En muchas fábricas medianas ya hay sensores, ERP, MES, cuadros de mando y alguna prueba con inteligencia artificial. Aun así, el jefe de turno sigue llamando para saber si la pieza está bloqueada en calidad, si falta un útil o si compras ha confirmado el material. Opino que ahí está el punto: no falta tecnología, falta arquitectura operativa. Toyota ya resolvió parte de este problema con personas, máquinas, tarjetas y reglas claras. Hoy lo llamamos agentes de IA, pero la pregunta sigue siendo la misma: ¿quién decide, con qué información, dentro de qué límites y cómo aprende el sistema?

Situación

Durante esta serie hemos mirado el Toyota Production System desde otro ángulo. No como un conjunto de herramientas lean para ordenar la fábrica, sino como un sistema distribuido de decisión. En el TPS, cada puesto, cada kanban, cada andon, cada estándar y cada rutina de mejora tiene una función dentro de una red. No todo sube a dirección. No todo se decide en una reunión. La información se mueve hacia donde se necesita y la decisión se toma cerca del problema.

Ese es también el reto de muchas implantaciones actuales de inteligencia artificial. Se crean pilotos atractivos, con una pantalla limpia y una predicción interesante, pero la operación no cambia. El planificador no confía en la recomendación. El encargado no sabe cuándo intervenir. Mantenimiento recibe alertas sin prioridad. Calidad acumula incidencias, pero no cierra el aprendizaje. Resultado: más datos, más ruido y pocas mejoras medibles.

Me he encontrado con plantas donde el problema visible era "necesitamos IA para planificar mejor", pero la realidad era otra: rutas mal mantenidas, datos maestros incompletos, prioridades comerciales cambiando 4 veces por turno y decisiones sin dueño. En ese contexto, un agente de IA no arregla el sistema. Lo amplifica.

Tarea

El objetivo, si llevamos el TPS al lenguaje de agentes, no es "digitalizar lean". Esa frase me parece pobre. El objetivo es diseñar una organización capaz de decidir mejor, antes y con menos desperdicio. Eso exige traducir la operación en unidades de decisión: qué observa cada agente, qué puede hacer, cuándo debe escalar, qué indicador mejora y cómo se corrige si falla.

En esta serie hemos trabajado 4 ideas que conviene cerrar bien:

• El TPS funciona como una arquitectura de agentes porque reparte decisiones con reglas, límites y señales compartidas.
• El kanban no es una tarjeta; es un protocolo de comunicación entre procesos con capacidad finita.
• El jidoka y el andon enseñan una regla incómoda: parar a tiempo puede proteger más margen que producir piezas dudosas durante 45 min.
• La mejora continua es el mecanismo que permite que el sistema aprenda sin depender de héroes.

Si aceptas estas 4 ideas, el salto hacia agentes de IA deja de parecer un asunto de moda. Pasa a ser una evolución natural de la gestión industrial. Un agente de planificación, uno de calidad, uno de mantenimiento o uno de compras solo tiene sentido si se integra en una lógica operativa: flujo, estándar, excepción, escalado y aprendizaje.

Acciones

Recomiendo empezar por el mapa de decisiones, no por el mapa de sistemas. La pregunta no es qué software tienes, sino qué decisiones se toman cada día para servir al cliente con margen. En una fábrica de 120 personas, esas decisiones suelen estar repartidas entre planificación, compras, producción, calidad, mantenimiento, logística interna y atención al cliente. Si cada área decide con su propio dato, el sistema se descoordina.

El primer paso es identificar entre 10 y 20 decisiones repetitivas con impacto económico. Por ejemplo: liberar una orden, cambiar una secuencia, parar una máquina, bloquear un lote, lanzar una compra urgente, reasignar operarios o adelantar un transporte. Cada decisión debe tener un dueño, una frecuencia, una fuente de datos, un límite de autonomía y un indicador asociado.

Después se revisa el equivalente TPS de esa decisión. ¿Hay señal clara? ¿Existe estándar? ¿Se conoce la capacidad real? ¿Hay condición de parada? ¿Se mide la causa del fallo? Aquí aparece el valor del lean bien entendido. Antes de pedir a un agente que optimice la secuencia de producción, necesitas saber si los tiempos de cambio están medidos, si la disponibilidad de máquina es fiable y si el material está confirmado.

En una célula de mecanizado con 3 centros CNC, una familia de piezas de aluminio y 2 turnos, detectamos que el plan cambiaba 6 veces al día. La causa no era solo comercial. Había utillajes compartidos sin visibilidad, controles de primera pieza que tardaban 35 min y una cola de calidad que nadie priorizaba. Antes de hablar de IA, definimos reglas de secuenciación, límites de WIP, estado visual de útiles y un protocolo de escalado cuando calidad superaba 20 min de espera. Solo entonces tenía sentido plantear un agente que recomendara secuencias.

Mi secuencia preferida es sencilla: diagnosticar el flujo, estabilizar datos mínimos, definir reglas de decisión, probar el agente en una zona acotada y medir contra una línea base. Si el agente recomienda, pero nadie cambia su rutina, no hay implantación. Si el agente decide sin límites, hay riesgo. El equilibrio está en dar autonomía con control, igual que hizo Toyota con sus mecanismos físicos.

Resultados

Cuando esta arquitectura se diseña bien, los resultados dejan de ser abstractos. No hablamos de "más digitalización", sino de menos esperas, menos urgencias, menos inventario y más cumplimiento. En una primera ola razonable se pueden plantear hipótesis como reducir entre 15% y 30% las replanificaciones manuales, bajar entre 10% y 20% el WIP en una familia de producto, recortar entre 20 min y 60 min el tiempo de reacción ante paradas repetitivas o aumentar entre 5 puntos y 12 puntos el cumplimiento de secuencia en una línea crítica. No son promesas; se validan con diagnóstico y medición.

