Bab 6: Orkestrasi Peran: Mengakhiri Tradisi Lempar Tanggung Jawab

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

“TI itu urusan operator, bukan manajemen.” Dalam skenario komposit bab ini, kalimat seperti itu menjadi awal dari risiko yang terlambat naik ke meja pimpinan. Beberapa bulan kemudian, sistem core mati; tidak ada yang tahu siapa yang bertanggung jawab.

Intisari Eksekutif: Tiga Bekal untuk Bertahan

Sebelum menggambar ulang bagan dan matriks peran, tiga prinsip ini menentukan apakah struktur Anda menutup celah tanggung jawab atau justru melebarkannya:

• Struktur mengikuti strategi; bukan sebaliknya. Sebelum merancang ulang bagan organisasi TI, pastikan ada kejelasan: strategi organisasi apa yang harus didukung oleh TI dalam 2-3 tahun ke depan?
• RACI bukan dokumen administratif; ia kontrak kepemimpinan. Ketika insiden terjadi dan tidak ada yang tahu siapa yang bertanggung jawab, akar masalahnya kerap ketiadaan RACI yang disepakati.
• Pisahkan pengawasan dari pelaksanaan. Kepala TI atau CIO boleh menjadi narasumber utama, tetapi keputusan prioritas, risiko, dan investasi tidak boleh hanya diputus oleh pihak yang juga menjalankan pekerjaan.

Navigasi Bab: Apa yang Akan Anda Hadapi?

Diagram 6.1 menunjukkan alur Bab 6: mulai dari risiko TI yang tidak punya kursi di forum strategis, masuk ke model organisasi, peran kunci, matriks RACI, lalu berakhir pada transisi dari struktur saat ini ke struktur target.

Insiden: Ketika TI Tidak Punya Kursi

Cerita pembuka ini adalah komposit dari pola yang sering muncul di grup perusahaan utilitas: Kepala TI di salah satu anak perusahaan meminta pembaruan infrastruktur yang sudah menua, tetapi forum pimpinan di holding melihatnya sebagai urusan operasional lokal. Kalimat yang muncul kurang lebih begini: “TI itu urusan operator wilayah, bukan urusan strategis holding.”

Beberapa bulan kemudian, sistem core di wilayah tersebut mengalami gangguan besar dan memicu efek domino ke pelaporan keuangan konsolidasi grup. Operasi berhenti, loket layanan tersendat, dan tim lapangan kebingungan. Dalam rapat darurat tingkat direksi grup, pertanyaannya berubah menjadi lebih keras: siapa yang bertanggung jawab atas keputusan menunda pembaruan sistem, mengapa tidak ada eskalasi sebelum mencapai titik kritis, dan seharusnya siapa yang berwenang memutuskan risiko seperti ini?

Masalahnya bukan hanya server tua. Masalahnya adalah struktur keputusan. Ketika TI tidak memiliki seat at the table dalam ruang strategis, risiko teknologi berubah menjadi kejutan manajemen. Investasi penting ditunda karena tidak ada pemilik keputusan yang jelas. Risiko yang diketahui tim teknis tidak naik ke meja Direksi. Pada akhirnya, organisasi baru sadar bahwa struktur organisasi adalah bagian dari sistem kendali risiko.

Bab ini memberi alat untuk merancang struktur organisasi TI yang mendukung tata kelola efektif: model organisasi yang mungkin dipilih, peran kunci yang harus jelas, forum keputusan yang diperlukan, dan matriks RACI agar tanggung jawab tidak kabur saat keputusan sulit harus diambil. Jika Bab 5 membahas risiko, bab ini membahas siapa yang memegang risiko itu di dalam struktur organisasi.

6.1 Dilema TI Tanpa Kursi di Meja Keputusan

Sebelum membahas model struktur organisasi, penting untuk memahami mengapa isu ini begitu krusial. TI tanpa kursi di meja keputusan (seat at the table) menghadapi beberapa tantangan fundamental.

6.1.1 Konsekuensi Tanpa Representasi Strategis

Ketika TI tidak terwakili dalam forum pengambilan keputusan strategis, beberapa konsekuensi negatif dapat terjadi:

1. Ketidakselarasan strategis (strategic misalignment). Keputusan strategis bisnis dibuat tanpa pemahaman yang memadai tentang implikasi TI. Contoh: keputusan untuk memperluas layanan ke area baru dibuat tanpa konsultasi dengan TI, kemudian ternyata infrastruktur TI yang ada tidak memadai untuk mendukung ekspansi tersebut. Hasilnya: implementasi terlambat, biaya membengkak, atau kualitas layanan menurun.
2. Prioritas investasi yang salah (investment priorities). Tanpa pemahaman yang baik tentang kebutuhan TI, investasi mungkin diarahkan ke area yang kurang kritis sementara kebutuhan mendesak diabaikan. Contoh: investasi besar untuk renovasi kantor sementara sistem core yang sudah usang tidak diganti.
3. Ekspektasi tidak realistis (unrealistic expectations). Manajemen bisnis mungkin memiliki ekspektasi tidak realistis tentang apa yang dapat dicapai TI, dengan jadwal yang tidak masuk akal, atau dengan anggaran yang tidak memadai. Tanpa komunikasi yang terbuka dan jujur tentang kapasitas dan keterbatasan TI, ekspektasi ini akan menyebabkan kekecewaan dan konflik.
4. Kejutan saat kritis (surprise). Ketika insiden besar terjadi, manajemen puncak mungkin terkejut menemukan bahwa infrastruktur TI lebih rentan daripada yang mereka kira. Kejutan ini bukan hanya masalah teknis, tetapi juga kegagalan tata kelola: tidak ada mekanisme pelaporan yang memadai, tidak ada eskalasi (escalation) ketika risiko diidentifikasi, dan tidak ada kepemilikan (ownership) yang jelas.

6.1.2 Tanda-Tanda TI Tidak Memiliki Kursi di Meja Keputusan

Organisasi dapat mengidentifikasi apakah TI memiliki posisi strategis dengan melihat indikator berikut.

Indikator Positif (TI memiliki seat at the table): Kepala TI atau CIO dilibatkan dalam komite eksekutif (executive committee) atau forum setara. Keputusan investasi besar melibatkan masukan TI sejak awal. Risiko dan kinerja TI dibahas rutin di rapat Direksi, bukan hanya ketika insiden terjadi. Anggaran TI diprioritaskan berdasarkan kebutuhan strategis, bukan hanya sisa ruang setelah anggaran fungsi lain selesai.

Indikator Negatif (TI tidak memiliki seat at the table): Kepala TI atau CIO melapor terlalu jauh dari Direksi. Keputusan bisnis dibuat tanpa konsultasi TI. TI baru dilibatkan ketika masalah sudah terjadi. Risiko dan kinerja TI jarang masuk agenda pimpinan. Anggaran TI menjadi sasaran awal saat efisiensi, walaupun sistem yang ditopangnya kritis untuk layanan.

6.1.3 Menciptakan Kursi di Meja Keputusan

Menciptakan posisi strategis bagi TI memerlukan lebih dari sekadar menempatkan Kepala TI atau CIO di ruang rapat. Ini memerlukan:

1. Kompetensi kepemimpinan TI. Kepala TI atau CIO bukan hanya teknokrat, tetapi pemimpin bisnis yang memahami teknologi. Ia harus mampu: (a) menerjemahkan kebutuhan bisnis menjadi solusi teknologi, (b) mengomunikasikan isu TI dalam bahasa bisnis, dan (c) membangun kredibilitas dengan rekam jejak hasil.
2. Mekanisme pelaporan yang sesuai. Kepala TI atau CIO perlu memiliki jalur pelaporan dan eskalasi yang cukup dekat dengan Direktur Utama atau forum direksi. Ini memastikan bahwa isu TI dapat diangkat langsung ke level tertinggi tanpa penyaringan (filtering) yang membuat risiko terlambat terlihat.
3. Forum pengambilan keputusan formal. Komite Pengarah TI (IT Steering Committee) atau forum serupa menyediakan mekanisme terstruktur untuk diskusi dan keputusan strategis TI. Forum ini harus memiliki mandat yang jelas, keanggotaan yang tepat, dan agenda yang terdefinisi.
4. Transparansi kinerja. Laporan kinerja TI yang jelas, terukur, dan relevan membantu manajemen puncak memahami kontribusi TI. Tanpa data kinerja yang baik, persepsi tentang TI akan didasarkan pada asumsi, bukan fakta.

6.2 Model Struktur Organisasi TI

Tidak ada satu struktur organisasi TI yang benar untuk semua organisasi. Model yang tepat bergantung pada: ukuran organisasi, kompleksitas operasi, tingkat sentralisasi, budaya organisasi, dan strategi bisnis. Bagian ini membahas model-model umum dan pertimbangan pemilihannya.

