Цифровая миграция в 2026–2030 годах: как на базе SAP построить интегрированную, расширяемую компанию с управлением на основе данных

On the way to an intelligent enterprise, organizations have to streamline multiple business processes such as improving customer experience with planning and analytics, assessing the impact of global events on their business, etc.

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

Это происходит потому, что при цифровом переходе важно заняться структурными изменениями того, как функционирует компания. К чему и стоит приступать в 2026–2030 годах.

IT‑ландшафты компаний становятся все тяжелее и сложнее в управлении: параллельно функционируют сторонние и SAP‑системы, расширяется функционал SaaS‑решений, а облачные и локальные среды работают вместе. Основная проблема состоит не только в количестве подключенных систем, а в том, как через них проходят данные.

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

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

Изменения происходят и в регуляторных нормах. Требования к приватности и безопасности ужесточаются, аудиты становятся более строгими, правила локализации данных – менее гибкими. Когда ландшафт распределен между облаком и локальными средами, к решению нужно подходить на уровне архитектуры. Именно поэтому ROI так сложно реализовать.

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

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

Проблема 1: Интеграция в гибридном и мультиоблачном ландшафте

Существует мнение, что миграция в облако снизит объем интеграционной работы. На практике компании получают более сложную архитектуру. SaaS‑решения расширились по всему бизнесу, и каждое приложение принесло свои API, свои определения данных и свои параметры процессов.

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

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

Следующая проблема: один и тот же бизнес‑объект может выглядеть по‑разному в разных системах. Данные клиентов, товары, цены, запасы, финансовые атрибуты – все это хранится и определяется по‑разному. Когда модели данных разрознены, интеграция превращается в постоянную работу по поддержанию согласованности бизнес‑логики во всем ландшафте.

Основные проблемы интеграции в корпоративных ландшафтах

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

Тогда приходится решать такие проблемы:

• Низкая прозрачность сквозных процессов, поскольку данные и события распределены между разными инструментами;
• Слабое управление, когда никто конкретно не отвечает за стандарты, API и контроль изменений;
• Рост совокупной стоимости владения, так как поддержка интеграций превращается в постоянную нагрузку;
• Медленные циклы изменений, потому что даже небольшие корректировки требуют тестирования во множестве систем и зависимостей.

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

Как SAP Business Technology Platform решает интеграционные проблемы

В активно развивающихся компаниях интеграцию необходимо рассматривать как стратегический слой, а не как набор разрозненных соединений. Именно здесь SAP Business Technology Platform (SAP BTP) играет иную роль, чем типовой набор инструментов. Она предоставляет основу для интеграции, которая масштабируется как в SAP, так и в других средах.

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

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

Интеграция как возможности для бизнеса

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

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

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

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

Проблема 2: Расширяемость без нарушения целостности ядра

Современный ERP не останавливает поток запросов на изменения. Командам по‑прежнему нужны новые шаги согласования, корректировки ценообразования, правила соответствия требованиям, партнерские процессы. Расширения — это часть ежедневной работы, с разницей в способах создания. Если все сделано правильно, ядро остается стабильным, а обновления – управляемыми. Если нет, ERP постепенно превращается в систему, которая тормозит любые изменения.

Почему кастомизация стала риском в современных ERP‑ландшафтах

В большинстве ландшафтов после миграции «чистое ядро» – не абстрактная цель, рабочий стандарт, который обеспечивает обновляемость SAP S/4HANA. Настоящая работа начинается после запуска, когда организации «очищают» ядро, сокращая объем наследственного Z‑кода и вынося пользовательскую логику за пределы ERP.

На практике «чистое ядро» поддерживается комбинацией подходов к расширяемости. Примеры из опыта разработки на SAP BTP помогают командам выстроить расширяемость, готовую к будущим обновлениям. Внешние расширения на SAP BTP используются для новых приложений, сценариев использования и межсистемной логики. Разработка внутри платформы ABAP Cloud применяется для безопасных с точки зрения обновлений, когда нужно провести работу близко к ядру.

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

Когда кастомизация находится в ядре, повторяется один и тот же сценарий:

• Обновления становятся медленными и рискованными, потому что пользовательский код создает скрытые зависимости;
• Объем тестирования растет, поскольку даже небольшие изменения могут нарушить несвязанные процессы;
• Команды откладывают улучшения, потому что вмешательство в ядро кажется небезопасным;
• Технический долг накапливается, а затраты растут незаметно.

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

Кастомизация или расширяемость

От пользовательского кода к композиционным расширениям

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

Обычно практическая модель расширяемости включает два направления:

• Расширения с минимальным объемом кода для изменений в сценариях действий, форм и легких приложений;
• Расширения на полноценном коде для сложной логики, производительных сервисов или глубоких интеграций.

Цель — сделать индивидуальную разработку управляемой, пригодной для повторных применений и безопасной для развития.

Роль SAP BTP для «чистого ядра» и инноваций

В SAP BTP возможности расширяемости позволяют создавать внешние расширения для SAP S/4HANA и RISE with SAP. Расширения на основе событий помогают сохранять чистоту ядра, минимизируя жесткую связность. Вместо того чтобы «вшивать» логику в ERP, организации могут реагировать на бизнес‑события и выполнять нестандартные шаги вне ядра.

Наглядно продемонстрировать это можно так:

• Ядро выполняет стабильные бизнес‑процессы;
• Уникальные функции и инновации создаются на базе SAP BTP;
• Интеграции и события поддерживают синхронизацию между ними.

Расширяемость как фактор, обеспечивающий гибкость бизнеса

При правильных настройках бизнес получает такие результаты:

• Быстрая реакция на изменения рынка, потому что корректировки не требуют переписывания ядра;
• Инновации без сбоев, поскольку новая логика может разрабатываться и выпускаться независимо;
• Отраслевые отличия через точечные возможности, а не глубокую кастомизацию ядра.

Расширяемость помогает двигаться быстрее, не усложняя управление ландшафтом.

Проблема 3: Превращение корпоративных данных в бизнес‑ценность

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

Почему обилие данных все еще не приносит ценности

Если проблемы только копятся, со временем они начинают блокировать более продвинутые цели.

Устаревшие хранилища данных — особенно в гибридных средах, объединяющих SAP, сторонние системы, облако и локальные среды — мешают работе с ИИ. Когда данные фрагментированы по платформам, один и тот же клиент, продукт или поставщик может существовать в нескольких версиях, определенных по‑разному и обновляемых в разное время.

Это напрямую влияет на семантическую согласованность. Если системы и модели ИИ интерпретируют один и тот же объект по‑разному, логика принятия решений становится ненадежной.

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

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

Основная проблема — отсутствие общего смысла, согласованности и скорости во всем корпоративном ландшафте.

Построение доверенного и семантически согласованного фундамента данных

Для развития компаниям необходимо настроить единую сквозную архитектуру данных, которая сохраняет контекст бизнеса при работе между системами.

В 2026–2030 годах единый источник данных означает:

• Согласованные бизнес‑определения;
• Надежные и управляемые мастер‑данные;
• Прозрачную трассировку происхождения данных;
• Семантическую согласованность между SAP и сторонними системами.

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

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

SAP HANA Cloud, SAP Datasphere и SAP Analytics Cloud

Современная SAP‑архитектура данных работает через три взаимодополняющих слоя.

Производительный слой: SAP HANA Cloud

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

Бизнес‑ориентированная сквозная архитектура данных: SAP Datasphere

SAP Datasphere устраняет разрозненность гибридных ландшафтов, формируя единую бизнес‑ориентированную архитектуру данных, которая сохраняет семантический контекст. Она позволяет предприятиям интегрировать данные из SAP и сторонних систем, при этом сохраняя семантику SAP.

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

Слой интеллектуальности: SAP Analytics Cloud

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

Вместе эти слои создают архитектуру, в которой производительность, контекст и интеллектуальность работают как единая система.

От отчетности к проактивной интеллектуальной поддержке решений

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

Такой подход строится на:

• Операционных выводах на основе данных в реальном времени;
• Планировании сценариев, позволяющем тестировать варианты до исполнения;
• Раннем выявлении рисков через предиктивные сигналы;
• Моделях ИИ, работающих на семантически согласованных данных.

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

Цель — обеспечить масштабируемые и поддерживаемые ИИ решения, основанные на гармонизированных мастер‑данных и семантическом слое SAP BTP. Это позволяет улучшать операционную деятельность, финансы, эффективность цепочек поставок и клиентские результаты в реальном времени.

SAP Business Technology Platform как основа цифровой миграции

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

SAP BTP создана, чтобы решить именно эту проблему. Не как очередной набор сервисов, а как фундаментальный слой, обеспечивающий единообразие интеграций, расширений и работы с данными во всем SAP‑ландшафте.

SAP BTP как корпоративная платформа, а не набор инструментов

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

Проще всего представить это так:

• Системы выполняют транзакции и доменные процессы;
• BTP оркестрирует системы и гармонизирует модели данных, позволяя внедрять изменения без переписывания ядра;
• Данные, автоматизация и ИИ становятся повторно используемыми возможностями, а не отдельными проектами.

