Otomasyonun Epistemik Ön Koşulu Olarak Süreç Madenciliği

Başarısız otomasyon projelerinin çoğunda sorun, ekibin süreç hakkında yanlış bildiklerinden çıkar. Ekip, kimsenin gerçekte izlemediği bir süreci harfiyen yürüten bir makine kurar, sonra bütçenin kalanını gerçek süreçle arasındaki farkı keşfetmeye harcar. Bu yazıdaki savımız şu: otomasyon öncesi süreç madenciliği, yani işin gerçekte nasıl yürüdüğüne dair olay günlüğü kanıtı toplamak, otomasyonun ön koşuludur ve sonraya bırakılamaz. Uygunluk denetimi yapılmadan otomatikleştirilen sistem, kurumun süreç hakkındaki anlatısını koda döker ve bu anlatı insanların fiilen yaptığı işten çok uzak olabilir. Yazı önce tasarlanan, anlatılan ve yürütülen süreci birbirinden ayırıyor. Sonra bunları ayırt etmeye yetecek asgari veri belirtimini veriyor ve doğrudan gözlemin enstrümantasyondan ucuz olduğu durumlar için bir karar kuralı öneriyor.

Üç Süreç Arasındaki Boşluk: Tasarlanan, Anlatılan ve Yürütülen

Bir kurumun işlettiğine inandığı her süreç en az üç ayrı sürümde var olur ve bir otomasyon programındaki asıl risk, bu sürümler arasındaki mesafedir.

Tasarlanan süreç

Tasarlanan süreç, amaçlanan süreçtir: sistem satın alınırken modellenen akış, gereksinim belgesindeki kulvar (swimlane) diyagramı, ERP yapılandırmasına kodlanmış durum makinesi. İşin nasıl olması gerektiğini söyler. Genellikle kendi içinde tutarlıdır, çünkü tek oturumda ve süreci yürütenlerden çok süreç üzerine düşünen kişiler tarafından yazılmıştır.

Anlatılan süreç

Anlatılan süreç, katılımcıların sorulduğunda ne yaptıklarını söyledikleri şeydir. Görüşmelerde, çalıştaylarda ya da ISO 9001 gibi kalite yönetimi gerekliliklerinin başlattığı dokümantasyon çalışmalarında ortaya çıkar. Bu anlatılar kasıtlı değildir. İnsanlar işi hafızadan yeniden kurarlar ve bu yeniden kurgu öngörülebilir biçimde yanlıdır: en sık izlenen yolu anlatırlar, istisna yönetimini atlarlar, bekleme süresini olduğundan kısa söylerler ve işin onaylı olduğunu düşündükleri hâlini tarif ederler. Tasarlanan süreci gerçek hayatta ayakta tutmak için icat ettikleri baypaslar ise kendiliğinden en az söz ettikleri ayrıntılardır.

Yürütülen süreç

Yürütülen süreç, vaka vaka gerçekten yaşanmış durum değişikliklerinin gerçek zaman damgalarıyla oluşturduğu dizidir. Yeniden işleme döngülerini, tek bir onay için yapılmış dört denemeyi, on bir gün dokunulmadan bekleyen vakayı ve kimsenin sözünü etmediği paralel hesap tablosunu içerir. Üç sürümden gerçekte olanı kaydeden yalnızca budur, diğer ikisi olanlar hakkında ne söylendiğini gösterir.

Otomasyon bir süreç belirtimini yazılıma döker. Bu belirtim tasarlanan ya da anlatılan süreçten geliyorsa ve yürütülen süreç bunlardan esaslı biçimde farklıysa, kurulan sistem iş hakkındaki bir anlatıyı otomatikleştirir. İşin kendisi onun etrafında eskisi gibi dönmeye devam eder. Hammer'ın mevcut süreçleri otomatikleştirmek yerine yeniden tasarlama çağrısı (Hammer, 1990) genellikle daha iddialı olma çağrısı olarak okunur. Aynı zamanda bir kanıt çağrısıdır, çünkü ne olduğunu bilmediğiniz bir süreci yeniden tasarlayamazsınız. Davenport ve Short (1990) bunu tamamlayan noktayı koydu: bilgi teknolojisi ve süreç yeniden tasarımı tek bir problemdir ve birlikte ele alınmalıdır, biri bitince öbürüne geçilmez.

