Bab 3: Anatomi Stakeholder

Wajah ketiga dari tesis yang sama: kenapa proyek yang disetujui semua orang malah tidak bergerak satu inci pun?

Ruang Rapat yang Membeku

Bayangkan sebuah forum pengarah (steering committee) proyek transformasi di sebuah utilitas air yang di atas kertas seharusnya berjalan mulus. Agendanya menyetujui arsitektur pelaporan data terpusat (Enterprise Data Warehouse): seluruh data produksi, distribusi, dan penagihan ditarik ke satu dasbor yang bisa dibuka Direktur Utama kapan saja, secara seketika (real-time). Tim konsultan sudah memaparkan rancangannya dan logikanya nyaris tak terbantah. Manajer proyeknya, sebut saja Mas Arif, baru saja mengantongi sertifikasi manajemen proyek (Project Management Professional atau PMP), dan ia datang membawa matriks pemangku kepentingan yang rapi: seluruh jajaran direksi BUMD ia tandai sebagai pendukung berpengaruh tinggi. Matriks itu rapi dan, sejauh yang sanggup ditangkap sebuah matriks, benar. Di atas kertas, proyek ini sudah menang sebelum dimulai.

Lalu sesi tanya jawab dibuka, dan suhu ruangan turun beberapa derajat. Direktur Operasional, sebut saja Pak Hendra, berargumen bahwa sensor di lapangan belum stabil, sehingga data mentah tidak boleh ditarik sebelum “divalidasi” oleh timnya. Direktur Keuangan beralasan rekonsiliasi penagihan punya siklus tutup buku sendiri, dan dasbor seketika hanya akan memicu kepanikan bila ada selisih angka sementara. Kepala Divisi TI mengeluhkan anggaran pengamanan data yang belum ada. Tidak satu pun dari mereka mengucap kata “tolak”. Semua, dengan khidmat, menyebut digitalisasi sebagai masa depan.

Hasilnya, proyek itu jalan di tempat selama satu setengah tahun. Penundaan prosedural, syarat teknis yang mustahil dipenuhi, dan alasan kehati-hatian yang semuanya terdengar bertanggung jawab. Mas Arif kebingungan. Matriksnya jelas-jelas menunjukkan semua orang mendukung. Mengapa proyeknya mati pelan-pelan justru tanpa seorang pun yang membunuhnya?

Saya tahu jawabannya, karena bertahun-tahun sebelumnya saya membuat matriks yang sama persis dan gagal dengan cara yang sama. Yang tidak pernah masuk ke peta Arif adalah pertanyaan yang sesungguhnya menggerakkan ruangan itu: bukan “seberapa besar pengaruh tiap orang”, melainkan “apa yang akan hilang dari tiap orang kalau proyek ini berhasil”. Itu bukan kelalaian Arif; pertanyaan semacam itu memang jarang muat di kolom mana pun, dan tak banyak pelatihan yang sempat mengajarkannya. Pak Hendra tidak takut pada teknologi. Ia takut pada satu hal yang sangat masuk akal: begitu dasbor itu menyala, angka kebocoran mentah dari wilayahnya akan terpampang di layar Direktur Utama sebelum ia sempat menjelaskannya.

Dan selama satu setengah tahun rapat-rapat itu berputar tanpa keputusan, kebocoran yang seharusnya bisa dipetakan oleh sistem terpusat itu terus mengalir di bawah jalan-jalan kota. Politik di ruang ber-AC tidak pernah benar-benar berhenti di ruang ber-AC; ongkosnya selalu menetes ke suatu tempat, ke pipa yang tak kunjung diperbaiki, ke pelanggan di ujung jaringan yang airnya tetap tersendat. Rapat yang membeku itu punya korban. Mereka hanya tidak hadir di ruangan.

3.1 Mitos Harmoni Organisasi

Buku teks manajemen proyek menggambarkan pemangku kepentingan sebagai pihak-pihak yang pada dasarnya menginginkan kemenangan yang sama, hanya berbeda kebutuhan komunikasi. Ini mitos yang berbahaya, dan bahayanya halus: ia menuntun kita salah membaca tanda. Persetujuan bulat terdengar seperti kabar baik. Padahal dalam proyek transformasi, justru persetujuan bulat yang paling patut dicurigai.

