The view of the consultants

Where and how will the systems be operated? How should the system architecture, how should the structure of the client and company codes be designed? What will the blueprint phase look like and who will provide the required information?

The project organization had to operate in parallel with the operational business. In addition, there was the question: How will the required information about the changes to the system be received? After all, according to SAP, Simple Finance is a "game changer" that makes it possible to manage a company in a completely different way.

The decision in favor of Hana was made quickly due to the solution envisaged; in view of the expertise already available, a cloud solution with Microsoft Azure as provider was chosen. This meant that requirements for hardware and system extensions could be implemented quickly at the click of a mouse.

Lack of consistency

The initial phase - customizing and recording the requirements of the business side: The business side brought its requirements into the Blueprint phase quickly and without complications. For the business side employees, SAP was completely new and therefore procedures and technical terms had to be trained by SAP.

In this way, "simplified" and modernized procedures and processes could be established at the same time, especially in financial accounting. The initial customizing was carried out quickly.

However, when it came to the details of the structures and process flows, a certain discrepancy between the delivered software and the available or discoverable documentation became apparent.

Sometimes the software was further along than the documentation, sometimes the documentation was more up-to-date than the software. Challenges during implementation: This was not helped by various name changes: For example, "SAP Simple Finance add-on 2.0 for SAP Business Suite powered by SAP Hana" became "SAP Simple Finance, on-premise edition 1503". The documentation refers to the technical name SFIN 2.0 or also sfin200.

In the meantime, the names of the Support Package stacks also varied, and these renaming changes were only reflected in parts of the documentation. SAP Note 2171868 now sheds some light on the changes in naming.

After the delivered software stack had been regularly upgraded to an up-to-date status by the Hana-certified consultants, operation and implementation of the business requirements became much easier.

The Blueprints were implemented relatively quickly; however, due to a restructuring, some structures had to be recreated and transported.

Without aggregates

The cross-divisional analyses were evaluated and validated with great interest, as reporting for the Alegri Group across corporate structures had been a reason for implementing S/4 Hana Finance.

Reports can now be created, adapted and executed easily and quickly, and thus one of the announced advantages of S/4 Hana Finance comes to bear immediately: Aggregates or even ETL processes are no longer required and lead to a significant increase in agility.

Since the previously necessary reconciliation entries between FI and CO have been significantly reduced, the month-end closing process is lighter and can be carried out more quickly.

No "normal" introduction

The Alegri-specific forms were created by the company's own nearshoring development department in Romania. After coordination in project management, this also ran effectively and so change requests and adjustments could also be carried out in parallel with the project.

It can be summarized that this was not a "normal" implementation; the conversions and changes in the S/4 Hana Finance system are associated with a certain learning curve. The positive results allow these efforts to be seen as a worthwhile investment for further projects.