多くのSAPソフトウェアーのユーザーにとって、SAP ECC6.0の保守期限が残り４年となってきました。SAP社は、2027年までのECC6.0の保守期限としていますが、2025年から2027年に延長するためには、SAP EHP6以上が適用されている必要があると、皆様もかなりご理解いただいているのではないかと思います。私が直接会話をさせていただいている、日本の多くのECC6.0ユーザーは、EHP6が適用されていないことも多く、さらには、ユニコード対応もされていない会社もいらっしゃると思います。もしも、なんとかSAP S/4 HANAにアップグレードしてしまえば、しばらくは安泰と思っている皆様、そこ本当ですか？
私は、S/4 HANAが悪いソリューションであるとは思っていません。技術屋の私からすると、システムアーキテクチャー的には、おもしろいシステムであると思っています。もし、皆様がS/4 HANAに価値を感じていらっしゃるのであれば、バージョンアップも一つのオプションだと思っています。ただ、「価値は感じていないけど、SAP社のロックインから外れるのは少々怖い」と思われている皆様、もし、アップグレードを考えられるのであれば、注意をしなくてはいけないポイントがあります。
SAP ECC6.0というバージョンは、ある意味特殊なバージョンでした。それ以前のバージョンにおいては、５年前後のサイクルでのバージョンアップを必要とされていました。ECC6.0はおおよそ20年という長い期間、SAP保守が継続され、SAP社がECC6.0を発表したときに、EHPといった考え方を導入し、お客様にビジネス上必要があれば、その機能だけEHPを適用してスイッチオンしてくださいというコンセプトが適用されました。これは、お客様がビジネス上不要なバージョンアップを抑制し、リソース（人、お金、時間）をビジネスの優先順位に基づいたIT投資に大きく寄与してきたと思っています。
しかしながら、SAP社はS/4 HANAにおいては、EHPという考え方をなくし、以前と同様にユーザーが必要かどうかに関係なく、保守期限は５年で終了するといった考え方に戻しています。つまり、S/4 HANAにバージョンアップした後も、5年ごとにバージョンアップを行う必要が出てきます。例えば、2015年に発売された、S/4 HANA 1510に関しては、昨年末保守期限が切れていますし、S/4 HANA 1611に関しては本年末には保守期限を迎えます。つまり、S/4 HANAのお客様は、20年近く前に発売されたECC6.0より先に保守期限を迎えてしまうといった逆転現象が発生しているのです。
最近、とあるS/4 HANAのユーザーとお話をする機会がありました。その企業は、まもなくS/4 HANAの保守期限を迎えるにあたり、バージョンアップの見積もりを行った結果、予想を大きく上回るコストがかかることが判明しました。このコストには、いくつかの要因が含まれており、一つは2025年（あえて、2027年ではなく2025年と書きます）に向けて、SI企業におけるリソースが不足していることにあると言われました。これにより、時間当たりの単価が急騰しており、お話をお伺いするに「以前と同様の単価では提案してもらえなくなった」との声も聞こえてきております。また、ECC6.0からそのまま持って行ったアドオンが、バージョンアップ工数を増加させることにもなっていると言われました。さらに、テスト工数に関しては、S/4 HANAへバージョンアップするのにかかるのと同等の工数が発生するものと思われます。
では、S/4 HANAからS/4 HANAの新バージョンへのバージョンアップリスクを抑制するためにはどうしたらよいでしょうか？ベンダーはバージョンアップツールにより、安くバージョンアップできるようになりました」とお伝えするかもしれません。この「安い」バージョンアップはブラウンフィールドというテクニカルアップグレードを想定しており、つまり、現在皆さんお持ちのアドオンもそのまま持ち込まれます。ECC6.0からS/4 HANAへのバージョンアップはグリーンフィールドより安く済むのかもしれませんが、S/4 HANAへ行ってからの５年ごとのバージョンアップに苦しみ続けることになると思っておりますではどうしたらよいのか。もし、S/4 HANAに価値を理解して、S/4 HANAへのバージョンアップを決めた方がいらっしゃったら、ぜひとも下記項目に注意いただきたいと思います。
まずは、S/4 HANAはいままでやってきた、アドオンやモディフィケーションといった手法はとらずに、S/4 HANA自身は「そのまま」使うことを推奨します。といっても、ユーザーにとって拡張なしで使うというのは正直現実味がないかと思いますので、拡張は必ず外のプラットフォームに作成し、S/4 HANAの標準インターフェイスを活用して疎結合するようにすることが大事だと思っています。こうすることにより、S/4 HANA-S/4 HANAバージョンアップ時のアドオン問題は解決できるかと思います。そう考えてしまいますと、オンプレミス※３でのS/4 HANAデプロイメントを選択する理由は大きく減りますよね。もし、完全にこのアーキテクチャーへ移行するのであれば、マルチテナンシーのSAP S/4 HANA Cloudもターゲットに入ることと思います。つまり、ブラウンではなくグリーンフィールドで、完全に拡張開発を排除した導入をしないと、５年ごとにバージョンアップ問題に向き合うことになります。
次のポイントとしてはテストです。私も昔は導入コンサルを行っていたことがありますが、どうしてもプロジェクトが忙しくなるとテスト計画がおろそかになってしまったという反省を持っています。慌ててテスト計画を作ると、自動化も難しくなりますし、じゃあ、どこまでOKなら本稼働していいのかといった判定にも苦しむことになるかと思います。S/4 HANAの5年ごとのバージョンアップを乗り切るためには、まずテスト方針の明確化と自動化が重要な課題になるのではないかと思っています。まず、方針を作成するときに、このテストをすべて実行したら合格とし、その他の障害に関しては本稼働中に対応を行っていくといったことを明確にすることです。また、そのステップを自動化することにより、テスト工数は大幅に削減することが可能と思っています。もし、これがなされないままS/4 HANAへ持って行ってしまうと、毎回同様のテスト工数が発生することとなり、これも5年ごとのバージョンアップ時に頭を悩ませることになるかと思います。
まず、みなさんに考えていただきたいのは、今の一時しのぎのためのブラウンフィールドバージョンアップはやめましょうということだと思っています。これだけDXが叫ばれている中で、この場しのぎのバージョンアップを行い、本来投資をしなくてはいけない領域に対して投資ができなくなるのは本末転倒だと思っています。もし、S/4 HANAの価値を理解し、そこが企業の第一プライオリティーである場合は、おのずとブラウンフィールドはあり得ませんよね。
ガートナー社の調査※１によりますと「基幹システムの改良／刷新」への投資に関して、日本企業のCIOの59%が投資を増やすと回答しているのに対し、世界での割合はわずか36%であり、10%は削減すると回答しています。経済産業省の「DXレポート２」※２においても、バージョン2を出した問題意識の一つが「DX＝レガシーシステム刷新」という間違ったイメージの修正にあるという点を指摘してあげるのが重要だと思います。
そこで、もう一度考えてみてください。将来、みなさんの企業が将来ERPの最新化のプライオリティーが高まることもあるかと思います。その時にもしS/4 HANAが一番皆さんに価値を生むソリューションであったなら、もし、私がお話しした「そのまま使う」アーキテクチャーを理解いただけたのであれば、SubscriptionでS/4 HANA Cloudを選択されればよいのではないでしょうか？
今、経済産業省も含め日本のDXの出遅れには危機感を持っています。（経済産業省DXレポートより）もし、皆さんのDXがERPの更新でないのであれば、今はバージョンアップを見送り、みなさんのDXに投資をしてみてはいかがでしょうか？ リミニストリートは最低１５年、ECC6.0をお預かりさせていただきます。
※１（https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20210201）
※２（https://www.meti.go.jp/press/2020/12/20201228004/20201228004.html)
※３ 弊社では、シングルテナンシーCloudでのS/4 HANAデプロイメントも含めてオンプレミスと定義づけています。