エンタープライズ・リソース・プランニング (ERP)

ERP（エンタープライズ・リソース・プランニング）は、企業の日常業務をサポートし、資金、原材料、仕掛品、完成品、顧客注文、購買注文、給与などの資源を管理するエンタープライズ・ソフトウェアの一種を指します。ERPは通常、会計、調達、流通、財務、販売などの主要なビジネス機能向けの複数のモジュールを含み、各モジュール間で（取引）情報の流れを円滑にするための厳密な連携を提供します。ERPはリレーショナルデータベース上に構築され、非常に拡張性の高い設計となっており、製品、顧客、請求書など多数のエンティティ、多数の画面、そして高い構成可能性を備えています。

起源と動機

1970年代には、電子記録が従来の紙ベースの記録に比べて多くの利点を持つことが次第に明らかになりました。電子記録は紙の記録よりも安価で、迅速かつ信頼性が高くなっていました。バーコードリーダー（1950年代）とリレーショナルデータベース（1970年代）という、ERP以前の二つの発明が、電子記録の普及を後押ししました。バーコードリーダーは商品の流れを管理する優れた方法を提供し、生産性を向上させつつ事務エラーを削減しました。しかし、バーコードリーダーが多くの状況でデータ取得を大幅に改善した一方で、電子記録の保存、整理、処理は約20年間ほど未解決の問題として残っていました。リレーショナルデータベースは、1970年代後半におけるこの問題に対するソフトウェア業界の回答であり、5半世紀が経過した現在でもビジネスデータ管理の主流の手法として位置付けられています。

しかし、1980年代初頭に一般的に販売されていた単体のリレーショナルデータベースシステムは、各企業が自社のデータベース内に製品、顧客、請求書、支払いなどすべてを再構築して表現する必要があったため、実装コストが非常に高額となりました。その結果、1980年代には「事前設定済み」のリレーショナルシステムを販売する一連のソフトウェア企業が登場しました。これらの製品は後にまとめてERPと呼ばれるようになり、この用語は1990年代に造られました。残念ながら、ERPという略称は誤りで、本来はEnterprise Resource Management（企業資源管理）とすべきでした。実際、プランニングはERPにおいて第二義的な関心事に過ぎません。以下で述べるように、予測分析は基本的にERPの核心設計と矛盾しています。

歴史的に、ERPはかつて多大な事務作業を必要とした一連の業務の効率化により普及しました。例えば、サプライヤーへの購買注文の発行では、サプライヤーの名前と住所を記入したフォームの記入が必要でした。注文行には有効な製品参照のみが含まれなければなりませんでした。そして、商品の受領時には、受領数量が元の購買注文と一致し、納品が適合していると判断された後、適切な金額、サプライヤーの支払条件に沿った日付、そしてサプライヤーの銀行口座番号を正確に特定したテンプレートに基づいて支払い注文が生成されました。これらすべてはERP内で管理され、一貫性のチェックは自動化された方法で容易に行われます。

ERP市場は、プロセッサ、メモリ、ストレージといったコンピュータハードウェアの着実な進歩に支えられ、1990年代後半に急速な成長を遂げ、あらゆる規模の企業に手の届くものとなりました。

1990年代には、ERPは主に商品の流通を中心とする大手企業においてソフトウェアの中核として採用されました。一方、サービスを主要事業とする企業は通常、CRM（Customer Relationship Management／顧客関係管理）ソフトウェアを中核として採用しました。ERPとCRMは、リレーショナルデータベース上に構築されているという共通点を含む多くの属性を共有しています。ERPは通常、取引中心の視点を採用するのに対し、CRMは顧客中心の視点を採用します。

ERPの設計

ERPは多様であり、市場には何十年にもわたり様々なバージョンのERP製品を提供し続ける多くのベンダーが存在しますが、その根底にある多くの実装は非常に類似した設計方針に従っています。ERPは、リレーショナルデータベース上に実装された「事前設定済み」のソフトウェア層として登場しました。したがって、ERPの設計プロセスには以下の要素のカタログ化が含まれます:

• entities、すなわちERPが表現する必要のあるすべての概念やオブジェクト（製品、支払い、在庫、サプライヤーなど）です。各エンティティは、基盤となるリレーショナルデータベース内で1つまたは複数のテーブルを使用する場合があります。ほとんどのERPは数百のエンティティを定義し、最も複雑なERPでは数千にのぼることもあります.
• user interfaces、すなわちエンドユーザーがエンティティのデータを閲覧・編集できるユーザーインターフェースです。これらのインターフェースは、エンドユーザーがエンティティを操作する際に期待する基本的な操作であるCRUD（作成/読み取り/更新/削除）デザインが支配的です.
• business logic、つまり、例えば顧客注文を顧客請求書に変換するなど、明確に定義されたルールに基づいて多くの事務作業を自動化する動作を提供します.

ビジネスは非常に多様かつ複雑であるため、進化する業務慣行をカバーするために、常に新たまたは精緻なエンティティ、ユーザーインターフェース、ビジネスロジックが要求されます。これはERPベンダーにとって膨大な継続的努力を必要とし、さらに多様な業界に対応する際に生じる各種の曖昧さがこの課題を一層難しくしています。同一の用語であっても、例えば「payment」は業界によって全く異なる意味やプロセスを反映することがあります。ソフトウェアにおいて、複雑性は非線形のコスト増を伴い、製品機能を2倍に拡大するには、元のコストの単純な2倍以上の費用がかかることが多いのです.

その結果、ERPベンダーはソフトウェア投資をより競争力のあるものにするため、一連の戦略を採用するようになりました.

技術

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

特に、多くのERPベンダーは、基盤となるリレーショナルデータベースのクエリ言語（今日では一般的にSQLの一種）を補完する目的で、DSL（ドメイン固有プログラミング言語）を開発しました。よく設計されたDSLを用いることで、特定企業の特殊な要件に合わせてERP（すなわち新たなエンティティ、インターフェース、ロジック）の拡張を、一般目的のプログラミング言語で同等の作業を行うよりも少ないリソースで実現できます.

2000年代以降、オープンソースERPベンダーは、1990年代後半に登場したオープンソースのリレーショナルデータベースを活用し、通常はDSLの代わりにプラグイン戦略を採用しました。この戦略では、ERP自体と同じ一般目的プログラミング言語で記述されたカスタムコードを導入することでERPを拡張できるよう設計されています。この戦略は、ERPベンダーにとって（DSLの構築が不要なため）実行が容易であり、ERPのオープンソース性とも整合しています.

提供

機能の実装とサポートのコストが全体の機能数とともに増大するため、ほとんどのERPベンダーはモジュールベースの価格設定戦略を採用しています。機能は「モジュール」としてまとめられ、企業内の特定の機能領域、たとえば在庫管理、財務、給与などに焦点を当てています。ERPはモジュール単位で販売され、クライアント企業は最も緊急性の高いモジュールを選択し、他のモジュールは後の投資に回すことができます.

モジュールベースの価格設定戦略は、ERPベンダーに対して、既存顧客層を将来の販売の主要ターゲットとする自然なアップセル戦略も提供します。最初のERPモジュールセットでカバーされなかったビジネス分野には、新たな専用モジュールが追加され、これがクライアント企業に対して販売されることになります.

このモジュールベースの価格設定戦略は、支払い意欲が最も高い機能領域に関してERPベンダーへ直接フィードバックを提供するため、複雑性に対処するための効果的な仕組みとなっています。その結果、ベンダーはソフトウェアエンジニアリングへの取り組みの優先順位を正しく設定できるのです.

エコシステム

ERPに追加される各機能は、ERPベンダーがソフトウェアエンジニアリングへの取り組みの優先順位を適切に設定している場合、収益効果が低下する傾向があります¹。実際、もしその機能が以前追加されなかったとすれば、それは当初十分な関心を引かなかったためでしょう。さらに、ERPベンダーを含む組織は、追加のソフトウェアエンジニアの投入が製品の改善のスループットに線形的な効果をもたらさない、いわゆる規模の不経済にも直面します.

このため、ほとんどのERPベンダーは、ERPを各企業で稼働させるために必要な最終段階の開発作業を、一般に統合業者と呼ばれる第三者企業に委託するエコシステム戦略を採用しています。これらの統合業者は、ERP自体が提供しないすべての機能の実装および展開に対してクライアント企業から料金を徴収します。歴史的には、企業が初めてERPを採用した2000年代以前は、統合業者の作業は主にERPの追加機能の導入を中心としていました。しかし、今日ではほとんどのERPプロジェクトがアップグレードであり、レガシーERPがすでに稼働しているため、統合業者の主な付加価値は旧ERPから新ERPへの円滑な移行を保証することにあります。実際、この作業にはシステム間でのデータおよびプロセスの移行が含まれます.

