Záznam událostí pro process mining: jak ho vytvořit

Process mining se záznamem událostí začíná u jedné tabulky: aktivit s časovými razítky seskupených podle ID případu. V tomto návodu sestavíte tabulku ze systémových dat na příkladu fiktivního procesu zpracování objednávek v restauraci. Ukážeme vám dva způsoby: několik řádků v Excelu nebo jeden dotaz SQL, který spojí aktivity pomocí UNION ALL. Postup můžete průběžně porovnávat s hotovým záznamem událostí.

Záznam událostí pro process mining: potřebujete tři sloupce

Záznam událostí je strukturovaný přehled toho, co se v procesu stalo. Každý řádek představuje jednu událost, například zadání objednávky nebo přijetí platby. ID případu propojuje související události, časové razítko určuje, kdy k nim došlo. Nástroj díky těmto údajům dokáže rekonstruovat, jak případy procházejí procesem.

Aktivita označuje typ, událost konkrétní výskyt. Aktivita je druh činnosti, například „Odeslání objednávky“. Událost je jeden konkrétní případ této činnosti: objednávka 12345 byla odeslána 15. ledna ve 14:30. Záznam obsahuje události a každá z nich má název aktivity. Lidé tato slova často zaměňují, ale při přípravě dat je rozdíl důležitý. Aktivita říká, co se stalo, událost pak popisuje, že se to stalo právě tomuto případu v daný čas.

Základní event log pro process mining potřebuje tři sloupce:

Než budete pokračovat, ověřte tato tři pole:

Tyto tři údaje tvoří základ. Pokud některý chybí nebo není konzistentní, zobrazení procesu neodpovídá skutečnému pořadí práce. Ostatní údaje jsou volitelné. Záznam událostí, který dokážou nástroje pro process mining načíst, tvoří vždy jedna tabulka případů a událostí. Tři sloupce potřebné pro použitelný záznam událostí se nemění. Podporované formáty a postup přípravy dat najdete v dokumentaci k datům pro process mining.

Praktický příklad: systém objednávek v Pizza Palace

Abychom si jednotlivé kroky ukázali na konkrétním příkladu, použijeme fiktivní restauraci Pizza Palace. Zákazníci zadávají objednávky online, personál připravuje jídlo a řidiči ho rozvážejí. Příklad neobsahuje žádné údaje o skutečných zákaznících.

Představte si, že systém ukládá informace do těchto tabulek:

• orders: ID objednávky, zákazník a čas objednání
• order_items: pizzy, přílohy a nápoje v jednotlivých objednávkách
• kitchen_queue: kdy objednávka vstoupí do kuchyně a kdy ji opustí
• delivery_assignments: přiřazení řidičů a sledování doručení
• payments: záznamy o zpracování plateb

Cílem je vytvořit jeden event log, který zachytí cestu každé objednávky od zadání po doručení. ID objednávky bude sloužit jako ID případu. Každá relevantní časová značka a činnost se zaznamená na samostatný řádek. Stáhněte si ukázkový záznam událostí Pizza Palace a porovnejte jeho sloupce se svým výpisem. Jde o ukázkový event log pro process mining.

Než začnete data extrahovat, rozhodněte, které aktivity zahrnete. Objednávka v Pizza Palace prochází šesti kroky:

1. Zadání objednávky: zákazník odešle objednávku.
2. Přijetí platby: platba se úspěšně zpracuje.
3. Předání objednávky do kuchyně: objednávka vstoupí do fronty na přípravu.
4. Dokončení přípravy objednávky: kuchyně označí objednávku jako hotovou.
5. Přiřazení řidiči: objednávce se přiřadí řidič.
6. Dokončení doručení: objednávka je doručena.

U každé aktivity určete zdrojovou tabulku, pole s časovou značkou a pole s ID případu. Ověřte, že ID případu propojuje událost se správnou objednávkou.

Rozlišujte přímé a odvozené události. Přímá událost má ve zdrojovém systému vlastní záznam a časovou značku. Zadání objednávky vychází z časové značky ve sloupci orders, přijetí platby ze sloupce payments a dokončení doručení ze sloupce delivery_assignments. Tyto údaje se obvykle extrahují snadno, pokud časová značka odpovídá události, kterou chcete analyzovat.

Odvozená událost nemá vlastní záznam, takže její čas určíte z jiného pole. Přiřazení řidiči může být zaznamenáno jen jako čas vytvoření záznamu o přiřazení doručení. Dokončení přípravy objednávky může být zaznamenáno jen jako okamžik, kdy se stav fronty v kuchyni změnil na „dokončeno“. Odvozené události mohou být užitečné, ale zdokumentujte, jak jste je určili. Změna stavu nebo čas vytvoření záznamu nemusí přesně znamenat to, co naznačuje název aktivity. Než takové pole použijete jako časovou značku události, ověřte jeho význam u lidí, kteří zdrojový systém znají.

