Cuando hablamos de la ejecución de procesos dentro de una organización, surgen preguntas recurrentes como:

• ¿Cómo puedo saber en qué punto está esto?
• ¿Cómo puedo asegurar que, especialmente en procesos manuales, se trabaja realmente como hemos definido y documentado?
• ¿A quién le corresponde actuar ahora?
• ¿Por qué lleva tantos días bloqueada una ejecución?
• ¿Qué necesita para avanzar?
• ¿Por qué se producen tantos errores sin saber exactamente dónde se originan?

Estas preguntas suelen llevar a un uso excesivo de correos electrónicos, llamadas y plataformas como Teams, con el típico “déjame que pregunte”.

Y ahí está el problema de partida: podemos tener procesos perfectamente documentados e incluso correctamente modelados y, aun así, no ser capaces de controlar su ejecución real.

Porque una cosa es saber cómo debe funcionar un proceso y otra muy distinta saber qué está ocurriendo mientras se ejecuta, comprobar si realmente se está siguiendo lo definido y poder actuar cuando algo se desvía.

En otras entradas de este blog ya he hablado de dos problemas directamente relacionados: transformar sin comprender y acabar, simplemente, digitalizando el caos, o documentar y validar flujos para que, después, terminen quedándose en un cajón.

En esta ocasión quiero avanzar un paso más. Supongamos que ya hemos entendido el proceso, sabemos cómo queremos que funcione e incluso lo hemos implantado. La pregunta que surge ahora es otra: ¿somos capaces de saber qué está ocurriendo mientras el proceso se ejecuta y de actuar cuando no avanza como debería?

Ese es el verdadero foco de este artículo: pasar del proceso que conocemos y diseñamos al proceso cuya ejecución somos capaces de gobernar.

1. Entiende y haz visible el AS-IS real

Identificar que tenemos un problema no significa que entendamos por qué ocurre. Por eso siempre me gusta empezar entendiendo cómo funciona realmente el proceso: actividades, responsables, handoffs (transferencias o transiciones), decisiones, excepciones, sistemas, datos, tiempos y esperas.

Especialmente en organizaciones con poca madurez en gestión por procesos, aun a riesgo de que me consideren “el pintor de la organización”, yo sigo recomendando dibujarlo. Porque muchas veces, hasta que no ponemos el proceso delante de todos, no somos realmente conscientes de cómo estamos trabajando.

Poner el proceso delante de todos suele hacer visibles cosas que permanecían ocultas: diferentes formas de trabajar, responsabilidades interpretadas de manera distinta, pasos informales, dependencias entre áreas o actividades que “siempre se han hecho así”.

El objetivo no es dibujar un BPMN perfecto. Es conseguir que todos veamos y entendamos el mismo proceso.

Y aquí no quiero volver a desarrollar algo que ya traté ampliamente en “Transformar sin comprender el qué… puede significar digitalizar el caos”: comprender y hacer visible el proceso no es burocracia previa a la transformación, sino una forma de evitar transformar aquello que realmente no conocemos. 

Hoy tenemos además otras posibilidades. Si el proceso está suficientemente digitalizado y disponemos de buenos registros de eventos, Process Mining puede ayudarnos a reconstruir buena parte de lo que realmente está ocurriendo. Y eso puede reducir mucho el esfuerzo de levantamiento manual.

Pero ¿qué pasa cuando esos datos no existen, la madurez es baja o ni siquiera compartimos una misma visión del proceso? Ahí, para mí, hacer explícito el AS-IS sigue aportando muchísimo valor.

Y si pensamos que el proceso futuro puede tener sentido orquestarlo en su ejecución, conviene aprovechar el análisis del AS-IS para identificar también aquello que después tendremos que ser capaces de coordinar: eventos de inicio y fin, tareas y responsables, sistemas implicados, datos utilizados, pasos entre funciones, puntos de integración, excepciones y la forma en que identificamos y seguimos cada ejecución.