La bonanza económica aparece cuando conectas la decisión con la cuenta de resultados. Un cambio de secuencia mal gestionado no es solo una molestia: puede suponer 40 min de máquina parada, 2 operarios esperando, un transporte urgente de 450 € y una entrega parcial que tensiona al cliente. Si eso ocurre 8 veces al mes, ya no hablamos de cultura lean; hablamos de margen.

También mejora la calidad de gestión. El encargado no necesita preguntar 12 veces por el estado de una orden. Compras ve antes el riesgo de rotura. Calidad prioriza por impacto en flujo. Mantenimiento distingue entre alerta informativa y condición de parada. Ese orden reduce fricción entre áreas, porque la conversación pasa de la opinión al dato operativo.

Para sostener el resultado hay que evitar dos errores. El primero es abandonar el estándar cuando el piloto funciona. El segundo es dejar que el agente aprenda sobre datos sucios o decisiones improvisadas. Recomiendo una rutina mensual de revisión con 5 elementos: indicador económico, cumplimiento de reglas, excepciones, calidad del dato y nuevas oportunidades. Si una recomendación del agente se ignora 60% de las veces, no culpes al usuario. Revisa la regla, el dato o el contexto.

Si has seguido esta serie, ya tienes el hilo completo: Toyota diseñó una red de decisiones antes de que habláramos de agentes, automatización inteligente o modelos predictivos. El TPS nos dejó una lección práctica: la autonomía funciona cuando hay propósito, límites, señales y aprendizaje. Sin eso, la IA se convierte en otra capa de complejidad encima de una operación que ya iba justa.

Si quieres profundizar, te recomiendo revisar nuestras series relacionadas sobre planificación industrial, reducción de desperdicio, gestión visual, estandarización de procesos y Lean Manufacturing 4.0. Todas apuntan a la misma idea: antes de escalar tecnología, hay que entender cómo fluye el trabajo y dónde se toman las decisiones que mueven el margen.

En brotherHUB podemos ayudarte a hacer ese puente con los pies en planta: diagnóstico operativo, mapa de decisiones, diseño de pilotos con agentes, medición económica y transferencia al equipo interno. No te vamos a prometer ahorros sin medir. Sí te vamos a decir dónde se pierde tiempo, dinero y capacidad de respuesta, y qué conviene atacar primero.

Si tu fábrica tiene datos, pero las decisiones siguen dependiendo de llamadas, urgencias y hojas paralelas, merece la pena mirarlo. ¿Quieres transformar tus operaciones? ¡Hagámoslo Juntos!

En el post anterior dejamos el jidoka y el andon en su sitio: detectar la anomalía, parar antes de propagarla y pedir ayuda sin castigo. Falta una pieza que decide si esa lógica se convierte en aprendizaje o en un archivo de incidencias. Ohno lo resolvió yendo al gemba. Hoy muchas implantaciones de IA intentan resolverlo desde un panel. Mi tesis en este post es clara: si tu sistema no ha estado en planta, no debería opinar con autoridad.

Situación

Seguimos en la misma célula de mecanizado de cuerpos de válvula de aluminio: 2 tornos CNC, 1 centro de mecanizado y 1 lavadora final, con un objetivo de 320 piezas por turno. El segundo torno vuelve a mostrar la misma deriva: el sonido de corte cambia y la medida crítica se desplaza 0,08 mm. Con jidoka bien diseñado, la segunda pieza fuera de tendencia detiene la máquina y enciende el andon. En menos de 5 min llega alguien. Hasta ahí, el sistema ha protegido el flujo.

El problema aparece después. En la reunión de las 10:00 se proyecta un gráfico limpio: “deriva de cota en torno 2, 7 eventos en 12 días”. Alguien propone un agente de IA para predecir la desviación y recomendar el cambio de herramienta. La idea suena moderna. Yo pregunto otra cosa: ¿ha visto el modelo la viruta, ha oído el corte, ha comprobado el refrigerante, ha hablado con el operario del turno de tarde y ha contrastado el lote de material? Si la respuesta es no, no tienes un sistema inteligente. Tienes una opinión con dashboard.

Me he encontrado con plantas donde el histórico de paros era impecable y, aun así, el mismo fallo se repetía. No faltaban datos. Faltaba gemba. El registro decía “herramienta”, pero en planta la causa real era una combinación de presión de refrigerante irregular, un lote de barra con dureza distinta y una medición de primera pieza hecha con prisa al inicio del turno. Ningún modelo aprende eso si solo lee códigos de paro escritos a las 23:00 por alguien que ya quiere irse a casa.

El punto de dolor es doble. Por un lado, la operación sigue dependiendo de veteranos que “saben” lo que no está en el sistema. Por otro, la digitalización intenta decidir sin haber visto el proceso. En ambos casos, la distancia entre el hecho y la decisión se alarga. Y esa distancia cuesta dinero: piezas dudosas, esperas, cambios de secuencia y conversaciones de culpas en vez de contramedidas.

Tarea

La tarea de este post no es “poner IA en la fábrica”. La tarea es diseñar cómo el sistema aprende cerca de la realidad. En vocabulario TPS: ir al gemba, ver el proceso, entender la causa y actualizar el estándar. En vocabulario actual: recuperar contexto de planta antes de que un agente de IA recomiende, priorice o replanifique.