Boşluğun biçimini görmenin en kolay yolu bir örnektir. Aşağıdaki örnek kurgudur ve sayıları aritmetiği kolay okunur kılmak için seçilmiş varsayımlardır. Bir operasyon sorumlusunun bir devir teslim adımını on beş dakikalık bir iş olarak tarif ettiğini, aynı adım sahada tekrarlanan çalışmalar boyunca ölçüldüğünde ise sürenin kırk beş dakikaya yaklaştığını varsayalım. Böyle bir fark nadiren abartıdan gelir. Diyelim ki açıklaması, dokümantasyonda adı geçen iki sistemin arasında duran üç hesap tablosu. Her birini farklı bir kişi tutuyor. Tablolar, tasarlanan süreç sık karşılaşılan bir durumu ifade edemediği için ortaya çıkmış ve hiçbir diyagramda görünmüyorlar. Bu durumda belgelenmiş adımı otomatikleştirmek gerçek işin kabaca üçte birini kapsar ve kimsenin yazıya dökmediği geri kalanını bozar. Bu yazının konusu olan başarısızlık budur ve bir otomasyon programının nereden başladığı konusunda dikkatli olmanın nedeni de bu.

Olay Günlüğü Gereksinimleri ve Asgari Uygulanabilir Olay Günlüğü

Süreç madenciliği mütevazı bir veri yapısıyla çalışır. Bir olay günlüğü (event log) vakalardan oluşur, bir vaka da sıralı olaylardan. Bir olay en az şunu söyler: adı belli bir etkinlik, adı belli bir vaka için, bilinen bir anda gerçekleşti. Bu yüzden asgari uygulanabilir günlükte üç zorunlu kolon vardır:

case_id, activity, timestamp
ORD-10231, order_received,  2026-01-14T09:12:03+03:00
ORD-10231, credit_checked,  2026-01-14T11:40:55+03:00
ORD-10231, order_received,  2026-01-15T08:03:12+03:00

Üçüncü satıra bakın: aynı sipariş ikinci kez alınmış. Tek bir vaka içinde tekrar eden bir etkinlik hiçbir diyagramda görünmez, günlükte ise hemen göze çarpar. İsteğe bağlı kolonlar modeli değiştirmeden analizi güçlendirir. Kaynak tanımlayıcısı devir teslim analizini mümkün kılar, başlangıç ve tamamlanma zaman damgası çifti kuyrukta beklemeyi çalışmadan ayırır, vaka öznitelikleri de bölümlemeye imkân verir. Bu disiplinin ve algoritmalarının standart kaynağı Van der Aalst'tır (2016).

En zor karar tanımla ilgilidir: neyin vaka sayılacağı (case notion). Aynı veri kümesi sipariş başına, sipariş satırı başına, sevkiyat başına ya da müşteri başına analiz edilebilir ve her seçim aynı veriden farklı bir süreç çıkarır. Satır düzeyinde görünen bir yeniden işleme döngüsü, satırlar siparişlerde toplandığında kaybolur. Vaka olarak işletmenin çevrim süresini önemsediği birimi seçin ve bu seçimi herhangi bir model üretmeden önce yazılı hâle getirin.

Zaman damgaları günlüğü klasik operasyon teorisine de bağlar. Little Yasası (Little, 1961) L = λW der: devam eden vakaların ortalama sayısı, varış hızı ile sistemde geçirilen ortalama sürenin çarpımına eşittir. Görüşmeye dayalı dokümantasyon bu bağıntıyı besleyemez, çünkü insanların anlattığı süreler dokunma süresidir ve yasanın ihtiyaç duyduğu şey geçen süredir. Olay günlüğü her vaka için W'yi doğrudan verir. Böylece devam eden iş ölçülen bir nicelik olur ve kısıtı Goldratt'ın anlamında (Goldratt, 1984) veriden bulabilirsiniz. İnsanların kendini en yoğun hissettiği yere bakıp tahmin yürütmeniz gerekmez.

Keşif, Uygunluk ve Zenginleştirme Farklı Sorulardır

Bir olay günlüğünün bu üç kullanımı çoğu zaman "süreç madenciliği yaptık" cümlesinin içinde birbirine karışır ve sonunda hangi soruya cevap verildiği belli olmaz.

Keşif

Keşif, günlüğün hangi süreci ima ettiğini sorar. Girdi olarak bir referans model almaz, çıktısı gözlenen davranıştan türetilmiş bir modeldir. İnandırıcı bir tasarım yoksa ya da tasarım ancak bir hipotez muamelesi görecek kadar eskidiyse doğru soru budur.

Uygunluk denetimi

