10 reasons why the strategic enterprise architect will include BW/4 in their S/4 programme

Introduction

One of the key benefits of S/4 over ECC is the quantum shift in reporting capability. This is made possible through the delivery of the virtual data model and analytic Fiori apps which, together, comprise Embedded Analytics.  The availability of Embedded Analytics has led some enterprise architects to conclude that a data warehouse is an unnecessary expense and have hung their reporting strategy on S/4 alone.

In this article, I will cover typical requirements which show that S/4 is not a panacea, that the data warehouse (whether it be BW/4 HANA, Datasphere or something else) is still a valid component of the landscape, and that the wider reporting requirements should be considered in the overall architecture from the outset – not introduced as an afterthought.

1      No S/4 is an Island

Arguably the three common processes in all organisations are Finance, purchasing and HR. Whilst a programme might start with just S/4, a theoretical modern SAP-centric landscape might easily comprise the following systems:  S/4 HANA, SuccessFactors Employee Central, Employee Central Payroll, Concur, Ariba, Fieldglass and many others, including non-SAP systems.

Efficiency of the individual processes is enhanced by these best-of-breed tools but the data that their transactions generate needs to be brought together and blended for high level managerial reporting and analysis.  Suddenly, reporting out of S/4 becomes a bit more problematic as, to do this reporting, one would need to start loading the relevant data to it and perform the necessary harmonization and transformation within it.

Include data from any other functional and line of business systems and the argument for a purpose-built data warehouse becomes compelling.

Alternatives such as replicating data across the landscape and data federation bring a host of challenges; loss of one source of the truth, sub-optimal performance and loss of agility to name but a few.

2      Additional Historical Data

Data take-on for an S/4 project is a major consideration.  Ideally, only data that is absolutely necessary will be loaded into the transaction system.  This might be open documents, current fiscal year or, at a stretch, current fiscal year plus one. 

On the reporting side of things, current versus previous year comparisons are a given, however, there are many KPIs which only become meaningful over considerably longer periods of time.  The information spanning multiple historic years has no place in the transaction processor.  The data warehouse supports the loading of summarized historical data and blending it virtually with the latest information loaded at transaction level from S/4, or other source systems. 

3      Reduce Load on the Transaction Processing Systems

The original function of the data warehouse is to take the ‘heavy lifting’ from the transaction processor and move it to an environment which is technically orientated towards rapid mass-processing of data.  The HANA database underpinning S/4 supports very fast reporting, however, in the data warehouse much of the work is done during ETL.  Even in S/4, memory consumption and CPU can still be a significant resource bottleneck.  At no point should transaction processing be jeopardized by reporting activity.  This fundamental purpose is still valid today, especially when reporting on long-term data, cross-application functions or where complex calculations or look-ups are required.

4      Secure Your Data… but Make It Available

Data security has never been more important. High profile data breaches result in negative corporate publicity and/or significant fines through legislation such as GDPR. 

A federated data approach relies on each source system performing its own checks at runtime. This means managing different technology and different underlying data sets.  This, in turn, means more moving parts to coordinate during access provision.  The risk of incorrect or partial access being granted is significantly higher, as is the administrative overhead.

By bringing the data into a data warehouse, the authorisation concept becomes simple and transparent. The models and the access to them is all contained and controlled in one system with one technological basis. The authorisation concept in SAP data warehouses allows separation of the query permissions from the data permissions allowing the same data to be reused by multiple different user groups.

5      Enable Archiving

Archiving is not something that generally gets thought about at the start of any project, however, at some point it is likely to become necessary.  A data warehouse enables archiving without compromising critical reporting. The benefits of archiving include:

5.1   Reduce the Overall Data Footprint

It seems counter-intuitive that a data warehouse will reduce the overall data footprint, however, S/4 transactions typically reference many tables (and table columns) that are useful only for the period that the transaction is active.  By extracting the useful information and archiving old documents a data warehouse can reduce the overall footprint.

5.2   Lower the Cost of Long Term Data Storage

Data warehousing concepts such as dynamic data tiering and near-line storage allow an organisation to store information long after it would be useful in the transaction processing system.  The data is still available for reporting, but the storage cost reflects how regularly it needs to be accessed. Whilst it is theoretically possible to utilise this functionality in S/4, the organisation and partitioning of data warehouse objects makes this much more practical to achieve.  Typically, in S/4, transactions must be reloaded from the archive before the data in them becomes available.

