B2B-порталы и личные кабинеты для клиентов и партнёров

B2B-портал — не просто закрытая часть сайта

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

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

Если нужен внутренний сервис для сотрудников, это другой контур — корпоративный портал для сотрудников.

Сначала разделяем организации, роли и полномочия

В B2B-сценарии одного признака «пользователь авторизован» недостаточно. До разработки нужно определить:

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

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

Какие сценарии имеет смысл выносить в портал

Функции определяются реальным процессом. Часто обсуждаются:

• список заказов и повтор заказа;
• статусы заявок, поставок или услуг;
• персональные документы;
• договорные или коммерческие условия;
• остатки и доступность, если эти данные разрешено показывать;
• обращения в сервис;
• уведомления об изменениях;
• обмен файлами;
• история действий.

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

У каждого объекта должен быть источник истины

Портал редко должен становиться второй ERP или второй CRM. Для клиента, договора, товара, заказа, цены, документа и статуса нужно определить систему, которая остаётся источником истины.

До реализации фиксируем:

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

Портал почти всегда зависит от внутренних систем

Внешний интерфейс может быть связан с ERP, CRM, 1С, документооборотом, складской системой, платёжным сервисом или другим backend-контуром. Конкретный набор зависит от существующей архитектуры заказчика.

Интеграционный слой должен определять:

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

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

Главный риск — показать или разрешить лишнее

Для внешнего сервиса особенно важны изоляция данных и проверка полномочий на серверной стороне.

В проекте рассматриваются:

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

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

Сначала процесс, затем интерфейс

До оценки полезно описать один сценарий от начала до конца. Например:

партнёр входит → выбирает организацию → видит доступные позиции → создаёт заказ → получает номер → отслеживает статус → получает документ.

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

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

Пилот проверяет полный бизнес-сценарий

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

Приёмка строится вокруг рабочих сценариев:

• пользователь видит только разрешённые данные;
• действие корректно отражается в системе-источнике;
• повторная отправка не создаёт дубликат;
• недоступность интеграции обрабатывается предсказуемо;
• права меняются без ручного вмешательства в базу;
• критичные действия журналируются.

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

Где проходит граница этой услуги

B2B-портал — это конкретный внешний пользовательский контур.

Если требуется:

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

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

Что подготовить для первого обсуждения

Достаточно описать:

1. кто внешний пользователь — клиент, дилер, партнёр или другая роль;
2. какое действие он должен выполнять самостоятельно;
3. какие данные он должен видеть;
4. какая система сейчас хранит эти данные;
5. какие организации и роли нужно разделить;
6. что происходит сегодня вручную;
7. какой один сценарий важнее всего проверить первым.

Пароли, рабочие ключи API и реальные базы данных через форму передавать не нужно.

Обсудить B2B-портал →

Подробнее о специализированной команде разработки — на stdev.by.