Digitalizing Public Institutes: Where to Start

Where should a public institute start with digitalization?#

A public institute should begin digitalization by mapping its existing processes, not by shopping for software. Before any system is chosen, leadership needs to know which procedures still run on paper, where delays occur, and which data gets entered twice across departments. That mapping shows where digitalizing a public institute delivers the most value while keeping risk to staff and service users as low as possible.

The mapping should cover every department the change will touch: administration, finance, human resources, the archive, and the front-line services that deal directly with citizens. Each department lists which forms it uses, where they are stored, and who signs off on them. The result is a list of processes ranked by how many people they involve, how often they run, and how much time they currently take. That ranking is the basis for deciding which block to digitalize first.

Only after the mapping comes the decision on scope: a new information system, a citizen-facing portal, integration between existing systems, or a mix of all three. The scope can be taken on in full or broken into separate blocks, turning one large project into a sequence of smaller, manageable steps. That approach lowers the risk of the project stalling or outgrowing the institute's available staff capacity.

Which processes to digitalize first#

Priority goes to processes that repeat most often and weigh most heavily on staff: filing applications, attendance records, document handling, and reporting to oversight bodies. These processes deliver a visible improvement early, which gives staff a concrete result and lowers resistance to the steps that follow. Processes that happen rarely or involve only a handful of people can wait until the institute has gained experience from a smaller project first.

Choosing the first block means weighing a few questions that reveal where digitalization pays off most and where the risk stays manageable. Those answers show whether a process is frequent and heavy enough to earn first place on the list, or whether it belongs to a later block. It helps to write the answers down process by process, not just for the institute as a whole, since the load varies sharply between departments. Worth assessing are:

Once the first block is chosen, it helps to set a measurable goal for it, such as a shorter processing time for applications or fewer paper copies in circulation. The goal should attach to a process staff actually recognize, not stay abstract. That goal makes it possible to check afterward whether the change achieved its purpose, and to plan the next block of digitalization on real experience rather than assumptions.

• how many staff and users rely on the process daily
• how much paper documentation the process generates
• whether the process needs data from several departments at once
• how often errors or delays currently occur
• whether the process is required by law or internal rule
• how sensitive the data handled by the process is

Connecting existing systems and data#

Public institutes rarely start from a blank slate: they already run records, archives, and often ERP or CRM systems for finance, HR, or citizen relations. Before any digitalization project, it must be decided which of these systems stays in use, which gets replaced, and how they will exchange data through APIs. Whether the project builds something new or upgrades what already exists strongly shapes how long it takes and how complex it becomes.

When an institute takes over or continues an unfinished system, the first step is reviewing the source code, architecture, infrastructure, and existing data before deciding what comes next. That review shows whether the system can be upgraded or should be replaced. Skipping it risks building new work on an unstable base, which stretches out delivery and raises the cost of fixes later in the project.

Connecting systems and migrating data raises several technical questions that need answers before work starts, since problems in this area only surface later, when they are harder to fix. Decisions about data sources, access, and the test environment should be written down before development begins, not after the first mismatch between two systems appears. Among the questions an institute should settle with its provider in advance are:

Development, test, and production environments must stay separate throughout the project, not just at launch. Every change goes through review and testing before it reaches the production environment where the institute actually serves its users. That discipline matters even more in the public sector, where a production error can affect a service every citizen is entitled to, not just a single user.

• which data gets migrated and in what condition it currently is
• which system becomes the master source for each record afterward
• how to keep real personal data out of the test environment
• how changes get tested before they reach production
• who holds access to the data during and after migration

Data security and compliance in the public sector#

Public institutes handle personal data belonging to users, staff, and sometimes children or patients, so data security is a precondition for launch, not an optional extra. Before digitalizing, it has to be clear which data is sensitive, who can access it, and how that access is controlled. Compliance questions are worth settling at the planning stage rather than right before launch, since fixing the architecture for security afterward only stretches out the project.

Assessing risk means asking which rules apply to the institute's own field: general personal-data protection, sector rules for health or education, and internal retention policies. These questions are best worked through with the institute's legal function, not the technical team alone, since decisions about data retention and access often reach beyond information technology.

It also has to be agreed what happens at the end of the project: the source code and data remain the client's property, while documentation, access, and passwords are handed over as part of closeout. That means the institute isn't left dependent on a single provider for access to its own data once the project ends — an important guarantee of independence in the public sector, where support contracts are periodically renewed or switched between providers.

Who within the institute is responsible for the project#

Digitalization that touches several departments needs one decision-maker who can resolve disagreements between departments instead of waiting for everyone to agree. In practice, the institute's leadership names a person or small group who understands how the institute works and has the authority to set priorities. Without that person, the project stalls at every disagreement between departments, which in the public sector — where coordination is already slower — stretches out delivery.

On the provider's side, larger projects get a project manager who sets team responsibilities, deadlines, and how reporting to the client works. That arrangement should be written down from the start, not after the first disagreement over who decided a particular change. A clear split of responsibility between institute and provider is what makes the project trackable and correctable in time.

Beyond the project lead, it helps to involve representatives from the departments that will use the system daily, since their knowledge of the actual work reveals details leadership alone would miss. That involvement also lowers resistance during rollout, because staff aren't handed a system designed without them — they helped shape it during planning and can recognize their own contribution in the final solution.

How to choose a partner for digitalizing a public institute?#

