Kamus Data Hasil: Bahasa Bersama untuk RevOps

Kamus data hasil menentukan perkataan dan medan yang menggerakkan sistem hasil.

Tanpanya, pasukan menggunakan label yang sama secara berbeza. "Sumber lead", "SQL", "pipeline", "commit", "churn", dan "pengembangan" masing-masing boleh bermaksud sesuatu yang berbeza bergantung kepada siapa yang melaporkan.

RevOps memiliki kamus ini supaya syarikat dapat mempercayai dashboard dan aliran kerjanya.

Model tanggungjawab RevOps oleh Forrester berguna kerana kamus ini berada merentas fungsi, bukan di dalam satu pasukan sahaja. Penyelidikan penjajaran teknologi RevOps oleh Forrester turut mengukuhkan mengapa teknologi hasil memerlukan tadbir urus yang dikongsi bersama.

Fakta operasi utama

• Kamus data hasil bukan sekadar hamparan nama medan. Ia adalah kontrak yang dikongsi tentang bagaimana pasukan mentakrif, memasuki, mengubah, dan melaporkan data hasil.
• Versi pertama sepatutnya fokus kepada medan dan metrik yang menjejaskan keputusan: peringkat kitaran hayat, sumber, segmen, pemilik, peringkat, kategori ramalan, jumlah, tarikh pembaharuan, sebab churn, dan isyarat pengembangan.
• Definisi memerlukan pemilik. Medan tanpa pemilik akan melencong, terutamanya apabila ia muncul dalam pelaporan eksekutif, panggilan ramalan, atau perancangan kewangan.
• Setiap metrik yang dipaparkan kepada lembaga sepatutnya dapat dikesan kembali kepada satu entri kamus. Itulah yang mengekalkan pelaporan hasil sedia untuk lembaga dan tadbir urus ramalan daripada bertukar menjadi perdebatan definisi.

Apa yang perlu disertakan

Mulakan dengan medan kritikal

Jangan dokumenkan setiap medan dahulu. Mulakan dengan status kitaran hayat, sumber lead, pemilik, segmen, peringkat, tarikh tutup, kategori ramalan, jumlah, sebab churn, tarikh pembaharuan, dan jenis pengembangan.

Kaitkan ini dengan Tadbir Urus Medan CRM.

Mengapa kamus itu penting

Kamus data menghalang pasukan daripada menggunakan perkataan biasa dengan cara yang tidak serasi.

Sebagai contoh:

• Pemasaran mungkin mentakrif SQL sebagai diterima oleh jualan.
• Jualan mungkin mentakrif SQL sebagai discovery selesai.
• Kewangan mungkin mentakrif pipeline sebagai opportunity layak sahaja.
• Pengurus jualan mungkin memasukkan opportunity awal dalam pipeline.
• CS mungkin mentakrif churn mengikut logo manakala kewangan melaporkan churn hasil.

Perbezaan ini bukan sekadar semantik. Ia mengubah dashboard, perancangan, belanjawan, ramalan, dan akauntabiliti.

Struktur kamus

Setiap entri sepatutnya merangkumi:

Struktur ini menjadikan kamus berguna kepada kedua-dua pemimpin perniagaan dan pemilik sistem.

Standard kualiti definisi

Kualiti sesuatu entri kamus bergantung kepada sama ada ia dapat menghapuskan tafsiran semasa kerja sebenar.

Entri yang kukuh menjawab lima soalan:

Definisi yang lemah kedengaran biasa tetapi tidak membimbing tingkah laku. "Pipeline layak ialah pipeline yang kelihatan sahih" tidak akan bertahan dalam panggilan ramalan. "Pipeline layak ialah jumlah opportunity terbuka di mana opportunity itu telah melepasi kriteria keluar peringkat 2, mempunyai tarikh tutup semasa, mempunyai pemilik, dan tidak dikecualikan oleh polisi ramalan" memberikan pengurus sesuatu untuk diperiksa.

Standard yang sama terpakai kepada medan. "Sebab churn ialah mengapa pelanggan pergi" tidak mencukupi. Entri itu sepatutnya menyatakan sama ada sebab itu churn logo atau churn hasil, siapa yang menetapkannya, bila ia ditetapkan, nilai mana yang dibenarkan, dan bagaimana ia digunakan dalam pelaporan.

