Process Mining için olay günlüğü nasıl oluşturulur

Process Mining için bir Event Log oluşturmak, vaka kimliğine göre gruplandırılmış zaman damgalı etkinlikleri tek bir tabloda toplamakla başlar. Bu rehberde, hayalî bir restoran sipariş sürecini örnek alarak sistem verilerinden bu tabloyu nasıl hazırlayacağınızı gösteriyoruz. İki yöntemle ilerleyin: Excel’de birkaç satır oluşturun ya da etkinlikleri UNION ALL ile tek bir SQL sorgusunda bir araya getirin. Çalışmanızı adım adım tamamlanmış örnek Event Log ile karşılaştırın.

Process Mining Event Logu: gereken üç sütun

Event Log, bir süreçte neler olduğunu yapılandırılmış biçimde kaydeder. Her satır, sipariş verilmesi veya ödemenin alınması gibi tek bir etkinliği gösterir. Vaka kimliği ilişkili etkinlikleri birbirine bağlar, zaman damgası her etkinliğin ne zaman gerçekleştiğini belirtir. Bu bilgiler bir araya geldiğinde araç, vakaların süreçte nasıl ilerlediğini yeniden oluşturabilir.

Etkinlik bir türü, olay ise gerçekleşen tek bir örneği anlatır. Etkinlik, “Sipariş gönderildi” gibi bir eylem türüdür. Olay ise bunun belirli bir zamanda gerçekleşmesidir: 12345 numaralı sipariş 15 Ocak günü saat 14.30’da gönderildi. Günlüğünüz olayları kaydeder ve her olay bir etkinlik adı taşır. Bu iki sözcük günlük kullanımda birbirinin yerine geçse de veri hazırlarken aralarındaki fark önemlidir. Etkinlik ne olduğunu, olay ise bunun hangi vakada ve ne zaman gerçekleştiğini belirtir.

Temel bir Process Mining Event Logunda üç sütun bulunmalıdır:

İlerlemeden önce bu üç alanı kontrol edin:

Bu üç alan temel gereksinimdir. Bunlardan biri eksik veya tutarsızsa süreç görünümü iş akışının sırasını yanlış gösterir. Diğer her şey isteğe bağlıdır: Process Mining araçlarının okuyabildiği bir Event Log, vakaları ve olayları içeren tek bir tablodur. Kullanılabilir bir iş süreci Event Logu için gereken üç sütun da değişmez. Desteklenen biçimler ve hazırlık adımları için Process Mining veri dokümantasyonuna göz atın.

Uygulamalı örnek: Pizza Palace sipariş sistemi

Adımları somutlaştırmak için Pizza Palace adında hayalî bir restoranı ele alalım. Müşteriler internetten sipariş verir, çalışanlar yemekleri hazırlar ve kuryeler teslim eder. Örnekte müşteri verisi bulunmuyor.

Sistemin bilgileri şu tablolarda sakladığını varsayalım:

• orders: sipariş kimliği, müşteri ve sipariş zamanı
• order_items: her siparişteki pizzalar, yan ürünler ve içecekler
• kitchen_queue: siparişin mutfağa ne zaman girdiği ve mutfaktan ne zaman çıktığı
• delivery_assignments: kurye atamaları ve teslimat takibi
• payments: ödeme işlem kayıtları

Amaç, her siparişi verildiği andan teslimata kadar izleyen tek bir Event Log oluşturmaktır. Vaka kimliği olarak sipariş kimliğini kullanacağız. İlgili her zaman damgası ve eylem ayrı bir satıra dönüşecek. Process Mining için örnek Event Log olarak Pizza Palace örnek günlüğünü indirin ve sütunlarını kendi veri aktarımınızla karşılaştırın.

Verileri aktarmadan önce hangi etkinlikleri dahil edeceğinize karar verin. Pizza Palace sipariş süreci altı adımdan oluşuyor:

1. Sipariş verildi: Müşteri siparişi gönderir.
2. Ödeme alındı: Ödeme başarıyla tamamlanır.
3. Sipariş mutfağa gönderildi: Sipariş hazırlık kuyruğuna girer.
4. Sipariş hazır: Mutfak siparişin tamamlandığını işaretler.
5. Kuryeye atandı: Sipariş için bir kurye atanır.
6. Teslimat tamamlandı: Sipariş teslim edilir.

Her etkinlik için kaynak tabloyu, zaman damgası alanını ve vaka kimliği alanını belirleyin. Vaka kimliğinin olayı doğru siparişle ilişkilendirdiğini doğrulayın.