Definición mínima de gemba: el lugar real donde se crea valor y donde ocurre el problema. No el informe. No la media mensual. El puesto, la máquina, el contenedor, la herramienta y la persona que lo toca cada turno.

Definición mínima de RAG, en este marco industrial: un mecanismo para que el sistema recupere información relevante del contexto operativo —estándares, incidencias cerradas, parámetros de proceso, vida de herramienta, desviaciones de material, decisiones de escalada— antes de emitir una recomendación. No es magia. Es una forma de no responder de memoria genérica cuando la planta ya tiene historia concreta.

La conexión es directa. El gemba aporta el hecho. El estándar aporta la regla. El historial de anomalías aporta la memoria. El agente, humano o digital, solo debería opinar después de recuperar ese contexto. Si no, automatizamos la superficialidad.

En la célula de válvulas, el objetivo de diseño no sería “predecir defectos”. Sería más preciso: que cualquier desviación de medida o de sonido active, en menos de 2 min, la recuperación del contexto útil —referencia, lote, herramienta, turnos previos, últimas contramedidas— y que la decisión de cambiar herramienta, medir más o escalar a proceso se tome con ese marco, no con intuición suelta ni con un modelo ciego.

Acciones

Para convertir gemba y contexto recuperable en sistema, recomiendo vigilar estas acciones. Son operativas, no decorativas.

• Ir al puesto antes de discutir el gráfico. Si el andon del torno 2 se ha activado 7 veces, el primer paso no es abrir un piloto de IA. Es pararse delante de la máquina en el turno donde ocurre, con el operario, mantenimiento y, si hace falta, calidad. ¿Cambia el sonido? ¿La viruta es distinta? ¿El refrigerante llega bien? ¿La sujeción marca la pieza? El gemba no sustituye el dato; lo hace creíble.
• Definir qué contexto debe recuperarse ante cada tipo de señal. Una deriva de cota no necesita el mismo paquete de información que una falta de material. Para la deriva: referencia, lote, contador de herramienta, últimas mediciones, presión de refrigerante, incidencias iguales en 30 días y contramedida aplicada. Si ese paquete no existe, el agente no tiene con qué razonar.
• Escribir el estándar como memoria viva, no como PDF muerto. El estándar de trabajo debe decir qué es normal, qué se mide, con qué frecuencia, qué se hace si se sale de tendencia y cuándo se escala. Cuando el equipo descubre que la rebaba aparece antes en el turno de tarde con otro lote de barra, el estándar se actualiza. Si no se actualiza, el sistema olvida a propósito.
• Registrar la anomalía con causa útil, no con etiqueta cómoda. “Herramienta” es un cajón de sastre. Mejor: desgaste prematuro asociado a refrigerante bajo y lote X. Esa frase sí sirve después para recuperar contexto. Un código genérico solo alimenta un ranking bonito e inútil.
• Separar lo que el puesto puede decidir solo de lo que debe escalar. Dentro de límite: medición adicional, cambio de herramienta en la siguiente ventana, retención de las 2 últimas piezas. Fuera de límite: parada, andon y soporte. La IA, si entra, hereda esos mismos límites. Autonomía sin frontera es ruido acelerado.
• Probar cualquier recomendación digital en un perímetro pequeño. Un torno, una familia, dos turnos, dos semanas. Compara tiempo hasta detección, piezas afectadas, paros repetidos por la misma causa y porcentaje de recomendaciones aceptadas por el equipo. Si nadie confía en la recomendación, no hay arquitectura: hay demo.

Fíjate en la secuencia: primero realidad, después regla, después memoria, después automatización. Invertir el orden es lo que produce agentes que hablan bien y deciden mal.

Resultados

Cuando gemba y contexto recuperable funcionan, el sistema deja de improvisar con educación. Cada paro enseña algo. Cada estándar mejora. Cada agente —persona, máquina o software— opera con menos ambigüedad.

En la célula de válvulas, el resultado que buscaría medir no es un eslogan de “fábrica inteligente”. Es más duro y más útil: menos piezas dudosas aguas abajo, menos paros repetidos por la misma causa, menos tiempo entre señal y contramedida, y menos decisiones que suben a supervisión por falta de regla clara. Con 3 o 4 semanas de seguimiento ya se ve si el aprendizaje es real o solo documental.

También cambia la conversación con la tecnología. Un modelo que recomienda cambiar herramienta cada 180 piezas sin mirar lote, refrigerante ni turno es un oráculo frágil. Un sistema que recupera el contexto de las últimas 10 derivas y lo cruza con el estándar actual se parece mucho más al TPS: decide cerca del hecho, con memoria y con límite.

La bonanza económica aparece cuando dejas de pagar dos veces el mismo problema. La primera vez cuesta la parada. La segunda, la tercera y la cuarta cuestan la desconfianza del equipo. Si la misma deriva se repite y el sistema no ha incorporado lo aprendido, no tienes mejora continua: tienes un bucle de urgencias.

Antes del cierre de la serie, te propongo un ejercicio concreto. Elige la última incidencia repetida de tu planta: deriva de medida, falta de material, útil no disponible, defecto que salta dos operaciones tarde o replanificación por sorpresa. Baja al gemba. Reconstruye la cadena en minutos. ¿Qué se vio? ¿Qué se registró? ¿Qué contexto habría necesitado un agente —humano o digital— para decidir bien a la primera? ¿Qué parte de ese contexto hoy no existe, está en la cabeza de alguien o llega demasiado tarde?

