Cara Menyusun RFP (Request for Proposal) untuk Proyek IT

Apa Itu RFP dan Kenapa Masih Jarang Dipakai di Indonesia

RFP atau Request for Proposal adalah dokumen resmi yang dipakai perusahaan untuk mengundang vendor mengajukan penawaran proyek. Isinya mencakup latar belakang, lingkup pekerjaan, spesifikasi teknis, jadwal, dan kriteria evaluasi. Singkatnya, RFP itu surat lamaran versi kebalikan. Vendor yang melamar, perusahaan yang memilih.

Di Indonesia, praktik ini masih kalah populer dibandingkan nego langsung dengan satu vendor. Dari 60 lebih proses pengadaan klien yang kami dampingi periode 2022 sampai 2026, hanya sekitar 20% yang menyusun RFP formal. Sisanya memilih vendor berdasarkan rekomendasi atau harga pertama yang masuk. Padahal untuk proyek di atas Rp 100 juta, selisih kualitas antar penawaran bisa sangat jauh. Vendor yang sama bisa mengirim proposal bagus dan buruk tergantung seberapa jelas brief yang mereka terima.

Belanja teknologi korporasi Indonesia terus naik. BPS mencatat pertumbuhan pengguna internet dan investasi TIK bisnis dari tahun ke tahun, sementara jumlah penyedia jasa software makin padat. Lebih dari 300 software house aktif tercatat di Bandung saja pada 2026, belum termasuk Jakarta dan Surabaya. Makin banyak penjual, makin penting pembeli punya cara objektif membandingkan. RFP adalah alatnya.

Kapan Anda Butuh RFP dan Kapan Tidak

RFP bukan jawaban untuk semua kondisi. Memaksakan RFP untuk proyek kecil justru bikin prosesnya lambat dan biaya administrasinya tidak sebanding. Ini panduan kasarnya:

• Proyek di atas Rp 100 juta dengan vendor yang belum dikenal: wajib RFP.
• Proyek berulang dengan vendor yang sudah terbukti 2-3 tahun: cukup perpanjang kontrak, tidak perlu RFP baru.
• Proyek kecil di bawah Rp 30 juta dengan lingkup jelas: cukup quotation dan brief singkat.
• Proyek yang butuh teknologi spesifik yang jarang dikuasai vendor lokal: RFP justru paling berguna karena memaksa calon vendor menjelaskan pendekatan mereka.

Prinsipnya satu: gunakan RFP saat risiko salah pilih lebih mahal daripada biaya menyusun dokumennya. Untuk perusahaan menengah yang baru pertama kali membeli jasa pengembangan software, RFP adalah investasi kecil yang melindungi budget besar.

Struktur RFP Proyek IT yang Benar

RFP yang baik tidak harus tebal. Dokumen 8 sampai 15 halaman sudah cukup untuk proyek bernilai ratusan juta. Yang penting isinya lengkap dan tidak ambigu. Ini tujuh bagian yang wajib ada:

1. Ringkasan Eksekutif dan Latar Belakang

Jelaskan siapa perusahaan Anda, bergerak di bidang apa, dan kenapa proyek ini diadakan. Sertakan konteks bisnis, bukan cuma konteks teknis. Contoh: "Perusahaan logistik di Cikarang dengan 200 karyawan ingin mengganti sistem pencatatan gudang yang masih manual." Vendor butuh konteks ini untuk menyusun solusi yang masuk akal, bukan sekadar menjual fitur.

2. Lingkup Pekerjaan (Scope of Work)

Ini bagian paling sering gagal. Lingkup yang samar menghasilkan penawaran yang samar. Tuliskan deliverables secara eksplisit: modul apa saja yang dibangun, berapa halaman aplikasi, integrasi dengan sistem apa, data apa yang dimigrasi. Kalau memungkinkan, lampirkan dokumen SRS atau daftar kebutuhan fungsional sebagai lampiran. Semakin detail di sini, semakin kecil ruang dispute saat proyek berjalan.

3. Spesifikasi Teknis dan Non-Fungsional

Bedakan kebutuhan fungsional (fitur) dan non-fungsional (performa, keamanan, skalabilitas). Sebutkan target konkret: aplikasi harus bisa menangani 1.000 pengguna bersamaan, response time di bawah 2 detik, data tersimpan di server Indonesia. Kalau Anda tidak yakin dengan spesifikasinya, tuliskan kebutuhan bisnisnya saja dan minta vendor mengusulkan arsitektur. Anda sedang membeli hasil, bukan teknologi tertentu.

