Ekibinizden bir hafta boyunca tekrar eden görevleri not etmesini isteyin. Her görev için harcanan süreyi, kullanılan bilgiyi ve yanlış yapıldığında ortaya çıkacak sonucu değerlendirin. Sık tekrarlanan, çıktısı kolay kontrol edilen ve hatası geri alınabilen bir görev iyi bir başlangıç adayı olabilir.
Örneğin müşteri destek mesajlarından cevap taslağı çıkarmak düşünülebilir. İlk aşamada mesaj müşteriye otomatik gönderilmez; çalışan taslağı kontrol eder. Böylece işletme, cevap hazırlama süresini ölçerken hatalı bilginin doğrudan müşteriye ulaşmasını önleyebilir.
Yapay zekâya hangi bilgilerin verileceğini belirleyin. Güncelliğini kaybetmiş fiyat listeleri veya birbiriyle çelişen prosedürler, doğru yanıt üretmeyi zorlaştırır. Önce kullanılacak belgeleri gözden geçirin ve her birine bir içerik sorumlusu atayın.
Müşteri bilgilerini, çalışan kayıtlarını veya ticari sırları bir araca aktarmadan önce erişim, saklama ve kullanım koşullarını inceleyin. Başlangıç denemesini mümkünse kişisel veri içermeyen örneklerle yürütün. “Bu sistem hangi bilgiyi kullanabilir, hangi işlemi yapamaz?” sorusunun cevabı yazılı olsun.
NIST’in AI Risk Management Framework yaklaşımı, yapay zekâ sistemlerini kullanım bağlamı ve riskleriyle birlikte değerlendirmek için gönüllü bir çerçeve sunar. KOBİ ölçeğinde bunun pratik karşılığı; sorumlu kişiyi, kontrol yöntemini ve durdurma koşulunu baştan belirlemektir. NIST yapay zekâ risk yönetimi çerçevesi
Pilot başlamadan önce mevcut durumu ölçün. Örneğin öneri olarak şu tabloyu kullanabilirsiniz:
| Ölçüm | Sorulacak soru |
|---|---|
| Hazırlık süresi | Bir taslağı oluşturmak ne kadar sürüyor? |
| Kontrol süresi | Çalışan çıktıyı düzeltmek için ne kadar zaman harcıyor? |
| Doğruluk | Kontrol edilen örneklerin kaçında önemli hata var? |
| Toplam maliyet | Araç, kurulum ve insan kontrolü birlikte neye mal oluyor? |
Yalnızca ilk taslağın hızlı üretilmesine bakmayın. On dakikada yazılan bir metin, yapay zekâyla iki dakikada hazırlanıp on beş dakikada düzeltiliyorsa süreç kazandırmıyor olabilir.
Önerilen bir pilot planında önce örnekleri hazırlayabilir, ardından sınırlı bir ekip ve belirli bir görevle deneme yapabilirsiniz. Süreç boyunca kabul edilen ve reddedilen çıktıları kaydedin. Beklenmeyen bir durum oluştuğunda işi çalışana devretmenin yolu açık olsun.
Pilot sonunda üç karardan birini verin: kapsamı artırmak, yaklaşımı değiştirmek veya uygulamayı durdurmak. Başarısız bir denemeyi erken sonlandırmak da değerli bir sonuçtur; daha büyük bir yatırımın yanlış varsayımla yapılmasını engeller.
İşleri seçerken yalnızca tekrar sıklığına bakmak yanıltıcı olabilir. Günde birçok kez yapılan bir işlem, yüksek hata maliyeti nedeniyle ilk denemeye uygun olmayabilir. Örneğin ödeme onayı vermekle ürün açıklaması taslağı hazırlamak aynı kontrol düzeyini gerektirmez. İlk projede, yanlış çıktının kolayca fark edildiği ve uygulamaya geçmeden düzeltilebildiği bir görev seçmek değerlendirmeyi kolaylaştırır.
Bir toptancı işletmeyi düşünelim. Satış ekibi her gün ürün ölçüleri, paket içeriği ve teslimat seçenekleri hakkında benzer sorular alıyor olsun. İlk deneme, güncel katalogdan cevap taslağı hazırlayan bir yardımcı olabilir. Yardımcı fiyat değiştirmez, müşteriye süre taahhüt etmez ve sipariş oluşturmaz. Yalnızca onaylı belgede bulunan bilgiyi önerir; çalışan da yanıtı göndermeden önce kontrol eder.
Bu örnekte iş tanımı dar tutulduğu için sonuç daha kolay incelenir. Taslağın doğru ürüne ait olması, belgede olmayan bilgi eklememesi ve cevap bulunamadığında bunu belirtmesi beklenir. Proje başarıyla ilerlerse yeni ürün grupları eklenebilir. Böylece kapsam, ilk günden bütün müşteri hizmetlerini devralacak bir sistem kurmaya çalışmadan büyütülür.
Yalnızca kolay örneklerden oluşan bir test, yanıltıcı bir başarı izlenimi verebilir. Destek mesajlarını sınıflandıracak bir sistem için açık soruların yanında eksik, uzun, birden fazla konu içeren ve yazım hatalı örnekler de seçin. Aynı sorunun farklı biçimlerde sorulmasını deneyin. İşte sık karşılaşılan durumlar değerlendirme grubunda temsil edilmelidir.
Örnekleri hazırlayan kişi, kabul edilebilir cevabın hangi bilgileri içermesi gerektiğini de yazmalıdır. Her zaman tek bir doğru cümle aranmaz; belirli bilgilerin doğru verilmesi ve yasaklanan davranışlardan kaçınılması beklenebilir. Örneğin bir teslimat sorusunda depodan doğrulanmamış bir gün söylemek hata, müşteriden sipariş numarası istemek ise uygun bir sonraki adım olabilir.
Deneme sırasında yeni bir sorun fark ettiğinizde bunu test listenize ekleyin. Böylece iyileştirmenin yalnızca o örneği düzelttiğini değil, önceki örnekleri de bozmadığını inceleyebilirsiniz. Küçük bir işletmede başlangıç için sade bir değerlendirme tablosu yeterli olabilir; önemli olan aynı ölçütlerin tutarlı uygulanmasıdır.
Çalışanlar sistemin nerede kullanılacağını bilmiyorsa aynı araç birbirinden çok farklı amaçlarla denenebilir. Bir kişi e-posta taslağı hazırlarken diğeri müşteriye fiyat sözü verebilir. Pilotun amacını, izin verilen verileri ve insan kontrolü gereken noktaları kısa bir kullanım notunda birleştirin. Aracı kullanacak kişilerin bu notu birlikte değerlendirmesini sağlayın.
Bir süreç sahibi ve bir teknik sorumlu belirlemek de yararlıdır. Süreç sahibi işin doğru tamamlanıp tamamlanmadığını, teknik sorumlu ise erişim ve bağlantı sorunlarını takip eder. Küçük işletmelerde aynı kişi birden fazla rol üstlenebilir; ancak görevlerin belirsiz kalmaması gerekir. Yanlış cevap bildirildiğinde kimin inceleme yapacağı önceden bilinmelidir.
Çalışanlardan yalnızca “beğendiniz mi?” geri bildirimi istemeyin. Hangi durumda taslağı tamamen yeniden yazdıklarını, hangi bilgiyi başka yerden doğruladıklarını ve hangi adımın zaman kazandırdığını sorun. Günlük işin ayrıntıları, aracın kısa bir sunumda görünmeyen sınırlarını ortaya çıkarır.
Varsayımsal bir hesap yapalım: Ekibiniz ayda 200 yanıt hazırlıyor ve her yanıt ortalama 10 dakika sürüyor olsun. Yapay zekâ taslağıyla hazırlık ve kontrol toplamı 6 dakikaya düşerse örnek hesapta 800 dakika fark oluşur. Bu rakam bir ürün vaadi değildir; kendi ölçümlerinizi nasıl değerlendirebileceğinizi gösterir.
Bu süreden belge güncelleme, hatalı örnekleri inceleme ve sistem yönetimi için ayrılan zamanı çıkarın. Abonelik, entegrasyon ve eğitim bedellerini de ayrıca yazın. Kazanılan zamanın işletmede neye ayrılacağını belirleyin: Daha fazla müşteri talebini yanıtlamak mı, teklifleri daha hızlı hazırlamak mı, yoksa yoğun dönem yükünü hafifletmek mi?
Her kazanım doğrudan çalışan maliyetinde düşüş olarak görülmeyebilir. Daha tutarlı cevap hazırlamak veya yeni çalışanın bilgiye erişimini kolaylaştırmak da değerli olabilir. Ancak bunları baştan tanımlayın ve gözlenebilir işaretlerle takip edin. Belirsiz bir “verimlilik arttı” değerlendirmesi, sonraki yatırım kararını taşımaya yetmez.
Öneri olarak kapsamı büyütmeden önce farklı kullanıcıların benzer sonuç alıp almadığını, içerik güncellendiğinde sistemin nasıl davrandığını ve hataların yönetilebilir olup olmadığını inceleyin. Başlangıçtaki bir başarılı gösterim, günlük kullanım için yeterli kanıt değildir. Sonuçlar değişkense önce sorunun kaynağını anlamaya çalışın.
Hatalar önemli iş kararlarını etkiliyor, kontrol süresi kazancı ortadan kaldırıyor veya gerekli belgeler düzenli tutulamıyorsa kapsamı küçültmek daha uygun olabilir. Bazen doğru sonraki adım daha gelişmiş model seçmek değil, ürün bilgisini düzenlemek veya iş akışını sadeleştirmektir. Başlangıç projesi, işletmenin hazırlık eksiklerini de görünür kılabilir.
Hangi görevin destekleneceğini, kimlerin kullanacağını, hangi verilerin gerekli olduğunu ve sonucun nasıl ölçüleceğini yazın. Bu sayfa, sağlayıcılarla görüşürken de size yol gösterir. Yapay zekâ yatırımı, işinize somut katkı sağladığı ve ekip tarafından yönetilebildiği ölçüde anlam kazanır.