At first the process of managing Change records in ServiceNow can be daunting; however, it’s important to realize that no single step in the process is difficult. After performing a few Changes, the process becomes quite evident.
Creating the Change
A change to SEA’s production environment has a number of documentation requirements, most of which can be satisfied when the Change record is initially created. ServiceNow’s Change form is broken up into several areas, the most important of which are discussed below.
Part 1 – What is Changing and Who is Impacted
- Requested By – you, generally. But if you’re entering a change request for your manager, you could select him/her.
- Change Stakeholder – the application owner, generally. If a particular change is better represented by another business resource, he/she could be selected instead.
- Category – Applications Software, generally
- Configuration Item – the application or service being changed. Presently ServiceNow’s configuration database only contains our business applications. Eventually it will also contain our discrete servers and components thereof, allowing the contents of this field to be much more precise. For now, if you’re making a change to a web server, for example, set the CI field to the most important application on that server.
- Device/Asset – additional detail about the CI
- Production System – check!
- Priority – as appropriate
- Risk and Impact – these field are filled in later, as the result of the Risk Assessment step.
Part 2 – Who is Doing the Work, Change Type and Status
- Opened by – you
- Approval – the Change’s approval status. This is managed by the Change workflow. Emergency Changes must be approved by the Emergency CAB (E-CAB).
- Type – Standard, Emergency, or Normal.
- State – the Change’s processing status. This is also managed by the Change workflow. After being approved by the E-CAB, the Change’s status is controlled by the completion of the Change Tasks, which we will discuss later.
- Assignment unit – TAMUS
- Assignment group – team with overall responsibility for the Change. For a change to LeaveTraq, that would be the ESI Developers team.
- Assigned to – individual on the team with overall responsibility for the Change.
Part 3 – Describing the Change
- Reason – for an Emergency Change, this will generally be “Problem resolution”, but fill in as appropriate.
- Short description – quick overview of Change. Include the Incident Number and/or TFS Task Number, if available.
- Description – explanation of what is being changed.
- Parent – Incident or Problem Number, if applicable.
Part 4 – Schedule
- Scheduled dates – date/time Change is expected to hit production. For an Emergency Change, these will generally be the same value.
- Important: Formatting is very particular – YYYY-MM-DD HH:II:SS; e.g., 2015-09-30 17:30:00.
Part 5 – Planning
All production changes, Emergency and otherwise, should be planned. ServiceNow requires that plan to be written down:
- Change plan – how will the Change be deployed? N2O event, TFS build, SQL script, manual action?
- Backout plan – in the event of a problem, how will the Change be undone?
- Test plan – post-deployment of the Change, how will it be verified?
- Implementation plan – exactly what will be executed against the production environment? SQL script names, N2O event number(s), etc.
- Communication plan – who will be notified about the change and when?
Creating the Change
At this point your Emergency Change can be saved, so click the “Save” button in the top-right corner of your browser.
The Change is saved in Draft status, so you can make changes to any and all of the data, as well as continue on to the Risk Assessment portion of the exercise.
It’s important to get your Change right before submitting it for approval, at which point it effectively becomes non-editable. So double-check that your information is complete and accurate at this point!
The risk associated with a change is determined by the Risk Assessment form and cannot be edited manually.
Filling Out the Risk Assessment
Save your Change, if you haven’t already, and click the “Fill Out Risk Assessment” button near the top-right of your screen. The Risk Assessment form will “pop up” on top of the Change record:
Fill out the form as accurately as possible.
Regarding the Potential Reach of Change question, most of our changes will be “High: This change will impact the entire campus” since there is no “… impact the entire system” choice.
Note that you may have to scroll downward in the pop-up window to see the Submit button.
Also note that failing to save your Change form before clicking the “Risk Assessment” button can result in lost changes, so be sure to save first.
Applying the Risk Assessment
After you submit the Risk Assessment form, you will be taken back to the Change form. The “Fill Out Risk Assessment” button will be replaced by one labeled “Execute Risk Calculation”.
Click it and your Change’s risk fields will be updated.
Once you’ve completed your Change and done a Risk Assessment, the Change can be submitted for approval. Click the “Request Approval” button at the top-right of your screen to do so.
Approval of Emergency Changes is done by the Emergency Change Authorization Board (E-CAB). As of this writing, E-CAB approval requires only one member of the board to act on the Change record, so obtaining approval is normally a simple matter.
The E-CAB members will receive an email regarding the Change with a link to approve it directly from Outlook, so they can approve the change very quickly – if they so choose. If not, E-CAB members can view the Change’s approval list and approve it from ServiceNow:
To approve a Change as an E-CAB member, click the “Requested” link next to your name to see the Approval form:
Simply click the Approve button (or choose Approved from the State dropdown) and the Change will be approved.
When an Emergency Change is approved, two Task records are created (as of this writing) – Implementation and Testing:
Recall that the Planning information entered on the Change record earlier described what is to be done to make the actual changes to the production environment.
Now, your Implementation Task is used to document the result of making these changes. Note that there are several fields on the Task form that are repeated from the Change form. This is because individual tasks may have different attributes than the Change as a whole.
- Configuration item – application or other asset being changed.
- Priority – as appropriate.
- Due date – as needed.
- State – set to Closed Complete when done with implementation.
- Assignment unit – TAMUS
- Assignment group – team implementation is assigned to; e.g., BPP Production for BPP and ESI Natural Changes.
- Assigned to – individual performing the implementation.
- Short description – leave unchanged.
- Description – describe work done as appropriate.
- Implementation code – generally “As Planned”, unless something went wrong.
After the Change has been implemented, we will generally perform some validation of the results, whether that’s logging into SSO and another application and trying out the changed features, running reports, or perhaps simply looking at data resulting from the change.
After applying the criteria used to determine that Implementation was successful, mark the Testing task as Closed Complete per the instructions above.
Poorly Placed Section About Calendar Dates
Loren intends to find a better home for this section:
One of the goals of a change management system is that multiple people can implement a change without having to clarify with each other outside of the CM system.
To get us closer to that goal we need to have consistent definitions, some of which include:
Change Request “Planned Start Date” The earliest of any service-affecting Change Task, which is any task starting with “Implementation” in the name.
Change Task “Due Date”
The Planning Task by definition cannot be service-affecting. It must be finished by the Due Date.
The Build Task by definition cannot be service-affecting. It must be finished by the Due Date.
The Implementation Task: This is the first service-affecting task, and cannot be started until the Due Date.
It’s time stamp should match the Planned Start Date of the parent Change Request.
If additional Implementation Tasks are needed, label them starting with “Implementation-“, such as “Implementation-SQL”.
The Test Task Due Date is actually the time where testing is expected to start, given that the above implementation tasks are complete.
All tasks that can be done concurrently should have the same Due Date.
Tasks with later Due Dates cannot be started until all tasks with earlier Due Dates are Closed Complete.
After working all of the Change Tasks to completion, the Change itself will be in a Complete state. Congratulations – you’ve just processed your first Change through ServiceNow!