Тендеры и лиды
Информация
Ситуация: менеджер по закупкам крупного производства заходит в личный кабинет поставщика, чтобы оформить типовой заказ. В том же аккаунте вчера работал бухгалтер — проверял закрывающие документы и случайно изменил платежные реквизиты. В итоге руководитель отдела не может утвердить заказ, потому что заявка не отображается в общем списке, а тем временем поставщик уже требует счёт!..
Когда закупщик, бухгалтер и руководитель делят один логин, система не знает, кто именно совершает действие. А значит, нет ответственности за ошибки.
Чтобы избежать таких ситуаций, на B2B-сайтах используют ролевую модель. Если роли настроены правильно, все специалисты могут работать, не мешая друг другу: закупщик видит цены и остатки, а бухгалтер — счета и акты; каждый входит под своей учетной записью и оставляет уникальный «цифровой след». Ролевая модель на сайте и в цифровом сервисе — хороший способ дать каждому пользователю ровно те инструменты, которые нужны для его работы.
Базовые элементы ролевой модели: что лежит в основе
Ролевая модель — специальный инструмент управления, который определяет набор прав и разрешений для различных категорий пользователей (ролей) системы. Роли могут быть привязаны к должностям, подразделениям, возможностям ресурса или функциональным задачам сотрудников.
Любая ролевая модель строится на четырёх сущностях.
Пользователь — конкретный сотрудник с персональной учётной записью.
Роль — права и должностные обязанности: закупщик, бухгалтер, руководитель, администратор организации.
Компонент — объект, к которому даётся доступ: страница, таблица, документ, отдельная функция вроде корзины или реестра счетов.
Полномочие — право на конкретное действие: просмотр цен, размещение заказа, подписание документа, редактирование реквизитов.
Обычно на B2B-сайтах от трёх до десяти ролей (в редких случаях больше): например, закупщик, бухгалтер, контент-менеджер, руководитель, администратор.
Сервис с настроенной ролевой моделью меняется и подстраивается под каждую группу пользователей. Благодаря этому легко избегать конфликтных ситуаций, вроде той, что описаны в начале: например, можно настроить полномочия так, что бухгалтер видит дебиторскую задолженность, но не может менять реквизиты без подтверждения руководителя.
Работоспособная ролевая модель начинается не с таблиц, а с аналитики и проектирования: для неё нужно выстроить архитектуру прав, создать интерфейс под каждую роль и описать бизнес-процесс, в который эти роли встроены. Если хотя бы один слой проработан слабо, система начинает «протекать». Расскажу подробнее про самый интересный слой — интерфейсный, ведь именно с ним взаимодействуют пользователи. Вот несколько приёмов, которые мы используем в своих проектах.
Закупщик после авторизации попадает на форму быстрого заказа с историей последних корзин и остатками по складам, а руководитель видит дашборд с оборотом, статусами согласований и просрочками — это два совершенно разных стартовых экрана. Здесь определяется рабочий сценарий: пользователь не блуждает по меню, а сразу оказывается в нужном месте.
В B2B-среде всегда много данных: прайс-листы, реестры заказов, отчёты, при этом одна и та же таблица должна выглядеть по-разному для разных ролей. Закупщику показываются артикул, цена, остаток и кнопка «В корзину»; бухгалтеру — сумма, статус оплаты, ссылка на счёт; руководителю — агрегированные показатели. Чтобы создать такой интерфейс, мы используем динамическую конфигурацию: разрешенные поля заданы на бэкенде, то есть в программном коде сайта или сервиса.
Критичные операции, такие как смена платёжных реквизитов, требуют подтверждения. Если полномочий не хватает, кнопка не просто пропадает — отображается системная подсказка. Например, «этот раздел доступен вашему руководителю. Обратитесь к Елене Николаевне Ивановой». Если подсказки не сделать или прописать их формально («действие недоступно», «недостаточно прав»), сотрудники будут терять время, а нагрузка на техподдержку увеличится.
В сложных ролевых системах мы не пытаемся спроектировать роли под все мыслимые ситуации. Считаем, что разумнее запустить MVP с тремя ролями — закупщик, руководитель, администратор — и расширять список, изучая статистику и поведение пользователей. Архитектура должна позволять добавлять роли без переписывания системы, поэтому права лучше не зашивать в код.
Одно из важных правил на любом этапе — не создавать лишние сущности. Например, для крупного проекта «Алюминиевая Ассоциация» мы создали модель всего из пяти типов пользователей.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
Покажем, как перечисленные принципы работают в проекте, где ролевая модель была обязательным элементом. Это один из сложных сервисов для бизнеса, реализованный нашей командой.
Задача. Минэкономразвития России нуждалось в автоматизации сбора отчетности о выбросах парниковых газов. Будущая система должна была объединить сотни промышленных предприятий, государственные органы и надзорные ведомства.
Реализация ролевой модели. Мы спроектировали пять полностью обособленных личных кабинетов — по одному на каждый тип участника, учитывая контекст и потребности каждого из них.
Эмитенты: компании, подающие отчёты о выбросах.
Оператор: министерство, проверяющее и принимающее отчёты.
Надзорный орган, проводящий дополнительный контроль.
Органы власти субъектов РФ: мониторинг на уровне региона.
Администраторы: управление системой и справочными данными.
Подробнее о полномочиях каждой роли и о сложных механизмах в интерфейсе проекта рассказали в кейсе на сайте Uplab.
Итог. Поэтапный переход с бумажной отчётности на цифровую. Минимальная нагрузка на службу поддержки — пользователи перестали звонить с вопросами «где мой отчёт» и «почему не принимают». Нулевое пересечение данных между ролями: эмитент не видит чужие документы, оператор не может случайно изменить данные эмитента. Система сама проводит пользователя по процессу, предотвращая ошибки до их возникновения.
1) Изучайте реальных пользователей в их рабочей среде. Роли, придуманные в переговорной, неизбежно расходятся с действительностью.
2) Составляйте матрицу прав до написания первой строчки кода — как общий артефакт для разработчика, дизайнера и менеджера.
3) Тестируйте интерфейс на живых пользователях под каждой ролью. То, что удобно проектировщику, может оказаться неудобным для закупщика.
4) Обеспечивайте контроль доступа на уровне бэкенда. Фронтенд скрывает элементы ради удобства, но не гарантирует безопасность.
5) Запускайте MVP с минимальным набором ролей и расширяйте его итеративно. Не проектируйте «на вырост» то, что не подтверждено обратной связью.
Наш опыт подтверждает: в среде любой сложности можно построить удобную и безопасную систему. Когда каждый сотрудник заходит в цифровой сервис под собственной ролью и действует по своему сценарию, хаос уступает место порядку.
