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