On our process optimisation page there is a question we put to every customer sooner or later: what does this process cost us every month, and what would happen if it were 20 to 30 percent more efficient?
At a spare-parts wholesaler with around 60 employees and four companies across the DACH region, that question wasn't the starting point. The costs were roughly known: too much capital in items nobody needed, and shortages of the ones currently in demand. The real problem sat elsewhere. Purchasing no longer believed its own order-planning software.
This article walks the four steps from that page through the project once. Not as a methodology lecture, but the way it actually happened.
Why the most expensive process is rarely the one you touch
Almost every company knows which workflow creates the most friction. That friction just rarely gets translated into a number, and without a number there is no priority.
One reason sits in the data. According to the Bitkom study on the digitalisation of the economy 2026, which surveyed 604 companies with 20 or more employees, 61 percent barely use their data potential or don't use it at all. Only 5 percent get everything out of it. The second reason is even more mundane: 66 percent name a lack of internal time as a digitalisation barrier. Anyone who has to place orders every day doesn't analyse the ordering process on the side.
That is exactly why the known problem case persists. Not because nobody sees it, but because nobody calculates it.
Step 1: Understanding the process means finding the parallel world
The first step is what we call "understand the process", and it doesn't consist of painting a nice target picture. It consists of finding the process that actually runs.
The four questions behind it are unspectacular: who is involved? Where do waiting times arise? What runs manually? Where is data captured a second time?
But the fastest route to an answer is a different one, and it has become our most important diagnostic question: does someone keep their own list alongside the system? Wherever a spreadsheet runs in parallel to the software, that is where the real process sits. The spreadsheet isn't carelessness, it is a diagnosis. It shows precisely which part of their work a person won't hand over to the system, and usually they can tell you exactly why.
At the wholesaler the answer was unambiguous. Purchasing planned its orders in its own spreadsheets, even though established order-planning software was running and calculating in-house. That identified the subject of the investigation. Not the software, but the gap between software and decision.
Step 2: Identifying cost drivers
The second step is about making the most expensive spots visible and prioritising them. In document- and decision-heavy workflows, the same categories show up almost every time: quotation and order processing, invoice verification, reporting, complaints, approvals, warehousing and delivery.
In the ordering process the costs sit on two sides, and the second one is regularly forgotten.
On one side there is tied-up capital. Every item that sits on the shelf too early or in too large a quantity ties up money that could be working elsewhere, and creates storage, handling and write-down costs. This side can be calculated once you know your average inventory value and your imputed interest rate. Both are in your accounting.
On the other side there is the stockout, and it appears in no account. An item that is missing when a customer needs it costs express freight, follow-up effort in sales, postponed orders and, in the worst case, the customer. There is no booking for these costs, which is why they show up in no report. That is exactly what makes them so expensive.
A defensible number only emerges here with your own values, not with industry averages. Which metrics are suitable for that and which merely reassure, we wrote up in more detail in Improve, reinvent, or scrap?.
The problem wasn't the wrong calculation, it was the inexplicability
This is where the project got interesting, because the loss of trust had a backstory.
The standard software in use had demonstrably calculated wrong order proposals in the past. The background wasn't bad software, but the complexity of its implementation: many parameters, many assumptions, many places where a configuration didn't match the reality of the spare-parts business. On top of that, the result wasn't traceable. The proposal was there, but not how it came about.
And from that grows the chain that made the process genuinely expensive in the end:
- Standard software carries a core process whose logic depends heavily on the individual company.
- The implementation becomes complex, because every peculiarity has to be modelled through parameters.
- Wrong proposals arise.
- The result isn't traceable, so the error can't be attributed.
- Because nobody finds the cause, nobody can eliminate it.
- Purchasing builds itself a parallel world in which it understands the calculation itself.
The decisive point sits in stage four. A wrong proposal alone doesn't destroy trust. A wrong proposal you cannot explain does. With an explicable error you check the master data, correct a parameter and carry on. With an inexplicable error you don't know whether the parameterisation was at fault, the data quality, or the calculation model itself. So you stop trusting the next proposal too, even when it is right.
That this pattern is no isolated case shows in the wider view of automation. In Camunda's State of Agentic Orchestration and Automation Report 2026, 71 percent of companies run AI agents in pilot projects, but only 11 percent productively in real decisions. 85 percent lack the process maturity for that step, and 48 percent report that their automation runs isolated alongside the actual process. The pattern is the same as at the wholesaler: computing power was never the bottleneck. Traceability was.
Step 3: Optimising deliberately, and at the root
From that diagnosis followed a decision we took together with the customer: the old solution wasn't extended, it was replaced.
The reason is the same one the process failed on before. Transparency cannot be layered over an opaque calculation. You can put a better interface in front of it and additional reports beside it, but the black box stays and gets carried along. If traceability is the actual goal, it has to arise inside the calculation itself.
So what was built is a web app with statistical demand forecasting and a connection to both ERP systems, which explodes sales items through multiple levels into their purchasing components so that order proposals arise where ordering actually happens. Four things were decisive:
- Every order proposal reveals its basis. Average consumption, safety stock, replenishment time and the applied strategy are visible, including intermediate results. Purchasing can check every proposal, comment on it and adjust it with domain knowledge, instead of believing it or ignoring it.
- Coordinated weekly cycles instead of ad-hoc decisions. All four companies order to a shared, aligned rhythm.
- Management approval before release. Nothing goes out automatically. Leadership keeps control without having to check every individual item.
- Live connection to both ERPs. Stock and order data flow into the forecast in real time, rather than from an export made last week.
Inside this third step, the workflow that was built looks like this, a cycle of five stations that starts afresh in every company:
The special part sits in the box at the edge. The four companies are supplier and customer to each other at the same time. What shows up as demand in one becomes a delivery in another, and the terms for it are agreed internally. That is precisely why order planning doesn't work here as four independent calculations. When all four calculate at the same time using the same method, their orders no longer add up by accident but go into the supplier conversation as one aligned picture.
The last item on the list is the one that makes the solution viable, and it has nothing to do with calculating. With intelligent process automation we handle it the same way: the system prepares and proposes, the critical approval stays with the human. Whoever carries responsibility needs control, otherwise they won't use the system.
Step 4: Measuring success, including where no number exists
The fourth step is the before-and-after comparison. At the wholesaler, the hard side reads:
| Result | Before |
|---|---|
| Approval turnaround under one day, from proposal to released order | No approval process in place |
| Four companies ordering to a shared cycle | Four companies with no shared rhythm |
| Two ERP systems live in the forecast | Manual data upkeep on outdated foundations |
The indicator that tells us the most, however, appears in no table: the side spreadsheets disappeared. As long as someone is still calculating in parallel, the optimisation hasn't landed, regardless of what the dashboard claims. The sentence we measure this project by came from the head of purchasing: "At last we know why the system orders what it orders." The full story is in our reference Order optimization with transparent forecasting; the solution itself is now available as Visposition.
Honesty requires the other side too. In the Bitkom survey, 45 percent of AI-using companies report accelerated internal processes, but 33 percent also report higher costs than expected. That is why we measure before the start and not only afterwards. Without a baseline there is no proof later, only claims in both directions.
The same sequence, a different process
The pattern isn't tied to procurement. At a mid-sized food company, every service request ran through five stations: customer service, internal sales, technical, dispatch and billing. All worked on the same case, but not in the same system. Handovers went by email, spreadsheet and phone, across three ERP systems that had grown over time.
Here too the cost driver wasn't the individual piece of processing, but the handover in between. And here too the largest items sat outside any report: recourse claims against suppliers that got lost in day-to-day business. In the end it amounted to five-figure annual losses that previously weren't measurable. Today the three ERP systems come together in one continuous workflow, and a ticket is handled in under a day. It's all in the reference Service ticketing, rethought end-to-end.
Two industries, two completely different processes, the same root cause: information that doesn't travel with the process, and results nobody can explain.
Four questions for your process
If you want to transfer this to a workflow of your own, four questions are enough to start:
- Does someone keep their own list alongside the system? If so, which part of the work do they not trust the system with?
- Can anyone explain how the system arrives at its result? If not, every error is an unsolvable error.
- Which costs of this process appear in no booking? Express freight, rework, postponed orders, lost orders.
- Does anyone know where a case currently stands without asking? Every necessary follow-up question is a measuring point.
Anyone who can answer these four questions for their most important process no longer needs a study to know where the money is left behind. And usually doesn't need a major project to get it back either.