Обновление SAP Solution Manager до версии 7.2 в группе компаний Северсталь

03 сентября 2018 |

В данной статье мы хотели бы поделиться опытом обновления SAP Solution Manager (далее – SolMan) на версию 7.2 в группе компаний Северсталь, где SolMan является не просто инструментом для обновления SAP-систем и поставки стандартных сервисов SAP, а одной из самых больших инсталляций, как по масштабам используемого функционала, так и по количеству пользователей, на территории региона СНГ.

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

Спецификации проекта

Обоснование проекта

Главным обоснованием проекта послужил выход из поддержки (Mainstream Maintenance) версии 7.1 с 31.12.2017г., что само по себе не очень критично, т.к. режим Extended Maintenance означает, что корпорация SAP будет исправлять ранее известные ошибки, а финансовые риски могут наступить только при обнаружении новых.

Еще одним поводом стало предложение по реализации текущих запросов на изменение на базе новой версии SAP Solution Manager, т.к. с обновлением версии ключевых компонент SAP BASIS и SAP ABAP c версии 7.02 на 7.40 возникал вопрос адаптации реализуемых изменений версии 7.1 для версии 7.2.

Краткое описание обновляемой инсталляции

Исходная версия: 7.1 SP14

Целевая версия: 7.2 SP05

Исходная\Целевая версия БД: ORACLE 11.2.0.3.0

Продуктивная эксплуатация c 2008 г. (обновление на версию 7.1 в 2013 г.)

Используемые модули: IT Service Management (ITSM), Change Request Management (ChaRM), Solution Documentation (SolDoc), Technical Monitoring (TechMon), Business Process Monitoring (BPMon), Test Management, Job Scheduling Management (JSM)

Кол-во конечных пользователей: ~15.000

Кол-во консультантов по поддержке: ~500

Кол-во управляемых систем: ~200

База обращений: ~1.000.000 (~10.000 ежемесячно)

База документов изменений: ~50.000 (~1500 ежемесячно)

График проекта

Проект содержал 3 фазы:

Дизайн (обоснование, планирование, проектирование, организация ландшафта) – июль-октябрь 2017 г.
Реализация (установка нот, тестирование и исправление ошибок, сам апгрейд) – ноябрь 2017 г. - начало марта 2018 г.
Стабилизация (эксплуатация в продуктивном режиме) – март-май 2018 г.

Greenfield vs. Brownfield

Во время обсуждения подходов по реализации данного проекта прорабатывался вариант перехода на 7.2 на базе новой инсталляции (greenfield), однако окончательный выбор был сделан в пользу апгрейда текущей инсталляции (brownfield).

За Greenfield:

Полный back-to-standard;
Экономия трудозатрат на апгрейде;
Возможность более быстрого и предсказуемого старта с параллельной эксплуатацией, где переход на версию 7.2 практически отсекался бы переключением управляемых систем на новую инсталляцию.

Против Greenfield:

Дополнительные трудозатраты на повторение базисных и прикладных настроек;
Дополнительные трудозатраты на миграцию транзакционных данных (обращения пользователей и контент по управлению документацией);
Дополнительные трудозатраты на миграцию основных данных (пользователи, роли и их присвоения, бизнес-партнеры и т.д.);
Дополнительные трудозатраты на перепроектирование и реализацию Z-разработок;
Дополнительные трудозатраты на переключение всех управляемых систем на новую инсталляцию;
Рекомендация инженеров SAP обновлять версию посредством апгрейда текущей инсталляции.

Oracle vs. SAP HANA

На момент проработки обоснования проекта обсуждался вопрос о переходе на SAP HANA. После оценки всех «за» и «против» было решено остаться на Oracle.

За SAP HANA:

Повышенная репутация проекта (в силу инновационности SAP HANA);
Потенциальное повышение производительности;
Инструментарий формирования отчетности

Против SAP HANA:

Особые требования к аппаратному обеспечению для SAP HANA;
Потенциальные риски дополнительных трудозатрат на адаптацию Z-разработок;
Потенциальные риски дополнительных трудозатрат на возможные исправления ошибок по результатам конверсии БД.

Организация двойного ландшафта

По опыту проектов c двойным ландшафтом, где Solution Manager являлся инструментом организации и синхронизации изменений между проектным ландшафтом и ландшафтом поддержки, системный ландшафт самого Solution Manager было решено организовать аналогичным образом (Рис.1.)

Рис 1. Организация системного ландшафта самого Solution Manager

Дополнительно была развернута эталонная система версии 7.2 в качестве ссылочной системы для сравнения версий стандартных объектов. Это очень помогло при анализе проблем в проектном ландшафте.

После апгрейда продуктивной системы система разработки D71 была выведена из эксплуатации; проектный ландшафт стал ландшафтом поддержки. Такой подход в нашей

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения 2

Комментарий от

Кирилл Сатарин

| 04 сентября 2018, 22:20

Сергей, спасибо за статью.

"Дополнительно была развернута эталонная система версии 7.2 в качестве ссылочной системы для сравнения версий стандартных объектов. Это очень помогло при анализе проблем в проектном ландшафте."
Я правильно понял, что у вас в системе были изменены стандартные объекты SAP? Иначе зачем эта ванильная система?

Сергей Когай

| 05 сентября 2018, 16:56

Кирилл Сатарин 04 сентября 2018, 22:20

Кирилл,
Если Вы имеете в виду модификации стандартных объектов, то их у нас совсем немного и подход к такой практике очень осторожный.
Однако, за 10 лет эксплуатации у нас накопилось достаточное количество расширений стандартного функционала (реализации BADI, явные\неявные Enhancements, копии стандартных объектов и т.д.).

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

Наверное, еще стоит еще добавить, что наличие эталонной системы нам также помогло более наглядно оценить доп. трудозатраты при рассмотрении варианта перехода на 7.2 путем новой инсталляции (Greenfield).

Обновление SAP Solution Manager до версии 7.2 в группе компаний Северсталь

Оглавление