RevOps Build vs Buy: Cara Membuat Keputusan Alat Hasil

Keputusan alat RevOps perlu bermula dengan masalah operasi, bukan kategori vendor.

Bina apabila aliran kerja bersifat strategik, spesifik, dan sukar disokong oleh alat sedia ada. Beli apabila kategori sudah matang, proses adalah standard, dan kos integrasi boleh diterima.

Kajian Forrester mengenai penjajaran teknologi RevOps berguna kerana keputusan build-vs-buy menjejaskan keseluruhan enjin hasil, bukan hanya satu pasukan. Panduan Gartner mengenai pengurangan kerumitan pengupayaan turut relevan kerana keputusan alat yang salah boleh menambah lebih banyak beban aliran kerja berbanding yang dihapuskannya.

Fakta operasi utama

• Build-vs-buy perlu bermula dengan masalah aliran kerja, model data, pemilikan, dan laluan penyelenggaraan, bukan dengan demo vendor atau prototaip dalaman.
• Konfigurasikan dahulu apabila sistem semasa boleh menyokong aliran kerja dengan bersih. Beli apabila pasaran menyelesaikan masalah itu dengan baik. Bina apabila aliran kerja bersifat strategik, spesifik, dan berbaloi untuk dimiliki dalam jangka panjang.
• Kos integrasi dan penerimaan selalunya lebih penting daripada harga langganan. Alat yang murah boleh menjadi mahal jika ia mencipta data pendua, beban admin, atau tingkah laku pengguna yang lemah.
• Setiap keputusan perlu menyertakan laluan penamatan. RevOps perlu tahu bagaimana data, aliran kerja, dan laporan akan terus berfungsi jika alat itu kelak digantikan.

Jadual keputusan

Soalan yang perlu ditanya

• Adakah proses ini jelas?
• Adakah aliran kerja ini pembeza (differentiator)?
• Data apa yang perlu disegerakkan?
• Siapa yang menyelenggaranya?
• Apa akan berlaku apabila proses berubah?
• Apakah kos terikat kepada satu vendor (vendor lock-in)?

Kaitkan ini dengan Revenue Tech Stack.

Mulakan dengan masalah

Tuliskan masalah dalam bahasa operasi.

Kenyataan masalah yang lemah: "Kita perlukan alat yang lebih baik."

Kenyataan masalah yang lebih baik: "Penghalaan lead adalah perlahan kerana pemadanan akaun, logik wilayah, dan peraturan kapasiti dikendalikan secara manual. Ini menyebabkan tindak balas lewat dan pemilikan yang tidak konsisten."

Kenyataan kedua memudahkan keputusan. Pasukan boleh menilai sama ada hendak mengkonfigurasi CRM, membeli alat penghalaan, mengintegrasikan pengayaan data, atau membina logik khas.

Build-vs-buy tidak sepatutnya bermula dengan demo. Ia perlu bermula dengan aliran kerja, data, pengguna, pemilik, dan keputusan yang perlu disokong oleh sistem.

Empat pilihan

RevOps biasanya mempunyai empat pilihan:

Jawapan yang betul mungkin menggabungkan beberapa pilihan. Contohnya, konfigurasikan medan CRM, beli pengayaan data, integrasikan data akaun, dan bina lapisan penghalaan kecil.

Kriteria keputusan

Nilai:

• Kepentingan strategik
• Keunikan aliran kerja
• Kematangan vendor
• Kerumitan integrasi
• Pemilikan data
• Keperluan keselamatan
• Penyelenggaraan admin
• Penerimaan pengguna
• Keperluan pelaporan
• Kekerapan perubahan
• Jumlah kos
• Masa untuk nilai (time to value)

Jangan nilai berdasarkan kos langganan sahaja. Alat yang murah dengan kos integrasi dan admin yang tinggi boleh menjadi mahal. Pembinaan khas tanpa pemilik penyelenggaraan boleh menjadi liabiliti tersembunyi.

Bila hendak mengkonfigurasi

Konfigurasikan alat sedia ada apabila aliran kerja hampir sama dengan yang standard.

Contoh:

• Menambah medan wajib berdasarkan peringkat
• Mencipta amaran kebersihan ramalan
• Membina dashboard pengurus
• Menambah tugas serah tugas
• Mencipta aliran kelulusan
• Menyesuaikan paparan pipeline

