SAP BTP ile Akıllı Süreç Otomasyonu: RPA ve AI Entegrasyonunda Mimari Kararlar

Üretim hattında bir anomali tespit edildiğinde, bunu ilk fark eden bir çalışan değil, gerçek zamanlı çalışan bir AI modeli oluyor. Model hemen SAP PP modülüne sinyal gönderiyor, ilgili iş emri otomatik olarak revize ediliyor ve kalite ekibine Slack üzerinden bildirim ulaşıyor—tüm bunlar siz kahvenizi yudumlayan o birkaç saniyede gerçekleşiyor. Bu artık hayal değil; SAP Business Technology Platform (BTP) ve akıllı otomasyon araçlarının doğru mimariye kavuşturulduğu gerçek prodüksiyon senaryoları.

Bu makalede, SAP BTP ekosisteminde RPA (Robotic Process Automation) ve yapay zeka bileşenlerini bir arada kullanan entegrasyon mimarilerini ele alacağız. Sadece teoriden bahsetmeyeceğiz—hangi mimari kararların neden verildiğini, hangi trade-off’ların kabul edildiğini ve gerçek projelerden edindiğim dersleri paylaşacağım.

Not: Bu makale, SAP entegrasyon ekosistemini genel hatlarıyla tanıdığınızı varsayar. IDoc’tan REST/OData servislerine geçiş konusunda bilgi almak isteyenler için SAP’de IDoc’tan REST/JSON/OData Servislerine Geçiş Rehberi makalemizi okumanızı öneririm.

İnsansız Süreçler Neden Artık Zorunlu Hale Geldi?

McKinsey’nin 2023 araştırmasına göre, finans ve tedarik zinciri fonksiyonlarındaki tekrar eden görevlerin %60 ila %70’i tam otomasyon kapsamına giriyor. SAP kullanan kurumlar bu potansiyelin büyük bölümünü hâlâ manuel süreçlerle yönetiyor.

Peki neden? Çünkü SAP’yi “otomatikleştirmek” kolay değil. Sistem çok katmanlı, veri modeli karmaşık, iş kuralları şirket içinde binlerce özelleştirmeyle büyümüş durumda. Geleneksel RPA araçları (UiPath, Blue Prism, Automation Anywhere) bu karmaşıklıkla başa çıkmaya çalışırken kırılgan otomasyon senaryoları üretiyor—SAP arayüzü değişti mi, bot çöküyor.

İşte burada SAP BTP devreye giriyor: SAP’nin kendi ekosisteminden gelen, API-first, event-driven ve AI-ready bir platform. Ancak BTP’yi doğru kullanmak için mimari kararları net vermek gerekiyor.

SAP BTP Akıllı Otomasyon Ekosistemi: Bileşenleri Anlayalım

BTP üzerinde akıllı süreç otomasyonu inşa ederken kullandığımız temel bileşenler şunlar:

1. SAP Build Process Automation (eski adıyla SAP Intelligent RPA)

SAP’nin kendi RPA motorudur. UiPath gibi harici araçlara kıyasla en önemli avantajı: SAP GUI ve Fiori arayüzlerini native entegrasyonla kontrol edebilmesi. Ekran scraping’e gerek yok, BAPI/RFC çağrıları doğrudan botlar tarafından yapılabiliyor.

Kullanım alanları:

• Fatura doğrulama ve GR/IR eşleştirme süreçleri
• Satın alma siparişi onay döngüleri
• Müşteri master data temizleme ve standardizasyonu
• Periyodik rapor üretimi ve e-posta ile dağıtımı

2. SAP Integration Suite (Cloud Integration + API Management)

Kurumsal entegrasyon katmanıdır. SAP sistemleri arasında ve SAP ile üçüncü taraf sistemler arasındaki mesaj akışını yönetir. Event-driven senaryolarda SAP Event Mesh ile birlikte kullanılır.

3. SAP AI Core & AI Launchpad

Makine öğrenmesi modellerini SAP ekosisteminde deploy etmek ve yönetmek için kullanılır. Kendi modellerinizi (örneğin anomali tespiti için eğitilmiş bir scikit-learn modeli) burada production’a alabilirsiniz.

4. SAP HANA Cloud (Vector Engine dahil)

2024’ten itibaren HANA Cloud, vector store desteğiyle geldi. Bu, SAP verisi üzerinde RAG (Retrieval-Augmented Generation) senaryolarını doğrudan HANA katmanında çalıştırma imkânı sağlıyor. Yani harici bir vector DB’ye gerek kalmıyor.

5. SAP Joule (GenAI Asistan)

