貴社の問題管理``データ``テンプレート
貴社の問題管理``データ``テンプレート
- より深い根本原因分析のための重要な属性
- 問題`ライフサイクル`の`標準化された`活動`マッピング`
- Freshserviceからの`データ`抽出に関する`技術`ガイド
問題管理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
問題レコードで`実行された`特定`の`イベント`または`アクション`。 | ||
|
説明
この 分析では、この
その重要性
プロセス実行の「何を」定義し、プロセスマップ生成には必須です。
取得元
Freshserviceの「Activities」または「Audit Log」エンドポイントから派生します。
例
問題記録優先度更新ステータスが「解決済み」に変更されました
|
|||
|
タイムスタンプ
EventTimestamp
|
アクティビティが発生した正確な日時。 | ||
|
説明
この 分析では、この
その重要性
イベントのタイムラインを確立し、サイクル時間の計算とプロセス順序付けを可能にします。
取得元
アクティビティストリーム内のFreshservice APIの「created_at」または「updated_at」フィールド。
例
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z
|
|||
|
問題レコード
ProblemNumber
|
問題レコードに`割り当てられた`一意の`英数字``識別子`(例:`PRB-10234`)。 | ||
|
説明
この 分析では、この
その重要性
プロセスフローを再構築するための基本的なキーであり、各ケースを一意に識別するために必要です。
取得元
Freshservice API「Problem」オブジェクト、「display_id」フィールド。
例
PRB-10023PRB-10045PRB-11201
|
|||
|
`サポートグループ`
SupportGroup
|
問題を`処理する`ために`割り当てられた`技術`チーム`または`グループ`。 | ||
|
説明
この 分析では、この
その重要性
引き継ぎの分析やサイロ化されたボトルネックの特定に不可欠です。
取得元
Freshservice API「Problem」オブジェクト、「group_id」フィールド(Groupsテーブルへのルックアップが必要)。
例
データベースチームネットワーク運用アプリケーションサポート
|
|||
|
RCAまでの時間
TimeToRootCause
|
問題`作成`から`根本原因`特定`までの`期間`。 | ||
|
説明
この 分析では、これは「
その重要性
特に調査フェーズの速度を測定します。
取得元
イベントタイムスタンプから算出されます。
例
48時間3 days45 minutes
|
|||
|
SLA違反
IsSlaBreached
|
プロブレムレコードがサービスレベル目標を達成できなかったことを示すフラグ。 | ||
|
説明
この 分析では、これは「
その重要性
プロセスコンプライアンスとパフォーマンスの直接的な測定です。
取得元
Freshservice API、「sla_policy」または「sla_breached」フラグから派生。
例
truefalse
|
|||
|
ステータス
ProblemStatus
|
問題の`現在`の`ライフサイクル``ステータス`(例:`オープン`、`変更`要求`済み`、`解決済み`)。 | ||
|
説明
この 分析では、これは
その重要性
ケースの状態を定義し、フロー統計の計算に使用されます。
取得元
Freshservice API「Problem」オブジェクト、「status」フィールド。
例
オープン変更保留中解決済みクローズ
|
|||
|
リンクされたインシデント
RelatedIncidentCount
|
この`問題`に`リンクされている`インシデント`レコード`の`数`。 | ||
|
説明
この 分析では、これは「
その重要性
プロブレムがヘルプデスクに与える影響の大きさを表します。
取得元
Freshservice API、「associated_incidents」配列のカウント。
例
05120
|
|||
|
優先度
ProblemPriority
|
問題に`割り当てられた`優先度`レベル`(例:`低`、`中`、`高`、`緊急`)。 | ||
|
説明
この 分析では、この
その重要性
影響の大きい問題に対する分析のフィルタリングと優先順位付けに不可欠です。
取得元
Freshservice API「Problem」オブジェクト、「priority」フィールド。
例
低中高`緊急`
|
|||
|
再オープン済み
IsReopened
|
プロブレムレコードがクローズ状態からオープン状態に移動されたことがあるかどうかを示すフラグ。 | ||
|
説明
この 分析では、これは「
その重要性
誤検知の解決と手戻りの主要な指標。
取得元
イベントログ(ActivityName)から算出されます。
例
truefalse
|
|||
|
担当者
AgentName
|
`現在`、`問題`に`割り当てられている`サービスデスク``エージェント`の`名前`。 | ||
|
説明
この 分析では、
その重要性
リソース分析と組織マイニングの鍵となります。
取得元
Freshservice API「Problem」オブジェクト、「responder_id」フィールド(Agentテーブルへのルックアップが必要)。
例
Alice Smithボブ・ジョーンズシステム管理者
|
|||
|
根本原因カテゴリ
RootCauseCategory
|
問題に対して`特定された`根本原因`の`分類。 | ||
|
説明
この 分析では、これは「
その重要性
傾向分析および予防的改善の領域を特定するのに不可欠です。
取得元
Freshservice API「Problem」オブジェクト。設定に応じて、多くの場合カスタムフィールドまたは「root_cause」テキストフィールドです。
例
ソフトウェア障害設定エラーハードウェアの誤動作
|
|||
|
部署
DepartmentName
|
問題を`報告した`ユーザー`または`主`に`影響`を受けた`ユーザー`の`部門`。 | ||
|
説明
この 分析では、これは「
その重要性
問題の影響に関する組織的な
取得元
Freshservice API、リクエスターの部門テーブルへのルックアップ経由。
例
財務人事IT
|
|||
|
ソースシステム
SourceSystem
|
`データ`の`発信元``システム`名です。 | ||
|
説明
この 分析では、これは
その重要性
マルチシステムプロセスマイニング実装におけるデータリネージとトレーサビリティを保証します。
取得元
抽出時にハードコードされた値。
例
Freshservice
|
|||
|
リンクされた変更リクエスト
ChangeRequestId
|
問題を`修正`するために`作成された`変更`要求`の`識別子`。 | ||
|
説明
この 分析では、これは「
その重要性
プロブレムプロセスを変更管理プロセスにリンクします。
取得元
Freshservice API、「associated_change_request」フィールド。
例
CHG-2001CHG-2045
|
|||
|
ワークアラウンド`説明`
WorkaroundNotes
|
`一時的な`修正`または`ワークアラウンド`を`説明する`テキスト`。 | ||
|
説明
この 分析では、この
その重要性
緩和速度と完全な解決速度の測定に不可欠です。
取得元
Freshservice API「Problem」オブジェクト、「workaround」フィールド。
例
サービスを手動で再起動するブラウザキャッシュをクリア代替VPN`エンドポイント`を`使用する`
|
|||
|
最終データ更新
LastExtractionTime
|
Freshserviceから`データ`が`抽出`された`時刻`を`示す``タイムスタンプ`。 | ||
|
説明
この 分析では、これは
その重要性
取得元
ETL実行時のシステム時間。
例
2023-11-01T12:00:00Z
|
|||
|
影響を受ける資産
AssociatedAsset
|
問題に`リンクされている`主要な`構成`アイテム`(CI)または`資産`。 | ||
|
説明
この 分析では、
その重要性
プロセスパフォーマンスをインフラストラクチャコンポーネントに接続します。
取得元
Freshservice API、「associated_assets」フィールド。
例
サーバー-01給与計算アプリケーションコアスイッチA
|
|||
|
影響度
ImpactLevel
|
問題が`ビジネス``プロセス`に`与える`影響の`度合い`。 | ||
|
説明
この 分析では、
その重要性
ビジネス
取得元
Freshservice API「Problem」オブジェクト、「impact」フィールド。
例
低中高
|
|||
|
支払期日
DueDate
|
問題レコードが`解決`される`予定`の`目標`日付。 | ||
|
説明
この 分析では、この
その重要性
期限内の
取得元
Freshservice API「Problem」オブジェクト、「due_by」フィールド。
例
2023-12-31T17:00:00Z
|
|||
問題管理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
サポートグループ`割り当て`済み
|
問題レコードを特定の技術チームまたは`割り当て`グループにルーティングします。`チケット`履歴の「グループ」`フィールド`の`変更を監視することで`捕捉されます。 | ||
|
その重要性
サポートグループ転送ヒートマップに不可欠です。これを追跡することで、ピンポン効果やチーム間の過度な引き継ぎが明らかになります。
取得元
アクティビティストリーム:「group_id」または「group_name」フィールドの更新。
取得
グループフィールドが更新された際にログ記録
イベントタイプ
explicit
|
|||
|
プロブレムクローズ済み
|
レコードが`ロック`され、`非`アクティブ`と`見なされる`最終`ライフサイクル``イベント`。「`クローズ済み`」への`ステータス`移行`によって`捕捉されます。 | ||
|
その重要性
プロセスインスタンスの絶対的な終了を定義します。総サイクル時間の計算に必要です。
取得元
アクティビティストリーム:ステータスの「クローズ」への変更。
取得
ステータスがクローズ済みに変更されたときに記録されます
イベントタイプ
explicit
|
|||
|
ワークアラウンド`公開済み`
|
問題レコードへ`一時的な`解決策を追加すること、これは多くの場合、「`ワークアラウンド`」`ノート`または`フィールド`として`マーク`されます。`ワークアラウンド`公開`速度`の`計算に`使用されます。 | ||
|
その重要性
チームがどの程度迅速に影響を緩和するかを測定します。平均回避策リードタイムKPIに不可欠です。
取得元
アクティビティストリーム:「workaround」フィールドの更新、または解決策/回避策としてマークされたメモの作成。
取得
回避策フィールドが入力された際にログ記録
イベントタイプ
explicit
|
|||
|
問題記録
|
システムにおける`問題`レコード`の`初期`作成`。`この`イベント`は、新しい`問題``チケット`が`保存`された`とき`にFreshserviceの`監査`ログに`明示的に`捕捉されます。 | ||
|
その重要性
プロセスインスタンスの開始を示します。すべてのリードタイムとサイクルタイムを計算するためのアンカーポイントです。
取得元
FreshserviceアクティビティストリームまたはチケットAPI(created_atタイムスタンプ)。
取得
トランザクション「New Problem」が実行された際にログ記録
イベントタイプ
explicit
|
|||
|
変更リクエスト関連付け済み
|
`変更`レコード`と`問題`レコード`の`関連付け`は、`是正措置`フェーズの`開始`を示します。`「`変更`との`関連付け`」`システム``イベント`を`介して`捕捉されます。 | ||
|
その重要性
取得元
アクティビティストリーム:「変更との関連付け」イベント。
取得
変更IDがリンクされた際にログ記録
イベントタイプ
explicit
|
|||
|
恒久的な修正適用済み
|
最終的な解決策の実施を表します。Freshserviceでは、ステータスが「解決済み」または「解決済み」に移行した`時点`で、これが通常推測されます。 | ||
|
その重要性
恒久的な修正の実装遅延を計算します。技術的な修正作業の終了を示します。
取得元
アクティビティストリーム:ステータスの「解決済み」または「対応済み」への変更。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
根本原因特定済み
|
`根本原因``テキストフィールド`または`分析`セクションが`入力`された`時点`。`「`根本原因`」`フィールド`の`初期``更新`を`null``状態`から`特定する`ことで`捕捉されます。 | ||
|
その重要性
RCA
取得元
アクティビティストリーム:「root_cause」または「analysis」フィールドの更新。
取得
root_causeフィールドを更新前後で比較
イベントタイプ
inferred
|
|||
|
SLA違反
|
「期日」が超過したことを示すシステム生成イベント。Freshserviceは特定のSLA違反マーカーをログに記録します。 | ||
|
その重要性
重要プロブレムSLAパフォーマンス分析を直接サポートします。コンプライアンス違反を強調表示します。
取得元
アクティビティストリーム:SLA違反システムログ。
取得
システムSLAモニターがトリガーされた際にログ記録
イベントタイプ
explicit
|
|||
|
ステータス`変更`保留中
|
変更リクエストが実装されるのをプロブレムが待っていることを示すステータス遷移。「Change Requested」または類似のステータスフィールドへの変更から推測されます。 | ||
|
その重要性
プロブレム管理チームが外部の変更プロセスに依存している場合の待機時間を特定します。
取得元
アクティビティストリーム:「変更リクエスト済み」を表すIDへのステータス変更。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
メモ追加
|
パブリックまたはプライベートノートがレコードに追加された際の一般的なアクティビティ捕捉。継続的なコラボレーションまたは更新を表します。 | ||
|
その重要性
ステータスが変更されていない場合でも、アクティブな作業を示します。「アクティブな待機」期間を特定するのに役立ちます。
取得元
アクティビティストリーム:「メモ追加」イベント。
取得
コメントが投稿された際にログ記録
イベントタイプ
explicit
|
|||
|
優先度更新
|
プロブレムレコードの緊急度または影響レベルの変更。「Priority」フィールドの監査証跡を通じて記録されます。 | ||
|
その重要性
SLA違反の分析および重要プロブレムSLAパフォーマンスダッシュボードのフィルタリングに不可欠です。
取得元
アクティビティストリーム:「priority」フィールドの更新。
取得
優先度フィールドが変更された際にログ記録
イベントタイプ
explicit
|
|||
|
問題タスク完了
|
問題レコードに`添付された`サブ`タスク`の`完了`。`これは、多くの場合、`実施後`レビュー`(PIR)`または`特定`の`調査`ステップを`追跡する`ために`使用されます。 | ||
|
その重要性
取得元
アクティビティストリーム:「タスク」ステータスのクローズ/完了への変更。
取得
リンクされたタスクが完了とマークされた際にログ記録
イベントタイプ
explicit
|
|||
|
問題再開
|
「Resolved」または「Closed」状態から「Open」状態への遷移。修正が失敗したか、拒否されたことを示します。 | ||
|
その重要性
「
取得元
アクティビティストリーム:ステータスの[クローズ/解決済み]から[オープン/進行中]への変更。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
担当者割り当て済み
|
問題レコードに`特定`の`個人`担当者を`割り当てること`。`「`エージェント`」`フィールド`が`入力`または`更新`された`とき`に`明示的に`捕捉されます。 | ||
|
その重要性
リソースが正式に作業に着手した時期を示します。優先度によるリソース割り当ての分析に役立ちます。
取得元
アクティビティストリーム:「responder_id」フィールドの更新。
取得
担当者フィールドが更新された際にログ記録
イベントタイプ
explicit
|
|||
|
資産リンク済み
|
設定`アイテム`(CI)または`資産`を`問題`レコードに`関連付けること`。`これは、「影響を受ける`ビジネス``サービス`」または「影響を受ける`設定``アイテム`」を特定するのに役立ちます。 | ||
|
その重要性
抽象的なプロブレムを物理的または論理的インフラストラクチャにリンクします。根本原因分類の品質分析に不可欠です。
取得元
アクティビティストリーム:「資産との関連付け」イベント。
取得
資産がレコードに添付された際にログ記録
イベントタイプ
explicit
|
|||