Uygunluk denetimi, günlüğün mevcut bir modelden nasıl ayrıldığını sorar. Çıktısı sapmalardır: sırası bozulmuş etkinlikler, atlanmış zorunlu adımlar, yapılmış yasak geçişler ve hiç yeniden oynatılamayan vakalar. Otomasyon açısından önemli olan budur, çünkü üç süreç arasındaki boşluğu sayıya döken tek analiz bu. Tek bir üst düzey uyum (fitness) değeri analize başlamak için iyidir. Üzerinde çalışılacak çıktı, sapan davranışların her birinin kaç vakayı etkilediğiyle birlikte tek tek sayıldığı listedir.

Zenginleştirme

Zenginleştirme, günlüğün mevcut bir modele ne ekleyebileceğini sorar: zaman nereye gidiyor, yeniden işleme nerede yoğunlaşıyor, hangi devir teslimlerin ardından gecikme geliyor. Hiç uygunluk denetiminden geçmemiş bir model üzerinde çalıştırılırsa, belki hiç var olmayan bir süreç hakkında kendinden emin performans istatistikleri üretir.

Varyant Patlaması ve Süreç Yollarının Uzun Kuyruğu

Gerçek veriden keşfedilen ilk model neredeyse her zaman okunamaz, çünkü gerçek süreçlerde herhangi bir diyagramın gösterdiğinden çok daha fazla farklı yol vardır. Her tekil etkinlik dizisi bir varyanttır ve bir düzine kutuyla belgelenmiş bir süreçte yüzlerce varyant görmek olağandışı değildir.

Aşağıdaki örnek de açıklama amacıyla kurgulandı. Orta ölçekli bir siparişten tahsilata (order-to-cash) sürecinden 12.000 vakalık bir günlük, 640 farklı varyant ve uzun kuyruklu operasyonel veride tipik olan bir dağılım varsayın.

Böyle bir dağılımın iki sonucu var. Birincisi, yalnızca mutlu yolu (happy path) kapsayan tam otomasyon hacmin kabaca yarısını karşılar. Toplam vaka sayısına dayanan bir iş gerekçesi bu yüzden yaklaşık iki kat abartılı olur. Getiri hesabının nokta tahmini yerine bir aralık olarak verilmesi gerektiğinin bir nedeni de bu. İkincisi, kuyruğu gürültü diye temizleyip geçemezsiniz. Bir kısmı veri kalitesinden doğan yapaylıktır, bir kısmı da tasarlanan sürecin ifade edemediği gerçek değişkenlik. Hangisinin hangisi olduğunu ancak vakalara tek tek bakarak anlarsınız. Deming'in, değişkenliğe müdahale etmeden önce onu anlamak gerektiği savı (Deming, 1986) tam burada geçerlidir. Kararnameyle kaldırılan bir istisna yolu çoğu zaman belgelenmemiş bir baypas olarak geri döner. Aynı nominal süreç farklı sahalarda farklı yollar izliyorsa, Conway'in sistemlerin onları üreten iletişim yapılarını yansıttığı gözlemi (Conway, 1968) iyi bir başlangıç varsayımıdır. Süreç, müşterinin ihtiyaçlarından çok raporlama hatlarına göre parçalanıyor olabilir.

Süreç Madenciliğinin Göremedikleri

Süreç madenciliği dijital izleri görür. Kör noktası da iz bırakmayan her türlü iştir.

Dijitalleşmemiş iş görünmez. Fiziksel muayene, bir masada yapılan konuşma ya da bir tedarikçiye açılan telefon hiçbir olay üretmez. Günlükte açıklaması olmayan bir boşluk görünür ve bu boşluğu çalışma yerine bekleme olarak okuyan analist kısıtı yanlış sınıflandırır. Gölge sistemler de aynı nedenle görünmez. Hesap tabloları, yerel veritabanları ve mesajlaşma yazışmaları gerçek eşgüdümün önemli bir kısmını taşır ve madenciliği yapılan sistemlere hiçbir şey yazmaz. Yukarıdaki devir teslim örneğinde geçen sürenin çoğu bu gölge işte harcanıyor. Adı geçen iki sistemin günlüğüne bakan biri temiz ve hızlı bir iz görürdü, ama bu iz tamamen yanıltıcı olurdu.

Muhakeme, sonucu günlüğe düşse bile görünmez. Günlük bir onayın belli bir anda verildiğini kaydeder. Onaylayanın hangi ölçütleri tarttığını ya da hangi yazılı olmayan kuralı uyguladığını kaydetmez. Otomasyon açısından en önemli kör nokta budur, çünkü ekonomik olarak otomatikleştirmeye en değer adımlar çoğu zaman mantığı yalnızca onaylayanın kafasında duran adımlardır. Günlüklerin kendi yapaylıkları da vardır. Toplu yazmalar sıralamayı bozar, üzerine yazılan durum alanları ara durumları kaybeder ve kaynak kolonunda görünen "kullanıcı" bazen paylaşılan bir servis hesabıdır.

