Finans ekibinin onaylayacağı bir yapay zeka iş gerekçesi nasıl yazılır?

Finans ekibi yapay zeka önerisini üç soruyla geri gönderir. Yalnızca geliştirmesi değil, işletmesi kaça mal olacak? Neyle karşılaştırıldığında? İşe yaramazsa ne olacak?

Tedarikçinin öne çıkardığı bir iddiaya ve token başına fiyata dayanan bir öneri bu soruların hiçbirini yanıtlayamaz. Finansın onaylayacağı bir yapay zeka iş gerekçesi, tüm iş akışını ölçülmüş bir başlangıçla karşılaştırarak fiyatlar, varsayımları kontrol edilebilsin diye yazıya döker ve nerede durulacağını söyler. Tek bir sayfaya sığar.

Finans ekibi ne görmek ister?

• Ölçülmüş bir başlangıç durumu. Birinin hatırladığı haliyle değil, iş bugün nasıl yürüyorsa öyle: hacim, vaka başına süre, hata oranı ve vaka başına maliyet.
• Tüm maliyet. Yalnızca lisanslar ya da token’lar değil; geliştirme, işletme ve inceleme.
• Finansın diliyle faydalar. Hangi bütçe kalemi değişiyor ve hangi faydalar nakit değil, kapasite?
• Kontrol edilebilir varsayımlar. Her sayı bir kaynağa dayanır ya da tahmin olarak işaretlenir.
• Kötü senaryo. İşe yaramadığını anladığınız ana kadar ne harcamış olacağınız ve durma kararını kimin vereceği.

İş gerekçesine hangi maliyetler girer?

Geliştirme maliyeti bir kerelik kısımdır: keşif, pilot, iş akışının dokunduğu sistemlerle entegrasyon, güvenlik ve veri koruma incelemesi, eğitim ve değerlendirme seti. Şirket içi zamanı, özellikle referans yanıtları yazan uzmanların zamanını da sayın; en sık unutulan kalem budur. Geliştirme maliyetini neyin belirlediği ayrı bir konudur.

İşletme maliyeti her ay tekrarlanır: model kullanımı, altyapı, izleme, destek ve promptları güncel tutmak ya da model güncellemelerinden sonra yeniden test etmek gibi bakım işleri. İnsanların her vakayı incelemek için harcadığı dakikalar da buna dahildir ve çoğu zaman en büyük kalem budur.

Değişim maliyeti kolayca unutulur: pilot sırasında eski ve yeni yolu yan yana yürütmek, işe yeni başlayanları eğitmek ve eski yolu kapatmak. Bir kerelik ve tekrarlanan maliyetleri nasıl görmek istediklerini finans ekibine sorun ve onların formatına uyun.

Faydalar, sayı uydurmadan nasıl tahmin edilir?

Mevcut sürecin ölçümlerinden başlayın. Hacim sistemlerinizden gelir. Vaka başına süre kısa bir zaman etüdünden gelir: bir sabah ekiple oturun ve gerçek vakaların süresini tutun. Hata oranları yeniden işleme kayıtlarından, iade faturalarından ve şikayetlerden gelir.

Değişimi bir aralık olarak tahmin edin ve erkenden test edin. Aday bir tasarımı pilottan önce birkaç düzine geçmiş vaka üzerinde çalıştırmak, size bir tedarikçinin ortalaması yerine kendi işinizden gelen bir aralık verir.

Sonra kapasiteyi nakitten ayırın. Serbest kalan saatler ancak fazla mesai, geçici personel ya da artık gerekmeyen bir işe alım gibi bir bütçe kalemi değiştiğinde paraya dönüşür. Aksi halde zamanın ne için kullanılacağını söyleyin ve onu kapasite olarak sayın. Bu ayrımı canlıya geçişten sonra yatırım getirisini ölçme notu ayrıntılı olarak ele alıyor. Kimsenin fiyatlamadığı faydaları, örneğin ekipler arasındaki tutarlılığı, sayılarla değil sözcüklerle listeleyin.

Risk ve hataların maliyeti nasıl gösterilir?

Her hata türünü süreç sahibi ve finans ekibiyle birlikte fiyatlandırın: yeniden işleme, doğrudan kayıp, müşteri etkisi, uyum riski. Kaba aralıklar yeterlidir; hesabın nasıl yapıldığını token maliyetini hata maliyetiyle karşılaştıran not gösteriyor.

Hataların beklenen maliyetini iki tarafta da gösterin, çünkü mevcut süreç de hatasız değildir. Hangi oranda olursa olsun kabul edilemeyecek hataları fiyatlandırmak yerine tek tek adlandırın ve her birini önleyen kontrolü yazın; bu genellikle bir onay noktasıdır. Kötü senaryoyu da açıkça yazın: kriterlerini karşılayamayan bir pilotun sabit maliyeti.

