◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 取引先ごとにWeb-EDI画面が違うのは自社の運用の問題ではなく、個社仕様のWeb-EDIが広がったことが原因で、流通業界では団体が抑制の対象として扱ってきた
- 一次資料で道筋を確認できる集約の経路は、取引先側の業界標準への切り替えを待つ方法と、共通EDI規格に対応したプロバイダーを介す方法の二つ
- どちらも自社だけでは完結せず、取引先の切り替えか、双方が同一標準対応のプロバイダーと契約することが前提になる
- 自社側だけで動かせるツールは存在するが、対応範囲と費用は公的資料では裏付けられず、個別のベンダーへの確認が要る
- 最初の一歩は製品の比較ではなく、取引先ごとの画面と注文件数の棚卸し、対応規格と切り替え予定の確認
目次
取引先ごとに違うWeb-EDI画面がなぜ負担になるのか
A社のポータルで当日分の注文を開き、B社は別のIDで入ってCSVを落とし、C社は画面を見ながら自社システムへ手で打ち込む。
同じ「注文を受ける」仕事なのに入口も操作も相手ごとに違えば、見落としが起きるのは担当者の不注意ではありません。
取引先ごとにWeb-EDIがばらばらなのは各社が個社仕様で構築してきた結果で、流通業界では団体自身が抑制すべき課題として扱ってきた経緯があります2。
一次資料で道筋を確認できる集約の方法は、取引先側が業界標準へ切り替えるのを待つ形と、共通EDI規格に対応したプロバイダーを介して使い慣れたアプリで統一データを扱う形の二つです1。
どちらも自社だけでは完結しないため、出発点は取引先側の対応状況を確かめることになります。
画面が増えるほど、どこで時間と注意が削られるのか
受注を担当していると、一日の始まりが取引先の数だけのログインになります。
A社のポータルでIDとパスワードを入れて当日分の注文を開き、B社は別のIDで入ってCSVをダウンロードし、C社は一覧をスクロールしながら自社の受注システムへ品番と数量を打ち込む。
「今日の注文を確認して社内に流す」という一つの仕事が、相手の数だけ別々の手順に分かれている状態です。
作業そのものは難しくありませんが、切り替えのたびに頭の中の段取りを入れ替える必要があり、そこで時間が削られていきます。
厄介なのは、画面の枚数そのものよりも、画面ごとに細かい決まりが違うことです。
注文番号の桁数も、品番の表記も、数量の単位の置き方も相手ごとに異なり、ダウンロードできるCSVの列の並びもそろっていません。
締め時刻や、訂正注文がどこに出るかも各社の設計次第で、A社では一覧の色が変わるだけ、B社では別のメニューに入らないと見えない、ということが起こります。
その結果、担当者の頭の中には「この取引先ではここを見る」という個別の約束事が何本も並ぶことになります。
確認漏れは、この約束事の本数が増えたところで起きます。
画面が一つなら「未確認の注文が残っているか」を一目で判断できますが、画面が分かれていると、どこまで見たかの記録も画面ごとに分かれます。
五つの取引先を回っている途中で電話が入り、戻ったときに四つ目まで終わっていたのか三つ目までだったのかが分からなくなる、という詰まり方は、注意深さでは埋めきれません。
減らせるのは注意の量ではなく、確認先の数そのものです。
もう一つ、見えにくい負担として引き継ぎがあります。
個別の約束事は担当者の経験として溜まるため、休暇や異動のたびに、画面の数だけ説明が必要になります。
手順書を作っても、発注側が画面の仕様を変えれば書き直しが発生し、更新が追いつかなくなる。
ここまで来ると、問題は「慣れているかどうか」ではなく、仕組みの形そのものにあると分かります。
個社仕様のWeb-EDIが増えてきた経緯
なぜ取引先ごとに画面が違うのかというと、Web-EDIが発注側の都合で作れる仕組みだからです。
受発注のデータ交換は、どの項目をどんな形式で送るかという取り決めがあって初めて成り立ちますが、ブラウザで完結するWeb-EDIは、その取り決めを発注側が自社の業務に合わせて設計できます。
自社の基幹システムに合った項目名を並べ、自社の運用に合った締め時刻を置く。
発注側から見れば合理的な作りであり、その積み重ねが受注側の画面の数になっています。
この状況は、業界の側でも早い段階から問題として扱われてきました。
流通BMS協議会は、個社仕様のウェブ-EDIの蔓延を抑制するべく2010年度にウェブ-EDI検討部会を設置し、2011年3月に基本方針を策定・公開、2012年3月にガイドラインV1.0を公開しています2。
受注側の現場が日々感じている負担が、業界団体が公式に抑制の対象として掲げるほどの広がりを持っていたということです。
ここで範囲を一つ確かめておくと、この取り組みが対象にしているのは流通業界、つまり小売と卸の取引です。
すべての業界に同じ枠組みがあるわけではないため、自社の取引が流通以外であれば、そのまま当てはめることはできません。
それでも、画面がばらばらになる原因が自社の運用や担当者の習熟にあるのではなく、相手側の仕様の違いにあるという見立ては変わりません。
だとすれば、解決の向きは「操作に慣れる」ではなく「相手から届くデータの形をそろえる」側にあります。
出典：流通システム開発センター（流通BMS協議会）「流通ＢＭＳにおけるWeb-EDI」／対象は流通業界（小売・卸）の取引
画面を集約する方法にはどんな選択肢があるか
「画面をまとめる」より先に「データをそろえる」
集約と聞くと、複数のWeb-EDIを一枚の画面に並べて見られるようにする姿を思い浮かべがちです。
ただ、実務の負担を決めているのは画面の枚数よりも、そこから先の扱いです。
一枚にまとまって見えても、A社の品番とB社の品番が違う形のままなら、自社システムへ入れる前の読み替えは残ります。
逆に、届くデータの項目と形式がそろっていれば、経由する画面がいくつあっても、自社側の作業は受信したデータを取り込むところに一本化できます。
つまり判断の軸は、「一つの画面で見られるか」ではなく「自社が普段使っているアプリケーションで、読み替えなしに扱えるか」です。
この軸に置き換えると、選択肢は、相手が送ってくるデータの形そのものをそろえる方向と、間に立つ誰かが形をそろえて渡してくれる方向に分かれます。
どちらを向いても、自社の画面操作を工夫する話からは離れていきます。
一次資料で道筋を確認できる二つの経路
一つ目は、取引先側が業界標準へ切り替えるのを待つ経路です。
流通BMS協議会が基本方針とガイドラインを公開して普及を進めてきたのは、まさに個社仕様の画面を減らすためでした2。
取引先が標準に沿った形へ移れば、受注側は同じ考え方で複数社のデータを受けられるようになり、相手ごとの読み替えが減ります。
二つ目は、共通の規格に対応したプロバイダーを間に置く経路です。
中小企業庁の解説では、受発注側企業と発注側企業が同じ標準に対応するプロバイダーと契約すれば、プロバイダーが必要な情報を変換するため、自社の使い慣れたアプリケーションを使って統一したデータをやり取りできるとされています1。
画面の違いを人が吸収するのではなく、変換の役割を担う事業者が引き受ける形です。
並べてみると、この二つは実現の仕方が違うのに、必要な条件が重なっています。
どちらも、相手側が標準へ移るか、相手側が同じ規格のプロバイダーと契約するかという形で、取引先の動きを必要とします。
自社の意思だけで明日から始められる方法として、公的機関や業界団体の資料で裏付けられるものは見当たりません。
そこが、この課題がなかなか片付かない理由でもあります。
自社側だけで動かせるツールはどう位置づけるか
では、自社だけで動かせる手段がまったくないのかというと、そうではありません。
各社のWeb-EDI画面を自動で操作して注文データを取り出す仕組みや、複数のWeb-EDIをまとめて取り込むことをうたうサービスは、商品として存在します。
相手の対応を待てない事情があるなら、検討の対象から外す理由はありません。
ただし、扱いには注意が要ります。
これらが自社の取引先の画面にどこまで対応できるのか、費用がどの程度かかるのかは、公的機関や業界団体の資料で裏付けられる性質の情報ではありません。
今回参照した範囲でも確認できていないため、この記事で効果や相場を示すことはできず、対応可否は個別のベンダーに確認する必要があります。
確認するなら、取引先名と使っている画面の種類を挙げて対応実績を尋ねること、発注側が画面の仕様を変更したときに誰がどう直すのかを尋ねることが、実際の使い勝手を分ける質問になります。
位置づけとしては、相手側の対応を待たずに当面の手数を減らす手段であり、相手の画面が個社仕様のまま残る点は変わりません。
そこを踏まえておくと、「これを入れれば集約が終わる」という期待の掛け違いを避けられます。
では、この二つの経路はそれぞれ何が前提で、どこまでを自社の判断で進められるのでしょうか。
集約の経路そのものは公開資料で確かめられても、自社の取引先構成と既存システムに当てはめたとき、どこから動かせるかは手元の条件を並べないと決まらないためです。
取引先ごとの画面数と注文件数、いま使っている受発注システムの取り込み口を整理したうえで、切り替えを待てる相手と先に手を打つ相手の切り分けを一緒に確認できます。無料相談で要件を整理する
方法ごとの前提条件と対応範囲
| 方法 | データがそろう場所 | 自社だけで完結するか | 必要な前提 | 進み方の見通し |
|---|---|---|---|---|
| 業界標準（流通BMS）への統一を待つ | 取引先が送る側でそろう | 完結しない | 取引先が標準へ切り替えること | 協議会の普及活動に沿って各社が順次判断するため、時期は自社で決められない |
| 共通EDI規格に対応したプロバイダーを介す | 間に立つプロバイダーの変換でそろう | 完結しない | 自社と取引先の双方が同一標準対応のプロバイダーと契約すること | 相手ごとに合意が取れたところから順に |
取引先の切り替えを待つ方法は、何がそろい、誰が決めるのか
そろうのは相手側なので、自社の受け取り方は一つで済む
業界標準への統一は、取引先が使う画面やデータの形そのものが、共通の取り決めに沿った形へ移ることを意味します。
そろうのは相手の側なので、自社は受け取り方を標準に合わせておけば、切り替えの済んだ取引先から順に同じやり方で処理できます。
読み替えの表を取引先の数だけ持つ必要が減り、新しい取引先が増えたときの立ち上げも軽くなります。
担当者の経験に依存していた「この会社ではここを見る」という約束事も、標準に沿った相手の分だけ減っていきます。
一方で、切り替えを決めるのは自社ではありません。
協議会は基本方針やガイドラインを公開して普及を進める立場であり2、実際にどの企業がいつ移るかは各社の判断と投資計画に左右されます。
受注側が「来期までに全取引先をそろえたい」と考えても、その時期を自社の側から動かす手立ては基本的にありません。
ここは、この方法を検討するときに最初に飲み込んでおくところです。
時期が読めないことを、業務計画にどう織り込むか
この性質があるため、期限のある業務改善の柱に据えるのは向きません。
たとえば増員なしで受注件数を伸ばす計画を立てているとき、標準化の進み具合を前提に置いてしまうと、進まなかった場合に打ち手が残らなくなります。
「いずれそろうはずだから」と待っている間も、画面ごとのログインと転記は毎日発生します。
現実的な扱い方は、全社一斉ではなく、対応が済んだ取引先から順に受け取り方を切り替えていく形です。
取引先ごとの状況を把握しておけば、相手から切り替えの案内が届いたときに、自社側の準備がそろっているかどうかで対応の速さが変わります。
待つこと自体は選択のひとつですが、待ちながら何もしないことと、切り替えが来たらすぐ乗れる状態で待つことは別の話です。
準備として意味があるのは、標準に沿ったデータを受けたときに自社システムがそのまま取り込めるかを先に確かめておくことです。
相手が切り替えたのに自社側で受けられず、結局これまでどおり画面から手で拾う、という事態は避けられます。
この確認は次の方法を選んだ場合にも同じく必要になるので、どちらに転んでも無駄になりません。
出典：流通システム開発センター（流通BMS協議会）「流通ＢＭＳにおけるWeb-EDI」／対象は流通業界（小売・卸）の取引
変換を挟む方法は、どこまで自社の判断で進められるのか
変換されたデータが自社のアプリに届くまで
この方法は、自社と取引先の間に、同じ標準に対応したプロバイダーを置く形です。
受発注側企業と発注側企業がそれぞれ同標準に対応するプロバイダーと契約していれば、プロバイダーが必要な情報を変換するため、自社は使い慣れたアプリケーションで統一されたデータをやり取りできるとされています1。
相手の画面がどう作られていても、自社に届く段階では同じ形になっている、というのがこの経路の要点です。
日々の作業で言えば、Web-EDIの画面にログインして注文を探し、CSVの列を自社の形に直して取り込む、という一連の手間が仕組み側へ移ります。
一方で、届いた注文の数量や納期が妥当かを見る確認そのものがなくなるわけではありません。
電話やメールで来る変更依頼も、この経路の外側に残ります。
減るのは転記と読み替え、残るのは判断が要る確認、と分けて考えておくと、導入後の落差が小さくなります。
1社だけでは効果が出ないという前提
この方法には、はっきりした条件があります。
中小企業庁の解説は、EDIは1社だけが導入しても効果を得ることはできないと明記しています1。
自社がプロバイダーと契約しても、相手が同じ標準に対応していなければ、その取引先の注文はこれまでどおり個別の画面から取ることになります。
つまり、契約の前に確かめるべきなのは製品の機能ではなく、主要な取引先が同じ標準に乗る意思を持っているかどうかです。
導入が進んだ場合にどの程度変わるのかを示す材料としては、平成28年度補正（2016年度）の中小企業共通EDI実証事業の結果があります。
12のプロジェクトを対象にした集計で、大企業と比べて中小企業のほうが業務時間の削減率が高く、平均51.4%の削減効果が得られたと報告されています1。
ただしこれは実証事業に参加した企業の集計であり、取引先数も業務の作り方も違う自社に同じ率が出ると読むことはできません。
読み取るべきは率そのものより、効果が自社の努力だけでなく、相手を含めた対応の広がりに左右されるという関係のほうです。
検討の順番も、ここから決まります。
先にサービスを比べるより、注文件数の多い取引先に対応の可否を打診し、応じる相手が何社あるかを見てから規模を決めるほうが、費用の見通しが立ちます。
相手が動かない状態で契約だけ進めると、費用は発生するのに処理が二本立てのまま残る、という形になりかねません。
出典：中小企業庁「企業間のデータ連携で、受発注の業務コストを削減する！（ミラサポplus）」／受発注側・発注側の双方が同標準対応のプロバイダーと契約している場合
取引先数・既存システムの状況に応じた選び方
取引先へ確認すべきこと
確認は、全取引先に一斉に問い合わせる前に、自社側の棚卸しから始めるほうが早く進みます。
取引先名、使っているWeb-EDIの画面、一日あたりの注文件数、受け取っている情報の種類（注文だけか、出荷や請求まで含むか）を並べると、どの相手の画面が時間を食っているかが数字で見えます。
注文件数の多い数社で作業時間の大半を占めているなら、最初に確認する相手はその数社です。
取引先に尋ねる内容は、三つに絞れます。
一つ目は、いま使っているWeb-EDIが業界標準に沿ったものか、個社仕様かという点。
二つ目は、標準への切り替え予定があるか、あるならおおよその時期。
三つ目は、共通EDI規格に対応したプロバイダーを介したデータ連携に応じる余地があるかどうかです。
聞き方も結果を左右します。
これはシステム担当に回る質問なので、窓口の購買担当にいきなり規格名を尋ねても答えが返らないことがあります。
「注文データをファイルや連携で受け取る方法があるか」という業務側の言葉で入り、必要に応じて担当部署につないでもらうほうが話が進みやすくなります。
回答が「未定」でも収穫はあります。
当面は相手の画面運用が続くと分かり、他の相手に力を振り分ける判断ができるからです。
既存システムとの接続可否の確認
取引先側の答えが出ても、自社の受発注システムが受け取れなければ集約にはなりません。
確かめたいのは、外部からデータを取り込む口があるか、取り込める形式は何か、取り込んだ後に手作業の補正が要らないかの三点です。
中小企業庁の解説が「自社の使い慣れたアプリケーション」を前提に説明しているのも1、受け取る側の道具を変えずに済むことが導入のしやすさに直結するからです。
ここで見落としやすいのが、自社の中の読み替えです。
取引先の品番と自社の品番が違う場合、届くデータが標準化されても、社内のマスタで結び付ける作業は残ります。
この対応表が整理されていないと、集約の仕組みを入れた後に「取り込めない行」が毎日出て、結局その分だけ手作業が戻ってきます。
先に手を付けるなら、注文件数の多い取引先の品番対応表を確認しておくことが、どちらの方法を選んでも効いてきます。
自社システムに取り込み口がない場合は、その整備が先に必要な工程として乗ってきます。
この場合、集約の検討は「どの方法を選ぶか」の前に「自社側の受け皿をどうするか」から始まることになり、費用と期間の見積もりも変わります。
取引先へ確認を出すのと並行して、社内のシステム担当や保守先に取り込みの可否を聞いておくと、相手の回答が出たときに判断が止まりません。
取引先数と偏りで、手を付ける順番が変わる
取引先が数社で、そのうち大半が同じ業界の大手なら、標準への切り替え時期を確認し、それに合わせて自社の受け取り方を整える進め方が合います。
相手の予定が読めれば、待つ期間も見通せます。
この場合に自社がやることは、切り替えの案内が来たときに受けられる状態を作っておくことに絞られます。
取引先が多く、規模もばらばらな場合は、一社ずつの切り替えを待つほど負担が長引きます。
注文件数の多い相手から共通EDI規格に対応したプロバイダーを介す形を相談し、残りは当面これまでの画面運用を続ける、という二本立ても現実的です。
すべてを一度に集約しようとすると、どの相手も動かないまま時間だけが過ぎます。
時間を食っている上位の数社から順に手を打つほうが、同じ労力でも効き方が違います。
そして、どちらの方法でも自社だけでは完結しないという前提は変わりません。
だからこそ、最初に取る行動は製品の比較ではなく、取引先ごとの画面と件数の把握、そして対応状況の確認になります。
ここが分かれば、待てる相手と先に手を打つ相手が分かれ、選ぶべき方法も自然に絞られていきます。
要点の整理
| 確認する場面 | 判断の基準 |
|---|---|
| 集約の目的 | 一つの画面で見られるかではなく、使い慣れたアプリで読み替えなしに扱えるか |
| 業界標準を待つ場合 | 切り替え時期は取引先が決める。期限のある業務改善の柱には据えない |
| プロバイダーを介す場合 | 自社と取引先の双方が同一標準に対応していること。1社だけでは効果が出ない |
| 自社側だけのツール | 対応範囲と費用は個別のベンダーに確認。相手の画面は個社仕様のまま残る |
| 最初の行動 | 取引先ごとの画面と注文件数を棚卸しし、対応規格と切り替え予定を確認する |
取引先の回答が出た後、自社側の受け取り方をどう整えるかの段階で手戻りが起きやすいためです。 既存システムに外部データを取り込む口があるか、品番の読み替えがどこに残るかを見たうえで、現実的な進め方の順番を確かめられます。
よくある質問
取引先が業界標準にもEDI規格にも対応していない場合、集約はあきらめるしかないですか
記事で扱った二つの経路はどちらも相手側の対応が前提なので、その取引先のデータをそろえることは当面できません。
残るのは、確認の抜けを減らす運用の整理（取引先ごとの画面と件数の棚卸し、確認する順番を固定する）と、自社側だけで動かすツールの検討です。
後者は対応範囲や費用を個別のベンダーに確認する必要があり、相手の画面が個社仕様のまま残る点も変わりません。
注文件数の多い相手については、切り替え予定の有無を定期的に聞いておくと、相手が動いたときに乗り遅れずに済みます。
自社完結型の集約ツール（RPAやEDI集約サービス）は、今回の二つの方法とどう違いますか
二つの経路は、相手から届くデータの形そのものをそろえる方法です。
自社完結型は、相手の画面が個社仕様のまま、自社側で取り出し方を自動化・集約する方法だと整理できます。
前者は相手の動きが要る代わりに読み替えが減り、後者は相手を待たずに始められる代わりに、発注側の画面仕様が変わったときの影響を受けます。
今回参照した公的機関・業界団体の資料では後者の対応範囲や費用を確認できていないため、導入前に個別のベンダーへ具体的な取引先名と画面を挙げて確認してください。
集約を進める際、まず取引先の何を確認すればよいですか
尋ねるのは三点です。
いま使っているWeb-EDIが業界標準に沿ったものか個社仕様か、標準への切り替え予定と時期、共通EDI規格に対応したプロバイダーを介した連携に応じる余地があるかどうか。
その前に自社側で、取引先ごとの画面と一日あたりの注文件数を並べておくと、どこから聞くかが決まります。
規格名で通じない場合は「注文データをファイルや連携で受け取る方法があるか」という業務側の言葉から入ると、担当部署につながりやすくなります。
業界標準への切り替えと共通EDI規格対応は、同時に進めても良いですか
相手ごとに状況が違うので、二つは排他ではありません。
標準への切り替えが決まっている相手はその時期に合わせ、予定のない相手にはプロバイダーを介す形を相談する、という分け方ができます。
ただし自社側の受け取り方が当面二通りになるため、社内の手順が増える負担は見ておく必要があります。
注文件数の多い相手をどちらの経路に寄せるかを先に決めると、全体の手順が散らばりにくくなります。
実証事業で報告された51.4%という削減率は、自社でも見込めますか
この数値は平成28年度補正（2016年度）の中小企業共通EDI実証事業で、12のプロジェクトを対象に集計されたものです。
大企業と比べて中小企業のほうが業務時間の削減率が高く、平均51.4%の削減効果が得られたと報告されています1。
参加企業の集計であり、取引先数や業務の作り方が違えば同じ率にはなりません。
加えて、EDIは1社だけが導入しても効果を得られないとされているため1、どれだけの取引先が同じ標準に乗るかが結果を左右します。
- 1 出典：中小企業庁「企業間のデータ連携で、受発注の業務コストを削減する！（ミラサポplus）」（2020年）
- 2 出典：一般財団法人流通システム開発センター（流通BMS協議会）「流通ＢＭＳにおけるWeb-EDI」（2012年）
