スポンサー:

サービスサポート評価指標

構成管理

第9章

他のすべてのプロセスが構成管理データベース（CMDB）を利用しますから、一般的に、構成はITILサービス管理の中心として考えられます。したがって、CMDBは正確であり適時的に更新されることが不可欠です。CMDBの重要性を考慮すれば、構成管理には管理報告とKPIの両方が含まれることに気付くのは驚くべきことではありません。推奨される評価指標を見る前に、構成アイテム（CI）がCMDBの入り口であることを思い出してください。まず、管理情報から始めましょう。

構成監査の結果

発見された未登録あるいは誤って登録されたCIとその修正処理の情報。

CIカテゴリやタイプ、ステータス（可能であれば場所や、その他のCIの属性によっても）に分類された登録済CIやCIバージョン数の情報

成長とキャパシティの情報。

CI／CMDBとDSLの変更割合の情報

構成管理作業の残作業もしくは構成管理活動での送れの詳細と改善の提案

構成管理スタッフを配置する場所

時間外に他のITサービス・スタッフがこなした許可された作業の量

構成管理システムの効果／効率のレビュー、成長のレビュー、および監査の結果と、実際もしくは潜在的な問題に取り組むための提案

タイプ毎のCIの数に関するデータと分析 (例えば、サービス、サーバ、ルータ、ハブ、ソフトウェアライセンス、デスクトップPCなど)。

CI（もしくは資産）の価値。

配付配付配付配付配付■ 事業単位や、サポート・グループ、あるいはサービス毎のCIの場所。

お分かりのように、管理情報は、主としてCMDBの正確性、CMDBの内容の分析、およびCMDBを維持管理するスタッフの努力、と3つの領域に関わっています。それぞれの評価指標を見ていきましょう。

構成監査の結果。ITILは、CMDBの内容が現実と一致することを確認するために、CMDBが頻繁に監査を受けるべきであると提案しています。例えば、ある部門に50台のワークステーションがある場合、CMDBにも50台のワークステーションが登録されているはずであり、また各ワークステーションに対する詳細情報は正確であるはずです。ITILは、以下の時に監査が必要であると述べています。

新規の構成管理システムを導入した直後。

ITインフラストラクチャの重大な変更の前後。

環境が前提と一致していることを確認するため、ソフトウェア・リリースやインストールの前

災害復旧に続いて、「通常状態に戻った」後（この監査は、緊急事態計画に含まれるべきである）ランダムな間隔で。

すべての未許可のCIの発見に対応して。

定期的な間隔で。

多くの組織は定期監査プログラムを持っており、これにより「スナップショット」監査を行います。これは、1月はサーバ、2月は電気通信、そして3月はデスクトップソフトウェアの監査といった、予定のスケジュールに従ったCMDBの「部分的」監査の実行に関連します。またITILは、自動化された監査ツールがある場合は、それを用いて毎週CMDBの監査を行うことを推奨しています。また、この監査を実行している間、CMDB問題の結果として何らかの記録が作成されているどうかを識別するために、インシデントデータベースと問題データベースを分析する必要があります。

さらに、サービスデスクは、実際にワークステーションにインストールされているソフトウェアのバージョンがCMDBに記録されたバージョンと異なっていることを不具合の分析中に発見した時など、サービスデスク担当者によって検出されたすべての不一致を報告するべきです。監査は、CMDBが正確な情報を確実に保持することに役立ちます。これは高品質のサービス管理に不可欠です。さらに、サーベンス・オクスリー法（米国企業改革法）により、CMDBの正確性の重要度は前例のないレベルまで高められています。このレポートを配付する前に、監査で発見されたあらゆる不一致について明らかにしておいてください。この監査結果は、すべてのITマネージャに配付してください。

ビジネス連携の指標 – これは、主にサーベンス・オクスリー法の観点から、すべてのITILサービス管理プロセスの中で最も重要なビジネス連携のポイントであると言えるでしょう。すべての監査結果は、サーベンス・オクスリー法の遵守に責任を負うIT監査チームあるいは内部監査チームのメンバーなどの、主要なビジネスマネージャに配付されなければなりません。また監査結果は、監査により明らかとなった不一致を有するビジネスマネージャに配付されるべきです。さらにビジネスマネージャは、彼らが所有しているまたは彼らのコントロール下にあるすべてのITインフラアイテムの監査であっても実行できなければなりません。自身の監査を実行するために、ビジネスマネージャは彼らの環境に関連するすべてのCIを見ることができなければなりません。

