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

アクティビティ属性は、サービスリクエストに対して実行された特定のステップまたはアクションを記述します。これらのアクティビティは、「リクエスト作成済み」、「リクエスト割り当て済み」、「作業中」、「リクエストクローズ済み」といったプロセスの連続的な構成要素を形成します。各アクティビティは、サービスリクエストのジャーニーにおける明確な時点を表します。

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

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

サービスリクエストオブジェクトに関連付けられたステータス変更ログ、イベントテーブル、または監査証跡から導出されることがよくあります。

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

プロセスマイニング分析において、このIDはすべてのリクエストのエンドツーエンドのジャーニーを再構築するための基本です。すべてのイベントを共通のCaseIdの下にグループ化することで、アナリストはプロセスフローを視覚化し、ケース期間を計算し、異なるリクエストがどのように処理されるかのバリエーションを特定できます。これは、サービスリクエスト管理プロセスに対して実行されるあらゆる分析の基礎となります。

このIDは、サービスリクエストのすべてのイベントを結合し、完全なエンドツーエンドのプロセスビューを可能にするために不可欠です。

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

開始時刻は、特定のアクティビティが開始された正確な日時を記録します。このタイムスタンプは、イベントを時系列に並べ、アクティビティの期間と全体的なケースのライフサイクルを計算するために非常に重要です。正確なイベントログを構築するには、プロセスの各アクティビティに対応する開始時刻が必要です。

プロセス分析では、開始時刻はサイクル時間、アクティビティ間の待機時間、アクティビティ処理時間などの主要なKPIを計算するために使用されます。これにより、プロセスを時間ベースでビュー化し、遅延を強調表示し、どのステップが最も時間を消費しているかを特定するのに役立ちます。正確なタイムスタンプは、あらゆるパフォーマンス関連の分析の基本です。

このタイムスタンプは、イベントを正しく順序付けし、サイクル時間やボトルネックなどのすべての時間関連メトリクスを計算するために不可欠です。

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

ソースシステム``属性は、データが抽出されたITサービスマネジメント（ITSM）プラットフォームまたはその他のアプリケーションの名前を指定します。複数のシステムがある環境では、このフィールドはデータソースの区別を助け、データリネージの明確化を保証します。

ほとんどのプロセスフロー分析では直接使用されませんが、データガバナンス、バリデーション、トラブルシューティングにとって不可欠です。複数のソースからデータを結合する場合、この属性によりアナリストはシステムごとにプロセスビューをセグメント化でき、異なるプラットフォーム間でのプロセス実行やデータ品質の違いを明らかにできます。

データガバナンスとトラブルシューティングにとって不可欠であり、特に複数の統合システムがある環境ではデータの起源を明確にします。

この値は通常、データ抽出（ETL）プロセス中にアドされ、ソースシステム自体に固有のフィールドではありません。

最終データ更新は、最新のデータ抽出または更新のタイムスタンプを提供します。これにより、ユーザーは分析しているデータの鮮度について知ることができ、分析が現在の状態を反映しているのか、過去のスナップショットを反映しているのかを理解できます。

この属性は、生成されたインサイトの適時性に関するコンテキストを提供するものであるため、運用監視およびレポート作成にとって不可欠です。これにより、ユーザーはデータを信頼し、その最新性に基づいて情報に基づいた意思決定を行うことができます。たとえば、1週間前に最終更新されたデータを示すダッシュボードは、1時間前に更新されたものとは異なる解釈がされます。

データの鮮度を示し、分析が関連性があり、最新情報に基づいていることを保証するために不可欠です。

これは、通常データ抽出（ETL）プロセス中に生成および保存されるメタデータ``フィールドです。

SLA期日は、リクエストに関連するサービスレベルアグリーメントに基づいて算出される目標タイムスタンプです。これは、リクエストのプライオリティ、タイプ、作成時間などの要因によって決定され、期待される解決期間を定義します。

この属性は、すべてのSLAコンプライアンス分析の基礎となります。実際の解決時間とSLA期日を比較することで、組織はリクエストが期限内に解決されたか、またはSLAが侵害されたかを判断できます。これはサービス品質を測定するための重要なKPIであり、遅延を引き起こし違反につながる体系的な問題を特定するために使用されます。

これはパフォーマンス測定のベンチマークです。SLAコンプライアンス率を計算し、どのリクエストが違反しているかを特定するために使用されます。

サービスリクエストレコード上の計算フィールドであることが多く、適用されるSLAポリシーによって決定されます。

