Bencana Implementasi Serentak

Sebuah utilitas air daerah berencana meluncurkan sistem pembacaan meter otomatis dan aplikasi penagihan pelanggan yang baru. Tergiur potongan harga dari vendor dan ditekan kebutuhan menunjukkan hasil cepat kepada pemegang saham, manajemen memutuskan meluncurkannya serentak (big bang) di kesepuluh cabang pelayanan sekaligus, tepat pada 1 Januari. Persiapan di atas kertas dilakukan berbulan-bulan, dan pelatihan besar-besaran digelar.

Hari peluncuran tiba, dan kekacauan datang serentak pula. Aplikasi seluler pembaca meter membeku di wilayah-wilayah bersinyal lemah. Sistem penagihan pusat salah menghitung tarif progresif untuk kelas industri. Pusat panggilan (call center) kebanjiran ribuan telepon pelanggan yang marah karena tagihannya melonjak tiga kali lipat.

Direksi panik, tetapi terjebak. Karena sistem sudah digulirkan ke semua cabang sekaligus, tim TI tidak bisa mematikannya tanpa menghentikan seluruh aliran pendapatan perusahaan. Tidak ada tempat untuk mundur. Butuh enam bulan kerja lembur, audit berlapis, dan mediasi dengan perwakilan pelanggan untuk memulihkan kepercayaan publik yang telanjur retak.

Di balik “ribuan telepon” itu ada manusia. Seorang ibu pemilik warung kecil menerima tagihan tiga kali lipat yang tak sanggup ia bayar, lalu dengan panik mengantre seharian di kantor pelayanan dan meninggalkan warungnya tutup. Sistem yang dibangun untuk melayaninya justru, di pekan pertamanya, menakutinya. Dan kepercayaan, sekali retak seperti itu, jauh lebih mahal dipulihkan daripada perangkat lunak mana pun.

Saya sering memikirkan versi lain dari kisah ini. Seandainya sistem yang sama diluncurkan lebih dulu hanya di satu zona kecil, katakanlah satu kelurahan, selama sebulan. Kegagalan sinyal dan salah hitung tarif itu akan tetap terjadi, persis sama. Bedanya, korbannya tiga ratus pelanggan, bukan tiga ratus ribu. Kerusakannya menjadi bahan pembelajaran harian yang murah, bukan skandal yang masuk berita daerah. Pertanyaannya, mengapa manajemen nyaris selalu memilih cara yang pertama?

8.1 Big-Bang Adalah Pengakuan Bahwa Anda Takut Belajar

Jawabannya tidak menyenangkan. Peluncuran serentak jarang dipilih karena ia cara terbaik untuk berhasil; ia dipilih karena ia cara terbaik untuk terlihat berhasil. Satu peluncuran besar bisa difoto, diresmikan, dan dilaporkan tuntas dalam satu tanggal. Peluncuran bertahap di satu kelurahan selama sebulan tidak menghasilkan momen seremonial apa pun; ia hanya menghasilkan daftar kesalahan yang harus diperbaiki.

Tetapi ada yang lebih dalam dari sekadar gengsi seremoni. Meluncurkan semuanya sekaligus pada dasarnya adalah pernyataan bahwa Anda sudah memutuskan rencana Anda benar, dan melarang kenyataan mengoreksinya. Big-bang menutup pintu umpan balik justru pada saat Anda paling membutuhkannya. Ia bukan sekadar keputusan penjadwalan yang berisiko; ia pengakuan diam-diam bahwa organisasi lebih takut pada proses belajar yang berantakan daripada pada bencana yang rapi jadwalnya.

8.1.1 Menanggalkan Jargon, Menyimpan Polanya

Banyak eksekutif alergi begitu mendengar konsultan menyebut metodologi Agile. Bagi mereka, Agile identik dengan rapat berdiri tiap pagi, papan penuh catatan tempel, sebutan-sebutan asing seperti Scrum Master, dan budaya perusahaan rintisan yang terasa janggal diterapkan pada petugas lapangan berusia lima puluh tahun yang sehari-hari berkubang lumpur dan kunci inggris. Dan sebagian besar kecurigaan itu, sejujurnya, beralasan.

