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.

So, why are we not doing this already?

From a historical perspective, you can track most DSR's back to starting out with a particular retailer's data and supporting CPG sales-teams for that retailer.  The sales-team were the folks with the checkbook and they were not very interested in what the system could do with any other retailer's data.  DSR solutions are still often sold to individual sales-teams which is why CPGs support numerous DSR implementations.

Can these solutions support multiple-retailers - yes - sort of - maybe - probably not.  The key issues to resolve are data-volume, data-standardization, localization and security.

Data Volume

From my previous post (Next-Generation DSRs - data handling) I was stressing how circa 2010 technology was struggling to handle the volume and velocity of data involved in a DSR.  And that was with single retailer solutions.  Newer database applications gives us the capability to maintain or improve performance while handling substantially more data  through columnar, massively parallel and in-memory technology.  I fully acknowledge I may be missing a few ideas on that list, it doesn't matter - the point being that a 10 fold increase in data volume is no longer something to be worried about,  Trade up  to new technology and you can handle it.  

Data Standardization

This is dull, really dull, it's right up there with Data Cleansing (boring, painful, tedious and very, very important).  There is no standard for what data a retailer chooses to share with their CPG suppliers.   There is overlap, yes of course, but no actual standards.  They will:

• call the same facts (e.g. point of sale units) by different names.
• report facts in different time buckets (weekly, daily)
• report facts that are 100% unique to a particular retailer (some of which may be useful)
• have similar but (subtly different) meanings for what appears to be the same fact
• not provide key facts that seem essential (like on-hand inventory at stores)

And through all this you are trying to find enough common ground to generate reports and analytics that work across retailers.  I can hear the cries now of "but Retailer-X is completely unique, that won't work for us".  Ignoring for the moment the impossibility of degrees of "unique-ness", they are wrong, this really can be done.  All retailers sell, order, hold inventory and promote (to list but a few things).  What is common between data sources is huge, but it takes real discipline to find the commonality wherever it exists and map it to a single data-structure for reporting/analytic purposes.  And when you do find something unique, that's ok:  map it to a new fact, store it and wait.  Perhaps it's only unique because you haven't seen it in another retailer's data feed... yet.

Bottom line - It's dull (I did warn you about that right?) but it can be done.

Localization

When I'm generating a report for retailer X, they call the Point of Sale revenue fact 'POS Sales', retailer Y calls it 'Point of Sale $', retailer Z calls it 'POS Revenue'.  Internally, and when reporting across multiple retailers,  we call it just 'POS'.  How can we support this?

I've coded custom solutions for this before, it's not that hard, but it strikes me that this is just another example of "language" and if we can have the same application work in English, German, Italian, Spanish and Russian, how hard should it be to translate between variations on the same language.

Security

Is Retailer X allowed to see data from Retailer-Y - no way !  Are the Retailer-X sales-team allowed to see Retailer-Y point of sale data - very probably not.  Are my sales folks allowed to see any competitor sales data provided to category managers  - nope.  Do I want the sales-team to see the profit margin on the products they sell?  (This sounds sensible, but actually some CPGs do not want this.  I guess, if they don't know, they can't tell the customer).

These are all issues with DSR's as they stand today and are all resolved already with solid user account management.  If this process is done well, security is not a problem.  If the processes around security management are sloppy, it's already a problem.  Adding more data into the system really doesn't make a difference one way or another.

Bottom line

If a DSR was designed from scratch to support multiple retailers, it would have one single data model and all new data sources get mapped to this single model.

Localization means that the same report for Retailer-X and Retailer-Y is shown with their own naming preferences.

Security controls who is allowed to see what.

And what's in it for you ?

• You now have the ability to rapidly leverage learnings (in the form of new analytics and reports) across all retailers and sales teams.
• As team members move from one sales-team to another they do not need to learn a new system or even necessarily, a new "langauge".
• You get to maintain, develop, learn and train against  just one system
• And the really big pay-off is that you can now start to run value-added analytics that require access to multiple retailer's POS data .   Think about significantly enhanced promotional-effectiveness,  assortment planning and supply-chain forecasting (demand sensing)  More on this very soon.