引き続いて個別作法のお話です。前回では、プロセスの始点、終点と依頼受付機能のようなお話をしましたが、今回は終点とプロセスの流れを見ることが中心となります。

それでは、プロセスの終点となるアクティビティとはいったい何なのでしょうか。どうなるとプロセスが終わるのか、どうやって終わらせるのかということです。前回、プロセスが起こされるのは、顧客接点からと内部から生じる場合のケースを提示しました。この二つのケースで終点の考え方が変わってきます。

お客さんからの依頼の場合は、その依頼に対して回答しなくてはいけませんから、その報告や情報提供といったことが終点となります。例えば、見積の依頼が来て、それに対して見積結果を返してやるといったプロセスがそれに該当します。

一方、内部プロセスの場合は、最終的には基幹DBを更新することがそれにあたります。それは、“ヒト・モノ・カネ”の出入りを表現したものになります。入出金、入出荷データなどの登録・更新ですが、この場合のプロセスの切り方をどうするかは考慮が要ります。

例えば、入出荷といっても厳密に言うと最後は代金請求して入金されてプロセスは完結するとも言えます。ところが、それだとプロセスが長くなるのと、性格が違うプロセスをつなぎますので、現実的には、ヒト・モノ・カネは別のプロセスとして一旦切った方がいいと思います。

その場合、DBへの登録・更新で終わる事が前提であること、ですから中間の過程でも例えば個別で一旦登録しておいて、それらを集約して続きのプロセスが走るような場合もそこで一旦切ってもかまいません。

こうしてプロセスの終点を見ていくと、基本的に「BS/PL」につながっているのかどうかという観点が必要です。別な言い方をすると、“勘定科目データ“を生成するためにプロセスがあると考えることになります。もしそうではなかったら（顧客接点の場合はこういうケースはもちろんあります）、そのプロセスの存在そのものを見直すべきでしょう。

次に、この終点のアクティビティで最終的に確定する必須データ項目を定義します。いままで述べてきたように、依頼から始まるケースでは、依頼された内容に対して登録・報告すべきデータ項目になります。例えば、見積依頼であれば、対象商品名、スペック、数量、価格、納期などになります。

内部プロセスの場合は、出荷、購買、製造などの商品別の量だとか売上高などといったものが対象となります。

さて、こうして最終的にどんなデータを確定するのかがわかると、その複数のデータをどういう順番で確定していくのかを考えていきます。この場合のデータというのはあくまで必須データのことです。参照データや付帯情報などはここでは外しておきます。

このデータ項目と順番を見るときにわかりやすいように「コンテ」というものを作ることを薦めています。コンテというのは映画などでも絵コンテといって映画を撮る前にだいたいのストーリーとカット割がわかるものを作りますが、それと同じです。業務では仕事のあらすじを決めておくといった感じになります。

ここで頭に浮かべてほしいのは、業務プロセス（マクロワークフロー）は、単位意思決定の連鎖であるということです。ですから、単位意思決定をコンテの一枚に埋め込むということがポイントになります。もう少し分かりやすく表現すると「依頼を受付けて何かを決めて次に依頼する」という動作のつながりとなり、決めるとはデータを確定していくイメージとなります。

ですから、コンテ1枚には、○○の依頼を受付けて、○○を決め、○○を依頼するという流れになります。例えば、見積の依頼を受けて、仕様を決め、見積依頼書作成を購買部に依頼するというような感じです。

そしてそこに、参照情報（業務ルール含む）、連携サービス、分岐を記入していきます。下図にそのイメージを示します。ただしここでは、参照情報、連携サービスはここでは厳密に書かなくてもだいたいのことでかまいません。

こうすると、業務プロセスのおおよその流れが見えてきます。次回から、その中間のアクティビティの作り方を考えていきます。