Quiero mejorar los procesos de mi empresa.

Cuando algo tarda demasiado, se atasca o sale mal, es fácil buscar el problema en la persona que estaba haciendo el trabajo en ese momento. Se pide más atención, se añade otra revisión, se cambia una responsabilidad, se contrata a alguien o se compra una herramienta para intentar que aquello funcione mejor.

Pero si el mismo problema vuelve a aparecer con personas distintas, quizá estemos mirando al lugar equivocado.

Cuando un problema aparece una y otra vez con personas distintas, quizá el problema no sean las personas. Quizá sea el proceso.

Un proceso es la forma real en la que el trabajo consigue avanzar.

Un proceso no es solamente un procedimiento escrito, un organigrama o un diagrama guardado en una carpeta. Es lo que ocurre desde que algo empieza hasta que termina.

Cómo entra un pedido. Quién lo revisa. Qué información necesita. Dónde se registra. A quién se avisa. Qué ocurre si falta algo. Quién puede decidir. Cuánto tiempo espera. Qué sistema interviene. Qué documento se genera y qué tiene que ocurrir para que el siguiente paso pueda comenzar.

Por eso, cuando quiero mejorar los procesos de una empresa, no empiezo preguntando cómo deberían funcionar. Empiezo entendiendo cómo funcionan de verdad.

El proceso que tienes no siempre es el proceso que crees que tienes.

Sobre el papel, un pedido puede pasar de Comercial a Administración y después a Producción. En la realidad quizá Comercial envíe primero un correo, Administración compruebe un Excel, alguien pregunte por WhatsApp un dato que falta, Producción espere una confirmación, otra persona actualice el ERP y finalmente alguien vuelva a avisar por correo de que el pedido ya puede continuar.

El proceso oficial puede tener tres pasos mientras que el proceso real tiene muchos más.

Por eso mapear un proceso no consiste en dibujar cómo nos gustaría trabajar. Consiste en seguir el recorrido real de la información, las decisiones y el trabajo hasta descubrir todo aquello que hemos añadido con el tiempo y ya consideramos normal. A menudo el problema empieza a verse precisamente ahí.

Un cuello de botella no siempre está donde más gente trabaja.

Cuando un proceso va lento, tendemos a mirar qué tarea tarda más en ejecutarse. Pero muchas veces el trabajo no está tardando: está esperando una aprobación, un dato, una respuesta, que otra persona termine una tarea, que alguien revise un documento o que llegue una información que debería haber estado disponible desde el principio.

Por eso, para encontrar un cuello de botella, me interesa tanto dónde se acumula el trabajo como cuánto tarda cada persona en realizar su parte.

Si todo el mundo está ocupado y el trabajo sigue esperando, el problema no se arregla pidiendo que corran más.

La velocidad de una persona no puede compensar indefinidamente un proceso que obliga al trabajo a detenerse.

Cada traspaso es un lugar donde el proceso puede romperse.

Comercial termina su parte y se la pasa a Administración. Administración prepara algo y se lo entrega a Operaciones. Operaciones necesita una validación de Dirección. Dirección responde y alguien tiene que comunicar que ya puede continuar.

Los cambios de responsable son normales. El problema aparece cuando cada cambio obliga también a trasladar manualmente la información, explicar de nuevo el contexto o recordar al siguiente que ahora le toca intervenir. Entonces un simple cambio de etapa se convierte en una pequeña coordinación y, cuando un proceso contiene muchas, una parte importante del trabajo consiste únicamente en conseguir que el propio proceso siga moviéndose.

Un buen traspaso debería parecerse menos a una conversación improvisada y más a una transferencia clara de responsabilidad, información y estado.

El retrabajo es una pista.

Hay procesos que parecen funcionar porque siempre terminan saliendo, pero terminan saliendo porque alguien corrige continuamente lo que ocurre durante el camino.

Se devuelve un documento porque falta información, se modifica un pedido porque un dato llegó mal, se vuelve a llamar al cliente porque nadie preguntó algo al principio, Administración corrige lo que recibió de Comercial, Producción devuelve algo a Administración o una persona revisa otra vez algo que ya había sido revisado. Eso es retrabajo: hacer de nuevo aquello que debería haber quedado resuelto en un paso anterior.

Cuando ocurre ocasionalmente puede ser una excepción. Cuando ocurre todas las semanas ya forma parte del proceso, aunque nadie lo haya diseñado así. Y entonces no basta con pedir que haya más cuidado: hay que descubrir por qué el propio proceso permite que el problema llegue tan lejos.

Que un paso siempre se haya hecho así no significa que todavía tenga sentido.

Los procesos acumulan historia. Una aprobación apareció porque hace años hubo un problema. Una hoja nació porque el programa no ofrecía determinado dato. Una revisión adicional se añadió después de un error. Un correo sigue enviándose porque antes era la única forma de avisar. Un documento se prepara porque alguien lo pidió una vez.

Cada decisión pudo tener sentido cuando nació, pero eso no significa que todas sigan necesitándolo hoy. Por eso, cuando reviso un proceso, hay una pregunta que me interesa especialmente: ¿Para qué existe este paso hoy?

