OPS09-BP01 メトリクスを使用して業務目標と KPI を測定する
業務の成功を定義する目標と KPI を組織から取得し、それを反映するメトリクスを決定します。基準点としてベースラインを設定し、定期的に再評価します。このようなメトリクスをチームから収集して評価するメカニズムを開発します。
期待される成果:
-
組織の業務チームの目標と KPI が公開され、共有されています。
-
このような KPI を反映したメトリクスが確立されています。以下はその例です。
-
チケットキューの長さ、またはチケットの平均経過時間
-
問題の種類別のチケット数
-
標準業務手順書 (SOP) の有無を問わず、問題の処理に費やした時間
-
失敗したコードプッシュからの回復に費やされた時間
-
通話ボリューム
-
一般的なアンチパターン:
-
デベロッパーがトラブルシューティングタスクに追われてしまうため、デプロイの期限が守れない。開発チームは追加の人員を求めていますが、開発作業に取り組めなかった時間を測定できないため、必要な人数がわからない。
-
Tier 1 デスクが、ユーザーからの電話に対応するために設置され、時間が経つにつれて、ワークロードは増えましたが、Tier 1 デスクへの人員は追加されない。通話時間が長くなり、問題が解決されないまま問題が長引くと、顧客満足度は低下するが、経営陣にはそのような兆候が明らかでないため、対策がとられていない。
-
問題のあるワークロードは、メンテナンスのために別の運用チームに引き継がる。その他のワークロードとは異なり、この新しいワークロードには適切なドキュメントとランブックが付属していないため、チームはトラブルシューティングや障害への対処に時間を費やすが、これを文書化するメトリクスがないため、説明責任が困難となる。
このベストプラクティスを活用するメリット: ワークロードのモニタリングではアプリケーションとサービスのステータスを明らかにするのに対し、モニタリングする運用チームは、ビジネスニーズの変化など、ワークロードのコンシューマー間の変化についてオーナーにインサイトを提供します。運用状況を反映するメトリクスを作成することで、チームの有効性を測定し、ビジネス目標に照らして評価できます。メトリクスでは、サポート上の問題を浮き彫りにしたり、サービスレベル目標から逸脱した時期を特定したりできます。
このベストプラクティスを活用しない場合のリスクレベル: 中
実装のガイダンス
業務部門のリーダーおよび関係者とサービスの全体的な目標を決定します。さまざまな業務チームのタスクがどうあるべきか、またどのような課題に取り組むことができるかを判断します。これらを使用して、これらの業務目標を反映すると思われる主要業績評価指標 (KPI) についてブレインストーミングを行います。これには、顧客満足度、機能の構想からデプロイまでの時間、平均問題解決時間などが含まれます。
KPI に基づいて、このような目標を最もよく反映すると思われるメトリクスとデータソースを特定します。顧客満足度は、通話の待ち時間や応答時間、満足度スコア、発生した問題の種類など、さまざまなメトリクスを組み合わせたものです。デプロイ時間は、テストとデプロイに必要な時間に加えて、デプロイ後に追加する必要のある修正を加算したものである場合があります。さまざまな種類の課題に費やされた時間 (またはそれらの課題の数) を示す統計値から、集中的に取り組む必要がある個所を把握できます。
リソース
関連ドキュメント:
