「ビジネスとITが出合う場所」のために何が必要か？：BPTrends（15）（1/2 ページ）

「ビジネスプロセスがポイントである」という点については、多くのビジネスマネージャ、ITマネージャがともに理解しつつある。しかし、両者が語るビジネスプロセスには齟齬（そご）が隠されているのだ。

[著：デレク・マイヤー, 訳：吉川昌澄，ウルシステムズ]

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

　ビジネスプロセス・マネジメント（BPM）が熱い話題であることは誰もが認めるだろう。あらゆるビジネス雑誌に取り上げられ、ハーバードビジネスレビュー誌の2007年4月号にはマイケル・ハマー（Michael Hammer）の記事が掲載された。CIOマガジンの昨年の調査報告では、BPMがCIOの関心事のNo.1であった。もし、あらゆる著者や記事が「ビジネスプロセス・マネジメント」という単語を同じように扱っていたとすれば、もっと簡単にどの会社がBPMに取り組んでいるかを調べることができるだろう。しかし、人々は同じ単語を違う方法で用いるものであり、記事の執筆者が何を意味しているのか、いちいち読んで理解しなければならないのが現実だ。

　2006年初頭に実施したBPTrendsの調査において、回答者たちはBPMを4つの異なる方法で定義した。

• コスト削減のイニシアティブ - 12％
• 新しいソフトウェアテクノロジ - 16％
• プロセス改善へのシステマティックなアプローチ - 26％
• プロセスを用いて組織を編成し管理する新しいアプローチ - 40％

　私たちは「ビジネスプロセス」は、ビジネスとITのマネージャたちが企業の問題を議論する際に利用できる共通の土台であり、共通言語たることができるし、そうであるべきだと信じている。

　ビジネスサイドの人ならほとんど、ITサイドが新しい技術に執着して結果よりも実装にばかり着目するといったことに不満をいったことが、一度や二度ぐらいあるだろう。あまりにも多くのビジネスサイドの人々が、ビジネスの主要な目的に対して何もしてくれないように見えるITの新規テクノロジへの執着に従ってきたのだ。同じように、多くのITサイドの人々は、ビジネスマネージャからの変更要求に挫折してきた。それらは、漠然としているだけならまだましな方で、最悪の場合、単に不可能な要求なのだ。

「プロセスを考える」だけでは足りない！

　私たちの経験において、ビジネスとITが相互に関与する方法についての革命は、1995年ごろからのインターネットの広範な利用とともに始まった。インターネットと電子メールの広範な受容に起因する変化により、ビジネスマネージャはよりテクノロジの話題の理解に務めるようになり、ITマネージャはよりビジネスの話題の理解に務めるようになった。突然、誰もが、コンピュータとソフトウェア技術は既存ビジネスに比べてあらゆる観点ではるかに統合されると考え始め、誰もが将来の新しいeビジネス企業がどうなっていくのかを見極めることに懸命に取り組んだ。

　多くの場合、ビジネスサイドの人々がビジネスプロセスの改良に注目し、ITサイドの人々はビジネスプロセスを支援するように構成されるべきだという考え方は、共通の合流場所に向けた重要な転換のように見える。その議論以降、ITサイドは一切、テクノロジの目的のためにテクノロジを売り込もうとはしなくなった。ITはビジネスプロセスを改善できるテクノロジを推奨するようになった。同じように、ビジネスの人々は、ITを微に入り細にわたって管理しようとはしなくなった。その代わりに、特定のビジネスプロセスを支え実現するためにITがどう使われているかを評価することに注目するようになった。いい換えれば、両者は、ビジネスにとって重要なプロセスについて話し合い、それを改善するために協力して働くようになったのだ。私たちはときどき、このアイデアを、下図を使って表現している。

図1　ビジネスマネージャとITマネージャの双方が賛同して特定のビジネスプロセスの改善に着目する

　しかしながら、私たちは懸念を持っている。というのは、すでに多くの組織がプロセスレベルに着目することで合意したかのように見えるが、ビジネスとITの双方がチームに何をもたらせば成功につながるかを、厳密に考えている組織はごくわずかであるということだ。

　私たちが顧客と話す中でしばしば出合うのは、何がプロセスなのか、それをどう分析すればよいのか、そしてどう支援すればよいか、そんなことは誰でも知っているという甘い思い込みである。もちろん現実には、ビジネスサイドとITサイドの人々は往々にして、プロセスの性質に関して似ても似つかない考えを持っているものだ。

プロセスには「レベル」がある

　サプライチェーンカウンシル（SCC＝Supply Chain Council）は企業のコンソーシアムである。ほとんどの企業の代表者は、その企業のサプライチェーンのオペレーションに責任を持つバイスプレジデント（VP）やシニア・バイスプレジデント（SVP）だ。私たちは、彼らとの会議に出席してきたが、ITの人々と出合うことはほとんどなかった。SCCのメンバーは非常に高いレベルのプロセスに関心を持つビジネスマネージャであり、多くの場合、そのプロセスは企業の境界を超えている。彼らは、詳細を実現することではなく、全体のフローを正確にとらえることに注力している。つまり、彼らはサプライチェーンプロセスを彼らが得るビジネスの結果だけに基づいて評価するのが普通であり、それがどう実現されているかは判断しないのだ。

　従って、われわれは共通言語を必要とするだけでなく、共通の分析レベルについて合意しなければならない。正しいアプローチは、ビジネスとITの両者が、自分がかかわるプロセスを特定できて、それらがどのようにかかわっているかを理解できるように、ビジネスプロセスの階層構造を定義できるビジネスプロセスアーキテクチャを開発することだと考えるかもしれない。しかし、このもっともなゴールは、しばしばフラストレーションの原因になる。それはEA（Enterprise Architecture）を開発するために米国政府が行ってきた努力を見てきた人であれば分かるだろう。シニア・ビジネスマネージャにはとうてい理解し切れない膨大な詳細情報に埋もれて、大きな絵（大局）を見失ってしまうことがしばしば起こる。ITの人たちは何でもかんでも膨大なザックマン（John A. Zachman）の“整理棚”（訳注：ザックマン・フレームワークのこと）に仕分けして、しまい込むことにとらわれる。共通の議論の土台を提供する高いレベルの全体像は、データベース編成の努力に終わってしまい、結局、ITチームだけにメリットがあり、ITチームだけが理解できるものとなってしまうのだ。

　近年、共通言語のアイデアの整備に取り組む人々は、組織におけるビジネスプロセスの階層のハイレベルの概観を与えるビジネスプロセスアーキテクチャ（Business Process Architecture）と、エンタープライズアーキテクチャ（Enterprise Architecture）とを区別すべきだと唱えている。なぜなら、EAはBPAを含んでいるかもしれないが、往々にして組織のITリソースを識別し構成するためだけに用いられる手法であるからだ。