Skip to main content
Tycom Insights

S/4HANA Transformation

Experience report S/4HANA Transformation - The path to an intelligent digital company

Data-driven decisions, quick reactions to changing market conditions and digitally optimised processes form the basis for the future success of your company. As a decision-maker, you know that the digital transformation can only be achieved by migrating to S/4HANA as the digital core.

The complex issues and interdependencies require a coordinated approach to scenario and operating model selection, departmental and process requirements, project procedures and target alignment on the timeline. In this article, we present our experiences with the transformation to S/4HANA in the Tyrolit Group.

Your contact person

Daniel Testor Sustainability Specialist

Eduard Kohler

Chief Operating Officer

Inform now

Would you like to know how this solution can be integrated into your company?

I would like to find out more

Project customer: Tyrolit

The Tyrolit Group is one of the world's leading manufacturers of grinding and dressing tools and a system provider for the construction industry. For over 100 years, innovative tools and solutions from the Tyrolit Group have played a decisive role in technological progress in various industries.

  • 80000+ products, 4500 employees, 30 global production sites,
    Distribution in 140+ countries
  • Machine connection in production (Industry 4.0)
  • SAP customer since 1985 with SAP ECC until Q2/2023: Migration S/4HANA
  • SAP solutions in use: S/4HANA, SAC, SCT, BTP, Cloud Connector

Thematic familiarisation and rough planning

With an effective lead time of 1.5 years, the changeover from SAP ECC to S/4HANA took place in mid-March 2023. Good preparation and planning of activities and the timeline are basic prerequisites for the success of the project. SAP offers a lot of input here in the form of blogs, process models, initial consultation, webinars, etc. Internal planning is carried out in as much detail as possible and in close coordination with the responsible IT and specialist departments.

The procedure can be roughly summarised as follows:

Fig. 1: Project phases. Source: SAP with supplement/design Tycom

Preparation phase

  • Requirements analysis: Recording and clarification of requirements regarding processes, functionalities, master data and reporting.
  • Process analysis: Comparison of the actual and target process in order to identify necessary adjustments.
  • Time and budget planning: Definition of a realistic project schedule and budget estimate.
Fig. 2: Steps of the technical migration Source: SAP

Technical preparation

  • SAP Readiness Check (RC): Carrying out a comprehensive system analysis to identify compatibility problems and necessary adjustments.As a starting point for every transformation, the RC is carried out in the production system wherever possible.
Fig. 3: Readiness check result. Source: SAP
  • Custom Code Check: Review and customisation of in-house developments to ensure compatibility with S/4HANA.
  • Database conversion: Switch to the HANA database, which can often be done before the actual conversion.

Planning strategies

  • Choose a transformation approach: Decision between brownfield (system conversion), greenfield (new implementation), or selective data transition based on business requirements.

Fig. 4: Decision criteria for approach selection. Source: SAP with revision Tycom

  • Plan the system landscape: Consideration of the effects on development, test and production systems.Consideration of interfaces in third-party systems, add-ons, company-specific special or in-house solutions.
  • Identify innovation potential: Identification of areas in which S/4HANA-specific functions can offer added value.

Project management

  • Put together a project team: Involvement of technical experts and IT specialists.
  • Change management: Planning of training and communication measures for end users.
  • Risk management: Identification of potential risks and development of migration strategies.

Performance optimisation

  • Database table design: Adaptation of the database design to optimise the use of HANA technology.Determination of the required database size.
  • HANA-specific features: Planning the implementation of HANA-specific functions to increase performance.

We recommend carrying out an initial sandbox conversion at an early stage in order to obtain a prompt overview of the issues facing the specific project.

Get advice now!

Contact us without obligation and let us advise you.

Involvement of business departments

With the brownfield approach, which is favoured by most SAP customers and is usually the quickest way to achieve the goal, there are two basic procedure options regarding the involvement of the business departments. It is important to understand that this is never a pure IT project as there will inevitably be functional impacts on the business departments. Depending on the approach, however, these effects can be smaller or larger.
  • Technical migration: The specialist departments are kept out of migration issues as far as possible. The system is migrated purely technically wherever possible, i.e. only technically necessary changes are made for which IT assumes primary responsibility and the specialist departments are only involved where necessary (new credit management, new asset accounting, new business partners, etc.). This approach was chosen in the Tyrolit project in order to minimise the use of specialist department resources. However, the involvement of the respective departments is unavoidable for tests, for the final acceptance of the system and the key financial figures, and for mandatory training on new topics. With this approach, process optimisations, master data improvements and the introduction of new functionalities only take place after the successful S/4HANA migration.
  • Technical and content migration: The migration will also be used to achieve process improvements and harmonisation, master data improvements and new functionalities in combination with the introduction of S/4HANA. However, this requires greater resource availability in both IT and the specialist departments.

The chosen approach should be clearly recorded and communicated to everyone.

Fig. 5 Example: Differentiation between preliminary projects, main projects and downstream projects
The customer's project manager should have good IT skills, be well networked within the company, be a good communicator and be familiar with the company's processes and business requirements.
In terms of effort, the following topics are particularly in focus:
  • New business partner and Customer Vendor Integration (CVI)
  • New general ledger and general ledger migration (Finance Data Migration)
  • New asset accounting
  • New credit management
  • Material leather
  • Recognition of income
  • Bonus and discount agreements (contract settlement)
  • New cash management
  • Coordination with the auditors and comparison of key financial figures before/after migration
  • Foreign Trade / Intrastat Reporting
  • RE/FX contracts
  • Special processes or customer's own solutions

Separate preliminary projects are recommended for CVI and the new general ledger, and if the go-live takes place later in the year then also for contract settlement.

