На страже границ WMS Дмитрий Перов

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

Проблема ли это? 

Есть ли правильное ее решение? 

Надо ли об этом говорить? 

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

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

Иерархическое положение  WMS

Что такое WMS, и какое место они занимают среди других систем, какое поле задач должны покрывать. Сначала рассмотрим «вертикальную» иерархию. Данные системы относятся к классу исполняющих. «Над» ними существуют системы планирующие. Критерием разделения задач между системами здесь служит ответы на вопросы «что делать» (планирование) и «как делать» (исполнение). Именно «как делать», а не просто «делать», потому что если поставить вопрос так, то действие должно быть элементарным, для него и система не нужна – все остальное будет относиться к планированию. Если же исполняющая система отвечает на вопрос «как делать», то в ней остается некоторый элемент планирования – и наш критерий перестает быть четким. Соответственно, границы будут размытыми.

«Ниже» исполняющих систем в иерархии расположены системы АСУТП (управление технологическим процессом). С точки зрения того же критерия разделения, исполняющие системы играют здесь роль планирующих, отвечают на вопрос «что делать» а АСУТП – исполняющих. Как видим – и здесь та же проблема, поэтому разделить четко по вертикали системы нельзя. Как же поступают в таком случае? Следуют традициям, не более того.

Традиционно финансы относятся к планирующим системам (в логистике и производстве, в банках и торговле это вполне могут быть и исполняющие и даже АСУТП). Поэтому, когда речь заходит о деньгах, в каком бы то ни было контексте, то это та самая «не складская задача». А как же биллинг, услуги 3PL, или внутренний бюджет? Ведь многие WMS его включают. Здесь две противоречащие друг другу традиции. Одна говорит: «Включать, ведь операции осуществляются на складе, там и посчитаем». Другая традиция ей противоречит: «Не включать. Выгрузить данные по операциям в третью систему (система или модуль Биллинга) и больше ничего не делать, иначе сядет быстродействие».

Какая из традиций правильная – неизвестно, но почему-то отсутствует третья: «Считать услуги надо не в отдельном модуле биллинга, а в планирующей системе. Она и с договорами на обслуживание должна работать и с финансами». Раз нет такой традиции, то и ни один протокол обмена между ERP и WMS не поддерживает выгрузку стоимости (ресурсоемкости, конечно же) одновременно с подтверждением операций. И пресловутый EDI – тоже не поддерживает. И очень даже зря, очень бы красиво получалось, но традиции нет…

Различия по горизонту планирования

Еще планирующие системы традиционно отделяются от исполняющих по горизонту планирования. ERP управляют заказами и строками заказов, а ячейками хранения и процессами сборки они управлять не могут (в них и объекта такого нет). Поэтому планирование отбора – задача исполняющей системы.

Все просто и понятно, пока это касается отбора. Или внутренних перемещений, которые на верхний уровень даже не передаются. Но если встает задача планирования приемки, вопрос значительно усложняется. Казалось бы, все просто – известен объем склада и объем занятый товаром, есть план отгрузок и поставок, объем которых тоже известен. Считай! Однако, ERP, как мы уже говорили, ничего не знает об адресном пространстве, то есть, как этот объем разбивается.

Значит, считать должна WMS? Не тут-то было. Да, она может спланировать размещение того, что уже пришло, и она это делает. Она видит текущую картину пустого пространства и создает задания на его заполнение. Может ли она это сделать на месяц вперед? Нет. И даже на день не может (если конечно склад не полупустой, когда однозначно все поместится, но тогда и считать ничего не надо).

Дело в том, что конкретное время исполнения как заказов на приемку, так и заказов на отгрузку отличается от планового. Поэтому, предсказать, какова будет картина расположения товара на складе в каждый конкретный момент времени – это сложная динамическая задача, скорее всего переборная. Это значит, что, либо нужны серьезные дополнительные вычислительные мощности, либо надо упрощать постановку задачи. В упрощенном виде (по суммарному объему) ее вполне может делать и ERP. Традиции в данном случае ничего не говорят, их просто нет.

Границы систем в цепи поставок

Теперь рассмотрим границы систем «по горизонтали». Прежде чем товар попадет на склад, его надо закупить. Планированием закупок занимается, либо ERP, либо отдельная система управления закупками. Есть попытки решать эту задачу и в WMS, хотя это, безусловно, задача планирования. Но где бы ее ни решали, всегда используется одна и та же математическая модель оптимального заказа. Причем, затраты на хранение всегда константа, а это далеко не так. С точки зрения оптимизации – затраты на хранение и на складскую обработку рассматриваются здесь, как затраты на хранение. Каковы же они на самом деле?

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

