İkinci Düzey Düşünme ve Otomasyon

Bir işletmede en pahalı hatalar yanlış yapılan işlerden değil, doğru göründüğü için sonucu sorgulanmadan otomatikleştirilen işlerden çıkar. Birinci düzey düşünme "bu süreci otomatikleştirelim, zaman kazanırız" der ve durur. İkinci düzey düşünme ise "peki bu otomasyon altı ay sonra hangi yeni sorunu doğuracak, kim bakacak, bozulunca ne olacak" diye sorar. Danışmanlık yaptığım her projede fark bu ikinci soruyu soran ile sormayan arasında açılıyor.

Birinci Düzey ve İkinci Düzey Düşünme Arasındaki Fark

Kavram Howard Marks'ın yatırım felsefesinden geliyor ama otomasyon ve yapay zeka projelerinde bundan daha keskin işliyor. Birinci düzey düşünme anlıktır ve tek adımlıdır: "Fiyat düştü, alalım." İkinci düzey düşünme zincirlidir: "Fiyat düştü, çünkü herkes panikledi; peki panik haklı mı, haksızsa fırsat, haklıysa tuzak."

İş süreçlerine çevirdiğinizde şöyle görünür: Birinci düzey "müşteri mesajlarına otomatik cevap kuralım" der. İkinci düzey "otomatik cevaplar hangi durumda yanlış bilgi verip müşteriyi kaybettirir, hangi soruları insana devretmeli, sistem çöktüğünde müşteri bunu ne zaman fark eder" diye sorar. İlki bir hafta sonra çalışan bir robot kurar; ikincisi bir yıl sonra hala güvenilir olan bir sistem kurar.

Otomasyonun Hız Tuzağı: 'Yaptık, Bitti' Yanılgısı

Otomasyonun en tehlikeli yanı, ilk gün muhteşem görünmesidir. Manuel yapılan bir iş artık kendiliğinden oluyor, ekip rahatladı, herkes mutlu. Bu birinci düzey hazdır. Sorun şu: otomatikleştirilen bir süreç görünmez hale gelir. Kimse bakmadığı için sessizce bozulur, yanlış veri üretir ya da değişen koşullara ayak uyduramaz. Ve bunu genellikle bir müşteri şikayet edene kadar kimse fark etmez.

İkinci düzey düşünen bir operasyon kurarken ben şunu şart koşarım: her otomasyon, kendi sağlığını raporlayan bir mekanizmayla birlikte kurulur. Sessizce çalışan bir robot değil, "ben buradayım ve şu an şu durumdayım" diyen bir sistem. Çünkü otomasyonun asıl maliyeti kurulum değil, ona kimsenin bakmadığı o uzun sessiz aylardır.

Kararlarınıza İkinci Düzey Düşünmeyi Nasıl Katarsınız?

Bunu bir yetenek gibi değil, bir alışkanlık gibi kurmak gerekir. Kendi ekiplerimde uyguladığım üç pratik soru:

• "Ve sonra ne olur?" sorusunu üç kez sorun: Her kararın ardından sonucunu, sonra o sonucun sonucunu, sonra onun da sonucunu düşünün. Genellikle asıl risk üçüncü halkada saklıdır.
• Tersini kurgulayın (inversion): "Bu otomasyon nasıl başarılı olur" yerine "bu otomasyon en kötü nasıl patlar, beni gece 3'te kim arar" diye sorun. Felaket senaryosunu önce görürseniz onu baştan engellersiniz.
• Geri alınabilirliği ölçün: Karar geri alınabilirse hızlı verin, denemekten korkmayın. Geri alınamazsa (veri silme, müşteriye giden mesaj, kalıcı entegrasyon) yavaşlayın ve ikinci düzeyi zorunlu kılın. Hız ve dikkat, kararın türüne göre ayarlanır.

İşin özü: birinci düzey düşünme size hız verir, ikinci düzey düşünme o hızın sizi uçuruma değil hedefe götürmesini sağlar. Otomasyon ve yapay zeka çağında rekabet, en hızlı otomatikleştiren değil, otomatikleştirdiğinin sonucunu en iyi gören tarafından kazanılacak.

