Equipo de implementación CMMS: quién decide, quién ejecuta y quién es dueño del dato

La reunión de kickoff con el proveedor está agendada para el martes. Del lado de la planta, el jefe de mantenimiento figura como “responsable del sistema”, sin horas asignadas y con la línea de llenado detenida dos veces esa semana. Nadie definió quién decide si la jerarquía de activos baja hasta el componente, quién confirma que el listado de repuestos del pañol es el vigente ni quién puede postergar el arranque si el piloto no está listo. Esas preguntas no figuran en el cronograma. Aparecen en la tercera semana, como demoras que nadie tiene autoridad para destrabar.

Armar el equipo de implementación de un CMMS consiste en asignar esas decisiones antes de que se necesiten. Este artículo propone los roles mínimos del proyecto, una matriz RACI organizada por decisión y no por tarea, y criterios para repartir roles cuando la planta tiene pocas personas para cubrirlos. Las fases, la elección del piloto y qué cargar primero se desarrollan en la guía para implementar un CMMS sin frenar la operación.

Respuesta directa: un proyecto CMMS necesita, como mínimo, un sponsor con autoridad sobre recursos de varias áreas, un líder funcional de mantenimiento que decida sobre el proceso, IT a cargo de accesos, dispositivos e integraciones, un responsable con nombre propio por cada dominio de datos y usuarios clave que prueben el flujo en campo. Del lado del proveedor, una contraparte que configure, cargue y capacite sin decidir por la operación.

Rol de proyecto, perfil de sistema y cargo: tres cosas distintas

En una implementación, la palabra “rol” se usa para tres cosas diferentes, y mezclarlas genera discusiones que no avanzan. El jefe de mantenimiento puede ser líder funcional del proyecto, tener perfil de administrador en el sistema y seguir siendo jefe de mantenimiento. Cada uno de esos sombreros se define en un lugar distinto y dura un tiempo distinto.

Lo que sigue trabaja solo sobre el primer plano. Cuando la matriz RACI incluye “aprobar perfiles y permisos”, asigna quién firma esa decisión. El diseño de los perfiles es otra discusión.

Los roles mínimos de un proyecto CMMS

Los roles que siguen no equivalen a seis personas. En una planta con un solo jefe de mantenimiento, dos o tres pueden recaer en la misma persona, y más abajo se analiza qué combinaciones funcionan. Lo que no puede pasar es que alguna de las decisiones asociadas a cada rol quede sin dueño.

Sponsor ejecutivo

Suele ser el gerente de operaciones, el gerente de planta o quien tenga autoridad simultánea sobre mantenimiento y producción. Su función no termina al firmar la orden de compra: durante el proyecto decide lo que el líder funcional no puede resolver desde su posición.

Un caso típico: para relevar placas y códigos de la línea de envasado, el equipo necesita que producción libere la línea dos horas y que dos técnicos dejen de atender correctivos menores esa mañana. El jefe de mantenimiento puede pedirlo; el sponsor puede ordenarlo. Pasa lo mismo cuando compras demora el alta de repuestos en el ERP o cuando alguien propone sumar a mitad de camino una integración que no estaba en el alcance.

Al sponsor le corresponde lo que compromete recursos de otras áreas o cambia la forma de trabajar de la planta: liberar horas de producción, desempatar entre áreas, aprobar cambios de alcance y, al final, autorizar el arranque y aceptar el cierre.

Señal de que falta el sponsor. La misma decisión vuelve a la reunión de seguimiento varias semanas seguidas y nadie en la mesa tiene autoridad para cerrarla.

Líder funcional de mantenimiento

Es el dueño del proceso de mantenimiento dentro del proyecto. Define cómo nace una solicitud, qué tipos de OT existen, qué estados recorren, qué campos son obligatorios para cerrar y con qué criterio un supervisor devuelve un cierre. Normalmente ocupa este rol el jefe de mantenimiento, un planner senior o el responsable de confiabilidad, y trabaja sobre el flujo completo de la orden de trabajo que la planta ya tiene o necesita ordenar.

No conviene confundirlo con el coordinador del proyecto. El coordinador sigue el cronograma, convoca reuniones, registra pendientes y persigue entregables. El líder funcional toma decisiones de proceso. En una planta chica ambas funciones suelen recaer en la misma persona; con varias integraciones o varias áreas en juego, separarlas evita que el líder funcional termine dedicado a la administración del proyecto.