発見された未登録あるいは誤って登録されたCIとその修正処置の情報。この評価指標は、前の評価指標での監査から派生しています。ここで鍵となるのは、この評価指標がただデータを提供するのではなく、修正処置を指定しているということです。このレポートを編集する際は、抜けている構成アイテム（CI）を忘れずに含めてください。レポートでは、CMDBが不正確となった経緯、および同じ不正確の繰り返しの防止対策について説明するべきです。また、このレポートを編集している間、CMDB問題の結果として記録が生じているかどうかを識別するために、インシデントデータベースと問題データベースを分析する必要があります。さらにサービスデスクは、CMDBにはないCIの問題の修正を依頼されているときなど、サービスデスク担当者によって検出されるあらゆる不一致をすぐに報告するべきです。このレポートの結果は、サーベンス・オクスリー法の遵守に責任を負う監査チームのメンバーなどの主要なビジネスマネージャ、そして少なくとも、レポートで明らかにされる不一致を有しているビジネスマネージャに配付されなければなりません。

ビジネス連携の指標 – これは、主にサーベンス・オクスリー法の観点から、ITILサービス管理プロセスにとって重要なもう1つのビジネス連携のポイントです。最高財務責任者（CFO）など、サーベンス・オクスリー法の遵守に対する責任を担っているビジネスマネージャに、このレポートのコピーが確実に渡るようにしてください。

CIカテゴリやタイプ、ステータス（可能であれば場所や、その他のCIの属性によっても）に分類された登録済CIやCIバージョン数の情報。この情報は、CMDBの内容をリストアップしたレポートの中に提示されます。レポートは、オンラインあるいは印刷物として利用可能にすることができます。評価指標が述べているように、カテゴリ、タイプ、およびステータスに加えて、自分の要件に合う他のカテゴリを使用して、レポートをさらに細分化することができます。他のすべてのIT部門と相談して、彼らがCMDBをある特定の分類で示すことを必要としているか、またレポートの形式は印刷あるいはオンラインのどちらが良いかなどを判断する必要があります。さらに、自分達の計画立案の目的で、詳細より全体像に関心があることもよくあります。そのため、他のIT部門と確認をとり、彼らが詳細な内訳を必要とするのかあるいはただ全体像を必要としているかを判断してください。このレポートは、すべてのIT部門、および相応の権限を持つすべての者がオンラインにより閲覧できるようにすべきでしょう。

ビジネス連携の指標 – ビジネスマネージャは彼らの環境にIT設備を所有しているか、あるいはその管理責任があります。いずれの場合も、ビジネスマネージャは、自分達の構成アイテムについて常に知っているように、このレポートのコピーを受け取るか、あるいは彼らのCIをオンラインで確認できなければなりません。このレポートが確実にすべてのビジネスマネージャに利用可能であるようにしてください。

成長とキャパシティの情報。CMDBがキャパシティ不足のために不正確になる可能性があってはなりません。いうまでもなく、キャパシティ管理がCMDBのキャパシティの計算とモデル化に責任を持つべきです。それには、CMDBの現在のサイズ、CMDBに利用可能なスペース量、および既知の計画された新しいCIのリストを示す増加とキャパシティの情報が必要です。この情報は、キャパシティ管理グループに必ず提供してください。また、この情報を構成管理グループに提供して、彼らが日々のキャパシティについて常に知っていてキャパシティ不足に意表を突かれることがないようにしなければなりません。所定の時間におけるCMDBのサイズを記録して、CMDBの増加率を明らかにするべきでしょう。例えば、最近12か月のデータベースのサイズを月単位で示すグラフを作成することができます。キャパシティ管理と構成管理以外に、他のITマネージャがこのデータのコピーを必要とすることはないでしょう。しかし、他のITマネージャに問い合わせ、このレポートに関心があるかどうか確認してください。

ビジネス連携の指標 – ビジネスマネージャがこのレポートのコピーを必要とすることはあまりないでしょう。しかし、CMDBの今後の増加を計算する助けとなるデータが彼らから得られるかもしれません。ビジネスマネージャには、今後の増加に関連するいかなるデータ、あるいは彼らの環境における著しい変化を提供してくれるよう依頼するべきでしょう。

