この記事でわかること
BtoB-EC導入の比較検討で、多くの企業が「機能の多さ」「価格の安さ」「導入実績数」で判断しています。しかしこれらは判断精度が低い軸です。導入後に「業務が減らない」「価格管理が破綻した」「作り直すしかない」となった企業の多くは、比較検討の時点で重要な軸を見落としていました。本記事では、比較表を作る前に設定すべき7つの判断軸と、ベンダーに投げるべき具体的な質問を整理します。
比較表を作る前にやるべきこと
BtoB-ECの比較検討で最初にやるべきことは、ベンダーを並べることではありません。自社の受注構造を書き出すことです。
以下が整理されていない状態でベンダーに提案を依頼すると、各社がバラバラの前提で提案してきます。比べようがない状態になります。
- 現在の受注フロー（FAX・電話・メール・どのタイミングで誰が何をするか）
- 価格ロジックの全パターン（顧客別掛率・数量別・期間別・特例価格の有無）
- 例外処理の種類（分納・ロット割れ・納期変更・返品・特別値引きの承認ルート）
- 基幹システムの構成（ERP・在庫管理・会計との連携要件）
- 3年後の想定規模（取引先数・商品数・注文件数の見込み）
この整理なしに「どのシステムが良いか」を聞いても、正確な答えは返ってきません。受注構造が把握できていないベンダーも、正確な提案ができません。
7つの判断軸と確認すべき質問
① 「できる」と「運用できる」を分けて確認する
ベンダーの提案でよく出てくる言葉があります。「顧客別価格、対応できます」「基幹連携、可能です」。これらはすべて「機能として存在する」という意味です。「無理なく運用できる」という意味ではありません。
典型的な例を2つ挙げます。
- 顧客別価格：「会員区分を増やせば対応可能」でも、区分が50種類になった時点で管理が破綻する。区分の追加・変更・削除を誰がどの画面でどれくらいの工数でやるかを確認しないと判断できない
- 基幹連携：「CSVで対応可能」でも、毎日手動でインポートして、データを加工して、エラー検知も手動なら業務は減らない。むしろCSV管理の工数が増える
| 確認項目 | ベンダーへの質問 |
|---|---|
| 顧客別価格の運用 | 「新規取引先の価格設定を追加する場合、誰がどの画面で何分かかりますか？価格パターンが100種類になっても同じ手順ですか？」 |
| 基幹連携の運用 | 「連携でエラーが発生した場合、誰がどう検知して、どう対処しますか？その対応に開発は必要ですか？」 |
| 在庫更新の運用 | 「在庫データの更新頻度と方法を教えてください。リアルタイム更新でない場合、欠品注文が発生した時の処理はどうなりますか？」 |
② 価格ロジックの設計深度を確認する
BtoB-ECの設計でもっとも難しいのは価格です。導入から2〜3年後に「価格管理が限界に来た」という理由で再構築を検討するケースの多くは、この設計深度の確認が不十分だったことが原因です。
確認すべき価格パターンの一覧です。自社に該当するものを整理した上でベンダーに提示してください。
| 価格パターン | 確認すべきこと |
|---|---|
| 顧客別掛率（○○社は定価の80%） | 顧客が増えた時に設定追加は容易か。上限はあるか |
| 顧客別商品単価（契約単価） | 顧客×商品のマトリクス管理ができるか。ERPの単価マスタと連携できるか |
| 数量ブレイク価格（100個以上は○%引き） | 段階数に上限はあるか。商品カテゴリ別に異なる段階設定ができるか |
| 期間指定価格（キャンペーン） | 期間終了後に自動で元の価格に戻るか。複数キャンペーンの並行設定は可能か |
| 特例価格（営業が個別交渉した単価） | ERP側にしか存在しない特例価格をEC側に反映する方法はあるか |
③ 例外処理の扱いを確認する
BtoBでは例外が日常です。ロット割れ・分納・納期変更・特別値引き（承認フロー付き）・緊急対応——これらは比較表に載りません。ところがこの領域の設計が甘いと、「ECはあるが電話は減らない」という状態が続きます。
確認すべき質問です。
- 「現在FAX・電話で対応している例外注文（ロット割れ・分納・特別値引きなど）は、どのようにシステムで扱いますか？」
- 「例外注文が発生した場合の処理フロー（申請・承認・修正）は、システム内で完結しますか？それとも電話・メールでの確認が残りますか？」
- 「例外として運用するもの・仕組み化するもの・EC外で対応するものの分類を、要件定義でどのように整理しますか？」
最後の質問が特に重要です。例外処理の分類をきちんとやるベンダーかどうかが、設計力の指標になります。
④ 基幹連携の深さと現実性を確認する
「API連携可能」と書かれていても、比較すべきはそこから先です。
| 連携項目 | 確認すべき質問 |
|---|---|
| 在庫データ | リアルタイム更新かバッチ更新か。更新頻度は？在庫切れ時の注文はどう処理されるか |
| 受注データ | ECの受注がERPに即時反映されるか。反映されるまでのタイムラグは？ |
| 顧客・価格マスタ | ERP側で変更されたマスタがEC側に自動反映されるか。手動同期が必要な場合の手順は？ |
| 与信・請求 | 与信限度額超過時の注文をシステムで止められるか。掛売りの請求データはどう連携するか |
| 返品・キャンセル | 返品・キャンセル処理はEC・ERP双方で整合性が取れる設計か |
CSV連携から始めることが必ずしも悪いわけではありません。ただし「将来APIに移行する場合に何が必要か」「その時の追加費用はどれくらいか」を答えられないベンダーは、長期的な設計を考えていない可能性があります。
⑤ 将来拡張の余白を確認する
比較検討時は「今の要件」で判断しがちです。ただしBtoB-ECは導入後に高確率で要件が増えます。今の規模に最適化した設計が、2〜3年後に足かせになるケースは多い。
確認すべき質問です。
- 「取引先が現在の3倍・商品数が5倍になった場合でも、同じシステムで対応できますか？その場合に追加費用が発生する部分はどこですか？」
- 「新しい価格条件が生まれた時（例：新たな取引区分、新しいキャンペーン形式）、対応に開発は必要ですか？それとも管理画面で設定できますか？」
- 「権限設計について、現在想定していない権限パターン（新しい部署・新しい取引形態）が出てきた場合に追加できますか？」
⑥ 設計プロセスが提案に含まれているか確認する
BtoB-ECは「何を使うか」より「どう設計するか」が成否を分けます。にもかかわらず、提案の多くは「このシステムでこの機能を実装します」という内容で、設計プロセスへの言及が薄い。
以下の工程を提案の中でどう扱うかを確認してください。
- 受注フローの可視化：現行の受注フローを書き出し、ボトルネック・例外・属人化箇所を特定する工程があるか
- 価格ロジックの棚卸し：全価格パターンを書き出し、システムで実装するもの・運用で対応するものを分類する工程があるか
- 基幹連携のデータ設計：どのデータが「正」でどちらのシステムから流すかを設計する工程があるか
- 例外処理の分類：頻出例外は仕組み化・特殊例外は運用化・EC外対応を明確に分類する工程があるか
これらの工程が提案に含まれていないベンダーは、受注構造を整理しないまま構築に入る可能性があります。
⑦ 導入後の運用体制を確認する
「導入したら業務が楽になる」は自動では起きません。誰が何を担当するかの運用設計が必要です。
| 運用項目 | 確認すべきこと |
|---|---|
| 価格改定 | 誰が・どの画面で・どれくらいの頻度で行うか。担当者が変わっても対応できるか |
| 顧客追加・契約単価追加 | 新規取引先の登録から価格設定完了まで、何ステップ・何分かかるか |
| 連携エラー対応 | エラーが発生した場合の検知方法・対応フロー・開発依頼が必要なラインはどこか |
| 例外注文対応 | EC外で処理する例外注文の入口（申請・承認・修正）が設計されているか |
| 保守・バージョンアップ | 月額の保守費用・対応範囲・バージョンアップへの対応方針 |
比較軸の設定から、一緒に整理します
「何を基準に比較すべきかわからない」「ベンダー提案が出揃ったが判断できない」——その段階でのご相談も承っています。御社の受注構造を整理した上で、比較に使える軸と質問リストを一緒に作ります。
比較表に入れるべき項目・入れても意味がない項目
よく使われる比較表の項目を、判断精度の観点で整理します。
| 比較項目 | 判断 | 理由 |
|---|---|---|
| 初期費用・月額費用 | △ 参考程度 | 前提条件（カスタマイズ範囲・連携要件）が揃っていないと比較できない。「安い」提案が後から追加費用だらけになるケースが多い |
| 標準機能の一覧 | △ 参考程度 | 「機能がある」と「自社の要件に合う設計ができる」は別。機能数より設計深度を見る |
| 導入実績数 | △ 参考程度 | BtoB-ECの実績か・自社と同規模・同業種の実績かを確認しないと意味がない |
| 価格ロジックの設計深度 | ◎ 重要 | 自社の価格パターン全件に対して、どう設計するかを確認する |
| 例外処理の扱い方 | ◎ 重要 | 「電話が残る」要因の多くがここ。ベンダーの設計力が如実に出る |
| 基幹連携の設計方針 | ◎ 重要 | CSV連携・API連携・将来移行コストを含めて評価する |
| 設計プロセスの有無 | ◎ 重要 | 受注構造の整理・価格ロジックの棚卸しをやるベンダーかどうか |
| 運用の具体的な手順 | ◎ 重要 | 「誰が何分で何をするか」が言えないベンダーは運用設計を考えていない |
あわせて読まれています
よくある質問
ベンダー比較はRFP（提案依頼書）を作るべきですか？
規模が大きい案件（概算見積で500万円以上）であれば、RFPを作ることで各社の提案条件が揃い、比較しやすくなります。ただしRFPの品質は受注構造の整理度に比例します。価格ロジック・例外処理・基幹連携要件が整理されていない状態でRFPを作っても、各社がバラバラの前提で提案してきます。RFPを作る前に受注構造の整理を先行させてください。
SaaS型とカスタマイズ型のどちらが良いかも比較で判断できますか？
判断できます。この記事で挙げた7つの軸、特に「価格ロジックの設計深度」「例外処理の扱い」「将来拡張の余白」を自社要件で整理すると、SaaS型の標準機能で対応できるかどうかが見えてきます。SaaS型の限界についてはこちらの記事で詳しく解説しています。
ベンダーの提案が出揃ったが判断できない場合はどうすればいいですか？
この記事で挙げた質問を各ベンダーに投げ直してみてください。「価格ロジックが100パターンになった場合の追加費用は？」「例外処理の分類はどのようにやりますか？」——これらに明確に答えられるベンダーと答えられないベンダーで、自然に判断できるようになります。それでも判断が難しい場合は、第三者のセカンドオピニオンをご活用ください。
複数ベンダーから提案を取る場合、何社が適切ですか？
2〜3社が現実的です。4社以上になると比較の工数が膨らむ一方で、判断精度はあまり上がりません。大切なのは社数ではなく、この記事で挙げた判断軸に沿って同じ条件で比較できているかどうかです。1社の提案を深掘りする方が、4社を浅く比較するより判断しやすいケースも多い。
「何を基準に比較すればいいか」——そこから一緒に整理します
受注構造の整理・比較軸の設定・ベンダー提案のセカンドオピニオン。「まだ比較の段階」「提案が出たが判断できない」どのフェーズでもご相談いただけます。
投稿者プロフィール
- CEO
- 株式会社サンクユー 代表取締役CEO。
基幹システムとECをつなぎ、受発注業務の最適化を支援する専門家。
関西大学卒業後、東証プライム上場のゼネコンにて人事総務を経験。
その後システムベンダーへ転職し、IBM AS/400環境における金融・物流・販売管理・経理・人事など、企業の基幹業務を支えるシステム開発に従事する。
プログラマからプロジェクトマネージャーまでを経験し、台湾・台北駐在として銀行システム構築プロジェクトにも参画。
この経験を通じて、「システムの質は要件定義の質に比例する」という思想を確立。
業務理解を起点としたシステム設計を強みとする。
その後、クレジット決済代行会社にて、決済システムの再構築や銀行連携、ECサイト構築を担当。
あわせて組織改革にも携わり、20名から60名規模への組織拡大を実現（退任時：常務取締役）。
2008年に株式会社サンクユーを創業、2010年に法人化。
現在は、基幹システムとECの両領域に精通した知見を活かし、BtoB企業における受発注業務のデジタル化・効率化を支援。
特に、FAX・電話・メールなどアナログ業務のEC化や、基幹システムとの連携を前提とした業務設計を得意とする。
単なるECサイト構築にとどまらず、業務フローの整理・要件定義・システム設計まで一貫して関与し、「現場で使われる仕組み」を実現することを重視している。
NTTレゾナント「goo Search Solution」にてEC関連コラムを執筆。
ECマーケティングレポート | goo Search Solution
■趣味・関心領域
BMW / WRC / ロードバイク / RIZIN / UFC / 大相撲
David Bowie / blur / MUSE / The Rolling Stones / XTC
機動戦士ガンダム（富野由悠季）
ベルセルク / 頭文字D / 進撃の巨人 / ジョジョの奇妙な冒険 / あしたのジョー
Mission: Impossible / Memento / ワイルド・スピード / ソナチネ
LOST / Game of Thrones / FRINGE / The Mentalist
上岡龍太郎 / ダウンタウン
