¿Desarrollar una GMAO propia con IA? Lo que debes saber antes de empezar

“¿Y si desarrollamos nuestra propia GMAO?”

Hace unos años, esta propuesta solía venir acompañada de un “conozco a alguien que sabe programar”. Hoy el escenario ha cambiado: tenemos inteligencia artificial, herramientas low-code y no-code y plataformas capaces de generar una aplicación funcional en muy poco tiempo.

Y hay que reconocerlo: desarrollar software nunca había sido tan accesible como ahora.

Con conocimientos técnicos y herramientas de IA es perfectamente posible crear rápidamente una aplicación que permita registrar activos, abrir órdenes de trabajo (OT), asignarlas a técnicos y consultar su estado.

Así que la pregunta ya no es si puedes desarrollar tu propia GMAO.

Probablemente puedas.

La pregunta importante es otra:

La IA ha cambiado el desarrollo de software. Y eso es positivo

La inteligencia artificial no es el enemigo del desarrollo profesional de software. Todo lo contrario.

Bien utilizada permite analizar información, generar código, automatizar tareas repetitivas, detectar posibles errores y acelerar considerablemente determinados procesos de desarrollo.

En GMAO CLOUD también utilizamos IA.

Nos ayuda a desarrollar más rápido y a dedicar más tiempo a analizar cómo debe funcionar el producto.

Pero hay una diferencia importante entre utilizar IA para desarrollar software y delegar en la IA las decisiones sobre cómo debe construirse un producto.

En nuestro caso, el código generado o asistido mediante IA pasa por supervisión técnica, revisión por perfiles con experiencia —incluyendo un perfil senior con más de 25 años desarrollando software en diferentes tecnologías— y code review del equipo.

No incorporamos un cambio simplemente porque la IA diga que funciona.

La IA puede ayudarte a escribir código. La experiencia te ayuda a saber qué código necesitas, qué puede fallar y qué puede ocurrir cuando ese código lleve cinco años funcionando.

“Nuestro informático puede hacerlo”

Es posible.

De hecho, si tienes en tu empresa una persona que administra sistemas, trabaja con el ERP, programa integraciones y además utiliza herramientas actuales de IA, probablemente tenga conocimientos suficientes para construir una primera versión.

Imaginemos el encargo:

“Necesitamos algo sencillo. Una tabla de clientes, otra de activos, usuarios, técnicos y órdenes de trabajo. Que los técnicos puedan indicar lo que han hecho y adjuntar alguna fotografía.”

No parece especialmente complicado. Y posiblemente no lo sea.

Hasta que la aplicación empieza a utilizarse de verdad.

Entonces aparecen preguntas que probablemente no estaban en la primera definición:

• ¿Quién controla los permisos de cada usuario?
• ¿Puede un técnico consultar las OT de otro?
• ¿Puede un cliente acceder a información de otro cliente?
• ¿Qué ocurre si alguien elimina accidentalmente un activo?
• ¿Cómo mantenemos todo su histórico?
• ¿Quién controla las copias de seguridad?
• ¿Dónde almacenamos fotografías y documentos?
• ¿La aplicación debe funcionar fuera de la red de la empresa?
• ¿Qué ocurre cuando un técnico trabaja sin cobertura?
• ¿Necesitamos Android e iOS?
• ¿Quién mantiene las aplicaciones cuando Apple o Google cambian sus requisitos?
• ¿Quién monitoriza que todo esté funcionando?
• ¿Quién actualiza dependencias y componentes?
• ¿Quién revisa la seguridad?
• ¿Quién atiende a los usuarios?

Y hay una pregunta especialmente importante:

¿Quién se encargará de todo esto si la persona que desarrolló la aplicación cambia de puesto o deja la empresa?

De repente, aquel pequeño desarrollo interno se ha convertido en un producto de software que la empresa tiene que mantener.

El reto no es hacer una GMAO que funcione con 1.000 OTs

Esta es una de las lecciones que solo aparecen cuando un software empieza a utilizarse de verdad.

Una aplicación puede funcionar perfectamente durante las pruebas. Puede funcionar perfectamente con 100 OTs. Y con 1.000.

