AleksDi

Какие задачи решает компьютерное зрение

На складе компьютерное зрение может применяться для:

• распознавания товаров и упаковки;

• считывания штрихкодов и маркировки;

• подсчёта коробок и паллет;

• контроля комплектности заказа;

• проверки состояния упаковки;

• фиксации перемещения товара;

• контроля размещения в складских ячейках;

• автоматического измерения габаритов;

• подтверждения погрузки и отгрузки;

• обнаружения нарушений техники безопасности.

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

Чем точнее сформулирована задача и чем меньше в ней неоднозначности, тем выше вероятность экономически успешного внедрения.

Когда система окупается быстрее

Операция часто повторяется

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

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

Ошибки уже выражены в деньгах

Экономический эффект проще рассчитать, когда компания знает:

• размер недостач и пересортицы;

• количество претензий клиентов;

• стоимость повторной комплектации;

• потери из-за неправильных габаритов;

• расходы на ручную проверку;

• стоимость простоев;

• число ошибочных отгрузок.

Автоматическое измерение веса и габаритов может быть оправдано, если расчёты с клиентами или перевозчиками зависят от фактического объёма груза. DWS-системы (Dimensioning, Weighing and Scanning) за одну операцию получают размеры, вес и штрихкод, а некоторые решения дополнительно сохраняют фотографию. Эти данные могут использоваться для расчёта стоимости перевозки, проверки счетов, разрешения претензий и подтверждения состояния груза в момент приёмки или отправки.

Когда нужна метрологическая проверка проекта

Если результаты измерений непосредственно используются для определения количества товара, стоимости услуги или других юридически значимых расчётов, необходимо проверить, относятся ли такие измерения к сфере государственного регулирования обеспечения единства измерений (102-ФЗ, статья 1). В этом случае могут потребоваться средства измерений утверждённого типа и действующая поверка (статьи 9 и 13 того же закона).

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

Результат автоматически попадает в WMS или ERP

Само по себе распознавание объекта редко создаёт экономический эффект. Ценность появляется, когда результат используется в информационной системе. Например, система должна не просто обнаружить коробку, но и:

1. распознать товар или прочитать штрихкод;

2. сопоставить его с заданием;

3. зафиксировать расхождение;

4. остановить операцию или создать уведомление;

5. сохранить фотографию события;

6. передать данные ответственному сотруднику.

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

Существующую инфраструктуру можно использовать повторно

Подключение к установленным IP-камерам может снизить стоимость проекта. Многие платформы получают видеопоток по RTSP. ONVIF может использоваться для обнаружения устройств, получения их параметров и управления совместимыми функциями, но не заменяет сам протокол передачи видео.

Однако наличие камер ещё не означает готовности объекта к компьютерному зрению. Охранное видеонаблюдение обычно проектируется для общего обзора и последующего просмотра человеком. Для автоматического распознавания могут потребоваться:

• другой ракурс;

• более короткая выдержка;

• дополнительное освещение;

• более высокая детализация контролируемой зоны;

• отсутствие перекрытий;

• стабильное положение объекта;

• достаточная пропускная способность сети;

• сервер или периферийное вычислительное устройство.

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

На события действительно реагируют

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

До запуска необходимо определить:

• какие события считаются нарушением;

• кто получает уведомление;

• сколько времени отводится на реакцию;

• когда операция должна быть остановлена;

• какие материалы сохраняются;

• кто анализирует ложные срабатывания;

• как корректируется модель.

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

Когда проект, скорее всего, не окупится

Поток операций слишком мал

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

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

Задача сформулирована слишком широко

Формулировки вроде «контролировать весь склад», «предотвратить воровство» или «исключить все ошибки» не подходят для расчёта проекта.

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

Но камера сама по себе не знает, было ли перемещение согласовано, изменился ли заказ или попросил ли клиент перенести отгрузку. Для этого необходимы данные из WMS, TMS, ERP или другой учётной системы.

Нет критерия успешности

Пилот нельзя оценивать по впечатлению «работает достаточно хорошо». До начала проекта необходимо зафиксировать:

• долю обнаруженных реальных нарушений;

