情報システム
業務改革

ＥＲＰ導入における上流工程の要諦

No.676 | 2026年8月号

今月の視点

　基幹システムの刷新に取り組む際、ＥＲＰパッケージソフト（以下、ＥＲＰと記載）の導入を前提とするケースが一般化している。しかし、導入実績や機能の豊富さのみに集中してＥＲＰ・ベンダー選定を進めてしまい、導入工程での多額の追加開発や、稼働後の業務運用の混乱に直面する事例も少なくない。

　こうした問題の背景には、「どのＥＲＰを選ぶか」という選定そのものに過度に意識が向けられ、本来出発点とすべき「どのような業務を実現したいのか」という検討が必ずしも十分に行われていないことがある。ＥＲＰはあくまで手段であり、自社の業務のあり方が曖昧なままでは、その適合度を判断できないだけではなく、システムの適用方針や導入後の業務を適切に描くことが難しい。

　今月は、上流工程における検討の質を高めることでＥＲＰ導入を成功に導いたＡ社の事例を通じて、上流工程の進め方とそのポイントについて考えてみたい。

1　上流工程の基本手順

ＥＲＰ導入における上流工程は、ベンダー選定以降の導入工程の基盤となるプロセスであり、これを適切に進められたかどうかがＥＲＰ導入の成否を左右する。

まず「①プロジェクト計画の立案」では、システム刷新の背景・目的を整理する。経営からの要請、事業推進上の必要性、業務改革の可能性といった複数の観点から目的を明確にすることで、プロジェクトの方向性を定める。この段階で、現状の課題認識に基づく方針仮説を組み立て、推進手順・スケジュール・体制を具体化しておくことが大切である。

「②前提条件確認」では、新しい業務・システムを設計する上での前提となる事項を洗い出しておく。事業区分、取引形態・条件、管理会計や計数管理の体系などは、システムの構造や機能要件に直接影響を及ぼすため、曖昧なまま進めると後工程での手戻りの原因となる。

「③現行業務・システムの詳細分析」では、業務処理パターンや手順、会計処理基準、システムの利用状況、業務負荷やスケジュールなどを業務セグメント単位で整理し、現行業務・システム運用を詳らかにする。この際、現行業務の抱える問題点や、あるべき業務とのギャップを意識して分析することで、後続の検討における論点が浮き彫りになる。

「④ＥＲＰ機能解析」では、ベンダーからの情報提供をもとに、機能概要を確認し、各ＥＲＰの特性や自社業務に対する適合度を検証する。この検証結果は、自社に適した候補ＥＲＰの絞り込みに使用するとともに、次ステップの論点審議においてもＥＲＰ標準機能が前提とする業務運用の実現可能性を検討するために活用する。

「⑤論点審議」では、現行業務・システムの詳細分析、ＥＲＰ機能解析の結果を踏まえて設定した「あるべき業務を実現するための論点」について、関係者を巻き込んで集中的に審議し、方針を定める。

最後に、「⑥マスタープラン策定」において、論点審議を通じて決定した方針を踏まえて、システム導入に向けた基本要件に落とし込む。業務フローやシステム要求仕様を体系的に整理した基本要件書を作成するとともに、導入までのマスタースケジュールを策定する。

こうして策定したマスタープランをもとに、ベンダーに対して適切な提案を求めるための提案依頼書を作成し、ＥＲＰ・ベンダーを選定する工程へとつなげていく。

2　Ａ社の事例

（１）システム刷新の背景

Ａ社は、全国に営業・製造拠点を持つ産業資材メーカーである。設計開発から製造、販売、施工支援、保守サービスまでを一貫して手掛ける体制を強みに、公共・民間双方の需要を取り込みながら、安定的に事業規模を拡大してきた。

近年は、海外市場への展開やＭ＆Ａを通じて事業領域を広げており、グループ全体での事業運営の高度化が重要な経営課題となっていた。