Pero eso no significa que su arquitectura vaya a responder igual cuando tenga que gestionar 10.000, 100.000 o cientos de miles de órdenes de trabajo junto con años de históricos, fotografías, documentos, activos, mantenimientos preventivos y usuarios trabajando simultáneamente.

Lo hemos visto en proyectos reales.

Sistemas que aparentemente funcionaban correctamente empezaban a mostrar importantes limitaciones de rendimiento cuando aumentaba el volumen de información.

También hemos recibido empresas que habían implantado previamente otras soluciones de mantenimiento y que, después de trabajar durante meses con ellas, buscaron una alternativa porque el rendimiento con su operativa y volumen real de datos no era el esperado.

La escalabilidad rara vez es lo primero que se comprueba en una demo.

Pero puede convertirse en uno de los factores más importantes después de varios años de utilización.

La primera versión puede ser barata. El coste real viene después

Uno de los principales argumentos para desarrollar internamente suele ser económico:

“Si lo hacemos nosotros, nos ahorramos pagar una licencia todos los meses.”

Pero esa comparación deja fuera gran parte del coste.

Para comparar correctamente desarrollar frente a contratar una GMAO hay que calcular el coste total de propiedad (TCO).

Desarrollar es solo una parte

Una GMAO propia puede requerir:

• Análisis funcional y diseño.
• Desarrollo backend y frontend.
• Base de datos.
• Infraestructura.
• Almacenamiento de documentos y fotografías.
• Copias de seguridad y recuperación ante fallos.
• Certificados SSL.
• Seguridad y actualizaciones.
• Monitorización.
• Gestión de usuarios, roles y permisos.
• Aplicaciones móviles.
• Funcionamiento offline.
• Publicación y mantenimiento en las stores.
• Integraciones con ERP y otros sistemas.
• API.
• Pruebas.
• Correcciones.
• Soporte a usuarios.
• Documentación.
• Evolución funcional.
• Actualización de tecnologías y dependencias.

Y todo ello debe mantenerse mientras exista la aplicación.

El coste tampoco es únicamente económico.

Si la persona responsable de sistemas dedica una parte importante de su jornada a desarrollar y mantener la GMAO, esas son horas que deja de dedicar a infraestructura, ERP, seguridad, soporte interno o cualquier otra responsabilidad para la que originalmente fue contratada.

“Pero si la hacemos nosotros estará exactamente adaptada a nuestra empresa”

Este argumento tiene sentido.

Un desarrollo propio puede diseñarse exactamente alrededor de los procesos actuales de una organización.

Pero existe una segunda cara: solo puedes desarrollar inicialmente aquello que ya sabes que necesitas.

La experiencia de un producto especializado también consiste en haber descubierto necesidades que aparecen después.

Una empresa puede pensar inicialmente que una OT necesita una descripción, un técnico y un estado.

Con el uso aparecen nuevas preguntas: ¿prioridades?, ¿SLA?, ¿tiempos de respuesta?, ¿desplazamientos?, ¿materiales?, ¿almacenes?, ¿firmas?, ¿checklists?, ¿fotografías?, ¿preventivos?, ¿subcontratas?, ¿presupuestos?, ¿permisos de clientes?, ¿diferentes centros?, ¿trazabilidad?, ¿informes?, ¿notificaciones?, ¿integraciones?

Muchas de estas necesidades no aparecen durante la primera reunión.

Aparecen después de miles de operaciones reales.

La ventaja que no puedes programar en un fin de semana: la experiencia

GMAO CLOUD comenzó a desarrollarse como producto en 2016.

Eso significa que detrás de una funcionalidad actual no está únicamente el código necesario para implementarla.

Hay años de feedback de empresas de mantenimiento, industria, retail y otros sectores.

Cada cliente incorpora formas diferentes de trabajar. Unos necesitan controlar técnicos propios. Otros trabajan principalmente con proveedores. Otros necesitan gestionar el mantenimiento preventivo de sus instalaciones. Otros deben justificar ante sus clientes cada intervención realizada.

Cuando una necesidad es común, el producto evoluciona.

Y esa evolución puede beneficiar después al resto de empresas que utilizan la plataforma.

Esto crea algo difícil de replicar mediante un desarrollo interno:

Conocimiento acumulado de producto.

