Скан — это не действие

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

Обычно это не считают проблемой, потому что интервал кажется коротким. На деле он и есть основное рабочее время. Скан занимает секунду. Между сканами — путь до ячейки, поиск позиции, ожидание пополнения зоны, занятый проезд, разговор, перекур. В журнале сканирований всё это выглядит как пустое место между двумя строками с временем.

Отсюда класс задач, которые внутри учётного контура не решаются — не по недосмотру проектировщика, а потому что решать их нечем:

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

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

Откуда я на это смотрю

Двадцать пять лет занимаюсь складскими системами на 1С: проектирование, тиражные решения со статусом «1С:Совместимо», внедрения на десятках площадок, от небольших складов до 3PL. Последний год работал аналитиком в складской группе ИТ-департамента розничной сети: восемь складов, 250 магазинов, сильно переработанная УТ.

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

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

Спор о том, что видно на камере, решается арифметикой

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

Ширина поля зрения на дистанции D составляет W = 2 · D · tg(HFOV / 2), где HFOV — горизонтальный угол объектива. Разрешение на объекте: px/m = горизонтальное разрешение матрицы / W. Для камеры 1080p с типовым обзорным объективом 70° получается: на двух метрах 686 пикселей на метр, на четырёх 343, на десяти 137, на двадцати 69, на тридцати 46. Камера 4K удваивает эти числа, узкий объектив 45° добавляет ещё примерно 55 процентов.

Рис. 1. Разрешение на объекте в зависимости от дистанции и типа камеры, с порогами задач

Дальше остаётся сопоставить полученное число с потребностью задачи. Ориентиры такие: устойчивое присутствие и трекинг человека — от 40 до 80 пикселей на метр; класс действия, счёт паллет в проёме и локализация до паллето-места — от 80 до 150; ячейка полочного стеллажа и сверка предмета с фото карточки — от 250 до 600; чтение линейного кода на паллетной этикетке — от 4000, а DataMatrix «Честного знака» требует на порядок больше и остаётся задачей сканера.

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

Ячейка полочного стеллажа — другой случай: 30–50 сантиметров по фронту, на двадцати метрах это 20–40 пикселей, чего не хватает. Но полочные стеллажи и мезонины не просматривают с двадцати метров. Там камера стоит в трёх-пяти метрах и даёт от 270 до 460 пикселей на метр, то есть от 80 до 230 пикселей на ячейку.

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

Как посчитать под свой объект

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

Дальше сравнить с порогом задачи и с реальным размером объекта: паллето-место 1,2 метра, паллета 1,2 × 0,8, человек по ширине около полуметра, ячейка полочного стеллажа 0,3–0,5 метра. Если получившееся число попадает в порог с запасом менее чем в полтора раза, лучше считать, что задача не решается: реальные условия — блики, контровой свет, перекрытия, наклон ракурса — съедают этот запас первыми.

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

Точки наблюдения: покрывать нужно узлы, а не площадь

Возражение «камеры не покрывают весь склад» верно и при этом не мешает: сплошное покрытие не требуется. Операции концентрируются в узлах, и почти вся ценность собирается в пяти-шести местах.

Рис. 2. Узлы наблюдения на типовом складе и задачи, решаемые в каждом

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

Проём ворот

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

Стол контроля

По соотношению «разрешение к ценности» это лучшая точка на складе. Камера висит в полутора-двух метрах над рабочей поверхностью и даёт от 686 пикселей на метр при 1080p до 1371 при 4K. В сети, где я работал, столы контроля уже оборудованы камерами — их ставили для разбора претензий, и всё остальное время они пишут в архив.

Рис. 3. Стол контроля: три независимых признака в одном кадре

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

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

Мезонин мелкоштучки

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

Где граница проходит на самом деле

Список короткий и от выбора модели не зависит.

• Чтение DataMatrix «Честного знака» обзорной камерой. Модуль кода — доли миллиметра, требуемое разрешение на порядок выше того, что даёт любая потолочная камера. Это задача сканера или специальной камеры на дистанции в двадцать сантиметров.
• Содержимое закрытого короба. Закрытая коробка выглядит как закрытая коробка.
• Зоны без обзора. Камера видит свою зону, и это входное условие, а не дефект настройки.
• Верхние ярусы, перекрытые стоящей паллетой. Перекрытие лечится вторым ракурсом, а не моделью.
• Намерение человека. Наблюдение даёт расхождение и основание, по которому оно получено; интерпретация остаётся за человеком.

