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

The SAP S/4HANA journey continues. The strategic considerations were set,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 established, it became more concrete in the Explore phase. Goals had 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 (reconstruction 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 off we go – now really

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

• Software components must 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 in 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 be an issue 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 the 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 prerequisites. For us, no upgrade and/or database migration project was required 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. In this phase, 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 not only to 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, it 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 client examples, another point that should be mentioned here: With some clients, a lot of data accumulates over time, and in some cases, 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 conducted on the system, resulting in 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 hiding," 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, if necessary, define future processes. One of the hotly debated topics is the transition to the new general ledger – especially for 'long-standing' SAP customers who have never made the leap 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 that 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 not only inform all our employees but also to bring them on board early regarding 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, the project plans had 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 participants 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 consolidates the supplier and customer records of a business partner. This also provides the opportunity to clean up legacy data and consolidate business partner records. Existing suppliers, customers, and master data are checked and consolidated. Thematically related business partners should also be summarised.

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 the Business Partner and customers/suppliers synchronised.

In this area, we also had an expert at SRB: Veronika Wolfgruber. She conducted the CVI for us. There were important questions to clarify:

• How should the numbering be done (at BP, customer, supplier levels)?
• How to deal with existing customers/suppliers?
• How to merge suppliers and customers? Who is allowed to maintain which data?
• Which data must 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 mappings 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 made swift progress in our project. Data was analysed, cleaned, and the CVI tested. Ultimately, the CVI was successfully implemented 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: 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: During the S/4HANA transitions, there are limited adjustments that can be made in preparation. 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

Planning the 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 examination of 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 executing the conversion. Here, 'historically grown bookings' can lead to errors in various areas of accounting that must 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 goes smoothly in every conversion cycle, particularly in the area of asset accounting. After a successful technical conversion, it turned out that it had run over a month-end, making asset depreciation 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 invaluable. Each phase is important in its own right, each significant for later success.

In the Explore phase, the foundation for a successful SAP S/4HANA transition is laid. Here, fundamental, guiding 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 detailed.

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 this happened to us will be revealed in the next installment 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.Info Sheet 1: Strategies & Methods Info Sheet 2: Preliminary Projects

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