EDI導入の期間は多拠点でどう見積もる？取引先ごとの調整から考える計画の立て方

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

B2B EC-COLUMN

EDIの導入期間は何で決まるのか：「拠点数」より取引先ごとの調整の積み上げ

拠点ごとにFAX・電話・メールで受けている受発注をEDIへ切り替える計画を立てると、まず「全拠点で何か月かかるのか」が書けずに止まります。
拠点数で期間を割り出しても、取引先や決裁者に説明できる根拠にはなりません。
確認できた事例で期間を動かしていたのは、取引先ごとの事前調整の積み上げでした。
ピップグループは1取引先あたり約1カ月かかり¹、ダイエーは取引先をカテゴリ別に段階導入して2,000社を最短1〜2カ月で移行しています²。
取引先・形式・基幹連携・拠点の運用差に分けて前提を置き、先行グループの実績で見積もりを更新するのが現実的です。

期間を取引先ごとの作業に分ける

複数拠点の導入計画で期間を考えるとき、まず拠点の数を数えたくなります。
工場や営業所ごとに端末を用意し、担当者に操作を覚えてもらう作業は、確かに拠点の数だけ発生します。
ただ、EDIは自社と取引先のあいだで注文や出荷のデータをやり取りする仕組みです。
ある取引先との注文データが実際に流れ始めるには、自社の拠点の準備が終わっているだけでは足りません。
その取引先と方式・項目・日程・テストを合わせる必要があります。

そのため、期間を数える単位は「拠点」より「取引先」に置くほうが説明しやすくなります。
取引先ごとに見ると、作業はおおむね、仕様と日程の事前調整、接続とテスト、旧方式との並行運用、利用開始という流れをたどります。
この一連の作業が取引先の数だけ並び、それを何件同時に進められるかで全体の長さが決まります。

一方で、基幹システムへの取り込みや、拠点ごとの業務の合わせ込みは、取引先とは別に自社側で進む作業です。
こちらは取引先の数では増えにくい代わりに、拠点ごとの運用の違いが大きいほど重くなります。
見積もりを「取引先ごとの調整の積み上げ」と「自社側の作業」の二本に分けておくと、計画が遅れたときに、どちらで遅れているのかを後から説明できます。

1取引先あたり約1カ月という事例の読み方

取引先単位の期間を考える手がかりになるのが、医薬品・健康食品の製造販売を手がけるピップグループの事例です。
同グループは約500の小売取引先とEDIを行っており、事前調整から利用開始までは1取引先あたり1カ月ほどかかると報じられています¹。
取引先ごとにスケジュールの調整が必要になる点も述べられています¹。

ただし、この数字は2016年の記事で、ISDN（INSネット）の終了に伴って既存のEDIの通信手段を切り替える場面のものです。
すでにEDIで取引している相手との切り替えであり、FAXや電話からの新規導入や、基幹システムの改修を含む導入にかかった期間ではありません。
自社の新規導入にそのまま当てはめると、調整以外の作業が抜け落ちた見積もりになります。

この事例から読み取りたいのは、1カ月という長さそのものより、期間の組み立て方です。
1社あたりの作業がそれほど長くなくても、相手ごとに日程を合わせる必要がある以上、取引先が増えれば作業は積み上がります。
1社ずつ順番に進めれば取引先の数がそのまま期間に効き、並行して進めれば、自社側で調整やテストを受け持てる人数が上限になります。

見積もりの式に置き直すと、全体の期間はおおよそ「取引先の数 × 1社あたりの調整から利用開始までの日数 ÷ 同時に進められる件数」に「自社側の作業」を加えたものとして考えられます。
これは事例から組み立てた見積もりの考え方で、原典が示した計算式ではありません。
それでも、どの数字を変えれば期間が縮むのかが見えるため、社内で人員や時期を相談するときの土台になります。

