Stop the line (Jidoka)

“Para la producción, de modo que la producción nunca tenga que parar”. Dicen que en las fábricas de Toyota se emplea este proverbio para explicar que es mejor detener una linea de producción al encontrar un pequeño defecto para impedir la aparición de un defecto verdaderamente grave que pueda provocar la detención inesperada de la producción. A esta práctica se la conoce como “STOP THE LINE” y está basada en el principio del Jidoka, fundamental en los métodos de producción ajustada (o Lean Manufacturing).

El origen del Jidoka se remonta a 1896, cuando Sakichi Toyoda (fundador de Toyota) patentó un sencillo dispositivo que podía detener la lanzadera de un telar automatizado si el hilo se rompía. Esto no sólo impedía que la máquina continuara trabajando creando defectos sino que además alertaba al operario del problema, lo que implicaba que un único operario podía encargarse de varios telares en vez de estar pendiente de uno sólo por si acaso algo iba mal. A este principio también se le conoce como Autonomatización o Automatización “con un toque humano”.

Para los sistemas JIT (Just-in-Time) es esencial producir sin defectos (“Tolerancia cero a errores”) o de lo contrario estos defectos pueden detener el proceso de producción o afectar al flujo ordenado de trabajo. De ahí que TaiiChi Ohno incluyera el Jidoka como uno de los pilares fundamentales del Lean Manufacturing.

STOP THE LINE consiste en:

  1. Detectar la anormalidad.
  2. Parar.
  3. Arreglar o corregir la condición anormal.
  4. Inspeccionar para encontrar la causa raíz e instalar contramedidas.

Por ello, cuando un operario detecta un defecto, pulsa el botón de detención de la máquina de la que es responsable, pudiendo incluso obligar a la detención de la linea de producción completa. Es, por tanto, una decisión de diseño del proceso. La parada obliga a prestar atención inmediata al problema. La mejora continua consiste en localizar y eliminar las causas a estos problemas de manera que no surjan de nuevo.

La parada provoca que se ralentice la producción, pero esto ayuda a:

  • que el error no vuelva a aparecer,
  • incrementar la calidad de la producción,
  • reducir los desperdicios (tiempo, materiales, etc),
  • incrementar la producción,
  • asegurar las entregas a tiempo,
  • propagar las buenas prácticas.

Este principio no está limitado sólo a los procesos industriales de manufactura pues tiene más que ver con crear calidad desde dentro de un proceso en vez de inspeccionar al final del mismo. Ya lo dice el refrán: “Prevenir antes que curar”. Igual no has caído aún, pero si desarrollas software y además lo haces en un equipo, lo normal será que apliques este principio muy a menudo: la integración continua.

