СУС с огоньком. Как не сжечь склад при автоматизации

СУС с огоньком. Как не сжечь склад при автоматизации
изображение создано нейросетью
Почему 80% компаний используют свои системы управления складом лишь на 15% от их потенциала? Эксперт с 23-летним опытом в логистике анализирует типичные ошибки внедрения WMS и предлагает практическое решение: не менять систему, а грамотно реанимировать существующую. В материале IT-World — подробный разбор кейсов и пошаговая инструкция по актуализации СУС без лишних затрат.

Изменения — это, пожалуй, основная тенденция нашего времени. Сложно однозначно сказать, какие изменения негативные, а какие позитивные, они такие, как есть, и наша задача — уметь максимально адаптироваться к ним. Хорошая новость состоит в том, что сегодня рынок активно реагирует на изменения и предлагает различные инструменты. В логистике одним из таких инструментов являются автоматизированные системы управления складом (СУС). В популярной литературе можно встретить аббревиатуру WMS (warehouse management system). Но ГОСТ Р 59282-2020 определяет систему управления складом как систему, целью которой является эффективное управление процессами и ресурсами склада по правилам и алгоритмам, установленным в функционале конкретной системы, а также при ее внедрении и эксплуатации. По сути, это программа, которая берет на себя функции начальника склада и даже больше.

А так ли много предприятий сегодня, на которых есть реально работающая система управления складом (СУС по ГОСТ), она же WMS?

Проработав более 23 лет в сфере логистики и управления цепями поставок, могу сделать вывод, что это не более 10–15% предприятий, а то и меньше. Более того, около 80% тех у кого СУС есть, используют ее потенциал лишь на 15%. Печальная статистика, не правда ли?

А почему так? Давайте рассмотрим жизненную ситуацию. Крупная компания (хотя размер в данном случае не имеет значения). Ретейл. Товаропоток растет. Предприятие развивается, но вместе с этим растут и затраты на логистику. Причем не пропорционально.

Идеальный склад: пять идей по доработке «1С:WMS»
Долго обсуждали и пришли к выводу, что СУС спасет ситуацию. Было решено внедрять. Но что-то пошло не так. С самого начала оказалось, что не учли то, не учли это... Как итог проект — затянулся по времени и вышел за границы бюджета. Значительно вышел. Ситуация критическая, и надо было рапортовать о внедрении. Отрапортовали бодро, и работа началась. Проект постепенно обрастал проблемами. Спустя 1–2 года команда внедренцев и владельцев процессов почти полностью изменилась, те, «кто хоть что ни будь помнил», заняты уже другими делами, а тем, кто работает сейчас, не понятно, почему вообще так было задумано. На этом этапе появляются «костыли», локальные программные доработки, позволяющие частично привести функционал программы в соответствие с текущими, актуальными процессами. А дальше — «новые костыли», которые позволяют работать «старым костылям» и т. д.

Почему так происходит? Причин несколько. Во-первых, на предприятии отсутствует система передачи знаний и информационная база по поддержке системы, поэтому при ротации персонала неизбежно происходит утрата накопленного опыта. Во-вторых, нет объективной и, главное, динамической оценки бизнес-процессов склада: изначально они легли в основу технического задания, но со временем изменились, а формально остались прежними. В-третьих, отсутствует ИT-культура и системное взаимодействие подразделений ИT с владельцами процессов. Чаще всего управление системой передается именно айтишникам, хотя оно и находится не в их ведении. В результате система технически исправна, но не соответствует текущим потребностям, а снежный ком доработок растет изо дня в день. Безнадежная ситуация, скажете вы. Нет, отвечу я вам.

Хорош Федот, да не тот?

Что делать в ситуации, когда СУС уже есть, но не соответствует текущим потребностям, — менять или дорабатывать? Глубоко убежден, что, как говорится, старый друг, лучше новых двух.

Причин тому несколько, как минимум две. Прежде всего функционал:

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

Ну разве этого мало ? А отсюда и вторая причина — финансы.

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

Учитывая плюсы, можно приступать к работе. Начинать надо как всегда с процессов, их актуализации. При этом однозначно, от текущего функционал системы придется абстрагироваться. Да, да, именно так. Мы не подстраиваем процессы под систему. Система — это наш инструмент для реализации актуальных, реальных (а не на бумаге) процессов.

