Bab 3: Kerangka Kerja COBIT untuk Utilitas

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

Tiga Hal yang Wajib Dibawa Pulang

• 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.

Peta Konsep Bab Ini

Diagram 3.1 menunjukkan alur Bab 3: mulai dari prinsip dan komponen COBIT 2019, masuk ke pemetaan objektif yang relevan untuk utilitas air, lalu berakhir pada perangkat awal yang bisa dipakai di rapat Direksi.

Pembuka: Dari Ratusan Halaman ke Satu Peta Keputusan

Di situs resmi ISACA, COBIT 2019 tidak hadir sebagai satu artikel ringkas. Ia hadir sebagai rangkaian publikasi: Introduction and Methodology, Governance and Management Objectives, Design Guide, dan Implementation Guide. Salah satu publikasinya menjelaskan 40 governance and management objectives; publikasi lain menjelaskan cara mendesain sistem tata kelola yang disesuaikan dengan konteks organisasi. Bagi praktisi governance, kelengkapan ini berharga. Bagi Direksi perusahaan utilitas air dengan tim TI kecil, dokumen sebanyak itu bisa terasa seperti tembok.

Bayangkan rapat Direksi yang baru saja menerima presentasi COBIT. Di layar muncul domain EDM, APO, BAI, DSS, MEA; lalu muncul istilah design factors, governance components, capability level, dan management practices. Pertanyaan pertama yang muncul biasanya bukan pertanyaan teknis. Pertanyaannya jauh lebih praktis: “Apa yang benar-benar harus kami putuskan bulan ini?”

Hook ini bukan klaim tentang satu organisasi tertentu. Ia merangkum situasi yang berulang saat standar internasional masuk ke organisasi dengan sumber daya terbatas. Fakta publiknya sederhana: COBIT 2019 memang kerangka yang komprehensif, diterbitkan ISACA untuk membantu organisasi mengelola informasi dan teknologi secara sistematis. Tantangan lokalnya juga sederhana: perusahaan utilitas air Indonesia tidak membutuhkan semua halaman itu sekaligus. Yang dibutuhkan adalah peta keputusan.

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.

3.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.

3.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.

3.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.

3.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 mengeksekusi 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.

3.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.

3.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 eksekusi. 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.

3.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.

3.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.

3.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.

3.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.

3.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

3.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.

APO10: Managed Vendors

Dengan ketergantungan yang tinggi pada vendor teknologi, objektif ini sangat relevan. Secara resmi APO10 berada di domain APO, tetapi sengaja disebut di sini karena sering muncul dalam keputusan pengadaan dan implementasi. Implementasinya mencakup proses seleksi vendor yang terdokumentasi, perjanjian tingkat layanan (service level agreement, SLA) yang jelas, pemantauan kinerja vendor, dan rencana kontinjensi jika vendor gagal memenuhi komitmen.

3.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.

3.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.

3.2.5 Mapping ke Proses Bisnis Utilitas

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

Tabel 3.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 3.1, Direksi dapat mengubah COBIT dari daftar istilah menjadi peta prioritas.

3.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:

Kesenjangan 1: Belum ada komite pengarah TI yang meninjau proyek secara teratur.

Proyek digitalisasi meter diinisiasi oleh tim operasional dan tim TI, tanpa melibatkan Direksi atau unit keuangan dalam keputusan awal. Ketika masalah muncul pada tahap implementasi, tidak ada forum keputusan yang jelas untuk menyelesaikan konflik prioritas.

Pemetaan COBIT. Kesenjangan ini terkait dengan EDM01 (Ensured Governance Framework Setting and Maintenance) dan EDM02 (Ensured Benefits Delivery). Komite pengarah TI diperlukan untuk memastikan proyek tetap sesuai dengan tujuan organisasi dan menghasilkan manfaat yang dijanjikan.

Tindakan perbaikan. Organisasi X membentuk komite pengarah TI dengan Direktur Operasi sebagai ketua, anggota dari Direksi Keuangan, Kepala TI, dan Kepala Operasional. Komite ini bertemu setiap bulan untuk meninjau progres proyek digitalisasi meter.

Kesenjangan 2: Daftar risiko belum memuat risiko proyek digitalisasi.

Daftar risiko TI berisi risiko-risiko umum seperti server downtime, virus, dan kegagalan perangkat. Namun, risiko spesifik proyek digitalisasi meter tidak teridentifikasi: risiko smart meter tidak akurat, risiko integrasi data ke sistem billing, risiko penolakan pengguna, dan risiko keamanan data konsumsi pelanggan.

