La conexión perfecta para lograr un buen proceso diagnóstico en un proyecto Seis Sigma

Uno de los aspectos fundamentales para lograr resolver un problema de negocios, en el ámbito del Seis Sigma y la mejora continua de procesos, es lograr identificar eficazmente las causas raíz que generan el problema. En las primeras etapas del ciclo DMAIC es común batallar con la identificación y desarrollo de estadísticas valiosas que permitan diagnosticar adecuadamente las causas raíz del problema. Es común ver obstáculos que generalmente a los lideres de proyecto se les presentan y cómo estos obstáculos pueden dar al traste con un plan de acción lo suficientemente bueno para solucionar el problema.

En este particular, es importante saber que los proyectos seis sigma son como eslabones de una cadena. Imagínese una cadena, su función puede ser la de transmitir fuerza a lo largo de toda su extensión para generar tracción en una bicicleta, mover unos piñones en una máquina de planta o simplemente resguardar seguramente el portón de nuestra casa cuando salimos de vacaciones.

El punto es, que cada etapa del DMAIC se relaciona íntimamente con su etapa predecesora, y si no hacemos eso, lo olvidamos o lo hacemos mal, posiblemente lo que va a suceder es que el proyecto no logre los resultados esperados, es más, le puedo garantizar que no hacer este ejercicio de “encadenamiento” puede generar un efecto “bola de nieve” que afecte por igual a todas las demás etapas de su proyecto de mejora continua.

Para esta ocasión, quiero conversar sobre la relación entre las 2 primeras fases, sus encadenamientos, que en este caso serian para las etapas DEFINIR y MEDIR. Escogí estas dos fases por ser claves en el proceso de planificación del proyecto, además, por ser las que sistemáticamente me han demostrado una “alta tasa de mortalidad” con respecto a lo que presentan green belts y black belts en proceso de entrenamiento para certificación. Las demás etapas las cubriré en entregas futuras del Blog de PXS.

Bueno, empecemos, es importante entender que el elemento que une a una fase de DEFINIR y una MEDIR es el árbol de críticos de calidad, o CTQ TREE. Esto por cuanto necesitamos empezar a cuantificar estadísticamente factores causales en MEDIR, y estos factores causales deben estar necesariamente alineados con la meta del chárter, que como usted sabe está en DEFINIR. Hasta ahí vamos bien, sin embargo, el asunto de hacer este alineamiento nace desde más antes, nace en la misma etapa de DEFINIR.

Le cuento en detalle; si nos enfocamos estrictamente en un problema seis sigma, por ejemplo, la tasa de abandono de clientes que llaman a un Call Center, pues el green belt o el black belt en conjunto con el equipo podrían plantear un “Project goal” como así:

“Disminuir en al menos un 10% la tasa de abandono de los Clientes que llaman al Call Center para el 30 de Octubre de 2022”

Sin meternos en mucho detalle, de si hay validación del problema, de si el caso de negocio es válido, de si hay una buena delimitación de proyecto; pues lo que nos ocupa saber es cómo diagnosticar bien las causas del problema. Para ello, entonces vamos a explicar cómo diseñar el Árbol de críticos de calidad, que es la herramienta puente entre DEFINIR y MEDIR según mi criterio.

Primero recordemos que el concepto “CTQ” es relativo a la situación del proyecto que tenemos. Mucha gente tiende a confundir el concepto de CTQ. Según el Libro CSSGB PRIMER del Quality Council of Indiana un árbol de críticos de calidad “traduce los requerimientos iniciales del cliente en requerimientos numéricos o cuantificables para el producto o servicio”, sin embargo esa definición debe ser extrapolable a problemas y no solo a desarrollo de productos como originalmente conceptualiza la técnica. Es por ello que la propuesta mía es manejar el concepto de “CTP”. Recuerde que CTQ significa “crítico para la calidad”, sin embargo, si readecuamos ese significado a un proyecto de un problema de negocio, realmente lo que nos importaría sería un “crítico para el problema”.

