00:00:00 SAPの失敗がこの深い探求を引き起こす
00:02:15 ERPで失われた数十億ドル—それは氷山の一角に過ぎない
00:06:15 レガシーデザインの間違いが現代のシステムを苦しめる
00:10:20 ERPの拡大の背後にある土地の取得ロジック
00:12:26 CRUDアプリケーションとERPの商品化
00:16:30 HANAはSAPの分析への戦略的な転換点でした
00:20:38 なぜ表形式のデータベースがレポート作成に失敗するのか
00:26:23 列指向データベース：利点と隠れたコスト
00:30:21 RAMへの賭けは失敗した賭けです
00:34:31 ハイブリッドデータベースでのパフォーマンスの衝突
00:40:41 ハイブリッドソフトウェアはすべてに失敗する
00:42:33 インテリジェンスシステム：第三のパラダイム
00:46:59 初期のERPは誤って知的と宣伝されました
00:52:33 なぜS/4HANAは一度にすべてのことができないのか
00:58:43 CRUDでのGoogleの失敗は文化的な不一致を示しています
01:05:02 プログラム可能性は意思決定システムの鍵です
01:10:38 オールインワンアプローチの経済的失敗
01:16:30 なぜERPの近代化が遅くて高価なのか
01:22:06 プロセスだけでなく意思決定を最適化する
01:27:24 独自の記録レイヤーの構築に関するアドバイス
01:34:13 オープンソースと商品技術の真のコスト
サマリー
LokadのConor DohertyとCEO Joannes Vermorelの間で行われた洞察に富んだ議論では、SAPのソフトウェア導入に関連する財務上の問題について掘り下げられています。 Vermorelは、記録システム、レポートシステム、インテリジェンスシステムを1つのERPソリューションに統合することの基本的な問題を明らかにし、これにより効率が低下し、衝突が生じます。彼らは、DHLやLidlなどの企業が経験したSAPの欠陥戦略、特にHANAの統合による高額な失敗を強調しています。 Vermorelは、専門システムやPostgreSQLなどのオープンソースソリューションを提唱し、これらは低コストで堅牢な機能を提供し、複雑で効果のないソフトウェアの統合から企業を遠ざけます。
拡張サマリー
最近の情報によると、主要な企業がSAPソフトウェアの導入に伴う多数の財務上の損失に関連しています。LokadのコミュニケーションディレクターであるConor Dohertyは、LokadのCEO兼創設者であるJoannes Vermorelと対談し、エンタープライズソフトウェアの設計の課題や野心的でありながらも欠陥のあるSAP戦略の落とし穴についての深い議論を行いました。彼らの会話は、企業ソフトウェアの設計の課題や野心的でありながらも欠陥のあるSAP戦略の落とし穴についての豊かで啓発的な分析を提供しています。
Vermorelは、企業が使用するソフトウェアシステムの微妙な違いについて説明しています：記録システム、レポートシステム、インテリジェンスシステム。企業がこれら3つの異なるシステムを1つのソフトウェアパッケージ内に統合しようとすると、必然的に衝突や効率の低下が生じます。このシナリオは、SAPがERPソリューション内にHANAなどの基本的に互換性のない要素を組み込んだことによって具体的に示され、結果として時間の経過とともに重大な戦略的および運用上の障害が生じています。
SAP関連の失敗例は驚くほど多いです。Conorが挙げたように、DHL、Lidl、Spar、Asdaなどの企業は、SAP ERPの導入により数億ドルに及ぶ損失を報告しています。これらの損失は、システムのアップグレードに専念した長期間中にこれらの組織が経験したより大きな経済的停滞の一部に過ぎません。Vermorelは、このような事業が近代化の取り組みを凍結し、他のデジタル進展を阻害し、これらのプロジェクトの真のコストを著しく膨らませることを指摘しています。
問題の核心は、Vermorelが主張するように、SAPが数十年前に行った基本的な決定にさかのぼります。SAPはもともと記録システムに焦点を当てており、企業の運用の包括的な側面をカバーすることを目指した洗練された電子帳簿である「ランドグラブ」戦略は、広範囲なスコープをもたらしましたが、CRUD（作成、読み取り、更新、削除）操作の商品化ももたらしました。2000年代初頭には、レポートシステムへのシフトが始まり、洗練されたが複雑な分析ツールが生まれました。
SAPが行った重要な選択の1つは、分析能力を向上させるために設計された列指向のインメモリデータベースであるHANAを統合したことですが、これはトランザクション処理の基礎としては適していませんでした。Vermorelは、この戦略的な失敗が広範な影響を及ぼし、コアプロセスの遅延や、管理するために広範で高コストな過剰エンジニアリングが必要となるパフォーマンスの問題を引き起こしたことを詳しく説明しています。
インタビューでは、異なるソフトウェアシステムの設計ニーズとの間の固有の衝突に触れています。記録システムは高速で高信頼性のトランザクション処理を必要とし、レポートシステムは広範なデータ分析機能を要求します。これらをインテリジェンスシステムと組み合わせることは、プログラム可能性を通じて意思決定を自動化しようとするもので、ソフトウェアアーキテクチャをさらに複雑にします。このジレンマは、優れた飛行機であり素晴らしいボートである車両を構築しようとすることに例えられ、劣ったハイブリッドに終わる運命にあるとされています。
Conorは、ソフトウェアソリューションを選択する際の機械的同情の役割を取り上げます。つまり、ソフトウェアの固有の特性や制約、例えば表形式と列形式のデータベースの違いを理解することです。このような基本的な知識は、企業が高額な決定から逃れるのに役立つ可能性があります。
Vermorelの前向きなメモは、PostgreSQLなどのオープンソースソリューションの可能性を強調しています。彼は、これらの利用しやすく堅牢なシステムを活用し、SAPの誤りによって示された落とし穴を回避するための実現可能な道を提案しています。
結論として、VermorelとDohertyの議論は、野心的なソフトウェアソリューションが多様な機能を1つの屋根の下に統一することを約束している一方で、そのような統合はしばしば不必要な複雑さとパフォーマンスの問題を引き起こすことを強調しています。企業は代わりに、特定のニーズに合わせた専門のシステムを検討すべきであり、高度なエンジニアリングの卓越性を提供するオープンソースの豊富な提供物から利益を得るべきです。この会話は、企業がデジタル変革を進める際に、経済的に有害であることが証明されている歴史的な誤りを回避しながら進むための指針となります。
フルトランスクリプト
Conor Doherty: Lokadへようこそ。最近、非常に大きな企業がSAPの導入で非常に多額の資金を失ったというニュースを受けて、Joannesと私は座って、具体的に何が間違っていたのかについて話し合うことにしました。Joannesは、エンタープライズソフトウェアの設計の背後にある課題や、記録システム、レポートシステム、インテリジェンスシステムの違いについての彼の見解を説明しています。Joannesが主張するように、企業が1つのソフトウェアでこれら3つをすべて生産しようとすると、問題が発生し始めます。
今回も、お聞きになりたい場合は、YouTubeチャンネルに登録して、LinkedInでフォローしてください。それでは、今日の会話をお届けします。では、ジョアネス、ブラックロッジで私に参加してくれてありがとう。少しテーブルを設定しましょう。
イントロでは、非常に大きな企業が非常に多額の資金を失った理由の1つを認めました。今回この会話をすることになった理由は、チャンネルの友人であるAnthony MillerがLinkedInでややバイラルになった投稿で、多くの場合、数十億ドル規模の企業がSAPの導入による数億ドルの損失を報告している数字をまとめたことです。
つまり、引用するか要約すると、DHLはSAPとIBMのソリューションを導入しようとして3億7000万ドル以上を失ったとのことです。ドイツのリドルは、アイルランドではリドルですが、大陸ではリドルですが、アイルランドではリドルですが、5億ユーロを費やした後に実施を中止しました。つまり、5億ユーロを費やした後に実施を中止しました。
オランダのチェーンであるSPARは、SAPの導入により1億9000万ドルの売上損失を被ったと主張しています。つまり、導入の結果です。ASDAは、SAP ERPとWMSの間で2,550万ドルの在庫の不一致を報告しました。他にもありますが、ここで言いたいのは、これが10億ドル以上または10億ユーロ以上の損失であるということです。つまり、取るに足らない金額ではないということです。
では、質問です。ジョアネス、これらの巨大企業と彼らのSAPの導入で具体的に何が間違っているのでしょうか？
Joannes Vermorel: 明らかに、すべての問題の共通点は、間違ったベンダー、SAPを選んだことです。しかし、残念ながら、これらの数字はアイスバーグの一部に過ぎません。実際、私自身の簡単な観察では、損失は桁違いに大きく、これらは人々が認めているものです。つまり、実際のコストを認めていません。
たとえば、彼らは、うーん、何かがうまくいかなかったことにお金を払ったと認めるだけです。彼らが認めないのは、通常、多くのプロジェクトに数年かかったプロセスであることです。実際、会社は、ERPのアップグレードに焦点を合わせる以外に何もできない時期が半年間、時には10年間凍結されていました。
つまり、何百万ドルを無駄にするだけでなく、実際にはそれは小さなことです。なぜなら、実際に行ったことは、すべての近代化、デジタル化、進行中の変革を一時停止したということです。そうでなければ、ERPのアップグレードに気を取られることなく、できたはずのすべての近代化、デジタル化、進行中の変革を一時停止したということです。何度も何度も見てきましたが、企業がこれを実現するためにすべてを一時停止するような数年間のプロセスに取り組むことがあります。コストは絶対に巨大です。
つまり、それは明らかに、彼らがこのプロセスを生き延びるためには、その会社の品質の証明です。ソフトウェア業界では、自分の開発を半年間一時停止する人は、実際には死んでしまうでしょう。つまり、彼らは、彼らよりも3世代先のテクノロジーで置き換えられるものによって置き換えられるでしょう。ですから、これらの企業が生き残ることができるということは、彼らが自分たちのゲームを絶対的にマスターしているということです。そのような機能不全のプロセスで長期間生き残ることができるのです。
現実は、見通しが非常に悪いです。この共通点の背後に行くと、SAPを責めることでは問題が明らかになりませんので、根本原因を調査したいと思います。私が言う「間違い」とは、ビジネス上の決定なのか、それともソフトウェア上の間違いなのか？「間違い」と言うとき、何を意味しているのですか？
Conor Doherty: 「ビジネス上の決定」ですか、それとも「ソフトウェア上の間違い」ですか？「間違い」と言うとき、何を意味していますか？
Joannes Vermorel: 私が言う「間違い」とは、SAPの人々が数十年前に犯した戦略的な設計上の間違いです。それらの失敗は数十年前に犯された間違いに遡ることができます。そして興味深いことに、これらの失敗を分析すると、責任のゲームになります。「インテグレーターが良くなかった」または「企業での変更管理が正しく行われていなかった」または「企業のIT部門が適切なレベルに達していなかった」など、言い訳が続きます。言い訳ばかりです。
そして実際、すべての失敗は毎回独自のように見えます。しかし、これらは満足のいく説明ではありません。これらの問題がなぜ発生するのか本当に理解したいと思うなら、それは非常に大規模なエンタープライズソフトウェアベンダーに特有のものです。数十年前に行われた決定に遡ることができる明確な根本原因があります。今、その結果が明らかになっています。
観客は気づかないかもしれませんが、ソフトウェア会社を運営するときは、非常に長い間、おそらく永遠に、過去の間違いとともに生きなければなりません。それは非常に奇妙です。なぜなら、ソフトウェアは完全に変更可能だと思うかもしれませんが、現実は異なります。
一般的に、建築上の決定に関しては、間違いを犯すと、それに永遠に囚われる可能性があります。そして、それらの間違いは永遠にあなたを苦しめ、あなたが行っているすべてを毒します。人々は症状を見ますが、それを根本原因に遡ることは必ずしもありません。根本原因は頻繁に非常に古いため、人々がそれに気づかないことがよくあります。
Conor Doherty: さて、記録上、SAPは50年以上前に遡る巨大な企業です。ですので、数十年前の根本原因や戦略的な設計上の選択について話すと、2025年にこれらのエラーと共に生きることは、非常に極端な主張であり、非常に特別な証拠が必要です。1970年代の戦略的な設計上の選択の例を挙げていただけますか？それが2025年のSAP ERPを苦しめているものの一例を教えていただけますか？
Joannes Vermorel: そうですね、SAPは70年代後半に始まり、私がシステムの記録と呼ぶものです。それがERP、CRM、WMSなど、会社で起こっていることの電子的な対応物と言われるものです。これらの記録システムには知能がなく、私は、ファンシーな元帳だと言います。過去に戻ると、成功したベンダーは最も多くの土地を獲得したものでした。
何が「土地を獲得する」と言うのか？在庫を管理し始めると、従業員を管理する必要があり、その後、注文、支払い、調達、顧客、サプライヤー、パートナーなどを管理する必要があります。アイデアは、記録のために可能な限り広範囲なカバレッジを持つ必要があるということです。過去にさかのぼって、80年代とします。この土地獲得競争が進行中でした。現実は、ある企業が主要なベンダー（当時はSAP、Oracle、IBMなど）を採用し始めると、その企業内で勝者独占効果が生じるということでした。
あなたはクライアント企業であり、ベンダーからソフトウェアを運用しています。このベンダーと取引を始めると、ほとんどのビジネスをこのベンダーに向けることになります。なぜなら、当時、分散ソフトウェアのエンジニアリングは絶対的でした。すべてのソフトウェアが同じメインフレームに存在しないと、困難な状況になりました。理論的には、ネットワーキングを行うことができました（80年代にはそうでした）、一部の銀行がその当時それを行っていましたが、それは非常に複雑で非常に高価でした。
現実的には、在庫やサプライヤーを管理し、つながりを持たせるための経済的に実行可能な唯一の解決策は、すべてを同じシステムに組み込むことでした。したがって、勝つためのベンダーはすべてをカバーしなければなりませんでした。それが最終的に成功するベンダー、ERPやCRMと呼ばれるものを開発する人々を作り出すものでした。これらの大規模なシステムが成功したのは、広範囲なカバレッジを持っていたからです。それは何を意味するのでしょうか？可能な限り多くの土地をカバーする必要があり、最終的にはすべてに触れることになります。
現実的には、ハイパー一貫性やハイパーインテグリティを持つインセンティブを作り出すことはあまりありません。本当に重要なのは、可能な限り速やかに可能な限り多くの土地を手に入れることです。その過程で、大規模な企業が気づいたのは、CRUD（作成、読み取り、更新、削除）アプリケーションは完全な商品であるということです。その過程で、ソフトウェア業界はこのプロセスが完全な商品であることに気づきました。レコードシステム、CRUDアプリケーションを持ちたい場合、非常に簡単です。
関係データベースとフレームワークが必要で、各エンティティに対して一連のビューを提供し、すべてのエンティティに対してCRUD操作を実行するためのユーザーインターフェースを提供する必要があります。クライアントを作成、更新、削除することができます。クライアント、サプライヤー、請求書などについても同様です。非常に速く、これらのベンダーはこのものが完全な商品であることに気づきました。土地の獲得フェーズは2000年代にほぼ終了しました。 2000年まで、すべてがカバーされていたわけではありません - 新しい分野が現れていました、たとえば、電子商取引など。
当時はそうではなかった。それを追加する必要があります。常に新しいものがありますが、ほとんどの土地の獲得が完了していました、それが問題です。 SAPのようなベンダーは、商品化が非常に強くなっていることに気づきました。レコードシステムは簡単で、安価でなければなりません - 非常に安価でなければなりません。したがって、技術を販売している場合、利益とマージンをどのように維持するのでしょうか？完全な商品である技術を販売している場合。
そこで彼らは希望を見出しました：レポートシステム。 90年代半ばに、Business Objectsという会社が登場し、OLAP（オンライン解析処理）技術を販売する最初の大規模な成功を創出しました - レポートシステム。 これは大成功でした。 Business Objectsは2006年または2007年にSAPに買収されました。 人々は、価値はおそらくレポートシステムにあると気づきました。当時はそれがファンシーに見えました。
明らかに、電子レコードとは異なり、データベースにお客様に関するすべての情報があると、あなたの価値は限定されてしまいます。あなたはビジネスに電子的な相手を提供することになっています。ビジネスの満足のいく電子的表現を持ってしまえば、追加することはあまりありません。データベース内の製品、クライアントなどを説明するために追加できることは限られています。要するに、分析への動きがあります。 SAPはそれに気づき、2010年からHANAでこの第2段階に全力を注ぐことを決定しました。
それが、私にとって、今日のほとんどの問題の核心であると思います。私はそれがHANAに向かっていく決定から来ていると考えています。当時のこの決定に戻ると、SAPには依然として戦略的な問題がありました：第三者のデータベースへの依存。 2000年代には、彼らは主にOracleデータベースに依存しており、MicrosoftやIBM DB2に少し依存していましたが、主にOracleに依存していました。 これは、その時点でERPであるSAP ECCやその他のスイート（多くの製品と買収を含む）が第三者のデータベースに依存していたことを意味しました。
これは問題でした、なぜなら価値の大部分が別のソフトウェア会社に行ってしまっていたからです。商品化のため、縮小する市場で競争することは問題でした。 SAPは独自のデータベースレイヤー、コードネームHANAを展開することに決めました。彼らはこの分析方向に強く進出したいと考えていたため、列指向でインメモリのシステムを目指しました。 この決定だけで、2010年当時、エラーが発生しました。
ERP S4は2015年にのみリリースされました。したがって、新しいデータベースシステムを持っている場合、新しいデータベースの上に自社のERP技術を数年かけて再構築する必要があります。しかし、時間を遡ると、今起こっているエラーの核心はHANAに遡ることができます。今、もう少し理解する必要があります。少し複雑なので、ここで何が起こっているかを説明するのに少し時間がかかるかもしれません。
記録システムに必要なのは、行ごとにデータが整理された伝統的なデータベースであるタブラーデータベースです。タブラーデータベースとは何でしょうか？データが行ごとに整理されたテーブルを持つデータベースです。コンピュータシステムでは、参照の局所性がパフォーマンスに非常に重要であることを心に留めておく必要があります。つまり、データのコレクションにアクセスしたい場合、パフォーマンスを得るためには、すべてのデータがシステム内の同じ場所に配置されている必要があります。
例えば、サプライヤーを更新したいとします。サプライヤーには、名前、場所、認証など、多くの情報があります。システム内のサプライヤーエンティティの属性をすべて考えることができます。それはテーブルになります。おそらく「サプライヤー」というテーブルがあり、このテーブルには数十、おそらく百の列があるかもしれません。したがって、データベースをタブラー形式で構成すると、サプライヤーを選択すると、サプライヤーが表示されます。
特定のサプライヤーからのすべての情報は、システム内の同じ場所に集約されます。更新したい場合も同様です。データのタブラー表現がある場合、行を追加したり削除したりするのは非常に簡単です。これらのことはすべてきちんと集約されています。うまく機能します。したがって、タブラーデータベース、記録システムにとっては完璧です。
しかし、分析には完全にダメです。それが問題です。それがタブラーデータベースのクソさです。それがビジネスオブジェクト、ビジネスインテリジェンスツールなどが最初に成功した主な理由です。それは、90年代に、データベースの隣に存在するOLAP、つまりキューブ、ハイパーキューブを提供し始めたためです。それらは、データベースの隣に存在し、分析を提供するのがはるかに便利です。
なぜそうなのでしょうか？考えてみてください。注文というテーブルがあるとします。注文テーブルには、例えば、ドルで表現された金額である1つの列があります。しかし、注文テーブルには他にも100の列があります。今、昨年の売上金額を計算したいとします。実際には、昨年の売上金額を計算したい場合、つまり列の合計を知りたい場合、タブラーデータベースを持っている場合、ほぼテーブル全体を解析することができます。システムはすべての行を通過しますが、その結果、金額列を特定することができません。なぜなら、それは他のすべての列の中心に完全にあるからです。
この1列の追加を計算するために、システムはテーブル全体を見ることになり、それはおそらく各行ごとに必要な情報の数百倍になるかもしれません。システムを大幅に遅くします。しかし、解決策があります。それは、データベースを列指向のセットアップに整理することです。それは何を意味するのでしょうか？データを行ごとにグループ化するのではなく、列ごとにパックすることです。
突然、列を選択して、「この列にあるすべてを合計したい」という操作を行いたい場合、その列に単独でアクセスできるため、非常に高速になります。注文テーブルに見つかる注文ID、クライアントID、製品IDなどの他のすべての列を持つ必要はありません。必要なのは1つの列だけです。日付の選択を行いたい場合も同様です。日付列を選択してフィルターを適用することができます。
これは桁違いに効率的になります。それは非常にクールです。ところで、この列指向のセットアップは、歴史的には、企業の分析を始めたときに、人々がハイパーキューブ、つまりOLAPテクノロジーで始めたことです。しかし、2000年代末までに、人々はすぐに列指向のデータベースの方が優れていることに気づきました。したがって、テクノロジーの観点から見ると、ビジネスオブジェクトがハイパーキューブを扱っていた時期があり、テクノロジーは非常に速く、それを上回るバージョンである列指向のデータベースに変わっていきました。
さて、列指向のデータベースは分析にはずっと優れています。ですので、すべてのレポートシステムにとっては素晴らしいニュースです。観客にとってはずっと良いものがあります。ちなみに、列指向のデータベースは、例えば、列指向のデータベースを提供するオープンソースの実装であるSparkです。
それは取り扱うのが信じられないほど大きいものであり、パフォーマンスの面でも非常に効率的です。しかし、これはトレードオフがあることを意味します。そのトレードオフは、列指向のデータベースは記録システムには全く向いていないということです。つまり、設計上、それは2つの面で問題があります。まず、データを列で整理すると、行を更新するたびに多くの列に触れることになります。すべての列で正しい位置を特定する必要があり、もし列が100あるなら、システム内で更新する場所が100箇所あることを意味します。
過去には、表形式のデータベースでは、1回の更新で済んでいたことが、ここではデータが列で整理されています。ですので、レコードを更新したい場合、多くの列に分散されることになります。それは桁違いに効率が悪くなります。再び、ここには無料の昼食はありません。データを表形式のシステムとして整理するか、それとも列指向のシステムとして整理するか、どちらかを選択する必要があります。記録システムには表形式が最適であり、レポートシステムには列指向が最適です。どちらも同時にはできません。
SAPはHANAに全面的に取り組むことを決定しましたが、それは列指向のデータベースでした。それが、記録システムであるすべての取り組みに終止符を打った決定だったと思います。
Conor Doherty: わかりました、たくさんの内容をカバーしていたので、ありがとうございます。ただ、今この瞬間にこれを聞いている人として自分を置いてみると、「DHLやSpar、Asdaが、列指向と表形式の分析エラーのために、合計10億ドル相当の在庫やお金を失ったと主張しているのですか？それが問題の根本原因なのですか。そう主張しているのですか？」
Joannes Vermorel: 大部分においては、はい。つまり…
Conor Doherty: それを裏付けてください。
Joannes Vermorel: はい、重要な設計上のミスがあると、何千もの副作用を引き起こす傾向があります。何かが非常に混沌と複雑であるからといって、その根本原因自体が非常に複雑で混沌としているわけではありません。例えば、地球の自転です。地球は太陽に比べて軸が傾いており、これが季節の変化、暑い時期と寒い時期、風などを引き起こす超複雑なシステムをもたらし、これらはすべてこの単純な傾きの結果です。
ですので、非常に単純な根本原因があることがありますが、その結果が非常に複雑で多様であることを見ると、それは非常に複雑なものであり、それでも非常に単純なものに遡ることができます。
Conor Doherty: 私も同意します。素敵な天文学の例ですね。
Joannes Vermorel: ここでは、分析にはプラスであるが、記録システムにはマイナスであるという決定を下すことで、非常に遅いシステムを作成してしまいました。ここで、2010年にSAPが行った賭けを見ることができます。彼らは列指向だけでなく、インメモリにもしました。これは別の間違いでした。インメモリにするという考え方は、すべてのデータがサーバー用のRAMであるDRAMに保存されるということです。
当時の考え方は、DRAMが将来非常に安くなり、はるかに速くなるだろうというものでした。ソフトウェア企業は、「現在パフォーマンスの問題があるが、正しい決定をすれば、ハードウェア業界の進歩が将来この問題を無効にしてくれるだろう」と言う傾向があります。彼らは、計算機ハードウェアが正しい方向に向かって100倍速くなるか、より良くなるかどうかを信じています。その場合、現在のパフォーマンス問題は数年以内に解消されるかもしれません。
Microsoftは長い間それを行っていました。彼らはほとんどのマシンでうまく動作しないソフトウェアをリリースし、数年後にはすべてが速くなり、ソフトウェアが正常に動作するようになりました。問題は、2010年以降、RAMが15年間ほど進歩していないことです。進歩はありましたが、他のすべてと比較してほんの少しであり、特にSSDなどの他のデータストレージ形式と比較してほとんど進歩していません。
RAMはほとんどコスト面、速度面、レイテンシ面、すべてにおいて微動だにせず、一方でソリッドステートドライブ（SSD）は同じ期間に1000倍以上進化しました。そのため、この技術が桁違いに進化することを期待して全力を尽くしましたが、それは実現せず、おそらく多くの理由で実現しないでしょう。他の分野ではコンピュータサイエンスが猛烈に進歩しています。
AIに使用されるGPUは著しく進化しています。他にも進化が著しい分野がたくさんありますが、この分野は進化していませんでした。そして、もしデータベースを列指向にしてシステムを実行することで犠牲を払うなら、レイテンシがひどくなるだけです。
事が設計上の問題であることはほぼ確実です。そして、それは既に表形式の設計のボトルネックで問題になっていました。それはすでに問題でしたが、ここではそれをはるかに悪化させています。つまり、その結果として、不正確なアーキテクチャによって最初に引き起こされたすべての問題を緩和するために常に消火活動を行うことになります。
Conor Doherty: まあ、それは完璧な移行を示しています。なほど私が言おうとしていた言葉をほとんど取り上げていました。さっき説明したことを適用するだけで、記録システムとレポートシステム、つまり、記録システム、ERP、具体的なユースケースでは、バーコードをスキャンしてシステムが更新され、倉庫にあるものの量や店にあるものの量がいつでもわかります。わかりました、いいですね。それにはかなり低いレイテンシが必要だと思いますか？
Joannes Vermorel: 絶対に。
Conor Doherty: わかりました、いいですね。では、その記録システムの設計構造については、ビジネスレポート目的の良いシステムが危険またはコストを伴うということですが、どこに葛藤があるのでしょうか？システムを、バーコードをスキャンするときに合理的なコアが超スナッピーであることを望んでいます。バーコードをスキャンしてビープ音が鳴り、物が認識され、すべてが大丈夫であることがわかります。バーコードがシステムに存在する。すべて。それが、ビープ音が鳴る、システムがすべてが記録されたことを認識する、問題ない、前進する、完璧です。
Joannes Vermorel: しかし、最初の問題は、列指向のセットアップを選択すると、たった1つの操作、つまり、何かをスキャンしたことを認識するだけでも、定義上、遥かに遅くなるということです。なぜなら、システム内で分離された多くの列と接続するために多くの情報が必要になるからです。
そのため、このようなスナッピーなシステムを設計することは、設計上、はるかに困難になります。再び、列指向データベースは大規模な分析に適していますが、スナッピーではありません。これらのデータベースには、低レイテンシ向けに設計されたものはありません。それが設計された目的とは真逆です。
さらに、もう1つの問題が重なります。つまり、データベースレイヤーが、在庫管理や従業員の出退勤など、絶対的な精度が必要なものと同じものとして使用されるということです。そして、誰かが出退勤を記録し、バッジを取るときにも、極めて迅速な応答が必要です。
システムが「あなたが実際の従業員であり、今日バッジを取ることができるかどうかを調べるのに20秒かかります」と言うことはしたくありません。いいえ！このことを超スナッピーにしたいのです。バッジを取り、ビープ音が鳴り、すぐに！さもないと、すべてが遅くなります。
そして、問題は、列指向データベースとして設計された同じシステムであるために、さらに複雑になります。システムの記録のためのシステムのレポート、はい。起こることは、人々がレポートを作成することです。あなたは、「私たちには、ファンシーな分析を行うために設計されたシステムがある。ファンシーな分析をしましょう！」と言います。
しかし、ファンシーな分析の結果は何でしょうか？その結果は、非常に大量のデータを処理する操作が必要になります。そして、それは低レイテンシとは完全に相反するものです。すべてのプロセスで共有されるこのデータベースコアがあります。共有されなければならないのは、そうしないと整合性が取れません。人々が現在の在庫レベルを同じように見ていないと、問題が生じます。
在庫レベルが同じでないと、ウェブサイトの誰かが、他の誰かがすでにこのユニットを選んでおり、この情報が伝播するのに遅れがあったため、在庫がないユニットを注文できると信じてしまいます。電子商取引は、まだ1つのユニットが残っていると信じていますが、実際にはありません。それは大きな問題です！
ですから、愚かな問題がたくさん発生しないように、この整合性を持っている必要があります。今、リレーショナルデータベースのリソースは、非常に軽量で超高速である必要があるものと、非常に重いものとで共有されています。例えば、「昨年、カテゴリごとに3回以上購入したすべてのクライアントを分析する」といったレポートです。
ですから、計算量の多いリクエストがあり、持っているデータ全体のかなりの部分を通過する必要があります。これが対立です。それが分析を行う目的です。分析は、このSKUやこのクライアントを取得することではありません。分析は、これやあれの統計を持つためにすべてのクライアントをスキャンすることです。
私は、過去数年間の販売履歴全体をスキャンしてトレンドを分析します。ですから、非常に貪欲な操作がたくさんあるシステムが同じシステムになっています。そして、再び、それが完全にレイテンシーに損害を与えることをどのように緩和するのでしょうか？
つまり、問題にハードウェアを投げるという答えです。どんな種類のハードウェアを問題に投げる必要があるのでしょうか？まあ、2010年にカラムインメモリシステムになると決めたので、メモリを投げる必要があります。ついてない！
もし世界が異なる方向を取っていたら、DRAMが1000倍安くて速かったら、それは完璧な選択肢だったでしょう。しかし、それは起こらず、おそらく起こらないでしょう。つまり、この技術であるDRAMは進化していますが、コンピュータハードウェアのほとんどの他の技術ほど速く進化していません。
それは、特にレイテンシーの面で、ほとんど20年間ほとんど進歩していない技術の1つです。特にレイテンシーの面で、今後しばらくの間改善を期待しないべきクラスのものさえあります。
たくさんの改善があるでしょうが、この面ではありません。ですから、ポーカーをしてオールインをした人々は、彼らのカードが全く良くないのに、全てを賭けました。それが2010年に起こったことです。そして、今日、非常に多様な方法でその結果が展開しているのを見ています。
Conor Doherty: もう一度、できるだけ多くを要約しようと思います。間違っているところがあれば訂正してください。最初のソフトウェアのクラスで優れるために行う設計選択肢—エンタープライズソフトウェアとは、あなたがシステムの記録として説明するもの—と、システムのレポートなどの分析ソフトウェアで優れるために行う設計選択肢は、対立するものです。
そして、両方を行おうとする—ハイブリッド化する、と言ったように—同時に両方を行おうとすると、基本的には引き延ばし合戦になります。両方を行うことができるかもしれませんが、それらを個別に行った場合よりもうまく行うことはできません。
Joannes Vermorel: 多かれ少なかれ、はい。まさにそうです。つまり、問題は、非常に良いボートと非常に良い飛行機の両方を持つことはできないということです。どちらかです。両方をしようとすると、可能ですが、クソみたいなボートとクソみたいな飛行機になります。
Conor Doherty: さて、再び、私はこのコンセプトを最初に紹介したブログに精通しているので、少しややこしくなります。しかし、それを行う前に、私たちがカバーした地面を要約しましょう。スプリントとウェイトリフティングの比喩を使用しています。あなたを非常に優れたものにするもの—そして私はそれが好きです、なぜなら分析はすべてを取ることについてです。ウェイトリフティングを比喩として気に入りました。
あなたは非常に、非常に優れたウェイトリフターになることができます。地面から200、300、または400キロを持ち上げたい場合、それを行うためには大きくなければなりません。それはパワーベースの動きです。100メートルを10秒未満で走る？あなたが150キロの体重がある場合、それは起こりません。ですから、あなたは非常に良い有酸素運動をすることができますし、無酸素運動のウェイトリフティングエクササイズで世界クラスになることができます。両方になることはできませんし、両方になろうとすると、どちらも本当に優れていません。
Joannes Vermorel: はい、その通りです。はい、さて、再び、私はこの視点を導入した場所に精通しているので、実際にはエンタープライズソフトウェアのクラスの第三のカテゴリがあります。私たちは再び記録システム、在庫単位のデータリスト、在庫単位をカバーしていますが、BIツールは分析とプレゼンテーションのためのものです。まだ触れていないソフトウェアの第三のクラスがあります。
Conor Doherty: それは何ですか？
Joannes Vermorel: 3つ目はインテリジェンスシステムです。興味深いことは、インテリジェンスシステムは、最初の2つのクラスとは異なり、直接的に意思決定を行うことを目指しています。それだけです。興味深いことは、エンタープライズソフトウェアの歴史を見ると、70年代後半から始まり、どんなに効果的に行っていたかに関係なく、すべてのエンタープライズソフトウェアが常にインテリジェンスシステムとしてマーケティングされてきたことです。これは非常に疑問です。
ですから、あなたが売っているものがインテリジェンスシステムであるかどうかは重要ではありません。企業をターゲットにしている限り、それはインテリジェンスシステムとしてマーケティングされます-あなたのためのより良い意思決定。
Conor Doherty: はい、それは非常に疑問です。たとえば、在庫管理ソフトウェアを見てみましょう。実際には、このものは単なる元帳です。在庫がいくつあるかを数えるだけです。何かを取り出すと、在庫が減ります。何かを入れると、在庫が増えます。それだけです。在庫の電子的な反映に過ぎません。
Joannes Vermorel: これらの製品は常に「在庫切れが少なくなり、在庫過剰が少なくなる」としてマーケティングされていましたが、それは元帳自体とは何の関係もありません。
Conor Doherty: いいえ、私は、在庫の簿記を行う際に効率が向上するかもしれませんが、在庫の意思決定が改善されると言うのはなぜでしょうか？ソフトウェアはそれを行いません。あなたが持っているものを教えてくれるだけです。あなたが意思決定をするのを少し良い方法で行うことができるかもしれませんが。
しかし、リアルなチェスボードまたはコンピューターのチェスボードでチェスをすることができます。過去のゲームをすべて追跡したい場合、電子バージョンの方が便利ですが、コンピューター上にあるという事実があなたをより良いチェスプレイヤーにするわけではありません。おそらく、それはあなたをより悪いチェスプレイヤーにする分散要因でさえあります。
コンピューターとやり取りしているからといって、コンピューターで行う決定が自動的により良くなるとは限りません。それは起こるかもしれませんが、論理的にはそのように設計されていません。私自身のカジュアルな経験でも、人々に本当に何かを考えるように求めると、コンピューター画面はルールとして分散要因です。
本当に良い意思決定をしたい場合、大量の混乱した画面が焦点を合わせ、本当に考え抜くのを助けるかどうかはわかりません。
Joannes Vermorel: それは非常に大胆な主張です。はっきりさせておきますが、私たちは記録システムの価値を無視していません。理解しているところでは、システムの記録とその機能を、明示的に意思決定を行うために設計されたソフトウェアの機能と混同しないでください。
これら初期のエンタープライズソフトウェアベンダーを擁護するために、それは非常に曖昧でした。今では私たちにとって非常に明確です-それらの記録システム、原始的なアプリ、ビジネスインテリジェンスツールとモダンな分析を備えたレポートシステム、そして予測能力、最適化能力を持つインテリジェンスシステム、文字通り意思決定プロセスを自動化するという考え-このような分類は当時非常に不明瞭でした。
彼らはすべての3つを試みていましたが、70年代には、非常に初期の在庫管理システムが「在庫のすべての意思決定を直接自動化します」としてマーケティングされていました。そう宣伝されていました。コミュニティは在庫を管理するのは非常に簡単だと気づきました。管理という意味での管理がさらに進化しているという意味で。
70年代に在庫管理と言っていたとき、マネージャーが行うであろうさまざまなことを意味し、マネージャーは単なる簿記を行うだけではありませんでした。彼は在庫の意思決定も行っていました。したがって、在庫管理というとき、在庫を追跡し、関連するすべての意思決定を行うものを考えた人々がいました。しかし、実際にはそうではありませんでした。
したがって、私たちはドメインを在庫管理、在庫最適化に分割しました-最適化はインテリジェンスシステムに属しています。しかし、その当時は非常に不明瞭でした。アナリティクスも同じです-表示することができますが、人々はデータベースがどれほど大きくなるか、それらから統計を作成する際に直面するすべての課題を理解していませんでした。
統計は最初から可能でした。これらのシステムは通常、夜間に実行され、データベース全体を1回通過して統計を収集しました。したがって、タブラーデータベースでも、夜間のバッチを実行して探していた統計を収集することができましたが、非常に遅かったため非常に不便でした。
ロジックを事前に準備する必要があり、ロジックを準備したら、夜間のバッチが実行されるまで待たなければなりませんでした。コードに誤字があることに気づいたのは翌日だけでした。運用上、それは悪夢でした。可能ではありましたが、摩擦の量は単に過度でした。
そのため、ビジネスオブジェクトのようなツールは、本質的にOLAPテクノロジーとハイパーキューブを開発し、数秒でいくつかの分析を行うことができました。これは完全なゲームチェンジャーでした。突然、何かを実装して、明日間違いがあるかどうかを見るまで待つ必要がなくなりました。以前よりも100倍の速さでそれを行うことができました。
Conor Doherty: 先ほど、2015年にリリースされたS4/HANAについて触れました。この会話の録音時点では、ほぼ10年前です-2日前にちょうど10年前だったと思います。それを取り巻くマーケティング資料を見直した結果、特にあなたの分類を使用して、それは記録システム、レポートシステム、そしてAIによる意思決定を通じて、インテリジェンスシステムのすべての機能を備えていると紹介されました。したがって、記録システムとレポートシステムを組み合わせようとすることによって生じる問題をカバーしています…
Joannes Vermorel: いくつかの分析は、完全にゲームチェンジャーであり、突然、何かを実装して明日まで待つ必要がなくなりました。繰り返しますが、以前に比べて100倍の速さで行うことができました。
Conor Doherty: さらに、先ほどSAP S/4HANAについて触れましたが、2015年にリリースされました。実際、この会話の録音時点では、ほぼ10年経っています-私は、2日前にちょうど10年前だったと思います。それを取り巻くマーケティング資料を見直した結果、特に、あなたの分類を使用して、それは基本的に記録システム、レポートシステム、そしてAIによる意思決定-インテリジェンスシステムを持っていると紹介されました。ですので、記録システムとレポートシステムを同時に行おうとすると生じる問題についてはすでにカバーしています。これらの3つのシステムを1つのフードの下で行おうとするとどうなるか？
Joannes Vermorel: そうですね、ここでは列車、船、飛行機を同時にやろうとしているわけですから、さらに悪いです。フランケンシュタインの領域に入るようなもので、本当に醜いものになります。現実は、ソフトウェアベンダーとして、これらすべてを試みるとすべてがあなたに逆らっているということです。ちょっと立ち止まって、それが具体的に何を意味するかを理解してみてください。
記録システムでは、通常、オペレーター、シート、ユーザーごとに料金がかかります。今日この種のものを販売する方法はそういうものです。それが非常に典型的な指標になります。インテリジェンスシステムを行う場合、それは意味をなしません。なぜなら、ユーザーを排除するからです。ああ、そうですね、それがあなたの意図です-良い意思決定を行いたいのです。ですので、あなたがどれだけ優れているかによって、ユーザーが少なくなります。最終的には、クライアント企業には、あなたの意思決定を監視し、それで終わりにするためのわずかなユーザーしかいません。ですので、ユーザーごとに料金を請求している場合、これはうまくいきません。インセンティブの観点で対立があるからです。しかし、もちろん、それは細部に過ぎません。他にもたくさんの問題があります。
必要なソフトウェアエンジニアはまったく異なるタイプです。ちなみに、逆の問題から大きな問題を抱えたソフトウェア企業が1社ありました。それはGoogleです。Googleはインテリジェンスシステムのキャンプに非常に近いものを先駆けていました。当時のGoogleの賢明な決定は何でしたか？それが検索です。ここが私のクエリ、10億のウェブサイトの中から最も関連性の高いものを特定してください。それが行われる決定であり、非常に巧妙に行われなければなりません。Googleは、その決定が非常にうまく行われるように-少なくとも競合他社よりもうまく-彼らは非常に賢いエンジニアが非常に難しい問題に取り組むことを前提にして、全体の労働力を構築しました。意思決定は、その特性上、非常に難しいということです。
だからこそ、それらをコンピュータに委任したいのです。それが簡単であれば、それはさえない決定とは言えません。何かが単なる算数の問題であれば、「わかりました、基本的な計算だけです、次に進みましょう」と言うでしょう。Googleは、そのような洒落たシステムを行うためにたくさんの有能なエンジニアを雇いました。記録システムを開発する際、それは平凡で退屈で繰り返しの作業であるため、彼らは失敗しました。
Googleの歴史を見ると、平凡なものはすべて窓から投げ捨てられました。Google Readerというブログリーダーがありましたが、広く採用されました。それはシンプルで粗末なアプリでしたが、Googleにとっては十分ではなかったので、捨てられました。彼らは、粗末なアプリ-CRUDの意味で粗末なアプリ-をリリースしましたが、それを維持できなかったのです。それは彼らにとっては価値がなかったからです。
これは、会社全体が知能システムの開発に重点を置いているときの実際の問題です：あなたのエンジニアリングチームは退屈で繰り返しの作業をすることに熱心ではありません。逆に、数十年間記録システムを作成してきた場合、あなたのチームは単に何千もの画面を作成することに慣れており、「このソフトウェアには5,000個または20,000個の異なる機能が必要で、それぞれが非常に簡単で何の挑戦もない」と認識していますが、それらはやらなければなりません。
エンジニアリングの労働力と文化に関しては、まったく異なります。私の認識では、SAPは土地の獲得という考え方に傾倒した労働力を持っていました-何百ものエンジニアが何百もの画面と何百もの機能を作成できる、それぞれが個別に非常に簡単なものです。そして、彼らは知能システムに飛び込もうとしましたが、それは非常にうまくいきませんでした。
知能システムに長けた人々が見られる分野の1つは、技術的なブレークスルーを達成し、それがオープンソースプロジェクトの形で漏れ出てくることです。例えば、Googleは粗末なアプリの維持に失敗したかもしれませんが、価値のあるオープンソース技術の断片をリリースすることに成功しました。SAPを見ると、SAPから興味深いオープンソースプロジェクトが1つも出てきたとは言えません。
Conor Doherty: さて、私たちは記録システムとレポートシステムの構造をかなり詳しく説明してきましたが、実際には、知能システムのための戦略的なアーキテクチャ設計の選択肢-なぜそれが他の2つのアーキテクチャと互換性がないのか-についてはまだカバーしていません。たとえば、Lokadは意思決定のシステム、知能のシステムです。それが記録システムと調和しようとすると、それが軽く言っても問題があるのは、その構成要素について何ですか？
Joannes Vermorel: 基盤として、知能システムはレポートシステムといくつかの類似点を持っています。分析にはこの列形式の表現が必要です。しかし、知能システムで求められるものは非常に迅速なプログラム可能性です。意思決定プロセスをエンジニアリングする柔軟性が欲しい場合、非常に表現力豊かなものが必要です。ところで、それがなぜExcelスプレッドシートが意思決定プロセスをサポートするために頻繁に使用されるかです。Excelにはプログラミング言語があり、それは非常に重要です。
Excelの数式は任意に複雑にでき、高度な場合、VBAやPythonを介してプログラミングを行うことさえできます。Excelはプログラム可能であり、それが知能システムをサポートするツールとして頻繁に使用される理由です。プログラム可能性が必要であり、それはレポートシステムとはまったく異なるゲームです。レポートシステムでは誰にでもアクセス可能であるべきです。WYSIWYG（What You See Is What You Get）の領域にいます。ファンシーなインターフェースがあり、それがレポートシステムの世界です。
Conor Doherty: また、私には、まだ触れていない経済の観点があることに気づきます。そして、再び、あなたは経済学者であり、トーマス・ソウェルの人です。
ソフトウェアの観点から、記録システム、レポート、知能をすべて兼ね備えた3-in-1ソリューションを購入しようとするのは、知的な決定なのかどうかは別として、それが3つの別々のソフトウェアの購読よりも安くつく可能性があるという経済論があるのではないでしょうか。少なくとも、3つの別々のソフトウェア、3つの別々の問題、3つの別々のトレーニングが必要な代わりに、3つのことをすべて行えると主張しているソフトウェアを購入する方が安いというトレードオフのセットがあるのではないでしょうか？
Joannes Vermorel: そうですね、それは実際にはF-35の物語です。アメリカの戦闘機であり、史上最も高価な飛行機になると言われています。問題は、これらのものが線形ではないということです。
「私は、自分の飛行機を近接戦闘で非常に優れたものにしたい、長距離作戦でも非常に優れたものにしたい、ステルス性があり、垂直に離陸できる」と言うと、機能を追加するたびに、全体の価格が2倍になるということです。
その結果、長距離作戦用の1機、他の飛行機との戦術戦闘用の1機、ステルス性のある1機、垂直離陸用の1機など、すべての機能を1つのセットにまとめた飛行機ができます。すべてを持つ必要はないかもしれません。などなど。ですので、それは線形ではありません。すべてを1つのセットにまとめることはできません。
さて、SAPが完全に独立した3つのシステムを持つことを決定したと言えます。記録システムを扱うもの、レポートシステムを扱うもの、知能システムを扱うものの3つで、それらの部門の間に中国の壁を設け、それらが独立して運営されるようにすればうまくいったかもしれません。しかし、それは行われたことではありません。
すべてを含めて引っ張り寄せる誘惑が強すぎました。買収されたサードパーティーのソリューションを含めることは、混合物が有害であるだけです。非常にうまく混ざらない製品を取り、機能しないものを作り出します。それが今見ているものだと思います。
タイムラインに戻りますと、2010年にHANAがありました。それにS/4を5年かけて展開しました。これらの失敗のほとんどは文字通り10年かかりました。10年かかって展開されたものを見ています。
HANAの失敗が公に目立ち始めています。それは氷山の一角に過ぎません。多くの企業の機会費用は狂っています。アップグレードには多くの年数がかかるためです。5年以上かかるアップグレードについて話していますが、それはまったくばかげています。
それは狂っています。ChatGPTや生成AIが5年前に存在しなかったことを考えてください。戦いに遅れることになります。その上、インメモリシステムにすべてをかけるなど、非常に悪い決定がされました。つまり、インフラに過剰に支出することを意味します。
大量のハードウェアがある場合、必要以上に多くのシステム管理者、IT部門の人員が必要になります。すべてが非常に複雑になります。それは単により複雑になるだけでなく、遅くなります。これらのことは複合的です。それははるかにコストがかかり、遅くなり、より多くの人員が必要であり、機会費用がさらに悪化します。
その後、人々は経営層で怖がるようになります。リスクが非常に高いため、プロセスがさらに遅くなります。それは悪循環のようなものです。問題が目に見えるようになっています。企業は、内部のミスが公にならないように最善を尽くします。それは良い報道ではありません。自分たちの無能さを広告することはしたくありません。それを密室で処理できれば、はるかに良いです。
どれほど問題が深刻であるかを考えてみてください。それをすべて公に開示するにはどれほどの事態になるか。ほとんどの状況は、企業が公開されている場合を除いて、開示されないでしょう。それは詐欺として分類される可能性があるため、公開企業であり、それ以外の場合は開示しなければならないときです。
Conor Doherty: さて、機会費用について何度か触れていますね。実装に巻き込まれることの機会費用、突然、そのプロセスに閉じ込められ、他のことに切り替えることができなくなります。それには、それを維持する人々に関連する膨張コストもかかります。
これには別の側面があり、ここに「完璧性」と書いています。機会費用の観点から、それぞれのソフトウェアの3つのクラスを個別に取り上げた場合、理論的にはそれらは別々に保持されるときに最も優れています。なぜなら、別々の記録システム、別々のレポートシステム、別々のインテリジェンスシステムがあるからです。
各々を完璧にしようとします。記録システムがどれほど完璧であるかには上限があります。100％の精度があると、それで終わりです。例えば、テーブルの上にはボトルがいくつありますか？2つです。それ以上はありません。
レイテンシが50ミリ秒に達したら、それは無視できるレベルです。レポートシステムは、ダッシュボードがどれだけ良く見えるか？美学について議論することはできますが、収益が減少する前にどれだけの時間とお金を投資したいかには上限があります。
インテリジェンスシステムは、あなたが言ったように、意思決定に関わります。Lokadの哲学では、それは行われたすべての意思決定に対する投資対効果を考慮することを意味します。理論的には、私には、これ以上に良い意思決定をすることができる完璧なポイントがあるとは言えません。
それは必ずしも完璧ではありません。アルゴリズムを継続的に改善して、より良い意思決定を行うことができます。私が間違っていますか？
Joannes Vermorel: いいえ、しかし、誤解も解消しなければなりません。数学者は、「ああ、でも最適解に到達したら、最高ですよ」と言うでしょう。最適解に到達したら、それ以上良くすることはできません。そして、私が言うには、任意の数学的パズルについて、数学的パズルを取り上げて、「これがそれです、これがパズルです」と言えば、このパズルのための最適解を持つことができます。
しかし、ビジネスの世界でそう考えるのは間違っています。パズルの選択は非常に恣意的です。あなたは、「このフレームワークに最適なものを持っているかもしれませんが、自分自身のビジネスを再発明し、さらに高いリターンを得る新しいフレームワークを持つかもしれません」と決めることができます。したがって、持っている選択肢は静的ではありません。あなたは何をする意志があるかを決定し、あなたがやりたいことの中で、最適なものがあるかもしれませんが、基本的に、あなたの可能性は無限です。
私が見る限り、唯一の上限は人間の創造力そのものです。つまり、「私の最適解は意味がない」と言うのは、最適解が形式的な制限の中にあるからです。私は砂の上に線を引いて、この領域だけを見ることができると言います。この砂で区切られた領域内で、はい、私の最適解はそうかもしれません。数学的にそれを証明できるかもしれません。
しかし、現実は、それはただ砂の上に引かれた線です。どこにでも行けます。ですので、ビジネスの意思決定を考えるとき、最終的には、ケースに取り組む人々の知性と創造力以外には制限がありません。
さて、ソフトウェア業界は非常に早い段階でそれに気づいたと思います。つまり、70年代から、すべてのベンダーが、より良い意思決定という言葉で利益を追求していました。彼らは文字通り、電子的な在庫の表現を持つ問題が有限であることに気づいたのです。それが正しく行われたら、何をしますか？
人々は段階を踏んでいきました。最初はテキストインターフェースがあり、次に90年代のデスクトップ、ファットクライアント世代のようなグラフィックインターフェースがありました。今日では、Webアプリがあり、そして今はモバイルアプリがあります。つまり、インターフェイスレベルでも、ユーザーインターフェイスには一連の移行がありました。
たとえ課題が有限であったとしても、ソフトウェア企業は、テキスト端末からグラフィックインターフェース、Webアプリ、そして今はモバイルアプリにアップグレードするだけで忙しかったことがわかりました。しかし、重要なことは、誰もがこのものがいつか終わるだろうということが非常に明確であったということです。つまり、それが無限に成長して非常に大きなものになることはないということです。
だからこそ、SAPを含む多くのベンダーが、実際には彼らのソフトウェアがより良い意思決定を生み出すこととは何の関係もないにもかかわらず、それらの意思決定に対して自分たちをブランド化しました。
Conor Doherty: さて、理論についてたくさん話しましたが、それは良いことです。実際、ここで少し実践を交えた理論ですが、確かに、もう少し実践的にしてみたいと思います。私は、あなたにこのように質問をフレームにしてみたいと思います。エピソードの最初で、DHL、Asda、Sparと言いました。Anthony Millerの投稿から他の例もありました。
もし今日、もし意思決定者、重要人物、大物たちと一緒にボードルームにいたら、「よし、ジョアネス、次に何をすべきか」と言われたらどうしますか？これを試してみたけれどもうまくいかなかった。あなたのアドバイスは何ですか？
Joannes Vermorel: 私のアドバイスは非常にシンプルです。レコードシステムは10年前に完全に商品化されました。実際、10年以上前です。だから、段階的に進めましょう。あなたのデータベースは、たとえば、PostgreSQLになるでしょう。それはオープンソースであり、優れています。
これは2010年にSAPが「私たちは多くの問題を抱えており、Oracleを戦略的な脅威と見なしている」と言ったときのことでした。彼らが気づかなかったのは、Oracleは無視できる存在だったということです。真のライバルは実際にオープンソースでした。
したがって、今日勝利したリレーショナルデータベースは実際にオープンソースデータベースです。リレーショナルデータベースは今や完全な商品となり、最高の製品はオープンソースプロジェクトであり、PostgreSQLはOracleやプライベートのものよりも優れています。
ですから、大手ベンダーであるSAPは、Oracleという他のベンダーを抑えたかったが、結局はオープンソースの製品であるPostgreSQLよりも劣る技術を開発することになりました。
それが劣っているとどうやって知っているのか？Hacker Newsを見たり、最近のスタートアップが何をしているかを議論したりすればわかります。私は3桁の数のスタートアップを監査してきました。過去10年間、非オープンソースのリレーショナルデータベースを使用しているスタートアップを見たことがありません。一度も。
彼らはオープンソースのデータベースのみを使用します。たとえば、Oracle Databaseを使用しているスタートアップを見たことがありません。一度も。ですから、技術に詳しい人々、技術に携わる人々はこの選択をしません。まず、この幹部の部屋に対して言うべきことは、「データベースレイヤーについては、市場にある優れたオープンソースの選択肢の1つを選択する必要があります」と言います。
それがPostgreSQLであるかもしれません。これらのソリューションは優れており、それをしないと機会損失が膨大になります。なぜなら、これらのデータベースの1つを選択すれば、その上には、既にそれらの技術に精通している100万人以上のソフトウェアエンジニアがいるからです。それに比べて、非公開の、不透明なファイアウォール技術は運用がはるかに難しいです。これが最初の問題でした。
それから、上に何が必要ですか？基本的には、データベースの上にクラッドアプリを展開するためのフレームワークが必要です。これらのフレームワークはたくさんあり、そして再び、オープンソースで利用可能です。Pythonの場合はDjango、Microsoftの場合はASP.NETのMVCフレームワークが必要です。これらのフレームワークは、すべての主要なスタック、Python、Java、.NET用に用意されています。
なぜなら、それは完全に商品化されているため、あなたのシステムの記録のために既にオープンソースのベンダーを選択するか、自分で作成するだけで済みます。それはさえずりも高くつきません。問題は、ERPのアップグレードを行うために5年かかるプロジェクトを終えると、部分ごとに自分自身の置き換えを展開する方がはるかに良いということです。
6か月後には、既にアップグレードおよび置換されている一連のモジュールを持っているかもしれません。内部で行うか、IT企業の助けを借りるかすれば、それが可能です。再び、システムの記録が完全に商品化されていることの素晴らしい点は、それを行う人を見つけることが非常に簡単であるということです。これらのことを外部委託することは非常に簡単です。それを内部で行うことも非常に簡単です。
バーは非常に低く、非常に安価です。この世界のすべての技術に精通した企業を見ると、この世界のZalandoは自分自身のERPを開発しており、それで十分です。Amazonを見ると、同じことをしています。JD.comも同じことをしています。デジタルネイティブの人々は、記録システムに対する明らかな解決策としてそれを見ています。
レコードは完全に商品化されています。最終的には、それらの製品は高価であってはならないということです。もし高価であれば、あなたのプランBは、「わかりました、自分でやります」ということになるべきです。もし家の壁に絵を描くために画家に頼んだら、それが200万ユーロかかると言われたら。
それは4平方メートルですが、もし私がそれ以上のことができないなら、あなたは「わかりました、自分でやります」と言うでしょう。それが唯一の選択肢であれば、私は自分でやります。はい、絵を描くことはしたくありませんが、私たちは宇宙にロケットを送ることではありません。私たちが話しているのは、非常に簡単なことです。
Conor Doherty: さて、これは、私が詳細なメモを取るので、おわかりいただけるとおりです。しかし、私が次に尋ねたかったのは、3つのクラスを明確にした後で、再びその役員たちと同じ部屋にいるということで、私たちの潜在的な偏見が明らかであることをご存知のとおりです。Lokadはベンダーそのものです。これらのクラスごとのコストについて、何度もコメントしてきた最後の2〜3分間について、“見てください、基本的には自分でやることができます"と何度も言っています。
つまり、技術的に熟練している場合、そしてデジタルネイティブである場合、自分自身の記録システムを設計することができます。では、それはおそらく、レポートシステムやインテリジェンスシステムよりも安価であるべきです。それでは、どのようにして予算を割り当てるのでしょうか？
Joannes Vermorel: つまり、記録システムは他のものよりもはるかに単純です。最初に登場したものです。その技術は完全に商品化されています。オープンソースは必要なすべての要素を提供しています。クラッドアプリを開発することは、統合開発環境の典型例です。
ですので、ツールは優れており、フレームワークも優れています。そしてツールは優れています。多くのエンジニアが大きな生産性を持っており、今日ではLLMがさらに優れています。これは、ジェネレーティブAIが非知的なコードを大量に書く際に非常に優れている分野です。これらのツールは、そのようなことをするのに非常に優れています。
Conor Doherty: では、200億ドル、それが私たちが請求すべき金額です。
Joannes Vermorel: そうですね、それは比較的、つまり、それは企業にとってかなり安いはずです。10年前に同様のシステムに支払った金額の十分の一以上を支払うことになった場合、それは詐欺です。つまり、それがあなたの基準であるべきです。ですので、再び同じことをしようとしている場合は、「予算の十分の一でやります」と探しているべきです。それはまだ押し付けることではありません。
技術の進化を考えると、それは出発点です。狂ったように、攻撃的に進めるとすれば、イーロン・マスクがそのケースを引き受けるとします。それは、「100倍安くやります」となるでしょう。しかし、私は、次のERPプロジェクトは、10年前に費やしたコストの十分の一であるべきだと言いたいと思います。少なくとも記録システムに関しては、それが合理的な基準だと思います。
レポートシステムに関しては、技術はかなりパッケージ化されています。問題は、通常、企業がバズィリオンのレポートを求めるため、非常に高額になることです。コストは、無制限の数のレポートの実装、特注品です。狂った数のレポートです。
ですので、レポートシステムがあると、ある時点で人々は言うでしょう、「ああ、しかし、私は、ボックスから出た、すぐに使えるテンプレートのレポートを持ちたいです」と。そしてベンダーは、「はい、問題ありません、いくつ欲しいですか？」と言い、そしてリストアップし、数千のレポートができます。それをやると、あなたがそんなにたくさんを求めているので、信じられないほど高価になります。
ですので、ここでは、技術がかなりパッケージ化されているため、それはかなり安いはずですが、記録システムよりも難しいです。ですので、自分で作ることをお勧めしません。しかし、Sparkのようなオープンソース技術を使用すれば、それほど難しくはありません。ただし、記録システムよりも難しいです。
ここでは、予算を引き締めたい場合は、要求をコントロールする必要があります。特に大企業では、誰も消費しないであろう無限のレポートのリストを要求する誘惑があります。それは、それらの人々が時々それらの数字を見なければならないため、非常に高価になりますが、それは実際にはあまり意味がありません。
ですので、短く集中させ、コストは非常に高くなりません。実際、それは、10年前の基準ERPコストよりもはるかに小さくなるはずです。新しいERPはそのほぼ十分の一であるべきだと言いました。レポートシステムは、この次世代ERPのコストの20%を超えないようにするべきです。
それが私たちが話していることです、非常に小さなものです。最終的に、レポートは、ビジネスに関する基本的な記述統計情報を報告するのに数百万ドルや数千万ドルかかるべきではありません。その意味はありません。技術は十分に進歩しているので、それは非常に安いはずです。
Conor Doherty: あなたが最初に3つのクラスまたは3つの種類のエンタープライズソフトウェアの分類を提案したとき—あなた—私は正確な比率を思い出せませんが、IT予算の約90%が知能システムに費やされるべきだというものでした。
Joannes Vermorel: 私が提案した分割は、ERPに20%、知能システムに5%、そして—すみません、記録システムに20%、レポートシステムに5%、そして知能システムに75%でした。それが私がほぼすべてのビジネスに対してヒューリスティックとして提案するものです。
それに対して、今日起こっていることは、ERPに75%、ビジネスインテリジェンスまたはレポートシステムに20%、そして知能システムにわずか5%です。私はこれらの数字が間違っていると言います。それらを入れ替える必要があります。なぜお金の大部分を知能システムに費やす必要があるのでしょうか？
明らかに、Lokadは知能システムですので、観客は多額のお金を費やすべきです。しかし、現実は、投資対効果がちょうどそこにあるということです。それが、決定が正しく行われれば、大きなリターンが得られる場所です。レポートシステムは、主に、火事になっていないことを確認することに関係しています。
遡って、自社のプロセスに準拠しているか、進行中かどうかを確認するために見ることです。しかし、基本的に、過去を振り返って成功した企業は一つもありません。それがレポートシステムの問題です。あなたは後ろを見ているのです。
レースに勝つためには、後ろを見ていては勝てません。ある時点で、前を見る必要があります。
Conor Doherty: 実際に目の前にラップトップがあることに気づきました。これはWi-Fiが付いています。私が言及していたブログは実際に「エンタープライズソフトウェアの3つのクラス」という名前でした。去年の6月のものです。
数値を明確にするために、企業がどのように、ほぼすべての企業が、通常、支出を分割するかを思い出していました—彼らのIT予算は記録システムに75%、そしてその後に「間違っている」と遊び心を込めて書かれています。レポートシステムに20%、また「間違っている」、そして知能システムに5%、最後に「完全に間違っている」と書かれています。
知能システムに75%、レポートシステムに5%、記録システムに20%を逆転させます。今、そのブログを読むことを強くお勧めします。とても良いです。
さて、最後にまとめを始める前の最後の質問ですが、私に思いついたものです。これは、以前にあなたが講義で述べたポイントであり、私もここで何度か話したことです：機械的同情心の役割。それについて長く話す必要はありませんが、購入しようとしているツールで優れた成績を収めるために必要なパラメータやアーキテクチャ設計の選択肢について基本的な理解があるということが私に思い浮かびます。
それについてある程度理解していれば、少なくとも「これは私には向いていないかもしれない」という感覚を得ることができます。ですので、たとえば、カラム型と表形式のデータベースの違いさえ理解していれば、このシステムが何に使用されているか、そのシステムをどうしたいかをよく理解していれば、高額な選択を即座に再考することができるかもしれません。
Joannes Vermorel: はい。そして、再び、SAPが2010年に、えー、間違ったことをした種類の間違いに戻ると… HANAは2010年にリリースされましたので、おそらくそれには数年前から取り組んでいたでしょう。当時、内部のコンピュータシステムの遅延が改善し続け、メモリがはるかに安くなると仮定するのは良い考えのように見えました。
なぜなら、もう一度言いますが、2010年と、たとえば、15年前の、えー、1995年との大きな違いは何かを見てみると、その15年間で、メモリが劇的に安く、劇的に豊富になっていました。当時、1995年に、私は最初に使用したコンピュータ、Windows 95、には8メガバイトのメモリが搭載されていたことを覚えています。
そして、2010年になると、その時は、Windows 7だったと思います。その時点で、8ギガバイトを持っていたと思いますので、この期間中に1000倍に成長しました。そして、遅延は50倍程度に分割されていました。
ですので、このトラックを続けていたら、それは信じられないことでした。つまり、2010年にコンピュータに8 GBが搭載されていたことを意味します。15年後に同じように改善されていた場合、今日のコンピュータには8テラバイトが搭載されていたはずです。もちろん、私のコンピュータにはそんなものはありません。誰もが自分のコンピュータに8テラバイトを持っているわけではありません。
しかし、15年前と同じように技術が進歩していた場合、人々が持っていたものであったでしょう。そして、遅延の同様の削減もあった場合、問題は光速が非常に厄介であることです。物理学があなたに優しく振る舞っていないのです。光速が邪魔をしているということです。
それでも、彼らはこの悲劇的な間違いを犯したと思います。そして、その結果、多くのことが過度に設計されなければならなかったのです。これはまるで原罪のようなものです。そのため、問題から抜け出すために行わなければならない多くの隠蔽があります。そのような大規模な設計上の問題がある場合、問題から抜け出すためにダクトテープを試すことができます。しかし、すべてがぎこちなくなります。
ですので、パフォーマンスの問題に直面した場合、ハードウェアを追加することで解決できます。はい、明らかに超高価なハードウェアを購入することから始めることができます。しかし、ある程度は機能しないようなものにならないように、ある種のものを過度に設計することができます。基本的には、十分なエンジニアリングがあれば、いくつかの問題を緩和することができます。
しかし、SAPは依然として、私が説明していたような野心を持ってすべてをカバーしようとしています。1つのことの記録システムであることを望んでいますが、彼らはすべてのことの記録システムであることを望んでいます。つまり、この選択によってパフォーマンスの問題が発生する可能性のある表面積は、絶対に巨大です。
そして、私たちが見ているのは、ゆっくりと、ゆっくりと崩壊していくものです。それが私たちが見ているものです。それには多くの時間がかかります。HANAの上にERPをリリースするのに5年かかりました、それがS/4です。そして、最初の企業にERPを販売するのに数年かかりました。
なぜなら、企業向けソフトウェアを販売したい場合、取引を6か月で成立させるわけではなく、頻繁に数年かかります。したがって、実装には半世紀サイクルがかかります。そして、半世紀かかると、アップグレードの計画が立てられます。
それは狂っています。しかし、現実は、半世紀かかるのではなく、1世紀かかるということです。ですので、私たちは、長い時間前に行われた悪い決定によって引き起こされた失敗を目撃しています。そして、私たちは過去数十年にさかのぼっています。これらの問題が繰り返し発生するのを見ると思いますが、それは新しいものではありません。それは、長い時間前に行われた間違いを反映しています。
そして今、私たちが本当に提案できる唯一のことは、古代の間違いを繰り返さないことです。しかし、狂ったことは、それらの間違いが非常に長い時間前に行われたため、SAPによる間違い、そしてそれが正しいと思ってそれを採用した人々。
興味深いことに、これらの間違いは非常に長い時間前に行われたため、人々は「ああ、しかし今日では正しいはずだ」と考えているかもしれません。彼らは自分たちのことをまとめました。彼らの考えをまとめました。これは解決されました。なぜなら、明らかに、ベンダーとして、もし私がそのような製品を提案する場合、「尊敬する見込み客様、私たちは過去の間違いから学びました。それらのことは修正されました。私たちは多くを学びました。それらの間違いは二度と起こりません」と言うでしょう。
と言いたいところですが、問題はまだあなたのテクノロジーの非常に核心にあります。HANAは依然としてすべてのSAPの提供物の中心にあります。それがある限り… はい、あなたは困っています。より正気のある領域に入るためには、それらすべてを解除する必要があります。
現在、彼らがコースを変えてHANAを取り除き、PostgreSQLなどのオープンソースに移行し、そして彼らの提供物をスライスして切り刻んで、きちんと分離されたリーンなアプリケーションを持つことができるようにするまで、インターネットを介しての統合は非常に簡単です。したがって、彼らは非常にモジュラーな設計を持つことができます。
それを始めない限り、元の罪はまだそこにあります。すべてをシステムのエンジンにするという野望と、間違ったエンジンがシステムの中核にあるということ。
Conor Doherty: さて、前向きなノートで終わろうとすると、これらの巨大企業のいくつかが犯した、引用符で囲まれた地雷を避けるために人々と共有できる建設的なアドバイスはありますか？
Joannes Vermorel: 私が言いたいのは、本当のポジティブな見方であり、それが私がそれらの間違いを見たときに非常に悲しくなる理由です。オープンソースコミュニティが信じられないほど素晴らしいものを提供してくれました。PostgreSQLはエンジニアリングの驚異です。これはオープンソースです。これは魔法です。
私たちは、価格については正確には無料ではありませんが（もちろんインターネット接続料金は支払う必要がありますが）、信じられないほど低価格で、信じられないほどよく設計されたシステムや、私たちの世紀の最も優れたエンジニアの何百年にもわたる成果を表すエンジニアリングの断片を手に入れることができます。これは信じられないことであり、それを無料で手に入れることができます。だから、それが私の考えです。