4. Jadwal dan Milestone

Beri tanggal target yang realistis. Pisahkan menjadi milestone dengan deliverable yang bisa dicek: desain selesai, modul inti selesai, uji coba, peluncuran. Hindari frasa "sesegera mungkin". Vendor tidak bisa memberi harga yang akurat tanpa jadwal yang jelas, dan Anda tidak bisa menilai progress tanpa titik cek.

5. Syarat Komersial dan Model Pembayaran

Minta vendor menyebutkan struktur biaya secara transparan: biaya pengembangan, biaya bulanan, biaya maintenance setelah peluncuran. Sampaikan juga skema pembayaran yang Anda harapkan, misalnya 30% di muka, 40% saat milestone kedua, 30% saat serah terima. Skema ini melindungi kedua pihak dan menjadi dasar SLA dan kontrak nantinya.

6. Kriteria Evaluasi Vendor

Tuliskan bobot penilaian di RFP. Contoh: harga 30%, pendekatan teknis 30%, pengalaman tim 25%, jadwal 15%. Dengan bobot yang terbuka, vendor tahu apa yang Anda hargai dan menyusun proposal yang relevan. Ini juga melindungi Anda dari tuduhan nepotisme di internal perusahaan, karena keputusan bisa dijelaskan dengan angka.

7. Ketentuan Kontrak dan SLA

Sebutkan durasi kontrak, opsi perpanjangan, kepemilikan source code, dan garansi. Jangan lupa SLA dasar: waktu respons perbaikan bug, jaminan uptime, dan sanksi keterlambatan. Detail SLA lengkap bisa Anda pelajari di panduan memilih partner teknologi kami.

Contoh Kalimat RFP yang Bagus vs yang Buruk

Perbedaan RFP yang bagus dan buruk sering cuma soal kalimat. Ini perbandingannya:

• Buruk: "Kami butuh sistem yang bagus dan modern." Bagus: "Kami butuh aplikasi yang bisa diakses 50 admin dari browser, dengan form input dan laporan otomatis."
• Buruk: "Vendor diharapkan berpengalaman." Bagus: "Vendor wajib menyertakan 2 portofolio proyek serupa dalam 2 tahun terakhir beserta kontak klien."
• Buruk: "Harga harus kompetitif." Bagus: "Sertakan rincian biaya per fase dan biaya maintenance bulanan tahun pertama."

Kalimat yang spesifik membuat vendor berhenti menebak. Dan vendor yang tidak perlu menebak, bisa memberi harga yang lebih jujur.

Kesalahan Umum Saat Menyusun RFP

Setelah bertahun-tahun membaca RFP dari klien, ini kesalahan yang paling sering kami temui:

• Terlalu teknis padahal tujuannya bisnis. Menuliskan nama framework tertentu padahal Anda tidak butuh framework itu, hanya mempersempit jumlah vendor yang layak.
• Tidak menyebutkan budget. Vendor yang tidak tahu budget akan mengirim proposal kemahalan atau terlalu murah. Sebutkan rentang, misalnya Rp 150 sampai 200 juta, agar penawaran masuk akal.
• Jadwal tidak realistis. Minta aplikasi ERP selesai dalam sebulan, kemudian mengeluh semua vendor menolak.
• Evaluasi hanya berdasarkan harga. Kesalahan yang sama dengan yang dijelaskan di artikel kesalahan fatal IT outsourcing kami: proyek termurah sering jadi proyek termahal setelah revisi dan bug diperhitungkan.
• Menilai proposal dari ketebalan dokumen, bukan dari kualitas jawaban.

Kalau Anda baru pertama kali menyusun RFP dan butuh gambaran proses pengadaan yang lebih luas, baca juga panduan proses development dari brief sampai launch.

Cara Menilai Respons Vendor

Setelah RFP terkirim, jangan langsung memilih vendor dengan proposal tercantik. Buat sesi klarifikasi selama 60 sampai 90 menit untuk setiap vendor yang masuk daftar pendek. Perhatikan hal yang tidak tertulis di proposal:

• Apakah tim yang hadir di rapat sama dengan tim yang akan mengerjakan proyek? Banyak vendor mengirim tim sales di awal, lalu menyerahkan pengerjaan ke tim lain yang belum pernah mendengar RFP Anda.
• Apakah mereka menjawab pertanyaan dengan spesifik atau berputar-putar? Jawaban yang berbunga-bunga biasanya menutupi ketidakyakinan.
• Bagaimana mereka memperlakukan pertanyaan sulit? Vendor yang jujur mengakui keterbatasan lebih bisa dipercaya daripada yang menjanjikan segalanya.
• Minta demo atau proof of concept untuk modul yang paling berisiko, bukan modul yang paling mudah.

Berdasarkan pengalaman Next IT menangani 50 lebih proyek pengembangan, keputusan yang paling sering disesali klien bukan karena salah pilih teknologi, tapi karena salah menilai kesiapan tim vendor. Teknologi bisa dipelajari. Kultur kerja dan kejujuran komunikasi tidak bisa diubah dalam satu proyek.

Checklist RFP Sebelum Dikirim

Sebelum tombol kirim ditekan, cek dokumen Anda sekali lagi dengan daftar ini. Kalau ada yang belum terisi, lengkapi dulu. RFP yang setengah jadi hanya membuang waktu semua pihak.

• Latar belakang bisnis tercantum, bukan cuma daftar fitur.
• Lingkup pekerjaan menyebutkan deliverables yang bisa dicek, misalnya "modul laporan siap dipakai 30 hari setelah desain disetujui".
• Jadwal realistis dengan milestone dan tanggal konkret.
• Rentang budget disebutkan, kecuali ada alasan strategis untuk menyembunyikannya.
• Kriteria evaluasi dengan bobot tertulis.
• Ketentuan kepemilikan source code dan SLA dicantumkan.
• Daftar pertanyaan untuk vendor dilampirkan, misalnya soal pengalaman di industri Anda.
• Nama dan kontak penanggung jawab yang bisa dihubungi vendor.
• Batas waktu pengiriman proposal yang masuk akal, minimal 7 hari kerja.

Dokumen yang lolos cek ini biasanya menghasilkan proposal yang jauh lebih mudah dibandingkan. Vendor menghargai kejelasan, dan kejelasan itu kembali ke Anda dalam bentuk penawaran yang lebih akurat. Satu tambahan terakhir: minta vendor mempresentasikan proposalnya langsung, bukan hanya mengirim file PDF. Presentasi live mengungkap banyak hal yang tidak bisa dinilai dari dokumen.

Rekomendasi Next IT

Ambil posisi tegas di sini: untuk proyek di atas Rp 150 juta, jangan pernah memilih vendor tanpa RFP dan proses evaluasi tertulis. Itu bukan birokrasi, itu perlindungan budget. Untuk startup dan perusahaan kecil dengan anggaran terbatas, kami sarankan RFP versi ringkas: cukup lingkup pekerjaan, jadwal, budget, dan 3 portofolio. Empat bagian itu sudah menyaring 80% vendor yang tidak serius.

Kami juga menyarankan Anda melibatkan pihak yang benar-benar paham teknis saat menyusun spesifikasi, baik itu tim internal maupun konsultan IT outsourcing. RFP yang disusun tanpa masukan teknis biasanya menghasilkan kesenjangan besar antara dokumen dan realita pengerjaan. Konsultan yang baik akan membantu Anda menulis kebutuhan bisnis dengan bahasa yang bisa diterjemahkan vendor menjadi arsitektur, tanpa Anda harus belajar coding.

Terakhir, jadikan RFP sebagai dokumen hidup. Setelah proyek selesai, simpan dan gunakan untuk proyek berikutnya. Klien kami yang paling efisien adalah mereka yang punya template RFP sendiri dan tinggal menyesuaikan. Satu kali kerja keras menyusun struktur, sepuluh kali proyek terbantu.

Butuh pendamping menyusun RFP atau mengevaluasi penawaran vendor? Tim Next IT bisa membantu Anda lewat layanan konsultasi IT, atau diskusikan kebutuhan solusi AI dan otomasi Anda bersama kami. Sumber acuan resmi soal proses pengadaan bisa Anda lihat di portal LKPP dan data statistik TIK di situs BPS.

Ditulis oleh Tim Next IT. Kami adalah software house dan konsultan IT di Bandung yang sudah menyelesaikan 50 lebih proyek untuk klien di Indonesia, dari sistem internal hingga platform publik.