ITILの中身は実務でわかってるんだけど、用語を覚えるのがしんどい。。。
ということでキーワードだけ整理。
0.サービスとサービスライフサイクル全体像
基本
ITサービスの3要素
顧客とユーザー
- 顧客 => サービスを購入する人
- ユーザー => サービスを使う人
サービス分類１
| 分類 |
ポイント |
| 顧客向けサービス |
顧客 = サービスを買う人 |
| => 外部顧客向け |
ITサービス・プロバイダの外の組織向け |
| => 内部顧客向け |
ITサービス・プロバイダの中の組織向け |
| 支援サービス |
ITサービス・プロバイダがサービスを実現するためのサービス（サービスのためのサービス） |
サービス分類２
| 分類 |
ポイント |
| コアサービス |
顧客の成果に直接つながるサービス |
| 実現サービス |
コアサービスのためのサービス |
| 強化サービス |
魅力品質を実現するためのサービス（オプション） |
| サービスパッケージ |
サービスのパッケージ |
ITサービス・プロバイダ
| 分類 |
ポイント |
| 外部サービス・プロバイダ |
顧客と異なる組織のプロバイダ |
| 内部サービス・プロバイダ |
顧客と同じ組織のプロバイダ |
| タイプI |
同じ部門内の内部サービス・プロバイダ |
| タイプII |
複数の部門向けの内部サービス・プロバイダ（シェアードサービス） |
| タイプIII |
外部顧客むけのサービス・プロバイダ |
機能、プロセス
| 用語 |
ポイント |
| 機能 |
チーム（人材）、ツール、リソース |
| プロセス |
定義されたインプットから定義されたアウトプットへの変換。測定可能性、特定の結果、顧客、特定のトリガへの応答性の４特性を持つ。 |
| プロセスモデル |
プロセスを表現したモデル |
| 閉ループシステム |
アウトプットが入力になるシステム |
役割
| 用語 |
ポイント |
| 役割 |
責任、活動、職権。１人に複数の役割もある。 |
| RACIモデル |
Responsible（実行責任）, Accountable（説明責任）, Consulted（協議先）, Informed（報告先） |
| プロセスオーナー |
プロセスが目的に適しているかに責任を負う |
| プロセスマネージャー |
プロセスの運用管理に責任を負う |
| プロセス実務者 |
プロセスを実施することに責任を負う |
| サービスオーナー |
サービスの実行責任、サービスの説明責任を負う |
サービスライフサイクル全体像
| フェーズ |
分類 |
ポイント |
| サービスストラテジ |
- |
サービスマネジメント戦略 |
|
ITサービス財務管理プロセス |
資金確保、高いROIの実現 |
|
需要管理プロセス |
ユーザーの需要に合わせた調整 |
|
サービスポートフォリオ管理プロセス |
サービスの強み弱みの明確化 |
|
事業関係管理プロセス |
顧客のニーズを満たす |
| サービスデザイン |
- |
サービスの設計 |
|
デザインコーディネーション |
サービスデザイン全体の調整 |
|
サービスカタログ管理 |
サービスの情報を管理 |
|
サービスレベル管理 |
SLAを満たす |
|
キャパシティ管理 |
キャパシティ要件を満たす |
|
可用性管理 |
可用性要件を満たす |
|
ITサービス継続性管理 |
リスクを管理し、最低限のサービスを保証 |
|
情報セキュリティ管理 |
CIAを確保 |
|
サプライヤ管理 |
サプライヤの管理 |
| サービストランジション |
- |
新規または変更したサービスの運用移行 |
|
移行の計画立案およびサポート |
移行計画とリソース確保 |
|
変更管理 |
変更実施の手順確立 |
|
リリース管理および展開管理 |
変更実施 |
|
サービス資産管理および構成管理 |
サービス資産、構成を正確に保つ |
|
ナレッジ管理 |
ノウハウの共有 |
| サービスオペレーション |
- |
サービスの運用管理実施 |
|
組織・役割 |
サービスデスク、技術管理、IT運用管理、アプリケーション管理 |
|
イベント管理 |
イベント監視と対応 |
|
インシデント管理 |
サービス中断や品質低下の事象、可能性を管理。早期解決、暫定対処 |
|
問題管理 |
根本原因の特定、解決 |
|
要求実現 |
パスワードリセットなどの要求を処理 |
|
アクセス管理 |
アクセス権限設定 |
| 継続的サービス改善 |
- |
PDCAをまわす |
1.サービスストラテジ
サービスストラテジの目的
- 有用性 => 機能が目的を満たしていること
- 保証 => キャパシティ、可用性、継続性、セキュリティなどの要件を満たすこと
サービス資産
- リソース => ITインフラ、人（単なる工数）、アプリ、情報、資金など
- 能力 => 人（知識、経験、スキル）、ナレッジ、組織、プロセス、管理などの無形資産
ITサービス財務管理プロセス
| 用語 |
ポイント |
| 会計業務 |
実コストと見積の比較と管理 |
| サービス指向IT会計 |
ITサービスごとにコストを会計する（費目ごとではない） |
| サービス査定 |
供給価値と潜在的価値を測り、価値に合意する |
| サービス供給価値 |
サービスを供給するのにかかるコスト |
| サービス潜在的価値 |
サービスの金銭価値と付加価値の合計 |
| 需要モデル |
顧客のサービス総利用コスト(TCU)の特定と将来需要の予測 |
| ビジネス・ケース |
コスト、利点、代案、リスクなどの情報で構成される支出の正当性説明資料 |
需要管理プロセス
| 用語 |
ポイント |
| 事業活動パターン(PBA) |
Pattern of Business Activity。事業活動の負荷の様子 |
| ユーザープロファイル(UP) |
ユーザーの要望のパターン。営業は社外で社内システムに接続したい、開発は社内で利用したいなど |
サービスポートフォリオ管理プロセス
| 用語 |
ポイント |
| サービスパイプライン |
開発中で顧客に提供できないサービス情報を格納するDB、文書 |
| サービスカタログ |
提供中または提供が決定して準備中のサービス情報を格納するDB、文書 |
| 廃止済みサービス |
停止、廃止したサービス |
事業関係管理プロセス
| 用語 |
ポイント |
| 事業関係マネージャー(BRM) |
Business Relationship Manager。顧客との関係維持。サービスレベルマネージャーと兼務することが多い。 |
2.サービスデザイン
概要
4P
- People
- Product
- Partner
- Process
5つの側面
- サービス・ソリューション
- ツール、サービスポートフォリオ
- 技術/管理アーキテクチャ
- プロセス
- 測定方法/基準
サービスデザインパッケージ
サービス全体の要件、設計、サービスライフサイクル計画
サービス自動化
サービスプロセスを自動化し、サービスの有用性と保証を改善
デザインコーディネーション
サービスデザイン全体の調整。
サービスカタログ管理
| 用語 |
ポイント |
| サービスカタログ |
提供中または提供が決定して準備中のサービス情報を格納するDB、文書 |
| 事業/顧客サービスカタログ |
顧客向けのサービスカタログ |
| 技術/支援サービスカタログ |
支援サービスのサービスカタログ |
サービスレベル管理
| 用語 |
ポイント |
| サービスレベル要件(SLR) |
サービスの要件 |
| SLA |
サービスレベルに関する顧客とプロバイダとの合意 |
| サービスベースのSLA |
サービス単位。顧客複数 |
| 顧客ベースのSLA |
顧客単位。複数サービス |
| マルチレベルSLA |
企業レベル、顧客レベル、サービスレベルのように階層構造で定義 |
| オペレーショナルレベルアグリーメント(OLA) |
SLA実現のために、プロバイダの組織内での交わされる合意 |
| 外部委託契約(UC) |
SLA実現のために、プロバイダと外部サプライヤとの間で交わされる契約 |
| サービスレビュー |
サービスの達成度を確認するミーティング |
| サービス改善計画(SIP) |
Service Improvement Plan |
| SLAモニタリングチャート(SLAMチャート) |
サービスレベルの達成度をモニタリングして報告する技法。Red, Amber(黄色), Greenで色分けするため、RAGチャートとも呼ばれる。 |
| サービスレベルマネージャー |
SLA, OLAを文書化し、状況を監視する責任者 |
キャパシティ管理
| 用語 |
ポイント |
| キャパシティ計画 |
需要予測、SLAを達成するための原価計算、代案を含む計画 |
| 事業キャパシティ管理 |
将来の事業要件の把握 |
| サービスキャパシティ管理 |
サービスのパフォーマンス、キャパシティの把握 |
| コンポーネントキャパシティ管理 |
コンポーネントのパフォーマンス、キャパシティの把握 |
可用性管理
| 用語 |
ポイント |
| 可用性 |
必要なときに合意した機能を利用できること |
| 信頼性 |
合意した機能をどれだけ長く実行できるか |
| 保守性 |
障害発生時にどれだけすばやく回復できるか |
| サービス性 |
サードパーティーサプライヤが持つ契約条件を満たす能力 |
| 重要事業機能(VBF) |
Vital Business Function。事業に必要不可欠な機能。 |
| 拡張版インシデントライフサイクル |
インシデントのライフサイクルの詳細。検出、診断、修理、復旧、回復。 |
ITサービス継続性管理
| 用語 |
ポイント |
| 事業継続性計画(BCP) |
Business Continuity Plan |
| 事業継続性管理(BCM) |
事業継続のリスク管理 |
| ビジネスインパクト分析(BIA) |
サービス中断のインパクトの定量化 |
| リスクアセスメント |
資産の価値、脅威、脆弱性の評価 |
| リスク分析(RA) |
リスクの識別とアセスメント |
| リスク軽減手段 |
リスク顕在化時の影響を軽減する手段 |
| 復旧オプション |
サービス中断に対応するための戦略。手作業ワークアラウンド、相互協定、段階的復旧（コールドスタンバイ：場所だけ用意）、中間的復旧（ウォームスタンバイ：場所と機器を用意）、高速復旧（ホットスタンバイ：場所と機器とデータを用意）、即時的復旧（ホットスタンバイ：バックアップセンター） |
情報セキュリティ管理
| 用語 |
ポイント |
| CIA |
機密性、完全性、可用性 |
| 情報セキュリティ方針 |
セキュリティ管理の方針 |
| ISMS |
情報セキュリティ・マネジメントシステム |
サプライヤ管理
| 用語 |
ポイント |
| コモディティサプライヤ |
価値：低、リスク：低 |
| 運用上のサプライヤ |
価値とリスクのどちらかが低 |
| 戦術的サプライヤ |
価値もリスクも中以上 |
| 戦略的サプライヤ |
価値：高、リスク：高 |
| サプライヤおよび契約管理システム(SCMIS) |
サプライヤ管理のツール、データ、情報管理システム |
| アウトソーシング |
サービスリソースを外から調達 |
| インソーシング |
サービスリソースを社内で調達 |
| コソーシング/マルチソーシング |
インとアウトのの組み合わせ |
| パートナーシップ |
提携 |
| アプリケーションサービス供給 |
ASP |
| BPO |
ビジネス・プロセスのアウトソーシング |
| KPO |
専門能力が必要な領域のBPO |
| クラウド |
SaaSなど |
3.サービストランジション
移行の計画立案およびサポート
移行計画とリソース確保
変更管理
| 用語 |
ポイント |
| 変更要求(RFC) |
Request For Change |
| 変更要求の種類 |
標準（手順が確立している）、緊急、通常（その他） |
| 変更提案 |
概要説明、ビジネス・ケース、スケジュールを含む変更提案書 |
| 変更レコード |
単一の変更ライフサイクル詳細 |
| 修復計画 |
変更失敗時の切り戻し計画 |
| 変更管理の7R |
Raised:提起、Reason:理由、Return:見返り、Risk:リスク、Resource:リソース、Responsible:責任者、Relationship:関係 |
| 変更モデル |
特定の変更の手順などが定義されたもの |
| 変更マネージャ |
変更管理の責任者 |
| 変更委員会(CAB) |
Change Advisory Board。各ステークホルダーの代表者で構成 |
| 緊急変更委員会(ECAB) |
Emergency Change Advisory Board。緊急時のCABより小規模な委員会 |
リリース管理および展開管理
| 用語 |
ポイント |
| リリースユニット |
通常、同時にリリースされるコンポーネント群 |
| リリースパッケージ |
１つのリリースに含まれる構成アイテム |
| ビッグバンリリース |
一斉リリース |
| 段階リリース |
ユーザー、場所、時間で段階リリース |
| プッシュ |
中央から配信 |
| プル |
ユーザーが必要時に取得 |
サービス資産管理および構成管理
| 用語 |
ポイント |
| 構成アイテム(CI) |
Configuration Item。ITサービス提供のために必要なもの全て |
| 確定版メディアライブラリ(DML) |
Definitive Media Library。】確定バージョン |
| 構成モデル |
CI間の関係を含むサービス、資産、インフラのモデル |
| 構成ベースライン |
合意済みのCIのスナップショット |
| 構成管理DB(CMDB) |
CIを管理するDB |
| 構成管理システム(CMS) |
構成管理用のツール、DB |
ナレッジ管理
| 用語 |
ポイント |
| DIKW |
Data:データ => Information:情報 => Knowledge:知識 => Wisdom:知恵 |
| SKMS |
Service Knowledge Management System |
4.サービスオペレーション
サービスデスク
| 用語 |
ポイント |
| 単一窓口(SPOC) |
Single Point Of Contact |
| ローカルサービスデスク |
ユーザー拠点に設置 |
| 中央サービスデスク |
複数拠点の窓口を集約したサービスデスク |
| バーチャルサービスデスク |
実際は分散している仮想的な中央サービスデスク |
| フォロー・ザ・サン |
24,365を実現するために世界中に分散させる |
| インシデントオーナーシップ |
受け付けたところがクローズまでの責任をもつこと |
技術管理
ITインフラの技術を担当する組織
IT運用管理
SLAを満たすようにITインフラを管理する組織
アプリケーション管理
アプリを管理する組織
イベント管理
| 用語 |
ポイント |
| イベント重要度 |
情報、警告、例外 |
| アラート |
人の処理が必要な、人に向けた通知 |
インシデント管理
早期解決、暫定対処を優先し、根本原因解決はしない。根本原因解決は問題管理で行う。
| 用語 |
ポイント |
| インシデント |
サービス中断や品質低下の事象、可能性 |
| インシデントモデル |
特定のインシデントの定義済み対処手順 |
| 優先度 |
インパクトと緊急度にもとづいて決定される |
| 機能エスカレーション |
専門知識を持つ部隊へのエスカレーション |
| 階層エスカレーション |
上位の管理者へのエスカレーション |
| 1,2,3次サポート |
1次:サービスデスク、2,3次:専門知識を持つ部隊 |
| プロセス |
識別 => 記録 => 分類 => 優先度決定 => 初期診断 => エスカレーション => 調査と診断 => 解決と復旧 => クローズ |
問題管理
根本原因を特定、解決する。
| 用語 |
ポイント |
| 問題とエラー |
問題は根本原因が未知の不具合を引き起こす事象。エラーは根本原因が既知の不具合を引き起こす事象 |
| 問題モデル |
特定の問題の定義済み対処手順 |
| KEDB |
Known Error DataBase |
| リアクティブ/プロアクティブ |
受動的/能動的 |
要求実現
パスワードリセットなどの要求を処理すること。
| 用語 |
ポイント |
| 要求モデル |
特定の要求の定義済み対処手順 |
| セルフ・ヘルプ |
FAQなど、ユーザーが自己解決するための仕組み |
アクセス管理
セキュリティを保つために適切に権限設定すること。
5.継続的サービス改善
| 用語 |
ポイント |
| 継続的サービス改善アプローチ |
ビジョン => どこにいるか => どこを目指すか => どのように目標達成するか => 達成したか => どのように推進力を維持するか |
| ベースライン |
基準とするベンチマーク |
| 測定理由 |
妥当性確認、方向付け、正当化、介入 |
| 測定基準 |
技術、プロセス、サービスの３種類がある |
| ガバナンス |
コーポレート（公正、透明、説明責任）、ITの２種類がある |
| 7ステップ |
識別 => 定義 => 収集 => 処理 => 分析 => 提示 => 実施 |
| CSI管理表 |
改善の機械を記録したもの。内容、理由、効果、規模、時期、優先度などを含む |
