プロセスマイニングで進めるITSMプロセス最適化

ITSMプロセスの最適化：ITILのプラクティスと実際のチケット経路を比較する

ITSMプロセスの最適化には、インシデントやリクエストがサービスデスクを実際にどう進むのかを把握することが欠かせません。ITILはサービス管理の指針を示します。一方、チケットデータからは、業務が想定どおりに進んでいるか、再割り当てでどこに遅れが生じているか、どのケースがSLAを満たせていないかを確認できます。プロセスマイニングはイベントデータから業務の流れを再構成し、継続的改善に向けた判断材料を提示します。

ITILの枠組みと実務にずれが生じる理由

ITILは、サービス管理に共通のアプローチを提供します。文書化されたインシデントプロセスでは、インシデントの記録、分類、優先順位付け、割り当て、調査、解決の方法が定められている場合があります。一方、チケット記録には実際の対応が残り、例外や回避策など、文書に反映されていない内容も確認できます。

こうした違いが生じるのは自然なことです。チームや責任の範囲は変わり、ツールやポリシーも進化します。ある問題を解決するために導入した振り分けルールが、別の場所で引き継ぎを増やすこともあります。チケットを早く処理するための回避策が日常化しても、文書化されたプロセスは変わらない場合があります。

ダッシュボードでチケット件数や平均解決時間を確認できますが、集計値だけでは各ケースがたどった経路は分かりません。複数回の引き継ぎで遅れが生じても、全体の平均値から原因を特定できないことがあります。プロセスマイニングでは、イベントデータを使って各ケースの順序、所要時間、結果を再構成します。実際の経路を、想定していたプロセスと比較できます。

これにより、焦点を絞った問いを立てやすくなります。どの種類のインシデントが最も頻繁に再割り当てされているか。ケースの待機前と待機後のどちらで優先度が変更されているか。どの経路でSLA未達が起きているか。こうした問いへの答えをもとに、すべての例外を失敗とみなさずに、調査すべき箇所を判断できます。

プロセスマイニングがITILにもたらすもの

プロセスマイニングは、既存のITILプラクティスに実行状況の根拠を加えます。ITSMの記録システムや、サービス提供を管理する担当者に代わるものではありません。ServiceNowやJiraなどのシステムからイベントデータを分析し、ケースの流れを把握して、プロセス変更の影響を評価します。

観測した経路を想定するワークフローと比較し、どのバリアントが多く発生しているか、ケースがどこで待機したり別の経路に進んだりするかを確認できます。また、サービス目標に結び付いた重要業績評価指標（KPI）で、プロセスの健全性を継続的に追跡できます。

継続的な改善を、次のような形で支援します。

• 振り分けルールやポリシーを変更する前にベースラインを設定する。
• 遅延、再割り当て、例外が集中する箇所を見つける。
• 変更後の結果をベースラインと比較する。
• ケース単位の根拠を使い、レビューや改善作業の対象を絞る。

どのポリシーを採用すべきかを、プロセスマイニングが決めるわけではありません。現在のプロセスの動きを示すことで、チームが根拠に基づいて判断し、その後の結果を評価できるようにします。

試験導入を選ぶ前に、チケットログから何が分かるかを把握しましょう。分析に関する文書では、プロセスバリアントとパフォーマンスの調べ方を説明しています。

ITSM担当者が追跡すべき5つの指標

サービスの成果を適切に表す指標を選びましょう。チーム間や期間ごとの比較を始める前に、各KPIの基礎となるイベントとケース項目の定義をそろえてください。

これらの指標は組み合わせて確認してください。再割り当て率が高くても、ケースが目標を達成できていれば、対応可能な範囲かもしれません。一方、再割り当てと未解決案件の長期化、SLA達成率の低下が同時に起きている場合は、振り分けのルールを調べる根拠がより明確になります。

