Keith Swenson氏は、BPM.comの新しい記事(リンク)で次のように述べている。
BPMコミュニティで多くの混乱や困難が見られるのは、BPMを一種のソフトウェア工学であると考える人がいるからです。確かに、表面的にはBPMはソフトウェア工学のように見えます。要件から始めて、変数へ格納し取得する必要のある情報を決定します。関係の図ができるかもしれません。そして、最後に、ネットワーク接続されたコンピュータにインストールし実施できるものが完成するのです。しかし、この2つには違いがあります。そして、その違いこそが、BPMの存在理由なのです。
Swenson氏によれば、ソフトウェア工学は、50年以上に及ぶその歴史で、すさまじい進歩を成し遂げた。構造化プログラミングやオブジェクト指向プログラミング、高度なモデリング言語(UML)、そして開発の各段階でエンジニアを支援する多数のツールを生み出した。その結果、ソフトウェアエンジニアは、「ビジネスプロセス管理」を、図を実行可能なプログラムに変換する方法の1つとしてしか見ていないというのだ。
ハンマーを握ると、自分のまわりの問題はすべて釘のように見えてきます...ビジネスプロセスの手順も、まるでプログラムのステップのように解釈されます。ほとんど反射的に、ソフトウェアエンジニアは、高レベル関数を、制御フローなどを持つより低いレベルの一連の関数に変換できます。最終的に実行可能な機械語へ変換可能なものに翻訳できるのです。BPMは、ソフトウェア工学の世界ではまったく平凡なものを誇大に宣伝しているだけだ、とこの部類の人たちの多くは考えているようですが、だとしたら、どうだというのでしょうか？
Swenson氏は、ビジネスプロセスと典型的なプログラムとの違いによって、ソフトウェア工学とBPMとの違いを説明しようする。
「ビジネスプロセス」はプログラムではありません。プログラムによる支援は受けるかもしれませんが、ビジネスプロセスとは、組織が実行したいもののことです。ビジネスプロセスは、プログラム自体ではなく、プログラムの目的であると言えるかもしれません。ビジネスプロセスを管理するのは経営者であり、経営者は「ビジネス」を理解し、そのビジネスを行うための戦略を決定し、ビジネスの現状を評価し、状況の変化に対応するためプロセスの変更を決めます。ソフトウェアエンジニアはソフトウェアを管理するかもしれませんが、経営者はビジネスプロセスを管理します。
続いてSwenson氏は、BPMソリューションと典型的なプログラムとの主な相違点を概説する。
- 経営者は図を描きます。それは実行される図です。その図を、ソフトウェアエンジニアの便宜のために、別の形に変えてはいけません。実行のために、別の形に変えてもいけません...この変形は、特に処理能力が限られたマシンで、最適な実行のために行われます。ビジネスプロセスには、まだこれを必要とするものもありますが、ビジネスプロセスの大部分は、CPUの性能に束縛されません。
- 履歴や分析レポートは、プログラマがプログラムの作動具合を伝えるためではなく、ビジネスユーザーがその組織のパフォーマンスを評価する際にサポートできるように、元の図に一致している必要があります。
- ソフトウェアシステムでは、ユーザーがプログラムの内部構造を知る必要はめったにありませんが、ビジネスプロセスは、この意味ではプログラムではありません。プロセスをサポートするプログラムの実行時に、プロセス自身が見えなければなりません。プロセスに関係する人間は、プロセスのどのステップにいるか、次のステップが何か、その前のステップは何だったかを理解できなければなりません。これが、BPMとソフトウェア工学との最大の相違点です。
Keithは、混乱や誤解に至る大きな原因の1つに、BPMの設計と開発をソフトウェアエンジニアが行う場合が多すぎる、という点をあげている。
あいにく、BPMシステムを研究する人間の多くは、ソフトウェア工学畑の出身で、BPMが標準的なソフトウェア機能を持っているべきだと自動的に考えてしまいます。ソフトウェアエンジニアは、システムとは、情報を送り、受け取り、形を変える方法であると見なしていて、これらの点から実行可能なものにビジネス上の問題を還元するよう訓練されています。経営者は、バイトの送受信ではなく、責任やコミットメントに注目します。ビジネスプロセスを見る視点が異なるのです。この違いによる影響は巨大です。BPM(経営者用)機能にソフトウェア工学の機能をすべて組み込もうとすることによって、どちらにも役立たないものができあがります。BPELがビジネスプロセスを実装する究極の方法である、とまだ信じている人がいます。BPELは、送り、受け取り、形を変える方法を提供するだけです...これらは、ソフトウェア工学の要件ですが、ビジネス要件ではありません。ソフトウェアエンジニアは、これらのプリミティブがあれば、何でも実装できる、おそらくスプレッドシートでも実装できる、と言うでしょう。しかし、そもそもなぜスプレッドシートやBPMがあるのかという、肝心な部分を忘れています。スプレッドシートやBPMがあるのは、それらがソフトウェア工学ではないからなのです。
記事の最後に、Swenson氏は現在のOMG BPMN 2.0活動を次のように評価している。
BPMNは、ソフトウェアエンジニアが好むダイアグラム標準である、統一モデリング言語(UML)の方言にすぎないかに関して、OMGメーリングリストで大きな議論が起こっています。確かに、ソフトウェアエンジニアがBPMNを見ると、ソフトウェア工学に役立つものが見えるかもしれません。元来、OMGが、ソフトウェア工学によるソフトウェア工学のための組織であることを思い起こせば、OMGのメンバーの多くがこの結論に達しても、それほど驚くべきことではありません。UMLがすべての分野に役立つとさえ考えるメンバーも多いかもしれません。BPMNをUMLの方言にしてしまえば、図を実行可能プログラムに還元するソフトウェア工学の実践に、非常に便利でしょう。
BPMNは、人間がビジネス環境でどのように影響し合うかを経営者が表現するためのものです。このことも理解している人間がOMGの中に多くいます。我々のためにも、彼らの声が、すべての問題をソフトウェア工学の問題と見なすメンバーの声にかき消されないことを期待しています。BPMNは、ソフトウェアエンジニアの便宜のために存在するのではありません。BPMはソフトウェア工学ではないからです。
ソフトウェア工学とBPMとの関係について、業界には確かに多くの混乱がある。それらは、非常に異なるが、相互に関連する分野でもある。一方では、自動化なしにビジネスプロセスを設計、実装することは十分可能だ。また一方では、ビジネスプロセスの自動化には、ソフトウェア工学のかなりの関与が明確に必要である。
原文はこちらです：http://www.infoq.com/news/2009/01/BPMSoftwareEngineerin