ITIL V3

1. ITIL概要

1.1. 特徴

1.1.1. ベンダに依存しない

1.1.2. 規範的でない

1.1.3. ベストプラクティス

1.2. ITILにおけるサービス

1.2.1. 例

1.2.1.1. eメールサービス

1.2.1.2. クラウドコンピューティングサービス

1.2.1.3. データセンタサービス

1.2.2. サービスの性質

1.2.2.1. 無形

1.2.2.2. 需要と顧客資産が密接

1.2.2.3. 生産者と消費者が密接

1.2.2.4. 損耗しやすい

1.2.3. サービスの種類

1.2.3.1. コアサービス

1.2.3.2. 実現サービス

1.2.3.3. 強化サービス

1.2.4. サービスの価値

1.2.4.1. 有用性(Utility)

1.2.4.1.1. パファオーマンスがサポートされるか？

1.2.4.1.2. 制約が排除されるか？

1.2.4.2. 保証(Warranty)

1.2.4.2.1. 可用性は十分か？

1.2.4.2.2. キャパシティは十分か？

1.2.4.2.3. 継続性は十分か？

1.2.4.2.4. セキュリティは十分か？

1.2.5. キーワード

1.2.5.1. サービスマネジメント

1.2.5.2. ITサービスマネジメント

1.2.5.2.1. 4P

1.2.5.3. ITサービスプロバイダ

1.2.5.3.1. 自らのサービス資産を活用し、商品やサービスの形で価値を提供

1.2.5.3.2. 種類

1.2.5.4. サービスライフサイクル

1.2.5.4.1. ガバナンス

1.2.5.5. プロセス

1.2.5.5.1. 特徴

1.2.5.5.2. 役割・責任

1.2.5.6. リスク

1.2.5.7. 利害関係者

1.2.5.7.1. 顧客

1.2.5.7.2. ユーザ

1.2.5.7.3. サプライヤ

1.2.5.7.4. 機能

1.2.5.8. 機能

1.2.5.9. 資産

1.2.5.9.1. 能力

1.2.5.9.2. リソース

2. サービスストラテジ

2.1. ITサービス戦略管理プロセス

2.1.1. 市場の定義

2.1.2. 提供内容の開発

2.1.3. 戦略的資産の開発

2.1.4. 実行の準備

2.2. サービスポートフォリオ管理

2.2.1. サービスポートフォリオ

2.2.1.1. 廃止サービス

2.2.1.2. サービスパイプライン

2.2.1.3. サービスカタログ

2.2.2. 管理プロセス

2.2.2.1. 定義

2.2.2.1.1. サービス

2.2.2.1.2. ビジネスケース

2.2.2.2. 分析

2.2.2.2.1. 価値提案

2.2.2.2.2. 優先度付

2.2.2.3. 承認

2.2.2.3.1. 変更提案

2.2.2.3.2. 許可

2.2.2.4. 制定

2.2.2.4.1. コミュニケーション

2.2.2.4.2. リソース割当

2.3. 需要管理

2.3.1. どうやって需要を分析する？

2.3.1.1. 事業活動を把握

2.3.1.1.1. 事業活動パターン（PBA）

2.3.1.2. 提供内容を差別化する

