ビジネスプロセスの標準規格：BPTrends（1）（1/2 ページ）

ビジネスプロセスに関する標準規格がさまざまな団体、企業から提唱されている。それらはどのような場面で使われるものなのだろうか？ BPTrends編集責任者のポール・ハーモンが解説する。

[著：ポール・ハーモン, 高木克文（日本能率協会コンサルティング），＠IT]

今日のビジネスプロセス標準規格

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

　たいていの企業のたいていの社員は、仕事の標準規格について気に掛けることがない。彼らの仕事は、それをどのように遂行するかに関する共通の理解と合意を得た多くの約束事と協定に基づき、極めて単純化されたものである。彼らは、その事実に思いをはせることなく、単に仕事をこなしているにすぎない。

　車の運転では、道路の右側を走ることと左側を走ることの間に、何の違いもない。しかし、特定地域内では、そのいずれを選択するかについて、すべての人間の合意が欠かせない。同様例で別の観点からいえば、ネジ頭の形状数を限定し、2セットのドライバーでほとんどの場合に対応できることで、われわれ全員が恩恵を被っているのである。

　筆者（ポール・ハーモン）は、ほかのアドバイザリ・Webページ^※1で、ジェフリー・ムーア（Geoffrey A. Moore）の技術導入ライフサイクルモデルについて論じたことがある（図1）。

※1 訳注：本稿を含め、筆者が月次発信するBPM論考シリーズ

　簡潔にいえば、イノベーターの範疇（はんちゅう）に属する企業は大学や研究機関から直接新しい技術を採用し、それを大きな競争力の源泉となる突破口として活かそうとする。その技術を役立てる方法を見いだすために、膨大なリソースを積極的に投じている。早期導入者は少し遅れて技術を採用し、競合企業より先に用途を開発することで競争優位に立とうとする。

　早期多数派に位置する企業は、新技術を導入する前に、その技術の有効性が明らかになるまで待つ。それにより、新技術の実験と未成熟なツールとの格闘に必要なコスト高の努力を回避する。さらに注目されるのは、彼らが標準規格が整うまで待とうとすることだ。別のいい方をすれば、少なくとも技術領域における標準規格開発は、技術ライフサイクルの早期導入者フェイズの期間中にベンダと先行的ユーザーによって遂行される活動なのである。

図1　ジェフリー・ムーアの技術導入ライフサイクル

　標準規格開発への取り組みに関心を持つ企業は、そう多くない。たいていの企業は、技術の普及体制が整うころには標準規格も完成しているはず、と見込んでいるのだ。数年内に有効な標準規格が作成できなかったために、キャズム^※2に落ち込み消え去る技術もある。

※2 編注：規格をリリースできなかったとすれば、死の谷というべきかもしれない

　標準規格について考えるときに念頭に置かなければならないもう1つの事柄は、デファクト・スタンダードとデジュアリ・スタンダードの違いである。デジュアリ（公的な）・スタンダードは、標準規格機関や業界コンソーシアムによって設定される。片や公式的取り決めを求めないコミュニティによって定められるのが、デファクト（実際上の）・スタンダードだ。

　例えばMicrosoft Windowsは、90％以上のPCユーザーが依存するマイクロソフトのOSである。それはOSのデファクト・スタンダードであり、PC用ソフトウェアを売ろうとするベンダであれば、それを支持せざるを得ないであろう。

　複雑で急速に進展する環境下では、デファクト・スタンダードの方が、デジュアリ・スタンダードよりも重要である場合が多い。デジュアリ・スタンダードの決定には、通常、より長い時間がかかるからだ。別のいい方をすれば、有力なベンダが一般の標準規格に従えない場合に裁定を下すのは市場であり、結局はデジュアリ・スタンダードとなるベンダが勝利を収めるのである。

　これらの考察を念頭に置き、今日のビジネスプロセスに関する標準規格について少し述べたい。この論述の整理の仕方として、標準規格を利用する立場に応じ、それらを3つの大きな枠組みに分類してゆくことになろう。

　まず、エンタープライズレベル標準規格は、ビジネスマネージャが、事業活動を分析し体系化するために使用する。

