オンライン受発注を多拠点で段階移行する進め方｜拠点の選び方から並行運用の終わらせ方まで

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

B2B EC-COLUMN

電話・FAX受発注の限界と、多拠点移行で段階を踏む理由

先に一つの拠点だけオンライン発注へ切り替えてみたら、思ったより素直に回り始めた。
ところが残りの拠点へ同じやり方を広げようとした途端、どの順で手を付けるか、電話とFAXをいつやめてよいかが決まらない——多拠点の移行は、たいていここで止まります。
全拠点を同じ日に切り替えれば、欠品や誤発注が出たときに影響が全社へ一度に広がり、原因がシステムなのか操作なのか取引先側なのかも切り分けられません。
ここで自分の裁量で変えられるのは、切り替えの速さではなく、切り替える単位と順序です。
影響の範囲が小さく、結果を自分の目で見届けられる単位から着手し、そこで運用が落ち着いたと確かめてから次へ広げる。
遠回りに見えて、これが混乱を抱え込まずに全拠点まで届かせる現実的な進め方です。

「まだFAXが主流」は、どこまで言えるのか

電話とFAXで注文をやり取りしている現場は、いまも珍しくありません。
経済産業省が帝国データバンクに委託した調査報告書を引用した記事では、日本の中小企業の7〜8割が受発注をファクスでやり取りしているとされています³。
ただしこの数字は記事による紹介として確認したもので、報告書本体まで当たって確かめたわけではありません。
対象も中小企業全般で、複数拠点を持つ企業に限った調査ではない点は踏まえておく必要があります。

別の角度からも似た状況が見えます。
中小商業・サービス業における「電子文書での商取引や受発注情報管理」の導入率は、2018年時点で18.5%と2割を下回っていました¹。
業種が限られた数字ではありますが、紙と口頭のやり取りが標準で、電子化している側が少数だった状況が読み取れます。

では切り替えるとどうなるか。
中小企業共通EDIの実証プロジェクト12件では、参加した中小企業の受発注業務時間が平均51.4%削減されました¹。
2016年度の実証で、発注側と受注側の双方を含む平均値ですから、どの企業でも半分になると読むことはできません。
それでも、「多少は楽になる」という程度の話ではなく、業務時間の桁が変わる規模で効いた例があることは確かめられます。
切り替える価値そのものは、数字の上で疑う段階にありません。

それでも一斉には切り替えない方がよい理由

効果が分かっているなら早く全社でやるべきだ、という結論になりがちです。
ところが拠点が増えると、切り替えの影響範囲は拠点数との掛け算で広がります。
一つの拠点が20社の取引先と発注のやり取りをしていて、拠点が12あれば、延べ240の発注関係がある計算です。
同じ日に方式を変えるということは、240通りの「初日」が同時に来るということでもあります。

発注が半日止まったときに何が起きるかを考えてみてください。
欠品は店頭や現場に出ます。
電話とFAXであればその場で追加発注して間に合わせられますが、オンラインに切り替えた直後は、注文が通らない理由がシステム側なのか、操作の間違いなのか、取引先がまだ受け取り方を決めていないのかが分かりません。
拠点が一つなら電話で詰めていけますが、同時に八つの拠点から同じ問い合わせが来れば、原因を切り分ける前に対処で手一杯になります。

段階を踏む目的は、慎重さを演出することではありません。
原因と結果を結び付けられる状態を保つことです。
一つの拠点、あるいは一つの取引先群だけを切り替えていれば、不具合が出たときに「変えたのはそこだけ」と言い切れます。
この切り分けができるかどうかが、そのまま次の拠点へ渡せる学びの量になります。
逆に全部を同時に動かすと、問題は起きても、何を直せば次が良くなるのかが残りません。

受発注のオンライン移行はどんな段階を踏んで進むのか(全体の流れ)

一組の取引をオンラインにするまでの流れ

拠点の順番を考える前に、「一拠点分の移行」が何から何までを指すのかを押さえておきます。
中小企業共通EDIの導入手順として示されているのは、説明・ヒアリング、導入検討と取引先との調整、製品・サービスの選定、導入計画の策定、運用、という順番です⁴。
これは一組の発注側・受注側の間でEDIを入れる場合を想定した一般的な流れで、複数拠点へどう広げるかまでを定めたものではありません。

