Bir üretim şirketinin aylık kapanış toplantısında, tedarikçi faturalarının sisteme girilmesiyle ilgili gecikme gündeme geldiğinde, verilen cevap genellikle sistemin yetersizliğine değil, girişin "dikkat gerektirdiğine" dayanır. Aynı toplantıda, bu girişi yapan kişinin yıllık izne çıktığı iki hafta boyunca kapanışın nasıl kaydığı da hatırlanır, fakat bu iki gözlem birbirine bağlanmaz. Faturaların bir bölümünün formatı standart değildir, bir bölümünde kalem eşleştirmesi elle yapılır, bir bölümünde ise tedarikçinin gönderdiği belge ile sipariş arasındaki fark ancak o işi yıllardır yapan kişinin hafızasıyla kapanır. Süreç manuel kalmıştır ve bunun gerekçesi her seferinde aynıdır: iş, göründüğünden daha karmaşıktır.
Aynı örüntü satın alma onaylarında, stok sayımında, müşteri sipariş kabulünde, üretim planı revizyonlarında ve saha ilerleme raporlamasında tekrar eder. Otomasyon önerisi masaya geldiğinde reddedilmez; ertelenir. Erteleme gerekçesi teknik gibi görünen bir dille kurulur — mevcut sistem uygun değildir, veri kalitesi yeterli değildir, entegrasyon maliyeti yüksektir — fakat aynı kurumda benzer ölçekte başka yatırımlar aynı gerekçelerle engellenmemiştir. Dolayısıyla direncin kaynağı bütçe kısıdı ya da teknik olgunluk değil, sürecin mevcut hâlinin kime ne sağladığıdır.
Bu erteleme örüntüsüne under-automation bias — otomasyona teknik olarak uygun bir işin, kültürel ve konumsal nedenlerle manuel bırakılması eğilimi — denir, ve mekaniği iki ayrı katmanda çalışır. Birinci katman bireyseldir: manuel bir süreci taşıyan kişi, o süreç boyunca kurum içinde görünür ve vazgeçilmez bir konum edinmiştir; sürecin otomatikleşmesi bu konumun dayanağını ortadan kaldırır. İkinci katman örgütseldir: manuel süreç, kural setinin dışına düşen her durumu sessizce soğuran bir tampon işlevi görür, ve bu tamponun varlığı üst yönetimin gözünde sistemin sorunsuz çalıştığı izlenimini üretir. Otomasyon önerisi, bu iki katmanı aynı anda tehdit ettiği için, teknik bir tartışma kılığında yürütülen konumsal bir müzakereye dönüşür.
Bu eğilimin belirli koşullarda tümüyle rasyonel olduğunu görmek, onu doğru teşhis etmenin ön şartıdır. İşlem hacmi düşükse, istisna oranı yüksekse, süreç kuralları henüz oturmamışsa ve iş tanımı çeyrekten çeyreğe değişiyorsa, manuel yürütmek gerçekten daha ucuzdur; bir insan, tanımlanmamış bir durumu yeniden kodlama gerektirmeden karşılar, ve erken evrede bu esneklik değerlidir. Sorun eğilimin kendisinde değil, koşul değiştiğinde eğilimin sabit kalmasındadır: hacim on kat arttığında, istisna oranı düştüğünde ve kurallar kararlı hale geldiğinde, manuel yürütmenin dayandığı gerekçe ortadan kalkar, fakat sürecin kendisi değişmez, çünkü değişimi tetikleyecek bir gözden geçirme ritmi kurulmamıştır.
Kurumsal bedelin ilk göründüğü yer, beklenenin aksine hata oranı değildir. Manuel süreçler çoğu zaman düşük hata oranıyla çalışır, zira onları taşıyan kişi işin tüm istisnalarını bilir; asıl bedel, hatanın **ne zaman ve kim tarafından** fark edildiğindedir. Otomatik bir süreçte tutarsızlık işlem anında yakalanır ve kayda geçer; manuel bir süreçte aynı tutarsızlık, düzelten kişinin başında düzeltildiği için hiç kayda geçmez, dolayısıyla kök nedeni de hiç ele alınmaz. Bunun operasyonel karşılığı, tedarikçi performansının gerçekte ne olduğunun bilinmemesi, sözleşme cezalarının işletilememesi ve satın alma pazarlığının veri yerine izlenime dayanmasıdır.
İkinci bedel işletme sermayesi döngüsünde birikir. Fatura kabulü, mal kabul kaydı ve ödeme onayı arasında manuel bir bekleme varsa, bu bekleme tedarikçiye karşı vade avantajı gibi görünür, oysa pratikte tedarikçinin fiyatına gecikme primi olarak geri döner; aynı şekilde müşteri tarafında sipariş kabulündeki manuel gecikme, teslim taahhüdünün fiili başlangıcını geciktirir ve stok devir hızını sessizce düşürür. Bu kalemler bilançoda ayrı bir satır olarak görünmez; stok ve ticari alacak kalemlerinin sektör ortalamasına göre bir miktar yüksek seyretmesi olarak görünür, ve bu fark genellikle sektörel bir özellik olarak açıklanır.
Üçüncü ve en pahalı bedel, değerleme masasında ortaya çıkar. Bir yatırım komitesi ya da alıcı tarafı danışmanı, süreçlerin manuel olduğunu bir maliyet kalemi olarak değil, **devredilebilirlik sorunu** olarak fiyatlar. Sorulan soru "bu iş ne kadara mal oluyor" değil, "bu işi yapan kişi ayrıldığında ne olur" sorusudur; ve cevap süreç dokümantasyonunda değil, o kişinin hafızasında duruyorsa, sonuç öngörülebilir biçimde ya değerleme çarpanında bir iskonto, ya kilit personel için bağlayıcı bir kalış taahhüdü, ya da earn-out yapısında kapanış sonrasına sarkan bir performans koşulu olur. Bir şirketin değerlemesini belirleyen şey performansın kendisi değil, performansın kişilerden bağımsız olarak tekrarlanabilir olduğunun gösterilebilmesidir; manuel süreç tam olarak bu gösterimi imkânsızlaştırır.
Bu eğilimi nötrleyen mekanizma bireysel ikna ya da farkındalık eğitimi değildir; sürecin sahipliğini kişiden role taşıyan bir mimari düzenlemedir. Bu düzenlemenin dört bileşeni vardır: birincisi, her tekrarlayan sürecin **istisna oranının** ölçülmesi — kaç işlemin standart akıştan saptığı, ve bu sapmanın hangi kalemlerden kaynaklandığı; ikincisi, otomasyon kararının süreç düzeyinde değil işlem tipi düzeyinde alınması, zira çoğu süreçte işlemlerin büyük çoğunluğu standart, küçük bir azınlığı gerçekten yargı gerektirir; üçüncüsü, süreç sahipliğinin bir isim değil bir rol tanımı olarak yazılması, ve bu tanımın devir prosedürünü içermesi; dördüncüsü, otomasyona geçen sürecin sahibinin, otomasyon sonrası işini kaybetmek yerine istisna yönetimi ve tedarikçi ilişkisi gibi daha üst bir hatta konumlandırılacağının **karar anında** yazılı olarak belirlenmesi.
Bu bileşenlerin sırası tesadüfi değildir. İstisna oranı ölçülmeden yapılan otomasyon girişimleri tipik olarak yarıda kalır, çünkü sistem yüzde beşlik istisna kümesini karşılayamadığında tüm süreç manuel akışa geri döner ve kurum içinde "denedik, olmadı" biçiminde kalıcı bir hafıza bırakır; bu hafıza, ikinci girişimin önündeki en güçlü engeldir. Aynı şekilde, dördüncü bileşen atlandığında — yani otomasyonun süreç sahibi için ne anlama geldiği belirsiz bırakıldığında — projenin teknik tarafı ilerlerken veri temizliği, kural tanımı ve test aşamalarında sürekli gecikme üretilir, ve bu gecikme hiçbir zaman açık bir itiraz olarak ifade edilmez.
BEIREK'in bu alandaki müdahalesi, teknoloji seçimiyle değil süreç envanteriyle başlar: her tekrarlayan iş için işlem hacmi, standart-dışı işlem oranı, işleme dokunun kişi sayısı ve o işin kesintiye uğraması hâlinde kapanan pencerenin süresi kaydedilir; bu dört veri, otomasyon önceliğini kanaate değil ölçüye bağlar. Ardından her süreç için bir devir testi işletilir — süreç sahibinin bulunmadığı bir dönemde işin yazılı prosedürle yürütülüp yürütülemediği fiilen sınanır — ve testin başarısız olduğu noktalar, otomasyon kapsamının değil, dokümantasyon borcunun haritasını verir. Karar kaydı onay anında değil öneri anında tutulur; bir otomasyon önerisinin hangi gerekçeyle ertelendiği yazılır, ve aynı gerekçe bir sonraki gözden geçirmede yeniden sınanır.
Bu kaydın işlettiği ritim, yılda bir kez tekrarlanan basit bir sorudur: geçen dönem erteleme gerekçesi olarak yazılan koşul hâlâ geçerli midir? Hacim aynı mı kaldı, istisna oranı düştü mü, kural seti kararlı hâle geldi mi? Bu soru sorulmadığında, bir kez verilmiş erteleme kararı sessizce kalıcı bir mimari tercihe dönüşür, ve beş yıl sonra kimse o tercihin hangi koşullar altında verildiğini hatırlamaz. Karar kaydının işlevi haklı çıkmak değil, koşulun değiştiğini fark edecek bir tetikleyici bırakmaktır.
Manuel kalmayı sürdüren bir işin gerçek maliyeti, o işi yapmak için harcanan saat değil, o işin varlığının kuruma ne söylemeyi engellediğidir. Bir süreç manuel olduğu sürece, o sürecin ürettiği veri kurumun dışına gösterilebilir bir kanıt olarak çıkmaz; ne tedarikçiye karşı bir pazarlık zemini, ne bankaya karşı bir operasyonel olgunluk göstergesi, ne de alıcıya karşı bir devredilebilirlik ispatı olur. Otomasyon kararının hangi düzeyde alındığı — bir BT bütçesi kalemi olarak mı, yoksa şirketin kişilerden bağımsızlaşma programının bir parçası olarak mı — bu farkı tek başına belirler.