SAP Clean Core: ne anlama gelir, A'dan D'ye seviyeler ve yönetişim

SAP Clean Core, S/4HANA sisteminizi işinizin izin verdiği ölçüde SAP standardına yakın tutmak demektir. Eklediğiniz her şey, SAP'nin yayımladığı ve kararlı tutmayı taahhüt ettiği arayüzler üzerinden geliştirilir; böylece yükseltmeler onu bozmaz.

Kısa cevap: Clean Core, SAP'yi nasıl genişlettiğinize ve yönettiğinize dair bir disiplindir. Özel mantık ABAP Cloud ile on-stack ya da SAP BTP'de side-by-side çalışır ve SAP her uzantıyı A seviyesinden (en temiz) D seviyesine (kaldırılması gereken modifikasyonlar) kadar derecelendirir. Kazanç daha hızlı yükseltmelerdir: Bu yolla yükseltme sürelerini %40 kısaltan şirketler gördüm.

Sisteminiz SAP standart nesnelerindeki 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ıma dönüşür.

Clean Core ilkelerini uygulayarak yükseltme sürelerini %40 kısaltan şirketler gördüm. Bunu, özelleştirmeleri asgaride tutarak ve korudukları özelleştirmeleri iyi yöneterek başardılar.

2024'te Avrupalı bir tüketim malları şirketi, eski fiyatlandırma mantığını çekirdeğin dışında, SAP BTP üzerinde geliştirilmiş modüler bir Fiori uygulamasıyla değiştirdi. Bu, o mantık için regresyon testini tamamen ortadan kaldırdı.

Clean Core bir ERP'yi yine de özelleştirebilirsiniz. Ancak özelleştirmenin, SAP'nin yayımladığı ve kararlı tutmayı taahhüt ettiği arayüzleri kullanması gerekir. SAP bunun için iki yol sunar:

• On-stack, ABAP Cloud ile. Uzantılar S/4HANA'nın içinde çalışır ama yalnızca yayımlanmış API'leri ve genişletme noktalarını kullanır.
• Side-by-side, SAP BTP'de. Uzantılar ayrı uygulamalar olarak çalışır ve S/4HANA ile API'ler ya da olaylar aracılığıyla konuşur.

SAP yaklaşımını, her kullanım senaryosuna göre seçim yapan BTP-first olarak tanımlıyor. Benim deneyimime göre kodun nerede çalıştığı, gereksinimin hiç kod gerektirip gerektirmediğinden daha az önemlidir.

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ılarını okuyan arayüzler, kimsenin belgelemediği örtük genişletmeler. Bunların hiçbiri yapıldığı dönemde yanlış değildi. Sadece her bir ya da iki yılda bir yükseltilen bir sistem için yapılmamışlardı.

Bu konuyu YouTube kanalımdaki bir videoda da ele alıyorum (İngilizce).

SAP, Clean Core'u beş yol gösterici ilke etrafında düzenler. SAP her birini şöyle çerçeveliyor, ben de ilk olarak şunlara bakıyorum:

İlke	SAP'nin kastettiği	İlk kontrol ettiğim şey
Süreçler	SAP standart sürecine mümkün olduğunca yakın kalmak	Hangi süreç varyantlarının yalnızca "hep böyle yaptık" diye var olduğu
Genişletilebilirlik	Yayımlanmış API'ler aracılığıyla çekirdekten ayrıştırılmış, hangi seçeneğin kullanıldığı yönetişime tabi uzantılar	Ne kadar özel kod olduğu, bunun ne kadarının kullanıldığı ve hangi seviyede durduğu
Veri	Yerleşik bir yönetişim modeliyle temiz ve uyumlu veri	Mükerrer ve eksik ana veriler, kimsenin açıklayamadığı özel alanlar
Entegrasyonlar	Desteklenen teknolojiler üzerine kurulu, standartlaştırılmış ve 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ı kimin onayladığı ve bir sonraki modifikasyonu neyin durduracağı

Ekiplerin çoğu genişletilebilirlikle başlar ve onunla bitirir, çünkü ölçmesi en kolay olan odur. Benim deneyimime göre süreçler ve veri daha fazla gecikmeye yol açar. Özel kod genellikle belirtidir, arkasındaki süreç ise nedendir.

Ağustos 2025'te SAP, önceki üç katmanlı genişletilebilirlik modelinin yerine Clean Core seviye konseptini getirdi. Her uzantı; nasıl geliştirildiğine, çekirdekten ne kadar ayrıştırıldığına ve bir yükseltmeden ne kadar güvenle çıktığına göre değerlendirilir. Katmanlardan (tier) söz eden eski SAP materyallerini okuyorsanız, onların yerini alan budur.

A seviyesiB seviyesiC seviyesiD seviyesi

Ne kullanırA seviyesiYalnızca herkese açık yayımlanmış, kararlı arayüzlerB seviyesiSAP'nin klasik API'leri deC seviyesiSAP iç nesneleriD seviyesiModifikasyonlar, SAP tablolarına yazma, örtük genişletmeler

Yükseltme riskiA seviyesiEn düşük, kararlılık sözleşmeleriyle güvence altındaB seviyesiGenellikle yükseltmeye dayanıklıC seviyesiHer yükseltmede kontrol gerektirirD seviyesiEn yüksek

Ne karar verilmeliA seviyesiYeni her şey için varsayılanB seviyesiGerekçesi kayda geçirilerek kabul edilirC seviyesiGerekçeyle kabul edilir, her yükseltmede yeniden kontrol edilirD seviyesiÖnce kaldırılır ya da B veya C'ye taşınır

Kaynak: SAP Clean Core seviye konsepti, SAP News, Ağustos 2025

A seviyesi yalnızca kararlılık sözleşmeleri olan, herkese açık yayımlanmış arayüzleri kullanır ve SAP Build, ABAP Cloud ya da BTP ile geliştirilir. B seviyesi buna SAP'nin klasik API'lerini ekler. C seviyesi SAP iç nesnelerine dokunur ve SAP, yükseltme planlamasına yardımcı olmak için bunlara yönelik bir değişiklik günlüğü planlıyor.

D seviyesi modifikasyonlar, SAP tablolarına yazma, örtük genişletmeler ve SAP'nin önermediği diğer tekniklerdir. Bu, eski "temiz mi değil mi" tartışmasından daha kullanışlıdır, çünkü her nesne için bir hedef belirlemenize olanak tanır. D seviyesindeki nesnelerinizi bir yükseltmeden önce B'ye ya da C'ye taşımak, riskte zaten gerçek bir azalmadır.

ABAP Cloud, SAP'nin buluta hazır ABAP geliştirme modelidir. Geliştiriciler "ABAP for Cloud Development" dil sürümünü kullanır ve yalnızca yayımlanmış nesneler, genel API'ler ve genişletme noktaları üzerine geliştirme yapabilir. SAP BTP ABAP ortamında başladı ve artık her S/4HANA sürümünde mevcut (SAP ABAP Cloud SSS).

S/4HANA Cloud size üç genişletme yolu sunar. Anahtar kullanıcı genişletilebilirliği, SAP koduna dokunmadan basit alan, mantık ve kullanıcı arayüzü değişikliklerini kapsar. ABAP Cloud ile geliştirici genişletilebilirliği sıkı bağlı mantığı ele alır, SAP BTP'deki side-by-side uzantılar ise ayrık kalması gereken her şeyi üstlenir.

Ne kadar seçeneğiniz olduğunu sürüm belirler:

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition ve on-premise
ABAP geliştirme	Yalnızca ABAP Cloud, 2208 sürümünden bu yana yeni müşteriler için zorunlu	2022'den bu yana ABAP Cloud öneriliyor; klasik ABAP'a hâlâ izin veriliyor
SAP kodunda değişiklik	Mümkün değil	Mümkün, ama D seviyesindedir
Anahtar kullanıcı ve BTP side-by-side uzantıları	Mevcut	Mevcut
Clean Core'u kim zorunlu kılar	Sistem	Sizin yönetişiminiz

Private Edition müşterileri için kuralım şu: Yeni olan her şey için onu Public Edition'mış gibi ele alın. Klasik ABAP'a izin veriliyor, ama bugün eklediğiniz her klasik nesne, birinin bir sonraki yükseltmede savunmak zorunda kalacağı bir karardır.

Clean Core kararlarının sahibi, iş birimleri ve BT'den oluşan bir tasarım otoritesi olmalıdır. BT tek başına teknik olarak mümkün olan her şeyi onaylar. İş birimleri tek başına eski süreçlerini geri ister.

Ben bunu şöyle kurardım:

1. Üyeleri belirleyin. Her ana alan için iş süreci sahipleri, artı çözüm mimarı ve baş geliştirici. İş tarafındaki sahipler bir gereksinimin gerçek olup olmadığına, BT ise nasıl geliştirileceğine karar verir.
2. Geliştirme başlamadan önce tercih sırasında anlaşın. Önce standart süreç, sonra anahtar kullanıcı genişletilebilirliği, sonra ABAP Cloud ya da BTP üzerinde A seviyesi. B ya da C seviyesi yazılı bir gerekçe, D seviyesi ise bir çıkış planı gerektirir.
3. Her uzantı talebinin bir sahibi ve bir iş gerekçesi olsun. Sahip yoksa geliştirme de yok. Karar ve kabul edilen seviye tek bir kayda girer.
4. Transportların önüne teknik bir kapı koyun. ABAP test cockpit'in Clean Core kontrollerini planlı olarak çalıştırın ve yeni D seviyesi kodu canlı sisteme ulaşmadan durdurun.
5. Her yükseltmeden önce kaydı gözden geçirin. Artık kimsenin kullanmadığını emekliye ayırın ve şimdi daha yüksek bir seviyeye çıkabilecek her şeyi taşıyın.

O masada eskiden sorulan soru "bu neden BTP'de duramıyor?" idi. Bugün "bu neden A seviyesi olamıyor?" diye sorardım. Olamıyorsa, sıradaki soru hangi seviyeyi neden kabul ettiğinizdir.

Gördüğüm en büyük Clean Core hatası, SAP'yi Oracle gibi çalıştırmaya çalışmaktır. Başka bir sistemin mantığını özel kodla yeniden kurmak yerine SAP'nin standart süreçlerini benimseyin. Hâlâ ikisi arasında seçim yapıyorsanız, onları SAP ve Oracle karşılaştırmamda ele alıyorum.

Clean Core teknik bir sorun olmadan önce bir değişim yönetimi sorunudur. Her özel nesne, biri istediği için vardır. Onu kaldırmak, o kişiyi standart sürecin yeterince iyi olduğuna ikna etmek demektir.

Bu konuşma, iş tarafı yeni süreci onun hakkındaki bir slaytta değil, çalışırken gördüğünde daha iyi geçer. Bir sürecin benzersiz olduğu iddiasını test ettiğinizde de daha iyi geçer, çünkü çoğu zaman öyle değildir (aşağıdaki 4. ve 5. adımlara bakın).

Beceriler de araçlar kadar önemlidir. 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 iç BTP programı yürüttü ve bu, geliştirme sırasında daha az sürprizle karşılığını verdi.

Clean Core uyumu, sisteminizin beş ilke genelinde SAP'nin kriterlerini ne ölçüde karşıladığıdır. Rakamlar olmadan onu yönetemezsiniz ve SAP bu rakamları alabileceğiniz üç yer sunar.

1. ABAP test cockpit. SAP'nin kod düzeyindeki kontroller için aracı. Hangi özel nesnelerin yayımlanmamış nesneler, modifikasyonlar ya da doğrudan tablo erişimi kullandığını gösterir.
2. SAP Readiness Check. Bakım sözleşmenizle birlikte gelir ve bir S/4HANA geçişinin neyi etkileyeceğini, siz taahhütte bulunmadan önce gösterir.
3. Clean Core panosu olarak da bilinen RISE with SAP Methodology panosu. SAP Cloud ALM içinde çalışır. Sistem görünümü S/4HANA sürümünüzü kontrol eder, veri toplama araçlarının etkin olduğunu doğrular ve bir yükseltme öncesinde uzantıları gözden geçirir; operasyon görünümü ise operasyonel KPI'ları izler.

Her ay tasarım otoritesinin önüne koyacağım rakamlar basittir. Her seviyede kaç özel nesne var ve D seviyesi düşüyor mu? Kaç istisna açık ve her birinin bir sahibi var mı?

Sisteminizi önümüzdeki ay değerlendirmemi isteseydiniz, izleyeceğim sıra şu olurdu.

1. Neyin kullanıldığını öğrenin. SAP Readiness Check'i çalıştırın ve özel kodunuzla ilgili kullanım verilerini toplayın. Bir programda smartShift ile yapılan analiz bizi 18.000 özel nesneden 3.200'e indirdi, çünkü geri kalanın çoğu basitçe kullanılmıyordu.
2. Kalanları A'dan D'ye seviyelere ayırın. Kod için ABAP test cockpit'i kullanın. RISE kullanıyorsanız, oradan sonrasını Clean Core panosu izler.
3. Nesne nesne karar verin. Emekliye ayırın, yayımlanmış bir arayüze taşıyın, BTP'de yeniden geliştirin ya da belgelenmiş bir gerekçeyle tutun. Her gün çalışan kodla başlayın, çünkü tek bir bölgesel ekibin yılda iki kez kullandığı bir rapor bekleyebilir.
4. İş tarafını odaya alın. Birlikte çalıştığım bir finans lideri, yeni Fiori uygulamasını ancak 45 dakikalık bir uygulamalı tanıtımdan sonra anladı. O oturum, UAT'de iki haftalık gidip gelmeyi önledi.
5. "Bizim sürecimiz farklı" iddiasını sorgulayın. 2023'te Avrupalı bir sanayi şirketinin satış ekibiyle yaptığımız bir atölyede, "benzersiz" sürecin %80'inin gereksiz eski idari iş olduğu ortaya çıktı. Geçici çözümler kalktığında standart SAP, müşteri deneyimlerini iyileştirdi.
6. Veri çalışmasına erken başlayın. 2024'te birlikte çalıştığım GCC'deki bir perakende müşterisinin elden geçirmesi gereken 15.000'den fazla özel alanı vardı. Benim deneyimime göre veri taşıma, uygulama eforunun %30 ila %40'ını alır ve SAP uygulama maliyeti rehberim bunun bütçede nereye düştüğünü gösterir.
7. Yönetişimi canlıya geçişten önce kurun. Yukarıda anlatılan tasarım otoritesini oluşturun ve onu yeni bir uzantı için tek yol yapın.

Bu konuda yaptığım hemen her konuşmada üç soru gündeme gelir.

RISE with SAP kapsamında Clean Core zorunlu mu?

Genel bir kural olarak değil. Public Edition'da bunu sistem zorunlu kılar, Private Edition'da ve on-premise'de ise çekirdeği hâlâ değiştirebilirsiniz.

Orada Clean Core, SAP'nin RISE metodolojisi panosu üzerinden izlediği bir yönetişim tercihidir. Bir SI size bunun sözleşmeden kaynaklandığını söylüyorsa, ilgili maddeyi göstermesini isteyin.

ECC'de ne kadar zamanım var?

Enhancement package 6 ila 8 üzerindeki SAP ERP 6.0 için ana bakım 31 Aralık 2027'de sona eriyor. İsteğe bağlı genişletilmiş bakım, ek ücret karşılığında 31 Aralık 2030'a kadar sürüyor.

Bundan 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.

2033'ü bir planlama tarihi olarak değil, bir istisna yolu olarak görün. ECC'den S/4HANA'ya geçiş rehberim yol seçeneklerini ele alıyor.

Clean Core yapay zeka için önemli mi?

Evet. SAP'yi standart tutmak yapay zekanın ve Joule'un daha iyi çalışmasına yardımcı olur; yoğun şekilde değiştirilmiş süreçler ise onları benimsemenin en zor olduğu yerlerdir.

SAP, Joule dahil yapay zeka özelliklerini kendi standart süreçleri ve veri modeli üzerine kuruyor. Geliştiriciler için Joule, yayımlanmış API'lere dayalı ABAP Cloud kodu üretiyor. Bulut, yapay zeka ve Clean Core'un nasıl bir araya geldiğini ERP modernizasyonu yazımda ele alıyorum.

