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,
#build bridges, not silos