Gözlem ile Enstrümantasyon Arasında Bir Karar Kuralı

Enstrümantasyon, yani süreç madenciliğe uygun hâle gelsin diye günlükleme ya da olay yakalama eklemek, kalıcı cevaptır ama hazırlanması haftalar ya da aylar sürer. Endüstri mühendisliği anlamında doğrudan gözlem, yani işin yanında durup süre tutmak, birkaç gün içinde başlayabilir ama toplayabileceği örneklem çok daha küçüktür. İkisi birbirini tamamlar. Hangisiyle başlayacağınız kapsama ve riskin büyüklüğüne bağlıdır.

observe_first if:
    digital_coverage < ~70% of steps
 or shadow_tooling_suspected
 or case_notion_still_disputed
 or decision_needed_within_weeks

instrument_first if:
    digital_coverage >= ~70% of steps
and process_is_high_volume_and_repetitive
and conformance_must_be_monitored_after_go_live

Buradan pratik bir sıra çıkıyor. Veriye dokunmadan önce neyin vaka sayılacağını ve bir vakanın değerini belirleyin. Var olan günlüğü çekin ve kapsamını dokümantasyonla kıyaslamak yerine küçük bir gözlenmiş örneklemle karşılaştırın. Kapsamın zayıf olduğu yerde önce gözlemleyin ve neyin enstrümante edileceğine gözlemden yola çıkarak karar verin. Herhangi bir otomasyonun kapsamını çizmeden önce tasarlanan modele karşı uygunluk denetimi çalıştırın ve kapsamı varyant varyant belirleyin, süreci tek parça almayın. Devreye aldıktan sonra da denetimi çalışır durumda tutun, çünkü otomatikleştirilmiş bir süreç, girdileri ve çevresindeki sistemler değiştikçe kayar.

Bir koleksiyon kartı üreticisi için kurduğumuz otomatikleştirilmiş kalite kontrol pipeline'ı bu sırayı izledi. Haritalamayı inşadan önce yaptık. Ortaya çıkan pipeline 90+ doğrulama kontrol noktasını ve QC sürecinin kabaca %95'ini kapsıyor. Sekiz saatlik manuel bir geçiş yaklaşık on beş dakikaya indi ve üretim çevrimi yaklaşık %300 hızlandı. Ardından, onaylanan tasarımları baskıya hazır montaj dosyalarına dönüştüren bir baskı öncesi araç geldi. Burada bakılması gereken sayı kontrol noktası sayısı. Her kontrol noktası ters gidebilecek bir şeye karşılık geliyor ve bu listeyi diyagramdan kopyalamak yerine işin gerçekte nasıl yürüdüğüne bakarak çıkardık.

Sınırlamalar

Bu analiz, süreç madenciliğinin otomasyonu başarılı kıldığını göstermiyor. Buradaki ilişki ampirik değil mantıksal: uygunluk denetimi, belirtim ile davranış arasındaki boşluğu ölçmenin elimizdeki tek yolu ve onu atlamak bu ölçüm olmadan ilerlemek demek. Madencilik aşaması olan ve olmayan projeleri kontrollü biçimde karşılaştırmadık. Boşluğun ne sıklıkla önemli olacak kadar büyük olduğunu da ölçmedik. Kendi gözlemlerimiz imalat ve baskı üretiminde az sayıda projeden geliyor. Bunlar bir örneklem sayılmaz, saha notudur. Yukarıdaki varyant dağılımı da kurgudur. Keşfedilen modellerin doğru olduğunu iddia etmiyoruz. Keşfedilen bir model tek bir dönemdeki tek bir günlüğü özetler ve o günlüğün bütün yapaylıklarını devralır. Onu bir diyagramdan daha iyi bir hipotez olarak okumak gerekir.

Kaynaklar

• van der Aalst, W. (2016). Process Mining: Data Science in Action.
• Hammer, M. (1990). Reengineering Work: Don't Automate, Obliterate.
• Davenport, T., & Short, J. (1990). The New Industrial Engineering: Information Technology and Business Process Redesign.
• Deming, W. E. (1986). Out of the Crisis.
• Goldratt, E. M. (1984). The Goal.
• Little, J. D. C. (1961). A Proof for the Queuing Formula L = λW.
• Conway, M. E. (1968). How Do Committees Invent?