Yapay Zekâ Dönüşümü, İşi Yeniden Tasarlamakla Başlar

Bir müşteri destek ekibinin yapay zekâyla yanıt hazırlamaya başladığını düşünelim. İlk yanıt süresi kısalıyor. Yönetim, aynı sayıda talebi daha küçük bir ekibin karşılayabileceğini hesaplıyor. Fakat müşterilerin sorunları gerçekten daha hızlı çözülüyor mu? Yoksa hızlı gönderilen yanıtların ardından yeni mesajlar, tekrar açılan kayıtlar ve başka ekiplere aktarılan işler mi geliyor?

Bu örnekte yapay zekâ bir görevi hızlandırmış olabilir. İşin bütünü için henüz aynı şeyi söyleyemeyiz. Dönüşüm iddiasını değerlendirmek için yanıtın hazırlanmasından müşterinin sorununun çözülmesine kadar uzanan sürece bakmak gerekir.

Kadro kararı, işin tasarımını açıklamaz

Bir şirketin yapay zekâ kullanırken çalışan sayısını azaltması, işini yeniden tasarladığını tek başına göstermez. Daha az kişiyle aynı süreci yürütmeye çalışıyor da olabilir. Aradaki fark; hangi görevlerin değiştiğinde, hangi adımların ortadan kalktığında ve sorumluluğun nasıl dağıtıldığında ortaya çıkar.

Elbette yapay zekâ bazı görevlere duyulan ihtiyacı azaltabilir. İş hacmi, maliyet yapısı ve kadro ihtiyacı bunun sonucunda değişebilir. Ancak önce kadro hedefi koyup ardından kalan işi teknolojiyle karşılamaya çalışmak, henüz sınanmamış bir varsayımı işletme planına dönüştürür.

Bu varsayım bazen tutabilir. Bazen de kontrol, istisna yönetimi ve düzeltme yükü kalan çalışanlara dağılır. Organizasyon şeması küçülürken işin gerektirdiği emek aynı ölçüde azalmamış olabilir.

Bu nedenle başlangıç sorusu, kaç kişinin azaltılabileceğinden önce hangi işin neden yapıldığı ve nasıl daha iyi sonuç verebileceği olmalı.

“Yapay zekâ sayesinde” açıklamasının kanıtı gerekir

Faisal Hoque, Tom Davenport ve Paul Scade, HBR’de yayımlanan “AI Transformation Requires Redesigning Work, Not Cutting Roles” başlıklı yazılarında, yapay zekâyla ilişkilendirilen erken işten çıkarmaların beklenen getiriyi sağlamayabileceğini tartışıyor. Bazı açıklamaların, başka nedenlerle alınmış kararları yapay zekâ anlatısıyla sunan bir “AI-washing” biçimi olabileceğine de dikkat çekiyorlar.

Bu, her kadro azaltımının yanlış olduğu veya her şirketin gerekçesini gizlediği anlamına gelmez. Bir duyuru, kendi başına neden-sonuç ilişkisi kurmaya yetmez. Talep daralması, önceki dönemde fazla işe alım veya genel maliyet baskısı da kararda etkili olabilir.

Yazıdan çıkardığım işletme açısından önemli soru şu: Yapay zekânın katkısını gösterecek operasyonel değişim nerede?

Hangi iş adımının değiştiği, değişiklikten önce ne kadar kaynak tükettiği ve sonrasında ne olduğu açıklanamıyorsa, elimizde dönüşümün sonucundan çok yönetimin beklentisi vardır. Beklenti yatırım kararı için kullanılabilir; gerçekleşmiş kazanım gibi değerlendirilmemelidir.

Meta örneği: Ekipleri küçültmek işi yeniden tasarlamak değil

Pragmatic Engineer’ın aktardığı Reuters haberine göre Meta’nın Project OT çalışmasında bazı ekiplerin yüzde 60’a kadar küçültülmesi senaryoları ele alındı; Meta da bunların bazı ekipler için planlama senaryoları olduğunu doğruladı. Bu, şirket genelinde yüzde 60’lık bir iş gücü azaltımı değildi. İlk Mayıs dalgası gerçekleşti, planlanan ikinci dalga ise iptal edildi.

