SAP ROI — Enterprise Architecture & Business Solutions

After a short look at the peer-reviewed academic literature, Anil Bhagwani, did a brief case-study on 10 failed SAP implementations and 10 successful SAP implementations.  From these he continued to distill SAP critical success factors.

For more vendor selection background, before or after reading this post, please refer to another study that was reviewed on the topic of vendor seleciton–, SAP Implementation Partner or Company Selection Criteria.

Common SAP Critical Success Factors (CSF’s) identified for successful ERP implementations

The study author’s perspective and summary of the key success criteria from the Executive Summary, pg. 5, is reproduced here (altered and reformatted for easy reading):

• Sustained executive management support and their ownership of the implementation.
• Project team composition.
• Good project management (especially pertaining to process design).
• System testing.
• Training of the end users.

These are the most important factors contributing to the success of SAP implementations in most organizations.  The lack of sustained management support / contribution and user involvement / training and testing seems to be the most important factors contributing to the failure of SAP implementations in most organizations. [FN1]

These conclusions are consistent with my experience and tend to be mostly in line with the academic literature.

Why do so many SAP projects come in over budget and over time?

One important feature of this paper is the notation about project management and its relationship to project failure.

“30% of projects were perceived to have failed because of a lack of effective project planning, while 10% were perceived to have failed because of technology-driven causes” [FN1]

This, in my opinion, can be laid at the feet of the implementation vendor and the project management they provide.  More often than not it is the implementation vendor who is tasked with providing the experienced consultants and project management team.  And in the SAP world nearly every SAP system integrator pitches the SAP ASAP implementation methodology but few of them bother to actually follow it after the sale.

Companies pay dearly for “experienced” resources who claim to follow a proven methodology to steer a customer correctly through their SAP business software system implementation.  But in most cases a good system integrator, with seasoned project management is critical to your implementation success.

Although the literature suggests that 10% of the ERP project failures were related to technology, with SAP in particular I would challenge that as masking the real underlying cause.  Let’s put the claim of SAP technology limitations into perspective.  As of October 6, 2010,

• SAP has over 100,000 customers in more than 120 countries [FN3],
• nearly 50,000 employees [FN2] (with approximately 15,000 of those employees being developers [FN3]),
• about 15% of total revenue dedicated to R&D. [FN2],
• and more than 24 global industry segments. [FN3]

Plainly the SAP solution has been proven in nearly every environment imaginable. In spite of some of the headlines about failed projects, the application itself is so widely used, adopted, supported, and developed it can not be the problem.  In my opinion the blame for failed implementations, blown budgets, and blown project timelines is frequently the fault of the guidance many companies receive from their hired help.  That does not mean that customers do not contribute to this in many cases, only that the system integrators are the ones that should “know better.”  When an ERP implementation project is headed toward the rocks the system integrator should have enough experience and integrity to raise the risk issues and help to avoid disaster.  After all, during all of the sales pitches they are the ones that tout how much experience they have and you hire them based on that supposed experience to help ensure you do not crash on the rocks.

This does not mean that SAP does not have its technology limitations.  After participating in SAP projects since 1994 I have rarely encountered SAP software limitations where the standard application was not able to deliver 90 – 95% of the business requirement without any custom coding.  Where that 5 – 10% of custom coding was required SAP has provided both user exits (prior to version 5.0) and enhancement points (versions ≥ 5.0) to modify the data processing within the transaction stream.  And unlike other consultants, my experience has taught me that there is a standard solution there somewhere so I will look for the standard functionality before trying to undertake custom “software engineering” efforts.

As a result I would attribute that 10% “technology-driven” failure rate to other ERP applications, or more likely improper requirements, poor project management, or bad consulting.  Although I have not had the direct application exposure to SAP’s competitive products, I would guess they are fairly well developed in their focus areas as well.  And over the years I have had a LOT of SAP client counterparts wanting what I call mutually exclusive requirements.  Or, as an analogy, they wanted to have their cake undisturbed while still eating it too. 

Defining SAP Success Criteria (Lacking these can cause ERP Project Failure)

The academic study’s author offers an ERP success definition which notes projects are “done within budget and time with meeting all the preset implementation goals as measured by ROI, etc.” [FN1, pg. 8].  The author then notes a 2007 Gartner study showed only 60% of the projects achieve this success definition. 

In my next post I have reproduced the list of critical success factors (CSFs) and added a responsibility matrix.  Those critical success factors come from a combination of this study, done in 2009, combined with a prior peer-reviewed study I wrote on previously ( The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors ) and my own personal experience.

The responsibility matrix I developed defines major project success criteria and who is (or at least should be) responsible for ensuring the successful delivery of those key components. 

More of this is explained in my next post which looks at some of the key areas for project success, who should manage those success factors, and how so many consulting firms avoid responsibility.  After that we will review details on steps and strategies to ensure ERP system integrator accountability for managing those success factors to ensure you don’t get robbed in your SAP business software system project.