2.3.1.2.1. ユーザプロファイル(UP）

2.3.2. サービスパッケージ

2.3.3. サービスオプション

2.3.4. キャパシティ管理に役立てる

2.4. ITサービス財務管理

2.4.1. 活動

2.4.1.1. 予算業務

2.4.1.2. 会計業務

2.4.1.3. 課金

2.4.2. サービス査定

2.4.2.1. 供給価値

2.4.2.2. 潜在的価値

2.5. 事業関係管理

3. サービスデザイン

3.1. プロセス

3.1.1. デザインコーディネーション

3.1.1.1. SDP(サービスデザインパッケージ）

3.1.1.1.1. 要件

3.1.1.1.2. サービスデザイン

3.1.1.1.3. 組織の準備状況アセスメント

3.1.1.1.4. サービスライフサイクル計画

3.1.2. サービスカタログ管理

3.1.2.1. 複数のビュー

3.1.3. サービスレベル管理

3.1.3.1. 成果物

3.1.3.1.1. SLA(Service Level Agreement)

3.1.3.1.2. SLR(Service Level Requirement)

3.1.3.1.3. OLA(Operation Level Agreement)

3.1.3.2. SLAMチャート

3.1.3.3. サービスレビュー

3.1.3.4. SIP(サービス改善計画）

3.1.4. キャパシティ管理

3.1.4.1. 事業キャパシティ管理　サブプロセス

3.1.4.2. サービスキャパシティ管理　サブプロセス

3.1.4.3. コンポーネントキャパシティ管理　サブプロセス

3.1.4.4. 活動

3.1.4.4.1. リアクティブな活動

3.1.4.4.2. プロアクティブな活動

3.1.4.4.3. 反復的な活動

3.1.5. 可用性管理

3.1.5.1. 活動

3.1.5.1.1. リアクティブな活動

3.1.5.1.2. プロアクティブな活動

3.1.5.2. キーワード

3.1.5.2.1. 可用性

3.1.5.2.2. 信頼性

3.1.5.2.3. 保守性

3.1.5.2.4. サービス性

3.1.5.2.5. 重要事業機能（VBF　Vital Business Function）

3.1.6. ITサービス継続性管理

3.1.6.1. 事業インパクト分析（BIA Business Impact Analysys)

3.1.6.2. 事業継続性管理（BCM Business Continuity Management）

3.1.6.3. 事業継続性計画（BCP Business Continuity Plan）

3.1.6.4. ITサービス継続性管理（ITSCM IT Service Continuity Managament）

3.1.6.5. リスク対応手段

3.1.6.5.1. UPS,バックアＰップ電源

3.1.6.5.2. RAID等

3.1.6.6. 復旧オプション

3.1.6.6.1. 手作業のワークアラウンド

3.1.6.6.2. 相互協定

3.1.6.6.3. 段階的復旧（コールドスタンバイ）

3.1.6.6.4. 中間的復旧（ウオームスタンバイ）

3.1.6.6.5. 高速復旧（ホットスタンバイ）

3.1.6.6.6. 即時的復旧（ホットスタンバイ、ミラー化、ロードバランシング、サイト分割）

3.1.7. 情報セキュリティ管理

3.1.7.1. 目標

3.1.7.1.1. 機密性を確保

3.1.7.1.2. 完全性の確保

3.1.7.1.3. 可用性を確保

3.1.7.2. キーワード

3.1.7.2.1. 情報セキュリティ方針

3.1.7.2.2. 情報セキュリティマネジメントシステム（ISMS）

3.1.8. サプライヤ管理

3.1.8.1. UC(Underpinning Contract)

3.1.8.2. サプライヤおよび契約管理情報システム　SCMIS(supplier and contract management information system)

3.2. 対象

3.2.1. サービスソリューション

3.2.2. 管理情報システムとツール、サービスポートフォリオ

3.2.3. 技術と管理両方のアーキテクチャ

3.2.4. 必要なプロセス

3.2.5. 測定方法と測定基準

3.3. 4P

3.3.1. People

3.3.2. Process

3.3.3. Product

3.3.4. Partner

3.4. ツール

3.4.1. 設計に活用

3.4.2. ツールや技法の利用目的

3.4.2.1. 設計プロセスの高速化

3.4.2.2. 標準と規約の遵守

3.4.2.3. プロトタイピング、モデル化およびシミュレーションの機能の提供

3.4.2.4. 仮定（What if）のシナリオの調査

3.4.2.5. インタフェースと依存関係の確認と関連付け

3.4.2.6. 開発と導入前に設計の妥当性を確認する

4. サービストランジション

4.1. 変更管理

4.1.1. 活動

4.1.1.1. RFC(Request For Change)の作成

4.1.1.2. RFCの記録

4.1.1.3. RFCのレビュー

4.1.1.4. 変更のアセスメントと評価

4.1.1.5. 変更の構築とテストの許可

4.1.1.6. 変更の構築とテストの調整

4.1.1.7. 更新の展開の許可

4.1.1.8. 変更の展開の調整

4.1.1.9. 変更レコードのレビューとクローズ

4.1.2. 変更の種類

4.1.2.1. 通常の変更

4.1.2.1.1. CAB(Change Advisory Board)　変更諮問委員会　あり

4.1.2.2. 標準的な変更（事前許可済み）

4.1.2.2.1. CAB(Change Advisory Board)　変更諮問委員会　なし

4.1.2.3. 緊急の変更

4.1.2.3.1. ECAB(Emergency CAB)　緊急変更諮問委員会　あり

4.1.3. 変更のインパクトの評価のポイント

4.1.3.1. 7Rモデル

4.1.3.1.1. Raised

4.1.3.1.2. Reason

4.1.3.1.3. Return

4.1.3.1.4. Risk

4.1.3.1.5. Resource

4.1.3.1.6. Responsible

4.1.3.1.7. Relationship

4.1.4. 変更の戻し計画立案

4.2. 移行の計画立案およびサポート

4.2.1. リリース方針（リリースポリシー）

4.2.1.1. 緊急リリースの方法は？

4.2.1.2. 通常リリースの方法は？

4.3. リリース管理及び展開管理

4.3.1. リリースパッケージ

4.3.1.1. リリースユニット

4.3.2. ナレッジが継承されるようにする

4.3.3. リリースアプローチ

4.3.3.1. ビッグバンアプローチ vs 段階的アプローチ

4.3.3.2. プッシュアプローチ vs プルアプローチ

4.3.3.3. 自動 vs 手動

4.3.4. リリース展開のモデル

4.3.4.1. 手順化

4.3.5. サービスVモデル

4.3.6. 初期サポート（Early Life Support)

4.4. サービスの妥当性確認及びテスト

4.5. サービス資産管理及び構成管理

4.5.1. キーワード

4.5.1.1. 構成アイテム（CI Configration Item)

