# Партнерские и B2B продажи тормозят из-за разрозненных данных

Canonical: https://www.kt-team.ru/blog/b2b-api-mdm-pim-preproject

Source: https://www.kt-team.ru/blog/b2b-api-mdm-pim-preproject

## Платформа не спасает, если не описан контур

У компаний с партнерскими продажами запрос часто звучит просто: нужен B2B-портал, внешний API и порядок в карточках товаров. Дальше в обсуждении появляются PIM, MDM, 1С или ERP, интеграционная шина, API Gateway, личный кабинет партнера, статусы заказов, документы, остатки, цены и разграничение доступа.

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

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

## Главное

- B2B-портал, API и PIM/MDM нельзя проектировать отдельно: партнер видит один сервис, а внутри работают учет, мастер-данные, интеграции, контент, документы и права доступа.
- Начинать нужно с сценариев партнерского канала: каталог, подбор товара, повторный заказ, статусы, документы, маркетинговые материалы, претензии и ограничения по видимости данных.
- Для каждого домена нужен владелец: продуктовая карточка, цена, остаток, заказ, статус, документ, медиа, коммерческое условие, партнер и роль доступа.
- PIM хорош для продуктового контента и публикации в каналы, MDM — для мастер-данных и правил качества, 1С или ERP — для учета и заказного контура, интеграционный слой — для доставки и надежности.
- Внешний API проектируется не с методов, а с модели ответственности: авторизация, ключи, rate limits, версии, идемпотентность, ретраи, дедупликация, журналы и мониторинг.
- Результатом обследования должна быть не презентация про инструмент, а карта AS-IS, требования, варианты TO-BE, критерии выбора платформы, roadmap и оценка следующего этапа.

## Почему задача стала срочной

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

Sana Commerce в B2B Buyer Report 2025 пишет, что 73% B2B-покупателей предпочитают покупать онлайн, 85% сталкиваются с фрустрацией в онлайн-заказе, а 75% готовы сменить поставщика ради лучшего онлайн-опыта. McKinsey B2B Pulse 2024 показывает, что e-commerce уже дает 34% B2B-выручки у респондентов и остается самым эффективным каналом для компаний, продающих онлайн.

С другой стороны, MuleSoft Connectivity Benchmark 2025 фиксирует средний ландшафт в 897 приложений, из которых интегрировано только 29%; при этом 95% организаций сталкиваются с интеграционными сложностями при внедрении AI. Postman State of the API 2025 показывает, что 93% API-команд имеют блокеры коллаборации: документация, дублирование, поиск существующих API и потеря контекста.

## Почему нельзя начинать с выбора PIM

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

Если начать с выбора PIM, команда быстро попадает в спор о функциях: какие атрибуты поддерживает платформа, есть ли workflow согласования, удобно ли грузить медиа, как устроены категории. Это важные вопросы, но они вторичны. До них нужно ответить на более жесткие: кто мастер для цены, где остаток, кто владелец статуса заказа, где живет документ, как партнер видит только свои условия, кто отвечает за качество карточки и как исправление попадет во все каналы.

Хорошее обследование не отменяет выбор платформы. Оно делает выбор проверяемым: платформа сравнивается с требованиями, а не с демо и списком функций.

## Целевой контур: не монолит, а группа сервисов

Партнерский канал работает поверх учетного, продуктового и интеграционного контуров.

- Учет → 1С / ERP: цены, остатки, заказы, статусы, документы, коммерческие условия.
- Мастер-данные → MDM: домены, владельцы, качество, справочники, правила изменения.
- Контент → PIM / DAM: карточки, атрибуты, характеристики, описания, медиа, маркетинговые материалы.
- Доставка → Интеграционный слой: очереди, ретраи, дедупликация, идемпотентность, логи, мониторинг.
- Канал → B2B-портал и API: самообслуживание партнеров, ключи, роли, лимиты, версии, статусы.

Слабая связанность здесь не архитектурная мода, а способ сохранить управляемость. Учет не превращается в CMS, PIM не становится системой заказов, портал не берет на себя доставку сообщений, а API Gateway не хранит бизнес-правила.

## Границы ответственности нужно зафиксировать явно

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

