Bab 6: Dokumentasi & Standar

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

Tiga Hal yang Wajib Dibawa Pulang

• Dokumen yang tidak dipakai bukan dokumen; ia arsip. Sistem dokumentasi yang efektif dimulai bukan dari kelengkapan, melainkan dari relevansi: dokumen yang benar-benar dicari saat insiden terjadi.
• Tiga dokumen kritis lebih berharga dari tiga puluh dokumen tidak terawat. Mulai dari jumlah yang bisa dijaga kualitasnya; baru berkembang setelah disiplin perawatannya terbentuk.
• Pemilik dokumen (document owner) adalah nyawa sistem dokumentasi. Tanpa orang yang bertanggung jawab memperbarui, setiap dokumen akan kedaluwarsa dan menjadi sumber salah informasi yang berbahaya.

Peta Konsep Bab Ini

Insiden: Prosedur Itu Ada, Tapi Di Mana?

Cerita pembuka ini adalah komposit pembelajaran. Situasinya sederhana: sistem billing mengalami gangguan pada Jumat sore, tim TI harus merespons cepat, tetapi dokumen yang dibutuhkan tidak dapat ditemukan. Prosedur incident response tidak jelas lokasinya. Dokumentasi konfigurasi sistem tersebar. Contact list vendor tidak diketahui versi terbarunya.

Pencarian pun dimulai. Satu orang ingat bahwa prosedur ada di shared drive yang jarang diakses. Orang lain yakin dokumentasi tersimpan di laptop mantan karyawan. Tim operasi mengira vendor pernah menyerahkan dokumen konfigurasi, tetapi tidak ada yang tahu lokasi terakhirnya. Semua orang merasa dokumennya “sangat mungkin ada”, tetapi tidak ada yang bisa mengaksesnya saat dibutuhkan.

Tiga jam berlalu sebelum tim mengumpulkan informasi yang diperlukan untuk mulai merespons insiden. Tiga jam itu mahal. Pelanggan tidak dapat melakukan pembayaran, call center dibanjiri keluhan, dan pimpinan meminta estimasi pemulihan yang tidak dapat dijawab karena data dasar belum tersedia.

Masalahnya bukan kurangnya dokumen. Masalahnya adalah dokumen tidak hidup sebagai sistem kerja. Empat gejalanya mudah dikenali:

• dokumentasi tersebar di banyak lokasi
• tidak ada sistem untuk menemukan dokumen dengan cepat
• tidak ada ownership yang jelas atas pemeliharaan dokumen
• tidak ada proses untuk memastikan bahwa dokumentasi yang ada masih relevan dan akurat

Bab ini membahas cara membangun sistem manajemen dokumen TI yang efektif: taksonomi dokumen, prinsip document control, repositori yang mudah dipakai, siklus tinjauan, dan daftar dokumen kritis yang harus ada lebih dulu. Jika Bab 5 memberi struktur akuntabilitas, bab ini memastikan akuntabilitas itu memiliki bukti, standar, dan jejak keputusan.

6.1 Masalah Dokumentasi dalam Praktik

Sebelum membahas solusi, penting untuk memahami masalah dokumentasi yang sering terjadi dalam organisasi.

6.1.1 Fenomena “Documentation Debt”

Mirip dengan technical debt dalam pengembangan software, organisasi juga dapat mengakumulasi documentation debt: hutang dokumentasi yang harus dibayar di masa depan.

Tanda-tanda Documentation Debt:

Dokumentasi tertinggal di belakang realitas sistem. Workaround dan proses ad hoc tidak terdokumentasi. Informasi kritis hanya ada di kepala satu atau dua orang (knowledge silos). Onboarding karyawan baru memakan waktu lama. Investigasi insiden juga melambat karena informasi tersebar.

Konsekuensi Documentation Debt:

• Ketergantungan berlebihan pada individu kunci
• Waktu yang hilang untuk mencari informasi
• Kesalahan karena mengikuti prosedur usang
• Kesulitan transfer pengetahuan
• Risiko kehilangan pengetahuan ketika karyawan keluar

