Sari la:
tl;dr
The zeros attached to digitalisation projects financed over the past two decades have been many. The figures speak more plainly than any speech about how old and how costly the promise of digitalisation in Romania has been.
“According to our estimates, between 2000 and 2008 Romania invested 6 billion euros in electronic systems specific to public administration, and the reality is that we find ourselves in a situation where each institution has multiple systems that do not communicate with one another,” Toma Câmpeanu, head of the e-Romania team at the Ministry of Communications at the time, told us back in 2010. Further waves of funding followed: the eRomania portal, which cost around 12 million euros in total, as well as the health card and the electronic health record, which together consumed up to 300 million euros.
Through the NRRP (National Recovery and Resilience Plan), Romania committed to a major leap forward: 5.97 billion euros, 20.5% of the plan’s total value, allocated to digitalisation projects, of which 1.81 billion euros for the digital transformation component of the public sector alone. To this must be added the Smart Growth, Digitalisation and Financial Instruments Programme 2021–2027, from which 661,597,387 euros (495,775,745 euros in ERDF and 165,821,642 euros from the state budget) are earmarked for the priority “Digitalisation in central public administration and the business environment.”
For more details about the digitalization projects (and not only) in the NRRP, I recommend the interface created by transparență.eu.
These are a few specific examples that indicate quite clearly that Romania’s digitalisation has not suffered from a lack of funding, perhaps only in the sense of long-term financial planning for overhaul and improvement, but it suffers acutely from a lack of vision, genuine conviction, and from the “this is how we’ve always done it” syndrome.
Old habits die hard; and so do the state’s procedures.
With all the nuance that such a generalisation sacrifices, the trajectory of e-government projects has, in general, been the same: terms of reference, public procurement, implementation of an IT system and accompanying platform, at the end of which projects have emerged that competed with one another for the title of the platform with the most user-hostile experience.
What is missing from that trajectory is process analysis and the corresponding legislative changes. In reality, there are three concepts whose distinction is constantly ignored:
- Digitisation: the conversion of documents or information from paper to electronic format;
- Digitalisation: the same procedure, but conducted on an electronic medium;
- Digital transformation: a workflow redesigned and adapted for the electronic procedure.
Digital transformation cannot be achieved if we cling to procedures that are incompatible with any meaningful definition of modern public services. What appears to be modernisation, but is not:
- When you are required to submit exactly the same documents for the online procedure as for the in-person one;
- When you can send a scanned request by email;
- When you can book an appointment online;
- When, after submitting your request electronically, you receive a reply asking you to appear in person to submit the original documents.
What we currently receive by way of electronic public services are the crumbs of what those services could be, and this is borne out by our own opinion polls, which clearly show what the state actually provides in terms of electronic public services: online tax payments and online appointment booking.
But first: what does a successful digital transformation project actually look like?
I. Academic Literature: The Success of E-Government Projects
The academic literature tells us that evaluating the degree to which an e-government project has achieved its objectives must address several dimensions.
- Does the system deliver the promised functionalities, and have administrative processes been genuinely redesigned for the digital environment or merely transposed mechanically online? Richard Heeks proposes the ITPOSMO model, which measures the gap between project design and implementation reality across seven dimensions: information, technology, processes, objectives and values, staffing and skills, management structures, and resources.
- Technical delivery does not automatically constitute success if users do not adopt the system. DeLone and McLean demonstrated as early as 1992 that the success of an information system depends on six interdependent dimensions: system quality, information quality, and service quality, alongside usage intent, user satisfaction, and net benefits. Actual usage rates and satisfaction levels must be measured separately from technical indicators.
- Adoption is in turn conditional on interoperability. Fitsilis, Anthopoulos, and Gerogiannis reiterate that a system that does not allow data exchange between institutions continues to force the citizen to present documents already held by other authorities, thereby negating part of the value delivered.
- Measurable impact and organisational change: reductions in processing time, lower cost per transaction, and the elimination of redundant service counters, factors identified by Joshi and Islam as key determinants.
- These are reflected, or should be reflected, in the public value perceived by citizens. Vial defines digital transformation as a process aimed at significantly improving the properties of an entity through combinations of information and connectivity technologies. In the public sector, this means that evaluation cannot sidestep questions about transparency, the reduction of perceived bureaucracy, and trends in institutional trust.
- None of the above dimensions can be achieved if the institution’s staff and the target citizens lack the necessary digital skills. The existence of training programmes, the level of digital literacy among target groups, and the availability of alternative channels for vulnerable groups are equally important criteria.
Focusing on the first of these dimensions, what follows is a brief analysis built around one example, not the most dramatic available, but selected because it is a relatively recent digitalisation project that promised much and delivered below expectations: the Ministry of Labour’s services hub.
II. An IT System Built on Legislation from Another Era
The Competitiveness Operational Programme 2014–2020 funded the project “HUB de Servicii MMPS – SII MMPS” (SMIS code 130963), with a named beneficiary: the Ministry of Labour and Social Protection, in partnership with ANPIS and the Authority for the Digitalisation of Romania. With an estimated value of 58,601,001.68 RON (excluding VAT), the stated objective was an ambitious one: providing electronic public services for citizens’ life events at sophistication level 4 (fully electronic transactions), in line with the National Strategy on Romania’s Digital Agenda 2020.
“The supplier shall be required to carry out analysis activities that create the conditions for effective implementation at central and national level. The beneficiary shall provide all necessary support to ensure the fullest possible understanding of the context in which the IT system will be implemented.”
Section 7.1 of the terms of reference defines the analysis and design phase, assigning the supplier the obligation to carry out analysis activities that create the conditions for effective implementation, including an as-is situation analysis, identification of operational processes, and definition of information requirements. The beneficiary is, according to the terms of reference, responsible for providing all necessary support to ensure the fullest possible understanding of the context.
In a mature digital transformation project, the contracting authority initiates the procurement procedure only after the to-be vision for existing procedures has reached at least the stage of a proposed legislative act. Full responsibility for process reform cannot rest with the private firm, because it is not a legislator, at best, and if asked, it can propose workflow changes on the basis of which legislation can subsequently be drafted.
The user guide for applying for child allowance, parental leave allowance, and the reinsertion incentive documents workflows that faithfully reproduce the anatomy of the paper form. The once-only principle remains an abstract concept, because data on employment status, income, beneficiary history, and disability status are supplied by the citizen rather than retrieved from IT systems, even though some of those systems are managed by institutions subordinate to the Ministry of Labour itself. This is far from a deficiency unique to the hub; the system reflects the state of interoperability in Romanian public administration, or rather, the lack of it.
If we have made you curious, go and see for yourselves
For the most impatient among our readers: after filling in all the fields, a request is generated that has the feel of an archaeological discovery.
III. What We Found at the Legislative Level
The legislation governing child state allowance and parental leave allowance was conceived in a strictly physical logic (applicant presence, originals, copies, and handwritten signatures). Requests “shall be submitted to the town hall of the commune, town, or municipality within which the applicant has their domicile or residence” (GEO 111/2010, art. 14(1)); documents “shall be submitted as copies to be checked against the originals at the time of submission” (Implementing Norms 2011, art. 6(1) and (4)); and once submitted, files do not circulate in real time between institutions: “by the 5th of each month, town halls are required to transmit, by covering schedule, the applications registered in the previous month, together with the supporting documents” (GEO 111/2010, art. 14(2)).
In the same vein, “applications registered in the previous month shall be transmitted monthly to the territorial directorates by educational institutions through the school inspectorates” (Government Decision 577/2008, art. 3(3)), and “mayors are required to transmit monthly to territorial agencies the registered applications and supporting documents, together with a consolidated table” (Implementing Norms 2008, art. 7(1)).
The standard form has dedicated fields for “Applicant’s Signature” and “Other Parent’s Signature” (Implementing Norms 2008, Annexes 1a, 1b, 2); the town hall’s consolidated table carries the printed notation “L.S.” — official stamp space (Implementing Norms 2008, Annex 4); and supporting documents require “the stamp of the legal representative” (Implementing Norms 2011, Annex 2). All subsequent communication follows the same rule: the beneficiary “is required to notify the town hall in writing of any change” (GEO 111/2010, art. 19(1)), and in certain situations “the child’s legal representative transmits their written and signed consent to the territorial directorate” (Implementing Norms 2008, art. 11(3)).
Digital elements make their way into these procedures far too tentatively, and local authorities do not promote the online option at all in their informational sections on how to apply for allowances and benefits. In the same spirit, document certification “by signature and stamp” is the rule, while “where possible, certification shall be carried out by electronic signature” (Implementing Norms 2011, art. 19(3)). Similarly, town halls transmit documents “including in electronic format where this is possible” (Implementing Norms 2011, art. 19(2)).
We have a legislative architecture that has never been redesigned for the online environment, despite a digital ecosystem that — for better or worse — does exist. Any genuine digitalisation effort runs up against the text of the law before anything else.
IV. What Should Happen
A digital transformation project begins with a simple and uncomfortable question: does the procedure we want to put online still make sense in its current form? You cannot build a functional electronic public service on a legislative foundation that requires originals and copies, monthly covering schedules, signatures, and stamps. At best, you can build an interface.
Three things that must happen in this order, and not in reverse:
- Process reform first. Procedures must be analysed and redesigned for the digital environment. This means answering questions such as: why does the state need this document, why can it not obtain the information directly from the relevant institution? Why does the town hall communicate with the territorial agency on a monthly basis rather than in real time?
- Then, amendment of the legislative framework. The process analysis must produce concrete legislative amendment proposals, and these must be adopted before or at the very latest simultaneously with the launch of the public procurement procedure (where applicable).
- Only then, technical implementation. With the process clarified and the legislation aligned, the terms of reference can be written properly. The firm implementing the system cannot be left to discover, during the analysis phase, that the procedure it is about to automate is incompatible with any reasonable definition of a digital service.
Conclusion
My conclusion today is that we need the funds already allocated to follow the correct logic: first, understand what you are building; then, amend the law so that you can build it; and only after that, build it while trying to avoid the familiar cycle of funding, platform, disappointment.