Pengurusan Perubahan CRM: Bagaimana RevOps Melancarkan Perubahan Proses

Perubahan CRM tidak gagal kerana pengguna membenci sistem.

Ia gagal kerana pengguna mengalami perubahan itu sebagai geseran yang mengejutkan. Satu medan wajib muncul sebelum closed-won. Satu peringkat jualan berubah tanpa penjelasan. Satu peraturan penghalaan mula menetapkan lead secara berbeza. Satu angka dashboard bergerak kerana definisi berubah, tetapi tiada siapa memberi amaran kepada pengurus yang bergantung kepada laporan itu.

Kemudian jalan pintas bermula. Wakil jualan memasukkan nilai sementara dalam medan wajib. Pengurus mengeksport hamparan mereka sendiri. Customer success meminta konteks dalam Slack kerana medan serah tugas kosong. Finance berhenti mempercayai rollup CRM. Sistem secara teknikalnya berubah, tetapi model operasi tidak berubah.

Itulah kerja sebenar pengurusan perubahan CRM: menjadikan setiap perubahan medan, aliran kerja, automasi, peringkat, dan laporan sebagai tingkah laku yang boleh digunakan dalam proses hasil.

Penyelidikan model operasi RevOps oleh Forrester adalah relevan kerana pengurusan perubahan CRM tergolong di dalam model operasi, bukan hanya senarai tugas sistem. Penyelidikan penjajaran teknologi RevOps oleh Forrester turut menunjukkan kenapa keputusan teknologi memerlukan penjajaran merentas fungsi di seluruh enjin hasil.

Fakta operasi utama

• Perubahan CRM menjejaskan tingkah laku, pelaporan, automasi, dan kepercayaan pada masa yang sama.
• Perubahan medan berisiko rendah boleh menjadi berisiko tinggi apabila ia menyumbang kepada ramalan, penghalaan, serah tugas, atau pelaporan kepada lembaga.
• Pemeriksaan pengurus adalah mekanisme penerimaan. Komunikasi sahaja tidak mencukupi.
• Setiap perubahan berisiko sederhana atau tinggi memerlukan pemilik selepas pelancaran, bukan hanya sebelum pelancaran.
• Proses perubahan CRM yang terbaik melindungi pengguna daripada geseran yang mengejutkan dan melindungi pemimpin daripada hanyutan metrik secara senyap.

Kenapa perubahan CRM gagal dalam pasukan hasil

Kebanyakan kegagalan perubahan CRM bukanlah kegagalan teknikal.

Medan itu telah ditambah. Automasi telah berjalan. Laporan telah dimuatkan. Peraturan pengesahan berfungsi. Dari perspektif admin, perubahan itu telah dihantar.

Tetapi pasukan hasil tidak hidup di dalam halaman persediaan admin. Mereka hidup di dalam serah tugas, semakan, blok panggilan, mesyuarat pipeline, panggilan ramalan, pembaharuan, dan pelaporan kepada lembaga. Satu perubahan CRM berjaya hanya apabila ia sesuai dengan detik-detik tersebut.

Corak kegagalan biasa kelihatan seperti ini:

1. Seorang pihak berkepentingan meminta satu perubahan CRM.
2. RevOps membina medan, peraturan, aliran kerja, atau laporan yang diminta.
3. Pengguna melihat perubahan tanpa konteks yang mencukupi.
4. Pengurus tidak memeriksa tingkah laku baharu itu.
5. Pengguna mencari jalan pintas.
6. Kualiti data merosot.
7. Pemimpin berhenti mempercayai output tersebut.
8. RevOps diminta untuk membersihkannya.

Kitaran itu mahal kerana ia mencipta dua sistem: CRM yang dikonfigurasi dan proses operasi sebenar yang digunakan orang untuk menyelesaikan kerja.

Pengurusan perubahan CRM yang baik menutup jurang itu. Ia mengubah permintaan konfigurasi menjadi perubahan operasi yang diurus dengan baik.

Masalah pengurusan perubahan yang sebenarnya dimiliki RevOps

Pengurusan perubahan CRM bukan nota keluaran (release notes).

