Log Keputusan: Cara Mencatat Keputusan Agar Alasannya Tetap Terjaga

Institusi mengingat apa yang mereka putuskan, tetapi melupakan alasannya. Bagaimana cara kerja catatan keputusan, apa yang harus dicatat, templat ringkas, dan cara menghubungkan setiap keputusan dengan hasilnya.

Ibrahim Elkobeissi · 2 November 2026 · 6 menit pembacaan ·

LinkedIn X WhatsApp

Fasad dari sebuah bangunan institusi modernis yang besar

Tanyakan kepada tim mengapa suatu kebijakan ada, dan Anda sering kali akan menemui keheningan. Seseorang mengingat sebuah rapat. Orang lain mengira itu masalah pemasok. Orang yang tahu telah keluar tahun lalu. Keputusannya masih ada, tetapi alasannya hilang.

Hal ini lumrah terjadi, namun berbiaya mahal. Tanpa alasan yang jelas, tim memiliki dua pilihan buruk: mempertahankan keputusan yang tidak lagi mereka pahami, atau membatalkannya dan berisiko memunculkan kembali masalah yang sebelumnya telah diatasi. Log keputusan menawarkan pilihan ketiga. Baca catatannya, periksa apakah kondisinya masih relevan, dan putuskan kembali dengan sengaja.

Mengapa institusi melupakan alasan keputusan mereka

Tiga kekuatan bekerja melawan ingatan institusi terhadap keputusannya sendiri.

Alasan hidup dalam percakapan. Keputusan dibuat dalam rapat, panggilan, dan utas pesan. Hasilnya mencapai kebijakan atau rencana. Namun, konteksnya jarang tercatat.
Orang-orang berpindah. Orang-orang yang menimbang opsi berganti peran atau pergi. Pemahaman mereka ikut terbawa bersama mereka.
Ingatan menulis ulang dirinya sendiri. Dalam studi tahun 1975, psikolog Baruch Fischhoff menemukan bahwa setelah orang mengetahui suatu hasil, mereka menilainya lebih dapat diprediksi daripada kenyataannya. Ia menyebut ini "creeping determinism." Setelah kejadian, keputusan tepat yang berakhir buruk akan terlihat ceroboh, dan keputusan beruntung akan terlihat bijaksana.

Poin terakhir adalah yang terpenting. Bahkan ketika orang yang sama tetap ada, ingatan mereka tentang alasan keputusan dipengaruhi oleh apa yang terjadi selanjutnya. Hanya catatan yang ditulis pada saat kejadian yang dapat melestarikan apa yang diketahui, apa yang diharapkan, dan apa yang belum pasti.

Panduan arsitektur Microsoft menyatakan biayanya dengan jelas. Keputusan yang tidak pernah dicatat "kemungkinan besar akan terlupakan, yang menyebabkan perdebatan berulang."

Apa yang dipelajari tim perangkat lunak: architecture decision record

Rekayasa perangkat lunak memiliki jawaban yang telah teruji. Pada November 2011, Michael Nygard mengusulkan architecture decision record, atau ADR: sebuah dokumen singkat untuk setiap keputusan penting, diberi nomor secara berurutan, dan disimpan bersama proyek. Formatnya terdiri dari lima bagian.

Judul. Frasa kata benda singkat dengan nomor, seperti "ADR 9: LDAP untuk Integrasi Multitenant."
Konteks. Kekuatan yang berpengaruh: teknis, politik, sosial, dan lokal. Nygard meminta agar bagian ini bersifat netral secara nilai, berupa deskripsi fakta.
Keputusan. Respons terhadap kekuatan tersebut, dalam kalimat lengkap menggunakan kalimat aktif: "Kami akan..."
Status. Diusulkan, diterima, usang, atau digantikan, dengan referensi ke penggantinya.
Konsekuensi. Konteks yang dihasilkan. Dalam kata-kata Nygard, "Semua konsekuensi harus dicantumkan di sini, bukan hanya yang 'positif' saja."