• долю пропущенных нарушений;

• частоту ложных тревог;

• стоимость ошибки каждого типа;

• долю контролируемых операций;

• среднее время проверки;

• размер предотвращённых потерь;

• сокращение ручного труда;

• снижение количества претензий.

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

Условия съёмки нестабильны

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

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

От системы ждут стопроцентного результата

Компьютерное зрение снижает количество определённых ошибок, но не исключает их полностью. Результат зависит от состава данных, условий эксплуатации и действий персонала.

Обещание устранить фиксированный процент потерь без обследования объекта и пилотных данных некорректно. Универсального отраслевого показателя вроде «система всегда сокращает потери на 40–70%» не существует.

Как рассчитать предварительную окупаемость

Для первичной оценки можно использовать модель:

Годовой экономический эффект = снижение потерь + денежный эффект от сокращения трудозатрат + дополнительная выручка или сокращение потерь от некорректного тарифицирования − ежегодные эксплуатационные расходы.

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

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

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

Срок окупаемости можно рассчитать так:

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

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

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

Условный пример

Через контрольный пост проходит 20 000 отправлений в месяц. Ошибка возникает в 0,5% случаев — это 100 инцидентов. Средняя стоимость исправления, повторной обработки и претензии составляет 3 000 рублей. Потери достигают примерно 300 000 рублей в месяц.

Если система предотвращает половину таких случаев, она экономит около 150 000 рублей в месяц. При стоимости внедрения 3,6 млн рублей простой срок окупаемости только за счёт сокращения ошибок составит около 24 месяцев, без учёта сопровождения, поверки и стоимости денег. С учётом этих расходов срок будет длиннее. Проект станет привлекательнее, если одновременно уменьшит сверхурочную работу или потери от неверного тарифицирования.

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

Каким должен быть правильный пилот

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

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

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

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

Видеонаблюдение за сотрудниками и хранение данных

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

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

Вывод

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

Наиболее перспективны проекты, в которых:

• есть большой поток однотипных операций;

• стоимость ошибки известна;

• объект можно уверенно наблюдать камерой;

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

• назначены ответственные за реакцию;

• эффект измеряется до и после внедрения.

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

Тогда зачем нам PLANKA?

Ответ у нас не технический, а поведенческий. OpenProject —  тяжёлый интерфейс, спроектированный вокруг пакета работ со всеми его полями. Разработчик, которому нужно за день десять раз что-то передвинуть и оставить комментарий, туда просто не заходит. PLANKA открывается, обновляется по вебсокету в реальном времени, и порог входа у неё нулевой —  человек, который умеет пользоваться Trello(или аналогом), умеет пользоваться PLANKA.

Если ваша команда охотно работает в OpenProject —  не городите огород, оставайтесь в одной системе. Связка из двух инструментов оправдана ровно в одном случае: когда доска в основной системе стоит пустая, а реальная работа всё равно ведётся где-то ещё (как в нашем случаи :-) ).

Разделение зон

Принцип простой: OpenProject отвечает на вопрос: «Что и к какому сроку», а PLANKA: «Как и кто прямо сейчас». Микрозадача не должна попадать в OpenProject никогда. Как только она туда попадает, РП начинает управлять задачами вместо сроков, и вся затея теряет смысл.

Что обе системы реально умеют

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

OpenProject. API v3 —  гипермедийный REST, документация написана по спецификации OpenAPI 3.1, интерактивная версия доступна прямо в вашей инсталляции по адресу /api/docs, а исходник спецификации по /api/v3/spec.json. Аутентификация API-токеном в виде bearer. Вебхуки настраиваются администратором в разделе «API и вебхуки». Всё зрелое, всё предсказуемое.

PLANKA. Здесь надо быть аккуратнее. Официальной документации API у проекта долгое время не существовало вовсе — мейнтейнер прямо признавал, что генерация через Sails-хук для Swagger получалась кривой и до дела не доходили руки. То, что сегодня лежит в разделе API Reference документации PLANKA —  работа сообщества по v2, а не вендорский контракт. Практический вывод: закладывайте, что при мажорном обновлении что-то может поехать, и покрывайте интеграцию тестами.

