サービス依頼管理のデータテンプレート

アクティビティ属性は、サービスリクエストに対して実行された特定のステップや操作を表します。「リクエスト作成」「リクエスト割り当て」「作業中」「リクエストクローズ」などのアクティビティが連なり、プロセスを構成します。それぞれのアクティビティは、サービスリクエストの進行過程における特定の時点を示します。

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

プロセスの各ステップを定義し、実際のプロセスフローやボトルネック、逸脱の把握に役立ちます。

サービスリクエストに関連するステータス変更ログ、イベントテーブル、監査証跡から取得することがよくあります。

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

プロセスマイニング分析では、このIDを使って各リクエストの開始から終了までの流れを再構成します。共通のCaseIdでイベントをグループ化すると、プロセスフローの可視化、ケース所要時間の算出、リクエストごとの対応の違いの特定が可能になります。サービスリクエスト管理プロセスの分析に欠かせない項目です。

サービスリクエストに関するすべてのイベントを結び付け、プロセス全体を把握するために必要なIDです。

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

開始時刻には、特定のアクティビティが始まった正確な日時が記録されます。このタイムスタンプは、イベントを時系列に並べたり、アクティビティの所要時間やケース全体のライフサイクルを算出したりするうえで重要です。正確なイベントログを作成するには、各アクティビティに対応する開始時刻が必要です。

プロセス分析では、開始時刻を使ってサイクルタイム、アクティビティ間の待ち時間、アクティビティの処理時間などの重要業績評価指標を算出します。時間軸に沿ってプロセスを確認できるため、遅延や時間のかかるステップを特定できます。パフォーマンス分析には、正確なタイムスタンプが欠かせません。

イベントを正しい順序に並べ、サイクルタイムやボトルネックなど、時間に関する指標を算出するために重要です。

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

ソースシステム属性には、データの抽出元であるITサービス管理（ITSM）プラットフォームやその他のアプリケーションの名称が記録されます。複数のシステムを使用する環境では、この項目によってデータソースを区別し、データの来歴を明確にできます。

多くのプロセスフロー分析で直接使われる項目ではありませんが、データガバナンス、検証、トラブルシューティングには欠かせません。複数のソースからデータを統合する場合、この属性でシステム別にプロセスを確認できるため、システム間のプロセス実行状況やデータ品質の違いを把握できます。

データの取得元を明確にするため、特に複数のシステムを連携している環境でのデータガバナンスやトラブルシューティングに役立ちます。

通常、データ抽出（ETL）の過程で追加される値で、ソースシステムに元から存在する項目ではありません。

最終データ更新日時には、直近のデータ抽出または更新のタイムスタンプが記録されます。分析対象のデータがどの程度新しいかを確認でき、分析結果が現在の状態を反映しているのか、過去の時点のものなのかを判断できます。

この属性は、運用状況の監視やレポート作成に欠かせません。インサイトがいつ時点のデータに基づいているかが分かるため、データの信頼性を判断し、更新時期を踏まえた意思決定に役立ちます。たとえば、1週間前に更新されたデータを示すダッシュボードと、1時間前に更新されたダッシュボードでは、解釈が異なります。

データの新しさを示します。分析の妥当性を保ち、最新情報に基づいて判断するために重要です。

通常、データ抽出（ETL）の過程で生成・保存されるメタデータ項目です。

SLA期限は、リクエストに適用されるサービスレベル契約に基づいて算出される目標日時です。リクエストの優先度、種類、作成日時などをもとに決まり、解決までに想定される期間を定めます。

この属性は、SLA適合性分析の基準となります。実際の解決日時とSLA期限を比較することで、リクエストが期限内に解決されたか、SLAに違反したかを判断できます。サービス品質を測る重要業績評価指標（KPI）であり、遅延やSLA違反につながる組織的な問題の特定にも使われます。

パフォーマンスを測定する基準です。SLA適合率の算出や、SLA未達のリクエストの特定に使います。

多くの場合、適用されるSLAポリシーに基づいて算出される、サービスリクエストのレコード上の項目です。

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

プロセス分析では、サービス種別をデータの切り口として利用できます。サービス種別ごとにプロセスマップを絞り込むと、リクエストの種類によってプロセスの流れが大きく異なることや、サイクルタイムが長いこと、手戻りが多いことが分かる場合があります。こうしたインサイトをもとに、サービスカテゴリごとの改善に取り組めます。

リクエストのカテゴリごとにプロセスを絞り込んで比較し、それぞれに固有のボトルネックや非効率な点を把握できます。

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

リクエストステータスは、ライフサイクルの各時点におけるサービスリクエストの状態を示します。一般的なステータスには、「新規」「対応中」「保留」「解決済み」「クローズ」があります。この属性から、プロセス全体のどの段階にリクエストがあるかを確認できます。

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

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

サービスリクエストのメインテーブルまたはステータス履歴ログにあります。