Toto mapování je návrh, nikoli potvrzení, že jsou všechna pole vhodná. Ověřte, zda jsou časové značky vyplněné a zda lze každou tabulku propojit s ID objednávky, aniž by vznikly duplicitní řádky.

Atributy případů a událostí

Atributy doplňují kontext pro analýzu. Jde o sloupce nad rámec ID případu, časové značky a aktivity. Přidávejte je jen tehdy, když mají jasný význam a lze je přiřadit ke správnému případu nebo události.

Atributy případu popisují celý případ a obvykle zůstávají u všech jeho událostí stejné: jméno zákazníka, celková hodnota objednávky, adresa doručení nebo počet objednaných položek. V plochém event logu opakujete hodnotu na každém řádku daného případu. Díky tomu můžete později filtrovat a porovnávat události podle informací o případu.

Atributy události popisují jednu konkrétní událost: řidiče u události doručení, způsob platby u události platby nebo stanoviště v kuchyni u kuchyňské události. Takový sloupec se nevztahuje na každý řádek. Tam, kde se nepoužije, ho nechte prázdný, ale v tabulce ho ponechte, aby měly všechny řádky stejnou strukturu.

Hotový event log má tvořit jedna plochá tabulka s jednou událostí na řádek. Zde je záznam pro Pizza Palace:

Zákazník a hodnota objednávky se u každé události stejného případu opakují. Je to záměr. Díky tomu zůstává event log v jednoduché tabulce, kterou nástroje pro process mining dokážou načíst.

Postup 1: sestavte event log v Excelu

Excel se hodí pro menší výpis nebo první pokus. Exportujte každý typ události, sjednoťte sloupce a spojte řádky na jednom listu. Pět níže uvedených kroků zabere nad daty Pizza Palace přibližně hodinu.

Krok 1: exportujte každý typ události na samostatný list. Pro každý typ aktivity vytvořte vlastní list. Například:

List 1: Zadání objednávky

List 2: Přijetí platby

Stejným způsobem vytvořte další listy pro události v kuchyni a při doručování.

Krok 2: sjednoťte sloupce. Na každém listu použijte stejné názvy sloupců ve stejném pořadí. Pokud se atribut na daný typ události nevztahuje, přidejte prázdný sloupec. Například list Zadání objednávky může obsahovat všechny sloupce:

Zkontrolujte, zda jsou hodnoty ve slučitelných formátech. Zejména ověřte, že jsou časové značky uložené jako datum a čas, ne jako text, který jen vypadá jako časová značka.

Krok 3: spojte listy. Vytvořte nový list s názvem Záznam událostí a zkopírujte do něj řádky událostí z listů jednotlivých aktivit. Ponechte jeden řádek záhlaví a jednu událost na každém řádku.

Krok 4: seřaďte data podle případu a časového razítka. Spojená data seřaďte vzestupně podle Case ID a potom podle Timestamp. Snáz tak zkontrolujete posloupnost událostí v jednotlivých případech. Řazení neopraví nepřesná časová razítka, proto před spoléháním na jejich pořadí prověřte události se stejným nebo neočekávaným časem.

Krok 5: exportujte data do CSV. Uložte spojený list jako CSV se záznamem událostí pro process mining, který váš nástroj dokáže načíst. Exportovaný soubor otevřete a ověřte, že záhlaví, oddělovače, formát data i prázdné hodnoty vypadají podle očekávání.

Tipy pro Excel:

• Pomocí funkcí VLOOKUP nebo XLOOKUP doplňte atributy případu, například jméno zákazníka, z listu s objednávkami.
• Používejte jednotný formát data a času, například YYYY-MM-DD HH:MM:SS.
• Před exportem zkontrolujte duplicitní řádky.
• Původní výpisy uchovejte beze změn, abyste mohli dohledat všechny opravy.

Metoda 2: sestavení pomocí SQL

SQL se hodí, když máte data v databázi, výpis je rozsáhlý nebo potřebujete stejný výpis zopakovat příští měsíc. Obvyklý postup je vytvořit jeden SELECT pro každou aktivitu a spojit je pomocí UNION ALL.

Jak funguje UNION ALL. Spojí řádky vrácené několika příkazy SELECT. Každý příkaz musí vracet stejný počet sloupců ve stejném pořadí, s kompatibilními datovými typy a jednotnou sadou aliasů, aby měly výsledné sloupce srozumitelné názvy.

Dotaz. Níže uvedený příklad pracuje s fiktivními tabulkami Pizza Palace. Před úpravou si ověřte názvy vlastních tabulek a polí, význam časových razítek i použitý dialekt 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;

Dotaz používá ID objednávky jako Case ID a pro každou aktivitu vrací stejných sedm sloupců. Hodnoty NULL zachovávají jednotnou strukturu sloupců tam, kde se atribut neuplatňuje. Filtr data a podmínka úspěšné platby jsou jen příklady. Zvolte filtry podle procesu a období, které chcete analyzovat.

