Yapay zekayla yönetim raporları: sayılar sistemlerden, yorum modelden.

Bir operasyon müdürü her pazartesi sabahını haftalık rapora ayırır: rakamları dışa aktarır, şablona yapıştırır ve bir fabrikanın neden planın gerisinde kaldığını anlatan üç paragraf yazar. Rakamlar bir saat sürer. Paragraflar sabahın geri kalanını alır; çünkü nedenler vardiya kayıtlarında, satış notlarında ve başka insanların e-posta kutularında durur.

Yapay zeka o sabahın çoğunu geri kazandırabilir; tek bir koşulla: aritmetiğe asla dokunmamalı. Yönetim raporlamasında yapay zekayı şöyle kullanın: rakamları ERP’de ya da iş zekası (BI) katmanında hesaplayın; model yorum taslağını bu rakamlardan ve insanların zaten yazdığı notlardan hazırlasın; her ifade açıkladığı sayıyı kaynak göstersin. Aşağıdaki adımlar bunun nasıl yapılacağını ve her adımda işin ne zaman bitmiş sayılacağını gösteriyor.

Hesabı neden model yapmamalı?

Bir dil modeli metni hesaplayarak değil, tahmin ederek üretir. Bir sütunu çoğu zaman doğru toplar, arada bir de bir toplamı ya da yüzdeyi yanlış çıkarır; yanlış sayı da doğrusundan hiç farksız görünür. Ayrıca biri söylemedikçe sizin “net satışlar” tanımınızın iadeleri dışarıda bıraktığını ya da zamanında teslimatı nasıl tanımladığınızı bilmez.

Model sayılar hakkında yazar. Sayıların kendisini asla yazmaz.

İş bittiğinde: taslakta girdi tablosunda bulunmayan tek bir rakam bile yoktur. Basit bir otomatik kontrol metindeki her sayıyı tabloyla karşılaştırır ve biri tutmazsa taslağı durdurur. Sık yapılan hata: modelin “yardımcı olmak için” kimsenin vermediği bir toplamı ya da değişimi kendisinin hesaplaması.

Rakamlar nereden gelmeli?

Finansın arkasında durduğu rakamları zaten üreten ERP sorgularından ya da iş zekası katmanından; modelden önce hesaplanmış ve kontrol edilmiş olarak. Toplamlar defterle mutabıktır; önceki döneme ve plana göre farklar da orada hesaplanır.

Model ham veri değil, bir tablo alır. Her satırda metrik, dönem, değer, karşılaştırma rakamları, fark, bir önemlilik işareti ve en önemlisi metriğin tanımı bulunur; böylece yorum doğru kelimeleri kullanır. Yuvarlama ve birimler de modelden önce belirlenir: tablo bir rakamın bin mi milyon mu olduğunu söyler, taslak da onu tam verildiği gibi aktarır. Aynı veri üzerinde anlık sorular sormak başka bir tasarımdır; bunun ne zaman işe yaradığını doğal dilden SQL üretimi notumuz anlatıyor.

İş bittiğinde: rapordaki her rakam, adı belli ve test edilmiş bir sorgudan gelir. Sık yapılan hata: birinin bir dışa aktarımı sohbet penceresine yapıştırıp özet istemesi.

Model neyi katabilir?

Sözcükleri, yapıyı ve “neden” sorusunun kanıtını. Bir sapmanın nedenleri çoğu zaman insanların zaten yazdığı notlarda durur: CRM’deki satış notları, vardiya ve operasyon kayıtları, bakım talepleri, şikayet kayıtları. Model rapor dönemine ait bu notları okur ve her sapmayı onu açıklayan kayıtlara bağlar.

Neyi katmaması gerektiği de aynı ölçüde önemlidir. İşaretlenmiş bir sapmanın kayıtlı bir nedeni yoksa taslak akla yatkın bir neden önermez; “kayıtlı neden yok” yazar ve sahibine sorar. Hangi sapmaların önemli olduğuna da modelden önce karar verilir: bir sapmanın paragraf alıp almayacağını modelin izlenimi değil, tablodaki önemlilik işareti belirler.