Nota keluaran memberitahu orang apa yang berubah. Pengurusan perubahan menjadikan perubahan itu boleh digunakan dalam kerja harian. RevOps perlu mengaitkan perubahan teknikal dengan tingkah laku yang dijangkakan daripada jualan, pemasaran, customer success, finance, dan pengurus.

Satu perubahan CRM boleh menjejaskan:

• Medan mana yang perlu diisi pengguna
• Rekod mana yang dicipta, digabungkan, dikemaskini, atau diarkibkan
• Aliran kerja mana yang tercetus secara automatik
• Laporan mana yang dipercayai pemimpin
• Serah tugas mana yang membawa konteks yang mencukupi
• Peraturan ramalan mana yang diperiksa pengurus
• Pasukan mana yang memiliki pengecualian
• Definisi mana yang muncul dalam pelaporan eksekutif

Risikonya bukan hanya kekesalan pengguna. Satu perubahan CRM yang buruk boleh merosakkan CRM field governance, melemahkan CRM data hygiene, merosakkan data hasil sumber kebenaran, dan menjadikan dashboard operasi hasil kurang dipercayai.

Soalan praktikal adalah mudah: jika perubahan ini dihantar esok, adakah orang yang perlu menggunakannya akan tahu apa yang perlu dilakukan, kenapa ia penting, dan bagaimana kejayaan akan diperiksa?

Apa yang termasuk dalam pengurusan perubahan CRM yang baik

Setiap perubahan CRM yang bermakna memerlukan enam bahagian.

Ini bukan birokrasi. Ia adalah perlindungan terhadap perubahan yang kelihatan kecil dalam konsol admin tetapi menjadi besar dalam sistem operasi.

Contoh: menambah satu medan wajib sebelum closed-won kedengaran remeh. Tetapi ia mungkin menjejaskan aliran kerja wakil jualan, pemeriksaan pengurus, serah tugas customer success, kakitangan pelaksanaan, pelaporan closed-won, dan penyesuaian finance. Perubahan itu tidak sepatutnya dilancarkan sehingga kesan tersebut difahami.

Klasifikasikan setiap perubahan mengikut risiko

Bukan setiap perubahan CRM memerlukan proses yang sama.

RevOps perlu mengklasifikasikan perubahan mengikut risiko sebelum memutuskan berapa banyak semakan yang diperlukan. Intinya bukan untuk melambatkan segala-galanya. Intinya ialah menghalang perubahan kritikal daripada dilancarkan dengan proses berisiko rendah.

Ujiannya ialah pergantungan, bukan usaha. Satu perubahan yang mengambil masa 10 minit untuk dikonfigurasi masih boleh menjadi berisiko tinggi jika ia menjejaskan pelaporan, penghalaan, atau kualiti serah tugas.

Perubahan berisiko rendah

Perubahan berisiko rendah bersifat tempatan, boleh diterbalikkan, dan tidak berkemungkinan mengubah tingkah laku di luar khalayak kecil.

Contoh termasuk:

• Menambah paparan senarai peribadi
• Menamakan semula widget dashboard untuk kejelasan
• Menambah medan nota pilihan untuk satu pasukan
• Mengemaskini teks bantuan
• Membetulkan salah taip dalam label picklist

Perubahan berisiko rendah masih memerlukan pemilik. Ia tidak memerlukan jawatankuasa.

Perubahan berisiko sederhana

Perubahan berisiko sederhana menjejaskan penggunaan harian tetapi tidak mentakrifkan semula model operasi.

Contoh termasuk:

• Menambah medan wajib pada peringkat yang diketahui
• Menyusun semula susun atur halaman
• Menambah automasi tugasan baharu
• Mengemaskini penapis dashboard pengurus
• Menukar nilai picklist yang digunakan satu pasukan

Perubahan ini memerlukan semakan pengurus kerana pengurus adalah saluran penerimaan. Jika pengurus tidak dapat menerangkan kenapa perubahan itu wujud, pengguna akan menganggapnya sebagai gangguan sistem.

Perubahan berisiko tinggi

Perubahan berisiko tinggi menjejaskan tafsiran hasil atau proses merentas fungsi.

Contoh termasuk:

• Mengubah peraturan peringkat opportunity
• Melaraskan logik penghalaan
• Mengubah tingkah laku atribusi sumber
• Mengemaskini logik kategori ramalan
• Mengubah keperluan serah tugas antara jualan dan customer success