注目したいのは二番目です。
製品を選ぶより前に、取引先との調整が置かれています。
自社の都合だけでは決められない工程が、流れの前半に組み込まれているということです。
多拠点でこの順番を無視すると、本部でシステムを決めてから各拠点で「取引先が対応できない」と判明する、という最も厄介な順序で問題が出ます。
選定を急ぐ前に、拠点が抱えている取引先がどこまで対応できるのかを拾う必要があるのは、この構造からです。

多拠点では、この流れを単位ごとに回す

拠点が複数ある場合にこの流れをどう当てはめるかは、資料に答えがある部分ではなく、自社で組み立てる部分です。
実務的に扱いやすいのは、五つの工程をひとまとまりの「移行サイクル」と見て、対象の単位を変えながら繰り返す形です。
最初の単位で一周し、運用が落ち着いたことを確かめてから、次の単位で二周目に入ります。

この見方の利点は、「全社移行」という大きな塊を、同じ形の作業の繰り返しに分解できることです。
一周目で何に時間が掛かったかが分かれば、二周目以降の予定も、その実績から組み直せます。

二周目から短くなるところ、毎回必要なところ

繰り返すといっても、毎周が同じ重さになるわけではありません。
製品・サービスの選定は原則として一回で済みます。
導入計画の型も、一周目で作った操作手順書、現場向けの説明資料、問い合わせ窓口の決め方がそのまま使えます。
二周目の拠点には、一周目で出た質問と回答をまとめて渡せるので、説明の時間も縮みます。

一方で、毎回必要になるのが取引先との調整と、その拠点の運用の確認です。
取引先が拠点ごとに違えば、調整は拠点の数だけ発生します。
同じ取引先であっても、拠点ごとに窓口の担当者や納品の条件が違えば、受け取り方の確認はやり直しです。
現場の習熟も、人が違えば一から始まります。

つまり二周目以降に短縮できるのは自社内の準備で、外との調整と現場の慣れは短縮しにくい。
この区別は、後で移行期間を見積もるときにそのまま効いてきます。

最初に移行する拠点・単位はどう選ぶか

「代表的な拠点から」でよいのか

最初の単位をどう選ぶかについて、数値で裏づけられた公的な基準は見当たりませんでした。
ここから先は、前の節で確認した「取引先との調整が選定より前に来る」という事実を手がかりに組み立てた考え方として読んでください。
自社の拠点特性に当ててみて妥当かどうかは、着手前に確かめる必要があります。

よくあるのは、売上規模の大きい主要拠点を最初に選ぶ発想です。
全社の典型だからここで回れば他も回る、という理屈は分かります。
ただ主要拠点ほど発注量も取引先も多く、止まったときの影響が大きい。
検証したい段階で、最も失敗できない場所を選ぶことになります。

逆に最も小さい拠点を選べば影響は抑えられますが、扱う商品も取引先も少なすぎて、他の拠点で起きるはずの問題が表に出てきません。
一周目を無事に終えても、二周目で初めて本番の問題に出会うことになります。
規模の大小だけで選ぶと、どちらに振っても据わりが悪いわけです。

候補を見るときの観点

間を取るというより、「一周目で何を確かめたいのか」を先に決めてから選ぶ方が決めやすくなります。
確かめたいのが取引先の対応可否なら、すでに対応状況が分かっている取引先を多く抱えた拠点が向きます。
確かめたいのが現場が操作に慣れられるかなら、発注の担当者が固定されていて、教育の手が届く拠点です。

この中で判断が割れやすいのは、三行目の「移行前の状態を数えられるか」です。
紙と表計算で管理していて、月にどの品目をどれだけ発注しているか即答できない拠点は少なくありません。
そこを一周目に選ぶと、移行後に誤発注や欠品が増えても減っても、良くなったのかどうかを説明できません。
比較の土台がない拠点から始めると、次へ進む判断の材料が手元に残らないのです。

拠点で区切らない選び方もある

