Berapa persen anggaran ERP yang seharusnya dialokasikan untuk kustomisasi?

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.

Bagaimana aturan 80/20 diterapkan dalam keputusan kustomisasi ERP?

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.

Apa itu jebakan upgrade dan bagaimana dampaknya pada ERP yang dikustomisasi secara berlebihan?

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.

Apa itu daftar kustomisasi dan mengapa penting?

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.

Kustomisasi ERP: Kapan Sepadan dan Kapan Jadi Technical Debt

Q: Apa saja alasan yang sah untuk mengkustomisasi sistem ERP?

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.

Kapan kustomisasi ERP sepadan dengan biayanya dan kapan menjadi technical debt — dengan contoh nyata dari implementasi UKM Indonesia dan kerangka kerja untuk mengambil keputusan.

Ringkasan Utama

Perkirakan 10 sampai 30 persen dari total anggaran ERP habis untuk kustomisasi, dan anggap itu angka konservatif. Biaya sebenarnya menumpuk setelahnya lewat pengujian upgrade, pemeliharaan, dan kerumitan yang harus dilewati setiap perubahan berikutnya, dan karena itu keputusannya termasuk bagian dari business case.

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.

Standar vs Kustom: Apa yang Dikatakan Angka

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.

Tiga Alasan Sah untuk Mengkustomisasi

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.

Tujuh Permintaan yang Tidak Pernah Sepadan untuk Dikustomisasi

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 horizon

Dari 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 vs Kustomisasi: Ketahui Perbedaannya

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 * rate

Kustomisasi dalam Custom ERP: Permainan yang Berbeda

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

Membangun Daftar Kustomisasi

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.

Rekomendasi Saya: Aturan 80/20 untuk Kustomisasi ERP

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.

Sumber & Bacaan Lanjutan

Kustomisasi ERP: Analisis Biaya-Manfaat yang Jujur