Bab 4: COBIT Pragmatis: Membangun Struktur Tanpa Birokrasi Ekstra

Track: Praktisi (P); untuk IT practitioner, auditor, dan pelaksana teknis.

Intisari Eksekutif: Tiga Bekal untuk Bertahan

Inti bab ini bisa dipadatkan menjadi tiga sikap yang membedakan kerangka COBIT yang hidup dari tumpukan dokumen yang mati:

• COBIT bukan proyek implementasi; ia bahasa bersama. Nilai utamanya bukan pada kelengkapan kerangkanya, melainkan pada kemampuan menerjemahkan masalah teknis menjadi diskusi tata kelola yang bisa dipahami Direksi.
• Mulai dari 3-5 proses, bukan 40. Organisasi yang mencoba mengimplementasikan semua proses COBIT sekaligus kerap gagal. Pilih yang paling kritis untuk konteks Anda, kuasai dulu.
• Kematangan bukan tujuan akhir; kematangan yang cukup untuk mengelola risiko utama adalah targetnya. Level 3 yang konsisten jauh lebih berharga dari level 5 di atas kertas.

Navigasi Bab: Apa yang Akan Anda Hadapi?

Diagram 4.1 menunjukkan alur Bab 4, yang terbagi dua paruh. Bagian A (Memahami) membongkar prinsip dan komponen COBIT 2019 (§4.1). Bagian B (Menerapkan) menerjemahkannya: memetakan objektif yang relevan untuk utilitas air (§4.2), lalu merakit perangkat awal yang bisa dipakai di rapat Direksi (§4.3).

Pembuka: Rapat yang Tidak Bisa Menjawab Satu Pertanyaan

Pada 27 Juni 2017, perusahaan logistik global Maersk terdampak serangan NotPetya. Serangan ini sering disebut ransomware, tetapi secara praktis bekerja seperti perusak sistem: pesan tebusan muncul, namun pemulihan data tidak sesederhana membayar tebusan. Dalam laporan triwulan 2017, Maersk memperkirakan dampak negatif serangan ini terhadap hasil usaha berada di kisaran USD 200-300 juta.

Dalam paparan publik setelah kejadian, Chairman Maersk Jim Hagemann Snabe menyebut skala pemulihannya: sekitar 45.000 PC, 4.000 server, dan 2.500 aplikasi harus dipasang ulang dalam sepuluh hari. Di lapangan, dampaknya bukan istilah teknis. Terminal terganggu. Pemesanan baru sempat tidak bisa dilakukan. Sebagian pekerjaan kembali ke kertas, surel pribadi, WhatsApp, dan spreadsheet.

Satu detail pemulihan Maersk sering dikutip karena terdengar hampir tidak masuk akal: satu domain controller di Ghana selamat karena sedang terputus dari jaringan akibat gangguan listrik. Salinan data itulah yang membantu memulihkan lapisan identitas jaringan. Tetapi pelajaran tata kelolanya bukan bahwa Maersk sudah punya kerangka keputusan yang sempurna sebelum krisis. Pelajarannya lebih keras: ketika sistem inti jatuh, organisasi membutuhkan bahasa keputusan yang cukup jelas untuk menentukan apa yang dipulihkan dulu, risiko apa yang diterima sementara, siapa yang boleh mengubah prioritas, dan bagaimana Direksi memantau pemulihan tanpa menenggelamkan tim teknis.

Kisah pembuka ini merujuk pada kejadian publik yang terdokumentasi luas: laporan triwulan Maersk 2017 dan paparan publik manajemennya, serta liputan media internasional. Buku ini tidak mengklaim Maersk memiliki tata kelola sempurna; yang dipinjam adalah pelajaran bahasa keputusan saat krisis.

Sekarang, bayangkan yang terjadi bukan perusahaan logistik global, tetapi perusahaan utilitas air Indonesia dengan 50.000 pelanggan. Serangan datang. Sistem billing mati. Sistem SCADA tidak bisa diakses. Tidak ada domain controller cadangan di Ghana. Tidak ada kerangka keputusan. Siapa yang memutuskan? Siapa yang mengeskalasi? Siapa yang berbicara ke publik?

Di sinilah COBIT masuk. Bukan sebagai daftar 40 objektif yang harus dihafal. Tapi sebagai bahasa keputusan, satu kerangka yang memastikan bahwa ketika krisis datang, organisasi Anda tidak bergantung pada keberuntungan memiliki server di Ghana.

Kalau Anda jajaran Direksi yang membaca bab ini, tugas Anda bukan menjadi ahli COBIT. Tugas Anda adalah memastikan tim tidak memakai COBIT sebagai beban administratif baru, melainkan sebagai bahasa bersama untuk menjawab tiga pertanyaan: risiko TI mana yang paling kritis, investasi TI mana yang benar-benar memberi nilai, dan siapa pemilik keputusan saat dua prioritas saling bertabrakan.

Bab ini menyaring COBIT 2019 menjadi alat kerja yang bisa dipakai. Urutannya praktis: prinsip dasar, objektif yang paling relevan untuk perusahaan utilitas air, prioritas implementasi, lalu asesmen kematangan dan analisis kesenjangan sederhana. Ukuran keberhasilan bab ini bukan apakah pembaca hafal 40 objektif COBIT, melainkan apakah pembaca tahu lima objektif pertama yang harus dibahas di ruang rapat.

4.1 COBIT 2019: Prinsip dan Komponen

COBIT (Control Objectives for Information and Related Technologies) pertama kali diperkenalkan oleh ISACA pada tahun 1996. Selama lebih dari dua dekade, framework ini terus berkembang mengikuti perubahan lanskap teknologi dan praktik tata kelola. Versi terbaru, COBIT 2019, memperkenalkan pendekatan yang lebih fleksibel dan terintegrasi dengan governance perusahaan secara keseluruhan.

4.1.1 Sejarah Singkat dan Evolusi COBIT

Memahami evolusi COBIT membantu kita mengapresiasi mengapa framework ini dirancang seperti sekarang. Versi pertama COBIT pada tahun 1996 berfokus pada control objectives untuk audit TI. Pada saat itu, kebutuhan utama adalah memiliki kerangka acuan untuk auditor dalam mengevaluasi kontrol TI.

COBIT 4.1 (dirilis 2007) memperkenalkan konsep 34 proses yang dikelompokkan dalam empat domain: Plan and Organize, Acquire and Implement, Deliver and Support, dan Monitor and Evaluate. Versi ini sangat populer dan digunakan secara luas sebagai standar de facto untuk tata kelola TI.

COBIT 5 (2012) merevolusi framework dengan mengenalkan lima prinsip dan pendekatan yang lebih holistik. Untuk pertama kalinya, COBIT secara eksplisit memisahkan antara governance dan management, serta menekankan pentingnya enablers selain proses.

COBIT 2019, edisi yang menjadi acuan buku ini, membangun di atas fondasi COBIT 5 dengan peningkatan signifikan: lebih fleksibel, lebih terintegrasi dengan tata kelola korporasi, dan lebih mudah disesuaikan dengan konteks organisasi spesifik. Versi ini memperkenalkan konsep sistem tata kelola (governance system), komponen tata kelola (governance components), faktor desain (design factors), serta pembedaan yang lebih jelas antara objektif tata kelola dan objektif manajemen.

4.1.2 Prinsip 1: Menghasilkan Nilai bagi Pemangku Kepentingan

Prinsip pertama COBIT 2019 menegaskan bahwa sistem tata kelola harus menghasilkan nilai dari penggunaan informasi dan teknologi. Nilai itu muncul dari keseimbangan tiga hal: manfaat yang ingin dicapai, risiko yang sanggup diterima, dan sumber daya yang tersedia. Ini terdengar sederhana, tetapi dalam praktik sering dilupakan. Banyak organisasi menerapkan framework atau teknologi karena tren, tekanan vendor, atau kecemasan menghadapi audit; bukan karena kebutuhan nyata pemangku kepentingan sudah dipetakan.

Untuk perusahaan utilitas air, pemangku kepentingan utama dapat dibaca dalam lima kelompok.

