How Not to Roll Out a New System or Process 

A version of this article appeared at Inc.com
Last week it was reported that Avon (you know, the ding-dong people) 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.
In most cases, complex new systems are conceived internally by Processors (not surprisingly), who then partner with system suppliers like SAP, who employ mostly, wait for it, more Processors. And, because Processors love systems and processes, the end result emerges late, bloated, over-specified, over-rich in options and features and stuffed full of redundancies. It is also almost always light on real-world nous.
The end result is then tossed over the transom to the eventual end-user (along, of course, with weeks of tortuous training and orientation). The end-users are most often Operators – pragmatic, real-world individuals for whom a system or process is simply a tool (the simpler the better) to assist them in getting their job done.
Result? From day one the Operators feel overburdened with a bunch of stuff they know isn’t necessary to do their job well, and a standoff begins, with the Processors back at corporate forced to justify the massive expenditure on something the people on the front line won’t (or can’t) support.
The answer? Don’t let your Processors do this stuff alone. If you have a big new process or system coming down the pipeline, grab your best Operators and make sure they’re involved from day one. Your bottom line will thank you.