POC yang Memprediksi Keberhasilan: dan POC yang Membuang Waktu Semua Orang

Proof of concept harus menjawab satu pertanyaan: apakah produk ini akan memecahkan masalah spesifik kami di lingkungan spesifik kami? Dalam praktiknya, sebagian besar POC B2B menjawab pertanyaan yang berbeda: bisakah sales engineer vendor ini mempersiapkan demo yang bagus dengan logo kami?

Kesenjangan antara POC yang berguna dan yang teatrikal sangat besar. Pembeli yang tidak dapat membedakannya membuat keputusan mahal dengan data yang buruk. Mereka menemukan enam bulan pasca-kontrak bahwa kompleksitas integrasi yang dilewatkan semua orang selama evaluasi kini menjadi proyek IT enam minggu yang tidak dianggarkan siapa pun.

Ini bukan masalah etika vendor. Vendor membangun POC untuk menang, bukan untuk mengungkap mode kegagalan. Tanggung jawab untuk merancang evaluasi yang menghasilkan sinyal nyata ada pada pembeli. Riset Harvard Business Review tentang keputusan pembelian B2B telah lama mencatat bahwa pembeli yang mendefinisikan kriteria evaluasi di muka mencapai hasil jangka panjang yang lebih baik.

Lima Tanda POC Anda Adalah Teater

Sebelum merancang proses yang lebih baik, kenali seperti apa POC teatrikal itu. Pola-pola ini cukup umum sehingga sebagian besar pembeli menemui setidaknya dua atau tiga di antaranya dalam evaluasi besar mana pun.

Data yang dikontrol vendor. POC berjalan sepenuhnya pada data sampel vendor atau versi sanitasi milik Anda yang disiapkan vendor. Data Anda yang sebenarnya, dengan kasus tepi, ketidakkonsistenan historis, dan nama bidang non-standar, tidak pernah menyentuh sistem. Demo terlihat bersih karena datanya dikurasi untuk demo.

Tidak ada kriteria keberhasilan tertulis. Semua orang setuju sebelum POC bahwa Anda mengevaluasi "kemudahan penggunaan" dan "kemampuan integrasi." Tidak ada yang menulis apa artinya itu. Di akhir enam minggu, vendor bertanya bagaimana hasilnya dan champion menjawab "cukup baik", tetapi procurement dan IT memiliki ekspektasi yang sama sekali berbeda yang tidak pernah dimunculkan.

Vendor menjalankan semua sesi. POC yang berguna melibatkan tim Anda yang benar-benar menggunakan produk. POC teatrikal melibatkan sales engineer vendor yang mendemonstrasikan produk ke tim Anda setiap Selasa. Jika pengguna Anda belum mengerjakan pekerjaannya sendiri, Anda belum mengevaluasi kemudahan penggunaan. Anda mengevaluasi kemampuan vendor untuk presentasi.

Perluasan ruang lingkup tanpa penyesuaian timeline. POC dimulai sebagai evaluasi migrasi CRM. Pada minggu ketiga, vendor telah mengusulkan untuk juga mengevaluasi modul marketing automation mereka, karena "sudah disiapkan dan akan menunjukkan nilai platform secara penuh". Ruang lingkup sudah berlipat ganda. Timeline tidak berubah. Kedalaman evaluasi pada ruang lingkup awal terpotong setengahnya.

Tidak ada diskusi tentang seperti apa kegagalan. POC yang dirancang dengan baik mendefinisikan, di muka, hasil apa yang akan menyebabkan Anda tidak membeli. Jika semua orang bertindak seolah pembelian adalah satu-satunya hasil yang mungkin, Anda tidak sedang menjalankan evaluasi. Anda sedang menjalankan penutupan yang dikoreografikan.

Apa yang Perlu Didefinisikan POC yang Berguna di Muka

Prediktor tunggal terbesar dari kualitas POC adalah apakah pembeli menulis brief desain POC sebelum sesi kick-off vendor pertama. Sebagian besar tidak. Inilah yang harus dimuat brief tersebut.

Kriteria keberhasilan tertulis. Bukan "kami ingin melihat apakah mudah digunakan." Kriteria tertulis terlihat seperti: "Orientasi pengguna: 80% pengguna pilot menyelesaikan workflow inti pertama mereka tanpa intervensi dukungan dalam 5 hari kerja." Atau: "Integrasi CRM: semua perubahan tahap deal di CRM sumber tercermin di platform ini dalam 15 menit, divalidasi selama periode observasi 10 hari." Ini dapat difalsifikasi. Hasilnya lulus atau gagal. Anda tidak perlu memperdebatkan apakah kriteria itu terpenuhi.