Perubahan berisiko tinggi memerlukan ujian, contoh, komunikasi, dan pemantauan selepas pelancaran. Ia juga memerlukan pemilik di luar RevOps yang mengambil berat tentang hasil perniagaan.

Perubahan kritikal

Perubahan kritikal menjejaskan integriti sistem hasil.

Contoh termasuk:

• Menggantikan sistem rekod
• Mengubah logik penggabungan akaun
• Membina semula medan pengebilan atau kontrak
• Mentakrifkan semula satu metrik lembaga
• Mengubah kebenaran untuk data hasil yang sensitif

Perubahan kritikal memerlukan perancangan rollback dan kesedaran eksekutif. Ia juga mungkin memerlukan semakan finance, undang-undang, IT, keselamatan, atau pasukan data.

Mulakan dengan keputusan, bukan medan

Kebanyakan masalah perubahan CRM bermula dengan pengambilan (intake) yang lemah.

Seseorang meminta satu medan. Seseorang meminta satu automasi. Seseorang mahukan penapis dashboard. Jika RevOps menerima permintaan itu seperti yang ditulis, CRM akan dipenuhi objek yang menyelesaikan kesakitan tempatan sambil mencipta kerumitan yang dikongsi.

Soalan pertama tidak sepatutnya "Medan apa yang anda mahu?"

Soalan pertama sepatutnya "Keputusan apa yang akan diperbaiki oleh ini?"

Soalan itu memisahkan keperluan operasi daripada rasa ingin tahu pelaporan.

Jika pemohon tidak dapat menerangkan keputusan tersebut, perubahan itu mungkin belum sepatutnya berada dalam CRM.

Gunakan ringkasan pengambilan (intake brief)

Untuk perubahan sederhana, tinggi, dan kritikal, gunakan ringkasan pengambilan yang ringkas.

Ia perlu menjawab:

• Masalah apa yang kita selesaikan?
• Siapa yang meminta perubahan ini?
• Aliran kerja mana yang berubah?
• Pasukan mana yang terjejas?
• Medan, laporan, dashboard, atau integrasi mana yang bergantung kepada data ini?
• Adakah data baharu ini wajib, pilihan, dikira, atau dijana sistem?
• Pada titik mana dalam aliran kerja pengguna boleh mengetahui jawapannya?
• Apa yang berlaku jika pengguna tidak menerimanya?
• Apa laluan rollback?
• Bagaimana kita akan mengukur kejayaan?

Ringkasan ini melindungi RevOps daripada membina permintaan yang hanya jelas kepada pemohon. Ia juga memberikan pasukan ingatan. Tiga bulan kemudian, seseorang perlu masih dapat memahami kenapa perubahan itu wujud.

Petakan kesan hiliran

Perubahan CRM jarang kekal di dalam satu skrin sahaja.

Satu medan baharu mungkin menyumbang kepada dashboard. Satu dashboard mungkin menyumbang kepada laporan lembaga. Satu peraturan peringkat mungkin menyumbang kepada kategori ramalan. Satu perubahan penghalaan mungkin menjejaskan kapasiti jualan. Satu medan closed-won mungkin menjejaskan onboarding pelanggan.

RevOps perlu memetakan kesan hiliran sebelum pelancaran.

Kesan medan

Periksa sama ada medan itu menjejaskan:

• Peraturan medan wajib
• Susun atur halaman
• Automasi
• Integrasi
• Pelaporan
• Set kebenaran
• Templat import
• Rekod sejarah
• Entri kamus data

Jika medan itu tiada pemilik, tiada definisi, dan tiada keputusan yang dikaitkan dengannya, ia akan mereput. Perubahan itu mungkin masih sah, tetapi pemilik mesti dinamakan sebelum pelancaran.

Kesan aliran kerja

Periksa sama ada aliran kerja itu menjejaskan:

• Penghalaan lead
• Pergerakan peringkat opportunity
• Serah tugas closed-won
• Tugasan pembaharuan
• Pemeriksaan ramalan
• Semakan pengurus
• Onboarding customer success
• Penyesuaian finance

