Hangi İş Süreçleri Otomasyona Uygundur?

İki süreç düşünün. İkisi de her gün çalışıyor, ikisi de tekrar ediyor, ikisi de kural tabanlı görünüyor. Biri otomatikleştirildiğinde ekip rahatlıyor; diğerinde altı ay sonra herkes eski yöntemine dönmüş oluyor.

Aradaki fark genellikle sanıldığı yerde değildir. Otomasyon adaylarını seçerken en çok kullanılan ölçüt tekrardır: bu iş sık yapılıyorsa otomatikleştirelim. Tekrar gerekli bir koşuldur, ama tek başına hiçbir şeyi garanti etmez.

Belirleyici olan, sürecin ne kadar sık çalıştığı değil, ne kadar sık kendi tanımının dışına çıktığıdır.

Otomasyon bir yolu otomatikleştirir

Bir otomasyon, tanımlanmış tek bir yolu hızlandırır. O yolun dışına çıkan her vaka, ikinci bir yol yaratır: birinin fark etmesi, sistemden çıkarması, elle tamamlaması ve sonucu geri yazması gereken bir yol.

Kritik nokta şudur: ikinci yol açıldığı anda maliyet, iki yolun toplamı değildir. Daha fazlasıdır. Çünkü artık her vaka için önce hangi yola ait olduğuna karar verilmesi gerekir ve bu karar, işin kendisinden bağımsız bir yüktür.

Bu yüzden istisna oranı, otomasyonun ekonomisini doğrudan belirler.

Yüzde iki istisna üreten bir süreçte sistem işi gerçekten devralır; ekip doksan sekiz vakayı hiç görmez ve kalan ikisine odaklanır. Yüzde otuz istisna üreten bir süreçte ise kimse sisteme güvenemez — her çıktının kontrol edilmesi gerekir, çünkü hangi vakanın yanlış işlendiği ancak bakılarak anlaşılır. Bu noktada otomasyon, işi azaltmak yerine üzerine bir denetim katmanı eklemiş olur.

Sonuç, sezgiye aykırıdır: ayda bin kez çalışan ama üçte biri istisna olan bir süreç, ayda iki yüz kez çalışan ve neredeyse hiç sapmayan bir süreçten daha kötü bir adaydır.

İstisnaların üçte ikisi aslında istisna değildir

İstisna oranı yüksek çıktığında verilen refleks karar genellikle "bu süreç otomasyona uygun değil" olur. Bu, çoğu zaman erken bir karardır; çünkü istisnaların hepsi aynı türden değildir.

Gerçek çeşitlilik. İşin doğası gereği vakalar birbirinden farklıdır: her müşterinin sözleşmesi başka koşullar taşır, her talep başka bir değerlendirme ister. Bu tür istisnalar azaltılamaz.

Tanımsızlık. Kural aslında vardır, ama yazılı değildir. Deneyimli bir çalışan ne yapacağını bilir; kimse bunu sormadığı için hiçbir yerde kayıtlı değildir. Bu istisnalar, yazıldıkları anda istisna olmaktan çıkar.

Veri eksikliği. Vaka aslında standarttır, ancak karar için gereken bilgi sistemde olmadığından biri gidip elle bulur. Burada sorun süreçte değil, girdi tarafındadır.

Bu ayrımı yapmak, otomasyon kararını değiştirir. Yüzde otuzluk bir istisna oranının yirmi puanı tanımsızlıktan geliyorsa, yapılacak iş otomasyondan vazgeçmek değil, kuralları yazmaktır. Bu da dijital dönüşümün yalnızca yazılım satın almak olmadığı yazısındaki sadeleştirme adımının somut hâlidir: burada sadeleştirme, süreci kısaltmak değil, zaten var olan kararı görünür kılmaktır.

Oranı tahmin etmeyin, sayın

İstisna oranı toplantıda sorulduğunda gelen cevap neredeyse her zaman iyimserdir. Süreci yürüten kişi istisnaları zihinsel olarak işin parçası saydığı için ayrı bir kalem olarak görmez.

Ölçmenin ucuz bir yolu vardır: son elli vakayı geriye dönük inceleyip her birinin tanımlı yoldan mı geçtiğini işaretlemek. Bu birkaç saatlik bir iştir ve iki şey üretir — gerçek oran ve istisnaların listesi. İkinci çıktı genellikle birincisinden değerlidir, çünkü sapmalar birkaç başlık altında toplanır ve bunların bir kısmının kural hâline getirilebildiği hemen görülür.

Elli vaka istatistiksel bir kanıt değildir; ancak "sanırım nadiren oluyor" ifadesinden çok daha iyi bir temeldir.

Bu sayımın, süreci fiilen yürüten kişiyle birlikte yapılması önemlidir. Dışarıdan bakan biri sapmaların bir kısmını göremez, çünkü kayıtlarda iz bırakmayan düzeltmeler vardır: bir telefonla halledilen eksik bilgi, elle düzeltilen bir tutar, atlanan bir adım. Bunlar tam olarak otomasyonun tökezleyeceği yerlerdir.