拠点の数が期間に効いてくるのは、この式の中です。
同じ取引先でも拠点ごとに納品先や発注の単位が違い、テストを拠点の数だけ繰り返す必要があるなら、実質的には「取引先×拠点」の組み合わせが調整の件数になります。
逆に、全拠点が同じ形式で同じ取引先とやり取りしていれば、拠点が増えても調整の件数はあまり増えません。
拠点数で延びると考えていた部分の多くは、取引先との調整の件数と、それを同時に何件こなせるかに置き換えて考えられます。

期限間際に切り替えが集中するリスク

同じ記事では、取引先ごとに個別の調整が必要なため、切り替えが期限間際に集中すると間に合わない取引先が出る懸念も示されています¹。
取引先から対応期限を示されている場合や、社内で稼働の目標日を決めている場合に、そのまま当てはまる注意点です。

1社あたりの作業が短く見えると、着手を後ろにずらしても間に合うように感じます。
しかし調整は相手の都合とこちらの体制の両方に縛られるため、後半に寄せるほど同時に進める件数が膨らみ、テストや問い合わせへの対応が重なります。
自社側の担当者が同じ人数のままなら、件数が重なった分だけ1社あたりの待ち時間が延びます。

期間を見積もるときは、終わりの日から逆算して「いつまでに何社の調整を始めておくか」を置いておくと、集中を避けやすくなります。
この逆算の組み方は、一斉に切り替えるか段階的に進めるかによって変わります。

▼ 図の内容を文字で読む

1. 仕様と日程の事前調整
2. 接続とテスト
3. 旧方式との並行運用
4. 利用開始

導入形態と標準仕様で、何が決まり何が決まらないのか

流通BMSと中小企業共通EDIが定めるもの

取引先との調整をどこまで軽くできるかには、使う形式が関わります。
受発注のデータの形や通信の手順を業界でそろえたものを標準仕様と呼び、代表的なものに流通BMSと中小企業共通EDIがあります。

流通BMSは、消費財流通業界の標準を目標に策定された、メッセージと通信プロトコル・セキュリティのEDI標準仕様です⁴。
導入した卸・メーカーは、2025年6月時点で21,600社以上と推計されています⁴。
取引先がすでにこの標準で受発注しているなら、メッセージの形や通信の手順を相手と一から取り決める部分は小さくなります。

中小企業共通EDIは、中小企業の受発注を対象にした標準です。
その標準仕様書は、EDIサービスを提供するプロバイダーに対応を求める注文メッセージとして全135項目を、自社が使う業務アプリケーションに最低限対応を求める項目として13項目（注文書番号、注文書発行日など）を定めています³。
やり取りする項目があらかじめ決まっているため、項目の取り決めから始める必要は減ります。

一方で、標準仕様が決めるのはデータの形とやり取りの手順までです。
受け取った注文を自社の基幹システムへどう取り込むか、どの拠点のどの担当者が処理するか、取引先といつテストし、いつ切り替えるかは、標準仕様の外にあります。
先ほどの見積もりの式でいえば、標準仕様は「1社あたりの調整」の中身を一部軽くする可能性はあっても、取引先の数や同時に進められる件数、自社側の作業は変えません。
標準仕様を採用したことで期間がどれだけ変わるかは、標準の内容からは導けないため、形式の選択は期間の長短ではなく、調整のどの部分を省けるかで考えるのが妥当です。

取引先が方式を指定している場合

取引先から特定の方式を指定されている場合は、選択の余地がそこで狭まります。
相手が流通BMSを指定していれば流通BMSで、相手が用意したWeb画面での受発注を求めていればその画面で対応することになり、自社にとって都合のよい標準より取引先の仕様が優先されます。

このとき期間を左右するのは、相手が示す接続の手順と日程です。
テストの時期や切り替えの順番を取引先側が決めていることもあれば、拠点ごとに順に切り替えたいのか、全拠点を同じ日にそろえたいのかが相手によって違うこともあります。
自社だけで期間を決めず、まず取引先ごとに仕様書、接続までの手順、希望する切り替え時期を集めることが見積もりの出発点になります。