Penolakan yang sesungguhnya nyaris tidak pernah datang sebagai penolakan. Ia datang sebagai kehati-hatian yang terdengar bertanggung jawab, sebagai “mari kita validasi dulu”, sebagai syarat teknis yang tak pernah bisa dipenuhi. Proyek yang ditentang secara terbuka setidaknya masih hidup, karena ada sesuatu yang bisa dijawab dan didebat. Proyek yang disetujui semua orang lalu tidak bergerak satu inci pun adalah proyek yang sudah mati, hanya saja belum ada yang mengumumkannya. Di ruang rapat utilitas air, keheningan yang sopan jauh lebih mematikan daripada perdebatan yang gaduh.

3.1.1 Arsitektur Informasi Adalah Arsitektur Kekuasaan

Untuk mengerti mengapa Pak Hendra menahan dasbor itu, berhentilah menganggapnya sebagai proyek teknologi. Sebuah dasbor terpusat sesungguhnya adalah pemindahan kekuasaan: kekuasaan untuk menentukan kapan dan bagaimana sebuah angka dilihat. Selama ini, ketika kebocoran di wilayah Pak Hendra melonjak, ia punya jeda, sehari atau seminggu, untuk menyiapkan konteks sebelum angka itu naik ke meja atasannya. Dasbor seketika mencabut jeda itu. Yang ia pertahankan bukan kendali atas sensor, melainkan kendali atas narasi.

Maka ketika Direktur Operasional tersebut berkata “sensor belum dikalibrasi”, ia tidak sedang berbohong secara teknis, dan ia sama sekali bukan penjahat (villain) dalam cerita ini. Posisinya justru pantas dilihat dengan simpati: ia adalah aktor rasional yang terjebak dalam ekosistem pelaporan yang menghukumnya setiap kali ada angka buruk yang mengejutkan pimpinan/Pemda, tetapi tidak pernah memberinya perlindungan politik karena berani jujur lebih awal. Sistem informasi yang baru menggambar ulang siapa berutang penjelasan kepada siapa, dan ia melakukannya tanpa pernah meminta izin pada peta kekuasaan yang sudah ada. Tidak ada dasbor, secanggih apa pun, yang sanggup menetralkan kenyataan bahwa seseorang akan kehilangan kendali atas informasi krusialnya. Teknologi tidak melarutkan politik kantor; ia hanya memindahkannya.

3.1.2 Cermin Universal: Papan Skor yang Ditakuti

Pola ini jauh melampaui dunia air. Bayangkan sebuah dinas pendidikan yang ingin memasang dasbor terpusat berisi angka kelulusan dan putus sekolah tiap sekolah, terbuka dan diperbarui terus-menerus. Secara teknis tidak ada yang salah; datanya memang ada dan akurat. Tetapi para kepala sekolah akan menahannya dengan seribu alasan prosedural. Bukan karena mereka anti-data, melainkan karena angka mentah tanpa konteks, tingkat kemiskinan murid, mutu calon yang masuk, kekurangan guru, akan menghakimi mereka seketika di layar atasan sebelum mereka sempat menjelaskan.

Di mana pun sebuah angka dipakai untuk menilai orang, membuat angka itu terlihat seketika dan oleh semua orang adalah tindakan politik, bukan sekadar tindakan teknis. Yang ditakuti bukan kebenaran angka itu, melainkan kecepatan dan ketelanjangannya. Siapa pun yang merancang transformasi tanpa menyadari hal ini akan terus heran mengapa “sekadar menampilkan data” justru memicu perlawanan yang paling keras.

3.1.3 Sistem Kekebalan di Meja Rapat

Kalau kita memandang organisasi sebagai sistem yang hidup, rapat yang membeku tadi bukanlah kegagalan komunikasi. Itu adalah sistem kekebalan organisasi yang sedang bekerja persis sebagaimana mestinya: melindungi keseimbangan kekuasaan yang ada dari benda asing yang mengancamnya. Reaksinya otomatis, kolektif, dan nyaris selalu disampaikan dalam bahasa yang sopan dan masuk akal.

Artinya, mendamaikan konflik semacam ini tidak mungkin dilakukan lewat lokakarya pembangunan tim (team building) atau pidato tentang sinergi. Selama struktur insentifnya tidak disentuh, sistem kekebalan itu akan menolak setiap kali, dengan alasan yang berbeda-beda. Tugas pemimpin perubahan bukan meredam gejala penolakannya, melainkan merekayasa ulang apa yang dipertaruhkan tiap pihak, dan memberi jaminan keamanan politik bagi mereka yang diminta melepaskan sesuatu.

3.2 Memetakan Anatomi Ancaman, Bukan Pengaruh

