Peter Woodhull氏は新しい記事「BPMとSOAのべき・べからず集」をこう始めている。
ビジネスプロセスの効率性と有効性を向上させるため、BPMとSOAに目を向けるビジネスが後を絶ちませんが、その多くは相変わらず的を外しています。アプローチは数多くあり、うまく行くものもあれば期待を裏切るものもあるのです。
Woodhull氏はBPMとSOAを実装する上でのべき・べからず集のいくつかについて論じている。べからず集は次のようなものだ。
はじめにソフトウェアを買う。Woodhull氏によると最悪の過ちは、BPM/SOAの第一歩をまずソフトウェアを評価し購入することから始めることだ。これが問題なのは、どのタイプのソフトウェアが必要かということを事前に分かっている組織などほとんどないからだ。ソリューションを既製品のソフトウェアに合わせるということは、ビジネスを誰か他の人に実行してもらうことに等しいのだ。
製品を購入することで踏み出される第一歩は、ほとんどが組織のITグループによって主導されており、結果としてボトムアップの支援運動と実装戦略になります。これはビジネスの戦略的目標と食い違う結果となります。プロセスやビジネスの要求よりも技術に集中する傾向があるからです。
組織的な変化に必要な努力を軽視する。ほとんどの人は変化にアレルギーがあるので、仕事が簡単になるとしても変化を嫌がるのだ。
ユーザとの間に適切な約束が取り交わされ、整備されつつある新しいプロセスとシステムをレビューし、コメントをつけ、検証し、意思決定を助けるという機会が与えられれば、ユーザは変化の意味を本当に理解して受け入れるのです。
何もかもやろうとする。BPM/SOAソリューションを１つの巨大なアップグレードないしロールアウトとして実装することはほぼ不可能だ。
BPMとSOAの取り組みは、どちらもその性質からして漸進的なものです。漸進的というのはつまり、機能のリリースは小さく制限されたものを頻繁に行い、相互に関連しながら成長するように実装していくのが最も良いということです。機能はコントロールされたやり方でイテレーティブに展開されるべきです。プロセスとサービスの管理と実装は相互に独立しているべきで、そうすることでユーザのグループに対してすぐに価値を提供することができるのです。
Woodhull氏のべき集は次の項目を含んでいる。
すべて発見から始める。氏は問題に対する明確な理解が得られる前に技術的なソリューションをかき集めることが、失敗する最大の原因だと考えている。
管理されているプロセスを正確に定義し、サービスコントラクト（WSDLファイルとデータスキーマ）を文書化することが、どんな実装を始める時でも最初に行うべき最も重要なことなのです。プロセスの仕様（つまり、ビジネスの要件）が正確かつ明確に文書化されて初めて、開発とプロトタイピングを開始するべきであり、そうでなければ開始してはいけません。
BPMとSOAは複合的なソリューションとして一緒にアプローチする。多くの人がBPMとSOAは２つの独立した取り組みで、異なる組織が異なる優先順位によって実装するものだと考えている。
BPMとSOAは、（中略）ビジネス内のあらゆる場所に偏在する極めて一般的な問題を解決するために利用される戦略であり技術です。両者については（中略）技術的なプラットフォームによるサポートもしっかりしています。BPMパッケージは非常に効果的な統合ツールですが、特に効果が出るのは人間とコンピュータシステムを１つのまとまったソリューションへと統合する必要がある時です。WebサービスとSOA技術はコードの再利用と、コンピュータシステム／プラットフォームと組織の間での相互運用をもたらす偉大な仕組みです。
ミッションクリティカルなプロセスから始める。あらゆる新しいアプローチと同じように、SOAとBPMも経営側のサポートを得るためには効果が証明される必要がある。
単独のミッションクリティカルなビジネスプロセスで、その価値を特定し定量化できると認められるものから始めなさい。理想としては、顧客に直接焦点を当てていて、まだ明確なソリューションが存在しないプロセスを選ぶべきです。こうすることで実装されたものが組織内のビジネスグループによって所有されるようになり、ITチームの負担にはなりません。
Woodhull氏は記事の最後で、SOAとBPMが一緒に実装された時の複雑さとそこで発揮される威力について強調すると同時に、技術ではなくビジネスに主導されたアプローチを取ることを勧めている。記事のべき・べからずに従うことで成功が保証される訳ではないが、失敗する可能性を減らすことはできる。