Skip to Content

Why don’t you use your new Ferrari?


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”


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.

You must be Logged on to comment or reply to a post.
  • Great post. I agree in all the points mentioned. A lot of companies have a Ferrari (SAP) and they don´t use a lot of SAP standard functionality either they don´t have time to learn the new functionalities or they are afraid of changing the customs programs (some of them are a black hole for the entire company).
    • 'Black Holes' indeed!! I had used a milder term "gray area". But yes, you are correct. Some of the customized programs are true black holes. And just as a black hole sucks in matter, these customizations suck in resources for their maintenance and upkeep.
      Thanks for your response!
  • Hi Asutosh,
    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..
    • That's a good idea, Holger! Probably your flyer should show a red Ferrari covered in dust and cobwebs 🙂
      Thanks for your comments!
  • Hi Ashutosh,

    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

  • It'a nice note Ashutosh.

    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.


  • Ashutosh,
    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.


  • Ashutosh,

    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


  • Functional upgrades (process improvements) can come from anywhere: SAP, employees, competitors, other industries.  Until employers respect employees and promote job security, improvements of this sort will improve productivity only marginally. Why bother with hard work that could lose my job ??
  • Good blog!!
    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).


  • For any functional upgrade to happen successfully, the project driver needs to be convinced of the benefits of new functionalities, and should be able to strike a cord with the process owners. This can be tricky, especially when a lot of change management is involved.

    So it totally depends on the relations between the project manager and process owners.