Why the spreadsheet plan breaks
A spreadsheet is not a plan. It is a photograph of the plan at the moment somebody filled it in. While nothing changes, the difference does not show. The problem starts on Thursday at ten, when a machine breaks, the steel from the supplier is late, or your biggest customer calls with a rush order.
Somebody then has to work out by hand what moves, what still makes its date and what does not. That work takes long enough that something else changes while it is being done. In practice the plan is out of date before it has been rewritten, and the shop floor starts working from what the operators remember rather than from the sheet.
- The sheet does not know how much capacity you really have, so it will happily let you put twelve hours of work into an eight-hour shift.
- It does not know that the second operation cannot start before the first has finished.
- One person holds it. When that person is on holiday, the plan stands still.
- It remembers nothing. At the end of the month you cannot reconstruct why you were late.
What a plan has to know
Before any software, there has to be an answer to three questions: what is being made, with what, and how long it takes. That is the whole model, and it is simpler than it sounds.
WORK ORDER
customer, quantity, due date, priority
└── OPERATION (sequence is mandatory)
resource / work centre
setup time
time per piece (standard)
RESOURCE
available time per shift
planned downtime (maintenance, breaks)
actual downtime (failures, waiting for material)If this exists and is roughly accurate, a plan can be produced. If it does not, no software will help, because it will only produce the wrong plan faster. The part that most often is not accurate is material, because recorded stock is not actual stock.
Your capacity is fiction until you measure downtime
This is the most common reason plans do not hold, and it is almost never mentioned. The firm assumes a machine runs eight hours a shift. In reality it runs five and a half: some goes on setup, some on a breakdown, some on waiting for material or a forklift, some on nobody noticing that a batch had finished.
If you plan on eight, the plan is mathematically impossible from day one and everyone on the floor knows it before you do. After a few weeks people stop believing the plan and go back to arranging things as they go, and you have software nobody looks at.
So downtime tracking is not a separate project for later; it is the precondition for serious planning. The good news is that it is also the cheapest part: it is enough for the operator to mark the machine and the reason when it stops. Within a few weeks you have a distribution of reasons, and it usually turns out that three reasons account for seventy per cent of the loss.
The infinite capacity trap
A large part of classic systems plan with so-called infinite capacity: they work out what has to be done and when, without checking whether a machine is free at that moment. What you get is a tidy list that cannot be executed on the floor.
Finite capacity scheduling works the other way: every operation occupies a specific resource for a specific interval, and if the resource is busy, the operation moves. The resulting plan is uglier and the dates are later than you would like, but it is achievable. An ugly plan that holds beats a pretty one that does not.
The other useful distinction is direction. Forward scheduling starts from today and asks when the job will be finished. Backward scheduling starts from the due date and asks when it must start at the latest. The first tells you what you can promise; the second tells you whether you are already late.
The bottleneck decides, the rest is noise
Every shop has one resource that governs total throughput. Whatever you do on the other machines does not change how much the firm ships in a month. Speeding up an operation that is not the bottleneck only builds a pile of work in progress in front of the one that is.
The practical consequence for software matters: you do not have to schedule the whole shop precisely to get the benefit. Schedule the bottleneck precisely and let the rest fall in around it. That is a much smaller system, it goes in faster, and people accept it more easily.
The bottleneck is also not always a machine. Often it is the one person who can set a particular machine up, or quality control that everything has to pass through, or the forklift. If you cannot see that in the data, you will optimise the wrong thing.
Replanning speed matters more than an optimal plan
This is where most money is wasted. There is a temptation to build a system that searches for the best possible schedule. Mathematically interesting, on the shop floor close to worthless.
The reason is simple: the inputs go stale faster than optimisation is worth. By the time the system has computed a perfect schedule for the next ten days, a machine has broken and the perfect schedule is no longer even a good one. A firm working to order does not need the best plan; it needs a plan that can be rebuilt in fifteen seconds when something changes.
The real measure of such a system is not the quality of the schedule but how much time passes between something happening and everyone on the floor knowing what they are doing now.
The order to introduce it in, and when not to
An order that does not collapse in practice, because each step is worth something even without the next:
- Visibility. Which orders exist, what stage they are at and where they physically are. A few forgotten orders usually turn up right here.
- The truth about capacity. Downtime tracking, and a comparison of actual times against the standards. The standards are almost always optimistic, and it is better to know.
- Scheduling the bottleneck, with finite capacity.
- Promising dates from the plan rather than from instinct. This is the point at which sales stops promising the impossible.
And now the part nobody selling this will tell you. Do not introduce a scheduling system if you make a small number of the same things at a steady rate, if you have one line without branching, or if one person holds the whole shop in their head without difficulty and it works. In those cases the spreadsheet is the right tool and will stay the right tool for a long time.
The need appears when the number of parallel orders grows until the sequence is no longer obvious, when dates start slipping without a clear reason, or when it turns out that the only person who knows the schedule cannot take a holiday.