B2B-портал: этапы разработки и внедрения

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

Что вы узнаете из статьи

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

Когда компании нужен B2B-портал

B2B-портал позволяет партнёрам самостоятельно оформлять заказы, проверять цены и остатки, получать документы и отслеживать статусы. Он особенно полезен, когда ассортимент, цены, лимиты и порядок согласования зависят от клиента, а нужные данные хранятся в разных системах: учётной системе, CRM (системе управления отношениями с клиентами), ERP (системе управления ресурсами предприятия) и других сервисах.

Как разрабатывают и внедряют B2B-портал

Для планирования работу над B2B-порталом можно разделить на семь этапов. Для каждого согласуют результат, участие заказчика и задачи, которые можно выполнять параллельно.

1. Исследование бизнес-процессов и ролей

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

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

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

2. Определение состава первой версии и требований

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

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

Техническое задание (ТЗ) на B2B-портал описывает состав работ, требования к системе и критерии приёмки — условия, по которым заказчик проверяет результат. В него включают:

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

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

3. Проектирование данных, интеграций и прав доступа

B2B-портал подключают к учётным, CRM, ERP и складским системам, чтобы передавать заказы и получать цены, остатки, документы и статусы. Описания и характеристики товаров могут поступать из системы управления информацией о продуктах (PIM). Например, портал отправляет заказ в ERP и получает его номер и статус, а после отгрузки — обновлённый статус и документы.

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

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

4. Проектирование и дизайн интерфейса

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

5. Разработка и настройка интеграций

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

6. Тестирование и пилотный запуск

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

Проверки планируют по требованиям и рабочим процессам и проводят по мере разработки. Тестирование включает:

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

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

7. Внедрение, обучение и поддержка

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

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

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

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

Что влияет на сроки и бюджет B2B-портала

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

При оценке учитывают:

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

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

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

При внедрении стоит избегать следующих ошибок:

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

FAQ

Чем B2B-портал отличается от интернет-магазина?

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

Нужна ли интеграция с 1С в первом релизе?

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

Можно ли запускать B2B-портал частями?

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

Кто участвует в проекте со стороны компании?

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

Как понять, что портал готов к запуску?

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

Итог

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

В Айдис мы разрабатываем сложные веб-сервисы. Если вы планируете B2B-портал для дилеров, партнёров или корпоративных клиентов, расскажите нам о задаче, обсудим текущие процессы, функции первой версии, интеграции и порядок запуска.

См. также

• Техническое задание на сайт: из чего состоит хорошее ТЗ и как его использовать в работе
• Зачем нужен предпроектный анализ и как его провести?
• Пользовательский сценарий (User Flow)
• Прототип
• Сколько времени нужно на создание сайта: честный ответ без обтекаемых формулировок