SAP S/4HANA and key risk management components and considerations

Introduction

The increasing wealth of information is one of today’s key challenges for a company. Recent surveys show that powerful intelligence is vital for successful companies. Applying this intelligence will enable companies to assess new markets, improve performance and reshape the enterprise’s strategic business needs.

To respond to the trend of so called ‘digital enterprises’, SAP has developed in recent years a complete new SAP platform called SAP S/4HANA. SAP S/4HANA is positioned as the digital core of the ‘digital enterprise’ and the strategic way forward for organizations with an existing SAP landscape. SAP S/4HANA will become the de facto standard in the upcoming years as the current SAP systems will run out of support. The main question therefore is not ‘if’, but ‘when’ and ‘how’ the move to SAP S/4HANA takes place.

SAP S/4HANA will form the new SAP core for the coming decades. It aims to respond to the challenges of organizations by providing 1) improved reporting functionality (agility and speed), and 2) enhanced process efficiency (e.g. a more rapid monthly closing process, improved user experience). The performance provided by the in-memory HANA database combined with the enhanced user experience (called Fiori), provides organizations with an improved way of doing business: it is now possible to combine analyses of real-time data with transactional processing on device-independent apps.

The S/4HANA Finance module is part of SAP S/4HANA and is the latest solution for the CFO office. It provides support in several finance areas as part of an integrated ERP environment: financial planning and analysis, accounting and period close, treasury and financial risk management, collaborative finance operations and enterprise risk and compliance management. Apart from the functional benefits it also requires 3) less maintenance and development due to a simplified data model, and 4) your IT landscape is primed for planned SAP innovations.

In order to fully leverage these benefits, more than just a technical solution is needed. Although SAP provides the IT elements for the solution, it is up to the organizations to prepare and organize the department and processes in such a way that the new functionality is fully utilized. For example, organizational strategy cascades into reporting requirements, which in turn should be determining factors in the design of the financial administration; processes should be standardized, harmonized and free of all superfluous complexity.

This article provides insights into key risk management components and considerations for the SAP Business Suite on HANA migration projects and SAP S/4HANA migration projects.

In this article, when talking about SAP S/4HANA, we focus on the on-premise solution of S/4HANA Finance, based on the experience gained by the authors.

SAP S/4HANA risk management

As companies using SAP need to move sooner or later to SAP S/4HANA, there will be many SAP (re)implementation programs started. These SAP programs have the reputation of being challenging, as many programs are not delivering the expected value or are not completed within time and budget. It is therefore very important that mature risk management procedures are in place as this will help to ensure early identification and appropriate mitigation of project risks. Typical examples of risk management activities are:

• Program Governance and Risks. Providing updates on risks and issues identified during assessments of the process, performance and deliverables associated with program/project governance. Conducting risk workshops with the various stakeholders involved to have an integrated overview of all the risks. Reviewing formally defined go-live go/no-go criteria and the plans to establish Operational Readiness pre go-live before the hand-over to operations.
• Business Processes and Testing. Determining whether the testing approach covers the validation of the current business processes, including the current application controls to support complete and accurate financial reporting after go-live. Topics to specifically focus on are whether the new functionalities offered by SAP S/4HANA are considered and implemented in the new ways of working. Examples are the new GR/IR cockpit, new HANA transactions, new reporting capabilities etc.
• HANA Infrastructure. New technology and hardware need to be in place within the data centers to be able to operate the new SAP S/4HANA systems. It is important to provide feedback on the mechanisms in place to achieve compliance, control and security over the new or updated data centers; the SAP landscape infrastructure service model and the specific HANA architecture.
• Data Migration and Reconciliation. Many organizations have a defragmented SAP landscape. These organizations are using SAP S/4HANA to also consolidate and simplify their landscape. This results in complex migration projects which makes it important to assess data migration related risks. Examples are assessing the data migration software tools and the controls critical for data integrity, e.g. data and object consistency and completeness, which are implemented to mitigate both financial and operational risks. Monitor data migration and reconciliation procedures. Understand proposed housekeeping activities and make recommendations as necessary. Re-perform a selection of reports relevant for financial statement audit purposes.
• General IT Controls. SAP S/4HANA introduces new technology and operating procedures and it is therefore important to assess general IT controls. Backup and restore processes are changed, change management processes are impacted by the faster SAP release strategy and the changed SAP platform has an impact on how interfaces are integrated.

