an experts guide to erp success chapter eight

8/14/2019 An Experts Guide to ERP Success Chapter Eight

1/17

An Experts Guideto ERP Success

By Eric Kimberling, Managing PartnerPanorama Consulting Solutions


2/17

Page 1 of 16

3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209

720-515-1377 Panorama-Consulting.com

Copyright 2012 Eric Kimberling. All Rights Reserved.

Chapter 8. ERP Implementation Challenges . . . and Failures

I'm a big fan of '80s rock. So when I heard Canary in a Coal Mine by The Police on the radio the other day, Iinstantly thought about ERP projects. The song title refers to the coal mining practice of using canaries to warnworkers of dangerous gas leaks that they may not otherwise have detected. The canary sang when all waswell. When it stopped singing, it was usually because it had died, which warned miners to stop their work and

get to a safer place.

ERP projects have a similar though probably not fatal dynamic. We've all heard about massive ERPfailures over the years, but those failures didn't just happen overnight. Instead, a number of toxic leaks builtup over time until the projects were doomed.

So what are the warnings that you might have a dead canary or two on your hands? Here are a few signs thatyour ERP project may be in trouble:

You're not reviewing the project with your executive team on at least a bi-monthly basis.Youneed leadership involvement to ensure the project is aligned with expectations, key decisions are beingmade in a timely fashion, and resources are being directed appropriately. This problem area is also

likely to become the root cause for many of the other warning signs listed below.

There is no dedicated project team.It is very difficult for your employees to do their day-to-day jobsand also participate effectively in a project as important as an ERP implementation. Many of our clientshire Panorama to ease employee workloads but regardless of how many consultants an organizationbrings in, there still needs to be a small internal group that is dedicated to the project.

There is no training scheduled until less than 90 days before go-live.Training is an iterativeprocess and should begin well before go-live. The core team needs to be trained early in the project;super-users should be trained prior to and during conference room pilots and end-users should betrained in multiple ways and at multiple stages prior to go-live.

Your organizational change management plan (OCM) only consists of end-user training. Trainingis important, but it is only one small portion of OCM. Organizational design, employee communications,process and organizational gap analyses and organizational readiness assessments are just some ofthe key activities too often overlooked during ERP implementations.

You have no contingency budget.You don't know what you don't know when you budget for theproject. And, of course, things never go exactly as planned. Trust me when I say, you will find that onepart of the software that doesn't fit your business and needs customization. You will find that onebusiness process that takes a while to get right and causes delays. You will find that pocket ofemployee resistance that works to dismantle all that you have built. It is much easier to ask your Boardfor money up front instead of after you've blown through your budget. Depending on risk andcomplexity, Panorama consultants often recommend that up to 15- to 20-percent of a companys total

budget should be set aside for contingency.

You don't have at least three iterations of conference room pilots or integration testing.MostERP software is flexible and robust out-of-the-box, so defining your business processes and workflowscan be challenging to justify. But just as you wouldn't introduce a new product or manufacturingprocess without extensive testing, you shouldnt introduce entirely new business software into yourorganization without testing and refining.


3/17

Page 2 of 16




Your budget assumes that software license costs are a majority of your total implementationcosts.Software is the relatively easy and low-cost portion of your budget. Even with an acceleratedimplementation, you will have costs related to configuration, hardware, internal and external resources,integration and a number of other budgetary line items that you must anticipate to avoid nasty surprisesdown the line.

You don't have a strong program management team with at least several dozenimplementations under their (collective) belt.Every organization has a few people that eitherimplemented software in their previous lives or have a friend that did so. However, there is nosubstitute for a team of experts that have been through it a million times. Survey your organization andfind those employees who have been there done that to help guide the implementation.

The software techies are running the project. If the business isn't driving the project, then you're introuble. Too heavy of an IT hand will lead to software that doesn't fit the business, employees thatresist the software, cost overruns or all of the above. Hands-on functional and technical expertise isimportant, but these resources shouldn't be running the project.

You don't have a business case, performance metrics, or a benefits realization plan.Hopefullyyour organization isnt implementing ERP just for the fun of it. Assuming its not, then you should havemetrics to define how you expect the new system to improve the business, along with a plan of how youare going to measure actual results. It doesn't stop there, either since you won't achieve businessbenefits on day one, you'll need a plan to introduce continuous improvements.

Your definition of success is: Just get the damn thing up and running.It's easy to fall into thistrap after the project has been dragging on for months or years. However, this is a slippery slope. Onceyou start cutting corners, budgets and time allocations just to get the project done, you are driving uplong-term costs and risks.

You have very little margin for error to miss customer shipments at go-live.You don't want toassume that you are going to have problems at go-live, but according to Panoramas independentresearch, 54-percent of organizations experience some type of operational disruption after go-live. Ifyou don't have much slack in your inventory or lead times, then this can magnify the risks of the project

