オンライン受発注システムへの移行、取引先の優先順位はどう決める?段階移行と並行運用の進め方

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

B2B EC-COLUMN

なぜ取引先を一度に移行せず、段階に分ける必要があるのか

取引先とのオンライン受発注への切り替えを任され、全社を一度に動かすのは無理だと分かったところで、どこから声をかけるかで手が止まっていないでしょうか。
取引量の大きい順か、システムに慣れている順か、と並べ始めても決め手が出てきません。
ここで変えられるのは、順位の付け方ではなく割り当て方です。
受発注の切り替えは相手のある作業で、1社ずつ日程を合わせて進めるほかありません¹。
そのため決めるべきなのは「どの属性を先にするか」ではなく、1社あたりに何週間かかるかを見積もり、月ごとに抱える件数が偏らないように配ることです。
取引量やIT対応力の差は、順位ではなく所要期間の見積もりに反映させます。

切替日は自社で決められても、1社ごとの準備は相手の予定で動く

受発注の切り替えは、自社のシステムを立ち上げれば終わる作業ではありません。
取引先の側でも、発注担当者にログイン情報が渡り、いつも使っている品名と画面上の商品コードが突き合わされ、発注単位や単価の表示が普段の取引と合っているかを見てもらう必要があります。
ここで数字の見え方が普段と違えば、相手は発注そのものを止めます。
だから切替日は自社の都合だけでは置けず、相手の締め日や繁忙期、社内で注文を承認する手順に合わせて動かすことになります。

流通業界で企業間EDIをインターネット経由の方式へ移す動きが進んでいた2016年の時点で、ピップグループの担当者は、EDIの切り替えは小売店1社ずつとスケジュールを合わせて取り組まなければならないと述べています¹。
注文を出す側と受ける側の両方が同じ日から新しい経路を使い始めなければ、注文は届きません。
この「1社ずつ日程を合わせる」という性質が、一斉切替を難しくしている正体です。

自社の側から1社分の作業を並べると、打診、日程の調整、マスタの登録、テスト発注、最初の何回かの注文の見守り、という流れになります。
このうち自社だけで進められるのはマスタの登録くらいで、残りは相手の返事を待つ時間を含みます。
同時に十社へ声をかければ、十社分の待ちと確認が並行し、担当者は返事が来た順に対応することになります。
案内を出す作業は一度で済んでも、そこから先は件数分だけ増えていきます。

後ろに残した分ほど、期限の直前に効いてくる

移行に期限がある場合は、この積み上がりがそのまま結果に出ます。
旧システムの保守が終わる、通信方式が使えなくなる、取引先から一定の時期までに対応してほしいと要請される——理由はさまざまですが、期限が決まっていれば、そこまでに何社を通せるかという計算になります。

先の2016年の記事では、残りの取引先の移行が2020年度後半の切替直前に集中すると間に合わない取引先が出てくること、逆に今後の移行数が平準化すれば対応できる見込みであることが語られています¹。
これは流通業界のEDI移行という特定の場面で、期限が示されていた状況の話です。
ただ、示している構造そのものは単純です。
1か月に対応できる件数には上限があり、その件数と期限までの月数の積が、期限までに移し終えられる社数の上限になります。

段階に分ける理由は、慎重に進めたいからではありません。
同時に抱えられる件数が限られているために、分けるしかないというのが実際のところです。
そう考えると、最初に決めるべきなのは「どの取引先を上に置くか」ではなく、「自社は1か月に何社まで面倒を見られるか」になります。
この問いに答えを出さないまま順位表を作っても、上から順に呼びかけた結果、後半が渋滞します。

取引先の優先順位は「属性ランキング」ではなく「対応期間の平準化」で考える

取引量・IT対応力は順位ではなく所要期間の見積もりに使う

優先順位を考え始めると、多くの場合、取引量の大きい順に並べるか、システムに慣れている順に並べるかで迷います。
ところが、どちらにも理屈が立ちます。
大口から始めれば効果は早く出ますが、最初の不具合がいちばん影響の大きい相手で起きます。
小口から始めれば練習になりますが、手間の割に社内向けの成果が見えにくく、重い相手が後半にまとまって残ります。

