Perusahaan harus mengharapkan pengeluaran 10–30% dari total anggaran ERP hanya untuk kustomisasi — dan itu adalah perkiraan konservatif. Di luar biaya pengembangan awal, kode kustom menambahkan biaya pemeliharaan tahunan $10.000–$50.000 per kustom utama akibat pengujian upgrade dan pekerjaan kompatibilitas, sehingga biaya seumur hidup bertambah secara signifikan.
Ada tiga justifikasi yang sah: kepatuhan regulasi yang tidak didukung sistem standar (seperti perhitungan pajak spesifik Indonesia, format audit BPK, atau integrasi BPJS untuk HR), logika bisnis inti yang benar-benar unik dan kompetitif, serta integrasi dengan hardware atau sistem eksternal yang tidak memiliki konektor standar. Permintaan kustomisasi yang tidak masuk dalam salah satu kategori ini sebaiknya ditolak.
Targetnya adalah 80% konfigurasi standar dan maksimal 20% kustomisasi, diukur berdasarkan biaya bukan jumlah fitur. Jika kustomisasi berdasarkan biaya mendekati 40–50%, sistem tersebut sudah beralih dari 'ERP yang diadaptasi' menjadi 'sistem kustom yang dibangun di atas kerangka ERP' — dan pada titik itu, ERP kustom yang dirancang khusus sering lebih murah selama lima tahun.
Jebakan upgrade adalah biaya yang terus bertambah untuk menjaga kode kustom tetap kompatibel dengan rilis vendor — Odoo merilis satu versi utama per tahun, dan setiap upgrade memerlukan pengujian ulang semua kode kustom serta perbaikan kerusakan kompatibilitas. Untuk bisnis yang menjalankan kustomisasi berat pada Odoo, biaya upgrade tahunan sering melebihi biaya kustomisasi asli, itulah mengapa membangun ERP kustom penuh terkadang lebih disarankan agar tim memiliki codebase sepenuhnya.
Daftar kustomisasi adalah dokumen hidup yang dibuat sebelum pengembangan apa pun dimulai, yang mencantumkan setiap item kustom beserta justifikasi bisnisnya, perkiraan biaya pengembangan, perkiraan biaya pemeliharaan tahunan, dan pemilik yang meminta serta menyetujuinya. Daftar ini harus ditinjau setiap kuartal, dan item yang tidak memiliki hasil bisnis terukur setelah 12 bulan harus menjadi kandidat untuk dihapus — tanpa dokumentasi ini, kode kustom menjadi tidak terpelihara karena tidak ada yang ingat mengapa kode itu ditulis.
Perusahaan harus mengharapkan pengeluaran 10–30% dari total anggaran ERP hanya untuk kustomisasi — dan itu adalah perkiraan konservatif. Biaya kustomisasi ERP sebenarnya bertambah seiring waktu melalui biaya upgrade, pemeliharaan, dan kompleksitas yang diperkenalkan ke sistem yang seharusnya standar. Namun kustomisasi terkadang sangat penting.
Solusi ERP yang terstandarisasi dapat diluncurkan dalam 6–12 bulan. Platform yang sangat disesuaikan membutuhkan 12–18+ bulan. Kode kustom menambahkan biaya pemeliharaan tahunan $10.000–$50.000 per kustom utama. Kasus bisnis untuk kustomisasi harus melewati ambang yang tinggi: kustomisasi harus memberikan nilai bisnis yang spesifik dan dapat dikuantifikasi yang melebihi biaya seumur hidupnya.
Setelah mengevaluasi puluhan permintaan kustomisasi, saya menemukan tiga justifikasi yang sah. Pertama: kepatuhan regulasi yang tidak didukung sistem standar (perhitungan pajak spesifik Indonesia, format audit yang sesuai BPK, integrasi BPJS untuk HR). Kedua: logika bisnis inti yang benar-benar unik dan kompetitif. Ketiga: integrasi dengan hardware atau sistem eksternal yang tidak memiliki konektor standar.
Permintaan kustomisasi ini muncul di hampir setiap proyek dan hampir tidak pernah sepadan: tata letak laporan kustom (gunakan pembuat laporan bawaan atau ekspor ke Excel), template email persetujuan kustom, perubahan UI minor, fitur kenyamanan yang menduplikasi fungsionalitas yang ada, preferensi yang berbeda per pengguna individu, perubahan label bidang kosmetik, dan penambahan bidang yang 'mungkin dibutuhkan suatu hari nanti'.
ERP Customization Decision Matrix
REQUEST │ Config? │ Worth Customizing?
────────────────────────────────┼─────────┼──────────────────────
Indonesian e-faktur integration │ NO │ YES — regulatory req
BPJS contribution calculation │ NO │ YES — regulatory req
Custom approval hierarchy │ MAYBE │ YES if unique logic
Product pricing engine │ MAYBE │ YES if core business
Custom report layout │ YES ✓ │ NO — use config
Field label rename │ YES ✓ │ NO — cosmetic only
Email template styling │ YES ✓ │ NO — use template
"Shortcut" for 3-step process │ NO │ NO — train instead
Sort order preference │ YES ✓ │ NO — user setting
Future "maybe needed" fields │ YES ✓ │ NO — YAGNI
────────────────────────────────────────────────────────────────
COST-BENEFIT GATE: Before approving any customization, require:
1. What business outcome does this enable? (Specific, measurable)
2. What is the annual value of that improvement? (In IDR)
3. Can 80% of the value be achieved through configuration?
────────────────────────────────────────────────────────────────
Lifetime cost formula:
Total = Dev_Cost + (Annual_Maintenance × Years) + (Upgrade_Cost × Upgrades)
Example: Custom approval module
= Rp 25M dev + (Rp 5M × 5yr) + (Rp 8M × 2 upgrades) = Rp 66M
Annual value needed: > Rp 13.2M/yr to justify at 5-year horizonDari pengalaman saya sebagai konsultan ERP lepas (freelance): gunakan gerbang biaya-manfaat untuk setiap permintaan kustomisasi. Pemohon harus menjawab tiga pertanyaan: Hasil bisnis spesifik apa yang ini aktifkan? Apa nilai tahunan estimasi dari peningkatan itu? Bisakah kita mencapai 80% nilai melalui konfigurasi alih-alih kode kustom?
Konfigurasi adalah mengubah cara sistem berperilaku menggunakan alat bawaan — tidak memodifikasi codebase dan tidak rusak pada upgrade. Kustomisasi adalah menulis kode yang mengubah cara sistem bekerja di tingkat teknis — memodifikasi codebase dan rusak pada upgrade. Dalam pengalaman saya, 60–70% dari permintaan kustomisasi awal dapat diselesaikan melalui penggunaan konfigurasi yang lebih baik.
# Configuration vs Customization: Odoo Examples
# ✅ CONFIGURATION — safe, upgrade-friendly
# Setting approval thresholds in Odoo Purchase Settings:
# No code changes. Uses built-in workflow engine.
PURCHASE_ORDER_APPROVAL = {
"limit_1": 5_000_000, # auto-approve under Rp 5M
"limit_2": 25_000_000, # manager approval Rp 5M–25M
"limit_3": None, # director approval above Rp 25M
}
# ✅ CONFIGURATION — custom fields via Odoo Studio
# Adding NPWP field to vendor form:
# Drag-drop in Studio interface. No Python code.
# ❌ CUSTOMIZATION — requires Python code, breaks on upgrade
# Custom module to change the AP aging calculation:
# /addons/custom_ap_aging/__manifest__.py
# This will need retesting and potential rewriting
# every time Odoo releases a major version (yearly).
# 🔶 LEGITIMATE CUSTOMIZATION — regulatory, justified
# Indonesian PPh 23 withholding tax calculation:
class IndonesianWithholdingTax(models.Model):
_inherit = 'account.move'
def compute_pph23(self):
"""Calculate PPh 23 per DJP regulations"""
# This customization is justified:
# 1. Regulatory requirement (no alternative)
# 2. Annual value: avoid manual calculation errors
# 3. Cannot be solved by configuration alone
rate = 0.02 # 2% for services, per PMK-141/2015
return self.amount_untaxed * rateKetika saya membangun ERP kustom sebagai konsultan ERP lepas, pertanyaan kustomisasi tidak menghilang — hanya berubah bentuk. Setiap permintaan fitur masih merupakan keputusan biaya-manfaat. Tetapi perbandingannya berbeda: tidak ada biaya upgrade dari kerusakan kompatibilitas vendor, tidak ada peningkatan biaya lisensi dari menambahkan pengguna.
Ketika Anda mengkustomisasi platform ERP vendor, Anda bertaruh bahwa kustomisasi Anda akan tetap kompatibel melalui upgrade vendor di masa mendatang. Odoo merilis satu versi utama per tahun. Untuk bisnis yang menjalankan kustomisasi berat pada Odoo, biaya upgrade tahunan sering melebihi biaya kustomisasi asli.
Sebelum pengembangan apa pun dimulai, buat daftar kustomisasi: dokumen hidup yang mencantumkan setiap item kustom, justifikasi bisnisnya, perkiraan biaya pengembangan, perkiraan biaya pemeliharaan tahunan, dan pemilik yang meminta dan menyetujuinya. Tinjau daftar ini setiap kuartal.
Targetkan 80% konfigurasi standar, maksimal 20% kustomisasi — berdasarkan biaya, bukan jumlah fitur. Jika Anda mendekati 40–50% kustomisasi berdasarkan biaya, Anda telah melintasi dari 'ERP yang diadaptasi' menjadi 'sistem kustom yang dibangun di atas kerangka ERP' — dan pada titik itu, ERP kustom yang dirancang khusus sering lebih murah selama 5 tahun.