Minería de procesos: el mapa real, no el que dibujó calidad

La minería de procesos parte de una idea incómoda: el proceso que está documentado en el manual de calidad y el proceso que ocurre de verdad cada día no son el mismo. El primero tiene seis pasos ordenados. El segundo tiene esos seis, más cuatro atajos que inventó alguien en 2019, dos devoluciones al paso anterior, un correo a un proveedor que no aparece en ningún diagrama y un Excel paralelo que mantiene una persona que lleva ocho años en la empresa. Cuando una organización intenta automatizar sin ver esa segunda versión, automatiza una ficción.

Esto es lo que resuelve la minería de procesos: reconstruir el flujo real a partir de las huellas que el propio trabajo deja en los sistemas. Cada vez que alguien crea un pedido en el ERP, lo aprueba, lo modifica o lo cierra, queda un registro con un identificador, una actividad y una marca de tiempo. Con suficientes registros se puede dibujar el proceso tal cual sucede, con todas sus variantes, sus esperas y sus bucles.

Esta guía explica qué datos hacen falta de verdad, qué cosas encuentra esta técnica que no encuentra una entrevista, cuánto cuesta montarlo y —lo más importante para una empresa mediana— en qué casos no compensa y es mejor sentarse una mañana a mirar cómo trabaja el equipo.

¿Qué es la minería de procesos y en qué se diferencia de un diagrama de flujo?

Un diagrama de flujo es una declaración de intenciones: alguien se sentó, preguntó y dibujó cómo debería funcionar el proceso. La minería de procesos es una reconstrucción forense: parte de los datos que han quedado grabados y muestra qué pasó realmente, en qué orden y cuánto tardó cada salto.

La materia prima es un registro de eventos (event log). Es una tabla con tres columnas mínimas:

| Columna | Qué contiene | Ejemplo | |---|---|---| | ID de caso | Lo que identifica una ejecución completa del proceso | Nº de pedido, nº de expediente, nº de factura | | Actividad | El paso que se ejecutó | «Pedido creado», «Aprobado por compras», «Recibido en almacén» | | Marca de tiempo | Cuándo ocurrió ese paso | 2026-03-14 09:41 |

Con eso ya se puede dibujar un proceso. Si además hay una cuarta columna con el recurso (quién o qué sistema ejecutó el paso) y alguna dimensión de negocio (importe, cliente, centro, tipo de producto), el análisis pasa de interesante a accionable: ya no es «hay esperas», es «las esperas se concentran en los pedidos de más de 5.000 € del centro de Valencia».

Las tres preguntas que responde la técnica, en este orden:

• Descubrimiento. ¿Cómo es el proceso real, con todas sus variantes?
• Conformidad. ¿Dónde se desvía lo real de lo que dice el procedimiento o el contrato?
• Mejora. ¿Dónde está el tiempo perdido, el retrabajo y el cuello de botella que más cuesta?

¿Qué encuentra que no encuentra una entrevista?

Las entrevistas son imprescindibles para entender el porqué, pero tienen tres puntos ciegos conocidos. La gente describe el camino feliz, olvida los atajos que ya ha normalizado y nunca es buena estimando tiempos. La minería de procesos es fuerte justo ahí.

El número de variantes. Es el dato que más sorprende en la primera reunión de resultados. Un proceso de compra que en el manual tiene un camino suele tener entre 40 y varios cientos de variantes distintas en los datos. No todas importan: lo normal es que un puñado concentre la mayoría de casos y el resto sea una cola larguísima de excepciones. Esa cola es exactamente lo que hace fracasar una automatización diseñada solo para el camino feliz.

El retrabajo invisible. Bucles del tipo «aprobado → devuelto a revisión → aprobado». Nadie lo reporta como problema porque cada vuelta cuesta diez minutos; en el agregado puede ser el mayor consumo de tiempo del departamento.

La espera frente al trabajo. Esta distinción cambia conversaciones. El tiempo de ciclo de un expediente puede ser de once días, de los cuales el trabajo efectivo son dos horas. Si la dirección cree que el problema es que el equipo es lento, los datos reordenan la discusión: el problema es que el expediente pasa nueve días esperando una firma.

El salto de control. Pedidos que llegan a recepción sin haber pasado por aprobación, descuentos aplicados por encima del límite, pasos ejecutados por el mismo usuario que debía supervisarlos. Esto es análisis de conformidad y suele ser el hallazgo que más interesa a auditoría interna.

