Aniruddha BiswasSAP Planning Advisory
<- Insights

Classifying High-Frequency vs. Low-Frequency Demand SKUs

A practical ML workflow applied to demand planning, translated for SAP IBP and PP/DS contexts.

In this article

  • Why high-frequency and low-frequency SKUs need different planning treatment.
  • How an Orange ML classification workflow maps to SAP IBP demand planning.
  • Why governance, drift monitoring, and fallback logic matter in regulated environments.
Aniruddha BiswasMay 1, 20268 min read
Abstract SKU classification workflow with demand clusters and forecast signal paths

Most pharma and process-manufacturing supply chains run thousands of SKUs through demand planning. A smaller set of high-frequency or fast-moving SKUs drives much of the planning effort, inventory investment, and service-level risk. These are the items planners touch every cycle and where exception management tends to pay off.

Low-frequency SKUs, intermittent demand, and long-tail indications often require a different treatment. Applying the same forecasting intensity to every item can waste planning attention where it has little business impact and under-focus the items that carry the most risk.

The practical question is simple: can we systematically classify SKUs as high-frequency or low-frequency using their characteristics, rather than relying only on planner intuition? In machine learning terms, this is a supervised classification problem.

I worked through the workflow in Orange using a public retail customer-segmentation dataset from supply chain analytics coursework, then translated the method into a demand planning context. The SAP IBP analogue is straightforward: the target becomes SKU frequency class, and the features become demand volume, coefficient of variation, ABC class, plant, channel, lifecycle stage, therapeutic area, indication breadth, and other master-data or demand-history signals.

The first discipline is data typing. Product hierarchy, plant, ABC class, and channel may arrive as codes, but they are categorical variables. Treating them as continuous numbers can distort the model. In SAP planning terms, a serious ML overlay starts with the data dictionary, not the model.

The next discipline is visual exploration. Before fitting a model, I look for feature pairs and distributions that separate the classes in a way planners can recognize. For SKU classification, that may mean plotting mean demand against volatility by ABC class, or reviewing lifecycle and therapeutic-area distributions within the high-frequency group.

A decision tree is a useful first model because it is explainable. A planner or supply chain leader can read the split logic and challenge whether it makes business sense. For SKU classification, a reasonable tree might split first on demand volume or volatility, then refine by lifecycle stage or ABC class.

Model comparison still matters. Logistic regression, K-nearest neighbors, and random forest each behave differently. AUC is a more useful comparison metric than accuracy when classes are imbalanced, which is common in SKU portfolios where low-movers often outnumber fast-movers.

The production lesson is governance. Model performance will change as the portfolio changes. A planning architecture needs retraining cadence, distribution-drift monitoring, champion/challenger comparison, and fallback logic when confidence drops. In regulated environments, silent model degradation is not acceptable.

The value of this work is not the model by itself. The value is translating planning problems into ML problems and then translating the model output back into SAP planning decisions that planners can trust, govern, and use.

Need a practical perspective on SAP planning, AI-enabled forecasting, or clinical trial supply chain?

Start a Conversation