業務の流れを定義する際、「業務プロセスの【S:始点】と【E:終点】を何に設定するか」は、センスが問われる。『問合対応フロー』であれば、「s:問い合わせの受信」に始まり「e:回答の送信」に終わる。『請求書発行フロー』であれば、「s:請求データの入力」に始まり「e:入金確認」に終わるだろう。・・・これらのワークフロー設定に異論は少ない。仮に、『s:引合対応』から『見積受注』や『製造』などを経て『e:請求入金確認』に至る様な、、、長い工程を「一つの業務プロセス」として定義したとすれば、それには大きな反論があるだろう。何と言っても、フロー図が複雑になり、その作業工程が見づらくなる。「業務データ」の項目数も必然的に多くなり、処理に必要なデータが見づらくなってしまう。簡単な解決策は、≪(A)フェーズに分割して管理≫する手法だ。一連の業務を「東京から大阪までの新幹線」に喩えれば、「(1)東京から名古屋」と「(2)名古屋から京都」と「(3)京都から大阪」に3分割して管理する方法だ。(1)~(3)それぞれのフェーズで重要な手順を、各設計責任者が定義する。『建築工事』や『研究論文作成』など、プロジェクト自体が長期に及ぶ業務を想像すればイメージしやすい。関与する人間(管掌する部門)が変わるポイントでフェーズ分割するのが王道だろう。一つの解決策は、抽象化して≪(B)単純サイクルに分割して管理≫する方法だ。「東京から大阪までの新幹線」で言えば、これを「発車から停車」と言うシンプルな業務プロセスの繰り返しと捉える。汎用性が高くなり、また業務手順を詳細に記録できるようになる。同時に(一般論ながら)「全体」を俯瞰しづらくなる。[発車から停車までの業務プロセス][発車から停車までの業務プロセス:「1.出発の合図」画面](A)の概念に基づいた業務定義:『見積商談プロセス』や『請求入金確認プロセス』など(B)の概念に基づいた業務定義:『日報プロセス』や『汎用依頼プロセス』など当然の話ながら(A)と(B)は、どちらが良いと言うものではない。全社の業務進捗を可視化しようとするなら、≪(A)フェーズに分割して管理≫と≪(B)単純サイクルに分割して管理≫の両方を上手く組み合わせて、全社の業務領域を定義して行く必要がある。CIOは、事業戦略を考慮した中長期的な視点に立ち、各業務プロセスのオーナーシップ(プロセスオーナーの任命)を考えなければならない。ワークフローシステムやBPMシステムの製品選定よりも重要な仕事かもしれない。当然のことながら、必要な業務データが自動的に受け渡しされる事が望ましい。BPMNで言えば、『メッセージ送信中間イベント』と『メッセージ開始イベント』で接続する。データ受け渡し設定については、以下の≪関連記事≫を参照されたい。