Bab 9: Maturity Assessment IT Governance

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

Tiga Hal yang Wajib Dibawa Pulang

• Kematangan yang tidak diukur tidak bisa ditingkatkan. Assessment bukan formalitas tahunan; ia kompas yang menunjukkan di mana organisasi berdiri hari ini dan ke arah mana harus bergerak.
• Perbedaan persepsi antara pimpinan dan tim teknis adalah temuan terpenting. Jika Direksi menilai kematangan di level 3 tapi tim TI menilai level 1, itu bukan masalah skala; itu masalah informasi yang tidak mengalir.
• Pilih 2 domain fokus, bukan semua domain sekaligus. Mencoba memperbaiki semua area dalam satu periode kerap berakhir dengan tidak ada yang benar-benar membaik.

Peta Konsep Bab Ini

Insiden: Kita Sudah Implementasi Tata Kelola TI, Kan?

Cerita pembuka ini adalah komposit pembelajaran. Dalam sebuah rapat Direksi, Kepala Divisi TI menyampaikan bahwa organisasi sudah mengimplementasikan tata kelola TI: sudah ada komite, sudah ada prosedur, dan sudah ada rapat rutin dengan unit bisnis.

Direktur Utama mengangguk, tetapi pertanyaannya belum terjawab: bagaimana organisasi tahu bahwa tata kelola itu sudah cukup baik? Apakah ada standar? Apakah kondisi saat ini dapat dibandingkan dengan target? Apakah Direksi dan tim teknis akan memberi jawaban yang sama jika diminta menilai kematangan organisasi?

Pertanyaan ini penting karena banyak organisasi “sudah melakukan sesuatu” tanpa tahu apakah sesuatu itu cukup. Ada aktivitas, tetapi belum ada ukuran. Ada komite, tetapi belum jelas apakah ia efektif. Ada prosedur, tetapi belum jelas apakah dipakai. Ada proyek, tetapi belum jelas apakah manfaatnya diukur.

Tanpa pemahaman tentang kondisi saat ini (current state) dan kondisi target (target state), perbaikan menjadi seperti menembak dalam gelap. Organisasi mungkin mengalokasikan sumber daya ke area yang salah, mengabaikan area yang paling kritis, atau merasa sudah matang hanya karena sudah punya dokumen.

Bab ini membahas cara mengukur tingkat kematangan tata kelola TI dan menggunakan hasilnya untuk merencanakan perbaikan yang terarah: model kematangan, domain yang dinilai, metode asesmen, skoring, analisis kesenjangan, dan prioritas perbaikan. Setelah Bab 8 membahas proyek dan investasi, Bab 9 membantu organisasi memahami kesiapan tata kelolanya sebelum masuk ke implementasi.

9.1 Mengapa Maturity Assessment Penting

Sebelum masuk ke detail, penting untuk memahami mengapa maturity assessment adalah aktivitas kritis dalam implementasi IT Governance.

9.1.1 Dari “Sudah Belum” ke “Sudah Sejauh Mana”

Pertanyaan “Apakah kita sudah implementasi IT Governance?” adalah pertanyaan yang salah. IT Governance bukan biner (ya/tidak), tetapi sebuah spektrum kematangan.

Organisasi yang memiliki beberapa kebijakan TI dan steering committee yang jarang bertemu berada di tingkat kematangan yang berbeda dengan organisasi yang memiliki framework lengkap, proses terdokumentasi, metrics yang terukur, dan budaya continuous improvement.

Keduanya “sudah implementasi IT Governance”, tetapi berada di titik yang sangat berbeda dalam spektrum kematangan. Dan implikasinya besar untuk perencanaan perbaikan.

9.1.2 Tiga Manfaat Utama Maturity Assessment

1. Baseline yang Terukur. Assessment memberikan baseline atau titik awal yang terukur. Tanpa baseline, kita tidak dapat mengukur kemajuan. Kita tidak dapat menjawab pertanyaan “Apakah kita lebih baik tahun ini dibanding tahun lalu?” jika kita tidak tahu di mana kita berada tahun lalu. Di Organisasi X, maturity assessment pertama tahun 2021 menunjukkan tingkat kematangan rata-rata 2,1 (skala 1-5). Tiga tahun kemudian, assessment berikutnya menunjukkan peningkatan menjadi 3,4. Ini adalah bukti konkret kemajuan yang dapat dikomunikasikan ke direksi dan stakeholder.