Di sinilah peta pemangku kepentingan standar mengkhianati Anda. Matriks pengaruh dan kepentingan hanya memotret keadaan sekarang: siapa yang kuat, siapa yang peduli. Tetapi transformasi tidak berurusan dengan keadaan sekarang; ia berurusan dengan redistribusi. Setiap perubahan besar memindahkan kendali, informasi, atau anggaran dari satu tangan ke tangan lain. Maka peta yang sebenarnya Anda butuhkan bukan peta pengaruh, melainkan peta kehilangan: siapa yang sedang diminta membayar, dan dengan apa ia membayarnya.

Untuk tiap nama di ruangan, ganti pertanyaan “seberapa besar pengaruhnya” dengan “apa yang proyek ini ambil darinya”: kendali atas data, kenyamanan rutinitas, pemasukan informal, rasa aman dari sorotan, atau sekadar relevansi keahlian yang sudah dua puluh tahun ia bangun. Peta kehilangan inilah yang menjelaskan mengapa orang yang di atas kertas “mendukung penuh” justru berubah menjadi pengganjal yang paling halus. Mereka tidak berbalik pikiran; mereka hanya baru menyadari apa yang akan hilang.

3.2.1 Ancaman Eksistensial vs Kebingungan Teknis

Tidak semua penolakan sama, dan menyamaratakannya adalah kesalahan yang merugikan ke dua arah sekaligus. Ada penolakan yang lahir dari kebingungan teknis: antarmuka yang membingungkan, pelatihan yang kurang. Ada pula penolakan yang lahir dari ancaman eksistensial: sistem baru akan mencabut kekuasaan atau pemasukan informal seseorang. Keduanya bisa terdengar persis sama di telinga Anda, sama-sama berbunyi “aplikasinya bermasalah”.

Salah mendiagnosis merugikan di kedua sisi. Mengirim orang yang sebenarnya melindungi rente ke kelas pelatihan hanya membuang waktu, dan ia akan terus menambal alasan baru. Sebaliknya, mendisiplinkan orang yang sebenarnya hanya bingung berarti mengubah seorang calon pendukung menjadi musuh sejati. Ujinya sederhana, dan sama dengan yang kita pakai di bab pertama: penolakan karena kebingungan akan mereda begitu alatnya diperbaiki; penolakan karena ancaman justru mengeras begitu alatnya makin baik. Petugas yang terus berkata aplikasi kerja lapangan (work order) “sering mati sendiri”, padahal catatan server menunjukkannya stabil, biasanya sedang melindungi sesuatu, mungkin kemampuannya melaporkan kehadiran di titik yang sebenarnya tak pernah ia datangi. Untuk yang ini, obatnya bukan pelatihan tambahan, melainkan ketegasan pimpinan sekaligus skema insentif baru yang sah untuk menggantikan pemasukan lama yang hilang.

3.2.2 Aktor Kunci di Ekosistem Publik & BUMD

Peta kehilangan di sektor publik dan BUMD (termasuk utilitas air) punya beberapa pemain khas yang tidak ada di perusahaan swasta murni. Masing-masing menimbang sebuah proyek bukan dengan pertanyaan “apakah ini baik untuk perusahaan”, melainkan “apa yang ini lakukan terhadap posisi politik dan karier saya”.

• Kepala Daerah / Pemilik BUMD: Motivasi utamanya stabilitas layanan publik (tidak ada keluhan mati air/listrik di media sosial) dan citra inovasi, terutama menjelang pilkada. Yang paling ia takuti adalah gejolak tarif naik atau temuan BPK yang menyeret namanya.
• Investor atau Pemegang Konsesi (untuk Swasta): Fokus pada tingkat pengembalian investasi (Internal Rate of Return). Mereka akan menolak digitalisasi yang menambah belanja modal (CAPEX) tanpa garis waktu penghematan kas yang jelas.
• Serikat Pekerja dan Staf Senior: Sangat sensitif pada kata “otomatisasi”, yang bagi mereka dibaca sebagai pemutusan hubungan kerja atau hilangnya relevansi keterampilan yang telah mereka bangun selama dua dekade.

Memahami tiga sosok ini berarti berhenti menjual proyek dengan satu bahasa untuk semua orang. Apa yang menenangkan Kepala Daerah, yaitu citra dan stabilitas, justru bisa membuat serikat pekerja gelisah karena terdengar seperti otomatisasi. Pemimpin perubahan yang cakap berbicara dalam sebanyak mungkin “bahasa kehilangan”, dan menyiapkan jawaban yang berbeda untuk tiap ketakutan yang berbeda. Dan ketika kecerdasan buatan ikut masuk, satu entri baru menyelinap ke peta kehilangan ini: ketakutan akan tergantikan oleh mesin. Ia tidak bisa diredakan dengan janji kosong “tidak ada yang tergantikan”, melainkan hanya dengan rancangan pembagian kerja manusia dan mesin yang jujur, yang kita bahas tuntas di bab penutup. Tabel 3.1 merangkum peta kehilangan itu beserta bahasa yang menjawab tiap aktor.

