Bab 11: 100 Hari Pertama: Memadamkan Api dan Meraih Kemenangan Cepat

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

Intisari Eksekutif: Tiga Bekal untuk Bertahan

Enam bulan pertama berhasil atau gagal pada tiga keputusan yang justru diambil di minggu-minggu paling awal:

• Enam bulan pertama bukan tentang kesempurnaan; tentang membuktikan bahwa tata kelola TI bisa berjalan di organisasi ini. Satu komite yang aktif dan satu risk register yang diperbarui sudah merupakan lompatan besar.
• Quick win di bulan 1-2 adalah investasi kepercayaan. Direksi yang melihat hasil nyata dalam 60 hari pertama akan memberikan dukungan politik yang tidak bisa diperoleh dari presentasi manapun.
• Checklist adalah pelindung dari creep. Tanpa daftar komitmen yang tertulis, scope perlahan melebar, prioritas bercampur, dan 6 bulan berlalu tanpa pencapaian yang bisa dikomunikasikan.

Navigasi Bab: Apa yang Akan Anda Hadapi?

Insiden: Mulai dari Mana?

Cerita pembuka ini adalah komposit pembelajaran. Setelah membaca hasil maturity assessment dari seluruh anak perusahaan, Kepala Divisi TI holding menyadari bahwa daftar pekerjaan lintas wilayah terlalu panjang: komite di daerah belum efektif, risk register konsolidasi belum ada, kebijakan pusat belum sepenuhnya dianut, dokumentasi tersebar, dan pengukuran kinerja belum berjalan seragam. Pertanyaannya bukan lagi apakah tata kelola TI penting. Pertanyaannya: untuk grup sebesar ini, mulai dari mana?

Situasi seperti ini umum terjadi setelah asesmen pertama. Hasilnya membuka terlalu banyak pekerjaan sekaligus. Jika semua dikerjakan bersamaan, organisasi cepat lelah. Jika tidak ada hasil cepat, dukungan Direksi melemah. Jika terlalu banyak dokumen dibuat tanpa praktik nyata, perubahan terasa seperti birokrasi baru.

Lebih parah lagi, seringkali ada tekanan untuk “segera menunjukkan hasil”. Manajemen ingin melihat perbaikan segera, sementara realitas di lapangan menuntut waktu untuk perubahan yang berkelanjutan.

Pendekatan big bang mencoba melakukan semuanya sekaligus dalam waktu singkat. Pendekatan ini sering gagal karena perubahan membutuhkan: (a) waktu untuk sosialisasi, (b) sumber daya untuk pelaksanaan, (c) kesabaran untuk menghadapi resistensi, dan (d) fleksibilitas untuk belajar serta menyesuaikan.

Bab ini menyajikan pendekatan bertahap yang realistis untuk implementasi tata kelola TI. Fase pertama, yaitu 0-6 bulan, bertujuan membangun fondasi dan mencetak quick wins yang dapat membangun momentum untuk fase selanjutnya.

11.1 Prinsip Implementasi yang Efektif

Sebelum masuk ke detail aktivitas per bulan, penting untuk memahami prinsip-prinsip yang akan menentukan keberhasilan implementasi.

11.1.1 Prinsip Pertama: Phased Approach, Bukan Big Bang

Perubahan besar harus dilakukan secara bertahap. Ada beberapa alasan praktis:

1. Sumber daya terbatas. Organisasi tidak dapat mengerjakan semuanya sekaligus. People yang akan melakukan implementasi juga harus tetap menjalankan operasi sehari-hari.
2. Resistensi berkurang dengan perubahan bertahap. Perubahan drastis sekaligus menimbulkan kecemasan dan resistensi yang lebih besar. Perubahan bertahap memberikan waktu untuk adaptasi.
3. Pelajaran dari fase awal dapat diterapkan di fase selanjutnya. Implementasi IT Governance adalah proses belajar. Tidak ada resep yang sama persis untuk setiap organisasi. Pendekatan bertahap memungkinkan organisasi belajar dan menyesuaikan.

11.1.2 Prinsip Kedua: Kemenangan Cepat (Quick Wins) untuk Membangun Momentum

Memetakan roadmap tata kelola 18 bulan memang ideal secara teori. Namun, mari kita hadapi realitas struktural: jabatan Direksi di perusahaan utilitas air sering kali dibatasi masa jabatan. Bagi BUMD, masa jabatan mungkin 4 hingga 5 tahun, tetapi dinamika politik daerah (seperti pergantian kepala daerah) bisa membuat Anda diganti di tahun kedua. Bagi operator swasta mitra pemerintah, tekanannya berbeda tetapi hasilnya serupa: target kontrak, putaran investasi, atau perubahan pemegang saham dapat mempersingkat horizon keputusan Anda.

