ERPとは、会計・販売・購買・在庫・生産・人事といった基幹業務のデータと処理を、共通のデータ定義に基づいて統合する仕組みです。日本語では統合基幹業務システムと呼ばれます。ただし「統合」「一元管理」という言葉だけを受け取ると、導入後に「全社の数字がどこからでもすぐ見えるはずだったのに違った」という食い違いが起きます。この記事では、ERPという語の意味を整理したうえで、Dynamics 365の公式ドキュメントで「1つのデータベース」がどこまで1つなのかを確認し、基幹システムとの違い、導入が求められる背景、自社に必要かどうかの判断軸までを順に説明します。
まとめ:ERPの定義・統合範囲・導入判断
- ERPはEnterprise Resource Planningの略で、読み方は「イーアールピー」です。日本語訳は企業資源計画、システムを指す場合は統合基幹業務システムが使われます。
- ERPの中身は、業務ごとに別々のシステムとデータベースを積み上げるのではなく、共通のデータ定義の上で受注・出荷・請求といった処理が情報を引き継ぎ、在庫や会計の記録を生成する構造です。
- 「統合」は全社の全データが区切りなく1つになるという意味ではありません。本記事で確認したDynamics 365 finance and operationsでは、会社(法人)単位のデータ区分とアクセス権が設けられており、法人をまたいで共有できるのは勘定科目表などの一部です。
- ERPが必要とされる背景には既存システムの老朽化があります。経済産業省のDXレポートは、複雑化・老朽化・ブラックボックス化した既存システムが残存した場合、2025年以降の経済損失が最大12兆円/年にのぼる可能性があるとしています。ただしこれはレガシーシステムに起因するシステム障害の損失推計であって、ERPの導入効果額ではありません。
- 導入するかどうかは企業規模ではなく、同じ事実を複数の部門が別々のシステムに記録しているか、その突き合わせに人手と日数がかかっているかで判断します。
ERPとは何か|言葉の意味と2つの使われ方
正式名称は Enterprise Resource Planning
ERPはEnterprise Resource Planningの頭文字で、読み方は「イーアールピー」です。直訳すると企業資源計画となり、ヒト・モノ・カネ・情報という経営資源を全社の視点で計画し配分するという考え方を指します。日本ではこの考え方を実装したシステムを指して統合基幹業務システム、あるいは単にERPシステムと呼ぶのが一般的です。
注意したいのは、ERPという語が2つの層で使われている点です。1つは経営資源を全社で計画するという経営手法そのもの、もう1つはそれを実現するためのソフトウェア製品です。製品としてのERPは市販のパッケージとして提供されることが多く、この文脈ではERPパッケージとは?ERPとの違い・主要製品の価格と保守期限で整理しているとおりERPパッケージという言い方をします。記事や提案書で「ERPを導入する」と書かれているときは、ほとんどの場合この製品としてのERPを指しています。
ERPのデータ連携と重複入力の削減
ERPの設計思想は、同じ事実を二度記録しないという一点に集約されます。たとえば商品の販売では、在庫の減少、売上の計上、売掛金の発生という3つの結果が関連します(出荷と会計計上のタイミングは、製品の処理や設定によって異なります)。販売システム・在庫システム・会計システムが別々に存在する構成では、この3つに関わるデータを、手入力やAPI、イベント通知、バッチ処理などで連携する必要があります。手入力に頼れば入力漏れと転記ミスが起き、夜間バッチに頼れば連携が終わるまで会計側の数字は古いままです。
ERPでは受注・出荷・請求の情報を引き継ぎ、各処理の実行時に、設定に応じて在庫や会計の記録を生成します。締め処理のたびに部門間で数字を突き合わせる作業が減るのは、集計を速くしているからではなく、突き合わせる対象そのものを1つにしているからです。逆に言えば、この構造から得られる効果は、複数の部門が同じ事実を別々に持っている企業ほど大きく、もともと業務が1つの流れで完結している企業では小さくなります。
ERPの統合の実体|Dynamics 365に見るデータ区分と共有範囲
ERPの説明では統合データベース、データの一元管理といった表現が繰り返し使われます。導入を検討するときは、その共通データベースの内側でデータがどう区切られるかまで見ておく必要があります。ここは製品ドキュメントで確かめられる部分です。以下は、Microsoft Learnで公開されているDynamics 365 finance and operationsの公式ドキュメント「Organizations and organizational hierarchies overview」「Plan your organizational hierarchy」「Company concept in Dataverse」に記載されている内容です。
会社単位のデータ区分とアクセス権
Dynamics 365 finance and operationsでは、会社(company)は法律上の構成であると同時に業務上の構成でもあり、さらにデータのセキュリティと可視性の境界でもあると説明されています。利用者は常に単一の会社のコンテキストで作業し、ほとんどのデータは会社を単位として区分(striping)されます。
組織の種類としては法人(legal entity)・業務単位(operating unit)・チームが定義でき、このうち法人は登記または法令に基づく法的構造を持つ組織を指します。ドキュメントでは、現在作成できる法人は会社だけであり、すべての法人には会社ID(データモデル上はDataAreaId)が結び付くと明記されています。そのうえで、会社IDを使う機能領域では会社がデータセキュリティの境界となり、利用者はその時点でサインインしている会社のデータにしかアクセスできないとされています。
この区切りはデータモデルの層でも確認できます。同じくMicrosoft Learnの開発者向けドキュメント「Application Explorer properties」のテーブルプロパティ一覧には、そのテーブルのデータを会社単位で保存するかどうかを指定する設定(SaveDataPerCompany)があり、これを「いいえ」にするとデータは会社識別子(DataAreaId)を持たずに保存されると説明されています。裏を返せば、会社単位で保存する設定になっているテーブルのレコードは、すべて会社識別子を伴って格納されているということです。1つのデータベースの中で、会社に属するデータと会社に属さないデータがテーブル単位で分かれている構造だと分かります。
つまり、物理的に1つのデータベースに入っていることと、全社の担当者が同じデータを区別なく見られることは別の話です。グループ会社をまたいだ数字をすぐ出したいという期待は、この区切りを理解しないまま持つと外れます。
法人別の元帳・設定と法人間で共有するマスタ
同じドキュメントでは、組織を法人としてモデル化した場合と業務単位としてモデル化した場合で、何が分かれ何が共有されるかが項目ごとに整理されています。主要な項目を表にまとめます。
| 項目 | 法人としてモデル化した場合 | 業務単位としてモデル化した場合 |
|---|---|---|
| 取引データ | 会社IDで自動的に保護され、アクセスできる会社のデータのみ参照可能 | 個別のデータセキュリティポリシーを作って制限する |
| モジュール設定 | 債権・債務・現預金管理などのパラメータを法人ごとに設定する | 業務単位の間で共有される |
| 元帳 | 法人ごとに元帳が必要(勘定科目表・会計通貨・報告通貨・会計カレンダーを持つ) | 業務単位は独自の元帳を持てない |
| 会計カレンダー | 法人ごとに独自の会計カレンダーを持つ | 業務単位は会計カレンダーを共有する |
| 貸借対照表 | 法人単位でのみ作成できる | 業務単位では損益計算書を作成する |
| 連結 | 連結用会社への集約、またはFinancial reportingでの連結 | データが共有済みのため連結は不要 |
一方で、法人をまたいで使える要素も明示されています。主勘定・ディメンション・勘定構造・勘定科目表・勘定ルールは複数の法人で利用できるとされており、グループ全体で勘定科目の体系をそろえること自体は可能です。ここが「統合」の実体に近い部分で、共通化されるのは主にマスタと設定の体系であり、取引データそのものは法人の枠で保持されます。
会社に属さないデータの代表が、取引先の情報を横断して持つグローバルアドレス帳です。「Party and global address book」の説明では、取引先(party)は組織または個人であり、名称・言語・連絡先・住所といった属性をグローバルに保存して管理するとされています。ある場所で属性の値を変更すると、その取引先が関わるすべての場所に変更が反映されます。複数法人の取引先レコードを同じpartyに関連付けている場合、共通の住所変更を法人ごとに入力し直す必要がなくなります。取引データを会社単位で保持しつつ、取引先の共通属性を共有する仕組みは、Dynamics 365におけるデータ統合の一例です。
モジュールのパラメータが法人ごとに分かれるのは制約ではなく、各国・各社の制度要件や商慣行に合わせるための設計だとドキュメントでは説明されています。海外子会社を持つ企業がグループ共通のERPを導入しても、各法人の会計処理はその法人の設定で動くということです。
ERPが扱う業務領域と、基幹システムとの違い
ERPが扱う業務領域
ERPが標準で備える業務領域は製品によって差がありますが、おおむね次の範囲に収まります。どの領域まで自社が使うかを決めることが、導入範囲の設計そのものになります。
| 業務領域 | 主に扱う内容 |
|---|---|
| 財務会計 | 仕訳・総勘定元帳・債権債務・固定資産・決算 |
| 管理会計 | 部門別採算・原価計算・予算管理と実績対比 |
| 販売管理 | 見積・受注・出荷・請求・売上計上 |
| 購買管理 | 発注・入荷・検収・仕入計上・支払 |
| 在庫管理 | 在庫数量と評価額・入出庫・棚卸 |
| 生産管理 | 部品表・所要量計算・製造指図・製造原価 |
| 人事給与 | 従業員情報・勤怠・給与計算・人件費の会計連携 |
| 経費・プロジェクト | 経費精算・プロジェクト別の収支と工数 |
領域ごとの機能の粒度と、主要製品がどこまで標準で持っているかはERPモジュール一覧|主要10分野の機能とSAP・国産ERPの対応表にまとめています。会計領域を管理会計や部門別採算まで踏み込んで設計したい場合はERPの会計機能とは?財務会計・管理会計と部門別採算の作り方を参照してください。生産管理については、ERPが担う計画・原価の範囲と、製造実行システムが担う現場側の範囲の線引きが論点になるため、製造業のERPとは?MES・生産管理システムとの境界と導入判断で扱っています。
基幹システムとの違いは対立ではなくデータの持ち方
ERPと基幹システムは、しばしば対立する2つの選択肢のように並べられます。しかし基幹システムとは企業の中核業務を支えるシステムの総称であり、ERPもその1つです。対立しているのは、業務ごとに別のシステムとデータベースを積み上げる構成と、共通のデータベースの上に業務機能を載せる構成という、実装方式の違いです。
| 観点 | 業務別に構築した基幹システム | ERP |
|---|---|---|
| データの持ち方 | システムごとに別のデータベース | 共通のデータベース(会社単位で区分) |
| データの受け渡し | 連携インターフェースを個別に開発する | 同じ取引から各領域の記録が生成される |
| 業務への合わせ方 | 自社の業務手順に合わせて作り込める | 製品の標準機能に業務を合わせる前提 |
| 導入の進め方 | 必要な業務から順に導入しやすい | 領域をまたぐため導入範囲の設計が必要 |
| 変更したときの影響 | 連携項目や仕様を変える場合は他システムにも波及する | 1つの変更が他領域の処理に波及しうる |
どちらが優れているかという問いには意味がありません。業務別のシステムは、その業務の手順が自社固有で、他部門とのデータの受け渡しが少ない場合に有効です。ERPは、同じデータを複数部門が使い、部門をまたいだ数字が必要な場合に効きます。基幹システムという語の指す範囲、業務システムとの使い分け、刷新の進め方については基幹システムとは?業務システム・ERPとの違いと構成領域・刷新の進め方を解説で詳しく扱っています。
なお、ERPの中にも全業務を1つの製品で賄う統合型と、業務単位の製品を組み合わせるコンポーネント型があり、この選択によって「どこまでが1つのデータベースか」は変わります。製品タイプの見分け方はERPの種類とは?統合型・コンポーネント型・業種特化型の違いと提供形態での見分け方を参照してください。
ERPが必要とされる背景|既存システムの老朽化と「2025年の崖」
ERPの導入が検討される直接のきっかけは、多くの場合ERPそのものへの関心ではなく、既存システムが維持できなくなることです。この問題を正面から扱った公的な文書が、経済産業省のデジタルトランスフォーメーションに向けた研究会が平成30年9月7日に公表した「DXレポート ~ITシステム『2025年の崖』の克服とDXの本格的な展開~」です。
同レポートは、複雑化・老朽化・ブラックボックス化した既存システムが残存した場合、2025年までに予想されるIT人材の引退やサポート終了等によるリスクの高まり等に伴う経済損失は、2025年以降に最大12兆円/年(同レポートの推計時点の約3倍)にのぼる可能性があると記しています。この金額を導入判断に使う前に、推計の前提と算出方法を確認します。レポートの注記では次のように積み上げられています。
- EMCジャパンの調査をもとにした情報処理推進機構のまとめ(2016年2月公開・2018年3月更新)で、データ損失やシステムダウン等のシステム障害により生じた2014年1年間の損失額は国内全体で約4.96兆円。
- 日経コンピュータ2017年8月3日号による2010年代のシステムダウンの原因別割合のうち、レガシーシステムに起因して起こる可能性があるものをセキュリティ29.1%・ソフトの不具合23.1%・性能や容量不足7.7%・ハードの故障や不慮の事故19.7%と仮定すると合計79.6%。4.96兆円×79.6%で約4兆円/年。
- 日本情報システム・ユーザー協会「企業IT動向調査報告書2016」で、企業が保有する最も大きなシステム(レポートは基幹系システムに相当するものとしています)が21年以上前から稼働している企業は20%、11年から20年稼働している企業は40%。この状態のまま10年後の2025年を迎えると21年以上稼働が60%になるため、トラブルリスクも3倍になると推定。
したがって12兆円は、レガシーシステムに起因するシステム障害による経済損失の推計です。ERPを導入すればこの金額が回収できるという意味ではありませんし、ERPが唯一の対策として示されているわけでもありません。提案資料でこの数字がERPの導入効果として引用されていたら、前提がすり替わっていないか確認してください。
同レポートは別の箇所で、協調領域として検討し得る分野を挙げるなかで、人事・ロジスティクス・CRM等のERPの浸透度が低く、日本企業の生産性を落としている可能性のある分野があると指摘しています。会計を中心に部分的にERPを使っている一方で、その周辺の領域が個別システムのまま残っているという状態は、レポートが公表された時点で既に課題として認識されていたことになります。
ERPで解決できること・できないこと
ERPによる重複入力の削減と締め処理の効率化
ERPの共通データ構造は、重複入力の削減に加え、データ定義の統一や部門横断の分析を支えます。具体的には、部門間の二重入力や突き合わせ作業を減らせること、在庫数量・在庫評価額と会計記録を関連付けて確認できること、月次の締めで各システムから集めて表計算ソフトで合算していた工程が減ること、権限と操作履歴を1つの基盤で管理できることです。
ERP導入時に別途必要な連結設定・外部連携・業務設計
一方で、ERPを導入しても別の手当てが要る領域があります。Dynamics 365で複数法人の連結財務情報を作る方法には、連結用会社へ集約する方式と、Financial reportingでレポート生成時に連結する方式があります。グループ会社を含めて同じERPを使っていても、連結の数字が自動的に出てくるわけではありません。同様に、モジュールのパラメータは法人ごとの設定であるため、各法人の制度対応はその法人の設定として行います。
現場の実行系も範囲外になりがちです。工場の作業指示や設備からの実績収集、倉庫内の作業指示といった領域は、ERPの標準機能でどこまで賄えるかが製品によって異なります。外部のSaaSや既存システムを残す場合は、どの方式で連携するかを別途設計する必要があり、この論点はERP連携とは?連携先別の設計とAPI上限から決める方式選定・失敗条件で扱っています。
標準機能に業務を合わせる範囲と、拡張する範囲も決める必要があります。自社の手順を再現するために、標準のデータ定義や処理を無計画に変更すると、整合性の維持や保守、更新時の検証の負担が増えます。製品が提供する拡張機構の利用と、標準部分の改変は区別してください。この論点で実際に何が起きたかは、判例や開示資料で金額まで確認できる事例をERP導入の失敗事例と原因|判例・開示資料で確認できる4件と回避策にまとめています。
自社にERPが必要かを判断する4つの観点
ERPが必要かどうかは、従業員数や売上高といった規模の目安では決まりません。同じ規模でも、業務が1つの流れで完結している企業と、部門ごとにシステムが分かれている企業では答えが変わるためです。次の4点を確認してください。
- 同じデータを複数の部門が別々に持っているか。受注情報を販売部門と生産部門と経理部門がそれぞれのシステムに入力している状態であれば、ERPの構造が効きます。二重入力や照合負荷がなく、既存システムの保守も継続でき、刷新費用を上回る効果を見込めない場合は、ERPへの全面刷新を採用すべきではありません。
- 月次決算に何日かかっているか。締めの日数の大半がシステムからの出力と表計算ソフトでの突き合わせに使われているなら、それは統合されていないことのコストです。
- 法人や拠点が複数あるか。複数法人がある場合は、法人ごとに分かれる項目と共有する項目の設計が必要になるため、ERPの選定段階からこの観点を入れる必要があります。単一法人であれば法人間連結の設計は不要ですが、拠点・部門・権限・業務の設計は残ります。
- 既存システムの保守が続く見込みがあるか。サポート終了や担当者の退職が見えている場合、刷新の期限は自社の都合ではなく外部要因で決まります。この場合は「ERPにするか」より先に「いつまでに移行を終えるか」が制約条件になります。
必要だと判断したあとは、製品タイプの選択(ERPの種類)、クラウドかオンプレミスかという提供形態の選択(クラウド型ERPとは何か?企業導入のポイントからメリット・デメリットまで徹底解説)、費用と保守期限の確認(ERPパッケージとは?ERPとの違い・主要製品の価格と保守期限)という順に具体化していきます。国内でどのベンダーがどれだけ使われているかは、集計のものさしによって順位が変わるためERP市場規模とシェアの最新データ|国内2,558億円・ベンダー別順位の読み方で確認してください。
よくある質問
ERPとはわかりやすく言うと何ですか?
会計・販売・購買・在庫・生産・人事といった基幹業務を、共通のデータベースの上で扱う仕組みです。業務ごとに別々のシステムを持つ構成では、同じ取引を複数のシステムに入力し、あとで突き合わせる必要があります。ERPは取引を1回記録すれば、在庫や会計への反映が同じ記録から生成されます。日本語では統合基幹業務システムと呼ばれます。
ERPの読み方と正式名称は何ですか?
読み方は「イーアールピー」です。正式名称はEnterprise Resource Planningで、直訳は企業資源計画です。経営資源を全社の視点で計画するという考え方を指す場合と、それを実装したソフトウェア製品を指す場合があり、後者は特にERPパッケージと呼ばれます。
ERPを導入する目的は何ですか?
部門ごとに分断されたデータを共通の基盤に集め、同じ事実を二度記録しない状態を作ることです。業務・マスタ・権限を適切に設計することで、二重入力の削減、締め処理の短縮、業務記録と会計記録の照合効率化、権限や操作履歴の管理基盤の共通化が期待できます。逆に、これらが現状で問題になっていない企業では導入の効果は限定的です。
ERPと基幹システムの違いは何ですか?
基幹システムは企業の中核業務を支えるシステムの総称で、ERPもその1つです。基幹システムは業務上の役割を表す総称で、ERPは複数の基幹業務を統合する仕組みです。比較する際は、ERPと、業務別に個別構築したシステム構成を比べます。用語の範囲と刷新の進め方は、基幹システムを主題にした記事で詳しく扱っています。
ERPを入れれば全社のデータが1つになりますか?
ERPを導入しても、全データが物理的に1つのデータベースへ入るとは限りません。また、共通データベースを使う場合にも、会社や権限による区分があります。Dynamics 365 finance and operationsの公式ドキュメントでは、会社がデータのセキュリティと可視性の境界であり、利用者は常に単一の会社のコンテキストで作業し、ほとんどのデータが会社を単位に区分されると説明されています。複数法人の連結財務情報を作る場合は、連結用会社への集約やFinancial reportingなど、連結方式の選択と設定が必要です。