Back to TopBack to Top

ERP Success Factors vs. GRP Success Factors


July 6, 2012

Doug 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




The following two tabs change content below.
Doug Hadden

Doug Hadden

Executive Vice President, Innovation at FreeBalance
Doug is responsible for identifying new global markets, new technologies and trends, and new and enhanced internal processes. Doug leads a cross-functional international team that is responsible for developing product prototypes and innovative go-to-market strategies.

Leave a Reply