Cómo elegir un CMMS después de una implementación fallida: Guía 2026

Puntos clave

• Un despliegue de CMMS fallido casi nunca es un fallo del software. En la gran mayoría de los casos es una de cuatro cosas: nadie lo tuvo como responsabilidad, los datos nunca se limpiaron, los técnicos nunca tuvieron una razón para usarlo, o el alcance fue demasiado grande para la primera versión.
• Diagnostica antes de comprar. Si reemplazas la herramienta sin cambiar la causa, reproducirás el fallo a mayor coste, y la segunda falla es mucho más difícil de recuperar políticamente.
• El predictor individual más potente de adopción es si un técnico puede completar una tarea en un teléfono en menos de un minuto, sin teclear un número de activo. Prueba eso en la demostración, en un teléfono real, con tu propia lista de activos.
• No migres los datos antiguos en bloque. Migra el registro de activos y el trabajo abierto, y archiva el resto. Importar una década de registros defectuosos es la forma en que un nuevo comienzo hereda la mala reputación del sistema antiguo.
• Pregunta a cada proveedor qué ocurre en la quinta semana, no en la primera. Las implementaciones reciben soporte; la quinta semana, cuando el consultor ya se ha ido y se acumula el primer retraso, es cuando los sistemas realmente se abandonan.

La última implementación de CMMS falló. ¿Qué deberíamos hacer de forma diferente al elegir la siguiente?

Empieza por nombrar el fallo con precisión, porque la solución es diferente para cada causa. Si los técnicos no lo usaron, la siguiente selección se decide por la usabilidad móvil y el escaneo, y pruebas ambas con técnicos reales antes de firmar. Si los datos estaban mal, arreglas el registro de activos y la convención de nombres antes de elegir cualquier sistema, porque los datos defectuosos rompen el segundo sistema exactamente como rompieron el primero. Si nadie lo tenía como responsabilidad, asignas un responsable del sistema con horas dedicadas, y no se realiza la compra hasta que esa persona exista. Si el alcance fue demasiado grande, recortas la primera versión a trabajo reactivo más los 20 activos principales y añades el resto más adelante.

Luego cambia lo que evalúas. Juzga a los candidatos por el tiempo para completar una tarea en un teléfono, por si un activo se encuentra escanneando un código QR en lugar de teclear, y por la rapidez con la que un técnico real de tu equipo puede completar una tarea sin ayuda. Fabrico ofrece aplicaciones nativas para iOS y Android con escáneres QR para máquinas y repuestos, una tarjeta de trabajo personal para cada técnico y un temporizador automático para que la duración se capture sin que nadie la introduzca. La configuración se cotiza como 3 días de trabajo por parte de Fabrico incluyendo importación masiva, y la respuesta de soporte es contractualmente inferior a 2 horas.

Las cuatro causas y cómo saber cuál tuviste

Causa 1: sin responsable. La señal es que nadie puede decir quién decidió algo después de la puesta en marcha. Un sistema necesita una persona cuyo trabajo lo incluya: alguien que cierre activos duplicados, arregle un calendario que se dispara con demasiada frecuencia y responda la pregunta de un técnico el mismo día. Cuando ese rol se asumió en lugar de asignarse, el sistema se deteriora en silencio, y para el sexto mes la pizarra ha vuelto.

Causa 2: datos sucios. La señal es que la gente dejó de confiar en la búsqueda. Si un activo aparece tres veces con tres nombres, o la mitad del registro es una ubicación y la otra mitad es una máquina, los técnicos evitan el sistema en lugar de luchar con él. Esto no es un problema de software y comprar otro software no lo solucionará. Nuestra guía sobre diseño de la jerarquía de activos cubre la estructura que hay que acordar antes de cualquier importación.

Causa 3: ninguna razón para que el técnico lo use. La señal es que los datos entran y no vuelve nada. Si el sistema solo toma, es decir, exige entradas y no devuelve nada útil, los técnicos concluyen correctamente que es una herramienta de informes para la dirección. La contramedida es hacer que devuelva: el manual en el teléfono junto a la máquina, el historial de lo que se intentó la última vez, el número de pieza sin tener que caminar hasta el almacén.

Causa 4: alcance demasiado grande. La señal es que la puesta en marcha incluyó planes preventivos, inventario, compras, monitorización de condición y paneles de control a la vez. Todo está medio configurado, así que todo está algo mal, y por tanto nada se confía. Una primera versión que haga bien las órdenes de trabajo reactivas supera siempre a una que haga mal seis módulos.

Hay una quinta causa, más rara y que merece nombrarse: el software genuinamente no podía hacer el trabajo, normalmente porque se compró para otra industria. Si ese fue tu caso, el diagnóstico es fácil y el resto de este artículo sigue aplicando a la reconstrucción.

Qué hacer antes de mirar a cualquier proveedor