En el próximo post cerraremos el arco: del lean a los agentes de IA sin vender humo. Llevaremos esta lógica a una arquitectura práctica de decisión en operaciones. Si este enfoque te encaja, sigue la serie y compártela con tu equipo de fábrica, calidad y mantenimiento. Y si quieres revisar dónde tu sistema decide lejos del proceso, hablemos con datos de tu planta encima de la mesa. ¿Quieres transformar tus operaciones? ¡Hagámoslo juntos!

En muchas fábricas, la palabra automatización se entiende mal. Se compra una máquina que produce sola y luego dirección se sorprende cuando aparece un palet con 400 piezas defectuosas fabricadas de madrugada, sin que nadie parara, sin que nadie avisara, sin que nadie supiera. Toyota entendió otra cosa: la automatización útil no consiste en que la máquina trabaje sin personas, sino en que la máquina sepa cuándo detenerse y pedir ayuda. A eso lo llamaron jidoka, y a la señal que convoca esa ayuda, andon. Hoy la ingeniería de agentes de IA lo está redescubriendo con otro nombre: human-in-the-loop.

Situación

Me he encontrado con plantas que presumen de máquinas desatendidas y turnos nocturnos sin supervisión, y a la vez acumulan lotes bloqueados, retrabajos y reclamaciones de cliente que nadie vio venir. El operario detecta un ruido raro pero no para "porque la producción aprieta". La máquina sigue cortando con la herramienta desgastada porque nadie le enseñó a distinguir una viruta buena de una mala. Calidad descubre el problema tres operaciones después, cuando la trazabilidad ya es arqueología. Eso no es automatización. Es fabricar defectos a máxima velocidad.

El Toyota Production System resolvió este problema mucho antes de que habláramos de agentes, umbrales de confianza o supervisión humana de la IA. Sakichi Toyoda lo inventó en un telar: un mecanismo que detenía la máquina automáticamente cuando se rompía un hilo. La consecuencia fue enorme: si la máquina se para sola ante el defecto, una persona puede supervisar muchas máquinas en vez de vigilar una. Jidoka no quita personas del proceso; las coloca donde aportan juicio, no vigilancia.

Visto con ojos actuales, jidoka y andon forman el human-in-the-loop del sistema. El agente -máquina, operario o algoritmo- trabaja con autonomía mientras todo está dentro de condición. Cuando detecta una anomalía que supera su límite, se detiene y emite una señal visible: la luz andon, el cordón del que se tira, la llamada al líder de equipo. El humano no interviene en cada pieza; interviene exactamente cuando el sistema reconoce que ha llegado al borde de su competencia.

Ese es el dolor que veo hoy en muchas implantaciones de IA: agentes que actúan con la misma confianza cuando aciertan que cuando alucinan, sin un mecanismo que diga "aquí me paro y pregunto". Opino que un cordón andon bien diseñado enseña más sobre supervisión de sistemas autónomos que muchas plataformas llenas de dashboards que nadie mira.

Tarea

En esta tercera entrada seguimos desmontando el TPS como sistema de agentes. En el post anterior vimos el kanban como protocolo de comunicación: qué mensaje autoriza a actuar. Hoy vamos con la otra mitad del diseño: qué condición obliga a parar. Porque un sistema de agentes sin freno no es autónomo; es incontrolado.

Cuando hablo de agente no me refiero solo a un modelo de IA. Un agente puede ser un torno con paro automático por rotura de herramienta, un operario con autoridad para tirar del andon, una verificación en línea que bloquea el avance del lote o una regla de software que retiene una orden. Todos comparten el mismo diseño: actúan solos dentro de límites, se detienen fuera de ellos y piden ayuda sin esconder el problema.

La tarea consiste en pasar del "avisa si ves algo raro" a la detención diseñada. Eso exige responder preguntas muy concretas. ¿Qué anomalía debe detectar cada agente y con qué señal la reconoce? ¿Ante qué condición se detiene solo y ante cuál consulta antes de seguir? ¿A quién llama la señal y en cuánto tiempo debe llegar la ayuda? ¿Qué pasa con la producción mientras tanto? ¿Y quién garantiza que tirar del cordón nunca se castiga?

Piensa en la misma línea de mecanizado de los posts anteriores: 2 tornos CNC, 1 centro de mecanizado y 1 lavadora final, fabricando cuerpos de válvula de aluminio a 320 piezas por turno. El operario nota que cambia el sonido de corte en el segundo torno y la medida crítica se desplaza 0,08 mm, todavía dentro de tolerancia. Si el sistema está bien diseñado, esa deriva activa medición adicional; una segunda pieza fuera de tendencia detiene el torno y enciende el andon; y en menos de 5 min hay alguien de mantenimiento o de ingeniería de proceso delante de la máquina. Si no lo está, el torno seguirá produciendo hasta que calidad bloquee 70 piezas y la conversación sea sobre culpas en vez de sobre señales.

La tarea no es pedir "más atención" al equipo ni "más confianza" al algoritmo. La tarea es construir un sistema donde parar a tiempo sea más fácil, más rápido y mejor visto que seguir produciendo defectos.

Acciones

Para diseñar jidoka y andon como human-in-the-loop, recomiendo vigilar 4 elementos. Son sencillos de nombrar y exigentes de aplicar con disciplina.

Detectar la anomalía en origen. Ningún agente puede parar ante lo que no sabe ver. En TPS eso significa definir la condición normal con precisión: medida crítica, tendencia, vida de herramienta, par de apriete, aspecto de la viruta. En un agente digital significa lo mismo: qué dato observa, qué patrón es normal y qué desviación es señal. Si la condición normal no está definida, la detección depende del veterano del turno, y el sistema no aprende: recuerda a una persona.