ERP自体を知的財産（IP）資産として事業戦略の中心に据えるERPベンダーとは異なり、統合業者は通常、作業日数に基づく料金体系を採用しています。彼らは作業した日数に応じて料金を請求し、提供された作業の知的財産権は通常、契約によりクライアント企業に帰属します.

地理的にも業界的にも多様な統合業者のエコシステムを構築することは、ERP開発に伴う固有の複雑性を緩和するための効果的な方法です。ほぼすべての大手ERPベンダーは、相当規模の統合業者ネットワークを構築しています.

ERPの限界

ERPは、その基盤となるリレーショナルデータベースシステムの多くの制約を引き継いでいます²。さらに、前節で述べた複雑性緩和戦略から生じる追加の制約も存在します。これらの制約は設計上のものなので、新しいERPバージョンで対処される可能性は低く、むしろこれらの制約を解消するためにはERP自体が変質してしまい、もはやERPと呼ぶ意味が失われかねません.

大規模な読み書きに不向き

ERPで利用されるリレーショナルデータベースは、ACID（Atomicity, Consistency, Isolation, Durability）特性を提供し、主に低遅延で実行される小規模な読み書き操作を中心とするワークロード向けに設計されています。これらの操作は通常、1秒未満の遅延で行われ、読み取りと書き込みのバランスがほぼ等しい必要があります。本稿ではリレーショナルデータベースの詳細な解析には踏み込みませんが、このERP向けに意図されたワークロードの観点だけでも、多くの理解しづらいERPの制約を説明できます.

リレーショナルデータベースに基づく設計のため、ERPはデータ量が多い状況での分析、統計、報告にはほとんど適していません。業務が進行中のシステムで大量のデータにアクセスすることは常に問題となり、読み書きが過剰になるとシステムが飢餓状態に陥り、システム全体が低速化します。実際、これによりバーコード処理などの日常の業務すら遅延し、最悪の場合、企業全体の業務が停止してしまうこともあります。したがって、ERP内のすべての操作は、読み取りであれ書き込みであれ、可能な限り小規模、理想的には「些細な」ものでなければなりません。コンピュータハードウェアの進歩により非凡なデータ量の閾値は過去40年間で劇的に増加しましたが、企業はこの進歩を利用してERPに投入するデータ量も大幅に拡大しました。その結果、現代のERPシステムは20年前と比べても顕著に高速というわけではありません.

例えば、ERPはSKUの在庫レベルを表示したり、商品のピックまたは積載時にその値を更新するのには適していますが、過去3年間にわたるSKUの在庫変動の統合された日次タイムラインを表示するのには通常適していません。Business Intelligence（BI）セグメントのソフトウェア製品は、ERP（およびCRMも含めて）の分析上の限界に対する業界全体の対応策として1990年代に登場しました。ERPとは異なり、BIツールは通常、OLAP（Online Analytical Processing）と呼ばれるインメモリ・ハイパーキューブを中心に設計され、ACID特性を犠牲にすることでリレーショナルデータベースに比べハードウェア効率を大幅に向上させ、店舗別、カテゴリ別、日別の売上集計などを提供します.

興味深いことに、ほとんどのERPベンダーはこの設計上の制約を十分に認識していなかったようです。BIセグメントがこの現状の生きた証拠として存在していた1990年代以降に登場した製品においても同様です。例えば、多くのERPベンダーは、基盤となるリレーショナルデータベースと設計上全く相反する需要予測機能に手を出しました。需要予測には、販売、返品、在庫レベル、割引など、企業の全取引履歴へのアクセスが必要です。計算は通常、夜間にバッチ処理として実行され、前述のリソース飢餓の問題を緩和することが意図されていますが、リレーショナルデータベースはこの種の計算を実行する際に膨大な偶発的なオーバーヘッドを伴います。その結果、今日では、多くのERPに、数年前または数十年前に使われなくなった「レガシー」な予測機能が搭載されています³.

