企業資源計画（ERP）

ERP（企業資源計画）は、企業の日常業務をサポートし、現金、原材料、進行中の作業、最終製品、顧客注文、発注、給与などのリソースを追跡する企業ソフトウェアの一種を指します。ERPには、会計、調達、流通、財務、販売などの主要な業務機能を対象とした多くのモジュールが含まれており、これらのモジュール内で（トランザクションの）情報の流れを容易にするための緊密な統合を提供しています。ERPはリレーショナルデータベースの上に構築され、通常非常に広範な設計を特徴としています。多数のエンティティ（製品、顧客、請求書など）、多数の画面、高度な設定可能性があります。

起源と動機

70年代になると、従来の紙の記録と比較して、電子記録には複数の利点があることが徐々に明らかになってきました。電子記録は、紙の記録よりも安価で、高速で、信頼性が高くなっていました。 ERPsよりも前に登場した2つの発明が、電子記録の活用を可能にしました：バーコードリーダー（1950年代）とリレーショナルデータベース（1970年代）。バーコードリーダーは、商品の流れを管理するための優れた方法を提供し、生産性を向上させながら事務的なエラーを減らしました。しかし、バーコードリーダーは多くの状況でデータの取得を劇的に改善した一方で、電子記録の保存、整理、処理は20年間ほどの間、ある種の未解決の問題でした。リレーショナルデータベースは、70年代後半にこの問題に対するソフトウェア業界の対応策であり、50年後もなお、ビジネスデータ管理において主流の実践となっています。

ただし、80年代初頭に一般的に販売された裸のリレーショナルデータベースシステムは、実装に非常に高価であることが判明しました。なぜなら、すべての企業がデータベース内のすべての要素をどのように表現するかを再発明していたからです：製品、顧客、請求書、支払いなど。そのため、80年代には、「事前設定済み」のリレーショナルシステムを販売するソフトウェア会社が次々と現れました。これらの製品は後にERPと総称されるようになり、この用語は90年代に生まれました。残念ながら、ERPという頭字語は誤りです。ERPは、計画ではなく、むしろ企業資源管理であるべきでした。実際、計画は最大でもERPsの二次的な関心事です。以下で詳しく説明するように、予測分析は基本的なERPの設計とは相容れません。

歴史的に、ERPsは、以前は広範な事務作業を必要とした一連の操作を効率化しました。たとえば、サプライヤーに発注書を発行するには、サプライヤーの名前と住所を記入する必要がありました。注文行には有効な製品参照のみを含める必要がありました。次に、商品の受け取り時には、受け取った数量が元の発注書に記載されている数量と一致する必要があり、配送が適合と見なされた場合、適切な金額、サプライヤーの支払条件に一致する日付、正しくサプライヤーの銀行口座番号を含むテンプレートに対して支払い命令が生成される必要がありました。これらすべてはERPに見つけることができ、整合性チェックは自動的に簡単に行うことができます。

90年代後半には、コンピューティングハードウェア（プロセッサ、メモリ、ストレージ）の着実な進歩により、ERP市場は急速に成長し、あらゆる規模の企業にアクセス可能になりました。

90年代には、ビジネスが主に商品の流れを中心としていた場合、ERPsはほとんどの大企業のソフトウェアコアとなりました。対照的に、主にサービスに重点を置いた企業は、顧客関係管理（CRM）ソフトウェアをコアとして採用しました。ERPsとCRMsは、リレーショナルデータベースの上に共通の設計を採用しているため、多くの属性を共有しています。ERPsは、ほとんどの機能においてトランザクション中心の視点を採用していますが、CRMsは顧客中心の視点を採用しています。

ERPsの設計

ERPsは多様であり、市場には多くのベンダーが存在し、数十年にわたって多くのバージョンのERP製品を提供してきましたが、その中核においては、ほとんどの実装が非常に類似した設計ラインに従っています。 ERPsは、リレーショナルデータベースの上に実装された「事前設定済み」のソフトウェアレイヤーとして登場しました。したがって、ERPの設計プロセスには、次のようなカタログ作成が含まれます：