Чем это отличается от охранного видеонаблюдения

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

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

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

Точки и линия

WMS даёт последовательность точек: скан, скан, скан — каждая с меткой времени, оператором и адресом. Наблюдение даёт линию: кто-то находился в такой-то зоне с 11:58 по 12:04 и четыре минуты из шести не двигался.

Рис. 4. Одно задание отбора: журнал сканирований и непрерывное наблюдение

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

Что извлекается из сопоставления

Хронометраж операции. Задание закрыто в 12:04, оператор вошёл в проход в 11:58 и четыре минуты из шести провёл без движения. WMS покажет, что задание заняло шесть минут; сколько из них было работой, она не покажет никогда. Накопленный за месяц хронометраж по типам операций и зонам — это нормировка, построенная на наблюдении, а не на средних из справочника.

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

Маршрут. Задание ведёт в проход 5, оператор восемь минут провёл в проходе 8. Формулировка события — «задание ведёт в другой проход», а не «взял не ту позицию». Пока паллета на складе, проверка стоит несколько минут; та же ошибка, всплывшая у клиента, стоит на порядки дороже.

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

От факта к причине

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

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

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

Как оценивать эффект в деньгах

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

Пример со слоттингом. За месяц по позиции прошло 4200 отборов. Фактический маршрут по наблюдению длиннее оптимального на 30 метров. Получается 126 километров лишней ходьбы и около 29 часов рабочего времени; при ставке 360 рублей в час — примерно 10 400 рублей в месяц на одной перестановке двух ячеек. Для ошибок отбора формула та же по устройству: строк в день × доля ошибок × стоимость разбора одной ошибки × рабочих дней. Три множителя из четырёх берутся из WMS, четвёртый называет сам склад.

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

Контур обработки

Рис. 5. Распределение обработки между площадкой и сервисом

Агент на площадке — мини-ПК с docker и исходящим HTTPS-соединением, без входящих портов. Он разбирает поток, берёт от 0,2 до 1 кадра в секунду и отдаёт наружу не видео, а описание сцены. Видеоархив остаётся на площадке: это принципиально и для службы безопасности, и для трафика. Со стороны WMS читается поток заданий и операций, только чтение.

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

Контракт события

Событие — не картинка и не результат работы модели, а структура с заранее описанным составом полей:

{

  "event_id": "0f6c1e2a-...",

  "occurred_at": "2026-08-08T12:04:17+03:00",

  "type": "route_mismatch",

  "zone": "A-05",

  "wms_ref": { "task": "1847", "line": 3, "operator": "12" },

  "observed": { "zone": "A-08", "from": "11:58:41", "to": "12:04:02" },

  "confidence": 0.91,

  "model": "aisle-detect@2026.06.3",

  "cost_estimate_rub": 1900,

  "evidence": "https://agent.local/f/0f6c1e2a.jpg"

}

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

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

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

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

Как это выглядит со стороны WMS на 1С

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

Уровень первый: конфигурация не меняется. Чтение заданий и операций идёт через OData или существующий HTTP-сервис на чтение, вывод — в мессенджер ответственному и в отчёты. Релизный цикл не затрагивается, служба сопровождения не вовлекается. Этого достаточно, чтобы понять, есть ли на площадке что ловить.

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

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

Со стороны WMS читаются задания и их строки, журнал сканирований, справочник ячеек и зон, сотрудники и смены. Ничего экзотического: всё это есть и в Акселоте, и в Ситеке, и в самописных решениях на УТ, отличается только наименование объектов.

Что из этого следует

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

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

Вопросы к сообществу

Три вопроса, ответы на которые мне интересны больше, чем согласие с текстом.

Первый: сталкивался ли кто-нибудь с задачей учёта времени между сканами и чем её закрывали? Меня интересуют именно рабочие решения внутри 1С, включая те, которые в итоге признали неудачными.

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

Третий: если у вас на складе стоят камеры и работает WMS — какое расхождение между планом и фактом вы хотели бы увидеть первым? Не в идеале, а то, что мешает на этой неделе.