There are many benefits to SAP S/4HANA for existing SAP customers. However there is the inevitable challenge of migrating and upgrading existing systems. Especially in a complex legacy landscape this can be a risky and costly endeavour. In this post I will explore the benefits and challenges of using “Central Finance” as a stepping stone to an S/4 HANA implementation.
S/4HANA in brief
SAP is in the process of releasing components of S/4HANA for customers. Simple Finance is the first functional component with Simple Logistics expected in the near future. The vision behind this new tool is that SAP has re-engineered their business application suite to take full advantage of the performance benefits of the HANA database. This enables a tool that works more truly in “real time” and integrates operational reporting with business process. The main architectural difference is a radical simplification of the data base structures removing aggregates. This reduces the database footprint; but more importantly allows “HANA Live” reports to function in real-time. Enabling real-time reporting in the core finance applications can bring significant benefits in decision making and reduce the time for long running processes e.g. month end closing. For more information on the background to S/4HANA, there's a great FAQ by John Appleby.
SAP S/4HANA also needs to be on customer’s radar as it is the strategic replacement for SAP R/3 and ECC; at some point in the future support for the older products will begin to wane and so a clear roadmap is needed in the medium term.
SAP Central Finance
One element of the SAP S/4HANA story that has been exciting interest amongst clients is “Central Finance” (previously known as central journal).
Central Finance is not a new product from SAP; nor does it really provide functionality that was previously unavailable, but it can be seen as an approach to adopting SAP S/4HANA. The approach, instead of forcing customers to migrate to the SAP HANA Database and the S/4 application, allows finance documents to be replicated into a new Central Finance instance that running on S/4HANA. This is particularly relevant in an organisation where there are multiple older SAP ERP instances or other Finance applications outside of SAP.
The story goes like this: “Central Finance” exploits SAP HANA’s real-time capabilities to replicate financial documents into the central instance as they are posted, giving a real time organisation-wide finance view. There is minimal impact to the underlying source systems which are Central processing (e.g. cross system allocations and intercompany reconciliation) can be immediately moved to the central instance achieving immediate benefits, but further functionality can then be migrated piece by piece into the central instance: credit control, and outgoing payments would be good early candidates, because of the potential financial benefits of consolidating these activities. Eventually all finance functionality can be moved into the central instance and the source financial systems turned off. This presents a lower risk approach to migrating to S/4 HANA at least from older source platforms.
Technically the Central Finance approach exploits SLT (SAP Landscape Transformation Replication Server) to replicate appropriately filtered accounting documents from any source system: SAP or otherwise, into a central S/4 HANA environment. Configuration in the Central finance instance controls error handling through a suspense account. Master data, which needs to be kept in line between the source systems and the central finance instance is handled with master data governance (MDG) set up between the underlying and central systems.
Central Finance approach - challenges
From a business perspective there is a challenge around how to justify the additional cost associated with a central finance approach. The additional cost is associated with the fact that there will be two systems running to reflect financial transactions rather than a single one. This means that for a period of time it is necessary to maintain and support both legacy and new central finance system.
The central finance system will be running on SAP HANA, so the license uplift will already have been incurred before existing systems and hardware are decommissioned. This cost needs to be weighed against the benefits of the transparency of having financials in a single location and the risk mitigation associated with the gradual upgrade to S/4 HANA functionality. The business case therefore has to be carefully weighed.
Many of the IT benefits of moving to SAP S/4 HANA are associated with the smaller footprint that comes from removing aggregate tables. For this reason, the business case associated with a central finance migration should rely more heavily on business benefits rather than cost reductions in IT; see “SAP S/4HANA – which business users have the most to gain” by Mark Chalfen for some ideas for the business benefits case: (http://www.bluefinsolutions.com/blogs/mark-chalfen/march-2015/sap-s-4hana-which-business-users-have-the-most-t).
There are additional challenges to adopting central finance though.
As well as continued maintenance on the central finance system and the source systems; a number of other components are necessary; including the SLT server which is best hosted on a separate instance, as well as associated updates to the source systems. These include installing data replication components at the technical level, but also a number of functional level upgrades. Whilst SAP argues that the impact on source systems is “minimal”, a number of SAP notes need to be imported into the source systems in order to allow documents to be replicated from source to target. If all source systems are on recent releases and support packs are up to date then this shouldn’t be a challenge, but if not there are can be a large number of dependencies. This can quickly lead to a situation where source systems will need to be comprehensively regression tested adding cost and risk to the project.
There is a need for a capability to be build in the SLT server. This is relatively straightforward and should be absorbed into the existing BASIS provider, but further competence in Master Data Governance (MDG) must also be built, both technical and from a business perspective. This is a great opportunity to address a common weakness in master data in the organisation, but it has to be seen as part of the programme – if the mappings in MDG are tacked on as an afterthought there is a risk that benefits will not be achieved.
Architectural concern on the central finance approach
It moves away from the ideal of a single source of truth. Financial statements could in theory be drawn up in one of two locations either in the source systems or in the central finance system. If financial statements are drawn up from the source systems potentially the outcome of allocations or reconciliations performed in the central system need to be passed back into the source systems. If statements are derived from the central systems, the system of record may have changed, and in this case integration to consolidation systems may also need to change.
Central Finance represents an intriguing route to ERP system consolidation and migration to SAP S/4HANA at low risk. It delivers benefits throughout the project, however the devil is in the detail and the following items should be clearly addressed:
- Business case clearly balancing the cost of working in multiple systems against the benefits
- Budget for patching and regression testing source systems
- Clear Master Data Governance Strategy and capability plan
- Architectural and integration plan for the consolidated solution.
The Central Finance route won’t be for everyone, but in cases where an over-complex SAP estate exists on a variety of source versions, it may prove to be the most effective mechanism to generate some of the benefits of SAP S/4 HANA at an early stage, while (eventually) simplifying the overall estate.