PPT_補充

核心面向

教材重點

學習成果

協同基礎

上下游共享需求、庫存、促銷、產能與物流資訊，避免各自重複預測。

能解釋資訊延遲、需求失真與長鞭效應。

CPFR 流程

依共同規則進行規劃、預測、例外協調，再形成訂單與補貨。

能掌握三階段、九步驟及主要資料流。

配套與落地

結合 VMI、凍結期間、例外管理、資料標準與共同 KPI。

能設計協同採購、設計、製造、物流與行銷的導入條件。

教學步驟

教學內容

教學目的

建議輸出成果

第一步

建立八大資料分類：誰、哪份文件、哪一天、多少錢、什麼貨、從哪到哪、要交什麼文件、其他條件。

讓學生先看懂信用狀與貿易單據其實都在回答同一組問題。

八大分類表。

第二步

說明 LC 欄位總表與常見 MT SWIFT Tag。

讓學生理解 20、50、59、32B、45A、44、46A、47A 等欄位用途。

LC 欄位分類表。

第三步

整理四種常見單據：匯票、商業發票、包裝單、裝運單。

讓學生理解每種單據的功能，而不是把每個欄位都硬對應 ISO 20022。

每一種表格整理版。

第四步

整理重複項目：信用狀號碼、買方、賣方、金額、貨物、起訖地、單據要求。

讓學生知道審單重點是跨文件一致性。

高頻欄位與容易混淆欄位表。

第五步

引入 ISO 20022：不是直接把 MT Tag 改成 XML Tag，而是建立共同資料元素。

讓學生理解 ISO 20022 的核心是語義標準化與結構化資料。

MT 概念到 ISO 20022 概念表。

第六步

強調 AI 核單與供應鏈金融。

讓學生理解 ISO 20022 的現代價值：自動對帳、合規篩查、融資審核、風險控管。

AI核單表、供應鏈金融表。

核心面向

MT SWIFT 的限制

ISO 20022 的進步

對貿易單據 / 供應鏈金融的意義

語義標準化

MT 以固定 Tag 與半結構化文字表示資料，學生常只是在背代碼。

以共同資料字典、資料元素與 business components 描述付款人、收款人、金額、日期、地址、銀行與文件識別。

同一筆交易資料可跨 LC、匯票、發票、裝運資料與付款資料比對。

AI 核對單據

自由文字多，AI 或系統需先猜欄位意思，容易誤判。

資料更結構化、欄位更明確，適合機器讀取與規則比對。

AI 可自動核對受益人、申請人、金額、幣別、發票號碼、裝運港、卸貨港與付款用途。

自動對帳

匯款附言常不完整，企業財務需人工找款、沖帳。

structured remittance information 可放入發票號、訂單號、付款用途等資料。

有助企業快速把付款連到發票、訂單、出貨與 LC。

供應鏈金融

銀行審核融資時需人工比對訂單、發票、出貨、付款資料。

付款與交易資料更完整，有利風控、融資審核與交易真實性判斷。

可加快放款、降低偽造單據風險，改善中小出口商資金週轉。

合規與風控

姓名、地址、國家與金融機構資訊常混在文字裡，不利篩檢。

可使用結構化 party、agent、address、purpose code 等欄位。

改善 KYC、AML、制裁篩查、反詐騙與異常交易判斷。

資料治理與未來應用

MT 適合傳統銀行電文，不利 ERP、API、BI、AI 深度整合。

ISO 20022 可作為跨銀行、企業、清算系統與資料平台的共同語言。

支援 ERP/TMS/SCM、API、Power BI、AI Agent、數位貿易與即時支付。

比較項目

MT SWIFT

ISO 20022 / MX

教學重點

基本形式

以 Tag 為中心，例如 20、31C、32B、45A。

以結構化資料元素為中心，通常使用 XML 語法。

MT 是欄位代碼；ISO 20022 是資料模型。

資料方式

短代碼加半結構化文字。

標準化、可重複使用、可機器讀取的資料元素。

ISO 20022 較適合自動審單、資料交換、AI 檢核。

使用邏輯

每個 MT 類別有自己的欄位格式。

使用共同資料字典、business components 與 message definitions。

同一個人、金額、日期、地點可在不同訊息重複使用。

優點

簡短、銀行業熟悉、歷史久。

資料更豐富、結構更清楚、跨系統互通性較佳。

理解資料標準化與資料治理。

缺點

文字欄位多，容易有歧義，也不利完整自動化。

