Матрица ролей и прав доступа в CRM: как построить и не «протечь» данными

Представьте ситуацию. Новый менеджер по продажам в свой первый рабочий день открывает CRM — и видит абсолютно всё. Зарплаты коллег в карточках сделок. Персональные контакты VIP-клиентов директора. Историю переговоров по конфиденциальному тендеру. Комментарии руководителя о «проблемных» сотрудниках.

Через неделю этот менеджер уходит к конкурентам. Вместе с ним уходит вся информация, которую он успел скопировать. Руководство в шоке — как так получилось? А получилось очень просто: при настройке CRM права доступа остались «по умолчанию». То есть у всех — полный доступ ко всему.

Это не выдуманная история. Я лично разбирал подобный кейс у клиента из Алматы — компания потеряла трёх крупных клиентов, потому что бывший сотрудник знал все условия сделок и предложил им скидку «на 5% лучше». Ущерб исчислялся миллионами тенге.

Самое обидное — что предотвратить это было элементарно. Нужно было просто правильно настроить права доступа. Но почему-то именно эта часть внедрения CRM обычно откладывается «на потом». Потом превращается в никогда. А никогда превращается в инцидент.

Зачем вообще ограничивать доступ в CRM

Казалось бы, мы все свои, работаем в одной компании, делаем общее дело. Зачем городить какие-то ограничения? Пусть все видят всё — так прозрачнее и демократичнее. Некоторые руководители именно так и рассуждают. И ошибаются.

Ограничение доступа — это не про недоверие к сотрудникам. Это про защиту бизнеса от рисков. Причём рисков самых разных.

Утечка данных к конкурентам

Текучка кадров — реальность любого бизнеса. Особенно в продажах. Менеджер, который сегодня закрывает сделки для вас, завтра может работать на конкурента. И если у него был доступ ко всей клиентской базе, стратегическим ценам, условиям работы с ключевыми клиентами — считайте, что конкурент получил всё это бесплатно.

В Казахстане, где рынок во многих отраслях достаточно узкий и все друг друга знают, такие переходы случаются регулярно. И последствия бывают очень болезненными.

Внутренние конфликты и саботаж

Увольняющийся сотрудник может не просто унести данные, но и «подгадить» напоследок: удалить записи, изменить контакты клиентов, добавить некорректные комментарии в карточки. Если права настроены неправильно — вы даже не узнаете, кто это сделал.

Случайные ошибки

Не все угрозы — умышленные. Иногда сотрудник просто нажимает не ту кнопку. Массово меняет статусы сделок, случайно удаляет контакты, перезаписывает важную информацию. Если у человека есть доступ к тому, с чем он не должен работать — рано или поздно он там что-нибудь сломает. Просто по закону больших чисел.

Юридические требования

В Казахстане действует Закон «О персональных данных и их защите». Если вы храните в CRM персональные данные клиентов (а вы храните), вы обязаны обеспечить их защиту. Это включает ограничение доступа к данным теми, кому они не нужны для работы. Нарушение — штрафы и репутационные потери.

RBAC: ролевая модель доступа — с чего всё начинается

В основе любой системы управления доступом лежит концепция RBAC — Role-Based Access Control, или ролевой контроль доступа. Идея простая: вместо того чтобы настраивать права для каждого сотрудника индивидуально (что превращается в ад при 50+ пользователях), мы создаём роли и назначаем их людям.

Роль — это набор разрешений, объединённых по смыслу. Например, роль «Менеджер по продажам» может включать:

• Создание и редактирование контактов и компаний
• Создание и ведение сделок
• Просмотр задач и звонков по своим сделкам
• Выгрузка отчётов по своим продажам

А вот чего эта роль не включает:

• Просмотр сделок других менеджеров
• Удаление контактов
• Массовый экспорт всей базы
• Изменение настроек CRM

Новый менеджер приходит на работу → ему назначается роль «Менеджер по продажам» → он автоматически получает все нужные права. Уходит на повышение → меняем роль на «Руководитель отдела» → права обновляются. Увольняется → деактивируем аккаунт → доступ закрывается. Просто и понятно.

