Pilot neden üretime geçmiyor

Demo neyi ölçmez

Bir pilot en iyi ihtimalle şunu kanıtlar: seçilmiş bir veri kümesinde, seçilmiş bir görevi, başında deneyimli biri dururken model yapabiliyor. Üretim bu üç seçimi de elinizden alır. Veri ayıklanmadan gelir, görev istisnalarıyla gelir, başında kimse durmaz.

Bu yüzden pilot sonrası doğru soru “model yeterince iyi mi” değil, “bu iş model yüzde doksan doğruyken de yürür mü” olmalı. Yürüyorsa üretime geçebilirsiniz. Yürümüyorsa yapılacak şey daha iyi bir model aramak değil, süreci yeniden tasarlamak.

Bu ayrım, çoğu projede iki hafta ile altı ay arasındaki farkı belirliyor.

Bunu erken görmenin bir yolu var: pilotu iyi ihtimale göre değil, kötü ihtimale göre kurun. Ekibe en temiz elli belgeyi değil, geçen ayın en sorunlu elli belgesini verin. Demo daha az etkileyici olur, karar daha doğru çıkar.

Gerçek veri neye benziyor

Pilotlar temiz veriyle çalışır, çünkü pilot verisini bir insan seçer. Gerçek bir salı günü şöyle görünür: eğri taranmış bir PDF, iki sayfası eksik bir sözleşme, aynı tedarikçinin üç farklı yazımı, tablo programında tarih sanılıp bozulmuş bir ürün kodu ve yanlış klasöre düşmüş on dosya.

Bunu ölçmenin ucuz bir yolu var: son doksan günün gerçek girdilerinden rastgele iki yüz kayıt çekin, hiç ayıklamadan sisteme verin ve üç sayı tutun.

• Kaç kayıt hiç işlenemedi? Bunlar görünür hatalar ve en zararsız olanları.
• Kaç kayıt işlendi ama yanlış çıktı verdi?
• Yanlışların kaçı sessiz hata? Yani sistem emin görünürken yanlış sonuç veriyor.

Belirleyici olan üçüncüsü. Sessiz hata, insanın kontrol refleksini de zayıflattığı için maliyeti katlanarak artıyor. Sessiz hata oranı yüzde ikinin üzerindeyse üretim tarihini konuşmak erken; önce çıktının güvenilirliğini ölçülebilir hâle getirin.

Bu ölçümü müşterinin ekibiyle birlikte yapmakta fayda var. İki yüz kaydın çıktısını birlikte okumak, otuz sayfalık bir değerlendirme raporundan daha ikna edici oluyor; beklentiyi de yerine oturtuyor: kimse yüzde yüz doğruluk beklemiyor.

Sahibi olmayan sistem ayakta kalmıyor

Pilotun bir sahibi vardır: onu isteyen kişi. Üretimin sahibi çoğu zaman yoktur. Proje biter, ekip dağılır, sistem çalışmaya devam eder ve altı ay kimse çıktısına bakmaz.

Sahip, haftada bir saatini kayıtlara bakmaya ayıran ve eşikleri değiştirme yetkisi olan kişidir. Teknik olması gerekmez, işi bilmesi gerekir. Bir isim yazılı değilse sistem altı ayda kullanımdan düşüyor; bozulduğu için değil, arkasında kimse durmadığı için.

Devir teslim toplantısında sorulacak en yararlı soru bu: bu sistemin çıktısına önümüzdeki çeyrekte kim bakacak? Cevap bir departman adıysa cevap yok demektir.

Sahibi bulmanın ucuz bir yolu var: teslimden sonraki ilk ay için takvime haftalık on beş dakikalık bir aralık koyun. Gelen kişi sahibidir. Takvimde o aralığa yer bulunamıyorsa sistem kimsenin işine yaramıyor demektir; bunu altı ay beklemeden öğrenmek iyi olur.

Sahiplik aynı zamanda bir bütçe meselesi. Sistemin bakımı kimin bütçesinden çıkıyor: model ücreti, küçük düzeltmeler, yılda bir gelen sağlayıcı değişikliği. Bu kalemler proje bütçesinde biter, işletme bütçesinde başlar. Arada kalan kalemler ilk fatura tartışmasında ortaya çıkıyor.

Ölçeceğiniz sayıyı baştan seçin

Pilotların büyük kısmı “iyi çalışıyor” hissiyle bitiyor. Bu his bütçe toplantısında işe yaramıyor. Sistemi savunacak kişinin elinde tek bir sayı olmalı ve o sayı pilottan önce ölçülmüş olmalı.

