SAP & ERP Consulting from the Customer Point of View

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:

• Industry Specific SAP Consulting vs Deep SAP Application Experience
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• More on Stupid SAP Vendor – Partner Selection RFI-RFP Processes
• Using SAP to Improve Revenue and Profitability
• SAP Offshore Development Project Experience

Project Success Insight

 This is a followup to a previous post that introduced a fascinating study on expert performance (see  Successful SAP Project Team Composition – Technicians or Experts?).  One of the key insights of the authors was that it was not experience alone, but a very special kind of experience that produced “expert performance.”  A very focused type of continuous achievement that goes beyond mere time of experience or practice. 

The study’s authors noted the difference between the amateur and the professional (or expert) was more about the amateur being satisfied that they had achieved a certain level of proficiency and the expert continuously pushed it to the next level.  And by next level it was within the specific domain of expertise that they focused on for at least 10 years.  The authors noted:

While stable individual differences in rates of learning (improvement of performance) in certain domains unquestionably exist, they are associated with differences in the type of practice activities and the nature of the students’ concentration and engagement. From retrospective interviews of international-level performers in several domains, such as sports, arts, mathematics and neurology, Bloom and his colleagues (citation omitted) showed that future elite performers engage in activities that differ systematically from those of recreational amateurs.  Amateurs in sports, such as tennis, golf and jogging, acquire an acceptable level of performance and then merely maintain that level for decades as is illustrated in the lowest performance trajectory [illustrated].

The single most important differences between these amateurs and the three groups of elite performers is that the future elite performers seek out teachers and coaches and engage in supervised training, whereas the amateurs rarely engage in similar types of practice.  (Ericsson, K., et. al. 2007, pg. 34).

The current SAP consulting world rarely, if ever, supports this type of talent development.  SAP certification and training programs only impart a superficial type of proficiency.  Even the “professional” certification offers little more than a demonstration that someone may have reached an “amateur” status.  There is little if anything in the consulting world that presses for this level of exceptional proficiency.  There is nothing in the consulting world approaching the level of practice and competition that Olympic hopefuls or professional sports figures engage in.

Expert Performance Approach for SAP Integrators

The difference between amateurs and professionals (or experts) has wide implications for consulting firms and for SAP’s certification program.  At a consulting firm if you have not achieved a senior manager level or higher within 10 years your future prospects are not very good. According to the research however this 10 year mark is where a dedication to excellence within a specific domain for a committed SAP consultant is the point at which they begin to emerge as a true “expert” or “professional” according to the academic literature.

The consulting field does not properly pursue long term domain expertise at the delivery level because most consulting firms create a “climber culture” that provides incentives for aggressive “career growth.”  There is little or no incentive for a long term focus on “domain expertise.” 

Until consulting firms move beyond the one or two weeks of “continuing education” in the form of training courses they offer to their consultants each year  nothing is going to change.  Combined with that, real, meaningful, and substantial knowledge transfer is just as important, and maybe even more important, than it is for the consultants to the client (cf. Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2).  [T]raining and deliberate practice are the principal causes of exceptional performance.  (Ericsson, K., et. al. 2007, pg. 33).

Major ERP vendors like SAP do not produce any type of transcript program or other verification mechanism for training or certification.  With only a few recent exceptions there are few lawsuits against fraudulent vendors and consultants. 

The mark of experience and knowledge is the ability to make the complex or technical seem simple or at least understandable

We’ve all seen this before.  It is the athlete that performs some amazing feat in such a way that it looks effortless.  These athletes or other skilled professionals take exhaustive hours and years of practice to sharpen their skills until they look so polished we almost believe we could do it ourselves.  This may come out in the business or technology sector where some sage wisdom or suggestion on a very complicated or difficult topic is boiled down to an almost overly simplistic phrase or term.  It seems and sounds simple but that ability to take the complex and make it simple, or at least appear simple takes many hours and years of practice and experience.  There are no shortcuts. 

For a number of reasons it may be difficult at best for any well-established consulting firm to ever deliver the real results you want for your project and business.

Reducing SAP TCO and Improving SAP ROI

Consulting “experts”, those with at least 10 years of experience, generally have enough experience to:

• ensure scope is correct (reduce rework and reduce process gaps)
• help ensure that data conversions are more properly mapped and handled
• ensure testing is more thorough and comprehensive
• facilitate knowledge transfer