この二つを比べても決着がつかないのは、どちらを選ぶかで変わるのが「効果の出方」と「危険を置く場所」であって、「期限までに終わるかどうか」ではないからです。
終わるかどうかを左右するのは、期限までの各月に、対応しきれる件数だけが入っているかどうかです。
先の事例で語られていた見通しも、移行数が平準化すれば対応できる、というものでした¹。
取引量や注文頻度の多い方から着手すべきだという型が決まっているわけではなく、ここでは実例で確認できたこの考え方を軸に置きます。

では取引量やIT対応力の情報は使わないのかというと、使います。
使う場所が、順位ではなく所要期間の見積もりに変わります。
取り扱う商品点数が多く、納品先が複数あり、単価が個別に組まれている取引先は、マスタの準備とテストの範囲がそのぶん広がります。
普段の受発注をすべて紙と電話で回している取引先は、操作の説明と、最初の数回の注文を見守る期間が長くなります。

見積もりを期間に置き換えると、順序は自然に決まってきます。
重い相手を同じ月に二社も三社も入れないように配り、軽い相手で隙間を埋める、という組み方です。
結果として大口が先に来る月もあれば、後ろへ回る月もありますが、それは属性で決めたのではなく、その月の負荷で決まった結果です。
社内で順序を説明するときも、「なぜあの取引先が後なのか」に対して、月ごとの件数という共通の物差しで答えられます。

スケジュールは取引先ごとに個別調整する

案内そのものは一斉に出せます。
けれども切替日は、1社ずつ決めることになります¹。
打診のときに相手が知りたいのは、いつから新しい方法で出せるのか、何がどう変わるのか、これまでの電話やFAXはいつまで受けてもらえるのか、自社の誰が操作することになるのか、という四点です。
ここが曖昧なまま「移行にご協力ください」と伝えても、相手は社内で日程を組めません。

相手側の事情で日程が動く要素も見込んでおきます。
月末月初の締め処理と重なる時期、決算期、担当者の交代、相手自身が抱えているシステム改修などです。
打診から返事が返るまでの待ち時間は、自社の作業時間ではありませんが、割り当てた期間の中に含まれます。
「返事待ちの期間があるから、その月は三社まで」という数え方をしておくと、見積もりが崩れにくくなります。

ここで参照している裏付けは、2016年時点の流通業界における企業間EDI移行の事例です¹。
業種が変われば、1件あたりの調整の重さも、1か月に扱える件数も変わります。
自社にとっての適正な件数は、最初のグループを実際に移してみて、打診から利用開始までに何週間かかったかを記録するのがいちばん確かです。
最初の数社は、移行そのものと同時に、見積もりの物差しを作る作業でもあります。

取引先のIT対応力(電子受発注への準備状況)は所要期間の見積もりにどう影響するか

相手が電子のやり取りに慣れているとは限らない

IT対応力という言葉で思い浮かぶのは、相手がブラウザを使えるか、社内にシステム担当がいるか、といった点でしょう。
ただ、日程に効いてくるのはもう少し手前の事情です。
中小商業・サービス業を対象にした調査では、「電子文書での商取引や受発注情報管理」を導入している企業は18.5%にとどまり、2割を下回っていました²。

この数字は2018年に公表された調査によるもので、中小の商業・サービス業を全体として平均したものです²。
目の前の取引先が電子化できているかどうかを直接示すものではありませんし、業種による差もあります。
それでも、取引先の一覧を眺めるときの構えは変わります。
「たいていの会社はもう電子で処理しているはずだ」という前提で日程を詰めるより、紙と電話で受発注を回している会社が相応に混じっている前提で期間を見積もるほうが、後になって崩れません。

何を聞けば所要期間が読めるか

対応力を測るために聞くべきなのは、機器や回線のことよりも、いま実際にどうやって注文を出している(受けている)かです。
仮に、外回りの担当者が客先から電話で自社へ連絡し、内勤者がそれを注文書に書き起こしてFAXしている取引先があったとします。
この場合、オンライン化で変わるのは内勤者の作業ではなく、外回りの担当者がその場で画面に入力するのかどうかです。
誰の作業がいつ変わるのかが決まらないと、テスト発注の日程も組めません。

商品の呼び方も、期間を左右する分かれ目になります。
取引先が社内で使っている略称や旧品番と、こちらの商品コードが一対一で対応していないことは珍しくありません。
この対応表を自社が作って渡すのか、相手に作ってもらうのかで、必要な期間はかなり変わります。
相手に任せる場合、相手の担当者がその作業に割ける時間は、こちらからは見えません。

対応力が低いと見込んだ取引先ほど、テスト発注から本稼働までの見守りを長く取ることになります。
その分、同じ月に入れられる他社の数は減ります。
対応力の情報を順番を下げるために使うのではなく、その相手に何週間を割り当てるかを決めるために使う、というのはこういう意味です。
不慣れな相手を後ろへ回しても、期間が短くなるわけではなく、期限の近い月に重い荷物を置き直すだけになります。

移行期間中、旧来の受発注方法とどう並行運用し、過去データはどこまで引き継ぐか

並行稼働期間の目安

新しい経路で注文が入り始めても、その日から電話とFAXを止められるわけではありません。
販売管理システムのデータ移行について書かれた実務解説では、並行稼働期間の目安を6〜8週間とし、月次の締め処理を2回またぐ設計が勧められています³。

締めを2回またぐのには理由があります。
月次の締めは月に一度しか回りません。
1回目の締めで、新しい経路から入った注文が請求金額や数量に正しく反映されているかを突き合わせ、ずれていた箇所を直します。
2回目の締めは、直した状態で同じ処理がもう一度通ることを確かめるためのものです。
1回だけで終えると、たまたま通ったのか、手を入れたから通ったのかが区別できません。

この目安は販売管理システム全般のデータ移行を想定したもので、取引先ごとに切り替えていく受発注の移行に特化した記述ではありません³。
契約の内容やデータ量によっても動きます。
それでも、締めを2回通すという考え方は、取引先1社ごとの並行期間を決めるときの土台に使えます。
逆にいえば、締めをまたがない短さで旧方式を打ち切ると、請求段階のずれを本番で見つけることになります。

並行期間でいちばん起きやすいのは、同じ注文が両方の経路から届くことです。
相手の社内で、新しい画面を使い始めた担当者と、これまで通りFAXを送る担当者が並んでいれば起こります。
どちらを正式な注文として扱うかを切替日の前に決め、片方が届いたときに自社の誰が気づくのかまで決めておくと、締めのときに二重計上を探す作業が減ります。
ただし、届いた二件が同じ注文なのかどうかの確認は残ります。

並行期間が取引先ごとにずれて始まるということは、自社側は長い期間、二つの運用を同時に抱えるということでもあります。
前の節で見た平準化は、ここにも効いてきます。
同じ月に何社も切替日を重ねれば、その翌月と翌々月の締めに、突き合わせ作業がまとめて乗ってきます。
1か月に何社まで抱えられるかを数えるときは、新しく着手する件数だけでなく、まだ並行期間が終わっていない件数も一緒に数えておきます。

過去データの移行範囲

過去のデータをどこまで新しい仕組みへ持っていくかも、期間を左右します。
先の実務解説では、直近1〜2年分の月次集計データ(取引先別売上、商品別売上)を新システムへ移行し、それ以前はCSVやBIツールで参照する設計が挙げられています³。

全部入れたくなるのは、後から見られなくなるのが怖いからです。
ただ、入れたデータはそのまま検証の対象になります。
件数が増えるほど突き合わせに時間がかかり、古い時期の商品コードや取引先コードが現在と違っていれば、その読み替えも必要になります。
「新しい画面で何を見たいのか」から逆算すると、前年同月比や取引先別の実績が見られれば足りる場面は少なくありません。

受発注の移行では、もう一つ確かめておくことがあります。
取引先が、前回の注文内容を見ながら次の発注を出している場合です。
その参照を新しい画面の中で行うのか、当面は従来の帳票や自社からの連絡で行うのかを決めておかないと、切替の直後に「前回何をいくつ頼んだか分からない」という問い合わせが来ます。
これは自社の都合ではなく相手の作業の話なので、打診の段階で聞いておく項目に入ります。

なお、新しいシステムへ何年分を入れるかという話と、帳簿や書類を何年保存するかという話は別のものです。
保存の年限は法令や契約で定まりますから、移行の範囲を絞る場合は、範囲外のデータをどこで参照できるようにしておくかを先に決めます。
旧システムを止める時期も、この参照手段が用意できてからになります。

取引先数の規模に応じて、受発注システム側の対応可否をどう確認するか

トライアルで確認できる上限

段階移行を前提にすると、システム側にも確認しておくことが出てきます。
最初のグループでは問題なく動いたのに、取引先を増やしていった先で上限に当たる、という事態を避けるためです。
試用の枠と本番で必要な件数は、別々に見ておきます。