自社が取引先へEDIでの接続をお願いする側なら、方式を決めるのは自社です。
その場合は、取引先が新しい方式に対応するまでの準備も期間に含めて考える必要があります。
反対に、取引先からの要請に応じる側では、相手の仕様が出発点になり、複数の取引先がそれぞれ別の方式を指定していれば、自社側の作業も方式ごとに分かれます。
取引先を方式ごとに分けておくと、その分け方がそのまま、次に考える進め方のまとまりになります。

▼ 図の内容を文字で読む

• 標準仕様で決まるもの
  • メッセージの形式と項目
  • 通信の手順とセキュリティ
• 標準仕様では決まらないもの
  • 基幹システムへの取り込み
  • 取引先との日程とテスト
  • 拠点ごとのコード・単位・締め日
• 取引先が方式を指定している場合
  • 自社に都合のよい標準より相手の仕様が優先
  • 接続の手順と日程は相手が示す

一斉切り替えか段階導入か：期間・負担・リスクの違いと、順番・並行運用の決め方

大規模移行の事例：カテゴリ別の段階導入

取引先が非常に多い場合の進め方の例として、ダイエーの流通BMS・EDI移行があります。
同社は取引先をカテゴリ別にまとめて段階的に進め、テストと並行運用を行いながら、最短1〜2カ月で2,000社の取引先を順次EDIへ移行したと紹介されています²。
移行にあたっては、日立製作所が問い合わせ窓口や移行支援を担いました²。

これは大手小売の事例で、ベンダーによる窓口と移行支援の体制がありました。
2,000社という規模を短期間で動かせた背景にはこの体制があり、中堅・中小の企業が同じ速さを前提に計画を組むのは適当ではありません。
また、ピップグループの1取引先あたり約1カ月という数字とは、年代も目的も支援体制も異なるため、二つの数字を割り算して比べたり、平均の目安をつくったりすることはできません。

それでも二つの事例を並べると、進め方について言えることがあります。
ピップグループの事例は、取引先ごとの調整が積み上がり、期限前に集中すると間に合わなくなる危険を示していました¹。
ダイエーの事例は、取引先を性質の近いまとまりに分け、テストと並行運用を組み込みながら順に進めることで、多くの取引先を移行しています²。
ここから読み取れるのは、段階導入は期間を縮めるための手段というより、調整とテストを同時に何件抱えるかを管理するための手段だということです。
これは二つの事例を対比した分析で、両方の進め方の期間を直接比べた統計があるわけではありません。

一斉切り替えが向く条件

一斉切り替えは、全拠点・全取引先を同じ日に新しい方式へ移す進め方です。
旧方式と新方式が混在する期間が短く、拠点の担当者が二通りの手順を使い分ける期間も短くて済みます。
反面、不具合や手順の誤りが全拠点で同時に表に出るため、問い合わせと修正が一度に集中します。

このため、一斉切り替えを選びやすいのは、次の条件がそろう場合です。
<ul><li>拠点間で受発注の業務や形式がほぼ共通している</li><li>取引先の数が少ないか、同じ方式・同じ窓口にまとまっている</li><li>切り替え後も旧方式と並行して動かし、問題があれば戻せる</li><li>切り替え直後の問い合わせを受けきれる体制がある</li></ul>

どれか一つでも欠けている場合、一斉切り替えは、すべてが同時に始まる代わりに、すべてが同時に止まるおそれを抱えます。
特に切り戻しの手段がないまま一斉に切り替えると、問題が出たときに全拠点の受発注が影響を受けます。

段階導入が向く条件

段階導入は、取引先や拠点をいくつかのまとまりに分け、順に切り替えていく進め方です。
次のような場合に向いています。
<ul><li>取引先ごとに方式や仕様が異なる</li><li>拠点ごとに商品コードや発注単位、締め日などの運用が違う</li><li>調整やテストを担当できる人数が限られている</li><li>取引先から示された期限が取引先ごとに異なる</li></ul>

