ERP Governance: Simple, Important, But Definitely Not Embraced

In a recent post I excerpted passages from Lumber Liquidators Q3 2010 earnings release (NYSE: LL).  In this release LL’s management concisely explained the costly impacts of their not-so-successful ERP Go Live.

I think it’s important to applaud management’s candor.  Plenty of companies experience serious problems surrounding ERP yet make like a duck, calm on the surface but paddling furiously underneath.  I know one company who lost all visibility into collections following Go Live—they really didn’t know how much cash they were taking in for almost six months!

In most cases it’s not the technology that’s the problem—implemented correctly, ERP software works.  As with Lumber Liquidators (and MANY others) ERP failure is the result of too many things not being done correctly, or not being done by the right people, or not being done at all.

So what’s the solution: how can you substantially increase your odds of ERP success?

Well, Governance is a very good start.

ERP Governance is the process of deliberately managing relationships  so the right things get done at the right time by the right people to ensure your ERP is successfully delivered and used.

It’s obvious, but too often it does not happen.  Many business people are “just too busy” to discuss who does what.  Few see value in basic Governance concepts.

But  ERP is by design integrated and thus demands cooperation across organizational boundaries during implementation and use.

Successful ERPs clarify and manage the relationship between business and IT resources.  They deliberately manage the interactions across the different business functions implementing ERP.

We use Governance Maps to decide critical cross-business and business-to-IT relationships during ERP.   

Governance Maps are an effective tool for deciding:

1.  What needs to be done to successfully implement and support an ERP?

2.  Who is responsible for completing each task?

3.  At what point is each task completed? (During the Program? After Go Live? Both?)

It’s simple, really.

It just makes sense to decide who is doing what before you take first steps down your ERP path.

But we’re amazed how often these important decisions aren’t addressed until the pain and suffering begin.

Let's Visit The ERP Orphan (Failure!)

“Success has many fathers, failure is an orphan,” is a well-known English proverb.
So let’s visit the orphan: ERP failure.

Not the 15% of ERP projects that are cancelled, but the vast majority who somehow Go Live and limp through a trying Post Go Live period.

Meridian has been there with more than one client, most typically engaged after the Post Go Live problems become overwhelming.

Note that a lot of the initial wailing around Go Live is nothing more than noise—simple, solvable problems like people forgetting passwords.

But the real problems, the bad problems, follow a pattern. 

The “usual suspects” that sink ERP implementations are largely in the area of preparation, or more specifically lack of preparation.  These pitfalls include poorly cleaned data, insufficient training, and insufficient field support (no job aids, even worse no one to turn to for support).

The “hidden killer” of ERP implementations is subtler, though more insidious than a lack of preparation: it’s the failure to manage expectations about the ERP program, or more to the point to make the program a sufficient priority.

Hard data support this point.  Consider the following chart prepared by Meridian Consulting showing a strong correlation between ERP Project Outcomes (column 1) and Expectations Management (column 2).  And note the data in this chart represent over 180 projects (outcomes) and input from over 8,200 people who have implemented ERP (expectations).

Let me be clear: there will be system issues—some things will not work.

But most of your Go Live issues will be related to people, or more specifically your preparation of people and especially their expectations about ERP.  And the solutions are simple.

Make efficient, effective ERP use a management priority.  By the time you’re Going Live it doesn’t matter whether you think ERP is a good idea or not, you’re living with it, so make the best of it.  Allow people time to transition into new, ERP-enabled roles.

Ensure you have a proven process for continually managing and improving the data entered into your ERP system.

Provide training and opportunities to practice, a means for requesting retraining (because some proportion of your people will not go to the right courses the first time), and view training as never-ending (there will be new hires who have to be trained).

Support end-users far longer than you would like, and make sure personnel supporting users have the bandwidth needed to provide effective support.  Make user support an acknowledged, rewarded part of your SuperUsers' or PowerUsers' job profile for nine months to a year Post Go Live.

There is nothing mysterious or particularly difficult in my advice.

