コンポーネントの粒度
粒度の話に行く前に前回話した業務アプリケーションの階層構造について図示したものを見ていただきたい。
例えばとして販売管理という業務アプリケーションについてのそれぞれのプロセスやサービス名を書いてある。このなかで一番小さい業務コンポーネントは細かすぎるので書いていないが、本回ではここを中心に議論する。
この業務コンポーネントの粒度を決めるのは、その理論的な基準もないため非常に難しい。そこで考えついたのが、「書類」という単位です。
業務というのは、結局人間を中心に仕事の依頼（指示）が来て、それを受付し、何らかの処理や判断を行い、またつぎの人に新たな仕事を依頼するという繰り返しではないかと思う。その一部をITが人間の替わりに振舞ったりすることはあっても基本的な流れは人間を経由してまわっていくのではないでしょうか。
そのとき、受付－処理－依頼というアクションというかタスクというか、そういった単位業務処理は、書類で受け渡すことになるのではないのかということです。
「○○依頼書」で依頼して、その依頼書を受け付けて、処理というのは依頼書の作成・編集に相当して、例えば承認にしてもその書類に承認のサインをすることであるし、その時点でその書類が最終化され、次のステップのきっかけになっていく。
これは、何も書類になっていなくてもよくて、例えば「在庫引当」というような場合、あたかも「在庫引当依頼書」を発行したかのように振舞えばいいわけで、ほとんどのケースでそうした単位に分けることができる。そうです、この書類のライフとでも言ったらいいと思うが、一つの書類に対する「作成－編集－確定－承認」の単位を業務コンポーネントとすれば、すごく分かりやすいし、そのコンポーネントは業種・業態や環境の変化に左右されない。
そして、この業務コンポーネントを「受付」、「依頼」を介して、BPMがプロセスにしていくことになる。
