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

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

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

この`テンプレート`は、サービスリクエストプロセスを分析するために不可欠な`データ`を収集するための、構造化されたアプローチを提供します。収集すべき重要な`属性`、追跡すべき主要な活動、そしてシステムからこれらの情報を抽出する方法に関する`ガイダンス`を詳述しています。このリソースを活用して、`データ`準備を`ストリームライン`化し、業務におけるより深い`インサイト`を獲得してください。
  • 包括的な分析のための推奨属性
  • プロセスディスカバリで追跡すべき主要な活動
  • `Jira Service Management`からのデータ抽出ガイド
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

サービスリクエスト管理の属性

これらは、包括的なサービスリクエスト管理分析のために`イベント``ログ`に含めることを推奨する`データ``フィールド`です。
5 必須 5 推奨 10 任意
名前 説明
アクティビティ
ActivityName
サービスリクエストのライフサイクル内で発生した特定のイベントまたはタスクの名前。
説明

この属性は、サービスリクエストにおいて特定の時点で発生したアクションやステータス遷移を記述するものです。例えば、「リクエスト作成済み」、「リクエスト割り当て済み」、「解決策実装済み」、「リクエストクローズ済み」といった内容が含まれます。

これらの活動の順序と発生頻度を分析することが、プロセス``マイニングコアとなります。これにより、プロセスマップの可視化、ボトルネックの特定、標準ワークフローからの逸脱の検出が可能となり、プロセスの効率性とコンプライアンスを理解する上で不可欠です。

その重要性

プロセスにおけるステップを定義し、プロセスマップの可視化とワークフローパターンおよび逸脱の分析を可能にします。

取得元

通常、Jira課題の「status」遷移履歴から導出されます。課題の変更ログにおけるステータス``フィールドの各エントリーが、一つの活動を示します。

リクエストトリアージ済み情報の追加依頼解決策が実装されましたサービスリクエストクローズ済み
サービスリクエストID
ServiceRequestId
各サービスリクエストの一意な識別子であり、すべての関連`イベント`の`プライマリーキー`として機能します。
説明

「サービスリクエストID」は、Jiraではしばしば「課題キー」と呼ばれ、ユーザーまたはシステムによって提出された個々のサービスリクエストを一意に識別するものです。これは、最初ログ記録された時点から最終的にクローズされるまでの、すべての関連イベントを結びつける中心的なスレッドとして機能し、各サービスリクエストのジャーニーエンドツーエンドで完全に分析することを可能にします。

プロセス``マイニングにおいて、このIDケース相関に不可欠です。すべてのアクティビティ、ステータス変更、およびタイムスタンプが、それぞれの特定のリクエストに正しく関連付けられることを保証し、分析のための整合性のあるプロセスインスタンスを形成します。

その重要性

このIDは、すべての関連活動を単一のエンドツーエンドのプロセスフローに結びつけ、プロセス分析を可能にする基本的なケース識別子です。

取得元

これはJira Service Managementにおける課題の「keyフィールドです。

SR-2023-001IT-45892HELP-105
開始時刻
EventTime
特定のアクティビティやイベントが発生した正確な日時。
説明

「開始時間」、すなわちイベント``タイムスタンプは、活動が発生した正確な瞬間を記録します。これは、プロセス全体の時間的なコンテキストを提供するプロセス``マイニング分析にとって極めて重要なコンポーネントです。

このタイムスタンプは、イベントを時系列に並べ、活動間の期間を計算し、ケース全体のサイクルタイムを測定し、SLAのような時間ベースの目標に対するプロセスパフォーマンスを分析するために使用されます。正確なタイムスタンプがなければ、プロセスフローを理解し、遅延を特定し、効率を測定することは不可能です。

その重要性

このタイムスタンプは、イベントの順序付け、期間とサイクルタイムの計算、そしてプロセスボトルネックの特定に不可欠です。

取得元

これはJira課題の変更ログにおける各ステータス遷移に関連付けられたタイムスタンプです。課題の作成時間は「createdフィールドで確認できます。

2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
ソースシステム
SourceSystem
サービスリクエスト`データ`が抽出されたシステム名。
説明

この属性データの発生源を識別し、このケースではJira Service Managementです。単一のソースからのデータを分析する際には些細な情報に見えるかもしれませんが、複数のシステムからのプロセスデータを統合する際には極めて重要になります。

