Импортозамещение SAP без иллюзий: как выбрать ERP, которая не развалится при масштабировании

ERP — это не просто программа для учета. Это цифровой каркас бизнеса: в ней хранятся данные, проходят процессы, формируются документы, работают интеграции и принимаются управленческие решения. Поэтому импортозамещение ERP — это не замена одного логотипа другим, а архитектурная задача.

Разбираем, на что смотреть при выборе новой ERP, чтобы система выдержала рост компании, интеграции и реальные бизнес‑процессы.

Почему замена ERP — это вопрос архитектуры, а не только функций

При выборе ERP бизнес часто начинает с функциональной таблицы: есть ли склад, есть ли закупки, есть ли CRM, есть ли финансы, есть ли производство. Это логичный первый шаг, но не главный.

Если архитектура не готова к такой нагрузке, система может формально закрывать базовые функции, но плохо масштабироваться. На небольшом участке она работает, а при расширении на новые подразделения, склады, юридические лица или производственные контуры начинает требовать постоянных доработок.

Поэтому при импортозамещении важно смотреть не только на то, что система умеет сегодня, но и на то, как она будет развиваться завтра.

Какие ошибки бизнес допускает при выборе новой системы

Первая ошибка — искать полную копию прежней ERP. Старую систему часто внедряли годами, дорабатывали под конкретные процессы, подключали к десяткам сервисов и настраивали под внутреннюю логику компании. Повторить это один в один в новой системе почти невозможно, да и не всегда нужно.

Вторая ошибка — выбирать систему только по демо‑презентации. На демонстрации почти любая ERP выглядит логично: красивые интерфейсы, готовые сценарии, быстрые отчеты. Но демо показывает идеальный процесс, а в реальности у компании есть исключения, нестандартные маршруты, разные роли, исторические данные и внутренние правила.

Третья ошибка — недооценивать интеграции. ERP редко работает одна. Она связана с бухгалтерией, CRM, складским оборудованием, производственными системами, BI, сайтом, банками, ЭДО, телефонией и другими сервисами. Если новая система плохо интегрируется, сотрудники быстро возвращаются к Excel, ручным выгрузкам и двойному вводу данных.

Четвертая ошибка — внедрять всё сразу. Чем крупнее компания, тем выше риск, что большой запуск превратится в долгий и болезненный проект. В таких случаях безопаснее двигаться поэтапно: сначала закрыть критичные процессы, затем подключать новые модули и подразделения.

ERP выбирают не по количеству кнопок в интерфейсе, а по способности выдержать реальные процессы компании

Модульность против тяжелого монолита

Тяжелый монолит удобен, когда бизнес готов полностью подстроиться под логику системы. Но в реальности компании часто работают иначе: часть процессов уже оцифрована, часть остается в старых системах, часть нужно менять постепенно, а часть нельзя останавливать даже на время внедрения.

Такой подход особенно важен для среднего и крупного бизнеса. Он позволяет не останавливать операционную деятельность, быстрее получать первый результат и проверять систему на реальных процессах, а не только в тестовой среде.

API‑first и интеграции: как сохранить связность ИТ‑ландшафта

Одна из главных задач при замене ERP — не потерять связность систем. В компании уже могут работать CRM, MES, BI, ЭДО, сайт, складское оборудование, сервисы доставки, банковские интеграции, телефония и внутренние базы данных.

Подход API‑first означает, что система изначально готова к обмену данными с другими сервисами. Это особенно важно, если компания не хочет менять весь ИТ‑ландшафт одновременно. Хорошая ERP должна не ломать существующие инструменты, а связывать их в более управляемый контур.

Для бизнеса это означает меньше ручного ввода, меньше ошибок, быстрее обновляемые данные и больше возможностей для аналитики.

On‑premise и изолированные контуры: почему это важно

Для многих российских компаний вопрос размещения ERP — не техническая деталь, а требование безопасности. Особенно если речь идет о промышленности, госсекторе, инфраструктурных проектах, оборонных предприятиях, персональных данных или коммерчески чувствительной информации.

Облачная модель может быть удобной, но подходит не всем. Иногда системе нужно работать внутри защищенного периметра: без зависимости от внешних облаков, с контролем доступа, внутренними серверами и требованиями к информационной безопасности.

Поэтому при выборе ERP стоит заранее понять, где система будет развернута: в облаке, на собственных серверах или в изолированном контуре. Если этот вопрос оставить на потом, проект может столкнуться с ограничениями уже на этапе внедрения.

Low‑code и no‑code адаптация: как быстрее подстроить систему под бизнес

Даже если ERP подходит по основным функциям, в процессе внедрения почти всегда появляются уточнения. Нужно изменить форму документа, добавить поле, настроить маршрут согласования, поменять статус, создать отчет, адаптировать карточку клиента или складской процесс.

Если каждое изменение требует полноценной разработки, бизнес становится зависимым от очереди задач у подрядчика или внутреннего IT‑отдела. Это замедляет внедрение и делает систему менее гибкой.

Low‑code и no‑code инструменты помогают быстрее адаптировать ERP под реальные процессы. Они не заменяют разработку полностью, но позволяют закрывать часть настроек без сложного программирования: менять интерфейсы, создавать простые сценарии, настраивать формы и отчеты.

Для бизнеса это важно не только на старте. Процессы меняются постоянно: появляются новые продукты, подразделения, юридические лица, правила учета, требования руководства. ERP должна меняться вместе с компанией, а не превращаться в неподвижный монолит.

Что проверить до выбора ERP

Перед выбором новой ERP стоит ответить на несколько вопросов:

• какие процессы нужно заменить в первую очередь;
• какие данные нужно перенести из старой системы;
• какие интеграции критичны для ежедневной работы;
• какие подразделения нельзя останавливать во время внедрения;
• где должна размещаться система — в облаке или внутри контура компании;
• как будут настраиваться роли и права доступа;
• можно ли внедрять ERP поэтапно;
• какие изменения бизнес сможет делать без сложной разработки;
• как система будет масштабироваться через год, три года и пять лет.

Хорошая ERP должна не просто повторить старую систему. Она должна дать бизнесу возможность развиваться: подключать новые модули, интегрироваться с другими сервисами, работать в безопасном контуре, поддерживать рост компании и быстрее адаптироваться к изменениям.

Поэтому главный вопрос при выборе звучит не так: «Какая система больше похожа на прежнюю?» Гораздо важнее другой вопрос: «Какая система выдержит наш бизнес, когда он станет сложнее?»

Если ERP отвечает на этот вопрос, она становится не временной заменой, а платформой для следующего этапа развития компании.