Смета перезапуска магазина: интеграции и что каждая стоит в днях

Смету на перезапуск магазина обсуждают с конца. Заказчик считает экраны и концепции дизайна, а внизу документа стоит строка «интеграции» и цифра, которую никто не раскладывал. Через полгода выясняется, что именно эта строка и была проектом: дизайн сдали в срок, а магазин не запускается — остатки приезжают раз в сутки, резерва нет, оплаты по счёту для юрлиц не заложили.

Мы это делали: перезапуск GrandeBoutique разобран ниже. Сначала — как эта часть сметы устроена изнутри, сколько занимает каждый поток в рабочих днях и как прочитать чужую смету.

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

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

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

Рядом стоит поток, которого в сметах почти не бывает, — медиа. Фотографии редко живут в учётной системе: папка на диске, облако, иногда архив студии, а связь «файл — товар» держится на имени файла. Пока имена предсказуемы, это несколько дней; когда в папке десять ракурсов без порядка, сначала собирается карта соответствия, и собирают её люди, а не код. Строки нет в смете — она появится в самый неудобный момент: каталог готов, фильтры работают, а показывать нечего.

Цены и остатки кажутся простыми, пока их по одной. Одна розничная цена — это дни; розница плюс акция плюс цена постоянного клиента плюс цена магазина — матрица, и главная работа в ней не передача чисел, а согласование правил приоритета. То же с остатками: вопрос не «передать количество», а «по каким складам», потому что остаток в бутике и остаток на складе интернет-магазина — разные сущности.

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

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

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

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

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

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

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

С доставкой та же арифметика. Одна служба — это расчёт стоимости, справочник пунктов выдачи, передача заказа и отслеживание; вторая добавляет почти столько же, потому что протоколы не совпадают. Поэтому вопрос в смете звучит не «есть ли доставка», а «сколько служб заложено поимённо». И отдельно самовывоз из бутиков: самый простой с виду способ доставки тянет за собой остатки в разрезе магазинов, то есть переделку дорогого потока.

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

Первая — разметка аналитики: события корзины и покупки, цели, связка с рекламными кабинетами. Работы немного, но без неё перезапуск нечем оценить: «до» никто не размечал, «после» размечено через месяц, и сравнить два состояния магазина уже нельзя.

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

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

И пятая группа — отзывы, лояльность, внешний поисковый движок: три работы из категории «ну это же быстро». Быстро — но их три.

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

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

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

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

И последнее — объём и окно обмена. Выгружать десятки тысяч позиций целиком и передавать только изменения — разные инженерные задачи. На каталоге GrandeBoutique, где свыше 35 000 позиций и по каждой почти ежедневно меняются цена и остаток, вопрос «как часто и какими порциями» определяет архитектуру обмена, а не настройку расписания.

Сеть мультибрендовых бутиков из Уфы. Сайт прожил больше десяти лет на известной отечественной платформе и оставался необязательным дополнением к рознице. В перезапуске — более 35 000 товарных позиций и более 30 интеграций. Тридцать с лишним обменов и есть ответ, почему «интеграции» нельзя писать одной строкой: за ними список работ длиной в страницу.

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

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

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

Что запуск сам по себе поднимет продажи. У SHI TRENDY, московского концепт-стора, который больше десяти лет продавал через соцсети, запуск собственного магазина не дал мгновенного роста. Он дал другое: автоматизацию, разгрузку команды и независимость от чужих алгоритмов, а с ними собственную аналитику — бренд начал видеть динамику продаж и ожидаемые объёмы практически в реальном времени. Руководитель описывает результат теми же словами: автоматизация продаж, экономия времени персонала, удобство для клиентов.

Что интеграция делается один раз. Учётная система обновляется, службы доставки меняют протоколы, маркетплейсы — требования к карточке. Обмен не объект, а процесс, и в смете это означает строку на наблюдение после запуска и понятный ответ на вопрос, кто чинит расхождения на третий месяц.

И главное: что всё перечисленное нужно вам. Один склад, одна цена, одна служба доставки — и половина статьи к вам не относится. Лишний поток обмена не задел на будущее, а код, который надо поддерживать наравне с нужным.

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

А если у вас уже есть предложение на перезапуск — пришлите из него раздел про интеграции. Мы разберём его по тем же семи вопросам и скажем, какие потоки не перечислены и какие сценарии отказа пропущены, чтобы вы спросили об этом до подписания.