On–yirmi kişilik bir ekibi üç–beş kişi ve yapay zekâyla bırakmak, tek başına işi yeniden tasarlamaz. Alan bilgisi, yedeklilik, nöbet kapasitesi, muhakeme ile müdahale ve hesap verebilirlik düzeninin de yeniden kurulması gerekir. Dönüşümü çalışan sayısıyla değil; değişen görevler, korunan kontroller ve müşteri ya da ürün için ölçülen sonuçlarla değerlendirmek gerekir.

Kalan ekibin aynı talebi sürdürülebilir biçimde karşılayıp karşılayamayacağı ve hangi kararların insanlarda kalacağı da ayrıca tasarlanmalıdır.

Bu soru ancak gerçek operasyon verisiyle yanıtlanabilir.

İş unvanından görevlere inmek

İşi yeniden tasarlamak için bir pozisyonun içinde gerçekte neler yapıldığına bakmak gerekir. “Satış operasyonu” veya “müşteri desteği” gibi unvanlar, otomasyon kararı vermek için fazla geniştir. Aynı rol; bilgi toplamayı, metin hazırlamayı, doğrulamayı, karar vermeyi ve başka insanlarla uzlaşmayı içerebilir.

Örneğin bir teklif hazırlama sürecini ele alalım. Müşteri ihtiyacını anlamak, geçmiş sözleşmeleri incelemek, taslak hazırlamak, fiyatı onaylamak ve teslimat taahhüdü vermek birbirinden farklı işlerdir. Taslak üretiminin hızlanması, fiyatlama yetkisinin veya teslimat sorumluluğunun da aynı sisteme aktarılabileceğini göstermez.

Görev düzeyinde inceleme başka bir imkân da sunar: Bazı adımlar otomatikleştirilmek yerine tamamen kaldırılabilir. Kullanılmayan bir raporu daha hızlı hazırlamanın işletmeye katkısı sınırlıdır.

Burada amaç ayrıntılı bir görev envanteri üretip bırakmak değildir. Her adımın hangi sonuca hizmet ettiğini görmek ve teknolojinin bu sonuca nerede katkı sağlayabileceğine karar vermektir.

Bu görev değişiminin çalışanlardan beklenen becerileri ve rol tasarımını nasıl etkilediğini Yapay Zekâ İşleri Değiştirirken Çalışanları Eğitmek Yetmez yazısında ayrıca ele almıştım.

Karar yetkisi ve sorumluluk açık kalmalı

Bir sistem öneri hazırladığında, öneriyi kimin onayladığı önemlidir. Sistem doğrudan işlem yaptığında ise sınırların daha açık olması gerekir.

Varsayımsal bir iade sürecinde yapay zekâ başvuruyu sınıflandırabilir, eksik bilgiyi isteyebilir ve uygun işlemi önerebilir. Fakat müşteriye hangi koşullarda para iadesi yapılacağı, hangi istisnaların ayrıca değerlendirileceği ve hatalı işlemden kimin sorumlu olduğu ayrıca belirlenmelidir.

“Son kararı insan verir” cümlesi tek başına yeterli bir tasarım değildir. O kişinin kararı incelemek için zamanı, gerekli bilgisi ve işlemi durdurma yetkisi var mı? Onaylanan işlem sayısı arttığında kontrol hâlâ anlamlı biçimde yapılabiliyor mu?

Çalışanın yalnızca sistem çıktısını onayladığı bir düzen, kâğıt üzerinde insan denetimi içerebilir. Gerçek hesap verebilirlik için sorumluluk verilen kişinin sürece müdahale edebilmesi gerekir. Bu da görev tanımı kadar kapasite ve yetki meselesidir.

Hızın yanına kaliteyi ve yeniden yapılan işi koymak

İlk çıktının daha hızlı üretilmesi, toplam işin azaldığı anlamına gelmez. Taslağın kontrolü, yanlış bilginin düzeltilmesi veya müşteriye yapılan açıklamanın tekrarlanması da aynı işin maliyetidir.

Açılıştaki destek örneğine dönelim. İlk yanıt süresi düşerken tekrar açılan kayıtların oranı yükseliyorsa, hız kazanımının bir bölümü sonraki aşamalarda kayboluyor olabilir. Bu durumda yalnızca gönderilen yanıt sayısına bakmak yanlış bir başarı resmi çizer.

