道具としてのBPM

さて、SOA基盤に乗っかった業務プロセスをデザインするにはどうもBPMがよさそうだということになってきた。でもBPMとは何なんだろう。Business　Process　Managementというけど業務プロセスをマネジメントするって実はよくわからない。

そこで提案したいのは、BPMのMはMapper／Modeler／MonitorのMであることです。すなわち、業務プロセスをデザインするための道具（これとは別にエンジンとしての機能はもちろんある）と考えてしまったほうがわかりやすい気がするがどうだろう。

Mapperというのは、機能あるいはサービスをマッピングするツール、またはハブとして機能させることである。

Modelerは文字通りモデリングするためのツールで、しかもシミュレーションができることが必要である。このツールを使いモデルを描きながらシンプルで一貫化されたプロセスになっているかを検証していく。このとき、重要な機能として制約条件やルールによるチェックが自動的に行なわれることが望ましい。

例えば、プロセスのひとつの構成要素であるタスク(アクティビティ)のつながりの中で前のタスクのアウトプットが次のタスクのインプットになっているかだとかプロセスに重複業務や迂回業務が発生していないかなどをチェックしてくれて、それに従ってシミュレート(評価)しながら作っていくと、自ずとめざすプロセスができあがるというのが理想的である。

Monitorは業務の動きを監視し、異常の発見をおこなう。ここでは、パフォーマンスの監視というより、むしろ業務の流れの停滞を見つけたり、目標からの乖離などを探る役割である。

どうも、ITに限らないことかもしれませんが、概念的あるいは戦略的なことを大きな声で言う人がいますが、ではそれが実際に実行できるかというと、実は方法論を持っていないことが多いような気がします。

また、素晴らしい方法論でもそれが使えるのはごく限られた天才でしかなかったといったことも起こります。ですから、あるレベルのスキルをもった人（誰でもというのは無理ですが）が、それを使うとだいたいできてしまうという「方法（メソッド）」が必要となります。そのメソッドをBPMと結びつけてパッケージ化できたら素晴らしいと思います。このメソッドについては後でもう少し詳しく議論します。

そして、このパッケージを使いこなし、最適なビジネスプロセスを設計できる人をビジネスプロセス・デザイナー（BPD）と呼びたい。これまで、システムエンジニア（SE）と呼ばれるひとたちがいるが、そのネーミングからいくと、どうもビジネスのことをちょっとおろそかにしているイメージだ。だから、ビジネスエンジニア（BE）と呼んだほうがいいと思っていたが、それでもエンジニアという意味が単にモノを設計する感じとなるので、これからはデザイナーのほうがしっくりいくように思う。