SAPの次は来ないのでしょうか？

テックラウンジ#テック

@SAP

他のスレを見ていて、

・基幹システムは絶対死なせられないので数百億レベルで投資させる

・SAPが長年強い。そしてめちゃくちゃ高い

・JTCが仕事の仕方を変える意思決定しないため、プラグイン開発で多数のお金と年月と不具合を産む

のだと素人ながら理解しました。

ふと思ったのが、クラウドが普及しWebシステム開発も発展した中で、今の風潮に即したWebサービスぽい基幹システムは生まれてきたり、作る余地はないんですかね？

Web開発の思想をイメージしています。

・クラウドネイティブな基幹システム

・既存業務フローにシステムを合わせるのではなく、人がシステムに合わせる

　┗ゆえに汎用性がある、早く入れられ安い

・デザイン使いやすい

・slackと同じくらいの動作保証（ダウンタイムベース）。ただし、本体サービスが落ちた際の業務継続用のバックアップシステムがある

　┗ガチガチの動作担保を一部手放す、落ちる前提で準備しておく

・費用は桁が一つ安い

既に入っている基幹システムから移行できない、システムを出している会社の看板など目下では難しいとは思います。

ただ今後50年で考えたらSAPではなく、

もう少し安くて使いやすい、技術の進化の恩恵を得た基幹システムがあってもいいんじゃないかと思った次第です。

(編集済み)

コメント一覧

おそらく、このあたりの動きが仰っているものに近いのではないかと思います。基幹系を解体して規模が小さなサービスの集合体に変え、アジリティを確保しようとする動きと理解しています。設立時期などの経緯でレガシーを抱えたDNBや、先進的なエンプラ企業が取り組み始めています。

https://techblog.zozo.com/entry/replacing-shipping-system-supporting-zozobase

https://japan.zdnet.com/article/35205117/

前SAPの知り合いと話してたんですけど、下記って全部SAPがやり始めてるところだと思うんですよね〜

・クラウドネイティブな基幹システム

→クラウド化推進中

・人がシステムに合わせる

→いわゆるSAPのFit to Standard

・デザイン使いやすい

→UIをFioriに

・動作保証

→不明

・費用

→クラウド化に伴い、廉価版も販売

となると、結局はネームバリューと導入実績踏まえて、1強が続くかと

Inforとかですかね。Fit to standardとかいってますけど、企業ごとのテンプレートもあるにはありますが、バニラでは使いづらく（というか現場の業務を変えたくないという声を聞きすぎているが故に）、結局それぞれの企業でAdd-onが積み重なり、コストが掛かりますね。

確かSAPさんもパブリッククラウドとかいう、SaaS ERPを推進していくとかをみたような。。

加えて、クラウドのプラットフォームをかなり推しているイメージがありますね。そこにマイクロサービスとして機能がたくさん提供されているのであれば、投稿主様のイメージと少し近そうですな🧐

基幹システムとwebシステムに求める要件が異なるから、web開発に寄せる必要がないのだと思われます。

・クラウドネイティブと言うのは、単にクラウドに載せるとかSaaSを使うという意味では無く、要件に応じて柔軟に変更を加えてデプロイをガンガン掛けてく事や、スケーラブルな処理を柔軟にさばくシステムにする事を指しますが（コンテナ化などして）、基幹システムは要件が日々変わるようなものでも無いし、ユーザーは社員数が上限でスパイクアクセスがあるようなwebとは異なります。なのでそのアプローチの必要性がそもそも少ないとも言えます。

・デザインが使いやすいと良いのは、今初めて作ったシステムがそうなら嬉しいですが、70年代の汎用機で動作してた時代のトランザクションコード（SAP上においてユーザーが入力するコマンド）で慣れてるユーザーからしてみたら、それが今変わるのは煩雑です。SAPGUIという操作画面が変わるのもそうです。またSAP自体が、Javaや.NETで追加の画面を開発できる環境等は以前から提供はしてますし、FioriといいうHTML5のweb系のGUIを開発するプラットフォームもあり、全くの非オープンシステムだけでは無くやってきてます。

（続き）・高可用性については基幹システムでは重要で、クラウド登場以前に手を尽くしていました。信頼度の高い高価なハードウェアを用い、ホットスタンバイでレプリケーションさせ瞬時にフェールオーバーさせる事を、オンプレミスでやっているイメージです。この辺りはAWSのマルチAZやOracleのData GuardやGoldenGateの同期テクノロジーをクラウドで実装することで、クラウド時代に利点を得てきてたのでは（つまりクラウドの新テクノロジーを使うのではなく、既存テクノロジーをクラウドに適用というアプローチ）。SAPの最新のS/4 HANAでのこの辺りはキャッチアップしてないので分かりません（スイマセン）。

ともかく、長いSAPの歴史で既存資産として何があるのか（技術者のエコシステム含む）、基幹業務として求められる要件は何が（非機能含む）で考えてゆくと、現状の状態にありweb開発化しないのはうなずける感じです。

有識者現る。お金払わずこれを見られるのすごすぎませんか……？？

コメントはユーザーに削除されました。

そんな価値ありますか、このコメントに？ 🤣

業界が違うだけで、それぞれの方がそれぞれの専門性をお持ちで価値もそれぞれなだけで、この情報が絶対的に高い価値があるというほどでも無いですよ

SIerに勤めてるのに何となく技術っぽいことしてるだけで、最近ようやく本格的に勉強し始めた身としてはかなり分かりやすくて参考になります！！

ありがとうございます。

グローバルに大規模展開していないようなMid Market未満向けのERPなら幾つか選択肢が出てくるかもしれませんが、それ以上の規模だと各国の会計基準とか法規制に合わせた云々とかに対応する難易度が高くて厳しいのではないか、という印象ですね。

あと、フロント領域の柔軟さは要求される機会があるものの、先の投稿者様のコメント通りERPソフトウェアが充足するコア機能(SoR領域)は一度固めれば基本的にそうそう頻繁に業務が変わる事がないのでAgility確保へのニーズが薄く、

信頼性のほうが重視されると思います。

むしろ変化の多い現場向けフロント領域はSalesforceやServiceNOWのようなエンタープライズ向けのノーコード/ローコードのプラットフォームでアプリを作って対応し、後ろでSAPに繋ぐという整理/位置関係にあるように思えます。

(編集済み)

この整理/位置関係に腹落ちしました。SoR SoE とか言われましたが、見込みとか今現在進行中を管理したいフロントエンドはまた違ったアーキテクチャになるでしょうし、よりスクラップアンドビルドしやすいプラットフォームでアジャイルに使える事を現場は要求するでしょうね。でも野良化、スモールDBでサイロ化、運用管理者が業務兼任で疲弊とか別の課題が出てきていますね。