Эксперт по сопровождению технической инфраструктуру SAP рассказывает о реальном опыте перехода крупных предприятий на новую систему и самых частых ошибках компаний.
Переход на новое поколение корпоративной системы управления бизнесом SAP S/4HANA остается одним из самых масштабных ИТ-проектов. Согласно исследованию сообщества SAPinsider, к началу 2025 года около трети организаций уже завершили переход на новую платформу. Одновременно российский рынок движется своим путем: большинство предприятий не отказываются от SAP полностью, а модернизируют существующие системы и постепенно перестраивают ИТ-ландшафт.
По мнению Александра Семенкова, ведущего эксперта по сопровождению технической инфраструктуры SAP в одной из крупнейших российских ИТ-компаний, сегодня главная сложность для бизнеса заключается уже не в самом переходе на новую платформу управления корпоративными данными, а в последующей эксплуатации системы. По опыту эксперта основная работа по оптимизации, сопровождению и развитию платформы начинается уже после запуска системы. Александр уже более девяти лет занимается сопровождением и развитием корпоративной SAP-инфраструктуры крупных предприятий. В его практике — внедрение решений для мониторинга и обеспечения отказоустойчивости корпоративных систем, а также модернизация инфраструктуры, от стабильной работы которой зависят тысячи сотрудников и ключевые бизнес-процессы компаний.
В интервью itWeek Александр Семенков рассказал, насколько ожидания бизнеса от перехода на SAP HANA совпали с реальными результатами, какие ошибки компании чаще всего допускают при подготовке к миграции, почему производительность зависит не только от новой платформы, но и от качества существующего кода, а также что необходимо предусмотреть еще на этапе проектирования.
Александр, стандартная поддержка SAP ECC 6.0 завершится в конце 2027 года, и многие компании уже планируют дальнейшие шаги. Означает ли это, что всем пользователям SAP придется переходить на SAP S/4HANA, или у бизнеса есть другие варианты?
На самом деле у компаний есть три возможных сценария. Сам разработчик рекомендует перейти на SAP S/4HANA, поскольку новая платформа будет развиваться и получать все обновления, включая исправления безопасности и новые функции.
Также возможно остаться на прежней версии SAP и оформить расширенную платную поддержку, которая позволит продолжить использовать систему до конца 2030 года и получать необходимые обновления. Для некоторых компаний это возможность выиграть время и лучше подготовиться к масштабному проекту миграции.
Третий путь — продолжить работать на SAP ECC без официальной поддержки. Формально это возможно, но такой вариант связан с серьезными рисками. После окончания поддержки компания перестает получать обновления безопасности, исправления ошибок и изменения, связанные с требованиями законодательства. Кроме того, со временем становится сложнее сопровождать систему и поддерживать ее в актуальном состоянии.
Если сравнить ожидания бизнеса от перехода на SAP HANA и результаты, которые компании получили спустя несколько лет эксплуатации, насколько они совпали?
На мой взгляд ожидания совпали с реальностью, ведь в результате перехода на SAP HANA бизнес получил решение с большей производительностью, оптимизированное под управление крупным бизнесом. За последние годы вокруг SAP HANA сформировалась зрелая экспертиза: появились отработанные подходы к внедрению, эксплуатации и решению возникающих технических задач. Поэтому сегодня сопровождение таких систем стало гораздо более предсказуемым, чем несколько лет назад.
Можете привести пример из вашей практики, каких результатов удалось добиться при переносе крупной корпоративной системы на новую платформу?
Я участвовал в проекте по миграции на SAP HANA, где в системе работало свыше двух тысяч сотрудников. В ходе проекта было перенесено
Если говорить о крупных предприятиях, то что становится главным аргументом в пользу перехода на SAP HANA?
Для большинства компаний главным аргументом всегда была производительность. После перехода корпоративные системы начинают работать значительно быстрее: ускоряется выполнение бизнес-операций, быстрее формируются отчеты, пользователи меньше времени тратят на ожидание результатов. Но дело не только в скорости. Переход на SAP HANA открывает больше возможностей для развития самой инфраструктуры: становится проще реализовать отказоустойчивость, резервирование данных и масштабирование системы по мере роста бизнеса.
Еще один важный фактор — жизненный цикл продукта. Многие компании переходили на SAP HANA, понимая, что прежние версии платформы постепенно перестают поддерживаться, а дальнейшее развитие корпоративных систем будет связано уже с новым поколением решений.
При этом не все ожидания бизнеса оправдываются автоматически. Распространенное заблуждение заключается в том, что после миграции система сразу начинает работать идеально и больше не требует доработок. На практике это не так. Во многих компаниях за годы эксплуатации накапливаются собственные разработки, созданные под старую архитектуру. После перехода на новую платформу их часто приходится оптимизировать заново, иначе они не смогут полностью использовать возможности SAP HANA. Поэтому миграция — это не финальная точка проекта, а начало нового этапа развития корпоративной системы.
У вас есть опыт перевода корпоративной инфраструктуры с платформы IBM PowerPC и базы данных IBM DB2 на SAP HANA. Какие требования новая платформа предъявляет к инфраструктуре?
Главное отличие SAP HANA заключается в том, что эта платформа хранит и обрабатывает данные в оперативной памяти. За счет этого она обеспечивает очень высокую производительность, но одновременно предъявляет гораздо более серьезные требования к оборудованию. В первую очередь это касается объема оперативной памяти, а значит, и стоимости всей инфраструктуры.
По мере роста бизнеса увеличивается и объем данных. Если заранее не продумать, как ими управлять, расходы на поддержку системы начинают быстро расти. Поэтому компании заранее выстраивают стратегию хранения информации: архивируют устаревшие данные, выносят редко используемые документы в отдельные хранилища и оставляют в рабочей базе только то, что действительно необходимо для повседневной работы. Такой подход помогает сохранить высокую производительность без постоянного увеличения вычислительных ресурсов.
Вы разработали собственный подход к управлению данными и архивированию в высоконагруженных системах. Какие ошибки компании чаще всего допускают еще на этапе подготовки к миграции?
Одна из самых распространенных ошибок — это неверная оценка того, как будут расти объемы данных. Компания рассчитывает инфраструктуру с запасом на пять или даже десять лет, но уже через два-три года выясняется, что ресурсов не хватает. Бизнес развивается быстрее, появляются новые сервисы, увеличивается количество пользователей, и первоначальные расчеты перестают соответствовать реальности.
Очень важно заранее предусмотреть возможность масштабирования системы, резервного копирования и отказоустойчивости. На этапе проектирования эти вопросы часто кажутся второстепенными, но именно они определяют, насколько легко инфраструктура сможет развиваться в будущем. Если не заложить такие возможности сразу, позже модернизация потребует гораздо больше времени, денег и усилий со стороны технических специалистов.
Вы участвовали в масштабной модернизации корпоративной ИТ-инфраструктуры: переносили более 40 серверов и переводили SAP-системы с устаревших аппаратных платформ. Что оказывается самым сложным: сам перенос системы или обеспечение ее стабильной работы после запуска?
Самым сложным этапом остается именно подготовка и проведение миграции. Такие задачи требуют детальной проработки архитектуры, большого количества предварительных проверок и тщательного планирования. В зависимости от масштаба предприятия они могут занимать год и более. При этом важно не только перенести систему, но и сделать это с минимальным влиянием на бизнес.
Например, при реализации переноса более 40 серверов с платформы IBM на новое оборудование простой отдельных систем удалось ограничить несколькими часами. Для крупных предприятий, где ИТ-системы поддерживают непрерывные бизнес-процессы, это принципиально важный показатель.
После запуска новой платформы тоже возникают задачи, но они уже связаны с развитием и сопровождением системы. Если архитектура была продумана заранее и в проект изначально заложены возможности масштабирования, резервирования и дальнейшего роста, эксплуатация проходит значительно спокойнее. Именно поэтому успех подобных проектов во многом определяется качеством подготовки, а не только самой миграцией.
Если бы сегодня компания только начинала переход на SAP HANA, какой совет вы дали бы, опираясь на опыт реализации крупных инфраструктурных проектов?
Самое важное — не экономить время на подготовке. Практика показывает, что большинство проблем, с которыми компании сталкиваются после запуска новой системы, возникают именно потому, что какие-то вопросы были недостаточно подробно проработаны в начале проекта.
Я бы рекомендовал сразу смотреть на несколько лет вперед. Нужно понимать, как будет расти объем данных, какие новые системы могут появиться в компании и насколько легко инфраструктуру можно будет расширить. До начала миграции полезно провести ревизию данных: удалить или архивировать то, что уже не используется. Это сокращает время переноса и снижает требования к новой инфраструктуре.
Еще один обязательный этап — тестовые переходы. Они помогают заранее оценить продолжительность работ, выявить потенциальные риски и избежать неприятных сюрпризов в день запуска. И, конечно, нельзя недооценивать резервное копирование. Оно должно быть продумано как во время самого перехода, так и после ввода системы в эксплуатацию. Именно такие детали во многом определяют, насколько успешным окажется весь проект.
