No-Code and Progressive Activation in Government Resource Planning
If there’s one thing that FreeBalance has learned after almost 40 years exclusively dealing with the public sector, it’s that government processes are different. Different amongst governments. Different within governments. Very different from businesses. And, constantly changing.
Adapting Commercial-Off-the-Shelf (COTS) software such as the major Enterprise Resource Planning (ERP) systems to operate in government organizations can be disastrous. Enterprise software projects in government are fraught with failure and complex implementation methods. Many in the technology industry view these travails as the “cost of doing business.” “It is what it is”, etc. But why does it have to be this way? Why can’t COTS software adapt easily to changing requirements?
This blog unpacks the differences between configuration (used by the FreeBalance Accountability Suite™) and customization (required for ERP implementations), and explains our progressive activation and no-code approach.
Difference Between Configuration and Customization
Most COTS software used for Government Resource Planning (GRP) requires significant code customization. Software development, typically using proprietary programming languages, enables governments to support custom requirements. But, at a cost.
What is Configuration?
In digital Public Financial Management (PFM), configuration refers to the ability to set up and personalize the GRP system, or Integrated Financial Management Information System (IFMIS) as it is often called, to suit the needs of a public sector organization. This may include configuring workflows, setting up user permissions, and defining budget categories. Configuration options are typically pre-defined by the GRP provider and are available to all users within the organization.
What is Customization?
Customization, on the other hand, refers to the ability to modify the GRP platform or software to better fit the specific needs of the organization. This may include creating new modules, integrating with other systems, or even developing custom reports or dashboards. Customization options often require significant technical expertise.
What’s the Problem?
Many PFM experts don’t see much of a difference between configuration or customization – often referring to any adaptation as “customization”. We’ve been talking about the difference for some time. And, the industry has finally caught up to us by defining configuration as “no-code” customization. The use of helper software to facilitate code development is now called “low-code” development. We prefer the term “configuration”, but this no-code to full code spectrum is a useful model.
ERP and Customization
Generic ERP software is highly customizable using proprietary programming languages like ABAP and PL/SQL. It does offer some configuration opportunities, albeit not really applicable to the public sector:
- Configuration of standard parameters like fiscal years, currencies, vendors, etc.
- Vertical market quick starts to facilitate implementation, although few applicable for public sector
- ‘Best-practices’, primarily from the private sector, built into software that might be applicable to some government functions, as long as no legal reform is required
The issue with code customization is that it comes with high costs and future adaptability challenges thus creating technical debt.
Technical Debt
Governments acquire significant and compounding technical debt via full code and low code customizations.
Technical debt includes:
- Implementation Complexity of fully articulating requirements and deploying similar to fully custom development, requiring coordinating programming teams, and instituting comprehensive quality assurance
- Maintenance Complexity after implementation increases because there is orphan code that must be supported through internal resources, not the manufacturer’s responsibility
- Upgrade Complexity when leveraging functionality from new releases because the custom code needs to be examined and rationalized with the new version
- Change Complexity through needing to understand the orphan code before embarking on change
Technology Gap
Code customization also limits PFM reform opportunities. We call this the “technology gap“. A Gartner Group analysis found that software not designed for future adaptation cost organizations about 50 times original investments over 15 years.
Signs of the technology gap in play are:
- Poor time-to-results for implementations
- Poor time-to-change for systems
- Many high-cost contract personnel to manage systems
- Frequent system errors and quality problems
- Limited ability to leverage data for other purposes because of alack of openness because of proprietary technology lock-in
- Limited sub-system integration, even among products from the same manufacturer
Why is Government Resource Planning Different?
Governments are faced with more complex implementations than businesses.
Government enterprise software implementations are more complex from:
- Many more lines of business across a national or sub-national government, than business conglomerates
- High human capacity constraints in technology, project, and functional knowledge
- More complex performance management structures and planning, because government does not have a bottom-line like “profit or loss“
- Higher practice diversity because of legal requirements
- More complex planning through multiple-year budgets that create controls in systems for commitment accounting
- Significant political concerns for public sector implementations
Governments also experience a broader change footprint than private sector organizations:
- More reorganizations after elections, and from cabinet shuffles
- More legal reform because many system procedures are set in law, and laws change – for example: move to accrual accounting, support for Treasury Single Account, procurement reform, public service reform
- More process change in addition to legal reform
- More international standards like MTEF, IPSAS, COFOG, GFS, and SDGs, in addition to supporting some private sector standards
- Broader organizational constraints including vested interests opposed to change
- Higher use of legacy technology in government making change expensive, although saddled with high operations and maintenance costs
No Technical Debt
Product design drives technical debt or technical value-add. Effective design results in elegant solutions to customer problems. FreeBalance’s focus on government has freed us from many enterprise software constraints.
The design for the web-native FreeBalance Accountability Suite™ began in mid 2006. We examined many of the constraints facing enterprise software manufacturers and made some conclusions:
- Government Functions: Software manufacturers lacked comprehensive government functions because of the need to sell software to many industries, or vertical markets, across many software classes (ERP, CRM, SCM, HCM etc.), or horizontal markets, and throughout the software stack (database, application server, middleware etc.)
- Budget Cycle: Software manufacturers lacked full support for the full government budget cycle of policy, budget planning, commitments and obligations, for all spending and revenue applications
- Adaptability: Software manufacturers relied on code customization because software was often designed originally for businesses
- Metadata: Software manufacturers had significant data definition problems within product suites that compromised integration and controls, often from company acquisitions, while providing rigid localization, especially for languages
The FreeBalance Difference
Our first decision was to develop a government-specific platform with a unified design. The product suite was therefore developed based on our Public Financial Management Component Map.
- Government Functions: Our focus enabled us to build comprehensive government functions across the PFM Component Map with appropriate horizontal functionality, ignoring other markets, and an open system that could support many software stacks
- Budget Cycle: Our focus enabled us to support the entire budget cycle, making all applications budget-aware
- Adaptability: We understood government technical debt, and extended configurability significantly from our previous releases
- Metadata: We realized that metadata needed to be unified, and integrated with configuration – we also realized that there had to be a better way to localize
Configuration and Progressive Activation
FreeBalance had become successful at implementing software quickly. Our implementation in Kosovo took just 26 days. The operational system at the time including budget controls, cheque printing, and a chart of accounts structure. Accounting functions came later. As did treasury, and decentralized controls. The configuration approach in previous versions of FreeBalance software facilitated quick wins. We realized that we could “progressively activate” any government to advanced public finance functions as enjoyed by our first and longest standing customer, the Government of Canada.
Since the completion of the first version of our web-based FreeBalance Accountability Suite™ modules in 2009, we have seen an increasing need for progressive activation.
Governments seek progress and modernization, supported by GRP systems for:
- Governance Reform: PFM, audit, public service, procurement, and tax reform
- Open Government: budget, fiscal, procurement, revenue, and results transparency with participatory mechanisms
- Decentralization: agency and sub-national fiscal decentralization, devolution
- Technology Automation: automation efficiencies, exception alerts, artificial intelligence
- Digital Transformation: migration of systems of record to systems of engagement, to systems of intelligence, and to systems of innovation
- Performance Modernization: program budgeting, performance structures, outcomes and results
Product and Services Integration Advantage
FreeBalance has benefited from a single-minded focus on government. Our software is massively configurable, when compared with generic software. And we act as both system developers and system implementers – another unique FreeBalance characteristic.
Many of our early international customers contracted major systems integration firms. We were a software provider, with some sub-contracting responsibilities. We discovered that our project involvement was proportional to project success. We also found that many government requests for feature changes had not been forwarded by our partners. Our product roadmap was not aligned.
The traditional approach to enterprise software product roadmaps is via integration partners with a second channel through product support. Software manufacturers are often disconnected from customer requirements. Manufacturers that support many vertical markets often lack expertise, so the “feature lottery” will often favour some markets over others.
FreeBalance Product Roadmap Approach
Our approach is different.
Our policy is to be involved in all implementations. We understand the government market. We work with systems integration companies. Our product and services teams are integrated in such a way that we do any product customization required. And, this customization becomes part of our commercially supported code in the next release. There is no orphan code.
Traditional enterprise software manufacturers build up long-term product roadmaps. This is an accepted approach. It makes no sense, but “that’s the way it is.” Customer needs and technology changes so much, that mapping out product features over the next three to five years, is more like gambling. Especially with any level of detail.
Customers are, however, conditioned to roadmaps. Prospective customers often ask to see our five and ten year roadmaps. We show them the PFM Component Map and explain that we will do anything here, and adapt software to meet their needs. (As long, as it isn’t a bad practice.)
Our approach is to build a three year detailed product roadmap based on our in-depth customer experiences. And, our government and technology research. We present this to our FreeBalance International Steering Committee (FISC) every year. FISC attendees change the roadmap priorities, and add items. This includes products and services.
Progressive Activation Smashes Technical Debt
FreeBalance is a purpose-led business. Our mandate is to build smart prosperity through technology-enabled governance. Governments cannot build prosperity when under technical debt from information systems. Technology should enable governance reform.
This configuration approach, that enables progressive activation, includes:
- Business rule parameterization
- No-code workflow
- Multiple year configured chart of accounts
- Unified metadata
- Additional data fields
- Single language file (rather than rigid language sets)
- Terminology configuration
- Adaptable help through integral content management system
For more information on how FreeBalance’s configuration approach, please get in touch.