Cómo evoluciona GMAO CLOUD

La evolución de un producto se mira poco al comparar sistemas de mantenimiento, y es de las cosas que más determinan el coste de los próximos cinco años. Un sistema que no cambia se queda atrás; uno que cambia mal obliga a migraciones que nadie presupuestó.

Esto es cómo lo hacemos nosotros, y qué conviene preguntar a cualquiera.

De dónde salen las mejoras

De tres sitios, y el primero pesa más que los otros dos juntos.

De quien lo usa. La mayoría de lo que se incorpora viene de una situación concreta que alguien se encontró: un campo que faltaba, un estado que no existía, un caso que el circuito no contemplaba.

Se nota al mirar el producto de cerca. Que el preventivo compruebe si el día es festivo y si el técnico está disponible antes de generar una orden no es una idea de diseño: es la respuesta a que alguien acabó con revisiones programadas en agosto. Que los estados se puedan marcar como no notificar viene de que las notificaciones se convirtieron en ruido en algún sitio.

Del propio sector. Obligaciones nuevas, formas de trabajar que cambian, sectores con requisitos propios.

De la tecnología disponible, que es el que menos manda. Una capacidad nueva solo entra si resuelve un problema real, no por estar disponible.

Cómo se decide qué entra

Dos criterios.

Que resuelva un problema de varios. Una necesidad muy específica de una instalación concreta no suele entrar en el producto: se resuelve por configuración, o por la vía abierta —API REST y conexión SQL en integraciones— para quien necesite construir encima.

Que no complique lo que ya funciona. Es el criterio que más cosas descarta. Cada opción nueva es una decisión más que alguien tiene que tomar al configurar, y un producto con demasiadas opciones es tan difícil de usar como uno rígido.

Por eso hay funciones que se han descartado varias veces aunque se pidan: porque la versión que se pedía habría hecho más complicado el uso normal.

Lo que no hacemos

No cobramos por versión ni por módulo nuevo. Las mejoras llegan a los tres planes; la diferencia entre ellos está en el acompañamiento y los recursos, no en las funciones.

No dejamos versiones atrás. Al estar en la nube no hay «versión antigua» en la que quedarse, que es precisamente el problema que aparece en los sistemas instalados: un cambio mayor deja sin soporte a quien no migra, y salir de ahí exige un proyecto que nadie presupuestó.

No anunciamos lo que no existe. En el código del producto hay cosas empezadas que no tienen uso todavía, y no se cuentan como funcionalidad hasta que funcionan.

Lo que preguntar a cualquier proveedor

Cuatro preguntas que dicen más que un catálogo:

¿Qué pasó la última vez que hubo un cambio de versión mayor? Y quién asumió la migración de los clientes que se quedaron en la anterior. La respuesta describe al proveedor mejor que su web.

¿Qué pasa cuando necesito algo que hoy no está? Las respuestas posibles son tres —se configura, entra en una versión futura, o es un desarrollo facturable—. Las tres son legítimas; mezclarlas no, y hay que saber cuál te dan porque cambia el presupuesto de los próximos años.

¿Las mejoras llegan a mi plan? O solo a los superiores.

¿Cómo saco mis datos? Es la que más incomoda y la más reveladora.

Lo que ha cambiado y se nota

Para que no sea abstracto, tres ejemplos de cosas que hoy están en el producto y que vienen de problemas reales.

El disparo del preventivo por contador. Durante años el plan iba solo por calendario, y eso trata igual a dos máquinas idénticas que no trabajan igual. Ahora un activo puede llevar horas, ciclos o kilómetros con un límite y un porcentaje de aviso: cuando una lectura supera el umbral, la orden se genera sola. Es la diferencia entre revisar por costumbre y revisar por uso.

El aviso por coste acumulado. Sobre un activo se registra su coste de reposición y un porcentaje, y el sistema notifica cuando el gasto en repararlo lo supera. No genera orden —sustituir es una decisión de negocio— pero pone la cifra delante cuando toca mirarla, en lugar de dentro de un informe que nadie abrió.

El conector entre instalaciones, en los dos sentidos, para cuando el cliente y su subcontratista usan los dos el sistema. Viene de ver cuánto trabajo administrativo se iba en conciliar ficheros entre dos empresas que ya tenían el dato.

Ninguno es una idea de producto: los tres son la respuesta a algo que alguien contó.

Lo que sí conviene que cambie

Y conviene decirlo porque un producto que no evoluciona también es un riesgo.

Los sistemas operativos móviles cambian y una app tiene que seguirlos. Las obligaciones normativas de algunos sectores se mueven. Aparecen formas de trabajar que antes no existían —el modo sin conexión completo es una de ellas, y hace diez años casi nadie lo ofrecía—.

Un proveedor que lleva años sin tocar nada no es estable: está parado.

Lo que no cambia

Por encima de las funciones hay decisiones que se mantienen y que conviene conocer, porque condicionan cómo se usa el producto:

Las licencias ilimitadas en los tres planes. El modo sin conexión real en la app de técnicos —no en la de clientes—. Las tres interfaces separadas por rol. Y la configuración por familia con resolución en cascada, que es lo que hace viable gestionar cientos de equipos.

Y una forma de contar las cosas: decir lo que el producto no hace. Que el mantenimiento legal no es un módulo. Que ningún software garantiza el cumplimiento de una norma. Que no hay constructor visual de informes. Que el módulo de obras no es un programa de gestión de obra.

Si quieres proponer algo

Buena parte de lo que hay en el producto viene de alguien que se encontró con un problema y lo contó. Si tienes uno, puedes escribirnos.

Y si lo que quieres es ver cómo está hoy sobre tus propios equipos, puedes solicitar una demo.