分析において、データリネージを追跡し、データ品質を確保するのに役立ちます。さらに、異なるソフトウェア``プラットフォームにまたがる、あるいは連携するプロセスをフィルターし、比較することも可能になります。

その重要性

データの出所を特定します。これはデータガバナンスや、複数のエンタープライズシステムからのプロセスデータを組み合わせる際に重要です。

取得元

データ抽出・変換の過程で付与する固定値で、データセットのソースを示すラベルとして利用します。

Jira Service ManagementJiraSM
最終データ更新
LastDataUpdate
`ソース``システム`から`データ`が最後に更新された日時を示す`タイムスタンプ`です。
説明

この属性は、Jira Service Managementから最新のデータが抽出された日時を記録します。これは、分析の鮮度やダッシュボードおよびKPIに含まれるデータの正確性を判断する上で、重要なコンテキストを提供します。

どのような分析においても、データの適時性を把握することは、情報に基づいた意思決定を行う上で不可欠です。このタイムスタンプは、ユーザーがリアルタイムの情報を見ているのか、それとも過去のある時点のスナップショットを見ているのかを理解するのに役立ち、分析結果の妥当性にも影響します。

その重要性

データの鮮度を示し、分析が最新情報に基づいていることを保証します。

取得元

これは、データ抽出ツールまたはスクリプトが実行を完了した際に生成・保存されるメタデータ``フィールドです。

2023-10-27T02:00:00Z2023-10-28T02:00:00Z
`SLA`期日
SlaDueDate
SLAに基づき、サービスリクエストが解決されるべき目標日時です。
説明

「SLA期限日(SLA Due Date)」は、リクエストの解決期限を示す計算タイムスタンプです。これは、リクエストの優先度、タイプ、およびJira Service Managementで設定された特定のサービス``レベル合意(SLA)ポリシーに基づいて決定されます。

この属性は、「サービスリクエストSLAパフォーマンス」ダッシュボードと「SLA遵守率」KPIにとって極めて重要です。実際の解決時間とこの期限日を比較することで、システムは各リクエストが時間通りに完了したか、遅延したか、あるいはSLA違反のリスクがあるかをシステムが判断できます。

その重要性

これはパフォーマンス測定のベンチマークとなります。SLAコンプライアンスの計算を直接サポートし、作業の優先順位付けに役立ちます。

取得元

SLA情報はJira Service Managementで管理されており、API経由でアクセス可能です。多くの場合、動的に更新されるカスタムフィールドに保存されています。

2023-10-28T16:00:00Z2023-11-01T09:00:00Z
Assignee
Assignee
サービスリクエストの作業に現在割り当てられているユーザーまたはエージェント。
説明

「担当者(Assignee)」は、次のアクションやサービスリクエストの解決に責任を持つ個人を指します。この属性の値は、リクエストのライフサイクルを通じて、異なるエージェントやチーム間で引き継がれるたびに複数回変更される可能性があります。

この属性は、ワークロード分析、パフォーマンス測定、およびリソースマネジメントに不可欠です。エージェントごとにプロセスをフィルターし、個人間の解決時間を比較することで、潜在的なトレーニングの必要性や、ボトルネックを引き起こすワークロードの不均衡を特定するのに役立ちます。

その重要性

この属性は、エージェントのワークロード分析、個人のパフォーマンス測定、リソース配分理解にとって不可欠です。

取得元

これはJira課題の「assigneeフィールドに該当します。

Alice JohnsonBob Williams未割り当て
リクエストステータス
RequestStatus
サービスリクエストの`ライフサイクル`における現在の`ステータス`。
説明

この属性は、サービスリクエストの現在の状態を表します(例:「オープン」、「進行中」、「顧客待ち」、「解決済み」など)。特定の時点におけるリクエストの状況をスナップショットとして提供します。

活動ログが履歴的な流れを提供する一方で、現在のステータスは、未処理のワークロードを分析し、停滞している項目を特定するのに役立ちます。例えば、ベンダー待ち``ステータスに異常に長く留まっているリクエストに焦点を当てて分析することで、外部依存や遅延の原因を明確にできます。

その重要性

各ケースの現状のスナップショットを提供し、進行中の作業の分析や、停滞しているリクエスト、古くなったリクエストの特定を可能にします。

取得元

これはJira課題の「statusフィールドです。

