Why the production schedule still lives in a spreadsheet
The suite could not model changeovers, so planning left it. The spreadsheet is now the real system, and it has no access control and no history.
Walk into most mid-sized manufacturers and you will find a well-implemented ERP handling finance, and a spreadsheet handling the plan. The spreadsheet is maintained by one planner, contains a decade of accumulated logic in formulas nobody else fully understands, and is the actual system of record for what the factory will make this week.
It is easy to read that as a discipline failure. It is not. It is a fit failure, and the planner is the person compensating for it.
What the suite cannot express
Packaged planning modules assume a shape. Yours probably differs in at least one of these ways, and one is enough to push planning out of the system:
- Changeover cost depends on sequence. Running product A then B is cheap; B then A means a two-hour clean. Most standard schedulers treat setup as a fixed number per job.
- Machines are not interchangeable. Three lines can technically run the same SKU, but one does it at 60% yield and only when the good operator is on shift.
- Material substitution is routine. When the specified grade is unavailable, an experienced planner knows which alternative works for which customer and which absolutely does not.
- Customer priority is political, not a field. The order that ships late is a commercial decision, and the rule is not written down anywhere.
- Capacity is a range, not a number. It depends on shift pattern, absenteeism, and whether the maintenance window can be moved.
The spreadsheet is not a workaround for bad software. It is the only place the plant's actual operating rules are written down — and it has no access control, no history and no backup.
What the spreadsheet costs you
Nothing, until it does. The costs are real but deferred, which is why they rarely justify a project on their own until something goes wrong.
There is no history, so you cannot answer why a decision was made three months ago or measure whether planning is improving. There is no access control on a file containing customer priorities and margins. There is no integration, so the plan and the inventory position drift apart between refreshes. And there is key-person risk of the acute kind — if the planner leaves, a meaningful part of your operating knowledge leaves in the same week.
The right thing to build, and the order
Not a replacement ERP. Keep the packaged system for finance and statutory reporting, where it is genuinely strong, and build the layer it cannot express. In practice that is four things, and they sequence in a specific order because each depends on the one before.
First: inventory that is actually right
Planning against a wrong stock figure produces a wrong plan confidently. Before anything else, goods movements need to be recorded where they happen — scan at receipt, at issue, at transfer — and reconciled continuously against the ledger rather than at month end. Batch and serial genealogy goes in here too, because retrofitting traceability means reconstructing history you did not record.
Second: procurement that closes the loop
Requisition with a budget check, approval limits with delegation, purchase order, goods receipt, and three-way matching that names the specific blocker rather than failing silently. This is where material availability becomes trustworthy, which is what planning depends on.
Third: the scheduler, with your rules as configuration
Now the planning layer, with the constraints above expressed as data your team can edit rather than logic we hard-code. Sequence-dependent changeover matrices, machine capability and yield by SKU, substitution rules, priority tiers. The planner should be able to change a rule without a change request, because these rules move.
One design point worth insisting on: the scheduler must produce a plan a human can override, with the override recorded and a reason attached. A system that cannot be overridden gets abandoned within a month. A system that records why it was overridden gives you, after a year, the list of rules that are actually wrong.
Fourth: quality and maintenance around it
Inspection records against specification, non-conformance and corrective action workflows, and preventive maintenance scheduled on usage rather than memory — with work orders that consume spares from the same inventory the plan depends on. This closes the last loop: a machine down for maintenance is capacity the scheduler already knows about.
Where automation genuinely helps here
Deliberately narrow. Supplier quotations arrive in a dozen formats and normalising them into a comparable table is genuinely tedious and genuinely automatable. Inbound order confirmations and dispatch advices buried in email can be read and turned into structured updates. Purchase requisitions can be routed by value and category without a person deciding each one.
What we would not build for a plant at this stage is a demand forecasting model or vision-based defect detection. Both need data quality and volume that a business still planning in a spreadsheet does not yet have, and both are considerably easier to sell than to make work. Fix the record first; the interesting analysis is a later phase and will be better for the wait.
Read next
- Healthcare operationsThe hospital systems nobody demosEvery vendor demos the clinical system. Nobody demos the store, the equipment register or the service contract that quietly lapsed.
- InfrastructureWhen on-premise beats cloud, and the costs both sides leave outCloud became the default rather than a decision. There is a specific, identifiable set of workloads where owned hardware is simply better.