購買管理システム更改は、現行業務と資産の棚卸しから始め、要件定義、RFPの作成、ベンダー評価の順に進めます。この順で進めると、手戻りや業務停止のリスクを抑えられます。
経済産業省は、レガシーシステムを放置すると大きな経済損失を招く「2025年の崖」を指摘しています。購買・調達領域の更改も、待ったなしの経営課題です。
▼全体ガイドの記事
・購買管理システム更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
購買管理システム更改におけるアセスメント（現状分析・AS-IS可視化）
更改を成功させるには、まずアセスメント（現状分析）として、既存システムがどの業務と連携を支えているかを把握します。
新規構築と違い、更改は日々動いている調達業務を支える資産の置き換えです。そのため、現状分析とAS-IS可視化を出発点に、更改後の姿を設計します。特に、現行処理を漏らすと、以前の発注パターンが通らなくなったり、特定サプライヤへの支払が止まったりする恐れがあります。
現行購買フローとマスタ・連携の棚卸し
アセスメントの中核は現行購買フローの棚卸しです。発注から支払までの実務と、各システムやマスタのつながりを確かめます。
- 購買業務：発注・承認・検収・支払の担当部門、画面、帳票、承認ルート
- マスタ：サプライヤや単価の重複、古い取引先、契約単価と実績単価のずれ
- 外部連携：会計への支払データ、基幹との在庫・原価、サプライヤとのEDI
- 個別改修：標準機能を補うアドオンや、仕様が不明になった個別開発
マスタの不備を残すと、不正確なデータを新システムへ引き継ぎ、稼働後の混乱を招きます。また、外部システムとの連携インターフェース一覧を作り、データの流れる方向を可視化しておくことも欠かせません。連携が抜けると、切替時に業務が止まるおそれがあります。
連携を含む現行構成の依存関係は、更改範囲を見極めるための前提になります。長年積み上がったアドオンや個別改修も、あわせて洗い出します。
標準機能を補う個別開発は、仕様を正確に説明できないブラックボックスになっている場合があります。そのため、アドオンのうち標準機能で吸収する範囲を判断します。なお、JUASの調査では、約7割の企業が基幹システムのレガシー化を課題に挙げています。
インボイス・電子帳簿保存法の対応状況とツール活用
法制度への対応状況は、アセスメントで欠かせない論点です。保存や判定の要件、手作業が残る業務を調べ、更改で扱う課題を絞り込みます。
- インボイス制度：適格請求書の要件判定と登録番号の保持
- 電子帳簿保存法：取引関係書類を要件に沿って電子保存できるか
- 暫定対応：手作業で補っている業務や未対応の範囲
- 資産の依存関係：個別改修を含むプログラム間の構造とリスク箇所
長年改修したシステムは、人手だけでの棚卸しが難しい場合があります。そうしたときは、富士通の「ソフトウェア地図」のような、資産の複雑度や依存関係を可視化するツールが使えます（出典：富士通）。
さらに、機械的な解析を使えば、目視では追い切れない依存構造もデータで把握できます。リスクが集中している箇所を見ながら、更改範囲の優先順位を決められます。
アセスメントから要件定義までを外部に依頼する場合、業務の棚卸しと要件定義だけで200万〜500万円程度が目安になります。本体更改費用の一部に見えても、後工程の見積り精度を左右するため、相応の投資が必要です。
分析を省くと、開発中に仕様やマスタの不整合が判明し、追加要件や手戻りで費用と期間が膨らみます。そのため、RFPを出す前に、この工程を独立して進めます。確かな現状理解を得てから発注することが重要です。
更改後のKPIと機能・非機能・データ移行の要件定義
現行フローを可視化したら、その情報をもとに要件を定義します。更改後の目標、機能と非機能の要件、既存データの移行方法を固めます。要件が曖昧だと、各社が異なる前提で提案するため、横並びで比較できません。
購買業務で必要な要件は、KPIを起点に整理します。
更改後KPIと機能要件（3-way match・承認ワークフロー）
効率化の目標を測るKPIと、それを実現する購買機能は、一緒に定義します。
- 業務KPI：発注リードタイム、請求照合の自動化率、支出の可視化
- 3-way match：発注書・検収・請求書の三者照合
- 承認ワークフロー：部門や金額に応じて経路が変わる承認
- Web-EDI：サプライヤとの注文や納期回答のやり取り
- 請求書処理：インボイス制度に対応した適格請求書の処理
工数を何割減らすか、照合の自動化率を何％にするかといった数値目標を置くと、更改の成否を評価できます。KPIが曖昧なままだと、新システムが動いても期待した効率化を得られない結果になりがちです。
機能ごとに求める粒度を決め、現行業務との対応を整理します。そのうえで、標準機能に合わせて業務を見直せる部分と、譲れない購買ルールを分けておきます。
さらに、アセスメントで洗い出したアドオンの一覧も、検討の材料になります。標準機能で吸収できる処理を見極めると、過剰な作り込みを避けて、更改の難度とコストを抑えられます。
非機能要件とデータ移行要件（未検収POの引き継ぎ）
月末・期末の処理負荷や支払停止の影響を踏まえ、運用の品質と引き継ぐデータの両方を定義します。
- 性能：月末・期末の同時接続数、請求照合バッチの許容時間
- 可用性：求める稼働率と障害時の復旧目標時間
- セキュリティ：取引単価や支払情報のアクセス権限、監査ログ
- 移行データ：サプライヤマスタ、単価マスタ、未検収の発注
機能要件に加えて、性能・可用性・セキュリティの非機能要件も欠かせません。月末や期末は処理が集中するため、ピーク時の同時接続数と請求照合バッチの許容時間を明示します。
支払が止まれば取引先への遅延につながるため、稼働率や復旧までの時間を定義します。さらに、単価や支払情報は機密性が高いため、アクセス権限や監査ログも併せて定めます。
購買システム更改で特に難しいのが、データ移行です。なかでも未検収POは、発注済みでも検収が終わっていない取引です。切替時に宙に浮くと、検収や支払を処理できない恐れがあります。
そのため、どの時点のデータを、どの形式で、どこまで移すかを定義します。マスタの品質を踏まえ、移行前に行うクレンジング（データの整理・修正）の範囲も決めます。
汚れたマスタを移すと、新システムでも同じ問題を抱えることになります。一方で、すべてを事前に整えると工数が膨らむため、移行前後の修正範囲を要件に明記します。
RFPに盛り込む項目とベンダー選定の評価観点
アセスメントと要件定義の内容をRFP（提案依頼書）にまとめ、各社へ提案を求めます。RFPは、同じ前提で提案を受けるための共通の物差しです。記載が曖昧だと、各社の提案の前提がばらつきます。
RFPに盛り込むべき必須項目
ベンダーは現行システムを知らないため、現状情報の詳しさが提案の精度を左右します。RFPには次の情報を記載します。
- 現行構成図：ハードウェア、ミドルウェア、基幹・会計連携、EDIを含む全体図
- 対象範囲：更改する機能と現行のまま据え置く機能の線引き
- 性能要件：繁忙期の接続数と請求照合バッチの許容時間
- KPI：発注リードタイム、照合自動化率、支出可視化などの目標
- データ移行：サプライヤ・単価マスタと未検収POの引き継ぎ範囲
サポート体制には、稼働後に求める保守・運用のサポート水準を記します。移行方式には、段階移行やストラングラーパターンなど、想定する進め方を示します。さらに、概算費用と期間では、投資可能な金額の幅と希望する完了時期を伝えます。
項目を明記すると、各社が同じ前提で提案できます（出典：富士通）。なかでも現行構成図と移行対象範囲は、更改ならではの重要項目です。
連携の対象が曖昧だと、各社のスコープ解釈が分かれ、見積りがぶれます。そのため、連携一覧やマスタの状況も図表で示します。
段階移行か、一度に切り替えるビッグバン方式かも明示します。方式の方針を各社に伝えると、移行提案を横並びで比べられます。
ベンダー評価の5つのチェックポイント
基幹や会計と連携する既存資産を扱う、難しいプロジェクトです。そのため、次の5点で各社の実力を確認します。
- 更改実績：同業界・同規模の購買・基幹更改経験
- 段階移行の設計力：新旧を並行稼働し、機能を順次移す計画
- 停止時間の試算：切替時のダウンタイムを見積もる精度
- 保守体制：24時間365日の運用サポート
- 認証：ISO9001やISO27001など品質・セキュリティの認証
価格や提案書の見栄えだけで選ぶのは危険です。近い業界で手がけた実績は、固有の調達ルールや法対応への理解を裏づける材料になります。業務を止めずに移行を進めるには、段階移行の設計力が欠かせません。
停止時間を具体的に試算できるかは、移行の段取りが現実的かどうかを判断する材料になります。そのうえで、支払や検収が止まる時間も確認します。
購買・支払業務の停止は、取引先との関係に直結します。また、取引単価や支払情報を扱うため、品質管理と情報セキュリティも確認します。
ビッグバン方式は切替時の影響範囲が大きく、問題が起きたときに後戻りしにくい方式です。一方、段階移行は機能を分けて移すため、影響を一部に留められます。
安価な提案に飛びつくと、移行に失敗して支払業務が混乱し、かえって高くつく場合があります。各観点に重みを付けて点数化すると、複数社を定量的に比べられます。特に、段階移行の設計力と停止時間の見積り精度は重点的に確認します。
5つの観点で水準を確かめたうえで、総保有コストと更改後の運用負荷も含めて総合的に判断します。そこで、RFPで各観点を確かめる質問を用意します。具体例や試算を求めると、抽象的な説明にとどまらず、各社を比べられます。
まとめ
更改が失敗する要因には、アドオンのブラックボックス化やマスタ品質の見落としがあります。そのため、発注・承認・検収・支払の流れを棚卸しします。
更改では、サプライヤ・単価マスタの品質や、EDI・基幹・会計との連携も調べます。
また、制度対応の確認も更改前に欠かせません。可視化ツールとしては、富士通の「ソフトウェア地図」などを活用できます。
棚卸しと要件定義に200万〜500万円程度をかけておくと、手戻りを抑えられます。
要件定義では、KPIを起点に、3-way matchや承認ワークフローなどの機能を具体化します。ほかに、Web-EDIや適格請求書処理も固めます。
性能・可用性・セキュリティの非機能要件も固めます。移行では、サプライヤ・単価マスタや未検収POの扱いも決めます。
RFPには、現行構成図や移行範囲、性能を記します。さらに、KPIとサポート体制、移行方式、概算費用と期間も含めます。
ベンダー選定では、同業界・同規模の実績や段階移行の設計力、停止時間の見積りを確認します。24時間365日の保守体制やISO9001・ISO27001などの認証も、5つの評価観点に含まれます。
各社を客観的に比べ、総保有コストや運用負荷まで考えて選ぶことが、失敗を防ぐことにつながります。
2025年の崖が警告するように、レガシー化した購買・調達システムの更改は経営課題です。焦って発注せず、現状分析から順に進めることが大切です。
ビッグバンを避けた段階移行を前提に、RFPと客観的な評価で選定します。アセスメントから、ベンダー選定までを順に積み上げることが、成功への出発点になります。
▼全体ガイドの記事
・購買管理システム更改の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。