購買管理システム刷新のアセスメント/要件定義/RFPについて

購買管理システム刷新の成否を安定させるには、開発前に作る文書の質を保つことが欠かせません。アセスメント、要件定義、RFPの順に点検項目を固めます。

購買に特有の点検項目から、TO-BE要件、RFPとベンダー評価へ進みます。全体像は購買管理システム刷新の完全ガイドもご覧ください。

▼全体ガイドの記事
・購買管理システム刷新の完全ガイド

購買管理システム刷新のアセスメント:現行資産と業務の棚卸しで可視化する範囲

現行アプリケーション資産を中心に、複雑度、依存関係、影響範囲、段階移行を示した図。
依存関係の把握が、切り出し単位とRFPの裏付けを考える手掛かりになります。

アセスメントは刷新の入口で、何を可視化し、どの点検項目で見るかを決める工程です。

現状診断レポートと資産一覧を作り、現行の業務とシステム資産を見える形にします。

アセスメントでは、一般的なシステム資産の点検に加えて、購買・調達の現場に特有の点検項目も確認します。

診断結果は、後続の要件定義やRFPを組み立てる土台になります。

アセスメントの中心になるのは点検リストで、その考え方を次に示します。

点検すべき購買アセスメント項目リスト

点検項目を先にリストとして決めておくと、調査が偏らず、作業を効率よく進められます。漠然と現状を調べるより、診断の質を一定に保てます。

このリストは、業務・データ・連携・統制の観点から、正規の手順から外れた処理や、データと承認の抜け道を探せるように組んでいます。

  • 野良購買:Excelや紙で処理している発注の量
  • サプライヤーマスタ:表記ゆれによる重複登録や休眠データ
  • 例外承認:規程外の特急発注や事後承認の頻度
  • 基幹連携:ERPや会計システムとの受け渡し方式と更新頻度
  • 帳票・保存:発注書や検収書の紙・電子の別と制度適合性

点検結果を一覧にすると、刷新の対象範囲と移行の難所が見えてきます。

特に野良購買と例外承認は、診断の精度を左右します。野良購買は現行システムの画面だけでは把握できないため、購買部門・経理部門・現場の発注担当者に聞き取りを行い、正規の手順から外れた処理を探します。

例外承認も、どこでどれだけ発生するかを確かめます。点検リストに沿って進めれば、ヒアリングの抜け漏れを防げます。

ソフトウェア地図による複雑度と依存関係のデータ化

業務の点検と並行して、現行アプリケーション資産の技術的な診断も行います。ヒアリングだけでは把握しきれない複雑さをデータにし、購買刷新の移行範囲の検討に使います。

  • 複雑度の可視化:富士通の「ソフトウェア地図」で資産の複雑度を描き出す
  • 依存関係の把握:プログラム同士の関係やブラックボックス化を、客観データとして押さえる
  • 影響範囲の確認:発注・検収・支払・在庫・会計の連携を踏まえ、変更の波及を調べる
  • 段階移行の検討:依存関係から切り出し単位を決め、複雑度マップをRFPの裏付けにする

アセスメントは、独立した工程として外部に委託することもできます。

要件定義・業務棚卸しのみの費用相場は、200万〜500万円程度です。

診断を省いて要件が曖昧なまま開発すると、後工程の手戻りや追加費用が膨らむおそれがあります。このため、上流の診断は総コストを抑えるための先行投資と捉えられます。

ポイント

アセスメントは、業務の点検とソフトウェア地図による技術の診断を並べて進めます。どちらか一方だけで移行範囲を決めず、両方の結果を突き合わせるのが目安です。

要件定義で固めるべき購買刷新のTO-BE要件

購買刷新のTO-BE要件を、機能要件、非機能要件、制度要件の3層で整理した図。
制度への適合も、機能や稼働品質と並ぶ要件定義の柱です。

現状診断の次は、刷新後の姿を定める要件定義です。要件定義書は、ベンダーに渡すRFPの土台になり、その品質は後続の提案や見積もりの精度を左右します。

購買刷新のTO-BE要件は、機能・非機能・制度の3分類で整理します。そのうえで、各分類に漏れがないかを点検します。

機能要件と非機能要件の書き分け

機能要件では、システムが何をするかを定めます。購買管理では、発注・検収・三点照合が中核の機能です。

三点照合とは、発注書・納品書・請求書を突き合わせることです。

こうした機能に加えて、支払処理やマスタ管理も機能要件に含めます。

アセスメントで見つけた野良購買や例外承認については、新システムにどこまで取り込み、どう標準化するかを言葉にしておきます。ここが曖昧だと、稼働後に現場で使われないシステムになるおそれがあります。

非機能要件では、システムがどの程度の品質で動くかを定めます。

購買では、性能と可用性が事業継続に関わります。

要件定義書には、次の項目を具体的な数値で記載します。

  • 性能:月次締めの集中時に処理する発注・検収の件数と時間
  • 可用性:許容停止時間と障害時の切り戻し手順
  • 移行後KPI:発注リードタイムや支出可視化率の目標
  • 拡張性:取引先や拠点の増加に耐える範囲

処理件数や時間などの数値を明示しておけば、ベンダー各社の提案を同じ基準で比べられます。

移行後KPIは、要件定義書を成果の測定につなげる要素です。

発注リードタイムを何割短縮し、支出可視化率を何パーセントにするかを決めます。目標を定めておくと、刷新後の達成度を評価でき、ベンダーとの認識もそろえられます。

非機能要件の数値化を後回しにすると、稼働後に性能の評価が食い違うおそれがあります。

要件定義の段階で織り込む制度要件

機能要件と非機能要件に並ぶ第三の分類が、法制度への適合を定める制度要件です。

