S/4HANAへ移行したいと考えているシステム担当者は少なくないはずです。S/4HANAへの移行が必要となります。2020年頃には駆け込み移行が急増し、SAP関連のコンサルタントが不足することも予測されており、確実な移行を実現するためには今から準備しておくべきでしょう。S/4HANAに移行をする上で欠かせない、事前検討事項について解説します。S/4HANAへの移行に着手する際に、はじめに検討しなくてはならないことがあります。S/4HANAの新機能を導入するかです。一般的に前者は「マイグレーション」、後者は「リビルド」と呼ばれています。移行方式の概要マイグレーションは、現行のシステム設定をベースに移行を行う方式です。現在使っているカスタマイズ設定、アドオンプログラム、データをそのまま移植するため導入期間を短く、低コストで切り替えることができます。現行の業務に大きな課題がなく、現在の環境を継続したい場合におすすめの方式で、改善したい箇所のみに特化して最適化を図ることが可能です。S/4HANAの新機能が十分に活用されない可能性がありますが、新システム稼働後にあらためて表層化した課題に対して継続的なアプローチを図ることで、最大限のメリットを享受することができるでしょう。リビルドは、現行システムの設定に捉われず、ゼロベースから業務プロセスを見直し、システム構築を行う方式です。S/4HANAの新機能を有効に活用して業務プロセスを刷新する場合に有効です。新しい業務プロセスに合わせたシステム設計を行うことができ、システムの運用保守の障壁となりがちなアドオンプログラムを大幅に削減できます。刷新をきっかけに業務効率が向上し、ビジネスに付加価値が生まれる可能性はありますが、マイグレーションと比べると導入期間は長期化し、導入コストもかかります。S/4HANAへの移行を実現するマイグレーションについて解説しましょう。スタートは業務改善の構想、システム環境のアセスメントからマイグレーションを行うにあたっては、かかる期間やコストを試算して計画を立てる必要があります。この際、業務観点での改善構想とシステム観点でのアセスメント、それぞれを実施することが重要です。業務観点での改善構想では、システムに依存しない業務の改善策を検討することで、運用課題の洗い出し、作業環境向上の検討、ビジネスプロセスの見直しなどを進めます。ここで重要なのは、実現性や組織内部のしがらみに捉われず、広く意見を集め「こうなったらいいな」をかたちにしていくことです。そのためこのフェーズでは、IT部門以外に、現場キーマン、中立的な立場のファシリテータの参画、体制構築が成功のポイントとなります。システム観点では、現行環境の設定状況や移行後のシステムに関する深い知識をもとにTo-Beを検討していくことになるため、ユーザのみで進めることは困難です。S/4HANAに移行した場合の影響範囲を確認することから始めるのが基本です。S/4HANAで継続利用できるのか、あるいは改修が必要なのかがわかります。S/4HANAでは利用できなくなるケースがあるため、修正コストと期間を見積もる上で重要な作業となります。ERPと連携している周辺システムの影響範囲を把握することです。国内企業が持つ基幹システムでは、フロントの入力画面や帳票出力、さらには工場で稼働している生産・出荷管理などの機能が別システムで構築され、連携しているケースが多々あります。S/4HANAにマイグレーションするとこれら周辺システムが影響を受ける可能性が高く、アセスメントの際には慎重に調査する必要があります。S/4HANAへの進化において、データ構造が大きく簡素化されたことでパフォーマンス向上が謳われていますが、移行すればシステムのパフォーマンスが必ず上がるとは限りません。S/4HANA向けのチューニングを施すことで、はじめて最適なパフォーマンスが実現します。S/4HANAへの移行企画書を作成します。経営層に上申し、決済を経て本格的な移行プロジェクトがスタート。体制の構築や移行ベンダーの選定に入ります。ベンダーが提供するアセスメントはベンダー各社で手法が異なります。ERPの内部だけで周辺システムの影響調査はサービスの範囲外というケース、単純な影響調査だけで業務改善の評価までは含まれないケースもあります。S/4HANAへの移行ノウハウや実績もベンダーによって差があるため、アセスメントを検討する際には移行作業まで見据えて選ぶのが鉄則です。S/4HANAへの移行を実現するにはどうすればいいのでしょうか。その方法は下記のボタンの先にて示します。S/4HANAのマイグレーションを成功させるための明確なヒントが得られるはずです。S/4HANAのインフラ要件のポイント続いてインフラ面の検討事項を押さえておきましょう。インフラ要件のポイントを記します。柔軟な課金それぞれを簡単に解説しましょう。RDBMSをサポートすることで圧倒的なシェアを維持してきました。S/4HANAがリリースされたのです。HANAのみとなります。HANAはインメモリであることが前提の設計であり、圧倒的な超高速処理を実現しています。DB製品にとどまらない位置づけになっています。DBにも増してミッションクリティカルな存在であると言えます。基幹システムの負荷ピーク基幹システムの利用形態は業種・企業形態によりさまざまですが、一般的に処理負荷の高低サイクル、波が生じます。インフラを検討する上で注意しなければならないことがあります。ERPと同じ発想でアプローチしてはならない、ということです。S/4HANAはインメモリDBを使用するため、当然ながらメモリ上にデータを保持します。これに加えてデータ領域とは別のワークメモリ領域も必要です。そのため、実装すべきメモリ量が従来に比べて大幅に増大するのです。インメモリ処理はI/Oのボトルネックが小さいため、そのポテンシャルを引き出すには、CPUもより高性能なものが求められます。トランザクション処理だけではなく、データ分析も行われることを考えれば、求められる処理能力はさらに増大することになります。データ分析はトランザクション処理に比べて負荷の変動が激しいため、ピーク時に合わせたサイジングですとかなり高性能なハードウェアを用意しなければなりません。S/4HANAサーバーのサイジングにおいては、SAPS値は参考値として利用するにとどめておいた方がいいでしょう。システムランドスケープのことも考えておく必要があります。S/4HANAではそれぞれに必要となるサーバー数が増大する可能性があります。S/4HANAのメンテナンス性を考慮した場合、これらを別サーバーにすることが望ましいからです。Fiori用のサーバーも、別途用意しておく必要があります。ERPと連携して動作する周辺システムをどうするかという問題もあります。S/4HANAサーバーに比べて低いケースが一般的ですが、それぞれ個別にサーバーを立てているのであれば、その維持管理コストが必要になります。S/4HANAへ移行することで、システム基盤のコストが大幅に増大する可能性があります。S/4HANAサーバーに求められるキャパシティを持つインスタンスは利用料が高額になりやすく、周辺システムまでクラウド化した場合はインスタンス数が増大し、ここでもコストが増大することになります。それでは十分なキャパシティを確保しながら、インフラコストを抑制するにはどうすればいいのでしょうか。その秘策は下記のボタンの先にて示します。S/4HANAのシステム基盤をどのように確立すべきなのか、明確な指針が得られるはずでしょう。移行する前に検討すべきポイントとして、下記2つの移行方式と、それぞれのメリット、デメリットを解説しました。つのポイントと注意点についても解説しました。これらを踏まえ、マイグレーションを検討する際は、かかる期間やコストを試算して計画を立てるために、アセスメントの実施が特に重要になることをご理解いただけたと思います。S/4HANAへ最短4カ月で移行するサービス「MOA」を提供しています。マイグレーションを検討する場合は、最短1カ月で実施できる「MOA」のアセスメントサービスを同社に相談してみては如何でしょうか。各社の商標もしくは登録商標です。Corporation。