Опыт внедрения MES: ошибки, инсайты, практические советы

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

ИТ-директор пищевого предприятия, аналитик и два эксперта по внедрению честно рассказывают, где будет больно даже после десятков успешных проектов.

На пищевом производстве начальник цеха — человек, который делает все, чтобы фура с колбасой уехала в Волгоград сегодня. Это важнее любого совещания, даже если он прописан как функциональный заказчик. Он перенесет встречу. И еще раз. Проект буксует: «Пилу точить некогда: лес валить надо».

Будьте к этому готовы. Даже если вы четко распределили роли до старта и заказчик вам отдал файл с пофамильным распределением, произойдет примерно так:

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

Иногда в процессе внедрения становится ясно, что нужно подключать к проекту еще несколько цехов. Тогда функциональных заказчиков и потребителей станет еще больше.

Что делать?
Заранее заложить время на занятость заказчиков. Не ждать, что они бросят все свои дела и сразу пойдут на контакт.

MES — это дорого. На этапе планирования кажется: программист и аналитик со стороны справятся, ведь они обязаны сделать систему, которая работает. Зачем еще тестировщик и инженер по качеству внутри компании?

В итоге аналитик берет на себя лишние функции, зашивается, внедрение идет медленнее, а потом старые системы падают, прогресс откатывается назад.
Были бы автотесты, проблем бы не было. Но проект уже идет, и бюджета на дополнительных специалистов никто не даст.

Что делать?
Включать инженера по качеству в команду с первого дня. Не экономить на тестах — это экономия в будущем. Автотесты — страховка для системы и для ИТ-службы.

Голубая мечта аналитика — взять «коробку» (базовый продукт), пройти все участки по очереди и выдохнуть. Но так не бывает, потому что MES раскрывается по мере внедрения.

Чем дальше, тем больше пожеланий от функциональных заказчиков. Это хорошо — значит, система нужна. Значит, ее используют. Но если слушать всех бесконечно, проект застрянет.

Что делать?
Максимально точно определить и договориться на хороший MVP.

Сделать сначала колесо от машины, потом руль, потом двигатель — плохой MVP, потому что MVP — не разрозненные куски системы, а целостное решение минимального объема, решающее конкретную бизнес-боль.

При этом сделать сначала скейтборд, потом самокат, потом велосипед — тоже плохое MVP. Вроде бы на каждом этапе сдается то, что едет, но по факту вы каждый раз с нуля полностью переделываете решение.

Тогда какой MVP — хороший? Например, мы хотим дачу. Выясняем у заказчиков, что дача нужна для того, чтобы приехать туда на майские праздники, пожарить шашлыки. Тогда MVP — построить дачный домик с мангальной зоной, а в дом поставить стол и стулья, чтобы шашлыки съесть. Когда все готово, MVP выполнен.

Если в процессе пользователь поймет, что летом ему нужно приезжать на дачу с пятницы по воскресенье и для этого нужна хорошая спальная зона с качественной кроватью, это уже не часть MVP, а этап обогащения. Туда же можно вынести красивые занавески и вазы (перекрашивание кнопок и другие улучшения юзабилити).

На пищевом производстве MVP должно полностью замещать старый процесс. Если мастер смены вынужден дублировать данные в Excel — значит, это был плохой MVP.

Промышленные киоски, терминалы сбора данных, весы, защищенные корпуса, сетевая инфраструктура — критичная часть MES.

Выбор, сроки поставки (четыре месяца — реальность), адаптация под условия цеха (грязь, влага) и размещение в цеху (боксы занимают место!) требуют огромного внимания и времени.

Что делать?
Заключать договоры с поставщиками стоит на этапе моделирования системы, иначе задержки гарантированы.

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

Если оставить их в стороне, проект застрянет. Они — те, кто реально работает, и их сопротивление — главный барьер.

Что делать?
Вовлекать их с первого дня. Не просто дать роль в документах, а слушать, донастраивать интерфейсы под их запросы. Показывать личную пользу: «Это нужно тебе, чтобы было проще и быстрее». Сделать так, чтобы они почувствовали: это инструмент, а не чужая навязчивая система. И самое важное — фиксировать пожелания, но внедрять их поэтапно, после достижения MVP.

Обучение тоже часть вовлечения. Стандартные методы — видеоуроки и подробные инструкции — не всегда работают. Уровень экспертности и вовлеченности у работников разный. Значит, нужно учить их прямо на линии. В этом помогут короткие заламинированные чек-листы с картинками, которые можно повесить прямо на рабочем месте, и тренер, который поможет быстро разобраться, в какой последовательности и куда нужно нажать.

Классно, если мастер говорит своему оператору: «Смотри, тут я специально для тебя попросил вот эту кнопку зеленым покрасить, а вот эту — желтым, чтобы тебе удобнее было».

Без этапа «влюбление пользователя» даже самая классная система останется чужой, а внедрение — борьбой, а не ростом.