The problem
Forecasting looks self-contained on a diagram. In practice it sits between product hierarchies, locations, pricing, promotions, inventory, suppliers, orders, and replenishment. Each domain has its own timing, ownership, and definition of correctness.
The engineering challenge was therefore larger than moving feeds into a commercial forecasting product. The platform had to preserve business meaning across interfaces, support more than one operating model, and provide enough evidence to explain why a downstream decision changed.
Why it was hard
Most source systems were correct within their own boundaries. Disagreement appeared at the seams: late-arriving updates, mismatched calendars, different product granularity, overlapping ownership, and business events that did not map neatly to technical schedules.
A platform could be available and still be unusable for a planner if the data represented yesterday in one domain and today in another.
How we approached it
We treated integration, controls, orchestration, reporting, simulation, and recovery as parts of one product. Reusable logic handled common patterns, while configuration allowed business units to retain necessary differences.
- Make business run dates and dependency states visible.
- Separate raw arrival from business readiness.
- Reconcile the values that drive decisions, not only row counts.
- Keep test and simulation paths close to production behavior.
- Design restart and audit behavior before incidents occur.
Tradeoffs
Standardization reduces maintenance, but excessive standardization hides real business differences. Flexibility helps adoption, but unlimited variation makes the platform impossible to reason about. The useful boundary was a common operating model with explicit, reviewed exceptions.
What stayed with me
Forecasting systems are decision systems. Their value depends less on a single algorithm than on whether the surrounding data, timing, controls, and explanations create confidence in the decision.