ERP Multi-Perusahaan: Kapan Satu Database Membantu dan Kapan Menghambat
Oleh Apex Horizon Digital
Satu database ERP dapat memberi grup master data konsisten, transaksi intercompany terhubung, dan visibilitas konsolidasi. Satu database juga dapat menyebarkan kesalahan, mengaburkan batas legal, membuka informasi sensitif, dan memaksa perusahaan berbeda mengikuti aturan yang tidak cocok. Keputusan tidak seharusnya dimulai dari preferensi sentralisasi. Mulailah dari entity map: apa yang dimiliki setiap perusahaan, apa yang benar-benar dibagi, transaksi mana yang melintasi batas, siapa boleh melihat atau bertindak pada data, dan bagaimana laporan direkonsiliasi.
Ringkasan utama
- Bagikan data hanya ketika ownership, definisi, dan authority perubahan benar-benar sama.
- Jaga transaksi legal dan hak akses tetap eksplisit meski perusahaan memakai satu platform.
- Pilih batas database dari keterhubungan operasi, risiko, dan governance, bukan kenyamanan saja.
1. Gambarkan model entitas dan ownership
Daftarkan setiap legal entity, cabang, unit operasi, gudang, brand, dan shared service yang harus diwakili sistem. Untuk masing-masing, identifikasi ownership pelanggan, pemasok, produk, harga, inventory, karyawan, rekening bank, pajak, dan dokumen. Sebagian data dapat global dengan local extension. Data lain harus tetap khusus perusahaan. Katalog produk bersama dapat membantu procurement, sementara selling price, perlakuan pajak, atau account mapping berbeda per entitas. Model perlu menjelaskan siapa membuat, menyetujui, mengubah, dan menonaktifkan setiap shared record.
2. Definisikan transaksi intercompany sebagai workflow lengkap
Jangan sembunyikan aktivitas intercompany di balik jurnal manual atau transfer tanpa penjelasan. Petakan dokumen awal, entitas pemasok, entitas penerima, aturan harga, perlakuan pajak, shipment, receipt, invoice, settlement, penanganan mismatch, dan rekonsiliasi. Tentukan apakah satu tindakan membuat mirrored document serta sisi mana yang boleh mengubahnya. Jika inventory bergerak antarperusahaan, ownership legal dan lokasi operasional dapat berubah pada waktu berbeda. Sistem membutuhkan state eksplisit agar kedua entitas mampu menjelaskan apa yang dimiliki, terutang, diharapkan, dan diterima.
3. Rancang hak akses berdasarkan perusahaan dan fungsi
User dapat bekerja untuk satu entitas, beberapa entitas, atau tim shared service. Hak akses perlu menggabungkan company scope dengan fungsi dan tindakan. Group buyer dapat melihat approved demand dari beberapa perusahaan, tetapi tidak harus melihat payroll, margin, atau data bank. Finance lokal dapat melakukan posting untuk satu entitas sementara group finance mengonsolidasikan beberapa entitas. Administrasi juga perlu dipisah: siapa boleh memberi role lintas perusahaan, mengubah shared master data, atau menjalankan export. Uji permission dengan persona nyata dan negative case, bukan hanya akun administrator.
4. Pisahkan visibilitas operasional dari laporan legal
Manajemen mungkin membutuhkan group view untuk demand, stok, sales, exposure kas, dan kinerja, sementara setiap legal entity tetap memerlukan buku serta kontrol sendiri. Definisikan common dimension dan aturan kalkulasi sebelum membangun laporan konsolidasi. Catat mata uang, sumber exchange rate, aturan eliminasi, periode laporan, dan ownership adjustment. Dashboard operasional dapat menggabungkan data tanpa menganggap setiap transaksi milik satu perusahaan. Rekonsiliasi harus menelusuri angka konsolidasi kembali ke transaksi entitas dan menjelaskan perbedaan intercompany.
5. Kenali saat satu database mulai merugikan
Satu database menjadi berisiko ketika perusahaan memiliki sedikit hubungan operasional, kebijakan tidak kompatibel, batas regulasi berbeda, shared governance lemah, atau membutuhkan isolasi kuat. Sistem juga dapat menjadi bottleneck ketika setiap perubahan lokal memerlukan persetujuan grup. Database terpisah menciptakan pekerjaan integrasi dan konsolidasi, tetapi dapat membatasi risiko serta menjaga otonomi. Gunakan decision matrix berisi shared workflow, overlap master data, volume intercompany, kebutuhan reporting, isolasi keamanan, batas regulasi, authority perubahan, dampak outage, dan exit requirement. Arsitektur terbaik adalah yang dapat di-govern grup secara andal.
- Shared layer: definisi, ownership, authority perubahan, dan local extension.
- Company layer: dokumen legal, pajak, akun, ownership inventory, dan approval.
- Intercompany layer: mirrored transaction, state, pricing, settlement, dan rekonsiliasi.
- Access layer: company scope, fungsi, tindakan, field sensitif, dan administrasi.
- Reporting layer: common dimension, currency, eliminasi, traceability, dan sign-off.