Contact us

Request more information

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply

Please wait...

Contact Aiden for more information

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply

Please wait...

Press "Enter" to search

SAP S/4HANA lessons learned

We look back on a successful SAP S/4 HANA implementation, to which we as Aiden were able to contribute. A very special S/4HANA implementation, due to a phased go-live during the first corona wave. It is also good to know that this concerns a 'greenfield' implementation of the 'on-premise' version. Every S/4HANA implementation has its own challenges, so does this one. That is why we look back on the basis of so-called lessons learned.

Business Case

It is important as an organization to clarify why a SAP S/4HANA implementation project should be started. A good business case must therefore be drawn up from the discovery phase. The main reason for this customer was that the ERP system in use at that time was no longer supported. Initially, the project was therefore initiated from IT rather than from the business. Fortunately, as the project progressed, people increasingly realized that sufficient support must also be created within the business.
The choice was made in consultation with the relevant software supplier to see how to deal with the version that is no longer supported or to look for an alternative software supplier. In the end, an alternative ERP package was chosen far in advance, namely SAP S/4 HANA and then the 'on-premise' version.
  1. Trial System

  2. After the broad outlines for the future landscape were on paper, a 'trial system' was put into use. Experience shows that you should not wait too long with this. Start using such a system at an early stage, ensure that a master data set that is recognizable to the customer is available as soon as possible and, as an implementation partner, also let the customer log in to this system as soon as possible. This allows you to clarify the possibilities and impossibilities together with the customer at an early stage. If you do not do this, it will remain too long paper work and there is a good chance that you will have to go back on choices made earlier.
  4. Best Practices

  5. The best practices provided by SAP were incorporated into the system, supplemented with industry-specific solutions. In this way, it was possible to start from a kind of 'template', which largely matched the needs of the customer in question. Using such best practices acted as an accelerator, enabling them to quickly demonstrate certain processes and discuss them in workshops. This made it possible to determine at an early stage which 'best practices' could be adopted one-on-one, which were 'out of scope' and for which a solution had to be devised during the project.
  7. Scope Creep

  8. It is important to properly monitor your scope during the design phase. Initially, the project was also positioned as an excellent opportunity to contribute and secure all your requirements and wishes as a business. As a result, these are fulfilled at the end of the implementation project. As the phase progressed, it was concluded that this was not realistic. Also because SAP was completely new to many within the organization. It takes time to master such an ERP system, which is why it is better to opt for an incremental approach. This can first be looked at the current functionality supplemented with the needs and wishes to support the primary processes to keep the daily business running. From the implementation project, improvement projects can then be started in the second phase based on the implemented platform.
  10. Sprints

  11. When the scope was clear to everyone, the realization phase started. Work was done in 'sprints' and a distinction was made between the construction (configuration) process and the development (customization) process. In accordance with the 'scrum' methodology, supported by Jira, (development) building blocks were shifted from 'to do', 'in progress', 'to test', etc. It was important to involve the business in this; they also made use of Jira and in this way saw which (development) building blocks could be tested (again) and which were not yet ready. The communication about the various (development) building blocks) was also recorded so much in Jira. In this way it was clear to everyone where we stood as a project team.
  13. Customer Care

  14. SAP S/4 HANA is the latest version of SAP's ERP system. It is future-proof and, in addition to a different architecture and user interface, also contains new functionalities. It offers a platform (as SAP itself so beautifully puts it) to grow into a 'digital enterprise'. This also means that the software itself is continuously under development; as mentioned, many new functionalities, but also old functionality that has not yet been completely replaced. Because continuous developments are taking place and the available functionalities are very dependent on the 'roadmap' and therefore the version in use, it is good to be 'close to the ball' and to be able to switch directly with SAP itself. This can be done in the form of SAP's customer care program. As a project team, we have benefited greatly from this; ambiguities were removed and any "bugs" in the software were resolved as quickly as possible.
  16. Lead Consultants and Key Users

  17. A project stands or falls with good lead consultants and key users. To lead a stream (such as Purchase-to-Pay, Make-to-Demand, Order-to-Cash, Finance-to-Report, etc.), choose certified consultants with years of experience with SAP. Where necessary, each stream can then be supplemented with perhaps less experienced SAP consultants, who can work on defined components or provide support in aftercare. In addition to lead consultants, it is also important to choose an experienced key user per stream. Someone who knows the organization and therefore the business well, ideally already has experience with an ERP implementation and is open to change that contributes to the strategy of the organization in the long run. Make these people sufficiently available for the project by providing 'backfill'. If this is not possible, try to fill this role through an external employee. In the latter case, it is of course important that the knowledge remains internally secured in the long term.


Tenslotte is het belangrijk om tijdens alle fasen van het project zaken zoveel mogelijk voor iedereen te visualiseren. Geen lappen met tekst (die toch niet worden gelezen), maar plak afbeeldingen van het projectplan, het IT landschap met alle interfaces, de stroomdiagrammen, etc. op de wanden van de aangewezen projectruimte. Zorg dat iedereen op zijn tijd fysiek aanwezig is in deze projectruimte, met name tijdens de testfase. Dit faciliteert het end-to-end denken en bevordert de discussies tussen de verschillende streams onderling. Ook het reeds genoemde gebruik van Jira zorgde ervoor dat status van het project makkelijk kon worden gevisualiseerd en kon worden gedeeld met de verschillende stakeholders. Het zoveel mogelijk visualiseren kwam ook tot uiting in het door de organisatie zelf gemaakte trainingsmateriaal met veel ‘screenprints’, waarbij zoveel mogelijk het concept van ‘train-de-trainer’ werd gevolgd.


Make sure you have a good business case. Get the right people on board. Start as soon as possible on the basis of the 'best practices' in the system and prevent the scope from becoming too large. Work in short sprints, each time delivering parts of the solution that can be tested by the organization. Where necessary, use the SAP tools and programs offered. Ensure a flat organization, where people communicate visually as much as possible and are close to each other.
The latter was a major challenge during the rollout phase, as this was not possible due to the corona virus and had to be arranged in an alternative way. The project team succeeded very well during this S/4HANA implementation. Within the foreseeable future, the head office and four factories will be live on SAP S/4 HANA. It should be noted that this was partly facilitated by the fact that a close-knit team had already been formed during the current project phases and by properly dealing with the correct 'backfill' at all relevant locations. In short: a great project, which we can all look back on with satisfaction!

Aiden and SAP S/4HANA

Aiden has extensive experience with and is a market leader in migrating from R3 to SAP S/4HANA. Aiden has already performed about 15+ successful migrations. Our years of experience with SAP Business transformations ensures that we, together with our customers, can always be ahead of the crowd. Through our unique 10-step project approach, which is based on 15+ successful migrations and a short lead time (read 3-9 months) with a low investment.
As the migration to S/4HANA is approaching for many organizations, we see that this experience brings great benefits. We surprise with creativity and taking an extra step. Our SAP experience ensures that we prepare our customers for a successful future as an intelligent enterprise with SAP!