Why does technology work in one place, but not the other? This critical question asked by a team from the Harvard Kennedy School of Government about country development led by Matt Andrews, Lant Pritchett and Michael Woodcock. I think that their analysis applies to the high failure rate of ERP in government: isomorphic mimicry.
Isomorphic mimicry is about getting the “benefits of looking like something without being that thing” as described by Pritchett. It enables organizations to gain legitimacy by looking like legitimate organizations.
Andrews has described that mimicry enables governments to ‘signal’ improvements without necessarily improving. Andrews contends that governments focus more on “looking good” than “doing good.” There are four mimicry patterns that we see with ERP in the Government Technology market:
1. ‘Best Practices’
ERP vendors claim to build industry best practices in software. This “best practices” idea is also used in the country development space. Many international donors push these practices to developing countries. And, it is easier to get development programs approved when they follow established best practices.
Like with development, ERP implementations that worked in one context may not work in other context. There are so many factors including customer capabilities, customization needs, regulations, subsystems, change cultures, and more. And, many practices built into ERP software are poor for other situations.
The notion of using “best practices” is an excellent way to signal public service competence to politicians who approve ERP implementation budgets.
2. Cost Savings
ERP customers have saved millions of dollars, according to vendor pubic relations. The source of this savings include: lower IT costs, reduced manual stages, and improved integration.
This saving is relative to previous systems, and it’s often an aspiration or goal. Rarely do ERP customers report actual savings. It’s rare that ERP customers achieve these benefits. And, the unique context of the ERP customer who has achieved cost savings is rarely applicable to other situations.
This notion of saving money is politically attractive for governments to signal government financial stewardship.
3. Act as a Business
ERP software was usually developed to support private sector needs. Many of these products have been extended to support multiple industries, including government. Most experts agree that governments need significant amounts of code customization in ERP systems, especially compared to Government Resource Planning (GRP) systems alternatives. The more code is customized, the higher the costs. Code customization adds to technical debt. This is why GRP tends to be more economically viable than ERP in government.
However, many politicians are seeking to “run government as a business.” What better than to run business software? This view caters to the stereotype that governments are wasteful, and public servants lazy.
The use of business software in government is politically attractive for governments to signal government efficiency and effectiveness.
4. Enterprises use ERP
It’s all in the name. Everyone knows that enterprises use Enterprise Resource Planning. So, any organization looking at the “big picture” needs an enterprise software backbone. It doesn’t matter than there is enterprise-class software not called “ERP”, or open systems that are more effective than many proprietary software stacks, to many observers. Of course, ERP vendors have pushed this simplistic perception.
The use of “enterprise” software in government is an excellent way to signal public service competency to politicians who approve ERP implementation budgets.
Realities of ERP in Government Isomorphic Mimicry
Isomorphic mimicry is a mental shortcut – a heuristic. It’s easy to understand why politicians, public servants, and advisor succumb to the dominant development, and the dominant enterprise software narratives. There have been mixed results in country development practices, and in ERP implementations. In particular, the use of ERP in government when the unique government context is not understood has resulted in higher costs than anticipated for the project. The desired benefits are rarely achieved. Public servants need to work around the system in order to gets work done.
In other words, if governments utilized business mindsets, they would be unlikely to acquire ERP for most functions.