Cómo mejorar un proceso de negocio
Cómo mejorar un proceso de negocio: fija la línea base del proceso actual, busca la causa y no el síntoma, cambia una sola cosa cada vez y verifica que funcionó antes de darlo por cerrado.
Mejorar un proceso de negocio consiste en fijar una línea base de lo que ocurre hoy, encontrar la causa del problema en lugar de su síntoma, cambiar una sola cosa y verificar que el cambio funcionó de verdad.
En resumen
- Fija primero la línea base del proceso actual: no puedes demostrar una mejora frente a un proceso que nadie ha acordado.
- La contención detiene la hemorragia; no es la solución y se registra por separado.
- Cambia una sola cosa cada vez o no sabrás qué cambio funcionó.
- Verifica la eficacia pasado un plazo definido, contra la medida con la que empezaste.
- Eliminar un paso es una mejora. Añadir un aprobador casi nunca lo es.
La mayoría de las mejoras fracasa en el diagnóstico
La mejora de procesos tiene un modo de fallo muy conocido, y no es la pereza. Es diagnosticar desde el síntoma: las facturas se pagan tarde, así que añadimos un aprobador; las incidencias se reabren, así que añadimos una lista de comprobación. Cada una de esas reacciones es plausible ante lo observado y ninguna se apoya en por qué ocurre. Seis meses después el indicador sigue igual y el proceso tiene un paso más dentro, que es el coste real y acumulado de saltarse el diagnóstico.
La alternativa no es analizar más por analizar. Es una secuencia concreta: describe lo que ocurre hoy con suficiente detalle como para poder discutirlo, contén el daño inmediato sin fingir que la contención es la solución, encuentra una causa que las evidencias respalden, cambia una sola cosa y comprueba después si funcionó antes de darlo por terminado. El último paso es el que más se omite, y es el único que separa la mejora de la simple actividad.
El ejemplo de abajo es un proceso de análisis de causa raíz, el motor de diagnóstico que hay debajo de cualquier esfuerzo de mejora. Contiene las dos rutas que lo hacen honesto: una rama para cuando las evidencias no bastan, que permite cerrar con una limitación documentada en vez de inventarse una causa, y un bucle de verificación que devuelve al análisis toda hipótesis no probada.
El diagnóstico que hay debajo de la mejora
Un proceso de análisis de causa raíz, desde el problema abierto hasta las acciones correctivas aprobadas. Fíjate en dónde suelen atajar los equipos.
Define el problema antes de teorizar
Describir el problema tal como se observó, acordar una definición por escrito, aplicar contención inmediata y después formar el equipo de investigación. Una definición del problema escrita cuando alguien ya tiene una teoría acaba conteniendo esa teoría, y el análisis se limita a confirmarla.
Las evidencias, y la rama para cuando no las hay
Una decisión de suficiencia con tres salidas: continuar, ampliar la recogida o cerrar con una limitación de datos documentada. Esa tercera salida es justo lo que evita que una investigación se invente una causa cuando los registros ya se han rotado.
Contrasta la hipótesis, no la elijas sin más
Generar hipótesis de causa, contrastarlas con las evidencias y volver atrás en el bucle cuando la causa no queda verificada. Después, separar la causa raíz de los factores contribuyentes: un paso propio, porque si no los equipos escriben acciones contra el factor más fácil de arreglar.
Acciones aprobadas y con recursos
Se registran los hallazgos, se proponen acciones, una aprobación puede devolverlas y al final se abre un registro CAPA con responsables con nombre. La mejora muere justo donde las acciones están acordadas pero nadie ha financiado el tiempo, y por eso la aprobación se dibuja como una puerta.
Cómo funciona
Fija la línea base del proceso tal como es hoy
Mapea el proceso actual con quienes lo ejecutan, excepciones y apaños incluidos, y registra una o dos medidas: tiempo de ciclo, tasa de retrabajo, volumen en cada rama. Sin una línea base que la gente acepte, cualquier afirmación posterior de mejora es discutible, y será discutida.
Formula el problema sin una causa dentro
«Las facturas se pagan tarde» es un problema. «Los aprobadores son lentos» es una teoría disfrazada de problema, y cualquier análisis que empiece ahí termina ahí. Escribe el enunciado en términos de la observación y de la medida, y deja que las evidencias digan quién o qué está implicado.
Contén, y regístralo como contención
Donde el problema esté causando daño activo, párralo, pero anótalo como medida temporal con un responsable y una fecha de fin. La contención que se queda en silencio se convierte en un paso extra permanente, y además quita la presión de encontrar la causa real.
Encuentra una causa que las evidencias respalden
Recoge datos mientras aún existen, reconstruye la secuencia de los hechos, genera más de una hipótesis y contrástalas. Pararse en la primera explicación plausible es con diferencia el fallo más frecuente, y por eso la decisión de verificación del ejemplo vuelve atrás en lugar de seguir adelante.
Cambia una sola cosa
Elige el cambio más pequeño que ataque la causa, define qué es el éxito y para cuándo, e impleméntalo solo. Los cambios agrupados hacen imposible atribuir el resultado: si el indicador se mueve no sabrás cuál conservar, y si no se mueve no sabrás cuál revertir.
Verifica pasado un plazo definido y actualiza el diagrama
Vuelve cuando hayan pasado ciclos suficientes para ver una señal y compara contra la línea base. Si funcionó, actualiza el diagrama de proceso y su versión aprobada para que la forma nueva sea la forma documentada. Si no funcionó, reabre el análisis en lugar de apilar un segundo cambio sobre el primero.
Errores que debes evitar
Mejorar sin línea base
Sin un proceso actual acordado no hay forma de demostrar que el cambio ayudó, ni forma de darse cuenta de que no lo hizo.
Añadir un aprobador como solución
Es la reacción más a mano y ralentiza el proceso de forma fiable sin tocar por qué se produjo el error. La mayoría de las mejoras reales eliminan un paso.
Agrupar varios cambios
Cinco cambios a la vez producen un único resultado ambiguo. Secuéncialos, aunque parezca lento.
No verificar nunca
Una mejora que nadie ha comprobado es una suposición con un plan de proyecto grapado. El paso de verificación es lo que marca la diferencia entre mejora y actividad.
Mejora tu propio proceso
Abre el ejemplo de análisis de causa raíz como tu propio diagrama, o mapea antes tu proceso actual y trabaja a partir de ahí.
Guías relacionadas
Preguntas frecuentes
¿Cómo empiezo a mejorar un proceso de negocio?
Mapea lo que ocurre hoy, con las personas que lo hacen, incluidas las excepciones. Casi todos los proyectos de mejora que se atascan lo hicieron porque partieron de un proceso supuesto en lugar de uno documentado, y la versión supuesta es siempre el camino feliz. Cuando el proceso actual existe y la gente lo da por bueno, los problemas suelen identificarse solos: pasos sin responsable, bucles de retrabajo y traspasos en los que nadie avisa al receptor se ven sobre el papel.
¿Cuál es la diferencia entre un síntoma y una causa raíz?
Un síntoma es lo que observas: facturas tardías, incidencias reabiertas, entregas incumplidas. Una causa raíz es aquello que puedes eliminar para que el síntoma no pueda repetirse. El trabajo de mejora fracasa cuando trata el síntoma, porque el cambio que sale de ahí (otro aprobador, otra lista de comprobación) añade coste y no toca el mecanismo. La prueba de una causa raíz es si eliminarla habría evitado el problema, y si las evidencias lo respaldan en lugar de simplemente permitirlo.
¿Necesito Lean o Six Sigma para mejorar un proceso?
No, aunque ambos aportan un vocabulario útil. Los mecanismos que importan están disponibles sin metodología: documenta el proceso actual, mide algo, encuentra una causa respaldada por evidencias, cambia una sola cosa y verifica. Los programas formales añaden rigor y un lenguaje común, lo que ayuda a escala; también añaden una carga que puede superar el valor para un único proceso. Empieza por la secuencia y adopta el marco si el volumen de trabajo de mejora lo justifica.
¿Cómo consigo que una mejora se mantenga?
Actualiza el proceso documentado y su versión aprobada, cuéntaselo a quienes se ven afectados y vuelve a comprobarlo un trimestre después. Los cambios que solo viven en un informe de proyecto se deshacen en pocos meses, porque el proceso documentado sigue describiendo la forma antigua y a los nuevos compañeros se les forma en ella. La mejora no termina cuando se hace el cambio; termina cuando el diagrama, la formación y la práctica dicen lo mismo.