Entri kritikal

Mulakan dengan entri yang menjejaskan keputusan:

• Sumber lead
• Peringkat kitaran hayat
• MQL
• SQL
• Opportunity
• Pipeline layak
• Kategori ramalan
• Commit
• Best case
• Closed-won
• ARR
• Bookings
• Tarikh pembaharuan
• Sebab churn
• Isyarat pengembangan
• Kesihatan pelanggan

Jangan cuba dokumenkan setiap medan yang jarang digunakan dahulu. Mulakan dengan medan yang muncul dalam mesyuarat kepimpinan.

Nilai yang dibenarkan

Picklist memerlukan tadbir urus.

Sebagai contoh, nilai sebab churn sepatutnya cukup khusus untuk ditindak:

• Tidak sesuai
• Ciri yang hilang
• Tiada belanjawan
• Onboarding yang lemah
• Tiada penaja eksekutif
• Penggunaan yang rendah
• Pesaing
• Perniagaan ditutup

Jika senarai terlalu kabur, pelaporan tidak dapat menggerakkan tindakan. Jika terlalu terperinci, pengguna akan memilih nilai yang salah atau kembali kepada nilai lalai lain.

Medan wajib

Kamus sepatutnya menerangkan mengapa sesuatu medan diwajibkan.

Kaitkan keperluan dengan keputusan:

• Penghalaan
• Kelayakan
• Ramalan
• Serah tugas
• Bilan
• Pematuhan
• Pembaharuan
• Pengembangan
• Pelaporan lembaga

Jika tiada keputusan bergantung kepada medan itu, ia mungkin berguna tetapi tidak wajib.

Aliran kerja kamus

Apabila sesuatu pasukan meminta medan atau metrik baharu:

1. Tentukan soalan perniagaan.
2. Kenal pasti pemilik dan sumber kebenaran.
3. Tentukan nilai yang dibenarkan.
4. Tentukan peringkat wajib.
5. Kenal pasti laporan yang terlibat.
6. Luluskan atau tolak melalui tadbir urus.
7. Tambah entri ke dalam kamus.
8. Sampaikan perubahan itu.

Ini mengaitkan kamus kepada Medan Wajib berbanding Medan Berguna.

Kamus minimum yang berdaya guna

Kamus pertama yang berguna boleh bermula kecil. Ia tidak perlu meliputi setiap medan CRM.

Mulakan dengan 20 hingga 30 entri merentas empat kumpulan:

Versi pertama ini sepatutnya cukup baik untuk menyelesaikan pertikaian yang lazim. Jika pemimpin berdebat tentang atribusi sumber, kategori ramalan, definisi SQL, sebab churn, atau kualiti pipeline, kamus itu sepatutnya menjawab soalan tersebut atau menunjukkan tadbir urus yang masih hilang.

Jangan mulakan dengan medan yang jarang digunakan. Itu mewujudkan kerja dokumentasi dengan penerimaan yang rendah. Mulakan di tempat kekeliruan sudah mahal.

Kawalan perubahan

Definisi berubah. Masalahnya ialah perubahan senyap.

Setiap perubahan yang bermakna sepatutnya merangkumi:

• Definisi lama
• Definisi baharu
• Sebab
• Tarikh berkuat kuasa
• Laporan yang terlibat
• Kesan sejarah
• Pemilik kelulusan

Ini membantu pemimpin mentafsir trend dengan betul.

Penerimaan

Kamus yang tidak digunakan sesiapa hanyalah dokumentasi semata-mata.

RevOps sepatutnya mengaitkan kamus kepada:

• Tooltip dashboard
• Penerangan medan CRM
• Onboarding
• Latihan pengurus
• Tadbir urus sistem
• Pelaporan eksekutif
• Senarai semak audit

Kamus sepatutnya mudah ditemui semasa kerja sebenar.

Kesilapan yang lazim

Mendokumenkan terlalu banyak terlalu awal. Pasukan menjadi keliru.

Tiada pemilik bagi setiap entri. Definisi merosot.

Tiada sejarah perubahan. Perubahan trend menjadi mengelirukan.

