サービスリクエスト管理データ``テンプレート
サービスリクエスト管理データ``テンプレート
- 包括的な分析のための推奨属性
- プロセスディスカバリで追跡すべき主要な活動
- `Jira Service Management`からのデータ抽出ガイド
サービスリクエスト管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
サービスリクエストのライフサイクル内で発生した特定のイベントまたはタスクの名前。 | ||
|
説明
この これらの活動の順序と発生頻度を分析することが、
その重要性
プロセスにおけるステップを定義し、プロセスマップの可視化とワークフローパターンおよび逸脱の分析を可能にします。
取得元
通常、Jira課題の「
例
リクエストトリアージ済み情報の追加依頼解決策が実装されましたサービスリクエストクローズ済み
|
|||
|
サービスリクエストID
ServiceRequestId
|
各サービスリクエストの一意な識別子であり、すべての関連`イベント`の`プライマリーキー`として機能します。 | ||
|
説明
「サービスリクエスト
その重要性
この
取得元
これはJira Service Managementにおける課題の「
例
SR-2023-001IT-45892HELP-105
|
|||
|
開始時刻
EventTime
|
特定のアクティビティやイベントが発生した正確な日時。 | ||
|
説明
「開始時間」、すなわち この
その重要性
この
取得元
これはJira課題の
例
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
|
|||
|
ソースシステム
SourceSystem
|
サービスリクエスト`データ`が抽出されたシステム名。 | ||
|
説明
この 分析において、
その重要性
データの出所を特定します。これはデータガバナンスや、複数のエンタープライズシステムからのプロセスデータを組み合わせる際に重要です。
取得元
データ抽出・変換の過程で付与する固定値で、データセットのソースを示すラベルとして利用します。
例
Jira Service ManagementJiraSM
|
|||
|
最終データ更新
LastDataUpdate
|
`ソース``システム`から`データ`が最後に更新された日時を示す`タイムスタンプ`です。 | ||
|
説明
この どのような分析においても、
その重要性
データの鮮度を示し、分析が最新情報に基づいていることを保証します。
取得元
これは、
例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
`SLA`期日
SlaDueDate
|
SLAに基づき、サービスリクエストが解決されるべき目標日時です。 | ||
|
説明
「SLA期限日( この
その重要性
これはパフォーマンス測定の
取得元
SLA情報はJira Service Managementで管理されており、
例
2023-10-28T16:00:00Z2023-11-01T09:00:00Z
|
|||
|
Assignee
Assignee
|
サービスリクエストの作業に現在割り当てられているユーザーまたはエージェント。 | ||
|
説明
「担当者( この
その重要性
この
取得元
これはJira課題の「
例
Alice JohnsonBob Williams未割り当て
|
|||
|
リクエストステータス
RequestStatus
|
サービスリクエストの`ライフサイクル`における現在の`ステータス`。 | ||
|
説明
この 活動
その重要性
各ケースの現状のスナップショットを提供し、進行中の作業の分析や、停滞しているリクエスト、古くなったリクエストの特定を可能にします。
取得元
これはJira課題の「
例
オープン進行中顧客対応待ち解決済み
|
|||
|
リクエストタイプ
RequestType
|
サービスリクエストの分類(例:「`アクセス`リクエスト」や「`ハードウェア`問題」など)。 | ||
|
説明
「リクエストタイプ」は、サービスリクエストの性質に基づき分類します。リクエストの種類によって解決プロセス、SLA、必要なリソースが異なるため、これはプロセス分析において極めて重要な要素です。 リクエストタイプ別にプロセス分析をセグメンテーションすることで、組織は特定のワークフローに合わせて改善策を調整できます。例えば、「パスワードリセット」リクエストと「新規サーバープロビジョニング」リクエストでは、
その重要性
この
取得元
これはJiraの「
例
新規アカウントを申請するIT ヘルプを得る新入社員のオンボーディング
|
|||
|
リクエスト優先度
RequestPriority
|
サービスリクエストに割り当てられた優先度`レベル`(例:「低」、「中」、「高」、「`クリティカル`」など)。 | ||
|
説明
サービスリクエストの「優先度」は、その緊急度とビジネスへの影響を示すものです。この分類によって、リクエストの処理順序や、目標とする解決時間、SLAが決定されることがほとんどです。 プロセス分析では、優先度は重要なセグメンテーション(区分け)の軸となります。これにより、異なる優先度レベル間での処理サイクルタイムやSLA遵守状況を比較し、高優先度のリクエストが実際に迅速に処理され、目標を達成しているかを確認できます。これは、優先順位付けシステムの有効性を検証するために役立ちます。
その重要性
分析をセグメント化することで、優先度の高いリクエストがより迅速に処理され、より厳格なサービスレベルを満たすことを保証します。
取得元
これはJira課題の「
例
最高高中低
|
|||
|
`ケース``サイクルタイム`
CaseCycleTime
|
サービスリクエストの作成から最終クローズまでの全経過時間。 | ||
|
説明
ケースサイクルタイムは、サービスリクエストのライフサイクル全体の期間を測定する計算指標です。通常、「サービスリクエストクローズ済み」タイムスタンプと「サービスリクエスト作成済み」タイムスタンプの差として計算されます。 これはプロセスマイニングで最も重要な KPI の 1 つであり、「平均サービスリクエストサイクルタイム」KPI および「サービスリクエストエンドツーエンドサイクルタイム」ダッシュボードを直接サポートします。これは、プロセス全体の効率と顧客の待機時間の高レベルな尺度を提供します。
その重要性
これは、プロセス全体の効率性と
取得元
データ変換中に、各ケースの最終クローズタイムスタンプから作成タイムスタンプを減算することで計算されます。
例
864003600007200
|
|||
|
Organization
Organization
|
依頼者が所属する顧客組織、または社内部署を示します。 | ||
|
説明
この 組織別に分析することで、貴重なビジネス
その重要性
顧客または内部部門によるサービス需要とパフォーマンスの分析を促進し、重要なビジネスインサイトを提供します。
取得元
この
例
アクメコーポレーション財務部`Global Tech Inc.`
|
|||
|
SLA状態
SlaState
|
サービスリクエストが定義された SLA を満たしたか、違反したか、またはその範囲内にあるかを示します。 | ||
|
説明
「SLAステータス」は、各サービスリクエストがSLA期限に対してどれだけ達成しているかに基づいて分類する計算 これは「サービスリクエストSLAパフォーマンス」
その重要性
SLA パフォーマンスの明確かつ即時的な指標を提供し、サービス品質と契約遵守の重要な尺度となります。
取得元
データ変換中に計算されます。解決時間が「SlaDueDate」より前の場合、ステータスは「達成」となり、それ以外の場合は「違反」となります。
例
達成違反進行中
|
|||
|
チャネル
Channel
|
サービスリクエストを作成する際に使用された提出方法(例:`メール`、`ポータル`、`API`など)。 | ||
|
説明
「
その重要性
提出チャネルが解決時間、リクエストの明確さ、またはプロセス全体の効率性に影響を与えるかどうかを分析するのに役立ちます。
取得元
この情報はJira Service Managementの「
例
ポータルemailapi
|
|||
|
トリアージから割り当てまでの時間
TriageToAssignmentTime
|
リクエストがトリアージされてからエージェントに割り当てられるまでの期間です。 | ||
|
説明
これは、サービスリクエストの初期処理および この
その重要性
リクエスト処理の重要な初期ステップの効率性を測定し、作業開始前の遅延を浮き彫りにします。
取得元
データ変換中に、「リクエストトリアージ済み」イベントのタイムスタンプから「リクエスト割り当て済み」イベントのタイムスタンプを減算することで計算されます。
例
3009001800
|
|||
|
ベンダー関与期間
VendorEngagementDuration
|
サービスリクエストが外部ベンダーの対応を待機した合計時間。 | ||
|
説明
これは、サービスリクエストが外部ベンダー対応の状態にあった合計時間を合算する計算 この
その重要性
外部依存関係による遅延を特定・定量化し、ベンダーパフォーマンスの管理と予測改善のためのデータを提供します。
取得元
データ変換中に、「ベンダー連携開始」イベントと「ベンダー連携終了」イベント間の時間を測定することで計算されます。
例
172800604800259200
|
|||
|
再オープン済み
IsReopened
|
解決後にサービスリクエストが再開されたかどうかを示すブール値フラグです。 | ||
|
説明
この計算 この
その重要性
手戻りや初回解決の品質を直接測定し、プロセスの有効性と顧客満足度の主要な指標となります。
取得元
データ変換中に、ケースのアクティビティシーケンスに「解決済み」移行の後に「再開済み」移行が含まれているかをチェックすることで計算されます。
例
truefalse
|
|||
|
報告者
Reporter
|
サービスリクエストを最初に作成または報告したユーザー。 | ||
|
説明
「依頼者( 分析においては、依頼者情報を使って異なるユーザー、部署、顧客
その重要性
リクエストの起案者を特定し、ユーザー、部門、または顧客ごとのリクエスト量とタイプを分析できるようにします。
取得元
これはJira課題の「
例
チャールズ・ダーウィンマリー・キュリーアイザック・ニュートン
|
|||
|
担当チーム
AssignedTeam
|
サービスリクエストの処理を担当するチームまたは`グループ`。 | ||
|
説明
この この
その重要性
個々のエージェントだけでなく、チームまたは部門レベルでのパフォーマンス分析とワークロードバランス調整を可能にします。
取得元
これはJiraのカスタム
例
IT サポート - ティア 1インフラストラクチャチームアプリケーションサポート
|
|||
|
解決
Resolution
|
解決済みサービスリクエストの最終的な結果や結論。 | ||
|
説明
「解決」 解決策を分析することで、成果の質や性質を理解するのに役立ちます。例えば、「重複」という解決が多く見られる場合、リクエストの提出プロセスに問題がある可能性を示唆します。また、どの解決策がリクエストの再開につながっているかを追跡することで、効果の低い解決策を特定できます。
その重要性
リクエストの結果に関するコンテキストを提供し、解決品質の分析や、リクエストがクローズされる理由の傾向を特定するのに役立ちます。
取得元
これはJira課題の「
例
完了実行しない重複修正済み
|
|||
サービスリクエスト管理の活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
サービスリクエストクローズ済み
|
サービスリクエストの最終的な管理上のクローズを示します。「解決済み」ステータスで一定期間経過後に自動で処理されることが多く、Jiraにおける課題のライフサイクルの終点となります。 | ||
|
その重要性
これはプロセスの明確な終了
取得元
課題履歴から推測されます。このタイムスタンプは、「クローズ済み」またはそれに相当する最終ステータスへの最終的なステータス変更に対応します。
取得
「クローズ済み」ステータスへの最終ステータス変更のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
サービスリクエスト作成済み
|
この活動は、ユーザーが`ポータル`、`メール`、または他の`チャネル`を通じて正式にリクエストを提出する際に、サービスリクエスト`ライフサイクル`の開始点となります。この`イベント`は、Jiraで「サービスリクエスト」`タイプ`の新規課題が作成された時点で明確に記録され、作成`タイムスタンプ`も記録されます。 | ||
|
その重要性
これはプロセスにおける主要な開始
取得元
これは課題履歴
取得
「
イベントタイプ
explicit
|
|||
|
サービスリクエスト解決済み
|
リクエストが完了したとみなされ、解決策が記録される公式な時点を示します。Jira は、課題が初めて「完了」カテゴリのステータスになったときに「解決日」フィールドに値を入力します。 | ||
|
その重要性
これはプロセスにおける主要な終了
取得元
これは明示的な
取得
Jira課題の「
イベントタイプ
explicit
|
|||
|
リクエストがアサインされた
|
この活動は、サービスリクエストが特定の`エージェント`またはチームに解決のために割り当てられた際に発生します。Jiraは「`Assignee`」`フィールド`への変更を明示的に追跡し、その割り当てが行われた明確な`タイムスタンプ`を提供します。 | ||
|
その重要性
これは、トリアージから割り当てまでの時間やエージェントの
取得元
課題履歴から、
取得
課題履歴における最初の「
イベントタイプ
explicit
|
|||
|
解決策の提案
|
多くのサービスデスクワークフローでは、これはリクエスターに解決策を提示し、承認を得るための明確なステップです。これは、課題ステータスが「顧客承認待ち」や「確認待ち」のような状態に変化したときに推測されます。 | ||
|
その重要性
この活動は、解決策提供後に顧客からの
取得元
課題履歴から推測され、ステータスが顧客の検証待ちであることを示す状態に変わったタイムスタンプでキャプチャされます。
取得
「顧客承認待ち」またはそれに相当するステータスへの変更のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
ベンダー関与終了
|
外部ベンダーが作業を完了し、サービスリクエストが内部チームに戻る時点を表します。「ベンダー待ち」ステータスから移行した際に推測される活動です。 | ||
|
その重要性
ベンダー連携期間を測定することで、ベンダーのパフォーマンス管理と、外部関係者が全体の解決時間に与える影響を理解するのに役立ちます。
取得元
課題履歴から推測されます。このタイムスタンプは、課題のステータスが「ベンダー」ステータスから「進行中」ステータスに戻った時点に対応します。
取得
「ステータス」フィールドが「ベンダー」状態から「アクティブ」状態に戻るタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
ベンダー関与開始
|
この活動は、サービスリクエストが外部ベンダーまたは第三者にエスカレートされた、あるいはその対応を必要としていることを示します。課題が「ベンダー待ち」や「第三者対応中」といった`ステータス`に移行することから推測されます。 | ||
|
その重要性
ベンダーとの連携状況を追跡することは、社内サービス
取得元
課題履歴から推測されます。このタイムスタンプは、課題のステータスが指定された「ベンダー」ステータスに変化した時点に対応します。
取得
「ステータス」フィールドが「ベンダー待機中」のような値に変わるタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
リクエストが再オープンされた
|
この活動は、以前解決されたサービスリクエストが再びアクティブな状態に戻されたケースを捉えます。解決済みまたはクローズ済み`ステータス`からオープンまたは進行中`ステータス`への`ステータス`変更によって、この活動が推測されます。 | ||
|
その重要性
再開されたリクエストの追跡は、解決品質と初回解決率を測定する上で極めて重要です。再開率が高いことは、効果のない解決策や繰り返し発生する問題を示唆しています。
取得元
課題履歴から、「解決済み」または「クローズ済み」カテゴリのステータスから「オープン」または「進行中」カテゴリのステータスへの状態遷移を特定することで推測されます。
取得
「完了」ステータスカテゴリから「未着手」または「進行中」ステータスカテゴリへのステータス変更を探します。
イベントタイプ
inferred
|
|||
|
リクエストトリアージ済み
|
サービスリクエストの初期アセスメントを指し、優先度、カテゴリ、影響度を判断する活動です。通常、「新規」から「処理中」、または専用の「トリアージ済み」ステータスへの変更など、ステータスの変化からこの活動が推測されます。 | ||
|
その重要性
トリアージにかかる時間を分析することで、初期のリクエスト処理プロセスの効率性を評価できます。ここでの遅延は、全体の解決時間や SLA 遵守に大きく影響する可能性があります。
取得元
課題履歴から、初期の「新規」または「オープン」状態から「進行中」のようなアクティブな状態へのステータス変更の最初のタイムスタンプを特定することで推測されます。
取得
プロジェクトのワークフローに基づき、「新規」またはそれに相当する初期ステータスからの最初のステータス変更を特定します。
イベントタイプ
inferred
|
|||
|
情報の追加依頼
|
エージェントが解決を進めるためにリクエスターから追加情報を必要とする時点を示します。これは通常、課題が「顧客対応待ち」や「入力待ち」のようなステータスに移行することで推測されます。 | ||
|
その重要性
頻繁または長期にわたる「情報要求」サイクルは、初期提出の不明瞭さや非効率なコミュニケーションを示している可能性があり、遅延の大きな原因となります。
取得元
課題履歴から推測されます。このタイムスタンプは、課題のステータスが「顧客対応待ち」または同等のステータスに変化した時点に対応します。
取得
「ステータス」フィールドが、プロセスが顧客を待機していることを示す値に変更されるタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
情報提供済み
|
リクエスターが必要な情報で応答し、エージェントが作業を再開できるときに発生します。これは、課題が「顧客対応待ち」ステータスから移行したときに推測され、多くの場合、リクエスターがコメントを追加することでトリガーされます。 | ||
|
その重要性
この活動は、顧客とのリクエスト
取得元
課題履歴から推測されます。このタイムスタンプは、課題のステータスが「顧客対応待ち」から「進行中」の状態に戻った時点に対応します。
取得
「ステータス」フィールドが「待機中」状態から「アクティブ」状態に戻るタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
解決確認済み
|
リクエスターが提案された解決策を正式に承認したときに発生し、多くの場合、「解決済み」ステータスへの自動遷移を引き起こします。このイベントは通常、このステータス変更から推測されます。 | ||
|
その重要性
この
取得元
課題履歴から推測されます。このタイムスタンプは、課題のステータスが「顧客承認待ち」から「解決済み」または「クローズ済み」に変化した時点に対応します。
取得
「顧客承認待ち」から「解決済み」または「クローズ済み」ステータスへのステータス変更のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
解決策が実装されました
|
エージェントがサービスリクエストに対処するために必要なアクションを実行したか、解決策を開発したことを示します。これは通常、「レビュー待ち」または直接「解決済み」へのステータス変更から推測されます。 | ||
|
その重要性
この
取得元
課題履歴から推測され、「解決済み」、「承認待ち」、または同様のクローズ前ステータスへのステータス変更のタイムスタンプに対応します。
取得
「ステータス」フィールドが、作業が完了したことを示す値に変更されるタイムスタンプを特定します。
イベントタイプ
inferred
|
|||