Tune in over the next few weeks for more details and insight on this topic.  I’ll be exploring why so many SAP system integrators and ERP vendors are able to avoid accountability for these SAP critical success factors and how you can work to ensure your ERP system vendor covers these factors.

~~~~~~~~~~~~~~~~~~~~~~~~~~~

[FN1]  Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School. http://www.r3now.com/literature/2009-Bhagwani-SAP-Project-Success.pdf

[FN2]  SAP Inventor Relations, Business in Brief, http://www.sap.com/about/investor/inbrief/index.epx (retrieved 5/10/2010)

[FN3] Deutsche Bank European TMT Conference 2010, London, September 10, 2010 (retrieved 10/04/2010 http://www.sap.com/about/investor/presentations/pdf/WB_DB_London_8Sep2010.pdf

Related Posts:

• SAP System Vendor Project Success Criteria & Factors 3
• Series on SAP ERP Project Success Factors
• Toward an SAP Center of Excellence or SAP Competency Center – PART 1
• A New SAP Implementation Methodology and Implementation Steps
• SAP Implementation Partner or Company Selection Criteria

With Michael Doane’s permission I’m re-posting part 2 of his critique on SAP implementation projects.  For the first part you can see it here, SAP Implementation Projects: Still Crazy After All These Years.

In a previous post, I pointed out my discovery of an anonymous blogger who is providing a blow-by-blow of his firm’s painful SAP implementation. (SAP: Loathe It or Ignore It, You Can’t Like It http://sapmesideways.blogspot.com/. )

Since that post, I have had some e-mail contact with the writer, who has agreed to my re-use of our correspondence.

The most striking comment of his was this:

“I don’t know if the SAP project methodology is being used as I have nothing to gauge our experiences against; however, over the past 2 years, I have read a number of items by experienced SAP consultants, and I suspect that they are not applying it correctly, if at all.”

My reply:

“…if they were using a methodology, you would definitely know it. Outside of IBM and Accenture, all certified partners MUST adhere to SAP’s ASAP methodology, sometimes referred to (recently) as Focus ASAP. Most of these partners add some of their secret sauce to the core SAP methodology. I am willing to bet that if you look at this firm’s proposal of services to you that they make a big deal about their methodology.”

The blog was started in January of 2009, so over an eight month period our correspondent is not sure whether or not a methodology is being followed. While this may seem “crazy”, it is unfortunately a more widespread (mal)practice than the systems integrators will admit.

When clients search for SAP consulting help, they are looking for:

a) specific expertise (business process design, configuration, and technical) and

b) a proven project method or methodology by which all necessary project activities are navigated.

My research since 2001, both in the field and through extensive survey work, reveals that the leading SAP systems integration firms routinely fail to adhere to their own methodologies.

They claim to have best practices repositories that are referenced in the course of business blueprint but clients report a high incidence of white-boarding.  They claim to that their proven methodologies result in on-time, on-budget implementations and yet SAP implementations are still routinely late and over-budget. (I actually blame this aspect on clients who just as routinely establish wildly optimistic budgets and time-frames).

Failures to actually leverage promised assets are not limited to the usual suspects. Our anonymous correspondent had this to say about his firm’s SI partner:

“My main beef is with the consultants (what you would call the system integrators I think) – they are a mid sized company and it appears they have not previously implemented in the specific sector which my company operates in. They are an SAP gold partner, but I’m not sure what value that has – in my opinion they do nothing to enhance the reputation of SAP, the company or the product.

Although we had one person for a few months that was very experienced in SAP implementation (some 15+ years), most of the people seem to be very new to the role, less than 2 years. We have had so many different consultants, that I have actually lost track of the number (almost 60, I now believe, where they originally proposed just 4). They have failed to meet a single target on the deadline, or on the budget and in many areas have not met all of the requirements of the business. “

Individually, clients should do a better job of holding their systems integrators’ feet to the fire. Collectively, only SAP itself can directly address these failures and they can do so through the leverage of third-party project quality assurance as well as by leveraging more pressure on all systems integration partners, be they gold, silver, or bronze.

~~~~~~~~~~~~~~~~~~~~~

The original article can be seen at: http://sapsearchlight.blogspot.com/2009/08/sap-implementation-projects-still-crazy.html

Visit Author Michael Doane’s web site for more insightful articles on SAP projects at http://sapsearchlight.blogspot.com

Related Posts:

• SAP System Vendor Project Success Criteria 1
• Removing SAP Project Barriers to Realize ROI and Business Benefit
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• 7 Tips for Effective Client Management of SAP Consultants
• SAP System Vendor Project Success Criteria & Factors 4

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:

• SAP Implementation Focus, Software Engineering or Business Process Engineering?
• Technical SAP Upgrade or SAP Reimplementation
• SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1

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.

Related Posts:

• 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
• Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
• Planning For a Smooth Go-Live: Part 3