Rozšíření dotazu. Další aktivitu přidáte takto:

1. Jako výchozí bod zkopírujte blok SELECT.
2. Použijte zdrojovou tabulku, která zaznamenává událost.
3. Vyberte pole, které představuje její časové razítko.
4. Zadejte název aktivity, který bude jednotný s ostatními řádky.
5. Zahrňte Case ID a všechny relevantní atributy.
6. Přidejte filtry podle zamýšlené analýzy.

Například můžete přidat pokus o doručení, pokud váš systém obsahuje odpovídající tabulku a pole:

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'

Kontrola záznamu před analýzou

Před analýzou záznamu proveďte tyto kontroly. Zaměřují se na nejčastější nedostatky záznamů událostí v process mining, které vedou k zavádějícím výsledkům: duplicity, chybějící časová razítka, nestálá ID případů a pole se stavem zaměněná za aktivity.

1. Začněte povinnými sloupci. Než přidáte další události nebo atributy, vytvořte jednoduchý záznam se sloupci ID případu, časové razítko a aktivita.
2. Používejte stabilní ID případů. Každá událost stejného případu musí mít stejné ID. Nepoužívejte hodnotu, která se v průběhu procesu mění.
3. Názvy aktivit sjednoťte. Zvolte jeden název, například „Objednávka zadána“, a nemíchejte ho s názvy „Objednávka vytvořena“ nebo „Nová objednávka“.
4. Zkontrolujte časová razítka. Ověřte, že odpovídají času události, používají stejné časové pásmo a lze je seřadit jako datum a čas.
5. Prověřte duplicity a chybějící hodnoty. Zjistěte příčinu opakovaných událostí a řádků, ve kterých chybí ID případu, časové razítko nebo aktivita.
6. Zdokumentujte extrakci. Zaznamenejte zdrojové tabulky, pole, filtry, datum extrakce a předpoklady. Záznam pak bude snazší aktualizovat a řešit případné problémy.
7. Atributy přidávejte uvážlivě. Zahrňte pole, která pomohou zodpovědět konkrétní otázku, a ověřte, že spojení tabulek nenásobí řádky událostí.

Sedm běžných problémů s daty, od duplicitních událostí po chybějící ID případů, najdete v odpovědích na časté otázky na konci této stránky. Opakované výpisy řeší průvodce ETL pro process mining.

Co dělat, když nemáte potřebná data

K přípravě záznamu událostí nepotřebujete předem připravený konektor. Nejprve zjistěte, jaká data lze ze systému exportovat a zda obsahují tři povinná pole.

1. Určete proces a ID případu, který chcete sledovat.
2. Zjistěte, zda systém umí exportovat historii událostí, auditní záznamy nebo změny stavů s časovými razítky.
3. Pomocí datové šablony namapujte dostupná pole na ID případu, časové razítko a aktivitu.
4. Pokud nelze exportovat hotovou tabulku událostí, požádejte datový tým o výpis z databáze nebo report s jedním řádkem pro každou událost.

Export ze systému může obsahovat několik tabulek nebo používat různé názvy pro stejné pole. Data můžete spojit a přejmenovat v Excelu nebo SQL, pokud zachováte význam každého pole a dokážete ho dohledat až ke zdroji. Průvodce Kde získat data pro process mining ukazuje další místa, kde se mohou použitelná zdrojová data skrývat. V průvodcích zlepšováním procesů jsou pro váš systém už zpracované kroky 1 až 3 a pro každý proces je připravena datová šablona.

Pokud chcete porovnat formáty s dalším příkladem záznamu událostí pro process mining, v kolekci ukázkových souborů záznamů a šablon najdete připravenou tabulku. Na stránce šablona záznamu událostí jsou uvedené povinné i volitelné sloupce. Postup při načtení první datové sady najdete v průvodci Načtěte svou první datovou sadu.

Načtěte vytvořený záznam

Až bude záznam připravený, načtěte soubor a namapujte jeho tři povinné sloupce. ProcessMind načítá přímo soubory Excel, CSV i výpisy z databáze.

1. Nahrajte soubor nebo vyberte výpis z databáze.
2. Namapujte sloupce ID případu, časové razítko a aktivita.
3. Zkontrolujte další atributy.
4. Vygenerujte zobrazení procesu a ověřte, že případy i pořadí událostí dávají smysl.

Zobrazení mapování sloupců datové sady na role aktivity, případu a atributu v ProcessMind

Procesní pohled vám pomůže odhalit chybějící aktivity, neočekávané posloupnosti a oblasti, které je třeba prověřit. Neopravuje zdrojová data ani nemění způsob práce. Pokud první výsledek odhalí problém s daty, upravte výpis a načtěte ho znovu. Podrobný postup nahrání a mapování najdete v průvodci Načtěte svou první datovou sadu.

Načtěte právě vytvořený záznam