Early coordination with the auditors is recommended in order to jointly define how the system changeover is to be accepted and which key financial figures are to be provided in a comparison of ECC before the changeover vs. S/4HANA after the changeover.

Following thematic preparation, scope definition and rough planning in IT as well as preliminary discussions with the management, suitable project partners are selected.

Selection of project partners

Only a few customers will be able to shoulder the technical knowledge and resources for implementation on their own. When selecting a partner, we recommend locally available and competent developer expertise for the necessary custom code and performance adjustments, experienced project management including experience with S/4HANA and the migration, and good chemistry between the consultant and customer. The partner should also be well networked with SAP in order to be able to quickly access SAP experts and migration knowledge in the event of specific migration problems.

Project assignment

We recommend placing the project as high up in the hierarchy as possible and obtaining the support of top management for the entire duration of the project. The project owner should be located in the Management Board accordingly, as should parts of the Steering Committee. If major effects on individual specialist departments are expected, their representatives should also be involved in the project organisation.

Keep the system stable and clean

For the duration of the project, it is advisable not to add any new functionalities to the existing system so that the starting point and target image remain as unchanged as possible. This subsequently reduces the effort involved in the project, especially for topics such as custom coding and master data. Only absolutely necessary changes to the system should be permitted and should be made in close consultation with the project team.

Clean-up actions in advance are highly recommended, e.g. archiving exercises for master data such as customers and suppliers as well as for transaction data such as documents, removing obsolete and no longer used custom coding.

Time and task planning

The schedule and earliest possible go-live date depend very much on the current customer system. If this was only set up a few years ago without many in-house developments, with a small range of functions and with clean master data, a transformation can be achieved quite easily in 6-10 months. However, the reality for most SAP customers is different: historically grown systems have to be captured and brought into the new corset.

Schedules help to structure the migration and also serve as a means of communication. The individual tasks should be documented in as much detail as possible, especially for the implementation of the go-live (productive system migration), and assigned to those responsible in order to correctly take into account dependencies and important intermediate steps in the process. We recommend creating detailed schedules at a glance, especially for critical phases, and backing these up with task lists, while also keeping an eye on the dependencies on other projects, such as the replacement of other existing software solutions, and coordinating intensively with these.

Fig. 6 Example: High-level plan as a communication tool for project stakeholders and for planning dependencies on other projects
Fig. 8 Example: Scheduling of a sub-project
Fig. 9 Example: Visualisation of business partner data
Visualisation of the complexities helps to maintain an overview and bring the relevant stakeholders on board.

Particular attention must be paid to planning the go-live. After the go-live, sufficient hypercare support must be ensured for the specialist departments. We also recommend agreeing a standby service with SAP, e.g. in the event of HANA database problems during the conversion. We also recommend developing contingency plans and backup solutions in advance, e.g. under what conditions will the ECC backup be pulled, which must be created in advance, and what happens if a central project member unexpectedly fails.

Fig. 10 Example: Planning a go-live weekend

A conversion involves a large number of tasks, which usually need to be organised in chronological order in order to take dependencies into account. Structured task lists with a status indicator help here.

Figure 1 Example: Task plan with interdependencies. Source SAP
Figure 2 Example: Structured task list per conversion in chronological order

Release and sandbox planning

Depending on the initial system situation and the result of the first sandbox conversion, an initial decision is made on the number of test conversions, which affects the duration of the project. Test conversions significantly reduce the risk of errors during the productive migration and ensure that the project team is well-rehearsed. As a rule, there is a three-tier system landscape with development, test and production systems. This already results in two test cycles. We recommend carrying out at least two additional test cycles by copying the ECC production system into a sandbox and practising the conversion to S/4HANA on it - as close to production as possible. The sandbox systems are provided in close coordination with the base or with the base outsourcing partner.

Figure 3 Example: Sandbox conversions from the production system. Source: SAP

The overall procedure can then look like this.

As soon as the development system has been migrated to S/4HANA, the system freeze can be cancelled and new developments can be initiated again.

Figure 4 Overall procedure for sandbox and system landscape configurations. Source: SAP

Documentation, tests, training

A centralised project platform that is accessible to everyone facilitates communication and the provision of test files, training materials and relevant documents. We recommend using existing structures such as SharePoint or intranet sites wherever possible.

If there is an existing ticket system, it is a good idea to create a separate "S/4HANA Test Findings" category so that users can record negative test results in it. This allows the project team to maintain an overview, track progress and decide on this basis whether the system and users are ready for the go-live.

A test concept defines when which tests are to take place and how they interact with the overall project plan.

Figure 11 Example: Communication platform on SharePoint

Where possible, existing test scenarios and test documentation are used. We recommend tracking user behaviour over a longer period of time in the production system so that the transactions, reports and apps actually used can be covered in the test cases.

In terms of training, we have had good experiences with training videos that can be recorded using simple tools such as Camtasia from TechSmith and made available on the central project platform. This eliminates a large proportion of on-site training sessions and users can access the training content whenever it suits them.

Figure 12 Example: Training video for the business partner in Camtasia

Data validation

SAP recommends running at least 11 finance check reports in SAP ECC before the conversion and then in S/4HANA around the time of the go-live. This may require the involvement of all finance managers of the companies involved. We recommend a trial run of this validation process in the test system in advance as well as early coordination and go-live support by the Group's auditors. It may also be necessary in some countries to notify the authorities of the system changeover. Structured and comprehensible documentation of the test results with system screenshots is essential.

Figure 13 Example: Financial data reports for data validation
Figure 14 Example: Communication for the provision of financial data reports

S/4HANA transformation with Tycom

Benefit from our extensive implementation and operational experience with S/4HANA and put your company on a future-proof digitalisation platform.
Contact us now without obligation!

Contact us without obligation and let us advise you.