これまで、非定型で不安定な人間主体の単位意思決定とそれらを回す定型で安定なシステム主体の業務フロー制御という観点から、マクロワークフローとミクロワークフローの“場”について議論してきました。

ただし、業務システム全体について考えたとき、それだけではないことに気がつくと思います。すなわち、基幹システムとの関係やデータはどうなっているのということです。その関係が定義できなかったらただのワークフローで終わってしまいます。

プロセスで生成されたデータは、データベースに登録されますが、最終的には勘定系の決算システムでデータを更新することになります。ビジネス活動の結果がデータとして集約されます。すなわち、従業員数といったヒト、出荷量や在庫量といったモノ、売上高や経費といったカネというものになるわけです。

従って、システムの構造は3層構造になります。抽象的な言い方だと、機能とプロセスとデータの3層です。もう少し具体的に言うと、表層的な業務処理を行なうのが機能ですがユーザインターフェースと言ってもかまわないと思います。そして、中間層に位置するのがプロセスでこれはさんざん議論してきたとことになります。

そして、バックヤードにあるのがデータ層ですが、これは単にデータベースだけではなく、先ほどのように決算システムのようなものを指してもかまわないと思います。ERPの根幹のところです。会計システムでもいいかもしれません。

こうして3層にするのは、最初のエントリーでも書いてありますが、業務処理の性格が違うからです。非定型で不安定であいまいな人間系処理は機能で、定型で安定な逐次フロー型の処理がプロセスで、それらを集約して決算につなげるデータという区分けになります。

その他、構造的には、今まで言ってきたコアの構造での仕掛けを動かすためにサポート的に機能したり、サービスを要求したりすることも往々にしてあります。そうした連携もできる構造が望まれていて、これもSOA的で、Integration Centric BPMということになるのかもしれません。

実は、これからは定常、非定常も含めて業務プロセスの処理をサポートするための情報提供の充実がカギになるような気がしています。それは、いまやさまざまな情報が蓄積され、それを簡単に取り出せるようになったために、その情報の活用度の違いがビジネス遂行の優劣につながる可能性があるからです。

これを、BI（Business Intelligence）などと呼んでいますが、従来は結果の分析に使われるのが主だったように思いますが、それだけではなくプロセス実行時にも有用な情報を提供するようなBIが望まれるのではないでしょうか。
　
こうした、業務アプリケーションとそれが動くプラットフォームを３層にして、お互いに疎にして連携させるという概念が非常に重要です。BPM on SOAという概念の具体的な実行形態としての表現がここにあります。