Bahasa Melayu

Cara Menjalankan RFP SaaS yang Tidak Membazirkan 6 Minggu

Fakta Utama: Semak Realiti RFP SaaS

  • Purata kitaran RFP pasaran tengah: 4-6 bulan dari permulaan hingga kontrak ditandatangani (Gartner, 2024). RFP tanpa lemak memampatkan ini kepada 3 minggu.
  • Incumbent memenangi kira-kira 60-70% RFP di mana pembeli sudah mempunyai hubungan vendor, selalunya kerana keperluan ditulis berdasarkan set ciri incumbent.
  • Kos setiap RFP: $15K-$40K dalam tenaga kerja pembeli (5-10 orang x 40-60 jam) dan anggaran $30K-$75K dalam kos respons vendor, yang dihargakan semula ke dalam urusan.
  • Kadar kejayaan berstruktur berbanding ad-hoc: Pembeli yang menggunakan kad skor berpemberat dan skrip demo berstruktur melaporkan kepuasan 2.3 kali lebih tinggi pada tanda bulan ke-12 berbanding penilaian tidak berstruktur (Forrester, 2023).
  • Kadar peninggalan RFP: Kira-kira 25% RFP pasaran tengah berakhir tanpa pembelian, biasanya kerana proses telah melampaui keperluan masalah.

Keperluan telah dikenal pasti pada Januari. Menjelang Februari, pengarah telah menghantar RFP kepada tujuh vendor. Menjelang pertengahan Mac, enam respons telah masuk. Jawatankuasa penilaian terdiri daripada lima orang bertemu tiga kali dalam tempoh empat minggu untuk menilai respons. Dua vendor telah disenaraikan pendek. Kedua-duanya memberikan demo. Tiada demo yang berstruktur sama, jadi perbandingan adalah sukar. Perdebatan dalaman berterusan. Keputusan dibuat pada akhir April. Rundingan kontrak bermula pada Mei. Alat itu aktif pada Ogos.

Empat belas bulan dari pengenalan keperluan hingga go-live. Penyelidikan Forrester tentang kitaran pembelian perisian B2B menunjukkan bahawa proses perolehan yang berpanjangan adalah salah satu punca utama projek perisian yang terhenti atau ditinggalkan. Kosnya bukan sekadar masa, ia adalah kos berganda daripada masalah yang tidak diselesaikan.

Proses itu bukan tidak cekap. Ia hanya direka untuk organisasi yang berbeza. Kitaran perolehan syarikat besar dibina untuk pengurusan risiko pada skala: berbilang pihak berkepentingan, kontrak besar, hubungan vendor yang panjang, pengawasan kawal selia. Untuk syarikat bersaiz 150 orang yang membeli alat $40K setahun, proses ini tidak mengurus risiko. Ia mencipta risiko: risiko keputusan lambat, kekecewaan pasukan, dan kos masalah yang tidak diselesaikan selama setahun.

RFP SaaS yang baik untuk syarikat pasaran tengah memerlukan tiga minggu, bukan enam. Begini cara menjalankannya.

Apa yang RFP Tanpa Lemak Sebenarnya Capai

Mari jelaskan apa itu RFP SaaS dan apa bukan.

RFP adalah untuk: membuat keputusan yang boleh dipertahankan di antara beberapa pilihan yang boleh dipercayai, memastikan keperluan ditakrifkan dengan jelas, dan mewujudkan rekod bertulis yang mewajarkan pemilihan.

RFP bukan untuk: menemui apa yang anda perlukan (itu adalah ringkasan keperluan), menjalankan pertandingan kecantikan perolehan, atau mewujudkan proses yang begitu menyeluruh sehingga tiada sesiapa yang boleh mempersoalkan hasilnya. Sebelum menulis baris pertama RFP, pastikan anda telah menjalankan pokok keputusan pembelian SaaS untuk mengesahkan anda sepatutnya membeli, bukan membina atau melanjutkan alat sedia ada.