Praktik ini menyebar. Thoughtworks menempatkan ADR ringkas dalam ring Adopt di Technology Radar mereka, level rekomendasi terkuatnya, dan menyarankan agar ADR disimpan dalam source control daripada di wiki terpisah. Azure Well-Architected Framework dari Microsoft menyebut catatan keputusan sebagai salah satu hasil kerja paling penting bagi seorang solution architect. Panduannya menambahkan dua aturan yang patut dicontoh: perlakukan log sebagai append-only (hanya bisa menambah), dan catat tingkat kepercayaan pada setiap keputusan.

Semua ini tidak hanya spesifik untuk perangkat lunak. Rumah sakit mengubah prosedur penerimaan pasien. Sekolah mengubah kebijakan penilaian. Instansi mengubah pemasok. Setiap keputusan ini memiliki konteks, opsi, dan konsekuensi, dan masing-masing akan dipertanyakan di kemudian hari oleh seseorang yang tidak hadir saat itu.

Apa yang harus dicatat dalam sebuah catatan keputusan

Log keputusan adalah kumpulan dari catatan-catatan ini, dengan indeks yang merangkum masing-masing catatan. Playbook rekayasa Microsoft mendeskripsikan log sebagai tabel ringkasan eksekutif, lengkap dengan metadata, untuk keputusan yang ada dalam catatan lengkap. Templat log keputusan di bawah ini dapat digunakan jauh di luar bidang rekayasa. Setiap kolom memiliki fungsinya masing-masing.

ID dan judul. Nomor dan frasa yang menyatakan apa yang diputuskan.
Tanggal. Kapan keputusan dibuat, bukan kapan keputusan tersebut ditulis.
Pemilik. Orang yang bertanggung jawab atas keputusan, dan siapa yang dikonsultasikan.
Konteks. Masalah, batasan, dan kekuatan yang saling berbenturan.
Opsi yang dipertimbangkan. Termasuk opsi yang ditolak, beserta alasannya. Ini adalah kolom yang paling sering hilang dan paling sering dibutuhkan.
Keputusan. Satu kalimat jelas yang dimulai dengan "Kami akan..."
Bukti. Tautan ke data, laporan, audit, atau umpan balik yang menjadi dasar keputusan.
Hasil yang diharapkan. Apa yang seharusnya terjadi jika keputusan tersebut berhasil, dan kapan hal itu harus tercapai.
Keyakinan. Tinggi, sedang, atau rendah, lengkap dengan penjelasan mengenai hal yang masih belum pasti.
Tanggal peninjauan. Kapan keputusan tersebut akan diperiksa terhadap hasil yang diharapkan.
Status. Diusulkan, diterima, digantikan, atau dihentikan, lengkap dengan tautan ke penggantinya.

Bidang hasil yang diharapkan dan keyakinan berfungsi sebagai Jurnal keputusan. Keduanya mencatat apa yang Anda yakini sebelum Anda mengetahui hasilnya, yang merupakan hal yang justru sering terhapus oleh bias retrospektif.

Kami menerapkan standar yang sama pada setiap keputusan produk kami. Apa yang diamati ditulis secara terpisah dari apa yang disimpulkan, dan pandangan yang bertentangan tetap dipertahankan, bukan diseragamkan. Sebuah keputusan layak mendapatkan ketelitian setidaknya sejauh itu.

Tautkan setiap keputusan ke bukti dan hasilnya.

Catatan yang berdiri sendiri lebih baik daripada tidak ada sama sekali. Catatan yang tertaut jauh lebih berguna.

Tautkan kembali ke bukti. Saat sebuah keputusan mengutip survei pasien, analisis biaya, atau laporan insiden, tautkan sumbernya secara langsung. Pembaca berikutnya kemudian dapat menilai apakah bukti tersebut masih relevan. Panduan Microsoft menyampaikan poin yang sama: catatan tanpa justifikasi "akan kehilangan nilainya seiring waktu."

