Source of Truth untuk Data Hasil: Bagaimana RevOps Menghalang Angka Bercanggah

Pasukan hasil tidak memerlukan satu sistem untuk menyimpan segalanya.

Mereka memerlukan satu model source of truth yang memberitahu setiap pasukan sistem mana yang menang untuk setiap soalan.

CRM mungkin memiliki peringkat peluang. Automasi pemasaran mungkin memiliki keahlian kempen. Pengebilan mungkin memiliki jumlah langganan. Kejayaan pelanggan mungkin memiliki status kesihatan. BI mungkin menggabungkan kesemuanya untuk pelaporan. RevOps mentadbir bagaimana kebenaran-kebenaran ini berhubung.

Kajian penjajaran teknologi RevOps Forrester relevan kerana masalah source of truth biasanya muncul apabila pasukan menambah alat tanpa tadbir urus dikongsi. Kajian keyakinan ramalan Gartner juga peringatan berguna bahawa kepercayaan data menjejaskan keputusan hasil, terutamanya ramalan dan perancangan.

Fakta operasi utama

• Source of truth tidak bermaksud satu sistem memiliki segalanya. Ia bermaksud setiap soalan hasil yang penting mempunyai sistem menang, pemilik, definisi, dan amaran yang diketahui.
• CRM selalunya memiliki data aliran kerja jualan. Pengebilan atau kewangan mungkin memiliki kebenaran hasil. Automasi pemasaran mungkin memiliki kebenaran kempen. CS mungkin memiliki kesihatan pelanggan. BI mungkin menggabungkan kesemuanya untuk pelaporan.
• Tadbir urus source of truth sepatutnya menyelesaikan konflik sebelum mesyuarat eksekutif. Pemimpin sepatutnya berdebat tentang strategi, bukan hamparan mana yang betul.
• Model itu sepatutnya kelihatan dalam dashboard, tadbir urus medan, intake, dan kamus data hasil supaya pasukan boleh menggunakannya semasa kerja sebenar.

Peta source of truth

Peraturan tadbir urus

Tentukan:

• Sistem mana yang memiliki setiap elemen data
• Integrasi mana yang boleh menulis kepadanya
• Medan mana yang bersifat baca sahaja
• Bagaimana konflik diselesaikan
• Laporan mana yang menggunakan data gabungan
• Siapa yang meluluskan perubahan

Dokumenkan model dalam Revenue Data Dictionary.

Kenapa source of truth rosak

Masalah source of truth biasanya bermula kecil.

Pemasaran menukar medan sumber. Jualan menyunting jumlah peluang. Kewangan mengeksport tempahan ke dalam hamparan. CS menjejak risiko pembaharuan dalam alatnya sendiri. BI mengira pipeline dengan definisi yang sedikit berbeza daripada dashboard CRM.

Setiap keputusan tempatan mungkin masuk akal. Digabungkan bersama, ia mencipta angka yang bercanggah.

RevOps menghalang ini dengan menentukan sistem mana yang menang, pasukan mana yang memiliki medan tersebut, dan laporan mana yang menggunakan definisi mana.

Prinsip source of truth

Gunakan prinsip berikut:

Model itu sepatutnya menjadikan penyelesaian konflik membosankan (dalam erti kata rutin dan mudah).

Soalan perniagaan dahulu

Keputusan source of truth sepatutnya bermula dengan soalan perniagaan, bukan sistem.

Elemen data yang sama boleh muncul dalam pelbagai sistem, tetapi soalan itu menentukan sistem mana yang menang. Jumlah CRM mungkin berguna sebelum tandatangan kontrak. Jumlah pengebilan mungkin menang selepas kontrak. Kewangan mungkin memiliki metrik hasil peringkat lembaga pengarah walaupun CRM memiliki aliran kerja peluang.

Menulis soalan dahulu menghalang perdebatan kabur seperti "Adakah CRM source of truth?" Soalan yang lebih baik ialah "source of truth untuk keputusan apa?"

Peta elemen data

Mulakan dengan peta praktikal:

Jadual ini akan berbeza mengikut syarikat. Bahagian penting ialah ia wujud.

Penyelesaian konflik

