Олег Вайнберг, IT-директор сети "Кей" 
 

 

 

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

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

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

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

Второй подход. Зонированный склад. Все помещение заранее разбито на зоны и каждый товар раз и навсегда приписан к определенному месту. Склад строят заранее исходя из номенклатуры.

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

Третий подход. Я всегда называл это «WMS или WMS I», но тут меня просветили, что лучше применять термин «склад ячеистого хранения». В этом случае система учитывает, что и где на складе лежит, но этим не управляет. Именно поэтому, по мнению специалистов, в корне неправильно называть такой метод WMS — хоть с цифрой, хоть без нее. Компьютерная система совершенно пассивна. Она просто хранит информацию. Все места хранения (стеллажи, полки, зоны) имеют уникальные номера. Разместив единицу хранения, оператор фиксирует в системе номер места. Знание системы о том, что и где лежит, позволяет оптимизировать маршрут сбора и размещения. В принципе можно положить в одну ячейку несколько товаров. Это повысит коэффициент заполнения склада, но уменьшит точность сборки и потребует, чтобы оператор знал товар «в лицо». Один и тот же товар может оказаться на разных полках. Это крайне нежелательное явление называется «фрагментация». При данном подходе система ее не отслеживает и не минимизирует. Степень фрагментации остатков товара зависит целиком от разумности операторов.

Четвертый подход. WMSII, иногда называемый просто WMS. Собственно Система управления складом, причем главное слово в этом словосочетании — «управление». Эта система знает габаритные размеры товара, некоторые правила размещения и, с помощью достаточно изощренных алгоритмов, пытается оптимизировать хранение товара, исходя из заданных критериев и ограничений. Таким образом, система сама предписывает оператору, что и на какую полку положить.

Недостатки: при таком подходе достигается самый низкий коэффициент заполнения склада.

Преимущества:

— Система никогда не положит макароны с мылом и не разместит пиво над мешками с сахаром.

— Наиболее востребованный товар, скорее всего, окажется ближе к проходам и лифтам.

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

Пятый подход. Склада нет вовсе. Это JIT (Just In Time — точно вовремя), подход, столь любимый японцами. Или еще что-нибудь, утверждающее, что товар надо не складировать, а вот просто он должен «сам» оказаться в нужное время и в нужном месте. Поставщики должны все подвозить ровно со скоростью продажи или использования прямо к месту продажи или использования. Недостаток этого способа один. Никто не знает, как это сделать в условиях Российских просторов, дорог, дураков и таможенников.

В эволюции склада компания, как правило, проходит все этапы — от упомянутой кладовщицы Марьи Петровны» к WMS и до WMSII. Но надо ли идти до конца? И где нужно остановиться? Для каких товаров этот путь подходит,  а для каких нет? Не являясь экспертом в области «складостроения», я не могу сказать, что для «финтифлюшки номер 7» подходит ячеистое хранение, а для «штуковины номер 5» — напольное. Однако у меня есть личный опыт внедрения разных систем в одной и той же компании. И я практически попробовал первые  четыре из пяти перечисленных методов.

Из практики

Проект внедрения ERP в наших распределительных центрах (РЦ), в состав которого  входил склад ячеистого хранения, проходил в 2005 году. В качестве консультантов и поставщиков решения привлекалась компания Columbus. Проект длился 9 месяцев и завершился внедрением в штаб-квартире системы управления движением товаров, в том числе управлением центральным складом на базе программного продукта Axapta 3.0.

Почему Axapta и почему Columbus? Во-первых, будучи лидером петербургского рынка в своей области, мы не очень верим в best practice. Как мудро сказал один из моих приятелей, best practice способен сделать из лузера середняка. Если бы best practice позволял стать лидером, все бы ими уже были. Во-вторых, ритейл — самый динамичный вид бизнеса, и нам нужна была гибкая система, которая бы гарантировано нас не ограничивала. Columbus же сумел показать, что у них есть технологии и команды, которые позволяют быть уверенными в успешном завершении проекта.

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