Parar antes de propagar. La detención no es un fracaso del agente; es su función más valiosa. El torno que se detiene tras una segunda pieza fuera de tendencia pierde 20 min de producción y salva 250 piezas, dos operaciones posteriores y una reclamación de cliente. Un agente de IA que retiene una decisión de baja confianza pierde segundos y evita un error propagado por todo el flujo. La regla de diseño es idéntica: el coste de parar debe compararse con el coste de continuar, y ese cálculo se hace antes, en frío, no durante la urgencia.

Señalizar de forma que nadie pueda ignorarla. El andon no es un registro; es una convocatoria. La luz se ve desde el pasillo, el cordón detiene la estación al final del ciclo, la señal identifica puesto, problema y momento. Compara eso con la alerta número 47 en un dashboard que nadie tiene abierto, o el correo automático que muere en una bandeja llena. Si la señal no interrumpe a alguien concreto con la obligación de responder, no es un andon: es un archivo de excusas para la reunión del viernes.

Garantizar la respuesta y proteger a quien avisa. Tirar del cordón solo funciona si llega ayuda, rápido y sin reproches. En Toyota, el líder de equipo acude en segundos; la primera pregunta es "¿qué está pasando?", nunca "¿por qué has parado?". Si la primera vez que un operario detiene la línea recibe presión por la producción perdida, no volverá a parar: fabricará defectos en silencio. Con agentes digitales ocurre igual: si cada escalada al humano se percibe como ruido y se termina desactivando el umbral, el sistema aprende a no preguntar. La escalada es protección del flujo, y se mide: tiempo hasta la respuesta, no solo número de paros.

Estos elementos no son teoría de oficina. Son diseño operativo. Cuando se respetan, la autonomía crece porque cada agente tiene un freno fiable y una ayuda garantizada. Cuando se ignoran, la automatización solo acelera la fabricación de problemas.

Resultados

Aplicar esta lectura de jidoka y andon permite obtener autonomía con red: máquinas y agentes que trabajan solos la mayor parte del tiempo, y humanos que intervienen pronto, con contexto y en el punto exacto del problema.

En el ejemplo de la célula de mecanizado, el resultado esperado no sería prometer cero defectos sin medir. Sería empezar por indicadores observables: tiempo desde la anomalía hasta la detección, tiempo desde el andon hasta la llegada de ayuda, piezas afectadas por incidencia, paros repetidos por la misma causa y porcentaje de paros que terminan en cambio de estándar. Con 4 semanas de datos ya puedes separar opinión de realidad.

La mejora aparece cuando cada detención alimenta el sistema. Si el segundo torno pide ayuda cada 180 piezas por la misma deriva de medida, no basta con acudir rápido: habrá que revisar vida de herramienta, presión de refrigerante, frecuencia de medición y el propio umbral de paro. Ahí jidoka se parece mucho a un human-in-the-loop bien diseñado: cada escalada es un dato para ajustar el límite, no una molestia que silenciar. El objetivo no es que el agente nunca pregunte; es que cada pregunta haga al sistema un poco menos dependiente de la suerte.

También cambia la conversación con los equipos. En vez de preguntar "¿por qué paraste la línea?", preguntas "¿qué señal te dijo que había que parar?". En vez de premiar al que nunca molesta, reconoces al que detecta pronto. Eso desarrolla talento porque convierte el ojo clínico del veterano en condiciones de paro que cualquier agente, humano o digital, puede ejecutar.

Si estás pensando en agentes de IA para operaciones, te propongo empezar por una pregunta más básica: ¿tu fábrica ya sabe parar a tiempo? Mira una máquina, una estación, un proceso. Identifica el último defecto que avanzó más de una operación antes de ser detectado. Pregunta qué señal faltaba, quién debía haberla visto y cuánto tardó en llegar la ayuda. Después diseña la condición de paro y mide 2 semanas.

En brotherHUB trabajamos ese punto con equipos de dirección, operaciones, fábrica y cadena de suministro. No empezamos prometiendo máquinas desatendidas. Empezamos diagnosticando dónde el sistema sigue produciendo cuando debería estar preguntando.

¿Quieres transformar tus operaciones? ¡Hagámoslo juntos! Podemos revisar contigo un proceso concreto y convertirlo en tu primer mapa de condiciones de paro y escalada. La pregunta es directa: ¿qué máquina de tu planta seguiría fabricando defectos esta noche sin que nadie se enterara hasta mañana?

En muchas fábricas, la palabra coordinación se confunde con reuniones. Se junta a producción, logística y planificación cada mañana, se reparte un Excel y luego dirección se sorprende cuando el material aparece tarde, un puesto fabrica contra stock "por si acaso" y una falta de 40 piezas se convierte en una discusión de 2 días. Toyota entendió otra cosa: la coordinación útil no nace de hablar más, sino de diseñar una señal que cualquier agente del sistema pueda leer, ejecutar y devolver sin preguntar a nadie. Esa señal fue una tarjeta de cartón: el kanban.

Situación

Me he encontrado con plantas que han invertido en ERP, MES, capturas de datos e integraciones, y siguen reponiendo material por intuición. El planificador rehace el programa 6 veces al día, el encargado pide "un poco más para ir tranquilos", logística repone cuando alguien grita y calidad descubre inventario obsoleto que nadie recuerda haber pedido. Eso no es falta de tecnología. Es falta de protocolo.

El Toyota Production System resolvió este problema mucho antes de que habláramos de agentes, colas de mensajes o arquitecturas orientadas a eventos. Toyota necesitaba que cientos de puestos se coordinaran sin grandes inventarios ni una autoridad central decidiendo cada movimiento. Para eso diseñó el kanban: una tarjeta que autoriza producir o reponer una cantidad exacta, de una referencia exacta, cuando el consumo real lo pide. Nada se mueve sin señal. Nada se fabrica por adelantado "por si acaso".

