サービスリクエスト管理データテンプレート
サービスリクエスト管理データテンプレート
- 包括的な分析のための推奨属性
- プロセスディスカバリで追跡すべき主要な活動
- ソースシステムからのデータ抽出に関するガイダンス
サービスリクエスト管理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
サービスリクエストのライフサイクルにおける特定の時点で発生したイベントまたはタスクの名前です。 | ||
|
説明
この属性は、「承認のためにリクエストを提出済み」や「サービスリクエスト解決済み」など、サービスリクエストプロセス内の特定のステップやステータス変更を記述します。活動の順序と頻度を分析することは、プロセスフローを理解し、ボトルネックを特定し、標準手順からの逸脱を発見するために不可欠です。
その重要性
プロセスフローのステップを定義し、手戻り、ボトルネック、逸脱の特定を含むプロセスフローの可視化と分析を可能にします。
取得元
通常、Ivanti Service Manager内のステータス変更、ジャーナルエントリ、または監査ログイベント記述から派生します。
例
サービスリクエスト作成済み申請承認済サービスリクエスト解決済みサービスリクエストクローズ済み
|
|||
|
イベント日時
EventTime
|
特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
|
説明
イベントタイムは開始時間とも呼ばれ、システムにアクティビティが記録された正確な日時です。このタイムスタンプは、イベントを正しく順序付けするために不可欠であり、サイクルタイム、待機時間、アクティビティ期間の計算など、すべての時間ベースのプロセスマイニング分析の基礎となります。
その重要性
このタイムスタンプは、イベントを時系列で並べ、パフォーマンス分析の鍵となるすべての期間ベースのメトリックを計算するために不可欠です。
取得元
監査ログ、ジャーナルエントリ(例:Journal.CreatedDateTime)、またはサービスリクエストに関連付けられたステータス変更レコードで検出されます。
例
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
サービスリクエストID
ServiceRequestID
|
各サービスリクエストの一意の識別子です。 | ||
|
説明
サービスリクエストIDは、ユーザーまたはシステムによって提出された個々のサービスリクエストを一意に識別します。これは、初期ログから最終クローズまでのすべての後続イベントを結びつける中心的なスレッドとして機能し、各サービスリクエストのジャーニーの完全なエンドツーエンド分析を可能にします。
その重要性
これは、すべての関連活動を単一のプロセスインスタンスに接続し、エンドツーエンドのプロセス分析を可能にする必須のケース識別子です。
取得元
これは、サービスリクエストビジネスオブジェクトの主キーであり、ServiceReqテーブルのServiceReqNumberとしてよく見られます。
例
SR-0012345SR-0012346SR-0012347
|
|||
|
ソースシステム
SourceSystem
|
データを抽出した元システム。 | ||
|
説明
この属性は、プロセスデータの起源を識別します。このビューでは、値は一定であり、すべてのデータがIvanti Service Managerから来ていることを示します。これは、データが複数のシステムから統合される可能性のある環境において、明確なデータリネージとコンテキストを確保するために重要です。
その重要性
データ出所に関する重要なコンテキストを提供し、特にマルチシステム環境において、分析が特定のソースシステムに正しく帰属されることを保証します。
取得元
データ抽出時にデータセットの出所を示すために付与する、通常は固定の値です。
例
Ivanti Service Manager
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最新データ更新時刻を示すタイムスタンプ。 | ||
|
説明
この属性は、Ivanti Service Managerからデータが最後に抽出された日時を示します。これは、分析されているデータの鮮度に関するコンテキストを提供し、ユーザーが分析の対象期間と次の更新がいつ予想されるかを認識できるようにします。
その重要性
データの適時性をユーザーに通知します。これは、利用可能な最新のプロセスパフォーマンス情報に基づいて意思決定を行う上で非常に重要です。
取得元
この値はデータ抽出時に生成され、データセットに付加されます。
例
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
|
|||
|
SLAステータス
SLAStatus
|
サービスリクエストがSLA期限内に解決されたかどうかを示します。 | ||
|
説明
これは、サービスリクエストの解決時間がSLA期限に対して「達成」または「違反」しているかをフラグ付けする派生属性です。「SLA遵守パフォーマンス」ダッシュボードおよび「サービスレベルアグリーメント遵守率」KPIの基盤となります。ロジックは、各ケースのResolutionDateTimeとSLADeadlineを比較します。
その重要性
サービスコミットメントに対するパフォーマンスを直接測定するもので、サービス品質の評価とユーザーの信頼維持に不可欠です。
取得元
「解決日時」を「SLA期限」と比較して算出されます。解決日時がSLA期限以下の場合、ステータスは「達成」となり、それ以外の場合は「違反」となります。
例
達成違反
|
|||
|
SLA期限
SLADeadline
|
サービスリクエストが解決されると予想されるタイムスタンプです。 | ||
|
説明
SLA期限は、サービスレベルアグリーメントを満たすためにサービスリクエストが解決されるべき計算された日時です。この目標は通常、リクエストの優先度やタイプなどの要因に基づいて決定されます。実際の解決時間をこの期限と比較することが、SLA遵守を測定するための基礎となります。
その重要性
実際のパフォーマンスを測定するベンチマークであり、SLA遵守率の計算とリスクのあるリクエストの特定を直接サポートします。
取得元
これはIvanti内の計算フィールドであることが多く、サービスレベルアグリーメントまたはオファリングに関連するフィールド(例:「ResolutionTargetDateTime」)に保存されます。
例
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
イベントの終了時刻
EventEndTime
|
アクティビティの完了時刻を示すタイムスタンプ。 | ||
|
説明
イベント終了時間は、活動の完了を示します。イベント開始時間とイベント終了時間の間の期間は、その特定の活動の処理時間を表します。これは、プロセス内のどのステップが最も時間を消費しているかを特定し、非効率性や改善領域を特定するために非常に重要です。
その重要性
個々のアクティビティ期間の計算を可能にし、これはプロセスボトルネックや長期実行タスクを特定するために不可欠です。
取得元
独立したフィールドとして存在しない場合があります。多くの場合、同じケースにおけるシーケンスの次のアクティビティの開始時間です。
例
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
|
|||
|
サービスリクエストステータス
ServiceRequestStatus
|
イベント発生時のサービスリクエストのステータスです。 | ||
|
説明
この属性は、「登録済み」、「処理中」、「保留中」、「解決済み」、「クローズ済み」といったサービスリクエストの状態を記録します。ステータスの変更は、プロセスログ内の活動を定義することがよくあります。各ステータスで費やされた時間を分析することで、ボトルネック(例:リクエストが「保留中」状態で長すぎる場合など)を明らかにすることができます。
その重要性
任意の時点でのリクエストの状態のスナップショットを提供します。これは、特定の状態での費やされた時間を計算し、プロセスの停滞を特定するために不可欠です。
取得元
サービスリクエストオブジェクトの標準フィールドで、一般的に「ステータス」と命名されます。
例
ログ済みアクティブ`顧客`からの`連絡`を`待機中``履行済`クローズ
|
|||
|
サービスリクエストタイプ
ServiceRequestType
|
サービスリクエストの分類またはカテゴリーです。 | ||
|
説明
この属性は、サービスリクエストを「ハードウェアリクエスト」、「ソフトウェアインストール」、「パスワードリセット」などのカテゴリーに分類します。これは分析にとって重要な側面であり、チームが異なる種類のサービス間でプロセスパフォーマンス、サイクルタイム、SLA遵守を比較できるようにします。これらの違いを理解することは、プロセス改善を調整し、リソースをより効果的に配分するのに役立ちます。
その重要性
リクエストタイプ別にプロセスをセグメント化することで、ターゲットを絞った分析が可能になり、特定のタイプのリクエストが遅延、手戻り、SLA違反の傾向が強いかどうかを明らかにします。
取得元
Service Requestビジネスオブジェクトのフィールドで、「サービス」または「カテゴリ」と名付けられていることが多いです。具体的なフィールド名(例: 「SvcReqTmplLink_Category」)については、Ivanti Service Managerのドキュメントを参照してください。
例
新規ハードウェアリクエストソフトウェアアクセスアカウント変更情報照会
|
|||
|
サイクルタイム
CycleTime
|
サービスリクエストの作成から最終解決までの合計時間です。 | ||
|
説明
サイクルタイムは、最初のアクティビティ(サービスリクエスト作成)から解決アクティビティ(サービスリクエスト解決)までの期間を測定する計算メトリクスです。これはプロセス効率にとって最も重要な主要業績評価指標の一つです。このメトリクスは、全体的なパフォーマンスを追跡し、時間の経過とともに傾向を特定するために、ダッシュボードで広く使用されます。
その重要性
これは、エンドツーエンドのプロセス効率を測定し、ユーザー視点からのサービス体験を直接反映する主要なKPIです。
取得元
各サービスリクエストの解決タイムスタンプから作成タイムスタンプを差し引くことで算出されます。
例
25920000060480000086400000
|
|||
|
優先度
Priority
|
サービスリクエストに割り当てられた優先度レベルです。 | ||
|
説明
優先度とは、サービスリクエストの緊急性を示すもので、通常「低」「中」「高」「クリティカル」といった段階で表されます。この属性は、プロセスが高優先度リクエストを効果的に迅速化しているかを評価するための基本となります。分析では、優先順位付けルールが意図したとおりに機能していることを確認するため、異なる優先度レベル間でサイクルタイムとSLA遵守率を比較することがよくあります。
その重要性
優先順位付け戦略の有効性を評価し、高優先度のリクエストが低優先度のものよりも迅速に解決されることを保証するために重要です。
取得元
サービスリクエストオブジェクトの標準フィールドで、通常「優先度」と命名されます。
例
1 - Critical2 - High3 - Medium4 - Low
|
|||
|
担当チーム
AssignedTeam
|
サービスリクエストの処理に現在割り当てられているサポートチームまたはグループです。 | ||
|
説明
この属性は、ある時点においてサービスリクエストの処理を担当するチームを特定します。チーム間の引き継ぎ、各チームで費やされた時間、および異なるチームが処理したリクエスト量を分析することは、ワークロード配分を理解し、ボトルネックを特定し、チームのパフォーマンスを評価するために不可欠です。これは、SLA遵守とエージェントのワークロードに関連するダッシュボードを直接サポートします。
その重要性
責任と引き継ぎを追跡し、チーム間の遅延、ワークロードのバランス、プロセスにおけるボトルネックとなるチームの分析に役立ちます。
取得元
この情報は通常、サービスリクエストオブジェクトの「OwnerTeam」のようなフィールド、または関連する割り当てレコードに保存されます。
例
ITサービスデスクネットワーク運用人事サポートファシリティマネジメント
|
|||
|
担当者
AssignedAgent
|
サービスリクエストに割り当てられた個々のユーザーまたはエージェントです。 | ||
|
説明
担当エージェントは、サービスリクエストの作業を担当する特定の個人を指します。この属性により、個々のレベルでの分析が可能になり、パフォーマンス管理、ワークロードの均衡化、およびトレーニング機会の特定に役立ちます。「リクエストあたりの平均再割り当て回数」のようなKPIを計算し、プロセスの非効率性を理解するには、エージェント間の再割り当てを追跡することが重要です。
その重要性
個々のワークロード、パフォーマンス、再割り当てパターンを分析でき、トレーニング、スキルセット、または初期ルーティングの問題を示唆する可能性があります。
取得元
通常、サービスリクエストオブジェクトの「Owner」のようなフィールドにあります。これは再割り当てごとに変更される可能性があり、イベントログで追跡する必要があります。
例
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
|
|||
|
解決タイムスタンプ
ResolutionDateTime
|
サービスリクエストが正式に解決された日時です。 | ||
|
説明
これは、リクエストが正式にクローズされる前に、サービスが提供された、または問題が解決された最終的なタイムスタンプを示すケースレベルの属性です。このタイムスタンプは、サービスリクエストのエンドツーエンドのサイクルタイムを計算するための主要な終点です。全体的なプロセス効率とSLA遵守を測定するための重要な要素です。
その重要性
サービス提供効率の主要業績評価指標である、コアプロセスのサイクルタイム計算の終点を定義します。
取得元
サービスリクエストオブジェクト上の特定のタイムスタンプフィールドで、多くの場合「ResolvedDateTime」などと命名されます。
例
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
チャネル
Channel
|
サービスリクエストが提出された方法またはチャネルです。 | ||
|
説明
チャネルは、サービスリクエストがどのように作成されたかを示します。例えば、セルフサービスポータル、Eメール、電話、または他のシステムによる自動作成などです。チャネル別にリクエスト量と解決時間を分析することで、どのチャネルが最も効率的か、そしてどのチャネルがプロセス改善やユーザー研修を必要としているかについての洞察を得ることができます。
その重要性
ユーザー行動とチャネル効率の理解に役立ち、サービス提供戦略や自動化の機会に関する意思決定の参考となります。
取得元
これは通常、サービスリクエストオブジェクトの「Source」または「CreatedBy」タイプのフィールドに保存されます。
例
`セルフサービス`メール電話番号直接入力
|
|||
|
仕入先名
VendorName
|
リクエストの解決に関与した外部ベンダーの名前です。 | ||
|
説明
この属性は、サービスリクエストの支援または完了に関与する第三者ベンダーを特定します。「外部ベンダー活動期間」ダッシュボードにとって不可欠であり、異なるベンダーのパフォーマンスを測定および比較することを可能にします。これを追跡することは、ベンダー関係を管理し、外部依存関係によって引き起こされるボトルネックを特定するのに役立ちます。
その重要性
サードパーティのパフォーマンスと、それがサービスリクエスト全体の解決時間に与える影響を分析でき、ベンダー管理をサポートします。
取得元
これは、サービスリクエストに関連付けられたタスクオブジェクトのフィールド、またはベンダーが割り当てられている場合はサービスリクエスト自体の特定のフィールドである可能性があります。
例
デルサポートオラクルコンサルティングマイクロソフトプレミアnull
|
|||
|
依頼元部署
RequestorDepartment
|
サービスリクエストを提出したユーザーの所属部署です。 | ||
|
説明
この属性は、「営業」、「経理」、「人事」など、サービスリクエストを開始した従業員またはシステムの部署を識別します。これにより、組織内の異なる部門におけるサービス品質と需要の分析が可能になります。例えば、特定の部署がより長い解決時間を経験しているか、より多くのリクエストを提出しているかを特定するのに役立ちます。
その重要性
事業部門ごとのサービス利用状況と品質を分析でき、部門特有の問題や傾向を特定するのに役立ちます。
取得元
この情報は通常、サービスリクエストにリンクされた依頼者のユーザープロファイルから取得されます。フィールドはProfile.Employeeオブジェクトの「Department」である可能性があります。
例
財務営業マーケティング情報技術
|
|||
|
再オープン件数
ReopenCount
|
解決済みのサービスリクエストが再オープンされた回数です。 | ||
|
説明
この属性は、サービスリクエストが「解決済み」または「クローズ済み」の状態から「アクティブ」状態に戻るたびに増分するカウンターです。再オープン回数が多いほど、初回解決の品質が低い、ソリューションが不完全、または問題が再発しているという強い兆候です。「サービスリクエスト手戻り率」KPIを直接サポートします。
その重要性
手戻りを直接測定し、解決策の品質を示す主要な指標です。高頻度は初期の修正が効果的でなかったことを示唆します。
取得元
これは通常、サービスリクエストオブジェクトのカウンターフィールドであり、ステータスが適切に変更されたときにビジネスルールによって増分されます。「ReopenCounter」と名付けられている場合があります。
例
0123
|
|||
|
割り当て回数
AssignmentCount
|
サービスリクエストが割り当てまたは再割り当てされた合計回数です。 | ||
|
説明
この計算メトリックは、各サービスリクエストにおける割り当て関連活動(例:「チームに割り当て済み」、「エージェントに割り当て済み」)の数をカウントします。再割り当ての回数が多い場合(「チケットピンポン」とよく呼ばれる)、ルーティングの非効率性、初回解決の欠如、またはチーム責任の不明確さを示します。この属性は、「リクエストあたりの平均再割り当て数」KPIに不可欠です。
その重要性
非効率な引き継ぎやルーティングの問題を数値化します。この数値が高いほど、解決時間の長期化やユーザーの不満につながる強い兆候です。
取得元
データ準備中に、各ユニークなServiceRequestIDに対する割り当て関連アクティビティの発生回数を数えることで算出されます。
例
12345
|
|||
|
手戻り
IsRework
|
サービスリクエストに手戻り活動が含まれていたかどうかを示すブール値フラグです。 | ||
|
説明
この計算フラグは、サービスリクエストが解決後に再オープンされたり、特定の活動がループして繰り返されたりするなど、手戻りの兆候を示す場合にtrueに設定されます。これにより、「サービスリクエスト手戻り率」KPIの計算が簡素化され、「手戻りおよび再割り当てフロー」のようなダッシュボードで非効率なプロセスインスタンスをフィルタリングするのに役立ちます。
その重要性
追加の計画外の労力を必要とするリクエストの量を簡単に特定し、数値化するのに役立ち、品質と効率の問題を浮き彫りにします。
取得元
データから導出されます。「再オープンカウント」属性がゼロより大きいことに基づくか、複数の「担当者へ割り当て」イベントのような特定のアクティビティシーケンスを検出することに基づくロジックです。
例
truefalse
|
|||
|
解決カテゴリー
ResolutionCategory
|
サービスリクエストに対して提供された解決策の分類です。 | ||
|
説明
解決カテゴリーは、サービスリクエストが最終的にどのように解決されたかを分類するための構造化された方法を提供します。これは多くの場合、根本原因分析や傾向レポートに役立つ階層的な分類(例:カテゴリー、サブカテゴリー)です。例えば、繰り返される問題や一般的な履行アクションのタイプを強調表示し、サービス改善やナレッジベース記事の作成に利用できます。
その重要性
解決策の性質に関する洞察を提供し、一般的な問題、サービス改善の機会、および自動化の候補を特定するのに役立ちます。
取得元
多くの場合、「ResolutionCategory」やカスタムのクローズコードフィールドなど、解決時に記入される分類フィールドに保存されます。
例
ユーザー研修が必要ソフトウェア展開済みハードウェア修理済みアクセス許可
|
|||
サービスリクエスト管理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
サービスリクエストクローズ済み
|
サービスリクエストは正式にクローズされ、それ以上の操作はできません。これは多くの場合、「解決済み」状態での一定期間後に自動的に発生し、ライフサイクルの最終的な結論を表します。 | ||
|
その重要性
この活動はプロセスの最終的な終了を示します。「解決済み」から「クローズ済み」までの時間は、確認作業や自動化されたシステムプロセスにおける遅延を浮き彫りにすることができます。
取得元
サービスリクエストレコードの「ステータス」フィールドが「クローズ済み」に変更されたことと、関連するタイムスタンプから推測されます。
取得
監査履歴から「ステータス」フィールドが「クローズ済み」に更新されたことを検出します。
イベントタイプ
inferred
|
|||
|
サービスリクエスト作成済み
|
この活動は、新しいリクエストがIvantiに正式に提出され、ログに記録されるサービスリクエストライフサイクルの開始を示します。このイベントは、サービスリクエストビジネスオブジェクトに新しいレコードが作成され、一意のサービスリクエストIDが生成されたときに記録されます。 | ||
|
その重要性
これはプロセスの主要な開始イベントです。この時点から解決までの時間を分析することは、全体のサイクルタイムとプロセス効率を測定するために不可欠です。
取得元
これは、サービスリクエストレコードの作成タイムスタンプ(例:ServiceReqビジネスオブジェクトのCreatedDateTimeフィールド)から取得されます。
取得
作成タイムスタンプによって識別される、ServiceReqテーブル内のレコード作成イベントです。
イベントタイプ
explicit
|
|||
|
サービスリクエスト解決済み
|
サービスリクエストは解決済みと見なされ、解決策はユーザーに提供されました。これは「解決済み」へのステータス変更によって記録される主要なマイルストーンであり、多くの場合、SLAクロックの停止をトリガーします。 | ||
|
その重要性
これは、解決時間とSLA遵守を測定するための重要な終点です。作成からこの活動までの期間は、プロセスパフォーマンスの主要なKPIです。
取得元
サービスリクエストレコードの「ステータス」フィールドが「解決済み」に変更されたことと、関連するタイムスタンプから推測されます。
取得
監査履歴から「ステータス」フィールドが「解決済み」に更新されたことを検出します。
イベントタイプ
inferred
|
|||
|
チームにリクエストを割り当て済み
|
サービスリクエストは、処理のために特定のサポートチームに割り当てられます。これは、サービスリクエストレコードの「OwnerTeam」フィールドへの入力または変更を監視することで記録されます。 | ||
|
その重要性
このイベントは、チームレベルのパフォーマンス、ワークロード配分、およびチーム間の引き継ぎ時間を分析するために重要です。プロセス内のボトルネックとなるチームを特定するのに役立ちます。
取得元
サービスリクエストの監査履歴またはジャーナル内の「OwnerTeam」フィールドの変更によって追跡されます。
取得
「OwnerTeam」フィールドへの更新イベントで、通常は監査証跡に記録されます。
イベントタイプ
explicit
|
|||
|
リクエストが担当者にアサイン
|
特定の担当者がサービスリクエストのオーナーシップを引き継ぎます。このアクティビティは通常、「オーナー」フィールド(個々の担当者を指定するもの)が初めて入力または更新されたときに推測されます。 | ||
|
その重要性
これは初期の待機時間またはキュー時間の終了を示します。この活動までの期間を測定することは、リソース配分の問題を特定し、エージェントワークロードダッシュボードをサポートするのに役立ちます。
取得元
監査履歴に見られるように、サービスリクエストレコードの「オーナー」フィールドの入力または変更から推測されます。
取得
作成またはチーム割り当て後、「Owner」フィールドにエージェント名が初めて入力されたタイムスタンプです。
イベントタイプ
inferred
|
|||
|
サービスリクエストキャンセル済み
|
サービスリクエストは、解決前にユーザーまたはエージェントによってキャンセルされました。これは、「キャンセル済み」または「撤回済み」へのステータス変更によって記録される、代替の終了状態です。 | ||
|
その重要性
これは非標準のプロセス終了を表します。リクエストがキャンセルされる理由を分析することで、リクエストプロセス自体に関する問題やユーザーニーズの変化が明らかになる可能性があります。
取得元
サービスリクエストレコードの「ステータス」フィールドが「キャンセル済み」に変更されたことから推測されます。
取得
監査履歴から「ステータス」フィールドが「キャンセル済み」に更新されたことを検出します。
イベントタイプ
inferred
|
|||
|
サービスリクエスト再オープン済み
|
以前解決されたサービスリクエストが、問題が解決していない、または解決策が不十分であったために再アクティブ化されました。これは、ステータスが「解決済み」から「アクティブ」や「割り当て済み」のようなアクティブな状態に戻ったときに捕捉されます。 | ||
|
その重要性
この活動は、手戻りや初回解決品質の低さの直接的な指標です。再オープンイベントを分析することで、プロセスの弱点を特定し、サービスリクエスト手戻り率KPIの改善に役立ちます。
取得元
監査履歴において、「ステータス」フィールドが「解決済み」または「クローズ済み」からアクティブなステータスに変更されたことから推測されます。
取得
完了状態(「解決済み」、「クローズ済み」)からオープン状態(「アクティブ」、「割り当て済み」)へのステータス変更です。
イベントタイプ
inferred
|
|||
|
サービスリクエスト完了
|
サービスリクエストを完了するために必要なすべてのタスクが、担当者またはシステムによって完了しました。これは「完了済み」へのステータス変更によって捕捉され、このステータスは最終的な「解決済み」ステータスに先行することがよくあります。 | ||
|
その重要性
このマイルストーンは、技術的または手順的な作業の完了を示します。最終確認とクローズの前の積極的な処理時間を測定するための重要なポイントです。
取得元
サービスリクエストレコードの「ステータス」フィールドが「完了済み」に変更されたことから推測されます。
取得
レコードの履歴から「ステータス」フィールドが「完了済み」に変更されたことを検出します。
イベントタイプ
inferred
|
|||
|
ユーザーへの情報要求
|
担当エージェントは、サービス履行を進めるために依頼者からさらなる情報を必要としています。これは、リクエストステータスが「顧客対応待ち」のような状態に更新されたときに記録されます。 | ||
|
その重要性
この活動は、初期情報の不備による遅延を浮き彫りにします。その発生頻度と期間を追跡することは、情報要求影響分析とプロセス改善領域の特定にとって重要です。
取得元
サービスリクエストレコードのステータスが「顧客待ち」や「保留中」のような状態に変化したことから推測されます。
取得
「ステータス」フィールドが指定された「ユーザー待ち」状態に変化したことを検出します。
イベントタイプ
inferred
|
|||
|
ユーザー提供情報
|
依頼者が必要な情報を提供したため、エージェントは作業を再開できます。これは、リクエストが「顧客対応待ち」ステータスからアクティブな状態に戻ったときに記録されます。 | ||
|
その重要性
このイベントは情報要求のループを閉じます。情報の要求から受信までの時間は、プロセス遅延と手戻りループの重要な構成要素です。
取得元
サービスリクエストの「ステータス」フィールドが「顧客待ち」の状態から「アクティブ」や「進行中」のようなアクティブな状態に変化したときに推測されます。
取得
「ユーザー待ち」状態からアクティブ状態へのステータス変更を検出します。
イベントタイプ
inferred
|
|||
|
優先度変更済み
|
サービスリクエストの初期作成後に優先度が更新されました。このイベントは、フィールドレベルの変更を追跡する監査ログまたは履歴から取得されます。 | ||
|
その重要性
優先度変更の追跡は、優先度付けの有効性の概要にとって不可欠です。エスカレーションが正しく管理されているか、初期優先度付けが正確であるかを判断するのに役立ちます。
取得元
これは、サービスリクエストレコードの監査履歴から取得される明示的なイベントであり、「Priority」フィールドへの変更を記録します。
取得
システムの監査証跡に記録された「優先度」フィールドへの更新イベントです。
イベントタイプ
explicit
|
|||
|
外部ベンダー関与
|
サービスリクエストの履行が外部ベンダーまたは第三者に引き渡されました。これは通常、「サードパーティ対応待ち」または同様のステータスへの変更によって記録されます。 | ||
|
その重要性
この活動は、ベンダーのパフォーマンスとそれが全体的なサイクル時間に与える影響を測定するために不可欠です。ベンダー関連の遅延の分析を可能にし、外部ベンダー活動期間ダッシュボードをサポートします。
取得元
サービスリクエストレコードのステータスが「サードパーティ待ち」や「ベンダー保留中」のような状態に変化したことから推測されます。
取得
「ステータス」フィールドが指定された「ベンダー待ち」状態に変化したことを検出します。
イベントタイプ
inferred
|
|||
|
承認のためにリクエストを提出済み
|
サービスリクエストは、履行される前に必要な承認のために提出されました。これは通常、リクエストステータスが「提出済み」または「承認待ち」に変更されたときに推測され、多くの場合、承認ワークフローがトリガーされます。 | ||
|
その重要性
この活動を追跡することで、承認フェーズにおける遅延を特定するのに役立ちます。ここでの長い待機時間は、全体的な解決時間とユーザー満足度に影響を与える重大なボトルネックとなる可能性があります。
取得元
サービスリクエストレコードのステータスが「提出済み」または「承認待ち」のような状態に変化したことから推測されます。これはFRS_ApprovalまたはFRS_ApprovalVoteTrackingビジネスオブジェクトから取得することもできます。
取得
サービスリクエストレコードの「ステータス」フィールドが承認待ち状態に変更されたことを示します。
イベントタイプ
inferred
|
|||
|
申請承認済
|
サービスリクエストは必要なすべての承認を受け、履行に進むことができます。このイベントは、承認ワークフローが正常に完了し、リクエストのステータスが変更されたときに記録されます。 | ||
|
その重要性
この活動は、承認フェーズの終了と履行開始を示す重要なマイルストーンです。これにより、承認プロセス自体の効率を測定できます。
取得元
「承認待ち」から「承認済み」または「完了済み」へのステータス変更から推測されます。これはFRS_Approvalビジネスオブジェクトに明示的にログされるイベントである可能性もあります。
取得
サービスリクエストレコードの「ステータス」フィールドが承認状態からアクティブ状態へ変更されたことを示します。
イベントタイプ
inferred
|
|||