6.1.2 Dokumentasi sebagai Formalitas dan Jebakan “SOP Copy-Paste”

Di banyak perusahaan utilitas air, dokumentasi sering diperlakukan sebagai formalitas, bukan alat kerja. Fenomena yang paling lazim terjadi adalah: ketika staf TI dituntut membuat SOP atau runbook teknis, mereka akan mencari template dari organisasi sejenis, melakukan copy-paste, mengganti logo instansi, lalu menyimpannya dalam file PDF setebal 50 halaman.

Tujuannya? Murni hanya untuk memuaskan auditor dan meloloskan sertifikasi ISO (seperti ISO 9001 atau 27001). Dokumen ini kemudian dicetak rapi, dijilid, dan ditaruh di rak lemari sebagai pajangan mati (Shelf Decoration).

Dalam praktiknya, ketika server database terbakar pada jam 2 pagi atau aplikasi billing down, tidak ada satupun staf TI yang membuka SOP 50 halaman tersebut. Mereka bekerja murni berdasarkan insting, ingatan parsial, dan kepanikan.

Direksi harus mengubah mindset formalitas ini menjadi pragmatisme operasional: Dokumentasi yang baik tidak harus berupa buku tebal dengan stempel basah. Satu halaman checklist kotor berukuran A4 yang ditempel dengan selotip di pintu rack server (yang berisi 5 langkah merestart database secara berurutan) jauh lebih bernilai bagi tata kelola ketimbang 50 halaman SOP copy-paste yang tidak pernah dibaca. Nilai dokumentasi diukur dari apakah ia berfungsi menyelamatkan Anda saat krisis, bukan dari ketebalannya saat diaudit.

6.1.3 Tantangan Dokumentasi TI

Dokumentasi TI menghadapi beberapa tantangan khusus:

1. Perubahan cepat. Teknologi berubah dengan cepat, dan dokumentasi harus sering diperbarui. Tanpa proses pembaruan yang terstruktur, dokumentasi akan cepat usang.
2. Kompleksitas teknis. Dokumentasi TI seringkali memerlukan pengetahuan teknis yang spesifik. Tanpa penulis yang memahami teknologi dan dapat menjelaskannya dengan jelas, dokumentasi akan sulit dipahami.
3. Banyak audiens. Dokumentasi TI mungkin ditujukan untuk audiens yang berbeda: teknisi, manajer, auditor, atau pengguna bisnis. Setiap audiens membutuhkan level detail dan bahasa yang berbeda.
4. Volume besar. Sistem TI modern memiliki ribuan komponen dan konfigurasi. Mendokumentasikan semuanya adalah tugas besar yang memerlukan prioritisasi.

6.1.4 Dari Masalah ke Solusi

Pola yang berulang di banyak organisasi layanan air: organisasi mengalokasikan berminggu-minggu untuk membuat dokumen yang sempurna, lalu menyimpannya di folder yang jarang dibuka siapa pun. Itu bukan dokumentasi yang hidup; itu arsip pasif. Dokumentasi yang hidup adalah dokumen yang diakses saat bekerja, dipakai saat mengambil keputusan, dan diperbarui ketika proses berubah.

Solusi untuk masalah dokumentasi bukanlah “lebih banyak dokumentasi”, tetapi “dokumentasi yang lebih baik”. Dokumentasi yang baik adalah:

1. Relevan: membahas kebutuhan nyata pengguna.
2. Dapat diakses: mudah ditemukan ketika dibutuhkan.
3. Dapat dipahami: menggunakan bahasa yang jelas untuk target audiens.
4. Terkini: diperbarui secara berkala.
5. Digunakan: benar-benar diacu dan diikuti dalam praktik.

6.2 Taksonomi Dokumen TI

Taksonomi dokumen adalah sistem klasifikasi yang membantu organisasi mengelola dokumen secara sistematis. Untuk TI, lima level piramida dokumen pada Diagram 6.1 dapat digunakan sebagai kerangka awal.

6.2.1 Level 1: Kebijakan (Policy)