Tulis peraturan konflik.

Contoh:

• Jika jumlah CRM berbeza daripada kontrak yang ditandatangani, kontrak atau pengebilan menang.
• Jika sumber lead berbeza antara borang dan suntingan manual, sumber asal yang ditangkap menang melainkan RevOps meluluskan pembetulan.
• Jika kesihatan pelanggan berbeza antara nota CS dan model kesihatan, model kesihatan menang untuk pelaporan dan nota tersebut memaklumkan semakan.
• Jika pipeline BI dan CRM berbeza, definisi pelaporan eksekutif yang didokumenkan menang, dan RevOps menyiasat jurang tersebut.

Tanpa peraturan konflik, mesyuarat bertukar menjadi pertengkaran.

Source of truth peringkat laporan

Sesetengah laporan menggabungkan pelbagai sistem.

Sebagai contoh, laporan hasil sedia untuk lembaga pengarah mungkin merangkumi pipeline CRM, ARR pengebilan, pelan kewangan, risiko pembaharuan CS, dan sumber pemasaran. Laporan itu sendiri boleh menjadi source of truth untuk perbincangan lembaga pengarah hanya jika setiap input mempunyai definisi ditadbir.

BI bukan source of truth ajaib. Ia adalah lapisan pelaporan gabungan. Ia memerlukan definisi, pemilik, dan amaran.

Tadbir urus perubahan

Sebarang perubahan source of truth sepatutnya merangkumi:

• Elemen data yang terjejas
• Sumber lama
• Sumber baharu
• Sebab perubahan
• Sistem yang terjejas
• Laporan yang terjejas
• Kesan sejarah
• Pemilik kelulusan
• Tarikh pelancaran

Ini amat penting untuk dashboard eksekutif dan metrik perancangan.

Model penerimaan

Model source of truth hanya berfungsi jika orang menggunakannya.

RevOps sepatutnya menerbitkan:

• Kamus data
• Senarai pemilik
• Katalog laporan
• Log perubahan
• Laluan eskalasi
• Soalan Lazim untuk konflik biasa

Apabila pemimpin bertanya "angka mana yang betul?", pasukan sepatutnya tahu di mana untuk mencari.

Kesilapan biasa

Satu sistem memiliki segalanya. Ini mengabaikan realiti data pengebilan, CS, pemasaran, dan kewangan.

Tiada peraturan suntingan. Pengguna menulis ganti medan yang sepatutnya dilindungi.

BI menjadi kotak hitam. Laporan dipercayai sehingga tiada siapa dapat menjelaskan formulanya.

Kewangan dikecualikan. Metrik perancangan terhanyut daripada metrik operasi.

Tiada amaran. Data lemah kelihatan boleh dipercayai.

Senarai semak kesediaan

Sebelum pelancaran:

• Elemen data kritikal telah dipetakan.
• Pemilik telah dinamakan.
• Sistem menang telah ditentukan.
• Hak suntingan jelas.
• Peraturan konflik telah ditulis.
• Laporan eksekutif diikat kepada definisi ditadbir.
• Log perubahan wujud.

Model ini berfungsi apabila pasukan boleh menyelesaikan konflik data mengikut peraturan dan bukan hierarki.

Contoh aliran kerja konflik

Apabila dua angka bercanggah, gunakan aliran kerja mudah:

1. Kenal pasti soalan perniagaan.
2. Kenal pasti elemen data yang terlibat.
3. Semak peta source of truth.
4. Semak sama ada konflik itu adalah data, definisi, masa, atau transformasi.
5. Gunakan peraturan konflik yang telah ditulis.
6. Dokumenkan sebarang pembetulan.
7. Kemas kini peta jika peraturan itu tiada.

Ini menghalang corak biasa di mana pemimpin yang paling lantang memilih angka.

Konflik masa

Sesetengah konflik berlaku kerana sistem mengemas kini pada masa yang berbeza.

Sebagai contoh, CRM mungkin menunjukkan deal closed-won hari ini, pengebilan mungkin mengemas kini esok, dan BI mungkin mengemas kini semalaman. Itu bukan semestinya masalah kualiti data. Ia adalah amaran masa.

