Bab 1: Sindrom Beli Solusi

Wajah pertama dari tesis yang sama: kalau sistemnya semahal itu, kenapa orang lapangan diam-diam kembali ke buku tulis?

Server Miliaran yang Berdebu

Saya sudah cukup lama hidup di depan basis data untuk mempelajari satu hal yang tidak nyaman: layar yang paling mahal sekalipun bisa berdusta dengan cara yang paling meyakinkan. Cerita berikut bukan tentang satu utilitas tertentu, melainkan pola yang berulang dengan wajah yang nyaris selalu sama.

Di sebuah utilitas air skala menengah, jajaran Direksi memutuskan sudah saatnya perusahaan go digital. Anggaran miliaran rupiah untuk proyek ini disiapkan dan dikawal bertahun-tahun melalui rencana kerja dan anggaran perusahaan (RKAP), melewati berlapis kajian kelayakan, dan akhirnya disetujui dengan penuh keyakinan oleh Direksi dan dewan pengawas. Proyeknya terdengar luar biasa di atas kertas: sistem kendali Supervisory Control and Data Acquisition (SCADA) terintegrasi yang akan disambungkan langsung dengan sistem penagihan (billing system) terbaru. Targetnya adalah dasbor eksekutif (executive dashboard) yang menunjukkan kehilangan air (Non-Revenue Water) secara seketika (real-time). Pemenang tendernya adalah vendor teknologi multinasional.

Enam bulan kemudian, layar besar di ruang kontrol menyala terang. Lampu-lampu server berkedip. Pemotongan pita dilakukan oleh Kepala Daerah. Namun, jika Anda datang lagi satu tahun setelah perayaan tersebut, Anda akan melihat pemandangan yang berbeda.

Layar besar itu sering kali dimatikan untuk menghemat listrik. Angka yang muncul di dasbor tidak pernah sama dengan laporan yang dicetak oleh bagian keuangan. Ketika ditelusuri, para petugas baca meter di lapangan ternyata masih mencatat menggunakan kertas, lalu menyalinnya ke Microsoft Excel sebelum memindahkannya ke sistem baru. Mengapa? Karena sistem baru tersebut tidak mengizinkan koreksi angka secara manual, sementara di lapangan, meteran sering kali tertimbun lumpur atau rusak, sehingga petugas harus memasukkan angka taksiran. Jika mereka salah memasukkan angka di sistem baru, proses pembatalan (void) membutuhkan persetujuan berjenjang hingga manajer keuangan, sebuah birokrasi yang memakan waktu tiga hari. Untuk menghindari omelan atasan, mereka kembali ke cara lama yang aman dan tersembunyi: Excel.

Sistem miliaran rupiah itu akhirnya hanya menjadi hiasan ruang tamu, mati oleh gesekan kecil di lapangan yang tidak pernah dipikirkan oleh para pembuat cetak biru. Dan berkas Excel yang mereka kembali pakai itu bukan tanda kemalasan. Ia satu-satunya tempat angka sebenarnya milik perusahaan itu masih hidup. Ruang kontrol semacam itu mudah dijumpai di sektor utilitas air: layar yang indah namun keliru, sementara kebenaran tentang operasional justru tersimpan di buku tulis seorang petugas yang namanya bahkan tidak ada di daftar undangan peresmian.

Saya sering kembali memikirkan buku tulis itu. Kita sanggup membayar miliaran untuk sebuah layar, lalu kebenaran tentang air yang diminum manusia bertahan di sudut halaman yang melengkung, di tangan orang yang tidak diundang ke perayaannya sendiri. Barangkali di situlah pelajaran pertama yang paling sunyi: dalam sebuah transformasi, yang paling benar sering kali justru yang paling tidak terlihat.

1.1 Anatomi Organisasi: Mesin yang Punya Pendapat

Kesalahan paling mahal dalam sebuah transformasi tidak terletak pada pilihan teknologinya, melainkan pada satu asumsi diam-diam: bahwa organisasi bisa diperbaiki seperti mesin. Lepas komponen yang rusak, pasang yang baru, nyalakan kembali.

