ワークフローサンプル: 長いワークフロー定義を、分割する方法

業務の流れを定義する際、「業務プロセスの【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で言えば、『メッセージ送信中間イベント』と『メッセージ開始イベント』で接続する。Questetra のデータ受け渡し設定については、以下の≪関連記事≫を参照されたい。

＜比較のためのフロー図：始発から終着までの業務プロセス＞