今日発売になる「日経SYSTEMS」9月号は「SOAアプリの開発基盤BPMツール」というタイトルでBPMSの特集を組んでいる。

ぼくもこの記事に関する取材を受け、ひとことだけ載っていたが、この記事について考えてみる。

まずは率直な感想は今のBPMの課題が浮かび上がったということである。どういうことかというと、事例として出ているものをよくみると２つのタイプがあることがわかる。

ひとつは佐世保重工の例にあるように機能とプロセスを分離して、機能をサービスとして外部化することでプロセスに組み上げるモデリングである。一方、他の事例では申請･登録系などを対象としたワークフローツールとしてのBPMSである。コードレス志向で開発生産性を高める方向に重きを置いたものである。

この二つの間で大きく違うのは、サービスの粒度である。前者は比較的大きな機能という捉え方ですすが、後者はそれよりも小さな粒度であるアクションレベルのものをＢＰＭＳでつなげている。

この二つでどちらが良くてどちらが悪いというわけではない。もちろん両方ともありだが、両方とも何かが足りない。

大きな粒度でプロセスを作ったときは、実装にどう落とすかという問題が残る。一方、ワークフローだとコアに近いところの業務プロセスへ展開した場合、膨大なアクティビティ数になってしまい、プロセスの可視化が難しくなる。

ということは、両者の課題をうまく解決すればいい。ビジネスモデルから業務プロセスへ落としこみ、それを動く仕組みとして実装していかなくてはいけないわけで、まずはビジネスモデルから業務プロセスへ連結性を維持するには大きな粒度がいる。それはそれで大きな流れのプロセスを作るのだ。これはマクロワークフローでもある。

次にその“粒”＝アクティビティ・機能の中を細分化されたフローに分解するのである。これはミクロワークフローで、申請・登録などはこれにあたる。

こうしたレベル化がポイントである。マクロワークフローとミクロワークフローに分けたが、言い方を変えると、固定的（静的）プロセスと変動的（動的）プロセス、あるいは戦略的プロセスと戦術的プロセスともいえるのではないでしょうか。

この記事からうかがえるようにまだまだBPMについての定義や体系が定まっていなく、人によって語っていることが違っていることも多い。

これから、いろいろな議論や実績の評価により、輪郭がはっきりしてくると思うが、単なる新しい個別のソフトウエアだとかアーキテクチャというだけではなく、業界構造やIT人材像なども変えていくほどの影響力があるということだけは確かだと言えそうだ。