小売のオンライン受発注移行、段階の踏み方と方式の選び方

◆監修・編集責任者　小園 将隆　2026年9月20日

B2B EC-COLUMN

オンライン受発注移行の段階と最初に決めること

オンライン受発注への移行は、現行の可視化→あるべき業務の定義→移行・並行稼働の3段階で進め、順序は入れ替えません。最初の判断は方式選びで、再構築・現行資産の移行・パッケージ活用・段階的な刷新の4つに優劣はなく、保守期限・業務を変える意思・体制の3点で決めます。保守期限が近ければ範囲を絞ります。

現行の可視化→あるべき業務の定義→移行・並行稼働の3段階

オンライン受発注への移行は、現行の可視化、あるべき業務の定義、移行・並行稼働という3段階で進めます¹。
最初の現行の可視化では、注文がどの経路で入ってきているかを取引先単位で洗い出します。FAX、電話、メールに添付されたExcel、営業担当が訪問時に預かる手書きの注文書といった経路ごとに、1か月あたりの件数、締め時間、入力する担当者、入力後に誰が何を確認しているかを並べます。
ここで一緒に押さえておきたいのは、きれいに流れている注文ではなく例外のほうです。欠品したときの代替提案、分納、出荷後の数量変更、緊急出荷、返品や交換の連絡が、いま誰の判断で処理されているのかを書き出しておくと、次の段階でシステムに載せる範囲を決める材料になります。

二つ目のあるべき業務の定義では、可視化した業務のうちどれをオンラインで受け、どれを人が受け続けるのかを線引きします。小売や卸の受発注には、取引先ごとの掛率、ケース単位とバラ単位の使い分け、締め日ごとの請求のまとめ方といった商習慣が絡みます。この商習慣をどこまでシステムに載せ、どこを運用で扱うかを決める作業が、この段階の中心です³。
線引きの結果は、そのまま必要な機能の一覧になります。逆に言えば、ここが曖昧なまま製品を比較しても、比較するための軸が作れません。

三つ目の移行・並行稼働では、決めた業務に合わせてマスタとデータを移し、実際の注文を流します。多くの場合、FAXや電話といった現行の経路をすぐには止められないため、新旧を同時に動かす並行稼働の期間を挟みます。
この段階で初めて、日々の締め処理や請求が新しい方式だけで完結するかどうかが分かります。3段階のうち前の二つで決めきれなかった事柄は、必ずこの段階で表面化します。

順序を入れ替えてはいけない理由

順序を入れ替えたくなる典型は、製品の選定を先に済ませてしまう進め方です。導入時期が決まっている、取引先から要請されているといった事情があると、まず製品を決めて後から業務を合わせようとしがちです。
この順番だと、要件が製品の画面に引きずられます。可視化していない例外処理は要件から抜け落ち、テストの終盤や並行稼働中に「この取引先だけ掛率の扱いが違う」「この商品は分納が前提だった」という形で出てきます。出てきた時点では設計を変えにくく、運用でしのぐ判断になりやすいところです。

マスタの扱いでも同じことが起こります。可視化を飛ばしてデータだけを移すと、廃番になった商品、単位の揃っていない商品、同じ商品の重複登録がそのまま新しい仕組みに持ち込まれます。移した先で気づいても、稼働後の修正は注文や在庫に影響するため、移行前に整理するより手間がかかります。

工程を踏む理由は、効果が生まれる場所が業務の作り直し側にあるためです。中小企業庁がミラサポplusで紹介した中小企業共通EDIの実証事業では、参加した中小企業の業務時間が平均で51.4%削減されたと報告されています⁵。
これは2018年時点の実証事業に参加した企業の平均値であり、業種も取引量も自社とは異なります。同じ削減率が自社でも出ると読むのではなく、受け取った注文を人が入力し直す工程そのものを減らせれば時間は動く、という方向の裏付けとして扱うのが妥当です。どの入力工程を減らすのかは、可視化と業務の定義を経なければ特定できません。
段階の順序が決まったら、次に決めるのは移行の方式です。

移行方式は4つ―自社に合う型の選び方

再構築・現行資産の移行・パッケージ活用・段階的な刷新

