Почему оставаться на SAP R/3 в 2026 году — это огромный риск для бизнеса

Все еще используете SAP R/3 в 2026 году? Узнайте, почему компаниям необходимо ускорить переход на SAP S/4HANA, чтобы избежать прекращения поддержки в 2027 году.

Долгое время переход на SAP S/4HANA включали в стратегические планы и обсуждали на отраслевых конференциях, но до практической подготовки доходили немногие компании. Большинство рассматривало ее как долгосрочное обновление системы, к которому можно вернуться через несколько лет.

Сейчас откладывать переход становится все рискованнее, поскольку поддержка SAP ECC и SAP R/3 постепенно сокращается, а требования к безопасности растут. Пользовательский код устаревает, интеграции по-прежнему зависят от прежних интерфейсов. Системы могут стабильно выполнять текущие задачи, однако с каждым годом поддерживать их становится сложнее.

В статье мы разберем, с какими ограничениями сталкиваются компании, продолжающие использовать SAP R/3 в 2026 году, а также рассмотрим доступные варианты защиты данных, стабильной работы ERP-системы и ее подготовки к аналитике и решениям на базе ИИ, для которых архитектура R/3 изначально не предназначалась.

Почему SAP R/3 сегодня не помощница, а ограничение для бизнеса

То, что SAP R/3 продолжает работать без серьезных сбоев, часто служит главным аргументом в пользу ее дальнейшего использования. Однако в 2026 году при оценке ERP-системы приходится учитывать больше факторов — скорость обработки данных, сроки внедрения изменений, возможности масштабирования и другие. Архитектура R/3 негативно влияет на каждый из них.

Релиз SAP R/3 состоялся в 1992 году, и тогда компании работали с другими объемами данных и реже меняли процессы, поэтому многие операции в системе и по сей день выполняются по расписанию, а информация для отчетов готовится заранее или обрабатывается пакетами. Сейчас такой подход становится причиной задержек при получении актуальных данных.

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

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

После завершения официальной поддержки SAP R3 расходы на ее поддержку увеличились еще сильнее, поскольку компаниям необходимо платить за расширенное обслуживание или заказывать индивидуальные исправления. Чтобы сэкономить, некоторые компоненты используются без регулярных обновлений безопасности. Вдобавок ко всему специалистов, которые хорошо знают R/3, становится все меньше.

Как архитектура SAP R/3 влияет на скорость работы компании

Сначала обработка, затем анализ

SAP R/3 изначально разрабатывали как учетную систему, поэтому ее база данных надежно хранит транзакции, однако анализ этих данных выполняется позже: сначала система записывает операции, затем обрабатывает их в рамках пакетных заданий и только после этого передает результаты аналитическим инструментам.

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

Анализ данных без фоновой агрегации

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

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

Отсутствие возможностей для внедрения ИИ

Архитектура SAP R/3 ограничивает возможности внедренияискусственного интеллекта, поскольку современным ИИ-решениям нужны структурированные бизнес-объекты с едиными определениями данных и четко описанными связями, а в R/3 отсутствует семантический уровень, пригодный для такой работы.

SAP Joule и другие генеративные ИИ-сервисы используют компоненты современных SAP-сред, включая SAP HANA Cloud Vector Engine и RESTful ABAP Programming Model (RAP). SAP R/3 и SAP ECC эти технологии не поддерживают, поэтому подключить Joule к R/3 через интеграцию, репликацию или извлечение данных невозможно. Причина связана с архитектурой системы, и условия договора на использование ПО ее не устраняют. В линейке SAP только S/4HANA поддерживает их полноценное применение в рабочих процессах.

Скорость принятия решений и работа пользователей

Разница заметна и в повседневной работе. SAP GUI по-прежнему выполняет свои функции, но его интерфейс предназначен главным образом для ввода данных и обработки транзакций. SAP Fiori, встроенная аналитика и диалоговые интерфейсы S/4HANA позволяют быстрее перейти от запроса к нужной информации или действию.

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

«Серебряное цунами» и дефицит специалистов по SAP R/3

Многие системы SAP R/3 внедряли несколько десятилетий назад, после чего годами дорабатывали под процессы конкретной компании. За это время вокруг стандартной ERP появились пользовательские программы, интерфейсы и собственные структуры данных, логику которых лучше всего знают участвовавшие в разработке специалисты. Поскольку подробную документацию вели не всегда, часть информации сохранилась только в их памяти.

Теперь эти сотрудники постепенно выходят на пенсию. Массовый уход специалистов с многолетним опытом получил название «серебряное цунами», и для компаний с SAP R/3 его последствия особенно ощутимы. Вместе с сотрудником компания может потерять знания о связях между доработками, причинах прежних технических решений и возможных последствиях новых изменений.

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

