Designing an event log

Introducción

Al configurar las transformaciones para Process Mining, es importante tener una buena comprensión del proceso. El primer paso es definir los eventos que se producen y los objetos en los que tienen lugar estos eventos.

Define the events

Comience definiendo las actividades de alto valor. Priorice la adición de actividades en función de la frecuencia con la que ocurren y su importancia para el usuario final. La definición de las actividades debe ser un proceso iterativo.

La siguiente ilustración muestra un ejemplo de un registro de eventos para el proceso Facturas.

El número ideal de actividades para describir un proceso es entre 10 y 20. Aunque más actividades darán lugar a más posibilidades de análisis, también darán lugar a más variaciones de procesos y a una mayor complejidad.

Número de actividades	Resultado
<10	Baja complejidad de análisis, bajo número de posibles mejoras.
10-20	Equilibrio óptimo entre la complejidad del análisis y las posibles mejoras
20	Alta complejidad de análisis, alto número de pequeñas mejoras.

Convenciones de nombres

Para los nombres de actividad, la mejor práctica es utilizar el formato Verbo Sustantivo, como Crear documento. La siguiente tabla contiene algunos consejos sobre la denominación de actividades.

Nombre de actividad	Asesoramiento	Mejores prácticas
Orden Orden	Evita los nombres ambiguos de las actividades.	Solicitar material
Ticket	Evita los nombres singulares de las actividades, indica qué pasó con qué.	Crear ticket
Documento cancelado	Evita la voz pasiva.	Cancelar documento
Aprobar la comprobación del control de crédito en el pedido	Evita los nombres de actividades demasiado largos	Aprobar la verificación de crédito SO

Definir objetos

Los eventos tienen lugar en uno o más objetos del proceso. Utilice el conjunto de eventos deseados para determinar qué objetos son necesarios para un proceso empresarial. La siguiente tabla muestra un ejemplo de un conjunto de eventos y sus objetos correspondientes.

Evento	Objeto
Crear orden de compra	Orden de compra
Aprobar orden de compra	Orden de compra
Crear factura	Factura
Cambiar las condiciones de pago	Factura

Cada objeto puede tener propiedades que son específicas de ese objeto. Por ejemplo, un objeto de orden de compra puede tener un purchase_order_type y un objeto de factura puede tener un payment_due_date.

Define the event log

El número de objetos que son de interés en un proceso varía en función de la complejidad del proceso. En algunos procesos, solo se puede requerir un objeto, como el ticket en un proceso de gestión de incidentes.

En procesos más complejos, varios objetos pueden ser de interés. Por ejemplo, un proceso Purchase-to-Pay que comienza con la compra de un producto hasta el pago de una factura cubre un conjunto de eventos relacionados con múltiples objetos. Para crear un registro de eventos para tales procesos, deben definirse las relaciones entre los objetos. La siguiente ilustración muestra un ejemplo de diagrama de relaciones de objetos Purchase-to-Pay.

El registro de eventos describe el proceso de extremo a extremo que cubre los eventos de todos los objetos combinados. Solo un objeto del proceso puede funcionar como objeto principal, del que se realizará un seguimiento durante todo el proceso. Este objeto principal se denomina "Caso" en el proceso, identificado por su "ID de caso".