Doğrudan kaydedilen olaylarla çıkarımla belirlenenleri ayırın. Doğrudan kaydedilen bir olayın kaynak sistemde açık bir kaydı ve zaman damgası vardır: Sipariş verildi olayı orders satırındaki zaman damgasından, Ödeme alındı olayı payments tablosundan, Teslimat tamamlandı olayı ise delivery_assignments tablosundan alınır. Zaman damgası analiz etmek istediğiniz olayı gösterdiği sürece bu kayıtları aktarmak genellikle kolaydır.

Çıkarımla belirlenen olayın kendine ait bir kaydı yoktur; bu nedenle zamanı başka bir alandan belirlenir. Kuryeye atandı olayı yalnızca teslimat atamasının oluşturulma zamanı olarak, Sipariş hazır olayıysa mutfak kuyruğu durumunun “tamamlandı” olarak değiştiği an biçiminde kaydedilmiş olabilir. Çıkarımla belirlenen olaylar işe yarayabilir, ancak bunları nasıl belirlediğinizi belgeleyin. Durum değişikliği veya kayıt oluşturma zamanı, etkinlik adının düşündürdüğü anlamı tam olarak karşılamayabilir. Bu alanı olayın zaman damgası olarak kullanmadan önce kaynak sistemi bilen kişilere ne ifade ettiğini sorun.

Bu haritalama bir plandır, her alanın uygun olduğunun kanıtı değildir. Zaman damgalarının dolu olup olmadığını ve her tablonun sipariş kimliğiyle birleştirilirken yinelenen satırlar oluşturup oluşturmadığını kontrol edin.

Vaka ve olay öznitelikleri

Öznitelikler analizinize bağlam katar. Vaka kimliği, zaman damgası ve etkinlik sütunlarının dışındaki sütunlardır. Yalnızca anlamları açıksa ve doğru vaka ya da olayla ilişkilendirilebiliyorsa eklemeye değerler.

Vaka öznitelikleri vakanın tamamını tanımlar ve genellikle vakadaki tüm olaylarda aynı kalır: müşteri adı, sipariş toplamı, teslimat adresi ve sipariş edilen ürün sayısı. Düz bir Event Logda bu değeri vakaya ait her satırda yinelersiniz. Böylece daha sonra vaka düzeyindeki bilgileri kullanarak olayları filtreleyebilir veya karşılaştırabilirsiniz.

Olay öznitelikleri tek bir olayı tanımlar: teslimat olayındaki kurye, ödeme olayındaki ödeme yöntemi veya mutfak olayındaki mutfak istasyonu gibi. Bu tür bir sütun her satıra uygulanmaz. Uygulanmadığı satırları boş bırakın, ancak her satırın yapısını korumak için sütunu tabloda tutun.

Tamamladığınız Event Log, her satırda tek bir olay bulunan düz bir tablo olmalıdır. Pizza Palace günlüğü şöyle görünür:

Aynı vakadaki her olay satırında müşteri ve sipariş tutarı tekrarlanır. Bu tekrar bilerek yapılır: günlüğü Process Mining araçlarının okuyabileceği basit bir tabloda tutar.

Yöntem 1: Excel’de oluşturun

Excel, küçük bir veri aktarımı veya ilk deneme için uygundur. Her etkinlik türünü dışa aktarın, sütunları standartlaştırın ve satırları tek bir sayfada birleştirin. Pizza Palace verileriyle aşağıdaki beş adım yaklaşık bir saat sürer.

1. adım: her etkinlik türünü ayrı bir sayfaya aktarın. Her etkinlik türü için bir çalışma sayfası oluşturun. Örneğin:

Sayfa 1: Sipariş verildi

Sayfa 2: Ödeme alındı

Aynı yöntemi kullanarak mutfak ve teslimat etkinlikleri için ek sayfalar oluşturun.

2. adım: sütunları standartlaştırın. Her sayfada aynı sütun adlarını aynı sırayla kullanın ve bir öznitelik uygulanmıyorsa boş sütun ekleyin. Örneğin Sipariş verildi sayfasına tüm sütunları ekleyebilirsiniz:

Değerlerin uyumlu biçimler kullandığını kontrol edin. Özellikle zaman damgalarının yalnızca zaman damgasına benzeyen metinler olarak değil, tarih ve saat biçiminde saklandığından emin olun.