İyi sayılar dar ve sıkıcı olanlardır: bir faturanın masaya girmesiyle muhasebeye düşmesi arasındaki süre, ilk yanıta kadar geçen saat, elle düzeltilen satır oranı, ayda kaç teklifin zamanında çıkmadığı. Model doğruluğu bu listede yok; çünkü bu sayı kimsenin bütçesinde bir karşılığa dönüşmüyor.

Karşılaştırmayı da dürüst tutun. Yeni sistemi en iyi haftasıyla, eski süreci en kötü haftasıyla ölçerseniz çıkan sayıyı altı ay sonra kimse savunamaz.

Ölçmenin bir yan faydası daha var: hangi adımın gerçekten pahalı olduğunu görüyorsunuz ve cevap her zaman yapay zekâ olmuyor. Geçen yıl bir müşteride ölçtüğümüz gecikmenin dörtte üçü onay bekleyen bir e-postadaydı; modelin yapabileceği bir şey yoktu, kuralı değiştirmek yetti.

Hata durumları ve geri alma yolu

Üretim sistemleri hata yapmadıkları için değil, hataları görünür ve geri alınabilir olduğu için ayakta kalıyor. Bunun için üç parça yeterli: güven eşiği, insan kuyruğu ve geri alma.

Modelin güven skoru eşiğin altındaysa çıktı uygulanmaz; kuyruğa düşer ve insan bakar. Uygulanan bir çıktının yanlış olduğu anlaşıldığında geri alma tek tuşa bağlı olmalı. Bu iki mekanizma, doğruluk oranını beş puan artırmaktan daha fazla güvence sağlıyor.

Bir de sağlayıcı tarafı var: model sağlayıcısında kesinti olduğunda ne oluyor? İki makul cevap var: işi sıraya alıp sonra işlemek ya da eski kural tabanlı akışa dönmek. Cevabı olmayan sistemlerde kesinti gününde beş yüz kayıt işlenmeden bekliyor.

Kuyruğun da bir sahibi olmalı; yoksa üç günde dört yüz kayıt biriktirip kimsenin açmadığı bir klasöre dönüşüyor. Kuyruğa günlük bir üst sınır koyun: sınır sürekli aşılıyorsa yapılacak şey eşiği düşürmek değil, süreci değiştirmek.

Son yüzde yirmi: entegrasyon

Model çalıştıktan sonra kalan iş küçük görünür ama küçük olmaz. Kalan işin ne olduğu da bellidir.

• Kimlik ve yetki: hangi kullanıcı hangi kaydı görebiliyor, hangi çıktıyı onaylayabiliyor.
• Kaynak sistemle eşleme: alan adları, birim ve para birimi dönüşümleri, boş bırakılabilen alanlar.
• Yeniden deneme ve mükerrer kayıt koruması: aynı fatura iki kez geldiğinde ne olacağı.
• İşlem kayıtları, uyarılar ve nöbet: sistem bozulduğunda kimin telefonu çalıyor ve o kişi ne yapabiliyor.

Bunları pilot bütçesine koymak zorunda değilsiniz, ama üretim bütçesinden çıkaramazsınız. Bizim tecrübemizde, çalışan bir prototipten güvenilir bir servise geçmek bir o kadar daha zaman alıyor. Bu süreyi baştan söylemek, sonradan istemekten kolay.

Bu işi bitiren şey teknik zorluğun aşılması değil, sahibinin belli olması. Entegrasyon iki ekip arasında kaldığında haftalar takvimde kayboluyor; tek kişiye verildiğinde çoğu birkaç günde bitiyor.

Gecikme ve maliyet bütçesi

Pilotta kimse saniyeye ya da kuruşa bakmaz. Üretimde ikisi de ürünün parçasıdır. Şu dört rakamı önce yazın, sonra geliştirmeye başlayın.

Bu dördü yazılı değilse sistem üretime hazır sayılmaz; hazır olup olmadığını ölçecek bir ölçüt yoktur.

Maliyet tarafında bir de sessiz kalem var: yeniden çalıştırma. Bozulan toplu iş baştan başlatılıyor ve fatura ikiye katlanıyor. Kaldığı yerden devam edebilen bir akış ilk ayda kendini ödüyor.

Üretime geçiş listesi

Pilotu üretime taşımaya karar verdiğimizde bu listeyi geçiyoruz. On madde, hepsi bir günde doğrulanabilir.

Bu on maddenin hiçbirinde model kalitesi geçmiyor; pilotlar çoğunlukla model yüzünden durmuyor.

Bir de tarih koyun. Üretime geçiş tarihi olmayan pilotlar bitmiyor, yavaşlıyor; altı ay sonra model de eskidiği için işe baştan başlamak gerekiyor.