移行の方式は、再構築、現行資産の移行、パッケージ活用、段階的な刷新の4つに整理できます¹。
再構築は、業務の流れとデータの持ち方を作り直す方式です。現行資産の移行は、業務の作りを保ったまま置き場所や方式を移します。パッケージ活用は、製品の標準機能に業務を寄せます。段階的な刷新は、影響範囲を分けて順に切り替えます。

この4つは、受発注をオンラインにするという結果が同じでも、変える対象が違います。再構築とパッケージ活用は業務のほうを動かし、現行資産の移行は業務を動かさずに仕組みだけを動かします。段階的な刷新は、変える対象ではなく変える順番についての選択であり、他の方式と組み合わせて使われることもあります。

方式に優劣がない理由と選ぶ3つの軸

この4つに一般的な優劣はありません¹。どれが良いかは、自社が動かせる条件で決まるためです。判断の材料になるのは、保守期限、業務を変える意思、体制の3点です。

一つ目の保守期限は、いま使っている仕組みのサポートがいつまで続くかです。期限まで時間があるなら、業務の作り直しを含む再構築も選べます。期限が近い場合は、期間内に終わる範囲まで対象を絞る判断が先に来ます。ここで無理に全面の作り直しを狙うと、期限切れと開発の遅れが重なります。保守期限が契約上はっきりしない場合でも、現行を保守している担当者や委託先がいつまで対応できるのかを確認しておくと、実質的な期限が見えてきます。

二つ目は、業務そのものを変える意思があるかどうかです。オンライン受発注にすると、電話で融通していた納期調整や、営業担当が個別に判断していた価格の扱いが、画面上のルールに置き換わります。現場の運用を変えない前提を守るなら現行資産の移行が向き、変えることを組織として引き受けられるなら再構築やパッケージ活用が候補になります。意思の有無は担当者個人の意向ではなく、変更に伴う反発を引き取れる決裁者がいるかどうかで見ます。

三つ目は体制です。要件を決めきれる担当者がいるか、開発と運用を担う人手があるかで、選べる方式が変わります。社内に開発体制がなく、標準機能に運用を合わせられるならパッケージ活用が現実的です。逆に、要件を決める人を確保できないままどの方式を選んでも、判断待ちで工程が止まります。
3点を並べると、保守期限は時間の制約、意思は業務側の制約、体制は人の制約であり、どれか一つでも欠ければその方式は選べないという形で効いてきます。
方式の見当がついたら、次は進め方、つまり並行稼働を挟むかどうかの判断です。

段階移行(並行稼働)か一括切替か―判断基準と期間の目安

並行稼働が必要になる条件(停止可否・EOL/EOS・利用部門の負担)

並行稼働とは、新しい受発注の仕組みと現行のやり方を一定期間だけ同時に動かすことです。必要かどうかは、現行を止められるか、保守期限、利用部門の負担という条件で判断します²。

一つ目の停止可否は、切替の当日に現行の受注経路を閉じられるかどうかです。小売の受発注は日々の出荷とつながっているため、注文が入らない日はほとんどありません。締め処理や請求が月をまたいで走っている場合、旧側でしか完結できない処理が残ります。この状態であれば並行稼働が必要になります。

二つ目は、現行システムのサポート終了、いわゆるEOL/EOSの時期です。期限が先にあるなら並行稼働の期間を長めに取れます。期限が迫っているなら、並行稼働を短くするか、対象を分けて先に切り替えられるところから進めることになります。並行稼働は安全策である一方、期限に間に合わせるための時間を消費する面もあります。

三つ目は利用部門の負担です。並行稼働の間、受注担当は新旧の両方を見ることになり、実質的な二重入力が発生します。人数が限られる部門では、期間が延びるほど現場の負担と入力ミスの機会が増えます。負担を抱えきれないなら、並行稼働の対象を取引先や商品カテゴリで絞る判断が要ります。
この3条件のうち、停止可否と保守期限は動かしにくい前提であり、負担は範囲の絞り込みで調整できる変数です。

期間は月数で決めず業務サイクルを基準にする

並行稼働の期間を「まず3か月」のように月数で先に決めると、延長や短縮を判断する根拠が残りません。基準にするのは業務のサイクルです²。