Но пуск дался не легко. Первая проблема, которая возникла во время пуска, — это стресс персонала и отсутствие навыков работы в новой системе. Вывод: нужно учить персонал, не жалея денег, сил и времени. Конечно, мы проводили обучение. Но его оказалось недостаточно. Надо организовывать учебные классы и зоны, набирать дополнительный персонал и платить ему зарплату, а также оплачивать обучение. Это — окупится.

Дальше, недооценка внешних воздействий. Вывод: надо заранее прописывать требования к поставщикам и заранее, до внедрения системы, начинать отстраивать взаимоотношения. В момент пуска, когда и так все было достаточно напряженно, пришел безумный объем перемешанного груза, причем там вообще не было штрих-кодов. Мы оказались в положении человека, который купил классный японский шуруповерт, а ему принесли ведро гвоздей.

Еще одной проблемой стала недооценка внутренней коммуникации. В пусковой момент возникают особенно жесткие требования к коммуникации. Немаркированный груз, о котором я говорил, принимался крайне медленно. И закупщики, видя отсутствие товара, заказали его еще два раза. Товар привезли. После чего его в три смены разгребали. Это произошло по ясной причине – из-за отсутствия коммуникации между складом и отделом закупок.

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

Что мы получили с точки зрения склада? Классический WMS, в котором каждое место хранения было маркировано уникальным штриховым кодом.

Весь товар на входе проходил контроль и, при отсутствии штрих-кода производителя, перемаркировывается собственным внутренним кодом.  Что это дает? Оператор, поместив товар на полку, сканирует код полки и система знает, что и где лежит. На одну полку можно положить сколько угодно разных товаров, что позволяет очень компактно разместить товар. Плотность размещения в момент максимальной загрузки склада достигала 80%-85%. Оборотная сторона медали — высокие требования к персоналу. Оператор должен знать товар, чтобы при сборе груза взять с полки именно то, что нужно. Учитывая, что даже специалист не всегда отличит с первого взгляда одну модификацию видеокарты от другой, процент ошибок при сборе заказа достигал 8-10%. Это было некритично, поскольку склад обслуживал только свои магазины, но крайне неприятно. Выяснение отношений стоило массы сил и времени и иногда не приводило к результату.

На самом деле, система благополучно жила, и жила бы еще долго, несмотря на такой очевидный минус, как сильная зависимость от человеческого фактора. Но склад кончился, причем чисто физически. Его объема стало не хватать. Возникла потребность оборудования нового склада. Очевидно, что проблема расщеплялась на несколько: какое использовать помещение, какое оборудование; как это размещать? И, наконец, как всем этим управлять?

Казалось бы, половина этих вопросов не имеет отношения к CIO. Но РЦ — критическая точка, от которой зависит работа всей сети. А CIO должен  понимать все критические точки. Второй резон — ИТ всегда «завершает» строительство. И не важно, кто виноват. Шишки повалятся на последнее звено. Каждый руководитель знает, что «если ты не можешь предотвратить пьянку, ты обязан ее возглавить». Поэтому CIO может и должен участвовать в принятии всех решений.

Как это было

Совет директоров поддержал мой подход, который заключался в том, что для строительства склада надо нанять специалистов. К счастью, у Columbus оказалось подразделение бизнес-консалтинга, которое имело опыт проектирования складов. Наличие подрядчика, отвечающего за конечный результат, — огромный плюс. Не возникает ситуации: «Я пришивал пуговицы. К пуговицам претензий нет?». Специалисты Columbus изучили все вдоль и поперек. Были учтены прочностные требования к перекрытиям, углы наклона пандусов и ширина аппарели. В соответствии с нашими реалиями, товарными группами и прогнозами развития, на планах были расставлены стеллажи, выбрано оборудование , — от WiFi сканеров до погрузчиков. Был создан так называемый концептуальный дизайн склада – в документах были прописаны мельчайшие детали проекта: расположение стеллажей, размер ячеек, подъездные пути, необходимые для покупки автопогрузчики, терминалы для сбора данных и т.п. После чего консультанты расписали необходимые алгоритмы работы сотрудников склада и начали внедрять    WMS-систему. На начальном этапе были совместно сформулированы требования к системе управления.

