BeeX Technical Blog【寄稿】後悔しない「S/4HANA化を見据えた現行ERPシステムでの備え」とは

本記事は、JSUGが選定した旬なテーマを掲載する新しいテーマ別臨時メールマガジン「JSUG EXPRESS VOL.2」連動記事です。

2018/10/16 追記:本記事の改訂版を公開しました。【寄稿】続・後悔しない「S/4HANA化を見据えた現行ERPシステムでの備え」とは(SAP S/4HANA1809対応版)

第2回のテーマは「SAP S/4HANAのマイグレーション」

SAP S/4HANAマイグレーションとは、一般的には既存ERPシステムをS/4HANAへの移行することを指しますが、これからS/4HANAを使おうとする場合に考えられるシステム移行方法は以下の3種類です。

① 新規構築
② Conversion
③ Landscape Transformation

「新規構築」は文字通りS/4HANAを新規に導入し、必要データのみを移行また作成し、新規システムとして稼働させる方式です。一般的に「マスタのみ移行」とか「会計残高移行」と称される世界で、過去データについては古いシステムを塩漬け保存することで、参照することになります。

「Conversion」とは現在稼働しているERPシステムをS/4HANAへ変換することを意味し、実際には複数の方式が存在します。

「Landscape Transformation」はSAP社が提供するSLOサービスやSAP LT(将来計画予定)を用いて、現在稼働している複数のERPシステムをS/4HANAへ変換と同時に統合することを指します。

本記事では最も多くのSAPユーザが検討されるであろう「Conversion」に絞って解説します。

「Conversion」における3つの選択肢

  • Conversion Guideに従ってDatabase Migration Option with Software Update Managerを利用する。略称DMO with SUM(ディーエムーオー・ウィズ・サム)と呼び、SAP社の標準ツールを利用する
  •  SAP社のコンサルティングメニューであるSystem Landscape Optimizationサービスを利用する
  •  SAP社の移行ツールSAP Landscape Transformation 2.0(現時点では未対応、将来対応予定)を利用する

本記事では通常の保守契約のみで利用可能な、DMO with SUMに着目します。

SAP標準ツールでの「Conversion」留意事項

現在稼働しているERP(もしくはR/3)システムのバージョン、エンハンスメントパッケージレベル、サポートパッケージレベル、文字コード(ユニコードかノンユニコードか)によっては、制約があります。

本制約は、いざS/4HANAのプロジェクトを立案しようとした場合に、既存システム側の前提を満たしてないためにお手上げの状態になるとか、最悪システムの作り直しといった自体も招きかねない要件のため、自社システムのConversionパス(システム遷移シナリオ)は早期に見極める必要があります。

現行ERP環境に対して何が準備できるのか?

現在ERP6.0を利用している場合、S/4HANAの移行を見据えて何を備えるべきでしょうか。既存システムに大きな変更を加えるタイミングとしては以下のようなことが多いかと存じます。

・ ハードウェアの保守切れ
・ OS/DB等ミドルウェアの保守切れ
・ SAP製品(例:NetWeaver製品群)の保守切れ

その際、S/4HANAへの移行の準備という意味も踏まえて同時に実施できることとしては下記の通りで、これらは少なからずシステムのダウンタイムを伴います。

・ 基盤(サーバ等)の刷新
・ OSアップグレード又はデータベースアップグレード
・ SAP製品のアップグレード、エンハンスメントパッケージ適用

SAP製品のアップグレードにはS/4HANA化も含むことになってしまいますが、まずはERP6.0のまま留まる(=様子見)ということも現実解として十分ありえます。今回はたとえ様子見であったとしても、S/4HANAに備えるためには何ができるのかという点についても考察します。

ワンステップでS/4HANAに移行できるのか?

現行システムがS/4HANAにワンステップでConversionできるのかどうか、それを決定する要素としては主に「バージョン、SPSレベル」と「文字コード」です。

現行システムのバージョンとSPSレベル

まずバージョンとSPSに関してはコンバージョンガイド、及びノートに記載されておりターゲットバージョンのS/4HANAにより異なってきます、ここで確認しなければならないのは、現行システムのSPSがバージョン、エンハンスメントパッケージレベル毎に細かに指定されており、注意すべきは指定されたレベルより新しいものを適用してはならないことです。これまでは「~以上にしないといけない」という概念はよくあった話でありましたが、「~以下」つまり「新しくしすぎてはいけない」ということです。
しかし、最新のS/4HANA 1709ではERP6.0のEhP無~8までならばSPSを新しくしすぎてはいけない、という制約はなくなりました。