Как правильно проектировать роли

Главная ошибка при создании ролей — делать их слишком крупными или слишком мелкими. Если у вас одна роль «Сотрудник» на всех — это всё равно что не иметь ролей вообще. Если у вас 50 ролей под каждый чих — вы утонете в администрировании.

Золотая середина — роли должны отражать реальные должностные функции. Не придумывайте их из головы, а посмотрите на оргструктуру компании. Обычно получается 5-15 ролей для среднего бизнеса.

Типовые роли в CRM для отдела продаж

Матрица прав доступа: что это и как её построить

Роли — это верхний уровень. Но чтобы их настроить, нужна детализация: какие именно действия разрешены для каждой роли в каждом разделе CRM. Для этого строится матрица прав доступа.

Матрица — это таблица, где по вертикали — роли, по горизонтали — сущности CRM (контакты, компании, сделки, задачи, отчёты и т.д.) и операции с ними (создание, чтение, редактирование, удаление, экспорт). На пересечении — разрешено или нет.

Звучит просто, но есть нюанс. Для большинства сущностей нужно разделять не только «может/не может», но и область видимости:

• Свои — только записи, созданные пользователем или назначенные ему
• Команда — записи своего отдела/команды
• Организация — все записи в системе

Например, менеджер может «читать сделки — только свои», а РОП — «читать сделки — команды». Коммерческий директор — «читать сделки — организации».

Пример матрицы прав для раздела «Сделки»

Зелёный — полный доступ, жёлтый — ограниченный, красный — запрещено

Сложные сценарии: иерархии, территории, проекты

Базовая ролевая модель покрывает 80% случаев. Но реальный бизнес часто сложнее. Вот с чем можно столкнуться.

Иерархия доступа по организационной структуре

Представьте компанию с такой структурой: Генеральный директор → Директор по продажам → Региональные директора → Руководители отделов → Менеджеры. Каждый уровень должен видеть всё, что ниже него, но не то, что выше или параллельно.

Это называется иерархический доступ. РОП Алматы видит своих менеджеров, но не видит отдел продаж Астаны. Региональный директор по Казахстану видит и Алматы, и Астану, но не видит отдел СНГ.

Настраивается это через связь ролей с оргструктурой. В большинстве современных CRM есть соответствующий функционал — нужно только правильно её завести и привязать пользователей.

Территориальное разделение

Другой вариант — делить доступ не по оргструктуре, а по географии. Менеджер по Алматы видит только клиентов из Алматы. Менеджер по Западному Казахстану — только Атырау, Актау, Уральск.

Это актуально для компаний с географически распределённой структурой продаж. Настраивается через территории — сущность, которая привязывается к клиентам и менеджерам.

Проектный доступ

Иногда нужно дать доступ к конкретным сделкам или клиентам, независимо от оргструктуры. Например, на крупный тендер собирается команда из разных отделов: продажник, пресейл, юрист, финансист. Все они должны видеть эту сделку, но только эту.

Решается через команды проекта или sharing rules — правила совместного доступа. Добавляем пользователя в команду сделки → он получает доступ именно к ней.

Временный доступ

Отдельная история — когда доступ нужен временно. Аудитор приходит на проверку — ему нужно видеть определённые отчёты в течение недели. Подрядчик интегрирует систему — ему нужен доступ к API на время проекта.

Для таких случаев стоит заранее продумать процедуру: как выдаётся временный доступ, кто согласует, как автоматически отзывается по истечении срока. Иначе забытые аккаунты аудиторов будут висеть годами.

Защита критически важных полей

Права можно настраивать не только на уровне записей, но и на уровне отдельных полей. Это важно, когда одну и ту же сделку должны видеть разные люди, но с разным уровнем детализации.

Какие поля обычно требуют защиты

