SAP & ERP Consulting from the Customer Point of View

SAP Reimplementation

Some time ago I started a series on doing an SAP reimplementation for little more cost than a technical upgrade.  While I have done these, there were also a couple of interesting scenarios that added new complexities which needed to be addressed.  For example, how do companies deal with a seriously fragmented application landscape?  This is esepcially true in large enterprises where each company code, location, business unit, or other area decided to implement their own SAP applications independent of the others.  Then there are the companies with rollouts or upgrades underway.  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.

To review the previous posts on this topic, please see:

• Technical SAP Upgrade or SAP Reimplementation
• SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1
• SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2

This topic is difficult just because there are so many “dimensions” of options to consider. As a result I’ve narrowed the focus to a few key areas.

Primary SAP Reimplementation Approaches or Options

As I pondered it more, and looked at the re-implementations I’ve 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 ongoing project that is not complete or a fully implemented system and you are considering an upgrade.

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 (see SAP Implementation Focus, Software Engineering or Business Process Engineering?).
3. You’ve 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 and 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:

• SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2
• SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1
• Technical SAP Upgrade or SAP Reimplementation
• Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
• ERP and SAP Business Case for ROI, Business Benefit, and Success

ASAP Methodology Background

In the mid 1990’s SAP had gained a significant amount of bad press and publicity around several high profile project disasters that the company knew were completely avoidable. At that time Oracle, Baan, JD Edwards, and PeopleSoft all had sales people making the case that SAP was too expensive, too complicated, and took too long to implement. In response SAP released the ASAP Methodology in the mid-late 90’s (around 1996 or 1997) because of the number of SAP projects that were going over time, over budget, and were at risk. It has been refined, polished, enhanced, and adjusted with SAP’s supported R&D resources and efforts for about 15 years now.

The ASAP implementation methodology has leveraged the PMI (Project Management Institute) best practices around project delivery and the Carnegie Mellon CMMI (Competency Maturity Management Integration) approach for maturing the delivery process. The ASAP methodology also includes a number of ITIL (Information Technology Infrastructure Library) components in the Phase 6 Run and the ValueSAP portions of the methodology. Agile techniques are an option which can be “turned on” if you like.

The toolset includes an implementation “Roadmap” which is a WBS based project template. It has full explanations, templates, tools, resources, checklists, etc. Together with that the original version also included an MS Access, and then an MS SQL Database application for selecting your solution options which would then generate a list of processes, transactions codes, template BPPs, and a full SAP centered Blueprint document, etc.

Today all of that functionality is still available but it is housed in Solution Manager. The ASAP Roadmap is just ONE component of the entire ASAP Methodology. The Roadmap is focused on effective Program or Project Management for accelerated project delivery with high quality results.

My Experiences with the SAP ASAP Methodology

I was originally certified in the ASAP Methodology in 1998 while at Grant Thornton. In that time I have had the privilege of using ASAP on several projects and as the project manager on a few. One consistent result of using the methodology is that projects are delivered and they are usually delivered on time and on budget (although not always).

Every major SAP system integrator claims some methodology and nearly all of them are similar to, or variations of the SAP ASAP Methodology.

I have only ever seen significant problems with ASAP when a system integrator started to use the methodology and then abandoned it part way through the project. At one recent client I used it as the framework to support a LEAN implementation methodology. That LEAN methodology has served as an ongoing framework to significantly accelerate numerous rollouts at probably 25% of the normal implementation cost of other SAP projects.  This was driven by the client project manager and facilitated by using the ASAP tools. 

Starting with the ASAP Methodology

Even before the first consultant comes on board the ASAP methodology provides templates and resources to cover key project and program management areas such as

• communication planning
• decision making
• risk management
• project management master planning
• resource planning
• steering committee tools
• external links to best practice resources for reference (PMI, ITIL, Internal SAP, etc., etc., etc.).

Why ASAP Instead of a System Integrator Methodology?

First, I have nothing against the system integrator methodologies and some are very good with great resources. Unfortunately my experience has been while they have them, and may start with them, they rarely stick to them throughout the project. Since it is their methodology you have little or no insight to cross-check or validate their methodology use.  With ASAP it is yours to use as an SAP customer and you have full insight into it and control over its use.

One of the primary reasons for using the SAP ASAP Methodology is like all things SAP there has been a mountain of R&D spend, development, adjustment, and support. Every SAP client (large or small) who uses the ASAP methodology can avoid the “proprietary methodology lock-in” which the system integrators will walk out the door with. Another important reason is you own it as part of the standard Solution Manager offering. 

