ERP failures can be crippling to any business. Professor of Engineering, James Robertson, reckons a different perspective is needed – one where eliminating failure, rather than focusing on success is needed.
Despite the massive failures and negative sentiment the ERP market has experienced over the past decade, this sector of the IT market continues to be a hot button with companies looking to improve the order in their business operations and a more streamlined set of business processes.
And it is not as if ERP is becoming any safer a bet.
In fact, Dr James Robertson, CEO of James A. Robertson & Associates, says that the harsh reality is that ERP projects’ failure to meet business expectations is at epidemic levels.
“But do not take my word for it,” he says. “A presentation delivered last year by Rossouw von Solms from the Centre for information security studies and the Nelson Mandela Metropolitan University cited numerous examples of ERP failure.”
Von Solms’ presentation was sobering – it reported that executives at FoxMeyer Drugs had contended that the failure of its ERP system helped drive the company into bankruptcy in 1996; and that after spending seven years and close to half a billion dollars implementing a mainframe ERP system, Dow Chemicals stopped and started over with a client-server version.
Furthermore, Robertson says, the presentation reported that Nike had to write off $400 million against its supply chain management system and Kmart, $195 million against its supply chain hardware and software.
But, Robertson says these failures have more to do with a lack of executive sponsorship, a lack of understanding of what the system is designed to deliver and lack of communication of realistic goals between the implementation partner and the customer.
The engineer’s perspective
“In many ways, the IT industry should be taking a leaf out of the traditional engineering market in terms of how projects are designed and implemented,” he says.
Robertson says there is a fundamental difference in how engineers approach projects and how IT companies approach projects.
“While they are designing and building very different things, there are certain values that should hold true. Like for example the fact that engineers do not design bridges to stand up – they design them to not fall down.
“It is the difference between designing a project to succeed or designing it not to fail,” he says.
Keeping an eye on failure factors
It is a subtle difference, but Robertson says it is an important one.
“The key is to look at the failure factors rather than the success factors.
“With a good view on what could make an ERP solution fail, rather than focusing on what would classify it as a success, I would venture that fewer ERP projects would result in catastrophic losses,” he concludes.
Designing IT solutions ‘not to fail’ rather than aiming for them to be successful might just be what the doctor ordered. While they might not deliver the same level of value as solutions that are a huge success, at least companies will not bleed to death when their IT systems do not deliver what was promised. In tough times like these, the market could do with a little more conservative an approach.