La experiencia práctica dicta que la mayoría de nosotros estamos enfocados a solucionar problemas de negocio y no tanto al desarrollo o diseño de productos (al menos en Costa Rica), por lo que todavía con mucha más razón, el enfoque del CTP es más valioso que el del CTQ, que puede tender a confundir al “belt novato”.

Ahora bien, la pregunta de los 30 millones de ¿Quién quiere ser millonario?  Sería, ¿qué debo medir?

Lo primero que usted debe saber, es que a la etapa de MEDIR usted no llega a inventar qué medir, eso ya viene cocinado de DEFINE, la razón de mi afirmación es que como he dicho anteriormente la relación entre DEFINIR Y MEDIR es el árbol de críticos de calidad y ahora rebautizado como árbol de críticos PARA el problema. Entonces, para saber qué debo medir bastará con volver a ver el árbol de CTPs de la etapa DEFINIR y simplemente ejecutarlo, ¿más sin embargo cómo identifico los CTPs? Pues esa es la razón de ser de este artículo, le mostraré a continuación un método que me ha ayudado a resolver esta situación y que nace a partir de mi ejercicio empírico como facilitador de mejora de procesos y profesor de seis sigma de ya hace unos años.

Antes de explicarle mi método, le refresco un poco la estructura que tiene el Árbol de críticos de calidad. Es básicamente un árbol de decisión adecuado, donde vamos de lo general a lo especifico. Se maneja un encabezado donde se plantea la necesidad y dos niveles más, el nivel del “driver” y el nivel de “crítico de calidad”; los “CTQs” se agrupan en forma de “drivers”. Finalmente, un último nivel de métricas, que son simplemente la forma matemática que permitirá cuantificar el “CTQ”, le muestro la siguiente imagen como referencia:

Pareciera bastante simple, el completar ese diagrama, sin embargo, le puedo garantizar que son realmente pocas las personas que la primera vez que se les explica logran hacerlo bien, de hecho, muchas ocasiones el haber hecho mal el diagrama de árbol de críticos repercute en la etapa de MEDIR generando malas mediciones causales y por ende análisis e implementaciones muy deficientes.

Los principales errores que comente la gente son:

• No ligar la necesidad documentada en el diagrama de árbol de críticos con la meta del proyecto, es sumamente común que la gente ponga cosas que no se relacionan en mucho con la meta del proyecto. Esto es grave porque provoca desalineamiento del diagnóstico con la meta del proyecto.
• Muchas “y” y pocas “x”, que significa que la tendencia es volver a ver las mediciones que ya de por sí tenemos en los sistemas de la empresa, pero olvidamos el hecho que muchas de estas mediciones están diseñadas para mostrar resultados, a gerentes, clientes, nosotros, etc. pero no para demostrarnos aspectos que pueden estar causando problemas. Como resultado la gente tiene a crear arboles de críticos cargados de mediciones de resultados, que en nada ayudan a diagnosticar factores causales y que lo único que hacer es re-confirmar el hecho de que tenemos un problema que resolver.
• Pocos o muchos CTQs o como a mi me gusta llamarles CTPs, esto implica que o no se nos ocurre mucho que medir, lo que nos limita a poder diagnosticar bien, o más bien ponemos demasiados posibles CTPs condenándonos a procesos de medición sumamente largos, y poco prácticos, alejándonos de lo que realmente es importante.
• Métricas mal diseñadas, cada CTP debe tener una declaración de como se va a cuantificar el mismo. Es común ver, árboles con cosas que no son métricas, o métricas mal diseñadas o simplemente en lugar de la métrica ponen la meta o especificación y eso no esta bien, al fin y al cabo, lo que buscamos es diagnosticar.

