One of the promisses of S/4HANA is that analytics is integrated into the [S/4HANA] applications to bring analyses (insights) and the potentially resulting actions closely together. The HANA technology provides the prerequisites as it allows to easily handle “OLTP and OLAP workloads”. The latter is sometimes translated into a statement that data warehouses would become obsolete in the light of S/4HANA. However, the actual translation should read “I don’t have to offload data anymore from my application into a data warehouse in order to analyse that data in an operational (isolated) context.”.  The fundamental thing here is that analytics is not restricted to pure operational analytics. This blog elaborates that difference.

To put it simple: a business application manages a business process. Just take the Amazon website: it’s an application that handles Amazon’s order process. It allows to create, change, read orders. Those orders are stored in a database. A complex business (i.e. an enterprise) has many such business processes, thus many apps that support those processes. Even though some apps share a database – like in SAP’s Business Suite or S/4HANA – there is usually multiple databases involved to run a modern enterprise:

  • Simply take a company’s email server which is part of a communications process. The emails, the address book, the traffic logs etc sit in a database and consitute valuable data for analysis.
  • Take a company’s webserver: it’s a simple app that manages access to information of products, services and other company assets. The clickstream tracked in log files constitutes a form of (non-transactional) database.
  • Cash points (till, check-outs) in a retail or grocery store form part of the billing process and write to the billing database.
  • Some business processes incorporate data from 3rd parties like partners, suppliers or market research companies meaning that their databases get incorporated too.

The list can be easily extended when considering traditional processes (order, shipping, billing, logistics, …) and all the big data scenarios that arise on a daily base; see here for a sample. The latter add to the list of new, additional databases and, thus, potential data sources to be analysed. From all of that, it becomes obvious that not all of those applications will be hosted within S/4HANA. It is even unlikely that all the underlying data is physically stored within one single database. It is quite probable that it needs to be brought either physically or, at least, logically to one single place in order to be analysed. That single place hosts the analytic processing environment, i.e. some engines that apply semantics to the data.

Now, whatever the processing environment is (HANA, Hadoop, Exadata, BLU, Watson, …) and whatever technical power it provides, there is one fundamental fact: if the data to be processed is not consistent, meaning harmonised and clean, then the results of the analyses will be poor. “Garbage in – garbage out” applies here. Even if all originating data sources are consistent and clean, then the union of their data is unlikely to be consistent. It starts with non-matching material codes, country IDs or customer numbers, stretches to noisy sensor data and goes up to DB clocks (whose values are materialised in timestamps) that are not in sync – simply look at Google’s efforts to tackle that problem.

In summary: while analytics in S/4HANA is operational, there is 2 facts that make non-operational (i.e. beyond a single, isolated business process) and strategical analyses challenging:

  1. It is likely that enterprise data sits in more than 1 system.
  2. Data that originates from various systems is probably not clean and consistent when being combined.

A popular choice to tackle that challenge is a data warehouse. It has the fundamental task to expose the enterprise data in a harmonised and consistent way (“single version of the truth”). This can be done by physically copying data into a single DB to then transform, cleanse, harmonise the data there. It can also be done by exposing data in a logical way via views that comprise code to transform, cleanse, harmonise the data (federation). Both approaches do the same thing, simply at different moments in time: before or during query execution. But, both approaches do cleanse and harmonise. There is no way around. So, either physical or logical data warehousing is a task that does not go away. Operational analytics in S/4HANA cannot and does not intend to replace the strategical, multi-systems analytics of a physical or logical data warehouse. This should not be confused by the fact that they can leverage the same technical assets, e.g. HANA.

On purpose, this blog has been neutral to the underlying product or approach used for data warehousing. This avoids that technical product features are mixed up with general tasks. In a subsequent blog, I will tackle the relationship between S/4HANA and BW-on-HANA.

You can follow me on Twitter via @tfxz.

