Меню

Варианты перехода на SAP S/4HANA

|

Данная публикация является переводом статьи “Options for your SAP S/4HANA Transition”, автор – Heinrich Stroetmann, SAP Deutschland SE.

Ссылка на оригинал.

Концепция этого блога

Прочитав этот блог, вы:

  • получите представление о различных вариантах перехода на SAP S/4HANA;
  • поймете, когда применять выборочную миграцию данных в SAP S/4HANA вместо внедрения на основе существующих систем (подход Brownfield) или установки с нуля (подход Greenfield).

Структура этого блога

Этот блог разбит на следующие части:

  • Варианты перехода на SAP S/4HANA
  • Новое внедрение, или подход Greenfield
  • Выборочная миграция данных в SAP S/4HANA (SDT)
  • Создание оболочки
  • Примеры применения метода создания оболочки
  • Сценарий временных интервалов
  • Выборочная миграция кода компании
  • Сценарий адаптации и подбора
  • Комбинация
  • Заключение

Варианты перехода на SAP S/4HANA

Для перехода на локальную версию SAP S/4HANA можно использовать один из трех вариантов:

  • конверсия системы (так называемый подход Brownfield);
  • новое внедрение (так называемый подход Greennfield);
  • выборочная миграция данных в SAP S/4HANA.

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

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

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

Варианты перехода с SAP ERP на SAP S/4HANA

Ранее Амин Хок (Amin Hoque) опубликовал блог о выборочной миграции данных в SAP S/4HANA.

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

Конверсия системы или подход Brownfield

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

В случае подхода Brownfield вы преобразуете существующую систему в SAP S/4HANA при помощи инструмента Software Update Manager и в рамках локального процесса конверсии. Если вы все еще используете систему на на базе SAP HANA, вы можете объединить этот подход с переносом базы данных на SAP HANA. (Для самых ранних версий SAP S/4HANA рекомендовалось разделять процессы переноса базы данных на SAP HANA и перехода на SAP S/4HANA и проводить их в рамках разных этапов/проектов, однако эта рекомендация устарела еще несколько лет назад).

Блог с описанием шагов и подробными сведениями об этом подходе см. по адресу

https://blogs.sap.com/2020/05/27/sap-s-4hana-1909-system-conversion-steps-details-how-to-be-prepared/ 

Если у вас жесткие требования относительно времени простоя и огромные базы данных, можно объединить конверсию системы с подходом «околонулевой простой» (подход NZDT). Информацию об этом можно почитать в следующих блогах:

https://blogs.sap.com/2019/10/11/downtime-optimization-approach-lets-talk-all-about-different-zeros/
https://blogs.sap.com/2020/05/12/nzdt-downtime-approach-for-sap-s-4hana-coversion-customer-case/

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

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

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

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

Но есть один минус.

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

Конечно, можно привести множество других примеров изменений.

Эти ограничения толкают многих заказчиков к полному воспроизведению решения в рамках установки с нуля, даже если в этом нет необходимости.

В таких случаях я советую сделать следующее:

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

