Process mining: saber qué automatizar antes de automatizar

Process mining reconstruye cómo se ejecuta realmente un proceso a partir de los registros que ya dejan sus sistemas. En lugar de preguntarle a la gente cómo trabaja, observa lo que ocurrió: cada paso, su duración y sus desvíos. Sirve para decidir qué automatizar con evidencia en vez de con intuición.

A continuación: qué necesita para empezar, en qué se diferencia de un levantamiento tradicional, qué suele encontrar y cuándo no vale la pena.

La conversación sobre automatización casi siempre empieza por el final: alguien propone un proceso candidato y el debate pasa a la herramienta. El problema es que ese candidato suele elegirse por visibilidad —el que más se queja, el que está más cerca del comité— y no por costo real.

Process mining invierte el orden. Antes de proponer nada, reconstruye el proceso tal como sucede a partir de la huella que dejan los sistemas: qué pasó, en qué orden, cuánto tardó y cuántas veces hubo que repetirlo.

Qué necesita para empezar

Menos de lo que la gente supone. Hace falta un registro con tres campos: un identificador de caso, una actividad y una marca de tiempo. Con eso ya se puede reconstruir el flujo. La mayoría de los sistemas de gestión, tickets y ERP los produce sin que nadie lo haya pedido.

Lo que sí exige atención es la calidad de esos registros. Si la marca de tiempo se escribe cuando alguien cierra el caso y no cuando ocurre el paso, el análisis mide el momento de la digitación, no el del trabajo. Esa distinción define si el resultado es útil o decorativo.

En qué se diferencia de un levantamiento tradicional

Un levantamiento por entrevistas produce el proceso que la organización cree tener. Es una fuente legítima y captura intención, reglas y excepciones conocidas. Pero describe el camino principal, porque es el que la gente recuerda.

Process mining produce el proceso que la organización ejecuta, incluidas las variantes que nadie documentó. Es habitual encontrar que el camino previsto explica la mitad de los casos y el resto se reparte entre decenas de recorridos distintos. Esa dispersión, medida, es el mejor argumento para rediseñar antes de automatizar.

Las dos técnicas se complementan: los datos dicen qué ocurre, las entrevistas dicen por qué.

Qué suele encontrar

Tres hallazgos se repiten con una frecuencia que ya no sorprende. El primero son los reprocesos: pasos que se ejecutan más de una vez sobre el mismo caso, casi siempre por información incompleta aguas arriba. Se ven de inmediato y suelen ser el ahorro más rápido.

El segundo son las esperas. Cuando se mide el tiempo entre actividades en lugar del tiempo de las actividades, el diagnóstico cambia: el proceso no es lento porque el trabajo tarde, sino porque el caso pasa días esperando a que alguien lo tome.

El tercero son los caminos excepcionales que dejaron de ser excepción. Una ruta creada para un caso raro que hoy explica una porción grande del volumen, sin control y sin dueño.

Cuándo no vale la pena

Cuando el proceso tiene poco volumen, la respuesta se obtiene mirando veinte casos a mano. Cuando los registros no llevan marca de tiempo confiable, el análisis heredará ese defecto. Y cuando ya se sabe qué hay que arreglar y el obstáculo es la decisión y no el diagnóstico, medir otra vez solo aplaza el trabajo.

También conviene decirlo al revés: en operaciones grandes, con varios sistemas y volumen alto, es la forma más barata de evitar automatizar lo que no había que automatizar.

Del hallazgo a la decisión

Un mapa de proceso no cambia nada por sí solo. Lo que convierte el análisis en decisión es ponerle costo a cada desvío: cuántas veces al mes ocurre, cuánto tiempo consume y cuánto vale ese tiempo. Un reproceso que aparece en el 40 % de los casos suena grave, y puede no serlo si cuesta dos minutos; una espera que aparece en el 5 % puede ser lo más caro del proceso si detiene el caso una semana.

De esa cuantificación salen tres listas distintas, y conviene no mezclarlas: lo que se automatiza tal como está, lo que primero hay que rediseñar porque automatizarlo consolidaría un error, y lo que se deja quieto porque el volumen no justifica tocarlo. La tercera lista es la que más ahorra, aunque nunca aparezca en una propuesta.

Cómo encaja con el resto

El resultado natural es una lista priorizada de candidatos con su costo medido, que es exactamente lo que entrega un assessment de automatización de procesos. De ahí salen los casos que pasan a automatización y los que primero necesitan rediseño.

El caso de negocio se calcula con costos locales: una hora de trabajo manual ahorrada no vale lo mismo en Bogotá, en Ciudad de México o en una casa matriz europea, y usar la cifra de un caso de estudio extranjero distorsiona la prioridad completa.

Preguntas frecuentes

¿Qué datos necesito para hacer process mining?

Tres campos por evento: un identificador de caso, el nombre de la actividad y una marca de tiempo. La mayoría de los sistemas de gestión, tickets y ERP ya los registra. Lo crítico es que la marca de tiempo corresponda al momento del trabajo y no al de la digitación.

¿Reemplaza a las entrevistas con el equipo?

No. Los datos dicen qué ocurre y con qué frecuencia; las entrevistas dicen por qué y qué reglas hay detrás. Un diagnóstico que use solo una de las dos fuentes queda incompleto.

¿Sirve si el proceso pasa por varios sistemas?

Es donde más aporta. Un proceso contenido en un solo sistema suele entenderse sin ayuda; uno que cruza tres o cuatro es justamente el que nadie ve completo, y el que acumula esperas entre sistemas.

¿Cuánto tarda un análisis de este tipo?

La extracción y limpieza de los registros suele tomar más tiempo que el análisis. Con datos disponibles y confiables, semanas; con datos que hay que reconstruir, el plazo lo define esa reconstrucción, no la técnica.