基幹システム刷新は「基本構想」で決まる！

◆この記事の要約

本記事では、製造業の基幹システム刷新（ERP導入）を「基本構想フェーズ」で成功させるための考え方を整理します。Fit to Standard（FTS）を軸に、To-Be像とPKG調査を同時に進め、RFP・投資効果・ロードマップまでつなげる実務ポイントを解説します。

基幹システム刷新を「売上向上／コスト削減」に翻訳し、KPIでぶれない目的をつくる。
プロジェクトフェージングを「スパイラルFTS＆ウォーターフォールアドオン実装」のハイブリッドで設計し、早期からPKG標準に業務を合わせることで手戻りを抑える。
基本構想のKSF（成功要因）とChallenge（難所）を押さえ、将来像・変革定義と PKG選定、アーキテクチャー設計で実行力を担保する。

製造業の基幹システム刷新は、保守期限への対応だけでなく、近い将来の競争力を左右する経営テーマになっています。一方で、部門最適の要望が積み上がり、アドオンの肥大化や移行難航、稼働後の定着不全に陥る例も少なくありません。差がつくのは「基本構想フェーズ」で、刷新目的を経営成果に翻訳し、Fit to Standard（FTS）でどこまで標準化するか、どのデータを統合し、何を段階的に実現するかを合意できるかです。そこで本記事では、基本構想を軸に、導入の勘所と進め方、得られる効果を具体的に整理します。

刷新目的を「経営成果」に結び直す

基幹刷新の出発点は、システム更改ではなく「事業基盤の強化」や「成長に向けた体質改善」です。
保守期限や老朽化はきっかけに過ぎず、意思決定者が本当に問うべきは、刷新が売上向上とコスト削減にどう効くか、という一点です。ここが曖昧だと、要件定義で“現行踏襲”が優勢になり、結果として標準化が進まず、効果が出にくい投資になります。

基本構想では、バリューチェーンの全般に渡り、需要管理・生産手配・原価・技術管理といったテーマを「成果の因果」で束ね、優先順位をつけます。例えば、需要情報の一元管理で予測精度を上げる。管理・間接工数を削減して、営業活動や原低活動へ余力を振り向ける。こうした“余力の再配分”まで描けると、刷新がコストではなく成長投資になります。

KSF（成功要因）

「基盤事業の強化」を、売上向上／コスト削減のKPIに分解して改革テーマへ落とす
効率化で生まれる余力を、営業・原価低減など次の活動へつなげる前提で設計する

Challenge（難所）

部門ごとのローカルルールを全社最適へ寄せる合意形成
効果が“固定費化”しやすく、投資効果の説明が弱くなりがち

【図1】基盤事業の強化に資する基幹システム像

フェージングは「FTS重視×確実な実装」で組み立てる

基幹刷新は、プロジェクト設計（フェージング）で難易度が決まります。
FTSは、標準機能に業務を合わせるため、検討・合意に時間がかかります。しかしここを急ぐと、例外処理が増え、アドオンが雪だるま式に増えます。

現実的な解は、標準部（PKG標準）は早期からフィッティングとシナリオ検証に着手し、十分な時間をかけ、アドオン開発は段階的なウォーターフォールで確実に進めることです。加えて、意思決定の“関門”を先に定義します。To-Be像合意、パッケージ／ベンダー選定、投資決定、開発対象、移行判定——この順序が揃うと、判断の軸がぶれず、手戻りが減ります。

KSF（成功要因

FTSの判断基準（競争優位／法規制／監査対応など）を、基本構想で合意しておく
ゲート（投資決定、開発対象決定、移行判定）で品質・スコープをコントロールする

Challenge（難所）

標準化の“痛み”が現場に集中し、変更管理（教育・マニュアル・権限設計）が不足しやすい
検証対象とするビジネスケースをいかに選択するか、網羅性を上げると時間と費用が嵩み、下げると終盤でのアドオン追加など手戻り要因となりやすい

【図2】プロジェクトフェージング全体像

基本構想は「To-Be × PKG調査」を同時に回す

基本構想フェーズの本質は、将来To-Beを描くだけではありません。
To-Be像とPKG（ERP等）の機能を照らし合わせ、「実現手段と実現レベル」を合意することです。ここで作り込み過ぎると、PKG選定後に前提が変わり手戻りします。逆に粗すぎると、RFPが弱くなり、ベンダー比較や投資効果算定ができません。