その代わり、混在期間は長くなります。
どの取引先・どの拠点がすでに新方式に移り、どこがまだ旧方式なのかを管理する一覧が必要になり、拠点の担当者は取引先によってFAXとEDIを使い分けることになります。
段階導入を選ぶなら、混在期間をできるだけ短くする順番の工夫と、混在中に注文の受け漏れがないかを確かめる仕組みを計画に入れておきます。

拠点を順に入れる場合も、考え方は同じです。
同じ業務の流れで、同じ形で基幹システムとつながっている拠点をまとめ、運用のそろった拠点から先に切り替えると、先行した拠点で整えた手順を次の拠点へ持ち込めます。
これは事例で示された方法ではなく、取引先のまとめ方を拠点に当てはめた提案です。

先行グループの決め方

段階導入で最初に決めるのが、どこから始めるかです。
ここでは「調整に着手する順番」と「切り替える順番」を分けて考えると整理しやすくなります。
手順としては次のように進めます。
<ol><li>業務や形式が共通の取引先・拠点をグループにまとめる</li><li>調整の重い取引先は、切り替えの順番にかかわらず先に着手する</li><li>並行運用の終了条件と切り戻し条件を、切り替えの前に決める</li><li>先行1〜2グループの実日数で、残りの見積もりを更新する</li></ol>

調整の重い取引先に先に着手するのは、期限間際の集中を避けるためです。
独自の項目が多い、相手の担当窓口と日程が合いにくい、拠点ごとに別々のテストが要るといった取引先は、後ろに回すほど期限が迫った時期に作業が重なります。
着手だけを先にしておけば、切り替え自体は準備の整ったグループの後でもかまいません。

最初に切り替える先行グループには、形式が標準的で、自社の取引全体のなかで典型的な取引先や拠点を選ぶと、そこで得た日数や手順を残りに当てはめやすくなります。
規模の小さな取引先だけを先行させると作業は楽ですが、測った日数が残りの見積もりに使いにくくなる点には注意が必要です。

並行運用の期間と切り戻し条件

並行運用は、旧方式（FAXや電話、メールなど）と新しいEDIを一定期間同時に動かし、両方の内容を突き合わせて問題がないかを確かめる期間です。
ダイエーの事例でも、テストと並行運用を行いながら移行が進められています²。

並行運用の長さは、日数を先に決めるより、何を確かめ終えたら終えるのかで決めるほうが説明しやすくなります。
たとえば、注文の受け取りから出荷、請求までの流れが一巡し、拠点ごとの締め日を少なくとも一度またいで数字が合うことを確かめる、といった終了条件です。
締め日が拠点ごとに違うなら、最も遅い締め日を基準にしないと、一部の拠点で照合が終わらないまま旧方式を止めることになります。

同時に決めておきたいのが切り戻しの条件です。
どのような不一致や遅れが出たら旧方式に戻すのか、その判断を誰が下すのか、戻したあと再開するには何を直せばよいのかを、切り替えの前に取引先と共有しておきます。
条件が決まっていないと、問題が起きたときに戻すかどうかの相談から始まり、その間も拠点では二重の確認が続きます。

並行運用中、拠点の担当者は旧方式の注文と新方式の注文を見比べることになり、通常より手間がかかります。
期間を区切らずに続けると、その負担が拠点に残り続けるため、終了条件と切り戻し条件はセットで決めておくのが現実的です。

先行実績で見積もりを更新する

最初の見積もりで使う1社あたりの日数は、他社の事例か自社の推定にすぎません。
先行の1〜2グループを終えた時点で、調整を始めてから利用開始までに実際にかかった日数、同時に進められた件数、手戻りが起きた工程を記録し、残りのグループの見積もりをその実績に置き換えます。

