SRB goes SAP S/4HANA, Part 2: On the Road as 'Adventurers'

The SAP S/4HANA journey continues. The strategic considerations were established,the Discover & Prepare phases were behind us. Time to take action and dive into the implementation adventure.

Explore – we dive deeper

Once the strategic framework was in place, things became more concrete in the Explore phase. Goals needed to be defined more precisely and the project plan detailed.

The main goal was clear: the conversion of the existing ERP system to SAP S/4HANA using a brownfield approach. It got more exciting from there. We decided to define the following central additional goals:

• Use of Embedded BW with access to real-time data
• Integration of developments on SAP S/4HANA (e.g., our project system or our resource planning)
• Gateway replacement of UI5 applications (restructuring for direct access to backend – CATs)
• Improvement of performance

In return, we excluded process redesign, SAC reporting, and a C4C connection for the time being due to our chosen transformation path.

Objectives of our SAP S/4HANA migration

The processes included HR (time recording & travel expenses), invoicing, as well as accounting/controlling, while the custom code analysis covered extensions, forms, evaluations, and interfaces. Another point was planning the conversion cycles and setting up a sandbox to carry out a purely technical migration.

And here we go – now for real

When transitioning an existing SAP ERP system to SAP S/4HANA, several things must happen:

• Software components need to be updated, including an upgrade of the underlying SAP NetWeaver stack and a replacement of the SAP application software components (e.g., SAP_APPL) with SAP S/4HANA software components (S4CORE).
• If the SAP ERP system is not already running on SAP HANA, the database must be migrated to SAP HANA. With the transition to SAP HANA, the operating system of the database service must be Linux.
• To support the new SAP S/4HANA data model, the data in the system must be converted into the new tables and fields.

The good news: All these activities can be completed in one go, meaning a single project and a single downtime, as the Software Update Manager supports a one-step transition to SAP S/4HANA. Downtimes should generally not pose a problem here. For those who want to be on the safe side, SAP offers a downtime-optimised conversion in the Software Update Manager for larger systems as well as the Near Zero Downtime (NZDT) project approach for even larger systems.

For a one-step conversion for SAP ERP systems on any database (except SAP HANA), the following prerequisites must be met:

1. The SAP ERP system is at least on release SAP ERP 6.0 (no EHP required),
2. Unicode and
3. Single-Stack (only ABAP stack).

