Портал замовлень B2B: обсяг, фази, інтеграція з ERP

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

Що таке портал замовлень B2B?

Портал замовлень B2B — це брендований вебканал, у якому ваші схвалені дистриб'ютори та торгові клієнти входять до системи й працюють самостійно: переглядають каталог, видимий для їхнього акаунта, бачать узгоджені з ними ціни, формують нове замовлення чи повторюють попереднє та знаходять документи, що належать їхньому акаунту — комерційні пропозиції, замовлення, рахунки, кредит-ноти, поставки. ERP залишається системою обліку; портал — це вікно в неї, з правилами про те, що кожен акаунт може бачити й робити.

Варто відрізняти портал від трьох споріднених рішень, з якими його часто плутають:

Веб-магазин. Роздрібні ціни, відкрита реєстрація, оплата карткою. Портал дистриб'ютора — це протилежність: доступ надають за акаунтом, ціни є договірними, а оплата відбувається за узгодженими умовами, а не через касу.

Особистий кабінет на маркетинговому сайті. Корисний для завантаження файлів і звернень до підтримки, але без каталогу, ціноутворення та логіки замовлень він не прибирає жодного дзвінка до відділу продажів.

PDF-прайс-лист, надісланий електронною поштою. Стан, у якому більшість дистриб'юторів перебуває до появи порталу: точний того дня, коли його надіслали, застарілий уже за тиждень і недоступний для пошуку за конкретним акаунтом.

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

Таблиця функцій: обов'язково, бажано, пізніше

Сторінки функцій у постачальників перелічують усе одразу. Саме розмежування за етапами робить перший реліз таким, який можна випустити. Таблиця впорядковує регулярні функції за тим, що потрібно в першому релізі, що зазвичай додають у другому та що може зачекати на реальні дані про використання:

Таблиця A: функція | призначення | етап (1/2/3) | залежність від ERP

Функція	Призначення	Етап	Залежність від ERP
Акаунти клієнтів і вхід у систему	Кожен дистриб'ютор бачить лише власні дані	1	Акаунти та контакти
Прайс-листи за акаунтом	Договірні ціни, групи цін або ступінчасте ціноутворення для кожного акаунта	1	Прайс-листи та групи цін
Каталог з видимістю за акаунтом	Товари, які може купувати кожен акаунт, з документами та зображеннями	1	Довідник товарів, правила «акаунт—товар»
Швидке замовлення та повтор	Артикули, CSV або поле завантаження, повтор останнього замовлення	1	Довідник товарів, правила мінімального замовлення
Передавання замовлення в ERP	Замовлення стає документом ERP, а не листом	1	API замовлень або канал інтеграції
Статус замовлення та видимість документів	Рахунки, кредит-ноти, поставки, видимі за акаунтом	2	Архів документів або фінансова система
Пропозиції та перетворення пропозиції на замовлення	Запит ціни, затвердження, перетворення на замовлення	2	Документи пропозицій в ERP
Кредитні ліміти та умови оплати з відстрочкою	Показати акаунту його стан і умови; заблокувати подання замовлення поза правилами	2	Дані про кредит і умови в ERP
Платежі в порталі	Онлайн-розрахунок за рахунками або замовленнями	3	Платіжний шлюз плюс звірка з ERP
Ролі для затвердження замовлень	Закупівельник пропонує, затверджувач схвалює, ліміти за роллю	3	Дані про затвердження або процес на боці порталу
Багатомовний каталог і документи	Мова торгівлі за ринком або за акаунтом	3	Переклади товарів, шаблони документів
Відстеження та повідомлення про відправлення	Статус відправлення без дзвінка до відділу продажів	3	Дані логістики або доставки

Етап 1 — це реліз, який змінює поведінку: якщо дистриб'ютор може увійти, побачити свої ціни, повторити замовлення за минулий місяць і довести його до ERP, телефонний та табличний канал починає закриватися сам собою. Етапи 2 і 3 додають фінансовий і управлінський рівні, для яких спершу потрібні рішення організації щодо кредиту, фінансів і затверджень, і лише потім програмне забезпечення може їх утримати.

Інтеграція з ERP та CRM

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