CI/CMDBとDSLの変更割合の情報。この情報は極めて状況に依存しているため、なぜ必要であるか理解するのは難しいかもしれません。例えば、ソフトウェアの新バージョンをすべてのワークステーションにインストールする場合、多くの変更があることが予想できます。それなのになぜこの情報が必要なのでしょうか? その理由は、変更に関する情報（変更管理より提供された）とCMDBの変更情報と比較することで、異常あるいは不正確があることを明らかにすることができるからです。この情報は、通常は構成管理によって使用されますが、変更管理が使用する場合もあります。この情報は、管理の上で参考にするための変更割合のリストを提供するものであり、あるいは変更の問題を明らかにするために使用することができます。

ビジネス連携の指標 – 不正確であると判断された変更に関わっている場合を除いて、ビジネスマネージャがこの情報を必要とすることはあまりないでしょう。

構成管理作業の残作業もしくは構成管理活動での遅れの詳細と改善の提案。この評価指標は重要です。CMDBはその正確性が保たれ、ITインフラの現在のステータスを反映していなければなりません。この評価指標は2つの要素から構成されています。構成管理作業のバックログと、構成管理業務によって引き起こされている他のIT部門に対する遅延です。

第1の要素であるバックログを見てみましょう。CMDBの更新に遅延が生じるのは、管理上の意思決定の失敗、インシデント解決の遅延、変更の遅れ、財務上の計算ミスなど、さまざまな理由が考えられます。それが、CMDBの更新の遅延の原因となり得る構成管理のすべてのバックログを直ちに報告することが重要である理由です。

この評価指標の第2の要素は、構成管理業務に起因する遅延です。例えば、そのCMDBが、他のCMDB業務が原因で更新不能あるいは未更新であるために、変更を遅らせなければならないことがあります。繰り返しますが、構成管理業務に起因するすべての遅延を直ちに報告することが重要です。遅延の影響を受ける可能性があるITマネージャにはすぐに通知しなければなりません。また、すべてのバックログあるいは遅延を直ちに上級ITマネージャに通知することも重要です。最後の「提案される救済手段」も重要です。報告されたすべてのバックログあるいは遅延に対しても、その再発を防ぐために救済手段を提案することが重要です。

ビジネス連携の指標 – 構成管理バックログあるいは業務による遅延に悩むビジネスマネージャは皆、きっとこのレポートを見たいと思うでしょう。さらに、ビジネスマネージャがCMDBの更新に必要な情報を公表しないことにより、バックログを引き起こすことも考えられます。したがって、遅延を被るあるいは遅延の原因となっているすべてのビジネスマネージャに対して速やかに知らせることが重要です。

充分構成管理スタッフを配置する場所。「構成管理スタッフの配置する場所」の基準を明確に定義していないため、人員配置に関するレポートは難しい問題です。どのような追加情報もない場合、人員配置のレポートは、充分な人数の熟練スタッフが構成管理にいるかどうかを評価するものと見なさなければなりません。この場合、完了した作業、予定の作業、および投入可能なスタッフの数を示す定期レポートということになります。このレポートによって人員配置を決定することができるかもしれません。このレポートは、構成管理の責任を担う上級ITマネージャを対象とします。

ビジネス連携の指標 – このレポートに関心を示すのは、構成管理の責任があるビジネスマネージャだけでしょう。

時間外に他のITサービス・スタッフがこなした許可された作業の量。ITサービススタッフ以外のスタッフが、構成アイテムのライフサイクル管理の一環として定期的にCMDBを更新することができます。例えば、注文が出されれば購買スタッフがCMDBを更新し、新しいワークステーションが納入されれば機材受領スタッフがCMDBを更新し、またワークステーションが設置されればデスクトップサービススタッフがCMDBを更新します。以前に述べたように、短期間の残業が必要となる例外が常に存在します。

新規のしい構成管理システムを導入した直後。

ITインフラストラクチャへの重大な変更の前後。

環境が前提と一致していることを確認するため、ソフトウェア・リリースやインストールの前。

災害復旧に続いて、「通常状態に戻った」後 (この監査は、緊急事態計画に含まれるべきである)。

これらの状況ではいずれも、短期間で完了しなければならないCMDBの更新作業が数多く発生します。その結果、CMDBの保守管理者は、ある一定期間何らかの援助を必要とする場合があります。ITサービススタッフまたは他の認定スタッフによってすべての作業が数時間以内に終了することが理想的です。したがって、残業を必要とする余分な作業を慎重に追跡し、将来の作業が作業時間内に確実に終了できるように対策を取らなければなりません。残業について定期にレポートをまとめ、それをITマネージャ、特にCMDBの保守管理に責任があるITマネージャ全員に送ってください。

ビジネス連携の指標 – CMDBの更新の責任を負うスタッフを持つマネージャがこのレポートのコピーを望むことは明らかです。

構成管理システムの効果／効率のレビュー、成長のレビュー、および監査の結果と、実際もしくは潜在的な問題に取り組むための提案。これは、前の管理情報評価指標の多くを1つにまとめたものです。理想的には、イントラネットロケーションなどの中央ポイントを設定し、関心を持つすべての当事者がここにリストアップした項目のすべての結果を見ることができるようにします。

ビジネス連携の指標 – すべてのビジネスマネージャが、オンラインでこの貴重な情報に即時にアクセスできなければなりません。

配付配付タイプ毎のCIの数に関するデータと分析 (例えば、サービス、サーバ、ルータ、ハブ、ソフトウェア・ライセンス、デスクトップPC等)。この管理レポートの情報については以前に説明されていたと思いますが、ここでの重要な相違は「分析」という言葉です。以前は「リスト」と「総計」に関して話しましたが、ここではCMDBの分析について説明します。行うべき分析のタイプは2つあります。定期的な分析と、リリース計画情報の必要性など特別な事情で要求される緊急の分析です。どのようにして定期的スケジュールに従いCMDBを分析するかを決定できるのはあなた自身です。また、IT部門がCMDBの特別な分析を要求できる方法を確立しなければなりません。定期レポートはすべてのITマネージャに配付さられなければなりません。特別レポートは緊急要求を提出したマネージャが指名するITマネージャのみに配付します。

ビジネス連携の指標 – 定期レポートのコピーはすべてのビジネスマネージャの手に渡らなければなりません。特別レポートは緊急要求を提出したマネージャが指名するマネージャのみに配付します。

CI（もしくは資産）の価値。この評価指標は、ITサービスの財務管理と呼ばれる別のITILプロセスで使用することが可能です。ITでこのレポートを作成をする場合、レポートは構成アイテムに含まれる財務上の属性に基づかなければなりません。CI記録に財務上の属性を含めると、さまざまな財務レポートを作成することができます。しかしながら、この条件はCIと資産の価値だけに適用されます。すべての資産の合計値のみを示すレポートも作成することがでますが、ワークステーション、ラップトップ、デスクトップソフトウェアの価値など、各CIの異なるタイプ毎に合計値を示すレポートを提供するほうが有効的です。これにより、有用な予算編成データを提供することができ、より有意義なレポートとなります。このレポートは定期的に作成し、IT資産を有するすべてのITマネージャに配付してください。

ビジネス連携の指標 – 確かにこのレポートは、財務部門以外にも、恐らく購買などの部門にとって興味のあるものでしょう。また、部門や部署などのビジネスエリア毎の資産価値を示すレポートにすれば、ビジネスマネージャも関心を示すかもしれません。ビジネスマネージャと、彼らが望むレポートのフォーマットやレポートがカバーすべき期間について話し合ってください。

事業単位や、サポートグループ、あるいはサービス毎のCIの場所。これは計画と資産管理のための重要情報を提供する直接的なレポートです。これは簡潔なレポートであるべきであり、ロケーションごとにCIを示すために必要なCIの属性がなければなりません。このレポートに必要なレベルの詳細を示すことができるように、CIの設計には細心の注意を払ってください。特に監査が近づいているときは、すべてのITマネージャに定期レポートを配付するべきです。

ビジネス連携の指標 – これは、すべてのビジネスマネージャにとって基本的となる別のレポートです。彼らは、自身のコントロール下のすべての資産に関する定期レポートを手にする必要があります。

充分これで、ITおよびビジネスに重要なデータを提供するだけではなく、あなたの組織が法律上の義務を満たすのをサポートすることができる不可欠の情報を含む、構成管理のための包括的な一連の管理レポートを手にしたことになります。これらのレポートからのさまざまなデータは、重要業績評価指標を特定して検証するために使用されます。

