Çoğu şirkette yapay zekâ kararı bir araçla başlar. Bir demo izlenir, lisans alınır, ekibe duyurulur ve birkaç eğitim yapılır. Üç ay sonra lisansların büyük kısmı kullanılmıyordur. Bunun sebebi genellikle aracın kötü olması ya da ekibin direnç göstermesi değildir; araç, hiç tarif edilmemiş bir sürecin içine yerleştirilmeye çalışılmıştır.
Daha sağlam bir yol var: tek bir süreç seçmek, o sürecin bugün nasıl işlediğini ölçmek ve 30 günlük bir pilotun sonucunu bu ölçümle karşılaştırmak. Araç bu sıranın sonunda gelir. Bu yazıda yöntemi, gelen müşteri taleplerinin doğru kişiye ulaştırılması üzerine kurulmuş temsili bir örnekle adım adım anlatıyoruz.
Araçla başlamak neden tıkanıyor?
Araç görünürdür: demosu izlenebilir, fiyatı bellidir, yönetime sunulabilir. Süreç ise çoğu şirkette yazılı değildir; işi yapan kişinin alışkanlıklarında yaşar. "Hangi talebe kimin bakacağı belli değil" gibi bir sorunu ne sunabilir ne de bütçeleyebilirsiniz. Bu yüzden karar, görünür olanın etrafında verilir.
Oysa bir yapay zekâ aracı, bir sürecin belirli bir adımını üstlenir. Hangi adımı üstleneceği tanımlanmamışsa ekip aracı kendi işine nereden bağlayacağını bilemez ve bildiği yönteme geri döner. Ortaya çıkan tablo dirence benzer, ama kaynağı eksik tanımdır.
Doğru sıra: süreç, ölçüm, araç
İlk adım süreci yazmaktır: hangi adımlar var, her birini kim yapıyor, ne sıklıkla ve ne kadar sürede. Bu çalışma yapay zekâ olmasa da değerlidir; birçok şirket kendi sürecini ilk kez bu aşamada kâğıda döker ve o ana kadar fark etmediği boşlukları görür.
İkinci adım ölçümdür. Pilot başlamadan önce süreç bir hafta boyunca, hiçbir şey değiştirilmeden kaydedilir. Bu kayıt olmadan pilotun sonunda elinizde yalnızca izlenim kalır ve yeni bir şey denemenin heyecanı izlenimi neredeyse her zaman olumlu yöne çeker. Araç ancak bu iki adımdan sonra seçilir; süreç ve ölçüm netleştiğinde seçenekler arasındaki fark da küçülür.
Temsili örnek: gelen talepleri doğru kişiye ulaştırmak
Orta ölçekli bir şirket düşünelim. Web sitesindeki form ve genel e-posta adresi üzerinden ayda yaklaşık 400 talep geliyor: satış soruları, teknik destek, fatura, iade, şikâyet ve iş başvuruları. Talepleri tek bir müşteri hizmetleri sorumlusu okuyor ve her birini ilgili kişiye iletiyor. Gün içinde başka işleri de olduğu için gelen kutusuna ancak birkaç saatte bir bakabiliyor.
Bu süreç neden iyi bir aday?
İlk pilot için seçilecek süreç dört koşulu birlikte karşılamalıdır ve bu süreç dördünü de karşılıyor. Sık tekrarlanıyor: ayda 400 talep, 30 günde yeterli veri birikmesi için fazlasıyla yeterli. Kuralları tarif edilebilir: hangi tür talebin kime gideceği tek bir sayfaya yazılabilir. Verisi zaten bir sistemde duruyor: form kayıtları ve e-postalar. Hata maliyeti düşük: yanlış kişiye giden bir talep birkaç dakikada düzeltilir ve müşteriye hiçbir çıktı gitmez, çünkü cevabı yine bir insan yazar.
Bir konunun ise araç seçiminden önce karara bağlanması gerekiyor: talepler isim, telefon ve sipariş bilgisi gibi kişisel veriler içeriyor. Bu yüzden pilot, girilen verinin model eğitiminde kullanılmadığı kurumsal ve gizlilik uyumlu bir lisansla yürütülüyor. Ücretsiz ve bireysel sürümler bu süreç için uygun değil.
Taban haftası: dört sayı
Pilottan önceki hafta müşteri hizmetleri sorumlusu işini her zamanki gibi yapıyor ve dört şeyi bir tabloya yazıyor: o hafta kaç talep geldiği, bir talebi okuyup yönlendirmenin kaç dakika sürdüğü, kaç talebin yanlış kişiye gidip geri döndüğü ve bu işe toplam kaç saat ayrıldığı. Hafta sonunda tablo şunu gösteriyor: yaklaşık 100 talep gelmiş, her biri ortalama 4 dakika sürmüş, toplam yük 7 saate yaklaşmış. Bir talebin doğru kişiye ulaşması ortalama 5 saat almış ve taleplerin %15'i önce yanlış kişiye gitmiş.
Ölçümü yöneticinin değil, işi yapan kişinin tutması önemli. Yöneticinin tuttuğu ölçüm, ölçülen kişinin o hafta daha hızlı çalışmasına yol açar ve taban gerçekte olduğundan iyi görünür.
Dört hafta
30. gün: sayılar
| Ölçüt | Taban haftası | 4. hafta |
|---|---|---|
| Haftalık talep | Yaklaşık 100 | Yaklaşık 100 |
| Talebin doğru kişiye ulaşma süresi | Ortalama 5 saat | Ortalama 40 dakika |
| Talep başına harcanan süre | 4 dakika | 1,5 dakika |
| Haftalık toplam iş yükü | Yaklaşık 7 saat | Yaklaşık 2,5 saat |
| Önce yanlış kişiye giden talep | %15 | %18 |
Yalnızca ilk dört satıra bakan biri pilotu başarılı sayar. Son satır ise başka bir şey söylüyor: yanlış yönlendirme oranı azalmamış, artmış. Artışın neredeyse tamamı iade ve şikâyet taleplerinden geliyor. Dördüncü haftadaki görüşmede de aynı tablo çıkıyor: ekip hızdan memnun, ama iade taleplerini her seferinde ikinci kez kontrol ettiğini söylüyor.
Karar: düzelt ve tekrarla
30. gün kararı için üç seçenek pilotun başında yazılmıştı. Yaygınlaştırmak için üç şartın birlikte sağlanması gerekiyordu: sürede anlamlı iyileşme, tabandan kötü olmayan bir hata oranı ve ekibin devam etme isteği. Birinci ve üçüncü şart sağlandı, ikincisi sağlanmadı. Kapatmak için de bir sebep yok, çünkü iyileşme açık. Doğru karar, sorunu düzeltip 30 günü tekrarlamak.
Sorunun kaynağı araç değil, birinci haftada fark edilen tanım boşluğu. Şirket iade ile şikâyetin farkını hiç yazmadığı için makine de bu ayrımı tutarlı yapamıyor. Düzeltme iki adımlı. Önce ayrım yazılı bir kurala bağlanıyor; örneğin sipariş numarası içeren ve geri ödeme isteyen talep iadedir. Ardından bu iki kategori, ikinci pilot boyunca toplu onaya bırakılmadan tek tek sorumlunun kontrolünden geçiyor. İkinci 30 günün sonunda aynı dört sayıya yeniden bakılacak.
Örneğin asıl dersi de burada: pilot yalnızca yapay zekâyı test etmedi, şirketin kendi süreç tanımındaki bir boşluğu da görünür kıldı. Ölçüm yapılmasaydı bu boşluk, "yapay zekâ iadeleri karıştırıyor" gibi bir izlenim olarak kalacaktı.
Hangi süreçlerle başlanmaz?
Aynı şirkette ilk akla gelen iki aday aslında iyi bir başlangıç olmazdı. Haftalık yönetim raporunu derlemek zaman alıyor, ama ayda yalnızca dört kez yapılıyor. 30 günün sonunda dört tekrarla karar veremezsiniz; iyileşme olsa bile göremezsiniz. İş başvurularının ön elemesi ise sık tekrarlanıyor, fakat hata maliyeti yüksek: haksız yere elenen bir aday geri alınamaz bir sonuçtur, süreç doğrudan insanları etkiler ve kişisel veri açısından hassastır.
Bu iki süreç ileride ele alınabilir. Ama dört koşuldan birini karşılamayan bir süreci ilk pilot için zorlamak, pilotun tam o noktada tıkanmasına ve yapay zekânın işe yaramadığı gibi yanlış bir sonuca varılmasına yol açar.
Pilotu kim yönetmeli, ekibe ne söylenmeli?
Pilotun tek bir sahibi olmalı ve bu kişi bilgi işlemden değil, işin içinden gelmeli. Örnekte bu kişi müşteri hizmetleri sorumlusu, çünkü bir yönlendirmenin doğru olup olmadığını en iyi o değerlendirebilir. Bilgi işlem erişim, güvenlik ve lisans konularında destek verir. Süreç sahibinin taban haftası dahil beş hafta boyunca haftada 4–6 saat ayırması gerekir. Pilotun asıl maliyeti bu zamandır; ayrılamayacaksa başlamamak daha doğrudur.
Pilot başlamadan ekibin iki sorusu cevaplanmalı. İlki: "Bu benim işimi mi alacak?" Örnekte sorumlunun haftasında yaklaşık 4,5 saat boşalıyor; bu zamanın nereye gideceği, örneğin bekleyen taleplere daha hızlı dönmeye, baştan ve yazılı olarak söylenmeli. İkincisi: "Bir talep yanlış yönlendirilirse sorumlusu kim?" Kural basit: makine önerir, insan onaylar ve sorumluluk onaylayandadır.
Kendi şirketinizde nereden başlamalı?
Gelen talepler yalnızca bir örnek. Aynı dört koşulu çoğu zaman karşılayan başka süreçler de var: tekliflerin ilk taslağının hazırlanması, toplantı notlarından görev ve sonraki adım çıkarılması, uzun yazışmaların özetlenmesi, sipariş ve fatura belgelerindeki verinin sisteme aktarılması. Hangisinin sizin için doğru aday olduğunu sıklık, kural netliği, veri erişimi ve hata maliyetine bakarak puanlayabilirsiniz.
Yapay zekâ işleyen bir sistemi hızlandırır; tanımlanmamış bir sistemin yerini tutmaz. Bu yüzden ilk pilotun en kalıcı çıktısı çoğu zaman bir araç değil, yazıya dökülmüş ve ölçülen bir süreçtir. Aşağıdaki rehber, kendi aday süreçlerinizi puanlayabileceğiniz skorkartı ve hafta hafta pilot planını içeriyor.