新規または独自のパラダイムに不向き

The entity-cataloging strategy used by ERP vendors does not scale linearly in terms of complexity management. Better tools, as discussed above, only bring a linear relief - with respect to the number of entities - while complexity costs grow superlinearly. As a result, new or distinctive paradigms prove usually expensive both in costs and delays to integrate, frequently reaching the point where it’s a better alternative to skip the ERP altogether. These situations are diverse, we will list a few of them below, but they all similarly boil down to paradigms that are difficult to integrate because they came late in the ERP development process⁴.

Achieving ゼロ運用停止時間 is difficult because, as pointed out above, any large read or write puts the ERP at risk of a system slowdown. Thus, all those operations are typically performed as nightly batches, when there are little or no operations in progress. Yet, this design is at odds with ecommerce requirements that emerged relatively late in the history of ERPs. As a result, most ERP vendors did extensively separate their ecommerce module, frequently leveraging a separate database system, breaking the implicit design rule that all the ERP modules live in the same database(s). As a result, ERP-backed ecommerce modules tend to be as difficult and expensive to roll-out as third-party apps.

Dealing with 再製造 verticals where goods follow complex cyclical flows (i.e. repairs), while mainstream ERPs are heavily geared toward forward flows - from producers to consumers - as commonly found in FMCG and distribution. While most of the relevant entities necessary for remanufacturing purposes (i.e. products, stocks, orders) already exist in ERPs, their designs are typically completely at odds with the requirements of remanufacturing. It is frequently easier to re-implement entirely those entities rather than trying to recycle those of a mainstream ERP in those verticals.

Delivering 保証された低レイテンシ, say below human perception (i.e. below 50ms), is difficult because neither the ERP nor its relational database have been designed with such requirements in mind. Yet, piloting highly automated systems like robotic warehouses require these sorts of latencies in order to avoid the software-driven orchestration becoming the system’s bottleneck. Thus, in practice, most areas associated with “real-time” (4) processing have dedicated systems outside the ERP.

Interestingly, there are specialized ERPs - they don’t always refer to themselves as ERPs though - that took alternative development paths in order to precisely cope with those situations. These ERPs are typically targeting niche verticals that are not properly served by mainstream ERPs. However, these alternative development paths are typically at odds with mainstream requirements.

ERP移行におけるリスク

While it may seem like a paradox, it is typically vastly more difficult to upgrade an ERP rather than just deploy it for the first time. Upgrades are notorious for being multi-year processes. Even mere version upgrades of the ERP - keeping the same vendor - usually prove to be difficult, many-month undertakings. Anecdotally, this difficulty regularly makes the news as large companies publish press releases indicating that their ERP upgrade efforts have run over budget in excess of hundreds of millions of dollars or euros. In such situations, the ERP vendor, the integrator and/or the company itself gets blamed. Yet, it seems that most fail to acknowledge that such problems are intrinsic with ERPs themselves, as designed through the market forces listed above.

Complexity costs do not scale linearly but super-linearly. When a company adopts an ERP for the first time, it has the luxury of gradually adopting each module, one module at a time or so. Thus, the number of entities / interfaces / logics involved with each iteration is relatively small, and bespoke extensions can be gradually delivered to make the ERP suitable to the needs of the company.

However, when the company has to transition to another ERP, it then faces the problem of transitioning all the modules at the same time. Indeed, ERPs are, by design and by economic forces⁵, software monoliths built on top of a small set of databases. Thus, when the new ERP has to be deployed, the incremental adoption path used for the original ERP cannot be replicated. The company has therefore to transition in an all-or-nothing manner. As a result, upfront implementation costs tend to be very steep, while the post-deployment status tends to be half-broken situations that take up to several years to fix.

Technically, these upgrades are always difficult to implement because importing the entities / interfaces / logics between the old and the new system is not a one-to-one affair. The semantic of the entities evolves over time. For example, the ERP vendor might have started with a table named “Orders” that was intended for client orders. However, down the road, the vendor has to address the newer requirements, not originally planned, of managing client returns. The next version of the ERP recycles the “Orders” table for the client returns, however those lines now have negative order quantities. This seemingly innocuous change ends up vastly complicating the migration from the old ERP version to the new one.

