Готовность к внедрению B2B портала. Часть 1. Какие решения нужно принять до начала разработки.
07.10.2026
Подробное техническое задание не спасает проект, если бизнес ещё не договорился о собственных правилах. Пока не определены источник персональной цены, структура договоров, логика остатков, владельцы интеграций и порядок принятия решений, разработчики вынуждены заполнять пробелы предположениями.
Первая часть материала помогает подготовить основу проекта до написания кода. Это не перечень документов ради формальности. Каждая рекомендация отвечает на практический вопрос: какое решение нужно принять, почему оно влияет на архитектуру и чем подтвердить готовность.
Первая часть материала помогает подготовить основу проекта до написания кода. Это не перечень документов ради формальности. Каждая рекомендация отвечает на практический вопрос: какое решение нужно принять, почему оно влияет на архитектуру и чем подтвердить готовность.
1. Начните с бизнес задачи, а не со списка функций
Формулировка «нужен личный кабинет» не объясняет, что именно должно измениться в работе компании. Для одного бизнеса важнее сократить ручной ввод заказов, для другого — дать дилерам актуальные цены и остатки, для третьего — перенести согласование документов в цифровой канал. Эти задачи приводят к разному составу первого релиза.
До разработки сформулируйте проблему, ожидаемый эффект и способ его проверки. Метрика должна быть связана с конкретным процессом: временем обработки заказа, количеством ручных операций, долей заказов, которые клиент оформляет самостоятельно, или числом обращений за документами. Для каждой метрики нужен источник данных и владелец.
Готовность подтверждает: паспорт проекта или карточка инициативы с целью, исходным состоянием, метриками, границами и спонсором.
Сигнал риска: руководители по-разному описывают результат, а приоритеты меняются на каждой встрече.
До разработки сформулируйте проблему, ожидаемый эффект и способ его проверки. Метрика должна быть связана с конкретным процессом: временем обработки заказа, количеством ручных операций, долей заказов, которые клиент оформляет самостоятельно, или числом обращений за документами. Для каждой метрики нужен источник данных и владелец.
Готовность подтверждает: паспорт проекта или карточка инициативы с целью, исходным состоянием, метриками, границами и спонсором.
Сигнал риска: руководители по-разному описывают результат, а приоритеты меняются на каждой встрече.
2. Назначьте бизнес владельца проекта
B2B-портал затрагивает продажи, финансы, склад, логистику, поддержку и IT. Между подразделениями неизбежно возникают вопросы, на которые подрядчик не может ответить за компанию: какой договор использовать по умолчанию, кто видит задолженность, можно ли оформить заказ при отсутствии цены, какой канал становится основным после запуска.
Нужен бизнес-владелец с правом определять приоритеты, подключать экспертов и принимать решение, когда требования подразделений противоречат друг другу. Руководитель проекта организует работу, но не заменяет владельца бизнес-результата.
Готовность подтверждает: зафиксированная роль владельца проекта, его полномочия и порядок эскалации спорных решений.
Обычно отвечает: коммерческий директор, директор по развитию, руководитель e-commerce или другой руководитель, заинтересованный в результате проекта.
Нужен бизнес-владелец с правом определять приоритеты, подключать экспертов и принимать решение, когда требования подразделений противоречат друг другу. Руководитель проекта организует работу, но не заменяет владельца бизнес-результата.
Готовность подтверждает: зафиксированная роль владельца проекта, его полномочия и порядок эскалации спорных решений.
Обычно отвечает: коммерческий директор, директор по развитию, руководитель e-commerce или другой руководитель, заинтересованный в результате проекта.
3. Опишите процессы AS IS и TO BE
Проектирование начинается не со списка экранов, а с движения заказа и данных. Сначала зафиксируйте, как процесс работает сейчас: кто создаёт заказ, где рассчитывается цена, как проверяется лимит, кто подтверждает доставку, где появляются документы и как клиент узнаёт об изменении статуса.
Затем опишите целевую модель. Какие шаги исчезнут, какие автоматизируются, а какие останутся у менеджера? Обязательно разберите исключения: частичную отгрузку, отмену, возврат, рекламацию, отсрочку, отсутствие цены, нехватку остатка и ручное согласование. Именно исключения чаще всего меняют структуру данных и интерфейс.
Готовность подтверждает: карта AS IS и TO BE, перечень исключений и журнал принятых решений.
Сигнал риска: вместо процесса обсуждаются только страницы, а формулировка «работает как сейчас» нигде не раскрыта.
Затем опишите целевую модель. Какие шаги исчезнут, какие автоматизируются, а какие останутся у менеджера? Обязательно разберите исключения: частичную отгрузку, отмену, возврат, рекламацию, отсрочку, отсутствие цены, нехватку остатка и ручное согласование. Именно исключения чаще всего меняют структуру данных и интерфейс.
Готовность подтверждает: карта AS IS и TO BE, перечень исключений и журнал принятых решений.
Сигнал риска: вместо процесса обсуждаются только страницы, а формулировка «работает как сейчас» нигде не раскрыта.
4. Ограничьте MVP и договоритесь об изменениях
MVP — это не уменьшенная копия будущей платформы. В первый релиз должны войти функции, без которых не работает главный пользовательский сценарий. Для каждой функции нужно понимать, какую задачу она решает, от каких систем зависит и как будет приниматься.
Отдельно зафиксируйте то, что не входит в первый релиз. Если появляется новое требование, команда должна оценить его влияние на сроки, бюджет, интеграции и тестирование. Добавление функции без пересмотра состава MVP постепенно превращает первый запуск в долгострой.
Отдельно зафиксируйте то, что не входит в первый релиз. Если появляется новое требование, команда должна оценить его влияние на сроки, бюджет, интеграции и тестирование. Добавление функции без пересмотра состава MVP постепенно превращает первый запуск в долгострой.
Пример из практики: почему отдельный тип заказа перенесли за пределы MVP
При проектировании портала для производителя модульной мебели рассматривались стандартные заказы и отдельный сценарий заказа выставочных образцов для торговой точки. Для второго сценария требовались дополнительные правила: отдельное оформление, контроль обязательств и фотофиксация размещения образцов.
Этот процесс не был необходим для запуска основного канала заказов, но заметно расширял объём интеграций, интерфейсов и тестирования.
Принятое решение: В MVP оставили основной сценарий заказа, а выставочные образцы перенесли в следующий этап. Граница была определена по бизнес-ценности и зависимости от основного процесса, а не по удобству разработки.
Готовность подтверждает: реестр требований с разделами MVP, следующий этап и вне границ проекта, а также критерии приёмки.
5. Свяжите роли с действиями и данными
Названия должностей недостаточно. Для каждой роли нужно определить, какие компании и торговые точки она видит, какие заказы создаёт и согласует, какие документы скачивает, может ли просматривать задолженность и управлять другими пользователями.
Проверьте сложные случаи: один человек работает с несколькими юридическими лицами, руководитель видит заказы всех сотрудников, менеджер получает временные полномочия, пользователь переходит в другую организацию. Эти сценарии влияют не только на интерфейс, но и на модель доступа к данным.
Готовность подтверждает: матрица ролей и прав, дополненная сценариями регистрации, приглашения, блокировки и смены полномочий.
Сигнал риска: роли перечислены, но действия и видимость данных не определены.
Проверьте сложные случаи: один человек работает с несколькими юридическими лицами, руководитель видит заказы всех сотрудников, менеджер получает временные полномочия, пользователь переходит в другую организацию. Эти сценарии влияют не только на интерфейс, но и на модель доступа к данным.
Готовность подтверждает: матрица ролей и прав, дополненная сценариями регистрации, приглашения, блокировки и смены полномочий.
Сигнал риска: роли перечислены, но действия и видимость данных не определены.
6. Постройте модель юридических лиц, договоров и торговых точек
В B2B один пользователь может быть связан с несколькими контрагентами, филиалами или торговыми точками. У каждого юридического лица могут быть собственные договоры, цены, лимиты, условия оплаты, адреса доставки и документы. Простого поля «Компания» в профиле обычно недостаточно.
До проектирования интерфейса определите иерархию сущностей и правила переключения между ними. Нужно однозначно понимать, какой договор используется в заказе, где хранится связь пользователя с организацией и может ли история быть общей для группы компаний.
Готовность подтверждает: модель организационных сущностей и несколько реальных примеров сложных связей из клиентской базы.
До проектирования интерфейса определите иерархию сущностей и правила переключения между ними. Нужно однозначно понимать, какой договор используется в заказе, где хранится связь пользователя с организацией и может ли история быть общей для группы компаний.
Готовность подтверждает: модель организационных сущностей и несколько реальных примеров сложных связей из клиентской базы.
7. Зафиксируйте коммерческие правила
Фраза «цена приходит из 1С» не описывает бизнес-логику. Нужно определить, какой прайс действует для контрагента, как выбирается договор, как применяются скидки, когда цена фиксируется и что увидит пользователь, если расчёт невозможен.
То же относится к остаткам. Физическое наличие, доступный к продаже остаток, резерв и ожидаемая поставка — разные показатели. Если портал показывает их одинаково, клиент получает неверное представление о возможности отгрузки.
То же относится к остаткам. Физическое наличие, доступный к продаже остаток, резерв и ожидаемая поставка — разные показатели. Если портал показывает их одинаково, клиент получает неверное представление о возможности отгрузки.
Пример из практики: остатки на нескольких складах
В проекте с несколькими регионами одному городу обслуживания могло соответствовать несколько складов. Показывать общий остаток без учёта этой связи было нельзя: пользователь мог увидеть товар, который недоступен для его торговой точки.
Для реализации потребовалось согласовать правила связи города и складов, а затем проверить, что учётная система передаёт корректные идентификаторы и остатки каждого склада.
Принятое решение: В личном кабинете остатки показываются по складам, связанным с городом дистрибьютора. Источником значений остаётся учётная система, а портал применяет согласованную модель видимости.
Готовность подтверждает: матрица коммерческих правил и примеры расчётов на реальных клиентах, товарах, договорах и складах.
8. Определите источники данных и направления обмена
Для каждой сущности должен быть один владелец: каталог, клиент, договор, цена, остаток, заказ, статус и документ. Если одни и те же поля можно менять в нескольких системах, рано или поздно данные начнут расходиться.
Составьте схему обменов между ERP или 1С, CRM, PIM, WMS, ЭДО и другими сервисами. Укажите направление, инициатора, частоту, формат и поведение при задержке, повторной отправке, недоступности или конфликте. Интеграция — часть основного сценария, а не техническая задача, которую можно оставить на конец проекта.
Готовность подтверждает: реестр данных и схема интеграционных потоков с владельцами систем.
Составьте схему обменов между ERP или 1С, CRM, PIM, WMS, ЭДО и другими сервисами. Укажите направление, инициатора, частоту, формат и поведение при задержке, повторной отправке, недоступности или конфликте. Интеграция — часть основного сценария, а не техническая задача, которую можно оставить на конец проекта.
Готовность подтверждает: реестр данных и схема интеграционных потоков с владельцами систем.
9. Проверьте API и назначьте владельцев доработок
Документация API не подтверждает, что нужный метод доступен, возвращает необходимые поля и работает на данных, похожих на реальные. Критичные методы нужно проверить вызовом на тестовом контуре до того, как команда заложит их в архитектуру и оценку.
Если метода или данных нет, необходимо заранее определить, где появится логика, кто её реализует, как будет приниматься результат и от какой даты зависит портал. AVE Digital адаптирует решение под действующую инфраструктуру, но портал не может получить данные или выполнить правило, которых нет в исходной системе.
Если метода или данных нет, необходимо заранее определить, где появится логика, кто её реализует, как будет приниматься результат и от какой даты зависит портал. AVE Digital адаптирует решение под действующую инфраструктуру, но портал не может получить данные или выполнить правило, которых нет в исходной системе.
Пример из практики: почему общего статуса заказа оказалось недостаточно
В одном заказе отдельные товарные позиции могли находиться в разных состояниях: часть была зарезервирована, часть ожидала поступления, часть находилась в производстве, а часть уже была отгружена. Общий статус скрывал фактическую картину исполнения.
Команда описала статусы строк и правила их отображения. После этого стало понятно, какие сведения должна передавать учётная система и как портал должен собирать из них понятное состояние заказа.
Принятое решение: В требования к обмену включили построчные статусы. Пример подтверждает необходимость проработки контракта данных; факт тестового вызова API следует фиксировать отдельно.
Готовность подтверждает: описание методов, согласованные форматы запросов и ответов, результаты тестовых вызовов и план доработок систем клиента.
10. Проектируйте сценарии, а не набор страниц
Прототип должен показывать полный путь пользователя: вход, выбор организации, поиск товара, работу с ценой и остатком, создание заказа, подтверждение, оплату, получение документов и отслеживание исполнения. Для каждого шага нужны пустые состояния, ошибки, ограничения доступа и подтверждение критичных действий.
Отдельно проверьте длинные таблицы, массовое добавление товаров, повтор заказа и ключевые операции на телефоне. Мобильная версия не должна быть уменьшенной копией десктопа: приоритеты и способ управления могут отличаться.
Готовность подтверждает: User Flow, интерактивные прототипы и согласованный набор состояний для десктопа и мобильной версии.
Отдельно проверьте длинные таблицы, массовое добавление товаров, повтор заказа и ключевые операции на телефоне. Мобильная версия не должна быть уменьшенной копией десктопа: приоритеты и способ управления могут отличаться.
Готовность подтверждает: User Flow, интерактивные прототипы и согласованный набор состояний для десктопа и мобильной версии.
11. Переведите требования к безопасности и скорости в условия проверки
Требования «быстро» и «безопасно» невозможно принять. До разработки согласуйте способы авторизации, правила сессий, журнал действий, работу с персональными и коммерческими данными, ожидаемые объёмы каталога и частоту обменов.
Нужно заранее определить, какие операции критичны по времени, что будет происходить при сбое, как система восстанавливается и какие события должны попадать в мониторинг. Эти решения влияют на инфраструктуру и план тестирования.
Готовность подтверждает: нефункциональные требования и сценарии проверки безопасности, нагрузки, резервного копирования и восстановления.
Нужно заранее определить, какие операции критичны по времени, что будет происходить при сбое, как система восстанавливается и какие события должны попадать в мониторинг. Эти решения влияют на инфраструктуру и план тестирования.
Готовность подтверждает: нефункциональные требования и сценарии проверки безопасности, нагрузки, резервного копирования и восстановления.
12. Что должен подготовить клиент
Со стороны клиента нужны не только доступы. В проекте должны участвовать бизнес-владелец и эксперты продаж, финансов, склада, логистики, IT и безопасности. Команде потребуются примеры товаров, клиентов, договоров, цен, остатков, заказов, статусов и документов, а также доступ к специалистам по интегрируемым системам.
Отдельно согласуйте, кто дорабатывает ERP, 1С, CRM, PIM, WMS или ЭДО, кто принимает эти изменения и как задачи синхронизируются с разработкой портала. Если зависимость не включена в план владельца исходной системы, она почти неизбежно станет блокером.
Отдельно согласуйте, кто дорабатывает ERP, 1С, CRM, PIM, WMS или ЭДО, кто принимает эти изменения и как задачи синхронизируются с разработкой портала. Если зависимость не включена в план владельца исходной системы, она почти неизбежно станет блокером.
13. Красные флаги до разработки
Старт стоит остановить, если требования собирает только один отдел, никто не может принять финальное решение, источник цены или остатка не определён, интеграции оставлены «на потом», API существует только по словам или нет тестовых данных со сложными договорами и несколькими складами.
Другой характерный сигнал — постоянное расширение MVP без пересмотра зависимостей и критериев запуска. В этом случае команде нужен не новый срок, а предпроектное обследование, которое превратит противоречивые ожидания в согласованную модель.
Другой характерный сигнал — постоянное расширение MVP без пересмотра зависимостей и критериев запуска. В этом случае команде нужен не новый срок, а предпроектное обследование, которое превратит противоречивые ожидания в согласованную модель.
14. Проверьте готовность проекта по полному брифу
В отдельном интерактивном брифе собраны вопросы по бизнес-целям, процессам, данным, интеграциям, API, UX, безопасности, тестированию и запуску. После заполнения вы получите результат: можно ли переходить к разработке, есть ли управляемые риски или сначала нужен предпроект.
Получить бриф готовности к внедрению B2B портала
Во второй части статьи — «Как подготовить B2B-портал к запуску и работе после релиза» — разберём тестовые данные, пилот, обучение, поддержку, мониторинг и оценку результата.
Подробная последовательность работ и состав проектных артефактов раскрыты в материале «Методология внедрения B2B-портала».
Получить бриф готовности к внедрению B2B портала
Во второй части статьи — «Как подготовить B2B-портал к запуску и работе после релиза» — разберём тестовые данные, пилот, обучение, поддержку, мониторинг и оценку результата.
Подробная последовательность работ и состав проектных артефактов раскрыты в материале «Методология внедрения B2B-портала».
Разработка B2B порталов
