Bahasa Melayu

Menetapkan Peranan dan Kebenaran CRM dengan Betul

Keputusan kawalan akses yang anda buat pada minggu pertama pelancaran CRM anda cenderung untuk menghantui anda enam bulan kemudian. VP yang diberi hak pentadbir "untuk memudahkan segalanya" mula mengeksport seluruh pangkalan data kenalan. Wakil jualan baharu secara tidak sengaja memadamkan urusan yang sedang dalam rundingan selama empat bulan. Seorang pengurus tidak dapat melihat Pipeline pasukannya kerana seseorang menetapkan keterlihatan rekod kepada "peribadi" secara lalai.

Setiap satu daripada ini bukan bencana secara individu. Tetapi ia masing-masing memerlukan kerja tidak dirancang untuk diperbaiki, ia menjejaskan kepercayaan terhadap sistem, dan ia sering mencetuskan eskalasi tiket IT yang melambatkan pelancaran pada saat anda memerlukan momentum.

Penyelesaiannya bukan konfigurasi perisian yang rumit. Ia adalah melakukan kerja reka bentuk di atas kertas sebelum anda membuka panel tetapan.

Mengapa Kebenaran Lebih Penting Daripada Yang Anda Sangka

Kebanyakan pasukan CRM memikirkan kebenaran dari segi pematuhan IT: siapa yang sepatutnya boleh melihat apa. Itu penting, tetapi bukan gambaran keseluruhan.

Kebenaran juga membentuk tingkah laku. Apabila wakil jualan tidak dapat melihat urusan satu sama lain, kerjasama terhenti. Apabila pengurus boleh melihat semua tetapi tidak dapat mengedit apa-apa, mereka berhenti mencatat nota. Apabila pentadbir mempunyai hak pemadaman tanpa sekatan, kemalangan berlaku.

Terdapat juga risiko undang-undang dan persaingan yang nyata. CRM yang terlalu luas kebenaranannya boleh mendedahkan penetapan harga sulit, peta jalan produk yang belum dikeluarkan, dan data kenalan peribadi kepada pekerja yang tidak mempunyai keperluan yang sah untuk mengaksesnya. Di bawah GDPR dan CCPA, "kami memberi semua orang akses kerana ia lebih mudah" bukan pendirian yang boleh dipertahankan.

Dan secara praktikal: masalah kebenaran jauh lebih sukar untuk diperbaiki selepas pelancaraan rasmi berbanding sebelumnya. Setelah 40 wakil jualan telah di-Onboarding dengan tahap akses yang salah, menetapkan semula kebenaran mereka menyebabkan kekeliruan dan mencetuskan gelombang permintaan sokongan. Lakukan dengan betul pada minggu pertama. Jika anda belum mengunci model data CRM anda lagi, lakukan itu dahulu kerana medan dan objek yang anda lindungi bergantung pada cara rekod anda disusun.

Langkah 1: Petakan Peranan Pekerjaan kepada Keperluan Data, Bukan Jawatan Carta Organisasi

Ini adalah kesilapan paling biasa dalam reka bentuk kebenaran CRM: memetakan akses kepada jawatan seseorang dan bukannya apa yang mereka sebenarnya perlu lakukan untuk melaksanakan tugas mereka.

Seorang "Senior Account Executive" dan "Strategic Account Executive" mungkin mempunyai jawatan yang sama tetapi keperluan data yang sangat berbeza. Seorang menguruskan akaun PKS di satu wilayah. Yang lain menguruskan akaun perusahaan secara global dan memerlukan akses kepada data urusan bersejarah di seluruh syarikat.

Mulakan dengan menyenaraikan tingkah laku yang melibatkan data dalam proses jualan anda:

  • Siapa yang mencipta rekod kenalan dan syarikat baharu?
  • Siapa yang boleh melihat urusan aktif yang tidak ditugaskan kepada mereka?
  • Siapa yang memerlukan data urusan yang telah ditutup-menang secara bersejarah?
  • Siapa yang meluluskan diskaun atau mengemas kini medan penetapan harga?
  • Siapa yang sepatutnya dapat menjalankan eksport atau membina laporan?
  • Siapa yang memerlukan akses baca sahaja kepada keseluruhan Pipeline untuk ramalan?