However, upgrading toward a new ERP, or toward a later version of the same ERP, isn’t the only option for companies. Multiple alternatives are actually available to de-risk the transition. Naturally, the whole ecosystem of ERP vendors and integrators have a vivid financial interest in promoting the opposite, as a matter of survival of their economic model

モノリスを超えて

ERPs emerged as a ソフトウェアモノリス, that is, software products where all inner components are tightly coupled - a necessity in order to ensure a plug-and-play roll-out of all the modules. Furthermore, until the 2010’s, building distributed systems - i.e. software that operates over a fleet of machines rather than operating over a few central machines - was significantly more difficult and costly⁶. Thus, to a large extent, ERP vendors (most of them being decades old) did not have any alternative but to build their products as a monolith.

Nevertheless, as cloud computing became mainstream, tools and libraries - frequently open source - became more popular and more accessible. As a result, the costs and overheads associated with the design of distributed applications have been steadily decreasing over the past decade. The software industry has started to extensively revisit how the added-value that was historically only delivered by ERPs (or ERP-like software) can be delivered.

The modern approach to enterprise software consists of breaking the monolith through a series of smaller apps that, ideally, do one thing and do it well⁷. Glueing the apps together is done through APIs (Application Programming Interfaces) that are precisely intended to facilitate bespoke integrations into diverse applicative landscapes. Most APIs are designed to leverage popular open source API tooling that significantly lowers the development costs associated with those bespoke integrations.

Those apps sometimes have steeper upfront integration costs than built-in ERP modules. However, they present sizable long term benefits as they vastly de-risk further evolutions of the applicative landscape. The company gains the option of upgrading or replacing one app at a time, which proves not only much easier to execute, but cheaper as well while involving less risks. Finally, SaaS (Software as a Service) apps typically opt for a continuous delivery of small incremental changes. While this pattern generates an ongoing - but limited - workload for IT teams, the SaaS change process is more organic, cheaper and less risky compared to yearly or biennal upgrades.

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

Relational databases have been the de facto backbone of ERPs since the 80’s. However, since the 2010’s, compelling alternatives have emerged. The most notable one is probably イベントソーシング (ES) coupled with コマンドクエリ責任分離 (CQRS). This approach offers superior scalability and latency while also allowing more expressive designs, i.e. capable of more narrowly capturing business intents in various situations.

The gist of イベントソーシング consists of treating every change in the system as an immutable event. The immutability angle is inspired by accounting practices: when a line proves incorrect in a ledger, the accountant does not erase the line to fix the problem, instead he adds another corrective line in the ledger. Keeping the entire history of events - assuming data storage is cheap enough to make this strategy viable - yields numerous benefits: better traceability, auditability, security… Furthermore, the immutable angle makes event-driven systems easier to scale. Data can be extensively copied and replicated without having to deal with changes in the data.

The CQRS design acknowledges that, in most systems, the respective volumes of reads and writes are highly imbalanced. In many situations, the volume of (data) reads outsizes the volume of writes by several orders of magnitude. However, relational databases are geared toward (somewhat) symmetrical volumes of reads and writes. CQRS explicitly segregates the responsibilities for reads and writes, typically in two distinct subsystems. This design also yields benefits, mostly in terms of latency, scalability, and hardware-efficiency.

Yet, while both ES and CQRS are already popular in large consumer-oriented tech companies and in quantitative trading (finance), they have only very recently started to gain traction in mainstream enterprise software. As a result, the ES+CQRS tooling is still nascent compared to its counterparts in the realm of relational databases. Nevertheless, this approach offers ways to not only steeply reduce hardware costs, but also to compress latencies that frequently remain an acute problem for most ERP implementations.

Lokadの見解

As ERPs are not even suitable for analytical purposes - hence the need for BI (Business Intelligence) tools - it should not be a surprise that their track record is dismal whenever predictive analytics are involved. By way of anecdotal evidence, none of the machine learning / data science revolutions happened in ERPs, and when facing those classes of requirements, teams invariably fall back on spreadsheets or ad hoc scripts.

Lokad itself emerged as a specialized app intended to supplement - not replace - ERPs as an analytical layer dedicated to the predictive optimization of supply chains. Most of our core features such as probabilistic forecasting capabilities, intended to support mundane decisions such as stocks / purchasing / production / assortment / pricing, are downright impractical to implement inside ERP systems.

補足