Eseménynapló process mininghez: útmutató az összeállításhoz

A process mininghez használt eseménynapló egyetlen táblával kezdődik: az időbélyeggel ellátott tevékenységeket esetazonosító szerint kell csoportosítani. Ez az útmutató egy fiktív éttermi rendelési folyamat rendszeradataiból állítja össze a táblát, kétféle módon: néhány sorral Excelben vagy egy SQL-lekérdezéssel, amely a tevékenységeket UNION ALL segítségével egyesíti. Munka közben hasonlítsa össze az eredményt az elkészült példanaplóval.

Eseménynapló process mininghez: a három szükséges oszlop

Az eseménynapló a folyamatban történtek strukturált nyilvántartása. Minden sor egy esemény, például egy rendelés leadása vagy egy fizetés beérkezése. Az esetazonosító összekapcsolja az összetartozó eseményeket, az időbélyeg megadja az esemény időpontját. Ezek alapján egy eszköz rekonstruálhatja, hogyan haladnak végig az esetek a folyamaton.

A tevékenység egy típust, az esemény egy konkrét előfordulást jelöl. A tevékenység egyfajta művelet, például „Rendelés kiszállítva”. Az esemény ennek egy konkrét előfordulása: a 12345-ös rendelést január 15-én 14:30-kor kiszállították. A napló az eseményeket rögzíti, és mindegyikhez tartozik egy tevékenységnév. A két szót gyakran felcserélhetően használják, de az adat-előkészítésnél fontos a különbség: a tevékenység megnevezi, mi történt, az esemény pedig azt, hogy mikor történt meg az adott esettel.

A process mininghez használt alapvető eseménynapló három oszlopból áll:

Mielőtt továbblép, ellenőrizze ezt a három mezőt:

Ez a három mező az alap. Ha valamelyik hiányzik vagy nem egységes, a folyamatnézet hibásan mutatja a munka sorrendjét. Minden más mező opcionális. Az üzleti folyamatok process mining eszközei által beolvasható eseménynapló mindig egyetlen, eseteket és eseményeket tartalmazó tábla. Az üzleti folyamatok process miningjéhez használt eseménynapló három nélkülözhetetlen oszlopa pedig mindig ugyanaz. A támogatott formátumokról és az előkészítés lépéseiről a process mining-adatok dokumentációjában olvashat.

Példa lépésről lépésre: a Pizza Palace rendelési rendszere

A lépések bemutatásához egy kitalált étterem, a Pizza Palace példáját használjuk. A vendégek online rendelnek, a dolgozók elkészítik az ételt, a futárok pedig kiszállítják. A példa nem tartalmaz ügyféladatokat.

Tegyük fel, hogy a rendszer az alábbi táblákban tárolja az adatokat:

• orders: rendelésazonosító, ügyfél és a rendelés időpontja
• order_items: a rendelésekben szereplő pizzák, köretek és italok
• kitchen_queue: mikor kerül a rendelés a konyhába, és mikor távozik onnan
• delivery_assignments: futár-hozzárendelések és a kiszállítás nyomon követése
• payments: fizetési tranzakciók adatai

A cél egy olyan eseménynapló összeállítása, amely a rendelés leadásától a kiszállításig követi az egyes rendeléseket. Az esetazonosító a rendelésazonosító lesz. Minden releváns időbélyeg és művelet külön sorba kerül. Töltse le a Pizza Palace példanaplóját, és hasonlítsa össze az oszlopait a saját adatkinyerésével.

Az adatkinyerés előtt döntse el, mely tevékenységeket veszi fel. A Pizza Palace rendelési folyamata hat lépésből áll:

1. Rendelés leadva: A vendég elküldi a rendelést.
2. Fizetés beérkezett: A fizetés sikeresen megtörténik.
3. Rendelés elküldve a konyhának: A rendelés bekerül az elkészítendő rendelések sorába.
4. Rendelés elkészült: A konyha készre jelöli a rendelést.
5. Futárhoz rendelve: Kijelölnek egy futárt.
6. Kiszállítás befejezve: A rendelést kiszállítják.

Minden tevékenységnél azonosítsa a forrástáblát, az időbélyegmezőt és az esetazonosító mezőt. Ellenőrizze, hogy az esetazonosító a megfelelő rendeléshez kapcsolja-e az eseményt.

Különítse el a közvetlenül rögzített és a következtetéssel meghatározott eseményeket. A közvetlenül rögzített eseményhez a forrásrendszerben kifejezett rekord és időbélyeg tartozik: a Rendelés leadva esemény a orders sor időbélyegéből, a Fizetés beérkezett a payments, a Kiszállítás befejezve pedig a delivery_assignments rekordból származik. Ezeket általában egyszerű kinyerni, ha az időbélyeg valóban a vizsgálni kívánt eseményt jelöli.

A következtetéssel meghatározott eseménynek nincs saját rekordja, ezért az időpontját egy másik mezőből kell levezetni. A Futárhoz rendelve esemény például csak a kiszállítási hozzárendelés létrehozási időpontjaként szerepelhet, a Rendelés elkészült pedig csak akkor, amikor a konyhai sor státusza „completed” értékre változott. Az ilyen események hasznosak lehetnek, de dokumentálja, hogyan határozta meg őket. A státuszváltozás vagy a rekord létrehozásának időpontja nem feltétlenül azt jelenti, amit a tevékenységnév sugall. Mielőtt esemény-időbélyegként használná, egyeztessen a forrásrendszert ismerőkkel a mező jelentéséről.

Ez a mező-hozzárendelés terv, nem bizonyíték arra, hogy minden mező megfelelő. Ellenőrizze, hogy az időbélyegek ki vannak-e töltve, és hogy az egyes táblák a rendelésazonosító alapján összekapcsolhatók-e ismétlődő sorok létrehozása nélkül.

Eset- és eseményattribútumok

Az attribútumok további összefüggéseket adnak az elemzéshez. Ezek a Case ID, a Timestamp és az Activity mezőkön túli oszlopok. Csak akkor érdemes felvenni őket, ha egyértelmű a jelentésük, és hozzájuk rendelhetők a megfelelő esethez vagy eseményhez.

Az esetattribútumok a teljes esetet írják le, és általában minden eseménynél változatlanok maradnak: például az ügyfél neve, a rendelés teljes értéke, a kiszállítási cím vagy a rendelt tételek száma. Lapos eseménynaplóban minden, az adott esethez tartozó sorban megismétli az értéket. Így később az eset szintjén szűrheti vagy hasonlíthatja össze az eseményeket.

Az eseményattribútumok egyetlen eseményt írnak le: a futár adata egy kiszállítási eseménynél, a fizetési mód egy fizetési eseménynél, a konyhai állomás pedig egy konyhai eseménynél. Az ilyen oszlop nem minden sorra vonatkozik, ezért hagyja üresen ott, ahol nem alkalmazható, de tartsa meg az oszlopot, hogy minden sor szerkezete azonos maradjon.

Az elkészült eseménynapló egyetlen lapos táblából álljon, soronként egy eseménnyel. Íme a Pizza Palace naplója:

Az ügyfél neve és a rendelés értéke az adott eset minden eseménysorában megismétlődik. Ez szándékos: így a napló egyszerű, a process mining eszközök által beolvasható táblázat marad.

1. módszer: összeállítás Excelben

Az Excel jó választás kisebb adatkinyeréshez vagy első próbálkozáshoz. Exportálja az egyes eseménytípusokat, egységesítse az oszlopokat, majd egyesítse a sorokat egy munkalapon. Az alábbi öt lépés a Pizza Palace adatain körülbelül egy órát vesz igénybe.

1. lépés: exportálja az egyes eseménytípusokat külön munkalapra. Minden tevékenységtípushoz hozzon létre egy munkalapot. Például:

1. munkalap: Rendelés leadva

2. munkalap: Fizetés beérkezett

Ugyanezzel a módszerrel hozzon létre további munkalapokat a konyhai és a kiszállítási eseményekhez.

2. lépés: egységesítse az oszlopokat. Minden munkalapon ugyanazokat az oszlopneveket használja, azonos sorrendben. Ha egy attribútum nem alkalmazható, vegyen fel egy üres oszlopot. Például a Rendelés leadva munkalap is tartalmazhatja az összes oszlopot:

Ellenőrizze, hogy az értékek formátuma kompatibilis-e. Különösen ügyeljen arra, hogy az időbélyegek dátumként és időpontként szerepeljenek, ne csak időbélyegnek látszó szövegként.

3. lépés: egyesítse a munkalapokat. Hozzon létre egy új munkalapot Eseménynapló néven, majd másolja át az egyes tevékenységlapok eseménysorait. Csak egy fejlécsort használjon, és minden sorban egy esemény szerepeljen.