しかし、こうした事業構造の変化に対して、業務を支える基幹システムは十分に対応できていなかった。現行システムは約20年前に独自開発したものであり、その後、部門ごとの要望に応じて機能追加を繰り返してきた結果、システム全体の構造が複雑になり、操作性の低下などの問題が顕在化していた。

また、拠点ごとに業務運用が異なることから、同一の取引であっても処理方法やデータの持ち方にばらつきがあり、全社横断での情報の把握が困難となっていた。必要な経営情報はシステム外で個別に集計・加工することで対応しており、情報の精度やタイミングにも課題があった。現場ではシステムで対応しきれない業務を補うための手作業や二重入力も常態化しており、業務負荷の増大を招くと同時に、ミスの温床にもなっていた。

この状況を踏まえ、社長は基幹システムの刷新を決めた。

「事業の拡大に伴い、業務とシステムの乖離は大きくなった。このままでは拠点ごとの最適にとどまり、グループとしての力を発揮することができない。業務のあり方を見直し、全体として統制の取れた運営ができる仕組みに変えていく必要がある。

そのためにも、従来のように個別に作り込んできたシステムを改修し続けるのではなく、世の中で広く使われているＥＲＰの活用を念頭に置き、標準的な業務プロセスに対応していくべきである。法令対応や機能改善についても世間標準を継続的に取り込める仕組みにすることで、将来にわたって安定的に運用できる基盤を整えたい。」

この方針のもと、Ａ社は情報システム部門の中にＥＲＰ導入を念頭に置いた基幹システム刷新プロジェクトチームを組成し、以降の検討を進めていくことになった。

（２）当初の検討と行き詰まり

プロジェクトチームは、まず有力なＥＲＰの導入実績を持つ複数のベンダーに対して情報提供を依頼し、各社からの説明を受けることとした。提示された内容はいずれも魅力的であり、豊富な機能や導入実績、最新技術への対応などが強調されていた。これを受けて、候補となるＥＲＰおよび導入ベンダーを絞り込み、その中でも特に導入実績・コスト面で優位な提案をしてきたＸ社を選定し、導入に向けた検討を開始した。

検討は、現行システムの機能一覧をもとに、それぞれの機能がＥＲＰでどのように実現できるかを、Ｘ社からＡ社に対して確認していく形で進められた。業務部門に対しても、Ｘ社を中心に、現行業務における不便な点や改善したい点の聞き取りが行われ、それらが新システムへの要望として整理されていった。

当初、Ａ社内においてこの進め方に大きな違和感を持つ者はいなかったが、検討を進めるにつれて問題が生じてきた。現行システムを起点とする進め方を取ったことで、現行の業務運用が前提となり、業務のあり方そのものを問い直す議論がほとんど行われなくなったのである。

業務部門からは、「この入力画面は使いづらい」、「この処理は手間がかかる」、「この帳票はもっと見やすくしたい」といった要望が数多く挙げられた。いずれも日々の業務を担う担当者にとって切実な問題ではあったが、その多くは現行システムの使い勝手や個別の不満に起因するものであり、業務全体のあり方を見直すという観点で整理されたものではなかった。しかし、こういった要望を取捨選択するための基準もなかったため、提示された内容は基本的にすべてＸ社に対する要件として織り込まれていくことになった。

こうして現場からの要望が積み上がった結果として要件は肥大化し、Ａ社は想定以上に多くの機能が追加開発対象となるという現実を突きつけられることになった。最終的に提示された導入費用の見積は、当初想定していた投資水準を大きく上回るものであった。ＥＲＰを導入することで業務やシステムをシンプルにするはずが、現行業務にＥＲＰを合わせるような進め方をしたため、業務もシステムもかえって複雑化するような設計方針になってしまっていた。

（３）プロジェクトの再始動からプロジェクト計画の立案（①）

（括弧内の丸囲み数字は冒頭に図示した「取組事項」の番号に対応）