オープン進行中顧客対応待ち解決済み
リクエストタイプ
RequestType
サービスリクエストの分類(例:「`アクセス`リクエスト」や「`ハードウェア`問題」など)。
説明

「リクエストタイプ」は、サービスリクエストの性質に基づき分類します。リクエストの種類によって解決プロセス、SLA、必要なリソースが異なるため、これはプロセス分析において極めて重要な要素です。

リクエストタイプ別にプロセス分析をセグメンテーションすることで、組織は特定のワークフローに合わせて改善策を調整できます。例えば、「パスワードリセット」リクエストと「新規サーバープロビジョニング」リクエストでは、ボトルネックの原因が大きく異なります。この属性は、「カテゴリ別解決品質」のような関連ダッシュボードを作成する上でも鍵となります。

その重要性

この属性は、異なるカテゴリのサービスリクエスト間でプロセス、ワークロード、パフォーマンスを比較するために不可欠です。

取得元

これはJiraの「issuetypeフィールド、またはJira Service Managementのカスタム「リクエストタイプフィールドに該当することが多いです。

新規アカウントを申請するIT ヘルプを得る新入社員のオンボーディング
リクエスト優先度
RequestPriority
サービスリクエストに割り当てられた優先度`レベル`(例:「低」、「中」、「高」、「`クリティカル`」など)。
説明

サービスリクエストの「優先度」は、その緊急度とビジネスへの影響を示すものです。この分類によって、リクエストの処理順序や、目標とする解決時間、SLAが決定されることがほとんどです。

プロセス分析では、優先度は重要なセグメンテーション(区分け)の軸となります。これにより、異なる優先度レベル間での処理サイクルタイムやSLA遵守状況を比較し、高優先度のリクエストが実際に迅速に処理され、目標を達成しているかを確認できます。これは、優先順位付けシステムの有効性を検証するために役立ちます。

その重要性

分析をセグメント化することで、優先度の高いリクエストがより迅速に処理され、より厳格なサービスレベルを満たすことを保証します。

取得元

これはJira課題の「priorityフィールドに該当します。

最高
`ケース``サイクルタイム`
CaseCycleTime
サービスリクエストの作成から最終クローズまでの全経過時間。
説明

ケースサイクルタイムは、サービスリクエストのライフサイクル全体の期間を測定する計算指標です。通常、「サービスリクエストクローズ済み」タイムスタンプと「サービスリクエスト作成済み」タイムスタンプの差として計算されます。

これはプロセスマイニングで最も重要な KPI の 1 つであり、「平均サービスリクエストサイクルタイム」KPI および「サービスリクエストエンドツーエンドサイクルタイム」ダッシュボードを直接サポートします。これは、プロセス全体の効率と顧客の待機時間の高レベルな尺度を提供します。

その重要性

これは、プロセス全体の効率性とエンドツーエンドの顧客体験を測定するための主要なKPIです。

取得元

データ変換中に、各ケースの最終クローズタイムスタンプから作成タイムスタンプを減算することで計算されます。

864003600007200
Organization
Organization
依頼者が所属する顧客組織、または社内部署を示します。
説明

この属性は、依頼者を組織または部署ごとにグループ化します。Jira Service Managementには、エージェントが複数の顧客や社内チームからのリクエストを管理できる「組織」機能が組み込まれています。

組織別に分析することで、貴重なビジネスコンテキストが得られます。例えば、どの顧客や部署が最も多くのサポートリソースを消費しているか、特定のグループが繰り返し問題を抱えていないか、異なる事業単位間でSLAが確実に遵守されているかなどを特定するのに役立ちます。

その重要性

顧客または内部部門によるサービス需要とパフォーマンスの分析を促進し、重要なビジネスインサイトを提供します。

取得元

このデータは、Jira Service Managementのサービスリクエストに関連付けられた「Organizationsフィールドから取得されます。

アクメコーポレーション財務部`Global Tech Inc.`
SLA状態
SlaState
サービスリクエストが定義された SLA を満たしたか、違反したか、またはその範囲内にあるかを示します。
説明

「SLAステータス」は、各サービスリクエストがSLA期限に対してどれだけ達成しているかに基づいて分類する計算属性です。「達成済み (Met)」、「違反 (Breached)」、「進行中 (In Progress)」などの値があり、解決タイムスタンプと「SlaDueDate」を比較して決定されます。

