Todo proyecto de ERP se diseña sobre una ficción bien intencionada: lo que la gente dice que hace. La minería de procesos sustituye esa ficción por evidencia, reconstruyendo a partir de los datos que el sistema actual ya guarda cómo se ejecuta realmente cada proceso. La distancia entre las dos versiones es, casi siempre, la que explica los cambios de alcance, los retrasos y la resistencia al arranque.
La junta donde se documenta un proceso que no existe
La escena se repite en todos los proyectos. Un consultor se sienta con el responsable de compras y le pide que describa cómo se genera una orden. El responsable la describe: se recibe la requisición, se valida el presupuesto, se cotiza con tres proveedores, se autoriza, se emite la orden.
Lo que describió es el proceso como debería ser. Es también el proceso que él ejecuta cuando todo va bien, que es quizá la mitad de las veces. La otra mitad hay una compra urgente que se autorizó por WhatsApp, un proveedor único que nadie cotiza porque es el único que surte esa pieza, una requisición que se saltó porque el director la pidió directamente, y tres órdenes que se modificaron después de emitidas.
Nada de eso aparece en la junta. No porque alguien mienta, sino porque la gente describe su proceso, no sus excepciones. Y las excepciones son justamente donde el ERP se rompe.
Qué es la minería de procesos, en una frase
Es reconstruir cómo se ejecutó realmente un proceso a partir del rastro que dejó en los sistemas. Cada vez que un documento cambia de estado —una orden se crea, se aprueba, se modifica, se recibe— el sistema guarda quién lo hizo y cuándo. Con esos tres datos, caso, actividad y momento, se puede dibujar el proceso tal como ocurrió, no como se cuenta.
El resultado no es un diagrama bonito. Es un mapa con números: cuántas formas distintas hay de ejecutar el mismo proceso, cuánto tarda cada una, dónde se detiene el trabajo, qué porcentaje de casos se retrabaja y cuáles se saltan pasos que se suponían obligatorios.
Los tres momentos donde cambia el resultado
Antes: el alcance se define sobre hechos. Es el uso de mayor impacto y el menos común. Si antes de definir el alcance usted sabe que su ciclo de compra tiene once variantes y que tres de ellas concentran el ochenta por ciento del volumen, sabe exactamente qué debe soportar el sistema desde el primer día y qué puede esperar. Sin ese dato, el alcance se define sobre lo que se dijo en las juntas, y las excepciones aparecen una por una durante las pruebas, cada una convertida en una solicitud de cambio.
Durante: se valida que el diseño refleje la operación. A la mitad del proyecto, cuando el equipo ya configuró el sistema, la pregunta útil no es si está bien configurado, sino si eso se parece a cómo trabajan. Comparar el proceso diseñado contra el proceso observado responde eso con evidencia, no con opiniones.
Después: se puede demostrar que sirvió. Esta es la que más falta hace y la que casi nadie hace. Si se midió cómo operaba antes, seis meses después se puede decir con números qué cambió: cuánto bajó el tiempo entre pedido y entrega, cuánto se redujo el retrabajo, cuántas variantes desaparecieron. Si nadie midió el antes, la conversación sobre el retorno se vuelve una discusión de percepciones, y normalmente la gana el que estaba en contra del proyecto.
Por qué esto explica tantos proyectos que se salen de control
Cuando una implementación se descarrila, el diagnóstico habitual apunta al proveedor, al software o al equipo. En nuestra experiencia, el origen suele estar antes: el proyecto se diseñó para un proceso que no era el real.
Las consecuencias encadenan siempre igual. El alcance se queda corto porque no contempló las excepciones. Cada excepción descubierta se vuelve una solicitud de cambio, y cada cambio empuja la fecha. Cuando el sistema por fin arranca, obliga a la gente a trabajar de una forma que no es la suya, y entonces ocurre lo peor que le puede pasar a un ERP: la operación vuelve a Excel para lo que el sistema no le resuelve, y a partir de ahí el sistema deja de reflejar la realidad de la empresa.
Nada de eso es un problema de software. Es un problema de haber diseñado sobre una descripción en lugar de sobre evidencia.
El caso particular de la empresa mexicana mediana
Aquí conviene ser honesto, porque la mayoría de lo que se escribe sobre minería de procesos está pensado para corporativos con millones de transacciones y equipos de datos dedicados.
En una empresa mediana el escenario es otro. A veces hay un ERP con años de historia y un rastro utilizable; otras veces la operación vive en Excel, correo y conocimiento de las personas, y no hay nada que minar. Por eso el primer paso serio de cualquier trabajo de este tipo no es analizar: es verificar que exista con qué medir. Revisar si el sistema actual guarda el rastro de cambios, si las fechas son confiables, si los documentos se pueden seguir de principio a fin.
Ese paso es corto y barato, y si el resultado es que no hay datos suficientes, ahorra un proyecto entero mal planteado. Cuando ese es el caso, el camino correcto no es minería sino levantamiento de procesos por departamento, con entrevistas y observación, y con la disciplina añadida de dejar definido desde el inicio qué se va a poder medir después. No es lo mismo y no conviene venderlo con el mismo nombre.
Qué se necesita para que esto funcione
Tres datos, y no son sofisticados: un identificador del caso —el número de orden, el folio del pedido—, la actividad que ocurrió, y la marca de tiempo. Con eso se reconstruye el flujo.
La buena noticia para quien ya opera con un sistema moderno es que ese rastro suele existir de fábrica. Odoo, por ejemplo, registra los cambios de estado de sus documentos sin que nadie lo configure. Eso significa que la preparación de datos que en otras plataformas toma semanas, ahí puede resolverse mucho antes.
Las preguntas que conviene hacerle a su proveedor
Si está por arrancar un proyecto, hay cuatro preguntas que ordenan la conversación: cómo va a documentar el proceso actual y si lo va a hacer solo con entrevistas; qué va a hacer con las excepciones que aparezcan después de firmado el alcance; cómo vamos a saber, seis meses después del arranque, si el proyecto sirvió; y qué indicadores se van a medir antes de tocar nada.
Un proveedor que no tenga respuesta para la tercera y la cuarta le está diciendo, sin decirlo, que el éxito del proyecto se va a evaluar por sensación.
Preguntas frecuentes
¿Qué es la minería de procesos aplicada a un ERP?
Es reconstruir cómo se ejecutan realmente los procesos de una empresa a partir del rastro que dejan en sus sistemas, para diseñar la implementación sobre evidencia en lugar de sobre descripciones, y para poder medir el cambio después del arranque.
¿Sirve si mi empresa todavía no tiene un ERP?
No en su forma estricta, porque sin sistema no hay datos que analizar. En ese caso el trabajo equivalente es un levantamiento de procesos por departamento que además deje definido qué indicadores se van a medir cuando el sistema entre en operación.
¿Cuánto tiempo toma un análisis de este tipo?
Un diagnóstico acotado a uno o dos procesos con impacto claro se mide en semanas, no en meses. Antes conviene una verificación corta de disponibilidad de datos, de unos días, para confirmar que el análisis es viable.
¿Para qué sirve medir antes de implementar si de todos modos voy a cambiar de sistema?
Precisamente por eso. La medición previa es la única forma de demostrar después qué mejoró. Sin ella, el retorno del proyecto queda sujeto a la opinión de cada quien.
Si está evaluando un proyecto y quiere entender cómo definimos el alcance antes de poner un número, en la página de implementación de Odoo en México lo explicamos. Y si lo que tiene es una implementación que no terminó de arrancar, escribimos aparte sobre qué hacer cuando un proyecto de Odoo se sale de control y sobre cómo calcular el costo real de un ERP.