As you probably know Solution Manager is already a required part of your SAP landscape.  The SAP Solution Manager portion of the ASAP Methodology can house key items related to scope, configuration, documentation, the implementation roadmap, and all of the key deliverables. As the system integrator rolls off the project you have a centralized repository which is SAP specific for any future employees, support, upgrades, etc. You do NOT get that with a “custom” system integrator methodology which is probably based significantly on SAP’s ASAP Roadmap to begin with. Using an SI methodology you will NOT get the full configuration and development scope monitoring tools which Solution Manager contains either.

The entire ASAP Methodology is part of your application licensing and support you pay for. Why not at least take it for a test drive and see what it can do.

For more information on the SAP ASAP Methodology for SAP customers use your SAP OSS ID and log onto http://service.sap.com/asap .

Related Posts:

• SAP System Vendor Project Success Criteria 1
• SAP IT Governance, SAP Program Management, SAP PMO Metrics
• 7 Tips for Effective Client Management of SAP Consultants
• SAP Program Management Requires a Type of CMMI
• Steering Committee Governance for an SAP Center of Excellence

The most frequent response around accountability for program or project managers was a call for ”independence.” So when I raised the issue of project manager or program manager accountability, metrics, performance, and how to ensure project messes are avoided there were no takers.  Is it any wonder so many business application projects and programs get into trouble, go over budget and time?

SAP Program and Project Management Office Success

A good Program or Project Management Office provides the resources needed for delivery project participants to be successful.  Without this focus the value of an SAP Program or SAP Project Management Office is not realized.  The U.S. Department of Energy did a good review of performance and benchmarking for project management.  And while this was applied to a government program there is a lot of valuable insight for any SAP project or business application project [FN1].  

The U.S. Department of Energy had a committee evaluate success criteria and offered four sets or categories of performance measures to cover the 30 possible discrete measurements of project or program success.  Those four sets or categories were [FN1, pg. 1]:

• Project-level input / process measures. Assess the resources provided to deliver an individual project and the management of the project against standard procedures.
• Project-level output / outcome measures. Assess the cost and schedule variables of an individual project and the degree to which the project achieves the stated objectives.
• Program- and department-level input / process measures. Assess the total resources provided for all projects within a program or department and the degree to which program- and department-wide goals for projects and their management are met.
• Program- and department-level output / outcome measures. Assess overall project performance and the effectiveness of completed projects in supporting program and department missions.

Without this type of analysis and evaluation your project may be headed for trouble before it even begins.  When you start your large business application project what type of deliverables, output, or results do you expect from those who are leading the projects?  How will you measure and evaluate their performance?  If your evaluation of their performance is focused on how well they support the success of delivery teams, along with how well the projects are delivered (budget, scope, schedule, and quality) then you will be measuring the key project delivery values for success.

That same U.S. Department of Energy study provided guidance on the key components for a successful performance measurement system of program or project managers which can be applied to business software projects like SAP.  They noted key components of an effective performance measurement system include [FN1, pg. 7]:

• Clearly defined, actionable, and measurable goals that cascade from organizational mission to management and program levels;
• Cascading performance measures that can be used to measure how well mission, management, and program goals are being met;
• Established baselines from which progress toward the attainment of goals can be measured;
• Accurate, repeatable, and verifiable data; and
• Feedback systems to support continuous improvement of an organization’s processes, practices, and results.

The Answer for SAP Program and SAP Project Management Results

Over the years I have found the SAP ASAP Methodology helps to ensure SAP Project delivery.  The entire methodology is focused on project participant success; budget, time, and scope control; and quality control for project delivery. 

My non-cynical assessment for why it is not more widely used is because many SAP Program Managers and SAP Project Managers have not be trained to use these tools (or Solution Manager which contains them).  On the other hand there are some SAP Project and Program Managers who have a financial motive that can not be ignored.  They do not use the ASAP Methodology because it makes a client less dependent on them.  After all, why do you need an expensive program manager to deliver tools, templates, resources, guidance, quality control, and measurement utilities if you have a methodology that already contains all of this with step by step instructions to use it?

==============

[FN1]  Measuring Performance and Benchmarking Project Management at the Department of Energy. http://management.energy.gov/documents/performance_measures_final.pdf

Related Posts:

• Why Use the SAP ASAP Methodology?
• SAP Program Management Requires a Type of CMMI
• Steering Committee Governance for an SAP Center of Excellence
• SAP System Vendor Project Success Criteria 1
• The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors