Why Manufacturing Demand Planning Fails
And the Data Problem at the Root of It

When a PE-owned manufacturer acquires a second business, they inherit its ERP, its item master, and its transaction history - all in a format that was never designed to be compared with the platform company's data. The same customer might appear as three separate records across three ERP instances. The same product category is described under three different naming conventions. Revenue from the same end market sits in three different cost center structures, with three different period-close calendars.

A demand forecasting model trained on this data is not learning the true demand pattern for a customer or a channel. It is learning a fragmented partial history that represents some subset of the actual demand signal. The model finds patterns in the data it was given. If that data is missing 30% of the volume for the segment being forecast, the model will confidently predict 70% of reality - and there will be no flag in the output indicating that anything is wrong.

The prerequisite for accurate demand forecasting in a multi-entity manufacturing environment is the same as the prerequisite for accurate gross margin analysis and working capital reporting: a conformed master data layer that resolves customer, item, and channel records to a single reference point before any model runs. Solving fragmentation is not a data hygiene exercise. It is a forecasting accuracy exercise.

Historical revenue alone is a lagging signal. The most predictive features for a demand forecast are leading indicators: open backlog (what customers have ordered but not yet received), booking rate (the pace at which new orders are entering the system), and quote activity (pipeline that has not yet converted to orders). Models that incorporate these signals consistently outperform those built on revenue history alone - particularly at 3-to-12-month horizons where pure time-series momentum loses explanatory power.

The common assumption is that these features are impossible to reconstruct historically because ERPs record current state, not historical state. A purchase order that was open on January 1, 2023 and was subsequently received appears only as received - there is no native snapshot of what was open on that date. Many forecasting implementations abandon leading indicators entirely as a result and fall back to revenue history alone. This is the wrong conclusion.

Order line creation dates, acknowledged ship dates, scheduled delivery dates, and shipment confirmation timestamps - when combined with ERP-specific reconstruction logic - allow us to answer "what was open in backlog as of date X?" with reasonable accuracy for Epicor, Dynamics 365, Infor SyteLine, Sage, and the other platforms in a typical PE-owned manufacturing portfolio. The reconstruction is an approximation, not a perfect audit trail. We are transparent about where approximation is involved and what the implied confidence interval is. But the result is a backlog series that extends the leading indicator window back through the available transaction history and gives the model a materially richer feature set than revenue history alone.

Forecasting is never perfect. The goal is not a perfect feature set - it is a better feature set than what most implementations default to. Knowing how each ERP platform stores its transaction history, and knowing which fields to combine to reconstruct a useful approximation of past state, is a meaningful capability advantage at the start of a forecast build.

Grain (also referred to as granularity, entity, or hierarchy level in data science and forecasting literature) is the combination of dimensions that identifies a single forecast row - the level of detail at which the forecast is calculated and reported. This decision has a larger impact on forecast accuracy and operational utility than any model selection choice, and it is made before the first line of code is written.

The mathematical reality of grain is not a modeling problem. It is a statistical property of demand signals. A facility generating $24M per year has a relatively smooth monthly revenue curve with enough signal to support a reliable forecast. A specific product category within a specific end market at that facility, generating $180K per year, is inherently more volatile relative to its mean. Small volume cells have high coefficients of variation. A single large order, a seasonal spike, or one lost account can move the number by 40% in a month. No model produces a low-error forecast for a high-volatility cell, because the signal is genuinely noisy - not because the model is wrong.

The right grain is determined by what decision the forecast is meant to support. Finance needs L1 for revenue planning and working capital projections. Procurement and production scheduling need L2 or lower to size purchase orders and production runs by product category and facility. Neither is wrong. They serve different purposes and carry different accuracy expectations.

The most powerful approach in a PE-owned multi-entity portfolio is a reconciled top-down and bottom-up view. A top-down model forecasts total revenue at L1, then allocates proportionally to L2 using historical mix. A bottom-up model forecasts each L2 cell independently, then sums to L1. The gap between the two is not a problem to resolve - it is a signal to investigate. When the sum of bottom-up L2 forecasts diverges materially from the top-down L1 forecast, it typically indicates a structural change in product mix, a new customer ramping at one facility, or a demand shift in a specific segment that the aggregate model cannot detect on its own.