YZ Pilotları Neden Canlıya Geçemiyor ve Onları Canlıya Taşımak İçin Ne Gerekir?

Yapay zekâ pilotlarının çoğu yanlış model seçildiği için başarısız olmaz. Takılırlar, çünkü bir demo ile canlı bir sistem birbirinden çok farklıdır ve aradaki iş nadiren planlanır. Pilot, bir şeyin temiz bir veri setinde ve sabırlı bir izleyici önünde mümkün olduğunu gösterir. Canlı sistem ise gerçek veriyle, gerçek sistemlerin içinde ve bunu talep etmemiş kişiler için çalışmaya devam ettiğini kanıtlamak zorundadır.

Kurumunuz umut vadeden iki üç YZ pilotu yürüttüyse ama hiçbiri henüz günlük operasyonun parçası değilse, baktığınız boşluk tam olarak budur. Bu insight, pilotların nerede takıldığını, canlıya almanın gerçekte ne gerektirdiğini ve birinden diğerine geçişin nasıl planlanacağını anlatıyor.

Canlıya almak gerçekte ne gerektirir?

Bir pilot için model ve prompt yeterlidir. Canlıda çalışan bir YZ sistemi ise beş katman ister ve pilotların çoğu yalnızca birincisini kurar.

1. Model katmanı. Model, promptlar ve çıktının değerlendirilmesi. Her pilotun kurduğu kısım budur.
2. Veri katmanı. Şirketin gerçek verisine, günlük kullanımın gerektirdiği yetki, güncellik ve kaliteyle erişim. Pilotlar genelde dışa aktarılmış bir örnek veriyle çalışır.
3. Entegrasyon katmanı. İşin gerçekten yapıldığı sistemlere bağlantı: ERP, CRM, talep yönetimi, doküman arşivleri. Bu katman yoksa kullanıcılar YZ ile kendi araçları arasında kopyala yapıştır yapar ve kullanım birkaç hafta içinde söner.
4. Operasyon katmanı. İzleme, maliyet kontrolü, hata yönetimi, sürümleme ve pazartesi sabahı bir şey bozulduğunda net bir sorumlu.
5. Benimsenme katmanı. İnsanların gerçekten değiştirdiği bir iş akışı, eğitim ve sistemin tutulmaya değer olup olmadığını gösteren bir iş metriği.

Her pilot için işe yarayan bir test var: bu beş katmandan hangisi bugün mevcut ve canlıya geçtikten sonra her birinin sorumlusu kim? Sorumlusu olmayan katmanlar, projenin takılacağı yerlerdir. Henüz pilot aşamasına gelmediyseniz, 28 soruluk kurumsal yapay zekâ hazırlık değerlendirmemiz başlamadan önce nerede durduğunuzu görmenize yardımcı olur.

YZ pilotları neden canlıya geçemiyor?

Başarı ölçütü hiç tanımlanmadı

Birçok pilot, demonun toplantı odasını etkileyip etkilemediğine göre değerlendirilir. Canlıya geçiş ise bir sayı ister: haftada kazanılan saat, üst seviyeye aktarılmadan çözülen talep, bir süreçten düşen gün sayısı. Pilottan önce üzerinde anlaşılmış bir metrik yoksa kimse işe yarayıp yaramadığını söyleyemez ve bir sonraki aşamayı da kimse finanse etmez.

Pilot, canlı sistemin hiç görmeyeceği bir veriyle çalıştı

Özenle hazırlanmış bir veri dökümüyle kurulan pilot, canlı, dağınık ve yetkilerle korunan veriyi okuyan bir sistemden çok farklı davranır. Eksik alanlar, güncelliğini yitirmiş kayıtlar ve erişim kuralları ancak sistem gerçek ortamla karşılaştığında ortaya çıkar. Bunu geç fark eden ekipler çoğu zaman "YZ bizde çalışmıyor" sonucuna varır; oysa asıl sorun verinin hazır olmamasıdır.

Entegrasyonun sahibi yoktu

Model işin kolay kısmıdır; zor olan, onu insanların zaten kullandığı sistemlere bağlamaktır. Entegrasyon işi ekiplerin sınırlarını aşar: sistemler BT'nin, süreç iş biriminin, model YZ ekibinin sorumluluğundadır. Aradaki bağlantının sahibi olmadığında pilot, ara sıra açılıp sonra unutulan ayrı bir araç olarak kalır.