Finalmente, y algo que en general afecta, además de los 4 anteriores puntos, es la  disponibilidad de datos. La primera reacción de todos es buscar entre los indicadores que ya la empresa habitualmente calcula. Esto no esta mal, al final y al cabo debemos apoyarnos en lo que hay para maximizar el recurso tiempo, pero ¿qué sucede cuando no hay mediciones del todo o nada?, no es mi idea abordar ese tema en este artículo, porque hay mucha tela por cortar ante esta situación, pero definitivamente es un factor que afecta a la construcción de un buen árbol de críticos de calidad (mantenga la calma).

¿Como se construye el Árbol de Críticos para el Problema?

Lo que a continuación le muestro, es un método desarrollado por mi persona con base a mi experiencia empírica de enseñanza, y que me ha resultado muy útil a lo largo de los años (un día de éstos lo patento 😉). Vamos a ver, debemos seguir los siguientes pasos:

Cada paso tiene una finalidad. El paso 1, que se refiere a utilizar el primer nivel de necesidad, busca colocar el efecto que se tiene como problema, así como ejemplo usted se recordará que el goal de mi chárter, que mencioné al principio era “Disminuir en al menos un 10% la tasa de abandono de los Clientes que llaman al Call Center para el 30 de Octubre”. Usted NO debe utilizar eso en la celda de “necesidad”, si usted hiciera eso el efecto que generará es poner al Equipo a pensar en solución y no en causa, nunca cometa ese error, debe replantear ese goal a algo que usted aproveche en el Árbol de CTPs y que tenga sentido, así entonces, lo que colocaremos en el campo de “necesidad” será:

“Alta tasa de abandono de los clientes que llaman al Call Center”

El redactar el goal del chárter en el árbol de críticos como problema permite que el siguiente ejercicio de hacer la tormenta de ideas de causas hipotéticas se facilite, la gente cuando le hagamos la pregunta: ¿Qué puede estar causando la alta tasa de abandono? de una vez se pondrán a pensar en causas y no en soluciones, dado que para soluciones falta mucho aún (IMPROVE) y hay que demostrar las causas (MEASURE + ANALIZE).

También hay que entender que el tomar el goal del chárter y replantearlo en forma de problema en el árbol genera directamente a-li-ne-a-mi-en-to (léase como doña Eugenia de tra-ba-jan-do). Eso es muy valioso pues como le comenté el proyecto es una concatenación de acciones que deben darse si se quiere tener éxito en el mismo.

Seguidamente, haga la pregunta que ya le planteé:

¿Qué puede estar generando el problema que necesitamos resolver?

Esa pregunta clave se la hacemos al Equipo de proyecto, para tratar de identificar causas hipotéticas. Es fundamental que entienda que la intención en este punto NO ES RESOLVER EL PROBLEMA, sino simplemente identificar las mediciones que tendremos que hacer en MEASURE para diagnosticar el problema con objetividad y usando buena estadística. En este particular, es sumamente importante que usted como líder de proyecto maneje la ansiedad del Equipo, de las partes interesadas e incluso de usted mismo, al tratar de implementar soluciones. El éxito del proyecto depende de que su diagnóstico sea integral pero sobre todo bien argumentado, si usted comete el error de tomar estos aportes, que son causas hipotéticas para empezar a  implementar puede ciertamente fallar en resolver el problema, perder credibilidad ante sus pares y perder más tiempo por tener que devolverse a las primeras etapas para poder volver a diagnosticar, la moraleja de esto es, no caiga en la trampa, estas causas hipotéticas solo sirven para plantear los críticos de calidad del árbol y saber que vamos a ir a medir en la etapa de MEDIR.

Siguiendo los pasos 3 y 4 vamos a replantear los aportes de la tormenta de ideas en forma de críticos para el problema CTPs. Así, por ejemplo, imagínese que nos dan los siguientes 5 aportes:

