С развитием бизнеса на маркетплейсах практически каждый продавец приходит к необходимости усиливать ИТ-часть и быстро понимает: универсального решения «из коробки» не существует. Но главный вызов заключается не в автоматизации отдельных процессов, а в сохранении управляемости и контроля над бизнесом. Обсудим, как выстраивать ИТ-инфраструктуру селлера на разных стадиях развития.
Чужая система координат
Иногда кажется, что рынок сервисов для продавцов на маркетплейсах растет быстрее самих маркетплейсов. Аналитические платформы, конструкторы, системы учета и автоматизации обещают предпринимателям управляемость «из коробки»: подключил сервис — и бизнес прозрачен.
На старте готовые сервисы действительно работают. Они позволяют быстро выйти в продажи без собственной ИТ-команды и закрывают базовые задачи — учет заказов, аналитику, склад, рекламу.
Но вместе с удобством предприниматель получает зависимость. Инфраструктура оказывается арендованной: логика расчетов, доступ к данным и правила интеграций определяются не бизнесом, а поставщиком сервиса. Пока объемы небольшие, это почти незаметно. Но с ростом начинают проявляться ограничения:
- невозможно гибко считать юнит-экономику;
- данные из разных источников не сходятся;
- любое отклонение от стандартного сценария требует доработок или обходных решений;
- стоимость сервисов и интеграций растет быстрее оборота.
В какой-то момент инструмент, который помог запуститься, начинает ограничивать развитие.
Главная проблема — не отсутствие, а избыток
На практике минимальный технологический набор для профессионального селлера включает несколько ключевых компонентов:
- система управления складом (WMS), обеспечивающая точный учет и контроль остатков;
- система управления заказами (OMS), которая позволяет отслеживать статус каждой покупки и планировать отгрузки;
- интеграции через API между всеми системами для синхронизации данных;
- ERP для ведения бухгалтерского и финансового учета;
- CRM для работы с клиентами, маркетинга и обработки обращений.
При этом, по оценкам индустриальных исследований,
Каждый инструмент решает свою локальную задачу и при этом создает отдельный поток данных. В какой-то момент компания понимает, что проблема не в функциональности отдельных сервисов, а в отсутствии единой картины бизнеса.
Продажи, расходы, трафик и финансы существуют раздельно. Решения принимаются на основе фрагментов информации, а не целостной экономики.
По оценкам Gartner, плохое качество данных обходится компаниям в среднем в $12,9 млн. ежегодно. Для селлеров это означает искажение юнит-экономики: по оценкам отрасли, при реальной марже
Поэтому главным ИТ-проектом растущего селлера становится не внедрение новой системы, а интеграция всех существующих. Компании начинают строить собственное «ядро» — центральную базу данных, куда стекается вся операционная информация. Именно способность связать данные между собой превращается в ключевой фактор управляемости.
Автоматизация как источник новых рисков
Дополнительное ограничение — вопрос доступа и безопасности. Для того, чтобы сторонний сервис начал считать экономику бизнеса, ему необходимо предоставить доступ к личному кабинету маркетплейса — чаще всего через API или другие интеграции. Насколько это безопасно? Даже если это известная платформа, никто не может гарантировать, как именно будут использоваться данные и какие сценарии возможны в случае инцидента.
Представьте наихудший вариант: сервис допустил ошибку или злоупотребил доступом, и бизнес пострадал. Судебные разбирательства здесь мало помогают — основной ущерб уже нанесен. Особенно это актуально для России, где механизмы компенсаций и ответственности сервисов находятся пока на стадии формирования.
Быстрое внедрение автоматизации и ИИ опережает развитие систем контроля, формируя так называемый накопленный долг по безопасности. По данным IBM, 97% организаций, столкнувшихся с инцидентами, связанными с ИИ, не имели должного контроля доступа, а 60% компаний не имеют формализованных политик управления ИИ.
Облачные решения усиливают это противоречие. Они создают ощущение надежности, однако зависимость от одного провайдера означает, что технический инцидент может парализовать бизнес мгновенно. Пример: год назад перебои в международной интернет-инфраструктуре, связанные с событиями в Иране, затронули часть зарубежных облачных сервисов, которыми пользовался ряд компаний. Это показало, что в ряде случаев даже двух серверов в разных локациях недостаточно — иногда необходим третий балансировщик, чтобы ежедневно зеркалировать данные и иметь возможность мгновенно восстановить систему из резервной копии.
Аналогичные ситуации уже происходили с крупными провайдерами: уход Microsoft из России стал шоком для компаний, полностью завязанных на облачные решения — сотрудники потеряли доступ к корпоративной почте, контактам и мессенджерам, на которые полагались для ежедневной работы.
Поэтому зрелые игроки постепенно переходят к компромиссной модели: внешние сервисы используются как интерфейсы, но ключевые данные хранятся внутри компании — с резервными копиями, распределенным хранением и контролем доступа.
Почему с ростом бизнес неизбежно приходит к собственной разработке
С увеличением масштаба многие предприниматели проходят одинаковый путь: со временем складывается ситуация, когда поддержка набора внешних сервисов становится дороже и сложнее, чем создание собственной системы.
Прежде чем начать разработку собственной WMS-системы, тестируются готовые решения. Все они имеют определенную логику, но не закрывают потребности на 100%. С планируемыми темпами роста становится очевидно, что любое из имеющихся решений требовало бы бесконечных доработок, каждая из которых стоила бы дорого и не гарантировала нужного результата. Поэтому компании идут по пути создания собственного решения, которое дает полную свободу действий и позволяет выстроить систему под реальные бизнес-процессы.
Есть несколько типичных сигналов:
- данные из разных систем регулярно расходятся;
- отчеты собираются вручную или в Excel;
- невозможно посчитать маржинальность по SKU в реальном времени;
- рост оборота не приводит к росту прибыли;
- добавление нового канала или товара резко усложняет процессы.
Это не всегда означает, что компании необходимо создавать всю ИТ-систему с нуля. Чаще это постепенное формирование собственного data-слоя и логики обработки данных поверх существующих инструментов.
Кастомная разработка появляется не из технологических амбиций, а из управленческой необходимости. Бизнесу нужен контроль над логикой расчетов, данными и процессами. Маркетплейс-торговля постепенно превращается из торговой деятельности в инженерную — где конкурентным преимуществом становится не товар, а архитектура управления.
Эволюция ИТ-архитектуры селлера
На практике можно выделить три этапа технологической зрелости:
- Старт. Готовые сервисы «из коробки», минимальные интеграции, быстрый выход в продажи.
- Рост. Комбинация нескольких систем, появление бизнес-аналитики, первые попытки свести данные.
- Зрелость. Собственное ядро данных, централизованная логика расчетов, контроль над архитектурой.
Проблема возникает, когда бизнес остается на первом или втором этапе при растущих оборотах.
Маркетплейс как инструмент, а не бизнес-модель
Главное изменение мышления происходит позже — когда предприниматель перестает воспринимать маркетплейс как сам бизнес. Площадка — это канал продаж и источник трафика, но устойчивость появляется только там, где существует собственная экономика: бренд, операционная эффективность, логистика или производственное преимущество.
Рост оборота без системы учета часто приводит не к прибыли, а к управленческому кризису. Масштабирование требует понимания маржинальности, долговой нагрузки и реальных финансовых потоков — а значит, собственной инфраструктуры данных.
Именно поэтому технологическая архитектура сегодня стала базовой частью торговли. Продавец больше не просто закупает и продает товар — он управляет системой интеграций, финансовых моделей и данных.
Поэтому в новой реальности выигрывает не тот, кто быстрее выходит на маркетплейс, а тот, кто раньше начинает строить собственную управляемую инфраструктуру.