Petakan setiap tingkah laku kepada peranan pekerjaan yang memerlukannya. Anda mungkin akan berakhir dengan 5-8 profil kebenaran yang bermakna, tanpa mengira berapa banyak jawatan berbeza yang ada dalam carta organisasi anda.

Format lembaran kerja pemetaan peranan:

Tindakan Data AE SDR Pengurus RevOps Eksekutif
Cipta kenalan Ya Ya Ya Ya Tidak
Edit urusan sendiri Ya Tidak Ya Ya Tidak
Lihat semua urusan Sendiri Sendiri Pasukan Semua Semua
Padam rekod Tidak Tidak Tidak Ya Tidak
Eksport data Tidak Tidak Terhad Ya Tidak
Tetapan pentadbir Tidak Tidak Tidak Ya Tidak

Isi ini untuk peranan khusus anda sebelum menyentuh konfigurasi CRM.

Langkah 2: Fahami Tiga Dimensi Kawalan Akses

Kebanyakan CRM mempunyai tiga dimensi kawalan akses yang beroperasi secara bebas. Menurut penyelidikan Gartner mengenai keselamatan CRM, kegagalan kawalan akses berasaskan peranan adalah antara punca utama insiden tadbir urus data dalam tindanan teknologi jualan:

Pemilikan rekod, Siapa yang "memiliki" rekod dan bertanggungjawab secara utama terhadapnya. Pemilikan biasanya menentukan siapa yang muncul dalam laporan Pipeline dan siapa yang menerima peringatan automatik.

Keterlihatan, Siapa yang boleh melihat rekod dalam senarai, carian, dan laporan. Di sinilah anda mengawal sama ada urusan bersifat peribadi (pemilik sahaja), dapat dilihat oleh pasukan (hierarki pengurus wakil jualan), atau merangkumi keseluruhan organisasi.

Hak sunting, Siapa yang boleh menukar nilai medan pada rekod. Ini sering merupakan tetapan berasingan daripada keterlihatan. Seorang pengurus mungkin boleh melihat urusan yang tidak dimilikinya tetapi tidak dapat menukar tarikh tutup.

Perbezaan ini penting kerana banyak pasukan menggabungkan keterlihatan dan hak sunting. Mereka memberi pengurus akses "sunting" apabila mereka hanya memerlukan akses "lihat", yang membawa kepada penimpaan medan secara tidak sengaja dan masalah atribusi.

Pemisahan yang bersih: wakil jualan memiliki dan menyunting rekod mereka sendiri; pengurus melihat rekod pasukan mereka dan boleh menyunting medan eskalasi sahaja; RevOps dan pentadbir boleh menyunting mana-mana rekod; eksekutif mendapat paparan Portfolio baca sahaja.

Langkah 3: Bina Matriks Kebenaran Anda Sebelum Menyentuh Tetapan

Sebelum anda log masuk ke panel pentadbir CRM anda, letakkan matriks kebenaran penuh di atas kertas (atau hamparan).

Templat matriks kebenaran:

Peranan Rekod Boleh Dilihat Rekod Boleh Disunting Akses Laporan Akses Pentadbir Eksport Data
SDR Kenalan sendiri + yang ditugaskan Rekod sendiri Peribadi sahaja Tiada Tiada
Account Executive Urusan sendiri + kenalan pasukan Urusan sendiri Peribadi + pasukan Tiada Tiada
Sales Manager Urusan + kenalan pasukan Urusan pasukan (medan terhad) Pasukan + Pipeline organisasi Tiada Peringkat pasukan
RevOps Semua rekod Semua rekod Semua laporan Konfigurasi sahaja Penuh
Sales Director Semua rekod Baca sahaja kecuali yang ditugaskan Semua laporan Tiada Kelulusan diperlukan
Pentadbir IT Semua rekod Semua rekod Semua Penuh Penuh
Eksekutif Semua rekod Tiada Dashboard eksekutif Tiada Tiada

Matriks ini menjadi spesifikasi konfigurasi anda. Setiap tetapan yang anda konfigurasikan sepatutnya dapat dikesan kembali kepada sel dalam matriks ini.

Dapatkan kelulusan daripada kepimpinan jualan, IT, dan undang-undang sebelum anda membina apa-apa. Perbincangan ini sering mendedahkan perselisihan pendapat tentang siapa yang sepatutnya melihat apa. Perselisihan tersebut jauh lebih baik diselesaikan dalam hamparan berbanding dalam audit kebenaran selepas pelancaran.

