Bab 1: Pendahuluan - Mengapa Tata Kelola TI Penting

Track: Eksekutif (E); untuk Direksi, Manajer, dan pengambil keputusan.

Tiga Hal yang Wajib Dibawa Pulang

1. Tata kelola TI bukan proyek teknis, melainkan arsitektur keputusan. Kegagalan TI paling mahal bukan disebabkan oleh perangkat yang rusak, melainkan oleh keputusan yang tidak punya pemilik, jalur eskalasi yang tidak pernah dirancang, dan prioritas pemulihan yang baru dibahas saat krisis sudah terjadi.

2. Tiga pertanyaan diagnosa cepat cukup untuk menguji fondasi. Siapa pemilik keputusan eskalasi pada menit ke-15 insiden? Apakah ada risk register TI yang hidup? Apakah investasi TI memiliki gate review formal? Jika satu saja belum terjawab, fondasi tata kelola belum ada.

3. Mulai dari struktur, bukan dari teknologi. Organisasi tidak perlu membeli sistem baru untuk memulai tata kelola TI. Yang dibutuhkan pertama adalah kejelasan peran, forum keputusan, dan mekanisme akuntabilitas yang tertulis.

Pukul 02.15, alarm berbunyi di control room. Layar SCADA membeku. Operator jaga mengecek ulang. Bukan false alert. Koneksi ke PLC lapangan putus. Kontrol pompa dan valve tidak bisa dijalankan dari konsol.

Yang terjadi kemudian bukan panik. Dua operator mulai mengeksekusi yang mereka bisa: restart klien SCADA, telepon rekan teknis, kirim satu orang ke lapangan untuk menghidupkan pompa distribusi secara manual. Beberapa pompa menyala. Tetapi reservoir utama yang dikendalikan otomatis mulai turun levelnya. Tanpa SCADA, operator tidak bisa membaca tekanan di titik distribusi, tidak bisa mengatur valve jarak jauh dari ruang kendali.

Di titik ini mereka butuh keputusan yang lebih tinggi dari kewenangan teknis. Haruskah menghubungi Manajer Operasi sekarang, pukul 02.30 dini hari? Prosedur eskalasi darurat tidak pernah ditetapkan. Tidak ada yang melatih mereka tentang siapa yang harus dihubungi dalam 15 menit pertama insiden. Kepala regu memutuskan menunggu pagi: bukan karena tidak peduli, melainkan karena tidak ada yang pernah merancang jalur keputusan untuk situasi seperti ini.

Pukul 06.15, Manajer Operasi (yang biasa tiba lebih awal) menerima telepon dari kepala regu. Reservoir sudah mendekati level kritis. Pompa zona distribusi mulai mati satu per satu karena low suction. Begitu Direktur Operasi tiba pukul 07.00, air sudah tidak sampai ke sebagian besar wilayah. Rapat darurat dimulai tanpa peta keputusan, karena peta itu memang tidak pernah dibuat. Dari luar, warga hanya tahu satu hal: air tidak mengalir. Dari dalam, yang diuji sebenarnya satu hal fundamental: apakah arsitektur keputusan organisasi cukup kuat saat tekanan tinggi?

Kalau Anda jajaran Direksi yang membaca ini, mungkin Anda mengenali salah satu kursi di ruang rapat pagi itu. Mungkin Anda yang menerima telepon pukul 07.00 dan harus menjelaskan keadaan layanan kepada pemilik mandat, mitra pemerintah, atau publik dua jam kemudian. Mungkin Anda yang baru tahu jam berapa kejadiannya saat pers sudah menelepon. Insiden seperti ini jarang dimulai di meja Direksi, tapi hampir selalu berakhir di sana. Itulah alasan tata kelola ini harus dipimpin oleh Anda terlebih dahulu, bukan oleh tim TI.

Peta Konsep Bab Ini

Diagram 1.1 memetakan alur dasar bab ini: insiden dini hari sebagai pintu masuk, konteks utilitas air sebagai alasan urgensi, lalu definisi tata kelola, risiko, dan langkah pertama yang bisa dibawa ke rapat Direksi.

1.1 Insiden 02.15 dan Akar yang Tak Pernah Disentuh

Narasi pembuka ini bukan fiksi tunggal. Ia komposit dari pola insiden berulang di organisasi utilitas air. Identitas sengaja disamarkan, tetapi polanya mudah dikenali di banyak bentuk organisasi: operator yang tidak tahu batas kewenangannya, manajer yang tidak diberi jalur keputusan, direktur yang baru tahu setelah empat jam. Ini bukan soal orangnya. Ini soal sistem yang tidak pernah dirancang.

Pertanyaan yang membayangi insiden seperti ini bukan “apa yang rusak”. Teknisi bisa menjawabnya dalam lima menit. Pertanyaan yang sebenarnya: siapa yang berwenang mengeskalasi pada menit ke-15? Siapa pemilik keputusan pemulihan layanan? Kenapa pertanyaan-pertanyaan itu belum punya jawaban sebelum insiden terjadi?

