SAP S/4HANA に移行する前に検討すべきポイントとは

　現行のSAP ERP環境から、最新のSAP S/4HANAへ移行したいと考えているシステム担当者は少なくないはずです。また、SAP ERPは2027年にサポートが終了する予定で、いずれはSAP S/4HANAへの移行が必要となります。2020年頃には駆け込み移行が急増し、SAP関連のコンサルタントが不足することも予測されており、確実な移行を実現するためには今から準備しておくべきでしょう。本記事では、SAP S/4HANAに移行をする上で欠かせない、事前検討事項について解説します。

(本記事はクレスコ・イー・ソリューション株式会社様と伊藤忠テクノソリューションズ株式会社が共同執筆した記事です)

▼ 目次
1. SAP S/4HANAへの移行の前に考えておくべきこと
2. スタートは業務改善の構想、システム環境のアセスメントから
3. SAP S/4HANAのインフラ要件のポイント
4. SAP S/4HANAのインフラを検討する際の注意点

1. SAP S/4HANAへの移行の前に考えておくべきこと

　SAP S/4HANAへの移行に着手する際に、はじめに検討しなくてはならないことがあります。それは、現行の環境をそのまま移行するか、まっさらな状態からSAP S/4HANAの新機能を導入するかです。一般的に前者は「マイグレーション」、後者は「リビルド」と呼ばれています。

図 1. 移行方式の概要

　マイグレーションは、現行のシステム設定をベースに移行を行う方式です。現在使っているカスタマイズ設定、アドオンプログラム、データをそのまま移植するため導入期間を短く、低コストで切り替えることができます。現行の業務に大きな課題がなく、現在の環境を継続したい場合におすすめの方式で、改善したい箇所のみに特化して最適化を図ることが可能です。単純なマイグレーションを行うのみではSAP S/4HANAの新機能が十分に活用されない可能性がありますが、新システム稼働後にあらためて表層化した課題に対して継続的なアプローチを図ることで、最大限のメリットを享受することができるでしょう。

　リビルドは、現行システムの設定に捉われず、ゼロベースから業務プロセスを見直し、システム構築を行う方式です。アドオンプログラムを極力廃し、SAP S/4HANAの新機能を有効に活用して業務プロセスを刷新する場合に有効です。新しい業務プロセスに合わせたシステム設計を行うことができ、システムの運用保守の障壁となりがちなアドオンプログラムを大幅に削減できます。刷新をきっかけに業務効率が向上し、ビジネスに付加価値が生まれる可能性はありますが、マイグレーションと比べると導入期間は長期化し、導入コストもかかります。

図 2. 移行方式のメリットとデメリット

図 3. 移行方式の評価における比較

　これら両者のメリット、デメリットを踏まえて検討することになりますが、今回は、短期間・低コストでSAP S/4HANAへの移行を実現するマイグレーションについて解説しましょう。

2. スタートは業務改善の構想、システム環境のアセスメントから

　マイグレーションを行うにあたっては、かかる期間やコストを試算して計画を立てる必要があります。この際、業務観点での改善構想とシステム観点でのアセスメント、それぞれを実施することが重要です。
　業務観点での改善構想では、システムに依存しない業務の改善策を検討することで、運用課題の洗い出し、作業環境向上の検討、ビジネスプロセスの見直しなどを進めます。ここで重要なのは、実現性や組織内部のしがらみに捉われず、広く意見を集め「こうなったらいいな」をかたちにしていくことです。そのためこのフェーズでは、IT部門以外に、現場キーマン、中立的な立場のファシリテータの参画、体制構築が成功のポイントとなります。

　一方、システム観点では、現行環境の設定状況や移行後のシステムに関する深い知識をもとにTo-Beを検討していくことになるため、ユーザのみで進めることは困難です。そこで、ITベンダーやコンサルティング会社が提供するアセスメント（診断サービス）を受け、現行のシステム環境からSAP S/4HANAに移行した場合の影響範囲を確認することから始めるのが基本です。

　アセスメントを受けることで、現行のSAP ERPで動いている機能やアドオンプログラムがそのままSAP S/4HANAで継続利用できるのか、あるいは改修が必要なのかがわかります。特にこれまで利用できていたABAPプログラム言語の命令文がSAP S/4HANAでは利用できなくなるケースがあるため、修正コストと期間を見積もる上で重要な作業となります。

　加えて重要なのが、SAP ERPと連携している周辺システムの影響範囲を把握することです。国内企業が持つ基幹システムでは、フロントの入力画面や帳票出力、さらには工場で稼働している生産・出荷管理などの機能が別システムで構築され、連携しているケースが多々あります。SAP S/4HANAにマイグレーションするとこれら周辺システムが影響を受ける可能性が高く、アセスメントの際には慎重に調査する必要があります。

　また、SAP ERPからSAP S/4HANAへの進化において、データ構造が大きく簡素化されたことでパフォーマンス向上が謳われていますが、移行すればシステムのパフォーマンスが必ず上がるとは限りません。アセスメントにおいてパフォーマンス観点での調査も行い、移行時にSAP S/4HANA向けのチューニングを施すことで、はじめて最適なパフォーマンスが実現します。

図 4. マイグレーションにおける移行方針決定のポイント

　IT部門の担当者は、ユーザを中心に作成した構想案とベンダーから提示を受けたアセスメント結果をもとに、SAP S/4HANAへの移行企画書を作成します。経営層に上申し、決済を経て本格的な移行プロジェクトがスタート。体制の構築や移行ベンダーの選定に入ります。