Si el proyecto termina con un mapa precioso y ninguna decisión tomada, ha fracasado. El entregable útil no es el diagrama: es la lista corta de qué se cambia, quién lo cambia y cómo se verá en la métrica.

¿Qué datos hacen falta y de dónde se sacan?

Aquí está el 80% del esfuerzo real de un proyecto, y conviene decirlo antes de firmar nada. Extraer el registro de eventos es ingeniería de datos clásica, no magia.

De dónde salen. Los ERP y CRM modernos guardan tablas de histórico o de auditoría que sirven casi directamente. En sistemas más antiguos hay que reconstruir los eventos a partir de campos de fecha dispersos en la tabla principal: `fecha_creacion`, `fecha_aprobacion`, `fecha_envio`. Funciona, pero con una limitación que hay que asumir: si un campo se sobrescribe, se pierde el histórico y las vueltas atrás se vuelven invisibles.

Los problemas que aparecen siempre. Merece la pena anticiparlos porque son los que retrasan el calendario:

• Granularidad desigual. Un sistema registra «Pedido modificado» y otro detalla qué campo cambió. Hay que decidir un nivel común y agrupar.
• Marcas de tiempo con fecha pero sin hora. Si solo hay día, el orden de los pasos dentro de la misma jornada es ambiguo. A veces basta; para analizar esperas cortas, no.
• El caso no es único. Un pedido se parte en tres albaranes y dos facturas. Hay que decidir cuál es la unidad de análisis antes de extraer nada, y es una decisión de negocio, no técnica.
• El trabajo que ocurre fuera del sistema. Si la negociación con el proveedor pasa por correo y teléfono, en el registro aparece como un hueco de cuatro días sin explicación.
• Datos personales. El registro contiene quién hizo qué y cuándo, es decir, datos de empleados. Eso tiene implicaciones de RGPD y de relación laboral que conviene resolver al principio, no cuando alguien del comité de empresa pregunte.

Sobre el volumen: no hace falta todo el histórico. Para un primer análisis suele bastar con entre seis y doce meses de casos cerrados, siempre que incluyan temporada alta y baja. Más datos no mejoran el diagnóstico, solo encarecen la extracción.

¿Cómo se monta el primer análisis, paso a paso?

Un primer caso bien acotado se hace en seis u ocho semanas. Si alguien ofrece un plan de doce meses para «implantar la minería de procesos en la compañía», está vendiendo una licencia, no un diagnóstico.

| Fase | Qué se hace | Duración orientativa | |---|---|---| | 1. Elegir el proceso | Uno solo, con volumen alto, con dolor reconocido y con sistema que registre eventos | 1 semana | | 2. Definir el caso y las actividades | Qué cuenta como una ejecución y qué pasos se nombran; se acuerda con negocio | 1 semana | | 3. Extraer y limpiar | Consulta al origen, unificación de nombres, control de casos incompletos | 2-3 semanas | | 4. Analizar | Variantes, tiempos de espera, retrabajo, conformidad | 1-2 semanas | | 5. Decidir y medir | Lista corta de cambios, dueño y métrica de control | 1 semana |

Dos criterios para elegir el proceso de la fase 1. Primero, que tenga volumen: con 300 casos al año no hay estadística que valga y lo resuelve mejor una conversación. Segundo, que alguien sufra con él hoy; si no hay dolor reconocido, los hallazgos no se convertirán en decisiones. Los candidatos típicos en una empresa mediana son compra a pago, pedido a cobro, alta de cliente, tramitación de siniestros o incidencias y devoluciones.

Y un criterio para la fase 5 que marca la diferencia entre un informe y un proyecto: cada hallazgo debe salir de la sala con un dueño y una métrica. «Reducir la espera de aprobación en pedidos de menos de 1.000 € eliminando el visto bueno doble, responsable compras, se mide con el tiempo medio de aprobación mensual» es accionable. «Optimizar el flujo de aprobación» no lo es.

¿Para qué sirve antes de automatizar?

Esta es la aplicación con retorno más claro y la razón por la que la técnica aparece junto a cualquier conversación de automatización de procesos.

El patrón de fracaso es conocido: se compra una herramienta de automatización, se programa el camino feliz, y al entrar en producción resulta que el camino feliz cubre el 55% de los casos. El 45% restante va a una cola de excepciones que gestiona el mismo equipo de antes, y el ahorro desaparece. Es la misma historia que cuenta cualquiera que haya visto un RPA romperse a los tres meses.

