変更管理データテンプレート
変更管理データテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- Freshserviceからの抽出方法
変更管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
変更管理プロセス内で発生した特定のイベントまたはタスクの名前です。 | ||
|
説明
「Change Request Created」、「Approval Requested」、「Implementation Completed」など、変更のライフサイクルにおける1つの手順またはマイルストーンを示す属性です。特定の変更リクエストIDにおけるアクティビティの順序が、プロセスマップの基礎になります。これらのアクティビティを分析すると、プロセスフローの把握、逸脱の検出、各段階にかかった時間の測定が可能です。
重要な理由
プロセスフローの手順を定義し、変更のライフサイクルを可視化するとともに、プロセスのバリアントやボトルネックを分析できます。
入手先
Freshserviceの変更レコードにある監査ログ、アクティビティストリーム、またはステータス変更履歴から生成されます。
例
変更が承認されましたリスク評価を完了実装が開始されました変更がクローズされました
|
|||
|
イベント時刻
EventTime
|
特定のアクティビティまたはイベントが発生した正確な日時です。 | ||
|
説明
プロセス内の各アクティビティには対応するタイムスタンプがあり、発生時点を示します。この時系列データは、アクティビティ間の所要時間の算出、待機時間の特定、プロセス全体のサイクルタイム分析に欠かせません。パフォーマンス分析、ボトルネックの特定、SLA遵守状況の監視にも利用できます。
重要な理由
プロセス手順間のサイクルタイム、所要時間、待機時間の算出など、時間に基づくすべての分析の基礎となるタイムスタンプです。
入手先
Freshserviceの変更レコードにある監査ログまたはアクティビティストリームの各エントリに付随するタイムスタンプです。
例
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
|
|||
|
変更リクエストID
ChangeRequestId
|
Freshserviceシステム内で送信された各変更リクエストを一意に識別するIDです。 | ||
|
説明
変更リクエストIDは、開始からクローズまで、1件の変更ケースを識別する主要なIDです。関連するすべてのアクティビティ、承認、ログを一貫したタイムラインに結び付け、エンドツーエンドのプロセス分析を可能にします。プロセスマイニングでは、各変更のライフサイクルを再構築し、その経路、所要時間、結果を把握するために欠かせません。
重要な理由
関連するすべてのイベントをまとめる重要なCase IDです。1件の変更リクエストの全体の経過を追跡し、分析できます。
入手先
FreshserviceのChangeオブジェクトにある主要フィールドです。
例
CHG-10234CHG-10235CHG-10236
|
|||
|
ソースシステム
SourceSystem
|
データが抽出されたシステムを識別します。 | ||
|
説明
プロセスデータの取得元を示す属性です。このビューでは、値は常に「Freshservice」になります。複数のシステムからデータを統合する環境では特に、この属性を含めることが推奨されます。データの背景を明確にし、データガバナンスやトラブルシューティングにも役立つためです。
重要な理由
データの出所を明確にし、複数のエンタープライズシステムから取得したデータを分析する際に役立ちます。
入手先
データ抽出時に設定され、データの取得元を示す固定値です。
例
Freshservice
|
|||
|
最終データ更新日時
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された時点を示すタイムスタンプです。 | ||
|
説明
各イベントについて、直近のデータ抽出または更新が行われた日時を記録する属性です。分析対象データの鮮度を把握し、最新情報に基づいて分析していることを確認するうえで重要です。データの整合性を保ち、分析結果がどの時点の情報に基づくものかを明確にできます。
重要な理由
データの最新性を把握できるようにし、プロセスマイニング分析が現行のデータに基づいていることを確認できます。
入手先
通常、データ取り込みまたはETLプロセス中に生成され、追加されます。
例
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
|
|||
|
リクエスト者名
RequesterName
|
変更リクエストを開始した個人の名前です。 | ||
|
説明
リクエスト者は、検討対象として変更を提出した人物です。リクエスト者別にデータを分析すると、どの個人や役割が頻繁に変更を提出しているか、特定のユーザーからのリクエストが却下またはやり直しになりやすいかといった傾向を把握できます。部門情報と組み合わせれば、業務量の分析にも利用できます。
重要な理由
変更需要の発生元を特定し、トレーニングが必要なユーザーや、変更件数の多い特定のユーザーグループを明らかにできます。
入手先
FreshserviceのChangeオブジェクトにある「Requested by」フィールドで、ユーザーレコードに紐付いています。
例
Alice JohnsonRobert SmithMaria Garcia
|
|||
|
リスクレベル
RiskLevel
|
変更を実装する際に伴うリスクを評価したレベルです。 | ||
|
説明
リスクレベルは、変更が失敗した場合に想定される悪影響の大きさを分類します。一般的にはLow、Medium、Highなどがあります。この属性は、コンプライアンス分析や、高リスクの変更がより厳格なプロセス経路(追加の承認や詳細なテストなど)に従っているかを把握するうえで重要です。リスク管理の統制が正しく適用されていることの確認にも役立ちます。
重要な理由
コンプライアンスとリスク分析に欠かせません。高リスクの変更が適切な審査を受け、より厳格なプロセスに従っていることを確認できます。
入手先
FreshserviceのChangeオブジェクトにある「Risk」フィールドに対応します。
例
低中高非常に高い
|
|||
|
変更ステータス
ChangeStatus
|
変更リクエストの現在または最終的なステータスです。 | ||
|
説明
特定の時点における変更リクエストの状態、または「Closed」、「Cancelled」、「Rejected」などの最終結果を示す属性です。正常に完了した変更と、失敗または中止された変更を区別する結果分析に欠かせません。ステータスで絞り込むと、特定の変更グループに対象を限定して分析できます。
重要な理由
変更の結果を分析し、成功率、失敗率、キャンセル率を把握できます。
入手先
FreshserviceのChangeオブジェクトにある「Status」フィールドです。
例
クローズ済みキャンセル済み却下済みオープン
|
|||
|
変更タイプ
ChangeType
|
Standard、Normal、Emergencyなど、変更の分類です。 | ||
|
説明
変更タイプは、性質、リスク、承認要件に基づいて変更リクエストを分類します。Standard変更は事前承認済み、Normal変更は標準プロセスに従い、Emergency変更は迅速な対応が必要です。変更タイプ別にプロセスを分析すると、タイプごとに異なる経路やパフォーマンス特性(サイクルタイムや成功率など)があるかを把握できます。
重要な理由
変更タイプ別にプロセスを分けると、Standard、Normal、Emergencyの変更ごとに異なるプロセスの動きやパフォーマンス水準を明らかにできます。
入手先
FreshserviceのChangeオブジェクトにある「Change Type」フィールドです。
例
標準通常緊急重大
|
|||
|
変更の優先度
ChangePriority
|
変更リクエストに割り当てられた優先度で、ビジネス上の重要性を示します。 | ||
|
説明
優先度は通常、影響度と緊急度を組み合わせて決定され、リソース配分やスケジュール設定の指針になります。優先度がサイクルタイムやSLA遵守状況などのプロセス指標に与える影響を分析すると、高優先度の変更が低優先度の変更より速く処理されているかを確認できます。優先順位付けの方針が有効かどうかの評価にも役立ちます。
重要な理由
重要度の高い変更が適切に優先され、それに応じてリソースが配分されているかを確認できます。
入手先
FreshserviceのChangeオブジェクトにある「Priority」フィールドです。
例
低中高至急
|
|||
|
担当グループ
AssignedGroup
|
変更の実装を担当するチームまたはグループです。 | ||
|
説明
変更作業を実施する担当チームを示す属性です。たとえば「Network Team」や「Database Administrators」などです。担当グループ別にプロセスのパフォーマンスを分析すると、チームの業務量や効率を把握し、リソースのボトルネックを特定できます。実装時間が長いチームや、実装後の問題が多いチームも明らかになります。
重要な理由
実装チームごとのパフォーマンスと業務量を分析し、リソースの制約や優れた取り組みを特定できます。
入手先
FreshserviceのChangeオブジェクトにある「Group」または「Assigned Group」フィールドです。
例
インフラストラクチャチームアプリケーションサポートセキュリティ運用
|
|||
|
目標完了日
TargetCompletionDate
|
変更を完了すべき予定日、またはサービスレベル合意(SLA)に基づく期限です。 | ||
|
説明
変更リクエストをクローズする期限を示す日付です。SLA遵守状況を測定する主要な基準になります。実際の終了時刻と目標完了日を比較すると、変更が予定どおり、予定より早く、または遅れて完了したかを判定できます。「Change SLA Adherence Rate」KPIの主要な入力値です。
重要な理由
期限どおりに提供できたか、またSLAを遵守できたかを測定する基準になります。いずれもプロセスパフォーマンスを示す重要な指標です。
入手先
FreshserviceのChangeオブジェクトにある「Due by」または「SLA Target」などの専用日付フィールドが該当します。
例
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
|
|||
|
終了時刻
EndTime
|
変更リクエストケースで最後に記録されたイベントのタイムスタンプです。 | ||
|
説明
終了時刻は、変更リクエストのライフサイクルが終了した時点を示し、通常は「Change Closed」または「Change Cancelled」アクティビティに対応します。開始時刻と組み合わせて、各ケースのエンドツーエンドの総サイクルタイムを算出します。この属性を分析すると、変更管理プロセス全体の所要時間と処理量を把握できます。
重要な理由
変更リクエストの総サイクルタイムを算出するために欠かせません。プロセス効率を測る主要KPIです。
入手先
特定の変更リクエストIDにおけるイベントログの最終アクティビティのタイムスタンプです。
例
2023-11-05T18:00:00Z2023-11-06T09:45:00Z
|
|||
|
SLA違反の有無
IsSlaBreached
|
変更リクエストが目標日を過ぎて完了したかどうかを示すブール値のフラグです。 | ||
|
説明
SLA遵守状況を示す二値の属性です。変更の終了時刻が目標完了日より後の場合は「true」、それ以外は「false」になります。SLA遵守状況に関するダッシュボードやKPIを簡単に作成でき、期限超過の変更をすばやく絞り込み、集計できます。「Change SLA Adherence Rate」KPIを直接支援します。
重要な理由
SLAパフォーマンスを明確な二値の結果で示し、期限内の変更と期限超過の変更を簡単に絞り込み、レポートできます。
入手先
EndTimeとTargetCompletionDateを比較して算出します。EndTime > TargetCompletionDateの場合はtrueです。
例
truefalse
|
|||
|
クローズコード
CloseCode
|
変更リクエストをクローズした理由または理由コードです。 | ||
|
説明
クローズコードは、クローズされた変更の結果に関する詳細を示します。例として、「Implemented Successfully」、「Backed Out」、「Rejected」などがあります。最終ステータスだけでは分からない背景を補い、変更管理プロセスにおける成功や失敗のパターンをより細かく分析できます。
重要な理由
変更結果の詳細を把握し、変更が成功、失敗、または切り戻しになった理由を深く分析できます。
入手先
Freshserviceのドキュメントを参照するか、Changeフォームに「Closure Code」または同様のフィールドがあるか確認してください。
例
成功問題ありで成功失敗切り戻し済み
|
|||
|
実装所要時間
ImplementationDuration
|
変更の実装フェーズにかかった時間です。 | ||
|
説明
この指標は、通常、「Implementation Started」アクティビティから「Implementation Completed」アクティビティまでの時間を測定し、実装作業の所要時間を算出します。技術的な実行フェーズの効率分析に使用し、「Change Implementation Phase Efficiency」ダッシュボードを支援します。所要時間が長い場合は、技術的な複雑さ、リソース不足、予期しない課題などが考えられます。
重要な理由
計画や承認の遅延とは分けて、技術作業そのものの効率を測定します。
入手先
「Implementation Started」アクティビティと「Implementation Completed」アクティビティの時間差として算出します。
例
4時間1時間30分8時間
|
|||
|
影響度
ImpactLevel
|
変更が失敗した場合、またはサービス中断を引き起こした場合に想定されるビジネスへの影響を評価したレベルです。 | ||
|
説明
影響度は、1人のユーザーに影響する低レベルから、組織全体に影響する高レベルまで、業務への潜在的な影響を示します。通常、緊急度とともに全体の優先度を決定します。影響度別に分析すると、事業継続性に大きな脅威となる変更が適切に処理されているかを把握できます。
重要な理由
リスク分析に役立ち、ビジネスへの影響が大きい変更がより慎重に管理されていることを確認できます。
入手先
FreshserviceのChangeオブジェクトにある「Impact」フィールドに対応します。
例
低中高
|
|||
|
承認所要時間
ApprovalDuration
|
変更リクエストが承認段階にとどまった時間です。 | ||
|
説明
承認を依頼してから、承認または却下されるまでの時間を測定する計算値です。「Change Approval Phase Duration」ダッシュボードに欠かせず、承認ワークフローのボトルネックを特定できます。この指標を分析すると、承認者の対応の遅れ、グループ間の引き継ぎの非効率、意思決定における構造的な遅延を明らかにできます。
重要な理由
承認段階の効率を直接測定し、変更を遅らせるボトルネックを特定して解消するのに役立ちます。
入手先
「Approval Requested」アクティビティと「Change Approved」または「Change Rejected」アクティビティの間の時間差として算出します。
例
1日2時間5時間30分3日
|
|||
|
緊急度
Urgency
|
ビジネス上、変更をどれだけ早く実装する必要があるかを示します。 | ||
|
説明
緊急度は、変更の時間的な切迫度を示します。たとえば、セキュリティパッチは緊急度が高い場合があります。通常、影響度と組み合わせて優先度を設定し、時間的制約のあるビジネスニーズにプロセスが適切に対応できているかを分析できます。緊急度の高い変更が実際にプロセスを速く通過しているかも確認できます。
重要な理由
変更の時間的な切迫度を把握でき、サイクルタイムと関連付けてプロセスの応答性を評価できます。
入手先
FreshserviceのChangeオブジェクトにある「Urgency」フィールドです。
例
低中高
|
|||
|
部門名
DepartmentName
|
変更をリクエストしたユーザーの所属部門です。 | ||
|
説明
変更リクエストを開始した事業部門を示し、組織上の背景を提供する属性です。部門別に分析すると、どの部門が最も多く変更を発生させているか、却下率が高いか、サイクルタイムが長いかを明らかにできます。対象を絞ったプロセス改善やリソース計画に役立つ情報です。
重要な理由
異なる事業部門のプロセスパフォーマンスと需要を分析し、対象を絞った改善を進められます。
入手先
通常、Freshserviceに登録されたリクエスト者のユーザープロファイルから取得されます。
例
財務人事情報技術マーケティング
|
|||
|
関連インシデント数
AssociatedIncidentsCount
|
実装後にこの変更リクエストへ関連付けられたインシデントの数です。 | ||
|
説明
デプロイの結果として作成されたインシデント数を数え、変更が下流に及ぼした影響を定量化する指標です。件数が多い場合は、計画、テスト、または実装の品質に問題がある可能性があります。「Post-Implementation Issue Rate」KPIの直接的な入力値であり、変更の安定性と成否を測定するうえで欠かせません。
重要な理由
実装された変更の品質と安定性を直接測定し、サービス中断を引き起こした変更を特定できます。
入手先
Freshserviceで変更チケットに関連付けられたIncidentチケットの数を数えて算出します。
例
015
|
|||
変更管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
変更がクローズされました
|
変更管理プロセスが正式に正常完了したことを示します。変更チケットのステータスが最終状態である「Closed」に移行した際に、このイベントが取得されます。 | ||
|
重要な理由
プロセスの主要な終了イベントです。エンドツーエンドの「Average Change Cycle Time」と「Change SLA Adherence Rate」を算出するための最終データポイントになります。
入手先
変更チケットの履歴で、最終ステータスが「Closed」に変更された時点のタイムスタンプから取得されます。
取得
最終ステータスが「Closed」に変更された時点のタイムスタンプです。
イベントタイプ
explicit
|
|||
|
変更がスケジュールされました
|
承認済みの変更を実装する具体的な開始時刻と終了時刻を設定するアクティビティです。通常、「Scheduled Start Time」と「Scheduled End Time」フィールドに値が入力されたことから推定されます。 | ||
|
重要な理由
実装段階の開始を促す重要なマイルストーンです。「Average Implementation Time」の算出やスケジュール効率の分析に欠かせません。
入手先
スケジュール関連の日付フィールドが入力され、ステータスが「Scheduled」または同様の値に変更された時点のタイムスタンプから推定されます。
取得
「Scheduled Start Date」が入力され、対応するステータスが更新されたことから推定されます。
イベントタイプ
inferred
|
|||
|
変更が承認されました
|
Change Advisory Board(CAB)などの指定された承認権限者が、変更リクエストを進めることを正式に承認する重要なマイルストーンです。通常、システムに明示的なアクションとして記録されます。 | ||
|
重要な理由
承認段階の終了と、実装計画の開始を示します。このアクティビティは、「Average Change Approval Time」と「First-Pass Approval Rate」を測定するうえで欠かせません。
入手先
承認者が「Approve」ボタンをクリックした際、Freshserviceによって明示的なイベントとして記録されます。イベントはタイムスタンプとともにチケットのアクティビティログに保存されます。
取得
承認タブまたはアクティビティログに記録された「Approved」アクションのタイムスタンプです。
イベントタイプ
explicit
|
|||
|
変更要求を作成
|
Freshserviceに新しい変更リクエストが正式に記録され、変更管理プロセスが正式に開始されたことを示します。ユーザーが新しい変更チケットを保存すると、このイベントが明示的に記録され、一意のChange Request IDと作成タイムスタンプが生成されます。 | ||
|
重要な理由
これはプロセスの主要な開始イベントです。このアクティビティから「Change Closed」までの時間を分析することで、プロセス効率の主要KPIであるエンドツーエンドのサイクルタイムを把握できます。
入手先
変更レコードの監査履歴に明示的なイベントとして記録されます。変更チケットの作成タイムスタンプに対応します。
取得
変更リクエストレコードの作成タイムスタンプです。
イベントタイプ
explicit
|
|||
|
実装が完了しました
|
変更を実装する技術的な作業が完了したことを示します。通常、「Pending Review」など、実装後の状態を示すステータスへの変更から推定されます。 | ||
|
重要な理由
中核となる実装作業の終了を示すマイルストーンです。「Average Implementation Time」を算出する際の終点となり、テストまたはレビューの開始を示します。
入手先
「Pending Review」、「Awaiting Testing」、「Completed」などの値へステータスが変更されたことから推定されます。
取得
ステータスフィールドが「Pending Review」または同様の値に変更されたことから推定されます。
イベントタイプ
inferred
|
|||
|
テストが完了しました
|
変更が正常に完了し、悪影響を引き起こしていないことを確認するために必要なテストと検証がすべて完了したことを示します。タスクのクローズまたはステータス変更から推定される場合があります。 | ||
|
重要な理由
このアクティビティを追跡すると、「Testing Completion Rate」KPIを測定でき、最終的にクローズする前に変更が適切に検証されたことを確認できます。実装後の問題の削減にもつながります。
入手先
この情報の取得は難しい場合があり、関連付けられた「Testing」タスクの完了、またはステータスが「Testing Complete」に変更されたことから推定する必要があります。
取得
変更に関連付けられたテスト関連タスクがクローズされたことから推定されます。
イベントタイプ
inferred
|
|||
|
リスク評価を完了
|
変更に伴う潜在的なリスクの正式な評価が完了したことを示します。通常は、リスクレベル項目が入力または更新された時点、または関連タスクが完了した時点から推定します。 | ||
|
重要な理由
このアクティビティを追跡することで、リスク評価を義務付ける変更ポリシーへのコンプライアンスを確認できます。「Risk Assessment Coverage」や、この重要なステップにかかった時間も分析できます。
入手先
変更フォームの「Risk」項目がタイムスタンプ付きで更新された時点、またはリスク分析に関する特定のタスクが完了した時点から推定します。
取得
「Risk」項目が入力された時点のタイムスタンプ、または関連するチェックリスト項目が完了としてマークされた時点から推定します。
イベントタイプ
inferred
|
|||
|
変更がキャンセルされました
|
変更リクエストが完了前に終了したことを示します。チケットのステータスが「Cancelled」または「Withdrawn」に設定された際に取得される、別の終了状態です。 | ||
|
重要な理由
キャンセルされた変更を分析すると、初期の計画や承認段階にある問題を明らかにできます。たとえば、リクエストが不要になった、または有効なビジネス上の根拠がないといった問題です。
入手先
ステータスが「Cancelled」またはそれに相当する終端ステータス(「Closed」以外)に変更された時点のタイムスタンプから取得されます。
取得
ステータスが「Cancelled」に変更された時点のタイムスタンプです。
イベントタイプ
explicit
|
|||
|
変更が再オープンされました
|
以前にクローズまたは解決された変更が、通常は実装後に発見された問題を理由にオープン状態へ戻されたときに発生します。クローズ状態からオープン状態へのステータス変更から推定されます。 | ||
|
重要な理由
このアクティビティは、やり直しや変更の失敗を示す強い指標です。発生頻度を追跡することは、変更の品質とテストの有効性を把握するうえで重要です。
入手先
チケットのアクティビティログで、「Closed」または「Resolved」から「Open」または「In Progress」へステータスが戻ったことを検出して推定されます。
取得
終端状態(例:「Closed」)から非終端状態(例:「Open」)へのステータス変更を検出します。
イベントタイプ
inferred
|
|||
|
変更が却下されました
|
承認者が変更リクエストを正式に却下し、先に進められない状態になったことを示します。このアクションは明示的に記録され、多くの場合、プロセスはやり直しのループに入ります。 | ||
|
重要な理由
このアクティビティは、やり直しの分析やプロセス失敗の原因特定に欠かせません。却下の頻度が高い場合は、リクエストの品質やリスク評価に問題がある可能性があります。
入手先
承認者が「Reject」ボタンをクリックした際、Freshserviceによって明示的なイベントとして記録されます。イベントはチケットのアクティビティログに保存されます。
取得
承認タブまたはアクティビティログに記録された「Rejected」アクションのタイムスタンプです。
イベントタイプ
explicit
|
|||
|
変更へのメモ追加
|
変更リクエストにコメントやメモが追加されたことを示すアクティビティです。Freshserviceでは、各チケットのアクティビティフィードにこれらのイベントが明示的に記録されます。 | ||
|
重要な理由
中核となるプロセス手順ではありませんが、メモを追跡すると、特に承認や計画の段階で発生した遅延の背景を把握できます。メモの頻度が高い場合は、要件が不明確である、またはコミュニケーションに問題がある可能性があります。
入手先
変更リクエストチケットの「Activity」または「Audit」セクションに、タイムスタンプとメモを追加したユーザーとともに明示的に記録されます。
取得
チケットのアクティビティログに「Note Added」イベントとして記録されます。
イベントタイプ
explicit
|
|||
|
実装が開始されました
|
変更の実際のデプロイまたは実行が始まったことを示します。通常、変更リクエストのステータスが「In Progress」または同様の進行中の状態に更新されたことから推定されます。 | ||
|
重要な理由
実装が進行している期間を追跡するための明確な開始点になります。待機時間と実際に作業している時間を区別できます。
入手先
予定された開始時刻に、「In Progress」や「Implementation in Progress」などの値へステータスが変更されたことから推定されます。
取得
ステータスフィールドが「In Progress」に変更されたことから推定されます。
イベントタイプ
inferred
|
|||
|
実装後レビューが完了しました
|
変更の成否を評価し、得られた教訓を記録するPost-Implementation Review(PIR)が完了したことを示します。実装後にレビュー用のメモが追加されたこと、またはステータスが更新されたことから推定される場合があります。 | ||
|
重要な理由
正式なレビュー手順が実施されたことを確認できます。このアクティビティを分析すると、変更の有効性を把握し、継続的なプロセス改善に役立てられます。
入手先
実装日後に変更フォームのPIR関連フィールドが入力されたこと、またはステータスが「Review Complete」などの状態に変更されたことから推定されます。
取得
PIRメモフィールドに値が入力されたこと、または特定のステータス更新から推定されます。
イベントタイプ
inferred
|
|||
|
承認を依頼
|
変更リクエストが正式にレビューと承認に提出された時点を示します。通常は、変更リクエストのステータスが「Awaiting Approval」などに変わった時点、または承認者に割り当てられた時点から推定します。 | ||
|
重要な理由
このアクティビティは承認フェーズの開始を示します。この時点から「Change Approved」までの所要時間を測定することは、承認サイクルのボトルネックを特定するうえで重要です。
入手先
Activity Logから推定するか、ステータス項目が「Awaiting Approval」に変わったことを追跡して特定します。このステータス変更のタイムスタンプをイベント時刻として使用します。
取得
ステータス項目が「Awaiting Approval」に変わったことから推定します。
イベントタイプ
inferred
|
|||
|
計画が完了しました
|
実装計画や切り戻し計画の作成など、変更に必要な計画がすべて確定したことを示します。通常、承認後のステータス変更から推定されます。 | ||
|
重要な理由
計画から実行への移行を示します。計画段階の所要時間を分析すると、実装前のアクティビティを効率化できる箇所を特定できます。
入手先
「Pending Release」などの計画関連ステータスから、「Scheduled」などの実装ステータスへ変更されたことから推定されます。
取得
「Planning in Progress」または同様の状態から別のステータスへ変更されたことから推定されます。
イベントタイプ
inferred
|
|||
抽出ガイド
始める準備はできていますか?
この詳細なテンプレートでデータを準備し、今日から変更管理の改善に取り組みましょう。隠れた課題を見つけ出し、より効率的なデプロイを実現できます。
失敗する変更を防ぎ、Freshserviceの管理を今すぐ改善
変更の成功率95%を達成し、Freshserviceの中断と遅延をなくします。
クレジットカードは不要です。数分で始められます。