The important thing to remember is Post Go Live success is really the result of doing a few things right on behalf of the people who will use the system.

Special ERP Note: Lessons from Lumber Liquidators

A special contribution to our continuing discussion of Implementation Success

If you're in the ERP world and haven't heard about Lumber Liquidators you will.

Key excerpts from Lumber Liquidators Q3 2010 earnings report are provided in this post.

Three important points before we dive into the data:

First, substitute ERP for SAP in every instance—this is a cross-platform problem.

Two, applaud Lumber Liquidators for manning up to their problems, not pointing fingers (at least publicly), and moving ahead to fix their troublesome investment.

And three, please note that no one blames the system—it’s Lumber Liquidators inability to use the system that impacted Q3 revenue and profitability.

Enough said, here’s the headline of the Press Release—yikes!

Lumber Liquidators Announces Third Quarter 2010 Financial Results

~ SAP System Implementation Impacts Third Quarter Results 

This is the first line of the earnings release:

Lumber Liquidators (NYSE: LL), the largest specialty retailer of hardwood flooring in the U.S., today announced financial results for the third quarter and nine months ended September 30, 2010.

Standard stuff, but here’s what immediately  follows:

SAP System Implementation

On August 22, 2010, Lumber Liquidators implemented the most significant phase of its integrated business solution from SAP, including an enhanced point-of-sale solution, a warehouse management and inventory control system, an integrated merchandising and product allocation system, and related management reporting functionality.

All critical information was converted from the previous information system and the Company has continued to operate its business without interruption since the conversion.

Here’s the bad news:

However, the implementation significantly impacted third quarter 2010 results by reducing productivity, primarily across store and warehouse operations, including less effective conversion of customer demand into invoiced sales, less efficient product allocation and distribution, and the general need for additional resources to operate the business.

Let’s get specific:

The Company estimates that reduced productivity resulted in approximately $12 million to $14 million in unrealized net sales during the third quarter.

SG&A expenses for the third quarter of 2010 reflect one-time costs of approximately $0.5 million related to the SAP implementation, primarily resulting from increased payroll and warehousing costs.

The Company estimates that reduced productivity subsequent to the system implementation increased inventory carrying levels by approximately $8.0 million.

That’s $20 - $25 million in additional cost, largely because people were not prepared to use their new ERP system! 

Jeffrey W. Griffiths, Lumber Liquidators' President and Chief Executive Officer, commented, "While we are confident that over the longer-term the implementation of our new SAP system will significantly benefit the business, our performance in the third quarter reflects declines in productivity both at the store-level and in the flow of product through our warehouse following implementation."

“Overall, we remain focused on improving our operations and building a foundation for long-term success."

And in closing. . .

Sincere accolades to Lumber Liquidators' executives for doing the right thing after the fact—admitting the hit and committing to long-term success.  If you’ve ever shopped at a Lumber Liquidators you know they’re a quality outfit.

I don’t know what Lumber Liquidators spent to prepare their people for ERP or (more important) how they prepared their people for ERP.

But it was clearly not enough.

The Program's NOT The Problem!

I noted in a previous post that program credibility is a core requirement for program success. 

“You simply must make people believe you can and will complete what you have started, even if this has not been true in the past.”

In this post I’d like to review exactly how some of our clients have successfully grown program credibility.  My aim is to provide some concrete examples you can apply toward future projects.

Bury the Past

People are shockingly quick to tell us how their organizations have failed in the past:

“Has anyone told you about Project Forward?  It’s called ‘Project Forever’ for a reason, you know.”

Even worse, it’s dismaying how often past failures are considered relevant to your future efforts.

“We’ve tried and failed to do this so many times in the past, why should this project be different?”

It’s imperative to accept the inevitable, unfavorable comparisons with past efforts.  This requires admission you’ve failed, consideration why prior projects failed, and a credible demonstration of why things are different this time.

One practical suggestion is to address right up front why your next project is different from past efforts.  But give good reasons—failure to really differentiate ensures your current initiative is lumped with past disasters.  And be bold: call out the elephant in the room before it squashes support for your next project.