İkinci eksen: zaman nerede geçiyor?

İstisna oranı bir sürecin otomasyona uygun olup olmadığını söyler. Otomasyonun değerli olup olmayacağını ise başka bir ölçüm söyler: sürenin nerede harcandığı.

Bir talebin yaşam süresi ikiye ayrılır. İşlem süresi, birinin fiilen o iş üzerinde çalıştığı süredir. Bekleme süresi ise talebin bir masada, bir kutuda veya bir onay sırasında durduğu süredir.

Çoğu kurumsal süreçte bu ikisi arasında büyük bir fark vardır: on bir dakikalık işlem, üç günlük bekleme. Otomasyon projeleri neredeyse her zaman ilk kalemi hedefler, çünkü görünür ve ölçülebilir olan odur. Oysa on bir dakikayı dörde indirmek, üç günü değiştirmez.

Bekleme süresini kısaltan şey genellikle daha hızlı bir işlem değil, devir teslimin ortadan kalkmasıdır: bir adımın bittiğini bir sonrakine bildiren mekanizma, bekleyen işin görünür olması, onay gerektirmeyen vakaların onay sırasına hiç girmemesi. Bunlar teknik olarak daha basit, etkisi bakımından daha büyüktür.

Otomasyon eskir

Otomasyon adayı seçilirken neredeyse hiç sorulmayan bir soru vardır: bu sürecin kuralları ne sıklıkla değişiyor?

Bir otomasyon, yazıldığı andaki kuralı dondurur. Fiyat kademesi, onay eşiği, vergi oranı, indirim politikası veya bir müşteri segmentinin tanımı değiştiğinde sistem bunu kendiliğinden öğrenmez. Kural değişir, otomasyon geçen yılın kuralını uygulamaya devam eder.

Bunun tehlikeli tarafı, sessiz olmasıdır. Sistem hata vermez; yalnızca artık yanlış olan bir işi kusursuz biçimde yapar. Üstelik ekip uzun süredir kontrol etmediği için, sapma genellikle bir müşteri şikâyetiyle veya dönem sonu mutabakatında ortaya çıkar — yani en pahalı yerde.

Buradan iki pratik sonuç çıkar. Birincisi, sık değişen kurallara sahip bir süreçte otomasyonun değeri, kuralın koda gömülmemesine bağlıdır: eşikler ve oranlar, geliştirme gerektirmeden güncellenebilecek biçimde dışarıda tutulmalıdır. İkincisi, her otomasyonun bir sahibi olmalıdır — kural değiştiğinde sistemi güncellemenin kimin işi olduğu tanımlı değilse, o iş kimsenin işi değildir.

Kısmi otomasyon çoğu zaman doğru cevaptır

Otomasyon tartışması genellikle ikili kurulur: bu süreci otomatikleştirelim mi, etmeyelim mi. Pratikte en iyi sonucu veren kurgu üçüncüsüdür.

Sistem, tanımlı yoldan geçen vakaları uçtan uca işler. Tanıma uymayan vakaları işlemeye çalışmaz — tanır, ayırır ve bir insana yönlendirir. Böylece ekip yüzde yüz yerine yüzde yetmişini devreder ve kalan yüzde otuza gerçekten bakar.

Bunun işe yaraması için sistemin "bu vakayı işleyemiyorum" diyebilmesi gerekir. Bu yetenek, otomasyonun en çok atlanan parçasıdır: her vakaya bir çıktı üreten bir sistem, hatalı çıktıyı da aynı güvenle üretir ve fark edilmesi aylar alır.

Kısmi otomasyonun ikinci faydası ölçme imkânıdır. Ayrılan vakalar zamanla listelenir; bu liste, bir sonraki adımda hangi kuralın tanımlanacağını gösterir. Otomasyon böylece tek seferlik bir proje değil, kapsamı kademeli genişleyen bir sistem hâline gelir.

Sonuç

Otomasyona uygun süreç, en sık tekrar eden süreç değildir. En az sapan süreçtir.

Bu ayrım, otomasyon projelerinin neden birbirinden bu kadar farklı sonuçlar verdiğini büyük ölçüde açıklar: aynı yatırım, düşük istisna oranlı bir süreçte işi devralır, yüksek oranlı bir süreçte ise mevcut işin üzerine bir kontrol yükü ekler.

Bu yüzden seçim aşaması, geliştirme aşamasından daha belirleyicidir — ve birkaç saatlik bir sayım, aylık bir geliştirme kararını değiştirebilir. Kurumsal yazılım ve otomasyon çalışmalarımızda ilk adım, süreci tasarlamak değil, son elli vakanın nasıl yürüdüğüne bakmaktır.