Process Mining ile Süreç Analizi: Pratik Rehber
Dashboard'larızı somut stratejik bilgilere dönüştürün. 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 lognuzu 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 sisteminiz için Veri Şablonu’lerine göz atın. Ayrıca, basit Veri Şablonu’lerini tercih ettiğimiz için hazır out-of-the-box connector’ları neden tercih etmediğimizi okuyun.
Process Mining Event Log, iş sürecinizde neler olduğunu kaydeden basit bir veri tablosudur. Sisteminizden geçen her vakanın attığı her adımı takip eden bir günlük gibi düşünebilirsiniz. Process Mining yazılımı bu günlüğü okur ve sürecinizin gerçekten nasıl işlediğini gösteren görsel diyagramlar üretir.
Her Event Log satırı için üç temel bilgi gerekir:
| Sütun | Ne anlama gelir | Örnek |
|---|---|---|
| Case ID | İlgili olayları bir arada toplayan benzersiz tanımlayıcı | Sipariş #1, 2, 3, 45 |
| zaman damgası (zaman damgası) | Olayın gerçekleştiği zaman | 2025-01-15 09:30:00 |
| Activity | Ne olduğu | ”Sipariş Verildi” |
Hepsi bu. Yalnızca bu üç sütunla Process Mining yapmaya başlayabilirsiniz. Müşteri adları, sipariş tutarları veya çalışan ID’leri gibi diğer bilgiler ise analizinizi zenginleştiren, “öznitelik” dediğimiz isteğe bağlı ögelerdir.
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ş #1, 2, 3, 45, 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; zaman damgası (zaman damgası) veritabanında doğrudan bulunur.
Pizza Palace’tan örnekler:
orders tablosunda)payments tablosunda)delivery_assignments tablosunda)Türetilmiş olayların kendi zaman damgası (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 olayları 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 | zaman damgası (zaman damgası) 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, zaman damgası (zaman damgası) ve Activity zorunludur; nitelik’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 lognuzu process mining araçlarının sevdiği basit, düz tablo formatında tutar.
Nihai event lognuz, her satırın tek bir event’i temsil ettiği tek bir tablo olmalı. Pizza Palace event logmuz şöyle görünecek:
| Case ID | zaman damgası (zaman damgası) | 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 nitelik’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 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ş Verildi
| Case ID | zaman damgası (zaman damgası) | 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 | zaman damgası (zaman damgası) | 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ş Verildi (güncellendi)
| Case ID | zaman damgası (zaman damgası) | 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 tanımlayıcı
o.created_at AS zaman damgası (zaman damgası), -- When the order was placed
'Order Placed' AS activity, -- The activity name (sabit tanımlanmış)
o.customer_name AS customer, -- Case nitelik: who ordered
o.total_amount AS order_value, -- Case nitelik: 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 zaman damgası (zaman damgası),
'Payment Received' AS activity,
o.customer_name AS customer, -- Join to get case niteliks
o.total_amount AS order_value,
NULL AS driver,
p.payment_method AS payment_method -- Event-specific nitelik
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 zaman damgası (zaman damgası),
'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 zaman damgası (zaman damgası) 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 zaman damgası (zaman damgası), -- Different zaman damgası (zaman damgası) 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 zaman damgası (zaman damgası),
'Assigned to Driver' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
d.driver_name AS driver, -- Event-specific nitelik
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 zaman damgası (zaman damgası) field)
-- This captures when the order was delivered to the customer
SELECT
d.order_id AS case_id,
d.delivered_at AS zaman damgası (zaman damgası),
'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, zaman damgası (zaman damgası);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 zaman damgası (zaman damgası),
'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 oluşturup bir process mining aracına başarıyla yükledikten sonra, geri dönüp daha fazla event ve nitelik ekleyebilirsiniz.
Analize başlamadan önce event lognuzda sık görülen sorunları kontrol edin:
Şu konularda notlar tutun:
Bu dokümantasyon, ileride Event Log verinizi güncellemeniz veya bir sorunu gidermeniz gerektiğinde paha biçilemez bir kaynak olacaktır.
Aktivite adlarını tüm çıkarmalarda tutarlı kullanın:
Veri birden çok sistemden ya da bölgeden geliyorsa, tüm zaman damgası (zaman damgası)‘lerin aynı zaman diliminde olduğundan emin olun. Tutarlılık için UTC genelde en güvenli tercihtir.
Bazı olayların kendi zaman damgası (zaman damgası)‘i olmayabilir. Örneğin, “Order Approved” sadece boolean bir flag olabilir.
Çözüm: İlgili zaman damgası (zaman damgası)‘leri arayın. Örneğin bir “approved_at” alanı olabilir ya da “approved” flag’i değiştiğinde oluşan “modified_at” zaman damgası (zaman damgası)‘ini kullanabilirsiniz.
Milyonlarca event varsa, veri çıkarma sırasında sorgular yavaşlayabilir veya çökebilir.
Çözüm:
Event Log verinizi bir CSV dosyası veya veri tabanı çıktısı olarak hazırladıktan sonra, bir Process Mining aracına yüklemeye hazırsınız demektir. Çoğu araç benzer bir yol izler:
ProcessMind gibi modern Process Mining araçları bu süreci oldukça kolaylaştırır. Event Log verilerinizi yüklediğiniz anda araç süreçlerinizi otomatik olarak görselleştirir; darboğazları (bottlenecks), varyasyonları ve maliyetleri düşürüp operasyonel süreçleri optimize etmenizi sağlayacak iyileştirme fırsatlarını anında ortaya çıkarır.
Bir Process Mining Event Log oluşturmak için özel araçlara veya derin teknik bilgiye ihtiyacınız yok. İşin özünde, verilerinizi üç temel sütun içeren bir tablo halinde düzenliyorsunuz: Case ID, zaman damgası (zaman damgası) ve Activity.
Küçük veri setleri için Excel, daha büyük ve karmaşık veri çekme işlemleri için SQL kullanıyor olsanız da prensipler aynıdır:
İşin en zor kısmı teknik veri çekme süreci değil, hangi olayların önemli olduğunu anlayacak kadar iş süreçlerinize hakim olmaktır. Belirgin olaylarla başlayın (sipariş verildi, sipariş tamamlandı) ve Process Mining aracınızın sunduğu stratejik bilgileri keşfettikçe daha fazla ayrıntı ekleyin.
Daha derine inmeye hazır mısınız? Sürekli süreç iyileştirme sayfalarımızı inceleyerek Satın Almadan Ödemeye (Satın Almadan Ödemeye) , Siparişten Tahsilata (Order to Cash) ve Borç Hesapları (Accounts Payable) gibi popüler süreçler için aktiviteler ve veri gereksinimleri hakkında detaylı bilgilere ulaşabilirsiniz. Bu kaynaklar SAP, Oracle ve Microsoft Dynamics gibi yaygın sistemler için veri şablonları içererek Event Log oluşturma yolculuğunuzda size hız kazandıracaktır.
Bugün Başlayın
Mükemmel bir Event Log için beklemeyin. Elinizdeki verilerle başlayın, oluşturduğunuz süreç haritalarından ders çıkarın ve sistemi sürekli geliştirin. Temel aktiviteleri içeren basit bir Event Log bile süreçlerinizin gerçekte nasıl işlediğine dair şaşırtıcı stratejik bilgiler sunabilir.
Dashboard'larızı somut stratejik bilgilere dönüştürün. 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 detaylı 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ı gerekmez, bekleme yok. Mapping, mining ve simülasyonun birlikte nasıl daha akıllı, hızlı kararlar aldığını görün.
Tüm özellikleri keşfedin, detaylı stratejik bilgiler edininın ve operasyonlarını ilk günden itibaren etkin bir şekilde yönetinin.
Ücretsiz denemenize hemen başlayın, Process Intelligence'ın tüm potansiyelini keşfedin ve 30 günden kısa sürede gerçek iyileşmeleri görün!
Site deneyiminizi iyileştirmek, içerikleri kişiselleştirmek ve site trafiğini analiz etmek için çerezler kullanıyoruz. "Tümünü Kabul Et"e tıklayarak onay verirsiniz.