La cara B de la universidad digital: procesos en papel, datos duplicados y equipos al límite.

En un post anterior mirábamos la universidad desde los ojos del alumnado: esa generación que la compara con Netflix y se encuentra saltando entre varios sistemas para un solo trámite.

La conclusión es que el problema no está en la app, sino en la capa que hay debajo. Ese "debajo" tiene un lado que el alumno no ve, y es donde profundizamos en este artículo: la trastienda, la sala de máquinas donde el personal de la universidad sostiene, a mano, lo que la fachada digital promete de puertas afuera.

Porque el mismo dato que al alumno le toca escribir varias veces, alguien, dentro de la universidad, también lo teclea de manera repetida. Y esa persona no es el villano de esta historia: es su principal víctima.

Varios sistemas, varias versiones del mismo alumno y ninguna definitiva

La información en la universidad suele vivir fragmentada en silos por sistema. Admisiones tiene la suya en el CRM de captación; secretaría, en el sistema de gestión académica; el cobro, en la plataforma de pagos; la actividad docente, en el campus virtual...

Cada uno manda sobre su parcela y ninguno conoce el estado de los demás. El alumno es una sola persona, pero dentro de la universidad existen varios registros que divergen entre sí, se actualizan a ritmos distintos y nunca se han cruzado contra un identificador común.

No es un problema abstracto de modelo de datos. Es la razón por la que un tutor que quiere entender la situación de un alumno (cómo va, si ha pagado, si pidió una beca, si da señales de abandono…) tiene que abrir varias pantallas y reconstruir a mano una historia que ningún sistema le cuenta entera.

Es la razón por la que, cuando dos departamentos discuten una cifra, la reunión se centra en arbitrar qué sistema es la fuente buena. Y es la razón por la que las decisiones de rectorado se toman, más de lo que se admite, sobre exportaciones parciales a Excel en vez de sobre una vista consolidada.

El personal como middleware humano

Cuando dos sistemas no exponen una interfaz común, hace falta una capa intermedia que traduzca entre ambos: un middleware. En muchas universidades, ese middleware es una persona.

Es quien exporta un listado del sistema de admisiones y lo importa en el de gestión académica. Quien reintroduce a mano los datos del alumno del CRM a la plataforma de pagos porque no hay integración entre ambos.

Quien mantiene la hoja de cálculo paralela (la que el equipo usa de verdad) porque el sistema oficial no da la vista que la operativa necesita.

Cada una de esas tareas es un conector implementado en carne y hueso: existe porque, en algún punto, dos sistemas que deberían intercambiar datos se quedaron mudos y alguien tuvo que sincronizarlos a mano.

Es un trabajo invisible y, sobre todo, un recurso cualificado mal empleado: personas con criterio dedicando sus mejores horas a extraer, cuadrar y volver a cargar datos a golpe de copiar y pegar.

Y conviene decir algo con claridad: esto no se resuelve con más formación. En la mayoría de las universidades el equipo domina sus herramientas; el verdadero freno es la adopción, no el conocimiento.

El límite no es que no sepan usarlas, es que la herramienta les obliga a hacer a mano un proceso que debería estar automatizado. Formar mejor a alguien para una tarea que no debería existir no elimina la tarea.

Por qué el mismo dato acaba escrito varias veces

Merece la pena entender el origen, porque es la consecuencia lógica de cómo se construyó el mapa de sistemas.

Las universidades no compraron su tecnología de golpe ni bajo un plano común. La fueron acumulando por capas y por necesidades: primero el ERP académico, luego el campus virtual, más tarde un CRM de captación, después la sede electrónica para cumplir con la administración electrónica.

Coexisten el sistema de gestión académica, el campus virtual, el CRM, la sede, la web institucional, los entornos de Microsoft o Google, biblioteca y recursos humanos, y ninguno se compró, implantó o se gobierna pensando en los demás.

Cuando toca integrarlos, la vía por defecto es el punto a punto: un puente a medida entre el sistema A y el B, otro entre el B y el C, otro entre el A y el C. Es una vía que no escala.

Con cuatro sistemas los puentes son manejables; con doce se convierten en una maraña que nadie mantiene y que se rompe en cadena cada vez que uno de ellos se actualiza.

Llega un punto en que sale “más barato” absorber la diferencia con una persona que construir y mantener otra integración frágil. Así es como el trabajo manual deja de ser una chapuza puntual y se consolida como la arquitectura de integración de facto.

A esto se añade un límite que ya apuntábamos en el post anterior: buena parte de las plataformas compartidas sobre las que se apoyan las universidades solo permiten incrustar servicios mediante iframes o webviews, sin exponer APIs propias sobre las que integrar de verdad.

Comparten pantalla, pero no comparten los datos. Y encima está la capa de permisos: alumnos, PDI, PAS y externos conviven bajo un mismo modelo de roles que no encaja bien con ninguno, de modo que las excepciones se acaban resolviendo, otra vez, a mano.

El resultado es que el dato del alumno no tiene una única fuente de verdad. Se escribe en admisiones, se replica en secretaría, se vuelve a teclear en pagos. Tres veces el mismo dato son tres oportunidades de introducir una inconsistencia y ninguna forma fiable de saber cuál de las tres versiones es la buena.