ピップグループの約1カ月という数字は、最初の前提を置くための参考値にとどまります¹。
実績で置き換えた見積もりは、社内に対しても「先行グループの実績に基づく」と説明できるため、当初の数字より根拠が強くなります。
実績が当初の前提より長ければ、同時に進める件数を増やすのか、終了時期を見直すのかを、この時点で判断できます。

▼ 図の内容を文字で読む

• 一斉切り替えが向く条件
  • 拠点間で受発注の業務や形式がほぼ共通している
  • 取引先の数が少ないか、同じ方式・同じ窓口にまとまっている
  • 旧方式と並行して動かし、問題があれば戻せる
  • 切り替え直後の問い合わせを受けきれる体制がある
• 段階導入が向く条件
  • 取引先ごとに方式や仕様が異なる
  • 拠点ごとに商品コードや発注単位、締め日などの運用が違う
  • 調整やテストを担当できる人数が限られている
  • 取引先から示された期限が取引先ごとに異なる
• 並行運用で決めること
  • 終了条件
  • 切り戻し条件

▼ 図の内容を文字で読む

1. 業務や形式が共通の取引先・拠点をグループにまとめる
2. 調整の重い取引先は先に着手する
3. 並行運用の終了条件と切り戻し条件を決める
4. 先行1〜2グループの実日数で見積もりを更新する

基幹システムと拠点ごとの業務の違いは、見積もりにどう入れるか

基幹システムの取り込み範囲

取引先との調整と並んで期間を左右するのが、自社側の準備です。
まず決めるのは、EDIで受け取ったデータを基幹システムへどこまで自動で取り込むかです。
受け取った注文を画面で見て担当者が販売管理へ入力し直すのか、データとして取り込んで受注登録まで進めるのかで、必要な改修はまったく変わります。

中小企業共通EDIの標準仕様書は、業務アプリケーションに最低限対応を求める項目を13項目と定めています（注文書番号、注文書発行日など）³。
自社の基幹システムや販売管理がこれらの項目を受け止められるかどうかは、取り込みの範囲を考える一つの手がかりになります。
ただ、13項目は仕様上の最低限の項目数で、改修にかかる工数や期間を示すものではありません。
取り込みたい項目が最低限の範囲を超えるか、拠点ごとに別々のシステムを使っているかによって、作業量は大きく変わります。

改修の期間は、取り込みの範囲が決まり、社内のシステム担当者や開発会社が見積もるまで分かりません。
その段階で無理に数字を入れるより、見積もりの前提として「自社側の改修期間：未確定」と分けて書き、取引先との調整の期間とは別の行に置いておくほうが、後から数字が入ったときに全体を組み直しやすくなります。

拠点ごとのコード・単位・締め日の違い

複数拠点ならではの作業が、拠点ごとの運用の違いの洗い出しです。
たとえば、ある工場はケース単位で注文を受け、別の営業所は個数単位で受けている場合、同じ取引先からの注文データでも、どちらかの拠点では数量を換算しなければなりません。
取引先コードや商品コードを拠点ごとに独自に持っている場合や、締め日が拠点ごとに違う場合も、データを受け取ったあとで、どこかの拠点が手作業で読み替えることになります。

こうした違いへの対応は、二つに分かれます。
EDIの導入前に拠点間で統一するか、統一はせずに変換表などで読み替えるかです。
統一すれば運用はすっきりしますが、拠点の業務を変えるための社内の合意と移行の時間がかかります。
読み替えで吸収すれば導入は早まりますが、変換表を誰が保守するかという作業が導入後も残ります。

どちらを選ぶにしても、これは取引先との調整とは別の流れで進む作業です。
取引先との調整が順調でも、拠点のコードがそろっていないために切り替えられない、ということが起こりえます。
見積もりでは、拠点ごとの運用差の洗い出しと対応を、取引先の調整と並行して走る作業として別に置き、どの拠点にどの違いがあるかを一覧にしておくと、段階導入で拠点の順番を決めるときにも使えます。

▼ 図の内容を文字で読む

• 基幹システムへの取り込み範囲
  • 画面で見て担当者が入力し直す
  • データで取り込み受注登録まで進める
