ITIL環境における問題管理品質の測定、第3回

このシリーズの第1回および第2回の記事[第1回および第2回の記事へのリンク]で検討したように、ITIL環境における問題管理の品質を評価することは必ずしも容易ではありません。正しい質問をすることから、パフォーマンスを測定するためにどのメトリクスを使用すべきかを決定することまで、考慮すべき変数がたくさんあります。この記事では、問題の根本原因を特定する際の「魔法」について詳しく見ていきます。

問題分析に必要な要素

問題の根本的な原因を探るには、さまざまな方法があり、明らかに成功しているものもあります。しかし、標準的なフレームワークがなければ、人によってアプローチが異なるのは当然です。トラブルシューターのグループの有効性は、ベルカーブに沿ってどこかに落ちます。ほとんどのトラブルシューティングのエキスパートは、自信を持って何かを任せることができます。また、トラブルシューティングの評判が良くない人は、おそらく助けが必要です。

Kepner-Tregoe(KT)方式による問題分析は、1950年代に研究され、定義され、その後数十年にわたって改良とテストが続けられてきました。これは、コンピュータがどこにでもあるような時代ではなく、ITILが存在するような時代でもないことは明らかである。

KT法が研究された当時は、ITもITILも存在していなかったため、KT法のような手法は現在のIT業界には適していないのではないかという議論があります。適切な判断をするためには、KT法による問題分析を詳しく見てみる必要がある。問題分析の主なステップは次の通りである。

  • 問題の記述
  • 可能性のある原因の想定
  • 想定された原因の評価
  • 真の原因の確定
  • 問題解決後の考察

これらの各ステップには、明確な意図があり、質問の言い回しや、正しいデータを得るための回答の文書化に役立つ適切なサブステップが用意されています。これらのインプットはすべて、問題分析の思考プロセスにつながります。これは、特定の製品や問題を念頭に置くことなく行われるもので、あらゆる種類のIT組織に対応するITILと非常によく似ています。問題分析は、業界や技術に関係なく、さまざまな問題の根本原因を見つけるためのアプローチです。

問題分析の3つの切り口

KTの手法はどのようなタイプの問題にも適しているが、「問題」という言葉に対するKTの定義は非常に特殊であり、ITILと非常によくマッチしている。KTによれば、問題分析のプロセスを開始する前に、3つの基準が当てはまる必要がある。

実際のパフォーマンスと望ましいパフォーマンスの間にはギャップがあるはずです。これを偏差と呼んでいます。(例:機械が動いていないのに、機械が動いているべきだとか)
逸脱の原因が不明(例:既知のエラーではない)。
差異の原因を知る必要性がある。
トラブルシューティング担当者は、明確に定義された一連のステップを踏んで根本原因を見つけ出すことで、既に行われたことと、プロセス中に残されていることのコミュニケーションと文書化を開始することができます。問題の症状を説明するために、収集したデータをどのようにモデル化するかの例を以下の図に示します。

最終回となる次回は、ITILプロブレムマネジメントのパフォーマンスを効果的に測定するために、プロブレムアナリシスがどのようなコアフレームワークを提供するのかをご紹介します。

ブログ画像1
ITIL環境での問題管理品質の測定、その1
ブログ画像1
ITIL環境における問題管理品質の測定、パート2
ブログ画像1
ITIL環境における問題管理品質の測定、第4回

私たちは以下の専門家です:

お問い合わせ

お問い合わせ、ご意見、詳細確認はこちらから