6.2.1 Model Terpusat (Centralized)

Dalam model terpusat (centralized), seluruh fungsi TI dikumpulkan di bawah satu departemen yang dipimpin oleh CIO atau Kepala TI. Semua staf TI, anggaran, standar, dan keputusan utama TI berada di satu titik koordinasi.

Keuntungan: Model ini memudahkan konsistensi standar, prosedur, dan teknologi di seluruh organisasi. Pengadaan lebih mudah dikonsolidasikan, kapasitas staf TI lebih mudah dibagi, jalur pengembangan karier lebih jelas, dan kontrol keamanan lebih kuat karena standar ditetapkan dari satu tempat.

Kerugian: Risikonya adalah respons terhadap kebutuhan unit operasional dapat melambat. Model ini juga mudah jatuh ke pendekatan “satu pola untuk semua”, padahal kebutuhan kantor pusat, instalasi produksi, laboratorium, dan unit pelayanan pelanggan bisa berbeda.

Cocok Untuk: Organisasi dengan operasi yang relatif homogen. Organisasi dengan keterbatasan sumber daya yang memerlukan efisiensi. Organisasi dengan kebutuhan standar dan kepatuhan yang tinggi.

Contoh Implementasi: Sebuah perusahaan utilitas air dengan satu kantor pusat dan tiga unit operasional di satu wilayah menggunakan model centralized. Semua sistem (billing, SCADA, dan financial system) dikelola dari pusat. Unit operasional memiliki pengguna sistem tetapi tidak tim TI sendiri.

6.2.2 Model Terdesentralisasi (Decentralized)

Dalam model terdesentralisasi (decentralized), fungsi TI tersebar di berbagai unit operasional. Setiap unit memiliki tim TI sendiri, anggaran sendiri, dan otonomi lebih besar dalam pengambilan keputusan TI.

Keuntungan: Keputusan dapat dibuat lebih dekat dengan pengguna bisnis. Tim TI lokal memahami konteks operasi lapangan, hubungan dengan unit lebih erat, dan solusi dapat disesuaikan dengan kebutuhan spesifik wilayah atau fungsi.

Kerugian: Risikonya adalah duplikasi sumber daya, inkonsistensi standar, dan kesulitan integrasi data antar-unit. Keamanan dan kepatuhan juga lebih sulit dijaga jika setiap unit memilih teknologi, vendor, dan prosedur sendiri-sendiri.

Cocok Untuk: Organisasi dengan operasi yang sangat heterogen. Organisasi dengan unit yang tersebar di wilayah geografis yang jauh. Organisasi yang sangat menekankan otonomi unit.

Contoh Implementasi: Sebuah holding utilitas air dengan lima unit operasional di lima provinsi berbeda menggunakan model decentralized. Setiap unit memiliki Kepala TI sendiri, tim TI sendiri, dan bahkan memilih sistem yang berbeda. Pusat hanya menyediakan panduan minimal.

6.2.3 Model Federatif atau Shared Services

Model federatif atau shared services mencoba mengambil keuntungan terbaik dari model terpusat dan terdesentralisasi. Fungsi strategis dan layanan bersama (common services) dikelola terpusat, sementara fungsi operasional dan dukungan bisnis (business support) tertentu tetap dekat dengan unit.

Keuntungan: Model ini memberi keseimbangan antara efisiensi dan responsivitas. Area yang mendapat manfaat dari skala, seperti jaringan, pusat data, keamanan, dan helpdesk, dapat dikonsolidasikan. Sementara itu, kebutuhan lokal tetap memiliki kanal dukungan yang dekat dengan operasi.

Kerugian: Tantangannya adalah koordinasi. Jika batas kewenangan pusat dan unit tidak jelas, konflik peran mudah muncul. Model ini memerlukan mekanisme tata kelola yang lebih matang, termasuk aturan pembagian biaya (cost allocation) yang disepakati.

Cocok Untuk: Organisasi holding dengan beberapa unit operasional. Organisasi yang ingin mengonsolidasikan fungsi bersama. Organisasi dengan tingkat kematangan tata kelola yang memadai.

Contoh Implementasi: Sebuah holding utilitas air dengan sepuluh unit operasional membentuk entitas shared services yang mengelola infrastruktur jaringan, pusat data, sistem billing terpusat, dan helpdesk. Setiap unit operasional memiliki tim TI kecil untuk mendukung sistem Teknologi Operasional (operational technology, OT) seperti SCADA dan kebutuhan lokal spesifik.

6.2.4 Model Hibrida (Hybrid)

Banyak organisasi memakai variasi hibrida (hybrid) dari tiga model di atas. Tidak ada model yang hampir selalu benar atau hampir selalu salah. Pertanyaannya adalah apakah struktur itu sesuai dengan strategi, risiko, kemampuan SDM, dan kebutuhan koordinasi organisasi.

Contoh Konfigurasi Hibrida:

• Infrastruktur dan network dikelola secara terpusat
• Aplikasi bisnis (billing, financial) dikelola secara terpusat
• Teknologi Operasional (operational technology, OT) seperti SCADA dikelola secara terdesentralisasi di setiap unit
• Business partner TI ditempatkan di unit operasional untuk menjembatani komunikasi

6.2.5 Pertimbangan Pemilihan Model

Memilih model struktur organisasi TI memerlukan pertimbangan beberapa faktor.

Faktor Strategis: Seberapa homogen atau heterogen operasi bisnis? Seberapa besar kebutuhan integrasi lintas unit? Apakah strategi bisnis mendorong sentralisasi atau desentralisasi?

Faktor Operasional: Seberapa tersebar lokasi operasi secara geografis? Seberapa besar otonomi yang diperlukan unit operasional? Apakah ada perbedaan signifikan dalam kebutuhan TI antar-unit?

Faktor Keuangan: Seberapa besar efisiensi yang dapat dicapai melalui konsolidasi? Apakah ada skala ekonomi dalam pengadaan teknologi? Bagaimana alokasi biaya antara pusat dan unit?

Faktor Sumber Daya: Apakah ketersediaan talenta TI memadai di semua lokasi? Bagaimana struktur memengaruhi retensi dan pengembangan staf TI? Apakah organisasi mampu menarik talenta ke lokasi terpencil?

Dalam banyak kegagalan proyek TI, masalahnya bukan teknologi yang buruk. Masalahnya adalah tidak ada forum yang cukup jelas untuk menghentikan proyek ketika tanda kegagalannya sudah terlihat. Itu kegagalan tata kelola, bukan semata kegagalan teknis.

Faktor Tata Kelola: Seberapa kuat kemampuan tata kelola organisasi? Apakah ada mekanisme efektif untuk koordinasi lintas unit? Bagaimana konflik antar-unit dikelola?

6.3 Peran Kunci dalam Tata Kelola TI

Tata kelola TI yang efektif memerlukan peran-peran yang jelas dengan tanggung jawab dan otoritas yang terdefinisi. Bagian ini membahas peran-peran kunci tersebut.

6.3.1 Direksi dan Dewan Pengawas

Direksi memiliki peran pengawasan (oversight) tertinggi terhadap tata kelola TI, sedangkan Dewan Pengawas atau organ pengawas setara perlu memastikan pengawasan itu berjalan. Argumen “pengawas tidak perlu paham TI karena TI urusan teknis” terlalu sempit. Pengawas tidak perlu bisa mengonfigurasi server, tetapi harus bisa bertanya: “Apa risiko TI terbesar kita?” dan “Bagaimana kita tahu investasi TI memberi hasil?”

Meskipun dewan tidak perlu menjadi ahli teknologi, mereka harus memahami:

1. Peran oversight TI. Direksi dan organ pengawas harus menetapkan arah strategis TI yang selaras dengan strategi organisasi, menyetujui investasi TI besar, memantau kinerja TI, dan memastikan risiko TI dikelola secara memadai.
2. Pertanyaan yang harus ditanyakan dewan. ISO/IEC 38500 menyarankan pertanyaan berikut untuk direksi: Apakah strategi TI selaras dengan strategi bisnis? Apakah investasi TI memberi nilai yang dijanjikan? Apakah risiko TI dapat diterima dan dikelola secara memadai? Apakah kinerja TI memenuhi kebutuhan layanan? Apakah kepatuhan regulasi terpenuhi?
3. Mekanisme pelaporan. Dewan harus menerima laporan rutin tentang TI yang mencakup: kinerja operasional, proyek strategis, risiko dan insiden, dan kepatuhan regulasi. Laporan ini harus disajikan dalam bahasa bisnis, bukan bahasa teknis.

6.3.2 Direktur Utama (Chief Executive Officer, CEO)

Direktur Utama atau CEO memiliki kepemilikan utama atas implementasi tata kelola TI. Tanggung jawabnya meliputi:

1. Memimpin budaya tata kelola. Direktur Utama menetapkan nada dari puncak (tone at the top) untuk bagaimana organisasi mengelola TI. Jika pimpinan tertinggi tidak menempatkan prioritas pada tata kelola TI, mekanisme tata kelola akan sulit efektif.
2. Akuntabilitas untuk keputusan TI. Direktur Utama bertanggung jawab atas keputusan strategis TI, termasuk investasi besar, struktur organisasi, dan penunjukan Kepala TI atau CIO.
3. Integrasi TI ke strategi bisnis. Direktur Utama perlu memastikan bahwa TI tidak menjadi silo terpisah, tetapi terintegrasi ke perencanaan strategis dan pengambilan keputusan bisnis.

6.3.3 Kepala TI atau Chief Information Officer (CIO)

Kepala TI atau CIO adalah penggerak utama tata kelola TI di organisasi. Peran ini dapat diringkas dalam tiga tanggung jawab utama.

1. Pemimpin strategis, bukan hanya teknis. Kepala TI atau CIO harus: (a) menerjemahkan strategi bisnis menjadi roadmap TI, (b) mengomunikasikan nilai TI ke manajemen puncak, (c) membangun kemitraan dengan fungsi bisnis lain, dan (d) mengelola portofolio (portfolio) proyek TI.
2. Penjaga aset TI (steward). Kepala TI atau CIO bertanggung jawab atas: (a) perencanaan kapasitas infrastruktur, (b) manajemen siklus hidup (lifecycle) aset, (c) keamanan informasi, dan (d) kepatuhan regulasi.
3. Pemimpin SDM TI. Kepala TI atau CIO harus: (a) membangun tim TI yang kompeten, (b) mengembangkan talenta melalui pelatihan dan pengembangan, (c) menciptakan budaya yang mendukung inovasi dan akuntabilitas, dan (d) mempertahankan talenta yang dibutuhkan organisasi.

Kompetensi Kunci CIO: Kepala TI atau CIO membutuhkan pemahaman bisnis yang kuat, komunikasi yang efektif, pemikiran strategis (strategic thinking), pemahaman keuangan (financial acumen), kemampuan manajemen perubahan (change management), dan pengetahuan teknologi yang cukup untuk mengambil keputusan tanpa tenggelam dalam detail teknis.

6.3.4 Komite Pengarah TI (IT Steering Committee)

Komite Pengarah TI (IT Steering Committee) adalah forum pengambilan keputusan tingkat menengah untuk TI. Komite ini menjembatani antara manajemen puncak dan operasional TI.

Tujuan Komite Pengarah TI: Forum ini menetapkan prioritas investasi TI, memantau kinerja TI, mengambil keputusan untuk isu strategis, dan mengoordinasikan inisiatif lintas fungsi.

Komposisi yang Efektif: Ketua: Direktur Utama atau Direktur non-TI. Anggota: Semua direktur (atau wakilnya), CIO, dan undangan khusus sesuai kebutuhan. Sekretaris: Perwakilan TI yang mendokumentasikan keputusan.

Frekuensi Pertemuan:

• Minimal bulanan untuk agenda rutin
• Ad-hoc untuk keputusan strategis yang mendesak

Produk Komite Pengarah TI: Produk forum ini harus nyata: notulen keputusan, prioritas proyek, persetujuan anggaran TI signifikan, daftar isu yang dieskalasi, dan tinjauan kinerja TI bulanan.

Realitas Lapangan: Menghindari Sindrom “Komite Seremonial” Banyak perusahaan utilitas air, baik BUMD maupun operator swasta mitra pemerintah, membentuk Komite Pengarah TI melalui keputusan Direksi, surat keputusan, atau dokumen mandat internal. Dalam praktiknya, forum semacam ini tidak selalu berjalan. Rapatnya dapat berubah menjadi forum laporan rutin tanpa keputusan. Direktur Teknik sibuk mengurus target operasi dan distribusi, Direktur Umum atau Keuangan sibuk mengurus SDM dan kas, lalu isu TI kembali dipikul sendiri oleh Kepala Bagian TI.

Untuk mencegah hal ini, menerbitkan SK Komite saja tidak cukup. Kepedulian direktur non-TI perlu diikat ke indikator kinerja utama (key performance indicator, KPI) yang memang mereka kejar. Sebagai contoh:

• Keberhasilan peluncuran sistem peta jaringan (GIS) untuk menekan kebocoran air dimasukkan ke dalam KPI Direktur Teknik, bukan murni KPI Kepala TI.
• Keberhasilan implementasi ERP dan percepatan rekonsiliasi laporan keuangan dimasukkan ke dalam KPI Direktur Umum atau Keuangan.

Dengan mengaitkan hasil akhir (outcome) sistem TI ke KPI operasional para direktur non-TI, rapat Komite Pengarah TI tidak lagi menjadi “rapat TI” semata. Ia menjadi forum keputusan lintas fungsi karena setiap direktur memiliki kepentingan langsung terhadap hasil investasi TI.

6.3.5 Pemilik Proses Bisnis (Business Process Owner)

Pemilik proses bisnis (business process owners) adalah pemilik proses bisnis yang didukung oleh TI. Mereka bukan staf TI, tetapi pemangku kepentingan utama untuk solusi TI.

Peran pemilik proses bisnis: Mereka mendefinisikan kebutuhan bisnis, memvalidasi bahwa solusi memenuhi kebutuhan, menerima kepemilikan proses setelah implementasi, dan menjadi penggerak adopsi solusi di unit masing-masing.

Contoh:

• Pemilik proses billing untuk sistem billing
• Pemilik proses pengadaan (procurement) untuk sistem procurement
• Pemilik proses layanan pelanggan (customer service) untuk sistem CRM

Kemitraan dengan TI: Solusi TI yang berhasil memerlukan kemitraan kuat antara pemilik proses bisnis dan TI. Tanpa keterlibatan pemilik proses, solusi mungkin tidak memenuhi kebutuhan atau tidak diadopsi secara efektif.

Risiko shadow IT (pengadaan TI tanpa koordinasi) Risiko shadow IT muncul ketika pemilik proses bisnis, misalnya Bagian Keuangan atau Teknik, membeli perangkat lunak seperti HRIS atau aplikasi GIS menggunakan anggaran departemen sendiri tanpa melibatkan tim TI sejak awal.

Praktik ini disebut shadow IT. Ketika vendor selesai instalasi dan aplikasinya tidak stabil, atau datanya tidak bisa diintegrasikan dengan sistem billing utama, masalahnya sering naik ke meja TI pada saat pilihan teknis sudah telanjur terkunci. Akibatnya, tim TI diminta memulihkan risiko yang sejak awal tidak mereka ikut desain.

Kontrol administratif: Direksi perlu menetapkan aturan bahwa setiap pengadaan yang mengandung unsur perangkat lunak, server, integrasi data, atau cloud, meskipun menggunakan anggaran departemen non-TI, harus melalui persetujuan teknis tertulis (technical clearance) dari Kepala TI sebelum dokumen lelang atau SPK diterbitkan. Tujuannya bukan memperlambat pengadaan, melainkan memastikan risiko integrasi, keamanan, data, dan dukungan operasional dibaca sejak awal.

6.3.6 Audit TI (IT Audit)

Fungsi audit TI menyediakan assurance independen tentang kecukupan dan efektivitas kontrol TI.

Peran Audit TI: Audit TI mengevaluasi kecukupan kontrol, mengidentifikasi gap kepatuhan, merekomendasikan perbaikan, dan memantau tindak lanjut atas temuan.

Independensi: Untuk efektif, audit harus independen dari fungsi yang diaudit. Ini berarti: Audit tidak melapor ke CIO. Auditor tidak terlibat dalam desain atau implementasi sistem yang diaudit. Audit memiliki akses langsung ke dewan atau audit committee.

Kompetensi Auditor TI: Auditor TI membutuhkan pemahaman teknologi yang memadai, pengetahuan tentang standar dan kerangka kerja (framework) seperti COBIT dan ISO, komunikasi yang efektif, serta skeptisisme profesional (professional skepticism).

6.3.7 Peran Lain yang Relevan

Selain peran-peran di atas, beberapa peran lain juga penting:

Pejabat atau Petugas Pelindungan Data Pribadi (Data Protection Officer, DPO): Dalam kerangka UU Pelindungan Data Pribadi, peran ini relevan bagi organisasi yang wajib menunjuk fungsi pelindungan data pribadi. Tanggung jawabnya meliputi kepatuhan pemrosesan data pribadi, koordinasi respons insiden data, dan komunikasi dengan otoritas terkait jika diperlukan.

Pejabat Keamanan Informasi (Chief Information Security Officer, CISO):

• Bertanggung jawab atas strategi dan implementasi keamanan siber
• Menjadi advokat (advocate) untuk keamanan di organisasi
• Memimpin respons terhadap insiden keamanan

Manajer Proyek TI (IT Project Manager): Mengelola proyek TI dari inisiasi hingga penutupan. Memastikan proyek selesai tepat waktu, sesuai anggaran, dan memenuhi tujuan. Menjadi jembatan antara bisnis dan teknis.

Arsitek Enterprise (Enterprise Architect): Mendesain arsitektur sistem dan teknologi yang selaras dengan strategi bisnis. Memastikan integrasi dan interoperabilitas sistem. Menjaga standar teknis.

6.3.8 Bagaimana Menjelaskan Tata Kelola TI ke Kepala Daerah dan DPRD

Direktur Utama perusahaan utilitas air memiliki tantangan unik: menjelaskan tata kelola TI kepada Kepala Daerah dan DPRD yang mungkin tidak memiliki latar belakang teknologi. Padahal, persetujuan anggaran, dukungan politik, dan perlindungan saat insiden sangat bergantung pada pemahaman mereka. Bagian ini membekali Anda, sebagai Dirut, untuk menjembatani kesenjangan itu.

Menulis Memo Dua Halaman: Formula 5-3-1-1

Kepala Daerah membaca memo, bukan buku. Gunakan formula empat paragraf:

• 5 risiko: Tulis lima risiko TI terbesar yang dapat mengganggu layanan air minum (contoh: serangan siber ke SCADA, kegagalan sistem penagihan, kebocoran data pelanggan). Setiap risiko satu kalimat, tidak lebih.
• 3 proyek: Cantumkan tiga inisiatif TI prioritas yang sedang berjalan atau direncanakan, lengkap dengan status dan kebutuhan keputusan.
• 1 insiden: Ringkas satu insiden TI signifikan setahun terakhir: apa yang terjadi, dampaknya, dan pelajaran yang dipetik. Ini membangun kredibilitas: Anda jujur sekaligus belajar.
• 1 permintaan: Tutup dengan satu hal yang Anda butuhkan dari Kepala Daerah (persetujuan anggaran, arahan kebijakan, dukungan publik).

Menghadapi Rapat DPRD: Menghindari Jebakan Jargon

Saat rapat anggaran, anggota DPRD tidak perlu memahami perbedaan firewall, IDS, dan IPS. Mereka perlu memahami: berapa anggaran yang diminta, untuk melindungi apa, dan apa konsekuensi jika tidak disetujui. Gunakan analogi: “Sistem SCADA adalah otak pengolahan air; melindunginya sama seperti mengasuransikan aset produksi.”

Tiga pertanyaan yang hampir selalu muncul dan perlu Anda siapkan jawabannya:

1. “Kenapa anggaran TI naik padahal sistem sudah berjalan?”
2. “Apa buktinya investasi TI sebelumnya memberi hasil?”
3. “Bukankah ini tanggung jawab vendor?”

Menghadapi Panggilan DPRD Pasca-Insiden

Panggilan yang paling berbahaya bukan panggilan anggaran rutin; melainkan panggilan dadakan setelah insiden viral di media atau ada laporan masyarakat. Dalam situasi ini, Anda tidak datang dengan proposal. Anda datang untuk mempertahankan kredibilitas dan mencegah krisis politik. Berikut urutan yang dapat membantu.

Pertama, tentukan siapa bicara. Dirut menyampaikan kronologi dan dampak bisnis; Kepala Divisi TI menjawab detail teknis. Jangan Dirut menjawab teknis, jangan Kadiv TI menjawab dampak anggaran; satu peran menyelamatkan organisasi, satu peran lain menyelamatkan Dirut.

Kedua, buka dengan pengakuan berdampak tanpa menyalahkan. Kalimat yang bekerja: “Insiden ini berdampak pada X pelanggan di Y wilayah selama Z jam. Ini tidak boleh terjadi, dan saya sebagai penanggung jawab perusahaan meminta maaf.” Jangan buka dengan pembelaan teknis. Anggota DPRD ingin tahu Anda serius.

Ketiga, jelaskan akar masalah sebagai temuan organisasi, bukan kesalahan individu. Kalimat yang benar: “Berdasarkan investigasi awal, eskalasi terhambat karena prosedur kami belum mengatur skenario ini.” Kalimat yang salah: “Pak Budi lupa menghubungi atasannya.”

Keempat, ketika ditanya “siapa bertanggung jawab?”, jangan tunjuk orang. Katakan: “Saya sebagai Dirut bertanggung jawab penuh. Kami akan melaporkan hasil investigasi dan rencana perbaikan dalam 14 hari.” Ini mengalihkan dari pencarian kambing hitam ke akuntabilitas struktural.

Kelima, siapkan satu lembar ringkasan tertulis yang bisa ditinggalkan: kronologi, dampak, tindakan darurat yang sudah diambil, dan rencana perbaikan. Anggota DPRD akan memegang kertas itu saat berbicara ke media. Pastikan isinya akurat dan sama dengan yang Anda sampaikan lisan.

Mempersiapkan Diri untuk Audit BPK

Auditor BPK tidak mengaudit teknologi; mereka mengaudit kepatuhan dan dampak anggaran. Mereka akan menanyakan: apakah belanja TI sesuai aturan pengadaan? Apakah aset TI tercatat dan termanfaatkan? Apakah ada kerugian negara akibat kegagalan sistem? Pastikan dokumentasi pengadaan, berita acara serah terima, dan laporan manfaat selalu rapi sebelum audit dimulai.

Realitas Siklus Politik: Anda Bisa Diganti, Sistem Harus Berlanjut

Jabatan Dirut perusahaan daerah terikat siklus politik. Kepala Daerah baru dapat menunjuk Dirut baru. Karena itu, bangun kontinuitas: dokumentasikan keputusan strategis TI dalam bentuk kebijakan tertulis dan notulen forum resmi (IT Steering Committee), bukan dalam bentuk pesan WhatsApp atau arahan lisan. Kebijakan yang sudah dituangkan dalam surat keputusan jauh lebih sulit dibatalkan begitu saja oleh pemimpin baru.

Template memo ini dapat diadaptasi langsung dengan mengisi data spesifik organisasi Anda; sesuaikan bahasanya untuk Kepala Daerah di wilayah Anda. Referensi dan sumber daya pendukung tersedia di tools.itgbook.com.

Siklus Politik Daerah sebagai Risiko Tata Kelola

Di PDAM yang berstatus BUMD, Direksi diangkat dan diberhentikan oleh Kepala Daerah. Setiap pergantian Bupati atau Walikota; setiap 5 tahun, atau lebih cepat jika ada Pilkada serentak; berpotensi mengganti Direksi. Setiap pergantian Direksi berpotensi mengubah prioritas. Program tata kelola TI yang sudah berjalan 12 bulan bisa dihentikan oleh satu surat keputusan dari Dirut baru yang ingin “meninjau ulang semua program.”

Ini bukan anomali. Ini siklus yang dapat diprediksi. Karena dapat diprediksi, ia bisa dikelola:

1. Dokumentasi adalah pertahanan pertama. Program yang terdokumentasi dengan baik; tujuan, kemajuan, bukti hasil; lebih sulit dihentikan daripada program yang hanya ada di presentasi lisan. Ketika Dirut baru bertanya “apa manfaat program ini?”, Anda punya jawaban tertulis dengan angka. Ketika Dirut baru tidak bertanya, Anda punya dokumen untuk auditor yang akan bertanya nanti.

2. Kaitkan program dengan regulasi, bukan dengan kebijakan Dirut sebelumnya. Program yang dikaitkan dengan “arahan Dirut sebelumnya” akan mati ketika Dirut berganti. Program yang dikaitkan dengan “kewajiban UU PDP Pasal 20” atau “rekomendasi BPKP tahun lalu” akan bertahan; karena regulasi tidak berganti saat Dirut berganti.

3. Jangan berhenti saat isu politik memanas. Enam bulan sebelum Pilkada, prioritas pimpinan beralih dari operasional ke politik. Program tata kelola mungkin kehilangan perhatian; tetapi jangan dihentikan. Justru di masa ini, teruskan dokumentasi dan laporan rutin. Ketika pimpinan baru tiba, Anda bisa mengatakan: “Program ini berjalan bahkan saat transisi.” Itu bukti bahwa tata kelola sudah mulai melembaga, bukan bergantung pada individu.

4. Kenali pemangku kepentingan di luar Direksi. Dewan Pengawas, Kepala Bappeda, Inspektorat Daerah; mereka tidak berganti setiap Pilkada. Bangun hubungan informasional dengan mereka. Ketika Direksi berganti, Anda masih punya saluran untuk menjelaskan mengapa program tata kelola perlu dilanjutkan.

