RACI RevOps: Matriks Pemilikan untuk Revenue Operations

RevOps rosak apabila semua orang bersetuju kerja itu penting tetapi tiada siapa bersetuju siapa memiliki keputusan tersebut.

Siapa meluluskan peringkat kitaran hayat baharu? Siapa memiliki medan sumber? Siapa memutuskan sama ada peraturan penghalaan lead berubah? Siapa menyelesaikan pertikaian antara atribusi pemasaran dan pelaporan kewangan?

RACI RevOps menjawab soalan tersebut sebelum ia menjadi berpolitik.

Jika anda memerlukan model asas, lihat Matriks RACI dan RACI berbanding RASCI berbanding DACI.

PMI menerangkan RACI sebagai cara untuk menjelaskan tanggungjawab dan akauntabiliti supaya kerja tidak tercicir antara pasukan. Dalam RevOps, kejelasan itu penting kerana kerja tersebut merentasi pemasaran, jualan, customer success, kewangan, data, dan sistem.

Model tanggungjawab RevOps Forrester ialah peringatan berguna bahawa RevOps luas secara semula jadi. RACI mengelakkan keluasan itu daripada menjadi kekaburan.

Fakta operasi utama

• RACI RevOps perlu memetakan keputusan berulang, bukan hanya tugas projek. Soalan sukar biasanya mengenai definisi, pemilikan data, perubahan sistem, peraturan ramalan, serah tugas, dan pelaporan eksekutif.
• Setiap keputusan memerlukan satu pemilik akauntabiliti. Input bersama adalah sihat. Akauntabiliti bersama sering mencipta kelewatan dan eskalasi berpolitik.
• RevOps tidak sepatutnya dipertanggungjawabkan atas hasil tanpa kuasa. Jika RevOps memiliki kualiti data, ia mesti dapat meluluskan, menolak, atau mengeskalasikan perubahan medan dan aliran kerja.
• RACI berfungsi paling baik apabila ia dipadankan dengan mandat pengambilan. Pengambilan RevOps pertama memerlukan hak keputusan yang sepadan dengan matriks pemilikan.

Apa maksud RACI dalam RevOps

RevOps sering perlu bertanggungjawab akauntabiliti terhadap sistem walaupun pasukan lain bertanggungjawab terhadap pelaksanaan tempatan.

Perbezaan ini penting. Pengurus jualan mungkin bertanggungjawab membimbing wakil jualan memasukkan langkah seterusnya. RevOps mungkin bertanggungjawab akauntabiliti terhadap definisi peringkat, medan wajib, peraturan dashboard, dan irama pemeriksaan yang menjadikan langkah seterusnya itu berguna. Kewangan mungkin dirujuk kerana data peluang yang sama menyumbang kepada perancangan.

Itulah sebabnya reka bentuk RACI RevOps memerlukan lebih perhatian berbanding RACI projek biasa. Outputnya bukan sekadar satu penyampaian projek. Ia adalah model operasi berterusan. Di mana hak keputusan mendarat juga bergantung pada sama ada anda menjalankan RevOps berpusat berbanding terbenam.

RACI teras RevOps

Jadual ini adalah titik permulaan. Sesuaikan dengan struktur syarikat anda.

Cara membina RACI RevOps

Mulakan dengan keputusan, bukan jabatan.

RACI yang lemah bermula dengan senarai pasukan dan bertanya, "Apa yang dimiliki oleh setiap pasukan?" Itu biasanya mencerminkan politik sedia ada. RACI yang lebih kukuh bermula dengan keputusan berulang yang mencipta geseran:

• Apa yang dikira sebagai lead layak?
• Bila sesuatu deal boleh memasuki peringkat 3?
• Siapa boleh mencipta medan wajib baharu?
• Laporan mana yang menjadi sumber kebenaran untuk pipeline?
• Siapa meluluskan perubahan penghalaan?
• Siapa memutuskan kategori ramalan?
• Data apa yang mesti berpindah daripada jualan kepada CS?
• Siapa memiliki taksonomi sebab churn?

Selepas menyenaraikan keputusan, tetapkan peranan.

Bagi setiap keputusan, pilih satu pemilik akauntabiliti. Kemudian kenal pasti siapa melakukan kerja, siapa mesti memberi input, dan siapa perlu dimaklumkan. Jika terdapat dua pemilik akauntabiliti, berhenti dan selesaikannya. Input bersama tidak mengapa. Akauntabiliti bersama biasanya bermaksud tiada siapa boleh membuat keputusan akhir.

