サービスリクエスト管理向けデータテンプレート

アクティビティ属性は、サービスリクエストに対して実行された特定のステップまたは操作を示します。これらのアクティビティは、「Request Created」、「Request Assigned」、「Work In Progress」、「Request Closed」など、プロセスを構成する順序立った要素です。それぞれのアクティビティは、サービスリクエストの流れにおける特定の時点を表します。

アクティビティの分析は、プロセスマイニングの中心です。実際のプロセスフローを発見し、可視化できます。アクティビティの順序と頻度を調べることで、よくある経路、標準プロセスからの逸脱、リクエストが滞留するボトルネック、不要なステップが繰り返される手戻りループを特定できます。

プロセスの各ステップを定義し、実際のプロセスフロー、ボトルネック、逸脱の発見を可能にします。

通常、サービスリクエストオブジェクトに関連付けられたステータス変更ログ、イベントテーブル、または監査証跡から取得します。

サービスリクエストIDは、ライフサイクル全体を通じて各サービスリクエストを一意に識別する主キーです。ケース識別子として機能し、関連するすべてのアクティビティ、ステータス変更、属性を1つの一貫したプロセスインスタンスに結び付けます。

プロセスマイニング分析では、このIDが各リクエストのエンドツーエンドの流れを再構築する基盤になります。すべてのイベントを共通のCaseIdでグループ化することで、分析担当者はプロセスフローを可視化し、ケースの所要時間を計算し、リクエストごとの対応方法の違いを特定できます。サービスリクエスト管理プロセスの分析に欠かせない基盤です。

このIDは、サービスリクエストのすべてのイベントをつなぎ合わせ、エンドツーエンドのプロセス全体を把握するために欠かせません。

通常、サービスリクエストのヘッダーまたは主要なトランザクションテーブルにあります。

開始時刻は、特定のアクティビティが開始した正確な日時を記録します。このタイムスタンプは、イベントを時系列に並べ、アクティビティの所要時間とケース全体のライフサイクルを計算するために欠かせません。正確なイベントログを作成するには、プロセス内の各アクティビティに対応する開始時刻が必要です。

プロセス分析では、開始時刻を使ってサイクルタイム、アクティビティ間の待機時間、アクティビティの処理時間などの主要業績評価指標を計算します。時間に基づくプロセスのビューを作成できるため、遅延を把握し、最も時間を要するステップを特定できます。正確なタイムスタンプは、パフォーマンスに関する分析の基盤です。

イベントを正しい順序に並べ、サイクルタイムやボトルネックなど、時間に関するすべての指標を計算するために欠かせません。

イベントログまたは監査証跡テーブルにあり、各アクティビティレコードの「作成日」または「イベントタイムスタンプ」として記録されることがよくあります。

ソースシステム属性は、データを抽出したITサービスマネジメント（ITSM）プラットフォームまたはその他のアプリケーションの名称を示します。複数のシステムがある環境では、このフィールドによってデータソースを区別し、データの出所を明確にできます。

通常のプロセスフロー分析で直接使うことは多くありませんが、データガバナンス、検証、トラブルシューティングには欠かせません。複数のソースからデータを統合する場合、この属性でシステム別にプロセスビューを分けることができ、プラットフォーム間のプロセス実行やデータ品質の違いを明らかにできます。

データの出所を明確にするため、データガバナンスとトラブルシューティングに欠かせません。複数の統合システムがある環境では特に重要です。

通常、データ抽出（ETL）プロセスで追加され、ソースシステム自体に本来備わっているフィールドではありません。

最終データ更新は、直近のデータ抽出または更新のタイムスタンプを示します。分析対象のデータが現在の状態を反映しているのか、過去のスナップショットなのかを判断するために、データの鮮度を把握できます。

この属性は、運用監視とレポート作成に欠かせません。生成された分析結果がどの時点の情報に基づくものかを示し、結果の適時性を判断するための背景を提供します。データを信頼し、更新時点を踏まえて意思決定するうえでも役立ちます。たとえば、1週間前に更新されたデータを表示するダッシュボードと、1時間前に更新されたダッシュボードでは、結果の解釈が異なります。

データの鮮度を示します。分析が現在の状況に即し、最新情報に基づいていることを確認するうえで重要です。

通常、データ抽出（ETL）プロセスで生成・保存されるメタデータフィールドです。

SLA期限は、リクエストに関連付けられたサービスレベル合意に基づいて計算される目標時刻です。リクエストの優先度、種類、作成時刻などの要素によって決まり、想定される解決期限を定義します。

この属性は、SLA遵守状況を分析するための基準です。実際の解決時刻とSLA期限を比較することで、期限内に解決されたか、SLA違反が発生したかを判断できます。サービス品質を測定する主要KPIであり、遅延や違反につながる構造的な問題の特定にも使われます。

パフォーマンスを測定する基準です。SLA遵守率の計算や、SLA違反が発生したリクエストの特定に使用します。

多くの場合、適用されたSLAポリシーに基づいて決まる、サービスリクエストレコード上の計算フィールドです。

サービスタイプは、サービスリクエストの内容を分類します。新しいハードウェアやソフトウェアへのアクセスの依頼から、一般的な問い合わせや技術サポートまで、さまざまな種類があります。この分類により、適切なチームへリクエストを振り分け、サービスごとの需要を把握できます。

プロセス分析では、サービスタイプがデータを分けて見るための有効な軸になります。サービスタイプごとにプロセスマップを絞り込むことで、特定のリクエストが大きく異なるプロセスをたどる、サイクルタイムが長い、手戻りが多いといった傾向を明らかにできます。これにより、サービスカテゴリごとに改善策を検討できます。

リクエストカテゴリごとにプロセスを絞り込み、比較できます。種類ごとの固有のボトルネックや非効率性を明らかにできます。

サービスリクエストレコードにある標準フィールドで、サービスカタログに関連付けられていることがよくあります。

リクエストステータスは、ライフサイクルの特定時点におけるサービスリクエストの状態を示します。一般的なステータスには、New、In Progress、Pending、Resolved、Closedがあります。この属性により、リクエストがプロセス全体のどの位置にあるかを把握できます。

リクエストステータスの分析は、プロセスフローと状態遷移を理解するうえで重要です。ケースの絞り込み、特定の状態で滞留しているリクエストの特定、各ステータスに費やした時間の測定に利用できます。たとえば、「Pending」状態にどの程度とどまっているかを分析すると、ユーザーや外部チームからの情報待ちによる遅延を明らかにできます。

各状態にリクエストがとどまる時間を分析できるため、プロセスのボトルネックや遅延を把握できます。

主要なサービスリクエストテーブルまたはステータス履歴ログで確認できます。

リクエスト優先度は、サポートチームが対応順序を決めるための分類です。通常、業務への影響度と緊急度を組み合わせて決定します。一般的な優先度には、Low、Medium、High、Criticalがあります。

この属性は、パフォーマンス分析とリソース配分に欠かせません。優先度ごとにサイクルタイムとSLA遵守状況を比較し、高優先度のリクエストが適切に処理されているか確認できます。また、低優先度のリクエストが放置されていないか、サポートチームが優先順位付けのルールに従っているかも分析できます。

リクエストが業務上の重要度に応じて処理されているかを分析し、優先度が解決時間に与える影響を理解するために欠かせません。

通常、主要なサービスリクエストレコードにある標準フィールドです。

担当エージェントは、特定の時点でサービスリクエストの対応責任を負う人物です。リクエストのライフサイクル中に、担当が別のエージェントへ変わる場合があります。

この属性は、パフォーマンスと作業負荷の分析に欠かせません。個々のエージェントの平均解決時間や対応件数を測定・比較できます。また、エージェント間の再割り当てを分析し、初期トリアージ、エージェントの専門性、作業負荷の配分に関する問題を把握できます。

個々のエージェントのパフォーマンス、作業負荷の分布、エージェント間の再割り当て頻度を分析できます。

サービスリクエストレコードで確認できます。このフィールドの変更は、監査ログまたは履歴テーブルで追跡されることがよくあります。

担当チームは、サービスリクエストに対応する特定のサポートグループを指します。必要な専門知識に応じて、リクエストはレベル1ヘルプデスク、ネットワークチーム、ソフトウェア開発チームなど、複数のチーム間で振り分けられます。

チーム間の引き継ぎを分析することは、サービス管理のプロセスマイニングの中心です。この属性により、チーム間の移管を可視化し、コミュニケーション上の不足や遅延を特定できます。また、チームごとの効率、対応件数、追加のエスカレーションなしで解決する能力を比較し、パフォーマンスを評価できます。

チーム間のプロセス引き継ぎを分析し、移管時の遅延を特定し、チームのパフォーマンスを比較するために欠かせません。

サービスリクエストレコードにある標準フィールドです。このフィールドの変更は監査ログで追跡されます。

この真偽値属性は、サービスリクエストが定義されたサービスレベル合意を満たしたかどうかを示します。リクエストが「SlaDueDate」より後に解決された場合はtrue、それ以外はfalseです。

この属性により、SLA遵守状況の報告と分析が簡単になります。クエリごとに日付を比較する代わりに、この単純なフラグで容易に絞り込みや集計ができます。SLAパフォーマンスに焦点を当てたダッシュボードの主要指標であり、サービス目標を満たしていないリクエストの件数と割合をすばやく把握できます。

SLAパフォーマンスを分析するための明確で単純なフラグを提供し、SLA違反が発生したリクエストの絞り込みと報告を容易にします。

派生属性です。データ変換時に、最終解決タイムスタンプと「SlaDueDate」フィールドを比較して計算します。

この属性は、サービスリクエストを開始した人物の部署または事業部門を示し、リクエストに組織上の背景を付加します。

部門別にリクエストを分析すると、部門固有のニーズ、傾向、問題を特定できます。たとえば、財務部門から特定の種類のリクエストが大量に発生している場合、対象を絞ったトレーニングやシステム改善が必要な可能性があります。また、チャージバックレポートの作成や、組織全体におけるITサービスの需要把握にも役立ちます。

組織上の背景を提供し、事業部門ごとのリクエスト傾向とサービス需要を分析できます。

通常、従業員ディレクトリまたはITSMシステムにある依頼者のユーザープロファイルから取得します。

再割り当て回数は、サービスリクエストがある担当者またはチームから別の担当者またはチームへ移管された回数を合計した指標です。回数が多い場合、初回の振り分けミス、担当者の知識不足、プロセスの責任範囲が不明確であることなどが考えられます。

これは、プロセスの非効率性を把握するための重要な指標です。プロセスマイニングでは、リクエストが担当者やチームの間を何度も行き来する状況を定量化できます。再割り当て回数が多いケースを分析すると、トリアージプロセスの改善、担当者研修の強化、チームの責任分担の見直しなど、リクエストを初回から正しく振り分けるための改善機会が見つかります。

プロセスの非効率性を特定するための重要な指標です。再割り当て回数が多い場合、解決時間の長期化やユーザー満足度の低下と相関することがよくあります。

これは、特定の「CaseId」に対して「AssignedAgent」または「AssignedTeam」フィールドが変更された回数を数えて算出する指標です。

申請チャネルは、サービスリクエストがどのように作成されたかを示します。たとえば、セルフサービスポータル、メール、電話、APIなどです。チャネルによって、関連するプロセスやユーザーの期待が異なる場合があります。

申請チャネル別にプロセスを分析すると、重要な傾向を把握できます。たとえば、セルフサービスポータルから送信されたリクエストは構造化されているため、手動入力が必要になりやすいメール経由のリクエストよりも早く解決できる場合があります。この分析により、効率の高いチャネルの利用を促進したり、効率の低いチャネルのプロセスを改善したりできます。

申請方法がプロセスの効率、解決時間、または初回接触解決率に影響するかを判断するのに役立ちます。

通常、サービスリクエストレコードの標準フィールドとして確認できます。

終了時刻は、特定のアクティビティが完了した正確な日時を記録します。開始時刻が開始点を示すのに対し、終了時刻は終了点を示し、1つのプロセスステップの所要時間を定義します。イベントによっては瞬時に完了するため、明確な終了時刻がない場合もあります。

この属性は、個々のアクティビティの処理時間を計算するために欠かせません。終了時刻から開始時刻を引くことで、エージェントやシステムがタスクの処理に費やした時間を測定できます。これにより、時間を要するアクティビティや、効率化・自動化の候補となるステップを特定できます。

アクティビティの処理時間を計算できるため、プロセス内で特に時間を要するステップを特定できます。

イベントログまたは監査証跡テーブルにあります。明示的に記録されていない場合は、次のアクティビティの開始時刻から導出する必要があります。

解決コードは、サービスリクエストの結果を構造化して分類する方法です。例として、「Solved by User」、「Hardware Replaced」、「Software Deployed」、「Duplicate Request」などがあります。通常、リクエストをクローズする際にエージェントが入力します。

これらのコードは、根本原因分析に役立ちます。解決コードごとの頻度を分析することで、繰り返し発生する問題、よく使われる解決策、ナレッジベース記事の作成や解決の自動化に向けた機会を特定できます。たとえば、「Password Reset」が多数を占める場合、セルフサービスのパスワードリセットツールへの投資が有効な可能性があります。

リクエストの解決方法を分類して根本原因を分析し、傾向や予防的な問題管理の対象を特定できます。

通常、サービスリクエストの解決時またはクローズ時に、エージェントが手動で入力するフィールドです。