Wajah kedelapan dari tesis yang sama: kenapa peluncuran serentak yang paling percaya diri justru yang paling rapuh?
Bencana Implementasi Serentak
Sebuah kemitraan BUMD air minum daerah berencana meluncurkan sistem pembacaan meter otomatis dan aplikasi penagihan pelanggan yang baru. Tergiur oleh iming-iming “efisiensi instan” dari vendor dan ditekan oleh tingginya ekspektasi Kepala Daerah serta pemegang saham publik, manajemen memutuskan meluncurkannya serentak (big bang) di kesepuluh cabang pelayanan sekaligus, tepat pada 1 Januari. Pola ilusi ini berulang di banyak organisasi: persiapan di atas kertas dilakukan berbulan-bulan seolah itu menjamin keberhasilan lapangan, dan pelatihan massal digelar sekadar menggugurkan kewajiban administratif.
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: Ketika Kita Memilih Tak Belajar Dulu
Jawabannya tidak menyenangkan, tetapi sangat rasional dari kacamata struktural. Direksi yang memilih peluncuran serentak bukanlah pemimpin yang buruk atau gila hormat; mereka adalah eksekutif yang terjepit ekspektasi pemegang saham/Pemda. Peluncuran serentak dipilih karena ia satu-satunya cara “terlihat berhasil” di atas kalender pelaporan anggaran. Satu peluncuran besar bisa difoto, diresmikan, dan diklaim sebagai pencapaian KPI akhir tahun. Sebaliknya, peluncuran bertahap di satu kelurahan tidak menghasilkan momen seremonial politik apa pun; ia justru menghasilkan daftar keluhan teknis yang membuat Direksi diomeli oleh dewan pengawas.
Tetapi ada harga mahal yang dibayar dari menghindari teguran tersebut. Meluncurkan semuanya sekaligus pada dasarnya berarti menganggap desain awal sudah sempurna, dan menutup pintu bagi kenyataan lapangan untuk mengoreksinya. Pendekatan big-bang menutup pintu umpan balik justru pada saat sistem paling membutuhkannya. Ini bukan kelemahan individu, melainkan patologi ekosistem tata kelola kita: organisasi publik sering kali lebih takut pada proses trial and error yang terlihat berantakan daripada pada bencana operasional massal yang rapi jadwal peresmiannya.
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 eksternal 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.
8.3 Lulus di Atas Kertas, Gagal Saat Dibutuhkan
Sebelum menutup bab ini, ada satu jebakan terakhir yang harus disebut, karena ia bisa menelan bahkan organisasi yang sudah patuh menguji bertahap: pengujian itu sendiri bisa menjadi pentas. Bayangkan pola yang berulang di banyak lembaga: sebuah sistem dinyatakan berhasil diimplementasikan. Berita acara serah terima ditandatangani, daftar hadir pelatihan lengkap, dokumentasi prosedur rapi, indikator di laporan proyek semuanya hijau. Dua belas bulan kemudian server terganggu, dan ketika tim diminta menjalankan prosedur pemulihan, tidak ada yang sanggup. Prosedurnya ada; tidak pernah ada yang mempraktikkannya. Pelatihannya terlaksana; yang hadir justru staf yang sudah bisa, bukan yang seharusnya belajar. Semua artefak keberhasilan hadir. Keberhasilannya sendiri tidak.
Akar masalahnya sama dengan yang membuat peluncuran serentak begitu menggoda: sistem evaluasi yang menilai apa yang mudah difoto. “Sistem sudah go-live”, “dokumentasi sudah lengkap”, “pelatihan sudah berjalan”, semuanya adalah ukuran keberadaan artefak, bukan ukuran kondisi. Dan organisasi mana pun yang rasional akan mengoptimalkan apa yang diukur darinya: kalau yang diperiksa adalah dokumen, maka dokumenlah yang dirapikan menjelang pemeriksaan, bukan kemampuan orang menghadapi hari buruk. Tidak perlu ada niat menipu; jadwal audit yang selalu bisa diantisipasi dan kriteria yang tidak pernah berubah sudah cukup untuk melahirkan kepatuhan panggung.
Penangkalnya satu garis lurus dengan seluruh isi bab ini: paksa sistem Anda bertemu kenyataan dalam kondisi yang tidak sempat ia dandani. Ganti kriteria keberhasilan dari artefak ke kondisi; “80 persen pengguna menyelesaikan transaksi inti tanpa panduan setelah 30 hari operasi” adalah ukuran, sedangkan “aplikasi sudah diluncurkan” hanyalah tanggal. Sisipkan setidaknya satu pemeriksaan yang tidak terjadwal dalam siklus proyek, sebab kesiapan yang hanya muncul saat pemeriksaan diumumkan bukanlah kesiapan. Dan bandingkan laporan tim proyek dengan kesaksian pihak yang tidak berkepentingan atas laporan itu, terutama pengguna akhir; merekalah yang paling tahu mana yang benar-benar berfungsi dan mana yang hanya hidup di dokumen. Desain evaluasi dan auditnya secara teknis kami bahas di buku kedua seri ini, IT Governance Playbook. Prinsipnya yang perlu menetap di kepala: uji coba terbatas melindungi Anda dari kegagalan yang mahal, tetapi hanya kejujuran pengukuran yang melindungi Anda dari keberhasilan yang palsu. Tabel 8.1 menyandingkan kedua pendekatan ini.
| Aspek | Peluncuran serentak (big-bang) | Uji coba lapangan terbatas (iteratif) |
|---|---|---|
| Daya tarik | Bisa difoto, seremonial, klaim KPI akhir tahun | Tanpa momen seremonial; menghasilkan daftar keluhan |
| Umpan balik | Tertutup justru saat paling dibutuhkan | Penolakan lapangan menjadi spesifikasi tak tertulis |
| Skala kegagalan | Korban tiga ratus ribu, menjadi skandal | Korban tiga ratus, menjadi pelajaran murah |
| Kemampuan mundur | Tidak ada; mematikan sistem berarti menghentikan pendapatan | Bisa dihentikan atau diperbaiki tiap dua pekan |
| Efek pada pengguna | Kepercayaan retak, mahal dipulihkan | Rasa memiliki tumbuh (manajemen perubahan termurah) |
| Ukuran sukses | Artefak: “sudah go-live”, “pelatihan selesai” | Kondisi: “80% selesai transaksi inti tanpa panduan setelah 30 hari” |
Tabel 8.1 Peluncuran serentak versus uji coba terbatas: mengapa gagal murah mengalahkan sukses yang ditunda
Kalau ada tiga hal yang ingin saya titipkan dari bab ini:
- Peluncuran serentak bukan keputusan jadwal, melainkan cara menghindari belajar dari kenyataan. Ia dipilih karena bisa difoto, padahal ia menutup pintu umpan balik tepat ketika ia paling dibutuhkan.
- 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.
[!TIP] Executive Toolkit: Protokol “Agile” Berbaju Lumpur (Bab 8) Gunakan kerangka ini saat vendor IT atau konsultan mengusulkan “Grand Launching” atau peluncuran sistem secara serentak.
- Veto “Grand Launching”: Haramkan peluncuran big-bang. Wajibkan setiap vendor melakukan “Uji Coba Lapangan Terbatas” di satu zona operasional terkecil selama 30 hari pertama. Tujuannya bukan untuk sukses, melainkan untuk gagal dengan murah. Lebih baik mengacaukan tagihan 300 pelanggan daripada 300.000 pelanggan.
- Buang Kosakata ‘Agile’: Jangan bawa istilah Scrum, Sprint, atau Agile ke utilitas publik; itu sering hanya memicu resistensi budaya. Sebut saja “Piloting”, “Uji Coba Bersama”, atau “Penyempurnaan Berjalan”. Yang penting intinya jalan: perbaiki sistem setiap 2 minggu berdasarkan komplain riil dari lapangan.
- Ubah Komplain Menjadi Fitur: Ketika petugas lapangan (seperti Pak Yanto) menolak memakai aplikasi karena “layarnya silau di siang bolong” atau “tombolnya kecil saat pakai sarung tangan tebal”, jangan kirim dia ke kelas motivasi/disiplin. Catat itu sebagai Spesifikasi Sistem. Perbaiki aplikasinya bulan depan, dan tunjukkan kepadanya. Saat ia melihat sistem tunduk pada kebutuhan nyatanya, ia akan berubah dari penolak pasif menjadi advokat paling gigih di wilayahnya.
- Ukur Kondisi, Bukan Artefak: Tolak kriteria keberhasilan berbentuk “sistem sudah go-live” atau “pelatihan sudah terlaksana”. Ganti dengan ukuran kondisi: berapa persen pengguna sanggup menyelesaikan transaksi inti tanpa panduan setelah 30 hari? Sisipkan minimal satu pemeriksaan tak terjadwal, dan dengarkan pengguna akhir di luar laporan tim proyek; kesiapan yang hanya muncul saat diperiksa bukanlah kesiapan.
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 akan dibahas di Bab 9.
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.