Kesan aliran kerja adalah tempat di mana perubahan kecil menjadi jelas dilihat. Satu peraturan pengesahan yang menghalang pergerakan peringkat boleh berguna. Ia juga boleh menghentikan satu deal sebenar daripada ditutup jika ia muncul sebelum pengguna boleh mengetahui jawapannya.

Kesan pelaporan

Periksa sama ada perubahan itu menjejaskan:

• Dashboard eksekutif
• Pakej ramalan
• Liputan pipeline
• Laporan atribusi
• Pelaporan prestasi jualan
• Pelaporan hasil sedia untuk lembaga

Jika satu perubahan menyentuh pelaporan, RevOps perlu memberitahu pemilik laporan sebelum pelancaran. Pemimpin tidak sepatutnya menemui perubahan definisi metrik semasa satu mesyuarat.

Kesan integrasi

Periksa sama ada perubahan itu menjejaskan:

• Penyegerakan automasi pemasaran
• Alatan penglibatan jualan
• Platform customer success
• Sistem pengebilan atau langganan
• Model gudang data
• Alatan pengayaan
• Tugas reverse ETL
• Alatan automasi aliran kerja

Kesan integrasi mudah terlepas pandang kerana skrin CRM boleh kelihatan betul sedangkan sistem hiliran gagal secara senyap.

Tentukan pemilik sebelum membina

Perubahan CRM memerlukan lebih daripada seorang pembina.

Ia memerlukan pemilik untuk keputusan perniagaan, data, pelancaran, dan semakan selepas pelancaran.

Seorang boleh memegang lebih daripada satu peranan dalam syarikat kecil. Tetapi peranan itu masih perlu wujud.

Kesilapannya ialah menganggap RevOps memiliki segala-galanya. RevOps boleh memiliki proses, tetapi pemimpin fungsian mesti memiliki tingkah laku. Satu perubahan peringkat jualan tanpa pemeriksaan kepimpinan jualan tidak akan bertahan.

Uji perubahan seperti satu aliran kerja hasil

Ujian tidak sepatutnya berhenti pada "medan itu muncul" atau "automasi itu berjalan."

Uji aliran kerja itu dari hujung ke hujung.

Contoh: medan risiko pelaksanaan wajib sebelum closed-won.

Kes ujian:

• Wakil jualan boleh melihat dan memahami medan itu.
• Medan itu diwajibkan hanya pada peringkat yang betul.
• Nilai yang dibenarkan adalah jelas.
• Pengurus tahu cara memeriksanya.
• Customer success boleh melihat nilai selepas serah tugas.
• Dashboard boleh melaporkan kelengkapan medan.
• Opportunity sedia ada tidak terhalang secara tidak dijangka.
• Laluan pengecualian berfungsi untuk deal yang sudah dalam proses penutupan.

Ujian perlu merangkumi kes tepi. Apa yang berlaku jika deal itu ditutup sebagai closed-won melalui satu integrasi? Apa yang berlaku jika seorang pengguna tiada kebenaran? Apa yang berlaku kepada rekod lama? Apa yang berlaku jika medan itu kosong dalam data yang diimport?

Ujian yang buruk memeriksa persediaan admin. Ujian yang baik memeriksa tingkah laku operasi.

Gunakan matriks ujian

Matriks ujian mengekalkan semakan perubahan konkrit.

Matriks ini tidak perlu panjang. Ia perlu sebenar.

Berkomunikasi dalam bahasa operasi

Pengguna tidak memerlukan log perubahan teknikal. Mereka perlu tahu apa yang berubah dalam kerja mereka.

Mesej yang baik merangkumi:

• Apa yang berubah
• Kenapa ia berubah
• Siapa yang terjejas
• Apa yang pengguna perlu lakukan secara berbeza
• Apa yang pengurus akan periksa
• Ke mana untuk bertanya soalan
• Bila perubahan itu berkuat kuasa

Mesej lemah: "Kami menambah medan risiko pelaksanaan wajib."

Mesej lebih baik: "Bermula Isnin, setiap deal yang bergerak ke closed-won mesti menyertakan risiko pelaksanaan. Customer success menggunakan medan ini untuk menyediakan onboarding, dan pengurus akan menyemaknya dalam semakan deal. Gunakan 'Tiada' hanya apabila tiada risiko penghantaran yang diketahui."