SAP’nin yerleşik generative AI asistanı. S/4HANA, SuccessFactors ve Ariba ile entegre çalışıyor. Kullanıcıların doğal dil komutlarıyla SAP işlemleri başlatmasını sağlıyor.

Referans Mimari: Event-Driven Akıllı Otomasyon

Birlikte çalıştığım bir üretim firmasından anonimleştirilmiş bir senaryo üzerinden gidelim. Sorun şuydu: Üretim siparişleri tamamlandığında, kalite kontrol belgelerinin manuel olarak SAP QM modülüne girilmesi 2-3 saatlik gecikmelere neden oluyordu. Bu gecikme, bir sonraki üretim adımını ve sevkiyat planlamasını doğrudan etkiliyor.

Tasarladığımız mimari şöyle çalışıyor:

[MES Sistemi] 
    │ HTTP POST (kalite verisi)
    ▼
[SAP Integration Suite - Cloud Integration]
    │ Veri dönüşümü + doğrulama
    ▼
[SAP Event Mesh] ← Event yayınlanır: "QualityDataReceived"
    │
    ├──▶ [AI Core - Anomali Tespit Modeli]
    │         │ Anomali varsa → Alert Event
    │         │ Anomali yoksa → Onay sinyali
    │
    └──▶ [SAP Build Process Automation - Bot]
              │ BAPI_INSPOPER_RECORDRESULTS çağrısı
              ▼
          [SAP QM Modülü - Otomatik Kayıt]

Bu mimariyle gecikme 2-3 saatten ortalama 4 dakikaya indi. Ve kritik nokta şu: Anomali tespit modeli devrede olmaya başladığında, kalite ekibi zamanının %80’ini artık gerçekten sorunlu partilere odaklayabilir hale geldi.

Mimari Karar Noktaları ve Trade-off Analizi

Her projeyi zorlaştıran şey teknik bilgi eksikliği değil, doğru trade-off’ları görebilmek. İşte bu tür projelerde en sık karşılaştığım karar noktaları:

Karar 1: SAP Native RPA mı, Harici RPA mı?

Öneri: Süreç ağırlıklı olarak SAP içindeyse SAP Build Process Automation’u tercih edin. Karma bir ekosistem varsa (SAP + legacy ERP + Excel + e-posta) hibrit yaklaşım düşünün: BTP üzerinden event’ler tetiklensin, harici RPA aracı uç noktaları çalıştırsın.

Karar 2: Senkron mu, Asenkron mu?

RPA botları varsayılan olarak senkron çalışır: görevi al, işle, bitir. Ancak SAP gibi yoğun işlem yapan sistemlerde bu yaklaşım bottleneck yaratır.

Asenkron event-driven mimariyle (SAP Event Mesh aracılığıyla) şunları elde edersiniz:

• Dayanıklılık: Bot çökerse event kaybolmaz, kuyrukta bekler
• Ölçeklenebilirlik: Yüksek yük dönemlerinde bot sayısını dinamik artırabilirsiniz
• Gözlemlenebilirlik: Event akışını izlemek, senkron çağrı loglarından çok daha kolay

Senkron yaklaşımı yalnızca gerçek zamanlı onay beklenen (kullanıcı bir işlem başlatıp sonucu bekliyor) senaryolarda kullanın.

Karar 3: AI Modeli Nerede Çalışmalı?

Üç seçenek var ve her birinin farklı trade-off’ları mevcut:

• SAP AI Core üzerinde: SAP ekosistemiyle entegre, HANA veriye yakın, ancak model yönetimi SAP lifecycle’ına bağlı
• Harici cloud (Azure ML, AWS SageMaker): Daha olgun MLOps araçları, daha geniş framework desteği, ancak SAP verisiyle senkronizasyon ek efor gerektiriyor
• Edge/On-premise: Veri gizliliği gerektiren senaryolarda (savunma, sağlık), latency kritikse üretim hattında

Çoğu kurumsal senaryoda hibrit yaklaşım işe yarıyor: Model eğitimi harici cloud’da, inference SAP AI Core’da. Veriyi dışarı çıkarmadan tahmin alıyorsunuz.

Pratik Kod: SAP Integration Suite ile Event Tetikleme

Aşağıda SAP Cloud Integration üzerinde çalışan bir Groovy script örneği var. Bu script, gelen kalite verisi mesajını parse edip SAP Event Mesh’e iletmek üzere hazırlıyor:

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.json.JsonSlurper
import groovy.json.JsonOutput

/**
 * Groovy Script: Kalite verisi dönüşümü ve event hazırlama
 * Çalıştığı ortam: SAP Cloud Integration (CPI)
 * Önkoşul: Gelen mesaj body'si JSON formatında olmalı
 */
