Автоматизация склада. Система-локатор или WMS?

Все системы, которые используются сегодня на складах, условно можно разделить на три класса: учетные, системы-локаторы (IMS или ILS) и системы управления складом (WMS).

Учет и контроль

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

• прием и отпуск товара на складе;
• подготовка, печать и выдача отчетов о движении товаров по складу;
• инвентаризация товарных остатков.

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

– Дело в том, что в основе учетных систем лежит бухгалтерская модель, – поясняет В. БАРАНОВСКИЙ. – Грубо говоря, это просто автоматизированные конторские приходно-расходные книги, которые предназначены для того, чтобы отслеживать, сколько товара на склад пришло, сколько ушло и сколько есть в наличии. Их логика не имеет ничего общего со складскими процессами – это понятия, которые находятся в разных плоскостях. Отсюда – и ограниченная функциональность таких систем, и низкая помехоустойчивость, связанная с нарушением логики бизнес-процессов.

Отслеживать, что происходит с товаром на складе, можно по статусу сформированных в учетной системе документов на выполнение операций. Документ может иметь, например, такие статусы:

• запланирован – документ создан, работы с ним не начаты, и автор (например, менеджер по продажам) может вносить любые изменения;
• выполняется – на складе начата работа по выполнению задания, и теперь корректировки может вносить только оператор склада. Но подтвердить получение товара по документу с этим статусом грузополучатель еще не может;
• завершен – задание выполнено, оператор склада грузоотправителя теряет право вносить изменения в документ (собственно, редактирование документа заблокировано всем пользователям), а оператор склада грузополучателя получает возможность подтверждения приема товара.

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

Конечно, к учетным системам склады так или иначе приспосабливаются, однако ряд проблем все равно остается. Таких, к примеру, как перепроведение документов задним числом, которое обычно делают не материально ответственные люди. Или как вопросы синхронизации при работе в распределенной базе – когда, допустим, старая версия документа «затирает» новую при очередной синхронизации данных.

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

– Интересно бывает увидеть на остатках, допустим, минус 10 штук, – приводит пример эксперт. – Получается, что если сейчас на склад придет 10 единиц товара, мы их положим в ячейку, и они аннигилируются? Тогда в графе «остатки» будет ноль, и все станет нормально. И как бы мы ни пытались избежать подобных проблем, «обвешивая» систему новыми приложениями, полностью устранить их практически невозможно – корень их скрыт в самом ядре программы, которая оперирует исключительно артикулами и их количеством. Образно говоря, сколько «Жигуль» не тюнингуй, он все равно будет «Жигулем». Даже если туда поставить закись азота, разные брызговики, дополнительные кнопки, сигнализацию и т.д., быстрее он не поедет и больше людей не перевезет.

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

Системы-локаторы

Несколько больше возможностей дают так называемые системы-локаторы. Встречаются два их названия: Information Management System (IMS) – система управления информацией, и Information Location System (ILS) – система информирования о расположении. В их основе – все та же бухгалтерская модель, но к ней уже добавлена ячеистая структура склада (код аналитического учета – адрес ячейки хранения) и доработан пользовательский интерфейс.

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

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

– Есть возможность также наложить на ячейки ограничения по размерам и весу , – продолжает В. БАРАНОВСКИЙ. – И если когда-нибудь произойдет чудо и 100% товаров будут правильно взвешены и обмеряны, система сможет выдавать более качественные рекомендации, какой товар куда поставить. Но наличие полной точной информации о весе и габаритах по всему ассортименту – скорее исключение, чем правило. Обычно корректной информации – порядка 80%, а дальше против нас работает закон Парето. А соответственно, и функция пополнения ячеек «сбоит», если она использует весогабаритные характеристики.

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