Восполнить утраченные знания за счет найма тоже сложно. Специалистов по SAP R/3 становится меньше, а разработка для этой системы и постоянная работа через SAP GUI привлекают мало новых кадров. Разработчики чаще выбирают платформы с API, актуальными моделями данных и веб-интерфейсами, поскольку именно с такими технологиями связана большая часть новых SAP-проектов.

Цена ожидания: финансовые последствия откладывания перехода на S/4HANA

Чем ближе окончание поддержки устаревших систем, тем больше компаний одновременно выходят на рынок в поисках консультантов и технических специалистов. Их графики заполняются заранее, сроки запуска проектов увеличиваются, а стоимость услуг растет. Поэтому перенос миграции на 2027 год вряд ли позволит выполнить тот же объем работ на прежних условиях. В результате компаниям придется конкурировать за ограниченное число специалистов и планировать проект в период максимального спроса. По одной из оценок, из-за роста почасовых ставок и дефицита ресурсов стоимость внедрения может увеличиться на 30–50%.

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

Дополнительные возможности предлагают программы SAP. Например, RISE with SAP предусматривает разные варианты финансирования и коммерческие условия, которые могут частично сократить первоначальные расходы на переход. Доступность таких предложений зависит от выбранного решения и сроков заключения договора, поэтому раннее планирование дает компании больше вариантов при согласовании бюджета.

Зачем пересматривать ABAP-код при переходе на S/4HANA

За десятилетия работы компании создавали на ABAP собственные программы и дорабатывали стандартные функции, чтобы адаптировать систему к своим процессам. В тот момент такие решения помогали закрывать конкретные задачи, однако со временем между ними появилось множество зависимостей. И технические ограничения SAP R/3 во многом связаны именно с пользовательским кодом. 

Особенно трудно работать с так называемым spaghetti ABAP — запутанным кодом со слабой структурой и большим количеством взаимных зависимостей. Его прямой перенос сохранил бы в новой системе прежние ограничения, поэтому современные подходы к миграции предусматривают пересмотр доработок. Ключевые процессы переносят на S/4HANA, а код, который устарел или больше не используется, исключают.

Так постепенно формируется «чистое ядро» S/4HANA. В нем сохраняется бизнес-логика, необходимая компании, при этом количество устаревших доработок и зависимостей сокращается. Благодаря этому дальнейшие обновления требуют меньше времени, а влияние изменений на другие компоненты легче оценить заранее.

SAP R/3 и S/4HANA: ключевые различия

Пользовательские ABAP-доработки усложняют поддержку SAP R/3, но одной переработки кода для модернизации системы недостаточно. R/3 и S/4HANA по-разному хранят и обрабатывают данные, формируют отчетность и работают с ИИ-инструментами. Именно эти различия определяют, насколько быстро компания может получать информацию и менять свои процессы.

Как подготовиться к переходу на S/4HANA

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

Этап 1. Анализ текущей системы (4–6 недель)

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

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

Этап 2. Подготовка чистого ядра (2–3 месяца)

После аудита начинается работа с накопленными доработками. Мы сохраним бизнес-логику, которая нужна компании, и уберем устаревший код, одновременно очистив основные и транзакционные данные. Для тестирования новых решений наша команда параллельно создает отдельную среду на SAP BTP, которая будет функционировать вместе с основной системой и позволит проверить доработки без вмешательства в продуктивную среду SAP R/3. Это поможет нам обнаружить и устранить значительную часть проблем до начала миграции.

Этап 3. Реализация (6–12 месяцев)

Переход на SAP S/4HANA можно разделить на несколько последовательных запусков — это позволит не прерывать работу компании во время проекта. После каждого запуска наша команда проверяет данные и работу интеграций, а также сверяет отчетность. Такой порядок помогает сократить продолжительность простоев и снизить риск потери информации.

Этап 4. Развитие ИИ и аналитики после запуска (непрерывно)

После перехода на S/4HANA данные становятся доступны в формате, который подходит для прогнозной аналитики и SAP Joule. Финансовые, логистические и операционные подразделения могут работать с актуальной информацией без ожидания пакетной обработки и обновления отчетов.

Развитие этих возможностей продолжается и после запуска системы. Компания может постепенно подключать новые аналитические и ИИ-сценарии по мере появления задач и подготовки данных.

Не откладывайте подготовку на 2027 год

Дата окончания поддержки уже известна, и количество свободных специалистов по S/4HANA будет сокращаться по мере роста спроса. Ранний старт дает больше времени на подготовку команды и бюджета. Если отложить проект, выбирать подрядчика и согласовывать условия придется в более сжатые сроки.

LeverX сопровождает переход на S/4HANA от аудита текущей системы до запуска новой. Опыт работы с крупными SAP-системами помогает команде учитывать технические требования и регуляторные ограничения на каждом этапе миграции.

Давайте обсудим ваш проект.