SAP entegrasyon platformları: araçlar, lisans, senaryolar

SAP entegrasyon platformları: araçlar, lisanslama ve gerçek hayat senaryoları

SAP'yi daha geniş bir sistem ortamına entegre etmek, bazı parçaların bir türlü oturmadığı bir bulmaca çözmeye benzeyebilir. Dikkat çekmek için yarışan farklı araçlar, platformlar ve veri biçimleri. Aralarında SAP Integration Suite'in de bulunduğu, hepsi kendisinin en uygun seçenek olduğunu iddia eden bu kadar çok entegrasyon seçeneği varken bunaltıcı olabilir. Ekiplerin haftalarca platform karşılaştırdığını, sonunda lisanslama etkileri ya da yük altındaki sistem gecikmesi gibi temel bir şeyi atladıklarını fark ettiklerini gördüm.

Bu sayfa, işleri biraz netleştirmeye çalışıyor. Belki kusursuz değil, ama güvenle seçim yapmaya yetecek kadar net. SAP entegrasyon platformlarına pratik açıdan bakıyorum:

Hangi araçların gerçekten birlikte iyi çalıştığı
Dolaylı lisanslamanın sizi nerede yanıltabileceği
SAP Integration Suite, CPI, PI ve BTP araçlarının gerçekte nasıl kıyaslandığı
Üçüncü taraf araçların SAP'nin kendi araçlarından ne zaman daha mantıklı olduğu

Her proje için tek bir cevap yok. Ama kullanım senaryosu netleştiğinde doğru entegrasyon yolu genellikle kendini belli eder. En azından umut bu.

1. SAP Integration Suite'e giriş

SAP uygulaması nadiren yalnızca SAP'yi kurmakla ilgilidir. Çoğu zaman mesele SAP'yi geri kalan her şeyle çalıştırmaktır: eski sistemler, bulut uygulamaları, veritabanları ve işletmenin yıllardır güvendiği özel araçlar.

Entegrasyonun kritik hâle geldiği yer burası. Tüm sistem ortamını bir arada tutabilir ya da bir şey bozulana kadar kimsenin fark etmediği sürtünmeye sessizce yol açabilir.

Pratikte entegrasyon hafife alınır. Ekipler işlevselliğe, süreç tasarımına ve teste odaklanır. Oyunun geç bir noktasında biri şunu fark eder:

Kritik veriler gerçek zamanlı senkronize olmuyor
API limitlerine haftalar önce ulaşılmış
Dolaylı kullanım yüzünden lisans maliyetleri ikiye katlanmış
Seçilen middleware yük altında hacmi kaldıramıyor

Bunlar başta her zaman belli olmaz. Ama sonunda takvimi, bütçeyi ve hatta uyumluluğu etkiler.

Bu sayfa SAP Integration Suite konusuna o açıdan bakıyor: araçların proje ortamlarında gerçekte nasıl çalıştığına, hangi sorunları çözdüğüne ve risklerin nerede saklanma eğiliminde olduğuna.

Uygulama değerlendirmenizi başlatın SAP entegrasyonu

2. SAP projelerinde yaygın entegrasyon senaryoları

SAP projeleri genellikle boş bir sayfayla başlamaz. Mevcut sistemlerin bir karışımıyla başlarlar: bazıları iyi belgelenmiş, bazıları pek anlaşılmamış. Entegrasyon bunların hepsine anlam kazandırmak zorundadır, çoğu zaman da gecikmeye pek yer olmadan.

Çoğu sistem ortamında karşımıza çıkan birkaç örüntü var:

SAP'den SAP dışı sistemlere bağlantılar. Hâlâ kullanımda olan eski ERP'ler, CRM'ler ya da kurum içinde geliştirilmiş uygulamalar.
Hibrit kurulumlar. Senkron kalmaya çalışan bulut hizmetleri ile on-premise sistemlerin karışımı.
Gerçek zamanlı ve toplu akışlar. Hızlı olmak iyidir, ama çoğu zaman güvenilir olan kazanır.
API odaklı ve middleware tabanlı yaklaşımlar. Duruma göre bazen ikisi birden.

SAP Integration Suite gibi araçlar, bu örüntülerin çoğunu, özellikle hibrit ya da bulut ağırlıklı ortamlarda ele almak üzere tasarlanmıştır. Ama araç tek başına çözümün yalnızca bir parçasıdır.

SAP'yi dış platformlara bağlamak, biçimler, güvenlik ya da zamanlama işin içine girene kadar çoğu zaman basit gelir. Ekiplerin küçük uyumsuzluklar yüzünden günlerce takılıp kaldığını gördüm. Bir taraf REST konuşuyor, diğeri düz dosyada ısrar ediyor.

Hibrit kurulumlar ilk bakışta esnek görünebilir. Pratikte genellikle bir istisnalar yamasının üzerine kurulurlar. Bir servis veriyi anında gönderir. Bir diğeri hâlâ gece çalışan işlere dayanır.

Gerçek zamanlı entegrasyon planlama aşamasında herkese cazip gelir. Ama yalnızca iki sistem de bunu kaldırabildiğinde işe yarar. Bu her zaman geçerli değildir.

Middleware yapı sunar, API'ler hız. Birini ötekine tercih etmek, zevkten çok halihazırda neyin kurulu olduğuna ve ekibin gerçekçi olarak neyi yönetebileceğine bağlıdır.

Göz önünde bulundurulması gereken uygulamalar arası entegrasyon senaryoları

1. SAP'den SAP dışı sistemlere entegrasyon

SAP'nin çoğu zaman Salesforce, Oracle ya da sektöre özgü araçlar gibi platformlarla bağlantı kurması gerekir. Bu entegrasyonlar kritik iş sistemleri ve süreçleri arasında sürekliliği sağlar.

SAP ile üçüncü taraf platformlar arasında yapılandırılmış veri alışverişini mümkün kılar
Kimlik doğrulama, alan eşleme ve dönüştürme katmanlarını içerir
SAP geçişleri sırasında mevcut iş akışlarının korunmasına yardımcı olur

2. Hibrit sistem ortamları (on-premise / bulut)