結構較複雜，初學者不易直接閱讀。

教學上應先從 MT 入門，再轉 ISO 20022。

與 LC 關係

MT 700 系列是傳統信用狀與保證業務的重要訊息類別。

ISO 20022 不應教成每個 MT Tag 直接等於某個 XML Tag，而應教成共同資料元素。

先理解欄位用途，再理解資料模型。

原因

MT 時代的限制

ISO 20022 的改善

具體效果

資料結構更清楚

資料常放在自由文字欄位，欄位意義需要人工判讀。

把人、地址、金額、日期、銀行、匯款資訊拆成結構化元素。

有利 AI 核單、付款比對、合規篩檢與自動對帳。

資料更豐富

欄位容量有限，發票、地址、交易背景與付款用途常不足。

可承載更豐富、更細緻、更具語義的資料。

企業可更容易把付款連到發票、訂單、LC 或供應鏈金融資料。

減少人工介入

半結構化文字容易造成解讀差異。

標準化資料有利 straight-through processing。

降低手動修正、退件、延誤與營運成本。

提高透明度

付款鏈中資料可能被截斷、改寫或遺失。

ISO 20022 有利保留完整端到端交易資料。

有助跨境付款透明、客戶服務與風險控管。

支援合規與監管

非結構化資料不利自動合規檢核。

結構化姓名、地址、國家、金融機構與用途資料利於篩檢。

更符合反洗錢、制裁篩查、KYC 與監理資料需求。

支援數位貿易

MT 適合傳統銀行電文，不適合與 ERP、API、AI、資料平台深度整合。

ISO 20022 可作為跨系統共同語言。

可連接 ERP、TMS、SCM、財務系統、BI 與 AI 工具。

科學分類

資料類型

常見 MT SWIFT

出現在哪些單據

ISO 20022 教學概念

A. 關係人

誰對誰負責

50、59、42A、41A、53A、57A

LC、匯票、發票、裝運單

Party / Financial Institution / Agent

B. 文件種類

文件號碼、信用狀號碼、契約號碼

20、27

LC、匯票、發票

Identification / Reference

C. 日期與期限

開狀日、到期日、裝運期限、提示期限

31C、31D、44C、48、42C

LC、匯票、發票

Date / Expiry / Tenor

D. 金額與幣別

信用狀金額、發票金額、匯票金額

32B、39A、39B

LC、匯票、發票

Currency / Amount / Tolerance

E. 貨物描述

品名、數量、單價、總額、嘜頭

45A

LC、發票、包裝單、裝運單

Goods / Trade Terms

F. 運送規定

裝運港、卸貨港、轉運、分批

43P、43T、44A/E、44B/F

LC、發票、裝運單

Transport / Origin / Destination

G. 單據要求

發票、包裝單、提單、保險單、證明書

46A

LC、裝運單

Required Documents

H. 其他事項

費用、利息、提單規定、貼現息

47A、71B、39C

LC、裝運單

Additional Conditions / Charges

MT SWIFT

中文名稱

教學說法

ISO 20022 概念

SENDER

開狀銀行

發出信用狀的銀行

Issuing Bank / Sender FI

RECEIVER

通知銀行

收到並通知信用狀的銀行

Advising Bank / Receiver FI

50

申請人、開狀人

買方／進口商

Applicant / Buyer

59

受益人

賣方／出口商

Beneficiary / Seller

42A

付款銀行

到期付款或承兌的銀行

Drawee / Paying Bank

41A

指定押匯銀行

是否指定某銀行辦理押匯、讓購、付款

Available With Bank

53A

償付銀行

支付銀行間償付款項的銀行

Reimbursing Bank

57A

第二通知銀行

另一家協助通知受益人的銀行

Second Advising Bank

MT SWIFT

中文名稱

教學說法

ISO 20022 概念

40A

信用狀形式

可撤銷、不可撤銷、轉讓、限押等性質

Documentary Credit Type

41D

讓購／可用方式

信用狀是付款、承兌、議付或讓購

Availability / Method of Settlement

49

保兌指示

通知銀行是否加保兌

Confirmation Instruction

MT SWIFT

中文名稱

教學說法

ISO 20022 概念

31C

開狀日期

LC 成立日期

Issue Date

31D

有效期限及地點

最後提示日與提示地點

Expiry Date / Expiry Place

44C

最後裝運期限

最晚何時裝船或出貨

Latest Shipment Date

48

