SAP ERPの「2025年問題」とは？ 概要と対策
人手不足が本格化するといわれる2025年。この年、企業の基幹業務を支えてきた古い「SAP ERP」の保守サポートが終了する可能性がある。導入プロジェクトをけん引してきた人材が不在になる前に検討しておくポイントは？
団塊の世代が一斉退職して人手不足が本格化するといわれる2025年。この年、企業の基幹業務を支えてきたERP製品の1つ「SAP ERP」の古いバージョンで保守サポートが終了する可能性がある。初期のERPブーム時に導入プロジェクトをけん引してきた人材が不在になる前に、いま準備しておくべきことは何か。SAP ERPユーザーにとっての2025年問題と、選択できる対処方法を紹介する。
【更新情報】SAPは2020年2月にERP ERP 6.0のサポート延長を表明しました。詳細は下記記事をご確認ください。サポート終了期日は延長しましたが、移行に際して検討すべき課題に変わりはありませんので、ぜひ本記事も参考にしてください。
▼SAPが「2025年の崖」転落期日を延長、現行ERPは20年保証を明言
https://www.keyman.or.jp/kn/articles/2002/05/news087.html
この記事で分かること
- SAP ERP 2025年問題とは何か
- どうすればよいか〜ミドルウェアを軸に検討する場合の考え方
- データベースシステムの置き換えから考える場合の考え方
- 「サポートが切れても使いたい」勢力を説得する材料にはどんなものがあるか
SAP ERP 2025年問題とは？
所要量計算（MRP）を使った企業資源の管理といった、企業活動の根幹を担う資源の管理についての「ベストプラクティス」をそのまなITシステムに落とし込んだERP（Enterprise Resource Management）。その代表的なツールベンダーの1社がSAPだ。同社の中核は2000年前後から日本企業にも指示されてきたSAP ERPおよび調達や購買などの業務を含むパッケージ「SAP Business Suite」が担ってきた。
このとき、SAPはアプリケーションベンダーであり、利用するデータベースは「Oracle Database」や「SQL Server」といった複数の選択肢が用意されていた。
ところがその後SAPは、独自にインメモリデータベースを開発。その長所を生かして2015年に新たにERPアプリケーション「S/4HANA」を開発した。これは自社インメモリデータベースでの利用を前提とした実装であることから、旧来のSAP ERPユーザーは少なくともデータベースを置き変えるなどの対応が必要になる。
SAPはこの1年前となる2014年に、SAP ERP 6.0、SAP CRM 7.0、SAP SCM 7.0、SAP SRM 7.0を含む「SAP Business Suite 7」や「SAP Business Suite powered by SAP HANA 2013」の保守期限をこれまでの2020年からさらに5年延長し、2025年までサポートすることを表明した。SAPアプリケーションの移行は影響範囲が大きく全社規模での投資になるため、予算面でも工数面でも「すぐに動けない」というのがユーザー企業の本音だ。サポート期間の延長はこの実情に合わせ、ユーザーのIT投資を保護するための措置だ。今にわかに「SAP ERPの2025年問題」として語られる話題はこのことを指している。
実際のところSAPでは「2025年までしかサポートしない」と表明しているのではなく「少なくとも2025年までは投資を保護する」と約束しているかたちなので、4年前と同様に時期が近づいてきたときのユーザーの状況次第では、さらなるサポート延長も可能性としては残している状態だ。
どうすればよいか〜ミドルウェアを軸に検討する場合
基幹業務全般をになうERPの更新となればそう簡単に進む物ではない。計画策定から予算確保、検証などを含む行程を考えると「年」単位の行程となる。
自社データセンターでシステムを運用する企業であれば、アプリケーションの保守が切れるよりも前に、まずはハードウェア更改やデータベースの更新タイミングが訪れるはずだ。
例えば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に移行してしまうパターンだ。この場合は完全にリプレースに近い作業が必要になると考えた方が良いだろう。
この場合はリリースサイクルが非常にタイトになるため、カスタマイズやアドオンは極力排除した形での移行が前提になる。その際は乗り換えそのものの検証やテストスケジュールを引くだけでも重い作業になるのはもちろんだが、その手前で業務フロー変更に関わる各ユーザー部門との折衝に労力がかかるケースが考えられる。
この点については、いくつかの先行企業では「現場から不満の声が上がったとしても半年程度で収束する」という経験則を前提に、一律の更新を行った上でカスタマイズではなく定着のための教育に時間と予算を割く方針をとる向きもある。
一部をS/4HANA Cloudなどのクラウドサービスに移行してから、全体を移行する
同じSAPでも「S/4HANA Cloud」というクラウドサービスがある。
この場合もリリースサイクルが非常にタイトになることはもちろんだが、標準化した機能の提供を前提としたクラウドサービスらしく、原則としてカスタマイズやアドオンは行わない前提で考える必要がある。クラウドの場合も機能追加は高頻度で行われるが、周辺アプリケーションと接続する際のAPIを含め、標準化が進んでいることから、一度移行すれば、バージョンアップなしに使い続けられる。
S/4HANA Cloudの場合は大企業の子会社などでの利用を想定しているため、例えば本社側は「塩漬け」型で2025年までの延命を検討しつつ、導入規模が小さめの組織で実験的に導入しながら業務プロセスを整備したり自社テンプレートを確立したりして全子会社に展開、ゆくゆくは「塩漬け」システムも同じ標準業務プロセスを適用していく、といったアプローチも考えられる。
最終的にS/4HANAを中心に複数組織でERPを共通化しようと考えている場合には、まずは小規模拠点でS/4HANA Cloudの移行をテストし、その成果を各地に展開していく横展開を計画的に進めていけば、長大な工数を割かずに展開できる可能性がある。
既存システムを生かして別のERPシステムに乗り換える
旧来のERPをアーキテクチャが異なるS/4HANAに置き換えることは別プロダクトへの移行といっても過言ではないレベルの変更になる。移行支援環境やアセスメントサービスが充実しているとはいえ、テスト工程などを考えると他のプロダクトに移行する工数とさほど変わらない支出になる可能性もある。
そこで、SQL ServerやOracle Databaseユーザーは、これをきっかけに、SAPのERPを離れて別のERPを選択することも検討できるだろう。アプリケーションの設計思想が異なったり、超大規模エンタープライズへの対応状況がさまざまだったりするが、課題によっては他のERPシステムで、関係会社を含む統合を目指すことも考えられる。
「サポートが切れても使いたい」勢力を説得する材料は？
2025年までの延長が示されたことで、一定の猶予が与えられた格好だったが、サポート切れへの対応というだけで数千万から数億ともいわれるIT投資となれば、移行後の成果はそれなりのものが期待される。予算化に際しては何らかのバリューをうまく示せない場合はサポートなしで使い続けたい、と考える企業も少なからず出てくるだろう。
しかし保守切れの状態では何らかのインシデントやエラーなど業務遂行が不可能な致命的な問題が発生した場合に、大きなリスクが生じる。
S/4HANAに移行する場合は、リアルタイム経営基盤の実現、あるいは2層ERPによる情報統合、IoTとAIで獲得した知見を生かした新しいアプリケーション開発環境の提供など、企業価値を高める施策につながる仕掛けも合わせて検討したおきたいところだ。
他にも在庫情報などと連携するオムニチャネルマーケティング施策のように、従来ERPの周辺にあったアプリケーション類と連携した新しいサービス開発なども検討できるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.