Whenever we discuss Flowcasting, we always describe it as ‘a valid simulation of reality inside a system’. This term originated with our longtime colleague Darryl Landvater and it is the most concise and accurate way to describe what Flowcasting really is that we’ve heard.
In fact, we use that term so much that I think we sometimes assume its meaning is self evident.
It’s not.
Over the last 11 years since Flowcasting the Retail Supply Chain was first published, I’ve noticed that, more and more, the terms ‘Flowcasting’ and ‘valid simulation of reality’ have been treated somewhat like ink blots, with some folks (intentionally or otherwise) using them to mean whatever they want them to mean.
To set the record straight, a true ‘valid simulation of reality’ for the retail supply chain has some very specific characteristics, all of which must be present. To the extent that they are not, the value of the plan suffers – as do the results.
Before diving into the nitty gritty details, consider this: Virtually all retailers have a data warehouse that captures daily sales summaries for every product in every location, all upstream product movements, every on hand balance and certain attributes of every product and every location. This data is usually archived over several years and the elemental level of information is kept intact so that rollups, reports and analysis of that data can be trusted and flexibly done.
Think of a valid simulation of reality for the retail supply chain as a data warehouse – with a complete set of the exact same data elements at the same granular level of detail – except that all of the dates are in the future instead of the past.
However, it must also be said that ‘valid’ does not mean ‘perfect’. Unlike the historical data warehouse that remains fixed after each day goes into the books, the future simulation can and will change over time based on what happened yesterday and new assumptions about the future. Updating the simulation daily at all levels is the key to ensuring it remains valid.
Now let’s get into some of the specifics. A valid simulation of reality has 4 dimensions:
- Information about the physical world as of this moment
- Forecasts of expected demand over the next 52 weeks for each individual product at each individual point of consumption (could be a retail store or a virtual store)
- A simulation of future product movements driven by the forecasts and future planned changes to the physical world
- Rollups of the elemental data to support aggregate planning in the future
While it may seem that meeting all of these requirements is onerous, it is actually quite simple compared to trying to do things several different ways to account for variations in how products sell or are replenished.
Current information about the physical world includes things like:
- Master information about products (e.g. cube, weight, pricing, case packs, introduction and discontinuation dates) and locations (stores, DCs, supplier ship points)
- Relatively accurate on hand balances
- Planogram details such as store assortment, facings and depth
- Source to destination relationships with lead-times that are representative of physical activity and travel times
This information is ‘table stakes’ for getting to a valid simulation of the future and is readily available for most retailers. High levels of accuracy for these items (even store on hands) is achievable – so long as the processes that create this information have some discipline – because they are directly observable in the here and now.
Forecasts of demand over the next 52 weeks must:
- Include every item at every selling point
- Model demand realistically for slow selling items (i.e. integer values as opposed to small decimals that will model an inventory ‘sawtooth’ that won’t actually happen)
- Include all known positive and negative future influences for each individual item at each individual selling location (e.g. promotions, assortment changes, trends)
- Allow for ‘uncertainty on the high side’ for promotions to be modeled independently from the true sales expectation so as not to bias the forecast, especially for promotions
- Account for periods where inventory is planned to be unavailable at store level (e.g. sales forecast for a discontinued item should continue while the item is in stock and drop to zero when it’s projected to run out in the future)
The rule here is simple: if the item at a location is selling (no matter how slowly or for how long) it must have a sales forecast and that sales forecast must be an unbiased and reasonable representation of what future sales will look like.
A simulation of future product movements driven by the forecasts and future planned changes to the physical world means that:
- Replenishment and ordering constraints are respected in the plan (e.g. rounding up to case packs if that’s how product ships, rounding at lane level if truckload minimums across all products on a lane are required)
- Activity calendars are respected (e.g. an arrival of stock is not scheduled when a location is not open for receiving, a shipment is not scheduled during known future shutdown)
- Carryover targets are respected for seasonal items (e.g. before the season even begins, the planning logic suppresses shipments at the end of the season so as to intentionally run out of stock at the stores and DCs)
- Future changes to stocking requirements (e.g. changing the number of facings for an item or adding/subtracting it from the store assortment) are known in advance and the effect is visible in the plan on the future day when it will take effect
- Future changes to network and sourcing relationships (e.g. changing a group of stores to be served by a different DC starting 2 months from now) are known in advance and the effect is visible in the plan on the future day when it will take effect
- Future price changes (whether temporary or permanent) are known in advance and the effect is visible in the plan on the future day when it will take effect
- Pre-distributions of promotional stock are scheduled in advance to allow display setup time ahead of the sale
- Except in rare cases, the creation and release of orders or stock transfers at any location is a fully automated, administrative ‘non event’ that requires no human intervention
Here it can be tempting to take shortcuts that seem ‘easier’:
- ‘We don’t bother forecasting or planning slow moving items at store level. We just wait for a reorder point to trigger.’
- ‘For items we only buy once from a vendor, we just manually buy it into the DC and push it all out to the stores.’
- ‘We know our inventory isn’t very accurate for some items at store level, so we just get the store to order those items manually based on a visual review of available stock.’
In order to have a valid simulation of reality that supports higher levels of planning beyond immediate replenishment (see next section below), you need a system and process that can model these things in a way that is representative of what is actually going to happen.
If an item/location is selling/sellable, then it must have a forecast for those sales.
There is actually no such thing as ‘push’ in retail (unless you are able to ‘push’ product into a customer’s cart against their will and get them to pay for it).
Rollups of the elemental data to support aggregate planning in the future means:
- You can do proper capacity planning with a complete view of the future because a common process is being used at the elemental level, cube/weight data is accurate and so-called shortcuts are not being taken at the elemental level
- S&OP is possible because the elemental plans are complete, have future pricing changes applied – instead of looking in the mirror with ‘budget vs actual’, senior leaders and decision makers can look through the windshield and compare ‘budget vs operational plan‘
While all of these elements that define ‘valid simulation of reality’ may seem intuitive and reasonable, it doesn’t stop some people from saying things like:
- ‘A lot of items, especially slow movers, can’t be forecasted, so the whole idea kinda falls apart right there.’
- ‘That’s a great theory, but it’s actually not possible to use a pull-based system for every item.’
- ‘Just because of sheer volume, it’s impossible to manage every product at every location in this way.’
Again, as mentioned previously, a single process framework that can be used for all possible scenarios is actually much simpler to implement and maintain over the long run.
Plus, well… it’s already been done, which kinda deflates the whole ‘it’s impossible’ argument.