電子データ交換

電子データ交換( EDI ) とは、注文書、出荷前通知、請求書など、従来は紙でやり取りされていた情報を企業が電子的にやり取りするという概念です。EDIの技術標準は、特別な手配をすることなく当事者がこうした手段で取引できるようにするために存在します。

EDI は少なくとも 1970 年代初期から存在しており、多くの EDI 標準 ( X12、EDIFACT、ODETTEなど) があり、その一部は特定の業界や地域のニーズに対応しています。また、標準ファミリーを具体的に指すこともあります。1996 年に、米国国立標準技術研究所は、電子データ交換を「データ交換用の標準化された形式のコンピュータ間の交換。EDI は、どちらかが発信者または受信者として機能する 2 者間の一連のメッセージを意味します。ドキュメントを表すフォーマットされたデータは、発信者から受信者に電気通信を介して送信されるか、電子記憶媒体で物理的に転送されます。」と定義しました。この規格は単なる電子通信やデータ交換とは区別し、「EDI では、受信メッセージの通常の処理はコンピュータのみで行われます。受信メッセージの処理における人間の介入は、通常、エラー状態、品質レビュー、および特別な状況でのみ行われます。たとえば、バイナリ データまたはテキスト データの送信は、データが EDI メッセージの 1 つ以上のデータ要素として扱われ、通常、オンライン データ処理の一部として人間が解釈することを意図していない場合を除き、ここで定義される EDI ではありません」と規定しています。^{[1]つまり、EDI は、合意されたメッセージ標準に従って、人間の介入なしに、ある}コンピュータ システムから別のコンピュータ システムへ構造化データを転送することと定義できます。

他の多くの初期の情報技術と同様に、EDI は軍事ロジスティクスの発展に触発されました。1948年のベルリン空輸の複雑さにより、輸送される商品に関する膨大な量のデータと情報を、時には 300 ボーのテレタイプモデムを介して交換するための概念と方法の開発が必要になりました。これらの初期の概念は、後に米国で最初の TDCC (輸送データ調整委員会) 標準を形成しました。^[2] EDI を使用した最初の統合システムの中には、貨物管理システムがありました。そのようなリアルタイム システムの 1 つが、1971 年に英国ロンドンのヒースロー空港で導入されたロンドン空港貨物 EDP スキーム (LACES) です。直接トレーダー入力 (DTI) 方式を実装することで、運送業者が情報を税関処理システムに直接入力できるようになり、通関時間が短縮されました。海上交通量の増加とヒースロー空港で経験したような税関の問題により、1980 年代には個々の港または港のグループで DTI システムが導入されました。 ^[3]

EDI は、内部または外部の 2 つのエンティティ間の自動化された商用「会話」の技術的基盤を提供します。EDI という用語は、送信、メッセージ フロー、ドキュメント形式、およびドキュメントの解釈に使用するソフトウェアを含む、電子データ交換プロセス全体を網羅します。ただし、EDI 標準は電子ドキュメントの厳密な形式を規定しており、EDI 標準は当初自動車業界で、通信およびソフトウェア テクノロジに依存しないように設計されました。

EDI 文書には、通常、同じ組織機能に使用される紙の文書に通常含まれる情報と同じ情報が含まれています。たとえば、EDI 940 倉庫からの出荷指示は、製造業者が倉庫に製品を小売業者に出荷するように指示するために使用されます。通常、この指示には、「出荷先」住所、「請求先」住所、製品番号 (通常はUPC ) と数量のリストが含まれます。別の例としては、見積依頼(RFQ)、RFQ に対する入札、発注書、発注書確認、出荷通知、受領通知、請求書、支払通知など、売り手と買い手の間の一連のメッセージがあります。ただし、EDI は貿易関連のビジネス データだけに限定されるのではなく、医療 (患者記録や検査結果など)、輸送 (コンテナや輸送手段の情報など)、エンジニアリングや建設など、すべての分野を網羅しています。場合によっては、EDI を使用して新しいビジネス情報フロー (以前は紙のフローではなかったもの) を作成することもあります。これは、受取人に貨物、受け取る商品、および商品の梱包方法を通知するために設計された事前出荷通知（ASN）の場合です。これは、貨物の追跡番号を参照するGS1-128バーコードを含む出荷ラベルの使用によってさらに補完されます。^[4]

EDI標準規格の主なもの: ^[5]

