Осторожно: WMS – 2. Этап внедрения
«- Как у тебя это получилось? - Не знаю, наверно случайно». Мой знакомый завскладом – про единственный успешно сведенный пакет накладных на автомобиль доставки, в первый день работы склада в новой системе.
Семинар на тему: "Складская логистика торгового предприятия" с участием Виктора Барановского будет проходить 21-22 мая в городе Киеве.
Итак, допустим, решение руководством компании принято… Принято решение - ставим программу, должна заработать к … (назовем эту дату «день Д»). Программный продукт выбран (или выбирается).
Какие сложности нас ожидают? Как можно уменьшить количество проблем в процессе внедрения? Попытаемся «пройтись» по достаточно типичным проблемам.
Участие в выборе продукта.
Конечно, основное «право голоса» - за финансовым директором и руководителем ИТ-департамента. Но, тем не менее… Поскольку WMS – это практически всегда «штучный продукт», на этом этапе фактически проводится «конкурс презентаций». Задача поставщика – убедить заказчика, что именно этот продукт в состоянии решить его проблемы (и те, с которыми заказчик пришел к решению поставить систему на складе, и те, которые он еще не заметил..).
Следовательно, на этом этапе – активно посещаем встречи с потенциальными поставщиками, смотрим их презентации, в которых они расписывают преимущества своих продуктов. По возможности – задаем вопросы. Не надо стесняться и считать, что раз вопрос, который вы задаете, не в состоянии понять ваши коллеги, присутствующие на встрече, то лучше промолчать. Во-первых, ответ вам все равно нужен. Во-вторых, а если ответа у поставщика нет? Вот некоторые вопросы, которые лучше не откладывать.
- Смотрите то, что вам показывают. Обычно представители поставщика не первых встречах показывают презентацию с некоторого успешного проекта. Насколько описание похоже на процессы, происходящие на вашем складе? Когда на презентации для аптечного склада (поштучка, посерийный учет и прочий хардкор) показывают решение для склада бакалеи – кто-то должен озвучить фразу «а как это будет работать у нас?».
- Обращайте внимание на «железо», которое фигурирует в проекте. Поставщики обычно уверены, что без терминала сбора данных у каждого работника – работа не может проводиться, и все. Даже на поштучном отборе! При этом анатомические особенности отборщика должны выглядеть примерно так:
- в одной руке – ТСД
- во второй руке – стилус терминала (вводим количество штук)
- в третьей руке – отбираемый товар
- в четвертой руке – емкость для отбора товара (коробка или корзинка с ручкой) или поручень толкаемой тележки
Поскольку такие мутанты на складе не встречаются, можно сформулировать каверзный вопрос: «Правильно ли я понял, что мы тратим 1000 уе на оснащение ОДНОГО работника, и в результате получаем снижение его производительности в 1.5 – 2 раза?». Правильно…
Кстати, компьютеры, установленные на складе, вероятно, тоже придется сменить - из-за очевидно низкой производительности, не удовлетворяющей новым системным требованиям.
- Проанализируйте, что вам не показали. Например, «за кадром» часто остаются вопросы:
- пополнения зоны активного хранения (кто, как, когда)
- выполнения правил партионного учета
- количества «внутренних» документов в системе и необходимого для этого ресурса (сколько операторов учета придется добавить в штат склада при переходе на ячеистую струткуру склада? Хорошо, если одного..)
- работы с товаром, имеющим больше одного штрихкода.
- работы со штрихкодом, который встречается на нескольких товарах
4. Обязательно! Отработка исключений. Каким образом поставщик может продемонстрировать помехоустойчивость и эластичность своего продукта?
Внедрение – первый этап. Изучение того, что мы планируем изменить.
Первый этап – построение модели «как есть». Прежде чем что-то изменить, нужно это изучить.
На этом этапе – желательно удержаться от двух крайностей:
- игнорирование текущей ситуации. «Все равно новый продукт устранит все проблемы, которые мы сейчас сортируем и описываем». Большой соблазн не тратить ресурс на эту работу, а двигаться дальше как можно скорее. Потенциальная опасность потерять наработанные технологии «второго порядка», в основном – взаимодействие между структурными подразделениями склада, а также наработанные правила действия при нештатных ситуациях.
- увлечение моделизмом. Построение максимально подробной модели работы склада в данный момент, причем для анализа собранной информации нужно потратить тоже весьма значительное время. КПД этой работы может оказаться весьма низким, по причине очень низкого соотношения полезной информации к общему объему полученного многостостраничного опуса. Простые вещи не стоит называть сложными терминами и пространно описывать ну уж совсем базовые операции.
В общем, можно уверенно сказать: качественная работа на этапе построения модели работы «как есть» (обязательно – с пониманием причинно-следственных связей) – необходимое (но, к сожалению, не достаточное) условие успешности проекта.
Соответственно, игнорирование этого этапа членами проекта со стороны поставщика (все равно изменим - и так все понятно, что вы все делаете неправильно) – очень опасный признак.
Внедрение – второй этап. Разработка техзадания и собственно внедрение
На этом этапе ключевой фактор – корректная постановка техзадания. Основная проблема – корректно отработать все возможные исключения. Очень удобный инструмент в этом случае – стандартная логическая блок-схема (в школе проходили на программировании).
Она позволяет достаточно грамотно и без сложных действий описать все случаи «если-то», и не оставить подвешенной в воздухе какую-то логическую линию последовательности событий.
На основании описания запланированных алгоритмов работы – программисты должны предоставить техзадание. Внимание. Если техзадание обязаны по договору писать сотрудники заказчика – очень плохой признак, очевидное желание поставщика программы снять с себя ответственность. Продолжает работать правило «правильно заданный вопрос содержит половину ответа», но «отвечающий» получает замечательную возможность в случае некорректного ответа – обвинить «спрашивающего».
Здесь вариант конфликтов – все то же нежелание программистов «писать техзадания, которые никто не понимает» (писать понятно для персонала склада они обычно не пробовали) – а с другой стороны, неготовность персонала заказчика понять написанное. В результате – вместо техзадания как скелета, на который будут нанизываться все описания и алгоритмы работы склада, получаем не поддающийся описанию и непригодный к использованию набор текстов. В перспективе – очевидный провал проекта и исправлениезапланированных(как следствие собственной лени) на этом этапе ошибок.
Для профилактики этой проблемы – в проектную группу со стороны заказчика обязательно включайте способных разобраться в техзадании аналитиков. Во-первых, персонал поставщика WMS – не заинтересован в чрезмерной детализации работ на этом этапе, им инетереснее максимально упростить себе написанное задание, чтобы затем побольше находиться в условиях «правового вакуума» и непрописанные в техзадании процессы – закрывать своими старыми заготовками с прежних проектов. Во-вторых, аналитик долже выступить переводчиком «со складского на программистский».
Идеальная ситуация – включение в штатное расписание склада позиции «специалист по складским технологиям». Работа для этого специалиста при внедрении WMS – есть, и ее достаточно на полную занятость.
Кстати. В договоре на поставку – желательно прописать, что «рабочие встречи по обсуждению следующих вопросов…» не тарифицируются. Иначе – заказчик начинает оплачивать сначала некачественно выполненное техзадание, а потом – оплачивает его исправление.
Обратная крайность, которой тоже может болеть команда внедрения (и сотрудники заказчика, и программисты) – чрезмерное усложнение планируемых бизнес-процессов. С одной стороны, техническая возможность системы (WMS – действительно мощный продукт, настройки которого позволяют ну очень много себе позволить в технологиях) позволяет реализовать весьма экзотические технологические схемы. С другой стороны, «мы вот тут такое придумали, надо сделать» - заказчик может предлагать как следует не продуманные схемы работы на разных участках склада, особо не вдаваясь в детали работы и согласования разных бизнес-процессов.
Лучшая профилактика с этой стороны – здоровый скепсис и ориентация на аксиому «работают простые схемы». Чем меньше усложнений мы в систему вносим – тем стабильнее она будет работать. А благими намерениями куда дорога вымощена, мы помним.
В качестве примеров не всегда оправданных решений – можно привести достаточно длинный список разнообразных фантазий:
- динамическое складирование (забыли персоналу склада объяснить, что это такое, и почему постоянно перемещается системой товар по складу)
- сценарий максимального заполнения ячеек хранения (весьвесогабарит навесьтовар так и не собрали, а система почему-то думает, что в ячейку хранения можно впихнуть бесконечное количество товара с объемом единицу хранения = 0.0000 куб.м.)
- планирование к отгрузке товара из ожидаемого поступления (подвело большое количество ошибок поставщиков, вызвавшее слишком много исправлений в документах)
- отгрузка товара из всех хранимых на складе партий (система выдержала, а вот персонал склада не оценил такой продвинутый сервис для клиентов).
Краткий вывод. Важные условия для успеха проекта:
- Тщательная проработка планируемых бизнес-процессов–важное условие успеха
- Ограничения на «полет фантазии» заказчика – исходя из здравого смысла и настройки на простоту процессов как залог их надежности
- Контроль над разработкой техзадания, пресекание попыток персонала поставщика «протащить» свои старые наработки «втихую». Включение в проект определенных успешных модулей с прежних проектов возможно – как сознательное решение всех членов команды
- Стандартизация склада под единую структуру адресации мест хранения
- Тесное взаимодействие с другими функциональными группами, взаимный поиск оптимальных решений.
- При возможности выбора из нескольких вариантов решений – выбираем более «эластичное» и «помехоустойчивое»,
Внедрение – третий этап. Запуск.
1. Не поддаваться панике. Все пойдет не так, как вы планировали.
2. Переходим на работу в критическом режиме, фиксируем все сбои в работе.
3. в случае возникновения сбоя:
- максимально быстро вручную исправить ситуацию
- разобрать проблему с программистами, не успокаиваться пока они не обнаружат и не устранят причину, вызвавшую сбой.
4. вести статистику всех сбоев и ошибок системы. Принимать меры (в том числе непопулярные), если ошибка стала периодической (то есть не решили причину, а почему-то беремся с последстаиями)
5. Не забудьте про мотивацию персонала. Работникам на складе – никакой новый продукт не нужен. Им было и так хорошо. Соответственно, мелкий саботаж распоряжений – будет, если вы заранее не заручитесь поддержкой всего коллектива склада, Они должны быть заинтересованы в успехе внедрения. Но мотивация персонала – это уже другая тема…
Семинар на тему: "Складская логистика торгового предприятия" с участием Виктора Барановского будет проходить 21-22 мая в городе Киеве.
По вопросам регистрации: Тел: [відкрити контакти] , [відкрити контакти] Факс: [відкрити контакти] .
CallSend SMSAdd to SkypeYou'll need Skype CreditFree via Skype
Коментарі
Невірно заповнені поля відзначені червоним.
Будь ласка, перевірте форму ще раз.
Ваш коментар відправлений і буде доступний на сайті після перевірки адміністратором.
Інші статті в категорії Новини