Финансовая информация: сумма сделки, маржинальность, себестоимость, размер скидки. Менеджеру достаточно видеть сумму продажи, а вот маржу и закупочную цену — нет. Иначе он начнёт торговаться с клиентом «снизу», отдавая всю прибыль.

Контактные данные ЛПР: личный телефон директора крупного клиента — это конфиденциальная информация. Её должен видеть только ответственный менеджер и его руководитель. Не все в компании.

Комментарии и заметки: иногда РОП пишет в карточке клиента что-то типа «ненадёжный плательщик» или «работаем только по предоплате». Эту информацию клиент видеть не должен (если вы вдруг отправите ему выгрузку), да и не все сотрудники должны.

История изменений: кто когда что менял. Критически важно для разбора инцидентов, но рядовому менеджеру может быть не нужно (и не полезно) видеть, что его коллега вчера удалил десять контактов.

Пример: роли и поля в сделке

Экспорт данных: отдельная головная боль

Экспорт заслуживает отдельного разговора. Потому что именно через экспорт чаще всего утекают данные. Если менеджер может нажать кнопку «Выгрузить в Excel» и получить всю клиентскую базу — права доступа внутри CRM теряют смысл.

Принципы ограничения экспорта

Лимиты на количество записей. Менеджер может выгрузить 50 записей за раз (достаточно для работы), но не 5000 (это уже похоже на кражу базы). Если нужно больше — обращается к руководителю.

Ограничение полей в экспорте. Даже если менеджер выгружает контакты, в выгрузку не должны попадать все поля. Телефоны — да, история переписки — нет.

Логирование экспорта. Каждая выгрузка должна фиксироваться: кто, когда, какие данные, какой объём. Если через месяц выяснится, что база утекла — вы сможете поднять логи и понять, откуда утечка.

Уведомления при крупных выгрузках. Если кто-то пытается экспортировать больше определённого объёма — руководитель должен получить уведомление. Не постфактум, а сразу.

Аудит действий: кто, что и когда делал

Права доступа — это профилактика. Но даже с идеальными правами нужен контроль того, что происходит в системе. Для этого существует аудит — логирование всех значимых действий пользователей.

Что должен фиксировать аудит

• Вход в систему: кто, когда, с какого IP/устройства
• Просмотр записей: какие карточки открывали (особенно чужие)
• Изменения данных: что было до/после, кто менял
• Удаления: что удалено, кем, есть ли возможность восстановить
• Экспорт данных: объём, тип записей, время
• Изменения прав: кто кому менял роли и доступы
• Неудачные попытки доступа: когда пользователь пытался открыть запрещённое

Как использовать данные аудита

Расследование инцидентов. Клиент жалуется, что его данные попали к конкуренту. Смотрим аудит — кто открывал карточку этого клиента за последний месяц, кто экспортировал.

Выявление аномалий. Менеджер обычно открывает 20-30 карточек в день. Сегодня открыл 500. Это подозрительно — стоит разобраться, что происходит.

Доказательная база. Если дело дойдёт до суда (а при крупных утечках доходит), логи аудита — это доказательства. Без них вы ничего не докажете.

Подробнее про аудит и контроль доступа мы писали в статье RBAC и аудит в CRM: контроль доступа для роста без хаоса.

Типичные ошибки при настройке прав доступа

За годы внедрений мы насмотрелись на одни и те же грабли. Вот хит-парад ошибок, которые допускают компании.

Ошибка 1: «У нас всё на доверии»

Классика. «Мы небольшая компания, все свои, зачем ограничения?» Заканчивается обычно тогда, когда кто-то из «своих» уходит к конкурентам или случайно удаляет половину базы.

Доверие — это прекрасно. Но оно не отменяет необходимости базовых ограничений. Даже в семье у каждого есть личное пространство.

Ошибка 2: Один суперпользователь на всех

Вместо создания нормальных ролей — один аккаунт с паролем «admin/admin», который знают все. «Так проще, не нужно разбираться с правами». В логах — непонятно кто что делал. Ответственности — ноль.

Ошибка 3: Права настроили один раз и забыли