Langkah 4: Sediakan Paparan Ringkasan Pengurus Tanpa Mendedahkan Data Peringkat Wakil Jualan

Salah satu konfigurasi yang lebih rumit dalam mana-mana CRM adalah memberi pengurus keterlihatan ke dalam Pipeline pasukan mereka tanpa mendedahkan data wakil jualan individu kepada rakan sebaya secara tidak sengaja.

Kebanyakan CRM mengendalikan ini melalui peranan hierarki: jika anda mengkonfigurasi hierarki organisasi (wakil jualan melapor kepada pengurus melapor kepada pengarah), keterlihatan rekod secara automatik mengalir ke atas. Seorang pengurus melihat urusan laporan langsungnya. Seorang pengarah melihat semua urusan pengurus.

Tetapi hierarki hanya berfungsi jika ia dikonfigurasikan dengan betul, dan kebanyakan pelaksanaan menjadi tidak teliti di sini:

  • Kontraktor dan wakil jualan sambilan ditempatkan di bahagian hierarki yang salah
  • Pengurus diberikan peranan peringkat pengurus yang salah (berakhir dengan keterlihatan peringkat wakil jualan)
  • Organisasi matriks di mana seorang wakil jualan mempunyai dua pengurus fungsional tetapi CRM hanya menyokong satu hierarki

Uji konfigurasi keterlihatan dengan akaun ujian sebelum menambah pengguna sebenar. Log masuk sebagai wakil jualan ujian, cipta urusan, log keluar, log masuk sebagai pengurus ujian, dan sahkan anda boleh melihat urusan tersebut. Kemudian log masuk sebagai pengurus rakan sebaya dan sahkan anda tidak dapat melihatnya.

Langkah 5: Kunci Selepas Pelancaraan Rasmi dengan Audit Kebenaran

Minggu pelancaraan rasmi adalah huru-hara. Permintaan akses saat akhir masuk. Orang diberi hak pentadbir "hanya untuk hari ini" dan tiada siapa yang membatalkannya. Log masuk berkongsi digunakan semasa Onboarding dan kemudian kekal sebagai akaun aktif.

Jadualkan audit kebenaran untuk hari ke-30 selepas pelancaran. Penyelidikan McKinsey mengenai tadbir urus perisian perusahaan menyatakan bahawa organisasi dengan kadaran semakan akses formal mengurangkan insiden pendedahan data tanpa kebenaran sebanyak lebih daripada 60% berbanding yang bergantung pada semakan ad-hoc. Semak:

  • Setiap pengguna dengan hak pentadbir atau eksport: bolehkah anda mewajarkan setiap satu?
  • Sebarang akaun berkongsi atau perkhidmatan: adakah ia mempunyai akses yang sesuai?
  • Wakil jualan yang pergi semasa pelancaran: adakah akaun mereka dinyahaktifkan?
  • Sebarang pengecualian kebenaran yang diberikan semasa pelancaran: adakah ia masih perlu?

Bina pencetus offboarding ke dalam proses HR atau IT anda: apabila seorang wakil jualan pergi, menyahaktifkan akaun CRM mereka sepatutnya menjadi item senarai semak automatik, bukan sesuatu yang berlaku apabila pengurus mereka menyedari mereka masih menerima amaran Pipeline tiga bulan kemudian. Rutin kebersihan data CRM anda sepatutnya merangkumi semakan kebenaran suku tahunan untuk menangkap sebarang akaun yang terlepas. Bagi pasukan yang melakukan pelancaran penuh, pelancaran dan penerimaan CRM merangkumi cara menjadualkan persediaan kebenaran bersama fasa Pilot.

Perangkap Biasa

Kebenaran berlebihan "untuk memudahkan segalanya." Ini hampir selalu datang daripada keinginan untuk mengelakkan tiket sokongan. Pertukaran ruginya adalah pendedahan data dan masalah tingkah laku yang tidak mudah dikesan kembali kepada punca asal. Lakukan kerja matriks terlebih dahulu. Hari tambahan konfigurasi menjimatkan anda berminggu-minggu pembersihan.

