Implementasi Aplikasi di Lapangan: Pelatihan Pengguna, Migrasi Data, dan Go-Live
Panduan implementasi sistem informasi ke pengguna: persiapan lokasi, migrasi data, pelatihan per peran, strategi go-live, pendampingan (hypercare), dan menghadapi penolakan pengguna.
Aplikasi yang bagus di ruang developer bisa gagal di lapangan. Penyebabnya jarang soal kode. Lebih sering karena pengguna belum siap, data lama berantakan, printer tidak tersambung, atau jaringan di ruang poli lemah. Tahap implementasi adalah saat aplikasi bertemu kenyataan.
1. Survei lokasi sebelum hari H
Datangi lokasi dan periksa hal-hal yang sering luput:
- Jaringan: kecepatan dan kestabilan di setiap ruangan, bukan hanya di ruang server.
- Perangkat: spesifikasi komputer, versi browser, printer struk, printer label/gelang, barcode scanner, dan tablet.
- Listrik: ketersediaan UPS untuk server dan perangkat penting.
- Tata letak: posisi layar antrean, meja pendaftaran, dan alur gerak pasien.
Buat daftar kekurangan dan sepakati dengan klien siapa yang menyiapkannya, beserta tenggat waktunya.
2. Migrasi data
Data lama hampir selalu lebih berantakan dari perkiraan: pasien tercatat ganda, format tanggal tidak seragam, atau kode obat berbeda dengan master baru. Langkah yang disarankan:
- Tentukan data apa saja yang dipindahkan. Tidak semua data historis perlu masuk ke sistem baru.
- Buat skrip migrasi yang bisa dijalankan ulang, jangan dikerjakan manual.
- Lakukan migrasi percobaan ke lingkungan staging, lalu minta klien memverifikasi sampel data.
- Catat jumlah data sebelum dan sesudah migrasi, termasuk data yang ditolak beserta alasannya.
- Jalankan migrasi final sesaat sebelum go-live, setelah input di sistem lama dihentikan.
3. Pelatihan per peran
Pelatihan massal di aula selama sehari jarang efektif. Lebih baik:
- Kelompokkan per peran: petugas pendaftaran, perawat, dokter, farmasi, laboratorium, kasir, dan manajemen. Setiap kelompok hanya belajar yang mereka pakai.
- Gunakan skenario nyata di lingkungan latihan: "Pasien BPJS datang untuk kontrol, lalu dirujuk ke lab."
- Latih "super user" di setiap unit. Mereka menjadi tempat bertanya pertama bagi rekan-rekannya setelah go-live.
- Sediakan panduan singkat satu atau dua halaman per peran, lengkap dengan gambar, dan tempel di dekat komputer.
- Jadwalkan di luar jam sibuk pelayanan, dan siapkan sesi ulang untuk yang berhalangan.
4. Strategi go-live
| Strategi | Kelebihan | Kekurangan |
|---|---|---|
| Big bang (semua unit sekaligus) | Cepat, tidak ada masa dua sistem | Risiko tinggi jika ada masalah besar |
| Bertahap (per unit/modul) | Risiko lebih kecil, tim bisa fokus | Butuh jembatan sementara antar-sistem |
| Paralel (sistem lama dan baru bersamaan) | Ada cadangan jika sistem baru bermasalah | Beban kerja ganda bagi pengguna |
Apa pun strateginya, siapkan rencana darurat. Misalnya formulir kertas untuk mencatat pelayanan jika sistem tidak bisa diakses, dan prosedur memasukkan data tersebut setelah sistem pulih.
5. Hypercare: pendampingan setelah go-live
Minggu-minggu pertama menentukan kesan pengguna terhadap sistem baru. Tim sebaiknya:
- Hadir langsung di unit-unit sibuk pada hari-hari pertama.
- Menyediakan jalur laporan yang cepat, misalnya grup chat khusus, dengan pencatatan setiap masalah.
- Mengadakan evaluasi harian singkat: masalah apa yang muncul, apa yang sudah selesai, dan apa prioritas besok.
- Membedakan bug (sistem salah), permintaan perubahan (sistem benar tetapi pengguna ingin berbeda), dan kebutuhan pelatihan (pengguna belum paham).
Checklist menjelang go-live
| Waktu | Yang dipastikan |
|---|---|
| H-14 | UAT selesai dan ditandatangani, jadwal pelatihan semua peran tuntas |
| H-7 | Perangkat dan printer di setiap unit sudah diuji, akun pengguna dibuat, migrasi percobaan terakhir diverifikasi |
| H-3 | Backup dan monitoring produksi aktif, runbook rollback siap, formulir kertas cadangan dicetak |
| H-1 | Input di sistem lama dihentikan, migrasi final dijalankan, jumlah data dicocokkan |
| Hari H | Tim pendamping di setiap unit sejak jam buka, grup laporan aktif, evaluasi di akhir hari |
Contoh laporan masalah selama hypercare
| No | Unit | Masalah | Jenis | Status |
|---|---|---|---|---|
| 1 | Farmasi | Label obat tercetak terpotong | Bug (pengaturan printer) | Selesai hari 1 |
| 2 | Poli umum | Dokter ingin template anamnesis sendiri | Permintaan perubahan | Dijadwalkan |
| 3 | Kasir | Tidak tahu cara membatalkan transaksi | Pelatihan | Dilatih ulang |
Pencatatan seperti ini membuat evaluasi harian cepat, dan menunjukkan kepada klien bahwa setiap laporan ditangani.
Tanda implementasi berjalan baik
- Laporan masalah per hari terus menurun setelah minggu pertama.
- Waktu pelayanan, misalnya waktu pendaftaran per pasien, kembali normal atau lebih cepat dari sebelumnya.
- Super user di setiap unit mulai menjawab pertanyaan rekan-rekannya sendiri.
- Tidak ada lagi pencatatan ganda di kertas, kecuali saat prosedur darurat.
6. Menghadapi penolakan pengguna
Perubahan hampir selalu memunculkan penolakan: "Dulu lebih cepat pakai kertas." Sikap yang membantu:
- Dengarkan dahulu. Kadang keluhan itu menunjukkan masalah nyata pada alur aplikasi.
- Tunjukkan manfaat bagi pengguna itu sendiri, bukan hanya bagi manajemen. Contohnya laporan akhir bulan yang tidak perlu lagi direkap manual.
- Libatkan pimpinan unit agar penggunaan sistem menjadi keputusan organisasi, bukan hanya permintaan vendor.
- Perbaiki cepat hal-hal kecil yang mengganggu. Kepercayaan pengguna tumbuh dari masalah kecil yang cepat diselesaikan.
Implementasi adalah bagian dari siklus proyek yang lebih besar. Lihat gambaran utuhnya di artikel siklus proyek IT kesehatan.