Listrik padam sebentar. Mungkin cuma 30 detik. Tapi efeknya? Lebih dari 10 kelas Zoom mendadak gelap. Instruktur bingung, siswa komplain, dan tim IT sibuk cari penyebab.

Setelah dicek, masalahnya sederhana tapi menggelikan: router di ruang server mati. Bukan karena UPS tidak berfungsi—karena memang tidak ada UPS untuk router itu. Dan yang lebih bikin geleng-geleng: colokan listrik router ternyata nyambung ke ruang sebelah, yang sama sekali tidak dalam kendali tim IT.

Saya mencoba mencari jawaban atas pertanyaan sederhana: siapa sebenarnya yang bertanggung jawab atas infrastruktur jaringan kritis ini?

Jawabannya mengejutkan: nganu itu...!??

"Bukan Bagian Saya": Ketika Tanggung Jawab Menguap

Ilustrasi ini murni rekaan, tapi percayalah—kejadiannya nyata bisa terjadi di kantor mana pun.

Melalui obrolan whastapp begini: 

si-K : "Lo tahu nggak, yang bikin gue kesel bukan listrik matinya. Tapi pas gue tanya ke bagian gedung, 'Pak, kenapa router kita coloknya di ruang sebelah, bukan di ruang server yang ada UPS-nya?' Mereka jawab, 'Oh, itu kan urusan IT, Pak. Dulu pas pemasangan, tim IT yang minta colok di situ soalnya dekat sama tiang kabel. Kami cuma sediain stopkontak.'"

Saya coba konfirmasi ke koordinator gedung. Sebut saja si-A.

si-A: "si-K, kami di gedung urusannya AC, lampu, kebersihan, dan nyediain stopkontak sesuai permintaan. Dulu tim IT yang minta pasang di ruang sebelah karena katanya dekat jalur kabel. Kami nggak tahu kalau itu ternyata rawan mati listrik. Yang jelas, kalau ada masalah kelistrikan, kami siap bantu. Tapi urusan router, ya domain IT."

Dua versi, dua keyakinan, dan satu kesimpulan: tidak ada yang merasa punya tanggung jawab atas infrastruktur kritis ini—dan yang lebih parah, tidak ada yang pernah mendokumentasikan kenapa router dipasang di tempat itu.

Saya lalu coba naik level. sebut saja si-F.

si-F: "Pak, selama ini kami percaya tim teknis sudah menjalankan tugasnya dengan baik. Toh selama ini nggak pernah masalah. Soal router colok di mana, kami pikir sudah dipikirkan matang-matang sama IT dan gedung."

Nah, ini dia. "Selama ini nggak pernah masalah" adalah kalimat paling berbahaya dalam tata kelola TI. Karena ketika masalah datang, tidak ada yang siap.

Akar Masalah: Tidak Ada Kejelasan "Who Owns What"

Dari obrolan panjang dengan berbagai pihak, saya menarik benang merah:

Tidak ada struktur kepemilikan yang jelas atas aset-aset kritis.

Dalam governance yang baik, setiap aset penting harus punya owner—seseorang atau tim yang:

1. Tahu aset itu ada dan dalam kondisi apa

2. Bertanggung jawab atas kinerja dan perawatannya

3. Memiliki kewenangan untuk mengalokasikan sumber daya buat merawatnya

4. Diukur kinerjanya berdasarkan kondisi aset tersebut

Di kantor ini:

• Router adalah aset kritis (tanpanya, internet mati, 10 kelas Zoom gelap, bisnis terganggu)

• Tapi tidak ada yang merasa memilikinya sepenuhnya

• Tim IT menguasai konfigurasi, tapi tidak mengontrol sumber listrik

• Tim gedung menyediakan listrik, tapi tidak tahu prioritas mana yang harus diproteksi

• Tidak ada dokumentasi kenapa router dipasang di lokasi itu

• Tidak ada yang pernah mengevaluasi risiko dari konfigurasi ini

• Tidak ada yang diukur berdasarkan apakah koneksi internet tetap stabil atau tidak

Hasilnya: aset kritis dibiarkan bergantung pada stopkontak di ruang sebelah yang tidak terproteksi, tanpa ada yang menyadari risikonya—sampai akhirnya listrik padam dan semuanya kacau.

COBIT 2019: Struktur Kepemilikan yang Jelas

Sebenarnya, framework tata kelola seperti COBIT 2019 sudah mengatur ini dengan cukup jelas. Dalam domain EDM01 (Ensure Governance Framework Setting and Maintenance) , ada prinsip dasar: setiap keputusan harus punya pemilik, setiap aset harus punya penanggung jawab.

Lebih spesifik, domain APO01 (Manage the IT Management Framework) mengatur tentang penetapan struktur organisasi TI, termasuk:

• RACI chart yang jelas untuk setiap proses dan aset

• Pemisahan tugas yang tegas

• Akuntabilitas yang tidak tumpang tindih

Dalam kasus router ini, seharusnya ada:

• Accountable: Satu orang di tim IT yang jawabannya "ya, saya yang bertanggung jawab atas koneksi internet, termasuk memastikan listriknya aman"

• Responsible: Teknisi yang memasang, mengonfigurasi, dan memeriksa rutin