Pertanyaan-pertanyaan ini bukan tugas Kepala Divisi TI untuk menjawabnya sendirian. Kepala Divisi TI bisa memastikan server menyala dan jaringan terhubung. Tetapi siapa yang berwenang mengeskalasi ke pimpinan daerah atau mitra pemerintah, siapa yang berhak menghentikan distribusi di satu zona untuk menyelamatkan zona lain, siapa yang menetapkan urutan pemulihan saat sumber daya terbatas, itu adalah keputusan tata kelola, bukan keputusan teknis. Tata kelola adalah pekerjaan Direksi. Tidak bisa didelegasikan ke divisi, tidak bisa diserahkan ke vendor, tidak bisa ditunda sampai ada insiden. Disiplin inilah yang harus dipraktikkan, bukan sekadar retorika yang menghias rencana strategis.

1.1.1 Dua Wajah Ketergantungan: Budaya Pahlawan dan Tim Tanggap Darurat yang Tidur

Di banyak perusahaan utilitas air, tim teknis sebenarnya bekerja keras. Mereka mengenal infrastruktur, hafal perilaku sistem, dan terbiasa menambal gangguan dengan sumber daya seadanya. Tetapi kemampuan teknis tinggi tidak otomatis menghasilkan ketahanan organisasi. Justru sering terjadi sebaliknya: kemampuan teknis tanpa tata kelola yang matang melahirkan budaya pahlawan (hero culture). Organisasi bergantung pada individu kunci yang dianggap bisa menyelesaikan semua keadaan. Selama orang itu ada, semua tampak baik-baik saja. Begitu orang itu berhalangan, proses keputusan ikut melemah. Ini bukan masalah teknis lagi.

Kebalikannya juga terjadi: struktur ada, tapi hanya hidup setahun sekali. Banyak organisasi memiliki Tim Tanggap Darurat (Emergency Response Team, ERT), lengkap dengan SK, daftar nama, dan term of reference. Namun dalam praktiknya, tim ini hanya benar-benar diaktifkan menjelang libur Lebaran. Selebihnya, tim ini tidur. Insiden 02.15 tidak dianggap cukup darurat untuk membangunkan ERT, karena pemicu aktivasinya bukan sinyal operasional, melainkan kalender. Struktur tanpa pemicu keputusan adalah ilusi kesiapan.

Kita sering terjebak pada ketergantungan terhadap individu kunci. Dalam tata kelola organisasi, ketergantungan yang terlalu dominan pada satu orang adalah alarm bahwa sistem belum cukup kuat. Keahlian individu tetap penting, tetapi tidak boleh menjadi pengganti desain peran, jalur eskalasi, dan akuntabilitas yang jelas. Tata kelola hadir bukan untuk mengurangi dedikasi, melainkan memastikan martabat organisasi tidak bergantung pada kehadiran satu orang saja.

Dari sudut pandang rekayasa sistem, ketahanan layanan bukan hasil dari orang hebat semata. Ketahanan adalah hasil desain: desain struktur, desain proses, desain umpan balik, dan desain disiplin eksekusi. Keempatnya harus hadir bersamaan. Itulah napas utama yang harus dibawa oleh Tata Kelola TI (IT Governance).

Tiga aturan sederhana yang menyelamatkan organisasi saat tekanan tinggi: keputusan kritis punya satu pemilik, bukan komite; eskalasi punya batas jam, bukan ruang diskusi terbuka; setiap insiden menghasilkan pembelajaran tertulis, bukan hanya laporan status yang masuk laci.

1.1.2 Dari Gejala Teknis ke Akar Organisasi

Mari bedakan gejala dan akar masalah.

Gejala yang biasanya terlihat di lapangan: aplikasi tidak merespons, antrean transaksi tertunda, dasbor pemantauan tidak sinkron, tim lapangan menunggu kepastian data yang tidak datang.

Akar masalah yang sering tersembunyi di balik gejala itu: tidak ada pemilik keputusan pemulihan layanan yang ditetapkan sebelum insiden, tidak ada urutan prioritas layanan kritis yang disepakati lintas direktorat, tidak ada batas waktu eskalasi yang mengikat, tidak ada mekanisme komunikasi publik yang siap pakai.

Gejala teknis bisa diselesaikan teknisi. Akar masalah organisasi hanya bisa diselesaikan melalui tata kelola yang dipimpin manajemen puncak. Di titik ini bahasa rekayasa bertemu bahasa kepemimpinan: tanpa rancangan sistem keputusan, operasi berjalan di atas keberuntungan.

1.1.3 Tiga Lapis Pelajaran dari Insiden Dini Hari

Pelajaran pertama: teknis. Sistem perlu redundansi (redundancy), cadangan data (backup), dan pemantauan memadai. Penting, tapi belum cukup.

Pelajaran kedua: manajerial. Insiden harus dikelola melalui prosedur eksplisit. Siapa incident commander, siapa pemilik komunikasi publik, siapa pemilik keputusan prioritas layanan. Semua harus ditetapkan sebelum insiden, bukan saat insiden. Bukan saat alarm berbunyi pukul 02.15.

Pelajaran ketiga: tata kelola. Organisasi harus menyepakati prinsip keputusan pada masa tenang, supaya keputusan saat krisis tidak bergantung pada improvisasi. Di sinilah komposisi kepemimpinan jadi penting. Presisi sistem ala rekayasa dipadukan dengan disiplin langkah praktis, lalu dijaga oleh sensitivitas kemanusiaan. Organisasi publik tidak boleh kehilangan aspek teknis, tapi juga tidak boleh kehilangan hati.

1.2 Mengapa Konteks Perusahaan Utilitas Air Berbeda

