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