SAP AI Pilotundan Canlıya 90 Günlük Plan

Toplantı odasında yapılan yapay zekâ demosu genellikle iyi görünür. Kullanıcı sorusunu yazar, sistem düzgün bir cevap verir, masada birkaç baş memnuniyetle sallanır.

Sonra biri şu soruyu sorar: “Peki bu, gerçek SAP verisiyle ve gerçek kullanıcı yetkileriyle nasıl çalışacak?”

Asıl proje o anda başlar.

Bir SAP AI pilotunun değeri, tek bir etkileyici cevapta değil; günlük işin içinde güvenilir biçimde çalışıp çalışmadığını göstermesindedir. Yanlış veri geldiğinde ne olacak? Kullanıcının görmemesi gereken bir belge sorulursa sistem nasıl davranacak? Cevap üretilemediğinde iş kimin önüne düşecek? Bunlar çözülmeden yapılan şey, pilot değil demodur.

Bu yazıdaki 90 günlük plan bir proje reçetesi değil. Pilot kapsamını küçültmek, riski görünür kılmak ve canlıya geçiş kararını daha sağlam vermek için kullandığımız bir çalışma çerçevesi.

90 gün neyi garanti eder?

Önce sınırı koyalım: 90 gün bir teslim garantisi değildir. SAP sisteminin yapısı, veri erişimi, güvenlik onayları ve seçilen senaryonun karmaşıklığı takvimi doğrudan etkiler.

Bu sürenin sağlayabileceği şey daha değerlidir: Üç ayın sonunda “devam edelim” ya da “burada duralım” derken elinizde yalnızca bir sunum değil, gözlemlenmiş kullanım ve teknik kanıt bulunur.

İyi bir pilot şu dört soruya cevap verir:

Kullanıcının yaşadığı gerçek sorun nedir?
Gerekli veri güvenli ve sürdürülebilir biçimde alınabiliyor mu?
Yapay zekâ çıktısı iş akışında ölçülebilir bir fayda sağlıyor mu?
Çözüm hata verdiğinde operasyon nasıl devam ediyor?

1–15. gün: Modelden önce problemi seçin

“SAP’ye yapay zekâ ekleyelim” proje tanımı değildir. İlk iki haftada teknolojiyi değil, kullanıcının gün içinde tekrar tekrar yaşadığı tek bir sıkıntıyı seçmek gerekir.

Örneğin bir satın alma uzmanı, sipariş öncesinde farklı ekranlardan tedarikçi ve geçmiş işlem bilgisi topluyor olabilir. Bir bakım planlamacısı, uzun bildirim metinleri arasında benzer arızaları arıyor olabilir. Destek ekibi ise aynı SAP sorularını her gün yeniden yanıtlıyor olabilir.

Pilot için en iyi aday genellikle şu üç özelliği taşır:

Sık tekrarlanır.
Sonucu bir insan tarafından kontrol edilebilir.
Başarıyı ölçmek için başlangıç verisi vardır.

Bu aşamada tek cümlelik bir hedef yazın: “Şu roldeki kullanıcı, şu kararı verirken şu işi daha az adımla tamamlayacak.” Cümle uzuyorsa kapsam da muhtemelen büyümüştür.

16–30. gün: Verinin ve yetkinin gerçek yüzüyle tanışın

Yapay zekâ projesinde zamanın önemli bölümü model seçimine değil, verinin nereden geldiğini anlamaya gider. Test ortamındaki temiz örnekler ile canlı SAP verisi aynı davranmaz.

Bu dönemde ekip şu soruların peşine düşer:

Hangi SAP nesneleri ve alanları gerçekten gerekli?
Veri anlık mı alınmalı, yoksa belirli aralıklarla güncellenmesi yeterli mi?
Kullanıcının şirket kodu, satış organizasyonu veya tesis yetkisi sonuca nasıl yansıyacak?
Kişisel ya da ticari açıdan hassas alanlar modele hiç gitmemeli mi?
Eksik, eski veya çelişkili kayıt geldiğinde sistem bunu nasıl anlatacak?

En kolay yol bütün veriyi açmak gibi görünür. Genellikle en pahalı hata da budur. Pilot, mümkün olan en küçük veri kümesi ve en dar yetkiyle başlamalıdır.

Burada SAP BTP danışmanlığı yalnızca servis kurulumu anlamına gelmez. Kimlik, bağlantı, API yönetimi, izleme ve ortam ayrımı da tasarımın parçasıdır. Teknik mimari ile iş kuralı ayrı ayrı ele alınırsa, canlıya geçerken arada boşluk kalır.

31–60. gün: Pilotu gerçek iş akışına sokun

Bir sohbet penceresi açıp birkaç soru sormak kolaydır. Zor olan, doğru cevabı kullanıcının zaten çalıştığı noktaya taşımaktır.

Kullanıcı gününü SAP Fiori üzerinde geçiriyorsa öneri de mümkünse o bağlamda görünmelidir. Bir onay süreci içindeyse çıktı, ilgili belge ve karar adımıyla birlikte sunulmalıdır. Yeni bir ekran açmak kullanıcıya fazladan iş çıkarıyorsa, yapay zekâ teknik olarak çalışsa bile benimsenmeyebilir.

Bu aşamada “iyi cevap veriyor” gibi yoruma açık bir ölçü yetmez. Pilot için küçük ama açık bir kabul seti belirleyin. Örneğin:

Yanıt, dayandığı SAP kaydını veya belgeyi gösteriyor mu?
Yetkisi olmayan kullanıcı, kaynağa ya da türetilmiş bilgiye erişebiliyor mu?
Kullanıcı öneriyi kabul edebiliyor, düzeltebiliyor veya reddedebiliyor mu?
Manuel işleme dönüş yolu tek bir adımda görülebiliyor mu?
Yanıt süresi, işin doğal akışını bozuyor mu?

İnsan onayı gerekiyorsa bunu kusur gibi görmeyin. Yüksek etkili kararlarda insan kontrolü, pilotun güvenlik mekanizmasıdır.

61–75. gün: Başarılı cevabı değil, kötü günü test edin

Pilotun ilk haftalarında herkes doğru örnekleri denemeye yatkındır. Oysa canlı sistemde fark yaratan, çözümün kötü günde nasıl davrandığıdır.

Model emin olmadığı halde kesin konuşuyor mu? Bağlantı kesildiğinde kullanıcı boş ekranda mı kalıyor? Kaynak sistem yavaşladığında istekler birikiyor mu? Bir yetki değişikliği ne kadar sürede devreye giriyor? Hatalı bir yanıtı sonradan incelemek için yeterli kayıt var mı?

Bu test turunda en az şu durumları çalıştırın:

Eksik ve çelişkili veri
Yetkisiz erişim isteği
Konu dışı veya yönlendirici kullanıcı sorusu
SAP bağlantısının yavaşlaması ya da kesilmesi
Model servisinin yanıt vermemesi
Beklenmeyen maliyet veya gecikme artışı

Her hata için iki cevap gerekir: Kullanıcı ne görecek ve teknik ekip ne yapacak? Sadece log üretmek yetmez. Uyarıyı kimin alacağı, hangi durumda özelliğin kapatılacağı ve manuel sürece nasıl dönüleceği önceden belli olmalıdır.

76–90. gün: Canlıya geçiş kararını verin

Son iki hafta yeni özellik ekleme zamanı değildir. Ekip, pilot boyunca toplanan kanıtları önüne koyup karar verir.

Canlıya geçilecekse model veya uygulama kadar işletim planı da hazır olmalıdır: ürün sahibi kim, teknik sorumlu kim, hangi metrikler izlenecek, kullanıcı geri bildirimi nereye düşecek, değişiklikler hangi onayla yayınlanacak?

Burada üç kararın da meşru olduğunu kabul etmek gerekir:

Devam: İş değeri ve teknik güven yeterli; kontrollü bir kullanıcı grubuyla canlıya geçilir.
Yeniden çalış: Sorun doğru, fakat veri veya entegrasyon hazır değil; kapsam daraltılır ve pilot tekrarlanır.
Durdur: Faydası maliyetini ya da riskini karşılamıyor; yatırım büyümeden sonlandırılır.

Bir pilotun durdurulması başarısızlık değildir. Kanıtsız biçimde büyütülen bir projenin aylar sonra durmasından çok daha ucuz bir karardır.

Hangi pilot üretime gitmemeli?

Bazı uyarılar, “biraz daha iyileştiririz” diye geçiştirilmemeli:

Başarı yalnızca seçilmiş birkaç örnekte gösterilebiliyorsa
Çıktının hangi kaynağa dayandığı açıklanamıyorsa
Yetki kontrolü uygulama dışında elle yürütülüyorsa
Yanlış önerinin iş veya uyum riski yüksek, geri alma yolu belirsizse
Pilot sahibi var ama canlı operasyon sahibi yoksa
Kullanıcılar sistemi kullanmak için mevcut iş akışından kopmak zorundaysa
Maliyet, gecikme ve hata oranı izlenemiyorsa

Bu maddelerden biri varsa hemen vazgeçmek şart değil. Fakat canlıya geçmeden önce o risk için somut bir kapanış ölçütü gerekir.

Danışmanlık ekibine sorulacak 8 soru

Bir SAP AI projesine başlamadan önce çözüm ortağınıza şu soruları sorun:

İlk 90 günde hangi tek kullanıcı problemini ele alacağız?
Başarıyı hangi mevcut ölçümle karşılaştıracağız?
Model hangi SAP verisini görecek, hangisini hiç görmeyecek?
SAP yetkileri yapay zekâ çıktısına nasıl uygulanacak?
Üretilen cevabın kaynağı kullanıcıya gösterilebilecek mi?
Yanlış cevap, servis kesintisi ve maliyet artışı nasıl izlenecek?
Canlıya geçişten sonra ürün ve operasyon sorumluluğu kimde olacak?
Pilotun durdurulmasına yol açacak ölçütleri baştan yazabilecek miyiz?

Bu sorulara net yanıt verilemiyorsa, teknoloji seçiminden önce proje tasarımını düzeltmek gerekir.

İlk görüşmede ne konuşuyoruz?

NeKuDos ile ilk görüşmede ürün sunumuyla başlamıyoruz. Önce kullanıcıyı, kararı, veriyi ve mevcut SAP akışını birlikte çıkarıyoruz. Ardından pilot için küçük bir kapsam, ölçülebilir kabul koşulları ve canlıya geçişte cevaplanması gereken riskleri yazıyoruz.

Amacınız bir demo göstermek değil, gerçek sistemde savunulabilir bir karar vermekse SAP yapay zekâ danışmanlığı hizmetimizi inceleyebilirsiniz. NeKu AI ürün yaklaşımını görmek için de SAP için yapay zekâ çözümleri sayfasına bakabilirsiniz.

SAP AI Pilotundan Canlıya: 90 Günlük Yol Haritası