4. lépés: rendezze az adatokat ügy és időbélyeg szerint. Rendezze az egyesített adatokat először Case ID, majd Timestamp szerint növekvő sorrendbe. Így könnyebben áttekintheti az egyes ügyek eseménysorát. A rendezés nem javítja ki a pontatlan időbélyegeket, ezért mielőtt a sorrendre támaszkodna, ellenőrizze az azonos vagy váratlan időpontú eseményeket.

5. lépés: exportálja CSV-fájlba. Mentse az egyesített munkalapot process mininghez használható CSV-eseménynaplóként, majd nyissa meg az exportált fájlt, és ellenőrizze, hogy az oszlopfejlécek, az elválasztójelek, a dátumformátum és az üres értékek megfelelőek-e.

Tippek az Excel használatához:

• A rendelések munkalapjáról VLOOKUP vagy XLOOKUP függvénnyel adjon hozzá ügyadatokat, például az ügyfél nevét.
• Használjon egységes dátum- és időformátumot, például YYYY-MM-DD HH:MM:SS.
• Exportálás előtt ellenőrizze, vannak-e ismétlődő sorok.
• Az eredeti adatkinyerésről őrizzen meg egy változatlan másolatot, hogy visszakövethetőek legyenek a javítások.

2. módszer: összeállítás SQL-lel

Az SQL akkor jó választás, ha az adatok adatbázisban vannak, nagy mennyiségű adatot kell kinyernie, vagy a következő hónapban is ugyanazt a lekérdezést szeretné futtatni. Általában minden tevékenységhez egy SELECT tartozik, ezeket pedig a UNION ALL kapcsolja össze.

Így működik a UNION ALL. Több SELECT utasítás eredménysorait fűzi egymás alá. Minden utasításnak ugyanannyi oszlopot kell visszaadnia, azonos sorrendben és kompatibilis adattípusokkal. Az aliasoknak is egységesnek kell lenniük, hogy a végeredmény oszlopainak neve egyértelmű legyen.

A lekérdezés. Az alábbi példa a kitalált Pizza Palace tábláit használja. A lekérdezés átalakítása előtt ellenőrizze a saját táblái és mezői nevét, az időbélyegek jelentését és az SQL-dialektust.

-- 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;

A lekérdezés a rendelésazonosítót használja Case ID-ként, és mindegyik tevékenységhez ugyanazt a hét oszlopot adja vissza. A NULL értékek gondoskodnak arról, hogy az oszlopok szerkezete akkor is egységes maradjon, ha egy attribútum nem alkalmazható. A dátumszűrő és a sikeres fizetés feltétele csak példa: olyan szűrőket válasszon, amelyek illenek az elemzendő folyamathoz és időszakhoz.

A lekérdezés bővítése. Új tevékenység hozzáadásához:

1. Kiindulásként másoljon le egy SELECT blokkot.
2. Használja azt a forrástáblát, amely az eseményt rögzíti.
3. Válassza ki az esemény időbélyegét tartalmazó mezőt.
4. Adjon meg olyan tevékenységnevet, amely illeszkedik a többi sor elnevezéséhez.
5. Vegye fel a Case ID-t és a releváns attribútumokat.
6. Adjon hozzá az elemzéshez illő szűrőket.

Például a kézbesítési kísérletet így veheti fel, ha a rendszerében rendelkezésre állnak a megfelelő tábla és mezők:

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'

Ellenőrzések az eseménynapló elemzése előtt

Az eseménynapló elemzése előtt végezze el az alábbi ellenőrzéseket. Ezek a process mining eredményeit leginkább félrevezető adathibákat fedik le: az ismétlődő sorokat, a hiányzó időbélyegeket, a változó Case ID-ket és a tevékenységként félreértelmezett állapotmezőket.

