SAP Modernization: on why it is difficult and a way forward for the CIO
What do beans, band-aids, shiny stars, hot rods and safety have in common?
Is my question strange??Well, I will return to it at the end of this article…
If your organization has been running SAP for some time, you know that modernization is hard. I've been in the business of modernizing and creating innovative solutions for SAP for a long time now, and would like to share with you my experience on modernization challenges, as well as a recommendation on a way forward. This post is not about 'why' you should modernize or move to S/4HANA, I have written a previous post about this topic here. Rather, it is a direct exposition of my experiences - ‘straight talk’, if you will.
If you ask people involved in transformation/modernization projects, they will typically site a number of issues. Although relevant, I would like to share my views on this topic below.
Modernizing your SAP solutions is hard for several reasons:
I could easily write a paper on each of these areas, but will limit each to a paragraph because, at the end of the day, we all want solutions, not problems - and I would like to share with you what advice I would offer a CIO that runs SAP today.?So, here are what I see as root causes associated with modernizing SAP, or any other ERP, for that matter.
Cost vs Benefit from a customer business perspective
It is no secret that implementing and running SAP is expensive. Many customers struggle to justify the costs associated with yet another implementation. Implementing new functional capabilities provided by S/4HANA implies change in processes and user interface, and the impact to the organization is non-trivial, to say the least. Yet it is exactly this tension that becomes the primary 'show-stopper' in modernization decisions. Unfortunately, IT typically does a poor job in articulating the value of the S/4HANA platform itself to it's business counterparts. More on this at the end
Lack of customer investment in the proper maintenance of their systems
I see this time and again. Large databases, no archiving, inconsistent and old datasets, non-optimized system copy processes. Intermingled configurations and custom development, both used and unused. Outsourced low-cost technical managed services, whose interests are antithetical to optimizing anything. Systems not updated or patched for years. All this adds to significant technical debt, and I have yet to see a reasonable financial model that takes into consideration the true cost of the numerous short-sighted decisions that compound this problematic. Technical debt adds layers of complexity and costs to a modernization project.
Poor implementations
A good part of the cost of an implementation is based on services that configure SAP - this typically runs 3-5x the license cost. In many cases, companies will outsource this critical function, and put it our for bid. All SI implementation partners say they follow 'best practices', yet they are the first to propose custom solutions to problems when the fit to the standard is not obvious. Here, you get what you pay for here, then have to live with the consequences. The issues that directly impact modernization in this category are two-fold:
SAP standard x Customer enhancements, and change management.
On the former, companies that do not have the political will to insist that the business adjust itself to SAP standard processes will end up with significant custom enhancements of all kinds. This creates tremendous baggage and complexity in upgrading and migrating such extensions.
The change management topic creates all kinds of challenges, as the original implementer has long since left the company, and many projects since the original go-live have been completed. Changes have been made to configuration, but even if you have good change management processes, there are very few people, if any, that understand how and why the system is configured the way it is. This clearly is not a good situation, as the target system requires, to varying degrees, changes to such a configuration - which leads me to the next topic.
Lack of SAP tooling in dependency and impact analysis
A typical SAP ECC system has in excess of 100,000 database tables. Some 65,000 of these are known as configuration tables (aka 'IMG' in SAP speak). These drive the behavior of the SAP software from process down to low-level functionality. SAP is the epitome of a model driven architecture solution. The challenge lies in the complexity behind all of these relationships. As companies deploy SAP changes to these configurations occur over time in projects as well as to the business. In most cases, customers will not change or clean up these configurations because they do not understand the full impacts of making such change and therefore do not wish to take that risk. Because of this, they are left with an ever-growing set of configurations which at best have a 'do not use' description in their text. Unfortunately, SAP does not provide any tooling to assist customers in this area. As a result, this further exacerbates the technical debt problematic.
Inconsistent offerings and evolving SAP Roadmaps
Figuring out how to align your business and IT strategy is not easy. By Hasso Plattner's own admission, SAP has made a mess through multiple poorly integrated acquisitions, leaving customers with obsoleted solutions and a myriad of new options. In addition, most customers struggle with understanding the impact of S/4HANA and developing a rational roadmap.
SAP has been improving it's tooling in this area. But make no mistake that the goal here is to sell all the shiny new stuff of S/4HANA, which leads us back to the cost vs benefit issue.
What you may not know is that there is a way to get to S/4HANA without all the bells and whistles - it is something that SAP does not talk about much - it is called 'compatibility mode'.
领英推荐
Thoughts on a way forward
If you are running SAP, modernizing isn't just about moving from ECC to S/4HANA and running on cloud. It is also about leveraging the latest capabilities in cloud platform technologies, decoupling and refactoring your existing custom enhancements so that you can run a clean SAP core.
Why? Because, ultimately, you want to run SAP as if it was a true SaaS solution. Imagine that.
SAP has been trying to crack this problem for quite some time. This is NOT simple, because customers (and partners) have been creating bespoke extensions and solutions into SAP since time immemorial. I know - I was at SAP building R/3 and customers insisted in 'modifying' SAP in the name of being able to support their businesses, and business execs promising 'the same level of functionality as our in-house systems' to their constituents. Back then, there were significant functional gaps, so it is understandable. Today, it is more about customer execs having the will, experience and political capital to run SAP within it's possible parametric configurations. Much has changed since then, and SAP now provides different flavors of S/4HANA with different 'cloud native' extension options, including it's SCP (SAP Cloud Platform).
So, if I was having a chat with a CIO who has been running ECC for a large enterprise for a few years (or decades) - AND the CIO desired to continue being an SAP shop, this is what I would recommend:
A high-level plan:
OK, so now to the next level of detail, describing how to get there:
Remove Technical Debt
Functional Assessment
Decouple/re-factor enhancements
Get to a minimal 'Clean SAP Core' on Cloud as quickly as possible
You DO NOT have to implement all the bells and whistles of S/4HANA, no matter what SAP says. We have developed a methodology, called MVP for S/4HANA, that gets you to S/4HANA in months, not years.
Finally, release S/4HANA functional capabilities in an agile manner over time prioritized by the business.
Live happily ever after. Well, wouldn't that be nice :)
And to the original question: “What do beans, band-aids, trucks, shiny stars, hot rods and safety have in common?”
Shiny stars are what the business wants. Band-aids are fixes that create technical debt. Hot rods are the deep extensions and modifications to your systems that not only add to technical debt, but significantly increase operational and switching costs. Trucks are what your infrastructure becomes over time, increasing operational costs technical debt. Safety is related to folks acting very conservatively, partly for self-preservation and because of a lack of tools to do the right thing. Beans, well, because there is never enough to go around when you start counting - and frequently decisions are made on counts alone without a deeper understanding of their impact.
In short, these are key images that reflect the modernization challenge.