Untuk operator swasta mitra pemerintah, dinamika serupa terjadi saat kontrak kerja sama mendekati akhir atau saat Pemda mitra berganti. Strategi yang sama berlaku: kaitkan dengan regulasi, dokumentasikan kemajuan, dan jangan berhenti di masa ketidakpastian.

6.3.9 Tata Kelola TI dalam Skema Pemilik-Operator: Ketika Anda Bukan yang Menjalankan

Tidak semua perusahaan utilitas air menjalankan TI-nya sendiri. Dalam skema kerja sama pemerintah-swasta, seperti operator air kota besar yang mengontrakkan operasi ke mitra swasta, atau PDAM kabupaten yang mengontrakkan operasi penuh, BUMD adalah pemilik aset, data, dan pelanggan, tetapi operasi harian, termasuk TI, dijalankan oleh operator kontrak. Ini menciptakan tantangan tata kelola yang berbeda secara fundamental dari model PDAM dengan TI internal.

Realitas Struktural: Anda Memiliki, Mereka Menjalankan

Dalam skema ini, tidak ada Kepala Divisi TI yang melapor ke Dirut BUMD. TI dikelola oleh tim operator swasta. Kepala TI operator adalah rekan kontrak Anda, bukan bawahan Anda. Anda tidak bisa menginstruksikan mereka mengubah password; Anda harus mengontrakkannya. Anda tidak bisa meminta mereka membentuk Komite Pengarah TI; Anda harus menegosiasikannya.

Namun demikian, tanggung jawab hukum tidak ikut dikontrakkan keluar. UU PDP Pasal 1 menetapkan BUMD pemilik data pelanggan sebagai Pengendali Data Pribadi (bukan operatornya). UU ITE dan PP PSTE melekat pada sistem elektronik yang melayani publik, terlepas dari siapa yang menjalankannya. BPK akan mengaudit BUMD, bukan operator. Jadi, Anda bertanggung jawab secara hukum atas sesuatu yang tidak Anda jalankan secara harian. Inilah inti persoalannya.

Lima Prinsip Tata Kelola untuk BUMD Pemilik Aset

Pertama, tata kelola TI Anda adalah kontrak itu sendiri. Jika klausul tentang SLA, hak audit, kepemilikan data pasca-kontrak, rencana transisi, dan eskalasi insiden tidak tertulis di kontrak, maka ia tidak ada. RACI Anda dimulai dari kontrak kerja sama, bukan dari bagan organisasi internal.

Kedua, Komite Pengarah TI harus bersifat bilateral. Forum ini wajib beranggotakan perwakilan BUMD (Dirut, Direktur Operasi, dan penasihat teknis independen) dan perwakilan operator (manajer kontrak, Kepala TI operator, dan perwakilan operasional). Tanpa forum bilateral, tata kelola TI hanya terjadi di meja operator, bukan di meja pemilik.

Ketiga, bedakan kepemilikan data dari operasi data. Operator menjalankan billing, operator mengelola SCADA, operator mengoperasikan call center. Tetapi data pelanggan, data produksi, data keuangan, dan log insiden semuanya milik BUMD. Klausul kontrak harus menetapkan: (a) format data yang diserahkan setiap bulan, (b) hak akses BUMD ke database secara real-time atau near-real-time, dan (c) prosedur pengembalian penuh data saat kontrak berakhir, termasuk migrasi ke sistem pengganti.

Keempat, SLA bukan lampiran; ia instrumen tata kelola utama. Setiap SLA yang tidak disertai denda finansial hanyalah harapan. SLA harus mencakup: ketersediaan sistem kritis (SCADA, billing, portal pelanggan), waktu respons insiden per level keparahan, waktu pemulihan maksimum, dan mekanisme pelaporan bulanan yang diverifikasi oleh pihak ketiga bila diperlukan.

Kelima, siapkan exit plan sejak hari pertama. Kontrak kerja sama berjangka waktu. Saat kontrak berakhir, operator bisa berganti, tetapi operasi tidak boleh berhenti. Jangan biarkan operator menjadi satu-satunya pihak yang memahami arsitektur sistem, kode sumber, dan konfigurasi. Klausul transition assistance wajib mencakup: penyerahan dokumentasi teknis lengkap, pelatihan staf pengganti selama 3-6 bulan transisi, dan source code escrow untuk sistem yang dikembangkan khusus.

Checklist kontrak (daftar periksa untuk Direksi dan penasihat hukum BUMD yang menandatangani kontrak kerja sama operasi) tersedia di tools.itgbook.com.

6.4 Matriks RACI: Menetapkan Tanggung Jawab (template: tools.itgbook.com)

Untuk memperjelas peran dan tanggung jawab, organisasi dapat menggunakan matriks RACI: pelaksana (responsible), penanggung jawab akhir (accountable), pihak yang dikonsultasikan (consulted), dan pihak yang diberi informasi (informed). RACI sederhana, tetapi dampaknya besar: ia memaksa organisasi membedakan siapa yang mengerjakan, siapa yang bertanggung jawab akhir, siapa yang wajib diajak bicara, dan siapa yang cukup diberi informasi.

6.4.1 Konsep RACI

RACI bukan bagan jabatan. Ia peta keputusan. Satu orang bisa menjadi pelaksana untuk satu aktivitas, tetapi menjadi pihak yang hanya perlu diberi informasi untuk aktivitas lain.

• R - Pelaksana (responsible): Orang yang melakukan pekerjaan
• A - Penanggung jawab akhir (accountable): Orang yang bertanggung jawab akhir, hanya satu per aktivitas
• C - Pihak yang dikonsultasikan (consulted): Orang yang dikonsultasikan sebelum keputusan atau aktivitas
• I - Pihak yang diberi informasi (informed): Orang yang diberitahu setelah keputusan atau aktivitas

6.4.2 Contoh Matriks RACI untuk Tata Kelola TI

Tabel 6.1 menyajikan contoh RACI awal untuk tata kelola TI. Angka dan jabatan perlu disesuaikan dengan struktur masing-masing organisasi, tetapi prinsip utamanya tetap sama: satu aktivitas harus punya satu pihak yang accountable.

Tabel 6.1 Contoh matriks RACI untuk tata kelola TI

6.4.3 Prinsip Penggunaan RACI

1. Hanya satu penanggung jawab akhir (accountable) per aktivitas. Akuntabilitas ganda sering berarti tidak ada pihak yang benar-benar memegang keputusan akhir.
2. Pihak yang dikonsultasikan (consulted) harus terlibat sebelum keputusan. Jangan hanya menginformasikan setelah keputusan dibuat.
3. Pihak yang diberi informasi (informed) perlu informasi tepat waktu. Mereka mungkin perlu mengambil tindakan berdasarkan informasi tersebut.
4. RACI harus disepakati dan dikomunikasikan. Setiap orang harus memahami perannya.
5. RACI harus ditinjau berkala. Organisasi berubah, dan peran mungkin perlu disesuaikan.

6.4.4 Ketika RACI Dilewati: Manajer yang Bertanggung Jawab tetapi Dilewati

Sebuah matriks RACI yang rapi di atas kertas tetap bisa patah dalam praktik, dan cara patahnya paling sering begini: seorang Manajer TI tercatat bertanggung jawab atas seluruh sistem, tetapi di realitas harian ia dilewati. Manajemen di atasnya menugasi stafnya secara langsung, tanpa koordinasi. Pola ini biasanya tidak lahir dari niat buruk. Ia muncul dari keinginan akan kecepatan, dari kepercayaan pada staf tertentu, atau dari budaya hierarki di mana permintaan langsung seorang direktur sulit ditolak oleh staf junior, sebuah ewuh pakewuh yang khas di banyak organisasi kita. Apa pun pemicunya, hasilnya satu, dan termasuk cacat struktural paling korosif: tanggung jawab terpisah dari wewenang.

Akar masalahnya adalah ketidakcocokan antara akuntabilitas dan kendali. Manajer TI tetap menjadi nama yang ditanya ketika sistem bermasalah, tetapi ia tidak lagi mengendalikan apa yang sebenarnya dikerjakan stafnya; ia bertanggung jawab atas keputusan yang tidak pernah ia lihat. Risiko yang lahir dari sini tidak datang sebagai satu rentetan, melainkan sebagai beberapa kegagalan yang bisa muncul sendiri-sendiri, sebagaimana dirangkum Tabel 6.2.

Tabel 6.2 Pola pelewatan fungsi Manajer TI, risikonya, dan koreksi RACI

Di sinilah matriks yang baru kita susun berfungsi bukan sebagai bagan jabatan, melainkan sebagai pagar. Aturan dasarnya menuntut tepat satu penanggung jawab akhir per aktivitas, dan pelaksana yang dikoordinasikan melalui penanggung jawab akhir itu. Ketika staf dikerahkan langsung sementara atasan yang seharusnya akuntabel bahkan tidak tahu, RACI sudah patah di titik itu juga.