• 国連が推奨するUN/EDIFACT は唯一の国際標準であり、北米以外では主流です。
• 北米では米国規格 ANSI ASC X12 (X12)が主流です。
• GS1 EDI は、グローバルサプライチェーンで主流となっているGS1が開発した標準セットです。
• ANA (Article Number Association、現在は GS1 UK として知られています) によって開発された TRADACOMS 標準は、英国の小売業界で主流となっています。
• 欧州の自動車業界で使用されている ODETTE 規格。
• 主にドイツの欧州自動車業界で使用されている VDA 規格。
• HL7 は、医療データに使用されるセマンティック相互運用性標準です。
• HIPAA (医療保険の携行性と責任に関する法律) では、データを電子的に送信する何百万もの医療機関に、標準の HIPAA 形式で EDI を使用することを義務付けています。
• IATA Cargo-IMP、IATA Cargo-IMP は、国際航空運送協会の貨物交換メッセージ手順の略です。これは、航空会社とその他の関係者間のデータ交換を自動化および標準化するために作成された、EDIFACT に基づく EDI 標準です。
• NCPDP Script (SCRIPT) は、全米処方薬プログラム協議会 (NCPDP) によって開発および管理されている標準です。この標準は、米国における医療処方箋の電子送信用の文書を定義します。
• NCPDP 電気通信標準には、資格確認、請求およびサービス請求、給付の事前決定、事前承認、および情報報告のトランザクションが含まれており、主に米国で使用されています。
• Edig@s (EDIGAS) は、ガスの商取引、輸送 (パイプラインまたはコンテナ経由)、および保管を扱う標準です。

これらの標準の多くは、1980 年代前半から中頃に初めて登場しました。これらの標準では、ビジネス ドキュメントやフォームの交換に使用される形式、文字セット、およびデータ要素が規定されています。完全なX12 ドキュメント リストには、注文書や請求書など、すべての主要なビジネス ドキュメントが含まれています。

EDI 標準は、特定の文書の必須情報とオプション情報を規定し、文書の構造のルールを示します。標準は建築基準法のようなものです。2 つのキッチンが「基準に従って」建てられても外観がまったく異なるのと同じように、2 つの EDI 文書が同じ標準に従っていても、異なる情報セットを含む場合があります。たとえば、食品会社は製品の有効期限を示すかもしれませんが、衣料品メーカーは色とサイズの情報を送信することを選択します。

EDI は送信者と受信者が合意した任意の方法を使用して送信できますが、より多くの取引先が送信にインターネットを使用するようになったため、標準化されたプロトコルが登場しました。

これには、次のようなさまざまなテクノロジが含まれます。

• mModem（非同期および同期）
• FTP、SFTP、FTPS
• メール
• HTTP / HTTPS の仕様
• AS1
• AS2
• AS4
• OFTP (および OFTP2)
• モバイルEDI

EDI 文書の送信に使用される同期プロトコル 2400 ビット/秒モデム、CLEOデバイス、および付加価値ネットワークをインターネット経由の送信と比較した人は、非インターネット技術を EDI と同一視し、EDI 自体が非インターネット技術とともに置き換えられると誤って予測しました。ほとんどの場合、これらの非インターネット送信方法は、 FTP、HTTP、 telnet 、電子メールなどのインターネットプロトコルに置き換えられているだけで、EDI 文書自体はそのまま残っています。

2002 年にIETF はRFC 3335 を公開し、電子メール経由で EDI データを転送する標準化された安全な方法を提供しました。2005 年 7 月 12 日、IETF ワーキング グループはMIMEベースの HTTP EDIINT (別名AS2 ) 転送に関する RFC4130 を承認し、IETF は FTP 転送 (別名AS3 )に関する同様の RFC を準備しました。Web サービス経由の EDI (別名AS4 ) も OASIS 標準化団体によって標準化されています。一部の EDI 転送はこれらの新しいプロトコルに移行していますが、付加価値ネットワークのプロバイダーは引き続き活動しています。

インターネットに接続する組織が増えるにつれて、最終的に EDI のほとんどまたはすべてがインターネット上で行われるようになりました。当初は、特定の IP アドレスからのみ許可される、特定のホストの特定のフォルダへの ASCII テキスト ファイルの暗号化されていない FTP などのアドホックな規約によって行われていました。しかし、IETF は、EDI に標準のインターネット プロトコルを使用する方法を説明した情報ドキュメント (「適用性ステートメント」、以下の「プロトコル」を参照) をいくつか発行しました。

2002年現在、ウォルマートはEDIにAS2を採用しています。 ^[6]グローバルサプライチェーンにおける大きな存在感により、AS2はEDIに一般的に採用されるアプローチとなっています。

文書を相互に送受信する組織は、EDI 用語では「取引先」と呼ばれます。取引先は、送信される特定の情報とその使用方法について合意します。これは、人間が読める仕様 (メッセージ実装ガイドラインとも呼ばれます) で行われます。標準は建築基準法に似ていますが、仕様は設計図に似ています。(仕様は「マッピング」と呼ばれることもありますが、マッピングという用語は通常、翻訳ソフトウェアに与えられる特定の機械可読指示に使用されます。^{[7] ) 大規模な取引「ハブ」には、EDI を処理するための}ビジネス プロセスを反映した既存のメッセージ実装ガイドラインがあり、通常、取引先のニーズに合わせて EDI ビジネス プラクティスを変更することを好みません。大企業では、これらの EDI ガイドラインは、さまざまな支店や部署で使用できるように汎用的に記述されるため、特定のビジネス ドキュメント交換には不要な情報が含まれることがよくあります。他の大企業では、支店/部署ごとに個別の EDI ガイドラインを作成する場合があります。

取引先は、文書の送信に任意の方法を自由に使用できます (上記の「送信プロトコル」セクションで説明されているとおり)。さらに、取引先は直接やり取りすることも、仲介者を介してやり取りすることもできます。

取引先は互いに直接接続できます。たとえば、自動車メーカーは、数百のサプライヤーすべてが EDI を実行するためにダイヤルインする必要があるモデム プールを維持する場合があります。ただし、サプライヤーが複数のメーカーと取引している場合、各メーカーごとに異なるモデム (または VPN デバイスなど) と異なるソフトウェアを取得する必要がある場合があります。

EDI と Web テクノロジが進化するにつれて、取引先間の直接的な (ポイントツーポイントとも呼ばれる) EDI を容易にする新しい EDI ソフトウェア テクノロジが登場しました。最新の EDI ソフトウェアは、さまざまなファイル転送プロトコルと EDI ドキュメント標準を使用して交換を容易にし、コストと参入障壁を削減します。

EDI のピアツーピア導入の制限に対処するため、数十年前にVAN (付加価値ネットワーク)が確立されました。VAN は地域の郵便局として機能します。トランザクションを受信し、「送信元」と「送信先」の情報を調べ、トランザクションを最終受信者にルーティングします。VAN は、ドキュメントの再送信、サードパーティの監査情報の提供、さまざまな送信方法のゲートウェイとしての動作、通信サポートの処理など、いくつかの追加サービスを提供する場合があります。これらのサービスと VAN が提供するその他のサービスのため、両方の取引先がインターネットベースのプロトコルを使用している場合でも、企業は VAN を頻繁に使用します。ヘルスケア クリアリング ハウスは、VAN と同じ機能の多くを実行しますが、追加の法的制限があります。

VAN はさまざまな組織によって運営されます。

• 通信会社;
• 業界団体コンソーシアム;
• サプライヤー/ベンダーとやり取りする大企業。
• マネージド サービス プロバイダー。

VAN とダイレクト EDI の間には重要なトレードオフがあることに注意することが重要です^[8]。多くの場合、EDI ドキュメントを交換する組織は、EDI 実装のさまざまな側面で実際に両方を併用できます。たとえば、米国では、EDI ドキュメント交換の大部分は AS2 を使用しているため、米国を拠点とする組織では AS2 のダイレクト EDI 設定が理にかなっている可能性があります。ただし、ヨーロッパのパートナーと通信するために OFTP2 機能を追加するのは難しい可能性があるため、これらの特定のトランザクションを処理するには VAN が理にかなっている可能性があり、AS2 トランザクションにはダイレクト EDI が使用されます。

多くの点で、VAN はサービス プロバイダーとして機能し、EDI を開始しようとしている組織の設定を大幅に簡素化します。多くの組織は、顧客またはパートナーの要件を満たすために初めて EDI を開始するため、社内に EDI の専門知識が不足しているため、VAN は貴重な資産となります。

ただし、VAN には高額な費用がかかる場合があります。VAN は通常、顧客に代わって EDI トランザクションを処理するサービスに対して、ドキュメントごと、または明細項目ごとにトランザクション料金を請求します。これが、多くの組織が EDI ソフトウェア ソリューションを実装したり、EDI の一部またはすべてを最終的に EDI ソフトウェア ソリューションに移行する主な理由です。

一方、EDI ソフトウェアの実装は、ユースケースの複雑さ、関連するテクノロジ、EDI の専門知識の有無に応じて、困難なプロセスになる可能性があります。さらに、継続的なメンテナンス要件と更新を考慮する必要があります。たとえば、EDI マッピングは最も困難な EDI 管理タスクの 1 つです。企業は、取引先ごとに EDI マップを開発して維持する必要があります (注文履行要件に基づいて、取引先ごとに複数の EDI マップが必要になる場合もあります)。

EDI 翻訳ソフトウェアは、内部システムと送受信される EDI 形式との間のインターフェイスを提供します。「受信」ドキュメントの場合、EDI ソリューションはファイルを受信し (付加価値ネットワーク経由、または FTP や AS2 などのプロトコルを使用して直接)​​、受信した EDI ファイル (一般に「エンベロープ」と呼ばれる) を取り、ファイルを送信する取引先が有効な取引先であること、ファイルの構造が EDI 標準を満たしていること、および情報の個々のフィールドが合意された標準に準拠していることを検証します。通常、翻訳者は固定長、可変長、または XML タグ形式のファイルを作成するか、受信した EDI ドキュメントを「印刷」します (統合されていない EDI 環境の場合)。次の手順は、翻訳者が作成したファイルを、会社のバックエンド ビジネス システム、アプリケーション、または ERP にインポートできる形式に変換することです。これは、カスタム プログラム、統合された独自の「マッパー」、または統合された標準ベースのグラフィカル「マッパー」を使用し、XSLTなどの標準データ変換言語を使用することで実現できます。最後の手順は、変換されたファイル (またはデータベース) を会社のバックエンド システムにインポートすることです。

「送信」文書の場合、統合 EDI のプロセスは、会社の情報システムからファイルをエクスポート (またはデータベースを読み取り) し、そのファイルを翻訳者に適した形式に変換することです。次に、翻訳ソフトウェアは、送信された EDI ファイルを「検証」して、取引先が合意した標準に準拠していることを確認し、そのファイルを「EDI」形式に変換 (適切な識別子と制御構造を追加) し、そのファイルを取引先に送信 (適切な通信プロトコルを使用) します。

EDI 変換ソフトウェアのもう 1 つの重要なコンポーネントは、取引先間でビジネス ドキュメントを移動するすべての手順の完全な「監査」です。監査により、トランザクション (実際にはビジネス ドキュメント) を追跡して、紛失しないようにすることができます。小売業者が仕入先に注文書を送信する場合、注文書がビジネス プロセスのどこかで「紛失」すると、両方のビジネスに壊滅的な影響が生じます。仕入先にとっては、注文を受け取っていないため注文を履行できず、ビジネスを失い、小売クライアントとのビジネス関係にダメージを与えます。小売業者にとっては、在庫切れとなり、売上の損失、顧客サービスの低下、最終的には利益の低下につながります。

EDI 用語では、「インバウンド」と「アウトバウンド」は、特定のシステムに関連する EDI ドキュメントの送信方向を指し、ドキュメントによって表される商品、お金、またはその他の物の方向を指すものではありません。たとえば、倉庫に出荷を実行するように指示する EDI ドキュメントは、倉庫のコンピュータ システムに関連するインバウンド ドキュメントです。ドキュメントを送信したメーカーまたはディーラーに関連するアウトバウンド ドキュメントです。

EDI やその他の類似の技術は、大量の人間によるやり取りや紙の文書を必要とする情報の流れに代わる、または代替手段を提供することで、企業のコストを節約します。紙の文書が EDI 交換と並行して維持されている場合でも (印刷された出荷明細書など)、電子交換とその交換からのデータの使用により、紙の文書の分類、配布、整理、検索の処理コストが削減されます。EDI や類似の技術により、企業は手入力のコストをかけずに、データを電子的に保存および操作する利点を活用できます。EDI のもう 1 つの利点は、EDI により宛先側で文書を再入力する必要がなくなるため、出荷エラーや請求エラーなどの手作業によるデータ入力エラーを削減または排除できることです。紙の文書に対する EDI の非常に重要な利点の 1 つは、取引先が情報を受け取ってシステムに組み込む速度が速く、サイクル時間が大幅に短縮されることです。このため、EDI はジャストインタイム生産システムの重要なコンポーネントになり得ます。^[9]

1996 年にケネス・カーンとジョン・T・メンツァーが発表した研究では、サプライ ネットワーク内でリンクされた企業間の EDI 提携の使用が観察され、EDI によって、これまで「知る必要のある」情報のみを共有していた企業間の慣習よりも透明性の高い情報共有が促進された。彼らは、EDI がマーケティング チャネル内のすべての関係者を網羅し、チェーンの各段階でメリットをもたらす可能性を予測した。^[10]

2008 年のAberdeen Group のレポート「世界におけるサプライヤーの支援の比較」によると、北米では注文書の 34% のみが電子的に送信されていました。EMEA では注文書の 36% が電子的に送信され、APACでは注文書の 41% が電子的に送信されています。レポートでは、紙の注文書の平均コストは、北米では37.45 ドル、EMEA では42.90 ドル、 APAC では23.90 ドルであるとも述べられています。EDI 注文書を使用すると、コストは北米で23.83 ドル、EMEA で34.05 ドル、APAC で14.78 ドルに削減されます。 ^[11]

電子データ交換の導入には、いくつかの障壁があります。最も重大な障壁の 1 つは、それに伴うビジネス プロセスの変更です。紙の取り扱いを中心に構築された既存のビジネス プロセスは EDI に適していない可能性があり、ビジネス ドキュメントの自動処理に対応するには変更が必要になります。たとえば、ある企業が、商品の大部分を 1 日または 2 日で発送し、請求書をすべて郵送で受け取るとします。したがって、既存のプロセスでは、請求書よりも先に商品が受け取られることが多いと想定されます。EDI では、請求書は通常、商品の発送時に送信されるため、対応する商品がまだ受け取られていない大量の請求書を処理するプロセスが必要になります。

もう 1 つの大きな障壁は、初期設定にかかる時間と費用です。実装、カスタマイズ、トレーニングから生じる初期費用と時間は、コストがかかる可能性があります。ビジネス要件に合わせて適切な統合レベルを選択することが重要です。EDI ベースのパートナーとの取引が比較的少ない企業の場合、安価な「リップ アンド リード」ソリューションを実装するのが合理的です。このソリューションでは、EDI 形式が人間が読める形式で印刷され、コンピュータではなく人間が取引に応答します。もう 1 つの選択肢は、EDI「サービス ビューロー」が提供するアウトソーシング EDI ソリューションです。その他の企業では、EDI によって取引量が増加したために注文処理ビジネス プロセスを再実装する必要が生じ、統合 EDI ソリューションの実装が必要になる場合があります。

EDI の実装を成功させる上での主な障害は、多くの企業が EDI の性質について抱いている認識です。多くの企業は、EDI をデータ形式という技術的な観点から捉えていますが、EDI は外部のエンティティとビジネス ドキュメントを交換し、それらのドキュメントのデータを企業の内部システムに統合するためのシステムであるというビジネス上の見方を取る方が正確です。EDI の実装を成功させるには、外部で生成された情報が内部システムに与える影響を考慮し、受信したビジネス情報を検証する必要があります。たとえば、適切なチェックとバランスなしにサプライヤーが小売業者の買掛金システムを更新することを許可すると、企業は重大なリスクにさらされます。EDI の実装を初めて行う企業は、基礎となるビジネス プロセスを理解し、適切な判断を下す必要があります。

EDIでは、受信トランザクションが受信され、受信者によって処理されたことを送信者に通知する確認応答のメカニズムがいくつか使用されています。 ^[12]

• 通信ステータス – 送信が完了したことを示す
• MDN (メッセージ処理通知) – AS2のみ、メッセージが読み取り可能であることを示す
• 機能確認 – 通常は ANSI では「997」、EDIFACT では「CONTRL」で、メッセージの内容がテンプレートに対して検証されたことを示し、トランザクションが受信者の電子システムに投稿されたかどうかを通知します。
• ビジネス レベルの確認 – 最終インジケーターは、トランザクションが受信者によって承認されたかどうかを示します。

• 経費および費用回収システム (ECRS)
• 抽出、変換、ロード (ETL)
• 法的電子データ交換標準 (LEDES)
• 海事データ標準

• ゲンゲスワリ、K. およびアブ・バカール・アブドゥル・ハミド (2010)。 「電子データ交換の統合: レビュー」、ジャーナル ケマヌシアン、ISSN  1675-1930
• Notto, Ralph W.「課題と結果: Eコマースへの変革の強制」、Fenestra Books。2005年、ISBN 158736414X 

• 「電子調達 — 電子データ統合の成熟」2021年5月14日アーカイブ-ファイナンスディレクターヨーロッパジャーナルの記事
• EDI プロトコル – EDI ネットワークで使用されるさまざまなプロトコルと形式の概要
• EDI 標準 – 利用可能なさまざまな EDI ファイル形式標準の概要。