| Домен | Где обычно мастер | Что проверить на обследовании |
| --- | --- | --- |
| Номенклатура и SKU | 1С / ERP + MDM | коды, дубли, единицы измерения, жизненный цикл позиции |
| Атрибуты, описания, медиа | PIM / DAM | полнота карточек, качество, обязательные поля, каналы публикации |
| Цены и коммерческие условия | 1С / ERP / pricing-сервис | прайс-листы, индивидуальные условия, валюта, НДС, срок действия цены |
| Остатки и доступность | 1С / ERP / WMS | склад, резерв, доступность к заказу, период актуальности |
| Заказы и статусы | 1С / ERP / OMS | статусы, возвраты, частичная отгрузка, повторный заказ |
| Документы | 1С / ERP / ЭДО / DMS | счета, УПД, накладные, акты, доступ только своему партнеру |
| Партнеры и роли | CRM / MDM / IAM | иерархия контрагентов, пользователи, роли, ограничения видимости |
| API-доступ | API Gateway / IAM | ключи, OIDC, rate limits, версии API, аудит действий |

## Что обследовать в B2B-сценариях

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

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

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

## Минимальный набор входных материалов

- 10-20 реальных карточек товаров разных типов: простые, сложные, с характеристиками, медиа, описаниями и маркетинговыми материалами.
- Примеры прайс-листов, индивидуальных условий, остатков, заказов, статусов, счетов, УПД и накладных.
- Описание ролей партнеров: кто видит каталог, цены, заказы, документы, пользователей и ограничения.
- Текущие выгрузки, API, обмены, регламенты обновления и список ручных операций между системами.
- Логи или примеры инцидентов: неактуальный остаток, неверная цена, чужой документ, дубль SKU, задержка статуса.
- Бизнес-цель канала: доля самостоятельных заказов, снижение ручной нагрузки, скорость обработки, качество карточек или рост повторных заказов.

## Интеграционный слой важнее красивого каталога

B2B-опыт ломается не только на карточке товара. Он ломается, когда партнер видит товар, но не может понять доступность; когда заказ оформился в портале, но не дошел до учета; когда статус поменялся в ERP, но не обновился в личном кабинете; когда API вернул ошибку, которую не может объяснить ни партнер, ни поддержка.

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

Практика DORA и SRE полезна здесь не как ссылка на модные исследования, а как дисциплина: изменения должны быть небольшими, наблюдаемыми и быстро восстанавливаемыми. Для B2B/API это означает версии контрактов, тесты совместимости, логи, алерты, метрики доставки и понятный rollback для интеграций.

## API проектируется как продукт для партнеров

Внешний API нельзя описывать только списком методов. Для партнеров API — это канал работы с поставщиком, поэтому до разработки нужно зафиксировать продуктовые и эксплуатационные правила.

| Область | Что фиксировать до реализации |
| --- | --- |
| Авторизация | OIDC, API-ключи, срок жизни ключей, ротация, отзыв доступа, привязка к контрагенту |
| Ограничения | rate limits, квоты, лимиты по ролям, защита от массового скачивания чужих данных |
| Версионирование | политика изменений, deprecation window, совместимость старых интеграций |
| Идемпотентность | ключи запросов, повторная отправка заказов, защита от дублей |
| Ошибки | коды, человекочитаемые сообщения, correlation ID, инструкции для поддержки |
| Наблюдаемость | журналы, мониторинг, SLA по доставке, алерты, dashboard для разбора инцидентов |
| Документация | OpenAPI, примеры запросов, тестовая среда, changelog, владелец актуальности |

## Какие архитектурные варианты сравнивать

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

Второй — разделенная сервисная архитектура: учет, PIM/MDM, интеграции, B2B-портал и API имеют явные границы. Это более надежный путь для долгого развития канала, но он требует дисциплины владения данными и архитектурных решений.

Третий — расширенный MDM/PIM-контур: больше внимания мастер-данным, качеству карточек, workflow согласования, контенту, медиа и публикации в разные каналы. Он нужен, когда продуктовый контент становится отдельным бизнес-активом, но опасен как первый шаг, если заказный и интеграционный контур еще не описаны.

## Как выбрать вариант после обследования

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