Jika roadmap Anda baru membuahkan hasil di bulan ke-18, apa insentif Anda untuk menjalankannya hari ini? Anda berisiko bekerja keras meletakkan fondasi, hanya untuk membiarkan direktur penerus Anda yang memotong pita peresmiannya.

Inilah mengapa prinsip kemenangan cepat (quick wins) perlu diperlakukan serius. Roadmap jangka panjang harus dipecah menjadi siklus-siklus 3 hingga 6 bulan yang menghasilkan bukti politis dan operasional yang bisa ditunjukkan langsung oleh Direksi saat ini.

Contoh kemenangan cepat politis:

• Bulan ke-2: Penurunan angka downtime loket pembayaran air. (Memberikan bukti langsung bahwa layanan pelanggan membaik).
• Bulan ke-4: Peluncuran dashboard pantauan kebocoran pipa atau command center mini. (Memberi bukti konkret yang bisa ditunjukkan ke pemilik mandat, mitra pemerintah, atau publik).

Catatan untuk Manajer TI: Kemenangan Cepat Bukan Berarti Membangun Utang Teknis (Technical Debt) Berhati-hatilah saat mendiktekan kemenangan cepat. Bagi Direksi, kemenangan cepat kadang diterjemahkan sebagai “pokoknya fitur ini harus bisa didemokan ke pemilik mandat minggu depan”. Namun bagi Kepala Bagian TI, memaksa peluncuran fitur prematur tanpa infrastruktur dan keamanan yang matang berarti menumpuk utang teknis. Kode program ditulis asal jalan dan server dikonfigurasi seadanya.

Enam bulan kemudian, aplikasi seperti ini sering menjadi rapuh: layanan lumpuh, data rusak, dan staf TI harus lembur panjang untuk memulihkan sistem. Kemenangan cepat yang sehat adalah fitur kecil yang diselesaikan dengan standar arsitektur yang benar. Jangan menukar disiplin teknis dengan demonstrasi sesaat.

Dengan mendesain tata kelola sebagai serangkaian kemenangan cepat (quick wins) yang terukur (bukan dipaksakan), Anda tidak sekadar memperbaiki infrastruktur TI; Anda sedang membangun kredibilitas eksekutif di mata pemilik mandat dan mitra kerja sama, sembari menjaga kewarasan operasional tim Anda.

11.1.3 Prinsip Ketiga: Top-Down dan Bottom-Up

Implementasi IT Governance memerlukan dukungan dari atas (top-down) dan partisipasi dari bawah (bottom-up).

Dukungan Top-Down berarti: (a) komitmen dari direksi, (b) alokasi sumber daya, (c) otoritas untuk membuat perubahan, (d) contoh dari pemimpin.

Partisipasi Bottom-Up berarti: (a) pelibatan tim operasional dalam perancangan proses, (b) masukan dari pengguna proses, (c) ownership dari pelaksana, (d) umpan balik untuk perbaikan.

Tanpa dukungan top-down, perubahan tidak akan memiliki otoritas. Tanpa partisipasi bottom-up, perubahan tidak akan berkelanjutan.

11.1.4 Prinsip Keempat: Focus, Focus, Focus

Organisasi yang mencoba melakukan terlalu banyak hal biasanya berakhir tidak melakukan apa-apa dengan baik. Lebih baik fokus pada beberapa area penting dan melakukannya dengan baik, daripada mencoba menyelesaikan semuanya setengah hati.

Fase pertama harus fokus pada: (a) fondasi tata kelola seperti steering, policy, dan risiko, (b) area yang memberikan quick wins nyata, dan (c) proses yang paling kritis untuk operasi.

Dalam pengalaman saya, best practice generik jarang cukup. Yang bekerja di PDAM kota besar belum tentu bekerja di PDAM di kota kecil. Saya percaya konteks lokal adalah segalanya dalam tata kelola.

11.2 Kemenangan Cepat (Quick Wins): Bulan 1-2

Bulan pertama dan kedua adalah krusial. Tujuannya bukan untuk mencapai kematangan penuh, tetapi untuk memulai perjalanan dan mencetak quick wins.

11.2.1 IT Steering Committee Formation

IT Steering Committee (ISC) adalah forum pengambilan keputusan TI paling utama. Pembentukan ISC yang efektif adalah quick win penting.

Langkah-langkah:

1. Definisikan Terms of Reference. Terms of Reference (ToR) harus mendefinisikan: (a) tujuan ISC, (b) anggota dan perannya, (c) frekuensi pertemuan, (d) otoritas keputusan, (e) mekanisme pelaporan. Contoh tujuan ISC: “Memastikan investasi TI selaras dengan strategi bisnis, mengambil keputusan strategis terkait TI, dan mengawasi implementasi tata kelola.”

2. Tentukan Komposisi Anggota. ISC harus dipimpin oleh eksekutif senior (biasanya CEO atau Direktur Operasional) dan mencakup: (a) Kepala Divisi TI, (b) perwakilan dari unit bisnis utama, (c) perwakilan dari fungsi keuangan, (d) perwakilan dari fungsi risk/compliance.

