Manajemen Master Data ERP: Pelanggan, Produk, dan Pemasok
Oleh Apex Horizon Digital
Workflow ERP bergantung pada master data yang terlihat sederhana sampai pelanggan yang sama memiliki empat record, satu produk memakai tiga unit, atau supplier mengganti detail bank tanpa review. Defect ini menyebar ke order, inventory, invoice, reporting, dan integration. Master data management adalah disiplin operasi untuk menetapkan trusted record, memberi ownership, mengontrol perubahan, dan mengukur kualitas. Perusahaan tidak membutuhkan komite besar untuk memulainya. Yang dibutuhkan adalah data dictionary praktis, steward bernama, validation rule, dan workflow yang membuat jalur resmi lebih mudah daripada spreadsheet tidak resmi.
Ringkasan utama
- Perlakukan record pelanggan, produk, dan pemasok sebagai aset bisnis yang di-govern, bukan input administratif.
- Tetapkan satu accountable owner per domain dan definisikan tim yang boleh mengusulkan, menyetujui, serta menjalankan perubahan.
- Ukur completeness, uniqueness, validity, consistency, dan timeliness melalui exception queue yang terlihat.
1. Definisikan setiap domain dan record otoritatif
Mulai dengan data dictionary untuk pelanggan, produk, dan pemasok. Untuk setiap field, dokumentasikan arti, format, allowed value, status required, owner, dan downstream process yang memakainya. Bedakan legal customer dari delivery location, contact, account, atau sales relationship. Bedakan stocked product dari variant, packaging level, service, bundle, atau raw material. Bedakan legal entity pemasok dari cabang dan payment account.
Tentukan system of record dan golden identifier untuk setiap object. Jika CRM, ecommerce, procurement, dan accounting application menyimpan salinan, jelaskan sistem mana yang boleh membuat record serta sistem mana yang menerima update. Nama yang sama bukan key tepercaya. Gunakan stable identifier dan controlled cross-reference. ERP harus menolak atau mengantrekan record yang tidak dapat di-match dengan aman.
- Definisi dan tujuan bisnis
- Stable identifier dan system of record
- Required field dan allowed value
- Downstream consumer dan dependency
2. Tetapkan ownership dan workflow governance yang ringan
Domain owner accountable atas policy dan quality. Data steward menangani review harian, requester menyediakan evidence, dan technical administrator memelihara rule. Tulis responsibility matrix untuk create, review, approve, change, merge, deactivate, serta restore. Pisahkan perubahan sensitif seperti rekening bank supplier, credit limit pelanggan, tax identifier, dan product valuation attribute dari update rutin.
Gunakan request workflow berisi alasan, supporting document, affected record, effective date, reviewer, dan audit trail. Perubahan urgent tetap memerlukan jalur terkontrol yang lebih cepat. Service target mencegah tim membuat shadow record karena approval terasa lambat. Review antrean mingguan untuk menemukan bottleneck, alasan rejection berulang, dan perubahan yang sebaiknya diotomatisasi dari verified source system.
- Policy owner dan daily steward
- Requester, reviewer, dan executor
- Approval path untuk field sensitif
- Service target dan escalation
3. Tetapkan required field berdasarkan lifecycle
Tidak semua field harus lengkap pada initial capture, tetapi setiap workflow stage memerlukan entry standard. Sales prospect mungkin cukup dengan detail minimal, sedangkan customer yang boleh ditagih membutuhkan legal name, tax treatment, billing address, payment terms, dan credit control. Draft product mungkin belum memiliki final price, tetapi tidak boleh released untuk purchase tanpa unit, category, lead time, serta accounting mapping. Definisikan gate ini berdasarkan status.
Validasi format, range, reference, dan combination rule. Postal code dapat bergantung pada country, unit conversion harus positif, dan inactive supplier tidak boleh menerima purchase order baru. Hindari default yang menyembunyikan ketidakpastian, seperti unknown tax code atau warehouse. Arahkan invalid submission ke exception queue dengan penjelasan dan owner yang jelas.
- Minimum field per lifecycle status
- Format dan reference validation
- Cross-field business rule
- Exception handling yang terlihat
4. Cegah duplicate dan kelola merge dengan aman
Duplicate detection perlu menggabungkan normalized name dengan sinyal lebih kuat seperti tax number, telephone, email domain, address, bank account, manufacturer code, atau barcode. Konfigurasikan exact match dan possible match secara terpisah. Possible match sebaiknya meminta review, bukan memblokir cabang legal. Catat alasan steward menyatakan record sama atau berbeda agar reviewer berikutnya memahami keputusan.
Merge adalah controlled transaction, bukan penghapusan sederhana. Pilih surviving identifier, pertahankan source reference, pindahkan relasi yang diizinkan, selesaikan conflicting value, dan simpan audit trail. Uji perilaku open order, invoice, inventory, pricing, contract, serta integration. Sebagian record sebaiknya di-link, bukan digabung, karena perbedaan legal atau reporting tetap penting.
- Normalized field dan strong match
- Exact versus possible-match rule
- Survivor dan cross-reference policy
- Preservasi relasi dan audit
5. Jalankan quality scorecard dan change review
Pantau completeness, uniqueness, validity, consistency, timeliness, dan unresolved exception per domain serta tim. Laporkan konsekuensi operasional seperti order terblokir karena terms kosong, invoice ditolak akibat tax data, stock adjustment karena unit error, atau payment ditahan untuk review bank detail. Ukuran berbasis konsekuensi menjaga governance tetap terkait dengan business value.
Review high-risk change, duplicate trend, aging exception, rejected integration record, dan field yang sering dikoreksi setelah creation. Hapus field yang tidak dipakai dan perkuat rule jika defect berulang. Artifact intinya adalah living data dictionary yang dipasangkan dengan ownership, approval, duplicate, dan lifecycle rule. Master data yang baik membuat setiap ERP module serta connected application lebih mudah dipercaya.
- Quality dimension per domain
- Exception aging dan owner
- Ukuran operational impact
- Review rule dan field retirement