Tabel 3.1 Peta kehilangan: apa yang dipertaruhkan tiap aktor dan bahasa yang menjawabnya

3.3 Seni Mengangkat Konflik ke Permukaan

Karena penolakan sejati menyamar sebagai kehati-hatian, tugas tersulit seorang pemimpin perubahan adalah memaksa konflik yang sebenarnya keluar dari balik jargon. Ini berlawanan dengan naluri kebanyakan manajer, yang dilatih untuk menjaga rapat tetap “kondusif”. Tetapi kebuntuan yang didiamkan tidak akan pernah menyelesaikan dirinya sendiri; ia hanya berpindah menjadi bisik-bisik di kantin dan penundaan tanpa ujung.

Mengangkat konflik ke permukaan bukan berarti mencari kambing hitam. Ia berarti mendudukkan persoalan secara terbuka dan objektif: “Berdasarkan arsitektur datanya, integrasi antara modul A dan modul B terhambat. Keputusan manajemen apa yang kita butuhkan untuk memecah kebuntuan ini?” Pertanyaan yang menunjuk pada sistem, bukan pada orang, memberi semua pihak jalan keluar yang menyelamatkan muka. Ini menuntut keberanian untuk sesekali menjadi sosok yang tidak populer di ruangan, sebab perdamaian semu adalah pembunuh yang paling sabar bagi sebuah transformasi.

3.4 Ketika Forum Penjaganya Ikut Tertawan

Ada satu lapisan terakhir dari anatomi ini yang paling jarang diucapkan, karena mengakuinya terasa seperti menuduh. Bayangkan pola yang berulang di banyak BUMD: sebuah proyek modernisasi sistem penagihan masuk ke rencana kerja dan anggaran empat tahun berturut-turut. Setiap tahun disetujui, dianggarkan, lalu tidak terlaksana, dengan alasan yang selalu berganti: kajian belum selesai, vendor tidak memenuhi syarat, anggaran bergeser, kondisi berubah sehingga kajian perlu diulang. Tidak ada yang berbohong. Tidak ada yang menolak. Semua mekanisme formal berjalan sempurna; hasilnya tetap nol, karena yang bergerak hanyalah dokumennya.

Yang terjadi di situ bukan lagi sekadar ancaman eksistensial perorangan seperti yang kita petakan di atas. Forum yang seharusnya menjaga proyek, komite teknis atau panitia evaluasinya, justru dipengaruhi oleh pihak yang paling diuntungkan kalau sistem lama tetap hidup. Vetonya tidak pernah diucapkan; ia bekerja lewat prosedur. Meminta kajian tambahan. Menggeser persyaratan setelah vendor terpilih. Memberi proyek 40 persen dari anggaran minimum yang dibutuhkan, lalu menjadikan kegagalannya sebagai bukti bahwa “transformasi tidak cocok untuk organisasi kita”. Setiap langkah tampak bertanggung jawab; kumulatifnya yang mematikan.

Menghadapi tembok semacam ini, peta kehilangan saja tidak cukup. Ada tiga respons yang sama-sama sah, dan kejujuran diagnosislah yang menentukan mana yang dipilih. Pertama, rancang ulang lingkup: kecilkan proyek sampai ke titik yang bisa diputuskan tanpa persetujuan pihak yang memblokir, selesaikan, lalu pakai hasilnya sebagai bukti yang sulit dibantah. Manfaat yang langsung dirasakan pengguna akhir adalah pengubah dinamika forum yang paling ampuh, karena pengguna akhir tidak punya kepentingan atas sistem lama. Kedua, tunggu dan siapkan: kepemimpinan berputar, dan tembok yang hari ini permanen sering hilang dalam dua tahun. Menunggu bukan berarti pasif kalau diisi dengan mendokumentasikan bukti, membangun koalisi diam-diam di lapisan tengah dengan merekrut sekutu yang justru diuntungkan bila proyek berhasil, dan menjaga proyek hidup dalam lingkup kecil. Ketiga, dan ini yang paling jarang ditulis buku transformasi karena terdengar seperti kekalahan: berhenti, dengan rekam jejak yang utuh. Melanjutkan proyek yang diblokir secara struktural bukan keteguhan; itu pemborosan kapasitas tim dan legitimasi organisasi. Berhenti yang bermartabat meninggalkan dokumentasi lengkap tentang apa yang dicoba, apa yang menghadang, dan rekomendasi tertulis bagi penerus, sehingga organisasi tidak memulai dari nol ketika kondisinya berubah.

