Риски при выборе интегратора ERP: 7 типичных ошибок и способы их предотвращения

По статистике отраслевых экспертов, до 70% проектов по внедрению ERP на российских заводах выходят за рамки бюджета или сроков, а около 15% признаются полностью провальными. Основная причина — не техническое несовершенство ПО, а системные ошибки при выборе и управлении интегратором.

Ошибка 1: Погоня за минимальным коммерческим предложением

Разрыв в стоимости между демпингующим интегратором и рыночным специалистом может достигать 30-50%. В ERP-проектах стоимостью от 10 млн рублей экономия на старте в 3 млн обычно оборачивается дополнительными затратами в 7-10 млн на этапе исправления архитектурных ошибок. Типичный сценарий: подрядчик занижает стоимость этапа обследования, чтобы зайти в проект, а затем выставляет счета за каждый «дополнительный» бизнес-процесс, который он «забыл» учесть.

Экспертный вывод: выбирайте средний ценовой сегмент с детальной сметой. Слишком низкая цена — маркер того, что интегратор либо не понимает сложности вашего производства, либо планирует зарабатывать на бесконечных Change Requests.

Ошибка 2: Отсутствие выделенного архитектора в команде

Многие предприятия нанимают «команду консультантов», где функции архитектора выполняет руководитель проекта (РП). Это критическая ошибка. В проектах масштаба 50+ пользователей без архитектора возникает «лоскутная автоматизация»: модули закупок, склада и производства работают разрозненно. Кейс: завод по производству металлоконструкций потратил 1,5 года на внедрение, но из-за отсутствия единой модели данных расчет себестоимости единицы продукции отклонялся от реальности на 12-18%.

Экспертный вывод: роль архитектора в команде интегратора обязательна. Если его нет в штатном расписании проекта — вы получите набор разрозненных таблиц вместо ERP.

Ошибка 3: Доверие к «коробочным» срокам и функционалу

Интеграторы часто обещают запуск «базового функционала» за 4-6 месяцев. Однако для реального производства доля типового функционала редко превышает 60-70%. Остальное — доработки под специфику (нормы расхода, техпроцессы, маршрутные карты). Игнорирование этого факта ведет к тому, что система запускается в эксплуатацию, но сотрудники продолжают вести учет в Excel, так как ERP не закрывает их базовые потребности.

Экспертный вывод: закладывайте +30% времени к оптимистичному сроку интегратора и требуйте детального разбора разницы между «коробкой» и вашими требованиями еще на этапе пресейла.

Ошибка 4: Неправильный выбор модели оплаты

Попытка зафиксировать стоимость всего проекта через Fixed Price в условиях отсутствия детального ТЗ — путь к конфликтам. Интегратор закладывает в фиксированную цену огромные риски (до 40%), либо начинает жестко резать функционал, чтобы не уйти в минус. В то же время чистый Time & Materials без лимитов превращает бюджет в «черную дыру». Оптимальный вариант — гибридная модель: Fixed Price на обследование и проектирование, и T&M; с верхним лимитом (Cap) на разработку.

Экспертный вывод: используйте фиксированную стоимость только для этапов с четким измеримым результатом. Весь остальной цикл лучше вести по часам с жестким контролем KPI.

Ошибка 5: Игнорирование отраслевого опыта в портфолио

Интегратор, который успешно внедрил ERP в ритейле, может полностью провалиться на машиностроении. Разница в подходах к учету затрат, управлению незавершенным производством (НЗП) и планированию ресурсов (MRP) колоссальна. Ошибка проявляется на этапе настройки спецификаций: если консультант не знает, что такое «технологическая карта» или «переделка», он настроит систему так, что она будет работать по логике магазина, а не цеха.

Экспертный вывод: проверяйте портфолио именно по вашему коду ОКВЭД. Один кейс в вашей нише с реальным промышленным запуском ценнее десяти внедрений в смежных областях.

Ошибка 6: Отсутствие стратегии поддержки после запуска

Типичный провал: проект завершается «актом приемки», и интегратор исчезает. В первые 3-6 месяцев после промышленного запуска выявляются критические баги, которые блокируют отгрузки или расчет зарплаты. Стоимость экстренного вызова специалиста по модели «по запросу» в 2-3 раза выше, чем по сервисному контракту (SLA). Без четкого регламента поддержки система деградирует за полгода, так как пользователи находят обходные пути вместо исправления ошибок.

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

Ошибка 7: Перекладывание ответственности за ТЗ на подрядчика

Фраза «вы же эксперты, сами напишите ТЗ» — самая дорогая ошибка заказчика. Интегратор опишет систему так, как ему удобнее её внедрить (используя стандартные инструменты), а не так, как работает ваш бизнес. В итоге через год выясняется, что ключевой бизнес-процесс по контролю качества продукции просто не автоматизирован, так как он не был отражен в ТЗ, которое писал сам исполнитель.

Экспертный вывод: ТЗ — это документ заказчика. Интегратор может помогать в его оформлении, но финальная ответственность за описание бизнес-процессов лежит на вашем внутреннем команде или приглашенном независимом аналитике.

Вывод

Чтобы минимизировать риски, откажитесь от поиска «самого дешевого» и перейдите к оценке технического бэкграунда команды. Начните с найма независимого архитектора или проведения глубокого аудита ваших процессов перед тендером. Избегайте Fixed Price на неопределенных этапах и требуйте в портфолио подтвержденные кейсы именно в вашем производственном секторе. Лучшая стратегия — гибридная модель оплаты и жесткий контроль контрольных точек проекта, где оплата привязана к фактическому работоспособному функционалу, а не к дате в календаре.