Напрямок синхронізації. Майстер-дані — акаунти, товари, ціни, умови — надходять із ERP у портал. Замовлення, запити ціни та платежі йдуть у зворотному напрямку. Усе інше потребує явного власника: хто може змінювати ціну і де ця зміна зберігається?

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

Обробка збоїв. Коли ERP недоступна або запис не проходить перевірку, що робить портал: ставить у чергу, відхиляє чи показує останній відомий стан із чітким повідомленням? Тихий збій — це шлях до того, що дистриб'ютор замовляє за ціною минулого тижня, а суперечка стає вашою, а не його.

Звірка. Як ви дізнаєтеся, що кожне замовлення з порталу стало рівно одним документом ERP — без дублів, без пропусків, без напівконвертованих записів? Відповідь — операційний звіт, який хтось читає щодня протягом перших місяців, і це один із наведених нижче приймальних тестів.

Більшість проєктів покривають дві моделі розгортання. Шлях «нативно в ERP» будує портал як розширення власних можливостей ERP: це мінімізує кількість систем, які треба узгоджувати, але успадковує обмеження фронтенду ERP. Шлях «платформа» запускає commerce-платформу — Shopify та подібні системи зазвичай наводять у матеріалах постачальників — і з'єднує її з ERP через проміжне програмне забезпечення або конектори; цей варіант дає гнучкість фронтенду й звичний інтерфейс адміністрування ціною ще однієї системи, яку треба тримати синхронізованою. Сторінка про власне чи готове ERP розглядає ширшу версію цього питання «зробити чи купити», а контрольний список вимог до постачальника (RFP) перетворює обидва варіанти на запитання, які можна оцінити в пропозиції.

Багатомовні каталоги та каталоги з кількома валютами

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

Мови. Каталогу потрібні переклади назв товарів, категорій і документів; структура акаунтів потребує мовних уподобань для кожного акаунта, щоб портал не змушував того самого покупця обирати мову щоразу. Два практичні моменти: визначте, хто відповідає за переклади та їхній ритм оновлення — наполовину перекладений каталог читається гірше за англомовний для того покупця, який це помітить, — і вирішіть, чи документи (пропозиції, рахунки) наслідують мову інтерфейсу, чи залишаються мовою, якої вимагає ваша фінансова система. Друге питання не технічне: рахунок не тією мовою — це бухгалтерська проблема.

Валюти. Ціни, узгоджені в одній валюті, мають показуватися саме в ній незалежно від розташування відвідувача; змішування валюти відображення з договірною валютою — це початок суперечок. Якщо акаунт торгує більш ніж в одній валюті, правило має зберігатися в даних ERP, а не в налаштуваннях порталу, і портал у жодному разі не повинен бути місцем, де вигадують курс конвертації.

Обидві теми пов'язані з поетапним планом: експортер, який продає на три ринки, може запустити етап 1 мовами, які ці три ринки справді використовують у замовленнях, і додавати інші мови каталогу тоді, коли цього вимагає ринок. Загальне правило для мовної роботи на комерційних сайтах — один власник, один вихідний файл, один шлях оновлення — викладено на сторінці про інтернет-маркетинг, і воно так само застосовне до каталогу порталу.

Безпека та ролі

Портал — це двері до ваших комерційних даних, тож питання дизайну тут є питаннями доступу:

Доступ надають, а не отримують самореєстрацією. Кожен акаунт створює ваша команда на основі акаунта в ERP; альтернатива — відкрита реєстрація з етапом затвердження — приносить шум і розмиває, хто насправді є клієнтом.

Дозволи за ролями. Закупівельник може формувати й подавати замовлення в межах ліміту; затверджувач — схвалювати їх; спостерігач — лише читати документи. Ліміти за роллю — частина комерційних умов, а не технічний додаток: вони фіксують, хто в організації вашого клієнта може його зобов'язати.

Ізоляція акаунтів. Найсерйозніший збій у цьому класі продуктів — коли один дистриб'ютор бачить ціни чи документи іншого. Видимість даних за акаунтом потрібно тестувати окремо, і це один із наведених нижче приймальних тестів.

