SAP’s application landscape has the depth and breadth of functionality to handle 90% (and usually more) of nearly any business requirement. Regardless of this huge depth and breadth of functionality, many businesses still custom code and redesign the software too much (see e.g. SAP Implementation Focus, Software Engineering or Business Process Engineering?).
If you are an SAP shop considering an upgrade, you may need to take a hard look at whether you should do a technical upgrade or a reimplementation. As you probably know, a technical upgrade means taking what you already have — the good, the bad, and the ugly — and then converting it all, as is, to a new version. This includes the existing custom coding, processes, system settings, and all of the existing landscape. If the original implementation had poor designs, or bad coding substitutions for standard functionality together with security and authorization design problems, then you carry all of that trash forward.
In many cases, a reimplementation does not have to be much more expensive than a technical upgrade.
When done correctly, a reimplementation looks at the existing system landscape and evaluates the gaps. You evaluate where the system could be redesigned to deliver on the original promise of SAP’s ERP application suite.
Considerations for an SAP Reimplementation
After you went live with the implementation, you may have heard many comments that include the following:
- “if only we had known X?” or,
- “why didn’t the consultant tell us we could do Y?” or,
- this is too slow, painful, difficult, complicated, etc.
If so, you might be a good candidate for a reimplementation.
For example, after being live you might discover that the original SAP Organization Structure did not provide you with key information you need for good reporting. SAP standard LIS and SIS reporting provide you with little value because of this less-than-optimal organization structure. You might find that the pricing implementation was less than optimal and has lots of restrictions. After being live for a while, you might also discover that your supposed experienced consultants didn’t really know about SAP’s capabilities, and that all of those pricing or order-related processes they told you couldn’t be done are actually possible. Sure, they might not be easy, but they can be done with fairly standard functionality. The reasons why your original implementation was less than optimal may be limitless, but you have learned a lot since then.
- Maybe the team didn’t give enough attention to how the SD or MM org structures would impact reporting requirements.
- Maybe it has too much granularity or too little. Maybe you needed geographical elements included in the org structure, or maybe product line dimensions, or maybe sales office/sales territory information.
- Maybe that “experienced” consultant had no clue about your GL Account Determination, or about complex pricing. Maybe they misled you and told you SAP didn’t support what you wanted to do with pricing or accounting because they didn’t have the level of expertise you paid for.
- Maybe the SAP “expert’s” design produced too many pricing conditions, or huge amounts of master data to maintain.
- Maybe they didn’t consider the live system master data maintenance requirements, so the solutions they designed did not even take the needed ongoing support into account.
- Maybe the consultants didn’t know how to segment and stratify customers for better sales and pricing processes.
- Is your availability checking terrible or non-existent, causing bad promise dates?
- Is the backorder processing difficult or non-existent?
- Maybe the SD or MM or PP consultants were completely clueless about Sales and Operations Planning (S&OP) and left you with little or no forecasting and supply planning abilities.
- You might find that your Materials Management (MM) consultant was clueless about MRP or supply chain planning.
- Maybe the MM consultant didn’t have the critical experience for a good design around purchasing organizations, purchasing groups, PO pricing, material account determination, etc.
- Maybe your Inter-Company supply processing is painful with full transaction processing for an entire sales and purchasing process, when your “expert” never told you there is a simpler way with standard functionality. Or, you might have to manually do eliminations for Inter-Company clearing, but your “consultant” never told you standard SAP functionality can do this automatically.
- Maybe your PP consultant told you that you couldn’t do in-process subcontracting for subassemblies in the production process. Or, maybe the MM consultant made a mess out of your subcontract process by setting up storage locations or plants to represent the subcontract vendor (rather than using standard SAP subcontract functionality).
- Security authorizations are a mess, and nearly everyone has their own custom authorization. As a result, provisioning security and user roles takes too long.
The number of poorly done SAP design and implementation scenarios I’ve seen over the years are too many to list. I could go on and on with different examples across the entire application.
Your SAP Implementation Should Not Have Been So Painful
What it comes down to is your initial implementation was less than optimal. You paid a fortune for a bunch of custom hacks rather than using standard SAP functionality, or a lot of functionality gaps for important business functions. You may have ended up with overly complicated processes and difficult-to-manage data requirements. For any number of issues or reasons, you’re not too happy with your previous implementation results.
If you’re not too happy with your results, you are probably a good candidate for a reimplementation.
Before you panic, you can do a reimplementation on a reasonable budget, and without the huge pressures and stresses of your original project.
SAP Technical Upgrade Considerations
If you are very happy with your system, and your user community has seen improvements and efficiency gains with the original implementation, you are probably a good candidate for a technical upgrade. Keep in mind that a technical upgrade is taking exactly what you have, without any significant changes, and then converting the system landscape to a new version. Regression testing is done to ensure that previous functionality is not broken and that any custom programs still work as desired.
One other consideration for a technical upgrade verses a reimplementation is whether or not you kept the application fairly close to standard. By close to standard, I do not mean that you didn’t do any user exits (or with newer versions not make use of any of the enhancement points)– in other words, your “experts” didn’t invent new custom-coded applications where a standard solution would work.
Even during a technical upgrade, you may be able to make some adjustments and modifications, but they are more like minimal tinkering.
Conclusions on SAP Upgrade or SAP Re-Implementation
At the end of the day, when you are considering your SAP landscape, you need to remember that the application is supposed to support the business and produce business value. When you consider the huge investment and the impact to the business, you need to get real value from your SAP implementation. As you prepare for your upgrade, that is the key time to evaluate, or re-evaluate the business drivers for your technology spend and consider what you can do to gain real return on investment.