Si nadie puede explicar qué riesgo evita, qué decisión permite tomar o qué valor aporta, quizá no necesitemos hacerlo más rápido. Quizá necesitemos dejar de hacerlo.

Mejorar procesos no es pedir a la gente que trabaje más rápido.

Si una persona tarda diez minutos en completar una tarea, reducirla a ocho puede ser una mejora. Pero si después el trabajo permanece dos días esperando una aprobación, probablemente estamos optimizando la parte equivocada.

La eficiencia de un proceso no depende únicamente de la velocidad con la que se ejecutan sus tareas. También depende de las esperas, los traspasos, las duplicidades, las decisiones, la información que falta y las veces que algo tiene que volver hacia atrás. Por eso una empresa puede mejorar mucho sin que nadie trabaje más deprisa.

A veces basta con eliminar un paso, adelantar una decisión, pedir correctamente la información desde el principio, evitar una transferencia o permitir que dos tareas ocurran sin esperarse innecesariamente. El objetivo no es correr, sino conseguir que el recorrido tenga sentido.

Antes de automatizar un proceso, lo simplifico.

Automatizar puede eliminar muchísimo trabajo manual, pero la tecnología no decide por sí sola si un proceso está bien diseñado. Si existen cinco aprobaciones innecesarias, puedo digitalizar las cinco; si pedimos dos veces la misma información, puedo automatizar la duplicación; y si un documento que nadie utiliza tarda una hora en prepararse, puedo conseguir que se genere en diez segundos.

Todo funcionará más rápido y el proceso seguirá estando mal.

Automatizar un proceso mal diseñado no lo convierte en un buen proceso.

Por eso separo dos decisiones que parecen iguales y no lo son: primero decido cómo debería funcionar el proceso y después decido qué partes merece la pena automatizar, integrar o incorporar al software.

Primero simplifico. Después decido qué merece automatizarse.

Los procesos también necesitan saber qué hacer cuando algo no es normal.

Estandarizar no significa fingir que todos los casos son iguales. Un cliente puede necesitar una condición especial, un pedido puede llegar incompleto, una incidencia puede requerir una decisión extraordinaria o una operación puede superar un límite que obliga a intervenir a Dirección.

Las excepciones existen. El problema es que muchas empresas diseñan únicamente el camino ideal y dejan que todo lo demás se resuelva mediante correos, llamadas, memoria y buena voluntad.

Entonces la excepción no está realmente dentro del proceso, sino alrededor. Un buen diseño distingue claramente el proceso normal y la excepción, y sabe en qué momento el sistema puede continuar solo y cuándo necesita reclamar criterio humano.

Un buen proceso deja claro quién decide, con qué información y qué sucede después.

Muchos problemas operativos no aparecen porque falte esfuerzo, sino porque nadie tiene completamente claro dónde termina una responsabilidad y empieza la siguiente. Una persona cree que otra debe avisar, un departamento espera que el anterior compruebe un dato, una aprobación existe pero no está claro qué criterio debe utilizar o el proceso se detiene porque todos saben hacer su trabajo, pero nadie sabe exactamente quién debe provocar el siguiente paso.

Cuando una decisión forma parte del proceso, debería quedar claro quién decide, qué información necesita para hacerlo y qué ocurre inmediatamente después. Eso reduce consultas, interpretaciones y dependencias personales.

Además, permite que el software acompañe el proceso de verdad, porque ya no tiene que representar una sucesión de tareas aisladas: puede representar cómo trabaja la empresa.

El mejor proceso no es el que tiene menos pasos. Es el que tiene los pasos necesarios.

Eliminar por eliminar tampoco es mejorar. Hay comprobaciones que protegen a la empresa, decisiones que necesitan separación de funciones y controles que existen porque el riesgo de equivocarse justifica perfectamente el esfuerzo.

La simplicidad no consiste en quitar todo, sino en distinguir entre lo necesario y lo que permanece únicamente porque nadie se ha parado a cuestionarlo.

Un proceso bien diseñado puede tener dos pasos o veinte. Lo importante es que cada uno tenga una razón para existir y que el conjunto consiga el resultado con la menor fricción necesaria, ni más ni menos.

¿Por dónde empezaría a mejorar los procesos de una empresa?

No intentaría revisar toda la empresa a la vez. Empezaría por un proceso concreto que genere retrasos, errores, quejas, trabajo manual, persecuciones constantes o una dependencia excesiva de determinadas personas.

Seguiría ese proceso desde el principio hasta el final tal y como ocurre hoy, no como aparece en el procedimiento. Miraría dónde espera, dónde vuelve hacia atrás, dónde cambia de responsable, dónde alguien introduce información que ya existía, dónde aparece una aprobación y qué ocurre cada vez que el caso normal deja de ser normal.

Después preguntaría por qué existe cada paso. Algunos permanecerán exactamente como están; otros podrán simplificarse, combinarse, cambiar de orden o desaparecer. Y solo entonces tendrá sentido decidir qué debe hacer una persona, qué puede resolver una regla, qué merece automatizarse y qué debería formar parte del software.

No busco el proceso más bonito sobre un diagrama. Busco el proceso que menos obliga a la empresa a esperar, perseguir, corregir y rehacer para conseguir el resultado que necesita.