ServiceNowでチケットの分析をすることになったが、何分はじめてのことであり、どのような視点、角度から分析すればよいかわかりませんでした。ITILについてはL3は以前とっていたので、その知識とインターネットで調査。今後ダッシュボード等を作成する際の指針になればと思いまとめました。こちらは個人的な考えをまとめています。ITILからはずれている部分もあるかと思いますのでご了承ください。

用語

項目	説明
重要度	1から4を想定し、Sev1はクリティカル, Sev2は重要, Sev3はマイナー、Sev4は改善項目としています。
メトリックおよびKPI	こちらについては別章で記載しました。

KPIとメトリックの違い

KPIとメトリックはほぼ同じ意味ですが、微妙に異なります。説明としては"Measure Before Deciding: The Essence of Data in Marketing"が非常にわかりやすかったです。

KPIは戦略的な目標であり、メトリックは戦術的な目標といえます。すべてのKPIはメトリックですが、メトリックがKPIとは限りません。ITILでは、顧客満足度やMTTRがKPIになりますが、その他はメトリックとして取り扱ってよい気がします。

このドキュメントでは基本的にメトリックを用語として用います。現在の会社におけるサポート体制、ユーザーの知識等により、どのメトリックをKPIとして選択するかは変わってくるからです。

メトリックを設計するときの視点

メトリックを見るときに重要な視点が３つあります。

ボリューム
重要度
プロセス

他にもありますが、こちらは「その他属性」としてまとめます。

ボリュームはチケットの数です。数が多ければサポート体制、例えばヘルプデスクの人数などに影響があります。月ごとに追えば夏休みには少なく、年度末には多いといったことがわかるかもしれません。また定期的なシステム更新の際にもチケットがいきなり増えているといったケースもあります。全体の人数が減っているのにチケットの数が増えているのは何かおかしなことが起きて切る可能性もあります。

すべてのチケットを同様に管理するわけではありません。重要度はSeverityとも言います。少ないリソースでより良いプロセスを構築するにはすべてのチケットに対して同じように管理することは不可能です。チケットの重要度が高い、Sev1やSev2については例えばRCA(Root Cause Analysis)等が必要になります。

チケットはプロセスにより処理が進みます。チケットがオープンしてからクローズするまでには様々な段階を踏みます。この段階にかかる時間、ステータスの変化等を見ることで顧客満足度や問題がある体制、プロセスを明らかにすることができます。

他にもチケットは、ロケーション、部署、チャネル等いろいろな属性があります。これらの属性で層化して分析することでよりよい改善を目指すことができます。

ボリューム

チケットを管理する際の最も基本的な情報がチケットのボリュームです。

ボリュームを見るときには短期的と長期的の両方の視点から見る必要があります。

短期的な視点は前々日～当日のチケットボリューム変化を見ることです。この時重要なのはSev3になります。
例えばシステム切り替え後に"特定条件"や"特定地域"において発生するクリティカルなインシデントは当初把握することができません。しかし利用しているユーザーは使えないことがわかりますので、チケットを上げます。この時ユーザー自身はインシデントの広まり具合はわかりませんのでSev3で上がることになります。Sev3の数が突然スパイク上に上昇すればSev1もしくはSev2の初期段階である可能性があります。

長期的に見る際には、月ごとおよび去年のデータと比べることが重要です。このメトリックは主にヘルプデスクもしくはオンサイトサポートのヘッドカウントにも影響します。あなたがオペレーションマネージャーであるならば、来年度の予算どりをする際にもっとも有効となる証拠になります。

ボリューム分析をする際にはチケットのステータス、プロセス、SLA、その他属性と組み合わせばより詳細に分析をすることができます。

ダッシュボードに追加するメトリック

ダッシュボードには以下の項目ついてレポートを作っておけばよいでしょう。

短期的なメトリック

前々日、前日、当時のチケット数(重要度別)

長期的なメトリック(月別および年別)

オープンされたチケット(Sev1, Sev2)
SLA内でクローズされたチケット(Sev1, Sev2)

重要度

チケットの重要度は"ある程度"厳密に管理する必要があります。それぞれSev1, Sev2, Sev3, Sev3について明確に定義をしておき、迷った際にはその定義に照らし合わせて重要度を割り振ります。

声が大きいユーザーが強くクレームを入れてくると、つい重要度を上げたくなります。しかし定義が明確であれば、なぜその重要度が設定されているか説明できるので恣意的な設定を避けることができます。もしそれでも重要度を変更することが要求されても問題ありません。すでに重要度について説明したうえで、該当ユーザーのリクエストにより変更したことを記述したうえで変更すれ良いのです。これによりなぜその重要度になっているかが可視化され、さらに説明責任はユーザー側に移ります。

ダッシュボードに追加するメトリック

すでにダッシュボードにはSev1とSev2のメトリックが表示されているのでここで新しく追加すべきメトリックはないでしょう。

プロセス

インターネットやITILの教科書を見るとMTTR, MTTOなどメトリックの種類はたくさん出てきます。当初メトリックを考える上で最もわかりにくかった領域がこの"プロセス"におけるメトリックです。おそらくプロセス領域におけるメトリックはデータ分析をする際に最もやりがいがあり、かつ複雑になるメトリックといえます。なぜプロセスにおけるメトリックはわかりにくく、また種類が多いのでしょうか。

