Миграция на российское ПО: опыт Tarkett и уроки для инфраструктуры ритейла

29.09.2026 · 4 мин чтения

Компания Tarkett, один из мировых лидеров в производстве напольных покрытий, завершила масштабный проект по переходу с SAP на 1С:ERP. Ключевым элементом этого проекта стала миграция баз данных на российскую СУБД Postgres Pro Enterprise для обеспечения работы новой системы. По данным New Retail, главной целью было не просто заменить программное обеспечение, а выстроить отказоустойчивую инфраструктуру, способную обеспечить доступность сервиса на уровне 99,9%.

Что произошло

Проект перехода с глобальной ERP-системы SAP на отечественную платформу 1С:ERP потребовал от компании полной перестройки серверной архитектуры. Поскольку законодательство РФ (включая требования к критической информационной инфраструктуре) стимулирует использование отечественного софта, выбор пал на сертифицированную СУБД Postgres Pro Enterprise. Основная техническая задача заключалась в создании высокодоступного кластера базы данных, который бы гарантировал непрерывность бизнес-процессов — от оформления заказа до отгрузки товара со склада. Для достижения показателя доступности "три девятки" была реализована архитектура с синхронной репликацией данных между основным и резервным узлами кластера. Это означает, что транзакция считается завершенной только после записи как на основной, так и на резервный сервер, что исключает потерю данных при сбое. Механизм автоматического переключения (failover) был настроен таким образом, чтобы время простоя в случае отказа основного узла не превышало 30 минут. В этот интервал входит автоматическое обнаружение сбоя, перенаправление трафика приложений на резервный узел и проверка целостности данных.

Почему это важно

Для российского ритейла кейс Tarkett является знаковым, поскольку он демонстрирует зрелость отечественных программных продуктов уровня Enterprise. Однако прямая аналогия с кассами или ТСД здесь работает иначе. Если бэкенд вашей торговой сети (на базе 1С) падает на 30 минут, вы останавливаете отгрузки центральным складом. Но если падают мобильные устройства сотрудников торгового зала — курьеров, сборщиков заказов или кассиров на планшетах — ваш розничный канал теряет деньги каждую секунду.

Связь между MDM-инфраструктурой и стабильностью корпоративных систем становится критичной:

• Синхронизация справочников: Планшеты торговых представителей и ТСД на складе постоянно обращаются к API 1С за остатками и ценами. Недоступность БД даже на несколько минут приводит к тому, что сотрудники видят устаревшие данные, принимают неверные заказы или не могут провести оплату.
• Управление конфигурациями: При миграции ERP меняются эндпоинты API, форматы обмена данными и учетные записи служб. Без централизованного управления через MDM вам придется вручную обновлять профили подключения на сотнях или тысячах Android-устройств, что парализует работу магазинов.
• Соответствие требованиям безопасности: Переход на российские решения часто связан с выполнением норм законодательства о персональных данных (152-ФЗ) и требованиями регуляторов к импортозамещению. Использование российских ОС (например, Авроры) на мобильных устройствах должно сопровождаться соответствующей российской системой управления — Komendant MDM, которая также включена в реестр отечественного ПО.

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

Что делать

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

• Настройка политик условного доступа (Conditional Access). Через консоль /docs/policies следует создать правило, блокирующее доступ мобильного приложения к серверам 1С, если версия клиентского ПО устарела. Это предотвратит ошибки формата данных во время миграционного окна.
• Параметр политики: Minimum Application Version.
• Действие при несоответствии: Block access to specific Wi-Fi SSID или Wipe corporate data.
• Централизованное управление файлами конфигурации. Вместо ручного копирования файлов nethasp.ini или настроек HTTP-соединений используйте функцию File Sync в MDM. Разместите эталонный конфиг /sdcard/Android/data/com.e1c.mobile/files/config.json на управляющем сервере. Система сама раскидает его по устройствам при смене IP-адреса сервера 1С.
• Автоматизация обновления сертификатов. При переходе на новые домены внутренних сервисов старые SSL-сертификаты станут недействительны. Используйте скрипты ADB, отправляемые через MDM, для автоматической установки новых корневых сертификатов в хранилище пользователя:

    adb push new_ca.cer /sdcard/
    adb shell "su -c 'cat /sdcard/new_ca.cer >> /system/etc/security/cacerts/bks_file'"

• Подготовка сценариев автономной работы. На случай недоступности центральной БД более чем на 30 минут, настройте локальное кэширование на ТСД. Убедитесь, что приложение способно работать офлайн, накапливая чеки и накладные в локальной SQLite-базе, а политика MDM (/docs/) запрещает очистку данных приложения (Disallow Clear Data) до успешной выгрузки.
• Интеграция с каталогом пользователей. Чтобы избежать задержек с созданием учетных записей для новых сотрудников в период пиковых нагрузок после запуска новой ERP, настройте SCIM-интеграцию согласно документации /docs/scim/. Это позволит создавать и блокировать доступ на устройствах одновременно с кадровыми приказами в 1С:ЗУП.

Источник: https://new-retail.ru/business/keysy/tarkett_migratsiya_na_postgres_pro_enterprise_dlya_1s_v_ramkakh_proekta_perekhoda_s_sap_na_1s_erp

---

Источник: https://new-retail.ru/business/keysy/tarkett_migratsiya_na_postgres_pro_enterprise_dlya_1s_v_ramkakh_proekta_perekhoda_s_sap_na_1s_erp/