4.5.1.2. 構成管理システム（CMS Configuration Management System)

4.5.1.2.1. 構成管理データベース（CMDB Configuration Mangement Database)

4.5.1.2.2. DML(確定版メディアライブラリ）

4.5.1.2.3. DS（確定版予備品）

4.5.1.2.4. 構成ベースライン

4.5.1.2.5. スナップショット

4.5.2. 管理と計画立案

4.5.3. 構成識別

4.5.4. 構成コントロール

4.5.5. ステータスの説明と報告

4.5.6. 検証と監査

4.6. ナレッジ管理

4.6.1. SKMS(Service Knowledge Management System)

4.6.2. 活動

4.6.2.1. ナレッジ管理の戦略を立案する

4.6.2.2. ナレッジを継承する

4.6.2.3. データ、情報、ナレッジの管理をする

4.6.3. キーワード

4.6.3.1. DIKWモデル

4.6.3.1.1. Data

4.6.3.1.2. Information

4.6.3.1.3. Knowledge

4.6.3.1.4. Wisdom（知恵）

4.7. ツール

4.7.1. サービスナレッジ管理システム

4.7.1.1. 文書管理

4.7.1.2. コンテンツ管理

4.7.1.3. 公開と配布

4.7.2. テストツール

4.7.3. リリースと展開のためのツール

5. サービスオペレーション

5.1. 機能

5.1.1. サービスデスク機能

5.1.1.1. ITユーザにとっての日常的な単一窓口（SPOC : Single Point of Contact)

5.1.1.2. 構造

5.1.1.2.1. ローカルサービスデスク

5.1.1.2.2. 中央サービスデスク

5.1.1.2.3. バーチャルサービスデスク（フォロー・ザ・サン）

5.1.1.3. スタッフ配置レベル

5.1.1.4. スキルレベル

5.1.1.5. トレーニング

5.1.1.6. スタッフの定着

5.1.1.7. スーパーユーザ

5.1.2. IT運用管理

5.1.2.1. 目標

5.1.2.1.1. 日々のプロセスと活動の安定のための現状の維持

