
システム構成
基幹システム
SoR / System of Record
販売、購買、在庫、生産、会計、人事給与など、取引を金額と数量で確定させて記録する業務のシステムです。基幹システムには変化の少ない処理だけを実装し、変化の速い機能は周辺のシステムで開発するほうがよいです。
いーあーるぴー / 統合基幹業務システム / Enterprise Resource Planning
会計、販売、購買、在庫などの基幹業務を1つのデータでつなぐ統合パッケージです。費用と期間は製品の標準に業務をどこまで適合させられるかで決定します。

ERPは会計、販売、購買、在庫、生産、人事といった基幹業務を、1つのデータベースの上で集約して処理するソフトウェア製品です。
日本語では統合基幹業務システムと呼びます。
SAP S/4HANAやOracle NetSuiteのような海外製品のほか、中堅企業向けの国産製品も多くあります。
会社の取引を記録する基幹システムを、1つの統合製品で実現する手段にあたります。
部門ごとにシステムを分離していると、販売管理の売上を会計ソフトへ転記して在庫表と突合する作業が、月末に集中します。
販売管理、会計、在庫表で同じ取引の数字が一致せず、どれが正しいかの確認に時間がかかり、子会社や拠点が増加するほど集計の手作業も増加します。
ERPでは受注を入力すると、在庫の引当、売上の計上、会計の仕訳までが同じデータでつながります。
転記と突合が不要になるぶん月次決算が早期化し、拠点別や事業別の数字を同じ定義で比較できます。
誰がいつ入力したかの記録が保存されるため、内部統制や監査への対応もしやすくなります。

