アーカイブ

Archive for 2009年7月

BPMNは人のためか、ロボットのためか?

2009年7月13日 3件のコメント

BPMNはビジネスプロセスの表記法に過ぎないため、描き手のバックグラウンド、関心事の違いによって可視化したビジネスプロセスモデルは様変わりする。 同じ業務プロセスを可視化した場合、描き手によって「人中心のプロセス」と「システム中心のプロセス」に描き方が分かれてしまうのである。具体的な例示でその傾向を説明し、誤った使い方に警鐘を鳴らしたい。

図1は、一般的に描かれる承認プロセスを示している。このプロセスモデルは誰が、どのような手順で承認を得るか人の作業の流れ(ワークフロー)を示している。 BPMNを使った代表的表記例である。 


TasksOnly
  

図1: 人中心の承認プロセス

ところが、SOA志向のITエンジニアがBPMNを使ってビジネスプロセスを描くと、図2に示すように申請者、管理者(承認権限者)、仲介システムの3者コラボレーションプロセスで描いてしまうケースが見受けられるのである。特にBPELを使った経験のあるITエンジニアは、このような人とシステムのコラボレーションをプロセスモデルの表現に使っている場合がある(例図参照:ここ)。この図ではBPMNの表記ルールに従って解釈すると、申請者、管理者(承認権限者)とその2者を仲介する申請承認システム、3つのビジネスプロセスが独立して存在し、それぞれのプロセスから発信されるメッセージの送受信でそれぞれの活動が同期していることを表している。同じ承認プロセスの図1と比較してどう思われるだろうか?図2は現業部門の方から見るととても難解で、中段に表記した申請承認システムが申請者、管理者(承認権限者)の間に介入し、その関係を支配しているように見えるであろう。これは、ビジネスプロセス中の人対人の関わり合い(interaction)の調整作業にシステムを介入させロボット化した技術中心思考の産物と言えるものだ。私はある特例のビジネスプロセスを除いて、このようなシステム中心の設計をしてはいけないと考えている。なぜなら、これはユーザー視点のビジネスプロセスモデルではなく、BPMNの使用目的のひとつであるビジネスとITのコミュニケーションが達成できないからである。


TasksAndBytes
 

図2: システム中心の承認プロセス

人が介在しないビジネスプロセスのロボット化

株式決済プロセスに代表されるストレート・スルー・プロセッシング(STP: Straight Through Processing)と言われるプロセスパターンがある。これは、95%以上の活動がコンピュータで自動化され基本的に人が介在しないプロセスである。このパターンでは、例外が発生したときプロセスが本流から離れ、人の介入によりその例外が調整される。 図2の表現形式は、このSTPプロセスパターンでのみ許されもので、業務実行ロボットの内部プロセス仕様を表現するためには有効な手段といえる。

システム中心の表現形式が生まれる背景

図2の表現形式の描き手の多くは、BPELを使った経験のあるITエンジニアに見られると言ったが、何故なのか?私なりの見解を述べたい。

原因は2つあると考えている。

一つは、 BPMNで表記するスイムレーン、つまり活動の実行者あるいはロール(役割)がBPELでは定義ができない点にある。BPELでは、実行者は基本的にシステムが前提なので、実行の主体者をシステムにしていまい、活動の実行者あるいはロール(役割)はそれぞれ独立したプロセスを意味するプールで表現しそれぞれのプロセスがメッセージでコラボレーションしながら作業を進める表現になってしまうのである。二つ目は、 BPELはブロック構造のXML記述であるためループバック(差戻し処理)はDo-Whileで記述するしか方法がない点がある。そのため、差戻し処理は図3に示すループに書き換えざるを得ない。

 
DoWhile

図3: ループバックの書き換え

なお、人間系プロセスで頻繁に登場する図4で示すような交差ループバックはBPELでは記述できないので注意していただきたい。これは「
BPEL信奉者の落とし穴」である。 


DoWhile2

図4:  交差ループバック

結論

主題に「BPMNは人のためか、ロボットのためか?」というテーマを提起したが、「BPMNは双方のためにある」が私の結論である。ただし、BPMNは2つの目的によって使い分けねばならない。たとえば、ITを活用する業務システムの場合、図5に示すレイヤーで人中心のプロセス図とシステム中心のプロセス図に分割し、前者は現業部門の作業の流れを中心に表記した業務設計書として、後者はバックエンドのシステムのプロセス設計書(ロボット)として分けて考えよう。くれぐれも、人対人、人対システムの活動を図2の表現形式で記述し、BPELを適用するアプローチは避けたい。BPELのプロセスエンジンを提供するツールベンダーの中には、図4に示す交差ループバック問題に言及せず人中心のプロセスを自動化できるような営業トークをしているので注意が必要である。

  1. 人のため→人中心のプロセス図

    プロセス構成要素: 人対人、人対システムの活動

    適用プロセスエンジン: ワークフロー

  2. ロボットのため→システム中心のプロセス図

    プロセス構成要素: システム対システムの活動(STPプロセスパターン)。

    適用プロセスエンジン: SOA、BPEL


2レイヤー
  

図5: ビジネスとITのプロセスレイヤー分け

最後に

「BPMNは人のためか、ロボットのためか?」は、米国のBPM/SOA関連ブロガー間でも「BPMN for People and Robots」のテーマで次のように論議されていた。

ビジネスアナリストグループ:

プロセス図の目的は何で、何を可視化するか良く考えてほしい。多くのBPMツールがこのようなロボット図を描いている。理論的には詳細データの送信、受信を使ってモデル化できるが複雑になり、可視化のゴールを阻害する要因になる。システムとの情報伝達に関わる方法を隠ぺいし作業の役割、責任に着目しプロセスを描くべきだ。

デベロッパーグループ:

ロボット図面では業務担当者やビジネスアナリストと効率良くコミュニケーションできないことは承知している。チームの内にビジネスアナリストが不在でコミュニケーションする必要がなければ、デベロッパーはロボット図面を描いての良いではないか。

仲介者の決め言葉:

プロセス図は誰のためにあるのだろうか?デベロッパーにとって不可欠なのだろうか?プロセスはアナリストによって設計されるべきでと考えていないなら、答えは簡単だ。トラディショナルなプログラム開発には、BPMは必要ないよ!

岩田

BPMN 2.0仕様の最終採択スケジュール

2009年7月9日 コメントをどうぞ

Bruce Silverの7/6付けブログによると先月の6/22~6/26にコスタリカで開催されたOMG会議でBPMN2.0仕様の提案ドラフトが採択され、次のファイナライズ作業を経て来年6月下旬に最終採択される予定だそうだ。

2009年9月1日: ベータ版仕様書発行

2010年3月1日: コメント受付締切

2010年5月24日: 報告書提出期限

2010年6月21日: 最終採択版の発行

7月から6~8週間のOMG一般会員およびDTC メンバー (Contributing and Domain Contributing level members)投票期間を経て、ベータ仕様書が発行される。その後、IBM、Oracle、SAPなどの提案主導ベンダーやその他ツールベンダーの仕様実装作業が始まり、6か月間のフィードバックコメント受付期間を経てベータ仕様書をブラッシュアップする工程らしい。したがってBPMN 2.0をサポートする製品の登場は、早くて来年7月と予想される。なんだか、世界経済の底入れ回復予想時期に合わせているような感じですね。

岩田