Kaizen es una palabra japonesa compuesta por los términos Kai, que significa cambio, y Zen, que puede traducirse como “lo mejor”. Literalmente podría traducirse como “cambio para lo mejor”, y representa el concepto de Mejora Continua, englobando diversos elementos de la Gestión de la Calidad Total y del Sistema Productivo Toyota. El responsable de popularizar el término en occidente fué Masaaki Imai, autor del libro Kaizen: The Key to Japan’s Competitive Success, de 1986.

Kaizen

Kaizen en caracteres kanji

Suele decirse que hay dos formas de mejorar: mediante la innovación, y mediante la mejora continua. Ambas son necesarias y no son conceptos enfrentados, pero este artículo se centra sobra la segunda. La mejora continua no consiste en aplicar dos o tres grandes transformaciones o cambios radicales dentro de una organización, sino en aplicar progresivamente cambios pequeños y seguros, económicamente viables, que mejoren diversos aspectos del proceso productivo, especialmente los relacionados con la eficiencia. El lema de esta filosofía es “hoy un poco mejor que ayer, mañana un poco mejor que hoy”.

Un requisito para que la mejora continua sea posible es la adaptación al cambio. El taylorismo y el fordismo eran reactivos al cambio, ya que todo era planificado con mucha antelación mediante técnicas predictivas, buscando economías de escala, la repetitividad y la uniformidad del producto. Generalmente, la introducción de cambios o mejoras dentro de estos procesos era más costosa que el beneficio que dichas mejoras deparaban, ya que eran procesos rígidos e inflexibles. Por esta razón, cuando se encontraban los motivos de algún tipo de defecto o fallo dentro del proceso productivo, no quedaba más remedio que resignarse a desechar los productos defectuosos mediante un control de calidad por inspección, ya que modificar el propio proceso productivo era no factible.

El enfoque de la fabricación flexible es precisamente el opuesto. Los procesos no son rígidos, sino que se diseñan para poder cambiarse. Si habrá que cambiarlo, no tiene sentido planificar a largo plazo. No se utilizan por tanto las clásicas técnicas predictivas de planificación a largo plazo, sino técnicas adaptativas a corto plazo. Tampoco se buscan economías de escala, sino el menor tamaño de lote posible, o el mínimo alcance, evitando los stocks o los inventarios intermedios. En vez de buscar el abaratamiento de costes mediante la uniformidad del producto, se busca la mayor variabilidad posible. Es este escenario de adaptación al cambio lo que realmente permite introducir mejoras.

A nivel de dirección hay dos errores que son bastante frecuentes cuando se implantan procesos de mejora continua. La mayor parte de las normas y estándares de Calidad se centran en la construcción de sistemas formales y en la obtención de una etiqueta de certificación, que como el mismo Masaaki Imai denuncia, en realidad no garantizan ningún éxito. La estrategia de mejora pasa por pringarse las manos en el terreno, bajar al gemba y escuchar directamente de los trabajadores, que son los que mejor conocen las dificultades del día a día, cuáles son los obstáculos que se encuentran. El objetivo no es obtener ninguna pegatina o distinción, sino resolver los problemas reales. Cuando la dirección no escucha ni tiene en cuenta la experiencia de los trabajadores, la mejora continua suele reducirse a un lavado de cara externo, más relacionado con el marketing que con niguna otra cosa, del que los trabajadores se acaban enterando por la página web de la empresa y no porque su día a día haya cambiado en nada.

Otro error de la dirección, señalado por el propio Edwards Deming como una de las enfermedades mortales de la gerencia, es esperar resultados inmediatos o a corto plazo. La mejora continua no consiste en lograr milagros a corto plazo, sino en aplicar gradualmente pequeñas transformaciones, cuyas mejoras solo son visibles a medio y largo plazo.

En el contexto del desarrollo de software la Ingeniería de Software tradicional representa ese enfoque taylorista extremadamente reactivo al cambio y a las mejoras, donde toda modificación es lenta, costosa y burocráticamente pesada. Las mejoras dentro de un proyecto en marcha implican la modificación de la documentación de diseño, la replanificación del proyecto y una valoración de coste adicional. Dicho coste es tan elevado que generalmente no justifica el cambio. No suele haber problema en aprobar puntualmente aquellos cambios que claramente suponen mejoras drásticas, pero el camino de Kaizen no está compuesto por cambios puntuales y mejoras drásticas, sino por un conjunto constante de pequeños cambios y mejoras que dentro de una organización taylorista quedan naturalmente impedidos.

Dentro de los enfoques modernos de desarrollo, por el contrario, existe una práctica denominada refactorización que refleja algunas de las ideas de Kaizen. La refactorización consiste en mejorar el código mediante la incorporación de pequeñas mejoras que no alteren su funcionalidad, pero que lo hagan más simple, robusto o mantenible. Podría decirse que a corto plazo la refactorización no implica ninguna ventaja externamente observable, sino que es a medio y largo plazo cuando se observan sus beneficios. En realidad el desarrollo de software es un tanto peculiar porque lo que sí está constatado a corto plazo es que cuando no hay una refactorización constante, la complejidad, los bugs y los efectos colaterales aumentan exponencialmente en un plazo brevísimo de tiempo. La única forma de mantener grandes sistemas es mediante una refactorización constante, y aquellos donde no se practica son sistemas inmantenibles donde cada vez que alguien cambia algo todos cruzan los dedos para que no explote nada en ninguna parte.

Gran parte de las certificaciones de calidad, cuando se aplican sobre los procesos de desarrollo de software, rara vez tienen en cuenta la refactorización, la mejora del código, o el seguimiento de los estándares de codificación. Precisamente como Masaaki Imai describe, son meros sistemas formales muy alejados del gemba y del día a día. Para colmo, como ha quedado expuesto en el artículo sobre Jidoka, suelen ser sistemas centrados en el seguimiento de un proceso con unos determinados puntos de control, y están más relacionados con la inspección que con la calidad integrada. Se trata por tanto de enfoques tayloristas, reactivos al cambio y a la mejora continua, que si algo certifican y garantizan es precisamente lo difícil que debe resultar producir algo de calidad dentro de las organizaciones que con tanto orgullo las ostentan. Todas las grandes consultoras que emplean mano de obra en el tercer mundo para subcontratar y externalizar los servicios de desarrollo de software cuentan con todas las certificaciones y sellos de calidad imaginables. Eso demuestra que cuando hablamos de calidad, no todos hablamos de lo mismo.