ERP
Playbook Adopsi ERP: Champion, Sandbox, Komunikasi Cutover
April 202610 menit baca
Foto oleh Matheus Bertelli
Champion adalah kolega yang sudah biasa ditanyai rekan-rekannya saat ada hal digital yang membingungkan — mereka menjawab pertanyaan dalam bahasa dan konteks departemen sendiri, seringkali dalam dua menit di meja sebelah. Berbeda dari tim proyek yang tidak bisa ada di mana-mana saat go-live, satu champion per departemen hadir langsung di lapangan selama minggu cutover dan menjadi lini support pertama yang permanen setelahnya. Efektivitas mereka bergantung pada pengakuan formal: satu baris di performance review dan apresiasi terlihat dari atasannya — tanpa itu, peran ini membusuk dalam sebulan.
Sandbox diisi salinan teranonimkan dari data migrasi klien sendiri — kode item nyata, nama customer nyata, dan saldo terbuka yang realistis — sehingga user berlatih dengan data yang familiar dan tidak membeku saat melihat vendor sungguhan dan selisih di hari pertama. Sandbox berjalan dengan skrip skenario per role yang diselesaian secara terlacak, direset setiap Minggu malam agar user berani bereksperimen, dan sengaja menyertakan skenario salah-dan-koreksi agar kepercayaan diri tumbuh dari kemampuan pulih, bukan dari tidak pernah gagal. Yang krusial, sandbox di-deploy lewat pipeline rilis yang sama dengan production agar tidak tampak berbeda dari sistem live.
Selama sistem lama masih bisa ditulis, menggunakan ERP baru bersifat opsional — dan adopsi yang opsional artinya tidak ada adopsi. Post ini menegaskan bahwa tanggal go-live harus diumumkan lebih awal dan ditegakkan: begitu cara lama dikunci, cara baru menjadi satu-satunya jalur. Membiarkan fallback yang masih bisa ditulis juga melanggengkan spreadsheet bayangan dan entri data paralel, persis perilaku yang ingin dieliminasi playbook ini.
Kehadiran training hanya mengukur kursi terisi, bukan perilaku yang berubah, sehingga playbook ini melacak empat angka yang ditarik mingguan dari database aplikasi: transaktor aktif (user unik yang mem-posting dokumen nyata dibanding jumlah yang seharusnya), time-to-task (median menit dari pembuatan dokumen sampai submit untuk tiga jenis dokumen teratas), tingkat koreksi (porsi dokumen yang diedit, dibatalkan, atau diposting ulang setelah submit), dan sinyal alat paralel (apakah spreadsheet bayangan masih hidup, dikonfirmasi langsung oleh champion). Angka jelek di mana pun bukan alasan memarahi departemen — ia sinyal untuk membidik layar, departemen, atau workflow tertentu yang perlu diperbaiki.
Email status all-staff di akhir minggu pertama harus datang dari sponsor eksekutif dan secara terbuka mengakui masalah yang masih terbuka, lengkap dengan tanggal perbaikannya. User memaafkan bug yang terdokumentasi dengan komitmen penyelesaian, tetapi tidak memaafkan keheningan saat pekerjaannya macet. Kalender komunikasi cutover yang lebih luas juga mengandalkan pengulangan dan pengirim yang tepat di setiap tahap: pengumuman umum dari sponsor eksekutif, detail per departemen dari kepala departemen, dan lembar bertahan hidup praktis dari tim proyek tiga hari sebelum go-live.
Foto oleh Matheus Bertelli
ERP yang saya bangun untuk klien berfungsi di hari pertama. Adopsinya tidak. Tiga minggu setelah go-live saya menemukan tim purchasing memelihara sheet Excel paralel — mereka lebih percaya itu — dan mengetik ulang data ke sistem di akhir hari. Tidak ada yang rusak di service NestJS atau layar React saya. Yang rusak adalah rollout manusianya: siapa belajar sistem kapan, bertanya ke siapa saat bingung, dan diberi tahu harus berharap apa.
Sejak itu saya memperlakukan adopsi sebagai deliverable dengan desainnya sendiri, paralel dengan software-nya. Playbook ini adalah mekanika yang sekarang saya jalankan di setiap implementasi: jaringan champion dengan tanggung jawab nyata, program sandbox yang lebih dari sekadar login demo, dan kalender komunikasi cutover yang tidak menyerahkan minggu pertama pada improvisasi. Ini melengkapi desain kurikulum training — fokusnya di sini adalah mesin operasional di sekitarnya.
Champion bukan orang paling senior di departemen, dan bukan siapa pun yang sedang senggang. Champion adalah kolega yang sudah biasa ditanyai rekan-rekannya saat ada hal digital yang membingungkan — setiap departemen punya persis satu orang ini, biasanya level menengah. Rekrut mereka secara formal, umumkan namanya, dan beri empat tanggung jawab konkret:
Penjawab lini pertama
Champion menyerap pertanyaan bagaimana-caranya dalam bahasa dan konteks departemennya sendiri. Pertanyaan yang terjawab di meja sebelah dalam dua menit tidak pernah menjadi tiket, workaround, atau dendam.
Saluran feedback
Champion memegang jalur langsung ke tim implementasi — grup chat khusus sudah cukup — dan laporannya ditriase dalam sehari. Tidak ada yang membangun kredibilitas lebih cepat daripada keluhan champion yang dibereskan hari Jumat.
Validator workflow
Sebelum tiap modul rilis, champion-nya menjalankan proses nyata di sandbox: dokumen mereka, edge case mereka. Merekalah yang menangkap celah antara bunyi SOP dan cara kerja sebenarnya.
Letnan cutover
Selama minggu go-live, champion memimpin pengecekan pagi di departemennya, mengumpulkan masalah ke log bersama, dan memutuskan mana yang dieskalasi. Tim proyek tidak bisa ada di mana-mana; champion bisa.
Pastikan peran champion masuk ke objektif kerja mereka, walau informal — satu baris di performance review dan apresiasi terlihat dari atasannya. Kerja champion tanpa bayaran dan tanpa pengakuan membusuk dalam sebulan, dan bersamanya struktur support Anda.
Kebanyakan training ERP gagal di titik yang sama: data demo. User mengeklik latihan tentang perusahaan fiktif yang menjual produk fiktif, lalu membeku hari Senin saat layar menampilkan vendor sungguhan dan selisih setengah juta rupiah. Solusinya adalah environment sandbox yang diisi salinan teranonimkan dari data migrasi klien sendiri — kode item nyata, nama customer nyata, saldo terbuka yang realistis.
Saya menjalankan sandbox sebagai program berstruktur, bukan taman bermain bebas:
Jangan biarkan sandbox dan production tampak berbeda. Kalau sandbox menjalankan versi bulan lalu dengan menu berbeda, user menyimpulkan training tidak mencerminkan kenyataan dan diam-diam berhenti hadir. Deploy ke sandbox lewat pipeline rilis yang sama dengan production — build sama, konfigurasi sama, data dimasking.
Komunikasi cutover gagal saat hanya berupa satu email all-staff yang dikirim Jumat sebelumnya. Orang perlu mendengar fakta yang sama beberapa kali, dari pengirim yang tepat, dengan kespesifikan yang meningkat. Ini kalender minimum yang saya susun bersama sponsor proyek klien:
| Kapan | Pesan | Pengirim |
|---|---|---|
| Go-live minus 4 minggu | Tanggalnya, alasannya, dan apa yang berhenti: sistem lama jadi read-only di hari cutover. Champion diperkenalkan dengan nama. | Sponsor eksekutif, all-staff |
| Minus 2 minggu | Spesifik per departemen: proses mana yang berubah di hari pertama, pengingat akses sandbox, status penyelesaian training per nama. | Kepala departemen |
| Minus 3 hari | Lembar bertahan hidup praktis: URL login, bertanya ke siapa (champion dulu), keterbatasan yang diketahui saat launch, jadwal pembekuan sistem lama. | Tim proyek |
| Hari 1, pagi | Kickoff singkat di tiap departemen: sistem live, champion hadir, transaksi pertama dikerjakan bersama di tempat. | Champion, di lapangan |
| Akhir minggu 1 | Status jujur: transaksi terproses, masalah yang sudah dibereskan, masalah yang masih terbuka beserta tanggalnya. Terima kasih dengan nama untuk para early adopter. | Sponsor eksekutif, all-staff |
Dua detail menanggung sebagian besar efeknya. Pertama, sistem lama menjadi read-only harus diumumkan dengan tanggal dan ditegakkan — selama cara lama masih bisa ditulis, cara baru bersifat opsional, dan opsional berarti mati. Kedua, email status minggu pertama harus mengakui masalah terbuka apa adanya. User memaafkan bug yang terdaftar dengan tanggal perbaikan; mereka tidak memaafkan keheningan saat pekerjaannya macet.
Kehadiran training adalah vanity metric — mengukur kursi terisi, bukan perilaku berubah. Setelah go-live saya melacak empat angka per departemen, ditarik mingguan dari database aplikasi dan ditampilkan ke steering committee:
Tujuan mengukur adalah membidik. Angka jelek tidak pernah jadi alasan memarahi departemen — ia sinyal untuk mengirim champion, memperbaiki layar, atau menulis ulang satu halaman SOP. Panduan implementasi Microsoft menekankan poin proporsionalitas yang sama: curahkan upaya change management persis di tempat risikonya muncul, bukan merata di bagan organisasi.
Urutan lengkap seperti yang saya jalankan, dari sebulan sebelum cutover sampai kondisi stabil:
Cek realita anggaran: panduan industri konsisten menempatkan training dan adopsi di kisaran 10 sampai 15 persen dari total biaya proyek. Di custom build itu terasa seperti banyak kode yang bisa Anda tulis sebagai gantinya — sampai Anda ingat alternatifnya adalah sistem yang berfungsi tapi tidak dipakai.
Adopsi bukan yang terjadi setelah proyek; ia workstream di dalam proyek, dengan artefaknya sendiri — daftar champion, skrip skenario sandbox, kalender komunikasi, dashboard metrik. Bangun semua itu dengan keseriusan yang sama seperti kontrak API Anda dan tim purchasing tidak akan butuh spreadsheet paralel. Lewati, dan software tanpa cela pun menjadi sistem yang diakali orang.