モデリング講座3 ”良い業務フローと悪い業務フロー（後編）”

前編では良い業務フローと悪い業務フローの違いをご説明しました。本編では良い業務フローを書くために、いくつかのアイデアをご紹介します。他にもいろいろとあると思いますが、参考にしてみてください。

良い業務フローを書くために

記述範囲を決める

業務フローを記述する目的に合わせ、記述範囲を決めますが、まず、全体の開始と終了を決めます。例えば販売業務であれば、「お客様から注文を受けてから、納品・またはサービスの検収から売掛金を計上するまで」などです。

次に販売業務をすべて一つの業務フローに記述しようとすると膨大な業務フローになるので、サブ業務に分解します。例えば販売業務の受注業務は「お客様から注文を受けて出荷部門に出荷依頼をだすまで」、出荷業務は「出荷依頼を受けてお客様に納品・検収を受け請求部門に検収報告をするまで」などです。

上位の大きな視点から徐々に分解して行き、詳細な業務のフローを記述します。その際、分解した業務間を繋ぐ情報（帳票やデータ）を明確にすると記述完了後の業務間の情報の断裂がなくなります。例えば「受注業務と出荷業務は出荷指示書（またはデータ）で連携する」などです。いきなり詳細な業務フローを書き進めると抜けや漏れが発生してしまいます。例えば「受注業務は受注情報の登録まで。出荷指示は出荷の業務フローで記述されるだろう」などと勝手に考えてしまうと業務の繋がりが途絶えてしまいます。

記述ルールを決める

図形を用いて業務フローを書く場合、四角形はマニュアル業務、角丸四角形はシステムを利用する業務、帳票はある図形、画面はあの図形など凡例を決めて周知します。　業務フローの全体形式ですが、レーンを区切って業務を実行する組織やロールを設定し、縦または横に時間の流れを表す記法が一般的なようです。形式は問いませんが、業務フローを記述する際は統一した記述ルールを決め、記述者が順守することが重要です。

また、どの業務フローでも発生する「稟議や承認の差し戻し」や「アプリケーション間のインターフェース」などの記述例をストックすることをお勧めします。記述例を蓄積してゆくことにより、全体として統一感のある表現となります。

粒度を統一する

業務フローに登場するひとつの業務ステップは「他者からのインプットに始まり、他者へのアウトプットで終わる」という切り口で記述するのが一般的です。粒度を統一するための判断ポイントは下記の通りです。

責任の所在が変わる場合
「他者」としているのは「責任の所在が遷移する」ことを意味しています。例えば、業務フローのレーンを組織単位とした場合に受注登録の担当者と登録内容の確認者が別の場合は「受注登録を実施する」ステップと「受注登録内容を確認する」ステップに分けます。
データの状態が変わる場合
インプット・アウトプットの情報が同じでも状態が異なる場合は１ステップとします。例えば「未確認」の情報を「確認済」にするのは１つの業務ステップとなります。
後続フローの分岐が分かれる場合
注文を受けた商品の在庫があった場合・なかった場合、稟議が承認された場合・否認された場合などの分岐がある場合は「判断」を１つの業務ステップとします。

チームを作る

IT化が進んだこの時代では業務の内容もITの機能も熟知している人は稀です。ひとつの業務フローの内容をすべて把握している人はいないという前提で業務を知る人、ITを知る人をチームとして業務フローを作成することをお勧めします。「ITの中身はわからないから・・・」、「業務内容はわからないから・・・」などとよく聞きますが、チームを組んでお互いに説明しあいながら業務フローを記述することにより、相互に理解がすすみます。

第三者に説明する

テストの問題を作成して、自分で回答すれば100点がとれるのは当たり前です。作成した業務フローを第三者に説明してみると、説明のしにくさ、理解されにくさが見えてきます。また、業務フローを記述する際にも「第三者に説明する気持ちで記述する」ことを心掛けると良い業務フローになると思います。逆に第三者として他のメンバーが記述した業務フローを評価する際には、「きっと、こうゆうことを言いたいんだな」という、日本人特有の「思いやりと察し」の視点を発揮せず、誰が見ても誤解のないように記述するようにアドバイスしてあげてください。