← Предыдущая статья

Производительность в ERP — тема, с которой легко сорваться в маркетинговый экстаз.

«Прошли тест».
«Ускорили расчет».
«Выдержали нагрузку».
«Теперь работает быстрее».

Все это звучит хорошо. Иногда даже слишком хорошо.

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

На сессии «Перспективы развития ERP+ в партнерстве с ключевыми клиентами» производительность звучала не как праздный показатель, а как суровое испытание. И это хороший знак. Когда платформа взрослеет, разговор о ней начинает уходить от «она умеет» к «она выдерживает».

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

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

Факты

По итогам АКПО-Конф 2026

В сессии про развитие ERP+ производительность не висела отдельно, как технический бантик на продуктовой елке.

Крупный промышленный заказчик говорил о переходе корпоративных систем на Linux и PostgreSQL-подобную СУБД. Сам переход еще не доказывает зрелость платформы: система может запуститься, но это только первое знакомство. Дальше начинаются вопросы, ради которых и существуют производственные контуры: как она считает, сколько времени занимает тяжелая операция, укладывается ли расчет в окно, которое устраивает финансовую функцию.

В этом опыте важны две детали.

Первая — масштаб перехода. По словам участника дискуссии, за последние годы значительная часть корпоративных систем уже переведена на Linux и PostgreSQL-подобную СУБД, а в 2026 году этот процесс должен завершаться.

Вторая — не сама миграция, а проверка тяжелыми расчетами. Один из примеров — расчет себестоимости. Раньше часть таких расчетов выполнялась слишком долго. После доработок механизма записи в регистры время удалось существенно сократить и попасть в окно, приемлемое для финансистов. Это уже не «ускорили что-то где-то». Это понятная проектная проверка: был тяжелый расчет, было ограничение по времени, была доработка, появился значимый результат.

Финансовый заказчик добавил к этой картине свою историю с нагрузкой. Там другой профиль: единое юридическое лицо, крупный централизованный контур, ежедневная онлайн-работа, большие объемы операций и жесткие требования к устойчивости. В обсуждении прозвучал пример порядка 30 тысяч платежей в день. Для ERP это уже не красивая демонстрация, а жизнь в потоке: платежи, пользователи, регламентные процессы, устойчивость, обновления и требования к непрерывности складываются в один узел.

Особенно ценна была история с неудачным первым тестом. Решение по одному из направлений не прошло проверку производительности сразу. Затем были доработки, повторный просмотр решений на рынке, новый тест — и после этого 1С была выбрана по соответствующему направлению. В такой истории нет привычной лакировки «просто у нас все получилось». Зато есть то, что часто важнее: слабое место нашли, доработали, снова проверили и только потом сделали вывод.

Представители 1С отдельно говорили о постоянной оптимизации производительности в новых версиях ERP. За словами вроде «рефакторинг» и «обработка данных» стоит не самая эффектная, но важная работа: пользователю не показывают новую форму под красивым маркетинговым соусом, зато система быстрее считает, обрабатывает, пересчитывает и меньше мешает жить тем, кто в ней работает. В ERP это часто ценнее, чем еще одно торжественное перерезание ленточки.

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

Это не свидетельствует, что любая ERP-система в любом контуре уже выдержит любую нагрузку. Но свидетельствует о другом: разговор о зрелости ERP на российских проектах стал более предметным. Уже недостаточно сказать «у нас есть функционал». Нужно показать, как этот функционал ведет себя под нагрузкой.

Что видно по российским проектам

Российская специфика здесь проста и неприятна: многие компании одновременно меняют платформу, стек, СУБД, операционную систему, интеграции, инфраструктуру сопровождения и привычные регламентные процедуры. В таких условиях производительность нельзя проверять «в целом». Ее приходится проверять на отдельных операциях.

