|
ITIL サービスデザイン − サービスデザイン概要１ Vol.004 - 2008年11月25日（月2回発行） 前回までのお話は、ITIL v2の「サービスサポート」と「サービスデリバリ」に含まれていた「1つの機能と10個のプロセス」が ITIL v3の何処にどのように散らばったのかと言うことを中心に、ITIL v3 の５冊の書籍のうち４冊について簡単な紹介をいたしました。「継続的サービス改善」に関してはまったく触れていませんが、これはまさに「読んで字のごとく」の本なので、ここでは割愛します。 さて、最初に取り上げるのは「サービスデザイン」です。ITIL v3のセミナーが行われるときや参考書の解説などは、通常「サービスストラテジ」から取り上げています。本来であれば、ライフサイクルの出発点であり、 ITサービスに関するすべての土台となる「戦略を計画する」フェーズである「サービスストラテジ」を最初に解説するのは理にかなったことだといえるでしょう。しかし、このコラムではあえて「サービスストラテジ」を最後に取り上げるつもりです。 「サービスストラテジ」は ITIL v3 の中心を担う書籍です。コラムの1回目からお話ししていることですが、「サービスストラテジ」は他の4つの書籍の根拠となる「計画」部分を中心に取り上げて説明しています（図１）。ITIL v3 を実際に企業に導入する際には、ライフサイクルに則って「サービスストラテジ」から着手するのが良い手法だといえるかもしれません。 図1：ITIL v3 構成図 言い換えれば、「サービスストラテジ」は ITIL 全体に深く関わる要素です。ITIL v3 において、「なぜ企業は ITIL v3 を導入するとよいのか」を説明する根拠となる部分であるともいえるでしょう。そのため、ITIL v3 を正しく理解するためにはあえて最後に説明したほうがいいのではないか、と考えたのです。特にこのコラムの読者は ITIL v2 をある程度理解しておられる方が多いと予想できます。ITIL v2 をご存知の方に対しては、ライフサイクルの中でもまずなじみの深い「設計（サービスデザイン）」や「運用（サービスオペレーション）」などの部分を先に説明して、理解が深まったところで ITIL v3 の全体の意義である「計画（サービスストラテジ）」を説明したほうが理解が深まるのではないか、と考えたのです。 また、ITIL はあくまでもフレームワークであり、グッド・プラクティスです。標準や規格と呼ばれるものではありません。導入しやすい、効果が期待できるようなところから導入すればいいのです。イイトコドリをすればいいのです。導入する際だけでなく勉強する際も、勉強しやすい、わかりやすいところから始めればいいのです。 とはいえ、「サービスストラテジ」は全体に関わる概念なので、他の４冊の書籍を解説する際にちょくちょく登場します。全然触れないでいるわけにもいきません。そこで少しだけ、（あまりIT的ではない）具体的な例で先に説明しておきます。
サービスの具体的な内容を決めるのは「サービスデザイン」の仕事です。サービスを実際に提供するのは「サービストランジション」の仕事です。そして、日々のサービス提供をサポートし、万が一うまくいかなかったときに対応するのは「サービスオペレーション」の仕事です。「サービスストラテジ」は、これらのサービス提供の大元となる、サービスのコア・コンセプトを決定する段階だと思っていただければいいかと思います。 さて、今回からしばらくは「サービスデザイン」についてお話を進めてまいります。 まずは「サービスデザイン」とは何か？といった、大枠の部分から入っていきましょう。
では、どのようなIT機器を準備するのがよいでしょうか。例えばデスクトップPCはお客様先に持参することが困難です。社内の顧客データベースに接続するのですから、ネットワークに接続する必要があるでしょう。電子メールソフトやWebブラウザ、オフィススイートといったソフトウェアも必要になるでしょう。また、IT機器が故障した場合に何時間以内に復旧してほしいか、といった隠れたニーズにも働きかける必要が出てくるでしょう。 営業マンが実際に持っているのはビジネスニーズです。IT機器に求めるのはこれらのビジネスニーズを実現するサービスです。彼らは「Core 2 Duo の CPU を搭載したPCが欲しい」といったニーズを持っているわけではありません。ビジネスをストレスなく遂行させたい、というニーズを持っているのです。 一方で、ITが提供するのはサービス（ITサービス）です。顧客管理や売上管理をするためのデータベースサーバ、社内LAN、インターネット接続、社外からの VPN接続、必要かつ十分な性能のPCやソフトウェア、およびそれらをサポートするための体制といったものを ITサービスとして提供します。つまり、利用者が持っているビジネスニーズを、それを実現するためのITサービスに変換するという作業が必要です。例えば
という IT機器に求めるサービスを
といった具体的な ITサービスに変換する必要があるわけです。このように、ビジネスニーズをITサービスに変換する役割を果たすのが「サービスデザイン」である、というわけです。（ちなみに ITIL 書籍には「ビジネスニーズ」という用語は登場しません。これはよりわかりやすさを重視して登場させた用語です。）ビジネスニーズを満たすためにどのようなITサービスを提供するか、ということをまとめたものがサービスカタログであり、サービスカタログに記載されているITサービスをどのように、どの程度提供するかを取り決めたものがサービスレベルです。IT側は、ビジネスニーズにどの程度応えるか（または応えないか）ということを検討し、ビジネス側と合意した上でサービスレベルを決定します。この中にはIT機器の可用性の目標値、メンテナンスの頻度や故障した時の対応といった内容も含まれます。さらに、合意した内容でサービスが提供されているかどうか管理するということも行います。そして合意したサービスレベルを根拠にして、そのサービスレベルを満たすようなキャパシティや可用性などを具体的に検討していきます。こういった一連の活動が「サービスデザイン」に含まれるわけです。ITサービスを提供するために管理する項目ハードウェアやソフトウェアのみならず、企業が取り扱う情報や人材も含みます。そう考えると、ITIL v2 の「サービスデリバリ」の考え方にそっくりだ、と思われるかもしれません。第3回目のコラムでお話ししたとおり、事実 ITIL v2での「サービスデリバリ」にあったプロセスのうち
が「サービスデザイン」に含まれています。これら以外にさらに追加されたプロセスもあります。プロセス以外にも、様々な考え方が述べられています。
次回以降では、この「サービスデザイン」をさらに詳しく説明していきます。どうぞお楽しみに。 |
