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 締めくくりの考察.
要約
ケイラン・チャンドラーとのインタビューで、Lokadの創業者ジョアンネス・ヴェルモレルはエンタープライズ-リソース-プランニング-erp（ERP）システムの進化について語る。1970年代にその起源を辿り、ヴェルモレルはリレーショナルデータベースとバーコードリーダーという二つの主要な革新がERP開発に不可欠であったと強調する。彼は、これらのシステムが企業ごとの特注ソリューションからあらかじめパッケージ化されたビジネスモデル表現へと進化したことから、「エンタープライズリソースマネジメント」という用語の方がより正確であると示唆している。さらに、CRUDインターフェースやワークフローロジックなどのERPの現代的機能は、定型業務の自動化により生産性を向上させている。ヴェルモレルは、SAPのような成功しているERPベンダーがシステムの複雑性を管理するための戦略についても論じ、さまざまな規模の企業に対するERPの選定と実装についても触れている。
詳細な要約
インタビューでは、ホストのケイラン・チャンドラーがLokadの創業者ジョアンネス・ヴェルモレルと共に、エンタープライズリソースプランニング（ERP）システムの進化と機能について議論する。
ヴェルモレルはERPシステムの起源を1970年代に求めており、用語としての「ERP」が90年代に作られたにもかかわらず、実際のシステムはそれ以前に始まっていたと指摘する。彼によれば、ERPシステムの発展には二つの重要な革新が寄与している。第一は、コンピューティングハードウェアの進化によりリレーショナルデータベースが可能になったことである。初期は基本的なものであったが、これらのデータベースはデータを柔軟に整理する手段を提供した。テーブルとカラムからなるリレーショナル形式は、取引、支払い、顧客およびサプライヤとのやり取りなど、さまざまなビジネス活動のモデリングに適していた。
ヴェルモレルが言及する第二の重要な革新はバーコードリーダーの発明である。バーコードリーダーは1950年代に登場したが、十分なデータを記憶・処理できるほどにコンピュータハードウェアが進化するまで、1970年代まではその影響力は限定的であった。この二つの技術の組み合わせが、今日我々が知るERPシステムを生み出した。
また、ヴェルモレルはERPという呼称の誤りについても触れ、これが90年代に始まったマーケティング的な策略であると述べる。彼は、ERPシステムは計画とはほとんど関係がなく、むしろ管理に重点を置いているため、「エンタープライズリソースマネジメント」という名称の方が適切だと説明する。これを、初期段階で多くの企業が当時利用可能なデータベースやデータ入力装置を用いてリソース管理のための自社ソフトウェアシステムを開発し始めた事実で例証している。
支払い、在庫、従業員など、企業が表現する必要のある共通点に着目し、一部の企業はこれらのビジネスモデル表現のパッケージ版の提供を始めた。ヴェルモレルは、これが現在我々がERPシステムと呼ぶものの起源であることを示す一方、実際の機能性を考慮すると、これらをエンタープライズリソースマネジメントシステムと捉えるべきだと提案している。
ユーザーインターフェースは通常、CRUD（作成、読み取り、更新、削除）インターフェースと分類され、これらのエンティティ上で動作する。例えば、新製品の追加（作成）、既存製品の属性の閲覧（読み取り）、製品の修正（更新）、および製品の削除（削除）など、基本的なデータ入力作業が可能である。このCRUDパターンは、取引、顧客など、ERPシステム内のあらゆるエンティティに適用される。
三番目の要素はワークフローロジックであり、ここで自動化が実現する。ヴェルモレルは購買プロセスの例を挙げ、まず発注書を発行し、次に仕入先が請求書で確認し、そして商品が出荷される流れを説明する。ERPシステムはこれらの工程を追跡し、もし商品が受領されなかった場合にはユーザーへ警告を発する。さらに、受領数量が発注数量と一致しない場合、仕入先に不足分を送付するか、または商品を返却するかといった次の措置を提案する。このような定型業務の自動化は大幅な生産性向上につながる。
ERPの進化に話を移すと、ヴェルモレルはシステム形成におけるベンダーの役割を強調する。彼は、ベンダーにとって最大の課題は、無限に続くエンティティ、ユーザーインターフェース、ロジックの実装による複雑性の管理であると指摘する。そして、成功しているERPベンダーがこの複雑性を管理し競争力を維持するために採用している「三段階」の戦略に言及する。
第一に、ベンダーはエンティティ、ユーザーインターフェース、ロジックの生産を効率化するため、特定の技術を採用する。ヴェルモレルは、成功しているERPベンダーであるSAPの例を挙げ、実装プロセスを迅速化するために独自のドメイン固有プログラミング言語ABAPを開発したと述べる。
第二に、ベンダーは多様なエンティティの生産およびサポートに伴うコストと労力を反映するため、製品と価格設定の構造を調整する。これにより、エンティティをビジネス上意味のあるモジュールにまとめ、顧客が使用するモジュールに基づいて課金するモジュールベースの価格体系が構築されることが多い。
エンタープライズソフトウェアの世界で支配的な存在となったERPシステムは、企業とその複雑な業務のニーズに応えるため、絶えず進化し適応している。
ヴェルモレルはまず、ERPベンダーのインセンティブとビジネスモデルについて論じる。彼は、これらのベンダーが顧客に新たなモジュールや機能を継続的に開発して販売する動機付けを受けていることを説明する。ベンダーは各成功した実装を、顧客にさらにモジュールを提供するチャンスと捉え、これが販売と開発の絶え間ないサイクルを生み出す。
その後、会話は異なるERPアプローチの選択に移る。ヴェルモレルは、企業が1970年代後半に組み込まれた制約が、今日の自社の状況に依然として当てはまるかどうかを問うべきだと示唆する。彼は、単一の統合システムの必要性に疑問を呈し、このアプローチが複雑性の増大や多数の例外事例を引き起こす可能性があると主張する。代わりに、企業は一つのシステムで全てを賄うという前提を見直し、あまりにも多くの異なるシステムを持つことの危険性に注意するよう勧告する。
新たなERPシステムの実装について議論する中で、ヴェルモレルは、新システムへの移行や既存システムのアップグレードに伴う重大なリスクとコストに触れる。彼は、2009年にSAPのアップグレードで5億ユーロを浪費した企業の例を挙げ、ERPシステム内のエンティティの意味論が（システムの運用者によって大きく左右される）バージョン間で微妙ながらも大幅に変化し、多数の例外事例や課題を引き起こすことを強調する。
ヴェルモレルは、小規模なベンダーにもある程度のリスクが伴うと考えているが、現在の企業の複雑性や規模を反映した狭いコアを持つ製品を選ぶ方が賢明だと述べる。彼は、業務を混乱させる過剰な機能を避け、必要に応じて統合によって補完可能な製品を選ぶことを推奨する。
議論はまた、企業規模に応じた適切なERP選択にも触れている。ヴェルモレルは、従業員100人未満の小規模企業は、狭くシンプルかつ費用効果の高いSaaS（Software-as-a-Service）アプリケーションを選ぶべきだと示唆する。彼は、包括的なERPに依存するのではなく、特定のニーズをカバーする2～3の個別アプリの利用を推奨する。従業員約500人の中規模企業については、より複雑な中規模ERP製品を検討すべきだとし、一般的なビジネス機能の幅広い対応が可能であると示唆する。しかし、従業員が数千人に上る大企業の場合、ヴェルモレルはモノリシックなERPアプローチを避け、分割統治の戦略を提案する。彼は、業務領域を機能ごとに分割し、それぞれに適したソリューションを構築または購入することを推奨し、単一のERPシステムを実装しようとする試みは控えるべきだと述べる.
完全なトランスクリプト
Kieran Chandler: 今日は、この種のエンタープライズソフトウェアがどのようにして生まれ、その多様な選択肢の中から企業がどのように選択するかを探っていきます。では、ジョアンネス、まずERPシステムの起源について見ていくところから始めましょう。最初はどのようにして生まれたのですか？
Joannes Vermorel: ERPシステムは1970年代の二つの原動力から生まれました。ちなみに、用語としてのERPは90年代に作られましたが、我々が通常ERPシステムと呼ぶものは実際には1970年代に始まったのです。二つの重要な革新がありました。一つ目はデータベースシステム、すなわちコンピュータハードウェアの進化によりリレーショナルデータベースが可能になったことです。これが第一の革新でした。二つ目はバーコードリーダーです。この二つの革新を組み合わせると、リレーショナルデータベースが非常に柔軟で、支払い、顧客、サプライヤ、取引など、ほとんどのビジネス活動のモデリングに非常に適していることが実感できました。この形式は、データの受け皿として非常に適していると分かりました。バーコードは1950年代に発明されましたが、十分なデータを記憶・処理できるほどにコンピュータハードウェアが進化するまで、その影響は限定的でした。しかし、手作業による処理と比較すれば、既に大きな存在でした。
Kieran Chandler: なるほど、そこで触れてくれましたね。ERPという名称は少し後になってから、90年代に登場したのですね。ERPはエンタープライズリソースプランニングの略です。しかし、その名称は一体どこから来たのでしょうか？なぜその名前を採用したのですか？
Joannes Vermorel: 実は、ERPは誤称です。残念ながら、その名称は90年代に生まれたマーケティング的な策略に過ぎません。ERPシステムは本来、計画とはほとんど関係がなく、むしろ管理に重点を置いているため、より適切な名称はエンタープライズリソースマネジメントであるべきです。データベースとバーコードリーダーが登場するとすぐに、多くの企業がこれらのリソースを管理するためのコンピュータ化システムを求め始め、当時利用可能だったデータベースやデータ入力装置を基盤に各社独自のソフトウェア実装を展開しました。また、ある企業は、多くのビジネスが支払い、物理的資材の在庫、従業員の給与など、共通の表現を必要としていることに気付き、「これらのビジネスモデルのパッケージ版を提供しよう」としたことが、ERPの概念誕生の原点となりました。現在では、エンタープライズリソースプランニングではなく、むしろエンタープライズリソースマネジメントとして捉えるのが最適です。
Kieran Chandler: では、初期のERPシステムの基本的な機能は何だったのでしょうか？
Joannes Vermorel: 基本的に、ERPは３つの要素で構成されています。すなわち、エンティティ、ユーザーインターフェース、そしてワークフローロジックです。エンティティはテーブルの上にある抽象概念です。例えば、製品を表現したい場合、「products」というテーブルが存在しますが、異なる属性やサプライヤーごとに複数のテーブルが存在することもあります。エンティティは、データベースに実際にどのように保存されるかという低レベルの実装詳細ではなく、製品、顧客、取引などの高レベルの概念を表現します。
ユーザーインターフェースは、特にCRUD操作（作成、読み取り、更新、削除）のために設計されています。ほとんどの場合、エンティティを扱う際は、CRUDインターフェースを操作することになります。新しい製品の入力、既存製品の詳細確認、製品の修正、あるいは削除など、これが取引、顧客などすべてのエンティティに適用されます.
三番目の要素はワークフローロジックです。例えば購買プロセスを考えてみましょう。まず発注書を発行し、次に仕入先が請求書で確認、そして商品が出荷されます。ERPシステムはこれらのステップを追跡し、もし商品が受領されなかった場合には警告を発します。また、受領数量が発注数量と一致しない場合、仕入先に不足分を送るか、商品を返却するかの次の措置を提案します。ERPはこれらの定型業務を自動化し、基本的なビジネス運営から生じる結果を管理することで生産性を向上させます.
Kieran Chandler: ソフトウェアの世界では、これら初期のシステムからどれほど変化したのでしょうか？非常に興味深いのは、その変化を理解するためには、ERP市場を牽引するダイナミクスを理解する必要があるということです。特にERPベンダーは、企業自らが実装するのではなく、システムの導入において大きな役割を果たしています。それについて詳しく見ていきましょう。ほとんどのベンダーは、私が「アラー」と呼ぶ三段階の戦略を採用しており、この戦略が市場を獲得するのに成功しています.
Joannes Vermorel: ERPベンダーが直面する最大の課題は複雑性です。この課題に取り組むためには、絶え間なく生み出されるエンティティを実装し、意味のあるユーザーインターフェースやワークフローを提供する必要があります。競争力を高める最初の方法は、エンティティ、ユーザーインターフェース、ロジックの生成を効率化する特定の技術を持つことです。そういった技術の一例として、ドメイン固有のプログラミング言語があります。たとえば、成功しているERPベンダーCPは、「ab app」と呼ばれる独自のドメイン固有プログラミング言語を開発し、競合他社よりも速くエンティティ、ユーザーインターフェース、ロジックを展開するのに役立ちました。
Kieran Chandler: 興味深いですね。では、第二の方法は、提供内容と価格設定の構造を調整することです。もう少し詳しく説明していただけますか？
Joannes Vermorel: もちろんです。ベンダーとして、ERPの製造コストは、さまざまな要素を実装するために必要な労力に大きく左右されます。各部分は個別には単純かもしれませんが、ERPは領収書処理などの単調な作業を扱うものです。ベンダーは多数のエンティティを作成しサポートしなければならないため、個々のエンティティごとに課金するのではなく、モジュールごとに課金を始めるのが理にかなっています。モジュールは関連するエンティティをまとめ、事業上の観点とも整合します。これは、ERPシステムがソフトウェアに対してどのように料金を請求するかという興味深い点を提示します。
Kieran Chandler: その通りです。つまり、モジュールを追加するごとに追加料金がかかりますね。先ほどベンダーロックインについて議論しましたが、ERPプロバイダーの経済的利益は、このモジュールベースの料金体系と一致しているのでしょうか？
Joannes Vermorel: 確かに、モジュールを導入すると、すべての機能を実装するためのコストに合わせて料金を効率的に調整する方法が得られます。しかし、それは同時に特定のインセンティブも生み出します。ベンダーは、既存のモジュールに加えて新たなモジュールを開発し販売し続ける動機付けを受けます。これにより、クライアントに対してモジュールを次々と販売する終わりのないサイクルが生じる可能性があります。しかし、その詳細に入る前に、第三のアイデアに進みましょう。
Kieran Chandler: では、第三のアイデアは何でしょうか？
Joannes Vermorel: 第三のアイデアは、現実の細かなディテールをすべて捉えるという膨大な複雑性のために、成功しているERPベンダーがインテグレーターを通じてさらに急速に成長する方法を見出すということです。一つの企業で全てを管理することは不可能なため、ERPベンダーは、最後の一里を担当し、完全かつ包括的なソリューションを確実にするために、インテグレーターと呼ばれる外部企業と協力します。
Kieran Chandler: それでは、ジョアネス、以前ロカッドがクライアント向けに新しい機能を導入しているとおっしゃっていましたが、その詳細を教えていただけますか？
Joannes Vermorel: はい、確かに。私たちはクライアント向けに新しい機能を立ち上げます。それには新たなエンティティ、新しいユーザーインターフェース、そして新しいロジックが含まれます。この機能を実装するために、インテグレーターと呼ばれるパートナーのネットワークを構築しています。ビジネスモデルの観点から、これはERPベンダーにとって興味深いものであり、この機能に関連するコストとリスクを外部にアウトソースできるメリットがあります。アウトソース可能な機能は多数存在します。
Kieran Chandler: つまり、ソフトウェアベンダーはリスクをインテグレーターに、そして最終的にはクライアントに転嫁するということですね。インテグレーターにも独自のインセンティブがあり、それがソフトウェアベンダーのインセンティブと完全に一致しない場合もあるのでしょうか？
Joannes Vermorel: その通りです。インテグレーターは、既製のモジュールよりもカスタムモジュールでより多くの報酬を得られるため、クライアントに高度なカスタマイズを提供しようというインセンティブがあります。彼らは、クライアントの事業が独自であり、その独自性を反映するソリューションが必要だと説得することができます。これは非常に興味深いダイナミクスです。
Kieran Chandler: なるほど。ERPシステムに関しては、企業が取るべきアプローチにさまざまなものがあるのですね。では、どのようにして良いアプローチと悪いアプローチを判断するのでしょうか？
Joannes Vermorel: 現代においてERPを選択する際には、1970年代後半にERPに組み込まれたすべての制約が現在の状況においても依然として有効かどうかを問い直す必要があります。これはいくつかの要因に依存します。例えば、すべてを一つのシステムに統合する必要があるという考えはしばしば無意味です。なぜなら、複雑性は線形には拡大しないからです。システムにエンティティを追加すればするほど、各業界が「製品」と見なすものにおいて、より多くのエッジケースや変種が発生します。
Kieran Chandler: つまり、全てを扱うために一つのシステムが必要であるという前提を再検討する必要があると言うのでしょうか？
Joannes Vermorel: その通りです。その前提はもはや正確ではありません。調整しなければならない100個の独立したシステムを持つのは困難ですが、すべてを統べる一つのマスターシステムを持つのもまた問題があります。そのようなシステムに変更を加えようとすると、企業内のすべての機能に影響を及ぼす大規模なプロジェクトになってしまいます。
Kieran Chandler: 理解しました。新しいシステムへの移行は非常に困難な場合もあるようですね。新しいERPシステムへの切り替えで多大な費用がかかる失敗を経験した企業もありますが、その移行はどれほど現実的なのでしょうか？
Joannes Vermorel: 確かに、新しいERPシステムへの移行は非常に挑戦的です。我々は、そのような移行により何十億ドルもの無駄が生じた事例を見てきました。実際、これは容易な作業ではありません。
Kieran Chandler: 2009年、彼らはASAPのアップグレードに5億ユーロもの無駄遣いをしました。それは展開ではなく、単なるアップグレードだったのです。では、質問です。ERPのアップグレードは、新しいシステムに移行するよりも困難なのでしょうか？
Joannes Vermorel: 非常に興味深い質問です。驚くべきことに、ERPのアップグレードは新しいシステムへの移行よりも通常は困難です。直感に反するかもしれませんが、私が観察したところその通りです。新しいERPに移行する際は、それが大規模な作業になるという幻想はありません。しかし、単なるアップグレードだと考えると、簡単に聞こえるかもしれませんが、実際には非常に非常に困難になり得ます。
問題は、あるバージョンから次のバージョンへ移る際に、エンティティの意味論に変化が生じることです。ご存知の通り、ERPは製品など、ビジネスにおける様々な関心事を反映するエンティティを表現するものです。ERPにおけるこれらのエンティティの意味論はベンダーによって定義されると思われがちですが、それは必ずしも正確ではありません。エンティティの最終的な意味は、そのシステムとやり取りし、データ入力やワークフローを実行するオペレーターの目に委ねられています。
つまり、エンティティの真の意味論はERPを操作する人によって決定されます。不運にも、ERPベンダーは人々が実際に製品をどのように使用するかを大きく制御することができません。彼らは推奨事項やトレーニングプログラムを提供することはできますが、結局のところ、それは非常に困難です。ある企業は、ERPを自社の状況に合わせて機能させるために、若干異なる意味論を採用するかもしれません。それは彼らが反体制的だからではなく、ERPを機能させるために必要なことなのです。
しかし、次のバージョンに移行すると問題が発生します。新たな進展や無数のさまざまなエッジケースにより、エンティティの意味が突然全く同じでなくなる細かな事例が数多く発生する可能性があります。
Kieran Chandler: それは興味深いですね。つまり、スペクトルの一端には大規模なモノリシックなアプローチがあり、もう一方にはより小規模で専門性の高いERP企業があるということです。今後10年で生き残れないかもしれないこれらの小規模企業に、どれほどの信頼を置くことができるのでしょうか？
Joannes Vermorel: 小規模な企業であれば、自社の規模に即した複雑性が意味をなすシステムが望ましいです。ERP製品は時間とともにますます複雑になりがちです。ですから、もしあなたの会社が設立してまだ5年程度で急成長しているのであれば、3、4世紀前のERPに固執するのは誤りです。これらの古い製品は、何百、時には何千ものテーブルやエンティティがあり、非常に複雑なものとなり得ます。そのような複雑性に対処するのは、圧倒されるほどです。
ですから、私のアドバイスは、ある程度のリスクが伴っても、若いERP企業を検討することです。複雑性に埋もれてしまわないよう注意してください。10年以上にわたってロカッドを運営してきた経験から、ERPの選択だけが原因で劇的な状況に直面した企業は見たことがありません。しかし、自社の規模以上に複雑な製品を展開することは、実際に害になり、事業を破綻させる可能性すらあります。複雑さと機能が自社にとって過剰であったために苦労する企業を頻繁に見てきました。
Kieran Chandler: ソフトウェアを選ぶ際には、強固なコアと相互に連携するアプリケーションを持つことが、成長企業にとって非常に重要であるようです。ジョアネス、この考えをもう少し詳しく説明していただけますか？
Joannes Vermorel: その通りです。直感に反する本質は、たとえ一部機能が欠けていても、現状の複雑性と規模を反映する狭いコアを持つものを選ぶ方が良いということです。不足している部分は、統合によって補完することができます。一方で、あまりにも多くの矛盾する機能を持つと問題を引き起こすことがあります。未使用の機能は、プロセスに混乱をもたらし、単純な作業の遂行を妨げる傾向があります。完全に統合されたソフトウェア製品は、システム全体を混乱させずに特定の機能を削除または変更することを困難にします。
Kieran Chandler: では、小規模な製品を選ぶことがこれらの問題を完全に解消するわけではないのですか？
Joannes Vermorel: いいえ、これらの問題の大きさや重要性は、ソフトウェア内の複雑性やエンティティに依存します。しかし、企業の規模も重要な要素です。従業員が100人未満の小規模な企業の場合、狭くシンプルでコスト効率の良いSaaSアプリのようなソリューションを見つけることが推奨されます。人事、給与、そして inventory management など、さまざまな分野をカバーするために2～3個のアプリが必要になるかもしれません。すべてを網羅する単一のERPを持つ必要はありません。必要に応じて後で統合できるよう、これらのアプリにAPIが備わっていることを確認してください。
Kieran Chandler: それは納得できます。中規模企業の場合はどうでしょうか？
Joannes Vermorel: 中規模企業、例えば従業員数が約500人の場合は、より包括的なERP製品を検討することができます。それはより複雑で、多数のテーブルや機能を有するでしょう。この段階では、管理すべきビジネスのさまざまな典型的側面が存在し、ERPがそれらのニーズに対応できるのです。実装プロジェクトが長期化し、優れたインテグレーターが必要になるかもしれませんが、望ましい機能性を提供します。
Kieran Chandler: 小規模なアプリがその限界を見せ始めているのに比べ、こちらの方が生産的です。しかし、もし企業がより大規模であれば、状況はまた変わってきます。例えば、従業員が5,000人規模の大企業の場合、通常2つの重要な点が浮上します。まず、システムを細分化する必要があります。大企業でモノリシックなERPに依存すると、明らかにうまくいかないからです。ほとんどの大企業がモノリシックなERPを採用している場合、見た目は醜く、何年もかかり、信じられないほどのコストがかかると言えるでしょう。
Joannes Vermorel: 最高の大企業が何をしているかを見ると、彼らは通常、かなりカスタムメイドなシステムを展開しているのが見て取れます。そして、それには非常に明確な理由があります。大企業であれば、単純なものではない、独自の競争上の優位性を持っている可能性が高いです。それは、大規模で複雑な組織に埋め込まれており、場合によっては買収も経験しているかもしれません。つまり、元々、非常に独特な状況になっているのです。ですから、「すべてを統べる一つのERPが欲しい」と言うのではなく、従業員が500人のときは機能していたとしても、5,000人になると非常に困難になります。私の提案は、基本的に分割して統治する、いわばDivide and Conquerの戦略を採るべきだということです。かつて、小規模な企業向けに数個のアプリを提案したアプローチを、大企業の場合には全く異なる方法で見直すことができます。
つまり、私が提案するのは、全体の風景を、例えば最大で十数の機能領域に分割し、そして各領域ごとに、見つけられるベンダーが優れているかどうかに応じて、自作するか購入するかを決定するということです。そして、大企業に私が最も勧めたいのは、「すべてを統べる一つのERPが必要」というドグマを根本から打破することです。これはほとんど、いや大部分は無意味だと私は考えます。非常に競争力のあるプレイヤー、例えばAmazon、Alibaba、Rakuten、Zalandoのような、物理的なサプライチェーンを管理しなければならないテック企業を見ると、彼らは皆、非常に積極的にビルドかバイのアプローチ、つまりDivide and Conquer戦略を取っています。そして実際、これらの企業は本当の意味でのERPを持っているわけではなく、製品のリストを持っているに過ぎません。一部はERPに近いものですが、ほとんどの企業は特定のERPモジュールと呼ばれる部分について、独自のシステムを構築しているのです。
Kieran Chandler: さて、ここで締めくくらなければなりませんが、今朝は貴重なお時間をありがとうございました。
Joannes Vermorel: ありがとうございます、Kieran。
Kieran Chandler: 今週はこれで全てです。それでは、さようなら。