Tautkan ke depan ke hasil. Pada tanggal peninjauan, tuliskan apa yang sebenarnya terjadi di samping apa yang diharapkan. Jika terdapat celah yang besar, cari tahu alasannya. Apakah buktinya lemah? Apakah kondisi berubah? Apakah keputusannya sudah tepat namun hasilnya hanya kurang beruntung? Jawabannya adalah sebuah pelajaran, dan itu harus berada dalam rantai yang sama. Artikel kami tentang pelajaran yang mengubah proyek berikutnya menjelaskan cara agar pelajaran tersebut dapat diterapkan secara berkelanjutan.

Tautkan ke penerusnya. Saat sebuah keputusan dibatalkan, jangan mengubah catatan lama. Tandai sebagai digantikan dan arahkan ke catatan yang baru. Riwayat perubahan arah sering kali menjadi hal yang paling berharga dalam log.

Sebuah contoh hipotetis menunjukkan rantai ini. Sebuah klinik memutuskan untuk memindahkan panggilan tindak lanjut dari perawat ke koordinator khusus. Catatan tersebut mengutip data penyelesaian panggilan, menunjuk manajer operasional sebagai penanggung jawab, mengharapkan penyelesaian meningkat dalam tiga bulan, dan menetapkan tanggal peninjauan. Saat ditinjau, penyelesaian memang meningkat, tetapi beban kerja perawat tidak turun seperti yang diharapkan. Catatan baru menggantikan yang pertama, menyesuaikan peran, dan menautkan kembali ke catatan lama. Dua tahun kemudian, manajer baru dapat membaca seluruh ceritanya dalam lima menit.

Buatlah cukup ringan agar dapat bertahan lama.

Log keputusan gagal dengan cara yang sama seperti kegagalan dokumentasi pada umumnya. Mereka menjadi beban, lalu akhirnya dihentikan. Lima aturan ini akan menjaganya tetap berjalan.

Catat hanya keputusan yang signifikan. Tes dari Microsoft sangat berguna: keputusan yang membentuk struktur, memengaruhi kualitas utama, atau sulit untuk dibatalkan.
Buat setiap catatan tetap singkat. Satu halaman atau kurang. Tautkan ke materi pendukung alih-alih menyalinnya.
Tulis saat Anda memutuskan. Catatan yang ditulis pada minggu yang sama akan akurat. Catatan yang ditulis berbulan-bulan kemudian hanyalah sebuah rekonstruksi.
Simpan di tempat kerja dilakukan. Log yang disimpan di samping rencana dan prosedur yang dipengaruhinya akan dibaca. Log yang disimpan di folder terpisah tidak akan dibaca.
Mulai sekarang, lalu lengkapi beberapa yang lama. Mulailah dengan keputusan baru. Kemudian rekonstruksi beberapa keputusan masa lalu yang paling sering ditanyakan orang, dan tandai sebagai rekonstruksi.

Keputusan tanpa alasan hanyalah sebuah instruksi. Keputusan dengan alasan dapat diuji, dipertahankan, atau diubah dengan penuh ketelitian.

Cara Prism menjaga catatan keputusan

Prism menyimpan keputusan dan pengetahuan organisasi sebagai item dengan tingkat Kepercayaan yang dinyatakan: diratifikasi, terbukti, teramati, atau disimpulkan. Setiap keputusan tertaut ke buktinya, ke langkah-langkah pelaksanaannya, serta ke hasil dan pelajaran Pause and Learn yang menyertainya. Saat sebuah keputusan digantikan, catatan sebelumnya tetap terlihat. Asisten yang sudah digunakan tim Anda juga dapat membaca catatan tersebut, sehingga alasannya tersedia saat seseorang bertanya. Manusia yang membuat keputusan. Prism menjaga alasan mereka.