Импортозамещение ERP в ритейле: как миграция с SAP на российское решение меняет ИТ-ландшафт и управление мобильными устройствами
В сентябре 2026 года пивоваренная компания «Напитки Вместе» (ранее AB InBev Efes) завершила проект по замене зарубежного ПО от SAP и Microsoft на российскую систему Axenix In.Plan для планирования производства и дистрибуции. По данным TAdviser, этот переход является одним из наиболее масштабных примеров полного отказа от западных систем класса APO/ERP в пользу отечественного стека.
Что произошло
Проект миграции стартовал в январе 2023 года и затронул ключевую для бизнеса функциональность — замену модуля SAP SE APO SNP (Supply Network Planning) и сопутствующих инструментов управления цепочками поставок. Новым ядром корпоративной архитектуры стали продукты российской технологической компании Axenix:
- Модуль Axenix In.Plan Платформа интегрированного планирования.
- Модуль мультиэшелонной оптимизации запасов In.Plan MEIO.
Суть изменений заключается не просто в смене одного программного продукта на другой, а в переходе на платформу, изначально спроектированную под реалии российского рынка, включая требования к производительности при работе с большими массивами данных о товародвижении. Проект курировался консалтинговыми специалистами Axenix, что включало управленческий и кадровый аспекты трансформации. Фактически, бизнес-процессы прогнозирования спроса, формирования мастер-плана производства и распределения готовой продукции были полностью пересобраны на базе нового алгоритмического ядра. Это потребовало глубокой интеграции с унаследованными системами уровня WMS (Warehouse Management System) и историческими данными продаж, которые ранее также находились в контуре экосистемы SAP.
Особое внимание в рамках проекта было уделено отказу от облачных сервисов Microsoft Azure, которые часто используются как инфраструктура для подобных платформ. Переход на локальные серверные мощности или российские облачные платформы стал неотъемлемой частью стратегии обеспечения технологического суверенитета.
Почему это важно
Для руководителей ИТ в российском ритейле кейс «Напитков Вместе» служит прямым сигналом к действию. Если производитель такого масштаба смог отказаться от глубоко интегрированных глобальных решений, то аналогичный путь становится неизбежным стандартом и для крупных розничных сетей.
1. Прямое влияние на мобильные рабочие места
Планирование дистрибуции неразрывно связано с работой торговых представителей и водителей-экспедиторов. В старой парадигме (SAP + западные MDM/EMM) устройства получали политики через условную Microsoft Intune или VMWare Workspace ONE. При переходе на российский ERP-стек возникает критическая необходимость синхронизировать его с отечественной системой управления мобильными устройствами.
- Проблема: Несовместимость протоколов аутентификации. Западные системы опираются на Azure AD, тогда как российская альтернатива требует интеграции с отечественными провайдерами идентификации (например, через SCIM).
- Риск: Разрыв единого профиля пользователя. Торговый представитель может иметь актуальные данные об остатках товара в новой системе In.Plan, но не получить их на свое устройство вовремя из-за сбоя в политике доставки конфигураций.
2. Соответствие законодательству (152-ФЗ)
Перенос данных о производстве, логистике и клиентах с зарубежных серверов на территорию РФ — прямое требование регуляторов. Однако замена сервера приложения — это только половина дела. Необходимо убедиться, что каналы связи между новым планировщиком (Axenix In.Plan) и мобильными клиентами защищены сертифицированными СКЗИ. Использование стандартных TLS-шлюзов без поддержки ГОСТ-алгоритмов создает риски несоответствия требованиям ФСТЭК и ФСБ при обработке персональных данных клиентов и сотрудников.
3. Смежный кейс: Аврора ОС и специализированные задачи
Многие производственные площадки используют терминалы сбора данных (ТСД). Ранее они работали на Android GMS (Google Mobile Services). Смена бэкенда дает повод пересмотреть весь стэк мобильных устройств. Для производств с режимными требованиями логичным шагом становится перевод ТСД на ОС Аврора. Интеграция Axenix In.Plan с агентами на Авроре требует использования российских EMM-систем, поддерживающих протоколы этой ОС, так как стандартные API Google Play здесь недоступны.
4. Операционная непрерывность
Переход с SAP APO на In.Plan MEIO меняет математическую модель пополнения запасов. Это означает изменение частоты и объемов заказов, поступающих в магазины. Мобильные сотрудники должны мгновенно видеть новые KPI и маршруты в своих приложениях. Любая задержка в обновлении политик MDM приведет к тому, что курьеры будут ездить по старым маршрутам, неэффективно используя транспорт.
Что делать
ИТ-руководителям ритейла, планирующим аналогичную миграцию, необходимо выстроить дорожную карту, где внедрение новой учетной системы идет параллельно с перенастройкой мобильного периметра.
Шаг 1. Аудит интеграционных шин и подготовка каталога пользователей
Перед отключением SAP необходимо выгрузить всю структуру атрибутов пользователей (должности, регионы ответственности, лимиты), которые использовались для динамических групп в западном MDM.
- Настройте двустороннюю синхронизацию через /docs/scim. Используйте отечественный Identity Provider (IdP) как источник истины.
- Проверьте маппинг полей. Убедитесь, что кастомный атрибут
sales_territory_idиз SAP корректно передается в поле профиля устройства в новом MDM, чтобы политика ограничений автоматически применялась при перемещении сотрудника между филиалами.
Шаг 2. Пересмотр политик безопасности устройств (/docs/policies/)
Западные решения имели встроенные механизмы защиты контейнеризации (Samsung Knox, Apple Managed Open In). Российские аналоги требуют ручной настройки аналогичных правил.
- Создайте политику "Запрет экспорта корпоративных данных". Для приложений, работающих с новым планировщиком (например, нативный клиент In.Plan или веб-интерфейс), заблокируйте функции "Поделиться", скриншоты и копирование текста в личные мессенджеры.
- Пример конфигурации для ограничения WebView: пропишите в настройках MDM принудительное использование белого списка URL (
allowlist) для доступа к новому порталу планирования, блокируя любые попытки открыть его в личном браузере Chrome.
Шаг 3. Подготовка инфраструктуры для ФЗ-152
Если новый планировщик развернут в частном облаке, убедитесь, что трафик с мобильных устройств до него шифруется правильно.
- Выпустите пользовательские сертификаты через внутренний УЦ и доставьте их на устройства через MDM.
- Настройте VPN-профиль типа Always-on. Критически важно использовать российские криптошлюзы (например, КриптоПро NGate), чтобы обеспечить защищенный канал для передачи планов отгрузки, содержащих коммерческую тайну.
Шаг 4. Тестирование на реальных сценариях полевого персонала
Не ограничивайтесь тестированием десктопного интерфейса Axenix In.Plan. Симулируйте работу торгового представителя:
- Устройство теряет связь 4G в торговом центре. Как ведет себя приложение? Использует ли оно кэшированные данные о матрицах товаров, полученные от нового планировщика?
- Проверка работы push-уведомлений. Новая система должна инициировать отправку срочных заданий (например, внеплановая допоставка) через сервисы уведомлений вашего MDM. Убедитесь, что FCM (Firebase Cloud Messaging) заменен на работающий в РФ аналог или гибридный шлюз.
Шаг 5. Управление парком ТСД и специализированных устройств
Если часть ваших процессов завязана на складскую логистику, которая теперь управляется из In.Plan:
- Подготовьте скрипты массовой перепрошивки. Используйте команды ADB в режиме владельца устройства (Device Owner) для удаления старых агентов SAP и установки новых сертификатов Минцифры.
- Команда для очистки старого пакета:
adb shell pm uninstall --user 0 com.sap.mobile.fiori - Команда для установки корневого сертификата:
adb root && adb remount && adb push cert.crt /system/etc/security/cacerts/ && adb reboot - Рассмотрите миграцию части парка на /docs/aurora для изоляции производственной среды от потребительского интернета.
Источник: https://www.tadviser.ru/a/965688