6      Bring Planning and Reporting Together

BPC, for example, is an excellent, mature and well understood planning solution whose latest edition comes embedded inside BW/4.  Implementing BPC provides the significant advantage that plan data can be reported on in situ alongside near real-time actuals information.

As of Q3 2024, it will be possible to store SAC plan data in Datasphere conferring the same advantages.

Separating reporting and planning into different systems is, in my mind, a major mistake. It inevitably results in competition between the two systems.  More and more reporting moves to the planning solution resulting in two sets of the same data and a loss of one source of the truth.  There is an associated rise in the total cost of ownership as two teams grow and battle it out to deliver the same information.

7      Support Time Dependent Reporting and Snapshots

Multiple iterations and views of data are often required.  Examples of these are as follows:

7.1   Multiple Versions of Forecasts

The data warehouse is the ideal place to create and store versions of data without impacting your transaction processor.  This is especially true if the planning is being done as an embedded function.

It is not unusual to have 13 versions of a given plan type for one year (the budget, plus twelve, monthly snapshots). The volumes associated with this can be significant.

Historical months in forecast versions are typically filled with 'actuals' numbers.  Clever modelling capabilities allow these periods to be provided virtually rather than needing to persist the same information in multiple versions reducing storage costs further.

There is often more pressure to reduce disk space on the transaction processor, so the shelf-life of the versions is likely to be shorter in this environment.  The benefits of keeping versions for extended periods are not always immediately obvious, however, this data can often be valuable.  Having ready access to an old forecast allowed one previous client to support an insurance claim of significant proportions.

7.2   As Is and As Was Reporting

Different reporting perspectives are needed when the sales representative for a customer changes mid-year.  The current sales rep wants to see the history for that customer to make appropriate sales pitches.  They also need to see what their personal sales were across their current and previous customers so that they can achieve their targets.  There are many examples of where this dual view of data is required, and data warehouses are inherently designed to support this. This is particularly complicated where hierarchies are involved.

7.3   Point-In-Time Positions

Whilst real or near-time data is the demand of many requirements, there are many situations where the opposite is desired:  Weekly snapshots of open positions to reveal the changing blend of that picture. Frozen HR or finance positions to support requests for more information on publicly published top-line figures, and where the total of the follow-up details are expected to match the original headline numbers.  S/4 is not the place to store this information.

8      Break Down Silos - Datamarting

The data that is collected into a data warehouse is typically enterprise data from shared service systems supporting core functions.  There may be many parts to the business which perform different functions (line of business) and have their own needs of this data.  Multiple interfaces to multiple systems using different technology is expensive, both in creation and support.  A data warehouse as a centralised data hub provides the opportunity to connect to the source systems once, collect and transform the data once and to make it available from one source to the downstream consumers using a consistent approach.

9      Prevent Rework

Failing to plan the business intelligence strategy and incorporation of reporting requirements at the outset can result in many negative outcomes:

·         Reports being built in the transaction processor which later have to be moved to the data warehouse.

·         Failure to build functionality into business processes in S/4 that is necessary to support report requirements.

·         Fundamental overhauls in report provision as more systems come online.

10    Improve Business Continuity

Where it is understood that system outages will be required for upgrades and project go-lives, one approach to mitigate the business impact is to keep the data warehouse up for planning and reporting whilst the transaction systems are maintained. A data warehouse provides flexibility.

Bonus Reason – Business Content

This is particularly true for BW/4 which was designed and developed as the stablemate to S/4.  Here, much of the business logic is built into the solution so there is a huge amount of reporting capability ready out-of-the-box.  This simplifies design, encourages best practices, and reduces the delivery time.

Conclusion

A number of use cases for the data warehouse have been put forward.  Many of these will not be obvious or priorities at the outset of any programme. Having to cater for them later in the project will generate rework and add time and cost. 

With SAP’s 2027 deadline for ECC support looming, many organizations are about to set out on their own transformation.  Hopefully, this article will support architects in their decisions regarding their target system landscape and persuade them that the data warehouse is an essential component from the outset.

Do contact me or see our website: https://www.nac-it.com/ for more information.