From manual ops to automated pipelines
The path from a spreadsheet and two people to a pipeline that runs itself, without breaking the business on the way.
Most operations that need automating are already working. Slowly, expensively, and on the memory of one or two people who know where the bodies are buried – but working. That changes how you have to approach them. The first mistake is to replace all of it at once. The second is to automate the process exactly as it is, mess included, and end up with a faster way of doing the wrong thing.
Write it down as it is really done
Not as the manual says. The manual says orders are entered from the email. In practice, someone checks the email against a WhatsApp message from the driver, corrects the postcode from memory because the customer always gets it wrong, and enters it after lunch because the system is slow in the morning. Every one of those details is a requirement hiding as a habit. We spend the first days of an automation project watching and asking, and the map that comes out of it is worth more than any tool we bring.
Automate one step, and run it alongside
Find the step with the most repetition and the least judgement. Automate that one step only, and run it in parallel with the manual version for long enough that the numbers have to match. When they do, retire the manual step. When they don't, you have found either a bug or a rule nobody had written down, and both are worth finding this way rather than in production. Then move to the next step.
This is slower than a big-bang replacement on paper and faster in practice, because a big-bang replacement is never actually finished. It is switched on, breaks something invisible, and gets quietly worked around by the same two people, who now have two systems to keep alive.
Exceptions are the product
A pipeline that handles the ordinary case is easy. The value is in what happens to the case it cannot handle: the malformed feed, the missing field, the order that is technically valid and obviously wrong. Every exception needs somewhere to land – a queue, a message, a person's name – and needs to be visible. Automation that swallows its failures silently is worse than the spreadsheet, because at least the spreadsheet had someone looking at it.
What the team does afterwards
The people who used to do the work do not disappear; they change jobs. They watch the pipeline, catch the exceptions, and improve the rules, which is work that needs exactly their knowledge and none of their old patience. By the end, the operation is a chain of small, tested pieces rather than one big system nobody dares touch, and the two people who used to hold it together have a day back every week and a much better understanding of what they were holding.