• 拠点ごとの運用の違い
  • ケース単位と個数単位の混在
  • 取引先コードや商品コードが拠点ごとに独自
  • 締め日が拠点ごとに違う
• 違いへの対応方針
  • 統一する：社内の合意と移行の時間がかかる
  • 読み替える：変換表の保守が導入後も残る

見積もった期間を社内外へ説明するときの前提条件

前提欄に入れる項目

ここまでの分解を、期間を説明するための前提欄にまとめます。
稟議資料では「何か月」という一つの数字を求められがちですが、前提を書かずに数字だけを出すと、取引先の対応が遅れたり改修の範囲が広がったりしたときに、なぜ延びたのかを説明できません。

前提欄には、少なくとも次の項目を書いておきます。
<ul><li>対象の取引先の数と、方式別の内訳</li><li>1取引先あたりの事前調整から利用開始までの日数（当初は他社事例の参考値、先行グループの後は自社の実績）</li><li>同時に進められる取引先の件数と、担当者の人数・兼務の状況</li><li>並行運用の終了条件と切り戻し条件</li><li>自社側の改修の有無と範囲（未確定ならその旨）</li><li>取引先が指定する方式の有無と、取引先が示す期限</li><li>拠点の運用差への対応方針（統一か読み替えか）</li></ul>

期間は一つの数字よりも、前提に応じた幅で示すほうが実態に合います。
たとえば、同時に進められる件数を少なく見た場合と多く見た場合の二通りを出し、どちらになるかは担当者の確保しだいだと書いておけば、決裁者は期間を短くするには何が必要かを判断できます。
あわせて、先行グループが終わった時点で見積もりを更新することも前提欄に明記しておくと、計画の見直しが予定どおりの手続きとして扱われます。

取引先への説明で確認すること

取引先に期間を説明するときも、同じ前提が役に立ちます。
ただし、社内向けとは確かめたいことが違います。
取引先には、次の点を聞いておくと前提欄が埋まります。
<ul><li>相手が希望する切り替えの時期</li><li>指定の方式と仕様書</li><li>テストの日程を誰と調整すればよいか</li><li>並行運用の間、FAXなどの旧方式とEDIの両方で送るのか</li></ul>

自社が取引先へEDIでの接続をお願いする側なら、自社の段階導入の計画のなかで、その取引先がどのグループに入り、いつ頃調整を始めたいかを伝えます。
取引先の側にも準備の時間が要るため、相手の都合で調整の開始がずれる可能性を前提欄に残しておきます。

取引先から要請を受けて対応する側なら、相手の期限に対して、自社の基幹システムの改修や拠点の準備がどこまで間に合うかを示します。
全拠点を一度にそろえるのが難しい場合は、どの拠点から順に対応できるかを具体的に示して相談すると、相手も自社の計画に組み込みやすくなります。
期限に間に合うと約束するより、何が整えば何月から対応できるかという形で伝えるほうが、計画が変わったときにも説明を続けられます。

▼ 図の内容を文字で読む

• 取引先に関する前提
  • 対象の取引先の数と方式別の内訳
  • 1取引先あたりの事前調整から利用開始までの日数
  • 取引先が指定する方式と示す期限
• 体制と自社側に関する前提
  • 同時に進められる件数と担当者の人数・兼務
  • 自社側の改修の有無と範囲
• 並行運用と拠点に関する前提
  • 並行運用の終了条件と切り戻し条件
  • 拠点の運用差への対応方針

取引先の方式や拠点ごとの運用の違いは、社内だけで整理しようとすると、どれを前提として固定し、どれを未確定として残すかで迷いやすい部分です。

取引先の一覧と拠点ごとの運用の違いを持ち寄って相談すると、どの取引先から調整に着手するか、前提欄に何を未確定として残すかを整理できます。無料相談で要件を整理する

要点の整理

