Lesson 1: the order flow and the planning module do not communicate in real time
The pattern we encounter time and again: orders live in the ERP or CRM, while capacity planning sits in a separate system or a spreadsheet alongside it. The connection between the two is an export, a nightly batch, or a manual copy action by the planner. This means the planning is already outdated the moment a new order comes in. Planners are working with yesterday's snapshot while today's reality has already moved on. They try to keep up by phone, email, and memory. It works — until a large order arrives, a customer submits an urgent change, or a supplier reports a material delay. Then the facade falls away and it becomes clear that the planning never reflected the actual situation. What this requires is a data model in which the order flow and available capacity share a single source, so that a new order or a status change is immediately visible in the planning layer, without human intervention.
Lesson 2: capacity groups are too coarse to spot peaks in time
Even when capacity planning and order flow are connected, the next problem surfaces: the way capacity is structured. Many companies work with broad capacity groups such as 'machining', 'assembly', or 'surface treatment'. On paper, capacity appears available. In reality, one specific CNC machine or one particular operator certified for that piece of work is fully booked. That peak only becomes visible after the order confirmation has gone out and the delivery commitment is already in place. Setting up and maintaining finer capacity groups takes time, but the cost of groups that are too coarse is higher: late deliveries, internal firefighting, and customers calling to chase. The solution is not to install a new planning package. It starts with the data model: which resources are the real constraint, at what level do you want to track that, and is that level actually fed by current occupancy data from the shop floor?
Lesson 3: exceptions are handled outside the system
Rush orders, a machine breakdown, an employee calling in sick, a customer flipping priorities mid-week. All exceptions that in practice get resolved via WhatsApp groups, phone calls, or verbal exchanges on the shop floor. The system is not updated afterwards, or only at the end of the day when the planner gets around to it. The result is that the planning in the system and the actual situation on the floor drift further apart. This erodes trust in the system: once everyone knows the system does not reflect reality, everyone stops keeping it up to date. A downward spiral takes hold in which the exception becomes the norm and the system becomes decoration. You cannot fix this with a rule that says 'always fill it in'. You fix it by making the threshold for registering an exception lower than the threshold for picking up the phone, and by building the system to actively ask for confirmation when deviations are detected.
What does this require structurally from your data model and system architecture?
All three lessons point to the same underlying problem: linking capacity planning to order flow cannot work if the data model is wrong. Not if there is no shared model for orders, resources, and occupancy. Not if exceptions have a route that bypasses the system. What you need is an architecture in which order events directly affect the planning layer, without batches and without manual copy steps. Capacity groups defined at the level where the actual bottleneck sits, fed by current data from the shop floor. And a mechanism for registering exceptions that is simpler than sending a WhatsApp message. That sometimes means revisiting the ERP or the MES, sometimes adding an AI layer that recognises order mutations and proactively updates the planning. But it always starts with the question: who owns which data, and at what point is that data available to the planning? As long as that question has no clear answer, a new software package will solve nothing.