Pertama, pengguna jasa. Mereka mengharapkan layanan yang andal, kualitas produk yang konsisten, proses pembayaran yang mudah, respons cepat terhadap keluhan, dan informasi layanan yang transparan. Dari perspektif TI, harapan itu diterjemahkan menjadi ketersediaan sistem yang tinggi, integrasi kanal pembayaran, modul layanan pelanggan yang efektif, serta portal informasi yang akurat.

Kedua, pemegang saham, biasanya pemerintah daerah. Kepentingannya mencakup keberlanjutan finansial organisasi, pencapaian target pelayanan, kepatuhan regulasi, dan transparansi operasi. Dari perspektif tata kelola TI, ini menuntut sistem yang mampu mendukung perencanaan keuangan, dashboard kinerja operasional, pelaporan yang dapat diaudit, dan dokumentasi keputusan investasi.

Ketiga, regulator dan pihak pengawas seperti Kementerian PUPR, Kemendagri, BSSN, auditor sektor publik, serta BI/OJK ketika organisasi berurusan dengan kanal pembayaran atau mitra jasa keuangan. Mereka membutuhkan data kinerja, bukti kepatuhan, serta pelaporan insiden jika terjadi gangguan signifikan. Sistem TI harus menyediakan modul pelaporan, bukti kontrol, dan jejak audit yang cukup untuk diperiksa.

Keempat, karyawan. Mereka membutuhkan alat kerja yang efektif, pelatihan yang memadai, prosedur yang jelas, dan sistem keamanan yang mendukung pekerjaan tanpa membuat operasi harian macet. Tata kelola TI yang baik tidak membuat karyawan merasa diawasi semata; ia membuat pekerjaan lebih jelas dan risiko lebih terkendali.

Kelima, masyarakat luas sebagai penerima dampak tidak langsung. Mereka berkepentingan pada keberlanjutan lingkungan, tanggung jawab sosial, dan transparansi penggunaan sumber daya publik. Pada titik ini, TI menjadi alat akuntabilitas, bukan sekadar alat administrasi.

Tantangan dalam memenuhi kebutuhan pemangku kepentingan adalah adanya potensi konflik. Misalnya, persyaratan keamanan mungkin bertentangan dengan kemudahan penggunaan. Tekanan biaya rendah dari pemegang saham mungkin bertentangan dengan kebutuhan investasi TI dari karyawan. Prinsip pertama COBIT mengakui realitas ini dan menekankan perlunya pilihan sulit (trade-off) yang terdokumentasi dan disepakati.

4.1.3 Prinsip 2: Menggunakan Pendekatan Holistik

Prinsip kedua menekankan bahwa tata kelola tidak bisa hanya mengurus proses. COBIT 2019 melihat sistem tata kelola sebagai kombinasi beberapa komponen yang harus bekerja bersama. Jika hanya satu komponen dibenahi, hasilnya biasanya rapuh.

Tujuh komponen tata kelola yang perlu dibaca bersama adalah:

1. Proses. Himpunan praktik yang terdefinisi untuk mencapai tujuan operasional maupun tata kelola. Contoh: proses manajemen insiden dan manajemen vendor.
2. Struktur organisasi. Entitas pengambilan keputusan dengan garis kewenangan yang jelas. Contoh: komite pengarah TI (IT steering committee).
3. Prinsip, kebijakan, dan kerangka kerja. Arahan manajemen yang memandu perilaku sehari-hari. Contoh: kebijakan tata kelola data dan kebijakan perlindungan privasi.
4. Informasi. Seluruh informasi yang diproduksi dan digunakan organisasi. Informasi adalah produk kunci dari sistem tata kelola itu sendiri.
5. Kultur, etika, dan perilaku. Norma tak tertulis tentang bagaimana organisasi memperlakukan dan mengambil keputusan TI.
6. Orang, keterampilan, dan kompetensi. Ahli dan sumber daya manusia yang melaksanakan sistem.
7. Layanan, infrastruktur, dan aplikasi. Perangkat fisik dan logis yang mendukung sistem TI.

Penting untuk dipahami bahwa ketujuh komponen ini saling terkait. Fokus pada satu aspek saja tanpa memperhatikan yang lain akan menghasilkan perbaikan yang tidak berkelanjutan. Sebagai contoh, mengimplementasikan teknologi keamanan canggih tanpa memperbaiki kultur keamanan atau pelatihan karyawan tidak akan efektif. Teknologi mungkin diabaikan atau bahkan di-bypass oleh karyawan yang tidak mengerti alasannya.

4.1.4 Prinsip 3: Menjaga Sistem Tata Kelola Tetap Dinamis

Prinsip ketiga mengingatkan bahwa sistem tata kelola tidak boleh statis. Perubahan regulasi, model bisnis, ancaman siber, teknologi, dan kemampuan organisasi harus mengubah desain tata kelola. Di perusahaan utilitas air, kebutuhan tata kelola saat hanya memakai aplikasi billing lokal berbeda dengan kebutuhan saat organisasi mulai memakai pembayaran digital, cloud, sistem pelanggan terpadu, atau perangkat lapangan berbasis IoT.

Prinsip ini penting karena banyak organisasi memperlakukan dokumen tata kelola sebagai artefak sekali jadi. Dokumen disahkan, dimasukkan ke folder, lalu dibuka lagi ketika audit. Dalam COBIT 2019, sistem tata kelola harus ditinjau ulang ketika konteks berubah. Perubahan bukan tanda kegagalan; perubahan adalah tanda bahwa tata kelola hidup.

4.1.5 Prinsip 4: Memisahkan Tata Kelola dari Manajemen

Prinsip keempat adalah pembedaan yang jelas antara governance dan management. COBIT 2019 mendefinisikan perbedaannya secara praktis.

Governance adalah aktivitas evaluasi, arahan, dan pemantauan oleh governing body (biasanya dewan direksi atau dewan pengawas) untuk memastikan bahwa TI mendukung tujuan organisasi. Governance menjawab pertanyaan: “Apakah kita melakukan hal yang benar?” dan “Bagaimana kita memastikan keberhasilan jangka panjang?”

Management adalah aktivitas perencanaan, pembangunan, pengoperasian, dan dukungan oleh manajemen untuk mencapai tujuan yang ditetapkan oleh governance. Management menjawab pertanyaan: “Apakah kita melakukannya dengan benar?” dan “Bagaimana kita mencapai target yang ditetapkan?”

Pemisahan ini penting untuk beberapa alasan. Pertama, ia mencegah konflik kepentingan. Jika manajemen TI juga bertanggung jawab atas tata kelola, ada risiko bahwa mereka akan menilai kinerja mereka sendiri secara tidak objektif. Kedua, ia memastikan akuntabilitas yang jelas. Dewan direksi bertanggung jawab atas tata kelola, manajemen bertanggung jawab atas pelaksanaan. Ketiga, ia memfasilitasi pengawasan independen. Fungsi audit dapat mengevaluasi manajemen atas nama dewan direksi.

Dalam praktiknya, pemisahan ini diimplementasikan melalui pembentukan komite pengarah TI (IT steering committee) yang diketuai oleh Direksi non-TI, penugasan fungsi audit yang independen dari manajemen TI, mekanisme pelaporan dari manajemen TI ke komite pengarah dan Direksi, serta keterlibatan Direksi dalam keputusan investasi TI besar.

4.1.6 Prinsip 5: Disesuaikan dengan Kebutuhan Organisasi

Prinsip kelima menegaskan bahwa COBIT harus disesuaikan dengan konteks organisasi. COBIT 2019 menyediakan faktor desain untuk membantu organisasi menentukan objektif mana yang lebih penting. Faktor seperti strategi organisasi, profil risiko, persyaratan kepatuhan, model sumber daya TI, peran TI dalam bisnis, dan adopsi teknologi memengaruhi prioritas.

Untuk perusahaan utilitas air, artinya jelas: organisasi tidak perlu memulai dari seluruh 40 objektif. Organisasi dapat memulai dari objektif yang paling terkait dengan layanan, risiko operasional, keamanan, data pelanggan, investasi TI, dan kepatuhan. Prinsip ini menjadi dasar mengapa bab ini memilih prioritas awal, bukan menyajikan semua objektif sebagai daftar kerja.

4.1.7 Prinsip 6: Tata Kelola End-to-End