Masalahnya, sebuah mesin tidak punya pendapat tentang penggantian dirinya. Karburator tidak bersekongkol di grup percakapan. Sedangkan di organisasi, komponen yang hendak Anda ganti adalah satu-satunya pihak yang benar-benar tahu bagaimana mesin itu berjalan selama ini. Anda bisa me-reboot sebuah server; Anda tidak bisa me-reboot sebuah kebiasaan. Dan kebiasaan itu, yang dari luar tampak seperti kekakuan, sebenarnya adalah memori: rekaman dari setiap pengecualian yang pernah membuat layanan tetap hidup.

1.1.1 Mitos Mendesain Ulang dari Nol

Ada satu godaan yang nyaris tak tertahankan bagi manajemen: mendesain ulang seluruh cara kerja di atas kertas kosong. Godaan ini kuat bukan karena ia praktis, melainkan karena ia membebaskan. Di atas kertas kosong, Anda merancang untuk organisasi yang Anda idamkan, bukan organisasi yang Anda miliki. Proses yang bersih, tanpa pengecualian, tanpa orang yang membantah.

Tetapi pengecualian-pengecualian yang ingin Anda hapus itu bukan kotoran. Mereka tambalan. Setiap langkah ganjil dalam prosedur lama, mengapa pembacaan meter di satu zona harus diverifikasi dua kali, mengapa penghapusan tagihan butuh tanda tangan basah, biasanya lahir dari sebuah insiden nyata yang pernah merugikan organisasi. Prosedur yang berantakan adalah catatan luka. Semakin berantakan ia terlihat, semakin banyak luka yang dikandungnya, dan justru semakin berbahaya membersihkannya dengan satu sapuan.

Di sinilah tikungan yang jarang disadari: semakin kotor sebuah proses manual, semakin besar risiko sebuah desain ulang yang bersih. Sebab yang Anda buang bukan inefisiensi, melainkan pengetahuan mahal yang tak pernah sempat dituliskan.

Anda mungkin membantah: bukankah ada proses yang memang sudah rusak dan layak dibuang? Tentu ada. Tetapi Anda hanya bisa tahu yang mana dengan menelusuri mengapa setiap tambalan itu ada, satu per satu, bukan dengan mengasumsikan semuanya sampah karena terlihat jelek di diagram.

Selama puluhan tahun, ada satu alibi yang membuat desain ulang dari nol terasa wajar: perangkat lunak itu mahal dan kaku, jadi manusialah yang harus dibengkokkan agar muat ke dalamnya. Alibi itu kini mulai kehilangan dasarnya, meski belum merata. Yang menggesernya adalah kematangan kecerdasan buatan: perangkat lunak generasi baru kian sanggup belajar dari cara kerja nyata dan menyesuaikan diri dengan konteks pemakainya, alih-alih menuntut manusia menghafal konfigurasi yang kaku. Pergeseran ini masih terasa di tepi, belum di ruang server utilitas air yang anggarannya cekak dan talentanya tipis. Tetapi arahnya sudah jelas: ketika alat semakin lentur untuk belajar dari cara kerja nyata di lapangan, memaksa lapangan menyesuaikan diri ke cetak biru bukan lagi semata keterbatasan teknologi. Ia makin menjadi pilihan. Dan pilihan, tidak seperti keterbatasan, harus dipertanggungjawabkan.

1.1.2 Resistensi adalah Sinyal, Bukan Penyakit

Salah satu dari petugas yang kembali ke Excel di awal bab tadi punya nama. Sebut saja Pak Rahmat. Dua puluh tujuh tahun ia menyusuri gang yang sama, dan ia hafal hal-hal yang tidak pernah masuk ke sistem mana pun: meteran di rumah ujung yang selalu macet tiap kemarau, keluarga di nomor sembilan yang menunggak bukan karena nakal tetapi karena anaknya sakit, dan satu sambungan gelap di belakang warung yang tiap tahun ia laporkan dan tiap tahun diabaikan. Ketika sistem baru datang, Pak Rahmat tidak menolak dengan suara keras. Ia hanya, suatu sore, kembali membuka buku tulisnya yang sudutnya sudah melengkung, dan mencatat di situ seperti dulu.