検討の行き詰まりを受けて、Ａ社はプロジェクトの進め方を根本的に見直すことを決断した。提示された見積金額は投資として到底受け入れられる水準ではなく、このままでは業務のあり方の抜本的な見直しも果たすことができないと判断したためである。

社長は、これまでの検討をいったん白紙に戻し、プロジェクトチームを再編成した上で、検討をやり直すよう指示した。

再編成にあたっては、情報システム部門だけではなく、営業部門、管理部門、工場といった主要部門から責任者クラスのメンバーを選出し、全社横断的な体制を組むことにした。また、これまでの工程がベンダー任せになってしまった反省を踏まえ、ユーザー側の立場で上流工程を支援できるコンサルタントを新たに参画させることとした。

再編成されたプロジェクトチームは、システム刷新の目的を改めて捉え直すところから着手した。これまでの検討では、ＥＲＰ導入自体が目的化し、本来実現すべき業務のあり方についての議論が十分に行われていなかった。そこで、経営層も交えて議論を行い、事業拡大に対応した業務の標準化、グループ全体での情報の一元化、経営判断に資する計数管理の高度化といった目的を改めて設定した上で、プロジェクト計画に落とし込んでいった。

（４）前提条件確認と現行業務・システムの詳細分析（②③）

次にプロジェクトチームは計数管理体系等の前提条件を詳細に確認した上で、現行業務・システムの詳細分析に取りかかった。分析にあたっては、各拠点を訪問し、業務処理の流れや手順、システムの利用状況について、実務担当者レベルまで踏み込んだインタビュー調査を実施した。単に業務フローを確認するのではなく、どのような意図や背景のもとでその処理が行われているのかに着目しながら、実態の把握を進めていった。

インタビュー調査を通じて、これまで個別に認識されていた問題が、より具体的な形で浮かび上がってきた。拠点ごとに処理方法が異なることによるデータの不整合、システムで対応しきれない業務を補うためのExcelや紙の併用、業務処理のタイミングや基準のばらつきによる後工程での修正作業など、日常業務の中で非効率が発生している実態が明らかになった。

さらに分析を進めていくと、これらの問題は現行システムの改修経緯に起因していることがわかってきた。Ａ社の基幹システムは、各部門や拠点からの要望に応じて個別に機能追加や改修を繰り返してきた結果、全社としての統一的な設計思想に基づくものではなく、部門ごとの業務運用に合わせる個別最適の発想でシステムが作り込まれていた。そのため、業務の違いがシステムに反映され、そのシステムが業務の違いを固定化するという悪循環に陥っており、全社横断での情報活用にも支障が生じていた。

このような状況は、個別の業務改善や機能追加によって解決できるものではなく、全体最適の観点から業務とシステムの構造そのものを再設計する必要があるとの認識に至った。

（５）ＥＲＰ機能解析（④）

プロジェクトチームは、現行業務・システムの詳細分析と並行して、有力な候補ＥＲＰベンダーに対する情報提供依頼を実施し、主要な機能や処理の考え方について確認を進めた。対象としたのは、受注管理、生産計画・実績管理、出荷管理、売上・請求管理、入金管理、原価管理といったＡ社の中核的な業務領域である。

実際の画面を見ながら使い方を詳細に確認して主要機能や処理を理解するとともに、機能の有無だけではなく、「なぜそのような処理手順になっているのか」、「その前提となる業務の考え方は何か」といった観点で読み解くことで、ＥＲＰが前提としている業務モデルの把握も併せて進めた。プロジェクトメンバーは、この過程を通じて、導入実績が豊富なＥＲＰであっても、すべての業務に対して最適な解を提供するものではないことを改めて認識した。

例えば、Ａ社では製品別・案件別の採算管理を細かな粒度で行っていたが、ＥＲＰによってはそこまでの詳細な管理を前提としていないものもあり、ＥＲＰの前提に安易に合わせれば、自社が重視してきた管理水準を維持できなくなる懸念があった。こうした業務モデルが異なるシステムは自社業務への適合度が低く、導入のために業務全体の過度な見直しを要する、または業務品質を損なうことが懸念されたため、候補から除外し、対象を絞り込んでいった。