No estamos orquestando todavía. Estamos entendiendo qué tendremos que ser capaces de coordinar cuando pasemos del proceso actual a una nueva forma de ejecutarlo.

2. Diseña el TO-BE… y las capacidades que necesita

Una vez entendida la realidad, podemos decidir cómo queremos trabajar:

• Quién debe hacer qué.
• Cuándo.
• Con qué información.
• En cuánto tiempo.
• Qué decisiones existen.
• Qué controles necesitamos.
• Qué excepciones debemos contemplar.

Pero no diseñaría únicamente el nuevo flujo. También me haría una pregunta fundamental: ¿tenemos realmente las capacidades necesarias para hacerlo realidad? Personas y competencias, datos, tecnología, integraciones, ownership, gobierno, cultura y disciplina de proceso forman también parte de la respuesta.

Porque podemos diseñar un TO-BE magnífico que nuestra organización todavía no sea capaz de ejecutar, por lo que, junto al diseño, necesitamos identificar también las brechas de capacidad que tendremos que cerrar para hacerlo realidad.

Si además queremos orquestar su ejecución, es aquí donde tendremos que decidir cómo queremos que funcione esa coordinación: qué tareas serán humanas y cuáles podrán ejecutarse mediante sistemas o automatizaciones, qué eventos harán avanzar el flujo, qué reglas y SLA aplicarán, qué información deberá acompañar a cada ejecución, qué integraciones serán necesarias y cómo se gestionarán las excepciones.

La orquestación, por tanto, no empieza al instalar una herramienta: empieza mucho antes, entendiendo el proceso actual y diseñando el proceso futuro para que pueda ser ejecutado, coordinado y controlado.

3. Implementa el TO-BE y consolida la base

Que algo esté diseñado no significa que esté implantado. Aquí dejamos el dibujo y empezamos a cambiar la realidad.

Implementar puede significar modificar responsabilidades, desarrollar tecnología, integrar sistemas, mejorar datos, implantar controles, formar personas, redefinir procedimientos o cambiar determinadas formas de trabajar.

La adopción es clave, porque un proceso no está realmente implantado hasta que las personas trabajan conforme al nuevo modelo y las capacidades necesarias permiten sostenerlo.

Este es precisamente el punto en el que quiero continuar la reflexión que planteaba en “Procesos en acción: cómo el analista de negocio convierte “flujos” en compromiso”. Allí defendía que el dibujo es una herramienta y no un fin, y que un proceso solo cobra vida cuando pasa del documento a la práctica compartida. Aquí damos el siguiente paso: una vez convertido en práctica, necesitamos ser capaces de seguir y gobernar su ejecución. 

Y si hemos decidido orquestar su ejecución, es también aquí donde habilitamos lo necesario para hacerlo posible: conexiones entre sistemas, datos disponibles, reglas configuradas, gestión de tareas, eventos, alertas, tratamiento de excepciones y trazabilidad.

Es decir, cerramos las brechas que separaban el TO-BE diseñado del TO-BE realmente ejecutable.

4. Orquesta la ejecución

Aquí ocurre otro cambio importante. El proceso deja de ser únicamente una representación de cómo debería funcionar y empezamos a coordinar su ejecución, conectando personas, sistemas, reglas, eventos, tiempos y excepciones dentro de un mismo flujo.

Orquestar no significa automatizarlo todo. Pueden seguir existiendo muchas actividades humanas y, cada vez más, otras en las que intervienen la IA o agentes capaces de interpretar el contexto, utilizar herramientas o decidir dinámicamente cuál debe ser el siguiente paso.

Esto permite combinar dentro de un mismo proceso partes claramente predefinidas, en las que sabemos exactamente qué debe ocurrir, con otras más dinámicas, donde la IA puede aportar capacidad de interpretación, decisión o adaptación. Es precisamente el enfoque que ya están incorporando algunas plataformas de orquestación, integrando agentes junto a tareas humanas, reglas de negocio e integraciones con sistemas dentro de procesos end-to-end.

