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)
- GovTech & GRP News Digest - September 20, 2017
- Smart Cities and Open Government News Digest - September 20, 2017
- Public Financial Management & Country Development News Digest - September 20, 2017
- Yet more Corruption Studies? - September 19, 2017