ServiceNow Change management

The reason there are three rather than one is that a single process cannot serve both a firewall rule change and a database upgrade without being wrong for one of them. Too much oversight on routine work and people route around it. Too little on risky work and the process stops meaning anything.

Standard is pre approved. The approval happened once, when the change model was written and accepted, and each instance inherits it. This is the type most organisations underuse: a great deal of what goes through the full process every week is genuinely routine, low risk and repeated, and belongs here.

Normal is the full path. Assess, approve, schedule, implement, review. Everything that is neither routine nor an emergency.

Emergency exists because outages do not wait. The distinguishing feature is not that it skips governance but that the governance happens in a compressed form and, for some of it, afterwards. Emergency changes that are never reviewed after the fact are the clearest sign that a change process is theatre.

A useful sanity check on any change process is the ratio between the three. A healthy one has most volume in standard, a manageable number of normal changes that genuinely get discussed, and emergency as an exception that gets reviewed afterwards. Anything far from that shape is worth explaining.

This is the exercise that tells you whether a change process is working, and it needs no configuration access.

1. Pull last month's changes and count them by type. If almost everything is normal, standard is being underused and people are spending time on ceremony.
2. Count emergency changes. A high proportion means either the normal path is too slow to use, or emergency is being used to skip it. Both are worth knowing and they have opposite fixes.
3. Take ten normal changes and check how many were rejected at approval. If the answer is zero, approval is not a decision point.
4. Find the changes that caused incidents. Read what their risk assessment said beforehand.
5. Check how many changes have a completed post implementation review.
6. Check how many name the affected service, and whether that came from the CMDB or was typed by hand.

Steps three and four together are the honest measure. A process where nothing is ever rejected and changes still cause incidents is producing records rather than control.

Change requests (extending task) carry risk and impact, often scored by a risk assessment questionnaire or a risk-calculation rule. Higher risk routes to more approvals, culminating in the Change Advisory Board (CAB) for significant normal changes. Approvals are captured on the record, not in email, via the approval engine or a flow.

The most common failure here is a risk calculation nobody believes. Risk is usually derived from answers the requester gives, and requesters learn quickly which answers produce the least friction. A risk model that can be talked down is not measuring risk, it is measuring how much the requester wants to avoid the CAB.

Two things help. Derive what you can from data rather than from answers: the affected service's criticality, whether the change is in a freeze window, whether previous changes to this configuration item caused incidents. And check the model against outcomes periodically, which is step four of the exercise above.

On the CAB itself: its useful function is discussing the small number of changes that genuinely need several people in a room. A CAB that reads out forty low risk changes is a meeting people stop attending properly, and the ones that needed discussion get the same two minutes as the rest.

Conflict detection is only as good as what it is checking against, and that is the CMDB. It can tell you that two changes touch the same server because both name it. It can only tell you that two changes affect the same business service if the relationships exist. This is the most concrete argument for CMDB quality that exists, and it is worth using with a business audience, because it converts an abstract data project into a specific question: do you want to be told before two teams take down the same service on the same night.

Blackout and maintenance windows are the other half. Both are configuration that reflects business reality, and both go stale. A blackout window for a financial year end that moved, or a maintenance window nobody has reviewed since the service was hosted elsewhere, produces either false conflicts or none where there should be some.

The state that gets skipped is the last one. Closure should record whether the change did what it was meant to, whether it was backed out, and whether it caused anything. That record is what makes steps four and five of the exercise above possible, and without it a change process cannot learn from its own history.

Version note: ITIL 4 renamed this practice change enablement, and the platform's own terminology has followed in places while older labels persist elsewhere, so both names refer to the same thing. Change models, which package the process for a repeated kind of change, have also become the recommended way to express standard changes rather than maintaining a separate catalogue of templates.

Changes are the delivery vehicle for problem fixes and many incident resolutions; they reference the CIs they affect so impact is visible, and they increasingly integrate with DevOps pipelines for automated change creation.

The link that pays for itself fastest is the one to incidents. When an incident is raised, the changes made recently to the same service are the first thing worth looking at, and a process that records the affected service on both makes that a query rather than an investigation. A meaningful share of incidents are caused by a change, and the ones where nobody makes the connection are diagnosed the slow way.

• Routing everything through CAB, turning it into a rubber-stamp bottleneck.
• Not maintaining standard change templates, so low-risk work drags.
• Skipping CI linkage, losing conflict detection and impact.
• No post-implementation review, so failed changes teach nothing.

Two more worth adding. Treating approval count as rigour. Five approvers who each assume somebody else read it is weaker than one accountable person who did. And a process designed for the riskiest change and applied to all of them, which is how organisations end up with a change process their own engineers avoid, usually by classifying work as something else.

Configuring the three types takes a day, and designing a process that engineers use rather than avoid is the work the course covers.