Prinsip keenam menekankan bahwa tata kelola informasi dan teknologi harus mencakup seluruh organisasi, bukan hanya fungsi TI. Ini adalah kebalikan dari pendekatan silo di mana setiap unit atau fungsi mengelola sistemnya sendiri tanpa koordinasi.

Dalam konteks perusahaan utilitas air dengan banyak unit operasional, prinsip ini sangat relevan. Bayangkan sebuah perusahaan utilitas air dengan lima unit di lokasi berbeda. Tanpa pendekatan menyeluruh (end-to-end), setiap unit mungkin memakai sistem berbeda, prosedur berbeda, format data berbeda, dan teknologi baru yang diadopsi tanpa koordinasi.

Konsekuensinya:

• integrasi data menjadi sangat sulit
• pembandingan (benchmarking) antar unit tidak dapat dilakukan
• pemborosan terjadi karena duplikasi investasi
• pengambilan keputusan tingkat korporat terhambat oleh inkonsistensi data

Pendekatan menyeluruh COBIT menuntut arsitektur sistem yang terintegrasi, standar data yang konsisten, proses bisnis yang terdokumentasi, struktur tata kelola yang jelas untuk pengambilan keputusan lintas unit, dan teknologi yang mendukung interoperabilitas.

Skenario komposit yang umum dijumpai: satu organisasi memiliki beberapa unit operasional dengan sistem billing berbeda. Ketika manajemen pusat ingin menyusun laporan keuangan konsolidasi, tim keuangan harus merekonsiliasi data dari sistem yang tidak kompatibel. Masalahnya bukan hanya teknis integrasi; masalahnya adalah tidak ada keputusan tata kelola yang menetapkan standar data dan arsitektur bersama sejak awal.

4.1.8 Realitas Lapangan: COBIT untuk Tim TI Kecil

Membaca konsep di atas, seorang Direktur perusahaan utilitas air mungkin mengajukan keberatan yang sangat masuk akal: “Staf TI kami hanya beberapa orang. Mereka menjaga jaringan, aplikasi billing, komputer kasir, dan server. Kapan mereka punya waktu menyusun dokumen tata kelola?”

Keberatan itu valid. Sering kali, Direksi menuntut penerapan tata kelola TI (IT governance) tetapi lupa akan satu fakta fundamental: tata kelola TI membutuhkan biaya, waktu, dan kapasitas administratif. Staf teknis yang sehari-hari menjaga operasi belum tentu punya ruang untuk menyusun kerangka acuan kerja, dokumen justifikasi investasi, evaluasi vendor, atau dokumen kepatuhan yang kuat secara audit.

Bagi perusahaan utilitas air, memisahkan governance dan management berarti menyadari bahwa Kepala Bagian TI tidak boleh dijadikan satu-satunya penanggung jawab dokumen tata kelola.

• Jika organisasi menuntut tata kelola yang standar, organisasi perlu menyediakan kapasitas analis tata kelola/kepatuhan TI yang membantu administrasi, evaluasi vendor, dan kepatuhan regulasi.
• Jika anggaran rekrutmen belum ada, fungsi tata kelola seperti penyusunan kerangka acuan kerja, dokumen pengadaan, dan perlindungan kontraktual vendor harus didampingi aktif oleh Bagian Hukum dan Bagian Pengadaan, bukan dilempar sepenuhnya ke Manajer TI.

Anda tidak perlu menyerap seluruh jargon akademis COBIT. Anda hanya perlu memahami satu hal: jangan biarkan departemen TI berjuang sendirian membuat dokumen tata kelola. Bagilah beban administrasinya dengan departemen fungsional lain, atau tata kelola Anda hanya akan berakhir sebagai formalitas di atas kertas.

Ringkas Eksekutif: Prinsip Dasar COBIT Jika Anda hanya punya waktu 1 menit:

• Fokus pada Nilai: Proyek TI harus membuktikan manfaat bisnis nyata (penurunan kebocoran, kepuasan pelanggan naik).
• Pisahkan Keputusan dari Eksekusi: Direksi menetapkan arah dan batasan (tata kelola/EDM), tim TI mengeksekusi dan melaporkan (manajemen/APO, BAI, DSS).
• Sesuaikan Skala: Anda tidak perlu menerapkan semua modul COBIT. Ambil yang paling mendesak bagi masalah operasional Anda hari ini.

Checkpoint Bagian A ke Bagian B Sampai di sini Anda sudah memegang KONSEP: enam prinsip, pemisahan tata kelola dari manajemen, dan empat klaster proses. Itu Bagian A. Paruh kedua bab ini, Bagian B, soal MENERAPKANNYA: memetakan objektif ke proses utilitas (§4.2), lalu merakit lima kontrol pertama, model kematangan, dan roadmap (§4.3). Jika konsep di atas masih kabur, ulangi §4.1 dulu; tanpa fondasi ini, sisanya akan terasa seperti daftar istilah belaka.

4.2 Pemetaan COBIT ke Proses Utilitas

Setelah memahami prinsip dasar COBIT, langkah selanjutnya adalah memetakan objektif tata kelola dan manajemen COBIT ke proses bisnis spesifik perusahaan utilitas air. COBIT 2019 mendefinisikan 40 objektif: sebagian berada di domain tata kelola EDM, sebagian lain berada di domain manajemen APO, BAI, DSS, dan MEA. Tidak semua objektif ini memiliki prioritas yang sama untuk perusahaan utilitas air.

4.2.1 Objektif EDM: Lapisan Tata Kelola

Domain Evaluate, Direct, and Monitor (EDM) adalah lapisan tata kelola yang paling strategis. Objektif dalam domain ini menjawab pertanyaan tentang bagaimana organisasi diarahkan dan dipantau dari perspektif informasi dan teknologi.

EDM01: Ensured Governance Framework Setting and Maintenance

Objektif ini memastikan bahwa kerangka tata kelola TI ditetapkan, dipahami, dan dipelihara. Untuk perusahaan utilitas air, ini berarti kebijakan tata kelola TI disahkan oleh Direksi, struktur tata kelola seperti komite pengarah dibentuk dan benar-benar berfungsi, serta kerangka tata kelola ditinjau berkala agar tetap relevan dengan perubahan organisasi.

EDM02: Ensured Benefits Delivery

Objektif ini memastikan bahwa investasi TI menghasilkan nilai yang dijanjikan. Dalam konteks utilitas, contoh aplikasinya meliputi:

• business case untuk setiap proyek TI yang menghubungkan investasi dengan nilai bisnis
• pengukuran post-implementation untuk memverifikasi bahwa nilai tercapai
• mekanisme koreksi jika nilai tidak tercapai

EDM03: Ensured Risk Optimization

Ini adalah salah satu objektif paling kritis untuk perusahaan utilitas. Objektif ini memastikan bahwa risiko TI diidentifikasi, ditoleransi, diperlakukan, dan dipantau secara berkelanjutan. Implementasi praktisnya meliputi IT risk register yang terdokumentasi dan ditinjau berkala, risk appetite yang ditetapkan Direksi, rencana mitigasi untuk risiko prioritas, dan pelaporan risiko TI ke manajemen puncak secara berkala.

EDM04: Ensured Resource Optimization

Objektif ini memastikan bahwa aset TI (perangkat keras, software, kompetensi manusia, dan data) digunakan secara efisien dan efektif. Untuk utilitas, ini berarti inventaris aset TI yang lengkap dan terkini, perencanaan kapasitas yang memadai, manajemen siklus hidup aset, serta evaluasi penggunaan cloud computing atau shared services jika memang lebih efisien.

EDM05: Ensured Stakeholder Engagement

Objektif ini memastikan pemangku kepentingan dilibatkan dan menerima informasi yang relevan tentang kinerja TI, konsumsi sumber daya, risiko, dan manfaat. Implementasi praktisnya meliputi:

• dashboard kinerja TI yang dapat diakses direksi
• laporan triwulan ke steering committee
• transparansi penggunaan anggaran TI

4.2.2 Objektif BAI: Bangun, Akuisisi, dan Implementasi

Domain Build, Acquire, Implement (BAI) mencakup aktivitas pembangunan dan perolehan solusi TI.

BAI03: Managed Solutions Identification and Build

