Pemilik Data Sebelum Integrasi DMS dan ERP: Keputusan Kunci

Pemilik data adalah sistem atau tim yang berwenang menjadi sumber kebenaran untuk setiap objek data. Sebelum integrasi DMS dan ERP, jawaban langsungnya: sepakati pemilik data untuk ID pelanggan, SKU dan satuan, harga beserta versinya, stok, dan status pesanan. Tuliskan juga sistem penerima salinan, waktu pembaruan, pemilik pengecualian, dan bukti rekonsiliasi. Kesepakatan ini menjadi dasar ruang lingkup integrasi, bukan detail teknis yang diserahkan sepenuhnya kepada vendor.

Pesanan sudah dikonfirmasi di aplikasi sales, tetapi tim gudang melihat nomor pesanan berbeda di ERP; faktur memakai versi harga lama; stok yang dipegang sales tidak sama dengan catatan gudang. Karena itu, tetapkan sistem sumber kebenaran (system of record) untuk setiap objek data, bukan untuk setiap sistem.

Mengapa pemilik data harus disepakati sebelum integrasi DMS dan ERP

DMS (distributor management system) mendukung kerja sama principal, distributor, dan toko: pesanan, kunjungan, stok, dan aktivitas promosi di lapangan. ERP mencakup proses perusahaan yang lebih luas. Keduanya dapat menyimpan objek yang sama dengan tujuan berbeda, dan cakupan setiap produk berbeda. Karena itu, pertanyaan produktif bukan mana yang menggantikan mana, melainkan data mana yang menjadi acuan ketika keduanya berbeda.

Perbedaan definisi juga perlu diselesaikan lebih awal. Istilah sell-in dan sell-out, misalnya, harus dijelaskan berdasarkan transaksi yang dimaksud: penjualan principal ke distributor atau penjualan distributor ke toko. Bila definisi ini tidak sama antar tim, laporan akan tetap berselisih meski integrasi berjalan.

Matriks pemilik data untuk integrasi DMS dan ERP

Tabel berikut adalah kerangka kerja, bukan rekomendasi bahwa satu sistem selalu menjadi pemilik. Isi kolom pemilik sesuai proses perusahaan Anda, lalu uji dengan kasus nyata dari lapangan.

Checklist keputusan sebelum menandatangani ruang lingkup integrasi

Checklist ini membantu tim menetapkan pemilik data dan aturan yang perlu disepakati sebelum integrasi masuk ke tahap teknis.

1. ID pelanggan dan toko. Sepakati format ID, tempat pembuatan pertama, aturan penggabungan duplikat, serta perlakuan ketika toko berganti nama, pindah alamat, atau tutup. Tanpa aturan ini, satu toko dapat muncul dua kali dan riwayat kunjungannya terpecah.
2. SKU dan satuan. Simpan satu daftar konversi satuan yang disetujui kedua pihak. Selisih kuantitas sering berasal dari perbedaan satuan pesanan, bukan dari kesalahan pengiriman.
3. Harga dan versi harga. Tentukan siapa yang menyetujui harga, kapan versi baru mulai berlaku, dan bagaimana pesanan yang sudah dibuat diperlakukan ketika harga berubah. Sebutkan juga siapa yang berwenang memberi harga khusus untuk toko tertentu.
4. Waktu pembaruan stok. Sepakati kapan stok berkurang: saat pesanan dicatat, saat dikonfirmasi, saat barang keluar gudang, atau saat diterima toko. Setiap pilihan memberi konsekuensi berbeda terhadap janji ketersediaan dan terhadap pesanan yang menunggu.
5. Arti status pesanan. Buat daftar status resmi, definisi satu kalimat untuk masing-masing, dan siapa yang boleh mengubahnya. Status yang sama dapat berarti hal berbeda antara tim sales, gudang, dan keuangan.
6. Penanganan pesan gagal. Tentukan tempat pesan gagal terlihat, siapa yang memantau setiap hari kerja, berapa kali percobaan ulang dilakukan, dan kapan pesan dihentikan untuk diperiksa manusia. Tanpa pemilik, pesan gagal hanya berpindah dari satu kotak masuk ke kotak masuk lain.
7. Rekonsiliasi dan akses. Tetapkan laporan pembanding (misalnya jumlah dan nilai pesanan per hari), toleransi selisih yang masih diterima, pemilik tindak lanjut, serta hak akses berdasarkan peran. Tuliskan juga siapa yang berhak mengubah data master dan bagaimana perubahan itu tercatat.

Uji antarmuka dan cara menyelesaikan pengecualian

Sebelum menyetujui apa pun, tanyakan antarmuka apa yang tersedia hari ini: API, pertukaran berkas, atau entri manual. Minta dokumentasi dan nama pihak yang memelihara antarmuka tersebut. Jawaban seperti bisa disesuaikan perlu diikuti contoh tertulis, bukan hanya penjelasan lisan.