提示單據期限

出貨後幾天內要交單

Presentation Period

42C

付款／押匯期限

即期或遠期，例如 at sight、60 days after B/L date

Tenor / Draft Terms

MT SWIFT

中文名稱

教學說法

ISO 20022 概念

20

信用狀號碼

LC 的主識別碼

Documentary Credit Identification

27

電文頁次

電文分頁，例如 1/1、1/2

Message Sequence

32B

幣別與金額

LC 可使用的總金額

Currency / Amount

39A

金額允許範圍

可多裝或少裝百分比

Tolerance

39B

最高押匯金額

最高可議付或付款金額

Maximum Credit Amount

45A

貨物品名及貿易條件

商品描述、數量、單價、Incoterms

Goods Description / Trade Terms

71B

利息與手續費

誰負擔銀行費用

Charges

MT SWIFT

中文名稱

教學說法

ISO 20022 概念

39C

運費、保險費支付

Freight prepaid / collect 或保險費負擔

Freight / Insurance Charge Terms

43P

是否可分批裝運

Partial shipment allowed or not

Partial Shipment Indicator

43T

是否可轉運

Transshipment allowed or not

Transshipment Indicator

44A/E

裝運港／機場

出貨地、收貨地、裝運港

Place of Taking in Charge / Port of Loading

44B/F

卸貨港／機場

目的港、交貨地

Port of Discharge / Final Destination

MT SWIFT

中文名稱

教學說法

ISO 20022 概念

46A

提示單據種類與規定

要交哪些單據，例如發票、包裝單、提單、保險單等

Required Documents

47A

其他條款

嘜頭、可接受提單、簽發人、貼現息負擔等

Additional Conditions

Ref

欄位

MT SWIFT

教學重點

E01

匯票號碼

—

匯票自身編號，不一定有 MT Tag

E02

匯票金額，小寫

32B

對應 LC 金額與幣別

E03

開票日期與地點

48

PPT 對應提示期限；教學上要說明日期本身與提示期限不同

E04

匯票期限

42C

即期或遠期

E05

受款人

賣銀

非標準 Swift Tag，代表賣方銀行或指定受款人

E06

匯票金額，大寫

大寫

非標準 Swift Tag；用於防止金額誤讀

E07

信用狀號碼

20

連回 LC 主檔

E07 / 註記

開狀日期

31C

原資料 Ref 重複，可在教材中註記或改為 E08

E08

付款人

42A

匯票付款義務人

E09

開票人

59

多為受益人／出口商

Ref

欄位

MT SWIFT

教學重點

I01

發票號碼

—

發票自身識別碼

I02

發票日期

—

發票簽發日期

I03

貨品名稱及數量

45A

應與 LC 貨物描述一致

I04

抬頭人

50

通常為買方／申請人

I05

發貨人

59

通常為賣方／受益人

I06

啟航日期

—

運送資訊，應與運輸單據一致

I07

船名、航次等

—

不在 Swift list 上，但審單常用

I08

裝運港

44A/E

與 LC 裝運地一致

I09

卸貨港

44B/F

與 LC 目的地一致

I10

信用狀號碼

20

發票需連回 LC

I11

契約號碼

—

不在 Swift list 上，但商務比對重要

I12

貨運嘜頭及件號

45A

與包裝單、裝運單一致

I13

貨品明細敘述

45A

商品規格、型號、描述

I14

數量

45A

與 LC 可容許範圍、包裝單一致

I15

單價

45A

發票特有的重要欄位

I16

貨物總金額

32B

與 LC 金額、匯票金額比對

I17

大寫金額

大寫

非標準 Swift Tag

I18

其他事項

—

可放貿易條件、補充聲明

I19

發票人簽署

59

與受益人／發貨人一致

Ref

欄位

MT SWIFT

教學重點

P13

包裝件號

件數

非標準 Swift Tag，但物流重要

P14

貨物敘述

45A

應與 LC / Invoice 商品描述一致

P15

貨物數量

45A

與發票數量一致

P16

貨物淨重

—

不在 Swift list 上，但報關與物流重要

P17

貨物毛重

毛重

非標準 Swift Tag

P18

貨物體積

體積

非標準 Swift Tag

P19

裝運貨物總件數，大寫

件數

應與提單、裝運單一致

P20

其他事項

—

可寫包裝方式、特殊標示

P21

發票人簽署

59

與受益人／出口方一致

Ref

欄位

MT SWIFT

教學重點

