Revolution or Evolution?

Together with the medium-sized chemical company Zschimmer & Schwarz, Consolut carried out a migration to elicit the innovations that simple Finance already offers today.

The possibility of performing a migration on a customer system far away from any "laboratory conditions" was both an incentive and a challenge. The focus on the part of Zschimmer & Schwarz was primarily on faster and improved reporting options and additionally on simplified access to the database tables in order to be able to design interfaces more efficiently in a heterogeneous system landscape.

Child needs name

In June 2015, the time had come. A Hana (SAP ERP 6 EHP 7 sFin 1503) was used as the test system, which was created as a copy of the production system. In parallel, a corresponding non-Hana system (SAP ERP 6 EHP 7, Windows) was set up for comparative tests.

Here we noticed for the first time what later became a certainty: SAP changes product names and release descriptions at short intervals. Initially, the terms Smart Financials and Simple Finance were used, but in June, sFin was always mentioned.

SAP Simple Finance add-on 2.0 for SAP Business Suite powered by SAP Hana" became "SAP Simple Finance, on-premise edition 1503". While the release statuses were initially differentiated by a classic ascending numbering, this summer SAP decided to mark the release with the year and month of delivery (e.g. 1503 = March 2015).

This also applies to the Support Packages. From SAP's point of view, this was a migration with the release "SAP Simple Finance, on-premise edition 1503, SPS 1505".

The core of the changes in sFin are the changes in the table structures in the area of FI/CO. Previously, there were tables in SAP ERP for line items and balances in the General Ledger, Asset Accounting, Accounts Receivable, Accounts Payable and Controlling modules, but these have been replaced by a new central table (ACDOCA, recently referred to as "universal Journal").

Accordingly, all bookings from these areas are to be brought together centrally in this table. Financial accounting and controlling are combined in the database. So much for the theory. SAP combines this novel concept with the assurance that the stability of all application programs will be maintained.

This is ensured by the fact that, according to the new concept, some tables that are no longer required (e.g. BSID, BSAD, COSP) can still be accessed via so-called compatibility views. The application programs thus continue to use the familiar tables and views.

However, the actual data is retrieved via new views, strictly speaking from the new table ACDOCA. This enables SAP to implement a new table concept without having to make massive changes in the application programs.

The performance impact of this approach leads to some surprising results. However, not all tables are replaced by compatibility views. For example, BSEG and COEP remain and are populated in parallel with ACDOCA. Information is thus deliberately kept redundant.

Children's diseases

Before entering the brave new world of "simple Finance", SAP has set a cockpit for migrating the data. This is kept clear and anyone who has already carried out a migration to the new general ledger or similar will quickly find their way around here.

Through a series of steps, the data from the previous line item and balance tables is to be transferred to the new universal table ACDOCA. There is a bit of customizing on the side, and each migration step is followed by at least one more test program.

Thus, a migration could probably be carried out in a few hours if there were no error messages in the check programs at some point. This is where asset accounting turns out to be a troublemaker.

This is not surprising, because transactions in fixed asset accounting have an impact on several fiscal years due to their duration. A Customizing change from the past decade may well appear to be erroneous from today's perspective during an audit, even though the application programs have not been bothered by it over all these years.

To make matters worse, data management in fixed asset accounting is generally somewhat more complex than in general ledger accounting or controlling. At this point, the project could not continue without an OSS message to SAP.

The support from Walldorf initially led to the import of what felt like more than a hundred notes, most of which had release dates close to the current date. In the meantime, it was August and our assumption that a program status from May of the same year would be a sufficient basis for the migration proved to be a fallacy.

As helpful as SAP support was in the processing, from their point of view we had a hopelessly outdated program status. In further discussions, it became clear that the migration programs for Asset Accounting in our Support Package had some conceptual deficiencies that would not be corrected until the next Support Package.

SAP eventually helped us to avoid all the pitfalls and successfully complete the migration. This was coupled with the statement that these errors had been resolved in the meantime. There is much to suggest that this is the case.

After we had reached this milestone, our interest turned to the innovations in the application. One important finding is that there are practically no changes in the SAPGUI. This is where SAP is caught up with its intelligent strategy.

Since the new design does not require any adaptation of the application programs, there is no additional benefit at the moment. On the other hand, what about the much courted Fiori apps? Here, our conclusion remains undecided for several reasons.

The number of Fiori apps is currently still limited and in some cases deviates only slightly from the SAPGUI by reducing the selection options. In the relevant video portals and presentations, SAP all too often presents the same special processes, which solidifies the impression that the additional benefits of Fiori are still manageable at the moment.

Visually, Fiori apps certainly represent progress. However, many things do not seem consistent at the moment and evoke associations with a further development of the well-known Enjoy transactions. It should be added that some publications give the impression that the function and number of available Fiori apps will increase significantly in the near future.

Naturally, everyone involved had high expectations of the performance of the Hana system. To enable comparability, the productive system from Zschimmer & Schwarz (System i) was copied to a Windows VM and a Hana VM with identical hardware. The performance comparison was carried out at SQL level (see table).

Test #1 and Test #4 show the strength of the Hana system. In both cases, a significant increase in table access performance can be observed. The query from test #4 is broadly comparable to test #3.

The results of the #3 and #4 tests were surprising. The access required on Hana via the compatibility view significantly reduces the speed of read access, so that Hana is even slower here than the other two systems in comparison.

We would like to point out that the hardware used for Hana was not certified by SAP. It is to be expected that with a certified (and thus more powerful) Hana, the access times to the BSID and BSAD tables would be in the range of SAP ERP on Windows.

Up to this point, we were not really happy about the results we had achieved so far. The last thing we looked at was the possibility of "realtime reporting" with Hana. One possibility is to use Hana Live.

SAP delivers Hana Live Content for sFin. This enables SAP BI tools (e.g. BO Analysis for Office or BO Design Studio) to directly access the data of the ACDOCA table.

The second option is to use an "embedded BW" in the Hana system. For this purpose, an additional BW client is created in the Hana system. There, too, SAP provides content that can be used to access the sFin master and transaction data in real time.

Since data is accessed via virtual InfoCubes, reports can be created easily and very quickly using standard SAP BI tools. In both cases, no loading of data is necessary. The documents are available to reporting immediately after posting. The performance of accessing the data was very fast in both options.

Revolution and evolution

SAP has introduced a forward-looking table design in FICO with sFin. The migration programs were still buggy at the time of our project. However, these errors should be largely eliminated with a current support package level.

The benefits of Fiori apps are currently still manageable. There is still potential here in the coming years. The best came at the end. From our point of view, the possibilities of real-time reporting are currently the strongest argument for a migration to sFin.

From the point of view of Zschimmer & Schwarz, there is currently added value above all for SAP customers whose complete ERP landscape runs under SAP. This advantage cannot yet be seen in hybrid systems.

Zschimmer & Schwarz therefore decided to wait for further developments and, if necessary, to re-evaluate the software status available at a later date. Perhaps there will then be enough added value to make the switch if necessary.