• エンティティ、つまりERPが表現する必要があるすべての概念やオブジェクト、例えば製品、支払い、在庫、サプライヤなど。各エンティティは、基礎となるリレーショナルデータベースの1つまたは複数のテーブルを含む場合があります。ほとんどのERPsは数百のエンティティを定義し、最も複雑なERPsでは数千のエンティティを定義します。
• ユーザーインターフェースは、エンティティのデータを表示および編集するためのものです。これらのインターフェースは、エンティティを扱う際にエンドユーザーが期待する最も基本的な操作であるCRUD設計（作成/読み取り/更新/削除）によって支配されます。
• ビジネスロジックは、よく定義されたルールに基づいて自動化された動作を提供し、多くの事務作業を不要にします。例えば、顧客の注文を顧客の請求書に変換するなど、自動化できる作業です。

ビジネスは非常に多様で複雑なため、進化するビジネスプラクティスをカバーするために、新しいまたは洗練されたエンティティ、ユーザーインターフェース、ビジネスロジックが必要とされることは絶え間ない努力です。これはERPベンダーにとって大きな継続的な取り組みを表しています。そして、この課題は、非常に多様な垂直市場に対応しようとする際に生じるすべての曖昧さによって複雑さが増します。同じ用語「支払い」でも、垂直市場によっては非常に異なる現実とプロセスを反映しています。ソフトウェアでは、複雑さは非線形のコストを持つ傾向があります。つまり、製品の機能を2倍サポートすることは、元のコストの2倍以上のコストがかかります。

その結果、ERPベンダーは、ソフトウェアの投資を競争力を持たせるために、一連の戦略を採用しています。

テクノロジー

複雑さに対処するために、ERPベンダーが利用する最初の戦略は、複雑さに対処するためのコストを低減することを目的とした技術の開発です。

特に、多くのERPベンダーは、基礎となるクエリ言語（現在は通常SQLのバリエーション）を補完する目的で、ドメイン固有のプログラミング（DSL）言語を開発しました。よく設計されたDSLを通じて、特定の会社の特異性をカバーするためにERPを拡張する（つまり、新しいエンティティ、インターフェース、ロジック）は、汎用プログラミング言語を使用して同じ努力を行う場合に比べて、より少ないリソースで行うことができます。

2000年代以降、オープンソースのERPベンダーは、90年代後半に利用可能になったオープンソースのリレーショナルデータベースを活用して登場しましたが、通常はDSLの代わりにプラグイン戦略を採用しました。この戦略では、ERPは、ERP自体と同じ汎用プログラミング言語で書かれた、各クライアント企業に合わせたカスタムコードの導入によって拡張されるように設計されています。この戦略は、ERPベンダーにとって実行が軽く（DSLを設計する必要がない）、ERPのオープンソース性と一致しています。

提供

機能の実装およびサポートコストは、機能の総数とともに増加するため、ほとんどのERPベンダーはモジュールベースの価格戦略を採用しています。機能は「モジュール」にまとめられ、会社内の異なる機能領域に焦点を当てています：在庫管理、財務、給与など。ERPはモジュール単位で販売され、クライアント企業が最も重要なモジュールを選択し、他のモジュールを後で投資することができるようになっています。

モジュールベースの価格戦略は、ERPベンダーにとって将来の販売の主要なターゲットとなる既存の顧客基盤を持つ自然なアップセル戦略も提供します。最初のモジュールセットで最初にカバーされていなかった業務領域には、新しい専用モジュールが追加され、それらをクライアント企業に販売することができます。

このモジュールベースの価格戦略は、支払い意欲が最も高い機能領域についてERPベンダーに直接フィードバックを提供するため、複雑さに対処するための効果的なメカニズムです。そのため、ベンダーはソフトウェアエンジニアリングの取り組みを正しく優先するのに役立ちます。

