プロセスコンポーネントモデルとJBoss Process Definition Language（jBPM）(参考記事・英語)についての素晴らしい記事に続き、Tom Baeyens氏はビジネスプロセス管理（BPM）のパターンについて7つのユースケースを通して解説する記事(リンク)を発表した。
氏によると、
BPMという言葉はあまりに多くの意味をもち、さまざまなことに対して使われるため混乱を招いています。BPMという言葉のもつ別々な意味を具体的に説明するためにこれらのユースケースを挙げます。
最初のユースケースは規律としてのBPMについて検討をしている。
規律としての BPMが意味するのは分析、文書作成、そして人々やシステムがどのように一体となって作業するかを表す方法の改善ということです。ほとんどのBPMはこれに該当し、その中にはソフトウェアやITのサポートといった形を取らないものも含まれます。MS Visioはビジネスプロセスの文書化で最も使われているツールです。
この定義は広く定着しているBPMの定義からはやや離れている。たとえば次のVan der Aalst氏とその同僚らは次のように定義している(リンク)。
BPM は経営の知識とITの知識が交わる場所のひとつで、包括的方法であり、経営に関わるビジネスプロセスを設計・制定・コントロール・分析するための手法とツールである。このビジネスプロセスには人、組織、アプリケーション、サービス、文書、その他の情報ソースが含まれる。
あるいはWikipedia（英語版）では、(リンク)
BPM にはビジネスプロセスの管理のため、そして必要があればその改善のためにおこなわれる組織行動が含まれる。ビジネスプロセス管理システム（BPMシステム）と呼ばれるソフトウェアツールはそのような行動をより迅速かつ低コストでおこなえるようにする。BPMシステムはビジネプロセスの実態を監視し、そのことで経営者は直感でなくデータに基づいてプロセスを分析したり変更することができる。
このどちらの定義でも成熟したBPMシステムにおける3つの主要部分が強調されている。つまりプロセスの設計、実行、モニタリングだ。特にモニタリングはBaeyens氏の定義にはない部分だ（以降のユースケースにも含まれてない）。氏の定義およびユースケースに出てこないのは、測定してないことは改善できず、そのためプロセスのモニタリングはBPMに不可欠のコンポーネントであるからだ。
以降のユースケースでは、ビジネスプロセス設計、設計から実行モデルへの変換、設計とモデルを同期させることに集中して書かれている。設計については、BPM設計の一つの面にだけ焦点が当てられている。それはプロセスをグラフィカルに表現することだ。
基になる分析図はソフトウェアに必要な入力として利用できるべきです。そうすればディベロッパは可能な限りその分析図どおり理解できるような実行プロセスを組み立てることができるはずです。
この考えを議論するのは簡単ではないが、まず疑問と思われるのは、はたして図式でプロセス設計が表現できるのだろうか、ということだろう。プロセス設計についてこの考え方よりも受け入れられている方法は、図式化以外のツールを使うということだ。
- プロセス検証：設計されたプロセスが「実行可能」であることを確かめる
- プロセスシミュレーション：プロセスの変更による影響をシミュレーションすることで、よりしっかりしたプロセスに改善することができる
確かにこのようなツールの大半ではプロセス実行モデルとはかなり異なるプロセスモデルを採用している。そのことで2つのモデル間の変換が必要になり、それがプロセス設計全体において弱点となることがよくある。「純粋な分析モデルから実行プロセスモデルへ自動変換することは一般的には不可能だ」というBaeyens氏の意見に賛同するのは簡単なことだが、かといって両方のモデルをカバーする単一のモデルを使う方法（jBPMの方法がそうだ）が唯一の方法ともかぎらない。たとえばOracleの製品(参考記事・英語)ではBPMN（Business Process Modeling Notation：ビジネスプロセスを図式的に表すための表記法）とBPEL（ビジネスプロセスモデリング言語のひとつ）を「部分的に」相互変換する機能がある。
2つめのユースケースではHIM（ヒューマン・インタラクション・マネジメント）(リンク)に基づいた非定型なタスク管理について焦点を当てている。非定型なコラボレーションプロセスが主要なBPM実装製品に含まれるようになれば、既存のBPMシステムのカバーできる範囲は間違いなく広がるだろう。
HIM の実例からわかるのは、人が作ったタスクというのは非定型なプロセスを生み出すということです。人はさまざまな役割に関わることがあります。そのような働き方をタスク管理システムによってトレースすることには大きなメリットがあります。まず、あるタスクにしばらく関わることになった時、その人がタスクに関するこれまでの経過全体について瞬時に理解できることです。2つ目は、監査記録が自動的に残ることです。
他の2つのユースケースでは、互いに密接に関わるサービスオーケストレーション（ある処理を行うために必要なサービス間の複合的相互作用を管理する）と非同期トランザクションアーキテクチャを取り上げ、プロセス実行の基礎となるプロセスの実装およびプロセスの起動について論じられている。しかしこの2つのパターンに関してBaeyens氏が議論しようとしているのがjPDLとBPELの違いなのか、技術的な詳細なのかははっきりしない。確かにJavaベースのjPDLには優れた柔軟性があるが、Baeyens氏はその代償、つまりディベロッパが追加コードを書かないといけないことについては触れていない。BPELとjPDLの違いをざっくり表せば、BPELはビジネスプロセスの実装用につくられたDSL（Domain Specific Language：ドメイン固有言語）で表されるのに対し、jPDLはBPELといった新しいDSL（7番目のユースケース参照）あるいはプロセスを構築するためのJavaフレームワークであるということだ。その結果、たとえばBPELがプロセスの複数スレッド化からディベロッパを保護するのに対し、 jPDLは明示的にスレッドコントロールをおこなう（6番目のユースケース参照）必要がしばしばあるという違いが生まれる。jPDLとBPELのどちらかを選ぶかという問題は、高レベルの言語を選ぶか低レベルの言語を選ぶかという問題と基本的に同じで、開発の柔軟性と簡易化のトレードオフなのだ（とはいえ BPELプログラミングがいつもシンプルであるとはかぎらないが）。
最後に、ビジュアルプログラミング（5番目のユースケース）についてだが、この場合はBPELとjBPMは高い互換性がある。ただjBPMで使われているアクティビティとう言葉の方がサービスという言葉を使うBPELより分かりやすい言い方ではあるだろう。
全ての人が、Baeyens氏のユースケースはBPMで実際にあることを良く表している、と賛同する(リンク)わけではないだろう。Oracleのエンタープライズマネージャ部門のアプリケーションおよびミドルウェア管理を担当するアーキテクトであるWilliam Vambepene氏によると、
Tom（Baeyens）は「BPMという言葉はあまりに多くの意味をもち、さまざまなことに対して使われるため混乱を招いています」と書いています。しかし彼はそのBPMという言葉の器に、私が知る限り今まで誰も入れてなかったいくつかのユースケースを放り込んで、混乱を小さくではなくより大きくしているのです。
Vambepene氏が書いているようにBaeyens氏の記事は「読むに値するものであるが」、jBPMとその今後、そしてBPM全般について特に読む価値があるものになっている。