ERPシステムの出自が、そのシステムが本当に業界に役立つのか、それとも制約に合わせて業務側が適応を強いられるのかを決定します。
あらゆるエンタープライズソフトウェアシステムには、その出自の遺伝コードが宿っています。建築の基礎がその上に何を建てられるかを決めるように、ERPシステムの本来の目的は、そのロジック、強み、そして最終的に本当に対応できる業界を形づくります。
建設やプロジェクト型産業において、このヘリテージの問題は学問的な議論ではなく、現場運営そのものです。小売取引や人事ワークフローを管理するために生まれたシステムに対しては、どれだけ「業界モジュール」を追加しても、業務の進め方に関する中核的な前提を根本から組み替えることはできません。
主要ERPベンダーの系譜をたどり、そのDNAが真の能力について何を示しているのかを見ていきましょう。
Oracle: データベース帝国は買収によって拡大した
Oracleの物語は、業務プロセスではなくデータ基盤から始まります。1977年に創業したOracleは、企業アプリケーションそのものではなく、その下支えとなる関係データベース技術を基盤に帝国を築きました。
OracleがERP領域に参入したのは、内製開発ではなく買収によるものでした。2005年のPeopleSoft買収、同社がさらにJ.D. Edwardsを買収していたことに続き、Siebel Systemsの買収によって、アプリケーションの専門性がOracleのエコシステムに加わりました。会社の統合クラウドERPプラットフォームとして立ち上げられた Oracle Fusion Cloud は、こうした異なる買収案件を一つの整合した全体へまとめ上げようとする試みを表しています。
ヘリテージが示すもの: OracleのDNAは、アプリケーションよりもまずインフラです。その強みは、大量のデータと複雑なエンタープライズアーキテクチャを扱う点にあります。とりわけ物的生産ワークフローを伴う、深く専門化したオペレーションロジックを要する業界では、Oracle Fusion は、汎用的な企業プロセスと業界固有の現実との間のギャップを埋めるために、大規模なカスタマイズを必要とすることが少なくありません。
SAP: 会計帳簿からエンタープライズ志向へ
SAPの起源は1972年、ドイツのマンハイムにいた元IBMエンジニア5人にさかのぼります。その名称 Systems, Applications, and Products in Data Processing 自体が、財務会計と給与計算プロセスの自動化という創業ビジョンを示しています。
SAP R/1、R/2、そして最終的にR/3は、こうした会計のルーツから発展し、調達、製造、人事へと徐々に領域を広げていきました。同社の拡大は、財務の記録管理から、その記録を生み出す取引へと向かう、論理的な道筋に沿っていました。
ヘリテージが示すもの: SAPの中核ロジックは、依然として本質的に取引指向であり、財務主導です。このシステムは、金銭の流れを追跡し、会計コンプライアンスを確保することに優れています。しかし、オペレーションの複雑さが財務の複雑さに先行する業界、つまりコストを算出する前にまずどのように仕事が進むのかを理解しなければならない業界では、SAPはしばしば、物理世界を財務的抽象化に合わせることを要求し、その逆ではありません。
Salesforce: オペレーションを振り返るCRMの巨人
Salesforceは、機能ではなく提供方法によってエンタープライズソフトウェアを変革しました。1999年に「No Software」を掲げて創業し、クラウドベースCRMの先駆けとして、顧客関係、営業パイプライン、マーケティングオートメーションを管理してきました。
より広いエンタープライズ領域への拡大は、戦略的買収によって進みました。統合のための MuleSoft、分析のための Tableau、コラボレーションのための Slack です。同社はますますエンタープライズプラットフォームとして位置づけられていますが、その中核は依然として顧客接点のプロセスにしっかり根ざしています。
ヘリテージが示すもの: Salesforceは、フロントからバックへ、つまり顧客との接点から受注・履行へと発想します。複雑さが販売ではなく納品にある業界、つまり案件受注は長期にわたるオペレーション上の挑戦の始まりにすぎない業界では、Salesforceは優れたパイプライン管理を提供しますが、オペレーション実行に関するネイティブな理解は限定的です。
Workday: サービス経済向けに目的特化した人事・財務
Workdayは2005年、PeopleSoftの創業者たちの手によって誕生し、人材管理と財務計画のために特化して設計されました。老朽化したアーキテクチャを急いでクラウド化している既存ERPベンダーとは異なり、Workdayは創業当初からクラウドネイティブでした。
その強みは、採用、報酬、組織設計、そして人を中心にしたビジネスを取り巻く財務計画など、労働力のダイナミクスを管理することにあります。このシステムは、人材資本が主要な生産資源である企業向けに設計されました。
ヘリテージが示すもの: Workday は、人とその関連コストが主要なオペレーション上の関心事となる業界で優れています。一方、設備、資材、下請け業者、複雑な生産スケジュールが社内労働力と同じくらい重要な、資産集約型・プロジェクト型産業では、Workday の人材資本中心のアーキテクチャは、オペレーションの実態を部分的にしか可視化できません。
Infor: 業界特化を追求する買収集約型企業
Inforは、おそらくエンタープライズソフトウェアにおける最も積極的な統合戦略を体現しています。2002年のSSA Global と Infor Global Solutions の合併から生まれた同社は、Lawson（医療、ファッション）、MAPICS（製造）、SyteLine など、数多くの専門アプリケーションを取り込んできました。
2020年以降は Koch Industries の傘下で、業界別の「CloudSuite」を強化し、買収した製品群を整合性のある業種別ソリューションへ転換しようとしています。
ヘリテージが示すもの: Inforの強みは、買収した製品群が持つ専門機能にあります。課題は統合にあります。つまり、異なるアーキテクチャ、データモデル、運用思想を持つ分断されたシステムを結びつけることです。プロジェクトライフサイクルの各段階をシームレスに流れさせる必要がある組織にとっては、買収製品間の継ぎ目が運用上の摩擦点になり得ます。
IFS: エンタープライズ規模へ上り詰める資産管理
IFS（Industrial and Financial Systems）は1983年、スウェーデンのリンシェーピングで、プロジェクト中心・資産集約型産業向けのコンポーネントベースERPに焦点を当てて創業されました。その歴史的な強みは、航空宇宙・防衛、複雑製造、資産ライフサイクル管理にあります。
同社は、Astea International（フィールドサービス管理）を含む対象型の買収を通じて成長し、複雑で長寿命な資産を管理する組織にとってのERPとしての地位を築いてきました。
ヘリテージが示すもの: IFSは、プロジェクトの複雑性と資産集約型オペレーションを真に理解しています。そのアーキテクチャは、保守、サービス、長期資産のパフォーマンスが重要な業界向けに設計されました。しかし、製造および資産保守の出自は、資産創出を主眼とする業界とは異なります。そこでは、主要な課題は、複雑なプロジェクトを構想から建設、引き渡しまで進めることにあります。
Sage: 中小企業向け会計プラットフォームの上方拡張
Sageは1981年、英国ニューカッスルで、中小企業向け会計ソフトとして始まりました。その成長は典型的なパターンをたどりました。基本的な記帳から、より広範な業務管理へと発展し、主として中堅・中小企業にサービスを提供してきました。
Sage Intacct（2017年買収）などの製品によって同社はより大きな市場セグメントへ進出しましたが、中核顧客層は依然として、使いやすい財務管理を必要とする小規模組織です。
ヘリテージが示すもの: SageのDNAは、使いやすさと会計のシンプルさです。エンタープライズ規模の複雑さを伴わずに財務を管理したい組織に適しています。詳細なプロジェクト管理、複雑な資源計画、統合された原価エンジニアリングなど、オペレーションの深さを求める業界では、Sageの軽量アーキテクチャは通常、専門的なポイントソリューションで補完する必要があります。
ProjectVIEW ERP: 建設現場から生まれたERP
そしてもう一つ、異なる物語があります。それは、データベース研究室や会計部門ではなく、コンクリートが打設され、鉄骨が建ち上がり、数億ドル規模のプロジェクトが青写真から現実へと移っていく稼働中の建設現場から始まる物語です。
ProjectVIEW ERPは、DANAOS Projects が建設、海運、造船、インフラ産業で40年にわたり培ってきた直接経験から生まれました。その根本ロジックは、他業界から移植されたものではありません。プロジェクト型生産の運用実態から抽出されたものです。
このシステムのアーキテクチャは、そのヘリテージを根本的な形で反映しています:
三位一体の中核: 他のシステムが財務取引から始めて逆算するのに対し、ProjectVIEW は BoQ（Bill of Quantities）から始まります。これは、実際に構築しなければならないものの物理的な範囲です。BoQ は、WBS（仕事をどう構成するか）と Cost Codes（資源をどう分類するか）に双方向で接続し、建設業の実際の運用を映し出す三角測量型の統制システムを生み出します。
生産最優先のロジック: リソース計画、機材配分、下請け業者管理は、財務システムに後付けで追加する思いつきの機能ではありません。これらは中核となるアーキテクチャ要素です。このシステムは、建設業では物理的な生産を先に計画してはじめて、財務結果を正確に予測できることを理解しています。
請求・変更管理: 契約の複雑性が常態である業界で生まれたため、ProjectVIEW は請求、変更、契約調整を、回避策を必要とする例外ではなく、一級のオペレーション要素として扱います。
ヘリテージが示すもの: ProjectVIEW は、主要な複雑性がオペレーションにある業界向けに設計されました。成功は、数千の活動を調整し、変動する資材フローを管理し、長期にわたるプロジェクト全体で統制を維持することにかかっています。その財務機能は、逆ではなく、オペレーションの中核を支えるために存在します。
ヘリテージ診断: ERP選定のための3つの問い
プロジェクト型産業向けにERPシステムを評価する際、ヘリテージの問いは3つの診断質問に要約できます:
1. システムのロジックはどこから始まるのか? 財務取引から始めて、オペレーションへ逆算するのでしょうか。それとも、オペレーションのスコープから始めて、財務結果を導き出すのでしょうか。建設やプロジェクト型産業では、後者のアプローチが実際の業務の流れに合致します。
2. システムの元来の業界はどこか? すべてのシステムは、その創業文脈からの前提を引き継いでいます。小売で生まれたERPは、建設現場で生まれたERPとは在庫の捉え方が異なります。人事で生まれたERPは「リソース」を従業員として考えますが、建設で生まれたERPは、リソースを労働力、機材、資材、下請け業者の統合された組み合わせとして考えます。
3. システムはどのように拡張したのか? 新しい機能への有機的な拡張は、アーキテクチャの一貫性を示唆します。買収を通じた成長は専門機能をもたらす一方で、多くの場合、統合の複雑さと思想的一貫性の欠如を招きます。
業界の言語を話すソフトウェアを選ぶ
ERP市場には強力で有能なシステムが並んでいます。それぞれが、設計された業界に対して本当に優れた性能を発揮します。課題は「良い」ERPを見つけることではありません。自社の運用実態と中核的前提が一致するERPを見つけることです。
建設、インフラ、海洋、造船、その他のプロジェクト型産業の組織にとって、それは、オペレーションの複雑さが最初に来るシステム、BoQ が後付けではないシステム、生産計画が財務予測を主導するシステム、そしてプロジェクト型業務特有の変動性が、無理なく受け入れられるのではなく、最初からアーキテクチャに組み込まれているシステムを求めることを意味します。
ERPのDNAは重要です。自社の業界の言語を話すヘリテージを持つシステムを選びましょう。
