Article - ERP Transformation
Why Most SAP S/4HANA Programmes Stall at Integration
Integration is the part of every SAP programme that takes longer than planned, costs more than budgeted, and receives less attention than it deserves until it becomes the reason the go-live is delayed. This does not have to be the pattern.
The Integration Underestimation Pattern
Integration is consistently the most underestimated workstream in SAP S/4HANA programmes. This is not because programme teams do not know integration is important. It is because the true scope of integration work is structurally difficult to assess before the programme has begun, and the estimates made at the start of the programme reflect what is visible at that point, which is almost always less than what will ultimately need to be built.
A typical large-enterprise SAP landscape at the start of an S/4HANA programme includes dozens of integration points, some of which are formally documented, many of which are known only to the teams that built and maintain them, and some of which are not known at all until they break when the new system goes live. The programme scope captures the documented integrations. The undocumented ones surface later, as exceptions, issues, and delays.
The pattern is predictable because it is structural. The organisations that escape it are not the ones that document their landscape better at the start. They are the ones that build integration discovery into the programme methodology as an ongoing activity, not a one-time exercise at the beginning.
The Three Layers of Integration Complexity
Technical Complexity
The most visible layer is technical. SAP S/4HANA uses different integration technologies than the systems it is replacing. Legacy systems may use point-to-point connections, file-based transfers, or middleware that is not compatible with the API-based architecture that S/4HANA prefers. Migrating these integrations requires understanding how each one works, designing a replacement, building it, and testing it -- in parallel with the rest of the implementation.
The technical complexity is compounded when the landscape includes systems that have been in place for a long time and where original documentation does not exist. In these cases, the integration needs to be reverse-engineered: understanding what data flows where, at what frequency, in what format, and triggered by what events. This takes time that programmes typically have not budgeted for.
Data Complexity
Integration is not just about connecting systems. It is about moving data between systems that may have different data models, different field definitions, different coding frameworks, and different data quality standards. A customer number in SAP may or may not correspond to a customer number in the CRM, depending on the history of how each system was implemented. A product code in the ERP may have a different structure than the product code in the warehouse management system.
Data mapping -- establishing the rules for how data from one system corresponds to data in another -- is the unglamorous work at the heart of integration. It requires deep knowledge of both systems. It is difficult to automate fully. And errors in data mapping that are not caught during testing will manifest as data quality problems in production, often in ways that are difficult to trace back to their source.
Operational Complexity
The third layer of complexity is operational. Integrations are not just technical connections between systems. They are the mechanism through which business processes that span multiple systems are executed. When an integration is changed or replaced, the business process it supports changes with it. Process owners need to understand the change, test it, and sign off on it before the integration goes live.
Managing the operational complexity of integration requires more than a technical testing programme. It requires a structured approach to involving process owners in integration design, building test scenarios that reflect actual business operations, and ensuring that the people who will work with the integrated systems after go-live have tested them in conditions that resemble production.
"Integrations are invisible when they work and catastrophic when they do not. The investment in getting them right is always smaller than the cost of getting them wrong."
What Programmes That Handle Integration Well Do Differently
The programmes that manage integration well do not start by trying to be more accurate in their initial estimates. They start by acknowledging that initial estimates will be wrong and building a programme structure that can absorb and respond to what is discovered.
This means designating a dedicated integration workstream with its own leadership, its own timeline, and its own budget -- not a sub-track within a broader technical workstream. The integration lead needs the authority to escalate when integration scope expands and the relationship with the business to involve process owners appropriately.
It also means conducting a structured integration landscape assessment before the build phase begins. This assessment maps every known integration point, categorises them by complexity and business criticality, and establishes a priority order for building and testing. The assessment will not capture everything. But it reduces the number of surprises and ensures that the most critical integrations receive attention before they become blockers.
Finally, programmes that handle integration well treat integration testing as a first-class activity, not something that happens after functional testing is complete. End-to-end testing that simulates real business processes across integrated systems catches errors that unit testing of individual integrations will miss. This testing takes time and requires business participation. It is the most expensive thing to defer and the most valuable thing to complete before go-live.