RACI yang sehat menyembuhkannya dengan membedakan dua ketinggian akuntabilitas yang sering dicampur. Seorang Direktur sah menetapkan prioritas dan menuntut hasil bisnis; itu akuntabilitasnya di tingkat tata kelola. Tetapi penugasan eksekusi teknis tetap harus mengalir melalui Manajer TI yang akuntabel atas penyampaian. Dua akuntabilitas pada dua ketinggian itu tidak bermasalah selama dipetakan; ia menjadi racun hanya ketika dirancukan, ketika penentu prioritas merangkap pemberi tugas harian dan melompati pemilik tanggung jawab pelaksanaan.

Tiga hal membuat pagar ini nyata. Pertama, RACI harus disepakati, dikomunikasikan, dan ditegakkan; RACI yang hanya tergambar rapi di dokumen tetapi diabaikan setiap hari mengidap penyakit yang sama dengan kematangan di atas kertas. Kedua, perlu ada norma eskalasi yang melindungi: staf yang menerima perintah langsung dapat berkata “siap, saya teruskan ke atasan agar tercatat” tanpa itu dianggap pembangkangan. Ketiga, kebutuhan lintas fungsi yang sah sebaiknya disalurkan lewat Komite Pengarah TI, bukan lewat jalur samping, sehingga penugasan menjadi keputusan yang terlihat, bukan bisikan.

Bagi Manajer TI, RACI yang jelas dan ditegakkan adalah cara mengembalikan wewenang yang sepadan dengan tanggung jawabnya, tanpa harus berubah menjadi pertengkaran wilayah pribadi; yang menuntut koordinasi adalah aturan main yang disepakati, bukan ego perorangan. Dan bagi Direksi, melewati Manajer TI memang terasa lebih cepat, tetapi sesungguhnya ia membongkar akuntabilitas yang justru akan Anda panggil ketika sistem bermasalah. Menugasi staf secara langsung berarti diam-diam menjadikan diri Anda Manajer TI de facto; saat audit datang, yang ditanya adalah Anda.

6.4.5 Ketika Perintah Justru Datang dari Atas

Ada cara lain wewenang merusak struktur, dan ia lebih halus daripada melewati seorang manajer: memerintahkan kontrol itu sendiri dimatikan sejenak. Kategori risiko ini nyaris tidak pernah tercatat di daftar risiko (risk register), justru karena ia datang dari orang yang menyusun daftar itu. Literatur kontrol internal sudah lama menamainya. Kerangka COSO dan standar audit atas risiko kecurangan (fraud) seperti ISA 240 menempatkan penerobosan kontrol oleh manajemen (management override of controls) sebagai keterbatasan bawaan (inherent limitation) dari sistem kontrol mana pun: kontrol mengandaikan orang mematuhinya, padahal orang yang merancang kontrol biasanya juga yang paling mudah menangguhkannya. COBIT menjawabnya lewat pemisahan tegas antara fungsi tata kelola (arah dan pengawasan) dan fungsi manajemen (pelaksanaan), agar tidak ada satu pihak yang bisa sekaligus memerintah, menjalankan, dan menutup jejaknya.

Pemicunya bermacam-macam. Kadang berupa permintaan membuka akses jarak jauh (remote) untuk vendor di tengah gangguan; kadang permintaan menyalin data operasional ke luar “untuk keperluan rapat”; kadang permintaan melewati prosedur pengadaan karena “sudah dibahas di atas”. Bentuknya berganti, strukturnya satu: prosedur mensyaratkan permohonan berlapis lewat matriks persetujuan (approval matrix), sementara seseorang yang lebih senior meminta jalan pintas sekarang juga, dengan janji administrasi menyusul. Janji “menyusul” itu termasuk yang paling jarang ditepati.

Perhatikan satu detail yang menentukan: perintah semacam ini cenderung lisan. Yang tertinggal kemudian hanyalah satu baris di catatan sistem (log) yang mencatat bahwa seorang staf melaksanakan sesuatu di luar prosedur. Perintah lisannya menguap; catatan pelaksananya tidak. Inilah asimetri yang membuatnya berbahaya: yang memerintah memegang wewenang tanpa jejak, yang melaksanakan memegang jejak tanpa wewenang. Tata kelola yang sehat tidak boleh membiarkan seorang pegawai memikul pilihan antara membangkang kepada atasan atau menjadi satu-satunya nama yang tertinggal saat penelusuran dilakukan.

Maka kontrol yang baik tidak berpura-pura bahwa penerobosan bisa dilarang sama sekali. Keadaan darurat itu nyata; sistem inti yang bermasalah sesekali menuntut kecepatan yang melampaui jalur persetujuan normal. Tujuan tata kelola bukan meniadakan jalan pintas, melainkan memastikan setiap jalan pintas meninggalkan bekas yang tidak bisa dihapus. Sebagaimana dirangkum Tabel 6.3, perbedaan antara penerobosan yang berisiko dan akses darurat yang aman tidak terletak pada kecepatannya, melainkan pada apakah ia meninggalkan jejak yang utuh.

Tabel 6.3 Perbedaan menangani perintah menerobos kontrol secara informal versus melalui jalur akses darurat yang terkelola

Empat rancangan membuat pergeseran itu nyata. Pertama, sediakan prosedur akses darurat (break-glass) yang resmi: akses istimewa (privileged access) sementara yang sudah dipra-otorisasi, berbatas waktu sehingga kedaluwarsa otomatis, dan memicu pencatatan serta pemberitahuan ke pihak kedua. Ini berbeda dari akses rutin berbatas waktu untuk pihak ketiga yang dibahas di Bab 7; yang ini khusus untuk keadaan darurat. Kedua, terapkan pemisahan tugas (segregation of duties): pisahkan yang memerintah dari yang menjalankan, sehingga pemberian akses istimewa selalu menuntut pihak penyetuju kedua yang tidak melapor kepada pemohon, dan satu penerobosan membutuhkan dua orang, bukan satu. Ketiga, jadikan “tulis dulu” sebagai norma yang melindungi, bukan tanda pembangkangan; pegawai yang meminta perintah menyusul lewat surel atau tiket sedang menjalankan prosedur. Keempat, penerobosan yang tercatat tetapi tidak pernah dibaca hanyalah teater; Satuan Pengawas Intern atau komite audit perlu menjadikan tinjauan catatan akses darurat sebagai bagian rutin pemeriksaannya.

Pada akhirnya, kontrol paling efektif terhadap penerobosan dari atas bukan teknologi, melainkan sikap di puncak (tone at the top). Bila Dewan Pengawas memperlakukan informasi bahwa sebuah kontrol pernah diterobos sebagai bahan untuk ditindaklanjuti, bukan aib untuk dikubur, insentifnya berbalik: menerobos diam-diam menjadi lebih berisiko daripada menempuh jalur darurat yang tercatat.

Bagi Direksi, rancangan ini bekerja untuk kepentingan Anda. Perintah lisan yang diberikan di tengah tekanan bisa berubah menjadi satu baris log yang ditemukan saat audit, dengan hanya nama bawahan yang tertera; prosedur akses darurat memindahkannya ke tempat yang tercatat resmi, sehingga keputusan sah Anda tidak menjelma menjadi temuan pribadi orang lain. Bagi Manajer TI dan stafnya, jalur darurat yang resmi inilah yang memungkinkan mereka mematuhi perintah mendesak tanpa harus memilih antara loyalitas dan kewarasan kontrol.

RACI dalam Struktur yang Tidak Ideal: Ketika TI Berada di Bawah Bagian Umum

Struktur organisasi yang digambarkan di atas; CIO setara direksi, komite pengarah hadir; adalah struktur ideal. Kenyataannya, di banyak PDAM menengah dan kecil, fungsi TI adalah sub-bagian di bawah Bagian Umum, Bagian Keuangan, atau Bidang Administrasi. Kepala TI tidak hadir di rapat Direksi. Usulan investasi TI harus melewati dua tingkat hierarki sebelum sampai ke pengambil keputusan.

Apakah tata kelola TI masih bisa dijalankan dalam struktur seperti ini? Bisa. Tapi memerlukan strategi yang berbeda:

1. RACI Anda tidak dimulai dari struktur formal; tapi dari insiden. Pada insiden pertama yang berdampak ke pelanggan, tanyakan dalam rapat pasca-insiden: siapa yang memutuskan X? Siapa yang seharusnya dikonsultasikan? Gunakan insiden nyata untuk menunjukkan bahwa struktur saat ini menciptakan gap akuntabilitas. RACI yang lahir dari insiden lebih sulit ditolak daripada RACI yang diusulkan sebagai “program baru.”

