Ролевая модель для B2B: как распределить сложные процессы в личном кабинете

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

Ролевая модель — способ дать каждому пользователю ровно те инструменты, которые нужны для его работы. Закупщик видит цены, остатки и форму быстрого заказа. Бухгалтер — счета, акты и дебиторскую задолженность. Руководитель — дашборд с ключевыми метриками и задачи на согласование. Каждый входит под своей учетной записью, и система точно знает, кто что сделал. Правильно спроектированная ролевая модель убирает хаос, сокращает время обработки заказа, снижает нагрузку на поддержку и возвращает клиенту чувство контроля. Это элемент управляемого B2B-сервиса, который используется во многих системах.

В основе ролевой модели лежат четыре базовых элемента:

•

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

•

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

•

Компонент — объект, доступ к которому регулируется: страница, таблица, документ, функция (например, «корзина», «счета», «реквизиты»).

•

Полномочие — право на конкретное действие: «просмотр цен», «создание заказа», «подписание документа», «изменение реквизитов».

Например, типовые роли на стороне B2B-клиента на сайте электронной коммерции могут выглядеть так:

•

Закупщик — создает заказы, работает с вводом артикулов и шаблонами, видит персональные цены и остатки по складам.

•

Бухгалтер — видит счета, акты сверки, дебиторскую задолженность, кредитные лимиты. Цены и корзина ему не нужны.

•

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

•

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

О том, как может выглядеть ролевая модель в сложном В2В-сервисе и как в ней распределяются роли, рассказываем в описаниях наших кейсов.

Меню, колонки в таблицах и доступные действия отображаются на сайте так, как определено для каждой роли. А значит, сервис подстраивается под каждого пользователя. Например, закупщик видит кнопку «Быстрый заказ» и колонку с ценами. А бухгалтер видит дебиторскую задолженность, но цены для него скрыты.

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

Технический фундамент ролевой модели — разделение на то, кому что разрешено, и на то, как это проверяется при каждом действии. Фундаментом здесь являются два подхода: RBAC (Role-Based Access Control) и ABAC (Attribute-Based Access Control).

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

Права описаны централизованно, в матрице, которая хранится в базе данных. Это дает предсказуемость: всегда можно посмотреть, кто и что может делать в системе. Подход RBAC используют как основу для большинства B2B-систем, потому что он прост в управлении и легко аудируется.

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

Лучшая практика — гибридный подход: RBAC для базового разделения прав, ABAC для контекстно-зависимых операций.

Кое-что на техническом: где находятся права

Данные о ролях и разрешениях хранят в базе: таблицы roles, permissions, role_permissions. Чтобы не нагружать базу при каждом запросе, матрицу прав кэшируют — например, в Redis. Каждый запрос к API проходит через middleware, которое проверяет: есть ли у роли нужное разрешение на запрашиваемое действие.

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

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

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

Это преимущество подхода с RBAC, когда под роли предусмотрены экраны. В случае ABAC мы теряем гибкость, и экраны становятся универсальны (мы либо полностью отказываемся от экрана, либо отказываемся от элемента на экране, но при этом страница сама будет одной и той же).

Адаптация таблиц. В B2B много данных: прайс-листы, реестры заказов, отчеты. Одна и та же таблица для разных ролей должна выглядеть по-разному. Закупщику — колонки с артикулом, ценой, остатком и кнопкой «В корзину». Бухгалтеру — сумма, статус оплаты, ссылка на счет. Руководителю — агрегированные показатели.
Колонки не скрываются хаотично, для каждой роли описан набор видимых полей и доступных действий. Это работает через динамическую конфигурацию: backend отдает описание колонок, и в интерфейсе отображается только то, что разрешено.

Защита от ошибок. Критические действия — изменение платежных реквизитов, удаление заказа, подписание документа — требуют явного подтверждения. Если роль не позволяет совершить действие, кнопка не просто исчезает: система показывает понятное объяснение. Например, «Этот раздел доступен только вашему руководителю. Обратитесь к Иванову И.И.» вместо «Нет доступа». Так пользователь не упирается в глухую стену, а понимает, что делать дальше.

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

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

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