Perusahaan utilitas air punya karakter yang membuat kebutuhan tata kelola TI jauh lebih mendesak dibanding banyak sektor lain. Lima alasan berikut bukan sekadar latar, melainkan realitas operasional yang tidak bisa dihindari.

Pertama, layanan yang dijaga adalah layanan dasar masyarakat. Ketika sistem operasional (SCADA, billing, atau layanan pelanggan) terganggu, dampaknya tidak berhenti pada indikator internal. Dampaknya menjalar ke rumah tangga, fasilitas publik, aktivitas ekonomi lokal. Gangguan TI di organisasi utilitas air jarang murni gangguan TI. Hampir selalu ada yang menunggu air di ujung pipa.

Kedua, pola risikonya gabungan. Risiko layanan, risiko data, risiko finansial, risiko regulasi saling berkelindan. Satu keputusan yang terlambat satu jam pada malam hari bisa memicu biaya pemulihan berminggu-minggu. Mahal.

Ketiga, sumber daya terbatas. Anggaran terbatas, talenta terbatas, infrastruktur kompleks. Setiap keputusan investasi TI harus presisi. Salah memilih prioritas bukan hanya pemborosan. Bisa mengunci organisasi dalam utang teknis (technical debt) bertahun-tahun.

Keempat, ekspektasi pemangku kepentingan terus naik. Dewan Pengawas, komisaris, pemilik modal, dan mitra pemerintah menuntut akuntabilitas investasi. Regulator menuntut kepatuhan. Masyarakat menuntut kualitas layanan yang konsisten. Semua bermuara pada satu pertanyaan: apakah organisasi punya sistem tata kelola yang bisa dipertanggungjawabkan?

Kelima, dan ini yang paling sering terlewat: TI di organisasi utilitas air sering kali masih ditempatkan sebagai fungsi pendukung, biasanya di bawah Direktur Keuangan, bagian umum, atau unit administratif lain. Ini artefak era 1990-an, ketika “TI” masih berarti “komputer untuk akuntansi.” Dua setengah dekade kemudian, TI sudah menjadi tulang punggung operasional: SCADA mengendalikan produksi dan distribusi, billing adalah mesin pendapatan utama, layanan pelanggan bergerak ke kanal digital. Tetapi struktur organisasi di banyak perusahaan utilitas air belum selalu bergerak secepat perubahan itu. Di BUMD, keputusan TI kerap melewati jalur birokrasi yang tidak dirancang untuk krisis operasional. Di operator swasta mitra pemerintah, keputusan TI bisa tersangkut di antara target kontrak, unit operasi, dan kebutuhan persetujuan lintas pihak. Hasilnya sama: sistem kritis bergerak cepat, tetapi jalur keputusan bergerak lambat.

Ini bukan argumen bahwa TI lebih penting dari Keuangan atau Pengadaan. Tanpa Keuangan, listrik pompa tidak terbayar. Tanpa Pengadaan, suku cadang tidak tersedia. Argumennya lebih spesifik: TI bukan lagi supporting function. Ia operational function, setara dengan produksi dan distribusi. Bedanya: ketika sistem Keuangan mati, transaksi bisa dicatat manual. Lambat, tapi bisa. Ketika SCADA mati, tidak ada yang bisa menggerakkan valve jarak jauh secara manual di 50 titik sekaligus. Itu perbedaan fundamental yang belum tercermin di banyak struktur organisasi.

Era digital memperbesar urgensi ini. Media sosial membuat setiap insiden layanan menjadi konsumsi publik dalam hitungan menit: keluhan tidak lagi datang via surat atau telepon, tapi lewat utas media sosial dan grup WhatsApp yang bisa menyebar sebelum manajemen sempat merespons. Digitalisasi di hampir semua bidang kehidupan membuat masyarakat terbiasa dengan layanan real-time, dan kesabaran terhadap layanan publik yang lambat semakin menipis. Pada saat yang sama, semakin banyak sistem yang terhubung ke jaringan (SCADA, billing, portal pelanggan, IoT meter), semakin besar attack surface yang bisa dieksploitasi. Teknologi kecerdasan buatan menambah lapisan baru: ia bisa dipakai untuk memperkuat deteksi ancaman, tetapi juga bisa dipakai aktor jahat untuk melancarkan serangan yang lebih canggih dan lebih sulit dideteksi. Organisasi yang TI-nya masih dianggap “bagian komputer” tidak akan siap menghadapi realitas baru ini.

1.3 Apa Itu Tata Kelola Teknologi Informasi

Tata Kelola TI (IT Governance) bukan sekadar label baru untuk hal yang sudah lama ada. Ia sistem yang memastikan penggunaan TI hampir selalu berada pada orbit tujuan organisasi. Orbit itu dibentuk oleh struktur keputusan, proses pengendalian, indikator kinerja, dan akuntabilitas yang jelas.

Dalam praktik, istilah ini sering tercampur dengan Manajemen TI (IT Management). Keduanya saling terkait, tapi tidak identik.

Tata Kelola TI (IT Governance) menjawab “arah mana”, “siapa memutuskan”, dan “bagaimana memastikan nilai dan risiko terkendali”. Manajemen TI (IT Management) menjawab “bagaimana menjalankan operasi harian agar layanan tetap berjalan”.

Disederhanakan: tata kelola memilih tujuan dan memasang pagar pengaman. Manajemen mengeksekusi perjalanan harian di dalam pagar itu. Pagar tanpa perjalanan? Kosong. Perjalanan tanpa pagar? Kacau.

