MVP B2B-портала за 5 месяцев: как определить состав первой версии и не сорвать запуск

06.10.2026

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

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

MVP — это не полный портал с отключённой половиной функций. В первой версии должен полностью работать один выбранный бизнес-процесс на реальных данных.

1. Почему B2B-порталы годами не доходят до запуска

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

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

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

2. Что такое MVP B2B-портала

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

Формат	Чем отличается от MVP
Прототип	Проверяет логику и интерфейс; может не иметь реальных данных и рабочих интеграций.
Пилот	Способ запуска на ограниченной аудитории. Пилотировать можно MVP или более зрелую версию.
Первая очередь разработки	Организационный этап проекта; не обязательно содержит законченный пользовательский сценарий.
Полноценный продукт	Охватывает больше аудиторий, процессов, исключений и инструментов развития.
Набор функций	Может состоять из работающих модулей, но не давать пользователю сквозного результата.

Рабочая формула MVP: ограниченная аудитория + один ключевой сквозной сценарий + реальные данные + рабочие интеграции + измеримый результат.

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

3. С какого сценария начинать

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

БАЗОВЫЙ МАРШРУТ Авторизация → выбор организации → каталог → персональная цена → остаток → корзина → оформление заказа → передача в ERP → статус → документы.

Для другого бизнеса ядром будет заказ по договору, резервирование товара, согласование закупки, работа дилера с несколькими торговыми точками, получение финансовых документов или оформление рекламации. Универсального «правильного» маршрута нет.

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

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

Если хотя бы на часть этих вопросов нет ответа, сначала лучше проверить готовность проекта. Для этого можно использовать «Чек-лист внедрения B2B-портала», а последовательность предпроекта и интеграционной проработки — «Методологию внедрения B2B-портала».

4. Как определить состав MVP

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

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

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

Из практики: финансовые условия в MVP

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

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

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

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

Функция	Ценность для бизнеса	Нужна для сквозного сценария	Готовность данных / API	Решение по MVP
Персональная цена	Высокая	Да	Подтверждена	Обязательно
Бонусная программа	Зависит от модели	Нет	Частичная	Следующий этап
Статусы заказа	Высокая	Да	Подтверждается	Обязательно; требуется подготовить обмен данными
Расширенная аналитика	Средняя	Нет	Есть	Желательно / Следующий этап
Мобильное приложение	Зависит от аудитории	Нет для web-MVP	Не влияет	Вне первой версии

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

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

5. Что обычно входит в MVP B2B-портала

Для портала, где основной сценарий — самостоятельное оформление повторного заказа, ядро первой версии обычно включает:

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

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

В исследовании Data Insight 2025 рассматриваются разные модели цифровизации B2B — от отдельных сервисов до платформ, связанных с корпоративными системами. Поэтому состав MVP следует определять по процессам конкретной компании, а не копировать из чужого функционального списка

6. Когда запуск за пять месяцев реалистичен

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

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

Когда срок в пять месяцев нужно пересматривать

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

Из практики: правила ценообразования

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

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

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

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

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

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

7. Пример дорожной карты на пять месяцев

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

Период	Основные работы	Результат	Ответственность клиента	Ответственность разработчика
Месяц 1	Цели, процессы, роли, MVP, архитектура, источники данных, риски	Зафиксированные границы и критический путь	Эксперты, решения, доступы, владельцы систем	Анализ, формализация, архитектурная и интеграционная схема
Месяц 2	Сценарии, требования, правила обмена данными, UX, дизайн ключевых экранов, тестовую среду; старт основной серверной части	Согласованные сценарии и согласованные правила обмена для разработки	Согласования, план доработки обмена, тестовые данные	Проектирование интерфейса, ТЗ, правила обмена, старт разработки
Месяцы 3–4	Интерфейс и серверная часть, роли, каталог, цены, остатки, заказы, статусы, документы; интеграционные и внутренние тесты	Рабочая версия на тестовой среде	Доработки ERP/1С, проверка данных, бизнес-тесты	Разработка, интеграции, тестирование, исправления
Месяц 5	Сквозное тестирование, критические исправления, обучение, пилот, запуск, сбор обратной связи	MVP для ограниченной аудитории и список задач для следующих этапов	Пилотные пользователи, приёмка, поддержка запуска	Релиз, сопровождение пилота, мониторинг, список задач

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

8. Критический путь проекта

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

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

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

9. Почему критичные интеграции нужно проверять до завершения интерфейсов.

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

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