Проконсультируйтесь со специалистами отдела DMLT/SLO по вопросу возможности включения этих изменений в специальные пакеты конверсии, которые предлагает этот отдел и которые можно установить до или после конверсии системы в рамках самостоятельного проекта.
(Один из моих заказчиков вместе с купным партнером запустил проект установки SAP S/4HANA с нуля. Когда он понял, насколько колоссальной окажется стоимость полного повторного внедрения, он обратился к нам за консультацией. Изучив основные требования заказчика к изменениям, мы быстро поняли, что все эти изменения можно было бы внести в рамках «небольшого» 9-месячного проекта еще до конверсии системы. За счет такого поэтапного подхода заказчик сэкономил огромные средства, которые ему бы пришлось вложить в установку с нуля, заплатив вместо этого лишь малую часть этой стоимости за проект DMLT/SLO.

Вы можете обратиться непосредственно к сотрудникам отдела DMLT, чтобы узнать, можно ли внести планируемые вами изменения в рамках проекта оптимизации системного ландшафта. Отправьте письмо по адресу: sap_dmlt_gce@sap.com

Установка с нуля (подход Greenfield)

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

В отличие от конверсии системы, при установке с нуля возможен перенос только основных данных и информации по открытым позициям. Почему?

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

Серьезное преимущество SAP ERP и SAP S/4HANA — это интеграция между различными прикладными областями. Но у такой интеграции есть цена: очень сложные взаимосвязи между всеми этими разными объектами. SAP решила эту проблему за счет правильных интерфейсов для вставки или обновления сведений о бизнес-объектах. Однако, эти интерфейсы разработаны только для открытых документов, а не для архивных данных или так называемых закрытых документов.

Если вы хотите перенести архивные данные, следует не доверять эту задачу интерфейсу от SAP, а выполнить перенос самостоятельно, «на уровне таблиц», учитывая взаимосвязи между различными таблицами и объектами. Чтобы сохранить эти взаимосвязи, вам понадобятся глубокие знания и специальный инструментарий. В противном случае система может оказаться несогласованной и будет работать некорректно, а в худшем случае даже допускать ошибки в отчетах и расхождения между суммами. Впрочем, не стоит особо переживать, пример Wirecard говорит о том, что аудиторы могут их и не найти — надеюсь, вы простите мне такую шутку:-).

Отдел DMLT (также известный как SLO) разработал специальный инструментарий для миграции, позволяющий выполнять такие требующие большого мастерства задачи, но, даже несмотря на то, что этот набор инструментов был разработан примерно 25 лет назад, есть некоторые ограничения. Коротко говоря, ситуация такова: чем больше изменений мы вносим при переходе с исходной системы на целевую, тем сложнее или даже ближе к невозможному становится одновременный перенос архивных данных. Я расскажу об этом подробнее в разделе о выборочной миграции данных на SAP S/4HANA.

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

Пульт управления миграцией — это новый инструмент, созданный специально для перехода на SAP S/4HANA. Это единственный инструмент, который можно использовать также и для перехода на облачное решение SAP S/4HANA Cloud ES (essentials edition). Дополнительную информацию об этом решении и о поддерживаемых объектах см. по этим ссылкам:

https://www.sap.com/documents/2017/07/26113ac0-c47c-0010-82c7-eda71af511fa.html

https://help.sap.com/viewer/29193bf0ebdd4583930b2176cb993268/1709%20000/en-US

Информацию о доступных объектах миграции см. по ссылке

https://help.sap.com/viewer/29193bf0ebdd4583930b2176cb993268/1909.000/en-US

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

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

Последнее, но немаловажное, у некоторых из моих заказчиков были сотрудники, обладавшие опытом работы с LSMW, которые использовали этот инструмент для некоторых конкретных объектов данных.

Если вы также хотите использовать LSMW, ознакомьтесь со следующей нотой:

https://launchpad.support.sap.com/#/notes/2287723

Дополнительную информацию о доступных решениях см. в блоге Корри Брейг (Corrie Brague) и по приведенным в нем ссылкам:

https://blogs.sap.com/2020/05/14/sap-data-migration-solutions-available-to-make-a-smooth-move-to-sap-s-4hana/comment-page-1/#comment-528869

Дополнительную информацию о пульте управления миграцией можно прочитать в блогах Яцека Клатта (Jacek Klatt) и Зунаида Хингоры (Zunaid Hingora):

https://blogs.sap.com/2017/05/29/migrating-data-to-your-new-sap-s4hana/#:~:text=As%20per%20note%202287723%20%E2%80%93%20LSMW,in%20SAP%20S%2F4HANA%20anymore.

https://blogs.sap.com/2020/01/18/ltmc-s-4-hana-replacing-lsmw/

Выборочная миграция данных в SAP S/4HANA

Мотивация

Подытожим вышесказанное, отметив следующие ключевые моменты.

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

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

Войти