In mid-market companies, improvement projects rarely start with a question. They start with a solution: a new system, an automation, a tool somebody saw. That is understandable, because a solution is tangible. It regularly leads to improving a workflow that was not the problem.
The step almost always skipped is the process map: an overview of which workflows exist, who is involved, and where they touch. It is unspectacular because it improves nothing. It only states what is.
Why the overview is missing even though everyone knows the business
In smaller companies every person knows their own part very well. What is missing is the view of the transitions. That is exactly where the losses occur: an order is passed on by mail and sits for two days. A piece of information is entered twice because two areas use different systems. A query goes to a person on holiday, with no stand-in.
None of these can be blamed on anyone, because they sit between responsibilities. They become visible only once a workflow is recorded end to end instead of described department by department.
How the capture works in practice
- 1.Collect triggers: what starts work in the company? Enquiry, order, fault, appointment, deadline.
- 2.For each trigger follow the path: who picks it up, what happens, where it goes next, until the case is closed.
- 3.Add systems: in which program does each step happen, and where do people switch.
- 4.Mark handovers: every change between people or systems gets a point.
- 5.Walk through it with those involved and correct until the map shows daily reality, not the intended design.
The last part matters most. A map showing the described rather than the lived workflow is worthless, because it smooths over exactly the points where time is lost.
What the map answers afterwards
Once it exists, questions that used to be matters of opinion can be answered: where do cases wait longest? Which information is captured more than once? Which step depends on a single person? Which workflow runs as an exception so often that the exception is the norm?
Only with those answers does the question of tooling make sense. Before that it is a bet. That is precisely why the capture comes first in our approach, not the tool selection.
If there is agreement in the business that something is stuck, but not on what: the process map is the step that ends that discussion, because afterwards everyone has the same picture in front of them.