Leaders to the Front, Please

I don’t think you can underestimate the extent to which people expect, even demand executive attention and commitment to top projects.

“We all know this isn’t Tom’s top priority, why should it be mine?”

The imperative here is to trump talk with action.  Everyone knows which projects receive resources and which subsist on lip service. 

Executive commitment is measured by the answers to two questions that test a sponsor’s mettle: 


* Will you use your political capital to help us when other leaders and managers are putting up roadblocks?

* Will you ensure we have the resources we need, including the specific people we need?

Every organization should slim their program list down so it includes only those programs the organization and its leaders will adequately and consistently resource and support.

And all talk about top priorities must be consistently backed by political muscle and capable resources throughout the project lifecycle (however ugly it may be).

WHO Matters Most

The final determinant of program credibility is the most powerful but the most difficult to influence. 

Program credibility—the fundamental belief we can and will complete a program—results when the majority believes the people they work with and the people (or person) they work for also believe the program is credible.

The challenge here is indirect.  You cannot tell people to believe you can succeed.  You have to repeatedly make the case and help people across the organization believe.

I think this is where most change management programs fail.  You know the story, the program checks all the boxes on the change management checklist yet falls flat on its face.  Why?  Because the program failed miserably at the grass-roots level!  Despite the balloons, banners, pronouncements, and events people at all levels continue to doubt this program is different from every past failure.  Or they observe that the program really isn’t a top priority because Joe, the boss’ pet hot shot, was detailed to a competing program.  They’re never given a reason to believe we can succeed so they doubt we can.

To end, program success requires a shared belief you can succeed. You can build this belief.  It just takes departures from the past, real leadership commitment, and a consistent, credible effort to grow support amongst the people who really decide program success. 

The System's NOT The Problem (Part One)

Prior posts focused on implementing technology.  I’d like to take a step back to consider how people actually use the systems we’ve implemented, or more specifically to address how people exploit the information we pour into them.

The answer, of course, is it depends.

If you ask,”How well do we use information to operate our business, to do things like tally revenues, pay the bills, account for people and the like, the answer has to be ‘pretty well’.”

If you instead ask, “How well do we use information to better our business?” the answer is far less encouraging.

Consider the following charts.  You can quibble with the data points (endlessly) but the main messages resonate with me.

Both charts show the results of a survey of over 1,300 managers polled by the Harvard Business Review.  In the first chart (below) the left axis lists four important information uses.   The top (blue) bars show the percent of respondents who say their organizations use information to effectively improve service, sales, loyalty, and collaboration.  The second (red) bars show the percent of respondents who say the ability to achieve each objective is important to their business.

The gaps within each set of bars is dismaying: collectively, these gaps indicate a persistent inability to use information to serve customers, grow sales, and increase collaboration—in other words, to better our business.

I don’t think these gaps are terribly surprising.  Most organizations have volumes of information about what has happened.  Most own scads of information that could be used to make good things happen, but somehow fail to prospectively use information to make something new, important, valuable happen.

My second chart suggests why organizations don’t use information prospectively: information is as fragmented, isolated, and silo’ed as our organizations (all together now, D’OOHH!).

I don’t know if information utilization would really improve if there was “unified view” available to all—what I need to see as a customer service manager varies from what you might want to know as a salesperson. 

But I do subscribe strongly to the idea that organizations fail to effectively use information because information is bound too tightly by existing organizational structures.

Perhaps we need a new “information structure”—a commitment to making information access and use largely independent of existing organization lines.  Data collection could continue to conform to organization structures; accounting will collect the bills, sales will still book the sale; but profound changes in how information is compiled, accessed, and USED are in order.

But what would that look like?  And more to the point how would we get there? 

More thoughts on these practical considerations in future posts. 

Program Assessments Illuminate Real Problems

I thought it would be useful and interesting to share actual Assessments of three  programs.

My intent is to highlight a framework Meridian uses to help clients ensure program success. 

