POC yang Meramalkan Kejayaan — dan POC yang Membazirkan Masa Semua Orang

Bukti konsep (proof of concept) sepatutnya menjawab satu soalan: adakah produk ini akan menyelesaikan masalah khusus kami dalam persekitaran khusus kami? Dalam amalan, kebanyakan POC B2B menjawab soalan berbeza: bolehkah jurutera jualan vendor ini membuat demo yang baik dengan logo kami?

Jurang antara POC yang berguna dan yang bersifat teatrikal adalah besar. Pembeli yang tidak dapat membezakannya membuat keputusan mahal dengan data yang lemah. Mereka mendapati enam bulan selepas kontrak bahawa kerumitan integrasi yang semua orang gloskan semasa penilaian kini merupakan projek IT enam minggu yang tiada siapa anggarkan.

Ini bukan masalah etika vendor. Vendor membina POC untuk menang, bukan untuk menampakkan kegagalan. Tanggungjawab untuk mereka bentuk penilaian yang menjana isyarat sebenar terletak pada pembeli. Penyelidikan Harvard Business Review tentang keputusan pembelian B2B telah lama mencatat bahawa pembeli yang mentakrifkan kriteria penilaian terlebih dahulu mencapai hasil jangka panjang yang lebih baik berbanding mereka yang bergantung pada demonstrasi yang dipimpin vendor.

Lima Tanda POC Anda Adalah Teater

Sebelum mereka bentuk proses yang lebih baik, kenali rupa POC yang bersifat teatrikal. Corak ini cukup biasa sehingga kebanyakan pembeli menemui sekurang-kurangnya dua atau tiga dalam mana-mana penilaian besar.

Data yang dikawal vendor. POC dijalankan sepenuhnya pada data sampel vendor atau versi data anda yang telah disanitasi yang vendor sediakan. Data sebenar anda, dengan kes tepi, ketidakkonsistenan sejarah, dan nama medan yang tidak standard, tidak pernah menyentuh sistem. Demo kelihatan bersih kerana data telah dikurasi untuk demo.

Tiada kriteria kejayaan bertulis. Semua orang bersetuju sebelum POC bahawa anda menilai "kemudahan penggunaan" dan "keupayaan integrasi." Tiada siapa menulis apa maksudnya. Pada akhir enam minggu, vendor bertanya bagaimana keadaannya dan champion berkata "agak baik," tetapi procurement dan IT mempunyai jangkaan yang sama sekali berbeza yang tidak pernah diangkat.

Vendor menjalankan semua sesi. POC yang berguna melibatkan pasukan anda sebenarnya menggunakan produk. POC teatrikal melibatkan jurutera jualan vendor menunjukkan produk kepada pasukan anda setiap Selasa. Jika pengguna anda belum melakukan kerja sendiri, anda belum menilai kebolehgunaan. Anda telah menilai keupayaan vendor untuk membentang.

Pengembangan skop tanpa pelarasan jadual. POC bermula sebagai penilaian migrasi CRM. Pada minggu ketiga, vendor telah mencadangkan untuk juga menilai modul automasi pemasaran mereka, kerana "ia sudah disediakan dan ia akan menunjukkan nilai platform penuh." Skop telah berganda. Jadual tidak berubah. Kedalaman penilaian pada skop asal telah dipotong separuh.

Tiada perbincangan tentang rupa kegagalan. POC yang direka dengan baik mentakrifkan, terlebih dahulu, hasil apakah yang akan menyebabkan anda tidak membeli. Jika semua orang beroperasi seolah-olah pembelian adalah satu-satunya hasil yang mungkin, anda tidak menjalankan penilaian. Anda menjalankan penutupan yang dikoreografi.

Apa yang POC Berguna Perlu Takrifkan Terlebih Dahulu

Satu peramal terbesar kualiti POC ialah sama ada pembeli menulis ringkasan reka bentuk POC sebelum sesi kickoff vendor pertama. Kebanyakan tidak. Inilah yang perlu ada dalam ringkasan itu.

Kriteria kejayaan bertulis. Bukan "kami ingin melihat sama ada ia mudah digunakan." Kriteria bertulis kelihatan seperti: "Onboarding pengguna: 80% pengguna pilot melengkapkan aliran kerja teras pertama mereka tanpa campur tangan sokongan dalam masa 5 hari perniagaan." Atau: "Integrasi CRM: semua perubahan peringkat deal dalam CRM sumber mencerminkan dalam platform ini dalam masa 15 minit, disahkan sepanjang tempoh pemerhatian 10 hari." Ini boleh dibuktikan salah. Ia lulus atau gagal. Anda tidak perlu berdebat sama ada ia lulus.