Objektif ini penting untuk memastikan bahwa solusi TI yang dikembangkan atau diperoleh sesuai dengan kebutuhan bisnis. Dalam konteks utilitas, kebutuhan bisnis harus didefinisikan dengan jelas sebelum pengembangan atau pengadaan, feasibility study dilakukan untuk opsi yang tersedia, dan solusi yang dipilih diverifikasi terhadap kebutuhan layanan.

BAI06: Managed IT Changes

Objektif ini sangat penting untuk lingkungan dengan sistem kritis seperti SCADA. Manajemen perubahan (change management) yang buruk adalah salah satu penyebab utama insiden operasional. Implementasi praktisnya mencakup prosedur perubahan yang terdokumentasi, dewan penasihat perubahan (change advisory board) untuk mengesahkan perubahan signifikan, dan mekanisme pemulihan balik (rollback) jika perubahan menyebabkan masalah.

4.2.3 Objektif DSS: Layanan dan Dukungan

Domain Deliver, Service, Support (DSS) mencakup operasional TI sehari-hari.

DSS01: Managed Operations

Objektif ini adalah fondasi untuk memastikan sistem kritis tersedia sesuai target layanan. Implementasi praktisnya mencakup prosedur operasional untuk semua sistem kritis, pemantauan 24/7 untuk sistem utama, helpdesk atau service desk untuk menangani permintaan pengguna, dan maintenance preventif untuk infrastruktur TI.

DSS05: Managed Security Services

Dengan meningkatnya ancaman siber, objektif ini menjadi semakin krusial. Implementasinya mencakup firewall dan intrusion detection, kontrol akses berbasis peran, enkripsi data sensitif, security awareness training, dan incident response untuk insiden keamanan.

DSS06: Managed Business Process Controls

Objektif ini memastikan bahwa kontrol bisnis yang diimplementasikan dalam sistem TI berfungsi sesuai desain. Untuk utilitas, ini berkaitan dengan:

• Kontrol otomatis dalam sistem billing untuk mencegah revenue leakage.
• Kontrol dalam sistem SCADA untuk mencegah operasi yang tidak aman.
• Kontrol akses untuk melindungi data pelanggan.

4.2.4 Objektif APO: Selaras, Rencana, dan Organisasi

Domain Align, Plan, Organize (APO) mencakup perencanaan strategis dan organisasi TI.

APO02: Managed Strategy

Objektif ini memastikan bahwa strategi TI selaras dengan strategi bisnis. Implementasinya mencakup rumusan strategi TI yang diturunkan dari strategi bisnis, roadmap implementasi TI jangka menengah, dan mekanisme penyesuaian strategi jika kondisi bisnis berubah.

APO10: Managed Vendors

Objektif ini memastikan hubungan vendor dikelola secara sadar, bukan hanya berdasarkan kontrak pengadaan. Untuk perusahaan utilitas air yang banyak bergantung pada penyedia aplikasi billing, perangkat lapangan, cloud, jaringan, dan kanal pembayaran, APO10 membantu memastikan seleksi, pemantauan, eskalasi, dan risiko vendor dikelola secara konsisten.

APO14: Managed Data

Data adalah aset strategis yang sering kurang dikelola. Objektif ini memastikan data diklasifikasikan berdasarkan sensitivitas, kualitas data dipantau dan diperbaiki, keamanan data diimplementasikan sesuai klasifikasi, dan akses data dikontrol berdasarkan kebutuhan.

4.2.5 Mapping ke Proses Bisnis Utilitas

Untuk membantu visualisasi hubungan antara COBIT dan proses bisnis utilitas, Tabel 4.1 menyajikan pemetaan praktis. Tabel ini tidak dimaksudkan sebagai daftar final; ia adalah titik awal diskusi Direksi, TI, operasional, keuangan, dan audit internal.

Tabel 4.1 Pemetaan proses bisnis utilitas ke objektif COBIT prioritas

Pemetaan ini menunjukkan bahwa setiap proses bisnis utilitas didukung oleh beberapa objektif COBIT. Pendekatan ini membantu organisasi memprioritaskan implementasi berdasarkan proses bisnis yang paling kritis.

Pola yang berulang di banyak organisasi menunjukkan bahwa standar internasional tidak gagal karena terlalu tinggi. Ia gagal ketika diterjemahkan terlalu besar, terlalu cepat, dan tanpa pemilik keputusan yang jelas. Dengan pemetaan seperti Tabel 4.1, Direksi dapat mengubah COBIT dari daftar istilah menjadi peta prioritas.

4.2.6 Skenario Komposit: Pemetaan COBIT untuk Digitalisasi Meter

Organisasi X adalah skenario komposit, bukan klaim tentang satu perusahaan tertentu. Skenario ini menggambarkan pola yang umum dijumpai ketika perusahaan utilitas air menengah menjalankan proyek digitalisasi meter pada puluhan ribu sambungan rumah tangga. Proyek ini meliputi pemasangan smart meter, sistem pembacaan meter otomatis (Automatic Meter Reading, AMR), dan portal pelanggan untuk melihat penggunaan air secara real-time.

Tantangan yang dihadapi: proyek ini melibatkan investasi signifikan, perubahan proses operasional, dan dampak langsung ke pengalaman pelanggan. Namun, ketika dikaji menggunakan kerangka COBIT, terdapat beberapa gap yang perlu diantisipasi:

Empat kesenjangan utama muncul ketika proyek ini dikaji dengan lensa COBIT, masing-masing dengan objektif dan tindakan perbaikannya.

Tabel 4.1b Kesenjangan tata kelola proyek digitalisasi meter dan pemetaan COBIT-nya

Dengan menggunakan pemetaan COBIT, Organisasi X dapat mengidentifikasi kesenjangan secara sistematis dan menyusun rencana perbaikan yang terstruktur. Hasil yang paling penting bukan klaim bahwa proyek pasti sukses, melainkan bahwa Direksi memiliki dasar lebih kuat untuk memutuskan prioritas, menagih manfaat, dan mengelola risiko selama implementasi berjalan.

4.2.7 Matriks Prioritas Objektif COBIT untuk Utilitas

Tidak semua 40 objektif tata kelola dan manajemen COBIT memiliki prioritas yang sama. Tabel 4.2 menyusun prioritas awal untuk perusahaan utilitas air. Prioritas ini perlu divalidasi terhadap konteks masing-masing organisasi, tetapi cukup kuat sebagai titik awal.

Tabel 4.2 Prioritas awal objektif COBIT untuk perusahaan utilitas air

Prioritas pada Tabel 4.2 ditetapkan berdasarkan tiga pertimbangan: dampak ke operasi layanan jika objektif COBIT tidak terpenuhi, risiko regulasi jika diabaikan, dan kompleksitas implementasi.

Organisasi sebaiknya fokus pada P1 dan P2 dalam 12-18 bulan pertama, kemudian meluas ke P3 dan P4 setelah fondasi tata kelola TI sudah matang.

4.2.8 Objektif yang Sengaja Ditunda: Peta Lengkap dan Justifikasi

Buku ini memilih 17 dari 40 objektif COBIT 2019 sebagai prioritas implementasi. Pilihan ini bukan sembarang. Bagian ini menjelaskan metode pemilihannya dan, yang sama penting, mengapa 23 objektif lainnya tidak dimasukkan dalam daftar prioritas awal.

Metode Pemilihan: Tiga Faktor Desain Utama

COBIT 2019 menyediakan sebelas faktor desain (design factors) untuk membantu organisasi menyesuaikan (tailor) kerangka tata kelola. Buku ini menggunakan tiga yang paling relevan untuk konteks perusahaan utilitas air di Indonesia:

1. Profil Risiko (Risk Profile): Risiko tertinggi pada utilitas air adalah gangguan operasional (downtime), kegagalan kepatuhan regulasi, dan kebocoran data pelanggan. Objektif yang paling langsung mengurangi ketiga risiko ini diprioritaskan.
2. Peran TI dalam Organisasi (IT Role): Di utilitas air, TI adalah fungsi strategic sekaligus support: SCADA, billing, dan layanan pelanggan sangat bergantung pada TI. Objektif yang menjamin ketersediaan, keamanan, dan kontrol operasional dipilih lebih dulu.
3. Ancaman dan Kepatuhan (Compliance & Threat Landscape): UU PDP, UU ITE, PP PSTE, dan standar SPAM menetapkan kewajiban minimum. Objektif yang paling langsung memenuhi kewajiban ini didahulukan.

