Process mining nedir
Process mining, bilgi sistemlerinin ürettiği olay günlüklerinden (event log) sürecin gerçek akışını otomatik olarak çıkaran yöntemdir. Süreç modellemenin veriye dayalı karşılığıdır.
BPMN modeli genellikle bir toplantı masasında, sürece dahil olan kişilerin anlattıkları üzerinden çizilir. Herkes kendi gördüğü kadarını aktarır ve ortaya çıkan model süreci büyük ölçüde olması gerektiği gibi gösterir. Process mining ise anlatılana değil sistemin kaydettiğine bakar; istisnalar, geri dönüşler ve atlanan adımlar dahil olmak üzere ne olduysa onu çıkarır.
Bu yüzden iki yöntem birbirinin rakibi değil, birbirini doğrulayan bir çifttir. Elinde ikisi de varsa aradaki fark, üzerinde çalışılacak hazır bir bulgu listesi haline gelir.
Olay günlüğü
Process mining'in tek girdisi var ve şaşırtıcı derecede basit. Üç zorunlu sütun:
| Sütun | Anlamı | Kargo örneği |
|---|---|---|
| Vaka kimliği (case ID) | Süreçten geçen nesne | Gönderi takip numarası |
| Faaliyet (activity) | Ne yapıldı | Kabul edildi, tartıldı, ayrıştırıldı, sevk edildi, teslim edildi |
| Zaman damgası (timestamp) | Ne zaman | 2026-03-14 08:42:17 |
Bu üç sütun zorunludur; kaynak, lokasyon veya tutar gibi ek alanlar analizi zenginleştirir ama olmadan da çalışılabilir. Kargo operasyonunun bu noktada belirgin bir avantajı var: barkod okutma zaten bir olay günlüğü üretiyor, dolayısıyla ayrıca bir veri toplama sistemi kurmaya gerek kalmıyor. Veri çoğu kuruluşta yıllardır birikmiş halde duruyor, yalnızca bu gözle bakılmamış oluyor.
Üç tür analiz
| Tür | Sorusu | Girdi | Çıktı |
|---|---|---|---|
| Keşif (discovery) | Süreç gerçekte nasıl akıyor? | Sadece olay günlüğü | Otomatik üretilmiş süreç modeli |
| Uygunluk (conformance) | Gerçek akış, tanımlı sürece uyuyor mu? | Günlük + referans model | Sapma listesi ve uygunluk skoru |
| Geliştirme (enhancement) | Modeli veriyle zenginleştir | Günlük + model | Süre, maliyet, darboğaz bilgisi eklenmiş model |
Çalışmalar genellikle bu sırayı izler: önce keşifle sürecin gerçekte nasıl aktığı çıkarılır, ardından uygunluk analiziyle tanımlı süreçten ne kadar sapıldığı ölçülür, en son geliştirme adımında sürelerin ve maliyetlerin nerede biriktiğine bakılır.
Varyant analizi
Varyant, bir vakanın izlediği benzersiz faaliyet dizisidir. Aynı sırayı izleyen tüm vakalar aynı varyanta düşer.
Process mining'in en hızlı sonuç veren çıktısı budur. Yüz binlerce vaka genellikle birkaç düzine varyanta iniyor ve bunların yalnızca birkaçı toplamın büyük kısmını oluşturuyor. Geriye kalan uzun kuyruk ise istisna yönetiminin nerede yapıldığını, daha doğrusu nerede yapılamadığını gösteriyor.
Çözümlü örnek
Gönderi akışı — 1 aylık olay günlüğü
486.200 vaka (gönderi), 3,84 milyon olay, 9 farklı faaliyet. Keşif analizi 147 varyant buldu.
| # | Varyant | Vaka | Pay % | Kümülatif % | Ort. süre |
|---|---|---|---|---|---|
| 1 | Standart akış (9 adım, geri dönüşsüz) | 368.512 | 75,80 | 75,80 | 1,48 gün |
| 2 | Standart + "adres doğrulama" tekrarı | 48.126 | 9,90 | 85,70 | 2,91 gün |
| 3 | Standart + ikinci teslim denemesi | 31.603 | 6,50 | 96,20 | 3,64 gün |
| 4 | Aktarma merkezine ikinci kez giriş | 14.586 | 3,00 | 99,20 | 4,12 gün |
| 5–147 | Diğer 143 varyant | 23.373 | 4,81 | 100,00 | 5,80 gün |
Kalan 143 varyant = 23.373 vaka ⇒ %4,81
147 varyantın 4'ü vakaların %95,2'sini kapsıyor
Üç bulgu
1. Geri dönüşler süreyi ikiye katlıyor. Standart akış 1,48 gün; adres doğrulama tekrarı olan akış 2,91 gün.
Etkilenen vaka = 48.126
Toplam ek süre = 48.126 × 1,43 = 68.820 gün (aylık)
Bu, SIPOC örneğinde bulduğumuz adres girdi hatasının (%3,80) uçtan uca etkisidir. Orada girdi kalitesi sorunu olarak görünen şey, burada ölçülmüş bir süre kaybına dönüşüyor.
2. Uzun kuyruk küçük ama pahalı. 143 varyant vakaların yalnızca %4,81'i ama ortalama süreleri 5,80 gün — standart akışın 3,9 katı. Bu vakalar aynı zamanda manuel müdahale gerektirdiği için işçilik maliyeti de yüksek.
2. varyantın toplam ek süresine oranı = 100.971 ÷ 68.820 = 1,47 kat
Yani vakaların %4,81'i, vakaların %9,90'ından daha fazla gecikme üretiyor. Vaka sayısına bakarak öncelik belirlemek yanıltıcı olurdu.
3. Uygunluk skoru. Tanımlı BPMN modeliyle karşılaştırıldığında:
| Sapma türü | Vaka | Pay % |
|---|---|---|
| Modelde olmayan geri dönüş | 94.315 | 19,40 |
| Modelde tanımlı adımın atlanması | 11.669 | 2,40 |
| Modelde olmayan faaliyet | 3.404 | 0,70 |
| Tam uyumlu vaka | 376.812 | 77,50 |
Uygunluk skoru %77,5. Yani her 100 gönderiden 22'si, kurumun kendi yazdığı süreç modelinin dışında akıyor. Bu skorun tek başına iyi ya da kötü olduğu söylenemez — ama %2,40'lık "adım atlama" satırı ayrı bir konudur: tanımlı bir kontrol adımı 11.669 vakada hiç yapılmamış. Bu doğrudan bir uygunsuzluk kaydı konusudur ve iç denetimde bulunması gereken bir şeyin, veriyle önceden yakalanmasıdır.
Sık karşılaşılan hatalar
Veri kalitesi adımını atlamak. Kirli bir günlük kirli bir model üretir. Eksik okutmalar, çift kayıtlar ve saat dilimi tutarsızlıkları temizlenmeden yapılan analiz, olmayan bir süreci anlatır. Bu adım çalışmanın en uzun kısmıdır ve kısaltılamaz.
Yüz kırk yedi varyantı aynı anda anlamaya çalışmak. Analiz ilk dört beş varyantla başlar; uzun kuyruk ayrı bir çalışma olarak ele alınır, çünkü orada aranan şey akış değil istisnanın kendisidir.
Varyantları yalnızca vaka sayısına göre önceliklendirmek. Yukarıdaki örnekte görüldüğü gibi az sayıda vaka çok daha fazla gecikme üretebiliyor. Öncelik, vaka sayısı ile vaka başına ek sürenin çarpımına bakılarak belirlenmelidir.
Keşfedilen modeli olduğu gibi standart ilan etmek. Keşif çıktısı mevcut durumu gösterir ve içinde istenmeyen davranışlar da vardır. Hedef durumun ne olacağı ayrı bir karardır.
Analizi kişisel performans takibine dönüştürmek. Olay günlükleri kullanıcı kimliği içerir ve çalışma bir izleme aracına dönüştüğü anda iki şey birden olur: veri kalitesi bozulur, çünkü insanlar kaydı manipüle etmeye başlar; ayrıca kişisel veri yükümlülükleri devreye girer.