軸	基準
期間を数える単位	拠点数ではなく、取引先ごとの事前調整から利用開始までの作業の積み上げ
期間を動かす要素	取引先の数、1社あたりの日数、同時に進められる件数、自社側の作業
標準仕様の役割	データの形とやり取りの手順を決める。基幹への取り込みや日程は決めない
一斉切り替え	業務と形式が共通で、並行運用と切り戻しができ、問い合わせを受けきれる場合
段階導入	方式や拠点の運用が異なる、担当者が限られる場合。調整の重い取引先から着手
並行運用	日数より終了条件で決め、切り戻し条件とセットにする
見積もりの更新	先行1〜2グループの実日数で残りを置き換える

先行グループを終えて見積もりを更新する段階では、実績の日数をどう読み、残りの計画へどう反映するかの判断が求められます。 先行グループで記録した日数や手戻りの内容をもとに相談すると、同時に進める件数や拠点の順番を見直すべきかどうかを確かめられます。

よくある質問

取引先から指定されたEDI方式がある場合、自社の導入期間はどう変わりますか。

方式を選ぶ手間はなくなりますが、期間はその取引先が示す接続の手順やテストの日程に左右されるようになります。
基幹システムへの取り込みや拠点の準備といった自社側の作業は、方式が指定されていても残ります。
複数の取引先がそれぞれ別の方式を指定している場合は、自社側の作業も方式ごとに分かれるため、取引先を方式別にまとめてから見積もると整理しやすくなります。

一斉切り替えのとき、並行運用の期間はどのように決めればよいですか。

日数を先に決めるより、何を確かめ終えたら旧方式を止めるかという終了条件で決めるのが説明しやすい方法です。
注文から出荷、請求までの流れが一巡し、拠点ごとの締め日をまたいで数字が合うことを確かめる、といった条件が考えられます。
一斉切り替えでは不具合が全拠点で同時に出るため、どのような不一致が出たら戻すのか、誰が判断するのかという切り戻し条件も、切り替え前に決めて取引先と共有しておきます。

拠点ごとにコードや締め日が違う場合、先に何を統一すべきですか。

すべてを先に統一すべきとは限りません。
まず、どの拠点にどの違いがあるかを一覧にします。
取引先コードや商品コード、発注の単位のように、受け取ったデータの読み替えに直結するものは、導入前に統一するか変換表で吸収するかを決めておく必要があります。
締め日は、並行運用をいつ終えられるかに関わるため、統一しない場合は最も遅い締め日を基準に並行運用の終了条件を置きます。

1取引先あたり約1カ月という目安は、受注側の企業にも当てはまりますか。

そのまま当てはめることはできません。
この数字は2016年に報じられた1社の事例で、ISDN（INSネット）の終了に伴って既存のEDIを切り替える場面のものです。
受注側の企業による新規導入や、基幹システムの改修を含む導入を前提にした数字ではありません。
受注側では取引先が示す手順と日程に期間が左右されるため、最初の前提を置くための参考値にとどめ、自社の先行グループの実績で置き換えるのが確実です。

稟議資料では、期間をレンジで示すべきですか。前提条件はどう書けばよいですか。

一つの数字より、前提に応じた幅で示すほうが実態に合います。
同時に進められる件数を少なく見た場合と多く見た場合の二通りを出し、取引先の数、1社あたりの日数、並行運用の終了条件、自社側の改修の有無、取引先指定の方式と期限、拠点の運用差への対応方針を前提欄に書いておきます。
先行グループの完了後に見積もりを更新することも明記しておくと、後の見直しを計画どおりの手続きとして説明できます。

1. 1　出典：日経BP（日経クロステック）「ISDN移行のハードルは業界によって様々、EDIなどは早期対応が必要」（2016年）
2. 2　出典：日立製作所「ダイエー様 流通BMS/EDI移行事例」
3. 3　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年）
4. 4　出典：一般財団法人流通システム開発センター（GS1 Japan）／流通BMS協議会「流通BMS トップページ」（2025年）