Sometimes I get the feeling that people get tired of hearing me talk about some of the recent string of high-profile SAP failures. But then I post another article about the SAP failure at Revlon, Lidl, Haribo, or any of the others, and the article inevitably goes viral.
Still, I don’t feel right dissecting these case studies in S/4HANA failure without providing a clear solution. I have many battle scars as a recovering SAP consultant, and I have found that most problems can be avoided if they are addressed early enough. So, the more relevant question to many reading this article may be: how do I fix my failing SAP S/4HANA implementation – before it’s too late?
First, it is important to recognize some of the common warning signs of a failing S/4HANA implementation. These are some of the patterns and warning signs we see when helping fix SAP implementations or analyzing as independent SAP expert witnesses:
I could go on, so these are just a few of the many warning signs that your project may be coming off the rails. The first step is accepting that there is a problem. The next steps are to do something about it.
The first things we do when helping a client get its S/4HANA transformation back on track is to use our technology-agnostic SAP quality assurance and risk assessment methodology to assess the project from all angles. In most cases, this framework exposes a host of risks and obstacles to change that your SAP systems integrator refuses or doesn’t have the objectivity to admit. The key is to analyze the project from a people, process, and technology perspective, plus everything in between.
This video outlines the framework that we typically use to manage successful S/4HANA implementations, as well as to expose the risks of those S/4HANA implementations:
Often times, the above analysis reveals that the best thing would be to pause the project, regroup, and cast a more realistic plan than the one you are currently working from. If you are running at a highly inefficient and bloated run rate in your monthly project costs, you are wasting a lot of time and money for every day that continues down this wrong path.
Be prepared for your systems integrator to push back hard on the idea of calling a timeout. You will most certainly hear how the sky is falling, you are going to lose momentum, “we’re this close to turning the corner,” the team will get staffed on another project, and a host of other excuses. But stick to your guns. This is your project (and your career) at stake. (For more on this, read our recent article about big ERP systems integrators exposed.)
Once you have hit the pause button and the bleeding has temporarily stopped, it is time to revisit your business blueprint. Not your S/4HANA design blueprint, but your business process and target operating model blueprint. If you haven’t done this yet, then you should take the time to do it now.
Before continuing, you should have a clearly defined and documented vision for what you want your business processes, target operating model, and organizational design to look like. The good news is that you may have already worked through some of this during your S/4HANA design workshops, but chances are there are still quite a few gaps.
Each and every single time I have conducted and project assessment, recovery, or expert witness engagement for a trouble SAP implementation, organizational change management was a huge culprit for the challenges the client was facing. It is safe to assume that digging into this area will yield a plethora of low-hanging fruit to improve upon.
Following are some of the common SAP organizational change management issues we uncover when fixing a failing S/4HANA implementation:
Most SAP systems integrators aren’t good at addressing these critical organizational change pain points, so it is important to get an objective analysis of this people side of the equation in order to get your project back on track.
Once you have analyzed the above, it is important to consolidate the findings and recommendations into a more effective S/4HANA transformation plan. It should include a more comprehensive approach that the one your systems integrator initially proposed and managed the project from.
It is also important to ensure you have established the right project governance and controls. You don’t want the fox guarding the henhouse, so your systems integrator should not be providing the project governance and risk mitigation for their own project. You should either take on this responsibility internally or enlist the help of an independent third-party such as Third Stage to help.
When walking in to fix failing SAP projects, I am amazed at how often the client has ceded control and responsibility to its systems integrator. This is often due to lack of knowledge, lack of confidence, and/or the systems integrator team steamrolling the internal client team into taking a back seat.
This is your project, so it’s time to take back the reins and fix it.
Feel free to contact me with questions or to brainstorm ideas on how to fix your failing S/4HANA project. I am happy to be an informal and agnostic sounding board as you continue your journey!