You will not customize the software, under any circumstances. Unless you are a start-up withabsolutely no existing business processes, this is a bigger risk than many will admit. While the line inthe sand may be drawn for good reasons, it is not realistic. In fact, Panorama research has found thatonly 11-percent of companies implement without any customization. In addition, adopting businessprocesses baked into the ERP software can create misfits with your business needs and/or magnifyorganizational change challenges. These aren't necessarily things that can't be worked through, butmost companies are not prepared to deal with the consequences.

Though theyre not quite as obvious as a dead canary, the above are a few indications that your project maybe in trouble. But dont despair: each warning sign that you head off at the pass will improve your chances ofhaving a successful ERP implementation.


4/17

Page 3 of 16




Great Expectations: Why Do We Expect So Much From Our ERP Software?

Charles Dickens wasn't the only one with great expectations and an occasional letdown along the way.Panoramas research shows that fifty-percent of organizations fail to realize at least half of expected businessbenefits from their ERP implementation. Much like the characters in Dickens' novel, those trying to select andimplement ERP software are faced with high hopes and great expectations, only to make some bad decisionsand face some significant challenges along the way.

While not all ERP challenges are extreme enough to merit mention in a newspaper or legal journal, it is clearnot only that they abound but also that they are often related to mismanaged expectations. In one ofPanoramas online polls, 24-percent of respondents cited realistic ERP implementation expectations as themost important requirement to avoiding failure.

The good news is that there are some guidelines to keep expectations aligned with reality. It's important towatch for the pitfalls and landmines that often lead to unrealistic expectations. For example, how many of thefollowing statements sound familiar?