Data sebenar, bukan data demo. Data sebenar anda adalah ujian tekanan terbaik. Jika vendor memerlukan masa untuk memahami struktur data anda sebelum POC bermula, tidak mengapa, tetapi POC itu sendiri harus dijalankan pada sampel representatif data sebenar anda, termasuk bahagian yang paling tidak kemas. Sebarang soalan integrasi yang muncul semasa proses ini akan muncul selepas kontrak juga. Lebih baik menemuinya pada minggu kedua berbanding minggu kesepuluh selepas go-live. Panduan pembersihan data dan deduplikasi adalah senaman pra-POC yang berguna — data yang bersih mendedahkan masalah integrasi sebenar lebih cepat daripada data yang tidak kemas menyembunyikannya.

Takrifan skop integrasi. Sebelum POC bermula, senaraikan setiap sistem yang alat ini perlu sambung. Bukan "mungkin suatu hari nanti." Senaraikan hanya integrasi yang diperlukan untuk kes penggunaan asas berfungsi. Untuk setiap integrasi, takrifkan siapa yang memilikinya (IT, vendor, atau dikongsi) dan apakah kriteria penerimaannya. Ini mendedahkan kerumitan integrasi tersembunyi yang membunuh deal (dan pelaksanaan) kemudian.

Jadual keputusan. POC mempunyai tarikh tamat, dan tarikh tamat itu adalah apabila jawatankuasa pembelian berkumpul semula untuk membuat keputusan berdasarkan keputusan POC. Bukan "panggilan debrief" untuk merancang langkah seterusnya. Mesyuarat keputusan. Jika mesyuarat ditangguhkan, POC dilanjutkan sewajarnya — tetapi jangkaan bahawa keputusan mengikuti penilaian ditetapkan pada permulaan.

Peranan dan tanggungjawab. Siapa di pihak anda yang memiliki POC? Siapa kenalan utama vendor? Siapa dalam pasukan anda yang bertanggungjawab menjalankan aliran kerja pilot? Ini penting kerana POC gagal secara operasi apabila tiada siapa di pihak pembeli mempunyai pemilikan yang jelas dan penilaian berjalan di latar belakang sementara kerja sebenar semua orang terus bergerak.

Masalah Insentif Vendor

Berikut adalah sesuatu yang kebanyakan panduan pembelian tidak katakan secara langsung: vendor anda mahu POC berjaya. Itu bukan tidak jujur. Itu rasional. Tetapi takrifan "kejayaan" mereka dan anda mungkin tidak sejajar.

Vendor mentakrifkan kejayaan POC sebagai deal yang ditutup. Anda mentakrifkan kejayaan POC sebagai jawapan tepat kepada soalan "adakah ini akan berfungsi untuk kami?" Ini adalah objektif yang berbeza, dan mereka mewujudkan tingkah laku yang berbeza.

Vendor akan:

  • Membimbing anda ke arah ciri yang berfungsi dengan baik dan menjauhi kes penggunaan yang mendedahkan had
  • Menyelesaikan pemblokir dengan cepat semasa POC yang akan mengambil masa berminggu-minggu selepas kontrak
  • Menyediakan sumber sokongan khusus semasa penilaian yang tidak tersedia untuk pelanggan biasa
  • Membingkai kerumitan integrasi secara optimistik kerana jurutera jualan yakin ia boleh diselesaikan (pasukan pelaksanaan akan mendapatinya sebaliknya)

Ini amat ketara dalam POC CRM. Perbandingan seperti Rework vs. HubSpot CRM boleh mendedahkan perbezaan keupayaan struktur yang vendor cenderung meremehkan semasa demo.

Tiada satupun ini pembohongan. Ia adalah akibat semula jadi vendor menggunakan sumber terbaik dan orang paling berpengalaman mereka dalam penilaian berisiko tinggi. Selepas kontrak, anda adalah pelanggan biasa.