Pembaca yang menginginkan pendekatan lebih formal disarankan merujuk ke COBIT 2019 Design Guide: Designing an Information and Technology Governance Solution (ISACA, 2018), khususnya Bab 5 tentang design factors dan workbook penentuan prioritas objektif.

23 Objektif yang Ditunda beserta Alasannya

Tabel berikut mendaftar objektif yang tidak masuk prioritas awal buku ini, dengan alasan penundaannya. Penundaan bukan berarti tidak penting; ia berarti objektif tersebut memberikan hasil terbaik setelah fondasi prioritas awal berjalan.

Tabel 4.2b Objektif COBIT yang ditunda dan alasan penundaannya

Pembaca yang terbiasa dengan COBIT 2019 akan mengenali bahwa buku ini memilih rute “fondasi dulu, perluasan bertahap.” Ini adalah pilihan sadar: organisasi utilitas air dengan kematangan rendah (level 1-2) akan lebih diuntungkan oleh 17 objektif yang dijalankan dengan disiplin daripada 40 objektif yang hanya ada di atas kertas.

Rencana Perluasan (Fase 2):

Setelah 18-24 bulan fondasi berjalan, organisasi dapat menambah objektif berikut:

• APO03, APO04, APO05, BAI04, BAI05, DSS03, DSS04, MEA03, MEA04

Rencana Perluasan (Fase 3):

Setelah 36+ bulan, saat kematangan mendekati level 3, tambahkan:

• APO01, APO06, APO07, APO08, APO09, APO11, BAI01, BAI02, BAI07, BAI08, BAI09, BAI10, BAI11

Urutan ini bukan resep universal. Setiap organisasi perlu menyesuaikan berdasarkan profil risiko, kapasitas, dan hasil asesmen kematangan (Bab 10).

Ringkas Eksekutif: Matriks 4 Klaster Proses TI Jangan tenggelam di singkatan. COBIT membagi aktivitas TI jadi 4 blok besar:

1. EDM (Evaluate, Direct, Monitor): Tugas Direksi. Mengarahkan investasi, mengatur batas risiko.
2. APO (Align, Plan, Organize): Tugas Kepala Divisi. Merencanakan strategi, anggaran, dan kapasitas.
3. BAI (Build, Acquire, Implement): Proyek pengadaan dan implementasi sistem baru.
4. DSS (Deliver, Service, Support): Operasi harian, helpdesk, pemulihan insiden. Jika ini masih berantakan, perbaiki ini dulu sebelum beli sistem baru.

4.3 Perangkat Awal untuk Utilitas

Bagian ini menyediakan panduan praktis untuk memulai implementasi COBIT di perusahaan utilitas air. Perangkat awal ini dirancang untuk memberi kemenangan cepat (quick wins) sambil membangun fondasi perbaikan berkelanjutan.

4.3.1 Kemenangan Cepat: 5 Kontrol COBIT Pertama

Berikut adalah lima kontrol yang dapat memberikan dampak signifikan dengan implementasi relatif sederhana:

Lima kontrol berikut berdampak signifikan dengan implementasi relatif sederhana. Polanya sama: mulai dari versi minimum, lalu kembangkan seiring waktu.

1. Komite pengarah TI (IT steering committee). Forum keputusan strategi dan prioritas TI, diketuai Direktur Utama atau direktur non-TI, beranggota semua direktorat, bertemu bulanan. Quick win: bentuk komitenya dulu dengan terms of reference sederhana. Nilainya cepat terasa; konflik prioritas antar-fungsi berkurang dan keputusan TI punya akuntabilitas yang jelas.

2. Daftar risiko TI (IT risk register) terdokumentasi. Daftar risiko TI dengan penilaian dampak dan probabilitas serta rencana mitigasi, disusun lewat workshop dan ditinjau minimal triwulanan. Quick win: susun draft berisi 10-20 risiko utama; tidak harus sempurna, yang penting proses identifikasi dimulai. Nilainya: kesadaran risiko naik dan ada dasar untuk mitigasi serta pemenuhan compliance.

3. Inventaris dokumen (document inventory) dan analisis kesenjangan. Banyak organisasi punya dokumen tetapi tak tahu di mana atau apakah masih relevan. Inventaris mendaftar semua dokumen TI; gap analysis membandingkannya dengan kebutuhan untuk menemukan yang hilang. Quick win: susun inventaris sederhana dan tandai lima dokumen kritis yang belum ada atau perlu diperbarui.

4. Identifikasi sistem kritis (critical systems). Tidak semua sistem sama kritisnya. Sistem kritis berdampak langsung ke layanan, berisi data sensitif, atau menimbulkan kerugian finansial signifikan saat down. Quick win: susun daftar 5-10 sistem kritis dan tetapkan proteksi minimum masing-masing, agar investasi terarah ke yang paling penting.

5. Dashboard kinerja sederhana (performance dashboard). Anda tidak dapat memperbaiki yang tidak Anda ukur. Metrik umum: uptime, incident response time, project completion rate, dan budget variance. Tetapi hati-hati pada KPI yang mengukur aktivitas, bukan hasil; ‘100% server termonitor’ tak berarti banyak jika layanan masih lambat. Dashboard paling berguna bukan yang paling ramai grafiknya, melainkan yang paling cepat memaksa rapat mengambil keputusan; jika satu metrik tidak mengubah prioritas, pemilik, atau tenggat, ia hanya dekorasi. Quick win: mulai dari spreadsheet dengan 5-10 metrik utama, kembangkan bertahap.

4.3.2 Model Kematangan Ringkas

COBIT memiliki pendekatan pengukuran kinerja yang lebih rinci daripada ringkasan di bawah ini. Untuk kebutuhan awal perusahaan utilitas air, model ringkas lima level berikut dapat dipakai sebagai bahasa rapat. Ini bukan sertifikasi kematangan resmi, melainkan alat orientasi agar Direksi dan tim TI memahami posisi awal dan target realistis.

Level 1 - Awal/Ad-hoc (Initial/Ad-hoc):

Pada level ini, praktik dilakukan secara ad-hoc tanpa struktur formal. Tidak ada dokumentasi, proses sangat bergantung pada individu, dan kesuksesan lebih karena keberuntungan daripada desain. Banyak organisasi kecil berada pada level ini untuk beberapa area tata kelola TI.

Contoh karakteristik

• masalah diselesaikan ketika muncul, tanpa prosedur jelas
• tidak ada dokumentasi proses
• ketergantungan pada satu atau dua individu kunci
• lessons learned tidak ditangkap dan digunakan kembali

Level 2 - Dapat Diulang (Repeatable):

Pada level ini, proses mulai mengikuti pola yang dapat diulang, meskipun belum sepenuhnya konsisten. Dokumentasi mungkin ada tetapi tidak lengkap, dan proses berbeda antar-unit atau situasi.

Contoh karakteristik

• beberapa prosedur tertulis ada, tetapi jarang diikuti secara konsisten
• respons terhadap masalah serupa cenderung konsisten
• pelatihan informal dilakukan
• lessons learned kadang-kadang ditangkap

Level 3 - Terdefinisi (Defined):

Pada level ini, proses telah terdokumentasi dan distandardisasi. SOP ada, diikuti, dan dipantau kepatuhannya. Seluruh organisasi menggunakan proses yang sama untuk situasi yang serupa.

Contoh karakteristik

• prosedur tertulis lengkap dan disetujui
• pelatihan formal untuk prosedur kunci
• kepatuhan terhadap prosedur dipantau
• proses ditinjau dan diperbarui secara berkala

Level 4 - Terkelola (Managed):

Pada level ini, proses tidak hanya ditetapkan, tetapi juga diukur dan dikendalikan secara kuantitatif. Organisasi memiliki metrik untuk kinerja proses dan melakukan perbaikan berdasarkan data.

Contoh karakteristik

• metrik kinerja proses ditetapkan dan dipantau
• root cause analysis dilakukan untuk insiden
• perbaikan proses berdasarkan analisis data
• benchmarking dengan organisasi lain dilakukan

