Virtual Planning Layer

It is fair to categorize the collective IT tools, software and processes in a company as a complex system. They evolve over time with many cross-dependencies and are very critical to the operational efficiency. When things need to change, there is usually not enough time or budget to do a clean-slate redesign and the effort could end up being a partial upgrade or a patch. Especially, if it is a dynamic industry such as retail with constant change in consumer behavior and complex supply chains, the delta between ‘as is’ and ‘to be’ states in IT systems is ever increasing.

Planning teams, however, cannot afford to operate in the ‘as is’ state only. After all, even if it is a new channel not yet defined in systems, they need to somehow forecast sales and write the PO in time before leadtime restrictions hit. 

Not only handling ‘new’ is difficult, but there could also be a mismatch in the ‘existing’ data components, such as the granularity of data available in systems and the level needed for planning. For instance, IT might choose to define several location IDs for the same store (e.g., sales, returns, display, and a DC location ID for units allocated/in-transit to the store). However from a planning perspective, they are all one location and a total system inventory is most likely the best metric to base inventory decisions. 

Another major issue could be due to the planning teams’ need to dynamically move SKUs or Styles between merchandize hierarchies or collections without going through painful & irreversible reclassing efforts, so that they can have a better forecast. Similarly, the team might choose to define new product attributes (e.g., pricing strategy) that could be relevant for planning needs without affecting source systems.           

An interesting need that we observed at Demand Known was due to a client’s shift in supply chain strategy, driven by new tariffs introduced to one of their origin countries. They moved their operations to another country and started purchasing the exact same SKUs from other vendors (or factories of the original vendors). By design, IT systems assigned new IDs to these SKUs, though there was no visible change to the product from consumers’ perspective. Having two separate SKUs means all the valuable historical reference is lost or misplaced, and it would be a considerable manual effort to reconcile old & new SKUs when planning forward projections.   

In order to close the gap between the source data and planning needs of our clients at DK, we have developed a concept we call ‘virtual planning layer’. With simple user driven mapping tables and algorithms we transform the original source data to a granularity that would let our users plan at the level they need with minimum effort.

Özgür

February, 2024