The next section in this article focuses on the security, compliance and internal control aspects which come into play with S/4HANA as these aspects require different type of attention compared to a classic three-tier architecture.

Security, compliance and internal control

The classic three-tier architectural approach with distinct layers – data presentation, processing and storage – undergoes major changes with the introduction of SAP HANA database technology. In the classic three-tier architecture, the database layer was only accessible via ECC (the processing/application layer). In the S/4HANA solution, the database layer is extended with application functionality, which allows processing of large volumes of data without its retrieval to the application layer, as well as preparation of results that can be displayed on back-end devices such as mobile phones or tablets (i.e. Fiori Apps). This innovation led to the following architectural and use case modifications on the database layer:

• increased number of database interfaces (SAP Landscape Transformation Replication Server (SLT), Fiori, SAP Data Services (BODS), SAP Solution Manager etc.);
• potential direct access of business users to the S/4HANA data layer (native HANA);
• access to all/sensitive information in real time;
• increased number of users and, in particular, user groups (business users, developers etc.);
• business logic is developed and executed directly on the data layer (due to the delegation of data intensive operations to a database);
• increased number of use cases (analytics on ERP, mobile apps, etc.).

These changes have an even more significant impact on security with the implementation of S/4HANA as they apply to the database as well as the application layer. Based on our insights, we recommend paying special attention to the following security and compliance areas during S/4HANA design and implementation projects:

• strengthening database access controls: avoid unauthorized access to sensitive data and unauthorized or erroneous changes to program code;
• hardening of interfaces: harden HANA interfaces to prevent any unauthorized access to sensitive data of other systems;
• defining HANA security baseline: define security baselines for the HANA platform (database and operating system) and HANA web-application server;
• securing transport management: secure the S/4HANA transport management of HANA views and Fiori Apps to avoid any unauthorized or erroneous changes to program code;
• revision and adaption of a Segregation of Duties (SoD) model: exclude potential violations and conflicts across systems and processes caused by new HANA transactions and Fiori Apps;
• adjustment of internal controls: revise the control framework by eliminating redundant controls (e.g. reconciliation as data is ‘reconciled by design’) and adding new controls (e.g. authorization control on new transaction codes);
• defining secure custom code: define and implement secure development standards for custom code (ABAP and HANA).

Our experience shows that apart from the implications of the S/4HANA implementation on security, many companies still do not consider SAP security with an appropriate sense of complexity and criticality. A broader, holistic approach to addressing the related challenges is imperative. This is depicted in Figure 1. It is important to focus on the protection of all components within the core business process and not just those of the SAP system as such. Furthermore, special attention should be paid to the potential for attacks using the infected workplaces of employees.

Figure 1. Important security and compliance areas with regard to S/4HANA Finance. [Click on the image for a larger image]

Beside security-related aspects that accompany the new technology, S/4HANA involves considerable changes on the functional side, which should be taken into consideration from a compliance and internal controls point of view.

An example of the impact on the control environment caused by the simplification of the data model is the integration of sub ledgers into the main ledger. This makes certain error check reports redundant (i.e. the consistency checks in accounting and controlling), which is currently a key control within the finance procedures. Another example is the real-time asset depreciation functionality of S/4HANA Finance, which replaces the traditional batch job-based approach and requires adjustments to related user controls and procedures.

SAP S/4HANA involves new transactions, while certain other transaction codes become obsolete. For example, maintenance of credit account master data is done using a new transaction UKM_BP, which replaces transaction FD32. In some cases pre-existing transactions are replaced and in other cases some new – HANA-optimized – transactions are introduced. This in parallel to the existing transactions, which remain available to be backwards compatible. All these changes make it necessary to review the new possibilities of SAP S/4HANA and its transactions and adjust the existing SAP authorization model accordingly.

Data model and reporting

1. Single source of truth – overcoming the challenges of the SAP ECC data model