1. Kezdje a kötelező oszlopokkal. Először készítsen egy kis eseménynaplót a Case ID, a Timestamp és az Activity mezőkkel. Csak ezután vegyen fel további eseményeket vagy attribútumokat.
2. Használjon állandó esetazonosítókat. Egy eset minden eseményénél ugyanazt az azonosítót használja. Ne válasszon olyan értéket, amely a folyamat során megváltozik.
3. Használjon következetes tevékenységneveket. Válasszon egyetlen elnevezést, például „Order Placed”, és ne váltogassa az „Order Created” és a „New Order” nevekkel.
4. Ellenőrizze az időbélyegeket. Győződjön meg róla, hogy az esemény időpontját jelölik, egységes időzónát használnak, és dátumként, illetve időpontként rendezhetők.
5. Ellenőrizze a duplikátumokat és a hiányzó értékeket. Vizsgálja meg az ismétlődő eseményeket, valamint azokat a sorokat, amelyekből hiányzik az esetazonosító, az időbélyeg vagy a tevékenység.
6. Dokumentálja az adatkinyerést. Jegyezze fel a forrástáblákat, a mezőket, a szűrőket, a kinyerés dátumát és a feltételezéseket. Így könnyebb lesz frissíteni és hibakeresni az eseménynaplót.
7. Körültekintően vegyen fel attribútumokat. Csak olyan mezőket vegyen fel, amelyek segítenek megválaszolni egy kérdést, és ellenőrizze, hogy az összekapcsolások nem sokszorozzák-e meg az eseménysorokat.

Hét gyakori adatproblémára, az ismétlődő eseményektől a hiányzó Case ID-kig, az oldal végén található GYIK ad választ. Az ETL process mininghez című útmutató pedig az ismétlődő adatkinyeréshez nyújt segítséget.

Mi a teendő, ha nem fér hozzá az adatokhoz?

Az eseménynapló elkészítéséhez nincs szüksége előre elkészített csatlakozóra. Először nézze meg, milyen adatokat tud exportálni a rendszeréből, és szerepel-e bennük a három kötelező mező.

1. Azonosítsa a folyamatot és a követni kívánt esetazonosítót.
2. Ellenőrizze, hogy a rendszerből exportálható-e az eseményelőzmény, az auditnapló vagy az időbélyeggel ellátott állapotváltozások listája.
3. Adatsablonnal rendelje hozzá az elérhető mezőket a Case ID, a Timestamp és az Activity oszlophoz.
4. Ha nem tud kész eseménytáblát exportálni, kérjen az adatokért felelős csapattól adatbázis-kinyerést vagy eseményenként egy sort tartalmazó jelentést.

A rendszerből exportált adatok több táblában lehetnek, vagy ugyanazt a mezőt eltérő néven jelölhetik. Az adatokat Excelben vagy SQL-lel egyesítheti és átnevezheti, ha közben megőrzi a mezők jelentését, és vissza tudja követni őket a forrásukig. A Honnan szerezhet adatot process mininghez? című cikk bemutatja, hol találhatók még felhasználható forrásadatok. A folyamatfejlesztési útmutatók pedig az 1–3. lépést már elvégzik az Ön rendszeréhez, folyamatspecifikus adatsablonnal.

Ha formátum-összehasonlításhoz további process mining eseménynapló-példát keres, az példa-eseménynaplókat és sablonokat tartalmazó gyűjtemény kész táblázatot is kínál. A eseménynapló-sablon oldalon megtalálja a kötelező és választható oszlopokat. Az első adatkészlet betöltésének menetét a Első adatkészletének betöltése útmutató mutatja be.

Töltse be az elkészített eseménynaplót

Ha elkészült az eseménynapló, töltse be a fájlt, és rendelje hozzá a három kötelező oszlopot. A ProcessMind közvetlenül beolvassa az Excel- és CSV-fájlokat, valamint az adatbázisból kinyert adatokat.

1. Töltse fel a fájlt, vagy válassza ki az adatbázisból kinyert adatokat.
2. Rendelje hozzá a Case ID, a Timestamp és az Activity oszlopot.
3. Ellenőrizze a további attribútumokat.
4. Hozza létre a folyamatnézetet, és ellenőrizze, hogy az esetek és az események sorrendje megfelel-e a valóságnak.

A ProcessMindben megtekintheti, hogyan rendelhetők az adatkészlet oszlopai a tevékenység, az ügy és az attribútum szerepéhez

A folyamatnézet segít észrevenni a hiányzó tevékenységeket, a váratlan eseménysorrendeket és a további vizsgálatot igénylő területeket. A forrásadatokat nem javítja ki, és a munkavégzés módját sem változtatja meg. Ha az első eredmény adathibát jelez, frissítse az adatkinyerést, majd töltse be újra. Az Első adatkészletének betöltése útmutató részletesen bemutatja a feltöltést és az oszlopok hozzárendelését.

Töltse be az imént elkészített eseménynaplót