Data nyata, bukan data demo. Data Anda yang sebenarnya adalah uji stres terbaik. Jika vendor membutuhkan waktu untuk memahami struktur data Anda sebelum POC dimulai, itu tidak masalah, tetapi POC itu sendiri harus berjalan pada sampel representatif dari data nyata Anda, termasuk bagian yang paling berantakan. Pertanyaan integrasi apa pun yang muncul dalam proses ini akan muncul pasca-kontrak juga. Lebih baik menemukannya di minggu kedua daripada minggu kesepuluh setelah go-live. Panduan pembersihan dan deduplikasi data adalah latihan pra-POC yang berguna: data yang bersih mengungkap masalah integrasi nyata lebih cepat daripada data berantakan menyembunyikannya.

Definisi ruang lingkup integrasi. Sebelum POC dimulai, daftarkan setiap sistem yang perlu dihubungkan alat ini. Bukan "mungkin suatu hari nanti". Daftarkan hanya integrasi yang diperlukan agar kasus penggunaan baseline berfungsi. Untuk setiap integrasi, tentukan siapa pemiliknya (IT, vendor, atau bersama) dan apa kriteria penerimaannya. Ini mengungkap kompleksitas integrasi tersembunyi yang kelak mematikan kesepakatan (dan implementasi).

Timeline keputusan. POC memiliki tanggal akhir, dan tanggal akhir tersebut adalah saat komite pembelian berkumpul kembali untuk membuat keputusan berdasarkan hasil POC. Bukan "panggilan debrief" untuk merencanakan langkah berikutnya. Rapat keputusan. Jika rapat ditunda, POC diperpanjang sesuai, tetapi ekspektasi bahwa keputusan mengikuti evaluasi ditetapkan sejak awal.

Peran dan tanggung jawab. Siapa di pihak Anda yang memiliki POC? Siapa kontak utama vendor? Siapa di tim Anda yang bertanggung jawab menjalankan workflow pilot? Ini penting karena POC gagal secara operasional ketika tidak ada pemilik yang jelas di sisi pembeli dan evaluasi berjalan di latar belakang sementara pekerjaan sebenarnya semua orang terus berjalan.

Masalah Insentif Vendor

Vendor Anda ingin POC berhasil. Definisi "sukses" mereka dan milik Anda mungkin tidak selaras. Itu tidak tidak jujur. Itu rasional.

Vendor mendefinisikan keberhasilan POC sebagai kesepakatan yang tertutup. Anda mendefinisikan keberhasilan POC sebagai jawaban akurat atas pertanyaan "apakah ini akan berhasil untuk kami?" Itu tujuan yang berbeda, dan keduanya menciptakan perilaku yang berbeda.

Vendor akan:

• Mengarahkan Anda ke fitur yang bekerja dengan baik dan jauh dari kasus penggunaan yang mengungkap batasan
• Menyelesaikan pemblokir dengan cepat selama POC yang akan membutuhkan berminggu-minggu pasca-kontrak
• Menyediakan sumber daya dukungan khusus selama evaluasi yang tidak tersedia untuk pelanggan normal
• Membingkai kompleksitas integrasi dengan optimis karena sales engineer yakin hal itu dapat diselesaikan (tim implementasi akan menemukan sebaliknya)

Ini terutama terlihat dalam POC CRM. Perbandingan seperti Rework vs. HubSpot CRM dapat mengungkap perbedaan kemampuan struktural yang cenderung diremehkan vendor selama demo.

Tidak satu pun dari ini adalah kebohongan. Ini adalah konsekuensi alami dari vendor yang menurunkan sumber daya terbaik dan orang paling berpengalaman pada evaluasi bertaruhan tinggi. Pasca-kontrak, Anda adalah pelanggan biasa.

Implikasinya adalah Anda harus secara aktif mencoba menekan POC, bukan menerima jalur dengan hambatan paling kecil. Gunakan data Anda yang paling berantakan. Tanyakan tentang kasus penggunaan yang paling tidak Anda yakini akan berhasil. Minta percakapan dengan pelanggan referensi yang pernah menghadapi tantangan integrasi serupa. Temukan pelanggan referensi secara independen melalui komunitas atau jaringan Anda, bukan yang dikurasi oleh tim customer success vendor.