Bahasa teknikal sahaja. Pengguna perniagaan tidak dapat memahami medan itu.

Kamus terputus daripada CRM. Pengguna melihat panduan yang berbeza di tempat yang berbeza.

Senarai semak kesediaan

Sebelum pelancaran:

• Entri kritikal sudah didokumenkan.
• Pemilik sudah dinamakan.
• Peraturan sumber kebenaran sudah disertakan.
• Nilai yang dibenarkan adalah terkini.
• Medan wajib mempunyai sebab perniagaan.
• Proses perubahan sudah jelas.
• Definisi dashboard dikaitkan kembali kepada kamus.

Kamus itu berkesan apabila pertikaian metrik dapat diselesaikan dengan membuka entri itu, bukan dengan bertanya di sana sini.

Contoh entri

Contoh: Sumber lead

Contoh: Commit

Contoh menjadikan kamus lebih mudah diterima pakai.

Kamus dan onboarding

Gunakan kamus dalam onboarding untuk RevOps, jualan, pemasaran, CS, dan kewangan.

Pekerja baharu sepatutnya mempelajari:

• Apa maksud peringkat kitaran hayat
• Medan mana yang penting
• Definisi mana yang dikongsi
• Laporan mana yang menjadi sumber kebenaran
• Siapa memiliki perubahan

Ini mengurangkan pengetahuan yang tersimpan secara tidak formal dalam kumpulan kecil.

Penyelenggaraan kamus

Semak kamus setiap bulan untuk medan yang kerap berubah dan setiap suku tahun untuk model yang lebih luas.

Pencetus semakan:

• Permintaan medan baharu
• Pertikaian dashboard
• Perubahan definisi ramalan
• Pergerakan GTM baharu
• Migrasi CRM
• Perubahan integrasi
• Perubahan perancangan kewangan

Kamus sepatutnya berubah apabila perniagaan berubah, tetapi perubahan itu sepatutnya jelas kelihatan.

Penghentian medan

Kamus juga sepatutnya membantu menghentikan medan.

Hentikan sesuatu medan apabila:

• Tiada laporan menggunakannya.
• Tiada aliran kerja bergantung kepadanya.
• Kualiti data terlalu rendah untuk diperbaiki.
• Medan yang lebih baik menggantikannya.
• Soalan perniagaan itu tidak lagi penting.

Penghentian medan mengekalkan CRM boleh digunakan.

Metrik kualiti

Jejaki kesihatan kamus:

• Peratusan medan kritikal yang didokumenkan
• Peratusan medan kritikal yang mempunyai pemilik
• Medan dengan nilai yang dibenarkan tidak jelas
• Metrik tanpa formula
• Definisi yang berubah suku tahun ini
• Metrik dashboard yang dikaitkan dengan kamus

Metrik ini menunjukkan sama ada kamus itu adalah aset operasi.

Peraturan kualiti

Kamus sepatutnya berada dekat dengan tempat kerja itu berlaku. Jika pengguna perlu mencari definisi di wiki, mereka akan bertanya rakan sepasukan, meneka, atau mencipta definisi tempatan sendiri. RevOps sepatutnya menjadikan definisi rasmi lebih mudah ditemui berbanding definisi tidak rasmi.

Turutan pembinaan

Bina kamus secara berfasa.

Fasa 1: metrik eksekutif.

Dokumenkan metrik hasil, pipeline, ramalan, penukaran, pengekalan, pengembangan, dan kualiti data yang digunakan dalam mesyuarat kepimpinan.

Fasa 2: medan kitaran hayat.

Dokumenkan peringkat kitaran hayat, status lead, peringkat opportunity, kategori ramalan, status pembaharuan, dan status pengembangan.

Fasa 3: medan aliran kerja.

Dokumenkan pemilik, SLA, penghalaan, serah tugas, risiko, penolakan, dan medan closed-lost.

Fasa 4: pembersihan dan penghentian.

Buang atau tandakan medan yang tidak lagi menyokong keputusan.

Peranan tadbir urus

Kamus memerlukan peranan:

Tanpa peranan, kamus akan merosot.

Kaitan dengan dashboard

