Почему внедрение ERP проваливается: через три месяца сотрудники возвращаются к Excel

Через несколько месяцев после запуска новой ERP-системы на большинстве производств происходит одно и то же: возвращаются таблицы Excel. Складские остатки перестают сходиться с тем, что показывает система. Планировщики закладывают лишние буферы, потому что цифрам больше никто не доверяет. Снабженцы ведут свои записи «на стороне», мастера пропускают проводки, лишь бы не останавливать цех. А руководство смотрит на всё это и решает, что внедрение провалилось.

Картина повторяется на заводах с оборотом от 50 млн долларов до многомиллиардных корпораций – разные ERP-платформы, разные управленческие команды, один и тот же сценарий. И почти всегда дело не в программе.

Настоящий сбой в софте – редкость. Ли Стаут, основатель консалтинговой компании Staudt Solutions, вспоминает единственный такой случай из своей практики на крупнейшем в мире производстве портативных спа-бассейнов. Компания переходила с ERP среднего сегмента на систему высшего уровня. Примерно через три месяца после запуска начал пропадать материал – дефицит по десяткам позиций обрушился разом. Цех перешёл в режим аврала: снабженцы накидывали количество поверх того, что рекомендовал MRP, срочные закупки стали нормой, и никто не мог объяснить, почему только что внедрённая система делает хуже, а не лучше.

Причину удалось найти, прогоняя сценарии в тестовой базе и последовательно отсекая переменные. При частичном приёме заказа на закупку система молча переставала считать остаток по заказу источником поставки – и планирование не могло понять, почему цифры «плывут». Доказать, что виноват софт, а не сами сотрудники, заняло месяцы; в итоге вендор выпустил патч. По словам Стаута, это единственный раз за всю его карьеру, когда виновата оказалась действительно программа.

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

«Я обожаю перемены – до тех пор, пока они не касаются меня».

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

Когда после внедрения всё идёт наперекосяк, первым делом стоит пройтись по цеху и посмотреть, чем на самом деле пользуются операторы. Есть ли обходные пути и почему они появились – ответ на этот вопрос говорит почти обо всём. Руководство обычно винит последнее изменение, то есть само внедрение. Но в девяти случаях из десяти оказывается, что бизнес не разобрался со своими процессами заранее: система встала поверх сломанных или нигде не описанных рабочих схем, и вовремя этого никто не заметил.

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