Evaluar software de gestión de activos con listas de funcionalidades no funciona. La mayoría de las plataformas en el mercado tiene los mismos módulos en papel: inventario de activos, órdenes de trabajo, indicadores, programa preventivo. Lo que las diferencia no es la lista de capacidades: es si esas capacidades funcionan en la realidad operativa de tu planta, si el equipo técnico las adopta en campo y si los indicadores que genera son los que necesitas para tomar decisiones con datos, no con intuición.
¿Qué problema concreto estás resolviendo?
Antes de evaluar cualquier plataforma, el equipo debe tener claro qué está fallando hoy. No en términos de tecnología, sino de gestión: no sabemos cuánto cuesta mantener cada activo, no podemos identificar qué activos concentran la mayor parte de los paros no planificados, no tenemos historial confiable que permita ajustar el plan de mantenimiento preventivo. Esas son las preguntas que la plataforma tiene que responder. Si no se definen antes de empezar la evaluación, cualquier plataforma va a parecer buena en la demo.
Por qué la claridad del problema define el alcance del software
Un equipo que necesita ordenar su historial y sus órdenes de trabajo no necesita una plataforma de gestión de activos empresarial. Le alcanza con un sistema de implementación rápida y adopción fácil en campo. Un equipo que necesita conectar el monitoreo de condición con la gestión de intervenciones y los indicadores de producción necesita una plataforma con capacidades de integración real, no solo declarada.
El error más común es comprar la plataforma más completa del mercado cuando el problema real es de adopción y de registro consistente. Una plataforma compleja que el equipo técnico no usa genera datos de baja calidad, que generan indicadores poco confiables, que llevan a decisiones basadas en datos malos. Es peor que no tener sistema.
La pregunta correcta para empezar
¿Cuál es la decisión que hoy no puedes tomar porque no tienes el dato? Si la respuesta es "no sé cuánto me cuesta mantener el compresor de la línea 2", el problema es trazabilidad de costos por activo. Si la respuesta es "no sé qué activos voy a fallar la próxima semana", el problema es visibilidad de condición. Esas respuestas definen qué tipo de plataforma necesitas, antes de ver una sola demo.
¿Se adapta a la estructura real de tus activos?
Toda planta tiene una jerarquía: instalación, línea, equipo, subequipo, componente. No todos los sistemas permiten configurar esa jerarquía con el nivel de detalle que la operación necesita. Algunos tienen un máximo de dos o tres niveles. Otros permiten jerarquías profundas pero el proceso de configuración es tan laborioso que la mayoría de los usuarios termina usando la plataforma de forma plana, sin la estructura que hace que los indicadores sean útiles.
Qué evaluar en una demo de configuración de activos
Pedir al proveedor que muestre cómo se configura una jerarquía de tres niveles con activos de distintas criticidades y cómo esa configuración afecta las reglas del programa preventivo y la priorización de órdenes. Si la demo salta directamente a las pantallas de reportes sin mostrar el proceso de configuración, es una señal de que esa parte del sistema no es tan intuitiva como el proveedor presenta.
La criticidad como criterio de configuración, no de etiqueta
En un sistema bien configurado, la criticidad del activo debe influir en las reglas del programa: frecuencia de inspección, tiempo máximo de respuesta a una orden correctiva, umbral de alerta de condición. Si la criticidad es solo un campo descriptivo que no conecta con ninguna regla del sistema, su valor para la gestión es mínimo. Es una etiqueta, no un criterio de gestión.
¿Qué tan rápido lo adopta el equipo de campo?
El sistema que el técnico no usa no sirve. La interfaz móvil, el tiempo que toma registrar una orden de trabajo en campo y la claridad de las instrucciones son los factores que determinan si el sistema se adopta de forma consistente o si los técnicos encuentran atajos: el papel, el grupo de WhatsApp, la memoria. Esos atajos no generan datos. Sin datos, no hay indicadores de mantenimiento. Sin indicadores, no hay gestión.
El indicador que predice la adopción antes de implementar
Pedir al proveedor que muestre el flujo completo para que un técnico abra, ejecute y cierre una orden de trabajo desde un teléfono, sin ayuda de nadie. Contar los pasos. Si el flujo toma más de cuatro o cinco pasos desde que el técnico abre la app hasta que puede registrar la primera observación de la orden, la fricción es alta y la adopción en campo va a ser difícil.
La trampa del sistema bien configurado que nadie usa
El error más común en implementaciones de software de gestión de activos no es técnico: es de adopción. El sistema puede estar perfectamente configurado, con todos los activos cargados, las jerarquías definidas y los programas preventivos parametrizados. Si el técnico de campo no lo usa porque la app es lenta, porque no tiene señal en el piso de producción o porque el flujo de registro es más lento que anotar en papel, la inversión no rinde.
La prueba real de adopción no es la demo: es una prueba piloto con dos o tres técnicos reales de la planta, ejecutando órdenes reales durante dos semanas. El resultado de esa prueba es más informativo que cualquier presentación comercial.
¿Se conecta con tu tecnología de monitoreo de condición?
Un software de gestión de activos que no se conecta con las herramientas de monitoreo de condición crea una isla de datos. Las alertas de los sensores llegan a una plataforma y las órdenes de trabajo viven en otra. El técnico tiene que saltar entre sistemas, el dato de condición no queda vinculado al historial del activo y el análisis integrado de condición e intervenciones no es posible.
Qué significa integración real versus compatibilidad declarada
Compatibilidad declarada significa que técnicamente es posible conectar los dos sistemas. Integración real significa que la alerta de condición del Smart Trac genera automáticamente una orden de trabajo en el sistema de gestión, con el historial de condición del activo adjunto, sin que nadie tenga que hacer ese vínculo manualmente. La diferencia entre los dos no es técnica: es operativa. Solo la segunda agrega valor en la realidad del día a día.
La pregunta que hay que hacerle al proveedor
¿Cómo llega una alerta de un sensor de vibración a una orden de trabajo en su sistema? Si la respuesta involucra exportar un archivo, copiar un dato o que alguien tenga que revisar dos pantallas distintas para decidir si crear la orden, la integración no es real. Si la respuesta es que la alerta genera la orden automáticamente con el contexto de condición incluido, eso es integración funcional.
¿Cuánto cuesta realmente implementarlo?
El costo de licencia es solo una parte del costo total. La migración de datos históricos, la configuración inicial de activos y jerarquías, la capacitación del equipo técnico, el soporte durante los primeros meses de uso y el tiempo interno del equipo de mantenimiento dedicado a la implementación son costos reales que deben incluirse en la evaluación financiera desde el inicio.
Las variables de costo que hay que pedir por escrito
Migración de datos desde el sistema anterior, costo de consultoría para la configuración inicial, número de horas de capacitación incluidas en el contrato, costo de soporte técnico post-implementación, costo de actualizaciones y nuevas versiones. Esas variables, sumadas a la licencia anual, dan el costo total de propiedad en los primeros dos años. Ese es el número que hay que comparar entre plataformas, no el precio de lista de la licencia.
El costo que no aparece en ningún presupuesto
El tiempo del equipo interno durante la implementación. Configurar bien un sistema de gestión de activos requiere que alguien del equipo de mantenimiento dedique tiempo a cargar el inventario, definir las jerarquías, parametrizar los programas preventivos y validar que los datos estén correctos. En operaciones medianas, ese esfuerzo puede equivaler a dos o tres meses de trabajo de una persona a tiempo parcial. Si ese costo no está en el presupuesto, va a aparecer de todas formas.
¿Qué indicadores genera automáticamente y cuáles requieren trabajo manual?
Si el sistema requiere exportar datos a Excel para calcular el MTBF por activo, el porcentaje de mantenimiento planificado versus correctivo o el backlog de órdenes pendientes, esos indicadores no se van a calcular con la frecuencia que se necesita. El costo no es el tiempo de exportación: es que la decisión que dependía de ese dato se toma sin él o se toma tarde.
Los indicadores que deben ser automáticos sin excepción
MTBF y MTTR por activo, porcentaje de órdenes planificadas versus correctivas, backlog de órdenes pendientes y costo de mantenimiento acumulado por activo. Si alguno de estos requiere un paso manual para calcularse, la plataforma tiene una brecha de automatización que va a limitar la frecuencia con que esos indicadores se usan para tomar decisiones.
Cómo validar esto antes de comprar
Pedir al proveedor que muestre esos indicadores calculados a partir de datos reales de un cliente. Si los muestra en una pantalla preconstruida con datos de demostración que no reflejan la operación real, preguntar cómo se genera ese reporte cuando los datos son los de tu planta. Si la respuesta implica un proceso de configuración adicional o exportación, ya tienes información relevante sobre los límites del sistema.
Cómo estructurar el proceso de evaluación para no perder tiempo
Un proceso de evaluación mal estructurado puede durar meses sin llegar a una decisión. Hay cuatro pasos que aceleran la evaluación y reducen el riesgo de elegir la plataforma equivocada.
Paso 1: definir el problema antes de ver demos
Las demostraciones comerciales están diseñadas para impresionar, no para diagnosticar si la plataforma resuelve el problema específico de tu operación. Antes de agendar cualquier demo, el equipo debe tener escritas las cinco cosas que hoy no puede hacer porque no tiene el sistema correcto. Esas cinco cosas son los criterios de evaluación. Todo lo demás es ruido.
Paso 2: incluir al técnico de campo en la evaluación
La decisión de compra suele tomarse sin involucrar a quien va a usar el sistema en campo. El resultado es un software elegido por criterios administrativos que no funciona para el técnico que lo tiene que usar en el piso de producción. Al menos dos técnicos de campo deben probar la interfaz móvil de cada plataforma evaluada y dar retroalimentación sobre facilidad de uso antes de la decisión final.
Paso 3: pedir un piloto antes de comprometer
La mayoría de los proveedores de software de gestión de activos ofrece pilotos de 30 a 60 días. Un piloto con diez o quince activos reales de la planta, con técnicos reales ejecutando órdenes reales, revela más sobre el sistema que cualquier número de demos comerciales. El piloto debe incluir un criterio de éxito definido antes de empezar: qué tiene que funcionar para que la evaluación sea positiva. Mira cómo Grupo México estructuró exactamente ese proceso en su caso de estudio.
Paso 4: evaluar el soporte post-implementación antes de firmar
Las primeras semanas después de la implementación son las más críticas para la adopción. La disponibilidad de soporte técnico en español, los tiempos de respuesta garantizados, el acceso a un interlocutor técnico (no solo a un ticket de soporte) y la oferta de capacitación continua para técnicos son variables que deben estar en el contrato. Un sistema bien implementado con soporte post-venta deficiente tiene más probabilidad de abandono que uno menos completo con soporte real.
Qué hacer después de elegir: los primeros 90 días
La decisión de plataforma no termina con la firma del contrato. Los primeros 90 días determinan si la implementación se convierte en un sistema de gestión real o en otro sistema que se usa a medias. Hay tres prioridades para ese período que definen el resultado a largo plazo.
La primera es la carga correcta del inventario de activos con criticidad definida. Sin ese inventario bien construido, todos los módulos posteriores tienen datos de baja calidad. La segunda es la formación del equipo técnico en el flujo de apertura, ejecución y cierre de órdenes desde el teléfono. Esa parte de la implementación no puede delegarse a un video de capacitación: requiere práctica supervisada con órdenes reales. La tercera es definir la primera reunión mensual de indicadores y agendarla antes de que termine el primer mes de uso. Sin esa reunión, los indicadores se calculan pero no se usan, y el valor del sistema nunca se realiza plenamente.
Tractian: monitoreo de condición que se integra con el sistema de gestión de activos que elijas
Si la operación ya tiene un sistema de gestión de activos o está en proceso de elegir uno, Tractian no compite con él: se integra con él. Para las operaciones con SAP PM o IBM Maximo, la integración es nativa y certificada. Para las que usan otras plataformas, Tractian ofrece su propia plataforma de gestión de mantenimiento incluida. En ambos casos, la alerta del sensor se convierte en una orden de trabajo con el contexto de condición del activo, sin pasos manuales intermedios.
Agenda una demostración y ve cómo fluye esa conexión con activos reales de tu operación.
Señales de que el software elegido no está funcionando y qué hacer
Implementar un sistema de gestión de activos no garantiza que funcione. Hay señales específicas que indican que la implementación tiene problemas que requieren atención antes de que el sistema se abandone o se use de forma superficial.
La primera señal es que el equipo técnico sigue usando papel, WhatsApp o Excel para gestionar órdenes de trabajo, aunque el sistema esté disponible. Eso indica un problema de adopción: la fricción de usar el sistema supera el beneficio percibido. La solución no es insistir con el sistema que no funciona: es entender qué hace que los técnicos lo eviten y corregirlo, ya sea simplificando el flujo de registro, mejorando la interfaz móvil o ajustando la configuración de las órdenes.
La segunda señal es que los indicadores se calculan manualmente en Excel, aunque el sistema debería generarlos automáticamente. Eso indica un problema de configuración: el sistema no tiene los datos que necesita para calcular los indicadores, o los campos de las órdenes no están lo suficientemente estandarizados para que el cálculo sea confiable. La solución es revisar qué campos son obligatorios al cerrar una orden y si los valores capturados permiten calcular MTBF y MTTR de forma consistente.
La tercera señal es que los indicadores se calculan correctamente pero nadie los usa para tomar decisiones. Eso indica un problema de proceso, no de sistema: no hay una reunión regular donde los indicadores se revisen y se conviertan en acciones. La solución es establecer ese proceso y hacerlo parte del ciclo mensual del área de mantenimiento. Los modelos predictivos más sofisticados no generan valor si no hay un proceso humano que convierta los datos en decisiones.
