Новая роль — новый проект: когда личные кабинеты пора собирать в экосистему

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

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

Фраза «новая роль — новый проект» точно описывает этот этап роста. Экосистема начинается там, где несколько групп пользователей работают с общими деньгами, документами и процессами. Дальше бизнесу выгоднее развивать единое ядро и подключать к нему разные кабинеты.

Пятый кабинет приносит пятую версию статуса

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

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

Интеграции тоже начинают дублироваться. Кабинет клиента отдельно подключают к 1С, портал поставщика — к той же 1С, админку — к CRM и банку. У каждого обмена появляются свои форматы, расписания и обработка ошибок. Поддержка платит за эту разницу на каждом сбое, а разработка — перед каждым релизом.

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

Четыре числа покажут цену разрозненных кабинетов

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

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

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

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

Объём проверок перед релизом. Новая функция затрагивает клиента, поставщика, менеджера, биллинг и уведомления. Количество сценариев регресса показывает, насколько роли связаны между собой и умеет ли архитектура держать эту связь.

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

Один логин ещё не создаёт экосистему

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

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

Команда может обновлять отдельные экраны, не копируя бизнес-правила в каждый кабинет. Связь между ролями остаётся внутри платформы, а проверки выполняются на сервере.

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

Один пользователь, три компании и общий профиль

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

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

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

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

Источник истины нужно назначить до первой интеграции

Для каждой ключевой сущности нужен владелец данных. Счёт может формироваться в 1С, сделка — в CRM, статус подписания — в ЭДО, а согласие пользователя и настройки уведомлений — в личном кабинете. Конкретное распределение зависит от контура; важен один ответ на вопрос, где запись считается актуальной.

После этого команда описывает направление обмена и реакцию на сбой. Что произойдёт, если 1С недоступна? Повторится ли событие позже? Не создаст ли повторная доставка второй заказ или платёж? Увидит ли менеджер ошибку до обращения клиента? Эти решения входят в интеграцию вместе с API и вебхуками.

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

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

Общее ядро тоже выставляет счёт

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

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

Для простого кабинета на одну-две роли, без сложных согласований и глубоких интеграций, коробочный портал часто остаётся разумным выбором. Собственная платформа оправдывается, когда кабинет влияет на деньги, документы, права доступа и основной путь клиента, а новые роли уже стоят бизнесу отдельных запусков.

Главный критерий: новая роль подключается модулем

Проверка проста: к существующему ядру добавляют только сценарии и интерфейс очередной аудитории.

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

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

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