При внедрении CRM права настроили нормально. Прошёл год, структура компании изменилась, появились новые отделы, люди поменяли должности — а права остались старыми. Менеджер, который год назад был стажёром, до сих пор с правами стажёра. Человек, ушедший в другой отдел, до сих пор видит старые данные.

Права нужно ревизировать регулярно — хотя бы раз в квартал.

Ошибка 4: Не деактивируют уволенных

Сотрудник уволился в пятницу. В понедельник его аккаунт всё ещё активен. Иногда — месяцами. Бывшие сотрудники заходят в CRM «посмотреть, как там дела» (или скачать что-нибудь полезное для нового работодателя).

Деактивация аккаунта должна быть частью процесса увольнения. В идеале — автоматически при увольнении в кадровой системе.

Ошибка 5: Слишком сложная система ролей

Обратная крайность — 50 ролей, каждая отличается от другой одной галочкой. Никто не понимает, какая роль что даёт. При назначении — угадайка. При ревизии — ад.

Если у вас больше 15-20 ролей — скорее всего, вы что-то переусложнили.

С чего начать: пошаговый план

Если вы дочитали до этого места и поняли, что с правами в вашей CRM всё плохо — не паникуйте. Навести порядок можно. Вот план действий.

Шаг 1: Аудит текущего состояния

Выгрузите список пользователей с их ролями. Проверьте: есть ли неактивные аккаунты (люди уже не работают, а доступ есть)? Есть ли пользователи с избыточными правами? Сколько людей имеют полный доступ ко всей базе?

Шаг 2: Спроектируйте целевую матрицу ролей

Нарисуйте таблицу: какие роли нужны, какие права у каждой. Ориентируйтесь на должности и функции, а не на конкретных людей. Согласуйте с руководителями подразделений — они лучше знают, какой доступ реально нужен их сотрудникам.

Шаг 3: Создайте роли в CRM

Настройте роли согласно матрице. Протестируйте каждую роль: создайте тестовый аккаунт, назначьте роль, проверьте, что видит и может делать пользователь. Это критически важно — теория и практика часто расходятся.

Шаг 4: Переназначьте пользователей

Пройдитесь по списку пользователей и назначьте каждому правильную роль. Параллельно деактивируйте аккаунты уволенных.

Шаг 5: Настройте аудит и мониторинг

Включите логирование действий. Настройте алерты на подозрительную активность. Определите, кто будет следить за этими данными.

Шаг 6: Задокументируйте и обучите

Напишите документ: какие роли есть, что каждая даёт, как запросить дополнительный доступ. Проведите обучение для руководителей — они должны понимать систему и уметь запрашивать права для своих сотрудников.

Шаг 7: Встройте в процессы

Добавьте управление доступом в HR-процессы: при найме — выдача роли, при увольнении — деактивация, при переводе — смена роли. Назначьте регулярную ревизию прав (раз в квартал).

Итог: права доступа — это не бюрократия, а защита

Признаюсь честно: настройка прав доступа — скучноватое занятие. Куда интереснее строить воронки, крутить автоматизации, любоваться графиками роста. Но без грамотно настроенных прав всё это — карточный домик.

Одна утечка клиентской базы ставит под удар репутацию. Один обиженный увольняющийся может удалить критичные данные. Случайный неправильный клик — и месяц работы команды коту под хвост.

Хорошая новость: настроить права правильно — это не rocket science. Базовую матрицу ролей для типичной компании можно сделать за пару дней. А эффект будет на годы вперёд.

Начните с малого. Проверьте, что у каждого сотрудника свой аккаунт. Убедитесь, что менеджеры видят только свои данные. Деактивируйте аккаунты уволенных. Эти три шага уже закроют 70% рисков. А дальше — развивайте систему по мере роста компании.

И помните: доверяй, но проверяй. Или, в терминах информационной безопасности: принцип минимальных привилегий. Давайте пользователям ровно столько доступа, сколько нужно для работы — и ни битом больше.