前回は事業を実行するための企業の構造についてみましたが、まだかなり大きな括りですので、これを分解していくことになります。

前回最後の方で書いたリファレンスモデルでは、そこの落としこみをおこなっています。しかしながら、これもまだ粗いのでさらに細かくしていく必要があるのですが、リファレンスモデルではそこまでできていません。

ここは例をあげて説明した方が分かりやすいので、ごくオーソドックスな受注して出荷するというプロセスで考えてみます。

まず大きなプロセスである「受注―出荷」があり、それを分解すると、「受注」、「在庫引当」、「輸送手配」といったものに分解できます。つぎに、「受注」というものをみると、その中にもプロセスが内在しています。「受注受付」、「与信」、「納期確定」、「オーダー発行」といったものがあります。そして、最終アクションとして「受注メモ作成」、「連絡」、「承認」、「入力」といったものになります。

ここでは4段階に分解していますが、この程度の粒度で分けるのがいいと思っています。呼び方としては、上から「業務プロセス」、「業務サービス」、「アクティビティ」、「アクション」としていますが、どんな呼称でもかまわないと思っています。

要は、同じ粒度で分解していくことが重要で、下流にいくほどプロセスというより機能的な色合いが強くなります。また、人間系の処理に近くなりますのであいまいさが出てくるようになります。

そして、ここで大事なところは、下位2プロセスというか業務機能と言った方がマッチしますが、その機能である「アクティビティ」をどういう粒度で定義するのかが肝になるということです。上述のリファレンスモデルもこのアクティビティレベルに落とし込んでいないのです。

また、このアクティビティとその下のアクションレベルとの分離も非常に重要な考え方になります。
実は、この両者ではプロセスの特性や処理形態が違うことがわかります。そこを一緒くたにしてしまうと複雑になってしまいます。

このあたりの階層化の考え方や粒度設定については大いに議論するところになります。大きな括りから徐々に細かく分解していくことで、プロセスを表現していくアプローチでは、それぞれのレベルでの粒度の定義をしなくてはいけませんので、その考え方が納得できるものなのかが問われるわけです。

これまでは、いわばトップダウンアプローチ（ToBeモデルベース）でしたが、AsIsからみるボトムアップアプローチではどうなるでしょうか。それも基本的には一緒で、上流にはいかないので、アクティビティレベルを並べていくことになります。

もちろんここでもアクティビティとアクションの明確な分離が必要条件になります。対象プロセスを抽出して、プロセスの始点と終点を決めて、その間にアクティビティを配置することが基本になります。詳しくは、後のプロセス設計で出てきます。

繰り返しますが、最大のポイントはこの階層化と粒度設定にあります。ですから、粒度に求められる要件は何か、その要件を満たすための粒度の大きさと性格付け（何をもってアクティビティと定義するのか）を真剣に考えてみてください。