Come creare un Event Log per il Process Mining

Per il Process Mining basta una tabella con le attività, i relativi timestamp e l’ID del caso che le raggruppa. In questa guida vedrà come ricavarla dai dati di sistema, seguendo un esempio fittizio di gestione degli ordini di un ristorante: potrà inserire poche righe in Excel oppure eseguire una query SQL che combina le attività con UNION ALL. Durante il percorso, confronti il risultato con l’Event Log di esempio completo.

Event Log per il Process Mining: le tre colonne necessarie

Un Event Log è una registrazione strutturata di ciò che è accaduto in un processo. Ogni riga rappresenta un evento, ad esempio l’invio di un ordine o la ricezione di un pagamento. L’ID del caso collega gli eventi correlati, il timestamp colloca ciascun evento nel tempo e, insieme, questi dati consentono a uno strumento di ricostruire il percorso dei casi nel processo.

L’attività è una tipologia, l’evento è un’occorrenza. Un’attività è un tipo di azione, ad esempio “Ordine spedito”. Un evento è una sua occorrenza specifica: l’ordine 12345 è stato spedito il 15 gennaio alle 14:30. L’Event Log registra gli eventi e ciascuno riporta il nome dell’attività. Spesso i due termini vengono usati come sinonimi, ma la distinzione è importante quando si preparano i dati: l’attività indica cosa è successo, mentre l’evento specifica che cosa è successo a quel caso e in quale momento.

Un Event Log di base per il Process Mining richiede tre colonne:

Prima di procedere, verifichi questi tre campi:

Questi tre campi sono fondamentali: se uno manca o non è coerente, la rappresentazione del processo non rispecchierà la sequenza delle attività. Tutto il resto è facoltativo: un Event Log leggibile dagli strumenti di Process Mining è sempre una tabella di casi ed eventi, e le tre colonne necessarie per utilizzare un Event Log nel Process Mining aziendale non cambiano. Per conoscere i formati supportati e le fasi di preparazione, consulti la documentazione sui dati per il Process Mining.

Esempio pratico: il sistema ordini di Pizza Palace

Per rendere concreti i passaggi, useremo un ristorante immaginario chiamato Pizza Palace. I clienti ordinano online, il personale prepara i piatti e i corrieri li consegnano. L’esempio non contiene dati dei clienti.

Immagini che il sistema memorizzi le informazioni nelle tabelle seguenti:

• orders: ID dell’ordine, cliente e ora dell’ordine
• order_items: pizze, contorni e bevande di ogni ordine
• kitchen_queue: orari di ingresso e uscita dell’ordine dalla cucina
• delivery_assignments: assegnazioni ai corrieri e tracciamento delle consegne
• payments: registrazioni dell’elaborazione dei pagamenti

L’obiettivo è creare un unico Event Log che segua ogni ordine dall’invio alla consegna. L’ID dell’ordine sarà l’ID del caso. Ogni timestamp e azione pertinente diventerà una riga. Scarichi l’Event Log di esempio di Pizza Palace come modello per il Process Mining e confronti le sue colonne con quelle della Sua estrazione.

Decida quali attività includere prima di estrarre i dati. Per Pizza Palace, il percorso dell’ordine comprende sei passaggi:

1. Ordine inviato: il cliente invia l’ordine.
2. Pagamento ricevuto: il pagamento viene elaborato correttamente.
3. Ordine inviato in cucina: l’ordine entra nella coda di preparazione.
4. Ordine pronto: la cucina contrassegna l’ordine come completato.
5. Assegnato al corriere: viene assegnato un corriere.
6. Consegna completata: l’ordine viene consegnato.

Per ogni attività, individui la tabella di origine, il campo timestamp e il campo dell’ID del caso. Verifichi che l’ID del caso colleghi l’evento all’ordine corretto.

Distingua gli eventi diretti da quelli dedotti. Un evento diretto ha una registrazione esplicita e un timestamp nel sistema di origine: l’attività Ordine inviato deriva dal timestamp della riga orders, Pagamento ricevuto da payments e Consegna completata da delivery_assignments. In genere, questi eventi sono semplici da estrarre, purché il timestamp rappresenti l’evento che desidera analizzare.

Un evento dedotto non ha una registrazione propria, quindi il suo orario viene ricavato da un altro campo. L’attività Assegnato al corriere potrebbe essere registrata solo come ora di creazione dell’assegnazione alla consegna, mentre Ordine pronto potrebbe corrispondere soltanto al momento in cui lo stato della coda della cucina è passato a “completato”. Gli eventi dedotti possono essere utili, ma documenti il metodo usato per ricavarli: il cambiamento di stato o l’ora di creazione di una registrazione potrebbero non corrispondere esattamente a quanto suggerisce il nome dell’attività. Prima di usare il dato come timestamp dell’evento, ne verifichi il significato con chi conosce il sistema di origine.

