Why don’t you use your new Ferrari?

Introduction

If you own a new Ferrari, would you keep it locked up in your garage? Would you buy the latest smartphone studded with thousands of apps, and use it only to make phone calls? Then why would you upgrade your SAP system and choose not to use any new feature or functionality that come with it?

In this blog, I would like to discuss a common trend that I have observed over the years – a stiff resistance to functional upgrades .Why do customers choose to stop at ‘technical upgrade’ and never go for functional upgrade? What stops them from using the new features offered by the latest version that can potentially replace many custom programs? Why is the ‘baggage’ of customized developments created in the 3.1x era, carried forward unchallenged?

“Upgrade? Oh, what a pain”

            “It must be considered that there is nothing more difficult to carry out….nor dangerous to handle, than to initiate a new order. For the reformer has enemies in all those who profit from the old order”

– Machiavelli

SAP Upgrades are perceived as an unnecessary disruption to routine life. Many customers will be happy to do away with upgrades. Often the only driver for upgrade is to avoid falling out of support from SAP. Under these circumstances, I have often seen the project sponsors choose to go in for an easier route – a pure ‘technical’ upgrade. Their objective is just to restore the “as-is” situation after go-live – just “survival” is enough! There is no discussion around leveraging any new functionality offered by the latest version.  There is no initiative to review the relevance and the content of the customized programs, enhancements and user-exits.

Some organizations go in for a so-called “phased approach”. Phase 1 is the technical upgrade and Phase 2 is the functional upgrade.  But I have often seen that the Phase 2 doesn’t take off at all or is delayed indefinitely. The achievement of a successful technical upgrade and the resistance to undergo change again is too high. Another common excuse is that during the technical upgrade, there is often a “freeze” on new projects and enhancements. This causes a big backlog of projects that are to be rushed in, after the new version is up and running. It is very difficult to squeeze in process improvement projects in the midst of this mad rush. As a result – the functional upgrade sits on a backburner, where it is ignored for years!

Common Causes

            Here are some of the common causes, genuine reasons (and favorite excuses) that I have come across:

1. No room for (more) change: A technical upgrade itself is a stretch on the resources of the IT department. All the impacted objects are identified remediated to suit the new version. There are several rounds of testing. Changes to transactions and screens require additional training to SAP users. And post go-live, there is additional support required. At the end of this exercise, there is very little appetite for more. The process improvements that can be brought in by functional upgrades have to wait for a better time.
2. Poor business case for functional upgrade: Whenever there were “process gaps” that could not be fulfilled by standard SAP, they were bridged either by developing a custom program or an interface to a third-party software that did the work when SAP couldn’t. All this is considered a sunk cost. To change over to the new SAP functionality means to retire all these custom solutions. It is essential to support this argument for change with a sound business case. The total cost of support, upkeep and future upgrades of these custom developments should be factored in to show the new ROI for a functional upgrade. This step is often skipped and there is no concrete business case to proceed.
3. Fear of the unknown: A common feature observed at several places is that the existing custom developments are not accompanied by adequate documentation. As a result, no one is totally sure of what the program does and what would be the consequence of phasing out such a program in favor of a standard functionality. The business analysts and the process owners too change over the years without suitable knowledge transfer to their successors. All this results in gray areas, where no one dares to delve.
4. Emotional attachment: This is the human side of the picture. It is often noticed that the team that developed a custom solution have a strong bonding with their creation. They are reluctant to scrap the custom programs. In some cases, the custom program (with inadequate documentation and knowledge transfer) becomes the proprietary knowledge of a select few. Stiff resistance from such influencing groups can impede your case for a functional upgrade.

In the next part of this blog, we will look at  some of the good strategies, techniques and enablers that have helped people drive change in their organization.