受発注の業務は、日次の受注と出荷、月次の締めと請求、期ごとの棚卸し、季節ごとの繁忙期という複数の周期で動いています。並行稼働で確かめたいのは、これらの周期が新しい方式だけで一巡するかどうかです。月次の締めと請求を新方式側で完走していない段階で旧方式を止めると、止めた後に旧側にしかない情報が必要になります。
結果として、少なくとも締めと請求を一度は通す期間が要る、という決め方になります。棚卸しやセール期のように扱いが特殊な時期があるなら、その周期を並行稼働の中に含めるかどうかを個別に検討します。

もう一つ決めておくのは、旧方式を止める条件です。期間ではなく状態で書きます。対象の取引先からの注文がすべて新方式で入っている、締めと請求が新方式だけで完了した、問い合わせの内容が新方式の操作に関するものに限られている、といった書き方です。
条件を決めずに並行稼働を始めると、現場は安全のために旧方式を使い続け、二重入力だけが残ります。期間を延ばす判断をする場合も、何が満たされていないから延ばすのかを記録しておくと、次の取引先の切替で同じ議論を繰り返さずに済みます。

ここまでで、段階の順序、方式の選び方、並行稼働の要否という進め方の骨格は決まります。残るのは、取引先との調整、移行前のデータ整理、費用の見積もりという実務側の詰めです。

段階の順序と方式を絞る3つの軸までは社内で整理できますが、どの取引を標準機能に載せ、どこを運用で残すかの線引きは、BtoB ECの受発注設計を実際に手がけている相手と現物の注文書を突き合わせたほうが早く決まります。

現在のFAX・電話・メールでの注文と、取引先ごとの掛率や締めの条件を持ち込めば、標準機能で吸収できる範囲、人が受け続ける業務、並行稼働を置く位置の候補を具体的に確認できます。無料相談で要件を整理する

移行方式4つに優劣はない―選ぶ軸は3つ

自社側で動かせる前提条件（時間・業務・人）という観点で、方式を絞るための3つの軸として並べています。

• 保守期限（EOL/EOS）までの残り時間―期限が近いほど、期間内に終わる範囲まで対象を絞る

• 業務そのものを変える意思―現行の流れを守るのか、画面上のルールに置き換えるのか

• 体制―要件を決めきれる担当者と、開発・運用を担う人手が確保できるか

保守期限が先に来る場合は、業務を変える意思や体制よりも期限を優先し、期間内に終わる範囲まで対象を絞ります。

移行方式4つの中身と、移行前に固めること

方式	業務の扱い	選ぶ条件
再構築	業務の流れとデータの持ち方を作り直す	保守期限に余裕があり、業務自体を変える意思がある
現行資産の移行	業務の作りを保ったまま場所や方式を移す	現行の業務フローを大きく変えたくない
パッケージ活用	製品の標準機能に業務を寄せる	社内の開発体制が限られ、標準機能に運用を合わせられる
段階的な刷新	影響範囲を分けて順に切り替える	一括切替のリスクを避けたい、取引先ごとに対応時期が異なる

再構築―業務の流れとデータの持ち方を作り直す

向く条件と、着手前に決めること

再構築は、業務の流れとデータの持ち方を作り直す方式です¹。受発注で言えば、取引先ごとにばらばらだった注文書の様式や、担当者の記憶で運用されていた掛率の扱いを、マスタと画面のルールとして定義し直す作業になります。
選ぶ条件は、保守期限に余裕があり、業務自体を変える意思があることです。作り直す範囲が広いほど、要件を決める時間とテストの時間が必要になります。

着手前に決めておきたいのは、要件の決裁者と、旧データをどこまで移すかの2点です。決裁者が定まらないと、部門ごとに異なる希望がそのまま要件に積み上がります。旧データは、直近の取引実績だけを移すのか、過去の履歴まで移すのかで作業量が変わります。
また、再構築を選ぶ場合ほど、前段の可視化の精度が結果を左右します。可視化が浅いまま作り直すと、拾えなかった例外処理が稼働後に運用の抜け道として残ります。

現行資産の移行―業務の作りを保ったまま移す

向く条件と、移行後に確かめること

