Migrasi Data ERP: Rencana Bertahap untuk Cutover yang Bersih
Oleh Apex Horizon Digital
Migrasi ERP gagal secara diam-diam ketika tim menganggapnya sebagai satu kali export dan import. Load terlihat sukses, tetapi pelanggan duplikat, unit tidak valid, opening balance tidak lengkap, dan exception tanpa owner merusak minggu pertama operasi. Cutover bersih membutuhkan migration workbook yang menghubungkan business scope, source field, transformation rule, validation evidence, dan sign-off yang jelas. Tim juga perlu menjalankan trial load berulang dengan volume menyerupai produksi. Tujuannya bukan sekadar memindahkan setiap baris. Tujuannya adalah memulai ERP baru dengan record, balance, relasi, dan bukti audit yang benar.
Ringkasan utama
- Tentukan scope migrasi dan business ownership sebelum melakukan extract.
- Gunakan mapping, cleansing rule, trial load, dan rekonsiliasi yang repeatable, bukan perbaikan manual di menit terakhir.
- Tetapkan cutover gate, rollback criteria, dan acceptance tertulis untuk setiap domain kritis.
1. Inventarisasi source dan putuskan data yang dipindahkan
Buat source inventory yang mencakup aplikasi, spreadsheet, shared folder, database, dan daftar manual. Untuk setiap source, catat owner, extraction method, rentang tanggal, volume, encoding, identifier, defect yang diketahui, dan retention legal. Kelompokkan data sebagai master, open transaction, balance, history, reference, attachment, atau configuration. Business owner harus menentukan apakah data masuk ERP baru, archive, atau tidak dipindahkan.
Jangan mengimpor history hanya karena tersedia. Tentukan detail historis yang dibutuhkan untuk operasi, audit, warranty, service, atau perbandingan. Closed transaction lama dapat tetap di read-only archive jika akses dan retention terkendali. Definisikan cut-off date serta system of record selama masa transisi agar tim tidak terus mengedit dua sistem tanpa metode rekonsiliasi.
- Source dan business owner
- Kelas data dan keputusan retention
- Extraction method dan cut-off
- Target, archive, atau exclusion
2. Petakan field, key, transformasi, dan dependency
Bangun mapping workbook dengan satu baris untuk setiap target field. Sertakan source field, target entity, target field, data type, required status, transformation, default, lookup, validation, dan owner approval. Dokumentasikan bagaimana source identifier menjadi target key yang stabil. Nama pelanggan bukan identifier aman, dan nomor baris spreadsheet tidak boleh menjadi permanent business key. Simpan cross-reference agar migrated record dapat ditelusuri ke asalnya.
Urutkan dependency secara eksplisit. Unit, currency, tax code, warehouse, account mapping, dan user mungkin harus tersedia sebelum product atau transaction dimuat. Definisikan cara merakit composite record dan relasi many-to-many. Jika beberapa source mengklaim field yang sama, pilih authority dan tulis conflict rule. Mapping perlu memiliki versi serta dijalankan oleh script repeatable atau job terkontrol.
- Source-to-target field map
- Stable key dan cross-reference
- Transformation dan conflict rule
- Dependency dan load sequence
3. Bersihkan data dengan acceptance rule terukur
Profile setiap domain untuk missing required value, duplicate, invalid format, orphan reference, tanggal mustahil, unit tidak konsisten, dan inactive record yang masih dipakai open transaction. Sepakati matching rule sebelum menggabungkan duplicate. Pelanggan dengan nama mirip bisa menjadi cabang, legal entity terpisah, atau duplicate asli. Business steward perlu meninjau match ambigu dan mencatat identifier yang dipertahankan.
Ubah harapan kualitas menjadi count dan threshold. Catat total row, accepted, rejected, corrected, duplicate group, dan unresolved exception. Jangan sembunyikan failed record dengan menghapusnya dari load. Beri setiap exception alasan, owner, due date, dan disposition. Bekukan cleansing rule sebelum final rehearsal agar perubahan terlambat tidak mengubah balance secara tak terduga.
- Kelengkapan required field
- Duplicate dan matching rule
- Referential integrity check
- Exception owner dan disposition
4. Latih full load dan rekonsiliasi total bisnis
Jalankan setidaknya satu trial end-to-end dengan volume menyerupai produksi dan tool yang akan dipakai saat cutover. Ukur waktu extraction, transformation, loading, indexing, validation, dan recovery. Uji rerun agar tim memahami apakah failed batch dapat dilanjutkan dengan aman atau harus di-rollback. Simpan log serta rejected record di lokasi yang dapat diakses technical reviewer dan business reviewer.
Rekonsiliasi harus dilakukan pada beberapa level. Bandingkan record count dan control total, lalu periksa financial balance, quantity dan value inventory, total open order, receivable serta payable aging, dan sample relasi record. Validasi edge case representatif, bukan hanya total terbesar. Technical load yang berhasil belum berarti accepted sampai domain owner menandatangani evidence dan menjelaskan setiap material difference.
- Rehearsal dengan volume produksi
- Runtime dan perilaku rerun
- Count, control total, dan balance
- Sample check dan signed variance
5. Jalankan cutover dengan gate, ownership, dan rollback criteria
Tulis cutover runbook per menit berisi task, predecessor, owner, expected duration, evidence, serta go atau no-go gate. Cakup source freeze, final extraction, backup, load, rekonsiliasi, aktivasi integration, user access, smoke test, komunikasi, dan hypercare. Pastikan cara menangani transaksi yang datang selama freeze. Business decision maker harus tersedia karena hanya mereka yang boleh menerima variance dengan penjelasan.
Definisikan rollback trigger sebelum cutover, termasuk maximum delay, critical reconciliation failure, data domain hilang, atau perilaku integration yang tidak aman. Tetapkan authority untuk memutuskan rollback dan latih recovery path. Setelah launch, pantau data-quality exception, interface failure, duplicate creation, dan opening-balance adjustment setiap hari. Tutup migrasi hanya setelah owner menandatangani final workbook dan sisa issue memiliki controlled resolution.
- Timed runbook dan dependency
- Go atau no-go gate berbasis evidence
- Rollback trigger yang disepakati
- Hypercare metric dan final sign-off