2. Gap Analysis yang Spesifik. Assessment mengidentifikasi area di mana current state berada jauh di bawah target state. Ini membantu organisasi memprioritaskan area perbaikan. Di Organisasi X, assessment menunjukkan bahwa domain Risk Management berada di level 1,5, sedangkan domain Performance Measurement sudah di level 3,2. Ini memberikan sinyal yang jelas: Risk Management harus menjadi prioritas perbaikan.

3. Roadmap yang Realistis. Dengan pemahaman tentang current state dan gap yang spesifik, organisasi dapat menyusun roadmap perbaikan yang realistis. Bukan lagi sekadar daftar harapan, tetapi rencana yang berdasarkan analisis yang konkret.

9.1.3 Risiko Tanpa Maturity Assessment

Organisasi yang melakukan perbaikan tanpa maturity assessment menghadapi beberapa risiko:

1. Alokasi sumber daya ke area yang salah. Tanpa pemahaman tentang area yang paling kritis, organisasi mungkin menargetkan perbaikan di area yang sudah cukup baik sambil mengabaikan area yang benar-benar membutuhkan perbaikan.
2. Ekspektasi yang tidak realistis. Manajemen mungkin berharap perbaikan dapat dicapai dalam waktu singkat, padahal current state yang jauh dari target memerlukan waktu lebih lama.
3. Tidak dapat mengukur kemajuan. Tanpa baseline, organisasi tidak dapat menunjukkan bukti konkret kemajuan yang telah dicapai.

Catatan: Jangan pernah percaya klaim bahwa perangkat lunak saja dapat menyelesaikan masalah tata kelola. Tata kelola adalah tentang keputusan dan akuntabilitas; perangkat lunak hanya membantu jika keputusan dan akuntabilitasnya sudah jelas.

9.2 Model Kematangan IT Governance

Berbagai framework memiliki maturity model masing-masing. COBIT 2019, ISO/IEC 15504 (SPICE), dan CMMI semuanya memiliki konsep kematangan yang serupa. Bagian ini akan menyajikan maturity model yang praktis dan mudah diterapkan.

9.2.1 Tingkat Kematangan: Level 1 - Initial/Ad-hoc

Organisasi pada level ini memiliki karakteristik utama: proses tidak terstruktur, bergantung pada individu, dan tidak dapat diprediksi.

Ciri-ciri Level 1:

• Tidak ada proses formal yang terdokumentasi
• Aktivitas dilakukan secara ad-hoc berdasarkan kebutuhan mendesak
• Keberhasilan sangat bergantung pada kompetensi dan kemauan individu
• Tidak ada consistency dalam cara aktivitas dilakukan
• Tidak ada tracking terhadap performa
• Ketika terjadi masalah, reaksi adalah firefighting bukan pencegahan

Implikasi Praktis:

Organisasi pada level ini sangat rentan. Jika key person pergi, pengetahuan pergi bersamanya. Jika terjadi krisis, respon akan sporadis dan tidak terkoordinasi.

Contoh Nyata:

Dalam contoh Unit C sebelum perbaikan, jika server kritis mati, respons bergantung pada siapa yang pertama kali mengetahui. Jika orang yang tepat sedang tidak ada, masalah mungkin tidak segera tertangani. Tidak ada escalation procedure yang jelas, tidak ada SLA yang terdokumentasi, dan tidak ada incident log yang sistematis.

9.2.2 Tingkat Kematangan: Level 2 - Repeatable

Organisasi pada level ini telah mulai mengembangkan proses, tetapi belum konsisten.

Ciri-ciri Level 2:

• Proses mulai terdokumentasi, tetapi belum komprehensif
• Ada prosedur untuk situasi yang sering terjadi, tetapi belum mencakup semua situasi
• Konsistensi masih terbatas; proses diikuti secara sporadis
• Ada tracking terhadap beberapa aktivitas, tetapi belum sistematis
• Individu masih berperan besar, tetapi standar mulai terbentuk
• Accountability mulai jelas, tetapi belum sepenuhnya ditegakkan

Implikasi Praktis:

Organisasi pada level ini lebih baik daripada level 1, tetapi masih rentan. Proses ada di atas kertas, tetapi implementasi di lapangan masih tidak konsisten.

Contoh Nyata:

Di Unit B, ada prosedur backup data yang terdokumentasi. Namun, ketika audit dilakukan, ditemukan bahwa tidak semua tim mengikuti prosedur tersebut. Beberapa orang masih melakukan backup secara manual, ada yang lupa menjadwalkan backup, dan ada yang jarang mengecek apakah backup berhasil.

