例えば『問合対応フロー』であれば、「s:問い合わせの受信」に始まり「e:回答の送信」に終わる。
例えば『請求書発行フロー』であれば、「s:請求データの入力」に始まり「e:入金確認」に終わるだろう。
・・・これらのワークフロー設定に異論は少ない。
しかし仮に、『s:引合対応』から『見積受注』や『製造』などを経て『e:請求入金確認』に至る様な、、、長い工程を「一つの業務プロセス」として定義したとすれば、それには大きな反論があるだろう。何と言っても、フロー図が複雑になり、その作業工程が見づらくなる。更には「業務データ」の項目数も必然的に多くなり、処理に必要なデータが見づらくなってしまう。
最も簡単な解決策は、≪(A)フェーズに分割して管理≫する手法だ。
一連の業務を「東京から大阪までの新幹線」に喩えれば、「(1)東京から名古屋」と「(2)名古屋から京都」と「(3)京都から大阪」に3分割して管理する方法だ。つまり、(1)~(3)それぞれのフェーズで重要な手順を、各設計責任者が定義する。『建築工事』や『研究論文作成』など、プロジェクト自体が長期に及ぶ業務を想像すればイメージしやすい。関与する人間(管掌する部門)が変わるポイントでフェーズ分割するのが王道だろう。
もう一つの解決策は、抽象化して≪(B)単純サイクルに分割して管理≫する方法だ。
「東京から大阪までの新幹線」で言えば、これを「発車から停車」と言うシンプルな業務プロセスの繰り返しと捉える。極めて汎用性が高くなり、また業務手順を詳細に記録できるようになる。同時に(一般論ながら)「全体」を俯瞰しづらくなる。
[発車から停車までの業務プロセス]