def Message processData(Message message) {
    
    def body = message.getBody(String.class)
    def jsonSlurper = new JsonSlurper()
    
    try {
        def inputData = jsonSlurper.parseText(body)
        
        // Zorunlu alanların varlığını kontrol et
        if (!inputData.inspectionLot || !inputData.material || !inputData.results) {
            throw new Exception("Zorunlu alanlar eksik: inspectionLot, material veya results")
        }
        
        // SAP QM uyumlu yapıya dönüştür
        def eventPayload = [
            specversion: "1.0",
            type: "com.company.quality.resultsReceived",
            source: "/mes/qualityControl",
            id: UUID.randomUUID().toString(),
            time: new Date().format("yyyy-MM-dd'T'HH:mm:ss'Z'"),
            datacontenttype: "application/json",
            data: [
                inspectionLot: inputData.inspectionLot,
                material: inputData.material,
                plant: inputData.plant ?: "1000",
                results: inputData.results.collect { result ->
                    [
                        characteristic: result.charac,
                        measuredValue: result.value,
                        uom: result.unit,
                        isWithinSpec: isValueWithinSpec(result.value, result.lowerLimit, result.upperLimit)
                    ]
                }
            ]
        ]
        
        // Anomali kontrolü için flag ekle
        def hasAnomalies = eventPayload.data.results.any { !it.isWithinSpec }
        eventPayload.data.requiresAIInspection = hasAnomalies
        
        message.setBody(JsonOutput.toJson(eventPayload))
        message.setHeader("Content-Type", "application/json")
        message.setHeader("X-Quality-HasAnomalies", hasAnomalies.toString())
        
    } catch (Exception e) {
        // Hata detayını header'a yaz, dead letter queue'ya yönlendir
        message.setHeader("X-Processing-Error", e.message)
        message.setHeader("X-Routing-Target", "deadLetterQueue")
        
        // Orijinal mesajı koru
        message.setProperty("originalPayload", body)
    }
    
    return message
}

/**
 * Ölçüm değerinin spec limitler içinde olup olmadığını kontrol eder
 */
def boolean isValueWithinSpec(def value, def lower, def upper) {
    if (value == null) return false
    def numValue = value as Double
    if (lower != null && numValue < (lower as Double)) return false
    if (upper != null && numValue > (upper as Double)) return false
    return true
}

Bu scriptin kritik tasarım kararları:

• CloudEvents spec uyumu: Event payload’ı CloudEvents 1.0 standardına göre biçimlendirdik. Bu, gelecekte başka event consumer’lar eklediğinizde uyumluluk sağlar.
• Dead letter queue yönlendirmesi: Hata durumunda mesaj kaybolmuyor; özel header ile işaretlenerek hata kuyruğuna yönlendiriliyor. Takip ve retry mekanizması için kritik.
• AI inspection flag’i: Spec dışı sonuçlar varsa event üzerine flag ekliyoruz. AI modeli gereksiz yere her event için çalışmıyor; sadece şüpheli durumlar için tetikleniyor. Bu hem maliyet hem de latency açısından önemli.

Gözlemlenebilirlik ve İzleme: Otomasyonun Körü Körüne Çalışmasına İzin Vermeyin

Bir otomasyonu production’a aldıktan sonra en büyük risk, “çalışıyor sanıyoruz ama aslında sessizce hata yapıyor” senaryosudur. Bu konuda acı dolu tecrübem var.

Akıllı süreç otomasyonu için izleme katmanınızın şunları kapsaması gerekiyor:

• Process Instance Tracking: Her otomasyon akışının başlangıç-bitiş logları, kaç adım tamamlandı, nerede bekledi
• AI Model Drift İzleme: Modelinizin tahmin doğruluğu zamanla düşebilir. SAP AI Launchpad üzerinde model metriklerini periyodik olarak izleyin
• Business KPI Entegrasyonu: Teknik loglar yetmez. “Kaç fatura otomatik işlendi?”, “Ortalama işlem süresi ne kadar düştü?” gibi iş metrikleri SAP Analytics Cloud’a akmalı
• Anomali Alerting: Bot beklenmedik biçimde durduğunda veya hata oranı eşik değeri aştığında SAP Alert Management veya harici araçlar (PagerDuty, OpsGenie) üzerinden bildirim gitmeli

Sık Yapılan Mimari Hatalar

Bu alanda danıştığım projelerde tekrar eden hatalar var:

❌ Hata 1: Tüm Süreci Tek Bir Bot’a Yüklemek

Uzun, monolitik bot akışları hem debug edilmesi zor hem de kırılgan. Her bir iş adımını bağımsız, küçük bot bileşenlerine ayırın. Birisi hata verse, tüm süreci baştan çalıştırmak zorunda kalmayın.

