|
Our topic is the prevention of failure. Projects to implement ERP tend to be difficult, expensive and drawn-out. They are often full of painful surprises and overrun budgets and schedules that were extravagant in the first place. They fail entirely in an alarming number of cases. Why this should be so is not immediately apparent. If we list, at a fairly high level, the tasks required to implement an ERP system in a company that’s already familiar with ERP practices, what we see is a significant but not daunting amount of work. To be sure, some unknowns are usually involved. Nonetheless, companies that struggle to implement or re-implement ERP perform what would appear to be more complex tasks quite successfully in the course of creating and delivering their own products. One wonders why a little of the will and expertise that makes them successful in more challenging areas can’t be adapted to implementing ERP: a task that needn't be especially innovative and which, on the whole, appears to be quite well understood. One wonders why ERP packages that perform magnificently at some companies can't get off the ground at their closest competitors. One wonders how implementation consultants can go from heroes on one project to beaten, humiliated failures on the next. One wonders, finally, how the practice of ERP implementation, a business process that's well into its third decade, can be so haphazard, unpredictable and dangerous.
This white paper is a partial, high-level survey of the topic of ERP implementation failure and how it can be controlled. We discuss common patterns of failures, their symptoms and causes, and the circumstances in which they’re likely to occur. We identify alternative circumstances in which failure has been largely avoided. Finally, we discuss business strategies for bringing about the conditions of success and inhibiting the conditions of failure. We argue that bringing the conditions of success together is a business problem, to be achieved, not through technical approaches, but through consciously designed and consciously implemented business strategies – strategies that are explicitly shared by all players in the implementation process.
What we have come to call the new ERP business model views the problems we’ll address as failures of project management, not of software or even of consulting expertise. These failures of project management are the result of many individual failures of project planning, failures that make effective project management impossible. In turn, these failures of planning are, we believe, brought about by flawed business practices on the part of every kind of player in the implementation process: end users, ERP vendors and consultants. The net effect of these business failures is that the user company loses control of its implementation project. It is not that anyone else gains or seizes control; it is that control evaporates.
There are a great many aspects to this but usually there is a common denominator: the two wholly false ideas that implementation starts after system acquisition and that implementation is mostly about software. When accepted, these ideas lead to the disastrous notion that an ERP implementation is a technical service performed by technical experts: an attitude that is very likely to lead to loss of control by business management. The new ERP business model views a company as the work it does. It views the implementation plan not as a technical exercise but as an analog of the company's business operations, and it views the implementation process as beginning well before system acquisition. The common project theme is subordinating everything, especially all technical considerations, to the work that defines the company. The first step is defining that work in terms that can be applied directly to the software acquisition process. The remaining steps consist mainly in never losing sight of the work that the ERP system is being acquired to manage.
An important disclaimer. We have invented nothing here. We call the bundle of strategies we describe “the new ERP business model” because, first, it’s something we see catching on in parts of the ERP marketplace and, second, because it’s something we wish to frankly encourage. But our discussions of project failure don’t break any new ground and we advocate nothing here that has not been used successfully many times over.
|