単位は必ずしも拠点である必要はありません。
一つの拠点のうち特定の取引先だけ、あるいは特定の商品群だけをオンラインにする切り方もあります。
この場合は一拠点の中に二つの方式が同居するので現場の負担は増えますが、取引先の対応状況に合わせて進められるという利点があります。

拠点で区切るか取引先で区切るかは、どちらの線で揃えやすいかで決まります。
全拠点が同じ取引先から仕入れているなら、取引先単位で切れば一度の調整が全拠点に効きます。
拠点ごとに地場の取引先が違うなら、拠点単位で切る方が自然です。
仕入れの構造を一度書き出してみると、自社がどちらの線で切れるのかは案外はっきりします。

各段階で何を確認できたら次の拠点に進めてよいか

「使えている」と「回っている」は違う

一周目の拠点で画面から発注できるようになると、移行が済んだ気になります。
しかし操作できることと、その拠点の受発注が回っていることは別です。

具体的に見てほしいのは、保険の作業が残っていないかという点です。
オンラインで発注した後に、念のため電話で「送りました」と連絡していないか。
FAXの控えを取り続けていないか。
発注一覧を紙に印刷して手元で突き合わせていないか。
こうした作業が残っているうちは、現場はまだ新しい方式を信用していません。
信用されていない状態のまま次の拠点へ広げると、全拠点で二重作業が定着し、削減どころか手間が増えます。

見ておきたい観点

切り替え直後に見るのは、注文が相手に届いているかという一点です。
届いた注文に対して受注確認が返ってくるか、返ってこない場合に誰かが気づけるか。
ここが詰まっていると、以降の確認はすべて意味を失います。

しばらく経ってから見るのは、誤発注と欠品の発生状況です。
紙の時代と比べて増えていないか、増えていたなら原因は何か。
操作の迷いなのか、商品コードの対応付けなのか、承認が間に合わないことによる発注遅れなのか。
原因を分けて書き出しておくと、そのまま次の拠点で先回りして潰せる項目になります。

承認フローが実際に機能しているかも見ておきたいところです。
金額や数量で承認が必要になる設定にしていても、承認者が外出していて発注が止まるなら、現場は承認を通さない抜け道を探します。
承認待ちで止まった発注が何件あり、その間に現場が代わりに何をしたのかを拾うと、設定が実態に合っているかが見えます。

合格ラインの数字は自社で決める

誤発注が月何件以下なら次へ進んでよい、といった基準を示した資料は確認できていません。
実のところ、そうした数字は移行前の状態との比較でしか意味を持ちません。
紙の時代に月5件の誤発注があった拠点で移行後に月3件なら前進ですが、ほとんど誤発注のなかった拠点で月3件なら後退です。

だから一周目に入る前に、現状の誤発注・欠品・問い合わせの件数をざっくりとでも数えておきます。
移行後にその数字が悪化していないこと、悪化した場合には原因を説明できることが、次へ進む材料になります。
きれいな数字を出すことより、何が起きたかを説明できる状態を作る方が、二周目以降の役に立ちます。

電話・FAXとの並行運用はいつ・どう終えるか

期間で切るか、条件で切るか

並行運用をどのくらい続けるべきかについても、標準的な期間を示した資料は確認できていません。
「三か月」のような期間を計画に置くこと自体は分かりやすいのですが、期間だけで切ろうとすると、条件が整わないまま打ち切るか、期限が来ても延ばし続けるかのどちらかになりがちです。

扱いやすいのは、期間はあくまで目安として置き、終了するかどうかは条件で判断する組み方です。
期間は社内の予定を立てるために、条件は実際に止めてよいかを決めるために使う、と役割を分けます。

終わらない並行運用に共通すること

並行運用が終わらない拠点には、終了を決める人と条件がはっきりしていないという共通点があります。
誰も「この日からFAXは受け付けません」と言わないので、例外的にFAXで届いた注文も受け取り続けます。
受け取ってもらえるなら送る側も変える理由がないので、いつまでも両方が動き続けます。

