How to recognize the changes that look successful on paper but the task-level coordination issues hiding one layer below.
Change Managers report on volume, success rate, lead time, and CAB throughput. By those measures, most organizations look healthy with success rates over 95%, lead times trending down. But the riskiest changes, and the most inefficient ones, often hide inside that success rate. They were approved, they implemented, they closed clean. The risk lives in the path they took to get there, and one layer deeper, in how their child tasks were actually coordinated.
ServiceNow Process Mining reveals what a list view and a dashboard can’t: the actual sequence of states, approvals, handoffs, and reworks each Change Request went through, and how its Change Tasks were sequenced beneath it. Below are twelve recognizable execution patterns - six at the parent change level, six at the task-coordination level, and what each one is telling you about your Change Management process.
Part 1: Six Improvement Patterns in the Change Request Lifecycle
- The Phantom Emergency
What you see: 30% of your Emergency Changes show no implementation activity in the first 18 hours after creation; their approval cadence and total duration look like Normal changes. Shared signature: Emergency classification, but execution path matches the Normal change variant. Why it matters: Emergency is being used to bypass CAB, not for genuine urgency eroding governance trust and skewing every risk metric tied to change type. Surfaced by: variant analysis comparing Emergency and Normal execution paths.
- The Approval Shuffle
What you see: changes cycling through Assess → Approval → Rejected → Modified → Approval, sometimes three or four times before final approval, adding days to lead time. Shared signature: multiple back-flows to the Assess state, often involving different approvers each pass. Why it matters: either unclear approval policy, scope creep during assessment, or incorrect CAB routing. Either way, you’re paying a lead-time tax that doesn’t show up in a success-rate report. Surfaced by: back-flow detection on the process map combined with multi-hop reassignment analysis.
- The Standard Change Candidate
What you see: 50 Normal changes over six months following an identical 8-step path, with the same implementer group, the same CI class, the same risk score, and no failures. Shared signature: identical process variant repeating at high frequency, with stable attributes. Why it matters: these changes belong in the Standard Change catalog. Promoting them frees CAB capacity, shortens lead time, and reduces implementer overhead; a continuous improvement win you can quantify on day one. Surfaced by: variant analysis with filters, combined with attribute clustering.
- The Bypassed Step
What you see: 120 changes closed Successful last quarter where the Implementation state was never preceded by Technical Approval, and concentrated in two implementer groups. Shared signature: the same node missing from the conformance comparison, regardless of CI or change category. Why it matters: closed successfully isn’t the same as executed compliantly. This is the kind of governance gap that surfaces in an audit at exactly the wrong moment. Surfaced by: improvement opportunities page shows skipped step, combined with variant analysis
- The Silent Rollback
What you see: changes marked Successful, but their state history shows transitions back from Review to Implementation, often within the same day, with no formal failure or rollback record. Shared signature: Implementation→Review→Implementation back-flows that don’t appear in any failure report. Why it matters: rework happened but wasn’t logged. Your success rate is inflated, your lessons-learned base is empty, and your team has a normalized deviation hiding in plain sight. Surfaced by: back-flow detection on the process map.
- The Incident-Generating Path
What you see: changes that took a specific path i.e. Emergency, skipped peer review, implemented out of hours and correlate with a 4x higher rate of incidents on the same CI within 72 hours of closure. Shared signature: the same execution path, regardless of the change category or business service. Why it matters: this is the change pattern generating your incident workload. Eliminating the path, not the change, eliminates the downstream firefighting and the Problem tickets that follow. Surfaced by: cross-table correlation (multi-dimensional map) of change_request and incident on shared CI within a time window.
Part 2: Six Coordination Anomalies Between Change Requests and Change Tasks
The patterns above all live at the parent Change Request level. But Change Management actually executes at the task level and the relationship between a CHG and its child CTASKs is where most coordination failures hide. These six patterns surface when you mine the change_task table alongside change_request and analyze them as a connected parent-child process.
- The Parallel Task Stall
What you see: a change has six CTASKs designed to run in parallel during the implementation window, but the parent CHG closes Successful while two CTASKs remain in Open or Work in Progress. Shared signature: CHG closure timestamp precedes one or more CTASK closure timestamps. Why it matters: closure conformance is broken. The parent is being closed independently of child task completion, either through a workflow gap or manual override, and every metric tied to “CTASKs completed before CHG closure” is unreliable. Surfaced by: multi-dimensional map of CHG AND CTASK with breakdown analysis.
- The Sequencing Violation
What you see: CTASKs are ordered (1 = Backup, 2 = Deploy, 3 = Verify, 4 = Notify) but Process Mining shows Deploy starting before Backup completes in 18% of changes, concentrated in one implementer group. Shared signature: task start order systematically diverges from declared task order within the parent CHG. Why it matters: defined task sequencing isn’t being enforced. This is the change-management equivalent of skipping a pre-flight check, and it’s invisible in any report that looks only at CHG state. Surfaced by: process map of Change_Task table with Change_Request as a breakdown filter
- The Orphaned Task
What you see: CTASKs that move to Closed Skipped or Cancelled after the parent CHG closes, or CTASKs whose state activity continues for days after CHG closure with no corresponding parent activity. Shared signature: CTASK lifecycle continues past the parent CHG’s closure. Why it matters: tasks are being dispositioned outside the change lifecycle rolled into the next change informally, dropped without governance, or completed off-the-record. Implementer accountability is fragmenting. Surfaced by: multi-dimensional map of change_request and change_task, with transition/ step filter of change closing before task
- The Single-Implementer Bottleneck
What you see: across hundreds of changes, the same individual implementer appears in the assigned_to field of CTASKs on the critical path, and CTASKs assigned to them have a 3x longer average wait time before being picked up than CTASKs assigned to peers. Shared signature: consistent CTASK lead-time inflation concentrated on one assigned_to value. Why it matters: implementation capacity is concentrated in one person not visible in any change-level report, because the CHG record itself doesn’t know which CTASK was the bottleneck. This is a key-resource risk hiding in your execution layer. Surfaced by: root cause analysis RCA on the transition that takes long on the process map with 'assigned to' added as analysis attribute. Or 'assigned to' as breakdown filter.
- The Late-Created Task
What you see: CTASKs created after the parent CHG has already moved into Implementation state, sometimes after a peer review, sometimes after an initial failure. Frequency varies sharply by change category. Shared signature: CTASK sys_created_on postdates the parent’s transition into Implementation. Why it matters: either scope creep mid-execution, or initial planning gaps being patched in flight. Both indicate the Assess and Authorize states aren’t producing complete implementation plans, a leading indicator of the Silent Rollback pattern. Surfaced by: multi-dimensional map of CTASK and CHG drilling into parent CHG’s transition into Implementation state.
- The Ghost Dependency
What you see: CTASK A is marked dependent on CTASK B, but execution timestamps show A consistently completing before B is even started, yet both close Successful. Shared signature: declared task dependencies systematically violated by actual execution order. Why it matters: declared task dependencies are decorative, not enforced. Implementers are working in their preferred order and the dependency model is fiction, a real problem when the dependency actually does matter. Surfaced by: mining CTASKs and validating declared dependencies against actual execution order with breakdown of CTask Id.
Where to Start
Each pattern is a few clicks away. For Part 1, create a Process Mining project on the change_request table with State as Activity Definition. Apply Clustering, Variant Analysis, and Root Cause Analysis to surface the patterns most relevant to your environment. View the results of pattern detection already available in the baseline, on the 'improvement opportunities' panel.
For Part 2, run a project on change_task, and run a multi-dimensional mine with change_request to expose task-level coordination anomalies. For incident-related changes, add a multi-dimensional project on incident and change, with a configuration item breakdown within a defined window.
Reports tell you which changes succeeded. Process Mining tells you which of those successes were actually risky, and which of your risky changes never needed to happen at all.
