【寄稿】続・後悔しない「S/4HANA化を見据えた現行ERPシステムでの備え」とは（SAP S/4HANA1809対応版）

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

第5回のテーマは「SAP S/4HANAへの道」

昨年大好評だった、JSUG EXPRESS VOL.2への寄稿記事「後悔しない『S/4HANA化を見据えた現行ERPシステムでの備え』とは」を最新SAP S/4HANA 1809の最新情報も含めて2018年度版としてアップデートしました。
SAP S/4HANAコンバージョンとは、一般的には既存ERPシステムをS/4HANAへの移行することを指しますが、これからS/4HANAを使おうとする場合に一般的に考えられるシステム移行方法は以下の2種類です。
① 新規構築
② Conversion
「新規構築」は文字通りS/4HANAを新規に導入し、必要データのみを移行また作成し、新規システムとして稼働させる方式です。一般的に「マスタのみ移行」とか「会計残高移行」と称される世界で、過去データについては古いシステムを塩漬け保存することで、参照することになります。
「Conversion」とは現在稼働しているERPシステムをS/4HANAへ変換することを意味し、実際には複数の方式が存在します。
本記事では最も多くのSAPユーザが検討されるであろう「Conversion」に絞って解説します。

「Conversion」の選択肢

• Conversion Guideに従ってDatabase Migration Option with Software Update Managerを利用する。略称DMO with SUM（ディーエムーオー・ウィズ・サム）と呼び、SAP社の標準ツールを利用する
•  SAP社のコンサルティングメニューであるSystem Landscape Optimizationサービスを利用する

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

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

現在稼働しているERP（もしくはR/3）システムのバージョン、エンハンスメントパッケージレベル、サポートパッケージレベル、文字コード（ユニコードかノンユニコードか）によっては、制約があります。
本制約は、いざS/4HANAのプロジェクトを立案しようとした場合に、既存システム側の前提を満たしてないためにお手上げの状態になるとか、最悪システムの作り直しといった自体も招きかねない要件のため、自社システムのConversionパス（システム遷移シナリオ）は早期に見極める必要があります。

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

現在ERP6.0を利用している場合、S/4HANAの移行を見据えて何を備えるべきでしょうか。既存システムに大きな変更を加えるタイミングとしては以下のようなことが多いのではないかと感じています。
・ ハードウェアの保守切れ
・ OS/DB等ミドルウェアの保守切れ
・ SAP製品（例：NetWeaver製品群）の保守切れ
その際、S/4HANAへの移行の準備という意味も踏まえて同時に実施できることとしては下記の通りで、これらは少なからずシステムのダウンタイムを伴います。
・ 基盤（サーバ等）の刷新
・ OSアップグレード又はデータベースアップグレード
・ SAP製品のアップグレード、エンハンスメントパッケージ適用

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

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

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

まずバージョンとSPに関してはコンバージョンガイド、及びノートに記載されておりますが、基本的にERP6.0であればSPレベルは問われません。勿論S/4HANA 1511以上であれば1809へアップグレードが可能です。ERP6.0の場合は制約があり、得意先マスタの連絡先に担当者が割当たっているようなケースのみ、ERP6.0 EhP5未満のシステムでは最低SP要件やノート適用といった前提条件が存在しますので、参考ノートに記載された確認手順によってLIFNR列のエントリ有無の判断が必要です。

 件表示

検索:

5 件中 1 から 5 まで表示

前次

参考Note：2659710 – SAP S/4HANA 1809: Restriction Note

ERP6.0より下位のバージョンをご利用の場合は、ERP6.0  EhPxへのアップグレードというステップが前提条件となります。

文字コード

Non-UnicodeのシステムはS/4HANAコンバージョンの前にUnicode変換を実施する必要があります。これはERP6.0 EhPxであってもNon-UnicodeのシステムはワンステップでのS/4HANA Conversionが実施できないことを意味します。つまりS/4HANAへのアップグレードプロセスと同時にUnicode変換を実施することができないので、それぞれ独立したステップとして必要です。