| Критерий | Минимальный MVP | Разделенная архитектура | Расширенный MDM/PIM |
| --- | --- | --- | --- |
| Когда уместно | нужно быстро проверить самостоятельный заказ | нужно строить долгоживущий партнерский канал | карточки, медиа и атрибуты уже тормозят продажи |
| Главная ценность | короткий TTU и быстрый пилот | управляемые границы систем и интеграций | качество продуктовых данных и публикации в каналы |
| Главный риск | временное решение станет постоянным | понадобится больше согласования на старте | первый этап перегрузят мастер-данными |
| Что проверять | 3-5 сценариев и реальные данные | владельцы доменов, события, API, эксплуатация | модель атрибутов, workflow, качество, DAM, каналы |
| Хороший результат | понятен следующий шаг без большой перестройки | каждая система делает свою работу | продуктовый контент перестает быть ручным узким местом |

## Best practices, на которые стоит опираться

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

Второе — domain ownership. Для каждого типа данных должен быть владелец, мастер-система, правило изменения, правило качества и потребители. Это базовая логика data governance и MDM: без нее любые интеграции становятся обменом неоднозначными таблицами.

Третье — API contract first. Контракт API, модель ошибок, авторизация, версия, лимиты, тестовая среда и примеры появляются раньше production-разработки. Postman State of the API 2025 прямо показывает, что коллаборационные проблемы вокруг API остаются массовыми даже при зрелых инструментах; значит, единый источник правды по API нужно проектировать как часть продукта.

Четвертое — integration reliability by design. Очереди, ретраи, дедупликация, идемпотентность, outbox/inbox-паттерны, correlation ID, monitoring и runbook не добавляются после запуска. Они являются частью периметра, потому что без них партнерский канал нельзя сопровождать.

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

## Чек-лист готовности к реализации

- Есть карта B2B-сценариев с приоритетами MVP и измеримыми метриками успеха.
- Описан AS-IS контур: системы, интеграции, владельцы, ручные операции, ограничения и текущие инциденты.
- Для карточек, цен, остатков, заказов, статусов, документов и партнеров зафиксированы мастер-системы и владельцы.
- Понятно, какие функции остаются в 1С или ERP, какие уходят в PIM/MDM, какие живут в интеграционном слое, а какие видит B2B/API.
- Для API описаны авторизация, роли, ключи, версии, лимиты, ошибки, идемпотентность и журналирование.
- Есть 2-3 архитектурных варианта с критериями выбора, рисками и preliminary-оценкой следующего этапа.
- Заказчик выделил владельцев бизнеса, ИТ, продукта, интеграций, ИБ и учетного контура на время реализации.

## Предпроектное обследование B2B/API и MDM-PIM контура

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

- сценарии партнеров и метрики самостоятельного канала;
- AS-IS систем, интеграций, данных и ограничений;
- матрица владения доменами и требования к PIM/MDM;
- требования к интеграционному сервису, API Gateway и эксплуатации;
- варианты TO-BE и критерии выбора платформы.

## Источники

- [Sana Commerce — B2B Buyer Report 2025](https://www.sana-commerce.com/report/b2b-buyer/)
- [McKinsey — B2B Pulse 2024: how B2B winners keep growing](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/five-fundamental-truths-how-b2b-winners-keep-growing)
- [MuleSoft — 2026 Connectivity Benchmark Report](https://www.mulesoft.com/lp/reports/connectivity-benchmark)
- [Salesforce / MuleSoft — 2025 Connectivity Benchmark Report insights](https://www.salesforce.com/blog/mulesoft-connectivity-benchmark-2025/)
- [Postman — 2025 State of the API Report](https://www.postman.com/state-of-api/2025/)
- [DORA — State of AI-assisted Software Development 2025](https://dora.dev/research/2025/dora-report/)
- [DORA — Platform engineering capability](https://dora.dev/capabilities/platform-engineering/)
- [GS1 US — Data Quality Services, Standards & Solutions](https://www.gs1us.org/services/data-quality)
- [Gartner — Data Quality: Best Practices for Accurate Insights](https://www.gartner.com/en/data-analytics/topics/data-quality)
- [DAMA International — DAMA-DMBOK](https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/)