Konfigurasi selalunya laluan paling pantas. Tetapi konfigurasi memerlukan tadbir urus. Terlalu banyak medan, aliran kerja, dan pengecualian boleh mengubah CRM menjadi sistem khas yang rapuh.

Bila hendak membeli

Beli apabila keperluan adalah lazim dan vendor menyelesaikannya dengan baik.

Contoh:

• Sales engagement
• Automasi pemasaran
• Pengayaan data
• Alat kualiti data
• Platform kejayaan pelanggan
• Alat BI
• Rakaman panggilan

Membeli boleh mengurangkan masa pembinaan dan menyediakan sokongan vendor berterusan. Pertukaran gantinya ialah integrasi, kos, kesesuaian model data, dan pergantungan kepada roadmap vendor.

Bila hendak mengintegrasikan

Integrasikan apabila syarikat sudah mempunyai sistem yang kukuh tetapi memerlukan data bersama.

Contoh:

• Data pengebilan ke dalam CRM
• Penggunaan produk ke dalam platform CS
• Sumber pemasaran ke dalam pelaporan opportunity
• Isyarat sokongan ke dalam risiko pembaharuan
• Pemilikan CRM ke dalam logik penghalaan

Integrasi perlu mempunyai tujuan perniagaan. Menyegerakkan data hanya kerana ia tersedia mencipta kekacauan dan titik kegagalan.

Bila hendak membina

Bina apabila aliran kerja bersifat strategik, spesifik, dan berbaloi untuk diselenggara.

Contoh:

• Logik penghalaan khas yang terikat kepada kapasiti dan wilayah
• Model perancangan hasil dalaman
• Penjana pakej ramalan khusus
• Model pemarkahan pelanggan proprietari
• Aliran kerja yang membezakan perniagaan

Sebelum membina, sahkan:

• Siapa yang menyelenggaranya?
• Apa akan berlaku apabila proses berubah?
• Di mana data disimpan?
• Bagaimana ia dipantau?
• Bagaimana ralat dikendalikan?
• Apakah pelan rollback?

Keputusan pembinaan mencipta pemilikan jangka panjang.

Jumlah kos pemilikan

Sertakan:

• Langganan
• Pelaksanaan
• Integrasi
• Migrasi
• Masa admin
• Latihan
• Sokongan
• Semakan keselamatan
• Perubahan pelaporan
• Kos pembaharuan
• Penyelenggaraan
• Penamatan penggunaan (decommissioning)

Jumlah kos tidak selalu jelas semasa pembelian. RevOps perlu menjadikan kerja tersembunyi ini kelihatan sebelum keputusan dibuat.

Penerimaan pengguna

Keputusan alat hanya berjaya jika pengguna mengubah tingkah laku mereka.

Tanya:

• Siapa yang menggunakannya setiap hari?
• Aliran kerja semasa mana yang akan dihentikan?
• Data apa yang perlu dimasukkan oleh pengguna?
• Irama pengurus mana yang akan mengukuhkan penggunaannya?
• Laporan apa yang bergantung kepadanya?
• Apa akan berlaku jika pengguna mengabaikannya?

Jika alat tidak berkait dengan irama operasi, penerimaan akan lemah.

Perkongsian dengan keselamatan dan IT

RevOps perlu melibatkan IT dan keselamatan pada peringkat awal.

Semak:

• Akses data pelanggan
• Model kebenaran
• Kelayakan integrasi (credentials)
• Pengekalan data
• Log audit
• Risiko vendor
• Pemilikan admin
• Proses offboarding

Semakan keselamatan yang lewat boleh melambatkan pelancaran atau memaksa reka bentuk semula. Semakan awal menjimatkan masa.

Pemarkahan build-vs-buy

Model pemarkahan yang mudah boleh membantu:

Keunikan tinggi, nilai strategik tinggi, dan kesesuaian vendor yang lemah mungkin menunjukkan arah kepada pembinaan. Aliran kerja standard dan kesesuaian vendor yang kukuh biasanya menunjukkan arah kepada pembelian atau konfigurasi.

Kesilapan biasa

Membeli untuk mengelak reka bentuk proses. Alat tidak boleh menentukan pemilikan.

Membina kerana pasukan mampu. Kos penyelenggaraan diabaikan.

Mengabaikan integrasi. Data menjadi berpecah-pecah.

Tiada pelan penamatan. Aliran kerja lama terus kekal.

Tiada pelan penerimaan. Pengguna terus bekerja dalam hamparan (spreadsheet).