自社が提供しているEC-Rider Primoを例にすると、無料トライアルで登録できるのは商品500 SKU、取引先50件、ユーザー5名です⁴。
最初のグループを数社から十数社で始めるのであれば、この範囲で実際の注文の流れを一通り確かめられます。

試用の段階で見るべきなのは、件数そのものではありません。
相手の画面に単価がどう表示されるか、発注単位や最低数量の扱いが普段の取引と合っているか、締めのタイミングで自社側にどう注文が並ぶか、といった点です。
ここが普段のやり取りの感覚と合っていれば、打診のときに相手へ説明できることが増え、質問も具体的になります。
逆に、ここで自社の商習慣と合わない部分が見つかれば、それは1社あたりの所要期間に足しておく項目になります。

本契約時に必要な取引先数への対応

本番で必要になる件数は、試用の枠とは切り離して確認します。
同じくEC-Rider Primoのクイックビジネスプランでは、商品30,000 SKU、取引先10,000件、ユーザー5名が上限として示されています⁴。
これは2026年時点で公開している自社プランの条件で、他社の受発注システムでは区切り方も数え方も異なります。
他社と並べて検討する場合は、取引先の数え方(拠点単位か法人単位か)まで揃えて比べないと、見かけの上限だけでは判断できません。

規模の感覚をつかむために、事例を一つ挙げます。
日東電工CSシステム株式会社は、日東電工グループの一員として工業用粘着テープやテープ貼り機器を中心に製品の提案・販売を手掛けており、全国約3,000社の販売店が同社の製品を取り扱っています⁵。
同社はEC-Rider B2Bを導入することで、要件定義からテストサイト開設までを約10カ月に短縮しています⁵。

この10カ月は、要件定義からテストサイトを開くまでの期間です⁵。
約3,000社の販売店すべてが新しい経路へ移り終わるまでの期間ではありません。
段階移行の計画を立てるときは、「システムが使える状態になるまで」と「取引先が使い始めるまで」を分けて見積もる必要があります。
前者は自社とベンダーの作業なので短縮の余地がありますが、後者は1社ずつの日程調整が積み上がる部分です¹。

段階移行では、取引先の登録が月ごとに増えていきます。
そのため、上限の件数だけでなく、増やしていく途中の運用も確認の対象になります。
まだ移行していない取引先を先に登録しておけるか、グループごとに公開する商品や価格の範囲を分けられるか、操作するユーザーの数が増えたときにどう扱われるか、といった点です。
ここを契約前に押さえておくと、第2グループに入った段階で運用を組み直す手間を避けられます。

順序の決め方と並行運用の考え方はここまでです。
最後に、1社ごとの期間を見積もるときに実際へ確かめる項目を並べておきます。

月ごとに何社まで抱えられるかは、机上で決めるより、1社分の作業を実際に通してみたほうが早く定まります。<br>取引先へ渡す画面の見え方や登録の手順が分からないと、所要期間の見積もりに置く数字の根拠が作れません。

無料トライアルの範囲で、最初のグループに相当する取引先数と商品点数を登録し、発注から締めまでの流れを試せます。<br>1社あたりに何の作業が残るのか、自社の商習慣と合わない部分がどこかを、打診の前に洗い出せます。無料相談で要件を整理する

1社あたりの所要期間を見積もるときに確かめること

移行の順位を付けるためではなく、取引先1社ごとに何週間を割り当てるかを見積もるための確認項目として並べています。

• 相手の側で発注を出すのは誰か。いまはどの手段で出しているか

• 自社の商品コードと、相手が社内で使っている呼称や旧品番の対応表を誰が作るか

• 相手の締め日と繁忙期。切替日を避けたい時期はいつか

• 単価や納品先が個別に組まれているか。マスタ登録の範囲はどこまでか

• テスト発注から本稼働まで何回の注文を見守るか。従来方式を並行で受ける期間はどこまでか

• 打診してから返事が返るまでの待ち時間を、誰の予定として確保しておくか

長くかかると見込んだ取引先は、後ろへ回すのではなく、同じ月に他社を重ねない形で配ります。

要点の整理