Журнал аудиту. Хто розмістив замовлення, хто його схвалив, хто змінив ціну й коли — усе зберігається як дані, а не як файли журналів, які ще треба когось переконати прочитати. Торгові суперечки частіше вирішуються за цим слідом, ніж за пам'яттю.

Ідентифікація та єдиний вхід. Для більших дистриб'юторів єдиний вхід (SSO) до їхнього власного каталогу є частою вимогою, яку варто планувати пізніше, а не раніше: більшість акаунтів чудово працюють на запрошеннях і паролях, доки головний офіс не попросить федерацію.

Захист даних. Дані клієнтів у порталі підпадають під ті самі обов'язки, які компанія вже має щодо своїх клієнтських записів: для турецьких операцій це рамки KVKK, а для європейських клієнтів — GDPR; цю тему докладно розглянуто на сторінці про аутсорсинг у контексті роботи з партнером із розробки.

Власна розробка чи готова платформа

Вибір не зводиться до абстрактного «власне проти готового»; ідеться про те, який рівень ви насправді купуєте.

Таблиця B: шлях | що ви отримуєте | що ви несете | коли підходить

Шлях	Що ви отримуєте	Що ви несете	Коли підходить
Портал нативно в ERP	Єдина система обліку, ціни й кредит уже узгоджені, менше інтерфейсів	Фронтенд і мобільність обмежені власними можливостями ERP; цикли оновлення ERP визначають розвиток порталу	ERP сучасна, її портальний модуль покриває більшу частину етапу 1, а внутрішній ІТ-відділ може його адмініструвати
Commerce-платформа + конектор до ERP	Звичне адміністрування, сильний фронтенд і мобільний досвід, швидка робота з каталогом	Ще одна система, яку треба тримати синхронізованою; підтримка конектора; два шляхи оновлення	Досвід купівлі важить не менше за дані, і хтось відповідає за інтеграцію надовго
Власний портал	Точна відповідність комерційним правилам, зокрема й незвичним, що визначають вашу торгівлю	Повна відповідальність: безпека, продуктивність, оновлення, весь життєвий цикл	Процес справді вирізняє бізнес і жодна платформа його не витримує — перевірка в тому, чи не вистачить стандартної функції плюс зміни процесу

Середній шлях обирає більшість експортерів на першому етапі, і помилка, якої слід уникати, — вважати його дешевим: конектор — це продукт, який потребує підтримки, і його вартість повторюється. Структуру рішення для цього питання — налаштувати, купити чи розробити — докладно розглянуто на сторінці про власне чи готове ERP; те, що додає ця сторінка, — тест саме для порталу: що б ви не обрали, прайс-лист за акаунтом і замовлення в ERP мають пройти перевірку на відповідність, а обраний шлях має давати змогу підтвердити їхню правильність за найнижчої повторюваної вартості.

Поетапне впровадження та приймальні тести

Запуск порталу провалюється тихо, коли «це працює» означає «працювало в демо». Кожен етап має супроводжуватися письмовими приймальними тестами, які виконують на реальних акаунтах і реальних даних:

Видимість каталогу за акаунтом. Увійдіть як два різні дистриб'ютори; кожен бачить рівно свій набір товарів і жодного сліду чужого. Це тестують навмисно, а не припускають.

Точність цін. Для вибірки акаунтів і артикулів ціна в порталі дорівнює ціні в ERP — з урахуванням правил за нею (група цін, рівень, угода). Це тест, який захищає комерційні відносини: неправильна ціна в порталі гірша за неправильну ціну в пропозиції, бо клієнт бачив її як чинну угоду.

Цілісність замовлення. Замовлення, розміщене в порталі, стає рівно одним документом ERP з правильними артикулами, кількостями, одиницями та цінами — і звіт про звірку це показує. Перевірте й шлях збою: замовлення, заблоковане правилом, має чітко це повідомити, а не завершитися невдачею мовчки.

Статуси та документи. Рахунок і поставка, зафіксовані в ERP, з'являються в поданні порталу правильного акаунта, з правильним статусом, у межах узгодженого вікна синхронізації.

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

Щоденні звички. Повтор замовлення, швидке замовлення за артикулом і пошук — на двох реальних товарних списках ваших дистриб'юторів, а не на демо-каталозі. Від цих трьох шляхів залежить, чи приживеться портал, і перевірити їх належно коштує лише частку від розробки.