SAP müşterilerinin çoğu hibrit ortamlarda çalışır. On-premise SAP sistemleri bulut platformlarıyla bir arada var olur; bu da entegrasyonu veri tutarlılığı ve iş çevikliği için vazgeçilmez kılar.

SAP ECC ya da S/4HANA'yı SuccessFactors veya Ariba gibi bulut ürünlerine bağlar
Farklı protokoller ile güvenlik modelleri arasında köprü kurar
Gecikme ve senkronizasyon sorunlarını önlemek için güçlü yönetişim gerektirir

3. Gerçek zamanlı ve toplu (batch) entegrasyon

Gerçek zamanlı ve toplu entegrasyon arasında seçim yapmak sistemin kapasitesine, veri hacmine ve iş ihtiyaçlarına bağlıdır. Tüm süreçler anlık veri senkronizasyonundan aynı ölçüde yararlanmaz.

Gerçek zamanlı yaklaşım, sipariş oluşturma veya stok güncellemesi gibi işlemlerde iyi çalışır
Toplu yaklaşım, fiyatlandırma, ana veri veya geçmiş yüklemeleri gibi büyük veri kümeleri için daha uygundur
Çoğu sistem ortamı, sürecin kritikliğine göre ikisini de kullanır

4. API tabanlı entegrasyon

API tabanlı entegrasyonlar, uygulamaların hafif protokoller kullanarak doğrudan iletişim kurmasını sağlar. Bulut tabanlı (cloud-native) servislere ve modern geliştirme ortamlarına çok uygundur.

SAP'yi mobil uygulamalara, portallara ya da mikro servislere bağlamak için ideal
Devreye almak daha hızlı, ancak sıkı sürüm yönetimi ve güvenlik önlemleri gerektirir
Sıklıkla SAP API Management ve OData servisleriyle birlikte kullanılır

5. Middleware tabanlı entegrasyon

Middleware, SAP'yi birden çok sistemle entegre etmek için merkezi bir kontrol noktası ekler. Orkestrasyon, mesaj kuyruklama ve veri dönüştürme yoluyla karmaşıklığı yönetmeye yardımcı olur.

Birden çok sistemin SAP ile etkileşime girdiği sistem ortamlarında kullanılır
Merkezi izleme ve hata yönetimi sağlar
Örnekler: SAP PI/PO, SAP Integration Suite, MuleSoft, Dell Boomi

6. Karma entegrasyon yaklaşımları

Çoğu kuruluş API ve middleware stratejilerinin bir bileşimini kullanır. Bu hibrit model, sistem kısıtlarına, ekip becerilerine ve uzun vadeli destek ihtiyaçlarına uyum sağlar.

Doğrudan ve yönetilen entegrasyon yöntemlerini birleştirir
Gelecekteki genişleme ya da araç değişiklikleri için esneklik sağlar
Entegrasyonu hem teknik hem de iş önceliklerine uyumlu kılmaya yardımcı olur

3. SAP Integration Suite'e genel bakış

SAP entegrasyonunda doğru SAP Integration paketini seçmek çoğu ekibin beklediğinden daha önemlidir. Karar, özelliklerin ve hızın ötesine geçer. Takvimi, destek modellerini ve hatta lisanslamayı etkileyebilir. Projelerin takıldığını gördüm; nedeni entegrasyonun başarısız olması değil, platformun işletmenin çalışma biçimine uymamasıydı.

SAP birkaç entegrasyon seçeneği sunuyor: bazıları eski, bazıları yeni, bazıları da insanların fark ettiğinden fazla üst üste biniyor. Hangi aracın kullanılacağı konusunda sık sık tartışma çıkar. Elbette duruma bağlı. Neyi bağladığınıza. Verinin nasıl hareket etmesi gerektiğine. Ekibin neyi bildiğine.

Hiçbir araç her şeyi kapsamaz. Her birinin artıları ve eksileri var. Ama her birinin en iyi nerede işe yaradığını anlarsanız, büyük resim daha anlamlı hâle gelmeye başlar.

İşte en yaygın kullanılan SAP entegrasyon platformlarının, SAP'nin onları nasıl pazarladığına değil, gerçek projelerde nasıl uygulandıklarına dayanan kısa bir dökümü.

SAP entegrasyon platformları

1. SAP PI / PO (Process Integration / Orchestration)

PI/PO yıllardır on-premise SAP entegrasyonunun standardı oldu. Mesaj dönüşümlerini, iş akışlarını ve çeşitli protokol dönüşümlerini yönetir. Güvenilir olsa da daha dinamik ortamlarda biraz ağır kalır. Yine de karmaşık arka uç mantığıyla uğraşırken işi görür.

SAP'den SAP'ye ve eski sistem entegrasyonları için çok uygun
IDoc, BAPI, RFC, SOAP ve daha fazlasını destekler
Sıklıkla ECC tabanlı ya da hibrit kurulumlarda kullanılır

2. SAP CPI / Integration Suite

SAP CPI daha uyumludur ve önce bulut ile hibrit sistem ortamları için tasarlanmıştır. Özellikle SAP'ye yeni ekipler için kullanmaya başlamak daha kolaydır. Hazır iFlow'lar yardımcı olur, ama gerçek özelleştirme yine de zaman alır. Yeni S/4HANA projelerinin çoğunda genellikle varsayılan seçim budur.

Bulut ve hibrit entegrasyonları destekler
Yeniden kullanılabilir içerik paketleri ve adaptörler içerir
SAP Integration Suite lisanslama modelinin parçasıdır

3. SAP API Management

Verinin fiilen taşınmasından çok yönetişime odaklanır. API Management, kimin neye hangi koşullarda eriştiğini kontrol etmenize yardımcı olur. Onu bir teslimat aracından çok bir ön kapı gibi düşünün. API'leri iş ortaklarına ya da iç kullanıcılara açarken işe yarar.

Trafik kontrolü, hız sınırlama (throttling) ve kimlik doğrulama için kullanılır
SAP API'lerini dış uygulamalara açarken kullanışlıdır
Çoğu zaman CPI'yı ya da diğer arka uç araçlarını tamamlar

4. SAP BTP Integration Services

