От нескольких часов до нескольких минут: как сеть магазинов перешла на электронные ценники MERTECH ESL

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

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

Покупатель видит только одно: на полке указана одна цена, а на кассе — другая.

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

Именно с этой проблемы начался проект по внедрению системы электронных ценников MERTECH ESL в крупной розничной сети.

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

Почему бумажные ценники перестали справляться

Бумажный ценник кажется простой и надёжной технологией.

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

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

В обычный день один магазин мог получить до 2 500 изменений. Во время смены большой промокампании количество обновляемых позиций достигало 6 000–8 000.

Каждое изменение запускало цепочку ручных действий:

• Выгрузить данные из учётной системы.
• Напечатать новые ценники.
• Рассортировать их по отделам.
• Найти соответствующие товары в торговом зале.
• Снять старые ценники.
• Установить новые.
• Проверить результат.
• Исправить найденные ошибки.

Даже при хорошо организованной работе переоценка зависела от человеческого фактора.

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

В среднем на печать, сортировку, размещение и контроль бумажных ценников одна торговая точка тратила от 10 до 14 совокупных рабочих часов в неделю.

В масштабе сети из 80 магазинов это уже сотни часов ручной работы каждую неделю.

Поэтому заказчик сформулировал задачу не как «заменить бумажные ценники электронными».

Цель была шире:

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

Это уже не просто поставка оборудования.

Это полноценный ИТ-проект, затрагивающий товароучётную систему, инфраструктуру магазинов, процессы ценообразования и работу персонала.

Масштаб проекта

Внедрение решили проводить поэтапно.

Первый пилот охватил шесть магазинов трёх форматов:

• небольшие магазины у дома;
• супермаркеты среднего формата;
• крупные торговые точки с холодильными зонами и расширенным ассортиментом.

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

После завершения пилота первая очередь масштабирования охватила 80 магазинов.

В зависимости от формата в одной торговой точке устанавливалось от 4 500 до 7 000 электронных ценников.

Всего в первой очереди проекта использовалось около 420 000 ESL нескольких типов:

• компактные модели для основного ассортимента;
• увеличенные ценники для отдельных категорий;
• цветные модели для акционных предложений;
• морозостойкие устройства для холодильных и низкотемпературных зон.

Проект должен был ответить на несколько практических вопросов.

Как быстро можно изменить цены сразу во всей сети? Насколько устойчиво будет работать радиосоединение в реальных магазинах? Что произойдёт при временной потере связи с центральной системой? Как сотрудники будут привязывать ценники к товарам? Можно ли централизованно видеть проблемные устройства? И главное — даст ли система заметный бизнес-эффект?

Как устроена система MERTECH ESL

На верхнем уровне находится центральная информационная система торговой сети.

Это может быть ERP, 1С, товароучётная система или набор внутренних сервисов, в которых формируются:

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

Далее данные передаются через API в платформу MERTECH ESL.

Платформа определяет:

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

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

Упрощённо путь данных выглядит так:

учётная система → API → платформа MERTECH ESL → локальный сервер магазина → базовая станция → электронный ценник.

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

Основная логика при этом остаётся в программной платформе.

Зачем магазину локальный сервер

На этапе проектирования возник закономерный вопрос:

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

Причин оказалось несколько.

Магазин должен работать автономно

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

Это не должно останавливать работу магазина.

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

После восстановления связи информация синхронизируется с центральной платформой.

Не весь технический трафик нужно передавать в центр

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

Локальный уровень собирает эти данные и передаёт наверх уже структурированную информацию.

Центральная система и магазин решают разные задачи

Центральная платформа отвечает за управление сетью целиком:

• цены;
• шаблоны;
• массовые обновления;
• аналитику;
• мониторинг;
• контроль исполнения.

Локальный уровень работает непосредственно с оборудованием конкретного магазина.

Так архитектура разделяет централизованное управление и локальную устойчивость.

Первый сложный этап: привязать ценник к товару

Установить электронный ценник на полку недостаточно.

Система должна понимать, какой именно товар он представляет.