購買・調達は発注書や請求書などの証憑を大量に扱うため、税務・会計制度の影響を受けやすい領域です。

制度要件では、その適合方法を定めます。

制度を要件定義の段階で織り込まないと、稼働後に大規模な改修が発生しかねません。

購買刷新では、電子帳簿保存法とインボイス制度への対応が中心になります。

  • 電子帳簿保存法:電子取引の発注書や請求書を、改ざん防止と検索性の要件を満たして保存する
  • インボイス制度:適格請求書の記載事項を処理し、税区分ごとに正確な仕入税額控除を行う

要件定義書には、保存方法や処理フローまで落とし込んで書きます。「対応する」と一言記すだけでは、開発会社に前提が伝わりにくいためです。

制度要件を早い段階で固めれば、後から個別に改修する手間を避けやすくなります。

刷新は、属人化した承認ルールや帳票の扱いを制度に合わせて標準化する機会にもなります。

3分類の要件を明確に書くほど、ベンダーに前提が伝わり、提案の精度も高まります。その品質は、ベンダー選定の進め方にも響きます。

ポイント

要件定義では、機能・非機能・制度の3分類に漏れがないかを先に見直すのが目安です。非機能要件が数値で書けているかを確かめると、稼働後の評価のずれを防ぎやすくなります。

RFPに盛り込むべき項目とベンダー評価の客観基準

共通の採点表を中心に、ベンダー評価の5観点を放射状に示した図。
金額以外の観点も横並びにすると、提案の違いを判断しやすくなります。

要件定義の成果はRFP(提案依頼書)にまとめ、ベンダーの提案を客観的に評価します。RFPは、的確な提案を引き出し、複数社を同じ条件で比べるための共通の基準です。記載が薄いと提案も薄くなり、選定の精度が下がります。

RFPに記載すべき項目と成果物の整理

RFPでは、ベンダーが正確に提案できるよう、前提を過不足なく伝えます。

刷新案件では、現行システムの状態と刷新後の到達点を示します。そのうえで、要件定義書の内容を読みやすく組み直します。

RFPの中心項目を具体的に書くと、各社への提案条件をそろえられます。

  • 現行構成図:AS-IS全体像と連携先一覧
  • 性能要件:同時利用者数、処理件数、レスポンス目標
  • 移行後KPI:発注リードタイムや支出可視化率の目標
  • 段階移行方針:先行稼働する機能と新旧の並行方法
  • データ移行範囲:サプライヤーマスタや過去取引データの扱い

各項目を具体的に記すほど、提案の精度と各社の比較可能性が高まります。

購買管理システムのRFPでは、購買固有の前提が提案の差別化につながります。三点照合の自動化範囲も明記します。

ERP・会計との連携方式は、APIかファイルか、リアルタイムかバッチかを示します。

電子帳簿保存法とインボイス制度への対応方法も、要件に含めます。

発注や支払を止められないため、段階移行方針は欠かせません。発注機能を先行させ、検収・支払を後から移す案も示します。

現実的な移行像を描けるかどうかは、提案の質に表れます。

提案を見極めるベンダー評価の5観点

提案は、共通の観点で各社を採点して比べます。

提示金額の低さに引きずられると、刷新の途中で実装力やサポート体制の不足が表面化し、プロジェクトが立ち行かなくなるおそれがあります。

刷新案件で共通して有効な評価観点として、採点表には次の5つを盛り込みます。

  • 同業種・同規模の実績:類似する企業での刷新経験
  • 段階移行の設計力:新旧を並行させて安全に移す設計
  • ダウンタイムの見積り:切替時の停止時間の具体的な数値
  • 24時間365日の保守体制:稼働後のサポート体制
  • ISO9001/27001等の認証:品質と情報セキュリティの客観的な裏付け

各社を同じ項目で採点すれば、感覚に頼らず提案を横並びで判断できます。

購買業務への習熟度は見極めの精度を高めます。そのため、三点照合、予算統制、サプライヤーポータルについて、過去にどこまで実装してきたかを確かめます。

制度対応については、保存要件や適格請求書の処理方法まで説明できるかを見ます。

提案の具体性も、実装力を見極める材料になります。

アセスメント、要件定義、RFPと成果物を積み上げると、提案各社の差も読み取りやすくなります。

ポイント

RFPとベンダー評価で迷ったら、各社を同じ項目と同じ採点観点で比べられているかを見直します。金額の安さだけで決めていないかも、あわせて確かめてください。

まとめ

刷新のアセスメント・要件定義・RFPで作る成果物と点検項目は、ここまで見てきたとおりです。アセスメントでは、野良購買・サプライヤーマスタの汚れ・例外承認・基幹連携・帳票保存を点検します。富士通の「ソフトウェア地図」で、現行資産の複雑度と依存関係もデータ化します。

要件定義では、機能・非機能・制度の3分類でTO-BE要件を固めます。

移行後KPIや電子帳簿保存法・インボイス対応は、数値や処理フローまで書き込みます。RFPには現行構成図・性能要件・移行後KPI・段階移行方針・データ移行範囲を記載します。

ベンダー評価は、同業種・同規模の実績、段階移行の設計力、停止時間、保守体制、認証の5観点を採点します。購買業務への習熟度も、判断の材料として確認します。要件定義・業務棚卸しのみの費用相場は200万〜500万円です。

上流工程の成果物を堅実に作ると、刷新全体の手戻りを抑えられます。自社では記事のチェック項目を使い、各成果物の抜けを点検してください。

手法の全体像や費用感、進め方の選択肢は、完全ガイドで確認できます。上流工程の成果物を一つずつ固めることが、購買改革を進める一歩になります。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。