Control visual: hacer visible el problema

Share
Control visual: hacer visible el problema

Imagina un almacén donde el nivel de inventario de un componente crítico se agota sin que nadie lo note. El sistema lo registra, hay un reporte semanal que lo menciona, y en teoría cualquiera podría consultarlo. Pero nadie lo hace hasta que la línea de producción se detiene por falta de esa pieza. El problema existía desde hacía días; simplemente nadie lo había mirado.

Este patrón —un problema que existe en los datos, pero no en la atención de nadie— es exactamente lo que el control visual (visual management) busca eliminar. La causa no es falta de información: es que la información está disponible, pero no es visible. Hace falta buscarla, abrir un reporte, preguntar a alguien. Y lo que exige un esfuerzo activo para descubrirse, tarde o temprano deja de descubrirse.

Hacer visible lo que importa

El control visual es una de las funciones centrales de la gestión visual dentro del pensamiento Lean: convertir el estado real de un proceso en algo que cualquiera puede ver de un vistazo, sin preguntar, sin abrir un sistema, sin esperar un reporte. Algunos ejemplos comunes:

  • Un tablero Kanban con columnas de estado
  • Una luz Andon que se enciende cuando una máquina se detiene
  • Un marcador de nivel mínimo pintado directamente sobre el estante del almacén

Todos cumplen la misma función: convierten un dato en un hecho visible.

La idea central es sencilla y poderosa:

Cuando un problema es visible, alguien lo nota. Y cuando alguien lo nota, alguien actúa.

Muchas veces esto ocurre sin que exista ningún proceso formal que lo obligue. La sola visibilidad genera una presión organizacional silenciosa hacia la corrección, porque ignorar un problema que todos pueden ver tiene un costo distinto al de ignorar un dato enterrado en un reporte que nadie revisa.

La mejora como efecto de la atención

Esto tiene una consecuencia poco intuitiva: el control visual no resuelve problemas directamente, pero fuerza su resolución de forma indirecta, por la simple acumulación de atención sobre lo que importa. Un tablero que marca en rojo una tarea atrasada no ejecuta esa tarea. Pero cada persona que pasa frente al tablero ve el rojo, y esa repetición diaria construye una presión que termina moviendo a alguien a actuar donde antes nadie sentía la urgencia.

Es la razón por la que muchas organizaciones que instalan un tablero de estado, sin cambiar ningún otro proceso, ven mejoras reales en las primeras semanas. No cambiaron el proceso: cambiaron lo que era visible dentro de él.

Perspectiva Poka-yoke (Shigeo Shingo)

Un sistema Kanban con un límite fijo de tarjetas en circulación es, en la lógica de Shigeo Shingo, un mecanismo poka-yoke tan riguroso como cualquier dispositivo mecánico: cuando se alcanza el número máximo de tarjetas, estructuralmente no se puede iniciar una unidad más, sin que nadie tenga que decidirlo ni recordarlo.

Tipo de inspección Método Función reguladora
Inspección en la fuente (source inspection) Valor fijo (fixed-value method) Método de control (control method)

A diferencia de una alerta que solo informa (una luz Andon, por ejemplo, que depende de que alguien la note y reaccione: de aviso, warning method), el límite de tarjetas Kanban impide estructuralmente que el proceso continúe fuera de los límites establecidos. Es la diferencia entre hacer visible un problema y hacer imposible que el problema crezca sin control: ambos son control visual, pero solo el segundo elimina la dependencia de que alguien preste atención a tiempo.

Si en su organización los problemas se descubren solo cuando alguien pregunta, o cuando ya es demasiado tarde, con gusto reviso con usted qué partes de su proceso podrían hacerse visibles desde hoy, en Contacto.

Read more