ENG
В первые годы импортозамещения компании задумывались об устойчивости и поддержке текущих ERP-систем. Сейчас же фокус больше сместился на архитектуру, управляемость данных, стоимость изменений и долгосрочные риски. В мае Axenix провела исследование российского ERP-рынка — изучили подходы бизнеса к выбору систем, ключевые критерии и ограничения, с которыми сталкиваются заказчики. Один из главных выводов — крупные игроки не ищут идеальную замену SAP, они постепенно переходят к более прагматичной модели, отвечая на вопрос: как собрать устойчивый ERP-ландшафт под конкретные бизнес-задачи и уровень риска. На основе проведенного исследования мы собрали пошаговый маршрут, как российским компаниям выбрать качественное ERP-решение.
1. Сделать быстрый отсев по обязательным ограничениям
В первую очередь стоит смотреть не на функциональность системы, а на ограничения, которые она может создать для компании. На этом этапе формируем перечень критериев, которые можно проверить без глубокого исследования рынка.
Это может быть:
- юрисдикция вендора;
- возможность покупки лицензий российским юрлицом;
- наличие внедрений в РФ;
- партнерская экосистема;
- русскоязычная поддержка и документация;
- присутствие в реестре российского ПО;
- сертификаты ФСТЭК или ФСБ, если они требуются компании.
Важно сразу проверить технологические ограничения — закрытость платформы, возможность работы на Linux и в целевом инфраструктурном контуре, поддерживаемые СУБД, интеграционные механизмы, требования к безопасности.
На этом этапе задача — не выбрать систему, а быстро убрать варианты, которые заведомо не подходят компании по юридическим, инфраструктурным или организационным причинам.
2. Сформировать короткий список решений
После первичного отсева формируется ограниченный список систем, которые есть смысл анализировать глубже.
Формально российский рынок предлагает несколько ERP-платформ и смежных решений. Официальные материалы вендоров описывают продукты как полноценные платформы для автоматизации управления предприятием. Но для enterprise-сегмента этого недостаточно. Крупным компаниям нужны подтверждения того, что система работает на сопоставимых объемах данных, пользователей и процессов.
На этапе составления такого списка важно смотреть не только на презентации вендора, но и на зрелость экосистемы вокруг продукта. В исследовании Axenix среди критериев выбора компании чаще всего называли:
- функциональный охват;
- производительность;
- масштабируемость;
- интеграционную архитектуру;
- возможность доработок;
- качество документации;
- зрелость команды вендора;
- доступность внедренцев;
- стоимость владения;
- соответствие требованиям безопасности;
- наличие понятной дорожной карты развития продукта.
Важным критерием становится корпоративная зрелость самого вендора. Крупный бизнес смотрит не только на наличие конкретной функции, но и на способность поставщика работать с большими внедрениями — управлять релизами, тестированием, поддержкой, исправлением дефектов и критичных инцидентов.
3. Проверить зрелость решений на сопоставимых кейсах
Следующий этап — анализ реальных внедрений. Важно оценить релевантные кейсы рассматриваемых систем — как они внедрялись в похожих отраслях, какой там был масштаб бизнеса, какая нагрузка, сложность процессов, насколько большим был объем данных. Часто компании совершают одну и ту же ошибку — смотрят на наличие внедрения как такового, но не проверяют его сопоставимость со своим контуром.
Дело в том, что ERP, которая работает в производственной компании на 500 пользователей, может оказаться неготовой к требованиям холдинга с десятками тысяч специалистов, сложным технологическим слоем и высокими требованиями к отказоустойчивости. На этом этапе полезно подключать вендоров и интеграторов, у которых уже есть практический опыт внедрения выбранных решений.
Отдельно проверяются:
- наличие документации;
- результаты нагрузочных тестов;
- архитектурные ограничения;
- безопасность;
- интеграционные возможности;
- работа в целевых средах;
- стоимость лицензий, внедрения и дальнейшей поддержки.
На этом этапе нужно смотреть на ERP как на часть всей прикладной архитектуры, а не как на отдельное приложение. Это важно, потому что отечественная ERP не всегда означает полностью импортонезависимый ИТ-ландшафт. Даже если прикладная система российская, в контуре могут оставаться иностранные операционные системы, базы данных и средства виртуализации. Поэтому оценивать стоит полный технологический стек.
4. Не копировать старую ERP, а проектировать новую
Один из самых сложных этапов — формирование функциональных требований. На практике многие компании начинают проект с попытки буквально воспроизвести текущую ERP: сохранить все экраны, отчеты, пользовательские сценарии и накопленные доработки.
Но такой подход почти всегда ведет к росту стоимости и сроков проекта. Функциональные требования должны описывать не устройство текущей системы, а ключевые бизнес-потребности компании.
Они могут включать как критичную функциональность, которую необходимо сохранить, так и новые возможности, которых сейчас нет, но которые нужны бизнесу.
Важно не зацикливаться на исторических компромиссах старой системы.
5. Оценить объем доработок заранее
После формирования требований начинается совместная работа с вендорами и интеграторами. На этом этапе оценивается, какие требования закрываются стандартным функционалом, а какие потребуют серьезной разработки. При этом важно не вслепую повторять шаги процессов из старой системы, а по возможности применять разумный компромисс и использовать типовую конфигурацию нового решения. Полностью повторить прежний ERP-ландшафт в любом случае не получится. Лучше использовать внедрение как возможность спроектировать систему лучше текущей.
После этого становится понятна реальная стоимость конкретного проекта, и эта стоимость может сильно отличаться от первоначальных оценок на предыдущих этапах.
6. Сравнить не только продукты, но и риски
По каждому варианту ERP-системы необходимо построить полноценную дорожную карту:
- этапы внедрения новых продуктов, их длительность и стоимость;
- потребность во внутренних ресурсах от бизнеса и ИТ-команд;
- влияние на смежные ИТ-системы
Отдельно сравниваются технологические, юридические и организационные риски.
7. Сравнить внедрение новой системы с вариантом «ничего не делать»
Сценарий сохранения текущего ERP-ландшафта нужно анализировать так же строго, как и сценарий внедрения новой системы. На первый взгляд статус-кво может казаться самым дешевым и безопасным вариантом. Но на практике он часто содержит скрытые издержки:
- рост технического долга;
- дефицит экспертизы;
- риски поддержки;
- регуляторные ограничения;
- накопление ручного труда.
Это в большей степени актуально для компаний, которые продолжают использовать иностранные системы без понятного горизонта поддержки и развития.
8. Принять решение на уровне инвестиционного выбора
Финальный выбор ERP — не техническое решение ИТ-департамента. Для крупного бизнеса это управленческое и инвестиционное решение, где компании вместе с функциональностью системы оценивают масштаб предстоящих изменений, сроки, бюджет и уровень допустимого риска.
Для одних компаний рациональным решением становится полноценный переход на новую ERP-платформу. Другие выбирают более осторожный путь — поэтапную миграцию с сохранением части текущего ландшафта. Третьи строят гибридную архитектуру, в которой новое ERP-ядро сосуществует со специализированными системами. В некоторых случаях компании выгоднее временно сохранить текущую систему, если риски быстрого перехода оказываются выше потенциального эффекта.
