The Top 10 ERP Mistakes (Part 1)

June 23, 2003 by admin

Is the mountain-climbing analogy hyperbole? Perhaps, but it underscores the enormity of the obstacles that can impede ERP efforts to integrate internal business processes efficiently and, ultimately, lead to a disappointing — and costly — outcome. And, truthfully, while faulty technology often is blamed for the problems, it is frequently other shortcomings that create performance-related problems — such as the people employing the ERP application don’t fully understand what it is or how it works.
Certainly, obstacles exist, like those facing the bold mountain climbers, but the journey remains highly desirable because execution of a successful ERP project provides the backbone for a company’s internal and external operations — from integrating back-office financials with business performance data to building a launch platform for an extended enterprise and collaborative commerce. This foundation can serve as the competitive weapon of the future.
What can help is a road map, of sorts — a list of useful advice that can help foil the forces of failure that frustrate many ERP projects. Of course, a “cookbook” doesn’t exist that produces a perfect project every time. Still, ignoring the advice of veterans almost certainly will trigger failure. So, what follows is a list of the Top 10 mistakes to avoid in implementing ERP software — perhaps, in a way, similar to a list an experienced sherpa might develop for that fearless mountain climber.

10. Believing the journey is complete at “go live”

It is important to treat the day the ERP project goes live as the start of the next phase of the journey, not the finish because an ERP implementation represents much more than simply a project. Typically, the upfront investment is large, but the life expectancy of the application should lie somewhere between 10 years and 20 years. Customers then have already established their team and given it 15 to 30 months to bring the project to its launch date. So why should the team then be disbanded a month after the project goes live?
It’s like starting up a major chemical plant that took three years and millions of dollars to build only to dismiss the engineers the day after it starts up. Naturally, those engineers would nurture that plant for years to come. By retaining a subset of its installation team, its members can enhance the ERP application, handle bottlenecks, tweak and improve the system, look for continual productivity gains — and learn. This subset should be made up of both business and technical personnel.

9. Not planning for — and minimizing — the interim performance dip after start up

By and large, most ERP projects change a significant chunk of a company’s backbone. It’s not unusual that a project replaces the systems that have been used for half of a company’s back-office transactions — and it may affect as much as 90 percent of them. And it’s not that this is just a major technical shift. It usually represents a major change in business processes, culture, learning, and the environment.
That’s why a dip in performance invariably follows an ERP project going live. Research shows that even the projects that have gone the smoothest in the execution stage suffer a dip in performance after the new system launches. Transactional efficiency, for instance, might dip to 90 percent from 98 percent. The pace of taking sales orders may slow down. Or the speed of pushing products into the warehouse may decline a bit.
Everyone must, of course, try to minimize this through strong careful planning, testing, education, and risk analysis, among other things. Still one has to recognize that performance is going to suffer some at the outset, but with excellent execution, this effect can be very slim and very short.

8. Failing to balance the needs and power of integration with seeking quick business hits

Today, every chief executive officer must deliver results now, not in 15 months from now. Given the challenges of a full ERP implementation, it’s difficult for them to promise their board of directors that with the ERP project, they are going to see savings in 24 to 36 months of such-and-such amount. They want to see the return on investment now.
The challenge involves scoping and sequencing the ERP implementation to maximize the rapid business payback but without jeopardizing the overall power that ERP integration promises. Many ways exist to accomplish this and a good integration partner can offer advice on them.

7. Starting too late to address all things data (architecture, standards, management, cleansing, and so on)

An ERP investment will be substantial, but one has to remember: These systems are only as good as the fundamental data that enters them. And that’s where a common problem erupts. Far too often, research indicates, companies think about the quality and accuracy of their data too late in the project. But: The consistency and accuracy of the data is critical.
Therefore it is inevitable to start thinking about the data on the day the project begins, not two months before the application goes live. It takes time to determine the new data standards the company will employ, as well as to cleanse and transfer all the existing data. This ensures that valuable information about customers, vendors or accounts is consistent with how the enterprise wants to run its business going forward.
For example, it’s not unusual for a company’s vendors to have more knowledge about the company’s purchasing patterns than it has about itself. Suppose that a company is buying products and services from a major chemical manufacturer that supplies its needs in 32 countries. If this manufacturer is well run, it probably knows more about the buying company and what it is buying than the company itself knows about such purchases. But an ERP implementation can give this company the technical power to change this and get the upper hand so that it can push for a further 10 percent discount on price. This works, though, only if the company’s data is consistent and up-to-date and if it has instant access to it to make that case for a price break.

6. Failing to staff the team with “A” players from business and technical sides of the organization, including program management

This can be a major challenge. A company needs top-notch players for these projects — not just technical stars but stellar performers from the business side as well. Indeed, if the company has to trade off in terms of quality in one area, it should never skimp on business talent. It can perhaps trade off on technical expertise because the consultant it retains retain can bring in skilled technicians.
And the “A” players should encompass program managers to the most junior members of the team. Important is not to enlist Joe and Joan Doe simply because they don’t have anything else to do at the moment. This part can be difficult because the best staff members undoubtedly are busy with other assignments and because some of the larger ERP projects can involve 200 to 300 people. But freeing some of the very best players for this project team is crucial.
It is easy to justify the use of this top talent. The company is investing in their careers and in its own future success. By the time the project goes live, the best talent is immersed in the new strategy and the new operating system for the company. The result is a tremendous inventory of exceptional talent — and the company will realize firsthand that the best projects succeed when the team members are its stars.

For further information on ERP see the print edition of SAP INFO.

Clive Weightman

Tags:

Leave a Reply