変更管理データテンプレート
変更管理データテンプレート
- 収集を推奨する属性
- 追跡する主要なアクティビティ
- Freshserviceからのデータ抽出ガイド
変更管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
変更管理プロセスで発生した特定のイベントまたはTaskの名前です。 | ||
|
説明
この属性は、「変更要求の作成」「承認依頼」「実施の完了」など、変更のライフサイクルにおける個々の手順や節目を表します。変更要求IDごとのアクティビティの順序が、プロセスマップの基礎になります。アクティビティを分析すると、プロセスの流れを把握し、逸脱を検出し、各段階にかかった時間を測定できます。
重要な理由
プロセスの流れを構成する手順を定義し、変更のライフサイクルを可視化するとともに、プロセスのバリアントやボトルネックを分析できるようにします。
入手先
FreshserviceのChangeレコードにある監査ログ、アクティビティストリーム、またはステータス変更履歴から生成されます。
例
変更の承認リスク評価の完了実施の開始変更の完了
|
|||
|
イベント時刻
EventTime
|
特定のアクティビティまたはイベントが発生した正確な日時です。 | ||
|
説明
プロセス内の各アクティビティには、発生時刻を示すタイムスタンプがあります。この時刻データは、アクティビティ間の所要時間の算出、待機時間の特定、プロセス全体のサイクルタイムの分析に欠かせません。パフォーマンス分析やボトルネックの特定、SLA遵守状況のモニタリングにも役立ちます。
重要な理由
サイクルタイムや所要時間、プロセスの各手順間の待機時間など、時間に基づく分析の基礎となるタイムスタンプです。
入手先
FreshserviceのChangeレコードにある監査ログまたはアクティビティストリームの各エントリーに付与されたタイムスタンプです。
例
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
|
|||
|
変更要求ID
ChangeRequestId
|
Freshserviceに提出された各変更要求を識別する固有のIDです。 | ||
|
説明
変更要求IDは、開始から完了まで、個々の変更案件を識別する主キーです。関連するすべてのアクティビティ、承認、ログを一連の時系列にまとめ、プロセス全体を分析できるようにします。プロセスマイニングでは、このIDを使って各変更のライフサイクルを再構成し、経路、所要時間、結果を把握します。
重要な理由
関連するすべてのイベントをまとめる重要なケースIDです。1件の変更要求の全体を追跡し、分析できます。
入手先
FreshserviceのChangeオブジェクトにある主要な項目です。
例
CHG-10234CHG-10235CHG-10236
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となるシステムを示します。 | ||
|
説明
この属性は、プロセスデータの取得元を示します。このビューでは、値は常に「Freshservice」です。複数のシステムからデータを統合する環境では特に、この属性を含めることが推奨されます。データのガバナンスや問題の調査に必要なコンテキストを確認できます。
重要な理由
データの出所を明確にできるため、複数のエンタープライズシステムのデータを分析する際に役立ちます。
入手先
データ抽出時に設定し、データの取得元を示す固定値です。
例
Freshservice
|
|||
|
最終データ更新日時
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
この属性には、各イベントのデータが最後に抽出または更新された日時が記録されます。分析対象のデータがどの程度新しいかを把握し、最新の情報に基づいて分析するうえで重要です。データの整合性を保ち、インサイトの適時性を判断するためのコンテキストにもなります。
重要な理由
データの新しさを把握し、プロセスマイニング分析が最新のデータに基づいているか確認できます。
入手先
通常、データの取り込みまたはETL処理の際に生成され、追加されるタイムスタンプです。
例
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
|
|||
|
リスクレベル
RiskLevel
|
変更の実施に伴うリスクの評価レベルです。 | ||
|
説明
リスクレベルは、変更が失敗した場合に想定される悪影響の大きさを分類します。一般的には、低、中、高などのレベルがあります。この属性はコンプライアンス分析に欠かせません。リスクの高い変更に対して、追加の承認やより詳細なテストを求めるなど、より厳格なプロセスが適用されているかを把握できます。リスク管理の統制が適切に実施されているかの確認にも役立ちます。
重要な理由
コンプライアンスとリスク分析に欠かせない属性です。リスクの高い変更が適切に審査され、より厳格なプロセスに沿って進められているかを確認できます。
入手先
FreshserviceのChangeオブジェクトにある「Risk」フィールドに該当します。
例
低中高非常に高い
|
|||
|
依頼者名
RequesterName
|
変更リクエストを開始した人の名前です。 | ||
|
説明
依頼者とは、検討を依頼するために変更を申請した人です。依頼者別にデータを分析すると、変更を頻繁に申請する人やロール、特定のユーザーからの依頼が却下されたり、手戻りが発生したりしやすいかなどの傾向を把握できます。部門情報と組み合わせれば、業務負荷の分析にも役立ちます。
重要な理由
変更の需要がどこから生じているかを把握し、トレーニングが必要な人や変更件数の多いユーザーグループを特定できます。
入手先
FreshserviceのChangeオブジェクトにある「Requested by」フィールドで、ユーザーレコードに紐づいています。
例
Alice JohnsonRobert SmithMaria Garcia
|
|||
|
割り当て先グループ
AssignedGroup
|
変更の実施を担当するチームまたはグループです。 | ||
|
説明
この属性は、変更作業を担当するチーム(「Network Team」や「Database Administrators」など)を示します。割り当て先グループ別にプロセスのパフォーマンスを分析すると、チームの業務負荷や効率を把握し、リソースのボトルネックを特定できます。実施に時間がかかるチームや、実施後に問題が発生する割合の高いチームも明らかになります。
重要な理由
実施を担当するチームごとのパフォーマンスや業務負荷を分析し、リソースの制約や優れた取り組みを特定できます。
入手先
FreshserviceのChangeオブジェクトにある「Group」または「Assigned Group」フィールドです。
例
インフラストラクチャチームアプリケーションサポートセキュリティ運用
|
|||
|
変更ステータス
ChangeStatus
|
変更要求の現在または最終のステータスです。 | ||
|
説明
この属性は、特定の時点における変更要求の状態、または「クローズ」「キャンセル」「却下」などの最終結果を示します。変更が正常に完了したか、失敗または中止されたかを区別し、結果を分析するうえで重要です。ステータスで絞り込むと、対象を特定の変更グループに限定して分析できます。
重要な理由
変更の結果を分析し、成功率、失敗率、キャンセル率を把握できます。
入手先
FreshserviceのChangeオブジェクトにある「ステータス」項目です。
例
クローズキャンセル却下オープン
|
|||
|
変更の優先度
ChangePriority
|
変更リクエストに割り当てられた優先度です。業務上の重要性を示します。 | ||
|
説明
優先度は通常、影響度と緊急度を組み合わせて決まり、リソースの割り当てやスケジュールの調整に使われます。優先度がサイクルタイムやSLAの遵守状況などのプロセス指標に与える影響を分析すると、優先度の高い変更が低い変更より速く処理されているかを確認できます。また、優先順位付けの方針が有効かどうかを評価するのにも役立ちます。
重要な理由
重要度の高い変更が適切に優先され、それに応じてリソースが割り当てられているかを確認できます。
入手先
FreshserviceのChangeオブジェクトにある「Priority」フィールドです。
例
低中高至急
|
|||
|
変更の種類
ChangeType
|
標準、通常、緊急など、変更の分類です。 | ||
|
説明
変更の種類は、性質、リスク、承認要件に基づいて変更要求を分類します。標準変更は事前承認済みで、通常変更は標準プロセスに従い、緊急変更は迅速な対応が必要です。変更の種類ごとにプロセスを分析すると、種類によって経路やパフォーマンス(サイクルタイムや成功率など)が異なるかを把握できます。
重要な理由
変更の種類ごとにプロセスを分けて分析すると、標準変更、通常変更、緊急変更の動きやパフォーマンスの違いが明らかになります。
入手先
FreshserviceのChangeオブジェクトにある「変更の種類」項目です。
例
標準通常緊急重大
|
|||
|
目標完了日
TargetCompletionDate
|
変更を完了する予定日、またはサービスレベル合意(SLA)上の期限です。 | ||
|
説明
変更リクエストを完了する期限を示す日付です。SLAの遵守状況を測る際の主な基準となります。実際の終了時刻と目標完了日を比較することで、変更が期限どおり、期限前、または期限後に完了したかを確認できます。変更SLA遵守率の重要業績評価指標(KPI)を算出する際にも使われます。
重要な理由
期限どおりの納品とSLAの遵守状況を測る基準となり、プロセスのパフォーマンスを示す重要な指標です。
入手先
FreshserviceのChangeオブジェクトにある「Due by」や「SLA Target」などの専用日付フィールドが該当します。
例
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
|
|||
|
終了時刻
EndTime
|
変更要求のケースで最後に記録されたイベントのタイムスタンプです。 | ||
|
説明
終了時刻は、変更要求のライフサイクルの終了を示し、通常は「変更の完了」または「変更のキャンセル」に該当します。開始時刻と組み合わせて、各ケースのエンドツーエンドのサイクルタイムを算出します。この属性を分析すると、変更管理プロセス全体の所要時間や処理量を把握できます。
重要な理由
変更要求の全体のサイクルタイムを算出するために必要です。サイクルタイムは、プロセス効率を示す主要な重要業績評価指標(KPI)です。
入手先
特定の変更要求IDに対応するイベントログで、最後のアクティビティのタイムスタンプです。
例
2023-11-05T18:00:00Z2023-11-06T09:45:00Z
|
|||
|
SLA違反の有無
IsSlaBreached
|
変更リクエストが目標日を過ぎて完了したかどうかを示す真偽値です。 | ||
|
説明
この属性は、SLAの遵守状況を真偽値で示します。変更の終了時刻が目標完了日より後の場合は「true」、それ以外は「false」です。SLA遵守状況に関するダッシュボードや重要業績評価指標(KPI)を簡単に作成でき、期限を過ぎた変更の絞り込みや集計にも役立ちます。変更SLA遵守率の重要業績評価指標(KPI)にも直接使われます。
重要な理由
SLAの達成状況を明確な真偽値で示すため、期限内に完了した変更と期限を過ぎた変更を簡単に絞り込み、レポートできます。
入手先
EndTimeとTargetCompletionDateを比較して算出します。EndTime > TargetCompletionDateの場合はtrueです。
例
truefalse
|
|||
|
クローズコード
CloseCode
|
変更リクエストをクローズした理由を示すコードまたは理由です。 | ||
|
説明
クローズコードは、完了した変更の結果を詳しく示します。「実施成功」「切り戻し」「却下」などが例です。最終ステータスだけでは分からない情報が加わるため、変更管理プロセスにおける成功や失敗のパターンをより詳しく分析できます。
重要な理由
変更の結果を詳しく把握できるため、成功、失敗、切り戻しの理由を掘り下げて分析できます。
入手先
Freshserviceの文書を確認するか、Changeフォームに「Closure Code」または同様のフィールドがあるか確認してください。
例
成功問題ありで成功失敗切り戻し
|
|||
|
実施所要時間
ImplementationDuration
|
変更の実施段階にかかった時間です。 | ||
|
説明
この指標は、変更の中心となる実施作業にかかった時間を算出します。通常、「実施開始」アクティビティから「実施完了」アクティビティまでの時間を測定します。技術的な実施段階の効率分析に使われ、「変更実施段階の効率」ダッシュボードを支えます。所要時間が長い場合は、技術的な複雑さ、リソース不足、予期しない課題などが考えられます。
重要な理由
計画や承認の遅れとは分けて、技術的な実作業の効率を測定できます。
入手先
「実施開始」アクティビティから「実施完了」アクティビティまでの時間差として算出します。
例
4時間1時間30分8時間
|
|||
|
影響度
ImpactLevel
|
変更が失敗した場合やサービスの中断を招いた場合に想定される、業務への影響度です。 | ||
|
説明
影響度は、1人のユーザーへの影響から組織全体への影響まで、業務への影響の大きさを示します。緊急度と組み合わせて、全体の優先度を決めることもよくあります。影響度別に分析すると、事業継続に大きな脅威をもたらす変更がプロセスで適切に扱われているかを確認できます。
重要な理由
リスク分析に役立ち、業務への影響が大きい変更がより慎重に管理されているかを確認できます。
入手先
FreshserviceのChangeオブジェクトにある「Impact」フィールドに該当します。
例
低中高
|
|||
|
承認所要時間
ApprovalDuration
|
変更リクエストが承認段階にとどまった時間です。 | ||
|
説明
承認を依頼してから、承認または却下されるまでの時間を算出します。「変更承認段階の所要時間」ダッシュボードに欠かせない指標で、承認ワークフローのボトルネックを特定するのに役立ちます。この指標を分析すると、承認の遅い担当者、グループ間の非効率な引き継ぎ、意思決定の構造的な遅れなどが分かります。
重要な理由
承認段階の効率を直接測定し、変更の遅れにつながるボトルネックの特定と解消に役立ちます。
入手先
「承認依頼」アクティビティから「変更承認」または「変更却下」アクティビティまでの時間差として算出します。
例
1日2時間5時間30分3日
|
|||
|
緊急度
Urgency
|
業務上、変更をどれだけ早く実施する必要があるかを示します。 | ||
|
説明
緊急度は、変更にどれほど時間的な切迫性があるかを示します。たとえば、セキュリティパッチは緊急度が高い場合があります。優先度の設定にあたり影響度と組み合わせて使われることが多く、時間に制約のある業務ニーズにプロセスが適切に対応しているかを分析できます。緊急度の高い変更が実際にプロセスを速く進んでいるかも確認できます。
重要な理由
変更の時間的な切迫性を把握できます。サイクルタイムと照らし合わせることで、プロセスの対応速度を評価できます。
入手先
FreshserviceのChangeオブジェクトにある「Urgency」フィールドです。
例
低中高
|
|||
|
部門名
DepartmentName
|
変更を依頼したユーザーの部門です。 | ||
|
説明
この属性は、変更リクエストを開始した事業部門を示し、組織内での位置づけを把握するのに役立ちます。部門別に分析すると、変更件数が最も多い部門、却下率が高い部門、サイクルタイムが長い部門などを特定できます。こうした情報は、対象を絞ったプロセス改善やリソース計画に役立ちます。
重要な理由
事業部門ごとのプロセスのパフォーマンスや需要を分析し、対象を絞った改善につなげられます。
入手先
通常はFreshserviceの依頼者のユーザープロフィールから取得します。
例
財務人事情報技術マーケティング
|
|||
|
関連インシデント数
AssociatedIncidentsCount
|
変更の実施後に、この変更リクエストに紐づけられたインシデントの数です。 | ||
|
説明
この指標は、変更の実施によって発生したインシデントの件数を数え、変更が後続業務に与えた影響を示します。件数が多い場合、計画、テスト、または実施の品質に問題がある可能性があります。実施後の問題発生率の重要業績評価指標(KPI)の算出に直接使われ、変更の安定性や成否を測るうえで欠かせません。
重要な理由
実施した変更の品質と安定性を直接測定し、サービスの中断を引き起こした変更の特定に役立ちます。
入手先
FreshserviceでChangeチケットに紐づくIncidentチケットの件数から算出します。
例
015
|
|||
変更管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
変更のスケジュール設定
|
承認された変更の実施開始時刻と終了時刻を設定するアクティビティです。通常、「実施予定開始時刻」と「実施予定終了時刻」の項目に値が入力されたときに推定します。 | ||
|
重要な理由
実施段階の開始につながる重要な節目です。「実施時間の平均」の算出や、スケジュール設定の効率分析に欠かせません。
入手先
スケジュール関連の日付項目が入力されたタイムスタンプと、ステータスが「スケジュール済み」などに変わった履歴から推定します。
記録
「実施予定開始日」の入力と、それに対応するステータス更新から推定します。
イベントタイプ
inferred
|
|||
|
変更の完了
|
変更管理プロセスが正常に完了したことを正式に示します。変更チケットのステータスが最終状態の「クローズ」に変更されたときに記録されます。 | ||
|
重要な理由
このイベントは、プロセスの主な終了イベントです。エンドツーエンドの「変更サイクルタイムの平均」と「変更SLA遵守率」を算出するための最終データポイントです。
入手先
変更チケットの履歴で、ステータスが最終的に「クローズ」に変わった時刻から記録します。
記録
ステータスが最終的に「クローズ」に変わったタイムスタンプです。
イベントタイプ
explicit
|
|||
|
変更の承認
|
変更諮問委員会(CAB)など、指定された権限者が変更要求の実施を正式に承認する重要な節目です。通常、システムに明示的な操作として記録されます。 | ||
|
重要な理由
承認段階の終了と、実施計画の開始を示します。このアクティビティは、「変更承認時間の平均」や「初回承認率」の測定に欠かせません。
入手先
承認者が「承認」ボタンをクリックすると、Freshserviceに明示的なイベントとして記録されます。イベントはタイムスタンプとともにチケットのアクティビティログに保存されます。
記録
承認タブまたはアクティビティログに記録された「承認済み」操作のタイムスタンプです。
イベントタイプ
explicit
|
|||
|
変更要求の作成
|
Freshserviceに新しい変更要求が正式に登録され、変更管理プロセスが開始したことを示します。ユーザーが新しい変更チケットを保存すると、このイベントが記録され、固有の変更要求IDと作成時刻が付与されます。 | ||
|
重要な理由
このイベントは、プロセスの主な開始イベントです。このアクティビティから「変更完了」までの時間を分析すると、プロセス効率を示す重要業績評価指標(KPI)であるエンドツーエンドのサイクルタイムを算出できます。
入手先
変更レコードの監査履歴に明示的に記録されるイベントです。変更チケットの作成時刻に該当します。
記録
変更要求レコードの作成時刻です。
イベントタイプ
explicit
|
|||
|
実施の完了
|
変更を実施する技術作業が完了したことを示します。通常、「レビュー待ち」など実施後のステータスへの変更から推定します。 | ||
|
重要な理由
この節目は、実施の中核となる作業の終了を示します。「実施時間の平均」を算出する際の終点となり、テストやレビューの開始を示します。
入手先
ステータスが「レビュー待ち」「テスト待ち」「完了」などに変わった履歴から推定します。
記録
ステータス項目が「レビュー待ち」などに変わった履歴から推定します。
イベントタイプ
inferred
|
|||
|
テストの完了
|
変更が正常に完了し、悪影響が生じていないことを確認するために必要なテストと検証がすべて完了したことを示します。Taskの完了やステータス変更から推定する場合があります。 | ||
|
重要な理由
このアクティビティを追跡すると、「テスト完了率」を測定し、最終完了前に変更が適切に検証されたことを確認できます。実施後の問題の抑制にもつながります。
入手先
このイベントの記録は難しい場合があり、関連付けられた「テスト」Taskの完了や、ステータスが「テスト完了」に変わった履歴から推定する必要があります。
記録
変更に関連するテスト用Taskの完了から推定します。
イベントタイプ
inferred
|
|||
|
リスク評価の完了
|
変更に伴う潜在的なリスクの正式な評価が完了したことを示します。リスクレベル項目への入力や更新、または関連するTaskの完了から推定する場合があります。 | ||
|
重要な理由
このアクティビティを追跡すると、リスク評価を義務付ける変更ポリシーへの準拠を確認できます。「リスク評価の実施率」や、この重要な手順にかかった時間も分析できます。
入手先
変更フォームの「リスク」項目が更新されたタイムスタンプ、またはリスク分析に関する特定のTaskの完了から推定できます。
記録
「リスク」項目に値が入力された時刻、または関連するチェックリスト項目が完了になった時刻から推定します。
イベントタイプ
inferred
|
|||
|
変更のキャンセル
|
変更要求が完了前に終了したことを示します。別の終了状態であり、チケットのステータスが「キャンセル」または「取り下げ」に設定されたときに記録されます。 | ||
|
重要な理由
キャンセルされた変更を分析すると、初期の計画や承認段階における問題を明らかにできます。たとえば、不要になった要求や、妥当なビジネス上の根拠がない要求を特定できます。
入手先
ステータスが「キャンセル」または「クローズ」以外の同等の終端状態に変わったタイムスタンプから記録します。
記録
ステータスが「キャンセル」に変わったタイムスタンプです。
イベントタイプ
explicit
|
|||
|
変更の再オープン
|
完了または解決済みの変更が、再びオープン状態になったときに発生します。通常、実施後に問題が見つかった場合に起こります。クローズ状態からオープン状態へのステータス変更から推定します。 | ||
|
重要な理由
このアクティビティは、手戻りや変更の失敗を示す有力な指標です。発生頻度を追跡することは、変更の品質やテストの有効性を把握するうえで欠かせません。
入手先
チケットのアクティビティログで、ステータスが「クローズ」または「解決済み」から「オープン」または「進行中」に戻った履歴を検出して推定します。
記録
終端状態(例:「クローズ」)から非終端状態(例:「オープン」)へのステータス変更を検出します。
イベントタイプ
inferred
|
|||
|
変更の却下
|
承認者が変更要求を正式に却下し、先に進められなくなったことを示します。この操作は明示的に記録され、多くの場合、プロセスは手戻りのループに入ります。 | ||
|
重要な理由
このアクティビティは、手戻りの分析やプロセスが進まなかった理由の特定に欠かせません。却下が多い場合は、要求内容の品質やリスク評価に問題がある可能性があります。
入手先
承認者が「却下」ボタンをクリックすると、Freshserviceに明示的なイベントとして記録されます。イベントはチケットのアクティビティログに保存されます。
記録
承認タブまたはアクティビティログに記録された「却下」操作のタイムスタンプです。
イベントタイプ
explicit
|
|||
|
変更へのメモ追加
|
変更要求にコメントやメモが追加されたことを示し、連絡や文書化の状況を表します。Freshserviceでは、各チケットのアクティビティフィードにこれらのイベントが明示的に記録されます。 | ||
|
重要な理由
中核となるプロセス手順ではありませんが、メモを追跡すると、特に承認や計画の段階で遅延が生じた背景を把握できます。メモの頻度が高い場合は、要件が不明確である、または連絡に問題がある可能性があります。
入手先
変更要求チケットの「アクティビティ」または「監査」セクションに、タイムスタンプとメモを追加したユーザーとともに明示的に記録されます。
記録
チケットのアクティビティログに「メモ追加」イベントとして記録されます。
イベントタイプ
explicit
|
|||
|
実施の開始
|
変更の実際の導入または実行が始まったことを示します。変更要求のステータスが「進行中」などのアクティブな状態に更新されたときに推定します。 | ||
|
重要な理由
実施作業にかかった時間を追跡するための明確な起点になります。待機時間と実作業の時間を区別するのに役立ちます。
入手先
予定された開始時刻に、ステータスが「進行中」や「実施中」などに変わった履歴から推定します。
記録
ステータス項目が「進行中」に変わった履歴から推定します。
イベントタイプ
inferred
|
|||
|
実施後レビューの完了
|
変更の成否を評価し、得られた教訓を文書化する実施後レビュー(PIR)が完了したことを示します。実施後にレビューのメモが追加されたときや、ステータスが更新されたときに推定する場合があります。 | ||
|
重要な理由
正式なレビュー手順が実施されたことを確認できます。このアクティビティを分析すると、変更の有効性を把握し、継続的なプロセス改善に役立てられます。
入手先
実施日以降に変更フォームのPIR関連項目が入力された履歴、またはステータスが「レビュー完了」などに変わった履歴から推定します。
記録
PIRメモ項目への入力、または特定のステータス更新から推定します。
イベントタイプ
inferred
|
|||
|
承認依頼
|
変更要求が正式にレビューと承認に回された時点を示します。通常は、変更要求のステータスが「承認待ち」などに変わったとき、または承認者に割り当てられたときに推定します。 | ||
|
重要な理由
このアクティビティは承認段階の開始を示します。この時点から「変更承認」までの時間を測定すると、承認期間のボトルネックを特定するうえで役立ちます。
入手先
アクティビティログ、またはステータス項目が「承認待ち」に変わった履歴から推定します。イベント時刻には、ステータス変更のタイムスタンプを使用します。
記録
ステータス項目が「承認待ち」に変わった履歴から推定します。
イベントタイプ
inferred
|
|||
|
計画の完了
|
実施計画や切り戻し計画の作成を含む、変更に必要な計画がすべて完了したことを示します。通常、承認後のステータス変更から推定します。 | ||
|
重要な理由
計画段階から実施段階への移行を示します。計画段階にかかった時間を分析すると、実施前の作業を効率化できる箇所を特定できます。
入手先
「リリース待ち」など計画関連のステータスから、「スケジュール済み」など実施関連のステータスに変わった履歴から推定します。
記録
「計画中」または同様のステータスから別のステータスに変わった履歴から推定します。
イベントタイプ
inferred
|
|||
データ抽出ガイド
準備を始めましょう
この詳細なテンプレートを使ってデータを準備し、今日から変更管理の改善に取り組みましょう。見えにくかったインサイトを見つけ、リリースの効率を高めることができます。
変更の失敗を防ぐ:Freshserviceの管理を今すぐ改善
変更の成功率95%を達成し、Freshserviceでの中断や遅延をなくしましょう。
クレジットカードは不要です。数分で利用を開始できます。