SAP reimplementationSome time ago, I started a series on doing an SAP reimplementation for little more cost than a technical upgrade. While I have done these reimplementations, a few interesting scenarios added new complexities that need to be addressed. For example, how do companies deal with a seriously fragmented application landscape? We especially need to consider this issue in large enterprises where each company code, location, business unit, or other area decided to implement their own SAP applications independent of the others. Additionally, companies with rollouts or upgrades underway may experience issues. For them, the situation is a little different. As a result, I have decided to try to wrap this up with a focus on three key types of situations outlined below.

Please see the following previous posts on this topic for further review:

This topic is difficult, just because we need to consider so many “dimensions” of options. As a result, I have narrowed the focus to a few key areas.

Primary SAP Reimplementation Approaches or Options

As I pondered more and looked at the re-implementations I have done, as well as some of the system assessments and options, I finally decided to “bracket” them with a few key approaches. Because the numbers of options for re-implementation are too significant to address here, I decided to stay at the high level to cover the major approaches:

  1. A reimplementation of a single SAP production instance.
  2. Integrating a landscape with multiple SAP production instances onto a single global instance.
  3. Rollout, whether it is an incomplete, ongoing project, or a fully implemented system that you are considering an upgrade for.

SAP Reimplementation Assumptions

As I wrote previously, one of the crucial considerations for a re-implementation is to move away from Software Engineering and toward business process engineering. First, let’s establish a few very basic assumptions about an SAP reimplementation:

  1. After you went live, or as you continued to roll out your solution, you discovered several “If we had known ‘x,’ we would have done ‘y.’”
  2. Or, you may have incorporated a significant amount of custom code, or custom application development (inside or outside of SAP) and discovered that standard functionality would have met about 90% (more or less) of your requirements (for more information, see SAP Implementation Focus, Software Engineering or Business Process Engineering?).
  3. You have already worked through the hard stuff in your original SAP implementation (see the section by this same title in SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1). In other words, the hard decisions around the processes, organizational structures and data types have already been made.
  4. You may have additional functionality or other modules you want to implement, only to find that custom-coded “solutions” are making them difficult to bring in.
  5. The custom coding is requiring significant amounts of time for break-fix testing, integration testing, regression testing, SOX or other regulatory compliance when any new change is added.
  6. As new regulatory or other industry requirements are established, in whatever jurisdictions your company operates, you have to custom code new solutions to meet them (rather than using SAP’s standard maintenance to add the new functionality).
  7. The time to work around all of the customized “solutions” when you want to add new functionality, or new modules, takes a significant amount of time.
  8. In some cases, adding on brand new functionality is nearly impossible because of how much your system was “hacked together.”
  9. You need to upgrade, but there are probably hundreds, and in some cases thousands, of custom programs to evaluate, test, integrate, and update to the newer version of ABAP.

Coming up, we will start to review the three key types of re-implementations: a single production instance, consolidating multiple instances into a single global instance, and a re-implementation rollout.

Related Posts: