El árbol CTQ: de una necesidad del cliente a un requisito que se puede medir

"Necesitamos mejor servicio al cliente." "El producto tiene que ser más fiable." Frases así aparecen en casi cualquier proyecto de mejora, y son un mal punto de partida: son ciertas, pero no dicen qué hay que medir ni cuándo se ha cumplido el objetivo. Un equipo puede pasar semanas diseñando soluciones para un problema que todavía no ha traducido en números.

El árbol CTQ (Critical to Quality) existe para cerrar esa distancia entre lo que dice el cliente y lo que el equipo puede realmente medir y verificar.

Qué es un árbol CTQ

Un árbol CTQ descompone una necesidad amplia del cliente en tres niveles, cada uno más concreto que el anterior:

• Necesidad: lo que el cliente dice en sus propias palabras. "Quiero un buen servicio."
• Impulsores de calidad (drivers): los factores concretos que el cliente usa, aunque no lo diga explícitamente, para juzgar si esa necesidad está cubierta. "Que me respondan rápido", "que me traten como si me conocieran".
• CTQ o requisito medible: la especificación concreta, con un número o un límite, que ese impulsor tiene que cumplir. "Responder en menos de dos minutos."

El requisito final tiene que ser accionable y medible: si no se puede verificar con un dato, no es todavía un CTQ, sigue siendo una intención.

Un origen con otro nombre

El árbol CTQ se documentó como herramienta de la fase "definir" de Six Sigma en textos de referencia como el Six Sigma Pocket Guide de Rath & Strong y Lean Six Sigma de Michael George, ambos de finales de los noventa y principios de los 2000.

Pero la lógica de cascada que usa —partir de la voz del cliente y descomponerla en niveles cada vez más específicos— es anterior, y viene de Japón. En 1966, Yoji Akao y Shigeru Mizuno desarrollaron el Quality Function Deployment (QFD), un método para traducir la voz del cliente en características de diseño a través de matrices en cascada. El árbol CTQ es, en el fondo, una versión simplificada de esa misma idea: menos matrices, más rápido de construir, pensado para un equipo de mejora y no para un departamento de diseño de producto completo.

Una instrucción como "mejorar el servicio al cliente" es demasiado amplia para actuar sobre ella. El árbol CTQ permite descomponerla en requisitos concretos, medibles, que el equipo debe cumplir para satisfacer esa necesidad.

Cómo se construye

1. Identificar la necesidad. Se recoge en términos amplios, tal como la expresa el cliente: encuestas, entrevistas, quejas, o conversación directa con quien atiende al cliente cada día.
2. Identificar los impulsores. Qué hace que esa necesidad se sienta cubierta o no. Conviene no quedarse en el primero que aparece: suele haber tres o cuatro por necesidad.
3. Definir el requisito medible. Para cada impulsor, un número, un límite o un umbral verificable. Aquí es donde entran las capacidades reales del equipo: qué recursos y qué tecnología hay disponibles para cumplirlo.

Se construye un árbol por cada necesidad crítica identificada, no uno solo para todo el proceso. Al final del ejercicio, el equipo tiene una lista de requisitos verificables, no una lista de buenas intenciones.

Dónde encaja con el resto del trabajo de mejora

El árbol CTQ conecta directamente con otras herramientas de la fase de definición. Los requisitos que salen de un CTQ son, muchas veces, exactamente lo que hay que escribir en la columna de Clientes de un diagrama SIPOC: lo que el proceso tiene que producir para satisfacer una expectativa concreta, no una vaga.

• Evita diseñar soluciones para necesidades que nadie ha verificado con datos.
• Da un criterio objetivo para decidir si un cambio realmente mejoró la calidad percibida.
• Separa lo esencial de lo agradable-pero-no-crítico, algo especialmente útil cuando los recursos son limitados.
• Da a un directivo un criterio de aprobación claro: "¿cumple este requisito, sí o no?", en lugar de una valoración subjetiva.

Formación disponible

Imparto una sesión práctica de construcción de árboles CTQ para contribuidores de mejora de procesos, mandos intermedios y directivos. El objetivo no es memorizar la teoría, sino salir con al menos un árbol construido sobre una necesidad real de la organización, con requisitos medibles que el equipo pueda usar desde el día siguiente.

Fuentes

Rath & Strong Management Consultants. Six Sigma Pocket Guide, p. 18. ISBN 0-9705079-0-9.

George, Michael L. Lean Six Sigma, p. 111. ISBN 0-07-138521-5.

Akao, Y. y Mizuno, S. (1966). Quality Function Deployment (QFD).

"How to Make a Critical to Quality Tree", Lucidchart (incluye plantilla visual de ejemplo).