Cara Menyiapkan Tim Sebelum Go-Live Odoo

Hari go-live Odoo yang berjalan buruk hampir tidak pernah disebabkan software rusak. Berjalan buruk karena staff gudang nggak tahu tombol mana yang harus dipencet, sales menerima order via telepon lalu menulis di kertas karena nggak mau terlihat lambat di depan customer, dan akuntan memutuskan “cek dulu di sistem lama” lalu akhirnya menjalankan dua sistem sebulan penuh.

Software-nya sudah siap. Timnya belum. Gap itu bisa ditutup, tapi cuma kalau Anda mulai menutupnya sebelum tanggal launch, bukan sesudah.

Berikut rencana persiapan empat minggu sebelum go-live yang bekerja di proyek-proyek UKM Indonesia yang kami jalankan. Detail spesifiknya bergeser per industri, tapi bentuknya tetap.

Minggu minus 4: identifikasi power user dan skeptis Anda

Setiap departemen butuh dua orang: power user dan skeptis. Pilih sekarang.

Power user adalah orang yang akan jadi expert internal. Mereka ikut testing lebih cepat dari yang lain, mereka duduk dengan konsultan untuk walkthrough ekstra, mereka jadi orang yang ditanya kolega kalau stuck. Ini nggak mesti orang paling senior. Sering kali staff level menengah yang penasaran dengan sistem dan bisa eksekusi. Owner distributor tekstil di Bandung yang kami bantu memilih warehouse coordinator-nya — anak 28 tahun yang belum pernah pakai ERP — di atas warehouse manager-nya yang sudah pakai tiga ERP. Dia benar. Si coordinator paham Odoo dalam dua minggu lalu melatih semua orang lain.

Skeptis adalah orang yang paling mungkin menolak perubahan. Bukan yang paling lantang komplain — yang pendiam, yang sudah mengerjakan tugas dengan cara tertentu selama lima belas tahun dan nggak punya niat berubah. Tarik mereka masuk lebih awal. Minta mereka cari hal-hal yang nggak akan jalan di sistem baru. Tanggapi keberatannya serius. Kebanyakan dijawab dengan training. Yang nggak terjawab biasanya gap workflow nyata yang harus ditangani sebelum launch. Skeptis yang merasa didengar berubah jadi accepter. Skeptis yang merasa diinjak berubah jadi saboteur.

Minggu minus 3: training, dengan format yang tepat

Kebanyakan konsultan menjalankan training sebagai sesi kelas empat jam per departemen. Yang nyangkut hampir nggak ada. Format yang tepat tergantung peran.

Untuk peran transaksional — kasir, staff gudang, sales admin — train hands-on langsung di dalam sandbox dengan skenario realistis. “Ibu Sari dari Toko Mawar datang dan beli lima item, bayar setengah cash dan setengah GoPay, lalu minta retur satu item dari belanja kemarin.” Jalankan skenarionya. Suruh mereka kerjakan sendiri. Ulangi dengan variasi sampai jadi muscle memory. Sesi hands-on 90 menit selalu menang dibanding kelas empat jam.

Untuk peran pengambil keputusan — manajer yang approve pembelian, finance yang review laporan — train ke logika workflow-nya, bukan ke tombolnya. Mereka perlu paham apa yang sistem lakukan atas nama mereka saat klik approve, bukan cuma di mana tombol approve-nya. Walkthrough 90 menit dari alur purchase order end-to-end mulai dari request, approval, receipt, sampai pembayaran bill mengajarkan manajer kenapa tiap langkah ada, yang penting saat mereka harus mengambil pengecualian nanti.

Untuk eksekutif — owner, direktur — train ke laporan dan dashboard, bukan ke modul. Mereka jarang input data. Mereka lihat angka tiap hari. Pastikan angka yang akan mereka lihat dikonfigurasi, label-nya jelas, dan ditempatkan di mana mereka akan mencarinya.

Minggu minus 2: parallel running, dengan deadline

Di sinilah mayoritas proyek atau benar atau salah.