一方で、すべてを自社のやり方に合わせようとすれば、ＥＲＰ導入を契機とする業務の標準化・効率化を果たせなくなることに加えて、カスタマイズの増大を招き、保守性の向上やコスト抑制といった目的も達成できなくなる。プロジェクトチームは、ＥＲＰの機能や処理の自社業務との相違を、単なる制約条件として受け入れるのではなく、自社の業務設計を見直すための材料として活用していくこととした。

（６）論点審議（⑤）

プロジェクトチームは、これまで分析してきた現行業務の実態と、ＥＲＰの仕様の双方を踏まえ、あるべき業務を設計するための論点を次のように整理した上で、現行業務に精通した各部門の関係者を巻き込み、集中審議を実施した。

❶ 現状の業務の見直しを検討すべき論点

この論点としては、例えば「現場での受入・検収の記録と事務担当者による仕入入力に分散していた作業を、受入時点での入力へ一本化できないか」が挙げられる。このような業務の簡素化や標準化に係る論点については、ＥＲＰの標準機能でどのような処理が想定されているかを確認した上、その考え方を取り入れることで改善が可能かどうかを中心に検討した。

❷ 新たにシステム化を検討すべき論点

この論点は、「紙やメールで行っている見積承認、購買承認、製造依頼承認、出荷承認等のワークフロープロセスの電子化」などだが、標準機能での対応可否や代替手段の有無を見極めた上で、カスタマイズの必要性とその影響を含めて判断を行っていった。

❸ 業務の質や管理水準の低下につながるため変えてはいけないと想定される論点

これは、「製品別・案件別の原価把握や収益分析において重要となる計上情報の粒度」をはじめとする論点だが、ＥＲＰの仕様に合わせて安易に簡略化するのではなく、自社の業務や管理における重要性を前提として、必要に応じて個別対応を行うことも含めて検討した。すべてを標準機能に合わせるのではなく、どこを合わせ、どこを守るのかを明確に切り分けることが、審議の中核となった。

審議当初は現状のやり方を前提とした反対意見も多く見られたが、「何を実現するための業務なのか」という観点に立ち返りながら議論を重ねることで、次第に視点が揃っていった。審議の過程を経て、自社にとっての業務・システムのあるべき姿が運用の実現性を伴う形で具体化されていった。

（７）マスタープラン策定（⑥）

次にプロジェクトチームは、論点審議を通じて定めた業務・システムのあるべき姿を基本要件書として取りまとめることに着手した。

基本要件書の中核は、あるべき業務・システムフローと、それに対応する要求仕様の体系化である。

業務・システムフローについては、受注から出荷、請求に至る一連の業務を対象に、誰が、どのタイミングで、どの情報を用いて、どのような処理を行うのかを細かく展開し、業務とシステムの関係を一体として把握できるようにした。また、要求仕様については、各業務処理に対応する入力項目や処理内容、参照情報、例外対応等を整理し、システム機能に求める要件を詳細に記述した。

この際に重視したのは、「業務の流れ」と「機能要件」を分けて整理しつつ、両者の対応関係を明確にすることであった。業務の流れだけではシステムに対する機能要件が見えにくく、逆に機能要件だけでは業務全体の流れが見えなくなる。業務・システムフローによって業務の全体像と処理の前提を共有し、要求仕様によって機能単位で実現したいことを個別に定義することで、ベンダーが自社ＥＲＰとの適合度や対応方針を具体的かつ同一の前提で提示できる状態を整えた。これにより、ＥＲＰ・ベンダーの選定過程において、提案内容の差異を曖昧な印象ではなく、業務単位・機能単位で比較可能な形にし、より高い精度で評価できるようにすることを狙いとした。

