Рассказываем, как сделать систему, которую легко масштабировать: добавлять новых поставщиков, обновлять данные и управлять ассортиментом без изменений в 1С и пересборки сайта. Даже если каждый поставщик работает по своим правилам.
Привет! Я Серёжа Шилов, фаундер IT-аутсорс компании We Wizards. Моя команда занимается web&mobile разработкой для e-comm, от складов до аналитики.
Мы занимаемся разработкой и развитием интернет-магазинов уже много лет. За это время я пришёл к выводу и подкрепил его на практике — бизнес растёт отдельно от сайта. Проще говоря: появилась компания и завела себе сайт под ассортимент. Прошло N лет, бизнес вырос, а сайт и процессы вокруг него — нет. И тут бизнес начинает коллапсировать.
Чтобы обслуживать продажи с большим количеством SKU, нужен дотошный и супервнимательный менеджер продаж, который ведёт каждого клиента, запоминает условия, работает в закопанной 1С (если повезло) — или в чём похуже.
Вместе с ростом продаж в ритейле приходит кризис цифровизации: объём, скорость и коммуникации держатся на людях и их проектных знаниях. А должны — на системе, которая обслуживает процессы и снижает влияние человеческого фактора.
Кейс нашего клиента — дистрибутора светотехники — как раз из этой серии. Компания выросла, но единой цифровой системы у неё не было.
Показываем, как мы перестроили архитектуру и настроили автоматизацию Спойлер: ни один поставщик в процессе работы не пострадал.
Кто клиент?
Паллор — крупный поставщик осветительного оборудования. Светильники и комплектующие идут напрямую строительным и монтажным компаниям.
500+ проектов по всей стране;
25 000+ моделей светильников;
15 лет на рынке.
Компании было тяжело управлять ассортиментом и логистикой
Есть десятки поставщиков, каждый из них передает информацию о своих товарах по-разному. Один присылал таблицу Excel с десятками колонок, другой — XML-файл, третий — API, четвёртый — PDF-каталог.
При этом у всех свой набор полей: название товара, артикул, цена, наличие, характеристики — и всё это называлось и оформлялось по-разному. Например, один поставщик писал «цена с НДС», другой — просто «цена», третий указывал стоимость за упаковку. У кого-то остатки отображались как «в наличии», у кого-то — как число, у кого-то — как «да/нет». Даже названия одних и тех же товаров могли отличаться.
Чтобы выложить товар на сайт, менеджерам приходилось вручную открывать файлы, проверять корректность данных, переименовывать поля, убирать дубли и подгонять всё под одну таблицу. Только после этого информация попадала в 1С, а потом на сайт. На всё это уходили часы, иногда — дни. Так шли процессы несколько лет.
Хуже всего даже не это, а то, что раньше компания вручную заносила весь товар на старый сайт по каждому поставщику, и на формирование номенклатуры ушли годы. Просто потому, что они не могли придумать способ лучше.
Пришло время всё это автоматизировать
Руками управлять сотней и тысячей SKU и постоянно проверять её актуальность — слишком долго и муторно. Было принято волевое решение — автоматизировать этот процесс. Клиент пришел с четкой формулировкой и стандартным запросом: «…делаем новый сайт, а номенклатуру берем из 1С».
Мы заключили контракт и пошли в аналитику.
В процессе поняли, что нужно идти совсем другим путём
Это, кстати, довольно типичная ситуация: клиент приходит к подрядчику уже с готовым решением, не проработав глубоко саму суть проблемы. И если подрядчик достаточно вовлечён, может выясниться, что само решение выбрано неверно.
В нашем случае клиент решил, что нужно загрузить всю номенклатуру в 1С через интеграции. На первый взгляд — логично: отказались от ручного ввода, подключили каждого поставщика напрямую к 1С, а затем связали её с сайтом. Всё вроде бы работает.
Но есть один нюанс: 1С не предназначена для такого рода задач. Либо это сразу осознанный риск — получить дорогую и сложную в поддержке систему, где каждая интеграция может стать источником боли. Это прямой путь к неуправляемому легаси. Уже сейчас на рынке остро не хватает квалифицированных специалистов по 1С, а тут предполагается построить на этой платформе всю инфраструктуру продаж компании. Это утопия.
В итоге стало ясно: без пересмотра архитектуры и её полноценной пересборки эту проблему не решить.
И тут мы вспомнили другой наш кейс
На одном из проектов случилась похожая история: у клиента было несколько десятков поставщиков и попытка всё интегрировать через 1С. Тогда мы сделали иначе: перенесли работу с данными на сайт, а 1С оставили только для учёта (сугубо бухгалтерия).
Предложили Паллору тот же подход, показали демо, клиент удивился, но доверился.
Сделали 1С исключительно инструментом для обработки заказов и логистики
А всю работу с каталогом, карточками, категориями и остатками — вынесли на сайт.
Это позволило не перегружать 1С, снизить риски ошибок и гибко управлять данными. Все обновления и фильтрации происходят на уровне сайта. Это стало основой новой архитектуры.
Под каждого поставщика сделали свой модуль
Для того, чтобы строить одну большую схему, мы пошли другим путём. Под каждого поставщика сделали отдельный модуль.
Модуль — это маленький блок кода, который умеет:
— забрать данные от конкретного поставщика в конкретном формате;
— привести эти данные к общему виду (например, переименовать поля, убрать дубли, пересчитать цену);
– распределить входящие данные по нужным нам категориям
— передать дальше в витрину сайта.
Один модуль = один поставщик
Мы не пересматриваем всю логику сайта или работу с другими партнёрами, а заходим в конкретный модуль — тот, который отвечает за интеграцию с конкретным поставщиком — и вносим изменения локально.
Если поставщик изменил формат данных: например, переименовал колонки в таблице или добавил новую структуру каталога, это не влияет на всю систему. Модульная архитектура позволяет изолировать такие изменения и быстро на них реагировать.
По такому принципу работают крупные агрегаторы, вроде Level Travel или Aviasales: у них под каждого вендора есть отдельная команда, поддерживающая конкретную интеграцию. У нас используется похожий подход, только значительно проще и легче в поддержке.
Привели категории к единому виду
Один и тот же товар у разных поставщиков может относиться к совершенно разным категориям. Например, у одного прожектор находится в разделе «Промышленное освещение», у другого — в «Уличном», а у третьего — в «Социальном». Хотя по факту это один и тот же светильник.
Чтобы на сайте не было хаоса, мы собрали собственную структуру категорий. Заранее определили, какие группы товаров должны быть в каталоге и какими характеристиками должен обладать товар, чтобы туда попасть. После этого настроили фильтрующий алгоритм для всех входящих данных.
Затем каждый модуль, который забирает данные от поставщика, не просто передаёт их как есть, а сопоставляет категории поставщика с нашей структурой. Это называется маппинг: например, если у поставщика стоит категория «ТЦ и дворы», а у нас это «Уличное освещение», модуль автоматически переведёт название в нужный формат.
В результате клиент видит аккуратную витрину: прожекторы лежат с прожекторами, интерьерные лампы — с интерьерными лампами, даже если изначально это были десятки разных логик от производителей.
Собрали модификации в одну карточку
У многих товаров — не одна позиция, а серия с десятками вариантов. Это, например, светильник, у которого может быть разная мощность, цвет корпуса, тип крепления или угол рассеивания.
У каждого поставщика такие модификации оформлены по-своему: кто-то выносит каждую в отдельную строку, кто-то указывает в дополнительных полях, а кто-то вообще не разделяет.
Мы научили систему распознавать, что эти позиции — вариации одного и того же товара.
Для этого внутри каждого модуля мы анализируем не только название, но и артикул, свойства и характеристики. Если система находит совпадения по ключевым параметрам, она объединяет такие позиции в одну карточку — как серию с модификациями.
На сайте это выглядит как один товар, внутри которого пользователь может выбрать нужную конфигурацию — например, тот же светильник, но с разной мощностью или цветом. Даже если эти варианты пришли от трёх разных поставщиков, они будут отображаться вместе.
Настроили автообновления
Все данные теперь обновляются по расписанию. Для каждого поставщика настроен отдельный cron‑запуск — автоматическая задача, которая срабатывает в определённое время (например, каждую ночь в 03:00). В этот момент соответствующий модуль подключается к источнику (файлу, API или другой системе), забирает актуальные данные, валидирует их и приводит к нужному формату.
Валидация включает несколько проверок:
— есть ли все обязательные поля (название, артикул, цена, наличие);
— соответствует ли структура ожидаемому формату;
— не пришли ли дубли или пустые значения;
— изменились ли критические поля (например, формат категории).
Если структура изменилась — модуль это фиксирует и отправляет уведомление разработчику или в лог мониторинга. Это позволяет оперативно внести нужную правку, не дожидаясь сбоя или жалоб от пользователей.
Мы, кстати, очень полюбили тг-ботов для уведомлений и привязали такие штуки почти по каждому проекту, где это нужно.
Тестили, чтобы не уронить прод
Мы не выкатывали всё сразу. Каждый новый модуль, каждый блок логики сначала запускался в тестовой среде. Затем — на тестовой версии сайта с живыми данными, но без трафика. Только когда всё стабильно работало, подключали в прод.
Плюс у нас были закладки на откат: если что-то идёт не так, система возвращается к предыдущей версии. Такой подход позволил избежать простоев, а главное — не мешать бизнесу работать в процессе внедрения.
А что дальше?
Сейчас в систему уже интегрированы 8 поставщиков. В планах довести это число до 15 и запустить сайт в полноценную работу. В перспективе — масштабирование до 80 поставщиков.
Подключить нейронку для автоматического формирования описаний товаров и категорий. А ещё — для автоматической подстановки изображений в подходящие интерьерные сцены на основе тегов.
FIN!
Спасибо всем, кто дочитал до конца. Оставляю ссылку на наш сайт:
И на тг-канал, там мы делимся буднями, рассказываем о проектах и ищем людей в команду:
https://t.me/+HnhabNdowiI3Zjc6
А если нужны руки для разработки – пишите лично мне в телеграм @olivoin или на почту hello@wewizards.ru