SAP S/4HANA Transformation: Why the Biggest Challenge Wasn’t Necessarily the Technology?

From the moment the implementation tender was awarded until the end of the Hypercare phase, I spent three years on this project as Customer Director, Project Manager and architect on behalf of BPX. Without a doubt, it was the most challenging professional project of my career, but at the same time, the one that taught me the most. Dozens of consultants on the implementation side, nearly 500 people involved on the client side, thousands of meetings, almost 20,000 pages of project documentation, an endless number of emails and interactions. Yet behind these figures was a far more interesting story. Because the biggest challenge of this transformation was not SAP itself…

S/4HANA Transformation Begins Outside the System

Looking back, technological issues were usually the easier ones to solve. They could be analyzed, a solution could be found, the system could be configured, or an enhancement could be developed. Much more difficult was bringing a large organization to a common decision. When delivery began, in some areas we were still building the very foundations of the solution. In practice, this meant that we were designing, aligning and building simultaneously.

It is possible to run a project this way. Together, we proved it as one team representing both the client’s employees and the consortium of consultants delivering the project. However, it is an expensive path. Not only financially, but above all in terms of time and organizational energy. One of the most important lessons I take away from this project can be summarized in a single sentence:

SAP can be configured. Getting many people to reach a common decision is far more difficult.

In a major transformation, time is often lost not on system configuration itself, but on successive rounds of discussions and approvals. We also spent an enormous number of hours debating various topics. Looking back, some of those discussions could probably have been avoided through stronger organizational discipline, more effective change management and clearer decision-making mechanisms.

An additional challenge was the constantly changing business environment. During such a long project, it is natural for team members and decision-makers to change. Earlier agreements often need to be revisited, confirmed or adapted to new realities.

Today, I do not see this as a story of what went wrong. I see it as one of the most valuable lessons from the entire project. In subsequent transformations, much earlier than before, I ask not only about scope, timeline and architecture. I also ask: Who makes decisions? How much time do they have to make them? Who can end a discussion and how? Has the business truly allocated resources to the project? How are people being prepared for change? What will system migration, data management and organizational readiness for digital transformation look like? These questions are often more important than those concerning the technology itself.

Methodology Helps, But It Cannot Replace Experience

We delivered the project as agile as the organization’s capabilities allowed. Methodology is extremely important. It provided the team with a framework for action, structured our work, and helped manage an enormous number of dependencies. However, no framework can provide answers to every situation that arises during a three-year transformation involving hundreds of people and thousands of SAP and non-SAP data records.

During the most challenging moments, methodology proved to be just as important as consultant experience, business knowledge on the part of Product Owners, collaboration between the consortium team and the client’s team and consistency in pursuing the agreed objectives. Because sooner or later, in a project of this scale, something will happen that was not anticipated on any slide deck. And when that happens, you simply need to know what to do, solve the problem and continue relentlessly executing the agreed strategy.

TESTING. TESTING. TESTING.

If I had to identify one thing I would defend in every future implementation after this project, it would be testing. Not only because it helps identify defects. Well-designed integration and end-to-end tests are among the most effective ways to prepare an organization for an S/4HANA go-live. This is when users begin to truly understand the new process. They realize that their task does not end within a single module. They begin to understand the impact of their work on logistics, finance, controlling, taxation, reporting and even the operations of other companies within the group. That is why I no longer see testing purely as a quality assurance activity. Testing is simultaneously a validation of the solution, process integration, organizational readiness and one of the most effective forms of user training. In projects under schedule pressure, the temptation to shorten testing activities in order to regain a few weeks is entirely understandable. After this experience, I believe this is one of the most expensive places to look for time savings.

We Didn’t Do Everything Perfectly

It would be easy to describe this project as a classic success story. A large-scale transformation, a massive team, SAP S/4HANA delivered on schedule, within scope and within budget. Objective achieved. But there is little to learn from such stories. We made mistakes too. Thanks to this experience, we now know which mistakes should be avoided in the future and which ones cost the team the most. I do not view these mistakes as failures. Quite the opposite. They built the kind of experience that cannot be acquired in training sessions, learned from the SAP Activate methodology, or developed during a few months of a smaller implementation

Three Years of Professional Life

For me, this project also has a deeply personal dimension. I dedicated almost three years of my professional life to it. There were periods of immense pressure, exhaustion and frustration. There were weeks when I woke up thinking about the project and went to sleep thinking about it, or sometimes barely slept at all. There were moments when the number of new issues increased faster than we could close existing ones. During those periods, a strong belief in success, unwavering determination and the support of friends and family helped me overcome those challenges. But there was and still is, tremendous satisfaction. Above all, satisfaction from seeing people collaborate and solve real problems together during the most difficult moments. That is what I will remember most. Technology is critically important. Methodology is important too. But in the end, it is people who deliver the biggest projects.

BPX in a Different League of Projects

There is one more aspect of this project that is particularly significant from BPX’s perspective. This transformation demonstrated that a company with entirely Polish ownership can take responsibility for an SAP S/4HANA transformation on a scale typically associated with the world’s largest international system integrators. Not because everything went perfectly, but precisely because it did not always go perfectly and we were still able to overcome the challenges. After all, the true test of an implementation partner is not a project where reality remains aligned with the kick-off presentation for three years. The real test comes when circumstances change, problems emerge, previous assumptions must be redesigned, solutions must be found and the project must still be guided consistently toward its objective. I dare say that for BPX, this transformation marked an entry into a different league of project delivery. For me, above all, it was an invaluable lesson in experience and humility.

What Would I Take With Me into the Next S/4HANA Transformation?

After these three years, my key conclusions are relatively simple:

• Do not start a transformation with technology. Start with people, processes and decision-making. Prepare and align the backlog extremely carefully. Thanks, Piotr!
• Do not assume that a concept is complete simply because the document has been formally approved.
• Follow a methodology, but do not expect it to replace experience. Also, do not assume that people will consciously apply it.
• Always foster collaboration between the implementation partner and the client. Ultimately, we are helping execute the client’s agreed strategy, for the client’s benefit.
• There are no shortcuts when it comes to testing.
• An SAP S/4HANA transformation is far more an organizational transformation than a system transformation. The best practices embedded in S/4HANA strongly support that transformation.

And one final, entirely personal thought. With the benefit of hindsight, I increasingly believe that the things truly worth achieving rarely come easily. And perhaps that is exactly why they teach us so much.

What about your projects? What turned out to be the greatest challenge: technology, processes, people, or decision-making?