Many companies are now on the verge of implementing or migrating to S/4 HANA, and with SAP advertising the significant benefits of using their in-built analytics capability, one of the most pressing questions is ‘what should I do with my existing analytics investments? Can you just throw them out – or are they still of use?
In this blog, we will touch on what we see as the analytics capability of S/4, what it can and should be used for, and what this means for your existing capability.
S/4 HANA is the successor to SAP’s traditional Enterprise Resource Management Suite and is billed as a simplified version designed to work with SAP HANA. It offers an integrated transactional and analytics data platform called Embedded Analytics.
The main intent of Embedded Analytics in S/4 HANA is operational reporting, aimed at providing the necessary information for business users that will enable them to perform their day to day operations. For example, this might be a list of incoming sales orders, inventory levels, or purchase order items.
To be effective, operational reporting will require real time information. S/4 HANA promises to do this with the following enhancements:
The number of tables is significantly reduced in S/4 HANA system resulting in simplified data structures.
It is built on the in-memory platform SAP HANA, which has proven capabilities performing complex analysis on real time data.
A unified security setup across both the transactional and analytics platform.
S/4 HANA Embedded Analytics is part of the overall S/4 HANA capability and does not require separate licenses and installation.
FEATURES OF EMBEDDED ANALYTICS
Unlike native HANA, where HANA Live or calculation views form the basis of reporting, ABAP CDS views are used for reporting in S/4 HANA. These are also virtual data models (VDMs) that are built on top of physical tables, however are delivered through the ABAP application server. These CDS views are the core component of Embedded Analytics, providing standard content that can be further enriched by the customer. These VDMs can then be consumed through different user interfaces to suit different types of access and user profiles.
Let’s now look at few of the standard reporting tools that S/4 HANA offers. All these tools come with S/4 HANA installation and do not require any separate licenses.
For end users or users who want to quickly analyse real time data, S/4 HANA provides the following tools:
SMART BUSINESS COCKPIT
The Smart Business Cockpit was introduced with Suite on HANA and is provided with S/4 HANA as well. It provides a landing page to view all the key KPI’s that are relevant to the user and can be seen at a glance. For example, an accounts receivable manager in an organisation could quickly monitor multiple KPI’s like sales outstanding, overdue receivables, future receivables, collection progress etc.
MULTI-DIMENSIONAL REPORTS
This tool is basically a reporting client embedded into the S/4 HANA Fiori Front end, providing the logical detailed next step from your Smart Business Cockpit. It allows users to display reports using different graphs and visualisations, filter data or drill down for further analysis. For example, a procurement manager could use this to display open purchase order items, to investigate something of interest from his top level KPI’s. They can use various visualisations to display or filter data to display it for a particular supplier, purchasing organisation, material or plant.
QUERY BROWSER
The Query Browser is a Fiori App that allows you to search and execute specific analytical queries that the user is authorized to view. Custom ABAP CDS views would be visible here, if the user has relevant authorisations.
For advanced users or users who would need more access than just displaying the data, S/4 HANA provides the following tools :
QUERY DESIGNER
The Query Designer is a Fiori App that allows you to create and manage analytics queries. The queries can be built on top of standard or custom CDS views. The Query Designer enables you to manage the creation of analytical queries and make the results available through tiles in the Smart Business Cockpit or for Multi-Dimensional Reporting. The user has the benefit of selecting the attributes and measures needed without actually having to open or modify ABAP CDS views.
KPI MODELLER
The KPI Modeller is the design tool for deploying tiles within the Smart Business Cockpit. It is used to add new KPI Tiles, to apply display settings such as colour coding, and to add drill-downs. Again, the data source for these KPI’s would be existing ABAP CDS Views.
Developers who would want to develop their own views or extend existing views, will have to use ABAP for Eclipse. For a user to produce their own CDS Views, they should have experience in programming and handling data-modelling within the HANA environment. ABAP for eclipse is an additional ABAP Workbench that has to be installed on HANA Studio/Eclipse.
Apart from this, the CDS views also seamlessly integrate to other SAP Analytical offerings, such as Business Objects, Lumira and SAP Analytics Cloud. This means that there is no data load or ETL processes, with data able to be consumed in real time through these tools. However, utilising these other tools would require a separate license.
With all these offerings, the end user now has access to operational data which changes in real time as the transactions go through the system all “live” at the “point of decision”. The user doesn’t have to wait for complex process chains or for data to replicate to another platform to get the status of business.
SHOULD WE MIGRATE ALL EXISTING CONTENT TO S/4?
Now, if we consider a typical organisation that currently runs an analytics capability on HANA, it will have several reports running on HANA Live or custom graphical calculation views. The usual setup for such an organisation would be Business suite/ERP System for transactional processing and a side-car HANA database (or BW system) for operational reporting. Due to the use of separate systems, security roles would have to be created separately in each environment. With S/4 HANA this security issue is solved, as the same system facilitates both transactional and operational reporting.
However, migrating these existing HANA Live/calculation views to S/4 HANA system needs additional work to re-develop them using ABAP CDS. Similarly, if an organisation has several reports running on BW models, migrating these models to S/4 would mean significant effort in terms of re-developing them in ABAP CDS.
So, should we go ahead and migrate to make full use of S/4’s capabilities?
It is important to understand the nature of reporting before making this decision. If the main purpose of your report is operational, i.e. it is meant to help your business users or operations team with their day to day activities such as monitoring incoming sales orders or purchase order items, the reporting is most probably already available to use when you migrate to S/4. It would be as simple as setting up the system and having your reports ready. If not, a developer can make this type of information available easily by developing a custom ABAP CDS view.
When you develop a view using ABAP CDS, you can use all the standard reporting tools that S/4 offers as mentioned above. However, one thing to be cautious of at present is that since Embedded Analytics is a fairly new feature provided by SAP, there is limited online help, blogs or best practices available. The content may also not be fully matured and will probably evolve further with future releases. It may be a good idea to proceed with caution and test out the capability over time, rather than trying to fully replace your existing solutions in one go.
Now if the requirement is more complex in nature, such as merging data from multiple sources, handling IoT data, or running predictive scenarios, we believe it will not be a good idea to migrate such a model to S/4.
In S/4, the analytics platform is basically querying the transactional system in real time for every query we fire. Before generating any report, it is important to consider factors like the number of users, the volume of data and complexity of processing compared to the sizing of your HANA system. You would need to ensure that the transactional system (and users carrying out critical transactions on that system) are not impacted in any way.
Below are a few example scenarios where S/4 may not be the ideal platform to use for reporting:
Consolidating data from other sources – it is unlikely that all the data you need to meet your broader analytics requirement will sit in S/4. In many cases you might need to consolidate data from other SAP and Non-SAP sources, likely merging and transforming this data in the process. In such scenarios we would recommend thinking very carefully about bringing additional data into S/4. Generally, if you are only landing this data for analytics reasons you would not want this to consume the resources of your transactional system.
Computing big data or predictive scenarios – When dealing with IoT scenarios or predictive scenarios, usually the volume of data used is very high and it has to go through complex transformations. This creates a risk of a large chunk of S/4’s memory being blocked to run such models.
Historical analysis – Instead of reporting on the current state of an object, such as current open sales orders by product category, if we are trying to report on the revenue for each product category for the last 10 years compared with yearly growth, we are potentially accessing large volumes of data and performing a complex query on the data base at the same time. This could be a costly operation which again risks consuming valuable resources on your transactional system. There is also the risk that some of this data would expect to be archived over time out of S/4 memory.
Hosting archived data that may no longer be available within S/4 system – As hinted at above, use cases where you have to retain extra data above what is required in a transactional system just for the purpose of reporting, is potentially not the best use of expensive resources for an in-memory system.
Managing and reporting slow moving dimensions – Slow moving dimensions are when you wish to capture the changing data within the dimension over time. For example, a customer’s status, address or segment. Many details can change over the course of customer’s life, and instead of only reporting information on the current state of a customer you may wish to report on these aspects at the time of the transaction. The ability to effectively model these relationships and provide a time-dependent join to query this at run-time creates extra complexity and resource consumption that is generally not best placed on the transactional system.
For all these scenarios, there is likely a better alternative to providing a holistic analytics capability within your organisation. While S/4 may provide base real-time operational reporting capability, there will be a requirement for other more traditional reporting and historical analysis, as well as a need for innovation over larger datasets with more complex techniques. Assessing exactly how much of your existing capability could be addressed by S/4 will likely be specific to each organisation – however this should be something that is identified and addressed as part of your data and analytics strategy, before the rollout of S/4.
Leaving the analytics capabilities as an afterthought to your S/4 implementation, or incorrectly assuming that it will replace your existing BW or HANA sidecar, could lead to some significant buyers’ regret.