Among the three variations for SAP software reimplementations are two key approaches. You either make the changes to your existing production system (or a cloned copy of it), or you make the changes in a pristine, newly designed environment.
SAP Cloned Production System “Re”-Implementations
Making changes in your existing production system (more likely in a cloned instance of it) ensures data consistency and ease of adjustment. However, several difficulties are involved. If you have a significant number of custom-coded solutions, you will have to fight them every step of the way. You will have to work around them, deal with them throughout the process, adjust any out-of-date coding, and most likely end up keeping many of them. As you can tell, I am not a big fan of an SAP reimplementation in a production system with lots of custom coding.
You either make the changes in your existing production system or in a newly installed instance with no data.
For example, if you decide to consolidate organization structures from a multi-system environment, you might quickly discover many hard-coded values in custom programs. These hard-coded values in the programs themselves, rather than table-driven values and parameters, can cause system consolidation nightmares. This is just one type of problem that many custom-coded solutions cause.
Another problem occurs with any of the existing system configuration. If you make changes to existing objects that are already in production, you face the challenge of timing and coordinating your cutover to prevent disruption to existing processes. Depending on your circumstances, if you decide to do a transition in your own production system with the eventual goal of moving away from it and into a cleaner environment, then you may want to create all new custom configuration objects. Ultimately however, you must make that determination.
Clean SAP Re-Implementation with Old Legacy SAP for History
The other approach to SAP re-implementation is to do a re-implementation in a clean, non-modified system. That approach assumes that after conversion to the newly designed environment, you will leave your old “legacy” SAP system in place for reference and historical data only. Using a new system for a re-implementation means that you do not have to work around any of the poor setup or design decisions that were made previously. You avoid all of the headaches with the custom programs and only bring in custom programs that are business critical.
If necessary, and if you already have a BI/BW/other reporting system, you should complete some additional work to integrate old data structures with new ones. However, even that will be easier with standard functionality. The SAP BI/BW/BObj reporting options already contain a number of standard extractors that can be used more easily and with less expense.
The Optimum Solution is a Phased SAP Global Instance Harmonization
The most cost effective way I have found over the years to do a reimplementation is to bring in an operation that is moving to SAP in a “clean” environment. It is not particularly complicated to integrate two SAP systems using ALE (Application Link Enabling). In this way you create a new environment, with more up to date and more standard functionality that you can eventually migrate other business units into.
As upgrade projects occur, migrating the upgraded companies into the less customized environment only becomes incrementally more expensive. With an upgrade, you still have to do the custom ABAP program reviews, code validations, etc. With a cleaner environment without all of the custom-coded artifacts, you can more easily pick and choose what is really of value and what new or better understood functionality can replace.
For additional rollout locations, bringing those companies or organizations onto the more standard SAP environment has virtually no additional cost over the rollout project. In fact, the reduced custom coding is often less expensive because the amount of time spent regression testing custom functionality or fixing any organization-specific settings, as well as training people how to deal with some of the custom functionality, is lower. Consulting time, and therefore consulting cost, is lower as well, because the closer you stay to standard, the larger pool of resources available to make or adjust system settings.
SAP Organization Structure and Master Data Harmonization
One other possible project approach is to do the SAP Org Structure harmonization in all of the separate SAP global instances and then agree on the common master data types. At “go-live,” you extend all of the existing data in each production instance to begin executing with the new structure and master data types in each production instance. By doing this, the legacy data and org structures stay in place so that little or no business disruption occurs. You will need a transition period of approximately a year to complete at least one full annual financial close under the new structures and data in the existing production system.
By using this approach, you are actually making the transition in two steps. First, you build out the new state in your existing system. Then, after flushing out and adjusting most of the issues, you do a conversion or cutover to a clean system after a financial close. This approach allows for an orderly transition from the old to the new with relatively little business disruption. While the old SAP org structure elements and master data types are being made obsolete, they are still available for all processing and reference purposes.
Some of the key considerations for this approach involve what to do with custom coding and how to transition the master data. It is impossible to know what custom coding that standard functionality might replace. However, some new data types may help resolve the issue of moving off the custom coding in the same system. Eventually, the goal should be to upgrade away from the custom coding and into more standard functionality, unless you have some clear business justification preventing this.
The thought of a reimplementation seems like a crazy idea but from the way you describe it perhaps not so much with SAP. Since I have never directly supported an SAP environment my view is based on other ERP/MRP platforms most of which this would not be advisable.
Thanks Jerry for your comment and reading the post. Unfortunately I’ve seen WAAAyyyyy too many hacked together SAP systems. And there are various reasons for it. Some are the client just insists that it has to be re-done. Sometimes it is the System Integrator who had less than optimal resources and everything became “custom” or it was part of their “squatter” model.
Whatever the reason, SAP unlike some of the other ERP / MRP packages has enough depth and breadth that significant amounts of customization are truly not necessary. Unfortunately the depth and breadth of that functionality also means that you can’t just FAKE your way onto an SAP project and do a good job. Unfortunately the SAP marketplace is also filled with too many who scam their way into an SAP project and then make a mess. As a result sometimes a reimplementation is the best route.