SAP ROI — Enterprise Architecture & Business Solutions

It’s been a year since the recently-departed Leo Apotheker had an infamous outburst of criticism of, specifically, Accenture and IBM in the realm of SAP consulting. This highly-publicized moment led to an avalanche of largely uninformed blog posts (one gentleman cited SAP translation problems from the 1990’s that have long since been resolved). One over-arching theme that emerged was the need to certify SAP consultants even though various forms of such certification have been in existence since 1993. My own, belated, contribution to this particular point was a post about certifying SAP implementation partners, not just the individual consultants. (point to post).

http://www.businessinsider.com/2009/2/sap-clueless-consultants-from-accenture-and-ibm-giving-us-a-bad-name-sap#comment-49936f8e796c7ade006385cc

Skip the article, read the comments…

I pledge to write more about this in a later post. For the moment, I wish to concentrate on what I believe is at the heart of chronic questions about the efficacy of SAP systems integrators: the need to move to a more evolved delivery model.

When I began working in the world of SAP in 1995, there was no SAP (or ERP) specific delivery methodology extant. Most of the larger players were using modified versions of the 1980’s style Design Build Run methodologies which unfortunately did not at all address configurable software across entire business processes. Further, these methodologies placed a very high emphasis upon the As-Is phase (which I coined the consulting partner’s Retirement Fund phase).

In the spring of 1997, SAP itself unveiled Accelerated SAP (ASAP). Despite the fact that the earlier versions of the methodology were shallow at best, there was an immediate benefit: all systems integrators began working to mutually understandable “sheet music” (which happily included a brief and intelligent verse of As-Is analysis). By 2001, through a combination of more years of field experience and SAP’s iterative improvements to the methodology, we began to see better field results, more on-time implementations, and greater client satisfaction.

In addition to the improvements to ASAP Focus brought by SAP, the various partners have all added tools and layers built around the core of ASAP in order to differentiate and to address field aspects that may not be addressed in ASAP.

In order to cut through the fog regarding “good” or “bad” implementations, I led surveys in 2005 and 2007 regarding the relative field performance of the leading SAP systems integrators. Input from 1,502 clients of the six leading SAP systems integrators for projects completed from 2003-2007, yielded over-all positive results with an average over-all client rating of 6.8 on a scale of 1 to 10 in which 6 equals “good”. Given the high number of participants in these surveys, I conclude that the SAP consulting fields are not the mess that many make of them.

The field performance of the systems integrators varied according to type of project (new implementation, upgrade, optimization, roll-outs), client size, and project size. Accenture had world-class scores for its very large clients and, um, nothing to write home about for the others. Deloitte had persistently low scores for new implementations but enviable scores for the other types of projects. CSC was consistently mediocre, BearingPoint was all over the map. Only IBM had consistently decent levels of performance.

Having said that, I do believe that the final results of too many SAP engagements are disappointing. While over-all scores were good, many of the sub-results were less sunny-side. One key provided by the 1,502 clients: the systems integrators quite frequency go off the reservation and do not adhere to their own methodologies.

Another is that the focus of most projects is adhering to time and budget. This is mostly the fault of clients and the flawed nature of Total Cost of Ownership (given that it provided only one side of the necessary measure of ROI).

The research also shows that, without a clear notion of how an SAP project is going to bring measurable value, clients behave in ways that hinder ultimate success. The syndrome is: I Said I Wanted Chicken But Now I Want Steak and Later I Will Be Happy to Have a Hot Dog.

I said I wanted chicken: while choosing a systems integration partner, clients look for a balance between potential performance and cost.

Now I want steak: once the project starts, clients add scope and extend the aims of a project

I will be happy to have a hot dog: fatigued and running out of budget, clients stumble to go-live.
Over the past eight years, the most welcome of the new tools and methodology layers have been value drivers. Which brings me to the core evolution I believe needs to be brought to the way these systems integrators engage with clients and fulfill their duties in the field: value-driven methodologies and value-driven contracting. In my next post: Once Upon a Time at J.D. Edwards.

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

