Back to blog
Production Planning·7 min read

Why Manufacturing SMEs Still Run Planning on Spreadsheets (And What Actually Replaces Them)

Walk into most high-mix, low-volume manufacturing companies in the Netherlands and you will find the real production plan living in a spreadsheet, not the ERP system. Not because anyone chose it that way. Because it grew, one exception and one workaround at a time, until it became the only place where the full picture of capacity, priority and delivery risk actually lived.

The spreadsheet was never the plan

A spreadsheet is a coordination tool wearing a planning tool's clothes. It works because one planner holds the context: which order actually matters this week, which machine is really available, which customer called twice already. That context lives in a person's head, gets typed into cells, and gets rebuilt from memory every time something changes. It scales exactly as far as that one person's attention span, and no further.

For a while this is fine. Order volume is manageable, the product mix is familiar, and everyone knows everyone. The strain shows up later, when the company has grown past the point where one person can hold the whole operation in their head, but has not grown enough to justify a full ERP or MES rebuild.

Where it actually breaks first

  • A late order becomes visible only when the customer calls, not when the delay first appeared on the shop floor.
  • Capacity numbers get re-argued in the Monday planning meeting because two versions of the spreadsheet disagree.
  • Shop-floor status is two hours behind reality, so planning decisions are made on stale information.
  • One planner becomes a single point of failure. Their laptop, their memory, their sick day.

None of these are data problems in the traditional sense. The company usually has the data somewhere, in the ERP, on a machine controller, on a quality checklist. What is missing is a shared, current view that connects those facts to the decision someone needs to make right now.

Why buying an MES rarely fixes it

The instinctive next step is to buy a platform: a new MES, a bigger ERP module, a scheduling tool with a convincing demo. For an HMLV manufacturer this often disappoints, and not because the software is bad. A generic platform expects processes to conform to its model. Real HMLV operations do not conform easily. Product mix changes, routings vary, and exceptions are the normal case rather than the rare one.

The result is a familiar pattern: an expensive system goes live, gets used for the parts of the process that fit its template, and the spreadsheet quietly comes back for everything else. The company now maintains two systems instead of one, with no single source of truth for either.

The actual constraint

The problem was never a missing platform. It was a missing connection between the systems that already hold the facts and the people who need to act on them, in the sequence their operation actually follows.

What a working alternative looks like

A more durable fix starts smaller than a platform purchase. It starts with one real workflow, traced end to end: how a delayed order actually gets escalated, how a quality exception actually gets routed, how shift handover actually happens. That flow gets connected to the systems that already hold the relevant facts, ERP for orders and master data, machine or MES data for status, quality systems for checks, without replacing any of them.

The spreadsheet disappears not because someone banned it, but because the shared, current view it used to fake by hand now exists natively, updated automatically from the systems of record. Planners keep their judgment and their authority. What they lose is the manual reconstruction work.

This is also, not coincidentally, how mature manufacturing operations around Brainport Eindhoven tend to approach it: prove the model on one bounded flow before asking the rest of the organisation to change how it works.

Starting without a rebuild

The practical starting point is not "replace the spreadsheet." It is "pick one workflow with visible friction and a measurable outcome", a late-order escalation, a planning update cycle, a quality exception, and build the connected version of that one flow first. If it holds up under real use, it becomes the pattern for the next one. If it does not, the cost of finding out stayed small.

Start with the work

Have one workflow like this in your operation?

Send us what actually happens today, spreadsheet and all. We will tell you honestly whether a bounded first workflow is worth building.

Map a workflow