Lote y caducidad dejan de teclearse dos veces

El problema

El mismo lote y la misma caducidad se teclean dos veces, y ahí nacen las retiradas.

En una planta que exporta a más de veinte países, la caducidad impresa no es un dato: son varios. La vida útil declarada cambia con el producto, con el formato y a veces con el mercado de destino, porque cada mercado tiene sus reglas de etiquetado. El operario elige la plantilla correcta en el panel de la codificadora. La inmensa mayoría de las veces acierta, porque lleva años haciéndolo. El día que no, el error va impreso en decenas de miles de envases y se descubre en el palé, en el contenedor o —lo caro— en el punto de venta del país de destino, con el nombre de la marca encima. Es un error que no se resuelve con más formación ni con más atención. Se resuelve eliminando el punto donde puede ocurrir.

• La codificadora que imprime lote y caducidad en el brick tiene unos diez años y API abierta. El ERP sabe qué lote se está envasando y qué caducidad le corresponde. Y aun así alguien teclea el mismo dato en los dos sitios en cada cambio de producción.
• En una planta que exporta a más de veinte países la caducidad impresa no es un dato: son varios. La vida útil declarada cambia con el producto, con el formato y con el mercado de destino, porque cada mercado tiene sus reglas de etiquetado.
• El operario elige la plantilla correcta en el panel de la codificadora y acierta casi siempre, porque lleva años. El día que no, el error va impreso en decenas de miles de envases.
• Se descubre en el palé, en el contenedor o —lo caro— en el punto de venta del país de destino, con el nombre de la marca encima. No se resuelve con más formación: se resuelve eliminando el punto donde puede ocurrir.

Cómo encaja con el sistema IRIS

Connect cose el ERP y la codificadora por API, sin sustituir ninguno.

Connect cosiendo dos sistemas modernos por API, sin sustituir ninguno. El flujo:

Lo impreso vuelve confirmado al ERP: no lo que se pidió imprimir, sino lo que el cabezal dice haber impreso. Esa distinción es la que convierte el marcaje del brick en evidencia asociada al lote en vez de en una suposición, y la que hace estructuralmente imposible una clase entera de error de etiquetado.

• Al lanzar la orden de producción, el ERP empuja producto, lote, fecha de producción, vida útil aplicable y mercado de destino.
• Connect traduce esos datos a la plantilla que espera el cabezal de marcaje y la carga automáticamente.
• El cabezal imprime y confirma qué ha impreso realmente.
• Connect devuelve esa confirmación al ERP como evidencia asociada al lote.
• Si alguien fuerza un cambio manual en el panel, no se bloquea: se registra como desviación, con su motivo y su responsable.

Ni el ERP ni la codificadora cambian. Simplemente dejan de estar a un metro el uno del otro sin hablarse.

Ver la arquitectura IRIS completa →

Antes y después

La codificadora aislada frente a la codificadora cosida

Aspecto	Hoy	Con iLEAN Connect
Tecleo de lote y caducidad	Dos veces por cambio	Una, en el ERP
Caducidad por mercado de destino	Plantilla elegida a mano	Viaja desde la orden de producción
Qué se imprimió realmente	Se supone	Confirmado por el cabezal y devuelto al ERP
Cambio manual en el panel	Invisible	Registrado como desviación con motivo y responsable
Error de etiquetado	Posible en cada cambio	Estructuralmente imposible
ERP y codificadora	—	Ninguno se sustituye

de dos tecleos por cambio de producción, a cero. De "creemos que se imprimió lo correcto", a la confirmación de la propia máquina, lote a lote. De un error de etiquetado posible en cada cambio, a un error de etiquetado estructuralmente imposible.

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 4-8 meses contando solo el tiempo de cambio de formato recuperado.
• El grueso del valor está en eliminar una clase entera de error cuyo coste unitario es una retirada en el país de destino.
• La confirmación de la propia máquina, lote a lote, sustituye al «creemos que se imprimió lo correcto».
• A confirmar antes de dimensionar: que el modelo instalado expone API o RPC. Un cabezal de más de una década a veces no la trae y necesitaría un adaptador intermedio, lo que sube el CAPEX inicial sin romper el planteamiento.

payback estimado de 4 a 8 meses solo por tiempo de cambio de formato. El grueso del valor está en eliminar una clase entera de error cuyo coste unitario es una retirada. *Estimación a validar.* A confirmar antes de dimensionar: que el modelo instalado expone API o RPC. Los cabezales de más de una década a veces no la traen y requerirían un adaptador intermedio, lo que eleva el CAPEX inicial sin romper el planteamiento.

Y la duda razonable del responsable de producción

«¿No es más limpio hacer una integración clásica entre el ERP y la codificadora?» — lo es el día que el proyecto llegue a lo alto de la lista, y ese es el problema: es el caso clásico de dos sistemas modernos a un metro el uno del otro que llevan años sin hablarse porque nunca hubo tiempo. Esta costura no sustituye ninguno de los dos ni pide ventana de parada. Y donde interviene un modelo —interpretar una plantilla de marcaje o una regla de vida útil por mercado— la tarea es anclada y los mejores modelos bajan del 1,5% de error [1]; el resto es API contra API.

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