How to Automate Your Company: The Order to Do It In
A practical method for automating a business: how to choose the first process, how to score the rest, what to leave manual on purpose, and how to phase it so each stage pays for the next.
Order of operationsFIG.01
Short answer
Automate in this order: write down what your team actually does, score each process by how often it runs and how many times data is re-entered, connect your systems before adding any automation, then automate the highest-scoring process alone and measure it. The order matters more than the tools — automating a process you have not agreed on simply produces mistakes faster.
Key takeaways
- Do not start with the most annoying process. Start with the one that runs most often and involves the least judgement.
- Automation that is not connected to your main system just moves the retyping to a different screen.
- Map what actually happens, not what the SOP says. The gap between the two is where automation breaks.
- Measure the process before you automate it, or you will never be able to prove it worked.
- Some work should stay manual permanently — exceptions, negotiation and anything that changes every month.
Most automation projects stall for the same reason: the company automated whatever was irritating that week. Six months later there are four disconnected tools, each doing something useful, and the team is still copying between them.
The order you do this in decides whether it compounds or fragments. What follows is the sequence we use, which works the same whether you end up automating with an ERP, with AI, or with neither.
Step 0: write down what actually happens
Before any tool is discussed, sit with the people doing the work and record the real process — including the workarounds. Not the version in the SOP, and not the version the manager describes.
The gap between the two is where automation fails. If dispatch is officially approved by the manager but in practice goes ahead on a WhatsApp message when he is travelling, automating the official version will break your dispatches by Tuesday.
You are looking for four things per process: how often it runs, how many people touch it, how many times the same information is typed again, and what it costs when it goes wrong.
Step 1: score every process before choosing one
Score each candidate out of 5 on four axes. The arithmetic is crude on purpose — it exists to stop the loudest complaint winning.
| Axis | Score 1 | Score 5 | Why it matters |
|---|---|---|---|
| Frequency | Monthly | Many times a day | Savings multiply by repetition, nothing else |
| Re-entry | Entered once | Entered 4+ times | Re-entry is the part software removes cleanly |
| Judgement needed | Every case is a decision | Same rule every time | Rule-based work automates; judgement does not |
| Cost of an error | Someone corrects it | Customer lost, or money out | Decides urgency, not savings |
Add the four. Anything above 15 is a strong first candidate; anything below 10 should wait regardless of how much it irritates people. In most businesses the winner is order entry, document intake or invoice generation — not the thing that came up in the last management meeting.
Step 2: connect before you automate
This is the step companies skip, and it is the one that decides whether everything after it compounds.
If your order data lives in one place and your accounts in another with no link between them, adding an automation on top does not remove the retyping. It moves it. You now have a faster way to produce something that still has to be copied somewhere by hand.
Get the record into one place first — even a basic one. Automating on top of a connected system compounds, because every later automation reads data that is already correct. Automating on top of disconnected tools produces exactly the four-tool mess described at the start. If your finance data is the piece sitting apart, integrating ERP with your accounting software covers how that join is normally made.
Step 3: automate one process, completely
One process, end to end, with nobody keeping the old method running alongside it as insurance. A half-automated process is worse than a manual one, because now there are two places to check.
Automating a single process
Measure it as it stands
Time it, count the errors from last month, count the handoffs. Do this before you change anything — after go-live it is too late to establish a baseline, and without one you cannot prove the result.
Agree the rules in writing
Every branch: what happens to an urgent order, an unusual discount, a customer over their credit limit. Ambiguity here becomes an exception queue later.
Decide where a human stays in the loop
Approvals above a threshold, anything involving a price change, anything a customer sees for the first time. Name them explicitly rather than leaving it to be discovered.
Build it against the real process
Including the workarounds you found in step 0. If the workaround is legitimate, support it; if it is not, remove the reason it exists before go-live.
Run both ways for one cycle
One week, or one full cycle of whatever this process is. Compare outputs daily and fix the differences. This is the only parallel run you should allow.
Switch off the old way properly
Remove the old sheet and the old group chat. As long as the manual route exists, half the team will keep using it and your data will be split.
Measure again after a month
Against the baseline from step 1. A month is long enough for the novelty to wear off and for the real exception volume to show up.
Step 4: what to leave manual on purpose
Automating the wrong things is how companies end up with systems their staff quietly route around. Leave these alone:
- Negotiation and relationship work. Pricing exceptions, difficult customers, supplier disputes. Automate the record of the decision, not the decision.
- Genuine exceptions. If a case appears a few times a month and looks different each time, building rules for it costs more than handling it.
- Anything that changes every month. A process still being redesigned is not ready. Automate it once it has been stable for a quarter.
- Final judgement on anything expensive or irreversible. Large payments, large credit, anything a customer cannot easily undo. The system prepares it; a person approves it.
The point of automation is not to remove people. It is to stop people spending their day on work that has no decision in it.
Step 5: sequence the rest
After the first process works, order the rest by what feeds what. Automate upstream before downstream, always.
| Phase | What gets automated | Why here |
|---|---|---|
| First | Order capture and entry | Everything downstream reads this data; get it clean at the source |
| Second | Stock movement and dispatch | Now reads real orders instead of a copied list |
| Third | Invoicing and receivables | Generated from a dispatch that is already trustworthy |
| Fourth | Purchase and supplier records | Can now be driven by actual consumption |
| Fifth | Reporting and alerts | Only useful once the four above are entered consistently |
| Ongoing | Document intake, follow-ups, reminders | Bolt onto any phase once the records exist |
Reporting is last for a reason worth stating plainly: a dashboard built on inconsistent entry is not a small problem, it is a confident wrong answer. Most businesses want reporting first because it is the visible part. It is the part that depends on everything else.
Where this usually goes wrong
- Automating the complaint instead of the cost. The noisiest process is seldom the most expensive one.
- No baseline. Nobody measured the old way, so nobody can say whether the new way is better, and the next phase never gets approved.
- Leaving the manual route open. Data splits across two systems and neither is trusted.
- One person configuring it alone. They build the process as they believe it works. The people doing it daily find out at go-live.
- Buying tools before mapping. Every tool then defines the process, and none of them agree.
- Skipping training because the interface looks obvious. It is obvious to whoever specified it.
A realistic first ninety days
For a business with a few dozen staff and no system today, a workable shape is: two weeks mapping and scoring, three to four weeks getting records into one place, three weeks building and testing the first automated process, one cycle running in parallel, then a month of real use before the second phase is scoped.
That produces one process working properly and a measured result to justify the next. It is slower than a vendor timeline and considerably faster than the alternative, which is three phases started and none finished.
Start with one honest conversation
You do not need a specification to begin. If you can describe what your team does on a normal Tuesday and where the same information gets typed twice, that is enough to identify the first process worth automating — and to say so if the answer is that nothing is, yet.
Walk us through a normal week and we will map it with you before anything is proposed.
Frequently asked questions
Which process should we automate first?
The one that runs most often, involves the most re-entry of the same data and requires the least judgement — usually order entry, document intake or invoice generation. Score your candidates on frequency, re-entry, judgement and error cost rather than picking the one that generates the most complaints.
Do we need an ERP to automate, or can we start smaller?
You can start smaller, but connect things first. An automation sitting on top of disconnected tools moves the manual work rather than removing it. Getting your core records into one place — even a simple one — is what makes each later automation cheaper than the last.
How long does it take to automate a single process?
For a well-understood process with the rules agreed, three to four weeks of build and testing plus one full cycle running in parallel is typical. The mapping beforehand takes as long as it takes; rushing it is the most common cause of rework.
Will our staff resist this?
Some will, particularly anyone whose value has come from being the only person who knows where things are. It helps to involve the people doing the work during mapping, to be direct that the goal is removing retyping rather than removing jobs, and to switch the old route off cleanly instead of leaving it as an option.
How do we know the automation actually worked?
Measure the process before you change it — time taken, errors last month, number of handoffs — then measure the same things a month after go-live. Without that baseline any claim about the result is a matter of opinion, and the next phase becomes much harder to justify.
/Services in this article
/ERP & CRM Systems by country
Keep reading
All articlesERP Implementation Roadmap: From Spreadsheets to a Live System
A lower-risk rollout plan for mapping workflows, cleaning data, piloting one module, training teams and expanding ERP adoption.
Marine Procurement ERP: 7 Workflows That Need One Source of Truth
The essential modules for a marine procurement ERP: inquiries, vendors, quotes, purchase orders, warehouses, shipments and finance.