Kebanyakan RFP gagal kerana mereka cuba melakukan semua perkara di atas secara serentak, dan beban proses itu menghancurkan kelajuan keputusan. RFP tanpa lemak memisahkan langkah-langkah ini, memastikan setiap satu fokus, dan mengekalkan momentum.

Penapis RFP 3 Peringkat

Setiap keupayaan yang dinilai untuk vendor harus diisih ke dalam salah satu daripada tiga peringkat sebelum RFP dihantar. Mesti ada ialah keupayaan yang alat tidak boleh ketiadaan, tiada satu pun berarti syarat kelayakan automatik, tiada mata diberikan. Pembeza ialah keupayaan di mana vendor berbeza secara material dari segi kualiti dan di mana perbezaan itu mengubah pengalaman pengendali harian, ini membawa sebahagian besar berat penilaian. Elok ada ialah ciri berguna tetapi tidak menentukan yang hanya memaklumkan pengundi sama taraf. Kebanyakan RFP yang gagal mengaburkan peringkat ini, memperlakukan elok ada sebagai mesti ada akan mempersempitkan medan kepada pemenang yang salah.

Fasa 1: Ringkasan Keperluan (Hari 1-2)

Sebelum mana-mana vendor mendengar daripada anda, tulis ringkasan keperluan satu halaman. Bukan dokumen RFP tiga puluh halaman: ringkasan satu halaman.

Ringkasan itu menjawab lima soalan:

  1. Masalah apa yang kami selesaikan? Satu perenggan, tiada jargon, cukup spesifik supaya seseorang yang tidak biasa dengan pasukan akan memahami keperluan itu.

  2. Apakah keupayaan mesti ada? Maksimum lima. Ini adalah keupayaan tanpa mana alat tidak berfungsi untuk anda. Jadilah spesifik: "penyegerakan CRM dua arah" bukan "integrasi."

  3. Apakah keupayaan elok ada? Maksimum lima. Ini memaklumkan penilaian tetapi tidak menolak vendor.

  4. Seperti apa kejayaan pada 90 hari? Satu atau dua hasil yang boleh diukur. "Masa respons di bawah 2 jam untuk 90% tiket" adalah metrik kejayaan. "Perkhidmatan pelanggan yang lebih baik" tidak.

  5. Apakah kekangannya? Julat bajet (terus terang), keperluan integrasi, keperluan pematuhan, garis masa.

Templat: Ringkasan Keperluan 1 Halaman

Projek: Pemilihan [Kategori Alat], [Tarikh]
Pemilik: [Nama + Jawatan]

Pernyataan masalah:
[2-3 ayat menerangkan keadaan semasa dan kos masalah]

Keupayaan mesti ada (disusun mengikut keutamaan):
1.
2.
3.
4.
5.

Keupayaan elok ada:
1.
2.
3.

Metrik kejayaan pada 90 hari:
1.
2.

Kekangan:
- Bajet: $[X] hingga $[Y] setahun
- Keperluan integrasi: [senarai]
- Pematuhan: [senarai]
- Garis masa: aktif menjelang [tarikh]
- Pihak berkuasa keputusan: [nama]

Edarkan ringkasan ini kepada pembuat keputusan dan seorang pihak berkepentingan teknikal untuk kelulusan sebelum sebarang jangkauan vendor. Langkah ini mencegah kegagalan RFP yang paling biasa: keperluan yang berubah di pertengahan proses kerana ia tidak pernah ditakrifkan dengan jelas.

Fasa 2: Senarai Pendek Vendor (Hari 3-5)

Jemput tiga hingga lima vendor. Bukan tujuh. Bukan sepuluh.

Keinginan untuk menebar jaring lebar berasal daripada rasa takut terlepas pilihan terbaik. Tetapi menjemput terlalu banyak vendor mewujudkan empat masalah. Untuk CRM khususnya, senarai semak pembeli CRM boleh membantu anda menapis vendor sebelum mereka mencapai peringkat senarai pendek formal, mengurangkan medan tanpa melambatkan proses anda.

  1. Vendor memberikan respons generik apabila mereka bersaing dalam medan yang besar
  2. Penilaian menjadi sukar diurus dan perbandingan menjadi tidak adil
  3. Proses mengambil masa lebih lama, mengurangkan momentum
  4. Anda memberi isyarat keseriusan yang rendah, yang mempengaruhi kualiti penglibatan vendor