Di ruang rapat, perilaku Pak Rahmat punya nama yang tidak enak didengar: resistensi, penolakan, sistem imun organisasi yang menolak segala yang baru. Reaksi standar manajemen adalah memperlakukannya sebagai hambatan yang harus dipatahkan. Dan di situlah jebakan yang halus: dari ujung meja rapat, mudah sekali melihat orang-orang seperti Pak Rahmat hanya sebagai penghambat proyek, bukan sebagai manusia yang sedang berusaha memberi tahu sesuatu.

Membalik cara memandangnya tidak pernah mudah. Resistensi Pak Rahmat bukan hambatan. Ia alat ukur. Ketika ia kembali ke buku tulisnya, ia sedang melaporkan, dengan satu-satunya cara yang ia punya, bahwa sistem mahal itu meminta sesuatu yang tidak cocok dengan kenyataan di gangnya. Buku tulis lusuh itu, bukan dasbor di ruang kontrol, adalah peta paling akurat yang dimiliki perusahaan tentang dirinya sendiri. Dan organisasi membayar miliaran untuk menghancurkannya, lalu heran mengapa angka di layar berdusta.

Inilah inti dari satu kalimat berbahaya yang sering terdengar di ruang rapat: bahwa pengguna harus dipaksa berubah. Begitu sebuah sistem hanya bisa berjalan dengan memaksa Pak Rahmat, ia sudah memberi tahu kita bahwa dirinyalah yang salah rancang. Paksaan bukan obat bagi resistensi; ia cara membungkam sinyal, lalu menyebut alat ukur yang rusak itu sebagai keberhasilan.

Namun di sini seorang praktisi berpengalaman berhak curiga, dan kecurigaannya benar: tidak semua penolakan sejujur penolakan Pak Rahmat. Ingat sambungan gelap di belakang warung tadi. Orang yang menikmati sambungan itu juga akan menolak sistem baru, mungkin sekeras Pak Rahmat, tetapi karena alasan yang berkebalikan: transparansi mengancam keuntungannya. Petugas yang menolak meter otomatis karena cara manual memberinya ruang menerima amplop berdiri di gang yang sama dengan Pak Rahmat. Menyamakan dua penolakan ini adalah cara membela yang tidak pantas dibela, dan di situlah analisis yang dangkal berubah menjadi tameng bagi yang curang.

Pembedanya sederhana dan bisa diuji. Sinyal akan mereda begitu sistem diperbaiki; sabotase justru mengeras begitu sistem makin benar. Perbaiki alur agar cocok dengan kenyataan, dan penolakan Pak Rahmat akan surut, sebab keluhannya memang soal desain. Tetapi makin benar sistemnya, makin nyaring perlawanan dari orang di balik warung, sebab yang ia pertahankan bukan cara kerja, melainkan celah. Yang pertama menuntut Anda mendengar. Yang kedua menuntut Anda menegakkan. Membedakan keduanya adalah pekerjaan kepemimpinan yang tidak bisa didelegasikan ke vendor mana pun. Pembeda yang dapat diuji itu dapat diringkas menjadi satu alat diagnostik (Tabel 1.1).

Tabel 1.1 Membedakan penolakan yang harus didengar dari yang harus ditegakkan

Dan kalau Anda butuh alasan mengapa pembedaan ini penting, ia tidak muncul di dasbor yang saya urus. Justru sebaliknya: dasbor itu menyembunyikannya. Tekanan di zona tujuh tampak hijau dan sehat di layar saya, padahal di tumpukan keluhan pelanggan yang masuk ke sistem, zona yang sama muncul berulang kali. Butuh waktu bagi saya, orang yang sehari-hari hidup di depan basis data dan jarang menginjak gang-gang itu, untuk berhenti menutup keluhan-keluhan tersebut sebagai “tidak ada gangguan sistem” dan mulai bertanya siapa manusia di balik setiap tiket. Salah satunya, kata Pak Rahmat, seorang ibu yang harus bangun pukul empat subuh mengantre dengan jeriken. Air yang terlihat baik-baik saja di layar saya tidak pernah benar-benar sampai ke krannya. Kalau kami salah membaca Pak Rahmat, yang membayar bukan proyek kami. Yang membayar adalah ibu itu. Di situ saya mengerti bahwa urusan ini tidak pernah benar-benar soal data atau dasbor: di ujung setiap pipa yang salah kelola, selalu ada seseorang yang tidak kebagian air.

1.1.3 Cermin Universal: Catatan yang Disembunyikan