A partner for digitalizing a public institute is best chosen by whether it can take on the full project or a single block and whether it has public-sector experience, not by price alone. Public institutes often work under public-procurement constraints, so requirements need to be specific enough to check and compare across bidders, not just described in general terms.

The institute's procurement function knows the rules that apply to buying IT services, so it should be involved while the tender documentation is being drafted, not only when a bidder is chosen. Technical requirements set by IT and legal requirements set by procurement have to align, or complications surface once the project is underway, often only after the contract is already signed.

Assessing providers is worth checking against more than price, since a cheap bid that doesn't cover the real scope often ends up costing more later, once extra work surfaces. Comparison should rest on the same criteria for every bidder, set out in the tender documents, not on the impression left by a presentation. Worth checking in particular is their track record on:

For larger, technically demanding projects, it's worth checking whether the provider can also draw on a wider network of security, data, and infrastructure specialists, since a single project often needs several roles at once, not developers alone. Assembling the team to match the scope lets the institute get the right skills for a demanding block without signing a separate contract with another provider.

• whether they can take over an existing or unfinished system after reviewing code and architecture
• how changes are tested before release to production
• what post-launch support looks like and how issues get prioritized
• whether the team covers the roles the project actually needs, from architect to QA
• how access, passwords, and documentation are handled at project closeout

Impact on staff and users#

Digitalization changes how staff work who previously relied on paper forms or separate spreadsheets, so the impact on people matters as much as the technical build. Staff need to understand, ahead of time, what changes in their day-to-day work — not find out only at launch. Without that explanation, resistance often appears, not because the solution is poor, but because the change feels imposed without reasons given.

The same applies to the institute's users, who need to understand what's expected of them once they switch to filing applications or tracking requests digitally. A transition period where both a digital and a paper route exist lowers the risk that older or less digitally confident users lose access to the service. In the public sector, where the institute serves every citizen, a gradual rollout often matters more than launch speed.

Staff training should attach to the actual tasks they'll perform in the new system, not a general walkthrough of every feature they may never use. Short, targeted training that follows each department's real workflow shows staff exactly how their work changes and cuts down on questions once the system goes live. It also helps to hold a short check-in after the first few weeks of use, where staff raise whatever is still unclear, before such questions pile up and slow down daily work.

Maintenance and support after go-live#

Going live isn't the end of a digitalization project — it's the start of a period where bugs get fixed, the system gets updated, and it gets adapted to how the institute's work changes. Before launch, the institute should decide who takes on that role: its own IT team, the provider, or a mix of both. That decision shapes how fast issues get fixed and how requests for further development get handled once the system is already in use.

Post-launch support is best sorted by priority of handling, since without an agreed tiering, every issue reopens the debate over how urgent it is and who should fix it. The institute and provider write that tiering into the support contract before launch, so it's clear to everyone involved from day one of use. Issues and requests are usually grouped into four tiers:

Response times for each tier are agreed in the support contract and vary with how critical the system is to the institute's operations, so a single universal response time can't be stated in advance. What matters is agreeing the priority tiers before launch, since staff and provider otherwise disagree, the moment the first serious issue appears, on how urgent it is and how fast it needs fixing.

Beyond fixing bugs, post-launch support also covers technical and security updates that keep the system from becoming an easy target for known vulnerabilities over time. In the public sector, where systems often stay in use for years, regular maintenance is what keeps digitalizing a public institute a sound investment rather than a risk that grows with every year left unpatched.

• outage: the system or a key part is down, handled with top priority
• disruption: the system runs but a specific function doesn't, handled by agreed priority
• defect: a minor issue with no impact on operations, scheduled for the next release
• request: a change or upgrade, scoped and scheduled by agreement

What determines the cost of digitalizing a public institute?#

The cost of digitalizing a public institute isn't a fixed number — it's set after reviewing the scope of work, so the real question is what that scope includes. Cost depends on how many user roles the system needs, how many existing systems need connecting, and the condition of the data that needs migrating, not on a general estimate of the institute's size.

Cost is further shaped by whether the project sits in the public sector with audit-trail and compliance requirements, whether it needs a mobile component, how much AI functionality is involved, and what infrastructure requirements apply, such as high availability. The extent of testing, including any independent QA, and the level of post-launch support also show up in the final price, not just the cost of building the software itself.

That's why a short analysis that breaks the scope into blocks, each one estimable and deliverable on its own, is worth doing before pricing. It lets the institute compare bids on the same scope of work rather than on a single total figure — something that matters even more under public procurement, where bid comparison has to stay transparent and well-founded for every bidder involved.

A practical example: digitalization in public space#

One concrete public-sector example is the Zdravo Jem project for the Municipality of Sevnica, where a software solution with interactive content was delivered for a public space. The project included a 55-inch touchscreen, kiosk-environment configuration, and integration of software with the hardware on site. It shows that digitalization in the public sector isn't limited to internal information systems — it can also mean interactive content aimed directly at citizens in a public location.

In a project like this, on-site installation and documentation matter as much as building the software itself, since they let the municipality understand and, if needed, manage the system after the project closes. Handing over documentation and providing post-installation support are part of the same scope as development, not a separate add-on that only happens if time and interest allow.

The Sevnica example also shows how software and hardware meet in a single project: configuring the touchscreen and the kiosk environment is as much a part of digitalization as the code that drives it. Institutes planning similar solutions for public spaces should expect, from the start, that the project needs coordinated work on both sides, not just the choice of a single software provider.