また、基本要件書の作成と合わせて、稼働時期、対象範囲、段階導入要否といった前提条件や制約事項を整理した上で、導入までの推進スケジュールについても具体化し、プロジェクト全体の指針となるマスタープランとして取りまとめていった。

その後、プロジェクトチームは、マスタープランに基づき、提案依頼書（以下、 Request For Proposalの略記でＲＦＰと記載）を作成し、候補ベンダーに対して提案を依頼した。ＲＦＰには、プロジェクトの前提条件やスケジュール、評価方針なども明記し、各社に対して同一条件での提案を求めた。

こうしてＡ社のベンダー選定は、ベンダーから提示された内容を受け身で比較するものではなく、自社が定めた要件を起点として各社の提案を評価する主体的なプロセスへと転換した。

（８）中流工程以降における効果

Ａ社は、基本要件書およびＲＦＰに基づく提案依頼を経て、候補ベンダーからの提案内容を比較・評価する段階に入った。選定にあたっては、業務フロー単位での適合度や、標準機能での対応範囲、カスタマイズの必要性とその影響などを総合的に評価し、最終的に自社の業務・要件に対する適合度が最も高いＹ社を選定した。

ＥＲＰおよびベンダーの決定後、プロジェクトは導入工程へと移行したが、この段階においても上流工程での検討成果は大きな効果を発揮した。業務・システムフローおよび要求仕様が整理されていたことで、ユーザーとベンダーの間で認識の齟齬が生じにくく、システム適用方針や追加開発部分の設計に関する議論は順調に進んでいった。

また、導入を進める中では、業務部門から追加の要望が出される場面もあったが、その都度、基本要件書に立ち返り、当初定めた業務の方針に照らして必要性を判断することが徹底された。その結果、場当たり的な要望の取り込みによる仕様の膨張は抑制され、追加開発の範囲も当初想定の範囲内に収まった。

加えて、上流工程において現行業務に精通した関係者の主体的な参画を得て、あるべき業務の姿を議論してきたことにより、導入工程においても各部門の実務関係者が当事者意識を持ってプロジェクトに関与することとなった。上流工程の検討段階から関与していたメンバーが各拠点における推進役となり、新たな業務運用の定着に向けた働きかけを自律的に行ったことで、現場への展開は円滑に進んだ。押しつけられた業務ではなく、自ら関与して定めた業務であるという認識が、業務変更に対する抵抗を抑え、現場への定着の後押しになった。

このようにしてＡ社は、当初計画したスケジュールおよび投資範囲の中で新システムの安定的な稼働に漕ぎつけた。稼働後は、業務処理の標準化と効率化が進んだことに加え、データの一元化により経営情報の可視化も大きく前進し、所期の目的を果たすことができた。

3　留意点

Ａ社の事例では、ベンダー選定前の上流工程において、現行業務と真摯に向き合い、世の中のＥＲＰの仕様も踏まえて、自社にとってのあるべき業務・システムのあり方を具体化したことが、その後のベンダー選定および導入工程全体の成否を左右した。以下に、事例を踏まえて、上流工程の検討を進める上で留意すべきポイントを整理する。

①業務の背景まで踏み込んで理解する

Ａ社が当初行き詰まった最大の要因は、現行業務を表面的に捉えたまま検討を進めたことであった。結果として、現行機能をどう再現するかが議論の中心となってしまい、現行業務が見直されないまま、追加開発事項が積み上がっていった。これに対し、仕切り直し後は、各拠点を訪問し、実務担当者レベルまで踏み込んだ調査を行うことで、「なぜそのような運用が行われているのか」という背景まで含めて理解できるようになり、現行業務を前提とした表面的な議論から脱却することができた。

このように、ＥＲＰ導入の具体的な議論に入る前に、現行の業務運用を詳細に理解しておくことが肝要である。この理解が不十分であれば、その後にどれほど高度な議論を重ねても、地に足のつかない検討になってしまう。

②全体最適の視点で業務を見直す

