Forecasting Everything by November

No. 640 x 4,200 is 2.69 million series; training and scoring that grid is where budget and the six-week window disappear, and most of those series are slow movers with intermittent demand where a seasonal average is hard to beat.

Segment first. Run an ABC analysis on revenue: roughly the top 20% of SKUs carry most of the value. Forecast store-SKU daily for those, aggregate the long tail to store-category and disaggregate proportionally. Store-SKU granularity is where planners actually make decisions; category level is good enough for the tail.

Check data sufficiency before modeling. Capturing annual seasonality needs at least two years of history per series. Series shorter than that - new stores, new items - should inherit a category or store forecast as a prior rather than be modeled alone. Missing days need explicit treatment, not silent zero-filling.

Beat the baseline or do not ship. Backtest on a held-out window (for example the last eight weeks) against both the current spreadsheet error and a seasonal-naive baseline. Also confirm the forecast horizon covers supplier lead time; an accurate seven-day forecast is useless against a 21-day order cycle.

A forecast that ties the baseline on the pilot cohort is a signal to stop, not to scale.

The current rule fails on the wrong axis. Static thresholds ignore that each unit has its own baseline and that signals are correlated - compressor current rising while discharge temperature rises and door events are normal is a different situation from either alone. Nine hundred alerts a day with 96% noise means the alert stream has been abandoned, so recall in practice is near zero regardless of what the rule claims.

Use multivariate models per asset type. Train on normal operation with OCI Anomaly Detection, one model family per equipment class rather than one global model, over correlated signals (current, temperature, pressure, duty cycle). Failures are rare and largely unlabeled, which is the case for unsupervised training on healthy data; supervised training only makes sense where you genuinely have labeled failure history with enough positives per class.

Tune to the workable budget, not to maximum recall. Set sensitivity so the system produces roughly 40 alerts a day at the start. A model that catches everything but is ignored catches nothing. Precision at the fixed alert budget is the metric, not ROC AUC.

Exclude known-benign cycles from training. Defrost cycles, holiday closures and scheduled maintenance must not be learned as anomalous, or the holiday peak itself will swamp the queue.

Close the loop. Technicians' dispositions become labels; retrain on them periodically rather than treating the threshold as final.

Both projects can start in parallel, but neither should launch at full scope.

Forecasting. Week 1-2: segmentation and data audit. Week 3-4: pilot on a subset of stores, backtested against the baseline. Week 5: planners review sample forecasts alongside their spreadsheets. Week 6: enable for the pilot cohort only, with category-level fallback for the tail. Full rollout happens after the season, when the holiday distortion is no longer confounding evaluation.

Anomaly detection. Run in shadow mode for two weeks against the existing rules. Compare at the same 40-alerts-per-day budget: precision, and how quickly a known failure would have surfaced. Keep the threshold rules as a backstop until the model beats them on real dispositions.

Write the success criteria before launch. 'Alert precision rises from 4% to 40% at 40 alerts per day with no increase in missed failures' is testable; 'AI forecasting live by November' is not. If the pilot misses, the honest move is a scoped partial launch with a retraining plan, not a full deployment that erodes trust in the first week.