Escribe el fallo en un párrafo y compártelo. Esto es incómodo y es la hora de más valor en el proyecto. Un segundo intento que finge que el primero no ocurrió hereda todo el escepticismo y ninguno del aprendizaje. Un segundo intento que comienza con "esto es lo que salió mal y esto es lo que vamos a cambiar" obtiene audiencia.

Arregla el registro de activos fuera del sistema. Una convención de nombres, una jerarquía, duplicados eliminados, criticidad asignada. Hazlo en una hoja de cálculo si quieres; la cuestión es que esté acordado antes de importarlo. Este trabajo es portable a cualquier proveedor que elijas al final, así que nunca se pierde.

Asigna el responsable y dale las horas. Un porcentaje de la semana de una persona real, por escrito. Si la organización no financia eso, la conclusión honesta es que no está lista para comprar otra vez todavía, y decirlo ahora es más barato que decirlo dentro de un año.

Recorta la primera versión. Órdenes de trabajo reactivas, el registro de activos y planes preventivos para los activos principales por criticidad. Inventario, compras y analítica vienen después de que la primera versión esté realmente en uso. Resiste la tentación de incluirlo todo porque "ya lo estamos pagando".

Diez preguntas para hacer a los proveedores, tras una historia de fallo

1. Pon un teléfono en la mano de mi técnico y deja que cierre una tarea sin ayuda. ¿Cuánto tiempo tarda y cuántos toques son?
2. ¿Se puede localizar un activo escaneando un código en la máquina, y qué ocurre si el código está dañado?
3. ¿Qué obtiene un técnico del sistema en la máquina, no solo qué introduce?
4. ¿Quién de su lado está involucrado después de la puesta en marcha, durante cuánto tiempo y qué ocurre en la quinta semana?
5. ¿Podemos poner en marcha solo con trabajo reactivo y añadir planes preventivos más tarde sin una reimplementación?
6. ¿Qué espera su importación y nos ayudarán a limpiar el registro o solo a cargarlo?
7. ¿Cómo cambiamos un calendario preventivo nosotros mismos, sin abrir un ticket de soporte?
8. ¿Cómo se ve el sistema para un técnico que no se siente cómodo con el software, y la interfaz está disponible en su idioma?
9. ¿Podemos hacer una prueba de dos semanas en una línea, con nuestros activos y nuestra gente, antes de comprometernos?
10. ¿Cuál es su tiempo de respuesta de soporte, contractualmente, y en qué horario?

La pregunta 1 no es una formalidad. Hazla con un técnico real de tu planta, no con un supervisor, y observa dónde duda. Cada vacilación que veas en una demo se convierte en un abandono en el mes tres.

La prueba de adopción que lo predice todo

Si solo haces una cosa diferente esta vez, haz esto. Toma dos técnicos, uno cómodo con la tecnología y otro no. Dale a cada uno un teléfono con la aplicación candidata y sin más formación que una orientación de un minuto. Pídeles que hagan tres cosas: localizar una máquina específica, ver qué se hizo la última vez y registrar una tarea completada con una nota y una foto.

Mide el tiempo y cuenta las veces que piden ayuda. Cualquier cosa que tome a un técnico más de aproximadamente un minuto, o que requiera teclear un código de activo de memoria, no sobrevivirá al contacto con un turno húmedo, ruidoso y con guantes. Esta prueba cuesta una hora y es más predictiva que cualquier comparación de funciones, porque las funciones son lo que un sistema puede hacer y la adopción es lo que realmente se le pedirá que haga.

El idioma forma parte de esto. Si la mitad de tu equipo trabaja en un idioma que la interfaz no ofrece, la adopción queda limitada antes de empezar. La interfaz de Fabrico está disponible en inglés, búlgaro, alemán, francés y polaco, y añadir más idiomas es sencillo.

Dónde encaja Fabrico

Frente a las cuatro causas anteriores, las capacidades relevantes son: clientes nativos para iOS, Android y web con escaneres QR para máquinas y repuestos, de modo que la identificación sea por escaneo; una tarjeta de trabajo personal por técnico para que cada persona vea su propio trabajo en lugar de una cola compartida; un temporizador automático para que la duración se capture sin entrada de datos; un registro de máquinas que contiene manuales, archivos e historial completo, de modo que el sistema devuelva valor en la máquina; calendario y programación por arrastrar y soltar que un planificador de mantenimiento puede cambiar sin un ticket de soporte; y plantillas recurrentes, tareas condicionadas y flujos de aprobación para cuando estés listo para añadir estructura.

En cuanto a la implementación, la capa CMMS se cotiza en 3 días de configuración por parte de Fabrico que cubren configuración, usuarios, roles e importación masiva, con soporte para importación masiva, formación en vivo y en sitio, y una Evaluación Operativa disponible como complemento de pago cuando lo que necesita trabajo es el proceso subyacente y no solo la herramienta. La respuesta de soporte es contractualmente inferior a 2 horas por correo electrónico y devolución de llamada telefónica, con una base de conocimientos en búlgaro, inglés y alemán.

