SAP Ekibinde AI Pilotu: 30 Günde Neyi Ölçmeli?

SAP ekiplerinde AI denemeleri çoğu zaman aynı yerde tıkanır: birkaç kişiye lisans verilir, "bir bakın bakalım" denir, bir ay sonra kimse ne olduğunu net olarak söyleyemez. Kimi geliştirici çok memnundur, kimi hiç açmamıştır, elde tek bir karara dayanak yoktur. Sorun aracın kendisinde değil, pilotun bir soru etrafında kurulmamış olmasındadır. Bu yazı, bir SAP ekibinde 30 günlük bir AI pilotunu kararla bitecek şekilde nasıl kuracağınızı anlatıyor: kimin katılacağı, hangi işlerin seçileceği, neyin ölçüleceği ve ilk gün halledilmesi gereken güvenlik maddeleri.

1. Pilotu bir araç denemesi değil, bir soru olarak kurun

"AI'ı deneyelim" bir hedef değildir; ölçülebilir bir karşılığı yoktur. Pilotun ilk çıktısı, 30 gün sonunda evet ya da hayır ile yanıtlanabilecek tek bir cümle olmalı. Örneğin: "Rutin Z-rapor ve arayüz geliştirmelerinde ilk taslağı AI üretirse, geliştiricinin bu işlere ayırdığı süre anlamlı ölçüde kısalıyor mu?" ya da "Devraldığımız eski ABAP kodunu anlamak ve ST22 dump'larını çözmek için harcanan süre düşüyor mu?"

Bu cümle ekipteki herkesin bildiği bir sorunu işaret etmeli. Kimsenin şikâyet etmediği bir alanı pilota koyarsanız, sonuç ne çıkarsa çıksın kimseyi ikna etmez. Buna karşılık, ekibin zaten her hafta konuştuğu bir darboğazı seçerseniz — ör. "acil talepler yüzünden planlı geliştirmeler kayıyor" — 30. günde konuşulacak somut bir şey olur.

İkinci kural: pilotun kapsamı yazılı olmalı. Hangi sistemler (geliştirme mi, sadece bir test sistemi mi), hangi paketler, hangi kullanıcı yetkileri, hangi tarihler. Bu tek sayfalık kapsam metni pilotun sonunda tartışmayı "ama biz onu denemedik ki" noktasından kurtarır.

2. Kimler katılmalı: dar bir çekirdek ekip

Pilotu tüm ekibe açmak sezgisel olarak doğru görünür ama pratikte sonucu bulanıklaştırır: 15 kişiye lisans verirsiniz, 4 kişi düzenli kullanır, kalanın kullanmama nedenini kimse sormaz. Üç ila beş kişilik dar bir çekirdek daha iyi çalışır; herkesin kullandığını ve neden kullanmadığını bilirsiniz.

Çekirdekte üç profil bulunsun:

• Kıdemli bir ABAP geliştiricisi: üretilen kodun gerçekten kabul edilebilir olup olmadığına karar verebilecek kişi. Pilotun teknik hakemi odur; onun "bu kodu ben de böyle yazardım" ya da "bunu review'dan geçirmem" demesi, herhangi bir metrikten daha ağır basar.
• Orta seviye bir geliştirici: asıl fayda genelde burada görünür — standart işleri hızlandırmak ve bilmediği alanlarda (CDS View, yeni ABAP söz dizimi, ATC bulguları) yol almak.
• Bir fonksiyonel danışman veya veri tarafından biri: doğal dilde veri sorgulama tarafını değerlendirecek kişi. Bu profil çoğu pilotta unutulur, oysa "her küçük sorgu için geliştiriciye gitmek" birçok ekipte kod yazmaktan daha büyük bir yüktür.

Bir de pilot sahibi gerekir: sonucu toplayacak, haftalık 30 dakikalık kısa bir toplantıyı yürütecek kişi. Bu genellikle takım liderinin kendisidir ve rolü aracı savunmak değil, gözlemi kayıt altına almaktır.

3. Hangi işler pilota girmeli, hangileri girmemeli