In previous SAP solutions and in other ERP packages, the architecture is based on multiple sources of the truth. For example, entries are made into different ledgers, requiring numerous reconciliation activities across individual fiscal years. Within SAP ECC, the material ledger is not able to store G/L accounts or profit centers, while within asset accounting there is no profit center or G/L account information available in the Asset Accounting (AA) totals table. These are examples that require organizations to reconcile their material ledgers and asset accounting with their general ledgers. Reconciliation work was also required to reconcile CO (Controlling) data with the general ledger, and to reconcile CO-PA (Profitability Analysis) data with the general ledger, as the general ledger and the profitability tables were updated based on different business events in different entities (e.g. accounts).

To handle potential performance issues on retrieving data from SAP ECC, data was stored in various levels of detail and in differently structured components. Hence multiple BI extractors were required to cover the complete set for reporting purposes.

S/4HANA Finance overcomes these challenges through SAP’s introduction of the Universal Journal (see Figure 2). This Universal Journal is the single source of truth for all sub-ledgers as this journal has one line item table with complete details for all components. Data from G/L, CO-PA, CO, AA and ML is all stored in the Universal Journal. Hence, the data is stored once and therefore no reconciliation by architecture type is required.

Figure 2. Universal Journal.

2. Simplification for reporting

The new data model offers the possibility of fast multi-dimensional reporting based on this single source of truth. If an organization has a BI system, one single extractor is sufficient. All actual postings are registered in the same table, with the available dimensions as part of the same table. This simplifies the creation of data cubes.

SAP ECC’s aggregate tables have been replaced by compatibility views. Compatibility views are non-materialized views which means that the data is not stored in tables; in fact it is not stored at all. With the high calculation power of HANA, the views are calculated instantly when a report is called up by an end-user. These compatibility views do not disrupt the business or reporting processes. However, in cases of custom developments (such as custom ABAP queries), the performance may be affected where ABAP queries are intended to write data back into aggregate tables, as this is technically no longer possible with views. The consequence is that developments tailored to your organization either need to be removed or developed in a different manner.

From a compatibility perspective, SAP still provides the same reporting functionality in S/4HANA Finance as in SAP ECC. When combined with the power of the HANA database, the performance and reporting of transaction postings can drastically improve.

3. Reduced data footprint

As several sub-ledgers have been integrated into the single ledger (i.e. Universal Journal), data redundancy is eliminated and the data footprint is reduced. In addition to this integration, several SAP ECC tables (totals tables, index tables) have also been removed. In SAP ECC, the function of these tables was to improve performance, a requirement now met by the HANA database. The changes in the data model are depicted in Figure 3.

Figure 3. Revised data model. [Click on the image for a larger image]

An example regarding the reduction of the data footprint and its complexity: previously a vendor invoice with three accounting line items required more than 10 database tables to be updated more than 15 times, whereas with the new architecture potentially just four database tables need to be updated five times.

As mentioned above, some indexing and aggregate tables will no longer be used, e.g. FAGLFLEXA (line items for new G/L), and ANEP (line items for fixed assets); BSIS (index for G/L accounts) and BSID (index for customers); GLT0 (G/L totals) and LFC1 (vendor master transaction figures totals). The COEP (cost line items) table no longer contains all actual secondary postings, as these are now stored in the Universal Journal (table: ACDOCA). However, the COEP table does still exist, for statistical secondary postings. The result is less redundancy in data storage and unification of the data point in the Universal Journal.

For the G/L accounts master data on the chart of accounts level (table SKA1), there is one other change: this table is enhanced with a new field: ‘G/L account type’ (field: GLACCOUNT_TYPE). This means that cost elements are not managed as different objects compared to G/L accounts, i.e. cost elements are managed as G/L accounts in S/4HANA Finance.

The ACDOCA table is used for line items, therefore the BKPF (document header table) is still used to store financial transaction header data. The BSEG table (document line items) is not replaced by ACDOCA; this table will be used for line items for financial transactions.

Enabled by HANA database technology, the simplified data model and table structure of S/4HANA Finance will reduce data storage and maintenance requirements, and improve data consistency.

How to migrate to this simplified data model and how to assure data is migrated/converted correctly is explained in the next section in this article.

Data migration and reconciliation