Ａ社では、独自開発した基幹システムに対して、各部門や各拠点の要望を個別に反映し続けてきた結果、全社としての統一的な設計思想が失われていた。業務の違いがシステムに反映され、そのシステムが業務の違いを固定化することで、拠点ごとの運用差異やデータのばらつきが拡大していたのである。

こういった状態で個別の業務改善や機能追加を重ねても、問題の根本解決にはならない。ＥＲＰ導入を契機として目指すべきは、業務とシステムを一体として見直し、全社としての標準的な業務のあり方を定義し直すことである。現状の延長線上で考えるのではなく、全体最適の観点から業務を再設計することが全社的な業務改革の実現につながっていく。

③ＥＲＰが前提とする業務モデルを踏まえる

ＥＲＰは世の中の標準的な業務のあり方や処理の考え方をもとに構成されたソフトではあるが、必ずしも自社の業務運用や管理の考え方に合うとは限らない。

Ａ社の仕切り直し後の検討では、各ＥＲＰが前提としている業務の考え方や管理水準を踏まえながら、自社としてＥＲＰに合わせる部分と、維持すべき部分とを整理していった。

こうしたＥＲＰが前提とする業務モデルを踏まえずに要件検討を進めれば、「どこをＥＲＰに合わせ、どこを維持するのか」という判断ができないまま、自社のやり方や現場要望を積み上げることになり、どのＥＲＰを選定しても大規模な追加開発を伴うような要件になりかねない。ＥＲＰの業務モデルを事前に理解しておくことは、適合度評価に基づく候補の絞り込みにとどまらず、現実的な業務設計につながる。

④基本要件を体系化する

Ａ社が仕切り直し後に大きく変わった点の一つは、業務・システムフローと要求仕様を体系的に整理し、基本要件書として取りまとめたことであった。このことにより、ベンダーは、選定過程において自社ＥＲＰとの適合度や対応方針を具体的に示すことができ、Ａ社側でも各社の提案内容を業務単位・機能単位で比較できるようになった。加えて、選定後の導入工程を進めていく中でも、基本要件書に立ち返って対話を進めていくことで、Ａ社とベンダーの認識齟齬が抑制された。

要件を構造化し、業務の流れと機能要件の対応関係を明確にすることで、議論の軸が整い、ユーザーである導入企業が主体的にベンダーを評価できる状態が生まれる。これはベンダー選定のみならず、後続の工程を推進していく中でも判断の軸として機能する。基本要件書は、ユーザー側が主体的にプロジェクトをコントロールしていくための基盤となるものであり、上流工程においてユーザー自身が整えておくことが不可欠である。

⑤多くの関係者を巻き込んで進める

業務改革を伴うＥＲＰ導入は、情報システム部門だけで完結できるものではない。

Ａ社でも、仕切り直し前の検討では情報システム部門主導で検討が進み、業務部門は現行システムへの不満や改善要望を述べるにとどまった結果、現行踏襲から抜け出せず、要件の肥大化を招いた。これに対し、仕切り直し後は、営業部門、管理部門、工場など、現行業務に精通した関係者を巻き込み、集中審議を通じて方向性を定めていったことで、現場の実態を適切に設計に反映していくことができた。

また、上流工程から関係者の主体的な議論への参画を求めることは、単に知見を集めるためだけのものではない。自ら関与して決めた内容であるという認識が共有されることで、その後の工程においても判断に対する納得感が生まれ、追加要望や運用上の調整が必要となった場合にも、冷静な判断がなされやすくなる。さらに、早期から関与したメンバーが各部門における理解者・推進役となることは、業務変更に対する抵抗を抑えながら、導入後の定着を円滑に進めることにも寄与する。上流工程における関係者の巻き込みは、業務改革を現場に根付かせるための重要な条件となる。

今月号では、ＥＲＰ導入の上流工程に焦点を当てたが、バックナンバーにおいて、独自開発を含めた各工程の進め方について整理しているため、以下に記載する。