Опыт построения архитектуры WMS: как это было.
Несколько лет назад передо мной была поставлена задача разработать подсистему, функциональность которой позволила бы существенно повысить производительность складской подсистемы, в одной весьма известной компании федерального масштаба.
Как дополнительные требования выдвигались: не слишком высокая стоимость владения системой (решения типа Manhattan не рассматривались в принципе), а также высокая степень интеграции с текущей системой, в которой в принципе имелись данные для начала ведения учета.
К сожалению, на тот момент были загружены довольно серьезные складские площади, и провести быструю инвентаризацию было не возможно. Кроме того, на складе монтировали стеллажи, часть товара размещалась не в ячейках, а прямо на полу, и даже зоны не были размечены и промаркированы. В общем-то в наличии имелась классическая ситуация для российских реалий, с той лишь разницей, что у команды, работавшей над задачей, уже был некоторый опыт имплементации решений данного направления, поэтому, можно было сэкономить какое-то время на изобретение велосипедов, уже имеющихся в наличии.
Пару слов об интеграции и разработке пользовательского интерфейса. Именно требования к интеграции явились причиной решения использовать 1С: Предприятие как базу для разработки функционала WMS. Некоторые коллеги на тот момент выражали скепсис по поводу возможного достижения потолка производительности, но те, кто застал времена версии 1С: Предприятие 7.7 и 1С++ отдавали себе отчет в том, что ограничения производительности технологической платформы совершенно спокойно обходятся переходом на более низкий уровень — написание запросов и хранимых процедур на SQL.
А вот то, что интерфейс должен был сохранить черты 1С: Предприятия, сомнений не вызывало. Персонал, работающий на складе, с сожалению, не может похвастаться высоким уровнем компьютерной подготовки, но вот 1С худо-бедно знают (видели, пробовали выполнять простые операции под контролем старшего) практически все. Как бы отдельным творческим членам команды не хотелось создать свой, “идеальный” интерфейс, с этим приходилось считаться.
Итак, первоначально следовало определиться с хранением информации о топологии склада. Здесь есть несколько тонкостей.
- Справочник ячеек целесообразно делать иерархическим. Но не с иерархией групп и элементов, а с иерархией элементов, то есть от зоны к ячейке должны быть заданы все звенья — ряд, стеллаж и т.д. Это поможет избежать хаоса на том этапе, когда нам нужно быстро внести справочную информацию для работы, и мы указываем ориентировочное местоположение.
- Для графического отображения склада обычно используют горизонтальную проекцию (т.е. вид сверху). В принципе, можно использовать и изометрическую, но на мой взгляд, это избыточно.
- Таким образом, для описания каждого стеллажа нужно обычно задать координаты (x,y) по четырем его углам. Для описания ячейки к этом еще добавляется высота.
- Однако этого отнюдь недостаточно для того, чтобы построить какие-либо алгоритмы с достаточной эффективностью. Необходимо определить координаты расположения мест доступа к тем или иным стеллажам.
- И вот между этими точками нужно построить граф переходов, по которому будет рассчитываться оптимальный способ обработки текущего пула операций.
- Очевидно, что существует вероятность создания помехи двумя исполнителями друг другу, если ряды узкие и не позволяют разъезжаться. В таком случае, можно задать правил передвижения путем придания ребрам графа ориентированности.
Итак, когда структура данных заполнена, можно переходить к процедуре массовой привязки товара к ячейкам. Обычно берут данные из используемой в настоящее время системы, и в подсистеме ячеистого учета оформляют ввод остатков на служебную ячейку, обозначающую неизвестное местоположение.
Далее, обобщают знания по товарам в виде укрупненного списка по группам, наподобие:
- известно, что группа товаров А размещена в зоне 1
- известно, что группа товаров Б размещена в зоне 2, в ряду №4…
- и .т.д.
Таким образом, в течении полудня удается разбросать весь товар по его приблизительным местам размещения, с разной степенью детализации.
Сразу же после этого этапа, система начинает приносить пользу, так как нанятый на следующий день сотрудник, не знающий что где лежит, получит в задании на сборку заказа ориентировочной местоположение.
Одновременно с заданиями на сборку, сотрудники склада получают задания инвентаризации по сегментам. Мы понимаем, что в момент выдачи такого задания, сегмент временно замораживается, то есть другие сотрудники никаких заданий по нему получить в это время не могут.
В результате такой локальной инвентаризации, товар в учете списывается с “обобщенной” ячейки, и приходуется в конкретную.
Таким образом, в результате приложения последовательных усилий, мы из бардака получаем не “автоматизированный бардак”, а более-менее упорядоченную систему, которая с каждым днем будет работать все более четко. Конечно же, при плотной загрузке, даже через несколько месяцев могут остаться зону с “обобщенным” позиционированием, но ясно, что время в данном случае работает на нас.
Пару слов, про ситуацию с отсутствием данных в системе напрочь.
В данном случае, как мы понимаем, при избытке мощностей нужно загружать склад максимально “горизонтально”.
После получения же данных об оборачиваемости товара, уже можно начать выдавать задания о перемещении малооборачиваемого товара на верхние ярусы стеллажей.
В фарм логистике, в связи с требованиями GMP, каждую паллету нужно снабжать бумажной копией досье продукции, размещенной на ней — с тем, чтобы в случае технического сбоя, не утратить контроль за ситуацией даже на короткое время.
Конечно же, еще осталось довольно много вопросов для обсуждения, понемногу будем освещать в дальнейших публикациях.