Pemetaan COBIT. Kesenjangan ini terkait dengan EDM03 (Ensured Risk Optimization) dan BAI03 (Managed Solutions Identification and Build). Identifikasi risiko harus dilakukan sejak awal proyek, bukan setelah implementasi berjalan.

Tindakan perbaikan. Tim proyek melakukan asesmen risiko (risk assessment) khusus untuk digitalisasi meter. Risiko-risiko yang diidentifikasi dimasukkan ke daftar risiko TI dengan rencana mitigasi yang jelas.

Kesenjangan 3: Belum ada business case formal dengan manfaat terukur.

Proyek digitalisasi meter didasarkan pada asumsi manfaat: penghematan biaya pencatatan meter manual, peningkatan akurasi billing, dan peningkatan kepuasan pelanggan. Namun, manfaat ini tidak diukur secara baseline sebelum proyek dimulai, sehingga pengukuran keberhasilan proyek menjadi sulit.

Pemetaan COBIT. Kesenjangan ini terkait dengan EDM02 (Ensured Benefits Delivery). Business case dengan baseline dan target metrics harus disusun sebelum investasi disetujui.

Tindakan perbaikan. Tim proyek menyusun business case yang memuat: baseline biaya pencatatan meter manual, target penghematan, metrik pengukuran akurasi billing, dan survei baseline kepuasan pelanggan.

Kesenjangan 4: Manajemen perubahan tidak direncanakan untuk pengguna internal dan eksternal.

Proyek ini mengubah cara kerja petugas pencatat meter dan cara pelanggan memantau penggunaan air. Namun, tidak ada rencana manajemen perubahan (change management) untuk pelatihan petugas, sosialisasi kepada pelanggan, dan penanganan komplain selama masa transisi.

Pemetaan COBIT. Kesenjangan ini terkait dengan BAI06 (Managed IT Changes) dan DSS01 (Managed Operations). Perubahan proses bisnis akibat implementasi TI harus dikelola secara terstruktur.

Tindakan perbaikan. Tim proyek menyusun rencana manajemen perubahan yang memuat: pelatihan petugas pencatat meter untuk peran baru, materi komunikasi kepada pelanggan, dan prosedur penanganan komplain selama masa transisi.

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.

3.2.7 Matriks Prioritas Objektif COBIT untuk Utilitas

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

Tabel 3.2 Prioritas awal objektif COBIT untuk perusahaan utilitas air

Prioritas pada Tabel 3.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.

3.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.

3.3.1 Kemenangan Cepat: 5 Kontrol COBIT Pertama

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

1. Pembentukan komite pengarah TI (IT steering committee)

Steering Committee adalah forum pengambilan keputusan tingkat menengah untuk strategi dan prioritas TI. Komite ini sebaiknya diketuai oleh Direktur Utama atau Direktur non-TI, dengan anggota dari semua direktorat. Komite bertemu setiap bulan untuk membahas prioritas investasi TI, kinerja TI, isu risiko TI, dan keputusan strategis lain yang memerlukan koordinasi lintas fungsi.

Quick win di sini adalah dengan membentuk komite terlebih dahulu dan menyusun terms of reference sederhana. Detail dapat dikembangkan seiring berjalannya waktu. Komite ini akan segera memberikan nilai dengan: (a) mengurangi konflik prioritas antar-fungsi, (b) meningkatkan akuntabilitas pengambilan keputusan TI, dan (c) menyediakan forum komunikasi antara bisnis dan TI.

2. Daftar risiko TI (IT risk register) terdokumentasi

Risk Register adalah dokumen yang memuat daftar risiko TI, penilaian dampak dan probabilitas, serta rencana mitigasi. Dokumen ini sebaiknya disusun melalui workshop dengan pemangku kepentingan utama dan ditinjau minimal setiap triwulan.

Quick win di sini adalah dengan menyusun draft risk register yang berisi 10-20 risiko utama. Dokumen tidak harus sempurna pada awalnya; yang penting adalah memulai proses identifikasi dan dokumentasi. Risk Register akan memberikan nilai dengan: (a) meningkatkan kesadaran risiko di kalangan manajemen, (b) menyediakan dasar untuk perencanaan mitigasi, dan (c) memenuhi persyaratan governance dan compliance.

3. Inventaris dokumen (document inventory) dan analisis kesenjangan (gap analysis)