Tiga Kegagalan POC yang Paling Umum

Tiga mode kegagalan berulang kali melemahkan sinyal yang seharusnya dihasilkan POC.

Scope creep tanpa penyesuaian timeline. Ini sudah disebut dalam diagnosis teater, tetapi layak diperluas. Scope creep dalam POC hampir selalu berniat baik. Vendor melihat peluang untuk menunjukkan lebih banyak nilai. Champion Anda ingin mengevaluasi kemampuan yang awalnya tidak mereka rencanakan. Seseorang di komite bertanya "bisakah kita juga melihat bagaimana ini menangani X?" Setiap tambahan ruang lingkup individu terasa masuk akal. Tapi efek kumulatifnya adalah evaluasi yang mencakup segalanya dengan dangkal daripada kasus penggunaan asli secara mendalam.

Solusi: setiap penambahan ruang lingkup setelah brief desain POC ditandatangani memerlukan amandemen tertulis yang memperpanjang timeline sesuai. Tidak ada perluasan gratis.

Drift kriteria keberhasilan. POC dimulai dengan kriteria yang jelas. Tiga minggu kemudian, vendor belum memenuhi kriteria integrasi. Percakapan terjadi. Kriteria diubah menjadi "aspirasional" atau "fase dua." Pada akhir POC, kriteria awal telah digantikan oleh narasi yang lebih lunak tentang "sinyal yang menjanjikan" dan "roadmap implementasi."

Solusi: kriteria keberhasilan awal dikunci setelah brief POC ditandatangani. Kriteria dapat diamandemen secara formal oleh komite pembelian, tetapi vendor tidak dapat menegosiasikannya ulang secara sepihak melalui percakapan informal dengan champion.

Kepergian champion selama evaluasi. Orang yang merancang POC meninggalkan perusahaan, ditarik ke proyek prioritas lebih tinggi, atau dipromosikan ke peran di mana mereka tidak lagi memiliki keputusan ini. POC berlanjut tanpa pengetahuan institusionalnya. Pemilik evaluasi yang baru tidak menulis brief, tidak memahami kriteria keberhasilan awal, dan rentan terhadap pembingkaian ulang yang diarahkan vendor.

Solusi: POC memiliki dua pemilik internal, bukan satu. Pemilik cadangan diberi pengarahan tentang kriteria dan pendekatan sejak awal. Jika pemilik utama pergi, evaluasi tidak dimulai dari nol.

Template Brief Desain POC

Gunakan struktur satu halaman ini sebelum POC vendor apa pun dimulai.

1. Pernyataan masalah bisnis. Satu paragraf: masalah operasional atau pendapatan spesifik apa yang kami coba selesaikan? Bukan "kami ingin pelaporan yang lebih baik". Sesuatu yang spesifik, seperti: "tim penjualan kami menghabiskan 6 jam per minggu merekonsiliasi data pipeline secara manual antara CRM dan alat forecasting kami, dan hasilnya adalah error forecast rata-rata 22%."

2. Kriteria keberhasilan (tertulis). Tiga hingga lima kriteria, masing-masing dapat difalsifikasi. Untuk masing-masing: apa yang kami ukur, bagaimana kami mengukurnya, dan ambang batas yang merupakan keberhasilan.

3. Persyaratan integrasi. Setiap koneksi sistem yang diperlukan untuk kasus penggunaan baseline. Pemilik dan kriteria penerimaan untuk masing-masing.

4. Ruang lingkup pilot. Tim mana, berapa banyak pengguna, workflow mana. Apa yang akan mereka lakukan selama POC, dalam pekerjaan normal mereka, menggunakan data nyata.

5. Timeline. Tanggal mulai, tanggal akhir, tonggak check-in kunci. Tanggal rapat keputusan ditetapkan sebelum POC dimulai.

6. Klausul kegagalan. Satu paragraf: hasil apa yang akan menyebabkan kami tidak melanjutkan? Ini adalah bagian paling berguna dan yang paling sering dilewati pembeli. Menuliskannya memaksa kejelasan tentang apa yang sebenarnya Anda khawatirkan.

7. Peran. Pemilik evaluasi utama dan cadangan. Pemilik integrasi IT. Daftar pembuat keputusan untuk tinjauan akhir.

