Как реализовать B2B-портал на Битрикс?

Основные части B2B-портала:

• регистрация компаний и управление сотрудниками

• роли и ограничения доступа

• персональный каталог, цены и условия

• оформление, согласование и повторение заказов

• документы, статусы и история операций

• обмен с 1С, CRM, ERP и другими системами

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

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

B2B-портал начинается с процесса, а не с личного кабинета

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

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

Перед проектированием нужно определить:

• как компания получает доступ к порталу

• кто подтверждает регистрацию

• какие сотрудники могут действовать от имени одной организации

• кто создаёт, согласовывает и оплачивает заказ

• где рассчитываются цены и доступность

• кто меняет статус заказа

• какие документы получает партнёр

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

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

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

Основные различия двух форматов:

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

Организация, пользователи и роли должны быть разделены

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

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

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

Команда фиксирует:

• кто и каким образом создаёт организацию в портале

• как к ней добавляются сотрудники

• кто назначает и меняет роли

• какие действия разрешены каждой роли

• какие данные видны внутри одной компании

• что происходит после увольнения сотрудника

• как проверяются новые регистрационные данные

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

Персональные цены нужно связывать с договорными правилами

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

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

Перед разработкой нужно определить:

• где создаётся договорная цена

• какая система считается её основным источником

• как долго действует условие

• может ли менеджер изменить цену вручную

• что увидит клиент, если цена отсутствует

• когда цена фиксируется в заказе

• как обрабатывается изменение после согласования

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

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

Каталог должен учитывать доступность для конкретного партнёра

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

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

Основные правила B2B-каталога:

• доступный организации ассортимент

• единицы продажи и кратность упаковки

• минимальное количество

• остатки по разрешённым складам

• аналоги и замены

• возможность заказа отсутствующего товара

• ограничения по договору или региону

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

Оформление заказа должно повторять правила компании

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

Возможные сценарии заказа:

• быстрое добавление товаров по артикулам

• загрузка списка позиций из файла

• повторение прошлого заказа

• сохранение шаблона закупки

• согласование внутри компании клиента

• запрос коммерческого предложения

• резервирование товаров

• разделение заказа по складам или датам поставки

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

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

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

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

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

При работе с документами команда проверяет:

• какая система формирует оригинал

• кто имеет право его просматривать

• можно ли скачать предыдущую версию

• как документ связан с заказом и договором

• что происходит после отмены или изменения заказа

• нужно ли подтверждать получение или подписание

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

Интеграция с 1С определяет актуальность данных портала

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

Для каждого типа данных нужно назначить основной источник:

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

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

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

Что включить в первый запуск B2B-портала

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

Разделение функций по этапам может выглядеть так:

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

Безопасность нужно проектировать вокруг ролей и организаций

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

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

Для проверки доступа команда составляет сценарии по ролям:

• закупщик видит каталог и создаёт черновик

• руководитель согласовывает заказ своей организации

• бухгалтер получает разрешённые документы

• менеджер поставщика работает только с назначенными клиентами

• администратор компании управляет её сотрудниками

• отключённый пользователь больше не входит в портал

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

Компетентный разработчик понимает проект целиком

Компетентная команда не принимает формулировку «сделать личный кабинет дилера» как достаточное описание B2B-портала. Она выясняет, какую работу партнёр должен выполнить и какие внутренние процессы компании затронет новое решение

Вопросы, которые стоит задать разработчику:

• Какие роли и сценарии вы изучите до проектирования?

• Где хранятся договоры, цены, остатки и документы?

• Какие функции изменятся при смене роли или организации?

• Что вы проверите после передачи заказа во внутреннюю систему?

• Какие исключения могут повлиять на оценку?

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

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

Пример из практики Ameton

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

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

Практический вывод: B2B-портал нужно проектировать вокруг процессов организации, а не отдельных учётных записей

Как оценить подход к разработке B2B-портала

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

Критерии для сравнения решений:

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

Для каких проектов подходит B2B-портал на 1С-Битрикс

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

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

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