2026-07-26
Before you optimise anything, draw the floor
Over the past few weeks I had conversations with factory owners. Different companies, different products, different sizes. The same gap underneath all of them.
I asked each of them to show me how work and information flow through their factory floor. I was asking because I wanted to understand how complex the operation actually is, and a spoken description only gets you so far.
Every one of them could talk me through it. None of them were sure how to draw it.
That second part is the interesting one. Not unwilling, not evasive. Genuinely unsure where to start, because the flow they were describing had never existed as a picture. It existed as experience, and experience does not transfer.
A process that lives in someone’s head is not a process the business owns. It is a process one person owns, and everyone else is guessing at.
Four people, four versions of the same factory
A spoken description also hides how much disagreement there is. Ask the same question separately to four people in the same company and you get four answers, all of them sincere.
The owner describes the process as it was designed. Clean, linear, the way it was explained to the accountant.
The production manager describes it as it is scheduled. Roughly the designed version, plus the parts that always run late.
The team leader describes what actually happens this week, including the two workarounds that keep it moving.
The person at the machine describes what lands in front of them and where they push it next. They usually have the most accurate view and the smallest audience.
Nobody is lying. The process genuinely exists in four different heads, in four different versions, because there is no shared picture to argue with.
The map is the prerequisite, not the deliverable
Here is where this stops being philosophical.
Every improvement project encodes assumptions about flow. An ERP does. A scheduling tool does. A production tracking system does. Even a whiteboard with magnets does. Each one takes a model of how work moves and turns it into software behaviour.
If that model was never agreed, the tool automates a version of the factory that nobody on the floor recognises. Then people work around it, the data goes stale, and within six months you have an expensive system that everyone politely ignores while the real scheduling happens on WhatsApp.
Most failed implementations I have seen were not software failures. They were mapping failures that surfaced later, when they were expensive.
There is a second reason, and it is the one that actually saves money. You cannot find a bottleneck by looking at a list of workstations. A list tells you what exists. It tells you nothing about what feeds what. The constraint only becomes obvious when you can see the arrows: which station has work arriving from four directions, and which one everything downstream is waiting on.
Optimising anything other than the constraint is motion, not improvement.
So why does almost nobody have this drawn?
Not laziness. The tools are wrong for the job.
General diagramming software is built for consultants producing deliverables. Getting a real floor into it takes an afternoon of fiddling with connectors and alignment, and the result is a file in someone’s folder that is out of date by the next product change.
Spreadsheets hold the list but cannot show the flow, which is the entire point.
The whiteboard version is usually the most accurate thing in the building, and it survives until somebody needs the whiteboard.
So the map either does not exist, or it exists once, for a consultant, and dies.
I built the thing I kept wishing I had in those conversations
It is free and it runs in the browser.
You add a box for each workstation with its name and how many people work there. You drag arrows between boxes to show how work moves. You create departments, give each one a colour, and drag workstations into them so the map colours itself by area. The side panel keeps a running count of stations and headcount per department and across the whole floor.
That is deliberately the whole feature list. It is a thinking tool, not a system. It should take twenty minutes, not an afternoon.
How to actually use it in twenty minutes
Walk it, do not design it. Draw what happens this week, including the parts that embarrass you. The designed version is already written down somewhere and it is not the one costing you money.
One box per place where work waits or changes hands. Not per machine. If three machines sit in one cell and work moves between them without queueing, that is one box.
Put the real headcount in. Not the headcount on the org chart. The number of people standing there on a normal Tuesday.
Draw the ugly arrows. The rework loop back to sanding. The parts that go back to cutting because the panel was wrong. Those arrows are the whole reason to do this, and they are the first thing people leave out.
Group into departments and colour them. Then look at whether the colours cluster or whether the work crosses the floor four times to make one product.
Then stop and look at it for five minutes. That part is not optional.
What the picture tends to show
Every floor is different, but the same shapes come up.
One station with arrows arriving from everywhere. That is your constraint, and it is usually not the machine anyone talks about.
Rework loops that nobody had counted. Once they are on the page, the room tends to agree they happen more often than anyone admits.
Headcount that does not match flow. Six people upstream feeding one person at the choke point, with WIP piling up in between and nobody moving.
Departments that look tidy on the org chart and zig-zag across the physical floor.
A step that exists only because one person knows how to do it. If that box has one person in it and everything routes through it, you have a risk, not a workstation.
The point
If you are considering any kind of production software this year, draw the floor first. Do it with the people who work on it, not about them. Print it, stick it on the wall, and let people correct it, because they will, and every correction is information you did not have.
An hour spent drawing what actually happens is the cheapest hour in the whole project.
If you map yours, I would like to see it. Send it over and tell me what surprised you.