「S4 HANAでクラウド化」No2.SAP HANAへの移行はコンバージョンかリビルドか
INDEX LINK
■はじめに
SAP Freelance Jobs運営事務局です。
現在稼働しているSAPをS/4 HANAに移行するにあたってのアプローチには、「コンバージョン」と「リビルド」があります。言葉からある程度の意味は推測できるかもしれませんが、システム開発者でなければ確実に理解することは難しいでしょう。
今回はそれぞれがどのような手法であるのかと、S/4 HANAへの移行を検討する際のポイントについて解説します。また、近年は移行先としてクラウドサービスを選択する企業が多いため、こちらの選択肢についてもご説明します。
■S/4 HANAのコンバージョンとは
コンバージョンとは現在稼働しているSAPのアドオンプログラムやカスタマイズを活用しつつ、S/4 HANAへと移行する手法を指します。既存のSAPをそのまま利用することができないため、「一部のデータを変換して」S/4 HANAに取り込むとイメージすると良いでしょう。SAP社をはじめとして複数のベンダーが専用のツールを提供しているため、それらを活用してデータを変換します。
S/4 HANAへの移行にあたってコンバージョンを採用する際は以下のようなポイントを意識することが重要です。
- 準備コストを抑えやすい
- テストが簡略化できる
- 既存の業務をそのまま引き継ぎやすい
- S/4 HANAの新機能の恩恵を受けにくい
SAPを活用して新しくS/4 HANAを構築するため、後ほど説明するリビルドよりもコストを抑えやすい傾向にあります。また、既存の機能をそのままS/4 HANAで利用できるため、業務の変更が少なくテストもスムーズに実施しやすい魅力があります。
ただ、既存のSAPをベースにS/4 HANAを構築するため、S/4 HANAで新しく搭載された機能がうまく活用できないかもしれません。例えばS/4 HANAはシステムの高速化が図られていますが、利用しているアドオンの設計によっては恩恵を受けられないのです。コンバージョンは良くも悪くも既存のSAPに縛られる部分が出てしまいます。
■S/4 HANAのリビルドとは
リビルドとは現在稼働しているSAPとは別に新しくS/4 HANAを構築し、そのSAPを中心とした業務を再考する手法を指します。現在のSAPにとらわれることなく、S/4 HANAの機能を存分に発揮できる手法だとも言い換えられます。現在のSAPにおいて「SAPが業務フローに適していない」と感じるならば、リビルドを検討すると良いでしょう。
S/4 HANAへの移行にあたってリビルドを採用する際は以下のようなポイントを意識することが重要です。
- 新機能を存分に手に入れられる
- 保守性の悪い現在のSAPを手放せる
- アドオンが多いと業務フローが大きく変化する可能性がある
- ユーザーに利用教育が必要となる可能性が高い
新しいSAPを導入することになるため、基本的には業務フローの見直しから始まります。現在のSAPで多くの運用をしていると思われますが、それを忘れてS/4 HANAを中心とした業務フローを考えるのです。場合によっては業務フローを一新する可能性があります。
ただ、新機能を活かした業務フローを検討するため、導入コストが高まったりユーザーの教育が必要となったりします。現在、SAPを運用しているとはいえどもS/4 HANAはまったく異なった製品であるため、それなりの負担は見込まなければならないのです。
■S/4 HANAへ移行する際の検討ポイント
S/4 HANAへの移行が求められていますが、ご説明したとおりコンバージョンとリビルドの選択肢があります。これらはどちらが良いとは一概に言えず、以下の観点から検討しなければなりません。
- アプリケーションの変化
- リスクの許容
- 移行コスト
それぞれのポイントについて具体的に何を検討しなければならないのか、具体的にご説明します。
1.アプリケーションの変化
新しくSAPを構築するにあたって、アプリケーションの変化をどの程度許容できるのか検討が必要です。今まで利用しているSAPECCとS/4 HANAにはアプリケーションで大きな違いがあるため、業務影響などからどうすべきか判断が必要です。
まず、コンバージョンを選択すると、アプリケーションの変更は最小限に抑えられます。現在のSAPに実装されている機能をそのまま利用できる場合もあり、バージョンアップしてもユーザーはそれに気づかない場合があるぐらいです。「アドオン」と呼ばれるプログラムを大量に作成し、自社に特化したSAPを構築しているならば、コンバージョンを選択した方が良いかもしれません。
逆に、リビルドを選択すると、アプリケーションは最新のS/4 HANAに変化します。ユーザーインターフェースや機能が最新のものに変化するため、利便性の向上が期待できます。現在普及しているSAPが公開されてから日が長いため、大きな変化を感じられるでしょう。
ただ、SAP社が新しい機能を実装したり古い機能を削除したりしているため、業務で利用する機能が変化の対象であると大きなインパクトを与えかねません。また、自社の業務に合わせてアドオンを開発しているならば、これがS/4 HANAでは動作しない可能性もあります。新しいアプリケーションが手に入る反面、改めて教育が必要となるなどの手間が生じる可能性が十分にあります。
現在のアプリケーションを中心に考えるか新しいアプリケーションを中心に考えるかに明確な答えはありません。どちらにも良い点と悪い点があるため、自社として「どこに重きを置くか」を明確にし方針を決定すると良いでしょう。
2.リスクの許容
一般的にシステムの移行にあたっては一定のリスクが発生します。そのためどのようなリスクが発生するのかを理解し、そのリスクをどこまで許容できるのか検討しなければなりません。例えば、S/4 HANAのような基幹システムを移行する際には以下のリスクが考えられます。
- 要件が曖昧で移行後のシステムで業務が滞る
- 移行に失敗して業務に影響が出る
- システム移行が長引き担当者の負担が増える
- トレーニングが間に合わない
万が一このようなリスクが顕在化してしまった場合、業務に何かしらの影響を与えるのは言うまでもありません。最悪、社内だけではなく取引先や関係各所にも迷惑をかけてしまう可能性があります。不安を煽るような表現かもしれませんが、システム移行はそれぐらい大げさにリスクを認識し、どこまで許容できるかを考えなければなりません。
3.移行コスト
システム移行にはまとまったコストが必要となり、特にS/4 HANAのように大規模なシステムへの移行は様々なコストが発生します。プロジェクトによって発生するコストには差が生じますが、例えば以下のようなコストを意識しておく必要があります。
- ソフトウェアのライセンス費用
- ベンダーへの発注費用
- 社内でのシステム検討費用
- 社内での移行プロジェクト対応費用
まず、ベンダーへの発注費用はコンバージョンかリビルドで大きく変化します。基本的にはコンバージョンの方が安価で済み、リビルドを選択するとまとまったお金が必要となってしまいます。これはコンバージョンよりもリビルドのほうが対応すべき事項が多いからです。
また、意識してもらいたい費用は社内での対応コストです。多くのプロジェクトでライセンス費用やベンダーへの発注費用は見積もりを取りますが、社内での費用は忘れられがちです。基幹システムの移行にはベンダーだけではなく利用者側の協力が多く求められるため、十分に余裕を持ったコストを見積もっておくことが移行の成功に繋がります。
■S/4 HANAをクラウドで構築する場合どうすべきか
S/4 HANAをクラウドで構築する場合、コンバージョンもリビルドも選択肢としては考えられます。どのようなクラウド環境を構築するかによって検討しなければなりません。
まず、AWSなどのパブリッククラウドにS/4 HANAを構築するならば、自由にSAPのカスタマイズが可能です。必要に応じてS/4 HANAをカスタマイズしてコンバージョンしたり、業務フローの見直しを兼ねてリビルドしたりできます。上記でご説明したポイントを踏まえて、どちらが適しているかを検討すると良いでしょう。
また、クラウドにはSAP社が提供するSAP HANA Cloudと呼ばれるものもあります。こちらは自分自身でSAPを構築する必要はないものの、SAP社が設定した環境を利用しなければなりません。つまり、リビルドに近い使い方しかできなくなります。
パブリッククラウドにS/4 HANAを構築する際は大きな心配をする必要はありません。しかし、クラウド化にあたってSAP HANA Cloudを利用したいならば、制限がかかりやすいため注意しておきましょう。
■まとめ
既存のSAPからS/4 HANAへと移行する方法についてご説明しました。大きく分けてコンバージョンとリビルトの選択肢があるため、まずはこれらの選択肢について正しく理解しておきましょう。
両者について理解した上で重要となるのは、どちらの方式を選択すべきかという部分です。どちらの方法にも良い部分と悪い部分があるため、十分に比較して決定しなければなりません。
また、クラウドに移行するにあたってSAP HANA Cloudを選択するならば、リビルドに近い移行しかできなくなります。この点は注意したいポイントであるため、こちらのサービスの利用を検討する際は移行にも影響すると意識しておきましょう。
