Коротко: за один проход отберите до 50 пар хозяин+дополнение, запишите связь в матрице, поставьте совместный min и стоп автозаказа на 2 SKU, прогоните пилот на 1 категории и 1 цикле поставки, затем замерьте долю продаж хозяина при нуле attachment.
Категорийному менеджеру и закупщику розницы нужно за один проход выбрать сопутствующие товары как пару SKU из чека, внести связь хозяин→дополнение в ассортиментную матрицу и включить стоп: не формировать заявку на хозяина, пока attachment ниже порога. Иначе комплект разъезжается: кофе на полке есть, капсулы в нуле, и покупатель уходит с половиной набора. Система управления запасами БрайтБорд считает остатки и автозаказ по выгрузке из учётки, но правило пары должно жить в матрице отдельно от двух независимых min/max.
Боль знакома по бакалее и алкоголю: пиво продаётся, стаканчики не пополняются; макароны есть, соус к ним исчез. Задача закупки не «подсказать кассиру допродажу», а держать оба живых кода одним правилом пополнения. Ниже по шагам: критерий пары, поле связи, совместный min, действия при нуле дополнения и проверка после цикла.
Что такое сопутствующие товары. Сопутствующие товары - это дополняющий SKU к товару-хозяину в чеке (complement / basket attachment): расходник, аксессуар или второй элемент комплекта, который закупщик держит парой с хозяином в матрице и автозаказе. Это не подарочная подборка, не товарозаменитель при отсутствии на полке и не способ «поставить рядом» без связи в учёте остатков.
По какому критерию выбрать сопутствующий SKU к хозяину?
Пара годится, если второй код закрывает использование хозяина в том же чеке, а не ту же потребность другим брендом. Простой тест «дыра»: при нуле дополнения хозяин всё равно уходит с полки, и покупатель не может завершить сценарий (капсулы к кофе, соус к пасте, одноразовые стаканчики к разливному пиву). Субститут отвечает на другой вопрос: какой SKU заменить хозяина при OOS, а не что докупить вместе с ним.
Не путайте attachment с сегментом маржи вокруг KVI и с never-out одного кода из ядра ассортимента. Там держат наличие маяка или оборачиваемость вокруг него, но нет именованной связи «этот конкретный SKU обязан жить рядом с этим хозяином в заявке поставщику». Анализ корзины помогает найти кандидатов на связь, однако сам по себе отчёт по совместным покупкам не заменяет поле связи и стоп в автозаказе.
Для зимнего сезона уместны те же правила: термокружка к пакетированному какао или сироп к кофейному хозяину - attachment, если без второго кода первый продаётся «в пустоту». Списки «что подарить» и категория «сопутствующие» на сайте сюда не относятся: закупщику нужны живые коды в матрице, а не блок related на карточке.
| Хозяин | Дополнение | Почему attachment | Почему не субститут | Типичная ошибка отбора |
|---|---|---|---|---|
| Макароны группа A | Томатный соус той же полки | Соус дополняет блюдо в одном чеке | Другая паста закрывает ту же потребность «углеводы» | В пару кладут второй бренд макарон |
| Разливное пиво | Одноразовые стаканчики | Без стаканчиков пиво продаётся неполным комплектом | Другое пиво заменяет сорт, а не дополняет | Ставят рядом на полке без связи в матрице |
| Капсульная кофемашина | Капсулы совместимого формата | Расходник к устройству | Другая кофемашина - замена хозяина | Путают с Back Basket вокруг KVI-кофе |
| Зимний какао пакет | Термокружка или сироп | Второй элемент зимнего сценария чека | Другой напиток - аналог спроса | Берут любой товар из «высокой маржи» без теста дыры |
1. Зафиксируйте комплект в ассортиментной матрице
Связь пишут у хозяина: SKU дополнения, роль attachment, направление хозяин→дополнение, статус «оба кода активны в матрице». Автозаказ должен читать это поле и не крутить два артикула как независимые строки с разными точками заказа без согласования. Если связь живёт только в Excel закупщика, через месяц пара расползается при смене ответственного или при выводе одного кода из ассортимента.
Минимальный набор атрибутов: код хозяина, код дополнения, тип связи (attachment), дата утверждения пары, ответственный категорийный менеджер. При выводе дополнения из матрицы снимайте стоп с хозяина или переводите пару в архив, иначе система будет блокировать заказ по «мёртвому» SKU. Подробнее про матрицу и складской контур - в разделе про управление ассортиментом и складом.
Ошибка: считать, что выкладку по планограмме для категорийного менеджера можно подменить полем связи. Соседство на схеме помогает кросс-продажам, но не синхронизирует остатки и заявки поставщику.
- Снимите 20-50 хозяев категории, у которых в чеке стабильно есть второй SKU-расходник или аксессуар, а не аналог того же спроса.
- Для каждой пары запишите тест «дыра»: если дополнение в нуле, хозяин продаётся без половины комплекта.
- Внесите в матрицу поле связи хозяин→дополнение (SKU, роль attachment, оба кода живы).
- Поставьте совместный min на пару и стоп входа автозаказа: не заказывать хозяина, пока attachment ниже порога.
- Опишите действие при нуле дополнения: дозаказ или перемещение только attachment, потребность хозяина в этот цикл = 0.
- Запустите пилот на 1 категории и 1 цикле поставки, не на всём каталоге.
- Сверьте после цикла: продажи хозяина при OOS attachment, срабатывание стопа, оба конца выше совместного min.
БрайтБорд как IMS подтягивает продажи и остатки из учётной системы клиента; пара должна быть заведена в матрице явно, иначе два кода продолжают жить разными правилами min/max.
Настройте совместный min и стоп не заказывать хозяина без дополнения
На пару ставят одно правило входа в автоматизацию и управление закупками: совместный min (дозаказывать оба конца, когда суммарный запас пары падает ниже целевого уровня) и стоп «не формировать заказ хозяина, если остаток attachment = 0 или ниже минимального порога продажи». Это не второй независимый цикл автозаказа по одному коду и не сдвиг точки заказа всей мерч-группы из-за планограммы.
Если у attachment есть свой субститут в матрице (отдельная задача замены при OOS), стоп хозяина без дополнения не снимают автоматически: либо явно разрешают продажу хозяина с заменой расходника, либо держат стоп до появления живого кода дополнения. Иначе закупщик получит противоречие: система требует оба SKU, а полка уже продаёт хозяина через замену.
| Правило | Что видит система | Что происходит с заявкой | Типичный сбой |
|---|---|---|---|
| Совместный min на пару | Остатки хозяина и attachment ниже целевого уровня пары | В одном цикле планируется пополнение обоих кодов | Считают min только по хозяину, дополнение «догоняют вручную» |
| Стоп хозяина без attachment | Attachment = 0 или ниже порога | Заявка на хозяина не формируется, даже если у хозяина низкий остаток | Стоп не заведён, хозяин уезжает к поставщику в дыру |
| Независимый min/max двух кодов | Два отдельных SKU без поля связи | Заявки расходятся по разным датам | Комплект разъезжается каждый 2-3 цикл |
| Только полка «рядом» | Выкладка без связи в IMS | Автозаказ не знает о паре | Визуально рядом, в остатках разрыв |
Что делать, если хозяин в наличии, а дополнение в нуле?
Рабочий порядок для закупщика: зафиксировать стоп автозаказа хозяина (или обнулить расчётную потребность хозяина на текущий цикл), срочно дозаказать или переместить только attachment между точками, не маскировать проблему расширением фейсинга хозяина. Пока дополнение в нуле, каждая продажа хозяина увеличивает разрыв комплекта и жалобы покупателей.
Перемещение со склада сети часто быстрее, чем ждать поставщика по хозяину, который и так в избытке. Категорийному менеджеру стоит завести короткий регламент: кто инициирует перемещение, за сколько часов эскалирует на директора по закупкам, когда пара снимается с промо. Регламент инвентаризации и годовой пересчёт здесь не заменяют оперативный дозаказ расходника.
Если хозяин участвует в промо, а attachment нет, лучше снять хозяина с акции до восстановления пары, чем наращивать спрос в дыру. Иначе после акции останется двойной долг: и пустые полки дополнения, и излишек хозяина.
Сравните пару в автозаказе с заменой, полкой и Back Basket
Одна complement-пара в IMS решает другую задачу, чем соседние инструменты ассортимента. Товарозаменитель закрывает отсутствие хозяина другим кодом той же потребности. Планограмма задаёт соседство на полке. KVI и Back Basket выделяют маржу вокруг маяка без жёсткой связи двух SKU в заявке. Ядро держит never-out одного кода. Цикл автозаказа по одному артикулу не знает про стоп «хозяин без дополнения». Группа C в ABC может подсказать, что вывод стаканчиков бьёт пиво как хозяина, но это предупреждение, а не совместный min.
Цепочка внедрения: критерий пары из чека → поле связи в матрице → совместный min → стоп хозяина без дополнения → пилот на 1 категории → замер после 1-2 циклов поставки.
| Объект | Вопрос читателя | Что делать с SKU | Чего эта страница не закрывает |
|---|---|---|---|
| Complement-пара | Как не продавать хозяина без расходника? | Связь в матрице, совместный min, стоп заявки | Не учит продавать «средний чек» скриптами |
| Товарозаменитель | Чем заменить хозяина при OOS? | Матрица аналогов, правило замены | Не задаёт пару attachment |
| Планограмма | Где поставить рядом? | Схема выкладки, фейсинг | Не синхронизирует автозаказ двух кодов |
| KVI Back Basket | Что крутить вокруг маяка? | Сегмент маржи вокруг KVI | Не именованная пара в заявке |
| Ядро ассортимента | Что всегда в наличии? | Never-out одного SKU | Не стоп хозяина без конкретного attachment |
| ABC, группа C | Что выводить первым? | Классификация по обороту | Не заменяет совместный min пары |
| Автозаказ одного кода | Когда заказать один SKU? | Min/max, прогноз по одному артикулу | Не читает поле связи пары |
Краткий ориентир по ABC: при выводе кода из группы C проверьте, не является ли он дополнением к хозяину A; иначе потеряете не «мелочь», а половину комплекта. Разбор классификации - в материале как сделать ABC-анализ для управления запасами.
Отделите правило пары от блока related на сайте и 1С jointly-sold
Блок «с этим покупают» на карточке интернет-магазина и регистр «номенклатура, продаваемая совместно» в 1С закрывают подсказку менеджеру или покупателю в момент сделки. Они не останавливают автозаказ хозяина, когда склад дополнения пуст. IMS смотрит на остатки, продажи и правила пополнения двух живых SKU; related и jointly-sold без выгрузки в матрицу не создают стоп заявки.
Импорт связей из Excel в учётку полезен как черновик, но закупщику нужна версия в ассортиментной матрице, которую читает расчёт потребности. Иначе кассир видит подсказку, а через 3 дня хозяин снова уезжает к поставщику без капсул. BrightBoard не заменяет модуль related и не является расширением конфигурации 1С: платформа помогает считать запасы и автозаказ по согласованным правилам после выгрузки данных.
Проверьте после цикла: хозяин не продаётся в дыру без attachment
После 1-2 циклов поставки сверьте четыре сигнала. Доля продаж хозяина в дни, когда attachment был в нуле, должна снижаться, если стоп и промо-ограничения работают. Число заявок, которые стоп отсёк до отправки поставщику, показывает, что правило не «бумажное». Доля пар, где оба конца выше совместного min, отражает качество совместного планирования. Счётчик хозяев на полке без живого дополнения в матрице ловит разрывы до жалоб покупателей.
Ориентир успешного пилота: если стоп и ограничения промо работают, доля продаж хозяина в дни с нулевым attachment ниже, чем на базовой линии до внедрения. Сравнивайте только свои замеры до и после, это не обещание платформы.
Зафиксируйте базовую линию до пилота: 7-14 дней продаж и остатков по выбранным парам. Без базы непонятно, сработал стоп или сезон сам притушил спрос. Если стоп срабатывает, а доля «дыр» не падает, проверьте обходы: ручные заявки вне IMS, промо без блокировки хозяина, неверный порог attachment.
Какие цифры зафиксировать в отчёте закупок
Соберите короткий дашборд по пилотной категории: процент пар с заполненным полем связи, процент чеков с хозяином при нуле дополнения, количество отменённых заявок по стопу, процент пар над совместным min, число активных хозяев без живого attachment в матрице. Сравните с базой до внедрения правила, а не с чужими кейсами из маркетинговых статей.
Когда метрики стабилизируются, масштабируйте список пар партиями по 20-30 SKU, а не всей сетью сразу. Так проще отловить ошибочный отбор субститутов вместо attachment и не заморозить полкатегории ложными стопами.
БрайтБорд - IMS «помощник закупок в ритейле»: автозаказ, распределение остатков, дашборд с 20+ метриками и ассортиментная матрица по данным из учётной системы клиента. Подключение начинается с онлайн-встречи и выгрузки; чтобы пара не разъезжалась, заведите связь и стоп в матрице, а не только на витрине сайта.
Частые вопросы
Можно ли в пару поставить два сока разных брендов?
Нет, это субституты одной потребности. В матрице настраивают замену при OOS, а не совместный min двух соков. Attachment - расходник или второй элемент комплекта к одному хозяину.
Достаточно ли выставить товары рядом по планограмме?
Недостаточно. Соседство на полке не связывает остатки в автозаказе. Нужно поле связи хозяин→дополнение и стоп заявки, иначе хозяин уедет к поставщику без пополнения расходника.
Чем отличается работа с сопутствующими товарами от настройки автозаказа одного SKU?
Автозаказ одного кода считает min/max и прогноз по одной строке. Пара требует совместного min и запрета заказа хозяина при нуле дополнения. Без этого два независимых цикла разъедут комплект за 2-3 поставки.
Нужно ли дублировать связь в блоке «с этим покупают» на сайте?
Блок на сайте помогает покупателю, но не управляет запасами. Для закупки дублируйте связь в матрице IMS и проверьте, что она попадает в расчёт потребности после выгрузки из учётки.
Если после пилота остаются вопросы по матрице и автозаказу пар, можно связаться с БрайтБорд и разобрать выгрузку по вашей категории.