現行資産の移行は、業務の作りを保ったまま、置き場所や方式を移す方式です¹。現行の業務フローを大きく変えたくない場合に向きます。受発注の手順や帳票の形は維持したまま、入力の経路や連携の仕組みだけをオンラインへ寄せる進め方です。

利点は、現場の再教育が少なく済むことと、切替時の混乱が比較的小さいことです。一方で、現行の非効率もそのまま移ります。たとえばFAXを受けてから基幹へ手入力するという流れを残したまま移行すると、入力する場所が変わるだけで人の手数は減りません。
この方式を選ぶなら、移行後に何が減るのかを先に言葉にしておきます。減るものが保守の費用なのか、入力の手間なのかで、稼働後に確かめる指標が変わります。

パッケージ活用―製品の標準機能に業務を寄せる

向く条件と、寄せられるかの確かめ方

パッケージ活用は、製品の標準機能に業務を寄せる方式です¹。社内の開発体制が限られ、標準機能に運用を合わせられる場合に向きます。

判断の要点は、標準で吸収できない商習慣をどう扱うかです。取引先ごとの個別価格、分納や予約受注、預け在庫といった扱いは、製品によって対応の仕方が異なります。データを保持できることと、その条件が実際の受注画面や帳票に反映されることは別であり、機能として実装されているかを製品ごとに確かめる必要があります。
寄せる判断は情報システムの担当だけでは決められません。営業と受注の担当者が、現行のやり方を変えることに合意しているかを、製品の選定より前に確認しておきます。

段階的な刷新―影響範囲を分けて順に切り替える

分ける単位の決め方と、完了の見なし方

段階的な刷新は、影響範囲を分けて順に切り替える方式です¹。一括切替のリスクを避けたい場合や、取引先ごとに対応できる時期が異なる場合に選びます。

分け方には、取引先単位、商品カテゴリ単位、業務単位（受注だけ先に進め、請求は後に回す）などがあります。どの単位で分けるかは、例外処理がどこに集まっているかで決めます。特殊な条件の多い取引先を最初に選ぶと、初回で設計の穴が出て全体が止まりやすくなります。標準的な取引の多い相手から始め、例外の多い相手を後半に回すと、先行分で得た内容を後続に反映できます。

注意点は、分ける数が増えるほど二重管理の期間が延びることです。単位ごとに、何が満たされたらその単位の切替を完了と見なすのかを決めておきます。ここは並行稼働の設計と同じ考え方で、期間ではなく状態で書きます²。
方式の見当がついたら、自社だけでは決められない部分、つまり取引先との調整に移ります。

取引先(卸・メーカー)との調整で確認すべきこと

取引先側がFAX中心である前提をどう扱うか

オンライン受発注の計画でつまずきやすいのは、取引先も同じ時期にオンラインへ移れる前提で日程を引いてしまうことです。日経クロステックは、経済産業省の委託で帝国データバンクが行った調査を引いて、日本の中小企業の7〜8割が受発注をFAXでやり取りしていると2019年に報じています⁶。
これは中小企業全般についての2019年時点の状況であり、自社の取引先の内訳を示すものではありません。ただし、取引先の中にFAXのままの相手が相応にいることを前提に置いたほうが、計画は現実に近づきます。

前提を置いたうえで取れる手は二つあります。一つは、FAXで届いた注文を自社側でシステムに入力し、社内の処理をオンラインに一本化する運用です。相手の運用を変えずに、在庫の引当や出荷指示のばらつきを減らせます。もう一つは、段階的な刷新の考え方で取引先を分け、オンラインに対応できる相手から順に切り替える方法です。
どちらの場合も、相手にオンライン化を求めるのは自社側の運用が安定してからにすると、相手からの問い合わせに答えられる状態で依頼できます。

移行時期を取引先都合だけで決めないための確認事項

取引先からの要請が移行のきっかけである場合、まず確認したいのは相手が求めているものの中身です。相手のEDIに自社が合わせるのか、自社の受発注画面を相手に使ってもらうのかで、必要な作業はまったく異なります。
あわせて、やり取りするデータの項目、開始の希望時期、テストに使える期間、相手側の窓口担当者を確認します。ここが曖昧なまま日程だけが決まると、自社の保守期限や繁忙期と衝突します。