Each evaluation was completed by Meridian as part of our Program Delivery Assurance services.  In each case we were engaged by business leaders to provide a frank evaluation of the current state of three very different ERP programs and (more important) to advise whether and how to proceed with their ERP efforts.

This post highlights three ERP programs to provide a measure of cross-program comparability.  In practice our framework has been used to evaluate and guide a wide range of programs.

It’s important to note that we believe our charge is to find the best way to move forward.  Sure “shut down” is a last option, but it’s not considered lightly.  Experience shows that in most cases when there’s a will there’s a way to succeed with almost any program.

Summary evaluations of each program are shown in the following table (extensive analyses underpin each judgment).  A note on how we conducted these ERP evaluations follows in a separate post.

Program Dimensions	Program A	Program B	Program C
Planning	Murky	Very light	Good
Scope Management	“Bitten off far more than you can chew”	Too accommodating, creeping	Good scope management
Fit with Culture	Challenging—“we do everything at  once”	Standardization at odds with culture	Poor—individual fiefdoms threatened
Sponsorship	Confused but fixable	Sincere, though accountability is missing	Low—executives view as an IT initiative
Priority	Depends who you ask	Large program, not treated that way	One of many “top priorities”
Relationship with Business	Broken—no one really owns, champions this program	Not viewed as a business sponsored project	Very poor, business takes lead from sponsors, ignores
Program Management	“Can’t get to where we want to go with current approach”	Put together rapidly/recently	Good though playing catch-up
SI Support	Shared disaster	None	Arms length, to the letter of contract, no more
Use of Methodology	Making it up	Largely following vendor roadmap	Unclear beyond original design
Change Management	Too little too late	Inconsistent across locations, organizations	Nonexistent
Training	Incomplete at-best	Too technical, no opportunity to practice	Always “next on the agenda” but not addressed
Technical Development	Good	Good	Fragmented, configuring by line of business
Master Data	Adequate	Fragmented, no MD Process	Fragmented, managing by line of business
Testing	Scary bad, willing to seriously compromise	Inadequate time, depth to approach	Good, vendor standard approach
Cutover/Go Live	Expect a ‘scary’ Go Live experience	Focusing on pilot, not on larger Go Live	Fragmented planning, poor timelines

Scary stuff: we note problems along virtually every dimension of program performance.  Of course these programs were all clearly at-risk, hence the need for our Assessment services.

I highlighted (colored cells) the core problems we observed within each ERP program.  These highlights provide an easy way to summarize why each ERP program was struggling.

• Program A:  Program A was far too “ad hoc”—one week on the ground suggested this organization was making it up as they went (with little to show for their imaginative efforts).  The crux of the problem lay in the relationship between the client and their systems integrator—or more accurately the complete lack of a relationship which meant no one was in charge, planning and leading the ERP effort.

• Program B:  Can you be “too nice” to implement ERP?  I think so; this company bordered on this condition.  No one really wanted to hold the reins and drive the program forward; the Program Management Office was overwhelmed and incapable of forming the center of gravity and effort required to really drive a program of this scope and complexity.

• Program C:  “Do as I say, not as I do” might characterize this floundering program.  The project team was sincere, but their business executives weren’t and the Systems Integrator divined that this might not be their next great reference account.  Interesting, it took a real executive intervention, with shouts and tears, to “break the fever” and get this program back on track.

I don’t think it’s appropriate to tell specifically what happened with each program.  Suffice to say that each company had some level of ERP success (in fact two of the three were ultimately wildly successful).

My point in sharing these cases is two-fold:

• There are myriad reasons programs struggle.  Once struggling the key is honestly assessing where you are, understanding why you are where you are, and taking appropriate action, however unpopular.  If you’re not willing to do this then you probably should pull the plug!

• It’s far better to stay out of these unhappy positions by regularly and honestly assessing program progress and risks.  But don’t depend on those closest to you for this assessment.  It’s human nature to want the stoplights to stay green even if they should be blinking red!