Kaliteyi değerlendirirken bütün hataları da aynı saymamak gerekir. Küçük bir ifade düzeltmesiyle müşteriye yanlış taahhütte bulunmanın sonucu farklıdır. Kontroller, hatanın görülme ihtimali kadar etkisine göre de tasarlanmalıdır.

Müşteri açısından değer, şirketin daha çok çıktı üretmesi değildir. Sorunun doğru çözülmesi, verilen sözün tutulması veya hizmete daha kolay erişilmesidir. İçerideki verimlilik ölçüsü bu sonuçlarla bağ kuramadığında, süreç kendi performansını iyileştirirken müşterinin deneyimini kötüleştirebilir.

Dönüşüm nasıl ölçülür?

Ölçüm, değişiklikten önceki durumu görünür kılmakla başlar. İşin uçtan uca süresi, toplam emek ihtiyacı, düzeltme yükü ve müşteriye yansıyan sonuç bilinmeden kazanımı güvenilir biçimde değerlendirmek zorlaşır.

Yeni düzende yalnızca modelin veya yazılımın maliyeti hesaba katılmaz. Entegrasyon, kontrol, bakım ve istisnaları ele almak için gereken emek de maliyetin parçasıdır. Kazanılan zamanın başka bir işe aktarılıp aktarılmadığı da ayrıca izlenmelidir. Boşalan kapasite değerlidir; bunun doğrudan nakit tasarrufuna dönüştüğünü varsaymak ise ayrı bir iddiadır.

Değişiklik mümkün olduğunda sınırlı bir kapsamda denenebilir. Karşılaştırma yapılırken talep hacmi, işin zorluğu ve dönemsel etkiler dikkate alınmalıdır. Basit taleplerde alınan sonuç, bütün operasyonun aynı biçimde çalışacağını göstermeyebilir.

İyi bir değerlendirme birkaç ölçüyü birlikte okur: İş daha hızlı tamamlanıyor mu, toplam maliyet nasıl değişiyor, hata ve düzeltme yükü ne oluyor, müşteri hangi farkı görüyor? Bu soruların yanıtları birbiriyle çeliştiğinde, çelişkiyi saklamak yerine tasarımı yeniden ele almak gerekir.

Model çıktısı, tamamlanan iş ve işletme etkisini birbirine karıştırmamak için Yapay Zekâ Sisteminiz Gerçekten Sonuç Üretiyor mu? yazısındaki dört katmanlı ölçüm ayrımına da bakılabilir.

Başlangıç için daha yararlı bir soru

İşin yeniden tasarlanması her zaman daha küçük bir ekip sonucunu doğurmaz. Aynı ekibin biriken talepleri karşılamasını, hizmet kapsamını genişletmesini veya daha fazla dikkat gerektiren işlere zaman ayırmasını sağlayabilir. Hangi sonucun değerli olduğu, işletmenin gerçek ihtiyacına bağlıdır.

Bu yüzden ilk adım olarak somut bir iş seçmek ve onu baştan sona incelemek anlamlıdır. Nerede bekliyor, nerede hata üretiyor, hangi kararlar belirsiz kalıyor? Yapay zekâ bu sorunlardan hangisini çözebilir ve çözümün işe yaradığını nasıl anlayacağız?

Yönetim toplantısına taşınabilecek soru da buradan çıkar: Bu işi yeniden tasarladığımızda, müşteriye sunulan sonuç nasıl iyileşecek ve bunu hangi kanıtla göstereceğiz?

Kadro kararı bu değerlendirmeden sonra daha sağlam bir zeminde alınabilir. Yapay zekâ dönüşümünün değeri de kullanılan aracın isminden veya küçülen organizasyon şemasından önce, işin verdiği sonuçta görünür.

Kanıt sınırı: HBR yazısı bu tartışmanın çıkış kaynağıdır; burada anılan görüşleri her şirket için geçerli nedensel kanıt olarak ele alınmamıştır. Destek, teklif ve iade örnekleri varsayımsaldır; gerçek müşteri deneyimi veya ölçülmüş sonuç aktarmaz.