Dalam pengadaan jasa aplikasi, kerangka acuan kerja (KAK) adalah satu-satunya dokumen yang nanti dipakai sebagai pembanding saat pekerjaan diserahterimakan. Kalau isinya samar, dua pihak yang sama-sama beritikad baik pun bisa berselisih: penyedia merasa sudah selesai, instansi merasa belum. Dari pengalaman kami mengerjakan sistem untuk instansi, sumber sengketa hampir selalu sama, yaitu kalimat dalam KAK yang tidak bisa diuji.
Artikel ini membahas cara menulis KAK dan spesifikasi teknis supaya setiap butirnya bisa dicentang "sesuai" atau "belum sesuai" saat uji terima. Pengadaan barang/jasa pemerintah mengacu pada Perpres 16 Tahun 2018 beserta perubahannya (Perpres 12 Tahun 2021), dan aturan internal instansi Anda bisa menambah detailnya. Tulisan ini bukan nasihat hukum, melainkan praktik menyusun dokumen. Untuk hal yang mengikat, tetap konsultasikan dengan PPK dan unit pengadaan Anda.
Ukuran uji: satu kalimat, satu cara memeriksa
Bandingkan dua kalimat berikut.
- "Aplikasi harus mudah digunakan."
- "Staf baru dengan pelatihan 1 jam dapat menyelesaikan input satu permohonan tanpa bantuan dalam waktu maksimal 5 menit."
Kalimat pertama tidak bisa gagal, sehingga tidak bisa lulus juga. Kalimat kedua bisa diuji dengan stopwatch dan satu staf. Aturan sederhananya: setiap persyaratan harus memuat sesuatu yang bisa diamati, yaitu angka, daftar, atau perilaku yang jelas.
Beberapa pengganti kalimat samar yang sering kami pakai:
- "Cepat" menjadi "halaman daftar memuat 1.000 baris data dalam waktu di bawah 3 detik pada jaringan kantor."
- "Aman" menjadi "setiap pengguna memiliki akun sendiri, dan kata sandi disimpan dalam bentuk terenkripsi satu arah (hash)."
- "Laporan lengkap" menjadi "laporan bulanan dapat difilter per unit kerja dan periode, serta diekspor ke format Excel dan PDF."
Susun kebutuhan dalam empat kelompok
KAK yang rapi biasanya memisahkan empat hal, dan masing-masing diuji dengan cara berbeda.
- Kebutuhan fungsional. Apa yang bisa dilakukan pengguna. Tulis per peran: operator, verifikator, pimpinan. Contoh: "Verifikator dapat menolak berkas dan wajib mengisi alasan penolakan."
- Kebutuhan non-fungsional. Kecepatan, jumlah pengguna bersamaan, perangkat yang didukung, ketersediaan layanan.
- Data dan integrasi. Data apa yang dimigrasikan dari sistem lama, dalam format apa, dan siapa yang bertanggung jawab atas kebersihannya. Jika ada pertukaran data dengan aplikasi lain, sebutkan nama sistemnya dan bentuk pertukarannya.
- Layanan pendukung. Pelatihan, dokumentasi, masa garansi, dan pemeliharaan setelah serah terima.
Ruang lingkup harus menyebut yang tidak termasuk
Bagian yang paling sering dilewati adalah daftar hal yang tidak dikerjakan. Contohnya: "Pengadaan perangkat keras tidak termasuk", "Pembuatan aplikasi seluler tidak termasuk, hanya tampilan web yang responsif", atau "Migrasi data hanya untuk data tahun 2023 dan seterusnya". Tanpa daftar ini, setiap permintaan tambahan menjadi perdebatan.
Tentukan kriteria penerimaan sejak awal
Cantumkan di KAK bagaimana pekerjaan dinyatakan selesai. Contoh yang bisa ditiru:
- Seluruh butir kebutuhan fungsional diuji dengan skenario tertulis, dan hasilnya dicatat dalam berita acara uji terima.
- Cacat dikelompokkan menjadi kritis (fitur utama tidak jalan), mayor (jalan tetapi hasil salah), dan minor (tampilan atau teks). Serah terima baru dapat dilakukan bila tidak ada cacat kritis dan mayor yang terbuka.
- Dokumen yang wajib diserahkan: kode sumber atau akses repositori, dokumentasi pengguna, dokumentasi teknis, dan daftar akun beserta pemegangnya.
Tahap uji terima sendiri kami bahas di artikel tentang UAT. Hal yang perlu dipastikan di KAK adalah bahwa tahap itu dialokasikan waktunya, bukan diselipkan di minggu terakhir.
Cara menilai penawaran dengan spesifikasi yang terukur
Spesifikasi yang terukur memudahkan evaluasi. Alih-alih membandingkan brosur, Anda bisa meminta penyedia menjelaskan bagaimana tiap butir akan dipenuhi, lalu memberi nilai berdasarkan kejelasan jawaban tersebut. Untuk pengalaman yang relevan, minta contoh pekerjaan sejenis yang bisa diverifikasi, bukan sekadar daftar nama klien.
Contoh singkat satu butir yang baik
Untuk modul persetujuan cuti: "Pegawai mengajukan cuti melalui formulir; atasan langsung menerima notifikasi di aplikasi; atasan dapat menyetujui atau menolak dalam satu layar; sisa cuti terpotong otomatis setelah disetujui; riwayat perubahan status tersimpan beserta pelaku dan waktunya." Penguji tinggal menjalankan lima langkah itu dan mencentang hasilnya.
Kesalahan umum
- Menyalin KAK proyek lain tanpa menyesuaikan, sehingga memuat fitur yang tidak dibutuhkan.
- Memakai kata sifat (modern, canggih, intuitif) sebagai persyaratan.
- Tidak menyebut jumlah pengguna dan volume data, padahal ini menentukan rancangan teknis dan biaya.
- Tidak menetapkan siapa dari pihak instansi yang berwenang memutuskan perubahan.
- Tidak mengatur kepemilikan kode, data, dan akses setelah proyek selesai.
- Menaruh masa garansi tanpa menjelaskan apa yang dicakup: perbaikan cacat saja, atau juga perubahan kecil.
Daftar periksa sebelum KAK dikirim
- Setiap kebutuhan punya cara pengujian yang bisa dijelaskan dalam satu kalimat.
- Peran pengguna dan jumlahnya tertulis.
- Data lama, formatnya, dan penanggung jawab pembersihannya disebut.
- Ada bagian "di luar lingkup".
- Kriteria penerimaan dan klasifikasi cacat tercantum.
- Dokumen dan akses yang harus diserahkan terdaftar.
- Satu orang dari instansi ditunjuk sebagai pengambil keputusan atas perubahan.
KAK yang baik tidak harus tebal. Dokumen sepuluh halaman dengan butir yang bisa diuji lebih berguna daripada tiga puluh halaman berisi kalimat umum.