これは「サービスリクエストSLAパフォーマンス」ダッシュボードの主要属性であり、「SLA遵守率」KPIの計算にも使われます。レポート作成、契約マネジメント、サービス品質維持において極めて重要な、サービスレベル``コンプライアンスの現状を一目で把握できる明確なビューを提供します。

その重要性

SLA パフォーマンスの明確かつ即時的な指標を提供し、サービス品質と契約遵守の重要な尺度となります。

取得元

データ変換中に計算されます。解決時間が「SlaDueDate」より前の場合、ステータスは「達成」となり、それ以外の場合は「違反」となります。

達成違反進行中
チャネル
Channel
サービスリクエストを作成する際に使用された提出方法(例:`メール`、`ポータル`、`API`など)。
説明

チャネル属性は、サービスリクエストがどのようにシステムに入力されたかを識別します。Jira Service Managementにおける一般的なチャネルとしては、顧客ポータルメール、またはエージェントによる直接作成が挙げられます。

チャネルごとにプロセスを分析することは、ユーザーの行動を理解し、サービスデリバリーを最適化する上で重要です。特定のチャネルからのリクエストが解決に時間がかかったり、より多くの情報が必要となったりする場合があるかを明らかにでき、ポータル上のフォームの改善やメール解析ルールの改良が必要である可能性を示唆します。これは「サービスリクエストスループット``トレンドダッシュボードの基盤となります。

その重要性

提出チャネルが解決時間、リクエストの明確さ、またはプロセス全体の効率性に影響を与えるかどうかを分析するのに役立ちます。

取得元

この情報はJira Service Managementの「Request channel typeフィールドから取得できます。特定のAPIアクセスが必要な場合や、カスタムフィールドに保存されている場合もあります。

ポータルemailapi
トリアージから割り当てまでの時間
TriageToAssignmentTime
リクエストがトリアージされてからエージェントに割り当てられるまでの期間です。
説明

これは、サービスリクエストの初期処理およびルーティング段階の効率性を測定する計算済み期間メトリクスです。「リクエスト割り当て済み」活動と「リクエストトリアージ済み」活動の間の時間差として算出されます。

このメトリクスは、「平均トリアージから割り当てまでの時間」KPIおよび「トリアージと割り当て効率」ダッシュボードの基盤となります。この期間が長い場合、サービスデスクの受付プロセスにボトルネックがある可能性を示唆します。例えば、トリアージ担当スタッフの不足や、適切なチームへの割り当て決定における遅延などが考えられます。

その重要性

リクエスト処理の重要な初期ステップの効率性を測定し、作業開始前の遅延を浮き彫りにします。

取得元

データ変換中に、「リクエストトリアージ済み」イベントのタイムスタンプから「リクエスト割り当て済み」イベントのタイムスタンプを減算することで計算されます。

3009001800
ベンダー関与期間
VendorEngagementDuration
サービスリクエストが外部ベンダーの対応を待機した合計時間。
説明

これは、サービスリクエストが外部ベンダー対応の状態にあった合計時間を合算する計算メトリクスです。「ベンダー関与開始」活動と「ベンダー関与終了」活動の間の期間を特定し、もし単一ケース内で複数回発生する場合には、それらの期間を合計して算出されます。

この属性は、「外部ベンダー関与遅延」ダッシュボードや「平均外部ベンダー時間」KPIにとって不可欠です。第三者依存によって生じる遅延を定量化するのに役立ち、ベンダー関係のマネジメントや現実的な顧客期待値の設定において極めて重要です。

その重要性

外部依存関係による遅延を特定・定量化し、ベンダーパフォーマンスの管理と予測改善のためのデータを提供します。

取得元

データ変換中に、「ベンダー連携開始」イベントと「ベンダー連携終了」イベント間の時間を測定することで計算されます。

172800604800259200
再オープン済み
IsReopened
解決後にサービスリクエストが再開されたかどうかを示すブール値フラグです。
説明

この計算属性は、リクエストのワークフローに「リクエスト再開」活動が含まれる場合にTrueとなる真偽値``フラグです。これは、各ケースの活動シーケンスを分析することで導き出されます。

このフラグは、「サービスリクエスト再開率」KPIの算出や、「再開されたサービスリクエストボリュームダッシュボードの基盤として不可欠です。再開率が高いことは、初回解決の品質が低いことを強く示唆しており、手戻りの発生や顧客満足度の低下につながります。このフラグに関連するリクエストタイプや解決策を分析することで、改善すべき領域を明確に特定できます。

