Каталог предприятий

 

Складской учет и документооборот

17.11.2008

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

Оценка
Эксперты:
2.00
Анонимы:
2.00
Просмотров:
5303
Комментариев:
0
vktr аватар
(рейтинг: 3.00/2.20)

 

  

-  Не знаю, наверно случайно».

Мой знакомый завскладом – про единственный успешно сведенный пакет накладных на автомобиль доставки, в первый день работы склада в новой системе

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

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

 

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

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

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

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

- в одной руке – ТСД

- во второй руке – стилус терминала (вводим количество штук)

- в третьей руке – отбираемый товар

- в четвертой руке – емкость для отбора товара (коробка или корзинка с ручкой) или поручень толкаемой тележки

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

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

  1. Проанализируйте, что вам НЕ показали. Например, «за кадром» часто остаются вопросы:

-  пополнения зоны активного хранения (кто, как, когда)

- выполнения правил партионного учета

- количества «внутренних» документов в системе и необходимого для этого ресурса (сколько операторов учета придется добавить в штат склада при переходе на ячеистую струткуру склада? Хорошо, если одного..)

- работы с товаром, имеющим больше одного штрихкода

- работы со штрихкодом, который встречается на нескольких товарах

       4. ОБЯЗАТЕЛЬНО!! Отработка исключений. Каким образом поставщик может продемонстрировать помехоустойчивость и эластичность своего продукта?

 

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

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

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

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

- увлечение моделизмом. Построение максимально подробной модели работы склада в данный момент, причем для анализа собранной информации нужно потратить тоже весьма значительное время. КПД этой работы может оказаться весьма низким, по причине ОЧЕНЬ низкого соотношения полезной информации к общему объему полученного многостостраничного опуса. Простые вещи не стоит называть сложными терминами и пространно описывать ну уж совсем базовые операции.  

 

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

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

 

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

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

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

Например, на рисунке фрагмент блок-схемы:

 блоксхема

Теперь понятно, как мы планируем организовать действия работника при сканировании товара на приеме. Что в этой схеме, кстати, не описано?  Действия в случае «несколько штрихкодов у товара» и «несколько товаров имеют одинаковый штрихкод».

 

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

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

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

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

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

 

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

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

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

- динамическое складирование (забыли персоналу склада объяснить, что это такое, и почему постоянно перемещается системой товар по складу)

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

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

- отгрузка товара из всех хранимых на складе партий (система выдержала, а вот персонал склада не оценил такой продвинутый сервис для клиентов).

 

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

         Тщательная проработка планируемых бизнес-процессовважное условие успеха

         Ограничения на «полет фантазии» заказчика – исходя из здравого смысла и настройки на простоту процессов как залог их надежности

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

         Стандартизация склада под единую структуру адресации мест хранения

         Тесное взаимодействие с другими функциональными группами, взаимный поиск оптимальных решений.

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

 

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

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

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

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

 – максимально быстро вручную исправить ситуацию

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

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

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

 

 

«- Как у тебя это получилось?