Pola ini melampaui dunia air. Di sebuah rumah sakit yang memasang rekam medis elektronik (Electronic Medical Record), seorang perawat di bangsal yang penuh tetap menyimpan catatan kertas kecil di saku jas. Manajemen menganggapnya pembangkangan terhadap investasi mahal. Padahal kertas itu ada karena sistem elektroniknya menuntut urutan input yang tidak cocok dengan ritme bangsal saat pasien gawat datang bertubi-tubi. Catatan saku itulah rekam medis yang sebenarnya dipakai untuk mengambil keputusan; layar komputer baru diisi belakangan, kadang dari ingatan, kadang asal lengkap. Sistem yang dibeli untuk meningkatkan akurasi justru melahirkan dua versi kebenaran, dan versi yang resmi adalah yang paling tidak dapat dipercaya. Di mana pun manusia menyembunyikan catatan tandingan, di situ ada sistem yang gagal mendengar lapangan, dan ada Pak Rahmat lain yang sedang mencoba memberi tahu kita sesuatu.

Pola ini sebenarnya hadiah bagi siapa pun yang mau jujur menilai transformasinya sendiri. Kalau Anda ingin tahu apakah sistem baru benar-benar dipakai atau sekadar diisi demi laporan, jangan bertanya kepada vendor dan jangan menatap dasbor. Carilah catatan bayangannya. Tanyakan di mana orang menyimpan versi “yang sebenarnya”: buku tulis, berkas Excel pribadi, grup percakapan, coretan di balik struk. Keberadaan catatan tandingan itu adalah pengukur paling jujur tentang seberapa jauh sistem resmi Anda menyimpang dari kenyataan. Semakin rapi catatan bayangan itu, semakin lebar jurang yang sedang Anda tutup-tutupi dari diri sendiri.

1.2 Mengapa Sindrom Ini Tak Kunjung Berhenti

Ada satu pertanyaan yang lama mengganggu saya, dan ia kembali setiap kali sebuah server baru diresmikan. Kalau pola ini begitu mudah dikenali, begitu sering berulang, mengapa ia tak kunjung berhenti?

Jawaban yang gampang diucapkan: karena manajemen tidak belajar. Jawaban yang lebih jujur, dan lebih tidak nyaman, berbeda: karena membeli kotak adalah satu-satunya bentuk “transformasi” yang bisa dilihat dan dihitung oleh auditor dan politisi dalam satu tahun anggaran.

Sebuah kebiasaan yang berubah tidak bisa difoto. Konflik antar-divisi yang berhasil didamaikan tidak muncul di laporan realisasi. Sedangkan server baru bisa difoto saat peresmian, lisensi bisa dihitung jumlahnya, dan kontrak bisa dilaporkan terserap. Sistem penilaian hanya menghargai yang kasatmata. Maka sindrom beli solusi bukan kebodohan kolektif; ia keluaran rasional dari sebuah rezim pengukuran yang salah menatap sasaran. Dan di rezim semacam itu, sebuah aplikasi sering dibeli bukan sebagai alat, melainkan sebagai alibi: bukti fisik bahwa “kami sudah bertindak”, yang bisa ditunjukkan kepada siapa pun yang kelak bertanya. Alat dinilai dari hasilnya; alibi cukup dinilai dari keberadaannya. Itulah mengapa begitu banyak sistem tetap dianggap sukses justru ketika tidak seorang pun memakainya.

Dan Direktur yang meneken proyek itu bukan biang keladinya. Betapa kerasnya mereka terjepit di dalam rezim regulasi yang kaku sering luput dari penilaian orang luar. Seorang direktur utilitas publik akan ditegur keras atau bahkan diusut jika anggaran tidak terserap atau salah prosedur pengadaan, tetapi ia hampir tidak pernah ditegur kalau sistem yang dibeli itu mangkrak diam-diam setahun kemudian dengan alasan “kurangnya kesiapan SDM”. Selama itulah metrik keberhasilan birokrasi, orang paling rasional dan brilian sekalipun akan memilih proyek yang cepat, aman, dan bisa difoto. Persoalannya bukan mencari kambing hitam individual, melainkan menyadari bahwa kita semua (termasuk Pak Rahmat, saya, dan eksekutif BUMD) sedang dinilai dengan penggaris insentif yang keliru.