チケットを見る上でプロセスはステータスとして現れます。分析の際には各ステータスごとのボリュームを見ることは大事です。これだけであるならばボリューム分析の一環であり、全くややこしいことはありません。しかしプロセスには時間、経路、目標が絡んできます。

例えばチケットのプロセスをオープン→調査・解決→クローズと仮定してみます。この際にオープンからクローズまでの時間は当然興味を引く情報です。時間がかかる場合に明らか満足度に下がります。時間がかかっているのはサポートする人が少ないからなのか、問題が複雑なのか、それにより対応策も異なってきます。

また経路も重要です。例えばよく使われるのがResolution on First Callです。これは初回の連絡で解決したチケットのの数です。一般的でよくある問題であるならば、一回のやり取りで解決に持ち込むべきです。そのためにはトレーニング、インストラクション等を準備しておく必要があります。

最後がSLAです。例えばオープン→クローズまでの時間がSev1において、平均５分だとします。値を見るだけでは、この時間が長いか短いかを判断することはできません。例えばSLAが平均1分であるならば解決する必要があります。しかしSLAが1時間であるならば、とりあえず取り決め上は問題ありません。

ここで出てくる反論としては時系列でメトリックをとり、"常に短くしていく"ようにするべきだという要求です。メトリックを短くしようとすればするほど、用意するべきコストは指数関数的に増大します。ここではあまり突っ込みませんが、無茶苦茶な努力目標は百害あって一利なしです。

とりあえず考えるべきプロセスは以下のようなものです。

オープン
ファーストコール
調査及び解決
クローズ

ダッシュボードに追加するメトリック

情報は月別に表示し、過去１２か月でどのように変化しているかがわかるようにします。

オープン及びクローズ

オープンされたチケット数
クローズされたチケット数
オープンおよびクローズが同月のチケット数（割合）

解決にかかった時間

オープン～クローズまでの時間 (MTTR)、この値はSev別にターゲットが異なるのでSev別に出しておく。

SLA

SLA内に解決されたチケットの割合→SLAが異なるので、Sev別に算出しておく。

解決の状況（これらのメトリックの割合を増やすことが結果としてコストを下げる）

ファーストコール
リモートで解決されたチケット

その他属性

ここでは上記のダッシュボート組み合わせて利用できる属性についてまとめておきます。

チャネル別チケット

チャネルはチケットをオープンした人の属性になります。チケットはユーザー自身が挙げるヘルプデスクポータル、もしくはヘルプデスク等に電話をしてヘルプデスクが上げるといった方法があります。ヘルプデスクの人数を管理し効率化を目指すためにはポータル経由でのチケットオープンを目指す必要があります。

利用できるダッシュボード

ポータルからオープンされたチケットの割合
ヘルプデスクでオープンされたチケットの割合
その他

その他が多い場合には定義されたチャネル以外が多いために全体のプロセスを改善する必要があります。

ロケーション別

場所別に上げられたチケットの数、割合を管理します。例えば特定の言語地域でチケットが多い場合には、該当の言語でFAQなどを継続的に作成するといった対応が考えられます。

利用できるメトリック

ロケーション別チケット数

チケットの特殊な状態

その他特別なチケットの状態を探して、潜在的な問題を可視化できるメトリックがあります。

利用できるメトリック

メトリック	説明
繰り返し発生しているインシデント	例えば今はやりのテキスト分析等でおなじ種類のインシデントを明らかにすることができます
再オープンされたチケット	チケットの再オープンが発生してるということは調査が足りないか、提供された解決方法が中と反場であることが推測されます。特定のアプリケーション、特定の担当者で発生していないかを明らかにします。
再アサインされたチケット	チケットのアサイン先が変わった場合には、時間もかかります。またそもそも該当の内容から当初判断されたアサインが間違っていたことになります。これも特定のアプリケーション、特定の担当者で発生してるかを明らかにします。
滞留時間	滞留時間を層化してチケット数を明らかにします。SLAもしくは暫定的な基準値と使って滞留時間を減らすように定期的なレビュー（一週間毎くらい）や担当者への指導を実施します。また特定の地域で滞留時間が長い場合には、リソースがそもそも足りていないケースも考えられます。滞留時間も重要度別に異なる傾向があります。

チケットの層化

その他チケットの属性について層化ができます。分析に有用な属性をまとめました。

メトリック	説明
アプリケーショングループ	特定のアプリケーショングループで問題が多い場合にはシステム変更が多発していることが考えられます。さらにITILのシステム変更リストに出ていない場合には、管理外のシステム変更をしている可能性があります。
デパートメント	部署によっては特殊なアプリケーションを使い、問題が頻発していることがあります。例えばスーパーユーザーなどをアサインしてヘルプデスクに来る前に一段階入れる方法があります。

顧客満足度

顧客満足度は重要ですが、ITIL上でどのようにメトリックを取得するかというとなかなか難しい問題があります。よくあるパターンがチケットクローズ時に評価を入れるということがあります。しかしユーザーから見ると２度手間であり、社内向けヘルプデスクでそこまでやるかという考え方もあります。

顧客満足度はKPIといえますが、そのメトリックの取得方法については一考する必要があります。