「構成」が認可されているものと異なる場合。

誤って実装された変更にさかのぼることができるインシデントと問題。

インパクト評価が不充分であったり、CMDBのデータが誤っていたり、あるいはバージョン・コントロールが不充分であったために成功しなかった変更要求 (RFC)。

変更を許可し実装するサイクル期間。

特定の場所で無駄にされてきたか、使われてこなかったライセンス。

構成監査による例外報告。

利用が発見された未許可のCIコンポーネント。

これらは明確なKPIであり、構成管理データベース内の意思決定と管理計画のためのリソースの正確性を維持したいなら、これらのKPIのすべてを満たさなければなりません。一つ一つ見ていきましょう。

「構成」が認可されているものと異なる場合。不正確な構成が見つかった場合は常に、KPIを達成できなかったということです。以前説明した管理レポートのいくつかは、構成が正確でない場合に焦点を当てています。

ビジネス連携の指標 – すべてのビジネスマネージャは、必要な場合に構成を、あるいは少なくとも資産を閲覧することができなければなりません。彼らの構成が許可されていないことを発見した時は、彼らに通知してください。ビジネスマネージャ全員に通知することで他のマネージャに対して構成に同じ問題が起きる可能性を警告することになる思わない限り、通知は許可のない構成があるビジネスマネージャのみに行わなければなりません。

誤って実装された変更にさかのぼることができるインシデントと問題。このKPIを見ると、これは変更管理に属するように見えますが、今回は構成管理について説明しています。「構成管理の問題に起因する」という言葉を加えれば、このKPIをより理解できるでしょう。このKPIの目標は、インシデントがゼロであり問題がゼロであることです。両方がゼロでない場合、「なぜ」ゼロでないかを調査し、再発防止のための処置を講じなければなりません。

ビジネス連携の指標 – 誤って行われた変更から生じたインシデントと問題のために不具合を被った経験のあるビジネスマネージャなら、それに関しては既に知っているでしょう。しかし、問題とインシデントの性質を説明するため、さらに重要なこととして再発防止のために取られている処置について説明するために、影響を受けたビジネスマネージャには必ず通知しなければなりません。

インパクト評価が不充分であったり、CMDBのデータが誤っていたり、あるいはバージョン・コントロールが不充分であったために成功しなかった変更要求 (RFC)。構成管理の問題のためにRFCがうまく終了しなかった場合、これはその時の重要課題となり、詳細な分析と推奨される一連の処置が取られることになるでしょう。これは重要なKPIであり、これを満たせなかった場合は、上級ITマネージャによって大きな構成管理の失敗とみなされます。この評価指標に対する目標は、構成管理問題によって失敗に終わるRFCをなくすことでなければなりません。

ビジネス連携の指標 – 確かに、構成管理が原因でRFCがうまく終了しなかったことを経験したビジネスマネージャは、皆既に問題を意識しているでしょう。しかし、RFCがうまく終了しなかった理由、さらに重要なことして再発防止のために取られている処置について説明するために、不都合を被ったビジネスマネージャに通知するべきであることは確かです。

変更を許可し実装するサイクル期間このKPIに必要なものは何かを正確に決定することは困難です。変更はすべてそれぞれ異なり、変更のためのサイクルタイムもそれぞれ異なります。しかし、あらゆる変更には、ライフサイクル中の各段階に対して予定されたタイミングがあるはずです。達成すべきは、これらのサイクルタイムです。このKPIを理解するために、「構成管理に起因する変更を承認し実行するためのサイクル期間の遅延」と読み替えてみましょう。これで、このKPIは測定可能であり遅延ゼロを成功とすることが分かります。構成管理における変更のライフサイクルを遅延させる原因を排除するために、計画を立てて処置を講じなければなりません。遅延が構成管理内の欠点だけではなく、不充分な計画により引き起こされる場合があることに注意してください。その多くは、CMDBへのアップデートが大量にあり、作業負荷に誤算が生じるというパターンです。見積もられたタイミングと作業負荷が確実に実現できるように、構成管理をすべての変更計画に関与させるようにしてください。