ターゲットリリースソースシステムのリリースに適用できるSPSの上限
S/4HANA 1709なし(ノート2482453 Version 2 from 2017/09/15 in Englishより)
S/4HANA 1610SAP ERP 6.0 SP Stack 29
S/4HANA 1610SAP enhancement package 2 for SAP ERP 6.0 SP Stack 19
S/4HANA 1610SAP enhancement package 3 for SAP ERP 6.0 SP Stack 18
S/4HANA 1610SAP enhancement package 4 for SAP ERP 6.0 SP Stack 18
S/4HANA 1610SAP enhancement package 5 for SAP ERP 6.0 SP Stack 15
S/4HANA 1610SAP enhancement package 6 for SAP ERP 6.0 SP Stack 18
S/4HANA 1610SAP enhancement package 6 for SAP ERP 6.0, version for SAP HANA SP Stack 10
S/4HANA 1610SAP enhancement package 7 for SAP ERP 6.0 SP Stack 13
S/4HANA 1610SAP enhancement package 8 for SAP ERP 6.0 SP Stack 06
S/4HANA 1610SAP Simple Finance add-on 1.0 for SAP Business Suite powered by SAP HANA SP Stack 10
S/4HANA 1610SAP Simple Finance, on-premise edition 1503 SP Stack 06
S/4HANA 1610SAP S/4HANA Finance 1605 SP Stack 07
S/4HANA 1511SAP ERP 6.0 SP Stack 27
S/4HANA 1511SAP enhancement package 2 for SAP ERP 6.0 SP Stack 17
S/4HANA 1511SAP enhancement package 3 for SAP ERP 6.0 SP Stack 16
S/4HANA 1511SAP enhancement package 4 for SAP ERP 6.0 SP Stack 17
S/4HANA 1511SAP enhancement package 5 for SAP ERP 6.0 SP Stack 14
S/4HANA 1511SAP enhancement package 6 for SAP ERP 6.0 SP Stack 16
S/4HANA 1511SAP enhancement package 6 for SAP ERP 6.0, version for SAP HANA SP Stack 09
S/4HANA 1511SAP enhancement package 7 for SAP ERP 6.0 SP Stack 11
S/4HANA 1511SAP Simple Finance add-on 1.0 for SAP Business Suite powered by SAP HANA SP Stack 08
S/4HANA 1511SAP Simple Finance, on-premise edition 1503 SP Stack 04

参考Note:

2189824 – SAP S/4HANA, on-premise edition 1511: Release Information Note
2346431 – SAP S/4HANA 1610: Release Information Note
2482453 – SAP S/4HANA 1709: Release Information Note

文字コード

次に文字コードに目を向けてみます。SAPシステムはR/3 Enterprise 4.7より文字コードとしてUnicodeのサポートが開始されました。長らくUnicodeとNon-Unicodeのシステムが混在してきた経緯がありますが、NetWeaver7.5を基盤とするシステムからUnicodeのみがサポートされることとなりました。ERPのバージョンに当てはめると、下表のようになります。

ERPバージョンコードページサポート備考
ERP6.0 EhP無~7Unicode及びNon-UnicodeBusiness Suite 7 Innovation 2013まで
ERP6.0 EhP8UnicodeのみBusiness Suite 7 Innovation 2016

S/4HANAへのConversionと言えど、プロセスの一部には従来のリリースアップグレードに近い処理となり、上表の意味するところは現在Non-UnicodeのERPシステムはワンステップでのS/4HANA Conversionが実施できないことを意味します。Non-UnicodeシステムはConversionの過程でUnicodeシステムに変換しなければなりません。つまりS/4HANAへのアップグレードプロセスと同時にUnicode変換を実施することができないので、それぞれ独立したステップとして必要です。

データベース

S/4HANAでは文字通りデータベースはHANAの利用が前提となります。利用するS/4HANAのバージョンにより、HANAの利用バージョンにも前提条件が付きます。

S/4HANAバージョン利用可能なHANAバージョン
1511 on premise editionHANA1~
1610 on premise editionHANA1~
1709 on premise editionHANA2 ※注

※注 2524661 – SAP S/4HANA 1709 – SAP HANA Database Requirements

