Миграция Tarkett на Postgres Pro Enterprise: уроки для ритейл-ИТ при отказе от SAP и выборе СУБД

18.09.2026 · 5 мин чтения

Крупный производитель напольных покрытий, компания Таркетт Рус (Tarkett), завершила проект миграции с SAP на 1С:ERP, в рамках которого была выполнена замена базы данных на отечественное решение — Postgres Pro Enterprise. По данным [TAdviser](https://www.tadviser.ru/a/966644), этот шаг является частью комплексного проекта по переходу на российские программные продукты.

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

Компания «Таркетт Рус» реализовала масштабный ИТ-проект, включающий два ключевых технологических перехода:

1. Отказ от глобальной ERP-системы SAP в пользу конфигурации «1С:ERP Управление предприятием». Это ядро бизнес-процессов компании, охватывающее финансы, логистику, закупки и производство.

2. Замена проприетарной системы управления базами данных (предположительно, Oracle Database, исторически используемой с SAP) на российскую СУБД Postgres Pro Enterprise, сертифицированную для работы с платформой 1С.

Проектная задача заключалась не просто в смене ПО, а в обеспечении непрерывности бизнеса во время переноса исторических данных, интеграции с другими системами и сохранения производительности транзакционных процессов на уровне, сопоставимом с SAP. Выбор именно версии Enterprise обусловлен требованиями к высокой доступности (High Availability) через встроенные механизмы кластеризации, повышенной производительности за счет оптимизаций под тяжелые OLTP-нагрузки платформы 1С, а также необходимости расширенного мониторинга и технической поддержки в режиме 24/7. Для обеспечения целостности данных часто применяется режим синхронной репликации между основным и резервным узлом кластера, что исключает потерю информации при сбое одного из серверов.

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

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

Во-первых, происходит легитимизация связки 1С + российская СУБД как полноценной альтернативы глобальным экосистемам уровня SAP/Oracle. Если производственно-торговая компания такого масштаба успешно эксплуатирует эту связку, то технические риски считаются управляемыми. Для сетей с распределенной филиальной структурой (магазины, склады) это означает возможность строить импортонезависимое ядро бэк-офиса без опасения столкнуться с непреодолимыми ограничениями платформы.

Во-вторых, фокус смещается на уровень инфраструктуры данных. Проблема не в том, чтобы запустить 1С, а в том, чтобы она работала быстро и надежно под нагрузкой крупной розницы или дистрибуции. Использование специализированной сборки, такой как Postgres Pro Enterprise, решает специфические проблемы "из коробки":

• Оптимизированное выполнение сложных запросов в учетных регистрах 1С.
• Секционирование (partitioning) огромных таблиц документов и проводок, что кардинально ускоряет регламентные операции закрытия месяца.
• Встроенный пулер соединений, снижающий накладные расходы на создание сессий при большом количестве одновременных пользователей (кассиры, операторы склада, менеджеры).

В-третьих, возникают смежные вопросы комплаенса. Ритейлеры обрабатывают колоссальные объемы персональных данных клиентов (программы лояльности) и сотрудников. Размещение этих данных в СУБД, входящей в реестр отечественного ПО Минцифры, упрощает соответствие требованиям 152-ФЗ. При аттестации информационных систем персональные данные (ИСПДн) использование сертифицированных российских компонентов снижает регуляторные риски и объем необходимых организационных мер защиты. Документация по настройке защищенных конфигураций доступна в базе знаний вендора и интеграторов.

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

Что делать

Если ваша розничная сеть рассматривает аналогичный сценарий отказа от западных ERP/SAP или планирует модернизацию текущего ландшафта 1С, необходим пошаговый технический план действий. Простого обновления здесь недостаточно.

1. Аудит нагрузки и профилирование текущей БД. Перед выбором редакции СУБД необходимо собрать объективные метрики. Используйте анализатор медленных запросов (pg_stat_statements в случае PostgreSQL) и отчеты технологического журнала 1С. Определите пиковые значения количества конкурентных пользователей, частоту блокировок и среднее время выполнения ключевых операций (проведение реализации, расчет себестоимости). Без этих цифр выбор между стандартной версией, сборкой от вендора или редакцией Enterprise будет гаданием.

2. Пилотирование схемы лицензирования и развертывания. Не закупайте лицензии на весь парк сразу. Разверните тестовый контур, идентичный продуктивному. Продумайте архитектуру отказоустойчивости. Для ритейла простой центрального узла недопустим.

• Рассмотрите вариант построения кластера на базе потоковой репликации с автоматическим переключением (failover). Утилиты вроде Patroni или встроенные средства менеджера кластеров позволяют минимизировать RTO (время восстановления).
• Настройте расписание резервного копирования с использованием утилиты pg_probackup, обеспечивающей инкрементальные бэкапы без остановки инстанса, что критично для систем, работающих 24/7.

3. Настройка MDM-политик для периферийных устройств. Переход бэк-офиса на новую платформу требует синхронизации настроек мобильных рабочих мест (ТСД, планшеты торговых представителей). Через ваш MDM-концентратор необходимо централизованно обновить параметры подключения.

• Создайте профиль конфигурации Wi-Fi с новым доменным суффиксом, если изменился DNS-ландшафт после ввода новых серверов 1С.
• Примените политику управляемых конфигураций (Managed Configurations) для мобильного клиента 1С. Пути могут отличаться в зависимости от приложения, но суть одна — передача URL сервера приложений, порта и параметров безопасности в виде JSON/XML payload. Например, для многих Android-клиентов используется ключ server_address.
• Убедитесь, что политики шифрования хранилища данных на устройствах (device encryption) принудительно включены (android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION должен вести на доверенный ресурс), так как мобильные сотрудники будут работать с данными из новой ERP.

4. Планирование миграции данных. Прямой перенос терабайтов данных live невозможен. Разработайте стратегию частичного (поэтапного) перевода функционала. Классический подход — запуск финансового контура и закупок в новой системе с сохранением исторической WMS или CRM до их отдельной миграции. Инструменты извлечения, преобразования и загрузки данных (ETL) должны быть протестированы на целостность ссылочных полей.

5. Обучение персонала и регламентация. Технологический стек меняется. Администраторы Windows Server/MS SQL должны пройти обучение по администрированию Linux/PostgreSQL. Необходимо разработать новые инструкции (SOP) по мониторингу состояния кластера СУБД, проверке лагов репликации и процедуре отработки аварийных ситуаций (disaster recovery drill*).

Источник: https://www.tadviser.ru/a/966644