До 60% ERP-проектов выходят за рамки бюджета или сроков из-за того, что заказчик купил «красивую презентацию» вместо реальных компетенций команды. Чтобы не стать статистикой, нужно перевести разговор из плоскости маркетинга в технический допрос CTO интегратора, где каждый ответ проверяется конкретным кейсом.
Верификация архитектурного опыта через стек
Задайте вопрос о конкретном стеке интеграций в последних трех проектах. Если интегратор говорит «мы умеем всё», это красный флаг. Профессионал назовет конкретные инструменты: например, использование RabbitMQ или Kafka для асинхронного обмена данными между ERP и WMS-системой, чтобы избежать зависания интерфейса при передаче 10 000+ транзакций в час.
Кейс: компания внедряла ERP для завода с оборотом 2 млрд руб. Вместо прямой записи в БД (что убило бы производительность), они настроили шину данных. Результат: время отклика системы осталось в пределах 2 секунд при росте нагрузки на 40%. Мой вывод: если CTO не может описать схему потоков данных и выбрать между REST API и SOAP с аргументами по скорости, перед вами перепродавец лицензий, а не технический партнер.
Проверка компетенций по миграции данных
Миграция — это 20-30% общего бюджета проекта, но именно здесь зарыто большинство фатальных ошибок. Спросите: «Как вы обрабатываете дубли и неконсистентные данные при переносе из 1С 7.7 или legacy-систем?». Ожидайте услышать про ETL-инструменты, скрипты очистки и многоэтапную сверку (staging-зоны).
Пример: при переносе справочника номенклатуры на 50 000 позиций неопытный подрядчик просто импортирует Excel, создав 15% дублей. Профи внедряет алгоритм сопоставления по артикулам и характеристикам с ручной верификацией отклонений более 5%. Экспертный вывод: требуйте показать регламент миграции данных; если его нет, готовьтесь к остановке отгрузок на неделю после старта системы.
Оценка подхода к кастомизации и обновлениям
Критический вопрос: «Каков процент доработок ядра системы в ваших проектах и как они влияют на стоимость обновлений?». В идеале кастомизация не должна превышать 15-20% от стандартного функционала. Если интегратор пишет «всё под клиента», вы получите «зоопарк» кода, который невозможно обновить без затрат в 30-50% от стоимости внедрения каждые два года.
Сравнение: подход «Full Custom» дает идеальный интерфейс сегодня, но блокирует развитие системы завтра. Подход «Standard First» (использование стандартных модулей с минимальными надстройками) экономит до 1 млн руб. в год на поддержке. Мой вердикт: выбирайте тех, кто умеет перестраивать бизнес-процесс под систему, а не систему под привычки линейного персонала.
Методология управления изменениями и рисками
Спросите CTO, как они работают с сопротивлением пользователей и какие риски закладывают в график. Если в ответе нет упоминания матрицы ответственности (RACI) и плана обучения, проект рискует застрять на этапе опытной эксплуатации. Опытные команды закладывают 10-15% временного буфера на «непредвиденные доработки» в каждой фазе.
Кейс: внедрение в компании с 200 сотрудниками провалилось, так как сотрудники саботировали ввод данных. Интегратор, который внедрил систему «по инструкции», не заметил этого. Профи внедряют систему KPI для пользователей за корректный ввод данных. Экспертный вывод: техническая готовность системы — это лишь 50% успеха; остальные 50% — это управление людьми, и об этом должен думать техдиректор интегратора.
Проверка реальности кейсов и ресурсов
Запросите список конкретных специалистов, которые будут работать на вашем проекте, и их сертификаты. Часто компания продает опыт «звездных» архитекторов из презентаций, а на проект выводит джуниоров с опытом 1 года. Проверьте, сколько часов ведущего архитектора реально заложено в бюджет (обычно это 5-10% от общего объема часов).
Факт: разрыв в производительности между Senior и Junior консультантом в ERP составляет 3-5 раз. Если стоимость услуг кажется подозрительно низкой, значит, ваш проект станет полигоном для обучения новичков. Мой совет: зафиксируйте в договоре конкретных ключевых сотрудников, замена которых возможна только по согласованию с вами и с сохранением грейда.
Вывод
Чтобы не слить бюджет, избегайте компаний, которые говорят общими фразами («гибкий подход», «индивидуальные решения») и не могут предоставить детальную схему миграции данных. Начинайте с жесткого технического интервью с CTO: если он не может объяснить разницу между асинхронным и синхронным обменом данными или не имеет четкого лимита на кастомизацию ядра — отказывайтесь от сотрудничества. Лучший выбор — интегратор, который настаивает на стандартизации процессов и прозрачно показывает стоимость владения системой на горизонте 3-5 лет, а не только цену внедрения.