ITIL サービスデザイン − サプライヤ管理

Vol.015 - 2009年07月06日

毎日、蒸し暑い日が続きますね（この原稿を書いているのは、2009年6月です）。みなさんいかがお過ごしでしょうか。さて、今回で「サービスデザイン」のお話は終了です。最後に取り上げるのは「サプライヤ管理」です。

「サプライヤ」と言う言葉は、ITIL v2の時から登場しています。ITIL v2 では、顧客にITサービスを直接提供する組織のことをサービス・プロバイダと呼び、サービス・プロバイダを支援する外部のベンダのことをサプライヤと呼んでいました。IT に直接関係ない例になりますが、例えばレストランにおいては、お客様にサービスを提供する給仕係や料理人などがサービス・プロバイダであり、そのサービス・プロバイダを社外で支援する魚屋、肉屋、八百屋、酒屋といった組織がサプライヤ、といったところでしょうか。もうちょっと IT 寄りの例では、ユーザを直接支援する社内の情報システム部がサービス・プロバイダであり、そのサービス・プロバイダを社外から支援する業者、例えばインターネット接続事業者や社外のデータセンタ、ソフトウェア開発業者などをサプライヤと呼んでいます。

ただ、一般的にはそうした社外の業者のことを「プロバイダ」と呼ぶことが多いので注意が必要です。「インターネット・サービス・プロバイダ（ISP）」や「アプリケーション・サービス・プロバイダ（ASP）」という用語は有名ですね。ただ、ITIL では用語の使い方が異なりますので、十分注意してください。

さて、ITIL v2 からも UC（Underpinning Contract）を締結するという内容を中心に「サプライヤを管理する」という概念はあったのですが、いわゆる赤本、青本にはそこまで言及されていませんでした。それに対し、ITIL v3 ではひとつの独立したプロセスとして扱われています。決して新しい考え方だというわけではないのですが、ちゃんと日の目を見るようになった、ということですね。

そうそう、大事なことをふたつ。
ITIL v3 では、UC の日本語訳が「請負契約」から「外部委託契約」に変わりました。法律的には「請負契約」とは、成果物に責任を負うタイプの契約のことを指します。ITの世界では外部業者がサービス内容に責任を持つことはあっても、成果物を提供するとは限りません。ISP なんてのはその好例です。なので、「外部委託契約」のほうがより現実的な訳だと言えるでしょう。

もうひとつ。ある組織が、その組織の中にサービス・プロバイダを持たず、組織内のITサービスの管理をまるごと社外にアウトソーシングしている場合があります。その場合のアウトソーシング先は「サービス・プロバイダ」です。正確には「タイプ III サービス・プロバイダ」と言います。「サプライヤ」はあくまでも、サービス・プロバイダが顧客に対して IT サービスを提供するために必要となる道具（ハードウェアやソフトウェア）またはサービスを供給するサードパーティのことを指します。

さて、組織の顧客に対して ITサービスを提供する立場のサービス・プロバイダは、ビジネスとITのふたつの側面において、顧客とユーザの両方の要求を満足するように IT サービスを管理する責任があります。その責任範疇は SLA に明記されることになります。ここの詳細は「サービスレベル管理」で取り上げましたね。しかし、通常その責任をすべてサービス・プロバイダが負うわけにはいきません。インターネットに接続する、データセンターにサーバを置いてもらう、リース業者からクライアントPCをリースしてもらうなど、何らかの形で必ずサプライヤの力を借りることになります。サービス・プロバイダとサプライヤとの間で契約（UC）を交わすことになるわけですが、この UC の内容はもちろん SLA との整合性をとらなければなりません。つまりサプライヤが提供する IT サービスの内容は、サービス・プロバイダが顧客と取り交わした SLA の要件を満たすように、なおかつコストが妥当な金額になるように必要かつ十分なコストとのバランスを取るようにった上でり、SLAの内容とサプライヤとの契約内容に矛盾や不備が生じないように心がけます。

さて、サプライヤ管理の目的をはっきりさせておきましょう。サプライヤ管理の目的は、サービス・プロバイダとサプライヤとの間の契約が事業ニーズを満たすこと（すなわち SLA に準拠すること）と、すべてのサプライヤが契約上の義務を果たすようにすることです。具体的には、次の３つの側面に注目します。

１．サプライヤが提供するサービスが、ITサービスのSLAで合意した目標値をちゃんと満たしているかどうか
２．サプライヤが提供しているサービスが、事業の期待をサポートしているか
３．サプライヤに対して支払われる費用が、提供されるサービスの効果と比較して妥当かどうか

こう書くと、サプライヤに対してとっても偉そうに接するプロセスであるかのように見えます。しかし実際には、顧客が満足するようなサービスをサービス・プロバイダが提供するためには、プライヤが提供するサービスは不可欠です。サービス・プロバイダとサプライヤは使う・使われるの関係というよりも、顧客に対するサービス品質を保証するために効率的な協働をする間柄である、と考えるほうが妥当でしょう。

これらの項目を、もう少し具体的に見てみましょう。サプライヤ管理プロセスの主な達成目標は次の通りです。

サプライヤおよびサプライヤとの契約から、投資に見合う価値を取得する
サプライヤとの外部委託契約および合意が、ビジネス・ニーズと整合できていることを確実にすると共に、SLA の合意済み目標値をサポートするように調整する
サプライヤとの関係を有効に保つ
サプライヤのパフォーマンスを管理する
契約についてサプライヤと交渉し、合意し、そのライフサイクルを通して管理する
サプライヤ管理を支えるサプライヤ契約データベース（SCD）を維持管理する