S01

託運人

59

多與受益人／出口商一致

S02

受貨人

46A

PPT 對應 46A；可補充此為運送單據要求

S03

被通知人

50

常與申請人或其代理人相關

S04

船名及航次

—

不在 Swift list 上，但運輸識別重要

S05

收貨地

44A/E

多式運輸起點

S06

裝運港

44A/E

海運起運港

S07

卸貨港

44B/F

海運目的港

S08

交貨地

44B/F

最終目的地

S09

貨運嘜頭及件號

45A

與發票、包裝單一致

S10

包裝件數或貨櫃數

件數

非標準 Swift Tag

S11

貨物明細

45A

與 LC 貨物描述一致

S12

總毛重

毛重

非標準 Swift Tag

S13

總體積

體積

非標準 Swift Tag

S14

運費

46A

可與 LC 的運費條款、39C、47A 一起說明

S15

貨櫃裝運方式

—

不在 Swift list 上，但物流課程應提及

核心欄位

對應 MT SWIFT

出現單據

記法

信用狀號碼

20

LC、匯票、發票

所有文件的案件號碼

申請人／買方

50

LC、發票、裝運單

買方

受益人／賣方

59

LC、匯票、發票、包裝單、裝運單

賣方

金額與幣別

32B

LC、匯票、發票

錢

貨物描述

45A

LC、發票、包裝單、裝運單

貨

裝運地

44A/E

LC、發票、裝運單

從哪裡出

目的地

44B/F

LC、發票、裝運單

到哪裡去

提示單據

46A

LC、裝運單

要交什麼文件

其他條款

47A

LC、各單據補充欄

例外規定、附加條件

容易混淆項目

差異

50 申請人 vs 59 受益人

50 是買方／開狀人；59 是賣方／收款方。

44A/E vs 44B/F

44A/E 是起點；44B/F 是終點。

32B vs 45A

32B 是金額；45A 是貨物與貿易條件。

46A vs 47A

46A 是要交哪些單據；47A 是其他條件。

42A vs 42C

42A 是付款銀行；42C 是付款期限。

發票金額 vs 匯票金額

發票是交易金額；匯票是要求付款的票據金額。

淨重 vs 毛重 vs 體積

不一定在 Swift list 上，但物流、報關、包裝單非常重要。

AI 核對項目

傳統 MT / 自由文字問題

ISO 20022 幫助

可形成的教學檢核

付款人與收款人

名稱與地址常混在文字欄位中，角色可能不清楚。

可用 Debtor、Creditor、Agent、Ultimate Debtor / Creditor 等結構欄位。

申請人、受益人、發票抬頭、付款人、收款人是否一致。

金額與幣別

金額欄位簡短，若有多張發票或折扣需人工判斷。

Currency + Amount 與 structured remittance 可清楚連接付款與發票。

LC 金額、發票金額、匯票金額、實際付款金額是否相符。

發票與訂單

發票號碼常放在匯款附言中，不易自動對帳。

structured remittance information 可放發票號、訂單號、金額與付款用途。

付款是否對應正確 Invoice / PO / LC。

日期與期限

開狀日、裝運日、付款日、提示期限分散在不同文件中。

日期欄位可結構化，利於跨文件比對。

是否超過 LC 有效期限、裝運期限或提示期限。

地址與國家

地址為自由文字，合規篩查與地區風險判斷困難。

結構化地址與國家欄位可支援 KYC / AML / 制裁篩查。

買方、賣方、銀行、收貨地是否涉及高風險地區。

付款用途

傳統附言可能只寫 invoice payment，資訊不足。

可使用 purpose code 或更結構化的匯款資訊。

付款用途是否符合貿易背景，是否出現異常付款。

貨物與運輸資料

貨物描述、港口、嘜頭多在單據中，銀行付款資料未必能連接。

ISO 20022 可與企業 ERP / TMS / SCM 資料結合，形成交易資料鏈。

貨物描述、裝運港、卸貨港、出貨資料是否與付款交易相符。

異常偵測

人工核單容易漏掉小差異，例如名稱拼法、金額誤差、日期錯置。

結構化資料方便設定規則與 AI 異常偵測。

列出不一致項目、風險原因、需人工確認欄位。

供應鏈金融需求

傳統痛點

ISO 20022 的幫助

對銀行 / 企業的效益

確認交易真實性

銀行需人工比對訂單、發票、出貨、收款紀錄。

付款資料、匯款資訊與交易識別更結構化。

