Business Solutions with SAP

Phase 6 RUN SAP ASAP Methodology

March 26th, 2012 by

Anyone who has been around SAP for any period of time is reasonably familiar with the SAP ASAP Methodology.  In fact I rarely see sales presentation materials from many system integrators which do not at least mention it.  Even some of the bigger integrators with custom methodologies may reference it in passing and show the SAP Implementation Roadmap to demonstrate how their methodology has some similarity to it, or supplements some of the few gaps that may remain.  In a previous post on Why Use the SAP ASAP Methodology? I evaluated the SAP ASAP Methodology compared to SAP partner custom methodologies.

As of today it seems there are few of the SAP partners who are familiar with the latest Roadmap Phase 6–, the “RUN” ASAP Methodology enhancement.  This methodology enhancement is probably one of the most significant methodology changes offered since ASAP was originally introduced.  This is the key phase which relates to IT organizational maturity, to integration of the SAP support organization into the business after you go live.  In other words, this is one of the critical success factors for your SAP program.  That critical success factor is that SAP Program Management Requires a Type of CMMI.

Before we go into the little known Roadmap Phase 6 “RUN” enhancement let’s take a quick look at the first 5 phases of the SAP ASAP methodology most of us are familiar with:

  1. Project Preparation (before the consultants begin)
    • Project goals and objectives
    • Clarify scope
    • Schedule, budget plan, major milestones, and deliverables
    • First pass at a WBS and task based project plan.
    • Project organization, committees, and resources
  1. Business Blueprint
    • Design the future state
    • Revise and refine the project plan
    • Gain approval of all project templates and deliverables
    • Refine scope, resources, and schedule
  1. Realization
    • Build the solution
    • Test / adjust / correct the solution
    • Develop end-user training (courses, logistics, schedules, etc.)
  1. Final Preparation
    • Finalize end-user based testing, user acceptance testing
    • Perform final data conversion rehearsals (mock conversions with live data)
    • Test the final cutover script
    • Resolve any open issues or gaps
    • Perform final setup activities related to printing, interfaces, external systems, third party software, etc.
  1. Go-Live
    • Transition the enterprise to the new SAP system
    • Support the live environment with any needed fixes or enhancements
    • Optimize system performance
    • Transition to site support (help desk, etc.)
    • Close the project

At a very high level this is the SAP ASAP Methodology (without the latest addition).  But what about Phase 6?  What about the RUN ASAP Methodology?

RUN SAP ASAP Methodology

A few years ago SAP introduced a stand-alone version of this approach and methodology for post go-live SAP system support.  It is now incorporated as a key part of the overall ASAP Methodology in version 7.x onward.

While Roadmap Phase 6 is mostly focused on moving customers along to independent support, and toward an SAP Certified Center of Expertise (SAP CCoE) there is much more to this phase.  The most comprehensive tools, resources, templates, and development are around empowering SAP customers to support their own systems.  This is part of the “Internal” focus as I have described it in SAP Enabled Business Transformation for IT Leadership. From an SAP perspective there are 2 key reasons why this portion of the ASAP Methodology enhancement is “built out” 1) the more you support your implementation the less maintenance and support you need from SAP (i.e. you are carrying some of the cost of your own support), and 2) that is the relatively “easy” part of the support paradigm.

See the Series on SAP Competency Center or SAP Center of Excellence for supplemental material to make the transition beyond the “internal” focus to Enterprise and eventually External market focus.

While the Phase 6 RUN ASAP Methodology focuses heavily on areas of support which benefit SAP there are several areas which are critical for the strategic and business integrated IT organization.  The SAP “Certified Center of Expertise” is the first step to ensuring you gain the trust and confidence of your business counterparts.  The Phase 6 RUN ASAP Methodology does not end with that first portion which benefits SAP.  Even though the material and templates are sparse for moving very far beyond this “internal” (CoE) focus there is still significant substance and some meaningful templates for moving your SAP organization to the next level of “enterprise” focus.  This is where your SAP support organization begins gaining wider acceptance as a business peer.  If you haven’t had the opportunity to get familiar with the Phase 6 RUN ASAP Methodology section you might want to do that today! 

This phase should be reviewed during the Project Preparation phase and elements of the future state SAP organization incorporated into your overall SAP project plan, project approach, goals, milestones, deliverables, and especially any Organization Change Management program you begin.  Part of that initial evaluation of the RUN Methodology enhancement would be an internal organizational assessment to get a baseline of where you are, as well as what it will take to go to the next level by the time the project goes live.  THIS should be a critical part of your project planning right from the beginning.

If you are an SAP customer, or if you are considering an SAP solution and would like access to the SAP ASAP Methodology and tools contact me today.

Related Posts:

Global SAP Instance Consolidations

January 24th, 2011 by
SAP Business Software Integration

SAP Integration

Over the last several years a number of companies have undertaken a global instance consolidation.  And it’s no wonder why, a global SAP consolidation presents opportunities for significantly reducing Total Cost of Ownership (TCO).  But this type of system consolidation brings numerous change management issues to address.

