Смена подрядчика в середине ERP-проекта увеличивает итоговый бюджет на 30–50% и сдвигает сроки запуска минимум на 3–6 месяцев из-за необходимости аудита «наследия». Ошибка многих руководителей — пытаться забрать код и настройки силой, не понимая, что без актуальной технической документации стоимость восстановления логики процессов вырастет в разы.
Точки невозврата: когда менять интегратора необходимо
Переход к новому партнеру оправдан, если за 3–4 месяца не закрыт ни один этап (Milestone) или отклонение от базового функционала (Out-of-the-box) превысило 40% без четкого обоснования. Типичный кейс: завод по производству металлоконструкций сменил подрядчика на этапе настройки MRP, когда за 6 месяцев было описано 200 страниц ТЗ, но в системе не заработал ни один расчет потребности в материалах. Результат — простой команды внедрения стоимостью 1,5–2 млн руб. в месяц.
Экспертный вывод: если бизнес-аналитик подрядчика не может продемонстрировать работающий прототип процесса в системе через 2 месяца после обследования, проект находится в зоне риска. Продолжать работу в надежде на «рывок» бессмысленно — вы просто оплачиваете обучение сотрудников интегратора за свой счет.
Инвентаризация активов: что забирать у старого подрядчика
Главный риск при миграции — потеря интеллектуального слоя (Knowledge Base). Вам нужны не только исходные коды и SQL-скрипты, но и матрица прослеживаемости (Traceability Matrix), где требование бизнеса связано с конкретной настройкой в ERP. Без этого новый исполнитель потратит до 20% бюджета проекта на реверс-инжиниринг — попытки понять, почему система работает именно так. Обязательно требуйте актуальный реестр доработок и карту интеграций с внешними системами.
Пример: при передаче дел по блоку WMS отсутствие схемы потоков данных между ERP и ТСД привело к тому, что новый подрядчик перенастроил логику приемки с нуля, потратив 400 человеко-часов (около 600–800 тыс. руб.), хотя функционал был частично реализован. Экспертный вывод: передача проекта без описания архитектурных решений — это передача «черного ящика», за разблокировку которого новый партнер потребует двойную ставку.
Экономика перехода: скрытые расходы и сроки
Стоимость смены подрядчика складывается из трех компонентов: штрафные санкции по текущему договору (обычно 5–10% от суммы этапа), оплата аудита текущего состояния новым партнером (от 300 тыс. до 1,5 млн руб.) и стоимость переделки ошибок. В среднем, 15–25% кода, написанного некомпетентным разработчиком, приходится удалять и писать заново, так как попытки «допилить» кривой код стоят дороже, чем его полная замена.
Сравнение вариантов: «Мягкий переход» (параллельная работа двух компаний 1 месяц) стоит дороже в моменте, но сокращает риск остановки бизнеса на 80%. «Резкий разрыв» экономит бюджет сегодня, но создает риск потери доступа к серверам или базам данных, что может парализовать отгрузки на заводе на 2–3 дня. Экспертный вывод: выбирайте модель с перекрытием в 3–4 недели, даже если это увеличивает текущие расходы на 5–7%.
Технический аудит: как проверить нового кандидата
При выборе нового партнера для «спасения» проекта стандартный чек-лист не работает. Вам нужен опыт именно в реструктуризации чужих ошибок. Проверьте, есть ли у них компетенции по автоматизации планирования производства: MRP I vs MRP II на практике, так как именно здесь чаще всего происходят фатальные сбои в логике. Запросите кейсы, где компания заходила в проект на стадии 50% готовности и успешно его закрыла.
Кейс: компания по производству электроники при выборе нового интегратора потребовала провести экспресс-аудит текущей базы за 5 рабочих дней. Подрядчик за этот срок нашел 12 критических ошибок в архитектуре учета затрат, которые привели бы к искажению себестоимости на 10–15%. Экспертный вывод: если новый кандидат говорит «мы всё исправим и запустим быстро» без глубокого технического анализа текущего кода — это признак того, что вы повторяете ошибку с первым подрядчиком.
Юридическая защита и передача прав
Критически важно, чтобы в договоре с первым подрядчиком был закреплен пункт о передаче всех прав на интеллектуальную собственность (доработки, конфигурации) по мере их оплаты, а не после закрытия всего проекта. В противном случае при конфликте интегратор может заблокировать доступ к кастомным модулям или требовать выкуп кода по завышенной цене (в 2–5 раз выше рыночной стоимости разработки).
Рекомендация: перед уведомлением о расторжении договора сделайте полный бэкап всех баз данных, конфигураций и документации на собственные серверы. В 30% случаев конфликтов подрядчики ограничивают доступ к общим папкам или Jira/Confluence в первый же день ссоры. Экспертный вывод: технический контроль над данными должен быть у заказчика с первого дня проекта, а не у партнера по внедрению.
Вывод
Смена подрядчика — это хирургическая операция, которая оправдана только при системном провале компетенций. Чтобы не утопить бюджет, начните с независимого технического аудита текущего состояния (gap-анализа), заберите все архитектурные схемы и только потом подписывайте договор с новым партнером. Избегайте «дешевых» спасателей, которые обещают быстрый запуск без анализа ошибок предшественников — в 90% случаев это ведет к повторному краху проекта через 3–4 месяца. Оптимальный путь: аудит → фиксация остатков → передача прав → постепенный запуск с новым интегратором.