Ошибки маркировки Честный ЗНАК, или как мы внедрили проверку DataMatrix прямо в сборку FBS

Мы работаем с разными маркетплейсами по модели FBS. Вот только с засильем маркировки и при наших объёмах в сотню заказов в день ошибки в DataMatrix добавляли нервотрёпки всем — от сборщика до собственника. Потому что обнаруживали мы их уже постфактум, когда товар уехал к покупателю, а в системе честного знака висел пересорт.

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

Наверное, расскажу для начала, кто такие «мы». Мы — фулфилмент-оператор, работаем с селлерами на Ozon и Wildberries. Простыми словами: продавцы привозят нам товар на склад, а мы берём на себя всё остальное — хранение, сборку заказов, упаковку по стандартам площадок, маркировку и отгрузку. Селлер видит в личном кабинете только статусы, физически с товаром не контактирует.

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

Мы работали по схеме «собери — упакуй — проверь». На старте, когда заказов было немного, это казалось разумным: сначала обеспечиваем скорость потока, потом отдельный сотрудник на другом столе фиксирует коды. Но когда поток вырос, а количество SKU с маркировкой перевалило за тысячу, эта логика «отвалилась».

Главная проблема была не в том, что маркетплейс как-то особенно ловил нас на приёмке (ему на этапе FBS часто всё равно, какой именно пакет молока ты отсканировал). Проблема была в Честном Знаке.

Сборщик брал верный товар, но по невнимательности сканировал DataMatrix от соседней коробки. Товар уезжал покупателю, а нам, чтобы закрыть обязательства, приходилось вручную выводить марки из оборота по отчётам маркетплейса. Из-за того, что физически марки были привязаны не к тем заказам, в ЧЗ мы выводили не те коды. В итоге товар в обороте «подвисал», начинался пересорт марок.

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

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

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

Перебрали различные варианты доработок текущей 1С, интеграции по API, сторонние сервисы — но везде упирались либо в цену, либо в то, что проверка всё равно требовала лишних телодвижений.

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

Мы подключились к бета-версии программы с оговоркой, что будем ежедневно отписываться о багах и недостатках. Установили ПО, выделили одного конкретного селлера, с которым заранее обговорили все условия (решили «тренироваться на кошечках»), и погнали.

Сначала установили приложение на обычный Android-смартфон Infinix. При интенсивном потоке сканирования он начал подтормаживать, и разработчик посоветовал перейти на профессиональные терминалы сбора данных. Мы приобрели несколько ТСД Mertech — по рекомендации разрабов. Вместо одного стационарного компьютера на столе сборки сборщики получили два терминала. Это сразу развязало руки и сделало процесс мобильным.

А главное — мы получили именно то, чего не хватало:

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

И вот что заметили:

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

Из этого опыта могу дать несколько советов, о которых меня никто не просил:

То, что мы внедрили, — это «Маркетплейс 15» от Клеверенса. Функционал проверки КМ и коннектор к Честному ЗНАКу появились в одном из последних релизов.

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

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

Мы посчитали окупаемость для себя и можем сказать, что за счёт того, что ушли бумажные листы, ручные отметки в ЛК и сверки с ЧЗ, вложения вернулись за первые месяцы. Если есть сезонность, то лицензию можно не продлевать на «мёртвый» период. Разработчик даёт две недели бесплатного теста, так что проверить работоспособность на своих заказах можно ещё до оплаты.

Главный вывод из всей этой истории простой: ошибка в DataMatrix или пересорт обходятся дешевле всего, если их не совершать. Можете отследить коды и артикулы без сканирования и бумажных листов — делайте. Если нет — ищите автоматизированные инструменты.

И ещё одно: не бойтесь нововведений. Любой инструмент должен справляться с объёмами именно вашей компании, поэтому обязательно тестируйте всё на реальных заказах — только так можно понять, справится дополнительный софт или нет.