Bab 5: Struktur Organisasi TI & Peran

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

Tiga Hal yang Wajib Dibawa Pulang

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

Peta Konsep Bab Ini

Diagram 5.1 menunjukkan alur Bab 5: 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 organisasi layanan publik dan utilitas: Kepala TI meminta pembaruan infrastruktur yang sudah menua, tetapi forum pimpinan melihatnya sebagai urusan teknis. Kalimat yang muncul kurang lebih begini: “TI itu urusan operator, bukan manajemen.”

Beberapa bulan kemudian, sistem core yang sama mengalami gangguan besar. Operasi berhenti, loket layanan tersendat, transaksi pelanggan tertunda, dan tim lapangan harus menjawab keluhan tanpa informasi yang cukup. Dalam rapat darurat, 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 4 membahas risiko, bab ini membahas siapa yang memegang risiko itu di dalam struktur organisasi.

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3.3 Kepala TI atau Chief Information Officer (CIO)

Kepala TI atau CIO adalah penggerak utama tata kelola TI di organisasi. Perannya mencakup:

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.

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

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

[!WARNING] 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.

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

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

5.4 Matriks RACI: Menetapkan Tanggung Jawab

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.

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

5.4.2 Contoh Matriks RACI untuk Tata Kelola TI

Tabel 5.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 5.1 Contoh matriks RACI untuk tata kelola TI

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

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

5.5.1 Langkah 1: Asesmen Struktur Saat Ini

Langkah pertama adalah memahami struktur saat ini:

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.

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

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

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

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

Ringkasan Bab

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

Lima Pertanyaan Refleksi untuk Direksi

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?

Tiga Langkah yang Bisa Dimulai 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.

Daftar Periksa Rapat 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

Satu Pertanyaan untuk Dibawa ke Rapat Direksi Berikutnya

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”, hampir dipastikan berarti tidak ada satu pihak pun yang benar-benar memegang akuntabilitas.

Menuju Bab 6: Dokumentasi yang Menjaga Akuntabilitas

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

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