S/4HANA移行準備段階における進め方とポイントについて

この記事を書いたメンバー:

bxadm

S/4HANA移行準備段階における進め方とポイントについて

目次

■S/4HANA移行準備フェーズについて

現在ECCをご利用のユーザは、SAPの2027年問題に対しての準備はお進みでしょうか?
既にプロジェクト中の方もいれば、準備中や今から準備を進めれるユーザもいらっしゃるかと思います。
BeeXでは、各フェーズに合わせて各種サービスをご用意していますが、今回は、S/4HANAへの準備フェーズにおける赤枠で囲った4つのサービスの概要とポイントについて説明させていただきます。

■簡易アセスメント

簡易アセスメントとしては、SAP社から無償で提供されるReadiness Check、およびABAP Test Cockpit というチェックツールの利用したサービスをBeeXでもご提供しています。こちらのツールの内容はSAP社のブログ等でも紹介しておりますので、ご存じの方も多いかと思います。

簡単にご説明すると
Readiness Checkは、移行した際の標準機能の影響分析・移行時のダウンタイム予測・移行後の想定ディスクサイズなど、移行を検討する上で役立つ情報を提供するツールとなります。
ABAP Test Cockpitは、お客様で開発されたアドオンの影響調査を行うツールとなります。
無償で利用できるツールではありますが、かなり有益な情報が得られるツールとなっています。

移行を行う際の最初の一歩として、SAP社も推奨しているツールですので、まず何かをやってみようというユーザは、是非ご利用していただければと思います。

Readiness Check、およびABAP Test Cockpitの実行方法を簡単にご説明します。

まず、BeeX社内のBeeX Migration Factory というコンバージョンのため環境に、お客様のECC環境をコピーさせていただき、その後ノートやSPを適用します。

Readiness Checkを実行するためには、ECC上でReadiness Checkプログラムを実行します。
実行により作成されたファイルを、④としてSAP社のクラウド上のサービスにアップロードします。アップロード後は、SAP社クラウドサービスで各自のブラウザから実行結果の確認が可能です。

次ですが、ABAP Test Cockpitを実行するためには、別途NetWeaverのATC実行サーバが必要となります。こちらは事前にBeeXで用意してありますので、このATC実行サーバ上でABAP Test Cockpitを実行していきます。実行すると④のようにRFC接続でECC上のアドオン情報を取得します。取得した情報を元に⑤のようにGUI上で分析結果を確認する事ができます。

こちらの対応をBeeXで実施させていただき、結果についてのご説明を実施させていたくサービスとなっています。

■Readiness Check

Readiness Checkの主要機能について簡単に説明します。
ブラウザ上に様々な分析結果が出力されますが、こちらに一部の機能を並べています。
星マークは独断で設定した有益度となります。

サイジングやダウンタイムの情報でアーカイブの要不要の検討や、コンバージョン実施タイミングの検討などでも役立てる事ができます。
このようにReadiness Checkでは、移行影響分析からサイジング・ダウンタイム予測など、S/4HANA移行を検討する上で必要になる情報が提供されます。
BeeXでは、お客様がこちらのサイトにブラウザでアクセスできるようにした上で、使い方・意味などを解説させていただきます。


■ABAP Test Cockpit

次にABAP Test Cockpitの分析結果画面となります。
こちらはATC実行サーバ上で表示されます。

分析結果として、影響があるアドオンの統計情報や、影響対象一覧が出力されます。
一覧には、修正が必要な理由・修正箇所へのリンクなどの情報を出力されます。なお、実際のアドオン修正時でも、このABAP Test Cockpitは利用可能です。
S/4コンバージョンでは、アドオンの修正対応が、コストや期間に大きく影響を与えます。こちらの結果をExcel形式でダウンロードして、ピボットテーブル等を利用してさらに分析する事も可能です。

これらを利用しておおよその修正ボリュームを把握する事が可能となります。

■移行計画策定

アセスメントサービスの移行計画策定についてご紹介します。
こちらのサービスは、後続のS/4HANAコンバージョンプロジェクトの計画策定を、BeeXのコンサルタントがお客様から要件や現在の状況を確認しながらが実施するサービスとなります。
ご存じの通り、BeeXはBasis・インフラを得意としているベンダーとなります。そのため、主に基盤構成検討・移行方式検討をベースとした移行計画策定を実施させていただきます。

もちろん弊社パートナーのアプリベンダーと協業して、アプリケーション領域も含めての計画策定も可能です。また他のアプリベンダーと協力して実施する事も可能です。