La minería de procesos da tres cosas antes de escribir una línea de código:

• La cobertura real que tendrá la automatización. Si las tres variantes principales son el 78% de los casos, ese es el techo honesto del proyecto, y con ese número se decide si compensa.
• Dónde está el tiempo. A veces el paso que más tarda no es el que se iba a automatizar. Automatizar un paso de dos minutos dentro de un proceso con una espera de seis días no cambia nada.
• Qué excepciones hay que diseñar desde el principio, en lugar de descubrirlas en producción.

También sirve después: si el registro de eventos se mantiene vivo, se puede comparar el proceso antes y después del cambio y comprobar si la mejora ocurrió de verdad. Eso conecta directamente con medir el ROI sin estimaciones de servilleta.

¿Cuándo no compensa?

Decirlo ahorra dinero, así que va completo. Hay cuatro situaciones en las que el análisis no se sostiene.

Volumen bajo. Procesos con pocas decenas de casos al mes. El patrón se ve mejor hablando con las dos personas que los ejecutan.

El proceso no deja rastro. Si la mitad del trabajo ocurre en correo, teléfono y hojas de cálculo locales, el registro de eventos tendrá tantos huecos que el mapa engañará más de lo que aclara. Aquí la secuencia correcta es la inversa: primero llevar el proceso a un sistema, luego minarlo.

Ya se sabe cuál es el problema. Si todo el mundo en la empresa señala el mismo cuello de botella y la solución es evidente, gastar dos meses en demostrarlo con datos es un lujo. Se arregla y, si acaso, se mide después.

No hay nadie con autoridad para cambiar el proceso. Es la causa de abandono más frecuente y no tiene nada que ver con la técnica. Un análisis sin patrocinador acaba en un PDF compartido que nadie abre, igual que pasa con los catálogos de datos sin dueño.

Sobre herramientas: hay plataformas comerciales especializadas, módulos dentro de suites de BI y librerías abiertas. Para un primer diagnóstico, una librería abierta sobre el registro de eventos extraído resuelve el 90% de las preguntas y permite decidir con criterio si la licencia anual compensa. Al revés —comprar la licencia y luego buscar un proceso que justificarla— es como suelen empezar los proyectos que se abandonan al segundo año.

Preguntas frecuentes

¿Qué diferencia hay entre minería de procesos y minería de tareas?

La minería de procesos reconstruye el flujo a partir de los registros que dejan los sistemas de negocio: ERP, CRM, gestor de expedientes. La minería de tareas observa lo que hace el usuario en su propio equipo, clic a clic, para ver el detalle que el sistema no registra. La segunda da más detalle, pero implica monitorizar puestos de trabajo y exige una conversación previa con el equipo y con la representación de los trabajadores.

¿Cuánto cuesta un primer proyecto de minería de procesos?

El grueso del coste no es la herramienta, es extraer y limpiar el registro de eventos. Un primer diagnóstico sobre un proceso acotado se mueve en el rango de un proyecto de datos de seis a ocho semanas. Si el ERP ya guarda tablas de auditoría usables, baja bastante; si hay que reconstruir eventos de sistemas antiguos, sube.

¿Necesito una plataforma comercial para empezar?

No para el primer análisis. Con el registro de eventos extraído y una librería abierta se responden las preguntas de descubrimiento y de tiempos. La plataforma comercial compensa cuando el análisis pasa a ser continuo, con varios procesos vivos y usuarios de negocio consultando por su cuenta.

¿Esto sirve para vigilar a los empleados?

No es su propósito y plantearlo así es la forma más rápida de que el proyecto se bloquee. El análisis se hace sobre el proceso, no sobre personas: la práctica sana es agregar por rol o por equipo en vez de por usuario, documentar la finalidad, informar a la plantilla y limitar el acceso al detalle individual.

Si tienes un proceso que todo el mundo sabe que va lento pero nadie puede señalar dónde, la minería de procesos sirve para dejar de discutir por intuición. En la auditoría miramos primero qué registran tus sistemas, porque de ahí sale si el análisis es viable o si antes toca ordenar el dato; y si prefieres contarlo de viva voz, hablemos media hora y te decimos si tu caso aguanta este enfoque o se resuelve con algo más barato.