-
Company
Company
-
Sectors
Sectors
-
IT solutions
IT solutions
-
Knowledge
-
Contact
Universities need flexibility, not more systems
Heraclitus claimed that the only constant is change. Goethe added that those who do not move forward are inevitably left behind. Today, European higher education functions precisely between these two truths – under increasing regulatory pressure, with increasingly tight budgets and with expectations that change faster than IT systems can keep up.
The result? Universities know that they have to change. Increasingly, however, they are unable to do so - at least not with the tools they have today.
Universities across Europe are using student service systems, ERP platforms, document management tools, HR and payroll software, learning management systems, and a growing list of additional applications to bridge the gaps between them. Despite this extensive infrastructure, many institutions are still unable to respond quickly to regulatory changes, connect data between systems, or launch new digital services without initiating a formal purchasing process that can drag on for months or even years.
Regulatory pressure will not go away
Today, European higher education operates under one of the most demanding regulatory regimes of any sector. In the last decade, universities have had to implement the GDPR and adapt every process related to personal data – from recruitment to scientific research. The EU Web Accessibility Directive has imposed WCAG 2.1 compliance for digital interfaces. In turn, the eIDAS Regulation created the legal framework for qualified electronic signatures, which are expected today in administrative processes - from employment contracts to interinstitutional agreements. In addition, there are constantly changing requirements of the Bologna Process, new reporting obligations imposed by ministries and new data formats required by funding institutions.
Each of these changes is justified. But each also becomes, in practice, another requirement for IT systems that have never been designed with constant change in mind.
The result is easy to predict: makeshift and workarounds. Manual steps added to processes that were supposed to be digital. Spreadsheets functioning alongside the systems that were supposed to eliminate them. Reports to suppliers that return after many months with a refusal or with a valuation that strains the budget.
Why existing systems can't simply be modified
Providers of large ERP systems and student administration systems serve hundreds, and sometimes thousands, of institutions simultaneously. They are not able to permanently and scalably adapt the product to the individual expectations of each university. If each customer had its own version of the system, the vendor would have to maintain hundreds of parallel codebases. Updates, security patches, and changes resulting from new regulations would quickly become unmanageable.
In practice, this means that universities must adapt their processes to the capabilities of the systems, and not the other way around. About 80% of the needs that a standard system covers are handled well. The remaining 20% - institution-specific processes, shaped by its structure, strategic priorities, and a particular combination of research and teaching activities - are poorly or not served at all.
The hidden cost of island apps
When the system cannot be modified, institutions look for other ways. One department orders a separate application. Another team builds something on its own. Yet another reaches for a tool inherited from an earlier project. Each of these decisions separately seems rational. Together, however, they create a distributed digital environment that is costly, inconsistent, and difficult to secure.
Each such island application brings its own interface, its own infrastructure requirements, its own training workload and its own integration challenges. Having to switch between systems to accomplish a single process is no minor inconvenience. It's a source of errors, delays, and daily friction that builds up silently in thousands of interactions every year. And when employee turnover occurs, the cost of onboarding new people to many different environments increases even more.
From a technology investment perspective, financing three separate applications, each supporting only a portion of the process, rarely proves to be more rational than one investment in a flexible platform that can cover all three areas - and change with the needs of the institution.
Electronic signatures: a regulatory requirement hiding a procedural problem
A qualified electronic signature is a good example of how regulatory requirements and day-to-day operational complexity meet in higher education. eIDAS created the legal basis, and institutional rules made qualified signatures a practical requirement for many documents. The challenge is that these documents sit across HR, finance, student, and research systems, each with its own workflow. If e-signatures are managed separately in each system, processes fragment: documents circulate manually, next steps disconnect, and audit trails stay incomplete. The legal requirement is met, but the operational value is lost.
When workflows are unified on one platform, electronic signatures become part of the process rather than an obstacle. Support for multiple signature standards lets institutions meet legal obligations securely and consistently without breaking the workflow.
Low-code as a tool to increase the agility of institutions
Low-code platforms are not a substitute for ERP systems or platforms for student administration. Rather, they cooperate with them: they integrate with them, fill them in and close those operational gaps that standard systems are unable to handle. This is the role platforms such as nAxiom HiEdu Suite are designed to play in higher education environments.
The gist of this proposal is simple: instead of outsourcing a new application every time you need to digitize another process or change an existing one, the institution can build and modify solutions on its own - faster, more iteratively, and with the direct participation of those who understand the process best.
This development model is different from traditional development projects. A low-code implementation team does not have to be extensive. All you need is a technically competent leader, two or three developers who know the platform, and - most importantly - engaged users who really know how the process works. They are not passive recipients of the finished product. They co-create requirements, test prototypes almost on the fly, propose changes and approve the results. And because a prototype can be created in a few hours rather than a few weeks, the feedback loop becomes short enough to have a real impact on the quality of the final solution.
This is not a minor improvement. It's a way to eliminate one of the most persistent sources of technology project failure in higher education: a situation where a product delivered meets a specification written down two years earlier - for an institution that has since changed.
One environment, many processes
A well-designed low-code platform creates one coherent environment where applications from different areas use a common interface, a common security model, and the same integration layer. Thanks to this, the person working on student mobility, grant administration, room reservation or HR processes moves in one environment - because it really is one environment.
For universities with complex structures-faculty, affiliated institutes, satellite campuses, and technology transfer centers-a multi-tenant platform allows you to centrally manage a common infrastructure while maintaining full data separation across entities. One application server, one database infrastructure, common licensing – while maintaining the operational independence of each part of the organization.
Interoperability with existing systems is not an add-on here, but a prerequisite for success. The process can start in the ERP system, go through the low-code platform, and return to the source system with a complete set of data - not as a passive export, but as an active element of the workflow. From the user's perspective, the boundaries between systems simply begin to disappear.
Build internally or collaborate with a partner
There is no single right model for building applications. The choice depends on IT capacity, process complexity, and how quickly the institution wants to build its own competencies. Universities with strong IT teams can use low-code to build and maintain applications with less dependence on external vendors. The learning curve is usually much gentler than in traditional programming. Others can start with an external partner and gradually transfer knowledge in-house, moving over time from dependence to occasional expert support. In both models, people who truly understand the process must be involved from the start. Otherwise, technology may work correctly while solving the wrong problem.
The competitive value of institutional agility
Universities now compete not only for students, funding, staff, and reputation, but also on the quality of digital experience and the speed with which they respond to new requirements. An institution that can launch services faster, adapt workflows quickly, and meet reporting demands without delay sends a clear signal of capability. This is not mainly about technology, but about organizational capacity: the ability to adapt, build, and respond without unnecessary delay. In higher education, that capacity has become a real competitive asset, and low-code platforms are one of the most practical ways to strengthen it.