3. adım: sayfaları birleştirin. Event Log adında yeni bir sayfa oluşturun ve her etkinlik sayfasındaki olay satırlarını buraya kopyalayın. Tek bir başlık satırı kullanın ve her satıra bir olay ekleyin.

4. adım: vaka kimliğine ve zaman damgasına göre sıralayın. Birleştirdiğiniz verileri önce vaka kimliğine, ardından zaman damgasına göre artan sırada sıralayın. Böylece her vakanın sırasını incelemek kolaylaşır. Sıralama, hatalı zaman damgalarını düzeltmez. Sıralamaya güvenmeden önce aynı veya beklenmedik saatlere sahip olayları kontrol edin.

5. adım: CSV olarak dışa aktarın. Birleştirdiğiniz sayfayı, aracınızın okuyabileceği Process Mining Event Logu CSV dosyası olarak kaydedin. Başlıkların, ayırıcıların, tarih biçiminin ve boş değerlerin beklendiği gibi göründüğünü doğrulamak için dışa aktarılan dosyayı bir kez açın.

Excel ipuçları:

• Müşteri adı gibi vaka özniteliklerini orders sayfasından eklemek için VLOOKUP veya XLOOKUP kullanın.
• YYYY-MM-DD HH:MM:SS gibi tutarlı bir tarih ve saat biçimi seçin.
• Dışa aktarmadan önce yinelenen satırları kontrol edin.
• Düzeltmeleri kaynağına kadar izleyebilmek için özgün veri aktarımlarının değişmemiş bir kopyasını saklayın.

Yöntem 2: SQL ile oluşturun

Verileriniz bir veritabanındaysa, aktarım büyükse veya aynı aktarımı gelecek ay yeniden çalıştırmanız gerekiyorsa SQL kullanmak işinizi kolaylaştırır. Genellikle her etkinlik için bir SELECT yazılır, ardından sonuçlar UNION ALL ile birleştirilir.

UNION ALL nasıl çalışır? Birden fazla SELECT ifadesinin döndürdüğü satırları bir araya getirir. Her ifade aynı sayıda sütunu aynı sırayla ve uyumlu veri türleriyle döndürmelidir. Son sütunların anlaşılır adlar taşıması için takma adlar da tutarlı olmalıdır.

Sorgu. Aşağıdaki örnekte hayalî Pizza Palace tabloları kullanılıyor. Uyarlamadan önce kendi tablo ve alan adlarınızı, zaman damgalarının ne anlama geldiğini ve SQL lehçenizi kontrol edin.

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

Sorgu, sipariş kimliğini vaka kimliği olarak kullanır ve her etkinlik için aynı yedi sütunu döndürür. Bir öznitelik uygulanmadığında sütun yapısını korumak için NULL değerleri kullanılır. Tarih filtresi ve başarılı ödeme koşulu yalnızca örnek olarak verilmiştir. Analiz etmek istediğiniz sürece ve döneme uygun filtreleri seçin.

Sorguyu genişletme. Yeni bir etkinlik eklemek için:

1. Başlangıç noktası olarak bir SELECT bloğunu kopyalayın.
2. Olayı kaydeden kaynak tabloyu kullanın.
3. Zaman damgasını temsil eden alanı seçin.
4. Diğer satırlarla tutarlı bir etkinlik adı belirleyin.
5. Vaka kimliğini ve ilgili öznitelikleri ekleyin.
6. Analizinize uygun filtreler ekleyin.

Örneğin, sisteminizde ilgili tablo ve alanlar varsa teslimat girişimini şu şekilde ekleyebilirsiniz:

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'

Günlüğü analiz etmeden önce yapmanız gereken kontroller

Günlüğü analiz etmeden önce bu kontrolleri yapın. Böylece Process Mining sonuçlarını en çok yanıltan Event Log sorunlarını ele alırsınız: yinelenen kayıtlar, eksik zaman damgaları, tutarsız vaka kimlikleri ve etkinlik sanılan durum alanları.