エコシステム

ERPに追加される各追加機能は、ソフトウェアエンジニアリングの取り組みを正しく優先したERPベンダーにとって、収益が減少する傾向があります¹。実際、この機能が以前に追加されていなかった場合、それは最初から十分に関心を引かなかったためです。そのため、組織自体（ERPベンダーも含む）は、量的供給チェーンマニフェストに従っています：ソフトウェア製品に追加のソフトウェアエンジニアを追加することは、改善のスループットにおいて線形の利益をもたらさないことで広く知られています。

したがって、ほとんどのERPベンダーは、ERPを特定の企業で運用可能にするために必要な最後の開発作業を、通常はインテグレーターとして知られる第三者企業に委託するエコシステム戦略を採用しています。これらのインテグレーターは、クライアント企業に対して「生の」ERPでは提供されないすべての機能の実装と展開に対して料金を請求します。歴史的には、2000年代まで、企業が初めてERPを採用したとき、インテグレーターの仕事は通常、ERPの追加機能の導入に焦点を当てていました。しかし、現在では、ほとんどのERPプロジェクトはアップグレードです。レガシーERPが既に存在しているため、インテグレーターの主な付加価値は、古いERPから新しいERPへのスムーズな移行を確保することです。実際の作業では、システム間でのデータとプロセスの移行が含まれます。

ERP自体を主なビジネス戦略とするERPベンダーとは異なり、インテグレーターは通常、人日単価のいくつかのバリエーションを採用しています。彼らは作業量に基づいて仕事を請求し、通常、作業の知的財産（IP）は契約によってクライアント企業自体に帰属します。

多様なインテグレーターエコシステムを地理的および垂直に開発することは、ERP開発に関連する固有の複雑さを緩和する効果的な方法です。ほとんどの大規模ERPベンダーは、大規模なインテグレーターネットワークを開発しています。

ERPの限界

ERPは、基礎となる関係データベースシステムの制約のほとんどを受け継いでいます²。その後、前のセクションで説明した複雑さ緩和戦略からさらなる制約が生じます。これらの制約は特に興味深いものです。なぜなら、それらは設計上の制約であり、したがって、新しいERPバージョンでこれらの制約を解決することはほとんどないか、それらのソフトウェア製品をまだERPとして参照することはあまり意味がなくなるほどERPを変質させることになるでしょう。

粗い読み取りまたは書き込みに不適

ERPで使用される関係データベースは、ACID（原子性、一貫性、分離性、耐久性）の特性を提供し、主に小規模な読み取りおよび書き込み操作を含むワークロードに適した設計で、低いレイテンシで実行する必要があります。詳細な関係データベースの分析は、本記事の範囲を超えていますが、ERPの意図されたワークロードに関するこの観察は、ERPの理解されていない制約の多くを単独で説明しています。

関係データベースに基づいた設計のため、ERPはデータ量が膨大な場合には分析、統計、レポート作成には適していません。ビジネスの運用が続く中で、ERPで膨大なデータにアクセスすることは常に問題です。データの読み取りや書き込みが多すぎるためにシステムが遅くなるためです。実際には、バーコードの処理などの日常的な操作も遅くなります。最悪の場合、会社全体が停滞します。したがって、ERPのすべての操作（読み取りまたは書き込み）は、理想的には「些細な」ものである必要があります。非些細なデータと見なされる量は、過去40年間で劇的に増加し、より良くて安価なコンピュータハードウェアとともに増加しました。しかし、企業はこの進歩を利用して、彼らのERPに注ぎ込まれるデータ量を大幅に拡大しました。その結果、現在のERPシステムは、20年前と比べてほとんど速くなっていないことが一般的です。