5.1.2.1.2. 定常的な精査と改善

5.1.2.1.3. 運用スキルの迅速な適用

5.1.2.2. サブ機能

5.1.2.2.1. IT運用コントロール

5.1.2.2.2. 施設管理

5.1.2.3. 運用統制室（Operations Bridge)

5.1.2.3.1. ITサービスとITインフラストラクチャがモニタおよび管理される物理的な場所

5.1.3. 技術管理

5.1.4. アプリケーション管理

5.2. プロセス

5.2.1. イベント管理

5.2.1.1. イベント

5.2.1.1.1. 情報

5.2.1.1.2. 警告

5.2.1.1.3. 例外

5.2.2. インシデント管理

5.2.2.1. インシデント

5.2.2.2. 優先度

5.2.2.2.1. インパクト

5.2.2.2.2. 緊急度

5.2.2.3. エスカレーション

5.2.2.3.1. 機能的エスカレーション

5.2.2.3.2. 階層的エスカレーション

5.2.2.4. インシデントモデル

5.2.2.4.1. インシデント処理ステップの定義

5.2.2.5. 重大なインシデント

5.2.2.5.1. 通常のインシデント処理手順とは異なる

5.2.3. 要求実現

5.2.3.1. 活動

5.2.3.1.1. メニューの選択

5.2.3.1.2. 財務上の承認

5.2.3.1.3. ほかの承認

5.2.3.1.4. 実現

5.2.3.1.5. クローズ

5.2.3.2. サービス要求（Service Request)

5.2.3.3. 要求モデル

5.2.4. 問題管理

5.2.4.1. ワークアラウンド

5.2.4.1.1. 暫定処置や回避策

5.2.4.2. 既知のエラー

5.2.4.2.1. KEDB(既知のエラーデータベース）

5.2.4.3. 問題モデル

5.2.5. アクセス管理

5.2.5.1. 活動

5.2.5.1.1. アクセスの要求

5.2.5.1.2. 検証

5.2.5.1.3. 権限の提供

5.2.5.1.4. IDステータスのモニタリング

5.2.5.1.5. アクセスの記録と追跡

5.2.5.1.6. 権限の削除または制限

5.2.5.2. キーワード

5.2.5.2.1. アクセス

5.2.5.2.2. 権利、権限

5.2.5.2.3. ID

5.2.5.2.4. パスワード

5.2.5.2.5. ディレクトリサービス

6. 継続的サービス改善

6.1. プロセス

6.1.1. ７ステップの改善プロセス

6.1.1.1. 改善の識別

6.1.1.2. 定義

6.1.1.3. 収集

6.1.1.4. 処理

6.1.1.5. 分析

6.1.1.6. 提示

6.1.1.7. 実施

6.1.2. 手法

6.1.2.1. デミングサイクル（PDCA)

6.1.2.1.1. Plan 計画

6.1.2.1.2. Do 実施

6.1.2.1.3. Check 点検

6.1.2.1.4. Act 処置

6.1.2.2. CSIモデル（継続的サービス改善モデル）

6.1.2.2.1. ビジョンは何か？

6.1.2.2.2. 我々はどこにいるのか？

6.1.2.2.3. 我々はどこを目指すのか？

6.1.2.2.4. どのように目標を達成するか？

6.1.2.2.5. 我々は達成したのか？

6.2. 道具

6.2.1. CSI管理表

6.3. 測定

6.3.1. ベースライン

6.3.2. CSF(Critical Success Factor)

6.3.3. KPI(重要業績評価指標）

6.3.4. モニタと測定を行う４つの理由

6.3.4.1. 妥当性確認のため

6.3.4.2. 方向付けのため

6.3.4.3. 正当化のため

6.3.4.4. 介入のため

6.3.5. 測定基準

6.3.5.1. 技術測定基準

6.3.5.1.1. コンポーネント

6.3.5.2. プロセス測定基準

6.3.5.2.1. プロセスのCSF,KPI

6.3.5.3. サービス測定基準

6.3.5.3.1. エンドツーエンド