Maka tanggalkan saja seluruh jargonnya, dan simpan satu-satunya inti yang penting: memperpendek jarak antara asumsi di atas kertas dan benturannya dengan kenyataan. Anda tidak perlu menyebutnya Agile. Sebut saja “uji coba lapangan terbatas”. Daripada menyewa konsultan mahal untuk merancang sistem deteksi kebocoran yang sempurna selama setahun, lebih baik beli tiga sensor, pasang di pipa yang paling bermasalah, dan lihat apa yang terjadi pekan depan. Itulah seluruh isinya, tanpa perlu satu pun istilah asing.

8.1.2 Cermin Universal: Tidak Ada yang Menguji Obat di Seluruh Negeri

Pikirkan bagaimana sebuah obat baru sampai ke tangan kita. Tidak ada satu pun otoritas kesehatan yang waras yang akan membagikan obat yang belum teruji kepada seluruh penduduk sekaligus pada hari pertama. Obat itu diuji bertahap: mula-mula pada segelintir orang, lalu pada kelompok yang lebih besar, dengan pengawasan ketat di setiap tahap, justru supaya bila ada efek berbahaya, ia tertangkap selagi korbannya masih sedikit dan masih bisa ditolong.

Logikanya sederhana: semakin besar taruhannya bagi nyawa manusia, semakin kecil dan hati-hati uji coba pertamanya. Anehnya, banyak utilitas air justru melakukan yang sebaliknya. Mereka memasang sistem yang belum teruji kepada ratusan ribu pelanggan sekaligus, seolah perangkat lunak penagihan lebih aman daripada obat, padahal di ujung setiap tagihan yang salah hitung juga ada manusia nyata yang dirugikan. Di industri mana pun yang taruhannya tinggi, menguji dalam skala kecil lebih dulu bukanlah tanda ragu-ragu; ia tanda kedewasaan.

8.2 Penolakan Adalah Spesifikasi yang Tak Tertulis

Dalam cara pikir lama, kalau petugas lapangan tidak memakai aplikasi baru, mereka dicap “resisten terhadap perubahan” dan dikirim ke kelas motivasi. Kekeliruan ini sudah kita bongkar di bab pertama: penolakan adalah data, bukan penghalang. Dalam cara membangun yang tangkas, kebenaran itu dibalik menjadi metode kerja. Penolakan pengguna bukan gangguan yang harus diredam; ia justru spesifikasi produk yang paling berharga, spesifikasi yang tidak pernah berhasil ditulis oleh konsultan mana pun.

Sebab keluhan lapangan hampir selalu menunjuk pada kenyataan fisik yang luput dari ruang rapat ber-AC tempat sistem itu dirancang. Yang di kantor pusat terlihat seperti pembangkangan, di lapangan ternyata sekadar matahari, sarung tangan, dan sinyal yang lemah.

8.2.1 Dengarkan Pak Yanto

Ingat Pak Yanto, koordinator lapangan yang pelatihannya dulu mati di hari pertama karena ada pipa pecah. Bayangkan kali ini ia diberi aplikasi perintah kerja (work order) baru di satu cabang percobaan, dan ia membencinya. Cara pikir lama akan buru-buru menyalahkannya dan menatarnya. Cara membangun yang tangkas justru melakukan hal sebaliknya: turun menemuinya, lalu bertanya mengapa.

Dan jawabannya nyaris tak pernah soal “menolak teknologi”. Layar aplikasi itu memantulkan silau matahari sampai tak terbaca di siang bolong. Tombolnya terlalu kecil untuk ditekan jari yang terbungkus sarung tangan kerja yang tebal dan berlumpur. Tidak ada satu pun keluhan itu yang muncul di dokumen kebutuhan yang disusun di kantor pusat, sebab tidak ada satu pun perancangnya yang pernah berdiri di bawah terik memakai sarung tangan Pak Yanto. Keluhan-keluhan itulah spesifikasi yang sebenarnya. Sistem yang hebat tidak lahir di ruang ber-AC; ia ditempa oleh gesekan-gesekan kecil di lapangan yang memaksa perancang menyesuaikan diri dengan tubuh dan dunia nyata penggunanya.

8.2.2 Iterasi Adalah Manajemen Perubahan Termurah

