
İçindekiler
Clean Core, bir S/4HANA yükseltmesinin altı hafta mı altı ay mı süreceğini belirler. Sisteminiz SAP standart nesnelerinde yapılmış modifikasyonlarla doluysa her sürüm bir regresyon projesine dönüşür. Özel mantığınız yayımlanmış arayüzlerin arkasında duruyorsa yükseltmeler rutin bakım olur.
S/4HANA programları başlamadan Clean Core ilkelerini uygulayarak yükseltme sürelerini yüzde 40 kısaltan firmalar gördüm. Bir tüketim malları şirketi eski fiyatlandırma mantığını çekirdeğin dışında kurulmuş modüler bir Fiori uygulamasıyla değiştirdi ve yükseltmeler artık bu mantığı bozmaz oldu.
Bu yazıyı Nisan 2025'te ilk yazdığımdan beri çok şey değişti. SAP artık Clean Core'u beş yol gösterici ilkeyle tanımlıyor ve Ağustos 2025'ten beri her uzantıyı dört seviyeden birine sınıflandırıyor. ECC tarihleri de daha net. Bu sürüm bunu yansıtıyor.
Clean Core, S/4HANA sisteminizi işinizin izin verdiği ölçüde SAP standardına yakın tutmak ve ekstra olan her şeyi yükseltmelere dayanacak biçimde kurmak demektir.
Hâlâ özelleştirme yapabilirsiniz. Özelleştirmenin SAP'nin yayımladığı ve kararlı tutmayı taahhüt ettiği arayüzleri kullanması gerekir. SAP bunun için iki yol sunuyor:
- On-stack, ABAP Cloud ile. Uzantılar S/4HANA'nın içinde çalışır ama yalnızca yayımlanmış API'leri ve uzantı noktalarını kullanır.
- Side-by-side, SAP BTP üzerinde. Uzantılar ayrı uygulamalar olarak çalışır ve S/4HANA ile API'ler ya da olaylar üzerinden konuşur.
SAP'nin kendi rehberi, önce BTP olmak üzere kullanım senaryosu bazında seçim yapmak yönünde. Deneyimime göre kodun nerede çalıştığı, gereksinimin kod gerektirip gerektirmediğinden daha az önemli.
Kirli bir çekirdek, ECC işletmiş herkese tanıdık gelir: değiştirilmiş standart programlar, doğrudan yazılan Z-tabloları, SAP'nin iç yapısını okuyan arayüzler, kimsenin belgelemediği örtük geliştirmeler. Bunların hiçbiri geliştirildiği zaman yanlış değildi. Sadece bir ya da iki yılda bir yükselen bir sistem için kurulmamıştı.
SAP, Clean Core'u beş yol gösterici ilke etrafında düzenliyor. Bu yazının önceki sürümünde farklı başlıklar vardı. SAP'nin kullandığı başlıklar bunlar; her birinde önce neye baktığımı da ekledim:
| İlke | SAP'nin kastettiği | Önce neye bakıyorum |
|---|---|---|
| Süreçler | SAP standart sürecine mümkün olduğunca yakın kalmak | “Hep böyle yapardık” dendiği için var olan hangi süreç varyantları |
| Genişletilebilirlik | Uzantılar yayımlanmış API'ler üzerinden çekirdekten ayrıştırılır; hangi seçeneğin kullanılacağı üzerinde yönetişim vardır | Ne kadar özel kod var, ne kadarı kullanılıyor ve hangi seviyede duruyor |
| Veri | Yerleşik bir yönetişim modeliyle temiz, uyumlu veri | Mükerrer ve eksik ana veri, kimsenin açıklayamadığı özel alanlar |
| Entegrasyonlar | Desteklenen teknolojiler üzerine kurulu standartlaştırılmış, güvenli bağlantılar | Tabloları doğrudan okuyan noktadan noktaya arayüzler |
| Operasyonlar | Diğer dördünü yerinde tutan yönetişim, insanlar, süreçler ve araçlar | Bir uzantıyı kim onaylıyor ve bir sonraki modifikasyonu ne durduruyor |
Çoğu ekip genişletilebilirlikle başlar ve onunla biter, çünkü ölçmesi en kolay olan odur. Deneyimime göre süreçler ve veri daha fazla gecikmeye yol açar. Özel kod genellikle belirtidir. Nedeni arkasındaki süreçtir.
Ağustos 2025'te SAP, önceki üç katmanlı genişletilebilirlik modelinin yerine Clean Core seviye kavramını getirdi. Her uzantı, nasıl kurulduğuna, çekirdekten ne kadar ayrıştırıldığına ve ne kadar kolay yükseltilebildiğine göre değerlendiriliyor.
| Seviye | SAP'nin tanımı | Yükseltmeniz için anlamı |
|---|---|---|
| A | SAP Build ile genişletin. Yalnızca herkese açık, yayımlanmış kararlı arayüzler; ABAP Cloud ile on-stack ya da BTP üzerinde side-by-side | En düşük risk. SAP bu arayüzleri kararlılık sözleşmeleriyle destekliyor |
| B | SAP'nin klasik API'lerini ve teknolojilerini de kullanır | Genellikle yükseltmede kararlı, ancak bulut geliştirme modelinin dışında |
| C | SAP iç nesnelerine erişir | Kısmen uyumlu. Her yükseltmede kontrol gerekir; SAP iç nesneler için bir değişiklik günlüğü planlıyor |
| D | Önerilmez: modifikasyonlar, SAP tablolarına yazma, örtük geliştirmeler, açıkça önerilmeyen nesneler | İlk temizlenmesi gereken teknik borç |
Bu, eski “temiz mi değil mi” tartışmasından daha işe yarar. Nesne başına hedef koymanızı sağlar. Her şeyin A seviyesine ulaşması gerekmez. D seviyesindeki nesnelerinizi bir yükseltmeden önce B ya da C'ye taşımak bile riskte gerçek bir azalmadır.
Kaynak: SAP Clean Core seviye kavramı, SAP News, Ağustos 2025
Önümüzdeki ay sisteminizi değerlendirmemi isteseydiniz, şu sırayı izlerdim.
- Neyin kullanıldığını bulun. Bakım sözleşmenizle birlikte gelen SAP Readiness Check'i çalıştırın ve özel kodunuzla ilgili kullanım verilerini toplayın. Bir programda smartShift ile yaptığımız analiz bizi 18.000 özel nesneden 3.200'e indirdi. Geri kalanın çoğu zaten kullanılmıyordu.
- Kalanı A'dan D'ye seviyelere sınıflandırın. ABAP test cockpit, SAP'nin kod düzeyindeki kontroller için aracıdır. RISE kapsamında RISE with SAP Methodology panosu Clean Core benimsenmesini raporlar.
- Nesne nesne karar verin. Kaldırın, yayımlanmış bir arayüze taşıyın, BTP üzerinde yeniden kurun ya da belgelenmiş bir gerekçeyle tutun. Her gün çalışan kodla başlayın. Tek bir bölge ekibinin yılda iki kez kullandığı bir rapor bekleyebilir.
- İş tarafını odaya alın. Birlikte çalıştığım bir finans yöneticisi yeni Fiori uygulamasını ancak 45 dakikalık bir tanıtımdan sonra anladı. O oturum UAT'de iki haftalık gidip gelmeyi önledi.
- “Bizim sürecimiz farklı” savını sorgulayın. Bir satış ekibi çalıştayında “benzersiz” süreç, yüzde 80 oranında gereksiz eski idari iş çıktı. Geçici çözümler gidince standart SAP müşteri deneyimlerini iyileştirdi.
- Veri çalışmasına erken başlayın. Bir perakende müşterisinin ayıklaması gereken 15.000'den fazla özel alan vardı. Deneyimime göre veri taşıma, implementasyon çabasının yüzde 30 ila 40'ını alır ve çoğu planın en çok hafife aldığı kısımdır. Nedenini SAP veri taşımanın neden başarısız olduğunu anlatan yazımda açıklıyorum.
- Yönetişimi canlıya geçişten önce kurun. Her yeni uzantıyı bir tasarım otoritesi gözden geçirmeli. Varsayılan soru eskiden “bu neden BTP'de duramaz?” idi. Bugün “bu neden A seviyesi olamaz, olamıyorsa hangi seviyeyi, neden kabul ediyoruz?” diye sorardım.
Beceriler araçlar kadar önemli. ABAP Cloud ya da BTP ile çalışmamış bir ABAP ekibi, öğrenirken programı yavaşlatır. Birlikte çalıştığım bir üretici, S/4HANA projesi başlamadan önce üç aylık bir kurum içi BTP programı yürüttü ve bu, geliştirme aşamasında daha az sürprizle karşılığını verdi.
Clean Core'u atlayan ekipler işten kaçmış olmaz. İşi ertelerler ve iş, engellenen yükseltmeler ile kimsenin anlamadığı özel kod olarak geri gelir.
Bu konuda yaptığım hemen her görüşmede üç soru çıkıyor.
RISE with SAP kapsamında Clean Core zorunlu mu? Genel bir kural olarak hayır. S/4HANA Cloud Public Edition'da yalnızca yayımlanmış arayüzler üzerinden genişletebilirsiniz, yani sistem bunu zorunlu kılıyor. Private Edition ve on-premise'de çekirdeği hâlâ değiştirebilirsiniz. Orada Clean Core bir yönetişim tercihidir ve SAP bunu RISE metodoloji panosu üzerinden izler. Bir sistem entegratörü size bunun sözleşmeden kaynaklandığını söylüyorsa, maddeyi göstermesini isteyin.
ECC'de ne kadar vaktim var? EHP 6 ila 8 üzerindeki SAP ERP 6.0 için standart bakım 31 Aralık 2027'de sona eriyor. İsteğe bağlı uzatılmış bakım ek ücretle 31 Aralık 2030'a kadar sürüyor ve SAP müşterilerden bunu 2027'nin 3. çeyreğine kadar sipariş etmelerini istiyor. Daha eski geliştirme paketlerinde standart bakım 2025 sonunda bitti. 2030'dan sonra SAP ERP, private edition, geçiş seçeneği 2031 ile 2033 arasını kapsıyor. Bu seçenek yalnızca 2030 sonundan önce SAP HANA üzerinde SAP ERP, private edition'a taşınmış büyük sistemler için geçerli ve yalnızca SAP'nin max success planıyla. 2033'ü bir planlama tarihi olarak değil, bir istisna rotası olarak görün. ECC'den S/4HANA'ya geçiş rehberim rota seçeneklerini ele alıyor.
Clean Core yapay zeka için önemli mi? SAP, Joule dahil yapay zeka özelliklerini standart süreçlerinin ve veri modelinin üzerine kuruyor. Geliştiriciler için Joule, yayımlanmış API'lere karşı ABAP Cloud kodu üretiyor. Benim çalışma görüşüm basit: süreçleriniz ve verileriniz standarda ne kadar yakınsa, bu özellikler işinize yarayabilmeden önce o kadar az uyarlama gerekir. Yoğun biçimde modifiye edilmiş süreçler, yapay zeka özelliklerinin benimsenmesinin en zor olduğu yerlerdir.
Clean Core'u atlayan ekipler işten kaçmış olmaz. İşi ertelerler ve iş, engellenen yükseltmeler, regresyon testi maratonları ve kimsenin anlamadığı özel kod olarak geri gelir.
Bir S/4HANA ya da RISE sözleşmesi imzalamak üzereyseniz, kapsamı kararlaştırmadan önce sistem entegratörünüzden mevcut özel kodunuzun A'dan D'ye seviye sınıflandırmasını isteyin. Üretemiyorlarsa, bu size tahmin hakkında bir şey söyler. Geçiş seçeneklerinizi ECC'den S/4HANA'ya geçiş değerlendirmemle sınayabilirsiniz ya da görüşme planlayın, durumunuza birlikte bakalım.
SAP Clean Core nedir?
Clean Core, S/4HANA'yı SAP standardına yakın tutmak ve uzantıları yalnızca SAP'nin yayımladığı ve kararlı tutmayı taahhüt ettiği arayüzler üzerinden kurmak demektir. Uzantılar ya ABAP Cloud ile on-stack ya da SAP BTP üzerinde side-by-side çalışır. Amaç, yükseltmelerin özel mantığınızı bozmamasıdır.
SAP Clean Core'un beş boyutu nedir?
SAP bunlara Clean Core'un beş yol gösterici ilkesi diyor: süreçler, genişletilebilirlik, veri, entegrasyonlar ve operasyonlar. Süreçler standarda yakın kalır. Uzantılar yayımlanmış API'leri kullanır. Veri bir yönetişim modeliyle temiz tutulur. Entegrasyonlar standartlaştırılmış, desteklenen teknolojileri kullanır. Operasyonlar, diğer dördünü yerinde tutan yönetişimi, insanları ve araçları kapsar.
SAP Clean Core A, B, C ve D seviyeleri nelerdir?
SAP, Ağustos 2025'ten beri uzantıları dört seviyede sınıflandırıyor. A seviyesi yalnızca herkese açık, yayımlanmış kararlı arayüzleri kullanır. B seviyesi klasik SAP API'lerini de kullanır. C seviyesi SAP iç nesnelerine erişir ve her yükseltmede kontrol gerektirir. D seviyesi modifikasyonları, SAP tablolarına yazmayı, örtük geliştirmeleri ve önerilmeyen diğer teknikleri kapsar ve en yüksek riski taşır.
RISE with SAP ile Clean Core zorunlu mu?
Genel bir kural olarak hayır. S/4HANA Cloud Public Edition uzantılara yalnızca yayımlanmış arayüzler üzerinden izin verir, yani Clean Core'u teknik olarak zorunlu kılar. Private Edition'da çekirdeği hâlâ değiştirebilirsiniz, dolayısıyla Clean Core bir yönetişim kararıdır. SAP, Clean Core benimsenmesini RISE with SAP Methodology panosu üzerinden raporlar.
SAP ECC desteği ne zaman sona eriyor?
EHP 6 ila 8 üzerindeki SAP ERP 6.0 için standart bakım 31 Aralık 2027'de sona eriyor; isteğe bağlı uzatılmış bakım ek ücretle 31 Aralık 2030'a kadar sürüyor. Daha eski geliştirme paketlerinde standart bakım 2025 sonunda bitti. SAP ERP, private edition, geçiş seçeneği 2033'e kadar uzanıyor, ancak yalnızca 2030 sonundan önce SAP HANA üzerinde SAP ERP, private edition'a taşınmış uygun büyük sistemler için.
SAP sistemimin Clean Core hazırlığını nasıl değerlendiririm?
SAP Readiness Check ve özel kodunuzun kullanım verileriyle başlayın. Hâlâ kullanılanı A'dan D'ye seviyelere sınıflandırın; kod düzeyindeki kontroller için ABAP test cockpit'i kullanın. Ardından nesne bazında kaldırmaya, yayımlanmış bir arayüze taşımaya, SAP BTP üzerinde yeniden kurmaya ya da belgelenmiş bir gerekçeyle tutmaya karar verin. Süreçleri ve veriyi aynı anda gözden geçirin, çünkü kodun neden var olduğunu genellikle onlar açıklar.
Clean Core stratejisinde SAP BTP'nin rolü nedir?
SAP BTP, side-by-side uzantıların çalıştığı yerdir. BTP üzerindeki uygulamalar S/4HANA'ya API'ler ve olaylar üzerinden bağlanır, böylece çekirdeğe dokunulmaz. SAP önce BTP yaklaşımını öneriyor; mantığın veriye ya da işleme yakın durması gerektiğinde ise ABAP Cloud ile on-stack uzantılar kullanılıyor.
Sonraki adım
Şu anda bir ERP programı mı yürütüyorsunuz?
Bu makale şu anda içinde olduğunuz bir programa dokunduysa, 30 dakikalık bir görüşme genellikle bir hafta daha süren iç analizden daha fazla yol aldırır.