終了条件として置きやすいのは、取引先への周知が済んでいること、その取引先からの注文が一定期間すべてオンラインで来ていること、オンラインで通らなかったときの代替手段が決まっていること、の三つです。
三つ目が抜けていると、通信や画面の不具合が起きた瞬間に全部が電話へ戻り、その後も戻ったままになります。
代替手段は「電話で受ける」でも構いませんが、受けた注文を誰がオンライン側へ入力し直すのかまで決めておく必要があります。

残す例外と、残さない例外

すべての取引先を同時に終えられるとは限りません。
小規模な取引先でオンラインでの受け取りが難しい場合、その取引先だけ従来の方法を続ける判断はあり得ます。
その場合は「FAXを残す」のではなく「この取引先はFAX」と相手を特定して残します。
相手が決まっていれば、残った件数も把握できますし、後から対応可能になった時点で個別に切り替えられます。

避けたいのは「急ぎのときは電話」のような、条件が人によって変わる例外です。
急ぎの定義は人ごとに違うので、実質的に電話が使い放題になり、オンライン側に注文の履歴が残りません。
履歴が欠けると、誤発注や欠品を調べるときに原因を追えなくなります。
急ぎの発注をオンラインでどう扱うか——締め時間の後の注文をどう出すか、緊急の連絡を誰に入れるか——を先に決めてしまう方が、例外を残すより後が楽になります。

拠点間でコードや承認フローをどこまで揃える必要があるか

揃える話が出てくる場面

拠点ごとに別々に発注していた時代は、商品の呼び方が揃っていなくても困りませんでした。
A拠点で「段ボール大」、B拠点で「箱L」と呼んでいても、電話とFAXなら相手が読み取ってくれます。
長く取引していれば、品番が曖昧でも通ってしまいます。

オンラインに移すと、この違いが表に出ます。
発注のデータは商品コードで動くので、拠点ごとに違うコードを使っていると、本部で全拠点の発注を合算できません。
取引先側でも、同じ商品が別物として扱われたり、該当なしで弾かれたりします。
つまりコードを揃えるかどうかは、移行そのものの可否というより、移行後に何を見たいかで必要度が変わる論点です。

二つの方向と、それぞれ重くなるところ

考え方は大きく二つあります。
全拠点で一つのコード体系に揃えるか、拠点ごとの既存の呼び方を残してシステム側で変換するか。
どちらが標準だと示した資料は確認できていないので、正解を探すより、それぞれどこが重くなるかを比べて選ぶことになります。

判断が分かれるのは、既存の基幹システムや在庫管理をどこまで触れるかです。
コードを揃えるというのは、拠点のマスタを書き換えるだけでなく、過去の発注履歴や在庫データをどう扱うかまで決めることを意味します。
一方、変換で逃げると移行は軽くなりますが、変換表の手入れが恒久的に残ります。
商品が入れ替わるたびに両方のコードを登録する人が必要で、その人が異動するとそこで止まります。

一周目は変換で始め、全拠点が移行し終わってから統一へ進む、という順にすることもできます。
ただし先送りした分、統一するときに触る範囲は広がります。
どちらを選ぶにしても、コードの登録を誰の仕事にするのかを決めておかないと、移行後に宙に浮きます。

承認フローは別に考える

コードと違って、承認フローは拠点ごとに違っていても取引先には影響しません。
発注が誰の承認を経て出されるかは社内の話なので、揃えなければ動かないというものではありません。

ただし、本部が全拠点の発注を見るのであれば、承認の有無や金額の線引きがばらばらだと具合が悪くなります。
同じ金額の発注が、拠点によって承認済みだったり未承認だったりするからです。
統制の観点で揃えたいのか、拠点の裁量を残したいのか——これは移行の技術的な論点ではなく、社内の決め事です。
一周目の拠点で設定を決めてしまうと、それが暗黙の全社標準になりがちなので、拠点を広げる前に本部として答えを出しておく方が後戻りが少なくなります。

自社の拠点構成に合わせて移行計画を組み立てる

期間は掛け算から崩していく

