Di perusahaan dengan ratusan karyawan, proyek ERP jarang gagal karena software. Yang sering terjadi: keputusan macet di antara banyak pemangku kepentingan, integrasi dengan sistem lama molor, dan ratusan user enggan berubah.
Karena itu, implementasi Odoo di perusahaan besar sebaiknya diperlakukan sebagai program bertahap 6–12 bulan atau lebih, dengan go-live per entitas atau per lokasi.
Odoo sanggup di skala besar
Odoo sudah dipakai di deployment dengan lebih dari 3.000 user (Solvve, partner Odoo). Studi Panorama Consulting mencatat proyek yang sukses umumnya kuat di tiga hal: tata kelola proyek, perbaikan proses bisnis, dan manajemen perubahan.
Paket yang biasanya cocok
Perusahaan besar umumnya memakai Prune Success Pack layanan Advance dengan Modul Manufaktur atau Bisnis, Modul HRIS, dan Modul Untuk Industri Tertentu seperti konstruksi, rumah sakit, atau pelayaran. Modul industri ini minimal 50 jam, dan bila digabung dengan Modul Fitur Khusus minimal 75 jam.
Contoh: Manufaktur + HRIS + Fitur Khusus + Industri Tertentu 75 jam = Rp 9 juta + Rp 5 juta + Rp 30 juta = Rp 44 juta. Satu paket menampung sampai 200 jam. Untuk program yang lebih panjang, jam layanan offline dan pengembangan berikutnya bisa dibeli terpisah lewat tim Sales Prune. Lisensi dihitung per user (halaman harga Prune).
Struktur tim yang dibutuhkan
| Peran | Dari pihak | Tanggung jawab utama |
|---|---|---|
| Sponsor (CEO/CFO) | Perusahaan | Anggaran, prioritas, keputusan akhir |
| Steering committee | Perusahaan dan partner | Review progres bulanan, eskalasi |
| Project director | Partner | Konsistensi solusi dan jadwal |
| PIC internal | Perusahaan | Koordinasi dan keputusan harian |
| Key user | Perusahaan | Desain proses, UAT, melatih rekan |
| App expert dan developer | Partner | Konfigurasi lanjutan, development, review |
Struktur ini sejalan dengan metodologi Odoo untuk proyek besar: project director melapor ke steering committee, dan ahli dari luar proyek ikut mereview pekerjaan tim pada titik-titik penting.
1. Analisis kebutuhan (1–2 bulan)
Di skala ini, GAP analysis sering dijalankan sebagai proyek tersendiri sebelum kontrak implementasi penuh. Hasilnya business case, kelayakan, rencana fase, anggaran, dan proof of concept proses paling kritis. Libatkan semua entitas dan lokasi sejak awal, supaya tidak ada proses yang baru ketahuan saat testing.
2. Desain solusi (1–2 bulan)
Susun arsitektur solusi lengkap: struktur multi-company dan transaksi antar-entitas, matriks hak akses dan pemisahan tugas untuk kebutuhan audit, peta integrasi (bank, Coretax, HRIS, BI), kebijakan data master, serta infrastruktur dan target performa.
Tetapkan juga peta jalan rollout: entitas mana yang go-live pertama dan apa kriteria lulus sebelum lanjut ke berikutnya.
3. Konfigurasi dan kustomisasi (3–6 bulan)
Bagi pekerjaan ke beberapa workstream, misalnya finance, supply chain, manufaktur, dan HR, yang berjalan paralel. Gunakan lingkungan development, staging, dan produksi terpisah, dengan code review untuk setiap modul kustom.
Migrasi data jadi workstream sendiri dengan 2–3 kali uji coba migrasi penuh. Kustomisasi tetap dibatasi untuk kebutuhan yang kritis, supaya upgrade versi Odoo berikutnya tidak mahal.
4. Training dan UAT (1–2 bulan)
Testing berlapis: uji integrasi antar sistem, UAT per fungsi dengan skrip dan sign-off, serta uji beban agar sistem tetap cepat saat ratusan user aktif bersamaan. Training disebar lewat jaringan key user di tiap lokasi, didukung SOP dan video yang bisa diputar ulang.
5. Go-live dan support (bertahap)
Go-live per gelombang, entitas atau lokasi demi lokasi, dengan rencana cut-over dan rollback yang sudah diuji. Siapkan tim siaga 1–3 bulan per gelombang, dan hindari jadwal yang bertabrakan dengan tutup buku tahunan atau musim puncak.
Setelah stabil, lanjutkan dengan siklus perbaikan berkelanjutan. Metodologi Odoo menjadwalkan review sekitar sebulan setelah go-live untuk memprioritaskan pengembangan berikutnya.
Kesalahan yang paling sering terjadi
- Go-live besar-besaran di semua entitas sekaligus.
- Kustomisasi berlebihan untuk meniru sistem lama.
- Steering committee hanya formalitas, sehingga keputusan lintas fungsi macet.
- Anggaran manajemen perubahan dan training terlalu kecil dibanding anggaran teknis.
Referensi: Solvve, partner Odoo; dokumentasi QuickStart Odoo; Panorama Consulting.