サービスタイプは、サービスリクエストの性質を分類します。これは、新しいハードウェアやソフトウェアアクセスに関するリクエストから、一般的な問い合わせやテクニカルサポートまで多岐にわたります。この分類は、リクエストを適切なチームにルーティングし、異なるサービスに対する需要を理解するのに役立ちます。

プロセス分析において、サービスタイプはデータをセグメント化するための強力なディメンションです。プロセスマップを異なるサービスタイプでフィルタリングすることで、組織は特定の種類のリクエストが大幅に異なるプロセスをたどったり、より長いサイクルタイムを持っていたり、より多くの手戻りが発生したりすることを発見できます。このインサイトにより、特定のサービスカテゴリに対して的を絞ったプロセス改善努力が可能になります。

さまざまなリクエストカテゴリのプロセスをフィルタリングおよび比較でき、タイプごとの固有のボトルネックや非効率性を明らかにします。

サービスリクエストレコード上の標準フィールドで、多くの場合サービスカタログにリンクされています。

リクエストステータスは、そのライフサイクルにおける特定の時点でのサービスリクエストの状態を示します。一般的なステータスには、「新規」、「処理中」、「保留中」、「解決済み」、「クローズ済み」などがあります。この属性は、リクエストがプロセス全体でどこにあるかのスナップショットを提供します。

リクエストステータスの分析は、プロセスフローと状態遷移を理解するための鍵です。これを使用して、ケースをフィルタリングし、特定の状態に滞留しているリクエストを特定し、各ステータスで費やされた時間を測定できます。例えば、「保留中」ステータスにリクエストがどれくらいの期間留まっているかを分析することで、ユーザーや外部チームからの情報を待つことによる遅延が明らかになります。

各ステータスでリクエストがどれくらいの時間を費やすかを分析でき、プロセスのボトルネックや遅延を強調表示します。

メインのサービスリクエストテーブルまたはステータス履歴ログで利用可能です。

リクエスト優先度とは、サポートチームがリクエストを処理する順序を決定するのに役立つ分類です。これは通常、リクエストがビジネスに与える影響と緊急性の組み合わせに基づいて決定されます。一般的な優先度レベルには、低、中、高、クリティカルがあります。

この属性は、パフォーマンス分析とリソース割り当てにとって不可欠です。アナリストは、異なる優先度レベル間のサイクルタイムとSLA遵守率を比較し、高優先度のリクエストが適切に処理されていることを確認できます。また、低優先度のリクエストが無視されていないか、または優先度付けシステムがサポートチームによって正しく遵守されているかを特定するのにも役立ちます。

リクエストがビジネスの重要性に応じて処理されているかを分析し、優先度が解決時間にどのように影響するかを理解するために不可欠です。

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

割り当てられたチームとは、サービスリクエストを担当する特定のサポートグループを指します。リクエストは、必要な専門知識に応じて、レベル1ヘルプデスク、ネットワークチーム、ソフトウェア開発チームなど、異なるチーム間でルーティングされることがよくあります。

チーム間の引き渡しを分析することは、サービス管理プロセスマイニングの中核をなす部分です。この属性により、チーム間の転送を視覚化でき、コミュニケーションのギャップや遅延の特定に役立ちます。また、チーム間のパフォーマンスベンチマーキングも可能にし、効率性、リクエスト量、さらなるエスカレーションなしでリクエストを解決する能力を比較できます。

チーム間のプロセス引き渡しを分析し、引き渡し時の遅延を特定し、チームのパフォーマンスを比較するために不可欠です。

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

割り当てられたエージェントとは、特定の時点でサービスリクエストの処理を担当する特定の人物です。リクエストは、そのライフサイクルを通じて異なるエージェントに割り当てられることがあります。

この属性は、パフォーマンスおよびワークロード分析にとって重要です。これにより、組織は個々のエージェントのパフォーマンス（平均解決時間や処理するリクエストの量など）を測定および比較できます。また、エージェント間の再割り当てを分析するためにも使用され、初期トリアージ、エージェントの専門化、またはワークロードのバランスに関する問題を示唆する可能性があります。

個々のエージェントのパフォーマンス、ワークロードの配分、およびエージェント間の再割り当ての頻度の分析を可能にします。

サービスリクエストレコードで利用可能です。このフィールドの変更は、多くの場合、監査ログまたは履歴テーブルで追跡されます。

このブーリアン``属性は、サービスリクエストが定義されたサービスレベルアグリーメントを満たせなかったかどうかを示します。リクエストがSlaDueDate後に解決された場合はtrue、それ以外の場合はfalseです。

この属性は、SLAコンプライアンスレポート作成と分析を簡素化します。すべてのクエリで日付比較を行う代わりに、このシンプルなフラグを使用することで、簡単なフィルタリングとアグリゲーションが可能になります。これはSLAパフォーマンスに焦点を当てたダッシュボードの主要メトリクスであり、サービスターゲットを満たしていないリクエストのボリュームと割合を迅速に特定するのに役立ちます。