RevOps sepatutnya mendokumenkan irama kemas kini untuk laporan kritikal:

• Masa nyata
• Setiap jam
• Setiap hari
• Penutupan mingguan
• Penutupan kewangan bulanan

Metrik kewangan mungkin sengaja tertinggal daripada metrik operasi. Itu sepatutnya kelihatan.

Kontrak data

Untuk medan penting, cipta kontrak data:

Ini memberi pasukan sistem dan pemilik perniagaan rujukan yang sama.

Pelaporan eksekutif

Pelaporan eksekutif memerlukan tadbir urus yang lebih ketat berbanding dashboard pasukan.

Sebelum metrik muncul dalam pelaporan eksekutif atau lembaga pengarah, sahkan:

• Kewangan meluluskan definisi.
• RevOps meluluskan sumber data operasi.
• Pemilik fungsian memahami akauntabiliti prestasi.
• Amaran data telah didokumenkan.
• Trend sejarah boleh dibandingkan.

Ini menghalang pelaporan lembaga pengarah daripada menjadi latihan penyesuaian manual.

Pemeriksaan kesihatan source of truth

Jejak:

• Bilangan laporan bercanggah
• Kadar sumber tidak diketahui
• Kadar suntingan medan manual
• Jumlah ralat segerakan
• Medan tanpa pemilik
• Metrik tanpa definisi
• Laporan dengan formula tidak didokumenkan

Ini adalah isyarat kesihatan operasi.

Peraturan source of truth

Model source of truth sepatutnya menjawab "angka mana yang patut kita gunakan?" sebelum mesyuarat bermula. Jika pemimpin menyelesaikan konflik sumber secara langsung dalam mesyuarat kepimpinan, RevOps mempunyai lebih banyak kerja tadbir urus untuk dilakukan.

Contoh source of truth

Contoh: liputan pipeline.

Liputan pipeline sepatutnya menggunakan peluang CRM, tetapi hanya jika peringkat, tarikh tutup, jumlah, dan kategori ramalan ditadbir. Kewangan mungkin meluluskan formula liputan. RevOps mungkin memiliki amaran kualiti data. Jualan memiliki prestasi pipeline.

Contoh: NRR.

NRR mungkin menggunakan data pengebilan atau kewangan sebagai source of truth, dengan kesihatan CS dan risiko pembaharuan sebagai konteks operasi. CRM sahaja mungkin tidak mencukupi kerana pembaharuan, pengurangan, dan pengembangan bergantung kepada kebenaran kontrak dan pengebilan.

Contoh: ROI kempen.

Automasi pemasaran mungkin memiliki keahlian kempen. CRM mungkin memiliki data peluang dan closed-won. BI mungkin menggabungkan kesemuanya. RevOps sepatutnya menentukan bagaimana sumber lead, pengaruh, dan hasil dihubungkan.

Katalog source of truth

Cipta katalog dengan:

• Soalan perniagaan
• Elemen data
• Sistem sumber
• Pemilik
• Peraturan suntingan
• Laporan yang terjejas
• Amaran
• Pemilik eskalasi

Kekalkan katalog itu ringkas pada mulanya. Mulakan dengan elemen data yang paling banyak diperdebatkan oleh pemimpin.

Model eskalasi

Apabila konflik sumber tidak dirangkumi:

1. RevOps mengenal pasti sistem yang bercanggah.
2. Kewangan memberi pandangan jika metrik itu menjejaskan perancangan atau pelaporan lembaga pengarah.
3. Pemilik fungsian menjelaskan keperluan aliran kerja.
4. Pemilik sistem menjelaskan kekangan teknikal.
5. Penaja eksekutif membuat keputusan jika pertukaran masih wujud.
6. RevOps mengemas kini model tersebut.

Ini menukar konflik kepada tadbir urus yang lebih baik.

Skor kepercayaan data

RevOps boleh memberi skor kepada data kritikal:

Gunakan skor ini dalam amaran dashboard. Jika sumber pipeline berwarna kuning, pemimpin sepatutnya tahu sebelum menggunakannya untuk perancangan.

Isu operasi biasa

