Over on Inc., Les writes about how not to roll out a new system or process:

“Last week it was reported that Avon … had abandoned a $125 million SAP system. The reason? Their salespeople (mostly independent reps) where leaving in droves because the new system was so burdensome.

This is far from the only case of major systems and process investments coming a cropper, as the Wall Street Journal points out, Lumber Liquidators had a similar problem in 2010, as did Ingram Micro in 2011.

So does this mean that installing large-scale systems and processes, whether from SAP, IBM, Oracle or any other provider, is a bad thing, a waste of everyone’s time?

Of course not. While we’ve all seen examples of ill-considered systems and processes foisted on an organization that really didn’t need it, in most cases, it’s not the system itself that’s the issue–it’s how the system is designed and implemented ….

In the most recent case, neither Avon nor SAP expressed any concern that the software was deficient. In fact, the Avon CEO specifically made the point that the software was working as designed–the Avon reps simply voted with their feet. The system was working fine, but they didn’t like it–so they left.

And although Avon was particularly vulnerable to the reaction of the system’s end users–many of their salespeople being independent reps and therefore more likely to switch horses to a competing organization–both Lumber Liquidators and Ingram Micro (and thousands of smaller businesses just like them) found that even when the system’s end users are full-time employees (and therefore less likely to jump ship if they’re unhappy with a new system), productivity, and therefore profits, can take a massive hit.

Surprisingly, the answer to ‘the new system blues’ is quite simple: involve the eventual end users throughout the whole process.“

A couple of comments:

1. Later in the article, Les makes some good observations about the difference between “processors” and “operators.” It’s a useful distinction.

2. I disagree that the answer is simple, and I disagree with Les’s prescription. “Involving the eventual end users throughout the whole process” is not a simple answer in practice, nor is it sufficient. In my work, I call what Les is talking about the “business engagement” stage, and yes, there should be some business users – a “representative” group – involved in the envisioning, design, governance, and roll-out of the system. But it isn’t simple.

3. There is something else that is missing from the “simple” answer, and that’s an intentional focus on user adoption. Business engagement – which Les talks about – is a precursor to the system being made available, but once it has gone live, project teams need to take an intentional approach to adoption. I outline a variety of strategies in my book, User Adoption Strategies 2nd Ed. (2012), albeit with a focus on collaboration systems, but many would be equally applicable to SAP and other ERP systems.

4. Not all SAP implementations end in failure. I was speaking just last week with a colleague here in New Zealand whose organization had recently rolled out SAP enterprise-wide. The outcome: “it brought our organization together.” That’s a pretty great testimonial.

5. Has your organization taken a great approach to business engagement and/or adoption with SAP or another ERP system? I’d love to hear your story (below via a comment, or through a private briefing). Please get in contact if you have a story to tell.