Di banyak organisasi, penolakan terhadap alur persetujuan baru biasanya bukan karena orang anti perubahan, melainkan karena mereka khawatir pekerjaan jadi lebih lambat, lebih diawasi, atau lebih rumit. Jika Anda memimpin implementasi, keberhasilan bukan hanya soal fitur, tetapi soal bagaimana pengguna merasa aman, terbantu, dan tetap punya kontrol. Pembahasan ini memberi langkah praktis untuk menurunkan resistensi tanpa mengorbankan tata kelola, auditabilitas, dan kecepatan kerja.
Petakan sumber resistensi: proses, peran, dan beban kerja nyata
Resistensi muncul ketika sistem baru memaksa kebiasaan berubah, sementara manfaatnya belum terlihat. Mulailah dengan memetakan momen friksi di proses saat ini: kapan orang menunggu persetujuan, kapan keputusan bolak-balik, dan kapan versi dokumen hilang.
Wawancara singkat 20–30 menit dengan perwakilan pemohon, approver, dan admin biasanya lebih efektif daripada survei panjang. Tanyakan contoh konkret yang menyulitkan, misalnya pengadaan mendadak untuk event minggu depan atau reimburse perjalanan dinas yang terlambat karena approver cuti.
Setelah itu, pisahkan masalah proses dari masalah perilaku. Banyak organisasi punya aturan yang tidak konsisten antar unit, sehingga sistem terlihat menyusahkan padahal yang perlu dirapikan adalah standar kebijakan dan matriks kewenangan.
- Identifikasi tipe permintaan yang paling sering dan paling kritis (nilai kecil tapi volume tinggi vs nilai besar tapi jarang).
- Catat variasi persetujuan antar divisi (misalnya proyek vs operasional) yang selama ini berjalan informal.
- Ukur baseline sederhana: rata-rata waktu approve, jumlah revisi, dan titik antrean terlama.
- Temukan ketakutan tersembunyi: takut salah approve, takut disalahkan, atau takut dinilai lambat.
Pemetaan ini membantu Anda membuat narasi yang relevan. Sistem baru bukan sekadar alat kontrol, tetapi cara mengurangi kerja ulang dan mempercepat keputusan yang sering tersendat.
Desain alur yang terasa membantu: sederhana dulu, lalu bertahap
Kesalahan umum adalah memindahkan seluruh kompleksitas proses manual ke sistem pada hari pertama. Pengguna kemudian menemukan banyak field wajib, status berlebihan, dan rute persetujuan panjang, sehingga mereka kembali ke chat pribadi atau email.
Strategi yang lebih aman adalah menerapkan “minimum lovable workflow”: cukup tertib untuk mengatur, cukup ringan untuk dipakai. Misalnya, untuk reimburse di bawah ambang tertentu, mulai dengan satu approver dan satu verifikator, lalu tambahkan kontrol seiring stabilnya penggunaan.
Pastikan aturan eskalasi jelas ketika approver tidak tersedia. Di Indonesia, approver sering dinas luar kota atau rapat seharian; tanpa delegasi atau auto-escalation, persepsi “sistem bikin lambat” akan muncul walau masalah sebenarnya ketiadaan keputusan.
Rancang juga tampilan dan input yang sesuai bahasa kerja tim. Jika pengguna biasa menyebut SPPH atau BAST, gunakan istilah itu pada label dan template, lalu jelaskan definisi resminya di bantuan singkat agar tidak terjadi salah tafsir antar unit.
Dari sisi tata kelola, pastikan keputusan bisa ditelusuri tanpa membuat orang merasa diawasi berlebihan. Tekankan bahwa jejak persetujuan melindungi pemohon dan approver saat ada audit atau pertanyaan manajemen; penjelasan praktis tentang catatan audit untuk kepatuhan sering membantu menyelaraskan ekspektasi sejak awal.
Kelola perubahan sebagai kerja operasional: komunikasi, pelatihan, dan dukungan harian
Pengguna jarang menolak sistem; mereka menolak gangguan terhadap ritme kerja. Karena itu, buat rencana komunikasi yang menjawab tiga hal: apa yang berubah, kapan mulai berlaku, dan apa yang dilakukan saat ada kendala.
Hindari materi pelatihan yang terlalu panjang. Untuk pemohon, fokus pada pembuatan permintaan, lampiran dokumen, dan pengecekan status; untuk approver, fokus pada approve/return, memberi catatan yang jelas, dan memakai delegasi saat cuti.
Siapkan kanal dukungan yang responsif selama 2–4 minggu pertama go-live karena resistensi paling keras biasanya terjadi di minggu awal. Banyak masalah sederhana, seperti notifikasi masuk ke folder spam atau pengguna lupa memilih unit, namun efeknya besar karena membuat orang menyimpulkan sistem tidak bisa diandalkan.
- Buat panduan satu halaman per peran (pemohon, approver, admin) dengan contoh kasus nyata.
- Siapkan jam office hour singkat untuk tanya jawab, terutama bagi approver yang sibuk.
- Tentukan aturan respons dukungan, misalnya isu blocker ditangani hari yang sama.
- Publikasikan daftar kendala umum dan solusinya, diperbarui tiap minggu.
- Latih champion di tiap unit untuk membantu rekan kerja tanpa menunggu tim pusat.
Jika ada unit yang tetap memakai jalur informal, jangan langsung menghukum. Cari penyebabnya, lalu perbaiki friksi yang memicu bypass, misalnya rute persetujuan yang salah, SLA tidak realistis, atau field yang tidak relevan.
Ukur adopsi dengan metrik yang bisa ditindaklanjuti, bukan sekadar angka login
Untuk tim implementasi, metrik terbaik adalah yang langsung mengarahkan perbaikan. Jumlah pengguna aktif memberi gambaran kasar, tetapi tidak menunjukkan bagian proses yang membuat orang tersendat.
Gunakan metrik operasional: waktu siklus per jenis permintaan, persentase permintaan yang dikembalikan beserta alasannya, serta beban antrean per approver. Jika satu approver jadi bottleneck, solusinya bisa delegasi, perubahan matriks kewenangan, atau pemecahan alur berdasarkan nilai dan risiko.
Tambahkan indikator kualitas yang sederhana namun kuat, seperti kelengkapan lampiran untuk pengadaan atau konsistensi kode biaya untuk proyek. Di banyak organisasi di Indonesia, kesalahan kecil pada klasifikasi biaya bisa memicu koreksi laporan dan pertanyaan audit, sehingga perbaikan di titik input berdampak langsung pada kerja tim keuangan dan PMO.
Terakhir, lakukan review rutin yang fokus dan terbatas cakupannya. Alih-alih rapat besar yang melelahkan, cukup 30–45 menit tiap dua minggu untuk membahas tiga temuan terbesar dan tiga perubahan yang akan diuji, lalu komunikasikan hasilnya agar pengguna melihat sistem memang berkembang berdasarkan masukan mereka.
Dengan memetakan friksi, menyederhanakan desain awal, menguatkan dukungan harian, dan mengukur metrik yang tepat, resistensi biasanya turun karena pengguna merasakan manfaat yang konkret.
Jika Anda sedang menyiapkan peluncuran berikutnya, pilih satu titik friksi terbesar dan perbaiki minggu ini.
Pelajari Epruvo lebih lanjut: https://epruvo.com