За последние десять лет в электронной коммерции произошло изменение, которое легко не заметить, если смотреть только на обороты рынка. Уменьшилась сама единица взаимодействия. Раньше онлайн‑покупка была событием: человек собирал корзину, делал относительно крупный заказ и некоторое время ждал следующей покупки. Сегодня заказать одну упаковку кофе, зарядный кабель или продукты на ужин — обычное повседневное действие. Коммерция стала состоять из гораздо большего количества гораздо меньших транзакций.
Особенно хорошо это видно на развитии доставки. Несколько дней ожидания сначала сменились доставкой «завтра», затем — «сегодня», появились часовые интервалы и доставка продуктов за 15–30 минут. Вместо большой закупки раз в неделю возникает множество небольших покупок по мере появления потребности. В eGrocery этот эффект уже хорошо виден: покупатели заказывают чаще и меньшими корзинами.
Фактически весь российский e‑commerce движется в том же направлении. По данным Data Insight, в 2025 году количество онлайн‑заказов выросло на 24% — до 8,3 млрд, тогда как денежный объём рынка увеличился на 19%. Средний чек при этом снизился ещё на 5%, до 1610 рублей. Тренд длится не первый год: снижение среднего чека сопровождается ростом маркетплейсов и частоты покупок. Сам Data Insight описывает происходящее очень точно: «заказываем чаще, но меньше».
Как эти изменения влияют на ИТ‑инфраструктуру
Для ИТ это принципиальное изменение. Системы обрабатывают не рубли оборота. Они обрабатывают заказы, строки заказа, резервы, остатки, статусы, этикетки, отмены, возвраты, уведомления и обращения к API. Продажа на 10 000 рублей одним заказом и десять продаж по 1000 рублей дают одинаковый оборот, но совершенно разную нагрузку на инфраструктуру. На каждый рубль продаж постепенно приходится всё больше отдельных действий, а значит повышаются требования к архитектуре и производительности систем.
Именно поэтому высокая транзакционность перестаёт быть проблемой только банков, маркетплейсов и крупнейших ритейлеров. С ней начинает сталкиваться вполне обычный продавец. И для этого ему необязательно увеличить бизнес в десять раз. Достаточно, чтобы уменьшился размер заказа, выросло число каналов или изменилось место, где происходит исполнение каждого заказа.
Долгое время маркетплейсы позволяли продавцу почти не замечать этой сложности. При модели FBO продавец мог привезти на склад площадки несколько палет товара одной крупной поставкой. Дальше уже инфраструктура маркетплейса превращала эту поставку в тысячи отдельных покупательских заказов: хранила товар, резервировала единицы, собирала коробки, печатала этикетки, сортировала и отправляла их. Тысячи потребительских транзакций для продавца снова агрегировались в относительно небольшое число крупных операций.
Получалось, что высокая транзакционность существовала, но значительная её часть находилась по другую сторону интеграции — внутри инфраструктуры маркетплейса.
Летом 2026 года эта конструкция прошла стресс‑тест другого масштаба. С середины июля атакам беспилотников начали подвергаться логистические объекты Wildberries, а с 22 августа — Ozon. Работа отдельных складов приостанавливалась, товары начали перераспределяться по другим складам, продавцы столкнулись с потерями и задержками. Это, конечно, не означает исчезновения модели FBO. Но события очень наглядно показали риски чрезмерной концентрации товарного запаса и исполнения заказов внутри нескольких крупных логистических узлов.
Реакция части продавцов оказалась показательной. После атак предприниматели рассказывали о переходе на отгрузки со своих складов (FBS), распределении остатков между площадками, собственными складами и сторонними фулфилментами. Речь не идёт о тотальном отказе от FBO, но продавцы стали диверсифицировать риски и подключать новые модели исполнения заказов.
Однако, переход на FBS означает гораздо больше, чем перенос коробок с одного склада на другой. Вместе с товаром продавец забирает к себе и операционную нагрузку. Теперь каждый поступивший заказ нужно получить, зарезервировать под него товар, сформировать задание на сборку, получить этикетку, собрать и упаковать заказ, изменить необходимые статусы, включить его в отгрузку и уложиться в SLA площадки. Один заказ становится цепочкой связанных событий. Часть запросов приходится повторять после ошибок API, события могут приходить одновременно, а отмены и изменения заказа порождают новые операции.
Поэтому тысяча заказов — это десятки тысяч связанных операций и действий системы. И в этот момент уменьшение единицы взаимодействия в e‑commerce превращается в архитектурную задачу внутри компании продавца.
Почему ваша 1С не готова к такому переходу
Особенно хорошо такой переход заметен в компаниях, где учётной и одновременно операционной системой остаются решения 1С:Управление торговлей, 1С:Комплексная автоматизация, 1С:ERP. За годы вокруг такой системы обычно вырастает множество интеграций: документы поступают из внешних систем, заказы загружаются пакетами, остатки выгружаются регламентными заданиями, тяжёлые процедуры запускаются раз в несколько часов.
Такая архитектура прекрасно работала, пока транзакционность обеспечивали сами маркетплейсы. Но если непосредственно в неё направить непрерывный поток заказов и событий от нескольких маркетплейсов, требования к производительности быстро поменяются. Задержка обмена превращается в очередь, очередь порождает повторные запросы, появляются блокировки, расхождения остатков и необходимость разбирать ошибки. А один и тот же физический остаток одновременно пытаются продать Wildberries, Ozon, собственный интернет‑магазин и другие каналы.
Это не означает, что 1С не способна работать под высокой нагрузкой. Способна. Высоконагруженные решения на платформе используют параллельную обработку, фоновые задания, специализированные очереди и отдельные механизмы интеграционного обмена. Но это не возможности «из коробки» — компаниям, которые хотят эффективно работать в этой новой реальности, придется развивать ERP и инфраструктуру в целом.
Но должна ли учётная система быть единственной точкой, которая принимает на себя всю динамику внешнего e‑commerce? API маркетплейсов меняются, отдельные сервисы бывают недоступны, ограничивается число запросов в минуту, возникают повторные запросы и всплески нагрузки. У каждой площадки собственные статусы, SLA и правила обработки заказа. Всё это — довольно шумный и быстро меняющийся внешний мир. А от ERP бизнес обычно хочет противоположного: стабильности и корректности данных о товарах, закупках, себестоимости, остатках, документах и деньгах.
Поэтому бизнесу требуется отдельный операционный слой, который будет дополнять развитие 1С. ERP стоит усиливать как ERP. Но необязательно превращать её одновременно в OMS, интеграционную шину, очередь сообщений, обработчик ошибок API всех маркетплейсов и систему оркестрации каждого внешнего события.
Какая архитектура будет оптимальной
После перехода на FBS у продавца возникает ещё один выбор — уже на физическом уровне. Первый путь — передать исполнение заказов фулфилмент‑оператору. Тогда хранение, сборку и упаковку выполняет внешний партнёр. Второй — развивать собственную складскую инфраструктуру: склад, WMS, персонал и процессы исполнения.
Но ИТ‑задача остаётся в обоих случаях. Если используется фулфилмент, нужно связать между собой маркетплейсы, ФФ, ERP, заказы, остатки и статусы. Если склад собственный — те же потоки нужно связать уже с собственной WMS и внутренними процессами. Физическое исполнение можно отдать партнёру, но управление потоком заказа всё равно должно где‑то происходить.
И здесь инвестиции в собственную инфраструктуру начинают выглядеть интереснее, чем просто аварийная замена FBO. Если компания всё равно научилась хранить товар, принимать заказ, резервировать остаток, собирать его и передавать в доставку, эту возможность можно использовать не только для одного маркетплейса. Одни и те же складские процессы могут обслуживать Wildberries, Ozon, Яндекс Маркет, собственный интернет‑магазин, B2B и другие каналы продаж.
Тогда вложения в склад и автоматизацию дадут не только адаптацию к новой e‑commerce‑реальности c ее большим количество мелких заказов. Они становятся основой собственной многоканальной инфраструктуры продаж. Появляется возможность развивать прямые каналы, быстрее подключать новые площадки и использовать единый товарный запас сразу в нескольких направлениях.
Но для этого должна измениться и ИТ‑архитектура. Вместо множества прямых и разнородных связей «маркетплейс — ERP», “маркетплейс — WMS”, “маркетплейс — фулфилмент” появляется потребность в отдельном операционном контуре, который приведет все процессы к единому знаменателю. Он принимает поток заказов и событий из разных каналов, управляет очередями и повторными запросами, следит за дублями, синхронизирует остатки и статусы и передаёт внутренним системам уже контролируемый и унифицированный поток данных.
В такой архитектуре ERP остаётся стабильным учётным ядром. WMS или фулфилмент отвечают за физическое исполнение. А внешний мир каналов продаж перестаёт напрямую диктовать устройство каждой внутренней системы.
Возможно, это и есть следующая стадия развития e‑commerce продавцов. Раньше главным технологическим вопросом было подключение компании к маркетплейсам. Теперь задача постепенно меняется: нужно научиться управлять продажей независимо от того, где возник заказ и кто именно его исполняет. Продавцу при этом необязательно владеть каждым складом и самостоятельно выполнять каждую операцию. Но ему всё важнее владеть архитектурой управления заказом — от появления покупки в любом канале до её исполнения.
Высокая транзакционность больше не является прерогативой нескольких гигантов. Она становится обычной реальностью e‑commerce. И выигрывать в ней будут не только компании, способные выдержать больше заказов. Выигрывать будут те, чьи технологии позволяют менять каналы продаж, склады и модели исполнения, не перестраивая каждый раз весь бизнес вокруг них.