Облачная или локальная ERP: как выбрать архитектуру для крупной компании в России
2026-09-18 10:44
Облачную ERP выбирают, когда важны быстрый запуск и прогнозируемые операционные затраты. Локальную ERP выбирают, когда нужны прямой контроль над инфраструктурой, данными и графиком технических изменений. Выбор нельзя сводить к вопросу, где дешевле сервер, потому что от архитектуры ERP зависят управляемость данных, устойчивость процессов, скорость изменений, состав затрат и зависимость от поставщика за жизненный цикл системы. Решение корректно только после сравнения требований бизнеса, сложности схемы интеграций, модели доступа, совокупной стоимости владения (TCO) и рисков непрерывности работы.
ERP-система — это система управления ресурсами предприятия, которая объединяет финансовый учет, закупки, производство, склад, продажи, персонал и другие сквозные процессы в единой модели данных.
Архитектура ERP — это вариант размещения и эксплуатации ERP-системы: облачная ERP, локальная ERP или гибридная ERP. Архитектура не равна модели лицензирования и сама по себе не определяет метод внедрения.
Что сравнивать при выборе архитектуры ERP для крупной компании
Архитектуру ERP выбирают по ограничениям, которые нельзя компенсировать удобством интерфейса или низкой начальной ценой. Такими ограничениями обычно становятся требования к размещению данных, допустимое время простоя, работа производственных площадок без стабильной связи и зависимость критичных процессов от внешних сервисов.
Само по себе число пользователей мало говорит о требованиях к инфраструктуре. Важнее распределение нагрузки: сколько сотрудников одновременно закрывают период, проводят документы, работают со складскими терминалами, согласуют закупки или формируют отчетность. ERP для 800 пользователей в одном офисе и ERP для 800 пользователей на 25 площадках — разные инфраструктурные задачи.
Исходные данные, которые нужны до выбора архитектуры
До сравнения облачной и локальной ERP необходимо собрать единый паспорт требований. Без него обсуждение архитектуры затягивается из-за несогласованных требований ИТ, службы безопасности и финансов.
Паспорт требований включает восемь блоков данных:
Количество пользователей и ролей. Следует зафиксировать общее число пользователей, пиковое число одновременных сессий, внешних пользователей и пользователей с расширенными правами.
Организационная структура. Нужно определить число юридических лиц, филиалов, производственных площадок, складов и регионов присутствия.
Критичность процессов. Для каждого процесса требуется установить допустимое время простоя: например, 15 минут, 4 часа или рабочий день.
Требования к данным. Следует определить классы данных, правила размещения, хранения резервных копий, журналирования и удаления информации.
Схема интеграций. Необходимо описать все системы, с которыми ERP обменивается данными: WMS (система управления складом), MES (система управления производством), CRM, электронный документооборот (ЭДО), кадровые системы, банковские сервисы, BI, государственные системы и собственные приложения.
Сетевая модель. Нужно проверить качество каналов связи на площадках, резервирование каналов, задержки и сценарии работы при потере внешнего подключения.
Эксплуатационная модель. Следует определить, кто отвечает за мониторинг, обновления, резервное копирование, управление доступом и расследование инцидентов.
План роста. В оценку включают новые предприятия, сделки по слиянию и поглощению, выход в регионы, новые склады и возможное удвоение объема операций.
От сложности схемы интеграций зависят задержки и устойчивость обмена данными, а вместе с ними и выбор архитектуры. Чем больше систем обменивается данными в реальном времени, тем выше требования к сети, программным интерфейсам (API), очередям сообщений и мониторингу ошибок.
Требования к непрерывности определяют схему резервирования. Если склад или производство не могут остановиться при потере внешнего канала связи, облачная ERP потребует устойчивой сетевой схемы, локального компонента либо альтернативного процесса работы.
От требований к контролю доступа зависит модель идентификации. При сложной ролевой модели, использовании корпоративного каталога и обязательной многофакторной аутентификации (MFA) необходимо заранее проверить интеграцию ERP с системой управления идентификацией и доступом (IAM) и возможность аудита действий привилегированных пользователей.
Какие российские требования влияют на выбор архитектуры ERP
Для российских компаний архитектура ERP должна учитывать правовые, организационные и инфраструктурные ограничения. Вопрос не ограничивается местом установки серверов.
Проверке подлежат восемь условий:
размещение персональных данных и корпоративной информации;
возможность предоставления журналов событий по запросу службы безопасности;
условия доступа технической поддержки поставщика к продуктивной среде;
порядок передачи данных при смене поставщика;
доступность российских дата-центров и резервных площадок;
совместимость с отечественными средствами защиты информации, если они обязательны внутренними стандартами;
работоспособность интеграций с российскими системами электронного документооборота, банками, маркировкой и государственными информационными системами;
наличие решения в реестре отечественного программного обеспечения, если компания подпадает под соответствующие требования.
Требование о применении программного обеспечения из реестра распространяется не на всех участников рынка. Оно касается госсектора, объектов критической информационной инфраструктуры и закупок по государственным процедурам. Для остальных компаний реестр работает как входной фильтр допуска, если он задан внутренними правилами, и не является критерием сравнения.
Локальную ERP часто считают более безопасной по умолчанию. Такое допущение верно только тогда, когда компания управляет уязвимостями, резервным копированием, сегментацией сети и правами доступа. Без мониторинга компания не сможет вовремя обнаружить сбои, нехватку ресурсов и нарушения работы резервного копирования.
Сравнение облачной и локальной ERP по ключевым критериям
Облачная ERP подходит, когда компании важны быстрый запуск, прогнозируемые операционные затраты и передача части инфраструктурных задач поставщику. Локальная ERP подходит, когда критичны прямой контроль над размещением данных, глубокая интеграция с внутренней средой и самостоятельное управление техническими изменениями. Оба варианта требуют выстроенных процессов эксплуатации.
Основная разница между вариантами — в распределении ответственности за инфраструктуру, обновления и восстановление.
Критерий
Облачная ERP
Локальная ERP
Что проверить до решения
Размещение системы
ERP размещается в инфраструктуре поставщика или в выделенной облачной среде
ERP размещается в инфраструктуре организации или в выделенной среде под ее контролем
Место хранения продуктивных данных, резервных копий и журналов
Первоначальные затраты
Обычно ниже затраты на собственные серверы и базовую инфраструктуру
Обычно выше капитальные затраты на серверы, системы хранения данных (СХД), лицензии платформы и резервирование
Полный состав первоначального бюджета, включая инфраструктуру и проектные работы
Регулярные затраты
Основная часть — подписка, потребление ресурсов и сервисы эксплуатации
Основная часть — поддержка, электроэнергия, эксплуатация, обновления, резервное копирование
Индексация тарифов, стоимость роста нагрузки, состав услуг
Масштабирование
Ресурсы можно наращивать быстрее при наличии технической и договорной возможности
Масштабирование зависит от закупки оборудования, сроков поставки и запаса мощности
Срок увеличения мощности при росте нагрузки на 30–50 %
Контроль инфраструктуры
Часть контроля передана поставщику, но может быть закреплена договором и настройками
Организация самостоятельно определяет конфигурацию, сегментацию и график изменений
Границы ответственности ИТ-службы и поставщика
Обновления
Обычно выполняются по согласованному окну и правилам поставщика
Выполняются по графику организации
Возможность отложить обновление и протестировать его до переноса в продуктивную среду
Сетевая зависимость
Критична доступность каналов связи между пользователями, площадками и облачной средой
Внутри корпоративной сети зависимость от внешнего канала может быть ниже
Резервные каналы, задержки, сценарии работы при ухудшении связи
Схема интеграций
Потребуются защищенные каналы, шлюзы API, контроль обменов и сетевые правила
Внутренние интеграции часто строятся проще, внешние остаются
Контроль строится на договоре, технических настройках, журналировании и проверке поставщика
Контроль строится на внутренних процессах, средствах защиты и компетенциях команды
Шифрование, MFA, управление привилегированным доступом (PAM), сбор и анализ событий безопасности (SIEM), порядок реагирования на инциденты
Поддержка и уровень сервиса
Параметры сервиса и ответственность поставщика закреплены в соглашении об уровне сервиса (SLA)
Параметры формируются внутренней ИТ-службой и договорами с подрядчиками
Доступность, время реакции, порядок компенсаций, окна работ
Выход из решения
Нужно заранее определить экспорт данных и сроки миграции
Нужно учитывать перенос инфраструктуры, лицензий и сопровождения
Форматы выгрузки, стоимость миграции, права на данные
SLA не является гарантией отсутствия простоев. Соглашение фиксирует измеримые параметры доступности, время реакции на инциденты, порядок обслуживания и ответственность сторон, то есть определяет, что произойдет после инцидента и в какие сроки.
Ошибки при сравнении архитектур ERP
Первая ошибка — сравнивать ежемесячную подписку облачной ERP со стоимостью серверов для локальной ERP. Это разные части экономики. Для корректного сравнения совокупную стоимость владения считают за один и тот же период — жизненный цикл системы, горизонт которого задает финансовая политика компании.
Вторая ошибка — считать, что при облачной ERP внутренняя ИТ-команда не нужна. Она нужна: управление ролями, качество данных, тестирование доработок, контроль интеграций, приемка обновлений и работа с бизнес-пользователями сохраняются в любой архитектуре. Поставщик может эксплуатировать инфраструктуру, но не может вместо компании определить, кто имеет право менять, например, закупочные лимиты.
Третья ошибка — выбирать локальную ERP ради полного контроля, не оценивая цену этого контроля. Собственная инфраструктура требует резервирования, мониторинга, регулярной установки обновлений, тестовых сред и специалистов. Без ресурсов контроль остается формальным, а технический долг накапливается.
Независимо от модели размещения компании нужны владельцы ролей, регламент обновлений, мониторинг интеграций и процедуры восстановления.
Как оценить стоимость и выгоды облачной и локальной ERP
Экономику архитектуры ERP рассчитывают через TCO за жизненный цикл системы, одинаковый для обоих вариантов. Сравнение первоначальных расходов с подпиской за первый год искажает решение: при локальной ERP часть расходов концентрируется в начале проекта, при облачной значительная часть затрат распределяется по периодам.
TCO — это сумма всех расходов на внедрение, эксплуатацию, развитие и вывод ERP-системы из эксплуатации за выбранный период. Горизонт расчета задает финансовая политика компании, обычно его привязывают к сроку полезного использования системы.
Капитальные затраты (CAPEX) — это расходы на активы и инфраструктуру, которые компания приобретает для длительного использования. Операционные затраты (OPEX) — это регулярные расходы на эксплуатацию, сервисы, поддержку и потребление ресурсов.
Что включить в расчет TCO
Лицензии или подписка — облачная: подписка и потребление ресурсов; локальная: лицензии и поддержка производителя.
Миграция и выход — облачная: экспорт данных, смена поставщика; локальная: обновление инфраструктуры, вывод из эксплуатации.
Затраты на внедрение, интеграции и очистку данных присутствуют в обеих архитектурах, поэтому их учитывают отдельно от расходов на размещение ERP.
Как рассчитать выгоды ERP-внедрения
Выгоды связывают с измеримыми процессами. Экономический эффект возникает не от самой ERP, а от стандартизации процессов, качества данных и управляемости операций.
В расчет включают:
сокращение времени закрытия периода;
снижение доли ручного ввода и повторной обработки документов;
уменьшение ошибок в закупках, запасах и расчетах;
снижение объема избыточных запасов;
ускорение согласования заявок, заказов и платежей;
рост точности производственного и финансового планирования;
сокращение времени подготовки управленческой отчетности;
снижение затрат на поддержку нескольких разрозненных систем;
уменьшение рисков несанкционированного доступа за счет единой ролевой модели.
При сокращении ручных операций снижается трудоемкость и число исправлений. Экономический эффект считают только там, где высвобожденное время приводит к сокращению затрат, отказу от найма или росту производительности.
От единой нормативно-справочной информации зависит качество планирования: чем меньше расхождений между подразделениями, тем точнее план. Если закупки, финансы и склад используют разные классификаторы, точный отчет не получится даже на дорогой инфраструктуре.
Практическая модель расчета
Для каждой архитектуры готовят четыре сценария:
базовый — текущий объем пользователей, операций и интеграций;
рост — увеличение пользователей или нагрузки на 30–50 %;
сценарий отказа — потеря канала связи, задержка обновления, рост стоимости ресурсов;
выход — смена поставщика, перенос данных или смена размещения.
TCO складывается из трех групп затрат:
единовременные: внедрение, интеграции, доработки, миграция данных, закупка инфраструктуры и резервирование;
периодические: лицензии или подписка, поддержка, эксплуатация, информационная безопасность, внутренние трудозатраты;
затраты на выход: экспорт данных, перенос интеграций, вывод инфраструктуры из эксплуатации.
Выгоды приводят к текущей стоимости по ставке дисконтирования и сопоставляют с затратами на одинаковом горизонте. Иначе годовой эффект сравнивается с многолетними обязательствами.
Риски облачной и локальной ERP для российских компаний
Риски облачной и локальной ERP различаются по владельцу ответственности, а не по факту наличия угроз. При облачной ERP часть инфраструктурных рисков переходит к поставщику, но зависимость от сети, условий SLA и порядка доступа к данным выше. При локальной ERP внешняя зависимость ниже, но весь объем задач по эксплуатации и защите инфраструктуры остается у организации.
Для российской компании проверка рисков охватывает размещение данных, доступность каналов связи, договорные условия, резервное копирование, импортонезависимость критичных компонентов и возможность сопровождения выбранного решения.
Риск
Облачная ERP: как снизить риск
Локальная ERP: как снизить риск
Несанкционированный доступ к продуктивной среде
Проверить интеграцию с корпоративной IAM-системой, MFA, журналы действий и порядок доступа технической поддержки
Проверить сегментацию сети, PAM, управление привилегированными учетными записями и аудит действий
Потеря доступа к ERP при отказе канала связи
Резервные каналы, мониторинг связности, сценарии работы при ухудшении связи
Резервные каналы для удаленных площадок и внешних пользователей, VPN, контроль пропускной способности
Простой из-за недоступности инфраструктуры
SLA, резервирование дата-центра, целевое время восстановления (RTO), допустимый объем потери данных (RPO), порядок уведомления об инцидентах
Собственные резервные мощности, план аварийного восстановления, регулярное тестирование восстановления, дежурная команда
Зависимость от поставщика
Зафиксировать тарифы, условия поддержки, порядок доступа к данным и правила миграции
Оценить компетенции администраторов, поддержку платформы и доступность специалистов на рынке
Деградация времени отклика под нагрузкой
Проверить маршруты, задержки и нагрузку на интеграции
Проверить запас ресурсов, состояние оборудования и конфигурацию
Сбой процессов при обновлении
Тестовая среда, согласованное окно работ, план отката
Регламент установки обновлений и тестирования, отдельная тестовая среда
Невосстановимая потеря данных
Зафиксировать частоту, срок хранения, географию и процедуру восстановления резервных копий
Изолированное хранение резервных копий и регулярные тесты восстановления
Неурегулированные юридические условия
Определить применимое право, ответственность, порядок выдачи данных и аудита
Определить ответственность подразделений и подрядчиков, правила доступа и хранения данных
Что запросить у поставщика облачной ERP
Поставщику облачной ERP направляют перечень проверяемых требований. В него входят следующие вопросы:
Где физически размещаются продуктивные данные, резервные копии и журналы событий?
Какие параметры доступности, времени реакции и восстановления закреплены в SLA?
Как рассчитываются RTO и RPO для конкретного сервиса?
Кто и на каких основаниях получает административный доступ к среде?
Как организованы многофакторная аутентификация, журналирование и выгрузка журналов событий?
Как проводится изоляция клиентов в общей или выделенной среде?
Каков порядок уведомления об инциденте?
В каком формате и за какой срок можно выгрузить данные при прекращении договора?
Какие российские дата-центры и резервные площадки используются?
Как меняется цена при росте пользователей, транзакций и объема данных?
Для критичных процессов значения RTO и RPO утверждает бизнес: ИТ-служба не определяет их в одиночку.
Что проверить для локальной ERP
Локальная ERP требует регламентов эксплуатации и распределенной ответственности. Проверить нужно семь пунктов:
есть ли отдельные продуктивная, тестовая и резервная среды;
обеспечено ли резервирование ключевых компонентов;
тестируется ли восстановление данных по утвержденному графику;
определены ли владельцы серверов, базы данных, приложения и схемы интеграций;
ведется ли мониторинг производительности и событий безопасности;
есть ли план замены оборудования и продления технической поддержки;
может ли организация восстановить ERP при отказе площадки, а не только отдельного сервера.
Алгоритм выбора архитектуры ERP
Выбор между облачной и локальной ERP проводят как управляемую оценку. Сначала фиксируют ограничения, затем сравнивают варианты по единой матрице, после чего проверяют экономику и риски. Решение нельзя принимать только на основе презентации поставщика или предпочтений внутренней ИТ-команды.
Шаг 1. Собрать требования бизнеса, ИТ и службы безопасности
Нужно сформировать единый перечень процессов, пользователей, площадок, интеграций, классов данных и требований к доступности. Каждый пункт должен иметь владельца: бизнес-подразделение, ИТ, информационная безопасность, финансы или юридическая служба.
Результат шага — паспорт требований, в котором указаны измеримые параметры: число пользователей, пиковая нагрузка, допустимое время простоя, требования к RTO и RPO, состав схемы интеграций.
Шаг 2. Определить критерии, которые нельзя компенсировать
Требования к размещению данных, доступу без внешнего канала связи и обязательной аутентификации не подлежат балльному сравнению. Если внутренние правила требуют размещения определенного класса данных в контролируемой среде, вариант, который не выполняет это требование, исключается до расчета стоимости.
К некомпенсируемым критериям часто относятся требования:
обязательное размещение определенных данных;
требования к доступу без внешнего канала связи;
максимальное допустимое время простоя критичного процесса;
обязательные средства аутентификации и журналирования;
возможность экспорта данных при завершении договора;
совместимость с ключевыми системами схемы интеграций.
Шаг 3. Назначить веса компенсируемым критериям
После отсечения неподходящих вариантов нужно задать веса оставшимся критериям. Для производственной компании выше вес непрерывности операций и интеграции с MES или WMS. Для быстрорастущей распределенной группы компаний может быть важнее скорость масштабирования и подключения новых юридических лиц.
Непрерывность критичных процессов — 20%. Информационная безопасность — 20%. Схема интеграций — 15%. TCO за жизненный цикл — 20%. Масштабирование — 10%. Управляемость изменений — 10%. Зависимость от поставщика — 5%. Веса не универсальны и зависят от специфики бизнеса.
Веса не универсальны. Компания с непрерывным производством и компания с проектным бизнесом могут получить разные результаты при одной и той же матрице.
Шаг 4. Оценить варианты
Каждому варианту присваивается оценка по шкале, например от 1 до 5. Оценка должна подтверждаться документом, расчетом, демонстрацией или результатом технической проверки. Заявление поставщика без подтверждающего документа доказательством не считается.
Для облачной ERP подтверждением могут быть проект SLA, описание дата-центра, результаты нагрузочного тестирования, регламент резервного копирования и условия выгрузки данных. Для локальной ERP — спецификация инфраструктуры, расчет производительности, план аварийного восстановления, оценка команды эксплуатации и смета резервирования.
Шаг 5. Проверить сценарии отказа
Архитектуру нужно проверить в нормальном режиме и при отказах. Полезно смоделировать потерю основного канала связи, недоступность одного дата-центра, ошибку интеграции, рост объема данных и массовое закрытие периода.
Ограничением часто оказывается устаревший интеграционный сервис, который не попал в расчет. Архитектура ERP устойчива настолько, насколько устойчива ее схема интеграций.
Шаг 6. Подготовить решение для архитектурного комитета
На утверждение выносят комплект из восьми материалов:
паспорт требований;
список некомпенсируемых критериев;
матрицу оценки с весами;
расчет TCO за жизненный цикл;
реестр рисков и меры контроля;
результаты нагрузочных и интеграционных проверок;
проект SLA или внутренний регламент эксплуатации;
план миграции и сценарий выхода из решения.
Такой комплект делает выбор проверяемым и воспроизводимым.
Когда выбирают гибридную ERP
Гибридную ERP оценивают, когда часть процессов и данных должна находиться в контролируемой локальной инфраструктуре, а другая часть может использовать облачные сервисы. Такой подход выбирают из-за действующих ограничений: производственных площадок, нестабильной связи, требований к данным, распределенной аналитики или необходимости быстро подключать новые сервисы.
Гибридная архитектура ERP может включать локальное ядро для критичных операций и облачные компоненты для аналитики, планирования, резервного доступа, отдельных сервисов документооборота или взаимодействия с внешними контрагентами. Границу определяют потоки данных и требования к задержке.
Гибридную ERP имеет смысл оценивать в ситуациях:
критичные производственные или складские операции требуют минимальной зависимости от внешних каналов связи;
часть данных должна храниться в контролируемой локальной инфраструктуре;
компании нужны облачные аналитические мощности для нерегулярных, но ресурсоемких расчетов;
разные предприятия группы находятся на разном уровне зрелости инфраструктуры;
требуется поэтапная миграция с существующей локальной ERP;
в схеме интеграций есть локальные промышленные системы и внешние цифровые сервисы.
Мультиоблачность — это использование нескольких облачных сред или сервисов. По данным исследования MWS Cloud «Технологические стратегии бизнеса» (опрос 700 российских компаний, ноябрь 2025 года), минимум с двумя облачными провайдерами работает 41 % компаний, которые используют виртуальную инфраструктуру; у крупнейшего бизнеса эта доля выше, чем у среднего и малого. Для ERP такая модель повышает требования к управлению идентификацией, сетевой связности, мониторингу и единым правилам обмена данными.
Как AI, IoT и модульные архитектуры меняют требования к ERP
Для AI-сценариев архитектуру определяют требования к качеству данных, вычислительным ресурсам и контролю доступа к моделям. Прогнозирование спроса, интеллектуальная обработка документов или выявление аномалий не дадут достоверного результата, если справочники не унифицированы, а данные поступают с задержкой в несколько дней.
От объема и скорости потоков данных в IoT-сценариях зависит архитектура. Датчики оборудования, телеметрия транспорта и складские устройства могут создавать тысячи событий в минуту. Передавать весь поток напрямую в центральную ERP обычно нерационально: потребуется промежуточный слой обработки, очереди сообщений и правила агрегации.
Для AI- и IoT-сценариев проверяют восемь параметров:
качество нормативно-справочной информации;
владельцы данных и правила доступа;
задержка между источником данных и ERP;
наличие API и событийной интеграции;
вычислительная нагрузка AI-моделей;
место хранения обучающих и операционных данных;
способность сети обслуживать потоки данных от устройств;
порядок реакции на ошибки датчиков и дубли событий.
Модульная (композируемая) архитектура остается ориентиром для корпоративных приложений, но применимость подхода зависит от интеграционной модели организации. Для ERP практический вывод один: нужно выбрать ядро и сохранить возможность развития схемы интеграций.
Инженерия внутренних платформ означает, что выделенная команда задает единые правила интеграций, идентификации, мониторинга и развертывания. По прогнозу Gartner, к 2026 году такие команды создадут 80 % крупных организаций, занимающихся разработкой программного обеспечения, против 45 % в 2022 году. Не каждой организации нужна собственная платформа, но каждой нужно определить, кто поддерживает архитектурные стандарты.
Перед внедрением AI и IoT описывают процессы, унифицируют справочники и назначают владельцев данных: иначе новые сервисы будут получать неполные или несогласованные данные.
FAQ: выбор между облачной и локальной ERP
Как выбрать между облачной и локальной архитектурой ERP-системы?
Сначала определяют некомпенсируемые требования, такие как размещение данных, допустимое время простоя, работу площадок при потере связи, требования к доступу и схему интеграций. Затем облачную и локальную ERP сравнивают по единой матрице, рассчитывают TCO за жизненный цикл и проверяют сценарии отказа.
Что дешевле: облачная или локальная ERP?
Однозначного ответа нет: сравнивают TCO за жизненный цикл, расходы первого года для этого не подходят. При облачной ERP ниже первоначальные вложения, но регулярные платежи растут вместе с числом пользователей и объемом данных. При локальной ERP выше первоначальные вложения, зато часть расходов приходится на собственную инфраструктуру и команду. Результат зависит от нагрузки, срока эксплуатации и требований к резервированию.
Как оценить стоимость и выгоды от внедрения ERP-системы?
Нужно рассчитать TCO за жизненный цикл для обеих архитектур. В расчет включают единовременные затраты, периодические платежи, информационную безопасность, внутренние трудозатраты, резервирование и затраты на выход. Выгоды оценивают через измеримые показатели: время закрытия периода, трудоемкость операций, ошибки, запасы и скорость подготовки отчетности.