! We'll get this implementation done in no time.Software vendors and consultants are notorious forover-simplifying the implementation process. Most sales reps don't know (and in some cases, don'tcare) what it takes to do an ERP implementation right, but they are experts in making the sale.

Naturally, it is in their best interests to downplay the time, costs and risks associated with the project.Most projects take longer than expected and/or cost more than expected, so make sure you're notbasing your timeline and budget (and career) on overly optimistic and unrealistic estimates. Instead,use benchmarks of what other companies similar to you have actually achieved, such as those found inPanoramas 2012 ERP Report(available at panorama-consulting.com).

A more realistic expectation: Respect that ERP implementations are difficult and complex businesstransformations, and budget time, money and resources accordingly.

We're not going to customize a thing.Most companies, including Panoramas clients, draw thisline in the sand early in the ERP evaluation and selection process. While it is a noble and rational goal,it's not realistic and it is far from reality. According to our studies of thousands of ERP implementations

across the globe, and as mentioned previously, only 11-percent of companies implement out-of-the-boxsoftware without any customization. In addition, only 6-percent of respondents in one of our online pollsindicate that ERP customization is the most important factor to avoiding ERP failure.

A more realistic expectation:Recognize that customization will likely occur but minimize the effect bycustomizing only when necessary to preserve your company's core competencies and competitiveadvantages.

ERP software is going to change our whole business.And it should, but it's not going to happenovernight. The realization of actual benefits requires more than expecting them; they need to bemeasured with metrics closely aligned with business processes. Our research shows that half ofcompanies that have implemented ERP software fail to realize the business benefits they expected.

Again, it is okay to expect a lot, especially in this arena, but it takes some work to get there.

A more realistic expectation: Expect high business benefits but set targets and put in the legworkrequired to realize those benefits.

We all want our ERP implementations to go extremely well, deliver high business benefits and incur the lowest


5/17

Page 4 of 16




possible time and cost. Remember, however, that ERP projects are not technical transformations; they arebusiness transformations. It's important to treat them as such. Regardless of whether your organization isusing traditional on-premise ERP software, software as a service (SaaS), or software implementationaccelerators, changing your business processes and organization requires a great deal of skill and work.

Five Mistakes That Will Make Your ERP Implementation Feel Like a Bad Horror Movie

Too many ERP implementations play out like a bad horror film. For example, in the movie Saw, the creepyguy with the weird voice and disturbing mask kidnaps a bunch of characters and asks them to fight for theirlives by performing a series of seemingly impossible tasks. Whether it's running through a room of razor wireor sawing off a leg to break free from being locked in a room with toxic fumes, the odds clearly aren't in favor ofthe hapless characters.

Project managers and executive sponsors of ERP implementations often feel the same way. Notunderstanding how ERP systems work, how they can be completed on time and on budget, or how to get thebusiness to adopt the new system can feel like navigating the impossible.

Unfortunately, when faced with this task, many ERP project team leaders and core team members makedecisions that turn an already difficult situation into a nearly impossible one and set their initiatives up for

failure. Panorama consultants have seen many of these mistakes time and time again both when weve helpedcompanies recover their projects and when weve provided expert witness and testimony in ERP lawsuits.

Here are five common mistakes that will put you in a bind that you may not be able to escape:

1. Business requirements free for all. Business requirements definition by committee generally doesn'twork, and I wouldn't be going out on a limb to say it has never worked for anyone. Because modernERP systems are so robust and flexible with countless potential business process variations, thereneeds to be some control, rationalization and business justification for defining business processes andrequirements. While you want to gather input from key stakeholders and business process owners, youdon't want everyone to have an equal say in what the system will or won't do. Failure in this area is asure-fire recipe for a very long and costly implementation.

2. Cutting project costs to save a buck.In today's economy, gutting budgets is the name of the game.Long gone are the days of blowing through tens of millions of dollars on ERP projects with no results toshow. However, some companies go too far and throw the baby out with the bathwater. Cutting projectline items like OCM, business process management and third-party project management support maylook good on paper, but we have yet to see a situation where these cuts save money in the long-term.More often than not, cutting project costs too close to the bone will cost your company multiple timesthe money saved when the go-live doesn't go well.

3. Just get it done quickly.Even though our research shows that the average company requires 14months to implement their ERP solution, companies are often lured in by the false impression that ERPimplementations can be completed quickly and with relatively little effort. Executives with little ERP

experience are notorious for buying into these unrealistic expectations, which can jeopardize the wholeproject. ERP software can usually be implemented in a single day (literally), but getting it to work theway you want it to for your business is an entirely different story. If you don't spend the time to addressall the business aspects of an ERP initiative, it will cost a lot of time and money to fix the resultingproblems down the road.

4. The Hail Mary go-live.As mentioned previously, Panoramas research shows that 54-percent of all go-


6/17

Page 5 of 16




lives involve some type of material operational disruption to the company so why increase those oddsby going live when you're not ready? Even if you're behind schedule or outside the budget parameters,it's important to understand that going live before the business is ready can cost an organizationmillions. For example, we recently worked with a company that decided to go-live before they wereready. Although Panorama consultants advised them to wait 30 days to finalize key project activities,they decided to go forward anyway with the notion that they would save roughly $100,000 in additionalproject costs. At the end of the day, they went live before their order entry processes were ready adecision that cost an estimated $2 million-plus in cancelled shipments from disgruntled customers.

5. Our customers and shipments will be fine, even if the go-live isn't smooth.The above anecdoteprovides one example of the cost-benefit tradeoffs of cutting corners but hindsight is 20/20. How wouldyou quantify the cost of cancelled shipments or lower customer satisfaction caused by a rushedimplementation? How would you quantify the cost of the system not supporting key processes requiredto service your customers because they werent defined or tested well enough? Those are thequestions you need to ask yourself when determining the pros, cons and risks of cutting corners on anERP project.

Welcome to the Jungle: Lessons from ERP Software Implementation Failures

As noted above, ERP software implementation failures inflict a great deal of pain on organizations. Whether itsimplementation cost overruns, software that doesnt support the business, or devastating operationaldisruptions, ERP failures entail very negative consequences. So why do 50-percent of organizations fail torealize at least half of expected business benefits from their ERP implementation?

Our experience helping clients clean up poorly managed selections and implementations along with our timespent as expert witnesses in ERP lawsuits, has taught us quite a bit about the reasons for ERP failure. Beloware five trends I see in most troubled enterprise software implementations:

1. Lack of software fit.The first stumbling block for many failed implementations is a severemisalignment between software functionality and business needs. There are hundreds of enterprisesoftware options in the marketplace, so it is important to navigate carefully and find the product with the

right fit. Too many failed implementations neglected to engage in an effective ERP software selectionprocess, which can have long-lasting negative effects on the entire organization.

2. Unrealistic implementation expectations.As mentioned previously, enterprise software sales repsoften understate the level of resources required to make the implementation successful, so manycompanies fail to budget adequate time, money, resources and external consulting support to make theproject successful. In addition, failed implementations often neglect to include key activities in theirimplementation project plan, such as OCM, business process and workflow definition and thoroughconference room pilot testing.

3. Lack of executive buy-in and support.Executive buy-in involves more than signing the checks anddelegating the implementation to a project team. It involves defining clear implementation objectives,

establishing project governance, and making tough decisions when needed. Executive buy-in isarguably the most important factor in an ERP project, because it directly affects the other four failurepoints.

4. Propensity to customize software rather than leverage standard functionality.Nearly every failedimplementation I have seen suffers from this problem, and it is often because of a failure to select theright software in the first place (see the first point above). The more you customize the software, the


7/17

Page 6 of 16




longer its going to take to implement, the more its going to cost, and the more risk you introduce intothe project. But as we covered earlier in the chapter, its typically not realistic to completely abstain fromcustomization. The key point is that changes to the software should be devoted only to those areas ofcompetitive advantage or differentiators. If you arent able to limit customization to those areas, thenyou should either find another ERP software solution or back up and rethink your strategy.

5. Lack of ERP software implementation expertise.Implementations are tough. A team with testedbattle wounds is going to dramatically increase your likelihood of success. As we often tell our clients,

the fastest and cheapest way to implement enterprise software is to do it right the first time. Failedimplementations are more likely to have inexperienced team members who dont know enough to knowwhat they dont know. Add this failure point to an environment without executive buy-in and support andyouve got a recipe for disaster.

If you see one or more of these patterns emerging during your implementation, then your organization is atsevere risk for ERP failure. On the other hand, if your implementation project team is able to avoid these fivecommon pitfalls, then you have laid the foundation for ERP success

Fixing a Failed ERP Implementation

The good news is that troubled IT implementations can be fixed, even if they are way over-budget, behindschedule and creating great organizational strain. In these instances, Panorama consultants often adviseclients to reposition their projects as business improvement projects rather than IT projects.

At this point, you have to forget about ERP. During or after a failed implementation, the software is likelycreating huge difficulties. Just the mere mention of the letters E, R and P probably causes employees tocringe, so its important to focus less on ERP and more on how you are going to fix your business operations.With this new mindset, you can use ERP only as necessary to make business improvements to get yourorganization back on track.

Steps to Fix a Failed ERP Implementation

Assess each area and department of the business that ERP is affecting.What are your keyperformance measures (order fill rate, time to close books, order accuracy, etc.)? Where are yourbiggest operational pain points? Determining these issues and indicators will require you to secureinvolvement from key business stakeholders (if you havent already).

Develop two-tiers of potential solutions: stopgap / quick fix solutions and long-term solutions

Determine the costs and time required to implement each of the options.

Prioritize your problem/solution combinations to arrive at the top five to ten areas where youwill realize the most immediate business impact at the lowest cost (e.g., low-hanging fruit).Manyof these solutions may or may not involve ERP functionality. Instead they may require more training,communication or process optimization to support new solutions. Our experience has shown that

business process management and OCM are frequently the most common problem areas in failed ERPprojects, so many of your solutions may not even involve changing the system or implementing newfunctionality.

Begin implementing these low-hanging fruit solutions.The goal should be to build organizationalmomentum and confidence with these quick wins.


8/17

Page 7 of 16




Begin implementing long-term solutions as time and resources allow. Once you get some quickwins in place with the shorter-term solutions, begin prioritizing and implementing your long-term, morepermanent fixes the same way you did with your short-term problems.

By following this approach, you will better position your organization to make your troubled implementation asuccess and optimize the business benefits of ERP.

Commonalities Among Recent ERP Failures

The last year has seen a string of high-profile failures, ranging from mid-size companies such as ParknPooland CareSource Management Group to large government entities such as the United States Air Force andNew York City.

The good news is that this doesn't have to be the case. Panorama was not affiliated with any of theaforementioned ERP failures, but we found some common patterns by diagnosing public information aboutthese and other high-profile ERP lawsuits.

1. Typically, ERP failures are not related to the ERP system. This may sound like an oxymoron, butit's true. If you choose an ERP system that is not a good fit for your business requirements, then yes,

you will likely fail in the implementation because you are trying to force-fit a system that isn't right foryour organization. But even if you choose the right software, there is still a high risk of failure as most ofthe reasons are not related to technical issues. Instead, issues related to contracts, business processmanagement, project management and OCM are often at the root of ERP failures.

2. Poor project planning and unrealistic expectations set the stage for failure. The United States AirForce spent over $1 billion dollars and nearly eight years on its Oracle ERP implementation withoutyielding any significant military capability. The initial contract with Oracle was for $88.5 million. While Idon't know much about the USAF and its specific needs, the delta between planned and actual costscertainly seems to indicate an environment rife with unrealistic expectations.

3. Strong management of third-party resources is required for a successful ERP implementation.

According to a ParknPool representative, the organization believed that Epicor could implement its ERPsystem in seven weeks; seven months later, they still didnt have a workable system. Again, knowingnothing about the specifics of this situation, it still seems that there was significant confidence placed inEpicors ability to implement the system in an incredibly short timeframe. Although third-partyorganizations and consultants are essential to ERP success, organizations must never place the keysto their organization in the hands of another without strong management and leadership from theexecutive level.

Lesson Learned From Failed ERP Implementations: Executive Buy-in

Building on point number three above, a commonly known success factor for ERP implementations is

executive buy-in and support, which should be a key component of an effective OCM plan. But what does thisreally mean?

Panorama is often called upon to clean up failed implementations, and executive support (or the lack thereof)is a root cause for many of the issues that lead to failures. Effective executive support is a key differentiatorbetween successful, best-in-class implementations and failed projects that cost too much, take too long anddeliver too few benefits.


9/17

Page 8 of 16




Our experience shows that there are four dimensions required for effective executive buy-in:

1. Support for the ERP project.In its simplest form, executive buy-in should entail support for theproject. This goes beyond approving the project and writing the checks; it entails supporting ERP as abusiness transformation initiative rather than a technology project.

2. Involvement in software implementation decisions.Executives frequently think that a hands-off

approach is appropriate once the project has been approved. This is not the case. Given the flexibilityand power of robust ERP systems, business processes and operational models can be defined in anynumber of ways within an ERP system. Therefore, while detailed project management is likely to bedelegated to others, key decisions about how the business is going to be run need to be made andsupported by the management team.

3. Commitment of resources.A common pain point of ERP implementations is lack of resources. Whileit often makes sense to leverage external ERP experts, these resources can never fully replace theknowledge and ownership of internal employees. The executive team needs to ensure that thecompanys best and brightest are committed to the project and that additional resources are provided tosupport the implementation teams day-to-day operational duties.

4. Communication with implementation team members and all employees.Employees need to knowthat the executive team fully supports the project. Therefore, periodic formal and informalcommunication from the company CEO or executive team says a lot about the degree of C-levelsupport for the project. Although Panoramas OCM consultants often craft the messages that are to besent by management to employees, executives need to agree with and deliver the messages in orderfor them to be effective.

Risks of Tier I Implementations

Tier I ERP systems are generally more robust, complex and, as a result, more difficult to implement than Tier IIoptions. SAP implementations in particular get a bad rap because of the large, high-visibility companies that

have tried and failed to implement SAP.

So what is it about SAP and other Tier I implementations that make them so risky and subject to failure? Firstof all, it is important to debunk the myth that Tier I implementations are more likely to fail than Tier II or SaaScounterparts. As bears repeating, Panoramas research data shows that there is very little correlation betweenspecific software packages and their failure rates. In other words, different ERP vendors do not have materiallydifferent levels of ERP implementation success and failure. In our work as expert witnesses in ERP lawsuits,we have found that mistakes and failure points are fairly consistent across various ERP systems and have verylittle to do with the software itself.

Which brings us to a second point: while it does matter what software you choose in that you want a solutionthat fits your specific business needs, you are just as likely to experience problems if you don't handle the

implementation correctly. Even an ERP system that is a perfect fit for your organization isn't going to beimplemented smoothly if appropriate measures aren't taken.

That said, there are some things that make SAP, Oracle and Microsoft Dynamics implementations moredifficult and risky. The good news is that those risks can be mitigated once you understand them.

Top Three Tier I Implementation Risks


10/17

Page 9 of 16




1. Complexity. There is no denying that SAP, Oracle and Microsoft Dynamics implementations arecomplex compared to their Tier II counterparts. They each have extremely broad, deep and integratedfunctionality designed for a variety of industries, which is generally a good thing, but it's very easy to getangled up in their related webs of complexities. One change to a single aspect of your master data canhave profound impacts on your end-to-end business process flows. This can be overwhelming,especially if your implementation team doesn't have the necessary technical and functional experience.

2. Degree of Change. Most companies that implement Tier I systems are not migrating from one robustand sophisticated ERP system to another; instead, they are going from fairly primitive businessprocesses and business software to something much more powerful. Think of a 16-year-old that is justlearning to drive: he isn't going to handle a high-performance racing vehicle well if he hasn't evenmastered a Ford Focus. Most companies drastically underestimate just how big the change is going tobe from a technical perspective, and more importantly, from a business process perspective.

3. Flexible Business Processes. SAP, Oracle and Microsoft Dynamics each have tremendous amountsof functionality and potential configuration variations. These products have powerful configuration andintegration tools, which means that implementing companies have a world of possibilities at theirfingertips. However, the configuration of the software doesn't matter at all if the business operationsand employees can't adopt and adapt to the new processes. For this reason, generic and

transactional-based training materials do very little to get employees comfortable with the systems. Asa result, the business processes typically don't integrate well with the software, and vice versa.

Confessions of an SAP Expert Witness

Over the past 15 years, I have seen my share of successful ERP implementations. The Panorama team and Ihave successfully managed a number of complex implementations over the years ranging from SAP toOracle E-Business Suite, to Microsoft Dynamics to Tier II ERP implementations and have the battle scars toshow for it. In addition to managing implementations, weve also been called upon to provide expert witnesstestimony and analysis for some of the highest-profile ERP and SAP failures in the industry, many of whichyouve probably heard or read about in recent years. This experience as an ERP and SAP expert witness has

provided many valuable lessons that can help organizations avoid failure and make their projects moresuccessful.

Although our independent research shows that there is no correlation between ERP failure rates and thespecific ERP software implemented, SAP just so happens to have the largest market share in the industry andsome of the highest-profile Fortune 500 clients with pockets deep enough to afford legal battles so many ofthe lawsuits were hired for relate to SAP implementations. Most cases we're involved with have court ordersprohibiting Panorama from sharing client-specific details, but there are a number of interesting patterns worthmentioning that have emerged during our legal work.

Below are just a few confessions I can share from approximately a dozen cases that I have supported as anSAP expert witness. After all the deep-dive reports, depositions, discussions with attorneys, and jury trials, I

can say with confidence that SAP failures typically boil down to a handful of common themes:

SAP failures are rarely about the software. When looking at SAP failures, it is easy to get stuck indiscussions about system configuration, Netweaver integration, poorly written customization code, andsoftware functionality, but these minute details are typically indicators of deeper root causes. Forexample, poor project management, lack of organizational change management and inadequatelydefined business process workflows are often the causes of some of these symptoms. Of all the expert


11/17

Page 10 of 16




witness cases we have been involved with to date,not a single one had much to do with the softwareitself. Instead, it had more to do with how the software was implemented.

SAP failures typically begin early in the sales cycle. Expert witness work is similar to crime scenereconstruction. In the thousands of pages of documentation available in most cases, we have plenty ofevidence (and the benefit of hindsight) to be able to assess what went wrong and when and how it did.What we find in most cases is that the stage is set for failure early in the sales cycle -- beforeimplementation even begins. Mismanaged expectations, poorly reviewed contracts, ill-definedstatements of work, poor project plans and a host of other breakdowns early in a project often create adomino effect of a series of failure points throughout the implementation. For this reason, we oftenadvise our clients that they are actually influencing their likelihood of success or failure just as much inthe software selection and implementation planning stages of the projects as they are in the executionphase.

Every SAP failure involves poor organizational change management. Poor OCM is the single (andonly) issue that we can definitively say was a key contributing factor to each and every expert witnesscase weve been involved with. In each case, user resistance, unclear understanding of businessprocesses, roles and responsibilities, and poor training were just some of the organizational changemanagement issues experienced by the implementing organizations. Too often, organizations that havesuffered SAP or ERP failures had implementations that were too focused on technology issues ratherthan the more important business process, people and organizational issues.

Executive abdication is one of the root causes of SAP failure. The above issues are oftensymptomatic of even deeper issues at the executive level. As mentioned previously, CFOs or CIOs toooften delegate an entire SAP implementation to a project manager or project team with little to noexecutive involvement, which is a sure-fire recipe for disaster. Executives need to be engaged, makekey decisions regarding how their operations will look going forward, and provide oversight andgovernance of the project. However, too many executives assume they can abdicate themselves ofthese responsibilities, which often lead to the issues outlined above.

While every ERP implementation and SAP expert witness case involves various nuances and unique factors,most can be traced to the above four issues. The person or people most responsible for the above failurepoints vary from case to case, but regardless of who is at fault, these are issues that need to be proactivelyaddressed and managed.

The Real Reasons ERP Implementations Fail to Deliver to Expectations

CFOs and CIOs of most organizations begin their ERP implementations with the expectations that theirbusinesses will be transformed along the way. Using the power and flexibility of ERP systems such as SAP,Oracle, Microsoft Dynamics and Tier II ERP software, executives expect material cost improvements to theirsupply chains, more effective interactions with their customers, and better visibility to operational information.However, and as mentioned previously, our 2012 ERP Reportfound that half of organizations fail to realizeeven half of their expected business benefits.

Based on this gap between expectations and delivered reality, it is clear that something gets lost in translationfrom the time the executive team signs off on the investment until the organization flips the switch on its newERP software. Unfortunately, the things that seemed feasible at the outset of most enterprise softwareinitiatives seem unattainable as those same initiatives progress.


12/17

Page 11 of 16




There are a handful of challenges we see every day with our clients both the ones that enlist our assistancewith implementation and those that retain our services for expert witness engagements related to their ERPfailures. Here are three common pitfalls that most organizations have trouble navigating:

Tradeoff between speed, cost and business results. Most CFOs and CIOs are painfully aware ofthe risks associated with ERP implementations, and most are even more aware that a botcheddeployment will likely cost them their jobs. While there is a need to leverage enterprise software as anenabler of business transformation there is also the pressure to deliver on time and on budget. Thesecompeting priorities are inherently in conflict and, when forced to choose, speed and cost will almostalways trump business results. After all, leaders within most organizations know they wont be aroundto see the business transformations come to fruition if they dont survive the ERP implementation.Further, the risk-adverse nature so common to executives often lead them to choose this safer routewithout ever directing necessary organizational focus to potential business improvements.

Unrealistic expectations.Most executives have unrealistic expectations to begin with. They too oftenhear (and believe) the sales hype from ERP vendors that their software can be implemented inrelatively little time and with low cost and risk. For example, while our experience and research showsthat the average implementation takes 14 months and significantly longer for larger and multi-nationalcompanies, it is not uncommon for software sales reps to suggest that their software can beimplemented in just a few months. These unrealistic expectations result in unrealistic budgets andresource allocations. Its no surprise that corners are quickly cut when it becomes clear that there areinadequate resources to get the job done. When executive and project teams are under the gun tofinish the project anywhere close to original projections, you can be sure that post-implementationbusiness results are one of the first things to get thrown by the wayside.

Best practices = watered down competitive advantage.Just as point #1 creates competingpriorities, so do the concepts of software best practices and quantum leaps in competitive advantage.In other words, if a certain business process is baked into an ERP systems canned best practices,chances are that its not always going to result in a material improvement to operations. Sure, moretransactional, back-office operations like accounts payable or HR compliance may see a lift, but yourcore customer-facing processes and competitive advantages are much less likely to benefit from theseso-called best practices and off-the-shelf functionality. As a result, and as outlined in the below graphic,organizations too often end up with watered down competitive advantages or business processes thatsimply mimic or automate their old way of doing business.


13/17

Page 12 of 16




There is no easy answer to how to best achieve business results that meet or exceed executive expectationsand lead to true business transformations. However, there are a number of proven success factors that canhelp ensure your ERP implementation leads to material business improvements:

Create a realistic implementation planthat outlines the true resource requirements of a successfulimplementation.

Clearly define the goals and priorities of the ERP implementation. For some it will be to get the jobdone on time and on budget with little to no focus on measurable business results, but for most it will beto deliver a marked improvement to business operations.

Quantify and prioritize expected business results, which will drive various aspects of the initiative.

Ensure business processes drive the entire initiative, from ERP software selection all the waythrough the multiple phases of implementation and post-implementation.

Focus on OCMto ensure potential business process and system improvements stick within theorganization.

These success factors will ensure that your ERP implementation delivers the results expected by yourorganization.


14/17

Page 13 of 16




Case Studies of ERP Failures

Dorset County

Even with dozens of high-visibility ERP failures to point to over the last ten years, I dont remember a time inmy career where the failure rate was quite as pronounced as what I saw in 2010. Earlier in the year, it was

Marin County. Near Thanksgiving, Dorset County in the UK was added to the list, reporting that it spent 16million pounds on a system that made peoples jobs more difficult and less efficient and produced lowsatisfaction rates.

As you read that last sentence, keep in mind that an August 2008 article in Computerworld UK quoted ElaineTaylor, director of corporate resources at Dorset as saying, The ERP system is the backbone of our changeand efficiency program and will drive us to improve how we work.

Obviously Dorset Countys ERP implementation did not pan out as Ms. Taylor and her team expected. Theinteresting thing about these recent failures is that they tend to point to some common themes. Perhaps thereare some lessons to help executives and project managers not repeat the same mistakes?

Three Common Elements of Recent ERP Failures

1. Where are the business benefits?Organizations like Dorset County get to the end of an ERPimplementation and ask themselves what they have to show for their multi-million dollar investments. Inthese cases, jobs have gotten less (not more) efficient, sales have decreased (not increased), andbusiness processes now take longer than before. This is unacceptable and is enough to make any CFOnauseous after such large capital outlays. However, the problem is usually not because the softwaredoesnt work, which leads us to number two . . .

2. What about the people?At the end of the day, ERP systems are just tools to get a job done, but itsthe people that actually deliver the business processes and business benefits. In the case of DorsetCounty, the organization claimed that processes that took one minute now take one hour andemployees are so stressed out as a result that they are forced to take sick time. I dont believe weveever included employees getting sick as one of the line items in our total cost of ownership estimates,so I dont imagine that Dorset County did either.

3. Training is a key ERP failure point.In every failure and ERP lawsuit that Panorama has been hired tofor, poor training is probably the most common theme. Dorset County is no different, with 58-percent ofemployees expressing negative feelings about training, usability and support. Even several monthsafter go-live, 55-percent still expressed negative feelings about the system in general. Clearly,something went wrong in the training and user support provided by the organization. As Ive statedseveral times in this book, generic, transaction-based system training is woefully inadequate organizations need more comprehensive OCM plans to ensure users accept the new system.

It may seem repetitive that I keep harping on these same lessons but consider how many times similarmistakes have been repeated over the last ten to 20 years. As we look to the future, I expect that the Justslam it in, flip the switch, and voil!style of ERP sales messages will lead to more ERP failures as companiesbegin to realize that even SaaS ERP or Tier III ERP systems require fundamental changes to their businesses and their business processes. There is no easy button for changing your business, even if the softwareitself is becoming easier. The other thing to note is that these lessons become obvious only in massive failures


15/17

Page 14 of 16




(e.g., Dorset County, Marin County, Waste Management, etc.). For every instance like these, there arehundreds, if not thousands, of more moderate failures that repeat the same mistakes but dont quite reach thedisaster or lawsuit phase.

Lumber Liquidators

In the fall of 2010, Lumber Liquidators attributed its poor quarterly results to its troubled SAP implementation.

The interesting part of this ERP failure, which is consistent with what we see in the marketplace, is that thecompany claimed the software itself wasn't the cause of their woes. If the ERP software works so well, whatwas the problem?

The company's reason for the failure: lack of user acceptance and adoption of the system. It wasn't just thatthe new system was difficult for employees to figure out it also had a measurably negative impact on thebusiness, with the company estimating that it lost between $12 million and $14 million in net sales after go-live.In addition, the company's profit dropped 45-percent as a result. Lumber Liquidators is not a Panorama client,but I would venture to say that the company's executive team didn't factor those opportunity costs into theirtotal cost of ownership and ROI estimates.

So what could the company have done differently? Three factors have the highest correlation with positive use

acceptance of a new system: adaptability, understanding and IT skills.

These three areas must be addressed as part of an effective OCM plan, which Lumber Liquidators most likelydid not adequately focus on. Many companies think that some quick end-user training a few weeks before go-live will do the trick, but as this example illustrates, that is simply not the case. Instead, organizations need to:

Help employees adapt to and feel comfortable with changevia constant and early communications.Ease the transition by relating the new business process and system environment to the old way ofdoing things.

Ensure that employees have adequate IT skills in general,especially if they are going from acompletely manual business process environment to a powerful, automated and complex ERP system.

This requires much more than transactional training; it also requires that employees are given plenty oftime to become comfortable with technology in general.

Help employees understand what is changing, how things are changing, and why.Employeesneed frequent communications and training about how their business processes are changing, who isimpacted by the changes, and the benefits of those changes. Again, system-based training is woefullyinadequate in addressing these points.

Unfortunately, Lumber Liquidators isn't alone in its insufficient attention to OCM, training and communications.Most companies view these activities as optional or nice-to-have, but, as many companies realize the hardway, these are critical necessities. As Lumber Liquidators illustrated in its Q3 results, a few hundred thousanddollars and even just a little more time focused on change management would have easily taken a dent out of

the $12 million plus of lost sales that resulted from poor user acceptance of the new ERP system.


16/17

Page 15 of 16




Shane Company

In early 2009, jewelry retailer Shane Company filed for bankruptcy and partially blamed its botched SAPimplementation for its woes. While other factors such as a weak economy and a brutal retail environmentundoubtedly contributed to the companys difficulties, it is clear that its ERP project did not help matters.

ERP software is a double-edged sword. On one hand, it offers tremendous opportunity to improve andtransform a business. On the other, it can be risky if the implementation is not managed appropriately.

While Panorama was not associated with the Shane Co. ERP debacle, I observed a number of failure pointsbased on what I know of the project:

Failure to manage scope and cost.There is no reason for a $200M company to spend $36M andthree years to implement an ERP solution, as Shane Co. did. According to our study of 1,300 ERPimplementations across the globe, the average company spends nine-percent of annual revenue ontheir ERP implementations. The average Panorama client spends less than five-percent of their annualrevenue on their ERP investments. By contrast, Shane Company spent 18-percent of its annualrevenue on its SAP project and the solution still didnt work. This is clear evidence of a failure tomanage project scope and cost.

Undefined and/or untested business requirements and workflows.Given the fact that the companyspent as much as it did on SAP and still had inventory management issues, it is likely that thecompanys business requirements were not well-defined. If the company had clearly defined itsrequirements and thoroughly tested the system for those requirements prior to go-live, it would havebeen more likely to have more efficient and effective processes that would have helped avoid theproblem of overstocks and the wrong mix of inventory.

A budget and implementation plan that was not grounded in reality.In Shanes case, they weresold on a one-year implementation and $10M cost. The actual cost and duration was 300-percent morethan what the company expected. Any company considering a new ERP system should understandthat the goal of many software sales reps is to understate the cost and duration to close the deal. Anindependent ERP evaluation will often alleviate such mismanagement of expectations.

Poor ERP software selection.Although I cant be certain, it is likely that SAP may not have been theappropriate choice for Shane Co. Small- and mid-sized businesses such as Shane have dozens ofviable software options to choose from, so they should take the time to evaluate and select the rightERP system. If SAP was indeed the right fit for Shane Co., I have trouble believing that it would havecost nearly as much as it did.

There are probably other contributing factors to Shane Companys ERP failure, but these are somehypothesized lessons learned from the companys painful experience.


17/17

Page 16 of 16




About the Author

After 15 years of ERP consulting at large firms including PricewaterhouseCoopers and SchlumbergerSema,Eric Kimberling realized the need for an independent consulting firm that really understands both ERP and thebusiness benefits it can enable. He currently serves as managing partner of Panorama Consulting Solutions,the worlds leading independent ERP consultant.

Eric began his career as an ERP organizational change management consultant and eventually broadened hisbackground to include implementation project management and software selection. Erics background includesextensive ERP software selection, ERP organizational change, and ERP implementation project managementexperience.

Throughout his career, Eric has helped dozens of high-profile and global companies with their ERP initiatives,including Kodak, Samsonite, Coors, Duke Energy, and Lucent Technologies to name a few. In addition toextensive ERP experience, Eric has also helped clients with business process re-engineering, merger andacquisition integration, strategic planning, and Six Sigma. Eric holds an MBA from Daniels College of Businessat the University of Denver.

an experts guide to erp success chapter eight

Documents