たとえば、ERPはSKUの在庫レベルを表示したり、ユニットがピックアップまたはロードされたときにその値を更新するのに適していますが、ERPは通常、過去3年間のSKUの在庫変動の統合された日次タイムラインを表示するのには適していません。ビジネスインテリジェンス（BI）セグメントのソフトウェア製品全体は、ERPの分析上の制約（およびCRMも同様）に対する業界全体の応答として90年代に登場しました。ERPとは異なり、BIツールはインメモリハイパーキューブ（通常はOLAP（オンライン分析処理）と呼ばれる）を中心に設計されています。ACIDの特性を放棄することで、OLAPシステムは関係データベースよりもハードウェア効率がはるかに向上し、日ごと、店舗ごと、カテゴリごとの売上などの集計統計を提供します。

興味深いことに、90年代以降、BIセグメントがこの状況の証拠であったにもかかわらず、ほとんどのERPベンダーは自社製品のこの設計上の制約に完全に気付いていないようです。たとえば、ほとんどのERPベンダーは、設計上、単なるレポート機能よりもさらに関係データベースと相反する需要予測機能に進出しました。予測には、企業の取引データの全履歴（売上、返品、在庫レベル、割引など）へのアクセスが必要です。計算は通常、夜間にバッチ処理されることを意図していますが、関係データベースではこのタイプの計算を実行しようとすると、大きな偶発的なオーバーヘッドが発生します。その結果、現在のERPシステムには、数年または数十年前に廃れた「レガシー」の予測機能³がほとんど備わっています。

新しいまたは独自のパラダイムに不適

ERPベンダーが使用するエンティティカタログ戦略は、複雑性管理の観点から線形的にスケーリングしません。上記で説明したように、より良いツールはエンティティの数に対して線形的な救済をもたらしますが、複雑性のコストは超線形的に増加します。その結果、新しいまたは独自のパラダイムは、統合するのにコストと遅延がかかることが多く、ERPを完全にスキップする方が良い選択肢になることがよくあります。これらの状況はさまざまですが、以下にいくつかをリストアップします。しかし、すべての状況は、ERPの開発プロセスの後半に現れたために統合が困難なパラダイムに帰結します⁴。

ゼロの運用停止時間を実現することは困難です。なぜなら、上記で指摘したように、大規模な読み取りまたは書き込みはERPのシステムの遅延のリスクを引き起こすからです。そのため、これらの操作は通常、夜間のバッチ処理として実行されます。しかし、この設計は、ERPsの歴史の比較的遅い段階で現れた電子商取引の要件とは相容れません。その結果、ほとんどのERPベンダーは、電子商取引モジュールを別々に分離し、別のデータベースシステムを利用することがよくあります。これにより、ERPをバックエンドとする電子商取引モジュールは、サードパーティのアプリと同様に展開が困難で高価になる傾向があります。

リマニュファクチャリングのような複雑な循環フロー（修理など）に従う垂直市場に対処することは、主流のERPが一般的にFMCGや流通業界で見られるような前方フローに重点を置いているため困難です。リマニュファクチャリングの目的に必要なほとんどの関連エンティティ（製品、在庫、注文など）はすでにERPに存在しますが、それらの設計は通常、リマニュファクチャリングの要件とはまったく矛盾しています。これらの垂直市場で主流のERPのエンティティを再利用するよりも、それらのエンティティを完全に再実装する方が簡単です。

人間の知覚以下（つまり50ms以下）の低遅延を保証することは困難です。なぜなら、ERPやその関係データベースは、そのような要件を考慮して設計されていないからです。しかし、ロボット倉庫などの高度に自動化されたシステムを導入するには、ソフトウェアによるオーケストレーションがシステムのボトルネックになるのを避けるために、このような遅延が必要です。そのため、実際には、「リアルタイム」（4）処理に関連するほとんどの領域は、ERPの外部に専用のシステムを持っています。

