Одним из самых важных этапов проекта внедрения системы 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 написано в этой статье);
В-пятых: не выдавать функциональный объем вместо функциональных требований.
Хотелось бы отдельно остановиться на функциональном объеме. На моей практике более 90% компаний при составлении запроса предложения на внедрение системы WMS выдают функциональный объем вместо перечня функциональных требований и это – ошибка, которая приводит к тем негативным последствиям, о которых написано выше.
Функциональный объём – это набор функциональных возможностей системы WMS, входящих в состав внедряемой системы. Иными словами, функциональный объём – это совокупность бизнес-процессов, функций и операций, автоматизация которых предполагается за счёт внедрения системы управления складом.
Остановимся на группах складских бизнес-процессов. К ним относят следующие:
- Ведение организационной структуры склада и нормативно-справочной информации;
- Входящие процессы;
- Внутренние процессы;
- Исходящие процессы;
- Отчетность, аналитика, печатные формы.
Каждая группа бизнес-процессов содержит в себе конкретные бизнес-процессы, например:
Ведение организационной структуры склада и нормативно-справочной информации:
- Общие настройки склада;
- Настройка и ведение топологии;
- Ведение справочника видов операций;
- Настройка пользователей и ресурсов;
- Ведение справочника ТМЦ;
- Ведение справочника типов тары;
- Ведение справочника тары;
- Ведение справочника контрагентов.
Входящие процессы:
- Приемка готовой продукции;
- Приемка возвратов готовой продукции;
- Размещение готовой продукции;
- Размещение возвратов готовой продукции;
- Приемка сырья;
- Приемка возвратов сырья;
- Размещение сырья;
- Размещение возвратов сырья.
и так далее.
Перечень групп бизнес-процессов с указанием их содержимого, как на примере выше, – это и есть функциональный объем внедрения системы WMS. Он позволяет понять, какие конкретно бизнес-процессы есть/будут на складе, т.е. показывает объем автоматизации системой WMS (для составления функционального объема можно воспользоваться Национальным стандартом Российской Федерации «Системы управления складом. Функциональные требования», ГОСТ Р 59282-2020. Статья с обзором документа доступна по ссылке).
Вместе с тем, под каждым бизнес-процессом могут присутствовать такие функциональные требования, которые существенно повлияют на оценку внедрения. Например, приемка готовой продукции может содержать такие требования к функционалу:
- Настройка и использование видов заказов для входящих поставок и связанных с ними правил приемки ТМЦ: стандартная поставка, возврат и т.д.;
- Настройка параметров для автоматического назначения ворот приемки;
- Использование внешних идентификаторов контейнеров (тары) при приемке;
- Использование внутренних (сгенерированных в WMS) идентификаторов контейнеров (тары) при приемке;
- Получение информации о планируемой входящей поставке ГП с данными об SKU, партии, сроке годности;
- Приемка моно-паллет;
- Приемка микс-паллет;
- Возможность ручного ввода либо подтверждения партии, срока годности ТМЦ при приемке
- Возможность генерирования партии в WMS при приемке с последующей передачей данных в ERP;
- Обработка расхождений: автоматическое сравнение запланированного и фактически принятого количества ТМЦ
и так далее.
Из примера видно, что конкретно должно выполняться в системе в рамках бизнес-процесса. Это и есть функциональные требования.
Вернемся к показанному выше примеру с ячейками и грузами.
Функциональное требование «Грузы и запасы» лучше разделить на два бизнес-процесса:
- Ведение справочника товарно-материальных ценностей;
- Ведение справочника типов тары.
К первому бизнес-процессу будут предъявляться примерно следующие требования:
- Получение справочника ТМЦ из системы ERP посредством интеграции;
- Учет всех данных, характеристик и атрибутов, необходимых для обработки, хранения и отгрузки ТМЦ со склада;
- Учет ТМЦ в разных единицах измерения (штука, короб, паллета, масса) с автоматическим пересчетом из одной единицы измерения в другую;
- Ведение аналитики о классе оборачиваемости ТМЦ: А, В или С;
- Получение из ERP и учет данных по оборачиваемости ТМЦ;
- Учет данных о штриховых кодах ТМЦ для каждой единицы измерения конкретной товарной позиции
и т.д.
Что касается «Ячеек», то здесь в качестве бизнес-процесса будет выступать «Настройка и ведение топологии склада». К этому бизнес-процессу предъявляются следующие требования:
- Настройка структуры топологии склада;
- Настройка и использование разных типов хранения: напольное, стеллажное и т.д.;
- Создание и редактирование ячеек;
- Настойка свойств и характеристик ячеек;
- Зонирование склада по видам операций: зона приемки, транзитные (буферные) ячейки, зона паллетного хранения, зона хранения ТМЦ на контроле качества, зона коробочной комплектации, зона контроля, зона экспедиции, ворота;
- Зонирование склада по товарным группам с учетом ограничений по режиму хранения и правил обособленного хранения;
- Ведение типов ячеек (мест хранения): паллетные, коробочные, штучные;
- Настойка участков хранения по классу оборачиваемости ТМЦ: А, В, С;
- Настройка доступа к ячейкам, зонам, участкам, типам ячеек для пользователей и видов складской техники
и т.д.
Итак, для получения объективной оценки стоимости внедрения системы WMS на основании детализированного перечня функциональных требований необходимо:
- Определить цели внедрения системы WMS;
- Определить функциональны объем и составить перечень бизнес-процессов;
- По каждому бизнес-процессу определить функциональные требования, т.е. указать перечень функций, которые должны содержаться в системе WMS для обеспечения выполнения бизнес-процесса;
- При составлении перечня ФТ исходить из будущих, а не текущих бизнес-процессов;
- При составлении функциональных требований не исходить из функционала конкретной системы WMS.
Составление перечня функциональных требований – это процесс, требующий участия не только склада, но и смежных подразделений. Недостаточная детализация или требования, не относящиеся к функционалу склада, приведут к неверному пониманию задачи поставщиком системы и неверной оценке внедрения.
Для качественного составления функциональных требований к системе WMS можно воспользоваться услугами опытного консультанта, что позволит в короткие сроки получить детально проработанные ФТ и обеспечить объективный выбор системы WMS.
Оригинал статьи:
https://wms.su/consulting/oshibki-pri-sostavlenii-perechnya-funkcionalnih-trebovaniy-k-wms/
