Questions and Answers

Questions

Did you know that most, if not all, organizations and innovations started with a question, or series of questions?

Reed Hastings concocted Netflix by asking a simple question to himself…”what if DVD’s could be rented through a subscription-type service, so no one ever had to pay late fees?” (Rumor was that this was just after he’d been hit with a $40 late fee).

Apple Computer was forged by Woz and Jobs asking, “Why aren’t computers small enough for people to have them in their homes and offices?”

In the 1940’s, the Polaroid instant camera was conceived based on the question of a three year old. Edwin H. Land’s daughter grew impatient after her father had taken a photo and asked, “Why do we have to wait for the picture, Daddy?”

Harvard child psychologist Dr. Paul Harris estimated that between the ages of two to five, a child asks about 40,000 questions. Yup, forty thousand!

Questions are pretty important. They lead to thinking, reflection, discovery and sometimes breakthrough ideas and businesses.

The problem is that we’re not five years old anymore and, as a result, we just don’t seem to ask enough questions – especially the “why” and “what if” kinds of questions. We should.

Turns out our quest for answers and solutions would be much better served by questions. To demonstrate the power of questions, let’s consider the evolution of solutions to develop a forward looking, time-phased forecast of consumer demand by item/store.

Early solutions realized that at item/store level a significant number of products sold at a very slow rate. Using just that items sales history, at that store, made it difficult to determine a selling pattern – how the forecasted demand would happen over the calendar year.

To solve this dilemma, many of the leading solutions used the concept of the “law of large numbers” – whereby they could aggregate a number of similar products into a grouping of those products to determine a sales pattern.

I won’t bore you with the details, but that is essentially the essence behind the thinking that, for the /store, the forecast pattern would need to be derived from a higher level forecast and then each individual store forecast would be that stores contribution to the forecast, spread across time using the higher level forecast’s selling pattern.

It’s the standard approach used by many solutions, one who’s even labelled it as multi-level . Most retail clients who are developing a time-phased forecast at item/store are using this approach.

Although the approach does produce a time-phased item/store forecast, it has glaring and significant problems – most notably in terms of complexity, manageability and reasonableness of using the same selling pattern for a product across a number of stores.

To help you understand, consider a can of pork and beans at a grocery retailer. At what level of aggregation would you pick so that the aggregate selling pattern could be used in every store for that product? If you think about it for a while, you’ll understand that two stores even with a few miles of each other could easily have very different selling patterns. Using the same pattern to spread each stores forecast would yield erroneous and poor results. And, in practice, they do.
Not only that, but you need to manage many different levels of a system calculated forecast and ensuring that these multi-level forecasts are synchronized amongst each level – which requires more system processing. Trying to determine the appropriate levels to forecast in order to account for the myriad of challenges has also been a big problem – which has tended to make the resulting implementations more complex.

As an example, for most of these implementations, it’s not uncommon to have 3 or more forecasting levels to “help” determine a selling pattern for the item/store. Adding to the issue is that as the multi-level implementation becomes more complex, it’s harder for planners to understand and manage.

Suffice it to say, this approach has not worked well. It’s taken a questioner, at heart, to figure out a better, simpler and more effective way.

Instead of the conventional wisdom, much like our 3 year old above, he asked some simple questions…

“What if I calculated a rolling, annual forecast first?” “Couldn’t I then spread that forecast into the weekly/daily selling pattern?”

As it turns out, he was right.

Then, another question…

“Why do I have to create a higher level forecast to determine a pattern?” Couldn’t I just aggregate sales history for like items, in the same store, to determine the selling pattern?”

Turns out, he could.

Finally, a last question…

“Couldn’t I then multiple the annual forecast by the selling pattern to get my time-phased, item/store forecast?”

Yes, indeed he could.

Now, the solution he developed also included some very simple and special thinking around slow selling items and using a varying time period to forecast them – fast sellers in weekly periods, slower sellers monthly and even slower sellers in quarterly or semi-annual periods.

The questions he asked himself were around the ideas of “Why does every item, at the retail store, need to be forecast in weekly time periods?”

Given the very slow rate of sales for most item/stores the answer is they don’t and shouldn’t.

The solution described above was arrived at by asking questions. It works beautifully and if you’re interested in learning more and perhaps asking a few questions of your own, you know how to find me.

So, if you’re a retailer and are using the complicated, hard-to-manage, multi-level forecasting approach outlined above, perhaps you should ask a question or two as well…

1. “Why are we doing it like this?”
2. “Who is using the new approach and how’s it working?”

They’re great questions and, as you now know, questions will lead you to the answers!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>