SAP2027年問題で懸念される企業のビジネスリスクへの対応
私は、「社員が主役のワークショップ型DX」をDXコーディネーターとしてご支援する会社の代表をしています。
普段は、メンバーと共に企業のDXプロジェクト推進支援をする傍ら、時折ビジネス研修やDX人材育成研修のトレーナーとして、大企業やベンチャーのビジネスパーソン育成に携わっています。
詳しくは自己紹介をご覧ください。
プッチンプリン発売再開はまだ未定(2024/6/3現在)
先日以下記事を作成する際にご紹介したご隠居_むらたんさんに、私の記事を紹介して頂きました！（お礼が遅くなりまして申し訳ありませんでした…)
また、ご隠居_むらたんさんの記事の中で、私たちが自社で取り組んでいることにも触れて頂き誠に恐縮です。ありがとうございます！
例の江崎グリコのシステム障害ですが、この記事を書いている2024年6月3日現在、まだプッチンプリンの出荷再開の見込みは立っていない模様のようです。
関係者の苦労は察するに余りありますが、グリコにとっては主力商品でもありますから、1日も早い出荷再開を祈ります。
さて、先日は少し厳しめトーンでグリコの件を書いたことで、弊社メンバーに「書きぶりが厳しすぎだ」と叱られまして、今後は少し抑え目に、穏やかに書いていこうと反省しております….。
とはいえ、本当に思っていることはあまり隠せないタイプなので、言いたい事はそれなりに、今後もnoteを書いていこうとも思っています。
ユニ・チャームでも発生したSAPの障害
今回の記事ですが、SAPの話が私の周囲でも盛り上がっていることもあり、SAPの2027年問題で起こるビジネスリスクをテーマに話してみようと思います。
今回はたまたま江崎グリコ社システム障害の話が大々的に報じられましたが、メディアに取り上げられなくとも、それなりの規模でSAPをはじめとする基幹系システム系の障害事案は頻繁に発生しています。
またもデロイト社が担当する案件だとバレてしまっていますが（情報流失大丈夫なの…）、ユニ・チャーム社の以下のような記事が出ていました。
上記記事内の外資と国内を単純比較するステレオタイプな分析はともかく、事実としては以下の通りです。
ユニ・チャームは5月16日、一部商品について注文集中による出荷が遅延している旨をアナウンスしていたが、27日付「日経クロステック」記事によれば、ゴールデンウイークに実施した基幹システムの更新で新基幹システムと物流システムの接続でデータ連係に不具合が生じたという。
Copyright © Business Journal All Rights Reserved.
要するに、基幹システムの更新でシステム間のデータ連携がうまくいかず、製品の出荷遅延などが発生したという話。
なお、この基幹システムが「SAP S/4HANA」であることは関係者が明かしています。
2024年6月3日時点の以下記事では、データ連係の不具合とデータ処理の遅延はほぼ解消したとの事ですが、楽天の直営ECは引き続き利用できないようです。
SAPユーザーが直面する2027年問題
あまりネガティブな想定はしたくないですが、今後もこういった事案は各社で頻発するものと私は考えています。というのも、SAPは2027年に大きなマイルストーンが待っていまして、ユーザー各社とも対応期限が差し迫っています。
俗に「2027年問題」と言われており、これまで多くの企業で使われてきたSAP ECC 6.0(以前はR/3と言われていました)の保守サポート終了が2027年末に迫っているためです。SAPとしてはビジネス的にも次バージョンの「SAP S/4HANA」に移行してもらいたい中で、ユーザー企業に選択を迫っている格好になります。
ユーザーに与えられた3つの選択肢
「もうサポート無くなっちゃうから色々リスクあるなー」ということで、ユーザー企業は強制的に「SAP S/4HANA」に移行しなければならないのかというと、実はそんなこともありません。ユーザーにはいくつか選択肢があります。
NECソリューションイノベータ社のWEB記事がよくまとまっていたので以下引用します。
選択肢① 『SAP S/4HANA』へ移行
『SAP ERP 6.0』（ECC 6.0）から最新版『SAP S/4HANA』への切り換えはSAP社も推奨している選択肢です。
最新版ならではの優れた機能や、クラウド化といった恩恵を享受でき、ビジネスの意思決定の加速に貢献します。
ただしシステムの移行には、要件定義やアセスメント、PoC、アドオンの最適化など少なくない高度なプロセスがあり、発生するさまざまなコスト（資金的／人的／時間的）を踏まえたデジタル戦略の構想策定が求められます。
またシステム移行を機にアドオンを含めた業務プロセスを見直すことで、抜本的な業務改革であるBPR（Business Process Re-engineering：ビジネスプロセス・リエンジニアリング）を図ることができます。
選択肢② 移行せず継続して利用
あえて既存の『SAP ERP 6.0』（ECC 6.0）を使い続けるという判断も可能です。
現在の保守基準料金に2%追加することで、保守期限を2030年末まで伸ばす延長保守サービスも用意されています（Enterprise Supportだけでなく、Standard Supportのユーザーにも提供。
ただし“EhP6”以上を導入していることが条件）。また、第三者による保守サービスを受ける選択肢もあります。
システム基盤を刷新しないため業務面で混乱を起こすことはありませんが、機能が拡張されることもありません。
デジタル戦略において最適化を進めている競合他社からは後れを取る恐れがあります。
選択肢③ 他のERPサービスへ移行
このタイミングでSAP製品の利用を終了し、クラウドベースのERPサービスも含めた幅広い選択肢の中から新たな基幹システムを選択するという方法もあります。
ただしその場合は、ERPシステムの選定から開発、導入に至るまで多大なコストが発生します。
また過去に蓄積したデータや知見、ノウハウが活かせなくなる恐れもあるでしょう。
運用マニュアル作成や社内教育の負担も考慮して、構想する必要があります。
「SAPの2027年問題とは？移行の注意点を解説」
https://www.nec-solutioninnovators.co.jp/sp/contents/column/20220325_sap-2027-issue.html
まとめると、
選択肢①：「新バージョンのSAPにする」
選択肢②：「現バージョンのSAPをそのまま使う」
選択肢③：「SAP以外のものに乗り換える」
以上の3択ということです。
一部企業は別ベンダーへの移行を選択する可能性もあると思いますが、多くの企業では多額の費用をかけて新しいSAP S/4HANAへの移行が想定されています。
現在はその移行特需とも言える状態で、SAP移行祭りがコンサルティング会社やSIerを今後もしばらく潤わせることでしょう。。
ただ必ずしもSAPの目論見通りにならない面もあると言われていて、そのまま古いバージョンを利用する企業も多いのではないかと想定されています。
「保守サポートが終わっちゃうのにどうするの？！」と感じた方もいらっしゃるかと思いますが、少しだけ費用を上乗せすれば2030年まで保守サポートを延長できるオプションをSAPは提示しています。（なんとかその間にSAP S/4HANAへ移行を決断してもらいたいわけです）
サードパーティのサポートを前提にそのまま旧バージョンを使う企業も一定数存在
これは私が知り得る限りの事例からの推測ですが、社内でSAP旧バージョンを導入する際に、ガチガチにカスタマイズされた業務プロセスに従業員が長年馴染んでおり、今から新バージョン、もしくは別システムに切り替えることがビジネス上のリスクを増大させると感じている企業も一定数おり、そのまま旧バージョン利用を続けるものと思われます。
そんな企業のために、サードパーティ(not SAP)の保守運用専門ベンダーも現れており、その中でも代表的なリミニストリートという会社はエンタープライズ系の主要ソフトウェアの保守サポートでグローバルに活動しています。
日本国内でも、一部の企業は引き続きSAP旧バージョンを引き続き利用することを前提に、リミニストリートのようなサードパーティに既に保守運用を委託しているようです。
システム移行の投資対効果(ROI)を最大化できるかはリスク対応次第
基幹システムが止まると、今回の江崎グリコ社やユニ・チャーム社のようにビジネスのコア部分に大きな影響を与えますから、システム移行については、そのリスクとシステム移行によるリターンも踏まえて意思決定を各社行うこととなるでしょう。
システムの投資対効果(ROI)を最大化するには、効果だけに目を向けるのではなく、リスクの重大性を十分に分析した上で、どの程度自社にてコントロールが可能なのかにも目を向けておくことが重要です。
移行を選択する場合もそのまま使う場合も、リスクは早い段階から取り除いておく、もしくは対策を取っておく必要があります。
これも別記事でいつか1記事書こうと思うのですが、プロジェクトは夢や理想論で進めると、大抵の場合炎上を生みます。計画が夢物語になると、その先は悲劇しかありません。
プロジェクトリスクを十分に直視した上で、いざシステムが止まってもビジネスに重大なリスクが生じないよう、業務継続(Business Continuity)を常に考えておくことが本当に大切になってきます。
私はコンサルティング会社に在籍していた際、自治体の業務継続計画(BCP)策定に携わったことがありますが、もし基幹システムがなかったとしても自治体としての使命をどこまでどう果たすべきかは、なかなかの難題でした。
余談ですが、私が策定に関わったのは地震対策のBCP(ちなみに策定直後に、東北の震災が発生しました)だったのですが、耐震調査したらサーバールームの床が抜けるという調査結果が出て、「どうすんのよこれ…」と関係者で途方に暮れたことを思い出します。。
システム移行に向けて業務継続の観点からビジネスリスクの最小化が重要
何を申し上げたいかというと、どんなリスクが顕在化したとしても、ビジネスリスクを最小化してビジネスを継続するプランを常に持っておくことが特に社会的影響力の大きなビジネスを持つ企業にとっては重要です。
今回はたまたま2社のシステム障害事例がオープンになっていますが、果たしてどこまでビジネスの継続性に関してリスクをコントロールできていたのか、起きてから慌てて対応を考えていなかったか、実態が気になるところです。
ユーザーがベンダーに委託した際の開発作業や運用作業においては、不測の事態をユーザーとして想定した上でベンダーとプロジェクトについて詰めをを細かく行うと共に、良い意味ではベンダーを信用しすぎず自社でも業務継続に関する対策を準備しておくことが、来たるSAP2027年問題への対応として非常に重要となるでしょう。
結局、本日も長文となってしまいましたが、最後まで読んで頂きありがとうございました。