Для этого сотрудник магазина сканирует штрихкод товара и идентификатор ESL с помощью терминала сбора данных или мобильного приложения.

После этого в системе появляется связь:

магазин → товар → место размещения → электронный ценник.

На демонстрационном стенде операция занимает несколько секунд.

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

Кроме того, реальные магазины быстро усложняют даже простую модель.

Один товар может одновременно находиться:

• на основной полке;
• в холодильнике;
• в акционной зоне;
• возле кассы;
• на дополнительной выкладке.

Поэтому платформа должна поддерживать связь «один товар — несколько ценников».

Также потребовались сценарии:

• временной отвязки ESL;
• переноса устройства;
• замены повреждённого ценника;
• поиска непривязанных устройств;
• повторной привязки после изменения планограммы;
• массовой проверки корректности связей.

Именно на этом этапе команда поняла, что внедрение зависит не только от программного обеспечения.

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

Торговый зал оказался сложнее плана

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

По расчётам покрытия должно было хватить.

Но реальный торговый зал отличается от архитектурного плана.

После обследования и монтажа в помещениях появились:

• дополнительные холодильные витрины;
• металлические стеллажи;
• рекламные конструкции;
• новые промозоны;
• техническое оборудование;
• участки с особенно высокой плотностью ESL.

В одном из пилотных магазинов основная часть ценников обновлялась стабильно, но несколько зон заметно отставали.

На центральном дашборде было видно, что проблема сосредоточена не по всему магазину, а в конкретных участках:

• в холодильном ряду;
• за массивной металлической конструкцией;
• в дальней части торгового зала;
• в плотной прикассовой зоне.

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

Ситуация стабилизировалась.

Главный вывод этого этапа:

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

Металл, стекло, холодильники, товары и даже временные рекламные конструкции становятся частью радиосреды.

Первая массовая переоценка

Главная проверка системы состоялась во время смены крупной промокампании.

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

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

Теперь процесс запускался централизованно.

Первые ESL начали подтверждать обновления в течение нескольких секунд.

Основная масса ценников получила новые данные за 5–10 минут. Крупная пакетная переоценка в большинстве магазинов завершилась за 20–30 минут.

Но задача системы заключалась не только в том, чтобы отправить команды.

Она должна была:

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

В течение контрольного часа новые данные подтвердили около 99,5% устройств.

До 0,5% ценников временно попали в список исключений. Большая часть из них успешно обновилась после автоматической повторной доставки.

Физического внимания потребовала только небольшая доля устройств — менее 0,1% от общего количества.

Причины были разными:

• ценник переместили;
• устройство оказалось вне зоны устойчивого покрытия;
• товар был привязан некорректно;
• локальное оборудование временно находилось не в сети;
• ESL был физически повреждён.

Именно в этот момент стал заметен один из главных эффектов автоматизации.

Она не означает, что исключения полностью исчезают.

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

Что видит центральный офис

До внедрения ESL центральный офис мог сформировать новую цену и передать её в магазин.

Но между событиями «цена отправлена» и «информация на полке обновлена» оставалась зона неопределённости.

После запуска MERTECH ESL появилась сквозная видимость всего процесса.

На уровне сети платформа показывает:

• количество подключённых магазинов;
• число активных электронных ценников;
• долю устройств в сети;
• динамику массового обновления;
• статистику успешных доставок;
• магазины с отклонениями;
• состояние базовых станций;
• ценники с низким уровнем заряда;
• количество непривязанных устройств.

На уровне отдельного магазина доступны:

• список оборудования;
• история обновлений;
• ошибки доставки;
• данные о связи;
• непривязанные ESL;
• проблемные зоны;
• технические уведомления.

На уровне конкретного ценника можно проверить:

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

В результате электронные ценники перестали быть просто экранами на полках.

Они стали частью централизованно управляемой инфраструктуры.

Шаблоны превратились в бизнес-инструмент

В начале проекта шаблон воспринимался в основном как внешний вид ценника.

Название товара, цена, штрихкод и информация об акции.

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

На экране ESL можно отображать:

• обычную цену;
• акционную цену;
• цену по карте лояльности;
• размер скидки;
• срок действия предложения;
• цену за килограмм или литр;
• QR-код;
• штрихкод;
• дополнительные характеристики;
• внутреннюю информацию для сотрудников.

Шаблоны можно назначать по:

• товарным категориям;
• форматам магазинов;
• типам промоакций;
• размерам ценников;
• отдельным торговым зонам.

Это позволило централизованно менять оформление всей сети без печати и доставки новых материалов.

Но первые шаблоны оказались перегруженными.

На небольшой экран пытались одновременно вывести цену, старую цену, скидку, условия программы лояльности, срок акции, QR-код и внутренний артикул.

Формально всё помещалось.

Практически читать такой ценник было неудобно.

После тестирования шаблоны упростили:

• увеличили основную цену;
• усилили визуальную иерархию;
• сократили второстепенные поля;
• разделили покупательскую и служебную информацию;
• подготовили разные варианты под основные сценарии.

Цифровой ценник нельзя проектировать как уменьшенную копию бумажного.

Это отдельный интерфейс, который должен быстро считываться с расстояния.

Что изменилось в работе магазина

До внедрения процесс переоценки был массовой ручной операцией.

После запуска MERTECH ESL сотрудники стали подключаться в основном к исключениям.

Ручное участие требовалось, когда:

• новый ESL нужно привязать к товару;
• товар переместили в другую зону;
• ценник повредили;
• устройство долго не выходит на связь;
• требуется обслуживание;
• система обнаружила некорректную привязку.

Вместо 10–14 часов в неделю магазин стал тратить на операции с ценниками около 2–4 часов.

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

Трудозатраты, связанные с регулярной переоценкой, сократились примерно на 65–75%.

Высвободившееся время сотрудники смогли направить на:

• выкладку товаров;
• контроль наличия;
• проверку сроков годности;
• работу с покупателями;
• поддержание порядка в торговом зале.

Важно, что целью проекта не было механическое сокращение персонала.

Задача состояла в том, чтобы убрать повторяющуюся ручную операцию и перенаправить рабочее время на процессы, которые напрямую влияют на качество работы магазина.

Бизнес-эффект на уровне сети

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

Но в сетевом проекте основной эффект формируется не там.

Более 40 000 высвобождённых часов в год

Если каждый из 80 магазинов экономит в среднем 10 часов ручной работы в неделю, общий эффект составляет:

80 магазинов × 10 часов × 52 недели = 41 600 часов в год.

Это сопоставимо с полной годовой занятостью примерно 20 сотрудников.

Однако речь идёт не об автоматическом сокращении штата, а о перераспределении ресурса внутри магазинов.

Переоценка за минуты, а не за часы

До внедрения массовая смена цен могла занимать от нескольких часов до всей ночи.

После запуска MERTECH ESL основная часть обновлений выполнялась за 5–10 минут, а крупная промокампания — в пределах 20–30 минут.

Это позволило точнее планировать время начала и окончания акций.

Сокращение расхождений между полкой и кассой

Цена для кассовой системы и электронных ценников формируется из согласованного источника данных.

При корректно выстроенной интеграции количество расхождений снижается в несколько раз.

При этом платформа позволяет увидеть не только факт отправки, но и подтверждение обновления.

Централизованный контроль исполнения

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

Теперь отклонения отображаются в дашборде.

Можно увидеть:

• какой магазин не завершил обновление;
• какие устройства не подтвердили команду;
• где выросло количество ошибок;
• какая базовая станция недоступна;
• какие ценники требуют обслуживания.

Более быстрый запуск акций

Маркетинговые кампании можно запускать одновременно во всех подключённых магазинах.

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

Дополнительные сценарии управления ценой

Электронные ценники позволяют:

• запускать ограниченные по времени предложения;
• оперативно снижать цены на товары с коротким сроком хранения;
• менять информацию в отдельных магазинах;
• поддерживать локальные акции;
• быстро обновлять шаблоны;
• выводить дополнительную информацию без замены физического носителя.

Не все эти сценарии обязательно используются с первого дня.

