Разработка B2B-платформы: функции, интеграции и из чего складывается смета

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

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

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

Снаружи похоже на магазин: каталог, карточка, корзина. Различия начинаются с первого же вопроса «сколько стоит».

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

Из этого следует всё остальное, включая смету.

Кому окупается быстрее всего

Эффект виден там, где заказы повторяются и каждый проходит через менеджера руками.

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

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

Один из наших проектов — как раз про то, чтобы сайт и учётная система не разошлись.

Функции: первая очередь и всё остальное

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

Первая очередь:

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

Вторая очередь:

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

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

Диапазон, а не точка: так честнее, и не возникает вопроса, почему у нас 60, а вы насчитали 110. Для первой очереди по ставке 3 500 ₽ в час это примерно 1,7–2,9 млн ₽, без интеграций. Они считаются отдельно.

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

Интеграции: здесь и живёт бюджет

Главная мысль всей статьи: смету двигают не экраны, а связи с внешним миром.

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

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

Второе правило: для каждого поля заранее назначается система-первоисточник. Цену меняет 1С, портал её только показывает. Если оба могут менять — данные разъедутся, это вопрос времени.

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

От чего зависит цена

Семь факторов, по убыванию влияния:

• Логика цен. Одна скидка на контрагента против матрицы по договору, объёму, складу и акции — разница в разы. Дешевле, когда цену считает учётка.
• Число и состояние интеграций. Готовые методы обмена сокращают работы, их отсутствие добавляет разработку на стороне обмена.
• Роли и согласования. Каждая роль — свой набор экранов, прав и проверок при тестировании. Маршрут согласования добавляет ещё слой.
• Документы. Скачать счёт в PDF и подписать УПД через оператора ЭДО — задачи разного порядка.
• Качество данных. Дубли в номенклатуре, контрагенты без ИНН, устаревшие соглашения о ценах — всё это чистится до переноса.
• Каналы. Только веб-кабинет или ещё приложение для закупщиков, которые заказывают со склада и объекта.
• Размещение и безопасность. Облако или свои серверы, журнал действий, ожидаемое число одновременных заказов.

Обратите внимание, чего в списке нет: количества экранов, дизайна и модности стека.

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

Что входит в смету, а что оплачивается отдельно

Входит в работу подрядчика:

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

Не входит, но в бюджете быть обязано:

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

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

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

Как проверить смету подрядчика

Шесть вопросов к любой смете:

• Разбита ли по функциям и интеграциям? Строка «разработка — 800 часов» не даёт понять, за что вы платите.
• Есть ли отдельная строка на каждую внешнюю систему? Интеграция с 1С и подключение ЭДО оцениваются по отдельности.
• Названы ли допущения? Например, что у учётки уже есть методы обмена. И что будет, если их нет.
• Заложены ли тестирование и перенос данных? Смета без них выглядит дешевле, но работы всё равно придётся оплатить.
• Понятно ли, что считается изменением объёма? Новая роль или новое правило цены после согласования ТЗ меняют смету — договоритесь заранее.
• Есть ли план первой очереди? Смета на весь портал сразу без очередей почти всегда означает длинный проект до первого заказа.

Fix Price или Time & Materials

На практике модели сочетают: первая очередь по Fix Price, развитие после запуска — по T&M со сметой перед каждой задачей. Это разумный компромисс, потому что до запуска объём предсказуем, а после — определяется тем, что скажут живые закупщики.

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

Как снизить стоимость без потери качества

Основную экономию дают решения, принятые до первой строки кода.

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

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

Начните с описания правил цен и перечня систем для интеграции. Это половина сметы, и она считается до того, как выбран подрядчик.

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