Change Management Process Workflow

Change Management is the process of managing a change request through the lifecycle of a request. Change Management ensures that standardized methods and procedures are used to handle the changes.

The fast pace of change in technologies has led to the need for change in the IT service offerings. The changes that are not planned can lead to problems. Therefore, there is a need for tightly managed and controlled approach toward change in IT systems and services. 

Change Management aims to minimize any undesirable disruptions to an existing IT service due to change implementation. Change Management involves setting up a process for handling changes and ensure that:

• Change is classified using an appropriate change type; and processed through a workflow for that change type.
• Change is submitted through an appropriate change approval process; specific to the type of change.
• Change is implemented according to a defined process; with tasks to ensure that all aspects of the change are implemented.
• Change implementation is reviewed to ensure that overall business risk is minimized. Change implementation also ensures that the change is recorded in all related systems before closure.  

The Serviceaide Intelligent Service Management provides six predefined change management process workflows:   

The status of the default change management process workflows is:

• Default Normal Change Management Process Flow is Published.
• Default Standard Change Management Process Flow is Published.
• Default Emergency Change Management Process Flow is Published.
• Default Break Fix Change Management Process Flow is Published.
• Major Change Management Process Flow is Draft.
• DevOps Change Management Process Flow is Draft.

Default Normal Change Management Process Flow

The default normal change management process flow defines the basic process workflow of a request that is related to a normal change. The default process is applied when a request does not match the entry criteria of other change process workflows that are active.

The process of a default normal change management is shown in the following diagram:

The following steps explain how default normal change management process flow works:

1. When a ticket is raised, based on the matching conditions the entry criteria is verified to assign the request. By default, the request is assigned to Change Management group, when no  conditions are matched.
2. The Change Coordinator assesses and evaluates the request and submits the request for manager approval.
3. The manager performs one of the following actions on the request:
   • Approve - The request is assigned to the Change Advisory Board (CAB) for further assessment. 
   • Reject - The request is reassigned to the change coordinator for reevaluation or the request is closed.
4. The CAB assesses the request with one of the following actions:
   
   • Approve by all approvers -  The request is approved by all the CAB members.
   • Approve or reject by one approver - The request is approved by one of the CAB members.
   • Urgent approve by all approvers - The request is submitted for an urgent approval by the CAB.
     Note: The manager can withdraw the request from CAB approval and can close the request during approval phase.
5. When the CAB approves, the change gets implemented. If not, the CAB proposes an approval with modifications to the change request. 

Default Standard Change Management Process Flow

The default standard change management process flow defines the basic process workflow of a request that is related to a normal change. For example, requests such as applying a service pack, regular pack, and adding a server to the testing environment. The default process is applied when a request does not match the entry criteria of other change process workflows that are active.

The process of a default standard change management is shown in the following diagram:

The following steps explain how default standard change management process flow works:

1. When a change request is raised, based on the matching conditions the entry criteria is verified to assign the request. By default, the request is assigned to Change Management group, when no conditions are matched.
2. The Change Coordinator assesses and sends the request for approval from the Change Manager.
   Note: The Change Coordinator can withdraw the request from the approval of the manager to modify the request. After the modifications, the Change Coordinator resubmits the request for the manager approval.  
3. The Change Manager performs one of the following actions:
   • Approve - The request is implemented and closed as success.
   • Reject - The request is failed and closed with exceptions. 

Default Emergency Change Management Process Flow

The default emergency change management process flow defines the basic process workflow of a request that is related to an emergency change. For example, requests to fix the production downtime and network downtime. The default process is applied when a request does not match the entry criteria of other change process workflows that are active.

The process of a default emergency change management is shown in the following diagram:

The following steps explain how default emergency change management process flow works:

1. When a change request is raised, based on the matching conditions the entry criteria is verified to assign the request. By default, the request is assigned to Change Management group, when no conditions are matched.
2. The Change Coordinator performs one of the following actions:
   • Approve for Implementation: The Change Coordinator approves the request to implement.
   • Submit For ECAB Approval (All Approvers): The request is approved by all the ECAB members. 
   • Submit For ECAB Approval (Any One Approval or Rejection): The request is approved by one of the ECAB members.
3. The Change Manager or Emergency Change Advisory Board (ECAB) performs one of the following actions:
   • Approve - The request is implemented and closed as success.
   • Reject - The request is failed and closed with exceptions. 

Default Break Fix Change Management Process Flow

The default break fix change management process flow is applied when a request needs to fix a minor change. The default process is applied when a request does not match the entry criteria of other break fix change process workflows that are active.

The process of a default break fix change management is shown in the following diagram:

The following steps explain how default break fix change management process flow works:

1. When a change request is raised, based on the matching conditions the entry criteria is verified to assign the request. By default, the request is assigned to Change Management group, when no conditions are matched.
2. The Change Coordinator submits the request for Change Management review.
3. When the review comments are updated to the request, the Change Coordinator verifies the comments and performs one of the following actions:
   • Close the change request. 
   • Reopen the change request if the review comments are not satisfactory. 

Major Change Management Process Flow

The major change management process flow defines the basic process workflow of a request that is related to a major change. For example, a request to deploy an application. The default process is applied when a request does not match the entry criteria of other change process workflows that are active.

The process of a major change management is shown in the following diagram:

The following steps explain how major change management process flow works:

1. When a change request is raised, based on the matching conditions the entry criteria is verified to assign the request. By default, the request is assigned to Change Management group, when no conditions are matched.
2. The Change Manager assesses and evaluates the request and submits for review from IT support team.
3. The IT support team evaluates and submits the request for approval from Change Advisory Board (CAB). The CAB performs one of the following actions:
   • Approve - The CAB reviews the implementation plan and submits for deployment to deployment team. 
   • Reject - The request is reassigned to the change coordinator for reevaluation or close the change request.
     Note: The IT support team can withdraw the request from CAB approval and can reassign it the change manager. 
4. The deployment team performs one of the following actions on the request:
   
   • Approve -  The change is implemented and the request is closed. Optionally, if multiple teams are involved in the implementation process, a project is created. If the implementation fails, the request is reopened and the process is repeated from step 2 until a change implemented. 
   • Reject - The request is reopened and the process is repeated from step 2 until a change implemented.

DevOps Change Management Process Flow

The DevOps change management process flow defines the basic process workflow of a request that is related to a DevOps change. For example, a request to implement a change in the application for  the release. The default process is applied when a request does not match the entry criteria of other change process workflows that are active.

The process of a DevOps change management is shown in the following diagram:

The following steps explain how DevOps change management process flow works:

1. When a change request is raised, based on the matching conditions the entry criteria is verified to assign the request. By default, the request is assigned to Change Management group, when no conditions are matched.
2. The release coordination group assess and evaluate the request. A plan is created to implement the request and assigned to Change Advisory Board (CAB) for approval.
3. On approval by the CAB, the following steps are performed:
   1. Start Build Activity - SSH Connector: Initiates the build script to create the software package for the release.
   2. Check Build Status - SSH Connector Script: Verifies if the build script run successfully. If the build is failed, record the build and close the request with exceptions. 
   3. Start Test Activity - SSH Connector: Invokes the test scripts to verify if the software package works as designed. 
   4. Check Test Execution Status- SSH Connector: Verifies if the testing is successful. If the test fails, run the back-up plan or update as test failure and close the request with exceptions. 
   5. Start Implementation - Release Automation: Invokes the deployment script to implement the package.
   6. Retrieve Release Status from Release Automation: Gathers the release information from release automation application. 
      Note: If the implementation fails, run the backout plan and close the request with exceptions.
4. The request is implemented and validated for completeness. The change request is closed.