Успех внедрения ERP (системы планирования ресурсов предприятия) во многом зависит от выбора интегратора. Подрядчик должен взять на себя архитектуру внедрения: обеспечение взаимосвязанности между ERP и 1С/CRM/ESB, миграцию данных, настройку процессов, тестирование и запуск, а затем поддержку и режим изменений. Компаниям сложно держать под контролем всю связку процессов самостоятельно, но выбрать интегратора тоже непросто — по описанию они похожи, а отличия проявляются уже в работе.
В этом материале разберемся, как выбрать надежного подрядчика. В составлении материала также использовался чек-лист RFP (запроса предложений) от платформы корпоративных коммуникаций Пряники и ее основателя Евгении Любко.
Как мы собирали мнения
Мы погрузились в механику пресейла: какие вопросы обсуждают до контракта, как оценивают риски внедрения и фиксируют ожидаемые результаты. В успешных проектах именно на этом этапе заказчик и интегратор формулируют цели на совместную работу, подтверждают готовность данных, договариваются о принципах оценки доработок и способах эскалации рисков. Там, где пресейл сводится к примерной смете и обзору стандартной интеграции, проект почти всегда теряет управляемость по срокам и бюджету.
В качестве источников также использованы:
Материалы ИТ-консалтингового агентства RDV — специалистов в цифровой трансформации и автоматизации процессов.
Практику СОЛОВЬеВ.group — компания создает ИТ-решения для бизнеса.
чек-лист RFP от команды Пряники — взгляд подрядчика на то, что должен спросить сам заказчик.
Каркас выбора: от RFI к RFP и пресейлу
Путь к внедрению ERP выглядит линейно только на схеме. На деле каждая стадия добавляет конкретику, снижает неопределенность и помогает обеим сторонам — заказчику и интегратору — понять, готовы ли они работать вместе.
Дорожная карта внедрения ERP
RFI (первичный анализ)
Цель: понять, кто из подрядчиков способен реализовать проект, и отсеять случайные компании до начала диалога.
На этом этапе заказчик формулирует верхнеуровневые вводные:
- бизнес-цели проекта;
- масштаб внедрения (число пользователей, география, модули);
- технологическую среду (ERP-ядро, смежные системы, архитектурные ограничения);
- базовые ожидания по срокам и бюджету;
- критерии предварительного фильтра (опыт по отрасли, сертификация, поддерживаемые интеграции).
На основе ответов на эти вопросы можно составить шорт-лист кандидатов и перейти к следующему шагу.
Короткий скрининг
Цель: проверить, насколько предварительные обещания интегратора соответствуют реальному положению дел.
На этом шаге обсуждаются пять типовых зон риска:
- Данные: есть ли мастер-данные, кто ими владеет, насколько они достаточны.
- Интеграции: какие системы затрагиваются, есть ли документация и тестовые контуры.
- Безопасность: как устроены доступы, требования по 152-ФЗ, кто отвечает за аудит.
- Ресурсы: кто будет вовлечен со стороны заказчика (архитектор, PM, владелец данных).
- Оценка ожиданий: совпадают ли представления о результате и приоритетах.
RFP (запрос предложений)
Цель: собрать формальные предложения на основе единых критериев, а не интуиции.
Здесь уже задаётся структура и формат ответа:
- цели и ожидаемые результаты проекта;
- требования к функционалу, интеграциям, данным и безопасности;
- целевые SLO/SLA (уровни сервиса, аптайм, MTTR, % успешных релизов);
- план пилота и вехи внедрения;
- критерии оценки и их веса (например: архитектура — 20%, команда — 15%, стоимость — 10%);
- форма расчета TCO и условия индексации ставок.
Следующий шаг после этапа RFP — переход к пресейлу с 2-3 лучшими подрядчиками.
Пресейл (проверка гипотез)
Цель: подтвердить, что расчеты из RFP совпадают с реальностью, и снять ключевые риски внедрения до подписания договора.
На этой стадии команды интегратора и заказчика работают вместе:
- проводит профилирование данных и выявляет слабые места;
- уточняет архитектуру и объем интеграций;
- формирует риск-реестр;
- оценивает трудоемкость критических доработок;
- договаривается о методологии (agile/waterfall/hybrid) и ритмах релизов;
- документирует «границы успеха» по каждому процессу.
Комментарий RDV:
Заинтересованность исполнителя в комплексной проработке проекта до заключения договора и помощи с подготовкой критериев для выбора — вот, что особенно важно на этапе пресейла. Заказчику стоит обратить внимание на то, может ли исполнитель провести необходимые встречи и составить детальный план проекта до процессов верхнего уровня и проработать дорожную карту с учетом ограничений и рисков. Не нужно торопиться покупать обследование, исполнители с опытом могут дать оценку всего проекта даже при незначительных усилиях и дать вам информацию для погружения в проект уже на пресейле.
Александр Рошаль, генеральный директор RDV
Принятие решения
Цель: зафиксировать выбор интегратора ERP и условия, на которых стороны готовы двигаться дальше.
Кроме стоимости, решение опирается на:
- качество пресейла (насколько интегратор вник в контекст и проработал риски);
- прозрачность оценки и принцип расчета TCO;
- зрелость подхода к SLA/SLO/SLI;
- совместимость ритуалов и коммуникаций (скорость, инструменты, формат отчетности).
После этого формируется финальный договор с указанием моделей оплаты (фикс, почас или гибрид), индексации, бонус-малус к SLO и планом пилота ERP.
Комментарий RDV:
Глубокий пресейл должен показывать комплексную экспертизу Исполнителя по всему проекту: опыт других клиентов, понимание проблематики и целей, демонстрация компетенций по проектной методологии. Еще важно понимание, где клиенту нужна помочь в методологии, в проработке процессов, а где это должны быть только ИТ-услуги. Все, что важно заказчику в проекте, это должно быть оформлено в детальное коммерческое предложение и план работ.
Александр Рошаль, генеральный директор RDV
Чек-лист пресейла интегратора
Собрали список важных пунктов, на которые стоит обратить внимание на пресейле по мнению специалистов Пряников:
1. TCO — внедрение и владение
На пресейле важно посчитать общие расходы за 2–3 года владения системой, а не стоимость запуска. Сюда входят лицензии (частичные или полные), апдейты, техническая поддержка (L2/L3), резерв часов на доработки, инфраструктурные затраты.
2. Индексация ставок
Расценки не фиксируются навсегда. На пресейле интегратор должен сразу показать принцип индексации: как меняется ставка по годам, какие факторы на нее влияют (инфляция, курс, тарифы на лицензии), и где верхняя граница. В идеале, подрядчик показывает таблицу с с ценой первого года, прогнозом второго и третьего, а также условиями пересмотра. Это позволяет избежать неприятных сюрпризов в момент продления контракта.
3. SLA/SLO/SLI — формула качества
Уровни сервиса нужно определить еще до подписания договора.
- SLA — обязательства интегратора (например, MTTR ≤ 8 часов).
- SLO — целевые уровни (например, 98% успешных релизов).
- SLI — фактические показатели, которые будут замеряться.
Хороший интегратор сразу предлагает, какие метрики собираются автоматически и как их можно проверить.
4. Доступы и инфраструктура
Без доступа к нужным контурам внедрение ERP не начнется. На пресейле уточняется:
- какие именно доступы потребуются (серверы, БД, VPN, CI/CD, хранилища);
- кто выдает их со стороны заказчика и каковы сроки;
- какие политики безопасности действуют (в том числе требования по 152-ФЗ).
5. On-prem апдейты
Если ERP разворачивается в инфраструктуре заказчика, нужно определить, кто и как будет устанавливать обновления:
- делает ли это подрядчик (и сколько это стоит);
- кто отвечает за тестирование и rollback;
- как часто выходят апдейты и где хранится регламент установки.
Этот пункт напрямую влияет на TCO: если все ложится на внутреннюю разработку, потребуется их обучение и дополнительное время в релизных окнах.
6. Оценка доработок (change requests)
Интегратор обязан показать, по какой модели он считает доработки. Прозрачная калькуляция включает этапы: аналитика, дизайн, фронт, бэк, тестирование, управление проектом, риски. Хорошая практика — попросить интегратора оценить одну небольшую функцию и показать раскладку по видам работ. Это быстро выявляет, насколько оценка обоснована.
Пряники советуют закрепить SLA на оценку CR (например, не более 3 рабочих дней).
7. Роли и ответственность (RACI)
Четкое распределение ролей между заказчиком и интегратором снижает потери на коммуникации. Классическая матрица RACI (Responsible / Accountable / Consulted / Informed) заполняется прямо на пресейле: кто финализирует решения, кто согласовывает изменения, кто уведомляется.
8. План B/C/D — сценарии на случай непредвиденного
Опытные интеграторы признают: всегда что-то идёт не по плану. На пресейле нужно описать минимум три сценария:
- B — если интеграция не взлетела (альтернативный маршрут данных);
- C — если провалена миграция данных (откат или временный мост);
- D — если сдвигается релиз (перепланирование и заморозка изменений).
9. Качество данных и MDM
На пресейле проверяются источники мастер-данных, ответственные (data owners), процент пустых полей и дубликатов, план очистки и обогащения. Интегратор фиксирует SLI по качеству данных (например, ≥95% заполненности критичных атрибутов) и критерии остановки проекта, если уровень падает ниже порога.
10. Интеграции и архитектура
ERP редко живет в вакууме — вокруг десятки систем. На пресейле нужно составить полную карту интерфейсов: ERP ↔ 1С, CRM, BI, ESB, платежные шлюзы, внешние API.
Интегратор должен описать:
- формат обмена и политику версий API;
- наличие тестовых контуров и данных-муляжей;
- регламент изменений (changelog, обратная совместимость);
- кто чинит сбой и в какие сроки.
Комментарий Соловьев.group:
Важно, чтобы интеграций с критическими системами, которые нельзя заменить, было не больше двух. Если требуется больше интеграций, то я считаю, что наша система ERP недостаточно хорошо закрывает процессы заказчика, либо процессы заказчика избыточно «размазаны» на множество сторонних систем. Тогда стоит вначале поработать над оптимизацией своей системы до уровня замещения избыточных интеграций. В этом и есть суть работы интегратора — не просто «вонзить» свой продукт в зоопарк систем, а провести оптимизацию бизнес-процессов.
Качество и объем работы интегратора ERP напрямую связаны с эффективностью сотрудничества заказчика и сторонней системы. SLA интегратора не может значительно отличаться от SLA сторонней системы, иначе участники погрязнут в спорах вместо цифровизации и улучшения своих процессов. Это должно решаться «на берегу» и соответствующе оформляться в договоре. Если что-то не складывается с самого начала — лучше отказаться от проекта или конкретной интеграции и заменить ее на другую.
Максим Соловьев, основатель Соловьёв.Group
Чек-лист для команды заказчика
Основа успешного выбора — внутренняя готовность. Часть работ нельзя делегировать.
| Что подготовить | Как подтвердить | Кол-во дней до старта | Ответственный | Ссылка в RFP/риск |
|---|---|---|---|---|
| Цели по процессам | Метрики, базовые значения, целевые SLO | 7 дней | Бизнес-владелец | SLO/SLA — без измеримых метрик неясно, что считается успехом. |
| Приоритизация волн | Дорожная карта, критерии «готово» | 7 дней | PMO/Бизнес | RFP: раздел «План» — порядок релизов должен быть привязан к бизнес-целям. |
| Роли и RACI | Матрица ответственности | 5 дней | PMO | Риск «ответственность»: без RACI плывут сроки. |
| Мастер-данные | Источники, owner-ы, качество (SLI) | 10 дней | Data-менеджер | Риск «данные»: некачественные или неполные мастер-данные блокируют миграцию и тесты. |
| Интеграции | Список интерфейсов, владельцы, SLA внешних систем | 10 дней | Архитектор | Риск «интеграции»: неучтенные системы и версии API вызовут цепочку задержек. |
| Тестовые контуры | Описание сред, доступы, данные-муляжи | 5 дней | ИТ/DevOps | Риск «релизы»: без стейджинга тестируют на проде, что ведет к сбоям и простоям. |
| Окна релизов | Календарь, заморозки, регламент | В день старта | Release-менеджер | SLI/MTTR: без фиксированных окон релизы накладываются друг на друга. |
| Лицензирование | Перечень, условия, срок действия | В день старта | Закупки | TCO/индексация: важно заранее понимать стоимость владения и рост ставок. |
| Безопасность/152-ФЗ | Требования, роли, аудиты | В день старта | ИБ/Юр | Риск «комплаенс»: несоответствие 152-ФЗ или отсутствие аудита может заблокировать релиз. |
| Обучение/изменения | План обучения/коммуникаций | В день старта | HR/Обучение | Риск «adoption»: пользователи не примут новую систему без поддержки и обучения. |
| Контроль изменений (CR) | Процедуры, лимиты, SLA на оценку | В день старта | PMO | Риск «scope creep»: без регламента CR объем работ неконтролируемо растет, увеличивая сроки и бюджет. |
Критерии выбора интегратора ERP
| Критерий | Вес | Что проверять / доказательства | Связанный риск |
|---|---|---|---|
| Архитектура и интеграции | 12 | Карта интерфейсов, версия API, распределение ответственности, наличие тестовых контуров | «Костыли» в интеграциях, зависимость от подрядчика |
| Экспертиза по ERP-ядру | 12 | Опыт по конкретному ERP, модули и кейсы, сертификации, результаты архитектурных ревью | Переоценка «из коробки», срыв сроков |
| Отраслевая экспертиза | 10 | Знание нюансов процессов и отчётности, готовые отраслевые пресеты | Неверные допущения, неполный пресейл |
| Команда и роли | 10 | Замещение ключевых ролей, реальная доступность специалистов, RACI на пресейле | Уход экспертов, размытая ответственность |
| Оценка сроков / бюджета, методология | 10 | Принцип расчета, наличие буферов, процедуры CR (Change Request) | Разъезд сроков и бюджета, неготовность пользователей |
| Миграция данных / MDM | 8 | Профилирование источников, план очистки и обогащения, SLI по качеству данных | Задержки миграции, дефекты данных |
| Тестирование и приемка | 8 | UAT-процедуры, критерии «готово», автоматизация регресса | Скрытые дефекты, перенос «хвостов» в поддержку |
| Сопровождение и SLA / SLO / SLI | 8 | MTTR, % успешных релизов, аптайм, индикаторы деградации, регламент отчетности | Просадка качества эксплуатации |
| Безопасность и 152-ФЗ | 6 | Модель ролей и доступов, сегментация сред, аудиты, управление привилегиями | Инциденты комплаенса, задержки из-за доступов |
| Кейсы / референсы / устойчивость | 6 | Долгоживущие команды, наличие замены ключевых ролей, «анти-bus-factor» | Зависимость от единственного подходящего архитектора |
| Условия договора (фикс / почас) | 6 | Принцип индексации, бонус-малус к SLO, лимиты CR | Неконтролируемый рост объема и бюджета |
| Совместимость ритуалов / культуры | 4 | Регулярности коммуникаций, скорость откликов, инструменты взаимодействия | Коммуникационные задержки, молчание в критические моменты |
Чек-лист для RFP
На этапе пресейла важно договориться о целях предстоящей интеграции. Предлагаем шаблон для формулирования результатов, доступный по ссылке.
Комментарий от Пряники:
Для подготовки к RFP заказчик должен обозначить цели и задачи, чтобы понять, для чего вообще нужна выполняемая работа. Зная их, интегратор может предложить более эффективное решение, чем то, что зафиксировано в технических требованиях клиента. Дальше нужно понять аудиторию проекта и количество пользователей — от этого существенно зависит требование к устойчивости к нагрузке. Также важно учесть интеграции с другими сервисами: брендовыми, как 1С, и внутренними. Это нужно, чтобы выбрать оптимальную модель интеграции и понять, по какому протоколу взаимодействуют сервисы.
Евгения Любко, архитектор корпоративных миров в Пряники
Комментарий от RDV:
Базовые риски обсуждаются на пресейле при выборе вариантов автоматизации: в основной это сроки, объем консалтинга разработки. Триггеры и работа с индикаторами — это правильная работа с ожиданиями не только на пресейле, но и в ходе всего проекта. Поэтому процесс покупки проектов часто сложный: нельзя покупать его у менеджеров по продажам, если они не понимают детали и слепо обещают чудо. Нужно применять принципы должной осмотрительности и выбирать партнера с сильной командой и опытом по резюме.
Александр Рошаль, генеральный директор RDV
План поэтапного запуска
ERP-проект проходит несколько ключевых этапов — от проверки гипотез до устойчивой эксплуатации. Каждый шаг нужен, чтобы зафиксировать допущения, проверить риски и сохранить управляемость сроков и бюджета.
- Пресейл-спринт (проверка готовности)
Цель: подтвердить реальность оценок из RFP.
Проверяются объем и границы проекта, качество данных, дорожная карта интеграций, матрица RACI. Формируется риск-реестр с владельцами и планами B/C/D, уточняется сценарий пилота. - Пилот (проверка жизнеспособности)
Цель: показать, что система работает в реальности.
Берутся 1–2 приоритетных процесса, настраиваются интеграции, фиксируются критерии «готово». Измеряются SLI — MTTR, процент релизов без инцидентов. Вводятся короткие петли обратной связи между бизнесом и разработкой. - Волны (масштабирование внедрения)
Цель: развернуть ERP по процессам или подразделениям без потери качества.
Каждая волна включает настройку, тестирование, приемку и запуск. Контролируется технический долг, после каждой волны проводится ретро и пересмотр рисков. - Приемка волны (фиксация результата)
Цель: подтвердить выполнение целей.
Проводится UAT, обучение, документация и релиз-ноты. Подписываются акты на основе зафиксированных SLO. - Эксплуатация (мониторинг и улучшения)
Цель: перейти от внедрения к управляемой эксплуатации.
Отслеживаются SLI (MTTR, аптайм, стабильность интеграций), ведется бэклог оптимизаций, проводится регулярная ретроспектива и анализ TCO.
Итог: такой цикл делает внедрение ERP предсказуемым — у каждой стадии есть критерии «готово», метрики и ответственные.
Комментарий от Соловьев.group:
Критически важно не только обсудить, но и прописать условия вывода в эксплуатацию в контракте. Заказчик — не интегратор, и мыслит своими ожиданиями, которые могут быть нереалистичными или ошибочными. Обозначить метрики успеха процессов и этапов внедрения — это самое главное. SLI в данном случае — один из вариантов пакета метрик, и в его составе могут быть разные показатели в зависимости от задач доработки и внедрения нашей системы конкретному заказчику.
Максим Соловьев, основатель Соловьёв.Group
Итоги редакции
Результат перехода на ERP зависит от двух факторов: компетентности интегратора и готовности команды заказчика. Ошибки в начале обходятся дороже, чем любые оптимизации после запуска, поэтому решающими при выборе подрядчика становятся качество пресейла и ясность целей. Если команда заказчика знает, чего именно хочет достичь, а интегратор способен перевести эти цели в архитектуру, данные и процессы, проект становится предсказуемым и эффективным.