IT業務を効率化

ITプロセスの最適化

サービスデスクの記録から、業務の実態を把握できます。チケットの履歴を分析すれば、インシデントの担当が何度引き継がれたか、優先度が予期せず変更されたか、関連する再分類がないままSLA違反が何件発生したかを確認できます。プロセスマイニングで、こうしたパターンと解決時間やサービスの成果を結び付ければ、経営層が信頼できるKPIの設定に役立つ根拠が得られます。

チケット履歴から分かるインシデント対応の実態

まず、次の3つのパターンを確認します。

• **ケースごとの再割り当て回数：**インシデントがチームや担当者間を何回移動したかを数えます。引き継ぎの繰り返しは、担当範囲の不明確さ、振り分けの問題、情報不足を示している場合があります。
• **優先度の変更：**インシデントのライフサイクル全体を通じて、優先度がどのように変化したかを追跡します。解決時間やSLAの結果と比較します。
• **再分類されないままのSLA違反：**関連する優先度やステータスの変更がないままSLA違反となったインシデントを見つけます。再分類を問題検知の条件とするレポートでは、こうしたケースを見落とすことがあります。

これらはチケット履歴から確認できる問いであり、チームについての決めつけではありません。確認できる内容は、エクスポートデータに含まれる項目やタイムスタンプによって異なります。

プロセスマイニングによるITプロセスの最適化

プロセスマイニングでは、イベントデータからチケットの流れを再構成します。インシデントが実際にたどる経路を比較し、待ち時間や手戻りで前の工程に戻る箇所を見つけ、サービス、チーム、優先度、その他の利用可能な属性ごとに結果の違いを確認できます。

インシデントの解決時間を分析する際は、合計時間だけでなく、データが許す場合は実作業時間と待ち時間を分けて確認します。そのうえで、どの引き継ぎやプロセスのバリアントが長い解決時間やSLA未達と関連しているかを調べます。

この分析はITSMツールを補完するものです。チケットの管理やサービス業務の記録に使用しているシステムに代わるものではありません。

分析できるITILプラクティス

ITILでは、サービスマネジメントのプラクティスが定義されています。プロセスマイニングを使うと、それらのプラクティスに関するイベントデータを調べ、実際のチケットの流れを文書化されたプロセスと比較できます。

分析結果を、プロセスについて話し合う際の参考にしてください。データからパターンの発生箇所は分かりますが、原因の特定と変更の判断には、サービスオーナーの知見が必要です。

ITSMプロセス全体で測定できる項目

適切なイベントログがあれば、次の重要業績評価指標（KPI）を定義できます。

• インシデントの解決時間とSLA達成状況
• ケースごとの担当変更と引き継ぎの回数
• 優先度の変更とSLA違反との関係
• 再オープンと手戻り
• リクエストの承認時間と処理時間
• 変更の結果とプロセスのバリアント
• 処理件数と業務量の推移

チーム間の比較や結果の報告を始める前に、KPIの定義を合意しておきます。対象ケース、開始イベントと終了イベント、SLAのルールを明確にし、全員が同じ基準で測定値を解釈できるようにしてください。

分析結果を改善につなげる方法

まず、サービスチームが答えを必要としている問いを1つ選びます。たとえば、担当変更が最も多いインシデントの種類は何か、SLA違反はどこで発生しているか、リクエストのどの手順で待ち時間が最も長いか、といった問いです。

次の手順で進めます。

1. ケース識別子、アクティビティ名、タイムスタンプ、関連する属性を含むチケット履歴をエクスポートします。
2. イベントデータが分析対象のプロセスを表しているか確認します。
3. 検出されたプロセスフローを確認し、結果ごとにバリアントを比較します。
4. サービスに責任を持つ担当者とKPIを定義します。
5. 根拠をもとに、考えられるプロセス変更を検討します。

プロセスマッピングでは、想定するフローを文書化し、実際の動きとの違いを話し合いやすくします。シミュレーションを使えば、変更を実施する前に、提案するシナリオを比較できます。変更そのものを実行する機能ではありません。

経営層が信頼できるKPIを作る方法

各KPIの根拠となるデータと定義を追跡できるようにします。対象となるイベント、タイムスタンプが欠けている場合の扱い、SLA違反の条件、優先度の変更が報告に与える影響を文書化してください。

期間やチームを比較する際は、定義を統一します。チケット履歴に重要なイベントが記録されていない場合は、測定値を完全なものとして示さず、その制約を明記してください。明確な定義と注意事項があれば、コンテキストのないダッシュボードよりも、経営層が判断を下す際の確かな根拠になります。

プロセスダッシュボードと重要業績評価指標（KPI）の作成方法を見る

開始に必要なデータ

まず、次の情報を含むインシデントまたはリクエストのエクスポートデータを用意します。

• 変わらないチケットまたはケース識別子
• アクティビティ名またはステータスの変更
• イベントのタイムスタンプ
• 優先度、担当グループ、サービス、SLAの結果などの関連項目（データがある場合）

ServiceNowやJiraのエクスポートデータは、連携作業なしで直接読み込めます。分析できる内容は、エクスポートデータに含まれる項目と、その記録の一貫性によって異なります。次に、ProcessMindでマッピングを検証し、最初のKPIを算出して、推移を示すダッシュボードを作成します。

最初に分析するテーマの選び方

サービスデスクのプロセスを1つ選び、問いを1つ設定します。たとえば、インシデントの担当変更のパターンや、優先度の変更に表れないSLA違反から始められます。ほかのITSMプロセスに広げる前に、イベントデータを検証し、KPIの定義を合意したうえで、サービスオーナーと結果を確認してください。

ITILとプロセスマイニングの概要については、ITSMとプロセスマイニングのガイドをご覧ください。また、プロセスを分析してボトルネックを見つける方法もご確認いただけます。

しきい値を設定してプロセスの健全性を監視する方法については、プロセス健全性の文書をご覧ください。

チケットのエクスポートデータから、インシデントまたはリクエストの流れを分析