Change Management Is Where 'Automation' Quietly Becomes 'A Human Does It'

Change is the one ITSM discipline where the stakes are unambiguous: a botched change is the leading cause of self-inflicted outages. So it is worth being precise about what "change automation" actually automates today. It automates the request form. It automates the risk classification. It automates the routing to the right approvers and the assembly of the CAB agenda. It automates the notifications, the state transitions, and the closure record.

What it does not automate — what it structurally cannot reach — is the implementation. The instant a schema migrates, a firewall rule flips, a load balancer is repointed, or a config is pushed, that action happens in another system, executed by an engineer or by a script the engineer kicks off. The change tool's role at that moment is to hold a field that reads "In Progress," and later, "Implemented." It is a system of record narrating an event it is not performing.

Let me concede the real ground before I contest any of it, because pretending these gains don't exist would insult the reader. A single unified service-management platform genuinely beats a drawer full of siloed tools — one data model spanning incidents, problems, changes and assets is a real architectural advantage. ITIL-aligned change discipline is not bureaucracy for its own sake; the separation of request, assessment, authorization and review has prevented countless bad changes. Automated risk scoring genuinely triages the trivial from the dangerous. A well-maintained CMDB genuinely sharpens impact analysis — what else touches this configuration item.

And the newer generation of tooling does more than paperwork: it drafts implementation plans, suggests rollback steps, detects collisions in the change calendar, and even fires last-mile automation for routine, pre-approved changes. These are real gains. None of them is the thing I am about to argue.

Here is the uncomfortable part. Every control in a mature change process is applied to the paperwork, and the paperwork is only a proxy for the change. The approval authorizes a described intention. Segregation of duties is enforced on who can move the ticket — not necessarily on who runs the command. The risk score assesses a plan, not the executed action. Between the state "Approved" and the state "Implemented" sits a human in a separate console doing the actual, irreversible work, and in that interval the platform is blind.

It cannot verify that the implemented change matches the approved one. It cannot guarantee the person executing is not the person who approved. It cannot ensure the rollback attached to the ticket is the rollback that will actually run. It records the outcome the engineer reports. The governance and the risk are separated in time and in system: the controls sit upstream, the danger sits downstream, and the boundary between them is precisely where outages are born.

The obvious rebuttal: modern platforms do execute. They ship workflow engines and fire last-mile automation — a script, a bot, an integration that reaches into the target system and makes the change. True, and worth taking seriously. But look at the architecture, not the demo.

A workflow that routes a change ticket, and a bot that drives another system's API or UI as a "last mile," is orchestration across systems the platform does not own. The tool sends an instruction over a boundary and waits for a return code. The governance still lives on one side of that boundary — the ticket — and the execution lives on the other — the target system. If the automation half-completes, the platform knows what the script told it, not what actually became true of the configuration item. The control point and the action point remain two different places joined by a hopeful integration. That holds no matter how sophisticated the roadmap becomes, because it is a property of being a system of record beside the systems of action — not a limitation of any one release.

Entroid starts from a different premise: the change is not a ticket that describes work happening elsewhere — it is the work, modeled and executed as a governed process on one fabric. A change in ES is a Deterministic Workflow composed from five primitives, where the controls are not fields on a form but gates compiled into the execution path itself:

• The approval gate — the workflow cannot reach the step that alters the target system until the gate before it is satisfied, because the gate and the step are consecutive links in one chain, in one runtime.
• Segregation of duties — "who may approve" and "who may execute" are constraints the runtime evaluates at the moment of action, not conventions enforced on ticket ownership.
• Change window & thresholds — the schedule and blast-radius limits are conditions on the execution path, so an out-of-window or over-threshold action simply cannot fire.
• Compensation / rollback — the reversal is composed into the same workflow as the forward action, not stapled on as a paragraph someone hopes is current.

When the workflow acts, it acts through Connectors — the only primitive permitted to touch external systems — so the migration, the firewall change, the config push is performed by the governed process, not narrated by it. And to be honest about the mechanism, so I don't commit the very over-claiming I'm critiquing: ES does not replace your estate or pretend integration vanishes. It runs over your existing systems through governed Connectors. The difference is not "no integration." The difference is that the approval and the implementation are the same governed action, in the same runtime, under the same audit — not two events on opposite sides of a boundary.

State this at the right altitude: it is a property of the design, not a benchmarked outcome. Because governance is enforced inline rather than as a review step, every action lands in an immutable, per-action audit as a byproduct of executing — not as a report an engineer types in afterward.

Two consequences matter most to a change and release audience.

Rollback stops being a paragraph and becomes part of the path. Because the change runs as a Deterministic Workflow, compensation is composed into the same workflow as the forward action. If a step fails or a post-change check trips, the fabric runs the compensating path as a governed action — recorded, gated, and reversible on the same terms as the change — rather than a 2 a.m. improvisation against a runbook nobody has validated this quarter.

And the configuration state stops drifting. In the record-beside-the-work model, the CMDB is reconciled — discovered, imported, periodically corrected, perpetually a little bit wrong between scans. In ES, the CMDB is the live Semantic Ontology the change executes against, so it updates as a byproduct of the executed change, not as a later reconciliation job. The map is not a snapshot of the territory taken last Tuesday; the change and the record of what is now true are the same event.