Mesej kedua menerangkan sebab operasi. Itulah yang membantu penerimaan.

Berikan pengurus nota pelancaran yang berasingan

Pengurus memerlukan lebih daripada pengumuman pengguna.

Mereka perlu tahu apa yang perlu diperiksa, cara membimbing, dan rupa data yang lemah.

Pemerkasaan pengurus perlu merangkumi:

• Apa yang berubah
• Kenapa ia penting
• Rekod mana yang perlu diperiksa
• Rupa data yang baik
• Rupa data yang lemah
• Cara mengendalikan pengecualian
• Apa yang perlu dilakukan jika pengguna keliru
• Metrik mana yang akan diperhatikan RevOps selepas pelancaran

Untuk sebarang perubahan yang menjejaskan jurujual, pengurus perlu melihat contoh sebelum pelancaran. Tunjukkan satu rekod opportunity yang baik, satu rekod yang buruk, dan satu kes tepi. Itu memberikan pengurus bahasa yang boleh digunakan dalam bimbingan.

Gunakan templat perubahan, tetapi kekalkan ia ringkas

Templat hanya membantu apabila orang benar-benar menggunakannya.

Nota pengguna yang baik boleh ringkas:

Mesej itu perlu muat dalam satu siaran Slack, e-mel, dan nota mesyuarat. Jika penjelasan itu memerlukan dokumen yang panjang, aliran kerja itu mungkin terlalu tidak jelas.

Lancarkan perubahan dalam urutan terkawal

Pelancaran yang bersih mempunyai peringkat.

1. Pengambilan dan sebab perniagaan
2. Klasifikasi risiko
3. Semakan kesan
4. Pembinaan atau konfigurasi
5. Kes ujian
6. Pratonton pengurus
7. Komunikasi pengguna
8. Pelancaran
9. Semakan penerimaan selepas pelancaran
10. Semakan kualiti data
11. Keputusan untuk mengekalkan, melaraskan, menangguhkan, atau rollback

Perubahan kecil boleh melalui langkah-langkah ini dengan pantas. Perubahan besar memerlukan lebih banyak masa. Intinya bukan untuk menjadikan setiap perubahan berat. Intinya ialah menjadikan setiap perubahan lengkap.

Pilih corak pelancaran yang betul

Perubahan yang berbeza memerlukan corak pelancaran yang berbeza.

Corak pelancaran yang salah mencipta risiko. Pembaikan senyap sesuai untuk salah taip. Ia berbahaya untuk atribusi sumber, logik ramalan, atau keperluan serah tugas.

Perhatikan tingkah laku selepas pelancaran

Minggu pertama selepas pelancaran adalah tempat kebenaran muncul.

RevOps perlu memantau:

• Kadar kelengkapan medan
• Nilai sementara
• Soalan sokongan
• Ralat aliran kerja
• Kegagalan automasi
• Perubahan dashboard
• Maklum balas pengurus
• Jalan pintas pengguna
• Amaran kualiti data

Jika penerimaan lemah, jangan terus melompat kepada "pengguna memerlukan latihan." Medan itu mungkin tidak jelas. Masanya mungkin salah. Aliran kerja itu mungkin terlalu berat. Pengurus mungkin tidak mengukuhkannya. Perubahan itu mungkin menyelesaikan masalah pelaporan sambil menambah geseran pengguna.

Semakan selepas pelancaran perlu menghasilkan satu keputusan: kekalkan, tala, tangguh, atau rollback.

Ukur kejayaan perubahan dengan isyarat operasi

Kejayaan perubahan bukan "kami melancarkannya."

Ukur sama ada perubahan itu mengubah tingkah laku dan memperbaiki aliran kerja yang dimaksudkan.

Metrik perlu sepadan dengan sebab perniagaan. Jika sebab perniagaan itu ialah serah tugas pelanggan yang lebih baik, jangan hanya ukur kelengkapan medan. Ukur sama ada customer success menggunakan medan itu.

Contoh: mengubah peraturan peringkat opportunity

Andaikan kepimpinan jualan mahu mengetatkan peringkat opportunity kerana kualiti pipeline lemah.

Perubahan admin mungkin mudah: kemaskini definisi peringkat, tambah medan wajib, dan laraskan susun atur halaman. Perubahan operasi lebih besar.

