ArticleAutomationOperations
Your people are the integration layer
In most mid-sized organisations, systems don't talk to each other; staff do it for them. Automation is less about technology than about seeing that work clearly.
- By
- DGS Technology
- Published
- Reading time
- 3 min read
Ask a finance manager how invoices get from the sales system into accounting, and you will often hear a pause, then: "Ana does that."
Ana is the integration layer. So is the warehouse supervisor who updates stock on the website every afternoon, and the analyst who spends the first three days of every month building the management report. None of this appears on an architecture diagram. All of it costs money, introduces errors, and depends on specific people being available.
Make the invisible work visible
The first step in any automation project is not choosing a tool. It is watching the work. We sit with the people who do it, follow a real transaction from start to finish, and time each step.
Two things almost always come out of this.
First, the cost is larger than anyone thought. Small tasks repeated daily add up. Five minutes per order across sixty orders a day is a full-time job.
Second, the work is concentrated. A few processes account for most of the hours, which means a few targeted automations can deliver most of the benefit.
Where the hours go
Staff hours per week spent moving data between systems, by process.
- Order entry from email31
- Invoice reconciliation22
- Stock level updates14
- Weekly management report9
- Delivery confirmations6
Show data table
| Category | Value (hrs/week) |
|---|---|
| Order entry from email | 31 |
| Invoice reconciliation | 22 |
| Stock level updates | 14 |
| Weekly management report | 9 |
| Delivery confirmations | 6 |
Rank before you build
Once the work is visible, rank each candidate automation on three things: hours saved, risk if it goes wrong, and cost to build and maintain. Order entry from email might save the most time but touch revenue directly, so it needs human approval built in. A weekly report might save less time but carry almost no risk, which makes it a good first project to build confidence.
The goal isn't to remove people from the process. It's to stop using them as cables.
Build for the day it breaks
Every integration will fail eventually. An API changes, a password expires, a supplier sends a file in a new format. The difference between an automation that helps and one that creates a new kind of chaos is what happens next.
We treat these as minimum requirements:
- Logging. Every run is recorded: what came in, what went out, what was skipped.
- Alerting. When something fails, a named person knows within minutes, not at month end.
- A runbook. A one-page guide to what the automation does, what can go wrong, and how to fix it.
- An owner. Someone in your team, not ours, who is responsible for it.
Where AI fits
Language models are very good at the messy edges of business processes: reading an emailed order, classifying a document, drafting a response. They are a useful new tool for exactly the work people currently do by hand.
But the principles don't change. Measure the work first. Keep a person in the loop where the stakes are high. Log everything. Most of the value still comes from connecting systems properly; AI just extends how far you can go.
Where to start
Pick one process that everyone complains about. Time it for a week. If it costs more than a few hours, it is probably worth automating, and it will tell you a great deal about the rest.