Paradoks yang sering terlewat: banyak organisasi mengalokasikan miliaran untuk sistem TI baru, tapi tidak menginvestasikan waktu untuk menetapkan siapa yang berwenang memutuskan sistem itu dipilih. Hasilnya bukan transformasi digital. Hasilnya digitalisasi kekacauan yang sudah ada. Karena itu Tata Kelola TI (IT Governance) harus didahulukan sebelum Investasi TI (IT Investment). Bukan sebaliknya.

1.3.1 Definisi Operasional untuk Organisasi Layanan Publik

Untuk konteks perusahaan utilitas air, definisi operasional yang relevan:

Tata Kelola TI (IT Governance) adalah seperangkat keputusan, peran, proses, dan pengukuran yang memastikan investasi TI mendukung tujuan layanan publik, menghasilkan manfaat terukur, menjaga risiko dalam batas yang diterima, serta mematuhi regulasi.

Empat pilar dalam definisi ini: keselarasan tujuan, realisasi manfaat, pengendalian risiko, kepatuhan regulasi. Satu pilar diabaikan, kualitas tata kelola langsung menurun. Contoh paling umum: organisasi kuat di belanja teknologi, tapi lemah di pengukuran manfaat. Sistem baru dibeli. Laporan proyek selesai. Tapi dampak layanan tidak membaik secara nyata. Uang habis, laporan rapi, layanan tetap sama.

1.3.2 Lima Domain Inti yang Harus Bergerak Bersama

A. Keselarasan Strategi (Strategic Alignment)

Pertanyaan utamanya: apakah agenda TI benar-benar mendukung sasaran organisasi?

Pada perusahaan utilitas air, sasaran strategis biasanya terkait keandalan layanan, efisiensi biaya, penguatan pendapatan, dan kepatuhan. Program TI harus diturunkan dari sasaran tersebut, bukan dari dorongan adopsi teknologi semata.

Indikator praktis domain ini: peta inisiatif TI terhubung ke sasaran strategis tahunan, setiap proyek punya pemilik manfaat dari sisi bisnis bukan hanya dari tim TI, keputusan prioritas proyek ditetapkan lintas direktorat.

B. Penyerahan Nilai (Value Delivery)

Pertanyaan utamanya: manfaat apa yang benar-benar sampai ke organisasi?

Nilai tidak boleh didefinisikan hanya sebagai “proyek selesai”. Nilai harus berbentuk dampak yang bisa diverifikasi: durasi gangguan layanan menurun, waktu penyelesaian aduan menurun, akurasi data pelanggan meningkat, efisiensi biaya operasi meningkat. Bukan di slide presentasi. Di data.

Disiplin domain ini menuntut organisasi mendefinisikan manfaat sejak awal, lalu menagih realisasinya setelah proyek berjalan. Slide presentasi bisa dibuat tampak rapi. Data operasional lebih sulit disiasati.

C. Manajemen Sumber Daya (Resource Management)

Pertanyaan utamanya: apakah aset TI, anggaran, dan talenta dikelola sebagai portofolio strategis?

Sumber daya TI bukan hanya server dan aplikasi. Kontrak vendor, kapasitas tim, kualitas data juga termasuk. Banyak organisasi gagal karena melihat sumber daya secara terpisah. Sistem baru masuk, tapi tim tidak siap. Lisensi diperpanjang, padahal pemakaian rendah. Potret umum, bukan pengecualian.

Prinsip domain ini: inventaris aset harus akurat dan diperbarui, kapasitas tim dipetakan terhadap kebutuhan proyek, keputusan belanja berbasis siklus hidup aset bukan reaksi jangka pendek.

D. Manajemen Risiko (Risk Management)

Pertanyaan utamanya: apakah risiko TI dipetakan, diprioritaskan, dan diperlakukan secara disiplin?

Risiko TI pada organisasi utilitas air mencakup gangguan operasional sistem kritis, kebocoran atau ketidakakuratan data, ketergantungan berlebihan pada vendor tertentu, kegagalan kepatuhan terhadap regulasi.

Organisasi yang matang tidak menunggu insiden. Ia mengelola risk register, menetapkan ambang risiko, memantau mitigasi secara berkala. Pemantauan bukan formalitas. Instrumen navigasi.

E. Pengukuran Kinerja (Performance Measurement)

Pertanyaan utamanya: apakah keputusan TI dikendalikan oleh indikator yang relevan?

Tanpa indikator, organisasi bergerak berdasarkan persepsi. Dengan indikator, organisasi bergerak berdasarkan fakta. Perbedaan besar.

Contoh indikator yang relevan: ketersediaan layanan sistem prioritas, waktu pemulihan rata-rata saat insiden, persentase proyek yang mencapai manfaat bisnis yang ditargetkan, tingkat kepatuhan proses perubahan sistem.

Pengukuran kinerja bukan kegiatan administrasi. Ia instrumen kemudi. Tanpa kemudi, kapal boleh berlayar, tapi tidak jelas ke arah mana.

1.3.3 Satu Bahasa Bersama: COBIT

