RFP pengembangan software yang baik menjelaskan masalah bisnis, hasil yang diharapkan, ruang lingkup, kebutuhan fungsional dan nonfungsional, integrasi, data, keamanan, deliverables, kriteria penerimaan, tata kelola, serta cara proposal vendor dinilai. Dokumen ini tidak harus menentukan seluruh solusi teknis, tetapi harus cukup jelas agar vendor menawarkan pekerjaan yang sebanding dan risiko penting tidak tersembunyi di balik harga.
Bagi tim procurement dan IT, tujuan Request for Proposal (RFP) bukan sekadar meminta penawaran. RFP adalah dasar untuk menyamakan pemahaman, membandingkan solusi, mengendalikan perubahan ruang lingkup, dan membangun keputusan yang dapat dipertanggungjawabkan.
Apa itu RFP pengembangan software?
RFP pengembangan software adalah dokumen permintaan proposal yang menjelaskan konteks, kebutuhan, batas pekerjaan, hasil, dan aturan evaluasi untuk proyek aplikasi atau sistem. Vendor kemudian merespons dengan pendekatan solusi, rencana kerja, tim, asumsi, risiko, jadwal, dan biaya.
RFP berbeda dari daftar fitur mentah. Daftar fitur hanya menyebut apa yang ingin dibuat, sedangkan RFP membantu peserta memahami alasan bisnis, kondisi saat ini, siapa penggunanya, batas integrasi, ukuran keberhasilan, dan bentuk serah terima.
| Dokumen | Fokus utama | Kapan digunakan |
|---|---|---|
| RFP | Meminta solusi dan penawaran yang dapat dibandingkan | Saat organisasi akan memilih vendor atau pendekatan |
| KAK/TOR | Menetapkan kerangka acuan, tujuan, ruang lingkup, dan keluaran | Saat pekerjaan perlu didefinisikan secara formal |
| BRD | Mendokumentasikan kebutuhan dan aturan bisnis | Saat kebutuhan perlu dianalisis lebih dalam sebelum atau selama implementasi |
| SOW | Mengikat lingkup pekerjaan, deliverables, jadwal, dan tanggung jawab | Setelah solusi/vendor dipilih dan kontrak disiapkan |
Nama dan kedalaman dokumen dapat berbeda antarorganisasi. Untuk pengadaan pemerintah, tim tetap harus mengikuti kebijakan serta regulasi yang berlaku. Portal resmi LKPP menyediakan rujukan regulasi pengadaan melalui SIPRAJA LKPP.
Mengapa RFP software sering menghasilkan proposal yang sulit dibandingkan?
Penyebab utamanya adalah vendor menerima konteks dan batas pekerjaan yang tidak sama. Ketika RFP hanya berisi nama modul dan tenggat, setiap vendor akan membuat asumsi sendiri tentang jumlah pengguna, migrasi data, integrasi, keamanan, pelatihan, infrastruktur, dan dukungan.
Harga termurah akhirnya belum tentu mencakup pekerjaan yang sama. Perbedaan baru terlihat setelah proyek berjalan, lalu muncul change request, penundaan, atau perdebatan tentang hal yang dianggap “sudah termasuk”.
- Masalah bisnis tidak dijelaskan; vendor hanya diminta menyalin proses lama.
- Kebutuhan wajib dan kebutuhan tambahan tidak dibedakan.
- Volume pengguna, transaksi, data, dan lokasi tidak diberi kisaran.
- Integrasi disebut tanpa pemilik sistem, dokumentasi API, atau batas tanggung jawab.
- Kriteria selesai hanya berbunyi “sistem berjalan”.
- Format respons dan metode evaluasi tidak ditetapkan.
Apa saja isi RFP pengembangan software?
Gunakan 12 bagian berikut sebagai struktur minimum, lalu sesuaikan kedalamannya dengan kompleksitas dan risiko proyek.
| Bagian | Pertanyaan yang harus terjawab | Keluaran |
|---|---|---|
| 1. Latar belakang | Mengapa proyek diperlukan? | Konteks dan masalah terukur |
| 2. Tujuan | Perubahan bisnis apa yang diharapkan? | Outcome dan indikator keberhasilan |
| 3. Ruang lingkup | Proses, unit, lokasi, dan fase mana yang masuk? | In-scope dan out-of-scope |
| 4. Pengguna | Siapa memakai dan menyetujui apa? | Persona, peran, dan hak akses |
| 5. Kebutuhan fungsional | Apa yang harus dapat dilakukan sistem? | Daftar kebutuhan berprioritas |
| 6. Kebutuhan nonfungsional | Seberapa aman, cepat, tersedia, dan mudah digunakan? | Target kualitas terukur |
| 7. Data dan migrasi | Data apa dipindahkan dan siapa membersihkannya? | Objek, volume, kualitas, rekonsiliasi |
| 8. Integrasi | Sistem mana terhubung dan bagaimana pertukaran datanya? | Daftar interface dan tanggung jawab |
| 9. Deliverables | Apa yang diserahkan selain aplikasi? | Kode, dokumen, konfigurasi, pelatihan |
| 10. Implementasi | Bagaimana fase, jadwal, dan tata kelolanya? | Milestone dan forum keputusan |
| 11. Acceptance | Bagaimana hasil dinyatakan diterima? | Kriteria UAT dan bukti serah terima |
| 12. Respons vendor | Bagaimana proposal harus disusun dan dinilai? | Format respons dan matriks evaluasi |
1. Bagaimana menulis latar belakang dan tujuan?
Mulailah dari masalah dan outcome, bukan dari teknologi. Jelaskan proses saat ini, hambatan, dampak, pihak yang terdampak, serta perubahan yang ingin dicapai. Contoh: mempercepat konsolidasi laporan antarunit, mengurangi entri ulang data, atau menyediakan jejak persetujuan yang dapat diaudit.
Hindari menjadikan “membuat aplikasi” sebagai tujuan. Aplikasi adalah sarana; tujuan harus menggambarkan kondisi operasional yang lebih baik dan dapat diuji.
2. Bagaimana membatasi ruang lingkup?
Tuliskan apa yang masuk, tidak masuk, dan direncanakan untuk fase berikutnya. Sebutkan proses bisnis, badan usaha, lokasi, kelompok pengguna, kanal, platform, bahasa, serta periode data. Batas ini membantu vendor menghitung kapasitas tim dan membantu procurement mengenali perbedaan asumsi.
Jika kebutuhan belum cukup jelas, lakukan discovery dan audit requirement sebelum meminta harga implementasi penuh.
3. Bagaimana menuliskan kebutuhan fungsional tanpa terlalu teknis?
Nyatakan siapa melakukan apa, terhadap data apa, dalam kondisi apa, dan hasil apa yang diharapkan. Gunakan bahasa proses bisnis, lalu beri prioritas Must, Should, Could, atau Won’t for now.
Contoh kebutuhan yang lebih jelas: “Finance Manager dapat menyetujui atau mengembalikan pengajuan pembayaran di atas batas tertentu, dengan alasan, waktu, dan identitas pemberi keputusan tercatat.” Pernyataan ini lebih dapat diuji daripada “tersedia modul approval”.
4. Kebutuhan nonfungsional apa yang perlu dicantumkan?
Minimum, RFP harus membahas keamanan, kinerja, ketersediaan, backup dan pemulihan, audit trail, aksesibilitas, kompatibilitas, skalabilitas, serta pemeliharaan. Gunakan target yang relevan dengan operasi, bukan kata-kata absolut seperti “sangat cepat” atau “100% aman”.
Untuk keamanan pengembangan, NIST Secure Software Development Framework (SSDF) menyediakan praktik pengembangan perangkat lunak aman, sedangkan OWASP Application Security Verification Standard (ASVS) dapat menjadi rujukan penyusunan dan verifikasi kontrol keamanan aplikasi. Tingkat kontrol tetap harus disesuaikan dengan risiko dan data yang diproses.
5. Apa yang harus dijelaskan tentang data, migrasi, dan integrasi?
Jelaskan objek data, sumber, perkiraan volume, kualitas, histori, aturan transformasi, rekonsiliasi, serta pemilik persetujuannya. Untuk integrasi, cantumkan nama sistem, pemilik, arah pertukaran data, frekuensi, dokumentasi yang tersedia, lingkungan uji, keamanan akses, dan siapa menanggung perubahan sistem pihak ketiga.
RFP juga perlu meminta vendor menulis asumsi dan pengecualian secara eksplisit. Ini mencegah risiko integrasi dan migrasi tersembunyi di catatan kecil proposal.
6. Deliverables apa yang perlu diminta?
Jangan berhenti pada aplikasi yang dapat dibuka. Sesuaikan daftar serah terima dengan model kerja dan kontrak, misalnya kode sumber, konfigurasi, dokumentasi arsitektur, spesifikasi API, skema data, panduan deployment, manual pengguna dan administrator, test report, materi pelatihan, daftar akses, serta rencana rollback.
Tentukan pula hak penggunaan, kepemilikan hasil kerja, komponen pihak ketiga, lisensi, lokasi repositori, dan prosedur serah terima. Untuk membaca biaya secara utuh, bandingkan juga Total Cost of Ownership (TCO), belanja modal, dan biaya operasional.
7. Bagaimana menentukan acceptance dan UAT?
Setiap deliverable harus memiliki kriteria penerimaan, bukti, penanggung jawab pemeriksaan, dan batas waktu perbaikan. User Acceptance Testing (UAT) adalah pengujian oleh perwakilan bisnis untuk membuktikan bahwa solusi mendukung proses yang disepakati, bukan sekadar halaman dapat dibuka.
RFP dapat meminta traceability antara kebutuhan, skenario uji, hasil, defect, perbaikan, dan persetujuan. Panduan tentang gerbang kesiapan dapat dilihat pada artikel UAT dan kesiapan operasional sistem.
Bagaimana membuat matriks evaluasi vendor IT?
Tetapkan kriteria, bobot, skala nilai, bukti minimum, serta aturan kelulusan sebelum proposal dibuka. Ini mengurangi penilaian berdasarkan presentasi yang paling menarik atau harga terendah saja.
| Kriteria | Contoh bobot | Bukti yang dinilai |
|---|---|---|
| Pemahaman kebutuhan dan risiko | 20% | Ringkasan masalah, asumsi, pertanyaan, risiko |
| Solusi dan kesesuaian teknis | 25% | Arsitektur, integrasi, keamanan, skalabilitas |
| Metode dan rencana delivery | 15% | Fase, milestone, QA, UAT, cutover |
| Tim dan tata kelola | 10% | Peran, kompetensi, alokasi, eskalasi |
| Keamanan dan keberlanjutan | 15% | Kontrol, dokumentasi, dukungan, handover |
| Komersial dan TCO | 15% | Harga, lisensi, infrastruktur, support, asumsi |
Catatan: bobot di atas adalah contoh, bukan standar universal. Organisasi harus menyesuaikannya dengan risiko, kebijakan, dan tujuan proyek.
Selain skor total, gunakan kriteria gugur untuk hal yang benar-benar wajib, misalnya pemenuhan persyaratan hukum, kontrol keamanan minimum, atau kemampuan integrasi kritis. Setelah proposal masuk, lanjutkan dengan due diligence dan evaluasi vendor IT enterprise.
Apa checklist RFP sebelum dikirim kepada vendor?
RFP siap dikirim jika pembaca eksternal dapat memahami kebutuhan, batas pekerjaan, cara merespons, dan cara dinilai tanpa menebak informasi mendasar.
- Masalah bisnis, tujuan, dan indikator keberhasilan sudah disetujui pemilik proses.
- Ruang lingkup, pengecualian, fase, unit, lokasi, dan kelompok pengguna ditulis jelas.
- Kebutuhan wajib dipisahkan dari kebutuhan tambahan.
- Kebutuhan nonfungsional dan keamanan dapat diverifikasi.
- Sumber data, migrasi, integrasi, dan tanggung jawab pihak ketiga dipetakan.
- Deliverables, hak penggunaan, dokumentasi, pelatihan, dan handover didefinisikan.
- UAT, acceptance, perbaikan defect, serta mekanisme perubahan ruang lingkup dijelaskan.
- Vendor diwajibkan menulis asumsi, pengecualian, dependensi, dan risiko.
- Format harga memisahkan implementasi, lisensi, infrastruktur, support, dan biaya pihak ketiga.
- Matriks evaluasi dan aturan klarifikasi disetujui sebelum proposal diterima.
Bagaimana proses menyusun RFP yang efektif?
Proses yang efektif dimulai dari penyelarasan internal, bukan langsung meminta harga vendor.
- Tetapkan owner keputusan. Tentukan sponsor, pemilik proses, procurement, IT, keamanan, finance, dan pengguna kunci.
- Petakan kondisi saat ini. Catat alur kerja, data, sistem, masalah, dependensi, dan batas regulasi.
- Definisikan outcome dan prioritas. Pisahkan kebutuhan wajib, tambahan, serta fase berikutnya.
- Susun ruang lingkup dan acceptance. Hubungkan kebutuhan dengan deliverable dan bukti penerimaan.
- Lakukan review lintas fungsi. Uji dokumen dari sudut operasi, IT, keamanan, finance, legal, dan procurement.
- Terbitkan format respons yang seragam. Minta setiap vendor mengisi struktur teknis dan komersial yang sama.
- Kelola klarifikasi secara adil. Dokumentasikan jawaban dan bagikan perubahan material kepada seluruh peserta yang relevan.
Kapan perusahaan perlu bantuan menyusun RFP atau IT blueprint?
Bantuan eksternal berguna ketika kebutuhan lintas divisi belum selaras, sistem lama tidak terdokumentasi, integrasi kompleks, data sensitif, atau keputusan teknologi berisiko mengunci perusahaan pada vendor tertentu. Fasilitator independen dapat membantu memisahkan kebutuhan bisnis dari solusi, memetakan risiko, dan menyusun dasar evaluasi yang lebih objektif.
Layana.ID dapat membantu tim procurement dan IT melakukan pemetaan kebutuhan, menyusun IT blueprint, mendefinisikan ruang lingkup, dan menyiapkan kriteria evaluasi sebelum pengadaan. Diskusikan kebutuhan RFP dan proyek software Anda untuk menentukan apakah cukup dengan review dokumen atau perlu discovery lintas fungsi.
Pertanyaan umum tentang RFP pengembangan software
Apakah RFP harus menyebut teknologi yang digunakan?
Tidak selalu. Tetapkan teknologi jika ada alasan arsitektur, keamanan, integrasi, kompetensi internal, atau standar perusahaan. Jika tidak, jelaskan constraint dan minta vendor membandingkan opsi beserta konsekuensinya.
Seberapa detail fitur harus ditulis?
Cukup detail agar vendor memahami alur, aktor, aturan, data, pengecualian, dan hasil yang dapat diuji. Detail desain layar dapat dikembangkan saat discovery kecuali antarmuka tertentu memang menjadi syarat.
Apakah harga tetap dapat diminta jika kebutuhan belum lengkap?
Dapat diminta, tetapi risiko asumsi dan perubahan akan tinggi. Pilihan yang lebih aman adalah memisahkan fase discovery berharga tetap, lalu menetapkan baseline implementasi berdasarkan hasil yang telah disetujui.
Berapa vendor yang sebaiknya diundang?
Tidak ada angka universal. Pilih jumlah yang memungkinkan persaingan sehat sekaligus memberi waktu untuk klarifikasi dan evaluasi berkualitas sesuai kebijakan organisasi.
Siapa yang harus menyetujui RFP?
Minimal sponsor bisnis, pemilik proses, IT, procurement, dan fungsi risiko terkait. Finance, legal, keamanan informasi, serta data protection perlu dilibatkan bila lingkup dan risikonya relevan.
Kesimpulan
RFP pengembangan software yang efektif membuat vendor menjawab kebutuhan yang sama, mengungkap asumsi sejak awal, dan menyediakan dasar evaluasi yang dapat diaudit. Fokuskan dokumen pada outcome bisnis, batas lingkup, kualitas, data, integrasi, acceptance, serta total biaya—bukan pada daftar fitur dan harga semata.