Otomasyon bir işi ortadan kaldırmaz; o işi yapan kişinin gününü başka bir işe kaydırır. Formu dolduran kişi, formu dolduran sistemi denetleyen kişiye dönüşür. Bu daha kolay bir iş değildir — farklı bir iştir, farklı bir beceri ister ve kendi başına bir iş yükü yaratır.
Bu yazıda o geçişi süsleyerek değil, olduğu gibi anlatıyoruz: eski işin tarifi, yeni işin tarifi, yeni işin istediği beceriler, denetimin kendi maliyeti ve ekibin bu değişime nasıl hazırlanacağı. Yazı, sistemi kuracak olan patrondan çok, sistemi her gün kullanacak olan kişiye bakıyor — çünkü otomasyon projelerinin çoğu teknoloji yüzünden değil, onu kullanacak kişi süreci sahiplenmediği için tıkanır.
Eski işin tarifi: veriyi taşımak, kopyalamak, hatırlamak
Bir satınalma sorumlusunun ya da satış destek elemanının gününü açıp bakarsanız, saatlerin nereye gittiği bellidir. Mailden gelen talebi okur, kalemleri tek tek ayıklar, stok listesinden bakar, bulamadığını tedarikçiye sorar, gelen cevabı Excel'e yazar, oradan teklif şablonuna geçirir, teklifi mail olarak geri gönderir. Ekran değiştirir, kopyalar, yapıştırır, format düzeltir.
Bu işin üç bileşeni vardır ve üçü de birbirinden farklıdır:
- Taşıma: Bir yerdeki veriyi başka bir yere aktarmak. Maildeki kalemi tabloya, tablodaki kodu ERP'ye, ERP'deki fiyatı teklife.
- Eşleştirme: Müşterinin yazdığı tarifi elinizdeki ürünle çakıştırmak. Müşteri "8'lik siyah boru, 6 metre" yazar; sizin listenizde o kalem bambaşka bir kodla durur.
- Hatırlama: Hangi müşteriye hangi iskontoyu verdiğinizi, hangi tedarikçinin hangi kalemde hızlı olduğunu, hangi teklifin cevabının beklendiğini akılda tutmak.
Bu üç bileşenin ilki ve büyük ölçüde ikincisi, yazılımın iyi yaptığı işlerdir. Üçüncüsü zaten yazılımın yapması gereken iştir; insanın hafızasında durması bir yetenek değil, bir risktir. Veri girişi bir iş adımıdır, bir meslek değildir — ve otomasyon tam olarak bu adımı devralır.
Yeni işin tarifi: kaydı okumak, sınırı görmek, istisnayı yönetmek
Sistem kurulduğunda kişinin önüne gelen şey artık boş bir form değil, doldurulmuş bir öneridir. Talep okunmuş, kalemler ayrıştırılmış, stokta eşleşenler işaretlenmiş, eşleşmeyenler ayrı bir kutuya konmuş, tedarikçiye sorulacaklar hazırlanmıştır. Ekranda bir onay bekler.
İşte yeni iş burada başlar. Kişi artık şunları yapar:
- Şüpheli kaydı fark etmek. Sistem bir kalemi eşleştirmiştir, kutucuk yeşildir, ama fiyat geçen aya göre garip durmaktadır. Ekranda hiçbir şey "hata" demez; sadece bir şey yerine oturmaz.
- Sınır dışı durumu değerlendirmek. Müşteri normalde 30 gün vadeli çalışır, bu talepte peşin yazmıştır. Kural tablosunda böyle bir satır yoktur. Bu kararı insan verir.
- Sistemin yanlışını yakalamak. Kural doğru işlemiştir ama kuralın kendisi yanlıştır. Bunu ancak işi bilen kişi görür.
- İstisnayı yönetmek. Acil talep, yarım teslimat, iptal edilen sipariş, tedarikçinin geri çektiği fiyat. Süreçlerin en pahalı kısmı istisnalardır ve otomatikleşen kısım büyüdükçe insanın gününde istisnaların payı artar.
- Müşteriyle konuşmak. Talebin belirsiz olduğu, işin pazarlığa döndüğü, ilişkinin devreye girdiği yer. Bu yer küçülmez, tersine daha görünür hale gelir.
Dikkat edilirse listenin tamamı karar işidir. Kişinin zamanı taşımadan karara kayar. Kolaylaşmaz; yoğunlaşır. Beş saatlik kopyala-yapıştırın yerine, iki saatlik yüksek dikkat gelir.
Somut bir örnek: müşteriden gelen mailde "acil, geçen seferki gibi olsun, miktarı iki katına çıkarın" yazıyor. Sistem geçmiş siparişi bulur, kalemleri iki katına çıkarır, güncel fiyatla teklifi hazırlar ve önünüze koyar. Buraya kadarı doğrudur. Ama o kalemlerden biri artık tedarikçide kalmamıştır, benzeri farklı bir standartla gelmektedir ve müşterinin işinde o fark önemlidir. Bunu ekranda gören tek taraf, o müşteriyle daha önce konuşmuş kişidir. Sistemin ürettiği teklif hatalı değildir; eksiktir. Aradaki farkı görmek yeni işin tam olarak kendisidir.
Yeni işin istediği beceri: "bu doğru görünüyor ama yanlış" diyebilmek
Form doldurma becerisi öğrenmesi kolay bir beceridir: ekranı bir kez gösterirsiniz, kişi birkaç günde alışır. Denetleme becerisi böyle değildir. İki parçası vardır ve ikisi de deneyimle oturur.
Birincisi: neye bakılacağını bilmek. Ekranda kırk satır vardır, kırkını da tek tek kontrol etmek mümkün değildir. Deneyimli kişi bakılacak üç yeri bilir: birim fiyatın oynadığı kalemler, daha önce hiç satılmamış ürün kodları, alışılmadık miktarlar. Bu bilgi süreçte yaşayarak birikir; hiçbir yazılım bunu hazır vermez.
İkincisi: biçimsel doğruya güvenmemek. Sistemin ürettiği çıktı her zaman düzgün görünür. Tablo hizalıdır, alanlar doludur, tarih formatı doğrudur. Yanlış olan şey görüntü değil, içeriktir. "Bu doğru görünüyor ama yanlış" cümlesini kurabilmek, otomatik süreçlerde en değerli beceridir — ve genellikle o işi yıllardır elle yapmış kişide bulunur. Bu yüzden süreci bilen kişiyi sistemin dışına itmek değil, merkezine almak gerekir.
Eskiden, şimdi, gereken yeni beceri
| Eskiden yapılan iş | Şimdi yapılan iş | Gereken yeni beceri |
|---|---|---|
| Mailden kalemleri okuyup tabloya yazmak | Ayrıştırılmış kalem listesini gözden geçirmek | Eksik/yanlış ayrıştırmayı bir bakışta görmek |
| Stok listesinde kod aramak | Sistemin önerdiği eşleşmeyi onaylamak veya reddetmek | Benzer ama yanlış eşleşmeyi ayırt etmek |
| Tedarikçiye tek tek mail atmak | Hangi kalemin dışarı sorulacağına karar vermek | Sorunun ne zaman değeceğini kestirmek |
| Fiyatı elle hesaplayıp teklife geçirmek | Hesaplanmış fiyatı makul bulup bulmadığına karar vermek | Fiyat aralığı sezgisi, sapmayı fark etmek |
| Hangi teklifin cevabı geldi diye hatırlamak | Takip listesindeki istisnaları çözmek | Öncelik sırası kurmak, sıkışanı seçmek |
| Şablonu kurallara göre doldurmak | Kuralın kendisinin doğru olup olmadığını söylemek | Süreci tarif edebilmek, kuralı dille ifade etmek |
Denetim de bir iş yüküdür: sınırsız kontrol diye bir şey yok
Otomasyon anlatılırken atlanan kısım şudur: denetim bedava değildir. "Her çıktıyı insan kontrol etsin" cümlesi kulağa güvenli gelir ama uygulanamaz. Günde on teklif için mümkündür, yüz teklif için değildir. Her satırı kontrol edilen bir sistem, elle yapılan işten daha yavaş çalışır ve kimse uzun süre öyle çalışmaz — birkaç hafta sonra kontrol, tıklamaya dönüşür. Göz gezdirilen bir onay ekranı, olmayan denetimden daha tehlikelidir; çünkü kayıtta "kontrol edildi" yazar.
Bu yüzden denetimin de bir tasarımı olmalıdır. Pratikte üç şey belirlenir:
- Eşik: Hangi tutarın, hangi miktarın, hangi müşteri tipinin üstündeki her kayıt mutlaka insana düşer. Altındakiler otomatik akar.
- Örnekleme: Eşiğin altındaki kayıtların rastgele bir kısmı düzenli olarak elden geçirilir. Amaç o kaydı düzeltmek değil, sistemin sapıp sapmadığını erken görmektir.
- Tetikleyici: Sistem kendi emin olmadığı yeri işaretler — eşleşmeyen kalem, ilk kez görülen ürün tarifi, alışılmadık bir fiyat. Bu kayıtlar sıraya girmez, doğrudan öne alınır.
Metal ticaretinde kurduğumuz sistemde bu ayrım en başından yapıldı: 1.500+ gerçek talep ve 8.000+ kalemlik tedarikçi stok listesi üzerinde çalışan sistemde isabet %99'un üzerinde ölçüldü, ama ölçüm işin sonu değil başıydı — kalan kısmın insana nasıl ve ne zaman düşeceği ayrıca kurgulandı. Nasıl çalıştığını vaka sayfasında ayrıntılı anlattık.
Ekip buna nasıl hazırlanır: eğitimin içeriği değişir
Klasik yazılım eğitimi ekran turudur: şu menü, şu buton, şu rapor. Otomatik bir süreçte bu eğitim yetmez, çünkü kişi zaten ekranı doldurmayacaktır. Eğitimin konusu artık "nasıl doldurursun" değil, "yanlışı nasıl anlarsın"dır.
Uygulamada işe yarayan yöntem şudur: sistemi devreye almadan önce birkaç hafta paralel çalıştırın. Kişi işi eskisi gibi yapsın, sistem de aynı işi arka planda yapsın, sonuçlar yan yana konsun. Ayrışan yerler eğitim malzemesidir — hem kişi sistemin nerede yanıldığını görür, hem de sistemi kuran taraf kuralın nerede eksik olduğunu öğrenir. Bu dönemde "sistem bunu neden böyle yaptı" sorusunun cevabı verilebilmelidir; verilemiyorsa süreç henüz devreye alınmaya hazır değildir.
İkinci yöntem, hatalı örnek arşivi tutmaktır. Yakalanan her yanlış kayıt, kısa bir notla saklanır: ne oldu, nasıl fark edildi, ne yapıldı. Birkaç ay sonra bu arşiv, yeni gelen kişinin en iyi eğitim setidir. Süreç bilgisini kişinin kafasından çıkarıp yazıya geçirmenin en ucuz yolu budur. Kurulum sürecimizi bu mantık üzerine kurduk.
Kadro kararı teknolojinin değil, firmanın kararıdır
Burada dürüst olmak gerekir. Bir süreç otomatikleştiğinde ortaya çıkan zaman, iki şekilde kullanılabilir: aynı ekiple daha çok talep karşılamak ya da daha az kişiyle aynı işi yapmak. Bu bir yönetim tercihidir; teknolojinin dayattığı bir sonuç değildir. Gördüğümüz kadarıyla küçük ve orta ölçekli firmaların büyük çoğunluğu birinciyi seçer, çünkü darboğaz genellikle personel sayısı değil, karşılanamayan talep hacmidir. Ama bu seçimi yapan firmadır ve ekibe söylenmesi gereken şey de budur — belirsizlik, gerçeğin kendisinden daha çok direnç üretir.
Bir fren cümlesi: kötü tanımlanmış bir süreç otomatikleştiğinde düzelmez, daha hızlı bozulur. Fiyatlama kuralınız kişiden kişiye değişiyorsa, stok verisi güncel değilse, hangi işin kimde olduğu belli değilse, önce o dağınıklığı toplamak gerekir. Yazılım bir düzeni hızlandırır; düzensizliği de aynı hızla çoğaltır. Bu durumda doğru cevap projeyi ertelemek değil, kapsamı daraltmak ve düzeni oturmuş tek bir adımdan başlamaktır.
Özet
Otomasyon, bir kişinin gününü yiyen adımı devralır ve onun zamanını karar verilen yere kaydırır. Yeni iş — şüpheliyi fark etmek, sınırı değerlendirmek, istisnayı yönetmek, sistemin yanlışını yakalamak — daha kolay değildir; farklıdır ve eğitim ister. Denetimin kendisi de bir yüktür, o yüzden eşiği, örneklemesi ve tetikleyicisi baştan tasarlanmalıdır. Bu geçişi doğru kurgulayan firma, aynı ekiple belirgin biçimde daha çok iş karşılar. Kendi sürecinizde hangi adımın devredilebileceğini ve kararın nerede insanda kalması gerektiğini konuşmak isterseniz, teklif alın ya da yapay zeka personel ekibi sayfasındaki rol tariflerine göz atın.
Sıkça Sorulan Sorular
Ekipteki arkadaşlar sistem kurulunca işlerini kaybedeceklerini düşünüyor, ne söylemeliyim?
Her çıktıyı tek tek kontrol etmemiz gerekir mi?
Süreci en iyi bilen kişi bilgisayarla arası iyi değil, sistemi o mu kullanacak?
Sistem yanlış yaparsa sorumluluk kimde olur?
Devreye alırken eski yöntemi hemen bırakmalı mıyız?
Sürecimiz çok dağınık, önce mi düzeltmeliyiz yoksa sistem düzeltir mi?
Yazar
Doğukan Azer ÇİFTCİYazılım Mühendisi
QuantKOD’da yazılım mühendisi. Ölçeklenebilir mimariler, özel yazılım geliştirme ve doğru teknoloji seçimleri üzerine yazıyor.