July 6, 2012
Doug HaddenDoug Hadden, VP Products
Let’s face it, Enterprise Resource Planning (ERP) implementations are risky. Lots of reported failures. Lawsuits.
And, that’s in the private sector: the “enterprise” space.
For consultants, there’s nothing better than endemic failure. It’s a business opportunity.
For ERP vendors, there’s nothing better than a business model that enables blaming the victim (customer) for failure.
Is there a difference between ERP and Government Resource Planning (GRP) implementation success factors?
ERP Success Factor Responsibility
This chart is a consensus summary of ERP responsibilities for success. Where ++ represents key responsibility and + is supporting responsibility.
It’s a sorry state when customers are made responsible for so many critical success factors. Customers are expected to plan, select vendors, manage the project, articulate business requirements, get certified and test. Integrators have technical responsibilities. ERP software manufacturers; well – they have customer support.
It’s a sorry state
That’s right, if you’re not expert in ERP systems and IT program management, it’s your fault.
After you’re sold a bill of goods.
Manufacturers can blame integrators. Integrators can blame customers. For insufficient “management commitment” or “trained, certified and dedicated” personnel.
It’s a no-lose situation. For the manufacturer.
GRP Success Factor Responsibility
FreeBalance provides GRP software – designed for government only. FreeBalance is almost always involved in implementation, so we’re both integrator and manufacturer.
That eliminates some finger pointing.
My view is that the ERP responsibility table is all wrong. It should be more like the above.
- Software manufacturers should have products designed for the customer domain and should help in planning
- Manufacturers should be part of the governance structure – they should commit to feature changes
- Integrators should be experts in their field. After all, they know “best practices” and should be telling you what you should do
- Manufacturers should be finding ways of minimizing code customization – by putting your needs into the main line of the code
- Customers should not need to have teams taking months of training to use and administrate software
- Integrators should lead testing
Doug Hadden
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