Process Mining ile Süreç Analizi: Pratik Rehber
Dashboard'larınızı eyleme dönen içgörülere çevirin. Veriyi anlama, kalıp keşfi ve gerçek iyileştirme fırsatları için adım adım yaklaşım.
Neler Öğreneceksiniz
Bu rehberde sıfırdan bir process mining event log oluşturmayı öğreneceksiniz. Her event log’da mutlaka bulunması gereken üç temel kolonu ele alacak, gerçek bir örnek üzerinden ilerleyecek ve ilk event log’unuzu hem Excel hem de SQL kullanarak nasıl oluşturacağınızı göstereceğiz.
İlgili: süreç iyileştirme hakkında daha fazla bilgi edinin ve sisteminize uygun veri şablonlarını keşfedin. Ayrıca neden hazır connector’leri değil de basit veri şablonlarını tercih ettiğimizi anlatan yazımızı okuyun: why we skip out-of-the-box connectors.
Process mining event log, iş süreçlerinizde ne olup bittiğini kaydeden basit bir veri tablosudur. Bunu, sisteminizden geçen her case’in her adımını not eden bir günlük gibi düşünün. Process mining yazılımı bu günlüğü okur ve sürecinizin gerçekte nasıl işlediğini gösteren görsel diyagramlar üretir.
Her event log satırı için üç temel bilgi şarttır:
| Kolon | Anlamı | Örnek |
|---|---|---|
| Case ID | İlişkili event’leri aynı grupta toplayan benzersiz kimlik | Sipariş #12345 |
| Timestamp | Event’in gerçekleştiği zaman | 2025-01-15 09:30:00 |
| Activity | Ne olduğu | ”Sipariş Verildi” |
Hepsi bu. Yalnızca bu üç kolonla process mining yapmaya başlayabilirsiniz. Müşteri adı, sipariş tutarı veya çalışan ID’si gibi diğer her şey, analizi zenginleştiren isteğe bağlı attribute’lardır.
Detaya girmeden önce sık karıştırılan bir noktayı netleştirelim.
Bir aktivite, “Kargoya Verildi” veya “Ödeme Alındı” gibi bir eylem türüdür; bir kategori ya da etiket gibi düşünebilirsiniz.
Bir olay, o aktivitenin belirli bir gerçekleşmesidir. Sipariş #12345, 15 Ocak saat 14:30’da kargoya verildiyse bu bir olaydır.
Olay günlüğünüz (event log) olaylardan oluşur; ancak her olayın bir aktivite adı vardır. Pratikte bu terimler bazen birbirinin yerine kullanılır, sorun değil. Şunu unutmayın: aktiviteler “ne”yi, olaylar ise “kime, ne zaman oldu”yu anlatır.
Rehberi pratik kılmak için kurgusal bir sistem üzerinden gidelim. Çevrim içi sipariş sistemi olan yerel bir pizzeria Pizza Palace’ı yönettiğinizi düşünün. Müşteriler web sitesinden sipariş veriyor, ekip pizzaları hazırlıyor, kuryeler teslim ediyor.
Pizza Palace’ta sipariş sürecinin farklı bölümlerini takip eden birkaç veritabanı tablosu var:
Hedefiniz: Her siparişin, verilmesinden teslimine kadar tüm yolculuğunu gösteren bir event log oluşturmak.
Bir event log oluştururken iki tür event’le karşılaşırsınız:
Doğrudan event’ler sisteminizde açıkça kaydedilir. Biri butona tıklar ya da sistem bir işlemi loglar; timestamp veritabanında doğrudan bulunur.
Pizza Palace’tan örnekler:
orders tablosunda)payments tablosunda)delivery_assignments tablosunda)Türetilmiş olayların kendi zaman damgası yoktur; ancak diğer verilere bakarak ne zaman gerçekleştiğini anlayabilirsiniz.
Pizza Palace’tan örnekler:
delivery_assignments tablosundaki created_at alanı atamanın ne zaman yapıldığını gösterirTemel fark şu: Doğrudan olaylar açıkça kaydedilir; türetilmiş olaylar ise diğer veri alanlarını yorumlamayı gerektirir. İkisi de process mining için geçerli ve çok faydalıdır.
Veriyi çıkarmadan önce, hangi event’leri yakalamak istediğinizi planlayın. Pizza Palace için şu aktiviteleri izleyelim:
Her event için şunları belirleyin:
Eşleştirmemiz şöyle:
| Activity | Kaynak Tablo | Timestamp Alanı | Case ID Alanı |
|---|---|---|---|
| Sipariş Verildi | orders | created_at | id |
| Ödeme Alındı | payments | payment_time | order_id |
| Sipariş Mutfağa Gönderildi | kitchen_queue | queue_entry_time | order_id |
| Sipariş Hazır | kitchen_queue | completed_time | order_id |
| Kuryeye Atandı | delivery_assignments | assigned_at | order_id |
| Teslimat Tamamlandı | delivery_assignments | delivered_at | order_id |
Case ID, Timestamp ve Activity zorunludur; attribute’lar analizinizi çok daha güçlü kılar. Attribute’lar, bağlam sağlayan ek kolonlardır.
Case özellikleri, tüm case’i (sipariş) tanımlar ve o case’deki tüm event’lerde aynıdır:
Event özellikleri her event’e özeldir:
İpucu: Bazı özellikler belirli event’lere uymasa bile her satıra tüm özellikleri eklemenizde sakınca yok. Örneğin, “Order Placed” satırında “Driver Name” sütunu boş kalabilir. Bu yaklaşım, event log’unuzu process mining araçlarının sevdiği basit, düz tablo formatında tutar.
Nihai event log’unuz, her satırın tek bir event’i temsil ettiği tek bir tablo olmalı. Pizza Palace event log’umuz şöyle görünecek:
| Case ID | Timestamp | Activity | Müşteri | Sipariş Tutarı | Kurye | Ödeme Yöntemi |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Sipariş Verildi | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:30:15 | Ödeme Alındı | John Smith | 45.99 | Kredi Kartı | |
| 1001 | 2025-01-15 18:31:00 | Sipariş Mutfağa Gönderildi | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:45:00 | Sipariş Hazır | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:46:00 | Kuryeye Atandı | John Smith | 45.99 | Maria Garcia | |
| 1001 | 2025-01-15 19:05:00 | Teslimat Tamamlandı | John Smith | 45.99 | Maria Garcia | |
| 1002 | 2025-01-15 18:35:00 | Sipariş Verildi | Jane Doe | 28.50 | ||
| 1002 | 2025-01-15 18:35:20 | Ödeme Alındı | Jane Doe | 28.50 | PayPal | |
| … | … | … | … | … | … | … |
Case attribute’larının (Müşteri, Sipariş Tutarı) aynı case’deki her event için tekrarlandığına dikkat edin. Bu tekrar kasıtlıdır ve veriyle çalışmayı kolaylaştırır.
Verinizi Excel’e dışa aktarabiliyorsanız, event log’u elle de oluşturabilirsiniz. Bu yöntem küçük veri setleri ve öğrenme aşaması için idealdir.
Her aktivite türü için bir çalışma sayfası oluşturun:
Sayfa 1: Sipariş Alındı
| Case ID | Timestamp | Aktivite | Müşteri | Sipariş Tutarı |
|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Sipariş Alındı | John Smith | 45.99 |
| 1002 | 2025-01-15 18:35:00 | Sipariş Alındı | Jane Doe | 28.50 |
Sayfa 2: Ödeme Alındı
| Case ID | Timestamp | Aktivite | Müşteri | Sipariş Tutarı | Ödeme Yöntemi |
|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:15 | Ödeme Alındı | John Smith | 45.99 | Kredi Kartı |
| 1002 | 2025-01-15 18:35:20 | Ödeme Alındı | Jane Doe | 28.50 | PayPal |
Tüm sayfalarda aynı sırayla aynı sütunların bulunduğundan emin olun. Gerekirse boş sütunlar ekleyin:
Sayfa 1: Sipariş Alındı (güncellendi)
| Case ID | Timestamp | Aktivite | Müşteri | Sipariş Tutarı | Kurye | Ödeme Yöntemi |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Sipariş Alındı | John Smith | 45.99 |
Yeni bir “Event Log” sayfası oluşturun. Her aktivite sayfasındaki satırları kopyalayıp bu birleşik sayfaya art arda yapıştırın.
Tüm verilerinizi seçin ve şu şekilde sıralayın:
Bu işlem, her vaka içindeki olayları kronolojik sıraya koyar; böylece her siparişin yolculuğunu kolayca takip edebilirsiniz.
Birleşik sayfayı CSV olarak kaydedin. Bu format neredeyse tüm Process Mining araçlarıyla uyumludur.
Excel İpuçları:
Daha büyük veri setleri veya düzenli çekimler için SQL daha verimli ve tekrarlanabilir. Temel teknik, birden fazla sorguyu tek bir sonuç kümesinde birleştirmek için UNION ALL kullanmaktır.
UNION ALL, birden fazla SELECT ifadesinin sonuçlarını alt alta birleştirir. Her SELECT, nihai sonuçta bir satır kümesi oluşturur. Tüm SELECT’lerin aynı sayıda sütun üretmesi ve veri tiplerinin uyumlu olması gerekir.
Aşağıda Pizza Palace için bir event log oluşturan örnek bir SQL sorgusu yer alıyor:
-- 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;
Log’unuza daha fazla event eklemek için:
Örneğin, “Delivery Attempted” event’i eklemek için:
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'
Önce üç zorunlu kolona ve birkaç kilit aktiviteye odaklanın. Basit bir event log’u oluşturup bir process mining aracına başarıyla yükledikten sonra, geri dönüp daha fazla event ve attribute ekleyebilirsiniz.
Analize başlamadan önce event log’unuzda sık görülen sorunları kontrol edin:
Şunları not edin:
Bu notlar, event log’u daha sonra güncellemeniz ya da sorun gidermeniz gerektiğinde çok işinize yarar.
Aktivite adlarını tüm çıkarmalarda tutarlı kullanın:
Veri birden çok sistemden ya da bölgeden geliyorsa, tüm timestamp’lerin aynı zaman diliminde olduğundan emin olun. Tutarlılık için UTC genelde en güvenli tercihtir.
Bazen aynı event birden çok tabloda loglanır. Örneğin, hem sipariş sisteminiz hem de ERP’niz siparişin gönderildiği zamanı kaydediyor olabilir.
Çözüm: “Source of truth” olarak tek bir kaynağı seçin ve yalnızca onu kullanın. Bu tercihi belgeleyin.

