Change workflow
Change management is responsible for the life cycle of all changes. The aim is to respond to changing business requirements while maximizing value and reducing incidents, disruption, and rework. The process minimizes the impact of change-related incidents on service quality, and consequently, improves the day-to-day operations of the organization. This process includes activities that ensure the measurability of the impact of a change within the environment.
The change workflow is the end-to-end process from the change creation to the change closure.
Standard, Emergency, and Normal
Each of the Service Management change workflows reflects ITIL process recommendations. The building blocks of the workflow are:
Standard change
This is a pre-approved change, of low risk. It is relatively common, and follows a standard procedure or work instruction.
Emergency change
This is an expedited process, which implements changes to the production environment when an emergency caused by a service outage occurs. This process proactively prevents a serious service outage.
Normal change
This is a change that must follow the complete change management process. It proceeds through all steps of the change management process, and if successfully completed, is reviewed by a Change Advisory Board (CAB).
Metaphases and phases
This section describes the metaphases and subordinate phases in the life cycle of a change.
The change workflow relies on business rules. Rules repeat from one phase to another when the end user can make a change to a field affected by a business rule during that phase.
Metaphase: Classification
A Change Requestor logs a request for a change, including selecting a change model. The process type of whether it is a normal (the default), emergency, or standard change, is based on the model. A user with the appropriate privileges can set the change as an emergency. The Change Coordinator reviews the information filled in by the Change Requestor to ensure there are no blanks, and checks for duplicate change records.
| Phase | Transition |
Description |
|---|---|---|
| Log | Automatic |
A Change Requestor logs a request for a change. As soon as the change is logged it is automatically queued for evaluation by the Change Coordinator or Change Owner. Next phase: Evaluate |
| Evaluate | Manual |
The Change Coordinator or Change Owner checks the information provided— including the change model, performs an initial analysis, and selects a category for the change. If the decision is to move on with the change, the Change Coordinator or Change Owner transitions it manually to the Plan phase. If not, the change is canceled, and the Change Coordinator or Change Owner manually transitions the change to the Abandon phase. Next phase: Plan or Abandon |
Metaphase: Planning
The Change Owner plans the resources required, and reviews, revises, and updates the schedule for changes as necessary, including producing an implementation plan and remediation plan. The Change Owner also assesses the change by:
- Determining the risk and impact.
- Deciding whether it is necessary to test the change before deploying it.
In addition, the Change Owner assigns each task to a Change Task Assignee. The Change Approver reviews the change and, if not satisfied, can return the change to one of the earlier phases.
| Phase | Transition |
Description |
|---|---|---|
| Plan | Manual |
The Change Owner analyzes the change, plans the resources required, and reviews, revises, and updates the schedule as necessary. The Change Owner also evaluates the risk and impact, documents the change plan, and submits it for approval. If the decision is to move on with the change, the Change Owner transitions it manually to following phase depending on the change type:
If not, the change is canceled, and the Change Owner manually transitions the change to the Abandon phase. |
| Approve plan
(Normal change only) |
Automatic or Manual |
The Change Approver reviews the plan and the impact, risks, and benefits of the change request, as well as the consequences of not implementing the change. The Change Approver may:
In any of these cases, the change automatically transitions on to the Approve deployment or Build and test phase, or back to the Plan phase, depending on the information provided by the Change Approver. Alternatively, if the change is not approved, the Change Approver manually transitions the change to the Abandon phase. Next phase: Build and test, Approve deployment, back to Plan, or Abandon |
| Build and test
(Normal and Emergency changes only) |
Manual |
The Change Owner arranges for a deployment package to be built and tested, and tests the implementation of the change and the remediation plan, then manually transitions the change to the following phase, depending on the change type:
Alternatively, the Change Approver can cancel the change by manually transitioning it to the Abandon phase. |
| Approve deployment
(Normal change only) |
Automatic or Manual |
The Change Analyst reviews the testing of the change, and approves the proposed timing of the change. The change automatically transitions on to the Execute phase, or back to the Plan phase, depending on the information provided by the Change Analyst. Alternatively, the Change Analyst can cancel the change by manually transitioning it to the Abandon phase. Next phase: Execute, back to Plan, or Abandon |
| ECAB
(Emergency change only) |
Automatic |
The relevant analyst considers:
The change transitions automatically on to the Execute phase, or back to the Plan phase, depending on the information provided by the analyst. Next phase: Execute, or back to Plan |
Metaphase: Deployment
The change happens in this phase. The Change Owner coordinates and monitors the change implementation. If the change is not affected, the Change Owner implements the remediation plan.
| Phase | Transition |
Description |
|---|---|---|
| Execute | Manual |
The change is implemented, and the Change Owner manually transitions the change to the CMDB Update phase. If the execution fails, the Change Owner manually transitions the change to the Remediate phase. Alternatively, the Change Owner can cancel the change by manually transitioning it to the Abandon phase. Next phase: CMDB Update, Remediate, or Abandon |
| Remediate | Manual |
The remediation plan is implemented. Next phase: Review |
Metaphase: Validation
The Change Manager determines whether the change implementation was successful, and reviews the procedure taken for the purposes of process improvement.
| Phase | Transition |
Description |
|---|---|---|
| CMDB Update | Manual |
The relevant analyst updates the CMDB to reflect the implemented change, and sends the change for review. Next phase: Review |
| Review | Manual |
The relevant manager reviews the result of the change, compares the actual and proposed implementation, and decides whether to create a change model. The analyst also sets the completion code. The change is manually transitioned to the Close phase. Next phase: Close |
Metaphase: Done (End)
The Change Owner reviews the change implemented and closes it if the change has been successfully implemented.
Note An unsuccessful change and an abandoned change are also kept in this metaphase.
| Phase | Transition |
Description |
|---|---|---|
| Close | None |
The change is closed. |
| Abandon | None |
Service Management does not allow you to delete change records. A change that is not implemented is classified as Abandoned. It is inactive and not implemented. |