RevOps perlu semak:

• Opportunity semasa mana yang memerlukan migrasi
• Sama ada wakil jualan memerlukan contoh deal yang sepatutnya bergerak ke belakang
• Sama ada pengurus memahami bukti baharu yang diperlukan pada setiap peringkat
• Sama ada laporan ramalan akan bergerak selepas pembersihan peringkat
• Sama ada liputan pipeline akan kelihatan lebih kecil untuk satu atau dua kitaran
• Sama ada bukti keluar peringkat perlu didokumenkan dalam kriteria keluar peringkat

Jika perubahan itu dilancarkan tanpa konteks, pengguna akan menganggapnya sebagai geseran yang sewenang-wenangnya. Jika perubahan itu dilancarkan dengan contoh dan pemeriksaan pengurus, pasukan belajar piawaian baharu itu.

Contoh: mengubah atribusi sumber

Perubahan atribusi berisiko kerana ia menjejaskan pemasaran, jualan, finance, dan pelaporan eksekutif.

Sebelum mengubah medan sumber, RevOps perlu mendokumenkan:

• Sumber mana yang asal
• Sumber mana yang terkini
• Sumber mana yang boleh ditulis semula
• Sumber mana yang muncul dalam pelaporan kepada lembaga
• Titik sentuh kempen mana yang dikira sebagai pengaruh
• Pasukan mana yang memiliki pembetulan sumber
• Bagaimana laporan sejarah akan dikendalikan

Pemasaran perlu tahu bagaimana pengaruh kempen akan diukur. Jualan perlu tahu sama ada penghalaan berubah. Finance perlu tahu sama ada garis trend sejarah terganggu. Konfigurasi CRM mungkin mengambil masa satu petang. Kerja kepercayaan mengambil masa lebih lama.

Di sinilah pengurusan perubahan CRM berkait langsung dengan lead-to-revenue attribution. Jika definisi berubah tanpa pelan pelancaran, data mungkin lebih bersih dari segi teknikal tetapi kurang dipercayai dari segi operasi.

Contoh: mengubah kategori ramalan

Perubahan kategori ramalan mencipta dua jenis risiko.

Risiko pertama bersifat tingkah laku. Pengurus dan wakil jualan mungkin tidak tahu apa yang layak sebagai commit, kes terbaik, atau pipeline di bawah peraturan baharu.

Risiko kedua bersifat sejarah. Garis trend ramalan mungkin bergerak walaupun realiti perniagaan tidak berubah.

Sebelum pelancaran, RevOps perlu:

• Dokumenkan definisi baharu
• Semak contoh bersama pengurus
• Bandingkan pandangan ramalan lama dan baharu untuk sekurang-kurangnya satu kitaran
• Putuskan sama ada rekod sejarah akan dimigrasikan
• Tambah nota pada dashboard di mana definisi berubah
• Sediakan pemilik panggilan ramalan untuk soalan

Jenis perubahan ini perlu berkait dengan forecast governance, bukan dianggap sebagai kemaskini admin CRM peribadi.

Contoh: mengubah peraturan penghalaan atau SLA

Perubahan penghalaan terasa operasi sehingga ia mencipta masalah keadilan, kapasiti, dan masa tindak balas.

Sebelum mengubah logik penghalaan, RevOps perlu memeriksa:

• Pasukan mana yang akan memperoleh atau kehilangan volum lead
• Sama ada wilayah masih sepadan dengan liputan
• Sama ada peraturan kapasiti adalah semasa
• Sama ada penghalaan luar waktu berfungsi dengan betul
• Sama ada pengurus memahami barisan pengecualian
• Sama ada laporan SLA akan berubah

Pelancaran perlu merangkumi contoh sebelum-dan-selepas. Tunjukkan apa yang akan berlaku kepada satu lead di bawah peraturan lama dan apa yang akan berlaku di bawah peraturan baharu.

Ini mengelakkan aduan penghalaan yang paling biasa: "Kenapa saya mendapat lead ini?" Apabila pengguna memahami logik itu, mereka lebih berkemungkinan mempercayai penetapan tersebut.

Bina irama perubahan