ビジネス連携の指標 – この場合、ビジネスマネージャは「犠牲者」と「加害者」のどちらにもなり得ます。彼らの変更が遅らせられる場合は犠牲者です。CMDBの更新など、何らかの構成管理業務に責任があるものの、義務を果たせないような場合は、加害者となります。興味深いのは、1人のビジネスマネージャが、別のビジネスマネージャの変更を遅らせる可能性があるということです。例えば、購買部門によって購入された新しい設備データのCMDBへの変更入力が遅れているために、財務部門が提出する変更が遅れることがあります。遅延により影響を受けたすべてのビジネスマネージャに通知してください。

特定の場所で無駄にされてきたか、使われてこなかったライセンス。ライセンス管理はリリース管理の一部であるため、このKPIも他に属するように思えます。ではなぜここに示されているのでしょうか? 不要あるいは未使用のライセンスの原因が構成管理エラーの場合があるというのがその理由です。例えば、構成管理によるCMDBの更新が不正確であったことを原因としていくつかのライセンスが使用されていなかったことを、リリース管理が監査中に発見する場合もあります。また、構成管理がリリース管理に通知をせずにワークステーションを加えたため、ライセンスが遵守されなかったという例もあります。さらに、「構成管理における失敗に起因する」という言葉を補うと、このKPIの関連性が明確になるでしょう。このKPIはゼロであるべきです。このKPIを達成できない場合は、原因の再発を防ぐために対策を取らなければなりません。

ビジネス連携の指標 – これも、ビジネスマネージャが犠牲者と加害者のどちらにもなり得るというケースです。彼らが料金を支払っているライセンスのすべてを使用していない場合は、犠牲者となります。CMDBの更新など、何らかの構成管理業務に責任があるものの義務を果たせないような場合は、加害者となります。このKPIにおいても、1人のビジネスマネージャが別のビジネスマネージャに対してマイナスの効果を与える可能性があります。ライセンスの低使用率の影響を受けるすべてのビジネスマネージャに通知し、彼らと共同して貴重な予算を節約するためにライセンスを取り消すかどうかを決定してください。

構成監査による例外報告。このKPIは、探すべき例外が何であるかを述べていません。しかし、CMDBを常に正確に保つためには、ここですべての例外を述べなければならないと断言できます。このKPIはゼロであるべきであり、報告されたいかなる例外に対しても、その再発を防止するための処置が適切に取られなければなりません。

ビジネス連携の指標 – 例外が適用されるいかなるビジネスマネージャも、例外が発見された時点で連絡を受けるでしょうから、すべてのビジネスマネージャをこのKPIに関与させる必要はありません。しかし、構成管理に責任を負うビジネスマネージャと例外を引き起こした者は関与させなければならないでしょう。またこれらのビジネスマネージャは、このKPIを満たさなければなりません。

利用が発見された未許可のITコンポーネント。使用中の無許可のITコンポーネントについては、このセクションの初めで説明した監査により明らかとなるでしょう。したがって、ここでは分析を実行する必要はなく、使用中に検出されたすべての無許可のITコンポーネントを報告するべきです。このKPIはゼロでなければなりません。

ビジネス連携の指標 – 許可のないITコンポーネントの使用を認めた責任がない限り、このKPIに関するフィードバックを必要とするのは、影響を受けたビジネスマネージャだけです。インフラと構成に無許可のコンポーネントを組み込むと重大な問題と遅延が引き起こされる場合があるので、これは重大な問題です。さらに、インターネットからダウンロードしたものなど、いくつかのコンポーネントはウイルスあるいはハッカー侵入経路などのセキュリティ問題を導くおそれがあります。したがって、構成に対して許可のないITコンポーネントの使用を認めた責任を負うビジネスマネージャにすぐに通知しなければなりません。

またITILでは、構成管理の章の終わりに、以下のような関連する可能性があるその他のKPIが推奨されています。

ユーザが問い合わせている間に、さらなるエスカレーションの必要なく解決された、サービス・デスク・コールの割合の月毎の変化。

インシデントと問題の、数と深刻さの変化。

その場で解決できなかったサービスデスク・コールを診断、解決するためにかけた平均時間とコストの変化。

変更管理、構成管理、リリース管理、問題管理、もしくはサービスデスク機能いずれかにより生じたエラーにまで追跡可能な問題による、SLA違反の数とその深刻さの変化。

CMDB内で識別されたエラーによって起こったCMDBへの月毎の変更数。