更容易判斷是否有真實交易背景，降低假單據融資風險。

發票融資

付款是否對應哪張發票常不清楚。

structured remittance 可放入發票號、訂單號與金額。

加快發票核對與融資審核。

應收帳款管理

企業財務需人工對帳，收款延遲影響現金流。

可加速 auto-reconciliation 與付款歸戶。

出口商更快確認收款，改善資金週轉。

買方信用判斷

缺乏完整付款流、交易紀錄與對手方資料。

更豐富的付款與對手方資料可進入風控模型。

銀行可更細緻評估買方、賣方與供應鏈風險。

營運資金預測

未來收付款資訊分散，預測困難。

豐富且結構化資料可支援現金流預測。

企業可更有效安排資金、庫存與採購。

放貨與出貨決策

付款確認慢，可能延誤放貨。

付款與匯款資訊更容易連到訂單 / 發票。

可縮短查款時間，使貨物更早放行。

合規與盡職調查

交易背景、對手方、地址、付款用途不足。

結構化資料可支援 compliance、due diligence 與制裁篩查。

降低洗錢、詐欺、制裁與重複融資風險。

中小企業融資

中小出口商常缺乏可被銀行快速採信的資料。

若上下游採用標準化資料，銀行更容易驗證交易。

提升中小企業取得供應鏈金融的可能性。

口訣

說明

20 找案件，50 找買方，59 找賣方，32B 找金額，45A 找貨物，44 找路線，46A 找單據，47A 找條件。

讓學生先建立 MT SWIFT 的基本欄位感。

LC 管規則，發票管金額，包裝單管重量體積，裝運單管路線，匯票管付款。

讓學生理解不同單據的功能分工。

ISO 20022 不是把 Tag 改名，而是把資料變成可交換、可機器讀取、可被 AI 檢核的共同資料元素。

讓學生從代碼記憶轉向資料模型理解。

來源

用途

SWIFT：ISO 20022 官方說明

說明 ISO 20022 作為開放全球金融資訊標準，提供更一致、豐富、結構化的資料。

SWIFT：ISO 20022 for corporates

說明企業可利用結構化匯款資訊改善付款對帳、現金流預測與作業效率。

SWIFT：MT to ISO 20022 Conversion FAQ

僅作背景資料：跨境 FI-to-FI 付款共存期已結束，但本章不以互換與轉換為主。

ISO 20022 標準說明

說明 ISO 20022 作為金融訊息標準與資料模型方法。

項目

ICO

NFT

STO

RWA

核心邏輯

發行 Token 募資

建立數位稀缺性與可交易所有權

把證券以 Token 形式發行

把現實世界資產或金融權利 Token 化

主要成果

降低全球募資門檻；推動智能合約、公鏈與代幣經濟

建立數位所有權市場；催生創作者經濟、鏈遊與社群會員模式

把證券發行重新納入 Know Your Customer（認識你的客戶，KYC）、Anti-Money Laundering（防制洗錢，AML）、揭露與投資人保護框架

讓貨幣、債券、基金、不動產等既有資產進入鏈上金融

主要問題

詐騙、資訊不透明、監管套利、Token 無實質權利、暴漲暴跌

投機泡沫、洗售、估值困難、著作權與 Token 權利混淆、流動性枯竭

法規成本高、跨境監管不一致、交易平台與二級市場仍有限

鏈上 Token 與鏈下資產權利如何連結；託管、估值、贖回、Oracle 與破產隔離

是否回應前一階段問題

—

部分：證明 Token 可代表獨特權利，但未解決投機與法律權利問題

較能處理 ICO 的證券法與投資人保護問題

較能處理「Token 缺乏真實價值支撐」問題，並擴大實際金融用途

仍無法完全解決

市場投機與人性風險

投機、詐騙、平台操縱

詐騙、錯誤估值、流動性不足、跨境執法

鏈下資產造假、託管人失敗、法律執行、流動性與系統性風險

ICO／NFT 遺留問題

STO

RWA

分析

募資缺乏監管

高

中至高

STO 直接納入證券法；RWA 若屬證券仍需依相關規則發行。

投資人身份不明／AML

高

高

可透過受監管平台、KYC 與白名單處理，但公鏈轉移仍需制度設計。

Token 無實質權利

高

高

STO 明確化證券權利；RWA 以真實資產或請求權支撐，但前提是法律架構有效。

缺乏真實價值支撐

中

高

