Belajar IT Support - Documentation & Knowledge Base

#Pendahuluan

Setelah di episode 16 kalian punya senjata scripting, sekarang kita bahas aset yang membuat nilainya berlipat: dokumentasi. Solusi terbaik yang hanya ada di kepala satu orang adalah bom waktu organisasi — ia meledak tepat saat orang itu cuti, resign, atau sedang tidak bisa dihubungi saat server mati Jumat malam.

Mengapa dokumentasi disebut superpower support? Karena tiga alasan praktis: (1) masalah yang sama datang berulang — KB mengubah jawaban ke-50 sama cepatnya dengan jawaban pertama; (2) user bisa membantu dirinya sendiri lewat self-service, memangkas tiket; (3) kalian bisa libur tanpa telepon. Tim tanpa dokumentasi bekerja dua kali untuk setiap masalah: sekali menyelesaikan, sekali mengingat lagi.

#Dua Jenis Dokumen Inti

Jenis	Pembaca	Tujuan	Contoh
KB Article	End-user	Panduan mandiri bahasa manusia	"Cara connect WiFi kantor"
SOP/Runbook	Teknisi	Prosedur operasional presisi	"Runbook reset password AD"

Memisahkan keduanya itu penting: SOP yang diberikan ke user akan membuatnya bingung; KB yang dipakai teknisi akan kurang detail. Banyak perusahaan menyimpan keduanya di satu portal (Confluence, Notion, SharePoint, wiki helpdesk).

#Anatomi KB Article yang Benar

Struktur yang terbukti enak dibaca user:

Template KB article

JUDUL   : kata kerja + objek + konteks
          "Cara Connect VPN Kantor dari Rumah (Windows 11)"
1. Kapan artikel ini dipakai?     → gejala/situasi pemicu
2. Prasyarat                      → akun, aplikasi, akses apa saja
3. Langkah-langkah                → bernomor, satu aksi per langkah,
                                    sertakan screenshot titik kritis
4. Hasil yang diharapkan          → tanda berhasil
5. Kalau gagal?                   → 2-3 masalah umum + solusinya,
                                    lalu cara buka tiket
6. Terakhir diperbarui + pemilik  → agar pembaca tahu usianya

Aturan gaya tulis untuk user:

Satu langkah = satu aksi: "Klik ikon jaringan di pojok kanan bawah." Bukan paragraf campur aduk.
Tulis sesuai yang terlihat di layar, bukan istilah internal ("klik tombol biru Connect", bukan "invoke the VPN adapter").
Screenshot pada langkah yang rawan salah; lebih berharga daripada sepuluh kalimat.
Hindari singkatan internal (SSO, MDM) tanpa penjelasan singkat.

#SOP/Runbook untuk Teknisi

SOP ditulis untuk rekan kerja — standarnya beda:

Contoh runbook ringkas

RUNBOOK: Reset Password Domain
Scope    : semua user domain corp.local, TIDAK termasuk VIP (eskalasi Tier 2)
Prasyarat: akses RDP ke DC01, grup Helpdesk-Operators
Verifikasi identitas WAJIB: tatap muka + kartu pegawai ATAU video call HR
Langkah:
  1. ADUC -> cari user -> Reset Password
  2. Centang 'User must change password at next logon'
  3. Serahkan via kanal resmi (jangan email plain)
  4. Catat di tiket: jam, metode verifikasi, pelapor
Eskalasi: akun terkunci berulang 3x/hari -> indikasi brute force ->
          eskalasi security (tiket P2)
Referensi: KB-014 (panduan user ganti password)

Perhatikan ciri SOP dewasa: ada scope, prasyarat, verifikasi, langkah bernomor, batas eskalasi, dan referensi silang. SOP seperti ini membuat teknisi baru bisa bertindak benar di hari pertamanya.

#Self-service dan Shift-left

KB bukan sekadar arsip — ia strategi mengurangi beban tiket:

100%

Konsep shift-left: dorong penyelesaian semungkin ke tingkat paling awal (user sendiri), sisanya ke Tier 1, dst. Setiap artikel bagus = ratusan tiket yang tidak pernah lahir. Metrik pendukungnya sederhana: berapa persen kunjungan artikel yang mencegah tiket (banyak portal menampilkan rating "apakah ini membantu?").

Tip

Target realistis tim kecil: 20 artikel terbaik biasanya menutup 60-80% volume tiket rutin (password, VPN, printer, email kuota, request software). Mulai dari daftar top-10 tiket bulan lalu — itulah daftar prioritas penulisan kalian.

#Mendokumentasikan Sambil Mengerjakan

Kebiasaan yang membedakan tim hebat: dokumentasi lahir dari proses, bukan proyek terpisah:

Saat menyelesaikan kasus baru, langsung tulis log tiket yang rapi (episode 9) — itu draf mentah KB.
Tutup tiket dengan pertanyaan: "kalau kasus ini datang lagi, apakah saya butuh otak saya, atau cukup artikel?" Kalau butuh otak → tulis artikel hari itu juga.
Jadikan template: salin struktur log → rapikan jadi KB/SOP dalam 10 menit.
Beri atribusi: nama penulis di artikel memicu kebanggaan — dan tanggung jawab menjaganya tetap akurat.

#Menjaga KB Tetap Hidup

Dokumentasi busuk diam-diam. Siklus perawatan minimal:

Owner per artikel — dokumen tanpa pemilik pasti kedaluwarsa.
Review berkala (kuartalan untuk SOP sensitif: offboarding, security).
Tanggal update wajib tampil — user lebih percaya artikel yang jelas umurnya.
Umpan balik pembaca: tombol "artikel ini tidak membantu" adalah alarm gratis.
Hapus artikel usang dengan berani; portal penuh maya dokumen lebih buruk daripada kosong.

Note

Di era AI (episode 21), kualitas KB makin menentukan: chatbot support hanya secerdas artikel yang ia telan. Tim dengan KB rapi otomatis punya asisten virtual yang bagus — gratis. Tim tanpa dokumentasi tidak bisa diotomasi siapa pun.

#Penutup

Inti yang harus dibawa pulang:

Dua dokumen inti: KB untuk user (bahasa manusia) dan SOP/runbook untuk teknisi (presisi + scope + eskalasi).
Struktur KB: situasi → prasyarat → langkah satu aksi per baris → hasil → kalau gagal → tanggal & owner.
Shift-left: artikel bagus memangkas tiket di sumbernya; mulai dari top-10 keluhan.
Dokumentasikan sambil mengerjakan: log tiket rapi adalah draf KB, tutup tiap kasus dengan artikel atau alasan kenapa tidak perlu.
KB hidup butuh owner, review berkala, tanggal update — dan menjadi bahan bakar AI support nanti.

Di episode 18 selanjutnya kita masuk fase networking & security: network security basics — firewall dan aturan port yang sehat, VPN kantor jenis-jenisnya, mengamankan WiFi korporat dengan WPA2/WPA3, segmentasi VLAN sederhana, dan kebiasaan keamanan jaringan yang harus dimiliki setiap support. Sampai jumpa!