お分かりのように、これらのKPIは以前に議論したものより一般的ですが、まだ関連性はあります。初めにほんのいくつかのKPIを扱うことができれば、出発点として以前に説明されたものを実行するべきです。

では、これらの追加の構成管理KPIを見てみましょう。

ユーザが問い合わせている間に、さらなるエスカレーションの必要なく解決された、サービスデスク・コールの割合の月毎の変化。このKPIの成功レベルは、ユーザからの問い合わせに対してサービスデスクが、問題をさらに発展させる必要なしに電話だけで解決できる場合を増やし続けることができるかどうかに依存します。これは、このKPIが毎月増加するべきであることを意味します。理論的には、CMDBがより正確かつ包括的となるほど、サービスデスクがすぐに利用できる問題解決のための情報量が増し、一次レベルで解決できる数を増加させることができます。この水準が低下するようなら、調査にあたる必要があります。

興味深いのは、水準の低下が必ずしも問題を示しているというわけではないということです。例えば、多くのインシデントを引き起こしていた問題が排除される状況を想定してください。次善策があったため、ヘルプデスクのスタッフは最初の問い合わせでそれらのインシデントを解決することができました。問題を排除すると、それらのインシデントが排除され、最初の問い合わせで解決されるインシデントの数は減少するでしょう。したがって、一次レベルで解決できる問題のパーセンテージは減少しますが、問題に悩まされていた顧客は満足することになります。

ビジネス連携の指標 – 既に説明しましたが、通常サービスデスクと業界の間には、SLAで規定される「一次レベルの問い合わせの解決」の水準があります。そうであれば、ビジネスマネージャは既にこのKPIのコピーを受け取っていることでしょう。そうでなければ、定期レポートとしてビジネスマネージャにそれを提出するべきでしょう。

インシデントと問題の、数と深刻さの変化。このKPIには、変化が増加するべきなのか減少するべきなのかが示されていません。増加に対しては調査が必要ですが、減少については、著しい場合を除いて、調査されることは通常ないでしょう。インシデントデータベースと問題データベースを分析し、インシデントと問題の数と重大性における変化を確認してください。インシデントデータベースあるいは問題データベースのどちらかで変化が見つかった場合は、すぐに調査を開始し、現状復帰への行動を開始しなくてはなりません。分析を実行するとき、これは構成管理のためになされるということに留意し、構成管理に属さないインシデントと問題の数あるいは重大性が増加する場合は、追加調査や処置を行うために該当するプロセス所有者に報告してください。増加が構成管理に属する場合は、原因を特定し、それを排除するための対策を取らなければなりません。これは定期的に、最低でも週一回は監視する必要のあるKPIです。もちろん、変化がある場合はこのKPIを満たしていないことを示します。

ビジネス連携の指標 – インシデントと問題の数の増加あるいは重大性の変化を経験していない限り、ほとんどのビジネスマネージャはこの分析の結果を見る必要はないでしょう。影響を被るビジネスマネージャにこのKPIを配付し、彼らと相談する必要があります。

その場で解決できなかったサービスデスク・コールを診断、解決するためにかけた平均時間とコストの変化。このKPIにも、変化が増加するべきなのか減少するべきなのかが示されていません。増加に対しては調査が必要ですが、減少については、著しい場合を除いて、減少が調査されることは通常ないでしょう。ITサービスサポートに対する批判としてよくあるのは、最初の問い合わせで解決されなかったインシデントの解決に非常に長い時間を要するということです。それがこのKPIが非常に重要である理由です。

通常、インシデントデータベースあるいはサービスデスクデータベースでこの情報が利用可能であるため、該当するデータベースを毎日監視するべきでしょう。分析を実行するとき、これは構成管理のためになされるということに留意し、構成管理に属さないインシデントと問題の数あるいは重大性が増加する場合は、追加調査や処置を行うために該当するプロセス所有者に報告してください。ただし、増加が構成管理に属する場合は、原因を特定し、それを排除するための対策を取らなければなりません。ここで変化がある場合は、このKPIを満たしていないことを示します。

ビジネス連携の指標 – 即時解決が不可能なサービスデスクへの問い合わせの診断と解決に要する平均時間とコストの変化によって直接影響を受けていない限り、ほとんどのビジネスマネージャはこの分析の結果を見る必要はないでしょう。影響を受けたビジネスマネージャにこのKPIを送付し、彼らと話し合ってください。

