What typical errors do you observe in knowledge management in SAP projects?

The true meaning of SAP know-how is often underestimated. I repeatedly encounter projects where employees are deployed who, while dedicated, lack the necessary technical and professional foundation. Anyone who can neither read ABAP code nor understand SAP customising can hardly assess the numerous customer-specific extensions of a system.

Many believe that documenting processes graphically is sufficient. This is helpful, but it represents only a small part of reality. In practice, hundreds or even thousands of variations may exist for a single business process. These differences can be recognized only by understanding the processes themselves and the underlying system logic.

Equally important is professional project management. Every company should employ an experienced and certified project manager who works according to a clear phase and approval model. Before a project moves to the next phase, all prerequisites must be met.

I personally experienced a project that had to be stopped just two weeks before the planned go-live because the final test revealed that essential business processes had never been fully tested. This wasn’t a technical problem, but an organisational oversight.

That sounds more like a problem for medium-sized companies, correct?

Not necessarily. I see similar challenges in corporations as well. There, the greater risk is that projects will lose touch with operational reality.

My most important advice is: Rely on experienced project managers with sound project management training and bring the necessary SAP expertise on board early. The crucial factor is not the number of consultants, but their quality. Companies should not hesitate to seek external expertise in the early stages of a project. This is usually significantly cheaper than having to correct errors shortly before go-live.

One last question: Some companies are considering having their existing SAP systems maintained by third-party providers instead of migrating directly to S/4HANA. Is this a viable strategy?

I don’t personally know any clients who are taking this approach, but I can understand why companies are considering it. When studies by Gartner or McKinsey show that a large proportion of S/4HANA projects miss their deadlines or budgets, then their reluctance is understandable. After all, those who miss the deadline usually exceed their budget.

Furthermore, many consulting firms are operating at full capacity. Companies are therefore rightly asking themselves whether they can get the best resources for such a project right now, or whether a later date would be more sensible.

Those who still have sufficient support for their existing system and only need to make a few changes can consider using the remaining time strategically. However, it is crucial not to let this time go to waste.

In my view, there’s no way around S/4HANA in the long run. But speed alone isn’t a guarantee of success. Companies that have some leeway today can invest that time to prepare their organisation: by training employees, strengthening IT staffing, building the necessary expertise, and refining their own strategy.

In recent years, many companies have paid a high price for their migration projects. By 2028, more tools will be available, and the experience gained from the first large-scale projects will benefit everyone. Therefore, careful preparation can be more sensible than a rushed start.

My advice would therefore be: Use the remaining time wisely. Build expertise, attract the right employees, and align your IT so that it can still successfully support the company in five or ten years. The S/4HANA migration should be part of a long-term future strategy — not just a project to meet a deadline.