How to ensure your S/4 HANA conversion project rolls smoothly from start to finish?
Is there a S/4 HANA update looming in your near future? Find out the six steps that will help you to avoid typical pitfalls in a S/4 HANA project.
What do successful SAP projects consist of?
Every SAP is different and every customer is different, so there will inevitably be challenges to solve. However, challenges must not be feared, they must be prepared for! You can easily overcome them if the project is carefully planned, and the different parties – business, IT, and partners – share a common goal.
These steps help both the customer and the supplier to plan a successful SAP project:
- Make sure that the supplier receives the enterprise architecture map already during the offer phase
It is important that the supplier understands already at the offer phase how the system under change is connected to other systems.
The S4 conversion and the possible change of hosting partner will necessarily also apply to other related systems, network architecture, disk servers, and subscriptions. There may be a move outside the corporate domain, and surprisingly, there may arise a need to share certificates and network keys. When you get a comprehensive picture of the whole already in the beginning, you know how to prepare the right people for the project. A financial consultant will not open VPN tunnels or ports if data is not moving. Overall, integrations need to be identified in precise detail to avoid surprises during migration.
At this point, it is also important for the supplier to know how SAP product support is organised for the customer. Is it covered by SAP support or a VAR model delivered through a partner? This will have effect how to reach SAP support in the S4 project.
2. Make sure that people chemistry works both ways
There must be a strong sense of trust, and all project participants need to feel motivated. When communication is honest and straightforward from the beginning, problems can be addressed at an early stage and the focus can be on advancing the project.
A good confidential relationship works across geographical boundaries, and also virtually. I once worked in a project where I contributed from Helsinki, the client from Tampere, and the project team was scattered all over the globe. The team members were based in Espoo, Oulu, Milton Keynes (UK), Sofia (Bulgaria) and Delaware (USA), and everything still worked well.
Sofigate’s delivery model includes selecting the best people for key roles, and these folks are not always located next door. Thanks to our global network, we can contact local experts around the world to work with the client.
The CIO of one of my clients said that from a client’s perspective, it is important that you choose a partner who is the right size for their company. I truly concur both parties must see the project as equally important.
3. When the actual project delivery begins, it is crucial that the customer has a good understanding of their own processes
If up-to-date process descriptions do not exist, a good approach to getting things right is to make a comprehensive testing plan while the supplier is preparing for the migration.
In any case, the testing plan must be in place and reflect the company’s operations broadly. Preferably, it will cover all relevant activities in SAP. The testing should make note of the turn of the year, change of period, inbound and outbound traffic, possible acquisitions (if necessary) and less frequent operations. It is worth investing in the testing system and making it a responsibility of a designated person. Testing must also be scheduled realistically.
4. Testdrive the testing plan in the migration phase
The first tests should be extensive, so that the plan can be further refined and detailed. During this phase, a reference point is established to which the following tests can be compared. At the same time, the testers can recall some less frequently performed functions.
Migration testing also detects possible special features in the old system, which are not encountered in normal use with production data. For example, running some data into the system repeatedly fails and the system behaves unexpectedly. When there is a mention of this in the testing plan, the S4 testing will not be paused just to wonder why it is not working.
5. If you need to make changes to the platform during the project, you should schedule them as part of the migration
When systems are migrated to new servers as clones, it is easier to detect changes done in the platform, as everything should work as before.
Such changes are for example migration from Windows servers to LINUX servers, Kernel-level upgrades, database changes, and so on. In this way, the changes can be distributed into two stages and the effects can be identified more clearly. You can focus on what is essential in the S4 conversion, as for example the special features due to the operating system update have already been ruled out in the migration phase.
6. Once the migration phase is in progress, you should start building the S4 sandbox
The starting point can for example be a production copy from the beginning of the project, from which the test system has been updated.
Doing the first conversion with all its tricks and fixes takes time. Each SAP system is unique and cannot be converted in bulk. As an example, I once worked on a project where the conversion of the Sandbox system took 26 days. When we converted the production system, the customer’s downtime started again on Friday at 12 noon and S4 was up by Monday at 9 am. However, we did about 10 days of preparatory work in the background and the actual conversion started with the “uptime” phase on previous weekend.
The sandbox provides the customer a playground equal to the production environment where the system can be explored. When the customer tests the system already at this stage, the majority of problems and errors can be corrected, and at best on the fly. The goal is that when the test system is set up, the clear problems have already been resolved and customer-tailored programs are working.
Remember! Transformation is a transformation – and technical implementation is only the first step on the path to change
Although I have given tips for a conversion project here, I would like to stress one fundamental thing about succeeding in S/4HANA. Above all, the S/4 HANA transformation really is a transformation. The technical implementation is only the first step on the path.
If you think the implementation of a new system is the end of the journey, you are wrong. Most of your total benefit will not be achieved. SAP S/4 HANA – both the traditional On Premise and Cloud version – is a modern, real-time, user-friendly, and constantly evolving system.
Oh, and I have a bonus tip! S/4 HANA should not be modified with traditional custom tailoring and Z programs unless absolutely necessary. There are ways to reduce development and life cycle costs, and to help keep the system constant. Get in touch to discuss this in more detail!
Read more about our S/4 HANA offering – click here!
Do you invest in savings or employee experience – or both?
What’s so special about Sofigate’s approach to transformation?
