This article covers the overview of change requests, benefits, and the life cycle of change requests. The detailed steps to create a change request manually are also explained.
A change is defined as the addition, modification, or removal of anything that could have an impact on an IT service. Change management is the process responsible for facilitating the implementation of changes.
The objectives of change management are to:
- Provide a systematic approach to control the lifecycle of all changes
- Facilitate beneficial changes to be made with minimum disruption to IT services
- Control changes to the configuration management database (CMDB)
Why does a change request mandatory in a project or product?
Information technology is evolving faster and better day by day to cater to the business requirements of the present and future world. Old infrastructure of a large IT organization needs to be replaced with the new and upcoming devices, and services. With the continuous evolution in the IT world, require a potential and effective approach to meet the demand of the product/project management. Requesting a change of server or laptop with the new ones requires a seamless process to submit a request through an effective and communicative application.
Enterprises have two main expectations from the IT world.
- The services should be stable, reliable, and predictable.
- The services should be able to change rapidly to meet the evolving business requirements.
An effective and properly implemented change request enables the organizations to take a full benefit out of it.
The successful implementation of change request does in the following ways.
- Evaluate the benefits and risks posed by the proposed changes and consider all impacts.
- Prioritize the change requests based on their value proposition and urgency so that limited resources will be allocated to meet the business need.
- Test all proposed changes before they deployed to production environment that ensures a restore plan if the any of the changes fail.
- Update the configuration management system to reflect the implemented changes.
Benefits of Change Requests
Change Management delivers the following benefits if implemented meticulously.
- manage the diverse cost of change
- reduce the time needed to implement change
- support staff and help them understand the change process
- plan and execute an effective communication strategy
- improve cooperation and collaboration in your business
- minimize resistance to change
- maintain the routine in the running of your business during change
- maintain or even increase productivity, morale and efficiency
- reduce stress and anxiety associated with change
- reduce disruptive aspects and risks associated with change
- respond to challenges more efficiently
- minimize the possibility of change failure
Types of Changes
Standard Changes: Pre-authorized, low-risk Changes that follow a well-known procedure.
Emergency Changes: Changes that must be implemented immediately, for example, to resolve a Major Incident.
Normal Changes: All other Changes that are not Standard Changes or Emergency Changes.
How changes are initiated
Directly in ServiceNow – IT support users can raise changes directly in the change application as required.
From an Incident – Incident managers, service desk agents, or other IT support staff can raise a change from an incident when they identify the fix required to resolve the incident.
From a Problem – Problem managers, service desk agents, or other IT support staff can raise a change from a problem when they identify the fix required to resolve the problem.
Through the Service catalog – Standard changes can be raised by selecting the appropriate template from the standard change catalog.
From a Request – Users outside of the IT department can make a request to IT that requires a change to deliver the request.
Automatically via Integrations – Changes can be automatically generated via external systems such as vendor system integrations.
DevOps – Changes are initiated through the Change API through toolsets commonly used within development organizations.
Change Request Life Cycle
States are designed to make it clear where in a process a record currently resides and to display progress. States should represent a unique phase in a process when a specific set of related activities are grouped together designed to achieve a particular outcome to move to the next phase of the process.
Our recommended change management process consists of the following state model.
- New
- Asses
- Authorize
- Scheduled
- Implement
- Review
- Closed
- Canceled
Normal Change Request Process
State: New
When a change request is created initially, it is in a state of New. This is effectively a draft of a change and can be updated as many times as necessary to fully populate all the content. A change in New is not considered live in the lifecycle and is not being viewed by anyone other than the requester who is raising it.
When you are ready to submit the change, click the Request Approval button.
Any fields that are mandatory to move the change through the process will be highlighted at this point and prevent the change from progressing until they are populated.
If change tasks are in use, these may replace the need for the Implementation plan, Risk and impact analysis, Backout plan, and Test plan fields. This information could be stored in one or more tasks instead. Any tasks that are required during the lifecycle of the change should be created in the New state either automatically or manually. This ensures that the full picture of work can be seen from the start and allows appropriate resource planning if multiple groups need to be involved since different tasks can be assigned to different groups.
Risk Analysis
If risk assessment questions are in use, you should be automatically prompted to answer these questions before submitting a change into the lifecycle. There are example questions provided out of the box.
Below are some that are commonly used:
- What is the complexity of this change?
- Has this type of change been done in the past successfully?
- How many users will be impacted?
- Does this impact a critical business service?
- How many resources/groups are involved in implementing the change?
- Is the change during a freeze period?
- How long does the change take to implement?
- How long does the change take to back out?
- How difficult is the change to back out?
- Will the change require an outage?
- Has this been implemented in a pre-prod environment?
- What would be the scale of impact if the change were not to go as planned?
Answers to these questions should be provided as multiple-choice options and should avoid subjectivity. For example, the possible answers to a question such as “What would be the scale of impact if the change were not to go as planned?” should not be “Large,” “Moderate,” and “Small” because these answers may be interpreted differently by different people. Instead, use specific, quantifiable choices such as “Less than 50 users,” “50–1000 users,” “1000–5000 users,” and “All users.”
Once all the mandatory information is populated, click the Request Approval button to submit a change into the lifecycle.
State: Assess
In the Assess state, the change receives the bulk of the approvals, and all technical approvals should occur.
Although not demonstrated out of the box, it is very common to require a change manager to review the change before it is sent to any other team for approval. This is the first approval that should be requested in the Assess state. The change manager is conducting a quality control check to confirm that the content is acceptable to proceed to other approvers without wasting their time unnecessarily. They will be looking to see that all the information needed to fully assess the change has been provided and that the requested change window appears to be suitable.
If the change manager rejects the change, it will go back to the New state and includes a comment explaining the reason for rejection.
If the change manager approves the change, the state remains in the Assess state and all technical approval groups will be automatically requested to approve in parallel. The technical approvers are chosen based on the CIs that have been included in the Affected CIs related list. In addition, the change manager can review the list of automatically added approval groups and manually add any additional approval groups at this point by using the New button on the Group Approvals related list. If additional groups do need to be added manually, this will need to be done while there are still approvals waiting to be actioned as the workflow will push the change through to the next state if there are no approvals outstanding. The change manager should review the automatically created list as soon as they have approved their own approval record and add any additional groups they feel are missing.
Approvals should always be requested as groups rather than as individual people so there is no single point of failure in the process. As soon as one individual from the group has approved, this means the group has approved and approval records for other members of the same group will no longer be required.
If any approval is rejected, the change will be set back to the New state. The person who is rejected will have to give a reason for rejection using the Comments field in the approval record.
If more information is required to decide, this should be handled outside of the tool, and the approval state set to More Information Required until a conversation has taken place.
Once all approvals have been received, the change will automatically move to the Authorize state.
State: Authorize
The Authorize state is primarily used to handle CAB approval. All high- and moderate-risk changes will automatically require a CAB group to approve. In addition, the Authorize state is where the scheduled dates for a change are fully confirmed.
CAB meetings can be held using the CAB Workbench functionality. Changes that are required to attend CAB will display a meeting record associated with the change in the CAB Agenda Items related list. Each meeting record will be shown if the change needs to be discussed at multiple CABs.
During the CAB meeting, the CAB board members will review the overall landscape of changes occurring during a particular period relevant to the frequency of that CAB. The CAB members will take a decision on whether to approve the change and this can be actioned within the CAB Workbench. The change can be rescheduled at this time if required since it is being reviewed in the context of other changes.
If the change is approved at the CAB meeting, it will automatically move to the Scheduled state. If the change is rejected at the CAB meeting, it will be returned to the New state and a reason is provided.
Low-risk changes are not required to be discussed at a CAB meeting. If a final check of the planned dates against the overall schedule is required, this can be achieved by requesting final approval from Change Management. Otherwise, these changes will simply skip the Authorize state completely.
Once all approvals have been received, the change will automatically move to the Scheduled state.
State: Scheduled
No activities take place in the Scheduled state. The change is fully approved for implementation and is only waiting for the planned start date to be met. Once this occurs, the change can be moved to the Implement state using the Implement button.
State: Implement
The change is now in the process of being implemented. When the change moves to the Implement state, the Actual start date field is automatically populated with the date and time. The work notes field or change tasks can be used to capture all activities taking place as part of the implementation. Once the implementation is finished, the implementer can move the change to the Review state using the Review button.
State: Review
Post-implementation review activities take place during the Review state. When the change moves to the Review state, the Actual end date field is automatically populated with the date and time.
The implementer will populate these mandatory fields:
- Close code
- Successful
- Successful with issues
- Unsuccessful
- Close notes
The actual dates can be overridden manually if they differ from the date automatically populated.
If the Close code is not set to Successful, additional review fields or tasks can be included at this point, particularly for Change Management, to conduct a more thorough review of why the change did not go according to plan and lessons to learn for the future.
Once the review is complete, the Close button is used to move the change to the Closed state.
State: Closed
No further activity can occur against the change. In situations when the change was originally considered successful but subsequently discovered to be otherwise, it is acceptable for a change manager to return the change to the Review state to conduct a PIR against it.
State: Canceled
A change can be canceled at any time. This means the change is no longer required and will not go ahead. The cancel change menu option can be used to move the change to Canceled. It is mandatory to enter a Work Note to explain the reason for cancelation. This is captured in the Activity Log.
Emergency Change Process
Emergency changes are those that cannot follow the normal lifecycle and lead times since they are in response to a service that has already failed or one that is about to fail if no action is taken.
The lifecycle of emergency changes follows the same lifecycle and activities as a normal change with the below exceptions.
Approval
This is only required from an ECAB group that can decide about the content and timing of the change on behalf of everyone who would normally approve. This single approval occurs in the Authorize state which means that the Assess state is not used at all.
Retroactive changes
If it is critical to apply a change immediately without any opportunity to raise it as a record and seek approval, a retroactive change under the emergency change process can be made. Emergency changes allow the planned start and end dates to be in the past. These changes can be immediately moved through to the Review state since they have already been implemented. It is recommended that these changes undergo a review by the change management team to ensure the process is not being used incorrectly and to understand why it was necessary to implement the change without approval first.
Creating a Change Request (CR) manually
Prerequisites
In order to send change requests from Service Now to the Resolution Intelligence®, you must first integrate and map the mandatory fields from both applications.
To ensure a successful synchronization of different change types (Normal, Emergency, and Standard) from ServiceNow to Resolution Intelligence, the following system properties should be enabled in ServiceNow.
| System Properties | Description |
|---|---|
| com.snc.change_management.change_model.hide | If Type Compatibility is enabled (com.snc.change_management.change_model.type_compatibility), this hides the Change Model feature from the form and Change Request Interceptor. |
| com.snc.change_management.change_model.manage_workflow | Enables Workflow management support for ChangeRequest API if the com.snc.change_management.state.model plugin is installed. This will call the 'deleteDefaultWorkflowContext' method to be called on specific state and type changes. |
| com.snc.change_management.change_model.type_compatibility |
Enables Change Type Compatibility for Change Models if the com.snc.change_management.state.model plugin is installed. When true allows changes to be created with both the type based workflow and Change Models. |
Required User Permissions
A Process Owner, Change Manager, Change Implementer or Change Requester, Change Approver, and CAB Manager can trigger change requests manually.
To create a CR in Service Now manually,
- In your ServiceNow instance, search for Change using the Filter Navigator, click Create New and select which type of change is required: Normal, Standard or Emergency.
- Select the Company that is provisioned from Service Now to NNC. Then, click Request Approval.
- Once the CR is created, search and select the Service and Configuration Item that is provisioned from Service Now to NNC. Then, select the Assignment Group, Assigned to and enter a short description.
- Set the Priority, Risk, and Impact of the change request.
- In the Planning tab, enter a Justification, Implementation plan, Risk and impact analysis, Backout plan, Test plan if applicable. This information will appear in the change event’s details in NNC.
- In the Schedule tab, select and save the Planned start date, Planned end date, Actual start date, and Actual end date. This information will schedule the maintenance window on the selected service in NNC. Click Submit.
- Click the change request Number that was just requested and then click Request Approval at the top right of the request. Once approved, navigate to the change request, and click Implement at the top right. At the Implementation state, below the form, click Change Task tab, and select and close the tasks otherwise, these tasks will get canceled.
- You should now be able to see the change event in NNC.
- Enter the NNC ticket id in the View ticket field to open the change request that is created recently.
- To verify the request, select Verify (CM)in the Status field and click Post reply.
- To close the request,
- Assign the respective Owner, under the Ticket Notes, fill in the Close notes and Reason for Close fields.
- In Service Now, under Closure information, enter Close code and Close notes and click Save.
- In NNC, status will be in the Verify stage only. You need to change the status to Close to close the change request completely.
Comments
0 comments
Please sign in to leave a comment.