Облачная, локальная или гибридная ERP: как крупной компании не ошибиться с архитектурой

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

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

Архитектура ERP — это способ размещения и эксплуатации системы: облачная ERP, локальная ERP либо гибридная ERP.

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

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

Требования ИТ-службы, финансов, службы безопасности и владельцев процессов обычно разные. Одни отвечают за первоначальные вложения, другие — за доступ к данным, третьи — за непрерывность операций. Лучше начинать с единого паспорта требований — документа, в котором все эти ожидания переведены в измеримые параметры.

Вот что в него стоит внести:

Количество пользователей само по себе мало о чем говорит. ERP может обслуживать 800 человек в одном офисе — и это одна задача. Второй вариант — 800 пользователей на 25 площадках, где у каждой свой канал связи, складские терминалы и локальные особенности. В этом случае сеть, задержки и резервирование входят в проект с самого начала.

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

Если ERP обменивается данными с другими системами организации, при выборе архитектуры нужно учитывать эти обмены. Обычно это WMS (система управления складом), MES (система управления производством), CRM, ЭДО, кадровые системы, банковские сервисы, BI, государственные системы и собственные приложения компании.

Чем больше обменов в реальном времени, тем внимательнее надо проверять:

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

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

Некоторые требования обязательны: решение либо выполняет их, либо не рассматривается дальше.

До выбора архитектуры компании нужно договориться:

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

Отдельно обратите внимание:

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

Здесь появляются показатели RTO и RPO.

RTO показывает, за какое целевое время сервис обязан вернуться в работу после инцидента. RPO определяет, какой объем информации допустимо потерять. Это промежуток между последней резервной копией и сбоем.

Если владельцы процессов не согласовали RTO и RPO, система проектируется на предположениях, и расхождение обнаруживается при первом инциденте.

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

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

Представим удаленный склад с нестабильным каналом. Он теряет связь с централизованной ERP. В этот момент нужны конкретные ответы:

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

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

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

SLA — это соглашение об уровне сервиса, которое фиксирует измеримые параметры доступности, время реакции на инциденты, порядок обслуживания и ответственность сторон.

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

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

Это не означает, что после перехода в облако внутренняя ИТ-команда становится не нужна. На ее стороне остаются:

Поставщик может обслуживать инфраструктуру. Но он не определит вместо компании, кто согласовывает платежи или кому доступна финансовая информация.

Облачный вариант стоит внимательно рассматривать, если:

Перед решением уточните, сколько времени занимает рост нагрузки на 30–50% и можно ли перенести обновление, пока оно не прошло проверку в тестовой среде.

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

«Полный контроль» — это конкретный список обязательств:

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

Локальную ERP логично рассматривать, когда:

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

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

Для обеих моделей нужен единый жизненный цикл системы.

Совокупная стоимость владения, или TCO, — это сумма всех расходов на внедрение, эксплуатацию, развитие и вывод ERP-системы из эксплуатации за выбранный период.

Капитальные затраты, или CAPEX, — это расходы на активы и инфраструктуру, которые организация приобретает для длительного использования. Операционные затраты, или OPEX, — это регулярные расходы на эксплуатацию, сервисы, поддержку и потребление ресурсов.

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

В расчете удобно использовать контрольные вопросы:

Внедрение, очистка данных и интеграции присутствуют в обеих архитектурах. Их нельзя автоматически записывать в расходы только на облако или только на локальную установку. Эти статьи лучше считать отдельно от самого способа размещения ERP — иначе сравнение покажет разницу между неполными сметами вместо разницы между архитектурами.

Расчет удобно разложить на три группы:

Сложность обычно в том, чтобы не забыть часть расходов.

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

В расчет можно включить:

Высвободившееся время становится эффектом, когда позволяет не нанимать новых сотрудников, снижает затраты или повышает производительность.

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

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

При облачной ERP часть инфраструктурных рисков переходит к поставщику. Но взамен усиливается зависимость от сети, SLA и порядка доступа к данным.

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

Перед договором лучше направить поставщику перечень конкретных вопросов.

Нужно выяснить:

Локальная ERP требует регламентов эксплуатации и назначенных владельцев компонентов.

Минимальный список проверок:

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

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

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

К некомпенсируемым критериям обычно относятся:

Если внутренние правила требуют размещать конкретный класс данных в контролируемой среде, неподходящую модель надо исключить до расчета стоимости.

После этого можно использовать балльную матрицу.

У непрерывного производства выше значение устойчивости операций и связки с MES или WMS. У быстрорастущей распределенной группы важнее могут оказаться скорость масштабирования и подключение новых юридических лиц.

Каждой архитектуре можно присвоить оценку, например от 1 до 5. Но она должна опираться на документ, расчет, демонстрацию или техническую проверку.

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

Для облачной ERP подтверждением могут быть:

Для локальной ERP нужны:

Для каждой архитектуры стоит подготовить четыре расчета:

Кроме того, полезно отдельно смоделировать недоступность одного центра обработки данных, ошибку интеграции, рост объема данных и массовое закрытие периода.

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

На утверждение стоит выносить документы:

С таким набором решение можно перепроверить спустя год, и меньше риск, что важное условие не попало в обсуждение.

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

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

Например, локально могут оставаться критичные операции, а в облако могут перейти:

Границу определяют потоки данных и допустимая задержка.

Гибридную ERP стоит оценивать, если:

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

Для AI-сценариев архитектуру определяют требования к качеству данных, вычислительным ресурсам и правилам доступа к моделям.

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

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

Для AI- и IoT-сценариев стоит проверить восемь параметров:

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

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

До внедрения AI и IoT сначала нужно описать процессы, привести в порядок справочники и назначить владельцев данных. Иначе новые сервисы будут работать с неполными или несогласованными сведениями.

Как выбрать между облачной и локальной архитектурой ERP-системы?

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

Как выбрать ERP для крупной компании?

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

Когда выбирать облачную ERP?

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

Когда выбирать локальную ERP?

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

Как оценить стоимость и выгоды внедрения ERP?

Сравнивать TCO на одинаковом горизонте. В расчет входят единовременные затраты, периодические платежи, информационная безопасность, внутренние трудозатраты, резервирование и миграция.

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

Когда гибридная ERP лучше двух остальных вариантов?

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