Не забываем про технологии. Скорее всего, за последние пару-тройку лет технологии на складе могли поменяться. Проявилась новая техника, например, или изменилась технология погрузо-разгрузочных работ.

Объективно проанализировав и оценив процессы, приступаем к аудиту функционала системы. Это очень интересный процесс и, как правило, несет в себе много открытий. Оказывается, часть нужного и актуального функционала в системе уже есть! Мы просто не знали (забыли) о нем. От той части функционала, которая потеряла актуальность (а такая будет), придется отказаться. Да, именно отказаться. Просто отрезать ненужное. Потери, скажете вы. Да, потери, но они несопоставимо малы с потерями при внедрении новой системы.

Немаловажным фактором является и актуальность «железа». Терминалы сбора данных (ТСД), сканеры принтеры этикеток. Однозначно, стоит ответить на вопрос, касающийся перспективности использования текущего парка «железа».

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

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

Сложно? Долго? На самом деле, на практике такие изменения могут занять от полугода до года. Но только представьте себе риски, которые возникнут, если оставить ситуацию без изменений, я уже не говорю о рисках, связанных с внедрением новой системы. Ведь нет гарантий, что при ее внедрении вы не наступите на те же грабли. И главное, «слона надо есть по частям». Не надо пытаться изменить все и сразу. Изменения можно реализовать поэтапно. Мой совет — начните с приемки. Итак, на мой взгляд, гораздо практичнее будет обновить текущую систему. Однако прежде стоит убедиться в надежности текущего решения.

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

Как подойти к выбору новой СУС

Ну а если ваш вариант — это новая система. Как ее выбрать? Есть важное правило, которое необходимо учесть. При выборе системы необходимо отталкиваться не от ее стоимости или возможностей. Как я и говорил ранее, начните с бизнес-процессов склада. Я часто реализую проекты по повышению эффективности логистики на предприятиях, в рамках которых провожу предпроектное исследование перед внедрением СУС. Интересная ситуация складывается при анализе бизнес-процессов, подчас колоссальные резервы скрыты именно в них. Возможно вы удивитесь, но на большей части современных предприятий достичь значимого эффекта можно даже без внедрения каких-либо программ. При анализе сразу же видны и пути для улучшений, а также какой именно функционал необходимо автоматизировать. Но более того, есть предприятия, где автоматизация противопоказана, как бы это ни звучало.

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

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

Само словосочетание «бизнес-процессы» часто пугает неподготовленного руководителя. Да что там скрывать — и подготовленного тоже. Однако есть методики позволяющие довольно просто и эффективно выполнить работу по анализу бизнес-процессов и даже без привлечения супердорогих специалистов. Буквально своими силами. Главное — понять суть задачи. Мы описываем операции, каждый их шаг так, как видим, на каждом новом шаге задавая вопрос: «А как я могу это автоматизировать?».

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

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

Кстати, говоря о сроках и о стоимости. Основываясь на личном опыте, общаясь с коллегами по цеху, пришел к выводу, что около 50% проектов по внедрению СУС выходят за рамки бюджета и около 30% за установленные сроки. Так происходит потому, что чаще всего уделялось недостаточно внимания этапу подготовки к внедрению системы, о которой я писал выше. Есть желание внедрить систему и исправить все ошибки, но получается так, что ошибки мы не исправляем, а просто автоматизируем, получая автоматизированные ошибки. Уже в процессе внедрения приходит понимание, что забыли то, забыли это, надо доработать тут и там... Такие ситуации и загоняют потенциально успешные и довольно дорогие проекты в бесконечность. Чтобы избежать подобной ситуации, начинайте с анализа процессов. Если вы все сделали последовательно и правильно, то проект по внедрению не займет больше года и не превратится в «пожар».

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

  1. Поэтапное внедрение функций. Например, когда мы внедряем поэтапно маркировку, приемку, затем комплектацию, затем отгрузку, маркировку и т. д.
  2. Поэтапное внедрение по зонам. Да, внедряем и запускаем весь функционал, но на одном небольшом, пилотном участке и, отработав на нем, начинаем масштабирование.

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

Самописная система: оставлять или менять?

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

***

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

Опубликовано 02.09.2025

Похожие статьи