Bazı event’lerin kendi timestamp’i olmayabilir. Örneğin, “Order Approved” sadece boolean bir flag olabilir.
Çözüm: İlgili timestamp’leri arayın. Örneğin bir “approved_at” alanı olabilir ya da “approved” flag’i değiştiğinde oluşan “modified_at” timestamp’ini kullanabilirsiniz.
Milyonlarca event varsa, veri çıkarma sırasında sorgular yavaşlayabilir veya çökebilir.
Çözüm:
Event log’unuzu CSV dosyası olarak veya veritabanı çıktısı şeklinde hazırladıysanız, artık bir process mining aracına yüklemeye hazırsınız. Çoğu araç benzer adımları izler:
ProcessMind gibi modern process mining araçları bu süreci oldukça kolaylaştırır. Event log’unuzu yükleyin; araç sürecinizi otomatik olarak görselleştirerek darboğazları, varyasyonları ve iyileştirme fırsatlarını ortaya çıkarır.
Bir process mining event log’u oluşturmak için özel araçlara veya ileri teknik bilgiye gerek yok. Özünde yapmanız gereken, verinizi Case ID, Timestamp ve Activity’den oluşan üç temel kolona sahip tek bir tabloya düzenlemek.
Küçük veri setlerinde Excel’i, daha büyük ve düzenli çekimlerde SQL’i tercih edebilirsiniz; prensipler değişmez:
En zor kısım veriyi teknik olarak çekmek değil; süreçte hangi event’lerin önemli olduğunu kavramaktır. Önce bariz adımlarla başlayın (sipariş verildi, sipariş tamamlandı) ve process mining aracınızın sunduğu içgörülerle birlikte zamanla ayrıntı ekleyin.
Daha derine inmek ister misiniz? sürekli süreç iyileştirme sayfalarımızı inceleyin. Satın Almadan Ödemeye (Purchase to Pay), Siparişten Tahsilata (Order to Cash) ve Borç Hesapları (Accounts Payable) gibi yaygın süreçler için aktiviteler ve veri gereksinimlerine dair ayrıntıları bulacaksınız. SAP, Oracle ve Microsoft Dynamics gibi yaygın sistemler için veri şablonları da mevcut; event log oluşturma yolculuğunuza hızlı bir başlangıç yapın.
Bugün Başlayın
Mükemmel event log’u beklemeyin. Elinizdekilerle başlayın, oluşturduğunuz süreç haritalarından öğrenin ve tekrarlayın. Sadece temel aktiviteleri içeren basit bir event log bile süreçlerinizin gerçekte nasıl işlediğine dair şaşırtıcı içgörüler sunabilir.
Dashboard'larınızı eyleme dönen içgörülere çevirin. Veriyi anlama, kalıp keşfi ve gerçek iyileştirme fırsatları için adım adım yaklaşım.
Hazır bağlayıcılar kolaylık vaat eder ama çoğu kez karmaşıklık, gecikme ve bağımlılık getirir. Bizim basit yolumuz: veri şablonları.
Veriyle süreç iyileştirme ve iş dönüşümünün etkili yollarını anlatan kapsamlı rehber.
Celonis ve ProcessMind process mining’i 2025 için karşılaştırın. İşinize en uygun çözümü keşfedin.
Anında erişim, kredi kartı yok, bekleme yok. Mapping, mining ve simulation'ın birlikte nasıl daha akıllı, hızlı kararlar aldığını gör.
Tüm özellikleri keşfet, derin içgörüler kazan ve operasyonlarını ilk günden itibaren kolayca yönet.
Ücretsiz denemene hemen başla, Process Intelligence'ın tam gücünü aç ve 30 günden kısa sürede gerçek iyileşmeleri gör!