3. Jadwalkan Pertemuan Rutin. ISC sebaiknya bertemu setiap bulan dengan agenda yang jelas. Pertemuan harus didokumentasikan dengan notulen dan butir tindak lanjut.

4. Eskalasi ke Direksi. ISC harus melapor ke direksi secara kuartalan untuk memberikan update tentang strategi TI, portofolio proyek, dan isu strategis.

Kemenangan cepat ini:

• Waktu: 2-4 minggu untuk pembentukan
• Hasil: Forum keputusan TI yang terstruktur
• Dampak: Keputusan TI menjadi lebih transparan dan terarah

11.2.2 IT Risk Register Establishment

IT Risk Register adalah daftar risiko TI yang teridentifikasi beserta penilaian dan rencana mitigasinya. Ini adalah pondasi dari Risk Management.

Langkah-langkah:

1. Workshop Identifikasi Risiko. Selenggarakan workshop dengan tim TI untuk mengidentifikasi risiko. Gunakan teknik brainstorming dengan kategori: (a) operasional, (b) keamanan, (c) finansial, (d) kepatuhan, (e) reputasi. Contoh risiko yang biasa muncul: downtime sistem kritis, kebocoran data, vendor dependency, kekurangan skill internal, dan kegagalan proyek.

2. Penilaian Risiko. Untuk setiap risiko, nilai: (a) likelihood (1-5), (b) impact (1-5), (c) risk level (likelihood × impact).

3. Rencana Mitigasi. Untuk risiko dengan risk level tinggi, tentukan: (a) tindakan mitigasi, (b) owner (penanggung jawab), (c) target penyelesaian.

4. Tinjauan Berkala. Risk register harus ditinjau secara berkala (minimal kuartalan) untuk memperbarui penilaian dan status mitigasi.

Kemenangan cepat ini:

• Waktu: 2-3 minggu untuk inisialisasi
• Hasil: Daftar risiko yang teridentifikasi dengan rencana mitigasi
• Dampak: Risiko menjadi lebih terkelola dan termonitor

11.2.3 Document Inventory dan Gap Analysis

Organisasi biasanya sudah memiliki beberapa dokumen TI, tetapi tersebar dan tidak terstruktur. Document inventory adalah langkah pertama untuk pengelolaan dokumen yang lebih baik.

Langkah-langkah:

1. Kumpulkan Semua Dokumen. Kumpulkan semua dokumen TI yang ada: policy, procedure, work instruction, form, contract, project document, dan lainnya.

2. Klasifikasikan Dokumen. Klasifikasikan dokumen ke dalam kategori: (a) Level 1 - Kebijakan, (b) Level 2 - Prosedur, (c) Level 3 - Instruksi Kerja, (d) Level 4 - Form, (e) Level 5 - Record.

3. Identifikasi Gap. Bandingkan dokumen yang ada dengan kebutuhan. Identifikasi dokumen yang belum ada, dokumen yang sudah kedaluwarsa, dan dokumen yang tumpang tindih.

4. Prioritaskan Pengembangan. Berdasarkan gap analysis, prioritaskan dokumen yang paling kritis untuk dikembangkan lebih dulu.

Kemenangan cepat ini:

Hati-hati dengan ’transformasi digital’ yang hanya berisi pembelian software dan pelatihan dua hari. Transformasi sejati mengubah cara keputusan dibuat, dan itu jauh lebih sulit daripada membeli lisensi.

• Waktu: 2-4 minggu
• Hasil: Pemahaman jelas tentang status dokumentasi
• Dampak: Pengembangan dokumen menjadi lebih terarah

11.2.4 Critical System Identification

Tidak semua sistem memiliki tingkat kepentingan yang sama. Mengidentifikasi sistem kritis membantu organisasi fokus sumber daya pada area yang paling penting.

Langkah-langkah:

1. Daftar Semua Sistem. Buat daftar lengkap semua sistem TI: aplikasi, server, network, storage, dan lainnya.

2. Klasifikasi Berdasarkan Kritikalitas. Klasifikasikan sistem ke dalam kategori:

   • Mission Critical: Sistem yang jika down akan menghentikan operasi bisnis secara signifikan
   • Business Critical: Sistem yang jika down akan mengurangi produktivitas tetapi tidak menghentikan operasi
   • Operational: Sistem pendukung operasi
   • Administrative: Sistem administratif

3. Tentukan Standar Ketersediaan. Untuk setiap kategori, tentukan standar ketersediaan yang diharapkan:

   • Mission Critical: 99,9% uptime atau lebih
   • Business Critical: 99% uptime
   • Operational: 95% uptime
   • Administrative: Best effort

4. Prioritaskan Investasi dan Monitoring. Sistem kritis harus mendapat prioritas untuk investasi redundancy, pemantauan intensif, disaster recovery planning, dan preventive maintenance.

