Модуль в учётке или отдельный сервис: 6 порогов, на которых ломается интеграция

Почти любой товарный бизнес приходит на маркетплейсы одинаково: учёт уже ведётся в 1С или МойСкладе, к нему докупается модуль интеграции, и этого хватает на первые год-полтора. Ломается связка не от плохого качества модуля, а от роста: каждая новая площадка, каждая тысяча артикулов и каждая акция добавляют нагрузку туда, где её не проектировали.

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

Порог первый: площадок стало больше трёх

Модули внутри учётных систем традиционно вылизаны под две-три крупные площадки: Ozon, Wildberries, Яндекс Маркет. Это покрывает основную выручку рынка, и до поры этого достаточно. Как только добавляются Мегамаркет, AliExpress или отраслевые площадки, картина меняется: у каждой свой официальный API, свой цикл обновлений и свои правила по статусам заказов.

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

Порог второй: каталог вырос до тысяч артикулов

Массовое обновление цен и остатков устроено как очередь задач. Пока позиций несколько сотен, очередь проходит незаметно. На тысячах артикулов, да ещё с регулярными пересчётами под акции, она начинает конкурировать за ресурсы с тем, ради чего учётная система вообще существует: проводками, складскими документами, закрытием периода.

1. обновление цен по всему каталогу перестаёт укладываться в ночное окно
2. бухгалтерия жалуется на тормоза в дни распродаж, а не в дни отчётности
3. часть выгрузок приходится запускать вручную и партиями

Порог третий: остатки нужны не по расписанию, а почти сразу

Синхронизация раз в полчаса не проблема в обычный вторник и становится проблемой в 11.11. Один и тот же товар продаётся с одного физического склада на нескольких витринах, и чем длиннее пауза между продажей и обновлением остатка, тем выше шанс продать то, чего уже нет. Цена ошибки измеряется не только отменой: это рейтинг продавца, падение карточки в выдаче и иногда ограничения на уровне кабинета.

Важная деталь: заявленная частота обновления у модулей упирается не в сам модуль, а в лимиты API и нагрузку хост-системы. Сервисы вроде MPsklad честно пишут про интервал от одной до пяти минут при определённых условиях, и это добросовестная формулировка, а не слабость продукта. Просто это потолок конструкции, в которой интеграция живёт внутри чужого учётного контура.

Порог четвёртый: кабинетов и юрлиц стало несколько

Мультиаккаунтность появляется у бизнеса не от хорошей жизни и не от жадности: разные бренды, разные налоговые режимы, разные товарные группы, иногда разные партнёры. Модуль внутри учётной системы обычно рассчитан на связку «одна база - один кабинет на площадку». Дальше начинаются параллельные настройки, которые кто-то должен держать в голове и синхронизировать руками.

Порог пятый: схемы работы перестали быть одинаковыми

FBO, FBS и DBS отличаются не названием, а тем, кто хранит, кто собирает и кто отвечает за сроки. У каждой площадки своя трактовка статусов заказа и свои правила возвратов. Пока вся торговля идёт по одной схеме, разница незаметна. Когда часть ассортимента лежит на складе площадки, часть отгружается со своего, а часть везётся курьером продавца, универсальная логика модуля начинает упрощать то, что упрощать нельзя.

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

Порог шестой: учётная система тормозит в пики продаж

Это единственный признак, который касается не скорости обновления карточек, а устойчивости бизнеса целиком. Если во время акции медленно работает не только выгрузка остатков, но и выписка документов, значит интеграция и учёт делят один ресурс. В такой конфигурации любой всплеск спроса на площадке автоматически становится проблемой бухгалтерии и склада.

Чем встроенный модуль честно лучше

Сдвиг от модуля к отдельному сервису не универсальное правило, и было бы нечестно это замалчивать. У встроенных решений есть сильные стороны, которые отдельный сервис не повторит.

1. всё в одном окне: менеджеру не нужно переключаться между системами
2. одна точка ответственности при разборе расхождений в остатках
3. ниже стоимость владения на старте, нет второй подписки
4. быстрый запуск: решения класса MPsklad ставятся из магазина приложений учётной системы за вечер
5. для связки с 1С модули дают глубину по налогам и складу, которой у нишевых сервисов обычно нет

Что я советую сделать

Проверка занимает один рабочий день и не требует ничего менять.

1. Посчитать текущие значения по шести порогам: число площадок, число артикулов с регулярным обновлением, фактический интервал синхронизации остатков, число кабинетов и юрлиц, число используемых схем работы, время отклика учётной системы в пиковый день.
2. Сравнить фактический интервал обновления остатков с заявленным в документации вашего решения: расхождение показывает, упираетесь вы в продукт или в лимиты API.
3. Снять за месяц число отмен из-за отсутствия товара и перевести его в деньги и в потерянные позиции карточек.
4. Если порогов совпало три и больше, считать не замену, а параллельный контур: учёт остаётся на месте, товарные операции выносятся наружу.

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

Для индустрии здесь вывод шире, чем выбор подрядчика. Маркетплейсы перестают быть каналом сбыта и становятся инфраструктурным слоем, в котором скорость изменения цены и контента определяет маркетинговые возможности бренда. Вопрос к коллегам из агентств и брендов: вы знаете, за сколько минут ваш клиент физически способен поменять цену и описание на всех своих витринах?