成果物としたは、スケジュール案、タスク一覧、クラウド構成図、可能性方針、移行パス、ダウンタイム予測などの情報をご提供いたします。
ダウンタイム予測値は、あくまでの過去の経験を元にした予測値となります。

■S/4HANAコンバージョンのダウンタイムについて

S/4HANAコンバージョンのダウンタイムは、不確定な要素が多数あり、机上での予測は基本的には難しいものとなります。
当然、基幹システムであるERPを何日も停止できないので、ダウンタイムが分からないままですと、

 コンバージョン方式のまま進めて問題ないのか?
 移行実施タイミングをいつにすればよいのか?
 ダウンタイムの影響範囲がどこまになるのか?

など、わからないままとなってしまい、移行計画の策定自体が難しくなります。

こちらのチャートは、一般的なダウンタイム時の工程となります。

左から右へ、一般的に必要となるダウンタイムの工程を記載してあります。

これはECCがユニコード環境の場合ですが、ノンユニ環境の場合では、さらにユニコードコンバージョン処理が必要になります。濃い青の部分が、データ量に依存して時間が変動する工程となります。
青い部分の1つ目は、「コンバージョン前処理」となります。
こちらはSI-Checkというコンバージョンの前に実施するチェックプログラムをクリアするために必要な処理となります。SI-Check対応は、可能な限り事前に移送を作成して対応します。
ただし得意先・仕入先をビジネスパートナーを登録するCVI処理など、データ変換を伴う処理は、移送では対応できません。
そのため、多く場合はこの部分で実施します。
対象処理や対象データが多ければ多いほど時間がかかります。

次の青い部分は、SUMというコンバージョン処理本体のツール実行時間です。
移行元ECCからデータを抽出し、HANA-DBへ移行する処理となりますので、データ量が多ければ多いほど時間がかがります。
また、のちほど説明しますが、SUMは処理オプションがいくつかあります。
その方式によってもこの処理実行は大きく変わってきます。

次にコンバージョン後処理ですが、こちらは、会計および品目元帳データをS/4HANAデータモデルに変換する処理となります。こちらもデータ量に依存する処理となります。
このようにデータ量に影響をうける処理がいくつかありますが、これらの処理時間は様々要素の影響を受けるため、非常に予測が難しくなっています。

■PoCコンバージョンサービス

机上でのダウンタイム予測の難しさに説明しましたが、それも受けた上で、BeeXではPoCによるダウンタイム時間を把握するサービスをご提供しております。

こちらのサービスは、実際にコンバージョンを実施し、机上では把握できない、実行時の問題の確認や、各工程の処理時間を確認するサービスとなります。実施の際は、お客様の本番環境をお預かりして、コンバージョンを実施させていただきます。
コンバージョン時の課題・問題の洗い出しや、各工程の処理時間測定を目的としていますので、アプリレベルの修正対応は最小限の対応とさせて頂いています。

まず初回コンバージョンを実施し基本的なコンバージョン手順を確立します。こちらが約1カ月ぐらいとなります。
その後、BeeXのコンバージョンノウハウを生かし移行方式の再検討・パラメータチューニング、クラウドチューニングなどを実施し最適なダウンタイムを追求した再コンバージョンを実施します。
約3カ月で結果をご報告せていただきます。

PoCコンバージョンサービスの成果物としては、SI-Check対応の一覧、ダウンタイム分析、移行パス、ダウンタイムの詳細、会計後処理の詳細情報、モディフィケーション調整の一覧、など実際にコンバージョンを実施して得られた情報をご提供させていただきます。

これらの情報により、より正確な移行計画策定が可能となります。

■ダウンタイム短縮手法

一般的なダウンタイム短縮手法について解説します。

・データ量削減

会計データのアーカイブや、不要なデータを削除する方法です。
対応方法としては基本的にアーカイブとなります。アーカイブとなると敷居は高くなると思いますが一番有効でもあります。
PoCの中での検証も可能ではありますが、対応については個別に調整させていいただく事になります。

・処理の並列化

1616401 - Parallelism in the Upgrades, EhPs and Support Packages implementations、2351294 - S/4HANA System Conversion / Upgrade: Measures to reduce technical downtime といったSAPノートがでていますので最適な設定を実施して対応します。

・実行時のリソース拡張