Published with permission from the Author, Michael Doane who runs an EXCELLENT site devoted to how SAP customers can get the most from their implementations.  The original post can be found here:

http://sapsearchlight.blogspot.com/2010/02/its-time-to-evolve-sap-si-delivery.html

And his site is here:

http://sapsearchlight.blogspot.com/

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

Related Posts:

• SAP Service Delivery versus Value Delivery
• Phase 6 RUN SAP ASAP Methodology
• Why Use the SAP ASAP Methodology?
• SAP System Vendor Project Success Criteria & Factors 4
• SAP System Vendor Project Success Criteria 1

Project success depends on an implementation partner’s ability to ensure business transformation occurs.

Can the SAP implementation partner or company deliver business process engineering together WITH the new system? Or, as with so many of them, do they just install systems and call that an implementation?

Lately I’ve been focused on developing a solid and repeatable ERP software and vendor selection process. 

While reviewing the academic literature and reflecting on my time working with SAP (since 1994) I found an interesting study from Romania.  The study addressed software vendor selection criteria and methods related to the limited information they had within the country.  The opening abstract certainly lines up with my personal experience about whether or not you will ever see ROI from your software investment:

Successful implementation of an ERP system is the result of knowledgeable and dedicated people working together. It entails 1) company-wide commitment, 2) openness to change, 3) good planning and 4) experienced guidance.

These key ERP implementation success criteria help you realize significant return on investment (ROI) from an ERP system. Using these criteria as guidelines during the system selection process and subsequent implementation can ensure that the chosen system will support and enable the business improvements many SAP implementation partners claim during the sales process (Hurbean 2009, pg. 1).

SAP or ERP Software Installation or Implementation?

There is a lot of substance to this study, for example it notes that the software implementation strategy and methodology are critical success factors for both the project and the software vendor selection.  One of the important differences they identified for ERP or SAP implementation companies is the idea of companies that merely install the application (more of a technical exercise) and companies that implement the software (focus on business drivers and business change in addition to the technical exercise).

The point of failure for many software vendor selection processes is a focus on the “product features” and “less or not at all the implementation.”

This study reaches the conclusion I have been pointing out for a long time on this site; there is a significant difference between software installation (with “technicians”) and software implementation (with “experts”) (see CRM, ERP, BI, and IT Investment — Where Do You Find the Business Benefit?). 

The Romanian study provides a meaningful definition between the two “goal posts” of software implementation methods and processes (see Software Engineering or Business Process Engineering?).  The goal of a software installation is to move from one software system to another with a minimum of disruption. An implementation focuses on the business drivers and business goals through a transformation of processes with the right software (paraphrased from Hurbean 2009, pg. 2) and the right implementation partner.

Key Implementation Success Factors that Apply to the Type of ERP or SAP Implementation Company or Partner

The key vendor factors identifying the differences between an implementation and an installation were:

1. Lack of training and education to the company (typically a part of the change management process)
2. Lack of in house expertise (related to a knowledge transfer strategy)
3. Lack of clear goals or business objectives (poor business to IT alignment)
4. Lack of companywide support and involvement (change resistance – insufficient change management)
5. Lack of top management commitment and support (critical success factors and the senior leadership imprint)
6. Lack of data accuracy.

Only items 3 (goals and business objectives) and 5 (top management involvement) are directly dependent on the company who selects the ERP implementation partner.  And even those two items can be strongly influenced by an ethical SAP implementation company.  For item #5 I have been on a few projects where the vendor project manager refused to engage company leadership even though the leadership was more than willing to step up but just needed some guidance.  And for item #3 I have seen many implementation vendors who bring unqualified “con”sultants to a project who were incapable of helping a company align an SAP implementation to business goals and drivers.  And then I have seen companies where the internal political culture or the company project team prevented these two success criteria.  The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors is about another study I reviewed and wrote about which lines up with several of these key SAP implementation success criteria.

SAP or ERP Implementation Success Criteria