The key consulting skills for a successful SAP implementation include several requirements gained over more than just a few years and a couple of SAP implementations:

• clear oral and written communications,
• requirements gathering sessions,
• design sessions,
• blueprint writing,
• solution assessments,
• problem resolutions,
• fit / gap analysis,
• business process design,
• translation of SAP / ERP speak to business language,
• knowledge transfer,
• training,
• and organizational change.

That clear communication, from an experienced background, provides the ability to translate SAP specific processes and requirements into easily understood business language.  Without that ability then all of the other critical skills listed above mean little or nothing.  If the individual does not have enough experience to translate techno-speak into plain, understandable business language then how much meaningful experience do they really have?  For more details on this list of topics for your SAP consultants please see the post entitled “Screening and Interview Methods to Find the Right Consultant – Part 2“.

As a result of this experience these consultants usually go-live with relatively few hiccups or issues.  Consultants with deep experience may cost somewhat more from an hourly rate but they generally need fewer hours to accomplish the same effort.  Because of the amount of experience and skill they also have less rework of any kind and their system settings are generally resolved more quickly.  Deeply skilled functional consultants can write better functional / technical specs to ensure that less development time and effort is needed as well.  Consultants with more and longer project exposure have had to work through and resolve more issues, and have likely been exposed to more of the functionality.  As a result you are more likely to have more standard functionality rather than custom coded long-term support headaches.

These and many more reasons are some of the possible results of getting a good consulting team with very deep SAP experience. 

I’d also like to see some of the mid to larger sized consulting firms begin to develop and engage in some type of national or international competitions around business and application integration.  SAP offers a small measure of this during some of their annual conference events, but there is nothing approaching a formalized competition that is needed to begin a real change in the SAP consulting world.

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

Ericsson, K., Roring, R., and Nandagopal, K. (2007);  Giftedness and evidence for reproducibly superior performance: an account based on the expert performance framework.  High Ability Studies Vol. 18, No. 1, June 2007, pp. 3–56.

Related Posts:

• Industry Specific SAP Consulting vs Deep SAP Application Experience
• Global SAP Instance Consolidations
• SAP System Vendor Project Success Criteria & Factors 4
• SAP System Vendor Project Success Criteria 1
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP

In this final installment on these lessons learned and mini case studies we will look at a few older SAP project failures.  Even in these older SAP project failures it is still surprising that so many of the same problems continue to repeat themselves after all these years.

I’d like to point out once again that in the major SAP project failures the software application itself was not at the root of the failure.  The project failures I focused on are the ones where there is plenty of published literature to evaluate.  Obviously that does not mean that there aren’t projects with failures where the software itself was responsible, only that the available literature where you can do a fair analysis of the projects do not point to the software itself as the cause.

One of the interesting trends for several of the project failures was the SAP project was blamed for poor business results.  For example,

• Here you can see the Hewlett-Packard example listed below (2004).
• In the first post of the series it was the Shane Company (2008) (SAP ERP Project Failure Lessons Learned and Mini Case Studies 1).
• And then finally in the second post it was Levi Strauss & Company (2008) (SAP ERP Project Failure Lessons Learned and Mini Case Studies 2)

SAP ERP Implementation Failure Overviews – part 3

Some of the reasons for these older SAP ERP project failures (and many of the modern ones) include:

• insufficient or improper training,
• lack of change management,
• insufficient testing,
• poor scoping,
• bad go-live timing,
• unreasonable timelines,
• bad project management,
• lack of senior management participation,
• multiple simultaneous enterprise application projects,
• too much or too complex custom development efforts (interfaces),
• and inexperienced or incompetent consultants.

Hewlett-Packard Company – SAP ERP Project Failure? (2004)

• Even though this was attributed to the SAP implementation there are other things to consider.  At the time of this implementation HP was a fairly mature SAP shop.  They had already done 4 prior rollouts of the application and this was number 5.  The “hiccup” only prevented one week’s shipments and as an SAP consultant since 1994 I can all but guarantee you that this “hiccup” was at the beginning of a month, and probably the beginning of a quarter, and not at the end.  As a result it could not have affected the financials to that extent.
• CIO and Executive Vice President of Global Operations Gilles Bouchard didn’t think that… data modeling problems between the legacy and SAP systems was the source of the $160 million impact. He blamed HP’s inability to keep pace with orders in the supply chain once the problems were discovered. [FN1, pg. 26]
• Although HP’s Industry Standard Servers (ISS) business woes were blamed on SAP because of a one week supply chain hiccup, the actions by HP hint at a different reason.  If the SAP software were to blame then the division’s sales executives would not have been fired:

HP “announced that three major sales executives, including former server group head Peter Blackmore, had been fired in a management shake-up following the disappointing quarter in the company’s server division.” [FN2]

• I do not believe this was an SAP software failure regardless of how it was reported.

Lessons Learned: This “hiccup” was most likely a result of insufficient testing.  Otherwise this appears to be a case of blaming the enterprise software implementation for company or marketplace related issues.

Hershey Food Corporation – SAP ERP project failure overview (1999)

Hershey foods went live with their SAP implementation just before Halloween in 1999.  For the candy company this was the beginning of their peak season and the go-live created a major business disruption at the worst time from a revenue and operations standpoint.

• Insufficient training and user preparation
  • Users were not prepared to do their jobs, to manage day to day operations, or to clean up and correct data.  Training and change management needed more emphasis.
• Unrealistic implementation timeline
  • Original timeline for the entire project was 4 years, that timeline was cut down to 2.5 years.  Scope management, project planning, project scheduling (including task and resource leveling) are critical for success.
• Improper go-live schedule
  • Went “live” at peak sales season and did not allow enough time to “shake out” data and process issues.  Formal project plan and schedule; the integrator bears this responsibility unless they notified the company of the risks and the company insisted on going live.
• Additional large enterprise applications such as Siebel CRM and Manugistics went live at the same time.
• Has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned:  Careful timing and planning of the project are important considerations, as well as sufficient time and resources for training, change management and user involvement.  Major enterprise applications (ERP, CRM, Logistics, etc.) should be implemented one at a time and then at least modestly stabilized before undertaking additional enterprise applications. Attempt to schedule go-lives so that they coincide with the end of a busy season and a potential “lull” in business.  This way there is some time to work through stabilization issues before busy seasons start.

Whirlpool Corporation – SAP ERP project failure overview (1999)

Just before a Labor Day go live in 1999 several warning signs of serious problems appeared.  Interfaces and batch jobs that fed external systems indicated serious performance problems but Whirlpool management and their SAP implementation vendor Deloitte decided to go live anyway.  A decision was made to go with the known problems and the problems would be resolved within roughly a week after going live.  However the interface problems created far more disruption to the external shipping and distribution systems than was anticipated.  Shipments were delayed 6 – 8 weeks causing significant lost business because many customers cancelled orders and went elsewhere.

Lessons Learned: Red flags with enterprise applications should be carefully evaluated for a “go” or “no go” decision as you approach going live.  Testing of interfaces cannot be ignored and serious performance problems or known interface problems should not be ignored. 

Fox Meyer Drugs – SAP ERP project failure overview (1995)

• Management failure
  • SAP was being used to automate and consolidate warehouse operations and layoffs were known to be coming.  Labor sabotaged the efforts.
  • Warehouse consolidation was occurring just as the company captured a major new contract increasing the transaction and processing volume.
• An additional large enterprise warehouse management system was implemented during the SAP implementation.
  • This is scope management and project planning and scheduling.
  • Multiple enterprise systems create significant project risks.
• Insufficient training and user preparation
  • Users were not prepared to do their jobs, to manage day to day operations, or to clean up and correct data.  More emphasis on training and change management was required.
• The consulting company provided “trainees” to do the SAP implementation which turned out to be a disaster.
  • Project scope and cost were mismanaged because the consulting company drove the entire project.
  • Poor project planning and coordination.

Lessons Learned:  Change management, training, and employee acceptance are critical. Avoid multiple enterprise wide software projects at the same time.  Ensure that the SAP vendor partner doing the implementation does not staff the project with inexperienced, ineffective, or less than optimal consultants.

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

[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 implementation contributed to HP shortfall.  Computerworld, August 12, 2004.  http://www.computerworld.com/s/article/95223/SAP_implementation_contributed_to_HP_shortfall

Related Posts:

• SAP ERP Project Failures Lessons Learned and Mini Case Studies 2
• SAP System Vendor Project Success Criteria & Factors 2
• SAP System Vendor Project Success Criteria 1
• Planning For a Smooth Go-Live: Part 3
• SAP ERP Project Failure Lessons Learned and Mini Case Studies 1