When assessing the possibilities for migrating from the existing SAP landscape towards a Business Suite on HANA and/or S/4HANA several migration scenarios are possible. We see the following two scenarios currently being used:

• new implementation (greenfield implementation);
• landscape transformation (brownfield implementation).

New implementation – Greenfield approach

The first scenario is one in which SAP S/4HANA Finance is installed from scratch and the existing ERP instances are migrated to this single instance with S/4HANA Finance. This will give organizations the opportunity to optimize business processes, data and organizational structures.

Landscape transformation – Brownfield approach

In a brownfield scenario, one existing SAP ERP instance is upgraded to S/4HANA Finance on HANA and the other instances are migrated to this S/4HANA Finance on the HANA platform. The main benefit of this scenario is the opportunity to leverage the existing system which reduces implementation time (compared to a greenfield scenario). Furthermore, it retains the advantages of the greenfield implementation with the exception of the opportunity to improve current business processes, organizational structure and data.

Each migration scenario has its own challenges and characteristics. Regardless of the scenario which is applicable to you, it is of vital importance that the converted/migrated data is accurate, complete and that the data migration and reconciliation activities are performed in a controlled manner.

Below, we have outlined several key focus areas when choosing or coping with a migration scenario.

• As part of building a business case, as well as anticipating organizational complexity and follow-up (change for the organization or custom development), an analysis of the current operating model is advised. This includes current business processes and the use of ERP, including inefficiencies, pain areas and custom developments.
• When S/4HANA is installed, it is installed on a system level and not on a client level. Hence, after its installation, it is not possible to post documents within the whole system (development, test, etc.) until the migration is finalized. After the S/4HANA On-Premise edition is installed, a migration is required for each client as part of the system. This means a separate migration for development, test, quality assurance (if applicable) and production clients.
• The add-on which is installed includes a S/4HANA migration cockpit. This cockpit guides you in several steps through the simple finance conversion. The steps include both checks and actual migration steps. Depending on the data quality and consistency, success, error or warning messages are displayed which could require further actions (e.g. housekeeping and data cleansing).
• Migration can take place at any time, with the only requirement being that the latest period-end close is finalized. Based on closing calendars, this means migration is executed at the end of any month, i.e. there is no requirement to migrate at the end of fiscal years as would be the case for a migration to New G/L.
• Performing several migration cycles in test systems is key to testing the migration approach, familiarizing the team with the procedural steps and identifying any required cleansing and housekeeping activities. Please note that the quality of testing is mainly driven by the data quality of the test dataset. It is recommended that at least one of the test systems is based on production data (quality and volume wise).
• It is difficult to provide guidelines on migration throughput times. This depends on many factors such as database size, number of systems, number of clients, complexity of data, etc. An essential part of the total migration throughput time is the business outage that is required in order to migrate to S/4HANA. This business outage is mainly affected by the total data volume of the migrated dataset. In theory, the business outage duration is likely to increase when the total data volume increases. From a costing perspective, an extension of business outage may result in higher costs due to an increase of idle time. A possible solution to limit the business outage, is to divide the data loads into multiple increments by making use of the Near Zero Down Time (NZDT) technique that was developed by SAP.

Designing and performing a solid data migration process is state of art and at a minimum requires highly skilled personnel and mature processes. In-depth knowledge of S/4HANA is required to understand the impact of data model changes and interpret the messages from the checks as part of the S/4HANA Migration Cockpit.

Recognizing the importance and complexity of data migration and acting accordingly is a must for executives who want to be in ‘control’ of their professional company. It is important that data migration should not be seen as solely an IT function but also (and more heavily) a business requirement that has a significant impact on a company’s daily business.

Further information on SAP data migrations and how to realize more value from ERP and SAP is included in a recent Compact article ([Biew17]) and – although non-SAP specific – elsewhere in this Compact edition ([Verm17]).

Conclusion

In this article we have outlined key components and considerations for risk management in SAP Business Suite on HANA and SAP S/4HANA (migration) projects. The SAP HANA platform has been around for some time now, but is – in our view – also still in development. The risk management aspects addressed in this article are therefore also subject to the further development of the SAP HANA platform and need to be re-evaluated over time.