Your Change Management Data Template
Your Change Management Data Template
- Recommended attributes to collect for thorough analysis
- Key activities and milestones to track within your process
- Specific extraction guidance for relevant source systems
Change Management Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity
ActivityName
|
The name of the specific event or task performed within the change management process. | ||
|
Description
This attribute represents a single step or status change in the lifecycle of a change request, such as 'Change Request Submitted' or 'Change Request Approved'. These activities are the building blocks of the process map. Analyzing the sequence and duration of these activities helps identify the process flow, discover deviations from the standard procedure, and pinpoint bottlenecks. The activity names are typically derived from status transitions recorded in the system's audit logs.
Why it matters
It defines the steps of the process, allowing for the visualization and analysis of the process flow, which is the core of process mining.
Where to get
Derived from status transitions in the 'CHG:ChangeRequest_AuditLog' form or by tracking changes to the 'Status' field on the 'CHG:Infrastructure Change' form.
Examples
Change Request SubmittedRisk Assessment PerformedChange Request ApprovedChange Implemented
|
|||
|
Change Request ID
ChangeRequestID
|
The unique system-generated identifier for a change request, serving as the primary case identifier. | ||
|
Description
The Change Request ID is the unique key that identifies each change initiative throughout its lifecycle. It groups all related activities, approvals, and tasks, forming the basis of a single case in process mining. Analyzing processes by this ID allows for an end-to-end view of how changes are managed, from initial request to final closure. This is essential for tracking cycle times, identifying bottlenecks, and understanding process variations for individual changes.
Why it matters
This is the fundamental attribute that connects all related events into a single process instance, making end-to-end analysis of the change management process possible.
Where to get
Found in the 'Infrastructure Change ID' field (Field ID 1000000182) on the 'CHG:Infrastructure Change' form.
Examples
CRQ0000001234567CRQ0000001234568CRQ0000001234569
|
|||
|
Start Time
EventStartTime
|
The timestamp indicating when a specific activity or event began. | ||
|
Description
This attribute records the precise date and time that an activity occurred. For example, it would capture when a change was submitted, approved, or closed. This timestamp is crucial for analyzing the process timeline. It is used to calculate cycle times between activities, measure waiting times, identify performance trends over time, and determine the sequence of events. Accurate timestamps are the foundation for any time-based process analysis.
Why it matters
It provides the temporal dimension necessary for calculating durations, analyzing performance, and understanding the sequence of events in the process.
Where to get
Sourced from the 'Audit Date' field in the 'CHG:ChangeRequest_AuditLog' form or the 'Last Modified Date' associated with specific status changes.
Examples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
Last Data Update
LastDataUpdate
|
The timestamp indicating when the data for this record was last refreshed from the source system. | ||
|
Description
This attribute shows the date and time the data was last extracted from BMC Helix ITSM. It is not the time of the event itself but rather the time of the data pull. This information is vital for understanding the freshness of the data being analyzed and for managing data refresh cycles. In dashboards and reports, this timestamp informs users how current the analysis is, which is particularly important for monitoring ongoing processes.
Why it matters
It indicates the recency of the data, which is critical for ensuring that analyses and dashboards reflect the most current state of the process.
Where to get
This is a metadata field typically generated and populated by the ETL tool or data pipeline at the moment of data extraction.
Examples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
Source System
SourceSystem
|
The name of the system from which the data was extracted. | ||
|
Description
This attribute identifies the origin of the process data, which is 'BMC Helix ITSM' in this context. It helps in data governance and traceability, especially in environments where data from multiple systems might be combined for a broader analysis. For example, if change data is later merged with data from a financial or project management system, this field ensures clear differentiation of data sources.
Why it matters
It provides crucial context for data origin, ensuring traceability and proper interpretation of the data, especially in multi-system analysis scenarios.
Where to get
This is typically a static value added during the data extraction, transformation, and loading (ETL) process to label the dataset's origin.
Examples
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
|
|||
|
Approver Group
ApproverGroup
|
The team or group responsible for approving a change request at a specific stage. | ||
|
Description
This attribute identifies the group assigned to review and authorize a change. Since a change can have multiple approval stages, this may represent different groups throughout the lifecycle, such as a technical approval team and a business approval board. This is a vital attribute for the 'Change Approval Bottlenecks' dashboard, as it allows for the segmentation of approval times by the responsible group. This helps pinpoint specific teams that may be overloaded or inefficient, causing delays in the process.
Why it matters
It enables the identification of bottlenecks in the approval process by allowing analysis of approval durations per responsible team.
Where to get
Sourced from the 'AP:Signature' form, which manages approvals and is linked to the change request. The approver's group would be part of this record.
Examples
Change Advisory BoardIT SecurityNetwork EngineeringApplication Development
|
|||
|
Change Type
ChangeType
|
The classification of the change, such as Standard, Normal, or Emergency. | ||
|
Description
This attribute categorizes the change request based on its nature and the process it must follow. Common types include Standard (pre-approved, low-risk), Normal (requires full assessment and approval), and Emergency (requires expedited handling due to an urgent issue). Analyzing by Change Type is critical for understanding process variations. For example, the 'Emergency Change Volume & Impact' dashboard relies on this field to track urgent changes and their effect on service stability. It also helps in evaluating if different change types follow their prescribed paths.
Why it matters
It allows for segmentation of the process to analyze and compare different change workflows, which is key for compliance and performance analysis.
Where to get
Found in the 'Change Type' field on the 'CHG:Infrastructure Change' form.
Examples
StandardNormalEmergencyNo Impact
|
|||
|
Implementation Team
ImplementationTeam
|
The team responsible for carrying out the implementation of the change. | ||
|
Description
This attribute identifies the technical or operational group assigned to perform the work required by the change request. This is often the 'Assigned Group' during the implementation phases of the change lifecycle. This information is critical for the 'Resource Bottlenecks in Change Process' dashboard. By analyzing activity durations and volumes per implementation team, managers can identify load imbalances, skill gaps, or other resource-related constraints that delay change deployment.
Why it matters
It helps identify resource-related bottlenecks in the implementation phase by allowing performance analysis per responsible team.
Where to get
Found in the 'ASGRP' (Assigned Group) field on the 'CHG:Infrastructure Change' form.
Examples
Server OperationsDatabase AdministratorsSAP Basis TeamCloud Infrastructure
|
|||
|
Priority
Priority
|
The priority level assigned to the change request, indicating its business importance. | ||
|
Description
Priority is typically determined by combining Impact and Urgency, and it dictates the order and speed of handling for a change request. A higher priority change usually requires faster processing and may have stricter service level agreements (SLAs). This attribute is used in the 'Change SLA Performance' dashboard to segment and analyze performance for different priority levels. It helps answer questions like 'Are we meeting our SLAs for high-priority changes?' and guides resource allocation decisions.
Why it matters
It allows for performance analysis segmented by business importance, ensuring that the most critical changes are processed efficiently and meet their targets.
Where to get
Found in the 'Priority' field on the 'CHG:Infrastructure Change' form.
Examples
CriticalHighMediumLow
|
|||
|
Risk Level
RiskLevel
|
An assessment of the potential risk associated with implementing the change. | ||
|
Description
The Risk Level is a qualitative or quantitative assessment of the potential for negative consequences if the change is implemented. It is a key input for the approval process, where higher-risk changes undergo more scrutiny. This attribute is central to the 'Change Risk Profile Analysis' dashboard, which helps stakeholders understand the overall risk exposure from the portfolio of changes. It is also used to identify rework loops where initial risk assessments are inadequate, leading to later re-evaluation.
Why it matters
It provides a critical dimension for analyzing process compliance and efficiency, helping to ensure that higher-risk changes receive appropriate scrutiny.
Where to get
Found in the 'Risk Level' field on the 'CHG:Infrastructure Change' form.
Examples
1 - Critical2 - High3 - Medium4 - Low5 - Planning
|
|||
|
Status
Status
|
The current state or phase of the change request in its lifecycle. | ||
|
Description
The Status field indicates the exact stage of a change request at a given point in time, such as 'Draft', 'Request For Authorization', or 'Completed'. While activities are derived from transitions between these statuses, the status itself is useful for analyzing the current workload. This attribute is essential for the 'Change Throughput & Current Status' dashboard, providing a snapshot of how many changes are in each stage of the pipeline. It helps managers understand work in progress and resource allocation.
Why it matters
It provides a real-time view of the change pipeline, enabling analysis of work-in-progress and the current state of all change requests.
Where to get
Found in the 'Status' field on the 'CHG:Infrastructure Change' form.
Examples
DraftRequest For AuthorizationScheduledImplementation In ProgressCompleted
|
|||
|
Affected Service
AffectedService
|
The business or technical service impacted by the change. | ||
|
Description
This attribute links the change request to a specific service defined in the Configuration Management Database (CMDB). This could be a user-facing business service like 'Email Services' or a back-end technical service like 'Authentication Service'. It is used in the 'Emergency Change Volume & Impact' dashboard to correlate changes with the services they affect. This helps in understanding the stability of different services and identifying those that require frequent emergency interventions.
Why it matters
It provides crucial business context, linking technical changes to their impact on business services and enabling service-centric process analysis.
Where to get
Sourced from the 'ServiceCI' field or related Configuration Item (CI) relationships on the 'CHG:Infrastructure Change' form.
Examples
Corporate EmailSAP ERPCustomer Relationship ManagementOnline Banking Portal
|
|||
|
Change Submitter
ChangeSubmitter
|
The individual who created and submitted the change request. | ||
|
Description
This attribute identifies the person who initiated the change request. This is typically captured as the 'Submitter' or 'Reported By' user in the system. While not always a primary analysis dimension, it can be useful for understanding the sources of change requests. For instance, analyzing whether most changes originate from specific departments or roles can provide insights into business needs and planning processes.
Why it matters
It helps identify the originators of change requests, which can be used to analyze demand patterns and user behavior within the process.
Where to get
Found in the 'Submitter' field on the 'CHG:Infrastructure Change' form.
Examples
Allen AllbrookMary MannBob Baxter
|
|||
|
Close Code
CloseCode
|
A code indicating the final outcome of the change when it was closed. | ||
|
Description
The Close Code provides a standardized reason for the closure of a change request, such as 'Successful', 'Successful with Issues', 'Backed Out', or 'Cancelled'. This attribute offers a more granular view of the change outcome than the final status alone. Analyzing Close Codes can help in assessing the quality and success rate of implemented changes. For example, a high number of 'Backed Out' changes may indicate problems in planning or testing, providing a valuable metric for process improvement.
Why it matters
It provides a clear, structured outcome for each change, enabling analysis of success rates and reasons for failure or cancellation.
Where to get
Found in the 'Status Reason' or a similar closure code field on the 'CHG:Infrastructure Change' form, which becomes active in the final stages.
Examples
SuccessfulSuccessful with IssuesBacked OutCancelled
|
|||
|
End Time
EventEndTime
|
The timestamp indicating when a specific activity or event concluded. | ||
|
Description
The End Time marks the completion of an activity. In process mining, this is often calculated as the start time of the subsequent activity in the case, providing a clear duration for the preceding step. For the very last activity in a case, it might be the same as its start time or a specific closure timestamp. This attribute is essential for calculating the
Why it matters
It enables the precise calculation of activity durations, which is fundamental for identifying bottlenecks and measuring process performance.
Where to get
This is a calculated attribute, typically derived during data transformation by taking the start time of the next event in the sequence for a given case.
Examples
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
|
|||
|
Impact
Impact
|
The assessed impact of the change on business services and IT infrastructure. | ||
|
Description
Impact measures the potential effect of a change on business operations, services, and users. It is a critical factor, along with Urgency, in determining the Priority of the change request. In analysis, Impact is used in the 'Change Risk Profile Analysis' dashboard to provide a comprehensive view of the change portfolio's potential business consequences. Understanding the distribution of high-impact changes can inform risk management strategies and resource planning.
Why it matters
It helps quantify the potential business consequences of changes, allowing for risk analysis and prioritization based on how severely services could be affected.
Where to get
Found in the 'Impact' field on the 'CHG:Infrastructure Change' form.
Examples
1-Extensive/Widespread2-Significant/Large3-Moderate/Limited4-Minor/Localized
|
|||
|
Is Emergency Change
IsEmergencyChange
|
A boolean flag that is true if the change is of type 'Emergency'. | ||
|
Description
This derived flag simplifies analysis by providing a clear binary indicator for emergency changes. It is based on the value of the 'ChangeType' attribute. This attribute is primarily used to support the 'Emergency Change Volume & Impact' dashboard and the 'Emergency Change Percentage' KPI. It allows for easy filtering and aggregation of data related to emergency changes, making it straightforward to track their frequency and trends over time without complex filtering logic in the analysis tool.
Why it matters
It simplifies the analysis of emergency changes, making it easier to filter, dashboard, and calculate KPIs related to this critical change type.
Where to get
This is a derived attribute created during data transformation. The logic is: IF 'ChangeType' = 'Emergency' THEN true ELSE false.
Examples
truefalse
|
|||
|
Is Rework
IsRework
|
A flag indicating if an activity represents a rework loop or a step backward in the process. | ||
|
Description
This boolean attribute is set to true when a change request moves back to a previous stage in its lifecycle, for example, from 'Scheduled' back to 'Risk Assessment'. Such backward movements represent rework, which is often a source of inefficiency. This flag is used to calculate the 'Change Rework Rate' KPI and supports the 'Change Rework & Assessment Efficiency' dashboard. It helps to quantify the frequency of rework and identify the specific process steps where it most often occurs, pointing to areas for improvement in initial planning and assessment.
Why it matters
It directly identifies process inefficiencies by flagging activities that are part of a rework loop, enabling targeted improvement efforts.
Where to get
This is a calculated attribute, derived by analyzing the sequence of activities for a case. Logic is applied during data transformation to detect backward movements in the process flow.
Examples
truefalse
|
|||
|
Processing Time
ProcessingTime
|
The duration of time spent on an activity, calculated from its start and end times. | ||
|
Description
Processing Time, also known as cycle time, measures the time elapsed from the beginning to the end of an activity. It is calculated as the difference between the 'EventEndTime' and 'EventStartTime' for each step in the process. This is a fundamental metric in process mining, used to identify bottlenecks, measure efficiency, and set performance baselines. Dashboards like 'Change Approval Bottlenecks' and KPIs like 'Average Change Approval Time' are directly based on aggregating this calculated value.
Why it matters
It is a core performance metric used to quantify the duration of process steps, making it essential for bottleneck analysis and efficiency improvements.
Where to get
This is a calculated metric, derived during data transformation by subtracting the 'EventStartTime' from the 'EventEndTime'.
Examples
864000001728000003600000
|
|||
|
Related Incident ID
RelatedIncidentID
|
The identifier of any incident that was caused by this change. | ||
|
Description
This attribute links a change request to any subsequent incidents it may have caused. This relationship is crucial for understanding the downstream impact of changes on service stability. This is the primary attribute needed to calculate the 'Change-Induced Incident Rate' KPI. By tracking these links, an organization can measure the quality of its change process and identify types of changes, teams, or services that are associated with a higher rate of post-implementation issues.
Why it matters
It directly measures the negative impact of changes, providing a critical KPI for assessing change quality and risk management effectiveness.
Where to get
This relationship is typically established on the Incident form ('HPD:Help Desk'), where an incident can be linked back to a change request as its cause.
Examples
INC000000987654INC000000987655INC000000987656
|
|||
|
SLA State
SLAState
|
The calculated status of the change request relative to its SLA target. | ||
|
Description
This attribute indicates whether a completed change request met, was at risk of breaching, or breached its Service Level Agreement (SLA). It is calculated by comparing the actual completion timestamp with the 'SLATargetDate'. This is the primary metric for the 'Change SLA Performance' dashboard. It provides a clear, concise measure of performance against service commitments and allows for slicing and dicing the data by priority, change type, or team to identify areas with poor SLA adherence.
Why it matters
It provides a direct measure of performance against commitments, making it a key indicator of process efficiency and service quality.
Where to get
This is a calculated attribute derived during data transformation by comparing the final activity's timestamp with the 'SLATargetDate'.
Examples
On TimeAt RiskBreached
|
|||
|
SLA Target Date
SLATargetDate
|
The target date and time by which the change request should be completed. | ||
|
Description
The Service Level Agreement (SLA) Target Date is the deadline for completing the change request, determined by its priority and type. This is the benchmark against which the actual completion time is measured. This attribute is fundamental for the 'Change SLA Performance' dashboard. By comparing the actual closure time with this target, we can determine if the change met its SLA. Analyzing SLA performance helps in evaluating overall process efficiency and adherence to service level commitments.
Why it matters
It provides the benchmark for measuring performance, allowing for the calculation of SLA compliance rates and the identification of at-risk changes.
Where to get
This information is typically stored in related SLA management forms and linked to the change request, often visible on the change form itself.
Examples
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
|
|||
|
Urgency
Urgency
|
The urgency of the change, reflecting the time sensitivity of its implementation. | ||
|
Description
Urgency indicates how quickly the change needs to be implemented. It is a key component, along with Impact, used to calculate the overall Priority of the change request. Urgency is a key attribute for the 'Change Risk Profile Analysis' dashboard, providing insight into the time pressures on the change management process. Analyzing trends in urgency can help identify underlying issues that may be driving a high number of time-sensitive requests.
Why it matters
It reflects the time-critical nature of changes, helping to analyze whether the process effectively handles requests with different levels of time sensitivity.
Where to get
Found in the 'Urgency' field on the 'CHG:Infrastructure Change' form.
Examples
1-Critical2-High3-Medium4-Low
|
|||
Change Management Activities
| Activity | Description | ||
|---|---|---|---|
|
Change Closed
|
This is the final activity, marking the formal closure of the change request in the system. This event is captured when the status of the change request is set to 'Closed'. | ||
|
Why it matters
This activity marks the successful end of the change lifecycle. It is essential for measuring the end-to-end process duration and overall throughput.
Where to get
Inferred from the status change history in the CHG:Change form when the status moves to 'Closed'.
Capture
Identify timestamp when the 'Status' field on CHG:Change is updated to 'Closed'.
Event type
inferred
|
|||
|
Change Implemented
|
This activity represents the successful completion of the change implementation work. It is typically recorded when the status is updated to 'Completed' with a reason indicating success. | ||
|
Why it matters
This is a major milestone that marks the end of the deployment phase. It is essential for calculating the Change Implementation Cycle Time and analyzing change-induced incidents.
Where to get
Inferred from the CHG:Change form when the 'Status' is set to 'Completed' and the 'Status Reason' is 'Successful'.
Capture
Identify timestamp when the 'Status' field on CHG:Change is updated to 'Completed'.
Event type
inferred
|
|||
|
Change Request Approved
|
This is a key milestone where the change request receives formal approval to proceed. The event is inferred from a status change, typically to 'Scheduled' or 'Planning In Progress' after the final authorization. | ||
|
Why it matters
This marks the end of the approval phase and is critical for measuring approval bottlenecks and the Average Change Approval Time KPI. It's a key decision point in the process.
Where to get
Inferred from the status change history in the CHG:Change form, specifically when the request moves out of an approval status like 'Request For Authorization'.
Capture
Identify timestamp when the 'Status' field on CHG:Change transitions past the final approval phase, e.g., to 'Scheduled'.
Event type
inferred
|
|||
|
Change Request Created
|
This activity marks the initial creation of a change request record in the system. The event is captured from the creation timestamp of the change request entry in the CHG:Change form. | ||
|
Why it matters
This is the starting point for every change request, essential for measuring the total lifecycle duration and analyzing the volume of incoming changes.
Where to get
This event is captured from the 'Submit Date' or the record creation timestamp in the CHG:Change form's audit log (e.g., HPD:Help Desk Audit Log).
Capture
Use the record creation timestamp from the CHG:Change form.
Event type
explicit
|
|||
|
Change Scheduled
|
This activity marks the point where the approved change is officially scheduled for implementation. This event is captured from the status change to 'Scheduled' in the system. | ||
|
Why it matters
This is a critical milestone that signals readiness for implementation. It is the starting point for measuring the Change Implementation Cycle Time and Average Implementation Wait Time KPIs.
Where to get
Inferred from the status change history in the CHG:Change form when the status moves to 'Scheduled'.
Capture
Identify timestamp when the 'Status' field on CHG:Change is updated to 'Scheduled'.
Event type
inferred
|
|||
|
Risk Assessment Performed
|
This activity signifies the completion of the risk assessment for the proposed change. It is often captured when the change request status is updated or a specific risk assessment task is closed. | ||
|
Why it matters
Tracking this activity is vital for ensuring compliance with change management policies. It helps identify delays in the assessment phase and analyze the Change Rework Rate if the process reverts to this step.
Where to get
Inferred from a status change on the CHG:Change form (e.g., moving to 'Request For Change') or by the completion of a related task in the CHG:Task form.
Capture
Identify the timestamp when a linked 'Risk Assessment' task in CHG:Task is marked 'Closed' or 'Completed'.
Event type
inferred
|
|||
|
Testing Performed
|
Signifies that post-implementation testing or validation has been completed. This is often captured through the closure of a dedicated testing task associated with the change request. | ||
|
Why it matters
Tracking this activity is key to measuring the Average Testing Cycle Time and ensuring quality. It helps identify bottlenecks in the validation process before final verification.
Where to get
Inferred from the completion of a testing task record in the CHG:Task form linked to the parent change request.
Capture
Identify timestamp when a linked 'Testing' or 'Validation' task in CHG:Task is marked 'Closed' or 'Completed'.
Event type
inferred
|
|||
|
Change Cancelled
|
Represents the cancellation of a change request before its implementation or completion. This is captured when the change request status is updated to 'Cancelled'. | ||
|
Why it matters
Tracking cancellations provides insights into why changes are withdrawn. This can highlight issues like poor initial planning, changing priorities, or resource constraints.
Where to get
Inferred from the status change history in the CHG:Change form when the status moves to 'Cancelled'.
Capture
Identify timestamp when the 'Status' field on CHG:Change is updated to 'Cancelled'.
Event type
inferred
|
|||
|
Change Request Rejected
|
This activity signifies that the change request has been formally denied by an approver. It's captured by a status change to 'Rejected' and represents a terminal state. | ||
|
Why it matters
Tracking rejections helps identify reasons for denial, such as incomplete information or high risk. This analysis can improve the quality of future change submissions.
Where to get
Inferred from the status change history in the CHG:Change form, specifically the transition to a 'Rejected' status.
Capture
Identify timestamp when the 'Status' field on CHG:Change is updated to 'Rejected'.
Event type
inferred
|
|||
|
Change Request Submitted
|
Represents the formal submission of a change request for review and authorization. This is typically inferred when the status of the change request moves from 'Draft' to 'Request For Authorization'. | ||
|
Why it matters
This activity initiates the approval process. Tracking it is crucial for measuring the time requests spend waiting for initial review and for analyzing the Change Approval Time KPI.
Where to get
Inferred from the status change history of the change request in the CHG:Change form, specifically the transition to 'Request For Authorization'.
Capture
Identify timestamp when the 'Status' field on CHG:Change changes from 'Draft' to 'Request For Authorization'.
Event type
inferred
|
|||
|
Change Verified
|
This activity indicates that the change has been formally verified as successful by stakeholders after implementation and testing. It's often represented by a status change before final closure. | ||
|
Why it matters
Verification is the final quality gate before closing a change. It confirms that the change met its objectives and did not cause unintended negative impacts.
Where to get
Inferred from a status change on the CHG:Change form, such as moving from 'Completed' to a 'Verification' or 'Closed' status.
Capture
Identify timestamp when the 'Status' field on CHG:Change transitions to 'Closed' after implementation activities.
Event type
inferred
|
|||
|
Impact Analysis Conducted
|
Represents the completion of the impact analysis to determine the potential consequences of a change. This is typically inferred from a status update or the closure of an associated task. | ||
|
Why it matters
This activity is crucial for understanding planning efficiency and its effect on rework. Analyzing its duration and frequency helps improve the initial assessment phase.
Where to get
Inferred from the completion timestamp of an 'Impact Analysis' task in the CHG:Task form or a specific status transition in the CHG:Change form.
Capture
Identify the timestamp when a linked 'Impact Analysis' task in CHG:Task is marked 'Closed' or 'Completed'.
Event type
inferred
|
|||
|
Implementation Plan Developed
|
Indicates that the detailed plan for implementing the change has been created and documented. This is typically captured when a planning task associated with the change is completed. | ||
|
Why it matters
The completion of this activity is a prerequisite for scheduling and implementation. Analyzing its duration helps to identify delays in the planning stage before the change is executed.
Where to get
Inferred from the completion of a specific planning task record in the CHG:Task form linked to the parent change request.
Capture
Identify timestamp when a linked 'Implementation Planning' task in CHG:Task is marked 'Closed' or 'Completed'.
Event type
inferred
|
|||
|
Post-Implementation Review
|
Represents the completion of a formal review after the change has been implemented. This activity is typically captured from the closure of a post-implementation review (PIR) task. | ||
|
Why it matters
This activity is crucial for organizational learning and process improvement. Measuring the Post-Implementation Review Rate KPI helps ensure that lessons are learned from changes.
Where to get
Inferred from the completion of a 'Post-Implementation Review' task in the CHG:Task form linked to the parent change request.
Capture
Identify timestamp when a linked 'PIR' task in CHG:Task is marked 'Closed' or 'Completed'.
Event type
inferred
|
|||