Topic starter
04/07/2026 10:00 pm
TL;DR: Automation fails when teams layer it on undocumented, measurement-blind workflows, according to JumpCloud and cited research from S&P Global Market Intelligence, Ernst & Young, Gartner, and McKinsey. The practical lesson is that process standardisation, measurement, and control must come before workflow automation, or inefficiency and exceptions scale instead of shrinking.
Editorial analysis by NHI Mgmt Group, based on content published by JumpCloud: “Why Automating a Broken IT Process Just Makes It Fail Faster”.
By the numbers:
- Ernst & Young says 30 to 50% of RPA scripts break immediately after deployment when teams automate highly inconsistent processes.
- Gartner predicts that 60% of AI initiatives will be abandoned through 2026 because outputs are built on untrustworthy, unstructured data.
Key questions
Q: What breaks when teams automate an undocumented workflow?
A: Undocumented workflows break because automation removes the human judgement that was compensating for missing inputs, unclear handoffs, and inconsistent approvals.
Q: Why do automation projects fail when process quality is low?
A: Because automation magnifies whatever the underlying process already is.
Q: How do security teams know a workflow is ready for automation?
A: A workflow is ready when the team can define it clearly, measure its current performance, analyse its failure points, and show that exceptions are rare and understood.
Practitioner guidance
- Standardize the target workflow first Document the process end to end, including inputs, approvals, exceptions, and handoffs, before automating any step.
- Measure the current-state process Capture cycle time, manual step count, rework frequency, and exception volume so the team can prove whether the workflow is stable enough to automate.
- Use root cause analysis before scripting Identify whether delay or failure comes from data quality, ownership gaps, approval latency, or disconnected systems rather than from the task itself.
Bottom line: Automation does not repair a broken workflow. It reproduces the same defects at higher speed and with less human forgiveness.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
04/07/2026 10:06 pm
Automation is a process multiplier, not a process fix. If the workflow is inconsistent before automation, the inconsistency becomes cheaper to repeat and harder to unwind. That is why automation project failure so often looks like a governance failure rather than a tooling failure. The implication for practitioners is that the control point sits in process quality, not in the workflow engine.
A question worth separating out:
Q: What should identity teams do before automating lifecycle workflows?
A: They should standardise joiner, mover, and leaver steps, document ownership across HR, IT, and security, and remove ambiguity in approvals and triggers. That makes the workflow governable before it becomes programmable.
👉 Read our full editorial: Automation magnifies broken processes, not operational discipline