Demo de software CMMS: qué probar antes de elegir
Guía para evaluar una demo de software CMMS con pruebas de órdenes de trabajo, datos, app móvil offline, repuestos, integraciones, soporte y adopción.
Una demo de software CMMS puede mostrar una orden de trabajo creada en segundos, un dashboard completo y una aplicación móvil sin fricciones. El recorrido suele partir de activos ordenados, permisos ya configurados y datos preparados para la presentación.
En planta, la OT puede ingresar sin activo confirmado, requerir un repuesto no disponible, quedar pendiente por falta de evidencia o ejecutarse en una zona sin señal. La evaluación debe comprobar cómo responde el sistema ante esas condiciones, no limitarse a revisar menús y funciones.
“El objetivo de una demostración técnica es obtener evidencia.”
El objetivo de una demostración técnica es obtener evidencia. Cada requisito debería quedar asociado a un flujo probado, una dependencia identificada y un responsable de validación. Esa disciplina permite comparar proveedores con el mismo criterio y decidir cuándo una sesión guiada es suficiente o cuándo hace falta una prueba de concepto.
Qué definir antes de agendar una demo CMMS
La sesión debería responder una decisión concreta. “Queremos ver el software” deja el recorrido bajo control del proveedor; “necesitamos validar una OT correctiva con técnico externo, reserva de materiales y cierre aprobado” establece una prueba verificable.
Antes de confirmar la agenda, documentá el alcance: plantas, usuarios, activos, procesos prioritarios, restricciones de conectividad, sistemas relacionados y resultado que debe quedar demostrado.
Clasificá los requisitos por impacto operativo
| Categoría | Criterio | Ejemplo |
|---|---|---|
| Obligatorio | Sin esta capacidad el proceso no puede ejecutarse o incumple una condición operativa. | Trabajo offline en zonas sin cobertura. |
| Deseable | Reduce tareas manuales o mejora el control, pero admite una segunda etapa. | Firma digital del solicitante. |
| Futuro | Tiene valor potencial, aunque no forma parte del alcance inicial. | Integración con una fuente IoT específica. |
Una función poco frecuente no debería pesar lo mismo que el cierre diario de órdenes. Tampoco corresponde evaluar una pantalla estética al mismo nivel que una regla de permisos que evita modificaciones no autorizadas.
Sumá a los roles que detectan fricciones reales
| Participante | Qué debería revisar |
|---|---|
| Jefe de Mantenimiento | Trazabilidad, carga futura, supervisión e indicadores. |
| Planner | Backlog, prioridades, recursos, ventanas, reprogramaciones y materiales. |
| Supervisor | Asignación, validación de cierres, permisos y seguimiento del turno. |
| Técnico | Cantidad de pasos, uso móvil, evidencia, búsqueda de activos y trabajo offline. |
| Almacén | Reservas, entregas, devoluciones, sustituciones y faltantes. |
| IT | Seguridad, usuarios, API, autenticación, infraestructura y datos. |
| Operaciones y Compras | Solicitudes, impacto productivo, reposición y relación con el ERP. |
No todos deben permanecer durante toda la reunión. La agenda debe indicar qué bloque corresponde a cada participante.
Demo, trial o prueba de concepto: qué valida cada opción
El formato debe corresponder al riesgo de la decisión. Una demo guiada permite descartar opciones que no cumplen condiciones mínimas; una prueba de concepto se justifica cuando hay varias plantas, trabajo offline, permisos complejos, migración extensa o integraciones que no pueden validarse con datos preparados.
| Formato | Qué permite revisar | Límite principal |
|---|---|---|
| Demo guiada | Flujo general, interfaz y capacidades disponibles. | El proveedor controla datos, secuencia y escenario. |
| Entorno de prueba | Navegación autónoma, configuración básica y experiencia de usuario. | Puede carecer de datos reales, acompañamiento o alcance completo. |
| Prueba de concepto | Procesos definidos con datos, roles y criterios acordados. | Exige preparación, alcance y responsables. |
| Piloto operativo | Uso controlado con usuarios reales. | Requiere limpieza de datos, capacitación y seguimiento. |
Para conducir la evaluación, elegí un caso con excepciones. Por ejemplo: un compresor presenta alta temperatura y paradas intermitentes; intervienen un técnico interno y un contratista; la zona tiene conectividad irregular; hay un filtro disponible y un sensor pendiente de compra. El técnico registra lecturas, fotografías, causa y acción; el supervisor valida el cierre y revisa el historial.
Seis pruebas críticas para una demo de software CMMS
Usá un caso conductor y pedí que se ejecute sin saltar pantallas ni recurrir a registros preparados. Prepará una muestra pequeña: jerarquía de activos, tipos de OT, estados, prioridades, roles, campos obligatorios, un preventivo, repuestos, una condición sin señal y un reporte utilizado para decidir.
Ingresá una solicitud incompleta, validá el activo y la prioridad, asigná cuadrilla y contratista, reservá materiales, registrá evidencia y pedí que el supervisor rechace y reabra la OT. Verificá que el historial conserve cambios, responsables y cierres anteriores.
Entregá códigos duplicados, ubicaciones inexistentes, fechas incorrectas y usuarios en la planta equivocada. Revisá detección previa de errores, reporte de rechazos, actualización masiva, reversión y conservación de jerarquías.
Incluí un plan por calendario, otro por medidor y una parada desplazada. El sistema debería conservar fecha original, nueva fecha y causa de reprogramación; de lo contrario, el cumplimiento puede representar una situación distinta de la operación.
Descargá una OT, desconectá el dispositivo y registrá campos, horas, fotografías, QR y consumos. Al recuperar señal, simulá conflictos, archivos pendientes o cambios simultáneos y observá reintentos, errores y criterio de prevalencia.
Reservá, entregá y consumí un rodamiento o sensor; después simulá devolución, sustitución o faltante. Aclarar qué dato mantiene el CMMS, cuál pertenece al ERP y cómo se procesan los errores evita confundir una API disponible con una integración terminada.
Pedí que la orden aparezca en un reporte y volvé desde el indicador a los registros que lo alimentan. Revisá estados, fechas, filtros, reaperturas, cancelaciones y momento de actualización para distinguir tiempo real, actualización programada o una capa externa de análisis.
Si la evaluación depende de un flujo real, datos propios y condiciones de campo, pedí que la sesión se organice alrededor de una OT o un activo de tu operación en una demo técnica.
Qué demostrar sobre integraciones, permisos y seguridad
Cuando el proveedor afirma que el sistema “se integra”, pedí precisión sobre datos, dirección, frecuencia, sistema maestro, responsable de desarrollo, monitoreo y reenvío de errores. La sesión debe mostrar una acción concreta y la propuesta debe documentar el alcance completo.
| Tema | Mostrar durante la sesión | Documentar antes de decidir |
|---|---|---|
| Roles | Crear un perfil y restringir una acción. | Matriz completa de permisos y administración de bajas. |
| Auditoría | Modificar un registro y revisar el log. | Alcance, retención y exportación. |
| API | Abrir documentación o ejecutar una consulta. | Métodos, límites, autenticación, versiones y soporte. |
| ERP | Recorrer un dato representativo. | Mapeo, sistema maestro, frecuencia y manejo de errores. |
| Backups | Mostrar evidencia disponible para el cliente. | Frecuencia, retención, recuperación y responsabilidades. |
| Datos | Exportar un conjunto de registros. | Propiedad, portabilidad y mecanismo de salida. |
Qué validar sobre implementación, soporte y adopción
Una demo clara no garantiza una implementación controlada. Pedí un plan con diagnóstico, migración, configuración, pruebas, capacitación, piloto, salida y soporte. La capacitación no compensa formularios mal configurados, catálogos deficientes ni responsabilidades difusas.
Matriz para comparar demos de software CMMS
Usá el mismo caso, los mismos datos, las mismas preguntas y la misma escala para todos los proveedores. El puntaje máximo corresponde a una capacidad ejecutada con roles equivalentes a los reales, evidencia verificable, excepciones y dependencias claras: 0 = no disponible o no demostrado; 1 = requiere desarrollo o validación; 2 = disponible con configuración; 3 = demostrado con el caso acordado.
| Criterio | Peso | Resultado |
|---|---|---|
| Flujo completo de OT | 15 | 0–3 |
| Trabajo móvil offline | 12 | 0–3 |
| Datos y activos | 10 | 0–3 |
| Planificación | 10 | 0–3 |
| Repuestos | 10 | 0–3 |
| Reportes y trazabilidad | 10 | 0–3 |
| Integraciones | 10 | 0–3 |
| Permisos y auditoría | 8 | 0–3 |
| Implementación y soporte | 8 | 0–3 |
| Adopción por usuarios finales | 7 | 0–3 |
La puntuación total no debería compensar el incumplimiento de un requisito obligatorio. Registrá también las preguntas pendientes, la documentación recibida y quién debe validar cada dependencia.
Señales de alerta durante una demo CMMS
Registrá cada señal como punto pendiente y exigí documentación o una segunda prueba antes de avanzar.
Evaluá un flujo real antes de elegir tu CMMS
Traé una orden de trabajo, un activo o un proceso que necesites validar y organizá la demostración alrededor de las condiciones reales de tu operación.