9.2.3 Tingkat Kematangan: Level 3 - Defined

Organisasi pada level ini telah memiliki proses yang terdokumentasi dan distandardisasi secara menyeluruh.

Ciri-ciri Level 3:

• Proses komprehensif terdokumentasi dalam policy, procedure, dan work instruction
• Standar didefinisikan dan dikomunikasikan ke seluruh organisasi
• Proses diikuti secara konsisten, kecuali ada alasan yang didokumentasikan
• Ada ownership yang jelas untuk setiap proses
• Pelatihan tersedia untuk memastikan semua pihak memahami proses
• Ada tinjauan periodik untuk memastikan proses tetap relevan

Implikasi Praktis:

Organisasi pada level ini telah mencapai tingkat kematangan yang baik. Proses dapat diprediksi, dan hasil dapat diandalkan. Jika key person pergi, pengetahuan tetap ada dalam organisasi.

Contoh Nyata:

Di Unit A (setelah perbaikan), semua insiden TI ditangani berdasarkan Incident Management Procedure yang jelas. Setiap insiden dicatat dalam sistem, dikategorikan, dialokasikan ke tim yang tepat, dan ditutup dengan dokumentasi lengkap. Escalation otomatis terjadi jika insiden tidak terselesaikan dalam waktu yang ditentukan.

9.2.4 Tingkat Kematangan: Level 4 - Managed (Quantitatively Managed)

Organisasi pada level ini tidak hanya memiliki proses yang terdokumentasi, tetapi juga mengukur performa proses tersebut secara kuantitatif.

Ciri-ciri Level 4:

• Proses diukur dengan metrics yang jelas
• Data kinerja dikumpulkan secara sistematis
• Ada target kinerja yang terdefinisi untuk setiap proses
• Analisis kinerja dilakukan secara rutin
• Keputusan berdasarkan data, bukan sekadar persepsi
• Corrective action dilakukan ketika kinerja di bawah target

Implikasi Praktis:

Organisasi pada level ini memiliki kemampuan untuk mengoptimalkan performa secara objektif. Mereka tahu persis seberapa baik proses mereka berjalan dan di area mana perlu ditingkatkan.

Contoh Nyata:

Di Organisasi X (setelah transformasi), availability sistem diukur secara real-time dengan dashboard yang menunjukkan uptime per sistem. Jika availability sistem critical turun di bawah 99,5%, alert otomatis dikirim ke manajemen untuk tindakan. Data ini juga dianalisis bulanan untuk mengidentifikasi pola dan area perbaikan.

9.2.5 Tingkat Kematangan: Level 5 - Optimizing

Organisasi pada level ini tidak hanya mengukur dan mengontrol, tetapi secara aktif melakukan continuous improvement.

Ciri-ciri Level 5:

• Budaya continuous improvement tertanam di seluruh organisasi
• Proses diperbaiki secara berkelanjutan berdasarkan data dan inovasi
• Organisasi proaktif mengidentifikasi peluang perbaikan
• Best practices dari eksternal ditangkap dan diadaptasi
• Inovasi diuji dan diimplementasikan secara sistematis
• Organisasi dapat menjadi benchmark bagi organisasi lain

Implikasi Praktis:

Organisasi pada level ini adalah kelas dunia. Mereka tidak hanya mengikuti standar, tetapi menciptakan standar baru.

Contoh Nyata:

Sangat sedikit organisasi utilitas di Indonesia yang mencapai level ini. Contoh global mungkin adalah perusahaan teknologi besar seperti Google atau Amazon yang terus mengembangkan praktik IT Governance inovatif yang kemudian diadopsi organisasi lain.

9.2.6 Tabel Ringkasan Maturity Model

Tabel 9.1 merangkum lima tingkat kematangan tata kelola TI.

Tabel 9.1 Ringkasan maturity model tata kelola TI

9.2.7 Target Level yang Realistis

Pertanyaan penting: level mana yang harus menjadi target?

Jawabannya tergantung pada konteks organisasi. Untuk organisasi utilitas di Indonesia dengan keterbatasan sumber daya, level 3-4 adalah target yang realistis untuk jangka menengah (3-5 tahun). Level 5 adalah aspirasi jangka panjang, tetapi mungkin tidak realistis untuk dicapai dalam waktu dekat.

Penting untuk diingat bahwa ini bukan kompetisi untuk mencapai level tertinggi, tetapi tentang mencapai level yang sesuai dengan kebutuhan dan kapasitas organisasi.