Cara membina senarai pendek dalam 48 jam:

  • Mulakan dengan Gartner Peer Insights, G2, atau Capterra yang ditapis mengikut saiz syarikat (saiz anda) dan industri
  • Semak alat yang digunakan oleh rangkaian rakan sebaya anda (tanya dalam komuniti Slack, LinkedIn, jangkauan langsung kepada dua atau tiga pengendali rakan sebaya)
  • Lihat apa yang vendor yang telah anda lihat dalam demo sebenarnya bersaing (tanya wakil secara langsung)
  • Sahkan senarai pendek terhadap keupayaan mesti ada anda dan alih keluar mana-mana vendor yang jelas tidak dapat memenuhi mesti ada #1 atau #2

Hantar setiap vendor yang disenaraikan pendek salinan ringkasan keperluan ditambah dua permintaan khusus:

  1. Panggilan awal 30 minit untuk mengesahkan sama ada mereka sesuai sebelum ke peringkat demo formal
  2. Jawapan bertulis kepada lima soalan mesti ada anda sebelum panggilan

Panggilan saringan 30 minit menghapuskan vendor yang tidak sesuai tanpa membuang masa pada demo penuh. Mana-mana vendor yang tidak dapat menjawab soalan mesti ada anda secara bertulis sebelum panggilan mungkin tidak bersedia secara operasi untuk keperluan anda.

Fasa 3: Skrip Demo Berstruktur (Minggu 2)

Ini adalah langkah yang paling banyak RFP pasaran tengah terlepas, dan ia adalah yang paling mempengaruhi kualiti keputusan. Menjalankan senarai semak due diligence vendor secara selari dengan Fasa 3 membolehkan anda mengesahkan keselamatan, kesihatan kewangan, dan SLA sokongan semasa pasukan anda menilai ciri dalam demo.

Tanpa skrip demo berstruktur, setiap vendor menunjukkan kepada anda apa yang mereka banggakan. Anda melihat ciri yang berbeza dalam konteks yang berbeza dan membandingkannya menjadi latihan subjektif yang memihak kepada siapa yang memberikan pembentangan paling polished.

Dengan skrip demo berstruktur, setiap vendor menunjukkan kepada anda senario yang sama dalam urutan yang sama. Anda membandingkan cara alat yang berbeza mengendalikan masalah yang sama, yang sebenarnya berguna.

Membina skrip demo:

Ambil lima keupayaan mesti ada anda dan tulis satu senario bagi setiap keupayaan. Senario harus menggambarkan aliran kerja sebenar daripada perniagaan anda, bukan kes penggunaan generik.

Senario buruk: "Tunjukkan kami cara pelaporan anda berfungsi." Senario baik: "Pengurus jualan perlu melihat, mengikut wakil, akaun mana yang berpindah dari Layak ke Cadangan dalam 30 hari lalu, dengan ARR yang berkaitan. Tunjukkan kami cara membina dan berkongsi pandangan itu."

Masukkan dua atau tiga senario daripada senarai elok ada anda sebagai item bonus jika masa mengizinkan.

Templat Skrip Demo 15 Soalan:

Hantar ini kepada vendor sehari sebelum demo. Beritahu mereka untuk menjalani senario anda, bukan aliran demo standard mereka.

  1. Jalani [Senario Mesti Ada 1] dari persediaan hingga output.
  2. Jalani [Senario Mesti Ada 2] dari hujung ke hujung.
  3. Jalani [Senario Mesti Ada 3] termasuk cara ralat atau kes tepi dikendalikan.
  4. Jalani [Senario Mesti Ada 4] termasuk kebenaran dan kawalan akses.
  5. Jalani [Senario Mesti Ada 5].
  6. Tunjukkan kami integrasi dengan [CRM/HRIS], khususnya cara [objek data tertentu] menyegerak secara dua arah.
  7. Tunjukkan kami apa yang berlaku apabila integrasi terputus: bagaimana ralat dipaparkan dan diselesaikan?
  8. Tunjukkan kami Dashboard pentadbir, khususnya cara pengguna baharu diperuntukkan dan dialih keluar.
  9. Tunjukkan kami pandangan pelaporan yang akan digunakan oleh [jawatan tertentu] setiap hari: bagaimana ia diakses dan disesuaikan?
  10. Tunjukkan kami senario di mana sesuatu salah (import yang gagal, ralat kebenaran, konflik penyegerakan) dan bagaimana sistem mengendalikannya.
  11. Jalani kami melalui proses pelaksanaan untuk syarikat bersaiz kami. Seperti apa minggu pertama?
  12. Apakah yang ada dalam Roadmap anda untuk 90 hari akan datang yang relevan dengan kes penggunaan kami?
  13. Apakah yang biasanya sukar bagi pelanggan bersaiz anda dalam 60 hari pertama?
  14. Apakah SLA anda untuk gangguan P1 dan bolehkah anda tunjukkan kepada kami di mana ia didokumentasikan?
  15. Jika kami menandatangani hari ini dan aktif dalam 30 hari, apa yang anda perlukan daripada kami dan apa yang akan anda hantar?

Peruntukkan 60-75 minit bagi setiap vendor. Simpan nota anda sendiri pada helaian penilaian (lihat di bawah) semasa demo berjalan.

Fasa 4: Penilaian Kad Skor dan Keputusan (Minggu 3)

Selepas demo selesai, beri skor kepada setiap vendor pada matriks kriteria berpemberat sebelum sebarang perbincangan kumpulan. Ini menghalang berat sebelah penanda, di mana perbincangan kumpulan menumpu kepada pilihan yang paling banyak dibincangkan atau paling baru dilihat dan bukannya yang terbaik. Penyelidikan Harvard Business Review tentang membuat keputusan kumpulan menunjukkan bahawa penilaian individu sebelum perbincangan kumpulan secara konsisten menghasilkan penilaian yang lebih tepat berbanding penaakulan terbuka tanpa kerangka berstruktur.

Matriks Penilaian Vendor Berpemberat:

Kriteria Berat Vendor A Vendor B Vendor C
Mesti ada #1: [keupayaan] 20% 1-5 1-5 1-5
Mesti ada #2: [keupayaan] 20%
Mesti ada #3: [keupayaan] 15%
Mesti ada #4: [keupayaan] 15%
Mesti ada #5: [keupayaan] 10%
Kesediaan integrasi 10%
Kualiti sokongan dan SLA 5%
Rekod jejak pelaksanaan 3%
Elok ada #1 1%
Elok ada #2 1%
Jumlah Berpemberat 100%

Setiap penilai memberi skor secara bebas sebelum mesyuarat kumpulan. Mesyuarat kumpulan menyemak skor, membincangkan varians yang ketara (di mana penilai memberi skor vendor yang sama secara berbeza), dan membuat keputusan.

Tetapkan seorang pengundi sama taraf (pembuat keputusan) sebelum mesyuarat kumpulan bermula. Jika skor rapat dan perbincangan tidak menyelesaikannya, pembuat keputusan memutuskan.

Perangkap Biasa

Menjemput terlalu banyak vendor. Tiga hingga lima adalah optimum. Lebih daripada lima, proses menjadi masalah pengisihan, bukan penilaian.

Menulis keperluan yang memihak kepada incumbent. Ini berlaku apabila orang yang menulis ringkasan keperluan telah melihat demo satu vendor dan secara tidak sedar mencerminkan cirinya sebagai "keperluan." Edarkan ringkasan kepada seseorang yang belum melihat demo manapun.

Melangkau skrip demo berstruktur. Demo bebas adalah pembentangan, bukan penilaian. Skrip berstruktur itulah yang menjadikan perbandingan mungkin.

