Bir işletmede aynı bilginin üç farklı tabloya yazılması, tekliflerin kişisel mesajlarda kaybolması veya siparişlerin telefonla takip edilmesi, teknoloji yatırımı için işaretlerdir. Fakat yeni bir yazılım satın almak bu sorunların nedenini ortadan kaldırmaz. Önce işin nasıl yürüdüğü, hangi aşamada beklediği ve kimin sorumluluğunda olduğu anlaşılmalıdır. Doğru teknoloji kararı, günlük işin incelenmesiyle başlar.
Başlangıç için bir haftalık iş günlüğü tutulabilir. Ekip üyeleri tekrar ettikleri işleri, bekledikleri bilgileri ve geri dönen hataları kaydeder. “Sipariş takibi çok zaman alıyor” gibi bir ifadeyi ayrıştırmak gerekir. Zamanın çoğu siparişi bulmaya mı, müşteriyi aramaya mı, kargo bilgisini aktarmaya mı gidiyor? Bu ayrım, çözümün yeni ekran, sistemler arasında bağlantı veya görev dağılımındaki değişiklik olup olmayacağını belirler.
Sonraki adım, seçilen süreci tarif etmektir. Bir müşteri talebi nereden gelir, kim inceler, hangi bilgi eksik olabilir, ne zaman teklif hazırlanır ve iş nasıl kapanır? Adımların girdisi, çıktısı ve sorumlusu yazılmalıdır. İstisnalar da eklenmelidir: müşteri yanıt vermezse, ürün bulunamazsa veya fiyat onayı gecikirse ne olur? Günlük işin zorluğu çoğu zaman bu istisnalarda ortaya çıkar.
Süreç netleştiğinde çözüm seçenekleri karşılaştırılabilir. Mevcut yazılımın kullanılmayan bir özelliği ihtiyacı karşılıyor olabilir. Bazen iki araç arasında veri aktarımı kurmak yeterlidir. Özel yazılım ise işletmeye özgü bir çalışma biçimi, verimlilik ihtiyacı veya mevcut araçların karşılayamadığı bir gereksinim olduğunda değerlendirilebilir. Karar yalnızca geliştirme bedeline göre verilmemelidir; bakım, eğitim, veri taşıma ve ileride değişiklik yapabilme maliyeti de hesaba katılmalıdır.
Yapay zekanın rolü ayrıca belirlenmelidir. Belirli koşullarda aynı sonucu üretmesi gereken işlemlerde açık kurallar daha uygun olabilir. Stok sıfır olduğunda ürünü satışa kapatmak buna örnektir. Serbest yazılmış müşteri mesajlarını sınıflandırmak, uzun bir görüşmeyi özetlemek veya yanıt taslağı hazırlamak ise yapay zekanın denenebileceği işlerdir. İki yaklaşım birlikte kullanılabilir; modelin önerisi, tanımlı kurallar ve yetkiler üzerinden işleme dönüştürülebilir.
Örneğin bir müşteri destek sürecinde yapay zeka mesajın konusunu belirleyip uygun ekibe yönlendirme önerebilir. Sipariş durumunu yanıtlamak içinse güncel sipariş kaydına erişim gerekir. Modelin akıcı bir cümle kurması, verdiği teslimat bilgisinin doğru olduğunu göstermez. Bu nedenle yanıtın hangi veriye dayandığı açık olmalıdır. Kayıt bulunamadığında sistem tahmin üretmek yerine eksik bilgiyi istemeli veya talebi görevli kişiye aktarmalıdır.
Bilgi düzeni burada belirleyicidir. Farklı klasörlerde birbirinden farklı fiyat listeleri bulunuyorsa, yapay zekaya daha çok belge vermek tutarsızlığı büyütebilir. Kullanılacak kaynakların sahibi, güncellik tarihi ve geçerlilik kapsamı belirlenmelidir. Eski dokümanların nasıl kaldırılacağı da tanımlanmalıdır. Küçük ama bakımı yapılan bir bilgi alanı, doğruluğu belirsiz büyük bir arşivden daha yönetilebilirdir. Yanlış bilgi tespit edildiğinde hangi kaydın düzeltileceği bilinmelidir.
Birden fazla firma yöneten ekiplerde veri sınırları önemlidir. Aynı çalışan birkaç firmayla çalışsa bile her kullanıcı kayıtları görmemelidir. Yetki, kişinin görevine ve ilgili firmaya göre tanımlanmalıdır. Bu sınır yalnızca ekrandaki menülerde uygulanmamalı, veriyi sunan tarafta da denetlenmelidir. Yapay zekanın kullanabildiği kayıtlar da aynı yetkilere bağlı olmalıdır. Bir firmanın müşteri bilgisinin başka firmanın yanıtında görünmesi kabul edilebilir değildir.
Sistemden beklenen eylemler de riskine göre ayrılmalıdır. Bir görüşme özeti hazırlamakla müşteriye fiyat taahhüdü göndermek aynı etkiye sahip değildir. Başlangıçta özetler ve yanıt taslakları çalışan kontrolüne sunulabilir. Para iadesi, fiyat değişikliği veya dışarıya mesaj gönderme gibi işlemler için açık onay adımları kurulabilir. NIST'in yapay zeka risk çerçevesi de insan gözetimiyle ilgili rollerin ve sorumlulukların tanımlanmasını vurgular.[1]
Pilot çalışmanın kapsamı dar tutulmalıdır. Bütün işletmeyi kapsayan bir asistan yerine, ekibin tekrarladığı bir iş seçilebilir. Örneğin gelen taleplerin sınıflandırılması veya toplantı notlarından görev taslağı çıkarılmasıyla başlanabilir. Pilotun süresi, kullanıcıları ve başarı ölçüsü baştan belirlenmelidir. Böylece ekip yeni aracın yardımcı olup olmadığını, iş düzenini değiştirmeden gözlemleyebilir.
Ölçümde yalnızca hız kullanılmamalıdır. Bir yanıtın hazırlanma süresi azalırken kontrol ve düzeltme süresi artıyorsa beklenen kazanç oluşmayabilir. Tamamlanan iş başına toplam süre, yanlış yönlendirme sayısı, kullanıcı düzeltmeleri ve işin yeniden açılma oranı birlikte izlenebilir. Çalışanların aracı neden kullanmadığı da kaydedilmelidir. Kullanılmayan bir özellik, teknik olarak çalışsa bile işletmeye beklenen faydayı sağlamaz.
Basit bir kapasite hesabı bu değerlendirmeyi somutlaştırır. Varsayımsal olarak bir ekip günde yüz talep işliyor ve otomasyon her talepte iki dakika kazandırıyorsa, günlük brüt kazanç iki yüz dakikadır. Ancak istisnaları düzeltmek ve sonuçları kontrol etmek için seksen dakika gerekiyorsa kullanılabilir kazanç yüz yirmi dakikaya iner. Bu süre otomatik olarak nakit tasarrufu sayılmaz; ekibin boşalan kapasiteyi nasıl değerlendirdiği görülmelidir.
Maliyet hesabında geliştirme ücretinin yanında düzenli giderler bulunmalıdır. Sunucu, model kullanımı, izleme, bakım ve destek maliyetleri kullanım arttıkça değişebilir. Bu nedenle normal gün, yoğun gün ve beklenmedik kullanım için ayrı senaryolar hazırlanabilir. Harcama sınırları ve bildirimler kurulmalıdır. Ucuz görünen bir pilotun çok sayıda kullanıcıyla aynı ekonomik sonucu vereceği varsayılmamalıdır. İşlem başına maliyet ve sağlanan katkı birlikte değerlendirilmelidir.
Test verileri yalnızca kolay örneklerden oluşmamalıdır. Eksik sipariş numarası, çelişkili bilgi, yanlış yazılmış ürün adı ve bir mesajdaki birden fazla talep gibi durumlar denenmelidir. Kullanıcının farklı dillerde yazması da kapsam içindeyse değerlendirmeye eklenmelidir. Başarısız örnekler kaydedilip yeniden test edilmelidir. Böylece geliştirme ekibi, yalnızca gösterimde iyi çalışan bir sistem yerine işin koşullarında davranışı bilinen bir araç üzerinde çalışır.
Sistemin durduğu an için de bir plan gerekir. Dış servis yanıt vermediğinde talep kaybolmamalı; bekleyen işler görülebilmeli ve gerektiğinde elle tamamlanabilmelidir. Aynı işlemin tekrar denenmesi iki sipariş, iki görev veya iki ödeme oluşturmamalıdır. Yedeklerin varlığı kadar geri yüklenebilir olması da kontrol edilmelidir. Bu hazırlıklar, otomasyonun işler yolunda giderken sağladığı hızın, bir kesinti sırasında büyük bir iş yüküne dönüşmesini önler.
Verinin taşınabilirliği satın alma kararının parçası olmalıdır. İşletme kayıtlarını anlaşılır bir biçimde dışarı alabilmeli, gerekli belgeleri saklayabilmeli ve hizmet değiştiğinde geçmişine erişebilmelidir. Kullanılan modelin veya yazılım sağlayıcısının değişmesi ihtimali de düşünülmelidir. Bütün iş bilgisini yalnızca tek kişinin bildiği bir yapıya bırakmak sürdürülebilir değildir. Erişimler, bağlantılar, görevler ve bakım sorumlulukları işletmenin ulaşabileceği şekilde belgelenmelidir.
Uygulamaya geçişte çalışanların katılımı belirleyicidir. Süreci her gün yürüten kişiler, dışarıdan görünmeyen istisnaları bilir. İlk denemeler onların işleri üzerinden yapılmalı ve geri bildirim için düzenli zaman ayrılmalıdır. Kısa kullanım anlatımları, örnek görevler ve belirli bir destek sorumlusu geçişi kolaylaştırabilir. Yeni sistemin eski işle birlikte ne kadar süre kullanılacağı da açık olmalıdır; belirsiz bir geçiş dönemi çift iş yaratır.
R2 IDEA'nın teknoloji yaklaşımı, işletmenin sektörel bilgisiyle tasarım ve yazılım deneyimini aynı çalışma içinde buluşturmaya dayanır. Faydalı bir çözüm için işin sahibi süreci anlatmalı, teknoloji ekibi bunu ölçülebilen ve yönetilebilen bir yapıya dönüştürmelidir. İlk yatırımın değeri, eklenen özellik sayısıyla sınırlı değildir. Günlük işte hangi beklemeyi kaldırdığı, hangi hatayı önlediği ve ekibin hangi kararını kolaylaştırdığı açıkça gösterilebildiğinde sonraki adım daha güvenli planlanabilir.