Level 5 - Mengoptimalkan (Optimizing):

Pada level tertinggi, organisasi tidak hanya mengendalikan proses, tetapi terus memperbaikinya secara sistematis. Praktik best in class, inovasi didorong, dan organisasi belajar dari pengalaman sendiri maupun organisasi lain.

Contoh karakteristik

• perbaikan berkelanjutan adalah bagian dari budaya
• inovasi proses didorong dan dihargai
• organisasi adalah reference bagi lainnya
• benchmarking internasional dilakukan secara rutin

4.3.3 Kuesioner Asesmen Awal

Berikut adalah kuesioner sederhana untuk menilai kematangan tata kelola TI. Kuesioner ini dirancang untuk memberikan indikasi cepat level kematangan organisasi.

Dimensi 1: Struktur tata kelola (governance structure)

1. Apakah organisasi memiliki IT Steering Committee atau forum serupa? 0 = Tidak ada. 1 = Ada, tetapi jarang bertemu. 2 = Ada, bertemu secara berkala, dan efektif.

2. Apakah peran dan tanggung jawab untuk tata kelola TI didefinisikan dengan jelas? 0 = Tidak ada definisi formal. 1 = Definisi ada tetapi tidak dipahami. 2 = Definisi jelas dan dipahami.

Dimensi 2: Manajemen risiko (risk management)

3. Apakah organisasi memiliki IT Risk Register? 0 = Tidak ada. 1 = Ada, tetapi tidak diperbarui. 2 = Ada, diperbarui berkala, dan digunakan.

4. Apakah penilaian risiko TI dilakukan secara berkala? 0 = Tidak pernah. 1 = Pernah, tetapi tidak rutin. 2 = Rutin, minimal tahunan.

Dimensi 3: Kebijakan dan prosedur (policies and procedures)

5. Apakah kebijakan TI utama ditetapkan dan didokumentasikan? 0 = Tidak ada kebijakan tertulis. 1 = Beberapa kebijakan ada. 2 = Kebijakan komprehensif ada.

6. Apakah prosedur operasional TI didokumentasikan dan diikuti? 0 = Tidak ada prosedur tertulis. 1 = Prosedur ada, kepatuhan bervariasi. 2 = Prosedur lengkap dan dipatuhi.

Dimensi 4: Pengukuran kinerja (performance measurement)

7. Apakah kinerja TI diukur dan dilaporkan secara berkala? 0 = Tidak ada pengukuran. 1 = Beberapa metrik diukur. 2 = Pengukuran komprehensif dan dilaporkan.

8. Apakah kinerja TI digunakan untuk pengambilan keputusan? 0 = Tidak pernah. 1 = Kadang-kadang. 2 = Secara rutin.

Dimensi 5: Kepatuhan (compliance)

9. Apakah kepatuhan terhadap regulasi dipantau? 0 = Tidak ada pemantauan. 1 = Pemantauan informal. 2 = Pemantauan sistematis.

10. Apakah audit TI dilakukan secara berkala? 0 = Tidak pernah. 1 = Pernah. 2 = Rutin, minimal tahunan.

Interpretasi Skor:

Total skor maksimum kuesioner ini adalah 20. Interpretasi cepatnya: skor 0-5 menunjukkan Level 1 (Initial/Ad-hoc), ketika fondasi tata kelola perlu dibangun; skor 6-10 menunjukkan Level 2 (Repeatable), ketika beberapa praktik sudah ada tetapi perlu konsistensi; skor 11-15 menunjukkan Level 3 (Defined), ketika prosedur sudah terdokumentasi tetapi perlu pengukuran; skor 16-18 menunjukkan Level 4 awal, ketika tata kelola mulai dikelola berbasis metrik; skor 19-20 menunjukkan kandidat Level 4 kuat atau Level 5 awal, tetapi perlu dibuktikan dengan audit, data kinerja, dan bukti perbaikan berkelanjutan.

4.3.4 Analisis Kesenjangan: Dari Kondisi Saat Ini ke Target

Setelah menilai kematangan saat ini, langkah berikutnya adalah melakukan analisis kesenjangan (gap analysis) untuk mengidentifikasi area yang perlu diperbaiki. Analisis kesenjangan membandingkan keadaan saat ini (as-is) dengan kondisi yang diinginkan (to-be).

Tabel 4.3 memberi contoh kerangka gap analysis sederhana. Gunakan tabel ini sebagai bahan rapat awal, bukan sebagai dokumen final yang langsung ditempel ke kebijakan.

Tabel 4.3 Contoh gap analysis tata kelola TI berbasis COBIT

Prioritas dalam Tabel 4.3 ditetapkan berdasarkan risiko jika area tersebut tidak diperbaiki, kompleksitas implementasi, dan ketersediaan sumber daya. Area dengan risiko tinggi dan kompleksitas rendah sebaiknya diutamakan sebagai quick wins.

4.3.5 Roadmap Implementasi 12-18 Bulan

Berdasarkan gap analysis, berikut adalah roadmap implementasi COBIT yang realistis untuk perusahaan utilitas:

Bulan 1-3: Kemenangan Cepat dan Fondasi

• Pembentukan IT Steering Committee dengan terms of reference
• Penyusunan IT Risk Register awal
• Document inventory dan identifikasi lima dokumen kritis
• Identifikasi sistem kritis dan penetapan proteksi minimum
• Pembuatan performance dashboard sederhana

Bulan 4-6: Pengembangan Kebijakan dan Prosedur

• Pengembangan lima kebijakan utama (keamanan informasi, acceptable use, change management, incident management, vendor management)
• Dokumentasi prosedur untuk lima proses paling kritis
• Pelatihan awareness untuk seluruh karyawan
• Implementasi dasar change management

Bulan 7-12: Implementasi dan Pengukuran

• Implementasi penuh change management
• Pelaksanaan audit TI pertama
• Pengembangan performance dashboard yang lebih komprehensif
• Review dan perbaruan risk register
• Pelatihan teknis untuk tim TI

Bulan 13-18: Optimalisasi dan Perbaikan Berkelanjutan

Pada fase ini, organisasi melakukan remediasi atas hasil audit, mengimplementasikan perbaikan berdasarkan ukuran kinerja, meninjau dan memperbarui kebijakan serta prosedur, melakukan benchmarking dengan organisasi serupa, dan menyiapkan siklus peningkatan berikutnya.

4.3.6 Kematangan di Atas Kertas dan Kematangan yang Sebenarnya

Model kematangan di §4.3.2 memudahkan organisasi menilai posisinya, tetapi ia juga mudah disalahgunakan. Menaikkan tingkat kematangan COBIT di atas kertas relatif gampang: susun kebijakan, lengkapi dokumen, isi daftar periksa (checklist), tunjuk artefaknya saat asesmen. Seorang asesor bisa pulang dengan skor Level 3, sementara organisasi tetap beroperasi di Level 1. Artefaknya ada; perilakunya tidak berubah. Kesenjangan inilah yang menentukan apakah sebuah program tata kelola TI sungguh hidup atau sekadar pajangan, dan ia jarang ditulis dengan jujur.

Hambatan sebenarnya bukan resistensi yang terbuka. Resistensi terbuka justru mudah ditangani karena ia terlihat dan bisa diajak bicara. Yang sulit adalah resistensi yang pasif dan politis. Orang mengangguk di rapat, menandatangani kebijakan, lalu melanjutkan persis seperti sebelumnya; “iya, siap” yang sesungguhnya berarti tidak. Penyebabnya bisa dipahami begitu kita melihatnya sebagai soal kekuasaan, bukan soal kepatuhan: tata kelola membuat keputusan menjadi terlihat, terlacak, dan terbagi. Siapa pun yang selama ini diuntungkan oleh keputusan yang informal dan tidak transparan akan kehilangan sesuatu, dan ia tidak akan menentang transparansi secara terbuka; ia akan memujinya sambil diam-diam membiarkannya layu.

Maka pendekatan yang realistis dimulai dari satu pergeseran cara mengukur. Jangan bertanya “apakah ada kebijakan?” Tanyakan “tunjukkan tiga kali terakhir kebijakan ini benar-benar dipakai untuk mengambil keputusan.” Bukti kematangan adalah keputusan, catatan, dan pengecualian yang tercatat, bukan dokumen. Asesmen yang menilai artefak mengundang pajangan; asesmen yang menilai perilaku menutup pintunya. Sebagaimana ditunjukkan Tabel 4.4, tanda kematangan di atas kertas dan tanda kematangan yang sebenarnya bisa dibedakan dengan jelas bila kita tahu harus melihat ke mana.

