最近公司的 SSO 出問題，我想知道：在比較好的架構設計下，這裡面應該要放什麼？
這篇先把企業、電商、金流專案會碰到的系統和縮寫列成一張地圖。SSO 相關的名詞在「身分／安全／維運」那一節，但這裡只有一句話的解釋，SSO 本身該怎麼設計不在這篇的範圍。
後端工程師在企業／電商／金流專案會撞到的系統、縮寫與角色。跟電商金流直接相關的排前面。
這篇是索引，不是終點：縮寫是入口，每節底下的「↳ 展開讀」是出口，指到真的把那件事寫完的文章。
💳 支付/金流安全
| 縮寫 | 全名 | 一句話 |
|---|---|---|
| HSM | Hardware Security Module | 硬體加密模組，存金鑰+做加解密，信用卡處理合規核心 |
| KMS | Key Management Service | 金鑰管理服務（雲版金鑰保管，AWS KMS 等） |
| PKI / CA | Public Key Infrastructure / Certificate Authority | 公鑰基礎設施 / 憑證簽發機構 |
| PCI-DSS | Payment Card Industry Data Security Standard | 信用卡資料安全標準（存卡號要合規） |
| PA-DSS / P2PE | Payment Application DSS / Point-to-Point Encryption | 支付應用標準 / 點對點加密 |
| PAN / CVV / BIN | Primary Account Number / Card Verification Value / Bank ID Number | 卡號 / 驗證碼 / 卡號前綴銀行碼 |
| EMV | Europay-Mastercard-Visa | 晶片卡標準 |
| 3DS / SCA | 3-D Secure / Strong Customer Authentication | 線上刷卡持卡人驗證 / 強客戶驗證（PSD2 要求） |
| tokenization | — | 代碼化：存 token 不存卡號（縮小 PCI 稽核範圍） |
| PSP / PG | Payment Service Provider / Payment Gateway | 金流服務商 / 金流閘道（綠界、PayUni、Stripe） |
| Acquirer / Issuer | — | 收單行 / 發卡行 |
| ACH / SWIFT / IBAN | — | 美國自動清算 / 國際電匯 / 國際帳號 |
| settlement / chargeback | — | 撥款結算 / 爭議拒付（持卡人申訴退款） |
| e-invoice | 電子發票 | 台灣統一發票電子化（開立/作廢/折讓） |
| KYC / AML | Know Your Customer / Anti-Money Laundering | 認識客戶 / 反洗錢（金流合規） |
↳ 展開讀：
- 為什麼卡號根本不能存、八種付款怎麼分流 → 電商付款方式設計
- PSP callback 的驗簽與冪等（一個帳差事故） → 付款 callback 是生死線
- settlement / chargeback 對到的退款與逆向流 → 退款與對帳
📦 企業核心系統
| 縮寫 | 全名 | 電商系統裡對應什麼 |
|---|---|---|
| OMS | Order Management System | 訂單狀態機 |
| WMS | Warehouse Management System | 庫存/出貨/預佔 |
| PIM | Product Information Management | SPU/SKU 商品資料 |
| TMS | Transportation Management System | 物流/DeliveryGroup |
| POS | Point of Sale | 銷售時點/收銀 |
| ERP | Enterprise Resource Planning | 財會/採購/生產一體（SAP、Oracle） |
| EIP | Enterprise Information Portal | 企業入口網：員工每天第一個畫面（SSO＋待辦聚合＋簽核＋公告）。它是聚合層不是系統（作者的判斷框架，非業界定義） ⚠️ 雲端語境的 EIP＝AWS Elastic IP，完全不同的東西 |
| CRM / CDP | Customer Relationship Mgmt / Customer Data Platform | 客戶關係 / 客戶資料平台 |
| SCM | Supply Chain Management | 供應鏈 |
| CMS / DAM / DMS | Content / Digital Asset / Document Mgmt | 內容 / 媒體資產 / 文件管理 |
| HRIS / LMS | HR Information System / Learning Mgmt | 人資 / 教育訓練 |
| PLM | Product Lifecycle Management | 產品生命週期 |
| BPM / RPA | Business Process Mgmt / Robotic Process Automation | 流程引擎 / 機器人流程自動化 |
| ITSM / CMDB | IT Service Mgmt / Config Mgmt DB | IT 服務管理（ServiceNow）/ 組態庫 |
↳ 展開讀：
- OMS 那顆狀態機（其實是五個） → 一張訂單其實是五個狀態機在跳舞
- WMS 的預佔與超賣 → 庫存預佔：防超賣的三個數字
- TMS 對到的分批出貨粒度 → 電商出貨與物流
- 促銷引擎（多半散在 OMS/CRM 之間，沒有標準縮寫） → 促銷疊加規則
🔗 整合/資料
| 縮寫 | 全名 | 一句話 |
|---|---|---|
| ESB / EAI | Enterprise Service Bus / App Integration | 服務匯流排 / 企業應用整合（老派 SOA） |
| iPaaS | integration Platform as a Service | 雲版整合平台（Zapier/MuleSoft 那類） |
| API Gateway / BFF | — / Backend for Frontend | API 閘道 / 前端專用後端 |
| MQ / pub-sub / webhook | Message Queue | 訊息佇列 / 發布訂閱 / 回呼 |
| saga / outbox / CQRS | — | 跨服務事務補償 / 可靠事件發送 / 讀寫分離模型 |
| ETL / CDC / reverse-ETL | Extract-Transform-Load / Change Data Capture | 資料管線 / 變更捕捉 / 反向回灌 |
| EDI | Electronic Data Interchange | B2B 電子資料交換（下單/發票） |
| MDM | Master Data Management | 主資料管理（單一真相來源）⚠️ 跟 Mobile Device Mgmt 撞縮寫 |
| DW / ODS / data lake / OLAP·OLTP | Data Warehouse / Operational Data Store | 資料倉儲 / 營運資料存放 / 資料湖 / 分析型·交易型 |
| BI | Business Intelligence | 商業智慧報表 |
🔐 身分/安全/維運
| 縮寫 | 全名 | 一句話 |
|---|---|---|
| IAM / PAM | Identity & Access / Privileged Access Mgmt | 身分存取管理 / 特權帳號管理 |
| SSO / MFA | Single Sign-On / Multi-Factor Auth | 單一登入 / 多因素驗證 |
| OAuth / OIDC / SAML / JWT | — | 授權 / OpenID Connect / 企業 SSO 協定 / 權杖 |
| LDAP / AD | Lightweight Directory / Active Directory | 目錄服務（企業帳號中樞） |
| RBAC / ABAC | Role / Attribute-Based Access Control | 角色 / 屬性存取控制 |
| ZTA | Zero Trust Architecture | 零信任架構 |
| WAF / IDS·IPS / EDR·XDR | Web App Firewall / Intrusion Detection·Prevention / Endpoint·Extended Detection | 應用防火牆 / 入侵偵測·防禦 / 端點偵測回應 |
| SIEM / DLP / CASB | Security Info & Event Mgmt / Data Loss Prevention / Cloud Access Security Broker | 安全事件管理 / 資料外洩防護 / 雲存取安全 |
| vault / secrets manager | — | 密鑰保管（HashiCorp Vault、AWS Secrets Manager） |
| APM / o11y | App Performance Mgmt / observability | 應用效能監控 / 可觀測性 |
💰 財務/合規/治理
| 縮寫 | 全名 | 一句話 |
|---|---|---|
| GL / AR / AP | General Ledger / Accounts Receivable·Payable | 總帳（複式記帳）/ 應收 / 應付 |
| reconciliation | 對帳 | 比對兩系統帳目找差異（金流最後防線） |
| audit trail | 稽核軌跡 | 每筆變更留痕（合規+debug） |
| GDPR / PDPA | General Data Protection Reg / Personal Data Protection Act | 歐盟個資法 / 台灣個資法 |
| SOX / ISO 27001 / GRC | Sarbanes-Oxley / — / Governance-Risk-Compliance | 財報內控 / 資安管理 / 治理風險合規 |
| GAAP / IFRS | — | 美國/國際會計準則 |
| SLA / SLO / SLI | Service Level Agreement / Objective / Indicator | 服務等級協議/目標/指標 |
| DR / BCP / RTO·RPO | Disaster Recovery / Business Continuity Plan | 災難復原 / 營運持續 / 復原時間·資料點目標 |
👥 角色與職稱（傳統軟體公司 / SI 為主）
上面是系統，這節是人。進到企業專案，你要接的一半是系統、另一半是「誰有權說這件事」。
產品/需求線
| 縮寫 | 全名 | 一句話 |
|---|---|---|
| PM | Product / Project Manager | ⚠️ 台灣最常混用的縮寫：網路公司多指產品經理（決定做什麼），SI 公司多指專案經理（決定何時交付、管合約） |
| PO | Product Owner | Scrum 角色，backlog 的唯一決定者 |
| BA | Business Analyst | 訪談業主、把商業流程寫成規格書（SI/ERP 最吃重的角色） |
| SA | System Analyst | 系統分析師：把規格翻成系統設計（台灣 SI 特有的職級，介於 BA 與 RD 之間） |
| SD | System Designer | 系統設計師，SA 的下一手，畫到 table schema / 流程圖 |
| PMO | Project Management Office | 專案管理辦公室：管跨專案的排程、資源、報表（大公司才有） |
| UI / UX | — | 介面視覺 / 使用者經驗（小公司常是同一人） |
| 顧問 | Consultant | ERP/SI 的產業顧問，懂 SAP 那套怎麼對到客戶的流程，不寫 code |
工程線
| 縮寫 | 全名 | 一句話 |
|---|---|---|
| PG | Programmer | 老派 SI 用語，寫 code 的最底層職級（現在多改叫 RD/SWE） |
| RD / SWE | Research & Development / Software Engineer | 台灣愛用 RD，外商用 SWE |
| FE / BE / FS | Frontend / Backend / Full-Stack | 前端 / 後端 / 全端 |
| TL | Tech Lead | 技術決策 + 帶 code review，通常還在寫 code |
| EM | Engineering Manager | 管人（績效、招募、排程），不一定寫 code |
| Architect | 架構師 | 跨系統的技術決策、選型、非功能需求（效能/擴充/安全） |
| QA / QC | Quality Assurance / Control | 測試。傳統公司多為手動測試 + 寫測試案例 |
| SDET / QE | Software Development Engineer in Test | 寫測試框架與自動化的工程師（QA 的工程化版本） |
| DBA | Database Administrator | 管 DB 的效能、備份、權限。傳統公司 schema 改動要他點頭 |
| SRE / DevOps / OP | Site Reliability Eng. / — / Operation | 可靠性 / 交付流程 / 維運值班 |
| MIS | Management Information System | ⚠️ 台灣特有：名義上是資訊管理，實務上＝公司內部 IT（修電腦、管 AD、管網路、順便管 ERP） |
| NE / SysAdmin | Network Engineer / System Administrator | 網管 / 系統管理員（機房年代的主力） |
資料/AI 線
| 縮寫 | 全名 | 一句話 |
|---|---|---|
| DE | Data Engineer | 建資料管線（ETL/CDC），把資料搬到能用的地方 |
| DA | Data Analyst | 撈數字、做報表、回答商業問題 |
| DS | Data Scientist | 建模型、做實驗設計 |
| MLE / MLOps | Machine Learning Engineer / — | 把模型上線 / 管模型的部署與監控 |
| BI 工程師 | Business Intelligence | 做 DW + 報表平台（Tableau/PowerBI），傳統公司常掛在 MIS 底下 |
管理層與外圍
| 縮寫 | 全名 | 一句話 |
|---|---|---|
| CTO / CIO / CISO | Chief Technology / Information / Information Security Officer | 技術長（對外技術與產品）/ 資訊長（對內 IT 與 ERP）/ 資安長 |
| VPE | VP of Engineering | 工程組織的最高管理者（跟 CTO 分工：CTO 想方向、VPE 讓組織跑得動） |
| PreSales / SE | Pre-Sales / Sales Engineer | 售前技術：跟業務一起去客戶那邊做 POC、寫技術標書 |
| AM | Account Manager | 客戶經理，管客戶關係與續約，專案變更需求常從他嘴裡進來 |
| CS / TS | Customer Service / Technical Support | 客服 / 技術支援，第一線收到 bug 的人 |
| SI / ISV | System Integrator / Independent Software Vendor | 系統整合商 / 獨立軟體商（公司類型，不是角色，但決定了上面所有職稱的長相） |
後端工程師的實務對照：誰卡你什麼
認得縮寫沒用，知道誰能擋下你的 PR 才有用：
| 你想做的事 | 實際上要過誰 |
|---|---|
| 改 table schema / 加 index | DBA（傳統公司），或沒有 DBA 時＝沒人管、然後半年後爆炸 |
| 改 API 契約 | 前端 + 串接你 API 的 SI 廠商（EDI/API 對外時契約是合約的一部分） |
| 上線時間 | 專案 PM / PMO 的排程，不是你的 git tag |
| 存哪些欄位 | 資安/CISO + 法務（個資、PCI-DSS），這是設計限制不是建議 |
| 加一台機器 / 開一個 port | MIS 或網管，傳統公司要走簽核單 |
| 需求改了 | BA 改規格書 → SA 改設計 → 才輪到你。跳過這條鏈自己改，出事時沒有文件保護你 |
角色的形狀是組織成本決定的：SI 公司要把 BA/SA/PG 切這麼細，是因為「懂業務的人」跟「會寫 code 的人」在那個年代幾乎不重疊，中間必須有翻譯層。當這個翻譯成本變低（工具、AI、全端化），這條鏈就會塌——這是我的判斷；個人職涯的角度另見 AI 會取代我的工作嗎？。
設計/整合這些系統時要注意什麼（跨系統通用鐵律）
真正的難點不在認得縮寫，在系統之間怎麼接。以下是我認為踩過才學會的：
- 冪等性（idempotency）是碰錢/碰外部系統的生死線——重複點、重送 request、callback 重放，任何寫入動作都要能安全重複執行（用唯一鍵擋、用狀態判斷擋）。不做，遲早出帳差。
- 永遠留一道對帳（reconciliation）——不要相信任何單一系統的帳是對的。你的帳 vs 金流商的帳 vs 發票系統的帳，要有一層定期比對兜底。callback 掉了、金額被竄改，都靠這裡抓出來。→ 對帳不是會計的事、退款與對帳
- 跨系統一致性別用 dual-write——「同時寫 DB 又打外部 API」中間斷掉就不一致。用 outbox/saga/事件驅動，接受最終一致，別假裝能強一致。→ 狀態機拆開之後的代價
- 多個流分開，別混成一個狀態——訂單/金流/物流/發票是四個平行的流，各有各的狀態機。硬塞成一個「訂單狀態」欄位，撐到退款+部分出貨就爆組合。→ 五個狀態機在跳舞
- 合規決定你能存什麼——PCI-DSS 讓你實務上不該自己存卡號（CVV 等敏感驗證資料授權後一律不得儲存；卡號要存就得加密到不可讀、整個環境進稽核範圍，所以多半改存 token。來源：PCI DSS 要求 3，https://www.pcisecuritystandards.org/document_library/）；會員生日、身分證字號這類個資，蒐集目的與保存期間也受個資法約束。合規不是事後補，是設計時就限制你的資料模型。
- 金額永遠 Decimal，不用 float——浮點誤差會讓對帳永遠差幾分。多幣別再加 minor unit（存「分」）。→ 多幣別帳務設計：匯率 Snapshot 與精度處理
- 每個狀態變更都要 audit trail——不只為合規，出事時「這筆從哪個環節開始歪」全靠它還原時序。
- 整合用 API/事件，別直接 DB-to-DB——別讓 A 系統直接讀 B 的資料庫。用契約（API/事件）+ anti-corruption layer 隔開，否則兩邊 schema 綁死、一起爛。
- 主資料要有單一真相來源（MDM 精神）——同一個「商品」「客戶」在幾個系統各存一份、各自改，就是資料不一致的溫床。定義誰是 source of truth。遷移做一半是這條的重災區：新舊兩套並存、兩邊都能寫，真相就沒了 → 雙軌並存為什麼危險、怎麼收斂
- buy vs build 要算維運成本不是機器錢——ERP/金流/HSM 這種，自刻的真實成本是「永遠要養它」。能組裝就別自建（除非那是你的核心競爭力）。
相關主題
- ERP 與 EIP 的功能模組分解（另一篇草稿）
- 對帳模式、訂單狀態機、多幣別帳務