Güvenlik ve uyum en sona kaldı

Güvenlik incelemeleri, KVKK ve GDPR kontrolleri ve verinin nerede tutulacağı soruları çoğu zaman pilot başarılı olduktan sonra gündeme gelir. Bu noktada sistemin yeniden tasarlanmasını gerektirebilirler; özellikle pilot, canlı sistemin kullanamayacağı harici bir servise veri gönderdiyse. Bu soruları ilk haftanın gereksinimleri olarak ele almak, onaydan sonra sistemi yeniden kurmayı önler.

İşletme maliyeti hiç hesaplanmadı

On kullanıcılı bir pilotun çalıştırma maliyeti önemsizdir. Aynı sistemi bütün bir departman kullandığında, promptlar, önbellekleme ve model seçimi hiç optimize edilmediyse maliyet, yerini aldığı süreçten yüksek olabilir. İşlem başına maliyet, canlıya geçtikten sonraki ilk faturada değil, iş gerekçesinin içinde olmalıdır.

İş akışı değişmedi

Birinin gününe yeni bir adım ekleyen YZ sistemi, pilot boyunca kullanılır ve sonra bırakılır. Ayakta kalan sistemler ise bir adımı ortadan kaldırır: özet talebin içinde belirir, taslak CRM kaydının içinde hazır olur, rapor kimse istemeden gelir.

Kendi ekibinizle mi, bir ortakla mı, yoksa ikisiyle birden mi?

Artık birçok kurumun yetkin iç ekipleri var ve herkes aynı modellere erişebiliyor; bu yüzden işi kurum içinde yapmak makul bir ilk tepki. Asıl soru, ekibinizin YZ geliştirip geliştiremeyeceği değil. Asıl soru, ekibinizin zamanının en çok nerede değer ürettiği.

İç ekipler, işin ürününüze, müşterilerinize ve verinize dair derin bilgiye dayandığı yerlerde en güçlüdür. Onları en çok yavaşlatan ise pilot ile canlı arasındaki iştir: eski sistemlerle entegrasyon, canlı altyapı, izleme, güvenlik incelemeleri ve maliyet optimizasyonu. Bu iş projeden projeye tekrar eder ve ekibinizin teslim etmek için işe alındığı yol haritasıyla yarışır.

En iyi işleyen model genelde hibrittir. Kullanım senaryosu, alan bilgisi ve sistemin uzun vadeli sahipliği sizin ekibinizde kalır. Uzman bir ortak canlıya alma katmanlarını hızlandırır ve bilgiyi aktarır; böylece ekibiniz sistemi sonrasında kendisi işletip geliştirebilir. AI Integration Consulting çalışmalarımızda izlediğimiz yaklaşım da budur: kullanım senaryolarını önceliklendirmek, prototipi bir iş metriğine göre doğrulamak ve sonra sistemi müşterinin ekibiyle birlikte, onun yerine değil, canlıya almak.

Pilottan canlıya 12 haftalık yol

Bir pilot umut verdiğinde ve günlük operasyonun parçası olması gerektiğinde müşterilerimizle izlediğimiz sıra budur. Süreler kapsama göre değişir; sıra nadiren değişir.

• 1-2. hafta: Başarıyı ve sorumluları tanımlayın. Tek bir iş metriği, bir başlangıç değeri ve beş katmanın her biri için bir sorumlu üzerinde anlaşın. Güvenlik ve uyum sorularını sonraya değil, şimdiye koyun.
• 3-4. hafta: Gerçek veriye geçin. Sistemi canlı veriye, canlı yetkilerle bağlayın. Kaliteyi seçilmiş örneklerle değil, gerçek vakalarla ölçün.
• 5-7. hafta: İş akışına yerleştirin. Çıktıyı insanların zaten çalıştığı yere koyun. Günlerine bir adım eklemek yerine bir adımı kaldırın.
• 8-9. hafta: Operasyon katmanını kurun. İzleme, maliyet takibi, hata yönetimi ve modelin emin olmadığı durumlar için bir yedek akış ekleyin.
• 10-11. hafta: Sınırlı yaygınlaştırma. Tek bir ekiple başlayın, metriği başlangıç değeriyle karşılaştırın ve gerçek kullanımın ortaya çıkardığı sorunları giderin.
• 12. hafta: Karar verin. İlk haftada üzerinde anlaşılan metriğe göre büyütün, düzeltin ya da durdurun. Bir projeyi kanıta dayanarak durdurmak iyi bir sonuçtur; kanıtsız devam ettirmek değildir.