Bu, CPI'yı, API Management'ı, olay yönetimini ve daha fazlasını içeren daha geniş bir şemsiye. Araçları yönetmek için merkezi bir yer sunar, ama araçlar yine de bir ölçüde bağımsız davranır. Değer, onların bir araya paketlenmiş ve gevşek biçimde birleştirilmiş olmasında.

Birkaç SAP entegrasyon bileşenini bir araya getirir
SAP BTP cockpit üzerinden merkezi erişim
Çok araçlı entegrasyon ortamları için kullanışlıdır

5. SAP Data Intelligence

Data Intelligence, verinin platformlar arasında yapılandırılmış bir veri hattı (pipeline) içinde akması gerektiğinde kullanılır. İşlemden çok analitik düşünün. SAP'yi veri göllerine, makine öğrenimi araçlarına ya da günlük süreç akışlarının parçası olmayan diğer dış kaynaklara bağlar.

Platformlar arası veri orkestrasyonuna odaklanır
Analitik ve makine öğrenimi yığınlarıyla entegre olur
Yüksek frekanslı işlemler için değil, veri hatları için en uygunudur

6. Doğru aracı seçmek

Tek bir “en iyi” platform yoktur. Doğru araç, neyin entegre edildiğine, entegrasyonun ölçeğine ve ne kadar esnekliğe ihtiyaç duyulduğuna bağlıdır. Bazen mesele ekibinizin zaten neyle rahat olduğudur. Bu da sayılır.

Araçla değil, kullanım senaryosuyla başlayın
Lisanslamayı, beceri erişilebilirliğini ve destek modelini değerlendirin
Çoğu zaman birden fazla araç paralel olarak kullanılır

SAP ile çalışan üçüncü taraf entegrasyon platformları

1. Dell Boomi

Dell Boomi, hızlı devreye alma ve yeniden kullanılabilir entegrasyonlara ihtiyaç duyan kuruluşlara uygun, düşük kodlu (low-code), bulut tabanlı bir platform sunar. SAP'ye hazır bağlayıcılarla bağlanır ve hem gerçek zamanlı hem de toplu iş akışlarını etkili biçimde yönetir.

Daha hızlı uygulama için düşük kodlu arayüz
SAP'yi bulut uygulamalarına, CRM'lere ve eski sistemlere bağlar
Hibrit ihtiyaçları olan orta ölçekli kuruluşlar için iyi bir seçim

2. MuleSoft

MuleSoft, SAP'nin ötesinde büyük ölçekli entegrasyon ihtiyaçları olan kuruluşlarda sıkça kullanılır. API odaklı bağlantı ve zengin bir geliştirici deneyimi sunar. SAP bağlayıcıları güçlüdür, ancak iyi yapılandırmak başta daha fazla emek gerektirebilir.

Esnek servis tasarımı için API öncelikli model
SAP'yi daha geniş kurumsal mimariye entegre ederken kullanılır
Karmaşık ya da dağıtık sistemler için daha uygun

3. Informatica

Informatica, veri ağırlıklı ortamlarda öne çıkar. ETL, ana veri yönetimi ya da analitiğe odaklanan entegrasyonlar için sık seçilir. Doğrudan SAP entegrasyonu desteklenir, ancak genellikle diğer platformlara göre gerçek zamanlıya daha az odaklanır.

Yüksek hacimli veri taşıma ve temizleme için ideal
Raporlama ya da MDM senaryoları için çoğu zaman SAP ile birlikte kullanılır
Olgun BI ortamlarına sahip kuruluşlara uygun

4. Üçüncü taraf platformlar ne zaman kullanılmalı

Bazen SAP'nin yerel araçları uymaz, özellikle karma sistem ortamlarında. Üçüncü taraf bir araç daha iyi bağlayıcılar, daha basit arayüzler sunabilir ya da yalnızca mevcut iç uygulamalarla örtüşebilir.

Ekipler dış platformlar konusunda zaten eğitimliyse
SAP, çok daha büyük bir mimarinin yalnızca bir parçasıysa
Gerçek zamanlı, düşük kodlu ya da gelişmiş veri entegrasyonu gerektiğinde

5. Lisanslama ve maliyet etkenleri

Lisanslama platformlar arasında büyük farklılık gösterebilir. SAP araçları entegrasyonu çoğu zaman mevcut aboneliklerin içine paketler. Üçüncü taraf araçlar esneklik sunabilir, ancak fiyatlandırma modelleri hacme ya da kullanıcı sayısına bağlı olarak hızla büyüyebilir.

Maliyeti işlem hacmine ve bağlayıcılara göre değerlendirin
Halihazırda lisanslı SAP yetenekleriyle çakışmaya dikkat edin
Yalnızca lisans bedellerini değil, TCO'yu da düşünün

6. Entegrasyon bakımı ve desteği

Üçüncü taraf platformlar farklı destek modelleri gerektirebilir. Bazıları güçlü bir sağlayıcı desteği sunar, bazıları ise ağırlıklı olarak iç becerilere dayanır. Uzun vadeli bakım, yalnızca ilk kurulum hızı değil, kararın da bir parçası olmalıdır.

Sağlayıcının SLA'larını ve güncelleme döngülerini kontrol edin
İç bilgi birikimini ya da dış danışman ihtiyacını hesaba katın
Yönetişimi, sürüm yönetimini ve güvenlik güncellemelerini planlayın

4. SAP Integration Suite'te doğru bileşenleri seçmek

Mükemmel bir entegrasyon aracı yoktur. Bir SAP projesinde işe yarayan, bir diğerinde gereksiz yük yaratabilir. SAP Integration Suite içindeki doğru bileşenleri seçmek, çalıştığınız sistem ortamına ve entegrasyonlarınızın altında kalacağı baskının türüne bağlıdır: teknik, operasyonel ve bazen siyasi.

Seçenekleri birkaç ölçüte göre daraltarak başlayın:

Sistem ortamı: Kaç sistem söz konusu? Hepsi SAP mi, yoksa bulut ve SAP dışı araçların karışımı mı?
Gecikme ihtiyaçları: Veri anında mı taşınmalı, yoksa gecikme kabul edilebilir mi?
Genişletilebilirlik: Sık sık yeni sistemler eklenecek mi? Esneklik, standartlaştırmadan daha mı önemli?
Hacim: Saatte birkaç kayıt mı taşıyorsunuz, yoksa dakikada on binlerce mi?