Beberapa pertanyaan demo yang membantu memisahkan kemampuan nyata dari janji:

• Tunjukkan satu pesanan yang gagal terkirim, lalu jelaskan bagaimana pesan itu ditemukan, diperbaiki, dan dikirim ulang tanpa membuat pesanan ganda.
• Tunjukkan cara memperbaiki ID pelanggan duplikat yang sudah terlanjur dipakai di kedua sistem.
• Tunjukkan riwayat perubahan harga, termasuk siapa yang menyetujui dan kapan versi baru berlaku.
• Tunjukkan laporan rekonsiliasi pesanan dan stok, serta siapa yang bertanggung jawab atas selisih yang muncul.
• Minta contoh dokumen ruang lingkup yang menyebutkan apa yang termasuk dan secara eksplisit apa yang tidak termasuk.

Sepakati juga aturan pengecualian: data mana yang menang saat kedua sistem berbeda, siapa yang boleh memutuskan, bagaimana eskalasinya, dan prosedur sementara ketika salah satu sistem tidak dapat diakses. Aturan ini lebih menentukan kepercayaan tim daripada daftar fitur.

Kriteria pilot yang bisa diterima

Tetapkan periode pilot dan sumber data sebelum uji dimulai. Evaluasi dapat memeriksa kelengkapan pesanan, waktu pembaruan stok, penanganan pengecualian, dan visibilitas status pengiriman. Contoh ukuran keberhasilan seperti tidak ada pesanan ganda selama periode uji atau setiap pesan gagal memiliki pemilik tindak lanjut adalah contoh yang Anda susun sendiri, bukan tolok ukur industri. Jangan menerbitkan persentase peningkatan tanpa pengukuran yang terverifikasi.

Peran Airpalm dan langkah berikutnya

Airpalm menyebut kunjungan mobile, perencanaan rute, audit toko, pesanan, stok, dan pengelolaan promosi sebagai bagian dari cakupan produknya (airpalm.com, diperiksa 9 Oktober 2026), dengan ruang lingkup SFA, DMS, dan TPM. Ketersediaan integrasi tertentu, kebutuhan konfigurasi, dan ketentuan komersial harus dikonfirmasi melalui demo dan dokumen ruang lingkup; jangan mengasumsikan konektor siap pakai atau jaminan pembaruan waktu nyata. Untuk melihat konteks cakupan distribusi, Anda dapat membaca halaman DMS Airpalm, serta artikel tentang penyebab catatan stok distributor berbeda dari stok fisik dan arti serta batasan status pengiriman distributor.

Langkah praktisnya: isi matriks sumber kebenaran di atas bersama tim gudang, keuangan, dan sales, tandai objek yang belum ada pemiliknya, lalu bawa matriks itu ke sesi demo. Mintalah penjual menunjukkan satu alur gagal dan satu alur rekonsiliasi secara langsung sebelum membahas jadwal implementasi.

Pertanyaan yang sering diajukan (FAQ)

Apakah ERP harus selalu menjadi pemilik data pelanggan?

Tidak otomatis. Pemilik data pelanggan sebaiknya sistem tempat data itu pertama kali dibuat dan dipelihara sehari-hari. Jika sales membuat toko baru saat kunjungan, DMS dapat menjadi titik pembuatan, sementara ERP menyimpan ID referensi yang dipakai untuk faktur dan pembukuan. Yang penting, aturan penggabungan duplikat dan siapa yang berwenang menonaktifkan data ditulis dan disetujui kedua pihak.

Bagaimana menentukan siapa pemilik harga dan versi harga?

Pisahkan menurut jenis harga. Harga principal ke distributor biasanya terkait kontrak dan pembukuan, sedangkan harga promosi ke toko dapat dikelola bersama program promosi. Untuk setiap jenis, tetapkan penyetuju, tanggal mulai berlaku, cara menutup versi lama, dan perlakuan terhadap pesanan yang sudah dibuat sebelum harga berubah.

Seberapa sering rekonsiliasi stok perlu dilakukan?

Tidak ada angka tunggal yang berlaku untuk semua bisnis. Tetapkan periode berdasarkan volume transaksi, kecepatan perputaran barang, dan risiko selisih Anda, lalu lengkapi dengan rekonsiliasi per kejadian setelah retur atau penyesuaian gudang. Yang lebih penting adalah menyebut pemilik tindak lanjut dan toleransi selisih yang masih diterima.

Apa yang harus dilakukan jika pesan integrasi gagal terkirim?

Sepakati sebelumnya tempat pesan gagal terlihat, pemantau harian, jumlah percobaan ulang, dan kapan pesan dihentikan untuk diperiksa manusia. Pastikan pengiriman ulang tidak membuat pesanan ganda, dan catat siapa yang menyelesaikan setiap pengecualian beserta alasannya.