Ошибка №1 при внедрении WMS: документ, который стоит очень дорого

Вторник. Третий день тестового запуска новой WMS на складе.

Сеть стабильна, ТСД настроены, сотрудники мотивированы. Команда внедрения со стороны Заказчика и Исполнителя прогоняет сценарии и обучает ключевых пользователей - тех, кто будет работать в системе каждый день.

Казалось бы, всё идет по плану.

И вдруг со склада звучит вопрос:

— А как мы теперь будем печатать упаковочный лист после отбора?

Директор по логистике (он же руководитель проекта), господин N, спокойно отвечает:

— Так же, как и раньше. С ТСД.

Но тут в разговор вмешивается команда внедрения.

Они открывают документ, который все на проекте называют «Дизайн» и показывают: про печать упаковочного листа с ТСД там нет ни слова.

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

Господин N искренне возмущается:

— Так неудобно же. Люди будут постоянно бегать к компьютеру.

Ответ команды внедрения простой:

— В дизайне проекта этого требования нет.

Я называю эту сценку: последствия чрезмерного оптимизма на этапе подписания одного из самых важных документов проекта.

Этот документ называют по-разному:

· Технический проект

· Функциональный дизайн

· Проектное решение

Но смысл всегда один. В этом документе фиксируется, как именно бизнес-процессы будут реализованы в новой системе.

Если на этапе обследования мы описываем процессы как они есть, то в дизайне проекта фиксируется как они будут работать после внедрения.

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

А значит любое изменение на позднем этапе становится долгим, дорогим и болезненным для проекта.

Многие руководители думают, что это просто технический документ. На практике это не так.

Дизайн проекта требует проработки сразу двух вещей:

· технической реализации

· бизнес-процессов

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

В идеальном мире на складе уже существуют хорошо выстроенные процессы, которые нужно просто оцифровать. Но в реальности чаще происходит иначе.

Процессы начинают по-настоящему прорабатываться именно в момент внедрения системы.

Поэтому обсуждение дизайна - не только разговор с руководителем склада или директором по логистике. К обсуждению обязательно нужно подключать:

· ключевых пользователей

· операторов

· смежные подразделения

· иногда даже тех, кто взаимодействует со складом косвенно.

Представим ситуацию: компания-дистрибьютор не принимает товар с остаточным сроком годности ниже установленного лимита.

Раньше процесс выглядел так:

· Оператор видит, что ОСГ ниже лимита

· Звонит в отдел закупок

· Получает подтверждение

· Вручную меняет процент ОСГ в заказе

· Склад принимает товар

После обсуждения дизайна процесс меняется.

Теперь:

· Кладовщик на ТСД фиксирует нарушение ОСГ

· Система отправляет уведомление в отдел закупок

· Закупки должны подтвердить приемку в системе

· Только после этого склад может принять товар

С точки зрения склада всё логично и удобно. Но возникает простой вопрос: а отдел закупок вообще знает, что их процесс изменился? И еще один после ответа на первый: как быстро они будут реагировать в системе?

Нажать кнопку в программе - вроде мелочь. Но на практике может оказаться, что:

· менеджер не видит уведомление

· у него нет доступа

· он проверяет систему раз в час

· или ему просто быстрее ответить на звонок.

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

Есть ещё один важный момент. Внедрение системы почти всегда меняет процессы, даже если они были хорошо выстроены.

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

Но именно поэтому дизайн проекта нужно читать в два раза внимательнее. И желательно делать это не в одиночку.

Лучше дать документ:

· руководителям участков

· ключевым пользователям

· смежным отделам.

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

После запуска системы цена ошибки становится совсем иной.