Требования к WMS или как правильно оформить документацию

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

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

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

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

«В нашем справочнике – более 300 тысяч материалов, из которых 20% - активные. Многие артикулы являются многокомпонентными, и это вызывает необходимость формировать задания на склад на их сборку из компонентов, либо разборку – для отгрузки какого-то компонента, отсутствующего в непосредственном виде на складе. Осложняется все еще тем, что состав некоторых материалов, несмотря на один и тот же артикул, включает в себя абсолютно разные компоненты. Раньше для этих целей мы использовали функционал нашей ERP. На этапе выбора WMS, мы уделили большое внимание именно вопросам интеграции, но в результате поставщик предложил использовать функционал WMS для решения указанных задач, а механизм интеграции, наоборот, сильно упростили. Работа сотрудников стала намного проще, число допускаемых ошибок сократилось в несколько раз, а скорость работы существенно возросла. Вряд ли мы могли предугадать такой ход событий на этапе выбора системы и команды внедрения, поэтому можем лишь констатировать, что далеко не всегда тот эффект, который мы предполагаем получить, является действительно лучшим», - отмечает Игорь Мешков, руководитель проектов компании «Макслевел», подтверждая тот факт, что уже устоявшийся, стабильный алгоритм работы может получить значительные улучшения за счет применения стандартных функциональных возможностей WMS.

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

«Для нас крайне важным пунктом было обеспечение возможности работы персонала по пик-листам. Сохранение привычного для сотрудника инструмента действительно дало возможность перейти на использование функционала WMS в очень короткие сроки, но необходимость обработки исключительных ситуаций при помощи информационных киосков и контролеров не позволяла увеличить производительность более, чем на 20%», - комментирует директор по логистике компании «Велес Групп» Юрий Сырцов. - «Примерно в течение полугода мы производили переход от пик-листов к радиотерминалам, и этот шаг позволил нам исключить узкие места нашего процесса, дав возможность повысить производительность персонала еще примерно на 10%. На новом объекте мы запускали систему сразу с использованием терминалов, используя уже наработанную лучшую практику», - резюмирует Юрий Сырцов.

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

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

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

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

Если же мы рассмотрим применение системы правил, то она позволяет рассмотреть каждый процесс без жесткой привязки к другим процессам. Например, вполне реализуема без какого-либо программирования и доработок такая схема: «Если во время приемки для товара X было указано отклонение Y, то его необходимо отправить в зону контроля».

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

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

Если технология работы склада может оперативно меняться, то возможность реализовать и использовать собственную модель для специфических настроек, порой, бывает крайне необходима. К примеру, при использовании довольно редких и не всегда очевидных атрибутов в системе правил («пополнение рекламных материалов с габаритами единицы, превышающими 0,2 кубометра, на отдельный напольный участок набора», «стикеровка адаптационными этикетками всех товаров, отгружаемых украинским клиентам»).

Резюмируя вышесказанное, можно выделить несколько основных рекомендаций для составления требований к поставщикам WMS:

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

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