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:
- 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.
- 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.
- 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.
- 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.
Thanks for your response!
thanks for this great blog. There are some things that really need to be said. I have seen a couple of times situations like you described. I thought the same: Why do they let this chance go by?
Maybe we sould make your blog a flyer and hand it out everytime we see this..
Cheers
Holger
Thanks for your comments!
very true statements. yes, there are lot of ferrari’s here too :). Most falls under below categories.
1. Phase 2 never materialze.
2. What we need to change and what is the impact.
3. Lack of skills/knowledge to work with new models/technology/processes.
Will look forward to your next blog.
Arundeep Singh
The most common drawbacks observed are
Why do we require a change when everything is going fine?
No funding for it.
I think to overcome these things we should show our clients the benefits of doing a functional upgrade and also the ROI on their investments.
Cheers
Ram
Well thought!!! Most or almost all client does take this approach. And irony is that upgrade partners also shy away from recommending or building business cases to the clients. The question is customer is in showroom and wants to replace the old Ferrari but instead…end up getting engine change? I will look forward for your next blog to see how to sell the New Red Ferrari with better and new life saving features.
Cheers,
Vivek
This is well said and should be helpful to the ground crew who really work on these upgrade projects.
To initiate the dicussion with the Customers about the Best Practices available in the upgraded system.
Looking f/w for Part2
Srikanth
Always be carefull in driving a Ferrari. Use good drivers / pit crew in getting the most out of your Ferrari.
Analyse of what you really need (cost/benefit).
Regards,
Aart
So it totally depends on the relations between the project manager and process owners.
Regards,
Aroop