The study continues to provide some great insight into corrective actions that can be taken to ensure you more properly align your IT / ERP / SAP investment to your business goals and objectives.  They provided an overview of ERP implementation partner or implementation company selection criteria that helps to ensure SAP project success.  This site has addressed these key shortcomings in much detail.  Below you will see the numbered problem area from the list above, a summary explanation of how to address it, and then an in depth article on the topic or subject. 

1. Lack of training and education – ensure you have carefully considered both knowledge transfer and training requirements (see e.g. Change Management and Knowledge Transfer for a Successful SAP Project)
2. Lack of in house expertise – knowledge transfer and the best business employees to support your implementation efforts (see ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?)
3. Lack of clear goals or objectives – if the project requirements are not carefully aligned to business needs even before you begin you will have trouble finding value and finding the right vendor (see e.g. Aligning SAP Scope to Meaningful Business Requirements and Business and IT Alignment – Integrating Technology and IT Spend with Business).
4. Lack of companywide support and involvement – a solid change management focus and communication are critical which requires software implementation vendors who can help lead the change activities (see Leading Change (and Change Management)).
5. Lack of top management commitment and support – senior leadership must be educated as to the business benefit and the business direction of the project, and the importance of their strategic imprint for success (see The Real Reason Executive Participation Creates IT Project Success).
6. Lack of data accuracy – ensure that your vendors focuses on the right data migration strategy and using the right data transformation tools (see Planning For a Smooth SAP Go-Live: Part 2).

Doing the up front work to carefully understand your business requirements, and then to demand that an SAP implementation company or partner has the skilled and experienced consultants is critical to project success.

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

Hurbean, L. (2009). Factors influencing ERP projects success in the vendor selection process.  West University from Timisoara (Romania), MPRA Paper No. 14430, Faculty of Economics and Business Administration.

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

Note:  This post has been split into two key parts, this first part focuses on a review of the study and the second part More on Vendor Selection Criteria and Methods for ERP Project Success focuses on some specific methods or approaches for vendor selection.

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• The Real Reason Executive Participation Creates IT Project Success
• Change How You Look at SAP to Create ROI

People, organizational, and change management strategies on an ERP implementation are usually more difficult than the technology implementation. 

ERP implementation changes to the business cause employees from different departments to become more knowledgeable about business in general (Hall, 2002) (see also  The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors about interdepartmental cooperation and communication).  While this is good, it also presents a set of knowledge transfer process challenges that consultants without the depth of project and business skill may not be able to navigate.  They may not even be aware of knowledge transfer techniques (see Screening Methods to Find the Right SAP Consultant Part 2 about the required skills and communication requirements of a good consultant). 

The Critical Nature of Training and a Knowledge Transfer Strategy and Techniques in Any SAP or ERP Project

ERP applications like SAP have a “single source” of information creating a need to develop understanding of business processes.  Duplicate entry tasks are eliminated and the degree of data accuracy is increased. Organizational processing speeds increase over time (after the initial learning stage downturn) and the dependencies between departments increases requiring a level of cooperation that makes some tasks and jobs obsolete.  Employee skill level and performance increases (Scott and Sugar 2004) making knowledge transfer techniques, like training, a critical component for long term success.

Different Types of Training are Needed for SAP and ERP Project Success

One of the biggest problems in workforce preparation for ERP applications like SAP is the type of training they receive.  The types of training you decide to use are all part of the knowledge transfer strategies, techniques, or methods to support business transformation.

Most companies only perform the traditional scripted keyboard training which consists of carefully controlled individual transaction exercises.  The training contains only a very limited focus on performing a small sequence of keyboard tasks to impart the understanding of a single transaction.  They generally do not transfer process related knowledge.  Often there is little or no knowledge transferred of:

• The significance of the data that is entered.
• Where that data is integrated into other parts of the system.
• What the underlying data dependencies are.
• What types of troubleshooting steps to take.
• What interdepartmental impacts exist.
• What part of the overall process is affected.
• Etc.

Together with these common gaps in knowledge transfer techniques and methods there is little ongoing followup after the system is live such as:

• Communications about maintenance or performance tips and tricks after the system is live.
• Additional troubleshooting training or techniques as they arise.
• Where to find key data and information for decision making.
• Etc.

