Как организовать права доступа в бизнес-системе?

Права доступа в бизнес-системе стоит настраивать не по принципу «на всякий случай дать всё», а по ролям и задачам. Сотрудник должен видеть данные и действия, которые нужны ему для работы, но не чужие зарплаты, договоры, настройки или клиентские базы целиком. Начинать лучше с простой карты ролей, а не с длинного списка галочек в админке.

Такая настройка одновременно снижает риск ошибки и делает работу спокойнее. Человек не теряется в лишних разделах, а руководитель понимает, кто может менять важные данные.

Почему «дать всем полный доступ» кажется удобным

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

Проблема появляется позже. Никто уже не помнит, кому и зачем дали доступ. Уволившийся сотрудник может остаться в системе. Менеджер случайно меняет справочник цен. Стажёр видит список клиентов, который ему не нужен. А после ошибки невозможно понять, кто и когда её сделал, потому что несколько людей работали под одним логином.

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

Что такое роль простыми словами

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

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

Хорошая отправная точка — не экран настроек, а вопрос: «Какие три–пять действий сотрудник обязан сделать за обычный рабочий день?» По ним и собирается минимальный набор прав.

Четыре уровня, которые полезно разделить

В большинстве систем права проще обсуждать по четырём слоям.

1. Просмотр. Что человек может увидеть: свои сделки, заказы отдела, всю клиентскую базу, финансовую сводку.
2. Изменение. Что он может создать, отредактировать или удалить. Удаление почти всегда стоит отделить от обычной работы.
3. Подтверждение. Что требует отдельного решения: скидка, возврат, платёж, публикация, изменение статуса заказа.
4. Настройки. Кто меняет поля, интеграции, роли, справочники и правила. Этот слой должен быть самым узким.

Так разговор становится предметным. Вместо фразы «ему нужен доступ к CRM» появляется понятная формулировка: «он видит сделки своего отдела, создаёт предложения, но не меняет воронку и не выгружает всю базу».

Начните с процесса, а не с названий разделов

Допустим, компания принимает заказы через сайт, CRM и телефон. Менеджер фиксирует обращение, склад подтверждает наличие, бухгалтерия проверяет оплату, руководитель видит отклонения. Если раздать права по названиям меню, легко открыть сотруднику лишнее. Если пройти путь заказа, становится видно, какие действия нужны на каждом шаге.

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

Если процесс пока не описан, не стоит ждать идеального регламента. Достаточно разобрать его с теми, кто делает работу каждый день. Это тот же принцип, который помогает выбрать удачную точку для автоматизации: сначала увидеть реальный маршрут работы, а потом настраивать систему.

Не используйте общие логины

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

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

С доступами к облачным сервисам особенно важно не путать удобство и безопасность. Облако не отменяет ответственность за то, кто может попасть к данным — подробнее об этом есть в статье «Облако не отменяет ответственность за данные и доступы».

Кому нужен административный доступ

Администратор нужен, но это не роль «для тех, кому доверяют». Это роль для тех, кто обслуживает систему и отвечает за её настройки. У неё должен быть понятный владелец, резервный ответственный и процедура на случай отпуска или увольнения.

В небольшом бизнесе иногда один человек совмещает несколько функций. Тогда полезно завести для него два режима: обычная рабочая учётная запись и отдельная административная. В повседневной работе он не открывает настройки случайно, а административный вход использует только для специальных задач. Такой приём делает действия заметнее и снижает вероятность ошибки.

Как проверить, что права настроены разумно

Не обязательно устраивать аудит на несколько месяцев. Раз в квартал или после заметного изменения команды достаточно пройти короткий список.

• Есть ли в системе активные учётные записи людей, которые больше не работают с процессом?
• Может ли кто-то удалить, выгрузить или изменить критичные данные без подтверждения?
• Есть ли хотя бы два человека с понятным административным доступом, а не один «незаменимый» логин?
• Понятно ли по журналу действий, кто изменил заказ, цену, реквизиты или настройки?
• Есть ли отдельные правила для подрядчиков и временных сотрудников?

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

Права доступа связаны с резервными копиями

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

О том, как подойти к регулярности копий, можно прочитать отдельно: как часто нужно делать резервные копии сайта и бизнес-системы. Здесь важен общий принцип: данные должны быть не только сохранены, но и доступны ровно тем, кому это необходимо.

Частые ошибки

Давать доступ по должности, не глядя на реальную работу. Два менеджера с одинаковой должностью могут работать с разными клиентскими сегментами и разной зоной ответственности.

Открывать права навсегда «на время». Временные исключения стоит фиксировать с датой пересмотра. Иначе через год они превращаются в необъяснимую норму.

Считать, что ограничение прав мешает бизнесу. Плохое ограничение действительно мешает. Хорошее убирает лишние разделы и делает маршрут сотрудника понятнее.

Настраивать доступы без владельца процесса. IT-специалист может технически создать роль, но не должен в одиночку решать, кто имеет право менять цену или подтверждать оплату. Это бизнес-решение.

Короткий чек-лист на старт

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

Связанные вопросы

• Кому в компании нужен доступ к финансовой информации?
• Как безопасно дать подрядчику доступ к CRM или сайту?
• Нужно ли включать двухфакторную аутентификацию для всех сотрудников?
• Как вести журнал действий в бизнес-системе?

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