Kebijakan adalah pernyataan niat manajemen atau arahan. Kebijakan menjawab pertanyaan “apa” dan “mengapa”, bukan “bagaimana”.

Karakteristik Kebijakan: Kebijakan ditulis dalam bahasa strategis, bukan operasional. Ia menetapkan arahan yang jelas, mengikat secara organisasi, disetujui manajemen puncak, dan berlaku jangka relatif panjang.

Contoh Kebijakan TI:

• Kebijakan Keamanan Informasi
• Kebijakan Acceptable Use TI
• Kebijakan Bawa Perangkat Sendiri (Bring Your Own Device, BYOD)
• Kebijakan Business Continuity
• Kebijakan Vendor Management

Struktur Kebijakan:

1. Tujuan (Purpose)
2. Ruang Lingkup (Scope)
3. Pernyataan kebijakan
4. Compliance (kepatuhan)
5. Referensi
6. Definisi (jika perlu)

6.2.2 Level 2: Prosedur

Prosedur adalah langkah-langkah yang terdokumentasi untuk mencapai tujuan secara konsisten. Prosedur menjawab pertanyaan “bagaimana” pada level yang lebih tinggi.

Karakteristik Prosedur:

• Menjabarkan langkah-langkah operasional
• Memiliki urutan yang jelas
• Menetapkan responsibility (siapa melakukan apa)
• Mengidentifikasi input dan output
• Memiliki referensi ke kebijakan terkait

Contoh Prosedur TI:

• Prosedur change management
• Prosedur Incident Management
• Prosedur Vendor Selection
• Prosedur Backup dan Recovery
• Prosedur Access Request

Struktur Prosedur:

1. Tujuan
2. Ruang lingkup
3. Referensi (kebijakan terkait)
4. Definisi
5. Tanggung jawab
6. Prosedur (langkah-langkah)
7. Bukti Pelaksanaan (Record)
8. Lampiran

6.2.3 Level 3: Instruksi Kerja

Instruksi kerja adalah panduan teknis detail untuk melaksanakan tugas spesifik. Instruksi kerja menjawab “bagaimana” pada level paling rinci.

Karakteristik Instruksi Kerja: Instruksi kerja sangat detail dan spesifik. Dokumen ini dapat berisi tangkapan layar atau diagram, ditulis untuk tugas tertentu, sering dipakai sebagai referensi harian, dan dapat diperbarui lebih sering daripada kebijakan.

Contoh Instruksi Kerja TI:

• Instruksi Instalasi Server
• Instruksi Konfigurasi Firewall
• Instruksi Restore Database
• Instruksi Reset Password
• Instruksi Penggunaan Monitoring Tool

6.2.4 Level 4: Formulir dan Templat

Formulir dan templat adalah format baku untuk pengumpulan data atau dokumentasi. Mereka memastikan konsistensi dan memudahkan pengumpulan informasi.

Contoh Formulir dan Templat TI:

• Form Change Request
• Form Incident Report
• Template notulen rapat
• Template Business Case
• Template evaluasi vendor

Manfaat Formulir dan Templat:

• Konsistensi informasi yang dikumpulkan
• Mempermudah analisis dan pelaporan
• Mengurangi waktu untuk membuat dokumen baru
• Memastikan bahwa informasi penting tidak terlewat

6.2.5 Level 5: Bukti Pelaksanaan (Record)

Record adalah bukti bahwa prosedur telah dilaksanakan. Record penting untuk demonstrasi kepatuhan, audit, dan pembelajaran.

Contoh Record TI:

• Log change management
• Log insiden
• Backup log
• Catatan pelatihan (training record)
• Catatan evaluasi vendor (vendor evaluation record)

Pentingnya Record: Record menjadi bukti kepatuhan untuk audit, dasar analisis tren, sumber pembelajaran dari insiden, dan jejak keputusan (traceability).

6.2.6 Hubungan Antar-Level

Kelima level ini membentuk hierarki yang saling terkait.

Diagram 6.1 Hierarki dokumen TI

Kebijakan (Policy)
    ↓ menurunkan