移行時期を相手都合だけで決めないために、自社側で動かせない日程を先に書き出しておきます。現行システムの保守期限、決算や棚卸しの時期、季節的な繁忙期の三つが代表的です。この三つと相手の希望時期を並べたうえで、並行稼働をどこに置くかを決めます。
相手の希望に合わせる判断をする場合も、なぜその時期にしたのかを記録しておけば、別の取引先から異なる時期を求められたときに同じ基準で説明できます。
時期の見通しが立ったら、稼働までに社内で進めておく準備に移ります。

移行前の準備で見落としやすい点―商品データ精査の実例

商品登録データの精査にかかる規模感(事例)

移行前の準備で見落とされやすいのが、商品マスタの整理です。欧州を中心としたスポーツ自転車部品の輸入・卸売りを手がける株式会社ポディウムは、2万点ほどあった商品登録をだいぶ精査したと述べています⁴。これは1社の例であり、すべての事業者に同じ規模の作業が生じるという意味ではありませんが、取扱点数の多い業種では移行作業の中で相応の比重を占め得ることを示しています。

精査の中身は、廃番品の扱い、同じ商品の重複登録、入数や単位の不揃い、型番や画像の欠落といった判定です。これらは商品の知識がなければ判断できないため、外部に丸ごと任せにくく、社内の担当者の時間を使います。開発の進み方とは別に進む作業なので、着手が遅れるとそのまま稼働の遅れになります。

着手の時期は、可視化の段階からが現実的です。可視化で取引先ごとの注文内容を見れば、実際に動いている商品と、登録だけが残っている商品の区別が付き始めます。掲載の可否、単位、型番、画像という判定の基準を先に決めておけば、担当者が複数になっても判断がぶれません。
データの目処が立ったら、費用の見当を付ける段階です。

受発注システムの費用相場

初期費用の相場

受発注管理システムの費用は、提供形態や機能の範囲で幅があります。BOXIL Magazineは2026年の記事で、初期費用の相場を0円〜1,000,000円前後としています⁷。
0円に近くなるのは、標準機能をそのまま使い、設定を自社で行う場合です。上限に近づくのは、マスタの移行や取引先ごとの初期設定、既存システムとの連携を伴う場合です。見積もりを比べるときは、マスタ移行と初期設定がどちらに含まれているかを揃えたうえで並べます。

月額費用の相場

月額費用の相場は、同じ記事で1,000円〜90,000円程度とされています⁷。
幅の要因になりやすいのは、利用するID数や取引先数、扱う受注件数、必要な連携の有無です。契約前に、取引先が増えたときに月額がどう変わるのかを確認しておくと、段階的な刷新で対象を順に広げる場合の総額を見積もれます。

予算で見落とされやすいのが、並行稼働中の費用です。旧来の仕組みを止めるまでは、両方の費用が重なります。相場はあくまで選定の当たりを付けるための幅であり、自社の取引先数と必要な機能を示したうえで個別に見積もりを取ることが前提になります。

費目	相場の幅（2026年時点）	幅が生まれる主な要因
初期費用	0円〜1,000,000円前後	マスタ移行・初期設定・既存システムとの連携の有無
月額費用	1,000円〜90,000円程度	ID数・取引先数・受注件数・連携の有無

要点の整理

軸	基準
段階の順序	現行の可視化→あるべき業務の定義→移行・並行稼働。可視化の前に製品を選ばない
方式の選択	4つに優劣はなく、保守期限・業務を変える意思・体制の3点で決める
並行稼働の要否	現行を止められるか、保守期限、利用部門の負担で判断する
期間の決め方	月数ではなく、締めと請求など業務サイクルを一巡させる。止める条件は状態で書く
取引先調整	相手の受注体制を確認し、自社の動かせない日程と並べて切替時期を決める
移行前の準備	商品マスタの精査は可視化の段階から着手し、判定の基準を先に決める
費用の見方	初期0円〜1,000,000円前後、月額1,000円〜90,000円程度（2026年）を目安に個別見積もり

並行稼働の設計と商品マスタの精査は、社内の人手と稼働時期に直結する部分であり、同種の移行を支援してきた相手に現状を見せたほうが、必要な工数と順序の見立てが立てやすくなります。 取引先数、商品の登録点数、現行システムの保守期限を示せば、切替を分ける単位、旧方式を止める条件の書き方、費用が変動する要因を具体的に確かめられます。

