基幹システム刷新の進め方|SAP・AS/400・レガシーシステム再構築を成功させる構想策定とは

目次

SAPやAS/400の課題は、実は「システムの問題」ではない

近年、基幹システム刷新に関する相談が増えています。背景には、SAP ECCのサポート終了AS/400技術者の高齢化レガシーシステムのブラックボックス化DX推進への対応といった要因があります。

多くの企業が「そろそろ基幹システムを刷新しなければならない」という危機感を持っています。しかし私たちが実際にご相談を受ける中で感じるのは、企業が本当に悩んでいるのはシステムそのものではないということです。

「SAPを継続すべきか」「AS/400をリプレイスすべきか」「クラウドERPへ移行すべきか」という相談であっても、話を深掘りしていくと最終的には、「今後の事業をどのような仕組みで支えるべきか」という経営課題に行き着きます。

だからこそ基幹システム刷新は、単なるITプロジェクトではありません。企業の将来像を描く、経営プロジェクトでもあるのです。


なぜ今、基幹システム刷新が増えているのか

SAP ECCサポート終了という転換点

現在、多くの企業がSAP ECCのサポート終了をきっかけに基幹システム刷新を検討しています。SAP S/4HANAへの移行は避けて通れないテーマとして語られることが多く、実際に大規模なプロジェクトが数多く立ち上がっています。

しかし、本当に考えるべきことは「SAPを移行するか」ではありません。むしろ重要なのは「今後もSAPを中心に業務を構築していくべきなのか」という問いです。

企業によってはSAP継続が最適解かもしれません。一方で、事業環境や組織規模の変化を踏まえると、別のERPやクラウドサービスを選択した方が合理的なケースもあります。SAP ECC終了は、単なるシステム移行の問題ではなく、自社の業務基盤を見直す契機として捉えるべきでしょう。

AS/400の安定性が、逆に課題を先送りしてきた

AS/400を利用している企業からの相談も増えています。興味深いのは、AS/400そのものに大きな不満を持っている企業はそれほど多くないことです。「よく動いている」「止まらない」「安定している」という評価をよく耳にします。だからこそ、刷新の判断が難しくなるのです。

問題はシステムが古いことではありません。長年の運用の中で、業務ルールの属人化設計書の不在改修履歴の消失技術者の高齢化といった状態が積み重なっていることです。

つまり課題はAS/400ではなく、「システムを維持できる人と知識が失われつつあること」にあります。システムの寿命というよりも、維持体制の寿命が近づいているのです。

レガシーシステムが経営の足かせになり始めている

レガシーシステムの問題は、単に古い技術を使っていることではありません。本当に深刻なのは、「変えたいのに変えられない」状態に陥ることです。

新しいサービスを始めたい、新しい販売チャネルを追加したい、グループ会社とのデータ連携を強化したい——そう考えた時に「基幹システムが対応できない」という理由で経営判断そのものが制約されることがあります。

本来、システムは事業を支えるための仕組みです。しかしレガシーシステムが経営の選択肢を狭めてしまうなら、それは単なるIT課題ではなく経営課題と言えるでしょう。


実は「刷新時期」ではなく「刷新理由」が重要

老朽化したから刷新する、では不十分

基幹システム刷新のきっかけとして、保守期限が近い、技術者が退職する、保守費用が高いといった理由が挙げられます。もちろん、それらは重要な問題です。しかし、それだけでは十分な刷新理由にはなりません。

なぜなら、それはあくまで「刷新のきっかけ」であって、「刷新の目的」ではないからです。

本当に確認すべきは事業との整合性

例えば同じ製造業でも、国内中心で事業を継続する企業、M&Aを積極的に行う企業、海外展開を進める企業では必要なシステムは大きく異なります。また、データ活用を重視するのか、業務標準化を重視するのか、スピードを重視するのかによっても選択肢は変わります。