Pilotun en sık yapılan hatası, aracı ekibin en zor işiyle sınamaktır. On yıllık, kimsenin tam anlamadığı bir fiyatlandırma modülünü AI'a vermek etkileyici bir test gibi görünür; gerçekte hem AI hem geliştirici için en kötü başlangıç noktasıdır ve sonuç "işe yaramıyor" olarak kaydedilir.

Pilota uygun işler genelde şunlardır:

• Yeni ve orta ölçekli geliştirmeler: bir ALV raporu, bir veri aktarım programı, bir yardımcı sınıf. Sıfırdan başlayan iş, AI'ın en güçlü olduğu yerdir.
• Sözlük nesnesi ve iskelet üretimi: tablo, yapı, data elementi, domain gibi nesnelerin bağımlılık sırasıyla kurulması. Tek tek yapılınca zaman alan, hata payı yüksek ama zihinsel olarak zorlamayan iş.
• Kod anlama ve inceleme: devralınan bir programın ne yaptığını çıkarmak; güvenlik, performans ve standart ihlallerini taramak.
• Dump ve hata analizi: ST22 kayıtlarında kök nedene giden yolu kısaltmak — çıktının doğruluğu hızlıca test edilebildiği için ölçmesi kolay bir alan.
• Ad hoc veri soruları: "şu koşuldaki kaç sipariş var" tipi, normalde geliştirici kuyruğunda bekleyen sorgular.

Pilot dışında bırakılması gereken iki alan var: canlı sisteme doğrudan müdahale gerektiren acil düzeltmeler ve ekibin en karmaşık, en riskli çekirdek modülü. İkisi de pilotun sonucunu ölçmeyi değil, tartışmayı zorlaştırır. Bunlar için doğru zaman, araç ekibin günlük akışına yerleştikten sonrasıdır.

4. 30 günde ölçülecek beş şey

Ölçüm karmaşık olmak zorunda değil; bir tablo ve haftada beş dakikalık bir kayıt disiplini yeterli. Önemli olan, ölçütlerin pilottan önce belirlenmiş olması — sonrasında seçilen ölçüt her zaman çıkan sonucu haklı çıkarır.

• Görev başına süre: pilota giren her iş için "AI olmasaydı tahminen ne kadar sürerdi" ve "gerçekte ne kadar sürdü". Tahmin kaba olacaktır, sorun değil; on iş biriktiğinde eğilim görünür hale gelir.
• Kabul oranı: AI'ın ürettiği taslakların ne kadarı büyük değişiklik olmadan kabul edildi, ne kadarı baştan yazıldı? Bu, "hızlandırdı mı" sorusunun en dürüst göstergesidir.
• Düzeltme turu sayısı: istenen sonuca kaç turda ulaşıldı? Tek turda çıkan bir rapor ile beş turda düzelen bir rapor arasındaki fark, süre kaydından daha çok şey anlatır.
• Fiilî kullanım: kimler, hangi modülleri, ne sıklıkta kullandı? Yönetilen kurulumda model ve kullanım tarafı uygulama içinden görülebilir; görülemiyorsa haftalık toplantıda sormak yeterlidir. Düşen kullanım bir başarısızlık işareti değil, bir soru işaretidir: "neden bıraktın?" yanıtı genelde pilotun en değerli çıktısıdır.
• Kalite sinyalleri: pilotta üretilen kodun ATC bulguları, syntax hataları ve inceleme notları. AI'ın hızlandırdığı ama kalitesi düşen bir akış, uzun vadede kazanç değildir.

Bu beş ölçüt bilinçli olarak sadedir. "Yüzde kaç verimlilik artışı" gibi tek bir rakama indirgemek cazip gelir ama 30 günlük, beş kişilik bir pilotta böyle bir rakam istatistiksel olarak anlamlı olmaz; kararınızı eğilimlere ve çekirdek ekibin gerekçeli görüşüne dayandırmak daha sağlıklıdır.

5. İlk gün halledilecek dört güvenlik maddesi