Questa mappatura è un piano, non la prova che ogni campo sia adeguato. Verifichi che i timestamp siano valorizzati e che ogni tabella possa essere collegata all’ID dell’ordine senza generare righe duplicate.

Attributi del caso e degli eventi

Gli attributi aggiungono contesto all’analisi. Sono le colonne che si aggiungono a ID del caso, Timestamp e Attività e vale la pena includerli solo se hanno un significato chiaro e possono essere collegati al caso o all’evento corretto.

Gli attributi del caso descrivono il caso nel suo insieme e di solito restano invariati tra i suoi eventi: nome del cliente, valore totale dell’ordine, indirizzo di consegna, numero di articoli ordinati. In un Event Log tabellare, il valore viene ripetuto su ogni riga del caso, così in seguito sarà possibile filtrare o confrontare gli eventi in base alle informazioni del caso.

Gli attributi dell’evento descrivono un singolo evento: il corriere per un evento di consegna, il metodo di pagamento per un evento di pagamento, la postazione in cucina per un evento relativo alla cucina. Una colonna di questo tipo non si applica a tutte le righe: la lasci vuota quando non è pertinente e la mantenga nella tabella, così tutte le righe conservano la stessa struttura.

L’Event Log finale dovrebbe essere un’unica tabella piatta, con un evento per riga. Ecco l’Event Log di Pizza Palace:

Il cliente e il valore dell’ordine si ripetono per ogni evento dello stesso caso. È intenzionale: in questo modo l’Event Log resta una tabella semplice, leggibile dagli strumenti di Process Mining.

Metodo 1: crearlo in Excel

Excel è adatto a un’estrazione ridotta o a un primo esercizio. Esporti ogni tipo di evento, uniformi le colonne e riunisca le righe in un unico foglio. Con i dati di Pizza Palace, i cinque passaggi seguenti richiedono circa un’ora.

Passaggio 1: esporti ogni tipo di evento in un foglio separato. Crei un foglio di lavoro per ogni tipo di attività. Per esempio:

Foglio 1: Ordine inviato

Foglio 2: Pagamento ricevuto

Crei altri fogli per gli eventi relativi alla cucina e alle consegne, seguendo lo stesso metodo.

Passaggio 2: uniformi le colonne. Utilizzi gli stessi nomi e lo stesso ordine delle colonne in ogni foglio e aggiunga colonne vuote quando un attributo non è pertinente. Per esempio, il foglio Ordine inviato può includere tutte le colonne:

Verifichi che i valori utilizzino formati compatibili. In particolare, si assicuri che i timestamp siano memorizzati come date e orari, non come testo che sembra soltanto un timestamp.

Passaggio 3: unisca i fogli. Crei un nuovo foglio chiamato Event Log e vi copi le righe degli eventi di ciascun foglio delle attività, mantenendo una sola riga di intestazione e un evento per riga.

Passaggio 4: ordini per caso e timestamp. Ordini i dati combinati prima per ID del caso in ordine crescente, poi per Timestamp in ordine crescente. In questo modo sarà più semplice rivedere la sequenza di ogni caso. L’ordinamento non corregge i timestamp inesatti: prima di fare affidamento sull’ordine, controlli gli eventi con orari identici o inattesi.

Passaggio 5: esporti in CSV. Salvi il foglio combinato come Event Log CSV per il Process Mining, in un formato leggibile dal Suo strumento. Apra il file esportato per verificare che intestazioni, delimitatori, formato delle date e valori vuoti siano quelli previsti.

Suggerimenti per Excel:

• Usi VLOOKUP o XLOOKUP per aggiungere attributi del caso, come il nome del cliente, dal foglio degli ordini.
• Utilizzi un unico formato coerente per date e orari, ad esempio YYYY-MM-DD HH:MM:SS.
• Verifichi che non ci siano righe duplicate prima di esportare.
• Conservi una copia invariata delle estrazioni originali, così da poter ricostruire eventuali correzioni.

Metodo 2: crearlo con SQL

SQL è utile quando i dati si trovano in un database, l’estrazione è voluminosa o deve ripeterla il mese prossimo. In genere si usa una SELECT per ogni attività e si accodano i risultati con UNION ALL.

Come funziona UNION ALL. Accoda le righe restituite da più istruzioni SELECT. Ogni istruzione deve restituire lo stesso numero di colonne, nello stesso ordine e con tipi di dati compatibili. Anche gli alias devono essere coerenti, affinché le colonne finali abbiano nomi chiari.

La query. L’esempio seguente utilizza le tabelle fittizie di Pizza Palace. Prima di adattarlo, controlli i nomi delle tabelle e dei campi, il significato dei timestamp e il dialetto SQL utilizzato.

-- 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 query usa l’ID dell’ordine come ID del caso e restituisce le stesse sette colonne per ogni attività. I valori NULL mantengono coerente la struttura delle colonne quando un attributo non è pertinente. Il filtro per data e la condizione che seleziona i pagamenti riusciti sono esempi: scelga filtri adatti al processo e al periodo che desidera analizzare.

