It’s High Time to Reintroduce the “I” in Integrated Financial Management Systems for Government, but Let’s Get Beyond “Integrated”
Context : PFM experts coined the term “IFMIS””to refer to government systems that integrated core financial functions. Only problem? Very few were truly integrated. Integration is in a horrible state in many countries with multiple silos, legacy systems, and manual processes.
- Multiple custom subsystems with different technologies and classifications
- The combination of custom and Commercial Off-The-Shelf (COTS)
- It’s difficult to integrate modules from a single ERP system (despite the marketing noise from these vendors)
- We all seemed to give up on the “integrated” aspiration for Government Resource Planning: “FMIS” it is
Enter the COVID-19 pandemic, with governments:
- Reallocating spending
- Procuring PPE supplies and medical equipment
- Assisting businesses and citizens
- Supporting public servants to deliver citizen services
- Tracking spending
Challenge:: how can governments successfully manage the pandemic response when:
- Revenue, debt, and expenditure systems are separate, with different classifications, so liquidity information is stale?
- Procurement and core financial systems are separate so tracking spending alignment is difficult?
- Controls differ among procurement, relief, and other payroll, so many non-compliant spending occurs?
Reality check is that “integration” as originally conceived with “IFMIS” is not enough:
- Integration at the database level is a poor IT practice because there is no metadata and interfaces will break
- Integration at key points in the budget cycle, usually with vouchers, is superficial and prone to error
- Integration without metadata management generates many versions of the truth, compromises decision-making and audit
- Integration through APIs and web services lack resilience to software changes, especially when these integration methods are not commercially supported
- Integration without shared budget, commitment, and approval controls introduces compliance risks
An alternative view is that “integration” is just Information Technology “plumbing”.
- It’s very complex “plumbing” with a range of tools including: stored procedures, scripts, ODBC/JDBC calls, flat files, Extraction-Transformation-Load, Remote Procedure Calls, proprietary methods, metadata management, web services, and APIs
- Many integration methods are error-prone
- It’s difficult to validate data completeness, data validity, controls compliance, and user authorization at government transaction scales
That’s why it’s high time to think “interoperability”: seamless and unified integration
- where all core (and some non-core) are built on the same functions
- not just building modules with the same technology deployed as silos where classifications and controls can differ
- a single environment where all modules share the same metadata and controls
- change the Chart of Accounts, change a process, transfer an employee, depreciate an asset: once
- no need for a metadata management system or integration callisthenics
Why it matters for public finance? Consider the following scenario (that happens far too often):
- a government ministry attempts to procure something when the procurement system is not interoperable with core financials
- the ministry can procure based on different classifications than described in the core financial system
- the ministry can skip over segregation of duties in the procurement
- the ministry can record the procurement as anything in the financial system COA
- and, it can show up in government accounts as an emergency COVID-19 expenditure, when it isn’t
What is different about the legacy COTS method vs. the postmodern “unified” approach?
Example: debt, capital, development, operating & public sector budget planning integration, procurement integration, payroll integration
- Legacy: large monolithic components assembled as module silos, includes modules from mergers, has proprietary integration with some support for open standards, requires metadata management to interoperate
- Postmodern: granular components shared across the suite that inherently interoperate with a single point of metadata management
- In other words, don’t be fooled when legacy ERP vendors talk about integration
What about custom-developed financial applications in government? Integration has proven to be elusive in governments who think simple bespoke systems will cost less and have similar benefits to COTS.
- Mind you, some COTS implementations have as much code customization as custom-developed software!
- Many governments using custom-developed systems cannot provide timely information to decision-makers
- The amount of overnight batch processing for consolidated reporting or transparency portals in some countries is impressive: high complex transformation, validation and loading
What’s really needed for government resource planning or FMIS environments is an evaluation method to determine integration and interoperability risks and opportunities.
- That’s another service that FreeBalance can provide, remotely, to any government organization
The ideal Government IFMIS: Interoperable Financial Management Information System
