Puntos clave
Un piloto de OEE tiene como objetivo responder a una pregunta: ¿funcionará esto aquí? Demasiados pilotos fracasan no porque el software sea malo, sino porque nadie definió cómo se vería el éxito. Defínalo desde el principio y el piloto le dará un sí o un no claro.
Decida de antemano lo que el piloto debe demostrar: capturar datos precisos automáticamente, sacar a la luz pérdidas que el equipo no detectaba o lograr una mejora medible en la línea. Escriba estos criterios de éxito antes de la puesta en marcha, de modo que el resultado sea un hecho, no un argumento.
Elija una única línea que represente sus condiciones reales, idealmente una con pérdidas significativas por descubrir, no su mejor ni su peor rendimiento. Un piloto representativo le indica lo que realmente ofrecería un despliegue más amplio.
Registre el rendimiento actual de la línea antes del piloto, para poder mostrar el cambio. Fije un plazo claro, lo bastante largo para capturar patrones reales pero lo bastante corto para mantener el impulso. Un piloto abierto pierde impulso; uno acotado ofrece un veredicto.
El piloto vive o muere según si los operarios y supervisores se comprometen con él. Involúcrelos en la configuración, explíqueles para qué sirven los datos y deje claro que es una herramienta para encontrar pérdidas, no para vigilar a las personas. La adopción marca la diferencia entre datos ricos del piloto y una pantalla ignorada.
Una planta prueba OEE en una línea representativa, fija una ventana de cuatro semanas, establece la línea base de la disponibilidad actual y define el éxito como capturar microparadas que el equipo no puede ver actualmente y actuar sobre la más importante.
En la segunda semana, la captura automatizada revela una parada corta recurrente que nadie había registrado; al solucionarla, la línea mejora. El éxito fue evidente porque se definió desde el primer día.
Un piloto es la manera más segura de demostrar que el OEE en tiempo real dará beneficios antes de un compromiso a nivel de planta. Criterios claros lo convierten de una prueba en evidencia. Reserve una demo de Fabrico para definir el alcance de un piloto de OEE centrado en una de sus líneas.
Hacer bien el diseño del piloto de software de fabricación decide si un despliegue tiene éxito.
Lo suficiente para capturar patrones reales de producción, a menudo unas semanas, pero acotado para que se mantenga enfocado. Un piloto sin límite pierde impulso y nunca alcanza un veredicto.
Falta de criterios de éxito definidos y poca adopción. Si nadie acordó qué significa el éxito, o el equipo no se involucra, incluso buenos datos no llevan a ninguna parte.
Los pilotos de software OEE sin criterios de éxito predefinidos casi siempre terminan en conclusiones ambiguas.
El proveedor está satisfecho porque no ocurrió nada catastrófico; el equipo de TI es escéptico porque la integración llevó más tiempo del esperado; el responsable de producción está cautelosamente optimista porque los datos parecen más o menos correctos; y el director de planta no está seguro de si las cifras justifican la compra.
Sin un acuerdo sobre cómo se define el éxito antes de que comience el piloto, cada interesado evalúa el piloto a través del prisma de sus propias preocupaciones, y la discusión posterior al piloto se convierte en un debate sobre si las preocupaciones fueron atendidas adecuadamente en lugar de una evaluación objetiva de si se cumplieron los criterios.
Los criterios de éxito predefinidos cambian la conversación posterior al piloto de subjetiva a objetiva.
Cuando el equipo de evaluación acordó antes del piloto que "el éxito requiere una precisión en la recopilación de datos superior al 95% para al menos el 80% de los turnos monitorizados", la discusión posterior se centra en si ese umbral se alcanzó, no en si una precisión del 93% es suficiente.
Esta especificidad resulta incómoda para los proveedores que prefieren criterios más vagos, lo cual en sí mismo es informativo: los proveedores que se resisten a criterios específicos de éxito tienen menos confianza en su capacidad para cumplirlos que aquellos que participan de manera constructiva en la definición de umbrales medibles.
El proceso de definición de los criterios de éxito también obliga a alinear a la organización antes de que comience el piloto.
Los distintos interesados tienen definiciones de éxito diferentes: TI quiere cumplimiento de seguridad, operaciones quiere precisión de datos, finanzas quiere evidencia del ROI, y el director de planta quiere adopción por parte de los operarios.
Poner de manifiesto estas distintas definiciones antes del piloto y reconciliarlas en un documento de criterios compartido asegura que el piloto genere evidencia sobre todas las dimensiones de interés para las partes implicadas, no solo las que el responsable del equipo de evaluación considere más importantes.
Categoría 1, Precisión de la recopilación de datos: Defina la brecha aceptable entre las lecturas de la plataforma OEE y sus fuentes de datos existentes (contadores de producción, registros de turno) para los recuentos de producción, la duración de los tiempos de inactividad y los recuentos de rechazos de calidad.
Un umbral inicial razonable es ±3% para los recuentos de producción y ±5 minutos por turno para la duración de los tiempos de inactividad. Especifique cuántos turnos deben cumplir este umbral (p. ej., el 85% de los turnos durante el período piloto) y qué constituye una falla en la recopilación de datos que requiera investigación.
Categoría 2, Adopción por parte de los operadores: Defina la tasa mínima de categorización de tiempos de inactividad (porcentaje de eventos de inactividad categorizados por los operadores dentro de una ventana temporal definida) que indique que la interfaz de operador es funcional.
Un umbral del 75% o más de categorización dentro de 2 horas es un punto de partida práctico.
También especifique la inversión aceptable en formación: si los operadores requieren más de 4 horas de formación inicial para usar correctamente el sistema, eso es una señal de usabilidad que merece documentarse como un incumplimiento del criterio incluso si se alcanzan las tasas de categorización.
Categoría 3, Fiabilidad de la integración: Si la integración con ERP o CMMS está dentro del alcance del piloto, defina la tasa de éxito en la transferencia de datos requerida. El mínimo aceptable es el 99% de las confirmaciones de órdenes de producción transferidas correctamente dentro del SLA definido (p.
ej., dentro de los 15 minutos posteriores al fin de turno). Especifique cómo se detectan y reportan las fallas de integración y cuál es el compromiso de tiempo de respuesta del proveedor para las fallas de integración.
Categoría 4, Rendimiento del sistema: Defina la latencia máxima aceptable para que los datos de producción aparezcan en el panel OEE tras un evento real (2 minutos como máximo es típico), y la disponibilidad mínima del sistema durante las horas de producción planificadas (mínimo 99,5%).
Especifique cómo se mide el tiempo de inactividad, desde el sistema de monitorización del proveedor o a partir de marcas de tiempo verificadas de forma independiente, para evitar disputas sobre si se cumplieron los criterios.
Categoría 5, Usabilidad de informes y analítica: Defina informes específicos que deben generarse con éxito durante el piloto sin asistencia del proveedor, por ejemplo, un Pareto de 30 días de tiempos de inactividad por equipo, una tendencia semanal de OEE por línea y una comparación de rendimiento por turno.
Si el equipo de evaluación no puede generar estos informes de forma independiente para la semana 3 del piloto, esto indica un problema de usabilidad o configuración que debe resolverse antes del despliegue completo.
Categoría 6, Evidencia de ROI: Para pilotos de duración suficiente, defina qué mejoras en el rendimiento de producción se espera que sean visibles en los datos de OEE como resultado de la visibilidad de monitorización que proporciona el software.
Este criterio es más difícil de especificar rigurosamente en un piloto de 30 días (la atribución causal es complicada), pero incluso la evidencia cualitativa, acciones de mejora concretas tomadas basadas en los conocimientos de OEE que no se habrían tomado sin los datos, puede documentarse e incluirse en la recomendación de continuar o no con el proyecto.
El proceso de aprobación para la decisión go/no-go de un piloto de OEE debe involucrar a las mismas partes interesadas que definieron los criterios de éxito, no solo al líder del equipo de evaluación.
Programe la reunión de revisión posterior al piloto antes de que comience el piloto y exija que cada parte interesada aporte una evaluación escrita de los criterios en su ámbito (TI evalúa los criterios de seguridad e integración operaciones evalúa la precisión de los datos y la adopción por parte de los operarios
finanzas evalúa la evidencia de costes y ROI). Este compromiso previo con evaluaciones escritas evita que las partes interesadas asistan a la reunión de revisión sin haber realizado el trabajo de evaluación.
La agenda de la reunión posterior al piloto debe cubrir: resultados de la evaluación de criterios (decisión go/no-go para cada criterio y la base de evidencia) asuntos abiertos (criterios no totalmente cumplidos, con compromisos del proveedor y cronogramas para su resolución)
evaluación del desempeño del proveedor (calidad de la implementación, capacidad de respuesta y calidad del soporte durante el piloto) y una recomendación.
La recomendación debe ser uno de tres resultados: go (todos los criterios cumplidos, proceder al despliegue completo); go con condiciones (la mayoría de los criterios cumplidos, pero asuntos específicos requieren resolución contractual antes de comprometerse al despliegue completo); o no-go (criterios críticos fallidos, lo que exige un cambio de proveedor o una reconsideración fundamental de los requisitos).
Documente la decisión posterior al piloto y la base de evidencia en un informe escrito de conclusiones del piloto que se comparta con todas las partes interesadas y se archive en el expediente del proyecto.
Esta documentación protege al equipo de evaluación si el despliegue presenta problemas posteriormente: demuestra que la decisión se tomó en base a criterios objetivos y evidencia documentada, y no por relaciones con el proveedor o por una evaluación incompleta.
Además, ofrece al proveedor un informe claro sobre lo que necesita mejorar antes o durante el despliegue completo, lo que incrementa la probabilidad de que el despliegue total tenga éxito.
Iniciar sesión
Blog