Yo, además, a todos los equipos que acompaño implementando el método Kanban les insisto en aplicar “STOP THE LINE”. Típicamente, cuando el ingeniero de QA detecta un defecto avisa a sus compañeros desarrolladores para que lo resuelvan inmediatamente. Y dirás, éso es una interrupción y las interrupciones son desperdicio, pero ésta es una buena interrupción pues evitará que un defecto llegue hasta la siguiente etapa. Por tanto, no creamos un ticket nuevo por cada defecto encontrado para que, en algún momento, un desarrollador lo tome y lo resuelva, ni tampoco mandamos el ticket hacia atrás, sino que detenemos la linea de producción, resolvemos el defecto y nos preguntamos por qué ha sucedido. Bueno, para ser sincero, esta última parte, la de la inspección, es la que peor se nos da a todos. La falta de holgura suele jugar en nuestra contra. Ya sé que es una excusa, otro día hablaré del miedo.

  • Isidro López

    Coño, parezco una groupie aquí comentando, pero es que estos temas me interesan… ^___^

    Lo cierto es que nunca había hecho la relación consciente del Jidoka con la integración continua en el desarrollo de software, me ha resultado muy interesante y acertada.

    Por profundizar un poco más en esa parte, y aunque tal vez sea muy obvio: la “integración continua” a secas, el simple hecho de subir el código a un repositorio común donde ejecute el build y tests (si los hay, ejem), no sirve de casi nada. Digo esto porque he trabajado en varios sitios donde se integraba continuamente, pero si se rompía la build o los tests, se podían pasar así horas (cuando no días en algún caso), acumulando nuevos commits de otros desarrolladores, hasta que “alguien” lo corregía. Como siempre, es lo malo de hacer algo “porque sí”.

    Enganchando con el “stop the line” que comentas, esta “integración continua” tiene que ir acompañada de un consenso explícito entre los desarrolladores respecto a cómo reaccionar cuando se rompa la build. Por ejemplo: en una empresa en la que estuve, con 6 equipos de desarrollo diferentes subiendo continuamente código a un mismo repositorio, había un consenso por el que cuando una build/test se rompía, no se podía hacer ningún nuevo commit hasta que no se arreglase. Y de hecho, establecimos unos tiempos máximos (del orden de minutos) para que, quien lo hubiera roto, lo arreglase o se diera marcha atrás. Un estadio aún más maduro que este, es aquél donde no es necesario establecer tiempos máximos porque siempre se corrige inmediatamente.

    Yendo un paso más allá en la integración continua, si llegamos hasta el idílico “continuous deployment”, con un pipeline definido (build, tests, staging, etc.), se trataría de que el despliegue automatizado a producción no se produzca si falla cualquiera de estos pasos… y que se arregle inmediatamente, seguido del análisis sobre por qué ha ocurrido que comentas.

    Por cierto: manda huevos que todos estos términos y prácticas los conocí inicialmente durante un, ejem, MBA, en la parte de Operaciones, en relación con la Gestión de la Cadena de Suministros 🙂

    • I think that lately the practice of CI is being relegated to using the tool (e.g. Jenkins) and not to the practice itself.

      I see the same happening with BDD: just because you use a specification language (e.g. Gherkin) doesn’t mean you get the full benefits of the practice.

      Maybe the cause is cargo cult toward a good thing: have we forgotten why we do these things, and we just do them?

      • El cargo cult ha existido siempre y siempre existirá. Creo que cada uno tenemos la responsabilidad de recordar a los que nos rodean los principios que rigen las prácticas para que éstas, como bien dices, se terminen haciendo por rutina. Cambiar de vez en cuando las prácticas, bien para mejorarlas, bien para explorar qué pasa cuando hacemos un cambio en las mismas, ayuda a evitar caer en la rutina. Usaría aquí una metáfora doméstica, pero la dejaré para cuando nos veamos en persona algún día, por si hay niños leyendo esto. 😉

    • Ja, ja, ja. Gracias Isidro. Cualquier comentario siempre se agradece.

      Respecto a lo que comentabas, la Integración Continua que se queda en construir los artefactos, como bien dices, no es suficiente, pero es el primer paso. El principio del Jidoka nos lleva a automatizar todo aquello donde hay intervención humana porque los seres humanos somos muy dados a cometer errores, pero siempre teniendo en cuenta que el ser humano es el más adecuado para actuar y corregirlo. Esa responsabilidad del humano es clave.

      En ese sentido, una parte clave de la Integración Continua es la comunicación de que se ha detectado un defecto. En cierta empresa donde participé en implantar IC en todo el departamento de desarrollo, planteamos una gamificación según la cual cada equipo iba aumentando de nivel a medida que iba mejorando en sus competencias, pero a la misma vez iba aumentando también el ámbito de la empresa a la que llegaban las notificaciones del sistema de IC cuando se detectaba un error. Hoy día no tengo muy claro qué efecto tuvo el asunto de las notificaciones llegando a toda la empresa si estabas en el mayor nivel, pero sospecho que ayudó a concienciar sobre la importancia de la autodisciplina.

  • Hi,

    Good article, just a small thought:

    In the list of things that Jidoka might help with you say ‘propagar las malas prácticas’.

    I believe there’s a typo/thinkos there.

    Keep up the good work,

  • Isidro López

    Por si alguien llega aquí buscando información sobre “Jidoka”, comparto otro artículo interesante:

    http://www.lean.org/LeanPost/Posting.cfm?LeanPostId=646