Pengurusan perubahan CRM berfungsi lebih baik sebagai irama berbanding timbunan tiket.

Untuk kebanyakan pasukan yang berkembang, semakan perubahan CRM mingguan atau dwi-mingguan sudah mencukupi. Ia perlu ringkas dan fokus kepada keputusan.

Agenda yang dicadangkan:

1. Semak permintaan baharu.
2. Klasifikasikan risiko.
3. Luluskan atau tolak perubahan berisiko rendah.
4. Tetapkan pemilik untuk perubahan berisiko sederhana dan tinggi.
5. Semak ujian untuk pelancaran akan datang.
6. Periksa metrik selepas pelancaran daripada perubahan terkini.
7. Kenal pasti medan atau aliran kerja yang perlu disarakan.

Irama ini menghalang CRM daripada berubah secara senyap setiap hari. Pengguna tidak perlu tahu setiap butiran admin, tetapi pasukan operasi perlu mempunyai irama terkawal untuk perubahan.

Simpan log perubahan

Log perubahan bukan teater dokumentasi. Ia adalah ingatan.

Sekurang-kurangnya, log:

• Nama perubahan
• Tarikh
• Pemilik
• Tahap risiko
• Objek yang terjejas
• Sebab perniagaan
• Pengguna yang terjejas
• Laporan yang terjejas
• Nota rollback
• Hasil selepas pelancaran

Enam bulan kemudian, seseorang akan bertanya kenapa satu medan wujud, kenapa satu definisi laporan berubah, atau kenapa satu aliran kerja bertingkah laku dengan cara tertentu. Log perubahan perlu menjawab tanpa memerlukan penggalian arkib Slack.

Rancang rollback sebelum pelancaran

Rollback tidak selalu bermaksud "batalkan segala-galanya."

Kadangkala ia bermaksud:

• Lumpuhkan satu peraturan pengesahan
• Jadikan satu medan wajib sebagai pilihan
• Tangguhkan satu automasi
• Pulihkan satu penapis laporan lama
• Buka semula penghalaan manual selama seminggu
• Sembunyikan satu medan daripada susun atur sambil mengekalkan data utuh
• Pindahkan satu pelancaran kembali kepada kumpulan rintis (pilot)

Pelan rollback perlu spesifik. "RevOps akan memantau dan melaraskan" bukan satu pelan. Pelan sebenar menyatakan apa yang akan dimatikan, siapa yang boleh meluluskannya, dan apa yang berlaku kepada rekod yang sudah terjejas.

Sarakan perubahan yang sudah tidak lagi wajar

Pengurusan perubahan CRM bukan hanya tentang menambah perkara.

Ia juga tentang membuang medan, peraturan, laporan, dan aliran kerja yang sudah tidak lagi menyokong satu keputusan.

Semakan suku tahunan perlu bertanya:

• Medan mana yang mempunyai kelengkapan rendah dan tiada pemilik aktif?
• Laporan mana yang sudah tidak digunakan lagi?
• Peraturan automasi mana yang mencipta lebih banyak pengecualian berbanding nilai?
• Nilai picklist mana yang tidak jelas atau tidak digunakan?
• Medan wajib mana yang mencipta data sementara?
• Dashboard mana yang menduakan sumber yang lebih baik?

Persaraan adalah sebahagian daripada pengurusan perubahan kerana setiap medan lama bersaing untuk perhatian pengguna dengan setiap medan baharu.

Kesilapan perubahan CRM biasa

Menambah medan tanpa pemilik. Satu medan tanpa pemilik akan mereput dengan cepat.

Mewajibkan medan terlalu awal. Pengguna memasukkan nilai palsu kerana data itu belum boleh diketahui lagi.

Mengubah laporan tanpa amaran. Pemimpin kehilangan kepercayaan apabila angka bergerak tanpa konteks.

Melangkau pemerkasaan pengurus. Pengguna mendengar perubahan itu sekali sahaja dan kemudian kembali kepada tingkah laku lama.

Menguji hanya laluan lancar. Perubahan itu berfungsi untuk rekod sempurna tetapi gagal untuk import, deal lama, kebenaran, atau integrasi.

Tiada pelan rollback. Satu automasi yang buruk terus berjalan kerana tiada siapa merancang cara menghentikannya.

