ホーム > ベンダー動向, BPM, BPMN, 標準化 > SAP Netweaverと富士通Interstage BPMのBPMNビジネスプロセス実装設計能力を検証する

SAP Netweaverと富士通Interstage BPMのBPMNビジネスプロセス実装設計能力を検証する

人中心(ヒューマンセントリック)プロセス向けBPMツール群の中で業界標準であるBPMNを採用しているSAPNetweaver BPMと富士通Interstage BPM(Business Process Manager)の2製品について、BPMNによるプロセス可視化能力の観点から実装設計能力を検証してみた。この2製品は、現時点で最もBPMN標準に準拠し、日本国内でサポートを受けられる製品と評価しているからである。

それぞれの製品が提供するBPMNサンプルダイアグラムを次の図に示す。


Netweaver


Interstage

「BPMN標準に準拠している」私なりの基準は、まがりなりにもBPMNの特徴である①イベント、②外部プロセスとのメッセージ交換(相互関係)、を表記できる点をあげている。現時点では、BPMNサポートを表明しているベンダーの中でこの2点を表記できる製品は極めて少ない状況にある。

実行可能設計の夢と現実

BPMNの狙いはビジネスとITが同一のプロセス可視化標準を採用しビジネスプロセスに関わる業務要件を共有して双方のコミュニケーションギャップをゼロに近づけ、モデリングの最終成果物であるTo-BeモデルをBPMSのプロセスエンジンで実行可能なビジネスプロセスモデルに最小の労力で変換(設計)できることにある。OMGのBPMN標準開発チームは「人の介入なしに」この変換過程をゼロにする夢を追って標準仕様の拡張に努力している。しかし、BPMN標準で書かれたすべての図形表記を100%忠実に解釈し自動実行するプロセスエンジンは現在のところ存在しない。また、今後5年以内でも登場しないだろう。このギャップを埋めるには現在のところITエンジニアのプロセス設計能力に依存せざるを得ないのである。

プロセスモデル実装設計時に必要な変換スキル

ITエンジニアのプロセス設計能力とは、BPMNで表記したプロセスモデルを熟読し、ターゲットプラットフォームに機械的には実装できないプロセス要件を洗い出し、それらのミスマッチ要件をそれぞれのベンダー固有言語を使って実装するスキルである。下図はプロセスモデルの大きな変換点を示している。変換1は現状(As-Is)のプロセスモデルをあるべき姿(To-Be)に改変する過程であり、変換2はターゲットプラットフォームで実行可能なプロセスモデルに改変する過程である。変換1のスキル要件はビジネスアナリストに求められ、変換2のスキル要件はITエンジニアに求められる。ITエンジニアはBPMNで表記されたプロセスパターンの読解力を持つとともにターゲットプラットフォームのBPMN表記能力の限界を熟知しておく必要がある。


プロセスモデル変換パス

BPMNで定義したプロセス要件をどこまで実装につなげられるか?

SAPと富士通のご協力を得て当該製品が最新のBPMN1.1仕様で定義されている表記をどこまでサポートしているか次の資料にまとめてみた。

SAP Netweaver BPM編 (PDF – 399.2KB)

富士通Interstage BPM編 (PDF – 410.6KB)

この資料を見られた方の中には、「サポートできない範囲が多いね!」、「これじゃ使えないのでは?」と判断される諸氏がいらっしゃるだろう。私は逆に「ここまでできるようになった!」とプラス指向で受けとめている。

BPMNは、人中心(ヒューマンセントリック)プロセスモデルの表記とシステム統合(インテグレーションセントリック)プロセスモデルの表記の和集合であり、表記図形要素とその図形の組み合わせパターンも多様になる(パターンの参考:アメリカ国防総省(DOD)のBPMNを使ったビジネスプロセスモデル設計ガイドライン)。しかし、2製品が対象とする人中心プロセスモデルでは、システム統合プロセスモデルに比べて使用する表記図形要素は少なく、○×での判断は禁物である。

BPMN独特の表現にメッセージ中間イベントとタイマー中間イベントがある。これらは人中心のプロセスを表記するには非常に便利で頻繁に使用する。メッセージ中間イベントの例を挙げると、下図の送受信パターン1をよく使用する。この表記はSAP Netweaver BPMはサポートしていないが、送受信パターン2に書き換えればOKである。


送受信パターン

あえて表記サポートしてほしい人中心のプロセスパターンを挙げるとすれば、イベント準拠ゲートウェイのサポートだ。次の例は「外部にある回答を依頼し、その回答を受領後、その分析作業に移る。1週間経過しても回答がなかったら回答を督促する。それでも回答が得られなかったら回答が受領できるまで繰り返す。」といったビジネスプロセス(ポリシーの方が適切かも知れない)を簡潔に表現している。この表記はBPMN1.1で追加された新しい表現法で、このポリシーを文章で表現すると多様なアナログ的表現になるが、BPMNを使えば簡潔に形式化したデジタル的表現が可能であり、ビジネスアナリストが随所で使いたくなるパターンだ。このパターンはBPELには変換可能だが自動解釈して実行する人中心のプロセスエンジンは未だ存在しないため、このパターンで表記されたプロセス要件をどのような方法で実装するかはITエンジニアの腕にかかっている。


イベント分岐パターン
  

 

BPMN 2.0標準採択によりベンダー製品開発競争はさらに加速化する

現在審議中のBPMN 2.0仕様が本年6月ごろOMGで採択される予定である。この仕様策定にはIBM, SAP,Oracleが深く関与しており、システム統合(インテグレーションセントリック)プロセスモデルにもこの新しいBPMN標準が全面採用されるきざしがある。BPMN 2.0採択後は、BPMNを設計言語(”executable design language”)、BPELをシステム統合プロセスに限った実行言語(“execution language”)に位置付けたBPM/SOAの製品開発が進むものと予想され、人中心プロセスモデルからシステム統合プロセスモデルに至る全プロセスモデルがBPMNを使って設計できる多くの製品が来年の2010年には登場するだろう。

そのころには、「BPMNで定義したプロセス要件をどこまで実装につなげられるか?」という熱い議論がITエンジニアの間で話題になるような気がする。

岩田

広告
カテゴリー:ベンダー動向, BPM, BPMN, 標準化
  1. まだコメントはありません。
  1. No trackbacks yet.

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中