見出し画像

日経コンピュータ2025.02.20

日経コンは2週間に1度、年に52週÷2=26冊出る雑誌です。
2010年から全号精読して面白かった記事をザッピングしています。
※はブログ筆者のコメントです
★全文は、ここからお読みください

特集は<SAPのクラウドシフトで複雑化 終わらない「2027年問題」>です。SAPの導入失敗のニュースも多く流れていますが、SAPに替わるERPも見当たらない状態ですので企業は対応せざるを得ないのでしょう。


【SAPのクラウドシフトで複雑化 終わらない「2027年問題」】

独SAPのERPのサポート期限切れである2027年まであと2年。ユーザは後継版の「S/4 HANA」に移行する必要がありますが、最近SAPが急激にクラウドシフトしているためさらに複雑になっています。
1.半数が間に合わない クラウドシフトで混乱
ガードナージャパンが2024年3月に実施した調査では5割以上の企業がS/4HANAへの移行方針や時期を決めていません。
(1)2023年オンプレミス(導入型)ライセンスを原則販売しない
 →全く販売しないわけではないが値引せずクラウドに誘導
(2)RISE with SAP:アドオンソフトが利用可能
 →SAP、AWS、GCP選択可能
(3)GROW with SAP:アドオンソフトが原則利用不可
 →SAPに加え2024年12月3日にAWSを発表
2.ピークは2030年か 移行遅らす3つの課題
現時点では90%の企業がRISEを利用しています。GROWは新規導入の企業が選ぶことが多いです。移行の課題は3つ
(1)移行方法についての判断が複雑
 Brownfield:SAP ERPのアドオンやパラメータそのまま
 →GROWは不可。RISEでもアドオンが実質上移行困難
 →2年ごとにメジャーバージョンアップがある
 Greenfield:業務プロセス標準化など新規導入
 Bluefield:必要なデータだけを選択して移行
(2)パートナーの人材不足に拍車がかかっている
 SAPはコンサルタントを「1年数千人規模」で増やしている
 SAPだけでなくクラウドのインフラエンジニアも足りない
(3)オンプレのS/4HANA導入済の企業が「RISEリフト」
 標準サポートの提供期間を7年と設定。
 2023年導入企業は2030年がピークになり人手不足加速
3.追加は最小、外出しも F2Sの「新しい形」
※この章だけは日本TCSのメンバが書かれています
Fit to Standard(F2S)を目標したプロジェクトが軒並み上手く進んでいません。F2Sを素早く適用するコツを解説します。
F2Sには2つの進め方があります。
(1)S/4HANAを標準機能の範囲で利用する
 →業務オペレーションを変えるコンサルを行う
(2)アドオンは作るが最小限にする
 1)標準でカバーできるか確認してもらう
 2)業務オペレーション変更で対応出来るか検討
 3)S/4HANA以外のシステムで対応出来ないか検討
 4)どうしても無理な時だけアドオン開発
重要なことはプロジェクトメンバ全員にF2Sを理解してもらうことです。開発コストだけでなく稼働後の影響なども認識してもらいます。

※「標準でカバーできるか確認」と言うのは簡単ですが、現状業務をどう整理してSAPの動きをどう可視化するかが問題です。SAPから逃げ出す選択肢も報道して欲しいです。イトーキがSAPを損切りしてORACLE Fusionを導入したことは良い事例です

【「長期記憶」を持てるAIエージェント ソフトバンクGがオープンAIと開発へ】

年間30億ドルを支払い、まずはグループ内に展開
ソフトバンクGとオープンAIは2025年2月3日、企業用のAIエージェント「クリスタル・インテリジェンス」の開発・販売で提携することを発表しました。

企業内のあらゆるシステムのソースコードやデータを学習し、経営の中核として自律的に業務を代行する事を狙います。その場で企業内の情報を検索するRAG(検索拡張生成)と異なり「AIの長期記憶」も踏まえた上で正しいアドバイスを出します。

まず第1号ユーザとしてソフトバンクG内にある2500のシステムをすべてクリスタル・インテリジェンスに学習させAIエージェントを経営の中核に据える予定です。その後1業種1社程度に絞って展開します。

※短期記憶の海馬から長期記憶の大脳皮質に保存して判断に使うというイメージでしょうか。日本発という事が嬉しいです。

【ケーススタディー:クレディセゾン】

基幹システムとつながる「社内API基盤」をクラウド上に内製したことでボトルネックが解消され、デジタル施策のスピードが向上しました。

基幹システム「HELIOS」と接続する旧API基盤はオンプレミスサーバーで稼働しており、スケールが難しくアクセス集中の時は流入に制限をかけるなど苦労していました。

2020年7月に更改プロジェクトを始動。当初はインフラ基盤はITベンダーに依頼しメインフレームのz/Linux(IBM System z上のLinux)を採用、アプリケーションのみ内製していました。2021年3月から開発フェーズに入り、11月ごろシステムテストの段階でインフラの性能が出ないことが判明し、追加で数億円分の機器が必要になりました。

そこで2021年12月にすでに購入済のz/Linux数億円を捨てAWSに切り替えました。大きなトラブルなく2022年7月のリリースに間に合いました。これによりスマホアプリの処理速度も改善、新機能追加も月1回以上出来るようになりました。

ランニングコストもメインフレームだった時の年間4.8億円から1.3億円にまで改善されました。しかもHELIOSを大手国内企業に外販することも出来ました。システム運用も請け負うため5年で150億円の売り上げを見込みます。

※これこそDXの典型だと思います。そういう視点で記事が書かれていないことが残念です。ITイノベーションの中山嘉之氏の資料のP.10でいうと3段階まで来ています。

究極のDXは自社の新システムをサービス化(販売)すること

次はプラットフォーマーでしょう。

他にも面白い記事が多くありました。お時間が許す時に、ここからお読みください。

以上

いいなと思ったら応援しよう!