製品には受注、仕入、締めの標準的な進め方が組み込まれています。
標準機能にない処理をその会社向けに追加開発したものをアドオンと呼びます。
アドオンを開発するほど今の業務に適合します。
その一方で製品のバージョンアップのたびに改修と再テストが必要になり、保守費が年々積み上がります。
中身を把握しているのが開発した会社だけになり、その会社への依存も続きます。
アドオンを多く抱えたERPは新版へ移行するたびにそれを再構築することになり、数年おきに大規模な更新プロジェクトが発生します。
反対に、製品の標準に業務を適合させる進め方をFit to Standardと呼びます。
クラウド型の普及とともに主流になりました。
保守費と移行の負担は軽くなる一方、業務を変更する負担が導入時に集中してかかります。
帳票の形、承認の順番、締めの手順が変化するため現場の抵抗があり、教育と定着に時間がかかります。
どこまで適合させるかを決定する作業の速さが、そのまま導入の期間を左右します。
クラウド型のERPにはベンダーの共通の環境を複数の会社で利用する製品と、会社ごとに専用の環境を用意する製品があります。
共通の環境を利用する製品では、ベンダーが年に数回機能を更新し、更新の時期を自社では選択できません。
製品そのものを改変する作り込みはできず、追加は製品が用意した拡張の仕組みと、本体の外の周辺システムに限られます。
そのかわり法令改正への対応や基盤の保守はベンダーの更新に委ねられます。
専用の環境を用意する製品では作り込める範囲が広く、更新の時期もある程度選択できます。
利用料は共通の環境を利用する製品より高く、作り込んだぶん自社運用の製品と同じ改修と再テストの負担が戻ってきます。
製品名にクラウドと付いていても、どちらの環境かで費用も導入の進め方も変化するため、提案の段階で確認します。
海外製品ではインボイス制度や電子帳簿保存法のような日本の制度改正に、標準機能でいつ対応するかが製品ごとに異なります。
契約前にベンダーから施行日までの対応予定を提示してもらい、対応が施行日に遅れる場合の追加費用をどちらが負担するかを契約書に定めておきます。
費用の大半はソフトウェア代でなく、業務の整理、設定、データ移行、テスト、教育の作業費が占めます。
多くの会社は導入を支援する会社に依頼するため、そのコンサルタントの費用が最大の項目になりやすいです。
導入後もライセンス料や利用料が人数や機能に応じて毎年かかり、ベンダーの価格改定の影響を受けます。
規模は対象とする業務の範囲で決定します。
中堅企業がクラウド型で導入する場合、会計だけなら初期費用は目安として数百万円から1千万円程度です。
期間は数か月です。
販売、購買、在庫までつなぐと初期費用は数千万円規模になり、半年から1年程度かかります。
利用料は人数と機能に応じて年に数十万円から数百万円規模で続きます。
大企業が複数の事業と拠点にまたがって導入する場合は数年単位の期間がかかります。
総額は数億円を超え、数十億円規模になる例もあります。
外のシステムからERPに伝票を作成させると、その件数で課金する製品もあります。
SAPのDigital Accessがその例です。
システム同士をつなぐ窓口をAPI(Application Programming Interface)と呼びます。
ECサイトや他社製の顧客管理システムがAPIを通じて受注や請求の伝票を作成すると、伝票の種類と件数に応じて料金を計算します。
本体の外の周辺システムで補完する設計にするなら、つなぎ方ごとに課金の対象になるかを契約前に確認します。
社内の担当者も費用の一部です。
製品の設定と業務の両方を理解する担当がいないと、導入後の軽微な変更まで外部へ依頼することになり、その費用が毎年続きます。
稼働直後の停止は売上と取引先との関係に直結します。
江崎グリコでは2024年4月に基幹システムの切り替え後に受発注と出荷が停止した事例があります。
範囲を会計から開始する、拠点を1つずつ切り替えるといった段階的な進め方なら、停止したときの影響を一部に限定できます。
基幹業務がまるごと1つの製品に依存するため、ベンダーが保守を終了する時期に会社の計画が左右されます。
ERPの製品は世代が交代すると旧版の保守を終了します。
たとえばSAPは旧製品のSAP ERP 6.0について、標準保守を2027年末で終え、保守料の上乗せで2030年末まで延長保守を受けられると発表し、新製品への移行を促しています。
期限の後も旧版を使い続ける道はありますが、どれにも代償があります。
クラウド型でも短期間で済むのはソフトウェアの準備だけで、業務の整理とデータ移行の手間は自社運用の製品と大差ありません。
ERPは会計に加えて、販売、購買、在庫までを1つのデータでつなぐ製品です。
会計の機能だけを切り出して比較すると、ERPは割高な会計ソフトに見えます。
法人と事業が1つで、従業員が目安として100人前後までなら、会計ソフトと販売管理などのSaaS(Software as a Service)をつないだ組み合わせで十分なことが多いです。
従業員数は補助的な目安で、確認すべきは業務の症状のほうです。
ERP(Enterprise Resource Planning)の検討を開始するのは、次の症状が続く場合です。
部門間の転記と突合のせいで月次決算の締めに目安として10営業日以上かかっています。
複数の法人や事業の数字を表計算ソフト上の手作業で合算しています。
在庫の数字と会計の数字が毎月合いません。
子会社や海外拠点を持ち従業員が数百人を超える会社では、多くの場合候補になります。
単一事業で取引の形が単純で、月次の締めが数日で完了しているなら、ERPの導入を提案されても急いで検討しなくてかまいません。
原則は標準に適合させます。
アドオンは他社との差別化になる業務と、法令や取引先の都合で変更できない業務に限定します。
会計・購買・経費精算のように会社ごとの違いが競争力にならない業務は作り込みません。
標準機能と現行業務の差を一覧にし、1件ごとに業務を変更した場合の支障を確認します。
現場の慣れや帳票の見た目だけが理由の差は、業務側を変更します。
事業責任者か経営層がこの判断を下す場がないと、差がそのままアドオンの要望になり、期間と費用が膨らみます。
それでも必要な追加は本体を標準のまま維持できる形から検討します。
照会や入力補助のように会計や在庫の数字に影響しない補助的な画面なら、ノーコードツールで本体の外に構築してかまいません。
売上や会計の数字に直結する処理は、開発会社に周辺システムとして開発してもらうか、製品が用意した拡張の仕組みで本体側に構築します。
本体に作り込むアドオンの見積もりには、本数と開発費に加えて、バージョンアップのたびに必要になる改修と再テストの年額を記載してもらいます。
その額を支払ってでも残すかで決定します。
両方を同じ条件で見積もって比較します。
同じ製品の新版でもデータの構造や画面が変化し、再構築に近い規模になることもあります。
まず自社の版と契約で保守がいつ終了し、延長に何が条件かをベンダーか保守契約の窓口で確認します。
その日を期限として逆算します。
大企業の移行は数年単位でかかるので、保守期限の数年前には構想と製品選定を開始します。
比較の前に、既存のアドオンのうち現在も利用されているものを洗い出します。
利用されていないものを廃止するだけで移行の範囲は縮小します。
延長保守で得た時間は再構築の先送りでなく、業務を標準に合わせる準備に使います。
事業の課題や技術的な悩みなどどんなことでもお聞かせください