Berdasarkan pengamatan, skor rendah yang jujur lebih berguna daripada skor tinggi yang dibuat agar terlihat matang di rapat. Asesmen yang baik bukan alat gengsi; ia alat navigasi.

9.3 Assessment Toolkit

Bagian ini akan menyajikan toolkit praktis untuk melakukan maturity assessment di organisasi.

9.3.1 Domain yang Diases

Assessment harus mencakup domain-domain kunci dalam IT Governance. Berdasarkan COBIT 2019, ada enam domain utama:

1. EDM (Evaluate, Direct, Monitor): Governance keseluruhan
2. APO (Align, Plan, Organise): Perencanaan dan organisasi
3. BAI (Build, Acquire, Implement): Pembangunan dan implementasi
4. DSS (Deliver, Service, Support): Operasi dan support
5. MEA (Monitor, Evaluate, Assess): Pemantauan dan evaluasi
6. Security: Keamanan informasi

Untuk organisasi utilitas, domain-domain ini dapat dipetakan ke area yang lebih praktis sebagaimana ditunjukkan dalam Tabel 9.2.

Tabel 9.2 Pemetaan domain COBIT ke area praktis

9.3.2 Metode Assessment

Ada beberapa metode untuk melakukan assessment:

Metode 1: Self-Assessment

Organisasi menilai dirinya sendiri dengan menggunakan kuesioner. Ini adalah metode termudah dan termurah, tetapi memiliki bias subjektif.

Metode 2: Internal Assessment

Tim internal (misalnya dari fungsi audit atau PMO) melakukan penilaian. Lebih objektif daripada self-assessment, tetapi mungkin kurang independen.

Metode 3: External Assessment

Konsultan eksternal melakukan penilaian. Paling objektif, tetapi paling mahal.

Untuk organisasi utilitas dengan keterbatasan anggaran, kombinasi Metode 1 dan Metode 2 seringkali cukup. Self-assessment dapat dilakukan secara rutin, sementara external assessment dapat dilakukan setiap 2-3 tahun untuk validasi.

9.3.3 Assessment Questionnaire (Sample)

Berikut adalah contoh kuesioner untuk menilai tingkat kematangan. Untuk setiap pertanyaan, pilih jawaban yang paling menggambarkan kondisi organisasi saat ini.

Domain: Governance & Strategy

1. Apakah organisasi memiliki komite atau forum formal untuk pengambilan keputusan TI?

   • Tidak ada komite formal
   • Ada komite, tetapi jarang bertemu
   • Ada komite yang rutin bertemu dengan agenda yang jelas
   • Ada komite dengan terms of reference formal dan minutes yang didokumentasi
   • Komite memiliki performance metrics dan melakukan review periodik

2. Apakah organisasi memiliki strategi TI yang tertulis?

   • Tidak ada strategi TI tertulis
   • Ada strategi, tetapi tidak sejalan dengan strategi bisnis
   • Ada strategi TI yang selaras dengan strategi bisnis
   • Strategi ditinjau dan diperbarui secara periodik
   • Strategi dikomunikasikan dan dipahami di seluruh organisasi

Domain: Risk Management

3. Apakah organisasi memiliki risk register untuk risiko TI?

   • Tidak ada risk register
   • Ada risk register, tetapi tidak diperbarui
   • Ada risk register yang diperbarui secara periodik
   • Risk register terintegrasi dengan enterprise risk management
   • Ada proses formal risk treatment dan monitoring

4. Bagaimana organisasi menangani insiden keamanan informasi?

   • Tidak ada proses formal
   • Ada proses, tetapi tidak diikuti secara konsisten
   • Ada proses formal yang terdokumentasi dan diikuti
   • Insiden dicatat dan dianalisis untuk lesson learned
   • Ada continuous improvement berdasarkan analisis insiden

Domain: Performance Measurement

5. Apakah organisasi mengukur performa TI?
   • Tidak ada pengukuran formal
   • Ada beberapa metrics, tetapi tidak konsisten
   • Ada KPI yang terdokumentasi dan dilaporkan secara periodik
   • KPI disajikan dalam dashboard yang mudah diakses
   • Ada action berdasarkan analisis KPI

Domain: Project & Investment Governance

6. Bagaimana organisasi mengelola portofolio proyek TI?

   • Proyek dipilih secara ad-hoc
   • Ada daftar proyek, tetapi tidak ada seleksi formal
   • Ada proses seleksi berdasarkan business case
   • Ada portfolio management dengan prioritization formal
   • Ada review periodik dan re-prioritization portofolio

