Next Generation DSRs - An Analytic name is not enough

You need not always build your analytic tools, sometimes you should buy in. If the chosen application does what you need that often makes good economic sense... as long as you know what you are buying.

Let's be clear, an Analytic name does NOT mean there are any real Analytics under the hood.

For many managers, Analytics is akin to magic. They do not know how an analytics application works in a meaningful way and have no real interest in knowing. At the same time, there is no business standard for what makes up "forecasting", "inventory optimization", "cluster analysis", "pricing analysis", "shopper analytics", "like products" or even (my favorite) "optimization".  Don't buy a lemon!

Next-Generation DSRs (multi-retailer)

This post continues my look at the Next Generation DSR.  Demand Signal Repositories collect, clean,  report-on and analyze Point of Sale data to help CPGs drive increased revenues and reduce costs.

Most CPG implementations of a DSR support just one retailer's POS data.  OK before someone get's back to me with "but we have multiple retailers' POS data in our system", I'll clarify:

• Having Walmart and Sam's Club data in the same DSR does not count (as the data comes from the same single source, RetailLink) and I bet you are still limited as to what you can report on across them.
• If you have multiple-retailer's POS data set up in isolated databases using the same front-end... it does not count
• If you have the data in the same database but without common data standards ... it does not count.
• If you have the data in the same database but with no way to run analysis or reports across multiple retailers at once... it does not count.

So, yes, a number of CPGs have DSRs that support multi-retailer POS data sources, very, very few (if any?) have integrated that data into a single database with common data standards so they can report and analyze across multiple POS sources at the same time.

Does it matter?  I think so, multi-retailer ability opens up big opportunities around promotional-effectiveness,  assortment planning, supply-chain forecasting (demand sensing) and ease of use.

Clustering with a destination in mind

I've posted before on Cluster Analysis, in an attempt to demystify one of the more accessible and useful analytical approaches for CPG/Retail teams (see Cluster Analysis - 101) .

Finding groups of similar stores (for example) can be a very effective way to manage the complexity of offering each store group what they really need without having to deal with each one individually, a mammoth task.   Whether you are looking to find groups of stores, shoppers, regions, products or even sales patterns a very similar approach can work for you.

Clustering is part of the journey it's not a destination.  If you don't know and understand what decisions your analytic work should enable  (your destination) how can you build a good model?