Visto con ojos actuales, el kanban es un protocolo de comunicación entre agentes. Cada tarjeta es un mensaje con emisor, receptor, contenido y condición de disparo. El puesto aguas abajo consume y libera la tarjeta; el puesto aguas arriba la recibe y ejecuta. El sistema no pregunta todo a una autoridad central, pero tampoco deja que cada nodo actúe a su aire: la tarjeta define qué se puede hacer y qué no.

Ese es el dolor que veo hoy en muchas implantaciones de Industria 4.0 e IA: se conectan sistemas sin haber definido antes qué mensaje dispara qué acción, con qué dato y con qué límite. Opino que una tarjeta de cartón bien diseñada enseña más sobre coordinación que muchos proyectos digitales llenos de integraciones que nadie sabe explicar.

Tarea

En esta entrada bajamos a una pieza concreta del TPS: el kanban como protocolo entre agentes. En el post anterior vimos las condiciones que debe cumplir cualquier agente para decidir bien en planta: propósito, límites, información situada y escalada. Hoy vamos a comprobar cómo una simple tarjeta cumple las cuatro, y por qué eso la convierte en el mejor ejemplo de comunicación distribuida que ha dado la industria.

Cuando hablo de agente no me refiero solo a un modelo de IA. Un agente puede ser una persona en una célula de montaje, una carretilla que repone material, una máquina con paro automático o una regla de planificación. Todos reciben un mensaje, ejecutan una acción y devuelven una señal al sistema. El kanban es el idioma en el que se hablan.

La tarea consiste en pasar de la coordinación informal a la coordinación por protocolo. Eso exige responder preguntas muy concretas. ¿Qué evento autoriza a producir o mover material? ¿Quién emite la señal y quién la ejecuta? ¿Qué información mínima viaja con ella? ¿Qué cantidad autoriza y cuál prohíbe? ¿Qué pasa cuando la señal no vuelve?

Piensa en una línea de mecanizado con 2 tornos CNC, 1 centro de mecanizado y 1 lavadora final. En el turno de tarde se fabrican cuerpos de válvula de aluminio, 320 piezas por turno. Entre el segundo torno y el centro de mecanizado hay un supermercado con 3 contenedores de 40 piezas, cada uno con su tarjeta. Cuando el centro vacía un contenedor, libera la tarjeta y la cuelga en el buzón del torno. Esa tarjeta, y solo esa tarjeta, autoriza al torno a fabricar 40 piezas más. Si el torno fabrica sin tarjeta, está rompiendo el protocolo aunque "vaya adelantado". Si la tarjeta no vuelve en el plazo esperado, el sistema está gritando que hay un problema.

La tarea no es pedir "más comunicación" al equipo. La tarea es construir un mensaje donde actuar correctamente sea más fácil que improvisar.

Acciones

Para diseñar un kanban que funcione como protocolo entre agentes, recomiendo vigilar 4 propiedades. Son las mismas 4 condiciones del agente que vimos en el post anterior, ahora impresas en una tarjeta. Sencillas de nombrar, exigentes de aplicar con disciplina.

Propósito único del mensaje. Una tarjeta kanban autoriza una cosa: reponer o producir una cantidad concreta de una referencia concreta. No pide opinión, no negocia prioridades, no sirve "para avisar". En sistemas digitales pasa lo contrario: mensajes que mezclan datos, alertas y peticiones, y que cada receptor interpreta a su manera. Si el mensaje tiene más de un propósito, el protocolo ya está roto.

Límites incorporados en la propia señal. La tarjeta dice 40 unidades. No 38 porque hoy falta gente ni 80 porque "así vamos tranquilos". El número de tarjetas en circulación fija el inventario máximo del sistema: nadie puede inflarlo sin retirar o añadir tarjetas, y eso es una decisión de diseño, no de turno. Este punto evita dos males: el micromanagement del planificador que aprueba cada movimiento y la improvisación disfrazada de agilidad.

Información situada en el punto de decisión. Una tarjeta bien diseñada lleva todo lo que el agente receptor necesita: referencia, cantidad, origen, destino, contenedor y criterio de urgencia si aplica. El torno no tiene que abrir el ERP, llamar a planificación ni interpretar un correo. Lee la tarjeta y ejecuta. Si un agente digital debe lanzar una orden de reposición, necesita exactamente lo mismo: consumo real, stock del supermercado, capacidad y restricciones, en el momento y en el punto donde se decide. Sin información situada, la coordinación se convierte en apuesta.

Escalada cuando la señal falla. Un sistema maduro no pregunta "¿quién tiene la culpa?", sino "¿cuándo debía haberse visto?". El kanban escala solo: si el buzón del torno acumula 3 tarjetas sin atender, el problema es visible desde el pasillo. Si una tarjeta no vuelve en su ciclo esperado, falta material o sobra avería, y eso activa el andon antes de que el centro de mecanizado se quede parado. En el ejemplo de la célula, un contenedor que tarda más de un turno en reponerse obliga a avisar a mantenimiento o a ingeniería de proceso, no a fabricar a escondidas contra stock.

Estas propiedades no son teoría de oficina. Son diseño operativo. Cuando se respetan, cientos de decisiones diarias se toman sin reuniones, sin correos y sin héroes. Cuando se ignoran, todo acaba dependiendo del veterano del turno, del encargado que mejor apaga fuegos o del planificador que rehace el programa 6 veces al día.