Panduan ini menggunakan satu kerangka kerja sebagai acuan: COBIT, singkatan dari Control Objectives for Information and Related Technologies. COBIT adalah kerangka kerja internasional yang dikembangkan oleh ISACA, asosiasi profesional tata kelola TI global yang berdiri sejak 1969. Kerangka ini dirancang khusus untuk satu tujuan: menjembatani kesenjangan antara apa yang dibutuhkan bisnis dan apa yang dijalankan oleh TI.

COBIT tidak menggantikan regulasi Indonesia. Ia tidak menggantikan SOP internal. Ia memberi struktur berpikir: satu bahasa yang sama dari Dewan Pengawas sampai teknisi untuk mendiskusikan prioritas, risiko, dan hasil.

Bagi perusahaan utilitas air, nilai utama COBIT justru di situ: menerjemahkan diskusi teknis menjadi diskusi tata kelola, dan sebaliknya. Tanpa kerangka bersama, organisasi mudah jatuh ke dua ekstrem: teknokratis, semua dibahas terlalu teknis sampai pimpinan kehilangan pijakan; atau administratif, semua dibahas normatif tanpa desain eksekusi.

Bab 3 akan membahas COBIT secara mendalam. Untuk sekarang, satu prinsip cukup: tata kelola yang baik tidak menuntut semua orang menjadi ahli TI. Ia menuntut semua orang berbagi bahasa keputusan yang sama.

1.3.4 Garis Batas Tata Kelola dan Manajemen

Agar tidak kabur, berikut contoh garis batas yang jelas.

Keputusan tata kelola: menetapkan layanan digital prioritas 2 tahun ke depan; menyetujui ambang risiko untuk sistem operasional kritis (SCADA, billing, layanan pelanggan); menetapkan indikator nilai proyek TI; menentukan prinsip pemilihan dan evaluasi vendor strategis.

Keputusan manajemen: memilih konfigurasi teknis server; menjadwalkan patching bulanan; mengatur rotasi on-call teknisi; mengeksekusi uji pemulihan data per triwulan.

Garis batas ini jelas. Konflik peran berkurang. Rapat lebih singkat, keputusan lebih tegas, eksekusi lebih terukur. Sederhana, tapi sering diabaikan.

1.4 Risiko Tanpa Tata Kelola TI yang Baik

Tanpa tata kelola yang memadai, organisasi berjalan dengan biaya tersembunyi yang terus menumpuk. Biaya ini jarang terlihat di awal karena tersebar di banyak titik. Tapi ketika satu insiden besar terjadi, seluruh biaya tersembunyi muncul sekaligus. Seperti es berguncang. Baru kelihatan retakannya saat dipukul.

Risiko kita bagi menjadi empat kelompok: operasional, finansial, reputasi, dan regulasi. Pembagian ini memudahkan pembahasan, tapi kenyataannya keempatnya saling terkait.

Sebelum masuk ke pembagian risiko, perhatikan tiga tekanan yang bekerja bersamaan pada organisasi utilitas air saat ini.

Pertama, tekanan finansial. Untuk BUMD air minum, laporan evaluasi kinerja PDAM yang pernah diterbitkan BPPSPAM menunjukkan bahwa proporsi organisasi dengan kategori sehat masih jauh dari ideal: sekitar separuh atau kurang, tergantung tahun evaluasi. Untuk operator swasta mitra pemerintah, tekanannya muncul dari struktur tarif, target layanan, kewajiban kontrak, biaya operasi, dan komitmen investasi. Bentuk tekanannya berbeda, tetapi pesannya sama: setiap rupiah investasi TI adalah taruhan yang harus punya alasan, pemilik manfaat, dan ukuran hasil.

Kedua, tekanan kelembagaan. Dokumen perencanaan nasional, dari RPJMN hingga dokumen sektor air Bappenas, secara konsisten mencatat kesenjangan antara target layanan dasar dan kapasitas eksekusi pemerintah daerah. Target naik, kapasitas pelaksanaan tidak selalu mengikuti.

Ketiga, tekanan regulasi. Undang-Undang Nomor 17 Tahun 2019 tentang Sumber Daya Air dan Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi menaikkan standar akuntabilitas secara signifikan: layanan harus terukur, data warga harus dilindungi, dan kegagalan punya konsekuensi.

Tiga tekanan ini mengirim satu pesan konsisten: masalah TI tidak berdiri sendiri. Ia bertemu langsung dengan tekanan finansial, kapasitas kelembagaan, dan kepatuhan hukum. Karena itu, Tata Kelola TI harus dibaca sebagai disiplin strategi organisasi. Bukan urusan teknis semata.

1.4.1 Risiko Operasional

Risiko operasional muncul saat sistem tidak mampu menjaga kontinuitas layanan.

Bentuk paling umum: downtime sistem operasional kritis pada jam layanan padat (baik SCADA yang membuat distribusi terhenti maupun billing yang membuat transaksi tertunda), kegagalan sinkronisasi data antar aplikasi, proses pemulihan lambat karena prosedur tidak baku, ketergantungan pada personel tertentu. Pola yang familiar di banyak organisasi utilitas air, apa pun bentuk kepemilikannya.

Kerusakan utama dari risiko operasional bukan gangguan sesaat. Kerusakan utamanya adalah hilangnya prediktabilitas organisasi. Prediktabilitas hilang, semua unit bekerja reaktif. Energi habis memadamkan api, bukan memperkuat sistem.

1.4.2 Risiko Finansial

