Banyak perusahaan memulai pengadaan ERP dengan mengundang beberapa vendor untuk presentasi, lalu meminta penawaran harga. Hasilnya sering serupa: setiap vendor menawarkan lingkup berbeda, harga tidak bisa dibandingkan, dan tim evaluasi memilih berdasarkan demo yang paling meyakinkan. Masalahnya baru terasa saat implementasi, ketika fitur yang dianggap "sudah termasuk" ternyata butuh biaya tambahan.
Dokumen RFP ERP (Request for Proposal) mencegah situasi itu. RFP memaksa perusahaan merumuskan kebutuhannya lebih dulu, lalu meminta semua vendor menjawab pertanyaan yang sama dalam format yang sama. Keputusan pun bergeser dari "vendor mana yang paling pandai presentasi" menjadi "proposal mana yang paling cocok dengan proses bisnis kami".
Artikel ini membahas cara menyusun RFP ERP langkah demi langkah: apa saja isinya, cara menulis kebutuhan yang bisa diuji, cara menyusun bobot evaluasi, serta kesalahan yang sering membuat tender berlarut-larut.
Apa itu RFP ERP?
RFP ERP adalah dokumen resmi yang dikirim perusahaan kepada calon vendor atau implementor untuk meminta proposal solusi ERP lengkap: perangkat lunak, metodologi implementasi, tim, jadwal, dan biaya. Berbeda dengan permintaan harga biasa, RFP meminta vendor menjelaskan bagaimana mereka akan memenuhi kebutuhan Anda.
Dalam proses pengadaan, RFP biasanya berdampingan dengan dua dokumen yang namanya mirip:
- RFI (Request for Information): dikirim lebih awal ke banyak vendor untuk memetakan pasar dan menyaring daftar pendek.
- RFP (Request for Proposal): dikirim ke daftar pendek, biasanya tiga sampai lima vendor, untuk meminta solusi dan pendekatan lengkap.
- RFQ (Request for Quotation): berfokus pada harga untuk barang atau jasa yang spesifikasinya sudah jelas. Penjelasan lengkapnya ada di artikel kami tentang fungsi request for quotation (RFQ) dalam bisnis.
Untuk sistem ERP, RFQ saja jarang cukup. Kebutuhan ERP menyentuh banyak proses sekaligus, sehingga cara vendor memenuhinya sama pentingnya dengan harganya.
Mengapa RFP penting dalam pengadaan ERP
ERP adalah investasi multi-tahun yang mengubah cara kerja keuangan, gudang, pengadaan, produksi, hingga SDM. Keputusan memilih sistem dan partner sulit dibatalkan setelah kontrak ditandatangani. RFP yang disusun dengan baik memberi tiga manfaat utama.
- Proposal bisa dibandingkan secara adil. Semua vendor menjawab daftar kebutuhan dan format harga yang sama, sehingga asal selisih biaya terlihat jelas.
- Lingkup proyek terkunci sejak awal. Dokumen RFP dan jawaban vendor bisa dijadikan lampiran kontrak, sehingga perdebatan "ini termasuk lingkup atau tidak" berkurang.
- Keputusan lebih mudah dipertanggungjawabkan. Bagi perusahaan dengan komite pengadaan, auditor internal, atau pemegang saham, skor evaluasi tertulis jauh lebih kuat daripada kesan rapat.
Menyusun RFP juga memaksa diskusi internal yang sering tertunda: proses mana yang ingin distandarkan, laporan apa yang dibutuhkan manajemen, dan siapa pemilik keputusan di tiap area.
Isi dan struktur dokumen RFP
Tidak ada format baku, tetapi RFP untuk sistem ERP yang efektif umumnya memuat bagian berikut.
| Bagian | Isi utama | Tujuan |
|---|---|---|
| Profil perusahaan dan latar belakang | Bidang usaha, jumlah entitas dan lokasi, perkiraan jumlah pengguna, sistem yang dipakai saat ini | Vendor memahami skala dan kompleksitas |
| Tujuan dan lingkup proyek | Masalah yang ingin diselesaikan, modul dan entitas yang tercakup, serta yang tidak tercakup | Membatasi lingkup sejak awal |
| Kebutuhan fungsional | Daftar kebutuhan per proses bisnis beserta prioritasnya | Menilai kecocokan sistem |
| Kebutuhan non-fungsional | Integrasi, keamanan, opsi hosting, performa, bahasa, regulasi | Menilai kesiapan teknis |
| Implementasi dan dukungan | Metodologi, komposisi tim, migrasi data, pelatihan, dukungan pasca go-live | Menilai kemampuan eksekusi partner |
| Format harga | Template rincian biaya per komponen | Membandingkan biaya secara setara |
| Ketentuan proses | Jadwal, sesi tanya-jawab, format jawaban, kriteria evaluasi, kerahasiaan | Tender berjalan tertib dan transparan |
Kebutuhan fungsional yang bisa diuji
Bagian ini paling sering ditulis terlalu umum. Kalimat seperti "sistem harus mendukung manajemen persediaan" akan dijawab "ya" oleh semua vendor. Tulis kebutuhan sebagai skenario yang bisa diverifikasi, misalnya: "sistem dapat menghitung harga pokok persediaan dengan metode rata-rata tertimbang per gudang dan menampilkan kartu stok per nomor batch".
Kelompokkan kebutuhan per alur proses, seperti order-to-cash, procure-to-pay, dan record-to-report, lalu beri prioritas: wajib, penting, atau opsional. Minta vendor menjawab tiap baris dengan status seragam: tersedia standar, perlu konfigurasi, perlu kustomisasi, atau tidak tersedia.
Kebutuhan non-fungsional dan konteks Indonesia
Untuk perusahaan di Indonesia, sertakan kebutuhan yang sering terlupa: faktur pajak dan pelaporan yang selaras dengan sistem Direktorat Jenderal Pajak, laporan keuangan sesuai standar akuntansi yang berlaku (PSAK), multi-mata uang, antarmuka berbahasa Indonesia, serta pelindungan data pribadi sesuai UU No. 27 Tahun 2022. Bila sistem berbasis cloud, tanyakan juga lokasi penyimpanan data dan kebijakan backup-nya.
Format harga yang seragam
Sediakan template biaya yang memisahkan lisensi atau langganan, jasa implementasi, kustomisasi, migrasi data, pelatihan, infrastruktur, dan dukungan tahunan. Minta proyeksi biaya untuk beberapa tahun, bukan hanya tahun pertama, agar total biaya kepemilikan terlihat. Angka ini nantinya menjadi dasar saat Anda menghitung ROI implementasi ERP.
Cara menyusun RFP ERP: langkah praktis
- Bentuk tim penyusun lintas fungsi. Libatkan perwakilan keuangan, operasional, pengadaan, IT, dan satu sponsor dari jajaran direksi. Tetapkan satu koordinator sebagai satu-satunya jalur komunikasi dengan vendor.
- Petakan proses saat ini dan masalahnya. Dokumentasikan alur kerja utama, laporan yang dibutuhkan, dan titik masalah. Pemetaan ini juga bagian dari persiapan implementasi ERP secara keseluruhan, jadi hasilnya tidak terbuang.
- Tulis dan prioritaskan kebutuhan. Mulai dari kebutuhan wajib. Daftar yang terlalu panjang membuat vendor menjawab seadanya dan tim evaluasi kewalahan.
- Tetapkan kriteria dan bobot evaluasi sebelum RFP dikirim. Bobot yang baru disusun setelah proposal masuk rawan bias terhadap vendor favorit.
- Kirim RFP ke daftar pendek dan buka sesi tanya-jawab. Bagikan semua pertanyaan beserta jawabannya ke seluruh peserta agar informasi setara.
- Nilai proposal tertulis, lalu undang demo berbasis skenario. Berikan skenario bisnis Anda sendiri kepada vendor finalis dan minta mereka mendemonstrasikannya, bukan demo standar.
- Verifikasi referensi dan negosiasi. Hubungi referensi dari industri serupa, lalu lanjutkan negosiasi dengan satu atau dua finalis.
Contoh bobot evaluasi berikut hanya ilustrasi. Sesuaikan dengan prioritas perusahaan Anda.
| Kriteria | Contoh bobot | Yang dinilai |
|---|---|---|
| Kecocokan fungsional | 30% | Porsi kebutuhan wajib yang tersedia standar atau lewat konfigurasi |
| Metodologi dan tim implementasi | 25% | Rencana kerja, pengalaman tim yang diusulkan, pendekatan migrasi data dan pelatihan |
| Total biaya kepemilikan | 20% | Biaya awal dan biaya berjalan selama beberapa tahun |
| Kesesuaian teknis | 15% | Integrasi, keamanan, opsi hosting, skalabilitas |
| Dukungan dan keberlanjutan vendor | 10% | Layanan pasca go-live, rencana pengembangan produk, stabilitas perusahaan |
Beri vendor waktu yang wajar untuk menjawab. RFP ERP yang lengkap membutuhkan analisis serius, dan tenggat yang terlalu singkat justru menghasilkan jawaban dangkal. Daftar pertanyaan lanjutan untuk tahap demo dan negosiasi bisa Anda ambil dari panduan cara memilih vendor ERP yang tepat.
Kesalahan umum yang perlu dihindari
- Menyalin template RFP dari internet tanpa penyesuaian. Ratusan baris fitur generik tidak membedakan vendor, karena semuanya akan menjawab "tersedia".
- Menulis solusi, bukan kebutuhan. "Harus ada tombol X di layar Y" mengunci Anda pada cara kerja lama. Jelaskan hasil yang dibutuhkan dan biarkan vendor mengusulkan caranya.
- Mengabaikan kebutuhan implementasi. Kualitas eksekusi sama menentukannya dengan pilihan software. Minta CV tim inti yang benar-benar akan ditugaskan, bukan sekadar profil perusahaan.
- Membiarkan format harga bebas. Tanpa template, satu vendor memasukkan migrasi data ke harga dan yang lain tidak, sehingga perbandingan menjadi menyesatkan.
- Tidak menyebut apa yang di luar lingkup. Entitas, modul, atau integrasi yang tidak ditulis jelas akan menjadi sumber perubahan lingkup dan biaya tambahan di tengah proyek.
- Tanya-jawab yang tidak transparan. Menjawab pertanyaan satu vendor secara pribadi menciptakan ketimpangan informasi dan melemahkan akuntabilitas keputusan.
Pertanyaan yang Sering Diajukan
Berapa banyak vendor yang sebaiknya menerima RFP ERP?
Umumnya tiga sampai lima vendor hasil penyaringan awal. Lebih banyak dari itu membebani tim evaluasi tanpa menambah kualitas keputusan, sementara terlalu sedikit melemahkan posisi negosiasi.
Apakah perusahaan menengah perlu RFP formal?
Perlu, meskipun bentuknya bisa lebih ringkas. Yang terpenting adalah daftar kebutuhan berprioritas, format harga seragam, dan kriteria evaluasi tertulis. Ketiganya tetap relevan berapa pun ukuran perusahaannya.
Berapa lama waktu menyusun RFP ERP?
Bergantung pada jumlah entitas, proses, dan kesiapan dokumentasi internal. Perusahaan yang alur kerjanya sudah terdokumentasi akan jauh lebih cepat dibanding yang harus memetakan proses dari nol. Sisihkan waktu khusus bagi pemilik proses, karena merekalah sumber kebutuhan yang akurat.
Bolehkah memakai konsultan untuk menyusun RFP?
Boleh, dan sering membantu bila tim internal belum pernah menjalani seleksi ERP. Pastikan konsultan tersebut tidak memiliki kepentingan terhadap vendor tertentu, atau minta hubungan tersebut dinyatakan secara terbuka sejak awal.
Kesimpulan
RFP ERP yang baik bukan dokumen tebal berisi daftar fitur, melainkan alat untuk mengambil keputusan yang bisa dipertanggungjawabkan. Kuncinya ada pada kebutuhan yang ditulis sebagai skenario yang bisa diuji, prioritas yang jelas, format harga yang seragam, dan bobot evaluasi yang disepakati sebelum proposal masuk. Dengan fondasi itu, demo vendor menjadi ajang pembuktian, bukan sekadar presentasi.
Solvera mendampingi perusahaan dalam implementasi ERP, system integration, dan IT consulting, termasuk pemetaan proses sebelum pengadaan. Jika Anda sedang menyiapkan daftar kebutuhan untuk RFP dan ingin menguji apakah lingkupnya sudah realistis, diskusikan rencana pengadaan ERP Anda bersama tim kami.