Object-centric process mining: por qué el caso único ya no alcanza
EL PROCESS MINING CLÁSICO ASUME QUE CADA EVENTO PERTENECE A UN SOLO CASO. TUS DATOS NO FUNCIONAN ASÍ.
Es la limitación que más proyectos frenó durante una década, y casi nunca se nombra. Se atribuye el fracaso a la calidad de los datos cuando el problema era el modelo con el que se los miraba.
La pregunta que se hace al empezar es cuál es nuestro caso.
La correcta es cuántos objetos distintos participan y dónde se cruzan.
Piensa en un pedido cualquiera:
La orden tiene su ciclo.
Se crea, se aprueba, se cierra. Su reloj corre entre esos dos puntos.
El envío tiene otro.
Puede haber tres envíos para una orden, o uno para varias. Su ciclo no coincide con el de la orden en ningún extremo.
La factura tiene un tercero.
Y suele agrupar líneas de órdenes distintas, con su propia fecha de vencimiento.
Forzarlos a un caso único distorsiona todo.
Si eliges la orden como caso, los eventos del envío se duplican o se pierden. Si eliges la factura, la orden queda partida. No hay elección correcta: todas mienten.
Por eso el mapa salía imposible de leer.
Esos diagramas con cientos de caminos cruzados no reflejaban un proceso caótico. Reflejaban tres procesos aplastados en uno.
El enfoque object-centric abandona ese supuesto: cada objeto conserva su identidad y el modelo muestra dónde se tocan. Y OCEL 2.0 es el estándar que hace ese dato portable entre herramientas.
Van der Aalst lo plantea como pregunta: cómo vas a aplicar IA sin estructurar primero el problema.
Durante años pensé que el problema era el registro. Era el supuesto.
¿Cuántos objetos distintos participan en tu proceso principal?
- ProcessMining
- OCEL
- GestiónDeProcesos
- Datos
- BPM
El carrusel completo
7 láminas. Toca cualquiera para verla en grande.
