Коротко
ERP-внедрения проваливаются, когда их ведут как IT-проекты, хотя они меняют работу всего бизнеса. Софт редко бывает причиной: итог решают охват, данные, подготовка людей и внимание руководства.
Каждый разбор провалившегося ERP-проекта читается одинаково. Вендор винит клиента, клиент винит интегратора, интегратор винит объем работ. А где-то посреди программы стоимостью в миллионы управляющий комитет тихо перестает собираться.
ERP-внедрения проваливаются, потому что компании ведут их как IT-проекты, хотя по сути это изменение бизнеса. Систему строят вокруг процессов, которые никто не хочет менять, силами команд, которых никто не слушает, под руководством тех, кто отходит в сторону после старта.
Каждый крупный ERP-вендор продает одно обещание: примите стандартные процессы и получите десятилетия отраслевого опыта. На этапе продажи это звучит как зрелость. При внедрении обещание сталкивается с бизнесом, который не хочет менять то, как признает выручку, закрывает месяц или ведет склад, пока на этом не настоит кто-то из руководства.
Подразделения просят доработок, чтобы сохранить привычные процессы. Интегратор соглашается, потому что запросы на изменения приносят ему деньги. Вскоре стандартное внедрение превращается в подобие старой системы, которую оно должно было заменить, только дороже в поддержке. Доработки здесь симптом. Причина в том, что никто не решил, какие процессы действительно отличают компанию.
Большинство ERP-программ держится на трех сторонах: вендор софта, интегратор и клиент. Вендор получает выручку за лицензии при подписании. Интегратор зарабатывает на часах. Клиенту, обычно в лице CIO или финансового директора, сказали, что бизнес-кейс сходится при заданном бюджете.
Такая схема поощряет оптимизм при оценке. На воркшопах по требованиям всплывают модули, интеграции и частные случаи, которых не было в техническом задании. Интегратор им рад, вендор продает больше лицензий, а клиент соглашается, потому что остановка означала бы признать ошибку в плане. По прогнозу Gartner, к 2027 году больше 70% недавно внедренных ERP-инициатив не достигнут в полной мере своих исходных бизнес-целей.
В каждом плане ERP-программы есть строка «миграция данных». Обычно она стоит ближе к концу, получает малую долю бюджета и достается команде с наименьшим политическим весом. Именно здесь проект начинает проваливаться, задолго до того, как это кто-то заметит.
Мастер-данные почти всегда хуже, чем признают. Записи о клиентах дублируются в разных системах, коды материалов значат разное на разных заводах, план счетов по-разному сопоставлен в разных юрлицах. Когда такие данные попадают в новую систему, она повторяет их ошибки, и пользователи перестают ей доверять уже в первом отчетном цикле. Ни SAP, ни Oracle, ни 1С не исправят мастер-данные, которые годами никто не чистил.
Когда ERP-программа выходит за бюджет, сокращения идут по одной схеме. Лицензии подписаны, часы интегратора трудно тронуть, инфраструктура фиксирована. Поэтому режут строку, за которой не стоит договор: управление изменениями. Обучение сокращают, поддержка внедрения исчезает.
По данным бенчмарков Prosci, 88% проектов с отличным управлением изменениями достигли целей или превзошли их, а при слабом управлении изменениями таких было 13%, примерно в семь раз меньше. ERP задает, как тысячи людей будут завтра работать иначе, чем вчера. Если урезать работу, которая этому учит, запуск становится началом падения производительности.
Сценарий знаком. CEO открывает программу, управляющий комитет первый квартал собирается каждую неделю. Потом внимание переходит к следующему приоритету, и встречи становятся ежемесячными, затем ежеквартальными, затем «по необходимости».
Решения, которым нужен руководитель (отказать в доработке, переубедить главу подразделения, заменить слабого руководителя направления), копятся, и снять их некому. Программа уходит под ответственность IT. Софт работает, бизнес не изменился, а итог называют успешным техническим внедрением с трудностями в использовании.
Обычное возражение: все решает выбор вендора. Взяли SAP, когда нужен был Oracle, выбрали облако, когда нужен был on-premises.
Опыт внедрений говорит о другом. Компании, которые умеют внедрять, обычно добиваются успеха на разных платформах, а те, у кого не получается, повторяют неудачу на каждой. Дисциплина внедрения, готовность данных, управление со стороны руководства и способность к изменениям объясняют итог сильнее, чем платформа. Обвинение вендора объясняет прошлый провал и готовит следующий.
Финансируйте управление изменениями как основной поток работ, потому что счета за лицензии и интегратора поглотят любую долю бюджета, которую им позволят. Держите управляющий комитет на всю длину программы, с названными правами на решения и путями эскалации, которые не зависят от календаря CEO.
Начинайте чистить данные задолго до первого скрипта миграции. Отказывайтесь от доработок в процессах, которые не отличают вас от конкурентов: order-to-cash, procure-to-pay и record-to-report редко отличают. В Казахстане сценарий тот же на 1С, SAP и Oracle: доработки ради старых процессов, недофинансированная миграция данных и спонсоры, которые отходят, когда стратегия переходит в исполнение.
Чаще всего итог предсказывает спонсор, который отошел от программы. Технические проблемы поправимы, а программа, потерявшая поддержку руководства после старта, восстанавливается редко. Готовность данных и подготовка людей идут следом.
Ведите его как основной поток работ с отдельной строкой бюджета: обучение, перестройка процессов, ключевые пользователи и поддержка после запуска. По данным бенчмарков Prosci, цели достигли 88% проектов с отличным управлением изменениями и 13% проектов со слабым. Размер считайте от числа людей, чья работа меняется.
Меньше, чем кажется на этапе выбора. Компании, которые умеют внедрять, обычно добиваются успеха на разных платформах, а остальные повторяют неудачи. Большую часть итога решают дисциплина внедрения, управление, готовность данных и способность к изменениям.
Задолго до первого запуска скрипта миграции в тестовой среде. Чистка, устранение дублей, единые коды для всех юрлиц и правила управления данными должны появиться до переключения.
Нет. Оставьте ее для процессов, которые действительно отличают компанию. Order-to-cash, procure-to-pay и record-to-report почти никогда к ним не относятся. Решите, какие процессы особенные, до того как пойдут запросы, и дайте управляющему комитету право отказывать в остальном.
Запуск ERP назначают на дату. Система, на которой работает бизнес, держится на решенных процессах, чистых мастер-данных, обученных людях и спонсоре, который остается. Команда opengate проверяет управление, готовность данных и способность к изменениям до подписания первой лицензии, а затем проектирует и разрабатывает интеграции и софт вокруг ERP. Начните с одного процесса, а мы измерим, что он дает.
