Una prueba de concepto (POC) para software de OEE tiene un único propósito: reducir el riesgo de que el sistema que compras no funcione como el proveedor prometió en tu entorno de producción específico.
Un POC bien diseñado responde a las tres preguntas que las respuestas a una solicitud de propuestas (RFP) y las demostraciones no pueden responder: ¿El software recopila datos con precisión de tus máquinas y PLCs específicos?
¿Calcula el OEE de una manera que coincida con la comprensión del rendimiento por parte de tu equipo de producción? ¿Y pueden tus operarios usarlo sin soporte intensivo y continuo?
El error más común en un POC es hacerlo demasiado amplio.
Los fabricantes que intentan pilotar software de OEE en varias líneas, en varios turnos y con varios tipos de producto en un período de 30 días acaban con resultados inconclusos, demasiadas variables, demasiado trabajo de configuración y no suficiente tiempo para alcanzar una calidad de datos estable.
Un POC centrado en 1, 3 líneas de producción, que abarque de 2 a 3 semanas de producción estable después de un periodo de configuración de 1 semana, genera evidencia más fiable que un piloto extenso que nunca alcanza un estado estable.
Defina el alcance del POC por escrito antes de que comience. El documento de alcance debe especificar: qué líneas están dentro del alcance qué método de recopilación de datos se usará (integración con PLC, retrofit de sensores o registro manual) qué volumen de producción y mezcla de productos se espera durante el periodo del POC
qué integraciones con ERP y CMMS estarán activas durante el POC (si las hay) y qué soporte del proveedor se ha comprometido durante la ventana del POC. Un proveedor que no se comprometa a un documento de alcance por escrito antes de que comience el POC probablemente redefina el alcance después de que termine.
La medición del POC debe cubrir cuatro dimensiones: precisión de la recopilación de datos, confiabilidad del cálculo del OEE, adopción por parte de los operadores y rendimiento del sistema.
La precisión de la recopilación de datos es la más importante: compare las lecturas de la plataforma OEE con sus fuentes de datos existentes (contadores de producción, registros de turno, sistema SCADA) para los mismos turnos.
Una discrepancia de más del 2-3% en los conteos de producción o de más de 5 minutos por turno en la duración del tiempo de inactividad sugiere un problema de configuración de la recopilación de datos que minará la confianza en los datos de OEE tras el despliegue completo.
La confiabilidad del cálculo del OEE se evalúa conciliando las puntuaciones de OEE de la plataforma con cálculos manuales utilizando los mismos datos brutos. Seleccione 5-10 turnos distribuidos a lo largo del período del POC, extraiga los datos brutos, calcule el OEE manualmente y compárelo con el resultado de la plataforma.
Las diferencias deberían poder explicarse por decisiones documentadas sobre la metodología de cálculo (cómo se trata el tiempo de inactividad planificado, cómo se clasifican las microparadas), las discrepancias inexplicables indican un problema de lógica de cálculo en la plataforma que provocará problemas continuos de credibilidad con los responsables de producción que conocen bien sus líneas.
La medición de la adopción por parte de los operadores durante un POC de 30 días se centra en el cumplimiento de la categorización del tiempo de inactividad: ¿qué porcentaje de eventos de tiempo de inactividad fueron categorizados por los operadores (frente a dejarse "sin categorizar"), y cuánto tiempo después de los eventos se realizó la categorización?
Un objetivo de una tasa de categorización del 80% o más dentro de las 2 horas posteriores al evento es un punto de referencia razonable para el POC. Por debajo de esto, el sistema generará un análisis de Pareto dominado por tiempos de inactividad "sin categorizar", lo que contradice el propósito principal del software.
Si las tasas de categorización son bajas durante el POC, diagnostique si la causa es la complejidad de la interfaz del operador, una formación insuficiente o la lista incorrecta de causas de tiempo de inactividad, y pruebe si el proveedor puede abordar la causa raíz durante la ventana del POC.
La decisión de seguir o no (go/no-go) para una prueba de concepto (POC) de software de OEE debería basarse en criterios predefinidos acordados antes de que comience la POC, no en una evaluación ex post de si la relación con el proveedor se siente positiva.
Defina los criterios de aceptación como umbrales medibles: precisión de la recolección de datos dentro de ±3% del valor real en más del 90% de los turnos tasa de categorización de tiempos de inactividad por operador por encima del 75%
al menos una transferencia de datos de integración con el ERP completada con éxito (si está dentro del alcance) cero eventos de pérdida de datos durante la producción normal y disponibilidad del sistema (uptime) superior al 99%.
La decisión de no avanzar también debe ser explícita. Si la precisión de la recolección de datos falla en más del 20% de los turnos, o si el sistema requiere más de 2 horas de soporte del proveedor por semana para mantener una operación estable
o si los operarios evitan activamente usar el sistema a pesar de la formación, estas son señales de que la plataforma tiene un problema de encaje fundamental con su entorno que es poco probable que se resuelva con un despliegue más prolongado.
Entre un go claro y un no-go claro, la mayoría de las POC producen un resultado "aprobado con condiciones", el sistema funciona de forma aceptable pero hay problemas específicos que deben resolverse antes del despliegue completo.
Documente estas condiciones explícitamente en el informe de conclusión de la POC: qué problemas se identificaron, qué se comprometió a hacer el proveedor al respecto y en qué fecha.
Convertir estas condiciones en compromisos contractuales en el contrato de compra transforma la aprobación condicional en una decisión protegida, si las condiciones no se cumplen, usted tiene motivos para solicitar remediación o para salir.
Sin esta documentación, los problemas condicionales tienden a persistir después de la compra porque la urgencia del proveedor para resolverlos desaparece una vez firmado el contrato.
Iniciar sesión
Blog