No estás contratando únicamente las funcionalidades que necesitas hoy.

También estás aprovechando las decisiones, aprendizajes y mejoras derivadas de años trabajando específicamente en gestión del mantenimiento.

Una GMAO también tiene que salir de la oficina

Hay otro aspecto que suele infravalorarse: el técnico.

El software de mantenimiento no termina en la pantalla del responsable de mantenimiento.

En muchos casos empieza precisamente cuando el técnico sale de la oficina.

Necesita consultar sus OTs, desplazarse hasta una instalación, localizar activos, registrar tiempos, utilizar materiales, realizar comprobaciones, adjuntar fotografías y documentar el trabajo realizado.

Desde un móvil.

Y no siempre tendrá buena cobertura.

Por eso una aplicación móvil profesional añade otra capa de complejidad al proyecto.

Hay que desarrollar y mantener la aplicación, adaptarla a diferentes dispositivos, gestionar versiones, mantener compatibilidad con los sistemas operativos y cumplir los requisitos de publicación de Apple y Google.

Y si los técnicos trabajan en ubicaciones con poca o ninguna cobertura aparece además otro reto: el modo offline y la posterior sincronización de información.

Una aplicación web responsive puede parecer una app móvil. No significa necesariamente que resuelva correctamente el trabajo de un técnico en campo.

La infraestructura también forma parte de tu GMAO

Cuando una GMAO se convierte en una herramienta crítica, la pregunta deja de ser únicamente dónde instalarla.

Hay que pensar qué ocurre cuando algo falla.

• ¿Existen copias de seguridad?
• ¿Son copias remotas?
• ¿Se comprueba que pueden recuperarse?
• ¿Qué ocurre si falla el servidor?
• ¿Cómo se controla el almacenamiento?
• ¿La comunicación está cifrada?
• ¿Quién instala y renueva los certificados?
• ¿Quién monitoriza los servicios?
• ¿Quién aplica actualizaciones de seguridad?
• ¿Puede accederse de forma segura desde fuera de la red corporativa?

Todo esto también forma parte del producto.

Aunque el usuario nunca lo vea.

¿Y si utilizamos low-code, no-code o una plataforma creada con IA?

También puede ser una opción.

Las nuevas herramientas permiten crear aplicaciones internas con una velocidad que hace pocos años parecía imposible. Y seguirán mejorando.

Pero nuevamente debemos separar dos conceptos:

Crear una aplicación y mantener un sistema crítico de gestión.

Que una herramienta permita generar rápidamente formularios, tablas, automatizaciones e interfaces no elimina las necesidades relacionadas con escalabilidad, seguridad, continuidad, soporte, movilidad, integraciones o mantenimiento.

Lo mismo ocurre con nuevas soluciones GMAO recién llegadas al mercado.

Que un producto sea nuevo no significa necesariamente que sea una mala opción. Puede ser una solución excelente para determinados escenarios.

Pero si el mantenimiento es una actividad crítica para tu empresa, además de comparar funcionalidades y precio conviene preguntar:

• ¿Cuánto tiempo lleva este producto funcionando en entornos reales?
• ¿Qué volumen de información gestiona?
• ¿Qué ocurre cuando crece?
• ¿Quién hay detrás del producto?
• ¿Cómo se realizan las copias de seguridad?
• ¿Cómo se gestiona la seguridad?
• ¿Existe soporte?
• ¿Cómo se gestionan las actualizaciones?
• ¿Existe una estrategia de continuidad?

La experiencia no garantiza que nunca vaya a ocurrir una incidencia.

Pero sí significa que muchas situaciones ya se han encontrado, analizado y resuelto antes de que tú llegues.

Entonces, ¿nunca tiene sentido desarrollar una GMAO propia?

Sí puede tenerlo.

Imaginemos a José y Javi.

Son dos técnicos, realizan aproximadamente una intervención diaria y actualmente gestionan sus trabajos mediante un Excel.

Quieren registrar clientes, saber qué hicieron la última vez y poder consultar desde el móvil las actuaciones pendientes.

Crear una pequeña aplicación con IA o mediante una plataforma low-code puede ser una solución perfectamente razonable.

Incluso puede ser más adecuado que implantar una plataforma con capacidades que probablemente nunca utilizarán.

