Роботизация своими силами: как пересобрать внутрицеховую логистику без помощи интегратора

Наш завод работает в Коврове с 1994 года. Мы производим товары для сада и дачного хозяйства: опрыскиватели, шланги, капельный полив и другую сезонную продукцию. Бренд «Жук», под которым выпускается основная линейка товаров, хорошо знакома розничному рынку.

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

Мы приняли решение построить новое, автоматизированное производство с нуля — на собственной территории, с расчётом на дальнейшее масштабирование.

Планировали внедрить ERP и WMS. Казалось, что со складом проблем точно не будет: WMS фиксирует каждое движение — кто, что и откуда взял, где какой товар лежит, как переместился. При таком уровне прозрачности мы не ожидали сбоев.

 

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

 

 

На практике вышло иначе. Мы столкнулись с расхождениями между данными в системе и фактическими остатками.

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

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

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

Как работала система на старте

Изначально складской учёт вёлся на уровне палет.

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

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

Некоторые операции сотрудники фиксировали вручную, некоторые — не фиксировали вовсе. Однако для системы это всё ещё оставалась та же самая палета, в том же объёме. Формально такая палета могла числиться как полноценная, даже если от неё осталась половина.

В какой-то момент стали возникать расхождения: ERP и WMS продолжали считать, что нужные комплектующие есть в наличии, а при попытке отобрать детали оказывалось, что ящиков уже нет.

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

 

Пересборка логики внутрецеховой логистики продолжалась более двух лет —  с декабря 2020 по июнь 2023.

 

 

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

Мы приняли решение полностью пересобрать логику внутрецеховой логистики. Проект продолжался более двух лет —  с декабря 2020 по июнь 2023.

Как выбирали новое решение

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

Оставался главный вопрос: как это сделать? 

Вот какие варианты у нас были:

1. Готовое решение под ключ

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

У таких решений есть плюс: всё работает «из коробки». Но только если процессы компании полностью укладываются в то, как система устроена изначально.

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

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

2. Собственная архитектура 

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

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

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

 

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

 

 

В рамках проекта мы:

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

Команда проекта

На раннем этапе команда состояла всего из одного специалиста АСУ ТП.

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

Затем к нему присоединились:

• Специалист, который занимался интеграцией оборудования от поставщиков с уже встроенными системами управления «железом».
  
  Он настраивал связку ERP, WMS и системы собственной разработки, отвечал за общую архитектуру проекта, разрабатывал отдельные модули и бизнес-логику для управления роботизированным оборудованием на складе и в цеху.
• Сервисный инженер, который разбирался с поломками и отказами оборудования;
• Специалист по робототехнике, который отвечал за настройку роботизированных решений.

Всего — 4 сотрудника, работающие на проекте параллельно с другими задачами.

Как работает новая система

После перехода к ящичному формату мы перестроили всю логику внутренней логистики. Ящик — основная единица учёта. У него есть код, вес, маршрут, история. Система больше не работает с «условной палетой» — она управляет конкретной тарой.

Теперь наши процессы выстроены так:

1. Приёмка

Каждый ящик, поступающий с производства, взвешивается. Вес используется для расчёта количества деталей — по нормативу массы одной штуки.

Если данные соответствуют заданному диапазону, ящик автоматически ставится на учёт. Если нет — требуется ручная проверка.

На этом этапе печатается маркировка, и ящик получает уникальный идентификатор. Так начинается его цикл в системе.

2. Фиксация и хранение

Ящик фиксируется как самостоятельная сущность, привязанная к заданию и партии. Мы точно знаем, где он находится и откуда пришёл.

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

Перед размещением ящика включается фара — робот подсвечивает ячейку и делает фото.

 

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

 

 

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

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

3. Комплектация

Когда приходит задание, система формирует заказ на комплектацию.

Например, поступает запрос от производства — в ERP работник склада указывает, на какое рабочее место нужны ящики. Ящичный склад подбирает нужные позиции, и робот выкладывает их на палету. Получается скомплектованная палета под конкретное задание.

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

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

4. Возврат остатков

Если после сборки в ящике что-то осталось — он возвращается. Вес проверяется повторно. Если отличается от изначального — система фиксирует отклонение, требуется уточнение.

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

Система учитывает, сколько было, сколько ушло, сколько осталось. Например, если в ящике было 1500 деталей, а за смену собрали 1000 изделий — система ожидает, что осталось 500. При пересчёте мы попадаем в погрешность всего в несколько штук.

 

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

 

 

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

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

Что это дало

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

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

Измеримые эффекты

Раньше учёт вёлся на уровне палет, сейчас — на уровне ящиков. Это дало возможность перейти к автоматической инвентаризации: ящик ставится на весы, вес улетает в 1С, и система рассчитывает точное количество.

 

Минимальная точность увеличилась в 24 раза.

 

 

AGV устранил ручные ошибки перемещений. Раньше ящик могли поставить не туда или забыть провести в системе. Теперь всё движение — только по заданию, без самодеятельности. Робот стал виртуальным конвейером, который может перевезти «из любого места в любое место».

Эффекты в логике и управлении

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

 

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

 

 

Эта уверенность появилась не сразу, а постепенно, за счёт прозрачной логики на всех этапах.

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

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

Управление завязано не на жёсткую механику, а на цифровую логику: достаточно перенастроить маршруты, и AGV подстроится под новое размещение.

Экономический эффект

Объёмы продаж растут на 20–30% в год, при этом численность персонала на заводе снижается.

Производство масштабируется без наращивания команды — за счёт автоматизации процессов и изменения логики работы.

Итоги проекта

Для нас этот проект стал в первую очередь про прозрачность.

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

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

«Если ты не понимаешь, как работает система — ты ей не доверяешь». Мы сами видим, как система ведёт себя на каждом этапе, и именно это дало уверенность — в цифрах, в управлении, в принятии решений.

 

Объёмы продаж растут на 20–30% в год, при этом численность персонала на заводе снижается.

 

 

Что бы мы сделали иначе

За время проекта было и то, что сработало, и то, что хотелось бы переиграть.

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

 

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

 

 

• Во-вторых, мы не стали бы параллельно вести несколько крупных проектов, а выделили бы больше специалистов на этапах с высокой трудоёмкостью.
  
  В первую очередь — на интеграцию с ERP и WMS, проработку логики движения тары, настройку взаимодействия с AGV и контроль точности данных в системе.
  
  Эти точки требовали особой плотности внимания. Так получилось бы завершить проект гораздо раньше. 

Что предусмотреть при автоматизации своими силами

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

• Внутри команды должны быть специалисты, которые способны разработать архитектуру системы и проработать методологию: как будет устроена работа, кто с кем и на каком уровне взаимодействует.
  
  Речь не только о технической архитектуре, но и об общей логике процессов, системе ответственности и точках принятия решений.
  
  Если таких нет в штате, стоит привлечь их хотя бы на ключевые этапы проекта.
• Интеграция покупных решений и собственных разработок требует отдельного внимания.
  
  Эти системы не соединяются сами собой. Нужно заранее разложить по уровням, как они будут работать вместе, где граничат, и кто отвечает за результат.
• Качество — это не отдельный этап, а сквозной критерий.
  
  Оно важно и в выборе оборудования, и в настройке, и в логике. Если где-то сработает компромисс — потом это проявится в бесконечных доработках и сбоях.
• Масштабируемость и гибкость нужно предусматривать сразу.
  
  Любое изменение бизнес-процессов или требований не должно требовать пересборки всей системы с нуля. Архитектура должна это выдерживать без капитального ремонта.

 

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

 

 

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