Implikasinya adalah anda harus secara aktif cuba tekanan ujian POC, bukan menerima laluan yang paling kurang rintangan. Gunakan data anda yang paling tidak kemas. Tanya tentang kes penggunaan yang anda paling tidak pasti akan berfungsi. Minta perbualan dengan rujukan pelanggan yang mempunyai cabaran integrasi yang serupa. Cari satu secara bebas melalui komuniti atau rangkaian anda, bukan yang dikurasi oleh pasukan kejayaan pelanggan vendor.

Tiga Kegagalan POC Paling Biasa

Pengembangan skop tanpa pelarasan jadual. Ini telah disebut dalam diagnosis teater, tetapi ia memerlukan pengembangan. Pengembangan skop dalam POC hampir selalu dengan niat baik. Vendor melihat peluang untuk menunjukkan lebih banyak nilai. Champion anda ingin menilai keupayaan yang mereka tidak rancang pada mulanya. Seseorang dalam jawatankuasa bertanya "bolehkah kita juga lihat cara ia mengendalikan X?" Setiap permintaan individu kelihatan munasabah. Tetapi kesan kumulatifnya adalah penilaian yang meliputi segalanya dengan cetek dan bukannya kes penggunaan asal secara mendalam.

Penyelesaian: sebarang penambahan skop selepas ringkasan reka bentuk POC ditandatangani memerlukan pindaan bertulis yang melanjutkan jadual sewajarnya. Tiada pengembangan percuma.

Hanyutan kriteria kejayaan. POC bermula dengan kriteria yang jelas. Tiga minggu kemudian, vendor tidak memenuhi kriteria integrasi. Perbualan berlaku. Kriteria dibingkai semula sebagai "aspirasional" atau "fasa dua." Menjelang akhir POC, kriteria asal telah digantikan oleh naratif yang lebih lembut tentang "isyarat menjanjikan" dan "peta jalan pelaksanaan."

Penyelesaian: kriteria kejayaan asal dikunci setelah ringkasan POC ditandatangani. Ia boleh dipinda secara rasmi oleh jawatankuasa pembelian, tetapi vendor tidak boleh berunding semula secara unilateral melalui perbualan tidak rasmi dengan champion.

Pemergian champion semasa penilaian. Orang yang mereka bentuk POC meninggalkan syarikat, diambil untuk projek keutamaan lebih tinggi, atau dinaikkan pangkat ke peranan di mana mereka tidak lagi memiliki keputusan ini. POC berterusan tanpa pengetahuan institusinya. Pemilik penilaian baru tidak menulis ringkasan, tidak memahami kriteria kejayaan asal, dan terdedah kepada pembingkaian semula yang dipimpin vendor.

Penyelesaian: POC mempunyai dua pemilik dalaman, bukan satu. Pemilik sandaran dibriefing tentang kriteria dan pendekatan pada permulaan. Jika pemilik utama pergi, penilaian tidak bermula dari awal.

Templat Ringkasan Reka Bentuk POC

Gunakan struktur satu halaman ini sebelum mana-mana POC vendor bermula.

1. Penyataan masalah perniagaan. Satu perenggan: masalah operasi atau hasil khusus apa yang kami cuba selesaikan? Bukan "kami mahu pelaporan yang lebih baik." Sesuatu yang khusus, seperti: "pasukan jualan kami menghabiskan 6 jam seminggu secara manual menyelaraskan data pipeline antara CRM kami dan alat ramalan kami, dan hasilnya adalah ralat ramalan yang purata 22%."

2. Kriteria kejayaan (bertulis). Tiga hingga lima kriteria, setiap satu boleh dibuktikan salah. Untuk setiap satu: apa yang kami ukur, cara kami mengukurnya, dan ambang yang membentuk kejayaan.

3. Keperluan integrasi. Setiap sambungan sistem yang diperlukan untuk kes penggunaan asas. Pemilik dan kriteria penerimaan untuk setiap satu.

4. Skop pilot. Pasukan mana, berapa ramai pengguna, aliran kerja mana. Apa yang akan mereka lakukan semasa POC, dalam kerja biasa mereka, menggunakan data sebenar.

5. Jadual. Tarikh mula, tarikh tamat, pencapaian check-in utama. Tarikh mesyuarat keputusan ditetapkan sebelum POC bermula.

6. Klausa kegagalan. Satu perenggan: hasil apa yang akan menyebabkan kami tidak meneruskan? Ini adalah bahagian yang paling berguna dan yang paling banyak pembeli langkau. Menulisnya memaksa kejelasan tentang apa yang sebenarnya anda bimbangkan.