その重要性

手戻りや初回解決の品質を直接測定し、プロセスの有効性と顧客満足度の主要な指標となります。

取得元

データ変換中に、ケースのアクティビティシーケンスに「解決済み」移行の後に「再開済み」移行が含まれているかをチェックすることで計算されます。

truefalse
報告者
Reporter
サービスリクエストを最初に作成または報告したユーザー。
説明

「依頼者(Reporter)」は、サービスリクエストを提出した個人であり、多くの場合、エンドユーザーまたは顧客を指します。この属性は、プロセスを開始したステークホルダーを特定します。

分析においては、依頼者情報を使って異なるユーザー、部署、顧客セグメントからのリクエストパターンを把握できます。「どの部署が最も多くのリクエストを提出しているか」や「特定のユーザーが同じ問題に繰り返し直面していないか」といった疑問に答えるのに役立ち、プロアクティブな問題マネジメントやユーザートレーニングの改善に繋がる貴重な情報です。

その重要性

リクエストの起案者を特定し、ユーザー、部門、または顧客ごとのリクエスト量とタイプを分析できるようにします。

取得元

これはJira課題の「reporterフィールドに該当します。

チャールズ・ダーウィンマリー・キュリーアイザック・ニュートン
担当チーム
AssignedTeam
サービスリクエストの処理を担当するチームまたは`グループ`。
説明

この属性は、リクエストに割り当てられたチームを特定します。これは個々の担当者よりも上位のグループ分けとなることが多く、チームレベルでのパフォーマンス分析に役立ちます(例:ファースト``レベル``サポートチームとネットワーク運用チームの比較)。

このディメンションは、「エージェントワークロードと解決メトリクス」のようなダッシュボードにとって不可欠です。チームレベルでパフォーマンスメトリクスを集計できるため、公平な比較が可能となり、各チームがサービスデリバリープロセス全体にどのように貢献しているかを理解するのに役立ちます。

その重要性

個々のエージェントだけでなく、チームまたは部門レベルでのパフォーマンス分析とワークロードバランス調整を可能にします。

取得元

これはJiraのカスタムフィールド(例:「チーム」)であるか、または担当者のユーザープロファイル``属性から導出される場合があります。

IT サポート - ティア 1インフラストラクチャチームアプリケーションサポート
解決
Resolution
解決済みサービスリクエストの最終的な結果や結論。
説明

「解決」フィールドは、サービスリクエストがなぜクローズされたかを示します。「完了」、「実施しない」、「重複」、「再現不能」などの一般的な値があります。「解決済み」や「クローズ済み」というステータスに加えて、より詳細なクローズ理由を提供します。

解決策を分析することで、成果の質や性質を理解するのに役立ちます。例えば、「重複」という解決が多く見られる場合、リクエストの提出プロセスに問題がある可能性を示唆します。また、どの解決策がリクエストの再開につながっているかを追跡することで、効果の低い解決策を特定できます。

その重要性

リクエストの結果に関するコンテキストを提供し、解決品質の分析や、リクエストがクローズされる理由の傾向を特定するのに役立ちます。

取得元

これはJira課題の「resolutionフィールドに該当し、通常、課題が「完了」ステータスカテゴリに移行した際に設定されます。

完了実行しない重複修正済み
必須 推奨 任意

サービスリクエスト管理の活動

これらは、正確な`プロセスディスカバリ`と`最適化`のために、`イベントログ`に記録すべき主要な`プロセスステップ`と`マイルストーン`です。
5 推奨 8 任意
アクティビティ 説明
サービスリクエストクローズ済み
サービスリクエストの最終的な管理上のクローズを示します。「解決済み」ステータスで一定期間経過後に自動で処理されることが多く、Jiraにおける課題のライフサイクルの終点となります。
その重要性

これはプロセスの明確な終了イベントです。「解決済み」から「クローズ済み」までの時間は、管理オーバーヘッド自動クローズのポリシーを理解するために分析できます。

取得元

課題履歴から推測されます。このタイムスタンプは、「クローズ済み」またはそれに相当する最終ステータスへの最終的なステータス変更に対応します。

取得

「クローズ済み」ステータスへの最終ステータス変更のタイムスタンプを特定します。

