SAP ERPの「2025年問題」とは？　概要と対策

　自社データセンターでシステムを運用する企業であれば、アプリケーションの保守が切れるよりも前に、まずはハードウェア更改やデータベースの更新タイミングが訪れるはずだ。

　例えば2013年6月にリリースされた「Oracle Database 12c Release 1」ならPremier SupportとExtended Supportを使っても2021年7月が期限となる。Oracle Database同様、SAP ERPのバックエンドで広く使われているSQL Serverの場合はSQL Server 2008が2019年に保守サポート切れとなる。

　ここで、次の更新ではデータベースシステムをどこに置くかが問題になる。SAP ERP問題は「基幹業務のデータベースシステムをどうするか」という問題と考えることもできるだろう。

　例えばSQL Serverを使い続けたい場合はSQL Serverごと対応したパブリッククラウドに移行しておけば、場合によってはクラウド移行支援のディスカウントを適用して低コストで運用できたり、延長保守サポートを受けられたりする可能性もある。そこから時期を見てHANA用の大容量メモリ搭載型のインスタンスに切り替えるようにすれば、まずはハードウェア入れ替えに関わるコストも考慮しなくて済むようになる。

　一方で、ここでデータベースをHANA切り替え、S/4HANAに一足飛びに移行する場合にはクリアすべき課題が幾つか存在する。1つは既存アドオンやカスタマイズ、独自開発の機能の対処だ。もう1つは独自のインメモリデータベースアーキテクチャのシステムに移行するため、ある程度はSAPのプロダクトポートフォリオを活用する前提でうまく周辺機能も取り込む利用方法を構築できるか、という点だ。

データベースシステムの置き換えから考える選択肢

　さて、それではSAP ERPのライセンス切れを前に、将来的なERPの置き換えを前提にインフラやミドルウェアをどう切り替えていけるだろうか。ここではいくつかのケースを見ていこう。

オンプレミスでデータベースシステムごと乗り換え、S/4HANAに移行する

　データベースなどのシステム更新のタイミングで何らかの移行を検討する際、最も分かりやすいのがSAP HANAに移行してしまうパターンだ。この場合は完全にリプレースに近い作業が必要になると考えた方が良いだろう。

　この場合はリリースサイクルが非常にタイトになるため、カスタマイズやアドオンは極力排除した形での移行が前提になる。その際は乗り換えそのものの検証やテストスケジュールを引くだけでも重い作業になるのはもちろんだが、その手前で業務フロー変更に関わる各ユーザー部門との折衝に労力がかかるケースが考えられる。

　この点については、いくつかの先行企業では「現場から不満の声が上がったとしても半年程度で収束する」という経験則を前提に、一律の更新を行った上でカスタマイズではなく定着のための教育に時間と予算を割く方針をとる向きもある。

図2　S/4HANAのリリースサイクル Release strategy for 2018／2019 and definition of deliveries

一部をS/4HANA Cloudなどのクラウドサービスに移行してから、全体を移行する

　同じSAPでも「S/4HANA Cloud」というクラウドサービスがある。

　この場合もリリースサイクルが非常にタイトになることはもちろんだが、標準化した機能の提供を前提としたクラウドサービスらしく、原則としてカスタマイズやアドオンは行わない前提で考える必要がある。クラウドの場合も機能追加は高頻度で行われるが、周辺アプリケーションと接続する際のAPIを含め、標準化が進んでいることから、一度移行すれば、バージョンアップなしに使い続けられる。

　S/4HANA Cloudの場合は大企業の子会社などでの利用を想定しているため、例えば本社側は「塩漬け」型で2025年までの延命を検討しつつ、導入規模が小さめの組織で実験的に導入しながら業務プロセスを整備したり自社テンプレートを確立したりして全子会社に展開、ゆくゆくは「塩漬け」システムも同じ標準業務プロセスを適用していく、といったアプローチも考えられる。

　最終的にS/4HANAを中心に複数組織でERPを共通化しようと考えている場合には、まずは小規模拠点でS/4HANA Cloudの移行をテストし、その成果を各地に展開していく横展開を計画的に進めていけば、長大な工数を割かずに展開できる可能性がある。

図3　S/4HANA Cloudのリリースサイクル

既存システムを生かして別のERPシステムに乗り換える

　旧来のERPをアーキテクチャが異なるS/4HANAに置き換えることは別プロダクトへの移行といっても過言ではないレベルの変更になる。移行支援環境やアセスメントサービスが充実しているとはいえ、テスト工程などを考えると他のプロダクトに移行する工数とさほど変わらない支出になる可能性もある。

　そこで、SQL ServerやOracle Databaseユーザーは、これをきっかけに、SAPのERPを離れて別のERPを選択することも検討できるだろう。アプリケーションの設計思想が異なったり、超大規模エンタープライズへの対応状況がさまざまだったりするが、課題によっては他のERPシステムで、関係会社を含む統合を目指すことも考えられる。

「サポートが切れても使いたい」勢力を説得する材料は？

　2025年までの延長が示されたことで、一定の猶予が与えられた格好だったが、サポート切れへの対応というだけで数千万から数億ともいわれるIT投資となれば、移行後の成果はそれなりのものが期待される。予算化に際しては何らかのバリューをうまく示せない場合はサポートなしで使い続けたい、と考える企業も少なからず出てくるだろう。

　しかし保守切れの状態では何らかのインシデントやエラーなど業務遂行が不可能な致命的な問題が発生した場合に、大きなリスクが生じる。

　S/4HANAに移行する場合は、リアルタイム経営基盤の実現、あるいは2層ERPによる情報統合、IoTとAIで獲得した知見を生かした新しいアプリケーション開発環境の提供など、企業価値を高める施策につながる仕掛けも合わせて検討したおきたいところだ。

　他にも在庫情報などと連携するオムニチャネルマーケティング施策のように、従来ERPの周辺にあったアプリケーション類と連携した新しいサービス開発なども検討できるだろう。