Kemenangan cepat ini:

• Waktu: 1-2 minggu
• Hasil: Pemahaman tentang sistem yang paling penting
• Dampak: Fokus sumber daya pada area yang tepat

11.2.5 Timeline Bulan 1-2

Gambar 11.1 Timeline quick wins bulan 1-2

11.3 Foundation: Bulan 3-4

Setelah quick wins, bulan ketiga dan keempat fokus pada pembangunan pondasi yang lebih kuat.

11.3.1 Policy Development: 5 Kebijakan Minimum

Organisasi tidak perlu mengembangkan puluhan policy sekaligus. Mulai dengan 5 policy minimum yang paling kritis.

1. IT Governance Policy

Policy ini menetapkan kerangka tata kelola TI organisasi. Isi utama: struktur tata kelola, peran dan tanggung jawab, mekanisme pengambilan keputusan, dan prinsip utama.

2. Information Security Policy

Policy ini menetapkan prinsip-prinsip keamanan informasi. Isi utama: (a) klasifikasi informasi, (b) access control, (c) penggunaan email dan internet, (d) password management, (e) incident reporting.

3. IT Risk Management Policy

Policy ini menetapkan kerangka manajemen risiko TI. Isi utama: (a) proses identifikasi risiko, (b) metodologi penilaian, (c) pendekatan mitigasi, (d) risk appetite organisasi.

4. IT Project Governance Policy

Policy ini menetapkan kerangka tata kelola untuk proyek TI. Isi utama: proses seleksi proyek, gate review, persyaratan business case, dan post-implementation review.

5. IT Service Management Policy

Policy ini menetapkan standar pelayanan TI. Isi utama: (a) service level agreement, (b) incident management, (c) change management, (d) availability management.

Pengembangan Policy:

Gunakan template standar untuk konsistensi, dapatkan tinjauan dari fungsi terkait seperti hukum dan risiko, dapatkan persetujuan formal dari manajemen, lalu komunikasikan ke seluruh organisasi.

11.3.2 SOP untuk Critical Processes

Selain policy, organisasi membutuhkan Prosedur Operasi Standar (Standard Operating Procedure, SOP) untuk proses yang paling kritis. Prioritas SOP:

1. Incident Management SOP

Prosedur untuk menangani insiden operasional: (a) deteksi dan pelaporan, (b) kategorisasi dan prioritas, (c) eskalasi, (d) resolusi, (e) dokumentasi.

2. Change Management SOP

Prosedur untuk mengelola perubahan: (a) change request, (b) evaluasi risiko, (c) persetujuan, (d) implementasi, (e) rollback jika diperlukan.

3. Backup dan Recovery SOP

Prosedur untuk backup dan pemulihan: (a) jadwal backup, (b) prosedur backup, (c) penyimpanan backup, (d) pengujian pemulihan.

4. Vendor Management SOP

Prosedur untuk mengelola vendor: (a) seleksi vendor, (b) evaluasi performa, (c) contract management, (d) terminasi hubungan.

11.3.3 Tinjauan Struktur Organisasi

Struktur organisasi TI mungkin perlu disesuaikan untuk mendukung tata kelola yang lebih baik.

Pertanyaan Kunci:

Apakah ada peran yang bertanggung jawab untuk tata kelola TI? Apakah ada pemisahan tugas yang baik antara fungsi operasi, pengembangan, dan support? Apakah ada segregation of duties yang memadai untuk mencegah konflik kepentingan? Apakah struktur mendukung strategic alignment?

Peran yang Mungkin Ditambahkan:

IT Governance Manager menjadi koordinator implementasi tata kelola. IT risk manager mengelola risiko TI. IT security manager mengelola keamanan informasi. Service desk manager mengelola pelayanan TI.

Peran ini tidak harus berbentuk full-time atau new hire. Terkadang peran tambahan dapat diberikan kepada staf yang sudah ada dan kompeten.

11.3.4 Training dan Awareness

Tanpa pemahaman yang memadai, policy dan prosedur tidak akan efektif. Training dan awareness adalah kunci.

Jenis Training:

1. Training untuk Manajemen: Fokus pada konsep tata kelola, peran mereka, dan keputusan strategis
2. Training untuk TI Staff: Fokus pada prosedur teknis dan tanggung jawab mereka
3. Training untuk Seluruh Karyawan: Fokus pada keamanan informasi dasar (password, phishing, dll)

Metode Training:

• Workshop interaktif
• Online learning (untuk topik dasar)
• Newsletter atau email blast untuk tips
• Poster atau * signage* di area kerja

11.3.5 Timeline Bulan 3-4

Gambar 11.2 Timeline foundation bulan 3-4

11.4 Early Wins: Bulan 5-6

Bulan kelima dan keenam fokus pada implementasi yang mulai menghasilkan hasil nyata (“early wins”).

11.4.1 Siklus Audit Pertama dan Perbaikan