Risiko finansial pada tata kelola TI umumnya lewat tiga jalur: belanja tidak tepat sasaran, biaya operasi membengkak akibat desain sistem yang tidak efisien, kebocoran pendapatan akibat kualitas data dan kontrol proses yang lemah.

Dalam konteks perusahaan utilitas air, satu proyek digital yang gagal adopsi bisa memakan anggaran yang seharusnya dipakai untuk prioritas layanan lain. Lebih berbahaya lagi: kegagalan itu sering diikuti keputusan tambal sulam berulang yang menambah biaya tanpa menambah nilai. Biaya bertambah, pembelajaran tidak terbentuk.

1.4.3 Risiko Reputasi

Kepercayaan publik dibangun lama. Rusak cepat.

Ketika kanal digital terganggu berulang, publik tidak membedakan apakah penyebabnya server, vendor, atau prosedur internal. Yang mereka rasakan sederhana: layanan tidak bisa diandalkan. Bagi organisasi layanan publik, persepsi ini sangat mahal.

Reputasi juga tertekan saat organisasi gagal menjelaskan insiden dengan bahasa yang jujur dan terukur. Komunikasi yang terlambat atau tidak konsisten memperbesar spekulasi. Di era percakapan digital, ketidakpastian informasi lebih cepat menyebar dibanding klarifikasi resmi.

1.4.4 Risiko Regulasi

Regulasi terkait sistem elektronik, pelindungan data pribadi, dan tata kelola layanan digital semakin ketat. Organisasi yang tidak memiliki kontrol tata kelola memadai menghadapi risiko: temuan audit berulang, sanksi administratif, kewajiban perbaikan mendesak yang menyerap sumber daya, meningkatnya biaya kepatuhan karena semuanya dikejar saat tenggat.

Kepatuhan bukan kegiatan dokumentasi saja. Kepatuhan adalah bukti bahwa sistem keputusan organisasi cukup disiplin untuk menjaga hak pengguna jasa dan menjaga integritas operasi. Dokumentasi tanpa disiplin keputusan? Kertas.

1.4.5 Studi Kasus Ringkas: Unit A, Unit B, Unit C

Tabel berikut menggambarkan perbedaan dampak antara tiga unit dengan tingkat kematangan tata kelola yang berbeda.

Tabel 1.1 Perbedaan dampak operasional dan finansial antar tingkat kematangan

Pelajaran dari tabel ini sederhana: kematangan tata kelola tidak membuat organisasi kebal insiden. Kematangan tata kelola membuat organisasi pulih lebih cepat, belajar lebih cepat, dan mengulang kesalahan lebih sedikit. Itu bedanya.

1.5 Penutup Bab

Perusahaan utilitas air di Indonesia mampu menerapkan tata kelola TI setara standar internasional secara bertahap. Hambatannya sering kali bukan hanya kapasitas teknis, keterbatasan anggaran, atau kurangnya niat baik. Hambatan yang lebih mendasar adalah kebiasaan menyerah sebelum mencoba, seolah standar internasional selalu terlalu tinggi untuk konteks Indonesia. Tabel kematangan di atas menunjukkan organisasi di Indonesia bisa berada di tingkat mana pun, termasuk tingkat yang lebih matang, ketika Direksi memutuskan bahwa hari ini adalah hari pertama membangun disiplin itu.

Tata kelola TI bukan proyek kosmetik. Ia kerja desain organisasi. Kerja yang menuntut presisi, disiplin, dan keberanian menata ulang cara keputusan dibuat. Pada organisasi layanan publik, tata kelola TI bukan kemewahan. Ia prasyarat menjaga keandalan layanan sekaligus menjaga martabat institusi.

Air adalah amanah. Teknologi adalah alat menjaga amanah itu tetap sampai ke rumah warga tanpa gangguan. Pada akhirnya, tata kelola TI bukan hanya tentang server yang dingin atau kode yang efisien. Ia tentang ketenangan seorang ibu yang tahu bahwa besok pagi air tetap mengalir untuk anak-anaknya. Itulah martabat tertinggi dari organisasi utilitas: ketika sistem bekerja begitu sunyi dan rapi, sehingga keberadaannya tidak perlu dirasakan sebagai masalah.

Diringkas dalam satu kalimat: teknologi hanya menjadi pengungkit ketika organisasi punya keberanian menata keputusan, menata akuntabilitas, dan menata disiplin belajar dari setiap insiden.

Insiden 02.15 ini memakai wajah utilitas air, tetapi pola eskalasi tanpa peta keputusan adalah pola lintas industri. RSUD yang SIM-RS-nya mati di tengah malam, koperasi simpan pinjam yang sistem transaksinya turun di hari gajian, atau sekolah penerima BOS yang aplikasi pelaporannya berhenti menjelang tenggat, semua bertemu di pertanyaan yang sama: siapa pemilik keputusan saat sistem yang dirancang bekerja otomatis ternyata berhenti?

Masalah terbesar banyak organisasi layanan air bukan semata kurangnya teknologi. Masalah yang lebih mendasar adalah belum tertatanya siapa yang berhak memutuskan. Pola yang sama berulang di banyak tempat: organisasi menginvestasikan miliaran untuk sistem SCADA modern, namun ketika sistem itu gagal pada suatu dini hari, operator yang bertugas tidak bisa mendapat keputusan tentang apakah mereka boleh mengambil alih kendali secara manual. Prosedur tidak memberi mereka kewenangan. Atasan tidak bisa dihubungi. Sistem canggih menjadi tidak berguna bukan semata karena komponen teknisnya rusak, melainkan karena desain keputusan tidak pernah dirancang untuk menyertainya. Itu bukan kegagalan teknis saja. Itu kegagalan desain organisasi.