興味深いことに、主流のERPでは適切に対応していないニッチな垂直市場をターゲットにした専門のERPが存在します。ただし、これらの代替開発パスは、通常、主流の要件とは矛盾しています。

ERP移行のリスク

一見すると逆説的ですが、ERPをアップグレードすることは、初めてデプロイするよりもはるかに困難です。アップグレードは通常、数年にわたるプロセスとして知られています。同じベンダーを使用した場合でも、ERPのバージョンアップグレードは通常、数か月にわたる作業となります。逸話的には、このような困難は、大企業が数億ドルまたはユーロを超える予算オーバーとなったERPのアップグレードの取り組みを発表するときに、しばしばニュースになります。このような状況では、ERPベンダー、インテグレータ、または企業自体が非難されます。しかし、これらの問題は、上記でリストアップした市場の力によって設計されたERPs自体に固有のものであることを多くの人が認識していないようです。

複雑性のコストは線形的にではなく、超線形的にスケーリングしません。会社が初めてERPを採用する場合、各モジュールを段階的に採用することができます。したがって、各イテレーションで関与するエンティティ/インターフェース/ロジックの数は比較的少なく、ERPを会社のニーズに適したものにするために徐々にカスタマイズできます。

しかし、会社が別のERPに移行する必要がある場合、同時にすべてのモジュールを移行する問題に直面します。実際、ERPは、設計上および経済的な要因により⁵、一部のデータベース上に構築されたソフトウェアのモノリスです。したがって、新しいERPを展開する際には、元のERPに使用された段階的な採用パスを再現することはできません。したがって、前払いの実装コストは非常に高くなり、デプロイ後の状態は修正に数年かかる半壊状態になる傾向があります。

技術的には、これらのアップグレードは常に実装が困難です。古いシステムと新しいシステム間のエンティティ/インターフェース/ロジックのインポートは一対一の関係ではありません。エンティティの意味は時間とともに変化します。たとえば、ERPのベンダーは最初に「注文」という名前のテーブルを作成しましたが、これはクライアントの注文を意図したものでした。しかし、その後、ベンダーは元々計画されていなかったクライアントの返品を管理するという新しい要件に対応する必要がありました。次のバージョンのERPでは、「注文」テーブルをクライアントの返品のために再利用しますが、これらの行には負の注文数量があります。このささいな変更が、古いERPバージョンから新しいバージョンへの移行を非常に複雑にします。

ただし、新しいERPにアップグレードするか、同じERPの後のバージョンにアップグレードすることは、会社にとって唯一の選択肢ではありません。実際、移行のリスクを軽減するために複数の代替手段が利用可能です。ERPベンダーや統合業者のエコシステム全体は、彼らの経済モデルの生存のために、逆のことを推進することに強い経済的な利益を持っています。

モノリスを超えて

ERPは、すべての内部コンポーネントが緊密に結合されているソフトウェアモノリスとして登場しました。これは、すべてのモジュールをプラグアンドプレイで展開するための必要条件です。さらに、2010年代まで、分散システムを構築することは、いくつかの中央マシンではなく、複数のマシンで動作するソフトウェアを操作することよりもはるかに困難で高コストでした⁶。したがって、大部分が数十年前のERPベンダーであるため、彼らはモノリスとして製品を構築する以外の選択肢を持っていませんでした。

しかし、クラウドコンピューティングが主流になるにつれて、ツールやライブラリ（頻繁にオープンソース）がより人気があり、よりアクセスしやすくなりました。その結果、分散アプリケーションの設計に関連するコストとオーバーヘッドは、過去10年間で着実に減少しています。ソフトウェア業界は、歴史的にERP（またはERPのようなソフトウェア）によってのみ提供されていた付加価値をどのように提供できるかを広範に再評価し始めました。

