Danışmanlık projesi bittiğinde kurumun elinde kapsamlı bir sunum bulunabilir. Yine de ekipler pazartesi sabahı ne yapacaklarını bilmiyorsa, eksik kalan şey çoğu zaman bilgi değil, kullanılabilir teslimattır. Bu nedenle “kaç toplantı yapılacak?” sorusunun yanına “hangi kararı hangi belgeyle alabileceğiz?” sorusunu koymak gerekir.
Kısa cevap: Yapay zekâ danışmanlığı teslimatları kapsamla birlikte belirlenmelidir. İhtiyaç belgesi, mevcut durum değerlendirmesi, önceliklendirilmiş kullanım senaryoları, pilot değerlendirme raporu, uygulama planı ve devir dosyası olası çıktılardır. Her çalışmanın hepsini veya çalışan bir yazılımı içermesi gerekmez.
New Academy'nin yapay zekâ danışmanlığı yaklaşımında teslimat, süreci ilerleten bir karar aracıdır. Bu rehberdeki örnekler, ilk görüşmede kapsamı somutlaştırmak için kullanılabilir; her proje için değişmez bir paket listesi değildir.
Teslimatı bir dosya adıyla sınırlamayın
“Yol haritası PDF olarak teslim edilir” biçimi tarif eder, yeterliliği değil. Aynı dosya bir sayfalık hedef listesi de olabilir, bağımlılıkları ve sorumluları gösteren uygulanabilir plan da. Teslimat satırına dört bilgi ekleyin: içeriği, hangi karar için kullanılacağı, inceleyecek kişi ve kabul koşulu.
Örneğin “önceliklendirme tablosu” için yalnızca fikir listesi beklemeyin. Her fikrin iş sahibi, veri ihtiyacı, beklenen katkısı, riski ve sıralama gerekçesi bulunmalı. Henüz ölçülmeyen alanlar tahmin olarak etiketlenmeli. Böylece tablo, yönetimin yatırım sırası hakkında konuşabileceği ortak bir belgeye dönüşür.
1. İhtiyaç ve kapsam belgesi
İlk teslimat, ne yapılacağından çok hangi sorunun çözüleceğini netleştirir. Mevcut iş akışı, etkilenen kullanıcılar, başlangıç durumu, hedeflenen değişim ve kapsam dışındaki işler yazılır. Kullanıcı beklentileriyle yöneticinin beklentisi farklıysa bu fark erkenden görünür hale gelir.
Kabul sorusu: İş birimi ile teknik ekip aynı problemi aynı sınırlar içinde tarif ediyor mu? Örneğin “satış otomasyonu” yerine “onaylı fiyat listesinden teklif taslağı hazırlama” gibi bir sınır koymak, sonraki testleri de mümkün kılar.
2. Mevcut durum ve veri hazırlığı değerlendirmesi
Veriler hangi kaynaklarda? Hangi belgeler güncel? Erişimleri kim yönetiyor? Aynı kavram farklı dosyalarda farklı mı kullanılıyor? Bu sorular cevaplanmadan araç seçmek, çözümün temeline varsayım yerleştirmek olur.
Yapay zekâ olgunluk analizi çıktısı yalnızca bir puan olmamalı. Bulguların dayanağını, eksikleri ve sonraki adımın neye bağlı olduğunu da göstermeli. İncelenmeyen bir departman için sonuç üretilmemeli; örneklem kullanıldıysa sınırı açıkça yazılmalı.
Kabul sorusu: Her önemli bulgunun görüşme, belge incelemesi veya başka bir gözleme dayanan açıklaması var mı? Eksik veri ile zayıf performans birbirinden ayrılıyor mu?
3. Kullanım senaryosu portföyü
Çalıştayda çıkan onlarca fikir, tek başına yatırım planı değildir. Aynı işin farklı ifadelerle tekrarlandığı maddeler birleştirilmeli; fikirler karşılaştırılabilir ayrıntı düzeyine getirilmelidir. Her senaryo için kullanıcı, görev, girdi, çıktı, insan kontrol noktası ve ölçüm yöntemi yazılabilir.
Kullanım senaryosu ve fırsat analizi bu ayrımı yapmaya yardımcı olur. Seçilmeyen fikirlerin gerekçesini de koruyun. Bugün veri erişimi olmadığı için ertelenen bir fikir, veri koşulları değiştiğinde yeniden değerlendirilebilir; tamamen unutulması gerekmez.
Kabul sorusu: Öncelikli senaryonun neden seçildiği, alternatiflerden farkı ve hangi koşulda yeniden değerlendirileceği anlaşılabiliyor mu?
4. Pilot ve değerlendirme raporu
PoC kapsama dahilse rapor yalnızca başarılı ekran görüntülerinden oluşmamalı. Denenen örnekler, değerlendirme yöntemi, başarısızlıklar, kullanıcı düzeltmeleri ve sınırlar bulunmalı. Başlangıçta test ölçütleri yazılmadıysa sonuçları sonradan iyi gösterecek örnekler seçmek kolaylaşır.
Kurgusal bir belge karşılaştırma pilotunda “metni akıcı özetliyor” gözlemi yeterli değildir. Tutarları yanlış birleştiriyor mu, kaynak sayfasını gösterebiliyor mu, eksik bilgi karşısında durabiliyor mu? Bu sorular, çıktının gerçek kullanımda güvenilir olup olmadığını daha iyi anlatır.
Kabul sorusu: Devam, revizyon veya durdurma önerisinin dayanağı rapordan izlenebiliyor mu? Canlıya geçiş için gereken ek işler, pilot başarılarından ayrı mı?
5. Uygulama planı ve sorumluluklar
Takvim üzerinde renkli kutular bulunması planı uygulanabilir yapmaz. Her işin sorumlusu, bağımlılığı ve tamamlanma ölçütü olmalı. Veri hazırlığı bitmeden entegrasyon başlayamıyorsa bu ilişki görünmeli. Kurumun kendi ekibinden beklenen zaman da planın parçasıdır.
NIST AI RMF Playbook, risk yönetimi için yönetişim, bağlamı haritalama, ölçme ve yönetme başlıklarında uyarlanabilir eylemler sunar. Zorunlu bir kontrol listesi değildir. Danışmanlıkta bu tür çerçeveler, görevlerin ve risk kararlarının unutulmamasına yardımcı olacak şekilde kullanılabilir.
Kabul sorusu: Her aksiyonun sahibi belli mi? Bir bağımlılık geciktiğinde hangi kararın etkileneceği görülebiliyor mu? Risk kabulünü kimin yapacağı tanımlı mı?
6. Devir ve sürdürülebilirlik dosyası
Çalışma bittikten sonra kurumun çözümü anlaması, değerlendirmesi ve gerekiyorsa başka bir sağlayıcıya devredebilmesi gerekir. Bunun içeriği projeye göre değişir: karar kayıtları, veri kaynaklarının listesi, yapılandırma açıklamaları, test örnekleri, kullanım sınırları, bakım sorumluları ve varsa kaynak kodu erişimi.
Gizli anahtarları raporlara yazmak devir yöntemi değildir. Erişimlerin kurum tarafından yönetilmesi, hizmet hesaplarının sahipliğinin belirlenmesi ve geçici proje izinlerinin kapatılması ayrıca planlanmalı. Bir yazılım teslimi söz konusu değilse devir dosyası da bunu açıkça söylemeli.
Kabul sorusu: Projeye sonradan katılan yetkili bir çalışan, hangi kararın neden verildiğini ve bir sorun halinde kime başvuracağını anlayabiliyor mu?
Örnek bir kabul notu nasıl yazılır?
Aşağıdaki metin, gerçek bir müşteri sonucunu değil, kurgusal bir kapsam örneğini gösterir:
Teslimat: Satın alma teklif karşılaştırma pilotu değerlendirme raporu. İçerik: Kurumun onayladığı örnek belgelerde tutar, para birimi, teslim koşulu ve kaynak gösteriminin değerlendirilmesi. Kabul sorumluları: Satın alma süreç sahibi ve teknik sorumlu. Karar: Belirlenen hata türleri ve düzeltme yükü incelendikten sonra pilotun revizyonu veya sınırlı kullanıma geçişi.
Sayısal eşikler varsa kurumun risk değerlendirmesi ve başlangıç ölçümüyle belirlenmeli; başka projeden kopyalanmamalı. Canlıya geçiş rehberinde değerlendirme ile işletim hazırlığı arasındaki farkı ayrıntılandırıyoruz.
Toplantı sayısı yerine karar kalitesini satın alın
Toplantılar bilgi toplamak ve ortak karar üretmek için gereklidir. Ancak tamamlanan toplantı sayısı, danışmanlığın değerini tek başına göstermez. Proje sonunda ekipler hangi işi seçtiğini, neden seçtiğini, neyin henüz bilinmediğini ve bir sonraki adımın sorumlusunu söyleyebilmeli.
Teklifinizde bu açıklık yoksa danışmanlık fiyatını tartışmadan önce teslimatları netleştirin. New Academy ile iletişime geçerek, kurumunuz için analiz, pilot veya uygulama planından hangisinin doğru başlangıç olduğunu ve danışmanlık çalışmasının hangi çıktıları kapsayacağını birlikte belirleyebilirsiniz.