Do I need another Go Live Date?

If you're thinking of implementing SAP's product, be forewarned. Though it's hard to pinpoint a one-size-fits-all ballpark figure, your typical $5 billion company can easily spend in the $50 million range for the software, hardware, system integrator and internal team.

When your company is spending that kind of money, you'd better be sure you're delivering the ROI you promised.

To help save you from disaster, I am presenting the Top 10 implementation mistakes to avoid (in Letterman-style, starting with #10).

10. Believing the journey is complete at "Go Live"

Too many companies see their SAP implementation as a distinct project with a start and finish. "We say treat the day your ERP project goes live as the start of the next phase of your journey, not your finish."

A recent client who failed to plan for post-go-live and wound up having to pay for an extra six-months of on-site services from its consultants. "We'd normally expect three-to-four weeks of post-go-live support before self-sufficiency," says a end client. "It was as though they'd planned for the wedding as opposed to the marriage."

9. Failing to develop a business case

Don't start an SAP project just because you, the CIO/Owner/Corporate, think you need new software. It's just too expensive and complicated to risk going forward on that basis.

"The decision must be value-driven. There must be a specific business case,"

The risk of not having a business case is that you'll treat this as just another software implementation without redesigning your processes to maximize SAP's business-improvement potential.

"At the end of the day, if all you do is implement the same processes you had before, all you've done is paint cow-paths,"

"You have a newer system but you didn't attack the business problems that existed." Meanwhile, all the business benefits you promised the CEO never appear.

8. Failing to staff your implementation team with "A" players

King says he often sees SAP projects become a dumping grounds of people the client doesn't know what to do with.

But if you're going to redesign the processes for your company, you need the best and the brightest from all segments for the business. They're the last people anyone wants to give up, but they're the ones who will help you get the project delivered on time, on budget and with the optimized processes that most closely match the vision.

"It's amazing the fights you get into with clients to make them understand how important this is," he says.

Worse, warns by consultant, if you have a bad team, you'll never get to the endpoint. "A company can easily end up abandoning a project halfway through," he says.

7. Creating a solution that's incompatible with the company

For example, a consultant tells of a consumer distribution company who operated in a decentralized manner. It tried to become centralized via SAP and suffered a total failure in implementation. The technology was perfectly capable of centralizing the company, "but that's only half the problem," says one of the consultant .

"The other half is the company's culture, where senior staffers were used to making decisions for their own companies and areas of operation. They weren't willing to give up those responsibilities. The moral here is never to use technology as a vehicle to change your culture."

6. Using inexperienced consultants. Don't be looted.

"A lot of [consulting firms] will put in people through 'the academy,' where they take a training course and get sent straight out to the client. That won't work," says Kumar , who advises that your consultant team be a balance of new and old. "Make sure ahead of time that there are experienced people on the team, and get that in writing. Look at their CVs and such."

5. Insufficient training of users

Insufficient training of users is a mistake; can result in consultants having to stick around for months after go-live. Without sufficient user training, workers will do things their own way and it'll become impossible to manage the company's new processes. "This will create problems for every area of the business," one consultant company say's.

4. Failure to rein in "scope-creep"

A lot of companies will create a business case before they start, but then they'll start adding to the scope of the project simply because the software is capable of additional functions. But they never go back to the original business case and ask, "Does this addition support it?" The result can be "Death by 1,000 cuts," says Scherer. "Each change may be a tiny change, but collectively, these changes of scope will knock a product way off budget, out of time, or worse, prevent delivery of any of the original business benefits in the case."

3. Treating this as a technology project

An SAP implementation should be a balance of people, process and technology, says Hari Kumar . If you build a team that's 90 percent technology people without representatives from the business lines, "you'll end up with a fantastic technical implementation that does nothing to help your business become more competitive in today's environment." This sounds obvious, but as Hari Kumar points out, there are still plenty of companies that make this mistake.

2. Ignoring the advice of your systems integrator or Partner.

Hari Kumar says he worked with a company that was on its third SAP implementation and – as a result of its prior experiences – thought it knew everything. "Of course the big systems integrators have done thousands of these implementations around the globe and thus have a learning curve based on much more than two or three implementations," he says. In this case, the company suffered a five month delay, huge cost overruns and the loss of five months worth of business benefits.

1. Implementing in pieces

Many companies are tempted to get "quick business hits" by implementing SAP in stages – for example, starting with the financial piece, moving to the HR piece and then the sales and distribution piece, and so on. This will keep you from getting a good final integrated product. That's because once you're ready to implement the later stages, you're already handcuffed by the definitions you created in the earlier stages. Then you'll be forced to scrap chunks of early work and redesign those stages to work effectively with the newer ones. "We advise people to look for logical groupings of business processes and do those in one step," says Hari Kumar "Otherwise you may double your implementation timetable."