エンタープライズソフトウェアの現代的なアプローチは、一つのことをうまく行うように設計された一連の小さなアプリを通じてモノリスを分解することです⁷。アプリを結びつけるためのAPI（アプリケーションプログラミングインターフェース）は、さまざまなアプリケーションランドスケープへのカスタム統合を容易にするために特に設計されています。ほとんどのAPIは、そのようなカスタム統合に関連する開発コストを大幅に低下させる人気のあるオープンソースのAPIツールを活用するように設計されています。

これらのアプリは、組み込みのERPモジュールよりも前払いの統合コストが高い場合があります。しかし、これらのアプリは、アプリケーションランドスケープのさらなる進化を大幅にリスクを回避する利点があります。会社は一度に1つのアプリをアップグレードまたは置き換えるオプションを得ることができます。これは実行がはるかに容易であり、リスクも少なく、さらに安価です。最後に、SaaS（サービスとしてのソフトウェア）アプリは通常、小規模な増分変更の継続的な提供を選択します。このパターンはITチームに継続的な - しかし限定された - 作業量を生成しますが、SaaSの変更プロセスは年次または2年ごとのアップグレードと比較して、より有機的で、安価で、リスクが少ないです。

リレーショナルデータベースを超えて

80年代以来、リレーショナルデータベースはERPのデファクトバックボーンでした。しかし、2010年代以降、魅力的な代替手段が現れました。最も注目すべきものはおそらくイベントソーシング（ES）とコマンドクエリ責任分離（CQRS）です。このアプローチは、優れたスケーラビリティとレイテンシを提供し、さまざまな状況でより狭くビジネス意図を捉えることができるより表現力豊かな設計を可能にします。

イベントソーシングの要点は、システム内のすべての変更を不変のイベントとして扱うことです。不変性の観点は、会計の実践に触発されています。会計士は、元帳の問題を修正するために行を消去するのではなく、代わりに元帳に別の修正行を追加します。データストレージがこの戦略を実現するために十分に安価であると仮定すれば、イベントの完全な履歴を保持することは、追跡性、監査可能性、セキュリティなどの多くの利点をもたらします。さらに、不変性の観点から、イベント駆動型システムはスケーリングが容易になります。データは変更を扱う必要がないまま、広範にコピーおよび複製することができます。

CQRSデザインは、ほとんどのシステムで読み取りと書き込みのボリュームが非常に不均衡であることを認識しています。多くの場合、（データの）読み取りのボリュームは書き込みのボリュームを数桁上回ります。しかし、リレーショナルデータベースは（多少）対称的な読み取りと書き込みのボリュームに向けられています。CQRSは、読み取りと書き込みの責任を明示的に分離し、通常は2つの異なるサブシステムで行います。この設計は、レイテンシ、スケーラビリティ、ハードウェアの効率性など、さまざまな利点ももたらします。

しかし、ESとCQRSは、すでに大手の消費者向けテック企業や量的取引（金融）で人気がありますが、メインストリームのエンタープライズソフトウェアでの採用は最近になって始まったばかりです。その結果、リレーショナルデータベースの領域に比べて、ES+CQRSのツールはまだ初期段階です。それにもかかわらず、このアプローチはハードウェアコストを大幅に削減するだけでなく、ERPの実装において頻繁に問題となるレイテンシを圧縮する方法を提供します。

Lokadのアプローチ

ERPsは分析目的には適していないため（したがって、BI（ビジネスインテリジェンス）ツールの必要性がある）、予測分析が関与する場合、その実績は芳しくありません。事実証拠として、機械学習/ データサイエンスの革命はERPで起こりませんでした。そのような要件に直面すると、チームは必ずスプレッドシートや特別なスクリプトに頼ることになります。

Lokad自体は、ERPシステム内で実装するのは非現実的な、在庫管理/購買/生産/アソートメント/価格設定などの日常的な意思決定をサポートするための専門アプリとして登場しました。当社の確率的予測機能など、主要な機能のほとんどは、ERPシステム内で実装することは実用的ではありません。

ノート