Эксперт по внедрению систем управления складом (WMS)

Как избежать ошибок при составлении перечня функциональных требований к системе WMS

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




Составление перечня функциональных требований к системе управления складом (WMS)

Как правильно составить функциональные требования к системе WMS

Ошибки при составлении функциональных требований к системе управления складом (WMS)

Составление перечня ФТ происходит на этапе выбора системы WMS. Этот перечень рассылается потенциальным поставщикам систем для того, чтобы они смогли объективно оценить стоимость настроек, разработок и стоимость внедрения системы на автоматизируемом складе. По этой причине, перечню ФТ следует уделить максимум внимания.


Целью внедрения систем WMS является эффективное управление процессами и ресурсами склада. 


Таки образом, ФТ должны отражать тот функционал, который необходим именно для удовлетворения функциональных потребностей (дефицитов) в управлении складскими процессами и ресурсами. 


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

Такой подход непременно приводит к негативным последствиям: 

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


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


заявленные ФТ не будут покрывать потребности всех складских бизнес-процессов. 

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


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

Пример неправильно составленных ФТ к системе WMS

Это – скриншот фрагмента реального документа, на основании которого крупный производитель продуктов питания осуществлял выбор системы WMS.


Что в нем не так? Честно говоря, всё.

Например, что означает функциональное требование «Грузы и запасы»? Любой разработчик системы WMS поймет его, как наличие в системе грузов и запасов, не более, т.к. данное требование не достаточно детализировано. Истина в том, что для ведения грузов и запасов не обязательно внедрять систему WMS.

Другое требование: «Ячейки». Что можно понять из данного пункта? Максимум то, что в системе должны быть ячейки. Но ведь ячейки можно вести разными способами: в MS Excel, MS Access, в конце концов на бумаге, однако это не будет системой управления складом.

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

Ниже я приведу пример того, как должны выглядеть эти два требования.

Итак, как же правильно составить перечень функциональных требований к системе WMS?


Во-первых: обеспечить достаточную детализацию требований и исключить разночтения;


Во-вторых: включить в перечень ФТ только те требования, которые соотносятся с целями внедрения системы WMS на складе, т.е. направлены на автоматизацию управления складскими процессами и ресурсами (мне, например, приходилось в перечне ФТ к системе WMS встречать требования по автоматизации перевозок или планированию закупок, что никоим образом не относится к складским бизнес-процессам и целям внедрения систем WMS);


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


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


В-пятых: не выдавать функциональный объем вместо функциональных требований.

Хотелось бы отдельно остановиться на функциональном объеме.

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


Функциональный объём – это набор функциональных возможностей системы WMS, входящих в состав внедряемой системы. Иными словами, функциональный объём – это совокупность бизнес-процессов, функций и операций, автоматизация которых предполагается за счёт внедрения системы управления складом.

Функциональный объём

Функциональные требования

Остановимся на группах складских бизнес-процессов. К ним относят следующие:

  • Ведение организационной структуры склада и нормативно-справочной информации;
  • Входящие процессы;
  • Внутренние процессы;
  • Исходящие процессы;
  • Отчетность, аналитика, печатные формы.

Каждая группа бизнес-процессов содержит в себе конкретные бизнес-процессы, например:


Ведение организационной структуры склада и нормативно-справочной информации:

  • Общие настройки склада;
  • Настройка и ведение топологии;
  • Ведение справочника видов операций;
  • Настройка пользователей и ресурсов;
  • Ведение справочника ТМЦ;
  • Ведение справочника типов тары;
  • Ведение справочника тары;
  • Ведение справочника контрагентов.

 

Входящие процессы:

  • Приемка готовой продукции;
  • Приемка возвратов готовой продукции;
  • Размещение готовой продукции;
  • Размещение возвратов готовой продукции;
  • Приемка сырья;
  • Приемка возвратов сырья;
  • Размещение сырья;
  • Размещение возвратов сырья.

 

и так далее.

Ведение орг.структуры склада
Складские процессы