1. Zorunlu sütunlarla başlayın. Daha fazla olay veya öznitelik eklemeden önce vaka kimliği, zaman damgası ve etkinlik sütunlarını içeren küçük bir günlük oluşturun.
2. Kararlı vaka kimlikleri kullanın. Aynı vakaya ait her olayda aynı tanımlayıcı kullanılmalıdır. Süreç boyunca değişen bir değeri kullanmayın.
3. Etkinlik adlarını tutarlı kullanın. “Sipariş verildi” gibi tek bir ad seçin; bunu “Sipariş oluşturuldu” ve “Yeni sipariş” ifadeleriyle karıştırmayın.
4. Zaman damgalarını kontrol edin. Olayın gerçekleştiği zamanı gösterdiklerini, aynı saat dilimini kullandıklarını ve tarih-saat olarak sıralanabildiklerini doğrulayın.
5. Yinelenen ve eksik değerleri inceleyin. Yinelenen olayları ve vaka kimliği, zaman damgası ya da etkinlik alanı eksik satırları araştırın.
6. Veri aktarımınızı belgeleyin. Kaynak tabloları, alanları, filtreleri, aktarım tarihini ve varsayımları kaydedin. Bu bilgiler günlüğü güncellemeyi ve sorun gidermeyi kolaylaştırır.
7. Öznitelikleri dikkatle ekleyin. Bir soruyu yanıtlamaya yardımcı olan alanları dahil edin ve birleştirmelerin olay satırlarını çoğaltmadığını doğrulayın.

Yinelenen olaylardan eksik vaka kimliklerine kadar yaygın yedi veri sorununun yanıtlarını bu sayfanın sonundaki SSS bölümünde bulabilirsiniz. Process Mining için ETL rehberi, aynı çalışmanın düzenli veri aktarımlarına yönelik sürümünü ele alıyor.

Veri elinizde yoksa ne yapabilirsiniz?

Event Log hazırlamak için önceden oluşturulmuş bir bağlayıcıya ihtiyacınız yok. Önce sisteminizin hangi verileri dışa aktarabildiğini ve gerekli üç alanı sağlayıp sağlamadığını kontrol edin.

1. Süreci ve izlemek istediğiniz vaka kimliğini belirleyin.
2. Sistemin etkinlik geçmişini, denetim kayıtlarını veya zaman damgalı durum değişikliklerini dışa aktarıp aktaramadığını kontrol edin.
3. Mevcut alanları vaka kimliği, zaman damgası ve etkinlik alanlarıyla eşleştirmek için bir veri Templatei kullanın.
4. Hazır bir olay tablosunu dışa aktaramıyorsanız veri ekibinizden veritabanı aktarımı veya her satırda bir olay bulunan bir rapor isteyin.

Sistemden alınan dışa aktarım birden fazla tablo içerebilir veya aynı alan için farklı adlar kullanabilir. Her alanın anlamını koruyup kaynağına kadar izleyebildiğiniz sürece verileri Excel ya da SQL ile birleştirip yeniden adlandırabilirsiniz. Process Mining verilerini nereden bulabilirsiniz rehberi, kullanılabilir kaynak verilerin saklandığı diğer yerleri anlatıyor. Süreç iyileştirme rehberleri ise sisteminize özel olarak ilk üç adımı tamamladı ve her süreç için bir veri Templatei hazırladı.

Biçimleri karşılaştırmak için başka bir Process Mining Event Logu örneği arıyorsanız örnek günlük dosyaları ve Templateler koleksiyonunda kullanıma hazır bir elektronik tablo bulabilirsiniz. Template Event Log sayfasında zorunlu ve isteğe bağlı sütunlar listeleniyor. İlk Veri Seti’ni yükleme adımlarını görmek için ilk Veri Seti’nizi yükleyin.

Oluşturduğunuz günlüğü yükleyin

Günlük hazır olduğunda dosyayı yükleyin ve zorunlu üç sütununu eşleştirin. ProcessMind, Excel ve CSV dosyalarını ve veritabanı aktarımlarını doğrudan okuyabilir.

1. Dosyanızı yükleyin veya veritabanı aktarımınızı seçin.
2. Vaka kimliği, zaman damgası ve etkinlik sütunlarını eşleştirin.
3. Diğer öznitelikleri inceleyin.
4. Süreç görünümünü oluşturun ve vakaların ve olayların sırasının mantıklı olup olmadığını kontrol edin.

ProcessMind’de veri seti sütunlarının etkinlik, vaka ve öznitelik rollerine eşlenmesini görüntüleyin

Süreç görünümü; eksik etkinlikleri, beklenmedik sıraları ve araştırmanız gereken alanları fark etmenize yardımcı olabilir. Kaynak verileri düzeltmez veya işin nasıl yapıldığını değiştirmez. İlk sonuç bir veri sorununu ortaya çıkarırsa aktarımı güncelleyip yeniden yükleyin. İlk Veri Seti’nizi yükleyin rehberi, yükleme ve haritalama adımlarını ayrıntılı biçimde anlatıyor.

Az önce oluşturduğunuz günlüğü yükleyin