基幹システムを刷新するには？目的と進め方、失敗・成功事例

長期間使い続けている基幹システムは、処理能力の課題や業務の変化にシステムが追いつかない状態になりやすい時期に差し掛かります。

実行環境のサポート終了期限が近づくほど刷新の検討は具体化しますが、何を目的に進めるかが曖昧なままプロジェクトが始まることも少なくありません。

ここでは、基幹システム刷新の目的や進め方、失敗事例の要点、他社の成功事例まで解説し、着手前に確認したいポイントを整理します。

基幹システム刷新の目的とメリット

基幹システムの刷新とは、既存の基幹システムを新しい環境へ置き換え・再構築し、業務とデータの基盤を立て直す取り組みのことです。ハードウェアやソフトウェアを新しくするだけでなく、経営や業務上の課題を解決することが目的のひとつでもあります。

以下は、基幹システムの刷新で果たす目的と利点の具体例です。

• 増え続ける保守コストを抑える
• 部門や拠点に散らばったデータを統合する
• 内部統制の仕組みを整える

こうした課題解決に向けた刷新のほか、次のような状況が重なる場合は、システム刷新を本格的に検討する段階に入っている可能性があります。

• ハードウェアの老朽化
• 処理能力の限界
• 実行環境のサポート終了
• 業務の変化への対応遅れ
• DX推進
• 法改正対応の必要性

基幹システムの刷新を検討しはじめた段階では、まず自社の現状課題を整理することが出発点になります。課題の棚卸しには、社内のプロジェクトチームに加え、ベンダーが実施する診断サービスの活用も有効です。

1.増え続ける保守コストを抑える

基幹システムの刷新には、老朽化に伴って増え続ける運用・保守コストを抑えるねらいがあります。部分改修の積み重ねでシステムが複雑化すると、改修1件あたりの工数と外注費用が膨らみやすくなります。

保守ベンダーへの依存が強い環境では、帳票レイアウトの変更やマスタ項目の追加といった小さな依頼でも、見積もり期間とコストが想定以上にかかるケースも少なくありません。

また、システムが複雑化して業務の属人化が進むと、障害対応や改修のたびに特定の担当者へ負荷が集中します。属人化したシステムはブラックボックス化しやすいため、余計な追加コストが発生しやすい環境を作ってしまいます。

こうした保守コストの増大に歯止めをかけるため、標準化されたシステムへの移行に向けてシステム刷新が行われています。

2.部門や拠点に散らばったデータを統合する

基幹システムの刷新では、部門・拠点に分断された業務データを統合し、誰が見ても同じ数字を参照できる状態に整えることが、攻めの目的のひとつです。

データが部門・拠点ごとに分断されていると、二重入力やExcelでの取りまとめが発生し、同じデータとして扱える状態にするだけでも時間がかかります。

【データが分断されている場合の影響】

• 月次報告の集計に数日かかってしまう
• 拠点間で売上や在庫の数字が一致せず、整理に時間を要する

データが統合されれば、部門横断・拠点横断で同じ情報をすぐ確認できるようになり、経営判断の土台も整いやすくなります。

3.内部統制の仕組みを整える

基幹システムの刷新では、内部統制をシステムの機能として組み込むことが、重要な目的のひとつです。承認・権限管理・監査対応など、手作業や属人運用から脱却し、業務のなかで継続的に運用できる状態に整えることがねらいとなります。

上記がシステム化されていない環境では、内部統制の仕組み構築がどうしても後手に回りやすくなります。これに伴い、グループ連結への対応遅れや、セキュリティ要件の未達といった課題もドミノ倒しのように発生し、最終的にはコンプライアンス面で重大なリスクを抱えることになりかねません。

【コンプライアンスリスクの具体例】

リスク例	内容
監査手続きの遅延と『不適正』リスク	グループ各社で承認ルートや権限設定がバラバラなままだと、監査時に「誰が・いつ・何を承認したか」の証跡を示せません。結果として監査手続きが大幅に遅延し、最悪の場合は監査法人から内部統制の「開示すべき重要な不備」を指摘されるリスクが生じます。
社会的信用および取引機会の喪失リスク	取引先から求められるセキュリティや内部統制の確認に対し、システムログを一括提示できずExcelの手作業に頼っていると、データの信頼性を担保するコンプライアンス体制を証明できません。

内部統制の整備をはじめ、業務とデータの基盤を立て直す基幹システムの刷新には、ERPパッケージの活用が効果的です。基幹業務の標準化と内部統制の強化を実現する手段として検討してもよいでしょう。

失敗しない基幹システム刷新の進め方

基幹システム刷新は、現状の課題の可視化から本番稼働後の定着化まで、段階を踏んで進めることが大切です。全体の流れは次の5段階に整理できます。

1.現状の課題を可視化する

基幹システムの刷新では、現行システムの構成・利用状況・業務フロー・データの流れを洗い出し、課題を可視化することからはじめます。

情シス部門だけでなく、経理・販売・調達など利用部門へのヒアリングを通じて、As-Is（現状）を整理しましょう。その際、属人化した運用、紙・Excelへの依存、部門間でのデータの分断など、システム以外の課題も含めて把握することが重要です。

システム面と業務・運用面の両方を可視化できれば、論点のすり合わせを進めやすくなります。

2.基幹システム刷新の目的を決める

現状分析の結果をもとに、達成したいゴール（To-Be）を経営視点で定義します。「現行踏襲」ではなく、業務プロセスの見直し（BPR）を伴う刷新か、ハードウェアの老朽化対策にとどめるかなど、プロジェクト全体の方針として整理します。

基幹システムの刷新はプロジェクトの規模も大きくなる傾向があり、参画するベンダーが増えたりプロジェクトの期間も長くなったりします。必要に応じて目的や背景・全体KPIや優先すべき考え方などを「プロジェクト憲章」と呼ばれる基本文書にまとめ、プロジェクトメンバーに共有しましょう。

早期に認識を揃えておくことで、現場と経営の期待値のずれを抑えやすくなります。

3.刷新手法を選定する

刷新の主な手法として、リビルド（再構築）、マイグレーション（移行）、パッケージERP導入の3つがあります。それぞれ、アプリケーションとインフラのどこをどう変えるかが異なります。

自社の規模・業種・独自業務の有無・予算・期間などを踏まえ、刷新手法を選びます。

パッケージERPの導入を選ぶ場合は、Fit to Standard（標準機能に業務を合わせる）の考え方を前提に、過度なカスタマイズを避けることが大切です。開発費や運用開始後のカスタマイズ保守コストを減らすため、業務プロセスの見直しを前提に業務から再編していきましょう。

またベンダー選定では、導入実績・業種理解・支援体制・提案内容の現実性を評価します。RFP（提案依頼書）を作成し、複数社から提案を受けることで、比較検討の精度を上げやすくなります。

4.要件定義に沿ってシステムを構築する

プロジェクト初期段階に決定した目的と手法に基づき、要件定義から構築・テストへと工程を進めていきます。

要件定義では、業務部門の担当者を可能な限り早い段階から参画させることが重要です。現場を交えてFit・Gap分析を進め、Must・Wantを整理しながら優先順位を固めることで、後工程での手戻りを減らしやすくなります。

データ移行計画（マスタの名寄せ、コード体系の統一、過去データの扱いなど）はこの段階から並行して検討を始めておくと、構築フェーズに入ってからの混乱を防ぎやすくなります。

要件が確定したら設計・開発へ移り、構築した機能は単体・結合・総合・ユーザー受入（UAT）と段階を追ってテストします。本番相当のデータで要件どおりに動作するかを確認しながら、次のフェーズに進めます。

5.本番稼働後の定着化を進める

システムが本番稼働に入ったあとは、現場が操作に慣れ、業務として定着できるかどうかが重要です。特に旧システムから操作や帳票形式が大きく変わる場合は、現場の戸惑いや反発が出やすくなります。そのため、稼働前から次のような準備を整えておくことが大切です。

• 現場担当者へのユーザー教育の実施
• 移行直後の現地サポート体制の構築
• 移行期間の問い合わせ窓口の整備

また、稼働後の刷新効果（処理時間短縮、コスト削減、データ活用の進展など）を可視化し、経営層や現場へフィードバックし続けることが重要です。

こうした効果測定は、運用改善はもちろん、次期システムリプレイスの判断材料や改善の指針として活用できるため、継続的にまとめておくとよいでしょう。

【無料】基幹システムのリプレイスのコツ

基幹システム刷新の失敗事例

基幹システムの刷新は、そもそも難易度の高いプロジェクトです。検討対象となる業務範囲が広く、プロジェクト全体の規模が大きくなるほど様々な課題が発生しやすくなります。こうした難しさを踏まえたうえで、事前に失敗しやすいパターンを知っておくことが大切です。

なお、基幹システム刷新における「失敗」とは、単にシステムが動かないことだけを指すのではありません。次のいずれかに該当する場合も、プロジェクトの失敗に含まれます。

• 予算超過
• 稼働時期の遅延
• 期待していた業務効率が得られないこと

また、失敗要因としては次の5点がよく挙げられます。

• 現行システムの理解不足
• システムやベンダー選定の失敗
• あいまいな要件定義
• 業務担当者が不在のプロジェクト進行
• 移行計画の検討不足

こうした失敗要因が実際のプロジェクトでどう表れるか、国内の代表的な2事例を次の表に整理します。

企業	事象	概要	影響
A社	基幹システム 切替時の障害	切替直後にシステムが正常稼働せず、受注から出荷までの一連のプロセスが停止。取り扱い商品の出荷が一時停止	売上高500億円規模の損害。出荷停止が報道され、ブランドイメージも毀損
B社	中継コンピューターのハード 移行に伴う障害	保守期限に伴うハードウェア移行を契機に、企業間データ通信で大規模障害が発生	約2日間サービス利用不能。送受信処理が約560万件におよび、社会インフラとしての影響が表面化

失敗要因の詳細や対策、ほかの事例については関連コラムで解説しています。失敗パターンを押さえたうえで、成功事例もあわせて確認してみてください。

基幹システム刷新の成功事例

失敗のパターンを把握したうえで、対比として参考になるのが成功事例です。プロジェクトの進め方や目的の整理、現場を巻き込んだ推進体制など、失敗要因と重なる部分がどう解消されているかを確認してみてください。

以下では、GRANDIT導入による基幹システムの刷新事例を紹介しています。いずれも老朽システムからの脱却、データ一元管理、業務標準化・内部統制強化といった刷新の目的に沿った取り組みです。

25年稼働の自社開発基幹システムを刷新し、全社統一の業務基盤を構築

株式会社タイトーは、ゲーム・エンターテイメント業界大手です。同社では、約25年前から使い続けたIBM i（旧AS／400）ベースのスクラッチ開発システムが、業務・運用の両面で属人化を招いていました。

グループ会社スクウェア・エニックスの情シス部門と共同で課題を洗い出し、「次の10年を支える経営基盤」としてGRANDITへの刷新を決断しました。

標準化を基本方針に、カスタマイズ・アドオンを抑えた点が特徴です。2021年10月に本番稼働し、部門ごとに乱立していたマスタを統合。全社員が同じインターフェースで業務できる基盤を構築しました。

詳細は導入事例ページをご覧ください。

サポート終了を契機にグループ5社の基幹を統合し、コストを大幅削減

清和中央ホールディングス株式会社は、一般鋼材の卸売・加工・請負工事などを手がける鉄鋼専門商社の持株会社です。傘下に5つの事業会社を持ち、グループ横断で基幹業務を管理しています。

そのグループで20年以上稼働してきた汎用機ベースの基幹システムが、処理能力の限界とデータ蓄積期間の制約、拠点・グループ会社間の運用バラつきを招いていました。

2030年のベンダーサポート終了が迫ったことを契機に、グループ5社を横断するERP刷新を決定しました。経理は標準化、フロント業務は各社要件に合わせて最適化する方針でGRANDITを選定しています。

2022年1月に本番稼働。データの統合により再入力・チェック作業が大幅に削減され、印刷・保管コストは約9割削減、請求業務の電子化も進みました。

詳細は導入事例ページをご覧ください。

基幹システムを再構築し、法令遵守の仕組みを整備

大手メーカー出資の広告代理店である広告業A社。同社では、コンプライアンス経営・内部統制強化の要請を受け、業務コンサルタントの支援のもと全社BPRを実施。業務標準化・決算早期化・管理会計強化の3大テーマを掲げ、基幹業務システムのERP再構築を決断した経緯があります。

基幹システムの刷新に際し、マスタ一元管理、ワークフロー標準装備、職務権限に応じたセキュリティ管理が評価され、GRANDITを選定。拠点ごとにバラバラだった業務フローを統一し、下請法対応を含む法令遵守の仕組みも整えています。

導入開始から10ヶ月で本番稼働に至り、売上・仕入・請求・入金・支払いなど、各業務の入力データが会計まで自動転記される仕組みも整備。手書き伝票の削減、管理帳票のリアルタイム化、月末業務の平準化が進み、締め日周辺の業務負荷が軽減されたことで、残業の減少と管理人件費の抑制にもつながっています。

詳細は導入事例ページをご覧ください。

基幹システム刷新で経営基盤を立て直す

基幹システム刷新の目的は、保守コストの抑制、データ統合、内部統制の整備といった経営・業務課題の解決です。今回ご紹介した5つのステップでシステム刷新を計画し、失敗要因に対する対策も検討しておくことで、プロジェクトの準備が具体的になっていきます。

大規模なプロジェクトだからこそ、最初の一歩は慎重に。いきなりベンダー選定やプロジェクト体制の検討を始める前に、自社の課題を可視化し、社内説明の出発点を整えることが大切です。現状の課題を整理したい場合は、専門ベンダーの簡易診断サービスを活用してみてください。