BPMツールとは何か

先日、「BPMとBPMツールの関係」というブログ記事を書きました。その理由ですが、一般に「BPM」と「BPMツール（BPMS）」が一緒に語られる（ごちゃ混ぜになってしまう）ことが多いと思ったためです。
　実際のところ、BPMとBPMツールは全く別のもので、それぞれ単体で導入が可能です。そこで、前回の記事ではBPMとBPMツールの関係を整理しようと試みました。

ただし、なかなかうまく整理するところまではいかず、最終的には「BPM、BPMツール、SOAをうまく繋ぐ方法論が必要」という課題を提示して終わってしまいました。
　この「ビジネスとITを繋ぐ方法論が必要」という考えは今でも同じです。今月から始まったBPP研（ビジネスプロセスパターン研究）に参加する上での私の問題意識もそのあたりにあると考えています。ちなみに、来月のBPP研のテーマは「ビジネスと業務の構造化」ということですので、自分なりに業務をどのようにモジュール化できるかを考えていきたいと思います。

一方、今回のブログ記事の目的ですが、「BPMツール」の定義を明確化することです。前回の記事でBPMとBPMツールの関係を整理してみましたが、そもそもBPMツールとは何なのか、何ができるのかをここで明確にしておきたいと思ったのです。今回のブログ記事を書くにあたっては、以下の記事が参考になりました。

CIO Online ： 「BPMツール選択ガイド」
http://www.ciojp.com/contents/?id=00002398;t=10

この記事に書かれているBPMツールの定義をまとめると以下のようになります。

１．BPMツールの定義

「人やシステムが行うビジネスプロセスの管理・監視を自動化するためのソフトウェア」

２．BPMツールが提供する機能

次に、「BPMツールを使うと何ができるのか」ですが、「日経SYSTEMS 2008.9号」の記事は、BPMツールが提供する機能を以下の3つに分類しています。

1. モデリング機能（ビジネスプロセスの設計・可視化）
2. プロセスの構成要素に実行プログラム（Webサービスなど）をひも付ける機能
3. BPELなどで記述されたプログラムを実行する機能

一方、前掲の記事「BPMツール選択ガイド」では、BPMツールの機能を以下の3つに分類しています。

1. モニタリング・ツール
   （プロセスを監視し、イベント発生時に関係者に通知する）
2. ワークフロー・ツール
   （定義されたフローに基づいて、プロセスを実行する）
3. EAIツール
   （システム統合を支援する）

こちらの定義の方が、BPMツールの機能全体を網羅していると思います。日経SYSTEMSの記事は、2つ目の「ワークフロー・ツール」の部分にフォーカスしているのだと言えそうです。そこで、当ブログ記事では、BPMツールが提供する機能を以下のように整理しておきたいと思います。

BPMツールが提供する機能

1. モニタリング（プロセス監視、イベント発生時の通知）
2. ワークフロー（プロセス定義、実行）
   1. モデリング（ビジネスプロセスの定義）
   2. プログラム呼出（プロセスからWebサービスなどのプログラムを実行）
   3. フロー実行（BPELなどで記述されたフローを実行）
3. EAI（システム統合）

３．上記の定義は何に役立つか？

上記のように「BPMツール」を整理しておくことで以下のメリットがあると考えています。

ユーザにとってのメリット：
BPMツール導入を検討する際の評価軸として使用できます。

ベンダーにとってのメリット：
BPMツールについて説明・議論する際、内容を漏れなく網羅するためのマップとして使用できます。

BPELでシステム開発

日経SYSTEMSの最新号（2008年12月号）にBPELを使用したシステム開発事例が載っていました。

「事例に見る問題解決の軌跡：『BPELで業務アプリを開発 スキル底上げや性能向上に腐心』」（p.76）

UFJISさんが社内・グループ会社に展開するシステム開発でBPELを採用した事例です。記事を読む限りでは、BPMのためにBPELを使ったわけではなく、システム開発の手法としてBPELベースのモデリングと実装を取り入れたようです。それでも、最終的に画面数120の受発注アプリを開発したとのことですので、BPELを本格的に使用した先進事例として貴重な内容だと思います。

BPELの実行エンジンとモデリングツールは「Oracle BPEL Process Manager」と「JDeveloper」を使用したそうです。この記事を読んで参考になったのは、以下の３点です。

１．BPELを使用したプロジェクトの進め方について

初めから120画面のアプリを開発したわけではなく、約2年間の期間をかけて、開発基盤の整備、小規模アプリの開発、中規模アプリの開発という流れでプロジェクトを進めていったそうです。それぞれのフェーズにおいて、解決しなければいけない課題がいくつか見えてきたとのことですので、やはり大規模なシステム開発にいきなりBPMやBPELの手法を持ち込むのは非常にリスクが高いと思いました。

→ これまで慣れてきた開発手法や考え方を新しいやり方に置き換えていく必要があります。やはり、BPMのシステム開発では、スモールスタートから始めて、少しずつ開発のノウハウを蓄積していくことが望ましいと考えられます。

２．設計・モデリングのパターン化について

今回のシステムでは、画面をJSF、業務ロジックをWebサービスで実装したそうです。画面とロジックの連携部分も含め、確かにこのあたりの方式検討もしっかり行っておく必要があると思います。
また、BPELのモデリングを当初は開発者にすべて任せてしまったために、品質や性能のバラツキが発生してしまったとのことです。この問題に対しては、設計のベストプラクティスやBPELのサンプルソースを共有することで、対策を行ったということです。

