Do not automate a messy process

An executive team signs off on a new system because order processing runs too slowly. Six months later that same order processing still gets stuck, only now on a more expensive platform. The steps that made it slow are still there, neatly built in. What has been sped up is the error.

Software speeds up a process. It does not improve it. That difference sounds small and yet it determines whether an investment pays off or burns money. Whoever automates a messy process buys back the same work: the same duplicate entry, the same waiting time, the same exceptions, now set in concrete and billed per user.

The rule Bill Gates already wrote down in 1999

There is a sentence about automation that is older than most of the software you run today, and that still holds true.

Automating an efficient process increases efficiency. Automating an inefficient process increases inefficiency.

Bill Gates wrote that in Business @ the Speed of Thought (1999), and it is not wordplay but a warning. Software takes a process as it is and runs it faster, more often, at a lower cost per task. If that process is good, you win on every task. If it is messy, you scale the mess along with it, and from then on you pay faster for the same error.

Do the math. A task you get wrong three times a day today, a system will get wrong thirty times a day tomorrow, because a machine knows no doubt and no pause. The error does not become more visible, it becomes cheaper per unit and larger in total. That is exactly why companies sometimes spend more time on exceptions after an expensive implementation than before: they scaled a bad process instead of fixing it.

What mess looks like before you automate it

Mess is rarely dramatic. It is a step that was once introduced and that no one dares to remove anymore. An order that sits idle for three days on an approval no one remembers. Two departments retyping the same data into two screens, because the link between them was never built.

Often the waste is not in the task itself, but in the searching around it. McKinsey Global Institute calculated in The Social Economy (2012) that knowledge workers spend nearly 20% of their working week, about one day, searching for and gathering internal information, and that interaction workers spend about 28% on email. Cast that process into software without cleaning it up first, and you neatly build that searching and that email traffic in as well.

First the process, only then the software

That is why work with us does not start with a tool, but with the process. A process audit records how the work actually runs today, step by step, including the waiting time and the duplicate work. Not how it should run according to the manual, but how it runs on an ordinary Tuesday, with the exceptions everyone knows and no one writes down.

Then you cut. A step that adds nothing goes out. Two people entering the same thing becomes one entry. An approval that sits idle for days gets a limit or disappears. Only once the process stands do you know what you actually need to have built, and usually that is less than expected.

That cutting is not the fun part and it is the part that pays off the most. Removing a step costs no licence and no implementation. It costs a conversation and a decision. Every step that disappears this way, you then do not have to build, maintain or pay for, year after year. The cheapest software is the software you do not have to make because the work underneath already works.

The price of that cleanup pays for itself, because on a clean process the gain from automation suddenly becomes real.

What remains after the cleanup, YK builds as modules on one open-source platform that you own yourself. That way the gain lands with you, in a shorter lead time and less manual work, and not in a licence that keeps rising per user.

And you do not build everything at once. Each piece goes in waves, with a go or no-go at each step. If the cleaned-up process works in reality, you build the next one. If it does not work, you stop before you cast a second messy process into software.

Software follows the process, not the other way around. Whoever reverses that order buys speed on an error and pays for it for years. Whoever keeps to it ends up with fewer steps, less waiting time, and a system that does what the work actually requires. So do not start with the question of which software you buy, but with the question of how the work runs today, and what can be removed from it before a single line of code is added.