La señal más fiable de si un CMMS cumplirá con los resultados prometidos en su instalación es un piloto estructurado en sus activos reales con sus técnicos reales.
Si ha completado un piloto de 30 días, la siguiente validación ya debería existir.
Si no ha completado un piloto antes de llegar a la fase de contrato —complete uno antes de firmar.
Un proveedor que no esté dispuesto a apoyar un piloto de 30 días en una selección representativa de sus activos antes del compromiso contractual está comunicando algo importante sobre su confianza en el rendimiento del plataforma en el mundo real.
Lista de verificación de validación del piloto
☐ Se confirmó la conectividad de la máquina en al menos un activo moderno digitalizado, un activo heredado y una estación manual o híbrida durante el piloto.
☐ La conexión fue estable durante todo el periodo del piloto —sin lagunas de datos inexplicables, pérdidas de señal o problemas de precisión.
☐ Al menos un disparador de mantenimiento basado en condición se activó automáticamente a partir de una señal de máquina durante el piloto —no un mantenimiento preventivo programado manualmente por calendario.
☐ La tasa de adopción de los técnicos alcanzó más del 70% al día 30 del piloto —medida por la frecuencia real de inicio de sesión en la app móvil, no por cumplimiento autoinformado.
☐ Se revisó de principio a fin al menos un registro de la pista de auditoría de cumplimiento —confirmando que contiene atribución de usuario, marca temporal, piezas consumidas, versión del SOP y firma al nivel que exige su marco regulatorio.
☐ Se revisaron los datos de OEE del periodo del piloto junto con los registros de mantenimiento —confirmando que ambos conjuntos de datos existen en el mismo entorno y que su cruce no requiere exportación manual de datos ni conciliación.
Los contratos de CMMS para la industria manufacturera contienen términos que generan obligaciones y restricciones continuas que son fáciles de pasar por alto cuando el enfoque principal está en el precio.
Estos términos importan más de lo que la mayoría de compradores se da cuenta en la etapa de firma —particularmente los que rigen la portabilidad de datos, la renovación del contrato y los cambios de alcance.
Lista de verificación de términos del contrato
☐ Cláusula de portabilidad de datos confirmada.
El contrato establece explícitamente que todos los datos —registros de activos, historial de órdenes de trabajo, registros de mantenimiento, datos de OEE— son exportables en un formato estándar legible por máquina (CSV, JSON o XML) en cualquier momento y al finalizar el contrato.
Un proveedor que se resiste a una cláusula clara de portabilidad de datos está creando costes futuros de cambio que debería incorporar ahora en el coste total de propiedad.
☐ Período de preaviso para la terminación está documentado y es razonable.
Los contratos que requieren un preaviso de terminación de 6-12 meses para suscripciones anuales generan una retención significativa.
30-90 días es un periodo de preaviso razonable para la terminación de un CMMS de fabricación.
☐ Los términos de escalada de precios están definidos.
Los aumentos de precio anual por encima de un tope definido —típicamente el IPC más 2-3%— deberían requerir su consentimiento explícito en lugar de aplicarse automáticamente.
Confirme si el contrato incluye una cláusula de escalada de precios y cuáles son sus términos.
☐ El alcance del soporte incluido está definido explícitamente.
El soporte de implementación, la gestión de cuenta posterior al go-live, los compromisos de tiempo de respuesta para problemas operativos críticos frente a preguntas de configuración y el proceso para escalar problemas no resueltos están todos definidos por escrito —no dejados a garantías verbales durante el proceso de ventas.
☐ El alcance de la conectividad está documentado.
Los activos específicos incluidos en el proyecto de conectividad de máquinas están listados —con la ruta de conectividad para cada uno (PLC directo, pasarela IoT, visión por computador) y la parte responsable de la instalación.
Las sorpresas de conectividad a mitad de la implementación son una de las fuentes más comunes de retrasos en el calendario y conflicto presupuestario.
☐ Se establecen garantías de tiempo de actividad y disponibilidad de datos.
Confirme si se incluyen términos SLA para la disponibilidad de la plataforma —particularmente relevantes para plataformas alojadas en la nube— y qué remedios existen si no se cumplen.
La calidad del soporte post-go-live es el factor único más subestimado en el éxito de la implementación de un CMMS.
El equipo de ventas y el equipo de implementación que estuvieron atentos y receptivos durante el proceso de evaluación no siempre son las mismas personas que soportan la operación después del go-live.
Validar el modelo de soporte post-go-live antes de firmar no es escepticismo —es diligencia debida estándar.
Lista de verificación de soporte post-go-live
☐ Gestor de cuenta nombrado confirmado.
El nombre del gestor de cuenta que será responsable de la relación después del go-live está documentado.
Confirme si esta persona participó en el proceso de implementación o si es una nueva relación que comienza en el go-live.
☐ Los compromisos de tiempo de respuesta del soporte están por escrito.
El contrato distingue entre los compromisos de tiempo de respuesta para problemas operativos críticos (indisponibilidad de la plataforma, pérdida de datos, fallos del sistema que afectan las operaciones de producción) y preguntas estándar de configuración o uso.
Los tiempos de respuesta para incidencias críticas inferiores a 4 horas durante el horario laboral y un camino de escalado definido para incidencias críticas fuera de horario son expectativas razonables para una plataforma de operaciones de fabricación.
☐ Se define el proceso de comunicación de actualizaciones de producto.
El proveedor tiene un proceso documentado para comunicar las actualizaciones de la plataforma antes de su despliegue —incluidos los cambios que afectan flujos de trabajo configurados, integraciones o estructuras de documentación de cumplimiento.
Pregunte específicamente cómo las actualizaciones de producto han afectado las configuraciones de clientes existentes en los últimos 12 meses y cómo esos clientes fueron notificados y apoyados durante los cambios.
☐ Se han contactado clientes de referencia en operación post-go-live.
Se ha contactado directamente al menos a dos clientes de referencia que llevan 12-24 meses en operación post-go-live en un entorno de fabricación similar —no a través de llamadas de referencia curadas por el proveedor.
Las preguntas específicas para hacer a las referencias:
“¿Cómo cambió la calidad del soporte del proveedor entre la fase de implementación y la fase post-go-live?”
“¿Hubo sorpresas post-go-live —problemas de conectividad, brechas en la documentación de cumplimiento, problemas de adopción— que no se identificaron durante la evaluación?”
“¿Volvería a implementar esta plataforma, sabiendo lo que sabe ahora?”
Para fabricantes con infraestructura ERP existente —SAP, Microsoft Dynamics, NetSuite— la integración entre el CMMS y el ERP es un requisito operativo crítico que merece validación específica antes de la firma.
Lista de verificación de integración y conectividad ERP
☐ La arquitectura de integración está documentada por escrito.
Los flujos de datos específicos entre el CMMS y el ERP —órdenes de producción del ERP al CMMS, costes de mantenimiento del CMMS al ERP, flujos de trabajo de compra de repuestos— están documentados con el método técnico de integración especificado.
“Nos integramos con SAP” no es documentación suficiente.
“Nos conectamos a SAP vía una API REST bidireccional, sincronizando órdenes de producción cada 15 minutos y enviando los datos de coste de mantenimiento a SAP PM al cierre de la orden de trabajo” sí lo es.
☐ Se asigna la responsabilidad de la integración.
Quién es responsable de construir, probar y mantener la integración —el proveedor, su equipo de TI o un integrador tercero— está definido explícitamente en el contrato.
☐ Las pruebas de integración están incluidas en el alcance de la implementación.
El cronograma de implementación incluye una fase específica para pruebas de integración antes del go-live —con criterios de aceptación definidos que la integración debe cumplir antes de declarar la plataforma como operativa.
☐ La responsabilidad del mantenimiento de la integración está definida post-go-live.
Cuando el ERP o la plataforma CMMS se actualicen y la integración falle —lo cual ocurrirá en algún momento— quién es responsable de solucionarlo, en qué plazo y a qué coste está documentado.
El equipo de implementación que realmente configurará y desplegará la plataforma no siempre son las mismas personas que presentaron durante la evaluación.
Validar quién estará en el terreno durante su implementación —y cómo es el cronograma realista basado en implementaciones de clientes comparables— es una diligencia final que la mayoría de compradores omite.
Lista de verificación del equipo de implementación y cronograma
☐ Se confirman los miembros nombrados del equipo de implementación.
El ingeniero de automatización y el gestor de cuenta que se asignarán a la implementación se identifican por nombre antes de firmar el contrato.
Si el proveedor no puede nombrar a los miembros específicos del equipo de implementación en la etapa contractual, pregunte cuándo se asignarán y haga el contrato condicionado a la confirmación de la asignación del equipo antes de que comience la implementación.
☐ El cronograma de implementación está basado en datos de clientes comparables.
El proveedor puede proporcionar cronogramas documentados de implementación de al menos tres clientes comparables —similar tamaño de instalación, tipos de equipo similares, complejidad de conectividad similar.
Si el cronograma cotizado es significativamente más rápido que las implementaciones de clientes comparables, pregunte qué se pospondrá o excluirá para lograrlo.
☐ Los criterios de go-live están definidos en el contrato.
Las condiciones específicas que deben cumplirse para declarar la implementación como completa —porcentaje de conectividad de máquinas, tasa de adopción de técnicos, configuración de documentación de cumplimiento— están indicadas en el contrato en lugar de dejarse a la discreción del proveedor.
☐ Se confirma la viabilidad de conectividad para activos heredados.
Si la instalación incluye equipos heredados que requerirán despliegue de pasarelas IoT o cobertura de visión por computador, el enfoque de conectividad para esos activos específicos se ha validado durante el piloto o mediante una evaluación pre-implementación documentada.
Las sorpresas de conectividad en activos heredados son la causa más común de sobrecarga en el cronograma de implementación.
Después de completar cada sección de esta lista de verificación, una pregunta final merece hacerse directamente al representante de ventas del proveedor —no a su equipo de implementación ni a su gestor de cuenta.
“Si esta implementación no alcanza los resultados que discutimos durante la evaluación, ¿qué recursos tenemos?”
La respuesta revela más sobre la confianza del proveedor en su plataforma que cualquier demostración o comparación de características.
Un proveedor que responde con mecanismos específicos y documentados —garantías de rendimiento, procesos de remediación definidos, cláusulas de salida vinculadas a fallos en resultados medibles— es un proveedor que respalda su implementación.
Un proveedor que responde con tranquilizaciones, desvíos o un cambio hacia discutir por qué la falta de cumplimiento es improbable —en lugar de qué sucede si ocurre— está comunicando algo que vale la pena tener en cuenta antes de firmar.
| Área de diligencia | Estado |
|---|---|
| Validación del piloto completada — conectividad, tasa de adopción, disparador basado en condición, pista de auditoría de cumplimiento | ☐ |
| Cláusula de portabilidad de datos confirmada | ☐ |
| Período de preaviso de terminación documentado y aceptable | ☐ |
| Términos de escalada de precios definidos | ☐ |
| Alcance de conectividad documentado por activo | ☐ |
| Modelo de soporte post-go-live definido por escrito | ☐ |
| Gestor de cuenta nombrado confirmado | ☐ |
| Clientes de referencia contactados de forma independiente | ☐ |
| Arquitectura de integración con ERP documentada | ☐ |
| Responsabilidad de mantenimiento de la integración asignada | ☐ |
| Equipo de implementación nombrado confirmado | ☐ |
| Criterios de go-live definidos en el contrato | ☐ |
| Conectividad de activos heredados validada | ☐ |
| Pregunta final sobre recursos formulada y respondida | ☐ |
Firme cuando cada casilla esté marcada.
No antes.
¿Es razonable pedirle a un proveedor un piloto antes de firmar?
Sí —y la disposición de un proveedor a apoyar un piloto estructurado antes del compromiso contractual es en sí misma una señal significativa de su confianza en el rendimiento de la plataforma en el mundo real.
Un piloto de 30 días en una selección representativa de activos —cubriendo la validación de conectividad, la medición de la tasa de adopción y la confirmación de la pista de auditoría de cumplimiento descritas en el Área de Diligencia Debida 1— es un requisito razonable previo a la firma para una inversión tecnológica significativa.
¿Qué pasa si el proveedor se resiste a incluir criterios de go-live en el contrato?
La resistencia a criterios de go-live definidos es una señal que merece tomarse en serio.
Los criterios de go-live protegen a ambas partes —dan al proveedor una definición clara de qué significa el éxito y le dan al comprador una base objetiva para declarar la implementación como completa.
Un proveedor que se resiste a criterios de go-live definidos suele estar preocupado de que los criterios expongan una brecha entre su cronograma proyectado y su capacidad de entrega realista.
¿Qué tan importante es la portabilidad de datos para un CMMS alojado en la nube?
Críticamente importante.
Su historial de mantenimiento, registros de activos y documentación de cumplimiento son activos operativos que su organización posee —independientemente de qué plataforma los almacene.
Un contrato de CMMS que no garantiza explícitamente su capacidad para exportar estos datos en un formato estándar en cualquier momento —incluido al término del contrato— crea una dependencia que aumenta significativamente los costes de cambio si la plataforma no cumple.
¿Deberíamos negociar los términos del contrato o aceptar los términos estándar?
Negocie.
Específicamente: cláusulas de portabilidad de datos, periodos de preaviso de terminación, topes de escalada de precios, criterios de go-live y compromisos de tiempo de respuesta de soporte post-go-live.
Estos términos son negociables para la mayoría de los proveedores —y los proveedores que se niegan a negociarlos en cualquier punto están comunicando una dinámica de poder proveedor-comprador que afectará la relación durante todo el periodo contractual.
Si cada elemento de esta lista de verificación está confirmado y la pregunta final ha recibido una respuesta satisfactoria —el contrato está listo para firmar. Si queda algún elemento sin resolver —resuélvalo primero. La implementación aún no ha comenzado. Este es el último momento en que los problemas pendientes no cuestan nada abordarlos.
Iniciar sesión
Blog