Run parallel — tim memakai sistem lama dan Odoo bersamaan, membandingkan output — adalah rekomendasi standar. Penyebab biasanya gagal: nggak ada yang menetapkan tanggal akhir. Tim memakai dua-duanya selama dua minggu, lalu sebulan, lalu tiga bulan, dan sistem lama jadi sumber kebenaran sebenarnya sementara Odoo jadi proyek sampingan. Data di Odoo perlahan-lahan membusuk karena nggak ada yang berkomitmen padanya.

Solusinya brutal-sederhana. Tetapkan tanggal akhir parallel run yang keras sebelum parallel running dimulai. Dua minggu, bukan “sampai kita nyaman”. Selama dua minggu itu, tiap transaksi masuk ke kedua sistem dan konsultan rekonsiliasi output-nya. Hari ke-14, sistem lama jadi read-only. Hari ke-21, sistem lama diarsipkan.

Ini memaksa tim memunculkan masalah di minggu pertama parallel running, bukan bulan ketiga saat momentum sudah hilang.

Minggu minus 1: dress rehearsal

Seminggu sebelum go-live, jalankan satu hari penuh di mana tim hanya pakai Odoo, dengan sistem lama dilarang. Konsultan duduk di ruangan. Setiap masalah yang muncul dicatat dan ditriase. Kalau masalah kritis muncul, geser go-live seminggu. Go-live dengan masalah kritis yang sudah diketahui lebih buruk daripada digeser.

Dress rehearsal ini juga mengungkap gap proses yang training berapa pun nggak akan tangkap. Kasir yang sudah jalanin POS lima kali di training tapi belum pernah handle retur untuk metode pembayaran yang awalnya split antara cash dan OVO. Staff gudang yang sudah lakukan transfer di training tapi belum pernah handle transfer di mana count-nya kurang dua unit. Inilah situasi-situasi yang merusak kepercayaan diri di hari pertama go-live. Memunculkannya di hari dress rehearsal artinya Anda perbaiki di ketenangan sebelum launch.

Hari nol: siapa yang ada di ruangan

Pagi hari go-live, orang-orang kunci hadir fisik. Owner atau sponsor. Konsultan atau partner. Power user tiap departemen. Skeptis — biarkan mereka melihat. Orang IT. Grup WhatsApp untuk triase masalah cepat. Whiteboard untuk track issue terbuka dan ownership-nya.

Tim perlu melihat leadership memperlakukan hari launch sebagai prioritas, bukan sebagai hari biasa dengan go-live yang berjalan di latar belakang. Owner yang menerima telepon dan rapat selama go-live mengirim sinyal jelas bahwa ini sebenarnya nggak penting. Owner yang mengosongkan kalender dan berdiri di lantai mengirim sinyal sebaliknya. Yang kedua berhasil.

Yang training berapa pun nggak akan perbaiki

Satu pola yang layak disebut. Sebagian staff nggak akan engage dengan Odoo seberapa banyak pun training yang Anda berikan, karena mereka secara personal nggak mau berubah. Ini jarang tapi nyata. Identifikasi mereka di minggu minus 2. Pembicaraan yang harus terjadi — apakah mereka akan beradaptasi atau apakah perannya berubah — harus terjadi sebelum go-live, bukan setelah launch berjalan buruk. Ini bagian nggak nyaman dari transformasi digital yang nggak pernah ada di proposal manapun, tapi nyata.

Tujuan dari semua persiapan ini bukan launch day yang sempurna. Hari launch akan ada masalah. Tujuannya adalah tim yang tahu harus berbuat apa saat masalah terjadi dan percaya ada yang bantu. Tim dalam kondisi itu pulih dari minggu launch yang kasar dan akhirnya menyukai sistemnya dalam sebulan. Tim yang nggak siap akan menyalahkan software-nya selamanya.

Kalau Anda lagi menuju go-live dan ingin sepasang mata kedua untuk rencana kesiapan Anda, kami bahas itu di obrolan satu jam, tanpa biaya. Spesifik, jujur, tanpa pitch.