Banyak organisasi memiliki dokumen tetapi tidak tahu di mana mereka berada atau apakah masih relevan. Document inventory adalah daftar semua dokumen TI: kebijakan, prosedur, kontrak vendor, dokumentasi sistem, dan lain-lain. Gap analysis membandingkan dokumen yang ada dengan kebutuhan untuk mengidentifikasi apa yang hilang.

Quick win di sini adalah dengan menyusun inventaris sederhana dan mengidentifikasi lima dokumen paling kritis yang belum ada atau perlu diperbarui. Ini akan memberikan nilai dengan: (a) meningkatkan kemampuan untuk menemukan informasi saat dibutuhkan, (b) mengurangi duplikasi usaha, dan (c) menyediakan dasar untuk program dokumentasi yang lebih sistematis.

4. Identifikasi sistem kritis (critical systems)

Tidak semua sistem memiliki tingkat kritikalitas yang sama. Mengidentifikasi sistem kritis membantu organisasi memprioritaskan sumber daya untuk perlindungan dan pemeliharaan. Sistem kritis biasanya adalah sistem yang berdampak langsung ke operasi layanan, berisi data sensitif, atau menimbulkan dampak finansial signifikan jika down.

Quick win di sini adalah dengan menyusun daftar 5-10 sistem kritis dan menetapkan tingkat proteksi minimum untuk masing-masing. Ini akan memberikan nilai dengan: (a) mengarahkan investasi ke area yang paling penting, (b) mengurangi risiko downtime pada sistem kritis, dan (c) menyederhanakan pengambilan keputusan prioritas.

5. Dashboard kinerja sederhana (performance dashboard)

Anda tidak dapat meningkatkan apa yang tidak Anda ukur. Dashboard kinerja TI menyediakan visualisasi metrik kunci yang dapat digunakan manajemen untuk pengambilan keputusan. Metrik yang umum termasuk: uptime, incident response time, project completion rate, dan budget variance. KPI yang hanya mengukur aktivitas, bukan hasil, adalah kelemahan yang sering muncul dalam manajemen TI. Metrik seperti ‘100% server termonitor’ perlu dibaca bersama pengalaman pengguna jasa; jika layanan masih lambat, indikator teknis belum cukup menjawab kebutuhan bisnis. Berdasarkan pengamatan lintas industri, dashboard yang paling berguna bukan yang paling ramai grafiknya, tetapi yang paling cepat memaksa rapat mengambil keputusan. Jika satu metrik tidak mengubah prioritas, pemilik, atau tenggat, metrik itu kemungkinan hanya dekorasi. Quick win di sini adalah dengan menyusun dashboard sederhana dengan 5-10 metrik utama. Dashboard dapat dibangun secara bertahap, dimulai dari spreadsheet sederhana hingga aplikasi visualisasi data yang lebih canggih. Nilai yang diberikan: (a) transparansi kinerja TI, (b) identifikasi masalah lebih cepat, dan (c) dasar untuk perbaikan berkelanjutan.

3.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

3.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.

3.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 3.3 memberi contoh kerangka gap analysis sederhana. Gunakan tabel ini sebagai bahan rapat awal, bukan sebagai dokumen final yang langsung ditempel ke kebijakan.

Tabel 3.3 Contoh gap analysis tata kelola TI berbasis COBIT

Prioritas dalam Tabel 3.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.

3.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.

3.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.

Ringkasan Bab

• 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.

Lima Pertanyaan Refleksi untuk Direksi

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 3.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?

Tiga Langkah yang Bisa Dimulai Minggu Ini

1. Pilih lima objektif prioritas. Mulai dari P1 pada Tabel 3.2, lalu tambahkan EDM01 atau EDM02 sesuai konteks organisasi.
2. Isi satu tabel gap analysis. Gunakan Tabel 3.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.

Daftar Periksa Rapat Awal COBIT

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.

Satu Pertanyaan untuk Dibawa ke Rapat Direksi Berikutnya

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 4: 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 3.2 sebagai daftar kerja lengkap, tetapi daftar tanpa prioritas risiko akan cepat berubah menjadi beban administratif.

Ada tiga alasan Bab 4 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 4 akan menyusun cara mengidentifikasi, menilai, memitigasi, dan memantau risiko TI agar kerangka COBIT yang baru dibahas tidak berhenti sebagai teori.

Lanjutkan ke Bab 4: Manajemen Risiko TI.

Referensi & Bacaan 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. 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

7. 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.