7. Apakah organisasi melakukan post-implementation review?

   • Tidak pernah
   • Kadang-kadang
   • Rutin untuk proyek besar
   • Rutin untuk semua proyek dengan lesson learned tertulis
   • Lesson learned ditangkap dan digunakan untuk perbaikan proses

Domain: Operations & Service Management

8. Bagaimana organisasi menangani insiden operasional?
   • Tidak ada proses formal
   • Ada proses, tetapi tidak terdokumentasi
   • Ada prosedur terdokumentasi
   • Ada ticketing system dan SLA yang terukur
   • Ada continuous improvement berdasarkan analitik insiden

Domain: Documentation & Standards

9. Bagaimana kondisi dokumentasi proses TI?

   • Tidak ada dokumentasi formal
   • Dokumentasi ada, tetapi tidak lengkap
   • Dokumentasi lengkap, tetapi tidak diakses mudah
   • Dokumentasi lengkap dan mudah diakses
   • Dokumentasi diperbarui secara periodik dan digunakan untuk training

10. Apakah organisasi memiliki policy TI?

    • Tidak ada policy tertulis
    • Ada beberapa policy, tetapi tidak komprehensif
    • Ada policy untuk area utama
    • Policy lengkap dan dikomunikasikan
    • Policy ditinjau dan diperbarui secara periodik

9.3.4 Scoring Guide

Untuk setiap pertanyaan, skor diberikan sebagai berikut:

• Pilihan pertama = 1 poin (Level 1)
• Pilihan kedua = 2 poin (Level 2)
• Pilihan ketiga = 3 poin (Level 3)
• Pilihan keempat = 4 poin (Level 4)
• Pilihan kelima = 5 poin (Level 5)

Perhitungan Skor:

1. Hitung rata-rata skor per domain
2. Hitung rata-rata skor keseluruhan

Interpretasi Skor:

• 1,0 - 1,4: Level 1 (Initial) - perlu perbaikan mendesak
• 1,5 - 2,4: Level 2 (Repeatable) - perlu standardisasi
• 2,5 - 3,4: Level 3 (Defined) - perlu pengukuran dan pengendalian
• 3,5 - 4,4: Level 4 (Managed) - fokus pada optimasi
• 4,5 - 5,0: Level 5 (Optimizing) - pertahankan dan inovasi

9.3.5 Gap Analysis dan Prioritasi

Setelah skor diperoleh, lakukan gap analysis:

1. Identifikasi domain dengan skor terendah
2. Identifikasi domain dengan gap terbesar terhadap target
3. Pertimbangkan faktor: (a) risiko, (b) strategic importance, (c) ketersediaan sumber daya

Prioritaskan perbaikan berdasarkan kombinasi skor rendah dan strategic importance.

9.3.6 Studi Kasus: Assessment di Organisasi X

Organisasi X melakukan maturity assessment pertama pada tahun 2021. Berikut adalah hasil ringkas:

Tabel 9.3 Hasil awal maturity assessment Organisasi X

Analisis:

Skor terendah adalah MEA (Monitoring) dengan 1,2 - ini menjadi prioritas utama. BAI (Projects) juga skor rendah (1,5) - prioritas kedua. DSS (Operations) sudah relatif baik (2,8) - dapat menjadi quick win untuk mencapai level 3.

Aksi:

Berdasarkan hasil ini, Organisasi X menyusun roadmap 18 bulan dengan fokus pada:

1. Bulan 1-6: Implementasi monitoring framework (MEA)
2. Bulan 4-9: Implementasi project governance (BAI)
3. Bulan 7-12: Penguatan struktur tata kelola (EDM)
4. Bulan 10-18: Peningkatan area lain ke level 3

Tiga tahun kemudian, assessment berikutnya menunjukkan peningkatan signifikan:

Tabel 9.4 Perbandingan skor kematangan Organisasi X

KPI yang hanya mengukur aktivitas, bukan hasil, adalah kelemahan yang sering muncul dalam manajemen TI. Metrik seperti ‘100% server termonitor’ perlu dibaca bersama pengalaman pengguna jasa; jika layanan masih lambat, indikator teknis belum cukup menjawab kebutuhan bisnis. Pencapaian ini didukung oleh komitmen manajemen, alokasi sumber daya yang memadai, dan pendekatan bertahap yang terarah.

9.4 Penutup Bab

Kematangan tata kelola TI tidak naik karena organisasi menyatakan diri “sudah punya tata kelola”. Kematangan naik ketika proses dapat diukur, pemiliknya jelas, bukti tersedia, dan perbaikan dilakukan berdasarkan prioritas risiko.