Tabel 4.4 Membedakan kematangan tata kelola di atas kertas dari kematangan yang sebenarnya

Dari sana, beberapa langkah membuat kematangan tumbuh nyata. Mulai dari proses yang rasa sakitnya dirasakan unit itu sendiri, misalnya insiden yang berulang, sehingga tata kelola ditarik oleh kebutuhan, bukan didorong dari atas. Ikat jalur yang diatur dengan sesuatu yang diinginkan pihak yang resisten, sehingga menempuh jalur resmi menjadi cara tercepat mendapat anggaran atau persetujuan. Mintalah sponsor eksekutif yang sesekali bersedia membelanjakan modal politiknya dengan membuat satu keputusan kasatmata yang lahir dari proses tata kelola, seperti menghentikan proyek di sebuah gerbang tinjauan; orang baru percaya prosesnya nyata setelah melihatnya menggigit sekali. Dan tahan godaan angka: Level 2 yang benar jauh lebih berharga daripada Level 4 yang fiktif, karena kematangan palsu akan runtuh pada insiden nyata pertama dan pada audit yang sungguh-sungguh.

Versi paling akut dari kepalsuan ini muncul menjelang audit, ketika organisasi memoles penampilan dalam semalam; pola kosmetik itu dibahas tersendiri di Bab 8. Tetapi akarnya sama: memenangkan resistensi pasif bukan dengan konfrontasi, melainkan dengan membuat jalur yang benar sedikit lebih mudah dan jalur yang palsu sedikit lebih terlihat, diulang dengan sabar sampai perilaku bergeser. Bagi Direksi, ini soal apakah Anda sedang membeli perlindungan atau membeli ilusi; skor yang dipoles untuk asesor adalah kewajiban yang menunggu jatuh tempo. Bagi tim TI, fokus pada perilaku adalah pembenaran untuk menolak mengejar angka kosong, dan untuk meminta waktu membangun yang nyata.

4.3.7 Menyelaraskan COBIT dengan ISO: Tidak Perlu Dua Sistem Paralel

Banyak operator swasta utilitas air dan PDAM besar dituntut memenuhi beberapa standar sekaligus: ISO 9001 (mutu), ISO 27001 (keamanan informasi), ISO 37001 (anti-penyuapan), dan mungkin ISO 22301 (kelangsungan bisnis). Masing-masing memiliki persyaratan dokumentasi, audit, dan tinjauan manajemen. Jika organisasi menjalankan COBIT, ISO 27001, dan ISO 9001 sebagai tiga sistem terpisah, hasilnya adalah tiga set dokumen, tiga jadwal audit, tiga rapat tinjauan; dan kelelahan kepatuhan.

COBIT dan ISO sebenarnya saling melengkapi, bukan bersaing:

Langkah praktis menyelaraskan COBIT dengan ISO 27001:

1. Mulai dari ISO 27001 Annex A. Pilih kontrol yang relevan untuk organisasi Anda. Dari 93 kontrol, utilitas air menengah biasanya relevan dengan 40-50 kontrol.
2. Petakan setiap kontrol ke proses COBIT. A.9 (Access Control) → DSS05. A.12 (Operations Security) → DSS01, DSS05. A.14 (System Acquisition) → BAI02, BAI03. A.15 (Supplier Relationships) → APO10. A.16 (Incident Management) → DSS02, DSS03.
3. Gunakan COBIT untuk menilai kematangan. ISO 27001 bertanya “apakah kontrolnya ada?” COBIT bertanya “seberapa baik kontrol itu dikelola?” Jawaban COBIT (level 0-5) adalah bukti yang lebih kuat daripada jawaban biner (ada/tidak).
4. Satu jadwal tinjauan manajemen. Gabungkan agenda: 30 menit pertama membahas COBIT (risk register, maturity trends), 30 menit berikutnya membahas ISO (ISMS performance, incident trends). Satu rapat, dua standar.

Untuk operator swasta yang kontraknya mewajibkan ISO: tunjukkan ke mitra pemerintah bahwa COBIT adalah kerangka yang memperkuat ISO; bukan duplikasi. Buktikan dengan pemetaan kontrol di atas.

4.4 Penutup Bab

Satu hal perlu ditegaskan sebelum bab ini ditutup: COBIT bukan jawaban untuk semua masalah TI. Ia adalah bahasa keputusan. Bahasa itu berguna karena memaksa organisasi bertanya lebih presisi: tujuan apa yang dijaga, risiko apa yang diterima, nilai apa yang ditagih, sumber daya apa yang disiapkan, dan siapa yang bertanggung jawab.

Perusahaan utilitas air tidak perlu menunggu sempurna untuk mulai memakai COBIT. Justru organisasi dengan sumber daya terbatas perlu kerangka yang memaksa prioritas. Lima objektif pertama, satu tabel pemetaan proses, satu risk register, satu forum keputusan, dan satu dashboard sederhana sering lebih berharga daripada program transformasi tata kelola yang terlalu ambisius.

Pola ini berlaku lintas industri. BUMD listrik dan gas, koperasi simpan pinjam, puskesmas atau RSUD, sekolah penerima BOS, dan korporasi swasta menengah sama-sama membutuhkan bahasa keputusan yang menghubungkan teknologi dengan risiko, nilai, dan akuntabilitas.

💡 Angka yang mengubah keputusan: 5 dari 40. Jumlah objektif COBIT yang harus Anda pilih untuk 12 bulan pertama. Jangan implementasi semua; pilih 5 yang paling berdampak.

Tentang Sertifikasi COBIT Resmi

Buku ini adalah pelengkap, bukan pengganti pelatihan dan sertifikasi resmi COBIT. Pembaca yang ingin mendalami penerapan COBIT di tingkat enterprise atau mengejar sertifikasi profesional disarankan menempuh jalur resmi melalui ISACA:

• COBIT Foundation Certificate; untuk pemahaman dasar kerangka COBIT 2019
• COBIT Design & Implementation Certificate; untuk praktisi yang merancang dan menerapkan tata kelola
• COBIT Assessor Certificate; untuk profesional yang melakukan asesmen kematangan

Informasi lengkap dan pendaftaran tersedia di www.isaca.org. ISACA juga memiliki chapter Indonesia yang secara berkala mengadakan pelatihan dan ujian. Buku ini menggunakan COBIT 2019 sebagai kerangka utama, dan semua rujukan ke COBIT mengacu pada dokumen resmi ISACA. COBIT adalah merek dagang terdaftar ISACA.

Catatan Akhir: Mengikat Makna

Dari semua proses dan objektif yang sudah dibahas, beberapa simpul ini yang tidak boleh terlepas:

• COBIT 2019 harus dibaca sebagai kerangka keputusan, bukan daftar kontrol yang harus diterapkan sekaligus.
• Nilai utama COBIT bagi perusahaan utilitas air adalah kemampuannya menerjemahkan masalah teknis menjadi diskusi tata kelola yang dapat dipahami Direksi.
• Tidak semua objektif tata kelola dan manajemen COBIT memiliki prioritas sama. Untuk 12 sampai 18 bulan pertama, fokus pada risiko, operasi, keamanan, kontrol proses bisnis, kerangka tata kelola, dan realisasi manfaat.
• Pemetaan proses bisnis ke objektif COBIT membantu organisasi memilih prioritas berdasarkan dampak layanan, bukan berdasarkan tren teknologi.
• Maturity assessment yang sederhana lebih berguna daripada penilaian sempurna yang tidak pernah dipakai untuk mengambil keputusan.

Uji Nyali Eksekutif: Lima Pertanyaan yang Harus Bisa Anda Jawab

Gunakan lima pertanyaan ini sebagai uji cepat setelah membaca bab ini.