データベース

S/4HANA1809ではSAP HANA 2.0 SP03 Revision 033の利用が最低要件です。SAP HANA 1.0はサポートされず、常に最新のバージョンを利用することが推奨とされています。
※注　2659828 – SAP S/4HANA 1809 Feature Package Stack 00: Additional Release Information
Conversionプロジェクトを開始するにあたり、現在利用しているデータベースによって制約がかかることはありません。つまり従来のRDBMS（Any DB）で問題ありません。SAP ASEや、ましてやHANAでなければならないということもありません。AnyDB構成の場合は基本的にはDMO with SUM方式となりますが、既にSAP Business Suite on HANA（SoH）をご利用の場合は、SAP HANAのバージョンアップが必要となる可能性がありますが、同一環境でS/4HANAへ移行できる可能性があります。

S/4HANA1809のBASIS観点での新機能

今回は昨年記事の続編ということもあり、技術的により深いトピックを追記しました。スペシャリスト向けの内容になりますので、ご興味のある方のみご一読ください。
S/4HANA1809はABAP Platform 1809と呼ばれるNetWeaver7.53上で稼働します。執筆時点ではNetWeaver7.53は個別にリリースはされず、S/4HANA1809専用のプラットフォームとして提供されています。動作するSAPカーネルのバージョンは773です。
ABAP Platform1809での新機能としてBASISとして気にしておくべき点は以下のものかと思います。

ENQ2がデフォルトに

これまで高負荷の状況でボトルネックになった場合に改善することの困難なENQが進化しました。
2630416 – Support for Standalone Enqueue Server 2

SAP VMCが非サポートに

地味な機能として長きの間続いた仮想マシンコンテナは終わりを迎えました。
VMコンテナのアーキテクチャ

HTAが機能強化（HANAシステムの移送）

こちらもBASISのごく限られた方向けの情報かと思います。
SAP HANA Transport for ABAP (HTA) for SAP HANA Deployment Infrastructure (HDI)

ABAPデーモンの改善

GCやメモリ管理としてプライベートモードの防止などが組み込まれました。
ABAP Daemons (Enhanced)

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）、HANA Studioに替わりHANAデータベース管理タスクを実施できるHANA Cokpitを準備します。一般的な構成は上述ですが、HANAサーバとPAS、さらにFESも同居させて1台とすることも可能です。従来はPASとFESは別システムとして用意することが推奨とされてきましたが、1809では同居（Embedded-Deployment）も状況によっては推奨となり得る方針のようです。
本番環境には、DB HANAサーバとして、PrimaryとSecondaryがありますが、こちらはHANAデータベースのリアルタイムデータ複製機能（HANA System Replication）を活用してHA構成にしています。（オプション）
本番機だけReplicationを実装していて検証機と構成が違うじゃないか、というご意見もあるかと思います。構成の違いによる影響を検証したいような場面となった場合には、本番機のマシンイメージから完全なクローン環境を一式作成することが可能なため、クラウドではあえて本番と検証環境を同じ構成とする必要がないのです。
なお、Conversionを計画、実行するためにはSolution ManagerやSAProuterが必要となります。Maintenance Plannerの利用も前提となるため、Solution Manager 7.01 SP23以上または7.1 SP05以上である必要があります。

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

SAP HANA2.0は毎年4月に新しいSPSがリリースされ、2年間の保守期限が設定されます。SAP HANA 3.0がリリースされると、2.0向けの最終SPSがリリースされ、5年間の保守が提供されます。最低でも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方式を活用することが出来ます。
PoCプロジェクトで基盤観点でどの程度のダウンタイムが必要となるのかという点も見極めることが可能です。残念ながら現在Non-Unicodeシステムをご利用の場合は、Conversionの前にUnicode化を実施しなければならないので、SUMのダウンタイム削減オプションは有効に活用できないことがあります。何れにしても移行方式には環境による様々な制約が存在するため、何が最適なのか経験豊富なBASISコンサルタントと共に考案することになります。

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

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

まとめ

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