As you embark on your consolidation there will be some major issues that are easier to resolve because the hard decisions around processes and scope were resolved during an initial implementation and production support process.  On the other hand there will also be difficulties around resolving the conflicts about standardizing organization structures, business processes, and “sacred” developments which were done in some of the instances.  Each of these areas presents a point of possible conflict requiring cooperation, compromise, ownership, and change management.

To reduce the amount of customizing, shorten the duration of the consolidation, and ensure needs are met with more standard functionality rather than ever expanding lists of custom programs it will be important to:

  • Take inventory of the implemented system landscape (modules implemented, external systems, interfaces, middleware, etc.)
  • Inventory of all custom developed SAP programs or applications
  • Inventory separately any custom fields and table extensions and their use
  • Harmonize the organization structures
  • Standardize business processes
  • Both harmonize and standardize master data types and requirements
  • Develop the sizing and new hardware requirements for the consolidated environment

While I am generally opposed to “As-Is” process mapping (see How “As-Is” Process Mapping Can Damage Your SAP Project ) it is important from a scope perspective.  In other words, to do a system consolidation correctly, an inventory of the existing systems is needed.

The successful companies who can focus on moving away from custom coded solutions will find their TCO reduced and application maintenance to be easier overall.

Prototyping Possibilities After SAP Global Instance Evaluation

There are some great places to start with analysis on how to integrate the different systems.  Generally I am a big advocate of using the SAP IDES system that is available to all SAP customers for evaluation.  It serves as a great platform to review standard SAP options that have not been dirtied by custom-coded solutions.

SAP IDES stands for “Internet Demo and Evaluation System” and can be used like other SAP applications, however it does not allow for transports to other systems and should only be used for evaluation reasons.  This explanation from a recent SAP OSS Note explains the SAP IDES use, and some of the summary information is provided here (see Note 799639 – IDES – General Information about the usage of IDES systems):

IDES demo systems and IDES demo landscapes are copies of SAP internal demo systems with the data of the IDES model company in several clients. The IDES systems can support demos, functional and tests, self-study or functional evaluation based on the preconfigured data/clients. IDES must not be used in production!

The IDES systems do not contain training data that are used in the SAP training courses.

Customer training etc. based on the IDES systems are not supported.

Client transports are not available.

Standard SAP Support Packages can be applied to the IDES systems.

From the technical point of view Enhancement Packages can be implemented into IDES systems.

IDES should only be operated as a separate installation. Each new release requires a new installation!

We do not recommend to upgrade an existing IDES systems.

As an SAP customer it is important to read through this note, and other SAP OSS notes carefully.

I advocate here, and always have advocated the use of the SAP IDES system as a reference model for evaluation of a totally standard application.  In this way you have a great platform to evaluate future state differences in a possible upgrade situation from the perspective of a “clean” vanilla system.  By using the IDES system you bypass any custom coded solutions and can see for yourself whether or not the newest solution will handle your issues.

By using the IDES system as a baseline you can quickly determine scope for what business processes you may wish to adopt while eliminating custom solutions or additional external systems.

Related Posts:

Aligning SAP Scope to Meaningful Business Requirements

April 13th, 2010 by

ERP or SAP Business Case, CRM, ERP, BI, and IT investment, where is the business benefit?I’m always amazed at how many projects miss one of the most important (and relatively simple) scoping requirements.  The worst part is that projects don’t just miss it but they get it completely backward!

After doing SAP projects since 1994, I still can’t believe SAP’s customers don’t use the old “Seven Habits” step of starting with the end in mind.  What do I mean by that? 

Start your SAP project with REPORTS and BUSINESS requirements! 

Come on now, WHY do so many projects wait until they are live with some new system to figure out what the reporting requirements are?  Reporting requirements must become part of the initial SAP scoping exercise.  Even if it is not spoken, every business that undertakes a massive ERP or IT project like SAP wants actionable information from the system after it is installed.  You want critical information that can enable you to:

  • Make better management decisions
  • Make better financial decisions
  • Determine what products or services have good margins (and which ones don’t)
  • How different product lines or geographies are performing
  • What future business directions you should take based on ACTIONABLE information
  • What competitive pressures in the marketplace to focus on
  • Etc.

Aside from the operational automation and getting business processes defined, reporting is the key for :

  • compliance,
  • operations decisions,
  • sales and product (or service) decisions,
  • and for every part of the business. 

Reporting is so critical to a business yet on almost every project it is treated as an afterthought.  Too often “reporting projects” start after the system is in place and people start working in it.  From a budget and cost perspective you don’t need all of your reports done as soon as the system is installed, but the system must be designed from the beginning to support all of the data needed for those reports.  It must be designed from the start to produce actionable information after the operational and automation components are implemented. 

If you start from the beginning with your reporting requirements you can ensure that the system design addresses any reporting gaps.  By doing this from the beginning you will not have the system installed and then be disappointed that it does not provide you with the key actionable information you need for your business.

Using Reports for Driving Meaningful Business to IT Alignment