Otomasyonun Görünmez Maliyeti: Bakım Yükü Nereye Kaydı?

Bir süreci otomatikleştirdiğinizde iş ortadan kalkmaz; türü değişir. Elle yapılan tekrarlı iş yerine, sistemin kendisini ayakta tutma işi gelir. Birinci düzey düşünme bu değişimi kazanç hanesine yazar ve orada bırakır; ikinci düzey düşünme yeni yükün kime düştüğünü sorar.

Google'ın site güvenilirliği mühendisliği kitabı bu tür işi toil kavramıyla tanımlar ve altı özellik sayar: elle yapılan, tekrar eden, otomatikleştirilebilir, taktik (inisiyatif değil tepkiye dayalı), kalıcı değer üretmeyen ve hizmet büyüdükçe doğrusal olarak artan iş. Aynı kaynak somut bir sınır da koyar: bir ekibin zamanının en fazla %50'si bu tür işe gitmeli, kalan yarısı bu yükü azaltacak mühendislik çalışmasına ayrılmalıdır. Google'ın kendi anketlerinde ölçülen ortalama %33'tür.

Bu çerçeve otomasyon kararları için doğrudan kullanışlıdır, çünkü doğru soruyu sordurur: kurduğum otomasyon toplam toil'i azaltıyor mu, yoksa yalnızca yerini mi değiştiriyor? Haftada iki saatlik veri girişini ortadan kaldırıp yerine haftada üç saatlik “akış neden düştü” incelemesi koyan bir sistem, birinci düzeyde başarı, ikinci düzeyde kayıptır.

Çalışılmış Örnek: Bir Otomasyon Kararının Üç Halkası

Karar: “Teklif gönderdiğimiz müşterilere üç gün sonra otomatik hatırlatma maili gitsin.” Birinci düzeyde bu karar tartışmasız iyidir: takip unutulmaz, satış ekibi zaman kazanır.

Birinci halka (hemen olan): Hatırlatmalar gitmeye başlar. İlk hafta iki kapanmış teklif gelir, ekip memnun. Ölçüm: gönderilen hatırlatma sayısı ve gelen yanıt sayısı.

İkinci halka (bir ay sonra): Hatırlatma artık koşulsuz gidiyordur. Teklifi telefonda zaten reddetmiş müşteri de üç gün sonra “teklifimizi değerlendirdiniz mi” maili alır. Satış temsilcisi bu maili görünce müşteriye tekrar açıklama yapmak zorunda kalır. Kazanılan zamanın bir kısmı geri gitmiştir. Kök sebep teknik değildir: akış, teklifin durumunu okumadan tetikleniyordur.

Üçüncü halka (altı ay sonra): Ekip, otomatik hatırlatma gittiğini bildiği için elle takibi tamamen bırakmıştır. Mail sağlayıcısında yapılan bir ayar değişikliği yüzünden hatırlatmalar üç haftadır gönderilmiyordur ve bunu kimse fark etmemiştir — çünkü çalışan bir sistem sessizdir, çalışmayan sistem de sessizdir. Fark yalnızca sonuçta görünür ve sonuç geç görünür.

İkinci düzey kararın kendisi ne olurdu: aynı otomasyon şu üç ek şartla kurulurdu: (1) hatırlatma yalnız durumu “yanıt bekliyor” olan tekliflere gider, (2) sistem her gün kaç hatırlatma gönderdiğini raporlar ve sayı sıfıra düştüğünde uyarı üretir, (3) ekip için “otomasyon çalışmazsa ne yaparız” yordamı yazılır. Üçü de kurulum maliyetini artırır; üçü de altıncı ayda kendini öder.

Ölçüm ve Veri: İkinci Düzey Sonuçlar Nasıl Görünür Kılınır?

İkinci düzey düşünmenin en pratik hâli, kurulum anında hangi verinin toplanacağına karar vermektir. Birinci düzey metrikler kolay ve yanıltıcıdır; ikinci düzey metrikler zahmetli ve dürüsttür:

