ERP’ye karşı değil, çevresinde: entegre edin, genişletin, taşıyın.
SAP ve büyük ERP ortamları için clean-core uzantıları, entegrasyon katmanları ve geçiş desteği — kayıt sistemine uygulanan mühendislik disiplini.
- Ortam incelemesi
- Mimari
- Geliştirme
- Cutover & işletme
Birinci kural: özel iş mantığı çekirdeğin dışında yaşar ve çekirdeğe sözleşmeyle bağlanır.
ERP, gerçeğin yaşadığı ve çevikliğin öldüğü yerdir — çevresindeki mimari bilinçli kurgulanmadıkça. Çekirdeğin içinde yıllar boyunca iyi niyetle yapılan özelleştirmeler yüzünden bir yükseltme programa dönüşür, basit bir onay ekranı aylar sürer ve her yeni tüketici sistem, sahibi olmayan bir noktadan noktaya arayüz olarak gelir. Kayıt sistemi kendi işini yapıyor; çevresindeki ortam birkaç işi birden kötü yapıyor.
Ürün ekiplerinin kayıt sistemini bozmadan hızlı ilerlemesini sağlayan clean-core uzantıları ve entegrasyon katmanları kuruyor, geçişleri hak ettikleri prova disipliniyle destekliyoruz. Özel iş mantığı, modern bir teknoloji yığını ya da SAP BTP üzerinde yan yana çalışır ve ERP’ye yönetilen sözleşmeler üzerinden erişir. Arayüzler envantere alınır, kararlı hale getirilir ve genellikle Kafka üzerinden API ve olay olarak yeniden sunulur; böylece yeni bir tüketici geliştirme yapmak yerine abone olur. Raporlama işlemsel çekirdekten değil veri ambarından okur — işin o yarısı Veri Mühendisliği tarafında durur.
Yükseltmelerin baştan yazıma dönüşmesini engelleyen budur — ve bu, kodun nereye konduğuna dair bir karardır, hangi tedarikçiden satın aldığınıza dair değil. İlke S/4HANA’da da, Oracle’da da, Dynamics’te de, uzun kuyruktaki sistemlerde de geçerlidir.
Dört iş kalemi, tek mimari.
Çoğu ERP ortamı dördüne de bir oranda ihtiyaç duyar. Birinci fazdaki inceleme, hangisinin acil olduğunu ve hangisinin bekleyebileceğini söyler.
Clean-core uzantıları
SAP BTP ya da seçtiğiniz modern bir teknoloji yığını üzerinde yan yana çalışan uygulamalar — ERP standart kalır, farklılaşma dışarıda yaşar. Uzantılar yalnızca yayımlanmış arayüzler üzerinden okur ve yazar; böylece bir support pack ya da yükseltme, düzeltme projesi değil bir regresyon testidir. Pratikte kullanıcıyı memnun eden arayüzler buraya taşınır: onay uygulamaları, self servis portalları, hiçbir çekirdek işlemden çizmesi beklenmemesi gereken saha ve üretim alanı ekranları.
Entegrasyon katmanı
IDoc, BAPI, RFC ve OData’nın önünde yönetilen API’ler ve olaylar durur; böylece her tüketici ekip için ayrı bir sözleşme yerine her iş nesnesi için tek bir sözleşme olur. Yeni tüketiciler belgelenmiş bir olaya abone olur ya da sürümlenmiş bir uç noktayı çağırır; hiçbir zaman veritabanı erişimi ya da kendilerine özel bir dosya aktarımı almazlar. Katman kendi izlemesini, yeniden denemelerini ve dead-letter yönetimini taşır; arayüz hatalarını ay sonunda değil erkenden görünür kılan da budur.
Geçiş mühendisliği
ECC’den S/4HANA’ya geçişler ve konsolidasyon programları yalnızca konfigürasyon değil mühendislik ister: veri doğrulama araçları, özel kod triyajı, arayüzlerin yeniden yönlendirilmesi, paralel koşular ve prova edilmiş cutover’lar. Aynı girdilerle yeni sistemin çıktısını eskisiyle karşılaştıran düzeneği kuruyor ve runbook sorunsuz işleyene kadar cutover’ı prova ediyoruz. Her prova bir hata listesi ve bir süre üretir; canlıya geçiş kararını bir olguya dönüştüren de budur.
Süreç otomasyonu
ERP’yi ve ortamın geri kalanını kapsayan iş akışları — onaylar, satın alma, finans operasyonları, tedarikçi katılımı — sistemler arasında kimse yeniden veri girmeden. Kurallar, eşikler ve yetki devri, işin değiştirebileceği iş akışı katmanında yaşar; ERP ise kayıtları ve ana veriyi tutar. Süreç standart bir back-office süreciyse, Workflow & Procurement onu zaten uygular ve ERP’ye aynı sözleşmeler üzerinden bağlanır.
İş günlük olarak nasıl yürür?
Asıl çıktı, sınırın kendisidir.
Ürettiğimiz ilk şey kod değildir. Yazılı bir sınırdır: hangi davranış çekirdekte standart kalır, hangisi dışarı çıkar ve ikisi arasındaki sözleşme nedir. Mevcut her özelleştirme sınıflandırılır — standart olarak kalsın, dışarı çıksın, süreç yıllar önce değiştiği için emekli edilsin — ve bu sınıflandırma yalnızca BT tarafından değil, süreci sahiplenen kişiler tarafından onaylanır. O sınır bir kez oluştuğunda iki şey gelir. Yükseltmeler pazarlık olmaktan çıkar, çünkü çekirdek standarda yakındır. Ürün ekipleri de geliştirme yapacak bir yer bulur ve bunun için basis ekibiyle görüşmeleri gerekmez, çünkü uzantı katmanının kendi sürüm hattı ve kendi testleri vardır.
- Her özelleştirme sınıflandırılır: kalsın, dışarı çıksın ya da emekli edilsin — sahibi adıyla birlikte
- Yalnızca yayımlanmış arayüzler; çekirdek dışından hiçbir şeye doğrudan tablo erişimi yok
- Uzantılar kendi sürüm hattında, ERP’ye karşı sözleşme testleriyle
Arayüz kaosu önce bir envanter sorunudur.
Kurumlar kaç arayüzleri olduğunu nadiren bilir ve kayıttaki sayı, çalışan sayıya nadiren eşittir. Sahipsiz, belgesiz ve mükerrer akışlar kuraldır — aynı tedarikçi ana verisini farklı yollardan çeken birkaç ekip. Bu yüzden iş bir envanterle başlar: her akış, yönü, sahibi, hacmi, hata oranı ve durduğunda akışın devamında ne olduğu. Kararsız çalışan akışlar bulundukları yerde kararlı hale getirilir. Ardından birden fazla tüketicisi olanların önüne yönetilen API’ler ve olaylar konur, arkalarındaki noktadan noktaya bağlantılar sessizce çalışmaya bırakılmak yerine emekli edilir.
- Akış başına sahip, hacim, hata oranı ve iş etkisiyle envanter
- Önce kararlılık, sonra API katmanı — bozuk tesisatın üstüne yeni mimari yok
- Akış başına panolar ve alarmlar — duran bir arayüz, finanstan önce fark edilir
Daha önce prova ettiğiniz bir cutover.
Geçiş riski, kimsenin prova etmediği saatlerde yoğunlaşır. ECC’den S/4HANA’ya bir programda bizim payımıza düşen mühendislik omurgasıdır: geçiş öncesi ve sonrası veriyi doğrulayan araçlar, aynı girdileri her iki sistemden geçirip sonuçları satır satır mutabık kılan bir düzenek, yeni sürüme karşı özel kod triyajı ve sözleşme testleriyle arayüzlerin yeniden yönlendirilmesi. Ardından cutover uçtan uca prova edilir — gerçek hacimlerle ve gerçek runbook’la — süreler bilinene ve hata listesi boşalana kadar. Canlıya geçiş hafta sonu, ekibin bunu ilk kez yaptığı an değildir.
- Paralel koşu mutabakatı, satır satır; farklar tolere edilmek yerine açıklanır
- Özel kod triyajı: ne yeniden yazılmalı, ne çekirdek dışına çıkar, ne silinir
- Geri alma noktası olan süreli cutover provaları ve her arayüzde hypercare izlemesi
Masanın her tarafı ne kazanır.
Standarda yakın kalan bir çekirdek.
Çekirdeğin içindeki özel kod küçülür, kalan nesneler belgelenir ve test edilir, yeni olan her şey yayımlanmış arayüzlerden gelir. Yükseltmeler bir keşif çalışması yerine planlı bir regresyon koşusuna dönüşür ve basis ekibi şirketteki her ürün fikrinin darboğazı olmaktan çıkar.
- Nesne başına sahibi ve emeklilik planı olan özel kod envanteri
- Her support pack ve yükseltme öncesinde çalışan sözleşme testleri
- Uzantılar çekirdek transport zinciriyle değil, kendi hattından devreye alınır
Basis ekibiyle görüşme gerektirmeyen bir geliştirme alanı.
Yan yana çalışan uygulamaların kendi depoları, ortamları ve sürüm ritmi olur; ERP’ye belgelenmiş bir sözleşme üzerinden erişilir. Ekipler transport penceresi için sıraya girmek yerine canlı benzeri bir sandbox üzerinde kendi ritimlerinde sürüm çıkarır; tedarikçi ya da sipariş verisinin yeni bir tüketicisi de arayüz sipariş etmek yerine bir olaya abone olur.
- İş nesnesi başına sürümlenmiş API ve olaylar; belgelenmiş ve keşfedilebilir
- Her uzantı ekibi için maskelenmiş veriyle canlı benzeri sandbox
- Entegrasyon & API Geliştirme ile paylaşılan teslimat kalıpları
Mutabık kalan kayıtlar ve kendini raporlayan arayüzler.
Finansın iki sorusu vardır: rakam tutuyor mu ve bir besleme durursa fark eden olacak mı. Geçiş sırasında birincisini sözleşme testleri ve paralel koşu mutabakatı yanıtlar; ikincisini sonrasında sürekli olarak akış başına izleme yanıtlar. Onay kuralları ve yetki devri, işin değiştirebileceği bir katmana taşınır ve her karar için denetim kaydı tutulur.
- Canlıya geçiş kararının kanıtı olarak paralel koşu mutabakat raporları
- Sahibi ve eskalasyon yolu tanımlı, arayüz başına erişilebilirlik izlemesi
- Konfigürasyon olarak onay eşikleri ve yetki devri, tam denetim iziyle
ERP’yi neye ve nasıl bağlıyoruz.
SAP S/4HANA · ECC
Tedarikçi ana verisi, satın alma siparişleri, mal girişi, fatura kayıtları ve masraf nesneleri; IDoc, BAPI/RFC ve OData üzerinden — önlerinde sürümlenmiş API’ler ve olaylarla.
SAP BTP
Yan yana uzantılar, event mesh ve destination servisleri; ortamın geri kalanıyla aynı testlerle kendi hatlarınızdan devreye alınır.
Oracle · Dynamics · diğer ERP’ler
Clean-core ilkesi tedarikçiden bağımsızdır: yayımlanmış arayüzler, bir entegrasyon katmanı ve raporlama veritabanında iş mantığı bulunmaması.
Depo yönetimi & üretim sahası
Stok hareketleri, teyitler ve MES sinyalleri; bir ağ kesintisi kayıp bir kayda değil birikmiş bir iş listesine dönüşsün diye tamponlanır.
CRM ve ticaret
Dışarı akan müşteri ve fiyat ana verisi, içeri akan siparişler; idempotent işleme sayesinde yeniden denenen bir sipariş asla iki kez kaydedilmez.
Bankacılık ve e-faturalama
Ödeme dosyaları, banka ekstreleri ve yasal e-fatura uç noktaları; mutabakat ve saklama birinci sınıf gereksinim olarak ele alınır.
Veri ambarı & BI
Raporlama işlemsel çekirdeği sorgulamayı bıraksın diye veri ambarına change data capture — bkz. Power BI ve Veri Mühendisliği.
İş akışı & satın alma
Çekirdek dışında, Workflow & Procurement ya da kendi iş akışı katmanınız üzerinde çalışan onaylar, tedarikçi katılımı ve satın alma süreçleri.
Dört faz, her birinde kullanabileceğiniz bir çıktı.
Ortam incelemesi
Modüller, özelleştirmeler, entegrasyon noktaları — ve her birinde saklı yükseltme borcu. Her özel nesne ve her arayüz; sahibi, hacmi ve hata oranıyla envantere alınır ve inceleme bir sınıflandırmayla biter: standart kalsın, dışarı çıksın, emekli edilsin. Devam etseniz de etmeseniz de çıktısı tek başına ayakta durur.
Mimari
Clean-core sınırı: ne standart kalır, ne dışarı çıkar ve aradaki sözleşmeler. İş nesnesi başına API ve olay kataloğunu, uzantı çalışma zamanını, ortamları ve test stratejisini tanımlıyor; ardından iş sırasını yalnızca BT ile değil, süreç sahipleriyle birlikte kararlaştırıyoruz.
Geliştirme
Uzantılar ve entegrasyon akışları sprint sprint teslim edilir, maskelenmiş veriyle canlı benzeri bir sandbox üzerinde test edilir. Her akış kendi izlemesi, yeniden denemeleri ve dead-letter yönetimiyle çıkar; her uzantı da kullandığınız ERP sürümüne karşı sözleşme testleriyle çıkar.
Cutover & işletme
Süreleri ölçülmüş runbook’lar ve bir geri alma noktasıyla prova edilmiş canlıya geçişler, her arayüzde izlemeyle hypercare, ardından her zamanki düzen — eskisinden daha sakin. Ortamı işletmeye devam etmemizi isterseniz bu, üzerinde anlaşılan servis seviyeleriyle DevOps & Bulut altında sürer.
Ne devredilir ve kime.
- Yönetilen API/olay sözleşmeleriyle entegrasyon mimarisi
- Clean-core uzantı uygulamaları
- Geçiş doğrulama araçları ve paralel koşu kanıtları
- Akış başına panolarla arayüz izleme
- Basis ve ürün ekiplerinizin ikisinin de kabul ettiği dokümantasyon
Bunun doğru tercih olduğu durumlar.
ERP hem kayıt sistemi hem de kısıt olduğunda bunu seçin: yükseltmeler çeyrekler sürüyor, her yeni tüketici bir arayüze daha dönüşüyor ve ürün fikirleri transport penceresi beklerken ölüyor. ECC’den S/4HANA’ya geçişe hazırlanan ve SI’larının yanında bir mühendislik omurgasına ihtiyaç duyan kurumlara, bir satın alma sonrası birkaç ERP’yi birleştiren gruplara ve arayüz hatalarının izleme yerine finans tarafından fark edildiği ortamlara uygundur. Daha sessiz duruma da uygundur: ERP iyi durumda, ama çevresindeki süreçler hâlâ elektronik tablolar ve e-postayla yürüyor.
İhtiyacınız çekirdek modül konfigürasyonu ya da tam kapsamlı bir uygulama ortağıysa bu yanlış bir çalışmadır — o iş SI’nızın işidir ve biz aksini iddia etmektense onların yanında mimariyi dürüst tutmayı tercih ederiz. Kurum iş mantığını çekirdeğin dışına çıkarmaya istekli değilse yanlıştır, çünkü yöntemin tamamı o sınıra dayanır. Sürecin kendisi henüz kararlaştırılmadıysa da erkendir: önce onayın ya da satın almanın nasıl olması gerektiğinde anlaşın, sonra otomatikleştirin.
Sık sorulan sorular
Bu hizmet genellikle nerede durur.
Ne inşa ettiğinizi bize anlatın.
Bugün elinizde ne olduğunu ve neye ihtiyacınız olduğunu anlatın. Bir mühendis okur; nasıl yaklaşacağımızı ve size uyan modeli yazılı olarak iletir.