Но после внедрения их реализация становится программной задачей, а не масштабной ручной операцией.

Почему систему не развернули сразу во всей сети

После успешного пилота может возникнуть желание быстро установить ESL во всех магазинах.

Команда выбрала поэтапную модель.

Сначала были проверены базовые сценарии в шести пилотных точках. Затем скорректировали:

• архитектуру;
• правила интеграции;
• схемы радиопокрытия;
• шаблоны;
• инструкции для сотрудников;
• порядок привязки ESL;
• требования к мониторингу;
• процесс передачи магазинов в эксплуатацию.

После этого сформировали типовой процесс запуска.

Каждая новая торговая точка проходила следующие этапы:

1. Обследование магазина.
2. Проверка ИТ-инфраструктуры.
3. Подготовка схемы покрытия.
4. Установка локального программного компонента.
5. Монтаж базовых станций.
6. Установка креплений и ESL.
7. Привязка устройств к товарам.
8. Проверка интеграции.
9. Тестовая массовая переоценка.
10. Контрольный период.
11. Передача в промышленную эксплуатацию.

Поэтапный подход кажется медленнее только в начале.

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

Что пошло не по плану

В презентациях системы обычно работают с первого раза.

В реальных проектах это случается редко.

Во время пилота команда столкнулась с несколькими проблемами.

План магазина устарел ещё до монтажа

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

Предварительная схема покрытия перестала соответствовать реальности.

Решением стало повторное обследование уже полностью оборудованного торгового зала.

Один товар оказался в нескольких местах

Часть товаров размещалась одновременно на основной полке, в холодильнике и в зоне акции.

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

Общий показатель скрывал локальную проблему

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

В одном магазине отклонений почти не было, а в другом они концентрировались в одной проблемной зоне.

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

Сотрудники по-разному выполняли привязку

В разных магазинах персонал по-разному понимал последовательность сканирования товара и ESL.

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

Команда подготовила единый короткий регламент и обновила интерфейс так, чтобы последовательность действий была очевидной.

Красивый шаблон оказался нечитаемым

Первая версия дизайна содержала слишком много данных.

После тестирования шаблон упростили и оставили только информацию, которая действительно помогает покупателю принять решение.

Все эти сложности оказались решаемыми.

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

Проект находится на пересечении:

• ИТ;
• эксплуатации;
• ценообразования;
• маркетинга;
• мерчандайзинга;
• работы персонала;
• технической поддержки.

Результат первой очереди

После масштабирования на 80 магазинов сеть получила:

• около 420 000 централизованно управляемых ESL;
• автоматическую передачу изменений из учётной системы;
• массовую переоценку в течение нескольких минут;
• локальную автономность торговых точек;
• единые шаблоны для разных форматов;
• централизованный мониторинг оборудования;
• автоматическую обработку повторных обновлений;
• точечную работу с исключениями;
• снижение ручных трудозатрат на 65–75%;
• более 40 000 высвобождённых рабочих часов в год.

Основная масса ценников обновлялась за 5–10 минут.

Крупные пакетные изменения завершались в пределах 20–30 минут.

В течение контрольного часа подтверждение поступало примерно от 99,5% устройств. После автоматических повторных попыток физического внимания требовало менее 0,1% ESL.

На основании результатов пилота и первой очереди сеть смогла сформировать типовую модель дальнейшего масштабирования.

Главный вывод

В начале проекта основным вопросом было:

Насколько быстро электронный ценник способен изменить цену?

После внедрения стало понятно, что это слишком узкая постановка.

Гораздо важнее другое:

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

Отдельный электронный ценник — это небольшой дисплей, контроллер, радиомодуль и батарея.

MERTECH ESL — это инфраструктура управления информацией на полке.

Она связывает:

• центральную товароучётную систему;
• программную платформу;
• локальную инфраструктуру магазина;
• базовые станции;
• физические товары на полках.

Поэтому результат внедрения измеряется не количеством установленных дисплеев.

Он измеряется временем сотрудников, скоростью запуска акций, точностью информации, прозрачностью процессов и способностью сети централизованно управлять изменениями.