Prosedur
    ↓ menjabarkan
Instruksi Kerja
    ↓ menggunakan
Form/**Template**
    ↓ menghasilkan
Bukti Pelaksanaan (Record)

Setiap level merujuk ke level di atasnya. Misalnya, prosedur change management merujuk ke Kebijakan Perubahan, dan Instruksi Kerja Patch System merujuk ke Prosedur change management.

6.3 Sistem Manajemen Dokumen

Taksonomi dokumen saja tidak cukup. Organisasi memerlukan sistem manajemen dokumen yang memastikan dokumen dikontrol secara memadai, mudah diakses, diperbarui secara berkala, dan terintegrasi dengan proses bisnis.

6.3.1 Prinsip Document Control

Document Control adalah proses memastikan bahwa dokumen: (a) disetujui oleh orang yang berwenang, (b) tersedia di lokasi yang ditentukan, (c) dilindungi dari perubahan tidak sah, dan (d) ditinjau dan diperbarui secara berkala.

Elemen Document Control:

1. Alur persetujuan (approval workflow). Dokumen harus melalui proses persetujuan formal sebelum diterbitkan. Alur ini menetapkan siapa yang menyusun draf, siapa yang meninjau, siapa yang menyetujui, dan bagaimana perubahan dilacak.
2. Version Control. Setiap perubahan pada dokumen harus memiliki versi baru yang jelas. Sistem versi biasanya menggunakan penomoran: v1.0, v1.1, v2.0, dll, dengan aturan: perubahan minor (1.0 ke 1.1) dan perubahan mayor (1.0 ke 2.0).
3. Distribution Control. Dokumen harus didistribusikan kepada pihak yang membutuhkan, dengan pencatatan siapa yang menerima versi apa. Ini penting untuk memastikan bahwa semua pihak menggunakan versi yang sama.
4. Access Control. Tidak semua dokumen dapat diakses oleh semua orang. Dokumen sensitif mungkin memerlukan pembatasan akses berdasarkan peran.
5. Retention and Disposal. Dokumen tidak perlu disimpan selamanya. Kebijakan retention menetapkan: berapa lama dokumen disimpan, kapan dokumen dapat diarsipkan, dan kapan dokumen dapat dimusnahkan.

6.3.2 Repositori (Repository) Dokumen

Repository dokumen adalah tempat penyimpanan terpusat untuk semua dokumen organisasi. Repository yang baik memiliki karakteristik:

1. Searchable. Pengguna dapat mencari dokumen berdasarkan: kata kunci, tipe dokumen, penulis, tanggal, atau metadata lain.
2. Organized. Dokumen diorganisir dalam struktur folder yang logis dan konsisten. Struktur ini harus mudah dipahami dan digunakan.
3. Versioned. Sistem secara otomatis menyimpan riwayat versi, sehingga pengguna dapat melihat perubahan dan mengembalikan ke versi sebelumnya jika perlu.
4. Controlled. Sistem memiliki kontrol akses berbasis peran, sehingga hanya orang yang berwenang dapat mengubah dokumen.
5. Accessible. Sistem dapat diakses dari lokasi kerja pengguna, baik di kantor maupun remote.

Pilihan repositori dokumen diringkas dalam Tabel 6.1.

Tabel 6.1 Pilihan repositori dokumen

Untuk organisasi dengan sumber daya terbatas, kombinasi shared folder untuk dokumen sederhana dan wiki untuk dokumen kolaboratif dapat menjadi pilihan yang baik.

6.3.3 Siklus Review dan Pembaruan

Dokumen jarang selesai. Mereka harus ditinjau dan diperbarui secara berkala untuk memastikan relevansi.

Kategori Review:

1. Scheduled Review. Dokumen ditinjau secara berkala, misalnya: tahunan untuk kebijakan, triwulan untuk prosedur, dan bulanan untuk instruksi kerja.
2. Triggered Review. Dokumen ditinjau ketika ada pemicu, misalnya: perubahan regulasi, insiden signifikan, atau perubahan teknologi.
3. On-Demand Review. Dokumen ditinjau ketika pengguna mengidentifikasi masalah atau ketidakakuratan.

Proses Review:

1. Identifikasi dokumen yang perlu ditinjau
2. Tetapkan reviewer dan approver
3. Kumpulkan umpan balik pengguna
4. Lakukan revisi jika diperlukan
5. Perbarui versi dokumen
6. Komunikasikan perubahan ke pengguna
7. Arsipkan versi lama

6.3.4 Integrasi dengan Pelatihan

Dokumen tidak berguna jika tidak diketahui atau tidak dipahami oleh pengguna. Integrasi dengan pelatihan adalah kunci.

1. Onboarding. Karyawan baru harus diperkenalkan pada dokumen yang relevan untuk peran mereka. Ini dapat berupa: sesi orientasi, e-learning, atau mentoring.
2. Refresher Training. Pelatihan berkala, misalnya tahunan, untuk menyegarkan pemahaman tentang dokumen penting.
3. Training Records. Organisasi harus mencatat: siapa telah dilatih pada dokumen apa, kapan, dan dengan hasil apa.
4. Assessment. Untuk dokumen kritis, organisasi mungkin ingin menguji pemahaman pengguna melalui kuis atau sertifikasi.

6.3.5 Dokumentasi sebagai Living Asset

Dokumentasi yang efektif adalah “aset hidup”: terus diperbarui, digunakan, dan diperbaiki. Prinsip-prinsipnya:

Dalam pengalaman saya, dokumen yang paling berbahaya bukan dokumen yang belum ada. Yang lebih berbahaya adalah dokumen yang dianggap ada, tetapi tidak lagi dipercaya oleh orang lapangan. Begitu prosedur resmi kalah oleh kebiasaan informal, audit hanya menemukan kertas, bukan kendali.

1. Ownership yang jelas. Setiap dokumen harus memiliki owner yang bertanggung jawab untuk pemeliharaan dan pembaruan.
2. Umpan balik pengguna. Pengguna harus didorong memberikan umpan balik tentang dokumen: apakah jelas? Apakah akurat? Apakah lengkap?
3. Continuous improvement. Dokumen harus diperbaiki secara berkelanjutan berdasarkan: pengalaman praktis, insiden, perubahan regulasi, atau perubahan teknologi.
4. Terintegrasi dengan proses. Dokumen tidak terpisah dari kerja; mereka adalah bagian dari kerja. Prosedur harus diacu saat melakukan tugas, bukan hanya saat audit.

6.4 Dokumen Kritis untuk Tata Kelola TI

Berdasarkan kerangka COBIT dan praktik terbaik, berikut adalah dokumen kritis yang harus dimiliki organisasi untuk tata kelola TI yang efektif.

6.4.1 Dokumen Tata Kelola

Dokumen 1: Kerangka Tata Kelola TI (IT Governance Framework)

Dokumen ini menjelaskan bagaimana tata kelola TI diimplementasikan di organisasi. Isi minimal:

• prinsip tata kelola TI
• struktur organisasi TI dan peran
• forum pengambilan keputusan TI (steering committee)
• mekanisme akuntabilitas dan pelaporan

Dokumen 2: Rencana Strategis TI (IT Strategic Plan)

Dokumen ini merencanakan bagaimana TI akan mendukung strategi bisnis dalam jangka menengah (3-5 tahun). Isi minimal:

• analisis gap antara kebutuhan dan kapasitas TI saat ini
• arah strategis TI
• roadmap implementasi
• portfolio proyek prioritas

Dokumen 3: Daftar Risiko TI (IT Risk Register)

Dokumen ini mencatat risiko TI dan rencana mitigasi. Isi minimal:

• daftar risiko TI
• penilaian dampak dan probabilitas
• rencana mitigasi
• owner untuk setiap risiko

6.4.2 Dokumen Manajemen Risiko

Dokumen 4: Kebijakan Keamanan Informasi

Kebijakan ini menetapkan arah untuk keamanan informasi. Isi minimal:

• Komitmen manajemen puncak terhadap keamanan
• Prinsip-prinsip keamanan
• Klasifikasi informasi
• Persyaratan keamanan minimum

Dokumen 5: Prosedur Incident Response

Prosedur ini menjelaskan cara merespons insiden keamanan. Isi minimal:

• definisi insiden
• tingkat keparahan insiden
• escalation matrix
• peran dan tanggung jawab
• prosedur komunikasi

6.4.3 Dokumen Manajemen Aset

Dokumen 6: Asset Inventory

Dokumen ini mencatat semua aset TI organisasi. Isi minimal:

• daftar perangkat keras
• daftar perangkat lunak
• lisensi dan perjanjian
• lokasi aset
• owner aset

Dokumen 7: Kebijakan Lifecycle Management

Prinsipnya: jangan mulai dari pertanyaan “sistem apa yang harus kita beli?” Tanyakan dulu “keputusan apa yang harus kita perbaiki?” Sistem mengikuti keputusan, bukan sebaliknya.

Kebijakan ini menetapkan bagaimana aset TI dikelola sepanjang lifecycle-nya. Isi minimal:

• prosedur pengadaan
• standar konfigurasi
• prosedur pemeliharaan
• prosedur penghapusan

6.4.4 Dokumen Manajemen Proyek

Dokumen 8: Project Charter Template

Template ini digunakan untuk memulai proyek TI. Isi minimal:

• Tujuan proyek
• Ruang Lingkup (Scope)
• Pemangku kepentingan (stakeholder)
• Timeline
• Anggaran
• Risiko

Dokumen 9: Business Case Template

Template ini digunakan untuk mengusulkan investasi TI. Isi minimal:

• Problem statement
• Solusi yang diusulkan
• Analisis biaya-manfaat
• Return on Investment (ROI)
• Risiko dan mitigasi

6.4.5 Dokumen Manajemen Vendor

Dokumen 10: Kebijakan Vendor Management

Kebijakan ini menetapkan bagaimana vendor TI dikelola. Isi minimal:

• kriteria seleksi vendor
• persyaratan service level
• mekanisme evaluasi kinerja
• exit strategy

Dokumen 11: Service Level Agreement Template

Template ini digunakan untuk kontrak dengan vendor. Isi minimal:

• Layanan yang disediakan
• Standar kinerja
• Penalty untuk ketidakpatuhan
• Mekanisme pelaporan

6.4.6 Dokumen Kepatuhan

Dokumen 12: Compliance Matrix

Matriks ini memetakan regulasi ke persyaratan TI. Isi minimal:

• daftar regulasi yang relevan
• persyaratan TI dari setiap regulasi
• bukti kepatuhan
• owner kepatuhan

Dokumen 13: Audit Response Procedure

Prosedur ini menjelaskan cara merespons audit. Isi minimal:

• proses persiapan audit
• peran dalam audit
• proses respons temuan
• proses perbaikan dan tindak lanjut

6.5 Implementasi Sistem Dokumentasi

Bagian ini memberikan panduan praktis untuk membangun sistem dokumentasi TI yang efektif.

6.5.1 Langkah 1: Asesmen Dokumentasi Saat Ini

Langkah pertama adalah memahami keadaan saat ini:

1. Inventarisasi dokumen. Kumpulkan semua dokumen TI yang ada, di mana pun mereka berada: shared drive, laptop individu, wiki, dokumen cetak, atau lampiran email lama.
2. Klasifikasi. Klasifikasikan dokumen: tipe dokumen, level (kebijakan/prosedur/dll), topik, dan usia.
3. Identifikasi gap. Bandingkan dengan dokumen kritis di bagian 6.4. Apa yang hilang? Apa yang usang? Apa yang duplikat?
4. Kumpulkan umpan balik. Tanyakan pengguna: dokumen apa yang paling sering digunakan? Dokumen mana yang paling sulit ditemukan? Dokumen mana yang tidak akurat?

6.5.2 Langkah 2: Desain Sistem Dokumentasi

Berdasarkan asesmen, rancang sistem dokumentasi:

1. Tentukan struktur repository. Bagaimana dokumen akan diorganisir? Struktur folder harus logis dan mudah dinavigasi.
2. Pilih platform. Pilih repository yang sesuai dengan kebutuhan dan anggaran (lihat bagian 6.3.2).
3. Tetapkan standar. Standar meliputi: template dokumen, penamaan file, version control, dan proses persetujuan.
4. Definisikan peran. Siapa yang membuat dokumen, meninjau, menyetujui, dan memelihara?

6.5.3 Langkah 3: Pengembangan Dokumen Kritis

Mulai dengan dokumen paling kritis:

1. Prioritasi. Dari daftar di bagian 6.4, identifikasi dokumen yang paling kritis berdasarkan: risiko jika tidak ada, persyaratan regulasi, dan kebutuhan operasional.
2. Kembangkan secara bertahap. Jangan mencoba membuat semua dokumen sekaligus. Mulai dengan 3-5 dokumen kritis, lalu berkembang.
3. Gunakan template. Template mempercepat pengembangan dan memastikan konsistensi.
4. Libatkan pemangku kepentingan. Dokumen akan lebih baik jika dikembangkan dengan masukan dari pengguna yang akan menggunakannya.

6.5.4 Langkah 4: Peluncuran dan Pelatihan

Dokumen baru atau yang diperbarui harus diluncurkan dengan baik:

1. Komunikasikan. Beri tahu pengguna bahwa dokumen baru tersedia, mengapa penting, dan di mana menemukannya.
2. Latih. Sediakan pelatihan untuk dokumen penting: sesi langsung, e-learning, atau panduan tertulis.
3. Pantau adopsi. Pantau apakah dokumen digunakan melalui jumlah akses, unduhan, atau umpan balik langsung. Aturan praktisnya sederhana: jika risk register, prosedur insiden, atau daftar aset tidak berubah selama enam bulan berturut-turut, kemungkinan besar dokumen itu tidak sedang dipakai sebagai alat kerja.
4. Penegakan. Untuk dokumen kritis, pertimbangkan mekanisme penegakan seperti sign-off bahwa dokumen telah dibaca dan dipahami.

6.5.5 Langkah 5: Pemeliharaan Berkelanjutan

Sistem dokumentasi memerlukan pemeliharaan:

1. Scheduled review. Tetapkan jadwal review untuk setiap dokumen. Tandai di kalender.
2. Feedback loop. Buat mekanisme mudah bagi pengguna memberikan umpan balik tentang dokumen.
3. Audit dokumentasi. Secara berkala, audit sistem dokumentasi untuk memastikan: kepatuhan terhadap prosedur, kualitas dokumen, dan penggunaan aktual.
4. Continuous improvement. Perbaiki sistem dokumentasi secara berkelanjutan berdasarkan pengalaman, umpan balik, insiden, audit, dan perubahan organisasi.

6.6 Penutup Bab

Dokumentasi yang baik bukan tumpukan file. Ia adalah memori kerja organisasi. Saat insiden terjadi, audit datang, vendor berubah, atau staf kunci pindah, dokumentasi menentukan apakah organisasi tetap berjalan dengan tertib atau kembali bergantung pada ingatan perorangan.

Untuk perusahaan utilitas air, dokumentasi yang lemah biasanya terlihat di titik paling kritis: prosedur insiden tidak ditemukan, konfigurasi sistem tidak jelas, daftar aset tidak lengkap, dan bukti keputusan tidak tersimpan. Sebaliknya, dokumentasi yang hidup membuat organisasi lebih cepat pulih, lebih mudah diaudit, dan lebih mampu belajar dari kejadian.

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 dokumen yang dapat ditemukan, dipahami, dipakai, dan diperbarui. Skala organisasi boleh berbeda; kebutuhan akan jejak keputusan tetap sama.

Ringkasan Bab

• Dokumen yang tidak dipakai adalah arsip pasif, bukan alat tata kelola.
• Sistem dokumentasi perlu mengatur taksonomi, pemilik, versi, akses, siklus tinjauan, dan bukti pelaksanaan.
• Mulai dari dokumen kritis yang paling sering dibutuhkan saat insiden, audit, atau perubahan vendor.
• Pemilik dokumen harus orang yang jelas, bukan hanya nama divisi.
• Dokumentasi harus terhubung dengan pelatihan, proses kerja, dan audit agar tetap hidup.

Lima Pertanyaan Refleksi untuk Direksi

1. Dokumen TI apa yang paling dibutuhkan organisasi saat insiden terjadi, dan apakah lokasinya diketahui semua pihak terkait?
2. Siapa pemilik akhir untuk prosedur insiden, daftar aset, risk register, dan dokumen vendor kritis?
3. Berapa banyak dokumen kebijakan TI yang belum ditinjau lebih dari dua tahun?
4. Apakah dokumen kritis dipakai dalam pelatihan, atau hanya disimpan untuk kebutuhan audit?
5. Bukti keputusan TI penting disimpan di mana, dan siapa yang dapat mengaksesnya saat dibutuhkan?

Tiga Langkah yang Bisa Dimulai Minggu Ini

1. Daftar 3-5 dokumen TI yang paling sering dicari saat insiden atau audit; periksa apakah dokumen itu ada, lokasinya diketahui, dan versinya masih relevan.
2. Tunjuk satu pemilik dokumen untuk setiap dokumen kritis; bukan divisi atau tim, tetapi nama orang yang akan ditanya saat dokumen itu salah atau kedaluwarsa.
3. Jadwalkan tinjauan dokumen kritis setiap enam bulan dan masukkan pengingatnya ke kalender kerja.

Checklist Rapat Dokumentasi TI

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

• Dokumen kritis sudah terdaftar
• Setiap dokumen kritis memiliki pemilik
• Repositori dokumen disepakati
• Aturan penamaan dan versi dokumen jelas
• Siklus tinjauan dokumen masuk kalender
• Dokumen kritis terhubung dengan pelatihan dan audit

Satu Pertanyaan untuk Dibawa ke Rapat Direksi Berikutnya

Jika terjadi insiden besar sore ini, dokumen apa yang akan dicari pertama kali, dan apakah kita tahu persis versi terbarunya ada di mana?

Jawaban atas pertanyaan ini biasanya lebih jujur daripada laporan kematangan dokumentasi. Ia langsung menguji apakah dokumentasi adalah alat kerja atau sekadar koleksi file.

Menuju Bab 7: Audit yang Menguji Bukti

Dokumentasi memberi standar dan bukti. Bab 7 membahas fungsi audit TI yang memeriksa apakah standar itu dijalankan, apakah bukti cukup, dan apakah temuan benar-benar ditindaklanjuti.

Referensi & Bacaan Lanjutan

1. ISO 15489:2016 Information and Documentation - Records Management

   • ISO (2016). Standar internasional untuk manajemen record dan dokumen.
   • 🔗 ISO.org

2. COBIT 2019: Governance and Management Objectives

   • ISACA (2019). Objektif COBIT untuk manajemen informasi (APO12, DSS04).
   • 🔗 COBIT 2019

3. ITIL 4: Create, Deliver and Support

   • Axelos (2019). Praktik service management termasuk manajemen pengetahuan.
   • 🔗 ITIL Official

4. Documentation Best Practices for IT Governance

   • IT Governance Institute (2009). Panduan praktis dokumentasi untuk tata kelola TI.
   • 🔗 ITGI Resources

5. Knowledge Management: A Practical Guide

   • KM Institute (2020). Panduan manajemen pengetahuan untuk organisasi.
   • 🔗 KMI Institute

6. MoReq2010: Modular Requirements for Records Systems

   • DCC (2010). Standar requirements untuk sistem manajemen record.
   • 🔗 DCC UK

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. Dokumentasi yang efektif harus disesuaikan dengan konteks spesifik setiap organisasi. Standar yang disebutkan (ISO, COBIT, ITIL) adalah referensi dan organisasi harus mengecek versi terbaru sebelum implementasi. Hook pembuka adalah komposit pembelajaran, bukan rekonstruksi satu organisasi tertentu.