目次
はじめに
SAP ECC 6.0の標準保守は2027年末に終了します。追加費用による2030年末までの延長保守という猶予はあるものの、「いずれS/4HANAへ移行しなければならない」という本質は変わりません。
それでも、多くの企業がまだ移行に踏み出せていません。私たちは、これを決断力の問題だとは考えていません。日々お客様のSAP基盤と向き合う中で実感するのは、移行に踏み出せない企業には、それぞれに固有の、そして十分に合理的な事情があるということです。本コラムでは、私たちが現場でよく耳にする4つの事情を取り上げ、それらをどう軽減・解決できるのかを考えます。
投資に見合う価値を見出せない
S/4HANAへの移行には、ライセンス体系の変更、HANAデータベースを前提としたインフラコスト、移行プロジェクトそのものの費用と、負担が確実に増えます。一方で、経営層に説明できる効果が「保守切れの回避」だけでは、単なる技術更新の稟議になってしまい、決裁が下りにくい。「動いているシステムに、なぜ今それだけの費用をかけるのか」という問いに答えられない。これは担当者の怠慢ではなく、現行システムが安定稼働しているからこその、真っ当な悩みです。
移行に必要なダウンタイムを確保できない
統合のような特別な要件のない、単純なコンバージョンであっても、S/4HANAへの移行には相応のシステム停止が必要です。SAP標準ツールを利用した方式では、移行元システムの状況にもよりますが3日程度の停止が一つの目安になります。さらに、ノンユニコードのシステムでは先にユニコード化が必要となり追加で1〜2日、移行先がRISE with SAPであればSAP側の作業タスクが加わってさらに1日程度。積み上げていくと、想定以上に長い停止計画になります。24時間止められない基幹システムを抱える企業にとっては、この停止枠を業務側と合意すること自体が高いハードルです。結果として、切り替えは年末年始やゴールデンウィーク、夏季休暇といった長期休暇に限られ、その枠から逆算してプロジェクト全体を組み立てざるを得ない。一度タイミングを逃せば次の機会は半年後となり、スケジュールが休暇カレンダーに縛られてしまうのです。
乱立したインスタンスを統合したいが、標準の枠では収まらない
事業部門ごと、地域ごと、あるいはM&Aの経緯から、複数のSAPインスタンスを並行運用している企業は少なくありません。それぞれをそのままS/4HANAへ移行すれば、費用も運用負荷もインスタンスの数だけ膨らむため、「このタイミングで統合すべきだ」と考えるのは自然なことです。ところが、複数インスタンスの統合や会社コード・組織単位でのデータの組み替えといった変換は、SAP標準ツールが想定する移行方式の守備範囲を超えています。統合と移行を同時に成し遂げる手立てが見えず、道筋を描けないまま検討が止まってしまうのです。
肥大化したデータと、法定保存の板挟み
長年の稼働で蓄積されたデータは数TB〜数十TBに及びます。これを丸ごと新環境へ移せば、移行期間もHANA基盤のコストも跳ね上がる。かといって、会計データには電子帳簿保存法をはじめとする長期保存義務があり、監査や税務調査への対応を考えれば安易に削除もできません。そのため「移行後も参照用に旧ERPを残す」という判断になりがちですが、それはサーバ費用・運用工数・SAPライセンス費用を二重に払い続けることを意味します。
それぞれの事情に、SNPソリューションという打ち手がある
これらの事情は、我慢するしかない制約ではありません。私たちがSNPのソリューションを活用するのは、まさにこうした事情を軽減・解決できるからです。
SNPのプラットフォーム「Kyano」とBLUEFIELDアプローチ(選択的データ移行)は、「今のシステムを丸ごと移す」のではなく、必要なデータとプロセスだけを選んで移すという発想に立っています。
まず、投資対効果に悩む企業にとって、このアプローチは移行の意味づけそのものを変えます。移行と同時に不要データの削減やプロセスの見直しを行えるため、プロジェクトの位置づけが「保守切れ対応」から「IT資産をスリム化し、次の変化に備える投資」に変わります。事前分析によって移行スコープと効果を定量的に示せることは、経営層への説明材料としても大きな意味を持ちます。
ダウンタイムの壁も、技術で低くできます。SNPツールを用いた移行では、システムを稼働させたままデータを先行して移送し、切り替え時には差分のみを反映する方式が取れます。これにより切り替えに伴う業務停止を大幅に圧縮でき、通常の週末の枠でも移行が現実的になります。効果は停止時間の短縮にとどまりません。長期休暇から逆算してプロジェクトを組み立てる必要がなくなるため、準備が整い次第すぐにプロジェクトを開始し、適切なタイミングの週末に切り替える、という進め方が可能になります。スケジュールを休暇カレンダーから解放し、柔軟に設計できるのです。
インスタンスの統合についても同様です。SNPツールはテーブルレベルでのデータ変換を得意としており、複数インスタンスの統合や組織単位でのデータの組み替えといった、SAP標準ツールでは難しい変換を、S/4HANAへの移行と同じプロジェクトの中で実行できます。事前のシステム分析で各インスタンスのデータ構造やカスタマイズの実態を可視化できるため、「どこから、どの順で」という道筋を、勘ではなく事実に基づいて設計できます。
そして、肥大化したデータと法定保存の板挟みには、役割分担で応えます。現行業務に必要なデータは選択的にS/4HANAへ移し、過去データはSNP DataFridgeによってクラウドDBへ移管する、という考え方です。過去データはS/4HANAの専用画面から従来と同じ操作感で参照でき、保存期間管理などの機能により法定保存要件にも対応します。つまり、監査・税務対応を維持したまま旧ERPそのものを廃止し、二重の維持コストを解消できるのです。
なぜBeeXがご支援するのか
SNPのソリューションは、SNPの強力なツール群によって支えられています。しかし、実際のプロジェクトでそのツールの性能を引き出せるかどうかは、使い手の技術に大きく左右されます。移行先となる基盤の構築やネットワーク・性能の設計といったインフラ領域と、システムコピーやデータ変換、ジョブ・権限の整備といったBASIS領域が密接に絡み合いながらプロジェクトが進むからです。
実際の移行作業では、この2つの領域の境界にこそ落とし穴があります。インフラ担当とBASIS担当が別々の組織やベンダーに分かれていると、どちらの責任範囲とも言い切れない課題が「エリアの溝」に落ち、プロジェクトの停滞や品質低下を招きかねません。
BeeXは、クラウドインフラとSAP BASISの両方を深く理解したエンジニアが緊密に連携する体制でプロジェクトに臨みます。だからこそ、領域をまたぐ課題を溝に落とさず、SNPツールの力を最大限に引き出すことができます。そのうえで、"with customer"の精神でお客様に伴走し、事情を理解するところから、アセスメント、移行計画、実行、移行後の旧システム廃止まで一貫してご支援します。
おわりに
「まだ移行していない」ことには理由があり、その多くには、今や打ち手があります。まずは自社の事情を言葉にし、現状を可視化するところから始めてみませんか。その最初の一歩から、私たちはご一緒します。