Membandingkan ciri vendor sahaja. Kesesuaian operasi terlepas pandang.

Senarai semak kesediaan

Sebelum membuat keputusan:

• Masalah ditulis dengan jelas.
• Aliran kerja dipetakan.
• Pemilik data diketahui.
• Pengguna dikenal pasti.
• Alat semasa dinilai.
• Keperluan integrasi jelas.
• Semakan keselamatan dirancang.
• Pemilik penyelenggaraan dinamakan.
• Metrik kejayaan ditakrifkan.
• Pelan penamatan disertakan.

Apa yang perlu dibuktikan oleh senarai semak

Bina apabila aliran kerja cukup spesifik untuk mewajarkan pemilikan kekal. Beli apabila pasaran menyelesaikan aliran kerja itu dengan baik. Konfigurasikan apabila sistem semasa boleh menyokong proses dengan bersih. Integrasikan apabila sistem yang kukuh memerlukan data bersama. Buat keputusan berdasarkan masalah operasi, bukan keghairahan terhadap vendor.

Contoh keputusan

Contoh: pasukan memerlukan pengurusan data pendua yang lebih baik. Jika CRM mempunyai peraturan pendua asas dan jumlahnya rendah, konfigurasikan dahulu. Jika data pendua bervolum tinggi dan merentasi sistem, beli atau integrasikan alat kualiti data. Jika peraturan pemadanan bergantung kepada logik hierarki akaun proprietari, komponen khas mungkin wajar.

Contoh: pemimpin mahukan dashboard pelaporan lembaga. Jika takrifan metrik tidak jelas, jangan beli alat BI dahulu. Takrifkan kamus data, sumber kebenaran, dan proses rekonsiliasi kewangan terlebih dahulu. Kemudian tentukan sama ada BI sedia ada mencukupi.

Contoh: jualan mahukan pemarkahan ramalan khas. Jika kriteria commit tidak ditulis, jangan bina apa-apa. Jika kriteria jelas dan pasukan memerlukan model spesifik mengikut segmen, model khas atau lapisan analitik yang dikonfigurasi mungkin munasabah.

Pilot sebelum pelancaran penuh

Gunakan pilot untuk menguji kesesuaian operasi.

Pilot perlu menentukan:

• Skop
• Pengguna
• Aliran kerja
• Data yang diperlukan
• Metrik kejayaan
• Pemilik sokongan
• Tempoh masa
• Kriteria keputusan

Matlamatnya bukan untuk membuktikan pasukan mampu melancarkan alat. Matlamatnya ialah membuktikan alat itu memperbaiki aliran kerja.

Penilaian vendor

Apabila membeli, nilai lebih daripada sekadar ciri.

Tanya:

• Adakah model data sesuai dengan sistem rekod kita?
• Bolehkah ia menyokong kebenaran kita?
• Bagaimana integrasi berfungsi?
• Bolehkah admin mengurus peraturan tanpa kejuruteraan?
• Log audit apa yang wujud?
• Bagaimana pelaporan dieksport?
• Apa akan berlaku jika kita berhenti (churn)?
• Sokongan pelaksanaan apa yang wujud?
• Bagaimana harga berskala?
• Bolehkah aliran kerja diuji dengan data sebenar?

Perbandingan ciri berguna, tetapi kesesuaian operasi yang menentukan nilai.

Tadbir urus pembinaan

Apabila membina, tentukan pemilikan pada peringkat awal.

Keputusan yang diperlukan:

• Pemilik produk
• Pemilik kejuruteraan
• Pemilik sokongan
• Pemilik data
• Pemilik dokumentasi
• Pelan pemantauan
• Pengendalian ralat
• Proses permintaan perubahan
• Kriteria penamatan

Pembinaan dalaman selalunya bermula sebagai penyelesaian pantas dan menjadi sistem kekal. Jika aliran kerja cukup penting untuk dibina, ia cukup penting untuk ditadbir urus.

Perancangan penamatan

Setiap keputusan alat perlu menyertakan laluan penamatan.

Untuk alat yang dibeli:

• Bagaimana data akan dieksport?
• Aliran kerja apa yang akan menggantikannya?
• Laporan mana yang bergantung kepadanya?
• Integrasi mana yang perlu dialih keluar?
• Tarikh kontrak mana yang penting?

Untuk alat dalaman:

• Siapa yang boleh menamatkannya?
• Apa yang akan menggantikannya?
• Di mana dokumentasi disimpan?
• Bagaimana data dikekalkan?

Perancangan penamatan kelihatan terlalu awal semasa pembelian, tetapi ia menghalang keterikatan vendor dan kesukaran pembersihan kemudian.

Penjajaran pihak berkepentingan

Keputusan build-vs-buy melibatkan banyak pasukan.

Sertakan:

• RevOps untuk keperluan operasi
• Jualan, pemasaran, atau CS untuk aliran kerja pengguna
• Kewangan untuk kos dan perancangan
• IT untuk seni bina
• Keselamatan untuk risiko data
• Peguam untuk semakan kontrak
• Kejuruteraan jika pembinaan atau integrasi berat mungkin diperlukan

Penjajaran tidak bermakna semua orang mempunyai kuasa veto. Ia bermakna keputusan mencerminkan kos operasi sebenar.

Masa

Masa itu penting.

Membeli mungkin lebih pantas untuk dilancarkan jika aliran kerja adalah standard. Membina mungkin lebih pantas untuk keperluan dalaman yang sempit tetapi lebih perlahan untuk diselenggara. Konfigurasi mungkin paling pantas tetapi mungkin tidak berskala. Integrasi mungkin mengambil masa lebih lama pada peringkat awal tetapi mengurangkan kerja manual kemudian.

RevOps perlu membandingkan masa untuk nilai pertama (time to first value) dengan masa untuk operasi yang stabil. Kedua-duanya berbeza.

Rupa keputusan yang baik

Keputusan yang baik menghasilkan:

• Penambahbaikan aliran kerja yang jelas
• Data yang dipercayai
• Pemilik yang dinamakan
• Pelan penerimaan
• Impak pelaporan yang difahami
• Pelan penyelenggaraan
• Semakan keselamatan yang lengkap
• Laluan penamatan yang diketahui

Pilihan akhir kurang penting berbanding disiplin di sebaliknya. Proses yang baik boleh menjadikan konfigurasi, pembelian, integrasi, atau pembinaan berjaya. Proses yang buruk boleh menggagalkan mana-mana pilihan.

Bengkel penilaian

Jalankan bengkel ringkas sebelum membuat pilihan.

Agenda:

1. Takrifkan masalah aliran kerja.
2. Petakan proses semasa.
3. Kenal pasti sumber data.
4. Kenal pasti pengguna dan pemilik.
5. Senaraikan pilihan alat semasa.
6. Anggarkan laluan pembinaan, pembelian, konfigurasi, dan integrasi.
7. Semak risiko dan penyelenggaraan.
8. Pilih laluan pilot.

Bengkel ini mengekalkan keputusan supaya kekal berasaskan realiti. Ia juga menghalang demo vendor atau prototaip dalaman daripada menjadi jawapan lalai sebelum keperluan jelas.

Corak keputusan biasa

Konfigurasikan apabila aliran kerja hampir sama dengan model asli CRM dan keperluan pelaporan adalah mudah.

Beli apabila pasaran mempunyai vendor yang matang, pelaksanaan lebih pantas daripada kerja dalaman, dan syarikat boleh menerima model data vendor.

Integrasikan apabila dua sistem yang kukuh memerlukan data bersama dan menggantikan mana-mana satu akan mencipta gangguan yang tidak perlu.

Bina apabila aliran kerja bersifat spesifik, strategik, bernilai tinggi, dan syarikat sanggup menyokongnya selama bertahun-tahun.

Corak ini bukan peraturan, tetapi ia membantu pasukan mengelak keputusan yang bersifat emosi.

Tadbir urus selepas keputusan

Keputusan tidak selesai semasa pembelian atau pelancaran.

Selepas pelancaran, semak:

• Penerimaan
• Penambahbaikan aliran kerja
• Kualiti data
• Tiket sokongan
• Usaha admin
• Kebolehpercayaan integrasi
• Maklum balas pengguna
• Nilai pelaporan
• Kos berbanding nilai

Jika keputusan itu tidak memperbaiki aliran kerja operasi, RevOps perlu menyesuaikan, mengurangkan skop, atau menamatkan alat tersebut.

Hutang pembinaan

Pembinaan dalaman mencipta hutang apabila tiada sesiapa memilikinya.

Tanda amaran:

• Hanya seorang sahaja yang memahami logiknya.
• Tiada ujian wujud.
• Tiada pemantauan wujud.
• Pengguna tidak dapat melaporkan isu dengan jelas.
• Perubahan aliran kerja memerlukan pembaikan kecemasan.
• Dokumentasi sudah lapuk.

Jika tanda-tanda ini muncul, pembinaan itu mungkin masih berguna, tetapi ia memerlukan tadbir urus.

Memo keputusan

Tulis memo keputusan ringkas sebelum kelulusan.

Sertakan:

• Kenyataan masalah
• Pilihan yang dipertimbangkan
• Laluan yang disyorkan
• Faedah dijangka
• Impak data
• Impak integrasi
• Pemilik
• Kos
• Risiko
• Tarikh semakan

Memo tidak perlu panjang. Nilainya terletak pada kejelasan. Enam bulan kemudian, pasukan perlu tahu sebab keputusan itu dibuat dan hasil apa yang sepatutnya dicapai.

Semakan memo keputusan

Sebelum menandatangani kontrak atau memulakan pembinaan, tanya sama ada proses ini cukup jelas untuk menyokong keputusan tersebut. Jika jawapannya tidak, berhenti dan selesaikan reka bentuk operasi terlebih dahulu.

Keputusan terbaik adalah membosankan selepas pelancaran: pengguna menerimanya, data kekal bersih, pemilik tahu apa yang perlu dilakukan, dan aliran kerja bertambah baik.

Kekalkan model pemilikan kelihatan jelas selepas pelancaran.

Semakan kejayaan selepas pelancaran

Kualiti build-vs-buy perlu disemak selepas pelancaran, bukan hanya semasa kelulusan.

Semak selepas 30, 60, dan 90 hari:

Semakan ini menangkap jurang biasa antara kejayaan pelaksanaan dan kejayaan operasi. Sesuatu alat boleh dilancarkan tepat pada masanya tetapi masih gagal kerana pengguna terus menggunakan hamparan, data tidak disegerakkan dengan bersih, atau pengurus tidak mengukuhkan aliran kerja tersebut.

RevOps perlu membandingkan semakan ini dengan memo keputusan. Jika alat itu dibeli untuk memperbaiki kelajuan penghalaan, ukur kelajuan penghalaan. Jika ia dibina untuk memperbaiki pakej ramalan, ukur kualiti pakej ramalan dan masa penyediaan. Jika keputusan itu tidak boleh diukur, kenyataan masalah asal mungkin terlalu kabur.

Senario keputusan

Gunakan senario untuk menjadikan pilihan konkrit.

Senario ini menunjukkan sebab build-vs-buy bukan pilihan moral. Membeli tidak selalu lebih bijak. Membina tidak selalu membazir. Konfigurasi tidak selalu mencukupi. Laluan yang betul bergantung kepada kematangan aliran kerja, kesesuaian vendor, kapasiti penyelenggaraan, dan kos jika keputusan itu tersilap.

Pasukan RevOps terbaik sanggup berkata "belum lagi." Jika masalah belum ditakrifkan, data belum ditadbir urus, atau pemilik belum jelas, mana-mana pilihan akan mengecewakan.

Pemilik operasi selepas keputusan

Kerja build-vs-buy tidak selesai apabila keputusan diluluskan.

Setiap keputusan perlu menamakan:

• Pemilik perniagaan.
• Pemilik sistem.
• Pemilik data.
• Pemilik penerimaan.
• Pemilik pembaharuan atau penyelenggaraan.
• Metrik kejayaan.
• Tarikh semakan.

Ini menghalang corak biasa di mana sesuatu alat dibeli, dikonfigurasi, dilancarkan, dan kemudian ditinggalkan tanpa pemilikan operasi. RevOps perlu menganggap setiap keputusan build-vs-buy sebagai komitmen operasi jangka panjang, bukan sekadar peristiwa perolehan.

Soalan Lazim

Patutkah RevOps membina alat khas?

Kadangkala, tetapi hanya apabila nilai perniagaan mewajarkan penyelenggaraan tersebut. Kebanyakan pasukan patut mengkonfigurasi atau membeli sebelum membina.

Siapa yang membuat keputusan build vs buy?

RevOps perlu mengetuai keperluan operasi dengan input daripada IT, kewangan, keselamatan, dan pasukan fungsian.

Ketahui lebih lanjut

• Buy vs Build for AI Sales Operations
• Revenue Operations System of Record
• CRM Change Management