6/2 ITILｖ３への道
DML:(Definitive Media Library)
→確定版メディアライブラリ
承認済みのverのソフトウェア、文章のマスターコピーを保管・保護するライブラリ
参考)社内で開発したソフトウェア、ベンダから購入したソフトウェアの両方が含まれる
CMS:(Configuration Management System)
→構成管理システム
ITサービス・プロバイダの構成Dの管理に使用される一連のツールやDB
[事業・ビジネス要件の定義に対応するテスト]
→サービス提供、パッケージソリューションの検証
[サービス要件の定義に対応するテスト]
→サービス受入テスト
[サービスの設計に対応するテスト]
→サービスオペレーション準備状況テスト
[サービス・リリースの設計に対応するテスト]
→サービス・リリース・パッケージのテスト
リアクティブな問題管理
→インシデントが発生した後、その原因についての調査・分析を行うこと
リリース
→許可された変更を実装するために必要な新しいCI or 変更されたCIの集まりのこと
[リリースのタイプ]
→・フル・リリース
・デルタ・リリース
・パッケージ・リリース
リリース・ユニット
→同時にリリースされるITインフラストラクチャの一部分
ITインフラストラクチャ
→ITサービスを提供するための必要なソフトウェア、ハードウェア、NW、設備など
サプライヤ
→ITサービスを提供するために必要となる
ITインフラストラクチャ(ハードウェア、ソフトウェアなど)やITサービスをITサービス・プロバイダに提供する会社、組織
サプライヤ管理
→ITサービスを事業部門に途切れることなく提供できるように、サプライヤおよびサプライヤが提供するサービスを管理し、当市に見合う価値を得られるようにする
[サプライヤ管理の活動]
→・SLAを満たすようにサプライヤとの契約について協議、合意する
参考)サービスストラテジから得られた「サプライヤ戦略、方針」に従って推進
サービスストラテジ
→・ITサービスに対する戦略を立てる
・事業部門が望んでいる成果を実現したり、競合他社よりすぐれたITサービスを提供するためにITサービスやプロセスなどをどのように設計、導入、運用していけばいいか考える
参考)「サービスデザイン」「サービスストランジション」「サービスオペレーション」で実施
財務管理プロセス
→ITサービスの供給に必要な資金を確保し、コストパフォーマンス良くITサービスを供給できるように支援
需要管理プロセス
→ユーザがどのようにITサービスをしようするのかのパターンを把握し、ユーザの需要に対して適切にITサービスを供給可に調整
サービス・ポートフォリオ管理プロセス
→ITサービスが事業に提供する価値をサービス・ポートフォリオとして明確化
参考)他社が提供するITサービスと比較したときの強み、弱みなどを明確化可
SCD:(Supplier Contracts Database)
→サプライヤ契約DB。
サプライヤや契約に関する情報を管理しておくDB、文書のこと
参考)以下の情報を保存
・各サプライヤが提供するサービス製品に関する情報
・サプライヤとの契約内容
・SCDは、サービス・ナレッジ管理システム(SKMS)に含まれ、ITサービス・プロバイダに必要な情報を提供。
SKMS:(Service Management System)
→サービス・ナレッジ管理システム
ex)障害発生時にすべての担当が同じようなレベルで対処することが難しかったりする場合
参考)CMDB、既知のエラーDBなどのDB、ツールを含むが、「D」だけではなく、以下のような「知識」も合わせて管理し、意思決定する際に使用
・スタッフの経験
・天候、ユーザ数、組織の業績など
・ユーザのスキルレベル
サービス要求
→ITサービスの使い方などに対する助言や標準的な変更を求めるユーザからの要求
参考)・低リスク、低コストで発生頻度の高い小さな変更
・通常、サービスデスク、インシデント管理で処理
対応手順)事前に承認を受けて定型化しておく
セルフヘルプ
→ユーザが自らサービス要求、インシデントなどの登録やFAQの参照など、サービスデスクの昨日を利用可にする仕組み
要求実現
→サービス要求を処理するサービスオペレーションのプロセス
事業キャパシティ管理
→ビジネスのニーズと将来の事業計画を把握し、将来必要になるキャパシティを適切な時期に計画、実装することを目的に持つサービスデザインのプロセス
サービストランジション
→サービスデザインで設計したITサービスを開発環境や本番環境へ導入
参考)サービス・ポートフォリオの構成要素ではない
トリガー
→プロセスの活動を開始するきっかけ
参考)「入力」の1つ
VBF:(Vital Business Function)
→重要ビジネス機能。
ITサービスを構成する特に重要かつ不可欠な機能を指す。
参考)1つのサービスの中でも重要性は機能によってかわる
拡張版インシデント・ライフサイクル
→障害発生時に行う、インシデントの検出、診断、修理、復旧、回復
参考)各段階のダウンタイムを分析、ダウンタイムを減少させる活動を行う。
ex)
「検出」段階
→運用ツールを使い障害検地時間を短くする
「診断」段階
→KEDBを参照し、できるだけ早く原因究明
「修理」段階
→部品の予備をあらかじめ用意しておくなど
ダウンタイム
→回復時間、MTRS(保守性)
サービス性
→ITサービス・プロバイダが提供するITサービス、ITインフラストラクチャの可用性、信頼性、保守性を考える
SPO:(Single Point of Contact)
→単一窓口
参考)多岐にわたる情報を管理する必要有
SDP：
→サービスデザイン・パッケージ
設計活動の成果物のドキュメント一式のこと。
参考)ITサービスの設計内容に加え、ライフサイクルの構造の導入
運用段階で必要となるサービスのあらゆる事項が盛り込まれている。
ex)SDPには、以下の内容を含める
・要件(事業要件、サービスの活用方法や場所、サービスの事業窓口など)
・設計(サービスの機能要件、サービスレベル要件、運用管理要件)
・サービス・ライフサイクル計画
(サービス移行の計画、運用に関する全体的な戦略など)
このように作成されたSDPは、サービスストランジションに渡され、サービスが導入、テストされる
4つのP
→人材(People)、プロダクト(Products)、パートナ(Partners)、プロセス(Processec)
参考)バランスよく配置し運用していくことが大切
・人材(People)
→スタッフの能力やスキル
・プロダクト(Products)
→サービス、使用するツール(管理システム)、技術など
・パートナ(Partners)
→サービスを提供する時に地洋するメーカ、ベンダ、サプライヤなど
・プロセス(Processes)
→サービス設計時の役割、活動
[SDの5つの側面]
→以下の5つを設計する
・サービス・ソリューションの設計
・プロセスの設計
・測定方法と測定基準の設計
・技術アーキテクチャの設計
・支援的な仕組みの設計(特にサービス・ポートフォリオ)
注意)サービスの設計だけでなく、プロセス、役割や測定基準など、サービスを導入、運用するために必要な内容も合わせて設計
上記のメリット)・サービスストランジションで円滑にサービスを導入可
・サービス・ライフサイクルの構造の段階で発生する問題を最小限に抑える
SDツール
→・サービスや関連するコンポーネント設計を行うツール
参考)以下を設計可。設計支援ツールと考えればOK
・ハードウェア設計
・ソフトウェア設計
・環境設計
・プロセス設計
・D設計
[SDツールの利点]
→SDツール導入によって、設計の迅速化、標準と規約の遵守の徹底などの利点が得られる
メリット)
・設計プロセスの迅速化
・標準と規約の遵守の徹底
・プロトタイプ作成、モデル化、シュミレーション機能の提供
・What-If分析
・導入前に設計を検証可能
特に重要)
→「標準と規約の遵守の徹底」
ルール化することで誰が設計してもアウトプットを均一にできるメリット
BCM:Business Continuty Management
→事業継続性管理。
参考)
・ITサービス継続性管理の上位に位置つけられる。
・事業を構成するサービスを対象
・ITサービス継続性はBCMプロセスの一部であり、事業に対するITサービスの継続性を確実にする活動を行う
BIA:Business Impact Analysis
→ビジネス・インパクト分析
各業務の停止が、ビジネスにどの程度のインパクトを与えるのかを分析
メリット)ビジネスへのインパクトが大きい業務から優先的に復旧していくことが可能
リスク・アセスメント
→事業にとっての資産の価値を分析し、資産に対する脅威を識別して、脅威に対する脆弱性を評価
ex)脆弱であっても、資産の評価が低ければ大した脅威ではない
重要)リスクを正しく評価し、継続性管理のために適正なコストをかけること
ECAB:Emergency Change Advisory Board
→緊急変更諮問委員会
RFCの重要度や緊急度によって、CABメンバーを収集する余裕がないとき、緊急の意思決定を下す権限をもつCABより小規模なグループ
参考)決定が属人的にならないように、日ごろから合意された基準を文章化
CAB:Change Advisory Board
→変更諮問委員会
変更を許可し、変更の評価および優先度決定において変更管理を支援するための機関
議長)変更マネージャ
変更による利害関係者)顧客、サービスデスク、運用スタッフ、サプライヤで構成
参考)変更は1つずつ行われるべきであり、同時に複数の変更は行うべきではない。
CABメンバーが検討すべき項目を以下に
・提出されたすべてのRFC
・変更に対する許可
・変更スケジュール
DIKW:Data-to-Information-to-Khowledge-to-Wisdom
→データ-情報-知識-知恵
詳細)
「D」
→個別の事実であり整理されていない単なる事実のこと
インシデントex)
→「製品Aで2009年6月にインシデントが発生した」というような単なる事実。
「情報」
→「D」を整理したもの
インシデントex)「2009年6月のインシデント発生件数は60件」「製品Bに関するインシデントは20件」など月ごとや製品ごとにインシデント発生件数を集計
「知識」
→「情報」を分析してわかる傾向のこと
インシデントex)
→「月末のインシデント発生件数は多くなる傾向がある」、「製品Bはいつも使い方に関する問い合わせが多い」というような傾向
「知恵」
→いくつかの「知識」をもとに意思決定する際の「人間の知恵」のこと
インシデントex)
→「製品Bは使い方の問い合わせが多いので、顧客ユーザに製品Bの操作教育を実施する」
「製品BのGUIの使い勝手を改善する」といった意思決定する際の人間の知恵
KPO:Knowledge Process Out sourcing
→ナレッジ・プロセス・アウトソーシング
参考)
・ある面でBPOを一歩進めたもの。
KPOでは、BPOをさらに、マーケット・リサーチや証券業務など、特殊で高い専門スキルやビジネスにおける分析、意思決定を必要とするビジネス・プロセスをアウトソーシングするという点が異なる。
PBA:Pattern of Business Activity
→事業活動パターン。
事業活動パターンは、ITサービス・プロバイダが事業活動を理解し、ITサービスの計画立案に使用。
→確定版メディアライブラリ
承認済みのverのソフトウェア、文章のマスターコピーを保管・保護するライブラリ
参考)社内で開発したソフトウェア、ベンダから購入したソフトウェアの両方が含まれる
CMS:(Configuration Management System)
→構成管理システム
ITサービス・プロバイダの構成Dの管理に使用される一連のツールやDB
[事業・ビジネス要件の定義に対応するテスト]
→サービス提供、パッケージソリューションの検証
[サービス要件の定義に対応するテスト]
→サービス受入テスト
[サービスの設計に対応するテスト]
→サービスオペレーション準備状況テスト
[サービス・リリースの設計に対応するテスト]
→サービス・リリース・パッケージのテスト
リアクティブな問題管理
→インシデントが発生した後、その原因についての調査・分析を行うこと
リリース
→許可された変更を実装するために必要な新しいCI or 変更されたCIの集まりのこと
[リリースのタイプ]
→・フル・リリース
・デルタ・リリース
・パッケージ・リリース
リリース・ユニット
→同時にリリースされるITインフラストラクチャの一部分
ITインフラストラクチャ
→ITサービスを提供するための必要なソフトウェア、ハードウェア、NW、設備など
サプライヤ
→ITサービスを提供するために必要となる
ITインフラストラクチャ(ハードウェア、ソフトウェアなど)やITサービスをITサービス・プロバイダに提供する会社、組織
サプライヤ管理
→ITサービスを事業部門に途切れることなく提供できるように、サプライヤおよびサプライヤが提供するサービスを管理し、当市に見合う価値を得られるようにする
[サプライヤ管理の活動]
→・SLAを満たすようにサプライヤとの契約について協議、合意する
参考)サービスストラテジから得られた「サプライヤ戦略、方針」に従って推進
サービスストラテジ
→・ITサービスに対する戦略を立てる
・事業部門が望んでいる成果を実現したり、競合他社よりすぐれたITサービスを提供するためにITサービスやプロセスなどをどのように設計、導入、運用していけばいいか考える
参考)「サービスデザイン」「サービスストランジション」「サービスオペレーション」で実施
財務管理プロセス
→ITサービスの供給に必要な資金を確保し、コストパフォーマンス良くITサービスを供給できるように支援
需要管理プロセス
→ユーザがどのようにITサービスをしようするのかのパターンを把握し、ユーザの需要に対して適切にITサービスを供給可に調整
サービス・ポートフォリオ管理プロセス
→ITサービスが事業に提供する価値をサービス・ポートフォリオとして明確化
参考)他社が提供するITサービスと比較したときの強み、弱みなどを明確化可
SCD:(Supplier Contracts Database)
→サプライヤ契約DB。
サプライヤや契約に関する情報を管理しておくDB、文書のこと
参考)以下の情報を保存
・各サプライヤが提供するサービス製品に関する情報
・サプライヤとの契約内容
・SCDは、サービス・ナレッジ管理システム(SKMS)に含まれ、ITサービス・プロバイダに必要な情報を提供。
SKMS:(Service Management System)
→サービス・ナレッジ管理システム
ex)障害発生時にすべての担当が同じようなレベルで対処することが難しかったりする場合
参考)CMDB、既知のエラーDBなどのDB、ツールを含むが、「D」だけではなく、以下のような「知識」も合わせて管理し、意思決定する際に使用
・スタッフの経験
・天候、ユーザ数、組織の業績など
・ユーザのスキルレベル
サービス要求
→ITサービスの使い方などに対する助言や標準的な変更を求めるユーザからの要求
参考)・低リスク、低コストで発生頻度の高い小さな変更
・通常、サービスデスク、インシデント管理で処理
対応手順)事前に承認を受けて定型化しておく
セルフヘルプ
→ユーザが自らサービス要求、インシデントなどの登録やFAQの参照など、サービスデスクの昨日を利用可にする仕組み
要求実現
→サービス要求を処理するサービスオペレーションのプロセス
事業キャパシティ管理
→ビジネスのニーズと将来の事業計画を把握し、将来必要になるキャパシティを適切な時期に計画、実装することを目的に持つサービスデザインのプロセス
サービストランジション
→サービスデザインで設計したITサービスを開発環境や本番環境へ導入
参考)サービス・ポートフォリオの構成要素ではない
トリガー
→プロセスの活動を開始するきっかけ
参考)「入力」の1つ
VBF:(Vital Business Function)
→重要ビジネス機能。
ITサービスを構成する特に重要かつ不可欠な機能を指す。
参考)1つのサービスの中でも重要性は機能によってかわる
拡張版インシデント・ライフサイクル
→障害発生時に行う、インシデントの検出、診断、修理、復旧、回復
参考)各段階のダウンタイムを分析、ダウンタイムを減少させる活動を行う。
ex)
「検出」段階
→運用ツールを使い障害検地時間を短くする
「診断」段階
→KEDBを参照し、できるだけ早く原因究明
「修理」段階
→部品の予備をあらかじめ用意しておくなど
ダウンタイム
→回復時間、MTRS(保守性)
サービス性
→ITサービス・プロバイダが提供するITサービス、ITインフラストラクチャの可用性、信頼性、保守性を考える
SPO:(Single Point of Contact)
→単一窓口
参考)多岐にわたる情報を管理する必要有
SDP：
→サービスデザイン・パッケージ
設計活動の成果物のドキュメント一式のこと。
参考)ITサービスの設計内容に加え、ライフサイクルの構造の導入
運用段階で必要となるサービスのあらゆる事項が盛り込まれている。
ex)SDPには、以下の内容を含める
・要件(事業要件、サービスの活用方法や場所、サービスの事業窓口など)
・設計(サービスの機能要件、サービスレベル要件、運用管理要件)
・サービス・ライフサイクル計画
(サービス移行の計画、運用に関する全体的な戦略など)
このように作成されたSDPは、サービスストランジションに渡され、サービスが導入、テストされる
4つのP
→人材(People)、プロダクト(Products)、パートナ(Partners)、プロセス(Processec)
参考)バランスよく配置し運用していくことが大切
・人材(People)
→スタッフの能力やスキル
・プロダクト(Products)
→サービス、使用するツール(管理システム)、技術など
・パートナ(Partners)
→サービスを提供する時に地洋するメーカ、ベンダ、サプライヤなど
・プロセス(Processes)
→サービス設計時の役割、活動
[SDの5つの側面]
→以下の5つを設計する
・サービス・ソリューションの設計
・プロセスの設計
・測定方法と測定基準の設計
・技術アーキテクチャの設計
・支援的な仕組みの設計(特にサービス・ポートフォリオ)
注意)サービスの設計だけでなく、プロセス、役割や測定基準など、サービスを導入、運用するために必要な内容も合わせて設計
上記のメリット)・サービスストランジションで円滑にサービスを導入可
・サービス・ライフサイクルの構造の段階で発生する問題を最小限に抑える
SDツール
→・サービスや関連するコンポーネント設計を行うツール
参考)以下を設計可。設計支援ツールと考えればOK
・ハードウェア設計
・ソフトウェア設計
・環境設計
・プロセス設計
・D設計
[SDツールの利点]
→SDツール導入によって、設計の迅速化、標準と規約の遵守の徹底などの利点が得られる
メリット)
・設計プロセスの迅速化
・標準と規約の遵守の徹底
・プロトタイプ作成、モデル化、シュミレーション機能の提供
・What-If分析
・導入前に設計を検証可能
特に重要)
→「標準と規約の遵守の徹底」
ルール化することで誰が設計してもアウトプットを均一にできるメリット
BCM:Business Continuty Management
→事業継続性管理。
参考)
・ITサービス継続性管理の上位に位置つけられる。
・事業を構成するサービスを対象
・ITサービス継続性はBCMプロセスの一部であり、事業に対するITサービスの継続性を確実にする活動を行う
BIA:Business Impact Analysis
→ビジネス・インパクト分析
各業務の停止が、ビジネスにどの程度のインパクトを与えるのかを分析
メリット)ビジネスへのインパクトが大きい業務から優先的に復旧していくことが可能
リスク・アセスメント
→事業にとっての資産の価値を分析し、資産に対する脅威を識別して、脅威に対する脆弱性を評価
ex)脆弱であっても、資産の評価が低ければ大した脅威ではない
重要)リスクを正しく評価し、継続性管理のために適正なコストをかけること
ECAB:Emergency Change Advisory Board
→緊急変更諮問委員会
RFCの重要度や緊急度によって、CABメンバーを収集する余裕がないとき、緊急の意思決定を下す権限をもつCABより小規模なグループ
参考)決定が属人的にならないように、日ごろから合意された基準を文章化
CAB:Change Advisory Board
→変更諮問委員会
変更を許可し、変更の評価および優先度決定において変更管理を支援するための機関
議長)変更マネージャ
変更による利害関係者)顧客、サービスデスク、運用スタッフ、サプライヤで構成
参考)変更は1つずつ行われるべきであり、同時に複数の変更は行うべきではない。
CABメンバーが検討すべき項目を以下に
・提出されたすべてのRFC
・変更に対する許可
・変更スケジュール
DIKW:Data-to-Information-to-Khowledge-to-Wisdom
→データ-情報-知識-知恵
詳細)
「D」
→個別の事実であり整理されていない単なる事実のこと
インシデントex)
→「製品Aで2009年6月にインシデントが発生した」というような単なる事実。
「情報」
→「D」を整理したもの
インシデントex)「2009年6月のインシデント発生件数は60件」「製品Bに関するインシデントは20件」など月ごとや製品ごとにインシデント発生件数を集計
「知識」
→「情報」を分析してわかる傾向のこと
インシデントex)
→「月末のインシデント発生件数は多くなる傾向がある」、「製品Bはいつも使い方に関する問い合わせが多い」というような傾向
「知恵」
→いくつかの「知識」をもとに意思決定する際の「人間の知恵」のこと
インシデントex)
→「製品Bは使い方の問い合わせが多いので、顧客ユーザに製品Bの操作教育を実施する」
「製品BのGUIの使い勝手を改善する」といった意思決定する際の人間の知恵
KPO:Knowledge Process Out sourcing
→ナレッジ・プロセス・アウトソーシング
参考)
・ある面でBPOを一歩進めたもの。
KPOでは、BPOをさらに、マーケット・リサーチや証券業務など、特殊で高い専門スキルやビジネスにおける分析、意思決定を必要とするビジネス・プロセスをアウトソーシングするという点が異なる。
PBA:Pattern of Business Activity
→事業活動パターン。
事業活動パターンは、ITサービス・プロバイダが事業活動を理解し、ITサービスの計画立案に使用。