Ukuran kematangan organisasi layanan publik bukan hanya kecanggihan sistemnya. Ukurannya adalah ketenangan warga saat layanan benar-benar dibutuhkan.

Ringkasan Bab

• Tata Kelola TI (IT Governance) bukan soal menambah aplikasi. Soalnya jauh lebih mendasar: memastikan investasi TI benar-benar menguatkan layanan publik. Bukan sekadar menghias laporan.
• Krisis TI kelihatannya masalah teknis. Padahal akarnya kerap di desain keputusan, desain peran, dan desain akuntabilitas. Bukan di server. Bukan di kode.
• Tata kelola adalah pekerjaan Direksi, bukan tugas yang bisa didelegasikan ke Kepala Divisi TI. Divisi bisa menjalankan; Direksi yang menetapkan arah, batas risiko, dan pemilik keputusan.
• Lima domain inti harus jalan bareng, bukan dipilih-pilih: Keselarasan Strategi (Strategic Alignment), Penyerahan Nilai (Value Delivery), Manajemen Sumber Daya (Resource Management), Manajemen Risiko (Risk Management), dan Pengukuran Kinerja (Performance Measurement). Satu lemah, semua goyah.
• Perusahaan utilitas air tidak memiliki ruang besar untuk menunda. Layanan yang dijaga adalah layanan dasar warga, bukan layanan yang bisa ditunda sampai kuartal berikutnya.

Lima Pertanyaan Refleksi untuk Direksi

Lima pertanyaan ini bukan kuis. Ini cermin yang menunjukkan jarak antara kondisi sekarang dengan tata kelola yang sehat. Jawablah dengan jujur, bukan untuk laporan.

1. Apakah organisasi punya komite pengarah TI lintas direktorat yang aktif dan terdokumentasi?
2. Apakah setiap investasi TI punya business case dan indikator manfaat yang diukur setelah implementasi?
3. Apakah ada daftar risiko TI prioritas yang diperbarui berkala dan dibahas di level Direksi?
4. Apakah perubahan sistem kritis mengikuti prosedur perubahan yang sama di seluruh unit?
5. Apakah laporan kinerja TI dibaca sebagai bahan keputusan, bukan hanya lampiran rapat?

Jika jawaban “ya” belum dominan, itu bukan alasan pesimis. Itu titik awal yang sehat untuk membangun program perbaikan bertahap. Setidaknya, pertanyaan-pertanyaan ini sudah memaksa organisasi menghadapi kenyataan.

Tiga Langkah yang Bisa Dimulai Minggu Ini

1. Catat skor awal. Jawab Lima Pertanyaan Refleksi di atas dalam satu halaman, tanpa rapat besar. Ini bukan untuk dilaporkan, ini titik nol Direksi.
2. Tetapkan satu nama. Siapa incident commander resmi untuk sistem TI kritis (SCADA, billing, layanan pelanggan)? Tidak boleh dijawab dengan nama jabatan atau nama tim. Harus nama orang.
3. Jadwalkan rapat 2 jam dalam 2 minggu ini. Hadirkan Direksi dan kepala divisi kunci. Gunakan Daftar Periksa Eksekutif Saat Insiden TI (lihat di bawah) sebagai agenda pembuka.

Daftar Periksa Eksekutif Saat Insiden TI

Pakai daftar ini saat rapat insiden tingkat pimpinan. Bukan dokumen yang ditandatangani sekali; alat kerja yang dibuka setiap kali alarm berbunyi.

1. Apakah incident commander sudah ditetapkan dan diumumkan?
2. Apakah prioritas pemulihan layanan sudah disepakati untuk 2, 6, dan 24 jam pertama?
3. Apakah status data transaksi dinyatakan jelas, termasuk apa yang aman dan apa yang masih diverifikasi?
4. Apakah keputusan komunikasi ke pengguna jasa sudah punya naskah tunggal?
5. Apakah setiap keputusan punya pemilik dan batas waktu eksekusi?
6. Apakah rencana post-incident review sudah dijadwalkan sebelum rapat ditutup?

Daftar periksa tidak menggantikan kepemimpinan. Ia menjaga kualitas kepemimpinan saat tekanan tinggi membuat perhatian mudah terpecah.

Satu Pertanyaan untuk Dibawa ke Rapat Direksi Berikutnya

Jika sistem billing mati malam ini, siapa yang pertama kali Anda telepon, dan apakah orang itu tahu persis apa perannya pada menit ke-15?

Pertanyaan ini sederhana. Jawabannya tidak. Kalau jawabannya ragu, atau berbeda di antara Direksi yang hadir, itulah masalah yang harus diselesaikan lebih dulu daripada membeli sistem baru manapun.

Menuju Bab 2: Mengapa Regulasi Lebih Dulu

Sampai di sini, satu kesimpulan sudah cukup mantap: tata kelola TI adalah pekerjaan Direksi. Pertanyaan wajar berikutnya adalah “kalau begitu, bagaimana mulainya?”. Anda mungkin berharap bab berikutnya langsung membahas struktur komite atau template business case. Urutannya sengaja tidak begitu.

