Puntos clave
Vea los tipos de órdenes de trabajo que estas alertas deberían generar.
En una planta típica, el sistema de OEE vigila la línea y el CMMS vigila el activo. Ambos ven "paradas", pero cada uno ve una versión distinta. El lado de OEE captura toda parada por encima de algún umbral. El lado de mantenimiento solo captura las que se convirtieron en órdenes de trabajo.
La brecha entre esos dos números, generalmente del 20% al 40% del tiempo total de inactividad, es donde viven las pequeñas pérdidas recurrentes. Esas pequeñas pérdidas son también donde reside la mayor parte de la mejora alcanzable.
La razón por la que existe la brecha no es que un equipo esté haciendo el trabajo equivocado. Es que los dos sistemas no tienen una definición compartida de "esta parada necesita una orden de trabajo". El operador decide, el supervisor decide, a veces nadie decide, y las reglas derivan línea por línea.
Un modelo operativo de mantenimiento es el conjunto de reglas explícitas que convierten cada evento de OEE en un resultado binario: se abre una orden de trabajo, o no.
Un sistema de OEE sin una taxonomía clara de clases de pérdida es solo un temporizador agregado. El modelo operativo comienza por colapsar cada parada en un conjunto estable de clases, normalmente de siete a diez.
Comunes: cambio de formato, microparada, avería mecánica menor, eléctrica/sensor, falta de material, rechazo de calidad, exceso planificado, provocado por el operador. La lista exacta es menos importante que que la misma lista se use en todas partes, en todos los turnos y en todas las líneas.
El artículo sobre KPI de fabricación cubre las familias de KPI subyacentes a las que esta taxonomía se conecta.
Cada clase necesita una regla: ¿a partir de qué duración o frecuencia este evento se convierte en una orden de trabajo? Los umbrales casi siempre están equivocados el primer día y se ajustan en las semanas dos a seis. Lo que importa es que la regla exista y sea visible. Ejemplos de umbrales típicos iniciales:
Las reglas de umbral por agrupación ("3 veces en 8 horas") tienden a atrapar las pequeñas pérdidas recurrentes que los umbrales de evento único no capturan. Son el tipo de regla de mayor rendimiento para añadir.
Cada clase de pérdida tiene un responsable nombrado, no un departamento. Las averías mecánicas menores y las eléctricas van al gerente de mantenimiento. Los cambios de formato y lo provocado por el operador van al gerente de producción. La falta de material va al planificador. El rechazo de calidad va al responsable de calidad.
El responsable no necesariamente realiza la reparación, pero es dueño de la tendencia y del umbral. Cuando una clase se está disparando, el responsable actúa primero.
La regla más importante y la que más se omite.
Cuando un evento de OEE abre automáticamente una orden de trabajo, deben ocurrir dos cosas en el mismo minuto: el técnico de mantenimiento ve la orden de trabajo en un dispositivo móvil, y el registro de OEE se vincula a la orden para que el cierre fluya de vuelta.
Sin ese enlace bidireccional, el modelo operativo degenera en "OEE crea ruido, CMMS lo ignora" en el plazo de un trimestre. Un CMMS listo para uso en campo en el teléfono del técnico es lo que hace que esto funcione.
El artículo sobre sistemas de gestión de órdenes de trabajo profundiza en las piezas móviles.
Puesto que los umbrales por agrupación capturan la misma falla que se dispara tres veces antes de que alguien la hubiera notado, las pequeñas pérdidas recurrentes, las que actualmente son invisibles, empiezan a aparecer en el backlog de mantenimiento con una vía de solución real.
La mayoría de las plantas descubre que esta categoría por sí sola suele representar una gran proporción, frecuentemente del 15-25%, del tiempo de inactividad no planificado una vez expuesta. Vea el tratamiento más profundo en nuestro artículo sobre análisis de causa raíz en la fabricación .
Cuando cada evento relevante de OEE se convierte en una orden de trabajo, el CMMS finalmente ve la población completa de fallos. MTBF y MTTR empiezan a reflejar la realidad en lugar del subconjunto que los operarios o supervisores decidieron escalar. El efecto aguas abajo es que los programas de mantenimiento preventivo pueden ajustarse con datos reales de fallos en lugar de recomendaciones del proveedor.
Puesto que el evento de OEE y la orden de trabajo comparten un ID, el gerente de producción y el gerente de mantenimiento están mirando la misma fila. La reunión matutina pasa de "¿quién tiene el número correcto?" a "¿qué clase de pérdida se movió la semana pasada?".
Ese cambio único es el desbloqueo operativo que la mayoría de las plantas de mercado medio buscan al comprar un sistema de OEE, y casi nunca viene solo del software de OEE.
Un error común es lanzar 30 reglas de activación en el go-live. La mitad están equivocadas, todas crean ruido, y el equipo de mantenimiento desactiva la integración en la semana tres. Empiece con cinco o seis reglas. Añada una por semana basada en lo que está faltando.
Si la orden de trabajo se cierra pero el evento de OEE permanece "abierto" en el registro de pérdidas, los números de OEE y los del CMMS vuelven a separarse, a veces en semanas. El cierre debe fluir en ambos sentidos. Aquí es donde muchas pilas acopladas de OEE más CMMS fallan en la práctica.
Si una clase dispara una orden de trabajo pero no hay un responsable nombrado que vigile la tendencia, la orden se hace, la pérdida se repite y nada cambia. El responsable nombrado es lo que transforma volumen en mejora.
El modelo operativo anterior puede implementarse en cualquier arquitectura bien instrumentada, pero la razón práctica por la que las plantas de mercado medio luchan para hacerlo funcionar es que una herramienta de OEE y un CMMS separado rara vez comparten un enlace limpio evento/orden de trabajo.
Fabrico se construyó alrededor de este traspaso exacto: cada evento de OEE vive en la misma base de datos que las órdenes de trabajo, la jerarquía de activos y la taxonomía de pérdidas, de modo que las reglas disparadoras y las rutas de cierre existen por defecto en lugar de como una integración a medida.
Si quiere ver cómo se ve un modelo unificado con los datos de su propia línea, reserve una demo y la revisaremos con usted.
No, pero el problema de la ruta de cierre es difícil de resolver de forma limpia entre dos sistemas separados. Las plantas con pilas divididas suelen necesitar una capa de middleware o un paso de conciliación manual que se erosiona en el plazo de un trimestre. Una plataforma unificada elimina ese riesgo.
Cinco o seis. La tentación es definir todas las reglas el primer día; la realidad es que la mayoría de las reglas necesita 4, 6 semanas de datos reales antes de que el umbral sea el correcto. Un conjunto pequeño inicial afinado durante el primer trimestre supera a un conjunto completo desplegado en frío.
Operativamente, el gerente de la planta. El gerente de mantenimiento y el gerente de producción son responsables de sus respectivas clases. Sin un único responsable a nivel de planta del propio modelo, los umbrales derivan, los responsables nombrados rotan sin traspaso y el modelo se deteriora.
Muy poco al principio. El operario sigue registrando las paradas de la misma manera. Lo que cambia es que el sistema ahora decide si cada parada se convierte en una orden de trabajo, por lo que el operario no tiene que tomar esa decisión turno a turno. Con el tiempo el operario verá menos pequeñas pérdidas recurrentes porque las reglas disparadoras las captan antes.
Dos números: la proporción del tiempo de inactividad no planificado que tiene una orden de trabajo vinculada (objetivo: por encima del 80% en 90 días), y el conteo rodante de órdenes de trabajo generadas por reglas de umbral por agrupación (debe mantenerse distinto de cero; si llega a cero, las reglas ya no están captando nada nuevo).
Iniciar sesión
Blog