Platformların farklı ihtiyaçlarla nasıl eşleştiğine dair kaba bir görünüm:

SAP'den SAP'ye - PI/PO veya CPI
Buluttan buluta - CPI, MuleSoft, Boomi
API yönetimi - SAP API Management, MuleSoft
Yüksek hacimli ETL - Informatica, SAP Data Intelligence
Karmaşık orkestrasyon - PI/PO, MuleSoft, BTP Integration Services

5. SAP Integration Suite ile Oracle, Microsoft ve Salesforce

Gerçek SAP sistem ortamlarında SAP'nin yalıtılmış çalıştığını görmek nadirdir. Birçok ortamda Oracle, Microsoft ya da Salesforce gibi büyük, iş açısından kritik platformlar bulunur. Her biri kendi entegrasyon zorluklarını getirir: bazıları teknik, bazıları yapısal, bazıları da lisanslamanın gri alanlarına düşer.

1. SAP ↔ Oracle (ERP, İK, SCM)

SAP ve Oracle, daha büyük kuruluşlarda sıklıkla bir arada bulunur. Biri finansı yönetirken diğeri tedarik zincirini ya da İK'yı yönetir. Verileri güvenilir biçimde paylaşmalarını sağlamak başta yavaş gelebilir, özellikle modeller beklenenden daha farklıysa.

Oracle tablolarının çoğu zaman API'ler ya da ara (staging) katmanlar üzerinden açılması gerekir
SAP genellikle IDoc gönderir ya da BAPI kullanır; bunların çevrilmesi gerekir
Zamanlama kritiktir: toplu iş pencereleri senkronizasyon gecikmelerine yol açabilir
Oracle uygulamaları SAP süreçlerini otomatik olarak tetikliyorsa dolaylı erişim riskleri yaygındır

2. SAP ↔ Microsoft (Azure, Power Platform, M365)

Microsoft ve SAP, çoğu kişinin beklediğinden daha fazla noktada kesişir. İster Power BI SAP'den veri çeksin ister Teams canlı KPI'ları göstersin, bağlantılar artıyor. Ama entegrasyon dikkatli bir kurulum gerektirir. Bazı kısımlar sorunsuz. Bazıları pek değil.

Azure Logic Apps SAP API'lerini çağırabilir, ancak kimlik bilgilerinin dikkatle yönetilmesi gerekir
Power Platform bağlayıcılar sunar, ancak karmaşık akışlar için özel işlevler gerekebilir
Microsoft 365 (Excel gibi) çoğu zaman SAP verisini çevrimdışı düzenleyip sonra geri senkronize etmek için kullanılır. Bu kurulum, takip edilmezse sessizce lisanslama sorunları yaratabilir

SAP'nin Azure bağlantısı iyileşiyor, ancak hibrit modeller, özellikle on-premise sistemler söz konusu olduğunda hâlâ güçlü kimlik doğrulama gerektiriyor.

3. SAP ↔ Salesforce (müşteri verisi, siparişler, destek)

Salesforce neredeyse her zaman müşteriye dönüktür. Arka uçla SAP ilgilenir. İkisini köprülemek genellikle müşteri kayıtlarını, sipariş durumunu ve servis geçmişini senkronize etmekle ilgilidir.

Bu akışlar için SAP CPI ya da MuleSoft kullanımı yaygındır
Nesne modelleri farklıdır: Salesforce daha esnek, SAP daha katıdır
Salesforce'taki API hız limitleri yüksek hacimli senkronizasyonları durdurabilir
Salesforce, lisanslı bir kullanıcı olmadan SAP işlemlerini tetiklerse dolaylı lisanslama riski doğar

Bu bağlantılar bazen basit görünür. Ama hacim arttığında ya da süreç proje ortasında değiştiğinde karmaşıklık kendini gösterir. Bu istisnalar için erken plan yapmak nadiren boşa giden bir emektir.

CPI entegrasyonu

6. Dolaylı lisanslama nedir?

Dolaylı lisanslama, SAP dışındaki sistemlerin SAP ile arka planda etkileşime girdiği durumlarda ortaya çıkar. Hiç kimse SAP'ye doğrudan giriş yapmaz, ama iş süreçleri yine de ona dayanır. Yaygın bir örnek, hiçbir SAP kullanıcısı ekrana dokunmadan Salesforce'un SAP'de otomatik olarak satış siparişi oluşturmasıdır. Bu sayılır.

SAP buna “dolaylı erişim” (indirect access) diyor. Ve önemlidir, çünkü kullanıcı SAP'yi hiç görmese bile bu yine lisanslanabilir bir olay sayılır.

Bunu yönetmek için SAP, odağı kullanıcılardan belgelere kaydıran Digital Access modelini getirdi.

Tipik tetikleyicilerden bazıları şunlardır:

SAP'ye sipariş gönderen üçüncü taraf bir portal
Stok seviyelerini bir API üzerinden kontrol eden bir mobil uygulama
Giriş yapmadan müşteri verisini güncelleyen bir bot
SAP'den gerçek zamanlı fiyat çeken bir CRM

Sınırın nerede olduğu her zaman net değildir. Ama SAP başka bir sistem adına bir şey işliyorsa, kontrol etmeye değer.

7. Lisanslama ve uyumluluk değerlendirmeleri (doğrudan + dolaylı)

SAP projelerinde lisanslama genellikle geç gündeme gelir, bazen entegrasyon kararları çoktan verildikten sonra. Ama önemlidir. Çoğu kişinin beklediğinden de fazla. Özellikle üçüncü taraf sistemler adlandırılmış bir kullanıcı olmadan SAP'den okumaya ya da SAP'ye yazmaya başladığında.

Temel sorun çoğu zaman doğrudan ve dolaylı erişim ayrımına varır. Doğrudan erişim basittir. Adlandırılmış bir SAP kullanıcısı giriş yapar, bir süreci tetikler ve bu eylem lisanslıdır. Ama dolaylı erişim, harici bir sistem (Salesforce, özel bir portal, belki bir bot bile) arka planda SAP ile etkileşime girdiğinde ortaya çıkar. Bu da SAP'nin koşulları uyarınca kullanım sayılabilir.