Conversionにあたり、現在利用しているデータベースによって制約がかかることはありません、つまり従来のRDBMS(Any DB)で問題ありません。SAP ASEや、ましてやHANAでなければならないということは全くありません。AnyDB構成の場合は基本的にはDMO with SUM方式となりますが、既にSAP Business Suite on HANA(SoH)をご利用の場合は、同一環境でS/4HANAへ移行できる可能性があります。(ただし、HANAを1から2へアップグレードが必要。)

SoHで留めるという選択肢

現状のS/4HANAでは、自社のビジネスプロセスに対して明確なメリットとなる機能が無かったということも実際にはありえます。しかしハードウェア、ミドルウェアやOSの保守期限等を意識した場合には何らかの対策が必要です。

執筆時点(2017年9月)では、SoH(ERP6.0 Enhancement Package7及び8)でHANA2上での稼働がサポートされています。予めHANA2を利用することで、S/4HANA化の際にDB自体に変更を加えることなく移行可能です。

既にHANA1をご利用の場合はHANA1からHANA2へ予めアップグレード(※注)を実施しておくことでConversionへの近道となり得ます。なお、HANAがオンプレミスの場合はOSのアップグレードやカーネル類の調整等が必要となる場合があります。
※注 2420699 – Release of SAP HANA Database 2.0 for older SAP Version

S/4HANA化に最適なシステムランドスケープとは

S/4HANAの基本構成

ERP6.0ベースでセントラル構成(DB+CI 1台構成)かつ3ランドスケープで稼働させていた場合、S/4HANAに移行するとサーバの台数がどのように変わるかを図にしてみました。

これまで多くのシステムで採用されてきたSAPインスタンスとデータベースインスタンスが同一のホストに同居する構成ではなく、データベースとしてのHANAとSAPのメンテナンス性から別サーバとしてSAPインスタンス Primary Application Server(PAS)、並びに新しいユーザーインタフェースSAP Fioriを利用するために、Fiori Front-End Server(FES)を準備します。

なお、検証・本番環境には、DB HANAサーバとして、PrimaryとSecondaryがありますが、こちらはHANAデータベースのリアルタイムデータ複製機能(HANA System Replication)を活用してHA構成にしています。(オプション)

また、Conversionを計画、実行するためにはSolution ManagerやSAP Routerが必要となります。Maintenance Plannerの利用も前提となるため、Solution Manager 7.01 SP23以上または7.1 SP05以上である必要があります。

定期的な基盤S/W更新に対応できること

HANAは定期的にSPSがリリースされ、それぞれのSPS応じた保守期限が設定されます。最近までは各SPSの保守期限がやや短いため運用面での負荷が懸念されるものでした。しかしHANA2 SPS02のリリースと共に保守期限は大きく改善されることとなりました。

製品とSPS保守期限提供サイクル補足
HANA1 SPS122021年5月終了HANA1 最終SPS
HANA2 SPS022019年7月
(リリースから2年)
1回/年最終SPSのみ5年の保守期限

HANA1の最終パッチとして提供されたSPS12の保守期限は2021年5月に延長されましたが、これは直近のSAP製品ライフサイクルの考え方に適合したと捉えられます。

HANA2のSPSに関しては最新リリースとしてのパッチ提供期間中であるため、SPSがリリースされてから2年間の保守が提供されます。しかし2年の保守期間が確保されたとは言え、従来のSAP製品と比較して、定期的なアップデート、アップグレードを前提とした設計、運用が求められます。

また、S/4HANAの移行プロジェクトの立案・計画にあたっては、SPSのリリース計画と保守期限を意識する必要があります。プロジェクト期間が長期に渡るような場合は、プロジェクト期間中にHANAのSPS適用を予め計画に盛り込むことは勿論のこと、本稼働後にも定期的なSPS適用を考慮したシステムと運用の設計が必要です。システム構成という意味では、従来の3システムランドスケープに加えて、HANAに対するSPS適用のテストシステムが必要に応じて随時利用できるというというランドスケープが理想でしょう。また、本番システムから定期的にシステムコピーを実施し、3システムランドスケープとは別の検証システムを作成されているケースも現場で見かけるようになりましたが、クラウド環境であればオンデマンドで検証システムを準備することが出来、定期的なアップデートを見据えた環境を容易に準備することができます。

 

理想的なS/4HANAシステムランドスケープとは

例として、AWS基盤上にS/4HANA環境を展開した場合の具体的なシステム構成は下図の通りです。

基本構成