La factura que no aparece en ningún presupuesto y que todos pagan

Esta trastienda tiene un coste real, aunque no figure en ninguna partida. Lo más visible es el tiempo, pero debajo hay costes más caros y más silenciosos:

• El error humano, que en un proceso manual y a suficiente volumen no es un riesgo sino una certeza estadística: se propaga por los sistemas que beben de ese dato hasta que alguien lo detecta (o hasta que lo detecta el alumno, que es peor).
• La inconsistencia entre fuentes, que convierte cada dato en objeto de negociación entre áreas.
• Y el más caro: decisiones tomadas sobre información incompleta, porque no hay vista consolidada y cada quien decide con el trozo que le tocó ver.

Hay además una capa normativa que aprieta y que vuelve esto cada vez menos sostenible. La LOSU, el Esquema Nacional de Interoperabilidad, el RGPD y el Reglamento de IA no son recomendaciones: son obligaciones crecientes.

Un dato disperso en varios silos, sincronizado a mano y sin trazabilidad de quién lo modificó, cuándo y con qué base, es un dato difícil de gobernar y casi imposible de auditar.

Y por encima de todo, el coste de oportunidad. Un equipo que gasta su capacidad en mantener sincronizados los sistemas (en hacer de pegamento entre piezas que no encajan) es un equipo que no está trabajando en detectar a tiempo un abandono, en rediseñar un proceso ni en atender lo que de verdad importa.

Cuando el dato se mueve sin que nadie lo empuje

Conviene aterrizar el escenario opuesto, porque no es una utopía: es lo que ya se está construyendo en varias universidades españolas.

Un alumno escribe "necesito el certificado de notas para una beca" y el proceso se resuelve solo: se genera, se firma y se envía, sin abrir un formulario ni pasar por back office.

Un tutor consulta el historial completo de un alumno y recibe una respuesta única y coherente, no varias pantallas que tiene que cruzar de cabeza. El dato del estudiante se captura una sola vez, en el momento del ingreso, y a partir de ahí viaja solo: el alta en admisiones dispara el alta académica, que activa el expediente, que conecta con pagos, sin que nadie vuelva a teclearlo. Cuando algo cambia, cambia en un único sitio y se propaga al resto.

La diferencia no está en tener sistemas "mejores", sino en cómo se conectan. En lugar de la maraña de puentes punto a punto, una capa de orquestación por la que el dato fluye una sola vez y queda disponible, gobernado, para todos los procesos que lo necesiten.

Y sin arrancar lo que ya existe: el sistema académico, el campus virtual y el CRM no se reemplazan, se orquestan sobre una base común que los pone a hablar. Encima de esa capa, lo repetitivo se automatiza y lo que exige criterio queda para las personas.

Cambio de rol en los equipos: de teclear datos a tomar decisiones

Cuando lo mecánico se resuelve en la plataforma, el rol del equipo cambia de naturaleza. El PAS deja de ser el conector humano que introduce datos y pasa a supervisar que el sistema los trata bien; deja de ejecutar el trámite en cadena para ocuparse de la excepción, del caso que no encaja en ningún flujo y necesita criterio.

No es que trabaje más rápido haciendo lo mismo: es que deja de hacer lo que nunca debió ser su trabajo.

Esto importa especialmente ahora que la IA agéntica entra en la conversación, porque la pregunta que angustia a todo el mundo "¿esto sustituye a mi equipo?" tiene aquí una respuesta concreta.

Un agente que automatiza el certificado de notas no sustituye a secretaría: la libera de emitir mil certificados para que atienda a los mil alumnos. El agente puede proponer becar a un estudiante en riesgo, pero la decisión final la confirma una persona, y queda registrado quién decidió qué y por qué.

El rol no desaparece: sube de nivel, de la tramitación a la supervisión y el criterio. Y ese salto solo es posible si por debajo hay una capa que gobierne quién puede hacer qué y deje rastro de cada acción; algo que un mosaico de sistemas sueltos, cada uno con su propia lógica de permisos, no puede ofrecer.

Alumnado, equipo y dirección sufren el mismo problema… sin saberlo

La experiencia rota que sufre el alumno y la carga manual que soporta el equipo no son dos problemas: son el mismo, mirado desde dos ventanas. Los dos nacen de una tecnología que se fue sumando sin un plan común y de una dependencia de plataformas que la universidad no termina de controlar.

El alumno lo vive como fricción; el equipo, como sobrecarga; el rectorado, como decisiones a ciegas y riesgo normativo. Tres síntomas, una sola causa.

Por eso ninguno se arregla por separado, y desde luego no pidiéndole al equipo que corra más ni sumando otra herramienta al mosaico. Se arregla en los cimientos: recuperando el control del dato y de cómo las piezas encajan entre sí.

Al final, lo que está en juego no es el tiempo, es el talento: en qué lo gasta un equipo, si en pelear con sus propios sistemas o en las personas para las que la universidad existe.

Si mañana dirección necesitara saber cuántos alumnos están hoy en riesgo de dejarlo, ¿saldría de un sistema, o habría que pedirle a alguien que cruzara varias hojas de cálculo para averiguarlo?

La respuesta a esa pregunta dice más sobre lo digital que es una universidad que cualquier cosa que se vea en su web.