Осторожно: WMS – 2. Этап внедрения

«- Как у тебя это получилось? - Не знаю, наверно случайно». Мой знакомый завскладом – про единственный успешно сведенный пакет накладных на автомобиль доставки, в первый день работы склада в новой системе.

Семинар на тему: "Складская логистика торгового предприятия" с участием Виктора Барановского будет проходить 21-22 мая в городе Киеве.

Итак, допустим, решение руководством компании принято… Принято решение - ставим программу, должна заработать к … (назовем эту дату «день Д»).  Программный продукт выбран (или выбирается).

Какие сложности нас ожидают? Как можно уменьшить количество проблем в процессе внедрения?  Попытаемся «пройтись» по достаточно типичным проблемам.

Участие в выборе продукта.

Конечно, основное «право голоса» - за финансовым директором и руководителем ИТ-департамента. Но, тем не менее… Поскольку WMS – это практически всегда «штучный продукт», на этом этапе фактически проводится «конкурс презентаций». Задача поставщика – убедить заказчика, что именно этот продукт в состоянии решить его проблемы (и те, с которыми заказчик пришел к решению поставить систему на складе, и те, которые он еще не заметил..).

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

  1. Смотрите то, что вам показывают. Обычно представители поставщика не первых встречах показывают презентацию с некоторого успешного проекта. Насколько описание похоже на процессы, происходящие на вашем складе? Когда на презентации для аптечного склада (поштучка, посерийный учет и прочий хардкор) показывают решение для склада бакалеи – кто-то должен озвучить фразу «а как это будет работать у нас?».
  2. Обращайте внимание на «железо», которое фигурирует в проекте. Поставщики обычно уверены, что без терминала сбора данных у каждого работника – работа не может проводиться, и все. Даже на поштучном отборе! При этом анатомические особенности отборщика должны выглядеть примерно так:
  • в одной руке – ТСД
  • во второй руке – стилус терминала (вводим количество штук)
  • в третьей руке – отбираемый товар
  • в четвертой руке – емкость для отбора товара (коробка или корзинка с ручкой) или поручень толкаемой тележки

Поскольку такие мутанты на складе не встречаются, можно сформулировать каверзный вопрос: «Правильно ли я понял, что мы тратим 1000 уе на оснащение ОДНОГО работника, и в результате получаем снижение его производительности в 1.5 – 2 раза?». Правильно…

Кстати, компьютеры, установленные на складе, вероятно, тоже придется сменить - из-за очевидно низкой производительности, не удовлетворяющей новым системным требованиям.

  1. Проанализируйте, что вам не показали. Например, «за кадром» часто остаются вопросы:
  • пополнения зоны активного хранения (кто, как, когда)
  • выполнения правил партионного учета
  • количества «внутренних» документов в системе и необходимого для этого ресурса (сколько операторов учета придется добавить в штат склада при переходе на ячеистую струткуру склада? Хорошо, если одного..)
  • работы с товаром, имеющим больше одного штрихкода.
  • работы со штрихкодом, который встречается на нескольких товарах

       4. Обязательно! Отработка исключений. Каким образом поставщик может продемонстрировать помехоустойчивость и эластичность своего продукта?

Внедрение – первый этап. Изучение того, что мы планируем изменить.

Первый этап – построение модели «как есть». Прежде чем что-то изменить, нужно это изучить.

На этом этапе – желательно удержаться от двух крайностей:

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

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

Соответственно, игнорирование этого этапа членами проекта со стороны поставщика (все равно изменим - и так все понятно, что вы все делаете неправильно) – очень опасный признак.

Внедрение – второй этап. Разработка техзадания и собственно внедрение

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

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

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

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

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

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

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

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

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

В качестве примеров не всегда оправданных решений – можно привести достаточно длинный список разнообразных фантазий:

  • динамическое складирование (забыли персоналу склада объяснить, что это такое, и почему постоянно перемещается системой товар по складу)
  • сценарий максимального заполнения ячеек хранения (весьвесогабарит навесьтовар так и не собрали, а система почему-то думает, что в ячейку хранения можно впихнуть бесконечное количество товара с объемом единицу хранения = 0.0000 куб.м.)
  • планирование к отгрузке товара из ожидаемого поступления  (подвело большое количество ошибок поставщиков, вызвавшее слишком много исправлений в документах)
  • отгрузка товара из всех хранимых на складе партий (система выдержала, а вот персонал склада не оценил такой продвинутый сервис для клиентов).

Краткий вывод. Важные условия для успеха проекта:

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

Внедрение – третий этап. Запуск.

1. Не поддаваться панике. Все пойдет не так, как вы планировали.

2. Переходим на работу в критическом режиме, фиксируем все сбои в работе.

3. в случае возникновения сбоя:

  •  максимально быстро вручную исправить ситуацию
  • разобрать проблему с программистами, не успокаиваться пока они не обнаружат и не устранят причину, вызвавшую сбой.

4. вести статистику всех сбоев и ошибок системы. Принимать меры (в том числе непопулярные), если ошибка стала периодической (то есть не решили причину, а почему-то беремся с последстаиями)

5. Не забудьте про мотивацию персонала. Работникам на складе – никакой новый продукт не нужен. Им было и так хорошо. Соответственно, мелкий саботаж распоряжений – будет, если вы заранее не заручитесь поддержкой всего коллектива склада, Они должны быть заинтересованы в успехе внедрения. Но мотивация персонала – это уже другая тема…

 

Семинар на тему: "Складская логистика торгового предприятия" с участием Виктора Барановского будет проходить 21-22 мая в городе Киеве.

По вопросам регистрации: Тел: [відкрити контакти](044) 361-05-10[відкрити контакти](067) 680-15-70 Факс: [відкрити контакти](044) 586-56-99.

 

 

CallSend SMSAdd to SkypeYou'll need Skype CreditFree via Skype


Залишити коментар
Будь ласка, введіть ваше ім’я
Будь ласка, введіть коментар.
1000 символів

Будь ласка, введіть email
або Відмінити

Інші статті в категорії Новини