Yapay Zekâ İçin İş Akışı Nasıl Yeniden Tasarlanır?

Bir satış ekibinin teklif hazırlamak için yapay zekâ kullanmaya başladığını düşünelim. Müşterinin e-postası sisteme veriliyor, birkaç saniye içinde düzgün bir teklif taslağı çıkıyor. Fakat satış temsilcisi teslim tarihini operasyon ekibine soruyor. Operasyon, talepte ürün çeşidinin belirtilmediğini fark ediyor. Müşteriye dönülüyor. Yanıt geldiğinde fiyatın da yeniden hesaplanması gerekiyor.

Metin hazır. Teklif hâlâ hazır değil.

Bu varsayımsal örnekte gecikmenin ne kadarı yazı yazmaktan, ne kadarı eksik bilgiden veya karar beklemekten geliyor bilmiyoruz. Teklif metnini hızlandırmak yararlı olabilir. Ancak önce müşterinin talebinden kullanılabilir bir teklife kadar uzanan işin nasıl ilerlediğini görmemiz gerekiyor.

İşi yeniden tasarlamanın neden yapay zekâ dönüşümünün merkezinde olması gerektiğini önceki yazıda ele aldım. Burada o düşünceyi çalışma masasına taşıyalım: Hangi adımlar var, kim yapıyor, nerede karar veriliyor ve ilk olarak neyi değiştirmeye değer?

Haritanın başlangıcını ve bitişini müşteri belirlesin

“Teklif hazırlama” bir iş adı. Tek başına sürecin sınırını tarif etmiyor. Başlangıç müşterinin ilk mesajı mı, bütün bilgilerin tamamlanması mı? Bitiş dosyanın üretilmesi mi, onaylanması mı, müşteriye ulaşması mı?

Ölçümü yalnızca eksiksiz bilgiyle başlatırsanız bilgi toplarken geçen zamanı dışarıda bırakırsınız. Dosya oluştuğunda bitirirseniz fiyat onayında bekleyen işi göremezsiniz. Haritayı kolay ölçülen bölüme göre çizmek, çözmeye çalıştığınız sorunu baştan küçültebilir.

Örneğimizde başlangıç ilk teklif talebinin gelişi olsun. Akış, kapsamı, fiyatı ve teslim koşulları doğrulanmış teklif müşteriye ulaştığında tamamlansın. Müşterinin eksik veya yanlış bilgi nedeniyle düzeltme istemesini de bu işe geri bağlayalım. Satışa dönüşüm daha sonra izlenebilir. O sonucu teklif hazırlayan sistemin tek başına yarattığını varsayamayız.

İlk çalışma toplantısında süreci yöneten kişiyle birlikte işi yapanları ve çıktıyı kullananları buluşturun. Yakın zamanda tamamlanan sıradan bir talebi, gecikmiş bir talebi ve istisna içeren bir talebi açın. Bunlar bütün operasyonu temsil eden bir örneklem sayılmaz. Haritanın şirketin ideal süreç tarifinden kopup gerçek işe yaklaşmasını sağlar.

E-postada sorulan soruyu, başka bir tabloda tekrar girilen bilgiyi ve bir çalışanın telefonla çözdüğü belirsizliği de görünür kılın. İş, prosedürde yazmayan yerlerde de ilerliyor olabilir. Haritadaki bir adım tartışmalıysa tahminle tamamlamak yerine “doğrulanacak” diye işaretleyin.

Rolleri yan yana koyunca devirler görünür olur

CXL’in iş akışı haritalama yazısı, adımları rol bazlı şeritlerde göstermeyi ve ilk değişikliği açıkça tanımlanmış bir adımda denemeyi öneriyor. Yazı, CXL’in kendi eğitim programındaki atölyeden hareket ediyor ve o programı tanıtıyor. Bu nedenle onu uygulanabilir bir yöntem önerisi olarak kullanıyorum. Haritalamanın yatırım getirisi yarattığını gösteren bağımsız bir araştırma olarak değil.

