Запуск B2B-кабинета по этапам: от MVP до интеграции с 1С

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

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

Эта статья дополняет материал «B2B-кабинет на Битрикс: что реально нужно бизнесу». Там разобраны приоритеты функций — цены, быстрый заказ, роли и то, что можно отложить. Здесь фокус другой: последовательность проектирования, интеграции, пилота и промышленного запуска.

Этап 0. Назначить владельца процесса

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

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

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

Этап 1. Описать текущий путь заказа

Начните не с экранов будущего кабинета, а с одного реального заказа. Как клиент узнаёт цену? Откуда менеджер берёт остаток? Кто проверяет договор? Где создаётся заказ? Как отправляются счёт и статус?

Зафиксируйте:

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

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

Этап 2. Определить источники истины

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

Формулировка «данные синхронизируются» недостаточна. Нужна таблица:

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

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

Этап 3. Сформировать границы MVP

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

В типичное ядро могут войти:

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

Историю документов, сложную аналитику, бонусы, чат и широкую персонализацию можно вынести дальше, если они не блокируют заказ. Но безопасность, права, идемпотентность и диагностику нельзя откладывать как «не-MVP»: без них пилот не даст надёжных выводов.

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

Этап 4. Проверить платформу и лицензию

До архитектуры нужно сверить возможности текущей редакции 1С-Битрикс. Для сложного магазина, нескольких складов, типов цен и B2B-сценариев может быть релевантна редакция «1С-Битрикс: Бизнес». Но наличие продукта в связанных материалах не означает, что он автоматически нужен каждому кабинету.

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

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

Этап 5. Сделать прототип правил, а не только дизайна

Интерактивный макет помогает проверить навигацию, но главный риск B2B скрыт в данных. Прототип должен показать:

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

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

Отдельно согласуйте терминологию. «Заказ», «заявка», «резерв» и «счёт» должны означать одно и то же для клиента, менеджера и 1С.

Этап 6. Спроектировать интеграцию с 1С

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

Из 1С на сайт

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

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

С сайта в 1С

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

Обратные статусы

Пользователю важен не технический ответ «получено», а понятное состояние: принят, проверяется, подтверждён, отгружен, отменён. Карта соответствия между внутренними статусами 1С и текстом кабинета согласуется с бизнесом.

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

Этап 7. Реализовать вертикальный сценарий

Вместо разработки всех экранов по слоям соберите один путь целиком: авторизация — каталог — цена — корзина — заказ — передача — статус. Такой вертикальный срез рано обнаруживает несовместимость данных и позволяет показать бизнесу рабочий результат.

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

• критерии приёмки;
• права;
• журналирование;
• тесты ошибок;
• способ выпуска;
• описание настроек.

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

Этап 8. Подготовить данные и доступы

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

Варианты подключения:

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

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

Этап 9. Провести внутреннее тестирование

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

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

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

Этап 10. Запустить пилот

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

Измеряйте операционные признаки без заранее придуманных обещаний:

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

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

Этап 11. Обучить и развернуть

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

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

Этап 12. Развивать по данным эксплуатации

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

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

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

Основные риски по этапам

Неясные правила. Решаются владельцем процесса и таблицей решений до кода.

Грязные данные. Нужны проверка внешних ID, дублей и договоров до приглашения пользователей.

Слишком широкий MVP. Используйте один вертикальный сценарий и ограниченную группу.

Интеграция «в конце». Проверяйте обмен на раннем срезе.

Нет очереди и логов. Любая временная недоступность 1С превращается в потерянный заказ.

Слабая изоляция компаний. Серверные проверки прав обязательны для каждого запроса.

Принудительный переход. Пилот и параллельный канал снижают операционный риск.

Отсутствие владельца после запуска. Назначьте ответственного за данные, очередь и бэклог.

Как сформировать дорожную карту

Удобно планировать результаты, а не календарные обещания:

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

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

Следующий шаг

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

На странице разработки B2B-кабинета на 1С-Битрикс можно отправить этот контекст. Практичный старт — определить границу MVP и отдельно обследовать готовность обмена с 1С. После этого проект получает этапы, критерии приёмки и пилотный план вместо попытки запустить все функции одним рискованным релизом.