Satu disiplin menyatukan ketiganya: rekam jejak. Catat setiap perubahan lingkup yang diminta, setiap rekomendasi yang ditolak beserta siapa yang menolaknya, dan kirim laporan kemajuan ke lebih dari satu pihak, sebab laporan yang sudah diterima banyak orang jauh lebih sulit direvisi narasinya di kemudian hari. Tanpa rekam jejak, kegagalan akan mengambang lalu mendarat di pundak pihak yang paling tidak berdaya membela diri. Mekanisme tata kelolanya, dari desain forum evaluasi yang netral sampai struktur dokumentasi keputusan, kami bedah tuntas di buku kedua seri ini, IT Governance Playbook; di buku ini cukup satu pesannya: tembok kepentingan tidak dikalahkan dengan keberanian sesaat, melainkan dengan desain yang membuatnya kehilangan tempat bersembunyi.

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

• Persetujuan bulat lebih berbahaya daripada penolakan terbuka. Lawan sejati transformasi menyamar sebagai kehati-hatian yang sopan; proyek yang disetujui semua orang lalu tak bergerak sudah mati diam-diam.
• Arsitektur informasi adalah arsitektur kekuasaan. Dasbor terpusat bukan peningkatan teknis, melainkan pemindahan kendali atas kapan dan bagaimana sebuah angka dilihat. Teknologi tidak melarutkan politik; ia memindahkannya.
• Petakan kehilangan, bukan pengaruh. Untuk tiap orang di ruangan, tanyakan bukan “seberapa kuat ia”, melainkan “apa yang proyek ini ambil darinya”, lalu bedakan penolakan karena bingung (mereda saat alat diperbaiki) dari penolakan karena terancam (mengeras saat alat membaik).

[!TIP] Executive Toolkit: Matriks Kehilangan (Bab 3) Jangan bawa matriks pengaruh (Stakeholder Matrix) biasa ke ruang rapat. Buatlah Peta Kehilangan rahasia Anda sendiri sebelum proyek dimulai.

1. Daftar Barang Hilang: Di sebelah nama setiap direktur/manajer, jangan tulis “Tinggi/Rendah” pengaruhnya. Tulis secara eksplisit: Apa yang akan diambil dari orang ini jika aplikasi menyala besok? (Kendali data, otoritas ACC, kenyamanan rutinitas, pemasukan ekstra, atau rasa aman dari sorotan).
2. Uji Validasi Kebingungan vs Sabotase: Jika sebuah divisi terus beralasan “sistem ini membingungkan”, berikan perbaikan interface atau pelatihan tambahan. Jika setelah pelatihan mereka tetap menolak dengan alasan yang bergeser ke hal lain, itu bukan kebingungan. Itu adalah perlindungan kepentingan. Jangan kirim mereka ke pelatihan lagi; eskalasi ke level pimpinan untuk mengubah insentifnya.
3. Eskalasi Tanpa Menuduh: Saat mengangkat konflik tersembunyi ke permukaan di rapat, jangan tunjuk orangnya. Tunjuk sistemnya: “Tampaknya ada hambatan integrasi antara operasional dan IT yang membuat proyek ini tertahan. Kami mohon arahan Direksi untuk menyelaraskan kedua fungsi ini.”
4. Definisikan Kondisi Berhenti Sejak Awal: Sepakati di muka kapan proyek boleh dihentikan bukan karena gagal, melainkan karena hambatannya di luar kapasitas tim untuk diselesaikan. Periksa juga siapa yang duduk di forum evaluasi: adakah anggota yang justru paling diuntungkan bila proyek tidak pernah jalan? Jika ya, kondisi berhenti dan rekam jejak yang utuh adalah pelindung tim Anda.

Tetapi ada satu jenis konflik yang bahkan keberanian mengangkatnya ke permukaan pun tak akan bisa menyelesaikannya: ketika proyek itu sendiri sebenarnya tidak pernah dimaksudkan untuk berhasil. Ketika pemangku kepentingan yang paling menentukan bukan orang yang takut kehilangan kendali, melainkan orang yang justru diuntungkan oleh proyek itu sekadar berjalan, terlepas dari berguna atau tidaknya bagi pelanggan. Di situ, peta kehilangan berubah menjadi peta kepentingan yang jauh lebih gelap, dan akan dibahas di Bab 4. Saat konflik ini sudah mencapai level birokrasi eksternal, lihat Bab 7 untuk taktik mengelevasi sumbatan di luar wewenang.

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.