Business Solutions with SAP

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:

Technical SAP Upgrade or SAP Reimplementation

August 23rd, 2010 by

Business ApplicationsSAP’s application landscape has the depth and breadth of functionality to handle 90% (and usually more) of nearly any business requirement.  Regardless of this huge depth and breadth of functionality there is still way too much custom coding and redesign of the software (see e.g. SAP Implementation Focus, Software Engineering or Business Process Engineering?).

If you are an SAP shop considering an upgrade it may be time to take a hard look at whether you should do a technical upgrade or a reimplementation.  As you probably know, a technical upgrade means taking what you already have, the good, the bad, and the ugly, and then converting it all, as is, to a new version.  This includes the existing custom coding, processes, system settings, and all of the existing landscape.  If there were poor design decisions from the original implementation, or bad coding substitutions for standard functionality, together with security and authorization design problems then you carry all of that trash forward.

In many cases a reimplementation does not have to be much more expensive than a technical upgrade.

A reimplementation when done correctly, looks at the existing system landscape and evaluates the gaps.  You evaluate where the system could be redesigned to deliver on the original promise of SAP’s ERP application suite.

Considerations for an SAP Reimplementation

After you went live with the implementation, if you have heard lots of comments like:

  • “if only we had known X?” or,
  • “why didn’t the consultant tell us we could do Y?” or,
  • this is too slow, painful, difficult, complicated, etc.,

then you might be a good candidate for a reimplementation.

For example after being live you might discover that the original SAP Organization Structure did not provide you with key information you need for good reporting.  SAP standard LIS and SIS reporting provide you with little value because of this less than optimal organization structure.  You might find that the pricing implementation was less than optimal and has lots of restrictions.  After being live for a while you might discover that your supposed “experienced” consultants didn’t really know about SAP’s capabilities and that all of those pricing or order related processes they told you couldn’t be done are actually possible–, not easy, but can be done with fairly standard functionality.  The reasons why your original implementation was “less than optimal” may be limitless but you have learned a lot since then.

  • Maybe there wasn’t enough attention given to how the SD or MM org structures would impact reporting requirements. 
    • Maybe it has too much granularity or too little.  Maybe you needed geographical elements included in the org structure, or maybe product line dimensions, or maybe sales office / sales territory information. 
  • Maybe that “experienced” consultant had no clue about your GL Account Determination, or about complex pricing, and maybe they misled you and told you SAP didn’t support what you wanted to do with pricing or accounting because they didn’t have the level of expertise you paid for. 
    • Maybe the SAP “expert’s” design produced way too many pricing conditions, or huge amounts of master data to maintain.
    • Maybe they didn’t consider the live system master data maintenance requirements so the solutions they designed did not even consider the amount of ongoing support that would be needed
    • Maybe the consultants didn’t know how to segment and stratify customers for better sales and pricing processes, etc.
  • Is your availability checking terrible or non-existent and you have bad promise dates. 
  • Is the backorder processing difficult or non-existent?
  • Maybe the SD or MM or PP consultants were completely clueless about Sales and Operations Planning (S&OP) and left you with little or no forecasting and supply planning abilities.
  • You might find that your Materials Management (MM) consultant was clueless about MRP or about supply chain planning. 
  • Maybe the MM consultant didn’t have the critical experience for a good design around purchasing organizations, purchasing groups, PO pricing, material account determination, etc.
  • Maybe your Inter-Company supply processing is painful with full transaction processing for an entire sales and purchasing process when your “expert” never told you there is a simpler way with standard functionality.  Or, you might have to manually do eliminations for Inter-Company clearing but your “consultant” never told you there is standard SAP functionality to do this automatically.
  • Maybe your PP consultant told you that you couldn’t do in-process-subcontracting for subassemblies in the production process.  Or, maybe the MM consultant made a mess out of your subcontract process by setting up storage locations or plants to represent the subcontract vendor (rather than using standard SAP subcontract functionality).
  • Security authorizations are a mess and nearly everyone has their own “custom” authorization.  It is taking far too long to provision security and there are significant delays in provisioning user roles.

The number of dumb SAP design and implementation scenarios I’ve seen over the years are too numerous to list.  I could go on and on with different examples across the entire application. 

Your SAP Implementation Should Not Have Been So Painful

What it comes down to is your initial implementation was less than optimal.  You paid a FORTUNE for a  bunch of custom hacks rather than using standard SAP functionality, or a lot of functionality gaps for important business functions.  You may have ended up with overly complicated processes and difficult to manage data requirements.  There could be any number of issues or reasons, but let’s just say you’re not too happy with your previous implementation results.

If you’re not too happy with your results you are probably a good candidate for a reimplementation. 

Before you panic, there is a way to do a reimplementation on a reasonable budget, and without the huge pressures and stresses of your original project.  

SAP Technical Upgrade Considerations

If you are very happy with your system, and your user community has seen improvements and efficiency gains with the original implementation you are probably a good candidate for a technical upgrade.  Keep in mind that a technical upgrade is taking exactly what you have, without any significant changes, and then converting the system landscape to a new version.  Regression testing is done to ensure that previous functionality is not broken and that any custom programs still work as desired.

One other consideration for a technical upgrade verses a reimplementation is whether or not you kept the application fairly close to standard.  And by close to standard I do not mean that you didn’t do any user exits or with newer versions make use of any of the enhancement points–, in other words, your “experts” didn’t “invent” new custom-coded applications where a standard solution would work.

Even during a technical upgrade you may be able to make some adjustments and modifications, but they are more like minimal tinkering. 

Conclusions on SAP Upgrade or SAP Re-Implementation

At the end of the day, when you are considering your SAP landscape, the key issue to remember is the application is supposed to support the business and produce business value.  When you consider the huge investment and the impact to the business it is important to get real value from your SAP implementation.  As you prepare for your upgrade, that is the key time to evaluate, or re-evaluate the business drivers for your technology spend and consider what can be done to gain real return on investment.

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

Related Posts: