Kustomisasi dan integrasi ERP yang berlebihan: kapan perlu, kapan menjadi jebakan biaya

Kustomisasi ERP layak dilakukan bila memberi keunggulan nyata atau memenuhi kewajiban yang tidak bisa dipenuhi fitur standar. Kustomisasi yang hanya bertujuan mempertahankan cara kerja lama biasanya menjadi jebakan: biayanya dibayar sekali di depan, tetapi risikonya dibayar terus, yaitu saat upgrade versi, saat aturan pajak berubah, dan saat Anda ingin pindah vendor. Prinsip yang aman untuk UMKM: ubah proses dulu, konfigurasi kedua, kustomisasi terakhir.

Panduan ini bagian dari pola kegagalan implementasi ERP. Angka di bawah ilustratif.

Konfigurasi, ekstensi, dan kustomisasi

Jenis	Contoh	Risiko jangka panjang
Konfigurasi	Mengatur alur persetujuan, format faktur, hak akses dengan fitur bawaan	Rendah; biasanya ikut upgrade
Laporan khusus	Laporan penjualan per salesman dengan kolom tertentu	Rendah sampai sedang
Ekstensi atau add-on resmi	Modul tambahan dari marketplace aplikasi vendor	Sedang; tergantung pengembang add-on
Integrasi	Sinkronisasi dengan marketplace, POS, bank	Sedang; rusak bila salah satu sistem berubah
Kustomisasi kode	Mengubah logika inti, misalnya perhitungan harga pokok	Tinggi; bisa menghalangi upgrade dan pembaruan pajak

Pada ERP cloud multi-penyewa, kustomisasi kode biasanya dibatasi, yang justru melindungi Anda. Pada ERP on-premise atau open source, kebebasan mengubah kode lebih besar, dan risikonya juga lebih besar.

Aturan sederhana untuk memutuskan

Untuk setiap permintaan kustomisasi, jawab lima pertanyaan:

Apakah ini kewajiban hukum (pajak, ketenagakerjaan, data) yang tidak bisa dipenuhi fitur standar?
Apakah ini keunggulan bersaing yang membuat pelanggan memilih Anda?
Apakah proses bisa diubah agar sesuai fitur standar tanpa kerugian berarti?
Berapa biaya seumur pakai: pembuatan, pengujian di setiap upgrade, dan pemeliharaan?
Siapa yang memeliharanya bila pengembangnya pergi?

Bila jawaban 1 dan 2 "tidak" dan jawaban 3 "ya", jangan kustomisasi.

Contoh ilustratif: biaya seumur pakai

Permintaan: perhitungan komisi salesman dengan aturan khusus yang tidak didukung fitur standar.

Pembuatan: 8 hari kerja × Rp3.000.000 = Rp24.000.000
Pengujian ulang setiap upgrade besar, diasumsikan 2 kali dalam 5 tahun: 2 × 3 hari × Rp3.000.000 = Rp18.000.000
Perbaikan kecil dan pemeliharaan: Rp4.000.000 per tahun × 5 = Rp20.000.000
Biaya 5 tahun: Rp62.000.000

Alternatif: ekspor data penjualan per salesman dari laporan standar, hitung komisi di spreadsheet yang dikunci rumusnya, dengan waktu staf sekitar 4 jam per bulan. Bila nilai jam kerja Rp100.000, biayanya Rp400.000 per bulan atau Rp24.000.000 dalam 5 tahun.

Kustomisasi baru masuk akal bila perhitungan manual itu sering salah dan kesalahannya mahal, atau bila jumlah salesman bertambah banyak.

Integrasi: berapa banyak yang terlalu banyak

Setiap integrasi adalah jembatan yang bisa rusak. Pertanyaan untuk setiap integrasi:

Data apa yang mengalir, ke arah mana, dan seberapa sering?
Sistem mana yang menjadi sumber kebenaran untuk data itu (misalnya stok di ERP, bukan di marketplace)?
Siapa yang memantau bila sinkronisasi gagal, dan bagaimana Anda tahu?
Siapa yang memperbaiki bila sistem pihak ketiga berubah?
Berapa biaya per bulan dan per transaksi?

Untuk UMKM, mulai dengan integrasi yang wajib atau paling banyak menghemat: faktur pajak ke Coretax (lihat integrasi ERP dengan Coretax), mutasi rekening bank, dan kanal penjualan utama. Integrasi lain menyusul setelah sistem stabil.

Kustomisasi dan aturan pajak

Bagian yang paling berbahaya untuk dikustomisasi adalah yang berhubungan dengan pajak: perhitungan PPN, faktur, bukti potong, dan PPh 21. Bila vendor memperbarui fitur standar karena aturan berubah, kustomisasi Anda bisa tidak ikut diperbarui atau malah bertabrakan. Contoh perubahan beberapa tahun terakhir: TER PPh 21 sejak 2024, Coretax dan PPN 12% dengan DPP nilai lain 11/12 sejak 2025. Sebisa mungkin pakai fitur pajak standar vendor dan minta pembaruannya dijamin di kontrak.

Dokumentasi dan kepemilikan

Bila kustomisasi tetap diperlukan:

Minta dokumentasi tertulis: apa yang diubah, di mana, dan mengapa
Tentukan kepemilikan kode dan hak memakai kode itu bila pindah mitra
Simpan kode atau konfigurasi di tempat yang bisa Anda akses
Masukkan pengujian kustomisasi ke rencana setiap upgrade

Tanpa ini, kustomisasi menjadi alasan terbesar Anda tidak bisa keluar dari mitra atau vendor; lihat ekspor data dan keluar dari vendor.

Contoh keputusan untuk permintaan yang sering muncul

Permintaan	Keputusan yang biasanya masuk akal	Alasan
Format faktur dengan logo dan tata letak sendiri	Konfigurasi	Hampir semua ERP menyediakan pengaturan templat dokumen
Nomor dokumen mengikuti pola lama	Konfigurasi bila tersedia, bila tidak terima pola baru	Pola nomor jarang memberi nilai bisnis
Harga khusus per pelanggan dan wilayah	Fitur standar daftar harga	Kebutuhan umum di distribusi
Perhitungan harga pokok dengan cara yang berbeda dari standar akuntansi	Hindari	Berisiko terhadap laporan keuangan dan pajak
Laporan untuk bank atau investor	Laporan khusus yang hanya membaca data	Risiko rendah, nilai jelas
Alur persetujuan pembelian bertingkat	Konfigurasi alur persetujuan	Biasanya tersedia sebagai fitur
Perhitungan PPh 21 "versi sendiri"	Jangan	Gunakan fitur pajak standar yang diperbarui vendor

Bila sebuah permintaan masuk ke baris "hindari" atau "jangan", tuliskan alasannya di dokumen desain. Catatan seperti ini membantu saat permintaan yang sama muncul lagi dari staf baru.

Tanda kustomisasi sudah berlebihan

Upgrade versi ditunda karena takut kustomisasi rusak
Hanya satu orang di vendor yang mengerti sistem Anda
Biaya dukungan terus naik
Laporan standar tidak lagi cocok karena data diolah dengan cara khusus
Pengguna baru sulit dilatih karena alurnya berbeda dari panduan vendor

Pertanyaan yang sering diajukan

Apakah semua laporan khusus termasuk kustomisasi berisiko?

Tidak. Laporan yang hanya membaca data biasanya berisiko rendah. Yang berisiko adalah perubahan yang menulis atau menghitung ulang data inti.

Bagaimana bila vendor menyarankan kustomisasi besar sejak awal?

Tanyakan alternatif dengan fitur standar dan biaya seumur pakainya. Saran kustomisasi besar sebelum proses dipahami adalah tanda bahaya.

Apakah add-on dari pihak ketiga aman?

Tergantung pengembangnya. Cek apakah add-on itu diperbarui setiap kali versi ERP berubah dan siapa yang mendukungnya.

Bagaimana menganggarkan kustomisasi?

Masukkan biaya pembuatan, pengujian di setiap upgrade, dan pemeliharaan tahunan ke simulasi TCO ERP 5 tahun. Lihat juga biaya tersembunyi ERP.

Sumber resmi

Direktorat Jenderal Pajak — perubahan aturan faktur pajak dan PPh yang memengaruhi software
Badan Siber dan Sandi Negara — keamanan sistem dan integrasi
Kementerian Komunikasi dan Digital — penyelenggaraan sistem elektronik