Okuyucular nereye bakacaklarını bilsin diye yapıyı sabit tutun: iki satırlık bir özet, ardından önemlilik sırasına göre işaretlenmiş sapmalar (her biri nedeniyle ya da “kayıtlı neden yok” notuyla), en sonda da sahiplerine yöneltilen açık sorular.

Bir cümle bir rakama nasıl bağlanır?

Her rakama ve her nota bir kimlik verin; her cümlenin dayandığı kimlikleri taşımasını şart koşun:

• Bir sayı belirten cümle, o sayıyı içeren tablo satırını kaynak gösterir ve sayıyı tam orada göründüğü gibi yazar.
• Bir neden belirten cümle, geldiği notu kaynak gösterir; notun tarihi rapor dönemi içinde olmalıdır.
• İkisini de taşımayan cümle bir görüştür; ya çıkarılır ya da sahibi için işaretlenir.

İki kontrol de otomatiktir; inceleme ekranı, kaynak gösterilen satırı ya da notu tek tıkla açar. Kaynağa dayanan, kontrol edilebilir taslakların neden daha az hata yaptığını, yapay zekanın neden uydurduğunu anlatan notumuz açıklıyor.

Taslağı gönderilmeden önce kim inceler?

Raporu eskiden kim yazıyorsa o. Bu kişi taslağı rakamların ve kaynakların yanında, işaretli kalemler en üstte olacak şekilde görür; “kayıtlı neden yok” sorularını yanıtlar, hiçbir notta bulunmayan bağlamı ekler ve üslubu düzeltir. Rapor onun adıyla çıkar, çünkü hesabını o verir. Düzeltmeleri de saklamaya değer: sahibi her hafta aynı düzeltmeyi yapıyorsa (tercih ettiği bir terim ya da her seferinde eklediği bir uyarı gibi), bu düzeltmenin yeri bir tur daha düzeltme değil, talimatlar ya da tablodur. İş bittiğinde: işaretli her kalemde sahibinin bir yorumu vardır ya da kalem bilerek açık bırakılmıştır.

Raporun iyileşip iyileşmediği nasıl anlaşılır?

Temsili bir örnek: iki fabrikası olan bir üreticinin haftalık operasyon raporu.

• Önce: “Çeşitli sorunlar nedeniyle üretim düşük kaldı. Teslimatlar çoğunlukla zamanındaydı.”
• Sonra: “B Fabrikası’nın üretimi planın gerisinde kaldı [üretim, B Fabrikası]; vardiya kaydında 3 numaralı hatta bir duruş görünüyor [vardiya kaydı, 3 numaralı hat]. Zamanında teslimat oranı değişmedi [zamanında teslimat, tüm fabrikalar]. A Fabrikası’nda fire arttı, kayıtlı neden yok; sahibinin yorumu bekleniyor [fire, A Fabrikası].”

İkinci metin birkaç satır daha uzun; ama içindeki her ifade kontrol edilebilir ve henüz kimsenin bilmediği şeyi açıkça söylüyor. Değişimi başlangıç ölçümüyle karşılaştırarak değerlendirin: raporu hazırlama süresi, sahibinin yaptığı düzeltmeler, kayıtlı nedeni olan önemli sapmaların oranı, dağıtımdan sonra bulunan sayısal hatalar (hiç olmamalı) ve okuyucuların gönderdiği ek soruların sayısı.

Hangi raporla başlamalı?

Rakamları oturmuş, yorumunu bir sahibinin yazdığı ve düzenli çıkan tek bir raporla başlayın. Haftalık yönetim raporu taslakları, ERP ve kurumsal iş akışları alanında tipik bir kullanım senaryosudur. Altlarındaki test edilmiş sorgular ve tanımlar ise veri ve yapay zeka altyapısı işidir.