More than 220 automations, each built from scratch. Here's what changed when the business agreed the parts before building any more machines.
A global logistics business came to us with a problem. They didn't have too little automation. They had too much of the wrong shape.
Where they were
Their in-house team of about 30 people had built and supported more than 220 automations across RPA, document reading and Microsoft Power Platform. Those automations reached into SAP, Oracle, BlueYonder, the CRM and partner systems.
The trouble was what that added up to. Every automation had been built from scratch. Each one had its own integration code, its own error handling and its own support burden. New automations took about 30 days to deliver on average. And when an upstream system changed, the same fix had to be made to dozens of bots, one at a time.
So support work was duplicated across the estate, and delivery was slow.
What we advised
We proposed a different way of building, and ran it as a consultancy-led engagement. The client kept ownership of its automations and its team.
The idea is simple. Most business processes are made of the same few parts. Log into a system. Read a document. Validate a record against a rule. Raise an exception to a person. Write a result back. Record what was done.
If you build each of those once, properly, as a governed component, then every new automation becomes an assembly job. You stop writing the login logic for the fortieth time. When the system changes, you fix one component and everything that uses it is fixed.
We started by reviewing the whole estate and shortlisting the 20 most used, most valuable and most reusable processes. We mapped where they touched the same systems. Then we worked with their team to define four module categories (inbound, processing, storage and outbound), a first catalogue of reusable components with naming conventions and templates, and a governance model for who owns each module and how versions change. Support tickets were mapped to modules instead of to individual bots.
What changed
New automations now take 60% to 70% less time to deliver than the old average of about 30 days.
Support maps to modules, so a fix is made once and applies to every automation that uses that module.
A Centre of Excellence is running, the 30-person team has been trained, and there's an agreed roadmap for agents built on the same components: self-healing modules, decision-support agents and autonomous orchestration.
There's a less visible benefit to building this way, and it's the one risk teams care about most. When every automation is assembled from the same governed components, logging can be built in once. Then every automation can produce the same evidence, in one format, in one place, readable by audit. Without that, proving what a bot did means finding the person who built it.
Why this matters more with agents
A traditional bot follows a script. If it's badly built, it breaks in a predictable way.
An agent makes choices. If every team builds agents their own way, you don't just get a maintenance problem. You get forty different answers to the question of what this thing is allowed to do and how we know what it did.
A modular framework answers that once. The agent can only act through components you've approved. Each component records what it did. The agent gets freedom in how it reasons and none in how it touches your systems.
That's the pattern I'd recommend to any large organisation about to scale from a handful of agents to dozens. Agree the parts before you build the machines.
The takeaway
If your automation estate feels harder to run every year, the answer is rarely another tool. Look at how much of what you've built is the same thing, built differently, forty times.
How many of your automations would survive a major system upgrade without someone working the weekend?
Sources
- Turning 220 siloed automations into a reusable framework, the full case study on ettgroup.ai