Audit pertama mungkin menakutkan, tetapi penting untuk mendapatkan perspektif independen tentang keadaan tata kelola saat ini.

Pendekatan:

Gunakan audit internal atau self-assessment untuk siklus pertama. Audit eksternal dapat dipertimbangkan untuk siklus berikutnya setelah pondasi terbentuk.

Fokus Audit:

Audit pertama sebaiknya fokus pada area yang sudah ditangani: struktur tata kelola, risk management, kepatuhan policy, dan ketersediaan sistem kritis.

Proses Perbaikan:

Temuan audit harus ditindaklanjuti dengan proses remediation: (a) owner untuk setiap temuan, (b) rencana perbaikan, (c) target penyelesaian, (d) monitoring progres.

11.4.2 Performance Dashboard Establishment

Performance dashboard adalah alat untuk memvisualisasikan KPI TI. Ini membantu manajemen memahami performa TI secara cepat.

KPI Dasar untuk Dashboard:

• Ketersediaan Sistem (System Availability, per sistem kritis)
• Incident Volume dan Resolution Time
• Status Proyek (Project Status, on-track, at-risk, delayed)
• Budget Utilization
• Open Risk Items

Teknologi:

Mulai dengan alat sederhana seperti Excel atau Power BI. Alat yang lebih canggih seperti GRC suite dapat dipertimbangkan untuk fase selanjutnya.

11.4.3 Tata Kelola Proyek (Project Governance) untuk 5 Proyek Teratas

Alih-alih mencoba menerapkan project governance untuk semua proyek sekaligus, fokus pada 5 proyek teratas terlebih dahulu.

Kriteria Seleksi:

Pilih proyek yang: (a) memiliki dampak signifikan terhadap bisnis, (b) berisiko tinggi, (c) sedang berjalan dan membutuhkan pengawasan.

Implementasi:

Untuk setiap proyek, terapkan: (a) business case (jika belum ada), (b) project board atau steering, (c) gate reviews sesuai fase, (d) progress reporting berkala.

Hasil yang Diharapkan:

Proyek yang lebih terkontrol, keputusan yang lebih transparan, dan pelajaran untuk implementasi ke seluruh portofolio proyek.

11.4.4 Timeline Bulan 5-6

Gambar 11.3 Timeline early wins bulan 5-6

11.5 Studi Kasus: Implementasi di Unit B

Unit B adalah salah satu unit operasional Organisasi X. Berikut adalah perjalanan implementasi IT Governance mereka dalam 6 bulan pertama.

11.5.1 Konteks Awal

Sebelum implementasi, kondisi Unit B:

Tidak ada komite TI formal, tidak ada risk register, dokumentasi terbatas dan tersebar, sistem kritis belum teridentifikasi dengan jelas, dan proyek berjalan tanpa tata kelola yang jelas.

11.5.2 Kemenangan Cepat (Quick Wins) (Bulan 1-2)

Dua bulan pertama difokuskan pada kemenangan cepat: hasil kasatmata yang menjadi bukti awal bahwa tata kelola TI membawa manfaat nyata, sekaligus memunculkan gesekan yang harus segera ditangani.

Pencapaian:

IT Steering Committee terbentuk dengan lima anggota. Workshop risiko mengidentifikasi 23 risiko, 8 di antaranya dikategorikan high. Document inventory menemukan 45 dokumen TI, 30 di antaranya perlu diperbarui. Sebanyak 12 sistem diklasifikasikan sebagai mission critical.

Tantangan:

• Beberapa pemangku kepentingan merasa pertemuan ISC menyita waktu operasional
• Risk register awal dianggap terlalu teknis untuk manajemen non-TI

Solusi:

• ISC pertemuan dipersingkat menjadi maksimal 90 menit dengan agenda yang jelas
• Risk register disederhanakan dan dikategorikan berdasarkan bahasa bisnis

11.5.3 Foundation (Bulan 3-4)

Struktur dan proses organisasi yang perlu disiapkan meliputi:

Pencapaian:

Lima policy utama disusun dan disetujui manajemen. Empat SOP untuk proses kritis dikembangkan. Struktur organisasi TI disesuaikan dengan penambahan peran IT governance manager yang dirangkap oleh staf yang sudah ada. Pelatihan diikuti oleh 85% karyawan.

Tantangan:

• Resistensi terhadap SOP baru yang dianggap “menambah birokrasi”
• Keterbatasan waktu untuk training

Solusi:

• Sosialisasi manfaat SOP (bukan hanya kewajiban)
• Training dilakukan secara bertahap dan online untuk fleksibilitas

11.5.4 Early Wins (Bulan 5-6)

Pencapaian:

Audit internal pertama menemukan 12 temuan, terdiri dari 8 major dan 4 minor. Performance dashboard diluncurkan dengan tujuh KPI utama. Project governance diterapkan untuk tiga proyek prioritas. Enam temuan audit sudah diperbaiki.

