El código que identifica la unidad no puede depender de un tecleo

El problema

El código que identifica la unidad para toda su vida depende de un dedo bien puesto.

En cada cambio de modelo, alguien teclea en el panel de la marcadora la variante, la revisión de ingeniería y el formato de marcado. Un dedo mal puesto y toda una serie sale marcada con la revisión anterior — que es, técnicamente, una unidad no identificable. Lo mismo ocurre en el otro extremo: el banco de test de fin de línea guarda sus resultados en su propio disco, y alguien los exporta a mano cuando alguien los pide. El historial de nacimiento de la unidad queda incompleto hasta que se hace ese trabajo manual. La integración "de verdad" de estos equipos lleva años en la lista de deseos de ingeniería y nunca llega arriba del todo, porque cada uno habla un protocolo distinto y el proyecto compite con lanzamientos de producto. Mientras tanto, el tecleo manual sigue siendo el método estándar en el punto más crítico de toda la trazabilidad.

• La marcadora láser es la última pieza que toca el producto antes de salir: graba el código DMC que identifica esa unidad para el resto de su vida. Es un equipo moderno y tiene API, pero está aislado: en cada cambio de modelo alguien teclea la variante, la revisión de ingeniería y el formato de marcado en su panel.
• Un dedo mal puesto y toda una serie sale marcada con la revisión anterior, que es, técnicamente, una unidad no identificable. Es el escenario que convierte un lote sospechoso en una campaña de retirada amplia, porque no se puede acotar lo que no se puede identificar.
• En el otro extremo, el banco de test de fin de línea guarda su veredicto y sus medidas en su propio disco, y alguien los exporta a mano cuando alguien los pide. El historial de nacimiento de la unidad queda incompleto hasta que se hace ese trabajo.
• La integración de estos dos equipos lleva años en la lista de deseos de ingeniería y nunca llega arriba, porque cada uno habla un protocolo distinto y el proyecto compite con lanzamientos de producto. Mientras tanto, el tecleo manual sigue siendo el método estándar en el punto más crítico de la trazabilidad.

Cómo encaja con el sistema IRIS

Connect cosiendo dos sistemas modernos por API — sin sustituir ninguno ni tocar su lógica.

Connect cosiendo dos sistemas modernos por API.

Es el caso legacy de esta matriz aunque los equipos sean modernos: lo viejo no es la máquina, es el hueco entre la máquina y el sistema. Cuando el MES marca el arranque de una orden, la marcadora recibe variante, revisión vigente y formato sin tecleo; cuando el banco de test emite su veredicto, la unidad lo recibe en su historial. Un cambio de modelo pasa a ser un toque en el sistema.

• Sin sustituir ninguno de los dos equipos y sin tocar su lógica interna.
• Cuando el MES marca el arranque de una orden, publica automáticamente a la marcadora la variante, la revisión vigente y el formato de marcado.
• En sentido contrario, el banco de test publica su veredicto y sus medidas.
• Todo se ancla al número de serie en el master de trazabilidad, componiendo el historial de nacimiento de la unidad en tiempo real.
• Un cambio de modelo pasa a ser un toque en el sistema, no un tecleo en el panel de la máquina.

Ver la arquitectura IRIS completa →

Antes y después

La marcadora aislada frente a la marcadora cosida

Aspecto	Hoy	Con iLEAN Connect
Variante y revisión en la marcadora	Tecleadas en el panel en cada cambio	Publicadas por la orden activa del MES
Serie marcada con revisión anterior	Riesgo permanente, a reidentificar	Eliminado por construcción
Veredicto del banco de test	En su disco, exportado a mano	En el historial de la unidad al instante
Historial de nacimiento de la unidad	Incompleto hasta el trabajo manual	Completo en tiempo real
Cambio de modelo	Un tecleo en la máquina	Un toque en el sistema
Los dos equipos	—	Ninguno se sustituye ni se toca por dentro

de errores de tecleo en el marcado (con series enteras a reidentificar) a cero error de origen humano · de resultados de test exportados a mano a historial completo en el momento · de revisión de ingeniería desactualizada en el panel a la vigente siempre.

Estimación de impacto

Estimación de impacto — a validar con vuestros números.

El siguiente bloque es una estimación a validar con los datos concretos de tu planta. Lo planteamos para que el comité tenga un orden de magnitud; lo refinamos en el diagnóstico.

• Payback estimado 3-6 meses, rápido porque no hay hardware nuevo: los dos equipos ya tienen API.
• Reducción drástica del riesgo de unidad mal identificada, el escenario que convierte un lote sospechoso en una campaña de retirada amplia.
• Cero error de origen humano en el marcado: la revisión de ingeniería vigente viaja desde la orden, así que una serie con la anterior deja de ser posible.
• Y el historial de nacimiento de cada unidad —lote de generador, curva de par, veredicto de test— existe en el momento, no cuando alguien lo exporta.

payback rápido, 3-6 meses; reducción drástica del riesgo de unidad mal identificada — el escenario que convierte un lote sospechoso en una campaña de retirada amplia. *Estimación a validar*, empezando por confirmar que la API de la marcadora actual está disponible.

Y la duda razonable del responsable de producción

«¿No es más limpio hacer una integración clásica con el integrador de la marcadora?» — lo es el día que el proyecto llegue arriba de la lista, y ese es el problema: lleva años sin llegar. Esta costura no sustituye ninguno de los dos equipos, no toca su lógica y no pide ventana de parada. Y no hay interpretación de por medio: lo que viaja son campos de la orden activa por API, tarea anclada donde el error de los mejores modelos baja del 1,5% [1] y donde además la marcadora confirma lo grabado realmente, no lo que se pidió grabar.

^[1] Paper OpenAI «Why Language Models Hallucinate», 2025 — sobre fiabilidad de la IA en tareas ancladas.