00:00:07 ERPシステムの重要性。
00:02:42 ERP：誤った呼び名の説明。
00:03:54 初期のERPシステムの導入。
00:05:07 初期のERPシステムの主な機能。
00:07:34 ERPシステム：エンティティ、インターフェース、ロジック。
00:09:14 ERPのビジネス自動化における役割。
00:09:54 ERPの進化と戦略。
00:11:32 ERPにおけるドメイン固有言語。
00:12:07 ERPシステムのモジュールベースの構造。
00:14:22 ERPにおける統合業者の役割。
00:16:00 カスタマイズされたERPソリューションを推進する統合業者。
00:17:01 伝統的なERPの制約の重要性。
00:19:01 単一のERPシステムの必要性に対する挑戦。
00:20:01 ERPのアップグレードの困難さ。
00:21:35 ERPオペレーターの役割と複雑さ。
00:22:53 専門のERPプロバイダーのリスクと利点。
00:25:00 ERPシステムの複雑さと課題。
00:26:52 中小企業とSaaSアプリ。
00:28:42 中規模企業向けの複雑なERP製品。
00:30:16 大企業がモノリシックなERPを避ける理由。
00:31:46 トップ企業の戦略。
00:33:39 結論。
概要
Kieran Chandler氏とのインタビューで、Lokadの創設者であるJoannes Vermorel氏は、エンタープライズリソースプランニング（ERP）システムの進化について話しました。1970年代の発祥から、リレーショナルデータベースとバーコードリーダーの登場をERPの開発に不可欠な要素として強調しています。彼は、これらのシステムは特注の企業ソリューションから事前パッケージ化されたビジネスモデルの表現に成長したと述べ、“Enterprise Resource Management"がこれらのシステムに対してより正確な用語であると提案しています。CRUDインターフェースやワークフローロジックなど、ERPの現代的な機能は、日常業務を自動化し、生産性を向上させています。Vermorel氏は、SAPなどの成功したERPベンダーの戦略を探求し、さまざまな規模の企業に対するERPの選択と導入についても議論しています。
詳細な概要
インタビューでは、ホストのKieran Chandler氏がLokadの創設者であるJoannes Vermorel氏と話し、エンタープライズリソースプランニング（ERP）システムの進化と機能について議論しています。
Vermorel氏は、ERPシステムの起源を1970年代に特定し、ただし「ERP」という用語は90年代になって初めて作られたと述べています。Vermorel氏によれば、ERPシステムの開発には2つの重要なイノベーションがありました。最初は、コンピューティングハードウェアの進歩により、関係データベースが可能になったことです。これらのデータベースは初期段階では原始的でしたが、データを整理するための柔軟な方法を提供しました。テーブルと列からなる関係形式は、取引、支払い、顧客とサプライヤーの相互作用など、さまざまなビジネス活動のモデリングに適していました。
Vermorel氏が挙げる2番目の重要なイノベーションは、バーコードリーダーの発明です。バーコードリーダーは1950年代に登場しましたが、1970年代のコンピューティングハードウェアの進歩により、大量のデータを保存および処理することが可能になりました。これら2つの技術の組み合わせにより、私たちが今日知っているERPシステムが生まれました。
Vermorel氏はまた、ERPという用語の誤解について言及し、それが90年代に始まったマーケティングのトリックであると述べています。彼はERPが計画とはほとんど関係がなく、代わりに管理に焦点を当てていると説明しています。彼は、当時利用可能だったデータベースとデータ入力デバイスを使用してリソースを管理するために多くの企業が独自のソフトウェアシステムを開発し始めたと述べ、これにより説明しています。
支払い、在庫、従業員などのビジネスの表現に共通点を見出し、いくつかの企業がこれらのビジネスモデルの表現の事前パッケージ化バージョンを提供し始めました。Vermorel氏は、これが私たちが今日ERPシステムと呼んでいるものの起源であると指摘していますが、実際の機能を考えると、これをエンタープライズリソースマネジメントシステムと考えるべきだと提案しています。
ユーザーインターフェースは、一般的にCRUD（作成、読み取り、更新、削除）インターフェースとして分類され、これらのエンティティ上で動作します。これらのインターフェースは、新しい製品を追加する（作成）、既存の製品の属性を表示する（読み取り）、既存の製品を変更する（更新）、製品を削除する（削除）など、基本的なデータ入力タスクを可能にします。このCRUDパターンは、ERPシステム内のすべてのエンティティに適用されます。
ワークフローロジックは、自動化が関与する第3のコンポーネントです。Vermorel氏は、購買プロセスの例を挙げて説明します。これは、購買注文から始まり、サプライヤーからの請求書を受け取り、サプライヤーが商品を出荷するという手順です。ERPシステムはこれらの手順を追跡し、商品が受け取られない場合はユーザーに警告します。受け取った数量が注文数量と一致しない場合、ERPシステムはサプライヤーに残りを送るか商品を返品するなどの次の手順を提案します。これらのルーチンタスクの自動化により、生産性が大幅に向上します。
ERPの進化に移ると、Vermorel氏はベンダーの役割を強調しています。彼は、ベンダーにとって最大の課題は複雑さの管理であると指摘し、エンティティ、ユーザーインターフェース、ロジックの無限のストリームを実装する必要があります。彼は、この複雑さを管理し競争力を維持するために成功したERPベンダーが使用する「三つ折り」戦略に言及しています。
まず、ベンダーはエンティティ、ユーザーインターフェース、ロジックの製造を効率化するために特定の技術を採用します。Vermorel氏は、成功したERPベンダーであるSAPの例を挙げ、実装プロセスを高速化するために独自のドメイン固有のプログラミング言語であるABAPを開発したことを引用しています。
次に、ベンダーは提供物の構造と価格を調整し、エンティティの多様な範囲を製造およびサポートするためのコストと労力を反映させます。これは、ビジネス上意味のあるモジュールにエンティティをグループ化し、顧客が使用するモジュールに基づいて料金を請求するモジュールベースの価格設定構造につながることが多いです。
エンタープライズソフトウェアの世界で主要な役割を果たしているERPシステムは、常に進化し、ビジネスとその複雑な業務のニーズに対応しています。
Vermorel氏は、ERPベンダーのインセンティブとビジネスモデルについて説明を始めます。これらのベンダーは、顧客に販売するために新しいモジュールや機能を継続的に開発することがインセンティブとなっています。ベンダーはしばしば各成功した実装を、顧客に追加のモジュールを作成して販売する機会と見なします。これにより、販売と開発の永続的なサイクルが生まれます。
その後の会話は、異なるERPアプローチの選択肢について話します。Vermorel氏は、企業は70年代のERPに組み込まれた制約が現在の状況に対してまだ有効であるかどうかを問うべきだと提案しています。彼は、単一の統合システムの必要性に疑問を呈し、このアプローチが複雑さの増加と多くのエッジケースを引き起こす可能性があると主張しています。代わりに、1つのシステムがすべてを行うという前提を再考することを提案し、同時に異なるシステムを持つことにも警告しています。
新しいERPシステムの導入について話し合う中で、Vermorel氏は新しいシステムへの移行や既存システムのアップグレードに関連する重大なリスクとコストに触れます。彼は、2009年にSAPのアップグレードに50億ユーロを無駄にした会社の例を挙げ、ERPシステム内のエンティティの意味論は、システムのオペレータによって大きく変化することがあり、バージョン間で微妙ながら重要な違いが生じ、多くのエッジケースや課題が生じることを強調しています。
Vermorel氏は、小規模なベンダーにはリスクがあると考えていますが、現在の企業の複雑さとスケールを反映した狭いコアを持つ製品を選ぶ方が良いと述べています。彼は、プロセスを混乱させる余分な機能に反対し、必要に応じて統合で補完できる製品を選ぶことを推奨しています。
また、Vermorel氏は、異なる企業規模に適したERPの選択肢についても触れています。彼は、100人未満の小規模企業は、狭くてシンプルで費用効果の高いSoftware-as-a-Service（SaaS）アプリケーションを選ぶべきだと提案しています。彼は、特定のニーズをカバーする2つまたは3つの別々のアプリを使用することを推奨し、包括的なERPに頼ることを避けるよう助言しています。約500人の中規模企業に対しては、より複雑な中規模ERP製品を検討することをVermorel氏は提案しています。この製品は、典型的なビジネス機能の幅広い範囲を処理できます。ただし、数千人の従業員を抱える大企業に対しては、Vermorel氏は一元的なERPアプローチを避け、分割して征服する戦略を提案しています。彼は、ランドスケープを機能領域に分割し、各領域に合わせたソリューションを構築または購入することを提案しており、単一のERPシステムを導入しようとすることを避けるよう忠告しています。
フルトランスクリプト
Kieran Chandler: 今日は、このエンタープライズソフトウェアのクラスが最初にどのようにして生まれ、企業がさまざまなオプションの中から選択する方法を見つけることができるのかを知ることになります。では、ジョアネスさん、まずはERPシステムの起源について見てみましょう。最初にどのようにして生まれたのでしょうか？
Joannes Vermorel: ERPシステムは70年代の2つの要因から生まれました。ちなみに、ERPという用語は90年代に生まれましたが、私たちが通常ERPシステムと呼ぶものは実際には70年代に始まりました。2つの重要なイノベーションがありました。1つはデータベースシステムです。コンピュータハードウェアが進化し、関係データベースが可能になったということです。これが最初のイノベーションでした。2つ目のイノベーションはバーコードリーダーです。これら2つのイノベーションを組み合わせると、関係データベースが非常に多目的であり、支払い、クライアント、サプライヤー、取引など、ほとんどのビジネス活動をモデル化するのに適していることがわかります。この形式はデータの受信者として適していることが明らかになりました。バーコードは50年代に発明されましたが、70年代になるまでコンピューティングハードウェアがデータを格納および処理する能力を十分に進化させるまで、それほど影響力はありませんでした。ただし、手動処理と比較してすでに非常に大きかったです。
Kieran Chandler: そうですね、そこで触れましたね。ERPという名前は90年代になってから付けられました。ERPは企業資源計画を意味します。しかし、その名前は実際にはどこから来たのでしょうか？なぜその名前を選んだのでしょうか？
Joannes Vermorel: 実際には、ERPは誤った名前です。残念ながら、その名前は90年代に入ってからのマーケティングのトリックのようなものでした。ERPシステムは基本的に計画とは何の関係もありません。より適切な名前は企業資源管理でした。起こったことは、データベースとバーコードリーダーの両方があるとすぐに、多くの企業がすべてのリソースを管理するためのコンピュータ化システムが欲しいと気付いたということです。彼らはデータベースと当時利用可能なデータ入力デバイスの上に独自のソフトウェア実装を展開し始めました。他のいくつかの企業は、多くのビジネスが表現に関して類似のニーズを持っていることに気付きました。例えば、すべてのビジネスは支払い、物理的な材料を扱う企業は在庫、従業員の給与を表現する必要があります。そのため、いくつかのソフトウェア企業は、「これらのビジネスモデルのパッケージ化されたバージョンを持ちましょう」と考え、それがERPの概念が生まれたところです。現在では、それを企業資源計画ではなく、むしろ企業資源管理と考えるのが最善です。
Kieran Chandler: では、初期のERPシステムの主な機能は何でしたか？
Joannes Vermorel: ERPは基本的に3つの要素で構成されています。エンティティ、ユーザーインターフェース、ワークフローロジックです。エンティティはテーブルの上にある抽象化です。例えば、製品を表現したい場合、“products"というテーブルがありますが、異なる属性やサプライヤーに対して複数のテーブルがあるかもしれません。エンティティは、製品、顧客、取引などのような高レベルの概念を表し、それらがデータベースにどのように格納されているかという低レベルの実装の詳細とは異なります。
ユーザーインターフェースは、CRUD操作（作成、読み取り、更新、削除）に特化しています。エンティティを扱う場合、ほとんどの場合、CRUDインターフェースで作業します。新しい製品を入力したり、既存の製品の詳細を確認したり、製品を変更したり、削除したりします。これは、取引、顧客などのすべてのエンティティに適用されます。
3番目の要素はワークフローロジックです。購買の例を取りましょう。まず、発注書を発行し、その後、サプライヤーが請求書で確認します。商品を受け取り、システムでそれを追跡する必要があります。ワークフローロジックは、何かが欠けている場合にアラートを表示し、数量が注文と一致していることを確認します。これに基づいて、商品をサプライヤーに返品するか、残りの商品を要求するかを決定することができます。ERPはこれらの日常的なタスクを自動化し、基本的なビジネス操作の結果を管理することで生産性を向上させます。
Kieran Chandler: ソフトウェアの世界では、それらの最初のソフトウェアからどれだけ変わったのでしょうか？非常に興味深いのは、その変化を理解するために、ERP市場を牽引しているダイナミクスを理解する必要があるということです。特にERPベンダーは、企業がそれらを独自に実装するのではなく、これらのシステムを実装するために重要な役割を果たしています。それについて詳しく見てみましょう。ほとんどのベンダーは、私がAllahと呼んでいる3つの戦略を採用しています。この戦略は市場を制するために成功しています。現在、成功しているERPベンダーの大部分は、これらの3つの手法を適用しています。
Joannes Vermorel: ERPベンダーが直面する主な課題は複雑さです。この課題に対処するためには、エンティティの生成、ユーザーインターフェース、ロジックを効率化する特定の技術が必要です。そのような技術の例として、ドメイン固有のプログラミング言語があります。たとえば、成功したERPベンダーであるCPは、ab appという独自のドメイン固有のプログラミング言語を開発し、競争他社よりも高速にエンティティ、ユーザーインターフェース、ロジックを展開するのに役立ちました。
Kieran Chandler: 興味深いですね。では、2番目の方法は提供と価格の構造を調整することです。それについて詳しく説明していただけますか？
Joannes Vermorel: もちろんです。ベンダーとして、ERPを製造するためのコストは、さまざまな要素を実装するために必要な労力に大きく影響を受けます。個々の要素は単純かもしれませんが、ERPは領収書の処理などの日常的なタスクに関連しています。ベンダーは多くのエンティティを製造しサポートする必要があるため、エンティティごとではなくモジュールごとに料金を請求することが合理的です。モジュールは関連するエンティティをグループ化し、ビジネス上の考慮事項に合わせます。これにより、ERPシステムがソフトウェアをどのように請求するかに関する興味深い点が浮かび上がります。
Kieran Chandler: 確かに。モジュールを追加するための追加料金がありますね。以前、ベンダーロックインについて話しました。ERPプロバイダーの経済的な利益は、このモジュールベースの価格設定と一致していますか？
Joannes Vermorel: 確かに、モジュールを導入すると、すべての機能を実装するコストに価格を合わせる効率的な方法が提供されます。しかし、それは特定のインセンティブも生み出します。ベンダーは既存のモジュールの上に販売するために新しいモジュールの開発を続ける動機を持っています。これにより、クライアントに対してさらに多くのモジュールを販売し続けるという結果になる可能性があります。しかし、その詳細については後ほど詳しく説明しますので、次のアイデアに進みましょう。
Kieran Chandler: わかりました。3番目のアイデアは何ですか？
Joannes Vermorel: 3番目のアイデアは、現実の微細な詳細を捉えることの複雑さのため、成功したERPベンダーはインテグレーターを通じてさらに高速に成長する方法を見つけています。1つの会社ではすべてを管理できないため、ERPベンダーは完全かつ包括的なソリューションを確保するために、インテグレーターと呼ばれる外部企業と協力します。
Kieran Chandler: では、Joannesさん、Lokadはクライアント向けに新機能を導入しているとおっしゃいましたね。それについてもっと詳しく教えていただけますか？
Joannes Vermorel: はい、確かに。私たちはクライアント向けに新機能を導入しています。それには新しいエンティティ、新しいユーザーインターフェース、新しいロジックが含まれます。この機能を実装するために、インテグレーターと呼ばれるパートナーのネットワークを作成しています。ビジネスモデルの観点からは、この機能に関連するコストとリスクをベンダー企業からオフロードすることが興味深いです。サードパーティ企業にアウトソースできる機能の長いテールがあります。
Kieran Chandler: つまり、ソフトウェアベンダーはリスクをインテグレーターに移し、最終的にはクライアントに移すということですね。インテグレーターには独自のインセンティブがあり、それがソフトウェアベンダーのインセンティブと完全に一致しない可能性があります。それは正しいですか？
Joannes Vermorel: まさにその通りです。インテグレーターは、組み込みモジュールよりも特注モジュールのためにより多くの報酬を得るため、クライアントに高度なカスタマイズを提供するインセンティブを持っています。彼らは、自社のビジネスがユニークであり、ユニークさを反映したソリューションが必要であるとクライアントを説得することができます。興味深いダイナミックです。
Kieran Chandler: なるほど。ERPシステムに関しては、企業が取ることができるさまざまなアプローチがありますね。良いアプローチと悪いアプローチをどのように判断しますか？
Joannes Vermorel: 現在では、ERPの選択を考える際に、1970年代後半にERPに組み込まれたすべての制約がまだあなたの状況に適しているかどうかを疑問視する必要があります。それはいくつかの要素に依存します。たとえば、すべてを1つのシステムに統合する必要があるという考えはしばしば無意味です。複雑さは線形的にスケールしません。システムにさらにエンティティを追加すると、さまざまな業界が「製品」と考えるものにおいてエッジケースとバリエーションが増えます。
Kieran Chandler: つまり、すべてを処理するために1つのシステムがまだ必要かどうかという前提を再評価する必要があると言っているのですね。
Joannes Vermorel: まさにその通りです。その前提はもはや正確ではありません。調整が必要な100の異なるシステムを持つことは困難ですが、すべてを処理するための1つのマスターシステムも問題があります。そのようなシステムに変更を加えたい場合、それは会社のすべての機能に影響を与える大規模なプロジェクトになります。
Kieran Chandler: わかりました。新しいシステムへの移行はかなり困難な場合がありますね。一部の企業は新しいERPシステムへの切り替えを試みる際に高額な失敗を経験しています。そのような移行を行うことは実際にはどれだけ実用的なのでしょうか？
Joannes Vermorel: 確かに、新しいERPシステムへの移行は困難な場合があります。何十億ドルもの費用を無駄にする企業も見てきました。実際には簡単なタスクではありません。
Kieran Chandler: 2009年には、ASAPのアップグレードに5億ユーロもの費用がかかりました。それは展開ではなく、単なるアップグレードでした。ですから、ERPのアップグレードは新しいシステムへの移行よりも困難なのでしょうか？
Joannes Vermorel: とても興味深い質問です。驚くべきことに、ERPのアップグレードは通常、新しいシステムへの移行よりも困難です。直感に反するかもしれませんが、私が観察した結果です。新しいERPに移行する場合、大規模な作業であることに疑いはありません。しかし、単なるアップグレードと考えると、簡単に聞こえるかもしれませんが、実際には非常に困難な作業になることがあります。
問題は、バージョン間の移行時にエンティティの意味が変わることです。ERPは、製品など、ビジネスのさまざまな関心事を反映するエンティティを表現することに関してすべてです。ERP内のこれらのエンティティの意味はベンダーによって定義されると思われるかもしれませんが、それは完全には真実ではありません。エンティティの最終的な意味は、システムとデータ入力、ワークフローを実行する人、つまりオペレーターの目にあります。
したがって、エンティティの真の意味は、ERPベンダーにとっては制御できません。彼らは推奨事項やトレーニングプログラムを提供することはできますが、最終的には困難です。一部の企業は、ERPを特定の状況で動作させるために、わずかに異なる意味を持たせることを決めるかもしれません。彼らが反逆者であるわけではなく、ERPを動作させるために必要なことです。
しかし、次のバージョンに移行すると問題が発生します。新しい開発やさまざまなエッジケースにより、エンティティが突然まったく同じ意味を持たなくなる場合があります。
Kieran Chandler: それは興味深いですね。一方では、大規模なモノリシックなアプローチがあり、もう一方では、より専門化された小規模なERP企業があります。次の10年を生き残れないかもしれないこれらの小規模な企業にどれだけの信頼を置けるのでしょうか？
Joannes Vermorel: 小規模な企業の場合、複雑さが自社の規模に合っているシステムが必要です。ERP製品は時間の経過とともにより複雑になります。ですから、5年ほどの若い企業で急速に成長している場合、30年または40年前のERPに固執するのは間違っています。これらの古い製品は非常に複雑で、数百、数千のテーブルやエンティティを持っていることがあります。そのような複雑さに対処することは圧倒的です。
ですから、私のアドバイスは、いくらかのリスクを伴うかもしれない若いERP企業を検討することです。複雑さの山に自分自身を埋め込むことに注意してください。私はLokadを10年以上運営してきた経験から、ERPの選択だけで会社が困難な状況に直面することはありませんでした。しかし、自社の規模に比べてはるかに複雑な製品を導入することは、実際には有害であり、ビジネスを破壊することさえあります。私は頻繁にそれを目撃してきました。企業が複雑さと機能の面で自分たちにとってあまりにも大きすぎるソフトウェアを受け入れたために苦労しているのです。
Kieran Chandler: 成長する企業にとって、ソフトウェアを選ぶ際には強力なコアと連携したアプリケーションが重要ですね。ジョアネス、このアイデアについて詳しく説明していただけますか？
Joannes Vermorel: 確かに。それは直感に反する本質ですが、現在の複雑さと規模を反映した狭いコアを持つものの方が良いです。必要な機能が不足している場合は、常に統合を通じて不足している部分を補完することができます。一方、競合する機能が多すぎると問題が発生することがあります。使用されない機能はプロセスに混乱をもたらし、単純なタスクを実行することを妨げます。完全に統合されたソフトウェア製品は、特定の機能を削除または変更することなく、システム全体に影響を与えることなく、特定の機能を削除または変更することが困難です。
L6 Kieran Chandler: ですから、より小さな製品を選んでも、これらの問題を完全に解消するわけではありませんか？
Joannes Vermorel: いいえ、これらの問題の重要性と大きさは、ソフトウェア内の複雑さとエンティティに依存します。ただし、会社の規模も役割を果たします。100人未満の小規模企業の場合、人事、給与、在庫管理など、さまざまな領域をカバーするために、狭くてシンプルで費用効果の高いSaaSアプリケーションのような解決策を見つけることをお勧めします。すべてを包括する単一のERPを持つ必要はありません。ただし、これらのアプリケーションがデータを抽出するためのAPIを持っていることを確認しておきましょう。必要に応じて後で統合することができます。
Kieran Chandler: なるほど。中規模の企業はどうですか？
Joannes Vermorel: 中規模の企業（約500人）の場合、より包括的なERP製品を検討することができます。これは、多くのテーブルと機能を備えた複雑なものになります。この時点で、管理するべきビジネスの典型的な側面がいくつかあり、ERPはそれらのニーズに対応できます。より長期の導入プロジェクトと優れた統合業者が必要になるかもしれませんが、望ましい機能を提供することができます。
Kieran Chandler: それは、限界を示し始めている小さなアプリよりも生産的ですね。では、もしもっと大きな会社であれば、状況はまた変わると言えるでしょう。もしもっと大きな会社であれば、もっと… つまり、5,000人の従業員のような… 大企業の場合、本当に重要な2つの要素があると言えます。まず、葉でそれらを分割したいと思うでしょう。もしも大きな会社であれば、モノリスはうまくいかないでしょう。大企業が行っているのは、モノリシックなERPです。私は言います… ほとんど… つまり、醜くなるでしょう。数年かかります。非常に高額になります。
Joannes Vermorel: 最も優れた大企業が行っていることを見ると、彼らは通常、かなり特注のものを展開しています。そして、それには非常に良い理由があります。大企業であれば、単純なものではない、独自の競争上の優位性を持っている可能性が高いです。それは、大規模で複雑な組織に埋め込まれており、おそらく買収も行っているかもしれません。したがって、最初からエラティックなジーニアスの景色を持っているかもしれません。だから、「すべてを統治するための1つのERPが欲しい」と言う代わりに、それは500人の従業員がいたときに機能していたものですが、5,000人の従業員がいると非常に困難になります。私の提案は、基本的に分割して征服する必要があるということです。非常に小さかったときに私が提案していたこのアプローチは、大きな場合にはまったく異なる方法で再評価することができます。
ですから、例えば、景色を12の機能領域に分割すると言います。そして、各領域ごとにビルドまたはバイするかどうか、ベンダーが良いかどうかに応じて、ビルドまたはバイします。そして、最も大きな課題は、それらの大企業に対してお勧めすることです。すべてを統治するために1つのERPが必要だという教義を破ることです。それはほとんど… というか、ほとんどの場合は無意味です。そして、非常に競争力のあるプレーヤー、例えばAmazon、Alibaba、Rakuten、Zalandoなどを見てみましょう。物理的なサプライチェーンに対処しなければならないこれらのテックプレーヤーについて話しているわけではありません。Microsoftのような純粋なデジタルプレーヤーではありません。彼らにはXboxがあります。Xboxは非常に物理的な製品です。しかし、Amazonのような物理的なサプライチェーンを管理することができると認識されている企業を見ると、彼らはアプリケーションの景色において非常に攻撃的なビルドまたはバイのアプローチを取っています。そして、基本的に、これらの企業のどれも本当のERPを持っていません。彼らは製品のリストを持っています。それらのうちのいくつかはERPに近いかもしれません。そして、それらの企業のほとんどは、通常ERPモジュールとして言及されるものの特定の部分のために独自のシステムを開発しました。
Kieran Chandler: さて、ここで終わりにしなければなりませんが、今朝はお時間をいただきありがとうございました。
Joannes Vermorel: ありがとうございます、Kieran。
Kieran Chandler: それでは今週は以上です。では、また次回。さようなら。
