Роли и группы пользователей

Группы пользователей в RetailCRM — это шаблоны ролей, которые задают, что сотрудник видит и что может делать. Хорошо спроектированные группы масштабируются: новый оператор получает доступ за минуту, без ручной донастройки.

Роль и группа: в чём разница

В RetailCRM нет отдельной сущности «роль» — её функцию выполняет группа пользователей. Группа — это именованный набор прав: доступ к разделам, область видимости заказов, финансовые ограничения. Когда говорят «роль оператора» или «роль руководителя», на практике имеют в виду именно группу с соответствующими настройками.

Проектирование ролей — это описание того, какие типы сотрудников работают в системе и что каждому из них нужно. Затем под каждый тип создаётся группа в разделе Администрирование → Группы пользователей.

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

Типовые роли интернет-магазина

Большинству проектов достаточно четырёх-шести групп. Плодить их вредно: чем больше групп, тем сложнее поддерживать матрицу доступа.

Матрица доступа

Перед настройкой полезно составить матрицу: строки — роли, столбцы — права, на пересечении — «да/нет». Это документ, который защищает от хаоса и упрощает аудит.

1. Выпишите все роли, которые реально существуют в команде.
2. Перечислите ключевые права: заказы, клиенты, товары, отчёты, настройки, цена, себестоимость, экспорт.
3. Проставьте доступы и утвердите матрицу с руководителем.
4. Перенесите её в настройки групп RetailCRM один в один.

Когда появляется новый тип сотрудника, вы сначала добавляете строку в матрицу, а уже потом — группу в системе. Так решения о доступе принимаются осознанно.

Разделение по магазинам и отделам

Если компания продаёт через несколько сайтов или брендов, группы комбинируют с привязкой к магазинам. Оператор бренда А видит только его заказы, даже находясь в одной группе с оператором бренда Б по набору прав.

• Права (что можно делать) задаёт группа.
• Область данных (какие магазины) задаёт привязка пользователя.
• Комбинация даёт гибкое разделение без взрывного роста числа групп.

Такой подход избавляет от антипаттерна «группа под каждый магазин»: вместо десятка почти одинаковых групп остаётся несколько ролей плюс привязки.

Частые ошибки проектирования

Ошибки в ролях всплывают не сразу, а когда команда вырастает. Вот самые распространённые.

• Все в администраторах. Удобно на старте, опасно в работе: любой может сломать настройки.
• Группа под человека. Признак того, что роли не продуманы; поддерживать невозможно.
• Забытые права на экспорт. Операторы выгружают базу клиентов без ограничений.
• Нет роли «только чтение». Аналитикам приходится давать лишние права.

Поддержка ролей во времени

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

1. Раз в квартал сверяйте состав групп с актуальной оргструктурой.
2. Удаляйте роли, которыми давно никто не пользуется.
3. Документируйте изменения матрицы доступа.
4. При подключении аутсорса заводите отдельную ограниченную группу.

Итог

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

Мы проектируем ролевую модель под структуру вашей команды и переносим её в настройки RetailCRM без лишних групп и дыр в безопасности. Это особенно ценно при росте штата и подключении внешних операторов.