Software only makes bad processes faster

A process has two layers. The lower one is the logic: who decides what, in which order, with which information, and when a step is finished. The upper one is the tool: paper, Excel, email, a ticket system, an ERP. Software only ever replaces the upper layer. It takes over the lower one unchanged.

If the logic is right, a good tool makes it visible and fast. If the logic is wrong, it does exactly the same: it makes the lack of clarity visible and fast. An approval that used to sit in a tray for two days now sits in a queue for two days, and everyone gets a reminder about it. A field that nobody used to fill in is now a mandatory field that everyone fills with a dash.

In lean thinking this is called muda: waste. A digitised handover error is still a handover error. It costs less time per transaction, but it happens more often, because the system makes it more convenient. On balance, little has improved, and the disappointment in the team grows.

Before you write a requirements specification or watch a demo, it is worth taking an honest look at today's workflow. These are the signs I see again and again:

• Two people describe the same transaction differently, and both are right, because both variants exist.
• There are shadow lists. Someone keeps their own spreadsheet alongside the official route, because the official information is not enough for them.
• One step is called "clarify". Nobody can say what exactly exists at the end of the clarifying.
• Queries are normal. An order, a request or a drawing goes back and forth several times between the same people before it moves on.
• Done is not defined. Whether a step is complete depends on who you ask.

Each of these signs is a hole in the logic. Software does not fill a hole. It builds a screen over it.

A machine builder with several assembly lines introduced a ticket system for change requests from engineering. The aim was to get changes into production faster. After the roll-out, the number of open tickets rose, and assembly complained that it was hearing about changes later than before.

When we recorded the workflow at the workstations, the reason became clear. Before the system, the design engineer would go to the line with an urgent change and discuss it with the foreman. That was not documented, but it was fast. With the system, he created a ticket that dropped into a queue in production planning. There it was handled in order of arrival, not by urgency, because nobody had defined what urgent meant. The short walk to the line now counted as a workaround and was dropped.

The solution was not a different tool. It was three agreements: a clear definition of which changes may go straight to the line; a short daily look by production planning at new tickets; and a field that the design engineer sets himself. After that, the system did what it was supposed to do. It made a good workflow visible.

The sequence that has proved itself in my work is unspectacular. It costs a few weeks before the roll-out and saves months afterwards.

First, you record the workflow as it really runs today. Not according to the manual, but at the workstation, with the people who operate it. Value stream mapping works in the office just as it does on the shop floor: every step, every handover, every waiting time, every query is noted. This almost always produces surprises. Loops that management knew nothing about. Duplicated work that everyone thought was necessary.

Then you tidy up. Which steps disappear if the information is complete the first time? Which approvals are reassurance rather than decisions? Where can the person who has the information decide, instead of sending it upwards? That is the real work, and it is uncomfortable, because it touches responsibilities.

Only then do you describe what the tool has to do. You will find that the list is shorter than expected. A cleaned-up process needs few functions. An uncleaned one needs exceptions for every variant, and those are exactly what make software expensive, slow and unpopular.

The roll-out itself is a change project, not an IT project. That is almost always forgotten in the planning. A few points that make the difference:

• The team that operates the workflow helps to shape it. Not as test users at the end, but during the recording and the tidying up at the start.
• Shadow lists are not banned but understood. Every private Excel spreadsheet shows a piece of information that is missing from the official route. Bring it into the process, and the list dies of its own accord.
• One area first. Not the whole plant on a single cut-over date. One area, one workflow, then learn, then roll out.
• Done means used, not installed. After the roll-out, go to the workstations and check whether the paper printout is still lying next to the screen. If it is, you know what is missing.

The last point is the most important one for me. A system that formally runs and is bypassed on the side is more expensive than no system at all, because it costs trust.

When a management team presents a digitalisation project to me, I ask a single question: would this workflow also work well on paper? If the answer is no, software will not make it better. It will only make it bad faster.

That does not mean you should do without systems. A cleaned-up process in a suitable tool is a big win: for lead time, for transparency, for the people who operate it. It only means that the sequence is not negotiable. Process, then tool. Never the other way round.