Когда автоматизированная система работает с грузовыми единицами, она может объединить некоторый товарный запас, какое-то количество разных артикулов (сочетание артикул/количество) в одну складскую единицу хранения и дальше обрабатывать ее как целое, т.е. выдавать исполнителю команду на действия не с товаром, а с грузовым местом. В IMS этого пока нет, поэтому дополнительная складская обработка, т.е. такие операции, как, например, стикеровка, комплектация наборов или учет товаров, состоящих из нескольких единиц, ей не по зубам. К примеру, лучше не пытаться разработать алгоритм на перемещение кровати, состоящей из трех предметов (ножки в одном ящике, рама в другом, матрас в третьем), поскольку это разные артикулы, размещенные в разных ячейках. И это, понятно, затрудняет возможность полноценного контроля перемещения товара.

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

Курс на сближение

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

– Фактически получается, что в систему-локатор встроен дополнительный элемент в виде оператора, который заполняет дыры в бизнес-процессах путем нажатия разных кнопок, – отмечает В. БАРАНОВСКИЙ. – Это необходимо именно потому, что локаторы работают не с грузовыми единицами (поддонами или коробками), а с товарными запасами: артикул/количество. И если ориентироваться по этому признаку, приходится признать, что некоторые так называемые WMS на самом деле таковыми не являются. В т.ч. программные продукты для склада, разработанные на базе 1С, скорее можно отнести к локаторам. Их функционал значительно расширен, но «выросли» они из учетной системы и опираются на ее логику.

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

Он создает привязку-разрешение: данную категорию товара хранить только в данной группе ячеек, и если сотрудник получает запрет на работу с данной категорией товара, ему автоматически блокируется доступ на соответствующую территорию склада и к соответствующим документам.

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

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

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

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

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

– Есть очень удобный блок учета по разным единицам измерения с возможностью переупаковки одной единицы в другую, – акцентирует внимание В. БАРАНОВСКИЙ. – В WMS, к примеру, довольно сложно получить 10 т сахара, расфасовать его в мешки с переменным весом, а затем отгрузить часть товара в мешках, а часть – в килограммах. Учетная система с такими вещами справляется гораздо легче, потому что в исходном бухгалтерском ядре этот блок был когда-то доведен до совершенства.

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

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

Разумная достаточность

Подводя черту, эксперт еще раз перечислил операции, которые системы-локаторы выполняют с приемлемым уровнем качества.

Приемка товара:

• планирование приемки;
• контроль качества (как минимум, кондиция/некондиция, но параметры можно дополнить);
• переупаковка (изменение размерности единицы хранения);
• маркировка – под вопросом, но теоретически возможно, если «поиграть» со статусами документов;
• формирование всей приемной документации.

Размещение – по определенным критериям и правилам, ориентируясь на ту систему разрешений и запретов, которой в системе связаны товар и ячеистая структура склада:

• планирование;
• автоматический поиск ячеек для размещения.

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

Комплектация и отгрузка:

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

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

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

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

– Единственный способ корректно построить биллинг в локаторе – не строить его там вообще, – уверен В. БАРАНОВСКИЙ. – Лучше вынести его в отдельную опцию и назначить ответственного за корректный старт каждой операции и точный подсчет времени ее выполнения. Примерно таким же путем решается вопрос с учетом всех операций, при которых не меняются ни артикулы, ни количество (стикеровка, создание наборов и т.п.) – каждый раз приходится создавать дополнения, в которые отчетные данные о выполненных работах обычно вбиваются вручную.

Самое неприятное – что эти данные легко можно подтасовать, поскольку с ядром системы они никак не коррелируют. Если в WMS можно задать условие, что из машины не может быть выгружено больше 32 паллет (ну, пусть максимум 64), то в локаторе, где эта опция служит только для сбора информации, можно записать и 320 поддонов. Или указать, что весь товар пришел россыпью, а не на паллетах, потому что так выгоднее для зарплаты.

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

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

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

Коробочные решения

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

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