Pola “agile berbaju lumpur” ini menyimpan satu efek samping yang jauh lebih besar daripada sekadar menangkap kesalahan lebih awal. Ketika manajemen berani merilis sistem setengah jadi di satu wilayah, lalu benar-benar mendengar keluhan Pak Yanto dan memperbaikinya bulan depan, sesuatu berubah di dalam diri Pak Yanto. Ia berhenti memandang sistem itu sebagai “beban titipan dari pusat”, dan mulai merasa ikut memilikinya.

Inilah bentuk manajemen perubahan yang paling dalam sekaligus paling murah: ia tumbuh bukan lewat pidato penyemangat atau pelatihan berhari-hari di dalam kelas, melainkan lewat keterlibatan yang nyata. Ketika seorang petugas melihat keluhannya sendiri berubah menjadi perbaikan fitur, ia menjelma dari penolak pasif menjadi pembela paling gigih sistem itu di hadapan rekan-rekannya. Dan rasa memiliki itu, ternyata, adalah benih dari satu-satunya hal yang membuat sebuah transformasi sanggup bertahan hidup lama setelah seremoni peluncurannya berlalu.

Kalau hanya tiga hal yang layak Anda bawa dari bab ini:

  • Peluncuran serentak bukan keputusan jadwal, melainkan pengakuan bahwa Anda takut belajar. Ia dipilih karena bisa difoto, padahal ia menutup pintu umpan balik tepat ketika Anda paling membutuhkannya.
  • Tujuan sebuah pilot bukan untuk berhasil, melainkan untuk gagal dengan murah. Uji di satu kelurahan dulu: kesalahannya tetap terjadi, tetapi korbannya tiga ratus, bukan tiga ratus ribu. Semakin tinggi taruhannya, semakin kecil uji coba pertamanya.
  • Penolakan lapangan adalah spesifikasi yang tak tertulis. Silau layar dan tombol yang terlalu kecil untuk sarung tangan Pak Yanto adalah kebutuhan sebenarnya yang tak pernah ditulis konsultan. Mendengarnya lalu memperbaikinya adalah manajemen perubahan termurah, sebab ia menumbuhkan rasa memiliki.

Jurus: Uji Kecil Dulu, Dengarkan Lapangan

Kapan dipakai: saat hendak meluncurkan sistem baru ke banyak wilayah atau banyak pelanggan sekaligus.

  1. Haramkan peluncuran serentak. Luncurkan dulu di satu zona terkecil selama sebulan. Tujuannya bukan agar berhasil, melainkan agar gagal dengan murah, dengan korban tiga ratus pelanggan, bukan tiga ratus ribu.
  2. Tanggalkan jargonnya, simpan intinya: perpendek jarak antara asumsi di atas kertas dan benturannya dengan kenyataan. Sebut saja “uji coba lapangan terbatas”.
  3. Perlakukan keluhan lapangan sebagai spesifikasi yang sebenarnya. Turun temui petugas yang menolak, perbaiki keluhannya (silau layar, tombol yang terlalu kecil untuk sarung tangan), lalu tunjukkan perbaikan itu bulan berikutnya.

Rambu: ketika seorang petugas melihat keluhannya berubah menjadi perbaikan fitur, ia bertransformasi dari penolak menjadi pembela. Itulah manajemen perubahan termurah, sekaligus benih ketahanan.

Rasa memiliki itulah jembatan menuju pertanyaan terakhir buku ini. Sistem yang dibela oleh Pak Yanto dan rekan-rekannya akan jauh lebih tangguh daripada sistem yang dipaksakan dari atas. Tetapi rasa memiliki satu orang pun masih rapuh. Bagaimana caranya agar api perubahan ini tidak padam ketika proyeknya selesai, ketika anggarannya habis, dan ketika sang penjaganya pensiun? Bagaimana membuat transformasi bertahan tanpa bergantung pada satu pahlawan tunggal? Itulah yang kita tuju di bab penutup.

Penafian: Tulisan ini adalah pandangan pribadi penulis berdasarkan pengalaman praktis dan studi independen. Studi kasus di atas merupakan komposit pembelajaran dan tidak menunjuk pada satu entitas spesifik. Pembaca diharapkan melakukan verifikasi independen sebelum mengimplementasikan rekomendasi apa pun dalam lingkungan operasional masing-masing.