Clean Core'u atlayan ekipler işten kaçmış olmaz. Sadece onu erteler ve iş, engellenmiş yükseltmeler, regresyon testi maratonları ve kimsenin anlamadığı özel kod olarak geri döner.

Bir S/4HANA ya da RISE sözleşmesi imzalamadan önce SI'nızdan mevcut özel kodunuzu A'dan D'ye seviyelere ayırmasını isteyin. Bunu ortaya koyamıyorsa, bu size tahmin hakkında bir şey söyler. Bir görüşme planlayın, durumunuza birlikte bakalım.

SAP'de 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 geliştirmek demektir. Uzantılar ya ABAP Cloud ile on-stack ya da SAP BTP'de side-by-side çalışır. Amaç, yükseltmelerin özel mantığınızı bozmamasıdır.

SAP Clean Core'un beş ilkesi nelerdir?

SAP'nin beş yol gösterici Clean Core ilkesi süreçler, genişletilebilirlik, veri, entegrasyonlar ve operasyonlardır. Süreçler standarda yakın kalır, uzantılar yayımlanmış API'leri kullanır ve veri bir yönetişim modeli altında temiz tutulur. Entegrasyonlar desteklenen teknolojileri kullanır, operasyonlar ise 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 bu yana 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 ve C seviyesi SAP iç nesnelerine erişir. D seviyesi modifikasyonları, SAP tablolarına yazmayı ve örtük genişletmeleri kapsar ve en yüksek yükseltme riskini taşır.

RISE with SAP için Clean Core zorunlu mu?

Genel bir kural olarak değil. S/4HANA Cloud Public Edition yalnızca ABAP Cloud'a ve yayımlanmış arayüzlere izin verir, dolayısıyla Clean Core'u teknik olarak zorunlu kılar. Private Edition'da çekirdeği hâlâ değiştirebilirsiniz; bu nedenle Clean Core, SAP'nin RISE with SAP Methodology panosu üzerinden izlediği bir yönetişim kararıdır.

ABAP Cloud nedir?

ABAP Cloud, SAP'nin buluta hazır ABAP geliştirme modelidir. Yalnızca yayımlanmış nesnelere, genel API'lere ve genişletme noktalarına izin verir; bu da özel kodu yükseltmelere dayanıklı tutar. 2208 sürümünden bu yana yeni müşteriler için S/4HANA Cloud Public Edition'da zorunludur, 2022'den bu yana da Private Edition'da ve on-premise'de önerilmektedir.

Clean Core nasıl ölçülür?

Kod düzeyindeki kontroller için ABAP test cockpit'i kullanın ve özel nesneleri A'dan D'ye seviyelere ayırın. RISE müşterileri benimsemeyi SAP Cloud ALM'deki, Clean Core panosu olarak da adlandırılan RISE with SAP Methodology panosunda izleyebilir. Ben her seviyedeki nesne sayısını, D seviyesindeki eğilimi ve sahibi olan açık istisnaların sayısını izliyorum.

SAP Clean Core yönetişiminin sahibi kim olmalı?

Her Clean Core kararının sahibi, iş birimleri ve BT'den oluşan bir tasarım otoritesi olmalıdır. İş süreci sahipleri bir gereksinimin gerçek olup olmadığına, BT ise nasıl ve hangi seviyede geliştirileceğine karar verir. Her istisna bir sahiple birlikte kayda alınır ve her yükseltmeden önce gözden geçirilir.

SAP ECC desteği ne zaman sona eriyor?

Enhancement package 6 ila 8 üzerindeki SAP ERP 6.0 için ana bakım 31 Aralık 2027'de sona eriyor; isteğe bağlı genişletilmiş bakım ise ek ücret karşılığında 31 Aralık 2030'a kadar sürüyor. SAP ERP, private edition geçiş seçeneği, yalnızca 2030 sonundan önce SAP HANA üzerinde SAP ERP, private edition'a taşınmış uygun büyük sistemler için 2033'e kadar geçerli.