Welcome back to my blog post about Analytics in Retail.

(For those who missed the first blog post, click here: https://blogs.sap.com/2020/01/08/analytics-in-retail-a-short-introduction/)

Today I would like to summarise a few basics about the words “transactional” and “analytical” and how they are linked to a SAP Retail architecture. On my daily job, I could experience, that it is worth to talk about this.

Since the beginning, people in Retail are split into those who know about ERP and those who know about  Business Warehouse. That’s understandable since for a long time, those were the two most important systems in Retail. However today, everybody knows that there are far more systems a Retailer has to rule to dominate the business.

Unfortunately, the mindset has not really changed. People think either “transactional” or “analytical” . And the worst: most of the people aren’t aware of this fact. (Or should I say, aren’t aware of this “other” world at all?)

So let’s try to understand, what the words “transactional” and “analytical” means.

SAP started 1972 with the Vision to develop Standard application software for real-time data processing.  Since then, SAP was well known as a leader in Enterprise Resource Planning (ERP) software. I suppose in that time, the wording “transaction” became one of the most popular words in the SAP world.

Transactional data became the key of success in on-going business operations. Different business areas could be linked in one system – such as sales, order management, purchasing, etc – sharing a common data set. As a result, key business processes has been automated and the key system requirement was reliability despite a high number of daily transactions fulfilled by users.

Let’s think of a purchase order as an example of a transaction: A purchase order contains data like material, quantity, delivery date, vendor information and some more. And there is one important point: It is a person entering, controlling and saving data in this transaction. Thus, the data amount is low enough to be handled by a human being.

With that in mind, I want tho highlight the nature of a transactional system:

Now it is easy to understand, that such a system needs an engine designed for those facts. The term Online Transactional Processing (OLTP)  should come into your mind right now.

I always try to compare such things with examples of my daily life. In that case I’m figuring the ERP software as my car:  It enables me to drive and react of different situation by knowing about some important key figures (velocity, mileage, petrol gauge,…). However if my strategy is to save fuel, I need the possibility to learn from the past to find out the best gear for a given velocity. But even if the  strategy is to have as much fun as possible while drifting with your CAR on a layer of snow, you need the possibility to collect and analyse data in order to understand how to fulfil this strategy.

Now you should recognise, why a Business Warehouse is useful. While an ERP software gives you the ability to empower your daily business, you also need the possibility to get an overview of: What is going on? What happened in the past ? And what could be in the future? That is when the Business Warehouse with its analytical possibilities comes into the game. It helps to fulfil the business strategy.

With that in mind, let’s summarise the needs of an analytical business system.

For doing Analytics, the data warehouse is used to collect all digital data available in the enterprise landscape. Thus current and historical data are available in on repository. The goal is to provide a consolidated view of enterprise data for reporting to enable decision-making and planning. Compared to a transactional system, less users need high sophisticated reports in their daily business. But every single report is reading a hugh data amount which should be handled in an appropriate time. Thus, performance is a key fact for analytical systems.

The corresponding engine should fulfil those facts and again another term  “Online Analytical Processing (OLAP)” should come to mind now.

Now, after having understood the  differences of transactional and analytical backend systems, let’s have a look to SAP’s User Interfaces. And again, there are those two different worlds which has to be match by a fitting front-end solutions: SAP Fiori and SAP Analytics Cloud.

With SAP Fiori, a user is guided through his daily tasks (transactions) he has to master.

SAP Analytics Cloud is an all-in-one cloud platform for business intelligence, planning, and predictive analytics.

And again, each UI serves his corresponding personality: SAP Fiori for transactional Processes and SAP Analytics Cloud for analytical processes.

Now you could say:” But there are also analytical tiles available for SAP Fiori?” That’s true and of course, this makes sense. There is sometimes a need for analytical information also in a transactional environment. But analytical functionality has his limits within SAP FIORI.

There is so much more to write about it. And due to the fact that hardware and software evolves more and more, this hardline between transactional and analytical is getting softer or is even merging. SAP HANA is able to handle OLTP and OLAP together. However, I hope you got the difference between transactional and analytical information, since based on that I will continue in my next blog post.

https://blogs.sap.com/2020/07/01/analytics-in-retail-sap-retail-architectur/

Regards and stay curious,

Nicole

#build bridges, not silos