A system transition to SAP S/4HANA is also possible in other cases but would require several steps (e.g., initially a dual-stack split if it is a dual-stack system.

If the source SAP ERP system is already running on SAP S/4HANA, the SAP ERP systems must be on version SAP HANA 2.0 (and SP05 for SAP S/4HANA 2020) at the time of system conversion.

We were lucky: We were very up-to-date in this regard as we already met all these requirements. For us, no upgrade and/or database migration project was necessary before the SAP S/4HANA system transition.

In this phase, we also considered our system landscape in the context of the SAP S/4HANA transition. Here is the graphic of our design

:

Repeated readiness checks reduce risk

As the release status changed to S/4HANA 2022 during the Explore phase, the readiness check for SAP S/4HANA was repeated to identify the impacts of a change from the previously created readiness check. At this stage, it became clear how important it is to gain transparency over the necessary adjustment activities during a system transition. A proper analysis and scope definition phase is therefore essential, as based on these results, preliminary projects, the scope of the transition project, and mandatory activities were determined.

And more: We also recommend in this phase to not only review the mandatory adjustments but also other innovations that could create added value for the company. With many clients, we find that a prototype is also created to better understand the effort and activities involved in the conversion. At the same time, this provides an environment for conducting a functional evaluation that helps to understand and demonstrate the value for the company.

And while we are on the topic of customer examples, another point that should be mentioned here: With some clients, a lot of data accumulates over time, and some company codes have been inactive for a long time. Just like with our client

SALESIANER MIETTEX

. In this case, SAP offers an SLT programme to delete old company code data (see also SAP note

1462004 - SAP LT: Transformation solution for company code separation

). An analysis is performed on the system, which determines the scope of which company codes can be deleted. This is significant because it simplifies the transition to SAP S/4HANA, as these legacy data do not need to be considered during the accounting conversion. Or to put it in the words of my colleague Norbert Leimgruber: "That's where the youthful sins are hidden," meaning bookings made in the early years after system implementation.

Processes under scrutiny

The goal of the Explore phase was also to conduct a 'FIT GAP analysis' to analyse existing processes and possibly define future processes. One of the hotly debated topics is the switch to the new general ledger – especially for 'long-serving' SAP customers who have never made the transition from the classic general ledger to the new general ledger with parallel ledgers. Fortunately, we have Norbert Leimgruber, Head of Finance & Analytics, on our team. This is his favourite topic, and he is convinced:

"Yes, the old account solution is unsightly and wouldn't be done this way today, but it works. So, if you haven't introduced a new general ledger with parallel ledgers until now, you don't need to introduce it for the S/4 transition either."

Explore at SRB: Our Focus

For us 'SRB adventurers', the focus of the Explore phase was primarily on two things: defining the project scope and the planned approach. Also helpful: project marketing. Our initiative was presented at the monthly meeting to inform all our employees and to involve them early in the upcoming changes.

Realise – let's get to work

The Realise phase consisted of two parts: a preliminary project phase & the SAP S/4HANA transition phase.

Preliminary project phase

Through the preliminary project phase, we minimised risk. Here, the transition to CVI and an upgrade to EHP8 took place. In our case, we decided to carry out an ECC EHP8 upgrade to make the transition as smooth as possible. This step, upgrading directly to the latest EHP version, had proven effective in the past with our clients. After all, it not only reduced the effort of implementing notes but also brought all our test cases up to date as part of the upgrade. And the latter then formed the basis for later tests during the integration tests within the conversion cycles.

Furthermore, project plans needed to be detailed and the framework conditions for the project clarified. By mid-March 2022, it was time. In the form of a kick-off, all parties involved were informed about the project process and the framework conditions, which were as follows.

Customer Vendor Integration#_msocom_1

As an important preliminary project, we initiated the Customer Vendor Integration, or CVI. This is a mandatory prerequisite for the introduction of SAP S/4HANA. The aim is to transition customers and suppliers to the 'Business Partner Model'. The advantages are clear: it is not part of the SAP S/4HANA conversion downtime, not a critical path of the SAP S/4HANA conversion, and there are no last-minute surprises, thus minimising risk. For this reason, special focus should be placed on this.

But how does the Business Partner model work? A 'Business Partner' (BP) refers to a person, organisation, group of persons, or group of organisations with which a company has a business interest.

For better clarity, the Business Partner merges the supplier and customer master data of a business partner. This also provides the opportunity to clean up legacy data stocks and consolidate business partner inventories. Existing suppliers, customers, and master data are examined and consolidated. Thematically related business partners should also be grouped together.

The CVI links the Business Partner with the debtor and creditor master records, which are created during the initial transition via the CVI of the Business Partner. In ongoing operations, the CVI keeps the basic data between Business Partner and customers/suppliers synchronised.

In this area, we also had a designated expert at SRB: Veronika Wolfgruber. She conducted the CVI for us. Important questions needed to be clarified:

• How should the numbering be done (at BP, customer, supplier levels)?
• How to handle existing customers/suppliers?
• How to merge suppliers and customers? Who is allowed to maintain which data?
• Which data needs to be cleaned up before the transition (e.g., address data, tax numbers, ...)?
• Which data can be archived in advance (old booking data)?
• Which relationships need to be mapped (keyword bonus settlement)?
• Do all previous account groups need to be mapped?
• Future representations of sales representatives? Are these still needed?
• How do you 'translate' the 'existing customer/supplier account group customising into Business Partner' customising with BP grouping (for numbering) BP roles (for reports, functionality, ...) BP types (person, organisation, group)

To clarify these important questions with our clients and obtain answers we can work with, workshops were conducted. The result: Overall, the CVI transition went very well, and we progressed swiftly in our project. Data was analysed, cleaned, and the CVI tested. Ultimately, the CVI was successfully carried out on the productive system. One more step was taken. But the next one was already waiting.

Custom Code Migration

Another mandatory prerequisite for a successful migration to SAP S/4HANA is the Custom Code Migration. It is advisable to collect productive usage data using SCMON/SUSG. We also set up a remote ABAP Test Cockpit to use the SAP S/4HANA checks of the cockpit in the development system. The remote ABAP Test Cockpit is the technical infrastructure for all static checks on ABAP custom codes. We are now using the BTP for custom code analyses via the Custom Code Migration App.

What should not be forgotten at this point is that developers must also become 'SAP S/4HANA ready'. It is beneficial if they acquire practical skills in ABAP development tools in Eclipse and familiarise themselves with SAP S/4HANA must-have technologies (e.g., CDS, BOPF, Odata) – a point we could skip for good reasons. 😊

At this point in the SAP S/4HANA journey, there are certainly several steps that can be considered but are not mandatory. For example, one can adjust their own codes in the development system. Or switch to Unicode, and if not already done, fix SAP HANA related ATC errors (e.g., NO ORDER). One more tip: Run the SAP S/4HANA checks in ATC for all custom codes.

In summary, it can be said: There are limited adjustments that can be made in preparation for the S/4HANA transitions. The main part of the custom code adjustment will then be carried out in the SAP S/4HANA system itself

#_msocom_1.

SAP S/4HANA Transition Phase SAP S/4HANA is getting closer and closer. But planning does not end with migration.

Conversion Cycles

The planning of migration cycles is significant and should not be underestimated, as it helps to correctly define the scope and process of the SAP S/4HANA migration project. The result is a first version of a process that serves as the basis for a project plan. A detailed engagement with this supports the continuous refinement of the project plan as part of the project management workstream throughout the project.

For us, this meant the following during the transition phase:

What happens within a conversion cycle:

1. Copy of the productive system to a sandbox/system
2. Sandbox is upgraded from an ECC system to SAP S/4HANA using SUM (technical migration)
3. Migration of accounting data: Here, the data present in the system is transferred to the new structures. This occurs in 2 steps: customising and performing the conversion. Here, 'historically grown bookings' can lead to errors in various areas of accounting that need to be accepted or corrected.
4. Adjustments of mandatory simplification items: Innovations in SAP S/4HANA in various areas are adopted in the system and must be tested (e.g., the new credit management, settlement management, intercompany, etc.).
5. Custom code adjustments – see above
6. Testing and bug fixing in various forms:

© SAP Transition to SAP S/4HANA – Implementation Roadmap S207

It was made clear to us that not everything runs smoothly in every conversion cycle, particularly in the area of asset accounting. After a successful technical conversion, it turned out that this had occurred over a month-end, making depreciation of the assets impossible. This meant: Back to the start, which particularly pleased our department head Tech, Herwig Stecher. This is how we all learn.

Rich in experience: a journey with added value

Looking back on our journey, we find: The experiences we have gained so far are priceless. Each phase is important in its own right, each significant for future success.

In the Explore phase, the foundation for a successful SAP S/4HANA transition is laid. Here, fundamental, directional decisions are made that influence the entire SAP S/4HANA transition. Based on these decisions, the project scope is defined in detail, and the project plan is elaborated.

In the Realise phase, the project scope is implemented. It is crucial that the learnings within or after a conversion cycle are discussed and incorporated into the next one. Also critical are the tests that determine the quality of the project. Here, the rule is: 'Every error I find during testing won't blow up in my face at GoLive.' Whether that happened to us will be revealed in the next instalment of the little series.

Preliminary Projects

If you are also facing migration to SAP S/4HANA or have questions about our journey to the new platform, feel free to contact me. Additionally, I have compiled interesting supplementary information with further and hopefully helpful tips & tricks regarding the two phases of the transformation path described above.Information Sheet 1: Strategies & Methods Information Sheet 2: Preliminary Projects

Interested in all episodes on SAP S/4HANA migration at SRB? Readherethe first contribution on the phases 'Discover' and 'Prepare'.