　プロセスレベル標準規格は、ビジネスマネージャとビジネスプロセス担当者が、ビジネスプロセス変革プロジェクトの実施に臨む際に使用する。ビジネス・プロジェクトの実施には多様な立場の個人が携わるため、この領域の取りまとめが最も難しい。ある場合には、ビジネスマネージャがビジネス改革プロジェクトの実施に当たる。一方、ITビジネス・アナリストその他のIT関係者がプロセス自動化プロジェクトを遂行するといった実態がある。

　実施レベル標準規格は、プロセスにかかわる問題のソリューション開発担当者によって使用される技術を特定対象とするものだ。この領域の標準規格の大半は、ソフトウェア開発の方法あるいはソフトウェア・ツールのインターフェイスの方法を定めたIT標準規格である。既存の、あるいは現在開発途上にあるビジネスプロセス標準規格のすべてを包含するのはほとんど不可能なことだが、大局的見地からの概観は持ちたい。

　いうまでもなく、筆者はこの論述の構成と標準規格の分類を筆者自身の経験に照らして行った。これらの標準規格を、筆者と異なる様式で整理される方もおられるに違いない。また、筆者の考えで分類した標準規格の中には、ほかの範疇に位置付けてもよいものもあるだろう。いずれにせよ、概観を簡潔に提示することが必要なのだ。

エンタープライズレベル・ビジネスプロセス標準規格

　エンタープライズレベル・ビジネスプロセス標準規格は、ビジネス・パフォーマンスの概要把握、評価、およびマネジメントの体系化を支援するツールとして、エグゼクティブとシニア・ビジネスマネージャに使用される。さらに、エグゼクティブ・コミッティ傘下にBPMグループを設置し、同標準規格をマネージャのパフォーマンス評価とプロセス介入優先順位設定のツールとして用いている企業もある。

　恐らく、エンタープライズレベルで最も広く用いられているビジネスプロセス標準規格は、キャプランとノートンのバランスト・スコアカード（BSC）による経営評価アプローチであろう。これは事実上のデファクト・スタンダードであり、多様な様式で用いられていると思われる。しかし、多様ではあっても、キャプランとノートンのアプローチの改変版の間には十分な共通項が見られる。もしバランスト・スコアカードを用いているかと問われた場合、たいていの企業は直ちに「イエス」か「ノー」の回答ができるはずだ。

　エンタープライズレベルにおいて、最も注目されるビジネスプロセス標準規格が、サプライチェーン・カウンシルのSCORフレームワークと方法論である。SCORは、複数企業にまたがるサプライチェーン・プロセスを構築し評価するためのツールとして、サプライチェーン・マネージャたちによって開発された。バリューチェーン全体の定義、ベンチマーキング、および評価を行うための標準規格として、急速に普及している。その増幅版では、SCOR+とSCOR/ DCOR/CCOR（サプライチェーン・モデル、デザインチェーン・モデル、カスタマーチェーン・モデルに対応）の、いずれかの名称が使用されるようになった。

　今後数年間には、プロセスセントリック・アプローチを導入するシニア・エグゼクティブが増加する。これに伴い、SCOR+の重要度も増すに違いない。

　VCORは、SCOR+と非常に類似点が多いが、もう1つの異なるアプローチだ。eTOMは、テレコム業界向けに特別に作成されたフレームワークである（今後は、ほかの業界でも、同様のフレームワークが作成される可能性が大きい）。

　エンタープライズレベルで時々用いられる、もう1つの標準規格が、ソフトウェアエンジニアリング・インスティチュート（SEI）のケイパビリティ成熟度統合モデル（CMMI）である。CMMIをITプロセスのパフォーマンス評価に用いているケースが圧倒的に多く、この場合には、CMMIをプロセスレベル標準規格と位置付けるのが妥当であろう。しかし、一部の企業では、すべてのビジネスプロセスを評価し全体組織の動向を見極めるために用いられている。この場合には、エンタープライズレベルのツールとして機能していると見てよい。

　さまざまな米国政府機関の支柱になっているのが、連邦エンタープライズアーキテクチャ・フレームワーク（FEAF）だ。FEAFは、ある意味ではエンタープライズ・ツールであり、いくつかの機関がその位置付けで用いている。しかし、ITアーキテクチャ構築のアプローチとして用いられることがほとんどで、この場合には、ザックマンのようなIT実行標準規格の範疇に含められるであろう。

　図2に、筆者が想定する主要なビジネスプロセス標準規格の位置付けを示しておく。

CMMI

図2　ユーザー別ビジネスプロセス標準規格（クリック >> 拡大）