Setiap diskusi migrasi ke SAP S/4HANA cepat atau lambat sampai pada satu istilah yang sering diucapkan konsultan tapi jarang benar-benar dipahami orang yang harus menyetujui anggarannya: clean core. CIO dan pemimpin transformasi mengangguk saat istilah ini lewat, lalu diam-diam bertanya dalam hati. Apa sebenarnya yang dimaksud, kenapa SAP mendorongnya justru sekarang, dan apa konsekuensinya kalau diabaikan? Artikel ini bukan tutorial untuk developer ABAP. Ini penjelasan tingkat keputusan: apa untungnya inti sistem yang bersih bagi kecepatan upgrade, biaya migrasi, dan kesiapan SAP clean core menuju cloud.
Ringkas: Clean core adalah prinsip menjaga inti (digital core) sistem SAP S/4HANA tetap standar dan mudah di-upgrade dengan memindahkan kustomisasi ke luar inti, umumnya ke SAP BTP (Business Technology Platform) lewat side-by-side extensibility dan released API, alih-alih memodifikasi sistem standar. Tujuannya: upgrade lebih cepat dan murah, serta sistem yang siap pindah ke cloud.
Apa itu clean core SAP dan mengapa konsep ini muncul sekarang?
Mari mulai dari kesalahpahaman yang paling mahal: clean core bukan produk yang Anda beli, dan bukan berarti “tidak boleh ada kustomisasi”. Clean core adalah prinsip arsitektur. Intinya satu kalimat: jaga jantung sistem SAP S/4HANA, yakni objek dan kode standarnya, tetap utuh, dan letakkan semua penyesuaian khusus perusahaan Anda di luar inti itu.
Analoginya seperti rumah kontrak. Kalau Anda membongkar tembok struktural demi memasang dapur impian, dapur itu ikut ambruk setiap kali pemilik merenovasi instalasi. Tapi jika dapur dipasang sebagai unit terpisah yang hanya tersambung lewat colokan dan pipa standar, pemilik bisa merenovasi kapan saja tanpa merusaknya. Begitu pula inti SAP yang standar: bisa di-upgrade berkala, sementara kustomisasi Anda yang terisolasi di luar tetap aman.
Kenapa baru ramai sekarang? Karena di era on-premise klasik, memodifikasi sistem standar adalah praktik yang lumrah, bahkan dibanggakan. Begitu SAP mengarahkan seluruh ekosistemnya ke S/4HANA Cloud, tempat SAP yang memegang kendali upgrade, modifikasi inti gaya lama berubah dari “fleksibilitas” menjadi beban. Dua entitas perlu dikenali sejak awal karena akan terus muncul: SAP S/4HANA adalah ERP generasi terbaru SAP, yakni “inti digital” yang kita jaga tetap bersih; SAP BTP (Business Technology Platform) adalah platform pengembangan dan integrasi terpisah di luar inti itu, tempat kustomisasi clean-core “tinggal”.
Lebih dari sekadar “jangan utak-atik kode”: dimensi dan kontras intinya
Menyempitkan clean core menjadi “jangan mengubah kode standar” memang benar, tapi tidak lengkap. Dalam panduan SAP terkini, clean core umumnya dijelaskan dalam beberapa dimensi, bukan hanya soal software. Jumlahnya sering disebut sekitar enam, meski penamaan persisnya pernah bergeser antar versi materi SAP, jadi anggap daftar berikut sebagai gambaran arah, bukan teks resmi yang final:
- Software: inti S/4HANA tidak dimodifikasi; tidak ada perubahan invasif pada objek standar.
- Ekstensi (extensions): semua penambahan fungsi dibangun dengan cara yang upgrade-safe (aman saat di-upgrade), lewat in-app atau side-by-side.
- Integrasi (integrations): sistem disambungkan ke aplikasi lain lewat antarmuka stabil (released API), bukan koneksi rapuh ke objek internal.
- Data: kualitas dan tata kelola data dijaga; data master bersih dan konsisten.
- Proses: perusahaan mendekati proses standar SAP semaksimal mungkin sebelum menyesuaikan.
- Operasi dan tata kelola: ada aturan main agar tim tidak diam-diam “mengotori” inti lagi setelah dibersihkan.
Yang paling penting bagi eksekutif bukan menghafal keenamnya, melainkan kontras mendasar antara cara lama dan cara clean core. Tabel berikut adalah inti keputusan yang sebenarnya:
| Aspek | Modifikasi inti (cara lama) | Ekstensi di luar inti (clean core) |
|---|---|---|
| Pendekatan | Mengubah/menimpa objek dan kode standar SAP di dalam inti | Menambah fungsi lewat in-app (released) atau side-by-side di SAP BTP, tersambung via released API |
| Contoh | Modifikasi program/tabel standar, user-exit invasif, kode “Z” yang menyentuh objek inti | Custom field/logika via key-user tools; aplikasi/integrasi di SAP BTP; ABAP Cloud (released-only) |
| Saat upgrade | Berisiko patah; butuh adaptasi dan regression testing besar tiap kali | Tetap upgrade-safe; inti bisa di-upgrade tanpa merusak ekstensi |
| Dampak biaya | Technical debt menumpuk; biaya dan waktu upgrade membengkak | Biaya pemeliharaan lebih rendah; inovasi SAP lebih cepat diadopsi |
| Kesiapan cloud | Sulit/mahal; tidak kompatibel dengan S/4HANA Cloud public | Siap cloud; selaras dengan public/private dan jalur RISE/GROW |
Baris “kesiapan cloud” adalah tempat semua konsekuensi itu bertemu, sekaligus alasan clean core menjadi pembicaraan dewan direksi, bukan sekadar urusan tim teknis.
Bagaimana cara menjaga core tetap bersih? In-app vs side-by-side extensibility
Pertanyaan praktis yang selalu menyusul: kalau inti tidak boleh disentuh, di mana kustomisasi diletakkan? SAP menawarkan beberapa jalur, dan tiga di antaranya cukup dipahami pengambil keputusan pada tataran apa dan kapan:
- In-app extensibility (sering disebut key-user extensibility) memperluas S/4HANA dari dalam, misalnya menambah custom field atau logika ringan lewat extension point yang sudah di-released (disetujui dan dijamin stabil) oleh SAP. Bisa dikerjakan key user atau analis bisnis tanpa menyentuh kode standar. Cocok untuk kebutuhan kecil dan spesifik per modul.
- Side-by-side extensibility membangun ekstensi sebagai aplikasi terpisah di SAP BTP, lalu menyambungkannya ke inti lewat released/public API. Karena hidup di luar inti, aplikasi serumit apa pun tidak mengotori core. Inilah pilihan untuk logika bisnis besar, UX kustom, atau integrasi lintas sistem.
- ABAP Cloud bukan produk terpisah, melainkan model pengembangan ABAP yang ter-governance dan upgrade-stable: developer hanya boleh memakai objek dan API yang sudah di-released, bukan objek internal yang bisa berubah saat upgrade.
Salah satu cara membangun ekstensi side-by-side adalah lewat portofolio low-code SAP Build di atas BTP; untuk itu, pembaca bisa menelusuri topik platform low-code. Satu hal yang sering disalahpahami: in-app dan side-by-side bukan pilihan “salah satu”. Keduanya saling melengkapi, dan yang menentukan bukan selera developer, melainkan ukuran, siklus hidup, dan keterhubungan ekstensi itu.
Apa kaitan clean core dengan kesiapan migrasi ke cloud?
Di sinilah clean core berpindah dari “praktik baik yang dianjurkan” menjadi “prasyarat yang sulit dihindari”. Alasannya teknis, tapi konsekuensinya finansial.
SAP S/4HANA Cloud public edition, versi multi-tenant yang dipakai bersama banyak pelanggan, hanya mengizinkan extensibility yang sudah di-released. Modifikasi inti gaya lama tidak bisa dibawa ke sana. Maka pertanyaannya bergeser: bukan “apakah kami mau menerapkan clean core”, melainkan “berapa banyak warisan kotor yang harus dibereskan sebelum bisa pindah”. Pada private edition (single-tenant) keleluasaannya lebih besar, tetapi SAP tetap sangat menyarankan clean core. Jadi cloud bukan berarti “tidak boleh kustom”; lebih tepatnya, cloud menuntut kustomisasi yang patuh.
Faktor pendorong kedua adalah tenggat. Menurut panduan SAP terkini, mainstream maintenance untuk SAP ECC (bagian dari SAP Business Suite 7) berakhir pada 2027, dengan opsi extended maintenance berbayar hingga 2030. Tanggal ini pernah bergeser secara historis, sempat 2025 sebelum diperpanjang, jadi konfirmasi selalu ke pengumuman SAP terbaru sebelum mengunci anggaran. Yang tidak berubah adalah arahnya: jendela untuk pindah dengan tenang semakin sempit. Inti yang bersih membuat jalur seperti RISE with SAP atau GROW with SAP berjalan jauh lebih mulus, karena lebih sedikit kustomisasi yang harus diuji ulang, dipindahkan, atau dibuang. Pembaca yang ingin mendalami opsi brownfield, greenfield, dan pertimbangan downtime dapat membaca panduan migrasi ERP ke cloud yang membahasnya tersendiri.
Risiko core yang “kotor” dan kapan clean core BELUM jadi prioritas Anda
Sekarang sisi yang jarang ditulis kompetitor, padahal justru di sinilah kejujuran membangun kepercayaan.
Risikonya dulu. Custom code “Z” warisan, yakni modifikasi dan objek Z yang menumpuk di ECC selama bertahun-tahun, adalah technical debt yang paling sering memperlambat dan mempermahal migrasi. Pola yang berulang di lapangan: sebagian besar modifikasi Z lama itu sudah tidak terpakai, tapi tetap harus dianalisis dan diuji karena tidak ada yang berani memastikan masih dipakai atau tidak. Inilah biaya tersembunyi yang sering diremehkan saat menyusun anggaran migrasi, yakni bukan membangun yang baru, melainkan membongkar yang lama. Klaim “custom code menyumbang sekian persen biaya migrasi” memang beredar luas, tetapi angka pastinya butuh sumber analis yang valid; jadi perlakukan beban ini sebagai signifikan secara kualitatif, bukan sebagai persentase baku.
Meski begitu, clean core bukan prioritas hari pertama untuk setiap perusahaan. Anda kemungkinan belum perlu program remediasi besar-besaran jika:
- Anda masih jauh dari rencana S/4HANA. Baru meng-upgrade ECC dan belum berniat migrasi dalam waktu dekat? Remediasi raksasa sekarang adalah investasi terlalu dini. Yang mendesak justru inventarisasi: tahu dulu apa yang Anda punya.
- Anda membangun greenfield dari nol. Implementasi S/4HANA baru yang bersih otomatis mencapai clean core sejak awal, selama tim disiplin memakai released objects. Tidak ada warisan untuk dibersihkan.
- Belum ada tata kelola. Memburu custom code lama tanpa menetapkan aturan main ke depan hanya akan menghasilkan tumpukan kotor yang baru dalam dua tahun.
Maka, sebelum bicara remediasi besar, dahulukan urutan yang tidak glamor tapi menentukan: inventarisasi seluruh kustomisasi (SAP menyediakan instrumen seperti SAP Readiness Check untuk menyorotnya, konfirmasi nama tool yang relevan dengan versi Anda), lalu klasifikasi tiap item menjadi dipertahankan, dihapus, atau dibangun ulang di SAP BTP, dan tutup dengan tata kelola agar tim hanya memakai released objects ke depan. Pendekatan menilai clean core maturity (kematangan clean core) memang ada untuk memandu prioritas, tapi perlakukan sebagai pendekatan, bukan skala angka resmi tunggal. Sebagian besar nilai diraih di tahap memahami, jauh sebelum satu baris kode dipindahkan.
FAQ (Pertanyaan yang Sering Diajukan)
Apa itu clean core dalam SAP?
Clean core adalah prinsip arsitektur untuk menjaga inti (digital core) SAP S/4HANA tetap standar dan mudah di-upgrade. Kustomisasi tidak ditanam dengan memodifikasi sistem standar, melainkan dipindahkan ke luar inti, umumnya ke SAP BTP lewat side-by-side extensibility atau in-app extensibility yang hanya memakai objek released. Tujuannya: upgrade lebih cepat, biaya pemeliharaan lebih rendah, dan sistem siap cloud.
Apakah clean core wajib untuk migrasi ke SAP S/4HANA Cloud?
Secara praktik, ya, terutama untuk S/4HANA Cloud public edition, yang hanya mengizinkan extensibility yang sudah di-released. Modifikasi inti gaya lama tidak bisa dibawa ke sana. Pada private edition keleluasaannya lebih besar, tetapi SAP tetap sangat menyarankan clean core. Jadi clean core berfungsi sebagai prasyarat de-facto kesiapan cloud, bukan sekadar praktik baik opsional.
Apa bedanya in-app extensibility dan side-by-side extensibility?
In-app (key-user) extensibility memperluas S/4HANA dari dalam, misalnya menambah field atau logika kustom memakai objek yang sudah di-released SAP, sehingga tetap upgrade-safe. Side-by-side extensibility membangun aplikasi terpisah di SAP BTP yang tersambung ke inti lewat released/public API. Aturan praktisnya: kebutuhan kecil dan spesifik-modul cocok in-app; aplikasi besar, UX kustom, atau integrasi lintas sistem sebaiknya side-by-side.
Apa itu ABAP Cloud?
ABAP Cloud adalah model pengembangan ABAP yang ter-governance dan upgrade-stable: developer hanya boleh memakai objek dan API yang sudah di-released SAP, bukan objek internal yang bisa berubah saat upgrade. Model ini memastikan kode kustom tetap bersih dan tidak mematahkan inti standar, selaras langsung dengan prinsip clean core.
Apa risiko jika core SAP terlalu banyak dikustomisasi?
Kustomisasi inti berlebihan menumpuk menjadi technical debt: setiap upgrade berpotensi mematahkannya, sehingga proyek upgrade jadi lambat, mahal, dan penuh regression testing. Dalam praktik implementasi, banyak modifikasi “Z” warisan yang sudah tidak terpakai namun tetap harus dianalisis dan diuji. Akumulasi inilah yang sering menjadi penghambat terbesar saat ingin pindah ke S/4HANA Cloud.
Memahami clean core adalah langkah pertama; menerjemahkannya menjadi rencana migrasi yang nyata adalah langkah berikutnya, dan di situlah pengalaman lapangan menentukan apakah biaya tetap terkendali atau membengkak. Soltius membantu perusahaan menerapkan prinsip clean core, memindahkan kustomisasi yang layak ke SAP BTP, agar sistem tetap mudah di-upgrade dan siap cloud. Sebagai SAP Platinum Partner melalui keanggotaan United VARs dan bagian dari Metrodata Group sejak 1998, Soltius mendampingi perusahaan dari penilaian custom code hingga migrasi S/4HANA dan dukungan pasca go-live. Untuk gambaran menyeluruh, telusuri panduan lengkap SAP clean core, lalu mulailah dari inventarisasi, bukan dari membongkar.
Untuk menilai seberapa “bersih” inti SAP Anda sebelum melangkah ke cloud, jelajahi solusi dan mulai diskusi lebih lanjut di soltius.co.id.
