BPMのビジネスケースづくり − BPMベネフィット・チェックリスト（後編）：BPTrends（6）（1/2 ページ）

BPMへの取り組みではBPMS導入だけでもかなりのベネフィットが期待できるという。3つの従来手法と比較しながら、そのベネフィットを見ていこう。

[著：ジム・ラデン, 訳：高木克文（日本能率協会コンサルティング），＠IT]

導入方策選択肢の比較

本稿は、米国BPTrends.comからアイティメディアが許諾を得て翻訳、転載したものです。

　プロセス改善を推進するためのBPM実施の選択肢は、概ね3つあるといえよう。1つ目はプロセスまたは機能に主眼を置くパッケージを購入する方法、2つ目は既存ソフトウェア・アプリケーションを機能拡張する方法、そして3つ目は自社ニーズに対応するソリューションを独自に開発する方法である。

アプリケーションの新規購入

　プロセス問題解決アプリケーションの購入には、4つの課題が付きまとう。タイム・ツー・バリュー（成果達成までの期間）、導入リスク、変更への対応性、およびスコープ拡大の可能性である。

■タイム・ツー・バリュー

　フォレスター・リサーチの調査結果によれば、産業界における新アプリケーション導入に要する平均期間は14.5カ月、遅延したプロジェクトの率は36％であった^{［文献6］}。BPM導入に関するデータと比較すれば、BPM展開では同期間内に3〜4バージョンのプロセス配備が可能と思われる。また、それぞれのバージョンから、かなりのビジネス・バリューが得られるであろう。

　さらに、たいていのアプリケーションでは、コアデータ・モデルと基本機能の構築からのスタートが求められる。プロセスの問題と直接かかわりがなくてもアプリケーションを的確に実行させるのに必要な機能装備のために、膨大な時間を費やすことにもなる。BPMの装備に関しては、このようなスタートアップ・コストは掛からない。

■導入リスク

　アプリケーションを丸ごと更新する場合、新たな学習を強要されるユーザーからの抵抗に遭うことが多い。もしその機能がユーザーのニーズに合致していなければ、さらにひどい事態を迎える。新しいアプリケーションは使用されず、プロセス効率は上がるどころか低下するであろう。

　これとは対照的に、主要なBPMソリューションでは、プロセスを今日のユーザーになじみのあるツール──例えばMicrosoft Outlookに組み込むことができる。訓練と導入の障害が、実質的に削除されるのだ。さらに、BPMを用いることで、プロジェクトチームは、プロセス参加者が必要とする特定機能への取り組みに集中することができる。それ以上のことは求められない。使われそうにないアプリケーション機能や必要なカスタマイズを見極めるために時間を浪費しなくても済むのである。

■変更への対応性

　アプリケーションのインストールが済めば、アプリケーションをビジネスプロセス変更の優先度に同調させるという難題に直面することが多い。アプリケーションは、頻繁な変更に対応できるようにデザインされていない。アクションとプロセスの標準化を重点対象としているのだ。それどころか、次項で述べるように、標準アプリケーションのカスタマイズは、問題点とコストの増加を招きやすい。

■スコープ拡大

　プロセス改善要求が、組織内の全部門から寄せられることもある。最初に受け取った新入社員オンボーディングに関する課題の次には、出荷ロジスティクスのマネジメントにかかわる課題が飛び込んでくるかもしれない。これらの課題ごとに個別アプリケーションを購入するのは、実務的に無理であろう。

　これに対し、BPMスイートは、いかなるプロセスの改善にも用いることができる。

既存アプリケーションの機能拡張

　既存アプリケーションが整っている場合には、主要プロセス領域における改善手段として、そのアプリケーションの拡張を検討する企業もあるだろう。この進路に関しては、コスト、複雑性、成熟度の3つの問題点が関与する。

■コスト

　既存アプリケーションのカスタマイズのために新たに購入するモジュールと開発ツールのコストはかなりの額、それもBPM購入費用以上に達する可能性がある。

　加えて、アプリケーションの拡張は、特異で高価なスキルを必要とすることが多い。多くの場合、アプリケーションの拡張には、独自の専用言語を用いなければならない。その言語に通じたコンサルタントの招聘（しょうへい）にも、多額のコストを要する可能性がある。

　その点、主要なBPMソリューションは標準仕様であり、導入展開に必要なコアスキルとテクノロジを修得したコンサルタント数も豊富だ。

■複雑性

　一般的に、パッケージ・アプリケーションの拡張は、将来のアップグレードに際する複雑さを増す。時には、かなりの大きさで増幅する。このことから、拡張やカスタマイズを行わないようクライアントに進言するアプリケーション・ベンダが多い。将来のアップグレードを可能にするために、「標準的な」運用を推挙するのだ。

　また、プロセスマネジメント機能を支援するためのトランザクショナル・アプリケーションを拡張すれば、ワークフローとレポーティングのような機能の個別開発を強いられることが多い。これは、開発チームを最大のリスクにさらすことになる。彼らは、データモデルやユーザーインタラクションといった事柄に関しては既存アプリケーションによる制約を受ける。その一方で、プロセスマネジメントに即した複雑な新機能の個別開発をも迫られることになるのだ。

■成熟度

　多くのアプリケーション・プロバイダが、既存のアプリケーションとプラットフォームへのプロセスの付加に取り組んでいるが、現時点での商品はまた未成熟だといわなければならない。ガートナー社は次のように報じている。

「BPMS市場に参入する多くの大手ベンダ（例えば、IBM、マイクロソフト、オラクル、SAP）が、プロセスの改善と環境適応力向上に関する今日の吹聴と関心の高さに乗じようとしている。しかし、彼らが本心で待ち望んでいるのは、BPMS機能がより大掛かりな商品の一部になるとき（2009年ごろと推定）である^{［文献7］}」。

　端的にいえば、現在大手ベンダが提示しているプロセスマネジメント機能では、プロセス改善を推進することができないのだ。