Hamparan bayangan. Biasanya tanda bahawa laporan rasmi kekurangan kepercayaan atau masa.

Suntingan medan manual. Selalunya tanda bahawa peraturan sumber tidak dikuatkuasakan.

Metrik pendua. Pasukan berbeza mencipta versi tempatan metrik yang sama.

Pemilikan tidak diketahui. Tiada siapa membaiki medan yang rosak kerana semua orang menggunakannya tetapi tiada siapa memilikinya.

Senarai semak isu operasi biasa

Sebelum mengisytiharkan model selesai:

• Setiap metrik eksekutif mempunyai sumber.
• Setiap sumber mempunyai pemilik.
• Setiap pemilik boleh meluluskan perubahan.
• Setiap konflik mempunyai peraturan atau laluan eskalasi.
• Setiap dashboard mempunyai amaran yang kelihatan.
• Setiap perubahan definisi utama direkodkan.

Kerja source of truth tidak pernah selesai sepenuhnya, tetapi ia sepatutnya boleh ditadbir.

Amaran praktikal

Kerja source of truth boleh menjadi abstrak jika ia tidak dikaitkan dengan pertikaian.

Mulakan dengan soalan yang sudah diperdebatkan oleh pemimpin:

• Angka pipeline mana yang betul?
• Sumber mana yang mencipta deal ini?
• Angka ARR mana yang patut digunakan oleh kewangan?
• Status kesihatan pelanggan mana yang terkini?
• Tarikh pembaharuan mana yang rasmi?
• Sebab churn mana yang patut dilaporkan?

Gunakan pertikaian tersebut untuk membina versi pertama model. Ini menjadikan kerja itu praktikal dan lebih mudah diterima pakai.

Contoh operasi amaran praktikal

Jika dua laporan pipeline tidak bersetuju, RevOps sepatutnya menyemak sama ada mereka menggunakan peringkat peluang, tetingkap tarikh tutup, medan jumlah, penapis pemilik, dan rekod dikecualikan yang sama. Jawapannya mungkin isu logik laporan, bukan isu data.

Jika pemasaran dan jualan tidak bersetuju tentang sumber, RevOps sepatutnya menyemak peraturan penangkapan, sejarah suntingan manual, hierarki kempen, dan perkaitan peluang. Pembetulan mungkin memerlukan kunci medan atau padanan lead-ke-akaun yang lebih baik.

Jika kewangan dan jualan tidak bersetuju tentang hasil, RevOps sepatutnya menyemak masa. Jualan mungkin melihat tempahan closed-won manakala kewangan melihat hasil yang dibilkan atau diiktiraf. Kedua-duanya boleh betul untuk soalan yang berbeza.

Peraturan penerimaan amaran praktikal

Terbitkan model source of truth di tempat orang bekerja. Pautkan daripada dashboard, dokumen tadbir urus medan, dan intake RevOps. Jika orang hanya melihatnya semasa onboarding, mereka akan melupakannya semasa pertikaian sebenar.

Model itu sepatutnya mudah dirujuk pada saat konflik muncul.

Senarai semak risiko

Sebelum pelancaran, uji model terhadap konflik sebenar daripada suku tahun lepas.

Pilih contoh:

• Satu pertikaian angka pipeline
• Satu pertikaian atribusi sumber
• Satu percanggahan hasil kewangan berbanding CRM
• Satu percanggahan kesihatan pelanggan atau risiko pembaharuan
• Satu konflik definisi dashboard

Untuk setiap contoh, sahkan bahawa model memberitahu pasukan sumber mana yang menang, pemilik mana yang boleh meluluskan perubahan, dan amaran mana yang sepatutnya muncul dalam pelaporan.

Jika model tidak dapat menyelesaikan konflik sebenar, ia terlalu teori.

Peraturan praktikal

Model source of truth terbaik mengurangkan geseran mesyuarat. Pasukan mungkin masih berdebat tentang strategi, tetapi mereka tidak sepatutnya menghabiskan masa eksekutif memutuskan sistem mana yang dipercayai. Keputusan itu sepatutnya sudah ditadbir.

