Estos dos términos se usan como si fueran lo mismo. No lo son. Hacen cosas diferentes, responden preguntas diferentes, y elegir el incorrecto primero va a costar tiempo.

Qué hace realmente el process mining

Process mining toma los logs de eventos de los sistemas de software — ERP, CRM, herramientas de ticketing, bases de datos — y reconstruye el flujo de trabajo que ocurrió. Cada vez que un registro pasó de estado A a estado B, cada vez que un usuario hizo clic en "aprobar," cada vez que el sistema generó una factura. Lee timestamps, IDs de usuario y cambios de estado para armar un mapa de cómo fluye el trabajo a través de los sistemas digitales.

El resultado es potente. Se obtienen tiempos de ciclo exactos, identificación de cuellos de botella, análisis de variantes (¿cuántos caminos diferentes toma el mismo proceso en la realidad?), y verificación de cumplimiento. Para un proceso de compra-a-pago en SAP, por ejemplo, el process mining puede mostrar que el 34% de las órdenes de compra pasan por un desvío a un proveedor no aprobado que agrega 6 días al ciclo.

Eso es útil. Pero tiene un punto ciego del tamaño de un edificio.

La brecha del 40-60%

El process mining solo ve lo que pasa dentro del software. Se pierde todo lo demás.

La llamada telefónica donde un gerente aprueba verbalmente una orden urgente. El papelito pegado en el monitor de alguien que dice "consultar con Jorge antes de liberar órdenes de más de $50K." La cadena de emails donde tres personas negocian una excepción al proceso estándar. La planilla que alguien mantiene en su escritorio para rastrear cosas que el sistema principal no puede manejar. La reunión donde el equipo decide saltarse un paso porque la fecha límite es mañana.

En la mayoría de las operaciones, entre el 40% y el 60% del proceso real ocurre fuera de los sistemas rastreados. El process mining no ve nada de eso. El mapa que produce es preciso para lo que cubre — pero lo que cubre es incompleto. Si se usa ese mapa como base para automatizar, se va a automatizar la parte digital y romper la parte humana. La gente va a encontrar nuevos parches. Los problemas se van a multiplicar.

Qué hace diferente el descubrimiento de procesos

El descubrimiento de procesos es trabajo estructurado con personas. Entrevistas con los operadores que hacen el proceso todos los días. Sesiones de observación donde se los mira trabajar. Talleres donde el equipo mapea su propio flujo en un pizarrón, discutiendo los casos borde hasta que todos coinciden en lo que realmente pasa.

Es más lento. Un proyecto de process mining puede producir mapas iniciales en 2-3 semanas una vez que se tiene acceso a los datos. El descubrimiento de procesos toma 3 a 6 semanas porque requiere coordinar tiempo con las personas correctas, hacer entrevistas, sintetizar relatos contradictorios y validar el mapa con el equipo.

También depende mucho de la calidad de las entrevistas. Preguntas malas producen respuestas malas. Si quien entrevista no entiende de operaciones, va a documentar el proceso oficial (lo que la gerencia cree que pasa) en vez del proceso real (lo que realmente pasa). Este es el riesgo principal — y por eso el descubrimiento de procesos bien hecho requiere operadores experimentados, no solo analistas con planillas.

Pero cuando se hace bien, se obtiene algo que el process mining nunca puede dar: la imagen completa. Cada parche, cada excepción, cada decisión que pasa en la cabeza de alguien, cada pieza de conocimiento tribal que mantiene la operación funcionando.

La respuesta suele ser ambos

Hacer descubrimiento primero. Hablar con la gente. Mapear el proceso real, incluyendo todo lo que pasa fuera de los sistemas. Entender por qué existen los parches — generalmente están cubriendo algo que el sistema no puede hacer.

Después hacer process mining para validar y cuantificar. El mapa de descubrimiento dice que "la mayoría de las órdenes pasan por un paso extra de aprobación." Los datos de mining dicen que exactamente el 41% de las órdenes pasan por ese paso, que agrega un promedio de 2.3 días, y que ocurre un 68% más seguido en órdenes de la Región 3. Ahora se tiene el contexto y los datos. Se sabe qué arreglar y se puede medir el impacto.

Ir al revés — mining primero, descubrimiento después — también funciona, pero es más riesgoso. Se va a armar un mapa parcial y después hay que reconciliarlo con la realidad. Los equipos tienden a anclarse en la salida del mining y tratar las partes humanas como "excepciones" en vez de flujo central. Eso es un error.

Las empresas que hacen esto bien tratan el entendimiento de procesos como un prerrequisito, no como algo opcional. Pasan 3 a 6 semanas mapeando antes de gastar un peso en tecnología. Se siente lento. Pero es la diferencia entre construir automatización que funciona en el primer despliegue y construir automatización que se rompe en producción porque nadie sabía de la llamada a Jorge.