Разработка российских ERP-систем
Проблемы импортозамещения
С момента подписания Указа Президента РФ № 166 прошло уже более трёх лет, однако успешные кейсы импортозамещения остаются единичными. Несмотря на ряд государственных инициатив — включая недавний ЦИПР — ситуация лишь сейчас начинает меняться, и Правительство заявляет о готовности к системной работе.
Ключевой вызов — отсутствие экспертизы. Исторически автоматизация корпоративного сектора в России зависела от западных решений (SAP, Oracle, Microsoft), где российские компании выступали лишь дистрибьюторами и интеграторами, а вендоры сохраняли контроль над проектированием и адаптацией продуктов под местные требования. Даже при использовании стека технологий (например, Oracle) критическая экспертиза оставалась у зарубежных разработчиков.
Новая реальность, обозначенная на ЦИПРе, требует создания отечественных решений «с нуля» — а значит, формирования собственной экспертизы. Однако такой опыт в России крайне редок: он возможен только как результат реализации сложных, высоконагруженных проектов на базе open-source решений или российских продуктов, что до 2022 года было практически невостребованным направлением.
Инициативы Правительства, предложенные рынку, сталкиваются с рядом системных проблем:
Дефицит экспертизы по разработке ERP-класса
Энтерпрайз-решения требуют иных подходов, чем массовый софт: проектирование распределённых систем, обработка больших данных, интеграция с legacy-инфраструктурой.
Отсутствие зрелых отечественных СУБД для ERP
Западные аналоги (Oracle Database, SAP HANA) прошли 50-летнюю эволюцию, синхронную с ростом аппаратных возможностей и постепенно растущих потребностей заказчиков. России предстоит «перепрыгнуть» этапы развития, используя альтернативный стек на базе Open Source решений, но их изначальная ориентация — не ERP, а узкие задачи (соцсети, аналитика и специализированные задачи).
Риски слепого переноса open-source в ERP
Многие open-source решения родились в проектах социальных сетей и изначально были спроектированы под решение конкретных задач. Эти решения имеют специфику, которую необходимо учитывать при проектировании ERP-систем.
Интеграционные риски
Даже успешная разработка национальной ERP не гарантирует её внедрения из-за:
• Фрагментированности экосистемы (большинство российских CRM, SCADA, BI-систем изначально проектировались под западные ERP);
• Сопротивления бизнеса: компании опасаются потери производительности при переходе на «сырые» решения.
Экономические ограничения
• Высокая стоимость разработки: создание ERP с нуля требует инвестиций, сопоставимых с бюджетами крупных госкомпаний;
• Долгий ROI: срок окупаемости может превышать 5−7 лет, что отпугивает частных инвесторов.
Регуляторные вызовы
• Отсутствие единых стандартов;
• Недостаточность господдержки: существующие субсидии покрывают <20 % затрат на импортозамещение.
Энтерпрайз-решения требуют иных подходов, чем массовый софт: проектирование распределённых систем, обработка больших данных, интеграция с legacy-инфраструктурой.
Отсутствие зрелых отечественных СУБД для ERP
Западные аналоги (Oracle Database, SAP HANA) прошли 50-летнюю эволюцию, синхронную с ростом аппаратных возможностей и постепенно растущих потребностей заказчиков. России предстоит «перепрыгнуть» этапы развития, используя альтернативный стек на базе Open Source решений, но их изначальная ориентация — не ERP, а узкие задачи (соцсети, аналитика и специализированные задачи).
Риски слепого переноса open-source в ERP
Многие open-source решения родились в проектах социальных сетей и изначально были спроектированы под решение конкретных задач. Эти решения имеют специфику, которую необходимо учитывать при проектировании ERP-систем.
Интеграционные риски
Даже успешная разработка национальной ERP не гарантирует её внедрения из-за:
• Фрагментированности экосистемы (большинство российских CRM, SCADA, BI-систем изначально проектировались под западные ERP);
• Сопротивления бизнеса: компании опасаются потери производительности при переходе на «сырые» решения.
Экономические ограничения
• Высокая стоимость разработки: создание ERP с нуля требует инвестиций, сопоставимых с бюджетами крупных госкомпаний;
• Долгий ROI: срок окупаемости может превышать 5−7 лет, что отпугивает частных инвесторов.
Регуляторные вызовы
• Отсутствие единых стандартов;
• Недостаточность господдержки: существующие субсидии покрывают <20 % затрат на импортозамещение.
Импортозамещение ERP — это не замена «кирпичей», как это могло показаться в 2022 году, а пересборка фундамента. Без инвестиций в экспертизу и адаптацию open-source под энтерпрайз-задачи проекты останутся точечными экспериментами. Необходимо грамотное проектирование, которое начинается с фундамента подобных систем — с СУБД.
СУБД как фундамент ERP-системы
Пока на рынке сохраняется иллюзия возможности миграции с таких продуктов, как Oracle, на open-source аналоги без перестройки фундамента системы — слоя хранения данных, адаптированного под возможности этих решений — ситуация с импортозамещением останется без изменений.
СУБД общего назначения, аналогичных по функционалу и производительности решениям, которые предлагали западные производители, не существует.
Существуют специализированные СУБД, каждая из которых имеет свои особенности и возможности. Лишь их комбинация в фундаменте системы (в слое хранения данных) может дать результат, сопоставимый с западными аналогами:
• Транзакционные операции → PostgreSQL (с доработками)
• Аналитика и отчёты → ClickHouse
• Кэширование → Tarantool
• Хранение документов, обмен данными между компонентами ERP → СУБД «Енисей»
• Аналитика и отчёты → ClickHouse
• Кэширование → Tarantool
• Хранение документов, обмен данными между компонентами ERP → СУБД «Енисей»
Именно на таком принципе построены архитектуры высоконагруженных распределённых информационных систем, созданных в последние годы для заказчиков, включая государственный сектор, где использование западных технологий ограничено.
Преимущества гибридной архитектуры
• Гибкость: возможность замены отдельных компонентов без перестройки всей системы.
• Масштабируемость: распределение нагрузки между СУБД разного типа.
• Упрощённая миграция: постепенный переход на более производительные аналоги.
• Масштабируемость: распределение нагрузки между СУБД разного типа.
• Упрощённая миграция: постепенный переход на более производительные аналоги.
Импортозамещение СУБД для ERP — это не поиск «единого аналога», а создание сбалансированного стека.
Интеграционная СУБД «Енисей» в проектах ERP
СУБД «Енисей» — это интеграционная документоориентированная СУБД, предназначенная для:
• Обмена JSON-сообщениями (документами) между компонентами ERP (уровни L2-L4);
• Гарантированной доставки данных через встроенный транспортный слой;
• Долгосрочного хранения документов с поддержкой бинарных вложений.
• Гарантированной доставки данных через встроенный транспортный слой;
• Долгосрочного хранения документов с поддержкой бинарных вложений.
Ключевые преимущества СУБД «Енисей»
✔ Мультимастерная репликация
• Гибкие маршруты передачи данных между узлами без зависимости от кворума.
• Обеспечивает eventual consistency — узлы синхронизируются при восстановлении связи.
• Обеспечивает eventual consistency — узлы синхронизируются при восстановлении связи.
✔ Отказ от традиционных API
• REST/SOAP требуют версионирования при изменениях.
• В «Енисее» данные хранятся в бессхемных JSON-документах.
• Версионирование происходит на уровне структуры документа, а не протокола.
• В «Енисее» данные хранятся в бессхемных JSON-документах.
• Версионирование происходит на уровне структуры документа, а не протокола.
✔ Встроенная бизнес-логика
Поддержка JavaScript/Erlang:
• Сложные сценарии репликации;
• Валидация и преобразование данных;
• MapReduce-запросы (аналитика уровня L4).
• Валидация и преобразование данных;
• MapReduce-запросы (аналитика уровня L4).
Гибридная архитектура: «Енисей» + реляционные СУБД
Хотя «Енисей» идеально подходит для обмена сообщениями, для полного цикла ERP требуется комбинация с другими СУБД.
Роль СУБД «Енисей» в ERP-архитектуре
Пример работы в ERP
- L2 (цеховые данные): датчики отправляют показания в «Енисей» как JSON-документы.
- L3 (MES): документы реплицируются в PostgreSQL для транзакционной обработки.
- L4 (аналитика): ClickHouse агрегирует данные через MapReduce-запросы к «Енисей».
- ТСД: терминалы отправляют данные через «Енисей».
- Диспетчеризация: обеспечение взаимодействия, маршрутизация и валидация данных через СУБД «Енисей»
Кроссплатформенность
«Енисей» работает на множестве ОС и платформ, включая мобильные устройства. Это позволяет использовать её в гетерогенных инфраструктурах, включая ARM-архитектуру.
Выводы
СУБД «Енисей» — перспективное решение для включения в технологический стек отечественных ERP-систем. Она способна ускорить процесс разработки и обеспечить необходимую архитектурную гибкость, особенно актуальную для динамично развивающихся цифровых платформ.