Penilaian oleh jawatankuasa tanpa pengundi sama taraf. Jawatankuasa tanpa kuasa keputusan yang ditetapkan menghasilkan hasil konsensus-ke-tengah, bukan hasil terbaik. Namakan pengundi sama taraf terlebih dahulu.

Memulakan rundingan sebelum keputusan muktamad. Berunding dengan berbilang vendor secara serentak adalah sesuai hanya jika anda benar-benar ragu. Jika keputusan dibuat dan anda berunding untuk terma yang lebih baik sebelum menandatangani, katakan demikian. Itu adalah perbualan yang berbeza.

Templat Memo Keputusan

Sebelum menandatangani, dokumentasikan keputusan. Bukan laporan yang panjang: memo satu halaman yang merekodkan fakta utama. Analisis McKinsey tentang organisasi perolehan berprestasi tinggi mengenal pasti dokumentasi keputusan sebagai salah satu amalan paling konsisten yang memisahkan pasukan yang berjaya merasionalkan perbelanjaan perisian daripada yang tidak.

Keputusan: [Nama alat] dipilih untuk [kes penggunaan]
Tarikh: [Tarikh]
Pembuat keputusan: [Nama]
Penilai: [Nama]

Vendor yang dinilai: [Senarai]
Rasional pemilihan: [2-3 ayat tentang sebab vendor ini]
Terma utama: $[X]/tahun, [Y] lesen, tempoh [Z]-tahun
Garis masa pelaksanaan: [mula] hingga [tarikh go-live]
Metrik kejayaan pada 90 hari: [dari ringkasan keperluan]
Tarikh semakan: [90 hari dari go-live]

Alternatif yang dipertimbangkan:
- [Vendor B]: [1 ayat tentang sebab tidak dipilih]
- [Vendor C]: [1 ayat tentang sebab tidak dipilih]

Memo ini mengambil masa lima belas minit untuk ditulis. Ia mewujudkan rekod yang berguna pada semakan 90 hari, pada masa pembaharuan, dan jika keputusan perlu dipertahankan secara dalaman.

Menjalankan RFP dalam Rework Work Ops

Kebanyakan pasukan pasaran tengah cuba menjalankan RFP dari hamparan bersama dan saluran Slack, dan proses itu perlahan-lahan runtuh kerana tiada satu permukaan yang memegang ringkasan keperluan, senarai pendek vendor, kad skor, dan input penyemak silang fungsi. Rework Work Ops (dari $6/pengguna/bulan) memberikan pemilik RFP kanban khusus untuk menjalankan proses dari hujung ke hujung: papan dengan lajur untuk Senarai Pendek, Panggilan Saringan, Demo Dijadualkan, Kad Skor Belum Selesai, Finalis, dan Keputusan, dengan setiap vendor sebagai kad yang memegang respons bertulis, pautan rakaman demo, lampiran kad skor, dan tandatangan penyemak.

Kerana penilaian adalah langkah yang paling mudah gagal, Rework membolehkan anda membina templat kad skor berstruktur sekali dan menggunakannya pada setiap kad vendor, supaya penilai memberi skor secara bebas sebelum mesyuarat kumpulan, tiada berat sebelah penanda daripada utas Slack. Penyemak silang fungsi (IT, keselamatan, kewangan, pasukan pengguna akhir) ditanda terus pada kad vendor dan bukannya dihalakan melalui rantai kelulusan berasingan, yang biasanya merupakan tempat RFP pasaran tengah kehilangan minggu kedua dan ketiga mereka.

Soalan Lazim

Soalan Lazim Tentang Menjalankan RFP SaaS

Bilakah pembeli SaaS pasaran tengah perlu menjalankan RFP berbanding terus membeli?

