Any large scale SAP transformation projects will evolve over a period of time, due to the nature of business, it may not be feasible to replace existing legacy application with likewise products from SAP product portfolio.
The following are possible phases involves in any large scale SAP implementations.
- AS-IS : Transactional application & DW runs on non-SAP software / platform
2. Interim State: Identify mission legacy critical applications needs transitioned to SAP platform (Billing, FI-CA, Metering, Work and Asset Management) – This step is considered as first step in the total journey. Run legacy and SAP transactional applications in parallel for a stipulated time till all remaining Legacy application move to SAP platform in the scope.
3. End State (Co- existence of SAP & non-SAP transactional systems) – Continue to run few non-SAP applications where SAP portfolio does not offer like for like products such SCADA (Supervisory control and data acquisition), DMS (Distribution Management System) and OMS (Outage Management System).
Due to the transition of source transactional applications, down stream dependency such reporting applications / solution also need to be remediate to meet enterprise reports exists in Legacy reporting system. Customers often seek answers for the following to overcome this issue:
- What will happen to the reports post SAP transformation, but still required data from SAP applications.
- Data migration / remediation approach from reporting perspective
- The best way to produce consolidated reports on SAP & non-SAP data
- Is data flow or feed should be unidirectional / bi-directional (from legacy to SAP / SAP to legacy)
- How reporting users interpret SAP data in Legacy reporting applications (reports on SAP & non-SAP based applications)
I would like to summarise my experience on this front to help customers / consultants who is intends to migrate from non-SAP reporting platforms to SAP. This blog is intended to outline scenarios one may come across while proposing enterprise reporting solution in SAP BI or similar technologies.
It is inevitable to have more than one reporting application / solution to meet reporting needs of various business units. This is primarily due to the reporting requirements of each business units differs in principle. For e.g: Finance & Controlling BO reporting requirements not alike with Work and Asset Management.
This may have led to finding various means to cater their individual reporting needs and resulted in having multiple heterogeneous reporting applications / solution. This is an additional complexity in the large scale transformation projects to propose an enterprise reporting solution.
Back ground: Any Utility business involves in maintaining a complex system architecture simply due to nature of business needs. The range of applications including GIS, SCADA, DMS, OMS, Metering, Billing, FI-CA, Customer Services, Work and Asset management etc. Each application intended to perform a set activities for e.g: Control room activities to monitor network, distribution and crew availability etc. In a large scale transformation project, it is still possible to maintain some of non-SAP applications to meet day-to-day operations along with existing reporting application as well.
During the platform transformation (a use case) if customer decides to transform some of existing Legacy applications which supports Work And Asset Management and Billing, Metering, Customer Service with SAP software components. The remainder applications are still continue to operate as-is and feed to the current reporting application (legacy reporting solution).
Due to the complexity of the nature of the topic, only data migration and history reporting, consolidated reporting will be elaborated further in this blog:
Data migration: Data data data… what to do with the legacy data which differs from SAP data in terms of schema, model, granularity and business entities etc. It is well known that legacy transactional application schema / data model differs from SAP transactional applications thus reporting as well. Data migration is very vital part of any successful reporting solution implementation as most of the reports in Enterprise data warehouse should cater needs of regulatory, audit, enterprise wide KPI’s. Further the number of years of data within the migration scope also help reporting users to perform data mining / predictive analysis then gain insights to prevent or respond to a predicted event. For e.g: Impact of storm on network and customer base help to plan crew requirements and better incident management.
However data migration approach from transactional application needs should be different from reporting application. As transaction application also need a magnitude of data migration from current legacy transactional applications but all not entire data in scope of data migration. As this may lead to sub-optimal performance of SAP transactional applications, in general a quantum of data is migrated into SAP.
The remainder data in legacy transactional application and reporting applications also need to be preserved to support Legal , audit trails. Just to keep focused on reporting this blog only covers data migration approaches from legacy reporting application to SAP reporting solution.
Scenario 1: Data Virtualisation (from Legacy to SAP DW)
- Single point of access for all reports (SAP, Non-SAP & consolidated reporting)
- Minimal data migration efforts
- No data adulteration between the layers
- Optimal performance / SAP investments justified
- No transformations and physical movement between the applications
- Legacy DW and SAP BW runs in parallel
- Need to data feed to current legacy reporting application
- Opex cost for maintaining both legacy and SAP reporting solutions
Scenario 2 : Data migration from Legacy DW to SAP DW (BW on HANA or BW/4 HANA)
This approach involves in physical migration of the data from legacy DW to SAP DW. As underlying data models and schemas in legacy transactional applications differs from SAP S/4 HANA, data transformations needed to merge both data sets. This approach requires data staging layer (untouched data replica of legacy DW) and transformation layer (transformed data) to unite with data originates from S/4 HANA or ERP.
- Single point of reports access
- Replica of legacy data in SAP DW
- Better performance compared with scenario 1
- Continue feed from Legacy DW to SAP BW
- DB sizing evolves at high rates (as SAP DW has both SAP and non-SAP data)
Scenario 3: Schema re-mapping / accessing Legacy DW in BO layer.
This approach supersedes both options highlighted in this blog. By using SAP BO IDT data from SAP and non-SAP DW can be merged in the run time without any data persistence. As SAP BI BO suite capable of merging data in Universe, this option is very cost effective and sustainable.
The following are Pros and Cons involved in this approach:
- No ETL involved hence no additional cost associated for development
- Virtual access minimises data redundancy in SAP DW
- Universe level data security
- Less development efforts when compared with other approaches
- No single DW to offer Enterprise DW reporting needs
- Limited ability to support complex transformations
Scenario 4: Retrofit SAP data into Legacy DW to support consolidated reporting.
This approach involves in retracting the data from SAP transactional applications into legacy data warehouse. As SAP S/4 HANA SAP data model differs from current legacy transactional applications, there is a need for transforming SAP data before merging into legacy application data (history reports). SAP BODS (ODP-API) facilitates to load data from SAP ABAP objects such SAP CDS views, SAP Standard and custom extractors, SAP transactional tables into target legacy DW application.
- Enterprise data is available in existing DW wherein users are acquainted with reporting objects
- May form stepping stone for Enterprise wide Operational Data Store (ODS)
- Plug in plug out options will help to easily integrate with 3rd tool for data analysis
- Huge development efforts to create ETL jobs
- Requires through knowledge on S/4 HANA data models
Conclusion : Each and every option outlined here is viable however reporting complexity, project budget & timelines and Enterprise BI road map must be taken into consideration before choose a suitable option to meet individual estate needs.
Note: Author has profound knowledge & experience in implementing green fields reporting solutions (SAP BI Analytics) for major utility customers in United Kingdom and Australia. This blog is to outline approaches to overcome reporting issues purely based on his personal experience may not cater individual needs.