Untuk perusahaan utilitas air, maturity assessment membantu Direksi melihat jarak antara persepsi dan realitas. Tim teknis mungkin merasa sudah bekerja keras, tetapi Direksi membutuhkan ukuran yang dapat dipakai untuk menentukan prioritas, alokasi anggaran, dan target peningkatan.

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 cara sederhana untuk mengetahui posisi awal sebelum menyusun program perbaikan. Asesmen yang jujur lebih berguna daripada skor tinggi yang tidak mencerminkan realitas.

Ringkasan Bab

• Tata kelola TI adalah spektrum kematangan, bukan status sudah atau belum.
• Maturity assessment memberi baseline, analisis kesenjangan, dan dasar roadmap perbaikan.
• Level 3 sering menjadi target realistis awal untuk organisasi yang ingin membuat proses stabil dan terdokumentasi.
• Perbedaan skor antara Direksi, TI, dan unit bisnis adalah temuan penting yang perlu dibahas.
• Fokus perbaikan harus dibatasi pada beberapa domain prioritas agar hasilnya nyata.

Lima Pertanyaan Refleksi untuk Direksi

1. Apakah Direksi, tim TI, dan unit bisnis akan memberi skor kematangan yang sama untuk tata kelola TI saat ini?
2. Domain mana yang paling rendah skornya dan paling tinggi dampak risikonya?
3. Apakah organisasi memiliki baseline bertanggal yang dapat dibandingkan tahun depan?
4. Apakah target kematangan realistis dengan sumber daya yang tersedia?
5. Apakah hasil asesmen benar-benar masuk ke rencana kerja dan anggaran?

Tiga Langkah yang Bisa Dimulai Minggu Ini

1. Lakukan self-assessment dengan 5-10 pertanyaan kematangan; jawab jujur dan catat hasilnya sebagai baseline bertanggal.
2. Pilih dua domain dengan nilai terendah; jadikan keduanya fokus eksplisit untuk enam bulan ke depan.
3. Dokumentasikan tanggal asesmen, skor per domain, nama penilai, dan tiga kesenjangan terbesar.

Checklist Rapat Maturity Assessment

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

• Domain asesmen disepakati
• Skor diberikan dengan bukti, bukan perasaan
• Direksi, TI, dan unit bisnis ikut memberi perspektif
• Dua domain prioritas dipilih
• Target enam bulan ditulis dalam angka
• Jadwal asesmen ulang sudah ditetapkan

Satu Pertanyaan untuk Dibawa ke Rapat Direksi Berikutnya

Apakah pimpinan dan tim TI akan memberikan jawaban yang sama jika ditanya tingkat kematangan tata kelola saat ini?

Jika jawabannya tidak, perbedaan itu bukan kegagalan. Itu data awal yang justru membuat asesmen berguna.

Menuju Bab 10: Implementasi Fase Pertama

Setelah mengetahui posisi awal, organisasi perlu mulai bergerak. Bab 10 membahas implementasi fase pertama dengan langkah konkret bulan per bulan.

Referensi & Bacaan Lanjutan

1. COBIT 2019 Design Guide

   • ISACA (2019). Panduan desain tata kelola termasuk maturity model.
   • 🔗 Akses COBIT 2019 Design Guide

2. IT Governance Maturity Model

   • Van Grembergen, W., & De Haes, S. (2009). “Enterprise Governance of IT: Achieving Strategic Alignment and Value.”
   • Studi tentang maturity model untuk IT Governance.

3. Process Assessment Framework ISO/IEC 15504

   • ISO/IEC (2004). Standar internasional untuk process assessment.
   • 🔗 Akses ISO/IEC 15504

4. CMMI Maturity Model V2.0

   • ISACA / CMMI Institute (berkala). Capability Maturity Model Integration untuk proses organisasi.
   • 🔗 Akses

5. COBIT Performance Management Guide

   • ISACA (2019). Pedoman pengukuran kinerja proses tata kelola dan manajemen TI.
   • 🔗 Akses

6. ISO/IEC 33000 series - Process Assessment

   • ISO (berkala). Kerangka penilaian kematangan proses berbasis ISO 15504 (SPICE).
   • 🔗 Akses

7. Pedoman Evaluasi Indeks SPBE

   • Kementerian PANRB (berkala). Instrumen evaluasi resmi indeks SPBE untuk instansi pemerintah dan BUMD.
   • 🔗 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.