Checklist Kebutuhan Sistem Informasi Sebelum Meminta Penawaran

“Kami butuh sistem untuk operasional” adalah awal percakapan, tetapi belum cukup untuk membandingkan penawaran. Sebelum berbicara dengan calon penyedia, tulis dulu pekerjaan yang ingin dibantu sistem, siapa yang mengerjakannya, dan seperti apa hasil yang dapat diterima. Dokumen awal ini tidak harus berupa spesifikasi teknis yang panjang; yang penting, tim Anda dan penyedia membahas masalah yang sama.

1. Mulai dari masalah dan alur kerja saat ini

Pilih satu proses yang paling perlu dibenahi, misalnya permintaan pembelian internal. Catat titik awal, langkah-langkah, siapa yang memeriksa atau menyetujui, alat yang digunakan sekarang, dan titik yang sering membuat pekerjaan tertunda. Tanyakan kepada orang yang benar-benar menjalankan proses tersebut, bukan hanya pengambil keputusan. Panduan GOV.UK tentang memahami kebutuhan pengguna menyarankan untuk meneliti siapa penggunanya, apa yang mereka coba kerjakan, bagaimana cara mereka melakukannya saat ini, dan masalah yang ditemui.

Rumuskan tujuan sebagai hasil kerja: “staf dapat mengetahui status permintaan tanpa bertanya ke beberapa orang”, bukan langsung “harus memakai aplikasi dengan lima menu”. Dengan begitu, pilihan solusi masih terbuka untuk dibahas.

2. Daftar pengguna dan hak aksesnya

Siapa yang membuat data, siapa yang memeriksa, siapa yang menyetujui, dan siapa yang hanya melihat laporan? Tulis peran tersebut beserta tindakan yang boleh dilakukan. Jika ada beberapa lokasi atau unit kerja, jelaskan apakah data dan kewenangannya sama. Daftar peran membantu penyedia memahami alur persetujuan dan kebutuhan akses, tanpa mengasumsikan setiap pegawai membutuhkan fitur yang sama.

3. Pisahkan kebutuhan fungsi dan kualitas layanan

• Fungsi: tindakan yang perlu dilakukan sistem, misalnya membuat permintaan, mengubah status, mencatat persetujuan, atau mengekspor laporan.
• Kualitas dan batasan: hal yang perlu diperhatikan saat fungsi itu dipakai, misalnya kemudahan penggunaan, keamanan akses, keandalan, perangkat yang digunakan, dan kebutuhan pemulihan data.

IBM membedakan kebutuhan fungsional dan nonfungsional; contoh kebutuhan nonfungsional mencakup keamanan, keandalan, dan kegunaan. Jangan menulis target kinerja atau janji keamanan yang belum disepakati. Nyatakan kondisi pemakaian yang diketahui, lalu minta calon penyedia menjelaskan pendekatan dan asumsi mereka.

4. Petakan data dan ketergantungan

Sebutkan data yang masuk, asalnya, siapa yang bertanggung jawab atas kualitasnya, dan keluaran yang diperlukan. Apakah data lama perlu dipindahkan? Apakah sistem harus bertukar data dengan aplikasi yang telah digunakan? Tuliskan nama proses dan bentuk kebutuhan pertukaran data yang Anda ketahui; bila cara integrasinya belum jelas, tandai sebagai pertanyaan terbuka. Hindari mengirim contoh data pelanggan asli hanya untuk memperoleh perkiraan awal—gunakan contoh kosong atau data rekaan yang diberi label jelas.

5. Urutkan prioritas dan tulis cara memeriksanya

Bagi daftar menjadi kebutuhan untuk tahap pertama, kebutuhan tahap berikutnya, dan hal yang masih perlu diuji. Untuk setiap kebutuhan utama, buat contoh hasil yang bisa diamati. Misalnya: “Saat staf mengirim permintaan, penyetuju dapat melihat permintaan tersebut; setelah disetujui, staf dapat melihat statusnya.” Ini lebih jelas daripada “fitur persetujuan lengkap”. Panduan GOV.UK tentang user story menjelaskan bahwa kriteria penerimaan adalah daftar hasil yang digunakan untuk memastikan layanan memenuhi kebutuhan pengguna.

6. Samakan cakupan saat meminta penawaran

Dalam ringkasan untuk calon penyedia, sertakan tujuan, diagram alur sederhana, daftar peran, kebutuhan prioritas, data dan integrasi yang mungkin diperlukan, serta contoh kriteria penerimaan. Tambahkan batasan yang sudah diketahui, seperti tenggat yang diinginkan dan pihak yang akan memeriksa hasil. Minta setiap penyedia menyebutkan apa yang termasuk, yang belum termasuk, asumsi, tahapan kerja, dan hal yang masih perlu diklarifikasi. Dengan dasar diskusi yang sama, perbedaan penawaran lebih mudah ditelusuri tanpa menganggap harga terendah otomatis paling sesuai.

Checklist singkat sebelum menghubungi penyedia

• Masalah dan hasil yang diinginkan dijelaskan dengan bahasa kerja sehari-hari.
• Alur saat ini dan orang yang menjalankannya sudah dipetakan.
• Peran pengguna serta kewenangan utamanya tercatat.
• Fungsi utama dipisahkan dari kebutuhan kualitas dan batasan.
• Sumber data, keluaran, dan integrasi yang mungkin diperlukan dicatat.
• Prioritas tahap pertama serta contoh kriteria penerimaan disiapkan.
• Pertanyaan yang belum terjawab ditandai, bukan ditebak.

Dokumen ini adalah bahan awal, bukan keputusan desain final. Uji kembali asumsi bersama pengguna dan calon penyedia sebelum menyepakati lingkup pekerjaan. Jika proses bisnis masih berubah, mulai dari satu alur yang paling penting dan perbarui daftar kebutuhan berdasarkan temuan diskusi.

Kredit gambar: Beatriz Cattel — sumber gambar — Unsplash License
Deskripsi gambar: Perempuan menggambar diagram alur kerja di papan tulis.
Relevansi: Foto stok ilustratif menampilkan orang menggambar flowchart; relevan dengan langkah memetakan proses sebelum menyusun kebutuhan sistem, bukan dokumentasi proyek atau klien Sahabat Sistem.