Bina inventori keputusan dahulu

RACI RevOps yang paling berguna bermula dengan inventori keputusan.

Senaraikan keputusan berulang yang mencipta kekeliruan:

Inventori perlu berasaskan geseran sebenar, bukan kelengkapan teori. Ambil contoh daripada suku tahun lepas: laporan yang dipertikaikan, serah tugas gagal, permintaan medan yang bercelaru, ketidaksepakatan ramalan, pengecualian penghalaan, dan pembinaan semula dashboard. Itulah keputusan yang perlu dijelaskan dahulu oleh RACI.

Setelah inventori wujud, kumpulkan keputusan mengikut risiko. Keputusan berisiko rendah boleh bergerak pantas dengan RevOps dan pemilik sistem. Keputusan berisiko tinggi memerlukan kelulusan kewangan, kepimpinan fungsian, atau eksekutif.

Pandangan risiko ini mengelakkan RACI daripada melambatkan setiap perubahan kecil. Ia juga menghalang perubahan berimpak tinggi daripada berlaku melalui permintaan santai.

RACI mengikut kitaran hayat hasil

RACI RevOps yang berguna memetakan pemilikan merentasi kitaran hayat:

Pandangan ini membantu pemimpin melihat mengapa RevOps tidak boleh menjadi fungsi sokongan jualan sahaja. Sistem operasi yang sama merentasi keseluruhan perjalanan.

RACI untuk perubahan CRM dan pelaporan

Perubahan CRM adalah tempat pemilikan kabur menjadi mahal.

Gunakan RACI berasingan untuk perubahan sistem:

Ini menghalang kesilapan paling biasa: membenarkan mana-mana fungsi menukar struktur data bersama untuk keperluan tempatan.

Peraturan untuk menyelesaikan konflik

Malah RACI yang baik tidak akan menghapuskan setiap konflik.

Tambah peraturan eskalasi:

• Jika pertikaian hanya mempengaruhi satu fungsi, pemimpin fungsian memutuskan.
• Jika pertikaian mempengaruhi data bersama, RevOps memutuskan atau mengesyorkan.
• Jika pertikaian mempengaruhi ramalan, perancangan, atau pelaporan lembaga pengarah, RevOps dan kewangan mesti selaras sebelum pelancaran.
• Jika pertikaian mempengaruhi pengalaman pelanggan merentasi pasukan, CRO atau COO memutuskan.
• Jika pertikaian mempengaruhi pertukaran peringkat syarikat, penaja eksekutif memutuskan.

Peraturan eskalasi penting kerana RevOps sering berada di antara pemimpin kukuh dengan keperluan yang sah. RACI perlu menjadikan laluan keputusan kelihatan sebelum konflik menjadi peribadi.

Peraturan untuk menggunakan RACI

Satu pemilik akauntabiliti. Beberapa orang yang dirujuk tidak mengapa. Beberapa pemilik akauntabiliti mencipta jalan buntu.

Pemimpin fungsian masih memiliki prestasi. RevOps boleh memiliki sistem, tetapi pemimpin jualan masih memiliki prestasi jualan dan pemimpin CS masih memiliki pelaksanaan pengekalan.

Hak keputusan mesti sepadan dengan tanggungjawab. Jangan jadikan RevOps akauntabiliti terhadap kualiti data jika ia tidak boleh menguatkuasakan tadbir urus medan.

Semak selepas perubahan organisasi. RACI menjadi basi apabila pasukan, sistem, atau pergerakan GTM berubah.

Kesilapan RACI biasa

Terlalu banyak pemilik akauntabiliti. Ini adalah kegagalan paling biasa. Jika dua pemimpin akauntabiliti, tiada seorang pun mempunyai mandat yang bersih.

RevOps bertanggungjawab tetapi tidak diberi kuasa. Jangan jadikan RevOps akauntabiliti terhadap kualiti data jika ia tidak boleh menolak medan bernilai rendah, menukar kriteria peringkat, atau menguatkuasakan peraturan serah tugas.

Kewangan dimaklumkan terlalu lewat. Jika sesuatu metrik muncul dalam pelaporan lembaga pengarah, kewangan biasanya perlu dirujuk sebelum definisi berubah.

