Roles y permisos en un CMMS: cómo diseñar la matriz sin trabar la operación

Turno noche, línea de llenado 2. A las 3:40 el técnico cambia el sello mecánico de la bomba de CIP, la prueba con el operador y la línea vuelve a producir. Cuando intenta cerrar la orden de trabajo, el sistema no lo deja: cerrar OT es un permiso del supervisor, y el supervisor entra a las 7. La OT queda “en ejecución” cuatro horas más. Si se repite durante un mes, el backlog muestra trabajo que ya está hecho y, si el tiempo de reparación se calcula con las fechas de la OT, absorbe horas en las que nadie estaba reparando nada.

En otra planta, durante la configuración inicial, se dio perfil de administrador a medio equipo “para que nadie se trabe”. Seis meses después, una OT validada y presentada en una auditoría tiene otra descripción de la falla, y el sistema no permite reconstruir quién la cambió ni por qué.

Las dos fallas vienen del mismo error de diseño. Los roles y permisos de un CMMS se definieron a partir de los menús del software y no de lo que cada persona necesita hacer durante el ciclo de una orden de trabajo. Este artículo propone otra forma de armar la matriz: cruzar acción, objeto, alcance y estado de la OT. Incluye una matriz base por perfil, las excepciones que la matriz tiene que soportar y un método para probarla antes del arranque.

Una matriz de permisos útil da a cada perfil lo que necesita para completar su parte del trabajo y nada más. El técnico registra y cierra lo que ejecutó. El supervisor valida. El planner programa. Muy pocas personas modifican datos maestros, reabren órdenes cerradas o configuran el sistema. Antes de salir en vivo, la matriz se prueba con usuarios de cada perfil sobre escenarios reales.

Qué decide esta matriz y qué queda fuera

En una implementación, la palabra “rol” se usa para tres cosas. El rol en el proyecto define quién decide y quién aprueba durante la implementación, y se asigna en la matriz RACI del equipo de implementación CMMS. La gestión de accesos resuelve cómo se autentica cada usuario, cómo se da de alta y de baja y cómo se integra con el directorio corporativo. El perfil en el sistema define qué puede ver, crear, cerrar, aprobar o configurar cada usuario dentro del CMMS.

La RACI define quién firma la matriz de permisos y la gestión de accesos define cómo entra cada usuario al sistema. Lo que sigue trata solo del contenido de la matriz: qué puede hacer cada perfil una vez que ingresó.

Dos maneras de fallar: la matriz que traba y la que no controla

Una matriz demasiado restrictiva no se nota en la configuración. Se nota semanas después en los datos, porque la gente encuentra atajos. Una matriz demasiado abierta tampoco da problemas al principio: el daño aparece cuando alguien necesita reconstruir qué pasó.

La tabla no se ordena de “menos” a “más” control porque las dos direcciones fallan. Las fallas por exceso de restricción producen datos ausentes o tardíos. Las fallas por exceso de apertura producen datos que no se pueden defender. En las dos el CMMS deja de reflejar lo que pasó en planta.

Las cuatro dimensiones de un permiso

La mayoría de las pantallas de configuración presentan los permisos por módulo: órdenes de trabajo, activos, inventario, reportes. Es una forma cómoda de configurar, pero no sirve para diseñar, porque “acceso al módulo de OT” no dice nada sobre si el técnico puede reabrir una orden validada.

Para diseñar conviene descomponer cada permiso en cuatro dimensiones:

La cuarta dimensión es la que más se omite en las matrices armadas por menú, y la que resuelve más conflictos. Que un técnico pueda editar la descripción de la falla mientras la OT está en ejecución es razonable. Que pueda hacerlo después de la validación del supervisor, no. Es el mismo permiso sobre el mismo objeto, y lo que cambia la respuesta es el estado.