Открытые источники показывают, что тема уже вышла за пределы разговоров в зале. В январе 2025 года CNews писал о тесте «1С:ERP» на Linux с 15 тысячами одновременно работающих пользователей в одной базе; ранее 1С сообщала об успешном нагрузочном тестировании «1С:ERP Управление предприятием» на 12 тысяч одновременно работающих с единой базой пользователей на PostgreSQL и Linux (CNews, «1С» успешно испытала замену SAP на Linux на 15 тыс. одновременно работающих пользователей; 1С:Консалтинг, Успешный тест 1С:ERP на 12 000 одновременно работающих с единой базой пользователей).

Такой тест не дает индульгенцию на все случаи жизни. Он не доказывает, что каждый продуктивный контур выдержит любую нагрузку. Но он меняет язык разговора. Вместо «верим, что выдержит» появляется цепочка нормальных вопросов: какой профиль нагрузки, какой стек, какие операции, какое время отклика, какие ограничения, что считали, что не считали, что будет при сбое?

Другой открытый вопрос — СУБД и закрытие месяца. Postgres Pro в материалах по Enterprise-версии для 1С отдельно указывает сценарии повышения производительности для 1С, включая тест «Закрытие месяца», где время закрытия сократилось с 4 часов до 20 минут. В программе PGConf.Russia тема долгого закрытия месяца и расчета себестоимости на PostgreSQL описывалась как давняя боль, а доклад был посвящен способам сделать закрытие месяца в 1С быстрым и незаметным для текущей работы пользователей (Postgres Pro, Postgres Pro Enterprise для 1С; PGConf.Russia, Закрывай месяц в 1С ERP на PostgreSQL быстро и незаметно).

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

Что подсказывает опыт SAP

Опыт SAP здесь полезен не в качестве мерки для российских ERP-платформ. Он полезен как напоминание: в больших корпоративных системах производительность давно нельзя обсуждать одной фразой «работает быстро».

SAP Standard Application Benchmarks предназначены для проверки производительности аппаратного обеспечения и баз данных для SAP-приложений и компонентов. SAP также использует аппаратно-независимые единицы измерения производительности, например aSAPS, чтобы описывать производительность конфигурации в SAP-среде (SAP, About SAP Standard Application Benchmarks).

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

Поэтому SAP-фон здесь нужен не для сравнения «кто лучше». Он нужен в качестве ориентира для дисциплины мышления: производительность ERP нельзя оценивать одной цифрой. Ее нужно раскладывать на операции, сценарии, пики, окна и последствия задержки.

Редакционное наблюдение

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

Промышленный заказчик проверяет расчеты себестоимости и окно, приемлемое для финансовой функции.
Финансовый заказчик проверяет платежи, онлайн-работу, большой контур и повторный тест после доработок.
Вендор проверяет, может ли платформа ускоряться не только за счет новой функции, но и за счет скучного, трудного, почти невидимого технического развития.
Российский рынок проверяет связку ERP, Linux, PostgreSQL и отечественного стека.
SAP-опыт напоминает: без расчета требуемой мощности, тестов и сценариев нагрузки корпоративные ERP быстро превращаются в символ веры.

Все это разные стороны одного сигнала.

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

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

Попытка объяснения

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

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

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

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

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

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

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

Гипотеза

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

Не «быстро работает».
А что именно быстро работает?

Закрытие месяца?
Расчет себестоимости?
Массовые платежи?
Планирование производства?
Регламентные задания?
Интерфейсные обмены?
Отчеты?
Миграционные процедуры?
Пиковые пользовательские сценарии?

И еще важнее: что происходит, если все это накладывается друг на друга?

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

А на какой операции ваша система проходит проверку на зрелость: закрытие периода, расчет себестоимости, платежи, регламентные задания, отчеты, интеграционные пики, массовая работа пользователей или что-то еще? Как вы понимаете, что система действительно выдержала нагрузку: по времени выполнения, стабильности, числу инцидентов, реакции бизнеса, SLA или другому показателю?

Пишите на y.nechitaylov@sappro.ru, в комментариях к соответствующим постам в сообществе в ВК или в комментариях под этими материалами на sappro.ru.

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

Автор

Юрий Нечитайлов, главный редактор SAP Professional Journal Россия