Cистемы управления складом
Выбор, внедрение и эксплуатация

№ 2 апрель 2008

Границы задач WMS

◄... к началу статьи

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

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

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

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

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

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

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

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

Границы систем «по горизонтали»

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

С точки зрения оптимизации объема заказа или выбора точки заказа и затраты на хранение, и затраты на складскую обработку, рассматриваются здесь, как затраты на хранение. Но на пустом складе затраты на хранение будут большими, так как в них надо включать постоянные издержки на содержание самого склада (чем меньше запас – тем расходы на единицу товара больше). С заполнением склада затраты на каждую единицу товара падают, но возникает влияние другого фактора – затрат на обработку. Абсолютно все складские операции становятся более трудоемкими и выполняются медленнее.

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

WMS и транспортные системы

Что касается транспортных систем, то традиция здесь одна: они отстают функционально, а в большинстве случаев еще не внедрены. Что есть по этому поводу в WMS? Со стороны входа, как правило, ничего. Исключение – параметр планируемой даты и времени поставки, который загружается из ERP и используется как справочные данные для диспетчера приемки. Там, где интенсивность поставок небольшая, это работает. Где аврал – платят за простой транспорта.

Транспортная система (с мониторингом местоположения транспорта) должна выдавать вместо статичных плановых даты и времени, передаваемых из ERP, динамический прогноз прибытия транспорта под разгрузку. Должен быть соответствующий интерфейс между транспортной и складской системой. В самой же WMS (в связке с YMS) тоже нужен механизм, позволяющий использовать эту информацию. Должен быть некоторый экспертный модуль, который на основе статистики предыдущих приемок похожих заказов и стоимостей простоя конкретного транспорта оптимизировал бы управление ресурсами склада таким образом, чтобы поддерживать необходимую пропускную способность приемки. Где и как пройдут границы систем в этой задаче, пока говорить преждевременно — постановка задачи и ее реализация всегда вносят свои коррективы.

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

С точки зрения минимизации перемещений ТС существует некоторый оптимальный маршрут, под который необходимо выстроить порядок загрузки этого ТС. Соответственно этот порядок должна поддерживать WMS и ко времени прибытия ТС сформировать заказы. Еще должна быть учтена оптимальная загрузка транспорта. Каков будет объем и вес всего, что мы хотим поместить в кузов, заранее неизвестно, есть только прогнозы. Поэтому возникает обратная связь с транспортной системой, которая динамически должна менять маршруты в зависимости от реального объема заказов. Если принять во внимание, что все это должно работать в совокупности с вероятностными параметрами времени прибытия транспорта и сборки заказов, то мы получим очень сложную задачу, которая будет решаться в будущем и очень дорого. Соизмеримо со стоимостями WMS и ТМS. А пока это «не складская задача».

Управление прилегающей территорией

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

Системы отгрузки и упаковки

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

Отчасти это дочерняя проблема. Все эти системы – WMS cо стороны выхода, Shipping, Packing, Yard Management, TMS – тесно связаны между собой и с ERP. Но ERP и не хочет с ними связываться. Ее модель не соответствует по объектам, событиям и статусам – моделям этих систем. Стóит же она нередко дороже всех этих систем вместе взятых. Стоимость внесения в нее изменений – соответствующая.

Простой пример: распределительный центр торговой сети. Множество заказов во множество магазинов. На одном ТС может быть отправлено несколько заказов так же, как и один заказ может быть отправлен на нескольких машинах. С точки зрения системного анализа – это отношение «многие ко многим». Решается через промежуточный объект, который к двум исходным будет относиться как «один ко многим». Попробуем ввести его в ERP.

Вариант 1. Разработчики ответят, что это «складская задача» (хотя относится к транспортировке).

Вариант 2. Разработчики согласятся внедрить его в ЕRP систему, но он туда не поместится. Сначала может показаться, что все идеально работает, но в процессе работы выяснится, что существует множество ограничений по использованию объекта, ошибок, предупреждений. В результате окажется, что действия, которые пользователь в принципе имеет возможность выполнить, выполнять запрещается, потому что есть вероятность выхода системы из строя. Некоторые «именитые» ERP даже не знают, что давно изобретены такие привычные всем разработчикам баз данных транзакции…

Другие «эксклюзивные кнопки»

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

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

Аналитика в WMS

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

Выводы

Обсудить на Форуме

На этом сайте нет форума. Автор является активным участником Клуба Логистов http://logist.ru, на форуме которого можно пообщаться со специалистами.