On March 31st, 2013, a number of SAP's core products that run a lot of the world's industry and business, will fall out of support. This includes all customers running SAP R/3, and its ECC 5.0 product range as well. A lot of people are wondering if they have to upgrade, when and why and if they can get away without it. Here's my advice based on the conversations I am having, and the decisions I am seeing people making.
There is no direct business case to upgrade your ERP
Let's get this out the way early on. In most cases, if you must produce a business case to upgrade software, it will not stand on its own two feet. However, let's put this in terms of an analogy. For most people, their second most significant personal purchase is, after a house, their car. A car costs in the tens of thousands of Euros/Dollars/Pounds to purchase. And for a typical car, you lose 15% of the value each year, and pay 15%+ of the value in the cost of fuel, insurance, tyres and servicing - each year.
Large computer systems are much the same. To keep them fed and watered, you must invest some money in them. Don't be afraid of this! Many ERP environments cost millions to implement, and the same again each year in additional projects, support and maintenance. An upgrade from SAP R/3 to ERP is just like a 48,000 mile service. It's the cost of doing business, and that's OK.
That said, there are a number of ways in which you can build a business case around the wider elements that are going on in your business. Here's some ideas of where to start.
Don't be afraid - it's not as bad as you think
Many SAP R/3 implementations, especially those on older versions, are highly customised. I'm currently dealing with a number of customers who have levels of modification in the 10-100,000 objects. It may come as a surprise but a very large amount of this will work after the upgrade. The amount of restitution that you will require may be less than you expected. At least this is what I'm seeing with the customers I am working with.
Most upgrades are not purely technical
The experience we see is that most SAP Business Suite upgrades are not a purely technical activity. Even if business functions don't change then some business context as to what is going on will be required. This is especially true because after the technical portion of the upgrade, not everything will function correctly. Don't be worried about this, just make sure you have the functional and business resources bought into the process - because…
There is nothing more important than testing
Regardless of how you do your ERP upgrade, it will live or die by the quality of testing. This includes the knowledge of what processes to test and who by, and the quality of the test scripts, plus lining up the right resources. Automation can have a ROI depending on what you are doing down the line and needs to be considered on its own merit. But if you have poor process ownership, poor test scripts and vague execution, then I promise you that your upgrade will either fail, or be very painful during User Acceptance Testing, or after the upgrade itself.
Consider the wider business roadmap
Those organisations that I'm dealing with that are most engaged about doing a SAP upgrade, are including the upgrade assessment in the context of a wider business roadmap. For example, what is the M&A strategy and how does this relate to ERP? What is the Finance and HCM strategy - for instance around Financial Supply Chain Management or Talent Management? When done well, a SAP upgrade often sits as a necessary step and enabler in a wider business strategy.
Consider landscape strategy and other significant events
My rule is as follows: change many, test once. Because quality testing resources are so hard to obtain in most organisations, the risk of changing a bunch of things is much lower than the risk of running multiple parallel similar projects. And what this means is that infrastructure changes like replacement of equipment, strategic changes like a move to the multi-langauge Unicode version of ERP and fiscal changes like moving to a new RDBMS vendor are well considered at the same time. This can help with value engineering.
For example in one customer we are upgrading, we are moving from one platform to another, converting to Unicode and also upgrading to the Business Suite - all at the same time. For them, this made a compelling business case that allowed them to do the project - slashing Infrastructure costs and Operational Expenditure.
Consider future business state - especially around shared services
The SAP Business Suite 7 has a lot of features, functions, shiny things and flashing lights. Far too much for any one person to comprehend. However, there is one area of obvious major value which is worth considering - Shared Services. This can be Financial Shared Services, IT Shared Services or HR Shared Services - all of the above are well catered for.
By empowering employees to do more themselves (online or mobile time sheets, expenses etc.) and by consolidating operational teams, it is possible to dramatically cut the cost of running Shared Services departments. What this means depends on your organisation, but it's well worth looking into - some organisations are saving tens of millions a year.
There will be a few killer features
In every exercise of this kind that I have seen, there is one or two killer features that will provide massive business value. There's no point in going into them here because it's completely different from customer to customer, but they will be in there. Perhaps it's some obscure function of profitability analysis that allow you to increase profit margins. Perhaps it's an in-memory capability to improve planning. It's different for everyone but there will be one or two really relevant things in the detail. Spend some time getting to know the business units so you can claw this value out of the upgrade.
Contemplate Revert-To-Standard on a case-by-case basis
Your R/3 system will be heavily customised. In a few places there will be places where SAP have moved their solution on from when you originally implemented it, and what you need to do can be better done using newer standard SAP functionality. Where there is value in this, you should consider removing the customisation from SAP and reverting to standard. This reduces the costs of future change, but more to the point, standard SAP functionality will be better integrated with the rest of the Suite and you may find some value that you couldn't previously get.
I may have made this all sound very hard. It is an upgrade to your biggest and most important IT system, in many cases, and the effort involved shouldn't be underestimated. But with that said, my experience is that customers massively overestimate how hard it is. And in many cases, provided you don't need a business case, you can do this as a mostly technical activity, with some business and functional input.
However if you need to build a business case, then I hope the advice I give here will help you run a slick and simple process to find out where the value is in your business, and articulate why an upgrade to SAP Business Suite can help transform your business.