多くの文献で、ビジネスプロセス管理(BPM)の成功のための多くの必要条件のうちの一つとして、ビジネス側とIT側の密接な協力関係を取り上げている。このような協力関係を確立するための手段の一つが、Business Process Management Notation (BPMN)である。BPMNは、ITとビジネスで共用するプロセス定義言語とされている。BPMN 2.0で、直接プロセスを実行する記述が可能となり、結果として、いくつかのベンダーがBPMの実行言語として採用している。しかし、多くのアナリストはこのような実行時のサポートにより、言語がビジネス側の人々にとって複雑になりすぎたと考えている。Jim Sinur氏は、ビジネス側の人々に過度の要求をしていると主張している。
ビジネスの専門家にとってのBPMNは、ビジネスレベルの要求に合致するものではない。BPMNはITにとって十分なのだから、ビジネスの専門家にとっても十分であるに違いないと考えるひともいる。前者は真実だろうが、後者は全くもって的外れだと私は考えている。ビジネス側が、技術的なアイコンではなく、望ましいと考えるアイコンで自分たちのプロセスを記述したいと望む時に、もってまわった標準のフォーマットを彼らが理解することを期待することは、IT側の専門家にはできない。これは、「(パンがなければ)ケーキを食べさせておやり」と言っているようなものだ。このITの傲慢さがBPM技術を衰退させるかもしれない。BPMNは、実際のところ「Business People May Not... understand(ビジネス側の人々は理解できないかもしれない)」の略なのだ。
Sinur氏のブログのこの投稿には、大量の返信がついた。例えば、Scott Frances氏は、ビジネス側がIT側の人間にスキルの向上をお願いするのと同様に、ビジネス側の人間に新しいスキルを身につけるようにお願いすることができると考えている。
Jimは、ビジネス側に責任を免れさせていると私は思う。ビジネス側で新しいスキルを身につける必要は全くなく、単にナプキンに何かを書いて、それがプロセスになることを望む。思うがままに古めかしい図を書く。あなた以外のだれも理解できなくてもよいのであれば問題ないだろう(ご存じのとおり、標準の価値はチームの2人以上が作成されたものを理解できるところにある)。IT側の人間に新しいスキルを身につけて、もっとビジネス指向になれと依頼するのであれば、ビジネス側にプロセス改善をサポートする新しいスキルを身につけるように依頼することは、過大な期待だろうか。BPMNが記述方法として難しすぎることが問題なのではない。問題は、多くの人がBPMがBPMNに始まり、BPMNに終わると考えていることだ。ビジネスプロセスをマッピングするには、BPMN以外にも多くのことが必要であり、それらを改善していく必要があるのだ。
Keth Swenson氏は、BPMNの見た目に関する改良の大半は、ビジネス側のためのものではなく、開発者のためのもので、プロセスのグラフィカルなプログラム言語として変貌をとげさせるためのものだと書いている。また氏は、もしベンダーが実行よりもモデリングに力をいれているのであれば、ベンダーはBPMN 1.2から2.0に移行しただろうかと疑問を呈している。氏の考えは次のようなものだ。
エンタープライズ・アプリケーション・インテグレーション(EAI)やWebサービス・オーケストレーションともいわれる、サーバ間のインテグレーション型のBPMの場合、この種のプログラミングのために、BPMN 2.0で追加の規定が定義されたことの利点は大きいだろう。サーバではなく、組織の中のメンバーの行動を記述するために利用されるヒューマンスタイルBPMの場合、ユーザへの利点がないまま、BPMN 2.0は複雑さだけが増したと感じられるだろう。
Swenson氏のコメントに答える形で、Sandy Kemsley氏はこの考えに対して強く反対している。
私は、Keithは大切なものを大事なものと一緒にすてているように思える。多くの新たな構成要素が加わり、開発者にとってBPMNがより有用になったが、すでにビジネスプロセスをフローチャートで記述しているビジネス側の人々に不適切な基本的な一部分を提供しているわけではない。明確な指示がなければ、ビジネス側の人々(およびビジネスアナリスト)は、ビジネスプロセスを表現するためにフローチャートを使うのを、私はしょっちゅう見かける。彼等にBPMNのもっとも単純な一部を紹介することにより、これらのフローチャートが少なくとも標準化され、ダイアグラムで利用される形状に関しても誤解がなくなり、フローチャートのイベントに関するスパゲティー状態も緩和されるであろう。
Neil Ward-Dutton氏は中道の姿勢をとっている。
BPMNの適合性は、さまざまな要素に依存する。BPMN (特にBPMN 2.0)がビジネスが適しているという意見も、適していないという意見も単純すぎであり、白黒はっきりさせようとしすぎている。これはクラウドコンピューティングがITの未来だといっているのと同じだ。まずはじめに、BPMNを1か0かという視点で話さなければならないとしてしまっている。第2に、「ビジネス側」を単一ののスキルセットや経験、傾向をもった人種だと考えてしまっている。BPMNの中心となる一部分のシンボルは、ハイレベルな分析や設計の経験のあるビジネスアナリストにとって、とても有効なものであり、複数の専門分野にまたがるチームの共通言語を提供して、すばらしい効果が得られたという証拠は多数ある。
確かに、BPMN 2.0の新機能の大半は、BPMNを実行可能な言語にすることを意図して追加されたものだ。そして、標準全体をみると、とても複雑なのも事実だ。しかし、Bruce Silver氏が、自身の著書で述べているように、BPMN 2.0は、3つの異なったレベルで利用できる。記述のためのもの、分析のためのもの、実行のためのものの３つだ。もし、10個のアイコンからなるレベル1からビジネス側が始めるなら、それは複雑になりようがないだろう。しかし、この場合でも、ビジネス側とIT側とで同じように理解され、解釈される定式化された標準言語の利点はとても大きいのだ。