После ухода SAP с российского рынка перед компаниями встал вполне прагматичный вопрос: что делать с уже внедренными системами. Ожидания были понятны — быстрый переход на альтернативы, постепенный отказ от SAP. Но прошло почти четыре года, и реальность оказалась куда более сдержанной: массового перехода не случилось, и SAP по-прежнему остается ядром ключевых бизнес-процессов во многих компаниях.
Это означает только одно — вопрос поддержки никуда не делся, более того, с каждым годом он становится все острее. Если в функциональной части специалистов на рынке еще достаточно, то в технической, базисной поддержке постепенно формируется дефицит, и именно эта часть сегодня начинает напрямую влиять на устойчивость системы.
На первый взгляд все может выглядеть стабильно: пользователи работают, процессы идут, финансовые периоды закрываются, зарплата начисляется, товары отгружаются, закупки осуществляются — система жива. Но проблема SAP сегодня в том, что риски накапливаются не сразу, а постепенно, и часто остаются незаметными до первого серьезного сбоя. Это создает опасную иллюзию: кажется, что система работает нормально, хотя внутри уже формируется набор уязвимостей и ограничений, которые в какой-то момент проявятся одновременно.
Факторы, которые формируют риски
Один из ключевых факторов — безопасность. SAP продолжает выявлять уязвимости как в HANA, так и в ABAP-коде, и даже изолированные системы не защищены полностью: внутренние утечки и атаки остаются реальной угрозой.
Второй фактор — обновления. Патчи продолжают выходить, но их получение и применение становятся отдельной нетривиальной и часто трудозатратной задачей, которую откладывают, чтобы не трогать «работающую» систему или из-за наличия более приоритетных задач. В результате в ней постепенно накапливаются слабые места.
Третий фактор — технический долг. Большинство SAP-систем развивались годами, и сегодня это сложные архитектуры с высоким уровнем интеграции и большим количеством взаимосвязей, где любое изменение может повлиять на десятки процессов и требует крайне трудозатратного тестирования.
Отдельную нагрузку создают регулярные изменения в законодательстве. Если раньше значительную часть требований закрывал вендор, сейчас компании вынуждены самостоятельно адаптировать системы, что требует дополнительных ресурсов и повышает риск ошибок.
На этом фоне многие компании начали оптимизировать расходы на поддержку SAP. Это выглядит логично, но на практике часто приводит к обратному эффекту: экономия увеличивает вероятность инцидентов. А любой серьезный сбой — это уже не локальная ИТ-проблема, а остановка бизнес-процессов с прямыми финансовыми последствиями.
В этих условиях подход «и так работает» становится все более рискованным, потому что речь идет не о текущем состоянии системы, а о том, насколько она готова к следующему инциденту.
Главный риск сегодня заключается не в том, что система перестанет работать, а в том, что она продолжит работать до момента, когда сбой окажется критическим.
Какие стратегии выбирают компании
После ухода SAP компании оказались в ситуации, где необходимо определить дальнейший путь: развивать систему, замораживать ее или постепенно заменять. Со временем стало понятно, что универсального решения нет, и каждая компания выстраивает свою стратегию в зависимости от бизнес-задач, ресурсов и уровня зрелости внутренней ИТ-организации. Тем не менее на практике сформировалось несколько типовых сценариев.
● Развитие. Несмотря на ограничения, многие компании продолжают дорабатывать систему, поскольку она глубоко интегрирована в бизнес-процессы, а полноценной замены часто нет. Однако здесь быстро возникает ограничение по ресурсам: внутренние команды перегружены, часть специалистов переключается на другие задачи, а объем работ, включая требования законодательства, только увеличивается. В результате развитие замедляется или почти останавливается, а технический долг продолжает расти.
● Удержание и оптимизация. В этом случае компании стараются не расширять систему, а максимально продлить срок ее жизни, контролируя расходы и инфраструктуру. На первый план выходят задачи, которые раньше воспринимались как второстепенные: управление объемом данных, архивирование и оптимизация производительности. При этом именно здесь часто скрывается значительный потенциал: грамотная работа с данными и использованием ресурсов позволяет снизить нагрузку на систему, сократить затраты и ускорить выполнение операций.
● Гибридная модель. Система остается ядром, но окружение постепенно заменяется: интеграционные решения, аналитика, отдельные функциональные блоки. Это позволяет снизить зависимость без резких изменений, но требует аккуратной работы с архитектурой и глубокого понимания всех взаимосвязей. При переходе к такой модели возникает ряд вопросов, не всегда очевидных на этапе планирования. Замена отдельных компонентов приводит к необходимости заново оценивать поведение всей архитектуры в условиях реальной нагрузки.
Ключевой риск связан не столько с функциональностью новых решений, сколько с их работой в составе существующего ИТ-ландшафта. Выдержит ли новая система прежний объем операций? Как изменится время отклика? Как поведут себя смежные системы при одновременной нагрузке?
В таких условиях снова становится актуальной практика комплексного нагрузочного и интеграционного тестирования с фокусом на сквозные процессы. Это позволяет воспроизвести реальные сценарии, оценить влияние каждого компонента и выявить узкие места до того, как они проявятся в эксплуатации.
Отдельно стоит отметить, что независимо от выбранной стратегии, большинство компаний сталкивается с одной и той же проблемой — нехваткой опыта. Внутренние команды хорошо знают свою систему, но редко сталкиваются с большим количеством различных сценариев и инцидентов.
При этом именно опыт и накопленная практика позволяют не только реагировать на проблемы, но и заранее выявлять их предпосылки, корректно оценивать поведение системы под нагрузкой и принимать решения без дополнительных рисков для бизнеса.
Одна из самых распространенных ошибок — воспринимать поддержку лишь как процесс «закрытия заявок». В текущих условиях это уже полноценный инструмент управления рисками, от которого напрямую зависит стабильность бизнеса.
Устойчивость системы определяется не столько выбранной стратегией, сколько глубиной экспертизы и способностью работать с ней в условиях постоянных изменений.
Когда система работает на пределе
Поддержка обычно воспринимается как стабильный процесс до тех пор, пока система не начинает работать на пределе. Именно в такие моменты становится видно, насколько критична способность быстро находить первопричины проблем, а не просто реагировать на их внешние проявления.
На практике проблемы редко выглядят как классические аварии. Чаще это накопленные перегрузки, деградация производительности или сбои в отдельных бизнес-процессах, которые постепенно приводят к остановке системы.
Несмотря на различный характер таких ситуаций — повышенное потребление ресурсов, снижение производительности или сбои в процессах, все они сводятся к одному фактору. Решающее значение имеет не тип инцидента, а способность быстро проанализировать поведение системы, выявить первопричину и устранить ее без дополнительных рисков для бизнеса.
Именно здесь ключевую роль играет опыт работы с критическими системами, знание архитектуры и практика решения нестандартных задач в условиях ограниченного времени.
Поддержка как элемент устойчивости бизнеса
Сегодня поддержка — это уже не вспомогательный сервис, а инструмент обеспечения стабильности бизнеса на горизонте ближайших лет. Пока компании находятся в процессе выбора долгосрочной стратегии развития ИТ-ландшафта, система должна оставаться работоспособной и предсказуемой.
Поэтому ключевой задачей становится не только реакция на инциденты, но и их предотвращение через анализ текущего состояния системы.