1. Проектируем матрицу прав совместно. Аналитик описывает пользовательские сценарии. Разработчик предлагает архитектуру компонентов и полномочий. Дизайнер показывает, как это будет выглядеть в интерфейсе. Менеджер фиксирует договоренности. Матрица прав — это не технический документ, а общий артефакт команды: строки — роли, столбцы — ключевые действия и данные. На пересечении — разрешение. Так все видят картину целиком и могут спорить предметно.

2. Фиксируем сценарии. Кто создает заказ? Кто утверждает? Кто меняет реквизиты? В какой момент включается согласование? Ответы на эти вопросы описываются до первой строчки кода. Каждый сценарий проверяется вопросом: «А что будет, если этот пользователь попытается сделать то, что ему не разрешено?»

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

4. Тестирование под ролями. Автотесты проверяют, что API корректно отклоняет запросы от пользователей с недостаточными правами. Но этого мало. Тестировщик вручную проходит по каждому экрану для каждой роли с чек-листом: «Вижу ли я то, что должен? Не вижу ли лишнего? Понятно ли, почему кнопка недоступна?» Такие прогоны вскрывают проблемы, которые не ловятся автоматическими тестами.

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

Задача. Минэкономразвития России требовалось автоматизировать сбор отчетности о выбросах парниковых газов. Система должна была объединить сотни промышленных предприятий, государственные органы и надзорные ведомства. До запуска реестра отчеты заполнялись вручную, передавались на бумаге, проверялись неделями. Ошибки в данных были нормой, сроки срывались, аналитика по выбросам собиралась с задержкой в месяцы.

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

•

Эмитенты — компании, подающие отчеты о выбросах.

•

Оператор — Минэкономразвития, проверяющее и принимающее отчеты.

•

Надзорный орган — Росприроднадзор, проводящий дополнительный контроль.

•

Органы власти субъектов РФ — мониторинг по своему региону.

•

Администраторы — управление системой и справочной информацией.

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

Внутри роли «эмитент» реализовано автоматическое определение статуса организации. Компания вводит свои показатели во встроенный калькулятор. Система сама определяет категорию: регулируемая организация (РО — более 150 тыс. тонн CO₂ в год), региональная регулируемая организация (РРО — эксперимент на Сахалине) или иная организация (добровольная отчетность). От статуса зависит форма отчета и набор обязательных полей. Система не спрашивает пользователя, кто он, — она сама включает нужный сценарий, исключая ошибки ручной классификации.

Валидация на входе. До отправки отчет проходит несколько автоматических проверок: сверка электронной подписи, верификация компании через ЕГРЮЛ/ЕГРИП, выявление сомнительных значений по заданным алгоритмам. Если данные не проходят валидацию, система подсвечивает ошибку и не дает отправить отчет. Проверяющий получает уже очищенные от формальных ошибок документы — время обработки сокращается в разы.

Что получили. Каждый пользователь видит только свои реестры и отчеты. Движение отчета по статусам — от черновика до принятия — прозрачно и не требует звонков в ведомство. Ошибки отсекаются на этапе заполнения, а не постфактум. Жесткая валидация и автоматические уведомления о приближении дедлайнов защищают от штрафов за просрочку.

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

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

«В ГИС «Энергоэффективность» мы реализовали пять версий личных кабинетов. И при этом не пытались сэкономить на разделении интерфейсов. Из своей практики мы знаем: лучше потратить время на проектирование правильной архитектуры прав в начале, чем переделывать все после запуска, когда пользователи начнут жаловаться на путаницу и ошибки.

Юлия Яковенко

руководитель проекта

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

2. Постройте матрицу прав до написания кода — как общий артефакт для разработчика, дизайнера и менеджера.

3. Проверяйте интерфейс на реальных пользователях под каждой ролью. То, что удобно вам, может быть неудобно закупщику.

4. Используйте RBAC как фундамент, добавляйте ABAC только там, где нужен контекст. Не зашивайте проверки прав в код.

5. Защищайте доступ на backend. Frontend скрывает элементы для удобства, но не обеспечивает безопасность.

6. Запускайте MVP с минимумом ролей и расширяйте итеративно. Не проектируйте «на вырост» то, что не подтверждено обратной связью.

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