Uncategorized

Why Automation programs Stall in the First Six Weeks

asranaofc@gmail.com
September 7, 2026 · 2 min read
Share

Most automation programmes do not fail because the technology is weak. They fail because nobody agreed on what the process actually was before it got automated. This post walks through where that goes wrong, and what to do instead.

Where teams lose the first six weeks

The usual sequence looks sensible on paper. Pick a process, map it, build it, ship it. In practice the map is drawn from what people say they do, not what the system logs show they do. The gap between those two is where the six weeks go.

  • Process owners describe the happy path and forget the exceptions
  • Exceptions turn out to be 30 to 40 percent of real volume
  • The build gets rewritten halfway through
Worth knowing

Pull three months of system logs before the first workshop. The conversation changes completely when everyone is looking at the same numbers.

What the numbers look like when it works

82%
Faster processing
Measured over six months
4 days
Time to first deployment
11x
Fewer manual touches per invoice

Those are from a single mid-size finance operation, so treat them as a shape rather than a promise. The pattern holds across sites, the magnitude does not.

Manual, RPA and agentic side by side

CapabilityManualRPAARIA
Handles structured input
Handles unstructured documents
Survives a UI change upstream
Explains its own decisions
Setup timeNone6 weeks4 days
Cost per 1,000 itemsHighLowLow

The row worth arguing about is the third one. RPA breaking on upstream UI changes is the single biggest driver of maintenance cost, and it rarely shows up in a business case.

See it running

Replace this URL with a real episode or demo video.

How a first deployment runs

01
Discover
Pull the logs, map the real flow including exceptions, agree the scope with ops.
02
Design
Build the target flow and decide what stays human.
03
Deploy
Ship to one site, watch it for two weeks, fix what surfaces.
04
Scale
Roll to remaining sites once the exception rate is stable.

The honest trade-offs

What works
  • Runs without a vendor dependency on any single tool
  • Audit trail comes out of the box, not as a later project
  • Exception handling is designed in rather than bolted on

We stopped arguing about the numbers and started fixing the process.

Priya N
Head of Operations

The three phases, in short

Discovery
Where the process actually breaks, backed by log data rather than interviews.
Design
The target flow, agreed with the people who run it daily.
Delivery
Live in one site first, then scaled once the exception rate settles.

Before and after, on one process

MetricBeforeAfter
Cycle time4 days6 hours
Touches per invoice112
Exception rate34%9%
Headcount on the process62

Q2 pilot across three sites.

Common questions

How long does a first deployment take?
Four to six weeks for a first process, then two to three weeks for each one after it.
Do we need clean data before we start?
Yes. Master data quality is the usual blocker, and it is better found in week one than week five.
What happens to the team doing the work today?
They move onto exceptions and process design. The work that stays human is the work that needed judgement anyway.
Can this run alongside our existing RPA?
Yes. Most sites run both for a period, with RPA on the stable structured flows.
See it on your own process

Thirty minutes, your data, no slides.

asranaofc@gmail.com
Share this article: LinkedIn Twitter
EXPLORE COE

Ready to put these ideas into practice?

See how Automation CoE transforms enterprise intelligence into measurable business outcomes.