2. Jadikan atasan non-TI Anda sebagai sponsor, bukan penghalang. Kabag Umum yang membawahi TI mungkin tidak paham COBIT; tetapi ia paham risiko audit. Bantu ia memahami bahwa tata kelola TI melindunginya: ketika BPK atau BPKP menemukan masalah TI, yang dipanggil pertama adalah Kabag yang membawahi TI, bukan staf teknisnya. Jika Kabag Anda paham bahwa RACI adalah pelindung pribadinya, ia akan mendukung.

3. Forum keputusan tidak harus formal. Jika Anda tidak bisa membentuk IT Steering Committee formal, buat “Rapat Koordinasi TI Bulanan” yang dihadiri perwakilan operasi, keuangan, dan umum. Meskipun tidak bernama steering committee, fungsinya sama: keputusan lintas fungsi dibahas sebelum dieksekusi.

4. Dokumentasikan keputusan, meskipun tidak ada surat keputusan. Notulen rapat, disposisi email, atau memo singkat yang menyatakan “disetujui oleh Kabag Umum tanggal X” cukup untuk memulai audit trail. Yang penting: ada bukti bahwa keputusan dibuat secara sadar, bukan kebetulan.

Target jangka menengah: struktur membaik. Tetapi jangan tunggu struktur membaik untuk memulai tata kelola. Mulai dari apa yang ada; dengan RACI yang dipaksakan oleh insiden, bukan oleh bagan organisasi.

6.5 Implementasi: Dari Struktur Saat Ini ke Target

Banyak organisasi memiliki struktur organisasi TI yang “terbentuk secara organik” selama bertahun-tahun, bukan dirancang secara strategis. Bagian ini memberikan panduan untuk transisi dari struktur saat ini ke struktur yang diinginkan.

Berdasarkan pengamatan, struktur yang tumbuh organik biasanya menyimpan satu masalah sunyi: keputusan penting mengikuti orang yang paling aktif, bukan orang yang secara formal paling bertanggung jawab. Selama orang itu kuat, organisasi tampak berjalan. Ketika orang itu pindah atau kelelahan, lubang akuntabilitas baru terlihat.

6.5.1 Langkah 1: Asesmen Struktur Saat Ini

Langkah pertama adalah memahami struktur saat ini:

Ketika Pimpinan Berganti: Strategi Transisi Program Tata Kelola

Rata-rata Dirut PDAM menjabat 3-4 tahun. Program tata kelola TI membutuhkan 18-24 bulan untuk menunjukkan hasil penuh. Ini berarti: di banyak PDAM, Dirut yang memulai program bukan Dirut yang akan memetik hasilnya. Ini risiko struktural yang melekat pada siklus kepemimpinan BUMD.

Strategi untuk menjaga keberlanjutan:

1. Siapkan “Dokumen Transisi” setiap kali program mencapai tonggak besar. Dokumen satu halaman berisi: (a) apa yang sudah dicapai, (b) apa yang sedang berjalan, (c) tiga risiko jika program dihentikan, (d) rekomendasi untuk 6 bulan ke depan. Dokumen ini harus cukup ringkas untuk dibaca Dirut baru dalam 10 menit; dan cukup solid untuk dijadikan pegangan oleh staf yang akan melanjutkan.

2. Tanam program di lapisan operasional, bukan hanya di lapisan strategis. Jika hanya Dirut dan CIO yang memahami program, program akan mati saat keduanya pergi. Latih manajer operasi, manajer keuangan, dan staf kunci tentang mengapa tata kelola ini ada dan bagaimana menjalankannya. Program yang dijalankan oleh lima orang lebih tahan terhadap pergantian pimpinan daripada program yang dijalankan oleh satu orang.

3. Gunakan audit sebagai jangkar. Temuan dan rekomendasi BPK/BPKP tidak hilang saat Dirut berganti. Jika program tata kelola Anda adalah respons terhadap rekomendasi audit, Dirut baru tidak bisa menghentikannya tanpa menciptakan repeat finding; yang akan ditanyakan DPRD. Kaitkan program dengan rekomendasi audit sejak awal.

4. Jangan melawan Dirut baru. Beri ia data. Dirut baru mungkin ingin mengubah arah. Itu haknya. Tapi sebelum ia memutuskan, beri ia data: berapa biaya yang sudah dikeluarkan, berapa risiko jika dihentikan, berapa waktu yang dibutuhkan untuk memulai ulang nanti. Keputusan mungkin tetap sama; tapi setidaknya dibuat dengan informasi lengkap, bukan dengan asumsi.

Untuk Kepala TI: pergantian pimpinan adalah ujian apakah tata kelola yang Anda bangun adalah tata kelola organisasi; atau tata kelola Anda sendiri. Jika program bertahan tanpa Anda, Anda berhasil. Jika program mati saat Anda atau Dirut pergi, itu bukan tata kelola; itu karisma individu.

1. Pemetaan struktur organisasi. Buat diagram yang menunjukkan: siapa melapor ke siapa, di mana fungsi TI berada, dan bagaimana keputusan dibuat.
2. Identifikasi masalah. Tanyakan: (a) di mana hambatan keputusan (bottlenecks) terjadi?, (b) di mana duplikasi (duplication) terjadi?, (c) di mana celah kepemimpinan (leadership gaps) ada?, dan (d) di mana konflik (conflicts) paling sering muncul?
3. Kumpulkan perspektif. Wawancarai: manajemen puncak, manajer TI, pemilik proses bisnis, dan staf TI. Setiap perspektif memberikan wawasan berharga.

6.5.2 Langkah 2: Desain Struktur Target

Berdasarkan asesmen, rancang struktur target:

1. Tentukan model utama. Pilih antara centralized, decentralized, atau federal/shared services berdasarkan faktor-faktor di bagian 6.2.5.
2. Definisikan peran kunci. Tetapkan: siapa Kepala TI atau CIO dan apa perannya, bagaimana Komite Pengarah TI dibentuk, dan apa peran pemilik proses bisnis.
3. Rancang jalur pelaporan. Tentukan: siapa melapor ke siapa, di mana pelaporan fungsional (dotted line) diperlukan, dan bagaimana koordinasi lintas fungsi bekerja.

6.5.3 Langkah 3: Rencana Transisi

Transisi dari struktur saat ini ke target memerlukan perencanaan yang hati-hati:

1. Identifikasi hasil cepat (quick wins). Apa yang dapat diubah dengan mudah tetapi memberikan dampak signifikan? Contoh: pembentukan Komite Pengarah TI dapat dilakukan dengan cepat dan memberikan nilai segera.
2. Urutkan perubahan. Beberapa perubahan mungkin saling bergantung. Buat urutan logis untuk implementasi.
3. Kelola resistensi. Perubahan struktur sering menimbulkan resistensi. Siapkan: komunikasi tentang alasan perubahan, pelatihan untuk peran baru, dan dukungan selama transisi.

6.5.4 Langkah 4: Implementasi dan Pemantauan

Implementasikan perubahan secara bertahap:

1. Komunikasikan secara luas. Jelaskan: mengapa perubahan diperlukan, apa manfaat yang diharapkan, dan bagaimana proses akan berjalan.
2. Latih dan dukung. Sediakan pelatihan untuk peran baru, mentoring bagi mereka yang transisi, dan dukungan teknis selama periode penyesuaian.
3. Pantau dan sesuaikan. Tidak ada rencana yang sempurna. Pantau apakah perubahan memberikan hasil yang diharapkan, apakah ada dampak tidak terduga (unintended consequences), dan bagian mana yang perlu disesuaikan.

6.5.6 Shared IT Services Lintas PDAM: Model Tata Kelola Multi-Entity

Di beberapa provinsi, PDAM-PDAM dalam satu wilayah mulai menjajaki model shared IT services: satu data center digunakan bersama, satu sistem billing melayani beberapa PDAM, atau satu tim keamanan informasi menangani seluruh anggota. Model ini menjanjikan efisiensi biaya; tetapi membawa kompleksitas tata kelola yang berbeda dari single entity.

Pertanyaan tata kelola yang harus dijawab sebelum memulai:

1. Siapa pemilik risiko? Jika data center bersama mengalami insiden, PDAM mana yang bertanggung jawab? Jika jawabannya “semua,” risikonya tidak ada yang bertanggung jawab. Solusi: bentuk entitas pengelola bersama (mis. Unit Layanan Bersama di bawah asosiasi PDAM atau Pemprov) dengan RACI yang ditandatangani bersama.

2. Siapa yang membayar? Model pembiayaan bisa berbasis: (a) proporsi sambungan pelanggan, (b) proporsi volume transaksi, (c) flat fee per PDAM, atau (d) subsidi silang dari PDAM besar ke PDAM kecil. Masing-masing model menciptakan dinamika tata kelola yang berbeda. Model (a) dan (b) lebih adil tetapi membutuhkan transparansi data yang sering kali belum tersedia di awal.