Este enfoque es una aplicación práctica del control de acceso basado en roles (RBAC) descrito por NIST: los permisos se asignan a perfiles y las personas reciben perfiles, no permisos sueltos. Se combina con dos principios que el catálogo de controles NIST SP 800-53 formula como mínimo privilegio (AC-6) y separación de funciones (AC-5). Aplicados al mantenimiento, significan que cada perfil recibe lo que necesita para su parte del flujo y que la misma persona no ejecuta y valida su propio trabajo cuando ese trabajo requiere control.

Una aclaración operativa: el mínimo privilegio no es “lo mínimo posible”. Es lo mínimo necesario para completar la tarea. Si el técnico no puede cerrar su OT, el perfil no es mínimo: está incompleto.

Antes de cerrar el diseño hay que comprobar en el CMMS cuáles de las cuatro dimensiones se pueden configurar y cuáles hay que resolver por procedimiento. Una restricción que el sistema no aplica puede sostenerse con una regla escrita y una revisión periódica, siempre que alguien tenga asignada esa revisión.

Matriz base de roles y permisos por perfil

La siguiente matriz es un punto de partida para una planta con mantenimiento propio, pañol y algunos contratistas. No es una configuración para copiar: cada fila se ajusta según cómo trabaja la operación. Sirve para que la discusión empiece por las tareas de cada perfil y no por los nombres de los menús.

La última columna es la que más ayuda en las reuniones de diseño. Discutir qué no debería hacer cada perfil obliga a explicitar los riesgos. Si alguien pide que el planner pueda validar cierres, la pregunta es qué control se pierde y si la operación lo compensa de otra manera, por ejemplo con una revisión semanal del jefe.

Quién cierra, quién valida y quién reabre una OT

En la matriz, este es el punto donde más pesan las fallas por traba y las fallas por falta de control. La propuesta es separar dos momentos que muchos sistemas tratan como uno solo:

Con esta separación, el técnico del turno noche cierra su OT a las 3:40, el tiempo de reparación termina cuando terminó la reparación y el supervisor valida a las 7. El control se mantiene sin frenar el registro. El flujo completo de estados, con la aprobación del cierre como último paso, se desarrolla en el artículo sobre el sistema de órdenes de trabajo de mantenimiento.

Si el flujo configurado no distingue los dos estados, la validación puede sostenerse con una revisión diaria de los cierres del turno anterior, a cargo del supervisor. Lo que no conviene es resolverlo quitándole al técnico el permiso de cerrar.

La reapertura merece una regla propia: pocas personas la autorizan, siempre con un motivo, y el cierre original no se sobrescribe. Si la corrección de una OT validada borra lo que se había registrado, el historial pierde justamente lo que una auditoría o un análisis de falla repetitiva necesitan ver.

Datos maestros: activos, catálogos y planes preventivos

El técnico es quien primero descubre que falta un equipo en el árbol: un ventilador agregado en la última parada o una bomba de reserva que nunca se cargó. Si no tiene forma de reportarlo, la OT se imputa al activo “más parecido” y el historial queda mal desde el primer día. Si puede dar de alta activos libremente, aparecen los duplicados.

La regla práctica es que el técnico propone y una persona designada da de alta. La propuesta puede ser una solicitud con foto de la placa y la ubicación. El alta la hace quien conoce la codificación y la jerarquía del árbol de activos. Con los catálogos de fallas, causas y tipos de trabajo pasa lo mismo: si cada usuario agrega valores, en tres meses “rodamiento dañado” y “falla de rodamiento” son dos categorías distintas en el reporte.

Los planes preventivos siguen la misma lógica, con un matiz. El planner necesita editarlos, porque ajustar frecuencias y tareas es su trabajo. Pero cambiar el plan de un activo crítico, como el compresor principal o el tablero general, conviene que deje registro y pase por el jefe de mantenimiento. Los campos mínimos que tienen que estar definidos antes de cargar cada maestro se detallan en el checklist de datos mínimos para implementar un CMMS.

Costos, repuestos y compras

