La línea vuelve a estar en marcha. Justo ahí empieza a empeorar la historia de la parada.
A las 10:14, envasado se detuvo. A las 11:01, volvió a arrancar. El primer código de motivo dice “ajuste de operario”. El plan sigue apretado, mantenimiento no tiene una orden de avería abierta y calidad no ha puesto el lote en retención. Un panel puede cerrar el evento en una fila limpia.
La planta se ve menos limpia desde el suelo. La lista de alarmas muestra un aviso breve de baja presión antes de la parada. La nota del operario menciona producto desalineado después del reinicio. Una orden de trabajo de la tarde anterior cambió un racor neumático cerca del punto de transferencia. El código puede ser cierto: alguien ajustó la línea. También puede ser el dato menos útil del expediente.
El análisis de paradas no debería empezar por la etiqueta escrita después de recuperar producción. Debería empezar por evidencia operativa con fuente. APQC define la parada no planificada como parte del tiempo de ejecución programado, no como una categoría de culpa (benchmark de APQC sobre paradas). ISA-95 existe porque la información de planta cruza capas de empresa, operaciones y control que necesitan estructura común (ISA-95). Un registro serio tiene que respetar ambas ideas.
Trata el código de motivo como evidencia, no como veredicto
Los códigos de motivo son útiles. Dan a la planta un vocabulario compartido para pérdidas, permiten comparar turnos y evitan que cada reunión diaria dependa de memoria oral. Pero un código es una clasificación. No es el evento completo.
La diferencia importa porque muchos códigos se introducen bajo presión. La línea acaba de arrancar. El siguiente pedido espera. El operario tiene que elegir una opción de un menú que quizá no coincide con la secuencia real. El supervisor necesita una gráfica clara antes de la reunión de producción. “Ajuste de operario” puede describir la acción visible que permitió continuar, mientras la ventana del evento apunta a inestabilidad de presión, seguimiento de material o un cambio reciente de mantenimiento.
La medida de APQC ancla la pregunta en tiempo programado y pérdida no planificada, lo que mantiene el análisis unido a pérdida operativa y no a una etiqueta posterior (benchmark de APQC sobre paradas). El trabajo de NIST sobre medición del rendimiento desde operaciones encaja porque se centra en recopilar y analizar datos operativos para identificar problemas de rendimiento (medición de rendimiento de NIST). Juntas, esas fuentes llevan a una regla práctica: el código pertenece al paquete de evidencia, al lado del tiempo, el estado de línea, las alarmas, las notas, las órdenes de trabajo y el impacto.
El primer paquete de una parada debería incluir ventana programada, inicio del evento, fin del evento, hora de reinicio, estado antes de la parada, código seleccionado, persona o sistema que lo introdujo, alarmas, notas de operario, órdenes relevantes, estado de calidad y próxima pregunta de verificación. Ese paquete no ralentiza el análisis. Evita que la explicación más cómoda se convierta en oficial antes de comprobarla.
Hay una disciplina pequeña, pero incómoda: no preguntar demasiado pronto “cuál fue la causa”. Pregunta primero qué evidencia sostiene la clasificación actual y qué evidencia la limita. La primera pregunta invita a una historia segura. La segunda crea un registro revisable.
Para WizeeMind, la salida debe leerse como una tabla de evidencia, no como una sentencia. “Código actual: ajuste de operario. Evidencia de apoyo: ajuste de guía a las 10:16. Evidencia que limita: alarmas de baja presión a las 10:11 y 10:22; sustitución reciente de racor cerca del punto de transferencia; nota de producto desalineado tras reinicio”. Eso no es indecisión. Es análisis haciendo su trabajo.
Reconstruye la ventana del evento antes de debatir la causa
La ventana del evento es más que hora de inicio y hora de fin. Es la secuencia operativa alrededor de la parada: último estado normal conocido, primera señal anómala, declaración de parada, acciones manuales, alarmas, cambios de consigna, intervenciones, intentos de reinicio y retorno a operación estable. Si el equipo salta esa secuencia, la conversación pasa de “la línea se detuvo” a “alguien la causó”.
Aquí los datos de planta se parecen menos a una hoja de cálculo y más a una caja negra. Una caja negra no decide por qué ocurrió el incidente. Conserva tiempos, señales, comandos y contexto para que personas formadas reconstruyan qué cambió. La parada necesita esa misma humildad. El rastro tiene que sobrevivir a la reunión.
El proyecto de NIST sobre rendimiento desde operaciones conecta la fabricación inteligente con caracterización de sistemas, identificación de problemas de rendimiento y marcos de diagnóstico (medición de rendimiento de NIST). ISA-95 ayuda a ubicar dónde puede vivir cada pieza de la traza, porque programas de producción, registros MES, señales de control, órdenes de mantenimiento y estado de calidad suelen estar en capas distintas (ISA-95).
En la parada de 47 minutos, la línea temporal podría verse así: 10:07, línea a ritmo estándar. 10:11, aparece una alarma de baja presión y se borra tras 18 segundos. 10:14, MES registra inicio de parada. 10:16, el operario ajusta la guía y retira producto desalineado. 10:22, la alarma se repite durante el intento de reinicio. 10:29, mantenimiento comprueba suministro local de aire, pero no abre orden de avería. 10:48, la línea arranca a ritmo reducido. 11:01, vuelve a ritmo estándar y la parada se cierra.
Esa secuencia cambia la siguiente acción. El código sigue dentro de la historia, pero ya no la controla. Supervisión puede mantener el código y añadir una comprobación de presión. Mantenimiento puede inspeccionar el racor sustituido. Calidad puede revisar unidades fabricadas durante el reinicio inestable. Los mismos 47 minutos producen mejor trabajo.
WizeeMind debería obligar a que la ventana sea visible: sistema fuente, marca temporal, identificador de registro, objeto de planta y afirmación que soporta. Una alarma soporta una señal anómala. Una nota soporta un síntoma observado. Una orden de trabajo soporta actividad reciente. Ninguna de esas piezas prueba la causa por sí sola. El paquete debe mostrar esa frontera porque un párrafo pulido puede hacer que evidencia débil parezca fuerte.
Acerca mantenimiento al expediente sin convertir cercanía en prueba
La evidencia de mantenimiento puede explicar una parada. También puede distorsionar la revisión cuando el equipo trata una orden cercana como causa sin comprobar mecanismo. Un racor sustituido la noche anterior antes de una alarma de presión es una pista. No es prueba. Una orden cerrada puede demostrar que hubo trabajo, pero quizá no demuestra que las comprobaciones de retorno a servicio cubrieran el modo de fallo posterior.
NIST describe los datos de mantenimiento como procedentes de registros generados por personas, como órdenes de trabajo, y de fuentes generadas por equipos, como monitorización y diagnóstico (estrategias de mantenimiento de NIST). Douglas S. Thomas, Economist en el National Institute of Standards and Technology, plantea el valor del mantenimiento avanzado en fabricación como un problema de coste que incluye mantenimiento directo, reparación, paradas, ventas perdidas, retrabajo, defectos y la estrategia que hay detrás de esas pérdidas (economía del mantenimiento de NIST). La advertencia es útil: el análisis debe preservar categorías, no convertir todo en una causa cómoda.
Un paquete de parada debería colocar mantenimiento en la misma vista con etiquetas claras: número de orden, estado, identificador de activo, tarea solicitada, código de reparación si existe, notas del técnico, piezas ajustadas o sustituidas, mediciones tomadas, hora de cierre y comprobaciones antes de devolver el equipo a servicio. También debe decir qué no prueba el registro.
En la práctica, esto evita dos injusticias. La primera es culpar a mantenimiento porque hubo una orden cerca. La segunda es descartar mantenimiento porque no se abrió una orden de avería durante el evento. Las comprobaciones informales existen. Los nombres de activos no siempre coinciden. Una estación local puede llamarse de una forma en mantenimiento, de otra en MES y de una tercera en un procedimiento. El informe de NIST sobre el panorama de estándares señala precisamente ese problema de fabricación inteligente: los sistemas necesitan estándares y comprensión compartida entre información de producto, producción y negocio (panorama de estándares de NIST).
WizeeMind debería evitar frases como “mantenimiento causó la parada” salvo que la cadena de evidencia lo sostenga. Una redacción mejor es más precisa: “La sustitución previa del racor es relevante porque ocurrió en la misma ruta local de aire dentro de las 16 horas anteriores a alarmas repetidas de baja presión. Ningún registro confirma aún estabilidad de presión después de la reparación”. Esa frase da a mantenimiento una comprobación justa y da a operaciones una razón para no cerrar el evento demasiado rápido.
Conecta la parada con calidad y rendimiento real
Una parada no es solo un problema de reloj. Una línea puede arrancar de nuevo y dejar preguntas sobre producto: unidades fabricadas durante velocidad inestable, envases manipulados durante un atasco, comentarios de inspección después del reinicio, retrabajo, rechazo, estado de retención o huecos en el registro de lote. Si el paquete ignora esos registros, la planta puede resolver la pérdida de tiempo y perder la consecuencia operativa.
OEE lo hace visible al separar disponibilidad, rendimiento y calidad dentro de la efectividad del equipo, con la pérdida de calidad diferenciada de tiempo y velocidad (factores de OEE). La medida de APQC acota la parada a interrupción no planificada de tiempo programado, algo útil para comparar, pero insuficiente para cerrar un evento (benchmark de APQC sobre paradas). La planta necesita ambas vistas. El reloj dice cuánto se interrumpió producción. Calidad y rendimiento dicen qué hizo esa interrupción.
En la parada de 47 minutos, la pérdida de tiempo está clara. El impacto no. ¿Se fabricaron unidades entre el reinicio a ritmo reducido y la operación estable? ¿Se retiraron, inspeccionaron, enviaron a retrabajo o rechazaron los productos desalineados? ¿El registro de lote capturó la ventana inestable? ¿Calidad tuvo que revisar producto después de la segunda alarma de baja presión? No son preguntas académicas. Deciden si la parada fue una pérdida de disponibilidad, una señal repetida, una preocupación de calidad o una revisión entre funciones.
WizeeMind debería añadir una capa mínima de impacto a cada paquete: producto, orden, lote si existe, cantidad antes de la parada, cantidad durante el reinicio, rechazos, retrabajo, merma, estado de retención o liberación, comentarios de inspección y pasos de procedimiento ligados a reinicio o despeje de línea. El asistente no debe tomar la decisión de calidad. Debe mostrar si existe evidencia de calidad y si un rol cualificado necesita revisarla.
La línea temporal vuelve a importar. Una nota de calidad posterior al reinicio puede ser ruido de fondo. También puede ser el primer efecto visible del mismo mecanismo que causó la parada. El paquete debería etiquetarla como observación hasta que un registro la conecte con producto afectado. Suena pequeño. Evita que cada comentario cercano se convierta en prueba.
El cierre útil no es “47 minutos perdidos”. Es: “47 minutos perdidos, reinicio a ritmo reducido, producto desalineado observado durante recuperación, sin retención registrada por ahora, unidades posteriores al reinicio aún no vinculadas a resultado de inspección”. Esa frase permite actuar.
Haz visibles las señales ausentes y contradictorias
Los paquetes de parada fallan a menudo porque parecen demasiado limpios. Esconden los huecos que deciden la confianza: nombres de activos sin correspondencia, relojes de alarmas desalineados con MES, códigos introducidos tarde, notas de mantenimiento sin mediciones, estado de calidad no disponible o comprobaciones de reinicio registradas en una nota de turno, pero no en el sistema controlado.
La evidencia ausente también informa sobre confianza. Debe aparecer en el paquete en vez de quedar enterrada en silencio. El trabajo de NIST sobre rendimiento desde operaciones apunta a métodos y marcos de diagnóstico para identificar problemas, lo que implica proceso repetible y no una reunión dominada por quien habla primero (medición de rendimiento de NIST). El informe de NIST sobre estándares llega al mismo punto desde el sistema: la fabricación inteligente necesita intercambio de información y entendimiento entre dominios (panorama de estándares de NIST).
Una vista sencilla de confianza ayuda. Confianza alta: la línea perdió 47 minutos de tiempo programado. Confianza alta: el código seleccionado fue ajuste de operario. Confianza media: las alarmas de baja presión se relacionan con dificultad de reinicio. Confianza baja: la sustitución previa del racor contribuyó a la parada. No verificado: si las unidades posteriores al reinicio requieren revisión adicional de calidad.
Ese formato sirve más que un único porcentaje. Una puntuación puede sonar científica mientras esconde entradas débiles. Una declaración de confianza ligada a límites de fuente muestra qué revisar después. También protege a la planta de la certeza rara que crean algunos paneles. Las filas verdes parecen terminadas. Los eventos reales casi nunca lo están.
WizeeMind debería exponer los conflictos en lenguaje directo. Si MES dice “ajuste de operario”, las alarmas apuntan a presión, mantenimiento muestra trabajo reciente y calidad menciona producto desalineado, el asistente no debería suavizar esas señales en un resumen seguro. Debería decir que la clasificación está apoyada por una acción del operario, pero limitada por evidencia de presión y mantenimiento. Luego debería recomendar una comprobación: comparar tiempos de baja presión, inspeccionar el racor sustituido, confirmar alineación de guías y revisar disposición del producto antes del cierre final.
La regla incómoda del análisis de paradas es esta: un paquete más desordenado puede ser un paquete mejor. El objetivo no es hacer que el evento parezca resuelto. El objetivo es mostrar el estado real de conocimiento antes de que la parada desaparezca en el gráfico mensual.
Cierra con una próxima comprobación controlada
El análisis de paradas debería terminar con una próxima comprobación, no con una conclusión teatral. Esa comprobación puede ser pequeña: confirmar que la alarma no se repitió en la siguiente ejecución, confirmar que el código sigue encajando tras revisión de mantenimiento, confirmar que no apareció preocupación de calidad después del reinicio. En paradas repetidas, puede ser una revisión breve con operaciones, mantenimiento y calidad. En paradas de alto impacto, puede activar una investigación formal.
El cierre debe responder siete preguntas. Qué tiempo programado se interrumpió. Qué evidencia sostiene el código actual. Qué evidencia lo desafía o lo limita. Qué se comprobó antes del reinicio. Qué queda sin verificar. Quién es dueño de la próxima comprobación. Cuándo debe reabrirse el evento.
ISA-95 ayuda porque esas respuestas cruzan fronteras de sistema, y el estándar da un marco común de integración entre empresa y control (ISA-95). El informe económico de NIST añade el marco de coste: el análisis de paradas debe tener en cuenta parada, reparación, defectos, retrabajo y ventas perdidas cuando apliquen, no solo minutos en una gráfica (economía del mantenimiento de NIST).
Un cierre de WizeeMind para el evento inicial debería sonar así: “La parada de 47 minutos está actualmente codificada como ajuste de operario. La evidencia confirma interrupción de tiempo programado, ajuste de guía tras la parada, alarmas de baja presión antes y durante el reinicio, trabajo reciente en un racor neumático cerca del punto de transferencia y notas de producto desalineado. Próxima comprobación: revisar estabilidad de presión local, inspeccionar el racor sustituido, confirmar alineación de guía y comprobar si las unidades posteriores al reinicio requieren revisión de calidad antes del cierre final”.
Esa respuesta no pretende apropiarse de la decisión. Da al supervisor, al operario, al responsable de mantenimiento y a calidad la misma superficie de evidencia. La autoridad queda en personas responsables.
Ese es el estándar que WizeeMind debería ayudar a alcanzar: menos relatos sin soporte, menos búsqueda entre sistemas, límites de fuente más claros y una próxima comprobación que alguien cualificado pueda verificar. El primer código de motivo puede seguir siendo correcto. Solo tiene que ganarse su sitio.
Fuentes
- APQC: Unplanned machine/equipment downtime as a percentage of scheduled run time
- ISA: ISA-95 Series of Standards
- NIST: Operations-driven Performance Measurement for Smart Manufacturing Systems
- NIST: Enhancing Maintenance Strategies for Manufacturing Operations
- NIST: The Costs and Benefits of Advanced Maintenance in Manufacturing
- NIST: Current Standards Landscape for Smart Manufacturing Systems
- OEE.com: OEE Factors