Migrasi ERP bukan sekadar memindahkan tabel dari sistem lama ke sistem baru.
Jika data sumber berisi customer ganda, supplier tidak aktif, format tanggal berbeda, atau kode produk yang tidak konsisten, semua masalah tersebut ikut pindah dan bahkan bisa menjadi lebih sulit diperbaiki setelah go-live.
Karena itu, Mengurangi Risiko ERP Migration perlu dimulai melalui data cleansing yang terstruktur.
Tujuannya bukan membuat seluruh database sempurna, tetapi memastikan data yang benar-benar dibutuhkan ERP baru sudah akurat, lengkap, konsisten, unik, dan siap digunakan dalam proses bisnis.
Mulai dengan Data Profiling sebelum Membersihkan Apa Pun
Jangan langsung menghapus atau memperbaiki data tanpa mengetahui kondisi sebenarnya.
Tahap pertama adalah data profiling: memeriksa jumlah record, missing value, duplicate, format, distribusi nilai, hubungan antartabel, serta anomali yang mungkin mengganggu migrasi.
IBM menjelaskan bahwa proses discovery dan profiling membantu menemukan masalah seperti data yang hilang, format tidak konsisten, error, serta outlier sebelum data masuk tahap cleansing dan transformation.
Sebagai contoh, perusahaan mungkin memiliki 120.000 customer record. Setelah profiling ditemukan 18.000 record tidak memiliki tax ID, 7.000 memiliki alamat kosong, dan sekitar 12.000 berpotensi duplicate.
Informasi ini membuat pekerjaan cleansing dapat diprioritaskan berdasarkan risiko.
Jangan menghabiskan tiga minggu memperbaiki kolom yang tidak akan digunakan di ERP baru sementara field penting seperti customer ID masih berantakan.
Tentukan Data Mana yang Benar-Benar Akan Dimigrasikan
Tidak semua histori perlu dibawa.
ERP lama mungkin menyimpan data selama 15 tahun, tetapi sistem baru hanya membutuhkan master data aktif, open transaction, opening balance, dan histori beberapa tahun untuk kebutuhan operasional.
SAP menyarankan organisasi menyiapkan serta membersihkan master data dan menggunakan pendekatan migrasi yang terencana daripada memindahkan seluruh kompleksitas lama tanpa evaluasi.
Buat klasifikasi seperti:
Migrate untuk data yang masih digunakan.
Archive untuk data lama yang harus disimpan karena audit atau regulasi.
Delete untuk data duplicate, test, rusak, atau tidak memiliki nilai bisnis setelah melewati proses approval.
Misalnya dari 35.000 supplier, ternyata hanya 4.500 yang pernah digunakan dalam tiga tahun terakhir.
Membawa semuanya ke ERP baru hanya menambah beban cleansing, storage, pencarian, serta risiko duplicate.
Gunakan Prinsip Business Value
Tanyakan untuk setiap kelompok data: apakah pengguna benar-benar membutuhkan informasi tersebut setelah go-live?
Jika jawabannya tidak, kemungkinan besar data lebih cocok diarsipkan.
Dengan pendekatan ini, scope migrasai menjadi lebih kecil dan tim bisa memberikan perhatian lebih besar pada data kritis.
Bersihkan Duplicate secara Sistematis
Duplicate customer dan supplier menjadi salah satu masalah paling umum dalam migrasi ERP.
Contohnya:
PT Maju Jaya
PT. Maju Jaya
Maju Jaya, PT
PT Maju Jaya Indonesia
Secara visual mungkin terlihat jelas sebagai perusahaan yang sama. Sistem belum tentu mengetahuinya.
IBM memasukkan duplicate dan inconsistency sebagai masalah umum yang ditangani melalui data cleansing. SAP juga menyediakan proses untuk mengidentifikasi dan menggabungkan redundant business partner record melalui cleansing case.
Gunakan kombinasi identifier untuk melakukan matching, seperti tax ID, email domain, nomor telepon, alamat, rekening bank, atau external customer ID.
Jangan hanya menggunakan nama.
Dua perusahaan dapat memiliki nama hampir sama tetapi sebenarnya merupakan legal entity berbeda.
Untuk record yang meragukan, gunakan human review daripada melakukan merge otomatis. Salah menggabungkan dua supplier yang berbeda bisa jauh lebih berbahaya daripada membiarkan satu duplicate sementara.
Standardisasi Format dan Kode Referensi
Satu kolom negara saja bisa memiliki nilai:
Indonesia
INDONESIA
ID
INA
Indo
Bagi manusia, semuanya bisa dimengerti. Namun ERP baru membutuhkan struktur yang konsisten.
Hal yang sama berlaku untuk unit of measure, currency, payment terms, product category, warehouse code, postal code, dan chart of accounts.
Buat mapping dari legacy value ke target value.
Misalnya:
30 Hari → NET30
Cash → CASH
Indonesia → ID
SAP Data Services menjelaskan bahwa data-quality process dapat digunakan untuk menganalisis, membersihkan, dan melakukan matching pada customer, supplier, product, serta material data saat informasi dipindahkan ke target baru.
Jangan melakukan mapping berdasarkan ingatan masing-masing developer.
Gunakan mapping table yang terdokumentasi dan memiliki business owner sehingga setiap transformasi bisa ditelusuri.
Perbaiki Missing dan Invalid Data Berdasarkan Aturan Bisnis
Tidak semua field kosong adalah masalah.
Middle name kosong mungkin tidak penting. Tetapi currency kosong pada supplier payment atau account code kosong pada opening balance bisa menghentikan proses.
Tentukan critical data elements.
Misalnya master customer wajib mempunyai Customer ID, Legal Name, Country, Currency, dan Payment Terms. Product wajib memiliki SKU, Description, Unit of Measure, dan Product Category.
IBM menggunakan dimensi seperti accuracy, completeness, consistency, timeliness, uniqueness, dan validity untuk menilai kualitas data.
Buat data-quality rule berdasarkan dimensi tersebut.
Contohnya, completeness Customer Tax ID minimal 98%, duplicate active customer di bawah 0,5%, dan seluruh currency code harus mengikuti daftar target ERP.
Dengan begitu, kualitas data mempunyai target terukur, bukan sekadar penilaian “kelihatannya sudah bersih”.
Pisahkan Cleansing dari Transformation
Data cleansing dan data transformation sering dianggap sama, padahal fungsinya berbeda.
Cleansing memperbaiki kualitas sumber. Transformation mengubah struktur agar sesuai dengan target ERP.
Misalnya nilai JKT sebenarnya valid pada sistem lama. Jika ERP baru menggunakan ID-JK, proses mengubah JKT menjadi ID-JK adalah transformation, bukan perbaikan error.
Pemisahan ini penting agar root cause mudah dilacak.
Jika hasil migrasi salah, tim dapat melihat apakah masalah berasal dari source quality, cleansing rule, atau transformation mapping.
Microsoft menyarankan migration strategy mencakup source dan target, entity yang dipindahkan, metode extract-transform-load, dependency, sequence, responsibility, serta aktivitas sebelum dan sesudah cutover.
Dokumentasi ini mengurangi risiko validassi berubah-ubah selama proyek berlangsung.
Gunakan Data Owner untuk Menyetujui Hasil Cleansing
Tim IT tidak boleh menentukan sendiri bahwa dua customer harus digabungkan atau account tertentu tidak lagi digunakan.
Keputusan data membutuhkan business owner.
Finance menjadi owner chart of accounts. Procurement bertanggung jawab terhadap supplier. Sales atau customer operations mengelola customer master. Warehouse memahami material dan inventory.
Setelah cleansing selesai, masing-masing owner melakukan review serta sign-off.
Misalnya IT menemukan 800 supplier berpotensi duplicate. Procurement menentukan 610 memang duplicate, 140 sebenarnya legal entity berbeda, dan 50 perlu investigasi.
Ownership seperti ini menjaga cleansing tetap sesuai realitas bisnis.
Selain itu, buat change control setelah data dianggap bersih. Jangan sampai user terus mengubah legacy master data tanpa mekanisme sinkronisasi menjelang cutover.
Ukur Kualitas Data sebelum Memberikan Status Ready
Sebelum menyatakan cleansing selesai, bandingkan hasil dengan threshold yang telah disepakati.
Misalnya:
Customer completeness: 99,2%
Supplier duplicate: 0,2%
Product valid UOM: 100%
Invalid account mapping: 0
Open invoice reconciliation: 100%
Microsoft menekankan pentingnya memastikan data migrasi akurat, lengkap, tersedia, dan sudah diuji sebelum go-live.
Risiko jika langkah tersebut tidak dilakukan mencakup data corrupt, keterlambatan migrasi, hingga turunnya kepercayaan pengguna.
Angka seperti ini menghasilkan keputusan yang jauh lebih objektif.
Data cleansing bukan selesai ketika semua orang lelah memeriksa spreadsheet. Cleansing selesai ketika data memenuhi acceptance criteria yang sudah ditentukan.
Mengurangi Risiko ERP Migration membutuhkan data cleansing yang dimulai dari profiling, pengurangan scope data, deduplikasi, standardisasi, hingga quality validation. Jangan memindahkan seluruh masalah legacy ke sistem baru.
Tetapkan data owner dan target kualitas sejak awal, lalu ukur hasilnya sebelum cutover agar proses migrasi lebih aman dan kebutuhan rekonsilasii setelah go-live dapat ditekan.