BPMN 2.0エンジンと各社BPMツールの実装

BPMを支えるツール群

BPMの実施にはBPMツールが不可欠です。BPMツールは、多くのツール（機能）を提供します。これが、BPMツールが自らを"BPM Suite"と呼ぶ背景です。

プロセス・モデリング・ツールは、一般的に、BPMNでプロセスをモデル化します。ビジネス・ルールを記述するツールには、これまで金融や通信業界などで培われてきたBRMS（Business Rule Management System）の設計技術やエンジンが採用されています。

ビジネス・ルールは、プロセス・モデリングで形式化します。しかし、ルールの詳細定義は、データ・モデリングと同様に、BPMN標準の範疇外です。このため、ルール表記の標準は、いまだに存在しません。

ルールは現在、旧来からシステム仕様の文書化で使われてきたディシジョン・テーブルを使って設計／実装する方式が一般的です。しかし、この方法では、ベンダーによって設計方法に差異があることは否めません。

サービス・インテグレーションは、SOA（サービス指向アーキテクチャ）基盤が不可欠です。変化対応力のあるビジネス・プロセスを実現するために必要です。

• モデリング
  • モデラー - 標準表記（BPMN）
  • シミュレーション
• ビジネス・ルール - BRMS
  • ルール・デザイン、ルール・エンジン
• インテグレーション
  • サービス連携、サービス・レポジトリ
• プレゼンテーション
  • GUI、フォーム
• モニタリング
  • BAM、パフォーマンス・モニタリング
• エンジン
  • 実行基盤

これらのツールを基に、プロセス実行基盤上にBPMNで設計したプロセス・モデルを実装し、業務をオペレーションします。このための環境を、図12に示します。

設計環境では、第2回で解説した、ビジネス・サイドの記述モデリング／分析モデリングとITサイドの実行可能モデリングを、BPMNを使って順次進めます。

実行可能モデルは、実行基盤上のプロセス・エンジンに実装され、駆動されます。プロセス・エンジンは、大別して（a）ワークフロー・エンジン、（b）ビジネス・ルール・エンジン、（c）サービス・オーケストレーション・エンジン、の3つに分かれます。

（a）ワークフロー・エンジンは、プロセス・モデルに記述された"人の作業"を、プロセス実行手順に従ってワーク・リスト待ち行列にディスパッチし、ロールと人の割り当てを管理します。

人の割り当てが完了すると、"人の作業"タスクが開始状態になり、タスクに割り当てられていたユーザー・インタフェース画面が立ち上がります。タスクの完了を待つといったコントロールが、エンジンの主な作業になります。

このコントロールは、一般的に、ベンダーがあらかじめ用意した「ワークリスト・アプリケーション（To-Doリストのようなもの）」と呼ぶユーザー・インタフェースを介して行われます。同機能は、ロールで関連付けられた実行候補者にそれぞれの関連ワークリストを配信する仕組みを提供します。

モニタリング機構は、主に"人の作業"タスクの開始／終了時間や実行者をログに記録することが主な作業です。これらのデータをサマリーすることにより、プロセスの開始／終了時間、プロセスの平均経過時間、作業停滞個所、ループバック（手戻り）回数、などの業務分析指標を手に入れることができます。

（b）ビジネス・ルール・エンジンは、ワークフロー上にある"システムの作業"に対してディシジョン・サービスを提供する専用エンジンです。

ビジネス・ルールは、プロセス・モデルとは切り離して、ルール・リポジトリと呼ばれる外部データベースに形式化されて保存されています。

サービスが求める入力データと出力結果をプロセス変数で受け渡すことで、結果を基にして後続の作業の流れをコントロールできます。ルール・リポジトリに保管されているビジネス・ルールは、変化の都度、業務オペレーションの中で更新されます。

（c）サービス・オーケストレーション・エンジンは、ESB（Enterprise Service Bus）を利用して、BPEL（Business Process Execution Language）で記述されたプロセスを実行制御するものです。BPELエンジンとも呼ばれます。

BPMを全社的に適用するとなれば、上記のツール群に加えて、ユーザー・アクセスの窓口となるポータル環境、業務効率やKPI（業績評価指標）値をグラフィカルに表示して分析するためのBI（Business Intelligence）ツールなども必要になるでしょう。

ヒューマン・セントリックBPMとインテグレーション・セントリックBPMの統合

BPMツールは、1990年代から「ヒューマン・セントリックBPM」と「インテグレーション・セントリックBPM（あるいはシステム・セントリックBPM）」と呼ばれる2つの系譜で発展してきました。

ヒューマン・セントリックBPMに分類されるツールは、「人対人」および「人対システム」の作業プロセスと効率性に焦点を当てて、BPMの概念を忠実に具現化します。しかし、既存アプリケーションとの連携機能や、Webサービス開発にかかわるサービス・インテクレーション基盤は、提供しないのが一般的です。

インテグレーション・セントリックBPMに分類されるツールは、サービス部品の開発や「システム対システム」における連携プロセスの設計／実行に焦点を当てています。しかし、「人対人」や「人対システム」にかかわるビジネス的な視点に立った管理機能が不足しています。

BPMの導入を考える企業は、BPM（ヒューマン・セントリック）とSOA（インテグレーション・セントリック）の支援ツールを、それぞれ異なるベンダーから購入して運用しなければならず、機能の重複、ライセンス料の肥大化、運用の複雑さといった問題が生じていました。このため、BPMは、一部の先進的な企業でなければ踏み込めない状況にありました。

こうした背景から、BPM製品とSOA製品の統合を望む声が強まりました。昨今、主要なSOA基盤提供ベンダーがBPM専業ベンダーを買収して統合を図っているのも、こうした背景がベースにあります。