Tantangan:

• Beberapa pihak merasa “di-audit” terlalu dini
• Dashboard memerlukan penyesuaian beberapa kali

Solusi:

• Komunikasi bahwa audit adalah untuk perbaikan, bukan penilaian
• Iterasi dashboard berdasarkan feedback pengguna

11.5.5 Hasil Akhir Phase 1

Setelah 6 bulan, Unit B mencapai:

Maturity score meningkat dari 1,8 menjadi 2,6. System availability untuk sistem kritis meningkat dari 97% menjadi 98,5%. Tiga dari lima proyek yang mengikuti tata kelola proyek selesai tepat waktu; sebelumnya hanya 30%. Risk items berkategori high berkurang dari 8 menjadi 4.

Ada satu mitos yang ingin saya bongkar: bahwa tata kelola TI hanya relevan untuk organisasi besar. PDAM kecil justru lebih rentan karena satu insiden bisa menghancurkan seluruh operasi. Pencapaian ini memberikan momentum untuk fase kedua (6-18 bulan).

11.5b Studi Kasus: Ketika Kepala TI Baru Masuk di Tengah Kekacauan

Konteks berikut adalah komposit dari pola yang berulang di banyak organisasi; bukan kejadian spesifik di satu perusahaan.

Situasi Awal

Arif (bukan nama sebenarnya) baru dua minggu menjabat sebagai Kepala TI ketika Direktur Utama memanggilnya: “Saya tidak tahu apa yang dilakukan tim TI. Proyek selalu terlambat. Setiap kali ada insiden, saya baru tahu setelah pelanggan komplain. Apa yang bisa Bapak beri dalam 100 hari?”

Arif mewarisi tim 12 orang, 47 aplikasi (hanya 12 yang terdokumentasi), nol risk register, nol SOP insiden, dan satu vendor dominan yang memegang kunci administrator seluruh sistem billing. Tidak ada yang tahu password utama database pelanggan kecuali vendor itu.

Pendekatan 100 Hari

Arif memilih tiga prioritas, bukan dua belas:

Prioritas 1 (Bulan 1): Kendalikan akses. Ia meminta vendor menyerahkan seluruh kredensial administrator dalam satu amplop tertutup ke Direktur Utama. Vendor menolak pertama kali. Arif membawa klausul kontrak yang menyatakan semua kredensial adalah milik organisasi. Amplop diserahkan minggu ketiga. Ini adalah quick win simbolik yang memperlihatkan siapa yang sesungguhnya memegang kendali.

Prioritas 2 (Bulan 2): Satu SOP insiden. Arif tidak menulis 20 SOP. Ia menulis satu: “Apa yang dilakukan dalam 30 menit pertama setelah sistem billing mati.” SOP itu berisi tiga nama, dua nomor telepon, dan lima langkah. Diujikan dalam tabletop exercise dengan Direktur Utama hadir sebagai pengamat. Gagal pertama kali. Berhasil kedua kali. SOP direvisi.

Prioritas 3 (Bulan 3): Inventaris sistem + risiko. Dengan tim kecil, ia mendaftar semua 47 aplikasi, menandai 12 yang mission-critical, dan mengidentifikasi 15 risiko yang langsung dilaporkan ke Direktur Utama dalam format satu halaman.

Gesekan yang Muncul

Vendor dominan merasa terancam dan mengirim surat keberatan. Manajer keuangan protes karena Arif “terlalu banyak bicara langsung ke Direktur Utama, bukan lewat jalur.” Dua staf TI senior mengundurkan diri karena merasa “cara kerja berubah terlalu cepat.”

Arif tidak mundur. Ia menjawab keberatan vendor dengan data (klausul kontrak). Ia menjawab protes manajer keuangan dengan transparansi (laporan bulanan dikirim ke semua manajer, bukan hanya Direktur Utama). Ia mengisi kekosongan staf dengan merekrut satu orang baru dan melatih dua staf junior.

Hasil 100 Hari

• Seluruh kredensial sistem terdokumentasi dan dikuasai internal
• Satu SOP insiden berfungsi dan sudah diuji
• Risk register dengan 15 risiko teratas dilaporkan ke Direksi
• Satu IT Steering Committee dibentuk dan rapat pertama dijadwalkan
• Vendor dominan mulai menghormati batas kontrak

Yang paling penting: Direktur Utama berhenti bertanya “apa yang dilakukan tim TI.” Ia mulai bertanya “apa risiko terbesar bulan ini?”; perubahan pertanyaan yang mencerminkan perubahan persepsi.

Pelajaran untuk manajer TI: Fokus 100 hari bukan pada apa yang bisa Anda perbaiki, melainkan pada apa yang harus Anda perbaiki agar organisasi percaya bahwa perubahan mungkin. Pilih tiga, selesaikan tiga, laporkan tiga.

11.6 Checklist Implementasi 6 Bulan

