Компания открывает второй город, потом третий, и в какой-то момент директор филиала в Астане замечает, что видит клиентскую базу Шымкента целиком. Ещё через месяц выясняется, что менеджер, уходя к конкуренту, выгрузил контакты всех подразделений. Ни то, ни другое не связано с уязвимостями системы: просто права в портале настраивались один раз, когда офис был один.
Разграничение доступа по филиалам в коробочном Битрикс24 собирается из трёх независимых механизмов, и работают они по разной логике. Понимание этой разницы экономит недели переделок, потому что типичный сценарий выглядит так: настроили роли в CRM, обрадовались, а потом обнаружили, что филиалы всё равно видят чужие документы на Диске.
Что вообще нужно разграничивать, когда офисов больше одного
Перед настройкой полезно разложить, какие именно данные пересекаются между подразделениями. В филиальной компании это обычно четыре слоя.
Клиентская база и сделки. Самый очевидный и самый чувствительный слой: филиалы конкурируют за один и тот же рынок, и видимость чужих контактов почти всегда вредна.
Задачи и проекты. Здесь избыточная открытость мешает меньше, но руководитель филиала не должен управлять задачами чужого подразделения.
Документы и файлы. Договоры, прайсы, кадровые бумаги. Именно этот слой чаще всего забывают, потому что настройки живут отдельно от CRM.
Структура и кадры. Кто видит список сотрудников, кто может приглашать новых, кто может редактировать чужое подразделение.
Разные слои закрываются разными инструментами, и попытка решить всё «одной галочкой» приводит к дырам. Если вы только планируете переезд на коробку или наводите порядок в существующем портале, начните с описания этих четырёх слоёв, а уже потом переходите к настройкам. Мы часто делаем такой разбор в рамках проектов по внедрению и настройке Битрикс24, и почти всегда оказывается, что реальная схема доступа отличается от той, что руководитель держал в голове.
Фундамент: структура компании
Всё разграничение по филиалам опирается на структуру компании. Пока подразделения не отражают реальную географию, любые роли будут настраиваться вручную по конкретным людям, и через полгода схема развалится.
Правильный подход простой: каждый филиал становится отдельным подразделением, внутри него создаются отделы, а руководитель филиала назначается руководителем подразделения. После этого система начинает понимать, кто кому подчиняется, и права можно раздавать не пофамильно, а по структуре.
У самой структуры компании тоже есть права доступа, и это отдельная настройка. По умолчанию для подразделений предусмотрено пять ролей. Администратор получает полный доступ ко всем возможностям структуры, включая управление правами. HR может выполнять все действия, кроме настройки прав. Руководитель добавляет, редактирует и удаляет своё подразделение и подчинённые ему. Заместитель управляет своим подразделением: редактирует его, добавляет и удаляет сотрудников, приглашает новых. Сотрудник видит структуру компании.
Область действия прав задаётся отдельно и может быть ограничена всей компанией, своим подразделением с подчинёнными или только своим подразделением. Последний вариант как раз и нужен филиальной сети: директор в Караганде управляет своими людьми и не трогает Актобе.
Для команд действует похожая схема с четырьмя ролями: администратор структуры, руководитель отдела, заместитель руководителя и сотрудник. Руководитель отдела создаёт и редактирует команды в своём подразделении и подчинённых ему.
Набор управляемых прав шире, чем кажется: просмотр, добавление, удаление, редактирование, добавление и удаление сотрудников, приглашение новых, увольнение. В филиальной модели обычно оставляют руководителю приглашение и редактирование, а увольнение сотрудников закрывают на уровне головного офиса.
Ролевая модель CRM и семь уровней доступа
Клиентская база закрывается ролевой моделью в CRM. По умолчанию в системе есть две роли: администратор с полным доступом ко всем элементам и настройкам прав, и менеджер с доступом на просмотр, создание и редактирование собственных элементов.
Для филиальной структуры этих двух ролей мало, но сама механика гибкая. Для каждого действия с каждым типом элементов задаётся один из семи уровней доступа.
Полный доступ разрешает действие со всеми элементами определённого типа. Свои открывают только те элементы, где сотрудник назначен ответственным. Своего отдела дают доступ к элементам сотрудников собственного подразделения. Подотделов отдела расширяют охват на все подразделения внутри своего отдела. Своих команд открывают элементы участников команд, к которым принадлежит сотрудник. Своих команд и команд в подчинении охватывают все подчинённые структуры. Все открытые дают доступ к элементам с включённой опцией «Доступен для всех».
Именно связка «Своего отдела» и «Подотделов отдела» и есть рабочий инструмент для филиалов. Рядовой менеджер получает уровень «Свои» и видит только собственные сделки. Руководитель отдела продаж филиала получает «Своего отдела». Директор филиала, у которого внутри несколько отделов, получает «Подотделов отдела» и видит весь свой город, не касаясь соседних.
Роли назначаются не только на конкретных людей. Их можно выдавать отделам, командам, ролям в структуре компании, предустановленным группам и участникам проектов. Для филиальной сети это принципиально: роль вешается на подразделение, и новый сотрудник получает нужные права автоматически при добавлении в филиал. Настройка «по фамилиям» работает ровно до первого найма.
Правило пересечения ролей, о которое спотыкаются чаще всего
Есть механика, которая переворачивает интуитивные ожидания, и знать её надо до начала настройки. Если у пользователя несколько ролей с разными уровнями доступа, применяются те права, которые дают больше возможностей.
То есть система не ищет пересечение ограничений, она берёт максимум. Запрет в одной роли не перекроет разрешение в другой: если одна роль запрещает просмотр лидов, а вторая разрешает, сотрудник лиды увидит.
На практике это выглядит так. Менеджеру филиала выдали роль «Менеджер филиала» с уровнем «Свои», а заодно он числится участником проектной группы, которой когда-то дали полный доступ к сделкам. В итоге человек видит всю базу компании, а администратор смотрит на карточку роли «Менеджер филиала» и не понимает, почему ограничение не работает.
Отсюда практическое правило: перед разбирательством с «дырой» в правах нужно собрать все роли пользователя, а не смотреть на основную. И второе: любые временные широкие права, выданные под проект или под аврал, должны сниматься, потому что они переживут и проект, и аврал.
Группы пользователей: чем коробка отличается от облака
В коробочной версии есть механизм, которого в облаке нет в таком виде: группы пользователей. Они управляют доступом к модулям портала и лежат уровнем ниже, чем роли CRM.
По умолчанию в системе шесть групп с возрастающими правами. Сотрудники, это самая массовая и самая низкая по уровню прав группа. Отдел кадров может добавлять информацию во всех разделах. Руководство получает доступ к отдельным корпоративным документам. Маркетинг выделен как специализированная группа для работы с CRM. Администратор портала имеет права всех предыдущих групп плюс ограниченные возможности управления порталом. Администратор системы обладает полным доступом.
Важное следствие для филиальной модели: администратор портала и администратор системы сохраняют полный технический доступ ко всем документам и файлам. Разграничить их правами внутри портала не получится, это архитектурное свойство системы. Если в компании требуется, чтобы никто не видел всё сразу, вопрос решается организационно, а не настройками: ограничением числа администраторов, регламентом и журналированием действий.
Ограничивать доступ в коробке можно тремя способами. По должности, когда руководители получают более чувствительные документы, чем подчинённые. По функциональным обязанностям, через рабочие группы для совместной работы, в том числе временной. И по отдельному файлу, когда права выдаются конкретным пользователям, группам пользователей, рабочим группам или ролям, причём с возможностью ограничить доступ по времени и паролем.
Третий вариант удобен для филиалов в разовых ситуациях: например, головной офис открывает регионам доступ к тендерной документации на срок подготовки заявки.
Как это собирается для типичной сети
Соберём схему на условном примере. Компания с головным офисом в Алматы и тремя филиалами, в каждом филиале директор, отдел продаж и сервисная служба. Пример иллюстративный, конкретные уровни под вашу структуру подбираются отдельно.
Структура компании повторяет географию: головной офис, внутри него три подразделения по городам, внутри каждого города два отдела. Директор филиала назначен руководителем городского подразделения, права на структуру ограничены своим подразделением и подчинёнными.
В CRM создаются три роли вместо двух стандартных. Менеджер получает уровень «Свои» на просмотр, редактирование и удаление, плюс создание новых элементов. Руководитель отдела получает «Своего отдела» на просмотр и редактирование, но удаление ему обычно оставляют на уровне «Свои», чтобы случайное действие не стёрло чужую сделку. Директор филиала получает «Подотделов отдела» на просмотр и «Своего отдела» на редактирование.
Роли выдаются подразделениям, а не людям. Новый менеджер, добавленный в отдел продаж Караганды, автоматически получает нужный набор прав, и администратора при найме дёргать не нужно.
Коммерческий директор головного офиса получает полный доступ на просмотр по всем филиалам, но редактирование ограничивается своим подразделением. Так руководитель видит картину целиком и при этом не правит чужие сделки, пока его об этом не попросят.
Отдельно закрывается Диск. Папки по филиалам создаются с правами на соответствующие подразделения, общие прайсы и шаблоны договоров лежат в открытой для всех папке, кадровые документы доступны отделу кадров и руководству. Этот шаг делают в последнюю очередь и чаще всего забывают.
Задачи в такой схеме обычно разграничивают мягче, чем сделки. Директор филиала должен видеть загрузку своих людей, но жёстко закрывать задачи между городами смысла мало: совместные проекты головного офиса и регионов всё равно требуют общего доступа, и постоянные заявки на открытие доступа съедят больше времени, чем сэкономят. Разумнее оставить видимость задач внутри подразделения и открывать проектные группы точечно под конкретную работу, не забывая закрывать их по завершении.
Что делать с клиентами, которые обращаются в несколько филиалов
Как только доступ разграничен, всплывает встречная проблема. Клиент звонит в Астану, не получает нужного и через неделю пишет в Алматы. Оба филиала заводят его как нового, обе сделки идут параллельно, а клиент получает два разных предложения от одной компании.
Полностью закрытая схема эту ситуацию только усугубляет: менеджеры физически не видят, что контакт уже есть в системе. Поэтому в филиальных настройках почти всегда делают исключение для поиска дублей.
Рабочий компромисс выглядит так. Контакты и компании остаются видимыми по всей сети хотя бы на уровне названия и телефона, чтобы поиск при заведении срабатывал. Сделки, суммы и переписка закрываются по подразделениям. Менеджер видит, что клиент уже есть и за ним закреплён коллега из другого города, но не видит, о чём они договаривались и по какой цене.
Дальше нужен регламент, потому что техника здесь заканчивается. Компания должна заранее решить, кто ведёт клиента при пересечении: тот, кто завёл первым, тот, в чьём регионе находится юридический адрес, или тот, у кого сделка на более поздней стадии. Без такого правила настройка прав превращается в источник внутренних конфликтов, и разбирать их приходится коммерческому директору вручную.
Отдельно стоит договориться о передаче клиента между филиалами. Смена ответственного меняет и видимость элемента, поэтому передавать нужно вместе с историей: если прежний менеджер терял доступ мгновенно, а новый не получил комментарии и файлы, клиент повторяет весь разговор заново и делает вывод, что в компании бардак.
Чего правами доступа закрыть не получится
Ограничения системы полезно понимать заранее, иначе от неё ждут невозможного.
Администраторы видят всё. Как уже говорилось, администратор портала и администратор системы имеют полный технический доступ. Единственный работающий подход состоит в том, чтобы держать этот список коротким и знать поимённо, кто в нём.
Права не мешают выгрузке. Сотрудник, который видит сто своих сделок, может их экспортировать. Разграничение уменьшает объём того, что можно унести, но не превращает систему в сейф. Здесь помогают отдельные ограничения на экспорт и регламент.
Права не заменяют дисциплину. Если менеджеры ведут переписку в личных мессенджерах, а договорённости хранят в личных файлах, любая настройка портала остаётся декорацией.
Права не спасают от ошибок в самой структуре. Если сотрудник числится сразу в двух подразделениях или висит в головном офисе, потому что его туда добавили при найме и забыли перевести, никакая роль не сработает так, как задумано. Прежде чем искать проблему в настройках CRM, стоит открыть структуру компании и посмотреть, где человек находится на самом деле.
Излишняя закрытость тоже вредит. Когда филиалы полностью изолированы, компания перестаёт видеть повторные обращения одного клиента в разные города и теряет сделки на дублях. Разумный компромисс: сквозной поиск по контактам открыт, а содержимое чужих сделок закрыто.
Как проверить, что настройка действительно работает
Проверять права по карточке роли бессмысленно, потому что пересечения ролей там не видно. Надёжный способ только один: смотреть глазами пользователя.
Заведите тестовые учётные записи для каждой роли: рядовой менеджер филиала, руководитель отдела, директор филиала. Зайдите под каждой и попробуйте открыть заведомо чужой элемент: сделку соседнего города, контакт другого филиала, папку на Диске.
Отдельно проверьте списки и фильтры, а не только прямые ссылки. Бывает, что карточка не открывается, а в общем списке элемент виден вместе с суммой сделки, и этого уже достаточно, чтобы понять чужую воронку.
Проверьте поиск. Глобальный поиск по порталу часто показывает то, что закрыто в разделах, и это стандартное место утечки видимости.
Проверьте отчёты и аналитику. Ограничение на элементы не всегда автоматически означает ограничение в сводных данных, поэтому цифры по чужим филиалам стоит посмотреть глазами тестового пользователя.
Проверьте, что происходит при переводе сотрудника. Переместите тестового пользователя из одного филиала в другой и убедитесь, что он потерял доступ к прежним элементам и получил доступ к новым. Это единственный способ понять, действительно ли роли навешены на подразделения, а не на людей: при настройке пофамильно перевод сотрудника ничего не меняет, и человек продолжает видеть старый город.
Зафиксируйте результат письменно: какая роль что видит. Через полгода, когда появится новый филиал или сменится администратор, этот документ сэкономит день разбирательств.
Частые вопросы
Можно ли полностью скрыть один филиал от другого?
На уровне элементов CRM и файлов да, через роли с уровнем «Свои» и «Своего отдела» и через права на папки. Но администраторы портала и системы всё равно сохраняют полный доступ, это особенность архитектуры, а не ошибка настройки.
Почему сотрудник видит чужие сделки, хотя в его роли стоит уровень «Свои»?
Скорее всего, у него есть вторая роль с более широкими правами. При пересечении ролей применяются те права, которые дают больше возможностей, поэтому запрет из одной роли не перекроет разрешение из другой. Нужно собрать все роли пользователя, включая полученные через отделы, команды и проектные группы.
Как выдавать права, чтобы не настраивать их при каждом найме?
Назначать роли на подразделения и команды, а не на конкретных людей. Роли в CRM можно выдавать отделам, командам, ролям в структуре компании и предустановленным группам, и тогда новый сотрудник получает набор прав автоматически при добавлении в подразделение.
Чем разграничение в коробке отличается от облака?
Логика ролей CRM и структуры компании общая, но в коробочной версии дополнительно работают группы пользователей, управляющие доступом к модулям, и более гибкие настройки прав на отдельные файлы, вплоть до ограничения по времени и паролю.
Можно ли дать доступ к папке только на время?
Да, в коробке права на отдельный файл или папку выдаются пользователям, группам пользователей, рабочим группам или ролям, и доступ можно ограничить по времени, а также закрыть паролем.
Кто должен настраивать права: администратор портала или руководитель?
Настройку выполняет администратор, но схему доступа определяет бизнес. Решение о том, видит ли директор филиала соседний город, принимает руководство компании, и до начала работ его лучше зафиксировать письменно.
Разграничение по филиалам редко разваливается из-за нехватки возможностей в системе. Разваливается оно из-за того, что структура компании не соответствует реальной, роли раздали пофамильно, а временные широкие права никто не снял. Если эти три вещи держать в порядке, портал переживёт и открытие нового города, и смену администратора без переделки схемы с нуля.