Registro de eventos para Process Mining: cómo crear uno
Cree un registro de eventos para Process Mining con las columnas adecuadas, un ejemplo de restaurante descargable y métodos paso a paso en Excel y SQL.
El Process Mining con registros de eventos parte de una tabla que reúne actividades, sus marcas de tiempo y el ID de cada caso. En esta guía, creará esa tabla a partir de datos del sistema con el ejemplo ficticio de un restaurante. Puede hacerlo de dos formas: con unas pocas filas en Excel o con una consulta SQL que combina las actividades mediante UNION ALL. Compare sus resultados con el registro de ejemplo completo a medida que avanza.
Crear un registro de eventos tiene fama de ser una tarea abrumadora. No tiene por qué serlo, siempre que no intente hacerlo todo de una vez. Empiece hoy con una plantilla o con unas pocas filas en Excel y amplíe el trabajo cuando tenga claro qué necesita.
Registro de eventos para Process Mining: las tres columnas necesarias
Un registro de eventos es un registro estructurado de lo que ocurrió en un proceso. Cada fila representa un evento, como la realización de un pedido o la recepción de un pago. El ID del caso conecta los eventos relacionados y la marca de tiempo sitúa cada evento en el tiempo. Juntos, estos datos permiten que una herramienta reconstruya cómo avanzan los casos por el proceso.
Una actividad es un tipo; un evento, una ocurrencia. Una actividad es un tipo de acción, como «Pedido enviado». Un evento es una ocurrencia concreta: el pedido 12345 se envió a las 14:30 del 15 de enero. El registro contiene eventos y cada uno incluye un nombre de actividad. Aunque se suelen usar ambos términos indistintamente, la diferencia importa al preparar los datos: la actividad indica qué ocurrió y el evento, que ocurrió en este caso y en este momento.
Un registro básico de eventos para Process Mining necesita tres columnas:
| Columna | Contenido | Ejemplo |
|---|---|---|
| ID del caso | Identificador que agrupa los eventos de un mismo caso | 1001 |
| Marca de tiempo | Momento en que ocurrió el evento | 2025-01-15 18:30:00 |
| Actividad | Qué ocurrió | Order Placed |
Antes de continuar, compruebe estos tres campos:
| Comprobación | Qué confirmar |
|---|---|
| ID del caso | Los eventos relacionados comparten el mismo ID y los casos distintos tienen ID diferentes |
| Marca de tiempo | Cada evento tiene una fecha y hora válidas |
| Actividad | Los nombres son claros y coherentes en toda la extracción |
Estos tres campos son la base. Si falta alguno o no es coherente, la vista del proceso mostrará una secuencia de trabajo incorrecta. Todo lo demás es opcional: las herramientas de Process Mining pueden leer un registro de eventos de procesos empresariales siempre que esté en una sola tabla de casos y eventos. Las tres columnas que hacen que ese registro sea útil no cambian. Consulte la documentación sobre datos para Process Mining para conocer los formatos admitidos y los pasos de preparación.
Ejemplo práctico: el sistema de pedidos de Pizza Palace
Para ilustrar los pasos, usaremos Pizza Palace, un restaurante ficticio. Los clientes hacen pedidos en línea, el personal prepara la comida y los repartidores la entregan. El ejemplo no contiene datos de clientes.
Imagine que el sistema almacena la información en estas tablas:
- orders: ID del pedido, cliente y hora del pedido
- order_items: pizzas, acompañamientos y bebidas de cada pedido
- kitchen_queue: cuándo entra y sale un pedido de la cocina
- delivery_assignments: asignación de repartidores y seguimiento de entregas
- payments: registros del procesamiento de pagos
El objetivo es crear un registro de eventos que siga cada pedido desde que se realiza hasta que se entrega. El ID del pedido será el ID del caso. Cada acción y marca de tiempo pertinente ocupará una fila. Descargue el registro de ejemplo de Pizza Palace como muestra para Process Mining y compare sus columnas con las de su propia extracción.
Decida qué actividades incluir antes de extraer los datos. En Pizza Palace, el recorrido del pedido consta de seis pasos:
- Pedido realizado: el cliente envía el pedido.
- Pago recibido: el pago se procesa correctamente.
- Pedido enviado a cocina: el pedido entra en la cola de preparación.
- Pedido listo: la cocina marca el pedido como terminado.
- Asignado a un repartidor: se asigna un repartidor.
- Entrega completada: se entrega el pedido.
Para cada actividad, identifique la tabla de origen, el campo de marca de tiempo y el campo del ID del caso. Confirme que el ID del caso vincula el evento con el pedido correcto.
| Actividad | Tabla de origen | Campo de marca de tiempo | Campo del ID del caso |
|---|---|---|---|
| Pedido realizado | orders | created_at | id |
| Pago recibido | payments | payment_time | order_id |
| Pedido enviado a cocina | kitchen_queue | queue_entry_time | order_id |
| Pedido listo | kitchen_queue | completed_time | order_id |
| Asignado a un repartidor | delivery_assignments | assigned_at | order_id |
| Entrega completada | delivery_assignments | delivered_at | order_id |
Distinga los eventos directos de los inferidos. Un evento directo tiene un registro y una marca de tiempo explícitos en un sistema de origen: Pedido realizado corresponde a la marca de tiempo de la fila orders, Pago recibido a payments y Entrega completada a delivery_assignments. Por lo general, estos eventos son fáciles de extraer, siempre que la marca de tiempo represente el evento que quiere analizar.
Un evento inferido no tiene un registro propio, por lo que su momento se deduce de otro campo. Es posible que Asignado a un repartidor solo figure como la hora de creación de la asignación de entrega, y que Pedido listo corresponda únicamente al momento en que el estado de la cola de cocina cambió a «completado». Los eventos inferidos pueden ser útiles, pero documente cómo los obtuvo: un cambio de estado o la hora de creación de un registro quizá no signifiquen exactamente lo que sugiere la actividad. Antes de tratar esa hora como la marca de tiempo del evento, consulte a quienes conocen el sistema de origen.
Esta asignación es un plan, no una prueba de que todos los campos sean adecuados. Compruebe que las marcas de tiempo tengan valores y que pueda unir cada tabla con el ID del pedido sin generar filas duplicadas.
Atributos del caso y del evento
Los atributos aportan contexto al análisis. Son las columnas adicionales a ID del caso, Marca de tiempo y Actividad. Solo conviene añadirlos si tienen un significado claro y pueden vincularse al caso o evento correcto.
Los atributos del caso describen el caso en su conjunto y suelen mantenerse iguales en todos sus eventos: nombre del cliente, importe total del pedido, dirección de entrega y número de artículos pedidos. En un registro de eventos plano, el valor se repite en cada fila del caso. Así podrá filtrar o comparar eventos más adelante usando información del caso.
Los atributos del evento describen un evento concreto: el repartidor en un evento de entrega, el método de pago en uno de pago o la estación de cocina en uno de cocina. Una columna de este tipo no se aplica a todas las filas. Déjela en blanco cuando no corresponda y manténgala en la tabla para que todas las filas tengan la misma estructura.
El registro de eventos final debe ser una sola tabla plana, con un evento por fila. Este es el registro de Pizza Palace:
| ID del caso | Marca de tiempo | Actividad | Cliente | Importe del pedido | Repartidor | Método de pago |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Pedido realizado | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:30:15 | Pago recibido | John Smith | 45.99 | Tarjeta de crédito | |
| 1001 | 2025-01-15 18:31:00 | Pedido enviado a cocina | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:45:00 | Pedido listo | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:46:00 | Asignado a un repartidor | John Smith | 45.99 | Maria Garcia | |
| 1001 | 2025-01-15 19:05:00 | Entrega completada | John Smith | 45.99 | Maria Garcia | |
| 1002 | 2025-01-15 18:35:00 | Pedido realizado | Jane Doe | 28.50 | ||
| 1002 | 2025-01-15 18:35:20 | Pago recibido | Jane Doe | 28.50 | PayPal | |
| … | … | … | … | … | … | … |
El cliente y el importe del pedido se repiten en cada evento del mismo caso. Es intencional: así el registro conserva un formato de tabla sencillo que las herramientas de Process Mining pueden leer.
Método 1: créelo en Excel
Excel es una buena opción para una extracción pequeña o un primer ejercicio. Exporte cada tipo de evento, estandarice las columnas y combine las filas en una sola hoja. Los cinco pasos siguientes llevan alrededor de una hora con los datos de Pizza Palace.
Paso 1: exporte cada tipo de evento a una hoja distinta. Cree una hoja de cálculo para cada tipo de actividad. Por ejemplo:
Hoja 1: Pedido realizado
| ID del caso | Marca de tiempo | Actividad | Cliente | Importe del pedido |
|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Pedido realizado | John Smith | 45.99 |
| 1002 | 2025-01-15 18:35:00 | Pedido realizado | Jane Doe | 28.50 |
Hoja 2: Pago recibido
| ID del caso | Marca de tiempo | Actividad | Cliente | Importe del pedido | Método de pago |
|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:15 | Pago recibido | John Smith | 45.99 | Tarjeta de crédito |
| 1002 | 2025-01-15 18:35:20 | Pago recibido | Jane Doe | 28.50 | PayPal |
Cree hojas adicionales para los eventos de cocina y entrega siguiendo el mismo método.
Paso 2: estandarice las columnas. Use los mismos nombres de columna y el mismo orden en todas las hojas, y añada columnas en blanco cuando un atributo no corresponda. Por ejemplo, la hoja Pedido realizado puede incluir todas las columnas:
| ID del caso | Marca de tiempo | Actividad | Cliente | Importe del pedido | Repartidor | Método de pago |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Pedido realizado | John Smith | 45.99 |
Compruebe que los valores tengan formatos compatibles. En particular, asegúrese de que las marcas de tiempo estén guardadas como fechas y horas, no como texto que solo parece una marca de tiempo.
Paso 3: combine las hojas. Cree una hoja nueva llamada Registro de eventos y copie en ella las filas de eventos de cada hoja de actividad. Mantenga una sola fila de encabezados y un evento por fila.
Paso 4: ordene por caso y marca de tiempo. Ordene los datos combinados primero por ID del caso, en orden ascendente, y luego por Marca de tiempo, también en orden ascendente. Así será más fácil revisar la secuencia de cada caso. Ordenar no corrige las marcas de tiempo inexactas, así que compruebe los eventos con horas idénticas o inesperadas antes de confiar en el orden.
Paso 5: exporte a CSV. Guarde la hoja combinada como un archivo CSV de registro de eventos que su herramienta pueda leer. Abra el archivo exportado para confirmar que los encabezados, delimitadores, formatos de fecha y valores en blanco sean los esperados.
Consejos para Excel:
- Use VLOOKUP o XLOOKUP para añadir atributos del caso, como el nombre del cliente, desde la hoja de pedidos.
- Use un formato uniforme de fecha y hora, como
YYYY-MM-DD HH:MM:SS. - Compruebe que no haya filas duplicadas antes de exportar.
- Guarde una copia sin modificar de las extracciones originales para poder rastrear las correcciones.
Método 2: créelo con SQL
SQL resulta útil cuando los datos están en una base de datos, la extracción es grande o necesita repetirla el próximo mes. La estructura habitual consiste en una SELECT por actividad y combinar los resultados con UNION ALL.
Cómo funciona UNION ALL. Combina las filas devueltas por varias instrucciones SELECT. Cada instrucción debe devolver el mismo número de columnas, en el mismo orden y con tipos de datos compatibles. También debe usar un conjunto coherente de alias para que las columnas finales tengan nombres claros.
La consulta. El ejemplo siguiente usa las tablas ficticias de Pizza Palace. Antes de adaptarlo, compruebe los nombres de sus tablas y campos, el significado de las marcas de tiempo y el dialecto SQL.
-- Event Log Extraction for Pizza Palace
-- This query combines multiple event types into a single event log
-- Each SELECT block represents one activity type
-- Event 1: Order Placed
-- Source: orders table
-- This captures when customers submit their orders
SELECT
o.id AS case_id, -- The order ID is our case identifier
o.created_at AS timestamp, -- When the order was placed
'Order Placed' AS activity, -- The activity name (hardcoded)
o.customer_name AS customer, -- Case attribute: who ordered
o.total_amount AS order_value, -- Case attribute: order value
NULL AS driver, -- Not applicable for this event
NULL AS payment_method -- Not applicable for this event
FROM orders o
WHERE o.created_at >= '2025-01-01' -- Filter to your desired date range
UNION ALL
-- Event 2: Payment Received
-- Source: payments table
-- This captures successful payment processing
SELECT
p.order_id AS case_id,
p.payment_time AS timestamp,
'Payment Received' AS activity,
o.customer_name AS customer, -- Join to get case attributes
o.total_amount AS order_value,
NULL AS driver,
p.payment_method AS payment_method -- Event-specific attribute
FROM payments p
JOIN orders o ON p.order_id = o.id -- Join to get order details
WHERE p.payment_time >= '2025-01-01'
AND p.status = 'successful' -- Only include successful payments
UNION ALL
-- Event 3: Order Sent to Kitchen
-- Source: kitchen_queue table
-- This captures when the kitchen starts working on the order
SELECT
k.order_id AS case_id,
k.queue_entry_time AS timestamp,
'Order Sent to Kitchen' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
NULL AS driver,
NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.queue_entry_time >= '2025-01-01'
UNION ALL
-- Event 4: Order Ready
-- Source: kitchen_queue table (different timestamp field)
-- This is an inferred event based on when the kitchen marked it complete
SELECT
k.order_id AS case_id,
k.completed_time AS timestamp, -- Different timestamp than entry
'Order Ready' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
NULL AS driver,
NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.completed_time >= '2025-01-01'
AND k.completed_time IS NOT NULL -- Only include completed orders
UNION ALL
-- Event 5: Assigned to Driver
-- Source: delivery_assignments table
-- This captures when a driver is assigned to deliver the order
SELECT
d.order_id AS case_id,
d.assigned_at AS timestamp,
'Assigned to Driver' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
d.driver_name AS driver, -- Event-specific attribute
NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.assigned_at >= '2025-01-01'
UNION ALL
-- Event 6: Delivery Completed
-- Source: delivery_assignments table (different timestamp field)
-- This captures when the order was delivered to the customer
SELECT
d.order_id AS case_id,
d.delivered_at AS timestamp,
'Delivery Completed' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
d.driver_name AS driver,
NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.delivered_at >= '2025-01-01'
AND d.delivered_at IS NOT NULL -- Only include completed deliveries
-- Final ordering: by case, then by time
-- This makes the event log easy to read and follow
ORDER BY case_id, timestamp; La consulta usa el ID del pedido como ID del caso y devuelve las mismas siete columnas para cada actividad. Los valores NULL mantienen la estructura de las columnas cuando un atributo no corresponde. El filtro de fechas y la condición de pago completado son ejemplos: elija filtros que se ajusten al proceso y al periodo que quiere analizar.
Amplíe la consulta. Para añadir otra actividad:
- Copie un bloque
SELECTcomo punto de partida. - Use la tabla de origen donde se registra el evento.
- Seleccione el campo que representa su marca de tiempo.
- Asigne un nombre de actividad coherente con las demás filas.
- Incluya el ID del caso y los atributos pertinentes.
- Añada filtros adecuados para el análisis.
Por ejemplo, podría añadir un intento de entrega de esta manera, si su sistema tiene la tabla y los campos pertinentes:
UNION ALL
-- Event 7: Delivery Attempted
-- Add this to track failed delivery attempts
SELECT
d.order_id AS case_id,
d.attempt_time AS timestamp,
'Delivery Attempted' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
d.driver_name AS driver,
NULL AS payment_method
FROM delivery_attempts d
JOIN orders o ON d.order_id = o.id
WHERE d.attempt_time >= '2025-01-01' Comprobaciones antes de analizar el registro
Realice estas comprobaciones antes de analizar el registro. En conjunto, abarcan los problemas habituales de los registros de eventos que pueden distorsionar los resultados de Process Mining: duplicados, marcas de tiempo faltantes, ID de caso inestables y campos de estado confundidos con actividades.
- Empiece por las columnas obligatorias. Cree un registro pequeño con ID del caso, Marca de tiempo y Actividad antes de añadir más eventos o atributos.
- Use ID de caso estables. Todos los eventos de un mismo caso deben usar el mismo identificador. No use un valor que cambie durante el proceso.
- Mantenga la coherencia en los nombres de las actividades. Elija una etiqueta, como «Pedido realizado», en lugar de alternarla con «Pedido creado» y «Pedido nuevo».
- Compruebe las marcas de tiempo. Confirme que representan el momento del evento, usan una zona horaria uniforme y pueden ordenarse como fechas y horas.
- Revise los duplicados y los valores faltantes. Investigue los eventos repetidos y las filas sin ID del caso, marca de tiempo o actividad.
- Documente la extracción. Anote las tablas de origen, los campos, los filtros, la fecha de extracción y las suposiciones. Así será más fácil actualizar el registro y resolver problemas.
- Añada atributos con criterio. Incluya campos que ayuden a responder una pregunta y confirme que las uniones no multipliquen las filas de eventos.
Las preguntas frecuentes al final de esta página responden a siete problemas habituales con los datos, desde los eventos duplicados hasta los ID de caso faltantes. La guía sobre ETL para Process Mining explica cómo aplicar el mismo trabajo a extracciones recurrentes.
Qué hacer si no tiene los datos
No necesita un conector preconfigurado para preparar un registro de eventos. Empiece por comprobar qué puede exportar su sistema y si incluye los tres campos obligatorios.
- Identifique el proceso y el ID del caso que quiere seguir.
- Compruebe si el sistema puede exportar el historial de eventos, los registros de auditoría o los cambios de estado con marca de tiempo.
- Use una plantilla de datos para asignar los campos disponibles a ID del caso, Marca de tiempo y Actividad.
- Si no puede exportar una tabla de eventos lista para usar, solicite al equipo de datos una extracción de la base de datos o un informe con una fila por evento.
Una exportación del sistema puede incluir varias tablas o usar nombres diferentes para un mismo campo. Puede combinar y cambiar el nombre de los datos en Excel o SQL, siempre que conserve el significado de cada campo y pueda rastrearlo hasta su origen. La guía Dónde obtener datos para Process Mining explica dónde encontrar otras fuentes de datos útiles. Además, las guías de mejora de procesos ya han completado los pasos 1 a 3 para su sistema e incluyen una plantilla de datos para cada proceso.
Si quiere comparar formatos con otro ejemplo de registro de eventos para Process Mining, la colección de archivos de ejemplo y plantillas de registros incluye una hoja de cálculo lista para usar. La página sobre el registro de eventos de plantilla enumera las columnas obligatorias y opcionales. Para ver cómo cargar el primer conjunto de datos, consulte Cargue su primer conjunto de datos.
Cargue el registro que creó
Cuando el registro esté listo, cargue el archivo y asigne sus tres columnas obligatorias. ProcessMind lee directamente archivos de Excel, CSV y extracciones de bases de datos.
- Cargue el archivo o seleccione la extracción de la base de datos.
- Asigne las columnas ID del caso, Marca de tiempo y Actividad.
- Revise los demás atributos.
- Genere la vista del proceso y compruebe que los casos y el orden de los eventos tengan sentido.
La vista del proceso puede ayudarle a detectar actividades faltantes, secuencias inesperadas y aspectos que conviene investigar. No corrige los datos de origen ni cambia la forma de trabajar. Si el primer resultado revela un problema con los datos, actualice la extracción y vuelva a cargarla. Cargue su primer conjunto de datos explica en detalle cómo cargarlo y asignar las columnas.
Where to Go From Here
Ya tiene un Registro de eventos o las tres columnas necesarias para crearlo. El siguiente paso es descubrir qué ocurre realmente en el proceso.