Pilotların ikinci klasik tıkanma noktası, üçüncü haftada güvenlik ekibinin devreye girip her şeyi durdurmasıdır. Bunu baştan halletmek birkaç saatlik iştir:

• Hangi sistem: pilot geliştirme sisteminde koşar. Canlı sistem bağlantısı gerekiyorsa salt okunur bir kullanıcıyla sınırlanmalı; yazma yetkisi olmayan bir bağlantı, yanlışlıkla değişiklik ihtimalini yapısal olarak ortadan kaldırır.
• Veri ve anahtar akışı: AI trafiği nereden çıkıyor? mdp/aigui'de AI çağrıları doğrudan kullanıcının cihazından sağlayıcıya gider; SAP bağlantı bilgileri ve API anahtarları yalnızca cihazda şifreli saklanır. Trafiğin şirket ağından çıkmaması gereken senaryolarda kurumsal seçenekler (yönetilen erişim, Azure AI Foundry ile VNet yönlendirmesi) değerlendirilir.
• Yazma onayı: SAP'a hiçbir şey kullanıcı onayı olmadan yazılmaz; kod satır bazlı diff ile onaylanır, veri tarafında her sorgu çalışmadan önce onaya sunulur. Bunu pilotun ilk gününde ekibe göstermek, güvenlik toplantısındaki sorulardan çoğunu peşinen yanıtlar.
• Transport disiplini: pilotta üretilen her nesne normal CTS akışına girer. AI'ın ürettiği kod için ayrı bir istisna yolu açmayın — pilotun amacı zaten aracın mevcut süreçle uyumlu çalışıp çalışmadığını görmek.

Bu dört maddeyi kapsam metnine yazın; güvenlik ekibini pilotun sonunda değil başında masaya davet edin. Ayrıntılı bir soru listesine ihtiyacınız varsa SAP'ta AI kullanmadan önce sorulacak 7 güvenlik sorusu yazımız bu maddeleri daha geniş ele alıyor.

6. 30. günde nasıl karar verilir

Pilotun son toplantısı yeni bir değerlendirme değil, baştaki sorunun yanıtlanmasıdır. Elinizde beş ölçütün kaydı, çekirdek ekibin gözlemleri ve kıdemli geliştiricinin kod kalitesine dair yargısı olur. Üç olası sonuç vardır ve üçü de meşrudur: yaygınlaştır, kapsamı değiştirip bir tur daha dene, ya da bırak.

"Bir tur daha" sonucu genelde en gerçekçi olanıdır ve başarısızlık sayılmamalı. Çoğu pilot ilk turda aracı değil, kendi kapsamını test eder: yanlış işleri seçmiş, ölçütleri geç belirlemiş ya da çekirdek ekibi fazla geniş tutmuş olursunuz. İkinci tur, birincinin gözlemleriyle çok daha nettir.

Yaygınlaştırma kararı çıkarsa, geçişi tek seferde yapmayın: çekirdek ekip artık iç eğitmen konumundadır ve yeni katılan her geliştirici için ilk hafta rehberliği en hızlı benimseme yoludur. Bu aşamada merkezi yapılandırma da anlam kazanır — yönetilen AI erişimiyle kullanıcıların kendi anahtarlarını hiç girmeden, şirketin belirlediği bütçe ve politikalar içinde çalışması, hem yönetim hem denetim tarafını basitleştirir.

Sonuç

Bir AI aracının SAP ekibinizde işe yarayıp yaramadığı, aracın tanıtım listesinden değil sizin ekibinizin bir aylık kaydından anlaşılır. Dar bir çekirdek, doğru seçilmiş işler, önceden belirlenmiş beş ölçüt ve ilk gün halledilmiş güvenlik maddeleri — bir pilotu "herkes bir baksın" denemesinden ayıran şey bu dört unsurdur.

30 gün, alışkanlıkların oturması için kısa ama bir eğilimin görünmesi için yeterli bir süredir. Sonunda ne karar verirseniz verin, elinizde gerekçeli bir yanıt olur — ve bu, çoğu ekibin AI konusunda bugün sahip olmadığı şeydir.