ケースの数え方、優先度の変更の特定方法、SLA達成率の算出方法を定義してください。定義をそろえることで、分析をサービス方針に沿ったものにし、比較の有用性を高められます。

ITILのプラクティスにおける位置づけ

プロセスマイニングを使うと、ITSMシステム内で業務がどのように進むかを確認でき、複数のITILプラクティスを支援できます。レビューに役立つ根拠を示すものであり、プラクティスやそのガバナンス、信頼できる唯一の情報源に代わるものではありません。

• **インシデント管理：**振り分け、再割り当て、解決までの経路、SLAの結果を確認します。インシデントが滞留する箇所や、想定外の経路をたどる箇所を見つけます。
• **問題管理：**繰り返し発生するインシデントのパターンを比較し、調査すべきプロセス上の問題を特定する手がかりにします。根拠は問題管理に役立ちますが、プロセスマイニングだけで根本原因を特定することはできません。
• **変更の実現：**変更が評価や承認の各段階をどのように進むか、また意図したプロセスと異なる経路をたどるケースがどこで発生するかを確認します。
• **サービスリクエスト管理：**リクエストの振り分け、引き継ぎ、待ち時間、完了までの経路を分析し、停滞や手戻りが発生する箇所を見つけます。

同じ根拠を使って、プロセス変更の効果を評価することもできます。ケースの定義とKPIをそろえ、ベースラインと変更後の実行状況を比較します。結果が予想と異なる場合は、変更の背景にある経路や条件を調べてください。

IT分野のユースケースについては、ITプロセスの最適化をご覧ください。

プロセスマイニングを利用できるその他の分野

同じ方法を使って、ITSM以外のチームもシステム内で業務がどのように進むかを把握できます。プロセスや指標は異なっても、確認すべき点は共通しています。業務がどこで滞留するのか、引き継ぎが繰り返されるのはどこか、望ましい結果につながる経路はどれか、といった点です。

• 買掛金管理では、請求書の振り分け、承認の遅れ、例外を確認します。
• シェアードサービスでは、チーム間でリクエストがどのように進むかを比較し、繰り返し発生する引き継ぎを特定します。
• 製造では、プロセスの流れを分析し、業務が滞留する箇所や想定外の経路をたどる箇所を調べます。

これらは検討の出発点であり、データの内容を決めつけるものではありません。分析したいプロセスに関係するアクティビティとタイムスタンプが、イベントログに記録されている必要があります。

ITSMのプロセスマイニングを始める

まずは1つのプロセスと、チケットデータから答えを得られる問いを選びましょう。再割り当て、優先度の変更、SLA達成率を調べたい場合は、インシデント管理から始めるとよいでしょう。

1. **対象範囲を決めます。**分析するインシデント、チーム、期間を定義します。
2. **イベントデータをエクスポートします。**ケース識別子、アクティビティ、タイムスタンプに加え、優先度、担当チーム、SLAの結果など、関連する項目を含めます。
3. **データを確認します。**各ケースのイベントを順序づけられること、また分析したい問いに必要な項目がそろっていることを確認します。
4. **ベースラインを設定します。**指標の定義について合意し、プロセスを変更する前に現在の結果を記録します。
5. **調査して検証します。**KPIの背景にある経路を確認し、変更内容を決めたうえで、後の結果をベースラインと比較します。

ServiceNowとJiraのエクスポートデータはそのまま読み込めるため、連携を設定せずにチケットデータから始められます。ProcessMindはプロセスデータを分析しますが、記録システムは引き続きITSMシステムです。

ベースラインを有効に使えるよう、始める前に指標を選びましょう。イベントデータからプロセスの全体像を把握する方法については、プロセスマイニングとは何かをご覧ください。

チケットのエクスポートデータからインシデントプロセスを分析する

チケットデータを使って、ケースごとの再割り当て、優先度の逆転、SLA達成率を調べましょう。まずはデータをエクスポートし、インシデントプロセスの実態を確認してください。