Ne yapılmamalı?

• Modelle başlamayın. Değiştirmek istediğiniz süreçle ve değiştiğini kanıtlayacak metrikle başlayın. Model seçimi bundan sonra gelir.
• Takılan bir pilotu düzeltmek için yeni bir pilot başlatmayın. Değer göstermiş ama canlıya geçememiş bir pilotta eksik olan iş entegrasyon ve operasyondur. Yeni bir pilot yalnızca kolay kısmı tekrarlar.
• Canlıya geçişi bitiş çizgisi saymayın. Modeller, veri ve maliyetler değişir. Sorumlusu ve izlemesi olmayan bir sistem, insanların onu kullanmayı bıraktığı fark edilene kadar sessizce bozulur.

Sık sorulan sorular

YZ projeleri neden başarısız oluyor?

Başarısız olan YZ projelerinin çoğu modelden dolayı başarısız olmaz. Veri erişimi, sistem entegrasyonu, güvenlik onayı, işletme maliyeti ve iş akışı değişikliği baştan planlanmadığı için pilot ile canlı arasında takılırlar. Pilottan önce bir iş metriği ve bu alanların her biri için bir sorumlu belirleyen projelerin canlıya giden yolu çok daha nettir.

YZ projelerinin yüzde kaçı başarısız oluyor?

Yayımlanan tahminler birbirinden çok farklıdır, çünkü araştırmalar başarısızlığı farklı tanımlar: bazıları hiç canlıya geçmeyen pilotları, bazıları canlıya geçip hedefini tutturamayan sistemleri sayar. Tek bir kurum için daha faydalı soru, kendi pilotlarından hangilerinin günlük kullanıma girdiği ve girmeyenlerin ortak noktasının ne olduğudur.

Bir YZ pilotunu canlıya almak ne kadar sürer?

Kapsamı iyi tanımlanmış ve pilotu hazır olan bir kullanım senaryosu için, verinin hazır olma durumuna ve işin içindeki sistem sayısına göre 8 ile 16 hafta gerçekçi bir aralıktır. En büyük değişken genelde modelin kendisi değil, entegrasyon ve güvenlik incelemesidir.

YZ'yi kurum içinde mi geliştirmeliyiz, bir ortakla mı?

İşin ürününüze ve verinize dair derin bilgiye dayandığı yerlerde kurum içinde geliştirin. Entegrasyon, canlı altyapı ve izleme gibi projeden projeye tekrar eden işlerde bir ortakla çalışın. Ortağın teslimatı hızlandırdığı ve sahipliği ekibinize devrettiği hibrit model, iki tarafın güçlü yanlarını birleştirir.

Bir YZ sisteminin tutulmaya değer olup olmadığı nasıl ölçülür?

Pilot başlamadan önce bir iş metriği ve başlangıç değeri üzerinde anlaşın: bir işe harcanan saat, çözüm süresi ya da hata oranı gibi. Sınırlı yaygınlaştırmadan sonra metriği başlangıç değeriyle karşılaştırın. Sistem metriği değiştirmiyorsa, büyütmek bunu düzeltmez.

Pilotunuzu canlı bir sisteme dönüştürmek

Demoda işe yarayan ama günlük operasyonun parçası olamamış bir pilotunuz varsa, bir sonraki adım genelde yeni bir pilot değildir. Elinizdeki modelin etrafındaki veri, entegrasyon ve operasyon katmanları için net bir plandır. 2017'den beri 400+ projede gördüğümüz şey, bir YZ yatırımının karşılığını verip vermeyeceğini tam da bu ara bölümün belirlediğidir.

YZ pilotunuzu canlıya taşımak için ekibimizle görüşün