Закупленный товар должен кто-то доставить. Это транспортная система. Традиция здесь одна – транспортные системы традиционно отстают по функциональности, да и вообще, в большинстве случаев еще не внедрены. Что есть по этому поводу в WMS? Со стороны входа, как правило, ничего. Со стороны выхода, в некоторых есть планирование маршрутов, но что такое маршрут? Это просто некоторая константа, некоторый параметр заказа, указывающий, что заказ этот должен попасть в конкретное транспортное средство. Не более того. Попытки сделать что-либо «более серьезное» очень часто и приводят к тому, что в базе данных складской системы учитываются государственные номера, фамилии водителей, грузоподъемность и т.п. А складу этой самой константы и достаточно, его задача поместить нужное количество груза в нужную машину.

После транспортной системы и со стороны входа и со стороны выхода стоят системы управления двором. Традиционно они, в половине случаев, включены в WMS, хотя yard management – отдельная задача. Да, она связана с готовностью заказов, да, она связана с погрузочно-разгрузочными воротами склада, с транспортной системой. Возможно, если один и тот же транспорт используется и на отгрузку и на приемку, то эта задача будет влиять на внутренние маршруты погрузочно-разгрузочной техники (в WMS) и на маршруты самого товара (естественно, там же), но все равно эта задача отдельная и логика у нее совсем не похожа на логику WMS. Другое дело, что в складских системах и интерфейсов для такого взаимодействия, тем более синхронного, нет.

Со стороны выхода между складом и двором могут находиться системы отгрузки (shipping) и упаковки (packing). Часто они включаются в WMS. В чем, собственно, проблема? В простейшем виде, базовом, WMS должна отгружать, формировать транспортные единицы, рассчитывать упаковку. Но иногда, и чем дальше, тем чаще, складу становится надобен какой-нибудь эксклюзивный функционал, касающийся отгрузки. Это может быть подбор подходящего транспорта, порядок укладки, различные комплекты и формы отгрузочных документов, различные этикетки и т.п. Предусмотреть все заранее разработчики просто не могут и тогда в систему «затягиваются» такие объекты, которые совсем на складские не похожи.

Ракурс внутренних границ

Мы рассмотрели все что «сверху», «снизу» и «сбоку». Немного остановимся еще на том, что внутри. Внутри тоже может быть много интересного. Например, учет операций персонала. То, что все операции заносятся в журнал, вызвано далеко не желанием суммировать его рабочее время, количество операций и т.п. Это сделано для возможности анализа ошибок и выявления проблем. Увидев такой «подарок судьбы» многие хотят перевести свои склады на сдельную оплату. Так в базе появляются расценки, нормы, списки персонала, смены, бригады и т.п. Кроме проблем, как правило, ничего из этой затеи не получается. Во-первых, сложно правильно разделить операции в разрезе норм их выполнения, во-вторых, персонал быстро отыскивает дорогие операции. В-третьих, сбор этой статистики – большие нагрузки на систему. Это тот же самый биллинг, о чем я писал выше.

Еще внутри часто живет АВС анализ. Счастье, что в большинстве случаев он спит. Если сбор статистики еще не так сильно загружает процессор, то вычисления уже кардинально. Сам метод вынуждает сначала все суммировать, потом сортировать и в зависимости от накопленной суммы присваивать товару категорию. С точки зрения потребностей, процесс этот – внутренний, и должен быть в WMS. А вот с точки зрения реализации – стоит ли жертвовать производительностью? Может быть, целесообразно вынести его наружу…

Отдельный вопрос – аналитика. Все, казалось бы, понятно. Складская аналитика должна быть в складской системе. Традиционно она там и находится. И традиционно тормозит всю систему. Это противоречие не только WMS, а вообще всех систем, использующих реляционные базы. Системы делятся на транзакционные OLTP и аналитические OLAP. Главный принцип первых систем – отсутствие избыточности, любая информация должна храниться в одном месте. Вторые же, наоборот, специально вводят избыточность для возможности быстрого получения отчетов в любых разрезах.

Создать «два в одном» – невозможно, да и не нужно. Всегда можно поставить их рядом. Исполняющая система – в своей базе, аналитика – в своей. А если еще и аналитик умеет пользоваться инструментарием, а не зовет программиста каждые 15 минут, то это будет наиболее правильный подход. Пока же – имеем то, что имеем.

Вывод. 

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