dhbr0809106.html
「超」リエンジニアリング革命
（「サービス指向アーキテクチャー」が生み出す）
DHBRの記事を素材にした「示唆・学び」の共創・創発の場
「サービス指向アーキテクチャー」が生み出す
「超」リエンジニアリング革命
The Next Revolution in Productivity
マイクロソフト ビジネスアーキテクチャ リード
リック・メリフィールド Ric Merrifield
マイクロソフトのディレクター｡ビジネス･アーキテクチャー事業のリーダーのー人。
アクセレア CEO
ジャック・カルフーン Jack Calhoun
マサチューセッツ州ランドルフのコンサルティング会社､アクセレアのCEO。
シナプタス CEO
デニス・スティーブンス Dennis Stevens
ジョージア州ノークロスのコンサルティング会社､シナプタスのＣＥＯ。
ガートナーの調査によれば、
2007年に構築されたミッション・クリティカルなITシステムの半分以上は、
「サービス指向アーキテクチャー」(SOA)によるものだという。
この話を聞いて､新手のIT投資物件の登場かといぶかる向きもあろうが、
SOAが登場してきた背景、その目的と期待される効果について理解すれば、
そのような疑いも解けるはずである。
かつて一世を風扉したリエンジニアリングは、自社固有のビジネスプロセスを
カスタマイズすることで､効率性と生産性の向上を目指すものだったが、
SOAは、ビジネスプロセスの目的や成果､代替サービスや外部化の可能性に注目し、
重複の解消と部門横断的な共有､標準化されたプラグ・アンド・プレーによって、
21世紀の事業環境にふさわしいビジネスプロセスの構築を目指す。
本稿では､保険会社のハーバード・ピルグリムなどのケースを通じて、
SOAのポテンシャルとその導入方法について検討する。
1. 課題はプロセスからアクティビティに移行
リエンジニアリングヘの取り組みが始まって、かれこれ20年が経つ。
分散していた多くの作業やデータを統合し、部門横断的なビジネスプロセスを築き上げることで、コスト削減、サイクルタイムの短縮、サービスの改善など、それなりの効果は上がっている。
その一方で、リエンジニアリングを導入した企業の多くがいま、壁にぶつかっている。
ただし幸いにも、その壁を乗り越える方法が登場している。
インターネットを介してさまざまな機能を使ったり、共有したりできる新技術が開発されたおかげで、取り組むべき課題はもはやプロセスではなくなりつつある。
取り組むべきは、プロセスを構成する、たとえば製品の価格設定、請求書の発行、顧客別のリスク評価、開発中の新製品で優先すべき性能や特徴の決定など、事業にまつわるアクティビティになっている。
これらアクティビティを、〈レゴ〉のようにくっつけたり、外したりできるソフトウエア・コンポーネント（ある仕様に従って書かれたオブジェクト）として、設計できるようになった。
これに大きく貢献しているのが「サービス指向アーキテクチャ」（ＳＯＡ）である。
これは比較的新しい方法で、アクティビティをサポートするソフトウエアを設計して展開する。
ＳＯＡの強みは、ユビキタス化しつつあるインターネットを標準化された方法によって利用し、単一のアクティビティ、あるいは複数のアクティビティからなるプロセスにアクセスできることである。
そのアクティビティを実行するためのケイパビリティが手作業であれ、完全に自動化されたものであれ、あるいはその両方であれ、その土台となるソフトウエアやユーザー・インターフェースをＳＯＡによって設計することで、そのアクティビティを事実上、ウェブ・サービスヘと転換できる。
その結果、個々のアクティビティやプロセスを社内で共有したり、その実行をサプライヤーや顧客に委ねたり、あるいは他社に売買したり、さらにはＩＴシステムの更新やメインテナンスなどもきわめて容易になる。
とはいえ、このような方法にＳＯＡを使うに当たって、やはりボトルネックが存在する。
その一つは世界標準がないことである。
ベンダーや業界が現在使っているＳＯＡのバージョンはバラバラである。
しかし、これはさしたる問題ではない。
というのも、バージョンが違っていても、ほとんどのアクティビティをシステム間でやり取りできるからだ。
さらに言えば、現状を判断する限り、ＳＯＡの標準は早晩統一され、専門家たちで構成された運営組織によって監督されることになるだろう。
「世のなかは、その方向に急速に向かっています」。
このように述べるのは、マイクロソフトのシニア・テクノロジー・アーキテクトであるマーク・バシアックである。
彼は他社に先駆けて、マイクロソフト社内と大口顧客数社で、ＳＯＡプロジェクトを推進してきた第一人者である。
これにおける大きな障害は、おなじみの問題、すなわち経営陣とＩＴ部門の間における温度差である。
ＣＥＯたち他の執行役員は、ＳＯＡのことを、ＣＩＯ（最高ＩＴ責任者）が押しつけようとしている次なる目玉にすぎないとして、この技術も膨大なコストがかかるだけで経済的な利益をもたらすことなく消えていく運命であるうと見なしがちだ。
このような懸念も一因だが、ＳＯＡによって何か実現するのか、ＣＩＯがきっちり理解できていなかったり、うまく説明できなかったりすることも相まって、ほとんどのＣＥＯはＳＯＡの導入を承認するに当たって、「限定的」という条件をＩＴ部門に課している。
つまり、既存のプロセスをサポートしているソフトウエアを改善する、メインテナンス費用を削減するなどである。
実際、事業について再考することなくＳＯＡを導入している企業がほとんどである。
その結果、ＳＯＡの最大の価値である、事業の焦点を絞り込み、効率性が高く、柔軟な組織を構築するチャンスをみすみす見逃している。
我々もお手伝いし、業務プロセスを再設計してからＳＯＡを導入した企業は、重複していたソフトウエアの多くを排除し、手作業だったプロセスを単純化・自動化することで相当規模のコスト削減を果たし、大幅に生産性を改善している。
保険会社のハーバード・ピルグリム・ヘルスケアは、薬剤給付管理や診断など、戦略にほとんど関係しないノンコア・アクティビティを、その処理に優れている第三者企業にアウトソーシングできた。
モトローラの携帯電話事業では、これまで各地の顧客サービス・センターが個々に対応していたプロセスを標準化する方法を開発したことで、ソフトウエアを共有し、運用コストを合計で年数百万ドル削減した。
また、バシアックがマイクロソフトで実施したテスト・ケースでは、ＳＯＡを用いたプロジェクトに125万ドル投資し、ＩＴシステムー式のメインテナンス費用を年300万ドル以上削減することに成功した。
ただし、このような成果も、業務改善手法を変えることで実現される。
一言で言えば、自社を「独自の方法で処理される業務の集合体」から、「標準化したプラグ・アンド・プレー型アクティビティの集合体」へと変革しなければならないのである。
2. ＳＯＡは生産性を高め、組織の焦点を絞る
過去25年間にわたり、ＩＴ、そして業務の設計とその方法が急速に進歩したおかげで、ビジネスのやり方は一変し、生産性は飛躍的に改善された。
また、ＴＱＭ（総合品質管理）やシックス・シグマといった品質改善手法が広く採用されたことで、無駄や欠陥が激減した。
さらに、ＩＴ、リエンジニアリング、その他のプロセス改革手法を利用することによって、一部の作業を廃止し、複数部門で重複していた作業は統合された。
その結果、資材調達、受注処理、生産、サービスの提供、顧客への納品など、部門横断的なプロセスの効率性は一段と高まった。
これら一連のイノベーションは総合的に、数億ドルから、時に数十億ドルのコスト削減を実現し、受注から納品までにかかる時間を50％以上短縮し、品質を大幅に向上させるうえで大きく貢献した。
しかし、リエンジニアリングでは、多くの部分で、再設計されたプロセスとそれをサポートする情報システムは、標準化されたものではなく、各部門のニーズを踏まえてカスタマイズされている。
このように設計されているため、プロセスを共有、統合、変更するのは一筋縄にいかず、しかも高くつくことになる。
たとえば、フェデックスの業務を支えている受注処理プロセスとコンピュータ・システム、あるいはそれらの一部は、〈レゴ〉のように取り外し可能で、そのまま別の企業に接続できるようにはなっていない。
これが、買収した物流会社を統合するうえで足かせとなっている。
独自仕様で設計したため、また最近まで存在していた技術上の制約もあり、プロセスを構成しているアクティビティの数々は、そのプロセスのなかに閉じ込められていた。
したがって、これらアクティビティを他のプロセスと、あるいは事業部門同士で共有することは不可能だった。
その結果、何が起こったか。
大企業のほとんどが、アクティビティの重複、しかも膨大な重複に悩まされている。
そのような大企業では、いまだ何百というノンコア・アクティビティが生み出され、日々処理されているが、これらは理想的にはアウトソーシングすべきものである。
そればかりか、ほとんど戦略に貢献しない重複業務をサポートし、またコア・プロセスを更新するために、膨大な金額をＩＴプロジェクトに費やしている。
例えて言えば、自動車メーカーが、エンジンとそれを支えるオルタネーター（発電装置）、ラジエーター、燃料ポンプ、バッテリーなどの部品のうち、そのどれかがおかしくなった場合に、システム全体を交換しなければならないように設計したら、どうなるだろう。
大半の企業のビジネスプロセスは、まさしくそのような状態にある。
つまり、業務プロセスが一枚岩構造になっているために、それを支えるソフトウエアを部分的に取り替えることが難しい。
全社的なＥＲＰの場合など、とりわけ大変である。
たとえば、料金計算の仕組み一つ変えるだけでも、ばかばかしいほどの時間と金がかかる。
リエンジニアリングが独自の効率的なビジネスプロセスを目指した理由の一つとして、リエンジニアリング革命当時の20年前では、インターネットは今日のものとはまったく異なる存在だったことが挙げられる。
インターネットは現在、ユビキタス・コンピュータ・ネットワークとなり、中小企業であれ大企業であれ、ミネアポリスにあろうがムンバイにあろうが、簡単かつ低コストで、同じソフトウエア・モジュールに接続できる。
しかし当時は、たとえばプライシング、売掛金の回収、マーケティング、営業、その他のケイパビリティを共有するには、それらが自動化されている、少なくともデジタル・ユーザー・インターフェースを備えている必要があり、しかもそのためにプライベート・ネットワークを構築するか、リースするかしかなかった。
ほとんどの企業にとって、それは採算が合わなかった。
もう一つの理由は、およそ10年前までは、ケイパビリティをインターネット上のウェブ・サービスとして共有できるようにコンピュータ・システムを設計する術がなかったことである。
しかし、ＳＯＡの考え方に従えば、個々に独立したコード群----それぞれが、最終成果、性能評価指標、個々のアクティビティと他のサービスとの間のインターフェースが特定されている----によってシステムを設計できる。
これがＳＯＡの本質なのだ。
某メーカーでは、ダイレクト・メールによる販促キャンペーンで、郵便番号を確認するためにウェブ・サービスを導入した。
この場合、「郵便番号が正しいことを確認する」こと、すなわちダイレクト・メールの誤配をなくすことが重要な成果であった。
このウェブ・サービスの性能評価指標は、正しい住所に配達された率（郵便番号の間違いで返送されたダイレクト・メールの数で判断）と、返送されたダイレクト・メールの正しい郵便番号をソフトウエアで特定する頻度であった。
またそのインターフェースには、「顧客住所の更新」「返送された郵送物を処理する」などが表示されていた。
ソフトウエアをこのように設計し、イントラネットやインターネット上で提供すれば、事業部門であろうと、また顧客やサプライヤーであろうと、ＳＯＡを利用している者ならば、だれでも同一のソフトウエアに接続できるか、リモート・アクセスできる。
5つの部門が同じ料金計算手段を使えば、5つのシステムは必要なくなる。
また、ノンコア・アクティビティであれば、アウトソーシングも簡単である。
このような特性ゆえに、ＳＯＡによるソフトウエアは、独白の業務プロセスをサポートするためにカスタマイズされたソフトウエアや既製のＥＲＰよりも優れているといえる。
このＳＯＡ革命によって、世界はどのように変わるであろうか。
それを示す格好の例が、航空会社のチェック・イン・システムである。
標準インターフェースによって、乗客たちは自宅のＰＣからでも、空港の電子キオスクからでも、また情報端末を使う旅客サービス係に頼んでも、チェック・インできる。
インターフェースの裏側で何か起こっていようと、つまりそのケイパビリティを、だれが、どのように提供していようと、満足できる結果が得られる限り、顧客にはまったく関係がない。
自前で処理するよりも、低コストで望むような成果が出せる外部組織があれば、航空会社はそのサービスを購入して、〈レゴ〉のようにくっつければよい。
また、より優れたプロバイダーが登場したら、航空会社は既存のサービスを取り外して、その新しいサービスを付加することができる。
これはＳＦの世界の話ではない。
少なくとも某大手航空会社一社はすでにこれを実践している。
なお正確には、飛行機の搭乗チェック・インといった複雑な機能は、一つのアクティビティやサービスではなく、個別に交換したり、他の機能で代替したりできるアクティビティやサービスを統合したものである。
残念ながら、ＳＯＡによって、生産性がより高く、焦点の絞られた組織を構築したり、業務や技術の重複を排除したりして、大幅なコスト削減を達成している企業は稀である。
なぜか。
それは業務プロセスの基本設計を見直していないからだ。
3. 業務プロセスを成果や目的から見直す
ビジネスプロセスをプラグ・アンド・プレー型に転換するのは、リエンジニアリングより簡単なところもあるが、やっかいなところもある。
前者は、鳴り物入りで始める必要がないことである。
個々のＳＯＡプロジェクトはリエンジニアリング・プロジェクトより規模がはるかに小さく、期間も短く、しかも成果が出るのも早い。
それだけでなく、これまでのビジネスプロセスを緩やかに組み合わせたアクティビティの集含休へと変換するにしても、一枚岩構造のＥＲＰやＣＲＭを総点検したり、分割したりする必要はない。
むしろ、これらのアプリケーションの上にＳＯＡを置けば、それによって独自の言語から解放されて、アクセスが容易になる。
プラグ・アンド・プレーの世界にシフトするに当たり、リエンジニアリングよりも難しいところは、さらに一歩踏み込んだ業務改革、技術変革が必要とされることだ。
具体的には、部門間で業務とソフトウエアを共有し、全社的にいま以上にアウトソーシングを増やし、事業部門は業務の一部を顧客やサプライヤーに移転させる必要がある。
まさしく、まったく新しい方法で業務プロセスの設計に取り組まなければならないのだ。
その第一歩は、業務プロセスを分析する単位を改めることである。
トラブルを解決するに当たって、業務プロセスの問題をどの水準で診断し、事に対処するのかを決める。
19世紀末における分析単位は、労働者のタスクであった。
その効率は、フレデリック・Ｗ・テイラーの時間と作業の研究によって向上した。
それから約60年後、メインフレーム・コンピュータの誕生によって、主たる分析単位は部門に変わった。
その後、1980年代後半から90年代初頭にかけて、低価格化したＰＣと社内ネットワークによって部門間を経済的にも接続できるようになると、組織横断型のプロセスが出来上がった。
インターネットとＳＯＡの時代では、業務を処理する方法は分析単位になりえない。
どのような方法で処理するにせよ、各アクティビティの目的は何か、あるいは望んでいる成果は何かが分析単位となるのである。
たとえば、社内で処理するにせよ、アウトソーシングするにせよ、どのような企業にも給与計算とその支払いというプロセスがある。
その目的は言うまでもなく、社員たちに給料を支払うことである。
そのほか、どの企業にも共通しているアクティビティをさらに挙げると、受注の把握、供給の確保、需要予測、補充計画の立案などがある。
俯瞰してみると、典型的な大企業の各業務プロセスは、5～7つの分野、20～40のアクティビテイ、150～350のケイパビリティ、1000以上のサブ・ケイパビリティから成り立っている。
作業や技術の重複を特定する際にいちばんやっかいなのは、一企業内でも同じアクティビティや似通ったアクティビティに別々の名前がつけられていることである。
しかし、成果あるいは目的という切り口で業務プロセスを定義すれば、この問題の解決策になる。
その結果、経営者、業務プロセスの設計者や技術者は、社内の各部門、顧客、サプライヤーにおいて重複している作業、すなわち業務プロセスとそれをサポートする技術を客観的に判断できる。
たとえばアクティビティのうち、戦略的であり、かつ競争優位をもたらすために社内に残すべきものはどれか、外販可能なサービスはどれか、アウトソーシングすべきなのはどれか、社内に残すことを決定したもののなかで強化すべきものはどれかを判断できる。
このように根源的な視点に立って、初めて業務プロセスとそれをサポートする技術を改善するうえでの課題に優先順序をつけられる。
この方法はきわめて単純明快である。我々はそれを「ビジネス・ケイパビリティ分析」と称している。
4. ビジネス・ケイパピリティ分析のステップ
最初のステップは、事業内のアクティビティ、ケイパビリティ、サブ・ケイパビリティを表にまとめることである。
そして、各分野の担当者たちに協力を仰ぎ、成果あるいは目的という視点から各業務プロセスを再定義する。
ただしこれは、「言うは易く行うは難し」である。
彼ら彼女らは、自分が何を処理しているのか（たとえば「期限までにお支払いいただくように、お客様に請求書を送付します」など）、どのように処理しているのか（たとえば「お客様からのご注文と請求書を照合します。
そして、お客様にお電話して、請求書をどなた様宛てにお送りすればよいか、どのようにお送りすればよいかを尋ねます。
支払期限が来たら、お支払いの手続きを済まされたかどうかを確認します」など）と、ふだんから表現しているからである。
つまり、彼ら彼女らにすれば、成果や目的、たとえば「顧客に請求書を送る」とか「料金を徴収する」という視点は目新しいのである。
次のステップは、重要なものも含めて、ほとんどのアクティビティを支えるのに不可欠なケイパビリティを特定することである。
たとえば、ある金融サービス会社のマネジャーたちは、「需要の創造」という分野において、次の3つのアクティビティ、
「パートナーとの関係を管理する」
「商品とサービスのマーケティングを展開する」
「商品とサービスを販売する」
を挙げた。
そこで我々は、どのようなケイパビリティがこれらのアクティビティを支えているのかについて尋ねた。
そして、商品とサービスを販売するというアクティビティでは、「注文の管理」「販売の管理」「即座に受注処理した売上げの管理」「商品価格の設定」「契約の管理」「見込み客の絞り込み」「ビジネス・インテリジェンスの実行」の七つのケイパビリティが挙げられた。
以上のように、ケイパビリティとサブ・ケイパビリティを定義するのには、同社全体で約3週間かかった。
担当業務のアクティビティとその処理に関わるケイパビリティを表にまとめたら、次のステップは、
成功のカギを握るアクティビティを特定すること、
そしてそれらのアクティビティの健全性について評価することである。
収益を生み出す組織能力を左右するドライバーは何かについて、経営陣が正しく理解していれば、成功のカギを握るアクティビティを特定する作業に要する時間は2～4週間程度である。
このドライバーについて意見が一致した場合でも、職能部門の責任者、顧客接点をあずかる部門の管理職たちやスタッフといった社員だけでなく、顧客、パートナー、サプライヤーにも経営陣の見解を投げかけ、その反応を探ってみるのはとても有意義である。
このアプローチは、これまで広く採用されてきた業務改善手法とは大きく異なる。
そのため、まず狭い範囲、せいぜいある事業分野における1つないしは2つのケイパビリティから始めることで、中心的な役割を果たさなければならない職能部門の責任者を慣らしていくことをお勤めする。
こうすることで、従来のマインドセットを変えて、どのシステムをＳＯＡで再構築すべきなのか、どのシステムはそうすべきでないのかを考えるきっかけとなり、その後に訪れる組織変革の規模を理解するうえでも投に立つ。
その際、フルタイムで働く数人の担当者が不可欠だが、この最初の作業によって、通常6～10週間のうちに大きな改善機会を特定できる。
そのビジネスプロセスにおいて最も重要なのはどのアクティビティか、アクティビティを支えるケイパビリティのなかで改善すべきものはどれか、ウェブ・サービスに移行すべきものはどれかを判断する基準は、以下のように大きく3つある。
① 事業価値
そのアクティビティ、あるいはそれを処理するうえで必要なケイパビリティは、他社との差別化を生み出し、顧客が製品を購入し、ロイヤル・カスタマーであり続けるかどうかに大きく影響を及ぼすものか。
また、製造コスト、品質、上市までの時間などの業績評価指標を左右するものか。
② 現在のパフォーマンス
アクティビティを支えるケイパビリティは、自社のニーズに照らして、また競合他社と比較して、優秀か、あるいは劣っているか、一貫性があるか。
要求水準まで高めるには、どれくらいの投資が必要か。またパフォーマンスが向上すれば、その投資は正当化できるか。
③ 予測可能性
コスト、所要時間、質などの面から見て、アクティビティの成果は予測可能かどうか。
この質問への答えはきわめて重要だ。
なぜなら、予測が難しい場合、アクティビティ、あるいは少なくともそのユーザー・インターフェースは自動化が困難だからである。
ＳＯＡの考え方に従って自動化できなければ、他部門との共有、顧客やサプライヤーヘの委託や移転は困難であろう。
ここで重要な点は、予測が難しいアクティビティも存在することである。
たとえばアマゾン・ドットコムのようなオンライン企業なら、顧客の注文というアクティビティは予測しやすい。
顧客がオンラインで注文し、氏名、住所、選んだ商品、クレジット・カード番号などの必要情報を入力した時点で、アマゾンにはこの注文が確実なものであるとわかる。
一方、コンサルティング会社のような企業は、その提案にどれくらいのクライアントが賛同するのか、クライアントが提案どおりの内容を望んでいるのかを正確に把握しようとしても、それは一筋縄にいかない。
以上のようにビジネス・ケイパビリティ分析を終えたならば、その結果を用いて、ヒート・マップを作成する。
これはアクティビティすべてを並べて、重要なもの、ケイパビリティを改善すべきものを特定するチャートである。
言うまでもなく、まず最初に取り組むべきは、パフォーマンスは劣っているが、事業価値の高いケイパビリティである（図表「最優先課題を特定する」を参照）。
----------------------------------------------------
図表 最優先課題を特定する
このヒート･マップは､ある企業が｢需要に対応｣するうえでの諸活動について単純化したものだが､5つのアクティビティ､すなわち｢顧客サポートの管理｣｢生産計画｣｢調達]｢生産計画｣｢出荷｣とそれに関連する個々のケイパビリティを示している。
各マスの白の帯は事業価値(高い､中程度､低い)を､マスの色は現在のパフォーマンスを示している｡
事業価値は高いが､パフォーマンスの面で要注意の要素は､どれも改善活動において最優先すべきものである｡なお､どのアクティビティがウェブ･サービスに置き換えられるのかに関する分析は省略した。
------------------------------------------------------
年商数10億ドルのアメリカの某流通会社では、業務プロセスの一部について小規模な範囲で実験的にケイパビリティ分析を実施した後、全社的なヒート・マップを作成することを決定した。
特に知りたかったことは、「小売業者と消費者の満足度を大幅に改善する」という最大手メーカーからの指示を実行するには、どのケイパビリティが重要なのかであった。
この分析によって、同社の各業務プロセスは、約20のアクティビティと140のケイパビリティに分類された。
各分野の責任者たちに、事業価値、パフォーマンス、予測可能性について尋ねた後、改善すべき第一候補、すなわち事業価値が最も高く、成果が予測可能であり、パフォーマンスが最も劣っていたものとして、3つのアクティビティと14のケイパビリティが特定された。
とはいえ一度に取り組むには、14のケイパビリティというのは多すぎる。
そこで、小売業者たちにどれを優先すべきか、質問することにした。
その結果、次の3つのケイパビリティが浮かび上がった。
・ずさんな受注処理を改善し、適切な商品を、適切な小売業者に、適切なタイミングで納入すること
・小売業者に十分なマーケティング資料を提供して、同社の付属品を購入するように消費者に働きかけてもらうこと
・商品の売上げをよりきめ細かく追跡し、小売業者が売上げの芳しくない製品を素早く陳列棚から外せるようにすること
この時点で、これら3つのアクティビティに関わる人材、プロセス、ＩＴを詳しく分析した。
受注処理を改善するための解決策の一部は、既存の技術を活用するために小売業者に研修を実施することだった。
というのも、商品売上げを追跡するという課題への解答は「自動化」であったからだ。
導き出された解決策のすべてが、新しいものとは限らなかった。
たとえば、一部のマネジャーたちは、同社に製品情報ソフトウエアをインストールしてマーケティング資料の管理と配布を支援するよう以前から働きかけていた。
ところが、ビジネス・ケイパビリティ分析が実行されるまでは、投資対効果から判断する限り、この課題を推し進めるにも、説得力に欠けると思われていたのだった。
これら3つのケイパビリティに取り組んだ後、この流通会社は残りの11のケイパビリティに着手した。
全社的な改善プログラムはいまも進行中であるが、顧客満足度はすでに大幅に改善している。
この事例における教訓の一つは、ヒート・マップは優先事項を特定することに限定して使用すべきツールであるということだ。
当該事業のアクティビティすべてを俯瞰できるため、社内の全管理職が改善プログラムの優先事項について合意するうえでは投に立つが、一度に取り組めるケイパビリティの数
については、真剣に検討しなければならない。
さもないと、知らぬ間に方向性を見失ってしまう。
第二の教訓は、自動化は、ＳＯＡの導入も含めて、目的達成の手段であり、それ自体は目的ではないということである。
注目すべきは、この流通会社が何を自動化するのか、そして何にＳＯＡを適用するのかを決めたのは、その改善が事業目標を達成するうえでのカギを握るケイパビリティを特定した後であった点である。
5. 新たな業務プロセスを設計・構築する
ビジネス・アクティビティのヒート・マップを作成したら、新たな業務プロセスを設計するための情報の大半、あるいはそのほとんどが整ったことになる。
しかしここでもう一歩踏み込む必要がある。
たとえば、二つの分野におけるアクティビティは一見同じようだが、はたして本当にそうなのかについて確認する。
標準プロセスがすでに存在しているかどうかをチェックする。
あるいは複数のアクティビティがどのように絡み合っているか、あるいはそれぞれ独立しているのかについて把握する。
全アクティビティについて正確な姿がわかったと確信できたならば、以下のどのカテゴリーに該当するのか、各アクティビティを分類する。
① 主要（プライマリー）： 社内に残すべきアクティビティと、業務プロセスと技術を改善するために最優先すべきアクティビティ
② 共有： 他の部門と共有できるアクティビティ
③ 移転： 顧客、サプライヤー、専門会社に委託できるアクティビティ
④ 自動化： ウェブ・サービスで代替できるように、そのケイパビリティ、あるいは少なくともそのユーザー・インターフェースを自動化できるアクティビティ
一般的に、アクティビティの20％ は主要、25～50％は共有あるいは移転できる。
あるメーカーのＣＩＯがこの分類を試みたところ、当初はマーケティング・データ・システムとデータの定期購入が重複しているのは2部門だけと思っていたが、実に12部門にわたっていることが判明した。
このメーカーでは、ＳＯＡによるシステムによって、12部門すべてで共有できるように統合した。
その結果、システム・コストとデータの定期購入予算を合わせて4000万ドル削減し、これら12のシステムをサポートしていたスタッフ70人のうち63人が別の仕事に当たることになった。
また、以前はシステムを購入できなかった部門もこの新規システムにアクセスできるようになった。
ハーバード・ピルブリムは2000年、ビジネス・ケイパビリティ分析を実施した。
その結果、当時ＣＥＯに就任したばかりのチャールズ・ベイカーは、業務の40％は処理能力が勝っている外部企業に移転できると認識した。
たとえばヒート・マップを見ると、同社の最重要ケイパビリティの一つは、糖尿病や心臓疾患といった慢性的な病気の初期段階にある契約者、あるいは発病リスクの高い契約者を特定することだった。
早期発見できれば、症状が深刻化する前に、契約者たちを予防医療や疾病管理プログラムに申し込ませることができる。
ただしそのためには、高度なデータ・マイニング技術とデータ分析能力が不可欠であった。
そこでハーバード・ピルグリムは、自分たちにはこのようなスキルと専門知識が欠けていることを自覚し、これらのアクティビティを社外の専門家に委託することを決定した。
そして最終的に、競争優位をもたらすケイパビリティを改善することに意識と資源を集中させるという決断を下した。
具体的には、顧客サービス、新商品の開発、健康保険の保険料設定（保険数理サービス）、医者と契約を交して、自社のネットワークに参加してもらうこと、大規模団体への保険販売、個々の保険契約者へのダイレクト・マーケティングである。
その一方、薬剤給付管理、いくつかの疾患管理プログラム、問題行動の管理、保険金請求処理は、外部企業に委託した。
ビジネス・ケイパビリティ分析の結果を活用したことで、10社ほどあった請負業者に、質、コスト、量、リード・タイムの面で何を期待しているのかを正確かつ詳細に示すことができた。
そればかりか、これらがどれくらい達成できているのか、細かく追跡することもできた。
また、3つに分割されていた財務部門とそのシステムは続合され、1つにまとめられた。
ビジネス・ケイパビリティ分析のおかげもあって、ハーバード・ピルグリムの業務合理化は大きな成果を上げている。
2000年当時、この保険会社は倒産の危機に瀕していたが、いまではみごと黒字転換し、一定規模のロイヤル・カスタマーを抱え、サービスの質と顧客満足度で何度も最優秀賞を受賞したり、高い評価を獲得したりしている。
すでに明らかだと思うが、新たな業務モデルを構築するための第一歩は、ＳＯＡソフトウエアを構築したり購入したりすることではない。
それは最後のステップ、つまり自社の主要なアクティビティを特定し、自動化できるケイパビリティやユーザー・インターフェースはどれかを判断した後にやるべきことだ。
言うまでもなく、一つとして同じ企業は存在しないが、自動化の判断を最後まで待つことで、ＩＴコストを年20％削減した企業を、我々は何社も知っている。
ただし、成果が予測可能なアクティビティを特定したならば、ＳＯＡの導入に向けて積極的に行動すべきである。
大型アプリケーションと同じく、インストールには金がかかるが、投資するだけの価値はある。
ＳＯＡソフトウエアは、通常、他のソフトウエアにかかる時間の半分でアップデートできる。
何と言っても、さまざまなアクティビティをサポートする各種ソフトを総点検することなく、新しいモジュールを接続するだけでよいからだ。
6. ＳＯＡ導入におけるボトルネック
ガートナーの報告書によれば、2007年に構築されたミッション・クリティカルなシステム（24時間365日、正常に機能することを要求されるシステム）の半分以上は、ＳＯＡによるものだという。
またその比率は、2010年までには80％を上回るとも予測している。
とはいえ、そう簡単にＳＯＡの世界に入ることはできない。
この新しいモデルを導入するには、業務プロセスの改善とその技術に携わってきた人たちのマインドセットを転換しなければならないからだ。
それは、19世紀における建築の2大イノベーション、すなわち高強度鋼とエレベーターとによって、1800年代中盤の建築家とエンジニアが頭を切り替えなければならなかった状況と似ている。
この偉大な発明ゆえに、高層ビルが建てられるようになったことを認識するのに、実に30年かかっている。
同じように、革新的なネットワーキング技術およびソフトウエア開発手法は、業務プロセス設計革命の幕開けとなろう。
ところが、20世紀の業務プロセスがいまなお幅を利かせている。
すなわち、アクティビティと業務プロセスを自社固有のカスタマイズした方法で定義し、ソフトウエアも、その一部を交換しなければならない場合はシステム全体を捨てざるをえなくなるような方法で構築している。
経営者やビジネス・リーダーたちも、この変革の足かせになっている。
彼ら彼女らは、ＳＯＡなどよくわからない技術の話であり、自分には関係ないと決め込んでいる。それは、とんでもないことだ。
どのケイパビリティを廃止し、どのケイパビリティを顧客やサプライヤーに移転する、あるいはアウトソーシングするのかに関する判断を、業務部門だけに任せてはならない。
我々の経験から申し上げると、事業部門の責任者とその担当役員は、自分たちのアクティビティをなかなか手放さない。
つまり、その重要性を過大評価しており、それを共有したりアウトソーシングしたりすると、自部門の業績にマイナスの影響が及ぶと危惧しているのだ。
したがってＣＥＯは、どの業務を社内に残し、どの重複部分を解消するのか、またどれをアウトソーシングするかについて積極的に関与し、決定を下さなければならない。
ただしもちろん、プロセスと技術の細かい部分に首を突っ込む必要はなく、またそうすべきでもないが、それでもＣＥＯは「チーフ・ビジネス・アーキテクト」としての役割を果たさなければならない。
コンピュータ・ネットワークとソフトウエアを組み合わせる新手法の登場によって、瞬時にモジュールを世界中に流通できるようになった。
これは、効率的かつ柔軟なオペレーションを構築する新たなツールである。
他社に先駆けて、プラグ・アンド・プレー型ビジネスプロセスヘの転換に取り組めば、企業全体の生産性を大きく向上させる足がかりとなろう。
（HBR2008年6月号より）
edited by ©M-SAKU Networks 2008