Три исходных ситуации

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

2) Данные есть, но обмен нужно доработать. Информация хранится в 1С или ERP, однако не всё поступает в портал. Команда определяет необходимые доработки, ответственных и сроки.

3) Нет необходимых данных или правил. Например, расчёт скидки менеджер выполняет вручную. Сначала нужно согласовать правило и решить, где его реализовать: в 1С, ERP или портале. Это может изменить состав MVP и план запуска.

Из практики: построчные статусы заказа

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

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

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

Подробнее о ранней проработке обмена данными — в «Методологии внедрения B2B-портала», о требованиях к обмену и обработке ошибок — в статье «Техническое задание на B2B-портал».

10. Как распределить ответственность.

Подрядчик не может компенсировать отсутствие решений на стороне клиента. Значимая часть критического пути зависит от бизнес-экспертов, специалистов 1С/ERP/CRM, тестовых данных, доступов, владельцев систем и пилотных пользователей.

Клиент	Совместная зона	Разработчик
Владелец продукта и бизнес-эксперты	Выбор и фиксация MVP	Анализ и формализация требований
Специалисты 1С/ERP/CRM	Согласование API и интеграционных сценариев	Архитектура, UX/UI и разработка
Доступы и тестовые данные	Проверка сквозных бизнес-сценариев	Интеграции в согласованной зоне
Согласования и решения	Приёмка	Функциональное и интеграционное тестирование
Пилотные пользователи и внутренние инструкции	Решение о запуске	Документация, релиз и поддержка пилота

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

11. Как защитить MVP от бесконечного расширения

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

Из практики: поэтапное подключение регионов

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

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

Подключение остальных регионов выделили в отдельные этапы развития портала.

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

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

Не каждое изменение — новая функция

Тип	Как отличить
Уточнение требования	Детализирует уже согласованное поведение и не расширяет результат или зависимые сценарии.
Исправление ошибки	Реализация не соответствует согласованному требованию или критерию приёмки.
Изменение бизнес-логики	Согласованное правило бизнеса меняется; требуется повторная оценка затронутых сценариев.
Новая функция	Появляется новая пользовательская возможность, процесс, роль, интеграция или результат.

12. Пилот вместо запуска сразу на всех клиентов

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

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

На пилоте проверяют:

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

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

13. Как измерить результат MVP

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

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

доля клиентов, которые начали пользоваться кабинетом;
доля заказов, оформленных через портал;
доля заказов, переданных в 1С или ERP без ошибок;
время оформления повторного заказа.

Из практики: отчёт о новых пользователях

На одном из проектов в состав MVP включили простой отчёт о количестве новых пользователей личного кабинета.

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

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

14. Что чаще всего срывает пятимесячный план

Риск	Как снижать
MVP не зафиксирован	Утвердить состав первой версии, список исключённых функций и порядок согласования изменений.
Нет владельца продукта	Назначить одного человека с правом принимать решения и приоритеты
Согласования идут неделями	Согласовать сроки ответа и назначить ответственных за спорные решения.
Правила существуют только «в головах»	Разбирать реальные примеры и фиксировать решения в сценариях и требованиях.
Проверку обмена оставили на конец	Проверить обмен и тестовую среду в первые недели; включить доработки ERP в общий план.
Данные неполные или некорректные	Проверить качество данных до разработки и подготовить примеры для тестирования.
Тестовая среда отличается от рабочей	Заранее согласовать тестовую и рабочую среды, их настройки и данные.
Эксперты клиента перегружены	Зарезервировать их время в календаре проекта и назначить заместителей.
Дизайн согласуют отдельно от сценариев	Проверять экраны на реальных бизнес-сценариях, включая ошибки.
Тестирование начинается поздно	Тестировать модули и интеграции по мере готовности, не ждать «готового портала».
Пилот становится сбором хотелок	Разделять ошибки и пожелания; изменения состава MVP согласовывать отдельно.
В MVP включают все исключения	Автоматизировать частые случаи, а редкие временно обрабатывать по согласованному порядку.
Нет обучения и поддержки	Подготовить инструкции, канал обращений, мониторинг и ответственных до открытия доступа.

Если нужна более широкая проверка готовности до разработки, используйте «Чек-лист внедрения B2B-портала». Если требования уже собраны и нужно проверить их качество — материал «Техническое задание на B2B-портал».

16. Итог: пять месяцев — результат управляемого объёма, а не ускоренной разработки.

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

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

Разработка B2B порталов