電子資料交換 (EDI)

所有的 EDI 交易都由 EDI 訊息標準負責定義。安排適當控管程序來維護資料品質很重要。當資訊遺漏或出現在錯誤的地方時，可能就無法正確處理 EDI 文件。

標準是 EDI 交談 的基礎。² 有很多組織定義了 EDI 訊息標準，包括 ODETTE、TRADACOMS、GS1、Peppol 及 Accredited Standards Committee X12 (ASC X12)。

一般來說，EDI 傳輸分成兩種基本類型：

• 點對點或直接連線。兩台電腦或系統在無媒介的情況下，透過網際網路進行連線，通常會使用安全通訊協定。
• 加值型網路 (VAN)。協力廠商網路是使用郵箱參照範例來管理資料傳輸。

EDI 網際網路傳輸通訊協定包括安全檔案傳送通訊協定 (SFTP)、Applicability Statement 2 或 AS2、HTTPS 型通訊協定、簡易物件存取通訊協定 (SOAP) 及其他。

EDI 資料元素包括傳送端 ID 和接收端 ID 之類的項目。資料區段結合兩個或多個相關元素，以賦予它們更大的意義 - 例如，FNAME 與 LNAME 可以結合起來形成 CUSTOMERNAME。封套架構不同類型的資料，並攜帶傳送端和接收端位址資訊。EDI 文件流程或訊息流程說明 EDI 訊息移動到各種入埠和出埠位址和部門，以執行商業程序或交易的過程。³

像可延伸標記語言 (XML) 或 JavaScript 物件表示法 (JSON) 的中繼語言是用來補充而非取代 EDI。公司必須準備好處理為數越來越多的文件格式和傳輸選項。一家全球製造商要與將近 2,000 個合作夥伴定期交換大約 55 種不同的文件類型。 

「在我們開始使用 IBM Supply Chain Business Network 之前，有高達 20% 的 B2B 交易會發生錯誤。我們現在比較少發生錯誤，舉例來說，我們以前常因客戶提交錯誤代碼而產生轉移訂單的問題，這對我們的客戶服務團隊來說很痛苦。現在這類情況少了大概 80%，因為以前都是手動處理。」閱讀其他 EDI 管理者告訴 IDC 他們如何利用 IBM Sterling Supply Chain Business Network 來推動策略價值。

對某些企業來說，EDI 可能很難實作。其中一個原因是，需要跟上不斷變遷的政府法規、標準及更新項目。它本身也很複雜，因為它需要適應全球商業需求的複雜性。例如，B2B 網路中的每個交易夥伴可能會有個別需求。即使兩個交易夥伴協議好要使用哪一種 EDI 文件，但可能各有需要支援的獨特格式化需求。這些因素和其他因素導致許多組織將他們的 EDI 解決方案委外。

無論是內部自製或委外，都需要具備一些基本條件、能力和資源才能有效實作 EDI。除了協議文件類型、安全傳輸方法及必備軟硬體等因素之外，有效的 EDI 實作還應該考量：

• 轉換或對映軟體。取得名稱、地址、貨幣金額、零件號碼和數量等欄位，並將其從商業應用程式格式對映至標準化文件，反之亦然。
• 批次封套或解除封套功能。支援大型 EDI 訊息批次，讓傳送端和接收端能夠包裝及解除包裝交易，然後就可以從交易夥伴的數個業務部門或領域將這些交易集合在一起，或將這些交易分成數個業務部門或領域。
• 訊息遞送機制。在訊息解除封套時用以為不同群組排序訊息，並將訊息遞送至適當目標。另外可能還需要進行訊息轉換，使訊息轉換成適用於其目的地的正確格式。
• 交易夥伴合約 (TPA)。釐清條款、建立商業文件的標準，以及定義交易夥伴之間的通訊和商業通訊協定。