October 19, 2009Doug Hadden
It’s rather simple: GRP needs its own category because GRP is categorically different. We defined what GRP is in a post last week. To answer the question of how GRP is different, this week we’ll deal with what GRP is not.
Let’s take a brisk walk down memory lane.
In the 1980s, the business software industry had an obvious proclivity for three-letter acronyms (TLAs, if you will). Whether blatant attempts at vendor-driven fanfare (“No endeavour is respectable these days without a TLA…”) or genuine efforts towards outward simplicity, TLAs stuck as accessible abstractions for complex but disparate technologies with correspondingly complex names. HRM (human resources management), CRM (customer relationship management), SCM (supply chain management), and PPM (product portfolio management) became, among others, the tri-syllabic names of the trade.
The 1990s, however, saw a fundamental shift in the way vendors offered business process solutions to their clientele. HRM, CRM, SCM and PPM were no longer sourced from disparate vendors operating within singular domains. In 1990, Gartner crowned the queen of all business process TLAs, ERP (enterprise resource planning). ERP vendors began to consolidate the afore-mentioned business process solutions into a single all-encompassing suite of applications, offering one-stop shops for all of its business clientele’s needs.
Almost 2 decades later, major enterprise software companies continue to thrive under the ERP banner. In the process, however, the crucial components that make up ERP software (HRM, CRM, SCM, etc.) have been lost to obscurity; the queen of TLAs has made knowledge of its subject TLAs irrelevant. We’re led to believe that ERP is greater than the sum of its parts, but it’s still the parts that come together and make it so.
In fact, when ERP is deconstructed and its component applications are brought back to the fore, it becomes clear that its purported ‘relevance to government’ is premised on shaky foundations. HRM is not the same as civil service management, CRM is not the same as citizen relationship management, and SCM is not the same as budget and expenditure management. Indeed, there are crucial differences between government and business that the categorization of ‘ERP’ obscures.
We have nothing against ERP as a category – there’s nothing inherently wrong with it. Nor are we suggesting sinister motives. On the contrary, ERP is great at what it’s meant for: enterprise. But whatever the merits or demerits of the argument, the (arguable) notion that “Government should be run like business” – for ‘business-like’ efficiency, agility, accountability – by no means suggests that governments should be run as if they already are businesses. On the contrary, it suggests certain guiding principles for what governments might aim for without necessarily prescribing how to get there.
The fact is, there is no one way to get there. No two governments are in the same position at any one time; no two governments share the same context. What works in one country cannot be transplanted to another. And perhaps most importantly, there is no one conception of where ‘there’ is. Rarely do two governments have the same end-goals in sight.
Consider: unlike the private sector which aims to maximize profit, the public sector does not have a uniform bottom-line with clearly definable metrics. In fact, the public sector often has multiple bottom-lines, lending itself to myriad combinations of goals and objectives. And as if that weren’t complicated enough, it’s important to note that these myriad goals and objectives are in themselves dynamic. Even the US and UK, for example, arguably the two most advanced economies in the world, are engaged in improving their accounting practices – both are currently striving to implement consolidated government financial statements.
This uniformity in the bottom-line of private enterprises manifests itself in a uniform mode of accounting. Private sector enterprises across the board issue financial reports based on the commercial principles of double-entry accounting. As Nalin K. Srivastava and Jawahar Thakur point out in a soon-to-be-published paper, any differences that do exist among enterprises in different countries amount only to the processing and treatment of various types of financial transactions. Government entities, on the other hand, report accounts based on their own conventions (cash-based, modified cash-based, modified accrual-based, or full accrual-based), which are usually codified into law and are thus less conducive to rapid change.
It’s often the case that private enterprises modify their business processes to comply with new enterprise software implementations. Considering that the private sector can rely on industry-wide ‘best practices’, forcible improvements might not be such a bad thing. Government entities, on the other hand, with their wide array of contexts, services, and goals, do not have any ‘best practices’ to follow. It’s no coincidence, for example, that the International Public Sector Accounting Standards (IPSAS) continue to advocate the adoption of consolidated statements, while the most recent IMF Government Finance Statistics manual dropped all mention of them.
What emerges from these observations is the need for a categorically different system of applications that represents the categorical differences between government and business. GRP must not be held hostage to misplaced ‘best practices’ when there are none. GRP must not be premised on a pre-determined ‘end-state’ when governments do not have one. GRP must deploy functionality dynamically when government processes are dynamic in themselves. And when the medium is often the message, GRP must not be built as a monolithic black-box category with obscured components while governments strive for greater transparency and accountability.
The pressing fact is that in government, one size does not fit all. It’s high time that a category of applications was devised that considered this most basic observation. Welcome to GRP.