Why capacity planning in manufacturing companies is structurally lagging behind reality
Most manufacturing companies plan capacity based on a model: how many hours does an operation typically require, how many people are scheduled, how many machine hours are available. That model holds up on paper. The problem is that reality on the shop floor constantly deviates from that model, and the planning only notices once someone raises the alarm. A technician calls in sick, a machine breaks down, an order turns out to be more complex than estimated. All of these deviations accumulate, but the planning does not adjust automatically. The planner corrects manually, if he is even aware of the issue. By that point, the disruption has already propagated further down the line.
Bottleneck 1: real-time utilisation data is not in the planning system
In most manufacturing companies, utilisation information lives in three places simultaneously: in the head of the production engineer, in a time-tracking system that is only synchronised the following morning, and in an Excel sheet the planner maintains himself. The ERP or planning package sees none of those three sources directly. What the system shows is a capacity picture based on the situation from the previous evening, or worse: from the moment the production order was created. Making adjustments based on that data means adjusting based on the past. Only when a workstation has physically come to a halt or an order is at risk of being late does the deviation become visible. At that point, the options are limited.
Bottleneck 2: absence and downtime are not immediately translated into capacity
A sick report at half past seven in the morning disappears into the HR system. The planning either does not know about it, or finds out via a message from the team leader. A machine fault goes to the maintenance department. The planning hears about it once the fault is already an hour old. The result is that the capacity plan for that day still assumes the original staffing levels, while the shop floor is already running short. Orders are not redistributed, priorities are not adjusted, and the customer only notices at the end of the day or the week. This is not an organisational problem you solve with better communication. It is an architectural problem: the planning system receives no signals from the systems where downtime is recorded.
Bottleneck 3: the connection with purchasing and lead times is missing
Capacity planning is not only about people and machines. It is also about materials. If a component arrives two weeks later than expected, that has a direct impact on the sequence of orders and therefore on the utilisation of workstations. But in most companies, that information sits in the purchasing system or with the buyer. The planning only retrieves that information when someone actively requests it. Bottlenecks in the supply chain become visible the moment the production line stops due to a lack of materials, not a week earlier when adjustment was still possible. The three problems are interconnected: no real-time utilisation data, no automatic translation of downtime into capacity, no connection with purchasing. They reinforce each other and ensure that planning always remains a reactive activity.
When does capacity planning software actually change this?
Software only helps once the data sources are connected. That sounds obvious, but in practice it is the hardest part. Adding a new planning package on top of an existing ERP and a standalone time-tracking system solves nothing if the three systems do not feed each other in real time. What does work: an AI worker that retrieves signals from HR, maintenance, and purchasing and automatically recalculates the planning based on changed capacity, or a custom planning system built from the ground up on the data sources that exist in your company. Bonsai builds both, depending on what the situation requires. If the existing ERP is adequate but the connections are missing, we build an AI layer around it that links the signals and alerts the planner in time. If the core system itself is the bottleneck, we rebuild it AI-native, so that utilisation data, downtime, and purchasing status always live in the same model. When does it not help? When the underlying data is unreliable. Software that presents poor or incomplete input more attractively tends to make the problem worse rather than better. Get the data foundation right first, then automate.