Bununla başa çıkmak için SAP Digital Access modelini getirdi. Kullanıcı başına ücretlendirmek yerine, dolaylı erişimle oluşturulan belirli belge türlerinin sayısını sayar. Buna satış siparişleri, faturalar ya da malzeme hareketleri gibi şeyler dahildir. Kâğıt üzerinde daha nettir. Pratikte hâlâ gri alanlar var.

Uyumluluk riskleri çoğu zaman iyi niyetli otomasyonlardan doğar. Örneğin:

Kullanıcı girişi olmadan SAP'den fiyat çeken bir mobil uygulama
SAP'de müşteri kayıtlarını otomatik oluşturan bir CRM
Stok seviyelerini her saat kontrol eden bir zamanlama aracı

Bunların hepsi işe yarar. Ama düzgün izlenip raporlanmazlarsa lisans riskini tetikleyebilirler.

Maliyeti yönetmenin yolları var. SAP, belge tabanlı lisanslamaya geçiş için Digital Access Adoption Program (DAAP) teşvikleri sunuyor. Bazı şirketler ayrıca riskin nerede olduğunu izlemek için kullanım izleme araçları (SAP Passport ya da harici günlükleme araçları) uyguluyor.

Denetimler ise başka bir hikâye. Teknik, ticari ya da ikisi birden olabilir. Bazı denetimler öngörülebilir. Diğerleri o kadar değil. Her iki durumda da proaktif olmak, hazırlıksız yakalanmaktan genellikle daha ucuza gelir.

1. Salesforce, SAP'de satış siparişi oluşturuyor

Satış temsilcileri anlaşmaları Salesforce'a girer, o da sipariş verisini SAP'ye otomatik olarak gönderir. Hiçbir SAP kullanıcısı giriş yapmaz, ama arka uçta belgeler oluşturulur.

Sorun ne: Satış siparişleri, SAP dijital lisanslamasının kapsamına giren dolaylı erişimle oluşturuluyor.
Azaltma: SAP'nin Digital Access modelini kullanın ve bunları belge olarak sayın ya da adlandırılmış SAP kullanıcı iş akışlarıyla tetiklenecek şekilde yeniden yapılandırın.

2. Özel portal SAP'den fiyat okuyor

Herkese açık ya da iş ortaklarına dönük bir web portalı, SAP'den API ile çekilen gerçek zamanlı fiyatları gösterir. SAP kimlik doğrulaması kullanılmaz.

Sorun ne: Fiyat verisi erişimi adlandırılmış kullanıcıları atlıyor ve SAP arka ucunu izlenebilirlik olmadan açıkta bırakıyor.
Azaltma: Erişimi SAP API Management üzerinden yönlendirin ve uygun kullanıcı kimlik doğrulaması ya da kota kontrolleri uygulayın.

3. Mobil uygulama stok durumunu kontrol ediyor

Depo ekipleri, doğrudan SAP'ye giriş yapmadan canlı SAP stokunu sorgulayan bir mobil uygulama kullanır.

Sorun ne: Veriye dolaylı erişiliyor ve hacme ya da sıklığa bağlı olarak bu, lisanslama yükümlülüğünü tetikleyebilir.
Azaltma: Mobil kullanıcıları lisanslayın ya da erişimin belge tabanlı lisanslama eşiklerine uyduğundan emin olun.

4. E-ticaret platformu fatura oluşturuyor

Çevrimiçi satın almalar, SAP'ye otomatik fatura kayıtlarıyla sonuçlanır. Süreç tamamen sistemden sisteme işler, hiçbir SAP kullanıcısı dahil olmaz.

Sorun ne: Fatura oluşturma, dolaylı yapılıyorsa SAP'nin Digital Access modeli kapsamında lisanslanabilir bir olaydır.
Azaltma: Fatura belgelerini dijital erişim lisans sayımınıza dahil edin ve hacim eğilimlerini izleyin.

5. İK sistemi SAP'ye çalışan verisi yazıyor

Üçüncü taraf bir İK yazılımı çalışan ana verisini yönetir ve SAP HCM'i toplu işlerle günceller.

Sorun ne: Lisanslı bir SAP kullanıcısı olmadan ana veri oluşturmak, verinin nasıl işlendiğine bağlı olarak uyumsuz olabilir.
Azaltma: Bunların lisanslanabilir belge sayılıp sayılmadığını SAP ile netleştirin ve kullanım takibi uygulayın ya da adlandırılmış kullanıcılar üzerinden yönlendirin.

6. BI aracı SAP'den düzenli rapor çekiyor

Power BI ya da Tableau gibi raporlama platformları, zamanlanmış olarak OData veya JDBC üzerinden SAP tablolarına bağlanır ve veriyi sessizce çeker.

Sorun ne: Sık veri çıkarma, kimlik doğrulaması yoksa ya da kullanıcılar lisanslı değilse erişim politikalarını ihlal edebilir.
Azaltma: Erişimi yetkili raporlama kullanıcıları üzerinden yönlendirin ya da lisanslamayı doğru izleyen, SAP sertifikalı analitik bağlayıcılar kullanın.

8. Size nasıl yardımcı olabilirim?

SAP ve dijital dönüşümde 25 yıllık deneyimimle projeleri başlangıçtan canlıya geçişe kadar, bir de kimsenin konuşmadığı karmaşık orta bölümüyle birlikte gördüm. Bazen baştan ben yönetirim. Bazen de işler ters gittiğinde gemiyi dengelemek için çağrılırım.

Hangi durumda olursa olsun rolüm aynı: işletmenin gerçekte neye ihtiyaç duyduğunu sistemin gerçekte neyi sunabildiğiyle buluşturmak. Jargon yok. Dolgu yok. Burada bulacaklarınız teori değil. Sahada geçen yılların, gerçek baskı altında gerçek sorunları çözmenin şekillendirdiği şeyler.

Gereksinimleri toplamak

9. Bazı entegrasyon en iyi uygulamaları