イベントタイプ inferred
サービスリクエスト作成済み
この活動は、ユーザーが`ポータル`、`メール`、または他の`チャネル`を通じて正式にリクエストを提出する際に、サービスリクエスト`ライフサイクル`の開始点となります。この`イベント`は、Jiraで「サービスリクエスト」`タイプ`の新規課題が作成された時点で明確に記録され、作成`タイムスタンプ`も記録されます。
その重要性

これはプロセスにおける主要な開始イベントです。全体のサイクルタイムを計算し、リクエストのボリュームと到着パターンを理解するために不可欠です。

取得元

これは課題履歴テーブルに明示的に記録されるイベントです。活動タイムスタンプはJira課題の「createdフィールドの値です。

取得

issuesテーブルまたは履歴から課題作成タイムスタンプを使用します。

イベントタイプ explicit
サービスリクエスト解決済み
リクエストが完了したとみなされ、解決策が記録される公式な時点を示します。Jira は、課題が初めて「完了」カテゴリのステータスになったときに「解決日」フィールドに値を入力します。
その重要性

これはプロセスにおける主要な終了マイルストーンであり、解決時間とSLA遵守の算出に不可欠です。活動が終了したことを示します。

取得元

これは明示的なイベントです。タイムスタンプはJira課題の「Resolution Dateフィールドの値で、これは「完了」カテゴリステータスへの最初の遷移時に設定されます。

取得

Jira課題の「resolutiondateフィールドを使用します。このフィールドは自動的に入力されます。

イベントタイプ explicit
リクエストがアサインされた
この活動は、サービスリクエストが特定の`エージェント`またはチームに解決のために割り当てられた際に発生します。Jiraは「`Assignee`」`フィールド`への変更を明示的に追跡し、その割り当てが行われた明確な`タイムスタンプ`を提供します。
その重要性

これは、トリアージから割り当てまでの時間やエージェントのワークロード分布を測定する上で重要なマイルストーンです。待機状態から実際の処理へと移行する時点を示します。

取得元

課題履歴から、担当者 フィールドが最初に設定された、または未割り当てから変更されたインスタンスを探して取得されます。

取得

課題履歴における最初の「Assigneeフィールド変更のタイムスタンプを使用します。

イベントタイプ explicit
解決策の提案
多くのサービスデスクワークフローでは、これはリクエスターに解決策を提示し、承認を得るための明確なステップです。これは、課題ステータスが「顧客承認待ち」や「確認待ち」のような状態に変化したときに推測されます。
その重要性

この活動は、解決策提供後に顧客からのフィードバックを待つ時間を切り出し、内部作業時間と区別するのに役立ちます。

取得元

課題履歴から推測され、ステータスが顧客の検証待ちであることを示す状態に変わったタイムスタンプでキャプチャされます。

取得

「顧客承認待ち」またはそれに相当するステータスへの変更のタイムスタンプを特定します。

イベントタイプ inferred
ベンダー関与終了
外部ベンダーが作業を完了し、サービスリクエストが内部チームに戻る時点を表します。「ベンダー待ち」ステータスから移行した際に推測される活動です。
その重要性

ベンダー連携期間を測定することで、ベンダーのパフォーマンス管理と、外部関係者が全体の解決時間に与える影響を理解するのに役立ちます。

取得元

課題履歴から推測されます。このタイムスタンプは、課題のステータスが「ベンダー」ステータスから「進行中」ステータスに戻った時点に対応します。

取得

「ステータス」フィールドが「ベンダー」状態から「アクティブ」状態に戻るタイムスタンプを特定します。

イベントタイプ inferred
ベンダー関与開始
この活動は、サービスリクエストが外部ベンダーまたは第三者にエスカレートされた、あるいはその対応を必要としていることを示します。課題が「ベンダー待ち」や「第三者対応中」といった`ステータス`に移行することから推測されます。
その重要性

ベンダーとの連携状況を追跡することは、社内サービスデスクの直接的な管理外にある外部依存性や遅延を特定する上で不可欠です。

取得元

課題履歴から推測されます。このタイムスタンプは、課題のステータスが指定された「ベンダー」ステータスに変化した時点に対応します。

取得

「ステータス」フィールドが「ベンダー待機中」のような値に変わるタイムスタンプを特定します。

イベントタイプ inferred
リクエストが再オープンされた
この活動は、以前解決されたサービスリクエストが再びアクティブな状態に戻されたケースを捉えます。解決済みまたはクローズ済み`ステータス`からオープンまたは進行中`ステータス`への`ステータス`変更によって、この活動が推測されます。
その重要性

