Virtualising Operations Without Building Capability Is Just Moving the Problem Online

The DIVO model, documented and presented at EUNIS 2025 by Simon Whittemore, is built on a staged innovation process that begins with a hypothesis rather than a solution. Before any technology is selected or deployed, DIVO defines the problem it is attempting to solve, identifies the stakeholders affected, and establishes measurable criteria for success. Only once those foundations are in place does the technical phase begin. This sounds obvious. It is also almost entirely absent from how most European universities approach digitalisation of their operations.

The Jisc Maturity Model for digital transformation in higher education describes three stages of institutional progress: reactive, proactive, and integrated. Most UK and European universities, according to Jisc's own assessment data, sit between reactive and proactive - they respond to digital change as it arrives rather than anticipating and designing for it. The institutions at the integrated stage share a characteristic: their staff understand not just how to use digital systems, but how those systems relate to the processes they are designed to support. The technology is not layered on top of existing work patterns. The work pattern was redesigned before the technology arrived.

Gartner's 2025 research found that 76% of higher education CIOs planned to increase cloud investment, while 38% planned to reduce legacy infrastructure funding. That shift - from on-premises systems to cloud-based services - is not simply a technology migration. It changes what skills the staff managing those systems need. Building and configuring are different activities. Managing vendor relationships for a SaaS platform requires different competencies than maintaining an internally developed system. As Gartner noted, only 4 in 5 executive leaders outside IT consider digital leadership part of their job - yet the infrastructure decisions made in IT ripple through every administrative function. When operations virtualise without the people operating them understanding the new logic, the virtualisation creates new fragility rather than new resilience.

The DIVO programme illustrates this clearly. One of its flagship projects deployed AI assistants for the university's international office, managing a high volume of student prospect inquiries globally. Over a two-month period, the AI handled 313 conversations, saving staff over 4,200 minutes and enabling them to redirect their time to higher-value activities. What made this work was not the AI tool itself - equivalent tools are widely available. What made it work was that the international office staff co-designed the implementation, understood the escalation logic, and knew exactly what the AI could and could not do. They were not users of a system someone else had configured. They were owners of a capability they had helped build.

Finland's CSC research on AI transformation in HEIs found a consistent pattern: the institutions that managed AI adoption most effectively were those that had invested in what the AITO Framework calls the 'ability to change layer' - the organisational competencies that allow new technologies to be evaluated, piloted, and integrated without requiring external consultants at every stage. That layer does not emerge from a software purchase. It is built through structured development of the people who will manage, configure, and adapt the technology over its lifecycle.

The practical principle is this: every operational virtualisation project should carry an explicit capability question alongside its technical specification. What do the staff running this function need to know that they do not know now? What needs to be documented so the institution does not depend on a single person's memory? What competencies need to exist in-house so that the institution can evolve the function without calling a vendor? These are not supplementary questions. They are the difference between a project that delivers and one that simply closes.