Business Solutions with SAP

SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2

September 7th, 2010 by

SAP Upgrade

There are a number of important considerations in an SAP reimplementation that do not exist for a technical upgrade.  As a result the up front planning and evaluation time will be more involved.  For example you will have to consider any organization structure changes.  How will any new organization structure items map to old ones?

Then there is the analysis on how to handle old master data if the organization structure changes are so significant that they require a whole new master data paradigm.  If you have done a LOT of custom coding there may be a number of custom fields that you might want to handle differently.  Then you have to evaluate do you even want to bring those programs forward or do you want to use a “switched” framework that accesses the old data structures based on certain criteria but uses new or more standard functionality for newer items.  There are a lot of up front planning and evaluation considerations. 

If you are seriously considering an SAP upgrade and found this article, PLEASE take the time to get a little more key information about the upgrade options and considerations you have.  The following posts will help to clarify some of the direction to take on whether you should do a technical upgrade or a reimplementation:

Reduce SAP Application Lifecycle Costs by Going more “Vanilla”

One of the key goals of moving to more of a standard SAP system is to reduce application lifecycle costs by making upgrades quicker, easier, less expensive, and less risky.  Together with this the ongoing maintenance and additional functionality becomes less expensive to add.  When you don’t have all of that “software engineering” it is easier and less time consuming to add new functionality, easier to find knowledgeable consultants, and easier to find experienced employees for full time positions. 

One of the key steps in an implementation, or a re-implementation is to review the risk and cost of changes that have been or will be made.  You have to review all of that “software engineering” that was done rather than the business process engineering.  Since the focus of this post is on reimplementation we will look at the starting point for evaluating your upgrade project. The following development table, combined with the “frustration factor” (discussed later) will help determine if you are a good candidate for a reimplementation or a technical upgrade of your SAP system.

Start out by doing a careful evaluation of your current development and custom coding from your original implementation.  Then move on to understand where you have functionality gaps that you either expected from the original implementation or that the business found were important after you went live.

How do you know if you should consider an SAP Re-Implementation?

Probably the first sign you might be a good candidate for an SAP reimplementation is if you have an army of SAP support staff.  Some of the obvious indications you should consider a reimplementation rather than a techical upgrade are:

  • Your business probably has a massive IT department that looks more like a “full-employment” program for SAP skills.
  • You are highly dependent on contractors.
    • Contractors and consultants have become more like extended staff and staff augmentation rather than spot consultants.
  • Your SAP related support budget is beginning to approach the budget of some small countries ;)

Other things to consider that are not as obvious relate to the amount of business fit, custom coding, and business reporting requirements that we will look at next.

Evaluating custom development impact on your SAP upgrade

I have put together a table below related to development efforts (cost) and / or the risk involved with the development effort.  This table can be applied to a new SAP implementation or to an upgrade.  Whether that upgrade is a reimplementation or a technical upgrade this development table helps to understand the impact of a key part of the effort.

For an upgrade if all of your development efforts are in the Low to Average categories, and your “frustration factor” is low, you are probably a good candidate for a technical upgrade.  However, if there is much development work in the High category, or if the “frustration factor” is moderate to high then you are probably a good candidate for an SAP reimplementation.

Significant amounts of development in the High category (below) indicates that there may have been a number of custom coded solutions.  Unless these solutions were done to address a key business driver aligned with your company’s strategic direction or mission, and there were no other standard options you might want to reassess this type of development for a reimplementation.  This is especially true for any type of regulatory compliance requirement.  The reason it is critical there is because SAP maintains all of the system functionality to comply with the latest regulatory compliance requirements as part of your standard application support.  If a regulation changes SAP provides support and application changes for standard system functionality, not for custom coded solutions your system integrator invented.

Considering the frustration factor in your SAP upgrade

The other area to consider for evaluating a reimplementation or a technical upgrade is the “frustration factor.”  First, I’ll define the frustration factor as the failure of the SAP application to deliver on your business expectations.  This might be badly aligned organization structures that do not support easy reporting requirements; it might be partially implemented, poorly implemented, or not implemented at all functionality that supports a key part of the business; it might be any number of business reasons that the applications did not meet your business needs.

