5.1 サービストラジションの概要
サービス・トラジション→サービスデザインから、サービスデザインパッケージを受け取り、事業のニーズを満たすかどうかテストし、本番環境に展開し実際に運用で利用できる状態に移行する事。
変更管理・サービス資産管理・ナレッジ管理→サービス・ライフサイクルのすべてのフェーズで実行されるプロセス。
サービス・トラジションのみで実行されるプロセス→リソース管理および展開管理。移行の計画立案およびサポート、評価。サービスの妥当性確認およびテスト。 
5.2 変更管理
変更管理→標準化された手順を用いてあらゆる変更を効率的かつ迅速に処理する事。事業にもたらされるリスクを最適化するプロセス。
サービス変更→許可、計画、サポートさえているサービスやサービスの構成要素(サービス・コンポーネント)とその関連文書を追加、修正、削除すること。 
変更要求(RFC:Request for Change)→サービス変更の要求、提案のことで変更の詳細が記述されるもの。 変更理由、変更しない場合の影響、変更対象である構成アイテムのバージョンなどが含まれる。
修復計画→変更またはリリースが失敗した場合に、変更前の既知の状態に回復させる切りもどし計画のこと。
変更スケジュール→承認済みのすべての変更と詳細と変更の実施予定日をまとめた文書のことで「将来的な変更スケジュール」と呼ばれることもある。実施済みの変更情報を含む場合もある。
変更管理の7つのR→変更を評価、アセスメントするときの重要な質問のこと。①変更を要請(RAISED)したのは誰か。②変更の理由(REASON)は何か。③変更の成果(RETURN)として要求されるものは何か。④変更に伴うリスク(RISK)は何か。⑤変更を実施するために必要なリソース(RESOURCE)は何か。構築、テスト、実装の責任(RESPONSIBLE)は誰にあるか。⑦この変更と他の変更の関係(RELATIONSHIP)は何か。
変更要求の種類
→変更のインパクト大きさなどによる分類のことで「通常の変更」「標準的な変更」「緊急の変更」がある。 
通常の変更→変更管理の一般的な原則が適用される変更。変更の登録、フィルタリング、アセスメント、認可、スケジュール化、レビュー、クローズの段階を経て処理される。
標準的な変更→ビジネスへの影響度、リスク、コストが少なく変更管理によって手順が確率された(手順が承認済み)の変更。決められた手順以外の変更を実施しない。そのためRFCを必要としない場合がある。
緊急の変更→ビジネスに大きな影響を与えており、早急に変更しなければならない変更。時間が少ない状態、かつすぐにITサービスをを復旧しなければならないので別の障害をまねく可能性がある。緊急の変更は迅速に通常の変更を実施する事が大切。
変更プロセスモデル→特定の種類の変更に対処するためにとるステップを事前に定義する手法。5つのステップがある。①課題や予想外のイベント処理を含む変更を処理するステップ。②あらゆる依存性または共同処理が定義された、これらのステップの実行順序。③責任。誰が何を行うべきか。④処理の完了に対する期間としきい値。⑤エスカレーション手順。誰にいつ連絡をとるべきか。
変更マネージャ
→すべてのRFCについて受領、登録を行い優先度を割り当て必要なメンバーを招集しRFCのクローズ(すべての処置終了)まで責任を負う人。
変更諮問委員会(CAB:Change Advisory Board)→変更を許可し、変更の評価および優先度決定において変更管理を支援する機関。変更マネージャが議長を務め変更による利害関係者(顧客、ユーザ、サービスデスク、運用スタッフ、サプライヤーなど)で構成される。
変更諮問委員会のメンバー→顧客、ユーザのマネージャ、ユーザのグループ代表者、アプリケーション開発者、保守担当者、専門家、技術コンサルタント、サービスデスク、ITサービス継続性管理・キャパシティ管理・セキュリティ管理などの運用スタッフ、設備・事務サービスのスタッフ、アウトソーシングしている場合契約業者またはサードパーティの代表者など。
変更諮問委員会の検討すべき項目→提出されたRFC、変更に対する許可、変更スケジュール。
緊急変更諮問委員会(ECAB:Emergency Change Advisory Board)→緊急の変更が必要となった場合(CAB全体を招集する余裕がない場合)に召集され、緊急の意思決定を下す権限をもつ、緊急諮問委員会より小規模なグループ。
変更管理で行う9つのプロセス→①変更の計画立案とコントロール②変更のインパクトの理解③変更の意思決定と変更の許可④変更とリリーススケジュール⑤利害関係者とのコミュニケーション⑥修復計画があることの確認。⑦測定とコントロール⑧管理報告⑨継続的改善
RFCの作成、記録→追加設備を供給する事業部門や問題管理プロセスなどRFCは変更を必要とする個人、
グループである要求元から提出される。最初の変更管理の流れ。
RFCレビュー→各変更要求を検討し、「あきらかに無理なもの」「既に受け入れ済みのRFC(重複しているもの)」
「提出内容に不備があるもの」などを却下する変更管理の流れ。
変更アセスメント、評価→変更アセスメントと許可は変更許可委員が行う。
変更の許可→変更許可委員会によって変更を許可するか却下するかを決定する。
変更の実施の調整→変更許可後実施する変更管理の流れ。
変更のレビュー、クローズ→変更が完了した時点で変更管理の責任者に結果を報告し評価する。
PIR(Post Implementation Review)→変更実施後のレビューの事。
サービス資産管理および構成管理→変更の利害関係者やスタッフが構成管理システムを利用し、提案された
変更のインパクトを評価し、変更のワークフローを追跡できるようにするため、正確な構成情報に確実、迅速
容易にアクセスできるようにするプロセス。
リリース管理および展開管理→変更管理プロセスによって許可された変更をリリース管理および展開管理に
よって稼働環境にリリースされる。
問題管理→ワークアラウンドを実施したり、既知のエラーを修正したりするために変更が必要となる場合がある。
この時変更管理プロセスにRFCを提出するプロセス。
ITサービス継続性管理→「ITサービス継続性計画」は変更管理プロセスを介して更新し、常に正確かつ最新の
状態を維持し利害関係者に変更したことを認識させるおおもとのプロセス。
情報セキュリティ管理→セキュリティを維持するために必要な変更を変更管理プロセスにRFCを提出する。
キャパシティ管理→変更がキャパシティに及ぼすインパクトをアセスメントするプロセス。
需要管理→変更で事業部門の需要を満たすことができなくなることがないように適切に管理するプロセス。

