Custom software vs generic ERP for public administration: which to choose

When a public body needs a new management system, it invariably faces the same dilemma: do we buy a standard ERP off the shelf and configure it to our needs, or do we commission custom development? Both options have staunch advocates and success stories. Both also have costly failures to their name. The key is knowing which one is right for each situation.

What is a generic ERP and what is custom software?

Generic ERP (enterprise resource planning): a standard management system designed to work across many sectors and organisations through configuration and parameter settings. Examples: SAP, Oracle, Microsoft Dynamics, Odoo. In the Spanish public sector, there are also solutions that are sector-specific but standard, such as SIGEP, PLYCA for procurement, or the platforms of the Junta de Castilla y León (regional government) or of central government (Administración General del Estado, AGE).

Custom software: a system designed and developed specifically for the processes of a particular public body or sector. It does not exist before the project: it is built to the client’s requirements.

Between the two extremes lies a sizeable grey area: configurable ERPs and sector-specific products, which are standard at their core but can be extensively customised. Many public sector solutions fall into this category.

When a standard ERP makes sense

A standard ERP is the right option when:

The processes are standard and need no differentiation. Public sector accounting, civil service payroll, basic administrative case management – these processes are standardised by law and are the same in every public body at the same tier of government. There is nothing to be gained from building them to order.

The public body does not have the technical capability to maintain software of its own. A small local council with 20 employees has no technical staff to manage a custom system’s updates, security patches and adaptations to new legislation. An ERP with vendor support shifts that maintenance burden on to the vendor.

The budget is limited and the implementation timeframe is short. An existing ERP can be in production within weeks. Custom development of the same functionality can take between 3 and 12 months.

The ERP covers 80–90% of the functionality needed. If the standard system meets most of the requirements and needs only minor adaptations, the ERP is more efficient than development from scratch.

When custom software makes sense

Custom development is the right option when:

The processes are unique and no ERP on the market provides for them. A traceability system for a provincial water distribution chain, a tender management module for a provincial council (Diputación) with approval workflows dictated by its own organisational structure, or the platform on which SIMA (Spain’s national mediation and arbitration service) manages labour mediations – none of these systems exists as a standard ERP, because the market is too small for any vendor to develop one.

Integration with existing systems is critical and complex. When the new system has to integrate with several legacy systems built on different technologies, and that integration is what gives the project its value, a standard ERP requires costly adaptations that frequently end up costing more than custom development.

The public body needs full control over the intellectual property in the code. In critical projects financed with public funds, having the source code under the public body’s control means it can audit the code, have other suppliers modify it in future and guarantee continuity of service regardless of the original supplier.

The security requirements are stringent and the standard ERP does not meet them out of the box. For systems in the medium or high category of Spain’s National Security Framework (Esquema Nacional de Seguridad, ENS), security has to be designed in from the outset (security by design). Adapting a generic ERP to meet the ENS requirements for the high category is usually more expensive and less robust than designing security in from scratch.

If any of these scenarios applies to you, our custom software page explains how we approach the preliminary analysis of processes, the documentation and the handover of the source code to the public body.

The “almost perfect” ERP trap: the real cost of configuration

The most common argument in favour of a standard ERP is the financial one: “it is already built, it just needs configuring”. That argument consistently breaks down when the configuration is extensive.

A Gartner study of ERP implementations in the European public sector showed that the total cost of ownership of a heavily configured ERP over 5 years is between 1.8 and 2.4 times the cost of the initial contract. The hidden costs include:

• Annual licence fees that rise with the number of modules and users
• Specialist consultancy from the vendor for every configuration change (at premium rates)
• Version upgrades that undo earlier configuration work
• Technical lock-in to the vendor, which makes it hard to change supplier

Custom software has maintenance costs of its own, but they are more predictable and involve no incremental licence fees.

The ENS: how it affects the ERP vs custom decision

ENS certification adds an important dimension to this decision, and one that is frequently overlooked.

Standard ERPs and the ENS: The major vendors (SAP, Microsoft) hold ENS certification for their cloud platforms. However, the certification covers the base platform, not the customisations. When a public body adds custom modules or integrations, those additional components fall outside the scope of the certification and have to be certified separately. This can turn ENS certification of a configured ERP into a long and costly process.

Custom software and the ENS: An ENS-certified custom software supplier designs the system with the required security controls from the outset. ENS certification covers the whole product, because there is no standard base onto which layers of customisation have been added. The scope of the certification is clearer and the certification is simpler to maintain.

For public bodies with medium- or high-category systems that need ENS certification that is straightforward and easy to maintain, custom software from a certified supplier is usually the safest option in the long term.

Decision checklist: 8 key questions

Before deciding between an ERP and custom software, answer honestly:

1. Does the standard ERP cover more than 80% of the processes you need without adaptation?
2. Does your organisation have the technical capability to manage a custom system (updates, incidents)?
3. Is the implementation timeframe a critical factor (less than 6 months)?
4. Are the processes you need standard across the sector or unique to your organisation?
5. Do you need integration with many existing external systems?
6. Do you want to own the system’s source code?
7. Is the system’s ENS category medium or high?
8. Do you expect frequent regulatory changes that will affect the system?

If your answers to questions 4, 5, 6, 7 or 8 are mostly “yes”, custom software is probably the most efficient option in the long term.

With the model decided, a second question remains: what type of supplier will deliver it. In Large integrator or mid-sized company? How to choose a supplier we compare the two by category – contract size, who you deal with, the thresholds for technical capacity and financial standing in the tender specifications, and team turnover – and say when each one is the right answer.

Frequently asked questions about custom software vs ERP in the public sector

Can custom software be put out to tender as such, or does it require a specific type of contract?

It can be put out to tender as a services contract (development) or as a mixed contract (development + maintenance). Spain’s public procurement law, Law 9/2017 on Public Sector Contracts (Ley 9/2017 de Contratos del Sector Público, LCSP), places no restrictions on contracts for custom development; what matters is that the tender specifications correctly define the subject matter of the contract and the acceptance criteria. For complex projects, it is common to use the negotiated procedure with prior publication (procedimiento negociado con publicidad) or competitive dialogue.

What safeguards does the public body have if the custom software supplier disappears?

The tender specifications must include handover of the source code and the complete technical documentation, and the placing of the code in escrow with a third party (such as AENOR, a Spanish certification body, or a notary). With these safeguards, the public body can engage another supplier to maintain the system. This clause is especially important for critical software.

Is it harder to justify a custom software project to the comptroller’s office?

Not necessarily. The comptroller’s office (Intervención, the internal financial controller of a Spanish public body) looks at whether the subject matter of the contract is clear, the price is justified by market rates and the deliverables can be verified. Custom software that is well documented and has objective acceptance criteria is perfectly justifiable. The difficulty arises when the tender specifications are ambiguous or the deliverables are not defined.