The Top 10 ERP Mistakes (Part 2)

Feature Article | July 7, 2003 by admin

5. Starting without an effective and dedicated senior governance council, including a single executive sponsor

Any major ERP project overhauls a lot of business processes, roles, responsibilities, standards, and data definitions — and these are changes that cannot be pursued from the bottom up. An effective governing council — a steering group — is essential, as is a single executive sponsor, dedicated and effective, to chair it. The project will trigger difficult, sometimes nasty, issues and a senior executive who is accountable can make those decisions and see that the steering group understands and accepts them.
A steering council can meet just once a month for an hour or so to give encouragement to the project manager, or it can take the time to be an actively involved group that understands and guides the project, making key decisions and shaping the future of the company. A vast difference exists between the two.
On the business side, the senior executive often is the chief financial officer. It also can be the chief executive officer, especially if the project is a major business transformation critical to the company’s future success.
If the thrust of the ERP project affects sales and distribution, the senior executive could be the senior vice president for sales and marketing. The project’s executive “angel” must be from the corporate suite and, preferably, not the chief information officer. Unless the CIO happens to be an exceptional business manager and have the ear of his chief business counterparts, the other executives will not get involved and the project will often turn into the CIO’s and his technical staff’s mission.

4. Selecting a strong systems integrator and then not heeding its advice

It’s always surprising to learn that a company has spent considerable time and money to select a strong systems integrator and then does battle with the SI every step of the way. Why spend mega-bucks for this consulting partner’s expertise if the company then always questions the SI or thinks its recommendations reflect a desire simply to generate more revenue? An SI should serve as the company’s eyes and ears because while it may be its first or second time with a major ERP project, the SI has probably worked on similar assignments dozens or hundreds of times. So why second guess the SI?
Respect and mutual partnership is essential for the project to succeed — and that includes respect from each partner and often the software vendor. By the same token, an SI can’t assume a client is ill equipped to offer strong advice. In selecting an SI, a company should:

  • Consider compatibility. Some SI firms favor a “let’s solve this together” approach, while others prefer the “here are your marching orders, this is how it’s going to be, so let’s get down to business.” The company has to determine which approach it favors for the firm’s culture.
  • Clearly look at the SI’s track record. It is necessary to look beyond its marketing, to talk to the software vendors the company will be working with and also talk with industry analysts.
  • Spend considerable time examining the members of the actual team that will be working in the project every day. The company has to be sure to put language in the contract that at least binds the team leaders and the firm’s partner with it for the duration of the project.

3. Trying to create a solution incompatible with the company’s culture

In the 1990s, research found that many companies with ERP projects saw them as a silver bullet that would solve all their problems — even if the “style” of solution wasn’t compatible with their corporate culture traditions. An executive might say he or she wants to operate in a globally centralized fashion — to be more like a Wal-Mart, with the strength and discipline of a global head office. However, this doesn’t work if the firm’s culture is one of decentralized entrepreneurship. It then can’t use technology to force change in the culture of the company. So if it has a very decentralized structure, it would better opt to install a decentralized ERP application or recognize the enormous change-management mountain it faces.
For example, let’s say the company is consolidating 93 warehouses into five or six warehouses and the ERP application is “expected” to make that happen. Technically, ERP can make that happen. But this isn’t just a technical process but a business/people process. If the company doesn’t have someone who can change attitudes so that the organization understands and supports the consolidation, then the project will fail.
Now, if a CEO has a mandate to make an overhaul of a company and its culture, this can be a workable situation. But, again, the CEO isn’t looking at the ERP solution as simply a technical solution; rather, as a business and organizational one as well. The CEO must look at the first- and second-level managers to choose those who can work under this new regime and make the program successful.

2. Treating this as a technical project vs. a change that balances people, process, and technology; not using the power of the new, integrated information

The ERP technology must work, but one has to appreciate that 30 percent of the challenge of an ERP project usually is attributable to technology and the remaining 70 percent involves people and processes. Only few people really like change and if an organization is moving to SAP, for example, things are going to change. At the minimum, an employee’s computer screen is going to change; at the maximum, the employee’s entire life is going to change.
The new technology brings integration and, generally, makes information available instantly. For example, when raw material arrives at a company’s receiving dock and is scanned into the system, anyone can access that information and use it. When a product becomes a finished good and either automatically or manually is entered into the system, it becomes available immediately for sale; an employee needn’t wait overnight for such information to be available.
Real-time integration and accurate data change people’s jobs. A traditional sales order taker can change into a full-service customer agent. For example, with full online access to an integrated ERP backbone, the agent enjoys immediate access to the customer’s history and other vital identifiers. The agent can examine real-time open inventory at all warehouses (not just local) and future production schedules. The agent can freeze and commit from this schedule to the customer’s immediate needs, among other things. Again, the new ERP technology affects many people, their training, and the processes they use.

1. Embarking on the journey without a solid, approved business case, including mechanisms to update the business case continuously and to ensure the savings are baked into operational budgets

Stamina: Since an ERP project, no doubt, is going to take a minimum of 12 months and as much as 36 months to employ, and often costs between $5 million and $50 million out-of pocket costs, stamina is essential. So the company must be absolutely certain why it is embarking on this journey; that is, having a solid business case. At the same time, if a solid business case hasn’t been made for the project, the company won’t get the commitment from the entire business team to make the journey successful. Many times when a company pursues an ERP implementation, it isn’t simply to cut technology costs, because total technical costs may well increase with the application. Most of the time, the project is undertaken for broader business reasons, so if those reasons aren’t clearly expressed, fully understood, and approved in both qualitative and quantitative terms, members of the senior executive team won’t give their full support.
While this is far less of an issue than it was five years ago, a number of major companies still complete the business case for an ERP project, submit a capital appropriation request, eventually get it approved, only to park the business case on the shelf to gather dust while the project proceeds. A business case should be a living, breathing document of how to drive out both the original and updated business benefits from the ERP journey for, say, the next 20 years. It must outline how to track the benefits the application will produce, and it must be used for the CEO to bake into the annual operating budgets the cost-reductions and revenue increases that each vice president has committed to. It must make senior and middle executives accountable for the goals so that the anticipated bottom-line benefits are realized. This type of discipline still is relatively rare, in part because many managers think, “Hey, I’m not going to be here to see the end of this.”
But, for an ERP project to succeed, it is critical that this business case is documented and becomes well worn. Just how vital is it? It does head this list of mistakes to avoid!

Not by technology alone

The company’s persons in charge of the project always have to keep in mind that technology alone cannot help to reach the business goals. For inspiration these persons should think of that momentous day in 1953 when Edmund Hillary of New Zealand and Tenzing Norgay of Nepal became the first human beings to reach the pinnacle of Mount Everest, the highest place on earth. It wasn’t fancy technology that got them there; their equipment was relatively primitive. They succeeded because they avoided the costly mistakes that had tripped up so many before them.
Implementing a successful ERP project may not be as hard as scaling Mount Everest, but the consequences of failure might be dire to a company’s business. Avoiding these 10 costly ERP mistakes will protect an ERP project along its way.

Clive Weightman

Tags: ,

Leave a Reply