SAP implementations are notorious for their High failure rates an SAP S/4HANA implementations are no different but why exactly is it that SAP projects fail and what is it we can do to avoid those failures?
One of the most commonly implemented ERP systems in the market and amongst our client base here at Third Stage is SAP S/4HANA, in fact as SAP sunsets their legacy customers off of ECC and migrates more and more of them to S/4HANA, we're finding that more and more organizations throughout the world are implementing S/4HANA.
What we want to do today is talk about some of the common themes we see in a failed SAP S/4HANA implementations and more importantly talk about the things your project team can do to avoid those same failure points.
One of the primary root causes of why S/4HANA implementations so commonly fail is the fact that S/4HANA is a complex product. I don't necessarily mean that in a bad way, it's not a bad thing on the surface but what the complexity does is it creates implementation challengeshttps://www.thirdstage-consulting.com/what-is-business-process-analysis/.
First, let's talk about what I mean by complexity, when I say S/4HANA is a complex product, what I mean is it's a very broad and expansive product. A lot of organizations pick S/4HANA because it can do so much. Many larger organizations, diversified global organizations, pick S/4HANA because the software can handle their diverse and scalable business needs, so it's generally a good thing that SAP S/4HANA is so complex.
But when it comes to implementation, it escalates the risk. The reason for this is because so much of SAP is integrated with other parts of the business, so for example, if you make one change to one part of the business or one part of the software, it's going to affect other parts of the configuration, the design and employment of the software as well. So the complexity of the software is something that is just hard for a lot of organizations to get their heads around.
Even in situations where the organization is migrating from a legacy SAP product, it's still a big jump and it's still in many cases more complex than they're used to.
So it's important to recognize that SAP is a complex product, it takes a lot of time to define how these different end-to-end business processes are going to tie together, how the modules will be configured, how the integration is going to work, how we're going to make sure we test the system to ensure that that integration and that complexity is being dealt with.
So you just want to make sure that during your implementation you account for that complexity and you ensure that you have the right project governance and resource allocations to ensure that you can mitigate the risk of that complexity.
Another root cause of S/4HANA implementations so commonly failing is the relative rigidity of the product. Again, this isn't necessarily a bad thing, even though the word rigidity oftentimes has a negative connotation, oftentimes or more often than not, organizations that are deploying S/4HANA are doing it because they want to deploy a standard set of operating tools in business processes, so that's what they're buying, is that rigidity.
They want a software that can standardize business processes and drive a common operating model and drive consistency throughout the organization but the problem during implementation is that it ends up being a shock to the system, it ends up creating a lot of culture shock, creates operational shock in many cases because you can't simply replicate what you've been doing in your legacy system within S/4HANA.
S/4HANA has a set of common business processes and workflows and either it works for your business or it doesn't. Oftentimes, what that does is that relative rigidity creates a painful trade-off that needs to be made, either we're going to customize the software, which creates a whole other set of risks and complexities in our implementation or we can just force the business to adapt to the way that the software was built.
Neither one is a perfect answer, neither one is easy, they're both painful in different ways but the problem is many organizations don't plan for that and they don't plan for the implications of that.
Another reason why S4/HANA projects so commonly fail is because organizations don't have a good handle on what the real total cost of ownership is going to be for their implementation and for their ongoing support of the product. Oftentimes, organizations sign a contract to license a certain amount of S/4HANA and either they don't realize what they're getting themselves into on the surface with that contract and/or they realize later in the implementation that they didn't buy enough modules or there's additional modules that they're going to need because they didn't do enough vetting of the core product to understand what the strengths and weaknesses of the product are.
The fact that S/4HANA is relatively rigid and standard means that there's costs associated with that. So its a trade-off of choosing between changing the business to fit the software or changing the software to fit the business. That takes additional time and money and oftentimes organizations don't account for that, which is why so many projects go over budget and take more time than expected.
So one of the most important things you can do to overcome and mitigate this challenge and this risk is during the implementation planning phase or the phase zero, the pre-implementation of S4/HANA, you really want to take the time to really vet and fully understand where the gaps are in the product, what the decisions that need to be made are going to be. Are we going to change the software or change the business to fit each other's needs? You need to make sure that you understand what exactly you'rehttps://www.thirdstage-consulting.com/how-to-negotiate-an-sap-s-4hana-contract/ buying, what exactly are you contracting for and make sure we negotiate a deal that doesn't lock us into higher cost structures later on.
Those are just a few of things you can do to ensure that you're avoiding this issue of higher total cost of ownership than you might expect. One other hidden cost to be aware of with S/4HANA implementations is the ongoing internal IT support, so when you think about the skill sets and the competencies and the roles you're going to need to support the S/4HANA product, you want to make sure you have a clear vision for that as well. That's something else you can do during this pre-implementation phase of your sap S/4HANA implementation.
Another reason why S/4HANA implementations so commonly fail is because the organizations implementing the product don't have effective program management in place to ensure they've got the right project governance and controls to avoid some of the problems we've talked about this far.
What they do instead, is they hire a system integrator or an implementation partner or maybe SAP Professional Services to come in and do the implementation for them but you have to remember they have a conflicting self-interest that would suggest that the longer the project takes and the more billable hours it takes for them to deploy technology within your organization, they're going to be more profitable.
That hurts you as an organization. Add to the fact that the technical work stream that SAP and their implementation partners typically provide are just one work stream within a broader program, they're not the right party to be managing the overall program management. They can manage the technical work stream but you still need program management to manage that overarching program that would include things like process Improvement and organizational change management, architecture, data migration, integration, all that those areas that fall outside the realm of S/4HANA technical implementations.
So making sure that you have your own internal PMO or program management or at least some sort of third-party program management support is something that can help mitigate that risk and by the way our team at Third Stage Consulting oftentimes provides S/4HANA project teams with that program management expertise and capability so that you can have ownership and control of the project and you can put some of these guard rails in place via project governance and controls.
Finally, and perhaps most importantly, organizations often fail in their S/4HANA implementations because they don't manage organizational change well. We discussed how S/4HANA as a product is relatively rigid, it's relatively complex and that leads to a lot of organizational change management issues, especially if you haven't used an SAP product in the past.
Implementing S/4HANA can be somewhat of a culture shock to the organization, it creates a whole new set of technologies and tools you need to use but it also impacts your culture, it impacts your operations, the way you've done business in the past is now being disrupted for better for worse. You need to make sure that you have effective organizational change management in place to be successful in an S/4HANA implementation.
The problem is, is that SAP is a software vendor and SAP's implementation partners and system integrators typically don't do change management, they say they do but what they really do is basic training and end user training, that's not change management, that's a small component of change management.
If you are looking to strategize an upcoming transformation or are looking at selecting an ERP system, we would love to give you some insights. Please contact me for more information firstname.lastname@example.org