1.2.1 Yang Terukur Mengalahkan yang Penting

Ada turunan yang lebih keras dari logika ini, yaitu tekanan kalender keuangan, dan kita akan membongkarnya tuntas di bab tersendiri. Cukup dicatat di sini: ketika kecepatan membelanjakan uang lebih mudah diukur daripada ketepatan memecahkan masalah, organisasi akan selalu memilih yang terukur. Mengedukasi petugas dan merapikan data kotor memakan waktu berbulan-bulan dan tidak terlihat gagah di laporan akhir tahun. Membeli lisensi selesai dalam sepekan. Insting birokrasi tahu persis mana di antara keduanya yang menyelamatkan karier seseorang.

Inilah juga asal-usul fenomena yang akrab di banyak utilitas: tumpukan sistem yang dibeli tetapi tak pernah benar-benar dipakai. Lisensi yang diperpanjang otomatis tiap tahun, server yang menyala tanpa beban berarti, aplikasi yang tercantum di daftar aset tetapi tidak di layar siapa pun. Dalam logika serapan, sistem-sistem itu bukan kegagalan; mereka justru sukses, sebab peristiwa yang diukur adalah pembeliannya, bukan pemakaiannya. Organisasi membayar untuk memilikinya, lalu tidak pernah ditagih untuk benar-benar menggunakannya.

1.2.2 Mengotomasi Kekacauan

Sindrom ini bermuara pada satu kekeliruan yang mematikan: keyakinan bahwa mengotomasi sebuah proses akan merapikannya. Jika proses manual Anda berantakan, memasukkannya ke komputer tidak akan menyelesaikannya.

Tetapi alasannya bukan sekadar “komputer mengeksekusi kesalahan lebih cepat”, seperti yang biasa dikatakan. Alasannya lebih dalam. Proses manual yang berantakan itu, pada kenyataannya, ditahan oleh ribuan keputusan kecil yang tak tercatat. Pengetahuan Pak Rahmat tentang meteran yang macet tiap kemarau dan tentang keluarga di nomor sembilan adalah keputusan-keputusan semacam itu. Begitu pula staf penagihan yang tahu pelanggan industri mana yang harus ditelepon dulu sebelum salurannya diputus, karena memutusnya berarti menghentikan satu pabrik dan mengundang surat dari pengacara. Kekacauan itu adalah tempat kebijaksanaan manusia bekerja.

Ketika Anda mendigitalkannya tanpa memahaminya, Anda tidak mengotomasi proses. Anda mengamputasi kebijaksanaan itu, lalu menggantinya dengan aturan kaku yang tidak tahu apa yang diketahui Pak Rahmat. Lebih jauh lagi: digitalisasi membekukan kekacauan. Selama manual, sebuah kekeliruan masih bisa dinegosiasikan setiap hari oleh manusia yang memakai akal sehat. Begitu dikodekan ke dalam sistem, ruang akal sehat itu menyempit, dan yang tersisa adalah kesalahan yang permanen sekaligus tampak resmi. Angka yang keliru, setelah masuk basis data (database), berhenti dipertanyakan justru karena ia kini muncul dari layar, bukan dari mulut orang.

1.3 Keluar dari Perangkap Cetak Biru

Langkah pertama keluar dari perangkap ini bukan memilih teknologi yang lebih baik, melainkan mengubah peran yang Anda mainkan. Berhentilah berlagak seperti perakit mesin yang memasang komponen, dan mulailah bekerja seperti perawat kebun yang membentuk ekosistem. Kebun tidak dibangun dengan paksaan. Ia dibentuk lewat iterasi, pencahayaan yang tepat, dan pemangkasan yang sabar.

Secara praktis, peran itu menjelma menjadi beberapa pertanyaan yang wajib Anda ajukan sebelum meneken proyek apa pun, jauh sebelum bicara merek atau anggaran. Workaround apa yang akan dihapus oleh sistem ini, dan mengapa ia dulu muncul? Siapa yang akan menanggung selisih antara konteks vendor dan konteks kita, dan apakah ia ikut duduk saat keputusan diambil? Lalu, kalau nanti lapangan menolak, sudahkah kita tahu cara membedakan penolakan yang harus didengar dari yang harus ditegakkan? Jika ketiganya belum terjawab, yang dibeli belum tentu sebuah solusi; bisa jadi ia baru sebuah kotak.

Tetapi ada satu syarat yang tidak bisa ditawar, dan justru di situ banyak utilitas tersandung lebih dulu: seorang tukang kebun butuh waktu. Anda tidak bisa merawat ekosistem dengan tim yang setiap jam kerjanya sudah habis untuk memadamkan api. Di sinilah pembunuh transformasi yang berikutnya menunggu, dan ia bukan penolakan yang gaduh, melainkan kelelahan yang sunyi dari orang-orang yang terlalu sibuk menjaga sistem lama tetap hidup untuk sempat memikirkan yang baru.

Kalau ada tiga hal yang ingin saya titipkan dari bab ini:

• Resistensi adalah data, bukan penghalang. Ketika lapangan menolak sistem baru, mereka sedang melaporkan cacat pada peta kita tentang organisasi kita sendiri. Itu informasi termahal yang justru paling ingin kita bungkam.
• Kekacauan manual sering kali kecerdasan yang menyamar. Proses yang terlihat berantakan ditahan oleh ribuan keputusan kecil manusia. Mengotomasinya tanpa memahaminya berarti mengamputasi kebijaksanaan yang selama ini menanggung beban.
• Bahayanya bukan beli-atau-bangun, melainkan mengadopsi konteks orang lain secara buta. Solusi jadi membawa konteks orang lain; selisihnya dengan konteks kita tidak hilang, hanya berpindah menjadi beban diam-diam yang dibayar petugas di lapangan. Membangun sendiri pun sama berbahayanya bila pengetahuannya menumpuk di satu kepala, sebagaimana akan kita lihat di bab penutup.

[!TIP] Executive Toolkit: Filter Anti-Jebakan (Bab 1) Tiga pertanyaan yang biasa saya bawa, diam-diam, ke ruang rapat sebelum sebuah sistem baru diteken untuk “menyelesaikan” masalah operasional.

1. Audit Catatan Bayangan: Sebelum bicara merek atau anggaran, mintalah tim pengusul membawa tiga contoh proses manual (workaround) yang dilakukan lapangan saat ini (berkas Excel, buku tulis, coretan kertas). Jika jawabannya “semuanya lancar di atas kertas”, justru di situlah tanda paling jelas bahwa pengusulnya belum benar-benar menengok lapangan.
2. Identifikasi ‘Korban’ Konteks: Cari nama satu orang staf lapangan yang akan paling menderita (bottleneck) jika aplikasi dari vendor ini tidak cocok dengan realitas kerjanya, lalu pastikan ia ikut duduk dan menilai demo vendor. Sebab pada akhirnya, dialah yang akan menanggung selisihnya, jauh setelah kita semua pulang dari rapat.
3. Protokol Resistensi: Sepakati lebih dulu, sebelum proyek dimulai: kalau bulan depan muncul penolakan masif di lapangan, akankah kita merevisi software-nya agar sesuai dengan kerja mereka, atau menghukum pegawai yang menolak? Memilih jalan kedua berarti membeli masalah baru, bukan solusi.

Ingat alibi lama yang kita bongkar di awal bab: perangkat lunak terlalu mahal dan kaku, jadi manusialah yang harus dibengkokkan agar muat ke dalamnya. Alibi itu kini mulai luntur. Untuk pertama kalinya, alatnya sendiri yang belajar menyesuaikan diri dengan cara kerja manusia, bukan manusia yang dipaksa menekuk diri ke alat. Tetapi kelenturan itu tidak ada gunanya bila orang yang harus memandunya tak punya satu jam pun untuk berpikir. Pak Rahmat masih menunggu sistem yang mau mendengarnya, dan ibu di zona tujuh masih menunggu airnya. Keduanya tidak akan terlayani oleh tim yang kehabisan napas. Maka sebelum bicara teknologi yang melayani konteks, ada satu hal yang lebih dulu harus kita pulihkan: ruang bernapas yang membuat konteks itu bisa terbaca sama sekali. Ke sanalah kita melangkah berikutnya.

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 utilitas air spesifik. Pembaca diharapkan melakukan verifikasi independen sebelum mengimplementasikan rekomendasi apa pun dalam lingkungan operasional masing-masing.