Еще в начале 2000-х, когда логистика в Украине была в зачаточном состоянии, коробочные решения были просто находкой: не умея практически ничего, получить готовый бизнес-процесс, который гарантированно работает – это просто супер. Однако сейчас ситуация в корне изменилась. За последние лет шесть этап унификации и стандартизации бизнес"процессов многие компании уже пережили. Сегодня же, чтобы выжить на рынке, каждая из них ищет свои конкурентные преимущества, и стандартные решения в такой ситуации становятся дополнительным ограничением. А если начать дорабатывать «коробку», она вполне может рассыпаться.

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

К преимуществам коробочных решений однозначно относятся невысокая стоимость и короткие сроки внедрения, а также хорошая hot-line поддержка с большим количеством операторов coll-центра, которые, по крайней мере, ответят на звонок 24 часа в сутки 7 дней в неделю.

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

А вот простота «коробки», по мнению специалистов, не всегда является преимуществом – она может спровоцировать доработки, которые система «не потянет». Типичные недостатки коробочных версий и возможные пути их нивелирования Виктор изложил в виде Табл. 1. И уточнил, что для того, чтобы убедиться в качестве программного продукта, порой недостаточно пообщаться по телефону с менеджером компании, на которую ссылается поставщик:

– Дело в том, что иногда людям неудобно признаваться, что их обманули, что они потратили деньги и не получили результата. Некоторые менеджеры предпочитают делать хорошую мину при плохой игре: «Да-да, все хорошо, все работает! Приехать посмотреть? Да нет, у нас сейчас реконструкция, мы никого не принимаем!» Но нужно действительно ехать и смотреть – только так вы можете убедиться, что в других компаниях продукт успешно работает. Устные комментарии, что «все нормально», или просто весомый список из 200 «компаний-наших клиентов» – еще не повод для принятия решения.

Кстати, поставщики коробочных решений активно пользуются тем, что люди не любят признавать свои ошибки. Они требуют обычно минимум 70–80% предоплаты, и это становится для них своего рода гарантией, что клиент не остановит проект даже в случае явной неудачи. Не каждый имеет мужество признать, что деньги потрачены впустую, многие предпочитают довести проект до конца, доплатить оставшиеся 20–30% и потом некоторое время притворяться, что все нормально.

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

• покрытие требуемого функционала должно быть не менее 70%, причем доработки могут касаться только каких-то второстепенных, сервисных функций и ни в коем случае не должны затрагивать ядро системы;
• на рынке продукт должен быть представлен не менее 2 лет, количество успешных внедрений – не менее 10. Если купить новую, пусть даже более продвинутую версию, велики шансы стать тем самым «подопытным кроликом», на котором поставщик будет «обкатывать» систему;
• наличие авторизированных представительств в регионе – лучше всего, чтобы сервисный инженер был в пределах 1-дневной доступности. Удаленный доступ положение не спасает, поскольку пользователи системы обычно не имеют достаточной квалификации, чтобы самостоятельно диагностировать возникающие проблемы;
• продукт должен быть масштабируемый – так, чтобы в течение какого-то времени он поспевал за ростом бизнеса, открытием новых филиалов и пр.;
• большим плюсом является возможность опционной настройки логики продукта – например, чтобы в сезон и в несезон, когда меняются ассортимент и объемы складской обработки, можно было задействовать разные алгоритмы;
• и необходимое требование – наличие готовых интерфейсов взаимодействия с другими программными продуктами, чтобы не возникало проблем с обменом данными.

Резюме

– Локаторы ныне не те, что раньше, – делает однозначный вывод В. БАРАНОВСКИЙ. – По функционалу они все больше приближаются к WMS, а иногда «осваивают» даже те функции, которые не во всех WMS реализованы. Так что вполне можно надеяться, что уже в ближайшем будущем два класса систем фактически сольются в один, и потребители будут оценивать их не по исходной модели, которая «зашита» в ядре, а по полноте функционала и степени автоматизации, которую тот или иной продукт в состоянии обеспечить.