Estendere la query. Per aggiungere un’altra attività:

1. Copi un blocco SELECT come punto di partenza.
2. Utilizzi la tabella di origine che registra l’evento.
3. Selezioni il campo che rappresenta il timestamp dell’evento.
4. Assegni un nome all’attività, mantenendolo coerente con le altre righe.
5. Includa l’ID del caso e gli eventuali attributi pertinenti.
6. Aggiunga filtri adatti all’analisi.

Per esempio, se il sistema dispone della tabella e dei campi pertinenti, può aggiungere un tentativo di consegna in questo modo:

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'

Controlli da effettuare prima di analizzare l’Event Log

Esegua questi controlli prima di analizzare l’Event Log. Nel loro insieme, riguardano i problemi più comuni dei dati degli eventi che possono falsare i risultati del Process Mining: duplicati, timestamp mancanti, ID dei casi instabili e campi di stato scambiati per attività.

1. Parta dalle colonne obbligatorie. Crei un Event Log ridotto con ID del caso, Timestamp e Attività prima di aggiungere altri eventi o attributi.
2. Utilizzi ID dei casi stabili. Tutti gli eventi dello stesso caso devono riportare lo stesso identificativo. Non utilizzi un valore che cambia durante il processo.
3. Mantenga coerenti i nomi delle attività. Scelga un’unica etichetta, ad esempio “Ordine inviato”, senza alternarla a “Ordine creato” o “Nuovo ordine”.
4. Controlli i timestamp. Verifichi che rappresentino l’ora dell’evento, utilizzino un fuso orario coerente e possano essere ordinati come date e orari.
5. Riveda i duplicati e i valori mancanti. Verifichi gli eventi ripetuti e le righe senza ID del caso, timestamp o attività.
6. Documenti l’estrazione. Annoti le tabelle di origine, i campi, i filtri, la data di estrazione e le ipotesi adottate. In questo modo sarà più semplice aggiornare l’Event Log e risolvere eventuali problemi.
7. Aggiunga gli attributi con criterio. Includa i campi utili per rispondere a una domanda e verifichi che i join non moltiplichino le righe degli eventi.

Le risposte a sette problemi comuni dei dati, dagli eventi duplicati agli ID dei casi mancanti, si trovano nelle FAQ alla fine della pagina. La guida ETL per il Process Mining approfondisce lo stesso lavoro nel caso di estrazioni ricorrenti.

Cosa fare se non dispone dei dati

Non serve un connettore già pronto per preparare un Event Log. Per iniziare, verifichi quali dati è possibile esportare dal sistema e se sono disponibili i tre campi obbligatori.

1. Individui il processo e l’ID del caso che desidera seguire.
2. Verifichi se il sistema consente di esportare lo storico degli eventi, le registrazioni di audit o i cambiamenti di stato con timestamp.
3. Utilizzi un template per i dati per associare i campi disponibili a ID del caso, Timestamp e Attività.
4. Se non può esportare una tabella di eventi già pronta, chieda al team dati un’estrazione dal database o un report con una riga per evento.

L’esportazione di un sistema può contenere più tabelle o utilizzare nomi diversi per lo stesso campo. Può combinare e rinominare i dati in Excel o SQL, purché ne mantenga il significato e possa risalire alla fonte di ciascun campo. La guida Dove trovare i dati per il Process Mining illustra altre possibili fonti di dati utilizzabili; le guide al miglioramento dei processi hanno già completato i passaggi da 1 a 3 per il Suo sistema e includono un template per i dati di ciascun processo.

Se desidera confrontare i formati con un altro esempio di Event Log per il Process Mining, la raccolta di file di esempio e template include un foglio di calcolo già pronto, mentre la pagina dedicata al template di Event Log elenca le colonne obbligatorie e facoltative. Per una guida alla preparazione del primo insieme di dati, consulti Caricare il primo insieme di dati.

Carichi l’Event Log che ha creato

Quando l’Event Log è pronto, carichi il file e associ le tre colonne obbligatorie. ProcessMind legge direttamente file Excel, CSV ed estrazioni da database.

1. Carichi il file o selezioni l’estrazione dal database.
2. Associ le colonne ID del caso, Timestamp e Attività.
3. Riveda gli eventuali attributi aggiuntivi.
4. Generi la rappresentazione del processo e verifichi che i casi e l’ordine degli eventi siano corretti.

Visualizzazione della mappatura delle colonne del set di dati ai ruoli di attività, caso e attributo in ProcessMind

La rappresentazione del processo può aiutare a individuare attività mancanti, sequenze inattese e aspetti da approfondire. Non corregge i dati di origine né modifica il modo in cui viene svolto il lavoro: se il primo risultato evidenzia un problema nei dati, aggiorni l’estrazione e carichi di nuovo il file. Caricare il primo insieme di dati illustra nel dettaglio il caricamento e la mappatura.

Carichi l’Event Log appena creato