Skip to Content
Personal Insights

Analytics in Retail – SAP Retail Architectur

Welcome back to another blog post about Analytics@Retail. For those who want to get on track: https://blogs.sap.com/2020/01/08/analytics-in-retail-a-short-introduction/

In my last post, I tried to extract the main differences of transactional versus analytical information. With that knowledge in mind we finally are able to understand the actual SAP Retail Landscape. But let’s start from scratch:

What makes Retail so special?

That’s easy to answer: Everybody knows about Retail from his/her daily life: Making purchase decisions and buying stuff – that is something accompanying us from childhood to old age.

As a consequence, purchase transactions happen all over the world, every single day. And there it is: THE word “transaction”. Now, if you have read my last blog post, the term ERP or S/4 HANA should come in your mind as the leading system for transactional information. However, there are two other important facts: “Every single day  and all over the world“. Imagine how many point of sale (POS) transactions happen in a typical supermarket during the day! And now you got the hidden answer of what makes Retail so special: Big data! Since the beginning of digital data collection, Retail is – and will be –  a big data industry.

However, ERP is (or was?) not build for huge data amounts. Imagine your business “heart beat” having a “heart attack” due to too many data floating the system! As a consequence, SAP’s first POS  solution was build on top of SAP Business Warehouse (SAP BW). SAP BW has been designed to handle huge data volumes. The SAP POS Data Management (SAP POS DM) application was used to receive, audit, process and analyze transactional data from stores.

Since ERP is your leading operational system it was updated by transferring aggregated data on a regular base (the end of the business-day was a very common time for that). The transfer of aggregated information reduces data volume, improves performance and saves time.

 

 

Thus, in the beginning, SAP POS DM was sitting on top of SAP BW and after a few hours data were ready for reporting within SAP BW and ERP was updated regularly with aggregated data (mostly end of the day).

What happened next?

SAP HANA was born, a new era of performance. Suddenly, real-time information was possible. As a consequence, SAP invented and launched a new product – SAP Customer Activity Repository (SAP CAR). The idea of SAP CAR was being able to collect real time data:

“SAP Customer Activity Repository is a foundation that collects transactional data that was previously spread over multiple independent applications in diverse formats. The repository provides a common foundation and a harmonized multichannel transaction data model for all consuming applications.”

As a logical consequence, POS moved from SAP BW to SAP CAR known as POS Data Transfer and Audit (POS DTA). Suddenly real-time reporting became possible for POS data.

 

 