El liderazgo funcional no debería quedar en IT. Desde sistemas se puede dejar una configuración técnicamente impecable, con campos que ningún técnico completa desde el celular al lado de un compresor. Qué registrar lo tiene que decidir quien después va a usar ese dato para programar, investigar una falla repetitiva o defender un presupuesto.

IT y sistemas

IT responde por lo que el proveedor no controla dentro de la red del cliente: altas de usuarios, políticas de inicio de sesión, dispositivos móviles, cobertura wifi en planta, reglas de firewall, respaldos en despliegues locales e interfaces con el ERP. Sobre el proceso de mantenimiento, IT es consultado; sobre la infraestructura, decide.

Su carga depende de la arquitectura. Un despliegue local le traslada la administración de servidores, base de datos y recuperación ante incidentes; en la nube, el peso se concentra en accesos, dispositivos e integraciones. Los puntos que IT debe validar según la arquitectura elegida cambian bastante entre un modelo y otro.

Un problema de calendario que conviene prevenir: pedir las tablets, las cuentas o la apertura de puertos la semana previa al piloto. Si IT trabaja con cola de tickets y ventanas de cambio, esos pedidos tienen que entrar al plan desde el kickoff.

Responsables de datos por dominio

Cargar un dato y validarlo son tareas distintas. El proveedor o un analista pueden subir cientos de activos desde una planilla, pero solo alguien que conoce la planta puede decir cuál de las dos filas, “COMPRESOR 2” o “COMP-02 SALA MÁQ.”, corresponde al equipo real, y si el secador asociado merece un código propio.

Por eso cada dominio de datos necesita un dueño con nombre y apellido, no un área.

Qué datos conviene tener resueltos antes de empezar está en el checklist de datos mínimos para implementar un CMMS; hasta qué nivel desagregar la jerarquía, en la guía para estructurar el árbol de activos industriales. Acá interesa otra cosa: que ante cada inconsistencia de la carga piloto haya alguien que responda.

Usuarios clave y referentes de turno

Los usuarios clave son técnicos o supervisores con credibilidad en su turno que prueban el flujo antes que el resto. En el proyecto cumplen dos funciones. Detectan lo que no funciona en campo: el campo obligatorio imposible de completar sin señal, el estado que nadie entiende, la etiqueta QR ubicada donde no se puede leer. Y llevan al diseño el criterio de quien cierra órdenes todos los días.

Un criterio de cobertura razonable es tener al menos un usuario clave por turno y por área incluida en el piloto. Si el turno noche no tiene referente, sus problemas llegan tarde y contados por terceros.

Su formación y la evaluación de su competencia siguen el plan de capacitación CMMS por roles. Para el equipo de proyecto, lo que importa es que tengan horas asignadas para probar, no solo buena disposición.

Áreas que se consultan en decisiones puntuales

Algunas áreas no integran el núcleo del proyecto, pero tienen voz en decisiones concretas. Convocarlas a todo alarga las reuniones; dejarlas afuera produce configuraciones que después alguien rechaza.

En una planta de alimentos, dejar a Calidad fuera del diseño del cierre de OT puede descubrirse recién en la primera auditoría posterior al arranque: las intervenciones están registradas, pero sin la evidencia que se pide. Cómo construir trazabilidad para auditorías en la industria alimenticia se desarrolla por separado.

Qué hace el proveedor y qué decide el cliente

Un proveedor de CMMS puede cargar datos, configurar estados, dictar capacitaciones y construir integraciones. Lo que no puede hacer, por más implementaciones que tenga encima, es decidir por la operación qué activo es crítico, qué trabajos requieren aprobación o cuándo dejar de usar las planillas. Si esa frontera no se explicita, pasa una de dos cosas: el proveedor completa decisiones por omisión, o el cliente espera que el proveedor resuelva algo que solo la planta sabe.

La contraparte también importa. El proveedor necesita un único interlocutor que consolide respuestas. Si las definiciones llegan por canales distintos, mantenimiento por WhatsApp, IT por ticket y compras por mail, se contradicen y la configuración cambia de una semana a otra.

En OTEX, el servicio de implementación incluye la migración desde planillas, la carga de activos e historiales, la capacitación del equipo y la integración con los sistemas del cliente.

Matriz RACI de una implementación CMMS, decisión por decisión

La RACI asigna cuatro formas de participar. R (responsable) hace el trabajo; A (aprobador) responde por el resultado y tiene la última palabra; C (consultado) aporta criterio antes de que se decida; I (informado) se entera después. La regla que la vuelve útil es una sola A por fila: dos aprobadores equivalen a ninguno.