Jalankan RFP apabila kontrak melebihi $25K setahun, apabila alat menyentuh berbilang pasukan, atau apabila kos penukaran akan tinggi (CRM, HRIS, kewangan teras). Untuk alat di bawah $15K setahun yang khusus untuk pasukan dan mudah ditarik keluar, bake-off 2-vendor atau percubaan 30 hari pilihan teratas anda adalah lebih pantas dan menghasilkan kualiti keputusan yang serupa. RFP menambah kos proses, gunakan apabila kos itu diwajarkan oleh saiz kontrak dan risiko penukaran.

Berapa banyak vendor yang sepatutnya ada dalam RFP?

Tiga hingga lima. Di bawah tiga, anda tidak mempunyai perbandingan sebenar; di atas lima, penilaian menjadi sukar diurus dan vendor memberikan respons generik kerana mereka tahu mereka adalah salah satu daripada ramai. Lima adalah siling praktikal untuk pasukan pasaran tengah yang menjalankan penilaian selari dengan kerja harian mereka.

Berapa lama kitaran RFP sepatutnya?

Tiga minggu untuk RFP SaaS pasaran tengah (satu minggu bagi setiap fasa: keperluan dan senarai pendek, demo, penilaian dan keputusan). Apa pun yang melebihi enam minggu menunjukkan proses sedang menjalankan pasukan dan bukannya pasukan menjalankan proses, dan pada ketika itu, momentum dan perhatian pihak berkepentingan mula terhakis lebih cepat daripada maklumat terkumpul.

Haruskah penetapan harga diberi skor dalam RFP?

Tidak, penetapan harga sepatutnya merupakan rundingan berasingan selepas keputusan teknikal dibuat. Memberi skor penetapan harga bersama keupayaan memihak penilaian kepada vendor yang lebih murah tetapi lebih lemah dan menetapkan kedudukan rundingan anda pada harga senarai. Simpan kad skor berfokus pada keupayaan, pilih pemenang, kemudian berunding. Jika vendor secara teknikal kuat tetapi dihargai 30% di atas had anda, itu adalah masalah rundingan, bukan masalah penilaian.

Apakah isyarat amaran RFP daripada respons vendor?

(1) Jawapan generik kepada soalan mesti ada yang tidak merujuk kes penggunaan khusus anda; (2) respons bertulis yang bercanggah dengan apa yang wakil kata semasa panggilan saringan; (3) enggan membuat komitmen terhadap garis masa pelaksanaan atau SLA secara bertulis; (4) pembentangan peringkat "enterprise" apabila anda meminta penetapan harga pasaran tengah; (5) tiada pengurus pelaksanaan atau kenalan customer success yang dinamakan untuk syarikat bersaiz anda; (6) persekitaran demo yang terhenti atau lambat pada senario anda.

Apakah kesilapan terbesar pembeli pasaran tengah buat dengan RFP?

Menulis keperluan yang secara tidak sedar mencerminkan set ciri incumbent. Inilah sebabnya incumbent memenangi 60-70% RFP, ringkasan keperluan dibina oleh seseorang yang telah mengetahui satu alat dengan mendalam, jadi "mesti ada" dibaca seperti senarai semak ciri alat itu. Penyelesaian: minta seseorang yang tidak pernah melihat demo mana-mana vendor untuk menyemak dan mencabar ringkasan keperluan sebelum ia dihantar. Jika tiga daripada lima mesti ada anda adalah perkara yang hanya incumbent lakukan, RFP telah diputuskan sebelum bermula.

Adakah kami memerlukan RFP formal jika kami sudah tahu vendor mana yang kami inginkan?

Jika anda 90%+ pasti dan kontrak di bawah $40K setahun, bake-off ringan 2-vendor dengan demo berstruktur biasanya mencukupi. Anda sedang mengesahkan keputusan intuisi, bukan menemui pilihan baharu. Jalankan RFP penuh apabila anda berhutang keputusan kepada pihak berkepentingan yang tidak ada dalam penemuan awal, apabila kontrak melebihi $50K setahun, atau apabila keputusan memerlukan rekod bertulis yang boleh dipertahankan untuk lembaga, audit, atau justifikasi pembaharuan masa depan.

Ketahui Lebih Lanjut