よくある質問

並行稼働の期間はどのくらい設ければよいか

月数で先に決めるのではなく、業務が一巡する単位で考えます。少なくとも月次の締めと請求を新しい方式側で一度完走させることが目安になり、棚卸しやセール期のように扱いが特殊な時期があれば、それを含めるかどうかを個別に判断します。あわせて、旧方式を止める条件を状態で書いておきます。対象の取引先の注文がすべて新方式で入っている、締めと請求が新方式だけで終わった、問い合わせが新方式の操作に限られている、といった条件です。条件を決めずに始めると、現場が安全のために旧方式を使い続け、二重入力だけが残ります。

取引先がFAXのままでも移行を進めてよいか

進められます。2019年時点で日本の中小企業の7〜8割が受発注をFAXでやり取りしていると報じられており、取引先の側がすぐに変わらないことは前提として計画に織り込むほうが現実的です。この場合は、FAXで届いた注文を自社側でシステムに入力し、在庫の引当や出荷指示など社内の処理をオンラインに一本化する運用から始められます。相手にオンラインでの発注を求めるのは、自社の運用が安定し、操作の質問に答えられる状態になってからにすると、依頼の通りやすさが変わります。

受発注システムの初期費用・月額費用はどのくらいかかるか

2026年の相場として、初期費用は0円〜1,000,000円前後、月額費用は1,000円〜90,000円程度と紹介されています。幅が広いため、相場だけで判断せず、自社の取引先数、必要なID数、既存システムとの連携の要否を示して個別の見積もりを取ることをおすすめします。確認しておきたいのは、マスタ移行と初期設定が初期費用に含まれるか、取引先を増やしたときに月額がどう変わるか、の2点です。並行稼働の期間中は旧来の仕組みの費用と重なるため、その分も予算に含めておきます。

商品データの精査はいつ・どの段階で始めればよいか

現行の可視化の段階から着手するのが現実的です。可視化で取引先ごとの注文内容を見ると、実際に動いている商品と登録だけが残っている商品の区別が付き始めるためです。精査は廃番、重複、単位の不揃い、型番や画像の欠落といった判定が中心で、商品の知識が要るため社内の時間を使います。掲載の可否、単位、型番、画像という判定の基準を先に決めておくと、担当者が複数になっても判断がぶれません。開発の進み方とは別に進む作業なので、着手が遅れるとそのまま稼働の遅れにつながります。

小規模な小売店でも段階的な刷新は可能か

可能です。分ける単位を取引先や商品カテゴリに絞れば、担当者が少なくても進められます。むしろ要件を決める人が限られている場合は、判断待ちが起きにくいという面もあります。ただし、分ける数が増えるほど新旧を並行して管理する期間が延び、受注担当の負担が積み上がります。単位の数を絞り、単位ごとに完了と見なす条件を決めておくことが前提です。体制が厳しい場合は、標準機能に運用を合わせられるかどうかも合わせて検討すると、選べる方式が整理できます。

1. 1　出典：株式会社フライトソリューションズ「基幹システム刷新とは｜進め方と移行方式の選び方」（2026年）　経路
2. 2　出典：株式会社フライトソリューションズ「BtoB EC並行稼働と切り替え設計｜期間と判断基準」（2026年）　経路
3. 3　出典：株式会社フライトソリューションズ「卸売業のEC化の進め方｜商習慣を載せる5段階」（2026年）　経路
4. 4　出典：株式会社フライトソリューションズ「EC-Rider B2B 導入事例 株式会社ポディウム様」（2025年）　経路
5. 5　出典：中小企業庁「中小企業共通EDI(次世代企業間データ連携調査事業)ミラサポplus解説」（2018年）　経路
6. 6　出典：日経クロステック(経済産業省委託・帝国データバンク調査を引用)「中小企業の8割が『ファクスで受発注』の現実」（2019年）　経路
7. 7　出典：株式会社スマートキャンプ「BOXIL Magazine 受発注管理システムの費用相場と料金比較・おすすめサービス」（2026年）　経路