Дальше два пункта, которые определяют, возможна ли автоматизация вообще:

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

• Персональные API-ключи тоже из v2. До этого единственным способом авторизоваться программно был запрос POST /api/access-tokens с логином и паролем, в ответ —  JWT. Люди в issue-трекере доходили до того, что вручную подписывали долгоживущий токен и клали его в базу. Сейчас можно завести ключ пользователю и передавать его заголовком X-Api-Key.

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

Готового коннектора между системами нет. Ни встроенного, ни коммерческого. В n8n есть community-ноды и для PLANKA, и для OpenProject, но это отдельные ноды от независимых авторов с очень скромной аудиторией. Они снимают часть рутины, но не отменяют необходимость самому продумать маппинг. В Make или другом low-code проще сразу собирать на HTTP-модулях: контроля больше, сюрпризов меньше.

Где эта схема ломается

Грабли, на которые мы наступили. Обидно было бы, если бы вы наступили на те же.

1. Процент выполнения в OpenProject больше не «просто поле». Начиная с версии 14.0, % Complete связан с полями Work и Remaining work формулой: работа выполненная делится на работу общую. Свободно редактируемым вручную поле остаётся только тогда, когда Work и Remaining work не заполнены. Если задать процент и одно из двух других полей - третье вычислится само. У родительского пакета значения работ агрегируются отдельно из дочерних, и записать туда своё число не выйдет.

Отсюда практическое правило. Эпик, в который вы пишете прогресс из PLANKA, должен быть в OpenProject листовым узлом, без дочерних пакетов работ. Либо, что надёжнее, не трогайте нативный % Complete вовсе, а заведите отдельное пользовательское поле «Прогресс по доске» и пишите в него. Родная логика прогресса останется нетронутой, а РП увидит ровно то число, которое пришло от команды.

2. В PLANKA нет иерархии карточек. Карточка не может быть родителем другой карточки. Поля прогресса тоже нет. Поэтому сценарий: «Эпик пересчитывается по дочерним задачам» в лоб не собирается. Два рабочих варианта, либо эпик — это отдельная доска, и прогресс считается как доля карточек, доехавших до закрывающей колонки, либо эпик —  одна карточка, а задачи внутри неё оформлены чек-листом, и тогда процент берётся из него. Первый вариант честнее для команды, второй проще для интеграции. Мы выбрали первый.

3. Связь между сущностями надо где-то хранить. В v2 у карточек есть пользовательские поля, туда и кладите идентификатор пакета работ OpenProject, не в описание карточки. Описание редактируют люди, и рано или поздно кто-то сотрёт вашу служебную строчку вместе с лишним абзацем.

Как это выглядит в движении

Обычный понедельник. Открываю диаграмму Ганта, вижу, что этап «Ядро» подъедает буфер. Смотрю на эпик «Профили пользователей» —  прогресс 30%, число пришло с доски автоматически. Раньше я бы на этом месте написал в чат: «Что там по профилям?» и получил бы ответ через два часа. Сейчас открываю доску и вижу сам, три карточки стоят в «Заблокировано», у всех одна причина, не готовы макеты. Вопрос решается разговором с дизайнером, а не встречей на шесть человек.

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

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

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

Как начинать

Не с интеграции, а с договорённости.

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

Вторая неделя —  доска, две, а то и три карточки эпиков, синхронизация руками. Да, руками. Раз в пару дней РП обновляет процент. Это неприятно ровно настолько, чтобы через две недели стало понятно, стоит ли овчинка выделки.

Третья и четвёртая недели —  команда живёт на доске, РП смотрит из OpenProject, собираем, что раздражает.

И только после этого код. Небольшой сервис-прослойка слушает вебхуки PLANKA, пересчитывает прогресс, дёргает API OpenProject. Базовая версия —  несколько человеко-дней, если структура эпиков к этому моменту устоялась. Если не устоялась, срок можно смело умножать на два, и виновата будет не разработка.

Что в сухом остатке

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

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

И самое главное, что не чинится никаким кодом — если команда не ведёт доску, связка не работает. Это вопрос дисциплины, а не архитектуры.