Что SAP BTP меняет на практике

Как SAP BTP поддерживает сквозную миграцию

SAP BTP проводит миграцию по четырем направлениям:

• Интеграция, соединяющая SAP и сторонние системы в гибридных и мультиоблачных ландшафтах;
• Расширяемость, позволяющая создавать уникальные функции без риска для обновлений;
• Данные и аналитика, позволяющие видеть ситуацию в реальном времени, планировать и принимать решения;
• Автоматизация, оркестрирующая процессы на основе событий и согласованной бизнес‑логики.

Когда эти возможности строятся на едином фундаменте, миграция превращается в координированную программу, которую предприятие может масштабировать.

SAP BTP в контексте RISE with SAP и стратегии «чистого ядра»

В RISE with SAP «чистое ядро» — это операционный стандарт, а SAP BTP делает его устойчивым. RISE помогает компаниям двигаться к стандартизации и регулярным обновлениям. Если пользовательская логика встроена в ядро SAP S/4HANA, обновления проходят медленно и с рисками, а проведение инноваций становится невыполнимым.

После перехода на RISE with SAP платформа SAP BTP становится основным инструментом управляемых инноваций. Она предоставляет командам контролируемое пространство для расширения стабильных процессов, масштабирования продуктов на основе данных и внедрения ИИ без нарушения работы ядра S/4HANA.

Большинство компаний следуют такому сценарию:

• Сохранять SAP S/4HANA максимально близким к стандарту;
• Использовать BTP для интеграций, расширений, data‑сервисов и автоматизации;
• Позволить ядру обновляться плавно, пока инновации развиваются параллельно.

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

От проблем к структурированной дорожной карте миграции

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

Оценка текущего IT‑ландшафта и процессов

Надежная дорожная карта начинается с честной оценки текущего состояния: именно как ландшафт ведет себя на практике.

Наибольшее влияние оказывают:

• Зрелость интеграций: Оцените, как создаются и управляются интеграции. Это в основном точечные соединения или существует общий интеграционный слой с четкими стандартами, зонами ответственности и прозрачностью?
• Объем кастомизации: Определите, где живет пользовательская логика и почему. Какие кастомизации критичны, какие появились из‑за отсутствия лучшего варианта в прошлом, какие сейчас блокируют обновления или новые инициативы?
• Готовность данных: Оцените, насколько надежны и своевременны данные. Могут ли команды доверять цифрам в разных системах? Насколько быстро можно получить выводы и применить их в действиях?

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

Определение приоритетов трансформации

После базовой оценки проще расставлять приоритеты, где за основу рекомендуется брать бизнес‑результаты.

Практическая дорожная карта обычно сочетает два типа инициатив:

• Быстрые победы, которые устраняют очевидные узкие места, повышают прозрачность или сокращают ручной труд;
• Стратегические инициативы, меняющие архитектуру: внедрение централизованного интеграционного слоя, оптимизация настроек ядра, создание единой архитектуры данных.

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

Управление цифровой миграцией в масштабе

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

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

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

Как LeverX помогает компаниям преодолевать проблемы, связанные с цифровой миграцией

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

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

Архитектура прежде инструментов

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

Сквозная экспертиза SAP BTP

LeverX помогает компаниям использовать SAP Business Technology Platform как основу, а не как набор разрозненных сервисов. Это включает:

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

Цель — внедрить и использовать BTP так, чтобы снизить долгосрочную сложность.

Практические дорожные карты миграции

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

Опыт в разных отраслях и ландшафтах

LeverX обладает опытом работы в сложных корпоративных средах — гибридных ландшафтах, регулируемых отраслях и масштабных SAP‑трансформациях. Это помогает избегать типичных ошибок и ускоряет принятие решений, когда необходимо прийти к компромиссу.

От стратегии к устойчивой реализации

LeverX продолжает сопровождать клиентов после ввода в эксплуатацию, помогая укреплять систему управления, измерять прогресс с помощью четких KPI, поддерживать архитектурную согласованность по мере изменения приоритетов.

В задачи LeverX входит создание фундамента, который адаптируется к изменениям, а не вынуждает компанию начинать все заново.

Заключение

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

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

В этом контексте SAP BTP — не просто инструмент, а основа. Платформа объединяет системы, помогает сохранить «чистое ядро», обеспечивает безопасное расширение решений и превращает данные в реальный стратегический актив. Благодаря этому компании могут расти, внедрять инновации и двигаться вперед без необходимости каждые несколько лет заново перестраивать весь IT-ландшафт.

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