Lima Kriteria Keberhasilan yang Harus Dimiliki Setiap POC Perangkat Lunak

Terlepas dari kategori, lima kriteria ini harus muncul dalam beberapa bentuk dalam setiap POC perangkat lunak enterprise:

Tingkat penyelesaian workflow inti. Bisakah pengguna menyelesaikan workflow yang dimaksud secara independen, tanpa dukungan vendor, dalam periode pilot? Tetapkan ambang batas: penyelesaian 80% pada hari ke-10 adalah titik awal yang wajar.

Latensi dan keandalan integrasi. Untuk setiap integrasi yang diperlukan: data disinkronkan dalam jendela yang ditentukan (misalnya, 15 menit) pada tingkat keandalan yang ditentukan (misalnya, 99%+ selama periode POC). Uji ini secara aktif, bukan dengan bertanya kepada vendor.

Penanganan kasus tepi. Identifikasi tiga hingga lima kasus penggunaan yang mewakili situasi non-standar di lingkungan Anda. Jalankan secara eksplisit selama POC. Jika alat tidak menangani kasus tepi Anda, Anda akan mengetahuinya pasca-kontrak kecuali Anda mengujinya sekarang.

Kualitas respons dukungan. Kirimkan permintaan dukungan nyata selama POC, bukan yang mudah. Seberapa lama waktu untuk mendapatkan respons yang substantif? Siapa yang merespons? Apakah jawabannya akurat secara teknis? Kualitas dukungan pasca-kontrak sering kali menjadi dimensi yang paling kurang dievaluasi dari pembelian perangkat lunak enterprise, dan ini adalah salah satu sinyal terjelas dalam rollout implementasi CRM apa pun.

Validasi portabilitas data. Sebelum POC berakhir, ekspor data Anda dari sistem. Pastikan Anda dapat mengekspor semua yang Anda masukkan, dalam format yang benar-benar dapat Anda gunakan. Pertanyaan vendor lock-in lebih mudah dievaluasi dengan kontrak yang kosong daripada database yang penuh. Laporan B2B Buying Disconnect TrustRadius secara konsisten menemukan bahwa portabilitas data dan kualitas integrasi adalah faktor teratas yang ingin dievaluasi pembeli lebih ketat sebelum berkomitmen.

Seperti Apa yang Baik

POC yang menghasilkan sinyal pembelian yang andal berbagi beberapa karakteristik. Mereka pendek: empat hingga enam minggu, bukan tanpa batas waktu. Mereka berjalan pada data dan workflow nyata. Kriteria keberhasilan ditulis sebelum sales engineer vendor bergabung dalam panggilan pertama. Pemilik evaluasi memiliki otoritas untuk mengatakan tidak, dan semua orang di komite pembelian mengetahuinya.

Mereka juga dijalankan pembeli, bukan vendor. Vendor mendukung. Pembeli mengemudikan. Itu perbedaan operasional yang berarti, dan sebagian besar pembeli harus menetapkannya dengan sengaja karena vendor akan mengisi kekosongan jika Anda membiarkannya. Model kematangan RevOps menggambarkan bagaimana kesiapan organisasi tersebut terlihat pada berbagai tahap: fungsi RevOps level 3 atau lebih tinggi biasanya menjalankan POC yang jauh lebih terstruktur daripada tim yang berada lebih awal dalam progresi tersebut. Riset pembelian teknologi Forrester memperkuat ini: evaluasi yang terstruktur dan dikontrol pembeli menghasilkan skor kepuasan yang jauh lebih tinggi 12 bulan pasca-implementasi daripada yang dipandu vendor.

POC yang mengungkap masalah nyata sebelum kontrak adalah hadiah. Sebagian besar pembeli tidak melihatnya seperti itu pada saat itu. Mereka melihat evaluasi bermasalah yang mempersulit kesepakatan yang ingin mereka tutup. Tapi alternatifnya selalu lebih mahal: menandatangani kontrak dan menemukan masalah itu selama implementasi jauh lebih mengganggu daripada mengungkapnya selama evaluasi.

Pelajari Lebih Lanjut

• Komite Pembelian B2B Baru: Siapa yang Benar-Benar Ada di Ruangan, para pemangku kepentingan yang perlu menyetujui hasil POC Anda
• Biaya Sebenarnya Software Sprawl di Perusahaan Mid-Market, apa yang terjadi ketika jalan pintas POC menyebabkan utang integrasi dalam skala besar