Setiap metrik dashboard eksekutif sepatutnya dikaitkan kembali kepada satu entri kamus.

Entri itu sepatutnya menerangkan:

• Formula
• Sumber
• Tetingkap masa
• Pengecualian
• Kekerapan kemas kini
• Pemilik
• Amaran

Ini menjadikan dashboard lebih mudah dipertahankan dan lebih mudah dibaiki.

Kaitan dengan CRM

Penerangan medan CRM sepatutnya sepadan dengan definisi kamus.

Jika kamus menyatakan satu perkara dan tooltip CRM menyatakan perkara lain, pengguna akan mengikut alat yang berada di hadapan mereka. RevOps sepatutnya mengekalkan kamus dan panduan CRM sentiasa selari.

Contoh definisi yang buruk

Definisi buruk: "Pipeline layak ialah pipeline yang baik."

Definisi lebih baik: "Pipeline layak ialah nilai opportunity terbuka yang dijangka ditutup dalam tempoh terpilih di mana peringkat opportunity berada pada atau melepasi layak, jumlah sudah diisi, tarikh tutup adalah semasa, dan peringkat yang dikecualikan sudah dibuang."

Definisi buruk: "Sebab churn ialah mengapa pelanggan pergi."

Definisi lebih baik: "Sebab churn ialah sebab utama pelanggan, produk, komersial, atau kesesuaian yang ditetapkan semasa semakan churn, menggunakan nilai yang diluluskan dan dimiliki oleh CS bersama tadbir urus RevOps."

Definisi yang khusus mengurangkan tafsiran.

Senarai semak pembersihan definisi

Sebelum pelancaran:

• Medan kritikal sudah didokumenkan.
• Metrik eksekutif sudah didokumenkan.
• Bantuan medan CRM sudah selari.
• Pemilik sudah dinamakan.
• Log perubahan sudah wujud.
• Definisi lama sudah diarkibkan.
• Pengguna tahu di mana untuk mencari kamus.

Kamus itu matang apabila pasukan menggunakannya sebelum mencipta medan atau dashboard baharu.

Amaran praktikal

Kamus boleh menjadi basi dengan cepat jika ia dianggap sebagai projek dokumentasi semata-mata.

Kaitkan ia dengan aliran kerja aktif:

• Permintaan medan baharu memerlukan entri kamus.
• Metrik dashboard memerlukan definisi kamus.
• Perubahan kategori ramalan mengemas kini kamus.
• Medan wajib memerlukan sebab perniagaan yang didokumenkan.
• Medan yang dihentikan ditandakan dengan tarikh.

Ini menjadikan kamus sebahagian daripada tadbir urus, bukan sekadar renungan kemudian.

Contoh operasi amaran praktikal

Jika pemimpin jualan meminta medan wajib baharu bernama "kualiti deal," RevOps tidak sepatutnya mencipta ia serta-merta. Proses kamus sepatutnya bertanya: apa maksud kualiti deal, siapa memilikinya, nilai mana yang dibenarkan, di mana ia diwajibkan, laporan mana yang menggunakannya, dan tindakan apa yang menyusul?

Jika kewangan meminta "pipeline layak," RevOps sepatutnya mendokumenkan formula yang tepat sebelum dashboard dibina. Adakah ia termasuk peringkat 1? Adakah ia termasuk pembaharuan? Adakah ia mengecualikan tarikh tutup di luar suku tahun? Adakah ia menggunakan jumlah berpemberat atau tidak berpemberat?

Jika CS meminta sebab churn, RevOps sepatutnya mentakrif nilai yang dibenarkan yang boleh mengubah tingkah laku. Nilai kabur seperti "nilai tidak mencukupi" mungkin memerlukan sub-sebab yang berkait dengan penerimaan, onboarding, kesesuaian produk, atau penajaan eksekutif.

Peraturan penerimaan amaran praktikal

Kamus sepatutnya menjadikan data yang baik lebih mudah berbanding data yang buruk. Jika definisi rasmi sukar ditemui, pengguna akan mencipta definisi tempatan sendiri. Jika nilai yang dibenarkan tidak sepadan dengan kerja sebenar, pengguna akan memilih nilai lain. Jika perubahan mengambil masa terlalu lama, pasukan akan memintas tadbir urus.