7. Peranan. Pemilik penilaian utama dan sandaran. Kenalan utama vendor. Pemilik integrasi IT. Senarai pembuat keputusan untuk ulasan akhir.

Lima Kriteria Kejayaan yang Setiap POC Perisian Patut Ada

Tanpa mengira kategori, lima kriteria ini harus muncul dalam beberapa bentuk dalam setiap POC perisian enterprise:

Kadar penyelesaian aliran kerja teras. Bolehkah pengguna melengkapkan aliran kerja yang dimaksudkan secara bebas, tanpa sokongan vendor, dalam tempoh pilot? Tetapkan ambang: 80% penyelesaian menjelang hari ke-10 adalah titik permulaan yang munasabah.

Latency dan kebolehpercayaan integrasi. Untuk setiap integrasi yang diperlukan: data disinkronkan dalam tetingkap yang ditakrifkan (cth., 15 minit) pada kadar kebolehpercayaan yang ditakrifkan (cth., 99%+ sepanjang tempoh POC). Uji ini secara aktif, bukan dengan bertanya kepada vendor.

Pengendalian kes tepi. Kenal pasti tiga hingga lima kes penggunaan yang mewakili situasi bukan standard dalam persekitaran anda. Jalankan ia secara eksplisit semasa POC. Jika alat tidak mengendalikan kes tepi anda, anda akan tahu selepas kontrak melainkan anda mengujinya sekarang.

Kualiti respons sokongan. Serahkan permintaan sokongan sebenar semasa POC, bukan yang mudah. Berapa lama untuk mendapatkan respons substantif? Siapa yang menjawab? Adakah jawapannya tepat secara teknikal? Kualiti sokongan selepas kontrak sering merupakan dimensi paling kurang dinilai dalam pembelian perisian enterprise — dan ia adalah salah satu isyarat paling jelas dalam mana-mana pelaksanaan rollout CRM.

Pengesahan portabiliti data. Sebelum POC tamat, eksport data anda dari sistem. Sahkan anda boleh mengeksport semua yang anda masukkan, dalam format yang boleh anda gunakan sebenarnya. Soalan penguncian vendor lebih mudah dinilai dengan kontrak kosong berbanding pangkalan data penuh. Laporan TrustRadius B2B Buying Disconnect secara konsisten mendapati portabiliti data dan kualiti integrasi antara faktor teratas yang pembeli inginkan mereka penilaikan dengan lebih teliti sebelum berkomitmen.

Rupa Seperti Baik

POC yang menjana isyarat pembelian yang boleh dipercayai berkongsi beberapa ciri. Ia pendek: empat hingga enam minggu, bukan terbuka. Ia dijalankan pada data dan aliran kerja sebenar. Kriteria kejayaan ditulis sebelum jurutera jualan vendor menyertai panggilan pertama. Pemilik penilaian mempunyai kuasa untuk berkata tidak, dan semua orang dalam jawatankuasa pembelian mengetahuinya. Model kematangan RevOps menerangkan rupa kesediaan organisasi pada peringkat berbeza — fungsi RevOps peringkat 3 atau lebih tinggi biasanya menjalankan POC yang jauh lebih berstruktur berbanding pasukan yang lebih awal dalam perkembangan itu.

Ia juga dipimpin pembeli, bukan dipimpin vendor. Vendor menyokong. Pembeli memandu. Itu adalah perbezaan operasi yang bermakna, dan ia adalah sesuatu yang kebanyakan pembeli perlu tetapkan dengan sengaja kerana vendor akan mengisi ruang kosong jika anda membiarkan mereka. Penyelidikan pembelian teknologi Forrester mengukuhkan ini: penilaian berstruktur yang dikawal pembeli menghasilkan skor kepuasan yang jauh lebih tinggi 12 bulan selepas pelaksanaan berbanding yang dipimpin vendor.

POC yang mendedahkan masalah sebenar sebelum kontrak adalah hadiah. Kebanyakan pembeli tidak melihatnya seperti itu pada masa itu. Mereka melihat penilaian yang bermasalah yang merumitkan deal yang mereka ingin tutup. Tetapi alternatifnya selalu lebih mahal: menandatangani kontrak dan menemui masalah tersebut semasa pelaksanaan lebih mengganggu berbanding mendedahkannya semasa penilaian.

Ketahui Lebih Lanjut