Pero esto no cambia el objetivo de la orquestación. Significa conseguir que cada ejecución mantenga su contexto y que esté claro:

• Qué debe ocurrir.
• Quién o qué debe actuar.
• Cuándo.
• Qué sucede después.
• Qué hacer cuando algo no ocurre como estaba previsto.

El propio flujo pasa a ayudarnos a coordinar el trabajo, reduciendo la dependencia de que alguien tenga que recordar enviar un correo, perseguir una aprobación o avisar manualmente al siguiente participante.

La incorporación de IA tampoco elimina la necesidad de control. Más bien al contrario. Si introducimos decisiones más dinámicas o damos cierto grado de autonomía, necesitamos saber qué está ocurriendo, establecer límites, mantener la trazabilidad y tener claro cuándo debe intervenir una persona.

Aquí aparece, para mí, el verdadero salto respecto a simplemente tener un proceso definido: no solo sabemos cómo debería funcionar, empezamos a gobernar cómo está funcionando cada una de sus ejecuciones.

5. Haz visible lo que está ocurriendo

Con el proceso ya implementado y su ejecución convenientemente trazada, podemos empezar a responder rápidamente:

• ¿Dónde está cada ejecución?.
• ¿Quién tiene que actuar ahora?.
• ¿Cuánto tiempo lleva esperando?.
• ¿Qué paso viene después?.
• ¿Está dentro del SLA?.

Aquí es cuando pasamos del “déjame que pregunte” al “lo estoy viendo”.

Esta visibilidad no es un simple detalle, sino una condición esencial para gestionar la ejecución del proceso y poder actuar sobre ella.

6. Controla las desviaciones mientras ocurren

La visibilidad nos permite saber qué está pasando y detectar situaciones que requieren nuestra atención:

• Esperas.
• Reprocesos.
• Incumplimientos de SLA.
• Cuellos de botella.
• Excepciones recurrentes.

El control nos permite actuar sobre ello, y hacerlo antes de descubrir el problema al final del proceso.

Podemos alertar, escalar, reasignar, intervenir o analizar qué está impidiendo que una ejecución avance.

Esto cambia especialmente la forma de gestionar procesos muy manuales, donde buena parte del seguimiento suele depender de las propias personas que participan en ellos.

Porque controlar un proceso no debe significar explicar a final de mes por qué algo salió mal. Debe permitirnos detectar que se está desviando mientras todavía podemos hacer algo al respecto.

7. Mide, aprende y mejora continuamente

Con trazabilidad y datos de ejecución podemos comparar lo previsto con lo ocurrido, medir tiempos, detectar patrones y entender dónde debemos mejorar.

Pero aquí no analizaría únicamente el proceso, también volvería a mirar las capacidades que lo soportan.

Porque detrás de una tarea que tarda demasiado puede haber un problema de datos, tecnología, competencias, capacidad del equipo, ownership, reglas o gobierno.

Por eso, la mejora continua no consiste únicamente en preguntarnos “¿qué actividad puedo hacer más rápido?”, sino también “¿qué capacidad está limitando el rendimiento del proceso y necesito reforzar?”.

Aquí Process Mining puede ayudarnos a contrastar el comportamiento real, descubrir variantes, desviaciones y cuellos de botella cuando disponemos de datos de ejecución adecuados.

Y lo aprendido puede llevarnos nuevamente a revisar nuestro TO-BE, nuestras capacidades o incluso la propia forma en la que estamos orquestando el proceso.

Por eso, no estamos ante una secuencia que recorremos una sola vez, sino ante un ciclo de gestión y mejora que se retroalimenta con lo que aprendemos durante la ejecución.

8. Entonces podemos hablar de un proceso bajo control