Sebelum membangun struktur, Direksi perlu mengetahui batas wajib yang sudah ditetapkan negara. Tata kelola tanpa pijakan regulasi adalah desain yang melayang; cantik di kertas, tapi mudah jatuh saat audit datang, atau saat pengadilan datang. Ada tiga alasan kenapa bab regulasi datang sebelum bab implementasi.

Pertama, regulasi melindungi Direksi sebagai pengambil keputusan. UU Pelindungan Data Pribadi, UU ITE, ketentuan BUMD, dan perikatan kerja sama layanan publik membentuk batas tanggung jawab yang tidak bisa dilepas begitu saja dengan pendelegasian internal. Tidak memahami regulasi bukan posisi pembelaan yang kuat ketika audit, evaluasi kontrak, atau sengketa muncul.

Kedua, regulasi adalah peta batas risiko yang sudah disepakati negara. Direksi yang merancang tata kelola di atas regulasi mendapatkan satu hal mahal: dasar argumen yang kuat saat berhadapan dengan Dewan Pengawas, komisaris, auditor, mitra pemerintah, atau publik.

Ketiga, regulasi menentukan urutan prioritas implementasi. Kewajiban hukum yang sudah berlaku menjadi prioritas pertama, bukan inisiatif paling populer di rapat. Tanpa peta regulasi, Direksi mudah terjebak membangun yang opsional sambil menunda yang wajib.

Bab 2 menyusun peta itu sekaligus menjelaskan atas dasar apa setiap aturan mengikat: ada yang berlaku karena peran yang dijalankan (mengelola data pribadi, mengoperasikan sistem elektronik, menerima pembayaran), sehingga mengikat semua organisasi utilitas air termasuk operator swasta yang menagih pelanggan langsung; ada yang khusus melekat pada BUMD karena status kepemilikan; dan ada yang lahir dari kontrak kerja sama dengan pemerintah. Bab itu juga menyiapkan langkah inventaris pertama yang bisa dilakukan tanpa anggaran tambahan. Setelah peta itu ada di tangan, baru bab-bab selanjutnya membahas instrumen pelaksanaannya.

Lanjutkan ke Bab 2: Landasan Regulasi di Indonesia.

Referensi & Bacaan Lanjutan

1. Kerangka Tata Kelola TI Global

   • ISACA (2018-2024). Halaman resmi COBIT sebagai kerangka tata kelola dan manajemen informasi serta teknologi.
   • COBIT Resources - ISACA

2. Ketahanan Organisasi Layanan Air di Indonesia

   • World Bank (2021). Laporan ketahanan organisasi layanan air Indonesia dalam menghadapi ketidakpastian operasional dan finansial.
   • World Bank Documents & Reports

3. Acuan Sektor dari Asosiasi Profesional

   • PERPAMSI (berkala). Publikasi sektoral untuk dinamika operasi, pembiayaan, dan transformasi layanan.
   • PERPAMSI

4. Panduan Tata Kelola Air untuk Sektor Publik

   • OECD (2015, diperbarui berkala). Prinsip tata kelola layanan air untuk organisasi publik dan pemangku kepentingan.
   • OECD Water Governance Initiative

5. Hak atas Air dalam Kerangka Hukum Nasional

   • Pemerintah Republik Indonesia (2019). Undang-Undang Nomor 17 Tahun 2019 tentang Sumber Daya Air.
   • UU No. 17 Tahun 2019 - JDIH BPK

6. Pelindungan Data Pribadi untuk Layanan Digital

   • Pemerintah Republik Indonesia (2022). Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi.
   • UU No. 27 Tahun 2022 - JDIH BPK

7. Standar Tata Kelola TI Tingkat Dewan

   • ISO (2024). ISO/IEC 38500:2024 sebagai standar tata kelola TI untuk tingkat pimpinan organisasi.
   • ISO/IEC 38500:2024

8. Status Global Implementasi Tata Kelola TI

   • IT Governance Institute (2008). Laporan global implementasi tata kelola TI sebagai pembanding historis maturitas organisasi.
   • ISACA Archive

9. Ketahanan Siber dan Manajemen Risiko Organisasi

   • National Institute of Standards and Technology (2024). Cybersecurity Framework sebagai acuan pengelolaan risiko siber berbasis fungsi organisasi.
   • NIST Cybersecurity Framework

10. Kerangka Pembangunan Infrastruktur dan Layanan Dasar

• Bappenas Republik Indonesia. Dokumen perencanaan pembangunan nasional sebagai konteks target layanan dasar.
• Portal Dokumen Perencanaan - Bappenas

11. Acuan Statistik Nasional untuk Perencanaan Sektor Publik

• Badan Pusat Statistik. Rilis data sektoral untuk dukungan analisis kebijakan dan evaluasi layanan publik.
• Badan Pusat Statistik

Catatan akses sumber: Tautan di atas mengarah ke portal resmi pemerintah, lembaga standar, atau penerbit. Sebagian dokumen tersedia bebas; dokumen ISO/IEC dan jurnal akademik tertentu berbayar di situs resmi. Apabila tautan berubah karena pembaruan portal, gunakan judul resmi dan nomor regulasi sebagai dasar pencarian.

Penafian: Tulisan ini adalah pandangan pribadi penulis berdasarkan pengalaman praktis dan studi independen. Naskah ini tidak merepresentasikan sikap institusional atau komitmen formal dari organisasi mana pun.