Sebagian besar cerita gagal dalam proyek migrasi ERP ke cloud tidak bermula di modul inti. Keuangan, penjualan, dan logistik biasanya berpindah sesuai rencana. Yang menyandera jadwal go-live justru puluhan antarmuka kecil yang menghubungkan ERP dengan bank, sistem pajak, marketplace, dan gudang: integrasi yang dulu dibangun untuk SAP ECC dan sering tidak bisa dipindahkan apa adanya. Panduan ini bukan soal memindahkan data, melainkan cara menata ulang lapisan integrasi saat ERP migration to the cloud: menginventarisasi antarmuka, memilih pola yang tepat, dan memindahkannya ke platform integrasi cloud-native tanpa menyeret hutang teknis lama.
Ringkas: Strategi integrasi dalam migrasi ERP ke cloud adalah pendekatan terencana untuk memetakan seluruh antarmuka yang menghubungkan ERP dengan sistem lain seperti bank, pajak, e-commerce, dan gudang, lalu memilih pola integrasi yang tepat dan memindahkannya ke platform integrasi cloud-native seperti SAP Integration Suite, bukan menyalin interface lama apa adanya.
Urutannya di lapangan hampir selalu sama: petakan dulu, putuskan pola, baru pindahkan. Bagian berikut membedah tiap langkah, lengkap dengan pola integrasi dan antarmuka khas perusahaan Indonesia yang paling sering menyita waktu.
Mengapa integrasi jadi risiko tersembunyi terbesar saat migrasi ERP ke cloud?
Integrasi menjadi risiko terbesar karena sistem ERP jarang gagal di modul inti; mereka gagal di titik antarmuka ke bank, pajak, e-commerce, dan gudang. Banyak interface era ECC dibangun sebagai koneksi point-to-point atau di atas middleware lama yang masa dukungannya berakhir, sehingga tidak bisa dibawa ke cloud apa adanya.
Konsultan yang pernah menangani migrasi S/4HANA cenderung sepakat pada satu hal: integrasi yang kompleks konsisten disebut termasuk tantangan terbesar, sejajar dengan kualitas data dan kode kustom yang tidak lagi kompatibel (CIO.com). Kalimat yang sering diulang di ruang proyek terdengar sederhana tapi mahal: sistem tidak gagal secara terisolasi, mereka gagal di titik integrasi.
Lapisan integrasi (integration layer) adalah kumpulan antarmuka dan middleware yang memindahkan data antara ERP dan sistem lain. Di lingkungan ECC yang sudah berjalan bertahun-tahun, lapisan ini biasanya menumpuk tanpa peta: sebagian lewat middleware seperti SAP PI/PO, sebagian koneksi langsung antar aplikasi, sebagian lagi skrip yang dibuat cepat lalu dilupakan. Ketika ERP pindah ke cloud, endpoint berubah, model data S/4HANA berbeda, dan model keamanan cloud menuntut cara autentikasi baru. Antarmuka lama pun tidak ikut secara otomatis.
Karena itu integrasi layak diperlakukan sebagai alur kerja tersendiri dalam proyek, bukan tugas sampingan yang dikerjakan di akhir. Semakin cepat ia dipetakan, semakin kecil kejutan saat cutover (saat sistem lama dimatikan dan sistem baru dinyalakan).
Memetakan lanskap antarmuka: berapa banyak yang sebenarnya Anda punya?
Langkah pertama bukan memilih teknologi, melainkan inventarisasi. Perusahaan perlu mendata setiap antarmuka masuk dan keluar (inbound dan outbound), menandai mana yang kritikal seperti bank dan pajak versus non-kritikal, lalu memetakan ketergantungannya. Tanpa inventaris ini, tim baru menemukan interface yang terlewat saat pengujian cutover, ketika waktu paling mahal.
Pertanyaan “berapa banyak antarmuka yang kita punya?” hampir selalu dijawab terlalu kecil di awal, karena banyak integrasi lama berjalan diam-diam tanpa dokumentasi. Inventaris yang jujur biasanya menghasilkan daftar yang lebih panjang, dan itu justru bagus: lebih baik tahu sekarang daripada saat rekonsiliasi bank gagal di minggu pertama go-live.
Inventarisasi yang berguna menempuh empat langkah:
- Daftar semua antarmuka inbound dan outbound. Catat sumber, tujuan, data apa yang mengalir, dan seberapa sering (real-time, per jam, atau batch harian).
- Klasifikasikan kritikalitasnya. Interface bank dan pajak menghentikan bisnis bila putus; feed laporan mingguan bisa menunggu. Kritikalitas menentukan urutan pengujian dan prioritas.
- Petakan ketergantungan teknisnya. Protokol, format file, dan middleware yang menopang tiap interface menentukan seberapa besar pekerjaan pemindahannya.
- Putuskan nasib tiap antarmuka. Setiap interface hanya punya empat kemungkinan takdir: dipindahkan, dibangun ulang, digabung, atau dipangkas.
Langkah keempat inilah yang paling sering dilewati. Tim cenderung berasumsi semua interface harus ikut pindah, padahal sebagian sudah tidak relevan. Keputusan itu akan dibahas lagi di bagian akhir artikel ini.
Apa itu SAP Integration Suite dan mengapa menggantikan PI/PO?
SAP Integration Suite adalah platform integrasi cloud-native yang menjadi layanan inti SAP Business Technology Platform (BTP). SAP memposisikannya sebagai penerus resmi SAP PI/PO (Process Integration/Orchestration). Karena mainstream maintenance PI/PO berakhir 31 Desember 2027, perusahaan perlu merencanakan pemindahan antarmuka lama ke Integration Suite sebelum tenggat tersebut.
Selama bertahun-tahun, banyak perusahaan menjalankan integrasi SAP di atas SAP PI/PO, middleware on-premise berbasis SAP NetWeaver. Penggantinya kini adalah SAP Integration Suite, yang berjalan sebagai layanan cloud di atas SAP BTP. SAP menegaskan Integration Suite sebagai produk penerus resmi PI/PO, sementara PI/PO tidak lagi menerima inovasi fungsional baru (SAP Architecture Center).
Tenggatnya nyata. Mainstream maintenance PI/PO yang berbasis NetWeaver 7.5 berakhir 31 Desember 2027, dengan extended maintenance berbiaya lebih tinggi hingga akhir 2030. Tanggal ini sejajar dengan akhir dukungan SAP ECC, sehingga banyak perusahaan menghadapi dua tenggat sekaligus: memindahkan ERP dan memindahkan lapisan integrasinya.
Integration Suite bukan satu alat tunggal, melainkan kumpulan kapabilitas dalam satu paket. Yang paling sering dipakai:
- Cloud Integration: mesin integrasi proses dan pesan yang menjalankan integration flow (iFlow), penerus fungsi ESB (enterprise service bus) dari PI/PO.
- API Management: merancang, menerbitkan, dan mengelola siklus hidup API.
- Event Mesh: komunikasi berbasis event (publish/subscribe) untuk proses yang asinkron.
- Integration Advisor: usulan pemetaan cerdas untuk integrasi B2B, mendukung standar seperti EDIFACT, ANSI X12, dan IDoc.
- Open Connectors: ratusan konektor prebuilt ke aplikasi non-SAP, mempercepat integrasi ke aplikasi SaaS pihak ketiga.
| Aspek | SAP PI/PO (Process Integration/Orchestration) | SAP Integration Suite |
|---|---|---|
| Model deployment | On-premise, berbasis SAP NetWeaver | Cloud-native, layanan inti SAP BTP |
| Status dukungan | Mainstream maintenance berakhir 31 Des 2027 (extended s/d 2030) | Produk penerus resmi; menerima inovasi baru |
| Kapabilitas API | Terbatas (fokus middleware/ESB) | API Management penuh (design, publish, kelola siklus hidup API) |
| Event-driven | Tidak native | Event Mesh (publish/subscribe) |
| Konektor pihak ketiga | Adapter, sebagian besar dibangun manual | Open Connectors prebuilt (ratusan aplikasi) |
| Gaya integrasi | Cenderung point-to-point/terpusat | API-led, side-by-side (selaras clean core) |
Satu hal yang perlu diluruskan: “penerus resmi” tidak berarti tombol upgrade satu kali klik. Konten integrasi seperti iFlow, pemetaan, dan adapter umumnya harus dinilai ulang dan sebagian dibangun kembali. SAP menyediakan perangkat penilaian migrasi, tetapi mengharapkan konversi satu-lawan-satu adalah asumsi yang berisiko.
Pola integrasi: point-to-point, iDoc/RFC, atau API-led?
Tidak ada satu pola integrasi yang cocok untuk semua antarmuka. Koneksi point-to-point sederhana tetapi cepat menjadi “spaghetti” saat sistem bertambah; iDoc/RFC klasik andal untuk skenario SAP-ke-SAP; API-led lewat API Management paling fleksibel untuk ekosistem campuran SAP dan non-SAP. Pendekatan API-led juga sejalan dengan prinsip clean core.
Memilih pola bukan soal mana yang paling modern, melainkan mana yang paling pas untuk tiap antarmuka. Interface sederhana yang jarang berubah tidak selalu butuh tata kelola API penuh; sebaliknya, kanal yang menghubungkan banyak sistem cloud dan mobile akan tersiksa bila dipaksa point-to-point.
| Pola | Cara kerja | Cocok untuk | Risiko/catatan |
|---|---|---|---|
| Point-to-point | Koneksi langsung antar dua sistem | Interface sedikit, sederhana, jarang berubah | Berlipat jadi “spaghetti” saat sistem bertambah; sulit dipelihara |
| iDoc / RFC / BAPI (klasik SAP) | Format dan remote call bawaan SAP | Skenario SAP-ke-SAP, EDI berbasis IDoc | Masih didukung, tapi kurang fleksibel untuk konsumen cloud/mobile |
| API-led (REST/OData via API Management) | Interface distandarkan sebagai API terkelola | Ekosistem campuran SAP dan non-SAP, kanal cloud/mobile | Butuh tata kelola API; investasi awal lebih besar |
| Event-driven (Event Mesh) | Publish/subscribe event asinkron | Proses loosely-coupled, notifikasi real-time | Menambah kompleksitas operasional |
Di sinilah strategi integrasi bertemu strategi arsitektur. Pola API-led yang dipadukan dengan side-by-side extensibility (menaruh ekstensi di luar inti, di atas BTP) adalah wujud nyata prinsip SAP Clean Core: memperluas dan menghubungkan sistem tanpa memodifikasi inti S/4HANA, sehingga sistem tetap mudah di-upgrade. Karena itu keputusan pola integrasi sebaiknya diambil bersamaan dengan strategi clean core, bukan dipikirkan belakangan setelah interface terlanjur dibangun dengan cara lama.
Meski begitu, kenyataan di lapangan jarang hitam-putih. Sebagian besar organisasi melewati fase transisi hybrid, di mana beberapa interface tetap di on-premise sementara yang lain sudah pindah. Clean core lebih tepat dipahami sebagai perjalanan, bukan status yang tercapai di hari pertama.
Antarmuka khas perusahaan Indonesia: bank, pajak, e-commerce, dan gudang
Perusahaan Indonesia hampir selalu memiliki empat kelompok antarmuka lokal yang harus ditata ulang: koneksi bank host-to-host, integrasi pajak ke Coretax DJP, sinkronisasi e-commerce atau marketplace, dan pertukaran data dengan sistem gudang (warehouse management system). Masing-masing punya pola, format, dan aturan main berbeda yang menentukan urutan pengujian saat cutover.
Koneksi bank biasanya memakai pola host-to-host. Program pembayaran di ERP menghasilkan file pembayaran (payment file), yang lalu dienkripsi dan dikirim via SFTP ke jaringan bank; bank membalas dengan status pembayaran dan rekening koran dalam format seperti MT940 atau CAMT.053. Formatnya berbeda-beda per bank, jadi jangan menganggap satu format sebagai standar universal. Alternatif yang lebih baru adalah SAP Multi-Bank Connectivity, yang menstandarkan koneksi ke banyak bank sekaligus.
Untuk pajak, lanskapnya berubah signifikan sejak Coretax DJP berlaku 1 Januari 2025 (Kemenkeu), menggabungkan e-Faktur, e-SPT, dan e-Billing dalam satu platform. Banyak perusahaan harus membangun ulang interface pajaknya, karena integrasi ERP ke Coretax umumnya lewat API resmi DJP dengan autentikasi token: aplikasi ERP didaftarkan di portal DJP agar data faktur mengalir otomatis tanpa input ulang manual.
Antarmuka e-commerce dan marketplace membawa tantangan berbeda: volume tinggi dan kebutuhan penanganan error serta idempotensi, agar satu pesanan tidak tercatat ganda saat koneksi terputus lalu mencoba ulang. Sementara itu, sistem gudang atau warehouse management system adalah salah satu antarmuka satelit paling umum, biasanya bertukar data stok, pengiriman, dan penerimaan lewat iDoc/RFC atau API.
| Antarmuka satelit | Fungsi | Pola integrasi umum | Catatan lokal |
|---|---|---|---|
| Bank (host-to-host) | Kirim instruksi bayar, terima rekening koran/status | File pembayaran via SFTP; alternatif SAP Multi-Bank Connectivity | Format per bank bervariasi (mis. MT940/CAMT.053) |
| Pajak (Coretax DJP / e-Faktur) | Kirim data faktur, terima status | API resmi DJP dengan autentikasi token | Coretax live 1 Jan 2025; interface pajak lama perlu diperbarui |
| e-commerce / marketplace | Sinkron order, stok, harga | API/konektor (REST) | Volume tinggi; butuh penanganan error dan idempotensi |
| WMS / sistem gudang | Sinkron stok, pengiriman, penerimaan | iDoc/RFC atau API | Antarmuka satelit paling umum yang perlu di-repoint |
Saat cutover, semua antarmuka kritikal ini perlu di-repoint dari sistem lama ke lingkungan cloud dalam jendela waktu yang sempit. Karena itu urutan dan skenario ujinya harus disiapkan jauh hari, bukan diimprovisasi di akhir pekan go-live.
Yang jarang diakui: migrasi adalah kesempatan memangkas integrasi, bukan menyalinnya
Migrasi ke cloud adalah momen langka untuk memangkas antarmuka warisan, bukan menyalin semuanya. Membawa setiap interface lama (“lift & shift” integrasi) hanya memindahkan hutang teknis ke lingkungan baru. Sebagian antarmuka sudah usang karena sistem sumbernya pensiun atau prosesnya berubah, dan sebaiknya dihentikan, bukan dibangun ulang.
Bagian ini jarang ditulis vendor, padahal justru di sinilah biaya tersembunyi paling banyak dihemat. Godaan terbesar dalam proyek migrasi adalah menyalin apa yang sudah ada supaya “aman”. Untuk lapisan integrasi, menyalin apa adanya justru berisiko: Anda memindahkan spaghetti lama ke rumah baru yang seharusnya rapi.
Sebelum memutuskan sebuah interface layak ikut pindah, ada beberapa pertanyaan yang menyaring dengan cepat:
- Apakah sistem di ujung sana masih hidup? Interface ke aplikasi yang akan dipensiunkan tidak perlu ikut.
- Apakah prosesnya masih berjalan? Sebagian feed dibuat untuk laporan atau proses yang sudah lama tidak dipakai.
- Apakah beberapa interface bisa digabung? Beberapa koneksi point-to-point ke sistem yang sama sering bisa disatukan lewat satu API terkelola.
- Apakah ini seharusnya standar, bukan kustom? Banyak integrasi buatan tangan bisa digantikan konektor atau kapabilitas standar.
Kejujuran lain yang perlu disebut: berlangganan RISE with SAP atau GROW with SAP tidak otomatis menyelesaikan integrasi. Paket itu membundel S/4HANA Cloud dan hak dasar BTP, tetapi pekerjaan menata interface tetap proyek tersendiri. Menganggap “sudah RISE, jadi integrasi beres” adalah salah satu asumsi yang paling sering meleset.
FAQ (Pertanyaan yang Sering Diajukan)
Apa itu SAP Integration Suite?
SAP Integration Suite adalah platform integrasi cloud-native yang menjadi layanan inti SAP Business Technology Platform (BTP). Ia menyatukan beberapa kapabilitas: Cloud Integration untuk menghubungkan aplikasi cloud dan on-premise, API Management untuk mengelola API, Event Mesh untuk komunikasi berbasis event, plus Integration Advisor dan ratusan konektor prebuilt. SAP memposisikannya sebagai penerus resmi SAP PI/PO.
Apa bedanya SAP PI/PO dan SAP Integration Suite?
SAP PI/PO (Process Integration/Orchestration) adalah middleware on-premise generasi lama berbasis NetWeaver. SAP Integration Suite adalah penggantinya yang cloud-native di atas BTP, dengan API Management, Event Mesh, dan konektor bawaan. Yang menentukan jadwal: mainstream maintenance PI/PO berakhir 31 Desember 2027 (extended hingga 2030), sehingga interface lama perlu direncanakan pindah.
Apakah integrasi lama bisa langsung dipakai setelah migrasi ke cloud?
Umumnya tidak apa adanya. Banyak antarmuka era ECC dibangun sebagai koneksi point-to-point atau di atas PI/PO yang masa dukungannya berakhir 2027. Perubahan model data S/4HANA, endpoint baru, dan model keamanan cloud sering membuat interface warisan harus dipetakan ulang, dikonfigurasi ulang, atau dibangun kembali di platform integrasi cloud, bukan sekadar disalin.
Bagaimana SAP terhubung dengan e-Faktur/Coretax DJP dan bank?
Untuk pajak, sejak Coretax DJP berlaku 1 Januari 2025, integrasi ERP umumnya lewat API resmi DJP dengan autentikasi token, sehingga data faktur mengalir otomatis. Untuk bank, pola host-to-host lazim dipakai: ERP menghasilkan file pembayaran yang dikirim terenkripsi via SFTP, lalu bank membalas status dan rekening koran (misalnya MT940 atau CAMT.053).
Apakah integrasi harus diuji terpisah sebelum go-live?
Ya. Integrasi adalah salah satu titik kegagalan paling sensitif dalam migrasi S/4HANA; sistem sering gagal justru di titik antarmuka, bukan modul inti. Setiap interface kritikal (bank, pajak, e-commerce, WMS) sebaiknya punya skenario uji end-to-end sendiri, termasuk uji volume, penanganan error, dan rekonsiliasi, sebelum di-repoint ke lingkungan cloud saat cutover.
Berapa besar porsi pekerjaan integrasi dalam proyek migrasi ke cloud?
Bervariasi per perusahaan, tetapi integrasi konsisten disebut sebagai salah satu penyumbang risiko dan effort terbesar migrasi S/4HANA, sejajar dengan kualitas data dan remediasi kode kustom. Langkah pertama yang menentukan adalah inventarisasi: mendata seluruh antarmuka inbound/outbound, mengklasifikasi kritikal versus non-kritikal, dan memutuskan mana yang dipindahkan, dibangun ulang, atau dipangkas.
Kesimpulan
Antarmuka adalah tempat migrasi ERP ke cloud paling sering tergelincir, sekaligus bagian yang paling jarang direncanakan sejak awal. Kabar baiknya, ini bisa dikendalikan: petakan seluruh interface, pilih pola yang tepat untuk masing-masing, pindahkan ke platform integrasi cloud-native seperti SAP Integration Suite, dan pakai momen ini untuk memangkas yang sudah usang. Dengan komitmen inovasi S/4HANA yang dijanjikan SAP hingga 2040, kerja menata ulang lapisan integrasi hari ini punya umur pakai yang panjang.
Sebagai SAP Platinum Partner melalui United VARs dan bagian dari Metrodata Group sejak 1998, Soltius mendampingi perusahaan menata ulang lapisan integrasi SAP dan non-SAP, dari middleware lama ke SAP Integration Suite di atas BTP, agar antarmuka bank, pajak, dan gudang tetap andal setelah pindah ke cloud. Titik mulai yang paling aman bukan memilih alat, melainkan menilai kesiapan dan memetakan interface yang benar-benar Anda punya.
Untuk mendiskusikan kesiapan strategi integrasi migrasi ERP di perusahaan Anda, jelajahi pendekatan yang ditangani Soltius di soltius.co.id.