One of the other key areas where a reimplementation may be needed is if you are in a large enterprise with multiple SAP systems.  You may want to try to consolidate your SAP instances into a single system and a single enterprise-wide system.  The desire to consolidate systems onto a single application is one of the biggest reasons to consider a reimplementation, but this can also be one of the most challenging reimplementation types because of the amount of analysis of the delta in setup and design differences between systems.

SAP Technical Upgrade or Re-Implementation Conclusion

So, you’ve decided you are a good candidate for a reimplementation project.  You want to lower your overall SAP application lifecycle support costs; you want to ensure that future upgrades are less difficult and less expensive; and you have a pretty good idea of the delta of differences in your current system and what you would like to have; you also have a good idea of any additional functionality you would like to use.  So, where do you go from here?

Stay tuned, in a couple of weeks I’ll provide a post on the specifics and details of how to do a reimplementation in a fairly effective and efficient manner.


SAP ABAP Development Risk and / or Cost Table

Reports, Interfaces, Conversions, Enhancements, and Forms (RICEF or FRICE).

Note:  The following table provides some guidelines on how to judge the risk and / or cost of any development effort.  It is NOT meant to be a complete or comprehensive listing of the different scenarios or options.  There will always be other situations and circumstances which may fall into any of these categories. 

One other key consideration is that a piece of custom development may fall into the “Low” or “Average” area for actual development effort and cost but if it is mission critical, creates significant financial exposure, satisfies an external reporting reqiurement, or is related to a regulatory requirement it is automatically a “High” risk development.





  • Single table data extract (no joins)
  • One header description
  • Simple Ad-Hoc report
  • Minimal testing effort
  • A few input selections
  • A few header descriptions
  • Simple totals, subtotals, sums, or a few simple field calculations.
  • Simple table joins (generally 3 or less).
  • Data records and joins with one to one and in some cases one to many relationships.
  • Simple report layout
  • Simple Input / Output (I/O)
  • Moderate testing effort.
  • Mission critical; financial impact; external reporting; or regulatory impact.
  • Several input selections.
  • Several header descriptions
  • Complex totals, subtotals, sums, or field calculations.
  • Complex layout requirements.
  • Multiple headers
  • Complex Input / Output (I/O)
  • Complex or significant joins including many to many data relationships.
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well.
  • Simple change to an existing interface.
  • Manual trigger or simple batch processing.
  • Minimal testing effort .
  • Simple Input / Output (I/O)
  • Simple logic, little or no data transformation between interface points (i.e. no value lookup tables, no value substitutions, and few or no data value calculations within the interface).
  • Simple interface reporting requirements.
  • Single direction (inbound or outbound).
  • Single input or output record.
  • Moderate data volume.
  • Can generally be managed through periodic batch processing.
  • Moderate testing effort.
  • Mission critical; financial impact; or regulatory impact.
  • Complex Input / Output (I/O)
  • Complex logic with moderate to complex data transformation requirements (i.e. value lookup / reference tables, field value substitutions, field value calculations within the interface).
  • Multiple transaction formats
  • Complex calculations
  • Multi-directional
  • Real time interaction or involved batch processing (such as with batch job dependencies).
  • Average to High reporting effort (from above).
  • Moderate to high data volume.
  • Multiple input parameters
  • Multiple input or output records
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well.


  • Inbound data is well defined
  • Single source of data
  • Data is clean or cleansed prior to conversion
  • Data mapping is straightforward and one-to-one
  • Simple reconciliation required
  • SAP ALE distribution directly from one system to another without any changes.
  • Low data volumes.
  • Possible candidate for manual entry because of low data volumes and simplicity.
  • Minimal testing effort .
  • Data source is defined but field data formatting varies from source to input.
  • Multiple sources of data for a single conversion
  • Cleansing is defined via conversion routines
  • Complex data mapping but still one-to-one data relationships.
  • Only data formatting changes but not data value changes.
  • Easy to moderate data transformation rules from source system to input system.
  • Multi-step reconciliation of data conversions.
  • Use of control totals for value fields and record counts for data conversions.
  • Moderate data volume
  • Moderate testing effort.
  • Both field data values and field data formatting need changes.
  • Multiple sources of data and possible multiple data transformation steps.
  • Significant time and effort for data mapping and conversion routines between systems.
  • Complex logic with moderate to complex data transformation requirements (i.e. value lookup / reference tables, field value substitutions, field value calculations within the interface).
  • Complex calculations
  • Multiple sources of data requiring multiple mappings, or multiple table joins, and potential manual logic input.
  • Data cleansing and data transformation values must be performed outside of the source system (either in an intermediate mapping and logic step or in the receiving system as it is imported).
  • Data mapping contains potential many-to-many relationships or complex logic which is dependent on multiple field values or multiple data characteristics.
  • Reconciliation tools or complex reports required
  • Large data volume
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well.