　なお、ベンダーが提供するアセスメントはベンダー各社で手法が異なります。SAP ERPの内部だけで周辺システムの影響調査はサービスの範囲外というケース、単純な影響調査だけで業務改善の評価までは含まれないケースもあります。SAP S/4HANAへの移行ノウハウや実績もベンダーによって差があるため、アセスメントを検討する際には移行作業まで見据えて選ぶのが鉄則です。

　それでは社内の情報システム部門の工数を最低限に抑え、短期間かつ確実にSAP S/4HANAへの移行を実現するにはどうすればいいのでしょうか。その方法は下記のボタンの先にて示します。SAP S/4HANAのマイグレーションを成功させるための明確なヒントが得られるはずです。

3. SAP S/4HANAのインフラ要件のポイント

　続いてインフラ面の検討事項を押さえておきましょう。SAP S/4 HANA のインフラ要件のポイントを記します。

CPU 性能
大容量メモリ
高速ディスク
セキュリティ
可用性実装
DR実装
統合バックアップ
SAP運用監視
柔軟な課金

　それぞれを簡単に解説しましょう。

3-1. 新たな ERPパッケージとしての SAP S/4HANA

　SAP R/3に始まり SAP ERP 6.0まで、SAP社の ERP製品(SAP Business Suite)は多くの OS, RDBMSをサポートすることで圧倒的なシェアを維持してきました。しかしこのたびあえてその特色を廃し、「経営をリアルタイムに一元管理できる」メリットを得られる後継製品として SAP S/4HANAがリリースされたのです。

　SAP S/4HANAがサポートする DBは同社のインメモリDBである SAP HANAのみとなります。

図 5. SAP S/4HANA のインフラに求められる要件

3-2. インメモリDBとしてゼロから設計された SAP HANA

　既存DBの多くはオプションとしてインメモリ機能を提供しますが、SAP HANAはインメモリであることが前提の設計であり、圧倒的な超高速処理を実現しています。2010年に登場し、2015年には先述のSAP S/4HANAのランタイムDBとして採用されたのに加え、OLTPとOLAPの融合、開発プラットフォームとしての側面など、単なる DB製品にとどまらない位置づけになっています。これらさまざまな役割を担う SAP HANAは、従来の DBにも増してミッションクリティカルな存在であると言えます。

図 6. インフラで検討すべき事項

3-3. 基幹システムの負荷ピーク

　基幹システムの利用形態は業種・企業形態によりさまざまですが、一般的に処理負荷の高低サイクル、波が生じます。

年度決算処理による会計年度末の高負荷
月次決算処理による月末締めの高負荷
（業種に応じた）オンライン処理、夜間バッチ処理におけるリソース偏重

全営業担当が基幹SAPをリアルタイムに利用するような場合は日中のオンライン処理が高負荷になります
日次でためこんだ伝票情報を夜間に一括処理するような場合は、夜間のバッチ処理が高負荷になります

図 7. インフラに求められる要件

4. SAP S/4HANAのインフラを検討する際の注意点

　SAP S/4 HANA のインフラを検討する上で注意しなければならないことがあります。それは、SAP S/4HANAを動かすためのシステム基盤に対し、従来のSAP ERPと同じ発想でアプローチしてはならない、ということです。

　前述の通りSAP S/4HANAはインメモリDBを使用するため、当然ながらメモリ上にデータを保持します。これに加えてデータ領域とは別のワークメモリ領域も必要です。そのため、実装すべきメモリ量が従来に比べて大幅に増大するのです。またインメモリ処理はI/Oのボトルネックが小さいため、そのポテンシャルを引き出すには、CPUもより高性能なものが求められます。

　トランザクション処理だけではなく、データ分析も行われることを考えれば、求められる処理能力はさらに増大することになります。データ分析はトランザクション処理に比べて負荷の変動が激しいため、ピーク時に合わせたサイジングですとかなり高性能なハードウェアを用意しなければなりません。SAP環境のサイジングでは、ベンチマークとしてSAPS (SAP Application Benchmark Performance Standard) 値が使用されるのが一般的ですが、SAP S/4HANAサーバーのサイジングにおいては、SAPS値は参考値として利用するにとどめておいた方がいいでしょう。

　さらに、システムランドスケープのことも考えておく必要があります。SAPの利用においては開発機、検証機、本番機で構成される「3ランドスケープ」が推奨されていますが、SAP S/4HANAではそれぞれに必要となるサーバー数が増大する可能性があります。SAP ERPでは多くのシステムでSAPインスタンスとDBインスタンスが同一サーバーに同居する「セントラル構成」が採用されていましたが、SAP S/4HANAのメンテナンス性を考慮した場合、これらを別サーバーにすることが望ましいからです。また新たなユーザーインタフェースを提供するSAP Fiori用のサーバーも、別途用意しておく必要があります。

　これらに加え、SAP ERPと連携して動作する周辺システムをどうするかという問題もあります。周辺システムの負荷はSAP S/4HANAサーバーに比べて低いケースが一般的ですが、それぞれ個別にサーバーを立てているのであれば、その維持管理コストが必要になります。

　このようにSAP S/4HANAへ移行することで、システム基盤のコストが大幅に増大する可能性があります。IaaSなどのクラウドサービスを利用して初期投資を抑制するというアプローチも考えられますが、SAP S/4HANAサーバーに求められるキャパシティを持つインスタンスは利用料が高額になりやすく、周辺システムまでクラウド化した場合はインスタンス数が増大し、ここでもコストが増大することになります。

　それでは十分なキャパシティを確保しながら、インフラコストを抑制するにはどうすればいいのでしょうか。その秘策は下記のボタンの先にて示します。SAP S/4HANAのシステム基盤をどのように確立すべきなのか、明確な指針が得られるはずでしょう。