Легко писать об успешных внедрениях. Сложнее проанализировать и описать причины неудач. Впрочем, однозначно сказать, что является неудачей трудно. Если на складе год идет внедрение ВМС и за это время под управление системы переведена восьмая часть склада — это трудности процесса или же все-таки неудача. Давайте посмотрим на внедрение ВМС изнутри склада. Ведь автоматизируют склад, прежде всего для облегчения его работы. Но поскольку склад является ключевым производством для торговых и многих других компаний, автоматизация склада повышает качество работы всей компании. Поэтому ключевое производство должно быть полностью автоматизировано как можно быстрее. А для этого надо как можно полнее описывать функционал ВМС и тщательно его тестировать. Когда система полностью подготовлена внедрение можно начинать даже в пик сезона и через 3-4 месяца склад будет полностью работать под управлением ВМС. А в рассмотренном случае выходит, что запустили в работу не совсем готовую систему. Почему так может получиться? Процесс автоматизации сложен по определению. Сбои могут возникнуть на любом этапе. Попробую рассказать о том, на что стоит обратить внимание на разных стадиях выбора и внедрения ВМС. Все примеры ошибок и сбоев, приведенные в этом материале, взяты из жизни. Подавляющее большинство из собственной практики. Но не надо считать это сборником ужастиков. Кто предупрежден, тот вооружен. В жизни бывает много такого, что предвидеть можно, но сложно. Так что учитесь на чужих ошибках.
Начнем сначала. То есть с выбора системы. У вас есть логистический проект и как-то обозначен круг систем, из которых будете выбирать. Давно озвучено, что выбирать надо не систему, а команду. То есть группу технологов и программистов, сумевших успешно автоматизировать конкретный склад. Лично я полностью поддерживаю эту рекомендацию. Только есть одно «но». После кризиса 2008-2009 годов в сфере автоматизации все так перемешалось, многие программисты ушли из отрасли. Вы затрачиваете кучу усилий и находите в своей отрасли автоматизированное предприятие, уговариваете руководство поделиться информацией о команде внедренцев и особенностях работы с ней. Звоните разработчикам ВМС, а на выходе оказывается, что команды больше не существует.
И дальше что? Затрачивать кучу усилий в поисках членов команды или выбирать другую систему? Нужно чтобы компетентные люди уточнили как применить эту рекомендацию в современных условиях. От себе же хочу сказать, что независимо от того, что будете вы выбирать систему или команду, в процессе обязательно должны участвовать те, кто будут работать с системой непосредственно. Право решающего голоса им давать может и не стоит. Большая польза будет уже от того, что они внесут рациональное зерно в процесс выбора. А то иногда диву даешься от критериев выбора — система должна быть только импортная, интерфейс системы не должен быть 1Совским... Будто покупают не ВМС, а, скажем, мобильный телефон. Главное чтобы было красиво и радовало глаз. А то, что 80% функций не будем использовать это детали. Ключевыми критериями выбора должны быть ограничения системы и то, как она работает с номенклатурой и топологией.
Например, у вас есть товары у которых щтрихкод штуки совпадает с штрихкодом коробки. А у какой-либо ВМС ограничением является уникальность штрихкода штуки. То есть штрихкод на штуке не должен совпадать ни с каким другим штрихкодом. Что будет если такую ВМС использовать для указанного товара? При каждом сканировании штуки или короба пользователю придется указывать системе с какой единицей измерения она имеет дело. То есть пальцем нажимать несколько кнопок на клавиатуре терминала. Можно указать системе одну единицу измерения, а фактически взять другую. В результате при отгрузках вы будете либо недодавать товар, либо давать лишнее. О первом вам будут сообщать всегда, о втором крайне редко. В итоге вы будете в убытке. Можно говорить, что у сборщиков руки не оттуда растут. Но тут причина в том, что система, призванная уменьшить человеческий фактор, сама его плодит. О том, что при этом и скорость сборки гораздо ниже возможной при нормальной работе системы можно и не говорить. В целом можно сказать, что если вы будете знать ограничения и особенности работы с номенклатурой конкретной системы, то подавляющее большинство проблем, способных быть при работе этой системы с вашим товаром, вы сможете предвидеть. Во всяком случае, вы сможете понять какие уточняющие вопросы надо задать разработчикам. И вообще, старайтесь задавать как можно больше вопросов. Не бывает дурацких вопросов. Вы же не специалист по конкретной системе. А специалисты по системе далеко не всегда понимают как автоматизировать работу с этим товаром на конкретном складе. Красивая презентация и экскурсия дадут общее представление о работе системы, реализации основных процессов и интерфейсе системы. Далее вам надо понять как может происходить работа вашего склада под управлением этой системы. Это непростая задача. Поэтому надо задавать больше вопросов и анализировать ответы.
Также не забудьте уточнить в каких единицах используются в ВМС габариты и вес товаров. Если эти единицы отличны от используемых в вашей КИС надо понять какие коэффициенты надо использовать для перехода. И почти наверняка возникнет спор на какой стороне будут применяться коэффициенты. Ваш программист может занять железобетонную позицию, что он выгружает данные как есть, а что с ними сделает ВМС его не касается. А со стороны ВМС будут утверждать, что система должна получать правильные данные. Дело не в том кто под кого прогнется или что программисты хотят помериться славой. Если КИС ведущая система, а ВМС ведомая, то гораздо больше оснований принять точку зрения программиста КИС.
Важно и то, как система подсчитывает объем товаров. Не надо верить словам, что посчитают как угодно. Обязательно уточняйте. Например, несколько штук неплотно уложены в упаковку, а несколько упаковок так же неплотно сложены в коробку. Из КИС система получила габариты штуки, упаковки и короба. Как ВМС посчитает объем короба и паллета? Можно взять габариты короба и перемножить их. Затем умножить на количество коробов на паллете. А можно перемножить габариты штуки, а затем получившийся объем умножить на количество штук в коробе и умножить на количество коробов на паллете. Результаты таких расчетов могут отличаться весьма существенно. Эта разница скажется на размещении. Также на размещении скажется отсутствие у товара массо-габаритных характеристик. Некоторые системы, например Exceed, в таком случае не позволят произвести приемку.
Если структура вложенности ваших товаров штука-упаковка-коробка выясните как реагирует система на ситуацию упак=1 шт. То есть товар имеет структуру вложенности штука-коробка. В КИС для такого случая в карточке товара упаковка по умолчанию равна одной штуке. Некоторые ВМС реагируют на такую ситуацию, скажем так, нервно. Выражается это в неудобности приемки таких товаров и трудностях при отборе. В ТСД структура вложенности таких товаров почему-то отражается в виде
кор |
шт |
упак |
И приходится долго втолковывать, что количество штук надо всегда вбивать в нижнее поле, несмотря на то, что там написано УПАК. А на сборке у такой ВМС может быть обратная ситуация. Когда система просит сборщика отобрать 3 упаковки ему надо сообразить сколько это будет в штуках, не является ли для данного товара упак = 1 штука. А когда вы выясните у разработчика ВМС, что отображать количество товара в ТСД можно либо только в штуках, либо только в кратных единицах, приходится вырабатывать особую методику отбора для таких товаров.
Есть еще один момент в работе с товаром. Что делать если при приемке не удалось сразу опознать товар? Или вы получили товар который не заказывали и его нет в вашем справочнике? Для подобных случаев существует механизм, называемый «Неизвестный артикул». Существует два пути реализации этого механизма. Первый предполагает, что ВМС ведомая система и карточка товара должна быть получена из КИС. Но в КИС чтобы провести карточку товара необходимо заполнить кучу обязательных атрибутов. А это равносильно опознанию. Можно заполнить карточку усредненными параметрами. Но если реальные параметры товара будут сильно отличаться от средних, то при приемке неизбежны неудобства. Например, габариты или вес реального товара существенно меньше указанных для «Неизвестного артикула». В таком случае система автоматически закроет принимаемый паллет до того, как вы просканируете все короба. Надо либо перекладывать товар на другой паллет, либо присваивать одному паллету несколько этикеток. Во втором случае почти наверняка корректно разместить паллет не получится. Ведь может понадобиться длительное разбирательство, а паллет должен где-то числиться. Особенно если вы логистический оператор. Да и не каждый клиент логистического оператора будет напрягаться из-за проблем, имеющихся у оператора. Второй путь предполагает, что в ВМС есть специальная универсальная карточка «Неизвестный артикул». И существует способ преобразования «Неизветного артикула» в известный. После чего данные передаются в КИС. Это гораздо удобнее первого пути. Паллет с «Неизвестным артикулом» может быть сформирован так, как удобно складу. С этим паллетом можно работать по обычным правилам. Для логистических операторов и их клиентов это удобно. Если склад работает с собственным товаром, то приемочный персонал редко пользуется «Неизвестным артикулом». Обычно опознание невозможно из-за повреждения или отсутствия этикетки. В таком случае можно открыть короб и опознать товар самому или с помощью опытных коллег. При удачном опознании товар сразу принимается. И только если товар не заказывали и его нет в справочнике системы персонал может воспользоваться механизмом «Неизвестного артикула». Именно может, а не обязан. Если вернуть товар поставщику можно без проводок в КИС нет необходимости пользоваться «Неизвестным артикулом». А если решат оставить товар, то заведут не него карточку и он будет принят как известный. В целом могу сказать, что прежде чем включить в систему работу с неизвестным артикулом как следует обдумайте, с учетом вышеизложенного, в каких случаях у вас будет возникать необходимость реального запуска этого механизма. Затем подумайте, посоветуйтесь и решите как персонал будет физически работать в таких ситуациях. Если после этого окажется, что у вас осталась необходимость в механизме «Неизвестного артикула», тогда включайте этот пункт в техническое задание. Но не в абстрактном виде — «должно быть», а с конкретным указанием случаев и технологии использования механизма.
Прежде чем перейти к рассмотрению вопросов работы системы с топологией стоит рассмотреть адресное пространство. Структура адреса может состоять только из цифр, а может содержать цифры и буквы. ВМС в принципе безразлично каково будет наименование конкретного адреса. Это небезразлично людям. В работе склада всегда будет необходимость устно передать точный адрес. Тут надо понимать какие трудности будут при озвучивании адреса. Что такое передать адрес состоящий только из цифр, особенно длинный, может представить каждый. Это тоже самое, что сообщить кому-то номер телефона. Удобнее когда в адресе чередуются цифры и буквы. Но у SQL проблемы с русскими буквами. Программисты крайне не рекомендуют их использовать. А у большинства наших людей проблемы с озвучиванием и пониманием букв английского алфавита. Какие то общие рекомендации по этому вопросу дать сложно. Приведу пример из собственной практики. На одном складе ВМС внедряли дважды. Для первой ВМС адресация была буквенно-цифровая, для второй цифровая. Вот пример адресации одной и той же ячейки: А04J3 и 1К-06-04-3-1. Расшифровка адресов такова: А04J3 — А это зона, 04 — проход, J – ячейка (место), 3 — ярус; 1К-06-04-3-1 — 1К это зона, 06 — ряд, 04 — пролет, 3 — ярус, 1 — ячейка (место). В первом случае адресация идет по проходам и в нее зашит порядок обхода — от прохода по правой стороне до стены и по левой стороне обратно буквы идут по возрастанию. Во втором случае нумеруется каждый ряд стеллажей всегда от прохода к стене. Для первой системы можно было использовать произвольную адресацию. Во второй адресация задана жестко: Ряд-Пролет-Ярус-Место. Именно такой порядок адресации используется во многих системах. На мой взгляд этот порядок нелогичен. Погрузчик подъедет к ряду, отсчитает пролет, найдет место и поднимет вилы на ярус. Он же не может подъехать к ярусу и двигаясь поперек искать место. Принцип Ряд-Пролет-Место-Ярус логичен, позволяет последовательно обрабатывать части адреса. Вы можете решить, что это мелочь и люди привыкнут. При таком подходе может оказаться, что пока люди будут привыкать к куче таких «мелочей» склад может понести реальные убытки. Пример возникновения подобных убытков я приведу в рассказе о сборке. Про пару таких «мелочей» - обработку одинакового штрихкода штуки и короба, а также отражения в ТСД структуры вложенности товара — я писал выше. И все эти 3 мелочевки были в одном и том же месте. Так что на участке где без ВМС без напряжения справлялись 5 человек, под управлением такой вот ВМС не всегда успевали 6 человек. Да еще иногда подключался седьмой. Для разбора завалов.
Теперь рассмотрим порядок (маршрут) обхода ячеек. В большинстве систем он может быть раздельно задан для отбора и для размещения. Например, у вас ворота только с одной стороны склада, с другой стороны тупик. Зоны приема и отгрузки находятся у ворот. Порядок размещения логично задать от ворот к тупику, а порядок отбора наоборот — от тупика к воротам. Механизм обхода можно зашить в ВМС через использование координат, то требуется выработка алгоритма и программирование. Некоторые системы оставляют задание порядка обхода на пользователя. Он должен руками присвоить каждой ячейке номер. Понятно, что номера не должны повторяться. Маршрут обхода при размещении может быть задан системой жестко, а может допускать пользователю размещение в ячейку отличную от назначенной системой. Рассмотрим размещение на мезонин (в полки). Наиболее типичные наименования способов размещения: размещение по артикулу и размещение по маршруту. По маршруту — система выстраивает ячейки для размещения в порядке обхода и пользователю, подойдя к ячейке, надо искать на раскладываемом паллете конкретный товар. По артикулу — пользователь выбирает конкретный товар, а система сообщает ячейку для его размещения. Можно класть артикул в ячейку частично. Например, часть коробок лежит наверху паллета, а часть в нижних рядах. Когда пользователь доберется до низа паллета и еще раз просканирует этот артикул система предложит то же место куда он был положен в первом подходе к товару. При размещении по маршруту положить часть артикула нельзя, только все количество целиком. Что имеем в итоге? При размещении по маршруту мало ходите, около каждой ячейки перебираете товар на паллете. При размещении по артикулу сами выбираете товар (то есть почти нет переборки паллета), но много ходите. Адепты теории «нам электричество сделать всё сумеет» утверждают, что размещать всегда должна система, пользователь лишь исполнитель. Практика же показывает, что разместить паллет, содержащий 42 короба 25-ти артикулов чуть быстрее получится размещением по артикулу. А если у вас паллет имеет 56 коробов 37-ми артикулов разница в пользу размещения по артикулу еще больше.
Теперь рассмотрим принципы размещения. Основных принципов два: размещение к уже имеющемуся товару и размещение всегда в пустую ячейку. При каждом способе есть проблемы, которые придется решать. Если использовать размещение к уже имеющемуся товару, то надо решить куда помещать отсутствующий в данной раскладке товар. Можно оставить выбор места на пользователя. Только надо явно сообщить ему об этом. Не всем понятно, что отсутствие указания места на экране ТСД это сигнал включить мозги или разрешение положить товар куда угодно. Или можно выбрать для таких случаев какую-либо конкретную ячейку. Например, последнюю по пути обхода в данной зоне. В принципе толковый пользователь положит товар по всем правилам. Даже не формализованным для ВМС. Например, не учтен формат коробок. Или формат учтен, но при одинаковом формате у различных товаров этикетки находятся на разных сторонах (боках) короба. В таком случае на диспетчера ложится задача назначения толкового раскладчика и отслеживания правильности раскладки. Если выбирать конкретную ячейку, то надо понимать как система работает с объемом ячейки и что будет если превышено какое либо ограничение. Например, есть ограничение количества артикулов в ячейке. У меня в работе случалось следующее. У пользователя нет прав менять назначенную системой ячейку. Он сканирует товар. Этого товара нет в хранении и система предлагает фиксированную ячейку. Человек сканирует ячейку и видит сообщение: «Превышено допустимое количество артикулов в ячейке». То есть разместить нельзя. И другая ячейка не предлагается. Что делать? Нужен пользователь, способный изменить параметры системы. Менять права раскладчика именно в этот момент бесполезно. Права у пользователя поменяются при очередном заходе в систему. Чтобы заново зайти надо сначала выйти из неё. А выйти система не даст потому, что у пользователя на руках товар. Значит надо увеличивать допустимое количество артикулов в ячейке. После того как пользователь закончит раскладку снова надо что-то делать — менять права пользователя и/или менять ограничения на ячейку. Ну и конечно требовать от разработчика сделать автоматическую обработку нарушения ограничений на ячейки. Ограничение количества артикулов в ячейке типичное и очень часто используемое. Совершенно непонятно почему у разработчика нет автоматической обработки нарушения данного ограничения. Выявит такие вещи на тестах можно. Придется потратить достаточно много времени. Но даже если вы выявите эту недоработку на тестах, не всегда есть гарантия, что ошибка не появится снова. ВМС состоит из многих блоков. Когда запускают новую версию систему заново собирают из блоков. При сборке могут взять блок какого-либо процесса со старой ошибкой. У меня на предыдущем месте в процессе эксплуатации было, что после ввода новой версии ВМС, несмотря на ее тестирование, вернулась часть старых ошибок и добавились новые. Так что комплекс старых ошибок по сравнению с новым комплексом оказался цветочком. Пришлось просить разработчика откатиться на старую версию. Но они отказались. Чтобы не попасть в такую ситуацию, прежде всего надо тщательно и скрупулезно тестировать систему перед запуском в опытную эксплуатацию. Необходимо иметь схемы процессов и разработанный на их основании сценарий тестирования. А если в процессе опытной эксплуатации выявятся серьезные проблемы в 2 и более процессах или комплекс мелких проблем существенно понижающий производительность и точность работы (о чем было выше) надо откатиться назад и вернуться к доработкам и тестам. Повторюсь, запускать надо полностью готовую ВМС. Как известно, лучше день потерять, потом за 5 минут долететь.