5.3リソース管理および展開管理
リリース管理および展開管理→リリースをパッケージ化、構築、テストして本番環境にサービスを導入し、
サービスオペレーションへ引き継ぎ顧客に価値あを提供するプロセス。
リリース→ITサービスに対して承認された変更を実施するために必要とされる、ハードウェア、ソフトウェア、文書
プロセスなどの構成アイテムの集合。
リリース方針→組織のリリース活動に対する方針のこと。リリース管理および展開管理の役割を明確に定義し
自分の役割と権限レベルおよびプロセスに関わる他者の役割と権限レベルを理解できるようにすること。
リリースユニット→通常同時にリリースされるサービス、ITインフラストラクチャの1部分で構成ユニットをまとめた
リリースする単位のこと。
リリースパッケージ→同時にリリースするためにパッケージ化されたリリースユニット全体のこと。複数のリリース
ユニットで構成される場合もある。
5.4サービス資産管理および構成管理
サービス資産管理→サービスおよびITインフラストラクチャのコンポーネントの構成情報を正しい状態に維持し
他のプロセス活動(インシデント調査)を支援するプロセス。
構成アイテム(CI:Configuration Item)→ITサービスの提供のために管理する必要があるあらゆるコンポーネントの事で、一般にITサービス、ハードウェア、ソフトウェア、スタッフ、SLAなどの正式文書も含む。
確定版メディアライブラリ(DML:Definitive Media Library)→承認済のバージョンのソフトウェア、文書のマスターコピーを保管し、保護する1つないしは複数の場所。このライブラリには社内で開発したソフトウェア、ベンダから購入したソフトウェアの両方が含まれる。
構成モデル→確定版メディアライブラリ間の関係を含むサービス、資産およびインフラストラクチャのモデル。構成モデルを利用する事で、他のプロセスは価値ある情報を得る事ができる。①インシデントと問題のインパクト、原因のアセスメント②提案された変更のインパクトのアセスメント③新規または変更されるサービスの計画、設計④リリースおよび展開パッケージについて計画し別の場所やサービスセンターにサービスを移行⑤データセンタの統合、資産の再利用など資料の利用とコストの最適化。
構成ベースライン→正式に合意済みで変更管理プロセスで管理され将来の構成、リリース、変更のベースとして使用されるもの。
構成管理データベース(CMDB:Configuration Management Data Base)→構成アイテムを管理するデータベースのこと。他のCIとの関係も保存する。
構成管理システム(CMS:Configuration Management System)→ITサービスプロバイダの構成データの管理に使用される一連のツール、データベースのこと。
PICSV→サービス資産管理および構成管理での5つの主要活動の頭文字をとってこう記述する。
管理と計画立案(management and Planning)→構成を管理する方針、適用範囲、目標、役割、責任などの導入計画を構成管理計画として策定する事。
構成識別(configuration Identification)→マウス、HDD、キーボードなどどこまでをCIとして管理するかCIの選択基準、CIの命名規則、CIのラベル、CI同士の関係、CIのタイプなどを定義文書化すること。
構成コントロール(configuration Control)→CIの変更を追跡し、管理する事。
ステータスの説明と報告(Status accounting and reporting)→CIのステータスを追跡し、ステータスレポートを作成し報告する。
検証と監査(Verification and audit)→構成管理データベースに格納されているCIが実際に存在していることを確認、監査すること。
変更管理→構成管理システムを利用し提案された変更のインパクトを識別するプロセス。
インシデント管理と問題管理→構成管理システムを利用し故障した機器を識別し、インシデントのインパクトをアセスメントしたり、潜在的な問題によって影響を受けるユーザを識別したりするプロセス。
可用性管理→サービス資産管理および、構成管理プロセスは可用性管理の障害点の検出を支援する。
ITサービス継続性管理→構成管理システムを利用し、事業が依存している資産を認識し、重要な予備資産とソフトウェアをコントロールするプロセス。
財務管理プロセス→構成管理システムを利用し、コスト、減価償却手法、オーナ、ユーザ、保守コストと主要な財務情報を把握するプロセス。
5.5ナレッジ管理
ナレッジ管理→事業が必要とするサービスを提供およびサポートするために適切な人材が適切なブリッジをもっているようにするプロセス。①品質が改善したより効率的なサービス②サービスによってもたらされる価値についての共通の明確な理解③常に利用できる適切な情報
DIKWData to Information to knowledge to Wisdom データ、知識、知恵の間の関連を理解する方法。
サービスナレッジ管理システム(SKMS:Service knowledge Management System)→ナレッジ、情報の管理に使用される一連のツールのデータベース。知識に含まれる4つの点①スタッフの経験②気候、ユーザ数、組織の業績など③サプライヤ、パートナの要件能力④ユーザのスキルレベル 

 
スポンサードリンク