基幹システムとは、販売・購買・在庫・生産・会計・人事給与のように、止まると事業そのものが止まる業務を処理するシステムの総称です。特定の製品名ではありません。本記事では、6つの種類と業種による違い、業務システム・情報系システム・ERPとの線引きを整理したうえで、パッケージ・ERP・スクラッチ開発の選び分けと、刷新に踏み切るべき条件を経済産業省やJUAS(日本情報システム・ユーザー協会)の資料をもとに解説します。
まとめ:基幹システムは「止まると事業が止まる」業務を担うシステム群
基幹システムは事業の中核業務を処理するシステム群で、代表例に販売管理・購買管理・在庫管理・生産管理・財務会計・人事給与があります。業務システムや情報系システムとの境界は「停止したとき事業を続けられるか」で引くのが実務的です。ERPは複数の基幹業務を統合管理する実現手段の1つで、対象領域は製品や導入範囲によって異なります。
実現手段はパッケージ・ERP・スクラッチ開発の3系統で、どれが合うかは業務を標準に寄せられるかで決まります。刷新は「古いから」では費用倒れになりやすく、保守期限や担い手の退職のように止まる時期が特定できたときが着手の合図です。大規模になるほどQCDの不良が増え、JUASの調査では500人月以上のプロジェクトの47.8%で工期が遅延しています。要件定義を飛ばしてベンダー比較から入る進め方は避けてください。
基幹システムの定義と停止時の事業影響
「基幹」の範囲を先に確定させます。範囲が曖昧なまま製品比較に進むと、何を刷新するのかが関係者ごとにずれます。
基幹業務の判定基準と、止まったときに起きたこと
基幹業務とは、受注・出荷・請求・支払・給与計算のように、停止が続くと取引先や従業員への義務の履行に支障を来す業務です。あるシステムが基幹かどうか迷ったら、「明日そのシステムが止まったとき、手作業や別のツールで事業を続けられるか」を問います。販売管理システムの停止は出荷や請求に直結しやすい一方、影響の大きさは代替手順の有無と停止時間で変わります。社内チャットも受注の窓口に使っていれば、停止が取引に影響します。
この「止まる」の重さは公開記録で確かめられます。江崎グリコは2024年4月に基幹システムを切り替えた後にシステム障害が起き、チルド商品(冷蔵品)の出荷業務を停止しました。同社の2024年12月6日の発表によれば、障害前の全品出荷の状態に戻ったのは11月5日の出荷分です。2024年12月期の決算短信では、連結営業利益が110億65百万円と前期の186億22百万円から40.6%減り、乳業事業の大幅な減収の理由に出荷停止が挙げられています。切り替え当日に何が起き、どの工程で防げたかは基幹システム刷新の失敗事例と回避策で工程別に分解しています。
基幹系システム・情報系システムという呼び方
金融機関やSIerの現場では「基幹系」「情報系」という対の分類が使われます。基幹系は勘定処理や取引処理のようにオンラインで止められない系統、情報系は分析・帳票・情報共有のように多少の停止が許される系統で、銀行の勘定系システムが基幹系の典型です。提案書でどちらの用語が使われていても、判定の軸は上の「停止したら事業が続くか」と同じです。
基幹システムの種類:6つの領域と業種で変わる中心
種類は「どの業務を処理するか」で分けます。全領域を一度に揃える必要はなく、どこを厚く持つかは業種で決まります。
販売・購買・在庫・生産・会計・人事給与の6領域
| 領域 | 主な管理対象 | 停止時に止まる業務 |
|---|---|---|
| 販売管理 | 見積・受注・出荷・売上・請求 | 出荷指示・請求書発行 |
| 購買管理 | 発注・仕入・検収・支払 | 資材調達・支払処理 |
| 在庫管理 | 入出庫・引当・棚卸 | 在庫引当・欠品把握 |
| 生産管理 | 生産計画・所要量・工程・原価 | 製造指示・進捗把握 |
| 財務会計 | 仕訳・決算・財務諸表 | 月次決算・税務申告 |
| 人事給与 | 社員情報・勤怠・給与・社会保険 | 給与支払・保険手続き |
受注管理や勤怠管理を独立した種類として数える解説もありますが、受注は販売管理の入口、勤怠は人事給与の入力にあたるため、本記事では6領域にまとめています。販売領域を単体で入れるなら販売管理システムが、見積業務だけを先に整えるなら見積管理システムの解説が出発点になります。各領域がERP製品の中でどのモジュール名で呼ばれているかはERPモジュール一覧で製品ごとに対応させています。
業種で変わる中心領域と管理の単位
同じ6領域でも、業種によって中心と「何を単位に数字をつなぐか」が変わります。ここを外すと、汎用パッケージを入れても現場の管理単位と噛み合いません。
| 業種 | 中心になる領域 | 数字をつなぐ単位 |
|---|---|---|
| 製造業 | 生産管理・購買・原価 | 品目・製造指図 |
| 卸売・商社 | 販売管理・在庫管理 | 品目・得意先・ロット |
| 建設・リフォーム | 工事台帳・工事原価・請求入金 | 工事番号 |
| 会計事務所 | 顧問先管理・申告進捗・報酬請求 | 顧問先・申告期限 |
| 保険会社 | 契約管理・保険料収納・保険金支払 | 証券番号 |
建設業やリフォーム会社では、見積から発注・原価・請求入金までを工事番号で追えるかが基幹の要件になり、製造業向けのERPをそのまま入れると合いません。建設業向けの製品比較は建設業向けERPの比較と選び方、工事単位の管理機能は工事管理システムとはで扱っています。会計事務所は会計事務所の基幹システム、保険会社は保険基幹システムとはで、それぞれ業務領域とデータの持ち方を整理しています。
法令が要件を決める部分:帳簿保存・インボイス・電子取引
基幹システムの機能のうち、会計と販売の一部は自社の都合ではなく法令で決まります。会社法432条2項は会計帳簿とその事業に関する重要な資料を帳簿の閉鎖から10年間保存するよう求め、法人税法上の帳簿書類は原則として確定申告書の提出期限の翌日から7年間保存します。青色申告で欠損金が生じた年度や、青色申告以外で災害損失金が生じた年度は10年間で、2018年4月1日前に開始した該当年度は9年間です。適格請求書発行事業者は交付した適格請求書の写しを保存しなければならず、電子取引でやり取りした請求書等のデータは電子帳簿保存法により電子データのまま保存します。
この部分はシステムの入れ替え後も旧データを読める状態で残す必要があるため、刷新計画では移行対象から外したデータの保存方法まで決めておきます。制度改正のたびに帳票や保存方法が変わる領域なので、会計・給与を自社開発せずパッケージに任せる理由の多くはここにあります。会計領域の詳細はERPの会計機能で扱っています。
業務システム・情報系システム・ERPとの違い
周辺の用語は範囲の広さと統合の度合いで並べると整理できます。
| 用語 | 範囲 | 止まったとき | 例 |
|---|---|---|---|
| 業務システム | 社内業務を支えるシステム全般 | 種類による | 基幹システム・経費精算・名刺管理 |
| 基幹システム | 事業の中核業務 | 事業が止まる | 販売管理・会計・給与 |
| 情報系システム | 情報共有・分析 | 生産性が落ちる | メール・グループウェア・BI |
| ERP | 複数の基幹業務を統合管理 | 事業が止まる | SAP・Dynamics 365・OBIC7 |
業務システムとの違い:基幹システムを含む広い言葉
業務システムは社内業務を効率化するシステム全般を指し、基幹システムはその一部です。基幹以外の業務システム、たとえば経費精算や名刺管理が止まっても、一時的に不便になるだけで代替手段で業務は続きます。業務システム全体の種類と導入形態の選び方は業務システムとは?種類・基幹システムとの違いで整理しています。
情報系システムとの違い:情報共有と意思決定を支える領域
情報系システムは、メール・グループウェア・社内SNS・BIツールのように情報共有と意思決定を支えるシステムです。情報共有や分析が主目的でも、受注受付や出荷判断がそのシステムに依存していれば取引は止まります。停止の影響は、業務との依存関係と代替手順で判断します。企業によっては情報系を業務システムとほぼ同義で使うので、社内資料を読むときは名称でなく「止まったら何が止まるか」で分類し直すと、投資の優先順位を誤りにくくなります。
ERPとの違い:複数の基幹業務の統合による実現手段
ERP(Enterprise Resource Planning)は企業資源計画という考え方を指し、ERPシステムは会計・販売・購買など複数の基幹業務を統合管理します。対象領域は製品や導入するモジュールによって異なります。部門ごとに独立した基幹システムを持つ構成では販売データを会計に渡す連携を別途作る必要がありますが、ERPでは受注から売上計上・仕訳までの流れが製品の設計に組み込まれています。ERPは基幹システムと対立する概念ではなく、基幹システムを実現する手段の1つです。ERPという製品カテゴリの機能と歴史はERPとは?意味と基幹システム・CRM・SCMとの違いで掘り下げています。
パッケージ・ERP・スクラッチ開発:3つの実現手段を選び分ける条件
上位に表示される解説記事の多くはパッケージベンダーが自社製品の案内を兼ねて書いたものです。選定では、標準機能で満たせる業務と、競争力のために個別開発が必要な業務を分け、連携費用と保守負担まで比較します。
個別パッケージの採用条件:単一領域の業務課題
会計だけ、給与だけのように課題が単一領域に閉じているなら、その領域のパッケージやSaaSを標準機能のまま入れるのが最短です。帳簿保存やインボイスなどの制度変更は、製品の対応範囲と保守契約に応じてベンダーが改修するため、自社開発部分の改修を減らせます。ただし、自社側の設定変更や連携・帳票の確認は必要です。逆に、複数領域のデータを日次でつなぐ必要が既に見えているなら、個別パッケージの寄せ集めは連携開発がかさみ、数年後にERPへ乗り換える二重投資になりやすい構成です。
ERPの採用条件:標準プロセスへの業務統一
ERPが向くのは、販売から会計までのデータを一元化して経営判断を速めたい企業のうち、自社業務をERPの標準プロセスに寄せる意思決定ができる企業です。標準機能に業務を合わせるFit to Standardで進めないと、カスタマイズが保守費とバージョンアップ費用を押し上げます。固有の商習慣がそのまま競争力になっている企業がERPに業務を合わせると、強みを削ることになります。複数領域を1製品で束ねる国産ERPの例はOBIC7とは、SAP・Salesforce・Dynamics 365の選び方と導入順序はERP/CRM導入の進め方で比較しています。
スクラッチ開発の採用条件:利益を支える固有業務
スクラッチ開発を選ぶべきなのは、パッケージに存在しない業務プロセスが自社の受注や利益率を支えている場合です。たとえば価格決定や個別受注生産の固有要件を、既存製品の標準機能・設定・拡張で満たせず、その差分が利益に直結する場合が候補です。標準的な会計や給与計算をスクラッチで作るのは、法改正対応まで自社で抱えることになるため採用すべきではありません。実務では、会計・給与はパッケージ、受注と在庫の固有部分だけ個別開発するハイブリッド構成が現実的です。クラウドとオンプレミスのどちらに置くかは基幹システム・ERPのクラウドとオンプレミスで5年総額と保守期限から判断しています。
刷新の判断:踏み切るべき時期と、失敗しやすい条件
刷新の効果は、担当者のExcelと記憶に依存していた業務の標準化、受注から請求までの二重入力の解消、締め処理を待たずに売上・在庫・資金繰りを見られることの3つに集約されます。ただし効果が出るかどうかは着手の時期と進め方で決まります。
刷新すべきでない場面:理由が「古いから」だけのとき
現行システムが安定稼働しており、業務上の不満が「古い」という印象しかない場合、刷新は投資に見合いません。解決したい業務課題を金額や工数で言えないうちは着手すべきではありません。規模感の目安として、JUASの企業IT動向調査報告書2026(2025年度調査)ではIT予算の売上高比がトリム平均値で1.47%です。売上高50億円にこの比率を仮に当てはめると、年間のIT予算全体は7,350万円です。ただし、これは個社の予算や基幹システム刷新費用の相場を示す値ではありません。
踏み切るべき時期:保守期限と担い手の喪失時期
安定稼働していても、支える人と保守契約が失われる時期が特定できているなら事情が変わります。SAP ERP 6.0などのSAP Business Suite 7のコアアプリケーションは、SAPの保守方針で最新3世代のエンハンスメントパッケージに限り標準保守が2027年末まで、2028年初から2030年末までは保守料の基準に2ポイント上乗せする延長保守を選べます。影響と移行・延命の選択肢はSAPの2027年問題とはで解説しています。
経済産業省が2018年に公表したDXレポートの「2025年の崖」は、複雑化・老朽化した既存システムが残った場合の経済損失を2025年以降最大12兆円/年(同レポートの推計時点の約3倍)と見積もったものです。これはシステム障害による損失の推計で、刷新の効果額ではありません。同レポートは約8割の企業が老朽システムを抱えているとしています。棚卸しの開始時期は、要件定義、調達、移行・テスト、現場教育と予備期間を保守期限から逆算して決めます。残り期間が足りない場合は、保守延長や対象範囲の縮小も併せて検討します。老朽化したシステム全般の判断時期はレガシーシステムとはで整理しています。
刷新の失敗条件:大規模化と要件定義の不足
JUASの同調査では、プロジェクト規模が大きいほどQCDの不良が増えます。10人月未満では品質・予算・工期とも不良が10.0%を下回る一方、500人月以上では品質の不満が29.6%、予算超過が42.2%、工期遅延が47.8%です。QCDの悪化に影響した工程(複数回答)は、「要件定義」(57.4〜69.0%)と「設計・実装・テスト」(51.7〜74.1%)の2工程が高く、ほかの工程を大きく上回りました。
典型は、自社業務の棚卸しをせずに製品デモの印象で選定し、導入段階で「現行業務と違う」という声に押されてカスタマイズを積み増すパターンです。バージョンアップのたびに改修が必要な構造が固定化し、保守費が下がらなくなります。判決や開示資料で金額まで追える事例はERP導入の失敗事例と導入事例にまとめています。
刷新・導入の進め方:業務棚卸しから外注先選定まで
導入形態を問わず、進め方の骨格は共通です。刷新と更改・リプレイスの言葉の違いと、保守期限から逆算する計画の立て方はシステム更改とはで扱っています。
現行業務の棚卸しと要件定義:標準化対象と固有要件の仕分け
最初の工程は、部門ごとの業務フローと、現行システム・Excel・紙で管理しているデータの一覧化です。このとき現行のやり方をそのまま新システムに載せるのではなく、やめられる業務・標準に寄せられる業務・変えられない業務を仕分けることが要件定義の中身になります。要件定義はQCD悪化に影響した工程として回答の多い2工程の1つなので、見積を比べるときは各社が要件定義に何人月を置いているかを最初に確認してください。法令で保存が必要な旧データの扱いもこの段階で決めます。
段階刷新とビッグバン刷新の選定条件:並行稼働と切替リスク
全領域を一斉に切り替えるビッグバン刷新は暫定連携の開発が要らない半面、切り替え時のリスクが一点に集中します。切り替え直後に障害が出れば、グリコの事例のように出荷が止まります。領域ごとに順次切り替える段階刷新はリスクを分散できますが、新旧の並行稼働期間に暫定連携の開発と二重運用の負荷がかかります。現場教育を一斉に行えず、新旧の並行運用を維持できるなら段階刷新を選びます。着手領域は販売・在庫に固定せず、保守期限、システム間の依存関係、障害時の売上影響から決めます。
外注先の選定基準:業種理解と要件定義の支援力
成否を分けるのは製品の機能一覧よりも、外注先が自社の業種と業務を理解して要件定義を支援できるかどうかです。提案段階で自社の業務フローについて具体的な質問をしてくるか、標準機能で吸収できない要件に代替案を示せるかを見てください。発注時にRFPへ何を書くかはシステム刷新のRFPで、稼働後の運用保守の体制と委託範囲は基幹システムの運用保守で扱っています。一創では、業務の棚卸しから要件定義、パッケージ連携とスクラッチ開発を組み合わせた構成まで、基幹システム開発として一貫して支援しています。
基幹システムに関するよくある質問
基幹システムは英語で何と言いますか?
決まった1語の訳はなく、文脈で使い分けます。中核業務のシステム全体を指すときは core system や core business system、止められない性質を強調するときは mission-critical system、顧客に見えない後方業務を指すときは back-office system が使われます。
基幹システムの大手はどこですか?
国内のERP・基幹システム市場の1位は、売上金額・導入社数・利用者アンケートのどれで測るかで入れ替わります。比較候補にはSAP、Oracle、オービックなどがあります。順位を比較するときは、調査年、対象企業の規模、製品範囲、売上金額などの集計指標を揃えて確認します。調査ごとの数字と順位の読み方はERP市場規模とシェアで比べています。
基幹システムの導入にはどのくらいの期間がかかりますか?
公開例として、三井情報のサービス業界向けSAP S/4HANA Cloud Public Edition定額導入プランはフル導入で最短9ヵ月、会計のみで最短半年と示しています。これはスコープを固定した場合の最短値で、追加開発や複数拠点への展開があれば延びます。導入期間は、対象業務、追加開発、データ移行、外部連携、テスト、要件の確定状況によって変わります。
ERPを導入すれば基幹システムは不要になりますか?
ERPを入れること自体が基幹システムを持つことにあたるので、不要になるのではなく置き換わります。ERPの標準機能で吸収できない固有業務には、製品が提供する拡張機能を使う方法と、外部の個別システムを連携させる方法があります。
中小企業にも基幹システムは必要ですか?
販売・会計・給与のどれかを手作業やExcelで回していて、担当者が休むと請求や給与支払が止まるなら必要です。ただし中小企業では6領域を一度に揃える必要はなく、会計と給与はクラウドのパッケージ、販売と在庫は取引量に応じて販売管理システムを足すという順で十分なことが多くあります。