در یک تیم فروش، کارشناس جدیدی به گروه پشتیبانی منتقل می‌شود، اما دسترسی قبلی او به فرصت‌های فروش همچنان فعال می‌ماند. چند ماه بعد، یک کاربر قدیمی که دیگر با شرکت همکاری نمی‌کند هنوز در فهرست کاربران دیده می‌شود. چنین وضعیت‌هایی معمولا از یک تصمیم اشتباه شروع نمی‌شوند؛ از بازبینی‌نشدن تصمیم‌های قدیمی به وجود می‌آیند.
بازبینی دسترسی CRM کمک می‌کند مشخص شود هر کاربر چه اطلاعاتی را می‌بیند، چه تغییری می‌تواند ایجاد کند و کدام دسترسی دیگر برای کارش لازم نیست. در این نوشته، یک روش دوره‌ای و قابل اجرا برای کنترل نقش‌ها، سطح مشاهده اطلاعات، کاربران غیرفعال و تغییرات دسترسی می‌سازیم؛ روشی که مدیر فروش، مدیر پشتیبانی و مسئول امنیت اطلاعات بتوانند روی آن توافق کنند.
چرا تنظیم اولیه دسترسی برای همیشه کافی نیست؟
تنظیم دسترسی معمولا هنگام راه‌اندازی CRM انجام می‌شود. آن زمان نقش‌ها مشخص‌اند: مدیر فروش، کارشناس فروش، پشتیبان، مدیر سیستم یا مدیر ارشد. اما ساختار تیم ثابت نمی‌ماند. افراد جابه‌جا می‌شوند، مسئولیت‌ها تغییر می‌کنند، تیم جدید شکل می‌گیرد و بعضی فرایندها از فروش به پشتیبانی منتقل می‌شوند.
دسترسی قدیمی در چنین شرایطی ممکن است بدون توجه باقی بماند. کاربری که زمانی به همه فرصت‌های فروش نیاز داشت، شاید اکنون فقط پرونده‌های پشتیبانی را پیگیری کند. کارشناس موقتی که برای یک پروژه اضافه شده، ممکن است پس از پایان پروژه همچنان به اطلاعات مشتریان دسترسی داشته باشد.
مشکل فقط دیدن اطلاعات نیست. امکان ویرایش، حذف، انتقال مالکیت، تغییر مرحله فرصت فروش یا مشاهده مکالمات هم اهمیت دارد. دو کاربر ممکن است هر دو یک پرونده را ببینند، اما فقط یکی از آن‌ها اجازه تغییر اطلاعات داشته باشد. بنابراین کنترل دسترسی باید دو پرسش جدا را پاسخ دهد:
کاربر چه چیزهایی را می‌بیند؟ کاربر روی آن اطلاعات چه کاری می‌تواند انجام دهد؟
اصل حداقل دسترسی می‌گوید هر نفر باید فقط به اطلاعات و عملیاتی دسترسی داشته باشد که برای انجام مسئولیت فعلی‌اش لازم است. این اصل به معنی سخت‌گیری بی‌دلیل نیست. اگر کارشناس فروش برای پیگیری فرصت‌ها به اطلاعات کافی دسترسی نداشته باشد، فرایند فروش مختل می‌شود. سطح مناسب را باید بر اساس نقش واقعی و کار روزانه تعیین کرد، نه بر اساس عنوان شغلی تنها.
چه رویدادهایی باید کنترل دسترسی را فعال کنند؟
بازبینی نباید فقط به یک تاریخ در تقویم وابسته باشد. بعضی اتفاق‌ها باید همان زمان، کنترل دسترسی را فعال کنند. این رویدادها را می‌توان در یک فهرست داخلی ثبت کرد تا مدیر مربوطه بداند چه زمانی باید بررسی را آغاز کند.
تغییر نقش یا مسئولیت
وقتی کارشناس فروش به سرپرست فروش تبدیل می‌شود، احتمالا به گزارش‌های بیشتری نیاز پیدا می‌کند؛ اما این تغییر نباید خودکار به دسترسی نامحدود منجر شود. ابتدا وظایف جدید را بنویسید، سپس فقط اطلاعات و عملیات لازم را به نقش تازه اضافه کنید.
همین موضوع برای کاهش مسئولیت هم مهم است. اگر سرپرست به نقش کارشناس برمی‌گردد، دسترسی‌های مدیریتی قبلی باید دوباره بررسی شود. باقی‌ماندن دسترسی بیشتر از نیاز فعلی، یکی از رایج‌ترین شکل‌های دسترسی اضافی است.
جابه‌جایی بین فروش و پشتیبانی
در یک کسب‌وکار، فروش و پشتیبانی هر دو با پرونده مشتری کار می‌کنند، اما نیازهایشان یکسان نیست. فروشنده به فرصت فروش، مرحله مذاکره و اقدام بعدی توجه دارد. پشتیبان بیشتر به سابقه مکالمات، درخواست‌ها و تعهدهای پس از فروش نیاز دارد.
اگر کاربر از یک تیم به تیم دیگر منتقل شد، دسترسی قبلی را نگه ندارید تا بعدا تصمیم بگیرید. ابتدا نقش قبلی را بررسی و سپس نقش جدید را تعریف کنید. برای چنین سناریویی، مطالعه راهنمای تفکیک دسترسی فروش و پشتیبانی می‌تواند به طراحی ماتریس نقش‌ها و اطلاعات کمک کند.
خروج کاربر از شرکت یا پایان همکاری
این مورد باید خارج از تقویم دوره‌ای و در همان زمان خروج انجام شود. حساب کاربر را بدون بررسی سابقه فعالیت حذف نکنید؛ ابتدا مسئولیت پرونده‌ها، اقدام‌های باز و مکالمات مرتبط را مشخص کنید. سپس دسترسی ورود را ببندید و وضعیت حساب را ثبت کنید.
اگر کاربر پیمانکار یا نیروی موقت است، تاریخ پایان دسترسی را از ابتدا مشخص کنید. دسترسی موقت بدون تاریخ پایان، معمولا به دسترسی دائمی تبدیل می‌شود.
اضافه‌شدن یک ماژول یا فرایند تازه
راه‌اندازی گردش کار جدید، گزارش مدیریتی تازه یا فرایند تحویل مشتری می‌تواند نقش‌ها را تغییر دهد. قبل از فعال‌کردن قابلیت جدید، مشخص کنید چه کسانی باید آن را ببینند و چه کسانی فقط نتیجه آن را دریافت کنند.
مشاهده یک رفتار غیرعادی
تلاش ناموفق برای ورود، تغییر ناگهانی مالکیت چند پرونده یا دسترسی یک کاربر به اطلاعاتی خارج از وظیفه‌اش، دلیل خوبی برای کنترل زودتر از موعد است. لازم نیست هر رفتار متفاوت را تخلف بدانید؛ ابتدا سابقه کار و نیاز واقعی کاربر را بررسی کنید.
چک‌لیست بررسی نقش‌ها و سطح مشاهده اطلاعات
برای اینکه کنترل به گفت‌وگویی کلی درباره «دسترسی زیاد» تبدیل نشود، بررسی را با یک جدول ساده انجام دهید. برای هر نقش یا کاربر، پاسخ این موارد را ثبت کنید:
1. نقش واقعی کاربر را بنویسید
عنوان سازمانی را کنار بگذارید و کار واقعی را توضیح دهید. برای نمونه، «کارشناس فروش سازمانی که فرصت‌های شرکت‌های بزرگ را پیگیری می‌کند» دقیق‌تر از «کارشناس فروش» است.
در این توضیح بنویسید که کاربر با کدام نوع مشتری یا فرصت کار می‌کند، مالک اصلی پرونده‌هاست یا فقط همکار پرونده، اطلاعات را ثبت می‌کند، می‌خواند یا تأیید می‌کند و مسئول پیگیری روزانه است یا فقط گزارش می‌گیرد.
2. اطلاعات قابل مشاهده را مشخص کنید
فهرست اطلاعات را به بخش‌های جدا تقسیم کنید. در یک CRM معمولی ممکن است این بخش‌ها شامل مشتری، فرصت فروش، مکالمه، فعالیت، اقدام بعدی، تیکت یا گزارش مدیریتی باشد.
برای هر بخش، یکی از این وضعیت‌ها را ثبت کنید: مشاهده ندارد، مشاهده محدود دارد، مشاهده پرونده‌های خودش را دارد، مشاهده پرونده‌های تیم را دارد یا مشاهده همه اطلاعات را دارد.
«همه اطلاعات» را گزینه پیش‌فرض نگذارید. اگر مدیر فروش باید گزارش کل تیم را ببیند، این نیاز را جدا از دسترسی به جزئیات تمام پرونده‌ها بررسی کنید.
3. عملیات مجاز را جداگانه بررسی کنید
مشاهده و ویرایش را یکی نگیرید. برای هر بخش مشخص کنید کاربر می‌تواند رکورد جدید بسازد، اطلاعات موجود را ویرایش کند، رکورد را حذف کند، مالک پرونده را تغییر دهد، مرحله فرصت فروش را تغییر دهد، اقدام بعدی بسازد یا موعد آن را جابه‌جا کند و گزارش بگیرد یا اطلاعات را صادر کند.
در بسیاری از تیم‌ها، مشکل اصلی از دسترسی مشاهده به وجود نمی‌آید؛ از امکان تغییر یا حذف اطلاعات ایجاد می‌شود. بنابراین این بخش را با دقت بیشتری بررسی کنید.
4. محدوده دسترسی را کنترل کنید
کاربر شاید به همه پرونده‌ها نیاز نداشته باشد. بررسی کنید دسترسی او بر اساس کدام محدوده تعریف شده است: پرونده‌های متعلق به خودش، پرونده‌های تیم خودش، منطقه یا شعبه مشخص، نوع مشتری یا بازار مشخص و تمام اطلاعات سازمان.
اگر محدوده‌ای تعریف نشده، دلیلش را ثبت کنید. گاهی همه اعضای تیم باید اطلاعات مشترکی را ببینند؛ گاهی این تصمیم فقط از روی عادت باقی مانده است.
5. دسترسی گزارش‌ها را جدی بگیرید
گزارش مدیریتی ممکن است اطلاعاتی را کنار هم نشان دهد که در صفحه عادی برای کاربر قابل مشاهده نیست. بررسی کنید گزارش‌ها چه داده‌هایی دارند و چه کسانی باید آن‌ها را ببینند.
برای نمونه، کارشناس فروش شاید به گزارش عملکرد خودش نیاز داشته باشد، اما گزارش مقایسه‌ای کل تیم یا اطلاعات مالی برای او ضروری نباشد. دسترسی گزارش را بر اساس تصمیمی که کاربر باید بگیرد تنظیم کنید، نه صرفا بر اساس علاقه به دیدن اطلاعات بیشتر.
چگونه کاربران غیرفعال و دسترسی‌های اضافی را پیدا کنیم؟
فهرست کاربران را به دو گروه تقسیم کنید: کاربرانی که هنوز مسئولیت فعال دارند و کاربرانی که وضعیتشان نامشخص است. گروه دوم معمولا شامل حساب‌های قدیمی، کاربران موقت، حساب‌های آزمایشی و افرادی است که تیمشان تغییر کرده است.
برای هر کاربر نامشخص، این پرسش‌ها را پاسخ دهید: آیا هنوز با سازمان همکاری می‌کند؟ آیا در ماه گذشته به CRM وارد شده است؟ آیا پرونده یا اقدام بعدی فعالی به نام او وجود دارد؟ آیا مسئولیت پرونده‌هایش به فرد دیگری منتقل شده است؟ آیا حساب او برای یک کار مشخص و محدود ساخته شده بود؟ آیا دسترسی او بیشتر از نقش فعلی‌اش است؟
به ورودنداشتن کاربر به‌تنهایی تکیه نکنید. ممکن است کاربر چند هفته در مرخصی باشد یا وظیفه‌اش فصلی باشد. سابقه مالکیت پرونده‌ها و اقدام‌های باز را هم ببینید.
برای حسابی که دیگر لازم نیست، سه کار را جدا انجام دهید: دسترسی ورود را غیرفعال کنید، مسئولیت‌های باز را منتقل کنید و دلیل تغییر را ثبت کنید. حذف عجولانه حساب ممکن است سابقه فعالیت یا ارتباط آن با پرونده‌ها را برای تیم نامفهوم کند. اگر حساب مشترک وجود دارد، آن را هم شناسایی کنید. حساب مشترک مشخص نمی‌کند چه کسی اطلاعات را تغییر داده و با اصل پاسخ‌گویی سازگار نیست.
برای جلوگیری از برگشت دسترسی‌های اضافی، فهرست نقش‌ها را هم پاک‌سازی کنید. نقش‌هایی که دیگر استفاده نمی‌شوند، مجوزهای آزمایشی و استثناهای قدیمی را نگه ندارید. هر استثنا باید صاحب مشخص و دلیل قابل بررسی داشته باشد.
در راهنمای امنیت داده و سلسله‌مراتب دسترسی در CRM، موضوع‌هایی مانند نقش‌ها، حساب‌های مشترک و بستن به‌موقع دسترسی با جزئیات بیشتری بررسی شده است.
تغییرات دسترسی را چگونه ثبت و تأیید کنیم؟
تغییر دسترسی بدون ثبت، بعدا قابل توضیح نیست. یک برگه یا رکورد داخلی برای تغییرات بسازید و برای هر تغییر این اطلاعات را بنویسید: نام کاربر، نقش قبل و نقش بعد، دلیل تغییر، بخش‌های اطلاعاتی تحت تأثیر، عملیات اضافه یا حذف‌شده، درخواست‌کننده تغییر، تأییدکننده تغییر، تاریخ اجرا، تاریخ بازبینی بعدی و وضعیت نهایی.
برای تغییرهای ساده، یک تأییدکننده از مدیر همان تیم کافی است. تغییرهایی که دسترسی گسترده، گزارش‌های حساس، حذف اطلاعات یا انتقال مالکیت پرونده‌ها را دربرمی‌گیرند، بهتر است با تأیید مسئول امنیت اطلاعات یا مدیر ارشد انجام شوند.
ثبت تغییر فقط برای کنترل امنیتی نیست. این سابقه به مدیر کمک می‌کند بفهمد چرا یک کاربر به اطلاعاتی دسترسی دارد. اگر چند ماه بعد کسی درباره یک مجوز پرسید، پاسخ باید در سابقه تصمیم وجود داشته باشد، نه در حافظه یکی از اعضای تیم.
پس از اجرای تغییر، کنترل دوم انجام دهید. از کاربر بخواهید یک کار واقعی را آزمایش کند: دیدن پرونده خودش، ثبت فعالیت یا مشاهده گزارش مربوط به نقش. نتیجه را ثبت کنید. گاهی مجوزی که روی کاغذ درست به نظر می‌رسد، در کار واقعی بیش از حد باز یا بیش از حد محدود است.
تقویم پیشنهادی برای کنترل دوره‌ای دسترسی
یک زمان‌بندی ثابت، رسیدگی را از حالت واکنشی خارج می‌کند. فاصله مناسب به اندازه تیم، حساسیت اطلاعات و سرعت تغییرات بستگی دارد، اما می‌توانید از این الگو شروع کنید:
هر روز یا هم‌زمان با خروج کاربر
بستن دسترسی فردی که همکاری‌اش تمام شده است، انتقال پرونده‌ها و اقدام‌های باز، بررسی حساب‌های موقت با تاریخ پایان و ثبت دلیل و زمان تغییر را انجام دهید.
هر ماه
کاربران جدید و نقش‌های تازه‌ساخته‌شده را مرور کنید، حساب‌های غیرفعال را بررسی کنید، دسترسی‌های موقت باقی‌مانده را پیدا کنید، تغییرات انجام‌شده در ماه گذشته را بررسی کنید و حساب‌های مشترک را کنترل کنید.
هر فصل
نقش واقعی افراد را با سطح دسترسی آن‌ها مقایسه کنید، دسترسی مشاهده و ویرایش برای مشتری، فرصت و مکالمه را مرور کنید، گزارش‌های مدیریتی را بررسی کنید، نقش‌های بدون استفاده را کنترل کنید و تأیید مدیران فروش و پشتیبانی را دریافت کنید.
هر شش ماه یا سالانه
ماتریس نقش‌ها را بازطراحی کنید، ساختار تیم‌ها و شعبه‌ها را بررسی کنید، فرایندهای تازه‌اضافه‌شده را کنترل کنید، استثناهای قدیمی را مرور کنید و تصمیم‌های مهم را برای دوره بعد مستند کنید.
اگر تیم شما کوچک است و تغییرات کمی دارد، ممکن است بازبینی فصلی کافی باشد. اگر اطلاعات مشتریان حساس است یا افراد زیادی بین تیم‌ها جابه‌جا می‌شوند، فاصله کوتاه‌تری انتخاب کنید. مهم‌تر از انتخاب عدد ثابت، اجرای منظم و ثبت نتیجه است.
پرسش‌های رایج
اگر کاربر به چند تیم کمک می‌کند، چه نقشی برای او بسازیم؟
ابتدا وظایف مشترک و وظایف اختصاصی او را جدا کنید. اگر یک نقش پایه پاسخ‌گوست، همان نقش را نگه دارید و فقط مجوزهای لازم برای وظایف دوم را اضافه کنید. دادن نقش مدیریتی کامل برای حل یک نیاز محدود، انتخاب مناسبی نیست.
حساب کاربری فردی را حذف کنیم یا غیرفعال؟
بستگی دارد به اینکه سابقه فعالیت و مسئولیت‌های آن حساب برای گزارش‌ها و پرونده‌ها لازم است یا نه. پیش از هر تصمیم، مالکیت پرونده‌ها را منتقل و سابقه تغییرات را ثبت کنید. در بسیاری از موارد، غیرفعال‌کردن کنترل‌شده از حذف فوری قابل بررسی‌تر است.
اگر مدیر تیم با همه اطلاعات کار می‌کند، اصل حداقل دسترسی نقض می‌شود؟
نه لزوما. اگر تصمیم‌های شغلی مدیر به مشاهده همه پرونده‌های تیم نیاز دارد، این دسترسی می‌تواند توجیه داشته باشد. باید دلیل، محدوده و مسئولیت آن روشن باشد. دسترسی مدیر هم نباید خودکار شامل حذف یا تغییر همه داده‌ها شود.
هر چند وقت یک‌بار نقش‌ها را از صفر طراحی کنیم؟
بازطراحی کامل را می‌توان سالانه یا هنگام تغییر جدی ساختار انجام داد. اما بررسی کاربران، خروج افراد و تغییر مسئولیت‌ها باید در فاصله‌های کوتاه‌تر انجام شود. بازطراحی کامل جایگزین کنترل‌های ماهانه و فصلی نیست.
چه کسی مالک این فرایند باشد؟
یک نفر باید هماهنگ‌کننده باشد، اما تصمیم‌ها بهتر است بین مدیر فروش، مدیر پشتیبانی و مسئول امنیت اطلاعات تقسیم شود. مدیر هر تیم نیاز کاری را توضیح می‌دهد و مسئول امنیت، ریسک و ثبت تصمیم را بررسی می‌کند.
از فردا این روند را شروع کنید
فهرست همه کاربران و نقش‌های فعلی را استخراج کنید و کنار هر نام، نقش واقعی، محدوده مشاهده، عملیات مجاز و وضعیت همکاری را بنویسید. سپس حساب‌های نامشخص را جدا کنید و برای هرکدام مالک پرونده و تصمیم بعدی تعیین کنید.
در مرحله بعد، یک تقویم ماهانه و فصلی بسازید. تغییرات خروج، جابه‌جایی تیم و اضافه‌شدن نقش را به رویدادهای فوری تبدیل کنید و برای هر تغییر، تأییدکننده مشخص داشته باشید. اگر برای طراحی فرایندهای فروش و پشتیبانی یا تنظیم دسترسی‌های متناسب با ساختار تیم به اطلاعات بیشتری نیاز دارید، راهکارهای کلید برای مدیریت فروش و ارتباط با مشتری و صفحه تماس با کلید نقطه شروع مناسبی هستند. مهم این است که کنترل دسترسی از یک تنظیم اولیه به بخشی از کار منظم تیم تبدیل شود.