リクエスト優先度は、サポートチームが対応順を決めるための分類です。通常、リクエストが業務に与える影響と緊急度を組み合わせて決定します。一般的な優先度には、「低」「中」「高」「重大」があります。

この属性は、パフォーマンス分析やリソース配分に欠かせません。優先度ごとにサイクルタイムやSLA適合率を比較し、優先度の高いリクエストが適切に処理されているかを確認できます。また、優先度の低いリクエストが放置されていないか、サポートチームが優先順位に沿って対応しているかを把握するのにも役立ちます。

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

通常、サービスリクエストのメインレコードに標準項目としてあります。

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

チーム間の引き継ぎの分析は、サービス管理のプロセスマイニングの中心的な要素です。この属性を使うと、チーム間の移管を可視化し、連携不足や遅延を特定できます。また、チームごとの効率、リクエスト件数、追加のエスカレーションなしで解決できる割合を比較し、パフォーマンスを評価できます。

チーム間の引き継ぎを分析し、移管の遅れを特定して、チームのパフォーマンスを比較するために重要です。

サービスリクエストのレコードにある標準項目です。この項目の変更は監査ログに記録されます。

担当者は、特定の時点でサービスリクエストの対応を担う人を指します。リクエストのライフサイクル中に、担当者が変わることがあります。

この属性は、パフォーマンスや業務量の分析に役立ちます。組織は、担当者ごとの平均解決時間や対応件数などを測定し、比較できます。また、担当者間の再割り当てを分析すると、初期のトリアージ、担当者の専門性、業務量の調整に関する問題が見つかることがあります。

担当者ごとのパフォーマンスや業務量の分布、担当者間での再割り当ての頻度を分析できます。

サービスリクエストのレコードにあります。この項目の変更は、監査ログや履歴テーブルに記録されることがよくあります。

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

この属性を使うと、SLA適合性のレポートや分析が簡単になります。クエリごとに日付を比較する必要がなく、このフラグで簡単に絞り込みや集計ができます。SLAパフォーマンスを示すダッシュボードの主要指標であり、サービス目標を達成できていないリクエストの件数や割合をすばやく把握できます。

SLAパフォーマンスを分析するための明確で分かりやすいフラグです。SLA未達のリクエストを簡単に絞り込み、レポートできます。

データ変換時に最終解決タイムスタンプと「SlaDueDate」項目を比較して算出する属性です。

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

部署別にリクエストを分析すると、部署固有のニーズ、傾向、問題を特定できます。たとえば、財務部門から特定の種類のリクエストが多く寄せられている場合、対象を絞ったトレーニングやシステム改善が必要かもしれません。また、費用の部門別配賦レポートを作成し、組織全体のITサービス需要を把握するのにも役立ちます。

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

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

再割り当て回数は、サービスリクエストが担当者またはチーム間で移管された回数を示す指標です。回数が多い場合、最初の振り分けの誤り、担当者の知識不足、プロセスの担当範囲が不明確といった問題が考えられます。

これは、プロセスの非効率さを把握する重要な指標です。プロセスマイニングでは、リクエストが何度も行き来する状況を数値で確認できます。再割り当て回数の多いケースを分析すると、トリアージの改善、担当者のトレーニング、チームの役割分担の見直しにつながり、最初の段階で適切に振り分けられるようになります。

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

特定の「CaseId」に対して「AssignedAgent」または「AssignedTeam」項目が変更された回数を数えて算出する指標です。

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

申請チャネル別にプロセスを分析すると、重要なインサイトが得られます。たとえば、セルフサービスポータルからのリクエストは形式が整っており、メールで届くリクエストより早く解決できる場合があります。メールの場合は、手作業でのデータ入力が必要になることがあります。この分析は、効率のよいチャネルの利用を促したり、効率の低いチャネルのプロセスを改善したりするのに役立ちます。

申請方法がプロセスの効率、解決時間、初回対応での解決率に影響するかを確認できます。

通常、サービスリクエストのレコードに標準項目としてあります。

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

この属性は、個々のアクティビティの処理時間を算出するために必要です。終了時刻から開始時刻を差し引くことで、担当者やシステムがタスクに実際に費やした時間を測定できます。時間のかかるアクティビティを特定し、改善や自動化の候補を見つけるのに役立ちます。

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

イベントログまたは監査証跡のテーブルにあります。明示的な値がない場合は、次のアクティビティの開始時刻から算出することがあります。

解決コードを使うと、サービスリクエストの結果を体系的に分類できます。「ユーザーが解決」「ハードウェア交換」「ソフトウェア導入」「重複リクエスト」などが例です。通常、リクエストをクローズする際に担当者が入力します。

この情報は根本原因の分析に役立ちます。解決コードの頻度を分析すると、繰り返し発生する問題や一般的な解決策を特定し、ナレッジベース記事の作成や解決の自動化につなげられます。たとえば、「パスワードリセット」による解決が多い場合、セルフサービスのパスワードリセットツールへの投資が有効かもしれません。

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

通常、サービスリクエストの解決時またはクローズ時に、担当者が手動で入力する項目です。