Bir projenin başında entegrasyon genellikle işleri çalıştırmak demektir. Veriyi bir sistemden diğerine taşı, birkaç kutuyu işaretle, devam et. Ama asıl zorluk daha sonra, bir şey sessizce bozulduğunda ya da arayüzün en baştan nasıl kurulduğunu kimse hatırlamadığında ortaya çıkar.

En iyi uygulamalar katı bir standardı izlemekle ilgili değildir. Önlenebilir riski azaltmakla ilgilidir. Bu, daha güçlü kimlik doğrulama kullanmak ya da işler büyümeden önce izlemeyi kurmak anlamına gelebilir. Bazen de o an gerekenden daha fazla belgelemek demektir.

Birkaç şey, entegrasyonları uzun vadede sağlıklı tutmaya yardımcı olur:

OAuth2, SAML veya X.509 gibi güvenli protokoller kullanın
Akış basit görünse bile izleme kurun
Yeniden kullanılabilen ya da genişletilebilen iFlow'lar ve API'ler geliştirin
Nasıl çalıştığını ve başarısız olduğunda ne yapılacağını belgeleyin

Bu adımlar nadiren acildir. Ama sonradan saatler kazandırır. Bazen günler.

1. Her entegrasyon noktasını güvenceye alın

Güvenlik genellikle geç ele alınır, çoğunlukla canlıya geçişten hemen önce. Ama düzeltmesi en zor olduğu an tam da budur. Senaryoya göre OAuth2, SAML ya da sertifikalar kullanın. Statik kimlik bilgileri kullanılıyorsa bunların izini tutun ve düzenli olarak yenileyin. Onları bir yapılandırma dosyasında bırakıp kimsenin unutmamasını ummayın.

Şifrelemeyi yalnızca dışarıda değil, uçtan uca kullanın
Kimlik doğrulama protokollerini veri riskine göre seçin
Token süre dolumunu ve yenilemeyi erken test edin

2. En baştan izleyin

İzleme çoğu zaman bir olaydan sonra eklenir. Ama bir şey bozulmadan önce yerinde olduğunda en iyi işler. En asgari günlükleme bile yardımcı olur. Gösterişli panolarla ilgili değil. Neyin, ne zaman ve neden başarısız olduğunu bilmekle ilgili. Bu olmadan küçük bir sorunun izini sürmek bile saatler alabilir.

Hatalar ve zaman aşımları için uyarılar kurun
Yanıt sürelerini ve yeniden deneme sayılarını kaydedin
Varsa mevcut SAP izlemesini kullanın

3. Anı değil, yeniden kullanımı düşünerek tasarlayın

Acil sorunu hızlı, koda gömülü bir düzeltmeyle çözmek cazip gelir. Ama her tek seferlik çözüm sonradan sürtünme ekler. Yeniden kullanılabilir iFlow'lar, ortak dönüştürme mantığı ve parametrelendirilmiş girdiler, süreçler geliştiğinde, ki neredeyse her zaman gelişirler, zaman kazandırır.

Mümkün olduğunda şablon kullanın
İş kurallarını eşleme adımlarının içine koymaktan kaçının
Mantığı taşıma katmanlarından ayırın

4. Operasyonu düşünerek belgeleyin

Dokümantasyon genellikle tasarım aşamasında kalır. Ama destek ekiplerinin diyagramlardan fazlasına ihtiyacı vardır. Uç nokta çöktüğünde ya da bir alan eksik olduğunda ne olacağını bilmeleri gerekir. İyi dokümantasyon, destek talepleri açılmadan önce bu soruları yanıtlar.

Yeniden deneme mantığını, hata yönetimini ve sürüm bilgisini ekleyin
Girdi ve çıktı tarafındaki sistemlere dair varsayımları açıklayın
Akışlar değiştikçe belgeleri güncel tutun

5. Net bir sahiplik atayın

Bazı entegrasyonlar, kimsenin onlara sahip olmadığı fark edilmeden aylarca çalışır. Başarısız olduğunda herkes başkasının izlediğini varsayar. Bundan kaçının. Sahiplik atayın. Gayri resmî olsa bile. Bu tek adım, çoğu teknik düzeltmeden daha fazla kesinti süresini azaltır.

Her akış ya da arayüz için sorumluluğu tanımlayın
Sahibin günlüklere ve araçlara erişimi olduğundan emin olun
Sahipliği işe alıştırma ve devir teslim belgelerine ekleyin

6. Yalnızca açılış için değil, değişim için kurun

Arayüzler statik değildir. Alanlar değişir. API'lerin yeni sürümleri çıkar. Hacimler büyür. Akış fazla katıysa küçük değişikliklerde bile bozulur. Gereksinimler şimdilik istikrarlı görünse bile baştan ayarlamalara yer bırakın.

Eşlemelerde ve yapılandırmalarda sürüm kontrolü kullanın
Bilinen sınırları ve kısıtları açıkça belgeleyin
Entegrasyon akışlarını sürüm döngüleri sırasında gözden geçirin

10. Toplam maliyet ve ROI değerlendirmeleri

Entegrasyon projeleri çoğu zaman teknik hedeflerle başlar: sistemleri bağla, veriyi senkronize et, işleri çalıştır. Ama bunun altında maliyet, çoğu kişinin fark ettiğinden daha büyük bir rol oynar. Yalnızca baştaki lisanslama değil, sonradan ortaya çıkan maliyet türü: iş yükleri büyüdüğünde, gereksinimler değiştiğinde ya da bir geçici çözüm kalıcı hâle geldiğinde.

SAP CPI gibi bulut araçları başta daha uygun maliyetli görünebilir. Donanım yok, kurulum daha hızlı. Ama kullanıma dayalı fiyatlandırmada maliyetler hacimle birlikte yükselebilir. PI/PO gibi on-premise seçenekler fiyatlandırmada daha istikrarlıdır, ancak altyapı yüküyle gelir.

Bir de üçüncü taraf platformlar var. Her birinin kendi lisanslama modeli var: bazıları kullanıcı başına, bazıları işlem ya da bağlayıcı başına ücret alır. Toplamı hızla büyür.

Bu yüzden entegrasyona ROI açısından bakmak, “şimdi ne kadar tutuyor?” sorusundan fazlasını sormak demektir. İleriye bakmak demektir. Bu nasıl ölçeklenecek? Ve değişmesi gerektiğinde kim ödeyecek?