STO 可能仍是高風險新創股權；RWA 更直接引入既有資產與現金流。

價格投機與泡沫

低

中

監管與資產支撐可降低部分炒作，但不能消除市場投機。

詐騙與造假

中

中

揭露與審計可降低風險，但發行人、託管人或資產本身仍可能造假。

流動性不足

中

中

Token 化提高技術可交易性，不代表自然產生市場深度。

跨境法律衝突

低至中

低至中

技術全球化，但證券法、財產法、稅法與破產法仍以司法管轄區為基礎。

鏈上與鏈下脫節

中

核心挑戰

STO 可透過登記與發行架構改善；RWA 成敗更直接取決於鏈下資產權利的法律可執行性。

項目

內容

規劃主體

台灣大股東李父

最終目的

將李父持有的上市或即將上市甲公司股票，轉由第二代李子間接控制或受益

境外工具

在荷蘭設立T控股公司

境內帳戶

T公司在台灣銀行設立OBU帳戶；李父另有個人帳戶

資金來源

李父向荷蘭銀行台北分行貸款

操作核心

先把借來的資金匯往李子的境外帳戶，再成立境外控股公司，由境外公司透過OBU帳戶投資台灣股票

股票取得方式

由T公司經證券商買入李父所持甲公司股票，或認購甲公司的增資股票

資金回流

股票出售款進入境外公司或OBU帳戶，再用來償還李父原先向銀行借的貸款

稅務目的

將原由李父個人持有的股票及未來投資收益，轉為由境外公司持有，希望降低個人所得稅、贈與稅及境內所得稅負

書中主張的稅率差異

李父個人綜合所得稅最高稅率40%，境外公司投資台灣股票的所得，書中主張可按較低的公司股利稅負處理

主要法律風險

缺乏實質商業目的、資金由李父安排、李子只是名義持有人、境外公司欠缺實質營運，都可能被認定為租稅規避或實質贈與

時代背景

書中指出，這類安排在民國103年以前較難被掌握；CRS及洗錢防制制度上路後，金融帳戶與資金流更容易被交換及查核

現代可行性

已大幅下降。即使形式上成立公司、開設OBU帳戶，也不代表稅務上一定被承認

步驟

交易內容

實際功能

1

李父向荷蘭銀行台北分行貸款

取得整套交易所需資金

2

將資金匯入境外第二代李子帳戶

把資金移到李子名下或其可控制的境外帳戶

3

李父、李子成立荷蘭T控股公司

建立境外持股平台

4

將資金匯入T公司的台灣OBU帳戶

讓境外公司有資金投資台灣股票

5

委託E、F證券公司交易

透過正常證券市場形式進行買賣

6

買入李父持有的甲公司股票，或認購增資股

把股票由李父個人移到T公司名下

7

李父取得出售股票款

李父將股票變現

8

用資金償還原先銀行貸款

完成資金循環

發展階段

主要特色

常見工具／服務

管理重點

傳統物流

重點是把貨物從出發地運到目的地

海運、空運、公路、鐵路、倉儲

運價、交期、貨損

數位物流

貨況、庫存與交貨資訊可即時查詢

Track & Trace、條碼、GPS、電子報關

資訊透明與異常處理

第三方物流

由專業公司整合運輸、倉儲、報關與配送

3PL、WMS、TMS、多式聯運

成本、服務與彈性

供應鏈管理

把採購、生產、庫存、物流與市場需求一起管理

需求預測、區域倉、供應商協同、控制塔

整體效率與韌性

企業自行處理

交由 3PL 處理

主要差異

自行找船公司、倉庫與報關行

由一個物流服務商統一整合

聯絡窗口較少

各地庫存分散管理

使用同一套平台查看庫存與貨況

資訊較一致

運量小、議價能力有限

利用 3PL 的全球網路與規模

成本與運力較穩定

發生延誤時逐一追查

由 3PL 協調航線、倉庫與配送

異常處理較集中

功能

容易理解的說明

國際商務用途

跨境運輸整合

組合海運、空運、鐵路與公路

依成本與交期設計運輸路線

報關與法規支援

準備文件並協助通關

降低錯誤申報與延誤風險

倉儲與分撥

把貨物存放、分類並送往不同市場

支援區域倉與快速配送

資訊可視化

在系統中查看貨況、庫存與異常

提升交期與庫存透明度

供應鏈金融

以訂單、出貨與在途資料協助融資

改善中小企業現金流

永續物流

估算碳排並選擇較低碳路線

支援 ESG 與客戶揭露要求

物流節點

主要工作

可能風險

3PL 的處理方式

台灣出口港

裝櫃、報關、出港

文件錯誤、船期延誤

檢查文件並安排替代船期

美國西岸港口

卸貨與轉運

塞港、查驗

即時更新狀態並調整鐵路班次

美墨邊境

跨境通關

關務延誤

協調報關文件與卡車

墨西哥工廠

最終配送

到貨時間不穩

安排預約交貨與異常通知

比較項目

物流

供應鏈管理

關注範圍

運輸、倉儲、配送

採購、生產、庫存、物流、銷售與回收

主要問題

貨物如何準時到達

整體需求如何被穩定滿足

管理目標

速度、成本與貨損

成本、服務、現金流與韌性

資料來源

貨況與庫存

訂單、需求、供應商、生產與物流資料

主題

核心問題

常見工具

管理目的

供應鏈整合

採購、生產、庫存與配送如何彼此配合

ERP、供應商平台、需求預測

降低缺貨、延誤與重複庫存

智慧物流

如何即時知道貨物、庫存與設備狀態

IoT、GPS、條碼、RFID、AI

提高可視性與預測能力

供應鏈控制塔

如何把不同地區與系統資料集中管理

Dashboard、API、風險警示

及早發現異常並協調決策

供應鏈韌性

供應中斷時如何維持營運

多元供應商、安全庫存、替代路線

降低單一市場與單一節點風險

綠色物流

如何降低運輸與倉儲碳排

碳排計算、路線優化、低碳運具

符合客戶與法規要求

技術

可取得的資料

應用方式

GPS

車輛與貨物位置

預估到貨時間、偏離路線警示

條碼／QR Code

商品與批次資訊

收貨、揀貨、盤點與出貨

RFID

大量貨品的快速辨識

倉庫自動盤點與進出紀錄

IoT 感測器

溫度、濕度、震動

冷鏈食品、藥品與精密設備

AI

需求、延誤與風險模式

需求預測、路線優化與異常警示

控制塔看到的資訊

可做出的決策

某港口發生塞港

改走其他港口或調整出貨順序

重要原料交期延後

啟用替代供應商或調整生產排程

某地區庫存過高

減少補貨或轉移至其他市場

客戶需求突然增加

提高產能並優先安排高價值訂單

貨物溫度超標

啟動理賠、攔截或品質檢查

原有做法

發生問題

改善方式

只依賴單一供應商

供應中斷時無替代來源

建立第二供應商並通過品質認證

庫存維持極低水位

短缺立即影響生產

對關鍵零件保留安全庫存

只看採購價格

忽略地理與交期風險

把供應穩定性納入評分

供應商資料分散

異常發生後才被發現

建立供應商風險儀表板

韌性做法

作用

可能代價

多元供應商

降低單一供應商中斷風險

採購與品質管理更複雜

多地生產

降低單一國家或地區風險

固定成本較高

安全庫存

提供短期緩衝

增加資金占用與倉儲成本

替代運輸路線

塞港或航線中斷時可切換

運費可能較高

長期合作契約

確保關鍵原料與運力

彈性可能降低

未來方向

簡單說明

路線最佳化

用 AI 減少空車、繞路與等待時間

低碳運具

增加電動貨車、鐵路與低碳燃料使用

智慧倉儲

透過自動化與能源管理降低耗能

電子文件

以電子提單、電子報關減少紙本與等待

物流資料融資

以訂單、庫存與交貨紀錄作為信用依據

主要問題

形成原因

協同改善方式

存貨成本過高

需求預測錯誤、重複備貨或過度安全庫存。

共享銷售與庫存資訊，建立共同預測並降低重複庫存。

資源利用率過低／停工待料

原料、零組件、產能與排程未同步。

共同掌握供應能力、物料狀況與生產排程。

市場反應速度太慢

下游需求資訊無法即時傳遞到上游。

建立跨企業資訊共享與例外回報機制。

訂單履行週期太長

採購、生產、物流各自作業，前置時間層層累積。

整合採購、生產、補貨與配送計畫。

缺貨損失

庫存過低、需求突增或供應鏈缺乏彈性。

以共同預測與動態補貨降低缺貨風險。

長鞭效應

各層級依局部資訊重複預測並放大訂單。

共享較接近最終市場的需求資料，減少預測誤差逐級放大。

核心構成

內容

共同目標

