Is Big ERP Officially Obsolete for Government Shared Services? class=

Is Big ERP Officially Obsolete for Government Shared Services?

Doug Hadden, VP Products

Gartner has put the final nail in the coffin of big Enterprise Resource Planning (ERP) software value. When Gartner says that “heavily customized” major ERP software is now “legacy” – it’s rust. What does this mean for government-wide ERP shared services? Bad idea. Poor value for money. Gartner calls it an “anchor.” (It reminds me of review of an Eastern European automobile back in the 80s: “it accelerates like it was chained to the garage.”

Gartner claims that the enterprise software industry has hit a “post modern” phase. Let’s “deconstruct” what Gartner is saying. And, the implication for government shared services.

Heavy Customization

Heavy ERP customization = lack of flexiblity to change and adapt to legal reform and improved fiscal processes. The notion that ERP shared services provides agility is a myth. ERP standardization can reduce administration costs at the expense of flexbility. Government Resource Planning (GRP) software, on the other hand, doesn’t require heavy customization – its all about configuration.

And, don’t be fooled about the notion of “vanilla” implementations in government. It’s somewhat shocking how unalike departmental systems from the same manufacturer using the same version are in governments. The cost to maintain the customizations, add new customizations to reflect changing regulations and to manage these customizations during a version upgrade are horrendous.

One observer in the Government of Canada suggested that all of the FreeBalance implementations were uniquely customized. Only 1 of 28. The software was configured differently and there were some custom reports and interfaces but no customized code in core financials. 

Tightly to Loosely Coupled

Major ERP vendors sell the notion of “integrated solutions.” This makes sense because you would think that software modules from the same vendor would integrate “seamlessly.” That’s a claim that has been widely believed. Yet, ERP customers find that they need “metadata management” tools for integration. Because, apparently, the data definitions in one module are not unified to definitions in others.

When asked about “metadata management” in the FreeBalance Accountability Suite, I point to the configurations screens. We didn’t need to find a solution or “workaround” for poor software design. (Some Tier 2 ERP vendors have unified metadata).

Gartner is predicting that solutions will be loosely coupled among on-site and cloud applications. This thin method of integration enables flexibility among software choices. It’s also useful for custom applications when government regulations are too unique for commercial applications. It turns out that standards support for integration removes an administrative burden. (Some ERP and cloud vendors are supporting integration standards and loosely coupled interfaces.)

Myth of the Single Encompassing ERP for Government

Gartner points out that major enterprise software vendors have made so many acquisitions that it is impossible to achieve seamless integration. ERP vendors once sold this notion in order to sell more stuff to the same customer. (A friend of mine calls it LUFO or “load up and —well, you’ll need to fill in the blanks.)

The major ERP vendors have acquired so many horizontal and vertical applications. So much middleware. With many business partners who add additional functionality. Yet, they can’t fully satisfy customer needs in a broad range of industries without expensive customization.

There has been much misdirection by the marketing departments of these large vendors. There has been a lot of creative work to redefine “innovation” as additional features. Or, “cloud” as what they already have.

I have encountered this view that ERP is “tried and true”. It’s been tried and it is truly complicated and expensive. With high failure rates and cost overurns, particularly in government.

Myth of the Enterprise

I’ve heard many speeches for IT and financial professionals in governments talking about the notion of treating government as an enterprise. It tends to have a lot of resonance with politician. (I think it fits the narrative of governments as inefficient and in need of a strong political hand.)

The notion that a class of software has the word “enterprise” in it doesn’t mean that a class of software with the word “government” isn’t enterprise scale. Frankly, if the category had been originally called BRP, the big vendors would be talking about how governments need to be run like businesses.

The aspiration of governments wanting to operate like businesses is misguided. Business runs to make profit. Governments run to achieve societal outcomes where the key financial concept is budgets. ERP software has hamstrung governments trying to manage to budgets. There are countries that have ERP for financial management but don’t use it for budget management. There are countries that have automated budget management, thanks to ERP, that is antiquated. And, the number of times I’ve heard about ERP applications inadvertedly exceeding the budget is depressing. (One former finance officer told me what it was like to go to parliament to admit that they’d spent over the vote. It was not pleasant.)

What should Governments do?

  1. Examine the portfolio of needs not by shoehorning it into a vendor product – use the business component mapping process to determine where value can be optimized, what should be vanilla, what could be acquired via the cloud, what could be customized and what should be custom built
  2. Use open standard and open source for custom development or use a government software platform
  3. Develop new standards for integration that recognize industry standards like web services and provide loosely-coupled interfaces
  4. Develop a migration plan to get off any application that requires customization in a proprietary language – move to Java, Ruby, Python, C++, even C#
  5. Develop a migration plan to move to pure web applications – not the current generation of ERP applications that web-enable old client/server code
  6. Look at the current investment and the real cost rather than the potential cost of buying or renting something new and compare the 5 or 10 year Total Cost of Ownership. A $1M investment in new technology could save $500,000 in annual costs for just keeping the lights on for the current ERP
  7. Be more demanding of vendors – it’s public money. Don’t accept second-rate efforts. Don’t accept the notion that the software manufacturer shouldn’t be in the governance structure. Any manufacturer not prepared to work with you has no commitment.