So then the third core element. In designing a Demand Planning solution you mentioned was granularity. Can you explain a little bit more about what you mean by granularity. Indeed, getting the granularity right of the Demand Planning model is extremely critical.

So first, let's define what granularity is a little bit and why it's important, right? This might get a bit technical, but in terms of describing a demand plan, there are various what we call the business dimensions of describing the demand plan. So typically a demand plan is described in terms of the product that you're selling to the market, right? Described in terms of the market where you're selling it into: the locations, markets, countries, etc.

Customer segments you're selling to. So customers organizing into various customer segments, groups of customers, etc. Time, when you're selling the product, could be days, weeks, fiscal months, fiscal quarters, fiscal years, etc. So for each of these dimensions, there's various levels at which you're describing the demand at what are called hierarchies.

So a product would be organized into product families. Product families could be product groups, days could be organized into weeks, weeks could be into fiscal months, etc. So these are product and time or dimensions, and these are organized into product hierarchies or time hierarchies, etc. So that's the technical side of it.

Why is this important? If you take the Demand Planning model, right? The final output of the demand plan is a forecast that's driving the supply chain. What's the right level at which to model the forecast?

That's the question. But then what are the inputs going into the demand plan? There are a variety of inputs that are going into the Demand Planning, right? The budgets, the market size estimates, marketing initiatives, pricing plans, promotion initiatives.

There could be a variety of things that are going as inputs into creating the demand plan. What's the right level to model these things at? Okay, so what traditional planning systems have suffered from traditional Demand Planning models is the problem of least common denominator. So let me explain that.

The forecasts are required at a certain level of detail to drive the supply chain. For example, you might need the forecast for the supply chain at an SKU level, at a location, at a supply chain location level, at a weekly level, because that's what is required to drive, move the product through the supply chain to the location where you want to store it at in order to respond to the customer forecast. So you need you need to know exactly what SKU to move, how much to move it to, what location to move. Right?

But on the other side, you have, let's say, an input to the demand plan. Let's say something like a budget or a market share market size estimate. Does it make sense to have, what level does a budget get set at? You don't set a budget at an SKU level, at a week level.

Typically, budgets are set at a product family level for a particular market, for a particular quarter, etc. Right? So it's at a higher level in the product hierarchy, in the market hierarchy, in the time hierarchy, market size estimates are also at higher levels. You don't have market size at SKU level, typically for a particular category, for a particular region, for a particular month or quarter.

These are market size estimates. So inputs and outputs are at different levels naturally in a Demand Planning model. But traditional Demand Planning systems that didn't have the sophistication, they suffer from what we call the least common denominator problem, which meant that all the inputs also had to be forced to be modeled at the lowest common denominator, which meant that budgets had to be broken down to an SKU level, which absolutely does not make sense. Forecasts are required on a scale level for the supply chain, but budgets don't make sense at an SKU level.

So what this created was essentially a problem of performance. First of all, the system became highly non-responsive to big data. Second, it was also a problem of flexibility. If tomorrow we had to change the budget process from one, you know, forecasting at a product family level to a different level, all these fake details that were created had to be redone, which was essentially non-value-add work, right?

So the right way to think about a Demand Planning model is what is the right level to model each of the inputs. It should be model at the level it makes sense, market size makes sense only at the level at which you get market size data from external parties. Budgets make sense only at this level at which finance is able to set budgets and targets or wants to set budgets and targets. Supply chain forecasts or demand forecasts make sense of the level at which supply chain requires the forecast.

The system has to have the ability to connect the dots and reconcile it. So if I want to compare forecast versus budget, it's not by putting the budget down at the lowest level. The system should be able to automatically reconcile at the right level, the forecast versus the budget. So that is essentially the basic principle of getting the Demand Planning model right.

Number one is getting the inputs on the outputs all to be modeled at the right level of detail, the level of detail at which the decisions make sense versus the least common denominator principle. And for every decision, there's a natural level at which it makes sense to model. So that's number one. Number two, now you take the outputs itself, which is the forecast driving the supply chain.

I talked about, okay, supply chain requires a forecast at an SKU level, at a location level for a particular week. But if you look across the planning horizon, for example, as you go further out in the horizon, even the supply chain, the decisions that you are driving, the supply chain, for example, if you are driving decisions eight months out or 12 months out. The capacity addition decisions, they need not be driven by the SKU-level forecast. They are probably driven more by the total capacity required for a particular product family.

So even from a supply chain forecasting standpoint, we have to design the level at which you forecast for the operational planning horizon, the tactical planning horizon, the strategic planning horizon, depending on the granularity of what the supply chain requires to make those decisions intelligently. And often, a lot of badly designed processes force the entire horizon of Demand Planning, the supply chain forecast to be defined as the lowest common denominator, and that is fake details that are not adding value to the supply chain planning process. And it creates a lot of performance and maintenance problems as well.

So more than modeling of the inputs and how they are connected to the outputs and as well as the modelling of the forecast itself across the different elements of the horizon based on what decisions you are trying to drive the supply chain, we have to get the modelling of those decisions at the right level of granularity and that's what we mean by getting the granularity right.