Contrary to the beliefs of many, an ERP implementation is far more than a large IT project. It affects stakeholders in every functional area, and if it fails, it has dramatic consequences throughout an organization. With that said, an ERP failure is not unlike a car crash. Both are disasters that leave trauma and retrospection in their wake.
Despite this, there are notable differences between a car crash and an ERP failure that provide important lessons on mitigating risk in your ERP implementation. Heed these lessons and you will avoid the mistakes that lead to ERP crashes.
1. A car crash happens suddenly. In most cases, car accidents occur in an instant and have little or no warning. Not so with an ERP failure. In virtually all cases, ERP failures are preceded by numerous red flags over the course of months or even years. Warnings such as a lack of executive or employee buy-in, inadequate change management and unrealistic deadlines are often present leading up to an ERP failure. Identifying and addressing these warning signs are integral parts of a successful ERP implementation.
Register for our webinar, ERP Implementation Success: Five Tips for Getting More Out of Your ERP System.
2. In most car crashes, one or two individuals are culpable. In an ERP implementation, there are many parties involved that all bear part of the responsibility for project success. Examples of parties with responsibility in an ERP implementation include ERP vendors, system integrators, third party consultancies, and of course, teams from the organization itself. While the ultimate responsibility for ERP failure may lie more with one of these stakeholders than others, being vigilant of risk arising from one party is a duty shared by many. ERP failure is often attributable to failures in communication between many individuals. To avoid this, always ensure that roles and responsibilities among project stakeholders are defined and clear, and channels of communication are established and open.
3. Car crashes are sometimes the result of mechanical or system failure. A faulty computer in a vehicle may lead to a crash (or a recall), but this is rarely the case in ERP failures. In virtually all failed ERP projects, the technology is not to blame. Mismanagement of ERP implementations is a far more likely culprit than a problem with the system itself.
4. In most car crashes, emergency response is imminent. In many car crashes, help is on the way to preserve life and limb as well as to clear the street to allow the regular flow of traffic. No such guarantees exist in ERP failures. Coordination of recovery from an ERP failure is rarely as efficient as emergency response to a car crash, as there is no precedent for these situations within a given organization. This fact makes early identification of project risk all the more critical.
5. If another driver is at fault, they foot the bill. Assuming the driver at fault has insurance, the financial consequences for a car crash are generally born by the culpable party. This is not a sure bet in an ERP implementation. Even if the third parties involved are contractually liable for certain points of failure, significant financial damage is always suffered by the organization itself. When ERP failures do lead to litigation from organizations seeking recompense from partners who failed to deliver, damages awarded often do not approach the true financial cost of ERP failure.
While a failed ERP implementation may have a lot in common with a car crash, ERP failure is much more preventable. If you take away one lesson it should be this: prevention is always less costly than recovery.