Cuando el OEE está en alcance, disponibilidad, rendimiento y calidad vienen del PLC, con sensores IoT o cámaras con IA donde no exista una señal utilizable. Eso importa para un segundo intento porque el tiempo de inactividad registrado por la máquina no depende en absoluto de la adopción, así que produce valor incluso en las semanas en que la disciplina de las órdenes de trabajo aún se está construyendo. Ten en cuenta que conectar máquinas es un ejercicio separado de la configuración del CMMS, condicionado por tu equipo y el acceso a las líneas, así que plánificalos como dos cronogramas.

Ejemplo práctico: el segundo intento que funcionó

Una planta con 300 activos compró un CMMS bien valorado, pasó cuatro meses configurando seis módulos, lanzó el sistema en todo el sitio en una sola fecha y, para el mes siete, tenía el 11 % de las órdenes de trabajo cerradas en el sistema. El mantenimiento volvió a funcionar con la pizarra. El sistema se mantuvo en la factura otros dos años.

El análisis posterior encontró las cuatro causas. No había responsable, solo un jefe de proyecto que volvió a su trabajo diario en la puesta en marcha. El registro tenía 340 entradas para 300 activos. Los técnicos no obtenían nada de la app y tenían que teclear códigos de activo. Y el alcance había incluido compras, algo que nadie del mantenimiento había pedido jamás.

El segundo intento invirtió el orden. Se dedicaron seis semanas al registro antes de cualquier conversación con proveedores, terminando con 300 activos limpios, una convención y criticidad asignada. Se concedió a un planificador un día a la semana como responsable del sistema, por escrito. La selección se decidió por una prueba telefónica con dos técnicos en el taller. La puesta en marcha cubrió solo trabajo reactivo y el registro de activos, en una línea, y luego el resto de la planta cuatro semanas después. Los planes preventivos se añadieron en el mes tres, inventario en el mes seis y compras nunca.

La lección no es que el segundo software fuera mejor. Es que el primer intento compró una herramienta y el segundo intento arregló un sistema. La secuencia venció a la selección, y las seis semanas más baratas del proyecto fueron las empleadas antes de que alguien visitara la web de un proveedor.

Preguntas frecuentes

¿Deberíamos decirles a los proveedores que nuestra última implementación falló?

Sí, y con detalle. Un proveedor que oye la historia real puede decirte si su enfoque la aborda o no, y los que la descartan te están diciendo algo útil sobre cómo serán los próximos doce meses. Ocultarlo significa que cada proveedor vende la implementación estándar, que es exactamente lo que no funcionó la vez anterior.

¿Cuánta de la información antigua deberíamos migrar?

El registro de activos, las órdenes de trabajo abiertas y cualquier historial legal o relevante para garantías. Archiva el resto en una exportación de solo lectura que puedas buscar si alguna vez la necesitas. El instinto de traerlo todo es fuerte y normalmente está equivocado: el historial antiguo suele estar incompleto, y importarlo recrea la desconfianza que hizo que la gente dejara de usar el sistema anterior.

¿Merece la pena intentar arreglar el sistema existente en lugar de reemplazarlo?

A menudo sí, y merece una hora honesta antes de gastar un ciclo presupuestario. Si el fallo fue por propiedad, datos o alcance, esas causas te acompañan y la herramienta incumbente puede ser perfectamente capaz una vez que se arreglen. Reemplaza cuando la herramienta genuinamente no pueda hacer el trabajo, cuando la experiencia móvil no pueda mejorarse porque no es prioridad del proveedor, o cuando el sistema esté tan desacreditado internamente que un nombre nuevo valga más que el coste de la migración. Esa última razón es blanda pero real.

¿Cuánto debería durar la segunda implementación?

La configuración del software no es la parte larga y nunca lo fue. La configuración por parte del proveedor para una capa CMMS se mide en días. El camino realista es unas pocas semanas de preparación de datos que haces tú, una configuración corta, un piloto en una línea y luego un despliegue en la planta, con planes preventivos añadidos después. Cualquiera que prometa una puesta en marcha completa de varios módulos en quince días está describiendo la instalación del software, no el cambio.

¿Qué métrica única nos dice que esta vez funciona?

La proporción de trabajo que pasa por el sistema, medida semanalmente y vigilada en los dos primeros meses. No cumplimiento, no MTTR, no coste. Si los trabajos reactivos se crean y se cierran en el sistema en lugar de en una conversación, todo lo demás se vuelve posible. Si no lo hacen, ninguna otra métrica significa nada, porque los datos que las sustentan son una muestra del trabajo y no el trabajo.

Lecturas relacionadas: cómo cambiar de software CMMS para la mecánica de una migración, la guía de migración de datos para qué traer, y la guía de OEE para manufactura si los datos de máquina forman parte del segundo intento.

Si quieres hacer la prueba telefónica con tus propios activos y tus propios técnicos, reserva una demo y di que eso es lo que quieres hacer.

Última actualización: 7 de agosto de 2026.