Bu çizim biçimine swimlane deniyor. Her yatay şeritte bir rol bulunuyor. Adımları soldan sağa yerleştirince işin kimden kime geçtiği görülüyor. Araçları ilgili adımın yanına yazabilirsiniz. Otomatik çalışan bir sistem için ayrı şerit açsanız da işletmedeki sorumlusu ayrıca belli olmalı.

Teklif örneğinde satış temsilcisi, satış operasyonu, operasyon planlama ve satış yöneticisi ayrı şeritlerde yer alabilir. Aynı kişi küçük bir şirkette birkaç rolü üstlenebilir. Buna rağmen rollerin ayrılması yararlıdır: Müşterinin ihtiyacını yorumlamakla teslimat kapasitesini doğrulamak farklı sorumluluklardır.

Bir kutuya “talebi incele, fiyatla ve müşteriye gönder” yazarsanız otomasyon için hâlâ fazla büyük bir iş tarif etmiş olursunuz. İnceleme, fiyat kararı ve gönderme ayrı kutulara ayrıldığında her biri için farklı bir müdahale seçilebilir.

Çizimin ayrıntısını bu karara göre ayarlayın. Her fare tıklamasını belgelemek gerekmez. Girdi, çıktı, sorumlu, karar yetkisi veya hata halinde izlenecek yol değişiyorsa ayrı bir adım açmak anlamlıdır.

Her adımın altına şu bilgileri ekleyin:

• Hangi bilgi veya olayla başlıyor, hangi çıktı kabul edildiğinde bitiyor?
• Kim yapıyor, sonraki kişi neyi teslim alıyor?
• Ne kadar çalışma süresi, ne kadar bekleme var? Bu bilgi kayıt mı, tahmin mi?
• Hangi bilgi eksik gelebiliyor, hangi hata işi geriye döndürüyor?
• Bir karar gerekiyorsa yetki kimde ve hangi koşullarda kullanılabiliyor?

Bu notlar, aynı kutunun içinde farklı sorunlar saklanmasını önler. “Operasyon kontrolü uzun sürüyor” gözlemi, örneğin, kontrolün çok emek istediğini düşündürebilir. Kayıtlara bakınca işin çoğunlukla eksik bilgiyle geldiği veya uygun kişinin kuyruğunda beklediği anlaşılabilir. Bu iki durumda yapılacak değişiklik aynı olmaz.

Şeritli harita her süreç için zorunlu değildir. Tek kişinin yürüttüğü, dallanmayan kısa bir işte bir tablo yeterli olabilir. İş birkaç rol arasında dolaşıyor ve koşullara göre yön değiştiriyorsa şeritler okumayı kolaylaştırır. Haritanın değeri, ekipteki insanların aynı işi aynı biçimde açıklayabilmesinde.

Karar kutusuna soruyu, dönüş okuna nedeni yazın

Teklif talebinde teslim tarihi belirtilmemişse sistem nasıl davranacak? Geçmiş bir siparişten tarih mi çıkaracak, müşteriye mi soracak, satış temsilcisinin incelemesini mi bekleyecek?

Haritada “bilgiyi tamamla” yazmak bu seçimi çözmez. “Müşterinin istediği tarih belirtilmiş mi?” ayrı bir kontrol, “bu tarihi karşılayabilir miyiz?” ayrı bir iş kararıdır. Birincisi için kaynak mesajda bilgi ararsınız. İkincisi için kapasite, mevcut taahhütler ve öncelikler gerekir.

Karar kutusuna soruyu yazın. Çıkışları “evet”, “hayır” ve gerekiyorsa “bilinmiyor” olarak adlandırın. Bilinmeyeni olumlu kabul eden bir akış, eksik bilgiyi doğrulanmış bilgiye dönüştürür.