Berikut adalah checklist untuk memantau progres implementasi.

Tabel 11.1 Checklist implementasi 6 bulan

11.7 Penutup Bab

Enam bulan pertama bukan waktu untuk membuat organisasi sempurna. Enam bulan pertama adalah waktu untuk membuktikan bahwa tata kelola TI bisa dijalankan: ada forum keputusan, ada daftar risiko, ada dokumen kritis, ada sistem prioritas, dan ada hasil yang bisa dilaporkan ke Direksi.

Untuk perusahaan utilitas air, fase pertama harus cukup sederhana agar dapat dijalankan sambil operasi tetap berjalan. Jangan menunggu struktur ideal. Mulai dari keputusan yang paling sering tersangkut, risiko yang paling jelas, dan dokumen yang paling dibutuhkan saat insiden.

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 fase pertama yang realistis. Perubahan yang terlalu besar akan macet; perubahan yang terlalu kecil tidak terasa. Pilih sedikit pekerjaan, tetapi selesaikan sampai terlihat.

💡 Angka yang mengubah keputusan: 60 hari. Batas waktu untuk menunjukkan quick win pertama ke Direksi. Lebih cepat: Direksi percaya dan memberi dukungan politik. Lebih lambat: proyek tata kelola dianggap “tidak menghasilkan apa-apa.”

Catatan Akhir: Mengikat Makna

Agar seratus hari pertama tidak kehilangan arah, peta ringkasnya bisa dipegang seperti ini:

• Fase pertama 0-6 bulan bertujuan membangun fondasi dan quick wins, bukan mengejar kesempurnaan.
• Bulan 1-2 fokus pada komite pengarah TI, risk register, inventaris dokumen, dan identifikasi sistem kritis.
• Bulan 3-4 fokus pada kebijakan minimum, SOP proses kritis, struktur organisasi, dan pelatihan.
• Bulan 5-6 fokus pada audit pertama, dashboard kinerja, dan tata kelola proyek prioritas.
• Program implementasi harus dipantau dengan checklist agar cakupan tidak melebar tanpa kendali.

Perspektif PDAM Kecil (Tier-3): Ketika Semua Saran Terasa Terlalu Besar

Bab ini; dan sebagian besar buku ini; ditulis dengan asumsi organisasi memiliki setidaknya satu tim TI dengan 3-5 orang. Kenyataannya, banyak PDAM di kabupaten kecil beroperasi dengan realitas yang sangat berbeda: satu orang merangkap TI, helpdesk, dan kadang operator billing; tidak ada anggaran untuk konsultan; dan prioritas harian adalah memastikan tagihan tercetak, bukan membangun risk register.

Jika Anda berada di posisi ini, jangan membaca buku ini sebagai daftar tuntutan. Bacalah sebagai peta bertahap yang dimulai dari apa yang Anda punya; bukan dari apa yang seharusnya Anda punya.

Lima langkah realistis untuk PDAM kecil (total anggaran TI < Rp 200 juta/tahun):

Langkah	Tindakan	Waktu	Biaya	Output
1	Tulis satu halaman “Daftar Sistem Kami.” Sebutkan semua aplikasi yang dipakai (billing, Excel, WA grup), siapa yang bertanggung jawab, dan kapan terakhir diperbarui. Tulis tangan atau ketik; tidak perlu software khusus.	1 minggu	Rp 0	Inventaris sistem pertama
2	Tanya ke 5 orang: “Apa risiko TI yang paling Anda khawatirkan?” Pilih 5 orang dari operasi, keuangan, pelayanan, dan Direksi. Catat jawabannya. Itu adalah risk register versi 0 Anda.	2 minggu	Rp 0	5 risiko teratas dengan pemilik
3	Buat satu SOP: “Apa yang dilakukan jika billing mati.” Satu halaman. Lima langkah. Tiga nomor telepon. Tempel di dinding ruang server; atau di pintu toilet kalau tidak ada ruang server.	1 minggu	Rp 0	SOP pertama
4	Kirim email ke Kepala Bagian: “Berikut 5 risiko TI teratas yang saya identifikasi. Mohon arahan apakah ini bisa dibahas di rapat staf berikutnya.” Simpan balasannya. Itu adalah audit trail pertama Anda.	1 hari	Rp 0	Jejak keputusan pertama
5	Baca satu bab buku ini per bulan; bab yang paling relevan dengan masalah yang sedang Anda hadapi. Jangan membaca semua sekaligus.	12 bulan	Rp 0	Pemahaman bertahap

Satu hal yang tidak boleh ditunda; apapun keterbatasannya: Dokumentasikan keputusan. Sekecil apapun. Satu paragraf di buku catatan yang menyatakan “Tanggal X, rapat dengan Kabag Y, diputuskan Z” sudah cukup. Ketika auditor datang, buku catatan itu adalah benteng Anda. Ketika Bupati baru mengganti Direksi, buku catatan itu adalah bukti bahwa program sudah berjalan sebelum pimpinan baru tiba. Ketika vendor menyalahkan Anda, buku catatan itu adalah rekaman instruksi.