Tiada proses offboarding. Wakil jualan yang telah pergi dengan akaun CRM aktif adalah risiko keselamatan yang nyata. Kajian kos pelanggaran data Ponemon Institute secara konsisten mengenal pasti kelayakan bekas pekerja sebagai vektor serangan utama dalam persekitaran perisian perniagaan. Kelayakan log masuk mereka mungkin diketahui oleh orang lain, pemilikan rekod mereka perlu dipindahkan, dan keterlihatan mereka terhadap Pipeline aktif adalah tidak sesuai. Bina offboarding ke dalam proses, bukan selepas kejadian.

Log masuk berkongsi untuk latihan atau demo. Nampaknya mudah untuk mencipta akaun "training@company.com" untuk demo dan Onboarding. Tetapi log masuk berkongsi memintas jejak audit, mengelirukan rekod pemilikan, dan sering berakhir dengan kebenaran yang masih ada selepas ia tidak lagi diperlukan. Gunakan akaun sandbox individu atau persekitaran ujian khusus.

Tidak menguji dari pelbagai perspektif. Pentadbir sentiasa menguji sebagai pentadbir. Pastikan anda menguji konfigurasi kebenaran dengan log masuk sebagai wakil jualan ujian, pengurus ujian, dan eksekutif ujian sebelum Onboarding sesiapa pun. Anda akan menemui jurang keterlihatan dan konflik hak sunting yang kelihatan baik dari paparan pentadbir.

Templat Yang Anda Perlukan

Sebelum konfigurasi:

  • Lembaran kerja pemetaan peranan kepada akses (siapa melakukan apa dengan data mana)
  • Matriks kebenaran (setiap peranan x setiap dimensi kebenaran)
  • Senarai semak kelulusan (kepimpinan jualan, IT, undang-undang)

Selepas pelancaraan rasmi:

  • Senarai semak audit hari ke-30
  • Senarai semak pencetus offboarding
  • Log pengecualian kebenaran (menjejak sebarang pemberian ad-hoc dengan tarikh tamat tempoh)

Mengukur Kejayaan

Persediaan kebenaran yang dikonfigurasikan dengan baik sepatutnya menghasilkan hasil yang boleh diukur dalam masa 90 hari:

  • Sifar eksport data tanpa kebenaran, jika CRM anda mempunyai log audit, sifar eksport tidak dirancang dalam 90 hari pertama menandakan kawalan eksport anda berfungsi
  • Masa Onboarding di bawah 30 minit, wakil jualan baharu sepatutnya dapat masuk ke CRM, melihat rekod mereka, dan mula mencatat aktiviti tanpa menunggu tiket kebenaran diselesaikan
  • Tiada aduan pengurus "Saya tidak dapat melihat pasukan saya", ini menandakan hierarki anda dikonfigurasikan dengan betul
  • Tiada pemadaman rekod secara tidak sengaja, ini menandakan hak pemadaman anda dibataskan dengan sewajarnya

Sebelum Anda Membina, Baca Ini

Kebenaran tidak wujud secara terasing. Ia berinteraksi dengan struktur data asas dan cara rekod anda diatur. Sebelum mengkonfigurasi akses:

Ketahui Lebih Lanjut: Perbandingan CRM dan bertukar kepada Rework jika anda masih menilai platform sebelum mengunci model kebenaran anda.

Inti Pati

Kebenaran bukan tentang menyekat akses. Ia tentang menjadikan data yang betul tersedia kepada orang yang betul pada masa yang betul. Apabila dikonfigurasikan dengan baik, ia tidak kelihatan. Apabila dikonfigurasikan dengan buruk, ia menjadi penjelasan untuk setiap masalah kualiti data, setiap kebimbangan pematuhan, dan setiap wakil jualan yang mengatakan CRM "tidak berfungsi untuk Workflow saya."

Reka bentuk model di atas kertas. Dapatkan kelulusan sebelum anda membinanya. Audit selepas pelancaran. Itu sahaja.

Ketahui Lebih Lanjut: Terokai Panduan Pelaksanaan CRM yang lengkap untuk setiap langkah dari model data hingga penjejakan penerimaan. Untuk pandangan lebih luas tentang cara tadbir urus data jualan berhubung dengan prestasi hasil, lihat wawasan RevOps dan wawasan Kepimpinan Jualan.