Coming back to analytics – we now have an additional data bucket in the enterprise system landscape. And with that new data bucket, we do have new possibilities for reporting. The key here is real-time reporting! ( Accuracy depends on the frequency of the POS trickle feed into SAP CAR (roughly 7-15 min).

This blog post has not the intention to describe SAP CAR in detail. Instead of this, I would like to concentrate on the Retail Architecture and its understanding. Please read here, in case you would like to know more details about SAP CAR.

After having learned a bit about SAP CAR , the first question crossing my mind was: “Do we still need SAP BW?”

To make it short: Of course, we still need SAP BW. Let me give you an example why:

SAP CAR includes functionality that allows you to achieve a near real-time view on inventory in your business. This means, you will know the inventory of a particular product in a particular store as it is right now. But: you don’t know about the past. 1 hour in the past, or 2 days in the past, are unknown. That is an information you will get out of SAP BW! And here you can see the two different characters of the systems again: SAP BW gives you everything important for strategical decision making while SAP CAR helps you to understand your current operational business.

And since the topic is inventory, just another side effect to mention: Inventory is a non-cumulative key figure. Means 10 pcs in stock every day of the week does not mean 7*10 pcs = 70 pcs in stock per week. It’s still 10 pcs.

In SAP BW handling of such KPI’s has been improved the last decades. As a result, it is quite easy to query non-cumulative key figures. And with SAP BW on HANA or SAP BW/4HANA you can mix up the best of both worlds (HANA and BW). Within SAP CAR, the virtual data model is mainly done via HANA native views. (Depending on the application you will also find embedded BW functionality and ABAP CDS views, but by far the biggest ratio is based on virtual data models realized by HANA views.)

(Short remark: Of course few historical inventory information will also be available in SAP CAR, but not with the same completeness and logic SAP BW is offering!)

 

Again, coming back to analytics and the next important point: The growth of e-commerce over the last decade is affecting retailers and with it, the need to transform their strategies from multichannel to omnichannel. In the SAP Retail Architecture this need is addressed by SAP C/4 HANA Suite (including SAP Commerce Cloud) combined with SAP Qualtrics Digital CX. The idea and the need is clear: Supporting a cross-channel strategy to enable Retailers to improve their user experience and help them to drive a better relationship with their customers across points of contact.

 

But what does this mean for analytics of today?

The backbone of SAP’s Retail Architecture consist of 4 data buckets. Each data bucket is full of valuable informations which should be brought together to have the full picture of a Retailers business.

 

 

Having said that, we directly understand the challenge: data are spread over 4 data buckets and each data bucket is using different backend technologies:

Each system has good reasons to work with different back-end technologies.

Remember that in the transactional case, you do not want to risk your data base functionality gets lost du to e.g. an out of memory situation. That’s why SAP S/4HANA uses ABAP CDS views to guarantee an ABAP driven guidance.

In SAP BW/4HANA you want to combine the best of two worlds in so called mixed scenarios by using BW functionality and HANA native possibilities.

In SAP Customer Activity Repository real time is the key and this is guaranteed by using HANA native functionalities.

SAP Commerce Cloud and SAP Qualtrics Digital CX are using diverse cloud technologies.

As a result we have to deal with different technologies to bring the valuable data asset together for Analytics. This leads to two challenges “knowing which data bucket to use when” and “finding people having a broad technology knowledge”.

Fortunately, SAP has a strong analytics strategy by offering a holistic approach to combine data base, data management  and analytics cloud solutions within  SAP HANA Cloud Services.

In my next blog posts, I will have a deeper look into the different components of SAP HANA Cloud Services and how they can support you within your analytical journey.

 

Let me end with a quote:

“It is our purpose to give the data superpower to every business and every professional”

SAP HANA & ANALYTICS Product Vision & Strategy

 

 

Regards and stay curious,

Nicole

#build bridges, not silos

4 Comments
You must be Logged on to comment or reply to a post.
  • There seem to be several factual mistakes in this blog. POS DM was originally developed “on top” of SAP BW as you write but was separated from BW long before SAP CAR was introduced. The ability to support trickle feeds in POS DM was perfectly possible and I have personally done this at large multinational companies with a trickle feed frequency from their 5000+ stores of 5 minutes. Data was then aggregated continuously through-out the day and passed to BW as often as we wanted.

    I think it also misleading to refer to anything in this flow as real-time – at best you could call it near-real-time. Typically even with a frequency of  minutes for updates I would never describe the data as showing the “current” inventory in a store and you would need to be very careful using it that context e.g. for store stock status. The best you can hope for is an RSI (rough stock indicator) indicating the likelihood that a customer might find an item in stock .

    • Hi Niall,

      ok, you are concentrating on POS only and you would like to discuss in this context the word real-time. That’s fair and I would think, that my hint of real-time with the trickle -feed dependencies clears that point exactly. And yes, maybe, the wording near-real time would be the better one for that single process. But to be honest, I don’t get the difference in what you are writing and my wording.

      I didn’t mention trickle feed for POS DM , true ! I haven’t seen the need there. In general the aggregation process after the trickle feed took more time in the BW world. And yes, some customers did the aggregation several times over the day and some waited till the end of the day.

      But to be honest, the intention of this blog post is not to discuss every possibility in detail of POS or CAR or any of the data buckets.

      Fact is, that most of the people struggle to get the right data connected due to the fact, that we are living a silo world from the beginning. A customer want to understand CAR? Then he needs to look for a resource knowing about POS DTA, another one for UDF, another one for Planning, another one for PMR , another one for AMR ….not to mention OAA (with RSI possibility), Inventory visibility, the whole Multichannel Concept (which was not available before CAR), OSA and so on.

      You might know a lot about POS and surely much more than I do, but again, that’s not the point here. I tried to answer why an architecture looks the way it looks like today and where you should start the search for the data you need.

      Kind regards

      Nicole