Extensions or Enhancements

  • Simple rules
  • Standard SAP supported enhancements completely contained in SAP OSS Note instructions.
  • Field default changes
  • Copying of logic to custom records or views
  • SAP Authorizations are not affected.
  • Simple form routines that are very slight variations of existing form routines.
  • Simple user exits with 1 or no loop statements and no table joins.
  • Minimal testing effort .
  • New table
  • New table structure with no more than 2 table references.
  • Simple data modification rules or simple coded business rules which influence data values.
  • Standard SAP enhancements such as extending field catalogs, creating pricing form routines, common delivered SAP user exit or enhancements (not necessarily supported by SAP OSS Notes), and other simple user exit or enhancement point coding.
  • Single User Exit or single Enhancement Point coding to achieve result(s).
  • Create or modify SAP Search Helps.
  • New data tables based on existing SAP table structures.
  • Custom info structure definitions (without coding).
  • Display screen field adjustments.
  • Simple adjustments to existing SAP programs / transaction and assigning new transaction codes.
  • Coding that requires 2 table joins or 2 loop statements.
  • Moderate or detailed program testing with multiple options or variants.
  • Mission critical; financial impact; or regulatory impact.
  • Creating significant portions of processing functionality with custom code.
  • Coding which involves a process string or chain of 2 or more data “transactions” or complete process exchanges.
  • Multiple new tables with multiple formulas.
  • Coding which requires multiple criteria, multiple data dependencies, or multiple table evaluations.
  • User exit coding which requires significant design effort where there is no standard SAP proposed solution that does not meet at least 80-90% of the requirement.
  • Coding which involves 2 or more user exits.
  • Coding which involves functionality in 2 or more SAP modules.
  • ANY Coding which involves direct table updates is automatically high risk (and should be avoided).
  • Development of new custom transactions with significant non-standard functionality.
  • User exits, enhancements, or custom program that require custom field additions to existing SAP tables for additional processing.
  • Custom screen requirements with new fields and processing requirements.
  • Coding that requires more than 2 table joins, or coding that requires more than 2 loop statements.
  • Custom development that requires enhanced or additional security authorization objects.
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well. Generally involves testing within and across a module or function.


  • Use standard SAP pre-delivered forms without changes.
  • Accept SAP form logic and coding, accept standard SAP print programs and make only minor layout changes to existing forms.
  • Single forms without any variants for each type of output processing.
  • Use standard pre-delivered forms but make minor logic and programming changes to form processing.
  • Can make form layout modifications, even significant ones, as long as they are based on an existing SAP form (not a brand new form developed from the beginning).
  • Use standard print programs but make minor changes to print program processing.
  • Up to 2 types of layouts (with only minimal changes in layout or logic) for each document type that needs to be printed.
  • Multiple types of variants or processing of forms but with minor adjustments to layouts or logic.
  • All logic or coding changes to both forms or print programs are within the same module / processing stream (not dependent on requirements from other transaction streams or other modules).
  • Can retrieve data from a single table outside of the standard print program processing stream and apply simple logic.
  • Any print program or form program changes which fall within the criteria and examples provided under the “Average” section of the “Extensions / Enhancements” section.
  • Moderate or detailed program testing with multiple options or variants.
  • Mission critical, financial impact, or regulatory impact.
  • End customer-specific, or end vendor-specific form layout requirements.
  • Pricing requirements that must be recalculated in the form logic (not able to use standard functionality).
  • Substantial layout modifications or creating whole new forms or print programs that are not based on standard SAP forms or programs.
  • Substantial modifications or alterations to standard SAP forms or print programs.
  • More than 2 types of layouts for any document processing type. For example, more than 2 types of invoice layouts, production orders, goods movement slips, etc.
  • Form or print program logic that requires data outside of the module or processing stream that is being transacted in.
  • Form or print program that requires any custom tables or customized rules for processing.
  • Multiple output streams from the same document or transaction process.
  • Data or logic criteria accessed from multiple tables not included in the pre-delivered standard print program.
  • Any print program or form program changes which fall within the criteria and examples provided under the “High” section of the “Extensions / Enhancements” section.
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well. Generally involves testing within and across a module or function.