変更管理、構成管理、リリース管理、問題管理、またはサービスデスク機能いずれかにより生じたエラーにまで追跡可能な問題による、SLA違反の数とその深刻さの変化。これはほとんどのサービスサポートプロセスに適用される一般的KPIです。すべてのSLAの不履行を直ちに調査し、可能なときはいつでも再発防止のための処置を取ってください。しかし、このKPIは数と重大性における変化を要求しますが、違反の調査が既に行われているでしょうから全く同じではありません。このKPIには、将来の傾向分析と組み合わせた、数と重大性の定期的な比較が必要です。傾向を特定した場合は至急調査を行ってください。数または重大性に変化があった場合は、このKPIを満たせなかったことを意味します。

ビジネス連携の指標 – 影響を受けるビジネスマネージャには、SLAに対する違反の原因となるすべての変化を報告し、理由と再発を防止するために取るべき処置をすべて説明しなければなりません。

CMDB内で識別されたエラーによって起こったCMDBへの月毎の変更数。多くのITスタッフとビジネススタッフがCMDBを参照および意思決定のツールとして使用します。したがって、CMDBは正確に保持されなければなりません。CMDBで識別されたエラーに起因する毎月のCMDBの変更数を最小限に抑え、増加がある時はすぐに調査してください。このKPIは少なくとも毎週、できれば毎日追跡するべきです。増加の原因となるエラーの再発を防止するために定期的な点検と対策を設定するなら、変更の数は時間の経過と共に減少するはずです。数が増加した場合は、このKPIを達成できなかったということです。減少した場合は、このKPIを満たしたことを示しています。数に変化が見られない場合は、成功を収めたのか失敗してしまったのかを判断する必要があります。

ビジネス連携の指標 – ITがCMDBに対しすべての更新と変更を行っている場合、ほとんどのビジネスマネージャはこのKPIに関心を示さないでしょう。しかし、CMDBを更新または使用しているビジネスマネージャがいる場合、彼らは確実にこのKPIのコピーを必要とするでしょう。

既に構成管理のセクションの初めで説明したように、プロセスを管理するためには管理情報とKPIのセットが数多く必要です。一部はあまりにも過剰であるように見えるかもしれませんが、技術上およびビジネス上の両方の観点から、正確なCMDBが必要となります。技術エリアでは、正確なCMDBがITにとって重要な意思決定ツールを提供します。ビジネスエリアでは、不正確性は財務上・法律上の重大なペナルティをもたらします。それが不正確性の迅速な発見と訂正が不可欠である理由なのです。

要約

この小冊子では、およそ80のITIL推奨の測定ポイントを説明してきました。それらを全部実行することは不可能だと思われるかもしれません。そう思うのも無理はありませんが、それで良いのです。思い出してください。ITILは方法論ではなく、フレームワークなのです。ITILサービスサポートを自分なりに調整し、あなたの特定のニーズを満たしてください。ただし、あらゆる測定を慎重に見直し、監視が必要であるかどうかを決定しなくてはなりません。あるものは、あなたの組織には関連していないかもしれませんし、他の組織を監視するのに利用可能なデータがないかもしれません。何よりも、あなたの選択が確実に優れたビジネスセンスを作り出すようにしましょう。選択を行う際は、必ずビジネスマネージャから意見を求めるようにしてください。

多数のレポートの配付に加え、あるいはその代わりに、包括的なレポートとKPIをすべて含むよう定期的に更新されるイントラネットサイトを作成することも考慮してください。イントラネットのポータルサイトを作成し、それを介してビジネスマネージャが自分の固有情報を再検討することができるようにすることができます。ただレポートを利用可能にしたからといって、必ずビジネスマネージャがそれらを利用するものと思ってはなりません。レポートを利用していないビジネスマネージャを定期的にチェックし、それを伝えてください。

これらの鍵となる評価指標に焦点を合わせ、ITILベストプラクティスの価値を示してください。そして、ビジネスの優先事項とIT目標・目的の方向性が一致するよう、ビジネス連携の指標に細心の注意を払ってください。ビジネスとITの方向を一致させることにより、ITが提供する実質価値を示すことができるのです。

ITIL 的目标

サービスサポート評価指標

構成管理

第9章

要約