Menganggap pelancaran sebagai penyelesaian. Perubahan itu tidak lengkap sehingga penerimaan dan kualiti data disemak.

Mengelirukan komunikasi dengan penerimaan. Satu siaran Slack tidak mengubah tingkah laku. Pemeriksaan pengurus yang melakukannya.

Pakej perubahan yang praktikal

Untuk perubahan CRM berisiko sederhana atau tinggi, cipta satu pakej sehalaman.

Pakej ini memberikan RevOps ingatan. Tiga bulan kemudian, pasukan perlu masih tahu kenapa perubahan itu wujud.

Rupa yang baik

Pengurusan perubahan CRM yang baik adalah senyap.

Pengguna tahu apa yang berubah. Pengurus tahu apa yang perlu diperiksa. Dashboard masih diselaraskan. Customer success menerima konteks serah tugas yang lebih baik. Finance memahami perubahan metrik sebelum mesyuarat. RevOps melihat data penerimaan dan membaiki isu kecil sebelum ia menjadi ketidakpercayaan sistem.

Isyarat terbaik bukanlah tiada siapa mengadu. Isyarat terbaik ialah perubahan itu memperbaiki satu aliran kerja sebenar dan data kekal boleh digunakan.

Itu juga bermaksud perubahan itu mempunyai ingatan. Enam bulan kemudian, RevOps perlu dapat menerangkan kenapa satu medan, aliran kerja, atau laporan wujud. Jika tiada siapa dapat menerangkan sebab perniagaan itu, perubahan itu perlu disemak. Inilah cara pengurusan perubahan CRM berkait dengan persaraan medan, kepercayaan dashboard, dan penerimaan jangka panjang.

Model kematangan

Pengurusan perubahan CRM biasanya matang melalui empat peringkat.

Kebanyakan pasukan boleh bergerak daripada reaktif kepada diurus dengan pantas dengan menambah pengambilan, tahap risiko, dan semakan selepas pelancaran. Peralihan yang paling sukar bersifat budaya: menganggap perubahan CRM sebagai perubahan operasi, bukan tiket admin.

Pakej kelulusan perubahan CRM

Setiap perubahan CRM yang bermakna perlu mempunyai pakej kelulusan.

Ini mengekalkan pengurusan perubahan CRM praktikal. Matlamatnya bukan untuk melambatkan semua perubahan. Matlamatnya ialah mencegah perubahan senyap daripada merosakkan operasi hasil yang dikongsi.

Soalan Lazim

Siapa yang patut meluluskan perubahan CRM?

RevOps perlu meluluskan perubahan yang menjejaskan data hasil yang dikongsi, aliran kerja, dashboard, atau integrasi. Perubahan berisiko tinggi perlu melibatkan pemimpin fungsian yang terjejas. Pasukan finance, IT, keselamatan, atau data perlu menyertai apabila pelaporan, pengebilan, kebenaran, privasi, atau integrasi terjejas.

Kenapa perubahan CRM menjejaskan penerimaan?

Ia menjejaskan penerimaan apabila pengguna mengalaminya sebagai kerja tambahan tanpa konteks. Satu medan wajib dengan kegunaan operasi yang jelas lebih mudah diterima berbanding medan yang terasa seperti beban pelaporan.

Berapa kerap RevOps patut melancarkan perubahan CRM?

Kebanyakan pasukan patut mengumpulkan perubahan berisiko sederhana ke dalam irama pelancaran mingguan atau dwi-mingguan. Pembaikan berisiko rendah boleh bergerak lebih pantas. Perubahan berisiko tinggi dan kritikal memerlukan tetingkap pelancaran, pratonton pengurus, dan semakan selepas pelancaran.

Apa perbezaan antara pengurusan perubahan CRM dan governance CRM?

Pengurusan perubahan mengawal bagaimana perubahan individu bergerak daripada permintaan kepada penerimaan. Governance mentakrifkan peraturan, pemilik, definisi, dan irama semakan yang mengekalkan CRM boleh digunakan dari semasa ke semasa. Pengurusan perubahan adalah satu lapisan operasi di dalam governance.

Ketahui lebih lanjut

• CRM Adoption Operating Model
• Revenue Data Dictionary
• RevOps Charter
• Revenue Process Audit