Casi todas las RACI de proyecto se arman por tarea: cargar activos, capacitar técnicos, configurar OT. Para un CMMS rinde más organizarla por decisión, porque una tarea sin ejecutor se nota enseguida, mientras que una definición sin dueño recién se nota cuando otros ya dependen de ella. Las doce filas siguientes son decisiones que, si quedan abiertas, detienen el trabajo de alguien más.

Mirado por columnas, el reparto tiene una lógica. El sponsor aprueba lo que compromete recursos de otras áreas o define cuándo cambia la forma de trabajar de la planta: alcance, cambios, arranque y cierre. El líder funcional aprueba todo lo que define el proceso y la calidad del dato. IT aprueba lo que ocurre en su infraestructura.

La fila 6 es la única donde el sponsor aprueba una definición de datos, y hay un motivo. Qué sistema manda sobre repuestos, proveedores o centros de costo es una discusión entre áreas con reclamos legítimos: mantenimiento necesita registrar consumos en la OT, y administración necesita que el inventario contable siga cerrando en el ERP. Si ninguna de las dos puede imponerse, la decisión sube.

Algunas filas se apoyan en trabajos que exceden a la matriz. Cómo limpiar y validar la carga de la fila 5, cómo diseñar los perfiles de la fila 7 y con qué criterios decidir la fila 10 son discusiones propias de la migración de datos, del diseño de permisos y de la preparación del arranque. La matriz solo asigna quién firma cada una.

La asignación es un punto de partida, no una norma. En una planta donde el gerente participa todos los días, el arranque puede quedar en manos del líder funcional. En una operación con ERP corporativo administrado desde otra sede, la fila 6 probablemente se decide fuera de la planta.

Antes del kickoff, escribí un nombre, no un área, en cada A. Las filas donde no aparece un nombre son los riesgos del proyecto.

Cuando una persona cubre varios roles

En una planta con un jefe de mantenimiento, dos supervisores y un planner que además atiende el pañol, pensar en seis roles separados no tiene sentido. Acumular roles es lo normal. Lo que hay que cuidar es que una combinación no elimine un control.

La condición que más pesa es la del segundo renglón. Cuando la misma persona lidera el proceso y coordina el proyecto, el tiempo del proyecto compite todos los días con los correctivos, y ahí el proyecto pierde: la bomba centrífuga que pierde por el sello tiene una urgencia visible; la definición de estados de OT, no. Bloquear franjas fijas en la semana, avisadas a producción y a los supervisores, evita que esa competencia se resuelva cada día a favor del correctivo.

Cuánta dedicación pedirle a cada área

Pedir “participación de mantenimiento” no sirve para planificar. Cada área necesita saber en qué fase sube su dedicación y durante cuánto tiempo, para cubrir turnos o reprogramar trabajos.

La tabla muestra la forma de la curva, no su tamaño: las horas reales dependen del alcance, de la cantidad de áreas y de las integraciones.

Dos patrones se desprenden de la curva. El líder funcional sostiene una carga alta durante las tres primeras fases; si además coordina el proyecto, conviene revisar su agenda antes de fijar fechas. Los responsables de datos concentran su esfuerzo en una ventana corta: si esa ventana coincide con una parada programada o con el cierre contable, la carga piloto se corre.

Esa dedicación tiene un costo real aunque no figure en la cotización del proveedor. Cómo valorizar las horas internas dentro del costo total de un CMMS permite comparar propuestas que trasladan más o menos trabajo al equipo del cliente.

Qué pasa con el equipo después del arranque

El proyecto termina; el sistema sigue. Si al cierre nadie hereda las responsabilidades, a los pocos meses aparecen activos creados por cualquier usuario, campos obligatorios agregados a pedido de un supervisor y reportes que dejan de conciliar con el ERP.

El punto que más se descuida es el control de cambios. Durante el proyecto, agregar un campo obligatorio pasa por el líder funcional. Después del arranque, ese mismo pedido suele llegar directo al administrador del sistema, que lo resuelve en cinco minutos. Cada cambio aislado parece razonable; sumados, pueden llevar al técnico que antes cerraba la OT desde el celular a volver a anotar en papel y cargar al final del turno. Dejar escrito quién aprueba cambios de configuración, y con qué frecuencia se revisan, es parte del traspaso.

Sostener el uso real después del lanzamiento tiene su propia lógica, desarrollada en la guía sobre adopción del CMMS en el equipo técnico. Qué indicadores muestran que la implementación funcionó, y cómo se reparten los roles entre la sede central y cada planta cuando el sistema se extiende a varias operaciones, son análisis aparte.