Related Posts:

SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1

August 30th, 2010 by

SAP UpgradeI previously noted I would follow up with a post on doing an SAP implementation for only marginally more than a technical upgrade (see Technical SAP Upgrade or SAP Reimplementation).  In the process there are a few assumptions and several considerations to keep in mind.

If an SAP reimplementation is done well the Total Cost of Ownership can be significantly reduced.  Especially when you keep in mind that getting closer to standard functionality in non-business critical areas, or what I like to refer to as “commodity” processes, makes it easier and less expensive to add additional functionality as business needs arise.

Your IT Department Skills and Qualifications

If you are at the point of an upgrade you have most likely had SAP installed long enough to have developed some level of skill and competence with the software.  Along with this your SAP staff has developed an understanding of your business and the application. 

Over the years you have been on your current SAP version complaints and requests from the business have reached your department and staff.  So you have some insight on where the implementation might need to be corrected.  The business has been using SAP for a few years now so the end users are familiar with the interface and the data entry requirements.

Based on this new insight and the business needs that were not met with the system integrator’s guidance on the original implementation you believe you might be a good candidate for a reimplementation. 

Because of your experience with the system and because the end user exposure for a few years the difference between a technical upgrade and a reimplementation is a modest delta in terms of effort and cost.

You’ve Already Worked Through the Hard Stuff in your Original SAP Implementation

Probably one of the most important considerations to remember in a reimplementation is that the hard decisions around the processes, organizational structures and data types have already been made:

  • chart of accounts,
  • account posting models
  • SD / MM / PP / FI / CO / HR / etc., organization structures,
  • SD order types,
  • PP order types,
  • PO types,
  • HR info / activity types,
  • material types,
  • vendor accounts,
  • customer accounts,
  • pricing structures,
  • reports,
  • processes of all kinds,
  • form outputs (layouts),
  • interfaces,
  • reports,
  • enhancements,
  • etc.

Since the really hard part was done in the original implementation it is more a matter of understanding how to take your SAP implementation to the next level.  These decisions and other gaps discovered after you went live represent the difficult and stressful situations your company has already worked through. 

This incomplete list of setup items from your original project were probably the biggest project stress points and key decision points.  Even after you went live you’ve probably discovered a number of gaps, improvements, or corrections you wanted to make but were tied up by the previous design or limited by your staff’s understanding of how to make those changes in the live environment.

What Would SAP Look Like Had You Known Then What You Know Now?

All of those project decisions might have led to completely different SAP solutions in hindsight.  In other words, by the time you went live and finally got your SAP implementation stabilized there were probably a lot of things you would have done differently.

Related Posts:

SAP Implementation Projects: Still Crazy After All These Years

August 16th, 2010 by

R3 Solution

The following is re-posted with the permission of my friend Michael Doane, see his site at