SLAパフォーマンス分析のための明確でシンプルなフラグを提供し、違反されたリクエストのフィルタリングとレポート作成を容易にします。

これは、データ変換中に最終的な解決タイムスタンプをSlaDueDate``フィールドと比較することによって計算される派生属性です。

この属性は、サービスリクエストを開始した人物の部署または事業ユニットを識別します。これにより、リクエストに組織的なコンテキストが提供されます。

部署別にリクエストを分析することで、部署特有のニーズ、傾向、または問題点を特定できます。例えば、財務部門からの特定のリクエストタイプのボリュームが多い場合、ターゲットを絞った研修やシステム改善の必要性を示している可能性があります。また、チャージバックレポート作成や、組織全体のITサービスに対する需要理解にも役立ちます。

組織のコンテキストを提供し、事業部門ごとのリクエストパターンとサービス需要の分析を可能にします。

この情報は通常、従業員ディレクトリまたはITSM``システム内の申請者のユーザープロファイルから取得されます。

再割り当て回数は、サービスリクエストがあるエージェントまたはチームから別のエージェントまたはチームに転送された合計回数を示す指標です。回数が多い場合、初期ルーティングの誤り、エージェントの知識不足、または不明確なプロセス所有権といった問題を示唆する可能性があります。

これはプロセスの非効率性を示す主要な指標です。プロセスマイニングにおいて、この指標はリクエストが経験する「ピンポン」の量を定量化するのに役立ちます。再割り当て回数が多いケースを分析することで、トリアージプロセスの改善、エージェントトレーニングの強化、またはチームの責任の再定義を行い、リクエストが初回で正しくルーティングされるようにする機会を明らかにできます。

プロセス非効率性を特定する重要な指標です。再割り当て回数が多いと、解決時間の長期化やユーザー不満の増加につながる傾向があります。

これは、特定のCaseIdに対してAssignedAgentまたはAssignedTeam``フィールドが変更された回数をカウントすることで導出される計算メトリクスです。

申請チャネルは、サービスリクエストがどのように作成されたかを示します。例えば、セルフサービスポータル、メール、電話、またはAPI経由などです。異なるチャネルは、異なる関連プロセスやユーザーエクスペクテーションを持つ場合があります。

申請チャネル別にプロセスを分析することで、重要なインサイトが明らかになります。例えば、セルフサービスポータル経由で提出されたリクエストは、メール経由で提出されたものよりも構造化されており、解決が速い可能性があります。メールの場合、手動データ入力が必要になることがあります。この分析は、組織がより効率的なチャネルを促進したり、効率の低いチャネルのプロセスを改善したりするのに役立ちます。

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

通常、サービスリクエストレコード上の標準フィールドとして見つかります。

終了時刻は、特定のアクティビティが完了した正確な日時を記録します。開始時刻が始まりを示すのに対し、終了時刻は完了を示し、単一のプロセスステップの期間を定義します。すべてのイベントに明確な終了時刻があるわけではなく、瞬間的なものもあります。

この属性は、個々のアクティビティの処理時間を計算するために不可欠です。開始時刻から終了時刻を引くことで、アナリストはエージェントやシステムがタスクに積極的に費やした時間を測定できます。これにより、どの特定のアクティビティが時間を消費しており、最適化または自動化の主要な候補であるかを特定するのに役立ちます。

アクティビティの処理時間の計算を可能にし、プロセス内でどの特定のステップが最も時間のかかるものかを特定するのに役立ちます。

イベントログまたは監査証跡テーブルにあります。明示的に利用できない場合は、次のアクティビティの開始時間を使用して導出する必要がある場合があります。

解決コードは、サービスリクエストの結果を分類するための構造化された方法を提供します。例としては、「ユーザーによって解決済み」、「ハードウェア交換済み」、「ソフトウェアデプロイ済み」、「重複リクエスト」などがあります。この情報は通常、リクエストをクローズする際にエージェントによって入力されます。

これらのコードは根本原因分析に価値があります。異なる解決コードの頻度を分析することで、組織は繰り返し発生する問題、一般的な解決策、およびナレッジベース記事の作成または自動解決の機会を特定できます。例えば、「パスワードリセット」の解決コードが多数ある場合、セルフサービスパスワードリセットツールへの投資を正当化する可能性があります。

リクエストがどのように解決されたかを分類することで、根本原因分析を可能にし、傾向やプロアクティブな問題管理の領域を特定するのに役立ちます。

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