* Данная публикация является переводом статьи “Options for your SAP S/4HANA Transition”, автор – heinrich.stroetmann, SAP Deutschland SE
Ссылка на оригинал
Прочитав этот блог, вы:
Этот блог разбит на следующие части:
Для перехода на локальную версию SAP S/4HANA можно использовать один из трех вариантов:
Для начала кратко напомню, что представляют конверсия и внедрение с нуля, чтобы обосновать необходимость применения выборочной миграции данных в SAP S/4HANA.
На рисунке ниже схематично и обобщенно представлены разные подходы:
Если вы хотите сохранить все данные и вновь использовать текущие процессы, то вы, скорее всего, прибегните к преобразованию системы. Но если существует необходимость в полном перепроектировании процессов правильным решением станет внедрение с нуля. Однако в этом случае вы не сможете перенести данные из своей старой системы.
Поскольку зачастую заказчикам требуется больше вариантов, а не только эти два, был разработан метод выборочной миграции данных в SAP S/4HANA. Он позволяет обеспечить возможность возврата к старым процессам не только в масштабе всей системы, но и отдельно по разным решениям или приложениям.
Ранее Амин Хок (Amin Hoque) опубликовал блог о выборочной миграции данных в SAP S/4HANA.
Амин рассматривает в основном разные этапы проекта, я же хочу более подробно коснуться технических и практических аспектов выборочной миграции данных в SAP S/4HANA. Я расскажу о различных методах выборочной миграции данных в SAP S/4HANA и продемонстрирую, как сделать подход, основанный на преобразовании существующих систем, более гибким.
Основная идея этого подхода состоит в том, что, начиная работать с новой системой 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
Поскольку подход, предполагающий установку с нуля, хорошо известен большинству наших заказчиков, я буду очень краток и коснусь только одного аспекта процесса переноса данных при таком сценарии. Такое упоминание пригодиться, когда я буду приводить описание и мотивацию для выборочной миграции данных на 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...
Дополнительную информацию о пульте управления миграцией можно прочитать в блогах Яцека Клатта (Jacek Klatt) и Зунаида Хингоры (Zunaid Hingora):
https://blogs.sap.com/2017/05/29/migrating-data-to-your-new-sap-s4hana/#:~:text=As%20per%20note%2022....
https://blogs.sap.com/2020/01/18/ltmc-s-4-hana-replacing-lsmw/
Подытожим вышесказанное, отметив следующие ключевые моменты.
Установка с нуля зачастую становится самым сложным вариантом перехода на SAP S/4HANA. Кроме того, при этом подходе невозможна миграция архивных данных.
Конверсия системы представляет собой гораздо более простой и понятный проект, но лишает вас гибкости в том, что касается переконструирования существующих процессов.
Поэтому в качестве альтернативы разработан вариант перехода с выборочной миграцией данных на SAP S/4HANA. Выборочную миграцию данных включает два метода:
Рассмотрим оба метода
Основная идея подхода с выборочной миграцией данных заключается в том, чтобы запустить в работу новое решение SAP S/4HANA на основе существующего ERP-решения SAP, но при этом получить больше гибкости для внесения изменений, чем в случае конверсии системы.
Как этого добиться?
Основные принципы этого подхода очевидны.
Мы начинаем с создания оболочки существующего ERP-решения SAP, что дает нам пустую систему, содержащую только конфигурацию без каких-либо переменных и основных данных (шаг 1 в нижеприведенной диаграмме). Наличие конфигурации означает, что системе есть пользовательские настройки и объекты репозитория, и ничего больше . Эта система будет преобразована в SAP S/4HANA в порядке обычной конверсии системы (шаг 2).
Поскольку в ней нет данных, вы можете внести любые необходимые изменения в конфигурацию своей новой пустой системы SAP S/4HANA. Например, вы можете скорректировать финансовую модель или задать настройки контроллинга с учетом будущих требований. Тем самым вы создадите свою идеальную систему, которая станет отправной точкой для решения SAP S/4HANA (шаг 3).
Вы копируете ее, чтобы создать целевую систему (шаг 4).
Следующим шагом должна стать миграция данных (шаг 5). Во всех областях, к которым вы не применяли затрагивающих основные параметры изменений, будет также можно перенести архивные данные и менять их в процессе перехода на новые структуры SAP S/4HANA. В этих областях миграция данных осуществляется на уровне таблиц, и необходимые для SAP S/4HANA изменения «на лету» выполняются в специальных «разгонных» программах, которые идентичны или похожи на программы, используемых при обычном преобразовании системы в SAP S/4HANA.
Что касается тех областей, в которых вам нужно внести основополагающие изменения, используются другие методы миграции, предусматривающие добавление данных в безопасном режиме посредством системных интерфейсов, поэтому невозможно будет разместить никаких архивных документов, содержащих такие данные. Однако, если, например, в модуль логистики требуется внести лишь несколько изменений, а в модуль финансов — принципиальные изменения, то вы сможете перенести архивные документы в модуль логистики, но не сможете сделать это для модуля финансов.
В этом случае все равно можно будет связать документ логистики с соотносящимся с ним открытым финансовым документом.
Сценарий временных интервалов
Это один из наиболее широко используемых сценариев. Представим, что у вас в системе данные за 10 лет, но при текущих рабочих процессах вам могут понадобиться данные только за последние два года. Поэтому при переходе на SAP S/4HANA вы хотите полностью удалить данные более ранних периодов. Выборочная миграция данных в SAP S/4HANA — это идеальное решение для такой задачи! Вам не требуется переконструирование существующего решения, вы можете просто воспользоваться гибкостью, предоставляемой при выборочной миграции данных, чтобы избавиться от старых данных. Если вы хотите сохранить данные прошлых периодов для аудиторов, то рассмотрите возможность применения решения SAP Information Lifecycle Management.
Если вы переносите в SAP S/4HANA не все коды компаний сразу, а только один или некоторые из них, то этот сценарий для вас. Конечно, его также можно сочетать со сценарием временных интервалов.
Выборочная миграция кода компании используется, например, в сценариях комбинации или в случае масштабных проектов, когда этот сценарий позволяет разбить переход на SAP S/4HANA на несколько этапов. Используя сценарий временных интервалов, нельзя недооценивать объем работ, которые потребуются для создания временных интерфейсов, если одни компании частично уже используют SAP S/4HANA, а другие все еще работают с ERP-системой SAP.
Конечно, в реальной жизни все может быть намного сложнее, и вам потребуется сочетать сценарии временных интервалов и выборочной миграции. Кроме того, критерии отбора элементов организационных единиц могут быть гораздо более сложными, нежели просто использование полных кодов компании.
Учитывая это, для выборочной миграции данных был разработан механизм оценки объема данных (Data Scope Engine). Дополнительную информацию об этом см. в блоге моего коллеги Матиас Стегмюллер (Matthias Stegmüller):
https://blogs.sap.com/2020/09/23/data-scope-engine-identify-relevant-data-for-sap-s-4hana-transition...
Это наиболее широко используемый сценарий выборочной миграции данных. Здесь вам потребуется внести в определенные части системы изменения, которые невозможны во время конверсии системы.
Например, у меня достаточно клиентов, которые все еще используют классическую главную книгу с параллельными счетами и которые хотят перейти на решение с параллельными регистрами, а также, например, внедрить решение для разделения документа. Но при этом в область логистики существующего решения не требуется вносить никаких изменений.
В случае выборочной миграции данных эту задачу можно решить довольно просто:
данные логистики можно перенести полностью вместе с архивными данными, но в области финансов возможен перенос только открытых позиций и основных данных.
Примечание. Даже в этом случае подход с выборочной миграцией данных включает решения, позволяющие перенести архивные финансовые данные, но следует помнить, что это совсем не просто и это нельзя сделать исключительно при помощи инструментов; помимо технического решения для выборочной миграции данных потребуются высококлассные профессионалы-финансисты, которые действительно знают, что делают. Лично я в таких случаях советую подбирать для этой задачи консультантов с большим опытом в области миграции архивных данных на уровне таблиц.
Такой совет объясняется следующим.
SAP все еще не объявила, когда переход с модели параллельных счетов на модель параллельных регистров будет включен в стандартный объем решения SAP S/4HANA. Поскольку довольно много заказчиков заинтересованы в этом решении, на то есть причина:
это не тривиальная задача, и сложно создать законченное решение, учитывающее каждую возможную ситуацию, а значит, можно ожидать, что в каждом отдельном проекте решение нужно будет подогнать под обстоятельства заказчика, чтобы оно работало без нареканий
Если выборочная миграция данных — это способ сделать конверсию системы более гибкой, то комбинация позволяет при установке с нуля сохранить и обезопасить те компоненты конфигурации, которые не нуждаются в изменениях.
В отличии от метода создания оболочки, комбинация применяется гораздо реже. Однако здесь мои наблюдения не совсем объективны, и позже я объясню почему.
Основная идея комбинации заключается в том, чтобы применить подход установки с нуля, но при этом сохранить определенные области существующего решения SAP ERP, которые, как оказалось, вполне соответствуют будущим потребностям клиента.
Поскольку вы хотите сохранить некоторые области существующего решения, вам следует сначала четко определить их. (Помните, что даже сегодня, при наличии Agile, одной из основных причин перерасхода бюджета или полного срыва проекта является нечетко установленный или постоянно нарастающий объем работ).
Определив области решения, которые вы хотите перенести в новую систему SAP S/4HANA, необходимо решить, как это сделать.
Есть два возможных пути:
Особенности первого варианта
Потребуются опытные консультанты, которые вручную настроят решение в целевой системе.
Особенности второго варианта
Вариант а): если при переходе от SAP ERP к SAP S/4HANA изменения отсутствуют или являются незначительными, вы можете перенести пользовательские настройки из SAP ERP в SAP S/4HANA напрямую и вручную переделать кастомизацию в целевой системе.
Вариант b): если изменения при переходе от SAP ERP к SAP S/4HANA являются существенными, вы можете создать оболочку своей системы SAP ERP и преобразовать ее в SAP S/4HANA.
Теперь у вас есть основа для переноса решения в новую систему SAP S/4HANA.
Кроме того, в этом случае вы будете вручную переделывать и адаптировать перенесенные элементы в решении SAP S/4HANA.
Есть особый метод, позволяющий тщательно отбирать элементы пользовательских настроек и переносить их с помощью специального набора инструментов. Точкой отсчета при такой миграции может быть система SAP ERP и (или) SAP S/4HANA. Однако, это только полуавтоматическое решение, поскольку вам придется вручную проверять соответствие и правильность интеграции перенесенных элементов в целевую систему. Если вас заинтересовала услуга, в рамках которой предоставляется такое решение, обратитесь по адресу sapmcd@sap.com. Это решение создано на базе решения MCDelta, которое также используется для сравнительного анализа систем и при использовании варианта Central Finance.
Эту услугу оказывают сотрудники, специализирующиеся на этом конкретном решении. Привлечение таких специалистов планируется в отдельном порядке, поэтому услуга доступна ограниченному числу заказчиков. В настоящее время SAP не планирует сделать эту услугу доступной для всех заказчиков.
Последнее, но немаловажное: в обоих случаях необходимо провести финальные испытания, чтобы убедиться в том, что перенесенные пользовательские настройки работают без нареканий в новом решении SAP S/4HANA.
Кроме того, второй вариант предусматривает ряд неавтоматизированных операций, для выполнения которых требуются опытные консультанты. Поэтому при обсуждении проектов, в которых участвовал я, после изучения деталей выбор всегда падал на первый вариант.
И, разумеется, для этого решения не требуется специального инструментария. Теперь мы видим, почему мое суждение о методе комбинации необъективно.
В большинстве случаев этот метод не требует специального инструментария, необходимы только опытные консультанты. Поэтому заказчики, которым требуется именно этот метод, не обращаются в отдел DMLT, и у нас нет понимания того, насколько часто этот вариант используется в действительности.
Другими словами:
комбинация концептуально отличается от создания оболочки том, что не требует специального инструментария.
В заключение этого раздела хочу предложить простую схему, отражающую различия в стоимости разных вариантов перехода.
Для тех заказчиков, которые не могут использовать подход конверсии системы в SAP S/4HANA, но которым, тем не менее, требуется перенести в новое решение SAP S/4HANA хотя бы часть своей конфигурации, выходом станет выборочная миграция данных в SAP S/4HANA. Если вы хотите перенести большую часть текущей конфигурации, правильным выбором станет создание оболочки и конверсия системы, в других случаях более подходящим будет метод комбинации.
Если у вас есть дополнительные вопросы, задайте их в комментариях. Кроме того, если вам потребуется больше информации о выборочной миграции данных, перейдите по ссылке и ознакомьтесь с опубликованными там материалами:
https://support.sap.com/en/offerings-programs/support-services/data-management-landscape-transformat...
Если потребуется консультация или техническая поддержка по вопросам перехода на SAP S/4HANA, вы также можете направить сообщение по адресу: mailto:sap_dmlt_gce@sap.com.
Если вам понравился этот блог, делитесь им через свои странички в соцсетях и (или) нажмите кнопку «Нравится» 😉
Ссылка на оригинал
Концепция этого блога
Прочитав этот блог, вы:
- получите представление о различных вариантах перехода на 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...
Дополнительную информацию о пульте управления миграцией можно прочитать в блогах Яцека Клатта (Jacek Klatt) и Зунаида Хингоры (Zunaid Hingora):
https://blogs.sap.com/2017/05/29/migrating-data-to-your-new-sap-s4hana/#:~:text=As%20per%20note%2022....
https://blogs.sap.com/2020/01/18/ltmc-s-4-hana-replacing-lsmw/
Выборочная миграция данных в SAP S/4HANA
Мотивация
Подытожим вышесказанное, отметив следующие ключевые моменты.
Установка с нуля зачастую становится самым сложным вариантом перехода на SAP S/4HANA. Кроме того, при этом подходе невозможна миграция архивных данных.
Конверсия системы представляет собой гораздо более простой и понятный проект, но лишает вас гибкости в том, что касается переконструирования существующих процессов.
Поэтому в качестве альтернативы разработан вариант перехода с выборочной миграцией данных на SAP S/4HANA. Выборочную миграцию данных включает два метода:
- создание оболочки и конверсия;
- комбинация.
Рассмотрим оба метода
Создание оболочки и конверсия
Основная идея подхода с выборочной миграцией данных заключается в том, чтобы запустить в работу новое решение SAP S/4HANA на основе существующего ERP-решения SAP, но при этом получить больше гибкости для внесения изменений, чем в случае конверсии системы.
Как этого добиться?
Основные принципы этого подхода очевидны.
Мы начинаем с создания оболочки существующего ERP-решения SAP, что дает нам пустую систему, содержащую только конфигурацию без каких-либо переменных и основных данных (шаг 1 в нижеприведенной диаграмме). Наличие конфигурации означает, что системе есть пользовательские настройки и объекты репозитория, и ничего больше . Эта система будет преобразована в SAP S/4HANA в порядке обычной конверсии системы (шаг 2).
Поскольку в ней нет данных, вы можете внести любые необходимые изменения в конфигурацию своей новой пустой системы SAP S/4HANA. Например, вы можете скорректировать финансовую модель или задать настройки контроллинга с учетом будущих требований. Тем самым вы создадите свою идеальную систему, которая станет отправной точкой для решения SAP S/4HANA (шаг 3).
Вы копируете ее, чтобы создать целевую систему (шаг 4).
Следующим шагом должна стать миграция данных (шаг 5). Во всех областях, к которым вы не применяли затрагивающих основные параметры изменений, будет также можно перенести архивные данные и менять их в процессе перехода на новые структуры SAP S/4HANA. В этих областях миграция данных осуществляется на уровне таблиц, и необходимые для SAP S/4HANA изменения «на лету» выполняются в специальных «разгонных» программах, которые идентичны или похожи на программы, используемых при обычном преобразовании системы в SAP S/4HANA.
Что касается тех областей, в которых вам нужно внести основополагающие изменения, используются другие методы миграции, предусматривающие добавление данных в безопасном режиме посредством системных интерфейсов, поэтому невозможно будет разместить никаких архивных документов, содержащих такие данные. Однако, если, например, в модуль логистики требуется внести лишь несколько изменений, а в модуль финансов — принципиальные изменения, то вы сможете перенести архивные документы в модуль логистики, но не сможете сделать это для модуля финансов.
В этом случае все равно можно будет связать документ логистики с соотносящимся с ним открытым финансовым документом.
Основные шаги при создании оболочки
Примеры вариантов создания оболочки и конверсии
Сценарий временных интервалов
Это один из наиболее широко используемых сценариев. Представим, что у вас в системе данные за 10 лет, но при текущих рабочих процессах вам могут понадобиться данные только за последние два года. Поэтому при переходе на SAP S/4HANA вы хотите полностью удалить данные более ранних периодов. Выборочная миграция данных в SAP S/4HANA — это идеальное решение для такой задачи! Вам не требуется переконструирование существующего решения, вы можете просто воспользоваться гибкостью, предоставляемой при выборочной миграции данных, чтобы избавиться от старых данных. Если вы хотите сохранить данные прошлых периодов для аудиторов, то рассмотрите возможность применения решения SAP Information Lifecycle Management.
Выборочная миграция кода компании
Если вы переносите в SAP S/4HANA не все коды компаний сразу, а только один или некоторые из них, то этот сценарий для вас. Конечно, его также можно сочетать со сценарием временных интервалов.
Выборочная миграция кода компании используется, например, в сценариях комбинации или в случае масштабных проектов, когда этот сценарий позволяет разбить переход на SAP S/4HANA на несколько этапов. Используя сценарий временных интервалов, нельзя недооценивать объем работ, которые потребуются для создания временных интерфейсов, если одни компании частично уже используют SAP S/4HANA, а другие все еще работают с ERP-системой SAP.
Конечно, в реальной жизни все может быть намного сложнее, и вам потребуется сочетать сценарии временных интервалов и выборочной миграции. Кроме того, критерии отбора элементов организационных единиц могут быть гораздо более сложными, нежели просто использование полных кодов компании.
Учитывая это, для выборочной миграции данных был разработан механизм оценки объема данных (Data Scope Engine). Дополнительную информацию об этом см. в блоге моего коллеги Матиас Стегмюллер (Matthias Stegmüller):
https://blogs.sap.com/2020/09/23/data-scope-engine-identify-relevant-data-for-sap-s-4hana-transition...
Сценарий адаптации и подбора
Это наиболее широко используемый сценарий выборочной миграции данных. Здесь вам потребуется внести в определенные части системы изменения, которые невозможны во время конверсии системы.
Например, у меня достаточно клиентов, которые все еще используют классическую главную книгу с параллельными счетами и которые хотят перейти на решение с параллельными регистрами, а также, например, внедрить решение для разделения документа. Но при этом в область логистики существующего решения не требуется вносить никаких изменений.
В случае выборочной миграции данных эту задачу можно решить довольно просто:
данные логистики можно перенести полностью вместе с архивными данными, но в области финансов возможен перенос только открытых позиций и основных данных.
Примечание. Даже в этом случае подход с выборочной миграцией данных включает решения, позволяющие перенести архивные финансовые данные, но следует помнить, что это совсем не просто и это нельзя сделать исключительно при помощи инструментов; помимо технического решения для выборочной миграции данных потребуются высококлассные профессионалы-финансисты, которые действительно знают, что делают. Лично я в таких случаях советую подбирать для этой задачи консультантов с большим опытом в области миграции архивных данных на уровне таблиц.
Такой совет объясняется следующим.
SAP все еще не объявила, когда переход с модели параллельных счетов на модель параллельных регистров будет включен в стандартный объем решения SAP S/4HANA. Поскольку довольно много заказчиков заинтересованы в этом решении, на то есть причина:
это не тривиальная задача, и сложно создать законченное решение, учитывающее каждую возможную ситуацию, а значит, можно ожидать, что в каждом отдельном проекте решение нужно будет подогнать под обстоятельства заказчика, чтобы оно работало без нареканий
Комбинация
Если выборочная миграция данных — это способ сделать конверсию системы более гибкой, то комбинация позволяет при установке с нуля сохранить и обезопасить те компоненты конфигурации, которые не нуждаются в изменениях.
В отличии от метода создания оболочки, комбинация применяется гораздо реже. Однако здесь мои наблюдения не совсем объективны, и позже я объясню почему.
Основная идея комбинации заключается в том, чтобы применить подход установки с нуля, но при этом сохранить определенные области существующего решения SAP ERP, которые, как оказалось, вполне соответствуют будущим потребностям клиента.
Поскольку вы хотите сохранить некоторые области существующего решения, вам следует сначала четко определить их. (Помните, что даже сегодня, при наличии Agile, одной из основных причин перерасхода бюджета или полного срыва проекта является нечетко установленный или постоянно нарастающий объем работ).
Определив области решения, которые вы хотите перенести в новую систему SAP S/4HANA, необходимо решить, как это сделать.
Есть два возможных пути:
- вручную добавить конфигурацию в новое решение SAP S/4HANA;
- перенести решение с помощью определенного инструментария.
Особенности первого варианта
Потребуются опытные консультанты, которые вручную настроят решение в целевой системе.
Особенности второго варианта
Вариант а): если при переходе от SAP ERP к SAP S/4HANA изменения отсутствуют или являются незначительными, вы можете перенести пользовательские настройки из SAP ERP в SAP S/4HANA напрямую и вручную переделать кастомизацию в целевой системе.
Вариант b): если изменения при переходе от SAP ERP к SAP S/4HANA являются существенными, вы можете создать оболочку своей системы SAP ERP и преобразовать ее в SAP S/4HANA.
Теперь у вас есть основа для переноса решения в новую систему SAP S/4HANA.
Кроме того, в этом случае вы будете вручную переделывать и адаптировать перенесенные элементы в решении SAP S/4HANA.
Комбинация
Есть особый метод, позволяющий тщательно отбирать элементы пользовательских настроек и переносить их с помощью специального набора инструментов. Точкой отсчета при такой миграции может быть система SAP ERP и (или) SAP S/4HANA. Однако, это только полуавтоматическое решение, поскольку вам придется вручную проверять соответствие и правильность интеграции перенесенных элементов в целевую систему. Если вас заинтересовала услуга, в рамках которой предоставляется такое решение, обратитесь по адресу sapmcd@sap.com. Это решение создано на базе решения MCDelta, которое также используется для сравнительного анализа систем и при использовании варианта Central Finance.
Эту услугу оказывают сотрудники, специализирующиеся на этом конкретном решении. Привлечение таких специалистов планируется в отдельном порядке, поэтому услуга доступна ограниченному числу заказчиков. В настоящее время SAP не планирует сделать эту услугу доступной для всех заказчиков.
Последнее, но немаловажное: в обоих случаях необходимо провести финальные испытания, чтобы убедиться в том, что перенесенные пользовательские настройки работают без нареканий в новом решении SAP S/4HANA.
Кроме того, второй вариант предусматривает ряд неавтоматизированных операций, для выполнения которых требуются опытные консультанты. Поэтому при обсуждении проектов, в которых участвовал я, после изучения деталей выбор всегда падал на первый вариант.
И, разумеется, для этого решения не требуется специального инструментария. Теперь мы видим, почему мое суждение о методе комбинации необъективно.
В большинстве случаев этот метод не требует специального инструментария, необходимы только опытные консультанты. Поэтому заказчики, которым требуется именно этот метод, не обращаются в отдел DMLT, и у нас нет понимания того, насколько часто этот вариант используется в действительности.
Другими словами:
комбинация концептуально отличается от создания оболочки том, что не требует специального инструментария.
В заключение этого раздела хочу предложить простую схему, отражающую различия в стоимости разных вариантов перехода.
Объем работ по проекту
Заключение
Для тех заказчиков, которые не могут использовать подход конверсии системы в SAP S/4HANA, но которым, тем не менее, требуется перенести в новое решение SAP S/4HANA хотя бы часть своей конфигурации, выходом станет выборочная миграция данных в SAP S/4HANA. Если вы хотите перенести большую часть текущей конфигурации, правильным выбором станет создание оболочки и конверсия системы, в других случаях более подходящим будет метод комбинации.
Если у вас есть дополнительные вопросы, задайте их в комментариях. Кроме того, если вам потребуется больше информации о выборочной миграции данных, перейдите по ссылке и ознакомьтесь с опубликованными там материалами:
https://support.sap.com/en/offerings-programs/support-services/data-management-landscape-transformat...
Если потребуется консультация или техническая поддержка по вопросам перехода на SAP S/4HANA, вы также можете направить сообщение по адресу: mailto:sap_dmlt_gce@sap.com.
Если вам понравился этот блог, делитесь им через свои странички в соцсетях и (или) нажмите кнопку «Нравится» 😉
- SAP Managed Tags:
1 Comment
