Automation · 6 min
Build a roadmap by inventorying repeated work, scoring each item on volume, stability and system access, then sequencing so the first project is small enough to finish and instructive enough to change the plan.
How it works
Sit with the people doing it and record each repeated task, its frequency, roughly how long it takes, which systems it touches and where it stalls. The gap between the documented process and the real one is usually where the opportunity is.
Volume, because frequency times time saved is the return. Stability, because a process still changing shape will invalidate the build. Access, because a task spanning systems with proper APIs is a fraction of the cost of one requiring screens to be driven.
The first project should be small enough to complete in weeks, valuable enough that people notice, and instructive enough to correct the assumptions in the rest of the plan. Starting with the largest opportunity means discovering wrong assumptions at maximum cost.
Mapping a process almost always reveals steps that exist for reasons that no longer apply: an approval for a risk that has gone, a re-entry that exists because two systems were never connected. Removing a step returns more than automating it and costs less.
Every automated process meets input it cannot handle. Whether it stops, routes to a person with full context, or proceeds with a flagged default is a business decision, and making it during design is far cheaper than discovering the behaviour in production.
Automations break when systems change, credentials rotate and vendors update. A roadmap without a named owner and a maintenance allowance produces a portfolio of automations that quietly stop working.
Usually not. The first should be small enough to finish quickly and instructive enough to correct the plan. Starting with the largest means discovering wrong assumptions at the highest cost.
Someone in operations who understands the processes and can approve changes to them, supported technically. Ownership placed purely in IT tends to produce automations that encode a process nobody wanted to keep.
Build a roadmap by inventorying repeated work, scoring each item on volume, stability and system access, then sequencing so the first project is small enough to finish and instructive enough to change the plan.
You have read what we think. If you want to know what it means for your case specifically, describe it and we will tell you which parts of how to build an automation roadmap actually apply — and which do not.