Порядок впровадження важить не менше за тести: спершу один пілотний ринок або кілька акаунтів, їхні відгуки враховують, потім ширше відкриття. Альтернатива — анонс запуску всім дистриб'юторам того самого дня — перетворює перші тижні неминучих правок на втрату довіри, а дистриб'ютори, які знаходять неправильну ціну першого тижня, часто повертаються до телефону на місяці. Логіка пілота — та сама, що описана для проєктів із програмного забезпечення на сторінці про аутсорсинг, а дисципліна оцінювання для команд, які будують портали, викладена в контрольному списку вимог (RFP).

Часті запитання

Чи потрібна нам спершу ERP?

Не нова — але майстер-дані мають десь зберігатися надійно: акаунти, товари, прайс-листи та умови. Якщо вони живуть лише в електронних таблицях, портал автоматизує помилки таблиці за кожним акаунтом, а це гірше за роботу по телефону. У такому разі чесна послідовність — спершу стабілізувати дані (часто в наявній ERP, яку недовикористовують), а портал — після; сторінка про Odoo для торгових компаній розглядає це рішення з боку ERP.

Чи можуть клієнти мати власні прайс-листи?

Так — ціноутворення за акаунтом є суттю цього класу продуктів, а не додатком: групи цін, ступінчасте ціноутворення або індивідуальні угоди, усе це зберігається в ERP і показується за акаунтом. Правило, на якому слід наполягати, — портал ніколи не ціноутворює сам; він показує те, що зберігає ERP, і кожну ціну, яку бачить дистриб'ютор, можна простежити до угоди, укладеної вашою командою.

Як затверджують замовлення?

Зазвичай на двох рівнях. Усередині організації вашого клієнта затвердження — його: закупівельник пропонує, затверджувач схвалює, за потреби в межах лімітів — портал може підтримувати ці ролі на етапі 3. Усередині вашої власної організації замовлення надходить в ERP і проходить звичну для вас обробку; портал не замінює контроль відділу продажів, він прибирає повторне введення даних і дзвінок навколо них.

Чи підтримує портал кілька мов?

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

Кому належать дані?

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

Як підключати дистриб'юторів?

Почніть з акаунтів, які замовляють найбільше, запросіть їх особисто й дайте в першому повідомленні три речі: їхній логін, їхній прайс-лист на екрані та одну людину, якій можна зателефонувати. Далі стежте за сигналом впровадження, який справді важить, — не за кількістю входів, а за часткою обсягу повторних замовлень, що надходить через портал. Паралельна робота (замовлення через портал, потім підтвердження телефоном) — нормальна протягом тижнів; вона закінчується, коли портал доказово правильний щодо цін і документів, а для цього й призначені приймальні тести вище.

Джерела та стандарти

Наведений тут типовий набір функцій (акаунти, прайс-листи за акаунтом, повтор замовлення, рахунки та кредит-ноти, видимість за акаунтом, ролі з лімітами, умови з відстрочкою, платіжні шлюзи) відповідає загальним описам можливостей для порталів замовлень B2B у постачальників; жодних тверджень про результат продуктивності, вартість чи строки на цій сторінці немає.
Моделі розгортання (портал нативно в ERP; commerce-платформа, як-от Shopify, синхронізована з ERP через проміжне програмне забезпечення або конектори) описано як два повторювані шляхи; жодного партнерства з постачальником будь-якої платформи не заявлено.
Твердження про процеси та управління спираються на сторінки цього сайту: власне чи готове ERP, контрольний список вимог до постачальника, Odoo для торгових компаній та ІТ-аутсорсинг із Туреччини (обов'язки щодо захисту даних, інтелектуальна власність та умови виходу, дизайн пілота).
На цій сторінці немає прикладів клієнтів, бюджетів порталу чи тривалості проєктів; обсяг, етапи та комерційні умови визначають для кожного проєкту в пропозиції.

Пов'язані сторінки

Розробка програмного забезпечення · Власне чи готове ERP · Контрольний список вимог до постачальника · Odoo ERP для торгових компаній · Інтернет-маркетинг · Запросити пропозицію