→ 一般的なBPMプロジェクトでも、最終的にはBPMNをBPELに変換することになります。システムに落とし込むための最適なモデリング手法をパターン化して、開発者間で共有する必要があると思います。

３．BPELファイルの分割について

あるアプリに含まれるアクティビティ数が10万を超えていたため、BPMツールの制約により動かなかったそうです。この問題については、BPELソースを分割することで対応したそうです。

→ 使用するBPMツールの制約やメンテナンス性を考えた上で、適切なファイルの分割単位を検討しておく必要がありそうです。

事例でわかるWebサービス・ビジネス

4年以上前に出版された本ですが、それほど古さを感じませんでした。書籍の中に出てくる製品名や事例の一部には古いものもあります。しかし、それ以外の部分は今でも十分参考になりました。

この理由は恐らく、Webサービスの仕組み自体が当時からほとんど変わっていないためだと思います。また、当時の期待ほどWebサービスが普及していないという事情も背景にありそうです。

本に記載されているWebサービス活用事例は、今の時代でも参考になるものが多いです。逆に、当時の予想を超える画期的な利用方法はこれまで出現していないということだと思います。

Webサービスの今後に関する考察

本書を読んであらためて感じたのは、Webサービスはあくまでも技術にすぎないということです。技術を活かせるビジネス上のニーズがあれば、Webサービスは自然に活用されていくと思います。Webサービスが企業であまり活用されてこなかった理由は、企業システムにおいてWebサービス化の必要性がほとんどなかったということでしょう。

「UDDIを使用して外部のサービスを活用する」というアイデアが、楽観的すぎるのは確かです。しかし、企業内や企業間のシステム連携においても、アプリケーションをWebサービス化する必要性はそれほどなかったのだと思います。Amazonのように外部に公開するだけのメリット・価値がある「サービス」を生み出すには、ビジネス上の発想の転換が必要なのかもしれません。

今後、企業のシステム開発でWebサービスが活用されるかどうかは、当面のところSOAやBPMの普及次第とも言えそうです。SOAやBPMの観点からシステムの最適化を図るのであれば、アプリケーションをWebサービス化するメリットがあります。しかし、そうでなければ、これまで通り個別にシステムを開発して、それでハッピーということになるのでしょう。今後のシステム開発のトレンドについて、製品ベンダやSIerの動向を見守っていきたいと思います。
私としましては、当面は製品ベンダの立場から、BPMの普及に向けた啓蒙活動を行っていきたいと考えています。

BPMツール（日経SYSTEMS 2008.9号）

今月の日経SYSTEMS（2008.9号）にBPMツールが特集されていました。
「特集3 ＳＯＡシステムの開発基盤 ＢＰＭツール」（p.66）

6ページに渡る特集ですが、BPMツールのメリット・特徴、採用事例、製品一覧がほどよく網羅されていて、参考になりました。

記事中に「プロセスと機能を分離する」という言葉がでてきます。これはまさにBPMツールのメリットをうまく表現した言葉だと思います。ESBの導入やシステムのWebサービス化によって、システム間（機能間）の連携が可能になります。しかし、連携のロジック（プロセス）は、依然としてプログラム内に埋め込まれたままです。そこで、BPMツールを導入することにより、プロセスをプログラムの外部で定義できるようになります。これは、変更が多いシステムにとって大きなメリットだと思います。

また、本記事ではBPMツールの機能を大きく以下の3つに分けています。この分類も自分の頭を整理する上で役立ちました。

1. モデリング機能（ビジネスプロセスの設計・可視化）
2. プロセスの構成要素に実行プログラム（Webサービスなど）をひも付ける機能
3. BPELなどで記述されたプログラムを実行する機能

SOAやBPMを推進していく上で、BPMツールの活用が鍵になりそうです。私も仕事でBPMツールを扱っていますが、今後のBPMツール普及に向けて、ツール活用のメリットをうまくアピールできるように工夫していきたいです。

詳説ビジネスプロセスモデリング

BPMに関する本です。ただし、BPMそのものを解説した本ではありません。BPM（ビジネスプロセスマネジメント）とは、業務プロセスの分析、設計、実行、評価のサイクルを回して業務を改善していく手法です。

この本では、BPMを実現するための「プロセスモデリング」について解説しています。プロセスモデリングに関する本なので、やはりシステム寄りの内容です。「BPMのメリット」や「BPMとは何か」を知りたいビジネスマン向けの本ではありません。しかし、システムエンジニアやITアーキテクトがビジネスプロセスモデリングのアーキテクチャを把握するのには良い本だと思います。

かくいう私も、これからBPM製品に関わる機会が増えそうなIT技術者です。モデリング記法のBPMN、最終実行されるスクリプト（XML）のBPEL、よく使われるBPMNのパターン、この辺りはちゃんと読みましたが、その他は飛ばし読みといった感じです。
この本の良いところは単なる概念で終わらずに、実際のツール（特定ベンダの製品ですが）を使用したモデリングと実行の流れを体験できるところでしょう。

私の仕事では、本書とは別のBPMツールを使用していますので、こちらで動きを試せそうです。本書はアーキテクチャ全体を網羅していますが、実際にモデリングを行う上では、BPMNの詳細についてもう少し知っておいた方が良いと思います。とりあえず、以下のようなサイトの情報を利用して勉強しています。

@IT　BPMNを活用したビジネスプロセス・モデリング

UMTP　ローレベルBPMNパターン

BPMNを使いこなす上で、最初にはまりそうなのは「フローの流れとデータの流れは別物」というところです。この辺は、実際にツールを使ったりモデリングをしながら勘を掴んでいくことになるのでしょうね。