ポイントは、現状調査を“全部”やらないことです。FTSが前提であれば、現状把握はPKG選定と「基盤事業の強化」に直結する領域へ絞り込みます。同時に、マスタ・コード体系の統一方針を早期に議題化します。データ統合と移行難易度を左右するのは、機能よりもマスタの整合性であることが多いからです。

KSF（成功要因）

経営ニーズ→課題→FTS GAP→To-Be→解決方針の因果を一本につなぐ
RFI／PKG調査を並走し、比較軸（機能・非機能・保守体制）を早期に揃える

Challenge（難所）

断捨離（業務・帳票・個別システム）に踏み込めず、結局“現行の再現”に戻りやすい
マスタ統一は影響範囲が広く、後回しにすると移行局面で破綻しやすい

【図3】基本構想の進め方（要点）

短期推進のカギは「調査の型」と「会議設計」

基本構想を短期間で進める時、ボトルネックになりやすいのは“情報収集の散らばり”と“討議の渋滞”です。現状システム（ERP／HOST／周辺）の機能配置、マスタ構造、IF連携、データ量、ユーザー数——これらは後工程の移行・性能・権限に直結しますが、担当が分かれ抜け漏れが起きやすい領域です。

そこで有効なのが、作業のメリハリ化とナレッジ活用です。作業ボリュームの大きくなりがちな現状調査は、アンケート方式での現状調査が有効です。ユーザー部門に割り振ることで並列作業が可能になり、時間効率を有効に扱えます。また、To-Be像の検討や改革テーマの策定は、利害関係者の意見を統一し進むべき方向を定める必要があります。類似企業の事例やベストプラクティスを活用することで、実現イメージの共通認識を図り、To-Be像への腹落ち感を醸成しながら進めることが、難しい意思決定を前に進める武器となります。

KSF（成功要因）

現状調査をテンプレート化し、PKG調査と連動して並行して推進
変革方針を「刷新と同時にやるテーマ／中期テーマ」に仕分けし、スコープ膨張を抑える

Challenge（難所）

現状調査が広がり過ぎ、構想が終わらない（スコープ管理が難しい）
To-Be像、改革テーマで議論が発散、利害関係対立が発生（効果が出ない）

【図4】基本構想　効率推進のポイント

成果を出すには「代理人型PMO」と段階導入が効く

基幹刷新の要件定義フェーズ以降は、設計が正しくても「進め方」を誤ると失速します。
特に、ベンダー提案が主導になると、自社にとっての投資効果や実現可能性よりも、製品都合の判断が混ざりやすくなります。そこで重要になるのが、顧客側の意思決定を支える代理人型PMOです。戦略・ITテクノロジー・ガバナンスのバランスを取りながら、外部専門家とも協調し、要件定義、開発～テスト・移行まで一貫して“判断の質”を上げます。また、効果は段階的に出す設計が現実的です。
導入ステップは次のとおりです。

基本構想：目的／KPI、FTS方針、PKG調査、To-Be策定、投資効果算定
要件定義：シナリオ検証、アドオン要否の取捨選択、データ移行方針の具体化
開発：開発管理、システム全体での整合確認など、関係者間の連携を支援
テスト：結合・総合テスト、UATで業務定着の品質をつくる
移行・切替～安定化：移行トライアル、教育、ヘルプデスク立ち上げ、運用テスト

事例
国内に複数拠点を持つ部品製造業では、基本構想で「需要情報の一元管理」「見積・納期回答の半自動化」「原価の見える化」を優先し、FTSを原則としてアドオンを抑制。
稼働後6か月で、見積～納期回答LTは約30%短縮、間接工数は約20%削減、原価差異分析は月次で数日短縮といった効果の刈り取りを実現しました。

KSF（成功要因）

ベンダー任せにせず、評価軸と意思決定プロセス（ゲート）をPMOが握る
データ移行・教育・定着（運用・ヘルプデスク）まで“プロジェクトの範囲”として設計する

Challenge（難所）

ステークホルダーが多く、合意形成と変更管理が最も難しい
「何を標準で実現し、何を捨てるか」の判断が遅れると、工期とコストが膨らむ

【図5】システム構築・導入アプローチ

まとめ

基幹システム刷新は、基本構想から移行・定着まで「判断」と「合意」を積み重ねる取り組みであり、社内だけで完結させるには負荷が大きいのが実情です。レイヤーズ・コンサルティングでは、基本構想の進め方やRFP設計、FTS判断基準の整理から、第三者として最後までしっかり伴走させていただきます。
課題感をお持ちでしたら、ぜひお気軽にお問い合わせください。