Un proceso no está bajo control simplemente porque esté dibujado, porque exista un procedimiento que lo describa o porque dispongamos de un dashboard.

Podemos hablar realmente de un proceso bajo control cuando sabemos cómo debería funcionar, cómo está funcionando en realidad, dónde se está desviando y qué debemos hacer cuando ambas cosas no coinciden.

Tenemos definición, ejecución, trazabilidad, capacidad de intervención y aprendizaje. Algo muy diferente de simplemente “tener procesos”.

Aquí está, para mí, la diferencia fundamental respecto a las reflexiones de los artículos anteriores: comprender y modelar el proceso es necesario, y conseguir que se adopte también. Pero podemos ir un paso más allá y ser capaces de gobernar su ejecución mientras está ocurriendo.

9. Y solo entonces tiene sentido acelerar

Llegados a este punto, podemos empezar a plantearnos cómo acelerar el proceso apoyándonos en distintas capacidades y tecnologías: automatización, BPMS, RPA, Process Mining o inteligencia artificial. Y, cada vez más, también podemos incorporar agentes y modelos de orquestación agéntica capaces de participar en la ejecución y coordinación del proceso.

No todas estas capacidades serán necesarias en todos los procesos, ni todos requerirán el mismo nivel de automatización, orquestación o autonomía. Su verdadero valor dependerá de que las apliquemos allí donde tengan sentido y sobre una base que conocemos, gobernamos y somos capaces de medir.

La evolución hacia procesos más dinámicos y agénticos no invalida este recorrido. Probablemente lo hace todavía más necesario. Hoy podemos incorporar agentes capaces de interpretar información, tomar determinadas decisiones y colaborar con personas, sistemas u otros agentes. Pero esa mayor autonomía nos obliga también a saber qué hacen, establecer límites, mantener la trazabilidad y gobernar su comportamiento dentro del proceso.

Y esto ya está ocurriendo: las soluciones actuales de orquestación agéntica están incorporando precisamente capacidades de gobierno, observabilidad, políticas y control sobre los agentes.

Cuanto mayor sea la autonomía que introduzcamos en la ejecución, mayor será también nuestra necesidad de mantenerla bajo control.

Aquí sí enlazo deliberadamente con otra idea que ya desarrollé en “Transformar sin comprender el qué… puede significar digitalizar el caos”: la tecnología solo amplifica aquello sobre lo que la aplicamos.

Pero ahora añadiría algo a aquella reflexión: no basta con comprender antes de acelerar. Si queremos procesos verdaderamente gestionables, también necesitamos ser capaces de observar, coordinar y controlar su ejecución.

Porque la tecnología puede acelerar un buen proceso. Pero también puede acelerar uno malo.

Automatizar el desorden no elimina el desorden. Lo escala.

Y ahora podemos añadir un nuevo riesgo: dar autonomía al desorden tampoco lo soluciona.

Del proceso que conocemos al proceso que controlamos

Para mí, este recorrido tiene sentido en este orden:

No debemos interpretar este recorrido como una línea rígida que recorremos una sola vez. Lo que aprendemos al ejecutar, controlar y medir vuelve a alimentar el diseño, las capacidades y la forma en la que coordinamos la ejecución.

Gestionar procesos no consiste en dibujarlos una vez, sino en entenderlos, diseñarlos, hacerlos realidad, ejecutarlos, controlarlos y seguir mejorándolos.

Y quizá la evolución que intento reflejar a través de estas tres entradas pueda resumirse así: primero, comprender el proceso; después, conseguir que deje de ser un dibujo y se convierta en una forma real de trabajar; y, finalmente, ser capaces de gobernar su ejecución.

Y la pregunta final sigue siendo muy sencilla:

Si alguien te preguntara ahora mismo en qué punto está una ejecución concreta de uno de tus procesos, por qué no avanza, quién tiene que actuar y qué debe ocurrir después… ¿podrías responder en segundos?