Bagian ketiga telah menuntaskan pembersihan: nama sudah diseragamkan, tanggal memakai satu format, angka benar-benar menjadi angka, dan makna yang dulu tersimpan dalam warna sel kini berubah menjadi kolom yang tertulis. Data sudah siap dipindahkan. Yang tersisa adalah keputusan yang menentukan apakah peralihan berlangsung tenang atau berubah menjadi kekacauan berminggu-minggu: apa yang dipindahkan lebih dulu?

Ini tampak seperti detail teknis bagi pihak yang menangani implementasi. Sebenarnya ini keputusan operasional, dan itu keputusan Anda. Perusahaan Anda tidak akan berhenti demi migrasi. Pelanggan akan memesan, faktur akan terbit, pemasok akan mengirim — semuanya terjadi saat separuh data Anda berada di satu tempat dan separuhnya lagi di tempat lain. Urutan yang tepatlah yang membuat masa itu bisa dikelola, alih-alih menjadi periode ketika semua orang bekerja dua kali.

Mengapa memindahkan semuanya sekaligus tidak berhasil

Nalurinya bisa dimengerti: pindahkan semuanya di akhir pekan, mulai hari Minggu dengan sistem baru, selesai. Skenario itu biasanya gagal karena tiga alasan yang tidak ada hubungannya dengan kualitas sistem.

Pertama, Anda akan menemukan lebih banyak hal selama pemindahan daripada yang Anda kira. Setiap migrasi memunculkan data yang hilang yang tidak pernah disadari siapa pun: pelanggan tanpa nomor pajak, barang tanpa satuan ukuran, faktur tanpa nomor referensi. Pindahkan semuanya bersamaan, dan semua temuan itu datang serentak, pada saat yang paling sempit.

Kedua, tim Anda mempelajari sistem sambil menjalankannya. Tidak ada yang menguasai alat baru dalam sehari. Pemindahan sekali jalan menuntut semua orang mempelajari segalanya secara bersamaan, sehingga ketika muncul kesalahan Anda tidak bisa tahu asalnya: datanya yang salah, konfigurasi sistemnya yang keliru, atau karyawan memang belum memahami layarnya?

Ketiga, cara itu tidak menyisakan jalan untuk kembali. Jika dua hari kemudian muncul cacat mendasar, pilihan Anda hanya memaksakan diri terus maju atau kembali sepenuhnya, dan keduanya mahal. Pemindahan bertahap selalu menjaga sebagian bisnis tetap berpijak di tanah yang stabil. Ini salah satu pola yang berulang dalam proyek sistem yang macet: kesalahannya jarang ada pada alatnya, dan biasanya ada pada upaya mengubah segalanya di hari yang sama.

Data master sebelum transaksi: aturan yang menjadi landasan seluruh urutan

Data Anda terbagi dua jenis. Data master: pelanggan, pemasok, barang atau jasa, karyawan, bagan akun. Dan data transaksi: faktur, pesanan, pesanan pembelian, pergerakan stok, penerimaan pembayaran.

Perbedaan keduanya bukan soal kepentingan, melainkan arah. Data transaksi selalu menunjuk ke data master: setiap faktur menunjuk ke seorang pelanggan dan sejumlah barang, setiap pesanan pembelian menunjuk ke seorang pemasok. Kebalikannya tidak pernah berlaku. Jadi urutannya ditentukan oleh ketergantungan, bukan preferensi: pindahkan data master lebih dulu, karena transaksi tidak bisa berdiri di atas sesuatu yang belum ada.

Balik urutannya dan Anda mendapat kegagalan klasik: Anda mengimpor tiga ribu faktur, sistem otomatis membuat pelanggan baru untuk setiap nama yang tertulis di dalamnya, dan Anda berakhir dengan daftar pelanggan yang memuat perusahaan yang sama tiga kali dengan tiga ejaan. Anda akan menciptakan ulang, di dalam sistem, kekacauan yang persis sama dengan yang dibersihkan sepanjang bagian ketiga — hanya saja sekarang memperbaikinya lebih sulit.

Dalam praktiknya, urutannya seperti ini:

  • Pertama: entitas inti. Pelanggan, pemasok, barang, dan jasa. Daftar pendek yang dipindahkan sekali dan diperiksa dengan mata. Inilah lapisan tempat segala hal lain berdiri.
  • Kedua: saldo awal. Berapa utang setiap pelanggan kepada Anda dan berapa utang Anda kepada setiap pemasok, jumlah stok pada saat dimulai, saldo akun. Ini bukan riwayat; ini titik nol tempat sistem mulai. Pilih satu tanggal tertentu untuknya dan pegang teguh.
  • Ketiga: hanya transaksi yang masih terbuka. Apa yang aktif saat ini — pesanan yang belum dikirim, faktur yang belum tertagih, pesanan pembelian yang belum diterima. Inilah yang disentuh tim setiap hari, dan jumlahnya jauh lebih kecil daripada yang Anda bayangkan.
  • Terakhir, dan mungkin tidak pernah: arsip historis. Faktur yang sudah ditutup dari tahun-tahun sebelumnya.

Arsip historis: pertanyaan yang menghemat waktu berminggu-minggu

Satu-satunya penyedot waktu dan uang terbesar dalam migrasi adalah desakan untuk membawa seluruh riwayat perusahaan ke sistem baru. Pertanyaan yang harus mendahului keputusan itu: apa yang sebenarnya akan Anda lakukan dengan riwayat tersebut?