Without knowing in advance what the final actionable reporting requirements are you will not be able to take advantage of some of the really great information that a system like SAP can offer.  When an SAP system is properly implemented and constructed SAP provides mountains of data and field options.  There is the ability to add custom fields, re-purpose existing fields [FN1], and add other data dimensions so that you can track and report on any piece of information in any way you can imagine.  However, if this is not planned for in the beginning, and then set up and trained so that you can maintain that data, then after you go live you may be disappointed. 

If you do not do this up front exercise you may discover that you need certain key data requiring expensive rework, expensive customization, and additional time budgeted.  And in the worst case, depending on the system design, you may end up creating a design dilemma causing even more trouble down the road.  Worse still you may discover that the way the system was designed and implemented may prevent you from ever realizing key decision-making information.

There is one other benefit from this approach as well.  By defining end-state reporting needs and end-state actionable information needs you can use this during vendor selection to separate the capable from the incompetent.  The ideal situation would go so far as to provide actual desired end-state reporting examples (field names, field values, etc.).

By doing this exercise you also have the additional benefit of focusing the entire project, right from the beginning, on the end-state goal.  This will help to distill the project down into actual business needs and business requirements for success.

Where to Begin with SAP Scoping and Reporting

Every customer considering an SAP implementation should carefully read through the article on developing an SAP business case (ERP and SAP Business Case for ROI, Business Benefit, and Success, PDF version attached here). 

The key steps to getting the most from your SAP implementation or your SAP scoping exercise is to start with the tools and resources SAP provides free of charge to their customers (and prospects).  There are a couple of tools in particular that every customer, or prospective customer should insist on working with before doing their SAP implementation.  The first is the SAP Solution Composer [FN2], it is a free download and it is a great tool for understanding how to scope your SAP implementation.  As mentioned in the article linked above on developing the SAP business case, it is a great tool for:

  • Developing an initial scope
  • Creating process lists for starting some of the critical change management discussions
  • Communicating in a “new” but common language about the processes.

The next tool available for a high quality project is the ASAP methodology.  It is an active HTML and Java script based repository which contains templates, resources, materials, and a project plan for ensuring you have a successful implementation or upgrade. 

Take Inventory of Your Existing Reporting Landscape and Define Desired Metrics

After your initial SAP scoping exercise it will be important to take an inventory of all of the spreadsheets, databases, and system reports that exist.  From these you can get a good idea of what will need to be accommodated in the system.  And from these existing reports the master data requirements that are required can also be derived.

After gathering the existing reports, begin short duration management workshops to define desired reports.  In other words what has been lacking from the business decision-making process that would provide strategic or tactical insight going forward.  For more information on one reporting and metrics strategy see the posts related to defining and understanding real Key Performance Indicators for business performance (see Why Indexed KPIs are Critical for Business Performance and Success, and Using Key Performance Indicators for Building a Strategy Focused Organization).

Once the initial operational requirements, existing reporting requirements, and desired reporting requirements are defined a final scope and blueprint can then be determined which will propel the business forward strategically into the future.

Conclusion / Summary on

Early Reporting Requirements in SAP Scoping and Blueprinting

In the end I’m still suprirsed at how many organizations finally get around to SAP reporting requirements after the system is already implemented an in place.  Just because you consider and plan for them from the beginning does not mean that you have to complete them by the time the system is in.  On the other hand, you will need them at some point so having the key data and understanding the business drivers for key information is crucial in your SAP implementation.

Too often the reporting metrics, goals, and drivers for business decision-making are treated as an afterthought.  Those reporting metrics and the business goals, key performance indicators, or business direction they represent are generally the reason for the huge investment in new systems to begin with. 

Stop and think about it, how will you ever know if any of the business-centered success criteria was delivered if you don’t have a clear direction in advance?  Those reporting requirements must include current and desired actionable data requirements in some measure of detail.  Certainly as a company and then during the sales cycles the buzz words and generalities of the information end-state are discussed;

  • during the early research,
  • during RFP preparation, and then 
  • during the vendor sales cycles when all of those promises are made about a “future state” for your business. 

Some of the actionable data requirements, or efficiency improvements, or competitive improvements, or other business drivers are also explored during this period.  If they are not captured and distilled into some detail, and then included in your RFP and project charter how will you know if they were ever delivered without defining these critical business justifications for the system to begin with?

One other thing to keep in mind is that no system, no matter how good or how well implemented will change a business by itself, but properly implemented it will provide the actionable information to make sound business decisions for marketplace success (see also SAP as a Change Enabler, Using SAP to Improve Revenue and Profitability, and Change How You Look at SAP to Create ROI).

[FN1] SAP provides a huge number of fields that are never used on most projects.  Some of them are directly tied to application functions and can not be used, still others are not and without doing any custom coding or application changes you can use some of these fields for other purposes.  This “re-purposing” of some fields is a very easy, cost-effective way to solve a number of issues.

[FN2] Go to and search for “Solution Composer” (or use this link – retrieved 4/13/2010).

Additional SAP Project Success Reading:

ERP and SAP Business Case for ROI, Business Benefit, and Success

Why SAP Projects Fail to Deliver ROI (and How to Change IT)

Related Posts: