「基幹システムを刷新する」という話が社内で出ているのに、その基幹システムがどこまでを指すのかは、人によってまるで違う。情シスは販売管理と生産管理を思い浮かべ、経理は会計ソフトを想像し、経営層は「社内のシステム全部」を頭に置いている。この状態のまま開発会社に相談すると、金額も期間もバラバラの提案が返ってきて、そもそも比べられません。用語の意味を調べに来た方の多くは、その手前で足踏みしているのではないかと思います。
基幹システムとは、販売管理や生産管理、会計、人事給与のように、止まると事業そのものが止まる業務を支える仕組みのことです。ただ、発注する側にとって本当に必要なのは言葉の定義そのものではなく、「自社ではどこまでを基幹システムと呼び、どこまでを一括で作り替えるのか」という範囲の線引きです。範囲が曖昧なままだと見積もりの前提が揃わず、着手後に追加費用として跳ね返ってきます。この記事では、業務システムやERPとの違いと主な種類を押さえたうえで、範囲の決め方と、発注前に自社側で決めておくことを整理します。
この記事のポイント
- 基幹システムとは止まると事業が止まる業務を支える仕組みで、部門単位の業務システムとは影響の大きさが違う
- ERPとの違いは、業務ごとに独立したシステムの集合か、ひとつのデータベースで統合されているか
- どこまでを基幹システムに含めるかで、刷新の見積もり金額と期間は大きく変わる
- パッケージ・クラウドERP・個別開発のどれを選ぶかが、そのまま誰に何を頼むかを決める
目次
基幹システムとは？業務システムやERPとの違い
まずは前提をそろえます。基幹システムという言葉は、売る側の説明では「販売管理・在庫管理・会計……」といった機能の列挙で語られることが多いのですが、機能名を覚えても自社の判断には使えません。ここでは、止まったときの影響という切り口で定義を押さえ、そのうえで業務システム・情報系システム・ERPとの違いを整理します。
止まると事業が止まる仕組みが基幹システム
基幹システムの定義でいちばん実用的なのは、「止まったときに事業が続けられなくなるかどうか」で線を引く考え方です。受注を受け付けられない、出荷指示が出せない、請求書が発行できない、給与が計算できない。こうした業務を支えているシステムが基幹システムに当たります。基幹業務システム、基幹系システムという呼び方も同じ意味で使われます。
この線引きが実用的なのは、自社で確かめられるからです。試しに「明日このシステムが止まったら、何時間で業務が回らなくなるか」を主要なシステムごとに書き出してみてください。数時間で受注処理が滞るなら基幹、数日は表計算と手作業でしのげるなら基幹の外側、という判断ができます。私の感覚では、この作業をやっただけで社内の認識のズレが半分くらい解消します。
逆に、「重要なシステムかどうか」で線を引こうとすると必ず揉めます。どの部門も自分たちが使っているシステムを重要だと考えるからです。重要度ではなく、止まったときに代替手段があるかどうかで判断するほうが、社内の合意が早く取れます。
業務システム・情報系システムとの違い
基幹システムと業務システムの違いも、同じ「止まったときの影響」で説明できます。業務システムは特定の部門や用途の効率化を目的にしたもので、止まれば不便ではあっても、手作業や別のツールで業務そのものは続けられます。情報系システムと呼ばれるグループウェアやBIツールも同じ位置づけで、基幹システムが生み出したデータを参照・加工する側に立ちます。
| 観点 | 基幹システム | 業務システム・情報系システム |
|---|---|---|
| 目的 | 事業の根幹業務そのものを回す | 特定部門の効率化・情報の活用 |
| 止まったときの影響 | 受注・出荷・請求・給与が止まる | 不便になるが代替手段で継続できる |
| 対象範囲 | 複数部門にまたがる | 部門単位・用途単位 |
| データの位置 | 他システムへ渡す元データを持つ | 基幹側のデータを参照・加工する |
| 代表例 | 販売管理・生産管理・財務会計・人事給与 | CRM・グループウェア・BI・勤怠管理 |
ここで注意したいのは、この分類が会社によって動くことです。たとえば在庫管理は、卸売業では出荷が止まる基幹システムそのものですが、在庫をほとんど持たない業種では周辺の業務システム扱いになります。勤怠管理も、一般的には業務システムですが、シフトで現場が動く業種では基幹に近い扱いになります。一般論の分類表をそのまま自社に当てはめず、自社の事業でどれが止まると困るのかで並べ替えてください。
ERPとの違いは統合されているかどうか
ERPとの違いは、対象業務ではなく「作り方の思想」にあります。基幹システムは、販売管理は販売管理、会計は会計と、業務ごとに独立して導入・開発されてきた集合体を指すことが多く、システム間はデータ連携でつないでいます。一方のERPは、ひとつの統合データベースの上に各業務の機能を載せる考え方で、部門をまたぐデータが最初からつながっています。
この違いが発注実務でどう効くかというと、社内調整の質が変わります。個別のシステムを維持したまま作り替えるなら、業務のやり方は今のまま残せますが、連携部分の作り込みとその後の保守が残ります。ERPパッケージに寄せるなら、連携の手間は減る代わりに「業務をパッケージの標準機能に合わせる」という交渉が社内で必ず発生します。技術の選択というより、業務を変える覚悟をどこまで持てるかの選択に近いです。
もうひとつ、よくある誤解に触れておきます。ERPを入れれば社内のシステムが全部統合されるわけではありません。実際には、業種特化の生産管理や倉庫側のシステム、EDIなどは外に残ることが多く、連携は形を変えて残ります。ERPは統合の範囲を広げる手段であって、連携をゼロにする道具ではないという前提で検討してください。
基幹システムの主な種類と業種による差
基幹システムの種類として挙げられるのは、おおむね次の6つです。種類の名前を覚えることが目的ではなく、自社にどれがあり、それぞれが止まると何が起きるのかを把握することが目的なので、右列とあわせて確認してください。
| 種類 | 主な役割 | 止まったときに起きること |
|---|---|---|
| 販売管理 | 受注から売上・請求までの管理 | 受注処理と請求書の発行が止まる |
| 購買・発注管理 | 仕入れと支払いの管理 | 仕入れの手配ができない |
| 在庫管理 | 在庫数と入出庫の管理 | 出荷指示が出せない |
| 生産管理 | 生産計画・工程・原価の管理 | 製造の計画と進捗が追えない |
| 財務会計 | 仕訳・決算・支払の管理 | 決算と支払処理が止まる |
| 人事・給与 | 人事情報と給与計算 | 給与計算と社会保険手続きが止まる |
どれが自社の中核になるかは業種で変わります。製造業なら生産管理と原価管理、卸売・小売なら販売管理と在庫管理、建設業なら工事ごとの原価管理、人材サービスなら要員の配置管理が事業の心臓部です。ここを外すと、他がどれだけ整っていても事業が回りません。
そして実務上大事なのは、6種類すべてを同時に作り替える必要はまずないということです。中核の1〜2種類だけを刷新し、会計や給与は既存のクラウドサービスをそのまま使い続ける形も十分成り立ちます。種類の一覧は「全部やる」ためのチェックリストではなく、どれを対象にしてどれを触らないかを決めるための材料として使ってください。
基幹システムの範囲で刷新の見積もりは変わる
ここからが、ベンダーの用語解説ページではあまり書かれない発注側の実務です。基幹システムという言葉の範囲は、そのまま発注の範囲であり、見積もりの前提になります。範囲の決め方と、選択肢ごとに発注の形がどう変わるか、そして自社が手放せない役割を順に見ていきます。
どこまでを基幹システムに含めるか
範囲を決めるときは、次の順序で進めると迷いにくくなります。ひとつ目は、前半で書き出した「止まると困る業務」で線を引くこと。ふたつ目は、その線の内側から外に出ていくデータ連携の本数を数えること。みっつ目は、今あるけれど引き継がない機能を決めることです。
連携の棚卸しは、想像以上に見積もりを動かします。EDIでの受発注、銀行との入出金データ、経費精算、倉庫システム、ECサイト、会計ソフト。1本ごとに仕様の確認とテストが必要になるため、連携先が5本の会社と15本の会社では、同じ「販売管理の刷新」でも作業量がまったく違います。相見積もりで金額が大きくずれるときは、この本数の前提が揃っていないことが原因のひとつです。規模別の費用レンジや内訳の見方は、基幹システム刷新の費用相場はいくら？内訳と見積もりの読み方で整理しています。
いちばん効くのは、みっつ目の「引き継がない機能を決める」作業です。「現行と同じにしてください」と伝えた瞬間に、範囲は現行システムの全機能へ膨らみます。長年動いてきた基幹システムには、数年間誰も出力していない帳票や、退職者が作った例外処理が必ず残っています。使っている人がいるかを部門ごとに確認し、引き継がないものを一覧にして開発会社に渡すだけで、見積もりの前提が引き締まります。捨てる判断は発注側でしかできない仕事です。
パッケージ・クラウドERP・個別開発の選び分け
範囲が見えたら、次はどう作るかの選択です。ここで選んだ方式が、そのまま「誰に何を頼むか」という発注の形を決めます。
| 選択肢 | 向いているケース | 発注の形と自社の負荷 |
|---|---|---|
| 業務パッケージ導入 | 業務が業界標準に近く、早く安く整えたい | 導入支援会社に依頼。業務を製品に合わせる調整が主な仕事になる |
| クラウドERP | 全社のデータを一元化し、法改正対応も任せたい | 月額利用料が続く。カスタマイズの制約内で業務を設計し直す |
| 個別開発 | 業務の独自性が競争力になっている | 要件定義から依頼。仕様を決める責任が自社に残る |
実務では、この3つのどれかに全部を寄せるのではなく、混在させる形がいちばん多いです。事業の中核だけを個別開発で作り、会計や給与、経費精算はクラウドサービスに任せる。この組み合わせなら、独自性が必要な部分に投資を集めながら、法改正対応のような手間を外に出せます。既存システムを作り替える方式そのものの比較は、基幹システムの移行方式はどう選ぶ？3つの選択肢と費用の見方で詳しく扱っています。
選び分けで判断がつかないときは、「その業務のやり方は、同業他社と違うことに意味があるか」と自問してみてください。意味があるなら個別開発の対象、特にこだわりがないならパッケージやクラウドに合わせたほうが、費用も期間も保守の負担も軽くなります。独自性の有無を業務単位で仕分けしておくと、開発会社との会話も一気に噛み合うようになります。
発注側が手放せない2つの役割
基幹システムの刷新では、開発会社に任せられない仕事が2つあります。どちらも外注できると誤解されやすく、進行が止まる原因になりがちな部分です。
ひとつ目は、業務要件の確定です。どの業務をどんな流れで回すのか、例外処理をどこまで認めるのかは、自社の事業判断そのものなので、開発会社が代わりに決めることはできません。決めた内容を文書として残す作業も自社側に残ります。何を書けばよいか迷う場合は、要件定義書テンプレート（Word形式）のプロジェクト概要・システム構成・現状フロー・利用者一覧・機能要件といった項目を埋める形で進めると、抜けが見つけやすくなります。
ふたつ目は、データ移行の当事者になることです。どのデータをどこまで持っていくか、取引先マスタの重複や表記ゆれをどう寄せるか、過去何年分を残すか。この判断は業務を知っている人しかできません。移行作業そのものは開発会社が担いますが、判断を丸投げすると、稼働直後に「前のシステムでは出ていた数字が合わない」という形で必ず戻ってきます。
体制の面では、兼務の担当者1人で受けきれる仕事ではない点も先に見ておいてください。部門ごとに決められる人を1名ずつ立て、その人たちが週次で集まって決めていく形が現実的です。人を出せるかどうかで、実は開発会社の選び方も変わります。社内に仕切れる人がいないなら、要件定義から一緒に入ってくれる会社を選ぶ必要があります。
基幹システムについてよくある質問
- Q. 基幹システムと基幹系システムは違うものですか？
- A. 同じものを指します。基幹業務システムという呼び方も同義です。基幹系という言い方は、グループウェアやBIなどの情報系システムと対比するときに使われることが多く、システムの分類上の位置づけを示すための表現です。呼び方の違いを気にする必要はありませんが、社内の資料で表記が混ざっていると議論がぶれるので、稟議や要件定義書ではどれか一つに統一しておくと余計な確認が減ります。
- Q. 基幹システムを簡単に言うと何でしょうか？
- A. 「止まったら商売が止まるシステム」と言い換えると、社内でも一発で伝わります。受注が受けられない、出荷できない、請求できない、給与が払えない。この4つのどれかに直結しているなら基幹システムです。逆に、止まっても数日は表計算や手作業で回せるものは基幹の外側と考えて構いません。経営層への説明では、機能名を並べるより「止まると何日で何が止まるか」を示すほうが話が早く進みます。
- Q. 中小企業にも基幹システムは必要ですか？
- A. 必要かどうかは規模ではなく、手作業に戻れるかどうかで決まります。取引件数が少なく、表計算と会計ソフトで回っているなら、無理に統合された仕組みを入れる必要はありません。判断のサインは、同じ数字を複数の場所に入力している、月次の集計に何日もかかっている、特定の人しか処理できない業務がある、の3つです。どれかが出てきたら、範囲を絞った導入を検討する段階だと考えてください。
- Q. ERPを導入すれば基幹システムの課題は解決しますか？
- A. 全部は解決しません。ERPで統合できるのは製品が対応している範囲までで、業種特化の生産管理や倉庫システム、EDIなどは外に残るのが一般的です。加えて、業務をパッケージの標準機能に合わせる調整が社内に発生します。連携をゼロにする道具ではなく、統合の範囲を広げる手段だと捉えて、残る連携と業務変更の量を事前に見積もっておくことが大切です。