Jika jawabannya kami memerlukannya untuk mencari data atau untuk pemeriksaan sesuai ketentuan hukum, arsip sudah menjalankan fungsi itu sebagaimana adanya — tersimpan dalam format aslinya, di tempat yang diketahui dan dapat dicari. Kewajiban hukum Anda adalah menyimpan faktur dan catatan serta mampu menunjukkannya saat diminta, sebagaimana ditetapkan oleh Otoritas Zakat, Pajak, dan Bea Cukai (ZATCA), bukan memastikan semuanya berada di dalam sistem baru.

Jika jawabannya kami ingin laporan yang membandingkan tahun ini dengan tahun-tahun sebelumnya, maka Anda memerlukan sebagian riwayat, bukan seluruhnya, dan biasanya pada tingkat ringkasan, bukan setiap baris faktur. Perbedaan antara kedua migrasi itu besar, baik dari segi tenaga maupun biaya.

Aturan kerjanya: pindahkan riwayat yang akan Anda jadikan dasar keputusan, dan simpan sisanya sebagai arsip. Jangan jadikan migrasi arsip sebagai prasyarat untuk mulai beroperasi — itu bisa dilakukan belakangan tanpa tekanan, sementara mulai beroperasi tidak bisa ditunda tanpa batas.

Operasi paralel: perlu, dan berbahaya jika dibiarkan terbuka

Operasi paralel berarti mencatat transaksi di sistem baru dan di file lama secara bersamaan selama periode yang ditentukan. Tujuannya satu dan spesifik: memastikan sistem menghasilkan angka yang sama dengan yang sudah Anda ketahui. Anda membandingkan total penjualan minggu itu, saldo pelanggan, jumlah satu atau dua barang. Jika angkanya cocok, sistem bekerja dengan benar; jika berbeda, Anda mengetahuinya sebelum ada yang mengambil keputusan berdasarkan angka yang salah.

Namun operasi paralel punya biaya nyata: tim Anda bekerja dua kali. Biaya itu dapat diterima selama dua minggu dan merusak jika berlangsung tiga bulan. Bahayanya bukan hanya soal tenaga. Setelah beberapa waktu, pencatatan ganda mulai tergelincir — seseorang mencatat di satu tempat dan menunda yang lain — sehingga kedua salinan makin berbeda dan latihan ini sepenuhnya kehilangan maknanya, karena Anda tidak lagi tahu mana yang benar.

Jadi satu-satunya aturan yang penting di sini: operasi paralel dengan tanggal akhir yang diumumkan kepada semua orang sejak hari pertama. Tuliskan tanggalnya, sampaikan kepada tim, dan perpanjang hanya melalui keputusan yang tegas dengan alasan tertulis — jangan pernah karena terbawa arus. Masa tanpa batas waktu bukanlah kehati-hatian; itu keputusan yang ditunda, dan itulah cara paling umum sebuah sistem baru hanya setengah terpakai selama satu tahun penuh. Hal ini termasuk dalam pekerjaan manajemen perubahan yang dibahas panjang dalam panduan kami tentang menerapkan sistem secara bertahap.

Pandangan Origami

Saat kami membangun sistem khusus untuk perusahaan yang berjalan dengan spreadsheet, kami memperlakukan rencana migrasi sebagai bagian dari desain, bukan sebagai langkah eksekusi di akhir proyek. Alasannya, urutan migrasi memaksa keputusan tentang struktur sistem itu sendiri: entitas mana yang harus bisa berdiri sendiri, kolom mana yang harus boleh sementara belum lengkap, dan di mana kami memerlukan impor yang dapat diulang tanpa menggandakan catatan.

Kami juga menetapkan bersama klien tanggal penutupan file lama sebelum mulai, karena tanggal itulah yang mengubah proyek dari eksperimen paralel menjadi peralihan yang sesungguhnya. Ini pendekatan yang sama dengan yang kami terapkan dalam peta jalan digitalisasi bertahap, dan berlaku di seluruh layanan kami: setiap tahap menghasilkan sesuatu yang berfungsi, bukan janji bahwa semuanya akan berfungsi di akhir.

Tanda yang memberi tahu Anda bahwa peralihan berhasil

Anda tidak akan tahu apakah peralihan berhasil dari laporan penyelesaian atau persentase migrasi. Anda akan mengetahuinya dari perilaku yang tidak diminta siapa pun: seorang karyawan berhenti membuka file lama tanpa disuruh. Ketika sistem menjadi hal pertama yang mereka buka di pagi hari karena itulah jalan tercepat menuju apa yang mereka perlukan, peralihan benar-benar telah terjadi. Ketika mereka tetap membuka file itu setiap pagi meskipun semuanya sudah dimigrasikan, peralihan belum terjadi, apa pun yang dikatakan angka kemajuan.

Perhatikan tanda itu, bukan angka-angkanya. Dan jika Anda mendapati orang-orang kembali ke file lama, alasannya biasanya bukan penolakan — melainkan sistem tidak memberi mereka sesuatu yang mereka perlukan, atau memberikannya dengan lambat, atau dengan lebih banyak langkah. Itu penyebab yang bisa diperbaiki, tetapi hanya jika Anda melihatnya sejak dini dan menanyakannya.

Di bagian-bagian berikutnya

Data sudah berpindah dengan urutan yang benar, dan muncul pertanyaan yang tidak ada di dunia file: siapa pun yang membuka file melihat semua isinya, sedangkan sistem menentukan siapa melihat apa. Bagian berikutnya membahas hak akses — penggajian, margin, dan data pelanggan, serta siapa yang boleh melihat masing-masing. Setelah itu kita beralih ke laporan yang dulu Anda susun secara manual setiap bulan, dan menutup seri ini dengan tiga puluh hari pertama setelah peralihan.

Sumber