Automating processes in a technical company: where to start

Almost every technical company we know shares the same pattern: highly qualified professionals spending a sizable share of their week on tasks that do not require their qualifications. Copying results from a spreadsheet into a document. Checking twenty portals in case something has come up. Redoing an annex because one input value changed. It was never a deliberate decision: it built up over time.

The usual reaction to that diagnostic is to want to automate everything. It is the most expensive mistake you can make: automation projects do not fail because of the technology, they fail because they start with the wrong process.

The criterion: three questions per process

Before talking about tools, draw up a list of candidates and put each one through three filters:

• Frequency. How many times a month does it happen? A process that runs daily pays for its automation even if each run saves only minutes. A quarterly one, hardly ever.
• Clear rules. Could you write down the exact instructions for a new colleague on a single page? If the answer is yes, it can be automated today. If every case “depends”, the process needs human judgment — or it first needs you to define the rules.
• The cost of an error. What are the consequences of a mistake? Here lies the paradox: the processes where an error is expensive (a standards-based calculation, a bid) are precisely where automation contributes the most, because an automated system does not slip up out of tiredness or haste — but they demand rigorous validation, not an improvised macro.

The ideal first process scores high on all three: frequent, with rules you can write down, and with an appreciable cost of error. In a technical company, the usual candidates are four: the generation of repetitive documents, the calculations that live in legacy spreadsheets, tender monitoring and moving data between the ERP and everything else. All four are set out, with their starting point, in automation for industry and technical companies.

What not to automate yet

Two categories are better left for later. The first: processes that are badly designed. Automating a chaotic process produces chaos faster; first you put it in order, then you automate it. The second: processes where the value lies precisely in the judgment — the final review of a bid, the decision on which tender to go for. There, software prepares and organizes, but the final decision must remain with whoever signs it.

How to know whether it worked

Before building anything, write down two numbers: how many hours a month the process consumes today, and how many errors or rounds of rework it generates. They take ten minutes to estimate and prove very valuable, because three months later they make the difference between “I think we are doing better” and “we got twenty hours a month back”. If whoever proposes automating it does not ask you for those numbers, take it as a warning sign: they are selling technology, not results.

The mistake of starting big

The alternative to this criterion is usually the big project: the platform that will solve everything, in eighteen months, for a considerable quote up front. Our advice is the opposite: one narrowly scoped first process, working in weeks, with its numbers before and after. If the result convinces you, the second process decides itself — and with what you learned in the first, it turns out better and cheaper. That is also why we charge per deliverable and not by the hour: the scope of a first process can be pinned down.