Through the good graces of my long-time associate Jon Reed (, I recently discovered a blog that covers the life of an SAP project: SAP: Loathe It or Ignore It, You Can’t Like It

Shortly thereafter, Dennis Howlett posted about this blog “Your Implementations are Killing Us” and the next morning I received a frantic e-mail from a friend at SAP lamenting its posting. So I guess this blogger is gaining some buzz.

I take exception with the title of the SAP blog as I have seen countless clients who actually do like SAP. All the same, I find it a curious and worthwhile contribution. The writer maintains complete anonymity throughout. No profile or mention of his name, his company’s, the implementation partner’s identity. Mum. While this is largely understandable as a matter of the blogger’s self-protection, it also degrades the effect. All the same, the twenty-seven postings since January, 2009 vividly describe the mind-numbing frustrations, side-shows, and cul-de-sacs that a poorly-run implementation can engender.

The appearance of this blog is in parallel to some serious SAP head scratching on the subject of bad implementations. At the end of the day, when an SAP implementation project goes wrong, it is the joint fault (in varying measures) of the client and the systems integrator but it is usually SAP that gets the PR black eye.

I have been involved in SAP implementation work since 1995 and the balance of my book “The New SAP Blue Book, A Concise Business Guide to the World of SAP” provides guidance for the best practices for implementation. The book first appeared in 1998 and has been revised seven times as better practices continue to emerge. During this same time-period, I have done a considerable amount of primary research with more than 1500 clients reporting upon their SAP experiences and the performance of their SAP systems integrator.

SAP does not deserve the full black-eye for failed implementations. In my esteem, however, SAP does a poor job of policing its SAP partners. The 1500 clients reported upon the field performance of all of the leading integrators (Accenture, IBM, Deloitte, et al) and the following provider failures were chronically noted in regard to deficient project process (in order of importance):

  • Poor scope/resource management
  • Lack of adherence to methodology: all the systems integrators have sophisticated methodologies and tools; they just don’t use them consistently (if at all);
  • Ineffective partner management.

In this research, clients cited who they considered responsible for various issue. They tabbed themselves the guilty party for:

  • Over-engineered and difficult to use results
  • Insufficient post-implementation planning
  • Lack of client ownership.

What SAP Can Do to Address Implementation Issues

All the systems integrators, including SAP Consulting, regularly tout their client satisfaction ratings. When you scratch the surface, these ratings tend to be childish and generalized buckets for entire projects of Very Satisfied, Satisfied, and Not Satisfied. The first reaction is to ask who is satisfied, what are they satisfied with, and when were they satisfied. Many clients I have spoken to who claimed that they were satisfied added that the whole project was a bumpy nerve-wracking mess but they were finally satisfied that it was over.

In this light, SAP needs to finally recognize that implementation services are every bit as much about consulting as about software. While tools such as Solution Manager are excellent for tracking software issues, project issues relative to consulting, governance, etc. are not tracked. SAP should be working more closely with its largest implementation partners to create client-satisfaction tracking that continually addresses these issues from an SI perspective:

  • Business/IT Alignment
  • Governance & Control
  • Human Capital Management
  • Technology, Tools & Process
  • Service Delivery & Operations

Short of this, SAP should create and cultivate a network of objective, third-party quality assurance units (not SAP, not SAP implementation partners) to accomplish this tracking. When such a QA unit exists, life is better for both the client and the systems integrator as in many cases the QA group can point out to clients where they are going wrong. Again, each of the systems integrators have their own internal quality assurance but it is seldom demonstrably objective. By the same token, such QA should not be undertaken by SAP.

Quality assurance can add 1% to 2% to an overall implementation budget while resulting in a 10% to 30% savings in over-all implementation costs (primarily by fending off budget over-runs).

Value to Clients of Third Party Implementation Project Quality Assurance:

  • Cost containment, derived from progress monitoring
  • Time adherence, resulting from continuous (phase to phase) monitoring as well as scope management
  • Vision/benefits realization: assuring that the project will deliver the intended business value
  • Reduced administrative and strategic burden; fewer client/SI meetings for the purpose of progress reporting, issues management, and the like
  • Objective advisory as to what other services or support functions might be appropriate and desirable.
  • Quality assurance reporting would be most effective if it is directed to the client, to SAP, and to the systems integration partner.

In the field, I find that systems integrators initially balk at the inclusion of third party quality assurance on the premise that it will act as an audit of only their performance. Once they understand that the quality assurance role also focuses on client performance and SAP performance, the activity yields positive results.

It should be noted that the SAP/SI partner dynamic is not the same for all partners. Clearly, IBM and Accenture are not as malleable as a small partner such as Capgemini or any number of boutiques. However, it is evident that scrolling a third-party quality assurance activity into any SAP implementation will benefit all three parties (client, SI, and SAP).

It is probably too late for our anonymous blogger. I look forward to when he fills out his satisfaction rating.


The original posting for this article can be seen at:

Popular Searches:

  • How to budget a SAP project of migration a legal identity after M&A
  • sap project na

Related Posts: