EOS名人.NET

Amazonで商品を売る場合、二つのケースがあります。一つはAmazonマーケットプレイスで店舗を構えるのと、もう一つは卸販売です。この卸販売は、Amazonの仕入れチームからの招待によって参画するものです。販売実績がすでにあり、商品特性（類似品が少ないなど）があるとスカウトされることが多いようです。Amazonから卸販売の声掛けがあり、取引を開始する際に使うシステムは以下のとおりです。

■ベンダーセントラル
Amazonが卸販売業者（ベンダー）向けに提供している調達Webシステム（Web EDI）のこと。受注確認、納期回答入力、出荷入力、納品ラベル印刷などができる。

■Amazon EDI
ベンダーセントラル同様、Amazonが提供するEDIシステムのこと。日本の流通業界で普及しているEDIである流通BMS（流通ビジネスメッセージ標準）とは異なる仕様を持つ。

図1：Amazonとのビジネス

ベンダーセントラルはWeb EDIのシステムです。ブラウザを経由してAmazonからの受注確認や納期回答、出荷まで一連の手続きができます。無料で利用できるシステムであることはメリットですし、何より卸販売の場合は、マーケットプレイスでは消費者からの注文がなければ売上が立たないことに比べ、Amazonからまとめて発注がくるのは「売れない」というリスクが少しでも回避できます。
Amazonからの発注により売れないリスクが回避される一方で、デメリットもあります。それは、Amazonが要請する出荷形態に合わせなければならないことです。具体的には短時間での納期回答や配送内容明細貼り付け、出荷実績をデータ化して送信するといった、煩雑な納品手順があります。これに関して、ベンダーセントラルのオペレーションの課題を抱えた事例がありますので、図とともに紹介します。

図2：＜A社の例＞ベンダーセントラルのオペレーション略図

*FC…フルフィルメントセンター（Amazonの物流拠点）
*SSCC…出荷梱包シリアル番号（Amazonでは出荷する梱包ごとに一意になる番号を設定する必要があり、その番号が記載されたラベルを貼付する）

■ベンダーセントラルの煩雑さ
自動車・二輪車の部品卸販売をしているA社は、Amazonでの取引が拡大するにつれ、ベンダーセントラルでの発注・出荷に課題がありました。
ベンダーセントラルの受注データ確認作業―1,000明細／日にのぼる－から始まる一連の手作業が限界を迎えていたのです。納期回答や出荷情報を返信する作業（図２の②、③）が膨大なため多大な時間がかかり、ミスも発生していました。またこれらの大量出荷を納品先FCごとに一人で検品することもあり、出荷時間に間に合わないこともあります。送り状番号も控えておく必要もあったため、担当者のストレスは大変なものだったといいます。担当者を増員することもすぐにはできず、また、たとえ増員できたとしてもその場しのぎにしかならず、根本的な解決になっていないのは明らかでした。
Amazonからの発注に対し、迅速にミスなく進めるには、受注・検品・物流業務の見直しが必要という結論になりました。

■Amazon EDIの場合
人手による作業が発生するベンダーセントラルと違い、Amazon EDIはファイル交換型のEDIです。前述のA社のように一日の取引量が多ければAmazon EDIを選択したほうが効率がよいでしょう。しかし、流通BMSに代表される日本の流通業のEDIとAmazon EDIはメッセージや通信方式、物流ラベルの点で大きく異なり、考慮が必要です。

図3：Amazon EDIの特徴

日本で発展してきたEDIと比べ、細かいところで違いが散見されるのがAmazon EDIです（図３参照）。通信方式は、SFTP（SSH File Transfer Protocol）というセキュアなFTPとANSI（American National Standards Institute）X.12という米国統一規格のフォーマットです。日本では利用されていない通信方法ですが、フリーツールを利用してテキストに変換することができます。
データ種別としては納期回答メッセージが存在する点が大きな違いでしょう。Amazonから発注データを受信したら、出荷の前に在庫の有無と出荷予定日を返す必要があります。
さらに、発注区分としてバックオーダーという考え方も存在します。在庫なしであっても注残となり、入荷後、発送しなければなりません。これも日本の流通BMSなどのEDIにはないものです。自社でAmazon以外のEDIと基幹システムなどとの連携ができていたとしても、Amazonの取引だけは別で開発しなければならないということが起こりうるのです。
また、物流の現場でも送り状の点でAmazonは独自のものがあります。SSCCラベルといい、流通BMSのSCMラベルと同義で、出荷実績のデータの一部をラベルにしているものになります。そのデータに運送会社の送り状番号をASN（事前出荷情報）として付与する必要があるのです。

図４：流通BMSとAmazon EDI　フローの違い

ここまで、Amazonとの取引や売上を拡大させるのに、ベンダーセントラルやAmazon EDIの考慮すべき点を述べてきました。では、実際にどのようにしてこのシステムをうまく利用して日々の業務を効率化させつつ、自社のEC事業を成長させたらよいでしょうか。ケーススタディを紹介します。

■Amazon EDI対応事例
インターネット通販に注力した結果、右肩上がりの売上を記録し、Amazonでの売上も前年比150%となったD社。しかし、Amazonとの取引は、他のECサイトとは異なる業務フローのため、作業効率が悪いことが課題でした。

繰り返し述べている通り、他のECサイト取引とAmazonの取引では受注・検品・物流の点で大きく異なります。D社はAmazonとの取引に関して、受注のシステムをベンダーセントラル（Web EDI）からAmazon EDIに変更し、受注・納期回答などの送受信を自動化することで工数を削減しました。また、AmazonだけでなくEDIと物流のフローも見直しを実行したのです。

ユーザックシステムはベンダーセントラルやAmazon EDIでAmazonと取引をしている企業にアンケートを取り、その回答から取引の課題について知ることができました。以下に抜粋して紹介します。

■課題１：Amazon EDI（SFTP手順）利用者
自社でスクラッチ開発した受注管理システムでは、Amazon EDIの仕様に合っていなく、連携できない
●解決策１：
Amazon EDIを利用する際に必要な情報を付与できない（納期回答、出荷実績）ことが課題になっていると思われます。
①納期回答
在庫引当結果の連携が必要です。正確な在庫情報を基幹システムから連携させるためにEOS名人やRPAを利用することで解決できます。
②出荷実績のSSCC番号とPO番号の紐づけや、PO番号と送り状番号の紐づけについては、前段のケーススタディで解説したEOS名人、検品支援名人、送り状名人で解決できます。

■課題２：ベンダーセントラル利用者
ベンダーセントラルの操作（入力など）が大変である。また、在庫引き当てや納期回答、出荷商品の検品、梱包作業に追われ、苦労している。Amazonからの支払い内容確認作業も手間がかかる。
●解決策２：
これについても前述のケーススタディや解決策1での手法が応用できます。ベンダーセントラルからAmazon EDIへの変更も視野に入れ、受注業務だけでなく、物流の点も見直しを検討しましょう。

■課題３：Amazon EDI（SFTP手順）利用者
在庫引き当てや納期回答が大変である。仕様の解釈が難しく、送ったデータが合っているのかの確認があまりできていないため、不安。
●解決策３：
在庫の引き当てや納期回答も、システム化し、ミスなく実行することが可能です。基幹システムや在庫管理システムなどとEOS名人は連携可能であり、Amazon EDIにおいての事例もあります。

■課題４：ベンダーセントラル利用者
他のWeb EDIの受注業務はRPAで自動化しているが、ベンダーセントラルはサイト構成が度々かわり、RPAで対応しきれない。
●解決策４：
昨今、業務改善などで注目を浴びているRPAは、受注業務を自動化することで活用されています。しかし、自動化したいWeb EDIの画面が変更になることがあれば、RPAが認識できずにエラーになったり、入力する項目が多いなどという場合は自動化シナリオのフローが煩雑になるなど、懸念も聞かれます。ベンダーセントラルの場合は、受注データ（Excel）のダウンロードを自動化し、その後の作業、データのアップロードは人手でやらなければならないということが多いようです。Amazonでの取引量が多ければ、ファイル交換型のAmazon EDIを利用して効率化することも検討に入れてはいかがでしょうか。

今後の通販需要拡大を見通して、受注・物流業務の効率化に先手を打ちましょう。業務効率化は、従業員の働き方改革や満足度につながるだけでなく、ビジネスも大きく成長させることができます。Amazon EDIのご相談、システム活用や業務改善のノウハウについては、こちらからお問合せください。