March 5, 2012Doug Hadden
Enterprise Irregular Dennis Howlett wonders whether “intransigent clients” are to blame for failed projects of a major ERP vendor. Howlett critiques the views of Michael Doane on the so-called “false promise” of accelerated “go live” implementations from this ERP vendor and Michael Krigsman on an improved method or accelerating implementations from this ERP vendor. Vijay Vijasankar has added some more analysis. There seems to be an undercurrent among the cognoscenti that customers are to blame for poor ERP implementations.
There is also a school of thought that suggests that ERP failures are few – that there are enough good practices in ERP implementation. Notwithstanding the meme of ERP failures permeating the net. Especially in the public sector. It’s an open secret.
Maybe it’s the software
FreeBalance staff members encounter many ERP users in government. The feedback may be somewhat anecdotal – let’s say, it’s not pretty. We sometimes compete against ERP vendors. FreeBalance is a Government Resource Planning specialist – we don’t do private sector enterprise software. Rarely are the limitations of the ERP package presented as a cause or partial cause of failure.
- Michael Doane identifies the weakness of methodologies that attempt to accelerate implementation – “speed kills”.
- Michael Krigsman is optimistic about rapid implementation tools. His view is that there is a “devil’s triangle” of schizophrenic software vendors, wacky systems integrators and confused buyers that lead to ERP failure.
- Dennis Howlett describes the phenomena of customers buying into the brand and the influences of eager salespeople. He asks some very interesting questions on why these implementations are a “very hard road”.
- Vijay Vijasankar suggests that systems integrators operate differently – (less wacky?) He suggests that customers have no excuse for not having enough information prior to contracting for ERP.
The general consensus: failure is caused by numerous factors. However, only Howlett seems to suggest that the underlying software has a causal effect. I’m suspicious of those who think it’s all a question of Project Management 101. My view is that ERP software with some “devil’s triangle” incentives plays a significant role in failure:
- Software is designed for a purpose in mind: implement the software in domains (vertical market, location, organization size etc.) is fraught with danger. Business analysis required is proportional to the delta between the intended design and customer need. In-depth analyses on processes are needed.
- ERP software intended for multiple domains must rely on code customization. There is no way for ERP vendors to have fully parameterized software for a particular market. (As FreeBalance does with government.) This introduces complexity, placing more burden on customers and integrators. I agree with Doane: there is no such thing as a “vanilla” ERP implementation, especially if the organization has developed differentiated practices.
- Customization generates revenue for system integrators. Systems integrators are the primary channel for ERP vendors. This element of the ‘devil’s triangle’ provides little incentive for the ERP vendor to bake customization out of product. There is a bit of a “quickstart” arms race among the major ERP vendors – but it’s in dribs and drabs.
Customers are rarely to blame
I agree with Vijay Vijasankar that customers have access to information about ERP successes and failures. Have you tried making heads or tails of the information? There is so much noise about “best practices” and “magic quadrants” that customers are faced with information overload. And, ERP companies are eager to continue the assault on our senses.
Let me make it clear: I’m in this general market. I’ve been around for a while. It taxes me to understand what the heck ERP companies are on about. And then there are the technology analysts. Yes, I live in the TLA (Three Letter Acronym) “eco-system” tech-speak. Yet, if it wasn’t for the independent analyst groups like Constellation Research, I think I’d be in a state of confusion.
Reduce the scope of the problem
We’ve come up with some ways to significantly mitigate the risk of failure:
- Designed with the purpose in mind. In our case, government.
- Parameterized design. Eliminate code customization. (And, commit to putting missing features into the mainline of the code ASAP to reduce long-term upgrade costs.)
- Consultants are government first, FreeBalance second. Experts in a particular ERP package are often useless when outside their core business domain. Our consultants have government experience first. This reduces the needs analysis part of the project and provides customers with good practice advice.
- Software manufacturer committed in the project. Unlike almost all ERP projects, FreeBalance participates in customer implementations. We have no ability to blame the victim and hence are accountable.
Latest posts by Doug Hadden (see all)
- The (IT) Project was a Success, but the Patient Died [Part 2] - September 21, 2016
- The (IT) Project was a Success, but the Patient Died [Part 1] - September 20, 2016
- Have we over-complicated the ‘smart’ in smart government? - September 8, 2016
- Why PFM reform is integral to smart government - September 8, 2016