Current knowledge transfer processes, plans, strategies, techniques, or methods do not include these key activities even though they are important for long-term business success. Essentially users are trained on what tasks to perform but little or no training is done to help them understand why the transactions are being performed.  They have little or no understanding of the upstream and downstream dependencies within their own departments and across the enterprise (Wheatley, 2000).  The type of insight that would produce these kinds of knowledge transfer plans and techniques only comes from significant experience.

The typical system implementation focuses on training individual transactions without the explanation of dependencies or processes.  This works for initial exposure to the system–, for learning the user interface and the new data entry requirements.  This method is not good for long term business transformation or for high productivity.

Successful Change Management Planning Requires Multiple Strategies and Types of Training — A New Training and Change Management Model is Needed

A more complete change management process and plan, which some companies installing SAP or other ERP systems conduct, is an explanation or overview of processes and how the transaction fits into an overall process stream.  This is still not a sufficient change management strategy  or process to ensure you are doing the right knowledge transfer methods and techniques. 

A more complete list of knowledge transfer methods includes several components:

1. Transactional processing (typical keyboard training).
2. Business process understanding (some projects use this method with transaction flowcharts for showing dependencies).
3. Master data dependencies (few projects do this level of end user training because it is generally the implementation consultants who have this level of understanding).
4. Operational processing (fewer projects still do this type of training because this is the production support “troubleshooting” type of training that requires seasoned consultants to be on site long enough to help users work through the issues).
5. Ongoing knowledge transfer activities such as ad hoc troubleshooting meetings with all affected users (work through problems as a group in a conference room).
6. Continuing communication about tips and tricks after the system is live.

The first 3 items on the list above can be carried out by competent and skilled training professionals.  Or, as many companies do, they can also be done well by training team members.  Most consulting companies use a method called the “Train the Trainer” approach. This approach relies on teaching internal company employees how to teach, or train, the transactional (keyboard related) courses.  It relies on them to be able to walk-through carefully scripted and controlled user exercises of limited and discrete transactions.

The “Train the Trainer” approach is a good knowledge transfer technique or method for many companies if the staff they have provided is not stretched so thin that they have an opportunity to learn what they need to know.  For this to be effective it also requires the consultant to be skilled enough to transfer the critical understanding needed to be successful. If a consultant has deep experience they can transfer the transaction knowledge together with the data dependencies, key process understanding, and even troubleshooting tips.  If the consultants on the project are unable to do this then it is highly likely that they do not have the experience you may have been presented.  Your engagement agreement may be beneficial to include some type of language to support the knowledge transfer requirements, not just that it should be done, but expected results of that knowledge transfer.

If the consultants on the project do not have a good overall process understanding your trainers will struggle and the fourth item, the exception processing, will be nearly impossible.  For example a good consultant’s knowledge transfer plan should include the ability to transfer understanding of the entire process cycle of their area such as:

• Order to Cash
• Requisition to Payment
• Plan to Produce
• Etc.

My experience is that the “Train the Trainer” approach is the most effective method for knowledge transfer to internal employees.  And in turn, good knowledge transfer for internal employees helps to ensure longer term change management.  As a result of the need to understand the overall process cycle area the consultants must have deep experience in their respective area of expertise.

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

Hall, R.(2002), “Enterprise Resource Planning Systems and Organizational Change: Transforming Work Organizations?” Strategic Change, Vol. 11, pp. 263-270.

Scott, J. and Sugar, D. (2004), “Perceived Effectiveness of ERP Training Manuals.” Proceedings of the Tenth Americas Conference on Information Systems, New York, pp. 3211-3215.

Sia, S. and Soh, C. (2002), “Severity Assessment of ERP-Organization Misalignment.” Proceedings of the Twenty-Second International Conference on Information Systems, New Orleans, pp. 723-729.

Wheatley, Malcolm (2000), “ERP Training Stinks,” CIO Magazine, June.

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• SAP Implementation Partner or Company Selection Criteria
• The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
• ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?