Eric Kimberling, CEO of Panorama Consulting has had experience as an expert witness in some fairly high profile court cases. In a recent white paper he pointed out three general observations he’s taken away from the experience – general in the sense that court cases operate under a certain degree of confidentiality that somewhat limits discussion of the results. Still, he shares a few common threads from among those cases, which we pass along in today’s post.
- Most ERP failures could have been avoided. He points out that there is no sinister, evil force in effect here. Rather, he notes, “implementing organizations and their ERP consultants more often contribute to failure through a series of poor decisions, unrealistic expectations and too much focus on the wrong activities. For example, instead of focusing on critical organizational change management and business process reengineering activities, failing parties myopically focus on the technical aspects of the implementation.”
Our own experience does not contradict this, as too often we find clients focused more on the technical details, than on the Big Picture, starting with a thorough workflow and business process analysis that first and foremost focuses on the company’s strategic objectives.
- ERP failures occur regardless of the ERP software being implemented. Kimberling notes that while horror tales from Oracle and SAP may dominate the media, that’s generally because the clients are of the higher profile, Fortune 500 type. But in fact, his team has found no “meaningful correlation between software implemented and failure rate.” In other words, it’s not the software that matters. It’s more important to look at the method by which your software is being implemented.
- And finally… Most failures can be traced back to unrealistic expectations. Kimberling notes that he “identified unrealistic expectations early in the project as a root cause of many problems later on.” Beginning a project with unrealistic expectations and too low of a budget and timeframe leads to a series of bad decisions and cut corners. And those decisions, he finds, are what lead to failure. Skimping on training, testing and process analysis, to name a few, is more likely to make or break an implementation, he notes. Question assumptions, he adds, and add a good dose of reality before staking your project’s outcome, and perhaps your career, upon it.