Model itu juga sepatutnya melindungi kepercayaan pasukan. Pemasaran sepatutnya tahu data sumber tidak akan ditulis ganti sewenang-wenangnya. Jualan sepatutnya tahu peraturan pipeline konsisten. Kewangan sepatutnya tahu metrik perancangan diluluskan. CS sepatutnya tahu isyarat pembaharuan dan kesihatan tidak diabaikan. RevOps menyatukan peraturan tersebut supaya setiap fungsi boleh menggunakan data dengan kurang rundingan.

Apabila model source of truth berfungsi, pasukan masih mempunyai perbualan yang sukar, tetapi mereka bermula daripada bukti yang sama.

Bukti dikongsi itulah intinya. RevOps bukan cuba menghapuskan perselisihan. Ia cuba menghapuskan kekeliruan yang boleh dielakkan sebelum pemimpin membuat keputusan.

Perbezaan itulah yang menjadikan model ini berbaloi untuk dikekalkan.

Ia sepatutnya disemak setiap kali laporan utama berubah.

Semakan pemilikan

Semak pemilikan source of truth setiap kali perniagaan menambah motif, sistem, segmen, atau pakej pelaporan.

Tanya:

• Elemen data baharu mana yang telah dicipta?
• Sistem mana yang menangkapnya dahulu?
• Sistem mana yang sepatutnya menang untuk pelaporan?
• Pasukan mana yang memiliki ketepatan?
• Laporan atau aliran kerja mana yang bergantung kepada nilai tersebut?
• Pengguna mana yang boleh menyuntingnya?
• Amaran mana yang sepatutnya muncul dalam paparan eksekutif?

Terhanyutnya pemilikan biasanya senyap. Satu medan bermula sebagai nota CS tempatan, menjadi sebahagian daripada risiko pembaharuan, kemudian muncul dalam perancangan kewangan tanpa pemilik yang jelas. Atau medan sumber pemasaran bermula sebagai konteks kempen, kemudian menjadi atribusi untuk keputusan bajet. RevOps sepatutnya mengenal pasti bila medan tempatan menjadi medan hasil dikongsi dan memindahkannya ke dalam tadbir urus.

Inilah juga sebab kerja source of truth tidak sepatutnya hanya wujud dalam dokumentasi. Ia sepatutnya menjadi sebahagian daripada intake sistem, semakan dashboard, persediaan pelaporan lembaga pengarah, dan pembersihan selepas insiden konflik data.

Katalog laporan

Tadbir urus source of truth sepatutnya merangkumi katalog laporan untuk paparan menghadap kepimpinan.

Katalog itu tidak perlu merangkumi setiap laporan peribadi. Mulakan dengan dashboard eksekutif, pakej ramalan, pelaporan lembaga pengarah, laporan corong, laporan pembaharuan, dan paparan atribusi sumber. Itulah laporan yang paling berkemungkinan mencipta konflik jika definisi terhanyut.

Katalog laporan juga membantu apabila pemimpin meminta paparan baharu. RevOps boleh menyemak sama ada laporan ditadbir yang sedia ada sudah menjawab soalan tersebut. Jika tidak, laporan baharu itu mendapat pemilik dan definisi sebelum ia menjadi satu lagi source of truth tidak rasmi.

Pakej keputusan source of truth

Apabila pasukan tidak bersetuju tentang sesuatu angka, RevOps sepatutnya mendokumenkan keputusan tersebut dan bukan bergantung kepada ingatan.

Pakej itu menukar konflik kepada tadbir urus. Setelah keputusan ditulis, pasukan boleh menambah baik sumber dan bukan membina semula angka secara berbeza setiap kali.

Soalan Lazim

Adakah CRM sentiasa source of truth?

Tidak. CRM selalunya menjadi source of truth untuk data jualan dan peluang. Pengebilan, CS, automasi pemasaran, atau BI mungkin memiliki jenis data lain.

Siapa yang memiliki model source of truth?

RevOps sepatutnya memiliki model tersebut dengan input daripada kewangan, sistem, pemasaran, jualan, dan CS.

Ketahui lebih lanjut

• CRM Data Hygiene
• Lead to Revenue Attribution
• Board-Ready Revenue Reporting
• CRM Field Governance