Resultados

Aplicar esta lectura del kanban permite obtener coordinación rápida y trazable sin autoridad central. La planta gana velocidad porque la señal viaja directa del consumo a la reposición. También gana control porque los límites viajan dentro del propio mensaje y el inventario máximo está fijado por diseño.

En el ejemplo de la célula de mecanizado, el resultado esperado no sería prometer un ahorro sin medir. Sería empezar por indicadores observables: tiempo de ciclo de cada tarjeta, tarjetas atendidas fuera de plazo, reposiciones ejecutadas sin tarjeta, roturas de material en el supermercado y nivel real de inventario en curso frente al teórico por número de tarjetas. Con 4 semanas de datos ya puedes separar opinión de realidad.

La mejora aparece cuando el sistema aprende de cada desviación. Si las tarjetas del segundo torno vuelven sistemáticamente tarde, no basta con pedir más atención. Habrá que revisar vida de herramienta, tamaño de contenedor, número de tarjetas en circulación y frecuencia de recogida. Ahí el kanban se parece mucho a una arquitectura de eventos bien diseñada: mide la latencia de sus mensajes, detecta cuellos y ajusta el protocolo, no a las personas.

También cambia la conversación con los equipos. En vez de preguntar "¿por qué fabricaste de más?", preguntas "¿qué señal te autorizó a fabricar?". En vez de exigir coordinación de palabra, das un protocolo visible, un límite claro y una escalada que protege el flujo. Eso desarrolla talento porque convierte la experiencia de planta en reglas compartidas que cualquier agente, humano o digital, puede ejecutar.

Si estás pensando en agentes de IA para operaciones, te propongo empezar por una pregunta más básica: ¿tu fábrica ya tiene un protocolo de señales o sigue coordinándose a base de reuniones y urgencias? Mira un flujo de reposición, uno solo. Identifica qué evento debería disparar la acción, qué información necesita viajar con la señal y qué límite no debe poder saltarse nadie. Después mide 2 semanas.

En brotherHUB trabajamos ese punto con equipos de dirección, operaciones, fábrica y cadena de suministro. No empezamos prometiendo integraciones. Empezamos diagnosticando dónde la señal llega tarde, dónde el mensaje no lleva la información necesaria y dónde el sistema obliga a la gente a improvisar.

¿Quieres transformar tus operaciones? ¡Hagámoslo juntos! Podemos revisar contigo un flujo concreto y convertirlo en tu primer protocolo kanban con límites y escalada. La pregunta es directa: ¿qué movimiento de material de tu planta se decide hoy a gritos, cuando debería decidirlo una señal?

Cuando una planta pierde 45 min por turno esperando una decisión, el problema no suele estar en una máquina aislada. Está en la arquitectura del sistema: quién ve el problema, quién puede actuar, qué información circula y cómo se evita repetir el fallo. Mi tesis para esta serie es directa: el Toyota Production System fue una arquitectura de agentes antes de que usáramos esa palabra para hablar de inteligencia artificial.

Situación

Durante años hemos explicado el Toyota Production System como un conjunto de herramientas: kanban, jidoka, andon, heijunka, estándar de trabajo y mejora continua. Esa lectura se queda corta. El TPS nació como una forma de diseñar decisiones distribuidas en una fábrica con restricciones reales: poco capital, demanda variable, inventario limitado y necesidad de aprender rápido. Hoy muchas empresas hablan de agentes de IA para automatizar tareas, coordinar flujos y responder a incidencias. Opino que quien entiende bien el TPS tiene media arquitectura aprendida. Este primer post abre la serie: veremos el problema, el coste de ignorarlo y por qué Toyota resolvió hace décadas preguntas que ahora vuelven con otro vocabulario.

Me he encontrado muchas veces con plantas que tienen buenas personas, máquinas razonables y sistemas informáticos caros, pero siguen funcionando a base de persecución. El jefe de turno llama a planificación, planificación pregunta a compras, compras espera respuesta del proveedor y producción se queda con 18 órdenes abiertas en una pantalla que nadie cree del todo. En paralelo, una máquina de mecanizado para por falta de una referencia, mientras otra fabrica piezas que no se necesitan hasta dentro de 12 días.

El coste no aparece siempre con una etiqueta clara. Se reparte en inventario, horas extra, urgencias de transporte, reprocesos, reuniones y pérdida de confianza. Un cambio de útil que debería durar 35 min se convierte en 70 min porque faltan mordazas. Un operario detecta una rebaba en la pieza número 14, pero no para porque "ya avisará calidad". Al final del lote hay 120 piezas dudosas, 4 h de selección y una conversación incómoda con el cliente.

En una línea de montaje de subconjuntos metálicos para defensa, el turno de tarde acumulaba retrasos casi todos los jueves. No era falta de esfuerzo. El problema era que las desviaciones de suministro se conocían en almacén a las 10:00 h, llegaban a planificación a las 13:00 h y producción las descubría al montar el kit a las 17:30 h. La decisión estaba demasiado lejos del hecho.

Ese es el punto de dolor: la fábrica sabe cosas, pero las sabe tarde, en lugares separados y sin autoridad suficiente para actuar. Aquí entra Toyota.

Tarea

La tarea no es "implantar Lean" como quien instala un módulo. La tarea es diseñar un sistema donde cada punto de trabajo pueda detectar una desviación, decidir dentro de un marco claro y escalar solo lo que supera su capacidad. Eso, en vocabulario actual, se parece mucho a un sistema de agentes.

