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 there is still way too much custom coding and redesign of the software (see e.g. SAP Implementation Focus, Software Engineering or Business Process Engineering?).
If you are an SAP shop considering an upgrade it may be time 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 there were poor design decisions from the original implementation, 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.
A reimplementation when done correctly, 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, if you have heard lots of comments like:
- “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.,
then 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 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–, not easy, but 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 there wasn’t enough attention given 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, and 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 way 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 consider the amount of ongoing support that would be needed
- Maybe the consultants didn’t know how to segment and stratify customers for better sales and pricing processes, etc.
- Is your availability checking terrible or non-existent and you have 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 about 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 there is standard SAP functionality to 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. It is taking far too long to provision security and there are significant delays in provisioning user roles.
The number of dumb SAP design and implementation scenarios I’ve seen over the years are too numerous 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. There could be any number of issues or reasons, but let’s just say 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, there is a way to 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. And by close to standard I do not mean that you didn’t do any user exits or with newer versions 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, the key issue to remember is the application is supposed to support the business and produce business value. When you consider the huge investment and the impact to the business it is important 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 can be done to gain real return on investment.
Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.
- upgrade vs reimplementation