Ozon, 1С, МойСклад и Telegram: минимальная архитектура MVP

Практическая статья SellerVisor для Ozon-селлеров

Ozon, 1С, МойСклад и Telegram: минимальная архитектура MVP

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

Архитектура должна отвечать на практические вопросы: где лежит себестоимость, где актуальные остатки, кто подтверждает спорные цены, куда приходят алерты, как восстановить историю действий и что происходит при ошибке API. Если эти ответы есть, даже небольшой MVP уже снижает хаос.

Минимальные блоки системы

• Источник товаров и цен: Ozon Seller API или выгрузки, если API пока не подключён.
• Источник себестоимости и остатков: 1С, МойСклад, CRM или Google Таблицы.
• Модуль правил: Min/Max, целевая маржа, промо, исключения, режим подтверждения.
• Журнал событий: цена до и после, причина изменения, пользователь или автоматическое правило.
• Telegram-бот: алерты, подтверждения, сводки и ручной стоп.
• Отчёт собственника: проблемные SKU, эффект, ошибки, очередь решений.

Почему Telegram часто лучше нового кабинета

Новый кабинет полезен, когда нужно много сложной аналитики. Но для MVP важнее скорость реакции. Если менеджер и собственник уже работают в Telegram, алерт там увидят быстрее, чем уведомление в отдельном интерфейсе. Бот может прислать карточку события: SKU, текущая цена, новая цена, маржа после изменения, причина сигнала и кнопки "подтвердить", "запретить", "отложить".

Это не отменяет отчёты. Просто отчёт нужен для анализа, а Telegram нужен для действия. Хорошая архитектура разделяет эти задачи.

Как связать Ozon с 1С или МойСклад

Главная сложность обычно не в API, а в сопоставлении справочников. В Ozon один идентификатор, в учётной системе другой, в таблицах менеджера третий. До автоматизации нужно привести SKU, артикулы и названия к понятной связке. Иначе система будет считать маржу не по тому товару или не найдёт себестоимость.

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

Какие режимы нужны в MVP

Первый режим: только наблюдение. Система ничего не меняет, а считает сигналы и показывает, что бы она сделала. Это помогает проверить формулы и доверие команды. Второй режим: полуавтоматический. Система предлагает действие, но спорные изменения требуют подтверждения. Третий режим: автоматический для SKU с низким риском и хорошо проверенными правилами.

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

Что логировать

Лог должен отвечать на вопрос: почему система приняла решение. Минимум: время, SKU, источник данных, старое значение, новое значение, правило, пользователь, статус отправки в Ozon, результат и ошибка, если она была. Без лога невозможно разбирать спорные ситуации и защищать автоматизацию перед командой.

Журнал также нужен для оценки ROI. Если система предотвратила опасную акцию, остановила цену ниже MinPrice или сэкономила часы сверок, это должно быть видно не только в ощущениях, но и в фактах.

Безопасность доступов

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

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

Этапы запуска MVP

Первый этап: карта данных. Фиксируем, откуда берутся товары, цены, себестоимость, остатки и расходы. Второй этап: таблица соответствий SKU между Ozon и учётной системой. Третий этап: правила маржи и исключения. Четвёртый этап: режим наблюдения и журнал. Пятый этап: Telegram-алерты. Только после этого стоит включать автоматические действия.

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

Пример первого контура

У селлера 480 SKU на Ozon, себестоимость в МойСклад, часть расчётов в Google Таблице, решения менеджеры обсуждают в Telegram. Первый контур может контролировать только 80 SKU. Раз в день система забирает остатки и цены, пересчитывает MinPrice, сверяет участие в акциях и отправляет список исключений. Красные события требуют решения, жёлтые попадают в ежедневную сводку, зелёные только логируются.

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

Что подготовить к архитектурному аудиту

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

После такой карты можно выбрать минимальный контур. Иногда это Ozon плюс Google Таблица и Telegram. Иногда сразу нужна связка с 1С или МойСклад. Решение зависит не от "правильной" архитектуры в вакууме, а от того, где сейчас лежат данные, насколько они актуальны и какую ошибку опаснее всего допустить.

Как понять, что MVP готов к расширению

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

Хороший следующий шаг после первого контура: добавить отчёт собственника, расширить группу SKU, подключить второй источник данных или автоматизировать безопасные действия. Плохой следующий шаг: строить большой интерфейс, пока команда ещё не научилась пользоваться сигналами.

Мини-чек-лист архитектуры

• Определите главный источник себестоимости и ответственного за его актуальность.
• Проверьте связку артикулов между Ozon и учётной системой.
• Разделите режимы: наблюдение, подтверждение, автоматическое действие.
• Настройте ручной стоп до первого автоматического изменения цены.
• Сохраняйте журнал решений, ошибок API и отправленных уведомлений.

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

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

FAQ

Можно ли начать без 1С?

Да, если себестоимость и остатки можно временно вести в Google Таблице или другой выгрузке. Но источник должен быть ответственным и регулярно обновляться.

Нужен ли отдельный интерфейс?

Не всегда. Для MVP часто хватает Telegram-алертов, журнала и простого отчёта. Интерфейс стоит делать, когда есть повторяющиеся задачи, которые неудобно решать в чате.

Что делать при ошибке API?

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

Как выбрать первый сценарий?

Берите не самый красивый, а самый измеримый: контроль MinPrice, автоакции, остатки или конкуренты. Там быстрее видно, окупается ли MVP.