7/6 ITILｖ３への道
アプリケーション管理の活動
→アプリケーションの設計、機能の可用性の保証、アプリケーションの保守、障害発生時のサポート
アプリケーション管理
→アプリケーションの設計、構築、導入、改善を行うためのリソースを提供する専門的な組織
IT運用管理
→ITインフラストラクチャを安定的に維持できるように、ジョブのスケジューリング、NW運用センタでNWを監視するなど日常の運用を担当する「運用コントロール」
参考)サーバ室、DCなど、物理的なIT環境を管理する「施設管理」の機能を持つ
デミング・サイクル
→品質改善で用いられる4つの段階
計画(Plan)、実施(Do)、点検(Check)、処置(Act)をもつサイクル、PDCAサイクル
CSIモデル
→DPCAサイクル活用、改善をつづけることによって品質を高めるモデル
参考)6つのステップ
「ビジョンは何か」「現状はどこにいるのか」「どこを目指すのか」「どのように目標を達成するか」「目標の達成をどのように確認するか」「どのようにして推進を維持するか」
測定基準
→CSIで改善を行うにあたって、何を測定するべきかを定義。
測定基準の目的)
「妥当性確認」
→意思決定の内容が戦略とビジョンどおりになっているか検証
「方向付け」
→設定した目標を満たすために何をすべきかを伝達、指示
「介入」
→変更や是正措置などにおいて、介入が必要な個所を特定するために監視・測定
「正当化」
→行った措置が適切であったことを、実際の測定結果、証拠によって証明
プロセス測定基準
→ex)サービスデスクでの解決率、インデントの平均解決時間
サービス測定基準
→ex)ITサービスの稼働率
7ステップの改善プロセス
→CSIにおいて、Dを測定して分析する7つのステップで構成される改善プロセス
参考)PDCAとして構成される
→繰り返し行うことが大切。
順番)「測定対象の定義」「測定できる内容」「Dの収集」「Dの処理」「Dの分析」「情報の提示、活用」「是正措置の実施」
1、測定対象の定義(測定すべき内容の定義)
→事業部門(顧客)とITサービス・プロバイダ間で、何を測定すべきか協議、測定対象を決定。
参考)「ビジネスにとって重要なものは何か？」
「理想的な環境ではどうなっているべきか？」を意識し、測定対象を決める
参考2)この段階では、測定対象の洗い出しをする。
2、測定可内容の定義
→「測定対象の定義」で洗い出した項目から、どの項目が実際に測定可能か検討する。
参考)要員、体制、ツールの機能、業務手順などの制約を考慮し、測定可能な内容を決定。
参考2)測定が困難な場合、ツールを作り直したり、リプレースして、時間、費用をかけてまでも測定する必要をかけてまでも測定する必要があるかどうかをビジネスの視点で判断
3、Dの収集
→「測定可内容の定義」で決定した測定対象を誰が、いつ、どのように、どれくらいの頻度で収集するかなど、D収集のための体制を決定し、Dの収集を監視する。
4、Dの処理
→「D」を「情報」に変換し、意味を持たせる
参考)変換時は、頻度、形式(表、グラフなど)、鮮度などを考慮し処理
5、Dの分析
→「情報」をもとに、「目標値を満たしているか？」「目標値を満たしていない場合、原因は何か？」「この問題は是正する必要があるか？」を分析し「知識」として活用。
６、情報の提示、活用
→Dの分析結果をレポートとしてまとめ事業部門、経営者、ITサービス・プロバイダといった利害関係者に報告しレビュー
参考）レビューにより「知識」を「知恵」として活用可
参考2)工夫が必要
7、是正措置の実施
→レビューした結果、是正措置が必要と判断した場合には、サービスを改善。
参考)必要としても組織にすべてのケースで改善できるとはかぎりません。
ビジネス部門の最終目標などに基づいて優先順位をつけて改善。工数がかかる場合、あえて改善しない選択もある
顧客
→ITサービスのコストについて責任をもつ人
ユーザ
→ITサービスを仕様する人
プロバイダ
→ITサービスを提供
ITサービスの一覧
→サービス・カタログ管理が作成
エラー
→原因・対策が判明している排除すべき対象
参考)障害発生の理由がわかるもの
機能＝組織
→特定の業務に専念し、成果に対して責任を負う組織と定義
参考）成果を達成するために必要な能力やリソースをもっている
ex)サービスデスクなど技術管理、アプリケーション管理、IT運用管理
参考2）IT環境に関するもの意外に、作業手順や作業手法も含まれる
プロセス
→アウトププットを確実に提供するために必要な役割、責任、手段などが含まれる
4つの特性)
→「測定可能である』、「具体的な結果が得られる」、「結果を顧客or利害関係者に提供する」、「特定のイベントに対応する」
プロセス・モデル
→プロセスの構成要素、活動などを表現したモデル
参考)プロセスの特徴を理解したり、説明したりする場合に使用
閉ループ・システム
→自プロセスのアウトプット、他のプロセスのアウトプット、顧客の声をFbとして受け入れ、自身のプロセスを改善することができるシステム
プロセス・オーナ(基準チェック)
→文章化されている手順にしたがってプロセスが実効されていることやプロセスの成果が合意した基準を満たしていることに責任を負う。
参考)プロセスの成果について説明責任がある
プロセス・マネージャ
→プロセスの実効に責任をもつ。
参考)Responsible(実効責任者)
サービス・オーナ
→IT役員やサービスマネジメント役員に対して、担当するサービスの説明責任を負う
担当するサービスの会誌、導入、移行、継続的な保守、サポートに責任を負う
運営の為、スポンサークリックご協力お願い致します。
→アプリケーションの設計、機能の可用性の保証、アプリケーションの保守、障害発生時のサポート
アプリケーション管理
→アプリケーションの設計、構築、導入、改善を行うためのリソースを提供する専門的な組織
IT運用管理
→ITインフラストラクチャを安定的に維持できるように、ジョブのスケジューリング、NW運用センタでNWを監視するなど日常の運用を担当する「運用コントロール」
参考)サーバ室、DCなど、物理的なIT環境を管理する「施設管理」の機能を持つ
デミング・サイクル
→品質改善で用いられる4つの段階
計画(Plan)、実施(Do)、点検(Check)、処置(Act)をもつサイクル、PDCAサイクル
CSIモデル
→DPCAサイクル活用、改善をつづけることによって品質を高めるモデル
参考)6つのステップ
「ビジョンは何か」「現状はどこにいるのか」「どこを目指すのか」「どのように目標を達成するか」「目標の達成をどのように確認するか」「どのようにして推進を維持するか」
測定基準
→CSIで改善を行うにあたって、何を測定するべきかを定義。
測定基準の目的)
「妥当性確認」
→意思決定の内容が戦略とビジョンどおりになっているか検証
「方向付け」
→設定した目標を満たすために何をすべきかを伝達、指示
「介入」
→変更や是正措置などにおいて、介入が必要な個所を特定するために監視・測定
「正当化」
→行った措置が適切であったことを、実際の測定結果、証拠によって証明
プロセス測定基準
→ex)サービスデスクでの解決率、インデントの平均解決時間
サービス測定基準
→ex)ITサービスの稼働率
7ステップの改善プロセス
→CSIにおいて、Dを測定して分析する7つのステップで構成される改善プロセス
参考)PDCAとして構成される
→繰り返し行うことが大切。
順番)「測定対象の定義」「測定できる内容」「Dの収集」「Dの処理」「Dの分析」「情報の提示、活用」「是正措置の実施」
1、測定対象の定義(測定すべき内容の定義)
→事業部門(顧客)とITサービス・プロバイダ間で、何を測定すべきか協議、測定対象を決定。
参考)「ビジネスにとって重要なものは何か？」
「理想的な環境ではどうなっているべきか？」を意識し、測定対象を決める
参考2)この段階では、測定対象の洗い出しをする。
2、測定可内容の定義
→「測定対象の定義」で洗い出した項目から、どの項目が実際に測定可能か検討する。
参考)要員、体制、ツールの機能、業務手順などの制約を考慮し、測定可能な内容を決定。
参考2)測定が困難な場合、ツールを作り直したり、リプレースして、時間、費用をかけてまでも測定する必要をかけてまでも測定する必要があるかどうかをビジネスの視点で判断
3、Dの収集
→「測定可内容の定義」で決定した測定対象を誰が、いつ、どのように、どれくらいの頻度で収集するかなど、D収集のための体制を決定し、Dの収集を監視する。
4、Dの処理
→「D」を「情報」に変換し、意味を持たせる
参考)変換時は、頻度、形式(表、グラフなど)、鮮度などを考慮し処理
5、Dの分析
→「情報」をもとに、「目標値を満たしているか？」「目標値を満たしていない場合、原因は何か？」「この問題は是正する必要があるか？」を分析し「知識」として活用。
６、情報の提示、活用
→Dの分析結果をレポートとしてまとめ事業部門、経営者、ITサービス・プロバイダといった利害関係者に報告しレビュー
参考）レビューにより「知識」を「知恵」として活用可
参考2)工夫が必要
7、是正措置の実施
→レビューした結果、是正措置が必要と判断した場合には、サービスを改善。
参考)必要としても組織にすべてのケースで改善できるとはかぎりません。
ビジネス部門の最終目標などに基づいて優先順位をつけて改善。工数がかかる場合、あえて改善しない選択もある
顧客
→ITサービスのコストについて責任をもつ人
ユーザ
→ITサービスを仕様する人
プロバイダ
→ITサービスを提供
ITサービスの一覧
→サービス・カタログ管理が作成
エラー
→原因・対策が判明している排除すべき対象
参考)障害発生の理由がわかるもの
機能＝組織
→特定の業務に専念し、成果に対して責任を負う組織と定義
参考）成果を達成するために必要な能力やリソースをもっている
ex)サービスデスクなど技術管理、アプリケーション管理、IT運用管理
参考2）IT環境に関するもの意外に、作業手順や作業手法も含まれる
プロセス
→アウトププットを確実に提供するために必要な役割、責任、手段などが含まれる
4つの特性)
→「測定可能である』、「具体的な結果が得られる」、「結果を顧客or利害関係者に提供する」、「特定のイベントに対応する」
プロセス・モデル
→プロセスの構成要素、活動などを表現したモデル
参考)プロセスの特徴を理解したり、説明したりする場合に使用
閉ループ・システム
→自プロセスのアウトプット、他のプロセスのアウトプット、顧客の声をFbとして受け入れ、自身のプロセスを改善することができるシステム
プロセス・オーナ(基準チェック)
→文章化されている手順にしたがってプロセスが実効されていることやプロセスの成果が合意した基準を満たしていることに責任を負う。
参考)プロセスの成果について説明責任がある
プロセス・マネージャ
→プロセスの実効に責任をもつ。
参考)Responsible(実効責任者)
サービス・オーナ
→IT役員やサービスマネジメント役員に対して、担当するサービスの説明責任を負う
担当するサービスの会誌、導入、移行、継続的な保守、サポートに責任を負う
運営の為、スポンサークリックご協力お願い致します。