RevOps sepatutnya mengekalkan kamus itu praktikal, jelas kelihatan, dan dikaitkan dengan keputusan.

Senarai semak risiko

Sebelum pelaksanaan, uji kamus terhadap permintaan yang lazim:

• Medan wajib baharu
• Metrik dashboard baharu
• Pertikaian definisi ramalan
• Pembersihan sebab churn
• Soalan atribusi sumber
• Metrik pelaporan lembaga

Bagi setiap permintaan, kamus sepatutnya menunjukkan definisi, pemilik, sumber, nilai yang dibenarkan, penggunaan wajib, dan laporan yang terlibat. Jika ia tidak dapat berbuat demikian, tambah entri yang hilang sebelum meningkatkan skala proses itu.

Peraturan praktikal

Kamus sepatutnya mengurangkan tafsiran. Seorang pengurus jualan, pemasar, pemimpin CS, rakan kongsi kewangan, dan penganalisis RevOps sepatutnya dapat membaca entri yang sama dan memahami makna perniagaan yang sama.

Bahasa yang dikongsi itulah yang menjadikan pelaporan hasil dan aliran kerja lebih mudah dipercayai.

Kamus juga sepatutnya membantu pasukan berkata tidak. Jika medan yang diminta tiada pemilik, tiada sumber kebenaran, tiada nilai yang dibenarkan, dan tiada laporan atau aliran kerja yang bergantung kepadanya, RevOps sepatutnya menolak atau menangguhkannya. Disiplin itu menghalang CRM daripada dipenuhi medan yang mewujudkan lebih banyak kerja berbanding nilai.

Perkara yang sama terpakai kepada metrik. Jika sesuatu metrik tidak dapat ditakrif dengan cukup jelas untuk kamus, ia belum bersedia untuk pelaporan eksekutif.

Gunakan kamus sebagai pintu kualiti. Sebelum sesuatu medan menjadi wajib, sebelum sesuatu metrik sampai ke lembaga, dan sebelum sesuatu aliran kerja bergantung kepada satu nilai, definisi itu sepatutnya cukup jelas untuk orang yang memasukkan dan menggunakan data itu.

Itulah cara kamus berubah daripada dokumentasi kepada kawalan operasi. Ia melindungi dashboard, penghalaan, ramalan, perancangan pembaharuan, serah tugas pelanggan, dan pelaporan kepimpinan kerana setiap proses yang bergantung kepadanya merujuk kembali kepada definisi yang jelas.

Kos daripada percanggahan adalah tinggi. Medan yang bermula dengan satu makna dalam pemasaran, makna lain dalam jualan, dan makna ketiga dalam kewangan akhirnya akan mewujudkan tiga laporan yang tidak sepadan. Pada ketika itu, pembersihan bukan sekadar teknikal. Pemimpin terpaksa membina semula kepercayaan terhadap angka-angka itu. Kamus yang terkini menghalang kerja yang boleh dielakkan itu.

Cara menjadikan kamus jelas kelihatan

Penerimaan bertambah baik apabila kamus muncul di tempat orang sudah bekerja.

Gunakan pelbagai permukaan:

Kamus tidak sepatutnya memerlukan orang mencari di wiki semasa kerja langsung. Versi penuh boleh berada dalam dokumen yang ditadbir urus, tetapi definisi ringkas sepatutnya muncul dalam CRM, dashboard, atau proses di mana pengguna memerlukannya.

Inilah juga cara RevOps memperoleh pematuhan tanpa penguatkuasaan yang berat. Jika definisi rasmi lebih mudah ditemui berbanding definisi tidak rasmi, orang lebih cenderung menggunakannya.

Audit kamus data

Setelah versi pertama dilancarkan, audit ia terhadap kerja sebenar. Audit itu tidak sepatutnya bertanya sama ada dokumen itu lengkap. Ia sepatutnya bertanya sama ada kamus itu mengurangkan kekeliruan dalam keputusan yang penting.

Gunakan audit yang praktikal:

Audit sering menemui tiga jenis jurang.

Pertama, entri yang hilang. Sesuatu metrik muncul dalam mesyuarat kepimpinan tetapi tiada definisi. Tambahkannya sebelum kitaran laporan seterusnya.

