Роботизация своими силами: как пересобрать внутрицеховую логистику без помощи интегратора
Наш завод работает в Коврове с 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 и контроль точности данных в системе.
Эти точки требовали особой плотности внимания. Так получилось бы завершить проект гораздо раньше.
Что предусмотреть при автоматизации своими силами
Многие компании, которые автоматизируется самостоятельно, проходят похожий путь. Ниже — несколько принципов, которые, на наш взгляд, важно учитывать в подобных проектах:
- Внутри команды должны быть специалисты, которые способны разработать архитектуру системы и проработать методологию: как будет устроена работа, кто с кем и на каком уровне взаимодействует.
Речь не только о технической архитектуре, но и об общей логике процессов, системе ответственности и точках принятия решений.
Если таких нет в штате, стоит привлечь их хотя бы на ключевые этапы проекта. - Интеграция покупных решений и собственных разработок требует отдельного внимания.
Эти системы не соединяются сами собой. Нужно заранее разложить по уровням, как они будут работать вместе, где граничат, и кто отвечает за результат. - Качество — это не отдельный этап, а сквозной критерий.
Оно важно и в выборе оборудования, и в настройке, и в логике. Если где-то сработает компромисс — потом это проявится в бесконечных доработках и сбоях. - Масштабируемость и гибкость нужно предусматривать сразу.
Любое изменение бизнес-процессов или требований не должно требовать пересборки всей системы с нуля. Архитектура должна это выдерживать без капитального ремонта.
При самостоятельной автоматизации важно сразу продумать архитектуру, зоны ответственности и стыковку систем. Без этого масштабирование будет упираться в постоянные доработки.
Так можно получить не просто рабочее решение, а масштабируемую систему, которая развивается вместе с производством — без зависимости от подрядчиков и без переделки с нуля при каждом изменении.
