Aspectos de la descripción de un problema: la ruta más corta hacia la mejora continua
Aspectos de la descripción de un problema: la ruta más corta hacia la mejora continua
La metodología Six Sigma nos da unas pautas claras sobre cómo abordar un proyecto de mejora de procesos: usando la metodología DMAIC.
Cada fase del proceso tiene sus objetivos, sus herramientas y actividades, y sus resultados. En cualquier formación de Green Belt Six Sigma, se explica todo esto y más.
Pero hay algo que cuesta mucho entender y desarrollar correctamente, y que es la base de cualquier proyecto: describir el problema.
Dónde estamos y hacia dónde vamos
La descripción del problema establecerá el rumbo de nuestro proyecto. Nos dice cuál es el problema que queremos resolver.
Os daré un ejemplo muy gráfico: la descripción del problema es como la posición que me da el GPS. Si tengo una posición exacta, el GPS me podrá decir exactamente cómo llegar.
Si mi posición es aproximada, si más o menos me sitúa, podría acabar llegando al destino, pero ni estaré seguro de alcanzarlo ni tomaré el camino más eficiente.
Con la descripción de mi problema pasa lo mismo: si no es realmente clara, puede que llegue o que no llegue al destino. Pero, seguro que no lo lograré de la manera más eficiente.
Una descripción realmente clara
La palabra realmente es la que marca la diferencia.
Cuando pedimos a nuestros clientes que redacten la descripción del problema, siempre empiezan con algo que les parece muy claro: “tenemos un rechazo del 12% y es mucho”.
Ante la afirmación, surge una primera pregunta: ¿En qué proceso/línea de producción o producto?
Primera opción: es el proceso X. Entonces, entendemos que, sea cual sea el producto que sigue el proceso X, el total nos da 12% de rechazo.
Segunda opción: es el producto A. Entonces significa que este producto, esté fabricado en la línea 1 o en la línea 2, siempre generará un 12% de rechazo.
Tercera opción: es el producto A en la línea 1.
Ya se puede ver que el enfoque del problema no será el mismo en función de la opción elegida.
Pero vayamos más allá: ¿Un 12% es mucho?
Siempre pedimos a nuestros clientes que indiquen un valor absoluto cuando plantean un porcentaje.
No es lo mismo el 12% de 10 que de 1.000. Así que se tiene que especificar claramente el total producido o el total rechazado. O ambas cifras.
Otro aspecto a cuestionar es el tiempo: ¿Este 12% se ha calculado sobre los 3 últimos años, sobre los 6 últimos meses o en la última producción? ¿Ha habido cambios en el proceso o no?
Tomar datos de varios años puede conducir a falsas interpretaciones si el proceso ha cambiado, cosa que pasa con cierta regularidad. Así que es importante especificar el plazo analizado.
Con esto casi hemos acabado, solo quedaría eliminar el mucho .
Los adverbios y las locuciones adverbiales (mucho, poco, a veces…) no tienen cabida en una descripción de problema. Son un juicio aportado por una persona y, como todo juicio, son subjetivos.
Al ser valoraciones personales indefinidas, se abre la puerta a la discusión.
La cuantificación precisa de los costes
Aquí entra otro aspecto que tiene su propio apartado en la descripción del problema: el coste económico.
Los mucho o poco deben transformarse en coste de no calidad de XX€. Entonces la valoración ya no es si resulta demasiada o escasa. Se convierte en si es rentable realizar un proyecto para reducir estos costes de no calidad. Es un tema de ROI .
No es una cuestión de cuánto rechazo, sino de cuánto me cuesta rechazar productos.
Un rechazo de 1.000 productos que tienen un coste unitario de fabricación de 1€ (1.000€ de coste de no calidad) es menos grave que un rechazo de 100 productos con un coste unitario de fabricación de 20€ (2.000€ de coste de no calidad). Por eso suele ser más importante hablar de coste de no calidad en lugar de de volumen de rechazo.
Así que, llegados a estas alturas, nuestra descripción sería algo como:
Entre el 01/11/2021 y el 30/04/2022, hemos tenido una tasa de rechazo del 12% en la fabricación del producto A en la línea 1. Esto supone 2.078 productos de un total de 17.324 fabricados. El 70%, 1.454 productos, ha sido reprocesado, pudiéndose aprovechar; el resto, 624, han sido reciclados.
Después, en el apartado económico, podemos indicar los costes asociados:
• 1.474 productos reprocesados: coste personal, coste material…
• 624 productos chatarreados: coste producción de los productos, costes de reciclaje…
Un ejemplo real de descripción del problema
Dicho así, parece obvio, pero es importante que la descripción se ajuste fielmente a lo que realmente quiero hacer.
EL otro día, con un cliente, empezamos a plantear un proyecto: la máquina X debe llegar a tener un rendimiento de 300kg por hora.
Este proyecto, en principio, tiene que ver con hacer que la máquina trabaje más rápidamente. Pero, durante la conversación con el cliente, se añadió otro factor: este rendimiento se tiene que calcular sobre un turno de 8 horas.
Este condicionante lo cambia todo. Supongamos que la máquina pueda procesar, de por sí, 400kg/hora. Si, por averías o por cualquier otra fuente de paradas, solo funciona 4 horas al día, el rendimiento calculado sobre 8 horas sería de 4 horas x 400kg / 8 horas = 200kg/hora.
Ya no es un tema de velocidad de la máquina, si no de disponibilidad de máquina. El proyecto de mejora es totalmente distinto. Se trata de evitar paradas, no de mejorar el rendimiento de la máquina.
Pero a ese cálculo también habría que añadir los rechazos.
Si en este tiempo de funcionamiento tenemos una tasa de rechazo del 50%, entonces de estas 4 horas de funcionamiento solo podríamos aprovechar la mitad. O sea, que nuestro rendimiento real sería de 100 kg por hora.
Es decir, el proyecto podría tener que ver también con una reducción de los rechazos.
Aquí la única forma aclarar la descripción del problema, es teniendo datos sobre la disponibilidad en tiempo de funcionamiento de la máquina, la tasa real de rechazo y los tiempos de parada.
Obviamente, si se hace más de un producto en esta máquina, entonces también deberíamos tener estos datos separados por producto, ya que la actividad podría tener un impacto importante en los resultados.
Pensad, por un momento, que nos hubiéramos quedado con el primer enfoque: hacer que la máquina funcione más rápidamente. Habríamos empezado a analizar su funcionamiento, a buscar mejoras. Aunque, seguramente, en algún momento durante el análisis de los datos, alguien hablaría de paradas. Parecería obvio entonces que se deberían disminuir. Dejaríamos el trabajo realizado hasta ahora en pausa y nos enfocaríamos a las paradas.
Seguramente llegaríamos a un buen resultado, al destino, pero todo lo invertido al inicio del proyecto estaría perdido.
Llegamos, pero tardamos más. Y el tiempo es oro.
