Donato BlandolinoSAP implementations do not fail because of the technology. They fail because of how companies set them up. The three most common mistakes, and how to get it right.
SAP implementations do not fail because of the technology. They fail because of how companies set them up. Those who treat SAP as an IT project get an IT outcome. Those who see SAP as an operational transformation get a functioning company.
The recurring pattern
In almost every SAP assignment we take on at SMART iNTERIM, we encounter the same picture: The programme is running. The system architecture is defined. Status reports are green. An exemplary project on paper.
In reality: Business functions are not involved. Processes are not clearly defined. Responsibilities are unclear. And yet the project continues, because it is an IT project, after all.
Why SAP is not an IT project
SAP S/4HANA does not map processes. SAP forces companies to lay their processes bare. If processes are not clearly defined, not decided on, not followed in practice, then you are not building a system. You are building chaos into software.
During configuration, decisions are made that were never agreed with the business functions. Because the business functions had not made decisions and IT still had to deliver. The result is workarounds, shadow processes and manual corrections.
The three most common mistakes
1. Processes are not defined before the system
The most common and also the most expensive mistake: SAP is implemented before the organisation has clarified its processes. The system is configured on the basis of assumptions, not decisions. If these processes are not standardised, SAP becomes a mirror of the existing chaos, just in digital form.
2. Business functions are not held accountable
IT can build the system. What IT cannot do: decide how a company wants to work. That decision rests with the business functions, production, logistics, procurement, planning, quality. It is precisely this decision that many SAP programmes fail to demand.
3. The project is managed in isolation from day-to-day operations
SAP programmes often operate in a parallel world. The people who will later use the system are not part of the project. At go-live, a system configured in theory meets an operational reality that nobody on the project team knows from first-hand experience.
How SMART iNTERIM approaches SAP implementations differently
Our approach is not technical. Our approach is operational. We do not start with the system. We start with the question: How does this company work today? And how should it work tomorrow?
- We define process owners, not project owners.
- We go to the shop floor before we move on to configuration.
- We demand decisions, not coordination.
- We connect SAP with operational transformation.
From the shop floor to the system, not the other way round
On an automotive assignment, we deliberately reversed the approach to the SAP implementation. Instead of thinking from the system outwards, we started with the material flow. The question was not: How do we configure SAP? The question was: How must material flow through the plant so that we can deliver?
Only once the physical flows, planning logic and responsibilities were clear did we begin to configure the system to reflect them. The result: an SAP configuration that was operationally usable from day one.
SAP as a mirror of the organisation
Ultimately, SAP S/4HANA is nothing more than a mirror. It shows how a company actually works, not how it thinks it works.
If SAP is managed as an IT project, you get an IT outcome. If SAP is managed as a business project, you get a functioning company.
