ITIL V3 Foundation

2 05 2010
略語はみっちり覚えておく。 (CSIくらいしか出なかったけれど
サービスデザインのプロセスと機能は?とかで全て言えるようにしておく
CSIのモデルとかプロセスとかセットで覚えるものも必ず全て言えるようにしておく
~のプロセスはどれか?って聞かれて選択肢に機能が混ざってたりするのでそれでまたプロセスがどれかを覚えていれば絞れる
他の受験者ブログにあったようになぜか同じようにマルチレベルSLAが二問出た
メインの参考書は黄本。問題解いた後に調べる用にも。
サブとしてITIL V3 実践の鉄則。
解いた問題は
http://www.exin.jp/index.php?option=com_news&task=view&id=142&pItemid=28
http://naha.cool.ne.jp/overdrive/ItilV3Exam/index.htm
http://kakomon.s2.zmx.jp/staticpages/index.php/itil3
いずれも無料orサンプル問題
http://itildumps.blogspot.com/
あとこれを一セット。
そしてこれを少し読んだ
http://www.olivenet.co.jp/essay.html
勉強期間は1.5週間
時間があれば参考書開いてた感じ

広告




最低限覚える略語

1 05 2010
情報処理技術者試験同様ITILも略字が多い

SLA(Service Level Agreement)…サービスレベルアグリーメント

UC(Underpinning Contract)…外部委託契約

OLA(Operational Level Agreement)…オペレーショナルレベルアグリーメント

PBA(Pattern of Business Activity)…事業活動パターン

BIA(Business Impact Analysis)…ビジネス・インパクト分析

BCM(Business Continuity Management)…事業継続性管理

VBF(Vital Business Function)…重要ビジネス機能

KPO(Knowledge Process Outsourcing)…ナレッジ・プロセス・アウトソーシング

BPO(Business Process Outsourcing)…ビジネス・プロセス・アウトソーシング

SCD(Supplier Contracts Database)…サプライヤ管理データベース

CAD(Change Advisory Board)…変更諮問委員会

ECAD(Emergency Change Advisory Board)…緊急変更諮問委員会

RFC(Request For Change)…変更要求

SKMS(Service Knowledge Management System)…サービス・ナレッジ管理システム

CMS(Configuration Management System)…構成管理システム

CMDB(Configuration Management DataBase)…構成管理データベース

DML(Definitive Media Library)…確定版メディアライブラリ

CI(Configuration Item)…構成アイテム

KEDB(Known Error DataBase)…既知のエラーデータベース

SPOC(Single Point of Contact)…単一窓口

RACI(Responsible,Accountable,Consulted,Informed)…実行責任者,説明責任者,協議先,報告先

MoSCoW(Must,Should,Could,Would)

DIKW(Data-to-Information-to-Knowledge-to-Wisdom)…データ-情報-知識-知恵

PIR(Post Implementation Review)…導入後レビュー

ITSCM(IT Service Continuity Management)…ITサービス継続性管理

FSC(Forward Schedule of Change)…将来的な変更スケジュール

PSA(Projected Service Availability)…サービスの予想可用性

CSF(Critical Success Factor)…重要成功要因

KPI(Key Performance Indicator)…業績評価指標

AMIS(Availability Management Information System)…可用性管理情報システム

CMIS(Capacity Management Information System)…キャパシティ管理情報システム

CCM(Component Capacity Management)…コンポーネント・キャパシティ管理





まとめて覚える

29 04 2010
  • プロセスの特性
    測定可能
    具体的な結果を伴う
    利害関係者への結果の提供
    特定のイベントに対応
  • RACIモデル
    実行責任者(Responsible)1…*
    説明責任者(Accountable)1
    協議先(Consulted)*
    報告先(Informed)*
  • サービスライフサイクル
    サービスストラテジ
    サービスデザイン
    サービストランジション
    サービスオペレーション
    継続的サービス改善
  • サービスストラテジ
    財務管理プロセス
    需要管理プロセス
    サービスポートフォリオ管理プロセス
  • ITサービスのステータス
    サービス・パイプライン
    サービス・カタログ
    廃止されるサービス
  • サービスデザイン
    サービス・カタログ管理
    サービスレベル管理
    キャパシティ管理
    可用性管理
    ITサービス継続性管理
    情報セキュリティ管理
    サプライヤ管理
  • 4P
    人材(People)
    プロダクト(Products)
    パートナ(Partners)
    プロセス(Processes)
  • サービスデザイン5つの側面
    サービス・ソリューションの設計
    プロセスの設計
    測定方法と測定基準の設定
    技術アーキテクチャの設計
    支援的な仕組みの設計(特にサービス・ボートフォリオ)
  • MoSCoW分析
    持たなければならない(Must)
    可能であれば,持つことを推奨(SHOULD)
    他に影響を与えなければ持つことが可能(COULD)
    将来的に持ちたい(WOULD)
  • サービス・カタログ
    ビジネス・サービス・カタログ
    技術サービス・カタログ
  • キャパシティ管理
    事業キャパシティ管理
    サービス・キャパシティ管理
    コンポーネント・キャパシティ管理
  • 情報セキュリティ管理
    機密性
    可用性
    完全性
  • サービストランジション
    移行の計画立案およびサポート
    リリース管理および展開管理
    サービスの妥当性確認およびテスト
    評価
    変更管理
    サービス資産管理および構成管理
    ナレッジ管理
  • サービスVモデル
    事業,ビジネスの要件の定義←→サービス提供,パッケージ,ソリューションの検証
    ↓                                     ↑
    サービス要件の定義←→サービス受け入れテスト
    ↓                                     ↑
    サービスの設計←→サービス運用の準備状況テスト
    ↓                                     ↑
    サービス・リリースの設計←→サービス・リリース・パッケージのテスト
    ↓                                     ↑
    サービス・ソリューションの開発←→コンポーネントとアセンブリのテスト
    ↓                                     ↑
    サービス・コンポーネントの構築とテスト
  • データ,情報,知識,知恵(DIKW)
    データ(Data)
    情報(Information)
    知識(Knowledge)
    知恵(Wisdom)
  • 変更管理7R
    誰が(RAISED)
    なぜ(REASON)
    成果は(RETURN)
    リスクは(RISK)
    必要なリソースは(RESOURCE)
    責任は誰に(RESPONSIBLE)
    他との関係は(RELATIONSHIP)
  • 変更モデル
    通常の変更
    標準的な変更
    緊急の変更
  • サービスオペレーション
    サービスデスク(機能)
    技術管理(機能)
    IT運用管理(機能)
    アプリケーション管理(機能)
    要求実現
    インシデント管理
    イベント管理
    アクセス管理
    問題管理
  • サービスオペレーションのバランス
    内部的なIT視点と外部的な事業視点
    安定性と対応力
    サービスの品質とサービスのコスト
    リアクティブとプロアクティブ
  • インシデント管理プロセス
    インシデントの識別
    インシデントの記録
    インシデントの分類(カテゴリ化)
    インシデントの優先度の決定
    初期診断
    インシデントのエスカレーション
    調査と診断
    解決と復旧
    インシデントのクローズ
  • デミング・サイクル(PDCA)
    計画(Plan)
    実施(Do)
    点検(Check)
    処置(Act)
  • 継続的サービス改善モデル
    ビジョンは何か?
    現状はどれにいるか?
    どこを目指すのか?
    どのように目標を達成するか?
    目標の達成をどのように確認するか?
    どのようにして推進力を維持するか?
  • 継続的サービス改善で測定する理由
    妥当性確認
    方向付け
    正当化
    介入
  • 7ステップの改善プロセス
    測定すべき内容の定義
    測定できる内容の定義
    データの収集
    データの処理
    データの分析
    情報の提示,活用
    是正措置の実施




itil

27 04 2010
http://d.hatena.ne.jp/tacohachi/20090610/p1
色々

http://www.freeml.com/bl/7771196/121094/
マルチレベルSLA

http://ubichupas.blogspot.com/2009/03/itil-v3-foundation.html
7ステップの改善プロセス n番目は? このステップではなにする?

http://blog.livedoor.jp/inventrix/archives/156161.html
ITサービス継続性管理における各段階? サービスレベル管理?

マルチレベルSLA…企業レベルのSLA,特定の顧客レベルのSLA,特定のサービスのSLAと適切なサイズで分ける
ワークフローポジション…インシデントの現在の状態
フルリリース,デルタリリース,パッケージリリース。





ITIL V3 Foundation 覚書

27 04 2010
プロセスモデル…部門横断的な組織体制と管理向上のために使用されるモデル

プロセス…内部外部顧客またはステークホルダに成果をもたらす。実績指向である。特定のトリガーに反応する。特定の成果がある。特定のトリガだけに追跡される。方針,標準規格,ガイドラインを定義する場合がある

リリース管理プロセスを確立する際,最初の活動はリリースポリシの確立。

重大なインシデントのインパクト分析はインシデント管理の一部で,ITサービス継続性管理の責任ではない

既知のエラーをクローズできるのは,変更のレビューが満足のいく結果を導いたとき

構成管理はITインフラストラクチャとそのコンポーネントおよびそれらの関係に関する情報を提供する責任があり,変更のインパクト評価を手助けするために,構成管理には適切なレベルの詳細さがなければならない

PIRが開催されるのは毎変更後

承認された変更は,将来的な変更スケジュール(FSC)で発表される

問題管理は問題を解決する責任がある

サービスレベル管理プロセスの有効性を判断するには,顧客満足度を測定する

インシデントの調査と診断は,インシデント管理プロセスの責任

コンポーネントのコストは,サービスの可用性全体に直接影響しない

問題管理では,受容された時間枠を超過したインシデントの責任をとることはしない

構成管理の検証活動においては,監査が定期的に実施される

サービスレベルレポートにおいて,サービスデスクのスタッフの平均稼働率は在ると期待されない

キャパシティ管理と可用性管理は共通のゴールを共有し,相互補完する。相互依存がある。CFIAやFTAなど同じツールを使う

プロセス・オーナはプロセスを記述することに責任がある

ITSCM計画発動を依頼するのは,障害がSLAに定義された目標を超えて続きそうなとき

CMDBにおいて,詳細レベルという用語はデータベース構造の深さを意味する

KPIを定義するのはプロセスオーナ。説明責任者
プロセスマネージャは実行責任者