例えば、どのサプライヤと契約するのかとか、新たに契約を結ぶのか、既存の契約を更新するのか、既存の契約を破棄して新しい契約に変えるのか、そのサプライヤとの契約をやめてしまうのか・・・といったようなことから、現在サプライヤに支払っている金額はサービス品質やサービス内容からいって妥当なのか、というようなことを考えるのも、このサプライヤ管理の活動の範疇、ということになるのです。

実際には、組織の規模が大きくなればなるほど、関係しているサプライヤの数も増えるでしょうし、そのサプライヤが提供しているサービスにひもづく事業との関係も複雑になっていきます。そのためサプライヤ管理では、管理のための専用の「サプライヤ契約データベース（SCD）」を構築することを推奨しています。SCDは、各サプライヤが提供するサービスや製品の種類、詳細、その他関連するCI情報や、さらにはサプライヤとの契約の詳細の記録を含むことが理想的です。というのも、サプライヤが提供するサービスは、サービス・ポートフォリオやサービス・カタログにとって主要な要素であることが多いからです。このほかにもSCDに含まれるべき情報として、サプライヤ管理の手順と活動、参考情報なども登録されます。

サプライヤ管理プロセスの活動の主だったものは、次の通りです（図１）。

図１：サプライヤ管理プロセス

ビジネス・ニーズの識別とサプライヤの戦略、方針
新しいサプライヤと契約の評価と調達
新しいサプライヤと契約の確立
サプライヤおよび契約の管理とパフォーマンス
サプライヤと契約のカテゴリ化
サプライヤ契約データベース（SCD）の維持管理
契約の更新、終了の管理

サプライヤ管理プロセスの活動の中に「サプライヤのカテゴリ化」と言うものがあります。これは各サプライヤを、重要度の低いサプライヤと重要度の高いサプライヤに分けて管理することをいいます。この重要度とはもちろん業務の重要度と密接に関係します。つまり、サプライヤが提供するITサービスが何らかの理由で停止した場合、企業活動を行ううえで致命的であるのか、そうでないのかといったといった「重要度」で分類するのです。サプライヤを重要度でカテゴリ化した上で、それぞれのサプライヤに対して管理時間などに差をつけます。重要度が高いサプライヤほど、管理に多くの時間と労力をかけることが大切です。

サービス・プロバイダがサプライヤの重要度を元にカテゴリ化した例が図２です。これは、サプライヤを利用することによって得られる価値の高さと重要性の高さを元にサプライヤをカテゴリ化しています。これはあくまでも例えですが、プリンタを保守するサプライヤは、そのサービスの価値はさほど高くないものの、実際にプリンタが使えなくなっては困るので重要度は高いと言えるかもしれませんし、従業員が利用するPCをリースしてくれるサプライヤは、PCを従業員の数だけ購入することを考えれば価値の高いサービスを提供していると考えることができますが、その一方でPCが故障したり、リース切れを迎えたりしない限り頻繁に出入りするわけではないので、その重要度は低いと言えるでしょう。カテゴリ化を行った後、サプライヤとの関係を管理するために費やす時間と労力の量をカテゴリに見合うように設定します。

さて、改めて、図２を見てみましょう。ここではサプライヤを「戦略的」「戦術的」「運用上」「コモディティ」と4つのカテゴリに分けています。この違いについて軽く触れておきましょう。

図２：サプライヤのカテゴリ化

戦略的：
長期的な計画を促進するために、戦略の機密情報を共有する上級マネージャが関与する重要な「パートナー」関係のカテゴリです。たとえば、世界規模でネットワーク・サービスとサポートを供給するネットワーク・サービス・プロバイダがここに含まれます。
戦術的：
顕著な商業活動および事業とのやり取りが関与し、中級マネジメントによって管理されるカテゴリです。たとえば、サーバのハードウェア故障の解決を提供するハードウェア保守組織がここに含まれます。
運用上：
運用上の製品やそれらに伴ったサービスを提供するだけのサプライヤに対するカテゴリです。運用担当者によって管理されます。たとえば、低インパクトのウェブサイトなどのホスティング・スペースを提供するホスティング・サービス・プロバイダがここに含まれます。
コモディティ：
比較的容易に代替ソーシングやすい、価値が低く用意に入手できる製品とサービスを提供するサプライヤに対するカテゴリです。たとえば、紙やプリンタトナーのサプライヤが含まれます。

全体を通して重要なことは、サプライヤをただ漫然と使うだけとか、サプライヤをただの外注業者だと認識してこき使ったり、無理難題を押し付けたりしてはいけない、ということです。サービス・プロバイダはサプライヤを顧客にサービスを提供するための重要なパートナであると認識し、そのパートナの重要度に応じて、きちんと時間をかけ、ポリシーをもって管理する必要があるということです。さらには、サプライヤが提供するサービスがちゃんと顧客の事業を支援しているかどうか、ちゃんとした基準を持って管理する必要があるということも示しています。その基準とはもちろん、サービス・プロバイダが顧客と交わす SLA です。

以上でサプライヤ管理プロセスのお話は終わりです。また、「サービスデザイン」のご紹介もすべて終了したことになります。次回からは実際に ITサービスを事業環境に展開する「サービストランジション」のお話に移ってまいります。