Normal yolun yanına sık görülen istisnaları ekleyin. Talep birbiriyle çelişen iki miktar içeriyorsa, standart ürünün dışında bir özellik isteniyorsa veya müşteri sonradan kapsamı değiştiriyorsa işin nereye döneceği belli olsun. Dönüş oku yalnızca “hata” demesin. “Miktar çelişkisi: satış temsilcisi müşteriden doğrulama ister” gibi bir neden ve sorumlu taşısın.

İnsan kontrolünü de aynı açıklıkla tarif edin. Kişinin yalnızca onay düğmesine basması yeterli olmaz. Orijinal talebi, sistemin çıkardığı bilgileri ve belirsizlikleri birlikte görebilmesi gerekir. Yanlış çıktıyı reddedebilmeli, işi durdurabilmeli ve gerektiğinde başka bir yetkiliye aktarabilmelidir. Bu inceleme için ayırdığı süre haritaya ve pilot hesabına girmeli.

Öte yandan her istisna sistem arızası değildir. Şirketin daha önce karar vermediği bir duruma rastlamış olabilirsiniz. Böyle bir durumda doğru adım, eksik iş kuralını ilgili kişiye karara bağlatmaktır. Modeli daha kararlı cevap vermeye zorlamak belirsizliği çözmez.

Her adıma dört seçenekle bakın

Mevcut akış görünür olduğunda her kutunun neden var olduğunu yeniden değerlendirebilirsiniz. Bunun için dört çalışma etiketi yeterli: kaldır, otomatikleştir, destekle ve koru. Bunlar değişmez kategoriler değil, o adım için verdiğiniz kararlardır.

Kaldır: Çıktısını kimse kullanmayan veya başka bir adımı gereksiz yere tekrar eden işi bırakın. Ancak görünürde tekrarlanan bir kontrolün farklı bir sorumluluğu olabilir. Kaldırma kararı, çıktıyı kullanan kişiyle doğrulanmalı.

Otomatikleştir: Girdisi, kuralı ve kabul edilebilir çıktısı açık işi sisteme bırakın. Bu seçenek yapay zekâ gerektirmeyebilir. Standart alanların iki sistem arasında aktarılması için mevcut bir entegrasyon yeterli olabilir. Kayıt eşleşmesi belirsizse otomatik yol durmalı.

Destekle: Sistem bilgiyi düzenlesin, seçenek veya taslak hazırlasın. İnsan kaynağa bakarak değerlendirsin ve sorumluluğu taşısın. Yardımın değeri, kontrol ve düzeltme emeği hesaba katıldıktan sonra anlaşılır.

Koru: Bağlam, taahhüt veya hata etkisi nedeniyle insanın yürütmesi gereken işi açıkça insanda tutun. Bu, mevcut işleyişe dokunulmayacağı anlamına gelmez. Yetkiyi sadeleştirmek, gerekli bilgiyi aynı yerde toplamak veya bir yedek sorumlu belirlemek yine işi iyileştirebilir.

Varsayımsal teklif akışımızda ilk değerlendirme şöyle görünebilir:

Bu tablo bir uygulama talimatı değil, araştırılacak değişikliklerin listesi. Gerçek bir işletmede her satırın gerekçesi mevcut kayıtlarla sınanmalı. Aynı anda bütün adayları uygulamak, hangisinin neyi değiştirdiğini anlamayı zorlaştırır.

İlk pilotun sınırı bir cümleye sığmalı

İlk deneme için hem işletme açısından anlamı olan hem de sonucunu inceleyebileceğiniz bir adım seçin. Tekrarlanması, kabul ölçütünün açıklığı, veriye uygun erişim ve hata halinde eski yönteme dönebilmek seçimde işe yarar. En kolay görünen kutunun toplam akışa katkısı yoksa pilot için iyi bir aday olmayabilir.

Örneğimizde sınanacak öneri şu olsun: Yapay zekâ, standart ürünlerle ilgili teklif talebinden ihtiyaç alanlarını çıkaracak; satış operasyonu bunları kaynak mesajla karşılaştırıp kabul edecek veya düzeltecek.

