Most optimizations fail on scope, not on method: one step gets improved while the bottleneck sits two departments away. Measure first, refine second.
A business process is a chain of steps that runs from a trigger to a result somebody outside the chain wants.
An enquiry arrives, a quote goes out. An invoice comes in, a payment leaves the building. The trigger and the result are what matter, not the departments in between.
That is exactly what separates a process from a task: a task is done by one person in one place. A business process crosses the building and changes hands several times on the way. Look only at tasks and you optimize locally, moving the waiting time somewhere else.
Handovers are where business processes actually lose time. Not the handling, but the sitting still in between. A case touched by three departments usually waits longer than it is worked on — and that waiting appears on no timesheet.
It appears in no ERP report either, because those record when something was booked, never when it could have been booked.
Before any method can help, the process needs a boundary.
Where does it start, where does it end, and who is the customer of the result? Those three questions sound trivial and are the most common reason projects produce nothing. Draw the boundary too tightly and the bottleneck is not in the picture at all.
Draw it too widely and no decision ever gets made, because too many people have a say. The trigger is a workable rule of thumb: everything between the triggering event and the usable result belongs in scope — including the parts that happen in another department, and especially those. Start the quotation process at costing and you miss the days the enquiry spent sitting in an inbox.
Scope also means deciding which variants get counted. Almost no real process has a single path: there is the normal case, the rush case and the exception, and the exception often eats the most time. Leave it out as an outlier and the process looks healthy on paper while every third case in daily work runs through the special loop.
Eight steps, named after the method: FLOW measures, REFY refines. The order is not arbitrary — each step is what makes the next one possible.
Where does work pile up, where is data retyped by hand, where do people complain? The output is a list, not a diagnosis. Anyone who already knows the answer here has confirmed something rather than searched.
Every candidate gets a number: what it costs per year, stated as a range rather than false precision. Without that number there is no way to say later whether anything paid off.
The process is run hundreds of times with varying step durations instead of averages. Only then does it show which step actually blocks — and it is rarely the one everybody names.
The lever is set against its cost. Sometimes the answer is that nothing is worth doing. That is a legitimate result and cheaper than a project you have to quietly cancel later.
Duplicate entry, media breaks and waiting loops go first. That costs no licence and works immediately. Automate chaos and you get faster chaos.
Who decides, who executes, who is merely informed? A large share of bottlenecks are not capacity problems but ownership problems — and no software fixes those.
Only now does technology come in, and in exactly one place. Connect systems rather than replace them: Excel stays Excel, the ERP stays the ERP.
The same measurement runs again. The output is a before-and-after in euros — and an honest answer when the effect turned out smaller than expected.
All four happen before the first measure is agreed. After that they are expensive to correct.
Das Problem:
What gets examined is what your own department does. Whatever happens before and after counts as somebody else's topic. The optimization then shaves hours off the handling while the case sits for days two doors down.
Die Lösung:
Cut the process from triggering event to result, regardless of who owns which part. If three departments end up in the picture, that is the finding, not the problem.
Das Problem:
Average handling time says nothing about lead time. A step that takes two hours on average but occasionally two days sets the pace of the whole chain — and disappears completely into the mean.
Die Lösung:
Work with ranges instead of averages. Only a simulation across many runs shows which step creates the queue and which merely inherits it.
Das Problem:
The normal case gets modelled because it is the one that maps cleanly. The rush order, the complaint and the customer with their own ordering system stay outside — although together they often account for the larger share of the effort.
Die Lösung:
Count the variants before judging them. If the exception occurs more often than assumed, the exception is the process and the normal case is the outlier.
Das Problem:
The software decision lands before the bottleneck is known. From then on the process gets bent to fit the tool, and every later measurement only measures whether the rollout worked.
Die Lösung:
Measure first, decide second. The tool question is the second-to-last question in the sequence, not the first — and sometimes the answer is that no new tool is needed.
The method is the same everywhere. What differs is the place where the time goes missing.
Not with the one people complain about loudest. It works better to put a rough number on every candidate first and decide afterwards. The process that generates the most complaints is often not the most expensive one — and the most expensive frequently goes unnoticed, because the loss is spread across many small waits.
Measuring a bounded process is a matter of days, not months: map the flow, collect durations, simulate, put a number on it. How long implementation takes depends on what was found. Removing ballast and clarifying roles often takes effect within weeks; a technical integration takes longer.
Usually not as the first move. The two steps with the fastest effect — removing duplicate work and clarifying ownership — cost no licence. If a lever remains after that, it is about a connection between existing systems, not about replacing them.
Digitization moves a flow into a system. Optimization changes the flow. Digitize first and you cast today's state into software, detours included. That is why measurement comes first: it decides which part deserves to be digitized at all.
Then that is the result, and it gets said plainly. A process costing a few hours a year justifies no project. Getting that answer early is the cheaper outcome compared with an initiative quietly shut down after six months.
The full method: eight steps from finding candidates to proving the yield.
Mehr erfahrenHow to keep measuring once the first process is fixed: roles, metrics, cadence.
Mehr erfahrenBPMN, tool classes and why BPM programmes stall at the model.
Mehr erfahrenStart with the free diagnosis or download FlowVisual. If you want to speak to someone afterwards, we're reachable.