軸	基準
移行順序の決め方	属性の順位付けではなく、月ごとの移行件数が偏らないよう割り付ける
取引量・IT対応力の使い道	順位ではなく、1社あたりの所要期間の見積もりに反映する
日程調整の単位	取引先1社ごと。相手の締め日と繁忙期に合わせて切替日を置く
並行稼働の長さ	月次締めを2回またぐ置き方が目安(販売管理システムのデータ移行での目安)
過去データの範囲	直近1〜2年分の月次集計を移し、それ以前は別の手段で参照する設計が挙げられている
システム側の確認	本番の取引先数が上限に収まるか、登録を増やしていく運用に耐えるか

全取引先を載せたときに上限へ収まるか、移行の途中で登録を増やしていく運用に耐えるかは、公開している数字だけでは判断しきれない部分が残ります。<br>取引先の数え方や、グループごとに公開範囲を分けたいかどうかで、確認すべき点が変わります。 現在の取引先数と商品点数、段階移行で想定しているグループの分け方を伝えていただければ、どのプランの範囲に収まるか、どこが個別の確認事項になるかを一緒に整理できます。<br>移行を始める前に、期間の見積もりに入れておくべき項目がはっきりします。

よくある質問

取引先の合意が得られず移行が進まない場合、いつまで旧来方式(電話・FAX)を続けてよいか

一律の期限はありません。
判断の起点になるのは、自社側に動かせない期限があるかどうかです。
旧システムの保守終了など外から決まっている期日があれば、そこから逆算して、いつまでに合意が必要かを相手へ具体的な日付で伝えることになります。
そうした期日がない場合は、並行運用を続ける負担が判断材料になります。
二つの経路を受け続けるかぎり、注文の取り違えを防ぐ確認と、締めのときの突き合わせが毎月残ります。
合意が取れない取引先は、無理に同じ月へ押し込まず後ろのグループへ移し、空いた枠へ別の取引先を入れるほうが、全体の進みは落ちません。

段階移行を始める最初のグループには、どんな取引先を選ぶとよいか

取引量の多い先から、あるいは少ない先から、と決まった型があるわけではありません。
最初のグループで得たいのは成果よりも見積もりの物差しなので、日程を合わせやすく、注文の頻度がある程度あって、締めまでの検証が1か月で回る相手が向いています。
注文が数か月に一度しかない取引先だと、テスト発注から締めの確認までに時間が空き、何が起きるかを確かめるのに時間がかかります。
この段階で、打診から利用開始までに実際に何週間かかったかを記録しておくと、以降の月ごとの割り付けが具体的な数字になります。

移行後、旧システムや旧データはいつまで保持しておくべきか

新しいシステムへ入れる範囲と、保存しておく範囲は分けて考えます。
移行の範囲については、直近1〜2年分の月次集計データを新システムへ移し、それ以前はCSVやBIツールで参照する設計が挙げられています³。
一方、帳簿や取引書類を何年保存するかは法令や契約で定まるもので、システムの都合では決められません。
旧システムを止める時期は、範囲外のデータを別の形で取り出せる状態にし、実際に必要な期間のデータを開いて確認できたあとになります。
参照手段の用意ができる前に停止すると、問い合わせのたびに取り出せる人を探すことになります。

取引先数が数十社程度と少ない場合でも、段階分けは必要か

社数が少なくても、切替日を1社ずつ相手と合わせる必要がある点は変わりません¹。
数十社を一斉に動かせば、返事待ちと確認がその月にまとめて発生し、切替後は並行期間の突き合わせも重なります。
ただし、社数が少なければグループを細かく刻む必要はありません。
1か月に何社まで抱えられるかを見積もり、その数で割った月数を確保できれば十分です。
数十社で月に数社ずつなら、数か月の計画になります。
期限がない場合でも、並行期間が同じ月に集中しないことを目安に配っておくと、締めの作業が平らになります。

1. 1　出典：日経クロステック(xTECH)「ISDN移行のハードルは業界によって様々、EDIなどは早期対応が必要」（2016年）
2. 2　出典：日本政策金融公庫総合研究所（ミラサポplus掲載）「中小商業・サービス業におけるIT利活用の現状と課題（日本公庫総研レポートNo.2018-3）」（2018年）
3. 3　出典：株式会社ripla「販売管理システムのデータ移行を成功させる5ステップ」（2026年）
4. 4　出典：株式会社フライトソリューションズ「EC-Rider Primo 料金・プラン」（2026年）
5. 5　出典：株式会社フライトソリューションズ「EC-Rider B2B 導入事例（日東電工CSシステム株式会社様）」（掲載時点）