Этот проект я вспоминаю как один из самых болезненных и поучительных за всю карьеру. Внедрение ERP-системы в крупной государственной корпорации — на бумаге всё выглядело как образцово-показательная цифровая трансформация. Миллиардный бюджет, западный вендор, армия консультантов, поддержка топ-менеджмента. А в итоге — провал, который все предпочли тихо забыть. В системе никто не работал, процессы остались старыми, пользователи злились, а ИТ-служба просто выгорела.
И я не рассказываю эту историю, чтобы кого-то обвинить. Скорее наоборот — чтобы поделиться тем, чему я научился. Потому что если мы будем замалчивать такие факапы, мы так и будем наступать на одни и те же грабли. А ведь ERP — это не просто софт. Это хирургия на живом организме бизнеса. И если подходить к ней формально — всё развалится.
В этой статье я расскажу:
- Почему в реальности ERP-проекты чаще всего не про технологию, а про власть, страх и контроль;
- Какие 5 ключевых ошибок мы допустили (и допускают тысячи других компаний);
- И что мы могли бы сделать, чтобы не допустить тотального провала.
Если ты когда-либо был вовлечён во внедрение сложной системы — тебе многое покажется знакомым. А если только готовишься — возможно, эта история убережёт тебя от потерь. Потому что в отличие от успехов, именно провалы учат по-настоящему.
Причина 1: Отсутствие владельца результата
Один из главных парадоксов этого проекта — при всей его масштабности и стоимости, у него не было настоящего “хозяина”. Формально был спонсор, был проектный офис, был интегратор. Но вот человека, который сказал бы: “Я отвечаю, чтобы это заработало у нас в компании и принесло эффект”, — не было.
В ERP-проектах это критично. Потому что сама система — это не коробка, которую можно просто установить. Это способ изменить то, как работает организация: как принимаются решения, как двигается информация, как контролируются ресурсы. И без человека, который будет бороться за результат, защищать интересы бизнеса, выравнивать конфликты между ИТ, финслужбой, логистами, кадрами — система превращается в набор модулей, где каждый тащит одеяло на себя.
На практике это выглядело так:
- Руководитель отдела снабжения говорил: “Я не понимаю, зачем мне этот новый интерфейс, мои люди и так в Excel всё считают”.
- Финансовый директор требовал загрузку в 1С в старом формате, потому что “бухгалтеры привыкли”.
- Руководитель по ИТ жаловался, что “опять на нас всё скинули, а где бизнес?”
И все были в чём-то правы. Но никто не был единым голосом, который бы держал всю конструкцию в фокусе. Не было человека, который бы сказал: “Мы хотим, чтобы через 6 месяцев все закупки шли через ERP, и вот что это даст: прозрачность, контроль, экономию. И я отвечаю, чтобы это случилось”.
В итоге внедрение шло по инерции. Каждый участок делал “свою часть”. Никто не смотрел на общую картину. Никто не ставил цель выше своего комфорта. А значит, никто не защищал ценность, ради которой всё затевалось.
Что нужно было сделать? Назначить бизнес-владельца результата. Не ИТ-директора, не формального “sponsor”, а топ-менеджера, которому реально важно, чтобы бизнес стал эффективнее. И дать ему власть и полномочия вести за собой функциональных руководителей. Без этого ERP-проект — это как стройка без архитектора: материалы есть, подрядчики есть, деньги есть, а что строим — непонятно.
Причина 2: “Внедряем систему, а не меняем процессы”
Это была, пожалуй, самая коварная ошибка. Все силы были брошены на то, чтобы “внедрить систему”: настроить модули, наладить интеграции, загрузить справочники. Консультанты проводили воркшопы, рисовали схемы, писали документацию. Только никто не задал себе один простой вопрос:
“А на что именно мы хотим автоматизировать текущие процессы? Они вообще пригодны для этого?”
В итоге получилось вот что: старые, костные, неэффективные процессы просто запихнули в новую оболочку. Вместо “цифровой трансформации” получилась “цифровая бюрократия”.
Типичный пример — закупки. В компании была запутанная, многоступенчатая процедура согласования заявок, которая могла растягиваться на недели. Вместо того чтобы её оптимизировать, мы просто перенесли её в ERP. Но теперь ещё и интерфейс добавился. Люди жаловались: “Раньше мы в Excel за 15 минут всё делали, а теперь три экрана, пять кликов и всё зависает”.
Или другой случай — кадровый модуль. Внедрили систему расчёта KPI. Только KPI были прописаны в формате “Сократить издержки на 5%”, без привязки к действиям и данным. Автоматизация этих цифр была бессмысленна — потому что сами правила игры никто не пересмотрел. А сотрудники продолжали вручную “рисовать” нужные показатели, лишь бы система дала премию.
И вот тут проявился главный симптом: пользователи не переходили на систему, потому что она не делала их жизнь проще. Она просто делала её другой. И хуже.
Почему так получилось? Потому что никто не начал с анализа и редизайна процессов. Никто не задался целью: “А давайте упростим, оптимизируем, уберём ненужное — и только потом автоматизируем”. В итоге ERP стала просто дорогим, сложным отражением хаоса, который и так был в компании. Но теперь его нельзя было исправить одним нажатием Delete — он был зацементирован в коде.
Что надо было делать? Сначала провести реинжиниринг процессов. Понять, как должен работать бизнес. Где узкие места. Где дубли. Где потери. И только после этого — автоматизировать. Не “внедрить SAP”, а “перестроить работу так, чтобы SAP реально приносил пользу”. Только тогда система становится инструментом, а не обузой.
Причина 3: Прямое политическое давление на сроки
Если бы мне дали рубль за каждый случай, когда сроки в проекте устанавливаются не по готовности команды, а по “надо к дню рождения министра” — я бы давно не занимался ERP, а где-нибудь выращивал виноград в Тоскане. Но шутки в сторону: в этом проекте срок запуска был обозначен жёстко и сверху, без обсуждений. “До 1 октября система должна работать. Без вариантов”.
И вот тут начался цейтнот. Не потому что команда плохо работала. А потому что весь проект подстроили под политическое ожидание, а не под реальный уровень зрелости и готовности.
Когда ты внедряешь ERP в госкорпорации — ты имеешь дело не просто с софтом, а с целым организмом: привычками, страхами, внутренними договорённостями, конфликтами интересов. Это не микросервис накрутить. Это пересобрать инфраструктуру управления. А такие вещи не делаются по команде “надо вчера”.
Что случилось из-за давления?
- Начали срезать этапы: вместо полноценного тестирования — “прогнали по тестовому сценарию”.
- Вместо пилота — сразу релиз на всех, потому что “так быстрее”.
- Документацию писали “по ходу” и часто постфактум.
- Обучение пользователей сократили до 2-часового вебинара “для всех”.
В итоге 1 октября кнопка “пуск” действительно была нажата. И что? Система зависла. Люди не знали, как в ней работать. Приказы оформляли вручную. Руководство получало отчёты в Excel, потому что ERP “ещё не всё считает”. И самое главное — все начали воспринимать проект как имитацию. Как игру в айтишечку ради галочки.
Вот в чём главная проблема жёсткого давления на сроки: оно уничтожает доверие. Команда начинает работать “на видимость”, а не на результат. Люди учатся обходить систему, а не использовать её. И вся логика управления — летит в трубу.
Можно ли было иначе? Да. Надо было с самого начала обозначить два трека:
- Политический — что-то показать к нужной дате, например, MVP на одном пилотном участке.
- Реальный — полноценное внедрение поэтапно, с тестами, доработками и поддержкой.
Тогда был бы шанс показать “картинку” и при этом не убить проект ради картинки. Но для этого нужно иметь смелость сказать наверх: “Мы не успеем качественно. Давайте сделаем это правильно”. А это, как ты понимаешь, отдельное искусство.
Причина 4: Переоценка зрелости организации
Одним из самых серьёзных и, пожалуй, самых незаметных рисков стала иллюзия зрелости. В отчётах всё выглядело красиво: регламенты есть, структура выстроена, ответственные назначены. Система управления проектами — формально внедрена. И казалось, что организация готова к масштабной цифровой трансформации. Но реальность, как это часто бывает, оказалась совсем другой.
Когда мы начали глубже вникать в процессы, выяснилось:
- Регламенты есть, но никто ими не пользуется. А в некоторых случаях они противоречат реальному порядку дел.
- Ответственные есть, но они не принимают решений, боятся брать на себя ответственность без одобрения сверху.
- Формально процессы прописаны, но все работают “по понятиям” — через личные связи, звонки, ручные корректировки.
- Уровень ИТ-грамотности у сотрудников крайне разный: от продвинутых пользователей до тех, кто Excel боится открывать.
- Между подразделениями — скрытая вражда. Каждый думает, что сосед тянет одеяло на себя. Ни о каком сотрудничестве речи не идёт.
В итоге ERP оказалась слишком “жёсткой” для такой среды. Она требовала дисциплины, прозрачности, точности. А организация была устроена иначе — через гибкость, обходные пути, договорённости. И что случилось? Началось массовое сопротивление.
- Кто-то “терял” доступы, чтобы отложить работу.
- Кто-то вводил данные с ошибками — якобы случайно.
- Кто-то продолжал работать по-старому, а данные в систему забивал формально, чтобы “галочка была”.
Это не саботаж. Это естественная реакция системы, которая не готова к такому уровню прозрачности. И проблема не в том, что люди плохие. Проблема в том, что мы не провели диагностику зрелости. Мы не поняли, что нужно не просто “обучить людей”, а перестроить культуру. А это долгий путь.
Что можно было сделать иначе? Перед началом проекта — провести реальный аудит организационной зрелости. Не по бумажкам, а по факту:
- Как принимаются решения?
- Насколько процессы живые?
- Кто реально влияет на работу?
- Есть ли доверие между функциями?
И уже от этого строить стратегию внедрения: где начать, кого подключить первым, как готовить среду. Потому что ERP — это не про технологии. Это про социальную инженерию. А если фундамент кривой — никакая система его не выровняет. Она просто быстрее покажет, где трещины.
Причина 5: Игнорирование сопротивления пользователей
Это, пожалуй, самая типичная и самая недооценённая ошибка в ERP-проектах. Все фокусируются на технологии: какой вендор, какие модули, какие API. Кто-то чуть более зрелый — думает о процессах. Но очень редко кто по-настоящему думает о людях. А ведь именно они будут (или не будут) работать в новой системе. И если ты не работаешь с их восприятием, страхами, привычками — ты получаешь ровно то, что получили мы: саботаж под видом вежливого молчания.
На словах всё шло гладко. Руководители говорили “поддерживаем проект”. Сотрудники приходили на обучение. В кабинетах звучали правильные слова. Но как только дело доходило до практики — система оказывалась пустой.
- Никто не вносил заявки.
- Документы шли параллельно — и по новой системе, и “как обычно, в бумаге”.
- Руководители отделов начинали давить: “Зачем вы мучаете людей? Мы и так успеваем по старому”.
Почему так происходило? Потому что людям не объяснили, зачем всё это. Никто не донёс смысла. Никто не показал, какую ценность система даёт им. Наоборот — она воспринималась как ещё один инструмент контроля. Как угроза. Как лишняя нагрузка. Как проект “для галочки”.
Более того, у нас почти не было настоящего обучения. Был один общий семинар. Было несколько PDF-инструкций. Но не было индивидуальной поддержки. Не было “своих людей” в подразделениях, которые могли бы реально помочь, объяснить, поддержать. Всё строилось по принципу: “Мы сделали — теперь вы пользуйтесь”. Только это не работает.
Результат? ERP стала “системой на всякий случай”. Официально — она внедрена. Отчёты наверх шли. Но реально решения продолжали приниматься в Excel, в переписках, в кулуарах. А сама система жила как отдельный параллельный мир. Без влияния на бизнес.
Что надо было делать?
- Начинать работу с пользователями до начала внедрения. Объяснять, показывать, вовлекать.
- Выделить агентов изменений — людей в каждом подразделении, которые поддержат трансформацию изнутри.
- Создать систему живой обратной связи: не “пишите в саппорт”, а “вот Вася, он рядом, он поможет”.
- Показывать “быстрые победы”: что стало проще, быстрее, понятнее.
ERP — это всегда психологический проект. Это про переход от “я сам контролирую” к “работаем по общей логике”. И если не управлять этим переходом — система будет формально внедрена, но никогда не станет рабочей. А это и есть самый дорогой вид провала. Когда ты вроде как сделал всё правильно — но по сути потратил кучу ресурсов на то, что никто не использует.
Разбор: что можно было сделать по-другому
Проект уже был в процессе, но даже тогда у нас был шанс спасти его. Я уверен: на любом этапе провального проекта можно принять решения, которые не исправят всё, но переломят ход событий. Главное — признать, что что-то пошло не так, и перестать делать вид, будто «всё по плану». Вот несколько шагов, которые мы могли (и должны были) предпринять, чтобы выйти из тупика.
1. Остановиться и провести переоценку
Мы продолжали бежать, потому что “сроки горят”. Но иногда лучший способ продвинуться — это остановиться и разобраться. В какой-то момент нужно было честно собрать ключевых стейкхолдеров и задать неудобные вопросы:
- Кто реально пользуется системой?
- Что конкретно не работает?
- Где затыки и саботаж?
- Кто наш реальный владелец результата?
Эта сессия могла бы стать точкой сброса напряжения и основой для перезапуска. Без неё мы просто загоняли проект дальше в болото.
2. Сделать “микроуспех” на одном участке
Вместо того чтобы мучить всю организацию — можно было сфокусироваться на одном-двух подразделениях, где были лояльные руководители и адекватные процессы. Сделать там пилот, довести до результата, показать эффект.
Это создало бы:
- Прецедент: “смотрите, можно работать по-новому и не сойти с ума”
- Внутренних “амбассадоров”, а не внешних консультантов
- Реальный кейс для руководства, а не презентацию со словами “внедрено”
3. Переформулировать цели проекта
Изначально цель звучала как “внедрить ERP-систему”. Формально. Технически. Без вдохновения. Надо было переформулировать:
- “Сократить время на согласование закупок в 3 раза”
- “Сделать данные по финансам прозрачными в реальном времени”
- “Освободить специалистов от ручного ввода и сводных таблиц”
Когда цель смысловая, а не формальная, у команды появляется мотивация. Возникает энергия. И пользователи начинают воспринимать систему не как инструмент давления, а как шаг вперёд.
4. Перезагрузить коммуникацию
Нужно было перестать делать вид, что всё хорошо. И начать говорить с людьми честно:
- “Да, мы видим, что система пока неудобна”
- “Вот, что мы улучшим в ближайшие 2 недели”
- “Вот, как ваша обратная связь помогает проекту”
Коммуникация — это не рассылка. Это диалог. И если его не выстроить, люди сами себе всё объяснят — и, как правило, не в твою пользу.
5. Укрепить внутреннюю проектную команду
Проект вёлся через внешних консультантов и подрядчиков. Внутри компании почти никто не был вовлечён по-настоящему. Это была огромная ошибка. Надо было:
- Назначить продуктовых владельцев от бизнеса
- Сделать проектную команду смешанной — из ИТ, бизнеса, пользователей
- Встроить эту команду в повседневную работу
ERP нельзя внедрить “извне”. Она должна вырасти изнутри. И чем раньше ты это поймёшь — тем больше у тебя шансов, что проект не станет ещё одной неудачей на полке с дорогими ИТ-инициативами.
Выводы и уроки
С тех пор прошло много лет. Были успешные проекты, были неудачи поменьше. Но именно этот случай с ERP я до сих пор вспоминаю как самый мощный урок. Потому что он научил меня главному: проект — это не технология, и не план. Это — люди, ответственность и честность с собой.
Вот что я точно усвоил:
- ERP — это не IT-проект. Если вы отдаёте его на откуп ИТ-отделу или подрядчику, вы уже проиграли. Это трансформация бизнеса. А значит, нужен лидер с полномочиями и реальным интересом в результате.
- Сначала меняются процессы и культура — потом внедряется система. Не наоборот. Нельзя “накатить SAP” на хаос. Он не станет от этого порядком. Он станет автоматизированным хаосом.
- Сроки не святые. Свято — качество и доверие. Лучше честно признать, что не готовы, чем завалить запуск ради политического отчёта.
- Уровень зрелости компании — это не красивые слайды. Это поведение людей в условиях неопределённости. Готовность брать ответственность. Способность работать прозрачно. Если этого нет — проекту нужно больше времени, больше поддержки и меньше пафоса.
- Сопротивление — это не саботаж. Это обратная связь. Люди не будут использовать систему, которую не понимают и не чувствуют как свою. Их нужно вовлекать, обучать, слышать.
И наконец — не бойся говорить о провале. Это не позор. Это часть профессии. Если ты работаешь на настоящих проектах, если ты не занимаешься симуляцией — у тебя будут ошибки. И чем больше ты их разбираешь — тем меньше их будет в будущем.
Мой призыв: делитесь. Рассказывайте. Анализируйте. Потому что провал, о котором никто не говорит — самый дорогой. Он не даёт уроков. А значит, он обязательно повторится.
P.S. Проект вымышленный и все совпадения с Вашей компанией случайны!