Pilot fiyat vermeyecek, teslimat sözü üretmeyecek ve müşteriye mesaj göndermeyecek. Talep metninden ürün, miktar, istenen tarih ve açık sorular çıkaracak. Her alanın yanında dayandığı kaynak bölümü görünecek. Kaynakta bulunmayan bilgi “belirtilmemiş” olarak kalacak. Çelişkili bilgi insan incelemesine gidecek.

Bu seçimin gerekçesi, eksik veya yanlış aktarılan ihtiyacın sonraki teklif adımlarını etkilemesi. Yine de ilk haritalama bu işin çok az zaman aldığını ve neredeyse hiç hata üretmediğini gösterirse pilotu seçmemek gerekir. Bekleme esas olarak teslimat kararındaysa operasyon planlamanın bilgiye erişimini veya karar düzenini değiştirmek daha yararlı olabilir.

Pilotun hazırlığında normal taleplerin yanında eksik, çelişkili ve kapsam dışı örnekler de kullanın. İlk denemeyi gerçek işlemi etkilemeyen kopyalar üzerinde yapın. Şirketin kullanımına izin verdiği veri ve ortamla çalışın. Gerekli olmayan müşteri bilgilerini bu adıma taşımayın. Kabul edilen kapsamın dışındaki talepler mevcut insan yolundan ilerlesin ve sayıları kayıtta kalsın.

Canlıdaki sınırlı denemeden önce sorumluyu, inceleme kapasitesini ve durdurma koşullarını yazın. Kaynaksız bir bilginin doğrulanmış gibi sonraki adıma geçmesi veya müşteri kayıtlarının karışması bu örnekte durdurma nedeni olur. Hata araştırılırken ekip eski yöntemle çalışabilmeli. Pilot sahibi, sistemin hangi taleplerde kullanıldığını ve kimlerin çıktıyı inceleyeceğini bilmeli.

Bu aşamada diğer aday değişiklikleri uygulamayın. İkinci formu kaldırmak veya belge aktarımını otomatikleştirmek ayrı kararlar olarak beklesin. Sonraki pilotta bunlardan biri daha değerli çıkabilir.

Ölçüm, iş yeniden açıldığında da devam etmeli

Pilotun başarı tanımını sistemi kurmadan önce yazın. İlk taslağın kaç saniyede çıktığını ölçmek kolay. Fakat satış operasyonu alanları yeniden okumak ve düzeltmek için daha fazla zaman harcıyorsa o rakam eksik bir resim verir.

Başlangıç düzeyini aynı tanımlarla kaydedin. Pilot ile mevcut yöntemi karşılaştırırken iş türünü, zorluğunu, hacmini ve takip süresini benzer tutmaya çalışın. Uygunsa benzer talepleri iki yönteme tarafsız biçimde dağıtın. Yalnızca önce-sonra karşılaştırması yapabiliyorsanız o sırada değişen ekip, talep yapısı veya başka süreçleri de kayda alın. Bulguyu buna göre sınırlayın.

Teklif örneğinde beş ölçüm alanı birlikte okunabilir:

Ortalamaya bakıp uzun bekleyen işleri kaybetmeyin. Tipik tamamlanma süresinin yanında en fazla bekleyen grubu da inceleyin. Kontrolü tamamlanmamış talepleri başarılı saymayın. Pilotun dışına çıkan işleri de toplamdan sessizce düşürmeyin. Aksi halde sistem zor talepleri insana bıraktıkça kendi başarı oranı yükselir.

Küçük bir ifade düzeltmesiyle yanlış ürün miktarı aynı hata değildir. Hataları etkilerine göre ayırın. Tek bir ciddi hata, çok sayıda doğru alanın içinde görünmez olmamalı. Az sayıda ve hatasız tamamlanan bir deneme de nadir hataların çözüldüğünü kanıtlamaz.