Definición mínima: un agente es una unidad capaz de percibir un estado, tomar una decisión acotada, ejecutar una acción y alimentar el aprendizaje del sistema. Puede ser una persona, una máquina, una tarjeta kanban, una célula de trabajo, un algoritmo o una combinación de todo ello. Lo relevante no es si el agente "piensa" como una persona. Lo relevante es si actúa con autonomía controlada.

El Toyota Production System organizó esto con una precisión notable. Jidoka daba permiso para parar ante una anomalía. Kanban transmitía necesidad real desde el consumo, no desde una previsión inflada. El estándar de trabajo definía el rango aceptable de acción. El andon hacía visible la incidencia en el momento en que ocurría. Kaizen cerraba el ciclo de aprendizaje.

En mi opinión, aquí está la lección más incómoda para muchas implantaciones digitales: automatizar una mala arquitectura solo acelera el desorden. Si nadie tiene claro qué decisión corresponde al operario, al responsable de línea, a planificación o al sistema, añadir IA no mejora el flujo. Lo vuelve más opaco.

Acciones

Para mirar el TPS como arquitectura de agentes, recomiendo cambiar la pregunta. No empieces por "¿qué herramienta Lean aplicamos?". Empieza por "¿qué decisiones se toman demasiado tarde, demasiado arriba o con datos pobres?". Esa pregunta baja rápido a planta.

Kanban es un buen ejemplo. Una tarjeta de cartón parece rudimentaria, pero contiene una lógica potente: identifica referencia, cantidad, punto de consumo, punto de suministro y condición de reposición. No pide permiso a un comité. Tampoco improvisa. Actúa cuando se cumple una condición. Es autonomía dentro de límites.

Jidoka opera igual. La máquina o la persona detectan una anomalía y activan una respuesta. En Toyota, parar no era un fracaso; era una forma de impedir que el defecto viajara aguas abajo. Esto conecta con un principio que hoy se olvida al diseñar agentes de IA: un buen agente no solo ejecuta tareas, también sabe cuándo detenerse y pedir ayuda.

Percepción: el puesto detecta consumo, defecto, falta de material o desviación de tiempo.

Decisión acotada: el estándar define qué puede resolver el propio agente y cuándo debe escalar.

Acción: se repone, se para, se ajusta, se cambia la secuencia o se activa soporte.

Aprendizaje: el problema se analiza, se elimina la causa y se actualiza el estándar si procede.

El andon añade otra pieza. Convierte un problema local en información compartida. No para culpar a nadie, sino para acortar el tiempo entre el hecho y la ayuda. Cuando el problema se ve a los 2 min, aún es operativo. Cuando aparece en el informe del viernes, ya es financiero.

En esta serie vamos a recorrer esa idea en 5 posts. Este primero abre el marco: TPS como arquitectura de agentes. En el segundo hablaremos de kanban como protocolo de comunicación. En el tercero entraremos en jidoka y andon como mecanismos de control y escalado. En el cuarto veremos estándar de trabajo y kaizen como memoria del sistema. En el quinto llevaremos todo esto a la Industria 4.0 y a los agentes de IA sin vender humo.

Resultados

Mirar el TPS así permite ordenar conversaciones que suelen mezclarse. Una cosa es digitalizar datos. Otra es rediseñar decisiones. Otra es automatizar tareas. Y otra, muy distinta, es construir un sistema que aprenda sin depender de 5 personas que lo llevan todo en la cabeza.

Cuando la arquitectura está bien diseñada, el impacto se nota en indicadores sencillos: menos esperas entre operaciones, menos inventario de seguridad, menos urgencias, menos piezas bloqueadas y menos decisiones elevadas a dirección. No prometo porcentajes sin diagnóstico; sería poco serio. Sí afirmo algo por experiencia: cuando acercas información y autoridad al punto de trabajo, el sistema respira.

También cambia la conversación con la tecnología. Un sensor en una prensa, un MES o un agente de IA pueden aportar mucho si entran en un sistema con reglas de decisión claras. Si no, solo añaden otra capa de avisos. He visto pantallas con 40 alertas activas que nadie atendía porque ninguna distinguía entre ruido y pérdida real de producción.

El TPS obliga a preguntar: ¿qué señal merece acción?, ¿quién actúa?, ¿en cuánto tiempo?, ¿con qué límite?, ¿cómo se mide el resultado? Estas preguntas valen para una tarjeta kanban y para un agente digital que reprograma órdenes. Cambia la tecnología, no cambia el problema de fondo.

Si diriges una fábrica, una operación logística o una cadena de suministro, te propongo una prueba sencilla antes del próximo post. Elige una incidencia repetida de la última semana: falta de material, parada de máquina, cambio urgente de secuencia, defecto recurrente o retraso de expedición. Reconstruye el recorrido en minutos. ¿Cuándo ocurrió? ¿Cuándo se supo? ¿Quién podía actuar? ¿Qué información faltaba? ¿Qué se aprendió para que no volviera a pasar?

Ahí aparece la arquitectura real de tu sistema, no la que figura en el organigrama. Y casi siempre se ve una distancia excesiva entre el hecho y la decisión.

En el próximo post bajaremos a una pieza concreta del TPS: kanban como protocolo de comunicación entre agentes. Veremos por qué una tarjeta de cartón bien diseñada puede enseñar más sobre coordinación que muchos proyectos digitales llenos de integraciones.

Si esta lectura te encaja con algo que ves en tu planta, sigue la serie y compártela con tu equipo de operaciones. Y si quieres revisar dónde se están perdiendo decisiones, tiempo y margen en tu flujo, hablemos con datos de tu fábrica encima de la mesa. ¿Quieres transformar tus operaciones? ¡Hagámoslo juntos!