Central Finance Tips and Tricks #4 - Keys to Success

[MarcE]

Having recently completed a successful go-live of a Central Finance implementation, I found some time to reflect and share key points to help others achieve the same successful outcome.

1) Get the right resource mix

Central Finance implementations require a broad range of skill sets.  Having the right skills available is critical for ensuring the success of a project. Having full time business process and subject matter experts cannot be underestimated. These roles should provide significant input into the requirements and shape the business outcomes that Central Finance will deliver. In terms of IS teams tasked with delivering central finance, below are some key roles that we had in place.

Role	Description
Project Manager	This role speaks for itself
Central Finance Business Architect	Responsible as the interface between the business stakeholders Drives the S/4 HANA Finance roadmap and value proposition Conducts blueprint workshops and provides guidance on S/4 HANA finance functionality to accounting standards.
Central Finance Solution Architect	Conducts blueprint workshops and provides guidance on S/4 HANA and Central Finance. Lead for the delivery of the central finance core build, SLT and changes in source systems. Lead for functional and technical knowledge of S/4 HANA Finance and Central Finance, including limitations, initial load, replication and mapping.
Technical Solution Architect	Responsible to lead sizing activity and system installations
Technical Deployment Manager	Leads the technical implementation on source systems, SLT, and manages regression testing for these. Manages the deployments and transition through environments.
FICO Consultants	Deliver the core build of the Central Finance system, having MDG knowledge and S/4 HANA Finance knowledge is beneficial.
Technical Specialists	Developers with FICO experience and skill sets covering ABAP, MDG, SLT. Responsible to deliver enhancements for customer specific requirements.

2) Prepare for technical system readiness

Before you embark on a Central Finance journey one of the first steps is to get a working landscape. Typically, this would be a sandbox environment for on premise customers or cloud systems. A hybrid landscape is also possible where on premise can connect to cloud S/4 HANA solutions. Whatever model is chosen the key is to first evaluate the current S/4 HANA technical releases available in the roadmap viewer.

For real time replication, the DMIS add-on is required to be installed on source, central and the SLT server. For those standing up new instances of S/4 HANA as the Central System my recommendation is to install the latest version and support pack (yes, the latest, not your traditional support pack - 1). For customers with source systems that are on older ECC releases expect to implement hundreds of notes to enable Central Finance functionality.

Once the technical changes are identified they must be implemented, tested and moved through the environments. Regression testing is important to execute with notes technically changing core Finance functionality.

3) SAP Launchpad is your best friend

The maturity of S/4 HANA Finance and Central Finance as a deployment option are still relatively new. This means that you need to plan a strategy to monitor and implement SAP notes and a regular basis during a project life cycle. Get familiar with the SAP launchpad and put in place a process to monitor updated and new notes, implement and test them.

4) Understand the limitations of the Central Finance solution

There are many standard limitations with Central Finance, however some can be overcome with customer solutions. Here I outline some of the known limitations:

• The initial load does not contain the same level of detailed information available with real time replication. An example is sales invoices from the SD module. At the time of billing raw data is captured in the source system CFIN staging tables, this data contains dimensions such as the sales order, sales conditions along with corresponding amounts. This detail is transferred to central finance and can be used for derivation, mapping etc. In contrast, the initial load simply extracts data already posted to the Finance module on the source system, and in many cases the data is aggregated at GL account level.


• The replication of fixed asset postings is not supported. In other words, it is not possible to set up a fixed asset sub-subledger on the central system and replicate asset postings from the asset sub-ledger from a source system. All asset postings are simply posted to a GL account on Central Finance and the asset number, sub-numbers are lost.


• Like the previous asset point, an inventory sub-ledger is not supported. Material movement transactions posted in the source system will post into a GL account on Central Finance.


• Not all Controlling business transaction type are supported. Note 2320298 explains the supported business transactions. In real world terms, this means that some processes that run on source systems, such as COPA top down distribution will not replicate and need to be executed separately on Central Finance.


• Settlement rules on orders or WBS elements are not replicated to Central Finance