1. Bulut ve on-premise maliyetleri

SAP CPI gibi bulut platformları daha hızlı kurulum ve daha düşük altyapı maliyeti sunar, ama fiyatlandırma çoğu zaman kullanımla birlikte ölçeklenir. PI/PO gibi on-premise araçlar daha fazla baştan yatırım gerektirir, ancak özellikle donanım zaten mevcutsa zaman içinde maliyet istikrarı sağlayabilir.

Bulut: abonelik tabanlı, çoğu zaman mesaj ya da bağlantı başına
On-premise: CAPEX ağırlıklı, tekrarlayan lisans maliyetleri daha düşük
Fiyatlandırma, sistem hacmine ve BT ayak izine bağlıdır

2. SAP CPI lisanslamasının etkisi

SAP CPI kademeli, kullanıma dayalı bir model kullanır. Mesaj hacmine ve verime göre ücretlendirilirsiniz. Düşük ve orta senaryolarda öngörülebilirdir, ancak yoğun trafik ya da optimize edilmemiş akışlar maliyette sert artışlara yol açabilir.

Başlangıç kademeleri genellikle ayda yaklaşık 1.000 ila 2.000 € ile başlar
Yüksek hacimli mesajlar ya da standart olmayan adaptörler için ek ücretler
Maliyetleri proaktif yönetmek için kullanımı aylık takip edin

3. Üçüncü taraf middleware fiyatlandırması

MuleSoft, Dell Boomi ve Informatica farklı fiyatlandırma modelleri izler: bağlayıcı başına, kullanıcı başına ya da işlem başına. Temel fiyat uygun görünebilir, ama ölçeklendikçe çoğu zaman yeni ücretleri tetikleyen sınırlar ortaya çıkar.

MuleSoft: lisans + API hacmi + çekirdek paketler (yılda ~18 bin $+)
Boomi: entegrasyon süreci, bağlayıcı ya da kullanıcı kademesi başına
Informatica: maliyeti ETL hacmi ve platform hizmetleri belirler

4. Zaman içindeki değişim maliyeti

İlk kurulum maliyetleri hikâyenin yalnızca bir parçası. Değişiklikler (yeni uç noktalar, güncellenmiş eşlemeler ya da iş kuralı değişimleri), özellikle katı ortamlarda ek lisanslama ya da geliştirme maliyetleri getirebilir.

Karmaşık sistem ortamlarında yıllık %15 ila %30 değişim maliyeti öngörün
Daha modüler platformlar değişim sürtünmesini azaltma eğilimindedir
Özelleştirmeler lisans uzatmaları ya da danışmanlık gerektirebilir

5. Destek ve bakım maliyetleri

Destek, maliyet projeksiyonlarında çoğu zaman gözden kaçar. SAP CPI temel destek kademelerini içerir, ama yanıt süreleri ve SLA'lar değişir. Üçüncü taraf araçlar daha hızlı destek sunabilir, ancak bedeli vardır ya da ek hizmet sözleşmeleri gerektirir.

SAP desteği mevcut kurumsal sözleşmelere bağlıdır
Üçüncü taraf araçlar destek için yıllık lisans bedelinin %15 ila %20'sini talep edebilir
Sistem karmaşıklığı arttıkça iç destek ihtiyacı da artabilir

6. ROI'yi kurulumun ötesinde değerlendirmek

Gerçek ROI, yalnızca uygulamayı değil, zaman içindeki sahip olma maliyetini de içerir. Daha ucuz bir platform esneklikten yoksun olabilir; daha pahalı bir araç ise sonradan kesinti süresini ya da değişim emeğini azaltabilir. Yaşam döngüsü üzerinden değerlendirin, yalnızca açılış üzerinden değil.

Toplam lisans + bakım + destek + değişim maliyetini hesaba katın
ROI'yi yalnızca proje aşamasına değil, 2 ila 3 yıllık bir ufka göre tahmin edin
Başarısız ya da geciken entegrasyonların maliyetini olası risk olarak ekleyin

Sık sorulan sorular

Müşterilerin çoğu, bir SAP uygulamasını ilk kez düşünürken aynı sorular etrafında dolaşır.

Belki bunlardan birkaçını siz de sordunuz: gerçekte ne kadar sürdüğü, ne kadara mal olabileceği ya da sistem canlıya geçtikten sonra ne tür bir desteğe ihtiyaç duyulduğu. Haklı sorular.

Bu yüzden sizi tahminle baş başa bırakmak yerine, ne bekleyeceğinizi ve zorlu kısımların genellikle nerede ortaya çıktığını daha iyi kavramanıza yardımcı olacak net, dürüst yanıtlar derledim.

Bağlantı kuralım!

1. SAP CPI nedir?

SAP CPI, yani Cloud Platform Integration, SAP Integration Suite'in bir parçasıdır. Başlıca bulut ya da hibrit ortamlarda SAP ile SAP dışı sistemleri bağlamaya yardımcı olur. Onu middleware olarak düşünün, ama dağıtık sistem ortamları için tasarlanmış.

Şunları içerir:

Hazır entegrasyon akışları (iFlow denir)
HTTPS, SFTP ve OData gibi protokoller için destek
Özel eşleme, betik yazma ve yönlendirme seçenekleri

CPI, özellikle on-premise'ten buluta geçerken ya da üçüncü taraf uygulamaların SAP ile güvenli biçimde konuşması gerektiğinde işe yarar.

2. SAP, Salesforce ile nasıl entegre olur?

SAP ve Salesforce genellikle API'ler ya da SAP CPI, MuleSoft veya Dell Boomi gibi middleware üzerinden veri alışverişi yapar.

Yaygın kullanım senaryoları şunlardır:

Müşteri ana verisini senkronize etmek
Sipariş ve fatura ayrıntılarını aktarmak
Destek kaydı geçmişini ya da fiyat bilgisini paylaşmak

Zorluklar çoğu zaman veri modeli farklılıklarından ve Salesforce tarafındaki API limitlerinden gelir. Dikkatli eşleme ve hız sınırlama (throttling) anahtardır.

