As an example, Wagner points to an implementation at a large company in which adding new employees to the payroll required stepping through 25 screens, rather than consolidating all of the forms into one screen, with a several minute database access time between each. This ended up being hours of work for a commonplace task that is crucial to the company.

This leads naturally to a few questions. Wasn’t the product tested internally? Why weren’t these oversights caught earlier? The answer is multifaceted, but there are two prevailing problems. Management tends to think that end-users will simply adapt to the new system, and thus doesn’t always put enough emphasis on testing. As a result, beta-testing, an already imperfect process, allows even more bugs to slip through the cracks. Of course, this leads to tension with management, who feel that the testers should have found such errors.

The other major problem is simply having unrealistic expectations about standardized software. Every company is different, so naturally any software package is going to need some adjustment. Software vendors don’t like this.

“The vendor will say, ‘Our software is perfect, you shouldn’t have to make modifications to it. If you have to make modifications to it it’s a weakness in your company, you should change the way your company operates.’ What we’re finding in practice is that people are saying, ‘You have a great product that provides us with an integrated environment, but we’re going to need to make some customizations to this software.’”

Technology should not drive the company. Quite the reverse! Modification of such packages needs to be accepted practice, not a “dirty little secret.” Furthermore, this modification may need to be made after the software goes live: “You can ask people what do you want and what do you need, and on an abstract level they can tell you, but when it’s right in front of them and they have to do work with this system in order to get their job done, then they start to see the problems, then they have the feedback for you.”

Ultimately, employees aren’t able to discover all the holes in an ERP package until they’re truly engaged with it, and then modifications will need to be made.

“I think that the six months to a year after go-live should be another phase of the life-cycle, a post implementation phase… that involves a lot of negotiation and potentially changes, and that’s a normal part of what happens when we buy software.”

As more ERP vendors realize and anticipate this, the software will become more flexible and better able to suit the needs of the clients. In turn, the clients will loosen their definition of success a little bit, and expect an adjustment period. A beautiful compromise. Almost brings a tear to my eye.

Who knows? If there’s hope for stodgy old corporate America, maybe you can convince your mom to stop asking you to have kids.