通常の3ランドスケープ構成にHANA SPS適用等の定期的な基盤S/W更新時の事前検証用に臨時の検証環境を追加しています。本検証環境構築時は、本番機の定常バックアップデータからシステムコピー方式で自動構築することが考えられます。なお本環境は利用時のみのオンデマンド課金により、費用を最低限に抑えます。

 

基本構成+高可用性(HA)

さらに、高可用性のエッセンスを加えています。

※注:HANAデータベース標準機能である「HANA System Replication」を活用して、リアルタイムデータ複製を実装します。PAS、Fioriサーバは、事前に取得したバックアップデータをリストアすることで起動する前提です。本番待機側は定常運用時は検証環境として利用することで待機側のリソースを有効活用します。

AWS側の費用感については、SAP S/4HANA on AWS Tシャツモデルが参考になりますので、そちらを参照ください。

準備・計画フェーズにおける実機検証が重要

アプリケーション観点

S/4HANA化のConversionプロセスには、アプリケーション面での移行前処理、BASIS面でのリリースアップグレードとHANA移行に加えてS/4HANAの肝であるシンプル化をアプリケーション面の後処理として実施することが求められます。

既存環境とは別に一時的に評価環境を構築することで、S/4HANAのConversionが自社でどの程度の難易度か、そのボリュームはどれくらいになるのかを、PoC(事前検証)を実施することで容易に見極めることができます。

基盤観点

主にシステム停止を伴うDMO with SUMの処理となります。現在SUMは1.0と2.0の2種類のバージョンが存在しており、S/4HANA Conversionに利用するものはSUM2.0です。冒頭でも述べましたが、S/4HANAのConversionの前提条件としてシステムの文字コートはUnicodeである必要がありますので、Non-Unicodeシステムの場合はConversionに加えてUnicode化のダウンタイムが追加で必要になります。

既にユニコードシステムの場合はSUM2.0のダウンタイム短縮化アプローチとしてリリースアップグレード処理の大半をシステムの本稼働中に実施することができるDowntime Minimized(SUMのデフォルト)方式が利用可能です。

PoCプロジェクトで基盤観点でどの程度のダウンタイムが必要となるのかという点も見極めることが可能です。残念ながら現在Non-Unicodeシステムをご利用の場合は、Conversionの前にUnicode化を実施しなければならないので、これらのオプションは有効に活用できないことがあります。何れにしても移行方式には環境による様々な制約が存在するため、何が最適なのか経験豊富なBASISコンサルタントと共に考案することになります。

リフトアンドシフトの勧め

S/4HANA化を見据えて現行システムで何が準備できるのかについて説明して参りましたが、S/4HANA化するという大きな判断が必要になることに変わりはありません。クラウド環境であればシステム構成も状況に応じて柔軟な対応が可能なため、現行ERPシステムをLift and Shiftのコンセプトでまずはクラウド環境へ移行してしまうということも有効なアプローチです。

まとめ

今回のコラムではS/4HANAへの移行にあたってインフラ/BASISの視点での移行計画立案から運用までの大きな課題になり得るポイントを解説させていただきました。最新バージョンであるS/4HANA 1709がリリースされ、ビジネス機能として更なる革新がもたらされました。自社に明確なビジネスメリットをもたらす場合には、早期にConversionプロジェクトを計画されるユーザ企業様もいるかと思いますし、将来のバージョンでの機能拡張を見込んで現状維持の判断するという事も勿論有り得ます。今回のコラムではその両者について解説させていただきましたが、機能革新の著しいS/4HANAに追従するためには、その何れの方向であってもクラウドの有効性は確かなものです。Conversionのプロセスも非常に重要なものですが、安定した本稼働を維持するためには定期的な更新を見据えたシステム基盤選びも重要な要素となり得るでしょう。

 

関連サービス:SAPシステム移行・環境構築サービス

SAPシステム移行・環境構築サービス

SAPを中心とした基幹システムをパブリッククラウド等最新のIaaS基盤に移行します。2016年3月設立の若い会社ですが、集まってきた精鋭コンサルタントが携わってきた数多くのプロジェクトの経験をもとに、安全かつ確実にシステムを移行します。

詳細を見る

カテゴリ

タグ

BeeX Technical Blogについてのお問い合わせ

BeeX Technical Blogのエントリにご質問が御座いましたらお気軽にお問合せください。

お電話でのお問い合わせ

☎ 03-6214-2830

受付時間 平日9:30〜18:00

フォームでのお問い合わせ

お問い合わせフォーム