Когда речь заходит о выборе ERP-платформы и системного интегратора, почти всегда звучит слово «конкурс». Формально процесс выглядит структурированным: несколько поставщиков, демо, презентации, референсы, коммерческие предложения.
Но если посмотреть глубже, картина часто оказывается иной.
Не потому, что компании «не умеют выбирать».
А потому, что процесс выбора нередко начинается с инструмента, а не с методологии.
Иногда стартовая точка — это демо.
Иногда — список потенциальных вендоров.
Иногда — внутреннее ощущение, что «эти ребята выглядят сильнее».
Недавно я обсуждал проект с партнёром, который предложил:
«Давайте сделаем серию демо и на основе впечатления выберем».
В разговоре выяснилось, что на старте отсутствовали:
формализованные критерии выбора,
определение успешности проекта,
требования к модели команды,
понимание того, как будут управляться риски.
И это не редкость.
Гораздо чаще проблема не в том, что компании выбирают «толь��о по демо».
Проблема в том, что отсутствует чётко сформулированная матрица принятия решения.
А без неё процесс неизбежно становится хаотичным.
От ощущения к управлению
Выбор ERP-платформы и интегратора — это решение на десятки, а иногда и сотни миллионов.
И в этом решении есть важная особенность:
Вы выбираете не просто систему.
Вы выбираете архитектуру зависимости на 5–7 лет.
Если это решение нельзя разложить на измеримые параметры, вы не управляете риском — вы его принимаете.
Демо — полезный инструмент.
Но демо — это инструмент проверки гипотезы.
Матрица критериев — это инструмент управления.
Именно она переводит обсуждение из плоскости «кто произвёл лучшее впечатление» в плоскость «какое решение устойчиво в горизонте 5–7 лет».
6 блоков критериев, которые превращают хаос в систему
Ниже — структура, которую я использую в практике.
Это не «идеальная модель», а рабочий инструмент для сравнения решений по измеримым параметрам.
1. Экономика: считать весь жизненный цикл
Первое, на чём часто фокусируются, — стоимость лицензии.
Но лицензия — это входной билет, а не итоговая цена владения.
Ключевые критерии:
Стоимость лицензий (₽)
Ежегодная поддержка (%)
TCO на 3–5 лет (₽)
Стоимость major-апгрейда (₽)
Major-апгрейд — отдельная тема.
В ряде платформ переход на новую версию может стоить 30–50% от первоначального внедрения.
Если TCO не рассчитан минимум на три года, решение оценивается фрагментарно.
Иногда более дорогая на старте платформа оказывается дешевле в горизонте нескольких лет за счёт меньшего объёма доработок и более стабильной релизной политики.
2. Функциональность: сколько придётся разрабатывать
Красивое демо не равно функциональному покрытию.
Важно понять, какой процент ваших реальных требований закрывается без доработок.
Критерии:
Покрытие требований (%)
Объём обязательных доработок (%)
Риск роста доработок
Наличие отраслевых шаблонов
UX / удобство работы пользователей
Разница между «в системе это есть» и «это работает под наши процессы» часто оказывается критичной.
Каждый процент кастомизации — это будущая стоимость поддержки и обновлений.
3. Архитектура и экосистема: управляемость или зависимость
Здесь находится стратегический слой решения.
Архитектура:
Открытость API
Масштабируемость
Горизонтальное масштабирование
Совместимость версий
Закрытая архитектура и сложная совместимость версий формируют долгосрочную зависимость.
Но архитектура — это только половина картины.
Экосистема:
Количество партнёров на рынке
Доступность специалистов
Закрытость кода
Наличие обучающих программ
Доступность специалистов — один из ключевых факторов.
Если на рынке единичные эксперты по платформе, любая смена подрядчика становится проблемой.
Если же есть десятки партнёров, сотни специалистов, активный рынок вакансий — компания остаётся управляемой.
Возможность нанять команду в штат или зааутстафить специалистов — это не операционная деталь, а стратегическая устойчивость.
Именно здесь проходит граница между выбором решения и выбором зависимости.
4. Релизы: сколько будет стоить жить дальше
ERP — это не разовая инсталляция, а эволюция в течение 5–7 лет.
Критерии:
Частота major-релизов
Доля breaking changes
Наличие инструментов миграции
Срок поддержки версии
Если релизная политика агрессивна, а совместимость нарушается часто, каждое обновление может превращаться в мини-перев внедрение.
Это напрямую влияет на предсказуемость бюджета.
5. Интегратор: производственная способность
Платформа не внедряется сама по себе.
Важно оценивать не презентацию, а способность реализовать проект.
Критерии:
Опыт проектов
Отраслевой опыт
Сертифицированные специалисты
Средняя ставка часа
Ставка ниже рынка не всегда является преимуществом.
Иногда это индикатор демпинга с последующим ростом объёма работ через изменения.
Отдельный вопрос — кто именно будет работать на проекте и закреплён ли состав команды.
6. Управление и стратегия: зрелость решения
Даже при хорошем выборе платформы и интегратора проект может потерять управляемость.
Критерии:
Наличие PoC
Time-to-Value
Детализация WBS
Наличие risk register
Наличие roadmap
Возможность смены интегратора
Финансовая устойчивость вендора
ERP — это не только технология.
Это контракт на распределение рисков.
Если в договоре не зафиксированы вехи, метрики и ответственность, риски фактически остаются на стороне заказчика.
Независимая проверка: слой, который часто игнорируют
Самый чувствительный блок.
Критерии:
Судебные дела за 5 лет
Дела по расторжению контрактов
Доля проигранных дел
Исполнительные производства
Факты досрочных расторжений
Готовность фиксировать штрафы
И ещё один аспект — референс-визиты.
Чаще всего заказчик общается с компаниями, где проект прошёл успешно.
Это логично.
Но управленчески полезно смотреть шире — и на сложные проекты тоже.
Не для поиска негативных историй.
А для понимания того, как интегратор ведёт себя в кризисе.
Когда всё идёт по плану, многие выглядят одинаково.
В сложных ситуациях проявляется зрелость процессов.
Как превратить список критериев в инструмент
Определить веса критериев.
Собрать фактические данные.
Рассчитать интегральную оценку.
Использовать демо как проверку гипотез.
Зафиксировать ключевые параметры в договоре.
Если при заполнении матрицы по ряду критериев отсутствуют данные, это уже управленческий сигнал.
Либо информация не раскрывается.
Либо решение принимается преждевременно.
В чём корень проблемы
Провалы ERP-проектов редко начинаются в коде.
Они начинаются в момент выбора, когда вместо структурированного анализа принимается решение без формализованных критериев.
Не потому, что демо — зло.
А потому, что демо не может заменить систему.
Вы выбираете не просто платформу.
Вы выбираете архитектуру зависимости на 5–7 лет.
И если это решение не разложено на измеримые параметры, управляемость остаётся иллюзией.
