Manufacturing: Discrete Production Intelligence

Step 4 — Capacity constraint integration & production planning model (weeks 5–7) The demand forecast alone was only half the problem. We built a capacity integration layer in dbt that translated the SKU-level demand forecast into production requirements accounting for standard run rates by line, batch sizes, changeover time between SKU families, and raw material lead times by commodity. The output was a 10-week rolling production requirement plan that could be compared directly against available capacity, surfacing constraint violations weeks where demand exceeded what the plant could realistically produce with enough lead time to act on them. This was the connection that had never existed before: a number that answered "can we actually make what we're promising to sell?" automatically, weekly, without a spreadsheet in sight. Step 5 — Tableau planning suite for sales, operations & executive teams (weeks 7–9) Three connected Tableau environments were built on the same Snowflake foundation. The demand planning view gave the planning team a SKU-level forecast dashboard forecast vs. actuals by week, promotional lift overlays, and a days-of-supply view by SKU and storage location that replaced the nightly ERP inventory report with a live, actionable position. The production planning view gave the operations team a 10-week capacity plan demand requirements vs. available capacity by production line, raw material coverage flags, and a changeover impact calculator that showed the scheduling cost of different sequencing decisions. The executive S&OP view gave the VP of Supply Chain and CFO a single-page weekly summary: forecast accuracy, on-time delivery, inventory health, and any constraint alerts requiring leadership attention designed to be read and acted on in under five minutes.

Challenges faced The retail EDI feeds were the most technically complex data source in the project. Both retail partners used different EDI standards, different item identifier schemes, and different aggregation levels for their POS reporting. One reported daily by store; the other reported weekly by distribution center. Normalizing these into a comparable daily sell-through signal required significant transformation work and a mapping table that linked each retailer's item codes to the client's internal SKU master, a mapping that needed manual validation for approximately 60 SKUs where product packaging variations had created one-to-many relationships. The promotional lift model required more historical data than was cleanly available. The marketing team had records of past promotions, but the depth, mechanics, and retail coverage of those promotions were documented inconsistently. We spent three weeks reconstructing historical promotion records from a combination of ERP shipment spikes, marketing emails, and retail invoices building enough of a structured history to train the model before deploying it on the forward calendar. Organizationally, the S&OP meeting itself required reframing. The planning team was initially concerned that a centralized forecast model would reduce their role that the machine would make the decisions and they would just execute. We addressed this directly by building the forecast override feature into the planning dashboard from day one, making it visible and documented when the team applied a manual adjustment and why. The model's job was to give planners a better starting point. The judgment calls remained theirs.

Technology used Data Engineering: Cloud data warehouse, ERP & CRM pipeline automation, EDI feed normalization, promotional calendar integration Forecasting & Planning Analytics: Statistical demand forecasting, promotional lift modeling, capacity constraint integration, days-of-supply modeling Business Intelligence & Visualization: Integrated S&OP planning dashboards, capacity planning views, executive weekly summary