【 ここから本文 】
ビジネス・コミュニケーション
ソーシャルブックマークに登録 ：
印刷用ページの表示
BPM製品のトレンドと導入／運用の4ステップ
「モデル」「デザイン」「デプロイ」「監視」の基本フローを押さえる
（2006年07月08日）
BPM導入／運用の基本的な4ステップ
BPMの導入／運用のフローは、「モデリング」「プロセス・デザイン」「デプロイ」「監視」という4つのステップ（図1）を経ることになる。まず、モデリングにおいてビジネス・プロセスをモデルとして記述し、次のステップでそのモデルを基に、実装用のプロセス・デザインを作成する。作成されたプロセス・デザインを実装し、ビジネス・プロセスの運用を開始した後には、そのプロセスを継続的に監視していく。この監視の段階では、運用中のプロセスの課題や改善点を特定するために、パフォーマンスを測定し、プロセス・モデルを修正するためのフィードバックを行う。そしてそのフィードバックを基にモデルを修正し、同じフローを繰り返していくというサイクルを継続する。
| 図1：4ステップに分類できるBPM導入／運用の基本フロー |
 |
（1）モデリング
BPMの第一歩となるビジネス・プロセスのモデリングでは、現状のプロセス、および改善策として提案されたプロセスのフローをモデル化し、パフォーマンス指標に結び付ける。そして、シミュレーションでそれらのモデルを分析することで、ビジネス・プロセスに最適化されたモデルを作っていく。
モデリング・ツールでは、パフォーマンスに関連するパラメータ（目標達成までの予測時間、リソースのコスト、可用性、フローの分岐点における分岐比など）を注釈としてモデル内の各アクティビティに付加する。この情報があることで、モデリング・ツールのシミュレーション・エンジンを使用して、さまざまなシナリオに基づいた分析を行うことが可能になる。
さらに高度な機能を有するモデリング・ツールでは、KPI（重要業績評価指標）に基づいてプロセスのパフォーマンスを測定し、パラメータを決定することができる。ただしこの場合は、単にアクティビティのフローを記述したモデルだけでなく、組織のリソースやプロセスのパフォーマンス指標などのモデリングも行わなければならない。
この機能は従来、ケースワイズ、IDSシェアー、ポプキン（現社名はテレロジック）、プロフォーマといった、ビジネス・プロセスのモデリング・ツールを提供するベンダーの独壇場だった。しかし現在、グローバル360、IBM、サヴィオンなどのベンダーが、BPMスイートの一部として、この機能を実装しようとしている。
このような動きに対してモデリング・ツールの専業ベンダー側では、BPMN（Business Process Modeling Notation）の普及を推進することでBPMスイート間の相互運用性を確保しようと試みている。スイート化によるBPMシステムの単一ベンダー化によって、BPM市場から締め出されることを防ぐためだ。
なおBPMNは、オブジェクト指向関連技術の普及に取り組む業界団体であるOMG（Object Management Group）が推進するグラフィカルな表記標準である。
（2）プロセス・デザイン
次のステップでは、プロセス・デザイナを使ってプロセス・デザインを作成する。前述したように、プロセス・デザイナーはGUIベースの開発ツールであり、モデリング段階で最適化されたモデルを基に、人的ワークフロー、アプリケーション連携、ビジネス・ルールなどを統合してプロセス・デザインを自動的に生成する。
プロセス・デザイナによる開発は、パレットから必要なタイプのアクティビティを選択し、それを結合していくという作業になる。アクティビティをカスタマイズしなければ、ほとんどプログラミングを行う必要はない。プログラムのコードは、GUI環境で記述されたフローチャートを基に、プロセス・デザイナがプロセス実行言語で記述していくことになる。
ワークフロー・アーキテクチャをベースとするBPMスイートの場合、このプロセス実行言語はプロプライエタリなものが多い。アクティビティは数種類のタイプがあらかじめ定義されており、設計者は、選択したアクティビティそれぞれに人的タスクや連携アダプタといったリソースを割り当てる。
これに対し、オーケストレーションをベースとするBPMスイートは、BPELで定義されているアクティビティで、サービスを呼び出すために利用される「Invoke」を用いて、Webサービスや人的タスク、連携アダプタを呼び出すという仕組みをとる。なお、これらはすべて、個々のWebサービスが有する機能や、その機能の利用方法を定義するための言語仕様であるWSDL（Web Services Description Language）で記述されたインタフェースを備えたサービスとして実装されている必要がある。
もう1つの違いとして挙げられるのは、ワークフロー・ベースのBPMスイートがサブプロセスという概念をサポートする点だ。サブプロセスとは、再利用可能な部分的プロセスのことであり、これによって複数のプロセス間でデータの共有と“状態”の同期化を行うことができる。
サブプロセスという概念が存在しないBPELでは、すべてがプロセスとなる。このため、BPELベースのBPMスイートでデータの共有や“状態”の同期を行うためには、プロセス内に明示的に定義する手間が発生する。この手間を削減するためにBPELでサブプロセスを扱えるようにするオプションとして、IBMとSAPがBPEL-SPE（WS-BPEL Extension for Sub-processes）という拡張仕様を提唱している。しかしこの拡張仕様は、まだ一般的に利用されるような段階には至っていない。
各社のBPMスイートが実現する機能はほとんど同じように見えるが、以上のようなアーキテクチャの違いが存在する。それに加えて、BPELを始めとする標準仕様に準拠している場合でも、各社のプロセス・デザインを、他ベンダーのプロセス・エンジン上で稼働させることは基本的には不可能だ。
（3）デプロイ
完成したプロセス・デザインは、プロセス・エンジンを始めとするBPMスイートのコンポーネントにデプロイされる。プロセス・エンジンは、IBM、マイクロソフト、オラクル、SAPなどの製品では、アプリケーション・サーバやそれに関連するミドルウェアが備える機能として提供されている。一方、BPM専業ベンダーのプロセス・エンジンは、ユーザーが利用しているアプリケーション・サーバ上で動作するものが多い。
プロセス・エンジンは、プロセスのインスタンスが実行されたら、それを定義済みのアクティビティ・シーケンスに渡すという処理を行う。このシーケンスには、外部アプリケーションとの連携、タスクのルーティング、プロセス全体の締め切りと目標の管理などのアクティビティが含まれている。
それらのアクティビティが完了したら、プロセス・エンジンはどのような出来事が発生したのかを記録するためのイベントを生成する。このイベントは、パフォーマンス管理コンポーネントによって収集され、ビジネス・パフォーマンスを測定するための指標として利用される。
（4）監視
収集されたパフォーマンス指標は、通常はOLAPキューブに集約される。BPMスイートには、ビジネス・パフォーマンスを測定するための指標と目標値の対比をGUIで表示するパフォーマンス管理ダッシュボードが用意されており、ユーザーはOLAPキューブを、この管理ダッシュボードを通して利用することができる。収集したデータ・セットを再計算することでOLAPキューブが更新されるため、ほぼリアルタイムでリポーティングやドリルダウン分析などを実行することが可能だ。
さらに、BPMスイートによっては、KPIが基準を外れたときにアラートを発する機能などを提供するBAM（Business Activity Monitoring）コンポーネントがバンドルされている。BAMをサポートしたBPMスイートには、アドビ、ファイルネット、IBM、インタリオ、サヴィオンなどの製品がある。これらの製品では、パフォーマンス指標をリアルタイムに更新することが可能だ。
以上のように、実行中のプロセスから指標を算出し、その指標を基にモデルのパラメータを修正することによって、モデル自体の精度を高めることができる。さらに、このような一連の取り組みは、プロセス全体の改善につながることにもなる。
Column 2
BPMに注力するマイクロソフトとBEA
Computerworld米国版
BPM市場では、2006年に入って特に目立った動きを見せている大手ベンダーが2社ある。その1社は米国マイクロソフトで、同社は、ビジネス・プロセス統合ソフトウェア「BizTalk Server 2006」の一般向けリリースを5月1日より開始すると発表した。もう1社は、BPMツールの新バージョン「AquaLogic Interaction Process 1.5」を2月13日に発表した米国BEAシステムズである。同社は3月1日には、BPMソフトウェア・ベンダーの米国フエゴの買収も発表している。ここでは、この大手ベンダー2社の動向を紹介したい。
BizTalkの新版を2年ぶりに提供するマイクロソフト
BizTalk Server 2006は、2004年3月以来のメジャー・バージョンアップとなる。マイクロソフトでBizTalkの製品マネジメント・ディレクターを務めるスティーブン・マーティン氏は、新バージョンの狙いは、企業システムの統合作業を簡素化し、ユーザーがビジネス・プロセスの管理に集中できるようにすることだと説明している。具体的な新機能としては、ビジネス・プロセスを複数の画面で順番に表示していくのではなく、単一のウィンドウ内で一覧表示できる管理コンソールが挙げられる。
また、ビジネス・プロセスの効率を監視／評価するためのポータルを構築するBAM（Business Activity Monitoring）ツールも用意されている。他社製アプリケーションとの連携に関しては、連携アダプタが12種類バンドルされる。これらのアダプタはオラクルやJ.D.エドワーズ、ピープル・ソフト（共にオラクルの1部門）などのアプリケーションに対応しており、料金は基本的なライセンス使用料に含まれている。
BizTalk 2006のベータ版はすでに提供されており、ヒューストンを本拠として石油・ガス採掘業者にシーリング材を販売するガルフコースト・スチールでは、同ベータ版でアプリケーション連携作業を進めている。同社では請求書の処理業務にBizTalkを使っており、既存のERPシステムとの接続も実現している。同社のeコマース・マネジャー、ジェフ・リンチ氏は、BizTalk 2006の新機能の中でも、ネットワーク管理者が単一のコンソールからすべての機能を管理できるようになった点を評価している。
「ネットワーク管理者がシステムの状況を監視しながら、アプリケーションの停止や起動を容易に行えるようになった。BizTalk 2004で同様な作業を行うためには、多数のツールを使って複数の手順を踏まなければならなかった」（リンチ氏）
加えてBizTalk 2006は、POP3をサポートしているため、電子メールからデータを抽出してデータ・ウェアハウスに送信したり、リポートを作成したりすることもできる。従来こうした作業は、1人の社員が3日間かけて手作業で行っていたと、リンチ氏は説明する。
買収でBPM製品ラインを拡充するBEAシステムズ
BEAは、AquaLogic Interaction Process 1.5の発表により、BPM製品市場に本格的に参入する意向を明らかにした。同製品は、2005年8月に同社が買収した米国プラムツリーソフトウェアのBPMソフトウェア「Plumtree Process Server」をベースに、BEAの既存BPM機能で補完したものである。
BEAの製品マーケティング担当ディレクター、クリスティン・ワン氏によると、同社のこれまでのBPMに対する取り組みは、既存のバックエンド・システムのビジネス・プロセスをWebサービスと結び付け、新しいアプリケーションを開発できるようにすることに重点を置いていたという。これに対し、AquaLogic Interaction Process 1.5では、ポータルを通じて管理領域をユーザーにまで拡張し、人的ワークフローに配慮した設計を採用したのが大きな特徴だという。
「BEAが人的ワークフローという側面に対応するのは、今回が初めてのことだ。結局のところ、実際に業務を遂行しているのはエンドユーザーなのだ。新製品は、紙ベースのプロセスと格闘しながら、各種バックエンド・システムのデータを結び付けて集積するという、彼らの作業を支援するものだ」とワン氏は説明する。
建築会社の米国ハブナニアン・ホームズでソフトウェア開発担当バイスプレジデントを務めるアンドリュー・リード氏は、アプリケーションやデータに対するアクセス権を従業員に与える際の承認プロセスを自動化するために、AquaLogic Interaction Process 1.5の導入を検討している。紙ベースで行われているこのプロセスを自動化することで、承認処理の効率の改善に加え、SOX法（Sarbanes-Oxley Act：米国企業改革法）の順守にも役立つだろうと、同氏は期待している。
以上のAquaLogic Interaction Process 1.5の発表のほかにも、BEAは、フエゴの買収によって同社のBPM製品群を拡充しようとしている。BEAの会長兼CEOであるアルフレッド・チュアング氏は、BPMはSOA（サービス指向アーキテクチャ）ソフトウェア市場の中で最も成長率の高いセグメントだと述べている。
フエゴはSOA環境においてビジネス・プロセスの結合やオーケストレーションを実現するBPMソフトウェアを提供している。これらの製品が新しい「AquaLogic Business Service Interaction」製品ファミリーに組み込まれることになる。
BEAによると、フエゴの「FuegoBPM」スイートはこれまでに170件を超えるBPMプロジェクトに採用されているという。BEAでは、フエゴ製品をAquaLogic製品ラインに組み込むことによって、企業のビジネス・プロセスやアプリケーションをSOA環境に統合するための共通基盤を提供できるようになると説明している。