❌ Hata 2: Test Ortamı Olmadan Production’a Geçmek

SAP’de QAS (Quality Assurance) ortamında tam olarak test edilmemiş bot, production’da farklı davranıyor. Özellikle authorization nesne farklılıkları ve master data tutarsızlıkları burada yüze çıkıyor.

❌ Hata 3: AI Modelini “Kur-Unut” Olarak Yönetmek

Modeli bir kez deploy edip unutmak ciddi bir hata. Üretim verisi zamanla değişir, mevsimsel örüntüler oluşur. Modeli düzenli aralıklarla yeniden eğitin veya en azından performans metriklerini izleyin.

❌ Hata 4: İş Birimini Sürece Dahil Etmemek

IT ekibi harika bir otomasyon tasarlıyor ama iş birimi süreci tam olarak anlatmıyor. Sonuç: Otomasyon teknik olarak çalışıyor ama iş kurallarını eksik karşılıyor. Süreç sahiplerini en başından dahil edin, sadece son testlerde değil.

Gelecek Yönelimi: GenAI SAP Otomasyonunu Nasıl Dönüştürüyor?

SAP’nin Joule asistanı ve BTP üzerindeki generative AI yetenekleri, otomasyon anlayışını köklü biçimde değiştiriyor. Geleneksel RPA’da her adımı önceden kodlamak zorundaydınız. GenAI ile:

• Bot, belirsiz durumlarda kendi kararını verebiliyor (örneğin, bir faturayı onaylamak için yeterli bilgi yoksa, eksik bilgiyi tedarikçiden otomatik talep ediyor)
• Doğal dil ile süreç tanımlayabiliyorsunuz: “Stok seviyesi kritik eşiğin altına düşünce satın alma önerisi oluştur ve ilgili yöneticiye özet e-posta gönder”
• SAP HANA’nın vector engine’i ile geçmiş benzer vakalar bulunuyor ve yeni kararlar tarihsel bağlamla alınıyor

Bu gelişmeler heyecan verici ama bir uyarı: GenAI tabanlı otomasyon, deterministik RPA’ya kıyasla çok daha dikkatli governance gerektiriyor. Modelin yanlış karar verme riski var ve bu kararlar SAP’deki işlemsel verileri etkiliyor. Her GenAI destekli bot için insan onay adımı ve rollback mekanizması mutlaka tasarlayın.

Sonuç: Mimari Önce, Araç Sonra

SAP BTP üzerinde akıllı süreç otomasyonu inşa etmek bir araç seçiminden çok bir mimari disiplin meselesi. Hangi servisin nerede kullanılacağına, veri akışının nasıl tasarlanacağına ve AI bileşeninin nereye konumlanacağına verilen kararlar, projenin uzun vadeli başarısını belirliyor.

Özetlemek gerekirse:

• SAP odaklı süreçler için SAP Build Process Automation tercih edin
• Dayanıklı ve ölçeklenebilir akışlar için event-driven mimari benimseyin
• AI modellerini eğitimde ve inference’da bağımsız yönetin
• Otomasyonu kör bırakmayın; kapsamlı gözlemlenebilirlik kültürü oluşturun
• GenAI yeteneklerini entegre ederken governance çerçevenizi önce hazırlayın

Bu alana yeni başlıyorsanız, bir pilot süreçle başlamanızı öneririm: Yüksek hacimli, net kurallı, hata toleransı olan bir süreç seçin. Başarıyı ölçün, mimariyi kanıtlayın, sonra ölçeklendirin. Büyük otomasyonlar küçük adımlarla inşa edilir.

Aynı zamanda temiz, sürdürülebilir ABAP kodunun bu otomasyon süreçlerindeki temel önemini hatırlatmak isterim. BAPI’lar ve RFC’ler üzerinden tetiklenen bot iş akışları, arka plandaki ABAP kodunun kalitesine doğrudan bağlıdır. Bu konuda ABAP Clean Code: Okunabilir ve Sürdürülebilir SAP Kodu Yazmanın 10 Altın Kuralı makalemize göz atmanızı tavsiye ederim.

Sizin Deneyiminiz?

SAP ortamında RPA veya AI entegrasyonu üzerinde çalışıyor musunuz? Hangi mimari kararları en zorlu buldunuz? Aşağıda yorumlarınızı paylaşın—gerçek deneyimlerden çıkan tartışmalar bu alana katkı sağlayan en değerli kaynaklar.

Bu makaleyi faydalı bulduysanız, SAP ekosistemiyle çalışan mimarlara ve geliştiricilere paylaşmayı unutmayın.