Pasukan ops terbenam mengikut peraturan berbeza. Marketing Ops, Sales Ops, dan CS Ops boleh kekal dekat dengan fungsi mereka, tetapi definisi bersama memerlukan satu model tadbir urus.

RACI tidak digunakan dalam pengambilan. Jika permintaan masih tiba sebagai "boleh anda bina ini?", RevOps akan menjadi baris tiket. Pengambilan perlu bertanya keputusan mana yang dipengaruhi oleh permintaan dan siapa akauntabiliti.

Irama semakan

Semak RACI RevOps setiap suku tahun, dan lebih awal selepas perubahan besar.

Pencetus termasuk:

• CRO, CMO, ketua CS, CFO, atau COO baharu
• Pergerakan GTM baharu
• Perubahan CRM baharu atau sistem besar
• Pemerolehan atau pemisahan unit perniagaan
• Peralihan daripada tumpuan perniagaan baharu kepada tumpuan pengembangan
• Pertikaian berulang mengenai bidang pemilikan yang sama

RACI bukan dokumen statik. Ia adalah perjanjian kerja. Jika pemimpin berhenti menggunakannya, pemilikan akan menyimpang kembali ke kuasa tidak formal dan perdebatan berulang.

Model mesyuarat

RACI perlu digunakan dalam mesyuarat operasi berulang, bukan disimpan dalam folder.

Gunakan dalam:

• Semakan roadmap RevOps
• Semakan perubahan sistem
• Semakan tadbir urus ramalan
• Semakan definisi funnel
• Semakan kualiti lead
• Semakan serah tugas closed-won
• Semakan definisi dashboard

Setiap mesyuarat perlu menjawab soalan pemilikan yang sama:

• Keputusan mana yang kita buat?
• Siapa akauntabiliti?
• Siapa mesti dirujuk sebelum keputusan?
• Siapa perlu dimaklumkan selepas keputusan?
• Data atau bukti apa yang diperlukan?
• Apa yang berubah dalam sistem selepas keputusan?

Ini menjadikan RACI praktikal. Pemimpin tidak perlu menghafal dokumen. Mereka memerlukan tabiat menggunakan bahasa pemilikan apabila sistem hasil berubah.

Contoh: perubahan penghalaan lead

Andaikan jualan mahu lead enterprise dihalakan terus kepada AE kanan, manakala pemasaran mahu ia dihalakan dahulu kepada SDR untuk kelayakan.

Tanpa RACI, ini menjadi perdebatan mengenai keutamaan.

Dengan RACI:

• RevOps bertanggungjawab memetakan logik penghalaan dan impak SLA.
• CRO akauntabiliti terhadap keputusan aliran kerja hasil.
• Pemasaran, kepimpinan SDR, pengurus jualan, dan kewangan dirujuk.
• SDR, AE, dan pemilik kempen pemasaran dimaklumkan selepas perubahan.

RevOps kemudian boleh menguji impak operasi: masa tindak balas, kadar penerimaan, kadar penukaran, kapasiti pemilik, dan perubahan pelaporan. RACI tidak memutuskan strategi, tetapi ia menjadikan laluan keputusan bersih.

Contoh: medan wajib baharu

Medan wajib adalah sumber geseran yang biasa.

Jualan mungkin menentang kerana medan melambatkan aliran kerja wakil jualan. Pemasaran mungkin mahukan lebih banyak data segmentasi. CS mungkin memerlukan konteks serah tugas. Kewangan mungkin memerlukan pelaporan yang lebih bersih.

RACI membantu memisahkan nilai medan daripada pemilikan medan:

• Pasukan yang memohon bertanggungjawab menerangkan keputusan yang disokong oleh medan tersebut.
• RevOps akauntabiliti terhadap tadbir urus medan.
• Sistem bertanggungjawab terhadap konfigurasi.
• Pengurus terjejas dirujuk.
• Pengguna dimaklumkan dengan nota pelancaran yang jelas.

RevOps perlu meluluskan medan hanya jika ia menyokong keputusan atau aliran kerja sebenar. Jika medan itu hanya menyokong keingintahuan sekali-sekala, ia perlu kekal pilihan atau berpindah ke titik penangkapan lain.

Kuasa mesti sepadan dengan akauntabiliti

RACI boleh kelihatan bersih di atas kertas dan masih gagal jika kuasa tiada.

Ketidakpadanan biasa:

Baiki jurang kuasa sebelum menerbitkan matriks. Jika RevOps akauntabiliti terhadap tadbir urus, pemimpin mesti menerima bahawa RevOps boleh menangguhkan permintaan bernilai rendah, mewajibkan definisi, dan mengeskalasikan konflik. Jika pemimpin fungsian memiliki tingkah laku, mereka mesti memeriksanya dalam pasukan mereka. Jika kewangan dirujuk mengenai metrik perancangan, kewangan memerlukan kedudukan sebelum metrik itu dilancarkan, bukan selepasnya.

RACI juga perlu menyatakan apa yang berlaku apabila pemilik akauntabiliti tidak memutuskan. Sebagai contoh, jika pertikaian kitaran hayat menyekat pelaporan lebih daripada dua minggu, CRO atau COO mungkin perlu membuat keputusan akhir. Tanpa eskalasi, RACI menamakan pemilikan tetapi tidak menyelesaikan keputusan yang terhenti.

Bagaimana RACI berhubung dengan piagam

Piagam RevOps mentakrifkan mandat. RACI mentakrifkan siapa bertindak di dalam mandat tersebut.

Gunakan piagam untuk menjawab, "Adakah ini skop RevOps?"

Gunakan RACI untuk menjawab, "Siapa memutuskan, siapa melakukan kerja, siapa memberi input, dan siapa dimaklumkan?"

Bersama-sama, mereka mencipta disiplin operasi. Secara berasingan, mereka lebih lemah. Piagam tanpa RACI terlalu luas. RACI tanpa piagam mungkin menjelaskan tugas tetapi terlepas tujuan fungsi tersebut.

Versi ringan untuk pasukan kecil

Syarikat kecil tidak memerlukan matriks pemilikan yang besar.

Mulakan dengan lima keputusan:

• Definisi kitaran hayat
• Penghalaan lead
• Peraturan peringkat peluang
• Kategori ramalan
• Keperluan serah tugas closed-won

Bagi setiap satu, namakan satu pemilik akauntabiliti dan satu peranan RevOps. Itu sudah cukup untuk mengurangkan kekeliruan tanpa melambatkan syarikat.

Apabila syarikat menambah segmen, pergerakan, sistem, dan pakar ops, kembangkan RACI. Model perlu berkembang seiring kerumitan.

Senarai semak kesediaan RACI

Sebelum menerbitkan matriks, ujinya terhadap konflik terkini.

Pilih tiga contoh sebenar daripada suku tahun lepas:

• Definisi lead yang dipertikaikan
• Perubahan peraturan ramalan
• Ketidaksepakatan metrik dashboard
• Permintaan medan wajib
• Kegagalan serah tugas closed-won
• Eskalasi penghalaan

Bagi setiap contoh, tanya sama ada RACI menjadikan laluan keputusan jelas. Jika pemimpin masih tidak dapat menentukan siapa akauntabiliti, matriks belum sedia.

Uji juga sama ada pemilik akauntabiliti mempunyai kuasa untuk bertindak. RACI yang menetapkan akauntabiliti tanpa kuasa akan mencipta kekecewaan. Jika RevOps akauntabiliti terhadap tadbir urus medan, ia mesti dapat meluluskan, menolak, atau mengeskalasikan perubahan medan. Jika jualan akauntabiliti terhadap ketepatan peringkat, pengurus memerlukan irama pemeriksaan dan akibat bagi kebersihan yang lemah.

Ujian akhir ialah kebolehgunaan. RACI perlu muat dalam beberapa muka surat dan mudah diimbas. Jika matriks terlalu terperinci sehingga tiada siapa menggunakannya, mulakan lebih kecil dan tumpu pada keputusan yang mencipta geseran hasil paling besar.

Setelah matriks aktif, rujuknya dalam setiap perubahan sistem atau proses yang bermakna. Penggunaan berulang itulah yang menukar pemilikan daripada dokumen kepada tingkah laku operasi dan mengurangkan perdebatan berulang.

Cara mengekalkan RACI ringan

RACI perlu cukup terperinci untuk menyelesaikan konflik, tetapi tidak terlalu terperinci sehingga tiada siapa membukanya.

Gunakan tiga tahap:

Model berlapis ini membantu syarikat kecil mengelakkan lebih-proses sambil memberi pasukan lebih besar kawalan yang mencukupi. Pembersihan laporan kecil tidak sepatutnya memerlukan jawatankuasa pengarah. Perubahan kepada definisi kategori ramalan tidak sepatutnya berlaku di dalam tiket.

Tanda terbaik bahawa RACI berfungsi bukanlah orang merujuknya secara berterusan. Ia adalah lebih sedikit keputusan tergendala kerana semua orang sudah tahu laluannya.

Soalan pengambilan RACI

Gunakan RACI pada saat permintaan memasuki RevOps.

Selain bertanya sekadar "apa yang anda perlu dibina?", pengambilan perlu bertanya:

• Keputusan perniagaan mana yang dipengaruhi oleh permintaan ini?
• Medan, aliran kerja, dashboard, atau serah tugas mana yang berubah?
• Siapa akauntabiliti terhadap hasil perniagaan?
• Siapa perlu dirujuk sebelum pelaksanaan?
• Pasukan mana yang perlu dimaklumkan selepas pelancaran?
• Adakah kewangan perlu menyemak definisi?
• Adakah perubahan itu mempengaruhi pelaporan eksekutif atau ramalan?
• Apa yang berlaku jika permintaan ditolak atau ditangguhkan?

Soalan ini melambatkan permintaan lemah sebelum ia menjadi kerja sistem. Sesebuah pasukan yang meminta dashboard baharu mungkin tidak mempunyai definisi metrik. Seorang pemimpin yang meminta medan wajib mungkin tidak tahu siapa memiliki nilainya. Seorang pengurus yang meminta pengecualian penghalaan mungkin tidak mempertimbangkan kapasiti atau impak pelaporan.

Proses pengambilan tidak sepatutnya berat. Ia boleh menjadi borang ringkas atau senarai semak di dalam backlog RevOps. Bahagian penting ialah setiap permintaan bermakna diikat kepada pemilik akauntabiliti dan laluan keputusan.

Ini juga melindungi kapasiti RevOps. Tanpa disiplin pengambilan, pasukan menghabiskan masa membina pembaikan tempatan yang mencipta kerumitan bersama. Dengan pengambilan berasaskan RACI, RevOps boleh menerangkan mengapa sesetengah permintaan bergerak pantas, sesetengah memerlukan rujukan, dan sesetengah tidak sepatutnya dibina.

Tanda RACI berfungsi

Perhatikan perubahan tingkah laku:

• Permintaan medan tiba dengan pemilik, definisi, dan sebab perniagaan.
• Pertikaian dashboard diselesaikan melalui peraturan sumber kebenaran yang dipersetujui.
• Perubahan peraturan ramalan merangkumi jualan, kewangan, dan RevOps sebelum pelancaran.
• Kegagalan serah tugas membawa kepada perubahan pemilikan, bukan hanya peringatan.
• Pasukan tahu siapa memutuskan sebelum mesyuarat bermula.
• RevOps menghabiskan lebih sedikit masa menengahi perdebatan berulang.

RACI berjaya apabila keputusan menjadi lebih pantas dan jelas. Ia perlu mengurangkan masa mesyuarat, mengurangkan kerja semula, dan menjadikan eskalasi kurang peribadi.

Pakej keputusan RACI

Gunakan pakej keputusan apabila pemilikan dipertikaikan.

Ini menghalang RACI daripada menjadi dokumen statik. Ia menjadi berguna apabila pemimpin menggunakannya untuk menyelesaikan keputusan operasi sebenar.

Soalan Lazim

Adakah RevOps memerlukan RACI?

Ya, sebaik sahaja beberapa pasukan bergantung pada sistem hasil yang sama. Tanpa RACI, serah tugas dan pemilikan data menjadi tidak formal.

Siapa patut akauntabiliti terhadap ketepatan ramalan?

Kepimpinan jualan biasanya memiliki hasil ramalan. RevOps memiliki proses ramalan, definisi, kualiti data, dan irama pemeriksaan. Kewangan adalah rakan kongsi rujukan utama.

Adakah RACI mencukupi untuk membuat keputusan?

Kadangkala. Untuk keputusan bertaruhan tinggi, DACI mungkin lebih baik kerana ia secara eksplisit mentakrifkan pemacu keputusan dan pelulus.

Ketahui lebih lanjut

• Piagam RevOps
• RevOps dan Kewangan
• Tadbir Urus Ramalan
• Glosari Penjajaran Pemasaran-Jualan