• Costing to Account Based COPA is not officially supported. Customer projects will have to close the gap with their own enhancements. One key area to address is the generation of COPA information for cost of goods sold postings occurring on source systems that are only set up with costing based COPA. In standard costing based setups, no COPA segment is generated.


• Logistics, material and sales documents such as purchase orders, purchase requests, sales orders, sales invoices and material documents are not replicated to Central Finance. Only the resulting accounting or controlling documents from processes off the back of these types of documents are replicated.


• Document splitting is not officially supported in a Central Finance scenario when the source system does not have document splitting activated. Customer specific solutions are necessary to ensure that splitting design is robust and can handle different business scenarios, especially important when dealing with multiple SAP source systems with differing business processes and configuration. Extra time for analysis, design and testing must be planned for in cases where document splitting is necessary.


• The third party (external) interface for non-SAP systems does not support clearings. It is not possible to transfer invoices and subsequently clear them via the interface.

• Read SAP note 2184567 - Central Finance: Frequently Asked Questions for details on some of these and many other limitations.

 5) Test replication using Production systems connected to a test central finance system

Connecting Production source systems to a Pre-Production Central Finance system is recommended in the admin guide. This is an extremely useful testing approach. I cannot think of many other examples where so much test data is generated for so little effort. This approach decreases the testing effort and gives the project team means to:

1. reset and delete data on central finance in case changes are necessary to core configuration e.g. document splitting


2. the ability for month end processes to be completed and comparisons made to existing reporting solutions prior to the solution being productively deployed


3. provide some statistics on expected number of AIF errors encountered to help size and train support teams

6) Understand the tools available for fixing replication errors

For real time replication, many tools are available for handling errors. The most powerful is using AIF emergency correction mode but there are also other tools available. Knowing what to use and when is crucial for teams managing Central Finance operations. Refer to some information I put together in the blog Central Finance Tips and Tricks #3 – Understand the Utility Programs

7) Keep a running sheet or replication handbook of errors faced and how they were resolved

From conception - in the early prototype stages right through to productive solutions - keeping a record of what errors were faced and how they were resolved will save many moments of “I am sure I have had that error before?”. The sheer number of errors encountered, especially in the early stages of a project can be enormous. Recording key information will go a long way to saving time and provide vital information for sharing within project teams and for teams managing business as usual processes. Example data that should be recorded:

• Real time or Initial load


• Message Class


• Message Number


• Area (Configuration, Code, Master Data etc)


• Error Message


• Cause


• Resolution


• Any follow up actions needed such as restart of AIF messages

😎 Early engagement of partners to plan sizing

The sizing of SLT and the S/4 systems are important to get right. Can SLT handle the load that will be placed on it? How big S/4 will grow and how fast? Do you need to factor in planning and consolidation processes on S/4 in addition to the Universal Journal growth? There are many factors to consider when performing a sizing exercise and this should be one of the first pieces of work undertaken.

9) Have a well-defined catalogue of key replication regression testing scripts

Following on from my point about system readiness and applying the latest notes on a regular basis, defining key business scenarios to test with central finance is imperative. These tests, or at least a sub-set should be ready to run once notes or bug fixes are applied.

10) Lock down your Universal Journal data model early

Define the data model and key fields you will use for operational processes and reporting early. Doing so will provide clarity on what activities, such as enhancements and reporting build, need to be factored into the plan. Removing fields from the Universal Journal (including COPA) can be time consuming and error prone, defining coding block extensions and COPA fields in a system with no transactional data is much more appealing.

11) Limit the scope of the initial load

It is possible to load detailed documents from a source system as far back as you like. However, this carries additional effort to:

• Ensure mappings of historical data is available on Central Finance. Decisions will need to be made, do you want to set up and map blocked customers, cost centres, profit centres, vendors, GL accounts, cost elements etc? How much reconciliation will be done to source systems, will adjustments be posted directly on Central Finance in case of misalignments?


• The extraction and load times could be significant. Extracting data from systems with millions of records will likely result in long run times.

My recommendation is simply - reduce the initial load documents extracting period and get into real time replication as soon as possible. Only then will you get the rich raw information into Central Finance due to the initial load limitation (see the point on limitations mentioned above).