Orientasi Staf ke Sistem Baru Tanpa Kekacauan

Implementasi sistem yang buruk biasanya tidak gagal pada tingkat teknis. Perangkat lunak ini berfungsi. Yang rusak adalah sisi kemanusiaannya: staf menggunakan sistem lama secara paralel, manajer tidak menerapkan proses baru, pelatihan yang dilakukan sekali dan tidak dipertahankan, dan tanggal peluncuran yang tiba sebelum ada yang siap.

Mengapa Peluncuran Gagal

Mode kegagalan yang paling umum:

Pelatihan terlalu dekat untuk ditayangkan. Staf yang dilatih tiga hari sebelum peluncuran telah melupakan 60% dari pelatihan tersebut pada hari pertama. Mereka kembali ke proses lama atau bertanya kepada rekan kerja yang sama-sama ragu.

Tidak ada dokumentasi proses. Sistem mencerminkan suatu proses. Jika prosesnya tidak dituliskan sebelum pembangunan, staf tidak tahu apa yang harus mereka lakukan — mereka tahu cara mengklik layar, tapi tidak tahu urutan dan waktu.

Juara tidak teridentifikasi. Setiap tim membutuhkan seseorang yang mengetahui sistem dengan cukup baik untuk menjawab pertanyaan pada saat itu. Tanpa orang yang ditunjuk, setiap pertanyaan akan diteruskan ke vendor atau tidak terjawab.

Berjalan paralel tanpa tanggal akhir. Menjalankan sistem baru bersama sistem lama masuk akal untuk periode transisi yang ditentukan. Tanpa tanggal peralihan yang pasti, sistem lama tidak akan pernah benar-benar berhenti — staf akan menggunakannya secara default setiap kali sistem baru tidak dikenal.

Tahap Persiapan

Sebelum pelatihan staf dimulai, ada dua hal yang perlu dilakukan.

Dokumentasi proses. Untuk setiap peran yang akan menggunakan sistem, dokumentasikan alur kerjanya: apa yang memicu suatu tindakan, apa yang perlu dimasukkan, apa yang terjadi selanjutnya. Ini tidak perlu rumit — daftar bernomor sederhana untuk setiap peran sudah cukup. Tindakan menuliskannya mengungkapkan kesenjangan dalam proses yang terlewatkan oleh desain sistem.

Menguji data dan lingkungan pementasan. Staf perlu berlatih dalam sistem yang terlihat seperti sistem langsung tetapi tidak akan merusak catatan sebenarnya. Lingkungan pementasan dengan data realistis memungkinkan orang melakukan kesalahan dengan aman sebelum ditayangkan.

Pelatihan Berbasis Peran

"Pelatihan sistem" umum - satu sesi yang mencakup segalanya untuk semua orang - jarang berhasil. Seorang pemilih gudang tidak perlu tahu cara menjalankan laporan akhir bulan. Seorang pengguna keuangan tidak perlu mengetahui alur penerimaan barang.

Pelatihan berdasarkan peran, yang hanya mencakup apa yang dilakukan peran tersebut dalam sistem, lebih singkat, lebih relevan, dan lebih baik dipertahankan. Prinsip desain Jacob Ng untuk antarmuka pekerja garis depan dan pekerja migran juga berlaku di sini: jika layar untuk seorang pemilih hanya menunjukkan apa yang dibutuhkan oleh seorang pemilih, maka pelatihan untuk peran tersebut juga sederhana.

Model Juara

Identifikasi satu orang per tim atau shift yang akan dilatih ke tingkat yang lebih dalam — tidak hanya bagaimana menggunakan sistem tetapi juga bagaimana strukturnya, apa arti kesalahan umum, dan siapa yang harus dihubungi untuk jenis masalah apa. Orang ini menjadi pendukung lini pertama, menangani pertanyaan rutin sebelum menjadi lebih parah.

Sang juara membutuhkan waktu untuk bersiap. Mereka harus diidentifikasi sejak dini, dilatih sebelum anggota tim lainnya, dan diberi akses ke lingkungan pementasan untuk berlatih.

Urutan Go-Live

Tidak semuanya harus ditayangkan pada hari yang sama. Pendekatan bertahap berdasarkan modul atau tim mengurangi radius ledakan jika ada sesuatu yang memerlukan penyesuaian:

1. Mulailah dengan fungsi dengan frekuensi tertinggi dan risiko terendah (seringkali penerimaan inventaris atau entri pesanan penjualan)
2. Jalankan modul tersebut secara langsung selama dua hingga empat minggu sebelum menambahkan modul berikutnya
3. Jaga agar tim peluncuran tetap tersedia untuk dukungan dasar selama setiap fase

Peralihan secara paksa pada semua modul secara bersamaan adalah pendekatan dengan risiko paling tinggi. Audit sistem sebelum dan sesudah implementasi mengidentifikasi area yang paling mungkin memerlukan penyesuaian.

Setelah Go-Live: Bulan Pertama

Bulan pertama adalah saat implementasi berhasil atau gagal dalam jangka panjang. Muncul masalah yang tidak muncul dalam pengujian. Muncul kasus-kasus edge yang tidak diantisipasi. Staf memerlukan dukungan nyata — seseorang yang ada secara fisik, bukan hanya nomor telepon untuk dihubungi.

Tinjauan pasca-tayang pada hari ke-30 – memeriksa tingkat kesalahan, volume tiket dukungan, dan di mana staf masih menggunakan solusi – mengidentifikasi apa yang memerlukan penyesuaian sebelum hal tersebut diterapkan.

Pertanyaan Umum

Berapa lama kita harus menjalankan sistem lama dan baru secara paralel?

Dua hingga empat minggu adalah waktu praktis untuk sebagian besar fungsi. Cukup lama untuk menangkap kesalahan pada sistem baru; cukup singkat sehingga staf memiliki insentif yang tulus untuk mempelajarinya daripada mengikuti pembelajaran lama. Tetapkan tanggal kalender untuk sistem lama berhenti dan mengkomunikasikannya sebelum diluncurkan.

Bagaimana jika staf menolak menggunakan sistem baru?

Perlawanan biasanya mempunyai penyebab: sistem lebih sulit digunakan dibandingkan sistem lama untuk tugas khusus mereka, atau mereka tidak memahami mengapa perubahan diperlukan. Keduanya patut diselidiki sebelum mengaitkan masalahnya dengan sikap. Alur kerja yang benar-benar lebih lambat bagi staf garis depan dibandingkan dengan alur kerja yang digantikannya adalah masalah desain, bukan masalah manajemen perubahan.

Berapa banyak waktu yang harus kita anggarkan untuk pelatihan staf per peran?

Untuk sesi pelatihan berbasis peran yang terfokus, biasanya dua hingga empat jam untuk peran operasional (gudang, entri pesanan penjualan). Pengguna keuangan dengan alur kerja yang lebih kompleks mungkin memerlukan waktu sehari penuh. Pertimbangkan sesi kedua dua minggu setelah peluncuran — ini adalah saat pertanyaan menjadi konkret dan pelatihan dapat dipertahankan dengan lebih baik.

Pesan Audit Sistem