什麼是 EDI?如何讓企業間的訂購作業更輕鬆 ── 從傳真、電子郵件、手動輸入邁向資料連動
· Go Komura · EDI, 企業間交易, 訂購作業, 業務效率化, 系統整合, BtoB, DX
「交易對象透過傳真送來訂購單,承辦人員將其輸入至銷售管理系統」
「開啟電子郵件附加的 Excel 檔案,確認商品代碼與數量後進行抄錄」
「交貨後開立請款單,對方也將同樣的內容輸入至會計系統」
在企業間的交易中,相同的訂購資訊或請款資訊,有時會由多家公司、多位承辦人員反覆輸入好幾次。
而能夠減少這種重複輸入、讓下單、接單、出貨、請款等資料直接在企業之間往來的機制,就是 EDI。
一提到 EDI,或許會讓人聯想到大企業使用專用線路導入的大規模系統。但其本質其實單純得多。
EDI 是一種機制,讓來自交易對象的資訊不再需要由人重新閱讀並輸入,而是直接作為電腦可以處理的資料進行交換。
本文將以訂購作業為例,整理說明 EDI 是什麼、它與傳真、電子郵件有何不同,以及導入後企業業務會如何變得更輕鬆。
1. 先說結論
EDI 是 Electronic Data Interchange 的縮寫,中文稱為「電子資料交換」。
這是一種企業之間,將訂購單、出貨通知、請款單等交易資訊,以事先約定好格式的電子資料進行交換的機制。
JIPDEC 將 EDI 說明為企業或行政機關等透過網路連接電腦,自動地以電子資料交換單據或文件的機制。
導入 EDI 的目的並非單純消除紙本。
其主要目的是減少以下這類作業:
- 一邊看傳真或 PDF 一邊進行的手動輸入
- 從 Excel 抄錄至銷售管理系統
- 目視確認輸入內容
- 尋找訂購單或請款單的作業
- 用來確認訂單狀況的電話或電子郵件
- 銷售、庫存、請款資料的重新彙總
一言以蔽之,EDI 是讓原本停滯在公司與公司之間的資料,能夠直接流動起來的機制。
2. 沒有 EDI 的訂購作業中,正發生著什麼事
首先,來思考一下沒有使用 EDI 的訂購作業。
在下單方的公司,採購承辦人員會用自家的系統或 Excel 製作訂購內容,將其列印成訂購單,透過傳真或電子郵件送給交易對象。
在接單方,承辦人員會確認送達的訂購單,並將其輸入至自家的銷售管理系統。
之後,會製作接單確認書、出貨通知、送貨單、請款單等,再送回給下單方。下單方也會將這些資訊輸入至庫存管理系統或會計系統。
下單方輸入訂購資料
↓
訂購單列印・轉為 PDF
↓
以傳真或電子郵件寄送
↓
接單方確認內容
↓
重新輸入至接單方的系統
↓
製作出貨、請款資料
↓
下單方再次輸入至自家系統
在這個流程中,同樣的資訊會被輸入好幾次。
例如商品代碼、商品名稱、數量、單價、交期、送貨地點等等。
最初的訂購資料其實早已存在於下單方的電腦裡。儘管如此,因為被轉換成紙本或 PDF,接單方還是得由人重新閱讀,再重新輸入到電腦裡。
問題並不在於資訊沒有電子化。
而是原本已經製作成資料的資訊,被轉換成供人閱讀的文件,然後在對方那一端又再次轉回資料。
3. 使用 EDI 之後,訂購作業會如何改變
使用 EDI 之後,在下單方系統中製作的訂購資料,會被轉換成接單方系統可以讀取的格式,直接傳送過去。
在接單方,承辦人員不再需要一邊看訂購單一邊輸入,而是直接將接收到的資料匯入銷售管理系統。
flowchart LR
A[下單方的採購系統] --> B[訂購資料]
B --> C[透過 EDI 傳送・轉換]
C --> D[接單方的銷售管理系統]
D --> E[接單確認]
D --> F[出貨通知]
D --> G[請款資料]
E --> C
F --> C
G --> C
C --> A
從下單方將訂購資料送往接單方,再由接單方將接單確認、出貨、請款等資料回傳給下單方。
重點在於,不需要經過人一邊看文件一邊抄錄的環節,資料是直接從系統傳到系統。
JIPDEC 將 EDI 說明為一種機制:把各企業自有格式的資料轉換成標準格式,接收端也同樣會將標準格式轉換成自家的格式。
4. EDI 與電子郵件、PDF、Excel 有何不同
有時會有人認為「訂購單已經做成 PDF 用電子郵件寄送了,已經算是電子化了」。
的確,這比郵寄紙本更快,保存也更容易。但如果接收方仍然是一邊看 PDF 一邊輸入到系統中,那麼輸入作業本身其實還存在。
整理一下差異,如下表所示:
| 方式 | 傳送給對方 | 對方端的處理 | 重新輸入 |
|---|---|---|---|
| 紙本・郵寄 | 寄送紙本 | 看文件輸入 | 需要 |
| 傳真 | 以影像方式傳送 | 看傳真輸入 | 需要 |
| PDF 透過電子郵件寄送 | 以電子文件方式傳送 | 看 PDF 輸入 | 需要 |
| Excel 透過電子郵件寄送 | 傳送檔案 | 確認內容、加工、匯入 | 依方式而定 |
| EDI | 以約定好的資料格式傳送 | 系統直接匯入 | 原則上不需要 |
JIPDEC 的說明 中,將單據掃描而成的影像,或以一般文章形式撰寫的電子郵件,與電腦可以再處理的 EDI 資料做出區分。此外,在網頁畫面上由人手動輸入的方式,嚴格來說也與電腦之間的自動交換不同。
不過,使用 PDF 或 Excel 本身並不是壞事。
重要的是收到的資訊之後是如何被處理的。
- 由人看著 PDF 輸入
- 開啟 Excel 後複製貼上
- CSV 直接匯入系統
- 透過 API 自動登錄
即使同樣是「電子檔案」,後續作業的負擔也大不相同。
在判斷 EDI 的效果時,不能只看傳送方式,還必須看接收之後人做了什麼。
5. EDI 可以交換的資訊
EDI 並不只是用於訂購單的機制。
它可以交換企業間交易中發生的各種資訊。
| 業務階段 | 交換資料範例 |
|---|---|
| 報價 | 報價需求、報價回覆 |
| 下單 | 訂單、訂單變更、訂單取消 |
| 接單 | 接單確認、交期回覆 |
| 出貨 | 出貨預定、出貨實績、貨運單號 |
| 進貨・驗收 | 進貨實績、驗收結果 |
| 請款 | 請款明細、請款更正 |
| 付款 | 付款通知、匯款明細 |
例如,在收到下單資料的當下,接單方的系統就可以進行以下處理:
- 確認訂單編號是否重複
- 確認商品代碼是否存在
- 進行庫存分配
- 計算交期
- 向倉庫發出出貨指示
- 向下單方回傳接單確認
此外,出貨後還可以根據出貨實績登記銷售額,並製作請款資料。
也就是說,EDI 並不只是單純的通訊功能。
它以訂購作業為入口,成為連結後續庫存、出貨、銷售、請款的基礎。
6. EDI 如何讓企業業務更輕鬆
6.1. 可以減少手動輸入與抄錄
最容易理解的效果就是手動輸入的減少。
一邊看傳真送達的訂購單,一邊輸入商品代碼、數量、單價、交期的作業將變得不再需要。
減少手動輸入之後,承辦人員就能把時間用在輸入以外的例外處理上,例如:
- 庫存不足的訂單
- 交期與平常不同的訂單
- 商品代碼尚未登錄的訂單
- 大宗訂單
- 需要確認單價或合約條件的訂單
不再由人處理所有訂單,而是改為一般訂單自動處理、只有有問題的訂單才由人確認的形式。
6.2. 可以減少輸入錯誤
由人進行的輸入作業,一定機率下會發生錯誤。
- 商品代碼輸入錯一個字
- 數量輸入成 100 個而不是 10 個
- 送貨地點搞混
- 誤讀希望交期
- 同一筆訂單被重複登錄兩次
即使使用 EDI,如果原始資料本身有誤,問題還是會發生。但由於正確製作好的資料不需要在對方端重新輸入,因此可以減少因抄錄而產生的錯誤。
中小企業廳 也將訂購作業數位化的效果列為提升作業效率、減少人為疏失、提升交易記錄的檢索性。
6.3. 可以加快接單處理速度
在傳真或電子郵件的情況下,接單處理要等到承辦人員注意到收件、確認內容、完成輸入之後才會開始。
訂單較多的日子會出現輸入待處理的積壓。若承辦人員休假,處理也可能因此延遲。
在 EDI 中,接收到的資料可以自動匯入系統。
在收到訂單後,可以立即開始進行:
- 訂單受理
- 庫存確認
- 交期計算
- 向倉庫發出出貨指示
- 回覆接單確認
等處理。
接單處理加快,出貨所需的時間也會更容易縮短。JIPDEC 也將 EDI 的效果列為事務作業迅速化、前置時間縮短、庫存壓縮等。
6.4. 更容易確認訂單狀況
當紙本、傳真、電子郵件、Excel 混雜在一起時,要查明「那筆訂單現在的狀況如何」需要花不少時間。
必須依序確認承辦人員的信箱、共用資料夾、紙本檔案、銷售管理系統等等。
在 EDI 中,可以以訂單編號等為基準,將以下資訊關聯起來管理:
- 何時收到訂單
- 是否已正常匯入
- 是否已回覆接單確認
- 是否已出貨
- 是否已驗收
- 是否已請款
- 是否發生過錯誤或重新傳送
即使收到詢問,也不需要依賴承辦人員的記憶或私人電子郵件,而是可以從處理歷程中確認。
6.5. 可以連結至庫存、出貨、會計業務
EDI 的效果並不只是減少接單承辦人員的輸入作業。
透過將接收到的資料與內部系統連動,後續流程也能夠自動化。
訂購資料
↓
接單登錄
↓
庫存分配
↓
出貨指示
↓
銷售登記
↓
製作請款資料
↓
沖銷入帳
反過來說,即使透過 EDI 收到了訂購資料,如果還是將其列印出來由人輸入銷售管理系統,效果就會相當有限。
JIPDEC 也說明,若透過 EDI 收到的資料沒有匯入公司內部系統,而是列印出來以人工處理,那就與傳真沒有太大差別。
導入 EDI 並不只是導入與交易對象之間的通訊,接收到的資料要流入公司內部業務到什麼程度,才是關鍵所在。
6.6. 交易資料可以用於經營判斷
以紙本或 PDF 收到的訂購單,即使保存下來,也難以用來彙總分析。
在 EDI 中,交易資訊會以結構化資料的形式累積。
因此,可以進一步連結到以下這類分析:
- 各商品的接單量
- 各交易對象的銷售趨勢
- 各星期別、時段別的訂購傾向
- 交期延遲的發生狀況
- 缺貨較多的商品
- 從訂購到出貨所需的時間
- 退貨或更正較多的交易
JIPDEC 也表示,除了庫存分配、生產調度、進出貨驗收、應收帳款登記等日常業務外,EDI 資料還可以活用於暢銷商品分析、需求預測等方面。
透過 EDI 建立起可以彙集資料的狀態,不僅有助於業務效率化,也是未來庫存最佳化與需求預測的前提。
7. 用簡單的例子思考 EDI 的效果
假設某家批發公司,一天透過傳真或電子郵件收到 100 筆訂單。
假設將一筆訂單輸入銷售管理系統並確認內容,平均需要 3 分鐘。
100 筆 × 3 分鐘 = 300 分鐘
也就是說,每天要花費 5 小時在訂單輸入與確認上。
假設導入 EDI 之後,其中 80 筆能自動匯入,剩下 20 筆才由人確認。
20 筆 × 3 分鐘 = 60 分鐘
雖然是簡化過的例子,但輸入作業從 5 小時縮減為 1 小時。
實際上,除此之外還可能減少以下這些時間:
- 確認難以判讀的傳真
- 更正輸入錯誤
- 用來確認訂單內容的電話
- 尋找訂購單的作業
- 訂單清單的彙總
- 承辦人員之間的交接
導入 EDI 的效果,並不只是「減少紙張費用」這類直接成本。
真正的意義在於能夠減少每天反覆發生的小型確認、輸入、更正作業。
8. 依部門來看 EDI 的優點
EDI 帶來的業務改善,並不僅限於接單部門。
| 部門 | 導入 EDI 前的作業 | 導入 EDI 後可期待的變化 |
|---|---|---|
| 業務・接單 | 看訂購內容輸入 | 一般訂單自動登錄,只確認例外情況 |
| 採購 | 製作發包單並寄送 | 從採購系統直接傳送 |
| 倉庫 | 接收紙本出貨指示 | 從接單資料製作出貨指示 |
| 財會 | 重新輸入請款明細 | 從銷售資料製作請款資訊 |
| 管理階層 | 用 Excel 彙總實績 | 從累積的交易資料彙總 |
| 詢問窗口 | 尋找電子郵件或紙本 | 依訂單編號確認處理狀況 |
EDI 能夠減少的,不只是單純的輸入工時。
由於資訊的所在位置變得明確,即使不是負責承辦人員,也能容易掌握狀況,因此也能減輕業務對特定個人的依賴。
9. 導入 EDI 並不代表所有事情都能自動化
EDI 是很方便的機制,但並非導入之後所有作業就能自動化。
9.1. 需要與交易對象進行協商
企業之間要交換資料,至少需要決定以下事項:
- 要交換哪些資訊
- 使用哪種資料格式
- 何時收發
- 訂單變更或取消要如何處理
- 發生錯誤時該怎麼辦
- 相同資料重複傳送時要如何處理
- 在哪個時間點正式成立訂單
在 EDI 中,不只是通訊方式,資料項目與業務營運規則也同樣重要。JIPDEC 也整理出需要協商通訊協定、資料格式、訊息項目、發生錯誤時的因應方式、交易基本規約等。
9.2. 需要統一商品代碼等項目
下單方與接單方,有時會對同一項商品使用不同的代碼。
例如下單方的商品代碼是 A-001,接單方則是 100245 這樣的情況。
在這種情況下,需要一份用來轉換代碼的對照表。
除了商品代碼之外,也需要整理以下項目:
- 交易對象代碼
- 送貨地點代碼
- 單位
- 入數(每包裝數量)
- 稅別
- 貨幣
- 日期格式
- 字元編碼
即使能夠收發資料,只要項目的意義不一致,就無法構成正確的交易。
9.3. 例外處理仍然存在
即使一般訂單能夠自動處理,例外性的交易仍然會存在。
- 庫存不足
- 停產商品
- 與平常不同的價格
- 緊急訂單
- 訂單變更
- 訂單取消
- 分批交貨
- 退貨
- 資料缺失
重要的是,並非要勉強將所有事情都自動化。
將一般處理與例外處理分開,一般處理自動化,只有需要判斷的部分才交給人處理,這樣的設計才務實。
9.4. 會出現與傳真、電子郵件並行的過渡期
並非所有交易對象都能同時轉換至 EDI。
因此,在導入初期,有時會出現以下多種接單方式並行的情況:
- EDI
- 網頁畫面
- CSV 上傳
- 電子郵件
- 傳真
- 電話
在這種狀態下,即使導入了 EDI,也無法立即減少負責既有業務的人力。
要提高 EDI 的效果,必須從交易量較大的交易對象開始依序轉移,逐步減少以人工處理的件數。JIPDEC 也指出,如果仍保留傳真或電話等人工處理,就需要相應的人力來對應,因此難以充分獲得效率化的效果。
10. 適合導入 EDI 的企業
EDI 特別容易在以下這類企業中發揮效果:
- 每天或每週都與相同的交易對象進行訂購
- 訂單件數或明細數量較多
- 目前是從傳真或電子郵件抄錄至系統
- 曾發生輸入錯誤或重複登錄
- 確認訂單的電話或電子郵件較多
- 接單之後還會接續庫存、出貨、請款的處理
- 承辦人員休假時處理就會停滯
- 彙總訂單歷程或交易狀況需要花費不少時間
另一方面,對於一年只交易幾次的對象,或每次訂購內容都大幅不同的交易,EDI 的建置與營運成本有時可能會超過其效果。
是否要導入 EDI,不應該只依公司規模來判斷。
中小企業廳 也為中小企業建立了用來標準化訂購作業的「中小企業共通 EDI」,展現出透過減少專用終端與紙本、將單據以資料方式集中管理,來達成業務效率化的做法。
應該關注的不是員工人數,而是反覆發生的輸入、確認、抄錄的數量。
11. 檢討導入 EDI 時的進行方式
在檢討 EDI 時,並不需要一開始就選定產品或通訊方式。
首先,應該先整理現有的業務。
11.1. 將目前的訂購方式製成清單
依交易對象,整理以下資訊:
| 確認項目 | 內容 |
|---|---|
| 交易對象 | 與哪家公司交易 |
| 訂單件數 | 一天・一個月有幾件 |
| 接單方式 | 傳真、電子郵件、網頁、CSV 等 |
| 輸入目的地 | 銷售管理、Excel、核心系統等 |
| 輸入時間 | 每件需要多少分鐘 |
| 錯誤 | 發生過哪些更正 |
| 後續流程 | 如何連結至庫存、出貨、請款 |
| 例外 | 哪些訂單需要人工判斷 |
進行這樣的整理後,就能看出 EDI 化效果較大的交易對象或業務。
11.2. 從交易量最大的一家公司開始
如果一開始就以所有交易對象為對象,需要協調的項目會增加,導入時間也會拉長。
較務實的做法是,先選擇一家符合以下條件的交易對象:
- 交易件數較多
- 定型化的訂單較多
- 承辦人員之間容易聯繫
- 對系統整合有一定理解
- 效果容易衡量
在一家公司建立起運作方式之後,再推廣到其他交易對象。
11.3. 縮小交換對象的範圍
一開始並不需要將報價、接單、出貨、驗收、請款、付款全部納入對象。
例如,可以先將輸入負擔最大的訂購資料進行 EDI 化。
第一階段:訂購資料
第二階段:接單確認・交期回覆
第三階段:出貨通知
第四階段:請款資料
透過逐步增加對象範圍,可以在抑制對現場影響的同時確認效果。
11.4. 確認與公司內部系統的連接
即使導入了 EDI 服務,若無法將資料匯入既有的銷售管理系統,手動輸入的作業仍然會留存下來。
事前應確認以下幾點:
- 是否具備 CSV 輸出入功能
- 是否可以使用 API
- 是否能與資料庫連動
- 商品代碼轉換要在哪裡進行
- 如何防止接收資料重複
- 錯誤要通知給誰
- 處理歷程要保留在哪裡
在選定產品之前,先確認與既有系統的連接方式是很重要的一步。
12. 導入 EDI 之後應該衡量的指標
導入 EDI 之後,不應該就此止步於「已經可以使用了」,而是要確認業務究竟改變了多少。
例如,可以在導入前後比較以下指標:
- 接單輸入所需的時間
- 處理一筆訂單所需的時間
- 輸入更正的件數
- 重複登錄的件數
- 訂單確認的詢問件數
- 出貨延遲的件數
- 能夠透過 EDI 處理的訂單比例
- 由人確認的例外訂單比例
EDI 中重要的並不是能否傳送資料。
而是要以手動作業是否真的減少、處理是否變快、錯誤是否減少來評估。
總結
EDI 是一種機制,讓企業之間發生的訂購、出貨、請款等資訊,能夠以電腦可以直接處理的電子資料形式進行交換。
只是把傳真改成電子郵件,紙張雖然減少了,但手動輸入的作業有時依然存在。
EDI 真正的效果,在於能夠將從交易對象收到的資料,直接連結至銷售管理、庫存、出貨、會計等公司內部系統。
透過 EDI 可以期待的主要變化如下:
- 減少一邊看訂購單一邊進行的手動輸入
- 減少因抄錄而產生的輸入錯誤
- 加快從接單到出貨的處理速度
- 讓訂單或請款的處理狀況更容易確認
- 將庫存、出貨、銷售、請款串連起來
- 將累積的交易資料用於彙總或需求預測
- 減少依賴特定承辦人員的業務
不過,光是簽約導入 EDI 服務並不足夠。
還需要整理商品代碼等資料,與交易對象約定好營運規則,並讓資料能夠匯入既有的公司內部系統。
導入 EDI 的出發點,並不是「要使用哪一個產品」,而是調查目前業務中,同樣的資訊究竟被輸入了幾次。
找出在傳真、電子郵件、Excel、網頁畫面、銷售管理系統之間由人搬運資訊的地方,並從中挑選件數多、屬於定型化的業務,依序改為資料連動,這才是務實的做法。
給正在考慮導入訂購業務資料連動的您
若想提升企業間訂購作業的效率,卻不知道該從何著手檢視目前的傳真、電子郵件、Excel 運用方式,首先需要整理業務的流程。
只要確認交易對象是以何種格式提供資訊、輸入到公司內部的哪個系統、之後又如何連結至庫存、出貨、請款,就能看出可以自動化的範圍。
合同會社小村軟體(合同会社小村ソフト)可以為您整理現況,並就包含既有 Windows 業務應用程式、CSV・固定長度檔案、資料庫、網頁系統等在內的業務整合,提供實現方式的檢討諮詢。
我們也能夠在不以全面重建為前提的情況下,檢討保留現有架構、僅減少手動輸入部分的方案。
相關文章
共用相同標籤的最新文章。能以相近的主題延伸理解。
什麼是數位發票(Digital Invoice)?──與「把請款單 PDF 寄送 email」有何不同
數位發票是指將請款資訊從賣方系統直接以資料形式傳遞給買方系統、無需人工介入的機制。本文將淺顯解說它與 PDF 請款單的差異、與日本發票制度(Invoice 制度)的關係、Peppol・JP PINT 的運作方式、與電子帳簿保存法的關聯,以及中小企業的入門方法。
把 FAX 收單搬到網路上 ── 雙軌並行期的設計與分階段轉移實務
說明將 FAX 收單轉移到網路收單或 CSV 匯入的實務作法。整理一次性全面網路化容易失敗的原因、FAX 與網路雙軌並行期的設計、商品與客戶主檔的整備、CSV 匯入這種中間形態,以及如何讓客戶配合的分階段轉移步驟。
PowerShell 實用指令集錦 ── 累積日常工作常用的小工具
本文整理 PowerShell 日常工作中常用的實用指令,說明 Measure-Object、Group-Object、Select-String、Compare-Object、Tee-Object、Start-Transcript 等指令的使用場景與時機。
Windows 應用程式的工作列通知區常駐與 Toast 通知 —— NotifyIcon 的陷阱與 AppNotification 的選型
本文整理將業務用 Windows 應用程式常駐於工作列通知區,並透過 Toast 通知告知使用者的實作要點。內容涵蓋 NotifyIcon 的正確用法與「關閉後仍留在通知區」的設計、檔案總管重新啟動時的重新註冊、三種 Toast API(Windows App SDK Ap...
從 WordPress 遷移到 Movable Type ── 正因為是「反方向」,更該整理清楚的實務步驟
從實務角度解說從 WordPress 遷移到 Movable Type(MovableType.net)的步驟。整理遷移合理的情境、文章與固定頁面及圖片的匯入、自訂文章類型的處理方式、透過 URL 設計與 301 轉址延續 SEO 成效,以及外掛功能的替代方案。
相關主題
與本文相近的主題頁面。以本文為起點,可進一步連到相關服務與其他文章。
Windows 技術主題
彙整 KomuraSoft LLC 關於 Windows 開發、故障調查與既有資產活用文章的主題中心。
與本主題相關的服務
本文連結到以下服務頁面,歡迎從最接近的入口查看。
Windows 應用程式開發
評估並實作將既有的 Windows 業務應用程式與 CSV、固定長度檔案、資料庫、網頁系統連接起來的架構,正是業務應用程式開發諮詢的範疇。
Windows 軟體維護 & 現代化
不以全面重建為前提,在保留既有系統的同時逐步減少手動輸入與抄錄作業的改造,屬於既有 Windows 軟體的改造與維護範疇。
技術諮詢 & 設計審查
整理與交易對象之間的資料格式、營運規則、例外處理,並決定要自動化到什麼程度,這項作業屬於伴隨設計審查的技術諮詢。
作者檔案
本文作者的個人檔案頁面。
Go Komura
小村軟體有限公司 代表
以 Windows 軟體開發、技術諮詢與故障調查為中心,在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。