En costos importa tanto quién los ve como qué costo ve. El costo de repuestos de una OT es un dato técnico que al planner y al jefe les sirve para decidir. El costo de mano de obra se calcula con una tarifa horaria. Cuando esa tarifa es la de cada persona, un técnico que ve el costo de la OT de un compañero puede deducir cuánto cobra, y esa información pertenece a recursos humanos. Si el sistema no permite separar la visibilidad de los dos costos, una alternativa es valorizar la mano de obra con una tarifa estándar por especialidad, que no expone a nadie.

En repuestos y compras, la separación de funciones tiene una forma concreta: quien solicita una compra no la aprueba, y quien recibe la mercadería no es quien la pidió, al menos por encima de cierto monto. En muchas plantas ese circuito ya existe en el ERP. En ese caso la matriz del CMMS solo tiene que no contradecirlo.

Excepciones que una matriz real tiene que soportar

Una matriz diseñada para el turno de día, con todos presentes, falla la primera noche. Estas son las excepciones que conviene resolver antes del arranque y no cuando aparecen:

Cuando una excepción no tiene regla, la gente la resuelve con el usuario de otra persona. Ese atajo es más difícil de detectar que cualquier permiso mal asignado.

Para el trabajo sin conexión hay que hacer una verificación adicional. Si se cambia el perfil de un usuario mientras está en campo sin señal, hay que saber qué permisos rigen en el dispositivo hasta que sincroniza y qué pasa con lo que registró en ese lapso. Conviene incluir ese caso entre los escenarios de prueba de la matriz.

Cuántos perfiles conviene tener

La tentación es crear un perfil por persona: “el de Juan, que además maneja el pañol los sábados”. Funciona hasta que Juan cambia de puesto y nadie recuerda qué tenía su perfil ni por qué. Un perfil por persona no se puede mantener ni auditar.

El criterio que mejor resiste el tiempo es tener pocos perfiles estables, definidos por función, y resolver las diferencias con el alcance (planta, cuadrilla, empresa contratista) en lugar de crear perfiles nuevos. Si alguien cumple dos funciones, recibe dos perfiles, siempre que la combinación no rompa una separación que la matriz quería mantener. Por ejemplo, la misma persona no debería quedar como solicitante y aprobadora de compras.

El diseño de perfiles también tiene consecuencias sobre las licencias. Si los operadores de producción solo necesitan reportar fallas y seguir el estado, no hace falta darles un perfil completo. En OTEX el módulo de solicitudes admite solicitantes ilimitados desde el plan Standard, como se detalla en qué incluye OTEX CMMS y cómo se licencia. Eso permite que producción cargue sus avisos en el sistema sin consumir licencias de usuario, y es una de las formas más directas de sacar las fallas de WhatsApp.

Cómo probar la matriz antes del arranque

Una matriz que nunca se probó con usuarios reales solo es una hipótesis. Si la prueba se hace con el usuario administrador del proyecto, todo funciona porque el administrador puede hacer todo.

Estos escenarios negativos suelen encontrar los problemas que la revisión en pantalla no muestra:

Si durante la capacitación un usuario no completa una tarea, conviene descartar primero que sea un problema de permiso antes de suponer una falta de competencia. Ese diagnóstico está desarrollado en el plan de capacitación CMMS por roles. La prueba de la matriz es además uno de los controles de preparación del arranque.

Mantener la matriz viva después del go-live

La matriz cambia con la operación: se suma un contratista, se crea un segundo turno, una persona asume el pañol, se incorpora una sede. Si cada cambio se resuelve con un pedido por chat al administrador, en un año la matriz documentada y la configuración real son dos cosas distintas.

Quién cumple cada uno de esos roles permanentes queda asignado al cierre del proyecto de implementación.

Las altas y bajas de personas no forman parte de esta revisión. Cuando alguien deja la empresa, el problema es de gestión de identidades: desactivar el acceso, revisar dispositivos, transferir pendientes. Es otra discusión, que corresponde a IT y a la política de accesos de la empresa.

La definición de usuarios y roles forma parte del relevamiento y la parametrización que incluyen los servicios de implementación de OTEX. El marco general del proyecto está en la guía para implementar un CMMS sin frenar la operación.