先確認服務水準、庫存、成本、交期、銷售與顧客滿意度等共同成果。

資訊共享

共享銷售、POS、庫存、訂單、產能、物料、交期與運輸等資料。

共同規劃

共同制定市場、促銷、商品、存貨、生產與補貨方案。

資源互補

依合作夥伴的核心能力分工，整合技術、產能、通路與物流資源。

例外管理

設定容許範圍，只針對重大預測差異、缺貨風險或供應異常進行協調。

信任與治理

明確規範資料權限、責任分工、KPI、異常處理與爭議解決方式。

效益

說明

1. 建立信任關係

合作夥伴長期交換資訊並共同決策，可降低彼此防備，形成較穩定的夥伴關係。

2. 建構知識管理

共同累積需求、預測、製造與物流經驗，形成可重複使用的流程與知識。

3. 快速回應市場

需求變化可較快傳遞至供應與生產端，縮短調整時間。

4. 全球運籌管理

跨地區整合產能、供應、庫存、物流與市場資訊，提升全球資源配置效率。

階段

步驟

主要內容

協同規劃

1. 建立合作協議

確認合作範圍、共同目標、責任、資料共享、KPI及異常處理原則。

協同規劃

2. 建立共同事業計畫

整合商品、促銷、價格、庫存、新品與市場策略。

協同預測

3. 建立銷售預測

依POS、歷史銷售、促銷、季節與市場資訊形成共同需求預測。

協同預測

4. 辨識銷售預測異常

找出超過容許範圍的預測差異或市場異常。

協同預測

5. 協同解決銷售異常

共同分析原因並修正預測假設。

協同預測

6. 建立訂單預測

把需求預測轉為考量庫存、產能、交期與物流限制的訂單預測。

協同預測

7. 辨識訂單預測異常

找出供需、產能、庫存或交期不一致。

協同預測

8. 協同解決訂單異常

調整訂單、排程、供應或庫存方案。

協同補貨

9. 產生訂單

將協調完成的訂單預測轉為正式補貨與執行。

資料類型

來源

主要用途

POS／實際銷售

零售端

掌握接近最終市場的需求訊號。

庫存與在途庫存

零售、物流與供應端

判斷何時補貨及補貨數量。

促銷／新品／價格

行銷與通路

修正歷史資料無法反映的特殊需求。

產能與物料

製造商／供應商

判斷需求是否可被實際供應。

交期與運輸

物流商／供應端

確認預測能否轉為可執行的補貨時程。

對象

主要效益

買方

資訊透明、降低採購作業成本、形成集體議價力量、取得更具競爭力的供應商。

供應商

提供更完整服務、提升競爭力、降低銷售成本、擴大市場接觸面。

作業部分

內容

客戶需求

需求規格、設計意見、圖面確認與變更。

產品開發

產品設計、工程分析、包裝與組裝順序。

生產規劃

排程、製具、檢驗規格與量產準備。

零組件廠商

材料、製程、設備、加工條件與教育訓練。

主要挑戰

協同因應

訂單需求不易掌握

共享訂單、需求與交期資訊，降低臨時變更衝擊。

客製化生產複雜

整合產能與排程，降低頻繁換線及製造週期拉長。

物料供應不穩

共享供應與庫存資訊，及早進行物料調度。

面向

主要考量

數量

物流中心儲存空間、庫存量與運輸能量。

時間

產品有效期限、安全存量、交期與運輸時間。

空間

供應商、工廠、物流中心與客戶間的距離與路線。

成功條件

實務重點

高層支持與治理

明確設定負責單位、決策權與異常處理流程。

可信任的資料

銷售、庫存、訂單、主檔與交期資料須一致且及時。

共同KPI

避免買方只追求低庫存、供應商只追求高產能利用率而互相衝突。

分級導入

先從高價值、高波動、高缺貨風險或促銷頻繁品項開始。

例外管理

設定門檻，把人工協同集中在真正重要的異常。

系統整合

串接ERP、POS、WMS、TMS與預測／規劃系統，降低人工重複輸入。

KPI

衡量目的

Forecast Accuracy／預測準確率

衡量共同預測是否改善。

Forecast Bias／預測偏差

檢查是否長期高估或低估需求。

Fill Rate／訂單滿足率

衡量顧客需求被即時滿足的程度。

Stockout Rate／缺貨率

觀察缺貨是否下降。

Inventory Turnover／存貨週轉率

衡量庫存使用效率。