Process Mining y Process Conformance

En el post Process Discovery: Métodos y ejemplo práctico ya analizamos esta popular técnica para obtener un modelo de un proceso a partir de logs del sistema original.

No obstante, es posible hacer mucho más con esos logs de los procesos. Por ejemplo, podemos combinar lo que se hizo previamente y evaluarlo contra la realidad. O, incluso, generar nosotros el modelo ya sea mediante conocimiento experto o siguiendo unos pasos específicos para ello.

¿Qué es Process Conformance?

Para comprobar cómo un modelo se ajusta a la realidad, existe una disciplina conocida como Process Conformance o Conformidad del Proceso. Dicha especialidad se encarga de obtener varias métricas que permiten evaluar si el modelo es o no apropiado.

Ejemplo práctico de Process Conformance

A continuación, realizaremos un caso práctico para conocer cómo funciona este concepto. Para ello, el modelo de ejemplo sobre el que haremos las pruebas de conformidad del proceso es una representación de un sistema de pagos.

En dicho sistema, el cliente empieza registrando la orden, después se comprueba su crédito y se verifica o no el riesgo de pago. Posteriormente, se evalúa la orden, se aprueba o se rechaza y, al final, se le notifica al cliente la decisión tomada.

Para evaluar el modelo generamos 26 trazas diferentes. Cada una de ellas, además, pertenece a una de las siguientes 6 categorías:

• Completamente conforme al modelo con Assess Risk.
• Conforme al modelo pero sin Assess Risk.
• Una o más actividades han sido saltadas.
• Actividades fuera de secuencia.
• Actividades extra.
• Acaba antes de llegar a la última tarea (incompleto).

Seguidamente, evaluaremos las trazas con dos metodologías distintas. Por un lado, mediante Token Replay y, por otro, con Alignment o Alineamiento. Ambas técnicas permiten conocer la cercanía de nuestro modelo con respecto a la realidad observada, pero usan diferentes planteamientos.

Metodología Token Replay

En primer lugar, haremos uso de Token Replay para evaluar el modelo respecto a las trazas. Esta técnica es la más obvia para valorar un modelo y, básicamente, simula cómo la traza observada se movería por el modelo generado.

Primero, empezamos con una traza y la replicamos en el modelo que hemos generado. Por ejemplo:

Estado inicial:
Traza: Register -> Check Credit -> Assess Risk -> Evaluate -> Approve -> Notify
Tokens producidos: Ninguno
Paso 1.
Inicio de evaluación, traza empieza por "Register", creamos "Register".
Traza: Register -> Check Credit -> Assess Risk -> Evaluate -> Approve -> Notify
Tokens producidos: 1
Paso 2.
El modelo consume "Register", y produce "Check Credit".
Tokens producidos: 2
Token consumidos: 1
Traza: Check Credit -> Assess Risk -> Evaluate -> Approve -> Notify
Paso 3.
El modelo consume "Check Credit", y produce "Assess Risk".
Tokens producidos: 3
Token consumidos: 2
Traza: Assess Risk -> Evaluate -> Approve -> Notify
Paso 4.
El modelo consume "Assess Risk", y produce "Evaluate".
Tokens producidos: 4
Token consumidos: 3
Traza: Evaluate -> Approve -> Notify
Paso 5.
El modelo consume "Evaluate", y produce "Approve".
Tokens producidos: 5
Token consumidos: 4
Traza: Approve -> Notify
Paso 6.
El modelo consume "Approve", y produce "Notify".
Tokens producidos: 6
Token consumidos: 5
Traza: Notify
Paso 7.
El modelo consume "Notify", y no produce eventos.
Tokens producidos: 7
Token consumidos: 6
Traza: Ninguno

Al final del replay de esta traza perfecta tenemos que producir 7 tokens y consumimos 6. Por tanto, no nos faltó ningún token ni tampoco han sobrado tokens en la traza.

Cálculo del fitness model

El fitness del modelo es igual a 0.5*(1- (tokens faltantes/tokens consumidos)) + 0.5*(1 – (tokens restantes/tokens producidos)). En este caso, el fitness es 1 ya que no hay tokens faltantes ni restantes. Es decir, el modelo describe perfectamente el comportamiento observado en la traza.

Pero, en el caso que la traza no se comporte exactamente como el modelo espera, tenemos lo siguiente:

Estado inicial:
Traza: Register -> Check Credit -> Assess Risk -> Evaluate -> Alarm -> Approve -> Register -> Notify
Tokens producidos: Ninguno
Paso 1.
Inicio de evaluación, traza empieza por "Register", creamos "Register".
Traza: Register -> Check Credit -> Assess Risk -> Evaluate -> Alarm -> Approve -> Register -> Notify
Tokens producidos: 1
Paso 2.
El modelo consume "Register", y produce "Check Credit".
Tokens producidos: 2
Token consumidos: 1
Traza: Check Credit -> Assess Risk -> Evaluate -> Alarm -> Approve -> Register -> Notify
Paso 3.
El modelo consume "Check Credit", y produce "Assess Risk".
Tokens producidos: 3
Token consumidos: 2
Traza: Assess Risk -> Evaluate -> Alarm -> Approve -> Register -> Notify
Paso 4.
El modelo consume "Assess Risk", y produce "Evaluate".
Tokens producidos: 4
Token consumidos: 3
Traza: Evaluate -> Alarm -> Approve -> Register -> Notify
Paso 5.
El modelo consume "Evaluate", y produce "Approve".
El modelo es incapaz de consumir Alarm, falta un token en el modelo
Tokens producidos: 5
Token consumidos: 4
Tokens faltantes: 1
Traza: Approve -> Register -> Notify
Paso 6.
El modelo consume "Approve", y produce "Notify".
Tokens producidos: 6
Token consumidos: 5
Tokens faltantes: 1
Traza: Register
Paso 7.
El modelo consume "Notify", y no produce eventos.
El segundo Register nunca fue consumido, queda un token restante.
Tokens producidos: 7
Token consumidos: 6
Tokens faltantes: 1
Tokens resantes: 1
Traza: Register

Ahora, el fitness del modelo respecto a esta traza sería 0.5*(1-1/6)+0.5(1-1/7) = 0.845.

Observando el fitness, podemos ver cómo el modelo casi define el comportamiento, pero no completamente. Cosa que es de esperar, ya que hemos creado una traza que no es descrita por el modelo a propósito.

Aplicando este método sobre las trazas que generamos, encontramos que:

Las trazas que generamos a propósito siguiendo perfectamente el modelo tienen un fitness perfecto, mientras que diferentes defectos tienen efectos distintos sobre el fitness.

Sin embargo, existe una limitación básica usando Token Replay. Si hay eventos que son registrados fuera de orden o faltan, los efectos sobre su fitness son muy elevados. Esto es debido a que no se pueden consumir tal y como describe el modelo. Pero, bien podría ser que la única diferencia es un desalineamiento pequeño, un único evento ocurriendo antes que otro causado, por ejemplo, por imprecisión en el registro de eventos. Para tener en cuenta estos casos, tenemos la métrica del alineamiento.

Evaluación con Alignment

La metodología Alignment o Alineamiento de un modelo, a diferencia de Token Replay, lo plantea como un problema de optimización, donde tenemos la traza y su traza “equivalente” en el modelo. El alineamiento es entonces, el mínimo coste para transformar nuestra traza en su equivalente conforme al modelo.

Para ello, tenemos 3 tipos de movimientos necesarios cuando evaluamos una traza con alineamiento: Move on Log, Move on Model y Synchronous Move.

• Move on log. El evento existe en la traza, pero el modelo no tiene tal evento.
• Move on model. Un evento era esperado por el modelo, pero no fue observado en la traza.
• Synchronous Move. El evento en la traza corresponde con su especificación en el modelo.

Ejemplo de evaluación con Alignment

Por ejemplo, para la traza:

Register → Assess Risk → Evaluate → Alarm → Approve → Register → Notify

El coste total de alineamiento es entonces 3, debido a que tenemos 2 Move on Log y 1 Move on model.

Aplicando esto a nuestras trazas:

Podemos ver que es más fácil diagnosticar los fallos. Los errores como incompletud u orden erróneo de las tareas no son tan dominantes como en Token Replay, aun si siguen siendo importantes.

La limitación del análisis de conformidad con alineamiento es que es considerablemente computacionalmente más caro. Así pues, en casos de trazas suficientemente grandes, se dificulta este tipo de análisis. Por este motivo, Token Replay puede ser favorito sobre todo si es menos robusto a errores.

Conclusión

El análisis de conformidad permite evaluar de una forma estandarizada cómo unas trazas difieren de un modelo definido previamente. Para este propósito, hemos expuesto dos métodos populares, Token Replay y Alignment o Alineamiento.

A su vez, hemos mostrado cómo funciona Token Replay y expuesto ejemplos además de mostrar cómo diferentes errores afectan en el resultado obtenido. También hemos aplicado lo mismo con el Alineamiento de procesos, descubriendo que es más preciso en diagnosticar los errores, pero también es computacionalmente más costoso.

Si este artículo te ha parecido interesante, te animamos a visitar la categoría Data Science para ver otros posts similares a este y visitar la web de Damavis para conocer nuestros proyectos. ¡Hasta pronto!