itilv3 intermediate -...

Introduction, Service Portfolio Management, Service Catalogue Management, Service Lev-el Management, Demand Management, Sup-plier Management, Financial Management, Business Relationship Manager, Roles and Re-sponsibilities, Technology and Implementation Considerations, Exam Preparation Guide, In-troduction, Service Portfolio Management, Ser-vice Catalogue Management, Service Level Management, Demand Management, Sup-plier Management, Financial Management, Business Relationship Manager, Roles and Re-sponsibilities, Technology and Implementation Considerations, Exam Preparation Guide, In-troduction, Service Portfolio Management, Ser-vice Catalogue Management, Service Level Management, Demand Management, Sup-plier Management, Financial Management, Business Relationship Manager, Roles and Responsibilities, Technology and Implementa-tion Considerations, Exam Preparation Guide,

Service Offerings and Agreements

®

サービス提案および合意

受講

者用

ガイ

ド　

バー

ジョ

ン 2

.0

受講者用参考資料

ITILv3Intermediate

The information contained in this classroom material is subject to change without notice.

This material contains proprietary information that is protected by copyright.

No part of this material may be photocopied, reproduced, or translated to another language

without the prior consent of ITpreneurs Nederland B.V.

© Copyright 2011 by ITpreneurs Nederland B.V. All rights reserved.

ITIL® Qualification Scheme Copyright © 2007 APM Group. All rights reserved.

Glossaries/Acronyms © Crown Copyright Office of Government Commerce.

Reproduced with the permission of the Controller of HMSO and the Office of

Government Commerce.

The language used in this course is US English. Our sources of reference for grammar, syntax, and

mechanics are The Chicago Manual of Style, The American Heritage Dictionary, and the Microsoft Manual

of Style for Technical Publications.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the

Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

ITIL®V3 - Published for the Office of Government Commerce under license from the

Controller of Her Majesty’s Stationery Office © Crown Copyright 2007.

The Swirl logo™ is a Trade Mark of the Office of Government Commerce.

The OGC logo® is a Registered Trade Mark of the Office of Government Commerce.

All content in italics and quotes ©Crown Copyright 2007 Reproduced under licence from OGC.

All infographics © Crown Copyright 2007 Reproduced under licence from OGC, unless otherwise noted.

EXIN, the Examination Institute for Information Science, is a global, independent IT examination provider offering qualification programs for ISO/IEC 20000, ISO/IEC 27000, ITIL®, MOF, ASL, BiSL, TMap® and SCP. It’s EXIN’s mission to improve the quality of the IT sector, the IT professionals and the IT users, by means of independent testing and certification.

目次

i

ユニット 1: はじめに 1

1.1 受講者と講師の紹介 1

1.2 本コースの特徴 2

1.3 コースの学習目標 4

1.4 コースの内容 5

1.5 サービスマネジメントの概念 10

1.6サービスの概念 11

1.7 サービス・ライフサイクル内の機能とプロセス 12

1.8 サービス・ライフサイクル内の役割 14

1.9 サービスマネジメントの事業上の価値 16

1.10 サービス・ライフサイクルのサポート 18

ユニット 2: サービス・ポートフォリオ管理 23

2.1 サービス・ポートフォリオ、およびサービス・カタログとサービス・パイプラインとの関係 23

2.2 サービス・ポートフォリオにおけるサービス・プロバイダのサービスの記述、

およびビジネス・サービスをITサービスに関連付ける方法 30

2.3 サービス・ポートフォリオ管理の方法 37

2.4 グループ／個人演習 44

2.5 模擬試験問題 44

ユニット 3: サービス・カタログ管理 49

3.1 目的、最終目標、達成目標 50

3.2 プロセスの適用範囲 51

3.3 方針、原則、基本概念 52

3.4 サービス・ライフサイクルと事業にとってのサービス・カタログの重要性 54

3.5 ビジネス・サービス・カタログと技術サービス・カタログの違い 58

3.6 サービス・ポートフォリオとのインタフェース 60

3.7 プロセスに関連する主要な測定基準、課題、CSF、リスク 65

3.8 その他のプロセスと機能によるサービス・カタログの利用 67

3.9 サービス・カタログの作成 69


ii

ユニット 4: サービスレベル管理 75

4.1 サービスレベル管理の目的、最終目標、達成目標 76

4.2プロセスの適用範囲 77

4.3SLMの重要性と事業上の価値への貢献 79

4.4 原則と基本概念 80

4.5 主要な活動、手法、技法、サービス・ライフサイクルとの関係 82

4.6 成果物 87

4.7 SLAに照らしたサービス・パフォーマンスのモニタリング 89

4.8 主要な測定基準、課題、CSF、リスク 92

4.9 SLA、OLA、レビュー・ミーティングの内容 98

4.10 他のプロセスおよび機能とのインタフェース 100



ユニット 5: 需要管理 109

5.1 目的と最終目標 109

5.2 基本概念 110

5.3 活動を基準にした需要管理とPBA 112

5.4 サービス・ポートフォリオとのインタフェース 115

5.5 サービスの需要管理 116



ユニット 6: サプライヤ管理 123


6.2プロセスの適用範囲 125

6.3 サプライヤ管理の重要性と事業上の価値への貢献 127

6.4 原則と基本概念 128

6.5 主要な活動、手法、技法、サービス・ライフサイクルとの関係 130

6.6 サプライヤのカテゴリ化およびサプライヤ・データベースの維持管理 143

6.7 プロセスに関連する主要な測定基準、課題、CSF、リスク 147

6.8 インプットとアウトプット 150



iii

ユニット 7: 財務管理 157


7.2 プロセスの適用範囲 159

7.3 サービス査定の概念 161

7.4 サービス・ライフサイクルに対する重要性と事業上の価値への貢献 165

7.5 基本概念 ― 資金調達、会計、課金 168

7.6 ROIとビジネス・ケース 173

7.7 活動、手法、技法、サービス・ライフサイクルとの関係 181

7.8 財務管理プロセスの設計と実施 190



ユニット 8: 事業関係マネージャ 199


8.2 BRMの役割 200



ユニット 9: 役割と責任 213

9.1 サービスの役割と責任の目的と最終目標 213

9.2 サービス・カタログ・マネージャの役割と責任 214

9.3 サービスレベル・マネージャの役割と責任 215

9.4 サプライヤ・マネージャの役割と責任 216



ユニット 10: 技術と導入に関する検討事項 223


10.2 SOAで支援する一般的な技術要件 225

10.3 プロセス導入のための技術とツールの評価基準 230

10.4 プラクティスとプロセス導入に関するグッドプラクティス 235

10.5 プラクティスとプロセスの導入における課題、CSF、リスク 243

10.6 サービスマネジメント技術の計画立案と導入 251



付録 A: ケース・スタディ 257

付録 B: 用語集 273

付録 C: シラバス（講義概要） 305

付録 D: 解答 321

ユニット1はじめに


所要時間 1.5 時間

Student | ITIL v3 Intermediate Certification Level | Introduction

Copyright © 2011, ITpreneurs Nederland B.V. All rights reserved. 1

My N otes

ユニット1：はじめに

概要サービス提供と合意（SOA）は、ITILインターミディエイトケイパビリティ・ストリームに含まれる4つのコースのうちの1つです。SOAコースでは、サービス・ポートフォリオ管理、サービス・カタログ管理、サービスレベル管理（SLM）、需要管理、サプライヤ管理、および財務管理に関連するITILベストプラクティスについて理解し、実施できるようになります。

1.1　受講者と講師の紹介

ほかの受講者やあなたの講師について知りましょう。講師に、ITとITインフラストラクチャ・ライブラリ（ITIL®）に関する経験や経歴について尋ねてみてください。

次のことなどについて自己紹介してください。

あなたの名前と職業 yITにおけるあなたの役割と経歴 yITILにどの程度精通しているか yこの数日間で何を学びたいか y

ITIL v3 Intermediate Certification Level | Service Offerings and Agreements

Copyright © 2011, ITpreneurs Nederland B.V. All rights reserved.2

My N otes

1.2　本コースの特徴

ここで、このコースが対話中心で行われることを強調しておきます。

このコースは、講師がスライドを見せて講義するというような従来の「技術研修」形式で行うものではありません。その代わりに、受講者は多くのディスカッションや演習、および実践的経験の共有によって、学習体験に参加することを求められます。これは受講者が学んだことを確実に自分のものにすること、また、必要に応じて、最終試験に合格したり、新たに得た実践的経験を職場で実践したりすることを目的としています。

講師はこのような導入の時間を取って、受講者に受講者用教材について一通り説明し、情報を見つけることができる場所や、トレーニング・セッションの最も有効な参加方法についても説明します。

受講者用教材は、次の2つの教材で構成されています。

受講者用参考資料：講師が授業で説明する概念が含まれています。受講者はこの受講者用参考資料を、最終試験の準備に向けた毎晩の復習に使用できます。各ユニットの終わりには模擬試験問題があります。これらの問題は、認定試験と同じ形式で作成されています。

これらの問題の解答は、受講者用参考資料の付録Dの「解答」にあります。

受講者用ワークブック：受講者が授業で行う必要のあるすべての演習が含まれています。

このコースでは、さまざまな学習方法を採用しています。それぞれの学習方法は、受講者が教材を学習するだけでなく、その情報を適用できるようになっています。使用するさまざまな技法は次のとおりです。

ブレインストーミング：この学習方法では共同学習を推進します。グループに、分析なしでアイデアを提案し、その後ブレインストーミングをしてから解決策をまとめるよう奨励します。

シナリオ：実際のケースを使用して、ITILフレームワークを適用する状況を説明します。これは、受講者が状況を検討する視点を養い、ITILのどの側面がシナリオのニーズを満たすか選択するのに特に役立ちます。

ティーチバック：同じクラスの受講生に概念を教えるための自習や準備を通して、トピックの理解度を深めます。講師は、ティーチバック・セッションに適切な内容が反映されていることを確認する中心的な役割を担います。

講義：これは従来の学習方法ですが、PowerPointによるプレゼンテーションではなく、講師の手引きを使用して行います。受講者は、講義中は受講者用参考資料を参照することをお勧めします。



My N otes

ディスカッション：講師が問題を提起し、複雑なテーマについて受講者を指導します。ディスカッションは、受講者が複雑なテーマを理解するのに役立ちます。

自習：通常、あるトピックを学習した後で補助教材がある場合に行います。また、受講者の関心を持続させるために、指導技法を多様にするためにも行います。

ラウンドロビン：ディスカッションと似ていますが、ラウンドロビンでは受講者が1人ずつ順番に発言し、それぞれが考えや概念を述べる必要があります。

シンク、ペア、シェア：講師がクラス全体に質問をします。それから受講者がパートナとペアになり、回答を比較したり話し合ったりします。講師は受講者から数名を無作為に選び、話し合いの内容や回答を発言させます。

共通の問題の解決：クラスを2つのグループに分け、各グループで「トピックに関連する」問題を簡単に書き留めます。その後2つのグループ間で、与えられた問題の「解決方法」について質問を出し合います。

これまでの学習の振り返り：クラスで、これまでにファンデーション・コースまたは教材を通して学習したトピックに関して、できるかぎり多くのアイデアやキー・ポイントをリストアップします。



My N otes

1.3　コースの学習目標

このユニットを修了すると、次のようなナレッジとスキルが身に付きます。

プラクティスとしてのサービスマネジメントの重要性と、サー yビスオペレーション（SO）の原則、目的、達成目標を把握できる。サービス提供におけるITIL SOAの重要性を理解できる。 yITIL SOAの全プロセスがサービス・サイクルの他のプロセス yとどのように相互作用するか学習する。ITIL SOAの各プロセスで使用するプロセス、活動、手法、機能 yについて学習する。運用上の卓越性を実現するためにITIL SOAのプロセス、活 y動、および機能を利用する方法がわかる。ITIL SOAの測定方法を説明できる。 yITセキュリティの重要性と、ITIL SOAへのITセキュリティの貢献 yについて説明できる。ITIL SOAを取り巻く技術や導入に関する検討事項を認識でき yる。ITIL SOAに関連する課題、重要成功要因（CSF）、およびリスク yを説明できる。



My N otes

1.4　コースの内容

コースの必須条件：ケイパビリティ・コースでは経験に関して必須条件を設けて yいないが、ITサービスマネジメントにおける職務経験が2～4年あることが望ましい。ライフサイクル・コースでは経験に関して必須条件を設けて yいないが、ITを使いこなす基本的な能力と、IT部門での2年程度の経験があることが望ましい。

試験要件：所要時間：1.5時間。受講者の母語で記述しない場合、30分間 yの延長と辞書の使用が認められる。問題：多肢選択式の問題が8問出題される。各問題には4つの y選択肢があり、それぞれ配点が5点、3点、1点、および0点の不正解となっている。形式：資料の持ち込みは不可。オンラインまたは紙ベースの y試験。合格点：40点中28点（70%） y優秀点：未定 y授業時間：認定教育事業者（ATO）による30時間の正式なトレ yーニングAPMGが推奨する自主学習時間：12時間。演習を行うには、「 yロイヤルのケース・スタディ」を読む必要がある。

受験に役立つヒント：コース教材のシラバスを確認する。 y受験準備として、ITILコア書籍の中の特定の章に絞って学習す yるためにシラバスを利用できる。試験は、ITIL V3のベストプラクティスに関するしっかりとした y中核能力を身に付けているだけでなく、そのナレッジを実際のシナリオに適用できることを確認するように作成されている。質問をよく読む。 y　「～ではない」、「最も適切な」などの語句に注意する。 y提示される具体的な事業状況についてメモを取る。そのシナ yリオから、リストの中の「最も適切な」答えがわかるかもしれない。ITIL理論を用い、提示された情報を考慮することによって、で yきるかぎり不正解を除外する。



問題に解答したり、選択肢に残ったものから最も適切な答えを選ぶときには、ITIL理論を用いる。 yこの試験は傾斜配点になっているため、残りの選択肢は非常に似通っていることが多い。 y問題に行き詰まったら、その問題は飛ばして次に進む。 y試験を進めるにつれて、構成のリズムや問題の言い回しに慣れてくる。 yわからない場合は推測する。解答が間違っていても減点されることはない。 y



コースの内容

1日目 SOA

ユニット内容開始終了合計時間(単位：時)

はじめに 09:30 10:00 00:301 サービスマネジメント 10:00 10:30 00:302 サービス・ポートフォリオ管理 10:30 11:30 01:003 サービス・カタログ管理 11:30 12:00 00:30

昼休み 12:00 13:00 01:003 サービス・カタログ管理 13:00 14:30 01:304 サービスレベル管理 14:30 18:00 03:30

自宅学習 (本日の学習内容の復習) 01:00

合計 09:30

合計 - (昼休みと自宅学習を除く) 07:30



2日目 SOA


4 サービスレベル管理(1日目の続き) 09:30 11:30 02:005 需要管理 11:30 12:00 00:30

昼休み 12:00 13:00 01:005 需要管理 13:00 14:00 01:006 サプライヤ管理 14:00 16:00 02:007 財務管理 16:00 18:00 02:00

自宅学習 (本日の学習内容の復習) 01:00合計 09:30合計 - (昼休みと自宅学習を除く) 07:30



3日目 SOA


7 財務管理(2日目の続き) 09:30 11:00 01:308 事業関係マネージャ 11:00 11:30 00:309 役割と責任 11:30 12:00 00:30

昼休み 12:00 13:00 01:0010 技術と導入に関する検討事項 13:00 14:00 01:0011 試験対策/自習 14:00 15:00 01:00

試験 15:00 16:30 01:30合計 07:00合計 - (昼休み、試験を除く) 04:30SOAの合計時間 19:30

注:ケース・スタディの一読このコースの活動に使用するケース・スタディは、付録Aにあります。最初の休憩時間にケース・スタディを一読することをお勧めします。一読しておくと、活動に使用するシナリオをよく理解できます。

備考：ロイヤル・チャオプラヤ・ホテルとホテル・スタッフをより理解するには、ケース・スタディの「重要ではない」個所も読むとよいでしょう。

注:自主学習についての推奨事項SOAのシラバスでは、指定の授業時間に加えて12時間の自主学習を推奨しています。

受講者用参考資料には、このコースのための自主学習を支援する内容が含まれています。毎日授業後に、その日に習った個所を一読することをお勧めします。そうすることで記憶が新たになり、授業で学習した概念がしっかり定着します。

備考：これは学習に大いに役立ちますが、必須ではありません。

体系的な自主学習のアイデア：自習時に模擬試験問題を解いて自分の理解を明確にしましょう。



1.5　サービスマネジメントの概念

サービスマネジメントとは、顧客に対し、サービスの形で価値を提供する組織の専門能力の集まりである。（出典：『サービストランジション』）

あなたが考える組織の「専門能力」とは何でしょうか？

能力とリソースの違いは何でしょうか？

能力とは、一般的には経験に依存し情報に基づいた力を指す。 yリソースとは、一般的には組織の所有物を指す。 y

リソースが組織の財産または所有物である場合、リソースと能力の両方が組織の従業員にあたると言えるでしょうか？

そのとおりです。誰かを採用すると、その人はまずリソースになります（多くの場合、人材をリソースと呼びます）。しかしその人は、新しい業務の初日からに十分に業務をこなせるわけではありません。新しい従業員はプロセス、組織の要件、事業に関する特定のナレッジなどを認識していないのです。その従業員が経験を積み、情報を得て、十分に業務をこなせるようになるのは、その仕事に就いて数か月たってからです。その時点で、その従業員は企業の能力の一部になります。

リソースと能力は両方ともサービス資産の種類です。組織はこれらの資産を利用して、商品やサービスを提供します。商品やサービスを提供するこのプロセスが価値を創出します。

結果として、サービスマネジメントは組織の能力を最大限に利用して、利用できるリソースを価値あるサービスに変換する術と言えます。



My N otes

1.6　サービスの概念

サービスとは、顧客が特定のコストやリスクを負わずに達成することを望む成果を促進することによって、顧客に価値を提供する手段である。

（出典：『サービストランジション』）

あなたが考える「良いサービス」とは何でしょうか？

サービスとは、関連するタスクのパフォーマンスを改善し、制約の影響を緩和することによって、特定の成果を達成することを可能にする価値提案であることに注意してください。

このサービスの概念を理解することが重要です。夕食について考えるときのスーパーマーケットとレストランの違いを例に挙げてみましょう。

どちらの場所も食べ物を販売しています。スーパーマーケットでは、顧客は食事の材料である1つまたは複数の製品を購入し、食事を作る能力は自前です。帰宅して食事を作り、テーブルを整えて来客に夕食を出し、それから後片付けをします。一方レストランでは、食事をする客はサービス全体、つまり食事を作るための能力とリソース、および食事の経験全体を購入します。これは製品とサービスの間の非常に明確な違いです。

また、前述の定義の中の、特定のコストやリスクを「負わずに」という部分に注意することが重要です。サービスを利用するにあたり、顧客が支払うコストはまだあるでしょう。しかし顧客は、中核能力となるインフラストラクチャや能力を構築するためにそのコストを支払うのではありません。レストランと同様に、そのサービスの顧客として対価を支払っているのであり、シェフとして自分のスキルに投資しているのではないのです。



My N otes

1.7　サービス・ライフサイクル内の機能とプロセス

機能それでは、機能の概念の説明から始めましょう。

ITILによると、機能とは特定の成果を生み出すために、特定の種類の業務を実施する特別な能力を持つ構成単位です。機能は、必要とされる成果を生み出すために必要な専門化したリソースも持っています。専門化した能力とは組織の手法や知識体系などで、専門化したリソースとは専門的なナレッジを備えたさまざまな役割などです。

では、機能とはどのようなものでしょうか？

機能：組織に対して構造と安定性をもたらす。 y自己完結した組織単位で、独自の能力とリソースを備えてい yる。プロセスによって機能横断的な調整とコントロールを行う。 y経験から構築された、独自のナレッジベースがある。 y調整が乏しいか、焦点が内向きである場合、縦割りの機能とな yってしまう可能性がある。

プロセスプロセスとは、特定の達成目標を実現するために設計された、体系的な一連の活動です。明確に定義されたインプット、活動、結果があり、文書化されたプロセスの役割と継続的改善ループもあります。

覚えておく必要がある重要な点は、サービスマネジメント内のプロセスが、組織の利害関係者にとっての価値創出の中核にあるということです。



サプライヤ

データ、情報、ナレッジ

プロセス

活動1

活動2

活動3

サービスのコントロールと品質

トリガ

求められる成果

顧客

では、プロセスとはどのようなものでしょうか？

プロセス：すべての利害関係者にとっての価値を創出する。 y1つまたは複数のインプットを受け取り、定義されたアウトプットに変換する。 yアウトプットを提供するために必要なすべての役割、責任、ツール、マネジメント・コントロール（指 y標と測定基準）を含む。

プロセス・コントロールとは、効果的、効率的、かつ一貫的にプロセスを実行することを達成目標として、プロセスを計画立案して統制する活動です。ITILでは、閉ループ・システムとしてのプロセスの概念について非常に具体的に説明しています。閉ループ・システムの特徴は、自己補整と自己強化です。開ループ・システムは目的に従って設計されており、変更にはあまり対応できませんが、閉ループ・システムのフィードバック・ループでは補整が可能になります。

開ループ・プロセス：成果の価値がプロセスのインプットに何の影響も及ぼさないコントロール・プロセス

閉ループ・プロセス：成果の価値が、求められる価値を維持するような形でプロセスのインプットに影響を及ぼすコントロール・プロセス



My N otes

1.8　サービス・ライフサイクル内の役割

役割役割とは、プロセス内で定義され、個人やチームに割り当てられた責任、活動、および職権です。役割は機能の中に存在すると言えるでしょう。それぞれの役割は関連する説明責任と、特定の成果に対する実行責任を負います。機能内のすべての役割が効果的に働くと、その機能は目標とする成果を首尾良く生み出すことができます。

機能、プロセス、および役割の分類は、組織の構造と設計よって決まります。大規模組織では、キャパシティ・マネージャのプロセスは、組織図上のキャパシティ・マネージャの業務と同じであることがあります。一方、より小さな組織や構造の異なる組織では、標準的なIT職務にキャパシティ・マネージャというプロセス上の役割が割り当てられた、キャパシティ管理プロセスという文書として認識されていることもあります。

ファンデーション・トレーニングで学習したRACIを覚えていますか？

R 実行責任者（Responsible）

A 説明責任者（Accountable）

C 協議先（Consulted）

I 報告先（Informed）

ITILベストプラクティスに従って作成されたRACIチャートなどの説明責任マトリクスは、誰が何を行うべきかをチーム・メンバ全員に明確に理解させます。また、文書化されたITILプロセス内の活動の重複とギャップを識別するために使用できます。



前のトピックで学習したとおり、それぞれの役割には特定の機能があります。実際、ITILサービス・ライフサイクルのアプローチでは専門化が必要です。役割が特定の機能をどのように果たすかについて理解を深めるために、前述の役割について考えてみましょう。

サービス・オーナは、合意されたサービスレベルの枠内で特定のサービスを提供することに責任を負います。

プロセス・マネージャは、プロセス管理のすべての活動を計画立案および調整することに責任を負います。プロセス・マネージャは、プロセスの管理と改善に関与するすべての関係者、特にプロセス・オーナを支援します。プロセス・マネージャは担当のプロセスに対するすべての変更も調整し、すべてのプロセスが途切れなく連携することを確実にします。

プロセス・オーナは、プロセスが求められる成果を生み出すのに適しているようにする責任を負います。プロセス・オーナの責任には、プロセスとその測定基準の後援、設計、および継続的改善を含みます。

サービス・マネージャは、新規および既存の製品やサービスの継続した管理に責任を負います。

特定のタスクを実行する人材だけでなく、その人材の役割も特定することが重要です。役割は、組織内で明確に定義されないことがよくありますが、その場合、RACIチャートを作成し実行することが難しくなります。また、明確に定義された役割がないと、組織再編や業績評価時に役割を再調整することが困難になります。



1.9　サービスマネジメントの事業上の価値

継続的サービス改善

サービストランジション

サービスデザイン

サービスストラテジ

サービスオペレーション

授業で行ったシナリオでは、サービス・ライフサイクル内の各段階がどのような目的を持っているかを確認しました。例えば、戦略がない場合、サービス・プロバイダは自分たちがうまくやっているか、また顧客にとっての投資利益率（ROI）が上がっているかをどのようにして知るのでしょうか？



My N otes

設計なしで、サービスに適切な有用性と保証をどのように提供するのでしょうか？

移行なしで、変更管理、インパクト・アセスメント、適切なレベルのテストなどをどのように行いますか？

運用なしで、どうやってインシデントの適時の処理や根本原因の検出などを行いますか？

また、改善（CSI）なしで、時間がたつにつれてサービスが低下するのをどのように防ぐのですか？さらに、ITは事業に効果的な貢献をしなくなってしまいます。



My N otes

1.10　サービス・ライフサイクルのサポート

サービス・ライフサイクルをサポートするSOAプロセスには、次のものがあります。

サービス・ポートフォリオ管理：サービスを事業上の価値の面 yから説明し、ビジネス・ニーズと、そのニーズに対するプロバイダの対応を明確化する。サービス・カタログ管理：サービス・カタログが作成され、提供 yおよび導入されているすべてのサービスに関する正しい情報で最新に保たれるようにする。SLM：ITサービスの目標値について事業と交渉し、合意し、文 y書化する。その後、実際に提供されるサービスのレベルをモニタし、報告する。需要管理：事業活動パターン（PBA）、ユーザ・プロファイル、お yよび活動を分析し、サービスに対する需要について把握し影響を及ぼす。財務管理：ITサービス・プロバイダの予算業務、会計業務、お yよび課金に対する要件を管理し、サービスの価値とコストを比較した事業判断を下せるようにする。サプライヤ管理：サプライヤが投資に見合う価値を提供し、事 y業に提供されるITサービスの品質を維持することを確実にする。

これらのプロセスの価値は、プロセス間のインタフェースが機能して初めて実現されます。サービス、ITインフラストラクチャ、状況、アプリケーション、データを設計、管理、およびサポートするために、サービス・ライフサイクル内のすべてのプロセス間で強い結び付きを維持しましょう。

また、サービスやプロセスを設計すると同時に、役割と責任を定義する必要があります。組織のパフォーマンス全体を改善するには、迅速な意思決定と実行が不可欠です。決定は、誰がインプットし、誰が権限を持ち、誰が承認済みの決定を実行するかが明確であれば迅速に処理できます。

財務管理は、運用の可視化、洞察、優れた意思決定といった中核能力を組織が育成するのに役立ちます。コストが透明なサービスを提供することで、財務管理は事業に貢献します。このコストの透明性は、IT組織と事業による需要モデル化と資金調達の計画プロセスにおいて、大幅なコスト削減と需要管理能力を生み出すのに役立ちます。

これについては、このコースの後半で詳細に取り上げます。



My N otes

需要管理はサービスマネジメントの重要な要素です。サービスが適切に管理されていないと、需要が不確実になります。その結果、余分となったキャパシティが発生させるコストを回収できなくなり、サービス・プロバイダに対するリスクが増加します。顧客は、自分にとって価値をもたらさない余分なキャパシティにはお金を払いたがりません。しかし、時には、余分なキャパシティがサービスレベルの維持に必要となることがあります。そのような場合、より大きいキャパシティによる、より高いレベルの確実さによって価値が生まれます。

これについては、このコースの後半で詳細に取り上げます。

サービス・ポートフォリオは事業上の価値の面からプロバイダのサービスを説明するものです。サービス・ポートフォリオは、ビジネス・ニーズと、それらのニーズに対するプロバイダの対応を明確に示します。また、多くの戦略的な問いを明確にすることで意思決定を支援します。

サービス・ポートフォリオ管理は、企業全体のサービスマネジメントへの投資を統制し、価値を生むようにそれらを管理するための動的な方法である。

（出典：『サービスストラテジ』）

財務マネージャは、顧客のリスクと報酬の概要に従って投資のポートフォリオを調整します。しかし、その概要に関係なく、達成目標は常に、受容可能なリスク・レベルで利益を最大化することです。



サービス・ポートフォリオ管理ユニット2

Student | ITIL v3 Intermediate Certification Level | Service Portfolio Management


My N otes

ユニット2：サービス・ポートフォリオ管理

概要事業のサービス目録は常に変化しています。追加される新サービスも、廃止されるサービスもあります。既存のサービスに変更を加える場合もあるかもしれません。サービス・ポートフォリオ管理（SPM）は、企業が最大限の価値を得るように、事業全体にわたるサービスマネジメントへの投資を統制するための体系的なアプローチを提供します。

ユニットの学習目標このユニットを修了すると、次の成果が得られます。

プロセスの最終目標と達成目標を説明できる。 yサービス・ポートフォリオの役割と、サービス・カタログおよび yサービス・パイプラインとの関係を理解できる。サービス・ポートフォリオで、サービス・プロバイダのサービス yをどのように説明し、ビジネス・サービスをITサービスにどのように関連付けるかについて理解していることを実証できる。SPMで使用する手法を理解し、適用できる。 y

2.1　サービス・ポートフォリオ、およびサービス・カタログとサービス・パイプラインとの関係

サービス・ポートフォリオサービス・ポートフォリオは、顧客とターゲット市場に対してサービス・プロバイダが行う約束事項と投資を表します。これには次のものを含みます。

現在の契約上の約束事項 y新規サービスの開発 y継続的サービス改善（CSI）によって実施される継続的なサー yビス改善計画（SIP）サービス・プロバイダのサービス提供内容の中心となるサー yドパーティのサービス



顧客1

顧客2

顧客3

サービス改善計画

サービス・ポートフォリオ

サードパーティのサービス

ターゲット市場3



サービスによってリンク

サービスの潜在的な市場

ポートフォリオ管理アプローチは、マネージャが次のことを行う助けになります。

投資の優先度付け yリソースの割り当ての最適化 y顧客とターゲット市場にサービスを提供するための確実な準備 y無駄な投資を回避するために必要な財務の規律の採用 y

ポートフォリオへの変更は、設定した方針と手順に従って実施します。




サービス・カタログ

サービス・パイプライン


ターゲット市場

サービスの概念

顧客

サービスデザインサービス

トランジション


サードパーティ・カタログ

廃止される

サービス

使用されるリソース

サービスオペレーションから得た資産利益率

解放されたリソース

共通のリソース群

円の面積は、ライフサイクルの段階で現在使用されているリソースに比例する（サービス・ポートフォリオおよび財務管理）







顧客





廃止される

サービス






サービス・ポートフォリオの内容サービス・ポートフォリオは、顧客とターゲット市場にサービスを提供するための、サービス・プロバイダの能力と準備状況を表します。サービス・ポートフォリオには次の3つの段階があります。

サービス・パイプライン：準備中のサービスを含む。 yサービス・カタログ：サービス・ポートフォリオの一部で、顧客に提供されている実行中のサービス yを含む。廃止されるサービス：すでに市場にないサービスを含む。 y



サービス・ポートフォリオ = サービス・ライフサイクルのさまざまな段階において、現在使用されている、または解放されているすべてのリソース

サービス・ライフサイクルの各段階では、サービス・プロバイダはプロジェクト、取り組み、および契約の遂行のためにリソースを必要とします。ここでSPMのガバナンスの側面が重要になってきます。

適切なポートフォリオでは、サービス・パイプラインとサービス・カタログのサービスを適切に組み合わせる必要があります。

そうすることで、サービス・カタログによってサービス・プロバイダの財務的な存続可能性を確実にできます。コストを回収したり利益を生み出したりするのは、サービス・ポートフォリオの中でサービス・カタログだけであることに注意してください。

つまり、SPMはコストとリスクを最小限に維持しながら、サービス提供と顧客経験の改善によって価値を最大限にすることを目的とします。SPMによって、マネージャは品質要件と提供コストをより良く理解でき、ひいては、サービス品質を落とさずにコストを削減できるようになります。SPMプロセスは、標準化されたサービスを文書化することが始まります。またこのプロセスは、サービスレベル管理（SLM）、特にサービス・カタログと密接に関係しています。


説明

価値提案

ビジネス・ケース

優先度

リスク

提供内容とパッケージ

コストと価格設定


サービス

サポートされる製品

方針

順序付けと要求手順

サポート条件

エントリ・ポイントとエスカレーション

価格設定と課金


説明

価値提案

ビジネス・ケース

優先度

リスク

提供内容とパッケージ

コストと価格設定


サービス

サポートされる製品

方針

順序付けと要求手順

サポート条件

エントリ・ポイントとエスカレーション

価格設定と課金



My N otes

サービス・カタログサービス・カタログは、サービス・ポートフォリオのうち顧客に見える部分で、現在顧客に提供されているサービスで構成されています。サービス・カタログには、サービスオペレーション段階のサービスと、顧客に提供することを承認されたサービスが含まれています。つまり、サービス・カタログに記載されるアイテムは、コストとリスクに関する精査を終えたもののみです。実行中のサービスをあらゆる方法でサポートするために、すべてのリソースが活用されます。

サービス・カタログの有用性サービス・カタログは、1つまたは複数のサービスの顧客向けにカスタマイズした解決策を作成するのに役立ちます。顧客の特定の要件を満たすために、さまざまなサービスを組み合わせて価格設定したものをカタログに提示できます。

実際のところ、サービス・カタログにはサービス・プロバイダの現在の実運用能力に関する情報があるため、サービスストラテジの重要なリソースになっています。多くの顧客は、現在利用できるサービスにのみ興味を示します。サービス・カタログを見ることで、顧客は必要なサービスを選択できます。

つまりサービス・カタログは、サービスを受注し、顧客または市場の需要を管理するうえで重要な役割を担っています。サービス・カタログには、ほかにも次のような有用性があります。

SPMに必要な方針、指針、および説明責任を明示している。 ySPMで管理するサービスの基準を設定している。 ySPMで管理する各サービスの達成目標を定義している。 y各サービスの価格、サービスレベルの約束事項、および諸条 y件を示している。各サービスがコンポーネントに分解されていて、エントリ・ポ yイントおよび使用と供給の条件とともに、資産、プロセス、および仕組みが紹介されている。

サービス・プロバイダが複数の顧客や事業にサービスを提供している場合、1つのサービス・ポートフォリオを基にしてさまざまなサービス・カタログを提示することもあります。

マネージャは、意思決定のための視覚化ツールとしてサービス・カタログを利用できます。サービス・カタログは、顧客の需要とその需要を満たすプロバイダの能力を結び付けます。この2つが一致すると、サービス契約またはサービス合意が結ばれます。

サービス・カタログ内のアイテムは、事業活動パターン（PBA）に基づいてサービス・ライン（LOS）ごとにグループ化されます。十分な業績を



My N otes

上げているLOSには、その業績を維持し、またそれらのサービスへの需要の増加に対処するために、追加リソースが割り当てられます。業績不振のLOSは廃止と記され、移行計画を通して段階的に停止されます。ただし、他のサービスにとって戦略的価値がある、初期の顧客との契約上の義務があるなど、正当化できる理由がある場合は維持されることがあります。これには上級リーダの承認が必要となります。

サービス・パイプラインサービス・パイプラインには、開発中のサービスが記載されます。これらのサービスは、サービストランジションが設計、開発、およびテストを終了した後に運用可能になります。パイプラインはサービス・プロバイダの成長の見通しを表すので、十分な資金を投じる必要があります。また、新しいサービスと改善のアイデアの提案におけるサービスストラテジ、サービスデザイン、およびCSIの生産性も表します。

アウトソーシングされたサービスコアサービス・パッケージ（CSP）とサービスレベル・パッケージ（SLP）から成る、サードパーティによるサービスやアウトソーシングされたサービスもサービス・カタログに含むことができます。サードパーティ・カタログは、事業がサービス対象の顧客とターゲット市場の範囲を拡大するのに役立ちます。また、十分に対応されていない需要に対処するために、サービス・パイプライン内のアイテムが移行されるまでの代替サービスとしたり、廃止されるサービスに代わるものとして使用したりできます。ソーシングは戦略的選択肢であるだけでなく、時には、運用上の必需品にもなります。サードパーティ・サプライヤは、カーネギーメロン大学が開発したサービス・プロバイダ向けeソーシング能力モデル（eSCM-SPTM）によって評価できます。

廃止されるサービス定期的に、幾つかのサービスをカタログから削除する場合があります。段階的にサービスを停止する間、顧客に対する約束事項が果たされ、サービス資産が契約から解放され、関連情報が将来に備えて記録されることを、サービストランジションによって確実にする必要があります。廃止されるサービスは顧客には提供されません。特別なビジネス・ケースを作成する場合、段階的に廃止されたサービスを特別な条件に基づいて復活させ、そのサービスレベル・アグリーメント（SLA）を上級リーダが承認する場合があります。廃止されたサービスを復活させる決定は慎重に検討する必要があります。なぜなら、そのようなサービスにはより多くのサポートが必要となり、規模の経済と範囲の経済への障害となる場合があるからです。



My N otes

サービストランジションは、次のような理由から、サービス・カタログへのすべての変更を承認する必要があります。

サービス・カタログに不完全な製品を含めると、サービス・プ yロバイダと顧客が多大な損失を被るおそれがある。カタログに記載したあらゆるサービスは、十分にサポートされなければならない。サービスを十分にサポートするために、技術的実行可能性、財務的存続可能性、および運用能力に関する調査を最初に行う必要がある。運用中のサービスを変更すると、関与する契約上の義務を満 yたすプロバイダの能力に影響を及ぼす場合がある。需要のないアイテムを追加すると、価値のあるリソースがそ yれに占有されてしまい、より生産的に利用できなくなるおそれがある。

事業要件をカタログからのサービスで満たすことができない場合、サービス・プロバイダは次を行う必要があります。

なぜニーズを満たすことができないかを顧客に説明する。 y新しいサービスを開発するために顧客から必要なコミットメ yント、後援、または投資を詳しく説明する。顧客が必要なコミットメントに合意したら、サービス・プロバイダはそのサービスを開発しなければならない。サードパーティと協働して顧客ニーズに応えることを検討す yる。

財務管理とSPM財務管理はSPMの重要な側面です。企業はサービス提供にかかる内部コストを分析し、評価する必要があります。サービス・コストが、他のサービス・プロバイダが同様のサービスに設定している金額より高い場合、企業は、そのサービスをアウトソーシングし、それで空いたリソースをよりコストの低い、または品質の高いサービスに集中させるよう決定することができます。

このアプローチの根底にある基本原則は、サービスと製品を中核能力に一致させることです。他のサービス・ラインと比較して、費用対効果の低い、または要求される品質を提供しないサービス・ラインからは撤退するとよいでしょう。しかし、多くのIT組織はサービス指向のコストを明確にして事業に見せることを避けています。そうすると、ポートフォリオが、費用対効果が低く、顧客の期待を満たさないサービスばかりになります。



My N otes

2.2　サービス・ポートフォリオにおけるサービス・プロバイダのサービスの記述、およびビジネス・サービスをITサービスに関連付ける方法

サービス・ポートフォリオサービス・ポートフォリオは事業上の価値の面からサービス・プロバイダのサービスを説明するものです。サービス・ポートフォリオは、ビジネス・ニーズと、それらのニーズに対するサービス・プロバイダの対応を明確に示しています。事業上の価値の用語（マーケティング用語など）は、さまざまなプロバイダのサービスの競争力を比較するのに役立ちます。サービス・ポートフォリオは、次のような戦略的な問いを明確にすることで意思決定を支援します。

顧客はなぜこれらのサービスを購入しなければならないの yか？顧客はなぜこれらのサービスを我々から購入しなければなら yないのか？価格設定モデルや課金モデルはどのようなものか？ y自分たちの強みと弱み、優先度、リスクは何か？ y自分たちのリソースと能力をどのように割り当てるべきか？ y


組織はサービス指向のプロセスを一連の戦術的プログラムと見なしがちです。サービスの概念的な理解だけで装備し、サービスの成果の産業化に突き進む組織がよくありますが、その勢いで、組織の変更やプロセス再設計の取り組みを立ち上げることになります。そのような取り組み自体も重要な最終目標かもしれませんが、定めた規律に従うことが不可欠です。

この規律は必須ではありませんが、次のような2つの重要な役割を果たします。

第一に、規律を定めていると、どのようなサービスを提供する yべきかを知らずに組織の設計を実行するといった誤ったステップへの警告となる。第二に、規律を定めていると、サービス・ポートフォリオへの y初期のニーズを思い出すことができる。これは、サービス戦略を設計しサービス投資を管理するうえでしばしば見逃されるインプットである。



My N otes

財務マネージャは、顧客のリスクと報酬の概要に従って投資のポートフォリオを調整します。しかし、その概要に関係なく、達成目標は常に、受容可能なリスク・レベルで利益を最大化することです。ポートフォリオは変化する状況に一致していなければなりません。ポートフォリオの管理には、それに見合ったプラクティスを適用する必要があります。サービス・ポートフォリオに価値があるのは、戦略と計画立案にとって明確であると同時に、変更を予測できるからです。

サービス・ポートフォリオ管理サービス・ポートフォリオ管理は、企業全体のサービスマネジメントへの投資を統制し、価値を生むようにそれらを管理するための動的な方法である。


ここでのキーワードは「方法」です。サービス・ポートフォリオは、サービス、アプリケーション、資産、プロジェクトを単に列挙したものだと見なされることがよくあります。基本的にポートフォリオでは、同様の投資を、規模、領域、または戦略的価値ごとにグループ分けします。ITポートフォリオ管理、プロジェクト・ポートフォリオ管理、SPMの間の違いは、実施の詳細にあります。根本的に、これらはすべてガバナンスのための実現ツールです。



ビジネス・サービス ITサービス

ビジネス・プロセス ITアプリケーション

管理

人材

ナレッジ

情報

アプリ

ケーション

インフラ

ストラクチャ

ワークフロー

有用性

管理

人材

ナレッジ

情報

アプリ

ケーション

インフラ

ストラクチャ

ロジック

有用性

サービス・プラットフォーム

可用性

継続性

キャパシティ

セキュリティ

保証


可用性

継続性

キャパシティ

セキュリティ

保証

ビジネス・サービス ITサービス

ビジネス・プロセス ITアプリケーション

管理

人材

ナレッジ

情報

アプリ

ケーション

インフラ

ストラクチャ

ワークフロー

有用性

管理

人材

ナレッジ

情報

アプリ

ケーション

インフラ

ストラクチャ

ロジック

有用性


可用性

継続性

キャパシティ

セキュリティ

保証


可用性

継続性

キャパシティ

セキュリティ

保証

ビジネス・サービスとITサービスビジネス・プロセスは、複数の技術、アプリケーション、地理的範囲、ユーザ間に分散する場合がありますが、それを束ねているのはデータセンタ1個所です。ビジネス・プロセスを統合するために、ITでは通常ボトムアップ・アプローチを採用します。これは、ビジネス・プロセスの層では相互作用するように意図されていないアプリケーション・コンポーネントを技術と結び付けるものです。このアプローチでは、まとまりも柔軟性もないITソリューションとなり、事業の最終目標を満たせません。

より効果的なアプローチは、事業活動を抽象化してモデル化したものに焦点を当てることです。これによって、さまざまな事業活動がさまざまな形で表されます。ビジネス・プロセスは、1つのビジネス・サービスまたはビジネス・サービス一式、アプリケーション一式または個別のアプリケーション機能、個別のトランザクション、履行要素一式などとして表されることがあります。いずれの場合も、そのプロセスは事業の領域に存在します。



きめが粗い

きめが細かい

サービス重視

プロセス重視

サービスの詳細度

技術事業プロセスの背景

きめが粗い

きめが細かい

サービス重視

プロセス重視

サービスの詳細度

技術事業プロセスの背景

（サービスの観点の図には、EAI、ESA、SOAといった略語の定義はありません。）

SOA: Service-oriented Architecture

(サービス指向アーキテクチャ)

ESA: Enterprise Services Architecutre

(エンタープライズ・サービス・アーキテクチャ)

EAI: Enterprise Application Integration

(エンタープライズ・アプリケーション統合)



My N otes

サービスの観点ビジネス・サービスを定義できるのは事業だけです。ITが事業にサービスを提供していても、事業がそのサービスを事業内容の一部と見なさない場合、それはITサービスです。サービスが創出する価値を重視すると、ITサービスとビジネス・サービスの間の境界があいまいになり始めます。事業の観点またはITの観点を採用するときには、顧客を考慮する必要があります。ビジネス・サービスであれ、ITサービスであれ、それぞれのサービスは価値の基盤を提供し、ガバナンス、提供、およびサポートを必要とします。結局、ITサービスマネジメント（ITSM)とビジネス・サービスマネジメント（BSM）は、サービスマネジメントという同じ概念からの観点なのです。

ビジネス・サービスマネジメントBSMとは何でしょうか？

ビジネス・サービスマネジメントとは、ITとITが影響を与えるビジネス・サービスを統治し、モニタし、報告する継続的なプラクティスである。


ITの優先度は、事業上の価値を生み出す他の推進要因と一致していなければなりません。ITが事業達成目標に沿ってサービスを体系化するためには、ビジネス・プロセスやビジネス・サービスにかかわるべきです。そのためITリーダは、事業オーナとコミュニケーションを取り、求められる成果を明確に理解する必要があります。

インフラストラクチャの管理とサービスの管理には大きな違いがあります。インフラストラクチャの管理ではコンポーネントの運用上の可用性に注目する必要がありますが、サービスの管理では顧客と事業のニーズに焦点を当てる必要があります。インフラストラクチャが正しく機能しているかどうかに関する運用情報だけでは十分ではありません。多くの場合、IT組織は活動を事業達成目標に関連付けたいと考えていますが、事業の活動とIT実施との関係をどの程度まであらわにするかについて苦心しています。

最近の組織は、事業パートナと内部でアプリケーションを統合して、エンドツーエンドのビジネス・プロセスを自動化することをより重視しています。重要なのは、ビジネス・サービスの運用上の達成目標を実現することと、それを常に念頭に置いておくことです。BSMは、ITインフラストラクチャを事業の観点に適合させやすくするという課題に対処するのに役立ちます。

サービス・プロバイダは、BSMを通じてビジネス・サービスを管理できます。このようにビジネス・サービスに焦点を当てることで、プロバイダは次のことができるようになります。

インフラストラクチャへの投資および運用活動を事業達成目 y標に整合させやすくなる。事業中心の測定基準を策定し、事業が将来のニーズにより簡 y単に対応できるようにする。



BSMの主要な利点は、因果関係に基づいて、サービス資産を関連するビジネス・サービスに結び付けることです。そうすると、ITインフラストラクチャの視点が、資産とサービスの関連性を示す依存関係のモデルへと移ります。これにより、インフラストラクチャのイベントを事業成果に結び付けることができるようになります。

サービス

ビジネス・プロセス

サービス

リソースと能力

要員

抽象化または混成

分解

インターネット

サービス


サービス

リソースと能力

要員

抽象化または混成

分解

インターネット



My N otes

組織図組織図は運営管理に役立ちますが、次のものを反映していません。

顧客 y顧客に提供されるサービス yそのサービスを提供するワークフロー y組織が何をし、どのようにそれを行い、誰のために行うのか y

最終目標の設定とレポートの作成は、個別に行われます。社員を評価する基準は、戦略的計画立案能力、事業の専門知識、予測、測定基準の利用などではなく、特定の技術や機能に関する専門能力です。通常、技術マネージャまたは機能マネージャは、同僚をパートナではなく競争相手と見なし、先を争ってリソース、予算、昇進を確保しようとします。

ITSMを協調的で機能横断的なアプローチで進め、それぞれの機能マネージャが他のマネージャを競争相手ではなくパートナと見なすようにする必要があります。このアプローチでは縦割り間の課題が下位レベルで処理されるため、機能マネージャは顧客に関する優先度の高い課題に集中できます。このアプローチではまた、下位レベルの貢献者による取り組みを奨励します。

通常は対処されないままの機能横断的な課題は、組織の機能を改善する機会になります。組織図の空白または「余白」では、それぞれの枠が互いにやり取りして情報を交換しています。組織図は、組織自体を表すものと考えないでください。このような誤解のせいで、マネージャが組織ではなく組織図を管理するようになることもあります。マネージャは縦割り間の問題を解決するために、プロセス全体を作成しようとするべきです。

プロセスの中には、IT外部の顧客への製品やサービスを管理または作成するものもあります。組織のパフォーマンスを改善できるかどうかは、これらのプロセス次第です。つまり、ITSMプロセスの下では、ITを包括的な一連の事業リソースや事業能力と見なす必要があります。



2.3　サービス・ポートフォリオ管理の方法

SPMには4つの主要な段階があります。

定義 y分析 y承認 y制定 y

定義この段階では、概念段階のサービスを含む、既存および計画されたすべてのサービスから情報を収集します。この作業は既存ポートフォリオの機会費用を把握し、リソースの再割り当てについて決定するのに役立ちます。

分析収集すべき適切なデータを識別できるように、この段階を明確に事前定義する必要があります。中断を最小限にするためには、データを収集するプロセスそのものを合理化するべきです。

この段階は、サービスの初期目録を作成し、この目録を定期的に妥当性確認するのに役立ちます。複数のポートフォリオは、特定の傾向やイベントに応じて異なるタイミングで更新されます。例えば、合併や吸収時にはポートフォリオ見直しが必要です。

それぞれのサービスには、サービスが何を達成するべきかを詳細に示すビジネス・ケースを含める必要があります。ビジネス・ケースは、事業活動がサービス戦略と資金調達に結び付くように、組織の特定の最終目標を達成するための一連の行動を理由付けします。ビジネス・ケースでは、潜在的なメリットの面からサービスへの投資を評価し、そのサービスを提供し維持するのに必要なリソースと能力を識別します。

十分以上の対応顧客ニーズ不十分な対応

新規

市場空間

既存

新規

顧客

既存

将来的に投資する

かもしれない

将来的な投資が

ありうる

近い将来には投資しそうにない

近い将来におそらく投資する

投資しない投資する

1.0 価値対コスト


新規

市場空間

既存

新規

顧客

既存


かもしれない


ありうる







My N otes

オプション空間ツールオプション空間はサービス・ポートフォリオの中のツールで、ポートフォリオへの投資のタイミングと順序に関する決定の手引きとなります。

価値対コストの軸はサービスがそのコストに対して持つ価値の比率を表します。値が1未満の場合はサービスの価値がそのコストよりも低く、値が1より大きい場合はサービスの価値がそのコストよりも高いことを示します。価値対コストを計算するだけでなく、財務以外の指標も考慮する必要があることもあります。

財務以外の指標に基づいて価値対コストを出すこともできます。例えば、公共政策では政府機関向けの価値対コストを出します。

他の軸はターゲット市場、顧客、および顧客ニーズに基づくものになるでしょう。これらのそれぞれが戦略的意図の手引きとなります。例えば、プロバイダがある新しい事業部門にサービスを提供しようとしても、その部門の顧客へのサービス提供がすでに過剰になっている場合、創出される価値は低くなります。軸がポートフォリオに全く関係しない場合、その手引きは無視できます。

分析この段階では、まず次のトップダウン型の質問をすることで戦略を定義します。

サービス組織の長期的な最終目標は何か？ yそれらの最終目標を達成するにはどのようなサービスが必要 yか？組織がそれらのサービスを実現するには、どのような能力と yリソースが必要か？どのようにして目標を達成するか？ y


これらの質問によって、観点、ポジション、計画、およびパターン（サービスストラテジの4つのP）が明らかになります。これらの質問への答えから、分析だけでなく、SPMに求められる成果の概要がわかります。これらの質問には上級リーダと対象分野の専門家が答えます。彼らは新規サービスへの投資について十分な情報に基づいた決定を行うのに伴うリスク、インパクト、依存関係を理解しているからです。



投資に関する選択肢の選別どの投資を行うかは、どのようにして決定するのでしょうか？

上級リーダは、限りのあるリソースを管理する必要があります。そのために、上級役員はサービス投資に関して情報に基づいた決定を行うのに伴うインパクト、リスク、依存関係と、適切なレベルのリスクと報酬を理解しなければなりません。このような投資は複数の機能にまたがったり、さまざまな期間にわたったりする場合があります。想定した価値がリスク・レベルに合うようにしなければなりません。

サービス投資は、3つの戦略的カテゴリに分けることができます。

事業運営（RTB） ― RTB投資はサービス運用の維持に向けられる y事業拡大（GTB） ― GTB投資は組織のサービス適用範囲の拡大を意図する y事業変革（TTB） ― TTB投資は新しいターゲット市場に参入する動きである y


リスク

ベンチャー

成長

自由裁量

非自由裁量

中核

事業変革（TTB）

事業拡大（GTB）

事業運営（RTB）

リスク

ベンチャー

成長

自由裁量

非自由裁量

中核

事業変革（TTB）

事業拡大（GTB）

事業運営（RTB）



これらの投資カテゴリは、さらに予算割り当て別に分けることができます。

ベンチャー ― 新しいターゲット市場でのサービス創出 y成長 ― 既存のターゲット市場での新サービス創出 y自由裁量 ― 既存サービスの強化 y非自由裁量 ― 既存サービスの維持 y中核 ― 事業に不可欠なサービスの維持 y



新規

市場空間

既存

顧客


かもしれない


ありうる





新規

既存

変革

拡大

廃止

運営


新規

市場空間

既存

顧客


かもしれない


ありうる





新規

既存

変革

拡大

廃止

運営




新規

市場空間

既存

顧客

将来的に投資するかもしれない


ありうる


近い将来に

おそらく投資する



新規

既存

変革

廃止

拡大

運営


新規

市場空間

既存

顧客

将来的に投資するかもしれない


ありうる


近い将来に

おそらく投資する



新規

既存

変革

廃止

拡大

運営

事業運営、事業拡大、または事業改革のサービス・カテゴリへの予算割り当てを決定することによって、役員はSPMに関するリスクの受容を宣言することになるだけではなく、運用スタッフによって実施される運用のモードを直接的に左右することにもなる。RTBからTTBまでのサービスの配分は組織の性質を反映する。ITがコスト・センタ（バックオフィス）であれば主にRTBとなり、ITが投資センタ（商用プロバイダ）であれば主にTTBとなる。


この種の分析によって、リスクに対する企業の受容度が確認され、組織の性質が明らかになり、運用のモードが左右されることになります。サービスが主に事業運営（RTB）に配分されると、たいてい、ITはコスト・センタとして運営されます。サービスが主に事業変革（TTB）に配分されると、ITは投資センタとなることがほとんどです。



My N otes

承認この段階では、設計段階と分析段階を通して提案された計画を承認したり、却下したりします。承認とともに、新しいサービスとリソースも許可します。

既存サービスに対しては、承認結果は次のようになります。

維持 ― 組織の戦略に重要な資産、プロセス、システムの境界 yが定義されている、自己完結型のサービス。置換 ― 事業上の機能性が不明瞭で互いに重複しているサー yビス。合理化 ― 同じOSの複数のリリース、または同じソフトウェア yの複数のバージョンによるサービス。改良 ― 組織の技術的ニーズと機能的ニーズを満たしている yが、プロセスやシステムの境界があいまいなサービス。この例としては、それ自体の認証や継続性の機能を処理するサービスが挙げられる。このような種類のサービスは、そのサービスに中核的な機能性のみが含まれるよう改良し、他の機能性の提供には共通サービスを使用するようできる。改良は、再使用可能なサービスが組み込まれているサービスにも行うことができる。更新 ― 機能的な適合性基準は満たすが、技術的な適合性を y満たさないサービス。この例としては、組織の戦略計画ではメインフレーム・プラットフォームを廃止してマルチプロトコル・ラベル・スイッチング（MPLS）ワイド・エリア・ネットワーク

（WAN）をソーシングすることになっている場合に、今でも不可欠なビジネス・プロセスをサポートしているメインフレーム・システムとフレーム・リレー・ネットワークを履行要素に含むサービスが挙げられる。廃止 ― 技術的適合性も機能的適合性も最小レベルを満たし yていないサービス。



My N otes

制定この段階は、すべての決定事項と実施項目を一覧にすることから始まります。これらの項目は事業と共有し、予算決定と財務計画に結び付ける必要があります。予算を割り当ると、リソースも割り当てられます。

各サービスの推定される価値は、財務予測とリソース計画に組み込まれます。これはサービス投資のステータスを追跡するのに役立ちます。また、新たに制定されたサービスはサービスデザインへと進められ、サービストランジションを通してサービス・カタログの既存サービス部分が更新され、廃止されるサービスが削除されます。

市況が変化すると、これまでの投資利益率（ROI）計算が無効になります。コンプライアンスや規制の問題によって存続可能でなくなるサービスもあります。CIOは変化するビジネス・ニーズに合わせて、投資をモニタ、測定、再評価、再配分する必要があります。最適なレベルのROIとリスクを含んだポートフォリオを目指すべきです。そうすると、組織は制限されたリソースや能力を活用して最大の価値を実現するようになります。



My N otes

2.4　グループ／個人演習ワークブックを参照して演習に取り組んでください。

2.5　模擬試験問題

カナダ東部で急成長を遂げているある食品飲料企業の役員会で、ITILのプロセスと機能の正式な導入について調査することが決定しました。役員の多くはITILのことを知っていますが、ITILは事業にとってどのような意味があるのか、現在会社が経験している急速な成長をITILはどのように支援できるのかについて知識がありません。そこで、さまざまなコンサルタント会社を採用し、ITILの概要、導入後に期待できる利点、課題、および利益を示すように依頼することを決定しました。

役員会はあなたのコンサルタント会社を招き、役員に概要を説明するように依頼しました。具体的には、あなたの観点から、サービスマネジメントとは何であるかを説明するように依頼したのです。

あなたのプレゼンテーションに含めるべき適切な回答を選択してくQ1. ださい。

サービスマネジメントとは、顧客に対し、サービスの形で価値a) を提供する組織の専門的な能力の集まりです。この能力はライフサイクルを通してサービスを管理する複数の機能とプロセスの形を取り、戦略、設計、移行、運用、CSIに専門化されています。能力は、サービス組織のキャパシティ、力量、および行動に対する自信も表します。サービスとは、顧客が特定のコストやリスクを負わずに達成することを望む成果を促進することによって、顧客に価値を提供する手段です。リソースを価値あるサービスに変換することは、サービスマネジメントの中核に位置します。顧客の観点からは、価値は有用性と保証という2つの主な要素から成り立っています。有用性は顧客が得るものを意味し、保証は有用性が顧客にどのように提供されるかを意味します。

サービスマネジメントとは、顧客に対し、サービスの形で価値b) を提供する組織の専門的な能力の集まりです。この能力はライフサイクルを通してサービスを管理する複数の機能とプロセスの形を取り、戦略、設計、移行、運用、CSIに専門化されています。ITILには、貴社のサービスマネジメントに関するニーズを満たすために必要なプロセスと機能がすべて含まれているため、サービスマネジメントに最適なプラクティスです。サービスとは、顧客が特定のコストやリスクを負わずに達成することを望む成果を促進することによって、顧客に価値を提供する手段です。リソースを価値あるサービスに変換することは、サービスマネジメントの中核に位置します。



My N otes

サービスマネジメントは、ITILが提供する実証されたベストプc) ラクティスです。これらのプロセスと機能には、ライフサイクルを通してサービスを管理するための証明された実績があります。サービスマネジメントでは、構成、変更、インシデント、要求実現、財務キャパシティ、および可用性管理に焦点を当てることによって顧客にサービスを提供する、ITプロバイダの能力に重点を置いています。

サービスマネジメントは、顧客に良質なサービスを提供するd) ための広範なナレッジ体系、経験、およびスキルによって支えられる専門的なプラクティスです。サービスマネジメントではITILフレームワーク内のプロセスと機能のみを使用します。これらには、世界中の何千もの会社で使用されてきた過去25年間にわたる成功の実績があるからです。


所要時間 3 時間

サービス・カタログ管理ユニット3

Student | ITIL v3 Intermediate Certification Level | Service Catalogue Management


My N otes

ユニット3：サービス・カタログ管理

概要サービス・カタログは、あらゆる組織にとって不可欠なツールです。サービス・カタログは、事業が顧客に提供するサービスに関係するすべての情報の貯蔵庫です。組織の誰もが簡単に参照し、現在のサービス提供内容すべてに関する一貫した最新の情報を得ることができるようになっています。カタログによって、組織は各サービスのステータスをライフサイクルを通してモニタできます。

サービス・カタログ管理（SCM）プロセスは、サービス・カタログに含まれる情報が正確であり、定期的に更新され、サービス・カタログを必要とする人々がすぐに利用できることを確実にします。


プロセスの最終目標と達成目標を説明できる。 yプロセスの適用範囲を理解できる。 yプロセスの方針、原則、基本概念を説明できる。 yサービス・ライフサイクルと事業へのサービス・カタログの重 y要性を理解できる。ビジネス・サービス・カタログと技術サービス・カタログの違 yいを明確に理解できる。サービス・ポートフォリオ管理（SPM）とのインタフェースを理 y解していることを実証できる。プロセスに関連する主要な測定基準、課題、重要成功要因 y

（CSF）、およびリスクを理解できる。他のプロセスや機能によるサービス・カタログの利用を説明 yできる。サービス・カタログを作成できる。 y



My N otes

3.1　目的、最終目標、達成目標

目的：合意されたすべてのサービスに関する単一の情報源を常に y提供する。承認された顧客がサービスを広く利用およびアクセスできる yようにする。

最終目標：サービス・カタログが正しく作成および維持されるようにす yる。サービス・カタログに、現在運用中のサービスと提案されて yいる運用サービスすべてに関する正確な情報を含むようにする。

達成目標：

サービス・カタログ内の情報を管理する。 y情報が正確で、現行サービスと計画されているサービスを反 y映するように徹底する。



My N otes

3.2　プロセスの適用範囲

適用範囲SCMの適用範囲には、運用中のサービスと提案されたサービスに関する正確で一貫した情報を提供し、維持することを含みます。

SCMの活動は次のとおりです。

サービスの定義 y正確なサービス・カタログの作成および維持 yサービス・カタログとサービス・ポートフォリオの間のインタフ yェース、依存関係、および一貫性サービス・カタログおよびCMS内のすべてのサービスと支援 yサービスの間のインタフェースおよび依存関係サービス・カタログおよびCMS内のすべてのサービスと、支援 y的なコンポーネントおよび構成アイテム（CI）との間のインタフェースと依存関係

（出典：『サービスデザイン』）



My N otes

3.3　方針、原則、基本概念

組織のITインフラストラクチャは長年にわたって拡大し発展しているので、利用可能なサービスの範囲について組織内でもわからなくなっているかもしれません。組織内のすべての人がどのサービスが利用可能かを把握できるように、組織はサービスに焦点を当てたカルチャを醸成する必要があります。各サービス・プロバイダは、すべての不可欠なサービス関連情報を一元的に提供するために、サービス・カタログを含むITサービス・ポートフォリオを作成し、維持する必要があります。サービス・プロバイダは、明確に定義されたSCM方針を策定する必要があります。サービス・ポートフォリオには、サービスに対する将来の要件に関するすべての情報を含める必要があります。

サービス・カタログには次のものを含めます。

稼働中および提案されたすべてのサービスの詳細 yサービスの顧客と保守管理者の詳細 yサービスの主な特徴の要約 y

サービス・カタログの作成サービス・カタログを作成するには、次のことなどを行います。

古い文書とプログラム・ライブラリの検討 y調達レコードの調査 yITスタッフ、顧客、サプライヤ、委託先との会話 y

構成管理システム（CMS）や資産データベースも役に立つ場合があります。すべての情報は、検証してから使用してください。サービスストラテジはサービス・ポートフォリオの作成に責任を負いますが、サービスデザイン、サービストランジション、サービスオペレーション、継続的サービス改善（CSI）もこのプロセスに関与させる必要があります。

SCMはサービス・カタログを維持し、すべての現行サービスおよび計画されているサービスのステータスと、各サービスに関連する詳細が一元的に記録されるようにします。

サービス・カタログの内容多くの場合、ITスタッフは「サービスとは何か？」という基本的なことを明確には理解していません。

ITスタッフは「サービス」をITシステムと見なしています。このような混乱を避けるには、顧客が利用するITサービスや、そのサービスが彼らのビジネス・プロセスをどのようにサポートするかについて、顧客に尋ねると有益です。各組織は、事業の特定の状況内でサービスとは何かを明確に定義する方針を決める必要があります。

サービス・カタログ内のサービスを明確に階層化することも有益でしょう。このためサービス・カタログでは、顧客に見えるビジネス・サービ



My N otes

スか、顧客に見えない支援サービス（インフラストラクチャ・サービス、ネットワーク・サービス、アプリケーション・サービスなど）かといった、記録されるサービスの種類を指定する必要があります。

それを指定したら、サービス・カタログの内容を示すためのマトリクス、表、またはスプレッドシートを作成できます。多くの組織では、サービス・ポートフォリオとサービス・カタログは変更管理の一部になっています。各サービスを構成アイテム（CI）として定義し、それらを結び付けてサービス階層を作成することによって、組織はインシデントおよび変更要求（RFC）に、影響を受けるサービスを関連付けることができます。こうすることで、統合されたツールを使用する独自のモニタリングと報告の仕組みが作成されます。そうすると、サービス・ポートフォリオとサービス・カタログの変更が変更管理で扱われるようになります。

ビジネス・インパクト分析（BIA）の準備など、他のサービスマネジメントの目的のためにサービス・カタログを利用することもできます。カタログは基礎となる技術コンポーネントと関係がある多目的ツールであるため、維持にかかる費用と労力は容易に正当化できます。BIAの優先度付けを用いて維持すると、最も重要なサービスが最初に対処されるようにできます。

なぜサービス・カタログは重要な文書なのか

サービス・カタログが重要な文書であるのは、提供されるサービス一式に関する貴重な情報を含んでいるからです。また、サービス・カタログは非常に貴重な情報源であるため、組織内の誰でも利用できるようにするべきです。組織は、新規サービスの要件を定義して文書化し、合意したら、そのサービスをサービス・カタログに確実に記載するようなプロセスを備えていなければなりません。サービス・カタログには、各サービスに定義されたライフサイクルの各段階における、サービスのステータスも記録するべきです。



My N otes

3.4　サービス・ライフサイクルと事業にとってのサービス・カタログの重要性

サービス・カタログは、クライアントのために、1つまたは複数のサービスからカスタマイズした解決策を作成するのに役立ちます。顧客の特定の要件を満たすために、さまざまなサービスを組み合わせて価格設定したものをカタログに提示できます。

多くの顧客は、プロバイダが将来的にではなく、現在何を約束できるかということにのみ興味を示します。サービス・カタログは、そのような顧客からサービスを受注し、顧客または市場の需要を管理するうえで重要な役割を担っています。

サービス・カタログ内では、サービスは次のように記載されています。

コンポーネントに分解されている。 y資産、プロセス、および仕組みが、使用と配備のためのエント yリ・ポイントとともに紹介される

サービス・カタログは、顧客またはターゲット市場に対するサービス・プロバイダの運用能力を表すものです。

サービス・カタログは、意思決定のための有益な視覚化ツールでもあります。サービス・カタログは、顧客の需要とその需要を満たすサービス・プロバイダの能力を結び付けます。この2つが一致すると、サービス契約またはサービス合意が結ばれます。

サービス・カタログと需要管理カタログの中では、サービスに対するすべての需要が、それを満たすキャパシティに結び付けられます。需要源は、事業成果に結び付けられている顧客資産です。需要には、有用性と保証に対する期待が伴います。カタログのいずれかのアイテムがそれらの期待を満たす場合、サービス契約または合意が交わされます。カタログ内のアイテムは、サポートする共通の事業活動パターン（PBA）に基づいて、サービス・ライン（LOS）へとグループ化されます。

十分なパフォーマンスを発揮しているLOSには、次のために追加のリソースが割り当てられます。

パフォーマンスが一貫しているようにする。 yそれらのサービスへの需要の増加を予測する。 y



カタログ内のアイテムが財務上のしきい値を超えるパフォーマンスを持つ場合、そのサービスは存続可能と見なされます。次によって、サービスの人気度を上げることができます。

新しい属性 y新しいサービスレベル・パッケージ（SLP） y需要源との一致の向上 y新しい価格設定方針 y

サービスのパフォーマンスがしきい値未満になると、サービスは廃止対象になります。

組織は財務パフォーマンスの低いサービスでも、改善のためにカタログ内に残す決断をすることもできます。

サービス・カタログの一部サードパーティやアウトソーシングによるサービスは、サービス・カタログの一部である場合があります。これらのサービスは、さまざまなレベルの価値付加とともに、または他のカタログ・アイテムとの組み合わせによって顧客に提供されます。

サードパーティ・カタログは次のもので構成されます。

コアサービス・パッケージ（CSP） yサービスレベル・パッケージ y

製品マネージャー

人気のあるサービス

存続可能なサービス

段階的に停止するサービス

サービス・ライン


関係マネージャ

需要源

十分に満たされている需要

あまり満たされていない需要

全く満たされていない需要

製品マネージャー

人気のあるサービス

存続可能なサービス

段階的に停止するサービス

サービス・ライン


関係マネージャ

需要源

十分に満たされている需要

あまり満たされていない需要

全く満たされていない需要



この種のサードパーティ・カタログは、顧客とターゲット市場の面からサービス・カタログの適用範囲を拡張します。サードパーティ・サービスは、次のような目的で使用されます。

サービス・パイプライン内のアイテムが段階的に運用に移行されるまで、あまり満たされていない yか、全く満たされていない需要に対処するため。カタログから除外されるサービスの代替として。 y

ビジネス・サービスマネジメントビジネス・サービスマネジメント（BSM）とは、ITコンポーネントを事業の最終目標に関連付けることを推進する戦略で、事業への技術のインパクトと、技術への事業変更のインパクトの両方を予測できるようにします。事業部門、プロセス、サービス、それらとITサービスとの関係や依存関係も含めた、統合されたサービス・カタログを作成すると、ITサービス・プロバイダがBSMを提供する能力を強化することに役立ちます。

サービスデザインは、ITサービス・プロバイダのBSMの能力、特にサービス・ポートフォリオ、サービス・カタログ、および個々のITサービスの設計に中心的な役割を担います。これらの活動も、事業やその変化するニーズにITサービスが沿っているようにするのに役立ちます。

事業に対する価値

ITIL

ビジネス・サービスマネジメント

ITサービスマネジメント

ITシステム管理

事業活動

IT活動

インフラストラクチャとアプリケーション

の活動

技術リソース

事業に対する価値

ITIL

ビジネス・サービスマネジメント

ITサービスマネジメント

ITシステム管理

事業活動

IT活動

インフラストラクチャとアプリケーション

の活動

技術リソース



My N otes

ITサービス・プロバイダ組織は、BSMを使用して次のことができます。

事業の達成目標へのITサービス供給の整合 y重要なビジネス・プロセスとサービスに最大の注意を払うよ yうにするための、事業へのインパクトと緊急度に従ったすべてのIT活動の優先度付けITの有効性の強化による、事業の生産性と採算性の増大 y適切なITガバナンスとコントロールによる、コーポレート・ガ yバナンスのサポートITインフラストラクチャの革新と利用による競争上の優位性 yの創出サービス品質、顧客満足度、およびユーザの認識の向上 y規制および法律上のコンプライアンスの確保 yITおよび情報資産の適切な保護の確実化 yITサービスが進化するビジネス・ニーズに沿っていることの確 y実化

サービス・カタログは、プロバイダのサービス提供内容に関する一元的な情報源となるため、事業にとって非常に重要です。つまり、サービス・カタログは、事業のあらゆる部分がすべてのサービスに関する正確で最新の情報をサービスの詳細やステータスとともに利用できるようにします。サービス・カタログは、現在提供されているITサービスに対する顧客の視点、その想定された使用、サポートされるビジネス・プロセス、顧客が期待できるサービスのレベルと品質を明らかにします。



3.5　ビジネス・サービス・カタログと技術サービス・カタログの違い

サービス・カタログには2つの側面があります。

ビジネス・サービス・カタログ ― 顧客の視点によるサービス・カタログを表します。これには、サー yビス・プロバイダのサービス提供内容の詳細と、それらのサービスが、サービスに依存するビジネス・プロセスとどのように結び付くかに関する情報が含まれます。また、よりプロアクティブなSLMプロセスの開発を支援し、それによってSLMプロセスはBSMにまで発展することができます。技術サービス・カタログ ― 顧客には見えませんが、ビジネス・サービス・カタログの基礎となりま yす。これには、プロバイダのサービス提供内容の詳細と、これらのサービスが関与する支援サービス、シェアード・サービス、コンポーネント、CIとどのように結び付くかに関する情報が含まれます。また、サービスに必要な支援技術と、コンポーネントに必要なサポート・グループを特定することによって、サービス、SLA、OLA、およびその他の基本となる合意やコンポーネント間の関係を明確にするのに役立ちます。


ビジネス・プロセス1



ビジネス・サービス・カタログ

サービスA サービスB サービスC サービスD サービスE

技術サービス・カタログ

サポート・サービス

ハードウェアソフトウェアアプリ

ケーションデータ





ビジネス・サービス・カタログ

サービスA サービスB サービスC サービスD サービスE

技術サービス・カタログ

サポート・サービス

ハードウェアソフトウェアアプリ

ケーションデータ

2つのカタログのうちいずれか1つしか持たない組織もありますが、統合されたサービスマネジメント活動とサービス・ポートフォリオの一部として、1つのサービス・カタログ内に両方を含めることが推奨されます。それは、ビジネス・サービス・カタログと技術サービス・カタログを組み合わせると、インシデントおよび変更が事業に及ぼす可能性があるインパクトを事業がより迅速に把握するのに役立つからです。



電子トランザクション

物流輸送費

物流

サプライ・チェーン

物流輸送物流

スケジューリング

調達

財務／税金

財務／予算業務

クライアント・サービス

クライアントのOSクライアントの

ハードウェアブラウザ

オフィス・システム

セキュリティ・サービス

権限認証

分散サービスディレクトリ

FTPワークフロー

XMLウェブ・メッセージング

ターミナル・サービス

サーバOSサービス

WindowsサーバUN IXサーバ

メインフレーム・サーバ

サーバ・ハードウェア・

サービスDell HP Sun IBM

ネットワーク・サービス

WANLAN

音声型統合型

データ・サービスSA PデータベースBWデータベース

ロジスティクス・

データベース抽出変換

読み込みアーカイブ／検索

OLA P

統合

サービスメッセージ

ファイルXMLホストEDI

情報サービス報告

通知ポータル

文書管理

SA P CRM販売／顧客情報

販売／委託販売／価格設定

販売／見積もり販売／パイプライン

SA P ERP財務総勘定元帳財務売掛勘定

財務買掛勘定販売／収益

販売／伝票発行処理

販売／請求処理運用／生産管理

調達／購買物流／在庫


物流輸送費

物流


物流輸送物流


調達

財務／税金







権限認証











WANLAN

音声型統合型





OLA P

統合




通知ポータル

文書管理










物流輸送費

物流


物流輸送物流


調達

財務／税金







権限認証











WANLAN

音声型統合型





OLA P

統合




通知ポータル

文書管理











3.6　サービス・ポートフォリオとのインタフェース

サービス・ポートフォリオはすべての顧客とターゲット市場に対してサービス・プロバイダが行う約束事項と投資を表しますが、サービス・カタログはこのサービス・ポートフォリオの一部となります。顧客はこのカタログを見ることができます。カタログは2種類のサービスで構成されます。

現在運用段階で実行されているサービス y承認され、既存顧客または見込み顧客にすぐに提供できるサービス y

もう一度サービス・パイプラインとサービス・カタログの図を見てみましょう。







顧客





廃止される

サービス












顧客





廃止される

サービス








サービス・カタログの支援的な仕組みの設計サービス・ポートフォリオは、サービス・プロバイダが従うすべてのプロセスをサポートするために利用される最も重要な管理の仕組みです。サービス・ポートフォリオとは、次のようなものです。

事業上の価値の面から、サービス・プロバイダのサービスを説明する。 yビジネス・ニーズとそれらのニーズに対するサービス・プロバイダの対応を明確化する。 y

サービス・ポートフォリオは、包括的なサービス・ナレッジ管理システム（SKMS）の一部を成し、CMSに文書として登録される必要があります。

事業部門A 事業部門B 事業部門C

ビジネス

プロセス

ビジネス

プロセス

ビジネス

プロセス

事業

ITサービス

サービスA

インフラストラクチャ

システム

ハードウェア

システム

ソフトウェアネットワーク環境

支援サービス

チーム

サポート・チーム

サプライヤ

サプライヤ

サプライヤ

支援サービス


サービスステータスオーナ

サービスA

サービスB

サービスC


ビジネス

プロセス

ビジネス

プロセス

ビジネス

プロセス

事業

ITサービス

サービスA


システム

ハードウェア

システム

ソフトウェアネットワーク環境

支援サービス

チーム


サプライヤ

サプライヤ

サプライヤ

支援サービス


サービスステータスオーナ

サービスA

サービスB

サービスC



My N otes

サービス・ポートフォリオには、組織内のあらゆるサービスとそのステータスを記載する必要があります。サービス・ポートフォリオ内のステータスの選択肢には、次のものを含める必要があります。

要件：新規または変更されるサービスについて概略的な要件 y一式が事業またはITから受領されている定義済み：新規サービスの要件一式がアセスメント、定義、お yよび文書化され、SLRが作成されている分析済み：新規サービスの要件一式が分析され優先度付け yされている承認済み：新規サービスの要件一式が完成され許可されて yいる制定済み：新しいサービス要件が伝達され、リソースと予算が y割り当てられている設計済み：新規サービスとその構成コンポーネントが設計さ yれ、必要に応じて調達されている開発済み：サービスとその構成コンポーネントが開発されて yいるか、場合によっては確保されている構築済み：サービスとその構成コンポーネントが構築されて yいるテスト：サービスとその構成コンポーネントがテストされてい yるリリース済み：サービスとその構成コンポーネントがリリース yされている運用中：サービスとその構成コンポーネントが稼働環境の中 yで運用状態にある廃止済み：サービスとその構成コンポーネントが廃止されて yいる


図の四角い枠に示されているように、顧客とユーザはサービス・ポートフォリオの中でも「制定済み」から「運用中」までのステータスにあるサービス、つまりサービス・カタログに含まれるサービスにのみアクセスを許可される。出典：『サービスデザイン』）



高

低

低高

保証

事業成果へのインパクトは低いが、確実性が高い（バランスの取れ

ていない価値）

?事業成果へのインパクトは高いが、確実性が低い（バランスの取れて

いない価値）

有用性

保証寄りの

高価値

バランス・ゾ

ーン

有用性寄りの

高価値

保証寄りの

低価値

有用性寄りの

低価値

高

低

低高

保証

事業成果へのインパクトは低いが、確実性が高い（バランスの取れ

ていない価値）

?事業成果へのインパクトは高いが、確実性が低い（バランスの取れて

いない価値）

有用性

保証寄りの

高価値

バランス・ゾ

ーン

有用性寄りの

高価値

保証寄りの

低価値

有用性寄りの

低価値

データ／サービスの種類アクセスの提供先

サービス・ポートフォリオ内で、「制定済み」から「運用中」までにあるサービス

（これらはサービス・カタログ内のサービスである。）

顧客およびユーザ

サービス・ポートフォリオ内のすべてのレコードサービスストラテジとサービスデザインの要員

サービス・ポートフォリオ内のレコードの一部サービス・プロバイダ組織の他のメンバ

SCMプロセスは、サービス・ポートフォリオ内のすべての詳細が正確かつ最新であるようにする必要があります。



My N otes

サービス指向アーキテクチャビジネス・プロセスとソリューションはサービス指向アーキテクチャ

（SOA）アプローチによって設計し開発するべきです。SOAアプローチは、「自己完結型」で再利用可能なサービスの開発を奨励することによって、組織に価値と機敏性をもたらすため、ITサービスの供給における有効性と効率性を改善するために広く利用されています。この種のアプローチは、事業のさまざまな領域で利用できる「シェアード・サービス」の開発を推進します。実際、ビジネス・プロセスを、事業の多くの領域で利用し共有できる共通の「パッケージ・サービス」に変換する企業が増加しつつあります。

このアプローチでは、ITは次のことを行う必要があります。

サービスとは何かの定義 yサービス間のインタフェースと依存関係の決定 yサービスを開発し定義するための標準の活用 y共通した技術とツールセットの利用 y 「シェアード・サービス」への変更のインパクトの理解 yIT要員が共通の用語を使用するように、SOAのトレーニング yを受けさせることの徹底。これによって、新規または変更されるサービスの導入とサポートが改善される。



My N otes

3.7　プロセスに関連する主要な測定基準、課題、CSF、リスク

SCMに関連するKPIは次のとおりです。

稼働環境で提供されているサービスおよび稼働環境に移行 yされているサービスの割合として、サービス・カタログ内に記録され管理されているサービスの数サービス・カタログに記載された情報と実際の状況との間で y検知された差異の数


使用する可能性があるその他のKPIは次のとおりです。

提供されているサービスに対する事業ユーザの認識。すなわ yち、運用中のサービスに対し、ビジネス・サービス・カタログで網羅している割合の増加サービスを支えている技術に対するITスタッフの認識 y

サービスをサポートするITコンポーネントに対し、技 o術サービス・カタログで網羅している割合の増加サービスデスクが稼働中のすべてのサービスをサポ oートするための情報にアクセスできていること。適切なサービス関連情報がないインシデントの割合によって測定される


SCMの課題、CSF、リスクSCMの主要な課題は、サービス・ポートフォリオの一部として正確で一貫したサービス・カタログを維持し、CMSとSKMSの一部としてビジネス・サービス・カタログと技術サービス・カタログの両方を統合することです。カタログとポートフォリオには、単独のスプレッドシートまたはデータベースを作成することから始めるとよいでしょう。その後、CMSとSKMSに統合することができます。このためには、組織内の全員がカタログとポートフォリオを一元的な情報源として使用し、その維持を支援する必要があります。これはサービス・ポートフォリオとサービス・カタログの標準化、および規模の経済によるコスト削減に役立ちます。

SCMの主なCSFは次のとおりです。

正確なサービス・カタログ y提供されているサービスに対する事業ユーザの認識 yサービスをサポートする技術に対するITスタッフの認識 y




My N otes

正確なサービス・カタログの維持に関係するリスクは次のとおりです。

不正確なデータ、および適切な変更コントロールの欠如 y運用プロセスでサービス・カタログがあまり利用されていな yいことによる、不正確なデータサービス・ポートフォリオ、IT、および事業からの不正確なデー yタサービス・カタログを維持するために利用するツールとリソ yース正確な変更管理情報および変更管理プロセスへのアクセス yが不十分CMSおよびSKMSへのアクセスとサポートが不十分 yポートフォリオとカタログの利用が不十分 y情報の詳細さの度合いがCMSとSKMSに一致していない y



My N otes

3.8　その他のプロセスと機能によるサービス・カタログの利用

SCMのプロセスの活動、手法、技法SCMの主要な活動は次のとおりです。

関係者とサービス定義を確立し、文書化する。 ySPMと調整して、サービス・ポートフォリオとサービス・カタロ yグの内容について合意する。サービス・ポートフォリオと併せて、サービス・カタログを作成 yし維持する。ビジネス・プロセスと、ビジネス・サービス・カタログ内の対応 yするITサービスとの依存関係に関して、事業継続性管理およびITサービス継続性管理（ITSCM）と調整する。ITサービスと、技術サービス・カタログにある支援サービス、 yコンポーネント、およびCIとの間のつながりに関して、サプライヤ、サポート・チーム、および構成管理と調整する。サービス・カタログ内の情報が事業とビジネス・プロセスに y一致しているようにするために、SLMおよび事業関係管理と調整する。

トリガ、インプット、アウトプット、SCMとのインタフェースSCMプロセスに関連する情報源は次のとおりです。

組織の事業とITの戦略、その他の計画、およびサービス・ポー yトフォリオからの現在と将来の要件に関する情報優先度、可能性のあるインパクト、リスクなど、各サービスに y関するBIAの情報サービス・ポートフォリオからの、新規または変更された事業 y要件に関する情報サービス・ポートフォリオ yCMS yその他のプロセスから受け取ったフィードバック y

事業要件とサービスの変更は、SCMのトリガとなります。その場合、主なトリガはRFCと変更管理です。例として、導入、変更、または廃止されるサービスが挙げられます。



My N otes

SCMのプロセス・アウトプットは次のとおりです。サービスの定義と文書化 yサービスの現在のステータスと要件を含む、更新されたサー yビス・ポートフォリオ現在および提案されたサービスの詳細とステータス、インタ yフェース、依存関係を含む、更新されたサービス・カタログ



My N otes

3.9　サービス・カタログの作成

サービス・カタログは、サービス・プロバイダ組織が提供するサービスの全範囲に関する一元的な情報源です。変更管理は、カタログを一連の「サービス」CIとしてCMS内で維持する必要があります。サービス・カタログは、組織の全員にとって非常に重要なリソースです。そのため、広く利用およびアクセスできるようにするべきです。組織が新規サービスの要件を特定し文書化したら、サービス・カタログにそれらすべてのサービスに関する情報を含める必要があります。カタログには、サービスの説明、サービスの種類などの詳細のほかに、各サービスのライフサイクルを通したステータスを記載する必要もあります。



My N otes


RMCはコロラド州デンバーに本社を置く大手通信会社です。米国西部に多くのサービスを提供しているこの会社は、最近新しいCIOを迎えました。通信／ケーブル市場が開放されたため、RMCはかつてないほどの厳しい競争に直面しています。新しいCIOは最近、サービス品質を通じた顧客満足度向上に成功した実績があることから、市場でのRMCの競争力を高めるために同様の成功をもたらすよう要請されました。このCIOは国際的なベストプラクティスに非常に詳しく、特にITILのプラクティスの導入による成功例を数多く見てきました。

RMCは、サービスを顧客に提供する方法だけではなく、自社の内部の事業部からどのように認識されているかということから、サービスの品質に注目する必要があることに合意しています。RMCでは事業とITの間に強固な関係がなく、今後の達成目標を満たすにはその関係が重要だと感じています。利害関係者は、顧客関係の構築の重要性は言うまでもなく、サービス指向アーキテクチャ（SOA）と、事業とITの整合に関する他の多くの重要な領域の必要性に関して、アナリストから話を聞いています。

これらの利害関係者は、SOAの価値と、RMCが成功するために取り入れる必要がある必須事項を幾つか説明するように、新しいCIOであるあなたに依頼しました。

どのように回答しますか？Q1.

SOAの価値アプローチはベストプラクティスと見なされておa) り、すべてのITサービスの供給における効率性と有効性を改善するために多くの組織で利用されています。顧客に見られる成果物だけでなく、内部に対するSOAの価値を確実に得るには、RMCは、次に示すITの必須領域に特に注意する必要があります。

サービスとは何かの具体的な定義と決定 o

サービス間のインタフェースと依存関係の理解と明 o確化

共通した技術とツールセットの利用 o

サービスの開発と定義のための標準の活用 o

サービス・ポートフォリオとCMS全体の一部として oの、正確かつ整備されたサービス・カタログの使用

SOAは「自己完結型」で再利用可能なサービスの開発を奨励b) することによって、組織に価値と機敏性をもたらします。これにより、広く分散しているRMCの環境の多くの領域で利用できるシェアード・サービスの開発において、柔軟なモジュール式のアプローチが推進されます。顧客に見られる成果物だけでなく、内部に対するSOAの価値を確実に得るには、RMCは、次に示すITの必須領域に特に注意する必要があります。



My N otes




シェアード・サービスへの変更のインパクトの調査と o理解



SOAの価値アプローチは、ビジネス・サービスマネジメントc) （BSM）戦略のサブプロセスで、ベストプラクティスと見なさ

れており、すべてのITサービスの供給における効率性と有効性を改善するために多くの組織で利用されています。顧客に見られる成果物だけでなく、内部に対するSOAの価値を確実に得るには、RMCは、次に示すITの必須領域に特に注意する必要があります。




シェアード・サービスへの変更のインパクトの調査と o理解



ITサービス供給を事業の最終目標および達成目標と整合さd) せるために、RMCでBSM戦略を採用することが不可欠です。これにより得られる価値は、RMCの広く分散したインフラストラクチャ全体でIT組織を連携および協働させることだけでなく、競争の激しい市場の需要にRMCが迅速に対応する準備をより入念にできることです。取り組みを継続して成功に導くために、RMCは次も実施する必要があります。

重要なビジネス・プロセスとサービスが最も注目を o集めるようにするための、すべてのIT活動、事業へのインパクト、緊急度の優先度付け

ITプロセスの効率性と有効性の強化による、事業の o生産性と採算性の増大


ユニット4


サービスレベル管理

Student | ITIL v3 Intermediate Certification Level | Service Level Management


My N otes

ユニット4：サービスレベル管理

概要サービスレベル管理（SLM）は、すべてのIT活動を評価するためのパラメータを設定するので、すべてのITサービス・プロバイダ組織にとって重要なプロセスです。SLMは、各IT活動のサービスレベル目標値および責任について交渉および合意し、それらをサービスレベル要件

（SLR）とサービスレベル・アグリーメント（SLA）に文書化する責任を負います。目標値の設定は、バランスを取る必要のある難しい作業です。目標値は、人々が最善を尽くすための動機付けとなるほど十分に困難なものでなければなりませんが、あまりに困難だと達成が不可能になってしまうからです。目標値はビジネス・ニーズに沿って設定する必要があります。そうすることで、提供されるサービスは事業達成目標の実現を支援し、顧客の期待を満たすようになります。SLMはまた、サービス・プロバイダが提供する実際のサービスの品質をモニタし、報告します。


プロセスの最終目標と達成目標を説明できる。 yプロセスの適用範囲を理解できる。 yサービス・ライフサイクルに対するプロセスの重要性と、それ yがビジネスにもたらす価値を実証できる。SLMの原則と基本概念を明確に理解できる。 yこのプロセスの主要な活動、手法、技法、およびサービス・ラ yイフサイクルとの関連を理解できる。プロセスの成果物について明確に理解できる。 ySLAに照らしてサービス・パフォーマンスをモニタする方法を y説明できる。プロセスに関連する主要な測定基準、課題、重要成功要因 y

（CSF）、およびリスクを理解できる。SLA、オペレーショナルレベル・アグリーメント（OLA）、および yレビュー・ミーティングの内容を明確に理解して実証できる。他のプロセスおよび機能とのインタフェースを理解できる。 y



My N otes

4.1　サービスレベル管理の目的、最終目標、達成目標

目的： IT組織全体を通して統一された一貫性のある方法で、現在の yサービスのパフォーマンスを評価および測定する。提供されるサービスを事業および顧客のニーズに一致させ yる。

最終目標：現在のサービスおよび提案済みのサービスが、合意されたレ yベルで提供されることを確実にする。プロアクティブな対策を開始してサービス品質を改善する。 y

達成目標：サービスレベルを説明、文書化、合意、モニタ、測定、報告、お yよびレビューする。事業と顧客との関係を改善する。 yすべてのITサービスに対して測定可能な目標値を設定する。 yサービス品質に関する顧客満足度をモニタし改善する。 y提供されるサービスのレベルに対して、顧客が明確で一義的 yな期待を持てるようにする。サービスレベルの改善にプロアクティブに対策を導入する。 y



My N otes


SLMの適用範囲SLMは、ITILサービス・ライフサイクルにおいて非常に重要な役割を持っています。SLMは、事業に対してはITサービス・プロバイダの代表となり、ITサービス・プロバイダに対しては事業の代表となるような定期的な連絡とコミュニケーションの場を、顧客と事業マネージャが持てるようにする必要があります。

このコミュニケーション・チャネルでは、次を対象とする必要があります。

運用中のサービス y新規または変更されるサービスに生じる可能性のある要件 y

SLMの責任は次のとおりです。

事業、顧客、およびユーザの期待とニーズを管理する。 yサービス品質をそれら当事者の期待に応えるものにする。 y既存のすべてのサービスに対してSLAを作成および維持し、 y提供されるサービスのレベルが、SLA内に記載された目標値を達成できるようにする。計画されているサービスまたは変更されるサービスすべての ySLRを作成し合意する。これらの指標は、サービスとコンポーネントがビジネス・ニーズに応じて設定された目標値を達成することを確実にする。

SLMプロセス：

事業との関係を構築する。 y既存のサービスの現在の要件、目標値、およびSLAの文書化 yと管理について交渉し合意する。計画されているサービスまたは変更されるサービスの将来 yの要件、目標値、およびSLRの文書化と管理について交渉し合意する。SLAの目標値に沿った適切なOLAを作成し管理する。 y基本となるすべてのサプライヤ契約とサプライヤ合意を、SLA yの目標値と整合するよう、サプライヤ管理と合同でレビューする。他のプロセスと連携して、サービス障害の予防、サービス・リ yスクの軽減、サービス品質の改善を行う。



My N otes

すべてのサービスに関する報告と管理、およびSLA違反と弱 yみのレビューを行う。すべてのサービスとプロセスの改善の管理、計画立案、およ yび実施のためのサービス改善計画（SIP）を推進および調整する。



My N otes

4.3　SLMの重要性と事業上の価値への貢献

事業上の価値へのSLMの貢献 SLMでは、ITサービスの適切な目標値について、事業の代表者すべてと話し合い、合意し、それらを文書化します。その後、提供されたサービスが合意されたサービスレベルと一致するかどうかを評価し報告します。SLMは、すべてのIT活動に関して、SLAおよびSLRにサービス品質の目標値と責任を定義し文書化するため、すべてのITサービス・プロバイダ組織にとって重要です。

これらの目標値がビジネス・ニーズを反映するものであれば、提供されるサービスは顧客およびユーザの期待を満たし、事業要件に従ったものになります。目標値がビジネス・ニーズに沿っていない場合は、サービスレベルが事業の期待と一致せず、問題が生じます。

従って、SLAは、合意されたレベルのサービス品質に関するサービス・プロバイダから事業への一種の保証となります。サービス・ポートフォリオとサービス・カタログは、SLMに必要なすべての情報を提供するため、SLMの成功はこれらの品質に大きく左右されます。

SLMは、サービスレベルの目標値やそれらの目標値の達成を追跡する管理データなど、サービスに関連するすべての課題を対象とした信頼できるインタフェースを事業に提供します。目標値を達成しなかった場合、SLMは、違反の理由に関するフィードバックと、この種の違反の再発防止のために取られた処置の詳細を提供する必要があります。このように、SLMは、顧客と事業の代表者の間の信頼関係を築くのに役立つ、信頼できるコミュニケーション・チャネルとなります。



My N otes

4.4　原則と基本概念

SLMプロセスSLMプロセスとは、SLAの作成に関与する複数のプロセスの総称です。それらのプロセスは次のとおりです。

SLAの計画立案 ySLAに関する調整 ySLAの作成 ySLAに関する合意 ySLAのモニタリング ySLAに関する報告 y

SLMには、サービスの達成度を定期的にレビューして、組織がサービス品質を費用対効果の優れたレベルに維持し、それを徐々に改善していることを確認することも含まれます。ただし、SLMは既存のサービスだけを考慮するのではありません。新しい要件を識別し、新規または変更されるサービスとSLAが、関連するビジネス・ニーズと一致するようにします。SLAはプロバイダと顧客の関係を管理する基盤となり、SLMは顧客、事業部門、または事業ラインのグループの要となります。

サービスレベル・アグリーメントSLAとはITサービス・プロバイダとIT顧客の間での書面による合意であり、重要なサービス目標値と両当事者の責任を定義しています。SLAは、当事者間の合意に重点を置かなければならず、一方が他方から賠償金を得る手段としてSLAを使用するべきではありません。ITサービス・プロバイダと顧客との間に純粋なパートナーシップが築かれるべきであり、その結果として相互に利益のある合意が達成されるべきです。そうでなければ、SLAは信頼性を失い、組織にはサービス品質の改善を妨げる「非難のカルチャ」がはびこります。

SLMのもう1つの重要な責任は、事業、内部サポート・グループ、外部のパートナーおよびサプライヤとのSLAのすべての目標値および測定値が、対応するOLAまたは契約でサポートされるようにすることです。SLAとOLAは、事業が必要とするレベルのサービスを定義し提供するために重要です。




ビジネスプロセス



事業

ITサービス

サービスA


システムハードウェア

システムソフトウェア

ネットワーク環境

支援

サービス

チーム


サプライヤ

サプライヤ

契約支援

サービス

データアプリ

ケーション





事業

ITサービス

サービスA


システムハードウェア

システムソフトウェア

ネットワーク環境

支援

サービス

チーム


サプライヤ

サプライヤ

契約支援

サービス

データアプリ

ケーション

オペレーショナルレベル・アグリーメントOLAは、ITサービス・プロバイダと、サービスの供給を支援する事業内の他の部門との間で交わされる書面による合意です。他の部門とは、例えば、空調を管理する設備部門や、ネットワーク・サービスを管理するネットワーク・サポート・チームなどです。OLAにも目標値を含め、支援活動の障害によってSLA内の対応する目標値が違反されないようにするべきです。



My N otes

4.5　主要な活動、手法、技法、サービス・ライフサイクルとの関係

SLMの活動

SLMの主要な活動は次のとおりです。

SLRにある新規または変更されるサービスの要件の判断、交 y渉、文書化、合意、およびサービス・ライフサイクルを通したこれらの要件の管理およびレビューと運用中のサービスに対するSLAへの落とし込みSLAの目標値に照らした、運用中のすべてのサービスに関す yるサービス・パフォーマンスの達成度のモニタと測定顧客満足度の照合、測定、改善 yサービス・レポートの作成 yサービス・レビューの実施、およびサービス改善計画（SIP）範 y囲内での改善の推進SLA、サービス適用範囲、OLA、契約、およびその他の基本とな yる合意のレビューと改定事業、顧客、および利害関係者との窓口および関係の構築と y文書化あらゆる苦情の記録、対処、解決のための手順、および賛辞の y記録と伝達のための手順の作成、維持、および運用すべての苦情と賛辞の記録と管理 yパフォーマンス管理を支援し、サービスの達成度を実証する yための適切な管理情報の提供SLM文書の最新のテンプレートと標準を利用できるようにす yることと、その維持




次の図は、主要な活動間のインタフェースを示しています。

事業部門A 事業部門B



サービス

新規サービスのSLRの要件についての決定、文書化、合意、およびSLAの作成

SLAに照らしたサー

ビス・パフォーマンスのモニタおよびサービス・レポート

の作成

サービス・レビューの実施および

SIP全体における

改善の推進

標準とテンプレートの文書化

サービス・カタログに関する支援および文書テンプレートの

維持管理

窓口と関係の構築および苦情と賛辞の

記録と管理

顧客満足度の照合、測定、改善

SLA、サービス適用

範囲、基本となる合意のレビュー

と改定

サービス・レポート


事業

契約

サプライヤ管理サプライヤサポート・チーム

事業部門A 事業部門B



サービス

新規サービスのSLRの要件についての決定、文書化、合意、およびSLAの作成

SLAに照らしたサー

ビス・パフォーマンスのモニタおよびサービス・レポート

の作成

サービス・レビューの実施および

SIP全体における

改善の推進

標準とテンプレートの文書化

サービス・カタログに関する支援および文書テンプレートの

維持管理

窓口と関係の構築および苦情と賛辞の

記録と管理

顧客満足度の照合、測定、改善

SLA、サービス適用

範囲、基本となる合意のレビュー

と改定

サービス・レポート


事業

契約

サプライヤ管理サプライヤサポート・チーム

SLAフレームワークの設計図では主な活動を個別の活動として示していますが、これらの活動は、すべての顧客とすべての事業領域に適用できる1つの全体的なSLMプロセスとして統合するべきです。では、この統合SLMプロセスを作成する方法について学習しましょう。

SLMは、組織のニーズに合わせて、すべてのサービスと顧客が網羅されるような方法で、サービス・カタログを使用しながらSLA体系を設計する必要があります。

SLAのフレームワークの設計には、数多くのアプローチがあります。次に3つのアプローチを挙げます。

サービスベースのSLA y顧客ベースのSLA yマルチレベルSLA y



My N otes

サービスベースのSLAこのSLAは、1つのサービスのすべての顧客を対象とします。これは単純なアプローチのように思われますが、異なる顧客が同じサービスに対して異なる形式を要求したり、インフラストラクチャの性質のためサービス提供時にサービスレベルがばらついたりする場合、問題が生じることがあります。

また、そのような合意に誰が署名するかについても問題となる可能性があります。サービスベースのSLAは、例えば電子メールや電話など、事業全体で共通のサービスレベルで提供されるサービスに適切です。ゴールド、シルバー、ブロンズなどのサービス階級を明確に定義して、異なる顧客のさまざまなニーズに、より良く対応するサービスベースのSLAを作成することもできます。

顧客ベースのSLAこのSLAは、特定の顧客グループとの間で締結され、その顧客グループが使用するすべてのサービスを対象とします。

すべてのサービスおよび顧客を重複することなく網羅できる場合は、サービスベースのアプローチと顧客ベースのアプローチを組み合わせてSLAフレームワークを設計できます。

特定サービスレベルのSLA

顧客レベルのSLAまたは事業部門レベルのSLA

企業レベルのSLA

特定サービスレベルのSLA

顧客レベルのSLAまたは事業部門レベルのSLA

企業レベルのSLA



My N otes

マルチレベルSLA

マルチレベル構造のSLAは、次の役割を果たします。

管理可能なサイズの確実化 y重複の防止 y頻繁な更新の必要性の低減 y

ただし、サービス・カタログと構成管理システム（CMS）内の関連する関係とリンクを維持するために、より多くの労力が必要となります。

多くの組織では、すべてのSLA、SLR、およびOLAの基礎として使用できる雛形またはテンプレートを準備しています。雛型はSLAの草案と並行して作成できます。そのようなテンプレートおよび標準を使用することによって、それらに基づいて作成されたすべての合意の一貫性を確保できます。同時に、合意の使用、運用、および管理がより簡単になります。

SLAには役割と責任を含めることができます。その際は、ITプロバイダ、IT顧客、および実際のユーザの観点を考慮します。

SLAは、混乱や誤解の余地を残さないように大変慎重に記述するべきですが、通常は法律用語を用いる必要はありません。簡潔で平易な言葉を使用することによって、すべての当事者がSLAを完全に理解できるようになります。起草にかかわっていない第三者に最終版の文書を読んでもらうことも役に立ちます。それによって、あいまいな部分が明らかになり、それらに対処できます。各SLAには、重要な用語をすべて定義した用語集も含めるべきです。

国際的に提供されるサービスの場合、異なる言語に翻訳しなければならない場合もあります。さらに、1つの言語で書かれたSLAの草案を、世界中のさまざまな地域に適合するよう、各地域でレビューしなければならない場合もあります。このステップでは、用語、形式、およびカルチャの違いを考慮します。

サービスが外部サービス・プロバイダによって別の組織に提供される場合、サービス目標値は、契約に含めることも、契約に添付されるSLAやスケジュールに含めることもあります。どのような文書を使用するにしても、設定される目標値は、提供されるサービスの関係と品質を決定するため、明確であいまいさのないことが重要です。

新規サービスの要件の決定、文書化、合意とSLRの策定新規サービスの要件は、サービスデザイン段階の初期に定義、文書化、および合意されるべきです。サービス・カタログを作成し、SLA体系に合意したら、最初のSLRを起草します。最初から顧客を巻き込んで取り組むことがベストですが、具体的な議論に入る前に、パフォーマンスの目標値および管理と運用の要件に関する概略の草案を事前に作成しておくべきです。この草案は、確定しないで、変更可能にしておく必要があります。



My N otes

SLRまたはSLAの初期の目標値を定義することは、非常に困難な場合があります。現実的な目標値を決定するには、すべてのプロセスが関与する必要があります。インシデントの目標値に関してはインシデント管理に相談でき、サービスの可用性およびパフォーマンスの目標値に関してはキャパシティ管理と可用性管理に相談できます。サービス保証期間を通してモニタされ調整されるパイロットSLAに、暫定的な目標値を含めることができます。

新規サービスのSLRも作成するべきです。SLRはサービスデザインで定義するべきであり、設計、開発、および調達の段階を通してテストや追跡に活用するべきです。サービスがそのサービス・ライフサイクルを進捗するに従って、SLRは徐々に絞り込まれ、初期サポート（ELS）期間中のパイロットSLAになります。パイロットSLAまたはSLAの草案は、サービスと並行して作成されるべきで、サービスの運用を開始する前に承認される必要があります。

初期の段階で要件を定義する場合には注意が必要です。キャパシティ、セキュリティ、可用性、および継続性に関する要件の決定には支援が必要となる場合があります。最終的な要件が、初期に示されたものと異なることもあります。求められているものと、達成可能かつ妥当な価格のものとの間の妥当なバランスを取るまでには、何度も交渉を繰り返す場合があります。そのため、サービス・ソリューションを毎回再設計することになるかもしれません。

新規サービスがスムーズに移行されるようにするには、そのサービスとサービス・コンポーネントに対するサポートの取り決めを計画立案し、形式化することも必要です。計画立案でサービスとそのコンポーネントの導入、展開、およびサポートに関するすべての課題を網羅するためには、変更管理と構成管理に関与を求めるべきです。既存の契約／OLAに特定の要件を含めるか、または新規の契約／OLAについて交渉しなければならない場合もあります。サポートの取り決めとエスカレーション・プロセスを、サービス・カタログも併せて、サービスデスクが認識するようにCMSに追加します。必要な場合は、サービスデスクおよび他のサポート・グループに対して初期トレーニングと実習を行って、実際のサポートが必要になる前にナレッジの継承を行っておきます。

新規サービスをサポートするには、より多くの従業員が必要となる可能性があります。サポート・グループは新規サービスによって課せられたさらなる業務に対処しなければならないため、働きすぎのサポート・グループに対する期待はほどほどにしておくべきです。

顧客、顧客の代表、およびサービス・プロバイダと交渉を行い、SLAおよびサービスレベルの初期目標値を最終決定する必要があります。そのような交渉では、合意の草案をたたき台にすることができます。



My N otes

4.6　成果物

SLMプロセスは次のことを行う必要があります。

サービス・レポートの作成 yサービス・レビューの実施と総合的なSIP内での改善の推進 y

サービス・レポートの作成SLAが合意に達したら、サービス・プロバイダはモニタリングを開始し、サービスの達成度についてレポートを作成しなければなりません。運用レポートは頻繁に、できれば毎週作成する必要があります。これによって、時間の経過による傾向情報が把握でき、組織はタイミング良く是正処置を実施することができます。また、SLAに違反した場合や、

「早期の警告」のしきい値が違反の可能性を示したときには、例外レポートを生成するべきです。新規サービスのELS期間中は、大量の変更要求（RFC）があるため、目標値は必然的に未達成となります。ELS期間中に処理されるRFCの数を制限することによって、変更のインパクトを最小限に抑えることができます。

SLAの報告の仕組み、間隔、およびレポートの形式を定義し、合意する必要があります。サービス・レビュー・ミーティングの頻度と形式についても同様です。レビュー・ミーティングは一定の間隔で実施し、レビュー・サイクルと同期した定期レポートを作成することがベストです。

レポートを定期的に作成し、サービスレベル・レビューの数日前に顧客および関連のあるITマネージャにそれを回覧する必要があります。これは、問い合わせや不一致をレビュー・ミーティングの前に解決するのに役立ち、レビュー・ミーティングでは重要な課題に集中することができます。

定期レポートには次を含める必要があります。

SLA目標値に照らしたパフォーマンス測定値の詳細 y傾向情報や、サービス品質を改善するために取られた処置に yついての情報

SLAMとは何か？サービス・レポートの最初にSLAモニタリング（SLAM）チャートを使用できます。SLAMチャートとは、レポートの内容をわかりやすく、見やすい方法で要約したチャートです。これらは、色分け（赤、黄、緑、つまりRAG）するとより一層使いやすくなります。OLAまたは内部パフォーマンスのレビューやサプライヤ管理または契約管理のために、ITマネジメントから他のレポートが要求される場合があります。

レポートの作成には多くのリソースと時間を要する場合があります。レポートには顧客の視点を反映するべきです。すべての領域およびプロセスから集められたデータを適切に記録および分析し、1つの包括的なレポートに作り上げる必要があります。



My N otes

可能であれば、SLMは、特定の報告ニーズを識別し、これらのレポートの作成を自動化するべきです。統合サポート・ツールを選択する際は、サポート作成の自動化における容易さ、範囲、および正確さを考慮します。レポートには、改善処置の成功を評価し、予測し、長期的な傾向を把握できるように、過去のパフォーマンスの詳細も含めるべきです。

レビュー・ミーティングの重要性顧客との定期的なレビュー・ミーティングでは、先期のサービス・パフォーマンスを追跡し、翌期に対する課題があればそれを確認するのを支援します。そのようなミーティングは毎月、あるいは少なくとも四半期ごとに開催します。

顧客とプロバイダは、目標値がいつも達成されない弱い領域を改善するために必要なすべての対策を取るべきです。ミーティングの議事録および処置計画は、次回のミーティングで進捗をレビューする際に役立ちます。

各サービスレベル違反について特別の注意を払い、その原因を追跡して再発を防止するべきです。サービスレベルがもはや達成不可能なものであるなら、サービス目標値をレビューおよび再交渉し、変更します。サードパーティまたは内部サポート・グループがサービスの違反を生じさせた場合は、関連するOLAと支援的な合意をレビューします。サービス違反のコストとインパクトの分析は、SIP活動と処置において非常に役立ちます。事業にとって最大の利益をもたらす可能性のある領域に改善の努力を集中します。

SIPの進捗レポートを作成することが不可欠です。そのようなレポートには、完了したSIP処置の数や、期待された利益を実現した処置の数などの要素を含めるべきです。

サービスレベル・マネージャの役割ほとんどの顧客とITサービス・プロバイダのスタッフはサービスレベル・マネージャをスパイと見なしているという事実を心に留めておいてください。これは、サービスレベル・マネージャが次の2つの役割を持っているからです。

ITスタッフに対しては顧客の代表者 y顧客と会話する際にはプロバイダの代表者 y

この認識の問題を克服するには、サービスレベル・マネージャは両者との関係においてできるかぎりオープンで協力的でなければなりません。ただし、同僚を公然と批判することのないよう注意が必要です。



My N otes

4.7　SLAに照らしたサービス・パフォーマンスのモニタリング

SLAに照らしたサービス・パフォーマンスのモニタリングSLAには、合意されたポイントでモニタまたは測定できないものを含めるべきではありません。これは、将来の揉め事と、SLMプロセスの信頼性喪失を避けるためです。パフォーマンスに対して測定可能なパラメータを設定しないと、企業の信用が損なわれると同時に、多大なコストを負担する結果となる場合があります。

すでに導入されているモニタリングの能力を定期的にレビューし、アップグレードするべきです。これは、SLAの起草中または起草前に行い、提案された目標値の妥当性確認を支援するためにモニタリングの仕組みを導入できるようにするのが理想です。

モニタリングは、サービスに対する顧客の視点と合致していなければなりません。これは非常に困難な場合があります。個々のコンポーネントをモニタリングすることが、顧客に対するサービスの可用性を必ずしも保証するわけではありません。ある障害が他のサービスにも影響を与えた可能性があったとしても、顧客は通常、インシデントが報告されたときに自分がアクセスしようとしていたサービスでの障害のみを考慮します。これには注意が必要です。エンドツーエンドのサービスとしてコンポーネントをモニタした場合にのみ、真の全体像を把握することができます。しかし、これを実現するにはコストがかかり、かつ困難です。さらに、サービス目標値に違反があった場合にサービス・プロバイダが警告を受けられるよう、ユーザはインシデントを直ちに報告する責任を負っていることをユーザ自身に認識してもらう必要があります。

モニタリングにおけるサービスデスクの役割多くの組織では、サービスデスクを利用して顧客の視点でのサービスの可用性をモニタします。これには、インシデント／問題を記録する画面に特定の変更を加えることや、インシデントを記録する手順を厳格に遵守することが必要となる場合があります。これらの課題に対しては、可用性管理プロセスを関与させて合意を得る必要があります。

サービスデスクは、インシデントの応答時間と解決時間のモニタにもよく使用されます。その場合も、データ収集に対応するために記録画面を修正する必要があるかもしれません。また、コールの履歴を取る手順を合理化し、それに厳密に従う必要があります。外部プロバイダがサポートを提供している場合は、サプライヤ管理も関与します。

SLAに含まれるインシデント／問題の取り扱い目標値はすべて、サービスデスク・ツールで使用される値、およびエスカレーションとモニタリングのプロセスで使用される値と同じにすることが必須です。そうでなければ、設定されたSLA目標値とは異なる値をモニタすることにな



My N otes

ります。その結果、データをかなり操作しないとSLA目標値が達成されたかどうかを示すことができず、モニタリング・プロセス自体が意味のないものとなってしまいます。サポート・ツールは、データ収集に必要なすべてのフィールドを含むように調整する必要がある場合があります。

画面を操作してから応答を受け取るまでの時間を示すトランザクション応答時間も、追跡が困難です。エンドツーエンドの応答時間を追跡することは、技術的に非常に難しい場合があります。そのような場合は、次のことを実行します。

SLAに次のような記述を含める。「このSLAが対象とするサー yビスは、高速な応答向けに設計されており、大幅な遅れが発生することはありません。x秒以上の応答時間の遅れがy分以上の間継続して発生した場合は、サービスデスクに直ちに報告してください。」報告期間内において、そのようなインシデントを何回まで許 y容するかの目標値に合意し、これをSLAに含める。「応答率の低下」というインシデント・カテゴリを追加する。そ yのようなインシデントがすべて正確に記録され、対応するサービスに関連付けられるよう徹底する。SLAトランザクション応答時間に違反した場合に定型のレポ yートを作成し、問題を修正するために問題管理を通じて調査を推進する。

この体系的なアプローチは、モニタリングの技術的な問題の克服に役立ちます。また、応答率の低下が即座に報告されることによって、遅延を発生させる一時的なイベントの相互作用が直ちにに検知され、調査されます。

サービスオペレーションの助言を得て、クライアント／サーバにおける応答時間の自動モニタリング・システムを導入することが理想です。可能であれば、低いパフォーマンスを示すサンプリング・ツールや「ロボット」ツールを実装します。そのようなツールでは、ユーザが体験する実際の応答時間が示されます。

SLAにRFCをアセスメントおよび実施するための目標値を含めた場合、変更管理が使用するのと同じツールを使って変更管理関連の目標値をモニタするべきです。また、変更記録画面とエスカレーション手順もこれに対応するようにします。

幾つかの組織においては、「応答率の低下」がサービスに対するユーザの認識の問題でもあることがわかっています。ユーザは特定のレベルの応答に慣れており、それを下回るとたちまち不満をもらします。「サービスが遅くなったとユーザが感じたら、サービスは遅いのだ」と認識するべきです。

SLMは、継続的サービス改善（CSI）の重要な原則です。以前は、多くのIT組織がSLAを、サービスの可用性やヘルプデスク・コールに関する独立した合意セットとして単純にとらえていました。しかしそれは事実ではありません。今日では、事業は、ITがサービス・モデルに従うことを要



My N otes

求しています。これにより、事業とITの間で信頼性の高いパートナシップを築きやすくなります。また、ITは、すべての重要なビジネス・プロセスを支援するようになっています。このことから、ITは各コミュニケーション・チャネルおよび意思決定プロセスの各レベルのすべてに関与する必要があります。そのため、現在ではSLMが不可欠なのです。

SLMのステップSLMには、次のようなステップが含まれます。

IT組織が事業に対するサービス・プロバイダにならなければ、 y不要となってしまうことを全面的に受け入れる。事業のサービスレベル要件を決定する。 y計画中、開発中、本番稼働中のサービスを含む、内部サービ yス・ポートフォリオを定義する。このサービス・ポートフォリオには、最終のサービス・パッケージの一部となるコンポーネント・サービスも含まれる。ITがオプション、パラメータ、および価格設定とともに提示す yるあらゆるサービスとサービス・パッケージの詳細を示す、顧客向けのサービス・カタログを定義する。内部IT部門の関係を識別し、その関係における条件と責任に yついて合意し、それらをOLAに文書化する。外部ベンダとの契約上の関係を識別し、変更されたビジネ yス・ニーズを外部委託契約（UC）が満たしているかを検証する。満たしていない場合は再交渉する。サービス・カタログをベースラインとして活用し、SLAについ yて事業と交渉する。サービスレベルを定期的にモニタし、改善するために、SIPを y準備する。

IT組織は、SLMを導入し始めるとすぐに、「成功するIT」の古い定義がもはや当てはまらないことに気付きます。ネットワーク可用性の高いパーセンテージや顧客満足度調査での好成績は、もはや最終目標ではなく、サービスレベルの目標値を認識するのに役立つ肯定的な測定基準にすぎません。そこでITマネジメントは、SLMが根本的な変化の1つであることに気づきます。今では最終目標は、顧客と事業の両者によって合意されたサービスレベルなのです。そうしてITは、そのサービスレベルを満たすかあるいは超えるために、構成され、運用され、管理されます。サービスレベルは、すべてのIT活動が達成を目指さなければならない究極の最終目標です。



My N otes

4.8　主要な測定基準、課題、CSF、リスク

重要業績評価指標重要業績評価指標（KPI）および測定基準は、SLM活動の成功を評価し、SIPの進捗をモニタするために使用できます。これらの測定基準は、サービス、顧客、および事業の観点を反映していなければなりません。測定基準には次のものを含むべきです。

客観的測定値 y主観的測定値 y

客観的測定値測定基準では次の客観的測定値を網羅するべきです。

満たされているサービス目標値の数または割合 yサービス違反の数と重大度 y更新されたSLAがあるサービスの数 y適時のレポートと定期的なサービス・レビューのあるサービ yスの数

主観的測定値測定基準では、顧客満足度の改善を通じた主観的測定値を網羅するべきです。

SLMはSIPのベースとして適しています。SIPを推めるのはサービス・レビュー・プロセスですが、組織のすべてのプロセスおよび領域がSIPに貢献します。

サービス品質に影響する何らかの問題を識別したら、SIPを開始して、その問題を解決しサービス品質を回復させるのに必要な処置を識別し、実施しなければなりません。このプロセスにはプロジェクト管理と可用性管理が関与させます。SIPには、ユーザ・トレーニング、サービスとシステムのテスト、および文書化のプログラムも含めることができます。そのような場合、適切な人材を関与させ、将来の改善のために十分なフィードバックを行います。複数のサービスでの問題に対処するために、複数の異なるSIPの取り組みを並行して行うこともできます。

多くの組織では、SIPの取り組みにSLM予算をあてています。これにより、迅速な処置ができ、SLMが明らかにうまく機能します。SIPを維持して管理し、すべての改善処置について、サービス、顧客、および事業への潜在的なリスクとインパクトをアセスメントする必要があります。その後、それらの改善処置を優先付けし、スケジューリングし、実施します。このプロセスを拡張して、SLMをよりプロアクティブで先見的なものにします。



My N otes

サービス提供をアウトソーシングする場合、必ず、最初からサービス改善の課題について議論しておきます。議論では、サービス改善の取り組みの手順や、それらの取り組みの資金調達についても取り上げます。これらすべてをサプライヤとの契約の中に記述しておくべきです。サプライヤは、契約で要求されていないかぎり、追加の費用を負担してサービスを改善することはしません。

KPI全体的なITサービス品質を管理するためのKPIは次のとおりです。

達成できなかったSLAの目標値の削減率 y達成が危ぶまれたSLAの目標値の削減率 yサービス・レビューおよび顧客満足度調査の回答を通じ yた、SLA達成に関する顧客の認識と満足度の増加率サードパーティとのサポート契約（外部委託契約）に起因す yる、SLA違反の削減率内部のオペレーショナルレベル・アグリーメント（OLA）に起因 yする、SLA違反の削減率


合意されたサービスを妥当なコストで提供するためのKPIは次のとおりです。

適切に文書化されたSLAが実施されている総数および増加 y率すでに実行されている運用中のサービスに対して合意され yたSLAの増加率サービス供給に関連するコストの削減率 ySLAのモニタリングおよび報告のコストの削減率 y適切なSLAの策定と合意の速度の向上率 yサービス・レビュー・ミーティングの頻度 y


事業インタフェースを管理するためのKPIは次のとおりです。

SLAの対象となるサービスの増加率 ySLMのプロセスおよび手順の文書化と合意 ySLA要求に対する応答時間と対応時間の短縮 y予定どおりに完了したSLAレビューの増加率 y年次再交渉を行っていないSLAの削減率 y達成不可能な目標値など、変更が必要なSLAの削減率 y



My N otes

複数の契約を統合することで整備したOLAおよびサードパー yティ契約の範囲の増加率サービス・レビューおよびSLAレビューで提起された問題が y追跡され解決されていることの書面による証拠の増加SLA違反の数および重大度の減少 yあらゆるSLA、OLA、および外部委託契約（UC）の違反に関す yる適切なレビューとフォローアップの増加

SLMは、サービスの目標値、達成度、違反など、既存のすべてのサービスに関する重要な情報を提供します。SLMは、サービス・カタログ管理がサービス・カタログを管理するのを支援します。顧客からの苦情や賛辞など、顧客満足度に関する情報と傾向を提供します。

SLMはサービス品質に関する重要な情報と、顧客の期待および視点を提供します。この情報は、組織の誰もが入手できるようにしておく必要があります。

SLMの課題SLMの主な課題は、適切な顧客の代表者を識別することです。適切な顧客の代表者がわかれば、1人のサービス・マネージャが合意に署名できます。しかし、場合によっては、誰がサービスを「所有」するのかがはっきりしないことがあります。その場合、「有志」の代表者を苦労して見つけなければばらない場合があります。その「有志」の代表者は、常に総意を代表するとはかぎらず、時には個人的見解を表明する場合があることに注意してください。ほかに誰も見付からなければ、その顧客に署名させます。

顧客の代表者に最適なのは、広範な領域の顧客と定期的に交わり、顧客コミュニティの視点を正確に表すことができる人です。本社にいる代表者が必ずしもこの条件を満たしているとはかぎりません。最後の選択肢としては、SLMが独自に顧客と議論し、顧客の真のニーズをつかみます。

SLMのCSFSLMの主なCSFは次のとおりです。

全体的なサービス品質の管理 y合意されたサービスの妥当なコストでの提供 y事業およびユーザとのインタフェースの管理 y

SLMのリスク主なリスクには次が含まれます。

事業および顧客からのインプット、参加、およびコミットメント yの不足合意およびサービスレベルの合意、文書化、モニタ、報告、レ y



My N otes

ビューに必要なツールとリソースに関する問題プロセスがプロアクティブではなく、官僚的なものになった場 y合の、SLMから得られる測定可能な利益の不足適切なCMSおよびサービス・ナレッジ管理システム（SKMS）へ yのアクセスとサポートの不足定義済みSLMプロセスの欠如 y事業と顧客の測定値がその複雑さのために記録できないこ yと事業と顧客との間に不適切な窓口および関係が生まれること y顧客の期待が理不尽なほど高く、低い認識を招くこと y事業と顧客とのコミュニケーション不足 y

SLMのヒントと助言初めてサービスレベルに関する議論を開始する際には、「現在の課題」

（前日に発生した障害）や、長年にわたる不満（何年も前から交換を訴えている旧式のプリンタ）について最初に並べ立てられる傾向があるため、注意するべきである。そのような課題も重要かもしれないが、そのようなことが、長期的な要件の設定の妨げになってはならない。しかしながら、先に進むためのあらゆる信用を得るには、最初に挙げられたあらゆる課題に対処することも必要かもしれないということに留意すること。大きな問題を抱えている領域を最初のSLAとして取り上げてはならない。何らかの利点を迅速に示し、かつSLMプロセスを発展させそうな領域を取り上げるようにすること。成功ほど、新しいアイデアの迅速な受け入れを奨励するものはほかにない。企業レベルで安易な目標値を採用してはならない。そのような目標値は簡単に達成できるかもしれないが、サービスの品質または信用の改善には何ら価値がない。また、目標値が十分に高いレベルに設定されている場合、すべての新規サービスが達成するべき標準として企業SLAを利用できる。


SLMを導入する際は、SLA草案から開始します。その草案に対してどの顧客またはサービスを使用するかを決定します。選ばれた顧客が参加に興味を示している場合は有益です。その顧客がサービス品質の改善に熱心であると考えられるからです。初期段階で顧客の認識調査をすると、最初のSLA草案の起草に非常に役立ちます。

最初のSLAでは、迅速に結果が出る領域を選び、そこからSLMプロセスを構築していくとよいでしょう。初期の成功によって、SLMの導入に対する抵抗に先手を打てます。



My N otes

SLMプロセスで直面する別の問題は、顧客コミュニティのさまざまな階層の従業員が、それぞれ異なる視点や達成目標を持っていることです。例えば、下位のスタッフは自分たちが毎日使用するサービスの応答性、ユーザビリティ、信頼性により興味を持っています。一方、上級マネージャはサービスのコストや価値をより考慮します。すべての階層での重要な顧客要求をすべて識別し、SLAに織り込む必要があります。ある組織では、すべての課題に対処するために、顧客コミュニティ内のさまざまな階層から成るフォーカス・グループを組織しています。これにはより多くのリソースを必要としますが、非常に有益です。

内部か外部かにかかわらずプロバイダの代表者にも、このプロセスの間に意見を求めるべきです。彼らが、目標値が達成可能であり、またコストが妥当であることに合意する必要があります。合意しない場合、すべての当事者が受け入れ可能な妥協案に達するまで、さらに交渉します。また、交渉の間に、契約上の義務を考慮するためにサプライヤの視点も確認します。

過去のモニタリング･データを利用できない場合、目標値が達成可能であることをモニタリングで確認できるまで、最初の期間は合意を草案の形式のままにしておきます。場合によっては、目標値を再交渉する必要があるかもしれません。多くの組織では、ITがサービス目標値を最終決定するまでの時間枠を交渉します。目標値と時間枠が合意に達したら、SLAに署名しなければなりません。

SLA草案での初期の問題を解決したら、他のサービス／顧客に対して段階的にSLAを導入していきます。マルチレベル体系を採用した場合、最初のSLAにおいて、すべてのサービスを対象として企業レベルの課題に対処しなければなりません。この段階で企業の課題をテストします。

安易な企業目標値を設定するという誘惑に屈しないようにしてください。そのような目標値はたとえ達成できたとしても、サービス品質や信用を改善するものではありません。高い企業目標値は新規サービスの標準を高める効果もあります。

交渉と起草のプロセスが終了したら、顧客とプロバイダ両方の関連するすべてのマネージャがSLAにサインするよう徹底します。これにより、合意を満たすための両者のコミットメントが強固なものとなります。一般的には、署名者の職位がその組織の中でより高位であるほど、SLA内のコミットメントのメッセージはより強固になります。SLAが合意されたら、顧客、ユーザ、およびITスタッフの間に公表し、SLAの存在と決められた目標値を全員に確実に認識させます。

サービスデスクと他のサポート・グループに、新しいSLAとOLAの存在について、特にそれらの運用開始時期について公示するための措置を取ります。これらの合意から重要な目標値を抽出して表を作成し、サポート領域で掲示するとよいでしょう。それによって、業務において目指す目標値をスタッフが常に意識することになります。可能な場合、これらの目標値をサービス・カタログやCMSなどのサポート・ツールに含めて、全員が参照できるようにします。また、目標値をしきい値として設定し、目標値が違反されそうな場合や実際に違反された場合に自動的に警告を出すべきです。SLA、OLA、およびそれらの目標値もユ



My N otes

ーザ・コミュニティの間で公表し、ユーザがサービスに何を期待できるか、そしてどの時点から不満を表現できるかを認識できるようにするべきです。

サービスデスクのスタッフは、顧客のインシデント、苦情、および問い合わせに対する最初の窓口であるため、SLMプロセスに取り組み、SLAを公表するのを支援するべきです。サービスデスクのスタッフがSLAの内容について認識していないと、顧客はSLAをほとんど信頼しなくなります。



4.9　SLA、OLA、レビュー・ミーティングの内容

基本となる合意とサービス適用範囲のレビューと改定

ITサービス・プロバイダは、内部の技術サポート・チームか、外部のパートナまたはサプライヤにある程度依存しています。サポート・チームとサプライヤがそれぞれの基本となる目標値を目指さなければ、ITサービス・プロバイダはSLAの目標値を達成できません。外部サプライヤとの間では契約を交わしますが、多くの組織では、内部サポート・グループと簡単な合意であるOLAを交わします。基本となるOLA、SLA、および契約はすべて「基本となる合意」と呼ばれます。

これらの合意はしばしば「表裏一体」の合意と言われ、これらの合意の中の目標値が、事業との間で交わされたSLAとOLAで合意された目標値と整合していることを表しています。基本となる合意には複数の層が存在する場合があります。各層の目標値を、それより高い層の目標値（つまり事業の目標値により近い目標値）と必ず整合させます。

OLAに関する注意事項OLAはシンプルであるべきです。 ySLAに含まれる目標値を支えるような、それらと表裏一体の、サポート・グループに対する特定の目 y標値を含めます。

SLAに関する注意事項SLAには、コールへの応答、技術サポート・スタッフへのインシデントのエスカレーション、およびそ yのインシデントを調査し解決するためにかかる時間を含める必要があります。また、SLAのサービス提供時間を支えるすべてのグループに対する、全体的なサポート時間が含ま yれていなければなりません。さらに、例えば時間外の電話サポートなど、契約スタッフに対する特別な手順があれば、それも含 yめます。

OLAとSLAのレビューのベストプラクティスサービス・プロバイダは、OLAとSLAの両方の目標値と照らしてOLAをモニタし、フィードバックとして、達成に関するレポートをすべてのサポート・チームの適切なマネージャへ提供するべきです。これによって、問題のある領域が明らかになります。そのような領域が識別されたら、問題は内部で、あるいはSLAまたはOLAをレビューすることによって対処できます。運用サービスを可能にしているすべての内部サポート・チームに、正式なOLAを導入することを検討してください。

新規または変更されたSLAがある場合、既存の契約を確認し、必要に応じてそれらをアップグレードしなければなりません。これにかかるコストはITで負担するか、または顧客に配賦します。後者の場合、顧客が追加のコストを負担することに合意しなければなりません。合意しない場合、既存の契約内の目標値を軽減したものをSLAに含めることに合意するべきです。これにはサプライヤ管理プロセスを関与させる必要があります。SLM要件以外の、その他すべてのプロセスの要件、特にサプライヤおよび契約上の方針と標準を考慮する必要があるためです。

最後に、少なくとも年に一度はすべての合意と契約を定期的に更新およびレビューし、それらがすべて現在



My N otes

も有効で、ビジネス・ニーズと戦略に沿っていることを確認しなければなりません。すべての合意と契約は、構成管理のコントロール下に置くべきです。

レビューでは、対象のサービスとそれぞれの目標値がまだ適切であるかどうかを確認します。また、何らかの形で合意を無効とするような、インフラストラクチャ、事業、サプライヤの変更などの重大な変更がなかったかを確認します。変更が必要となった場合、変更管理のコントロールの下で合意を更新します。すべての合意を構成アイテム（CI）としてCMS内に記録しておくと、変更のインパクトをアセスメントし、コントロールされた方法で変更を実施することがより容易になります。

これらのレビューでは、全体的な戦略を記載した文書も対象とします。これによって、すべてのサービスとサービス合意が事業とITの戦略および方針と一致します。



4.10　他のプロセスおよび機能とのインタフェース

顧客満足度の照合、測定、改善サービスデザインの適用範囲の図は、ビジネス・プロセスと、ビジネス・ニーズを満たすのに必要なサービス、技術、支援サービス、グループ、およびサプライヤとの関係を示しています。

SLA自体はサービス品質を改善するものではなく、単なる文書です。ただし、早期に利益をもたらすサービス・カルチャを育成する可能性があります。長期的な視点に立ち、期待しすぎないようにしましょう。

顧客の管理顧客の感情など、多くの事柄は客観的または体系的な手段で測定することができません。複数のサービス障害があった場合でも、顧客はサービス・プロバイダが改善に必要な手順を行っているだろうと考えて、なおもサービスに満足しているかもしれません。その逆も同様です。顧客は、例えばSLA目標値の違反があったりすると、サービスデスクの一部のスタッフに対して不満を感じることもあります。



My N otes

顧客の期待に対処する方法

顧客の期待には最初から対応することがベストです。そのためには、サービス・プロバイダは最初に適切な期待と目標値を設定し、将来の期待を管理するための体系的なプロセスを整備しなければなりません。

「満足＝認識－期待」です。これが、ゼロまたは正の数の場合、顧客が満足していることを意味します。

サービスに対して課金している場合、顧客は変更を要求します。顧客は承認された予算の中で、合意された企業戦略に沿って必要なサービスを調達しているからです。直接的な課金が発生しない場合は、ITプロバイダが特定の顧客グループからの非現実的な要求に対処しなくてもよいように、上級事業マネージャの関与を求めるべきです。

顧客の認識のような「ソフト」面の課題をモニタするには、次のような方法があります。

定期的なアンケートと顧客調査 yサービス・レビュー・ミーティングによる顧客からのフィードバ yック変更管理プロセスの一環として行われる、重大な変更、リリー yス、新規または変更されたサービスなどに対する実施後のレビュー（PIR）からのフィードバックサービスデスクでの無作為抽出、または顧客代表者による電 y話での認識調査インストール、サービス訪問などの後に顧客に渡す満足度調 y査書顧客からの苦情と賛辞の分析 y

これらの方法に対して目標値を設定し、SLAの一部としてモニタします。例えば、サービス・パフォーマンスを1から5の範囲で評価します。ユーザからフィードバックをもらった場合は、ユーザのコメントが何らかの処置計画（たいていの場合はSIP）に含まれていることを示すものをユーザに提供するようにします。顧客満足度のすべての測定値は定期的にレビューするべきです。何らかのばらつきが識別された場合はそれらを分析し、今後そのようなばらつきを失くすために処置を講じるべきです。

窓口と関係の構築SLMプロセスでは、事業、特に事業上の重要な窓口と信頼関係を築き、互いに尊重する必要があります。サービス・カタログ、特にビジネス・サービス・カタログを使用することにより、SLMはよりプロアクティブになることができます。サービス・カタログは、サービスと事業部門の関係、およびビジネス・プロセスがサービスにどのように依存するかをSLMが理解する助けとなります。サービス・カタログはまた、サービスに関連する事業およびITのすべての重要な窓口についての情報も提供します。



My N otes

これを一貫した方法で確実に行うために、SLMは次のことを行うべきです。

利害関係者、顧客、事業マネージャ、およびサービスのユーザ yを定義する。サービス・ポートフォリオおよびサービス・カタログを正確に y維持するよう支援する。事業、顧客、およびユーザのニーズに対応できるようにす yる。SLMは、既存および提案されたビジネス・プロセスと、新規または変更されるサービスのためのそれらの要件を理解する必要がある。そして、それらの要件を文書化して他のプロセスに伝達し、有益で、革新的な変更を促進しなければならない。事業、顧客、およびユーザの計画と事業達成目標に従って、IT yが事業、顧客、およびユーザと長期的な関係を築いていけるようにする。IT顧客とITサービスを使用する外部の事業顧客の両方の顧客 y経験を定期的に体験して、顧客の課題についてITにフィードバックを行う。適切な関係プロセスが整備され、それらが達成目標の実現 yと、継続的な改善を目指していることを確認する。顧客調査を実施し、それらの分析を支援し、結果に対して処 y置が講じられることを確実にする。ユーザ・グループの編成と参加において、ITの代表者としての y役割を果たす。サービス・ポートフォリオとサービス・カタログを売り込み、事 y業の全領域でそれらが使用されることを確実にする。事業、顧客、およびユーザと連携することによって、現在およ yび将来のビジネス・ニーズを満たす最適なレベルのサービスをITが提供できるようにする。サービスに対する認識と理解を促進する。 y新しい技術を使うことの事業上の利点を周知させる。 y事業とITとの間で達成可能なSLRおよびSLAについて交渉し、 y設定する。事業、顧客、およびユーザに、ITに対するそれぞれのコミット yメントについて認識させる。保留中の改善および強化の記録を維持するのを支援する。 y



My N otes

SLMのトリガSLM活動を発動するトリガには次のものがあります。

新規または変更されたサービスまたは事業要件などのサー yビス・ポートフォリオの変更新規または変更されたSLA、SLR、OLA、またはその他の合意 yと契約

サービス・レビュー・ミーティングと実施された処置 y実際のサービス違反またはサービス違反のおそれ y苦情と賛辞 y定期的なレビュー、レポート、および顧客満足度調査 y

戦略的または方針的な変更 y

SLMプロセスのインプットSLMプロセスでは、次のような情報源から情報を入手します。

事業情報：事業の戦略、計画、および財務計画からの現在と将 y来の事業要件に関する情報ビジネス・インパクト分析：すべてのサービスのインパクト、優 y先度、リスク、およびユーザ数に関する情報事業要件：新規または変更された事業要件に関する情報 yサービスストラテジからの戦略、方針、および制約 yサービス・ポートフォリオおよびサービス・カタログ y変更情報：すべての変更がすべてのサービスに及ぼすインパ yクトをアセスメントする必要性と、変更管理プロセスからの将来的な変更スケジュールに関する情報CMS：ビジネス・サービス、支援サービス、および技術の関係 yに関する情報顧客とユーザからのフィードバック、苦情、および賛辞 yその他のインプット：SLA、SLR、OLA、およびサービス品質に y関する過去のサービス・レポートと、他のプロセスからの助言、インプット、および情報

SLMプロセスのアウトプットSLMのアウトプットには次のようなものがあります。

サービス・レポート：SLAの目標値に照らしたサービスレベル yの達成度の詳細を提供。これには、現在と過去のパフォーマンス、違反、弱点、重大なイベント、提案された変更、現在の作業負荷と予想される作業負荷、顧客のフィードバック、および改善計画と改善活動が含まれる。SIP：優先度付けされた改善処置のすべてを網羅した計画を y



My N otes

提供。これには、すべてのサービスとプロセス、および関連するインパクトとリスクも含まれる。サービス品質計画：全体的なサービス品質の改善の計画を y提供。文書テンプレート：企業標準と整合したSLA、SLR、およびOLA yの標準的な文書形式を提供。SLA：すべての運用サービスの合意された目標値と責任を文 y書化。SLR：すべての計画されたサービスまたは変更されたサービ yスの合意された目標値と責任を文書化。OLA：すべての内部サポート・チームの合意された目標値と y責任を文書化。OLAとUCを評価したレポート。 yサービス・レビュー・ミーティングの議事録と処置：議題、協 y議、および処置の詳細の記録および推進。SLAのレビュー・ミーティングおよびサービス適用範囲のレビ yュー・ミーティングの議事録：合意された処置、SLA、およびサービス適用範囲の改定の詳細を提供契約の改定：UCを変更する必要性に関する情報の提供、また yは変更されたSLAまたは新規SLRのための新規契約の交渉。



My N otes

4.11　グループ／個人演習

ワークブックを参照して演習に取り組んでください。


米国の国際的な大手コンピュータ・メーカでは、SLMを導入することによって、現在のITILプロセス導入の成功をより大きなものにしたいと考えています。この会社は、サービスデザイン、サービストランジション、およびサービスオペレーションの多くのプロセスをうまく実施してきており、現在と将来の顧客ベースと長期的な関係を構築することに重点を置きたいと考えています。

この会社は、国際通信をプロバイダにかなり依存しています。ダイアルアップ接続を使用する小さな販売オフィスから衛星通信や高速ファイバー・ネットワークまで、これらの通信は世界の代表的コンピュータ・メーカになるために必要不可欠であると考えています。

あなたは、この会社のサービスレベル・マネージャという新しい役割に任命されました。SLMプロセスの導入を成功させるために会社が考慮する必要がある主な検討事項を、ITマネジメントと主な利害関係者に説明するよう要請されています。

プレゼンテーションで考慮する必要のある主な領域は何ですか？Q1.

SLMは、事業でサポートされている全サービスの現在の利用a) 状況を識別する必要があります。ビジネス・サービスを維持する手段としてITサービス継続性管理（ITSCM）プロセスの活動と緊密に協力し、また、すべてのサービスのリソース利用率に関する履歴情報を提供するためにキャパシティ管理とも連携する必要があります。SLMは、事業と顧客の要件に応じるために、必要に応じて契約を再交渉するためにサプライヤとも直接的に協力します。顧客の信頼を獲得し関係を強化するために、サービス品質の報告を整備しなければなりません。

サービス・ポートフォリオ内で現在と将来のサービスを識別b) し、管理するべきサービスとそれらのサービスの重要度を特定します。また、事業と顧客にとって重要なことに焦点を当てられるように、利用されているサービスの内部要件と外部要件を収集する必要があります。さらに、サービス障害をプロアクティブに予防し、他のプロセスと連携してサービスの品質を全体的に向上するために、適切なリソースを確実に利用可能にすることも検討しなければなりません。SLAの報告とレビューであいまいな点が生じないように、顧客の観点からの測定基準も収集する必要があります。



My N otes

提供されているコアサービスを特定し、顧客の特定の要件にc) ついて顧客と話し合いを始めます。また、すべてのサービス違反をサービスデスクで記録する手段を用意して、それらの障害の根本原因を識別し、再発生のリスクを軽減する必要があります。もう1つの主要な検討事項は、顧客要件に基づいて適時に問題をエスカレーションすることです。これには、問題処理の流れを効率的にするために、エスカレーション手順を内部ITサービス・プロバイダとのSLAに文書化する作業も含まれます。また、他のプロセス・オーナと連携して、SLAレビューで使用する適切なデータを収集する必要があります。

サービス・ポートフォリオ・マネージャと密接に連携して、ITプd) ロバイダの現在と将来のサービスに関する情報を収集します。また、提供されるITサービスのレベルの定義、文書化、合意、モニタ、および測定に重点を置く必要があります。サービス需要に備えて、よりプロアクティブなアプローチを計画するために、事業活動パターン（PBA）の理解を深めるのもよいでしょう。SLA達成度の報告のための測定基準を収集するために、モニタリングの観点から現在何が導入されているかを評価する必要があります。



需要管理ユニット5

Student | ITIL v3 Intermediate Certification Level | Demand Management


My N otes

ユニット5：需要管理

概要リソースには限りがあるため、ITサービス・プロバイダ組織は、サービスの需要に対応するのに常に苦労しています。需要管理は、顧客のサービス要件をより良く理解するための助けとなり、ITサービス・プロバイダはサービスのライフサイクルを通してそれらの要件を満たすことができるようになります。

需要管理を通じて、顧客のサービス需要を理解し、需要のパターンを識別し、その需要を満たすために必要なキャパシティを割り当てることができます。この種の体系化されたアプローチを取ることで、リソースを過剰に拡張することなくサービス品質を維持できるような形で需要の流れを管理できます。


プロセスの最終目標と達成目標を説明できる。 yプロセスの基本概念を理解できる。 y活動を基準にした需要管理と事業活動パターン（PBA）につ yいての理解を実証できる。需要管理とサービス・ポートフォリオとのインタフェースを明 y確に理解できる。サービスに対する需要の管理方法を説明できる。 y

5.1　目的と最終目標

目的：サービスに対する需要を理解する。 y需要を満たすようにリソースを管理する。 yユーザ・プロファイルと事業活動パターンを分析する。 y価格による奨励策によって、顧客がピーク時以外の時間帯に yITサービスを使用するように奨励する。

最終目標：できるだけ正確にサービスの需要を予測する。 y需要と利用可能なリソースとの間でバランスを取る。 y



My N otes

5.2　基本概念

需要管理とは、サービスに対する顧客の需要、およびそれらの需要に対応するためのキャパシティの準備について把握し影響を及ぼすプロセスである。戦略レベルでは、需要管理には事業活動パターンとユーザ・プロファイルの分析が含まれる場合がある。戦術レベルでは、利用の少ない時間帯にITサービスを使用するよう顧客に促すために、格差課金を使用することもある。


需要管理需要管理はサービスマネジメントの重要な側面の1つです。サービスの不十分な管理は需要の不確実性を招きます。その結果、余分なキャパシティによって生じるコストを回収できないため、サービス・プロバイダにとってのリスクが増加します。顧客は使用されないキャパシティに対してお金を支払いたがりません。

ただし、サービスレベルを維持するために未使用キャパシティが必要な場合もあります。そのような場合の高いキャパシティは、それによって高いレベルの確実さが確保されるため、価値を生み出します。そのようなキャパシティは積極的に使用されるため、無駄と見なすべきではありません。

問題不十分なキャパシティは、サービス品質に影響を及ぼし、サービスが事業の要件を満たすのを妨げます。サービスレベル・アグリーメント

（SLA）、予測、計画立案、顧客との調整は、需要の不確実性を緩和しますが、完全に排除できるわけでは決してありません。

サービスマネジメントが直面する別の問題は、サービスが生産されながら消費されるという問題です。これは、消費サイクルが生産サイクルを刺激するプル方式であるため、避けられません。

オフピーク時向け価格設定、数量割引、サービスレベルの差別化などの需要管理技法を使うと、特定のパターンで需要が発生するように操作できます。ただし、需要がキャパシティを牽引します。つまり、需要のためにキャパシティがあるのであって、その逆ではありません。

協調的なパターンで、消費が需要を生み、生産が需要を消費していきます。サービスは商品とは異なり、需要を見越して事前に生産しておき、在庫として保管しておくわけにはいきません。



My N otes

ジャスト・イン・タイム（JIT）方式の製造と比較しても、サービス・システムにおいては需要とキャパシティがはるかに密接に結び付いています。

需要の予測およびパターンは、次を行うために使用します。

サービスに生産能力を割り当てる。 y未使用のキャパシティを迅速に増やし解放する。 y



5.3　活動を基準にした需要管理とPBA

事業活動パターン


需要パターン

サービス・プロセス

サービス・ベルト

提供スケジュール

キャパシティ管理計画

消費に影響を与えるための報奨と罰則需要管理

サービスの需要は、主にビジネス・プロセスから発生します。そのため、PBAは需要のパターンに影響します。

顧客の事業を調査して、需要のパターンを識別、分析、および文書化する必要があります。これは、キャパシティ管理の基盤となります。支援サービスに対する需要との関係から、顧客の事業活動と事業計画を検討する必要があります。

事業活動パターン事業活動はサービスの需要を促進します。PBAは、次の3つの顧客資産から生まれます。

人材 yプロセス yアプリケーション y

PBAは事業活動を定義し、次の4つのグループとのやり取りを含みます。

顧客 yサプライヤ yパートナ y利害関係者 y



My N otes

PBAは収益、収入、コストを発生させるものであるため、事業成果の大きな部分を占めています。組織は、詳細が明確で完全になるように、プロセスを通してPBAを識別、体系化、および共有します。

次の属性は事業活動を説明するものです。

頻度 y数量 y場所 y期間 y

これらの属性は次の要件と関連しています。

セキュリティ yプライバシー y待ち時間または遅延許容度 y

ビジネス・プロセス、人材、組織、アプリケーション、およびインフラストラクチャにおける変更および改善は、事業活動のプロファイルに影響を与えます。そのため、PBAを変更のコントロール下に置かなければなりません。

各PBAは一意の基準で体系化されています。このパターンの体系化は、類似性や近似性の基準を使って多次元的な視点でPBAを分析するのに役立ちます。これにより、次のようなシンプルで標準的なパターンのカタログを作成する効率性と堅牢性が高まります。

パターンの数を減らす。 y分析を容易にする。 y複雑な解決策を回避する。 y



事業活動パターンに一致するユーザ・プロファイル（例）

ユーザ・プロファイル該当する事業活動パターン（PBA） PBAコード

上級役員（UP1）中短期の国内海外出張、取り扱い要注意の情報、サービス要求の待ち時間なし、技術支援に高いニーズ、事業へ即応できる必要性

45F45A35D

移動の多い役員（UP2）長期の国内海外出張、取り扱い要注意の情報、サービス要求の待ち時間が短い、技術支援に中程度のニーズ、顧客との高い接触度、顧客に即応できる必要性

45A35D22A

オフィス・スタッフ（UP3）オフィスに常駐する総務スタッフ、低頻度の国内出張、サービス要求の待ち時間が中程度、技術支援のニーズ低、フル装備のデスクトップの必要性、顧客との中程度の接触、大量の事務作業、勤務時間中は高い生産性が必要

22A14B3A

支払処理システム（UP4）

業務システム、大量、トランザクション・ベース、セキュリティへの高いニーズ、サービス要求の待ち時間が短い、季節変動小、郵便による文書送付、自動顧客通知、規制上のコンプライアンスが基本、低単位コストの必要性、高セキュリティと透明性の必要性（監査コントロール）

12F

顧客支援プロセス（UP5）ビジネス・プロセス、中程度の分量、トランザクション・ベース、中程度のセキュリティの必要性、サービス要求の待ち時間が非常に短い、季節変動中程度、宅配便による交換部品の配送、自動顧客通知、顧客への即応が必要

24G10G




5.4　サービス・ポートフォリオとのインタフェース

サービス・ポートフォリオ、サービス・カタログ、およびSLMとのインタフェースサービス・ポートフォリオが提供する価格設定情報は、顧客の購買行動に影響を与えます。そのため、サービス・プロバイダはサービス・ポートフォリオを使って、価格を変更し、顧客の購買の意思決定に影響を与えることができます。サービス・カタログでサービスレベル・オプションに関する情報を提供することによって、顧客が最も費用対効果の優れたサービスを選択できるよう手助けできます。

さらに、ビジネス・サービス・カタログは、顧客がITコストと事業運営との関連をより良く理解するのに役立ちます。それによって、顧客は需要の予測をより正確に計算できるため、ITは財務的、技術的、および人的なリソースをもっとうまく割り当てられるようになります。

需要管理は、機会を追求するべきかどうかの理解の一環として、サービスストラテジ・プロセスのかなり早い時期に関与します。その情報はサービスストラテジ・プロセスの初期に取得され、サービス・ポートフォリオに含まれます。需要を理解することは、機会の有用性および保証の要件（サービスレベル・パッケージ（SLP））を決定する構成要素であるため、SLMと関連付けられます。

組織内でサービスマネジメントの成熟度が増すと、相当のコストの増加なしで、より高いレベルの有用性と保証を提供することが可能になります。従って、サービス・プロバイダにとっての価値の獲得は、顧客にとっての価値の創出を伴います。

サービスの需要が適切に管理されない場合、コストとリスクが大幅に増大します。サービス・カタログは、モデル化、意思決定、およびコントロールのための需要の重要な情報を提供するため、サービス需要の管理において有用なツールです。サービス・カタログからの情報は、事業において予想される用途とITの供給要件を見積もるための支援となる財務要件に変換されます。

サービス査定を使用して、サービス・カタログ内に各サービス、サービス・コンポーネント、およびSLPの価値を決定できます。これにより、想定サービス消費の見積もりが正確にでき、正確な需要の計画が可能になります。さらに、財務管理の適用を通じて、サービス・カタログは顧客が需要を調整するのを支援します。

サービス・カタログはまた、SLPおよびコアサービス・パッケージ（CSP）とでセグメント化し、顧客のニーズに応じた有用性と保証を顧客に提供できます。これによって、顧客への対応が不十分であったり過剰であったりすることがなくなり、サービス合意やサービス契約がより効率の高いものとなります。



5.5　サービスの需要管理


需要

需要

需要

従業員数使用中の

具体的な

プロセス

事業活動

サービス

要求

サービス・

インシデント

サービスデスクキャパシティの

計画とスケジュール

事業計画



My N otes

活動を基準にした需要管理を使用して、サービス・プロバイダはサービスマネジメント計画を顧客の事業計画と合わせて調整することができます。

事業計画で人的資源の割り当てが必要とされた場合、社員の追加は、サービス要求とサービス・インシデントの面でのサービスデスク機能に対する追加需要を意味します。新しいビジネス・プロセスは、サービスデスクの需要を予測するのにも役立ちます。活動／需要モデルの妥当性確認を行うと、新しい従業員、ビジネス・プロセスの変更、顧客の側での技術のアップグレードなどの変動に対応する調整が可能となります。

PBAを分析する主な利点は、それによってサービスマネジメントの機能およびプロセスにもたらされるインプットです。例として、次のようなものがあります。

サービスデザインで、需要パターンに合わせて設計を最適化 yできる。サービス・カタログで、サービスを需要パターンと一致させる yことができる。サービス・ポートフォリオで、追加のキャパシティ、新規サービ yス、またはサービス変更に対して投資を承認できる。サービスオペレーションで、需要パターンに合わせてリソー yス割り当てとスケジューリングを調整できる。サービスオペレーションで、同様の需要パターンをグループ y化し、需要を統合できる。

財務管理で、需要に影響を及ぼす奨励策を承認できる。 y



My N otes




あなたは、休暇シーズンに備えて事業が適切な意思決定を行うことQ1. を支援する担当者として任命されました。この意思決定に必要な正しい情報を取得するための、最も適切で期限を守れる手段について説明している選択肢を選択してください。

現在の事業計画をレビューして顧客と緊密に協力すa. ることで、現在および新しく修正したサービス提供内容のキャパシティに対する需要を把握します。人材、プロセス、およびアプリケーションが事業や顧客とともに使用されるPBAを活用して、休暇シーズン中の需要をどのように予測できるかを明確にする必要があります。また、利害関係者、パートナ、およびサプライヤと緊密に協力して、事業要件の変動性の理解を深める必要があります。コアサービスと支援サービスを定義して、すべての領域が話し合いに含まれるようにします。需要に影響を与えるために使用できる、格差のある提供内容を開発します。これらのプロセス活動は、一貫性を確保するために、厳格な変更コントロール・プロセスの管理下に置く必要があります。

現在の事業計画をレビューするだけでなく、利害関b. 係者や顧客と緊密に協力して、必要なPBAを導入します。PBAのアウトプットにより、キャパシティ管理チームと協力して、リソースに対する事業と顧客の動的なニーズを支援するのに必要なジャスト・イン・タイム

（JIT）のキャパシティ・レベルを適切に準備できるようになります。明確化したら、SLMチームと緊密に協力して顧客、サプライヤ、ITプロバイダ、およびパートナと契約を結び、サービスを提供するのに必要なすべての関係者からのコミットメントを確実にします。



My N otes

キャパシティ管理チームと直ちに協力し、全体的なc. キャパシティ計画をレビューして、事業キャパシティ・ニーズの現在の要件と将来の要件を識別します。休暇シーズンに対する顧客別のサービスレベル要件

（SLR）予測を収集します。これには具体的なPBAも含まれます。この情報を利用してベンダやIT組織と緊密に協力することで、適切なハードウェアとソフトウェアを確保できるようにします。

利害関係者とミーティングを持ち、最初に、休暇シーd. ズン中の事業自体のパフォーマンス予測について明確にします。この事業予測を把握できたら、SLMチームと直接協力して、顧客の潜在的な要件とキャパシティに対する具体的なニーズを把握することができます。この情報を活用することで、適切なキャパシティ計画を作成できます。このキャパシティ計画は役員会に提出し、ソフトウェアと関連ハードウェアを取得するのに必要な財務上の承認を得る必要があります。



ユニット6サプライヤ管理

Student | ITIL v3 Intermediate Certification Level | Supplier Management


My N otes

ユニット6：サプライヤ管理

概要事業では広範なITサービスが要求されますが、すべてのサービスを常に内部で提供できるとは限りません。必然的に、一部のサービスは外部サプライヤにアウトソーシングすることになります。サプライヤとの関係が事業に最大限の利益をもたらし、サプライヤがITサービス目標値の達成を支援することを確実にするのは、サプライヤ管理の責任です。


プロセスの最終目標と y 達成目標を説明できる。プロセスの適用範囲を理解できる。 yサービス・ライフサイクルに対するプロセスの重要性と、これ yがどのように事業上の価値を創出するかについて明確に理解できる。サプライヤ管理の原則と基本概念についての理解を実証で yきる。サプライヤ管理の主要な活動、手法、および技法と、プロセス yがサービス・ライフサイクルにどのように関連するか（新しいサプライヤの評価など）を説明できる。サプライヤのカテゴリ化およびサプライヤ・データベースの y維持管理について理解できる。プロセスに関連する主要な測定基準、課題、重要成功要因 y

（CSF）、およびリスクを理解できる。



My N otes


目的：投資に見合う価値をサプライヤから得る。 yサプライヤが自身の各契約および各合意に記載された合意 y済みの目標値と諸条件を守るように徹底する。サプライヤとサプライヤの提供するサービスが、ITサービス y目標値と事業要件をサポートすることを確実にする。

最終目標：サプライヤ管理プロセスの最終目標は、サプライヤとサプライヤの供給するサービスを管理し、投資に見合った価値を確実に得られるよう、事業への均一な品質のITサービスを提供することである


サービス・ライフサイクルの全段階にサプライヤ管理のプロセスと計画立案が含まれる必要があります。極めて複雑な現代の事業は、包括的な一連のITサービスを求めています。サプライヤとサプライヤのサービスは、現代の企業が要求するエンドツーエンドのソリューションにとって必須の要素です。そのため、サプライヤとサプライヤ管理は、良質なITサービスの提供に不可欠です。

達成目標：サプライヤ管理の達成目標は次のとおりです。

投資に見合う価値をサプライヤから得る。 yサプライヤとの合意が事業要件に沿っていることを確実に yし、サービスレベル管理（SLM）と連携して、サービスレベル要件（SLR）とサービスレベル・アグリーメント（SLA）の目標値をサポートする。サプライヤとの関係を管理する。 yサプライヤのパフォーマンスを管理する。 y契約についてサプライヤと交渉し、そのライフサイクルを通し yてモニタする。一貫したサプライヤ方針と、サプライヤ契約データベース y

（SCD）を維持管理する。



My N otes


サプライヤ管理は、事業が要求するITサービスの調達に必要な、すべてのサプライヤおよび契約を管理するべきです。サプライヤ管理の正式なプロセスを確立することが重要です。このプロセスは、サプライヤの重要性、およびサプライヤが事業に提供するサービスの重要性を明らかにするものでなければなりません。

大部分のサプライヤが提供するサービスは、個別に見れば限られた役割を果たしているにすぎないかもしれませんが、集合的に見れば価値創出と事業戦略の実行に大きく貢献していると言えます。事業上の価値へのサプライヤの貢献度が高いほど、サプライヤの管理、およびサプライヤを事業戦略の開発と実施に関与させることに対していっそう努力するべきです。比較的貢献度の低いサプライヤについては、運用レベルで管理することができます。

大きな組織では、内部のチームおよびサプライヤもサプライヤ管理の対象とする必要があります。

サプライヤ管理プロセスには次が含まれるべきです。

サプライヤ方針の導入と施行 yサプライヤ契約データベース（SCD）の維持管理 yサプライヤと契約のカテゴリ化、およびリスク・アセスメント yサプライヤと契約の評価および選択 y契約の策定、交渉、および合意 y契約のレビュー、更新、および終了 yサプライヤおよびサプライヤのパフォーマンスの管理 yサービスおよびサプライヤの改善計画の合意と実施 y標準的な契約および諸条件の維持管理 y契約上の争議解決の管理 y再委託先サプライヤの管理 y




サービス・プロバイダ

サプライヤ管理

プロセス・オーナ

サプライヤ・マネージャ1




契約

マネージャ

財務と購買

法務

サービスサービスサービスサービスサービスサービス

サプライヤ1

サプライヤ2

サプライヤ3

サプライヤ4

サプライヤ5

サプライヤ6

再委託先サプライヤ1

再委託先サプライヤ2

さらに、サプライヤ管理は、組織または企業の標準、指針、および要件、特に企業の法務部門、財務部門、購買部門に関するものに従う必要があります。

サプライヤが自身のサービス目標値などの契約上の義務を果たすようにするために、指名された従業員が各サプライヤとの関係の管理に責任を負うべきです。1人の従業員が複数のサプライヤに対して責任を負うこともあります。サプライヤとの関係を一貫した方法で構築し、サプライヤのパフォーマンスを定期的にレビューするために、サプライヤ管理プロセスのオーナと契約マネージャの役割を設定します。規模の小さな組織では、これらの役割を1つの責任にまとめることもあります。



My N otes

6.3　サプライヤ管理の重要性と事業上の価値への貢献

サプライヤ管理の目的は、サプライヤおよびサプライヤの契約から投資に見合う価値を得ることです。サプライヤ管理では、外部委託契約（UC）および合意内のすべての目標値が、ビジネス・ニーズおよびSLA内の上位の目標値と一致しているかもモニタします。これにより、事業に提供されるエンドツーエンドのサービスが、ビジネス・ニーズや事業の期待に確実に沿うようになります。すべてのサプライヤ管理活動は、企業要件と他のすべてのITプロセスおよびサプライヤ管理プロセス、特に情報セキュリティ管理およびITサービス継続性管理

（ITSCM）の要件に従う必要があります。



6.4　原則と基本概念

サプライヤ管理の目的は、サプライヤに自身の契約内の諸条件と目標値を確実に守らせつつ、サプライヤから得る投資に見合う価値を最大限にすることです。サービスストラテジによるサプライヤ戦略と方針が、すべてのサプライヤ管理活動を導くべきです。この方針は、適切に定義された役割および責任と併せて、サプライヤ契約データベース（SCD）を維持管理することによって、一貫性と有効性を保つことができます。

明確に定義された役割および責任とともにどのようにSCDを構築するべきかについて、次の図を見てみましょう。

サプライヤの戦略と方針

新しいサプライヤと

契約の評価

サプライヤのカテゴリ化とSCDの維持

新しいサプライヤと契約の確立

サプライヤと

契約の管理と

パフォーマンス

契約更新や終了

サプライヤ契約

データベースSCD

サプライヤのレポートと情報



My N otes

SCDは、包括的な構成管理システム（CMS）およびサービス・ナレッジ管理システム（SKMS）の不可欠な部分となるべきです。SCDは、すべてのサプライヤの詳細、各サプライヤが提供するサービスまたは製品の種類の詳細、およびこれらと他のCIとの関係を収集したものでなければなりません。サプライヤが提供するサービスは、サービス・ポートフォリオとサービス・カタログの重要な部分でもあります。支援サービスと、ビジネス・サービスおよびITサービスとの間のこのような相互関係は、高品質のITサービスを提供するうえで役立ちます。

サプライヤ管理の手順と活動には次の要素が含まれます。

サプライヤのカテゴリ化と、SCDの維持管理 y新しいサプライヤおよび契約の評価と設定 y新しいサプライヤの確立 yサプライヤおよび契約の管理 y契約の更新および終了 y

SCD内の情報は、これらの活動に関するすべての情報を提供します。このリストの最初の2つの活動はサービスデザインの一部、3つ目の活動はサービストランジションの一部で、最後の2つはサービスオペレーションの一部です。



My N otes

6.5　主要な活動、手法、技法、サービス・ライフサイクルとの関係

プロセスの活動、手法、技法外部サプライヤと取り引きする場合、すべての責任と目標値を定義し、文書化した正式な契約があることが重要です。そしてこの契約は、ビジネス・ニーズの識別から契約の運用と終了までの契約ライフサイクルを通して管理しなくてはなりません。

ビジネス・ニーズを識別し、ビジネス・ケースを準備する際は、次のことを行います。

要件記述書（SOR）や入札案内（ITT）を作成する。 y戦略／方針に従っているようにする。 y内部および外部の選択肢、コスト、期間、目標値、利点、リスク yを含む、完全なビジネス・ケースを準備する。

新しいサプライヤおよび契約を評価しソーシングする際は、次のことを行います。

購入と調達の方法を特定する。 y個人および組織の能力、サービス、品質、コストなどの評価基 y準を定義する。サプライヤおよび委託先に関するすべての選択肢を比較す yる。サプライヤまたは委託先を選択する。 y目標値、責任、終了、更新、延長、争議、移行など、契約の諸条 y件について交渉する。契約に合意し、発注する。 y

新しいサプライヤおよび契約を確立する際は、次のことを行います。

SCDおよび他の関連する企業システム内に、サプライヤのサ yービスと契約を設定する。サービスを移行する。 y関係および契約を確立する。 y

サプライヤおよび契約をカテゴリ化する際は、次のことを行います。

サプライヤまたは契約をアセスメントまたは再アセスメント yする。サービストランジションを通じてすべての変更を確実に進め yる。サプライヤをカテゴリ化する。 ySCDを更新する。 ySCDを継続的に維持管理する。 y



My N otes

サプライヤおよび契約のパフォーマンスを管理する際は、次のことを行います。

サービスまたは製品の運用と提供をコントロールし、管理す yる。サービスの品質とコストをモニタし、報告する。 yコミュニケーション、リスク、変更、障害、改善、目標値、インタフ yェースに関して、関係を管理する。

契約期間が終了する際は、次のことを行います。

利点および今後の要件をレビューする。 y契約を再交渉し更新するか、終了または移行する。 y

ライフサイクルを通して契約を適切に管理するために、事業、IT、財務、購買、および調達が協働する必要があります。事業のすべての領域が共同でソリューションを選択し、サプライヤのパフォーマンスを管理しなければなりません。各領域は、各自の利益に責任を負うと同時に、組織全体への影響も理解しなければなりません。

次に、契約ライフサイクルのさまざまな段階について理解しましょう。

新しいサプライヤおよび契約の評価このプロセスはサービスデザインの一部で、契約ライフサイクルの他の段階にインプットを提供します。契約を成功させるには、ITチームの関与が欠かせません。すべての組織は、ビジネス・ケースの策定、承認、および最終決定に対して、事前に定義されたテンプレートと、文書化された正式な手法を持つべきです。事業およびITは、ビジネス・ニーズおよびビジネス・ケースの内容について合意、承認、および最終承認しなければなりません。

組織は、新しいサプライヤおよび契約を確立するための適切なプロセスと手順を持つべきです。新しいサプライヤまたは契約を選択する際は、次の点を考慮します。

実績 y能力 y信用照会 y信用格付け y規模（提携する事業に関して） y人材関連の課題（サプライヤとの関係の種類による） y



My N otes

選択されるサプライヤや関係の種類は、多くの場合、職場の駆け引きや既存の関係などの他の要素に依存します。その場合、根拠を特定しインパクトをアセスメントして、コストのかかる誤った選択を回避することが重要です。1つのサプライヤが1つのサービスを供給することもあれば、複数のサービスを供給することもあります。標準的な「既製」のサービスの場合、組織は複数の競合サプライヤを利用するのが一般的です。コストが主要な要素で、類似サービスの開発の必要性が低い場合、組織は通常、サービスのマルチソーシングを利用します。あるいは、マルチソーシングによってリスクを分散することもあります。複数のサプライヤを利用する場合は、あるサプライヤを「推奨サプライヤ」として指定し、他のサプライヤを利用する際の適用範囲を制限することができます。

事業戦略を整合する目的で戦略情報を交換したいサプライヤとの間には、パートナ関係を確立するべきです。また、パートナ関係は役員レベルで確立する必要があります。戦略的なサプライヤ関係は、パートナ関係として位置付けるべきです。これは、サプライヤが顧客組織との関係において置かれる、従属的な立場から脱することを意味します。

非階層的な関係の利点新しい、非階層的な関係には、主に次の利点があります。

戦略的整合：カルチャ、価値、および達成目標の整合による、 y事業戦略の整合統合：両当事者の組織のプロセスの統合 y情報の流れ：全レベル、特に戦略的レベルでのコミュニケーシ yョンによる十分な理解相互信頼：両組織のメンバー間の信頼関係 y率直さ：サービス・パフォーマンス、コスト、およびリスク分析 yに関する報告時の率直さ連帯責任：現在のパフォーマンスおよび今後の関係発展に対 yして連帯責任を負う共同パートナシップ・チームリスクと報酬の共有：例えば、材料費の変動などのリスクの共 y有

提携の利点提携は、両当事者に恩恵をもたらします。組織に対するサプライヤの理解が深まるにつれて、組織が受ける恩恵は大きくなります。理解が深まるほど、サプライヤは組織のニーズに対して、より迅速かつより適切に対応できるようになります。一方で、サプライヤは、事業からの長期的なコミットメントによって財務が安定するという恩恵を受けます。これにより、サプライヤが自身のサービスや製品を改善するための長期投資が可能となり、これが顧客に利益をもたらすのです。



My N otes

パートナシップによって、両当事者はITインフラストラクチャを整合できるようにもなります。アーキテクチャとリスク・コントロールの共同合意によって、より互換性のあるソリューションをパートナたちが実施できるようになります。こうした統合は、サービスを改善し、コストを削減します。

パートナシップを締結する前に、その利点とコストを理解することが重要です。このようにして、両当事者は、何を期待されているかについて初めから理解しておきます。パートナシップを確実に成功させるには、合意や関係に従って、パートナまたはアウトソーシング組織にスタッフを送り出さなければならない場合もあります。

サプライヤを評価し、選択するための正式なプロセスでは、次の点を考慮する必要があります。

重要性およびインパクト：事業に対するサプライヤのサービ yスの重要性リスク：サービス利用に伴うリスク yコスト：サービスとその配分のコスト y

法務、財務、購買など、サービス・プロバイダ組織の他の部門もこのプロセスに関与することがあります。

サービス・プロバイダのプロセスサービス・プロバイダは、次を行うための確立されたプロセスを持たなければなりません。

ビジネス・ケースに関する文書を作成する。 ySORとITTまたは提案書を作成する。 yサプライヤおよび契約を正式に評価し、選択する。 y契約の標準的な条項および諸条件（通常の終了および早期 y終了、ベンチマーキング、譲渡または脱退、争議解決、再委託先サプライヤの管理など）を記載する。新しいサプライヤおよび契約を移行する。 y

これらのプロセスは、サプライヤと契約の規模、種類、およびカテゴリによって異なるべきです。



My N otes

契約のリスク合意の性質と適用範囲は、関係の種類およびリスク・アセスメントによって決まります。外部サプライヤとの合意を形式化する前に、合意前のリスク分析を行うことが重要です。各当事者に対するリスクが明らかになります。リスク分析は、財務、業界の評判、運用、規制、法律などの各リスクを含み、包括的かつ実用的でなければなりません。

包括的な合意は、何が期待されているかを両当事者に認識させるので、将来争議が起こる可能性を低くすることになります。合意は、その期間を通して存続するように、柔軟なものにしてください。そうすれば、将来の変更に合意を適応しやすくなり、最小限の交渉で済むことになります。

外部委託契約UCまたはサービス合意には次のものが含まれます。

諸条件：契約の存続期間、当事者、場所、適用範囲、定義、およ yび取り引き上の基準を含みます。サービスの記述および適用範囲：パフォーマンス、可用性、キ yャパシティ、セキュリティ、技術インタフェースなどの、提供への制約に加えて、供給されるサービスの機能性とその範囲を含みます。サービスの機能性は、明確に定義するか、または定着しているサービスの場合は、サービス・ポートフォリオ、サービス・カタログなどの他の文書への言及を含めなければなりません。サービス標準：サービスの品質およびパフォーマンスの許容 y可能なレベルを含みます。サービスレベルは測定可能、達成可能で、優先度に合うようにします。このサービスレベルはSLAとSLRの目標値の基本にもなります。作業負荷の範囲：サービス目標値が適用される量の範囲、ま yたは特定の価格設定の指針が適用される量の範囲を含みます。管理情報：サプライヤが報告するべき運用上のパフォーマン yスに関するデータを含みます。管理情報には、関係をアセスメントするための主要な報告指標だけを含めるべきです。パフォーマンス・データには、重要業績評価指標（KPI）およびバランス・スコアカードを含めることができます。責任および依存関係：コミュニケーション、窓口、およびエス yカレーションに関する、サービス供給におけるサプライヤの義務の説明と、サプライヤのサービス提供の取り組みを支援する組織の義務の説明を含みます。

広範なサービス合意には、次の内容を含めることができます。

サービスのデビットおよびクレジットの指針（報奨および罰 y則）

追加のパフォーマンス基準 y



My N otes

サービス合意の項目サービス合意には通常、次の取り引き上の項目および法的な項目が含まれます。

供給されるサービスの適用範囲 yサービス・パフォーマンス要件 y責任の分担および合意 y窓口、コミュニケーション、および報告の頻度と内容 y契約のレビューおよび争議解決のプロセス y価格構造 y支払い条件 y変更および投資に対する約束事項 y合意変更プロセス y機密性および告知 y知的所有権および著作権 y責任制限 y各当事者の契約終了の権利 y契約終了以降の義務 y


調達部門または法務部門、あるいは専門の法律事務所が、合意の最終形態と使用する用語を決定します。外部供給の合意を形式化する場合は、法的助言を求めるのが最善の策です。

正式な契約事業の実現および発展に多大な貢献をする外部サプライヤに対しては、正式な契約を使用します。正式な契約により、両当事者の約束事項が法的拘束力を持ちます。また、正式な契約は他方の組織に対する各組織の義務も規定します。これらの義務は、契約初日から終了日以降まで適用されます。

このような契約は通常、法的強制力のある約束事項が必要な場合に使用されます。正式な契約は、価値が高く、戦略的な関係の土台となります。正式な契約の拘束力は、提携の合意の精神と対立するものと見なすべきではありません。むしろ、このような契約は、パートナ関係にかかわる信頼の基礎を形成します。

契約の文章には通常、取り引き上の条項および法的な条項を含む本文があります。サービス合意の要素は、付則として添付されます。



My N otes

正式な契約の内容正式な契約には次のものが含まれます。

セキュリティ要件 y事業継続性要件 y義務付けられた技術標準 y移行計画（事前に計画された合意済みの変更） y情報開示の合意 y


大規模な組織には、ソーシング契約を専門とする法務および調達部門があります。重要な正式契約では、この部門を支援するために法律事務所を利用することもできます。

基本となる合意SLAは、サービスに対して合意されたサービスレベルを文書化したもので、サービス・プロバイダと顧客によって署名されます。SLAは、サービスに基づいた関係を形式化するために、内部と外部の両方で使用されます。SLAの詳細の度合いはさまざまです。

サービスのパフォーマンスが合意済みのレベルを満たすように、SLA、UC、および合意を定期的にレビューする必要があります。

内部サポート・グループが関与している場合、支援するサービスがSLAの目標値の達成に役立つようにするために、オペレーショナルレベル・アグリーメント（OLA）を策定しなければなりません。OLAは、サービスの運用要件に焦点を当てます。OLAにはサービスとサービス標準、および関連する責任と義務を記載します。本来、契約的なものではありません。

OLAをモニタすると、問題が起こりそうな領域が明らかになります。サービスレベル・マネージャは、目標値に対してパフォーマンスをチェックし、問題を解決して再発を防止するための処置を取らなければなりません。サービスレベル・マネージャは、組織の規模に応じてサービスの責任を負うべきです。

サプライヤのカテゴリ化およびサプライヤ契約データベースの維持管理参考資料のトピック6.6を参照してください。

新しいサプライヤおよび契約の確立サプライヤ管理、または調達部門や購買部門がSCDを所有していても、SCDへのすべての追加は変更管理が処理します。これは、いかなるインパクトの可能性も確実に評価するためです。SCDは、サプライヤおよび契約の管理に必要なすべての情報を提供します。



My N otes

サプライヤと連携する場合、リスク管理では、事業に何らかの脅威をもたらす各サプライヤ合意の脆弱性を評価します。これには、事業へのインパクト、可能性、顧客満足度、ブランド・イメージ、市場シェア、収益性、株価、規制上の罰則が含まれます。

リスクの程度は、サプライヤとの関係の性質に依存します。外部サプライヤの場合のリスクは、より大きく、複雑である可能性が高くなります。ほとんどの場合、リスクの一部だけをアウトソーシング組織に移転することができます。重大な障害が発生したときにサプライヤを非難しても何にもなりません。関係から生じる新たなリスクを、適切なコミュニケーションやエスカレーションによって、識別し管理する必要があります。

契約に署名する前に、十分なリスク・アセスメントを実施します。変化するビジネス・ニーズ、および契約の適用範囲や運用状況の変更を必ず考慮してください。

サービス・プロバイダ組織とサプライヤの両者が、関係によって自身の資産にもたらされるリスクに留意しなければなりません。それぞれが、自身のリスク・プロファイルを保有し、各自のリスク・オーナを特定しなければなりません。関係がうまく機能していれば、アセスメントの全部または一部を、もう一方の当事者と共有できます。リスク・アセスメント、特に運用リスク・アセスメント（ORA）にサプライヤのエキスパートを巻き込むことで、リスク軽減とアセスメント範囲改善の最良の方法について貴重な洞察を得られます。

事業の中断のリスクビジネス・サービスまたは機能の中断のリスクを評価する場合、事業に対する優先度はさまざまである可能性があることを覚えておいてください。ビジネス・インパクト分析（BIA）は、サービスの中断が事業のさまざまな領域に与えるインパクトを評価するために使用します。サプライヤに関係するリスク・アセスメントおよびBIAの活動は、サプライヤ側のサービス障害のインパクトと可能性を低減するために、サービス継続性管理、可用性管理、および情報セキュリティ管理を巻き込む必要があります。

SCDの更新これらの活動の完了後、サプライヤと契約の情報によってSCDを更新します。

これには次のものを含める必要があります。

新しいサプライヤや契約の管理責任者 yサプライヤ・レビュー・ミーティングおよび契約レビュー・ミー yティングの頻度適切な区切り点 y自動しきい値および警告 y



My N otes

新しいサプライヤと契約の導入は重大な変更であり、移行から運用に至るまで、そのようなものとして扱うべきです。このことは、適切な窓口とコミュニケーション・ポイントの確立に役立ちます。

サプライヤおよび契約の管理とパフォーマンス日常の活動とプラクティスを効率的にするために、組織のプロセスとサプライヤのプロセスを運用レベルで統合する必要があります。問うべき重要な質問事項を次に示します。

サプライヤに、組織の変更管理プロセスまたは他のプロセス yに従うことを期待しているか？サービスデスクは、サプライヤにインシデントをどのように知 yらせるか？サプライヤの対応の結果として構成アイテム（CI）が変更され yる場合、CMSはどのように更新されるか？誰が責任を負うのか？

利害の対立の処理サプライヤとサービス・プロバイダ組織との間で、特に変更管理、インシデント管理、問題管理、およびCMSの各プロセスに関して、利害の対立が生じる場合があります。両当事者が、自身のプロセスの使用を希望することもあるでしょう。このような場合、責任とインタフェースを明確に定義し、合意します。

円滑な運用を確保するために、このような課題に対処する必要があります。そのためには、全員が自身の役割と責任を理解するように、各サプライヤと契約の管理責任者を含む、すべての窓口を特定し、手順を定義する必要があります。しかし、組織は機械的に自身のプロセスをサプライヤに強要するのではなく、サプライヤから学ぶ機会を持つように注意するべきです。

プロセスのインタフェースに加えて、運用レベルでの課題の対処方法を決定することも必要です。明確なエスカレーション経路があれば、課題がより早く特定されて解決され、インパクトが最小限になります。これは組織とサプライヤ両方の利点になります。

サプライヤとサービス・プロバイダ間のコミュニケーション・チャネル両当事者は、良好なコミュニケーション・チャネルを確立するよう努力するべきです。そうすれば、サプライヤが組織の事業、要件、および計画をより深く理解する助けとなります。その結果、組織は、より対応力のあるサプライヤから、より適切なソリューションを受けるという利点を得ます。日常の密接なつながりは、各当事者が相手のカルチャを学ぶことに役立ち、その結果誤解が少なくなり、さらに良好で長期的な関係をもたらします。



My N otes

契約のレビュー契約から最大限の利点を得られるように、契約ライフサイクルを通して、2つのレベルの正式なレビューを行う必要があります。2つのレベルとは次のとおりです。

サービス／サプライヤのパフォーマンスに関するレビュー： yサプライヤのカテゴリに基づいて、定期的にパフォーマンス・レポートを作成します。サービス・レビュー・ミーティングは、これらのレポートを基礎とするべきです。サプライヤが重要になるほど、レポートやレビューは、より広範で頻繁であるべきです。サービス、サービス適用範囲、および契約に関するレビュー： yこれらは、主要なサプライヤについて、定期的に、少なくとも毎年実施するべきです。これらのレビューの目的は、サービス、そのパフォーマンス、適用範囲と目標値、および契約を、あらゆる他の関連する合意と併せてレビューすることです。サプライヤと契約が、変化するビジネス・ニーズと整合して、投資に見合う価値を継続して提供することを確実にするために、当初のビジネス・ニーズと現在のビジネス・ニーズとを比較します。

レビューの議題サービスレベルに対するサプライヤのパフォーマンスを詳細な運用レベルでレビューするために、正式なパフォーマンス・レビューを定期的に開きます。これらのレビューは、継続的なサービス・パフォーマンスの管理がビジネス・ニーズをサポートしているかを確認する助けとなります。

一般的な議題には次のものが含まれます。

合意済みの目標値に照らしたサービス・パフォーマンス yエスカレーションされた課題を含む、インシデントおよび問 y題のレビュー事業および顧客からのフィードバック y次のサービス期間にサービスの中断を引き起こす可能性の yある重大な変更、失敗した変更、およびインシデントの原因となりうる変更サプライヤに特別の注意を要する、次のサービス期間中の主 y要な事業イベントベストプラクティスおよびサービス改善計画（SIP） y



My N otes

各サプライヤに対するSIPは、サービスの障害や弱点に対処するための処置を含む、新しい主要な改善計画と処置をコントロールします。現行のSIPの進捗、および新しい取り組みの要件は、サービス・レビュー・ミーティングでレビューすることができます。プロアクティブな組織は、サービスの一貫性を改善するためにもSIPを活用します。契約は、両当事者に、サービス改善への投資に対する動機を与えなければなりません。

組織内のさまざまなレベルの適切な利害関係者のニーズが、サプライヤおよび契約に対するコントロールの仕組みを決定します。

サービスやサプライヤの規模および重要性は、必要なコントロール協定を決定します。依存関係が顕著になるほど、関係の管理に、より大きなコミットメントと労力を注ぐべきです。外部契約の統制は、金融や製薬など規制が厳しい業界では特に、サービス・プロバイダ側に大きな労力が求められます。

サプライヤの価値の十分な実現サービスマネジメントでは、組織がサプライヤの価値を十分に実現するように徹底することが重要です。価値は、運用上のパフォーマンスの保証、変更要求に対する対応力、および需要の変動から、ナレッジと経験の共有に至るまで、関係のあらゆる部分から得られます。サプライヤの優先度を事業の優先度と確実に一致させる必要もあります。サプライヤは、どのサービスレベルが事業にとって重要かを理解しなければなりません。

活動と窓口の一貫性を保つために、サプライヤとの関係のすべての側面について1人の担当者が責任を負うようにします。

満足度調査の活用サプライヤのサービスレベルが事業要件に合っているかを判断するために、満足度調査を活用することができます。調査によって、サプライヤ側の目標値への違反はないのに、サービスへの不満があるというケースが明らかになります。これは、目標値の定義が不十分な場合に起こります。このようなときは、契約、合意、および目標値をレビューしなければなりません。幾つかのサービス・プロバイダは、サプライヤの業績比較表の発行をうまく利用して、サプライヤ間の競争を促しています。

事業およびITは、調達部門とともに、事業が直接的な利害関係を持つ重要なサプライヤ関係に対して、関係に対する彼らの達成目標を確立し、期待する利点を定義する必要があります。これは、サプライヤと関係を結ぶためのビジネス・ケースの重要な部分です。



My N otes

利点の測定こうした利点は互いに補完的でなければなりません。また、測定され管理される必要があります。事業が改善しようとしている顧客サービスをサポートするITサプライヤとの関係は、サプライヤ自身の領域でのサービス改善を表し、その改善が顧客サービスの向上にどれだけ役立ったかを実証する必要もあります。

利点のアセスメントは、契約ライフサイクルを通して、変化に応じて更新していかなければなりません。年間運用コスト5%削減をもたらす能力により選択されたあるサプライヤが、実際には2年経っても全く削減できておらず、この原因が契約の変化、または他のサプライヤにも影響する業界の一般的なコストにある場合は、相対的なコスト削減は現在も実現されている可能性があります。利点を定期的に更新していれば、このような削減が明らかになります。

パフォーマンス・レポートの中で、利点のアセスメントの優先度を低くする組織が多いですが、達成度を認めることは長期的な関係にとって重要です。利点レポートには通常、客観的なアセスメントが含まれますが、士気を高めるような達成度の事例を組み入れることもあります。

定期的に利点をレビューし、報告することは、関係を長期にわたって存続させることになるため、両組織にとって重要です。

サプライヤとの関係のアセスメントサプライヤとの関係の成功を事業の観点から分析する場合は、主に財務パフォーマンス指標が関係します。サービスが十分なパフォーマンスを上げている場合であっても、両当事者の財務目標値を満たしていないことがあります。関係から両当事者が財務的な利益を受けることが重要です。サプライヤの利幅を搾取すれば、サプライヤによる過少投資につながります。また、サービスの品質に次第に影響を及ぼします。あるいは、サプライヤの存続にかかわるかもしれません。いずれにしても、事業に悪影響をもたらします。

契約をうまく管理するには、対立的なアプローチで一方の当事者から短期的な利益を搾取するのではなく、両当事者が財務的なバランスの維持に向けて共同で努力することが必要です。

関係を構築するには、多くの努力と時間が必要です。そのため、組織はごく少数の重要なサプライヤと長期的な関係を構築することになります。サプライヤ関係を管理するには、優れた契約とコントロール体制だけでなく、関与する人々の経験、カルチャ、およびコミットメントも必要です。能力不足の関係チームでは、優れた契約は実現されません。

契約の更新や終了契約がビジネス・ニーズを満たしていることを確認するために、頻繁に契約をレビューします。契約のレビューは、契約の運用を全体的に、また運用レベルで行われるサービス・レビューよりも上級のレベルで、評価することに役立ちます。



My N otes

これらのレビューでは次の点に注意します。

契約が機能しているか、また将来の妥当性はどうか。 yサービス、製品、契約、合意、目標値の変更が必要か。 y拡大、縮小、変更、終了、移行など、関係の将来予測はどのよう yなものか。契約の取り引き上のパフォーマンス、ベンチマークおよび市 y場アセスメントに対するパフォーマンス・レビュー、価格設定構造および課金協定の実行可能性はどうか。今後考えられる契約の方向性、およびベストプラクティスの管 y理プロセスの順守はどうか。サプライヤと契約のコントロール体制 y

サプライヤの変更を決定する責任を誰が負うかは、サプライヤとの関係の種類によって決まります。サービス・プロバイダは、パフォーマンスの低いサプライヤの変更を決定することがありますが、契約上の関係については、調達部門と法務部門とともに決定することになります。

組織は次のことを進めるべきです。

特に移行期間中に、サービス・プロバイダ組織および事業に y対する、サプライヤ（特に戦略的なサプライヤ）変更のインパクトおよびリスク分析を行います。終了コストの取り引き上のアセスメントを行います。サプライ yヤの法的責任が明確ではない場合、契約終了のコストを含める場合がありますが、主要なコストは移行プロジェクトに関連することがよくあります。関係が大規模なものであれば、サービスが移行される際に2つのサプライヤが重複する期間が含まれます。サプライヤ変更によって諸変更が行われ、コストが増大します。つまり、直ちに固定費が増大するか、またはサプライヤが負担する長期のコストが増大してサービス料金が跳ね上がることになります。特に契約が早期に終了されそうな場合は、終了条件、必要な y通知期間、関連する仕組み、および影響に関して、法的助言を求めます。サプライヤ変更の潜在的な利点について、市場を再評価しま yす。

契約を確立する際には、適切な条項がすべて含まれるように、これらのステップを行うのが最善の策です。サプライヤ変更を検討する際には、必ずレビュー活動を再評価してください。



My N otes

6.6　サプライヤのカテゴリ化およびサプライヤ・データベースの維持管理

サプライヤのカテゴリ化およびSCDの維持管理サプライヤ管理では、重要なサプライヤを優先する必要があります。サプライヤ管理プロセスは、こうしたサプライヤの管理に、より多くの時間と労力をかけるべきです。そのためには、サービス・プロバイダに対するサプライヤの重要性と、サプライヤが事業に提供するサービスの重要性に従って、サプライヤをカテゴリ化するためのプロセスが、サプライヤ管理内にあるべきです。最適な手法は、リスク、インパクト、および事業に対するサプライヤとそのサービスの価値をカテゴリ化の基準に利用することです。サプライヤとの関係の管理に費やす時間と労力は、そのカテゴリ化に見合うものであるべきです。

次のようなカテゴリが考えられます。

戦略的：ここには、上級マネージャ同士が長期的な計画に関 yする戦略的な機密情報を共有するようなパートナシップが含まれます。このような関係は、上級マネジメントが所有し、管理します。戦略的な関係では定期的な連絡とパフォーマンス・レビューを行い、サービスストラテジおよびサービスデザインのリソースを必要とします。継続的な改善プログラム（世界規模のネットワーク・サービスの供給とサポートを行うネットワーク・サービス・プロバイダなど）も、戦略的な関係に含まれます。戦術的：ここには、商業活動や事業とのやり取りが顕著に見ら yれる関係が含まれるでしょう。このような関係は、中級マネジメントが管理します。この関係では、継続的改善プログラム（サーバのハードウェアの故障を解決するハードウェア保守組織など）を含む、定期的な連絡とパフォーマンス・レビューを行います。運用上：ここには、運用中の製品やサービスのサプライヤとの y関係が含まれるでしょう。このような関係は、下級運用マネジメントが管理します。これらの関係では、頻繁ではないが定期的な連絡とパフォーマンス・レビューを行います。利用頻度の低い、低インパクトのウェブサイト向けのホスティング・スペースを提供するインターネット・ホスティング・サービス・プロバイダなどが含まれます。



My N otes

コモディティ：ここには、容易に代替プロバイダからソーシン yグでき、容易に入手できる、価値の低い製品やサービスを提供するサプライヤとの関係が含まれるでしょう。例えば、紙やプリンタ・カートリッジのサプライヤなどです。

戦略的に重要なサプライヤとの関係戦略的に重要なサプライヤとの関係には、より注意を払ってください。このような関係では、関係が初期の契約を越えて継続できるように、サプライヤ・マネージャは、サプライヤがサービス・プロバイダ組織のカルチャを取り入れることを確実にしなければなりません。外部ソーシングが普及し、ソーシングの取り決めの複雑さが増大した結果、サプライヤとの関係の種類のカテゴリ化は多様化しています。戦略的には、最大の事業利益をもたらし、発展するビジネス・ニーズに適合するサプライヤとの関係の種類を選択できるように、すべての可能な選択肢を理解することが重要です。

適切なサプライヤ関係を選択するには、事業達成目標に対する明確な理解が必要です。

事業の観点からのサプライヤの重要性は、サービスの性質から総コストまで、多くの要素に依存します。事業にとって重要な関係ほど、その管理や発展にさらに事業が関与する必要があります。カテゴリ化のプロセスは、この重要性の判断に役立ちます。

契約価格よりも事業上の価値を考慮するほうが、事業と整合したアセスメントになります。

標準的なサービスのサプライヤ標準的なサービスではサプライヤへの依存性は低くなります。このような場合、サプライヤを取り替えるのも容易です。標準化されたサービスは、市場投入までの期間が最短となるので、新規または変更されたサービスの展開には有益です。また、コスト削減戦略の実施にも役立ちます。

カスタマイズされたサービスのサプライヤサービスがカスタマイズされるほど、サプライヤを変更することは困難になります。カスタマイズは、差別化されたサービスを通じて、事業に競争力をもたらす場合があります。カスタマイズは、運用上の発展の結果である場合もあります。

オーダーメイドのサービスは、サプライヤへの依存性を高めます。また、コストとリスクを増大させます。サプライヤにとって、オーダーメイドのサービスは規模の経済を縮小させ、その結果、利幅が低下し、将来的な投資への資金が減少することにつながります。

標準的なサービスとカスタマイズされたサービスではどちらが良いのでしょうか？



My N otes

カスタマイズから得られる事業上の優位性が明確でない場合は、標準的な製品およびサービスを選ぶべきです。事業上の優位性が明確な場合は、戦略的サプライヤからオーダーメイドのサービスをソーシングすることができます。

サプライヤとサービス・プロバイダの合意関係の種類を確立したら、次に合意によってその関係を形式化する必要があります。合意には、非公式な契約から法的拘束力のある契約まであります。価値の低い関係に対しては、サプライヤの標準的な諸条件で十分であり、またこうした関係は、全面的にITによって管理することができます。

契約を管理し、策定するには、調達部門と法務部門、および事業の利害関係者を巻き込みます。

ビジネス・サービスの提供には、外部や内部のサプライヤが複数関与することがあります。複数のサプライヤには、戦略的サプライヤとコモディティ・サプライヤの組み合わせが含まれることもあります。組織に直接サービスを提供するサプライヤもあれば、他のサプライヤを通じて間接的に業務を行う再委託先サプライヤもあります。サービス・プロバイダは直接サプライヤを管理し、統括サプライヤは再委託先サプライヤを管理します。1つのサプライヤが、複数のビジネス・サービスに対して製品やサービスを提供する場合もあります。

サプライ・チェーン分析は、ビジネス・サービスとサプライヤのサービスとの間の結びつきを明らかにします。ビジネス・プロセスの分析は、各プロセスに関連するサプライヤと、それらのサプライヤ間での引継ポイントを示します。サプライ・チェーンの管理は、それぞれのサプライヤの機能上の境界とパフォーマンスの目標値を明確に定義するこで、ビジネス・サービスレベルが確実に達成されるようにします。サプライヤ間に、適切に定義された少数のインタフェースがある小さなサプライ・チェーンの場合は、ビジネス・サービスの目標値を満たしやすくなります。

直接サプライヤの数を減らすと、管理するべき関係の数や、個別に関係しているサプライヤの問題の数が減少し、サプライヤ管理活動が単純になります。一部の組織では、サプライ・チェーン全体を「主」サプライヤと呼ばれる単一のサービス・プロバイダにまで縮小しています。一般的に施設管理は、単一の専門サプライヤが行い、このサプライヤがレストラン・サービス、清掃、および自動販売機の保守を外注する場合が多くあります。

しかし、「主」サプライヤを利用すると別のリスクが生じます。そのため、重要な活動をアウトソーシングする前に、慎重にサプライ・チェーン戦略を検討する必要があります。サプライヤの数を減らす際は、アウトソーシングされるサービスの適用範囲を検討して、リスクが引き続き管理可能であり、供給市場の力量が適切であることを確実にしてください。



My N otes

SCDには、組織のサプライヤに関するすべての情報とともに、電子メール・サービス、PCの供給と導入、サービスデスク、契約などのサプライヤの製品またはサービスの詳細が含まれます。また、サポート協定および発注プロセスに関する情報も含まれます。SCDはCMSの一部で、CMSの中に含まれます。

SCDは、優先サプライヤの利用を促進したり、承認されていないか互換性のないアイテムを購入しないようにしたりするのに有益です。また、購買活動が体系化され、コントロールされるので、組織が優遇レートを交渉できるようにもなります。



My N otes

6.7　プロセスに関連する主要な測定基準、課題、CSF、リスク

サプライヤ管理のKPIサプライヤ管理の測定基準は、サービス、顧客、および事業の観点から策定することができます。

例えば、次のようなKPIを使用することが考えられます。

サプライヤの不十分なパフォーマンスや中断から事業を保護 yするためのKPI

サービス目標値を達成するサプライヤ数の増加 o

サービス目標値に対する違反数の減少 o

支援サービスとその目標値を、ビジネス・ニーズに整合させ yるためのKPI

サプライヤと一緒に行う、サービスおよび契約に関 oするレビューの頻度の増加

SLAおよびSLRの上位目標値と整合している、サプラ oイヤの目標値と契約上の目標値の数の増加

サービスの可用性を確実にするためのKPI yサプライヤ側のサービス違反数の減少 o

サプライヤ側のサービス違反に至るおそれがあった o回数の減少

サプライヤおよび契約の課題に関する明確なオーナシップを y定義し、認識を高めるためのKPI

指名されたサプライヤ・マネージャを持つサプライ oヤの数の増加

指名された契約マネージャを持つ契約の数の増加 o

サプライヤ管理の課題サプライヤ管理は次のような課題に直面する可能性があります。

現在のサービスの提供と併せて、事業とITのニーズの変化を y管理すること不十分な目標値または諸条件を持つ、理想的ではない契約 yによって業務を行うこと特に最近アウトソーシングされたサービスに伴う、引き継が yれてきた課題組織内での専門知識の不足 yすでに現実的ではないが、早期終了に対して懲罰的な違約金 yのある長期契約によって業務を行うこと



My N otes

例えばデータ入力など、サービス提供の履行でサプライヤが y組織に依存するような、不十分なサービス・パフォーマンスに対する説明責任の混乱料金に関する争議 y一方の当事者による、他方の内部業務の妨害 y日常業務に押されてプロアクティブなアプローチが不足する yことコミュニケーションの不足。頻度も迅速さも不十分で、扱う課 y題が不適切個性の衝突 y一方の当事者が他方の当事者を搾取するために契約を利用 yし、その結果、損得のある変更になること運用上の課題を重視しすぎて、その結果、戦略的関係の最終 y目標を軽視すること

これらの問題は、次のようにして回避することができます。

契約を、記述において明確に定義し、適切に管理する。 y相互に利益のある関係を構築する。 y両者において役割と責任を明確にする。 yコミュニケーションのための良好なインタフェースを構築す yる。両当事者についてサービスマネジメント・プロセスを定義す yる。ISO 9001などの国際的に認識された認証を持つサプライヤ yを選択する。

サプライヤ管理のCSFサプライヤ管理のCSFは次のとおりです。

サプライヤの不十分なパフォーマンスや中断から事業を保護 yする。支援サービスとその目標値を、事業の達成目標および目標値 yに整合させる。サービスの可用性がサプライヤのパフォーマンスによって妨 y害されないようにするサプライヤおよび契約の課題に関するオーナシップと認識を y明確にする



My N otes

サプライヤ管理のリスクサプライヤ管理に関連する重大なリスクは次のとおりです。

サプライヤ管理プロセスへのコミットメントが不足している y事業および上級マネジメント将来的な事業およびITの方針、計画、および戦略に関する情 y報の不足情報セキュリティ管理プロセスに対する予算やリソースの不 y足ビジネス・ニーズおよびSLAとSLRの目標値をサポートしな yい、契約の不十分な記載非現実的な目標値に合意するサプライヤ、または契約条件を y満たすことができないサプライヤサービス・プロバイダまたは事業のカルチャと一致しないサ yプライヤの組織のカルチャサプライヤ管理プロセスを進んで支援しないサプライヤ yサプライヤ引き継ぎの際の、関係、スタッフ、および契約の変 y更極めて官僚主義的な、企業のサプライヤと契約の手順の要求 yサプライヤ管理を支援しない、企業の財務プロセス y



My N otes

6.8　インプットとアウトプット

サプライヤ管理のインプットサプライヤ管理へのインプットは次のとおりです。

事業情報：組織の事業戦略、および財務やその他の計画から y得られます。現在および将来の事業の要件に関する情報が含まれます。サプライヤと契約の戦略：サービス・プロバイダのソーシング y方針および使用されるサプライヤと契約の種類が含まれます。サービスストラテジがこのインプットを提供します。サプライヤの計画と戦略：サプライヤの財務状況、計画され yた事業の実行可能性、および技術開発と併せて、サプライヤの事業計画と事業戦略の情報が含まれます。サプライヤとの契約、合意、および目標値：既存および新規の yサプライヤの契約と合意に関する情報が含まれます。サプライヤと契約のパフォーマンス情報：既存および新規の yサプライヤの契約と合意に関する情報が含まれます。IT情報：ITの戦略、計画、および予算から得られます。 yパフォーマンスの課題：サプライヤまたは契約の不十分なパ yフォーマンスに関連するインシデントと問題に関する情報が含まれます。インシデント管理と問題管理がこのインプットを提供します。財務情報：期待される事業利益と財務計画と予算を併せた、（ y複数の）サプライヤ・サービスのコスト、契約のコスト、およびサービスとサプライヤの障害のコストが含まれます。

サービス情報：サービス・ポートフォリオとサービス・カタログ yからのサービスの詳細、SLAおよびSLRのサービスレベル目標値の詳細、およびサービス・レビュー、SLA、およびSLAの違反のモニタリングに関する情報が含まれます。さらに、顧客満足度のデータが含まれることもあります。CMS：事業、サービス、支援サービス、および技術の間の関係 yについての情報が含まれます。

サプライヤ管理のアウトプットサプライヤ管理は、他のプロセスや組織の他の領域に対してインプットを提供します。このインプットから電子レポートが作成され、共有エリア上またはイントラネット・サーバのページ上に表示されます。



My N otes

サプライヤ管理のアウトプットは次のとおりです。

SCD ― サプライヤ管理のすべてのサブプロセスに情報を提 y供し、その後、プロセスの他の領域で利用されます。サプライヤおよび契約のパフォーマンス情報と報告 ― 共有 yしているリスクに関する情報など、サプライヤと契約のレビュー・ミーティングへのインプットを提供します。サプライヤおよび契約のレビュー・ミーティング議事録 ― サ yプライヤ・レビュー・ミーティングの議事録および対応を記録します。サプライヤのサービス改善計画（SIP） ― すべての改善およ yび処置計画を記録します。これらの計画は、サービス・プロバイダとサプライヤとの間で合意された改善処置の進捗を追跡するために使用できます。サプライヤ調査レポート ― サプライヤと取り引きするサービ yス・プロバイダ組織の従業員からのフィードバックを記録します。こうしたフィードバックは、サプライヤ・サービスの品質をより一貫したものにするために役立ちます。これらのレポートは、サプライヤ間の競争を促進するための業績比較表として発行される場合があります。

サプライヤ管理プロセスは、次のようなイベントによって引き起こされます。

新規または変更されたコーポレート・ガバナンス指針 y新規または変更された事業およびITの戦略、方針、または計 y画新規または変更されたビジネス・ニーズや、新規または変更 yされたサービスSLR、SLA、OLA、または契約などの合意内の新規または変更 yされた要件設計と戦略のレビューと改定 yサプライヤ管理の方針、レポート、および計画のレビューと改 y定を含む、レビュー、改定、報告などの定期的な活動他の領域、特にSLMおよびセキュリティ管理からのサプライ yヤの課題に関する支援の要求新しい契約、契約更新、または契約終了の要件 yサプライヤや契約の再カテゴリ化 y




My N otes

サプライヤ管理と他のプロセスとの主なインタフェースは次のとおりです。

ITSCM ― 内部と外部両方の、継続性サービスのサプライヤ yを管理します。SLM ― 目標値、要件、および責任が、該当するSLAとSLRの目 y標値をサポートするようにUC内で定義します。このインタフェースには、サプライヤの不十分なパフォーマンスに起因するSLAおよびSLRの違反を調査することも含まれます。情報セキュリティ管理 ― サプライヤ、サービスやシステムへ yのサプライヤのアクセス、および情報セキュリティ管理の方針および要件に関するサプライヤの責任を管理します。財務管理 ― サプライヤ管理の要件および契約に資金を提供 yし、購買および調達の課題に関して助言と方向性を提供します。サービス・ポートフォリオ管理 ― すべての支援サービスの詳 y細によってサービス・ポートフォリオが更新されるようにします。



My N otes




現在契約しているサプライヤと、将来的に契約する可能性があるサプライヤの品質を改善するために、マネジメント・チームは、サプライヤとの現在の関係を管理するサプライヤ・マネージャを任命する予定です。マネジメント・チームは、サプライヤ管理の役割において達成目標を達成するための適切なアプローチと考えられることに関して、責任リストの草案を作成しました。

次に草案を示します。

サプライヤ・マネージャは、サプライヤ管理プロセスの確実な実現に責任を負います。これに加えて、サプライヤ・マネージャには次のような責任もあります。

すべてのITサプライヤから投資に見合う価値が得られるよう yにする。サプライヤ契約データベースを維持管理し、レビューする。 yUC、合意、およびSLAとビジネス・ニーズの整合性が取られて yいることを確実にする。統括サプライヤと再委託先サプライヤ間の役割と関係を文書 y化および維持し、会社との契約上の合意の対象にする。契約上の争議に対処するプロセスを維持し、いかなる争議に yも効率的かつ効果的な方法で確実に対処する。サードパーティ・サプライヤ向けのSLA、契約、合意、または他 yのあらゆる文書を作成してレビューする。サプライヤおよび契約のそれぞれのオーナシップが確実に整 yっているようにする。サードパーティ・サービスの利害関係者、顧客、および重要な yユーザとの関係とコミュニケーションを構築する。



My N otes

この役割の説明は、どこに誤りがありますか？Q1.

会社はすでにSLMを導入しているため、サービスレベル・マa) ネージャは、UCおよびSLAと事業との整合性が取られていることを徹底し、契約における争議を管理することに責任を負います。

ITILのプラクティスの観点から、サプライヤ・マネージャは、サb) ードパーティ・サービスの利害関係者、顧客、および主要なユーザとの関係とコミュニケーションを構築する責任は負いません。また、契約上の争議に対して責任を負いません。契約上の争議はサービスレベル・マネージャの責任です。

会社はすでにSLMを導入しているため、サービスレベル・マc) ネージャは、サードパーティ・サプライヤ向けのSLA、契約、合意、および他のあらゆる文書を確実に作成およびレビューすることに責任を負います。SLMは、サードパーティ・サービスの利害関係者、顧客、および主要なユーザとの関係とコミュニケーションを構築することに責任を負います。

この説明は、ITILのすべてのベストプラクティスに当てはまりd) ます。サプライヤ・マネージャに関してここに挙げた役割はすべて、ITILによって推奨されています。これには、SLAを通じた必要なSLMの妥当性確認だけでなく、サプライヤ・マネージャが事業とサプライヤの両方とやり取りする方法が説明されています。



財務管理ユニット7

Student | ITIL v3 Intermediate Certification Level | Financial Management


My N otes

ユニット7:財務管理

概要財務管理は、意思決定と運用上の透明性の改善に役立つ財務データを生み出すので、ITと同様に事業にとっても極めて重要です。この種のデータは、事業にとって価値のある洞察ももたらします。技術および革新がますます収益を増大させる主要な推進要因となるにつれて、ITに対する財務管理の価値は確実に上昇しています。


財務管理プロセスの最終目標と達成目標を説明できる。 yプロセスの適用範囲を分析し、説明できる。 yサービス査定に関する概念を説明できる。 yサービス・ライフサイクルに対する財務管理の重要性と、事業 y上の価値への財務管理の貢献を理解できる。財務管理に関する概念とプロセスを挙げることができる。 y投資利益率（ROI）およびビジネス・ケースを作成できる。 yプロセスに関する活動、手法、および技法を挙げることができ yる。財務管理プロセスをどのように設計し、実施するかを説明で yきる。


目的：財務データの分析は、組織が、その財務パフォーマンスをどのように改善するかを理解するために有益です。財務管理では、適切な財務データが記録されるようにします。この記録は、運用上の可視性、洞察、および優れた意思決定のスキルなどの中核能力を組織が開発するのに役立ちます。

財務管理は戦略ツールとして、3つの種類のサービス・プロバイダすべてに対して有益です。

外部 y内部 yシェアード・サービス部門 y



My N otes

今日の事業環境では、内部サービス・プロバイダは財務管理のプラクティスを採用して、事業部門や外部プロバイダと同じレベルの財務的透明性と説明責任を維持しなければなりません。多くの企業にとって、技術と革新が急速に主要な収益推進要因となりつつあるため、これは必要なことです。

財務管理は、ITサービスおよび資産の財務的価値を定量化し、運用上の予測の正当性を確認することで、事業に恩恵をもたらします。そのため財務管理は、サービスの価値を識別し、文書化し、合意するために、また、サービス需要のモデル化を実施し、管理するために協働するよう、ITおよび事業に要求します。組織の中でITがどのように見られているかを一変させるために、ITをサービスの観点で考える必要があります。

最終目標：意思決定を強化する。 y変更のスピードを加速する。 yサービス・ポートフォリオ管理を改善する。 y財務上のコンプライアンスとコントロールを確実にする。 y優れた運用上のコントロールを提供する。 y価値の獲得と創出を促進する。 y

達成目標：サービスを評価する。 y需要モデル化を実施する。 yサービス・ポートフォリオを管理する。 yサービス供給を最適化する。 y計画立案の信頼度を確保する。 yサービス投資を分析する。 y会計機能を実施する。 yコンプライアンスを保証する。 y変動費力学（VCD）を分析する。 y

ここでは、財務管理の目的、最終目標、達成目標について学習しました。次に、プロセスの適用範囲について学習します。



My N otes


IT財務管理の適用範囲IT財務管理は、事業の中で行われる財務管理の方法によく似ています。IT財務管理は、ITの財務と会計の部門に限定されません。組織のさまざまな部分、例えば運用部門とサポート部門、プロジェクト管理組織、アプリケーション開発、インフラストラクチャ、変更管理、事業部門、エンド・ユーザなどの間でのやり取りが、ITの財務情報を生み出し、消費します。これらの各部分は、それぞれに関係する財務データを収集し、共有し、維持管理します。

ITが使用する財務管理データのオーナシップは会計と財務部門にありますが、このデータを適切に作成し、使用する責任は全員にあります。

財務管理の活動財務管理が実施する活動は次のとおりです｡

組織全体からデータのインプットを収集する。 yサービス査定、需要モデル化、およびサービス・ポートフォリ yオ管理などの重要な意思決定や活動に必要な情報を生み出し、伝えることを支援する。

今日のIT組織は、市場に向き合っている他のあらゆる企業によく似ています。IT組織は、他の事業と同様に、サービスを分析し、パッケージ化し、売り込み、提供する必要もあります。また、需要と供給の要因を理解しコントロールすることや、関連するコスト構造への可視性を最大化しつつ可能なかぎり費用対効果が高くなるようにサービスを提供することも必要です。

ITはサービス提供内容を改善しながらコストを下げることを追求するので、IT組織と、市場に向き合っている企業とが共有するこの必要性は、事業にとって大きな価値となります。

財務管理はどのようにITに役立つか？財務管理が財務管理の一環として収集し、絞り込み、配付する運用上の意思決定のためのデータは、実際のサービスと、サービス・ライフサイクルの設計戦略の段階で大いに活用されます。



My N otes

財務管理は、意味のある重要なパフォーマンス・データを生み出します。組織はこのデータを利用して、次のような重要な質問に答えを出すことができます。

組織の差別化戦略は利益や収益の向上、コスト削減、サービ yス採用度の向上につながっているか？どのサービスに最もコストがかかるのか、それはなぜか？ y組織で消費されているサービスの量と種類、また相関する予 y算要件は何か？組織のサービス供給モデルの効率性は、代替のモデルと比較 yしてどうか？サービス設計に対する組織の戦略的アプローチは、競争力の yある「市場価格」で提供できるサービスか、大幅にリスクを低減するサービスか、またはより高い価値をもたらすサービスにつながっているか？組織のサービスの中で最も非効率な部分はどこか？ y最も優先度が高く、重点を置くべき組織の機能領域は何か？ y

正確な運用上の財務情報がなければ、組織はこれらの質問に正しく答えることはできません。このような質問に答えなければ、すべての戦略的意思決定が、単独の組織部門から受け取ることの多い、不備や限界のある観察と情報に対する直観的な対応となってしまいます。このような不正確な手法が原因で、サービス戦略、サービス設計、または戦術的な運用上の意思決定に関して、組織が不適切で誤った決定をすることが多くなるでしょう。



My N otes

7.3　サービス査定の概念

サービス査定の定義サービスを提供するために、事業とITは資金を要求します。組織はこれらの資金を、提供されるサービスの価値に照らして測定します。この定量化のプロセスをサービス査定と言います。

サービス査定の概念サービス査定プロセスは、財務管理がサービスまたはサービス・コンポーネントに対して金銭的価値を計算し、割り当てるときに始まります。サービスの価格設定とは、コストを価値に変換することです。この変換は、サービスの需要と消費を管理しやすくします。

サービス査定には、次の2つの活動があります。

サービスのコスト・ベースラインを明確にする。 y最終的なサービス価値を算出するために、プロバイダのサー yビス資産によって付加された認識される価値を定量化する。

サービス査定の達成目標は次のとおりです。

事業が公正と考えるサービスの価値を生み出す。 y継続的な課題としてその価値をサポートするためのプロバイ yダのニーズを満たす。需要と消費の動向の管理を改善する。 y

ITILによれば、価値は、サービス・プロバイダがその能力とリソースを展開でき、一定レベルの確信を持って顧客にサービスのより高い有用性を提供できるときに生み出されます。

保証と有用性というサービス価値の要素は、金銭的価値で評価されるべきです。そのため、サービス査定は主に次の2つの主要な査定概念に焦点を当てます。

供給価値 yサービスの潜在的価値 y

サービスを提供するには、ITにコストがかかります。供給価値とは、サービスの供給に関連してITにかかる実際の基本的なコストです。インプットは財務システムから提供され、これはサービス供給においてITが使用した実際のリソースに対する支払い額で構成されます。

このIT関連サービスの原価要素には次のような項目が含まれます。

ハードウェアとソフトウェアのライセンス・コスト yハードウェアとソフトウェアの年間保守費 yサービスのサポートや保守に使用された人的リソース y



光熱費、データセンタなどの設備の費用 y税金、資本費、利息 yコンプライアンスのコスト y


サービス価値のベースラインは、実際のサービス・コストの合計です。サービスの最小価値は、ベースラインから計算されます。

ITサービスの顧客は、サービス・パッケージ全体の一部である付加価値コンポーネントに基づくサービスの価値を認識します。付加価値コンポーネントの金銭的価値と供給価値が、サービスの最終的価値となります。

顧客資産

潜在的パフォーマンス

サービスの潜在的価値サービスの供給価値

サービスレベルの設計時のパフォーマンスと実現されたパフォーマンス

サービス資産

解き放たれた潜在的価値

求められる成果サービス価値

の実現



My N otes

価値の定義この図は、供給価値と認識されたサービスの潜在的価値の相互に関連する概念を示しています。供給価値は、購入情報や人事情報が利用できることから、より計算しやすいものです。サービス指向アプローチを組み込んだ新しい会計手法は、サービスの潜在的価値の識別に役立ちます。

サービス査定活動を理解するには、次の用語を理解する必要があります。

直接費と間接費 y労務費 y変動費 y

サービスの潜在的価値前述の用語についてのナレッジを得るだけでなく、原価勘定データをサービス価値にどのように変換するかを理解することも重要です。この図は、この種の変換を示しています。

特定のサービスに関連するコストを直接費と言います。複数のサービスで共有されるコストは間接費です。これらのコストは、利用できるデータと必要な労力の量に応じて、どの費目を扱うべきかを判断するのに役立ちます。例えば、ハードウェア保守サービスのコンポーネントはその数が膨大すぎて分解できません。直接費と間接費は、各費目の原価を、より重要なコンポーネントだけに割り当てることに役立ちます。

コストを適切に識別したら、これらのコストを複数のサービスに配賦するための規則を定義することが必要になるでしょう。

組織は、人件費を組織のすべてのサービスに割り当てます。これらのコストは労務費と言います。さらに、組織は、すべてのITサービスの管理費を割り当て、これらのコストをどのように複数のサービスに配賦するかについての規則も作成することができます。

組織は、ある1つのサービスに固定費を割り当てることができません。このような場合のコストは、ユーザ数やインスタンス数など、多くの要素に応じて変動します。このようなサービスに割り当てられるコストを変動費と言います。コストの変動を招くサービスは、長期的には予測できるようにする必要があるため、組織はそのようなサービスを特定する必要があります。



My N otes

このようなサービスを特定し、変動費を予測することに役立つ可変要素は、次のとおりです。

階層化：サービス・プロバイダ内部で価格区分が生じるとき、 y顧客が規模の効率性を得ることができる。このような価格区分を階層化と言う。最大コスト：サービスは、変動の最大レベルに達することがあ yる。このレベルで規定されるコストを最大コストと言う。平均コスト：サービスの変動の平均に基づいてサービスのコ yストを設定することができる。このようなコストを平均コストと言う。

サービス価値を原価勘定データから計算するには、コストを原価勘定にではなく、サービスに配賦する必要があります。この変換により、サービスのコスト構造の透明性が高くなります。

原価勘定データのサービス価値への変換原価勘定データをサービス価値へ変換するステップは、次のとおりです。

基礎となるコスト・ベースラインを決定するために、サービス y指向のコスト項目を取得する。顧客のサービス資産に、保証と有用性を拡張した金銭的価値 yを加える。固定費および変動費を確定する。 y変動範囲と、コスト変動の推進要因を特定する。 y



My N otes

7.4　サービス・ライフサイクルに対する重要性と事業上の価値への貢献

財務管理財務管理は、IT組織と事業が、実際の証拠（つまり、コストと価値を比較して出した実際のコスト）に基づいて意思決定するのを助けるためのプロセスです。財務管理は、事業が、サービスの価値、資産の価値、および運用上の予測の品質を定量化することを助けます。財務管理は、サービス・プロバイダの戦略ツールとしても機能します。今では、技術と革新が収益の主要な推進要因となることが多いため、内部サービス・プロバイダは、事業部門や外部サービス・プロバイダと同じレベルの財務的可視性と説明責任を持って運用する必要があります。

次のようなことが原因で、ITに顕著な変化が起こっています。

戦略的なビジネス・モデルと提供モデルの急速な発展 y製品開発サイクルの短縮 yデザイン重視の使い捨て製品の増加 y

こうした変化は、運用上の可視性とコントロールを維持しながら、より優れたパフォーマンスおよび事業との整合を要求するという、優先事項の矛盾をもたらしています。

市場に向き合っている企業と同様に、IT組織もサービスを分析し、パッケージ化し、売り込み、提供する必要があります。また、需要と供給の要因をコントロールし、コスト構造の透明性を備えた費用対効果の高いサービスを提供しなければなりません。ITが低コストで優れたサービスを提供しようと努力するので、この類似性は事業の利点となります。



可視化され、一貫した運用コスト構造

サービス消費のモデル化、査定、計画立案の信頼度

サービス投資分析

以下の急速な変化をサポートする

財務プロセス：－予算－ビジネス・ニーズ－バリュー・

ネットワーク?

サービス・ポートフォリオの管理と最適化

既知の変動費力学

サービス供給の最適化

財務上のコンプライアンス

IT財務管理

ITガバナンス

顧客

サービス・

プロバイダ

関心と利点の共通性



My N otes

事業とITこの図は、事業とITとの間の関心と利点の共通性を示しています。財務管理は、サービス戦略とサービス設計に関する意思決定を助ける運用上のデータを蓄積し、絞り込み、配付します。また、組織が重要なパフォーマンス・データを生み出すのを支援します。

財務管理はITと事業の間の橋渡しとして機能し、サービス査定はITの真の価値を事業が理解できるようにします。サービス査定は、サービスレベル管理（SLM）とともに、サービスとは何か、そのコンポーネントは何か、実際のコストはどのようであるかという共通の定義を事業とITが定めるのに役立ちます。

サービス査定は、さらに、ITと事業顧客とのやり取りを変革します。財務管理が提供するコストの透明性を、サービス・カタログに組み込むことができます。これは、顧客がITサービスを計画し、消費する方法に影響を与えます。これを計画立案プロセスに組み込むと、需要モデル化や資金調達において事業を助け、大幅なコスト節減と需要管理能力の拡大につながります。



My N otes

7.5　基本概念 ― 資金調達、会計、課金

計画立案の信頼度財務管理の重要な最終目標は、サービスの提供と消費に適切な資金調達を確実に行うことです。この最終目標を達成するには、優れた財務管理の計画立案が必要です。計画立案は、次の点についてIT組織を支援します。

ITサービスに対する将来の需要を予測する。 yITサービスの需要と供給の差異に重点を置く。 y

財務管理は、IT組織の全領域からインプットを収集し、そのインプットを計画立案の3つの主な領域にカテゴリ化することで、計画立案プロセスを開始します。計画立案の3つの主な領域は次のとおりです。

総勘定元帳と固定資産元帳を扱う、運営と資本の計画立案 y需要の計画立案 y規制と環境、またはコンプライアンス関連の計画立案 y

計画立案のそれぞれのカテゴリは、可視性とサービス査定に必要な財務的結果を表します。

次に、計画立案の各カテゴリにおける計画立案のプロセスを理解しましょう。

運営と資本運営と資本の計画立案プロセスには、IT経費を企業の財務システムに織り込むこと、ITサービスの資金調達において想定される変更を他の事業領域に伝達すること、IT資産の変化の状態を更新することが含まれます。運営と資本の計画立案プロセスは、かなり標準化されています。

規制と環境に関連する計画立案プロセス規制と環境に関連する計画立案プロセスは、事業内で生じたトリガを受け取ります。しかしながら、財務管理も、関連するサービス価値に対してコスト・ベースか価値ベースかを問わず適切な財務上のインプットを確実に適用するべきです。



My N otes

信頼度信頼度とは、サービスの需要と供給の財務的インプットとモデルは正確で統計的に重要なデータを提供するという概念を指します。

データの信頼度は、財務管理が次のことを行うのに役立ちます。

達成目標を実現する。 yデータ計算中に起こりうるエラーを防止する。 y意思決定能力を改善する。 y

財務管理は、固有の財務的変換と必要条件設定の機能を実行するため、計画立案のデータと情報の信頼度を高いレベルで維持する必要があります。計画立案の信頼度には、測定可能な財務要件として表したサービス指向の需要モデル化と、高い統計的精度が必要です。

次に、財務管理がサービス投資分析をどのように行うかを理解しましょう。

サービス投資分析財務管理は、IT組織のためにサービス投資分析を行います。サービス投資分析には次の活動があります。

共有分析モデルとナレッジを提供する。 y規模、適用範囲、リソース、コスト、および関連パラメータに基 yづいて、さまざまなプロジェクトにおいて必要とされるレベルの分析上の精巧さを組織が判断する手引きとなる、しきい値を設定します。

財務管理が提供する分析モデルとナレッジは、IT組織が、与えられた取り組み、ソリューション、プログラム、プロジェクトの想定価値や利益を評価するのを助けます。このしきい値は、プロジェクトに必要な分析レベルをIT組織が決定するのに役立ちます。

サービス投資分析の最終目標は、ライフサイクル全体の価値指標を導き出すことです。サービスの価値指標を導き出すために必要なインプットは、得られる価値と、サービスの提供にかかるコストです。

財務管理は、IT投資分析を行うための手法、モデル、活動、および技法を使用します。

財務管理のモデル財務管理は次のモデルを使用します。

サービス査定 yマネージド・サービス供給モデル yシェアード・サービス・モデル y資金調達モデルの選択肢 yビジネス・インパクト分析（BIA） y



My N otes

投資分析に対する想定事項のインパクトサービスに関する想定事項は、投資分析の鍵です。こうした想定事項は、分析の成果に大きなインパクトを持ちます。

財務管理の会計財務管理の会計は、従来の会計とは異なります。サービス指向の費用や資本アイテムを追跡するための追加的なカテゴリが必要です。財務管理は企業の財務システムとサービスマネジメントとの間の橋渡しとして機能します。サービス指向の会計は、サービスの供給と使用についての深い理解をもたらし、計画立案プロセスのためのデータのインプットを与えます。

必要な機能と会計の種類は、次のとおりです。

サービスの記録 ― 適切なサービスと下位サービス・コンポ yーネントにコスト項目を割り当てる。原価費目 ― ハードウェアや労務などの上位レベルの費用を y分離する。サービスの需要と利用を財務用語で報告し分析することに役に立つ。コストの分類 ― サービス内のコストの最終目的を分類する。 y考えられる分類には、資本／運用（事業や規制によって必要とされる会計方法論に対応）、直接／間接、固定／変動、および原価単位などがある。

サービス指向の会計によって、より上位レベルのサービス戦略の開発と実行が可能になります。

次に、課金モデルについて理解しましょう。

課金モデルIT組織の中には独自に資金調達をする組織もあり、その場合は財務の仕組みが複雑で成熟しています。課金モデルはより大きな説明責任と可視性を与えるので、こうした組織に最適です。しかし、現在のモデルでより単純な年次の資金補充を行っている場合、説明責任や透明性は不要になることもあります。この場合、透明性は、計画立案、需要モデル化、およびサービス査定の活動とアウトプットから生まれます。

組織は、次のようにして可視性をもたらします。

サービス・ポートフォリオおよびサービス・カタログを識別す yる。ITサービスを価値査定する。 y需要モデルや消費モデルに価値を適用する。 y

組織は、次のようにして説明責任を果たします。

合意されたレベルでサービスを提供する。 yサービスに資金を提供する。 y



My N otes

しかし、サービスとは何か、そして、それが事業にどんな価値を提供するかについての理解が一致しないことが原因で、認識される価値が資金から乖離していると、説明責任を果たすのは難しくなります。従って、運用の仕組みも考慮されて初めて、課金の説明責任を果たすことができます。

課金モデルの達成目標課金モデルの達成目標は次のとおりです。

行動の変化を促して、ITサービスに対する需要に影響を与え yる。事業に価値を加える。 y予測可能性を与える。 y

課金モデルは、計算の単純さと、事業がそれらを理解できるかどうかによって異なります。

課金モデルとコンポーネントの例課金モデルとコンポーネントの例を幾つか挙げます。

概念上の課金 y階層別支払い y従量制 yダイレクト・プラス y固定制またはユーザ・コスト y

概念上の課金概念上の課金モデルは企業の財務システムに仕訳記入を行うかどうかに対応します。課金のプラクティスを、ある方法論から別の方法論に移行している場合には適切な暫定的モデルです。

概念上の課金モデルは、企業の財務システムに仕訳記入を行うにあたって、2つの選択肢を組織に与えます。概念上の課金の種類の1つに「2帳簿」方式と呼ばれるものがあります。2つの帳簿のうちの1つでは、必要とされる方法で企業財務システムにコストを記録し、2つ目の帳簿は付けますが記録はしません。この2つ目の帳簿は、同じ情報を、採用されていたかもしれない別の記録システムによって表します。このモデルは、課金のプラクティスを、ある方法論から別の方法論に移行している組織に適しています。



My N otes

階層別支払い階層別支払いの課金モデルでは、サービスの保証や有用性のレベルに基づいて、サービスをゴールド、シルバー、ブロンズ・レベルのサービスと呼び、サービスの各セットを適切な課金モデルで価格設定します。このモデルの短所は、利用に関して多様な行動を促進しないことと、受領拒否できないことです。

従量制従量制の課金モデルでは、需要モデル化とコンピューティング能力を利用し、時間数、日数、週数などの単位で顧客に課金します。このモデルには、成熟した財務環境と運用能力が必要です。

ダイレクト・プラスダイレクト・プラス課金モデルでは、あるサービスのコストが、その直接費と、そのサービスを作成するために事業の全部門で共有する間接費の一部を使用して計算されます。

固定制またはユーザ・コスト最も単純化された課金モデルで、コストを算出し、ユーザ数などの合意された分母で割ります。このモデルは顧客の行動に影響を与えず、実際のサービス需要を明確にすることもありませんが、簡単な方法でコストを複数の事業に配賦できます。

適切な課金モデルとは、事業に対して最大の価値をもたらすものです。



My N otes

7.6　ROIとビジネス・ケース

投資利益率

ROIは投資の価値を定量化します。

ただし、ROIの意味は一様ではありません。財務マネージャにとっては、ROIとは事業のパフォーマンスを測定する手段であり、投下資本利益率（ROIC）と呼びます。サービスマネジメントでは、資産から付加価値を生み出すための能力を測定するためにROIを使用します。

資産への付加価値は、投資の正味利益を、投資した資産の正味価値で割って計算します。単純化すると、次のようになります。

ROI（サービスマネジメントに対する）= 投資の正味利益

投資した資産の正味価値

ROIは自明な数値指標であることから、多くの組織がROIを利用してサービスマネジメントの採否を決定しています。しかし、短期に焦点を当てる場合のROI算出は、課題となることがあります。サービスマネジメントの実施は、さまざまな事業上のインパクトの変化に応じてさまざまなレベルのROIに関係します。実施の複雑性を定量化するのも困難な場合があります。

ROIの機能は、組織の規模に依存します。小規模な組織は、ROIの助けがなくても利益を計算できます。大きな組織ではさまざまな投資があるため、ROI分析が必要です。

サービスマネジメントは戦術的な利点をもたらさないので、サービスマネジメントからの財務的な利益は容易に識別できません。明らかな事業上の責務がなければ、ITILプロジェクトの資金を得ることはかなり困難になることがあります。

この難題には次の技法で対処します。

ビジネス・ケース yプログラム実施前ROI yプログラム実施後ROI y

ビジネス・ケースは、サービスマネジメントを必要とする事業上の責務を識別するための手段です。

プログラム実施前ROIおよびプログラム実施後ROIは、サービスマネジメントへの投資を分析する技法です。前者は定量的な分析を、後者は遡及的な分析を実施します。



My N otes

それではまず、ビジネス・ケースの定義、達成目標、およびインパクトを、例を使って理解していきましょう。

ビジネス・ケースITILによれば、ビジネス・ケースは、ある事業行動から起こりうる結果を定性的または定量的に予測する、意思決定支援および計画立案のツールです。財務分析は良いビジネス・ケースの中核となります。

ビジネス・ケースは、事業に対する利点やインパクトの詳細な分析を提供します。事業へのインパクトの調査は重要です。事業へのインパクトは事業達成目標に関連付けられるからです。

ビジネス・ケースの構造は均一ではなく、組織のニーズによって異なります。

ビジネス・ケース構造のサンプル

A.　概要サービスによって対応される事業達成目標を提示するB.　方法と想定事項期間、コスト負担先、メリット享受先などの、ビジネス・ケースの境界を定義するC.　事業へのインパクト財務的および財務以外のビジネス・ケースがありうるD.　リスクと緊急事態別の結果が発生する確率E.　推奨事項推奨される具体的な処置


事業達成目標事業達成目標は、営利組織と非営利組織とでは次のように異なります。

営利プロバイダ組織の事業達成目標は、事業そのものの達成 y目標になる傾向にあり、財務的および組織的パフォーマンスを含みます。非営利組織の事業達成目標は、財務的および組織的パフォー yマンスだけではなく、従事する人々の達成目標になる傾向があります。



My N otes

よくある事業達成目標

運用上財務上戦略的業界

開発時間の短縮

総資産利益率の向上

戦略的ポジショニングの確立または強化

市場シェア拡大

生産性の向上コスト回避競争力ある製品の導入

市場でのポジションの改善

キャパシティの増大

予算に占める自由裁量支出の拡大

組織のプロ意識の改善

取り引きのリピートの増加

信頼性の向上非自由裁量支出の減少

顧客満足度の改善

市場のリーダシップ獲得

リスクの最小化収益増大より良い品質

の提供

信頼性や品質の高い製品またはサービスの生産者として認められること

リソース活用度の改善利益幅の増大特別注文への

対応低価格のリーダとして認められること

効率性の改善支出の予算内への抑制

新製品または新サービスの導入

業界標準を遵守していると認められること


事業へのインパクトサービスマネジメントに対する事業へのインパクトは、財務的なものも、財務以外のものもあります。財務的なインパクトは、コスト分析に依存します。事業へのインパクトは、事業達成目標に関連付けられて初めて価値があります。事業達成目標に関連付けられた財務以外のインパクトを含んでいると、ビジネス・ケースはより説得力のあるものとなります。



事業へのインパクト事業達成目標

保守性の改善

具体的な指標：MTTR（平均修理時間）

インパクト：MTTRを6時間から2時間に

より低いコスト

具体的な指標：

サービス提供コスト

目標：サービス提供コストを30%削減

顧客満足


取り引きのリピート率

目標：リピート率を25%から60%に改善

市場イメージ


顧客満足度調査

目標：業界での格付けを3位から1位に改善



事業達成目標

顧客満足


取り引きのリピート率

目標：リピート率を25%から60%に改善

事業へのインパクト

信頼性の改善

具体的な指標：MTBF（平均故障間隔）

インパクト：MTBFを600時間から200時間に

保守性の改善

具体的な指標：MTTR（平均修理時間)

インパクト：MTTRを6時間から2時間に

サービスの改善


製品をオンラインで注文できるよう

になっている

インパクト：製品を24時間365日、注文できる

プログラム実施前ROIマネージャは、将来利益をもたらすことになる長期のプロジェクトに対して予算を作成します。利益は、収益などキャッシュ・インフローの増大という形になることもあれば、節約などキャッシュ・アウトフローの削減という形になることもあります。このような種類の予算業務を資本予算と言います。

マネージャは、資本予算を作成しながら意思決定を行います。このような決定を大きく分ける2つのカテゴリは、次のとおりです。

ふるい分けによる決定 y選好的決定 y

ふるい分けによる決定ふるい分けによる決定は、新しいサービスマネジメントの取り組みが、最小利益額などの所定の基準を超えるかどうかということを扱います。

選好的決定では、競合する複数の選択肢から選択できます。例えば、内部SIPかサービス・ソーシング・プログラムかを選択できます。



My N otes

正味現在価値ふるい分けによる決定に正味現在価値（NPV）が望ましいのは、NPV法では、キャッシュ・インフローがキャッシュ・アウトフローと比較されるからです。この2つの差が、投資が適切かどうかを決定します。

NPVの判定

NPVの値：プログラムの可否：プラス許容可能。必要な利益率よりも高い利益が確実。ゼロ許容可能。必要な利益率と同等の利益が確実。マイナス許容不可。必要な利益率よりも低い利益が確実。


提案されたサービスマネジメント・プログラムのNPV

初期投資 £50,000

投資期間 5年年間コスト削減額 £16,500

残存価額 £0

必要利益率 20%

項目年数キャッシュ・フロー額

割引率20%

キャッシュ・フローの現在価値

初期コスト削減額 1～5 £16,500 2.991* 49,352

初期投資現在 (£50,000) 1 -50,000

正味現在価値 -£648

*年金1ポンドの5年後の現在価値


NPV法の利点NPV法の利点は次のとおりです。

NPVは使いやすい。 yNPVは、プログラムの利益率を利益率として想定しない。 yNPVは、プロジェクトの有効性の利益率について、より現実的 yな想定事項を用いる。



サービスマネジメントのNPVサービスマネジメントのNPVでは、会計上の純益ではなくキャッシュ・フローに焦点を当てます。この方法では税金に対する影響もありますが、減価償却は控除しません。割引現在価値法では元の投資の回収が自動的に考慮されており、減価償却の控除は不要です。

初期投資以外のキャッシュ・フローはすべて期間の終わりに発生するという前提で、この方法の想定は単純化されています。キャッシュ・フローはその期間の任意の時期に発生するのが普通であるため、この想定は現実的ではないと思われます。

キャッシュ・フローの種類

代表的なキャッシュ・アウトフロー

導入コストも含めた資産への初期投資定期的な保守の費用トレーニングとコンサルティングに対する出費運用コストの増加運転資本の増加

代表的なキャッシュ・インフロー

収益の増加コスト削減運用廃止またはプロジェクト終了による旧資産の回収価値運転資本のリリース


選好的決定選好的決定、すなわち格付け決定やランク付け決定は、ふるい分けによる決定プロセスで対応できないすべての案件に対して行われます。選好的決定では、互いに競合する選択肢にランクが付けられます。選好的決定には内部利益率（IRR）、すなわち利回りが使用されます。IRRが高いほど、その取り組みは望ましいものです。



プログラム・コストの決定

プログラム達成目標

データ収集プログラムの効果の特定

データから金銭への変換

ROIの計算

定性的利益の識別

結果の伝達

プログラム実施後ROI明確に定義された財務達成目標は、サービスマネジメントの取り組みによって加えられる価値を測定することに役立ちます。この達成目標は、事業のリーダ、利害関係者、および顧客に、サービスマネジメントの価値を確信させることができます。組織は、サービスマネジメントへの投資の継続的な資金調達を確実にするために、頻繁にROI分析を実施する必要があります。

プログラム実施後ROIの達成目標プログラム実施後ROIの達成目標は次のとおりです。

安定した反復可能なサービスを提供する。 y総所有コストを削減する。 yサービスの品質を改善する。 y業界水準のベストプラクティスを導入する。 y全体的な構造とプロセスを提供する。 y共通した概念と用語の使用を支援する。 y



My N otes

7.7　活動、手法、技法、サービス・ライフサイクルとの関係

モデルと技法財務管理のモデルと技法には、次のようなものがあります。

サービス査定 yサービス供給モデルと分析 y資金調達モデルの選択肢 yビジネス・インパクト分析（BIA） y

サービス査定1. IT組織は、サービス査定活動中に次のような課題に対応する必要があります。

直接費と間接費 y労務費 y変動原価要素 y原価勘定データのサービス価値への変換 y

直接費と間接費直接費とは、特定のサービスに明らかに直接的に起因するものです。一方、間接費とは、複数のサービスで共有されるものです。

組織は、どの費目が次の条件に合うかを判断するために、これらのコストに賢明にアプローチするべきです。

扱うのが賢明である。 y利用可能なデータがある。 y必要とされる労力のレベルが適切である。 y

コストのコンポーネントの深さと幅を正しく識別することが重要です。識別したら、コストをどのように複数のサービスに配布するかの手引き、規則、方針が必要になるでしょう。



My N otes

労務費組織は、労務費についても重要な意思決定を行うべきです。この決定は「直接費と間接費」と類似していますが、時間追跡システムの複雑さと精度のため、さらに困難なものになっています。複数のサービスに配分したリソースを説明することができない場合は、労務費の配賦に対して規則や想定事項を作成しなければなりません。一般的で実際的な方法としては、サービス指向に基づく財務センタ全体に労務費を振り分けることで、人件費をサービスに整合させることができます。同様に、すべてのITサービスの管理費も、マクロ・レベルではある1つの財務センタにまとめることができます。このコストを複数のサービスに配賦する規則も作成できます。

変動原価要素変動原価要素には、ユーザ数や実行中のインスタンス数によって常に変動する費用が含まれます。変動は価格感度の主要な要因となりうるため、変動の度合いを大きくするサービスやサービス・コンポーネントを特定する能力に基づいて、組織は決定を下す必要があります。一定時間経過後の価格の変動から、予測を可能にする規則を作成することもできます。変動の大きいサービスにコストを関連付けるには、そのサービスの特定の消費を一定期間にわたって追跡する能力が必要です。これにより、変動の範囲が確定されます。

そのコストの予測可能性には、次の手段で対応できます。

階層化：プロバイダ内部で停滞が生じる部分で価格区分を明 y確にします。これによって、そのプロバイダが得意とする規模の効率性を得るよう顧客に奨励できます。最大コスト：変動の最大レベルに基づいてサービスのコスト yを規定します。おそらく、これによって過剰課金が起こりますが、事業は追加コストよりも割引を好むでしょう。平均コスト：変動の経時的な平均に基づいてサービスのコス yトを設定することです。計画立案サイクルの最後でコストに対応することができるように、ある程度の過剰課金と課金不足を許容します。



従来の勘定科目表

勘定科目表への請求の適用

給与 60,000サーバ保守 25,000ハードウェアの減価償却 15,000合計 100,000

サービス指向のIT会計

サービス指向のコストの会計と識別

サービス保守の請求 25,000* サービス：コラボレーション・サービスA* 原価費目：ハードウェア* 分類：

運用または資本

直接または間接固定または変動

*課金基準は製造番号

ハードウェアの減価償却 15,000* サービス：財務報告* 原価費目：ハードウェア

* 分類：運用または資本直接または間接

固定または変動*課金基準はユーザの内線番号

給与 60,000* サービス：サービス拡張プロジェクトABC* 原価費目：労務* 分類：

運用または資本直接または間接固定または変動

*課金基準は従業員ID

サービス指向の会計項目総計 100,000（同じく100,000であるが、サービス指向の会計として扱う）

サービス・コストの小単位：

コラボレーション・サービス

コラボレーション・サービスの総コスト

サービス・コスト #1 - 50,000サービス、コラボレーション・サービス年間保守

サービス・コスト #2 - 125,000コラボレーション・サービス

ソフトウェア

サービス・コスト #3 - 25,000コラボレーション・サービスその他の特性など

総サービス支出 225,000

サービス保守の請求は他のサービス

固有の請求と合計される

25,000

200,000

コラボレーション・サービスの査定

会計特性別のサービス・コスト内訳サンプル

コラボレーション・サービス総コストの特性別内訳

ハードウェア 150,000ソフトウェア 25,000 225,000 従来の原価会計労務 50,000運用 180,000資本 45,000 225,000 資本構成直接 51,000間接 55,000 225,000 利益構成固定 100,000変動 125,000 225,000 コストの変動性

支出小計 225,000

コラボレーション・サービスの潜在的価値の追加

有用性の最適化保証の強化 10,000 サービス改善の見積もり価値

付加価値小計 10,000

小計： 225,000 今期の資金基盤

予想されるピーク需要の変動 20%増大（減少） 47,000 追加資金要

282,000

サービス査定合計（将来） 282,000 将来必要な資金

従来の勘定科目表

勘定科目表への請求の適用

給与 60,000サーバ保守 25,000ハードウェアの減価償却 15,000合計 100,000

サービス指向のIT会計

サービス指向のコストの会計と識別

サービス保守の請求 25,000* サービス：コラボレーション・サービスA* 原価費目：ハードウェア* 分類：

運用または資本

直接または間接固定または変動

*課金基準は製造番号

ハードウェアの減価償却 15,000* サービス：財務報告* 原価費目：ハードウェア

* 分類：運用または資本直接または間接

固定または変動*課金基準はユーザの内線番号

給与 60,000* サービス：サービス拡張プロジェクトABC* 原価費目：労務* 分類：

運用または資本直接または間接固定または変動

*課金基準は従業員ID

サービス指向の会計項目総計 100,000（同じく100,000であるが、サービス指向の会計として扱う）

サービス・コストの小単位：

コラボレーション・サービス

コラボレーション・サービスの総コスト

サービス・コスト #1 - 50,000サービス、コラボレーション・サービス年間保守

サービス・コスト #2 - 125,000コラボレーション・サービス

ソフトウェア

サービス・コスト #3 - 25,000コラボレーション・サービスその他の特性など

総サービス支出 225,000

サービス保守の請求は他のサービス

固有の請求と合計される

25,000

200,000

コラボレーション・サービスの査定

会計特性別のサービス・コスト内訳サンプル

コラボレーション・サービス総コストの特性別内訳

ハードウェア 150,000ソフトウェア 25,000 225,000 従来の原価会計労務 50,000運用 180,000資本 45,000 225,000 資本構成直接 51,000間接 55,000 225,000 利益構成固定 100,000変動 125,000 225,000 コストの変動性

支出小計 225,000

コラボレーション・サービスの潜在的価値の追加

有用性の最適化保証の強化 10,000 サービス改善の見積もり価値

付加価値小計 10,000

小計： 225,000 今期の資金基盤

予想されるピーク需要の変動 20%増大（減少） 47,000 追加資金要

282,000

サービス査定合計（将来） 282,000 将来必要な資金

原価勘定データのサービス価値への変換この図は、財務管理が従来の原価勘定データをサービス勘定の情報に変換し、最終的にサービスの査定に変換する様子を示しています。

次に、サービス供給モデルについて理解しましょう。



サービス供給モデルと分析2. 財務管理は、サービス供給モデルを採用して、現在のサービス供給方法を分析します。サービス品質や移行の準備状況など財務以外の側面も重要ですが、このトピックでは次のようなサービス提供モデルの財務的側面のみを扱います。

マネージド・サービス供給モデル yシェアード・サービス供給モデル yユーティリティベースの供給モデル yサービス供給モデル y

マネージド・サービス供給モデル組織がマネージド・サービス供給モデルを使用する場合、事業部門が要求するサービスに対して、各事業部門が資金を用意します。サービス・プロバイダはサービスのコストを算出する際に、開発、インフラストラクチャ、および労務の費用を含めます。例えば、顧客固有のハードウェア、ソフトウェア、およびスタッフをサービスの管理のために使用する際、事業部門はそのサービスに対して料金を支払います。

1つの実体にサービスを提供するためにリソースを使用するので、このモデルは非常に高価です。ユーザがサービスと関連リソースを最大限に活用しない場合、使用されないキャパシティと、その同じキャパシティとリソースを利用して他のサービスを提供する機会が失われます。このような組織は、シェアード・サービス供給モデルを採用することで、リソースを適切に利用でき、コストを削減できます。このモデルでは、共有されたインフラストラクチャとリソースを利用して、複数のサービスを1つまたは複数の事業部門に提供します。

顧客1

顧客2

顧客3

顧客4

顧客5

サービス資産

顧客1

顧客2

顧客3

顧客4

顧客5

サービス資産



シェアード・サービス供給モデルシェアード・サービス供給モデルは、既存のリソースを最大限に活用することにより、大幅なコスト節減をもたらします。

シェアード・サービス・モデルをすでに採用している組織は、ユーティリティベースの供給モデルを採用することで、さらにサービスを強化できます。

ユーティリティベースの供給モデルこのモデルは、共有されたインフラストラクチャとリソースを利用して、サービスの組み合わせ数を最大にします。ユーティリティベースの供給モデルは、顧客がサービスをどれだけの量、どれだけの頻度で、またどのような時に必要とするかに基づいて、サービスを提供します。

組織は、技術アーキテクチャと顧客ニーズについての豊富なナレッジを活用して、既存リソースの利用を最大にするサービスの組み合わせとアーキテクチャを作成できるので、ユーティリティベースの供給は最も費用対効果の高いモデルです。

組織は、アウトソーシング・モデルを採用することができます。財務管理は、サービスのコスト・コンポーネントと変動費力学を明確にすることで、組織が、オンショア、ニアショア、オフショアのサービス供給の適切な組み合わせを得るのに役立ちます。

サービス供給モデルすべての供給モデルには、利点と欠点があります。組織は、最も有益なモデルを決定するためにサービス供給コスト分析を行います。この種の分析では、統計に基づいて供給モデルをランク付けします。

サービス供給コスト分析

サービス・コンポーネント

タイプⅠ プロバイダ

（内部）

マネージド・サービス

（オンショア・プロバイダ）

シェアード・サービス

（オンショア・プロバイダ）

マネージド・サービス

（オフショア・プロバイダ）

シェアード・サービス

（オフショア・プロバイダ）

コスト・スコア第1層サポート

（スタッフ10名） 10*40000/200000 2.9 2.1 1.8 1.5

第2層サポート（スタッフ10名） 3 3.5 3.2 2.2 1.9

第3層サポート（スタッフ10名） 4 4.8 3.8 3.5 3

サービスデスクのアプリケーション・ホスティング

1.2 1.5 1.5 1.1 0.6

コールセンタのインフラストラクチャ

1.5 1.5 0.8 0.5 0.4

小計 11.7 14.2 11.4 9.1 7.4



品質スコア第1層サポート

（スタッフ10名） 4 3 3.5 2.9 4

第2層サポート（スタッフ10名） 3 2 3 3 3

第3層サポート（スタッフ10名） 2 3.2 3.5 3.2 3.5

サービスデスクのアプリケーション・ホスティング

2.5 1 2 1.5 1.7

コールセンタのインフラストラクチャ

3.5 1 2 1 1

小計 15 10.2 14 11.6 13.2

合計 26.7 24.4 25.4 20.7 20.6


この表は、統計が供給モデルの分析にどのように役立つかを示しています。この例では、最も低い点が最も望ましい状態となるような、5段階に正規化されたスコア付けの仕組みを用いています。この企業は、幾つかのサービス・コンポーネントで、既存のプロバイダのほうが実際には1つを除く全領域で優れていても、他のプロバイダからも提供できるサービス品質とコストに対して、自身を低くランク付けしています。そのため、このプロバイダはコストと品質の正しい組み合わせを提供していないと考えられます。

次に、ITサービスの資金調達モデルについて理解しましょう。

資金調達モデルの選択肢3. 資金調達は、ITサービスの需要の変化による財務的インパクトへの対応と、日常的な運用を行うための資金の維持とを助けるため、IT組織にとって重要です。

資金調達モデルは、次の点において組織を支援します。

必要な情報を生み出す。 yサービス・コストおよび認識される価値を可視化する。 y

選択する資金調達モデルは、現在の事業のカルチャと期待に対して適切でなければなりません。

資金調達モデルの種類資金調達モデルには、次のものがあります。

ローリング・プラン資金調達 yトリガベースの計画 yゼロベースの資金調達 y



ローリング・プラン資金調達ローリング・プラン資金調達モデルでは、1つの資金調達のサイクルが他の資金調達のサイクルに置き換わるので、資金調達サイクルは継続的です。この計画は資金調達の一定のサイクルを推進しますが、精度は向上されません。このモデルは、組織が、サービスへの資金調達をサービス・ライフサイクルの最初に約束し、ライフサイクルが終了するか変更が行われるまで資金調達を継続する場合に、最もよく機能します。

トリガベースの計画トリガベースの資金調達モデルは、重要なトリガが組織内で発生したときに採用されます。資金は、事前に定義された計画に従って、トリガやイベントに対応するために割り当てられます。例えば、変更管理プロセスは、財務的インパクトを持つすべての承認された変更の計画立案に対するトリガとなります。このモデルを採用するには、トリガを予測し、トリガに対応するための計画を設定できなければなりません。この計画は、サービス・ライフサイクルを明確にするので、サービス・ポートフォリオ管理と組み合わせるとうまく機能します。このモデルは、すべての変更に対する将来の計画立案を必要とするので、不明確なイベントを防止します。

ゼロベースの資金調達ゼロベースの資金調達モデルは、IT組織内でどのように資金調達が行われるかを説明します。ITサービスを提供する実際のコストの分だけ資金が調達されます。このモデルでは、新たな資金調達サイクルが始まるまでは、IT財務サービスの残高ゼロを維持します。

最後に、BIAを使ってどのようにビジネス・インパクトを分析するかを理解しましょう。

ビジネス・インパクト分析4. BIAは、次の点において組織を支援します。

停止の重大度の財務価値と運用リスクを評価するための分析を行う。この分析は、企業の重要なビ yジネス・サービスの識別に役立つ。インシデント処理の優先度付け、問題管理などに関して、情報に基づいた決定を可能にすること yで、運用上のパフォーマンスを強化する。

ツールとしてのBIABIAは、次のものを識別するために有益なツールです。

サービス停止による会社へのコスト：「サービス停止のコスト」は、特定期間の特定のサービスにつ yいて失われた収益や生産性の財務価値を意味します。サービスの相対的価値：「サービスの価値」には、仕事をやり遂げたりクライアントと意思疎通した yりする能力など、収益発生には直接関係ない、サービスの財務以外の側面が含まれることがあります。



My N otes

BIA作成の活動BIAを作成するには、組織は次のことをする必要があります。

分析において協働する事業とITからリソースを手配する。 y組織の重要なサービスを識別し、それらを最重要、第2候補、 y第3候補などに分類する。リスクとインパクトの評価に役立ちそうな、次に示すような中 y核的な分析ポイントを識別する。これには次のものが含まれる。

売上収益の損失 o

罰金 o

障害リスク o

生産性の損失 o

機会の損失 o

影響を受けたユーザ数 o

株主、マネジメントなどに対する可視性 o

サービス陳腐化のリスク o

顧客、株主、規制当局などへの評判の低下 o


事業とともに、リスクとインパクトの要素を識別し、重み付け yする。重み付けしたリスクとインパクトの要素を基準に、候補となったサービスにスコアを付け、個々のリスク・スコアを合計する。リスク・プロファイルに従って、サービスのリストを作成する。 yサービス停止の財務コストへの変換を標準化するための共 y通時間を決定する。共通時間は、1分、1時間、または1日に設定できる。BIAで分析する各サービスの財務的インパクトを、合意された y手法、公式、および想定事項を使用して計算する。財務的インパクトに従って、サービスのリストを作成する。 yリスクと財務的インパクトのデータから、チャートを作成する。 yこのチャートによって、会社の中で最も高いリスクを持つアプリケーションが図示される。



この図は、比較スケール上で、サービスがどのように財務的インパクトとリスクの優先度を分析のポイントとして使用するかを示しています。

企業はシックスシグマ方法論を取り入れてBIAを強化することができます。さらに、シックスシグマ方法論は、故障モード影響解析（FMEA）への体系的なアプローチを可能にします。



My N otes

7.8　財務管理プロセスの設計と実施

財務管理を実施する際は、これを確実に段階的プロセスにする必要があります。段階とは、次のとおりです。

計画 y分析 y設計 y実施 y測定 y

次に、各段階を詳しく学習しましょう。

計画計画の段階は段階1とも言います。この段階では、次の活動を行う必要があります。

事業およびITのカルチャに関する重要な課題に対応する。 y企業のカルチャを評価し、単一個所にあるのか、世界に分散 yしているのかなど、地域固有のコンプライアンスと規制上の課題を検討する。ITの財務情報を提供、要求する連絡窓口をすべて識別する。 yITと事業の期待、特に成果物に関するものを識別する。 y財務管理からデータを提供または受領するシステムを識別す yる。利用する資金調達モデルや運用モデルを識別し、これによっ yて会計と査定が行われるようにする。各成果物の責任と、実施するべき活動を列挙する。 y

管理するべきデータのサイズ、実施するべき活動、および活 y動の実施に利用できるツールに基づいて組織図を作成する。

方針と運用手順のリストを作成する。 y



My N otes

分析ここでは、次の段階である分析について説明しましょう。この段階は段階2とも言います。この段階では、次の活動を行う必要があります。

前に識別した計画立案と資金調達の項目に関する詳細を収 y集するために、サービス査定と需要モデル化のデータを分析する。ITと事業が期待する成果物を生み出すのに必要なプロセスと y情報を分析し、明確にする。新たな査定文書と資金調達文書の作成に役立つように現在 yの経費をレビューする。サービス・コストを適切に計上できるようにするには、IT経費の集約化が重要である。IT経費のレビュー後に、サービス査定を実施する。サービス資 y産の評価額に関するレポートを作成する必要もある。そのためには、事業による価値と価格の認識を正確に計算することが重要である。この計算に到達するには、サービスレベル管理、可用性管理、セキュリティ管理、キャパシティ管理からのインプットが必要となる。財務管理依存のプロセスが利用できない場合は、実施計画 yを調整する。

設計財務管理実施における次の段階は設計で、段階3とも言います。この段階では、財務管理の実施のためのアウトプットを作成します。この段階には、次の活動があります。

主要な貢献者と協力し、データのインプットと変換、報告、方 y法論、およびモデルについての設計を行う。ITプロセスをすべて識別し、各プロセスと財務管理との各関 y係を決定する。査定モデルを作成およびテストし、これらが事業環境に適合 yするようにする。IT経費の以前の会計作業から得られた知見に基づいて、会計 yプロセスを開発する。さらに、コスト傾向、ROIおよび資産利益率（ROA）の分析など、運用モデルと事業環境に関連するレポートを作成する。適切な課金方法論を作成し、財務管理の方針と手順を設計す yる。役割と責任を識別し、職務記述書を作成する。 y



My N otes

実施ここでは、次の段階である段階4の実施について説明しましょう。この段階では、計画したプロセスを実行する必要があります。会社の財務システムと変更管理プロセスが、最初のインプットを提供します。会計プロセスが変換用のデータを受け取り、変更管理と需要管理が、ITに想定される変更に関する情報を提供します。

測定実施の最終段階は測定で、段階5とも言います。この段階には、次の活動があります。

資金調達、査定、および会計の中での財務的傾向に関する成 y功の指標を分析する。受け取る価値と支払う価格との間に不一致があれば、システ yムを監査する。これは次のものを提供することによって行われる。

バランス・スコアカードを使用した簡潔なコミュニケ oーション

頻繁なコミュニケーション o

意味のあるデータ o

事業戦略への常時対応付け o

財務管理プロセスをどのように設計し、実施するかについて学習しました。次に、短い演習に挑戦しましょう。



My N otes




あなたは、ITサービスマネジメント（ITSM）関連の技術の統合と導入を専門とするITSMのコンサルタントで、過去15年間この分野に従事しています。ベンダに対する中立的なアプローチが買われて、最近、オーストラリアにある大規模なインターネット・サービス・プロバイダで、インシデント／イベント管理プロセスと問題管理プロセス、サービスデスクの機能面をアセスメントするように依頼されました。アセスメントが完了したら、アセスメントの結果と推奨事項を、顧客経験と顧客満足度の向上に重点を置いて今後の計画に示してほしいとITマネジメントは考えています。

アセスメント中に、あなたは改善するべき領域を数多く特定します。上位レベルでは、あなたは次の事項を特定しました。

顧客は、目下の課題が繰り返し発生し続けていることに関し1. て何度もコメントしている。

インシデント管理活動が疲弊した後にサービスのコミュニケ2. ーションが機能していないようである。

顧客に接している側で、トラブルシューティングの技法が不足3. しているようである。

初回コールでの解決率がやや低い。4.

サービスデスクで受け取った誤ったエラー・メッセージは、対5. 応している担当者にとってほとんど重要ではないようである。

実施した処置を文書化する能力が、同じ組織内の場所によっ6. て一貫していない。

数多くの種類の技術が識別されていて、それぞれが1つの特7. 定の小さなニーズにしか対応していないようで、データ解釈に関する課題の原因となっている。

各領域のパフォーマンスを全体的に測定する全体的な測定8. 基準がない。



My N otes

アセスメント中に収集した情報から、顧客満足度と全体的な経験をQ1. 向上するために、ITマネジメントに推奨する主要重点領域は何ですか？

使用するツールセットのMoSCoW分析に基づいて、要件記述a) 書の作成を開始できるように、最初に事業要件とプロセスの成熟度レベルの理解を深めることを推奨します。要件を特定した後に、アセスメント中に見つけた重要事項に焦点を当てることができます。最初に、マネジメントからの特定の要求に対応付けるだけでなく、ほかの支援プロセスにも対応するツールセットに注目する必要があります。特に1つを挙げると、毎回同じ方法で各インシデント／イベントを追跡し記録するためのサービスデスクの能力を含むインシデント管理プロセスのサポートがあります。この一貫性により、検索能力を通じた迅速な解決が可能になり、サービスデスクに対する顧客の認識と顧客満足度が改善されます。また、すでに導入している取り組みによってツールとデータを統合することにも注目する必要があります。これによって初期コストを削減できます。最後に、継続的にツールを評価する約束事項を定め、適切なレベルの事業要件の対応付けを確保する必要があります。

使用するツールセットの要件記述書の作成を開始できるようb) に、最初に事業要件とプロセスの成熟度レベルの理解を深めることを推奨します。要件を特定したら、アセスメント中に見つけた重要事項に焦点を当てることができます。具体的にはインシデント管理とイベント管理の領域に関してツールのアセスメントを開始して、新しいツールを導入する価値の実証を直ちに開始することができます。ツールによって徐々にデータが収集されるため、事業要件に対してツールの全体的な品質の測定を開始することができます。この情報が貴重なのは、この情報を使用すると、重要な事業上の決定を行うために特定のプロセスと機能のパフォーマンスを特定できるばかりでなく、継続的サービス改善（CSI）活動を支援する手段を特定できるからです。



My N otes

使用するツールセットの要件記述書の作成を開始できるようc) に、最初に事業要件とプロセスの成熟度レベルの理解を深めることを推奨します。完了したら、ITILからの推奨事項を使って主要な懸案に取り組むことができます。次にその内容を示します。

ツールの要件を特定する。1.

「必須」要件に適合する製品を特定する。2.

選択基準を確立する。3.

製品を評価する。4.

適合する製品を短いリストにまとめる。5.

適合している要件に基づいて製品にスコアを付け6. る。

全体的な能力により製品をランク付けする。7.

最善の製品を選択する。 8. このアプローチを使用すると、事業が必要とする主要重点領域の80%に対応するツールを正しく選択することによって、主要重点領域に対応することができるようになります。

アセスメントでの現在の結果から、要件を100%満たすことはd) 不可能に近いことを理解することが重要です。上位3件の顧客と事業にインパクトを与える領域にできるだけ一致するツールセットの特定に焦点を当てる必要があります。次に、ツールを導入済みのプロセスと統合し、プロセス統合による技術から最大のROIを得られるようにする必要があります。



事業関係マネージャユニット8

Student | ITIL v3 Intermediate Certification Level | Business Relationship Manager


My N otes

ユニット8：事業関係マネージャ

概要事業関係マネージャ（BRM）は、ITサービス・プロバイダ組織に新しく生まれつつある役割です。BRMは、ITと事業の間の連携役で、事業と顧客の間の関係を維持することに責任を負っています。その役割はサービスレベル管理（SLM）と密接に関連しています。そのため、多くの組織では、BRMの役割とサービスレベル・マネージャの役割が兼務されます。


ポジションの最終目標と達成目標を説明できる。 yBRMの役割を理解し、説明できる。 y


目的：事業が顧客に提供する価値が、顧客のニーズおよび期待を（ y超えないまでも）確実に満たす。サービス・カタログを作成して、この達成目標を実現するのを y支援する。

最終目標：サービス・プロバイダが顧客のニーズを満たす。 y事業マネージャとプロジェクト・マネージャの関係を生産的な yものにする。

顧客ポートフォリオを効果的なものにする。 y



8.2　BRMの役割

事業関係マネージャ事業関係マネージャは、顧客との関係維持を責務とする。この役割は、サービスレベル・マネージャの役割と兼務されることが多い。


事業は特定の資産を顧客に提供します。顧客はそれらの資産を所有および構成して、顧客自身の顧客に価値を提供します。

マネージャは、顧客が提供する、または対象とする事業について深く理解することが重要です。

そのためには、マネージャは次のことを行わなければなりません。

各顧客およびターゲット市場について、戦略に関する成果を識別する。 y明確さを維持するために、サービス・ライフサイクルのすべての領域で使用できる参照タグによっ yて成果を分類および体系化する。

顧客成果のタグ付け例

カテゴリタグ成果の説明

能力向上（Enhanced Capabilities：EC）

EC1

EC2

EC3

EC4

EC5

EC6

事業イベントに対応する意思決定および行動がより迅速である。ビジネス・プロセスに関するナレッジ、スキル、および経験が増加する。ビジネス・プロセスが、より優れたロジックによって強化される。

業界のベストプラクティスが、アプリケーションの更新によって利用可能である。サプライ・チェーンが拡大する。専門的なナレッジと技術の可用性がある。

パフォーマンス向上（Increased Performance：IP）

IP1

IP2

IP3

IP4

ビジネス・プロセスのスループットが向上する。平均回収期間（売掛勘定）が短縮される。総資産利益率が向上する。顧客満足度が向上する。

リソース強化（Enhanced

Resources：ER）

ER1

ER2

ER3

ER4

リソースを新しい機会のために使用できるようになる。スタッフの生産性が向上する。運用の柔軟性が向上する。利用可能なリソースが増加する。



カテゴリタグ成果の説明

コスト削減（Reduced Costs：RC）

RC1

RC2

RC3

ビジネス・プロセスの固定費が減少する。従業員手当ての管理作業の単位コストが減少する。新しい、または拡大された運用のための準備期間が短縮される。

リスク軽減（Reduced Risks：RR）

RR1

RR2

RR3

RR4

資産のパフォーマンスのばらつきによる運用のリスクが軽減される。資産のキャパシティ不足による運用のリスクが軽減される。事業継続性が確保される。監査に合格する。ビジネス・プロセスが規制を遵守している。


機会の理解十分にサポートされていない顧客成果は、事業にとって、新しいサービスを解決策として提供する機会となります。カタログ内の既存のサービスが、幾つかの成果に対してサポートを提供する可能性があります。また、設計および開発の段階にあるパイプライン内のサービスも、幾つかの成果をサポートする可能性があります。現在うまくサポートされている成果であっても、事業環境内の変化によってサポートの範囲や品質が低下する場合があるため、定期的にその成果をレビューするべきです。

原材料、構成部品、および部分組立品がそれぞれ使用される最終製品に合わせてタグ付けされるのと同様に、サービスおよびサービス資産には、サポートする成果に合わせてタグ付けをします。サービスおよびサービス資産の価値のアセスメントは、それらが実現する顧客成果を視覚化できる場合に、より容易になります。サービスおよびサービス資産への顧客成果の対応付けは、構成管理システム（CMS）の一環として実行できます。

BRMの責任BRMは次の責任を負います。

顧客との強力で持続的な事業関係を築く。 y顧客成果および顧客の事業を理解する。BRMは「顧客フォーカス」である。 y顧客ポートフォリオを使用して、機会を識別し活用する。 y

BRMの役割

BRMは、組織によってさまざまな名称で呼ばれています。例として、次のようなものがあります。

アカウント・マネージャ y事業の代表者 y販売マネージャ y



事業成果の識別

各成果にコードを

割り当てる

はい

いいえ

成果は十分に

サポートされ

ているか？

成果を定期的に、

または例外の発生時

にレビューする

はいいいえ成果はまだ十分

にサポートされ

ているか？

成果をカタログ内の

サービスと一致させる

うまく一致する

ものはあるか？

いいえ

はい

サービスに成果

をタグ付けする

意思決定のモデル、

方針、手順

マーケティング

（Marketing）設計（Design）運用

（Operat ions）財務

（Finance）エンジニアリング

（Engineering）

成果を

パイプライン内の


いいえ

はい



サービス（概念）に

成果をタグ付けする

サービス合意を

取り決める

契約ポートフォリオ

に追加する

新しいサービス

概念は正当化

されているか？

いいえ

はい

いいえ

はい

顧客は進んで

かかわろうと

するか？


概念を考案する

事業成果の識別

各成果にコードを

割り当てる

はい

いいえ

成果は十分に

サポートされ

ているか？

成果を定期的に、

または例外の発生時

にレビューする

はいいいえ成果はまだ十分

にサポートされ

ているか？

成果をカタログ内の




いいえ

はい

サービスに成果

をタグ付けする

意思決定のモデル、

方針、手順

マーケティング

（Marketing）設計（Design）運用

（Operat ions）財務

（Finance）エンジニアリング

（Engineering）

成果を

パイプライン内の


いいえ

はい



サービス（概念）に

成果をタグ付けする

サービス合意を

取り決める

契約ポートフォリオ

に追加する


概念は正当化

されているか？

いいえ

はい

いいえ

はい

顧客は進んで

かかわろうと

するか？


概念を考案する



成果ベースのサービス内部ITサービス・プロバイダは、内部市場を開発し、市場のニーズにすぐに対応するためにBRMを必要とします。BRMは、ライフサイクルを通してサービスを開発および管理する製品マネージャと密接に連携します。製品マネージャは「製品フォーカス」で、サービス・ポートフォリオを通じて環境を認識します。

サービスを成果に基づいて定義することで、マネージャは、顧客にとって何が重要かという観点からサービスマネジメントを実施するようになります。これによって、サービスが顧客にとっての価値を生み出すだけでなく、サービス・プロバイダにとっての価値も生み出すようになります。

コアサービス・パッケージ100

保証SLP Y

有用性SLP X

差別化された提供内容100 XY

コアサービス・パッケージ100

保証SLP Y

有用性SLP X

差別化された提供内容100 XY



サービスレベル・パッケージ（SLP）を通じて、サービスレベルを顧客の特定の要件と一致させることができます。SLPを使用すれば、ユーザのセグメントに、そのセグメントのニーズに対応するのに適した有用性と保証を併せて費用対効果の優れた方法でサービスを提供できます。コアサービス・パッケージ（CSP）とSLPを組み合わせると、セグメント化されたサービス・カタログになります。これによって、サービス合意やサービス契約の経済効率が高まり、顧客への対応が不十分であったり過剰であったりすることもなくなります。

現地サポート

「24時間365日」世界規模のモバイル性

ハードウェアのセキュリティ・トークン

ノートPC 3Gワイヤレス電話卓上電話オフィスのファックス

データ暗号化サービス

標準電子メール

ワイヤレスの音声とデータ

ダイヤルトーン


コンポーネント・サービス顧客資産サービス資産

現地サポート

「24時間365日」世界規模のモバイル性

ハードウェアのセキュリティ・トークン

ノートPC 3Gワイヤレス電話卓上電話オフィスのファックス

データ暗号化サービス

標準電子メール

ワイヤレスの音声とデータ

ダイヤルトーン


コンポーネント・サービス顧客資産サービス資産



サービス・コンポーネントとコンポーネント・サービスで構成される保証SLP

保証SLP ワークスペースSLP1 ワークスペースSLP2 ワークスペースSLP3

可用性SLP

高可用性の24時間365日プラン世界的なモバイル性ノートPCワイヤレスPDAサービス卓上電話3Gワイヤレス

非常に高い可用性の24時間365日プラン世界的なモバイル性ノートPCワイヤレスPDAサービス卓上電話3Gワイヤレス

標準的な可用性の平日9時5時プラン指定された拠点デスクトップPC卓上電話標準ワイヤレス

キャパシティSLP

大容量メールボックス高優先度ブロードバンド

超大容量メールボックス高優先度ブロードバンド

基本メールボックス基本ブロードバンド大量印刷サービス

継続性SLP

公衆交換電話網のバックアップレベル2のバックアップとリストア海外出張サポート

公衆交換電話網のバックアップレベル3のバックアップとリストア海外出張サポート

公衆交換電話網のバックアップレベル1のバックアップとリストア現地サポート

セキュリティSLP

多元的認証ハードウェア・トークン仮想プライベート・ネットワークセキュアなFTP

多元的認証仮想プライベート・ネットワーク




My N otes

セグメント化CSPとSLPは、再使用可能なコンポーネントで構成されています。それらのコンポーネントには、サービス、ソフトウェア、ハードウェア、ライセンス、サードパーティのサービス、公共インフラストラクチャ・サービスなどがあります。顧客が所有するサービス・コンポーネントもあります。

コンポーネント・サービスをサービス・カタログ上で顧客の目に見えるようにするかどうかは、価格設定とサービスのセットに関する方針決定です。サービス・カタログを拡張する前に、それに伴うリスクを慎重に考慮します。

サービス・カタログは、それぞれが製品マネージャのコントロール下にあるLOSのセットでもあります。

サービス・ライン各サービス・ライン（LOS）は、ある顧客セグメントで好まれる有用性と保証の特定の組み合わせを提供します。これらの顧客セグメントは事業成果の面から定義されます。このタイプのセグメント化は、人口統計、場所、事業の規模、購買行動、予測されたニーズなどの基準に基づいた従来の市場セグメントほど狭いものではありません。基準は事業成果とさほど密接に関連するものではありませんが、顧客の事業成果は常に顧客による価値の認識と関連します。成果ベースのセグメント化により、サービス・プロバイダがより専門化され、顧客ニーズをうまく満たせるようになります。

各LOSはサービス提供内容で構成され、各サービス提供内容はCSPとSLPで構成されます。このモジュール式アプローチは、サービス・ライフサイクルの中に複数のコントロールの観点を取り入れます。サービス・プロバイダ組織内のさまざまな専門ループが、それぞれ異なるCSPとSLPを管理します。例えば、専門化された能力とリソースを持つグループ、またはサードパーティが、有用性SLPと保証SLPを処理できます。

BRMは、担当する顧客成果それぞれに対してLOSとSLPの最適な組み合わせを特定しなければなりません。また、顧客成果を、関連するユーザ・プロファイルに関連付ける必要があります。次に、顧客成果のそれぞれにカスタマイズされたサービス提供内容を作成するために、ユーザ・プロファイルを該当するSLPにマッチングさせます。CSPとSLPは、基本サービス・パッケージ、性能サービス・パッケージ、または興奮サービス・パッケージを通じて、顧客の好みや認識の違いに対応できます。

コンポーネントベースのアプローチは、顧客満足度を維持しながらコストを大幅に削減します。BRMは顧客の代表としてプロジェクト・マネージャと密接に連携することによって、サービス・カタログ内のLOSとSLPの適切な組み合わせを通じて、顧客ポートフォリオのニーズが満たされるようにします。



My N otes




あなたは中規模の製造会社のサービス・マネージャです。この会社では最近、効率性と有効性を向上するためにITILを導入することに合意しました。会社では、これらの利点を製造の観点だけでなくITの観点においても達成したいと考えています。ITの観点については最近まで重視したことはありませんでした。

あなたは、継続的サービス改善の価値は言うまでもなく、ITILの各段階の重要性と、それが事業、顧客、IT、およびパートナにもたらす価値について理解しています。事業もこれらの価値を理解しており、サービスデザイン段階の導入を会社がどのように実施するかに特に興味を持っています。この段階はその後のすべての段階と活動の成功に重大なインパクトを与えるため、会社は、事業がどのように導入を行うべきかを明確化するようにあなたに依頼しました。

サービス・マネージャとして、上位レベルの観点から、どのように会Q1. 社がサービスデザイン段階を導入するように推奨しますか？

最初に、すでに達成されていることを活用するために、すでにa) 導入されている現在のプロセスと手順を特定する必要があります。これにより、サービスデザイン段階、およびこの特定の段階をどのように導入するかについてのプロセス定義から開始することができます。その後、多くの領域に焦点を当てて、次のことを特定します。

サービス・プロバイダとしての会社のカルチャと環 o境。これらは、全体的な事業のビジョンと達成目標に基づいた変更の改善に適していて、受け入れ可能である必要がある。

会社の将来的に望ましい状態。ITサービス供給の整 o合、品質、サービスレベル、および顧客満足度の改善。

組織のプロセスと成熟度の側面に関する会社内の o現在の状況。ほかのプラクティスと標準、およびリスク・アセスメントを考慮すること。

現在の状態から前進するために、識別した一連の改 o善事項を利用して望ましい状態に達する手段。

将来の望ましい状態を実現するために、設計された o一連の測定基準を活用する必要がある。

ビジョンと達成目標をレビューし、さらに改善処置を o特定して、活動を繰り返す。



My N otes

最初に、すでに達成されていることを活用するために、すでにb) 導入されている現在のプロセスと手順を特定する必要があります。これにより、サービスデザイン段階、およびこの特定の段階をどのように導入するかについてのプロセス定義から開始することができます。その後、多くの領域に焦点を当てて、次のことを特定します。

サービス・プロバイダとしての会社のカルチャと環 o境。これは、全体的な事業のビジョンと達成目標に基づいた変更の改善に適していて、受け入れ可能である必要があるためである。

組織のプロセスと成熟度の側面に関する会社内の o現在の状況。ほかのプラクティスと標準、およびリスク・アセスメントを考慮すること。


現在の状態から前進するために、識別した一連の改 o善事項を利用して望ましい状態になるようにする手段。



最初に行うべきことは、適切なガバナンスを伴う、サービスデc) ザインの導入と改善の正式なプロセスと手法を確立することです。この正式なプロセスは、次に示す6段階の実証されたプロセスに基づいて使用する必要があります。

サービス・プロバイダとしての会社のカルチャと環 o境。これは、全体的な事業のビジョンと達成目標に基づいた変更の改善に適していて、受け入れ可能である必要があるためである。

組織のプロセスおよび成熟度の側面に関する社内 oの現在の状況。ほかのプラクティスと標準、およびリスク・アセスメントを考慮すること。


現在の状態から前進するために、識別した一連の改 o善事項を利用して望ましい状態になるようにする手段。




My N otes


サービスデザインと会社のほかの機能面を支援する主要なd) 事業達成目標と要件を特定します。次に、サービスデザイン段階を適切に導入するのに必要な5つの品質レベルを採用する必要があります。5つの品質レベルには、次が含まれています。

定義（Define） ― 顧客の要求および組織戦略と一貫 o性のある設計活動の最終目標を正式に定義する。

測定（Measure） ― 重要成功要因（CSF）、能力、プロ oセス能力、リスク・アセスメントを特定する。

分析（Analyse） ― 代替手段を開発および設計し、上 o位レベルの設計を行い、最適な設計を選択するための設計能力を評価する。

設計（Design） ― 詳細な設計を行い、設計を最適化 oし、設計の検証を計画する。

検証（Verify） ― パイロット実施を設定し、作成プロ oセスを導入し、プロセス・オーナに引き渡す。


役割と責任


ユニット9

Student | ITIL v3 Intermediate Certification Level | Roles and Responsibilities


My N otes

ユニット9：役割と責任

概要サービス提供と合意（SOA）プロセスでは、幾つかの異なる役割が連携する必要があります。組織の規模および複雑さに応じて、1人の個人または複数名のグループがこれらの役割を実行できます。規模の小さい組織では、これらの機能を兼任の役割が果たすこともあります。

ユニットの学習目標：このユニットを修了すると、次の成果が得られます。

サービス・カタログ・マネージャの役割と責任を説明できる。 yサービスレベル・マネージャの役割と責任を説明できる。 yサプライヤ・マネージャの役割と責任を説明できる。 y

9.1　サービスの役割と責任の目的と最終目標

目的：各役割の責任、プロセス、依存関係、およびインタフェースを y明確に特定および定義する。役割と責任の適用範囲を定義する。 y活動またはプロセスを特定する。 yミーティングを実施して、RACI（実行責任者、説明責任者、協 y議先、報告先）のコードを割り当てる。役割、責任、プロセスなどの間のギャップや重複を識別する。 y

最終目標：適切な役割に適切な機能を割り当てる。 yできるだけ迅速に適切な意思決定を行う。 y決定された事柄を効果的かつ効率的に実行する。 yRACIチャートを割り当てて、フィードバックを含める。 y割り当てが守られていることを確認する。 y



My N otes

9.2　サービス・カタログ・マネージャの役割と責任

さまざまな役割の個人が互いに連携して、サービス提供内容が顧客のニーズを満たし、サービス・アグリーメントが事業の要件を満たすことを確実にしなければなりません。さまざまな役割の肩書きは組織によって異なってもかまいませんが、それぞれの責任、プロセス、インタフェース、および依存関係の定義と適用範囲を明確に定義しておくことが重要です。

サービス・カタログ・マネージャは、サービス・カタログを作成および維持して、すべての情報が正確で最新であるようにします。これには、次を確実にすることが含まれます。

サービス・カタログに、現在運用中のすべてのサービスおよ yび運用準備中のすべてのサービスが含まれている。サービス・カタログが正確で最新である。 yサービス・カタログがサービス・ポートフォリオと一致してい yる。サービス・カタログがきちんと保護され、信頼できるバックア yップがある。



My N otes

9.3　サービスレベル・マネージャの役割と責任

サービスレベル・マネージャは、サービスレベル管理（SLM）導入の成功を確実にします。

これには次の責任が含まれます。

ビジネス・ニーズの変化を常に認識する。 y顧客の現在および将来のサービス要件を特定し、サービスレ yベル・アグリーメント（SLA）やサービスレベル要件（SLR）に文書化する。内部および外部の顧客に対するサービスレベルを交渉およ yび合意し、合意内容をSLAに文書化する。OLA、他のSLA、およびSLAを下支えする合意について顧客と y交渉し合意する。サービス・ポートフォリオ、サービス・カタログ、アプリケーショ yン・ポートフォリオ、および対応する保守手順の作成および維持を支援する。外部委託契約（UC）内の目標値をSLAおよびSLRの目標値と y整合させる。各顧客サービスに対してサービス・レポートを作成し、SLA目 y標値に対する違反が記載および調査され、再発防止の処置が取られることを確実にする。定期的なサービス・パフォーマンス・レビューをスケジューリ yングして実施し、合意された処置の進捗を文書化する。サービス・レビューで特定された処置を確実に実施し、顧客 yにその進捗レポートを提供する。サービス適用範囲、SLA、OLA、およびその他の合意を定期的 yにレビューする。変更がSLA、OLA、およびUCのサービスレベルに及ぼすイン yパクトのアセスメントを確実に行い、必要な場合は変更諮問委員会（CAB）ミーティングに出席する。重要な利害関係者と顧客を特定する。 y利害関係者、顧客、およびユーザとの関係とコミュニケーショ yンを発展させる。苦情を定義し、それらを記録、管理、エスカレーション、および y解決する方法について合意する。すべての苦情を定義および記録し、伝達する。 y顧客満足度の測定、記録、分析、および改善を行う。 y



My N otes

9.4　サプライヤ・マネージャの役割と責任

サプライヤ・マネージャは、サプライヤ管理導入の成功を確実にします。

これには次のタスクが含まれます。

サードパーティ・サプライヤ向けのSLA、契約、合意、または他 yのあらゆる文書の策定およびレビューを支援する。すべてのITサプライヤと契約から投資に見合う価値が得られ yるようにする。ITサプライヤのすべてのプロセスに一貫性があり、企業にお yけるサプライヤ戦略、プロセス、標準的な諸条件と調和することを確実にする。サプライヤ契約データベース（SCD）を維持およびレビューす yる。すべてのサプライヤと契約に関するレビューとリスク分析を y定期的に実施する。UC、合意、またはSLAをビジネス・ニーズと確実に整合させ yる。すべての支援的なサービスと合意の範囲を設定し、文書化す yること、また、サプライヤ、支援サービス、サプライヤ・プロセス間の関連するインタフェースについて文書化することを確実にする。統括サプライヤと再委託先サプライヤ間のすべての役割と関 y係を文書化し、維持し、それらの契約上のコンプライアンスを確実にする。再委託先サプライヤが契約上の要件を満たしていることを確 y認するために、統括サプライヤのプロセスをレビューする。少なくとも毎年、SLAや契約のレビューを実施し、それらが組 y織の要件および標準的な諸条件と一致しているようにする。変更管理プロセスに従ってSLAまたは契約を更新する。 y契約上の争議を効率的かつ効果的な方法で解決するための yプロセスを維持する。サービスの予定どおりの終了、早期終了、または移転に対処 yするためのプロセスを維持する。サプライヤのパフォーマンスを目標値に照らして定期的にモ yニタ、記録、およびレビューし、改善処置が取られることを確実にする。変更がサプライヤ、支援サービス、および契約に及ぼすイン yパクトを確実に評価し、適宜CABミーティングに参加する。



My N otes

すべての個別のITサプライヤと契約マネージャを調整および y支援し、各サプライヤ／契約にはサービス・プロバイダの組織内に指名されたオーナが存在することを確実にする。



My N otes




あなたの会社では最近、新しいオンライン・ショッピング・カート・サービスを導入しました。このサービスはサービスストラテジとサービスデザインの段階を経て、すべての要件が文書化され、事業によって合意されました。しかし、サービスを稼働環境に移したとたん、事業はサービスが顧客のニーズを満たしていないと苦情を言い始めました。サービスレベル・マネージャとして、あなたはサービスレベル管理（SLM）に含まれる活動、プロセス、および役割を調整する責任を負っています。サービスデザイン段階で、あなたはそのサービスのサービスレベル要件（SLR）を把握する作業に積極的に参加しました。直近のサービス・レビューの際に、顧客はサービスレベル・アグリーメント（SLA）にかなりの変更を要求してきました。新しい要件が識別されたため、サービスを拡張する必要があります。あなたは、事業がなぜサービスに満足していないのかよく理解できません。あなたは、既存のサービスの評価を手伝ってくれる要員を組織内で見つける必要があります。

サービスをレビューするために、次のうちどの行動を取りますか？Q1.

プロセスとサービスの改善内容の識別に、CSIマネージャをa) 関与させることにします。サプライヤ・マネージャと協力して、すべての支援サービスの適用範囲を設定し文書化すること、サプライヤ、支援サービス、サプライヤ・プロセス間のインタフェースと依存関係について合意し文書化することを確実にしたいと考えています。また、サービス・カタログ・マネージャを関与させて、サービス・カタログ内の情報が正確で最新の状態であることを確実にしたいとも考えています。事業関係マネージャにも関与を依頼します。事業関係マネージャは、強力で持続する事業関係を築くことに責任を負い、顧客の成果と顧客の事業を最も深く理解しているためです。

サプライヤ・マネージャと協力して、すべての支援サービスのb) 適用範囲を設定し文書化すること、サプライヤ、支援サービス、サプライヤ・プロセス間のインタフェースと依存関係について合意し文書化することを確実にしたいと考えています。また、サービス・カタログ・マネージャを関与させて、サービス・カタログ内の情報が正確で最新の状態であることを確実にし



My N otes

たいとも考えています。事業関係マネージャにも関与を依頼します。事業関係マネージャは、強力で持続する事業関係を築くことに責任を負い、顧客の成果と顧客の事業を最も深く理解しているためです。プロセスとサービスの改善内容の識別に、CSIマネージャをc) 関与させることにします。サプライヤ・マネージャと協力して、顧客の現在および将来のサービス要件が特定および理解され、SLAやSLR文書に記載されることを確実にしたいと考えています。また、サービス・カタログ・マネージャを関与させて、サービス・カタログとサービス・ポートフォリオ内の情報が正確で最新の状態であることを確実にしたいとも考えています。事業関係マネージャにも関与を依頼します。事業関係マネージャは、強力で持続する事業関係を築くことに責任を負い、顧客の成果と顧客の事業を最も深く理解しているためです。

サプライヤ・マネージャと協力して、顧客の現在および将来のd) サービス要件が特定および理解され、SLAやSLR文書に記載されることを確実にしたいと考えています。また、サービス・カタログ・マネージャを関与させて、サービス・カタログとサービス・ポートフォリオ内の情報が正確で最新の状態であることを確実にしたいとも考えています。事業関係マネージャにも関与を依頼します。事業関係マネージャは、強力で持続する事業関係を築くことに責任を負い、顧客の成果と顧客の事業を最も深く理解しているためです。



技術と導入に関する検討事項ユニット10

Student | ITIL v3 Intermediate Certification Level | Technology and Implementation Considerations


My N otes

ユニット10：技術と導入に関する検討事項

概要それほど複雑でないプロセスを導入する場合でも、サービスマネジメント・ツールを使用すると便利です。ツールがプロセスを完全にはサポートしていない場合は、技術に合わせてプロセスを再設計しなければならない場合があります。ツールがプロセスをサポートする必要があり、その逆であってはなりません。また、プロセスを推進するツールに完全に依存するべきではありません。最終的に最も重要なのはプロセスと人材だからです。


技術と導入プロセスの最終目標と達成目標を説明できる。 yサービスデザインを支援する技術の一般的な要件を理解で yきる。プロセス導入における技術とツールの評価基準を説明でき yる。プラクティスとプロセス導入のためのグッドプラクティスの使 y用について理解できる。プラクティスとプロセスの導入に関係する課題、重要成功要因 y

（CSF）、およびリスクを明確に理解できる。サービスマネジメント技術を計画し導入する方法を示すこと yができる。



My N otes


目的：特定の設計プロセスをサポートする適切なツールがない場 y合があることを認識する。必要に応じてプロセスの再設計を開始する。 yあらゆる技術導入におけるプロセス、機能、および人材につ yいて検討する。

最終目標：生産性とサービス品質を高めてコストを削減することによっ yて、プロセスの効率性を向上する。主なサービスマネジメント・プロセスの集中化と自動化によ yって、実行可能な管理情報を提供する。実施活動を通じてさまざまな合意と契約に記述されていると yおりに、事業と顧客のニーズと要件を満たす。サービスとプロセスに対するリスクに対処する適切な対策を y確保する。



My N otes

10.2　SOAで支援する一般的な技術要件

設計ツールサービスとそのコンポーネントを設計するために、独自仕様のツールや技法と、そうでないツールや技法を複数使用することができます。ツールと技法は、次をサポートします。

ハードウェア設計 yソフトウェア設計 y環境設計 yプロセス設計 yデータ設計 y


ツールの使用ツールと技法を使用すると、次のことが可能になります。

設計プロセスを高速化する。 y標準や規約とのコンプライアンスを保証する。 yプロトタイピング、モデル化、およびシミュレーションのため yの機能を提供する。仮定（what if）のシナリオを構築する。 yインタフェースと依存関係の確認と関連付けを可能にする。 y予想された要件を満たしていることを保証するために、導入 y前に設計の妥当性を確認する。

開発ツールサービスとそのコンポーネントをあらゆる観点から視覚的に表すツールを使用すると、サービス設計の作成が容易になります。観点には、ビジネス・プロセス、サービス、サービスレベル・アグリーメント（SLA）、インフラストラクチャ、プロセス、環境、データ、アプリケーション、オペレーショナルレベル・アグリーメント（OLA）、契約、サプライヤ、チームなどがあります。この目的のために、幾つかの構成管理ツールを使用することができます。これらのツールは、ビジネス・サービスマネジメント・ツールの一部と考えられることもあります。「自動検出型」のツールとツール内の仕組みをリンクしたり、組み込んだりして、これらの要素間の相互関係を視覚的に表すことができます。これにより、各コンポーネントの細分化を実現することができます。



My N otes

ライフサイクル全体を通してサービスをモニタし管理するには、ツール内に財務情報を組み込み、サービスのさまざまな側面に対する重要業績評価指標（KPI）と測定基準を含む「測定基準ツリー」にリンクさせます。この一元的な単一のサービス情報源により、サービス・プロバイダ組織と事業の誰もが、サービスとそのパフォーマンスの正確で現実に即した全体像をいつでも参照できます。また、これによりサービス・プロバイダとその顧客の間に良好な関係の基盤を築くことができます。

開発ツールの使用ツールは、次に示すようなサービス・ライフサイクルのあらゆる段階においても役に立ちます。

サービス・ライフサイクルのすべての段階の管理 yパフォーマンスを含む、サービスのあらゆる側面の管理 yサービスの目標値の達成、SLA、OLA、契約とサプライヤのモ yニタリング、報告、管理管理ダッシュボードから、コンポーネント、そのパフォーマン yス、障害の特定と分析に関する詳細情報まで、さまざまなレベルを示す、包括的な測定基準と測定基準ツリープロセス、システム、技術、グループ全体にわたって統合され yた一貫性のある表示ITサービス、システム、およびプロセスと事業の関係と統合 y意思決定を向上するために一貫性のある情報を提供し分析 yを支援する、包括的な一連の検索と報告の仕組みサービスのコストと経費の管理 y関係、インタフェース、相互依存性の管理 yサービス・ポートフォリオとサービス・カタログの管理 y構成管理システム（CMS） yサービス・ナレッジ管理システム（SKMS） y

活動要件このアプローチを実施するためには、次の一般的な活動が必要です。

IT資産の一般的なライフサイクル（要件定義、設計と開発、構 y築、テスト、展開、運用と最適化、廃棄）を確立し、各資産タイプのライフサイクルの各段階での主要なプロセス、方針、活動、および技術を定義する異なるタイプのIT資産間の関係と、IT資産の取得と管理およ yび他のIT領域の関係を正式なものとするIT資産の活動に関連するすべての役割と責任を定義する yITサービスの（総）所有コストを把握するための手段を確立す yる



My N otes

サービス全般にわたるIT資産の再利用の方針を、例えば企業 yレベルなどで確立する他のIT戦略および事業戦略とどのように整合させるべきかを y含め、IT資産の取得と管理の戦略を定義する


アプリケーション資産の活動アプリケーション資産には、次の追加の活動が必要です。

IT資産を取得し管理するための戦略の概要を作成する。ほか yのIT戦略や事業戦略との関係を含む。事業へのITサービスの提供におけるアプリケーションの役割 yを文書化する。一般的なIT資産のライフサイクル・モデルをさまざまなタイプ yのアプリケーションに合わせて調整する。アプリケーションを開発するためのさまざまなアプローチの y使用標準を設定し、「再利用」を中心とするものを含む、開発方法論の役割を重視する。サービス・パフォーマンス、セキュリティ、運用性、保守性など、 yすべての要件タイプを検討する適切な手順を確保する。アプリケーション・サービス・プロバイダ、既製品（COTS）パッ yケージ、およびパッケージと開発のカスタマイズの利用など、事業にアプリケーションを提供する最適な方法について決定するための標準を設定する。

データまたは情報資産の活動データ／情報資産には、IT資産の取得と管理の基本原則が組織のデータ／情報リソースの管理にどのように役立つかを判断する追加的な活動が必要です。



My N otes

データ設計の説明責任データ設計では、次のことを説明します。

標準化された、再利用可能なメタデータの重要性 yデータ品質の標準 yデータの組織的な利点 y適切なデータ管理作業の重要性 y企業の対象領域と特定のサービスから見たデータの理解 yテキスト、スキャン画像、動画、音声などの従来のものとは異 yなるタイプのデータを扱う手順データに関係するストレージ、セキュリティ、法的な課題の認 y識一般的なIT資産のライフサイクル・モデルの、データ資産タイ yプへの適応

ITインフラストラクチャと環境資産の活動ITインフラストラクチャと環境資産には、次の追加の活動が必要です。

ハードウェア、ミドルウェア、ソフトウェア、ネットワークなど、IT yインフラストラクチャと環境機器の獲得と管理のための標準を設定し、その標準がITサービスの供給を支える、安定していながら、柔軟性のある基盤を確実に提供する。一般的なIT資産のライフサイクル・モデルをITインフラストラ yクチャのライフサイクルに適応させる方法を特定する。再利用によりITインフラストラクチャの最適利用を保証する y活動を作成する。ツールの要件を決定し、それらを使用することでITインフラス yトラクチャと関連サービスの管理にどのように役立つかを把握する。

活動と力量のスキルスキル（人材と力量の両方）には、次の追加の活動が必要です。

IT資産と関連サービスを管理する個人の力量を、組織が資産 yと見なして確実に管理する。一般的なIT資産のライフサイクル・モデルを、特にスキル、ナ yレッジ、資格、経験、思考形態、および行為の測定の点から人材資産にどのように適用するかを特定する。現在の力量を文書化し、それらを再利用または改善する方法 yを理解する。組織の標準がSFIA（Skills For the Information Age：情報時代 yのスキル）などの標準的なIT部門の力量のフレームワークに適合しているようにする。



My N otes

効率的なインタフェースと依存関係のための活動効率的なインタフェースと依存関係のために、次のことを実行します。

IT資産の取得および管理と、ITによる事業変更、ITプロジェク yト管理、ITセキュリティとの間のインタフェースの概要を定義する。IT資産の取得および管理と、IT以外の機能およびプロセスと yの間の公式なインタフェースを決定する。組織全体でのIT資産分散について適切な測定基準とレポー yトを特定し、IT資産の取得と管理において品質チェックと測定項目を設定することによって、正式な測定と報告を決定する。



My N otes

10.3　プロセス導入のための技術とツールの評価基準

サービスマネジメントのツールプロセスの効率と効果を向上するには、サービスマネジメント・ツールの導入が重要です。また、これらのツールには、多くの短期的および長期的な利点があります。

サービスマネジメント・ツールを導入すると、次を行うことができます。

サービスデザイン・プロセス内の重点領域を特定する。 y中核的プロセスを集中化、自動化、統合する。 y傾向を明確化し、予防対策を実施する。 yコストを削減し生産性を向上して、ITサービスの品質を高め yる。

サービスデザイン・ツールの使用あらゆるプロセスにおいてサービスデザイン・ツールを使用すると、次のことが可能になります。

効率を向上し、データを提供してプロセスのモニタリングを y簡単にする。豊富な管理情報を提供し、弱みとなる領域を特定する。これに yより、組織は弱い領域を強化してプロセス全体を改善するのに重点を置くことができる。重要なプロセスの集中化とサービスマネジメントの中核的プ yロセスの自動化と統合が実現する。収集したデータにより「傾向」が明確化できる。「傾向」が明確 yになると、組織が予防対策を実施して、ITサービスの品質を改善するのに役立つ。予防対策はサービス品質を改善するために組織が実施できる唯一の対策ではない。例えば、新しいKPIを追加して傾向分析を行うと、ITサービスの品質を改善することができる。



My N otes

ツールの評価要件の基準シナリオで述べた要件から明らかなように、ツールの要件は必須または任意としてカテゴリ化することができます。これを行うには、SORを使用して適切なツールを選択する必要があります。この記述に従って、MoSCoW分析を使用して、次のようにツールの要件をカテゴリ化するべきです。

MはMUSTを意味します。つまり、その要件は必須です。 ySはSHOULDを意味します。つまり、可能であれば、この要件を y満たす必要があります。CはCOULDを意味します。つまり、ほかに影響を与えない場合 yは、ツールはこの要件を満たす必要があります。WはWON'Tを意味します。つまり、ツールは将来的にこの要 y件を満たすかもしれませんが、直ちに満たす必要はありません。

ツールがカテゴリ化した要件を100%満たすことは、めったにありません。運用要件を約80%満たすツールは、目的に適していると考えるべきです。しかし、すべての必須要件を満たしていないツールは却下する必要があります。

状況によっては、すべての必須要件または事業の運用要件の80%のいずれかを満たすツールを評価するのが困難な場合があります。この場合、機能設計が最適なツールを選択し、ツールの不適切な要素の改善を試みてください。可能な場合は、ベンダが拡張コストを負担したり、購入者がコストの一部を負担したりする必要があります。

ツールの導入ツールを評価して選択した後に、リソースを利用可能なときに導入をスケジューリングして、成功を確実にする必要があります。また、関連ハードウェアまたはソフトウェアの設定を準備するのに必要な時間を計画する必要があります。アプリケーション・サービス・プロバイダを介してツールの機能性を提供することを選択すると、少なくともハードウェアを準備しなくてよくなり、ソフトウェア設定の多くも任せることができます。

どのツールを選択する場合でも、次のように要件の充足を差別化する必要があります。

即座に利用可能 ― 要件が満たされている場合 y構成 ― 要件を満たすために、このツールを構成できる必要 yがある。この作業は製品のアップグレード・バージョンでは必要ない。



カスタマイズ ― 要件を満たすために、ツールを再プログラムしなければならない。この作業は、製 y品のアップグレードのたびに繰り返さなければならない可能性がある。少なくとも、新しいバージョンではカスタマイズをチェックする必要がある。

ツールの短所さまざまな不利益が生じるため、広範囲に及ぶカスタマイズを必要とする製品を選択しないでください。次に例を示します。

カスタマイズと関連トレーニングのために追加費用が生じる。 yトレーニングのカスタマイズに追加費用が必要。製品のサプライヤが提供するトレーニング・コー yスは、製品をカスタマイズした後は利用できなくなる。製品をアップグレードするためのリソースを利用できない（ベンダが以前のリリースをサポートし yていない場合）。ベンダがサポート義務から開放される。このため、エラーまたは障害が発生したときにサービスマ yネジメント・システムを利用できない可能性がある。



My N otes

サービスデザイン・ツールの評価サービスデザイン・ツールを導入する前に、その有効性を評価する必要があります。

検討するべき要件は次のとおりです。

データ構造 y国際的なオープン・スタンダードへの準拠 y柔軟性 yユーザビリティ yスケーラビリティ yデータのバックアップ機能 yツール・ベンダによるサポート y技術主導ではなく事業主導の機能：機能が事業指向であるこ yとを確認するために機能を評価する。次に示すような特定の機能に注意すること。

堅牢なデータ構造 o

マルチベンダのインフラストラクチャ・コンポーネン oトの統合

ツールのデータ処理とモデル化の能力 o

ユーザビリティ o

過去の追跡データの変換要件 o

データのバックアップ、コントロール、セキュリティ o

スケーラビリティ o

良質な報告書の生成 o

管理コストと保守コスト o

セキュリティと完全性 o

サービスレベルのモニタリングのサポート o

ツールとサプライヤによるサービスマネジメントの oベストプラクティスの順守

許容可能なレベルの保守とリリースの方針 o

他のサービスマネジメント・ツールおよび運用管理 oツールとの統合



My N otes

導入、利用、およびデータ共有における柔軟性：ツールを運用 yする予定のプラットフォームを検討する。集約された共有データベースを持つ分散クライアントなど、 y基盤となるアーキテクチャ：ツールの導入条件が、組織のIT戦略によって課される制限と矛盾しないことを確認する。国際的なオープン・スタンダードへの準拠：製品が準拠しなけ yればならない現場の方針と標準を特定する。承認された予算：調達が、ツールに対して承認された予算内 yに収まることを確認する。トレーニング要件：関連するサポート・コストとトレーニング・ yコストを決定するために、組織のトレーニング・ニーズをアセスメントする。トレーニング・コストに加えて、必要なトレーニングの場所と期間も検討するべきである。ツール・ベンダが提供するサポート・オプション：ベンダまた yはサプライヤの信頼性と実績を検討する。サプライヤが適切なトレーニングを提供する能力を評価する。サプライヤのサービスデスクのサポート・サービスと技術的な力量をアセスメントする。検討中のツールの比較と分析：さまざまなサービスマネジメ yント・ツールが利用可能である。選択プロセスにおいて検討しているツールをすべて評価するために、インターネットやサービスマネジメントの出版物を調べたり、専門家に意見を求めたり、セミナーや会議に出席したりするべきである。



My N otes

10.4　プラクティスとプロセス導入に関するグッドプラクティス

SLMの要件サービスレベル管理（SLM）プロセスでは、サービスレベル要件（SLR）を決定して、可能な場合は正式なSLAとして文書化する必要があります。サービスデザインの観点からは、SLRの視点から新しいサービスを開発することが重要です。

サービスデザインまたはITサービスマネジメント（ITSM）のプロセスのために、通常の事業活動に混乱が生じてはなりません。ソリューションを選択して作成するときは、この基準に注意して検討してください。サービストランジション活動中にリスクを詳細にアセスメントします。

ITサービスを設計するために、文書化されたプロセス、方針、およびアーキテクチャを使用して、事業の現在と将来のニーズを満たす革新的なITサービスを開発し導入するべきです。

プロセスの導入サービスマネジメント・プロセスを組み合わせる利点は、個々のプロセスの利点よりはるかに大きいため、すべてのプロセスを一緒に導入するべきです。すべてのサービスマネジメント・プロセスは相互に密接な関係があり、また、相互に依存している場合もあります。従って、最適なのは、ライフサイクル全体にわたって一連のITサービスを管理する統合された一連のプロセスです。

しかし、組織においてすべてを同時に実施することはできません。組織はニーズを優先度付けする必要があります。これには、ITサービスの供給における強みと弱みを詳細に評価する必要があります。このタイプの評価では、顧客満足度調査を使用し、プロセスを分析して、顧客やITスタッフと話すことができます。このアセスメントを使用すると、短期戦略、中期戦略、および長期戦略を策定することができます。

短期的には「即効性のある成果」を導入できますが、中期戦略または長期戦略を達成するために修正したり切り捨てたりしなければならない場合があります。即効性のある成果は、長期的な最終目標を犠牲にして導入してはいけません。しかし、各組織は現在のITSM成熟度に基づいて開始する必要があります。

サービス改善計画（SIP）には導入の優先度を示すべきです。例えば、組織が直面している重大な問題がサービス可用性の場合には、可用性管理、インシデント管理、問題管理、変更管理などの可用性を改善するプロセスに多くの注意を払うべきです。意思決定には、サービスを受ける側と提供する側など、重要な関係者をすべて含めるべきです。ツールではなくニーズを優先するには、ワークショップまたはフォーカス・グループを利用して要件と導入プロセスを理解する必要があります。



最初にすることは、正式なプロセスと手順を規定し、サービスデザインを導入および改善することです。このプロセスには、コントロールとガバナンスのために適切な指標が必要です。

6. どのようにして

維持するのか？

1. ビジョンは何か？

2. 我々はどこにいるのか？

3. 我々はどこを目指すのか？

4. どのようにして目標を達成するのか?

5. 達成をどのようにして確認するのか？

高レベルの事業達成目標

アセスメント、ベンチマーク

測定可能な目標

プロセス改善

測定項目と測定基準

6. どのようにして

維持するのか？

1. ビジョンは何か？

2. 我々はどこにいるのか？

3. 我々はどこを目指すのか？

4. どのようにして目標を達成するのか?

5. 達成をどのようにして確認するのか？

高レベルの事業達成目標

アセスメント、ベンチマーク

測定可能な目標

プロセス改善

測定項目と測定基準

プロセス導入の改善導入／改善のサイクルは、次に示す6段階のプロセスに基づいて実施します。

ビジョンは何か？ y我々はどこにいるのか？ y我々はどこを目指すのか？ yどのようにして目標を達成するのか？ y達成をどのようにして確認するのか？ yどのようにして維持するのか？ y

プロセスを導入または改善するときは、順序付けされたプロジェクトマネジメントのアプローチに従ってください。



My N otes

ITと事業の達成目標を整合させる、という達成目標ITと事業の達成目標を整合させるには、次のことが必要です。

戦略的方向性、明瞭な達成目標、および最終目標の達成度を y測定するためのパラメータを設定するリーダシップ新しい業務方法の受け入れ y事業、利害関係者、および事業の状況の深い理解 yビジネス・ニーズを理解するITスタッフ yITの可能性を理解する事業 y必要な人すべてが情報とコミュニケーションを利用できる可 y用性資料を理解するために特に定められた時間 y技術を継続的に追跡することによる事業機会の特定 y

前述の導入／改善サイクルも、事業とIT間の整合を追跡するのに役立ちます。

ビジョンは何か？サービス・プロバイダ組織のカルチャと環境は、これらのすべての活動において決定要因となります。人と々カルチャは改善を従順に受け入れる必要があります。このため、最初にすることは、組織内の人々が変更と改善を受け入れるようにすることです。

ライフサイクルのこの段階の重要なステップは、次のとおりです。

事業のビジョンおよび達成目標と整合性のあるビジョンを確 y立するプロジェクト／プログラムの適用範囲を設定する y一連の上位の達成目標を設定する yガバナンス、後援、および予算を確立する y上級マネジメントのコミットメントを獲得する y次に焦点を当てたカルチャを確立する y

品質 o

顧客重視と事業重視 o

学習環境 o

継続的改善 o

「改善サイクル」に対するコミットメント o

オーナシップと説明責任 o




My N otes

我々はどこにいるのか？より大きなビジョンと最終目標を確立した後に、サービス・プロバイダは、既存のプロセスと組織の成熟度に関して現在の状況をアセスメントする必要があります。

ここで必要なステップは次のとおりです。

望ましい技法を利用した、現状のレビュー、アセスメント、また yはより正式な監査

内部レビューまたは内部監査 o

成熟度アセスメント o

外部アセスメントまたはベンチマーク o

ISO/IEC 20000の監査 o

COBITに照らした監査 o

SWOT分析（強み（Strength）、弱み（Weakness）、機会 o（Opportunity）、脅威（Threat））リスク・アセスメントとリスク管理の方法論 o

レビューには次が含まれるべきである yサービス・プロバイダの組織のカルチャと成熟度 o

現状のプロセスと、その能力および成熟度 o

人材のスキルと力量 o

サービスと技術 o

サプライヤ、契約、およびその能力 o

サービスの品質と、現在の測定項目、測定基準、およ oびKPI調査結果と推奨事項をまとめたレポート o




カルチャの成熟度のアセスメントカルチャのアセスメントでは、カルチャの能力と成熟度を明らかにする必要があります。

アセスメントは、各成長段階がIT組織の変化を表すことを考慮して実施するべきです。カルチャのアセスメントには、次が必要です。

人材の変化（スキルと力量） yプロセスと業務方法 y技術とツール（人材とプロセスをサポートし、可能性を与える） y運営（ビジョン、最終目標、結果） y姿勢（価値観と信念） y事業、利害関係者、顧客、およびユーザとの、適切なレベルと度合いのやり取り y




サービスデザイン・プロセスの能力と成熟度をアセスメントの一貫としてレビューすることが不可欠です。

この種のレビューには、次のようなプロセスの側面と利用がすべて含まれます。

ビジョン：運営、達成目標、および計画 yプロセスの成熟度、機能性、利用方法、適用方法、有効性、効率性、ならびにオーナシップ、管理、文 y書化人材：人材の役割、責任、スキル、およびナレッジ y製品：プロセスの自動化に使用されるツールと技術を含む yカルチャ：焦点、姿勢、および信念 y


この種のフレームワークにより、プロセスのアセスメントが、より一貫性の高いものになります。これら2つの側面を評価することで、組織の現状と、サービスマネジメントの能力と成熟度のレベルが判断されます。サービスデザインの導入または改善の最初の段階において、現在のカルチャとプロセスの強みを活用すること、および現在の弱みに取り組むことが重要です。



My N otes

我々はどこを目指すのか？現状のビジョンとアセスメントを使用して、達成したい状態を定義することができます。この状態は、次のように、求められる成果として定義する必要があります。

ITサービス供給と全体的な事業要件との整合性の改善 yサービスデザインの品質の改善 yサービスレベルおよびサービスの品質の改善 y顧客満足度の向上 yプロセス・パフォーマンスの改善 y


どのようにして目標を達成するのか？次のステップでは、現在の状態から望ましい状態に移るために組織に必要な改善事項を特定し、改善を導入するための計画を準備します。

サービストランジションとサービスオペレーションがこの計画の一部となるべきです。この計画には、次が含まれている必要があります。

改善処置 y実施するべきアプローチと使用するべき手法 y活動と期間 yリスク・アセスメントとリスク管理 yリソースと予算 y役割と責任 yモニタリング、測定、およびレビュー y


達成をどのようにして確認するのか？最初に測定の仕組みを配置しなければ、改善の取り組みが成功かどうかを評価することができません。導入を開始する前に、適切に定義した測定基準を決定してください。

測定基準は、次のように明確に測定できる必要があります。

サービスデザインの不適合をX％削減 y顧客満足度をX％向上 y重要なサービスのサービス可用性をX%向上 y




My N otes

改善計画を導入した後に、次のことを確認するためにレビューを実施する必要があります。

希望する達成目標を達成した。 y改善を導入するための、より良い方法がある。 yほかの改善も導入する必要がある。 y

どのようにして維持するのか？実施した改善を統合する必要があります。サービス・プロバイダ組織は、常に改善の余地があることを受け入れて、継続的な改善を支援する環境を築く必要があります。望ましい状態を達成したら、6段階のプロセス全体を繰り返す必要があります。このプロセスには、次が含まれます。

学習環境を構築する。 y組織内全員の改善意欲を向上させる。 y品質と改善がすべての人の懸案であることを全員が理解する yのを支援する。改善の推進力を維持する。 y



My N otes

10.5　プラクティスとプロセスの導入における課題、CSF、リスク

新しいサービスまたは変更を導入する際の課題eビジネスにおいて、ITは主要なビジネス・プロセスをサポートするだけでなく、実際にプロセスの一部となっています。さらに、サプライ・チェーンの至る所でサービスの複雑さが増しています。これらの要素のために、サービス・プロバイダは新しいサービスまたは変更を導入する際に、広範囲に及ぶ課題に直面します。

事業要件をすべて満たす新しいサービスを設計する場合、数多くの課題に直面する可能性があります。

課題を克服するには、次のような特定の指針に従います。

新しいサービスまたはプロセスを設計する際に、事業要件に y優先度を付ける。サービスまたはプロセスの導入による影響を受ける可能性 yのある人と々コミュニケーションを取る。

適切な解決策を作成してサポートを得るために、フォーカス・ yグループまたは運営グループを設定し、できるだけ多くの人を参加させる。上級マネジメントと組織内のすべてのレベルのスタッフから yコミットメントを得る。

サービスデザインの課題新しいサービスまたはプロセスを設計する際に直面する可能性のある一般的な課題を次に示します。

新しいサービスと既存のアーキテクチャ、戦略、および方針の y整合異なる技術やアプリケーションの使用 y受け入れられたプラクティスとプロセスの文書化と順守 y事業要件の変更または不明瞭な事業要件 yサービスおよび事業の目標と要件に対する認識およびナレッ yジの不足設計を作成する際の既存の機能に関する検討 y無計画な取り組みや無計画な購入 y



My N otes

労力とコストの損失につながるリソースの非効率的な使用 y事業上のインパクトと優先度に関するナレッジと理解の不足 yITサービス・プロバイダと事業の間のコミュニケーション不足 yと緊張した関係合意された戦略に従って動くことへの抵抗 yレガシー技術とレガシー・システムの使用 y高コスト、複雑さ、または必要なツールを導入するスタッフの y現在のスキル・セットとの不一致情報、モニタリング、および測定の不足 y以前のSLAとOLAで合意された非実用的な目標値と日程 yプロジェクト・コストまたは作業に関する利用可能なリソース yの過度なコミットメント不十分なサプライヤ管理や不十分なサプライヤのパフォーマ yンスサービス可用性への注目不足 yセキュリティの方針と手順における運用上の側面に対する認 y識と順守の不足通常の日々の運用と通常業務の維持 yコストと予算の制約 y投資利益率（ROI）と事業利益の確定 y

サービスデザインのリスクライフサイクルのサービスデザイン段階におけるリスクについても検討する必要があります。サービスデザインに関連する共通のリスクの一部を次に示します。

成功の必須条件（PFS）を順守しておらず、サービスデザイン・ yプロセスまたはサービスマネジメント・プロセスに失敗する。1つのプロセスの成熟度レベルが低く、ほかのプロセスの成 y熟度レベルに影響する。ITスタッフに伝えられた事業要件が不明瞭である。 yテストが不十分で、そのためサービス設計に不備があり、サ yービス導入がうまくいかない。サービスの革新、リスク、およびコストのバランスが悪い。 yインフラストラクチャ、顧客、およびパートナの調整が不十分 yである。ITの計画立案者と事業の計画立案者の間の調整がない。 yサービスマネジメント戦略と方針が利用不可能で不明瞭で yある。



My N otes

サービスデザイン活動の時間、リソース、トレーニング、およ yび予算が不十分である。固有の資産とインフラストラクチャを使用することによるサー yビス開発の孤立により、最終的にはコストの増加につながる。アプリケーション開発に対するコミットメントが不足してお yり、サービスデザイン要件への注目が十分でない。

サービストランジションのリスクサービスデザインに関連するリスクに加えて、計画されているサービスと移行中のサービスに対する潜在的リスクも識別する必要があります。サービストランジションでの実施上のリスクを識別するために、現在のサービストランジションと計画されているプロジェクトのベースライン・アセスメントを行う必要があります。

サービストランジションに関連する共通のリスクの一部を次に示します。

要員のモチベーションを下げるような、既存プロジェクトの説 y明責任、実行責任、およびプラクティスの変更主要なサポート・スタッフおよび運用スタッフの離反 y移行中のサービスに対する、計画外の追加コスト y官僚主義的と認識されたために起こる、変更への抵抗やプロ yセスの回避サービストランジションのプラクティスと計画でリスクを回避 yしすぎることで、事業に過剰なコストがかかるナレッジを共有すると、不適切な人々も情報にアクセスする yシステムおよびツールの成熟度と統合が不足しており、他の y欠点についても技術が「非難」されるようになるプロセス間の統合が不十分であるため、プロセスが孤立する yサービストランジションのプロセスが不十分であるため、生 y産的な時間の損失、コストの増加、収入の低下、あるいは事業の失敗さえもたらされる

（出典：『サービストランジション』）



My N otes

サービスオペレーションのリスク導入を成功させるために、サービスオペレーションにおける潜在的リスクも識別する必要があります。次に例を示します。

サービスの損失：これはサービスオペレーションにおける究 y極のリスクです。サービスの損失は事業、財源、および従業員の損失につながる可能性があります。健康機器や車両を扱う場合は、スタッフの手足を失うおそれもあります。サービスオペレーションの成功に対するリスク：これには、サ yービスオペレーション時の不十分な資金調達、原価計算、およびリソース、サービスマネジメント・プロセスに対する漫然とした姿勢、および健康上の理由または辞職による主要な要員の喪失などがあります。このため、組織は、スタッフを入れ替えるために緊急時対応計画を準備しておいたり、リスク状況に対して複数の部門の既存のスタッフに多方面の訓練を行ったりする必要があります。また、スタッフが変更を受け入れて従うことを拒む状況に直面する可能性もあります。チームをトレーニングおよびカウンセリングすることにより、変更を促進する必要があります。このほかに、サービスオペレーションの成功を阻むリスクに yは、マネジメントからのサポート不足、サービスデザインの欠陥、サービスマネジメントに対する信用不足、またはサービスに対する顧客の認識と要件の違いなどがあります。例えば、ある顧客が優れたサービスを受けるために代価を支払ったとします。しかし、ほかの顧客はその優れたレベルのサービスを見て、だまされたと感じる可能性があります。従って、プロジェクトを開始するときに、顧客に対してサービスデザインのコストについて説明する必要があります。

サービストランジションの課題eビジネスにおいて、ITは主要なビジネス・プロセスをサポートするだけでなく、主要なビジネス・プロセスの一部となっています。さらに、サプライ・チェーンの至る所でサービスの複雑さが増しています。この結果、サービス・プロバイダは新しいサービスまたは変更を導入する際に、広範囲に及ぶ課題に直面します。

サービストランジションを成功させる際に直面する共通の課題の一部を次に示します。

大きな顧客グループとすべての利害関係者のグループを扱 yう。サービストランジションがインパクトを与える、ほぼすべてのビジネス・プロセスとサービスを含む。多数の窓口、関連プロセス、および関係をサービストランジシ yョンを通じて管理する。



My N otes

財務、エンジニアリング、人的資源など、サービストランジショ yンにインパクトを与えるプロセスや規律における統合の不足を管理する。未知の依存関係を発生させる、レガシー・システムと新しい要 y素の間の本質的な違いを管理する。安定した本番環境と、ビジネス・ニーズに従って変化を続ける yサービスの間でバランスを維持する。実践的な選択肢（実用主義）と組織的な形式主義（官僚主義） yの間でバランスを維持する。標準化、単純化、およびナレッジ共有を促進する環境を作り出 yす。事業の変更を可能にし、事業変更プログラムに貢献する。 y変更と改善を推進するリーダを育てる。 y 「誰が、何を、いつ、どこで行っているか」および「誰が、何を、 yいつ、どこで行うべきか」を明確にする。人々が協働し効果的に作業することを奨励するカルチャを促 y進する。複数のプロジェクトとサプライヤに適用される、標準的なパフ yォーマンス指標と測定方法を策定する。提供とサポートの品質を、事業が新技術を使用する方法に確 y実に適合させる。サービストランジションの時間と予算が、サービス・ライフサ yイクルのそれより前のイベントのインパクトを受けないようにする。効果的なリスク管理の基本となる、さまざまな利害関係者の y観点を理解する。リスクを管理することとリスクを負うことのバランスは、組織 yの全体的戦略、およびプロジェクト・リスクとビジネス・リスクの間に起こりうる不一致に影響を及ぼすため、これを理解し、アセスメントする。リスク管理とコーポレート・ガバナンスに関する報告の有効 y性を評価する。



My N otes

サービストランジションのCSF各組織は、事業要件に基づいて、絶えずサービス品質を改善すると同時に、費用対効果を向上しようと努力しています。

これを実現するには、次のようなサービストランジションのCSFについて検討する必要があります。

効果的なリスク管理を確保するために、利害関係者の観点を y理解して管理する。サービストランジションにおいて、窓口を維持し、すべての関 y係者の関係を管理する。サービストランジションに影響を与える、サービス・ライフサ yイクルのほかの段階のプロセスと規律にサービストランジションを統合する。人的要素を含む、レガシー・システムと新しいシステムの間の y本質的な依存関係を理解する。サイクル時間を短縮しエラーを排除するためにプロセスを自 y動化する。容易にアクセス可能なナレッジ・プールを作成して維持する。 yサービストランジションのプラクティスを管理するための良 y質な仕組み、ツール、プロセス、および手順を開発する。サービスマネジメントおよびITインフラストラクチャに関する y優れたツールと技術を導入する。カルチャ環境と政治環境を正しく理解して活用する。 yサービス、技術構成、およびそれらの依存関係を理解する。 yサービストランジションのプラクティスを管理するのに必要 yなプロセス、手順、スキル、および力量を理解する。正しいナレッジとスキル・セットを持ち、正しいサービス・カル yチャを備えた人材を育成する。具体的な役割とその責任を定義する。 yナレッジ共有を促進する環境を作り出す。 y改善されたサイクル時間を設定して導入し、時間、コスト、お yよび品質の予測値からの逸脱が最も小さくなるように変更を実施する。サービストランジションにおける、顧客とユーザの満足度の y改善を保証する。サービストランジションのプラクティスとプロセスを確立し改 y善することの利点が関連コストを上回ることを実証する。サービストランジション活動において、リスク管理に対する組 y織のアプローチを効果的に伝達する。



My N otes

サービス・ポートフォリオ内のサービスのサービストランジシ yョンの成功にインパクトを与えた、または与える可能性のあるリスクを理解して分析する。

資金の正当化サービスオペレーションにおいて資金を節約し、サービスオペレーション領域でプラスのROIを示すには、次を行う必要があります。

ライセンスと展開されたコピーのより適切な管理によるソフ yトウェア・ライセンスのコストの削減インシデントと問題の減少および解決時間の短縮によるサポ yート・コストの削減人員整理、支援的な役割、および説明責任の構造を通じた人 y員削減低品質のITサービスによる「事業損失」の削減 yより優れたキャパシティ管理による既存のインフラストラクチ yャ機器の適切な利用とさらなる支出の先延ばし重複の少ない活動および既存リソースのより有効な使用に yつながる、プロセスの適切な整合

（出典：『サービスオペレーション』）

サービスオペレーションの課題サービスオペレーション・マネージャが直面する課題の一部を次に示します。

サービスオペレーションでは継続的で反復可能な管理プロセ yスと活動にのみ焦点を当てるため、プロジェクトの設計後はサポートを得られません。このため、サービスオペレーションは、設計段階に自らのスタッフを含めるとともに、プロジェクトの設計後に移行段階と運用段階をサポートするように計画する必要があります。ほとんどの場合、プロジェクトが計画どおりに実行されなかっ yた場合、またはプロジェクトが指定された予算や期限を超えた場合は、IT運用管理チームが責任を負います。これは、サービスデザインとサービスオペレーションが、プロジェクトの完了に対して異なる測定基準を持っているためです。これらの状況は、サービストランジション段階に運用スタッフを関与させることで回避できます。さらに、サービスオペレーション・マネージャはサービスの移行を支援し、課題をアセスメントして解決することができます。



My N otes

設計段階から運用段階への移行を管理するのにサービスト yランジションを使用しないこともあります。一部の組織では、変更管理を使用して、その変更がサービスにプラスの影響を与えるかどうかを分析することなくサービス変更を処理して導入します。変更のプラクティスが不適切に管理されるのを防ぐには、サービストランジション方針に従う必要があります。サービスオペレーション・マネージャ、変更マネージャ、および移行マネージャは、テストすることなく不適切な変更を運用環境に加えることを却下する必要があります。設計段階と移行段階にサービスオペレーション・スタッフを関与させることで、これらの課題に対処することができます。アイテムとサービス・パフォーマンスを測定するのが難しい場 y合もあります。サービスのパフォーマンスが良いか悪いかを判断できず、この課題を解決するためにSLMプロセスを使用しなければならない場合があります。このためには、プロセスにサービスオペレーション・スタッフを関与させる必要があります。大きなチーム構造を持つ組織では、スタッフは異なるタスク yを異なるレベルに報告しなければならない場合があります。このために混乱が生じタスクが失敗することがあります。しかし、必要に応じてスキルとナレッジを管理する際に組織にとって役に立つ場合もあります。サービスオペレーション・マネージャは、内部関係と外部関係 yを管理するのを困難に感じることもあります。今日、ほとんどの組織が多様なサービス、ネットワーク、およびパートナを持っているため、これらを効率的に管理することは困難です。このため、マネージャは、この課題を扱うために関係管理に関するナレッジとスキルを持っている必要があります。

サービスオペレーションのCSFサービスオペレーションのCSFの一部を次に示します。

上級および中級マネジメントからのサポート y事業部門からのサポート yITSMへの熱意とコミットメントを持ち組織内のスタッフを導く yことができる積極的な「推進者」適切な人数のスキルの高いスタッフ yより広範で全面的な利点を得るための十分なトレーニングと y意識付け十分かつ適切なツールのサポート y提供されるシステムとコンポーネントの品質 y明確な目標に対する明確に定義された測定項目と報告、およ yび進捗とレビューの容易かつ迅速なレビュー



My N otes

10.6　サービスマネジメント技術の計画立案と導入

ITSMツールの導入に伴う要素ITSMツールを導入する場合、展開および導入中に数多くの要素を計画する必要があります。

このような要素の例を次に示します。

ライセンス y展開 yキャパシティ・チェック y技術展開のタイミング y導入の種類 y

これらのすべての要素について詳しく見てみましょう。

ライセンス多くの場合、統合ITSMツールはモジュール式で販売されます。従って、各モジュールの具体的な機能を理解して、各モジュールにアクセスするユーザの数と種類を決定する必要があります。必要なユーザ・ライセンスの数と種類に基づいて、統合ITSMツールの総コストを決定することができます。

利用できるライセンスには、次の3つの種類があります。

専用ライセンス：これらのライセンスは通常、サービスデスク・ yスタッフなど、モジュールに頻繁かつ長期にわたりアクセスして使用する必要のあるスタッフが必要とします。共有ライセンス：これらのライセンスは、モジュールにアクセ yスして使用する必要はあるが、使用しない期間が長いため、同じライセンスを共有できるスタッフが必要とします。潜在的なユーザの数、使用期間、および予想される未使用期間に基づいて、購入するライセンスの数を適切に見積もることができます。ウェブ・ライセンス：これらのライセンスは、遠隔からモジュー yルにアクセスする必要のあるスタッフ、頻繁にはモジュールにアクセスしないスタッフ、またはモジュール機能全体の一部にしかアクセスを必要としないスタッフが必要とします。ウェブ・ライセンスは通常、ほかのライセンスに比べて低コストです。これに加えて、使用率が低いとコストはさらに低くなります。



My N otes

これら3種類のライセンスに加えて、オンデマンド・サービスというもう1つの選択肢があります。この場合、ITSMツールまたはアプリケーションへのアクセスは、必要な需要期間にのみ提供され、アクセスした時間に基づいて課金されます。この種の提供物は、組織が小規模な場合、または該当するツールが非常に専門的で、使用頻度の低い場合に魅力的となる可能性があります。

多くの場合、特定のコンサルティング業務の一環として提供されるITSMツールも使用することができます。この場合には、ライセンス料はコンサルティング料に含まれるか、または追加料金として請求されます。ライセンス・ツールまたはソフトウェアを使用するための別の選択肢として、モニタリングや問い合わせのソフトウェアなど、エージェント／活動ごとに利用する方法があります。この種類では、エージェントの数、その場所や行われる活動量に基づいて課金されます。

ただし、ライセンス体系を調達する前にコストを決定する必要があります。

展開ディスカバリ・ツールやイベント・モニタリング・ツールなどのITSMツールを展開する前に、クライアント／エージェント・ソフトウェアをすべての対象個所に展開しなければならないことがあります。このため、慎重な計画立案、スケジューリング、テスト、および実行をする必要があります。また、正式なリリース管理および展開管理、または何らかの形式の暫定的な変更管理を使用しなければならない場合もあります。サポート・スタッフが更新に関する詳細情報とナレッジを入手できるように、投入の間ずっとCMSのレコードを最新に保つ必要があります。

クライアント／エージェント・ソフトウェアは、クライアント・ソフトウェアを認識させるために装置を再起動しなければならない場合があります。このため、この種類のソフトウェアを展開する場合は、遅延を回避するために必要な取り決めを行う必要があります。

キャパシティ・チェッククライアント／エージェント・ソフトウェアを展開する場合、すべての対象個所が新しいソフトウェアを実装し、実行するのに十分なストレージ・キャパシティと処理キャパシティを持っていることを確実にするために、キャパシティ管理を実施しなければならない場合があります。また、管理情報、ログ・ファイル、ソフトウェアや構成ファイルなど、大量のデータの送信を処理するネットワークのキャパシティもチェックする必要があります。



My N otes

技術展開のタイミングITSMツールを展開する場合、組織のITSMの洗練さとナレッジのレベルに照らして、適切なタイミングでツールを展開することが重要です。このためには、ツールによって対処できそうなプロセスを調べ、新しいプロセスにスタッフを引き入れる必要があります。

適切なツールがなければ実施できないプロセスもあります。このため、ツールを導入するタイミングのバランスを取る必要があります。これに加えて、適切なタイミングでトレーニングを提供し、展開前にスタッフにツールの運用に精通させる必要があります。

導入の種類組織のビジネス・ニーズに基づいて、ビッグバン的に一度に導入するか、段階的に導入するかを決定する必要があります。ほとんどの組織では、導入中も稼働中のサービスを運用し続けます。このため、段階的アプローチのほうが適しています。以前のサービスまたはツールを新しいものに取り替える場合、データを転送する必要があり、また新しい一連の要件に対応するために再構成が必要な場合があります。データ転送プロセスに時間がかかったり、複雑であったりする場合は、最初の期間は両方のバージョンを同時に実行して、以前のデータをすぐに参照できるようにしておく必要があります。このような場合、新しいデータが古いツールに記録されないように、以前のバージョンを読み取り専用にしておくことが重要です。




このユニットには模擬試験問題はありません。


付録 Aケース・スタディ

ITIL v3 Intermediate Certification Level | Case Study


ロイヤル・チャオプラヤ・

ホテル

ホテルの概要　　　課題　　　　組織図　経営陣とスタッフ

免責条項：ストーリーの中で登場する人物、名称については、フィクションです。

ITIL v3 Intermediate Certification Level | Service Offerings and Agreement


ロイヤル・チャオプラヤ・

ホテル

ロイヤル・チャオプラヤ・ホテル（愛称はロイヤル）は、バンコクのチャオプラヤ川沿いにあるシティ・ホテルです。

1983年に、中国系タイ人の実業家であるテック・ウィー・リム（通称ハリー・リム）によって建てられ、その32階建ての建物は、25年近く、バンコクの空にそびえています。ロイヤルは、近くの由緒あるオリエンタル・ホテルを手本としています。5つ星ホテル市場に君臨するオリエンタル・ホテルに対抗して、ペニンシュラ（1998年オープン）やロイヤル・オーキッド・シェラトン（2001年改装）など、新しいホテルが次々に建てられています。その中には、国際的なホテル・ブランドを後ろ盾とするものもあります。

ここ10年間、競争が激しくなってきたため、目標とする宿泊料を145ドルから445ドルの間に据え置いたままで、前と同じ客室稼働率を達成することはますます困難になっています。

新たな競争相手の出現にもかかわらず、ロイヤルは宿泊客から高く評価されています。その多くは、ビジネスマンの常連客です。

大まかに分けると、5月から10月は宿泊客の大部分がビジネス客であり、11月から4月までと大半の週末は、観光客がほとんどになります。ロイヤルは、サパーンタクシン会議場とのコネがあるので、常に他の5つ星ホテルよりもかなり恵まれた立場にあります。というのは、会議に出席する宿泊客の客室1室当たりの売上高（RevPAR）は、通常の宿泊客より平均して30～50%高いためです。これは特に、医学、法律、保険、IT関係の会議の場合に当てはまります。こうした会議の出席者は、宿泊とそれに付随するサービスに対して、通常の宿泊客の最高3倍もの金額を支払います。

また、シティ・ホテルであるロイヤルは、公共交通機関へのアクセスが便利なことからも恩恵を受けています。バンコクの素晴らしいスカイトレイン（BTS）の駅までは90メートル足らずです。スカイトレインを使えば、宿泊客は市内で最も魅力的な場所へ、快適に、早く、安全にたどり着くことができます。また、ロイヤルには独自のボート・サービスがあり、リバー・ツアーや水上マーケットなど、市内の異国情緒溢れた場所への案内も提供しています。



設備

評価：

ビジネス・センタ、レストラン、バー、サウナおよびスパ付きのフィットネス・センタ、屋外プール

高級レストランヘブンリー 33

ロビー・バーシュガー・リーフ

紳士向けスモーキング・クラブハリーズ

4つのレストラン外部企業への賃貸

ホテルのデータ

客室 340

スタンダード 130

スカイ・ビュー 80

スカイ・エグゼクティブ 130

宿泊客の平均滞在日数は3.5日

人事

ホテルでは200名以上のスタッフが働いています。フロント係だけで70名おり、そのうち24名は、宿泊客サービスと受付を交代で勤めています。

スタッフの離職率は年平均30%です。つまり、平均すると3年でスタッフ全員が入れ替わる計算になります。もちろん実際には、従業員の中で中核を成すチームは長く勤めています。事実、32名のスタッフが、勤続20年で表彰されています。

} スイート 30



課題

サービスの質

最近、総支配人（ジェームズ）は、クイーンズランド大学のホスピタリティ・スクールによる、サービスの質に関する論文プロジェクトをホテルで実施させました。その結果は、経営陣にとって衝撃的なものでした。プロジェクトが実施された1か月間で、宿泊客の不満につながる重大なインシデントが73件も見つかったためです。

学生たちによると、苦情の50%は、宿泊客が期待したサービスと実際のサービスとの不一致に関するものでした。35%は、オーバーブッキングや宿泊客の要求に対して不適切な対応をするなど、サービス上の不手際でした。そして約13%は、「注文の多い客」と見なされました。これは、客観的かつ公平な基準から見ても、要求が過剰で、かつ評価が手厳しい宿泊客のことです。

ジェームズと客室部門担当マネージャであるディミトリは、回避可能だったと考えられる85%の苦情について特に懸念を抱いています。さらなる分析によって、これらの苦情のうち50%は宿泊客の滞在期間の初期に発生したもので、その結果、宿泊客が滞在期間を短縮またはすべてキャンセルしたため、利益の損失につながったことが判明しました。

報告によってさらに、ロイヤルには才能と意欲に溢れた従業員が多数いる一方で、構造化されたサービス改善計画や補償計画（苦情が起こってしまった場合の補償）がないこともわかりました。実際に一部の苦情は、類似するインシデントに対して苦情を申し立てたときに、ホテル側の対応が宿泊客によって異なる（一部の客が厚遇されている）と宿泊客が感じたことによるものでした。

新しい競争形態

ロイヤルはシティ・ホテルとして成功してきましたが、ホテル・チェーンに属する主な競争相手は、自らの所有するタイ国内のさまざまなホテルでの滞在を1つのパッケージにまとめることで、ロイヤルの顧客の一部を奪いつつあります。

例えば、バンコクで3日間過ごした後、チェンマイの心地よい田舎に行って活気ある地元市場や象乗り体験を楽しんだり、またはサムイ島やピピ島といった島に行ったりして、かなりの日数を過ごすというものです。

会議に出席する宿泊客で、配偶者や家族と来ている人々は、とりわけこのサービスに魅力を感じています。ロイヤルの経営陣は、貴重な常連客である会議出席者の減少を防ぐため、いかにしてポートフォリオに新しいサービスを導入できるかを積極的に検討しています。

スケーラビリティ

ロイヤルが直面しているもう1つの課題は、ロイヤルとサパーンタクシン会議場の良好な協調関係にも一部起因しています。サパーンタクシン会議場は、過去10年間にわたって成功を収め続けていることから、最近になって会議場の設備を70%拡張することを決定しました。これにより、ロイヤルの客室需要は最高で1,100室以上になります。ロイヤルは客室拡張のための土地と財力はありますが、この拡張を実現するためには持ち株会社から承認が必要になります。総支配人

（ジェームズ）は、この新たな開発に関してロイヤルがまだ十分な分析を行っていないことと懸念していますが、一方でホテルのオーナ（ハリー）は、サパーンタクシン会議場がそれほど多くの新規参加者を獲得するのはほぼ無理だろうと思っています。



課題

キオスク

宿泊客へのサービスを改善する一方、増加する宿泊客を適切にコントロールすることができるよう、ロイヤルはキオスクをインストールし宿泊客にセルフサービス機能を提供することを決定しました。キオスクを利用すれば、宿泊客はスパ施設のサービス予約をしたり、プールで行われるスキューバダイビングのクラスを予約したり、地元レストランの割引クーポンや地図などの情報を印刷することができます。

この新しいシステムを利用するには、客室のカードキーが必要です。もちろん宿泊客は、客室に入るためには客室のカードキーを持っていなければなりません。つまり、ホテルの中ではいつでもどこでも、宿泊客は当然自分の客室のカードキーを持っていると考えられます。このカードにおいて最も重要な点は、その宿泊客が誰なのかを認証することです。キオスクハードウェアを利用すれば、新しい情報や更新された情報をカードに書き込むこともできます。キオスクの利用はロイヤルの大きな前進ですが、キオスクは、ITに頼るため本番環境に移行する前に、発生しうる数多くの懸念事項を確認する必要があります。

上述したようにロイヤリティプログラムでは、宿泊客はプール施設でサウナを利用したり無料の食事や飲物を注文したり、さらなるサービスを利用するために、紙に印刷されたクーポンを渡されます。残念なことに、宿泊客は頻繁にこのクーポンを紛失してしまい、宿泊客の特権を適切に管理できる良い方法はないのかと苦情の声がありました。キオスク機能と結合する客室カードの利用は、このような状況を解決できるでしょう。

更にロイヤルは、近年増加の一途をたどる客室でラップトップを使用する宿泊客に、キオスクで利用可能な全ての機能の提供したいと思っています。ラップトップ使用時には、先述の状況とはうって変わって客室カードを更新する術がありません。しかし、アプリケーションは確実にサービスと特定の客室とを結びつけることが可能です。



参考

(ご参照ください）

ロイヤル・チャオプラヤ・ホテルの背景

沿革

オーナ

テック・ウィー・リム（ハリー）ハリー・リムは、1970年代に絹の貿易商として富を築きました。元々の事業は、バンコクを通過する旅行者向けの、安価かつ華美な衣服の貿易でした。ハリーの会社の成功に拍車がかかったのは、ラルフ・ローレンがウドンタニにあったハリーの繊維工場の1つと契約し、請負契約によってラルフ・ローレン・ブランドのスーツを生産して米国に輸出することになったときでした。それから今まで、ハリーは後ろを振り返ることなく前進してきました。

1981年に、債権者の1人が深刻な財政難に陥って負債を清算することになり、ハリーは支払いとしてロイヤル・チャオプラヤ・ホテルを引き取りました。当時、ロイヤルは完成間近で、最高の立地条件にありました。ハリーは資金を出してホテルを完成させ、1983年にロイヤルをオープンさせました。

ハリーは非常に慎重で洞察力のあるビジネスマンです。サービス業の複雑さをあまり理解していないので、「質が良ければうまくいく」というシンプルな前提で仕事をしています。「お客様は常に正しい。つまり正しい顧客を獲得し、正しくもてなせば、必ず成功する」というわけです。ハリーは、宿泊客からは見えない部分に費用をかけることを好みません。その結果、紳士向けスモーキング・クラブは皮製の椅子やチーク材の仕上げ、金の装飾など華美なものになっている一方で、ITアプリケーションなどの支援的なインフラストラクチャに関しては、ほとんど投資がなされていません。



組織図

テック・ウィー・リム

（ハリー）

オーナ

アッカラット・リム

（ジェームズ）

総支配人

ディミトリ・

ヴァン・ライン

（ディミトリ）

客室部門担当

マネージャ

チェ・

イグレシアス

（チェ）

飲食部門担当

マネージャ

キエット・

アピルクトヤンウント

（パップ）

エンジニアリング担当

マネージャ

カンヤ・

ウングヴィチェン

（ニー）

セールス／マーケティング担当マネージャ

スバルナ

レクリエーション・サービス

担当マネージャ

カツシ・フジヤマ

財務担当

マネージャ

スチュー・ミラー

人事担当

マネージャ

ダニエル・

キドワイ

（ダン）

保守責任者

イザベル・

オハラ

フロント／ビジネス・センタ

責任者

メアリー・

サンチェス

客室係

責任者

ジャニータ・

サンチェス

経理担当

イベット・ルルー

シェフ

ジーン

アシスタント・シェフ



経営陣

総支配人

アッカラット・リム（通称：ジェームズ）ジェームズはハリーの次男です。ジェームズがホテル事業を担っていくことは、常日頃からのハリーの意向でした。ジェームズはバンコクのハロウ・スクールに通った後、同じくバンコクにあるインターナショナル・ホテル・ツーリズム・インダストリー・マネジメント・スクールに進学しました。卒業後はニューヨーク大学のプレストン・ロバート・ティッシュ・センタでホスピタリティ／観光学／スポーツ・マネジメントについて学び、1997年に理学修士を取得しました。

ジェームズはタイ人の母親から自由な精神を受け継いでいます。母親のイスラ・サンシリトーン（通称エル）はタイのコ・パ・ガン島で育ち、常に人生を愛する外交的な人物です。夫が慎重で内省的な性格であることと、釣り合いがとれているようです。

ジェームズは36歳になり、父親の束縛から自由になってホテルの近代化を進めたいと強く願っています。ジェームズは、この業界の風向きの変化を感じ取っています。彼は今、ロイヤル・チャオプラヤ・ホテルを築き上げる力となった父親の倹約精神に対して、果敢に立ち向かっているところです。

ジェームズには父親にない若さ、現代的な展望、そして島育ちの母から受け継いだ今この瞬間を楽しむ精神があります。それゆえ、事業の拡大計画や人事の刷新を実行できないことに、いくらか苛立っています。

客室部門担当マネージャ

ディミトリ・ヴァン・ラインロイヤルでの最も重要な仕事が、客室部門担当マネージャの仕事であることはほぼ間違いありません。この仕事については、専門家に任せる必要があるとハリーは早くから気づいており、この職務には常に、高い評価を受けているオランダのマーストリヒト・ホテル・マネジメント・スクールを卒業したオランダ人を雇い入れてきました。

ディミトリは、この職に着くスクール卒業生の4人目にあたります。彼は現実的かつ実用的であることを心がける典型的なオランダ人です。彼はまた、与えられた権限内で協調的にマネジメントを進めていく上で、従業員たちと親密になることが重要だと信じています。このやり方は、アジアの伝統的文化において常に受け入れられるわけではなく、ハリーと対立することもよくあります。ハリーは決して家族以外の従業員を信用しません。従業員は、農村地帯のイーサーン出身者が多く、この風変わりなオランダ人と彼独特のやり方をどう判断すればいいのか図りかねています。



飲食部門担当マネージャ

チェ・イグレシアスチェは1960年代にフロリダに亡命した両親を持つ、キューバ系の派手な人物です。熱帯地方のゆっくりとしたリズムを好み、常に精力的なディミトリとは自然と好対照をなしています。ハリーとチェは葉巻の趣味を共有しており、客をもてなすために惜しみなく金を使うのが成功の鍵だと信じています。チェは現在の職務に関する正式なトレーニングを何も受けておらず、バー経営における効率を測るための飲料原価率1などの、飲食業界での標準となっている飲食料の測定指標を利用することはありません。

チェは大学卒業後、長期休暇で世界旅行をしている時にバンコクに住み着き、その後出世階段を上ってきました。彼はマイアミでウェイターと即席料理のコックとして働きながら学費を稼ぎ、マイアミ大学で経営学士を取得しました。このように、わずかな間でも飲食業界に触れていたことと、ハリーからの力強い支援があることで、チェは飲食部門担当マネージャをなんとか努めています。彼の1日は、他のどの従業員よりも少し遅めに始まり、シエスタは欠かしません。彼はこう言います。「明日のパーティに出たいからって、今日死ぬほど働くことはないだろう？」

エンジニアリング担当マネージャ

キエット・アピルクトヤンウント（通称：パップ）パップは有名なチュラロンコン大学を卒業した注意深いエンジニアです。仕事に真剣に取り組む、非常に優秀な技術専門家です。品質にこだわるあまり、仕事を仕上げるのに顧客の期待よりも長く時間がかかってしまうこともあります。パップは休暇以外で外国に旅行した経験がなく、英語や外国人客との会話にあまり自信がありません。

多くのタイ人と同様、パップはどのような形であれ対立を好みません。そのため、時に問題を避けるために顧客や同僚と口約束を交わしてしまい、約束が実現できずに要求に応えられない状態に陥ってしまうことがあります。

ディミトリとジェームズは、海外からの顧客を扱うのが得意な人物を採用して、パップとともに働かせたいと考えています。保守責任者のダン・キドワイには東南アジア諸国での滞在経験があり、ある程度はバップの助けになっています。しかし、ダンが好むのは顧客と関わることよりも、むしろ彼が愛する機械のそばにいつもいることです。新たな人物を採用した場合の問題は、新たな助けが加わることで、パップが面子を潰されたと感じるだろうということと、彼がエルの従兄弟であり、大きな支援を受けているということです。



マーケティング部門マネージャグヴィチェン（通称：ニー）ニーは豊富な人脈を持つ、自信に満ちた若きプロフェッショナルです。もともと金融について勉強していましたが、すぐに自分がサービス業に向いていることに気が付きました。米国ハーバード大学で経済学を学んだ後、ヨーロッパでMBAを取得しました。

貿易業に携わる彼女の一族はコネクションも多く、友人や親類縁者のネットワークをフルに活用して、次と々ロイヤルの常連客を獲得しました。加えて、かつてのクラスメートの多くが医学界、法曹界、IT業界等

で活躍しており、こうしたつながりから実入りの良い会議や宴会の仕事が入ってきます。

レクリエーション・サービス担当マネージャスバルナスバルナはロイヤルの人気者です。ある日、いきなりハリーの事務所に現れて、ホテルにちょっとしたマッサージ設備を導入させてくれないかと自信ありげに頼みました。今や、これがホテルのレクリエーション施設の柱になっています。誰も彼女のフルネームや、本当の年齢を知らないようです。「そんな失礼なことは聞けなかったから」というのがハリーの言い草です。

スバルナは魅力的で優雅な女性です。水泳のチャンピオンだったこともある彼女は、イタリアのモンテカティーニにあるかの有名なテットゥッチョ・スパで仕事を覚えました。さらに今後、充実した設備の託児所を開きたいと考えていますが、ハリーはそこまで画期的なサービスの必要はないと思っています。「赤ちゃんが泣いたりすれば他のお客様の迷惑になるだけだし、ホテルの従業員も皆、田舎に残してきた子供たちを連れて来て、ホテル中が子供で溢れ返ってしまうだろう」。

人事担当マネージャスチュー・ミラースチューは活気に満ちた米国人で、2001年の同時多発テロの後にパートナとともにタイにやって来ました。ニューヨークで起こったあの悲劇は、彼の人生観を変えてしまいました。競争に明け暮れる生き方を改めたいと考え、そのためにタイはうってつけの場所に思えました。いつか、どこかの島で自らリゾートを始めたいと考えています。ニューヨークに比べればいろいろな意味でまだ田舎に思えるものの、今のところバンコクの喧騒から離れがたい気がしています。

教育学博士号を持っているスチューには今の役割は少々物足りない気もしていますが、仕事自体は気に入っており、異文化間での交流を自分の貴重な財産にしたいと思っています。

財務担当マネージャカツシ・フジヤマフジヤマは日本人で、経験豊富な経理の専門家です。現在の仕事に就くまでに、ITや教育関連などさまざまな業種で働いてきました。何年も前、ハリーが輸出案件の交渉のため出向いた東京で、日本の輸入業者側の担当者だったフジヤマと出会いました。フジヤマを見込んだハリーが「断りようのない」待遇のオファーを出し、それ以来6年間、ロイヤルで働いています。

フジヤマはまじめで仕事熱心ですが、オフィスを離れて楽しい時間を過ごすことも大好きです。よくチェやハリーと一緒に高級カラオケ・バー「アマディス」や、町で評判の日本酒バー「ワサビ」にいるところを見かけます。



スタッフ

フロント／ビジネス・センタ責任者

イザベル・オハラロビーを含むフロントの責任者として、イザベルはロイヤルになくてはならない人物です。ハリーもジェームズも、彼女の精力的な仕事ぶりやコンピュータに明るいところを評価しており、ビジネス・センタとコーヒー・ショップも彼女の担当に追加したほどです。ジェームズは、ここをビジネスマンやコンピュータに慣れ親しんだ若い観光客が落ち着ける、気軽に利用できる場所にしたいと考えています。イザベルはエネルギッシュな人で、何か新しい動きがある所には必ず彼女がいます。新しい動きがなければ、彼女自身が自ら新しい動きを起こします。

イザベルは、個人的な対応が重要であり、顧客とのやり取りをすべて細かく管理すべきだという信念を持っています。どんな些細なことでも何一つ見逃しません。このため、今やチームのスタッフは、何事も喜んで彼女に決断を委ねるようになっています。自主的な判断など求められていないように思われるためです。彼女が1日の終わりには疲れ果ててしまうのも無理はありません。一体どこまで、1人でやりこなしてしまうのかと驚嘆します。猛烈な仕事のやり方を少しセーブしないと、燃え尽きてしまうかも知れないと忠告されています。最近は好きなジャズを聴く時間もほとんどなく、疲労のあまり趣味のスキューバ・ダイビングに行く気にもなれません。

シェフとアシスタント・シェフ

イベット・ルルーとジーンイベットはロイヤルの名物とも言える存在です。イベットの機嫌は、時を選ばずに豹変します。特に、自分の決定が受け入れられない場合は要注意です。

イベットは才能豊かなシェフで、複数の料理分野に精通しています。彼女は「食事を作ることは誰にでもできます。しかし、食事を神聖なものにまで高められるのはフランス人だけです」と公言しています。最高級のデザートを含め、イベットが作り上げる魅力的な食事を前に、経営陣は彼女の機嫌を損ねないようただただ必死になります。

しかしイベットが最後の最後までメニューについてあれこれ思案し、必要とする食材リストを突きつけてくるため、部下たちが苦心する場合も多く、チェもこのことに気づいています。イベットが要求する新鮮な魚介、野菜、果物は、1時間かかるサパーンマイの地元市場で調達します。この調達業務はロイヤル・グランプリ・レースと呼ばれ、地元では有名になっています。

ロイヤル・グランプリ・レース

長年の経験から選ばれた地元の納入業者の面々は厳戒態勢に入ります。イベットの若きアシスタントであるジーンが携帯電話を手に動き回り、ホテルの仕入れ用バンが待機しています。電話が鳴り、指示が伝えられた瞬間に、納入業者は行動を開始し、荷積み作業に大わらわとなります。

わずか数分でバンには納入品が積まれます。このロイヤル・グランプリ・レースでは、ジーンが比類無きスピードを披露します。ジーンがホテルに戻ってくるまでの時間を対象に、こっそりと賭けをしている者もいます。これを正式なプロのレースに仕立て上げようという冗談話さえ出ていたほどです。さすがにこの思いつきは、普段はおう揚な地元の警察官にも釘を刺されました。



ジーンはチェの暗黙の後押しを受けて、特に費用面から、この名物レースを毎日ではなく1週間に1回程度にしてもらえないかと、経営陣にかなり率直に依頼しています。しかし現在もまだ、この課題は解決されていません。

相手が手強いということを認識しているチェは、ひそかにコーヒー・ショップの改善を図り、迅速に提供できるさまざまな食事を提供したり、ビジネス客向けにWi-Fi無線通信環境を用意したりしています。少なくとも表向きには、イベットはコーヒー・ショップなどのジェームズの「ファストフード」構想に危機感を示していません。

客室係責任者メアリー・サンチェスサンチェス姉妹の姉であるメアリーは、いかなる手抜きも許さない完璧主義者です。メアリーの白手袋での業務チェックは、海兵隊の鬼軍曹でも認めるだろうと言われています。全スタッフがメアリーの存在に震え上がる理由の1つです。

メアリーの実直な勤務態度を疑う人はいません。しかし、メアリーが要求する極端に高い水準に、客室係が恐れおののくことも少なくありません。

メアリーは花が大好きで、珍しいパーロット・チューリップがお気に入りです。数少ない友人の1人は年配の庭師で、毎日午前11時にいっしょにコーヒーを飲んでいます。彼女は計画、管理、指示を徹底していますが、客室業務に関する苦情の増加には手を焼いているようです。指示や小言をどれだけ繰り返しても、部下の行動には変化が見られません。

経理担当ジャニータ・サンチェスジャニータ・サンチェスはメアリーの陽気な妹です。ジャニータは天性の統率力を備えており、周囲を元気づける態度によってロイヤルの若手従業員を大いに鼓舞しています。客室係を始めとして、多くの若手女性従業員の厚い信頼を得ているジャニータですが、相反する2つの感情で板挟みになることが少なくありません。姉に信頼と親愛の情を持つ一方で、質の高さで知られてきた客室業務の質の低下に懸念を強めています。

対人関係や数字の扱いには姉よりもはるかに長けたジャニータは、競争が激化する世界では資格、ノウハウ、経験を身につけることが常に不可欠であるとの考えから、（既に有している会計の基本的な資格以外に）経営を学ぶコースを受講することを検討しています。

ビジネス・センタ責任者のイザベル・オハラはジャニータの親友で、ジャニータが新しい技術を検討する際に手助けしてくれただけでなく、娯楽、教育、実務面でのさまざまな事柄をいっしょにオンラインで学習しています。



保守責任者ダニエル・キドワイ（通称：ダン）がっしりした体格の物静かなダン（37歳）は、機械作業が大好きです。ベテランになるに従って、会議や文書作成に費やさなければならない時間が増えるのが不満で、自分の手を「汚す」仕事ができる機会をいつでも狙っています。お茶を入れた魔法瓶と工具を持っているときが、ダンにとって一番幸せです。

しかし賢明なダンは、自分にとっての成功とは、自らの工場を設立するか、ホテルのヒエラルキーの中で昇進していくことであると理解しています。大家族を支えるダンにとって、開業という選択肢はリスクが高くなります。

ダンの祖父母はバングラデッシュのダッカからミャンマー、そして最終的にタイに移住してきました。ダンは苦労人で、昼間働きながら夜学で学び、工学分野の学位を取得しました。

これまでダンは、インドネシアの業務センタ、タイのホテル、マレーシアのリゾート施設など、複数の組織で働いてきました。

ダンは機械に関するスキルの高さと、経営陣の風当たりから部下を守ってくれることから、部下の尊敬を集めています。一方で経営陣側も、部下を掌握するダンの能力や「つべこべ言わずに」仕事をやってのける能力を高く評価しています。ダンは物腰穏やかですが、取引業者との交渉術には非常に長けています。

ダンは母親の母国語であるベンガル語の民謡が好きで、週末はサッカーも楽しんでいます。オーバーオールの作業着を着ていないときには、シンプルなコットン製の服を着るのがダンの好みです。


付録 B用語集

ITIL v3 Intermediate Certification Level | Glossary


用語、定義、頭字語

2008年2月25日更新（Baseline v01, 1 May 2006）

Acknowledgements

We would like to express our gratitude and acknowledge the contribution of Stuart Rance and Ashley Hanna of Hewlett-Packard in the production of this glossary.

Note for readers

This material may only be re-used under the terms of a licence from OPSI

See http://www.best-management-practice.com for details of licence terms.

ITIL ® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office

© Crown Copyright 2006



用語用語定義／備考Absorbed Overhead 配賦オーバヘッド（財務管理）特定の顧客に公正に配賦することが可能な、サービスの提供に関する間接費。配賦オ

ーバヘッドは、使用量やその他の公正な測定に基づく。例えば、ネットワーク帯域幅や共有サーバの提供にかかるコストなど。直接費、間接費、未配賦オーバヘッドも参照。

Acceptance 受け入れ ITサービス、プロセス、計画、またはその他の成果物が、完全かつ正確で信頼性があり、特定の要件を満たしているという正式な合意。通常、受け入れの前には評価またはテストが行われる。また、プロジェクトやプロセスの次の段階に進む前に要求されることが多い。サービス受け入れ基準を参照。

Acceptance criteria 受け入れ基準　

Acceptance environment 受け入れ環境 V3書籍内になしAcceptance test 受け入れテスト　Access control アクセス・コントロール　Access Management アクセス管理 (サービスオペレーション) ITサービス、データ、またはその他の資産をユーザが活用できるようにす

ることを責務とするプロセス。アクセス管理は、許可されたユーザだけが資産へのアクセスまたは修正を行えるようにすることで、資産の機密性、完全性、および可用性の保護を支援する。アクセス管理は、権限管理またはID管理と呼ばれることもある。

Accessibility アクセス性 V2黄色本では「アクセシビリティ」Account Manager アカウント・マネージャ (サービスストラテジ) 事業関係マネージャに極めて類似した役割。ただし、より営利的な側面を扱

う。外部顧客を扱う場合に最もよく配置される。Accounting 会計業務、会計 (サービスストラテジ) ITサービスの提供にかかる実際のコストを識別し、それらのコストを見積もら

れたコストと比較して、予算との不一致を管理することを責務とするプロセス。

Accounting Period 会計期間（財務管理）予算、料金、減価償却、およびその他の財務上の計算の対象となる期間。通常は1年間。会計年度を参照。

Accredited 認定ある役割を実行することを公式に認可されること。例えば、認定団体は、トレーニングや監査の実施を認可されている。

Active Monitoring 能動的モニタリング (サービスオペレーション) 自動的な定期チェックを利用して現状を把握する、構成アイテムまたはITサービスのモニタリング。受動的モニタリングを参照。

Activity 活動特定の結果を達成するために計画された一連の処置。活動は、通常、プロセスまたは計画の一部として定義され、手順に記載される。

Activity Based Costing (ABC) 活動基準原価計算（ABC） V3書籍内になしAdaptive maintenance 適応的保守 V3書籍内になしAdditive maintenance 付加的保守 V3書籍内になしAgreed Service Time 合意済みサービス時間 (サービスデザイン) サービス時間の同義語。可用性の正式な計算によく使用される。休止時間を

参照。

Agreement 合意複数の当事者間における正式な合意を記載した文書。合意は、契約の一部を構成しないかぎり、法的な拘束力を持たない。サービスレベル・アグリーメント、オペレーショナルレベル・アグリーメントを参照。

Alert アラート (サービスオペレーション) しきい値に達したとき、変更があったとき、または障害が発生したときの警告。アラートは多くの場合、システム管理ツールで生成および管理され、イベント管理プロセスで管理される。

Analytical Modelling 分析モデル化 (サービスストラテジ) (サービスデザイン) (継続的サービス改善) 構成アイテムまたはITサービスの動作を、数理モデルを使用して予測する技法。分析モデルは、キャパシティ管理と可用性管理によく使用される。モデル化を参照。

Application アプリケーション ITサービスに必要とされる機能を提供するソフトウェア。各アプリケーションは、複数のITサービスの一部になる場合がある。アプリケーションは、1台または複数のサーバまたはクライアント上で実行される。アプリケーション管理、アプリケーション・ポートフォリオを参照。

Application development アプリケーション開発　Application framework アプリケーション・フレー

ムワーク　

Application maintenance アプリケーション保守　Application Management アプリケーション管理 (サービスデザイン) (サービスオペレーション) アプリケーションのライフサイクルを通した管理を

責務とする機能。Application Management function アプリケーション管理機能　Application Portfolio アプリケーション・ポート

フォリオ(サービスデザイン) アプリケーションのライフサイクルを通した管理に使用するデータベースまたは構造化された文書。アプリケーション・ポートフォリオには、すべてのアプリケーションの主要な属性が含まれている。アプリケーション・ポートフォリオは、サービス・ポートフォリオの一部、または構成管理システムの一部として導入されることがある。

Application Service Provider (ASP) アプリケーション・サービス・プロバイダ（ASP）

(サービスデザイン) 自組織の施設内で実行しているアプリケーションを使用して、ITサービスを提供する外部サービス・プロバイダ。ユーザはサービス・プロバイダにネットワーク接続することによって、アプリケーションにアクセスする。

Application Sizing アプリケーション・サイジング

(サービスデザイン) 新しいアプリケーションや、既存のアプリケーションに対する重大な変更をサポートするために必要なリソース要件の把握を責務とする活動。アプリケーション・サイジングは、ITサービスが、キャパシティとパフォーマンスに関する合意済みサービスレベル目標値を確実に達成できるようにするために役立つ。

Application software アプリケーション・ソフトウェア

　

Architecture アーキテクチャ (サービスデザイン) システムまたはITサービスの構造。コンポーネント同士の関係や、コンポーネントとその環境との関係も含む。アーキテクチャには、システムの設計や発展を手引きする標準や指針も含まれる。

Archive アーカイブ（電子的ではない場合）保

管する、記録するなど

電子的な保存領域の場合のみ

Assembly アセンブリ (サービストランジション) 他の複数の構成アイテム（CI）から成るCI。例えば、サーバCIにはCPU、ディスク、メモリなどのCIが含まれ、ITサービスCIには多数のハードウェア、ソフトウェア、およびその他のCIが含まれるだろう。コンポーネントCI、構築を参照。

Assessment アセスメント標準や一連の指針に従っているか、レコードが正確か、効率性と有効性の目標値が満たされているかなどを確認する検査と分析。監査を参照。

Asset 資産 (サービスストラテジ) 任意のリソースまたは能力。サービス・プロバイダの資産には、サービスの提供に寄与する可能性があるすべてのものが含まれる。資産は、マネジメント、組織、プロセス、ナレッジ、人材、情報、アプリケーション、インフラストラクチャ、金融資本のいずれかのタイプになりうる。

Asset Management 資産管理 (サービストランジション) 財務資産の価値とオーナシップを、その資産のライフサイクルを通して追跡および報告することを責務とするプロセス。資産管理は、総合的なサービス資産管理および構成管理プロセスの一部である。資産台帳を参照。

Asset Manager 資産マネージャ　Asset Register 資産台帳 (サービストランジション) 資産の一覧。各資産のオーナシップと価値が含まれる。資産台帳は、資産

管理によって管理される。



用語用語定義／備考Assurance 確約、確実さ　Attribute 属性 (サービストランジション) 構成アイテムに関する情報の一部。名前、場所、バージョン番号、コストな

ど。CIの属性は、構成管理データベース（CMDB）に記録される。関係を参照。

Audit 監査標準や一連の指針に従っているか、レコードが正確か、効率性と有効性の目標値が満たされているかなどを確認する、正式な検査と検証。監査は、社内グループまたは社外グループによって行うことができる。認証、アセスメントを参照。

Auditability 監査可能性　Authentic 信頼するべき、真正性

のある　

Authentication 認証パスワードやユーザの認証の場合。certification（認証）とは区別する。

Authorisation 許可、認可　

Authorised Examination Centre 認定試験センタ試験委員会から、試験の実施を許可された団体。認定試験センタは試験会場を提供する。また、試験監督や自動採点を行う場合もある。

Authority (1) - as in authorization （1）許可を意味する場合 ― 許可

　

Authority (2) - as in responsibility （2）責任を意味する場合 ― 職務権限

（又は）権限

　

Authority Matrix 職務権限マトリクス RACIの同義語。Automatic Call Distribution (ACD) 自動着信呼分配(ACD) (サービスオペレーション) 情報技術を活用して、最適な相手に最短時間で着信呼を振り分けるこ

と。ACD（Automatic Call Distribution）はAutomated Call Distributionと表記されることもある。

Availability 可用性 (サービスデザイン) 構成アイテムまたはITサービスが、必要とされたときに、合意済みの機能を実行する能力。可用性は、信頼性、保守性、サービス性、パフォーマンス、およびセキュリティによって決定される。可用性は、通常、パーセンテージで計算される。この計算は、合意済みサービス時間と休止時間に基づいて行われることが多い。ITサービスに関する事業体のアウトプットからの測定値を使用して可用性を計算するのがベストプラクティスである。

Availability Management 可用性管理 (サービスデザイン) ITサービスの可用性のさまざまな側面を定義、分析、計画立案、測定、改善することを責務とするプロセス。可用性管理は、すべてのITインフラストラクチャ、プロセス、ツール、役割などが、可用性に関する合意済みサービスレベル目標値に適切であるようにすることを責務とする。

Availability Management Information System (AMIS)

可用性管理情報システム（AMIS）

(サービスデザイン) すべての可用性管理データの仮想的なリポジトリ。通常は複数の物理的な場所に保存される。サービス・ナレッジ管理システムを参照。

Availability Plan 可用性計画 (サービスデザイン) ITサービスに対する現在および将来の可用性要件を、費用対効果よく満たすようにするための計画。

Back-out 切り戻し修復の同義語。Back-out Plan 切り戻し計画（変更管理）（リリース管理）変更またはリリースが失敗した場合に、既知の稼働状態に戻すために

必要なステップを文書化した計画。Backup バックアップ (サービスデザイン) (サービスオペレーション) 元のデータの完全性や可用性の喪失を防止するた

めに、データをコピーすること。Balance Check バランス・チェック（財務管理）個々のコストまたは料金の総和が、コストまたは料金の総額と等しいことを検証する

計算。すべての金額が完全に把握されていることを確認するために行う。Balanced Scorecard バランス・スコアカード (継続的サービス改善) ハーバード・ビジネス・スクールのロバート・キャプラン（Robert Kaplan）教

授とデイビッド・ノートン（David Norton）教授によって開発された管理手法。バランス・スコアカードを使用すると、戦略を重要業績評価指数（KPI）に細分化できる。戦略がいかにうまく達成されているかを示すために、KPIに照らしたパフォーマンスが使用される。バランス・スコアカードには4つの主要な領域があり、各領域に少数のKPIが含まれる。これら4つの領域は、組織全体を通して、さまざまな詳細レベルで検討される。

Baseline ベースライン (継続的サービス改善) 基準点として使用されるベンチマーク。例として、次のようなものがある。ITSMベースラインは、サービス改善計画の効果の測定の開始点として使用できるパフォーマンス・ベースラインは、ITサービスの存続期間を通したパフォーマンスの変化の測定に使用できる構成管理ベースラインは、変更またはリリースが失敗した場合にITインフラストラクチャを既知の構成に戻せるようにするために使用できる。

Baseline Configuration ベースライン構成　Baseline Security ベースライン・セキュリティ（セキュリティ管理）組織全体で必要とされる、最低レベルのセキュリティ。Benchmark ベンチマーク (継続的サービス改善) ある時点で記録された物事の状態。ベンチマークは、構成、プロセス、または

その他一連のデータに対して作成できる。例えば、ベンチマークは次のような用途に利用できる。継続的サービス改善において、改善を管理するために現状を設定するキャパシティ管理において、通常の運用時のパフォーマンス特性を文書化するベンチマーキング、ベースラインを参照。

Benchmarking ベンチマーキング (継続的サービス改善) ベンチマークをベースラインやベストプラクティスと比較すること。ベンチマーキングという用語は、長期間にわたって一連のベンチマークを作成すること、そして進捗や改善を評価するためにその結果を比較することも指す。

Best Practice ベストプラクティス複数の組織で成功している、実績のある活動またはプロセス。ITILはベストプラクティスの一例である。

Billing 請求処理、請求（財務管理）課金プロセスの一部。請求処理は、明細書や請求書を作成し、顧客から料金を回収することを責務とする活動である。価格設定を参照。

Biometrics 生体認証　Brainstorming ブレインストーミング (サービスデザイン) チームでアイデアを出すことを支援する技法。アイデアのレビューは、ブレイン

ストーミング・セッション中ではなく、セッション後に行われる。ブレインストーミングは、考えられる原因を識別するために問題管理で使用されることが多い。

British Standards Institution (BSI) 英国規格協会（BSI）英国標準の作成と維持を責務とする、英国の国内標準化団体。詳細は、http://www.bsi-global.comを参照。ISOを参照。

BS 15000 BS 15000 英国規格協会によるITサービスマネジメントの仕様と実践のための規範。BS 15000はITILのベストプラクティスに基づいており、現在はISO/IEC 20000となっている。

BS 7799 BS 7799 英国規格協会による情報セキュリティ管理の仕様と実践のための規範。BS 7799は、現在はISO/IEC 17799およびISO/IEC 27001となっている。

Budget 予算特定の期間中に組織または事業部門が受け取ること、または支払うことを計画している、すべての金額の一覧。予算業務、計画立案を参照。

Budget (1) - as in the available sum of money

（1）使用可能な金額の合計 ― 予算

　

Budget (2) - as in estimated cost & income

（2）見積もられたコストと収入－予算

　



用語用語定義／備考Budgeting 予算業務金銭の支出を予測しコントロールする活動。将来の予算を設定する周期的交渉サイクル（通常は年

次）と、現在の予算に対する日々のモニタリングと調整で構成される。Budgeting (1) - as in the setting the available sum of money

（1）使用可能な金額の合計を設定すること ― 予算業務

（又は）予算計上

　

Budgeting (2) - as in estimating cost & income

（2）コストと収入を見積もること ― 予算業務

（又は）予算見積もり

　

Bug バグ　Build 構築 (サービストランジション) ITサービスの一部を作成するために、複数の構成アイテムを組み立てる

活動。配布を許可されたリリースを示す場合は、「ビルド」ともいう。例えば、「サーバのビルド」や「ノートPCのビルド」のように使用する。構成ベースラインを参照。

Build Environment 構築環境 (サービストランジション) アプリケーション、ITサービス、およびその他の構築の組み立てを行うコントロールされた環境。この環境の後、テスト環境または稼働環境に移行する。

Business 事業体 (サービスストラテジ) 複数の事業部門から成る、企業体または組織の全体。ITSMにおける事業体という用語には、企業だけでなく、公共部門と非営利組織も含まれる。ITサービス・プロバイダは、事業体内の顧客にITサービスを提供する。このITサービス・プロバイダは、顧客と同じ事業体に属している場合（内部サービス・プロバイダ）や、別の事業体に属している場合（外部サービス・プロバイダ）がある。

Business (1) - as in “company”” （1）企業を意味する場合－事業体

　

Business (2) - as in “customer”” 事業（2）顧客を意味する場合 ― 事業

　

Business (3) - as in “market sector” （3）マーケット部門を意味する場合 ― 事業

　

Business Capacity Management (BCM)

事業キャパシティ管理（BCM）

(サービスデザイン) ITSMにおける事業キャパシティ管理とは、キャパシティ計画で使用する将来の事業要件の把握を責務とする活動を指す。サービス・キャパシティ管理を参照。

Business Case ビジネス・ケース (サービスストラテジ) 主要な支出項目の正当性を説明するもの。コスト、利点、代案、課題、リスク、起こりうる問題などに関する情報を含む。費用便益分析を参照。

Business Continuity Management (BCM)

事業継続性管理（BCM） (サービスデザイン) 事業体に深刻なインパクトを与える可能性のあるリスクの管理を責務とするビジネス・プロセス。BCMは、主要な利害関係者の利益、評判、ブランド、および価値を創造する活動を保護する。BCMプロセスには、リスクを許容可能なレベルまで低減することや、事業体に中断が生じた場合にビジネス・プロセスを回復するための計画立案を行うことが含まれるBCMは、ITサービス継続性管理の達成目標、適用範囲、および要件を設定する。

Business Continuity Plan (BCP) 事業継続性計画（BCP） (サービスデザイン) ビジネス・プロセスの中断後に、そのプロセスを回復するために必要なステップを定義した計画。この計画では、発動の契機、関与する人、コミュニケーションなども特定する。ITサービス継続性計画は、事業継続性計画の重要な部分を占める。

Business Continuity Team 事業継続性チーム（ITサービス継続性管理）事業継続性計画で定義された活動を実行することを責務とする人々で構成されるチーム。

Business Customer 事業顧客 (サービスストラテジ) 事業体からの製品またはサービスの受領者。例えば、事業体が自動車製造業者の場合、自動車を購入する人が事業顧客である。

Business Driver 事業推進要因事業達成目標と事業戦略の定義に影響するもの。例えば、新しい法令や競合他社の行動など。事業推進要因という用語は、事業達成目標または事業戦略の同義語として使用されることがある。

Business environment 事業環境　Business function 事業機能　Business Impact Analysis (BIA) ビジネス・インパクト分析

（BIA）(サービスストラテジ) BIAは、重要事業機能とそれら機能間の依存性を識別する、事業継続性管理の活動である。これらの依存性には、サプライヤ、人材、その他のビジネス・プロセス、ITサービスなどが含まれる場合がある。BIAによって、ITサービスの復旧要件が定義される。これらの要件には、ITサービスごとの目標復旧時間、目標復旧時点、および最低限のサービスレベル目標値が含まれる。

Business IT Alignment (BITA) 事業とITの整合（BITA） ITサービス・プロバイダがどのようにして事業体に価値を付加するのかを把握し、IT戦略、IT計画、およびITサービスが事業の達成目標とビジョンを支援するようにすること。サービス・カルチャを参照。

Business needs ビジネス・ニーズ　Business Objective 事業達成目標 (サービスストラテジ) ビジネス・プロセスの達成目標。または事業体全体としての達成目標。事業達

成目標は事業体のビジョンを支援し、IT戦略の手引きを提供する。これらの達成目標は、ITサービスによって支援されることが多い。

Business Operations 事業運営 (サービスストラテジ) ビジネス・プロセスを日々実行、モニタリング、および管理すること。Business outcome 事業成果、事業の成果　Business Perspective ビジネスの観点 (継続的サービス改善) 事業体の視点からサービス・プロバイダおよびITサービスを理解することと、

サービス・プロバイダの視点から事業体を理解すること。Business Process ビジネス・プロセス事業体が所有し、実施するプロセス。ビジネス・プロセスは、事業顧客に対する製品またはサービス

の提供に貢献する。例えば、小売業者は事業顧客に対するサービス提供を支援する購買プロセスを持つだろう。多くのビジネス・プロセスはITサービスに依存している。

Business process outsourcing (BPO) ビジネス・プロセス・アウトソーシング（BPO）

　

Business recovery objective 事業復旧目標　Business recovery plan 事業復旧計画　Business recovery team 事業復旧チーム　Business Relationship Management 事業関係管理 (サービスストラテジ) 事業体との関係維持を責務とするプロセスまたは機能。事業関係管理では、

通常、次のことを行う。事業マネージャとの人的な関係の管理サービス・ポートフォリオ管理へのインプットの提供ITサービス・プロバイダが顧客のビジネス・ニーズを満たしていることの確認このプロセスは、サービスレベル管理と強いつながりを持つ。

Business Relationship Manager (BRM)

事業関係マネージャ（BRM）

(サービスストラテジ) 顧客との関係維持を責務とする役割。この役割は、サービスレベル・マネージャの役割と兼務されることが多い。アカウント・マネージャを参照。

Business request 事業の要求　Business Requirement 事業要件　Business Service ビジネス・サービスビジネス・プロセスを直接的に支援するITサービス。ITサービス・プロバイダによって内部で使用さ

れ、通常は事業体には見えないITサービスとは対照的である。ビジネス・サービスという用語は、事業部門によって事業顧客に提供されるサービスも指す。例えば、銀行の顧客に対する金融サービスや、小売店の顧客に対する商品の提供など。ビジネス・サービスの提供が成功するかどうかは、多くの場合、1つ以上のITサービスに左右される。

Business Service Management (BSM)

ビジネス・サービス管理（BSM）

(サービスストラテジ) (サービスデザイン) サポートされるビジネス・プロセスと、提供される事業上の価値を考慮する、ITサービスの管理に対するアプローチ。この用語は、事業顧客に提供されるビジネス・サービスの管理も意味する。



用語用語定義／備考Business Unit 事業部門 (サービスストラテジ) 独自の計画、測定基準、収入、およびコストを持つ事業体の一区分。各事業部

門は資産を有し、その資産を使用して、商品およびサービスの形で顧客にとっての価値を創造する。

Business value 事業価値、事業上の価値　

Bypass 回避　Call コール (サービスオペレーション) ユーザがサービスデスクにかける電話。コールによって、インシデントま

たはサービス要求が記録されることもある。Call Centre コールセンタ (サービスオペレーション) 大量の電話の発着信を処理する組織または事業部門。サービスデスク

を参照。

Call Type コール・タイプ (サービスオペレーション) サービスデスクで受信した要求の区分に使用されるカテゴリ。典型的なコール・タイプには、インシデント、サービス要求、および苦情がある。

Capability 能力 (サービスストラテジ) 活動を実行するための、組織、人、プロセス、アプリケーション、構成アイテム、またはITサービスの力。能力は、組織の無形資産である。リソースを参照。

Capability Maturity Model (CMM) 能力成熟度モデル（CMM） (継続的サービス改善) ソフトウェアの能力成熟度モデル（CMMおよびSW-CMMとしても知られている）は、プロセスの成熟度の向上を支援するベストプラクティスの識別に使用されるモデルである。CMMは、カーネギーメロン大学ソフトウェア工学研究所（SEI：Software Engineering Institute）で開発された。SW-CMMは改善され、2000年にCMMI®（Capability Maturity Model Integration：能力成熟度モデル統合版）となった。SEIでは現在、SW-CMMモデル、関連する評価手法、トレーニング資料を維持管理していない。

Capability Maturity Model Integration (CMMI)

能力成熟度モデル統合版（CMMI）

(継続的サービス改善) 能力成熟度モデル統合版（Capability Maturity Model® Integration：CMMI）は、カーネギーメロン大学ソフトウェア工学研究所（SEI）で開発されたプロセス改善のアプローチである。CMMIは、効果的なプロセスに不可欠な要素を組織に提供する。CMMIはプロジェクト、部門、または組織全体にわたるプロセス改善の指導に使用できる。CMMIは、従来分かれている組織機能の統合、プロセス改善の最終目標と優先順位の設定、良質なプロセスに関する手引きの提供、および現在のプロセスを評価するための基準点の提供に役立つ。詳細は、http://www.sei.cmu.edu/cmmi/を参照。CMM、継続的改善、成熟度を参照。

Capability Model for Client Organizations (eSCM-CL)

クライアント組織向け能力モデル（eSCM-CL）

v3.1.24ではeSourcing Capability Model for Client Organizations (eSCM-CL)：クライアント組織のためのeソーシング能力モデル（eSCM-CL）

Capacity キャパシティ (サービスデザイン) 構成アイテムまたはITサービスが、合意済みサービスレベル目標値を満たしながら提供できる最大限のスループット。ディスク・ドライブなど、CIのタイプによっては、キャパシティがサイズや容量を指す場合がある。

Capacity Database (CDB) キャパシティ・データベース（CDB）

　

Capacity Management キャパシティ管理 (サービスデザイン) ITサービスとITインフラストラクチャのキャパシティによって、合意済みサービスレベル目標値が、高い費用対効果でタイムリーに達成されるようにすることを責務とするプロセス。キャパシティ管理では、ITサービスの提供に必要なすべてのリソースと、短期的、中期的、および長期的な事業要件に対する計画を考慮する。

Capacity Management Database (CDB)

キャパシティ管理データベース（CDB）

（キャパシティ管理）キャパシティ管理の支援に必要なすべてのデータを含むデータベース。キャパシティ管理データベースには頻繁に変更されるデータが大量に含まれるため、通常、構成管理データベース（CMDB）とは別に設置される。

Capacity Management Information System (CMIS)

キャパシティ管理情報システム（CMIS）

(サービスデザイン) すべてのキャパシティ管理データの仮想的なリポジトリ。通常は複数の物理的な場所に保存される。サービス・ナレッジ管理システムを参照。

Capacity Plan キャパシティ計画 (サービスデザイン) キャパシティ計画は、ITサービスの提供に必要なリソースの管理に使用される。この計画には、事業体における需要をさまざまに予測したシナリオと、合意済みサービスレベル目標値を達成するための原価計算済みの代案が含まれている。

Capacity Planning キャパシティ計画立案 (サービスデザイン) キャパシティ計画の作成を責務とする、キャパシティ管理内の活動。Capital Cost 資本コスト（財務管理）コンピュータ機器や建物など、財務上の資産となるものの購入にかかるコスト。資産の

価値は、複数の会計期間を通して減価償却される。運用コストを参照。Capital Expenditure (CAPEX) 資本的支出（CAPEX） (サービスストラテジ) コンピュータ機器や建物など、財務上の資産となるものの購入にかかるコス

ト。資産の価値は、複数の会計期間を通して減価償却される。Capital Item 資本アイテム (サービスストラテジ) 合意された一定の財務的価値を上回るため、財務管理の対象となる資産。Capitalization 資本化 (サービスストラテジ) 資産が何も購入されていない場合でも、主要なコストを資本として識別する

こと。これは、コストの影響を複数の会計期間に分散させるために行われる。最も一般的な例として、ソフトウェア開発やソフトウェア・ライセンスの購入がある。

Category カテゴリ何らかの共通点があるもののグループに名前を付けたもの。カテゴリは、類似したもの同士をグループ化するために使用される。例えば、原価費目は類似したタイプのコストをグループ化するために使用される。インシデント・カテゴリは類似したタイプのインシデントを、CIタイプは類似したタイプの構成アイテムをグループ化するために使用される。

Cause / Effect Diagram 特性要因図（問題管理）影響の原因となりうるすべてのもの（例えば問題など）をチームが識別するのを支援する技法。石川馨氏によって考案されたもので、石川ダイアグラムと呼ばれることが多い。この技法のアウトプットは、魚の骨のように見える図になる。

CCTA CCTA 英国政府の一機関「Central Communications and Telecommunications Agency」の略称。ITILの原作者である。現在、この組織は存在していないが、その機能はOffice of Government Commerce（OGC）に引き継がれている。

CCTA Risk Analysis & Management Method (CRAMM).

CCTAリスク分析・管理手法（CRAMM）

CRAMMを参照。

Central Communications and Telecommunication Agency (CCTA)

Central Communications and Telecommunication Agency（CCTA）

CCTAを参照。

Central point of contact 中央窓口　Central Service Desk 中央サービスデスク　Certificate 証明書　Certification 認証標準に対する遵守性を裏付ける証明書を発行すること。認証には、独立した認定団体による正式な

監査が含まれる。認証という用語は、ある人が資格要件を満たしたことを証明する証明書の発行を意味する場合もある。

Certification 認証　Certification Authority (CA) 認証機関（CA）　Certify 認証する　Change 変更

(自然発生的な場合）変化(サービストランジション) ITサービスに影響を及ぼす可能性のあるものを、追加、修正、または削除すること。適用範囲には、すべてのITサービス、構成アイテム、プロセス、文書などが含まれているべきである。

Change Advisory Board (CAB) 変更諮問委員会（CAB） (サービストランジション) 変更のアセスメント、優先順位付け、およびスケジューリングにおいて変更マネージャに助言を与える人々のグループ。この委員会は、通常、ITサービス・プロバイダ、事業体、サードパーティ（サプライヤなど）のすべての領域の代表者で構成される。

Change Advisory Board / Emergency Committee (CAB/EC)

変更諮問委員会／緊急会議（CAB／EC）

（変更管理）変更諮問委員会の一部。緊急の変更について意思決定を行う。CAB／ECの委員は、会議召集時に決定される場合がある。またこの委員は、緊急の変更の性質によって異なる。

Change authority 変更許可委員　



用語用語定義／備考Change Case 変更ケース (サービスオペレーション) 提案された変更のインパクトを予測するために使用する技法。変更ケー

スでは、提案された変更の適用範囲を明確にし、費用便益分析を支援するために、特定のシナリオを使用する。ユース・ケースを参照。

Change History 変更履歴 (サービストランジション) 構成アイテムのライフサイクルの間に、そのCIに対して行われたすべての変更に関する情報。変更履歴は、そのCIに該当するすべての変更レコードで構成される。

Change log 変更ログ　Change Management 変更管理 (サービストランジション) すべての変更のライフサイクルをコントロールすることを責務とするプロ

セス。変更管理の主な達成目標は、ITサービスの中断を最小限に抑えながら、有益な変更を実施できるようにすることである。

Change manager 変更マネージャ　

Change Model 変更モデル (サービストランジション) 繰り返し利用できる、特定のカテゴリの変更に対する処理方法。変更モデルでは、そのカテゴリに対する変更の際に従う特定のステップを事前定義する。変更モデルは、承認を必要としない極めて単純なもの（パスワードの再設定など）になる場合や、承認が必要な多くのステップを伴う非常に複雑なもの（主要なソフトウェアのリリースなど）になる場合がある。標準的な変更、変更諮問委員会を参照。

Change Record 変更レコード (サービストランジション) 変更の詳細を含むレコード。各変更レコードには、単一の変更のライフサイクルが記録される。変更レコードは、受け付けた変更要求ごとに作成される。変更要求が受付後に却下されたとしても、その変更レコードは作成される。変更レコードは、該当する変更の影響を受ける構成アイテムに対する参照を含むべきである。変更レコードは、構成管理システムに保存される。

Change Request 変更の要求変更要求の同義語。Change Schedule 変更スケジュール (サービストランジション) 承認済みのすべての変更と、その予定実施日を示す文書。変更スケジュ

ールは、将来的な変更スケジュールと呼ばれることもあるが、すでに実施された変更に関する情報も含んでいる。

Change Window 変更時間帯 (サービストランジション) サービスに対するインパクトを最小限に抑えて変更またはリリースを実施できる、合意済みの規定時間。変更時間帯は、通常、SLAに記載される。

Chargeable Item 課金可能アイテム顧客に課金する料金の計算に使用するITサービスの成果物。例えば、トランザクションの数やデスクトップPCの台数など。

Chargeable unit 課金可能な単位 V3書籍内になしCharging 課金 (サービスストラテジ) ITサービスに対する支払いを請求すること。ITサービスの課金は任意であり、

多くの組織では、その組織のITサービス・プロバイダをコスト・センタとして扱っている。

Charging Policy 課金方針（財務管理）課金プロセスの達成目標および料金の計算方法を指定した方針。コスト、コストプラス、現行料金、市場価格を参照。

Charging Process 課金プロセス（財務管理）顧客が支払う金額の決定（価格設定）と、顧客からの料金の回収（請求処理）を責務とするプロセス。

Chief Sourcing Officer (CSO) 最高ソーシング責任者（CSO）

SS

Chief Technical Officer (CTO) 最高技術責任者（CTO） SOChronological Analysis 時系列分析 (サービスオペレーション) 問題に関して考えられる原因の特定を支援するために使用する技法。

問題に関して入手可能なすべてのデータを収集し、日付と時間ごとに並べ替え、詳細な時系列を作成する。これによって、どのイベントが他のイベントを引き起こした可能性があるかを識別できるようになる。

CI Type CIタイプ (サービストランジション) CIの分類に使用されるカテゴリ。CIタイプによって、構成レコードに必要な属性と関係が特定される。典型的なCIタイプは、ハードウェア、文書、ユーザなどである。

Clarity 明確さ　Classification 分類カテゴリを何かに割り当てる作業。分類は、一貫した管理と報告が行われるようにするために使用

される。通常、CI、インシデント、問題、変更などが分類される。 Clean desk クリーン・デスク　Client クライアント顧客、事業体、または事業顧客を指す総称。例えば、クライアント・マネージャはアカウント・マネー

ジャの同義語として使用されることがある。クライアントという用語は、次のものも意味する。ユーザが直接使用するコンピュータ。例えば、PC、ハンドヘルド・コンピュータ、ワークステーションなどクライアント・サーバ・アプリケーションの、ユーザと直接やりとりする部分。例えば、電子メール・クライアントなど。

Client Access Licence クライアント・アクセス・ライセンス

クライアントがサーバ上のリソースを使用することを許可するソフトウェア・ライセンス。

Closed クローズ済み (サービスオペレーション) インシデント、問題、変更などのライフサイクルの最終ステータス。ステータスがクローズ済みになっている場合、それ以上の処置は行われない。

Closure クローズ (サービスオペレーション) インシデント、問題、変更などのステータスをクローズ済みに変更する作業。

Closure Code クローズ・コードインシデントや問題をクローズする前に、それらに割り当てられるカテゴリ。このコードは原因を識別し、報告や傾向分析で使用するためのものである。例えば、「顧客トレーニングが必要」、「文書の不備」、「ソフトウェアのバグ」など。

COBIT COBIT (継続的サービス改善) Control Objectives for Information and related Technology（COBIT）は、ITプロセスの管理に対する手引きとベストプラクティスを提供する。COBITはITガバナンス協会によって発行されている。詳細は、http://www.isaca.org/を参照。

Code of Practice 実践のための規範（COP）公共団体または標準化組織（ISOやBSIなど）によって発行される指針。多くの標準は、実践のための規範と仕様で構成されている。実践のための規範では、推奨するベストプラクティスについて説明している。

Cold Standby コールド・スタンバイ段階的復旧の同義語。Command, control and communications

指揮、統制、伝達組織が指示や情報を効果的に提供することを可能にするプロセスおよびインフラストラクチャ。これによって、リソースの管理統制が可能になる。この用語は、通常、重大なインシデント、事業継続性、およびITサービス継続性の管理において使用される。

Commercial off the Shelf (COTS) 既製品（COTS） (サービスデザイン) サードパーティから購入可能なアプリケーション・ソフトウェアまたはミドルウェア。

Communication facility 通信設備 V3書籍内になしCompatibility 互換性　Completeness 完全性　Complexity 複雑性　Compliance コンプライアンス標準または一連の指針に従っているようにすること。または、適切で一貫した会計業務やその他の

プラクティスが用いられているようにすること。Compliance costs コンプライアンス・コスト　Component コンポーネント

(論理的なものの場合）要素

より複雑なものの一部を指す総称。例えば、コンピュータ・システムはITサービスのコンポーネント、アプリケーションはリリース・ユニットのコンポーネントとなる場合がある。管理する必要のあるコンポーネントは、構成アイテムである。

Component Capacity Management (CCM)

コンポーネント・キャパシティ管理（CCM）

(サービスデザイン) (継続的サービス改善) 構成アイテムのキャパシティ、使用率、およびパフォーマンスを把握することを責務とするプロセス。キャパシティ計画に使用するために、データを収集、記録、および分析する。サービス・キャパシティ管理を参照。



用語用語定義／備考

Component CI コンポーネントCI (サービストランジション) アセンブリの一部となる構成アイテム。例えば、CPU CIやメモリCIは、サーバCIの一部となる場合がある。

Component Failure Impact Analysis (CFIA)

コンポーネント障害インパクト分析（CFIA）

(サービスデザイン) CIの障害がITサービスに及ぼすインパクトの識別に役立つ技法。ITサービスを一方の軸にとり、CIを他方の軸にとる表を作成する。この表から、重要なCI（複数のITサービスに障害を発生させる可能性のあるもの）と、脆弱なITサービス（単一障害点が複数あるもの）を識別できる。

Compromise (1) - as in settlement of differences in intermediate solution

（1）相違に対して中間策で手を打つこと ― 妥協

　

Compromise (2) - as in expose to suspicion, discredit

（2）疑念や不信の対象となること ― 信用を落とす

　

Computer Aided Systems Engineering (CASE)

コンピュータ支援システム・エンジニアリング

（CASE）

　

Computer Telephony Integration (CTI)

コンピュータ電話統合（CTI）

(サービスオペレーション) コンピュータと電話システム間の何らかの統合を表す総称。最も一般的には、アプリケーションによって、電話の発着信に関する詳細な画面が表示されるシステムを指す。自動着信呼分配、音声自動応答を参照。

Concurrency 並行性同時に同じ作業を行うユーザ数の指標。Concurrent 同時　Confidentiality 機密性 (サービスデザイン) セキュリティ原則の1つ。許可された人だけがデータにアクセスするよう求め

る。

Confidentiality, Integrity and Availability (CIA)

機密性、完全性、可用性（CIA）

　

Configuration 構成 (サービストランジション) 連携してITサービスを提供する構成アイテムのグループ、またはITサービスの識別可能な一部分を指す総称。構成は、1つ以上のCIのパラメータ設定を指すこともある。

Configuration and Change Management (C&CM)

構成と変更の管理（C&CM）構成管理、変更管理、リリース管理の計画立案、導入、運用を統合したアプローチ。

Configuration Baseline 構成ベースライン (サービストランジション) 正式に合意済みで、変更管理プロセスを通して管理される構成のベースライン。構成ベースラインは、将来の構成、リリース、および変更のベースとして使用する。

Configuration Control 構成コントロール (サービストランジション) 変更要求やサービス要求の提出などにより、CIの追加、修正、または削除が適切に管理されるようにすることを責務とする活動。

Configuration Identification 構成識別 (サービストランジション) 構成アイテムおよびそれらの関係に関する情報を収集し、その情報をCMDBに取り込むことを責務とする活動。構成識別は、対応する構成レコードが分かるようにCI自体にラベル付けすることも責務とする。

Configuration Item (CI) 構成アイテム（CI） (サービストランジション) ITサービスの提供のために管理する必要がある、あらゆるコンポーネント。各CIに関する情報は、構成管理によって構成管理システム内の構成レコードに記録され、そのライフサイクルを通して維持される。CIは変更管理によってコントロールされる。一般にCIには、ITサービス、ハードウェア、ソフトウェア、建物、人材、およびプロセス文書やSLAなどの正式文書が含まれる。

Configuration Management 構成管理 (サービストランジション) ITサービスの提供に必要な構成アイテムに関する情報を、それらの関係に関する情報も含めて維持することを責務とするプロセス。この情報は、CIのライフサイクルを通して維持される。構成管理は、総合的なサービス資産管理および構成管理プロセスの一部である。

Configuration Management Database (CMDB)

構成管理データベース（CMDB）

(サービストランジション) 構成レコードのライフサイクルを通した保管に使用するデータベース。構成管理システムでは1つ以上のCMDBを維持し、各CMDBにはCIの属性および他のCIとの関係を保存する。

Configuration Management System (CMS)

構成管理システム（CMS） (サービストランジション) ITサービス・プロバイダの構成データの管理に使用される、一連のツールまたはデータベース。CMSには、インシデント、問題、既知のエラー、変更、リリースに関する情報も含まれる。また、従業員、サプライヤ、場所、事業部門、顧客、ユーザに関するデータも含まれる場合もある。CMSには、すべての構成アイテムおよびそれらの関係に関するデータを収集、保管、管理、更新、提示するためのツールも含まれる。CMSは、構成管理によって維持され、すべてのITサービスマネジメント・プロセスに使用される。構成管理データベース、サービス・ナレッジ管理システムを参照。

Configuration manager 構成マネージャ　Configuration Record 構成レコード (サービストランジション) 構成アイテムの詳細を含むレコード。各構成レコードには、単一のCIのラ

イフサイクルが記録される。構成レコードは、構成管理データベースに保存される。

Configuration Status Accounting 構成ステータスの説明（構成管理）各構成アイテムのライフサイクルを記録および報告することを責務とする活動。 Configuration Structure 構成構造 (サービストランジション) 構成を形成するすべての構成アイテム間の階層およびその他の関係。

Configuration Verification and Audit 構成の検証と監査（構成管理）CMDB内の情報が正確であり、すべての構成アイテムが識別され、CMDBに記録されているようにすることを責務とする活動。構成検証には、他のプロセスの一部として行われる日常点検が含まれる。例えば、ユーザがインシデントを記録する際に、デスクトップPCの製造番号を照合することなどである。構成監査は、正式な定期点検である。

Configure 構成する、設定する　Connectivity 接続性、接続　継続的サービス改善 (CSI) 継続的サービス改善（CSI） (継続的サービス改善) ITサービスのライフサイクルにおける段階の1つ。ITILコア書籍の1つのタイ

トルでもある。継続的サービス改善は、ITサービスマネジメント・プロセスとITサービスに対する改善の管理を責務とするプロセスである。効率性、有効性、および費用対効果を向上するために、ITサービス・プロバイダのパフォーマンスは継続的に測定され、プロセス、ITサービス、ITインフラストラクチャに改善が加えられる。計画・実施・点検・処置を参照。

継続的サービス改善 Model 継続的サービス改善モデル

　

継続的サービス改善 Programme (CSIP)

継続的サービス改善プログラム（CSIP）

V3.1.24の頭字語のみ。説明はなし

Continuity 継続性　Continuity manager 継続性マネージャ　Continuous Availability 継続的可用性 (サービスデザイン) 100%の可用性を達成するためのアプローチまたは設計。継続的可用性のある

ITサービスには、計画休止時間も計画外休止時間もない。Continuous Improvement 継続的改善 ITサービスマネジメント・プロセスとITサービスに対する改善の管理を責務とするプロセス。継続的

改善では、継続的に成果を測定し、プロセスとITインフラストラクチャを修正して、効率性、有効性、および費用対効果を改善する。CSIP、SIP、デミング・サイクル、最適化を参照。

Continuous Operation 継続的運用 (サービスデザイン) ITサービスの計画休止時間を排除するアプローチまたは設計。ITサービスが使用可能でも、個々の構成アイテムはダウンしている場合があることに注意すること。

Continuous Service Improvement Programme (CSIP)

継続的サービス改善プログラム（CSIP）

継続的改善プロセスを導入して管理する、正式なプログラム。

Contract 契約複数の当事者間における、法的な拘束力のある合意。



用語用語定義／備考Contract Manager 契約マネージャ（サプライヤ管理）1社または複数のサプライヤとの契約を管理することを責務とする役割。契約マ

ネージャは、通常、サービスレベル・マネージャと緊密に連携し、ITサービスの合意済みサービスレベル目標値がサプライヤ契約で支持されるようにする。

Contract Portfolio 契約ポートフォリオ (サービスストラテジ) ITサービス・プロバイダとその顧客との間のサービス契約または合意の管理に使用するデータベースまたは構造化された文書。顧客に提供される各ITサービスには契約またはその他の合意があるべきであり、これらは契約ポートフォリオに記載される。サービス・ポートフォリオ、サービス・カタログを参照。

Control コントロールリスクを管理する手段であり、事業達成目標を確実に実現する手段、またはプロセスに確実に従っているようにする手段。コントロールの例には、方針、手順、役割、RAID、ドアの施錠などがある。コントロールは、対策または保護手段と呼ばれることがある。コントロールは、構成アイテム、システム、またはITサービスの利用や動作を管理することも指す。

Control Objectives for Information and related Technology (COBIT)

Control Objectives for Information and related Technology（COBIT）

COBITを参照。

Control perspective コントロールの観点 (サービスストラテジ) ITサービス、プロセス、機能、資産などの管理に対するアプローチ。同じITサービス、プロセスなどに対して複数の異なるコントロールの観点を持つことができる。このため、異なる個人やチームが、その特定の役割にとって重要かつ適切なものに集中することができる。コントロールの観点の例には、IT運用内のリアクティブおよびプロアクティブな管理、アプリケーション・プロジェクト・チームに対するライフサイクルの視点などがある。

Control Processes コントロール・プロセス変更管理と構成管理を含む、ISO/IEC 20000のプロセス・グループ。Control, a コントロール　Control, to コントロールする　Controllability コントロール性　Core Service コアサービス (サービスストラテジ) 顧客に望まれる基本的な成果を実現するITサービス。補助サービス、コアサ

ービス・パッケージを参照。Core Service Package (CSP) コアサービス・パッケージ

（CSP）(サービスストラテジ) コアサービスの詳細な説明。複数のサービスレベル・パッケージで共有する場合もある。サービス・パッケージを参照。

Correctability 是正可能性 V3書籍内になしCorrective maintenance 修正保守 V3書籍内になしCorrective measures 是正対策、是正措置　Cost コスト特定の活動、ITサービス、または事業部門に費やされた金銭の額。コストは、実質的なコスト（金銭）

、工数などの概念上のコスト、および減価償却で構成される。Cost Benefit Analysis 費用便益分析 1つ以上の代替措置におけるコストと便益を分析および比較する活動。ビジネス･ケース、正味現在

価値、内部収益率、投資収益率、投資価値を参照。Cost Centre コスト・センタ (サービスストラテジ) コストを帰属させる事業部門またはプロジェクト。コスト・センタは、提供した

サービスに対して課金しない。ITサービス・プロバイダは、コスト・センタとしても、プロフィット・センタとしても運営できる。

Cost Effectiveness 費用対効果サービス、プロセス、または活動の有効性とコストのバランスの指標。費用対効果の良いプロセスとは、その達成目標を最小限のコストで達成するプロセスである。KPI、投資収益率、金額に見合う価値を参照。

Cost Element 原価要素 (サービスストラテジ) 予算業務と会計業務において、コストを割り当てる中間レベルのカテゴリ。最上位のカテゴリは原価費目である。例えば、「人材」という原価費目には、給与、福利厚生、経費、トレーニング、残業代などの原価要素がある。原価要素はさらに、原価単位に細分化できる。例えば、「経費」という原価要素には、ホテル代、交通費、食費などの原価単位を含めることができる。

Cost Management コスト管理 (サービスストラテジ) 予算業務と会計業務を指す総称。財務管理の同義語として使用される場合もある。

Cost Model コスト・モデル（財務管理）予算業務と会計業務で使用される枠組み。この枠組み内では、すべての既知のコストが記録され、分類されて、特定の顧客、事業部門、またはプロジェクトに割り当てられる。顧客毎コストとサービス毎コストは、典型的なコスト・モデルの種類である。原価費目、原価要素、原価単位を参照。

Cost of Service サービスのコスト　Cost Plus コスト・プラス（財務管理）課金方針の1つ。ITサービスの提供コストに一定の割合を加算して料金を計算する。加

算した料金は、将来の投資に使用されることが多い。Cost Type 原価費目 (サービスストラテジ) 予算業務と会計業務において、コストを割り当てる最上位のカテゴリ。例え

ば、ハードウェア、ソフトウェア、人材、施設、外部、振替など。原価要素、原価費目を参照。

Cost Unit 原価単位 (サービスストラテジ) コストを割り当てる最低位のカテゴリ。原価単位は、通常、容易に数えることができるもの（従業員数、ソフトウェア・ライセンス数など）か、容易に測定できるもの（CPU使用率、電力消費量など）である。原価単位は、原価要素に包含される。例えば、「経費」という原価要素には、ホテル代、交通費、食費などの原価単位を含めることができる。原価費目を参照。

Cost-by-Customer Cost Model 顧客毎コスト・モデル（財務管理）コスト・モデルの種類の1つ。顧客ごとにコストを識別し、割り当てる。 Cost-by-Service Cost Model サービス毎コスト・モデル（財務管理）コスト・モデルの種類の1つ。ITサービスごとにコストを識別し、割り当てる。Costing 原価計算　Countermeasure 対策あらゆるタイプのコントロールを指して用いる場合がある。対策という用語は、ITサービスの対障害

弾力性、耐障害性、または信頼性を向上させる対策を指すことが最も多い。

Course Corrections 軌道修正すでに開始している計画または活動が達成目標を実現するようにするために行う変更。軌道修正は、モニタリングの結果として行われる。

Cracker クラッカー V3書籍内になしCRAMM CRAMM リスクを分析および管理する方法論および手段。CRAMMは英国政府によって開発され、現在は民

間に移管されている。詳細は、http://www.cramm.com/を参照。Crisis Management 危機管理事業継続性のより広範な影響を管理することを責務とするプロセス。危機管理チームは、メディア

との関係や株主の信用の管理、事業継続性計画の発動時期の決定など、戦略的な課題の対応を責務とする。

Critical Success Factor (CSF) 重要成功要因（CSF）プロセス、プロジェクト、計画、またはITサービスを成功させるために必須のもの。各CSFの達成の測定には、KPIが使用される。例えば、「変更の実施時にITサービスを保護する」というCSFは、「失敗した変更の割合の減少」、「インシデントの原因となる変更の割合の減少」などのKPIを用いて測定できる。

Cryptanalysis 暗号解読 V3書籍内になしCryptography 暗号 V3書籍内になしCSI policies CSI方針　Culture カルチャ人々の集団で共有される一連の価値感。人々の振る舞いに対する期待、考え、信念、プラクティスな

どが含まれる。ビジョンを参照。Customer 顧客商品やサービスを購入する人。ITサービス・プロバイダの顧客は、サービスレベル目標値を定義し、

それに合意する人またはグループである。顧客という用語は、非公式にはユーザの意味で使用されることがある。例えば、「これは顧客フォーカスの組織だ」など。



用語用語定義／備考Customer assets 顧客資産　Customer Based SLAs 顧客ベースのSLA 　Customer Focus 顧客フォーカス顧客とユーザの実際のニーズを把握し、満たすこと。顧客満足を最大にし、それによってITサービス・

プロバイダが長期的な利益を得るために行われる。顧客フォーカスは、組織全体（サービス・カルチャを参照）、または特定の人やプロセスごとに表明できる。

Customer needs 顧客ニーズ、顧客のニーズ　Customer outcome 顧客成果、顧客の成果　

Customer Portfolio 顧客ポートフォリオ (サービスデザイン) ITサービス・プロバイダのすべての顧客を記録するために使用するデータベースまたは構造化された文書。顧客ポートフォリオは、ITサービス・プロバイダからサービスを受ける顧客に対する事業関係マネージャの視点となる。契約ポートフォリオ、サービス・ポートフォリオを参照。

Customer Relationship Management (CRM)

顧客関係管理（CRM）　

Customer Satisfaction Survey (CSS) 顧客満足度調査（CSS）　Customer-Managed Use 顧客管理下の使用（ソフトウェア資産管理）顧客またはITサービス・プロバイダがライセンスを管理すること。ライセン

スは、ソフトウェアのサプライヤによって管理される場合もある（ベンダ管理下の使用）。

Customers 顧客　Dashboard ダッシュボード (サービスオペレーション) ITサービスの全体的なパフォーマンスと可用性を視覚的に表現したも

の。ダッシュボード画像はリアルタイムに更新でき、管理レポートやウェブ・ページを含む場合もある。ダッシュボードは、サービスレベル管理、イベント管理、またはインシデント診断を支援するために使用できる。

Data データ　Data Administration データ管理作業、デー

タ管理V3書籍内に「data management=データ管理」もあるので区別する必要がある

Data center データセンタ　Data collection データ収集　Data infrastructure データ基盤 V3書籍内になしData lifecycle データ・ライフサイクル、デ

ータのライフサイクル　

Data mining データ・マイニング　Data warehouse データ・ウェアハウス　Database データベース ITサービスマネジメントにおけるデータベースは、構造化された一群のデータから成り、1つまたは

複数のプロセスのサポートに使用される。この種のデータベースは、単一の物理データベースである必要はなく、連携して要件を満たすさまざまなデータ・ソースとツールで構成することもできる。例えば、構成管理データベース、キャパシティ・データベース、可用性データベース、アプリケーション・ポートフォリオなど。

Data-to-Information-to-Knowledge-to-Wisdom (DIKW)

データ・情報・ナレッジ・知恵（DIKW）

データ、情報、ナレッジ、知恵の間の関係を理解する方法の1つ。DIKWは、データ、情報、ナレッジ、知恵がそれぞれ互いに依存している様子を表す。

Decryption 暗号解読 V3書籍内になしDefinitive Hardware Store (DHS) 確定版ハードウェアの保管

庫（DHS）（リリース管理）使用していないハードウェア構成アイテムを安全に保管する、1つまたは複数の物

理的な場所。DHS内のすべてのハードウェアは、変更管理とリリース管理によってコントロールされ、CMDBに記録される。DHSには、適切なリビジョン・レベルに維持されている予備部品が保管される。また、将来のリリースの一部になるハードウェアが保管される場合もある。

Definitive Media Library (DML) 確定版メディア・ライブラリ（DML）

(サービストランジション) すべてのソフトウェア構成アイテムの、承認済みの確定版バージョンを安全に保存する1つまたは複数の場所。DMLには、ライセンスや文書などの関連するCIが保存される場合もある。複数の場所に分散している場合でも、DMLは論理的には単一の保存領域である。DML内のすべてのソフトウェアは、変更管理とリリース管理によってコントロールされ、構成管理システムに記録される。リリース用に許可できるのは、DMLからのソフトウェアだけである。

Definitive Software Library (DSL) 確定版ソフトウェアの保管庫（DSL）

（リリース管理）すべてのソフトウェア構成アイテムの、承認済みの確定版バージョンを安全に保管する1つまたは複数の場所。DSLには、ライセンスや文書などの関連するCIが保管される場合もある。複数の場所に分散している場合でも、DSLは論理的には単一の保存領域である。DHL内のすべてのソフトウェアは、変更管理とリリース管理によってコントロールされ、CMDBに記録される。リリース用に許可できるのは、DSLからのソフトウェアだけである。

Definitive spares 確定版予備品　Degradability 低下の可能性 V3書籍内になしDegradation 低下　Deliverable 成果物サービスレベル・アグリーメントまたは契約内の義務を果たすために、提供されなければならない

もの。成果物は、非公式には、あらゆるプロセスの予定されたアウトプットを指すこともある。

Delta Release デルタ・リリース（リリース管理）前回のリリース以降に実際に変更されたリリース・ユニットのコンポーネントだけを含むリリース。デルタ・リリースは、部分的リリースと呼ばれる場合もある。リリース・タイプを参照。

Demand Management 需要管理サービスに対する顧客の需要、およびそれらの需要に対応するためのキャパシティの準備について把握し影響を及ぼす活動。戦略レベルでは、需要管理には事業活動パターンとユーザ・プロファイルの分析が含まれる場合がある。戦術レベルでは、利用の少ない時間帯にITサービスを使用するよう顧客に促すために、格差課金を使用することもある。キャパシティ管理を参照。

Demand modelling 需要モデル化　Deming Cycle デミング・サイクル計画・実施・点検・処置の同義語。Dependency 依存関係、依存性プロセスまたは活動が、他のプロセスまたは活動に、直接的または間接的に依存すること。Deployment 展開 (サービストランジション) 新規または変更されたハードウェア、ソフトウェア、文書、プロセスなどを

稼働環境へ移行することを責務とする活動。展開は、リリース管理および展開管理プロセスの一部である。投入を参照。

Deployment package 展開パッケージ　Depreciation 減価償却 (サービスストラテジ) 資産の価値を、使用期間全体にわたって減少させる際の指標。これは、経年劣

化、消耗、その他の経済的価値の低下などに基づく。Design 設計 (サービスデザイン) 要件を識別し、それらの要件を満たすことができる解決策を定義する活動また

はプロセス。サービスデザインを参照。Detection 検出 (サービスオペレーション) インシデントのライフサイクルにおける段階の1つ。検出によって、インシ

デントがサービス・プロバイダの知るところとなる。検出は自動で実行できるが、ユーザがインシデントを記録したことによって起こることもある。

Detection time 検出時間　Development 開発 (サービスデザイン) ITサービスやアプリケーションの作成または修正を責務とするプロセス。開発

作業を行う役割またはグループを指す場合もある。Development Environment 開発環境 (サービスデザイン) ITサービスやアプリケーションの作成または修正に使用される環境。開発環境

は、通常、テスト環境や稼働環境と同程度のコントロールの対象にはならない。開発を参照。



用語用語定義／備考Diagnosis 診断 (サービスオペレーション) インシデントおよび問題のライフサイクルにおける段階の1つ。診断の目

的は、インシデントのワークアラウンドや問題の根本原因を識別することである。

Diagnostic Script 診断マニュアル (サービスオペレーション) サービスデスクのスタッフが使用する体系的な一連の質問集。スタッフが的確な質問をできるようにし、インシデントの分類、解決、割り当てに役立つ。診断マニュアルは、ユーザが自らインシデントを診断し、解決するために使用する場合もある。

Differential Charging 格差課金需要管理を支援するために使用される技法の1つ。時間帯に応じて、同じITサービス機能に対して異なる金額を課金する。

Digital signature デジタル署名 V3書籍内になしDirect Cost 直接費 (サービスストラテジ) 特定の顧客、コスト・センタ、プロジェクトなどにすべてを割り当てることがで

きる、ITサービス提供のコスト。例えば、共有していないサーバやソフトウェア・ライセンスの提供コストなど。間接費を参照。

Directory Service ディレクトリ・サービス (サービスオペレーション) ネットワーク上で利用可能なITインフラストラクチャ、および対応するユーザのアクセス権限に関する情報を管理するアプリケーション。

Disaster 災害　Disaster recovery 災害復旧　Disaster recovery management 災害復旧管理 V3書籍内になしDistributed computing 分散コンピューティング V3書籍内になしDistributed system 分散システム　Do Nothing 何もしない (サービスデザイン) 復旧オプションの1つ。サービス・プロバイダは、対象のITサービスの復旧を実

施しないことを、顧客と正式に合意する。 Document 文書

（動詞の場合）文書化する読むことができる形式の情報。紙または電子形式の場合がある。例えば、方針記述書、サービスレベル・アグリーメント、インシデント・レコード、コンピュータ室のレイアウト図など。レコードを参照。

Domain 領域、ドメイン　Dormant Contract 休眠契約（ITサービス継続性）復旧オプションの1つ。サービス・プロバイダが、合意済みの期間に合意済み

の価格で必要な製品またはサービスを提供するために、サプライヤと契約を締結する。この契約は復旧計画の一部として履行され、その時点で追加料金が支払われ、商品またはサービスが提供される。

Downsizing ダウンサイジング V3書籍内になしDowntime 休止時間 (サービスデザイン) (サービスオペレーション) 合意済みサービス時間内に、構成アイテムまたはIT

サービスが使用可能ではない時間。ITサービスの可用性は、合意済みサービス時間と休止時間から計算されることが多い。

Driver 推進要因戦略、達成目標、または要件に影響するもの。例えば、新しい法令や競合他社の行動など。Early Life Support 初期サポート (サービストランジション) 新規または変更されたITサービスがリリースされた後、それらに対して一

定期間提供されるサポート。初期サポートの間、ITサービス・プロバイダはKPI、サービスレベル、およびモニタリングしきい値をレビューし、インシデント管理と問題管理のために追加のリソースを提供する場合がある。

Economies of scale 規模の経済 (サービスストラテジ) ITサービスや資産の使用量を増やすことによって可能となる、平均コストの削減。範囲の経済を参照。

Economies of scope 範囲の経済 (サービスストラテジ) 追加された目的のために既存の資産を使用することで、任意のITサービスに割り当てられたコストを削減すること。例えば、既存のITインフラストラクチャで新しいITサービスを提供すること。規模の経済を参照。

Effectiveness 有効性 (継続的サービス改善) プロセス、サービス、または活動の達成目標が実現されているかどうかの指標。効果的なプロセスまたは活動とは、その合意済み達成目標を実現するプロセスまたは活動である。KPIを参照。

Efficiency 効率性 (継続的サービス改善) プロセス、サービス、または活動の提供に適切な量のリソースが使用されているかどうかの指標。効率的なプロセスは、最小限の時間、資金、人材、またはその他のリソースで、その達成目標を実現する。KPIを参照。

Elapsed time 経過時間　Elements of cost 原価要素 v3書籍および用語集では「Cost Element」になっている。Emergency Change 緊急の変更、緊急変更 (サービストランジション) 可能なかぎり迅速に導入しなければならない変更。例えば、重大なイン

シデントの解決のための変更や、セキュリティ・パッチを実装するための変更など。通常、変更管理プロセスには、緊急の変更を処理するための明確な手順がある。緊急変更諮問委員会（ECAB）を参照。

Emergency Change Advisory Board (ECAB)

緊急変更諮問委員会（ECAB）

(サービストランジション) 変更諮問委員会の一部。インパクトの大きい緊急の変更について意思決定を行う。ECABの委員は、会議召集時に決定される場合がある。またこの委員は、緊急の変更の性質によって異なる。

Emergency Fix 緊急修正　Emergency Release 緊急リリース　Encipher 暗号化する V3書籍内になしEncryption 暗号化　End User エンド・ユーザ　Enterprise Application Integration (EAI)

エンタープライズ・アプリケーション統合（EAI）

　

Enterprise architecture エンタープライズ・アーキテクチャ、企業のアーキテクチャ

　

Enterprise Services Architecture (ESA)

エンタープライズ・サービス・アーキテクチャ（ESA）

　

Environment 環境 (サービストランジション) 特定の目的に使用される、ITインフラストラクチャの一部。例えば、稼働環境、テスト環境、構築環境など。複数の環境で構成アイテムを共有できる。例えば、テスト環境と稼働環境に、1台のメインフレーム・コンピュータ上の別々のパーティションを利用することができる。また、物理環境という用語の中では、施設、空調、電力系統などの意味にも使用される。環境は、何かに影響を及ぼす外的条件を指す総称としても使用される。

Error エラー (サービスオペレーション) 1つまたは複数の構成アイテムやITサービスの障害の原因となる、設計上の欠陥または不具合。CIやITサービスにインパクトを与える人的なミスや欠陥のあるプロセスも、エラーである。

Error Control エラー･コントロール（問題管理）変更の実施成功によって解決されるまで、既知のエラーを管理することを責務とする活動。問題コントロールを参照。

Escalation エスカレーション (サービスオペレーション) サービスレベル目標値や顧客の期待を満たすために必要なときに、追加のリソースを入手する活動。エスカレーションは、あらゆるITサービスマネジメント・プロセス内で必要になる場合があるが、最も一般的にはインシデント管理、問題管理、および顧客の苦情の管理に関連している。エスカレーションには、機能的エスカレーションと階層的エスカレーションの2つのタイプがある。

Escalation threshold エスカレーションのしきい値

V3書籍内になし

eSourcing Capability Model for Client Organizations (eSCM-CL)

クライアント組織向けeソーシング能力モデル

（eSCM-CL）

(サービスストラテジ) 組織によるサービス・ソーシング・モデルおよび戦略に関する分析および意思決定を手引きするフレームワーク。eSCM-CLはカーネギーメロン大学で開発された。eSCM-SPを参照。



用語用語定義／備考eSourcing Capability Model for Service Providers (eSCM-SP)

サービス・プロバイダ向けeソーシング能力モデル

（eSCM-SP）

(サービスストラテジ) ITサービス・プロバイダが、サービス・ソーシングの観点からITサービスマネジメント能力を開発することを支援するフレームワーク。eSCM-SPはカーネギーメロン大学で開発された。eSCM-CLを参照。

Estimation 見積もり経験から、測定基準またはコストの概略値を出すこと。見積もりは、キャパシティ管理および可用性管理における、最も安価で最も正確性の低いモデル化手法としても使用される。

European Foundation for Quality Management (EFQM)

欧州品質管理財団（EFQM） EFQM Excellence Modelは、欧州経営品質賞の対象の組織を評価する枠組みとして1992年初頭に導入された。現在は、欧州で最も広範に普及した組織の枠組みであり、国内や地域の品質に関する賞の大半に対する基礎となっている。詳細は、http://www.efqm.org/を参照。

Evaluation 評価 (サービストランジション) リスクが管理されていることを確認し、変更を進めるかどうかの決定を支援するために、新規または変更されたITサービスをアセスメントすることを責務とするプロセス。評価は、実際の成果を意図された成果と比較すること、またはある選択肢を別の選択肢と比較することも指す。

Event イベント (サービスオペレーション) 構成アイテムやITサービスの管理にとって重要性のある状態の変更。イベントという用語は、あらゆるITサービス、構成アイテム、またはモニタリング・ツールで生成されるアラートまたは通知も指す。イベントは、通常、IT運用の要員に処置を行うよう要請し、結果としてインシデントが記録されることが多い。

Event Management イベント管理 (サービスオペレーション) イベントのライフサイクルを通した管理を責務とするプロセス。イベント管理は、IT運用の主要な活動の1つである。

Examination Board 試験委員会試験の作成と管理を行うことを認定された組織。ITサービスマネジメントの試験委員会は、共通の摘要に基づいたITIL試験の作成、トレーニング組織の認定、証明書の授与を、ICMBに認可されている。ISEB、EXINを参照。

Examination Institute for Information Science (EXIN)

Examination Institute for Information Science（EXIN）

EXINは、試験委員会としてICMBに認定されている。詳細は、http://www.exin-exams.com/を参照。

Exception Report 例外レポート定義済みのしきい値を超えた、1つまたは複数のKPIやその他の重要な目標値の詳細を含む文書。例えば、達成されていないか達成されそうにないSLAの目標値や、潜在的なキャパシティの問題を示しているパフォーマンス測定基準などが含まれる。

Exclusiveness 排他性 V3書籍内になしExpanded Incident Lifecycle 拡張版インシデント・ライ

フサイクル(Availability Management) インシデントのライフサイクルの詳細な段階。検出、診断、修理、復旧、回復という段階がある。拡張版インシデント・ライフサイクルは、インシデントのインパクトを増大させたすべてのものを把握し、それらをコントロールまたは低減する方法を計画するために使用される。

Expert user エキスパート・ユーザー V3書籍内になしExploitation 活用、利用、実施　External audit 外部監査　External Customer 外部顧客 ITサービス・プロバイダとは異なる事業体に属する顧客。外部サービス・プロバイダ、内部顧客を

参照。External Metric 外部測定基準顧客へのITサービス提供を測定するために使用する測定基準。外部測定基準は、通常、SLAに定義

され、顧客に報告される。内部測定基準を参照。External Service Provider 外部サービス・プロバイダ (サービスストラテジ) 顧客とは異なる組織に属するITサービス・プロバイダ。ITサービス・プロバイダ

は、内部顧客と外部顧客の両方を持つ場合がある。タイプIIIサービス・プロバイダを参照。

External Sourcing 外部ソーシングアウトソーシングの同義語。Facilities 施設、設備　Facilities Management 施設管理 (サービスオペレーション) ITインフラストラクチャが存在する物理的環境の管理を責務とする機能。

施設管理には、物理的環境のあらゆる面での管理が含まれる。例えば、電源や冷却、建物へのアクセス管理、環境モニタリングなど。

Failure 障害、不具合 (サービスオペレーション) 仕様に沿って稼働する能力、または要求されるアウトプットを提供する能力を失うこと。障害という用語は、ITサービス、プロセス、活動、構成アイテムなどに関連して使用される場合がある。障害は、インシデントの原因となることが多い。

Failure Modes and Effects Analysis (FMEA)

故障モード影響解析（FMEA）

障害の潜在的なインパクトのアセスメントのアプローチ。FMEAでは、各構成アイテムの障害後に起こることを、事業体への影響にまでわたって分析する。FMEAは、情報セキュリティ管理およびITサービス継続性計画立案で使用されることが多い。

Fall back 戻る、後退する　Fast Recovery 高速復旧 (サービスデザイン) 復旧オプションの1つ。ホット・スタンバイともいう。ITサービスを短期間（通常

は24時間未満）で復旧させる態勢が取られる。高速復旧には、通常、コンピュータ・システムを含む専用の固定設備と、ITサービスをすぐに実行できるように設定、準備されたソフトウェアを使用する。バックアップからデータをリストアする必要がある場合、即時的復旧に最長24時間かかる可能性がある。

Fault 誤り、障害エラーの同義語。Fault Management 障害管理　Fault Tolerance 耐障害性 (サービスデザイン) ITサービスまたは構成アイテムが、あるコンポーネント部分に障害が発生した

後も適切に稼働し続ける能力。対障害弾力性、対策を参照。Fault Tree Analysis (FTA) 故障樹解析（FTA） (サービスデザイン) (継続的サービス改善) 問題の原因となるイベントの連鎖を判別するために使

用できる技法。故障樹解析では、ブール表記法を使用してイベントの連鎖を図に表す。

Feedback フィードバック　Financial Management 財務管理 (サービスストラテジ) ITサービス・プロバイダの予算業務、会計業務、および課金に対する要件の管

理を責務とする機能およびプロセス。Financial Management for IT Services

ITサービス財務管理（財務管理）ITサービス・プロバイダの予算管理、会計、および課金に対する要件の管理を責務とするプロセス。

Financial year 会計年度（財務管理）連続した12か月間の会計期間。会計年度は、どの日付から開始してもよい。例えば、4月1日から3月31日までなど。

First Time Fix Rate 初回解決率（サービスデスク）（インシデント管理）1次サポートによって遅延やエスカレーションなしで解決されたインシデントの割合を測定するための測定基準。この測定基準には異なる定義付けをすることもできる。例えば、ITサービス・プロバイダの中には、ユーザの初回のコール中に解決されたインシデントの割合として定義している所もある。

First-line Support 1次サポート (サービスオペレーション) インシデントの解決に関与するサポート・グループ階層の最初のレベル。レベルが進むごとに、より高度な専門的スキルや、より多くの時間やその他のリソースが費やされるようになる。エスカレーションを参照。

Fishbone Diagram フィッシュボーン・ダイアグラム

石川ダイアグラムの同義語。

Fit for Purpose 目的に適した、目的に適切な

達成目標またはサービスレベルを実現することが可能なプロセス、構成アイテム、ITサービスなどの説明に使用する、非公式な用語。目的に適しているようにするためには、適切な設計、実装、コントロール、保守が必要になる。

Fit for Use 使用に適した、使用に適切な

　

Fix 修正、修理、修復　Fix notes 修正記録、フィックス・

ノート　

Fixed Cost 固定費 (サービスストラテジ) ITサービスの使用によって変化することがないコスト。例えば、サーバ・ハードウェアのコストなど。変動費を参照。

Fixed Facility 固定設備 (サービスデザイン) ITサービス継続性計画によって必要とされる場合に使用可能な、常設の建物。復旧オプション、移動設備を参照。

Fixed Price 固定価格（財務管理）サプライヤまたは顧客と合意したコストまたは料金。リソースの使用やプロジェクトの実施時間が変更された場合でも、このコストや料金は変わらない。



用語用語定義／備考Flexibility 柔軟性　Follow the Sun フォロー・ザ・サン (サービスオペレーション) 24時間365日のサービスを途切れることなく提供するために、世界中の

サービスデスクやサポート・グループを活用する方法論。異なるタイムゾーンのグループ間で、コール、インシデント、問題、サービス要求の受け渡しが行われる。

Follow the Sun Support フォロー・ザ・サン・サポート

　

Framework フレームワーク　Fulfilment 履行、充足、実現ニーズや要件を満たすために活動を実施すること。例えば、新しいITサービスを提供することや、サ

ービス要件を満たすこと。Full Cost 全部原価（財務管理）ITサービスの提供に使用される、すべてのリソースの総コスト。つまり、アウトプットを

産出するための直接費、一定の比率で割り当てられる間接費、あらゆる販売経費や輸送経費の合計である。総所有コスト、限界費用を参照。

Full Release フル・リリース（リリース管理）変更されていないコンポーネントを含む、リリース・ユニットのすべてのコンポーネントを包含するリリース。リリース・タイプを参照。

Function 機能 · 1つまたは複数のプロセスや活動を実施するために用いられる、人材で構成されるチームまたは人材の集まりと、その人材が使用するツール。例えば、サービスデスクなど。機能という用語には、ほかにも次の2つの意味もある。構成アイテム、人材、チーム、プロセス、またはITサービスの本来の目的。例えば、電子メール・サービスの機能の1つは送信メールの保管と転送であり、ビジネス・プロセスの機能の1つは顧客への商品発送である。本来の目的を正しく実行すること。例：「コンピュータは機能している」

Function (1) - as in purpose (1)用途を意味する場合 ― 機能

　

Function (2) - as in functionality （2）機能性を意味する場合－機能

　

Functional Escalation 機能的エスカレーション (サービスオペレーション) エスカレーションを支援するために、より高度な専門知識を持つ技術チームにインシデント、問題、または変更を転送すること。

Functional maintenance 機能の保守　Functionality 機能性　Gap Analysis ギャップ分析 (継続的サービス改善) 2つのデータを比較し、違いを特定する活動。ギャップ分析は、一連の要件と

実際の提供物を比較するためによく使用される。ベンチマークを参照。Goal 最終目標　Going Rate 現行料金（財務管理）課金方針の1つ。内部の他の部署や類似組織の内部の部署が課金する料金と同じ料

金にする。Good Practice グッドプラクティス　Governance ガバナンス方針と戦略が実際に遂行されていることと、必要なプロセスに正しく従っていることを確実にするこ

と。ガバナンスには、役割と責任の定義、測定と報告、および特定された課題を解決するための措置の実施が含まれる。

Gradual Recovery 段階的復旧 (サービスデザイン) 復旧オプションの1つ。コールド・スタンバイともいう。ITサービスを72時間以上かけて復旧させる態勢が取られる。段階的復旧では、通常、環境的なサポートやネットワーク配線は配備しているが、コンピュータ・システムは含まない移動設備または固定設備を使用する。ハードウェアの設置とソフトウェアのインストールは、ITサービス継続性計画の一部として行われる。

Grow the Business (GTB) 事業拡大（GTB）　Guideline 指針実行するべきことを推奨する、ベストプラクティスを記述した文書。指針の遵守は、通常、強制的なも

のではない。標準を参照。Hacker ハッカー　Hardware ハードウェア　Help Desk ヘルプデスク (サービスオペレーション) ユーザがインシデントを記録するための窓口。ヘルプデスクは、通常、サ

ービスデスクより技術に焦点を合わせている。すべてのやりとりに対する単一窓口ではない。ヘルプデスクという用語は、サービスデスクの同義語として使用されることが多い。

Helpfulness 有益さ　Hierarchic Escalation 階層的エスカレーション (サービスオペレーション) エスカレーションを支援するために、より上級レベルのマネジメントに情

報を提供したり、彼らを関与させたりすること。High Availability 高可用性 (サービスデザイン) ITサービスのユーザに対する構成アイテムの障害の影響を、最小化するか見え

ないようにするアプローチまたは設計。高可用性ソリューションは、合意されたレベルの可用性を達成するために設計される。このソリューションは、耐障害性、対障害弾力性、および高速復旧などの技法を利用して、インシデントの数およびインシデントのインパクトを低減する。

Hoax デマ情報　Hot Standby ホット・スタンバイ高速復旧または即時的復旧の同義語。Identification 識別　Identity ID (サービスオペレーション) ユーザ、人、または役割を識別するために使用される一意の名前。IDは、

ユーザ、人、または役割に権限を与えるために使用される。例として、「SmithJ」というユーザ名、「変更マネージャ」という役割などがある。

Immediate Recovery 即時的復旧 (サービスデザイン) 復旧オプションの1つ。ホット・スタンバイともいう。サービスを止めることなくITサービスを復旧させる態勢が取られる。即時的復旧では、通常、ミラー化、ロード・バランシング、およびサイト分割技術が使用される。

Impact インパクト (サービスオペレーション) (サービストランジション) インシデント、問題、または変更による、ビジネス・プロセスに対する影響の指標。インパクトは、サービスレベルが受ける影響の程度に基づくことが多い。インパクトと緊急度は、優先度を割り当てるために使用する。

Impact analysis インパクト分析　Impact Code インパクト・コードインパクトを表すために使用するカテゴリ。例えば、重大、軽微、壊滅的など。優先度を参照。Impact scenario インパクト・シナリオ　Incident インシデント (サービスオペレーション) ITサービスに対する計画外の中断、または、ITサービスの品質の低下。サ

ービスにまだ影響していない構成アイテムの障害もインシデントである。例えば、ミラー化されたディスクの1つに起きた障害など。

Incident call インシデント・コール　Incident control インシデント・コントロール　Incident lifecycle インシデント・ライフサ

イクル　

Incident Management インシデント管理 (サービスオペレーション) すべてのインシデントのライフサイクルを管理するために使用されるプロセス。インシデント管理の主要な達成目標は、可能なかぎり迅速に、ユーザに対するITサービスを復帰させることである。

Incident Record インシデント・レコード (サービスオペレーション) インシデントの詳細を含むレコード。各インシデント・レコードには、単一のインシデントのライフサイクルが記録される。

Indirect Cost 間接費 (サービスストラテジ) ITサービスを提供するためのコストのうち、特定の顧客に全額を割り当てることができないもの。例えば、共有サーバまたはソフトウェア・ライセンスの提供にかかるコストなど。オーバヘッドともいう。直接費を参照。

Information 情報　



用語用語定義／備考Information & Communication Technology (ICT)

情報通信技術（ICT）　

Information management 情報管理　Information processing 情報処理　Information Security Management (ISM)

情報セキュリティ管理（ISM）

(サービスデザイン) 組織の資産、情報、データ、およびITサービスの機密性、完全性、および可用性を確実なものにするプロセス。情報セキュリティ管理は、通常、セキュリティ管理対する組織的なアプローチ（ITサービス・プロバイダよりも適用範囲が広い）に含まれ、組織全体にわたる書類の取り扱い、建物へのアクセス、通話などが含まれる。

Information Security Management System (ISMS)

情報セキュリティ管理システム（ISMS）

(サービスデザイン) 組織が情報セキュリティ管理の達成目標を確実に満たすことができるようにするための方針、プロセス、標準、指針、ツールの枠組み。

Information Security Manager 情報セキュリティ・マネージャ

（セキュリティ管理）情報セキュリティ・マネージャは、ITサービス・プロバイダにおける情報セキュリティ管理プロセスを責務とする役割である。情報セキュリティ・マネージャは、情報セキュリティ方針およびSLAで指定されたセキュリティに対する要求を満たすことを責務とする。情報セキュリティ・マネージャは、通常、実施自体はITサービス・プロバイダの他の要員に委任する。情報セキュリティ責任者と情報セキュリティ・マネージャは緊密に連携する。

Information Security Officer 情報セキュリティ責任者（セキュリティ管理）情報セキュリティ責任者は、事業上のリスクのアセスメントと情報セキュリティ方針の設定を責務とする。これは情報セキュリティ・マネージャに対応する役割であり、顧客の組織内に常駐する。情報セキュリティ責任者と情報セキュリティ・マネージャは緊密に連携する。

Information security plan 情報セキュリティ計画　Information Security Policy 情報セキュリティ方針 (サービスデザイン) 情報セキュリティ管理に対する組織のアプローチを統制する方針。Information system 情報システム　Information Systems Examination Board (ISEB)

Information Systems Examination Board（ISEB）

British Computer SocietyのISEBは、試験委員会としてICMBに認定されている。詳細は、http://www.bcs.org/bcs/products/qualifications/isebを参照。

Information Technology (IT) 情報技術（IT）情報の保存、通信、または処理のために使用する技術。この技術には、通常、コンピュータ、電気通信、アプリケーション、およびその他のソフトウェアが含まれる。情報には、事業データ、音声、画像、動画などが含まれる場合がある。情報技術は、ITサービスを介してビジネス・プロセスを支援するために使用されることが多い。

Information Technology Infrastructure Library (ITIL)

ITインフラストラクチャ・ライブラリ（ITIL）

　

Informed Customer インフォームド・カスタマ顧客側のマネージャであり、ITサービス・プロバイダへの対応と管理の専門家である。インフォームド・カスタマは、サービス・プロバイダとの関係の管理におけるあらゆる側面を責務とする。

Infrastructure インフラストラクチャ　Infrastructure Service インフラストラクチャ・サ

ービス事業体が直接使用するのではなく、ITサービス・プロバイダが他のITサービスを提供にするために必要とするITサービス。例えば、ディレクトリ・サービス、ネーミング・サービス、通信サービスなど。

Initiator 要求元、発信者　Input インプット　Insource インソース ITサービスの供給を、外部サービス・プロバイダから内部サービス・プロバイダへ移行すること。イン

ソーシングという用語は、内部サービス・プロバイダとしてITサービスを運用または管理する意味に使用される。アウトソースを参照。

Insourcing インソーシング内部ソーシングの同義語。Install （電子的な場合）インス

トールする、（物理的・概念的な場合）設置する、導入する

　

Installability インストール性　Installation （電子的な場合）インスト

ール、（物理的・概念的な場合）設置、導入

　

Institute of IT Service Management Institute of IT Service Management

特にITサービスマネジメントの専門家を対象とする、独立した専門家団体。「専門的かつ倫理的な行いに対する高度な水準を確立し、会員が能力とコミットメントを示すための継続的な専門能力開発を行うようにすることによって、会員の地位の向上と支援を目指している。」詳細は、http://www.iosm.com/を参照。

Integrated lifecycle management (ILM)

統合ライフサイクル管理（ILM）

　

Integration 統合　Integration Testing 統合テスト各部分が連携して正しく動作していることを確認するための、構築またはリリースのテスト。Integrity 完全性 (サービスデザイン) セキュリティ原則の1つ。データや構成アイテムが、許可された要員および活動

のみによって修正されるようにする。完全性には、ソフトウェアやハードウェアの障害、環境面におけるイベント、人による介入を含む、修正の原因になりうるすべての事柄を考慮する。

Interactive Voice Response (IVR) 音声自動応答（IVR） (サービスオペレーション) 自動着信呼分配の形式の1つ。キー入力や発話による指示などのユーザ入力を受信し、着信コールの正しい宛先を識別する。

Interface インタフェース　Intermediate Recovery 中間的復旧 (サービスデザイン) 復旧オプションの1つ。ウォーム・スタンバイともいう。ITサービスを24～72時

間で復旧させる態勢が取られる。中間的復旧では、通常、コンピュータ・システムとネットワーク・コンポーネントを含む、共有の移動設備または固定設備を使用する。ハードウェアとソフトウェアの設定、およびデータの回復は、ITサービス継続性計画の一部として行う必要がある。

Internal Customer 内部顧客 ITサービス・プロバイダと同じ事業体に属する顧客。内部サービス・プロバイダ、外部顧客を参照。Internal Metric 内部測定基準 ITサービス・プロバイダの内部プロセスの効率性、有効性、または費用対効果をモニタするため

に、ITサービス・プロバイダ内で使用される測定基準。内部測定基準は、通常、ITサービスの顧客へは報告されない。外部測定基準を参照。

Internal Rate of Return (IRR) 内部収益率（IRR） (サービスオペレーション) 資本的支出に関する意思決定を支援するために使用する技法。IRRでは、2つ以上の投資案を比較できるように数値を計算する。IRRが大きいほうが、投資が有利であることを示す。正味現在価値、投資収益率を参照。

Internal Service Provider 内部サービス・プロバイダ (サービスストラテジ) 顧客と同じ組織に属するITサービス・プロバイダ。ITサービス・プロバイダは、内部顧客と外部顧客の両方を持つ場合がある。タイプIサービス・プロバイダ、タイプIIサービス・プロバイダ、インソースを参照。

Internal Sourcing 内部ソーシング (サービスストラテジ) ITサービスの管理に内部サービス・プロバイダを利用すること。サービス・ソーシング、タイプIサービス・プロバイダ、タイプIIサービス・プロバイダを参照。

International Organization for Standardization (ISO)

国際標準化機構（ISO）国際標準化機構（ISO）は、世界最大の標準策定機関である。ISOは非政府組織であり、156か国の国内標準化機関から成るネットワークである。ISOの詳細は、http://www.iso.org/を参照。

International Standards Organisation

International Standards Organisation

国際標準化機構（ISO）を参照。

Internet Service Provider (ISP) インターネット・サービス・プロバイダ（ISP）

インターネットへのアクセスを提供する外部サービス・プロバイダ。ISPのほとんどは、ウェブ・ホスティングなどの他のITサービスも提供する。

Interoperability 相互運用性　



用語用語定義／備考Investment Appraisal 投資評価（財務管理）新規サービスまたは変更されたITサービスに対する資本的支出額を正当化するため

に、費用便益分析を実施することを責務とする活動。ビジネス･ケース、費用対効果、投資収益率、使用総資本利益率を参照。

Invocation 発動 (サービスデザイン) 計画で定義されたステップを開始すること。例えば、1つまたは複数のITサービスを対象としたITサービス継続性計画を開始するなど。

Ishikawa Diagram 石川ダイアグラム (サービスオペレーション) (継続的サービス改善) 問題の原因となりうるすべてのものをチームが識別するのを支援する技法。石川馨氏によって考案されたもので、この技法のアウトプットは、魚の骨のように見える図になる。

ISO 9000 ISO 9000 品質管理システムに対する数多くの国際的な標準や指針を指す総称。詳細は、http://www.iso.org/を参照。ISOを参照。

ISO 9001 ISO 9001 品質管理システムの国際標準。ISO 9000、標準を参照。ISO quality standards ISO品質規格　ISO/IEC 17799 ISO/IEC 17799 (継続的サービス改善) ISOによる情報セキュリティ管理の実践のための規範。標準を参照。

ISO/IEC 20000 ISO/IEC 20000 ISOによるITサービスマネジメントの仕様と実践のための規範。ISO/IEC 20000はITILのベストプラクティスと整合性を取っている。

ISO/IEC 27001 ISO/IEC 27001 (サービスデザイン) (継続的サービス改善) ISOによる情報セキュリティ管理の仕様。対応する実践のための規範はISO/IEC 17799である。標準を参照。

IT Accounting IT会計（財務管理）ITサービスの提供にかかる実際のコストを識別し、それらのコストを予算上のコストと比較して、予算との不一致を管理することを責務とするプロセス。課金も参照。

IT Accounting System IT会計システム（財務管理）財務管理を支援するすべての方針、手段、およびプロセスを包括したもの。IT Availability Metrics Model (ITAMM)

IT可用性測定基準モデル（ITAMM）

（可用性管理）可用性の測定基準とレポートを定義する際に、可用性のあらゆる側面を確実に考慮するために役立つモデル。

IT Directorate IT担当役員 (継続的サービス改善) ITサービスの開発と提供の責任者となる、サービス・プロバイダの上級マネジメント。この役割は、英国政府機関で最もよく用いられる。

IT Infrastructure ITインフラストラクチャ ITサービスの開発、テスト、提供、モニタリング、コントロール、サポートに必要とされるすべてのハードウェア、ソフトウェア、ネットワーク、設備など。ITインフラストラクチャという用語には、情報技術のすべてが含まれるが、関連する人々、プロセス、および文書は含まない。

IT Infrastructure Library (ITIL) ITインフラストラクチャ・ライブラリ（ITIL）

ITサービスマネジメントに関する一連のベストプラクティスの手引き。ITILはOGCによって所有され、itSMFと連携して開発されている。ITILは、良質なITサービスの供給に関する手引きを記載した出版物と、それらをサポートするために必要なプロセスおよび設備に関する手引きを記載した出版物のセットで構成されている。詳細は、http://www.ogc.gov.uk/index.asp?id=2261を参照。

IT manager ITマネージャ　IT Operations IT運用 (サービスオペレーション) IT運用コントロールによって実施される活動。コンソール管理、ジョブ・ス

ケジューリング、バックアップとリストア、印刷と出力の管理を含む。IT運用は、サービスオペレーションの同義語としても使用される。

IT Operations Control IT運用コントロール (サービスオペレーション) ITサービスとITインフラストラクチャのモニタリングとコントロールを責務とする機能。運用統制室を参照。

IT Operations Management IT運用管理 (サービスオペレーション) ITサービスおよびそれを支えるITインフラストラクチャの管理に必要な日々の活動を実施するITサービス・プロバイダ内の機能。IT運用管理には、IT運用コントロールと施設管理が含まれる。

IT Operations Management function (IT Operations Control and Facilities Management)

IT運用管理機能（IT運用コントロールと施設管理）

　

IT Service ITサービス ITサービス・プロバイダにより顧客に提供されるサービス。ITサービスは情報技術の使用を前提として、顧客のビジネス・プロセスを支援する。ITサービスは、人材、プロセス、技術の組み合わせから成る。ITサービスは、サービスレベル・アグリーメントで定義する必要がある。

IT Service Continuity Management (ITSCM)

ITサービス継続性管理（ITSCM）

(サービスデザイン) ITサービスに深刻なインパクトを与えるリスクの管理を責務とするプロセス。ITSCMは、リスクを許容可能なレベルにまで低減し、ITサービスの復旧に対する計画立案を行うことによって、ITサービス・プロバイダが最低限の合意済みサービスレベルを常に、確実に提供できるようにする。ITSCMは、事業継続性管理を支援するように設計されるべきである。

IT service continuity manager ITサービス継続性マネージャ

　

IT Service Continuity Plan ITサービス継続性計画 (サービスデザイン) 1つまたは複数のITサービスの復旧に必要なステップを定義する計画。この計画では、発動の契機、関与する人、コミュニケーションなども特定する。ITサービス継続性計画は、事業継続性計画の一部となるべきである。

IT service continuity planning ITサービス継続性計画立案　IT Service Management (ITSM) ITサービスマネジメント

（ITSM）事業体のニーズを満たす良質のITサービスを実施および管理すること。ITサービスマネジメントは、ITサービス・プロバイダによって、人材、プロセス、情報技術の適切な組み合わせを用いて実行される。サービスマネジメントを参照。

IT Service Management Forum (itSMF)

ITサービスマネジメントフォーラム（itSMF）

ITサービスマネジメントフォーラムは、ITサービスマネジメントに対する専門的なアプローチの推進に専念している独立組織である。tSMFは、会員による非営利の組織であり、世界中の多くの国に代表組織（itSMF支部）がある。itSMFとその会員は、ITILおよび関連するITサービスマネジメント標準の発展に貢献している。詳細は、http://www.itsmf.com/を参照。

IT Service Provider ITサービス・プロバイダ (サービスストラテジ) 内部顧客または外部顧客にITサービスを提供するサービス・プロバイダ。IT Steering Group (ISG) IT運営グループ（ISG）事業体とITサービス・プロバイダの戦略と計画を緊密に連携させることを責務とする正式なグルー

プ。IT運営グループには、事業体とITサービス・プロバイダの上級レベルの代表が含まれる。

ITIL ITIL ITサービスマネジメントに関する一連のベストプラクティスの手引き。ITILはOGCに所有されており、良質なITサービスの供給に関する手引きを記と、それらをサポートするために必要なプロセスおよび設備に関する手引きを記載した一連の出版物で構成されている。詳細は、http://www.itil.co.uk/を参照。

ITIL Certification Management Board (ICMB)

ITIL Certification Management Board（ICMB）

　

Job Description 職務記述書特定の個人に要求される役割、責任、スキル、ナレッジを定義する文書。1つの職務記述書には、複数の役割を含めることができる。例えば、構成マネージャと変更マネージャの役割は、1人の要員によって実行される場合がある。

Job Scheduling ジョブ・スケジューリング (サービスオペレーション) ITサービスの一部として必要とされるソフトウェア・タスクの実行の計画立案と管理。ジョブ・スケジューリングはIT運用管理によって実施され、多くの場合、日、週、月、または年の特定の時間にバッチまたはオンラインのタスクを実行するソフトウェア・ツールを使用して自動化される。

Kano Model 狩野モデル (サービストランジション) 狩野紀昭氏によって考案された、顧客の好みを理解するために使用するモデル。狩野モデルでは、基本品質、興奮品質、性能品質といった領域にグループ化されたITサービスの属性を検討する。

Kepner & Tregoe Analysis ケプナー・トリゴー分析 (サービスオペレーション) (継続的サービス改善) 問題解決に対する体系的なアプローチの1つ。何が、どこで、いつ、どの程度という点から問題が分析される。考えられる原因が識別され、最も可能性の高い原因がテストされ、真の原因が検証される。

Key Performance Indicator (KPI) 重要業績評価指標（KPI） (継続的サービス改善) プロセス、ITサービス、または活動の管理を支援するために使用される測定基準。さまざまな測定基準を使用できるが、最も重要なものだけがKPIとして定義され、プロセス、ITサービス、または活動を積極的に管理および報告するために使用される。効率性、有効性、費用対効果のすべてを確実に管理するためには、KPIを選択するべきである。重要成功要因を参照。



用語用語定義／備考Knowledge Base ナレッジ・ベース (サービストランジション) サービス・ナレッジ管理システムで使用されるデータを含む、論理データ

ベース。

Knowledge Management ナレッジ管理 (サービストランジション) 組織内における、ナレッジ情報の収集、分析、格納、および共有を責務とするプロセス。ナレッジ管理の主要な目的は、ナレッジを再発見する必要性を低くすることにより、効率性を改善することである。データ・情報・ナレッジ・知恵、サービス・ナレッジ管理システムを参照。

Knowledge process outsourcing (KPO)

ナレッジ・プロセス・アウトソーシング（KPO）

　

Known Error 既知のエラー (サービスオペレーション) 文書化された根本原因とワークアラウンドがある問題。既知のエラーは、問題管理によって作成され、ライフサイクルを通じて管理される。既知のエラーは、開発者またはサプライヤによって特定される場合もある。

Known Error Database (KEDB) 既知のエラー・データベース（KEDB）

(サービスオペレーション) すべての既知のエラー・レコードが含まれるデータベース。このデータベースは、問題管理によって作成され、インシデント管理と問題管理に使用される。既知のエラー・データベースは、サービス・ナレッジ管理システムに含まれる。

Known Error Record 既知のエラー・レコード (サービスオペレーション) 既知のエラーの詳細を含むレコード。既知のエラー・レコードそれぞれには、ステータス、根本原因、ワークアラウンドを含む、既知のエラーのライフサイクルを記述する。実施方法によっては、問題レコード内の補足的なフィールドを使用して既知のエラーを文書化する場合もある。

License Management ライセンス管理ソフトウェアのライフサイクルを通した、ソフトウェア・ライセンスの管理を責務とするプロセス。Lifecycle ライフサイクル ITサービス、構成アイテム、インシデント、問題、変更などの存続期間におけるさまざまな段階。ライ

フサイクルでは、ステータスのカテゴリと、許可されるステータス遷移が定義される。例として、次のようなものがある。アプリケーションのライフサイクルには、要件、設計、構築、展開、運用、最適化が含まれる。拡張版インシデント・ライフサイクルには、検出、応答、診断、修理、復旧、回復が含まれる。サーバのライフサイクルには、注文済み、受領済み、テスト中、稼働中、廃棄などが含まれる。

Lifecycle management ライフサイクル管理　

Line of Service (LOS) サービス・ライン（LOS） (サービスストラテジ) 複数のサービスレベル・パッケージを持つコアサービスまたは補助サービス。サービス・ラインは製品マネージャによって管理され、各サービスレベル・パッケージは、特定の市場区分を支援するために設計される。

Live 稼働中 (サービストランジション) サービスを顧客に提供するために使用されているITサービスまたは構成アイテムを指す。

Live Environment 稼働環境 (サービストランジション) ITサービスを顧客に提供するために使用される、稼働中の構成アイテムを含むコントロールされた環境。

Local (distributed) Service Desk ローカル・サービスデスク　Logging 履歴を取る、記録する　Maintainability 保守性 (サービスデザイン) 障害の後、構成アイテムまたはITサービスをどの程度迅速かつ効果的に通常

の稼働状態に戻せるかを表す指標。保守性は、MTRSとして測定、報告されることが多い。保守性は、ソフトウェアまたはITサービスの開発においては、容易に変更や修理を行える能力を意味することもある。

Maintenance 保守、維持、維持管理　Maintenance and Repair Operations (MRO)

保守作業と修理作業（MRO）

　

Maintenance window 保守時間帯　Major Incident 重大なインシデント (サービスオペレーション) インシデントのインパクトのうち、最上位のカテゴリ。重大なインシデント

は、事業体にとって深刻な中断の原因になる。Major Release 大規模リリース　Manage, to 管理する　Manageability 管理性　Managed Object (MO) 管理対象オブジェクト

（MO）リソースの運用管理に使用される、そのリソースの抽象的な表現。MOは、リソースの属性、そのリソースに対して実行される可能性がある操作、そのリソースが発行する可能性がある通知、他のMOとの関係の点で定義される。MOは、そのステータスが動的な点で構成アイテムと異なる。また、MOの運用状態に対する変更は、変更管理プロセスで承認する必要がない。

Managed Services マネージド・サービス (サービスストラテジ) ITサービスが管理されているということを強調した、ITサービスに対する観点の1つ。マネージド・サービスという用語は、アウトソースITサービスの同義語としても使用される。

Management (活動の場合)管理、(人の場合）マネジメント

　

Management Information 管理情報マネージャによる意思決定を支援するために使用される情報。管理情報は、さまざまなITサービスマネジメント・プロセスを支援するツールにより、自動的に生成されることが多い。管理情報には、「インシデントの原因になる変更の割合」や「初回解決率」などのKPIの値が含まれることが多い。

Management Information System (MIS)

管理情報システム（MIS）管理情報を取得、処理、および提供するITサービス。MISという用語は、非公式には、データやレポートなどのMISのアウトプットの意味にも使用される。

Management of Risk (MoR) リスクの管理（MoR）リスクの管理に対するOGCの方法論。MoRには、組織の事業達成目標の実現にインパクトを与える可能性のあるリスクの危険性の識別とコントロールに必要なすべての活動が含まれる。詳細は、http://www.m-o-r.org/を参照。

Management System 管理の仕組み組織がその達成目標を確実に実現できるようにする方針、プロセス、および機能の枠組み。Manual Workaround 手作業のワークアラウンド手作業による介入を必要とするワークアラウンド。手作業のワークアラウンドは、ビジネス・プロセス

がITサービスを使用しないで運用される復旧オプションの名前としても使用される。これは一時的な対策であり、通常、他の復旧オプションと併用される。

Marginal Cost 限界費用 (サービスストラテジ) ITサービスの提供を継続するためのコスト。限界費用には、新しいソフトウェアの開発やトレーニングの提供にかかるコストなど、すでに行われた投資は含まれない。

Market Price 市場価格（財務管理）課金方針の1つ。外部サプライヤが課金する料金と同じ料金にする。Market Space 市場空間 (サービスストラテジ) 顧客のビジネス・ニーズを満たすためにITサービス・プロバイダが活用でき

るすべての機会。市場空間は、ITサービス・プロバイダが提供を検討したほうがよい可能性があるITサービスを特定する。

Matching 照合　Maturity 成熟度 (継続的サービス改善) プロセス、機能、組織などの信頼性、効率性、有効性の指標。最も成熟したプ

ロセスおよび機能は、事業達成目標および事業戦略と正式に整合されており、継続的改善の枠組みによってサポートされている。

Maturity Level 成熟度レベルカーネギーメロン大学の能力成熟度モデル統合版などの成熟度モデルにおいて指定されているレベル。

Mean Time Between Failures (MTBF) 平均故障間隔（MTBF） (サービスデザイン) 信頼性を測定、報告するための測定基準。MTBFは、構成アイテムまたはITサービスが、合意済みの機能を中断なく実行できる時間の平均値である。CIまたはITサービスが稼働を開始した時点から、次に障害が発生した時点までを測定する。

Mean Time Between Service Incidents (MTBSI)

平均サービス・インシデント間隔（MTBSI）

(サービスデザイン) 信頼性を測定、報告するために使用される測定基準。MTBSIは、システムまたはITサービスに障害が発生した時点から、次に障害が発生した時点までの平均時間である。MTBSIは、MTBFとMTRSを足したものに等しい。

Mean Time To Repair (MTTR) 平均修理時間（MTTR）障害の後、構成アイテムまたはITサービスを修理するためにかかる時間の平均値。MTTRは、CIまたはITサービスに障害が発生した時点から、修理された時点までを測定する。MTTRには、復旧または回復に必要な時間は含まれない。MTTRは、MTRSと混同されることがある。



用語用語定義／備考Mean Time to Restore Service (MTRS)

平均サービス回復時間（MTRS）

障害の後、構成アイテムまたはITサービスを回復させるためにかかる時間の平均値。MTRSは、CIまたはITサービスに障害が発生した時点から、それらが完全に回復して通常の機能を提供できるようになった時点までを測定する。保守性、平均修理時間を参照。

Metric 測定基準 (継続的サービス改善) プロセス、ITサービス、または活動の管理を支援するために測定、報告されるもの。 KPIを参照。

Middleware ミドルウェア (サービスデザイン) 2つ以上のソフトウェア・コンポーネントやアプリケーションを連結するソフトウェア。ミドルウェアは通常、ITサービス・プロバイダで開発するより、サプライヤから購入する。既製を参照。

Minor Release 小規模リリース　Mission Statement ミッション・ステートメント組織のミッション・ステートメントとは、簡潔ではあるが、完全に組織の目的と意図を記述している説

明である。達成するべきことは記述されているが、取るべき方法は記述されていない。

Mitigate 軽減する　Model モデルシステム、プロセス、ITサービス、構成アイテムなどを表したもので、将来の働きを把握または予測す

るために使用される。 Modelling モデル化システム、プロセス、ITサービス、構成アイテムなどの将来の働きを予測するために使用される技

法。モデル化は、財務管理、キャパシティ管理、および可用性管理でよく使用される。

Modification 修正　Monitor Control Loop モニタ・コントロール・

ループ(サービスストラテジ) タスク、プロセス、ITサービス、または構成アイテムのアウトプットをモニタリングし、そのアウトプットを事前定義された規範と比較し、その比較に基づいて適切な措置をとること。

Monitor, to モニタする　Monitoring モニタリング (サービスオペレーション) イベントを検出し、現状を確実に把握するために、構成アイテム、ITサー

ビス、またはプロセスを繰り返し観察すること。Multilevel SLAs マルチレベルSLA 　Naming convention 命名規則　Near-Shore ニアショア (サービスストラテジ) 顧客が存在する国に近い国からサービスを供給すること。これには、ITサービ

スの供給や、またはサービスデスクなどの支援的機能の供給がある。オンショア、オフショアを参照。

Net Present Value (NPV) 正味現在価値（NPV） (サービスオペレーション) 資本的支出に関する意思決定を支援するために使用する技法。NPVでは、資金収入と資金支出を比較する。NPVがプラスであれば、投資に価値がある。内部収益率、投資収益率を参照。

Network ネットワーク　Network administrator ネットワーク・アドミニス

トレータ　

Network management ネットワーク管理　New services development (NSD) 新規サービス開発（NSD）　n-line Support N次サポート（サービスデスク）（インシデント管理）（問題管理）あらゆるレベルのサポート・グループに対する

総称。1次サポート、2次サポート、3次サポートを参照。Nonrepudiation 否認防止　Notional Charging 概念上の課金 (サービスストラテジ) ITサービスに対する課金のアプローチの1つ。顧客への料金が計算され、顧客

にその料金が通知されるが、実際の金銭の振込みは行われない。概念上の課金は、かかったコストを顧客に認識させるため、または実際の課金までの予備段階として導入されることがある。

Objective 達成目標プロセス、活動、または組織全体において定義された目的や狙い。達成目的は、通常、測定可能な目標値で表わされる。達成目標という用語は、非公式には要件の意味でも使用される。成果を参照。

Off the Shelf 既製既製品の同義語。Office of Government Commerce (OGC)

Office of Government Commerce (OGC)

OGCは、ITILブランド（著作権と商標）を所有している。OGCは英国の政府機関であり、他の機関とともに、共同調達や、調達のスキルや能力のレベル向上を図る業務を通して、政府の調達案件の実現を支援している。複雑な公共部門プロジェクトの支援も行っている。

Office of Public Sector Information (OPSI)

Office of Public Sector Information（OPSI）

OPSIは、ITIL出版物に使用されている、英国の国家著作権を有する資料の使用を許諾する。OPSIは英国の政府機関であり、英国の法令に対するオンライン・アクセスの提供、英国の国家著作権の再利用許諾、Information Fair Trader Scheme（英国の公正な情報取扱に関する体制）の管理、英国政府の情報資産台帳の維持、公式な出版と国家著作権に関する助言と手引きの提供を行っている。

Off-shore オフショア (サービスストラテジ) 顧客の本拠地である国の外、多くの場合別の大陸からサービスを供給すること。これには、ITサービスの供給や、またはサービスデスクなどの支援的機能の供給がある。オンショア、ニアショアを参照

On-shore オンショア (サービスストラテジ) 顧客の本拠地である国の中からサービスを供給すること。オフショア、ニアショアを参照

Open Systems Interconnection (OSI) 開放型システム間相互接続（OSI）

　

Operability 運用性、操作性、実現可能性

　

Operate 運用する期待どおりに機能すること。プロセスまたは構成アイテムが必要なアウトプットを提供している場合は、「稼働している」といわれる。1つ以上の作業を実行することを指して「運用／運営する」ともいう。例えば、コンピュータを運用することは、コンピュータが期待どおりに機能するために必要な、日々の作業を行うことである。

Operation 運用 (サービスオペレーション) ITサービス、システム、またはその他の構成アイテムの日々の管理。作業は、事前定義された活動またはトランザクションも意味する。例えば、磁気テープの装填、販売時点での金銭の受領、ディスク・ドライブのデータの読み取りなど。

Operational 運用上計画立案と提供における3つのレベル（戦略的、戦術的、運用上）のうち、最下位のレベル。運用上の活動には、ビジネス・プロセスまたはITサービスマネジメント・プロセスに関する日々または短期間の計画立案や提供が含まれる。運用上という用語は、稼働中の同義語でもある。

Operational Acceptance 運用上の受け入れ（リリース管理）リリースの受け入れ活動の一部。IT運用に必要なあらゆるものを、リリースが展開される前に準備することを責務とする。運用上の受け入れでは、必要なすべての文書、IT運用プロセス、ツール、およびトレーニングが確実に準備されるように、チェックリストを使用することが多い。

Operational Cost 運用コスト ITサービス実行の結果として生じるコスト。多くの場合は繰り返し支払われる。例えば、人件費、ハードウェアの保守費用、電気代など（「経常支出」または「収益支出」ともいう）。資本的支出を参照。

Operational Expenditure (OPEX) 運用支出（OPEX）運用コストの同義語。Operational Level Agreement (OLA) オペレーショナルレベル・

アグリーメント（OLA）(サービスデザイン) (継続的サービス改善) ITサービス・プロバイダと、同じ組織内の別の部署との間で交わされる合意。OLAは、ITサービス・プロバイダによる顧客へのITサービス提供を支援する。OLAは、提供される商品またはサービス、および両者の責任を定義する。例えば、次のようなOLAがある。合意されたタイミングでハードウェアを入手するための、ITサービス・プロバイダと調達部門とのOLA合意されたタイミングでインシデントを解決するための、サービスデスクとサポート・グループとのOLA。サービスレベル・アグリーメントを参照。



用語用語定義／備考Operational process 運用プロセス　Operational reliability 運用の信頼性　Operations Bridge 運用統制室 (サービスオペレーション) ITサービスとITインフラストラクチャがモニタおよび管理される物理的

な場所。

Operations Control 運用コントロール IT運用コントロールの同義語。Operations department 運用部門　Operations Management 運用管理 IT運用管理の同義語。Opportunity Cost 機会費用 (サービスストラテジ) 投資対象を決定する際に使用されるコスト。機会費用は、リソースを別の方法

で使用した場合に発生していたであろう収益を表す。例えば新サーバ購入の機会費用には、その資金が充てられていたであろうサービス改善活動を行わないことが含まれるだろう。機会費用分析は意思決定プロセスの一部として利用されるが、財務諸表で実際のコストとして扱われることはない。

Optimise 最適化プロセス、構成アイテム、アプリケーションなどから最大限の効率性と有効性を得るために、レビューと計画を行い、変更を要求すること。

Organisation 組織企業、法人組織、またはその他の機関。企業ではない組織の例には、国際標準化機構（ISO）、itSMFなどがある。組織という用語は、人材、リソース、予算を持つ任意の単位を指す場合がある。例えば、プロジェクトや事業部など。

Outcome 成果活動の実行、プロセスの遂行、ITサービスの提供などの結果。成果という用語は、意図された結果および実際の結果を意味する。達成目標を参照。

Output アウトプット　Outsource アウトソース ITサービスの供給を、内部サービス・プロバイダから外部サービス・プロバイダへ移行すること。ア

ウトソーシングという用語は、ITサービスを管理するために、外部サービス・プロバイダを活用すること、または外部サービス・プロバイダとして機能することを意味するために使用される。インソースを参照。

Outsource, to アウトソースする　Outsourcing アウトソーシング (サービスストラテジ) 外部サービス・プロバイダを利用してITサービスを管理すること。サービス・ソ

ーシング、タイプIIIサービス・プロバイダを参照。Overhead オーバヘッド間接費の同義語。Owner オーナ　Package Release パッケージ・リリース（リリース管理）複数のフル・リリースまたはデルタ・リリースを含む、単一のリリース。リリース・タ

イプを参照。Pain Value Analysis 痛みの値分析 (サービスオペレーション) 1つまたは複数の問題によるビジネス・インパクトの識別を支援するため

に使用する技法。影響を受けるユーザ数、休止時間の長さ、各ユーザへのインパクト、および事業体に対するコスト（分かる場合）に基づいて、ある計算式を用いて痛み値を計算する。

Pareto Principle パレートの法則 (サービスオペレーション) 活動に優先順位を付けるために使用する技法。パレートの法則では、あらゆる活動の価値の80%は、その作業の20%によって生み出されるとされる。パレート分析は、調査目的で、問題の考えられる原因に優先順位を付けるために問題管理でも使用される。

Partnership パートナシップ共通の最終目標や相互の利益のために緊密に連携することを伴う、2つの組織の関係。ITサービス・プロバイダは、事業体との間に、またITサービスの提供に極めて重要なサードパーティとの間にパートナシップを築くべきである。バリュー・ネットワークを参照。

Passive Monitoring 受動的モニタリング (サービスオペレーション) アラートや通知によって現在の状態を検知するようにしている構成アイテム、ITサービス、またはプロセスのモニタリング能動的モニタリングを参照。

Password パスワード　Patch パッチ　Pattern of Business Activity (PBA) 事業活動パターン（PBA） (サービスストラテジ) 1つまたは複数の事業活動の作業負荷の様子。事業活動パターンは、さまざ

まなレベルの事業活動をITサービス・プロバイダが理解し計画立案するために使用される。ユーザ・プロフィールを参照。

Penalty clause 罰則条項　Percentage utilisation 使用率 (サービスデザイン) 任意の期間中に、コンポーネントが使用中である時間の割合。例えば、CPUが1

時間のうち1800秒間使用中であれば、その使用率は50%である。Performance パフォーマンス、実績、業績システム、個人、チーム、プロセス、またはITサービスによって達成または提供されるものの指標。Performance Anatomy パフォーマンス構造 (サービスストラテジ) 組織のカルチャに対するアプローチの1つ。リーダシップと戦略、人材育成、技

術利用、パフォーマンス管理、および革新を統合し、積極的に管理する。

Performance Indicator (PI) 業績評価指標（PI）　Performance Management パフォーマンス管理 (継続的サービス改善) 日々のキャパシティ管理活動を責務とするプロセス。モニタリング、しきい値

検出、パフォーマンスの分析とチューニング、およびパフォーマンスとキャパシティに関する変更の実施が含まれる。

Personal Computer (PC) パーソナル・コンピュータ（PC）

　

Physical control 物理的コントロール　Pilot パイロット (サービスオペレーション) 稼働環境への、ITサービス、リリース、またはプロセスの限定的な展開。

パイロットは、リスクを低減し、ユーザからのフィードバックと受け入れを得るために行われる。テスト、評価を参照。

Plan 計画達成目標を実現するために必要とされる活動およびリソースを説明する、詳細な提案。例えば、新しいITサービスまたはプロセスを実施するための計画。ISO/IEC 20000では、各ITサービスマネジメント・プロセスの管理に対する計画が必要とされている。

Plan-Do-Check-Act 計画・実施・点検・処置、PDCAモデル

(継続的サービス改善) エドワーズ・デミング氏により考案された、プロセス管理のための4つの段階を伴うサイクル。計画・実施・点検・処置は、デミング・サイクルとも呼ばれる。計画：ITサービスを支援するプロセスを設計または修正する実施：計画を実施し、プロセスを管理する点検：プロセスおよびITサービスを測定し、達成目標と比較し、レポートを作成する処置：プロセスを改善するための変更を計画し、実施する。

Planned Downtime 計画休止時間 (サービスデザイン) 合意済みの、ITサービスを使用できない期間。計画休止時間は、保守、更新、およびテストのために使用されることが多い。変更時間帯、休止時間を参照。

Planning 計画立案 1つまたは複数の計画の策定を責務とする活動。例えば、キャパシティ計画立案など。PMBOK PMBOK プロジェクトマネジメント協会によって維持され発行されている、プロジェクト管理の標準。PMBOK

は、Project Management Body of Knowledge（プロジェクトマネジメント・ナレッジ体系）の略称である。詳細は、http://www.pmi.org/を参照。PRINCE2を参照。

Policies 方針　Policy 方針マネジメントの期待や意図を正式に文書化したもの。方針は、意思決定を導くために使用される。

また、プロセス、標準、役割、活動、ITインフラストラクチャなどを、一貫的かつ適切に開発および実施するためにも使用される。

Portability 携帯性、移植性、可搬性　Portable Facility 移動設備 (サービスデザイン) サードパーティが提供するプレハブ建物や大型車両であり、ITサービス継続性

計画で必要とされる場合に現場に移動する。復旧オプション、固定設備を参照。



用語用語定義／備考Portfolio Management ポートフォリオ管理（事業関係管理）サービスのポートフォリオの管理を責務とするプロセス。ポートフォリオ管理に

は、既存または提案されているITサービスの、事業体にとっての価値を最大限にすることと、新しいITサービスを作成する必要性の識別や、すでに価値がなくなったITサービスを廃止することが含まれる。詳細な計画立案と実施の作業は、サービス計画立案プロセスの一部として実行される。

Portfolio of Services サービスのポートフォリオ　Post Implementation Review (PIR) 実施後のレビュー（PIR）変更またはプロジェクトの実施後に行われるレビュー。PIRでは、変更またはプロジェクトが成功した

かどうかを判断し、改善の機会を識別する。 Practice プラクティス業務の方法、または業務を行うべき方法。プラクティスには、活動、プロセス、機能、標準、指針が含ま

れるだろう。ベストプラクティスを参照。

Prerequisite for Success (PFS) 成功の必須条件（PFS）計画またはプロセスを首尾よく実施するために、完了するべき活動、または満たすべき条件。PFSは、あるプロセスからのアウトプットであり、それは別のプロセスに必要とされるインプットであることが多い。

Preventive maintenance 予防保守　Preventive measures 予防対策　Price break 価格破壊　Pricing 価格設定 (サービスストラテジ) 顧客に課金する金額を決定する活動。 PRINCE2 PRINCE2 プロジェクト管理のための、英国政府の標準方法論。詳細は、http://www.ogc.gov.uk/prince2/を

参照。PMBOKを参照。Priority 優先度 (サービストランジション) (サービスオペレーション) インシデント、問題、または変更の相対的な重

要度の識別に使用されるカテゴリ。優先度はインパクトと緊急度に基づいており、行うべき処置に必要な時間の特定に使用される。例えば、SLAに、優先度2のインシデントは12時間以内に解決しなければならない、と記述するなど。

Private key 私有鍵　Proactive プロアクティブ　Proactive Monitoring プロアクティブなモニタ

リング(サービスオペレーション) 将来的に起こりうる障害を予知するために、イベントのパターンを待ち受けてモニタリングすること。リアクティブなモニタリングを参照。

Proactive Problem Management プロアクティブな問題管理 (サービスオペレーション) 問題管理プロセスの一部。プロアクティブな問題管理の達成目標は、見逃される可能性のある問題を識別することである。プロアクティブな問題管理では、インシデント・レコードを分析し、他のITサービスマネジメント・プロセスによって収集されたデータを使用して傾向や深刻な問題を識別する。

Problem 問題 (サービスオペレーション) 1つまたは複数のインシデントの原因。原因は、通常、問題レコードの作成時には未知であり、問題管理プロセスがその先の調査に対する責任を負う。

Problem analysis 問題分析　Problem Control 問題コントロール（問題管理）問題管理プロセスの一部。問題コントロールは、根本原因を識別し、問題に対するワ

ークアラウンドまたは構造的な解決策を策定することを責務とする活動である。エラー･コントロールを参照。

Problem diagnosis 問題診断、問題の診断　Problem Management 問題管理 (サービスオペレーション) すべての問題のライフサイクルを管理することを責務とするプロセス。問

題管理の主要な達成目標は、インシデントの発生を防ぎ、また防止できないインシデントのインパクトを最小限に抑えることである。

Problem manager 問題マネージャ　Problem processing 問題処理　Problem Record 問題レコード (サービストランジション) 変更の詳細を含むレコード。各問題レコードには、単一の問題のライフサ

イクルが記録される。Procedure 手順活動の達成方法を指定するステップを記載した文書。手順は、プロセスの一部として定義される。

作業指示書を参照。

Process プロセス特定の達成目標を実現するために設計された、体系的な一連の活動。プロセスでは、1つまたは複数の定義済みインプットを受け取り、定義済みアウトプットに変換する。プロセスには、アウトプットを確実に提供するために必要とされる役割、責任、手段、および管理コントロールなどが含まれる場合がある。また、プロセスでは、必要に応じて方針、標準、指針、活動、および作業指示を定義できる。

Process Control プロセス・コントロール効果的、効率的、かつ一貫的にプロセスを実行することを達成目標として、プロセスを計画立案して統制する活動。

Process improvement plan プロセス改善計画　Process Manager プロセス・マネージャプロセスの運用管理を責務とする役割。プロセス・マネージャの責任には、プロセスの実行、モニタ

リング、および報告に必要とされるすべての活動の計画立案と調整が含まれる。1つのプロセスに複数のプロセス・マネージャがいる場合がある。例えば、拠点ごとの変更マネージャや、データセンタごとのITサービス継続性マネージャなど。プロセス・マネージャの役割は、プロセス・オーナの役割を担う人に割り当てられることが多いが、大規模な組織では、これらの役割は分離される場合がある。

Process Maturity プロセスの成熟度プロセスの信頼性、効率性、有効性、および他のプロセスとの統合の程度に関する指標。最も成熟したプロセスは、事業達成目標および事業戦略と正式に整合されており、継続的改善の枠組みによってサポートされている。

Process model プロセス・モデル　Process Owner プロセス・オーナプロセスが目的に適しているようにすることを責務とする役割。プロセス・オーナの責任には、プロ

セスとその測定基準に対する後援、設計、変更管理、および継続的改善が含まれる。この役割は、プロセス・マネージャの役割を担う人に割り当てられることが多いが、大規模な組織では、これらの役割は分離される場合がある。

Procurement 調達　Product 製品　Production （活動の場合）作成、（実

稼働を意味する場合）本番、（活動の場合)製造、生産など

　

Production Environment 本番環境稼働環境の同義語。Production plan 生産計画、製造計画　Profit Centre プロフィット・センタ (サービスストラテジ) 提供したサービスに対して課金する事業部門。プロフィット・センタは、利益の

獲得、コストの回収を達成目標として設立できる。そうでない場合は赤字運営となる。ITサービス・プロバイダは、コスト・センタとしても、プロフィット・センタとしても運営できる。

pro-forma 雛型テンプレート、または実際の値が入手可能になったときに置き換えられるデータ例を含む文書例。

Programme プログラム関連する複数の達成目標およびその他の成果全体を実現するために、一緒に計画され管理される複数のプロジェクトおよび活動。

Project プロジェクトある達成目標やその他の成果を実現するために必要とされる人材や他の資産を含む、一時的な組織。プロジェクトごとにライフサイクルがあり、一般的に、開始、計画立案、実行、クローズなどが含まれる。プロジェクトは、通常、PRINCE2などの正式な方法論を使用して管理される。

Project management プロジェクト管理　



用語用語定義／備考Projected Service Availability (PSA) サービスの予測可用性

（PSA）（変更管理）将来的な変更スケジュール（FSC）に基づいて、合意済みサービスレベルに対して計画されている変更の影響を示す文書。

Projected Service Outage (PSO) サービスの計画停止（PSO）

(サービストランジション) 計画された変更、保守活動、およびテスト計画による、合意されたサービスレベルへの影響を示す文書。

PRojects IN Controlled Environments (PRINCE2)

PRojects IN Controlled Environments（PRINCE2）

PRINCE2を参照。

Provider プロバイダ　Public key 公開鍵　Public Key Infrastructure (PKI) 公開鍵基盤（PKI）　Qualification 検定 (サービスストラテジ) ITインフラストラクチャが、アプリケーションまたはITサービスをサポートする

のに適切であり、かつ正しく構成されていることを確認する活動。妥当性確認を参照。

Quality 品質製品、サービス、またはプロセスが、意図された価値を提供する能力。例えば、あるハードウェア・コンポーネントが期待されたとおりに動作し、必要とされる信頼性を提供する場合、このハードウェア・コンポーネントは高品質だと見なすことができる。プロセスの品質にも、有効性および効率性をモニタし、必要に応じてそれらを改善する能力が要求される。品質管理システムを参照。

Quality Assurance (QA) 品質保証（QA） (サービストランジション) 製品、サービス、またはプロセスの品質が、意図された価値を提供するようにすることを責務とするプロセス。

Quality control 品質コントロール　Quality level 品質レベル　Quality management 品質管理　Quality Management System (QMS) 品質管理システム（QMS） (継続的サービス改善) 組織によって実行されるすべての作業が、事業達成目標またはサービス

レベルを確実に満たすために適切な品質を備えているようにすることを責務とする一式のプロセス。ISO 9000を参照。

Quality of Service サービスの品質　Quality plan 品質計画　Quality policy 品質方針　Quality review 品質レビュー　Quality surveillance 品質査察　Quality system 品質システム　Quality system review 品質システムのレビュー　Query 問い合わせ、質問　Quick Win 即効性のある成果 (継続的サービス改善) 比較的少ないコストと労力によって、短期間で投資収益率を達成すると予想

される改善活動。パレートの法則を参照。

RACI RACI (サービスデザイン) (継続的サービス改善) 役割と責任の定義を支援するために使用されるモデル。RACIは、Responsible（実行責任者）、Accountable（説明責任者）、Consulted（協議先）、Informed（報告先）の略称である。利害関係者を参照。

RACI model (Responsible, Accountable, Consulted, Informed)”

RACIモデル（実行責任者、説明責任者、協議先、報告先）

　

Reactive リアクティブ　Reactive Monitoring リアクティブなモニタ

リング(サービスオペレーション) イベントが発生してから措置を講じるモニタリング。例えば、前のジョブの完了時にバッチ・ジョブを実行することや、エラーの発生時にインシデントを記録すること。プロアクティブなモニタリングを参照。

Real Charging 実際の課金（財務管理）課金方針の1つ。ITサービス提供に対する支払いとして、顧客からITサービス・プロバイダに実際の金銭の振込が行われる。概念上の課金を参照。

Reciprocal Arrangement 相互協定 (サービスデザイン) 復旧オプションの1つ。緊急時にリソースを共有するために、2つの組織間で交わす合意。例えば、コンピュータ室のスペースや、メインフレームの使用など。

Record レコード、(動詞の場合)報告する

プロセスまたは活動の結果やその他のアウトプットを含む文書。レコードは、活動が行われたという事実の証拠であり、紙または電子文書の場合がある。例えば、監査レポート、インシデント・レコード、または会議の議事録など。

Recoverability 復旧可能性　Recovery 復旧 (サービスデザイン) (サービスオペレーション) 構成アイテムまたはITサービスを、稼働状態に戻す

こと。ITサービスの復旧には、データを一貫した既知の状態に復旧する作業が含まれることが多い。復旧の後、ユーザがITサービスを利用できるようになる（回復する）には、さらにステップが必要になる場合がある。

Recovery (1) - as in “regain function” 機能を元どおりにすること ― 復旧

　

Recovery (2) - as in “regain costs” (2)コストを取り戻すこと ― 回収

　

Recovery Centre 復旧センタ（ITサービス継続性管理）サードパーティが提供する、復旧中に使用する共有の固定設備。復旧オプションを参照。

Recovery Option 復旧オプション (サービスデザイン) サービスの中断に対応するための戦略。一般的に使用される戦略には、何もしない、手作業のワークアラウンド、相互協定、段階的復旧、中間的復旧、高速復旧、即時的復旧がある。復旧オプションでは、専用の設備か、複数の事業体で共有するサードパーティの設備を使用する場合がある。

Recovery Option (1) - as in “regain function”

(1)機能を元どおりにする際の選択肢 ― 復旧オプション

　

Recovery Option (2) - as in “regain costs”

(2)コストを取り戻す際の選択肢－回収オプション

　

Recovery Point Objective (RPO) 目標復旧時点（RPO） (サービスオペレーション) サービスが中断後に回復された時点で失われている可能性のある最大データ量。目標復旧時点は、障害が起こるまでの時間で表される。例えば、目標復旧時点が1日の場合は日次のバックアップで対応できるが、最大24時間分のデータが失われる可能性がある。ITサービスごとの目標復旧時点について協議、合意、文書化し、サービスデザイン計画およびITサービス継続性計画の要件として使用するべきである。

Recovery time 復旧時間　Recovery Time Objective (RTO) 目標復旧時間（RTO） (サービスオペレーション) ITサービスの中断後、その復旧に許された最長の時間。提供されるサー

ビスレベルは、通常のサービスレベル目標値未満になる場合がある。ITサービスごとに目標復旧時間について協議し、合意し、文書化するべきである。ビジネス・インパクト分析を参照。

Redundancy 冗長性耐障害性の同義語。「冗長な（Redundant）」という用語には、「使用されなくなった」または「必要なくなった」という意味もある。

Reengineering analysisServicekennismanagementsysteem (SKMS)

リエンジニアリング分析　

Reference data 参照データ　Registered Certification Body (RCB) 登録認証機関（RCB） ISO/IEC 17799やISO/IEC 20000などの公開された標準に照らした認証を行うことを認定されてい

る組織。



用語用語定義／備考Registration 登録　Registration Authority (RA) 登録機関（RA）　Relationship 関係 2人の人や2つの物の間の繋がりまたはやりとり。事業関係管理では、ITサービス・プロバイダと事業

体間のやりとり。構成管理では、2つの構成アイテム間の依存関係や接続を表す、両アイテム間のリンク。例えばアプリケーションは、それが実行されているサーバとリンクでき、ITサービスは、そのITサービスに貢献するすべてのCIとのリンクを数多く持つ。

Relationship Processes 関係プロセス事業関係管理とサプライヤ管理を含むISO/IEC 20000プロセス・グループ。Release リリース (サービストランジション) ITサービスに対して1つまたは複数の承認された変更を実施するために

必要とされる、ハードウェア、ソフトウェア、文書、プロセス、またはその他のコンポーネントの集合。各リリースの内容は、単一の実体として管理、テスト、および展開される。

Release Acceptance リリースの受け入れ（リリース管理）リリース、その実装、および切り戻し計画が事業体とIT運用の要件を確実に満たすように、それらをテストすることを責務とする活動。

Release and Deployment Management

リリース管理および展開管理

(サービストランジション) リリース管理と展開の両方を責務とするプロセス。

Release Identification リリースID (サービストランジション) リリースを一意に識別するために使用する命名規則。一般的に、リリースIDには、該当する構成アイテムを示す部分とバージョン番号が含まれる。例えば、Microsoft Office 2003 SR2など。

Release Management リリース管理 (サービストランジション) テスト環境および稼働環境へのリリースの移行を計画立案、スケジューリング、およびコントロールすることを責務とするプロセス。.リリース管理の主要な達成目標は、稼働環境の完全性が守られ、正しいコンポーネントがリリースされるようにすることである。リリース管理は、リリース管理および展開管理プロセスの一部である。

Release Mechanism リリース・メカニズム（リリース管理）リリースを対象の環境に展開するための方法論。リリース・メカニズムには、ハードウェア・ツールやソフトウェア・ツールとともに手順が含まれることがある。

Release notes リリース・ノート　Release package リリース・パッケージ　Release Packaging リリース・パッケージ化　Release policy リリース方針　Release Process リリース・プロセスリリース管理を含むプロセス・グループに対してISO/IEC 20000で使用される名前。このグループ

は、他のプロセスを含まない。リリース・プロセスは、リリース管理プロセスの同義語としても使用される。

Release Record リリース・レコード (サービストランジション) リリースの内容を定義する、CMDB内のレコード。リリース・レコードは、そのリリースの影響を受けるすべての構成アイテムと関係がある。

Release Type リリース・タイプ　Release Unit リリース・ユニット (サービストランジション) 通常、同時にリリースされるITサービスのコンポーネント群。リリース・ユ

ニットには、一般的に、ある有用な機能を実行するために十分なコンポーネントが含まれる。例えば、あるリリース・ユニットはデスクトップPCであり、ハードウェア、ソフトウェア、ライセンス、文書などが含まれる。また、別のリリース・ユニットは完全な給与計算アプリケーションであり、IT運用の手順およびユーザ・トレーニングが含まれる。

Release Window リリース時間帯変更時間帯の同義語。Reliability 信頼性　Remediation 修復 (サービストランジション) 変更またはリリースが失敗した後の、既知の状態への復旧。Repair 修理 (サービスオペレーション) 障害を起こした構成アイテムを交換したり修正したりすること。Repair time 修理時間　Replaceability 交換性　Report （名詞の場合）レポート、(

動詞の場合）報告する　

Repressive 抑圧的コントロール　Request for Change (RFC) 変更要求（RFC） (サービストランジション) 行うべき変更についての正式な提案。RFCには提案された変更の詳細が

記述され、紙または電子的に記録されることがある。RFCという用語は、変更レコードや変更そのものを指すように使われることが多いが、それは誤用である。

Request for Information (RFI) 情報要求（RFI）　Request for Proposal (RFP) 提案要求（RFP）　Request Fulfilment 要求実現 (サービスオペレーション) すべてのサービス要求のライフサイクルを管理することを責務とするプ

ロセス。Requirement 要件 (サービスデザイン) 必要とされるものについての正式な記述。例えば、サービスレベル要件、プロジ

ェクト要件、またはプロセスに必要とされる成果物など。要件記述書を参照。

Requirements Catalog 要件カタログ　Requirements document 要件文書　Requirements Portfolio 要件ポートフォリオ　Resilience 対障害弾力性 (サービスデザイン) 障害に耐えるか、または障害後に迅速に復旧する、構成アイテムまたはITサー

ビスの能力。例えば、アーマード・ケーブルは、圧力がかかった場合の障害に耐性がある。耐障害性を参照。

Resolution 解決 (サービスオペレーション) インシデントまたは問題の根本原因を修正するために、またはワークアラウンドを実施するために取られる処置。ISO/IEC 20000では、解決プロセスは、インシデント管理と問題管理を含むプロセス・グループである。

Resolution Processes 解決プロセスインシデント管理と問題管理を含む、ISO/IEC 20000のプロセス・グループ。Resolution time 解決時間　Resolve, to 解決する　Resource リソース (サービスストラテジ) ITサービスの提供を支援する、ITインフラストラクチャ、人材、金銭、またはそ

の他あらゆるものを指す総称。リソースは、組織の資産と見なされる。能力、サービス資産を参照。

Resource Capacity Management (RCM)

リソース・キャパシティ管理（RCM）

（キャパシティ管理）構成アイテムのキャパシティ、使用率、およびパフォーマンスを把握することを責務とするプロセス。キャパシティ計画に使用するために、データを収集、記録、および分析する。サービス・キャパシティ管理を参照。

Resource cost リソース・コスト　Resource management リソース管理　Resource requirements リソース要件　Response rate 応答率　Response Time 応答時間作業またはトランザクションを完了するまでにかかる時間の指標。キャパシティ管理では、ITインフ

ラストラクチャのパフォーマンスの指標として使用される。またインシデント管理では、電話応答または診断開始までにかかる時間の指標として使用される。



用語用語定義／備考Responsibility 責任

（accountability（説明責任）と併記の場合）実行責任

　

Responsiveness 反応性何かに対する応答にかかる時間の測定方法の1つ。これには、トランザクションに対する応答時間や、ITサービス・プロバイダがインシデントや変更要求などに応じる速さなどが挙げられる。

Restoration (of service) （サービスの）回復　Restoration of Service サービスの回復回復を参照。Restore 回復 (サービスオペレーション) インシデントの修理と復旧後に、ユーザに対するITサービスを元の状態

に戻す処置を取ること。これは、インシデント管理の主要な達成目標である。

Restore, to 回復させる、元に戻す　Retire 廃止する (サービストランジション) ITサービスやその他の構成アイテムを稼働環境から永久に取り除くこと。

廃止は、多くの構成アイテムのライフサイクルの段階の1つである。Retirement 廃止　Return on Capital Employed (ROCE) 使用総資本利益率（ROCE）（財務管理）投資に対して予測される利益の測定方法の1つ。「税引前純利益に利子を足した額」を

「総資産から流動負債を引いた額」で割って算出する。この割合は、事業アナリストが組織全体としての有効性を判断するために使用する。ITサービスまたは製品に対するあらゆる変更は、この値を改善することを期待される。費用対効果、投資評価、投資収益率を参照。

Return on Investment (ROI) 投資収益率（ROI） (サービスストラテジ) (継続的サービス改善) 投資に対して予測される利益の測定方法の1つ。最も単純には、投資の正味利益を、投資した資産の正味価値で割ったものである。正味現在価値、投資価値を参照。

Return to Normal 平常復帰 (サービスデザイン) 完全な平常運用が再開される、ITサービス継続性計画の段階。例えば、代替データセンタを使用中の場合は、この段階で主データセンタを運用状態に戻し、ITサービス継続性計画を再度発動する能力を復活させる。

Reusability 再利用性　Review レビュー変更、問題、プロセス、プロジェクトなどの評価。一般的に、レビューは、ライフサイクル内の事前定義

された時点（特にクローズ後）に実行される。レビューの目的は、すべての成果物が提供済みであることを確認し、改善の機会を特定することである。実施後のレビューを参照。

Revision 改定、(文書の場合)改訂　Rights 権限 (サービスオペレーション) ユーザまたは役割へ与えられた権利または許可。例えば、特定のデータ

を修正する権限や、変更を許可する権限などがある。

Risk リスク損害や損失を引き起こす、または達成目標を実現する能力に影響する可能性があるイベント。リスクは、脅威の可能性、その脅威に対する資産の脆弱性、およびその脅威が発生した際に資産が受けるであろうインパクトから測定される。

Risk analysis リスク分析　Risk Assessment リスク・アセスメントリスク管理の最初のステップ。事業にとっての資産の価値を分析し、それらの資産に対する脅威を

識別して、それらの脅威に対する各資産の脆弱性を評価する。リスク・アセスメントには、定量的な（数値データに基づく）ものと定性的なものがある。

Risk Management リスク管理リスクの識別、アセスメント、およびコントロールを責務とするプロセス。リスク・アセスメントを参照。

Risk Reduction Measure リスク低減手段コントロールの同義語。対策を参照。Risk Treatment リスク対応策 · リスク管理の一部であり、リスクを管理するための選択肢の選択と実施を責務とする。リスク対応

策の選択肢は次のとおり。リスクを低減するために、費用対効果の高いコントロールを適用するリスクを容認することを決定するリスクをもたらす可能性のある状況を未然に防ぐことによって、リスクを回避する保険に入るなどして、リスクをサードパーティに転嫁する。

Robustness 堅牢性　Role 役割個人やチームに与えられた責任、活動、および職権。役割はプロセス内で定義される。1人の個人ま

たは1つのチームに、複数の役割が与えられることがある。例えば、構成マネージャと変更マネージャの役割を1人の要員が実行するなど。

Rollout 投入 (サービストランジション) 展開の同義語。複雑または段階的な展開について、または複数の場所への展開について言及する場合に最もよく使用される。

Root Cause 根本原因 (サービスオペレーション) インシデントまたは問題の、潜在的な、または元の原因。

Root Cause Analysis (RCA) 根本原因分析（RCA） (サービスオペレーション) インシデントまたは問題の根本原因を識別する活動。通常、RCAではITインフラストラクチャの障害に注目する。サービス障害分析を参照。

Run the Business (RTB) 事業運営（RTB）　Running Costs ランニング･コスト運用コストの同義語。Safety 安全、安全性　SAM Database SAMデータベース（ソフトウェア資産管理）ソフトウェア資産管理の支援に必要なすべてのデータを含むデータベー

ス。SAMデータベースはCMDBの一部になる場合がある。Scalability スケーラビリティ ITサービス、プロセス、構成アイテムなどが、作業負荷または適用範囲が変更されても、合意済みの

機能を実行する能力。Scalable 拡張可能、調整可能　Schedule of Changes (SC) 変更スケジュール（SC）　Scope 適用範囲プロセス、手順、認証、契約などを適用する限度または範囲。例えば、変更管理の適用範囲には、す

べての稼働中のITサービスおよび関連する構成アイテムが含まれ、ISO/IEC 20000認証の適用範囲には、該当するデータセンタから提供されるすべてのITサービスが含まれる。

Second-line Support 2次サポート (サービスオペレーション) インシデントの解決と問題の調査に関与するサポート・グループ階層の2番目のレベル。レベルが進むごとに、より高度な専門的スキルや、より多くの時間やその他のリソースが費やされるようになる。

Secondment 一時的な配置（換え）　Secret key 秘密鍵　Securability 安全性　Secure library セキュア・ライブラリ　Secure store セキュア・ストア　Security セキュリティ情報セキュリティ管理を参照。Security awareness セキュリティの認知、セキュ

リティの認識　

Security incident セキュリティ・インシデント　Security level セキュリティ・レベル　Security Management セキュリティ管理情報セキュリティ管理の同義語。Security Manager セキュリティ・マネージャ情報セキュリティ・マネージャの同義語。



用語用語定義／備考Security Officer セキュリティ責任者情報セキュリティ責任者の同義語。Security plan セキュリティ計画　Security Policy セキュリティ方針情報セキュリティ方針の同義語。Security Principle セキュリティ原則（セキュリティ管理）情報セキュリティ方針における戦略的達成目標。一般的なセキュリティ原則に

は、機密性、完全性、および可用性がある。否認防止や説明責任など、その他の達成目標もセキュリティ原則になりうる。

Security section セキュリティ条項　Segregation of duties 職務の分離（セキュリティ管理）1つの活動の実行を複数の役割に分割し、それぞれ別の要員に割り当てるコン

トロール。これにより、1人の要員が脆弱性を悪用するリスクを低減する。例えば、ある要員がインプットした財務データを、別の要員が確認する。

Senior management 上級マネジメント　Separation of Concerns (SoC) 関心事の分離（SoC） (サービスストラテジ) ソリューションやITサービスの設計に対するアプローチの1つ。問題を部分に

分解し、個別に解決できるようにする。このアプローチでは、「何をするべきか」を「どのようにするべきか」と分けて考える。

Serial number 製造番号　Server サーバ (サービスオペレーション) ネットワークに接続され、他のコンピュータで使用されるソフトウェア機

能を提供するコンピュータ。Service サービス顧客に価値を提供する手段の1つ。顧客が特定のコストやリスクを負わずに、期待する成果を実現

することを促進する。Service Acceptance Criteria (SAC) サービス受け入れ基準

（SAC）(サービストランジション) ITサービスがその機能性と品質要件を満たしていること、また新しいITサービスが展開されたときにITサービス・プロバイダがそれを運用する準備ができていることを確認するために使用される一連の基準。受け入れを参照。

Service achievement サービスの実績　Service Analytics サービス分析論 (サービスストラテジ) インシデントによるビジネス・インパクトのアセスメントで使用する技法。サ

ービス分析論では、構成アイテム間の依存関係、および構成アイテムに対するITサービスの依存関係をモデル化する。

Service Asset サービス資産サービス・プロバイダのあらゆる能力またはリソース。資産を参照。Service Asset and Configuration Management (SACM)

サービス資産管理および構成管理（SACM）

(サービストランジション) 構成管理と資産管理の両方を責務とするプロセス。

Service Automation サービス自動化　Service Based SLAs サービス・ベースのSLA 　Service breach サービス違反　Service capability サービス能力　Service Capacity Management (SCM)

サービス・キャパシティ管理（SCM）

(サービスデザイン) (継続的サービス改善) ITサービスのパフォーマンスとキャパシティを把握することを責務とする活動。キャパシティ計画で使用するために、各ITサービスで使用されるリソースと、時間の経過に従った使用状況のパターンを収集、記録、および分析する。事業キャパシティ管理、コンポーネント・キャパシティ管理を参照。

Service Catalogue サービス・カタログ (サービスデザイン) 稼働中のすべてのITサービスに関する情報（展開に使用可能な情報を含む）を格納するデータベースまたは構造化された文書。サービス・カタログは、サービス・ポートフォリオの中で顧客に公開される唯一の部分であり、ITサービスの販売と提供の支援に使用される。サービス・カタログには、成果物、価格、連絡先、注文、および要求のプロセスに関する情報が含まれている。契約ポートフォリオを参照。

Service Catalogue Management (SCM)

サービス・カタログ管理（SCM）

　

Service Continuity Management サービス継続性管理 ITサービス継続性管理の同義語。Service Contract サービス契約 (サービスストラテジ) 1つまたは複数のITサービスを提供するための契約。サービス契約という用

語は、法的な契約かSLAかにかかわらず、ITサービスを提供するあらゆる合意を意味する際にも使用される。契約ポートフォリオを参照。

Service Culture サービス・カルチャ顧客重視のカルチャ。サービス・カルチャの主な達成目標は、顧客満足と、顧客がその事業達成目標を実現するように支援することである。

Service definition サービス定義　Service Delivery サービスデリバリ戦術的または戦略的な焦点を持つ、核となるITサービスマネジメント・プロセス。ITILでは、これに

はサービスレベル管理、キャパシティ管理、ITサービス継続性管理、可用性管理、およびITサービス財務管理がある。サービスデリバリは、顧客にITサービスを提供することも意味する。サービスサポートを参照。

Service Dependency Modelling サービス依存関係のモデル化

構成アイテムに対するITサービスの依存関係を視覚的に表現するための技法。

Service deployment サービスの展開　サービスデザインサービスデザイン (サービスデザイン) ITサービスのライフサイクルにおける段階の1つ。サービスデザインには多数

のプロセスと機能が含まれる。これはITIL書籍の1つの題名でもある。設計を参照。

サービスデザイン Package サービスデザイン・パッケージ

(サービスデザイン) ITサービスとその要件のすべての側面について、ライフサイクルの各段階を通して定義する文書。サービスデザイン・パッケージは、新しいITサービス、重大な変更、またはITサービス廃止のそれぞれに対して作成される。

Service Desk サービスデスク (サービスオペレーション) サービス・プロバイダとユーザ間の単一窓口。典型的なサービスデスクでは、インシデントおよびサービス要求を管理し、ユーザとの連絡も処理する。

Service Desk function サービスデスク機能　Service Evaluation サービス評価、サービス

の評価　

Service Failure Analysis (SFA) サービス障害分析（SFA） (サービスデザイン) 1回以上のITサービス中断の潜在的な原因を識別する活動。SFAでは、ITインフラストラクチャだけでなく、ITサービス・プロバイダのプロセスとツールを改善する機会を識別する。SFAは、継続的な分析のプロセスというより、時間が制限されたプロジェクトのような活動である。根本原因分析を参照。

Service Hours サービス時間 (サービスデザイン) (継続的サービス改善) 特定のITサービスが使用可能になるよう合意した期間。例えば、「月曜から金曜の午前8時から午後5時。ただし祝祭日は除く」など。サービス時間は、サービスレベル・アグリーメントに定義するべきである。

Service Improvement サービス改善　Service Improvement Plan (SIP) サービス改善計画（SIP） (継続的サービス改善) プロセスまたはITサービスに対する改善を実施するための正式な計画。Service Improvement Program(me) (SIP)

サービス改善プログラム（SIP）

　

Service Interruption サービス中断　Service Knowledge Management System (SKMS)

サービス・ナレッジ管理システム（SKMS）

(サービストランジション) ナレッジまたは情報の管理に使用される、一連のツールまたはデータベース。SKMSには、構成管理システムおよびその他のツールとデータベースが含まれる。SKMSは、ITサービスのライフサイクル全体を管理するためにITサービス・プロバイダが必要とするすべての情報を格納、管理、更新、提示する。

Service Level サービスレベル 1つまたは複数のサービスレベル目標値に照らして測定され、報告された達成度。サービスレベルという用語は、非公式にサービスレベル目標値の意味で使用されることがある。



用語用語定義／備考Service Level Agreement (SLA) サービスレベル・アグリー

メント（SLA）(サービスデザイン) (継続的サービス改善) ITサービス・プロバイダと顧客との間で交わされる合意。SLAでは、ITサービスについて記述し、サービスレベル目標値を文書化して、ITサービス・プロバイダおよび顧客の責任を規定する。単一のSLAが、複数のITサービス、または複数の顧客を対象にする場合もある。オペレーショナルレベル・アグリーメントを参照。

Service Level Management (SLM) サービスレベル管理（SLM）

(サービスデザイン) (継続的サービス改善) サービスレベル・アグリーメントの交渉と、そのサービスレベルが満たされているようにすることを責務とするプロセス。SLMは、すべてのITサービスマネジメント・プロセス、オペレーショナルレベル・アグリーメント、および外部委託契約が、合意済みサービスレベル目標値に適切であるようにすることを責務とする。SLMは、サービスレベルのモニタリングと報告を行い、顧客によるレビューを定期的に開催する。

Service level manager サービスレベル・マネージャ

　

Service Level Package (SLP) サービスレベル・パッケージ（SLP）

(サービスストラテジ) 特定のサービス・パッケージに対して定義されたレベルの有用性および保証。各SLPは、特定の事業活動パターンのニーズを満たすように設計される。サービス・ラインを参照。

Service level report サービスレベル・レポート　Service Level Requirement (SLR) サービスレベル要件（SLR） (サービスデザイン) (継続的サービス改善) ITサービスのある面に対する顧客の要件。SLRは事業達

成目標に基づいており、合意するサービスレベル目標値の交渉に利用される。

Service Level Target サービスレベル目標値 (サービスデザイン) (継続的サービス改善) サービスレベル・アグリーメントに文書化された義務。サービスレベル目標値はサービスレベル要件に基づいており、ITサービスの設計が目的に適しているようにするために必要とされる。サービスレベル目標値はSMARTであるべきで、通常はKPIに基づいている。

Service Lifecycle サービス・ライフサイクル　Service Maintenance Objective サービス・メンテナン

ス目標(サービスオペレーション) 計画的な保守活動のために構成アイテムが使用できなくなることが予測される時間。

Service Management サービスマネジメントサービスマネジメントは、顧客に対し、サービスの形で価値を提供する組織の特別な能力一式である。

Service Management Information System (SMIS)

サービスマネジメント情報システム（SMIS）

　

Service Management Lifecycle サービスマネジメント・ライフサイクル

ITサービスマネジメントに対するアプローチの1つ。ITサービスのライフサイクル全体を管理するための、さまざまな機能、プロセス、およびシステムにわたる調整とコントロールの重要性を強調している。サービスマネジメント・ライフサイクル・アプローチでは、ITサービスの戦略、設計、移行、運用、および継続的改善を考慮する。

Service Management processes サービスマネジメント・プロセス

　

Service Management Technology サービスマネジメント技術　Service Manager サービス・マネージャ 1つまたは複数のITサービスのライフサイクル全体の管理を責務とするマネージャ。サービス・マネ

ージャという用語は、ITサービス・プロバイダ内のあらゆるマネージャも指す。事業関係マネージャ、プロセス・マネージャ、アカウント・マネージャ、またはITサービス全体に責任を持つ上級マネージャを指す際に最もよく使用される。

Service objective サービス達成目標　Service opening hours サービス提供時間　サービスオペレーションサービスオペレーション (サービスオペレーション) ITサービスのライフサイクルにおける段階の1つ。サービスオペレーショ

ンには多数のプロセスと機能が含まれる。これはITILコア書籍の1つの題名でもある。運用を参照。

Service Oriented Architecture (SOA) サービス指向アーキテクチャ（SOA）

　

Service Outage Analysis (SOA) サービス停止分析（SOA）（問題管理）（可用性管理）ITサービス中断の潜在的な原因を識別する活動。SOAでは、ITインフラストラクチャだけでなく、ITサービス・プロバイダのプロセスと手段を改善する機会を識別する。SOAは、継続的な分析のプロセスというより、時間が制約されたプロジェクトのような活動である。根本原因分析を参照。

Service Owner サービス・オーナ (継続的サービス改善) 特定のITサービスの提供に対する説明責任を持つ役割。Service Package サービス・パッケージ (サービスストラテジ) 顧客への提供が可能な1つのITサービスについての詳細な説明。サービス・

パッケージには、サービスレベル・パッケージおよび1つ以上のコアサービスと補助サービスが含まれる。

Service Pipeline サービス・パイプライン (サービスストラテジ) 検討中か開発中で、まだ顧客に提供可能ではないすべてのITサービスのリストを保持するデータベースまたは構造化された文書。サービス・パイプラインでは、将来予定されているITサービスを事業体が概観できる。サービス・パイプラインはサービス・ポートフォリオの一部である。サービス・ポートフォリオ自体は、通常は顧客に公開されない。

Service Planning サービス計画立案 ITサービスの導入と廃止を責務とするプロセス。サービス計画立案には、顧客の要件の把握と、ITサービスのライフサイクルの計画立案が含まれる。ISO/IEC 20000では、このプロセスを「新規サービス又はサービス変更の計画及び導入」という。ポートフォリオ管理を参照。

Service Portfolio サービス・ポートフォリオ (サービスストラテジ) サービス・プロバイダによって管理されているすべてのサービス。サービス・ポートフォリオはすべてのサービスのライフサイクル全体の管理に使用される。サービス・ポートフォリオには、サービス・パイプライン（提案または開発中）、サービス・カタログ（稼働中または展開可能）、廃止済みサービスという3つのカテゴリがある。サービス・ポートフォリオ管理、契約ポートフォリオを参照。

Service Portfolio Management (SPM)

サービス・ポートフォリオ管理（SPM）

(サービスストラテジ) サービス・ポートフォリオの管理を責務とするプロセス。サービス・ポートフォリオ管理では、サービスを、それが提供する事業上の価値の点から検討する。

Service Potential サービス潜在力 (サービスストラテジ) ITサービス・プロバイダの能力とリソース全体の包括的な潜在的価値。Service Provider サービス・プロバイダ (サービスストラテジ) 内部顧客または外部顧客にサービスを供給する組織。サービス・プロバイダ

という用語は、ITサービス・プロバイダの略称としてよく使用される。タイプIサービス・プロバイダ、タイプIIサービス・プロバイダ、タイプIIIサービス・プロバイダを参照。

Service Provider Interface (SPI) サービス・プロバイダ・インタフェース（SPI）

(サービスストラテジ) ITサービス・プロバイダと、ユーザ、顧客、ビジネス・プロセス、サプライヤとの間のインタフェース。サービス・プロバイダ・インタフェースの分析は、ITサービスの包括的な管理の調整に役立つ。

Service provision サービス供給　Service Provisioning Optimization (SPO)

サービス供給の最適化（SPO）

(サービスストラテジ) サービス提供に別のアプローチを使用することによってコスト削減や品質向上が可能かどうかを決定するための、ITサービスに対する財務や制約の分析。

Service Quality Plan (SQP) サービス品質計画（SQP）　Service release and deployment package

サービスのリリースおよび展開パッケージ

　

Service Reporting サービス報告 (継続的サービス改善) サービスレベルに照らした達成度と傾向に関するレポートを作成および提供すること責務とするプロセス。サービス報告では、レポートの書式、内容、および頻度について、顧客と合意するべきである。

Service Request サービス要求 (サービスオペレーション) 情報や助言、または標準的な変更やITサービスへのアクセスに対するユーザからの要求。例えば、パスワードのリセットや、新しいユーザに対する標準的なITサービスの提供など。通常、サービス要求はサービスデスクが処理し、RFCの提出は要求されない。要求実現を参照。

Service solution サービス・ソリューション　



用語用語定義／備考Service Sourcing サービス・ソーシング (サービスストラテジ) サービスを内部で提供するか、または外部サービス・プロバイダにアウトソー

シングするかを決定するための戦略とアプローチ。サービス・ソーシングは、この戦略の実施も意味する。サービス・ソーシングには次のものがある。内部ソーシング－タイプIまたはタイプIIサービス・プロバイダを利用した内部サービスや共有サービス従来のソーシング－タイプIIIサービス・プロバイダを利用した、サービスの完全なアウトソーシング複数ベンダによるソーシング－タイプIIIサービス・プロバイダを利用した主アウトソーシング、コンソーシアム・アウトソーシング、または選択アウトソーシング

サービスストラテジサービスストラテジ (サービスストラテジ) ITILコア書籍の1つの題名。サービスストラテジでは、ITサービスおよびITサービスマネジメントに対する全体的な戦略を確立する。

Service Support サービスサポート運用に重点を置いた、核となるITサービスマネジメント・プロセス。これには、インシデント管理、問題管理、構成管理、変更管理、およびリリース管理がある。サービスサポートにはサービスデスクも含まれる。サービス・デリバリを参照。

サービストランジションサービストランジション (サービストランジション) ITサービスのライフサイクルにおける段階の1つ。サービストランジションには多数のプロセスと機能が含まれる。これはITIL書籍の1つの題名でもある。移行を参照。

Service Utility サービス有用性 (サービスストラテジ) 顧客の観点からの、ITサービスの機能性。ITサービスの事業上の価値は、サービス有用性（サービスが何を行うか）とサービス保証（どれだけうまく行えるか）の組み合わせによって創出される。有用性を参照。

Service Validation and Testing サービスの妥当性確認およびテスト

(サービストランジション) 新規または変更されたITサービスの妥当性確認およびテストを責務とするプロセス。サービスの妥当性確認およびテストでは、ITサービスが設計仕様に合致しており、事業体のニーズを満たすようにする。

Service Valuation サービス査定 (サービスストラテジ) ITサービス提供の合計コストと、事業体にとってのそのITサービスの全体的価値の測定方法の1つ。サービス査定は、事業体とITサービス・プロバイダがITサービスの価値に合意することを支援するために使用される。

Service value サービス価値　Service value potential サービスの潜在的価値　Service Warranty サービス保証 (サービスデザイン) ITサービスが、合意された要件を満たすことに対する確約。これは、サービスレ

ベル・アグリーメントや契約などの正式な合意である場合も、広告メッセージやブランド・イメージである場合もある。ITサービスの事業上の価値は、サービス有用性（サービスが何を行うか）とサービス保証（どれだけうまく行えるか）の組み合わせによって創出される。保証を参照。

Serviceability サービス性 (サービスデザイン) (継続的サービス改善) サードパーティ・サプライヤがその契約条件を満たす能力。この契約には、構成アイテムに対して合意したレベルの信頼性、保守性または可用性が記載される。

Shared Services Unit 共有サービス部門　Shift シフト (サービスオペレーション) 決められた期間中に特定の役割を実行する人々のグループまたはチー

ム。例えば、1日24時間利用されるITサービスをサポートするために、IT運用コントロール要員のシフトが4つあるなど。

Signature 署名　Simulation modelling シミュレーション・モデル化 (サービスデザイン) (継続的サービス改善) 構成アイテムまたはITサービスの動作を予測するため

の、詳細なモデルを作成する技法。シミュレーション・モデルは非常に正確ではあるが、作成に費用と時間がかかる。シミュレーション・モデルは、モデル化する実際の構成アイテムに模擬的な作業負荷またはトランザクションを使用して作成されることが多い。このモデルは、正確な結果が重要である場合にキャパシティ管理で使用される。シミュレーション・モデルは、パフォーマンス・ベンチマークと呼ばれることがある。

Single Point of Contact 単一窓口 (サービスオペレーション) 組織または事業部門との間に提供される、単一の一貫した連絡手段。例えば、ITサービス・プロバイダの単一窓口は、通常、サービスデスクと呼ばれる。

Single Point of Failure (SPOF) 単一障害点（SPOF） (サービスデザイン) 障害によりインシデントの原因となる可能性のあるあらゆる構成アイテムのうち、対策が施されていないもの。SPOFは、ITインフラストラクチャのコンポーネントに限らず、人、またはプロセスや活動のステップである可能性もある。障害を参照。

Skilled Service Desk スキル型サービスデスク　SLA Monitoring (SLAM) SLAモニタリング（SLAM）　SLAM Chart SLAMチャート (継続的サービス改善) サービスレベル・アグリーメント・モニタリング（SLAM：Service Level

Agreement Monitoring）チャートは、サービスレベル目標値に照らした達成度のモニタリングと報告を支援するために使用される。一般に、SLAMチャートでは、過去12か月間の各月について、達成した、違反した、または違反しそうな合意済みサービスレベル目標値をそれぞれ色分けして表す。

SMART SMART (サービスデザイン) (継続的サービス改善) サービスレベル・アグリーメントおよびプロジェクト計画における目標値が、具体的（Specific）、測定可能（Measurable）、達成可能（Achievable）、適切

（Relevant）、および適時（Timely）であるべきということを覚えやすくするための頭字語。Snapshot スナップショット (サービストランジション) 検出ツールによって捕らえられた、ある構成の現在の状態。ベンチマーク

の同義語としても使用される。ベースラインを参照。Software ソフトウェア　Software Asset Management ソフトウェア資産管理（ソフトウェア資産管理）ソフトウェア資産のライフサイクルを通した管理、コントロール、および保

護を責務とするプロセス。Software item ソフトウェア・アイテム　Software Process Improvement and Capability dEtermination (SPICE)

Software Process Improvement and Capability dEtermination（SPICE）

ソフトウェア開発に関する、独立した国際的な品質管理システム。詳細は、http://www.sqi.gu.edu.au/spice/を参照。能力成熟度モデル統合版を参照。

Software Release ソフトウェア・リリース　Source ソーシングするサービス・ソーシングを参照。Sourcing ソーシング　Sourcing organisation ソーシング組織　Spamming スパミング　Specific, Measureable, Acceptable, Realistic, Time-bound (SMART)

具体的、測定可能、達成可能、適切、適時（SMART）

　

Specification 仕様要件を正式に定義したもの。仕様は、技術的または運用上の要件を定義するために使用される場合があり、内部のものと外部のものがある。多くの公開標準は、実践のための規範と仕様で構成されている。仕様によって標準が定義される。この標準に従って組織を監査できる。

Specsheet 仕様書　Spoofing なりすまし　Stability 安定性　Stage 段階　Stakeholder 利害関係者組織、プロジェクト、ITサービスなどに利害関係を持つすべての人々。利害関係者は、活動、目標、リソ

ース、または成果物に対して利害関係を持つこともある。利害関係者には、顧客、パートナ、従業員、株主、オーナなどを含めることができる。RACIを参照。



用語用語定義／備考Standard 標準必須の要件。例えば、ISO/IEC 20000（国際標準）、UNIXの構成に対する内部のセキュリティ標準、財

務関係のレコードの維持方法に関する政府の標準など。標準という用語は、ISOやBSIなどの標準化組織が公開した実践のための規範や仕様を指す場合にも使用される。指針を参照。

Standard Change 標準的な変更 (サービストランジション) リスクが低く、比較的よくあり、手順または作業指示書に従って行われる事前承認済みの変更。例えば、パスワードのリセットや、新しい従業員に対する標準的な機器の支給など。標準的な変更の実施にRFCは必要ない。標準的な変更は、サービス要求などの別の手段によって記録および追跡される。変更モデルを参照。

Standard Cost 標準原価（財務管理）一般的な運用の実行コストについて事前定義された計算方法。例えば、デスクトップPCをユーザに提供するたびに正確なコストを計算するのではなく、デスクトップごとの標準原価を使用できる。

Standard Operating Procedures (SOP)

標準運用手順（SOP） (サービスオペレーション) IT運用管理が使用する手順。

Standardisation 標準化　Standby スタンバイ (サービスデザイン) 稼働中のITサービスを提供するためには必要とされないが、ITサービス継続

性計画をサポートするために利用可能なリソースを指す。例えば、スタンバイ・データセンタは、ホット・スタンバイ、ウォーム・スタンバイ、またはイコールド・スタンバイ対策をサポートするために維持される。

Standby arrangements スタンバイ対策　State 状態　Statement of requirements (SOR) 要件記述書（SOR）製品購入、または新しいITサービスや変更されたITサービスに対するすべての要件を記述した文

書。委任事項を参照。

Status ステータス多くの種類のレコードに必要とされるフィールドの名前。関連する構成アイテム、インシデント、問題などのライフサイクルにおける現在の段階を示す。

Status Accounting ステータスの説明構成ステータスの説明の同義語。Storage Management ストレージ管理データのライフサイクルを通した保管と維持を責務とするプロセス。Strategic 戦略的計画立案と提供における3つのレベル（戦略的、戦術的、運用上）のうち、最上位のレベル。戦略的な

活動には、全体的なビジョンを達成するための達成目標の設定と長期的な計画立案が含まれる。

Strategic Alignment Objectives Model (SAOM)

戦略的連携の目標モデル（SAOM）

成果物と要件の関係を示す図。例えば、ITサービスが事業要件をサポートし、ITインフラストラクチャが技術要件をサポートしていることを示す。

Strategic assets 戦略的資産　Strategic industry factors (SIF) 戦略的業界要因（SIF）　Strategy 戦略 (サービスストラテジ) 定義済みの達成目標を実現するために設計された戦略的な計画。Super User スーパー・ユーザ (サービスオペレーション) 他のユーザを助け、サービスデスクやITサービス・プロバイダの他の部

署との連絡を支援するユーザ。スーパー・ユーザは、通常、軽微なインシデントやトレーニングに対する支援を提供する。

Supplier サプライヤ (サービスストラテジ) (サービスデザイン) ITサービスを提供するために必要となる、商品またはサービスの供給を責務とするサードパーティ。サプライヤの例には、汎用品のハードウェアやソフトウェアのベンダ、ネットワークと通信のプロバイダ、アウトソーシング組織などがある。外部委託契約、サプライ・チェーンを参照。

Supplier and Contract Database (SCD)

サプライヤ契約データベース（SCD）

(サービスデザイン) サプライヤ契約のライフサイクルを通した管理に使用するデータベースまたは構造化された文書。SCDには、サプライヤとのすべての契約の主要な属性が格納される。SCDは、サービス・ナレッジ管理システムに含まれているべきである。

Supplier Management サプライヤ管理 (サービスデザイン) サプライヤとのすべての契約が事業のニーズに対応することと、すべてのサプライヤが契約上の義務を果たすようにすることを責務とするプロセス。

Supply Chain サプライ・チェーン (サービスストラテジ) サプライヤが実施する、バリュー・チェーン内での活動。一般的に、サプライ・チェーンには複数のサプライヤが関与し、各サプライヤが製品やサービスに価値を付加する。バリュー・ネットワークを参照。

Support サポート　Support Center サポートセンタ　Support desk サポートデスク　Support Group サポート・グループ (サービスオペレーション) 技術的スキルを有する人材のグループ。サポート・グループは、すべての

ITサービスマネジメント・プロセスで必要とされる技術サポートを提供する。技術管理を参照。

Support Hours サポート時間 (サービスデザイン) (サービスオペレーション) ユーザがサポートを利用できる期間または時間。通常、これはサービスデスクを利用できる時間を表す。サポート時間はサービスレベル・アグリーメントに定義するべきであり、サービス時間とは異なる。例えば、サービス時間が1日24時間であっても、サポート時間は午前7時から午後7時であることがある。

Supporting Service 補助サービス (サービスストラテジ) コアサービスを可能にしたり、強化したりするサービス。例えば、ディレクトリ・サービスやバックアップ・サービスなど。サービス・パッケージを参照。

SWOT Analysis SWOT分析 (継続的サービス改善) 組織内部の強みと弱み、および組織が直面する外部の機会と脅威をレビューし分析する技法の1つ。SWOTは、Strengths（強み）、Weaknesses（弱み）、Opportunities（機会）、Threats（脅威）の略称である。

System システム全体的な達成目標を実現するために連携する、多数の関連するもの。例として、次のようなものがある。コンピュータ・システム。ハードウェア、ソフトウェア、およびアプリケーションを含む管理の仕組み。一緒に計画され、管理される複数のプロセスを含む。例えば、品質管理システムデータベース管理システムまたはオペレーティング・システム。一連の関連機能を実行するために設計された、多数のソフトウェア・モジュールを含む。

System Dynamics システム力学　System Management システム管理 ITサービスマネジメントの一部。プロセスよりもITインフラストラクチャの管理を重視する。 System software システム・ソフトウェア　Tactical 戦術的計画立案と提供における3つのレベル（戦略的、戦術的、運用上）のうち、中間のレベル。戦略的な

活動には、特定の達成目標を実現するために必要な、一般的に数週間から数か月間の中期計画が含まれる。

Tag タグ (サービストランジション) カテゴリの識別に使用する短いコード。例えば、戦略を分析および比較する際に、複数の顧客成果を識別するためにEC1、EC2、EC3などのタグを使用できるだろう。タグという用語は、あるものにタグを割り当てる活動も指す。

Target Return 目標収益　Task タスク　Technical Management 技術管理 (サービスオペレーション) ITサービスのサポートとITインフラストラクチャの管理において技術スキ

ルを提供することを責務とする機能。技術管理では、必要とされるツール、プロセス、および手順だけでなく、サポート・グループの役割も定義する。

Technical Management function 技術管理機能　Technical Observation (TO) 技術観察（TO） (継続的サービス改善) サービス改善、問題の調査、および可用性管理に使用される技法。技術サポ

ート・スタッフが、ITサービスの動作とパフォーマンスをモニタリングするために集まり、改善に向けた推奨事項を作成する。



用語用語定義／備考Technical Observation Post (TOP) テクニカル・オブザベーシ

ョン・ポスト（TOP）　

Technical Service 技術サービスインフラストラクチャ・サービスの同義語。Technical Support 技術サポート技術管理の同義語。Technology components 技術コンポーネント、技

術的要素　

Telematics テレマティクス　Tender 入札　Tendering process 入札プロセス　Tension Metrics 対立バランスの測定基準 (継続的サービス改善) ある測定基準の改善が別の測定基準にマイナスの影響を及ぼす、関連する

測定基準一式。対立バランスの測定基準は、適切なバランスを確立するようにするために設計される。

Terms of Reference (TOR) 委任事項（TOR） (サービスデザイン) プロジェクトまたは活動の要件、適用範囲、成果物、リソース、およびスケジュールを規定する文書。

Test テスト (サービストランジション) 構成アイテム、ITサービス、プロセスなどが、その仕様や合意された要件に合致していることを検証する活動。サービスの妥当性確認およびテスト、受け入れを参照。

Test Environment テスト環境 (サービストランジション) 構成アイテム、構築、ITサービス、プロセスなどのテストに使用する、コントロールされた環境。

Testability 試験性、試験容易性　Third Party サードパーティ ITサービスに対するサービスレベル・アグリーメントには含まれないが、そのITサービスをうまく提

供するために必要な人、グループ、または事業体。例えば、ソフトウェアのサプライヤ、ハードウェアの保守業者、または設備部門など。一般的に、サードパーティに対する要件は、外部委託契約またはオペレーショナルレベル・アグリーメントに規定される。

Third-line Support 3次サポート (サービスオペレーション) インシデントの解決と問題の調査に関与するサポート・グループ階層の3番目のレベル。レベルが進むごとに、より高度な専門的スキルや、より多くの時間やその他のリソースが費やされるようになる。

Threat 脅威脆弱性を突く可能性のあるすべてのもの。インシデントのあらゆる潜在的な原因も、脅威と見なされる。例えば、火災は、可燃性の床材の脆弱性を突く脅威である。この用語は、情報セキュリティ管理とITサービス継続性管理だけでなく、問題管理や可用性管理などの領域でもよく使用される。

Throughput スループット (サービスデザイン) 一定時間内に実行されたトランザクション、またはその他の作業の数の指標。例えば、1時間当たり5,000通のメール送信、または1秒当たり200回のディスクI/Oなど。

Tied Users 拘束ユーザ（財務管理）内部サービス・プロバイダが提供するITサービスを使用する以外に、選択の余地がないユーザ。非拘束ユーザを参照。

Tier 層　Tier one support 第1層サポート　Tier three support 第3層サポート　Tier two support 第2層サポート　Timeliness 適時性　Tool ツール、手段　Total Cost of Ownership (TCO) 総所有コスト（TCO） (サービスストラテジ) 投資判断の支援に使用する方法論。TCOでは、構成アイテムの初期コストや

購入価格だけでなく、構成アイテムを所有するライフサイクルの全コストをアセスメントする。総利用コストを参照。

Total Cost of Utilization (TCU) 総利用コスト（TCU） (サービスストラテジ) 投資およびサービス・ソーシングに関する判断の支援に使用する方法論。TCUでは、ITサービスの利用について顧客が負担するライフサイクルの全コストをアセスメントする。総所有コストを参照。

Total Quality Management (TQM) 総合的品質管理（TQM） (継続的サービス改善) 品質管理システムにより継続的改善を管理する方法論。TQMは、組織内のすべての人々を継続的なモニタリングと改善のプロセスに関与させるカルチャを確立する。

Traceability 追跡可能性　Transaction トランザクション ITサービスにより実行される個々の機能。例えば、ある銀行口座から別の口座への送金など。単一の

トランザクションには、非常に多くのデータの追加、削除、および修正が伴う場合がある。それらすべてが正常に完了されるか、どれも実行されないかのいずれかになる。

Transaction costs 取引コスト　Transaction rate トランザクション・レート　Transfer Cost 振替経費（財務管理）振替経費は原価費目の1つであり、組織の別部署の代わりに負担した支出を記録する。

例えば、財務部が利用する外部コンサルタントに対してITサービス・プロバイダが支払いを行い、そのコストを財務部に付け替える。ITサービス・プロバイダは、これを振替経費として記録する。

Transferability 移転性　Transform the Business (TTB) 事業改革（TTB）　Transition 移行 (サービストランジション) ITサービスやその他の構成アイテムが、ライフサイクル中のあるステータ

スから次のステータスに移ることに応じた、状態の変化。Transition Planning and Support 移行の計画立案および

サポート(サービストランジション) すべてのサービストランジション・プロセスの計画立案と、それに必要なリソースを調整することを責務とするプロセス。サービストランジション・プロセスとは、変更管理、サービス資産管理および構成管理、リリース管理および展開管理、サービスの妥当性検証およびテスト、評価、ナレッジ管理である。

Transparency 透明性　Transportability 運搬性　Tree structure 木構造　Trend Analysis 傾向分析 (継続的サービス改善) 時間に関連した傾向を特定するためのデータ分析。傾向分析は、問題管理

では、共通の障害や脆弱な構成アイテムを識別するために使用され、キャパシティ管理では、将来の動作を予測するためのモデル化手段として使用される。また、ITサービスマネジメント・プロセスの欠陥を識別する管理手段としても使用される。

Trigger （名詞の場合）きっかけ、（動詞の場合）引き起こす、（名詞の場合）開始、トリガ

　

Trojan horse トロイの木馬　Trusted Third Party (TTP) 信頼できるサードパーテ

ィ（TTP）　

Tuning チューニングリソースを最も効率的に利用するための変更を計画立案することを責務とする活動。チューニングはパフォーマンス管理の一部であり、パフォーマンスのモニタリングと必要な変更の実施も含まれる。

Type I Service Provider タイプIサービス・プロバイダ

(サービスストラテジ) 事業部門に内在する内部サービス・プロバイダ。組織内に複数のタイプIサービス・プロバイダが存在する場合がある。

Type II Service Provider タイプIIサービス・プロバイダ

(サービスストラテジ) 複数の事業部門に共有ITサービスを提供する内部サービス・プロバイダ。



用語用語定義／備考Type III Service Provider タイプIIIサービス・プロ

バイダ(サービスストラテジ) 外部顧客にITサービスを提供するサービス・プロバイダ。

Unabsorbed Overhead 未配賦オーバヘッド（財務管理）ITサービスの提供にかかる、特定の顧客に均等に配賦できない間接費。例えば、ITサービス・マネージャの派遣コストや、その他の測定されていない共有リソースのコスト。通常、未配賦オーバヘッドは、全ITサービスのコストに、ある割合を上乗せして回収する。直接費、間接費、配賦オーバヘッドも参照。

Underpinning Contract (UC) 外部委託契約（UC） (サービスデザイン) ITサービス・プロバイダとサードパーティとの間で交わされる契約。サードパーティは、顧客へのITサービス提供を支援する商品またはサービスを提供する。外部委託契約では、SLAに記載された合意済みサービスレベル目標値を満たすために必要な目標値および責任を定義する。

Uninterruptible Power Supply (UPS) 無停電電源装置（UPS）　Unit Cost 単位コスト (サービスストラテジ) ITサービスの1つのコンポーネントを提供するためにITサービス・プロバイダ

が負担するコスト。例えば、1台のデスクトップPCのコストや、1つのトランザクションのコストなど。

Unskilled Service Desk 非スキル型サービスデスク　Untied Users 非拘束ユーザ（財務管理）内部サービス・プロバイダが提供するサービスを利用するか、別の供給元からサービ

スを購入するかを選択できるユーザ。拘束ユーザを参照。

Upgrade アップグレード　Upgrade notes アップグレード・ノート　Uptime 稼働時間　Urgency 緊急度 (サービストランジション) (サービスデザイン) インシデント、問題、または変更が事業体に顕著なイ

ンパクトを与えるまでに残された時間の指標。例えば、インパクトが大きいインシデントであっても、そのインパクトが会計年度末まで事業体に影響しない場合は緊急度が低い。インパクトと緊急度は、優先度を割り当てるために使用する。

Usability ユーザビリティ (サービスデザイン) アプリケーション、製品、またはITサービスの使いやすさ。ユーザビリティ要件は、要件記述書に含まれることが多い。

Use Case ユース・ケース (サービスデザイン) 必要な機能性と達成目標の定義、およびテストの設計に使用される技法。ユース・ケースでは、ユーザとITサービスまたは他のシステムとのやりとりを説明する、現実的なシナリオを定義する。変更ケースを参照。

User ユーザ ITサービスを日常的に利用する人。一部の顧客はITサービスを直接的には利用しないため、ユーザは顧客とは異なる。

User acceptance ユーザ受け入れ　User Profile (UP) ユーザ・プロファイル（UP） (サービスストラテジ) ITサービスに対するユーザの要望のパターン。各ユーザ・プロファイルには、1

つまたは複数の事業活動パターンが含まれる。User support ユーザ・サポート　User-friendliness 使いやすさ　Utility 有用性 (サービスストラテジ) 特定のニーズを満たすために、製品またはサービスによって提供される機能

性。有用性は、「何を行うか」と言い換えられることが多い。サービス有用性を参照。

Validation 妥当性確認 (サービストランジション) 新しい、または変更されたITサービス、プロセス、計画、その他の成果物が事業体のニーズを満たしていることを確認する活動。妥当性確認では、元の設計から事業要件が変更されていても、その事業要件が満たされるようにする。検証、受け入れ、検定、サービスの妥当性確認およびテストを参照。

Validity 妥当性　Value Chain バリュー・チェーン (サービスストラテジ) 顧客にとって価値のある製品またはサービスを作り出す、連鎖した複数のプ

ロセス。この連鎖内の各ステップは、前のステップに重ねて実施され、製品またはサービス全体に貢献する。バリュー・ネットワークを参照。

Value Creation 価値創出　Value for Money 投資に見合う価値（VMF）費用対効果に対する非公式の指標。VMFは、他の選択肢のコストとの比較に基づくことが多い。費

用便益分析を参照。Value Network バリュー・ネットワーク (サービスストラテジ) 複数のグループまたは組織間の複雑な関係。ナレッジ、情報、商品、サービス

の交換から価値が創出される。バリュー・チェーン、パートナシップを参照。

Value on Investment (VOI) 投資価値（VOI） (継続的サービス改善) 投資に対して予測される利益の測定方法の1つ。VOIでは、財務上の利益と無形の利益の両方を考慮する。投資収益率を参照。

value-capture 価値獲得　Variable Cost 変動費 (サービスストラテジ) ITサービスの利用量、製品の製造数、ユーザの数と種類、または事前に固定で

きないものによって異なるコスト。変動費力学を参照。Variable Cost Dynamics 変動費力学 (サービスストラテジ) ITサービス提供に寄与する数多くの複雑な変動要素によって、全体的なコス

トがどのように影響を受けるかを把握するために使用する技法。Variance 差異計画値と実測値との差。財務管理、キャパシティ管理、およびサービスレベル管理でよく使用される

が、計画が整備されているすべての領域に適用できる。Variance analysis 差異分析　Variant バリアント（構成管理）特定の属性以外、他のCIと同一の構成アイテム。バリアントは、分析用に、類似したCI同

士をグループ化するために使用する。例えば、特定モデルのラップトップに多くのバリアントがあったとしても、そのラップトップを所持するユーザを識別するために必要になる場合がある。

Vendor-Managed Use ベンダ管理下の使用（ソフトウェア資産管理）ソフトウェアのサプライヤがライセンスを管理すること。ライセンスは、顧客またはITサービス・プロバイダによって管理される場合もある（顧客管理下の使用）。

Verifiability 検証可能性　Verification 検証 (サービストランジション) 新しい、または変更されたITサービス、プロセス、計画、その他の成果物が

完全で、正確で、信頼性があり、設計仕様に合致していることを確認する活動。妥当性確認、受け入れ、サービスの妥当性確認およびテストを参照。

Verification and Audit 検証と監査 (サービストランジション) CMDB内の情報が正確であり、すべての構成アイテムが識別され、CMDBに記録されているようにすることを責務とする活動。検証には、他のプロセスの一部として行われる日常点検が含まれる。例えば、ユーザがインシデントを記録する際に、デスクトップPCの製造番号を照合することなどである。監査は、正式な定期点検である。

Version バージョン (サービストランジション) バージョンは、構成アイテムの特定のベースラインを識別するために使用する。一般的に、バージョンには、各ベースラインの順序や日付が識別可能な命名規則が使用される。例えば、給与計算アプリケーションのバージョン3には、バージョン2から更新された機能が含まれる。

Version control バージョン・コントロール　Version number バージョン番号　Virtual service desk バーチャル・サービス

デスク　

Virus ウィルス　Vision ビジョン組織が将来どのようになることを意図しているかについての説明。ビジョンは、上級マネジメンによ

って作成され、カルチャおよび戦略的なの計画立案に影響を及ぼすために利用される。



用語用語定義／備考Vital Business Function (VBF) 重要事業機能（VBF） (サービスデザイン) 事業体が成功を収めるために不可欠なビジネス・プロセスの機能。重要事業機

能は、事業継続性管理、ITサービス継続性管理、および可用性管理に関する重要な考慮事項となる。

Vulnerability 脆弱性脅威によって突かれる可能性のある弱点。例えば、開放されたファイアウォールのポート、一度も変更されたことのないパスワード、可燃性のカーペットなど。コントロールの欠如も脆弱性と見なされる。

Warm Standby ウォーム・スタンバイ中間的復旧の同義語。Warranty 保証 (サービスストラテジ) 製品またはサービスが、合意された要件を満たすことに対する約束や請け合

い。サービスの妥当性確認およびテスト、サービス保証を参照。Work in Progress (WIP) 処理中の作業（WIP）活動が開始されたが完了はしていないことを表すステータス。インシデント、問題、変更などのステ

ータスとしてよく使用される。Work Instruction 作業指示書活動を実施するために従うべきステップを厳密に規定した詳細な指示を含む文書。作業指示書の

内容は手順よりも詳細であり、非常に詳細な指示が必要な場合にのみ作成される。

Workaround ワークアラウンド (サービスオペレーション) 完全な解決策がまだ存在しないインシデントや問題のインパクトを低減または排除すること。例えば、障害が発生した構成アイテムを再起動すること。問題に対するワークアラウンドは、既知のエラー・レコードとして文書化する。問題レコードに関連付けられていないインシデントに対するワークアラウンドは、インシデント・レコードとして文書化する。

Workflow Diagram (WFD) ワークフロー図（WFD）　Workflow position ワークフロー・ポジション　Workload 作業負荷 ITサービスの識別可能な部分を提供するために必要とされるリソース。作業負荷は、ユーザ、ユーザ

のグループ、またはITサービスに含まれる機能ごとに分類できる。作業負荷は、構成アイテムとITサービスのキャパシティ、パフォーマンス、および使用率の分析と管理を支援するために使用される。作業負荷は、スループットの同義語として使用されることがある。

Workload management 作業負荷管理　Workplace 職場　



頭字語

頭字語英語日本語ACD Automatic Call Distribution 自動着信呼分配

AM Availability Management 可用性管理

AMIS Availability Management Information System 可用性管理情報システム

ASP Application Service Provider アプリケーション・サービス・プロバイダ

BCM Business Capacity Management 事業キャパシティ管理

BCM Business Continuity Management 事業継続性管理

BCP Business Continuity Plan 事業継続性計画

BIA Business Impact Analysis ビジネス・インパクト分析

BRM Business Relationship Manager 事業関係マネージャ

BSI British Standards Institution 英国規格協会

BSM Business Service Management ビジネス・サービス管理

CAB Change Advisory Board 変更諮問委員会

CAB/EC Change Advisory Board / Emergency Committee 変更諮問委員会／緊急会議

CAPEX Capital Expenditure 資本的支出

CCM Component Capacity Management コンポーネント・キャパシティ管理

CFIA Component Failure Impact Analysis コンポーネント障害インパクト分析

CI Configuration Item 構成アイテム

CMDB Configuration Management Database 構成管理データベース

CMIS Capacity Management Information System キャパシティ管理情報システム

CMM Capability Maturity Model 能力成熟度モデル

CMMI Capability Maturity Model Integration 能力成熟度モデル統合版

CMS Configuration Management System 構成管理システム

COTS Commercial off the Shelf 既製品

CSF Critical Success Factor 重要成功要因

CSI Continual Service Improvement 継続的サービス改善

CSIP Continual Service Improvement Programme 継続的サービス改善プログラム

CSP Core Service Package コアサービス・パッケージ

CTI Computer Telephony Integration コンピュータ電話統合

DIKW Data-to-Information-to-Knowledge-to-Wisdom データ・情報・知識・知恵

eSCM-CL eSourcing Capability Model for Client Organizations クライアント組織向けeソーシング能力モデル

eSCM-SP eSourcing Capability Model for Service Providers サービス・プロバイダ向けeソーシング能力モデル

FMEA Failure Modes and Effects Analysis 故障モード影響解析

FTA Fault Tree Analysis 故障樹解析

IRR Internal Rate of Return 内部収益率

ISG IT Steering Group IT運営グループ

ISM Information Security Management 情報セキュリティ管理

ISMS Information Security Management System 情報セキュリティ管理システム

ISO International Organization for Standardization 国際標準化機構

ISP Internet Service Provider インターネット・サービス・プロバイダ

IT Information Technology 情報技術

ITSCM IT Service Continuity Management ITサービス継続性管理

ITSM IT Service Management ITサービスマネジメント

itSMF IT Service Management Forum ITサービスマネジメントフォーラム

IVR Interactive Voice Response 音声自動応答

KEDB Known Error Database 既知のエラー・データベース

KPI Key Performance Indicator 重要業績評価指標

LOS Line of Service サービス・ライン

MoR Management of Risk リスクの管理

MTBF Mean Time Between Failures 平均故障間隔

MTBSI Mean Time Between Service Incidents 平均サービス・インシデント間隔

MTTR Mean Time to Repair 平均修理時間

NPV Net Present Value 正味現在価値



頭字語英語日本語OGC Office of Government Commerce Office of Government Commerce

OLA Operational Level Agreement オペレーショナルレベル・アグリーメント

OPEX Operational Expenditure 運用支出

OPSI Office of Public Sector Information Office of Public Sector Information

PBA Pattern of Business Activity 事業活動パターン

PFS Prerequisite for Success 成功の必須条件

PIR Post Implementation Review 実施後のレビュー

PSA Projected Service Availability サービスの予測可用性

QA Quality Assurance 品質保証

QMS Quality Management System 品質管理システム

RCA Root Cause Analysis 根本原因分析

RFC Request for Change 変更要求

ROI Return on Investment 投資収益率

RPO Recovery Point Objective 目標復旧時点

RTO Recovery Time Objective 目標復旧時間

SAC Service Acceptance Criteria サービス受け入れ基準

SACM Service Asset and Configuration Management サービス資産および構成管理

SCD Supplier and Contract Database サプライヤ契約データベース

SCM Service Capacity Management サービス・キャパシティ管理

SFA Service Failure Analysis サービス障害分析

SIP Service Improvement Plan サービス改善計画

SKMS Service Knowledge Management System サービス知識管理システム

SLA Service Level Agreement サービスレベル・アグリーメント

SLM Service Level Management サービスレベル管理

SLP Service Level Package サービスレベル・パッケージ

SLR Service Level Requirement サービスレベル要件

SMO Service Maintenance Objective サービス・メンテナンス目標

SoC Separation of Concerns 関心事の分離

SOP Standard Operating Procedures 標準運用手順

SOR Statement of requirements 要件記述書

SPI Service Provider Interface サービス・プロバイダ・インタフェース

SPM Service Portfolio Management サービス・ポートフォリオ管理

SPO Service Provisioning Optimization サービス供給の最適化

SPOF Single Point of Failure 単一障害点

TCO Total Cost of Ownership 総所有コスト

TCU Total Cost of Utilization 総利用コスト

TO Technical Observation 技術観察

TOR Terms of Reference 委任事項

TQM Total Quality Management 総合的品質管理

UC Underpinning Contract 外部委託契約

UP User Profile ユーザ・プロファイル

VBF Vital Business Function 重要事業機能

VOI Value on Investment 投資価値

WIP Work in Progress 処理中の作業


付録 Cシラバス（講義概要）

Student | ITIL v3 Intermediate Certification Level | Syllabus


© Crown Copyright 2008 Reproduced under license from OGC The ITIL Intermediate Qualification_Service Offerings and Agreements Certificate_v3.1.doc – 29 July 2008

Version 3.1 (Status – Live) Document owner – Chief Examiner Page 1 of 13

Document Control Information Document Details

Document Name The ITIL Intermediate Qualification: Service Offerings and Agreements Certificate_v3.1

Purpose of Document Provide a detailed syllabus for the ITIL Intermediate Qualification: Service Offerings and Agreements

Document Version Number 3.1

Document Status Live

Document Owner Chief Examiner

Prepared By V3 Examination Panel

Date of First Draft August 2007

Date Approved 29 July 2008

Approved By Chief Examiner

Next Scheduled Review Date

Version History

Version Number Date Approved Change/Reasons for Change/Comments

3.0 23 June 2008 New Document

3.1 29 July 2008 Qualification name changed from “ITIL Expert Qualification” to “ITIL Intermediate Qualification”

Bullet removed from Learning Objectives

Change to pass mark and scoring system

Inclusion of Exam Preparation unit

Unit durations changed in Units 05 and 07

Distribution List

Version Name Title/Company

3.0 All ITIL EIs and ATOs

3.1 All ITIL EIs and ATOs





Professional Qualifications for ITIL® PRACTICES FOR SERVICE MANAGEMENT: INTERMEDIATE CAPABILITY STREAM The ITIL Intermediate Qualification: Service Offerings and Agreements Certificate SYLLABUS

OGC’s Official Accreditor

The Swirl logo™ is a Trade Mark of the Office of Government Commerce ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries





THE ITIL INTERMEDIATE QUALIFICATION: SERVICE OFFERINGS AND AGREEMENTS CERTIFICATE

The ITIL Intermediate Qualification: Service Offerings and Agreements (SOA) Certificate is a free-standing qualification, but is also part of the ITIL Intermediate Capability stream, and one of the modules that leads to the ITIL Expert in IT Service Management Certificate. The purpose of this training module and the associated exam and certificate is, respectively, to impart, test, and validate the knowledge on industry practices in Service Management as documented in the ITIL Service Lifecycle core publications. The ITIL Certificate in Service Offerings and Agreements is intended to enable the holders of the certificate to apply the practices during the Service Management Lifecycle. Target Group The target group of the ITIL Certificate in Service Offerings and Agreements is:

Individuals who have attained the V3 ITIL Foundation certificate in Service Management, or the V3 Foundation Bridge certificate and who wish to advance to higher level ITIL certifications.

Individuals who require a deep understanding of ITIL Certificate in the Service Offerings and Agreement processes and how it may be used to enhance the quality of IT service support within an organisation.

IT professionals that are working within an organisation that has adopted and adapted ITIL who need to be informed about and thereafter contribute to an ongoing service improvement programme

Operational staff involved in Service Portfolio Management; Service Catalogue Management; Service Level Management; Demand Management; Supplier Management; Financial Management and Business Relationship Management who wish to enhance their role-based capabilities.

This may include but is not limited to, IT professionals, business managers and business process owners. Learning Objectives Candidates can expect to gain competencies in the following upon successful completion of the education and examination components related to this certification:

Service Management as a Practice Processes across the Service Lifecycle pertaining to the Service Offerings and Agreement

curriculum: Service Portfolio Management which provides documentation for services and prospective

services in business terms Service Catalogue Management which is concerned with the production and documentation

of the Service Catalogue from a business and a technical viewpoint Service Level Management which sets up a Service Level Agreement (SLA) structure and

ensures that all SLAs have an underpinning support structure in place Demand Management which identifies Patterns of Business Activity to enable the

appropriate strategy to be implemented Supplier Management which ensures all partners and suppliers are managed in the

appropriate way and includes contract management Financial Management which includes ensuring understanding of the service value and the

management of all financial considerations Business Relationship Managers who have responsibility to represent customers and

ensure the Service Catalogue and Portfolio have the right needs Operational activities of processes covered in other Lifecycle phases such as Incident and

Change Management





Organizing for Service Operation which describe functions to be performed within Service Offerings and Agreement

Service Offerings and Agreement roles and responsibilities Technology and Implementation Considerations Challenges, Critical Success Factors and risks CSI as a consequence of effective Service Offerings and Agreement

Prerequisite Entry Criteria Candidates wishing to be trained and examined for this qualification must already hold the ITIL

Foundation Certificate in IT Service Management (the V3 Foundation or V2 Foundation plus Bridge Certificate) which shall be presented as documentary evidence to gain admission. It is also strongly recommended that candidates:

Can demonstrate familiarity with IT terminology and understand the context of Service Offerings and Agreements management of their own business environment is strongly recommended.

Have exposure working in the service management capacity within a service provider environment, with responsibility emphasizing on at least one of the following management processes: Service Portfolio Management Service Catalogue Management Service Level Management Demand Management Supplier Management Financial Management

It is recommended that candidates are familiar with the guidance detailed in the ITIL Service Lifecycle Practices core publications prior to attending training for this certification. Eligibility for Examination To be eligible for the examination leading to an accredited ITIL Certificate in Service Offerings and Agreements, the candidate must fill the following requirements:

At least 30 contact hours (hours of instruction, excluding breaks, with an Accredited Training Organisation (ATO) or an accredited e-learning solution) for this syllabus, as part of a formal, approved training course/scheme

There is no minimum mandatory requirement but 2 to 4 years professional experience working in IT Service Management is highly desirable

Hold the ITIL V3 Foundation Certificate in IT Service Management or ITIL V2 Foundation plus the bridging certificate

It is also recommended that students should complete at a minimum 12 hours of personal study by reviewing the syllabus and the pertinent areas of the ITIL Service Management Practice core guidance publications and in particular, the Service Strategy and Service Design publications





Level of Difficulty All ITIL Service Management certifications use the Bloom’s taxonomy in both the construction of the learning units and in the examination which is based on this syllabus. A learning taxonomy is a scale of the degree of difficulty in the learning process. These levels apply to the cognitive, affective and psychomotor domains of learning but in the ITIL Qualification Scheme, we deal only with the cognitive sphere. Bloom defines six levels of learning in the COGNITIVE domain which are both sequential and cumulative. They move from the simple to the complex. This implies that in order to achieve the sixth level of learning, for example, the instructor must ensure that the previous five levels have been mastered. The KNOWING level: Here the student is able to bring to mind or remember the appropriate material. The behavioural tasks associated with this level tax the student’s memory and include such tasks as defining, recalling, listing, recognizing, describing and naming. The COMPREHENDING stage: Here the student is able to understand or grasp the meaning of what is being communicated and make use of the idea without relating it to other ideas or materials and without seeing the fullest possible meaning or translation of the idea. Behavioural tasks at this level would include stating in the students own words, giving examples of, illustrating, inferring, summarizing and interpreting. These actions involve the knowing which has taken place at the first level. The APPLYING level: Here the student should be able to use ideas, principles and theories in new, particular and concrete situations. Behavioural tasks at this level involve both knowing and comprehension and might include choosing appropriate procedures, applying principles, using an approach or identifying the selection of options. The ANALYZING level: This is the fourth level of learning described by Bloom. At this level the student is able to break down a communication (rendered in any form) into constituent parts in order to make the organization and significance of the whole clear. Breaking down, discriminating, diagramming, detecting, differentiating and illustrating are important behavioural tasks at this level and can be seen to include the previous levels of knowing, comprehending and applying. Here the significance of the constituent parts of an entity are examined in order to understand the whole more fully. The SYNTHESIS level: At this level the student is able to put back together again the various parts or elements of a concept into a unified organization or whole. This putting together again and making sense of small parts is a crucial factor in intelligence and learning. Behavioural tasks at this level would include creating, writing, designing, combining, composing, organizing, revising and planning. This level of learning in order to occur must include the first four levels – knowing, comprehending, analyzing and applying. This level of learning is probably the most intense and exciting for student and teacher alike. The EVALUATING phase: In this phase the student is able to arrive at an overview and to judge the value and relative merit of ideas or procedures by using appropriate criteria. At this level of learning the student will be able to compare, judge, appraise, justify, criticize and contrast theories, procedures, methods and concepts. This level involves mastery of the five previous levels of knowing, comprehending, applying analyzing and synthesizing. For the purposes of the ITIL Qualifications Scheme, the Blooms level will appear in each syllabus module to identify the highest level of cognitive difficulty that course content should deliver to meet the learning outcome and competence to meet the examination level of difficulty.





The following table illustrates the use of the taxonomy in ITIL professional qualifications.

Bloom Levels and taxonomy

Used by ITIL certification

Intellectual activity in learning outcome and exam proficiency

Knowing

Comprehending

ITIL Service Management

Foundation Level stream

(includes V2 – V3 Foundation Bridge

certification

The ability to recall, recite, name, and understand the meaning of ITIL terminology and basic practice fundamentals. Vernacular examples used in Syllabus: Understand; Describe; Identify

Applying Analyzing


Lifecycle Stream Capability Stream

Managing Across the Lifecycle

The ability to use the practices and concepts in a situation or unprompted use of an abstraction. Can apply what is learned in the classroom, in workplace situations. Can separate concepts into component parts to understand structure and can distinguish between facts and inferences. Vernacular examples used in Syllabus: Analyze; Demonstrate; Apply; Distinguish; Justify; Produce; Decide

Synthesis Evaluate


Managing Across the

Lifecycle – level 5 only

ITIL Service Management Professional – Advanced

Series

The ability to create patterns or structure from composite elements to achieve a new meaning or outcome. Can make judgement, weigh options of ideas and elements to justify and support an argument or case. Vernacular examples used in Syllabus: Evaluate; Justify; Summarize; Plan; Modify; Manage; Control

Intermediate stream qualifications will examine according to the Bloom level assigned to each syllabus learning unit within each of the Service Lifecycle and Service Capability streams. This means that a student must be prepared to be tested up to and including that level for any question related to that learning unit or units. The examination format of complex multiple choice will offer a scenario and questions with a corresponding series of possible answers. Each is constructed to test a student’s competency up to and including the bloom level associated to the syllabus learning unit that the question is mapped to. Instructors should ensure that the module curriculum offers discussion, practical exercises and instruction that will satisfy the competency needed to meet the exam level of difficulty. The intermediate modules are expected to provide a practical level of proficiency for a student to be able to utilize the knowledge learned in their work environment. The examinations test a level of proficiency that allows students to apply the knowledge learned in the course to correctly select the correct sequence of possible answers.





Service Offerings and Agreements Syllabus The ITIL Intermediate Qualification: Service Offerings and Agreements is awarded to those who complete the following ten units of study and successfully pass the relevant examination. The units cover the topics listed (section numbers from the source publications are included along with indicative contact study hours). ITIL SC: SOA01 Level of Difficulty – up to Bloom level 2

Introduction This unit introduces the candidate to the concepts and terminology of the Service Lifecycle and the role of SOA within the Lifecycle.

To meet the learning outcomes and examination level of difficulty, the candidates must be able to understand and describe:

the concept of Service Management as a practice (SS 2.1, ST 2.1)

the concept of Service, its value proposition and composition (SS 2.2, ST 2.2)

the functions and process across the Lifecycle (SS 2.6, ST 2.3)

the role of Processes in the Service Lifecycle (SS 2.6.2, SS 2.6.3)

how Service Management creates business value (SS 3.1, SD 2.4.3, ST 2.4.3, SO 2.4.3, CSI 3.7.2)

how the processes within the Service Offerings and Agreement curriculum supports the Service Lifecycle (SD 2.4.5, SS 5.1 up to 5.1.2, SS 5.5.1, SS 5.3 up to 5.3.1)

The recommended minimum study period for this unit is 1.5 hours.

ITIL SC: SOA02 Level of difficulty – up to Bloom level 4

Service Portfolio Management This unit covers the Service Portfolio Management process and how it contributes to Service Offerings and Agreements.

To meet the learning outcomes and examination level of difficulty, the candidates must be able to understand, describe, identify, demonstrate, apply, distinguish, produce, decide or analyze:

the Service Portfolio and illustrate its relationship with the Service Catalogue and Service Pipeline (SS 4.2.3; SS 5.1.2.3)

how a Service Portfolio describes a provider’s service and how it relates the business service with the IT service. (SS 5.3)

the Service Portfolio Management methods (SS 5.4)







Service Catalogue Management This unit covers the Service Catalogue Management process and how it is integrated with the Service Portfolio.


the purpose, goal and objectives of the process (SD 4.1.1)

the scope of the process (SD 4.1.2)

the interface to the Service Portfolio (SS 4.2.3; SD 3.6.2; SD 3.9; SD 3.10)

the difference between a Business and a Technical Service Catalogue (SD 4.1.4)

the importance of the Service Catalogue to the Service Lifecycle and the business (SS 4.2.3; SD 3.10; SD 4.1.3)

its policies, principles and basic concepts (SD 4.1.4)

the use of key metrics, challenges, critical success factors and risks associated with the process (SD 4.1.8; SD 4.1.9)

the process including the utilisation of the Service Catalogue by other processes and functions (SD 4.1.5; SD 4.1.6)

produce a Service Catalogue (SD Appendix G)



Service Level Management This unit covers the Service Level Management process and deliverables.


the purpose, goal and objectives of the SLM (SD 4.2.1)

the scope of the SLM (SD 4.2.2)

the importance of the process to the Service Lifecycle and how its generate business value (SD 4.2 up to 4.2.1, SD 4.2.3)

the principles and basic concepts (4.2.4)

the main activities, methods and techniques of this process and how it relates to the Service Lifecycle. This includes the SLA structures and determining Service Level Requirements (SD 4.2.5 up to 4.2.5.3 including figures 4.5, 4.6 and 4.7)

the deliverables from the process (SD 4.2.5.6, 4.2.5.7)

monitoring of service performance against SLAs (4.2.5.3, CSI 3.5)

the use of key metrics, challenges, critical success factors and risks associated with the process (SD 4.2.7, SD 4.2.8, SD 4.2.9)

the contents of SLAs, OLAs and review meetings (SD 4.2.5.5, 4.2.5.8, SD Appendix F)

the interfaces to other processes and functions (SD4.2.5 up to 4.2.5.1, Figure 4.5, SD 4.2.5.4,, SD 4.2.5.8, SD 4.2.5.9, SD 4.2.6)







Demand Management This unit covers the Demand Management process and how it contributes to Service Offerings and Agreements.


the basic concepts of the process (SS 5.5.1)

activity based Demand Management and business activity patterns (SS 5.5.2, SS 5.5.3, SS figure 5.23)

the interfaces to Service Portfolio (SS 5.5.2)

Managing demand for Service (SS 5.5.3, table 5.8, table 5.9)



Supplier Management This unit covers the use of the Supplier Management process and the interfaces and dependencies of the process.


the purpose, goal and objectives of the process (SD 4.7.1)

the scope of the process (SD 4.7.2)

the importance of the process to the Service Lifecycle and how they generate business value (SD 4.7.3)

the principles and basic concepts (SD 4.7.4)

the main activities, methods and techniques of this process and how it relates to the Service Lifecycle including evaluation of new suppliers (SD 4.7.5 up to SD 4.7.5.2, SD 4.7.5.3, SD 4.7.5.4, SD 4.7.5.5)

the use of Supplier Categorization and maintenance of the Suppler Database (SD 4.7.5.2)

the use of key metrics, challenges, critical success factors and risks associated with the process (SD 4.7.7, SD 4.7.9)

the inputs and outputs of the process (4.7.6)







Financial Management This unit covers how Financial Management contributes to the Service Lifecycle Operation and the basic principles of Service Economics.


the purpose, goal and objectives of the process (SS 5.1 up to 5.1.2)

the scope of the process (SS 5.1.2 up to SS 5.1.2.1)

the concepts of Service Valuation (SS 5.1.2.1, SS 5.1.3.1, SS figure 5.3)

the importance of the process to the Service Lifecycle and how they generate business value (SS 5.1 opening section, SS 5.1.1)

the various aspects of the process and the basic concepts – funding, accounting and chargeback (SS 5.1.2.5, SS 5.1.2.6, SS 5.1.2.7, SS 5.1.4.2)

Return on Investment and the business case (SS 5.2 up to 5.2.2.1, 5.2.3 up to SS 5.2.3.1)

the main activities, methods and techniques that enable this processes and how it relates to the Service Lifecycle (SS 5.1.3)

Design and Implement a Financial Management process (SS 5.1.4.3)



Business Relationship Manager

This unit covers the role of Business Relationship Manager.


the role of Business Relationship Managers (SS 4.1.3; SS 5.5.4.5)



Service Offerings and Agreement Roles and Responsibilities This unit covers how Service roles and responsibilities contribute to Service Offerings and Agreement.


key roles and responsibilities of the Service Catalogue Manager (SD 6.4.5)

key roles and responsibilities of the Service Level Manager (SD 6.4.6)

key roles and responsibilities pertaining to the Supplier Manager (SD 6.4.11)







Technology and Implementation Considerations This unit covers technology implementation as part of implementing service management process capabilities, and what special technology functions and features are related to Service Offerings and Agreement practices.


the generic requirements for technology to assist Service Design (SD 7.1)

the evaluation criteria for technology and tooling for process implementation (SD 7.2)

the good practices for practice and process implementation (SD 8.2, 8.3, 8.4)

the challenges, Critical Success Factors and risks related to implementing practices and processes (ST 9.1-9.3, SO 9.1-9.3, SD 9.1-9.2)

how to plan and implement Service Management technologies (SO 8.5)


ITIL SC: SOA11

Summary, Exam Preparation and Directed Studies This unit summarises the material covered in the previous units and prepares candidates for the examination. It is likely that most course providers will wish to offer, and review, at least one mock examination opportunity.






Note: Lecture and exercises Meeting the learning objectives of this syllabus can be assisted through the use of practical exercises during the delivery of an accredited course. It is recommended that course providers make use of exercises to enhance the reinforcement of the learning objectives in this syllabus. To aid course providers, there are areas within each learning unit whose learning objective include such phrases as “illustrate, discuss, use examples”, etc, which may be considered as opportunities to introduce practical course exercises. These are not mandated areas for practical exercises, but provided as suggestions for use by course providers. Learning outcomes Following completion of this unit, the candidate will possess knowledge of:

Understanding of the importance of Service Management as a Practice concept and Service Operation Principles, Purpose and Objective

The importance of ITIL Service Offerings and Agreements while providing service How all processes in ITIL Service Offerings and Agreement interact with other Service Lifecycle

Processes The processes, activities, methods and functions used in each of the ITIL Service Offerings and

Agreement processes How to use the ITIL Service Offerings and Agreement processes, activities and functions to

achieve operational excellence Explain how to measure ITIL Service Offerings and Agreements The importance of IT Security and its contributions to ITIL Service Offerings and Agreements Understanding of technology and implementation considerations surrounding ITIL Service

Offerings and Agreements Challenges, Critical Success Factors and Risks associated to ITIL Service Offerings and

Agreements





Format of the Examination

Type

Eight (8) multiple choice, scenario-based, gradient scored questions. Each question will have 4 possible answer options, one of which is worth 5 marks, one which is worth 3 marks, one which is worth 1 mark, and one which is a distracter and achieves no marks.

Duration Maximum 90 minutes for all candidates in their respective language (Candidates sitting the examination in a language other than their first language have a maximum of 120 minutes and are allowed to use a dictionary)

Prerequisite ITIL V3 Foundation Certificate or ITIL V2 Foundation plus Bridge Certificate and completion of an accredited Course from an ITIL Accredited Training Provider

Supervised Yes

Open Book No

Pass Score 28/40 or 70%

Distinction Score TBC

Delivery Online or Paper Based Examination Criteria of Training Competence This syllabus can only be delivered to target groups by an accredited provider / trainer. Any provider/trainer must hold the following qualifications to be eligible to provide this syllabus: Criteria Eligibility Degree of proficiency validation

Accredited Training Organization Required The company shall be registered and in good standing with the Official Accreditor

ITIL Service Offerings and Agreements Certification Required

Instructor must present a valid certificate issued by an accredited Examination Institute

ITIL V3 Expert Certification Required Instructor must present a valid certificate issued by an accredited Examination Institute

-------------------------- E N D O F D O C U M E N T ---------------------------------------


付録 D解答

Instructor | ITIL v3 Intermediate Certification Level | Exam Preparation Guide


My N otes

UNIT 2: サービス・ポートフォリオ管理

2.5　模擬試験問題解答この問題では、サービスマネジメントの意味を認識しているかどうかをテストしています。サービスマネジメントにはさまざまな分野が含まれていますが、ITILではそれらを非常に明確に定義しています。

5:a) この選択肢は、ITILがサービスストラテジ段階で定義している要素を非常によく表しています。 3: b) この選択肢はほぼ正解ですが、誤りが含まれています。ITILはサービスマネジメントに「最適なプラクティス」ではありません。サービスマネジメントには、ITILだけでなく、ほかにも多くの標準やベストプラクティスがあります。1: c) これはITILフレームワークについて述べられたものではありませんし、ITIL用語も使用されていません。0:d) この選択肢はサービスマネジメントの要素について述べていますが、完全な説明ではありません。ITILでは、ITILがサービスマネジメントの唯一の解決策であるとは述べられていません。



My N otes

UNIT 3: サービス・カタログ

3.10　模擬試験問題解答この問題では、シナリオに特有のBSMに関する知識ではなく、特にSOAに関する知識をテストしています。

3: a) この選択肢の「価値」に関する記述は正しくありません。また、選択肢bのほうが、SOAに必須の項目を詳しく説明しています。5: b) これがITILに記述されている直接的な価値提案です。これはまた、利害関係者の要求に直接的に関係しています。1:c) この選択肢では、SOAの主要な領域の一部を説明していますが、SOAがBSMの「サブプロセス」であると述べています。SOAはサブプロセスではなく、どちらかといえばBSM戦略の実現要因です。0:d) この選択肢は焦点がまったく異なり、SOAではなくBSMについて説明しています。この質問がBSMに関係するものであれば、これが最も適切な解答になります。



My N otes

UNIT 4: サービスレベル管理

4.12　模擬試験問題解答この問題では、すでに成熟したITIL組織にグローバルにSLMを導入する場合に注目するべき多くの「主要な」領域を特定できるかどうかをテストしています。

0: a) これらすべては実施すると良いものですが、いずれも具体的には顧客のニーズに重点を置いていません。また、事業が最初に重点的に取り組む必要がある他の「主要な」検討事項にも対応していません。5: b) この選択肢は、得点のある他の2つの選択肢よりもITILのプラクティスをよく表しています。この選択肢は、取締役会に提示する必要があるSLMの「主要な」領域の多くを網羅しています。1: c) この選択肢は、ポートフォリオやサービス・カタログを、ITプロバイダによって提供されるサービスの基礎と見なしていない点で、最も不適切です。3: d) これは、新しいサービスの導入に必要な領域の多くを扱っていますが、事業と顧客両者の実際の要件よりもPBAに重点を置いているので、2番目に適切な答えです。



My N otes

UNIT 5: 需要管理

5.7　模擬試験問題解答この問題では、事業のリソースに対する需要のサポートに必要な、適切な情報を取得するために、組織が取り組むべき方法を識別する際に必要となる「主要な」領域の多くを識別できるかどうかをテストしています。

5: a) この選択肢は、ITILのサービスストラテジ段階で定義されている要素をよく表しています。3:b) この答えは誤りではありませんが、選択肢aの答えのほうが多くの側面について説明しています。1:c) この答えは誤りではありませんが、迅速かつ正確なアセスメントに必要な領域に直接触れていません。0:d) 上位の情報を得る優れたアイデアと方法ですが、事業が休暇シーズンの需要に備えるために不可欠な要件を適切に収集するには、需要管理の活動について検討することが重要です。



My N otes

UNIT 6: サプライヤ管理

6.10　模擬試験問題解答

この問題では、SLMとサプライヤ・マネージャに関する知識をテストしています。これら2つのプロセスには、類似する「同様の」責任が重複して含まれている場合があります。

1: a) 前半は正しくありませんが、後半は正しいです。この質問が本当に正しいかどうかに関する課題もあります。3: b) 前半は正しいです。後半は実際にはサプライヤ・マネージャの責任です。5: c) サプライヤ・マネージャは、実際には契約、合意などの「作成」に対して責任を負いません。実際には、これらの作業の「支援」を担当します。0: d) この記述は正しくありません。



My N otes

UNIT 7: 財務管理


この問題では、シナリオに基づいて独創的に思考して、可能な最善の方法でITILのプラクティスを適用できるかどうかをテストしています。

5: a) この答えでは、最初に要件と、MoSCoW分析を活用した要件記述書について言及しています。また、顧客満足度という事業の主要な関心事にも触れています。3: b) このアプローチは近いですが、統合されたITSMツールセットが実施する必要があるMoSCoWや他の支援プロセスが考慮されていません。1: c) この答えは、広範なITILのプラクティスが不足しているため最も不適切です。しかし、サービスマネジメント・ツールの評価プロセスを活用することが推奨されています。ただ、これ以前に必要な多くの重要なステップが抜けています。0: d) この答えは、ツールセットを要件に完全に対応付ける能力があることを示していますが、それはほぼ不可能であることが知られています。次に、対処する必要のある上位3つの領域に重点を置きます。これは、「するべきでないこと」として特に記述されています。



My N otes

UNIT 8: 事業関係マネージャ


ある活動の正しいアウトプットは、次の活動に必要なインプットになるため、この問題では、サービスデザイン段階を正しい順に導入するためにITILが推奨する最善のアプローチに関する知識をテストしています。

1: a) この選択肢では、選択肢bと同様に、正しいアプローチは示されておらず、また6段階の順序は正しく記載されていません。3: b) この選択肢では、選択肢cと同様に、6段階のプロセスが示されていますが、最初のアプローチが正しく実施されていません。5: c) この選択肢では、サービスデザインを導入するための重要なアプローチと、ITILが推奨する6段階のプロセスが考慮されています。0: d) この選択肢では、品質測定に主に使用されるシックスシグマの概念について述べています。



My N otes

UNIT 9: 役割と責任


5: a) これは最適な答えです。すべての役割と責任の正しい説明が含まれています。CSIマネージャも、関与する必要のある重要な役割です。 3: b) この答えはAと同様ですが、CSIマネージャが含まれていません。この役割は重要なので含まれている必要があります。 1: c) この答えにはCSIマネージャが含まれていますが、サプライヤ・マネージャの役割とサービスレベル・マネージャの役割が混同されています。これは既存のサービスであるため、サービス・ポートフォリオで確認する必要はありません。 0: d) この答えにはCSIマネージャが含まれておらず、サプライヤ・マネージャの役割とサービスレベル・マネージャの役割が混同されています。これは既存のサービスであるため、サービス・ポートフォリオで確認する必要はありません。

itilv3 intermediate -...

Documents