To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Johannes Lombard

    Great blog Thomas.

    It puts operational reporting back where it belongs, embedded with the processes. and Fiori will be a great skill to acquire. Modeling and / or the process of relating data still needs to occur for Advanced Analytics.

    The days of obtaining BI adoption through pre-defined canned reports in DW is gone. The future is about [1] easy to create operational reporting with great graphics, [2] some pre-defined reporting, as well as [3] allowing true self-service analysis against these so-called data lakes. Options 2 and 3 need modeling.

    Johannes

    @lombardjohannes

    (0) 
  2. Dinesh Anblazahan

    Very Good Blog Thomas,

      You have articulated very well,as you pointed out very precisely the Term Analytics has been mis understood totally in the recent past and people are replacing the term warehouse  with Analytics. Since users are used to do analysis only in Warehouse system  earlier they think warehouse means Analytics.

    Now wih HANA in place you can do analysis even in the transcational system so they think if you can do analysis in transcational system then we dont need Warehouse,

    but they are forgetting the fact that the warehosue system not only used only for data analysis but also for data consolidation and cleansing…

    Hope your blog reaches many people and clears their confusion and sends right message.

    Thanks & Regards

      A.Dinesh

    (0) 
  3. Carlos Eduardo España Orellana

    Dear Thomas

    And also for dear sap friends!

    In early 70’s and 80’s the systems were mainly operational, that results in RDBMS and ERPs that focused on “write” and store operational information (sales, purchases, payments, inventory, and so on).

    Nearly 2000, arrive the new “analytical” systems , that include as an innovation a “datawarehouse” with cubes, star models and a new approach to store and analyze information , in order to consolidate, measure by KPIs and make more flexible historical and predictive analysis.

    Now with HANA, we have a new path and possibilities, to extend all those systems in order to harmonize the “operational” (tactical) and “srategic” (long term) analysis.

    Hana enables to enhance time, effort and make possible some analysis of the operational information that were to difficult to do in the past. But I also believe, that this “operational” information that can be analyzed throgh Hana, can make a new database of facts in order to join different processes and make possible a “strategy” and long term analysis through the building of real time applications that feed “desicion making” processes.

    What I am trying to say, is that all the operational and analytical processes (OLTP and OLAP) are useful to build new models of analysis and also new processes to enhance and understand in a more fast way “what has happened, and what will happen” in an enterprise today. All this tools and systems are intended to “innovate” the way we think and make things, in order to be better. Regards! Carlos España.

    (0) 
  4. Johnny Muñoz

    Hi Thomas,

    In the medium-term maybe short-term, the SAP BW will disappear, because actually in HANA is possible to make ETL extraction from any datasource and the analytical report will be made by the HANA own analytical tools or any other software reporting, much friendlier than the framework of SAP BW.

    SAP S4 HANA now is Multi-Tenancy and allow work with third-party applications on HANA DB.

    Regards,

    Johnny

    (0) 
    1. Philipp Nell

      Hi Johnny,

      What are the alternatives and why are they better ? Could you briefly describe the base of your thoughts ? That would be very interesting, especially your thoughts re HANA only analysis.

      Cheers, Philipp

      (0) 
      1. Johnny Muñoz

        Hi Philips,

        The main tools are SAP HANA Live and SAP HANA PAL. SAP has not developed new cubes or SAP BW reports. All efforts are aimed at generating analytical views from SAP HANA. Additionally, all this can be combined with external data sources, and all this in real time.

        Regards,

        Johnny

        (0) 
        1. Philipp Nell

          Hi Johnny,

          For some aspects in operational reporting your proposal might be right, but HANA Live is not meant for reporting on a consolidating and centralized environment consisting of data from different sources, incl. nonSAP. (HANA live uses the source tables, replicated or not, of ECC so you would need to integrate external data there). In addition I would check, if all analytical requirements can be really computed on the fly as proposed by you. Did you consider this in your reply ?

          In addition, please check out the new info provider types like Composite provider, Open ODS View and Advanced DSO. They are all new in BW (starting mostly  with 7.4). Even the Business Content has been and is being adapted/enhanced to HANA based technologies to make use of it. Hence I can’t follow you in that point either.

          Please let me know if I misunderstood a point.

          Cheers, Philipp

          (0) 
  5. Michael Thuma

    SAP BW is not a data warehouse. That’s BW/BI’s biggest advantage. 🙂

    It’s no good idea to cleanse data on the BW/BI server. Wrong data is simply wrong.

    You can expand BW/BI’s horizon if you give up the idea of master data. Once we built a HR BWI which does away with the need of having to cope with time dependencies.Master data is simply deleted reloaded within the scope required and master data is added to transactional data while the Infobjects master data simply does present ‘logistics’ like master data in order to navigate the cube. Time of BW3/3.5. Today all that can be provided in a more flexible fashion and this practice is common sense and should be fully understood.

    The only thing you cannot do an a BW is a PSA that receives pushed information and decides that data sent is correct. In practice you need to replicate ‘all’ the master data and finally will come to the same conclusion. You can of course use data retrieved from other systems to improve the quality. I personally decided in the rare cases left (production line data for example) to cleanse the messages received and after having prepared the bulk to load simply notify the BW that the data is here.

    Being in the position to store incorrect data is good. Legal restriction for example. Data provided as of 1st of the month in HR.

    You don’t loose the advantage of simply being in the position to provide meta information that allows to simply click together data loads/staging and just take the information while moving data forward without reading from tables that are not visible to those who have to follow the data-loads.

    HANA is amazing indeed. From what I have seen, never enjoyed the pleasure to work with it, it’s  a dream come true. There are several things in the past we had to work around using analysis server but agreed not in the 97% of data origin from SAP sources. Count dimensions and such things. I personally move such ‘ODS’ (in the traditional sense) data via push to all reporting structures. If there is no change no impact. That’s what databases are about. Every load should be possible at any time. That requires to eliminate procedures that read or spoof other parts of the staging anyway. The staging should not be dependent on business semantics. I know such loads. You cannot load because the data from that part of the staging does not represent the state required or lookup if a certain ID is in place and then … that’s nuts. Implicit knowledge is never a good idea. That knowledge is easier to express in the PSA/ODS in a relational DB doing the cleansing. A thin layer that helps.

    Example you have planning data and get 2 versions via flatfile. People implemented amazing logic. The solution was then a file diff 🙂 and a fistfull of records was left instead of 200k. The PSA is should be a flexible animal.

    (0) 
  6. Joao Sousa

    The point is that we won’t be forced to to operational reporting in a datawarehouse which is most of the use BW gets these days.

    Sure there are situations were ETL will still be required especially in a company with a complex business landscape where S4/HANA is just another system, but for many companies that do mostly operational reporting over ERP data, BW won’t be needed anymore.

    (0) 
    1. Philipp Nell

      Hi Joao,

      I would check out the Embedded BW approach as described in this blog. Gives you a lot of infrastructure for managing and implementing reporting related stuff which otherwise you would need to re-implement by yourself. 

      Cheers, Philipp

      (0) 
  7. David Shoemaker

    Thomas,

    It would be enlightening to know what percentage of BW installed bandwidth is actually used for operational reporting vs. true analytics. I have only experiential data from many projects, and it indicates that customers are very focused on operational reporting. BW, like any IT product, is ultimately funded by the business, not IT, and the business is still using the BW for operations. If this usage drops out via S4HANA, it is not a certainty that BW will survive. Your point that BW can survive due to its’ ability to absorb multiple sources is not supported by the fact that HANA can do this also. BW is almost never used for data cleansing, as stated by other posts above. I thank you for the post, but, I have some reservations about your argument.  I truly do hope I am wrong.

    (0) 
    1. Thomas Zurek Post author

      David,

      this blog is not about BW – as explicitely mentioned. Let me ask you the following question: there is many customers that have a hand-crafted DW built on some RDBMS and they load data from SAP ERP, CRM, SCM, … into that DW. They use ETL tools like Data Services, Informatica, MS Integration Services. Now, with the advent of S/4HANA and operational reporting being available inside S/4HANA in real-time: will those customers continue to load data from the SAP systems into their DW? Or will those data flows become obsolete? Or will those DWs even become obsolete?

      Regarding the usage of BW: it is difficult to say how much it is used for operational reporting and how much as a DW. I see both cases and mostly the case of a DW with many sources connected. Also, there is a grey zone between operational and cross-system analytics. Therefore it’s sometimes not easy to categorise. Anyway. Is BW dying? Well, for an allegedly dying product the adoption is pretty flourishing. To me, this is not surprising.

      Thomas

      (0) 

Leave a Reply