Перечень групп бизнес-процессов с указанием их содержимого, как на примере выше, – это и есть функциональный объем внедрения системы WMS. Он позволяет понять, какие конкретно бизнес-процессы есть/будут на складе, т.е. показывает объем автоматизации системой WMS (для составления функционального объема можно воспользоваться Национальным стандартом Российской Федерации «Системы управления складом. Функциональные требования», ГОСТ Р 59282-2020. Обзор документа можно найти здесь). 

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

 

  • Настройка и использование видов заказов для входящих поставок и связанных с ними правил приемки ТМЦ: стандартная поставка, возврат и т.д.;
БП-ФО-ФТ
  • Настройка параметров для автоматического назначения ворот приемки;
  • Использование внешних идентификаторов контейнеров (тары) при приемке;
  • Использование внутренних (сгенерированных в WMS) идентификаторов контейнеров (тары) при приемке;
  • Получение информации о планируемой входящей поставке ГП с данными об SKU, партии, сроке годности;
  • Приемка моно-паллет;
  • Приемка микс-паллет;
  • Возможность ручного ввода либо подтверждения партии, срока годности ТМЦ при приемке
  • Возможность генерирования партии в WMS при приемке с последующей передачей данных в ERP;
  • Обработка расхождений: автоматическое сравнение запланированного и фактически принятого количества ТМЦ

 

и так далее.

 

Из примера видно, что конкретно должно выполняться в системе в рамках бизнес-процесса. Это и есть функциональные требования.

Вернемся к показанному выше примеру с ячейками и грузами.

Функциональное требование «Грузы и запасы» лучше разделить на два бизнес-процесса:

  1. Ведение справочника товарно-материальных ценностей;
  2. Ведение справочника типов тары.

 

К первому бизнес-процессу будут предъявляться примерно следующие требования:

  • Получение справочника ТМЦ из системы ERP посредством интеграции;
  • Учет всех данных, характеристик и атрибутов, необходимых для обработки, хранения и отгрузки ТМЦ со склада;
  • Учет ТМЦ в разных единицах измерения (штука, короб, паллета, масса) с автоматическим пересчетом из одной единицы измерения в другую;
  • Ведение аналитики о классе оборачиваемости ТМЦ: А, В или С;
  • Получение из ERP и учет данных по оборачиваемости ТМЦ;
  • Учет данных о штриховых кодах ТМЦ для каждой единицы измерения конкретной товарной позиции

 

и т.д.

Что касается «Ячеек», то здесь в качестве бизнес-процесса будет выступать "Настройка и ведение топологии склада". К этому бизнес-процессу предъявляются следующие требования:

  • Настройка структуры топологии склада;
  • Настройка и использование разных типов хранения: напольное, стеллажное и т.д.;
  • Создание и редактирование ячеек;
  • Настойка свойств и характеристик ячеек;
  • Зонирование склада по видам операций: зона приемки, транзитные (буферные) ячейки, зона паллетного хранения, зона хранения ТМЦ на контроле качества, зона коробочной комплектации, зона контроля, зона экспедиции, ворота;
  • Зонирование склада по товарным группам с учетом ограничений по режиму хранения и правил обособленного хранения;
  • Ведение типов ячеек (мест хранения): паллетные, коробочные, штучные;
  • Настойка участков хранения по классу оборачиваемости ТМЦ: А, В, С;
  • Настройка доступа к ячейкам, зонам, участкам, типам ячеек для пользователей и видов складской техники

 

и т.д.

Итак, для получения объективной оценки стоимости внедрения системы WMS на основании детализированного перечня функциональных требований необходимо:

  1. Определить цели внедрения системы WMS;
  2. Определить функциональны объем и составить перечень бизнес-процессов;
  3. По каждому бизнес-процессу определить функциональные требования, т.е. указать перечень функций, которые должны содержаться в системе WMS для обеспечения выполнения бизнес-процесса;
  4. При составлении перечня ФТ исходить из будущих, а не текущих бизнес-процессов;
  5. При составлении функциональных требований не исходить из функционала конкретной системы WMS.

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

 

Для качественного составления функциональных требований к системе WMS можно воспользоваться услугами опытного консультанта, что позволит в короткие сроки получить детально проработанные ФТ и обеспечить объективный выбор системы WMS.

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