再開されたリクエストの追跡は、解決品質と初回解決率を測定する上で極めて重要です。再開率が高いことは、効果のない解決策や繰り返し発生する問題を示唆しています。

取得元

課題履歴から、「解決済み」または「クローズ済み」カテゴリのステータスから「オープン」または「進行中」カテゴリのステータスへの状態遷移を特定することで推測されます。

取得

「完了」ステータスカテゴリから「未着手」または「進行中」ステータスカテゴリへのステータス変更を探します。

イベントタイプ inferred
リクエストトリアージ済み
サービスリクエストの初期アセスメントを指し、優先度、カテゴリ、影響度を判断する活動です。通常、「新規」から「処理中」、または専用の「トリアージ済み」ステータスへの変更など、ステータスの変化からこの活動が推測されます。
その重要性

トリアージにかかる時間を分析することで、初期のリクエスト処理プロセスの効率性を評価できます。ここでの遅延は、全体の解決時間や SLA 遵守に大きく影響する可能性があります。

取得元

課題履歴から、初期の「新規」または「オープン」状態から「進行中」のようなアクティブな状態へのステータス変更の最初のタイムスタンプを特定することで推測されます。

取得

プロジェクトのワークフローに基づき、「新規」またはそれに相当する初期ステータスからの最初のステータス変更を特定します。

イベントタイプ inferred
情報の追加依頼
エージェントが解決を進めるためにリクエスターから追加情報を必要とする時点を示します。これは通常、課題が「顧客対応待ち」や「入力待ち」のようなステータスに移行することで推測されます。
その重要性

頻繁または長期にわたる「情報要求」サイクルは、初期提出の不明瞭さや非効率なコミュニケーションを示している可能性があり、遅延の大きな原因となります。

取得元

課題履歴から推測されます。このタイムスタンプは、課題のステータスが「顧客対応待ち」または同等のステータスに変化した時点に対応します。

取得

「ステータス」フィールドが、プロセスが顧客を待機していることを示す値に変更されるタイムスタンプを特定します。

イベントタイプ inferred
情報提供済み
リクエスターが必要な情報で応答し、エージェントが作業を再開できるときに発生します。これは、課題が「顧客対応待ち」ステータスから移行したときに推測され、多くの場合、リクエスターがコメントを追加することでトリガーされます。
その重要性

この活動は、顧客とのリクエストレスポンス``ループを完結させます。情報要求から受領までの時間は、プロセス待機時間の重要な要素となります。

取得元

課題履歴から推測されます。このタイムスタンプは、課題のステータスが「顧客対応待ち」から「進行中」の状態に戻った時点に対応します。

取得

「ステータス」フィールドが「待機中」状態から「アクティブ」状態に戻るタイムスタンプを特定します。

イベントタイプ inferred
解決確認済み
リクエスターが提案された解決策を正式に承認したときに発生し、多くの場合、「解決済み」ステータスへの自動遷移を引き起こします。このイベントは通常、このステータス変更から推測されます。
その重要性

このマイルストーンは、解決策の有効性を検証し、SLAクロックを停止するためのトリガーとなります。顧客が修正を確認するのに要する時間を測定するのに役立ちます。

取得元

課題履歴から推測されます。このタイムスタンプは、課題のステータスが「顧客承認待ち」から「解決済み」または「クローズ済み」に変化した時点に対応します。

取得

「顧客承認待ち」から「解決済み」または「クローズ済み」ステータスへのステータス変更のタイムスタンプを特定します。

イベントタイプ inferred
解決策が実装されました
エージェントがサービスリクエストに対処するために必要なアクションを実行したか、解決策を開発したことを示します。これは通常、「レビュー待ち」または直接「解決済み」へのステータス変更から推測されます。
その重要性

このマイルストーンは、主要な解決作業の完了を示します。この活動に至るまでの時間は、プロセスにおける主な付加価値部分であることが多いです。

取得元

課題履歴から推測され、「解決済み」、「承認待ち」、または同様のクローズ前ステータスへのステータス変更のタイムスタンプに対応します。

取得

「ステータス」フィールドが、作業が完了したことを示す値に変更されるタイムスタンプを特定します。

イベントタイプ inferred
推奨 任意

抽出ガイド

`Jira Service Management`から`データ`を取得する方法