クラウドではリソースを柔軟に変更可能であるというメリットがあります。そちらを最大限に活用してダウンタイムの短縮を行います。特にデータ量に依存して処理時間がかかる各工程では、どの場所でどのリソースが必要なのかを把握した上で、適切なリソース増強を実施し対応する必要があります。

以下の表は、リソースごと・サーバごとの一般的なソース増強方針を示したものになります。

リソース増強の実施方法ですが、各クラウドごとに仕組みが違いますので、そちらを理解した上で対応する必要があります。

以前、社内検証したチューニング前と後での処理時間を比較しましたが、53時間から29時間に大幅に削減する事ができました。処理方法・データ量は同じですが、リソースのチューニングだけでこれだけの差が出ます。そのため、チューニングは必須です。

BeeXなら各クラウド特有のノウハウがありますので是非ご相談ください。

・最適なDMO実行方法の選択

標準的コンバージョン方式には大きく2種類の方式があります。

左がDMO with System Moveです。
この方式では、SUMの実行で、完全に別ホストへの移行が可能とします。そのためデータセンター間のマイグレーションで多く利用されています。
但し、ソースステムのデータを、ファイルにエクスポートしてから、新データベースへインポートする手順、となりますので、処理時間がそれなりにかかります。

右がプレーンDMOです。
こちらは1台のPAS上で、ソースデータベースからデータ抽出を行行い、メモリを介して、新データベースへインポートする手法です。ファイルを介さないため高速に実行する事が可能です。
但し、現PASがそのまま新環境のPASとなる、という制約がありますので、移行環境によってはこの方式が適さない場合もあります。

どちらの方法を選択するかは、現行の環境、および移行先環境を考慮した上で決定する必要があります。
この検討は非常に重要であり、経験やノウハウが必要になります。

・ダウンタイム最適化手法

SAP社標準のダウンタイム最適化手法も用意されています。
以前よりSAP社よりリリースされてはいましたが、以前までは、SAP社メンバーによるサポートが必要、などの実施条件がありました。直近においては、その実施条件が緩和されて一般利用が可能となっています。

上記図にあるように、標準的コンバージョンでダウンタイム時に実施している処理を、アップタイム中に実施する事でダウンタイムを短縮する、という手法となります。

現状で2方式あります。

Downtime-Optimized DMO では、一部の大きなテーブルのデータ移行を、アップターム中に実施し短縮を行います。

Downtime-Optimized conversion では、データ移行にくわえ、データ変換、会計データ変換もアップタイム中に実施する事で、さらなる短縮をはかります。

非常に魅力的な方法ですが、アップタイム中に移行処理を行うという事になりますので、アプリ的な制約事項もあります。また、不整合なく移行を行うためには、十分な検証が必要なとなります。

まだまだ一般的ではありませんが、今後、より利用されるテクニックかと思います。


BeeXではダウンタイム最適化手法についての検証も実施しています。BeeX技術ブログでも公開していますので、よろしければご確認頂ければと思います。

ダウンタイム最適化コンバージョンをやってみた①(概要編) ~Downtime Optimized Conversion~|株式会社BeeX (beex-inc.com)

■最後に

BeeXのS/4HANA 準備フェーズのご紹介と実施時のポイントなどについて記載してきました。

これらのサービスは組み合わせして実施する事も可能です。
例えば、本日お話した、Readiness Check ・ABAP Test Cockpit ・PoCコンバージョン・移行計画策定の4サービスを同時に実施する事も可能です。
環境をお預かりし、Readiness Check ・ABAP Test Cockpit ・PoCコンバージョンを実施しますので、個別に実施するよりも、効率よく実施する事ができます。

また、S/4HANAコンバージョンのダウンタイムは、不確定な要素が多数あり机上での予測は難しいものとなります。ダウンタイムがどのぐらいになるかわからないと、移行計画自体を立てる事も難しくなるため、手戻りなくプロジェクトを推進するためには、事前に正確な予測値を把握する事は非常に重要となります。

PoCコンバージョンを実施する事で確認できたダウンタイムを結果を移行に反映する事で、正確な移行計画策定が可能となります。

BeeXでは本日ご紹介したサービス以外にもSAPに関する各種サービスをご用意しております。
こんな事できないの?という感じでも問題ありませんのでお気軽にご相談をして頂ければと思います。

カテゴリー
タグ

この記事を書いたメンバー

Pick upピックアップ

Search記事を探す

キーワード

SAPシステムや基幹システムのクラウド移行・構築・保守、
DXに関して
お気軽にご相談ください

03-6260-6240 (受付時間 平日9:30〜18:00)