つまり、システム刷新の前に整理すべきなのはシステム要件ではなく、「経営として何を実現したいのか」なのです。


なぜ基幹システム刷新は失敗するのか

基幹システム刷新は、企業にとって数千万円から数億円規模の投資になることも珍しくありません。しかしそれだけの投資を行っても、想定より大幅に予算が膨らむ、稼働が遅延する、現場が使わない、効果が見えないといった問題が発生するケースは少なくありません。

私たちは、その原因の多くは技術的な問題ではなく、プロジェクト初期の判断にあると考えています。

システムの置き換えが目的になってしまう

最も多い失敗パターンがこれです。「SAP ECCが終了するからS/4HANAへ移行する」「AS/400が古いから新しいシステムへ入れ替える」という発想です。もちろん、それ自体は間違いではありません。しかし、それだけでは十分ではありません。

「何のために刷新するのか」が抜け落ちているからです。システムはあくまで手段。事業成長なのか、業務効率化なのか、データ活用なのか——まず目的があり、その実現手段としてシステムが存在します。目的が曖昧なまま進めると、「システムは変わったが何も変わらない」という状態になりがちです。

現行業務をそのまま再現しようとする

刷新プロジェクトでよく聞く言葉があります。「今の業務をそのまま再現してください」——一見すると合理的に見えます。しかし実際には、これが最も高価な刷新になることも少なくありません。

なぜなら、現在の業務プロセスは長年の運用の中で積み上がった結果だからです。そこには、過去の制度への対応、既に存在しない業務への対応、特定担当者の運用ルールなどが混在しています。つまり、現状業務は必ずしも最適化された状態ではないのです。

刷新の機会とは本来、「何を残し、何を変えるのか」を見直す機会でもあります。現行業務を無条件に再現することは、過去の課題までそのまま引き継ぐことになりかねません。

「Fit to Standard」と現場の壁

近年のERPやクラウドシステムは、「Fit to Standard(業務をシステムに合わせる)」を前提に設計されています。カスタマイズを最小化し、標準機能の範囲で業務を再設計することで、導入コストの抑制や保守性の向上を図る考え方です。

しかし現実はそう簡単ではありません。特にAS/400環境で長年運用されてきた企業では、業務プロセスが独自の進化を遂げており、「うちの業務はシステムに合わせられない」という声が現場から必ず上がります。

ここで重要なのは、現場の声を「抵抗」として封じ込めるのではなく、「なぜその業務が存在するのか」を丁寧に掘り下げることです。

長年の慣行の中には、顧客対応の差別化や品質管理上の合理的な理由から生まれたルールも混在しています。構想策定の段階で、現場リーダーを巻き込みながら業務の「なぜ」を整理することが、チェンジマネジメントの出発点になります。具体的には、

  • 競争優位の源泉となる業務は残す(カスタマイズを許容する)
  • 慣習や属人性による業務は標準に合わせる(Fit to Standardを適用する)
  • 判断の場に現場リーダーを参画させることで、「決めさせられた」ではなく「自分たちで決めた」という当事者意識を生む

この仕分けをいかに丁寧に行えるかが、現場の納得感と稼働後の定着率を大きく左右します。

ベンダに答えを求めてしまう

発注企業が陥りやすい罠があります。それは「ベンダが正解を持っている」と思い込むことです。確かにベンダは技術の専門家です。しかし、どの業務を変えるのか、何を優先するのか、どこまで投資するのかといった判断は、発注企業自身にしかできません。

A社は標準化を重視する、B社は柔軟性を重視する——同じ業種でも答えは変わります。システム刷新においてベンダが提示できるのは選択肢であり、経営判断そのものではないのです。

提案書を比較できない

RFPを発行し、複数社から提案を受けた。しかし提案内容が違う、前提条件が違う、スコープが違う、金額が大きく異なる——結果として「どの提案が良いのか分からない」という状態になることがあります。

実はこれは提案書の問題ではありません。比較可能な条件が整理されていないことが原因です。私たちはこれを「比較可能性の不足」と呼んでいます。ベンダ選定とは、提案を集めることではありません。比較可能な状態を作ることです。そのためにも、RFPの前段階で構想を整理することが重要になります。

誰も最終判断をしない

もう一つの典型例が「みんなで決めよう」としてしまうことです。もちろん、多くの関係者の意見を聞くことは重要です。しかし最終的には、何を優先するのか、どこまで投資するのか、どの案を採用するのかを決める必要があります。

そして、その責任は経営にあります。システム刷新はIT部門だけのテーマではありません。経営判断そのものなのです。


基幹システム刷新の本質は「経営判断」である

ここまで見てきた失敗要因には共通点があります。それは、技術の問題ではないということです。SAPか、AS/400か、クラウドか、オンプレミスか——そうした議論の前に、まず考えるべきことがあります。

システム刷新とは企業の将来像を決めること

基幹システムは企業活動の中心です。そのため刷新プロジェクトでは、単にシステムを作るのではなく、企業として何を目指すのかを決める必要があります。多拠点展開を進めるのか、M&Aを前提にするのか、グローバル対応を行うのか、データ活用を強化するのか——によって最適なシステムは変わります。つまり、システムの前に将来像があるのです。

正解を探すのではなく、判断できる状態を作る

私たちはシステム構想策定支援の中で、「正解を見つける」ことよりも、「判断できる状態を作る」ことを重視しています。なぜなら、企業ごとに状況も戦略も異なるからです。

重要なのは、選択肢を整理すること、メリットとデメリットを整理すること、投資対効果を整理することです。そして、経営として納得できる判断を行うこと。これこそが構想策定の役割だと考えています。

投資対効果(ROI)の評価という難題

経営者が基幹システム刷新で最も頭を悩ませるのが、「この投資の元は本当に取れるのか」という問いです。数千万円から数億円規模の投資に対して、明確なROIを算出することは容易ではありません。

その難しさの本質は、基幹システム刷新の効果が「守りのIT」「攻めのIT」の両面にまたがることにあります。

  • 守りのIT(維持・リスク回避):サポート切れによる障害リスクの回避、属人化した保守体制の解消、セキュリティリスクの低減。これらは「何も起きなかったこと」の価値であり、数字で示しにくい。
  • 攻めのIT(成長・データ活用):新サービス立ち上げのスピード向上、データ活用による意思決定の高度化、グループ横断での業務標準化による生産性向上。こちらは投資後の事業成果に依存するため、事前の確証が難しい。

構想策定の段階でこの両面を整理し、「刷新しなかった場合のリスクコスト」と「刷新した場合の事業機会」を並べて経営層に示すことが、意思決定の質を高める上で重要です。

完璧なROI計算を求めるより、「守りの最低ライン」と「攻めの期待値」を分けて議論できる状態を作ることが、基幹システム刷新における現実的な投資判断の進め方です。


基幹システム刷新の進め方

ここまで見てきたように、基幹システム刷新の成否は、製品選定や開発手法ではなく、その前段階の判断に大きく左右されます。私たちが支援するプロジェクトでも、概ね次のような流れで進めています。

STEP1 現状を整理する

最初に行うべきことは現状把握です。ここでいう現状とはシステム構成図だけを指すものではありません。確認すべき対象は大きく4つあります。

業務

  • どのような業務プロセスで運営されているのか
  • 属人化している業務はないか
  • 拠点や部門ごとの差異は何か

システム

  • 基幹システム以外に何が存在するのか
  • どのシステムと連携しているのか
  • ブラックボックス化している箇所はないか

データ

  • どこにデータが存在するのか
  • 二重管理は発生していないか
  • マスタは統一されているか

組織

  • 誰が意思決定するのか
  • 誰が運用しているのか
  • 将来的な体制はどうなるのか

特にAS/400や長年運用されたスクラッチシステムでは「システムは分かるが業務が分からない」あるいは「業務は分かるがシステムが分からない」という状態も珍しくありません。まずは現状を見える化することが出発点です。

STEP2 課題を整理する

次に「なぜ刷新するのか」を整理します。ここで重要なのは、システム課題と経営課題を分けて考えることです。

システム課題(保守要員不足、サポート終了、改修費高騰)だけを見ていると、「古いシステムを新しいシステムに置き換えるだけ」になってしまいます。本来、システム刷新は経営課題(業務標準化、データ活用、M&A対応、海外展開)を解決するための手段です。

STEP3 将来像を描く

ここが構想策定の中心です。私たちはこの工程を「設計図を描く工程」と考えています。街づくりでも道路も決まっていない状態で建物は建てません。同じように、将来像が決まっていない状態でシステムを選定しても成功は難しいのです。

検討するテーマは多岐にわたります。

業務

  • どこを標準化するか
  • どこを差別化要素として残すか

組織

  • 権限や責任をどう整理するか

データ

  • 何を経営指標として活用するか

システム

  • ERP中心か、ベストオブブリードか
  • クラウド中心か、オンプレミスか

この段階で重要なのは「どの製品を導入するか」ではなく、「どんな会社を目指すか」です。

STEP4 実現シナリオを比較する

将来像が整理できたら、実現方法を比較します。例えばSAP利用企業であれば、以下のような選択肢があります。AS/400の場合も同様に複数のシナリオを並べて検討します。

  • SAP継続:ECCからS/4HANAへ移行
  • ERP入替:別ERPへ移行
  • ハイブリッド構成:基幹部分のみ維持し、周辺システムをクラウド化
  • スクラッチ再構築:業務特性に合わせてゼロから再設計

重要なのは、最初から答えを決めないことです。比較検討を行い、それぞれのメリット・デメリット・投資対効果を整理することが重要になります。

STEP5 RFPを作成する

ここで初めてRFPの出番になります。多くの企業が誤解していますが、RFPはプロジェクトの出発点ではありません。むしろ構想策定の成果物です。将来像が整理され、比較すべき条件が明確になって初めて、ベンダへ提案依頼を行うことができます。構想が曖昧な状態で作られたRFPは、曖昧な提案しか集まりません。

STEP6 ベンダ選定を行う

ここで重要になるのが比較可能性です。評価すべきポイントは価格だけではありません。提案内容、実現性、体制、保守性、将来性などを総合的に判断する必要があります。ベンダ選定とは「一番安い会社を選ぶこと」ではなく、「自社にとって最も納得できる選択を行うこと」なのです。


SAP刷新・AS/400リプレイスで本当に考えるべきこと

ここまで読むと、SAPやAS/400の話が意外に少ないと感じるかもしれません。しかしそれには理由があります。私たちが支援する中で感じるのは、プロジェクトの成否を分ける要因は技術ではないことが多いからです。

SAPを続けることが正解とは限らない

SAPは優れたERPです。しかし、自社の規模、業務特性、投資対効果によっては最適解ではない場合もあります。SAPだから正しいのではありません。自社に合っているかが重要です。

AS/400を捨てることが正解とも限らない

同様に、AS/400だから駄目というわけでもありません。実際には、基幹部分は維持しつつ周辺システムを刷新するという選択が合理的なケースもあります。重要なのは流行ではなく合理性です。

製品ではなくアーキテクチャで考える

成功する企業は、製品選定から始めません。まず「どの機能をどこに置くか」「データをどう流すか」「将来どう拡張するか」を考えます。つまり、製品よりもアーキテクチャを重視しています。これは家づくりで言えば、家具を選ぶ前に設計図を描くのと同じです。


基幹システム刷新の成功企業に共通すること

多くのプロジェクトを見てきた中で、成功企業には共通点があります。

  • 最初にシステムを選ばない。まず将来像を考え、その後でシステムを考える。順番を間違えません。
  • 判断基準を整理している。コスト、スピード、標準化、柔軟性——すべてを同時に最大化できないことを理解し、何を重視するかが明確です。
  • 比較可能な状態を作っている。複数案を並べて比較し、納得して意思決定しています。
  • 発注側が主体的に判断している。ベンダ任せではなく、発注側自身が判断しています。だからこそプロジェクトがぶれません。

構想策定こそがプロジェクトの成否を決める

SAP ECC終了、AS/400技術者不足、レガシーシステムの老朽化——これらは確かに基幹システム刷新を考えるきっかけになります。しかし本当に重要なのは「何を導入するか」ではありません。「これからどんな会社を目指すのか」です。

基幹システム刷新とは、システムを作り直すプロジェクトではなく、企業の将来像を描くプロジェクトです。

だからこそ最初に必要なのは製品比較ではありません。SAPか、ERPか、スクラッチか——その前に、なぜ刷新するのか、何を実現したいのか、どの選択肢があるのか、何を基準に判断するのかを整理する構想策定が必要なのです。

設計図のない街が作れないように、構想のない基幹システム刷新も成功しません。システム刷新の第一歩は、製品選定ではなく構想策定から始まるのです。


基幹システム刷新で、こんなお悩みはありませんか?

  • SAP ECC終了への対応方針が決まらない
  • AS/400を刷新すべきか維持すべきか判断できない
  • ERP選定の前に何を整理すればよいか分からない
  • ベンダから様々な提案を受けているが比較できない
  • 経営層・業務部門・情報システム部門の意見がまとまらない
  • 基幹システム刷新を進めたいが、何から着手すべきか見えていない

基幹システム刷新では、多くの企業が製品選定やベンダ選定の段階で悩みます。しかし実際には、その前段階である「構想策定」が十分に整理されていないことが少なくありません。

私たちは特定の製品やベンダの立場ではなく、発注者側の立場から、現状分析・課題整理・将来像設計・実現シナリオ比較・RFP作成・ベンダ選定までを一貫して支援しています。

「何を導入するか」ではなく、「なぜ刷新するのか」「何を実現したいのか」から整理したい。そのような企業様はぜひご相談ください。

システム構想策定支援

基幹システム刷新の第一歩は、製品選定ではなく構想策定です。現状の業務・システム・データを整理し、将来像と実現シナリオを明確化します。「SAPを継続すべきか」「ERPを入れ替えるべきか」といった個別論ではなく、企業としてどのような基盤を目指すべきかを整理します。

システム構想策定支援を見る

基幹システム再構築支援

構想策定後の再構築プロジェクトについても支援しています。要件整理、プロジェクト推進、ベンダコントロールなど、発注者側の立場でプロジェクトを伴走支援します。数千万円から数億円規模の投資だからこそ、第三者視点での判断支援が重要です。

基幹システム再構築支援を見る

RFP作成・ベンダ選定支援

基幹システム刷新の成否は、ベンダ選定の前にほぼ決まっています。私たちは「比較可能性」を重視したRFP作成を支援し、複数ベンダの提案を適切に比較・評価できる状態を構築します。

RFP作成・ベンダ選定支援を見る

基幹システムに正解はありません

SAP、AS/400、ERP、クラウド——選択肢は数多く存在しますが、企業ごとに置かれた状況も目指す姿も異なります。だからこそ重要なのは、正解を探すことではなく、自社として納得できる判断を行うことです。私たちは、その判断のための整理と意思決定を支援しています。

基幹システム刷新を検討されている方は、お気軽にご相談ください。

無料相談はこちら

この記事を書いた人について

谷尾 薫
谷尾 薫
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア(全省庁統一資格Aランク)代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。

関連記事

AI自動応答
資料ダウンロード