全拠点の移行がいつ終わるかについて、業種や規模ごとの標準期間を示した資料は確認できていません。
自社の一周目の実績から積み上げる以外に、確かな見積もり方はないというのが実情です。
素朴な出発点は「一サイクルに掛かった期間 × 残りの単位数」で、十二拠点を一拠点二か月で進めるなら二十四か月という計算になります。

ただしこの掛け算は上限に近い数字です。
製品の選定と計画の型は二周目以降に流用できるので、自社内の準備に掛かる時間は確実に短くなります。
短くならないのは取引先との調整と、現場が慣れるまでの時間です。
したがって、残りの拠点の取引先が一周目と重なっているかどうかで見積もりは大きく動きます。
全拠点が同じ取引先から仕入れているなら掛け算よりかなり短く済み、拠点ごとに地場の取引先が違うなら掛け算に近づきます。

期間を縮めたいなら、複数の単位を並行して進める選択もあります。
その際に効いてくる制約は、人手というより切り分けの可能性です。
二つの拠点で同時に不具合が出たとき、どちらの何が原因かを追える体制があるか。
追えないなら、同時に動かす数は一つに戻した方が、結局は早く終わります。

次へ進める判断を誰がするか

段階移行では、各周の終わりに「次へ進んでよいか」を決める人が必要になります。
拠点の担当者だけに委ねると、自分の拠点が落ち着いたかどうかの判断になり、次の拠点へ渡すべき学びが整理されません。
本部だけで決めると、現場に残っている保険の作業が見えないまま、順調だという前提で進んでしまいます。

現実的には、確認の材料を拠点が出し、進める判断は本部が行う形が収まりやすいところです。
拠点が出すのは、誤発注と欠品の件数、問い合わせの内容、そしてまだ電話やFAXで処理している取引の一覧。
本部はそれを前の周の拠点と並べて、同じ問題が繰り返されていないかを見ます。
繰り返されているなら、次の拠点へ進む前に手順書や説明資料を直す。
この往復があるかどうかで、三周目以降の負担がはっきり変わります。

費用面の後押しと、最後に決める四つのこと

一周目の費用で足が止まる場合は、公的な支援制度を当たっておく価値があります。
たとえばデジタル化・AI導入補助金のインボイス枠では、補助額50万円以下の場合、対象ソフトウェアが会計・受発注・決済のうち1機能以上を持つことが機能要件とされています²。
枠組みや要件は年度ごとに変わるため、申請する時点の公募要領で確認してください。

結局のところ、段階移行の設計で決めるのは、単位・順序・次へ進む条件・並行運用の終わり方の四つです。
どれも公的な正解があるわけではなく、自社の拠点数と取引先の構成によって答えが変わります。
一周目を「切り替えを一つ済ませる作業」ではなく「この四つを決めるための実地の検証」と位置づけると、二周目以降に何を持ち越せばよいかがはっきりします。
そして二周目の拠点に渡すものは、動くシステムだけでなく、一周目でつまずいた場所の一覧です。

一周目をどの単位で切るかは、拠点の規模だけでは決まらず、取引先の対応状況と仕入れの構造を並べて見ないと判断できません。社内だけで検討すると、説明しやすい主要拠点か、影響の小さい拠点かの二択に寄りがちです。

現在の発注の流れと、拠点ごとの取引先の重なり方を共有いただければ、どの単位なら一周目で結果を見届けられるか、調整の手間がどこに集中するかを一緒に書き出せます。無料相談で要件を整理する

要点の整理

軸	判断の基準
一周目の単位	確かめたいこと（取引先の対応可否か、現場の習熟か）が確かめられる規模か
移行前の把握	誤発注・欠品・問い合わせの件数を、着手前にざっくりでも数えてあるか
次へ進む条件	確認の電話やFAX控えなど保険の作業が消え、残る課題を説明できるか
並行運用の終了	周知完了・一定期間オンラインのみ・通らなかった時の代替手段の決定
残す例外	相手を特定した例外にする。条件が人によって変わる例外は残さない
コードの扱い	全社統一か拠点別＋変換か。いずれも登録・維持の担当を決めてから選ぶ
期間の見積もり	一サイクル×残り単位数を上限に、取引先の重なりと切り分け可能な人数で調整