Anda tidak sendirian. Ribuan PDAM kecil di Indonesia menghadapi realitas yang sama. Yang membedakan bukan anggarannya; melainkan apakah ada satu orang yang memutuskan untuk mulai mendokumentasikan.

Uji Nyali Eksekutif: Lima Pertanyaan yang Harus Bisa Anda Jawab

1. Satu quick win apa yang dapat ditunjukkan dalam 60 hari pertama?
2. Apakah komite pengarah TI sudah punya mandat, anggota, agenda, dan notulen keputusan?
3. Risiko TI apa yang paling tinggi dan siapa pemilik mitigasinya?
4. Dokumen kritis apa yang harus ada sebelum audit atau insiden berikutnya?
5. Hambatan organisasi apa yang bisa menghentikan fase pertama jika tidak diselesaikan sejak bulan pertama?

Aksi Instan: Tiga Gebrakan untuk Minggu Ini

1. Buka checklist implementasi 6 bulan dari bab ini; tandai semua yang sudah ada.
2. Fokus bulan 1-2 pada pembentukan IT Steering Committee dengan mandat tertulis dan jadwal rapat bulanan.
3. Siapkan satu quick win untuk Direksi: risk register pertama, prosedur insiden, atau daftar sistem kritis.

Checklist Rapat Fase 1

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

• Komite pengarah TI terbentuk
• Risk register awal tersedia
• Inventaris dokumen selesai
• Sistem kritis teridentifikasi
• Lima kebijakan minimum disusun
• Audit internal pertama dijadwalkan

🛠️ Besok pagi, coba ini: Ambil kalender. Blok 2 jam minggu depan, bukan untuk rapat, tapi untuk menulis satu halaman: apa satu hal yang akan berbeda setelah 90 hari pertama? Kalau tidak bisa ditulis dalam satu halaman, scop-nya terlalu besar.

Untuk Disampaikan ke Direksi

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

1. 100 hari pertama: padamkan api dulu, baru bangun fondasi. Fokus pada quick wins yang terlihat: satu insiden berhasil dieskalasi dengan benar, satu risk register mulai dipakai rapat, satu SOP perubahan diuji. Momentum 100 hari menentukan kepercayaan untuk fase berikutnya.
2. Pilih 3 inisiatif, bukan 10. Kegagalan fase pertama hampir selalu karena terlalu banyak inisiatif paralel. Tiga yang selesai lebih berharga daripada sepuluh yang setengah jadi.
3. Laporkan progres ke Direksi setiap 30 hari, bukan setiap triwulan. Fase pertama butuh ritme cepat untuk membangun kepercayaan. Format laporan: satu halaman, tiga metrik, satu isu yang butuh keputusan.

Template rencana 100 hari tersedia di tools.itgbook.com.

Amunisi Rapat: Satu Pertanyaan Penguji Pimpinan

Apa satu hambatan organisasi yang, jika tidak diatasi sebelum bulan pertama berakhir, akan membuat seluruh program implementasi ini terhenti?

Jawaban atas pertanyaan ini menentukan apakah fase pertama realistis atau hanya daftar kerja yang terlihat rapi di atas kertas.

Menuju Bab 12: Pelembagaan dan Perluasan

Setelah fondasi enam bulan pertama berjalan, organisasi perlu memperluas cakupan dan melembagakan kebiasaan baru. Bab 12 membahas fase kedua: pelembagaan, perluasan ke unit lain, dan penguatan tata kelola lintas fungsi.

Referensi & Eksplorasi Lanjutan

1. COBIT 2019 Implementation Guide

   • ISACA (2019). Panduan implementasi COBIT secara praktis.
   • 🔗 Akses COBIT 2019 Implementation Guide

2. IT Governance Implementation Roadmap

   • Van Grembergen, W. (2005). “Strategies for Information Technology Governance.”
   • Studi tentang pendekatan bertahap implementasi IT Governance.

3. Making IT Governance Real

   • IT Governance Institute (2008). Panduan praktis implementasi.
   • 🔗 Akses ITGI

4. Kotter - Leading Change

   • Kotter, J.P. (1996, ed. Revisi). Buku referensi 8-step process untuk transformasi organisasi.
   • 🔗 Akses

5. ITIL 4 Foundation Reference

   • AXELOS (2019). Service Value System dan service management practices.
   • 🔗 Akses

6. Pedoman Manajemen SPBE

   • Kementerian PANRB (berkala). Pedoman implementasi manajemen SPBE untuk instansi.
   • 🔗 Akses

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. Bukan merupakan pandangan institusional atau komitmen formal dari organisasi mana pun. Hook pembuka adalah komposit pembelajaran, bukan rekonstruksi satu organisasi tertentu.