¿Desarrollar tu propio GMAO con IA?

Con las herramientas de generación de código actuales, montar un prototipo que liste activos y órdenes de trabajo es cuestión de días. Eso ha hecho que la pregunta aparezca en muchas empresas: si podemos construirlo nosotros, ¿por qué comprarlo?

Es una pregunta legítima y merece una respuesta honesta, no comercial. Lo que sigue es qué es fácil, qué no lo es, y en qué casos hacerlo propio tiene sentido de verdad.

Lo que la IA resuelve bien

Conviene reconocerlo sin rodeos, porque es mucho.

El CRUD. Pantallas de alta, listados, filtros, formularios y relaciones. Lo que antes eran semanas de trabajo repetitivo hoy es bastante rápido.

La estructura inicial. Modelo de datos razonable, autenticación básica, despliegue. Un prototipo funcional en poco tiempo.

La parte visual. Interfaces correctas sin necesitar un diseñador.

Si tu necesidad es un registro ordenado de equipos y trabajos para una operación pequeña y estable, es una opción real. No hay que descartarla por principio.

Lo que no resuelve, y es donde está el trabajo

El problema es que un GMAO no es un CRUD. La parte que cuesta no es la que se genera rápido.

El modo sin conexión de verdad. No es guardar pantallas: es una base local, una cola de acciones, resolución de conflictos y un comportamiento definido cuando algo falla al sincronizar —que no puede ser perder el trabajo de una mañana en silencio—. Es uno de los problemas más difíciles de la informática aplicada, y el mantenimiento ocurre justo donde no hay cobertura.

La generación de preventivo. Parece un cron y no lo es. Hay que resolver periodicidades múltiples sobre el mismo activo, cada una con su recuento; comprobar festivos y disponibilidad del técnico antes de generar; resolver la gama en cascada por activo, modelo, subfamilia y familia; y contemplar el disparo por contador cuando una lectura supera un umbral. Cada una de esas reglas viene de un caso real que alguien descubrió a base de errores.

El control de acceso. Perfiles, visibilidad documental por rol, qué ve cada cliente y cada proveedor. Y la trazabilidad: quién creó, modificó o eliminó cada cosa, con borrado recuperable.

Las integraciones. Cada ERP tiene su forma de hacer las cosas. Un conector que funcione en producción no es una llamada a una API: es gestión de errores, reintentos, conciliación y años de casos raros.

El histórico como prueba. Que un registro sirva ante una reclamación o una inspección exige que nadie pueda alterarlo sin dejar rastro y que cada trabajo esté a nombre de quien lo hizo.

El coste que no se calcula

El desarrollo inicial es la parte pequeña. Lo que se subestima es lo de después.

El mantenimiento del propio sistema. Actualizaciones de seguridad, dependencias que quedan obsoletas, cambios de las plataformas móviles. Es trabajo permanente, no un proyecto.

El soporte. Cuando algo falla un viernes por la tarde y la persona que lo programó está de vacaciones o ya no trabaja aquí.

La dependencia de una persona. Es el riesgo más serio y el menos visible. Un sistema hecho a medida por alguien concreto se convierte en un problema el día que esa persona se va, porque nadie más entiende por qué las cosas están así.

La infraestructura. Servidor, copias de seguridad, vigilancia, disponibilidad.

Lo que no sabes que necesitas. Las funciones que no están en tu primera lista porque todavía no has tropezado con el problema que las hizo necesarias.

Y sobre la IA dentro del producto

Merece la pena separar dos cosas que se mezclan en esta conversación: usar IA para construir el sistema, y tener IA dentro del sistema.

En GMAO CLOUD la IA hace cosas acotadas y verificables: un asistente que responde sobre tus activos, tus planes y tu histórico —también dentro de la app de técnicos—; lectura de documentos, de modo que el parte que te manda un proveedor en PDF se convierta en datos sin teclearlo; ayuda con la redacción de los textos de la orden; y traducción de tus propios catálogos.

Dos cosas importan más que la lista: propone, no ejecuta —no cierra órdenes ni asigna trabajo—, y cada función tiene su interruptor, con la mayoría apagadas de fábrica. Está detallado en la IA en GMAO CLOUD.

Y lo de siempre, que aplica igual a un sistema propio: un asistente sobre un histórico vacío no sabe nada. La IA no sustituye al registro, se apoya en él.

Cuándo sí tiene sentido hacerlo propio

Hay casos en que la respuesta es que sí, y conviene decirlos.

Cuando tu proceso es genuinamente atípico y ningún producto del mercado lo contempla, porque tu negocio es esa particularidad.

Cuando el sistema es una pieza de tu producto, no una herramienta interna.

Cuando tienes equipo de desarrollo propio y estable, con capacidad para mantenerlo durante años, y el mantenimiento es parte de tu núcleo de negocio.

Fuera de esos casos, lo habitual es que el prototipo funcione, se use unos meses, y se abandone cuando aparece la primera exigencia real: un técnico sin cobertura, una inspección que pide el expediente o un cliente que quiere su portal.

Una opción intermedia que se olvida

No es todo o nada. Si lo que te empuja a construir es una necesidad concreta que un producto no cubre, existe la vía de conectarte: hay API REST pública y acceso SQL para leer y escribir sobre el sistema desde tu propio desarrollo.

Así te quedas con lo difícil resuelto —el modo sin conexión, el preventivo, los permisos, la trazabilidad— y construyes solo tu particularidad encima. Es casi siempre la mejor relación entre control y coste.

Cómo decidirlo

Haz la lista de lo que necesitas de verdad —no de lo que estaría bien— y marca qué parte es CRUD y qué parte es de las difíciles. Si la mayoría es lo segundo, el prototipo no te va a ahorrar el trabajo: te lo va a aplazar.

Y calcula el coste a tres años, no a tres meses, con el mantenimiento y el soporte dentro.

Si quieres contrastar tu caso concreto, puedes escribirnos o solicitar una demo para ver qué parte de tu lista ya está resuelta.