ITIL 的目标
サービスサポート評価指標
インシデント管理
第5章
ITILサービスサポートブックのインシデント管理セクションでは、監視と測定は重要業績評価指標(Key Performance Indicator、KPI)であると述べられています。KPIに関して、ITILは以下のように説明しています。
「プロセスパフォーマンスを評価するためには、しばしば重要業績評価指標(KPI)と呼ばれる定量可能な目標により明確に定義された目的を設定するべきである」
ITILが示している例を見る際は、それらがサービスデスク自体ではなくインシデント管理に関連していることに注意してください。ITILは、インシデント管理プロセスの有効性と効率のための例として以下の評価指標を提案しています。
- インシデント数の総計。
- インパクト・コードで細分化したインシデントの解決あるいは回避を達成する平均経過時間。
- 同意された応答時間中に扱われるインシデントのパーセンテージ (インシデント応答時間目標は、SLAでは例えばインパクト・コードで特定されているかもしれません)。
- インシデントあたりの平均コスト。
- 他のレベルのサポートへ照会することなくサービスデスクで終了したインシデントのパーセンテージ。
- サービスデスクワークステーション単位で処理されるインシデント。
- 訪問の必要なく遠隔で解決されたインシデントの数とパーセンテージ。
これらの例について詳しく議論する前に、これらがすべて検証や介入、あるいは正当化ではなく方向付けのために使用された評価指標であることに注意してください。これらの評価指標の大部分は、目標あるいは目的が事前に設定されています。
それでは、さらに詳しく評価指標を見てみましょう。
インシデント数の総計。インシデント数の総計は明白な評価指標ですが、期間を日数と一日の時間数で細分化して報告すると最も有効です。また、月数や年数など、長い期間を用いてもかまいません。 しかしこれらの報告には、作業フローのピークと谷を示すより詳細なブレークダウンが含まれるべきです。特にピークが重要です。例えば、いつもある曜日が他の日より忙しいこともあるでしょうし、通常はインシデントが最も多い特定の月があるでしょう。ピーク評価指標はスタッフのスケジューリングと休暇計画に有効です。
期間に対しキャパシティ目標量を設定し、それを実際の量と比較することにより、適切なスタッフレベルを維持することができます。例えば、1時間で扱うことができるインシデント数が最大200件である場合、実際の量がそれに近づく頻度はどのくらいですか?実際の量が確実に最大キャパシティに近づくのであれば、特別な監視、つまり介入と正当化のための監視を設定する必要があるでしょう。キャパシティを超えてしまいそうな時期を決定することにより、予防的措置をとることができます。
- ビジネス連携の指標–予測される企業成長に基づいてインシデント数の増大を予測することができるように、重要な企業顧客やパートナーと作業負荷について話し合ってください。
インパクト・コードで細分化したインシデントの解決あるいは回避を達成する平均経過時間。一見、この評価指標の意味は不明瞭であるかもしれません。細かく見ていきましょう。ITILではよく、「平均時」と「平均時間」という用語が互換性を持って使用されます。またITILでは度々、「回避」は「次善策」と呼ばれ、「インパクト」は「インシデントのビジネスへの致命度の尺度」と説明されます。ほとんどの者にとって、「インパクト」は、優先度あるいは重大度のコードです。この測定基準は、優先度あるいは重大度コードにより細分化した、インシデントの解決策あるいは次善策を達成するまでの平均経過時間に着目しています。人員配置レベルの決定に役立つため、これは有効な基準となります。例えば、各優先度/重大度レベルに対する平均時間およびインシデント数の総計が既知の場合は、作業負荷のタイミングを決定するための基礎データがあるということです。また、最近の過去のデータから平均経過時間の変化を決定することができる場合、インシデント管理スタッフキャパシティに対する効果を予測することにより、作業負荷への影響を計算することができます。
- ビジネス連携の指標–ビジネス環境の変化の結果、インパクト・コードを変更する必要がある場合すぐに反応することができるように、重要な顧客やパートナーとの連絡を常に保ってください
同意された応答時間中に扱われるインシデントのパーセンテージ (インシデント応答時間目標は、SLAでは例えばインパクト・コードで特定されているかもしれません)。これは重要な測定基準です。 しかし、同意された応答時以内に処理されなかったインシデントの数がさらに重要です。SLAで同意された時間内でインシデントが処理されないごとに不満をもつ顧客が増えていきます。これらのインシデントを調査して同意された応答時内に処理されなかった理由を決定し、次にこの数を確実に減らすための可能な対策をすべて決定してください。
- ビジネス連携の指標–ビジネスマネージャは、同意されたサービスレベルを上回るいかなるインシデントの増加にも対処することができなければなりません。インシデントの解決が同意された期限を超えてしまった場合は、必ずビジネスマネージャに通知するようにしてください。さらにビジネスマネージャは、同意されたサービスレベルを満たしていないインシデントに関連する過去のデータを再検討することができなければなりません。
インシデントあたりの平均コスト。インシデントあたりの平均コストには、簡単な計算が必要ですが、チャージバックを含む多くの財政的な計算に使用することができます。しかし、「平均コスト」という用語が誤解を招く場合があるのに留意してください。例えば、パスワードのリセットに要する時間が1分未満で、要するコストが最小限であっても、ジャストインタイムトレーニング問題には30分かかり、はるかに高いコストとなるかもしれません。したがって、あなたはインシデントタイプで平均コストを計算しなければなりません。
- ビジネス連携の指標–ビジネスマネージャはいつでも、自分のビジネスエリアに関連するインシデントのコストを見直すことができなければなりません。理想的には、日付や部門などのカテゴリでこのデータを細分化する必要があります。
他のレベルのサポートへ照会することなくサービスデスクで終了したインシデントのパーセンテージ。これは度々、「一次レベルで解決されるインシデント」として知られ、ほとんどのサービスデスクに対する主要な測定基準です。通常、目標は一次レベル解決に設定され、SLAには一次レベル解決の評価指標が含まれる場合があります。この測定基準が間違ったサービスデスクの対応、例えばインシデントを終了させることがその解決よりも重要であるとするような対応を形成するためのものではないことに注意してください。
- ビジネス連携の指標–ビジネスマネージャにとって好ましいのは、「一次レベルのインシデント解決」よりむしろ「インシデント削減」です。問題管理を介したインシデント数削減のための構造化手法を確実に持つようにしてください。ビジネスマネージャに、まずレベル解決のデータ、そして問題管理におけるインシデント削減の状況を再検討させてください。
サービスデスクワークステーション単位で処理されるインシデント。これは、スタッフのパフォーマンスとキャパシティの両方を監視し測定するために使用される、もう1つの典型的なサービスデスクの測定基準です。 インシデントの処理はできるだけ効率的でなければなりません。つまり、これはインシデント管理プロセスのパフォーマンスを見直す重要な測定基準です。理想的には、サービスデスクワークステーションあたりのインシデントは皆同等であるべきです。不均衡は、サービスデスクワークステーションへのインシデントの配分における問題を示している場合があり、これにより効率が低下するでしょう (これはもちろん、例えばワークステーションのいくつかはオフピークの期間使用されないなど、不均衡が予定の範囲内である場合を除きます)。予定外の不均衡を調査し、修正しなければなりません。
- ビジネス連携の指標–この総合的な測定基準は、ビジネスマネージャには興味がないところでしょう。しかし、不均衡がビジネスマネージャあるいはそのスタッフによって引き起こされたのなら、彼らと話し合いをもち、不均衡の理由を検討しなければなりません。例えば、ビジネスマネージャあるいはそのスタッフがサービスデスクの担当者を名指しで電話に呼び出す、またはインシデント関連のEメールを直接担当者宛に送信します。
訪問の必要なく遠隔で解決されたインシデントの数とパーセンテージ。これはますます重要となってきている測定基準です。知識ベース技術がますます採用されるに従い、この数字は増加し、またサービスデスクの作業負荷は減少するはずです。また、どのツールがインシデントのリモート解決に使用されるかを示すデータを必ず収集してください。
- ビジネス連携の指標–インシデントのリモート解決のあらゆる点に関して、ビジネスマネージャと取り組んでください。例えば、サービスデスクに電話するのが、より速く低コストであることがあります。ビジネスマネージャは、使用する者から要する時間、要する物に及ぶ、インシデントのリモート解決に関連するすべての業務を再検討することができなければなりません。
前述したように、インシデント管理のための測定と監視の大部分は、方向付けに基づいています。しかしこれらの評価指標のいくつかは、例えばサービスの低下あるいはコストの上昇が発生した場合は、検証あるいは介入を必要とするかもしれません。
> > 第6章 - 問題管理