1. Las centrales ya no tienen capacidad y botan a los clientes que llaman.
2. Los operadores del call center están saturados y no logran dar abasto.
3. Nos pasa mucho los abandonos cuando son los pagos de quincena que la gente llama mucho.
4. En veces el suministro energía falla y se dan los abandonos.
5. La gente está desmotivada y no rinde igual en las llamadas.

Entonces vamos a replantearlos en forma de CTPs, tomando en consideración la siguiente pauta de diseño: “un CTQ es neutro en su abordaje, no dice que algo sea ni bueno ni malo, simplemente que es crítico para la calidad o para el problema” así por ejemplo tendríamos las siguientes equivalencias:

Como ve no hice la gran cosa, simplemente sinteticé cada aporte de la tormenta de ideas como un nombre genérico, intuitivo y claro. Tampoco tomé partido de si algo esta bien o está mal, dado que, ¡aún no lo sé! estoy apenas en DEFINIR.

Seguidamente aplico el paso 4, que es diseñar una métrica que permita cuantificar al CTP. En esta parte usted va a andar en dos mundos, el mundo de lo cualitativo y el mundo de lo cuantitativo, o lo que es lo mismo: datos atributivos y datos variables, por consiguiente, debe plantear estar métricas tomando en cuenta lo anterior. Veamos la siguiente tabla demostrativa:

Lo más importante es que note, que todos son planteamientos “algo matemáticos” de como cuantificar el crítico de calidad. Además, son neutrales, no dicen aún que algo este bien o mal, tercero, si se fija en cómo diseñé esas métricas todas tienen “dos dimensiones” que significa que podemos caracterizarlas bien en función de dos parámetros.

Finalmente, el paso 6, agrupo los CTQs (CTPs) y genero los “drivers”, que como mencioné son simples agrupaciones de críticos que se interrelacionan y que facilitan más adelante identificar posibles cursos de acción genéricos para varias causas raíz que se vayan detectando, así por ejemplo quedaría:

Vea que mi agrupamiento es muy “intuitivo” son cosas que me hicieron sentido, relacioné la capacidad de la central y el suministro eléctrico como recursos de sistemas y a los dos CTPs de demanda de llamadas y nivel de aprovechamiento del operador como desempeño de proceso. En veces pasa que un CTQ queda solo sin categoría, como el caso de motivación de personal, no hay problema, simplemente repita como driver el mismo CTQ o cree un driver que va a tener solo un CTQ.

Finalmente llame al “coach” que tenga, el máster black belt o el black belt y valide, recuerde que dos cabezas piensan mejor que una, al sponsor no le pida mucho criterio a menos que sea competente técnicamente en seis sigma (como consejo).

Nuestro Árbol de Críticos para el Problema quedaría elegantemente de la siguiente forma:

Recuerde entonces, que el Árbol de CTPs será entonces desplegado en la fase de MEDICIÓN, y a través de su cuantificación es que lograremos tanto validar qué cuestiones que pensamos, pueden estar generando el problema son efectivamente causas raíz como también descartar otros, que podría no ser causas o simplemente son causas que contribuyen pero que no son en definitiva raíz. Además, tenga cuidado con los extremos, la experiencia me ha enseñado que una media de 6 a 8 críticos para el problema es una buena medida de estadísticas para cuantificar, más de eso se vuelve laborioso y se tienden a perder foco y menos de eso por lo general es insuficiente para diagnosticar.

Fundamental, que sea consciente que los CTQs o CTPs como yo le llamo son factores causales o buscan serlo, son variables independientes “X” que buscan indicar si algo esta generando el efecto nocivo del problema, por ende, siempre trate de hacer CTQs que sean “X” y no “Y” de efecto.

Esta es la base de un buen proceso diagnóstico en Seis Sigma, más adelante les escribiré de este mismo diagrama de Árbol de Críticos de Calidad, pero aplicado a diseño de productos, que es el otro tipo que puede existir, como siempre le deseo mucho éxito en sus proyectos.