Müşterinin yanıt vermemesi teklifin sorunsuz olduğu anlamına gelmez. Takip süresi dolmayan veya sonucu bilinmeyen işleri ayrı gösterin. Teklifin kabulü ise fiyat, rekabet ve müşteri bütçesinden de etkilenir. Pilot daha fazla satış getirdi demek için alan çıkarma kalitesinden çok daha güçlü bir karşılaştırma gerekir.

Yapay zekâ sistemlerinde çıktı, tamamlanan iş ve işletme etkisini ayıran ölçüm yazısı bu kanıt farkını ayrıntılı ele alıyor. Buradaki uygulaması basit: Haritadaki her kazanım iddiasının yanında hangi kayda bakılacağı belli olsun.

Maliyet hesabında da model kullanımına kontrol, düzeltme, entegrasyon ve bakım emeğini ekleyin. Başlangıç kurulumunu düzenli işletim maliyetinden ayrı tutun. Kazanılan zamanı doğrudan ücretle çarpıp gerçekleşmiş tasarruf yazmayın. O süre birikmiş teklifleri azaltmış, fazla mesaiyi düşürmüş veya daha dikkatli müşteri görüşmelerine ayrılmış olabilir. Hangi karşılığın oluştuğunu ayrıca gösterin.

Öğrenilen şey haritayı değiştirmeli

Pilot sırasında müşterilerin sık sık iki farklı teslim tarihi yazdığını fark ettiğimizi varsayalım. Biri ürünün sevk tarihi, diğeri müşterinin kendi faaliyetine başlama tarihi olsun. Sistem bunları karıştırıyorsa yalnızca çıkarım talimatını değiştirmek yeterli olmayabilir. Talep formunda da tek bir “tarih” alanı bulunuyorsa belirsizlik işin başında üretiliyordur.

Bu bulgu satış temsilcisine ve operasyon planlamaya dönmeli. Hangi tarihin hangi kararda kullanılacağı açıklanmalı, gerekirse form ayrılmalı. Değişiklik daha sonraki benzer taleplerde sınanmalı. Böylece pilot, şirketin eksik bir tanımını düzeltmesine yardım edebilir.

İnsanların yapay zekâ sürecindeki öğrenme rolünü tartıştığım yazıda son kontrolün bu nedenle yeterli olmadığını anlatmıştım. Burada o düşüncenin haritadaki karşılığı, istisnadan iş tanımına dönen bağlantıdır. Çıktıyı düzeltmek bugünkü teklifi kurtarır. Belirsizliğin nedenini düzeltmek sonraki talebin farklı ilerlemesini sağlar.

Bu bağlantının da sahibi olmalı. Satış operasyonu belirsizliği kaydedebilir, ilgili rol kuralı karara bağlayabilir, süreç sahibi haritayı güncelleyebilir. Daha az deneyimli çalışanlar da yalnızca alan düzeltmeye değil, gerekçeyi incelemeye ve sonraki örneği değerlendirmeye katılabilir. Öğrenmeyi kaydedilen not sayısıyla ölçmek yerine kararın bir sonraki işte kullanılıp kullanılmadığına bakın.

Pilotun sonunda devam, değiştir veya durdur kararı verin. Süre kısalırken kontrol yükü veya müşteri düzeltmeleri artıyorsa yaygınlaştırmayı bekletin. Fayda yalnızca dar bir talep türünde görülüyorsa o sınırı koruyun. Katkı görünmüyorsa daha iyi bir model aramadan önce yanlış adımı seçmiş olma ihtimalini değerlendirin.

Bir sonraki çalışma toplantısını sınırları belli bir pilot kararıyla bitirin. Ekip, hangi talebin nereden başlayıp hangi sonuca ulaşacağını, ilk denemede hangi adımın değişeceğini ve hangi bulguda duracağını açıklayabilsin. Bu üç karar verildiğinde satın alınacak ya da geliştirilecek şeyin sınırı da çok daha net olur.