Un operador privado de aguas detecta una caída de presión en un ramal a las tres de la madrugada. El jefe de guardia abre su sistema de Gestión de Mantenimiento Asistido por Ordenador (GMAO), localiza el activo, genera la orden de trabajo y entonces empieza el problema de verdad: la plataforma le dice qué elemento ha fallado, pero no qué acometidas quedan sin servicio aguas abajo, ni qué válvulas hay que cerrar para aislar el tramo con el menor número de afectados. Esa información no está en el GMAO. Está en la cabeza del técnico veterano que conoce la red de memoria, o en un plano impreso colgado en la pared de la sala de control.

Este escenario se repite en cualquier operador con activos repartidos por el territorio: una cartera de plantas fotovoltaicas, una red logística con varias plataformas, un polígono industrial privado, una concesión de aguas a escala media. El GMAO funciona, registra órdenes, acumula histórico y mide indicadores. Pero hay una clase entera de preguntas operativas que no sabe responder, y son precisamente las que más cuestan dinero durante una incidencia.

El activo como registro frente al activo como nodo de red

La mayoría de plataformas GMAO del mercado son agnósticas al territorio. Modelan cada activo como una fila en una tabla: identificador, descripción, ubicación, criticidad, historial. La ubicación, en el mejor de los casos, es un par de coordenadas o una dirección. El sistema sabe dónde está cada cosa, pero no entiende cómo se relacionan las cosas entre sí. Una bomba y la válvula que la aísla son dos registros sin más vínculo que pertenecer a la misma instalación. La red, como estructura lógica con conexiones, sentido de flujo y dependencias, no existe para el software.

Para una sola planta compacta, esa carencia es asumible. El jefe de mantenimiento tiene la instalación en la cabeza y el GMAO le basta como cuaderno de bitácora digital. El problema aparece cuando los activos se distribuyen: decenas de kilómetros de red lineal, instalaciones separadas, ramales que dependen unos de otros. Ahí la pregunta deja de ser "qué le pasa a este activo" y pasa a ser "qué arrastra el fallo de este activo", y un GMAO genérico no tiene forma de calcularlo.

La diferencia técnica está en cómo se almacena la geografía. Un sistema con topología espacial nativa no guarda las posiciones como texto plano, sino con tipos geográficos y operadores que entienden relaciones: intersección, contención, distancia y, sobre todo, conectividad de red. Es el enfoque de motores como PostGIS, que permiten resolver con una consulta lo que de otro modo exige una persona con un plano. Ante el corte virtual de una válvula o un nodo, el sistema devuelve la lista de elementos afectados aguas abajo sin que nadie tenga que programarlo en el momento.

Las señales de que el GMAO genérico se ha quedado corto

Hay indicios concretos, no opiniones, de que una operación ha superado lo que su herramienta puede dar. El primero es la existencia de un sistema paralelo: si para responder a "qué queda afectado" alguien abre un QGIS, un Excel de tramos o un plano escaneado, la operación está manteniendo dos verdades sobre los mismos activos. La segunda señal es la dependencia de personas clave. Cuando el conocimiento de la topología de la red vive en la experiencia de uno o dos técnicos, la baja, la jubilación o las vacaciones de esa persona se convierten en un riesgo operativo real, no teórico.

La tercera señal es el coste de cualquier consulta espacial. Preguntas legítimas y frecuentes —qué activos caen dentro de la zona de una obra programada, qué instalaciones están a menos de equis metros de un punto de incidencia, qué tramo concentra más correctivos por kilómetro— requieren una tarde de trabajo manual cruzando exportaciones. La cuarta es el reporting: cuando los indicadores que la dirección pide obligan a reconciliar el dato del GMAO con el dato del GIS, el cierre de mes se alarga y la confianza en las cifras baja.

Por qué la capa GIS tiene que ser nativa, no un añadido

La respuesta habitual del mercado es acoplar un GIS al GMAO mediante una integración: una barra de herramientas que sincroniza dos sistemas y mantiene los activos "alineados" entre ambos. Funciona, pero crea exactamente el problema que se quería evitar: dos fuentes de verdad que hay que reconciliar, dos licencias, dos modelos de datos y un punto de fallo en la sincronización. La alternativa es que la capa geoespacial y la operativa de mantenimiento compartan el mismo modelo desde el origen, de modo que una orden de trabajo y la geometría del activo no sean dos copias enlazadas, sino el mismo dato visto desde dos ángulos.

Esa integración nativa es la que permite, además, dos cosas que un operador con activos distribuidos valora por encima de la cartografía bonita. La primera es trabajar en campo sin depender de la cobertura: el operario en una cámara subterránea, en un parque eólico aislado o en un tramo de red sin señal registra la intervención sobre el mapa y la sincroniza al recuperar conexión, sin libretas ni transcripciones posteriores. La segunda es la independencia del proveedor: si los datos entran y salen en formatos geoespaciales estándar —los que define el Open Geospatial Consortium, como GeoPackage o GeoJSON—, la operación no queda atrapada en una plataforma concreta. Maptainer se construye sobre esa premisa de modelo único GMAO + GIS, pero el criterio es válido para evaluar cualquier herramienta: la portabilidad del dato es una característica técnica, no un argumento comercial.

Qué cambia, y cómo se mide

La traducción de todo esto a la operación es directa y medible. El tiempo medio de reparación (MTTR) durante incidencias depende, en redes distribuidas, tanto del tiempo de desplazamiento como del tiempo de diagnóstico de afección. Si el sistema entrega la lista de afectados y la secuencia de aislamiento en segundos, la cuadrilla sale con un plan en vez de improvisarlo. La calidad de la comunicación interna y con el cliente durante el incidente mejora por la misma razón. Y el conocimiento de la red deja de ser patrimonio de una persona para convertirse en un activo de la organización, que es justamente lo que pide cualquier sistema de gestión alineado con la norma ISO 55000:2024.

La pregunta útil para cualquier responsable de operaciones que esté evaluando una plataforma no es si tiene mapa. Casi todas lo tienen. La pregunta es esta: ante un corte simulado en un nodo concreto, ¿el sistema me devuelve la lista de activos afectados aguas abajo sin que yo tenga que exportar a otra herramienta? Si la respuesta exige salir del GMAO, lo que hay sobre la mesa es un GMAO con un mapa encima, no un GMAO con GIS.