Они были такими:

1) Модульность. Условно говоря, система — это черный ящик с описанными входами (номенклатурный справочник, входной поток товара и документов, заказы на отгрузку) и описанными выходами (поток товара, снабженный документами). Система должна быть независимой от внешних систем. Если завтра ERP сменится — это не должно повлечь смену WMS.

2) Тиражируемость. При необходимости мы должны легко «клонировать» систему.

3) Масштабируемость. Появление дополнительных помещений в рамках системы не должно требовать ее переделки.

4) Точность. Процент ошибок не должен превышать 1%

5) Функциональность. Мир несовершенен, и на входе может оказаться совершенно немаркированный и неструктурированный груз. Разные части комплекта могут быть в разных упаковках и прийти в разное время. Магазины же должны получить товар, полностью готовый к продаже, — со всеми инструкциями, кабелечками, наклеечками и прочими мулечками.

Что было выбрано и почему:

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

2)В качестве рабочего инструмента были выбраны WiFi терминалы сбора данных фирмы Symbol. В помещении развернута сотовая WiFi инфраструктура.

3)В качестве системы было выбрано отраслевое решение WMSII фирмы Columbus на базе Axapta 3.0

4)Консалтинг, доработка и внедрение системы были поручены фирме Columbus.

5)Переезд склада на новое место должен был сопровождаться инвентаризацией и минимально ограничивать товаропоток в магазины.

Проект начался в начале 2006 года и должен был быть окончен в июле 2006 года. Поскольку WMSII — отработанное отраслевое решение Columbus, мы не ожидали особых проблем. Однако мир несовершенен. Строители не успели закончить работу. Наличие сезонного фактора не позволяло просто так передвинуть сроки.  Было принято следующее решение:

1)Назначить переезд на первую декаду января 2007 года. В этот момент нет поставок, соответственно, меньше перекрестных потоков.

2)Работы над проектом заморозить.

3)Рабочий вариант системы смонтировать в учебном классе и в течение всего времени проводить поддерживающее обучение персонала.

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

Уроки

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

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

Существует мнение, особенно культивируемое консультантами, что РЦ тем и хорош, что при увеличении вдвое товарооборота не надо в двое увеличивать площадь хранения. Достаточно вдвое быстрее принимать и отправлять товар. К сожалению, это сказка. Это может быть, с некоторыми оговорками, в лслучае абсолютно равномерных и непрерывных поставок. Но во многих отраслях ритейла наблюдается лакуна в поставках в районе нового года из-за каникул у дистрибьюторов.  В сочетании с новогодним пиком продаж это требует, независимо от скорости обработки, места для 3-4 недельного запаса товара. По сути, на распределительном складе должен помещаться месячный оборот фирмы.   WMSII принципиально имеет меньший коэффициент заполнения. Нам пришлось на ходу модифицировать систему, в частности вводить различные типоразмеры ячеек для того, чтобы поднять коэффициент заполнения. В результате с начальных 45% мы увеличили его до 60%, что, по видимому, является своеобразным рекордом для         WMSII.

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

Отдельно хочется сказать о WiFi-сканерах. Что бы ни говорили «консультанты» и «специалисты по продажам» этих самых сканеров — они далеко не всегда дают существенные преимущества. А иногда просто мешают. Вот маленькое эссе по поводу их применения при сборе грузов, написанное одним из наших сотрудников:

Представьте, вы дома встаете в 8:30 и четко знаете, что надо пойти в гальюн, зайти в ванну, где должна быть зубная щетка и душ, заскочить на кухню, где можно взять булочку с кофе, вернуться в спальню, где можно наконец надеть штаны и в 9:00 прибыть на работу. А теперь вам предлагают сделать все то же самое, но фиксируя свои действия сканером. Предположим, что он работает мгновенно (это не вполне так, но это уже претензии к Билу Гейтсу):

Этап 1. Вы встаете в 8:30. Берете в руку сканер (не мгновенно). Сканируете вход в гальюн (мгновенно). Заходите в гальюн (особо отличившиеся могут отсканировать туалет, а зайти в ванну). Этап 2. Кладете аккуратно сканер (а то его стоимость вычтут из зарплаты), чтобы освободить руки, ну и т.д. Ход мысли понятен. Этап 3. Организация склада WMSII такова, что через 2-3 смены контролер знает свою зону комплектации (где вовсе не 10 000 артикулов),  как свою квартиру. Сканер может помочь новичку, но потом он, если нет требований к учету отгрузок партиями, причина его лишних телодвижений.   Если вам во время такелажных работ предложить иметь в руках китайскую вазу, процесс передвижения мебели это не ускорит, хотя этот процесс может выглядеть намного привлекательнее.

Итоги

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

Система оказалась легко масштабируемой. Когда для создания запаса товара понадобилось дополнительное помещение на другом конце города, в систему просто добавили еще два «этажа». А когда необходимость отпала — просто перестали их использовать.

Из минусов — плотность заполнения склада упала до 60%.

Интеграция ERP И WMS

У нас получился тандем из ERP на базе Axapta 3.0 и WMS на базе Axapta 3.0. Системы установлены на разных серверах, полностью независимы и могут расширяться и модифицироваться независимо. Основные справочники ведутся в ERP. По сути, к одной ERP можно подключать любое количество таких «кубиков-WMS». WMS является практически самодостаточной и не слишком зависящей от типа ERP системой. Все, что ему надо, это справочники, заказы на прием и заказы на отгрузку. А как же проблемы с интеграцией, спросите Вы. На мой взгляд, жуткие проблемы интеграции — это некоторый миф, подкрепленный желанием «внедренцев» заработать лишнюю «копеечку» и подогреваемый их же страхами. Мы пробовали интегрировать Axapta 3.0 с самыми разными продуктами. Это и Axapta и 1Сv8 и старые DOS приложения, написанные в прошлом веке на Clipper и еще с кучей всего. По сути, интеграция сводится к выгрузке всего, что не SQL в SQL таблицы и построение взаимодействия между ними. А также обратный процесс. Ни один из этих процессов не является чем-то из ряда вон выходящим. Соответствующие программы-роботы пишутся достаточно легко и при разумном подходе работают достаточно устойчиво. Собственно говоря, у вас есть всего два подхода. Делать централизованную систему, что позволяет, зачастую, уменьшить TCO (общая стоимость владения), но создает единую точку отказа, или делать распределенную систему, которая, как подводная лодка, разделенная на отсеки, отличается изрядной непотопляемостью. Есть апологеты и той и другой модели, у каждой есть масса удачных внедрений. Я сторонник «подводной лодки». Очень может быть, что мной движет глубокое сомнение в качестве систем связи за пределами Москвы и Питера, хотя эта проблема отчасти решается с помощью спутниковых каналов. Но скорее всего, я просто переболел как идеей ERP как «все в одном флаконе», так и страхом интеграции. И предпочитаю для каждой серьезной бизнес-задачи подбирать адекватный инструмент.

Как быть?

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

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

При построении распределительных центров разумно привлекать консультантов разработчиков на самых  ранних этапах.

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

Польза от «достижений прогресса», таких как WiFi, и т.д. должна быть тщательно просчитана, а технологии проработаны не в воспаленном мозгу разработчиков, а на рабочем месте.

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

Отправить ответ

Уведомлять о
avatar