Jakarta, medianasional.id – Masalah termahal dari spreadsheet bukan spreadsheet-nya. Yang mahal adalah jam kerja yang habis untuk mencocokkan angka antar file: stok versi gudang, stok versi penjualan, dan stok versi laporan keuangan yang ketiganya beda. Riset internal Hashmicro atas lebih dari 5.400 proyek IT menemukan proyek besar rata-rata membengkak 45% dari anggaran, molor 7% dari jadwal, dan hanya memberi nilai 56% lebih rendah dari yang diproyeksikan.
Selama volume transaksi masih kecil, biaya itu tidak terasa. Begitu perusahaan punya dua gudang, tiga cabang, dan lima orang yang sama-sama bisa mengedit file yang sama, biaya koordinasinya naik lebih cepat daripada bisnisnya. Di titik ini migrasi ERP berhenti jadi wacana IT dan berubah jadi keputusan operasional.
Kapan biaya bertahan sudah melampaui biaya pindah
Kebanyakan perusahaan menunda migrasi karena melihat harga lisensi, lalu lupa menghitung ongkos yang sudah mereka bayar diam-diam. Kalau tim finance butuh tiga hari kerja penuh setiap bulan hanya untuk rekonsiliasi antar sistem, itu sekitar 36 hari kerja setahun yang tidak menghasilkan apa pun selain memastikan dua angka cocok. Angka itu belum termasuk waktu manajer yang ikut menengahi ketika dua laporan berbeda dan tidak ada yang tahu mana yang benar.
Ada beberapa sinyal yang lebih jujur daripada intuisi manajemen. Closing bulanan selesai lewat tanggal 15 dan alasannya selalu menunggu data dari gudang. Ada satu orang yang perannya de facto jadi penerjemah antar sistem, dan kalau dia cuti ada proses yang berhenti. Selisih stok fisik dan stok sistem sudah dianggap wajar, bukan dianggap masalah. Permintaan laporan baru dari direksi butuh dua hari kerja, meski datanya sebenarnya sudah tersedia di suatu tempat.
Kalau tiga dari empat sinyal itu kena, perhitungannya sebenarnya sudah selesai. Yang tersisa cuma soal kapan dan seberapa rapi migrasinya dijalankan.
Fase 1: Audit data dan proses sebelum bicara vendor
Urutan yang paling sering dibalik adalah memilih software dulu, baru membereskan data. Hasilnya data kotor pindah dengan rapi ke sistem baru, dan orang menyalahkan sistemnya.
Yang perlu dipetakan sebenarnya cuma tiga hal: proses mana yang benar-benar jalan hari ini (bukan proses versi SOP), data master mana yang jadi sumber kebenaran, dan siapa pemiliknya. Master data supplier dan pelanggan biasanya penyimpan duplikasi paling banyak. Satu supplier bisa punya empat entri dengan ejaan berbeda, dan itu baru ketahuan saat migrasi karena selama ini tidak ada yang dirugikan oleh duplikasi tersebut.
Fase ini juga tempat memutuskan berapa banyak histori yang dibawa. Banyak perusahaan otomatis minta seluruh data lima tahun ke belakang ikut pindah, lalu proyeknya molor berminggu-minggu hanya untuk membersihkan transaksi yang tidak pernah dibuka lagi. Praktik yang lebih masuk akal adalah membawa saldo pembuka plus histori satu sampai dua tahun terakhir, dan menyimpan sisanya sebagai arsip terpisah yang tetap bisa diakses kalau audit membutuhkannya.
Fase 2: Rancang proses target, jangan salin proses lama
Godaan terbesar saat implementasi adalah meminta sistem baru meniru persis cara kerja lama. Padahal banyak alur kerja di spreadsheet lahir dari keterbatasan spreadsheet: approval lewat chat karena file tidak bisa mencatat approval, rekap manual karena file tidak saling bicara, laporan dobel karena tiap divisi merasa perlu punya versi sendiri. Menyalin alur itu ke sistem baru sama saja membayar mahal untuk mengawetkan masalah.
Fase ini juga menentukan cakupan modul. Perusahaan yang memaksakan seluruh modul aktif serentak biasanya kehabisan energi di bulan ketiga, dan bukan karena softwarenya bermasalah, tapi karena tim operasional tidak punya kapasitas belajar sebanyak itu sambil tetap melayani pelanggan. Lebih aman memulai dari tulang punggung transaksi, yaitu inventory, purchasing, sales, dan accounting, lalu menyusul HR atau manufaktur di gelombang berikutnya. Syaratnya keempatnya berdiri di atas program ERP terintegrasi yang sama, supaya tidak lahir pulau data baru di dalam sistem baru.
Satu hal yang perlu diputuskan lebih awal: siapa pemilik proyek dari sisi bisnis. Kalau migrasi hanya dipegang IT, keputusan proses akan selalu tertahan menunggu persetujuan yang tidak jelas datang dari siapa. Proyek yang berjalan lancar biasanya punya satu orang operasional senior yang punya wewenang memutuskan alur mana yang dipakai, dan waktunya memang dialokasikan untuk itu, bukan disambi.
Fase 3: Parallel run
Sistem lama dan sistem baru berjalan bersamaan selama satu sampai dua siklus closing. Tim mencatat dua kali, lalu membandingkan hasilnya. Semua orang membenci fase ini karena beban kerjanya berlipat, tapi ini satu-satunya cara menemukan selisih ketika taruhannya masih rendah. Selisih saldo persediaan yang ketahuan saat parallel run cuma butuh perbaikan konfigurasi. Selisih yang sama, kalau ketahuan setelah cutover, bisa menahan penerbitan laporan keuangan dan menyeret tim finance ke lembur berminggu-minggu.
Trade-off-nya jujur saja ada. Parallel run memperpanjang timeline dan menambah lembur, dan tekanan untuk memangkasnya biasanya datang dari manajemen yang sudah terlanjur mengumumkan tanggal go-live. Kalau memang harus dipangkas, pangkas cakupannya, bukan durasinya. Jalankan pencatatan ganda penuh hanya untuk proses bervolume tinggi seperti penjualan dan penerimaan barang, dan cukup uji sampel untuk proses yang jarang terjadi.
Fase 4: Cutover dan stabilisasi
Cutover sebaiknya jatuh di awal periode akuntansi, bukan di tengah bulan. Saldo awal dikunci, transaksi baru hanya masuk ke sistem baru, dan sistem lama diubah jadi read-only. Poin terakhir sering dilewat, akibatnya ada tim yang diam-diam masih mencatat di file lama karena merasa lebih cepat. Dua bulan kemudian muncul selisih yang sulit dilacak, dan sumbernya bukan sistem baru, melainkan kebiasaan yang tidak pernah benar-benar ditutup.
Dua sampai tiga bulan setelah cutover adalah masa stabilisasi. Produktivitas biasanya turun dulu sebelum naik, karena semua orang sedang belajar. Manajemen yang tidak disiapkan untuk penurunan sementara ini cenderung buru-buru menyimpulkan bahwa sistem barunya gagal, padahal yang mereka lihat adalah kurva belajar yang normal.
Pelatihan juga sebaiknya tidak diperlakukan sebagai acara sekali jadi. Sesi dua hari sebelum go-live hampir selalu tidak cukup. Yang lebih berpengaruh adalah pendampingan di siklus transaksi pertama, saat orang menghadapi kasus nyata dan bukan contoh kasus.
Ukuran keberhasilan yang layak dipakai
Berapa persen modul yang aktif bukan ukuran keberhasilan. Yang layak diukur adalah hal yang berdampak ke biaya: lama closing bulanan dibanding rata-rata enam bulan sebelum migrasi, jam kerja yang habis untuk rekonsiliasi manual, akurasi stok sistem terhadap stok fisik saat opname, selisih waktu antara transaksi terjadi dan transaksi tercatat, serta jumlah laporan yang masih dirakit manual di luar sistem.
Ukur semuanya sebelum migrasi dimulai. Tanpa baseline, tidak ada cara membuktikan proyeknya berhasil, dan diskusi soal hasil akan berakhir jadi soal perasaan: tim IT merasa sudah berhasil, tim operasional merasa kerjanya justru bertambah, dan tidak ada angka yang bisa menengahi.
Migrasi ERP jarang gagal karena salah pilih software. Yang lebih sering terjadi, perusahaan memindahkan cara kerja lama ke sistem baru, lalu heran kenapa biayanya tidak turun.