• Consulted: Tim gedung yang perlu diajak diskusi soal lokasi dan ketersediaan listrik

• Informed: Manajemen yang perlu tahu kondisi dan risiko

Tapi kenyataannya di kantor ini, RACI-nya kosong—atau sekedar formalitas. Tidak ada yang benar-benar accountable. Dan ketika tidak ada yang accountable, tidak ada yang peduli. Paling kalau audit aja baru peduli. #eh

Dampak dari Kepemilikan yang Tidak Jelas

Ketika tidak ada yang jelas memiliki suatu aset, yang terjadi adalah:

1. Tidak Ada Dokumentasi Keputusan

Kenapa sumber listrik router dipasang di ruang sebelah? Tidak ada yang tahu. Tim IT yang dulu sudah pindah. Tim gedung lupa. Yang tersisa hanya "sudah dari sananya".

2. Tidak Ada Evaluasi Risiko

Tidak ada yang pernah bertanya: "Bagaimana kalau listrik di ruang sebelah mati? Apa dampaknya?" Karena tidak ada yang merasa bertanggung jawab, tidak ada yang melakukan assessment.

3. Tidak Ada Perbaikan Proaktif

Bahkan setelah kejadian, masih terjadi debat kusir: siapa yang harus pindahin colokan? Siapa yang tanggung biaya tambahan UPS?

4. Ketika Gagal, Semua Menunjuk

Yang paling menyedihkan: saat krisis terjadi, semua orang saling menunjuk. Tim IT menyalahkan gedung karena colokannya di situ. Gedung menyalahkan IT karena dulu minta di situ. Manajemen menyalahkan keduanya. Produktivitas habis untuk cari kambing hitam, bukan untuk mencari solusi.

Pelajaran: Mulai dengan Hal Sederhana

Memperbaiki governance tidak harus dimulai dengan proyek besar atau konsultan mahal. Di kantor ini, saya sarankan mulai dengan langkah-langkah sederhana:

1. Inventory Aset Kritis + Dependency Mapping

Duduk bersama, tulis semua aset yang kalau rusak/mati bisa menghentikan bisnis. Tapi jangan catat asetnya saja—catat juga dependensinya. Router tergantung pada listrik di ruang mana. Server tergantung pada UPS dan AC. Jangan sampai ada "dependensi siluman" seperti colokan di ruang sebelah yang tidak terdeteksi.

2. Tentukan Owner untuk Setiap Aset

Untuk setiap aset, tulis satu nama yang jawabannya "saya yang bertanggung jawab". Bukan tim, bukan departemen—satu orang. Orang ini tidak harus melakukan semua sendiri, tapi dia yang memastikan semuanya beres, termasuk:

• Memastikan dependensi terpetakan

• Memastikan risiko teridentifikasi

• Memastikan dokumentasi ada

3. Buat Rutinitas Sederhana

• Setiap 3 bulan, review aset kritis dan dependensinya

• Cek apakah ada perubahan (colokan dipindah, ruang direnovasi, dll)

• Hasilnya dicatat dan dilaporkan ke manajemen

4. Masukkan ke KPI

Jadikan kondisi aset dan kelengkapan dokumentasi sebagai salah satu ukuran kinerja. Misal: "Semua aset kritis memiliki dependency map yang ter-update" masuk ke KPI tim IT. Kalau tidak ada, ada konsekuensinya.

5. Komunikasikan ke Semua

Pastikan semua orang tahu siapa owner aset apa. Kalau ada masalah atau perubahan, mereka tahu ke mana harus lapor. Tidak ada lagi "saya kira bukan bagian saya".

Refleksi: Jangan Biarkan Aset Kritis Jadi "Anak Yatim"

Router di ruang server itu seperti anak yatim—tidak jelas siapa yang mengasuh, tidak jelas bagaimana sejarahnya, tidak jelas siapa yang bertanggung jawab kalau sakit. Dan seperti anak yatim yang tidak terurus, suatu saat dia akan tumbuh jadi masalah.

Di kantor ini, colokan router akhirnya jadi "titik gagal" di saat kritis. Bukan karena peralatannya jelek, tapi karena tidak ada yang pernah mendokumentasikan keputusan masa lalu dan mengevaluasi risikonya secara berkala.

Pertanyaan buat kita:

• Di organisasi lo, aset kritis apa yang tidak jelas dependensinya?

• Router, server, koneksi internet—lo tahu persis colokannya di mana dan dilindungi apa?

• Apakah ada keputusan teknis masa lalu yang tidak terdokumentasi dan tidak pernah dievaluasi lagi?

• Kalau lo tanya ke tim IT, mereka tunjuk orang yang sama atau saling lempar?

Karena percayalah: kalau tidak ada yang jelas memiliki, tidak ada yang akan peduli. Kalau tidak ada dokumentasi, sejarah akan hilang. Dan ketika tidak ada yang peduli dan sejarah hilang, bencana tinggal menunggu waktu.

Referensi:

1. ISACA. (2019). COBIT 2019 Framework: Introduction and Methodology

2. ISACA. (2019). COBIT 2019 Framework: Governance and Management Objectives

3. ISO/IEC 27001:2022, Annex A.8 — Asset Management

4. ITIL 4 Foundation: Service Asset and Configuration Management"