Виртуальное моделирование в процессе внедрения WMS: как избежать ошибок

В жизни любого складского комплекса рано или поздно наступает момент, когда вызовы современности создают необходимость выполнить глобальную модернизацию складских процессов и систем. Конечно, каждый заказчик надеется получить в итоге хорошо отлаженную систему, ведь такой проект предполагает масштабные единовременные инвестиции. Имеет смысл начать процесс модернизации с построения виртуальной модели системы WMS (Warehouse Management System). Однако при определенном стечении обстоятельств эта идея может завести нас в ловушку, поскольку никакая модель не отражает всех тонкостей функционирования реальной складской системы. При создании симулятора не стоит торопиться и экономить: чем детальнее вы рассмотрите и спроектируете складские процессы, тем больше будете удовлетворены конечным результатом автоматизации.

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

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

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

Примеры ошибочного подхода

Пример 1.

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

То есть, компания X сначала создала модель своего представления о желаемой работе склада и уже на ее основе сформулировала техническое задание, которое, как казалось в начале, полностью отражало имеющуюся ситуацию. Однако в процессе реализации проекта стало ясно, что модель неосуществима в реальности. Проблема была в том, что техническое задание основывалось на описании желаемого «идеального» процесса на складе без учета особенностей физического перемещения товаров. Заказчику нужно было убедиться в том, что модель работает: попытаться вручную провести весь процесс, выловить «подводные камни» и только потом переходить к реализации.

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

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

Пример 2.

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

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

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

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

Из рассмотренных примеров можно сделать несколько выводов:

• При построении виртуальной модели необходимо основываться на реальных данных. Чем детальнее вы изучите процесс, который пытаетесь воссоздать, тем жизнеспособнее будет результат.
• Заказчику необходимо знать стандарты оборудования и технические условия, применяемые в каждом конкретном месте или стране. Ведь даже оборудование одного и того же производителя может отличаться в зависимости от региона, а в некоторых случаях может оказаться вовсе несовместимо с существующими складскими системами. Кроме того, могут отличаться технические условия и требования, законодательство, вмешаются человеческий фактор и местные правила. Случаются отличия и в организации складских процессов самой же компании: например, одно и тоже оборудование может быть задействовано на разных этапах перемещения товаров и многое другое.
• И, конечно, самый важный вывод, который можно сделать из приведенных примеров, заключается в следующем: заказчик должен контролировать процесс разработки на всех этапах и пересматривать свои требования, как только возникает необходимость. Ключевым моментом является тесное сотрудничество с поставщиком (предпочтительно, чтобы он был один как для программного, так и для аппаратного обеспечения). И клиенту, и поставщику необходимо согласовать спецификации всех систем — это оптимальный вариант, при котором не будет посредников в процессе внедрения. Прямая связь между заказчиком и разработчиком программного/аппаратного обеспечения минимизирует количество проблем до успешного запуска WMS.

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

Внимание к деталям — путь к успеху

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

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

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

Конечно, «на ошибках учатся», но когда дело касается такого ответственного и дорогостоящего проекта, как автоматизация склада, стоит внимательнее отнестись ко всем этапам планирования и сделать все правильно с самого начала.