1. Jika harus memilih hanya lima objektif COBIT untuk 12 bulan pertama, apakah organisasi sudah tahu mana yang paling kritis?
2. Apakah setiap sistem kritis (SCADA, billing, layanan pelanggan, ERP, GIS) sudah terhubung ke pemilik risiko dan pemilik manfaat yang jelas?
3. Apakah komite pengarah TI (IT steering committee) membahas nilai, risiko, dan prioritas, atau hanya mendengar laporan proyek?
4. Apakah organisasi punya gap analysis sederhana seperti Tabel 4.3, atau masih mengandalkan persepsi umum bahwa “tata kelola sudah ada”?
5. Apakah Direksi pernah meminta bukti bahwa investasi TI benar-benar menghasilkan manfaat yang dijanjikan?

Aksi Instan: Tiga Gebrakan untuk Minggu Ini

1. Pilih lima objektif prioritas. Mulai dari P1 pada Tabel 4.2, lalu tambahkan EDM01 atau EDM02 sesuai konteks organisasi.
2. Isi satu tabel gap analysis. Gunakan Tabel 4.3 untuk satu sistem paling kritis. Jangan mulai dari seluruh organisasi; mulai dari sistem yang paling berdampak ke layanan.
3. Bawa hasilnya ke forum Direksi. Minta keputusan eksplisit: risiko mana yang diterima, risiko mana yang harus dimitigasi, dan siapa pemilik tindak lanjut 30 hari ke depan.

Amunisi Rapat: Daftar Periksa Awal COBIT (versi cetak: tools.itgbook.com)

1. Apakah tujuan rapat adalah memilih prioritas, bukan membahas seluruh COBIT?
2. Apakah setiap objektif prioritas punya pemilik dari sisi Direksi atau manajemen puncak?
3. Apakah risiko dan manfaat ditulis dalam bahasa bisnis, bukan hanya bahasa teknis?
4. Apakah ada tenggat 30 hari untuk satu tindakan pertama?
5. Apakah hasil rapat akan dibahas ulang pada rapat berikutnya?

Daftar periksa (checklist) ini menjaga agar COBIT tidak berubah menjadi seminar istilah. Ia harus menjadi alat keputusan.

🛠️ Besok pagi, coba ini: Print Daftar Periksa Rapat Awal COBIT. Bawa ke rapat TI. Jangan diskusikan 40 objektif. Pilih 5. Tetapkan pemilik. Tenggat 30 hari.

Untuk Disampaikan ke Direksi

Rangkuman untuk manajer TI yang perlu menyampaikan isi bab ini ke pimpinan dalam 3 menit:

1. COBIT bukan proyek implementasi; ia bahasa bersama. Nilainya bukan pada kelengkapan 40 proses, melainkan pada kemampuannya menerjemahkan “server bermasalah” menjadi “risiko layanan yang perlu keputusan Direksi.”
2. Mulai dari 5 objektif, bukan 40. Untuk 12-18 bulan pertama: fokus pada risiko, operasi, keamanan, kontrol proses bisnis, dan kerangka tata kelola. Jangan implementasi semua sekaligus.
3. Kematangan level 3 yang konsisten > level 5 di atas kertas. Targetnya kematangan yang cukup untuk mengelola risiko utama, bukan nilai sempurna yang tidak pernah dipakai mengambil keputusan.

Bawa Tabel pemetaan COBIT-ke-proses-bisnis (Bab 4 §4.3) sebagai handout rapat.

Amunisi Rapat: Satu Pertanyaan Penguji Pimpinan

Kalau organisasi hanya boleh memperbaiki tiga kontrol tata kelola TI dalam 90 hari ke depan, siapa yang memilih tiga kontrol itu, dan berdasarkan data apa?

Kalau jawaban pertanyaan ini masih berupa “nanti dibahas oleh tim TI”, berarti COBIT belum menjadi bahasa tata kelola. Ia masih dianggap urusan teknis.

Menuju Bab 5: Mengapa Risiko TI Lebih Dulu

Setelah COBIT memberi bahasa bersama, langkah berikutnya bukan langsung membangun semua dokumen, semua komite, atau semua dashboard. Langkah berikutnya adalah memilih risiko yang paling perlu dikendalikan. Anda mungkin tergoda memakai Tabel 4.2 sebagai daftar kerja lengkap, tetapi daftar tanpa prioritas risiko akan cepat berubah menjadi beban administratif.

Ada tiga alasan Bab 5 masuk sebelum pembahasan organisasi, dokumentasi, audit, dan proyek.

Pertama, risiko menentukan urutan. Perusahaan utilitas air tidak punya kemewahan untuk memperbaiki semua area sekaligus. Sistem yang berdampak langsung ke layanan, pendapatan, atau keselamatan operasional harus datang lebih dulu.

Kedua, risiko memberi bahasa yang dapat dipahami lintas fungsi. Direksi, TI, Keuangan, Operasi, Audit, dan regulator mungkin berbeda kosakata, tetapi semuanya memahami dampak: layanan berhenti, data bocor, tagihan salah, audit berulang, reputasi turun.

Ketiga, risiko menjaga COBIT tetap praktis. Tanpa manajemen risiko, COBIT mudah jatuh menjadi katalog kontrol. Dengan manajemen risiko, COBIT menjadi alat memilih kontrol mana yang layak didahulukan.

Bab 5 akan menyusun cara mengidentifikasi, menilai, memitigasi, dan memantau risiko TI agar kerangka COBIT yang baru dibahas tidak berhenti sebagai teori.

Lanjutkan ke Bab 5: Manajemen Risiko TI.

Referensi & Eksplorasi Lanjutan

1. Kerangka COBIT 2019: Introduction and Methodology

   • ISACA (2019). Dokumen utama COBIT 2019 yang menjelaskan kerangka, prinsip, dan komponen.
   • 🔗 COBIT 2019 Overview

2. Kerangka COBIT 2019: Governance and Management Objectives

   • ISACA (2019). Dokumen rinci yang menjelaskan 40 objektif tata kelola dan manajemen COBIT 2019.
   • 🔗 COBIT 2019 Objectives

3. Panduan Desain COBIT 2019: Designing an Information Technology Governance System

   • ISACA (2019). Panduan untuk menyusun sistem tata kelola TI yang disesuaikan dengan konteks organisasi.
   • 🔗 COBIT Design Guide

4. Panduan Implementasi COBIT 2019: Implementing and Optimizing an Information Technology Governance System

   • ISACA (2019). Panduan praktis implementasi COBIT dengan studi kasus dan template.
   • 🔗 COBIT Implementation

5. Analisis Tata Kelola TI Lokal Berbasis COBIT 2019

   • Mayang Sari dkk. (2023). Studi akademik tentang analisis tata kelola TI di perusahaan air minum daerah menggunakan COBIT 2019 dan ISO/IEC 27001.
   • 🔗 Jurnal Sistemasi

6. Kasus NotPetya dan Pemulihan Maersk

   • A.P. Møller - Mærsk A/S (2017). Laporan triwulan yang menyebut estimasi dampak negatif serangan siber terhadap hasil usaha di kisaran USD 200-300 juta.
   • 🔗 Interim Report Q2 2017 via GlobeNewswire
   • Wired (2018) dan BleepingComputer (2018). Liputan mendalam tentang dampak operasional, domain controller Ghana, dan skala pemulihan Maersk setelah NotPetya.
   • 🔗 Wired: The Untold Story of NotPetya
   • 🔗 BleepingComputer: Maersk Reinstalled 45,000 PCs and 4,000 Servers

7. Tata Kelola Korporat TI (Corporate Governance of Information Technology) ISO/IEC 38500:2015

   • ISO (2015). Standar internasional untuk tata kelola TI tingkat direksi, dapat digunakan bersandingan dengan COBIT.
   • 🔗 ISO.org

8. IT Governance: How Top Performers Manage IT Decision Rights for Superior Results

   • Weill, P., & Ross, J. (2004). Buku referensi tentang tata kelola TI yang komprehensif.
   • 🔗 Harvard Business Review

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 bersifat 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. COBIT adalah merek dagang terdaftar ISACA. Pembaca didorong untuk merujuk ke sumber resmi ISACA untuk informasi terkini dan lengkap tentang kerangka COBIT. Implementasi COBIT harus disesuaikan dengan konteks spesifik organisasi dan memerlukan pertimbangan matang mengenai ketersediaan sumber daya dan prioritas bisnis.