二周目以降の負担を決めるのは、一周目で出た問題を手順へ戻せたかどうかです。並行運用の終了条件やコードの扱いは、拠点が増えてから直そうとすると触る範囲が広がります。 すでに動いている拠点の運用と、残る拠点の構成を見せていただければ、終了条件の置き方やコードの扱いをどの順で決めるべきか、判断に必要な材料を具体化できます。

よくある質問

一部の取引先だけ電話・FAXでの発注を続けたい場合、その拠点はどう扱えばよいか

取引先の都合で従来の方法が残ること自体は、その拠点の移行を止める理由にはなりません。
扱い方として整理しやすいのは、「FAXも残す拠点」ではなく「この取引先はFAX」と相手を特定して例外にする形です。
相手が特定されていれば、残っている件数も、オンライン化できていない発注の割合も把握できますし、その取引先が対応できるようになった時点で個別に切り替えられます。
逆に拠点単位で例外にすると、どの発注がなぜ従来の方法なのかが曖昧になり、現場が判断に迷った時の逃げ道になります。
なお、FAXで受けた注文をオンライン側にも登録するかどうかは、先に決めておく必要があります。
登録しない方針なら、本部で見える発注はその分だけ欠けることを前提に、集計の扱いを決めておきます。

パイロット拠点で問題が出た場合、他拠点への展開はどのタイミングで止めるべきか

問題が出たこと自体は止める理由になりません。
判断の分かれ目は、原因が説明できているかどうかです。
操作の迷いが原因で、手順書を直せば解消すると分かっているなら、直してから次へ進めます。
一方、注文が相手に届いていたのかどうかすら追えない、原因が操作なのかデータなのか切り分けられない、という状態であれば、次の拠点へ広げても同じことが起きるうえ、切り分けはさらに難しくなります。
この場合は展開を止めて、原因を追える状態を作るのが先です。
止める判断は拠点の担当者には重いので、どういう状態になったら止めるのかを、一周目を始める前に本部と合意しておくと実際に止められます。

拠点ごとに異なる受発注システム・ベンダーを使い分けても問題ないか

取引先側の事情でそうならざるを得ない場合があります。
特定の取引先が自社の仕組みを指定しているなら、その取引先と取引のある拠点だけ別の方式になることは起こります。
判断材料になるのは、本部が全拠点の発注を合算して見たいかどうかです。
見たいのであれば、仕組みが分かれた時点で、どこかで突き合わせる作業が発生します。
商品コードが拠点ごとに違えば、その作業はさらに重くなります。
使い分けが避けられないなら、せめて出力できるデータの形式と、誰がいつ突き合わせるのかを決めてから広げる方が、後から揃え直すより負担は軽くなります。

移行の進捗確認や次拠点への移行判断は、本部と拠点のどちらが担うべきか

材料を出すのは拠点、進める判断は本部、という分け方が実務的です。
拠点でなければ分からないのは、画面の外で何が起きているかです。
念のための電話が残っているか、承認待ちで止まった発注をどう処理したか、取引先から何を言われたか。
これは本部からは見えません。
一方、拠点だけで判断すると、自分のところが落ち着いたかどうかの話に閉じてしまい、次の拠点へ渡す学びが整理されません。
本部の役割は、前の周と今回を並べて同じ問題が繰り返されていないかを見ること、繰り返されているなら進む前に手順を直すことです。
どちらか一方に寄せると、進捗は見えても質が落ちるか、質は保てても止まるかのどちらかになります。

1. 1　出典：中小企業庁「企業間のデータ連携で、受発注の業務コストを削減する！（ミラサポplus）」（2020年）
2. 2　出典：独立行政法人中小企業基盤整備機構（中小企業デジタル化・AI導入支援事業事務局）「デジタル化・AI導入補助金2026 インボイス枠（インボイス対応類型）」（2026年度）
3. 3　出典：日経BP（日経クロステック）「中小企業の8割が『ファクスで受発注』の現実、DX時代に日本の競争力が失われる」（2019年）
4. 4　出典：つなぐITコンソーシアム「中小企業共通EDIとは（導入までの流れ）」（公開年不明）