Lisanslama da bir endişe konusu olabilir. Salesforce SAP'de eylemleri tetikliyorsa dolaylı erişim söz konusu olabilir.

3. SAP dolaylı erişimi nedir?

Dolaylı erişim, harici sistemler bir kullanıcı doğrudan giriş yapmadan SAP ile etkileşime girdiğinde ortaya çıkar. Örneğin bir portal ya da üçüncü taraf uygulama, bir API aracılığıyla SAP'de satış siparişi oluşturur.

SAP bunu, kullanımın belge türüne göre (siparişler, faturalar vb.) takip edildiği Digital Access modeli kapsamında lisanslanabilir sayar.

Ekipleri hazırlıksız yakalayabilir. Sistemler arka planda sessizce çalışır, ama lisanslama riskini tetikleyen belgeler üretir.

Yönetmek için:

Harici sistemlerin SAP'yi nasıl kullandığını değerlendirin
Belge oluşturma hacmini izleyin
SAP'nin dijital belge tabanlı lisanslama yapısını göz önünde bulundurun

4. Hangi SAP entegrasyon aracı en iyisi?

Bu, neyi entegre ettiğinize, ne sıklıkla değiştiğine ve kimin bakımını yaptığına bağlıdır.

Buluttan buluta ya da hibrit için: SAP Integration Suite (CPI)
On-premise SAP'den SAP'ye için: SAP PI/PO
API yönetişimi için: SAP API Management
Veri hatları ve analitik için: SAP Data Intelligence
Daha geniş kurumsal entegrasyon için: MuleSoft veya Dell Boomi

Çoğu sistem ortamı bir karışım kullanır. “En iyi”nin ne olduğu, özelliklerden çok uyuma bağlıdır.

5. SAP, Microsoft ve Oracle ile entegre olabilir mi?

Evet, hem de sık sık.

SAP ↔ Microsoft

Azure Logic Apps, Power Automate ya da Power BI içindeki SAP bağlayıcıları
Yaygın kullanım: SAP verisini Excel'e, Teams'e ya da panolara çekmek

SAP ↔ Oracle

Genellikle middleware içerir (CPI, PI ya da üçüncü taraf)
Kullanım senaryoları arasında finans, satın alma veya İK entegrasyonu bulunur

Zorluklar arasında farklı kimlik doğrulama modelleri, zamanlama uyumsuzlukları ve bazı durumlarda lisanslama yer alır.

6. SAP Integration Suite nedir?

SAP Integration Suite, SAP'nin sistemleri, uygulamaları ve verileri bağlamak için geliştirdiği bulut tabanlı (cloud-native) platformdur. CPI'yı, API Management'ı, Open Connectors'ı ve event mesh yeteneklerini içerir.

Onu bir alet takımı olarak düşünebilirsiniz. Bazı parçalar hazırdır, bazıları yapılandırılabilir. Önce bulut ve hibrit ortamlar için tasarlanmıştır.

Temel faydalar:

Yaygın entegrasyonlar için hazır içerik
Gerçek zamanlı ve toplu işleme
Güvenlik, izleme ve yönetişim araçları

SAP'nin modern sistem ortamları için stratejik entegrasyon katmanı olarak konumlandırılmıştır.

7. SAP CPI, PI/PO'nun yerini alıyor mu?

Bulut ağırlıklı ya da hibrit sistem ortamlarında evet: tercih edilen yön SAP CPI. Ama PI/PO hâlâ destekleniyor ve özellikle ECC tabanlı sistemlerde ya da on-premise kurulumlarda yaygın olarak kullanılıyor.

SAP zaman içinde Integration Suite'e geçmeyi öneriyor, ancak zorunlu bir geçiş yok. Proje takvimine, sistem yol haritasına ve maliyete bağlı.

Bazı şirketler ikisini de kullanıyor ve CPI'yı kademeli olarak devreye alıyor.

8. SAP API güvenliğini nasıl ele alır?

SAP standart güvenlik protokollerini destekler:

Token tabanlı kimlik doğrulama için OAuth2
Birleşik kimlik (federated identity) için SAML
Sistemden sisteme güven için X.509 sertifikaları

Integration Suite ayrıca API hız sınırlama, kota uygulama ve politika yönetimi sağlar. Ekiplerin çoğu SAP güvenlik araçlarını Azure AD ya da Okta gibi kurumsal kimlik sağlayıcılarla birleştirir.

Güvenlik ihtiyaçları senaryoya göre değişir, bu yüzden bunu erken planlayın.

9. SAP entegrasyon maliyetini ne belirler?

Maliyeti birkaç etken etkiler:

Araç türü (bulut ve on-premise)
İşlem ya da mesaj hacmi
Arayüz ve sistem sayısı
Lisanslama modeli (örneğin CPI kullanıma dayalıdır)

Örneğin SAP CPI lisanslaması başta düşük görünebilir, ama hacimle birlikte hızla ölçeklenebilir. Üçüncü taraf middleware bağlayıcı ya da kullanıcı başına ücret alabilir.

Tahminlerinize yalnızca lisans bedellerini değil, destek ve değişim maliyetlerini de her zaman dahil edin.

10. SAP entegrasyonlarını nasıl izlerim?

SAP Integration Suite yerleşik izleme panoları, günlükler ve izleme (trace) araçları içerir. Şunları yapabilirsiniz:

Mesaj günlüklerini ve hataları gerçek zamanlı görüntülemek
Performansı ve gecikmeyi takip etmek
Başarısız ya da yavaş akışlar için uyarı kurmak

PI/PO gibi on-premise sistemlerde izleme Integration Engine'de ya da SAP Solution Manager üzerinden yapılır.

Önemli olan izlemeyi erken kurmaktır. Bir şey bozulana kadar beklemek genellikle önceden planlamaktan daha pahalıya gelir.

Ne üzerinde çalıştığınızı anlatın.

30 dakikalık bir görüşme. Programı, kararı ya da sorunu siz anlatırsınız. Yardımcı olup olamayacağımı söylerim; olamıyorsam kimin olabileceğini.

Projenizi konuşalım

SAP Integration Suite: araçlar, lisanslama ve gerçek hayat senaryoları

Ne üzerinde çalıştığınızı anlatın.