Las demostraciones de software de OEE son experiencias guionizadas. Los proveedores muestran su plataforma en su mejor versión, con datos limpios precargados, escenarios de producción ideales y entornos de demostración donde cada función funciona sin contratiempos.
Lo que no muestran es cómo el sistema maneja las condiciones desordenadas del mundo real: el operario que olvida cerrar un evento de paro, el PLC que envía señales de estado ambiguas, la corrida de producción que abarca un cambio de turno, o el informe que requiere combinar datos de tres líneas diferentes con estructuras de producto distintas.
La brecha entre el rendimiento en la demo y el rendimiento en el mundo real es la fuente más común de arrepentimiento entre los compradores de software OEE.
Los fabricantes que compran basándose en demostraciones pulidas sin probar casos límite suelen descubrir, tras la implementación, que el sistema maneja sus escenarios de producción específicos de forma distinta a como lo sugería la demo.
La forma de cerrar esta brecha es llevar tus propios escenarios a las demostraciones, exigiendo a los proveedores que muestren cómo su sistema maneja los casos límite y flujos de trabajo específicos que existen en tu planta, no los casos ideales para los que está diseñado su entorno de demo.
Estructurar la evaluación de las demostraciones en torno a una lista de verificación fija de escenarios también hace que la comparación entre proveedores sea más fiable.
Si cada proveedor demuestra los mismos 25 escenarios, puedes comparar sus enfoques uno al lado del otro en lugar de comparar la función de "gestión de paradas" de un proveedor con la función de "análisis de pérdidas" de otro que se mostró con datos y flujos de trabajo distintos.
La lista de verificación impone una consistencia en la comparación que, de otro modo, requeriría que evaluadores experimentados la mantuvieran manualmente a lo largo de varias sesiones.
Escenarios de recopilación de datos: (1) Muestre cómo se captura un cambio de estado de la máquina sin acción del operador, demuestre la canalización de la señal del PLC al estado OEE en tiempo real.
(2) Muestre qué ocurre cuando una señal del PLC es ambigua o un sensor se desconecta brevemente, ¿cómo maneja el sistema las lagunas de datos? (3) Demuestre a un operador añadiendo una razón de parada 2 horas después del evento, ¿es posible la categorización retroactiva y existe un registro de auditoría?
(4) Muestre una corrida de producción que cruza la medianoche, ¿cómo maneja el sistema los límites de turno? (5) Demuestre un cambio de producto que dura 90 minutos, ¿se registra el cambio por separado del tiempo de inactividad por avería?
Escenarios de cálculo de OEE: (6) Muestre el OEE de una línea que produce dos productos con diferentes tiempos de ciclo en el mismo turno, ¿cómo se gestionan los objetivos por producto?
(7) Muestre cómo el mantenimiento planificado durante horas de producción afecta la Disponibilidad, ¿se excluye del cálculo de OEE o se muestra como tiempo de inactividad planificado? (8) Demuestre el cálculo de la tasa de calidad, ¿de dónde provienen los datos de rechazados y cómo se gestiona el retrabajo por separado de la merma?
(9) Muestre qué ocurre si la puntuación de OEE de un turno es 0%, ¿el sistema maneja los casos límite sin errores? (10) Demuestre la agregación de OEE entre tres líneas con horarios de turno diferentes, ¿cómo se calcula el OEE multi-línea?
Escenarios de informes y usabilidad: (11) Muestre un diagrama de Pareto de causas de tiempo de inactividad de los últimos 30 días, ¿se puede filtrar por turno, producto y categoría de equipo? (12) Demuestre la creación de un informe personalizado, ¿cuánto tiempo lleva crear un informe nuevo desde cero sin ayuda del proveedor?
(13) Muestre la app móvil en un dispositivo real en la sala, ¿es una aplicación nativa o una vista web móvil? (14) Demuestre una alerta que se dispara y es recibida por un supervisor, ¿cuál es la latencia real?
(15) Muestre una exportación masiva de datos de 12 meses de tiempo de inactividad, ¿cuánto tarda y en qué formato se exporta? Integración y administración: (16) Muestre en vivo el sistema OEE recibiendo datos de un PLC de prueba vía OPC-UA, no una simulación, una conexión real.
(17) Demuestre la creación de una nueva configuración de línea de producción sin intervención del proveedor, ¿qué tan complejo es el procedimiento? (18) Muestre cómo se crea un nuevo usuario y se le asigna a una línea y rol específicos. (19) Demuestre la configuración de inicio de sesión único para su proveedor de identidad.
(20) Muestre cómo se actualiza la lista de códigos de causas de parada cuando cambia la taxonomía. (21) Muestre el sistema funcionando durante una simulación de corte de red, ¿funciona el almacenamiento en el edge?
(22) Demuestre la API, haga una llamada API en vivo delante de usted para extraer las últimas 24 horas de datos de OEE. (23) Muestre cómo se ve el sistema después de 2 años de datos, ¿hay degradación del rendimiento?
(24) Pídale al proveedor que le muestre un ticket de soporte al cliente de los últimos 6 meses y cómo se resolvió. (25) Muestre el proceso de actualización, ¿cómo se despliegan las nuevas versiones y qué tiempo de inactividad se requiere?
Envía la lista de verificación de 25 escenarios a los proveedores una semana antes de la demostración y pídeles que se preparen para demostrar cada uno. Observa su respuesta con atención, los proveedores que se oponen a escenarios específicos ("no podemos mostrar eso en un entorno de demostración") están señalando una brecha de capacidad.
Los proveedores que aceptan el reto y se presentan preparados muestran mayor confianza en el rendimiento real de su plataforma.
Durante la demostración, califica cada escenario en una escala simple de 0 a 2: 0 (no demostrado o capacidad no disponible), 1 (demostrado con salvedades significativas o soluciones alternativas), 2 (demostrado de forma clara y creíble).
Toma notas sobre la evidencia específica de cada calificación: lo que mostró el proveedor, las limitaciones mencionadas y las preguntas de seguimiento. Estas notas crean un registro de evaluación de la demostración que puede compartirse con los miembros del equipo de evaluación que no pudieron asistir a la sesión completa.
Después de la demostración, da seguimiento a cualquier escenario que no se haya demostrado mediante una solicitud de respuesta por escrito, pidiéndoles a los proveedores que documenten por escrito cómo su sistema maneja el escenario específico.
Las respuestas escritas a las lagunas de la demostración crean puntos de referencia contractuales: si un proveedor afirma por escrito que su sistema maneja un escenario de cierta manera y no funciona así después de la puesta en marcha, tendrás documentación de la tergiversación.
Esta documentación también enfoca al equipo de ventas del proveedor en la exactitud más que en el optimismo, lo que tiende a mejorar la confiabilidad de sus respuestas.
Iniciar sesión
Blog