Kedua, entri yang lemah. Entri itu wujud tetapi tidak menjawab cukup soalan. Sebagai contoh, "sumber pipeline" mungkin perlu menjelaskan sumber asal, sumber terkini, sumber opportunity, dan pengaruh kempen.

Ketiga, jurang penerimaan. Entri itu jelas, tetapi pengguna tidak melihatnya semasa kerja. Dalam kes itu, penyelesaiannya mungkin teks bantuan CRM, tooltip dashboard, latihan pengurus, atau pembersihan medan, dan bukannya dokumentasi tambahan.

Audit sepatutnya menghasilkan senarai tindakan yang ringkas. Jangan jadikan ia program pembersihan data yang penuh melainkan bukti mewajarkan skop itu. Audit yang terbaik memperbaiki kamus sambil juga mendedahkan di mana aliran kerja, pelaporan, atau tadbir urus perlu dibaiki.

Contoh operasi

Berikut ialah bagaimana kamus mengubah perbualan RevOps yang lazim.

Seorang pemimpin jualan meminta medan wajib "pembuat keputusan." RevOps menyemak standard kamus sebelum mencipta medan itu. Apa maksud pembuat keputusan? Adakah ia pembeli ekonomi, penaja eksekutif, kuasa menandatangani, atau peserta mesyuarat? Pada peringkat mana ia diwajibkan? Laporan atau aliran kerja mana yang menggunakannya? Jika jawapannya tidak jelas, permintaan medan itu belum bersedia.

Kewangan bertanya mengapa pipeline layak berubah sejak bulan lepas. RevOps membuka entri pipeline layak. Jika definisi berubah, sejarah perubahan sepatutnya menunjukkan tarikh berkuat kuasa, pemilik, dan kesan sejarah. Jika definisi tidak berubah, pasukan memeriksa data sumber: pergerakan peringkat, perubahan tarikh tutup, rekod yang dikecualikan, perubahan jumlah, dan penciptaan opportunity baharu.

CS mahukan sebab churn yang lebih baik. RevOps mengelakkan menambah dua puluh nilai serta-merta. Proses kamus bermula dengan soalan perniagaan: sebab churn mana yang akan mengubah pemerolehan, onboarding, produk, penetapan harga, atau penglibatan pelanggan? Nilai yang tidak mengubah tindakan boleh dikeluarkan daripada picklist.

Pemasaran mahukan dashboard atribusi baharu. RevOps menyemak definisi sumber dahulu. Jika sumber asal, sumber terkini, kempen, dan sumber opportunity tidak ditakrif, dashboard baharu itu hanya akan menjadikan percanggahan lebih jelas kelihatan. Kerja kamus mendahului pembinaan laporan.

Contoh ini menunjukkan tujuan sebenar kamus. Ia membantu pasukan melambatkan langkah sebelum mereka mengekod kekeliruan ke dalam sistem.

Pakej perubahan kamus data

Setiap perubahan medan yang penting sepatutnya mengemas kini kamus data.

Rekodkan:

• Nama medan.
• Definisi.
• Sistem sumber.
• Nilai yang dibenarkan.
• Pemilik.
• Peringkat wajib.
• Laporan yang terlibat.
• Aliran kerja yang terlibat.
• Tarikh perubahan.
• Peraturan penghentian.

Ini mengekalkan kamus daripada menjadi dokumentasi yang basi. Ia sepatutnya menjadi permukaan kawalan bagi data hasil, bukan arkib yang tidak dipercayai sesiapa.

Soalan Lazim

Siapa memiliki kamus data hasil?

RevOps sepatutnya memilikinya, dengan input peringkat medan daripada pemasaran, jualan, CS, kewangan, dan pemilik sistem.

Di mana ia sepatutnya disimpan?

Di suatu tempat yang jelas kelihatan dan cukup terkawal versi supaya orang dapat mencari definisi terkini. Format itu kurang penting berbanding penerimaan.

Ketahui lebih lanjut

• Sumber Kebenaran untuk Data Hasil
• Kebersihan Data CRM
• Metrik RevOps
• Atribusi Lead kepada Hasil