3. Bagaimana jika satu anggota ingin keluar? Klausul exit harus disepakati sebelum onboarding: berapa biaya pemisahan, berapa lama masa transisi, siapa yang memegang data historis. Tanpa klausul exit, shared services menjadi shared prison.

4. Siapa yang berwenang memutuskan investasi? Jika PDAM A ingin upgrade ke versi terbaru tapi PDAM B dan C tidak setuju, siapa yang memutuskan? Mekanisme pengambilan keputusan harus disepakati di awal: suara mayoritas, konsensus, atau hak veto untuk anggota dengan kontribusi terbesar.

Model RACI untuk shared services (contoh: satu sistem billing untuk 3 PDAM):

Pelajaran dari pola yang sudah berjalan: Shared services yang berhasil biasanya dimulai dari satu layanan sederhana (mis. hosting bersama, bukan billing bersama) dan diperluas secara bertahap setelah kepercayaan terbangun. Jangan memulai dengan sistem core; risikonya terlalu besar untuk eksperimen tata kelola.

6.6 Penutup Bab

Struktur organisasi TI bukan bagan jabatan yang ditempel di dinding. Ia adalah desain keputusan. Dari struktur itulah terlihat siapa yang berwenang, siapa yang bertanggung jawab, siapa yang harus dikonsultasikan, dan siapa yang boleh menghentikan keputusan ketika risikonya tidak dapat diterima.

Untuk perusahaan utilitas air, struktur yang lemah biasanya terlihat saat terjadi gangguan layanan: Kepala TI merasa sudah pernah memperingatkan, operasi merasa tidak pernah dilibatkan, keuangan merasa tidak pernah menerima justifikasi, dan Direksi baru melihat isu setelah menjadi krisis. Struktur yang baik membuat percakapan itu terjadi sebelum krisis.

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 struktur keputusan TI yang jelas. Teknologinya berbeda, tetapi pertanyaan organisasinya sama: siapa yang memutuskan, siapa yang menanggung risiko, dan siapa yang memastikan keputusan itu dijalankan?

💡 Angka yang mengubah keputusan: 1 orang. Setiap keputusan kritis harus punya tepat SATU Accountable, bukan komite, bukan tim. Kalau dua orang accountable, tidak ada yang accountable.

Catatan Akhir: Mengikat Makna

Inti dari perombakan peran dan struktur bisa diringkas dalam beberapa pernyataan berikut:

• Struktur mengikuti strategi; organisasi perlu tahu keputusan TI apa yang harus diambil sebelum memilih model organisasi.
• TI perlu memiliki seat at the table agar risiko teknologi tidak muncul sebagai kejutan manajemen.
• Model terpusat, terdesentralisasi, federatif, dan hibrida masing-masing punya konsekuensi terhadap standar, kecepatan respons, biaya, dan risiko.
• RACI membantu organisasi menetapkan tanggung jawab secara eksplisit, terutama untuk keputusan lintas fungsi.
• Perubahan struktur harus dilakukan bertahap, dimulai dari keputusan kritis yang paling sering tersangkut.

Uji Nyali Eksekutif: Lima Pertanyaan yang Harus Bisa Anda Jawab

1. Apakah Kepala TI atau CIO memiliki akses langsung ke forum yang membahas strategi, investasi, risiko, dan prioritas organisasi?
2. Keputusan TI apa yang paling sering tertunda karena tidak jelas siapa yang berwenang memutuskan?
3. Apakah organisasi memiliki IT Steering Committee yang benar-benar mengambil keputusan, bukan hanya menerima laporan?
4. Untuk sistem kritis, siapa satu pihak yang accountable ketika terjadi gangguan layanan?
5. Apakah struktur saat ini membuat risiko TI naik ke Direksi sebelum menjadi insiden?

Aksi Instan: Tiga Gebrakan untuk Minggu Ini

1. Gambar struktur TI saat ini dalam satu halaman: siapa melapor ke siapa, siapa pemilik keputusan teknis, dan siapa pemilik keputusan strategis.
2. Identifikasi satu keputusan TI yang rutin tersangkut karena tidak jelas siapa yang berwenang memutuskan.
3. Susun rancangan RACI untuk tiga proses kritis: perubahan sistem, pemilihan vendor, dan eskalasi insiden.

Amunisi Rapat: Daftar Periksa Struktur TI

Gunakan daftar pertanyaan di bawah ini untuk memicu diskusi kritis yang memastikan seluruh tim selaras dengan target tata kelola:

• Struktur TI saat ini sudah dapat digambar dalam satu halaman
• Jalur eskalasi risiko TI ke Direksi jelas
• Ada satu pemilik akhir untuk keputusan investasi TI besar
• Ada RACI untuk perubahan sistem, vendor, dan insiden
• Peran tata kelola dan manajemen tidak dirangkap tanpa kontrol pengimbang
• Steering committee memiliki mandat, agenda, dan produk keputusan yang jelas

🛠️ Besok pagi, coba ini: Lihat bagan organisasi TI. Kalau Kepala TI melapor ke Direktur Keuangan, tanyakan: apakah keputusan investasi TI Rp 5 M ditentukan oleh orang yang latar belakangnya akuntansi?

Untuk Disampaikan ke Direksi

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

1. Struktur adalah desain keputusan, bukan bagan jabatan. Dari struktur terlihat siapa berwenang, siapa bertanggung jawab, dan siapa yang boleh menghentikan keputusan saat risiko tidak bisa diterima.
2. Setiap keputusan kritis harus punya tepat SATU orang Accountable. Bukan komite, bukan tim. Kalau dua orang accountable, tidak ada yang accountable. Gunakan RACI untuk memetakan ini secara eksplisit.
3. Kepala TI harus punya akses langsung ke forum strategis. Jika CIO hanya dilibatkan setelah keputusan investasi dibuat, organisasi merancang kegagalan sejak awal. Seat at the table adalah prasyarat, bukan privilege.

Gunakan Tabel RACI di §6.4 sebagai template untuk memetakan keputusan kritis pertama.

Amunisi Rapat: Satu Pertanyaan Penguji Pimpinan

Siapa satu orang yang benar-benar accountable atas risiko TI terbesar organisasi kita hari ini?

Jawaban atas pertanyaan ini biasanya membuka masalah struktur yang selama ini tersembunyi. Jika jawabannya “semua pihak”, biasanya berarti tidak ada satu pihak pun yang benar-benar memegang akuntabilitas.

Menuju Bab 7: Dokumentasi yang Menjaga Akuntabilitas

Struktur memberi nama pada pemilik keputusan. Tetapi struktur belum cukup jika keputusan, standar, dan bukti pelaksanaannya tidak terdokumentasi. Bab 7 membahas bagaimana dokumentasi dan standar membuat akuntabilitas itu dapat dijalankan, diaudit, dan diperbaiki.

Referensi & Eksplorasi Lanjutan

1. ISO/IEC 38500:2024: Information technology: Governance of IT for the organization

   • ISO (2024). Standar internasional untuk tata kelola TI tingkat organ pengarah organisasi.
   • 🔗 ISO.org

2. COBIT 2019: Governance and Management Objectives

   • ISACA (2019). Objektif tata kelola dan manajemen COBIT untuk informasi dan teknologi.
   • 🔗 COBIT 2019

3. IT Governance: How Top Performers Manage IT Decision Rights

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

4. PP No. 54 Tahun 2017 tentang Badan Usaha Milik Daerah

   • Pemerintah Indonesia (2017). Regulasi tata kelola BUMD, termasuk organ, satuan pengawas intern, komite audit, komite lain, operasional, pelaporan, dan tata kelola perusahaan yang baik.
   • 🔗 JDIH BPK

5. UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi

   • Pemerintah Indonesia (2022). Dasar hukum pelindungan data pribadi, kewajiban pengendali dan prosesor data pribadi, serta relevansi fungsi pelindungan data.
   • 🔗 JDIH BPK

6. Perpres No. 38 Tahun 2015 tentang Kerja Sama Pemerintah dengan Badan Usaha dalam Penyediaan Infrastruktur

   • Pemerintah Indonesia (2015). Konteks regulasi untuk kerja sama pemerintah dan badan usaha, relevan bagi operator swasta utilitas air mitra pemerintah.
   • 🔗 JDIH BPK

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. Struktur organisasi yang optimal bergantung pada konteks spesifik setiap organisasi dan memerlukan pertimbangan matang mengenai budaya, sumber daya, dan strategi bisnis. Perubahan struktur organisasi adalah perubahan signifikan yang harus dikelola dengan hati-hati untuk meminimalkan disrupsi operasional. Hook pembuka adalah komposit pembelajaran, bukan rekonstruksi satu organisasi tertentu.