El escenario cambia cuando la operativa empieza a depender del sistema.

Por ejemplo, cuando:

• Hay varios técnicos trabajando diariamente en la calle.
• Debes coordinar decenas o cientos de OTs.
• Gestionas el mantenimiento de una fábrica o instalaciones críticas.
• Necesitas planificar una plantilla.
• Tienes compromisos y fechas que cumplir con clientes.
• Debes gestionar mantenimiento preventivo.
• Necesitas conservar el histórico de cada activo.
• Gestionas almacenes y materiales.
• Trabajas con proveedores o subcontratas.
• Tus clientes necesitan acceder al sistema.
• Necesitas integrar la GMAO con un ERP u otros sistemas.
• La pérdida de información tendría consecuencias operativas.
• La aplicación debe seguir funcionando aunque cambie el personal de IT.

En estos escenarios ya no estamos hablando simplemente de sustituir un Excel.

Estamos hablando de una herramienta que forma parte de la operación de la empresa.

Build vs. Buy: haz esta comparación antes de empezar

Antes de decidir desarrollar una GMAO internamente, conviene hacer una comparación completa:

La columna de una GMAO especializada tampoco debe darse por supuesta.

Pregúntale al proveedor.

No todas las GMAO ofrecen lo mismo ni tienen la misma experiencia, infraestructura, soporte o capacidad de evolución.

¿Qué ocurre cuando eliges GMAO CLOUD?

Con GMAO CLOUD el objetivo es que tu empresa se dedique a gestionar mantenimiento, no a desarrollar el software necesario para gestionarlo.

El producto comenzó a desarrollarse en 2016 y ha evolucionado desde entonces con las necesidades y feedback de empresas que lo utilizan en operativas reales.

Nos encargamos de aspectos que normalmente quedan fuera de la primera estimación de un desarrollo interno: infraestructura cloud, actualizaciones, copias de seguridad remotas, conexiones seguras mediante SSL, aplicaciones móviles, modo offline, soporte y evolución continua.

Además, el producto no deja de evolucionar cuando empiezas a utilizarlo.

El feedback de cada empresa ayuda a detectar nuevas necesidades y las mejoras de producto pueden terminar beneficiando a muchos otros clientes.

La IA no hace innecesario el software especializado. Puede hacerlo mejor.

Probablemente estamos al principio de uno de los mayores cambios que ha vivido el desarrollo de software.

La IA permitirá crear aplicaciones más rápido, analizar más información y automatizar procesos que hasta ahora requerían muchas horas.

En GMAO CLOUD queremos aprovechar precisamente esa capacidad.

Pero creemos que la combinación más interesante no es:

IA o experiencia.

Es:

IA + experiencia.

La IA puede acelerar el desarrollo.

Diez años evolucionando un producto te ayudan a decidir qué desarrollar.

Los clientes te ayudan a descubrir qué necesitan realmente las empresas.

Los técnicos te enseñan qué funciona cuando estás delante de una máquina sin cobertura.

Los grandes volúmenes de información te enseñan qué ocurre cuando una base de datos crece.

Los años de soporte te enseñan dónde se equivocan los usuarios.

Y las incidencias que has resuelto te enseñan qué debes prevenir la próxima vez.

Eso no aparece automáticamente al escribir un prompt.

Antes de desarrollar tu propia GMAO, haz las cuentas completas

Si estás valorando desarrollar internamente una GMAO, no queremos decirte simplemente que no lo hagas.

Haz números.

Define qué necesitas hoy, pero intenta también calcular qué necesitarás dentro de tres o cinco años.

Incluye infraestructura, aplicación móvil, seguridad, copias de seguridad, soporte, mantenimiento y evolución.

Y después compara.

Cuéntanos qué estás pensando desarrollar y qué necesita realmente tu empresa.

Podemos enseñarte cómo resolvemos actualmente esos procesos en GMAO CLOUD y ayudarte a comparar el alcance de ambas opciones.

Puede que necesites personalizaciones.

Puede que buena parte de lo que estás pensando desarrollar ya exista.

Y puede que, después de hacer las cuentas completas, mantener tu propia GMAO deje de parecer la opción más económica.