Back to TopBack to Top

Vanilla ERP for Government?


May 12, 2014

It’s high time for governments to abandon heavily customized Enterprise Resource Planning (ERP) systems. To migrate to zero-software code configuration. That’s something we’ve been saying for some time. Curiously, the Tier 1 ERP vendors are agreeing with us. Some government organizations are on the path to implement “vanilla” ERP configurations. Is this a good thing?

Vanilla vs. Customization Trade-off, ERP and GRP

In commercial systems such as ERPs, there appears to be a trade-off between achieving the benefits of standardization and accommodating the uniqueness of the organisation and this is sometimes referred to as the common system paradox.” This trade-of is considerable when the commercial system was designed for different domains such as manufacturing. What this means is that almost all ERP implementations in government are customized.

FreeBalance is a provider of Government Resource Planning (GRP) systems. This narrows the vanilla vs. customization trade-of significantly. GRP is “enterprise class” but government-exclusive. ERP systems were designed primarily for the private sector and extended to other industries or “vertical markets” like government. What we mean by “configuration” and what ERP vendors mean are quite different.

Vanilla ERP in government is about as likely to occur as spotting unicorns in a data center. There is no such thing as vanilla ERP in government.

FreeBalance provides a set of government functionality that covers the entire budget cycle. This functionality is configured through parameters and other non-code methods. There is significant configuration flexibility for government provided. The functionality is updated because we are involved in implementations.

ERP providers have a broad set of multiple-industry functionality where some industry requirements can be configured. This depends on distance between the customer’s requirement and the original code base industry. There is far less configuration capability in ERP software applications to meet government requirements than in FreeBalance GRP.

How are ERP Vendors Selling the Idea of Less Configurability?

ERP vendors are telling governments that they need to implement “best practices“.

What are these best practices? These are practices that are built into the software that primarily come from the private sector. They are often not best, better or even good for government needs. They often impose unnecessarily complex practices. Budget and commitment controls are lost or ineffective in large implementations.

ERP vendors sell this notion of poor practices as proven in the private sector and that governments want to operate more like the private sector.

Best practices and operating with private sector efficiency is a compelling narrative.

And, dead wrong.

It’s another sad milestone in the waste of public funds to support ERP systems.

In this rather lengthily post I will describe:

  1. Why this ERP narrative is wrong
  2. The motivation for ERP vendors to adopt this narrative
  3. How governments can be protected from the high cost of ownership associated with ERP

1. Vanilla ERP Narrative for Government is Wrong

It is generally accepted that vertical functionality is needed for ERP-class applications across all industries. A study by Panorama Consulting found that heavily customized Tier 1 ERP Systems ranged from 33% to 38%, Moderate Customization from 40% to 42% and Vanilla from 21% to 26%. It should be noted that the majority of survey respondents were from the private sector.

  • Legislation: “Best practices” sound like a good idea and has sold a lot of software in the past. Governments, however, operate on a legal basis. Some to many practices advocated by ERP companies will require legal changes in additional to business process re-engineering. The point here is that legislation is passed for a reason. That reason may be fully justified. These practices often “support your fundamental policy objectives.”
  • Best Practices: In addition to legislative differences, “ERP‟s best practices are not necessarily “best” for the organisation.” These so-called “best practices” are often default functions whose purpose is unclear.
  • Mimicry: Isomorphism – copying what another company or another government has done assumes an identical context – solving the same problem with the same resources. Governments do not have the problem of increasing gross profit margins. The German government does not have the liquidity problem experienced by the Greek government. A small national government operates at the local, state and national level at the same time while large federal states have separate tiers. The public service capacity to adopt accrual accounting is much higher in New Zealand than Vietnam.
  • Budget: Profitability is the main concept of control in the private sector. Budget is the main concept of control in the public sector. And, the budget is the law. Yet, many ERP subsystems such as Payroll and Procurement (the lion’s share of expenditures) often have limited or no budget controls.
  • Change: The vanilla ERP approach is predicated on the notion that significant changes are unexpected over time. After all, if one is running “best practices”…. However, change is a fundamental part of government and Public Financial Management (PFM). There is no election cycle in the private sector. New governments come in with new policies and change organizational structures, performance criteria and approaches to public finances (i.e. Public Private Partnerships, competitive sourcing, procurement support for small businesses, grants to disadvantaged regions). Most governments are on the road to reform i.e. accrual accounting, procurement reform, public service reform, performance management, value for money) where it is unrealistic to freeze a process snap shot.
  • Entities: Standardization is seen as a major advantage when adopting an ERP system. Of course, one can have compliance with standards with GRP or with having different software applications. The notion of vanilla ERP is to have a single standard package with standard processes used by every government entity. Of course, these entities differ far widely than those owned by a private sector conglomerate (who often use different ERP applications by division). In particular, mandates and size differ greatly. The process of procuring military equipment is far different than procuring office supplies. The control requirements for an entity of less than 100 staff differs from one with over 10,000 staff. And, the definition of what an entity is changes. Government create special agencies. Government consolidate agencies.
  • Information: Governments require rich decision-making information. Vanilla ERP often does not provide governments with data meeting information processing requirements.
  • Workflow: Many ERP failures are blamed on the unwillingness of customers to re-engineer business processes to be more efficient. ERP vanilla processes that originate in large private sector concerns are often more complex than those used in government.
  • Capacity: Capabilities of operating software differs among governments and differs within governments among ministries, departments and agencies. Vanilla ERP is still ERP. It’s complex. Some entities in a government may be able to operate ERP systems without a significant need for outside consultants while others will not.
  • Stakeholders: Government shareholders are citizens. Every citizen is a stakeholder in government. This introduces the need for governments to treat citizens in an equitable fashion. Governments elect to provide transfer payments to sub-national governments not based on population. Grants and procurement is used to build sectors of the economy. Private companies are not concerned about this. Governments also have more of a transparency mandate than in the private sector.
  • Standards: ERP systems need to keep up with regulatory changes. This problem is experienced in the private and public sectors. The public sector burden is increased because of international covenants and supporting standards such as IATI, EITI, OECD DAC, GFS, COFOG and the emerging open contracting standards.

2. High Costs to Government and Low ERP Satisfaction Driving the Vanilla ERP Narrative

3. How Can Governments Be Protected from the Customization – Requirement Conundrum?

There are some lessons learned from FreeBalance that I’m providing outside the context of our software. Here’s how to approach GRP requirements – whether you are acquiring GRP or ERP.

  • Governance: The software manufacturer must be part of vendor governance – not a hands-off provider through a reseller. The manufacturer must commit to features that can be configured by governments rather than rely on customization.
  • Adaptability: Expected modernization must be enabled in the software. Manufacturers must commit to supporting progressive activation.
  • Open and Modern: Systems to support GRP requirements should be built on open technologies or widely used but not proprietary to the manufacturer. Examples: Java, C++, C#. The software should not have any legacy client/server code. Integration must support the WebServices standards.
  • Roadmap: Many governments request a copy of the vendor roadmap for the next 2 to 5 years. This is a “tail wags dog” notion. Governments need to be driving the roadmap for government functionality, not the manufacturer.
  • Controls: All modules of software must be budget aware with budget and commitment controls.
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