Hiçbir şey yapmama seçeneğini de fiyatlandırın. Büyüyen iş birikimi, her yoğun dönemdeki fazla mesai ve ekibin karşılayamadığı büyüme gerçek maliyetlerdir; bunları dışarıda bırakmak her alternatifi pahalı gösterir.

Durma kriteri olmayan bir iş gerekçesi plan değil, para talebidir.

Hangi varsayımlar yazıya dökülmeli?

En azından şunlar: hacim, bugünkü vaka başına süre, sistemle birlikte inceleme süresi, önceki ve sonraki hata oranları, hata başına maliyet, görev başına işletme maliyeti, vakaların gerçekten sistemden geçecek kısmının oranı, geliştirme maliyeti ve tam verime ulaşma süresi. Her birine bir kaynak (ölçülmüş, tahmini ya da tedarikçinin bildirdiği) ve onu doğrulayacak pilot ölçümünü yazın. Bir satır şöyle olabilir: “Sistemle inceleme süresi: başvuru başına 4 dakika. Kaynak: bir prototipten geçirilen 30 geçmiş başvuru. Doğrulama: pilot sırasında canlı başvuruların süresinin tutulması.”

Ardından varsayımları tek tek değiştirin ve sonucu izleyin. Genellikle biri ağır basar. Pilotun ilk ölçmesi gereken ve durma kriterlerinin etrafına yazıldığı varsayım odur.

Tek sayfalık bir iş gerekçesi neye benzer?

Temsili bir garanti başvuruları masası ele alalım. Sayılar hesabı göstermek için seçilmiş varsayımsal değerlerdir ve birimler temsilidir; fiyat ya da kıyaslama değildir. Personelin bir dakikası 1 birime mal olur; yanlış bir kararı düzeltmek 60 birim tutar.

Ayda 1.000 başvuruda fark 8.200 birimdir; 60.000 birimlik bir geliştirme maliyeti yedi aydan biraz uzun sürede kendini öder. Personel süresi burada yalnızca bir nedenle para sayılıyor: süreç sahibi, serbest kalan zamanı aksi halde geçici personel gerektirecek büyümeyi karşılamaya ayırmayı taahhüt etti.

Şimdi duyarlılığı test edin. İşletme maliyeti iki katına çıkarsa geri ödeme süresi sekiz ayı biraz aşar; hatalar hiç azalmazsa yaklaşık sekiz buçuk aya uzar. İnceleme 4 yerine 9 dakika sürerse neredeyse on dokuz aya çıkar. Finans on iki ay içinde geri ödeme istiyor; bu da ancak inceleme başvuru başına yaklaşık yedi dakikanın altında kaldıkça mümkün. Bu iş gerekçesini inceleme süresi belirliyor.

İş gerekçesi ne zaman yeniden ele alınmalı?

Her karar noktasında: keşiften sonra, tahminler ölçülmüş bir başlangıca dönüştüğünde; pilottan sonra, varsayımlar ölçüme dönüştüğünde; canlı kullanımın ilk çeyreğinden sonra. Hacim, fiyatlar, hata maliyetleri ya da alttaki model gibi bir girdi değiştiğinde de yeniden ele alın.

Devam ve durma kriterleri, pilot başlamadan önce iş gerekçesine yazılır. Başvuru örneğinde şöyle olabilirler:

• Devam edilir: inceleme süresi yedi dakika ya da altındaysa, değerlendirme setinde kabul edilemez bir hata görülmüyorsa ve işletme maliyeti başvuru başına 1,5 birimin altında kalıyorsa.
• Durdurulur: iki tur değişiklikten sonra inceleme süresi dokuz dakikanın üzerinde kalıyorsa.
• Beklemeye alınır: veri erişimi ikinci haftanın sonuna kadar açılmamışsa.

Kendi kriterleriyle durdurulan bir pilot başarısızlık değildir. Sınırı önceden çizilmiş bir öğrenme maliyetidir. İş gerekçesinin onaylanan sürümünü de saklayın: finans ekibi bir sonrakine güvenmeyi, bu sürümü ölçülen sonuçlarla karşılaştırarak öğrenir.

Neden önce başlangıç ölçümü alınmalı?

Önce başlangıç ölçümü satırını doldurun; dolduramıyorsanız ilk işiniz budur. Yaklaşık iki hafta süren bir Keşif Çalışması başlangıç durumunu ölçer; bu sayfanın ihtiyaç duyduğu pilot planını ve kabul kriterlerini yazar. Yönetici Atölyesi’nden pilota kadar ilk adımların kapsamı ve fiyatı sabittir (başlangıç yollarına bakın); böylece öğrenmenin maliyeti, başlamadan önce bellidir.