Sağ sütundaki metriklerin ortak özelliği şudur: hepsi sistem iyi görünürken kötüye gidişi yakalar. Sol sütun ise ancak müşteri şikâyet ettiğinde bozulur.

Hata Desenleri ve Riskler

• Sessiz başarısızlığı tasarlamamak. Bir otomasyon durduğunu söylemiyorsa, durduğu gün ile fark edildiği gün arasındaki fark doğrudan zarardır.
• Koşulu okumadan tetiklemek. Durum kontrolü yapmayan akış, doğru işi yanlış kişiye yapar.
• Tek kişiye bağımlı kurmak. Akışı kuran kişi ayrıldığında kimse dokunamıyorsa, sistem çalışırken bile risktir.
• Geri alma yordamı yazmamak. “Bozulursa ne yaparız” sorusunun cevabı kurulum günü yazılmazsa, kriz anında doğaçlama yapılır.
• İnsan onayını gereksiz yere kaldırmak. Geri alınamaz işlemlerde onay adımı yavaşlatma değil sigortadır; bu ayrımı otonom ajanlarda insan onayı yazısında ayrıntılı ele alıyorum.
• Kazancı brüt ölçmek. Kazanılan saatten bakım saatini düşmeyen hesap, her zaman olduğundan iyi görünür.
• Otomasyonu ölçmeden büyütmek. Çalıştığı doğrulanmamış bir akışı başka süreçlere kopyalamak, hatayı da kopyalar.

Geri Alınabilirlik: Ne Zaman Hızlı, Ne Zaman Yavaş Karar Verilir?

İkinci düzey düşünme her karara aynı ağırlığı vermek anlamına gelmez — öyle olsaydı hiçbir şey ilerlemezdi. Ayarı belirleyen ölçüt geri alınabilirliktir: karar kolay geri alınıyorsa hızlı verilir ve denemekten kaçınılmaz; geri alınamıyorsa (veri silme, müşteriye giden mesaj, kalıcı entegrasyon, fiyat taahhüdü) yavaşlanır.

Aynı mantığın mühendislik tarafındaki karşılığı hata bütçesi kavramıdır. Güvenilirlik hedefiyle gerçek performans arasındaki fark bir bütçe olarak tanımlanır; bütçe varken risk alınır ve hızlı yayın yapılır, bütçe tükendiğinde yayınlar durdurulur ve kaynak dayanıklılığı artırmaya kaydırılır. Kavramın arkasındaki argüman da doğrudan ikinci düzeydir: %100 güvenilirlik yanlış hedeftir, çünkü her ek güvenilirlik basamağı öncekinden kat kat pahalıdır ve kullanıcı bu farkı çoğu zaman ayırt bile edemez.

İşletme diline çevirisi şudur: “hiç hata olmasın” hedefi, gerçekte “hiç ilerleme olmasın” demektir. Doğru soru hatanın olup olmayacağı değil, hangi hatanın ne kadar sürede fark edilip geri alınabileceğidir. Bu çerçeveyi otomasyon projelerine nasıl uyguladığımı yapay zekâ ve iş akışı otomasyonu sayfasında anlatıyorum.

Kaynaklar ve Referanslar

• Toil tanımı, altı özelliği ve %50 üst sınırı — Google SRE Book, Eliminating Toil
• Hata bütçesi ve %100 güvenilirliğin neden yanlış hedef olduğu — Google SRE Book, Embracing Risk

Son bir not: ikinci düzey düşünme, karamsarlık ya da her fikri baştan reddetme alışkanlığı değildir. Amacı kararı engellemek değil, kararın bedelini vermeden önce görmektir. Pratikte bu çoğu zaman projeyi yavaşlatmaz; yalnızca kurulum listesine üç kalem ekler: koşulun doğru okunduğu, sistemin kendi sağlığını raporladığı ve bozulduğunda ne yapılacağının yazılı olduğu. Bu üç kalem olmadan kurulan otomasyon çalışır — ta ki çalışmadığı gün fark edilene kadar.