訊息流是什麼

一句話：一件事從「發生」到「被記得」的整條路徑。信件只是它最前面的一段，不是它本身。

這一頁把「治理」說清楚：為什麼要分類、為什麼要有載體、為什麼同一件事會出現六種身分。

圖：同一則客訴 08:40 進來，隔天 07:30 變成廠長的第 1 條重點。中間換了六種身分，但編號只有一個。

1. 三個名詞，先切開（多數專案死在這裡）

名詞	意思	例子	常見錯誤
通道 Channel	訊息「怎麼來」	Email、Teams、LINE、電話、Portal、API、機台訊號	把 Email 當成一種分類
類別 Flow Type	訊息「是什麼事」，按業務語意與生命週期分	客訴、詢價、專案啟動、變更、問題研究	按通道分 ⇒ 路由必失準
載體 Carrier / SoR	這件事「以哪裡為準」	ERP、QMS、PLM、案件中心、DMS、KM	同一件事三個地方各一份

同一個客訴，走一遍給你看：
① 它從 LINE 群組進來（通道）→ ② 系統判定它屬於 品質客訴／A 客戶外觀不良（類別＋專案）→ ③ 但「官方真相」記在 QMS 的 8D 單（載體）。
三件事分開講，才不會把「LINE 記錄」誤當成「品質紀錄」。

2. 類別：6 大類 × 24 子類

用三個維度定位：來源邊界（客戶／內部／廠商／監管）× 訊息性質（事件／請求／文件／知識／數據／公告）× 時效。24 是刻意的：少於 20 路由不準，多於 30 没人記得、一定被自創。

大類	子類	主責 A
A 需求與商務流 4 類	詢價報價 RFQ・訂單／訂單變更・預測與產能 S&OP・合約價格法務	業務
B 品質與異常流 5 類	客訴／退貨 RMA（8D）・廠內製程異常停線・供應商 SCAR／來料異常・召回安全法規・CAPA 稽核缺失	品保
C 工程與變更流 5 類	專案啟動 NPI・設計變更 ECN/ECO・製造變更 MOC/4M・樣品承認 PPAP/FAI・技術問題研究 FA/DOE	工程
D 營運與數據流 4 類	生產工單排程・庫存與交期 ATP・設備 IoT 告警・品質數據 SPC	生管
E 法規與文件流 3 類	客戶／法規稽核・文件管制與版本・認證與宣告 CoC/CoA	品保／文管
F 組織協作流 3 類	信件與即時討論・會議決議待辦・公告政策訓練	各單位

注意 F1：信件討論是「通道類」——它是流，不是紀錄。郵件系統是暫存載體，歸檔進案件的原文才是紀錄。

3. 載體：10 種，各有權威範圍

載體	裝什麼	權威性	不可妥協的規則
交易資料庫 ERP／MES／QMS／PLM／CRM／SRM	結構化交易事實	該領域唯一真相	不手改、只走流程
案件／工單系統	生命週期、對話、SLA	跨系統共同語言	一個案件一個編號
文件管理 DMS	文件、圖面、版本	版本與發行權威	只認已發行版
物件儲存	附件、照片、郵件原文	證據保存地	不可變、年限依合約
事件流 Kafka／RabbitMQ／MQTT	即時事件、狀態變更	即時性骨幹	可重放、有序
API 網關	對外與跨系統介面	同步查詢	OAuth2／mTLS、限流
B2B 傳輸 EDI／AS2／SFTP	訂單、出貨、發票	跨公司法定交換	簽章與回執
協作通道 Email／Teams／LINE	人到人的傳遞	不是紀錄	涉承諾或異常，當日回寫案件
知識庫 KM	可重用答案、案例	經驗的權威	一頁一問題、有 owner
時序 DB Historian	高頻量測、機台參數	OT 資料權威	只出不進

4. 三方：客戶 ↔ 自己 ↔ 廠商

方向	做法	最常炸的地方
客戶 → 自己	CRM／客服系統收單；Portal 讓客戶自助查進度	業務用私人信箱收客訴，人一走資料就沒了
自己 → 客戶	8D／FA 報告、對外 Portal、EDI 856/810	同一份報告三個版本，客戶拿到舊的
自己 → 廠商	SRM／供應商 Portal、SCAR、PO 變更通知	群組信通知所有供應商，洩漏底價
廠商 → 自己	IQC 批退、8D 回覆、變更申請 MOC、PPAP 提交	廠商口頭承諾，事後無紀錄

業界的解法不是「三方共用一個系統」，而是共用一個可被三方各自解讀的物件：一個案號、一張 8D、一份 PPAP。

5. 推播：不是廣播，是「訂閱＋去重＋升級」

層級	內容	通道	時機
即時（例外）	P0／P1、停線、安全、客戶高層	App ＋電話／Teams	成立 5 分鐘內
每日摘要	我的佇列、今日到期	Email／Teams 卡片	上班前 08:00
每週回顧	單位 KPI、逾期清單	看板／會議	週一早上

同一案件 30 分鐘內合併成一次通知
非當責者只收摘要（避免通知洪水）
逾期自動升級一層，連兩層進廠長視圖
已讀未處理 24 小時再提醒一次，之後交回人

6. 背後的標準（不是我們發明的）

層	標準	解決什麼
分層與邊界	ISA-95／IEC 62443（Zone-Conduit）	ERP–MES–設備誰能跟誰講話、資料可跨哪條線
流程	ITIL 4、SIAM	案件生命週期、SLA／OLA、多供應商協作
交換格式	EDI／AS2、RosettaNet、OPC UA	跨公司與跨機器的語法與回執
治理與紀錄	ISO 9001 §7.4／§7.5／§10.2、IATF 16949 8D、ISO 27001	該留什麼證據、保存多久、誰能改

所以我們要治理的是「流」，不是「信」。
同一件事可以同時出現在信箱、群組、會議、ERP、看板，但只能有一個編號、一條時鐘、一份真相、一處可查。

延伸：理念頁（四個延遲、七條鐵律）　·　討論題　·　日報範例

專案樹

樹只負責「彙總」，不負責「存放」。同一則訊息可以同時屬於客訴與產品，歸檔是連結、不是搬家。

規則：子專案的問題往上捲、父專案狀態取子專案最壞者、只能往父層讀不能往子層寫、層數 ≤ 4。

系統規格（v0.1）

這一頁是給 IT／PM 看的實作依據。完整的論述在〈理念頁〉與〈實作指南〉，這裡只放「做的人需要對齊的東西」。

1. 一句話與五段

訊息流 = 收 → 辨 → 動 → 記 → 學。每一段都有產出、都有負責人、都能被人複核。

段	做什麼	沒有它會怎樣
① 收 SENSE	Email／企業微信／檔案／會議／系統事件收斂到單一入口，60 秒內給案號	訊息散在各處，永遠有人「沒收到」
② 辨 CLASSIFY	6 大類 24 子類、歸檔到專案、分級 P0–P3、低信心進人工	路由錯，事情在錯的人手上轉
③ 動 ACT	立案、指派、SLA 起算、決策卡、逾期升級	沒有時鐘，就沒有「逾期」這件事
④ 記 REMEMBER	每日 23:30 封存快照（不可變）、歷史履歷、原文可回溯	三個月後没人記得當時為何這樣決定
⑤ 學 LEARN	人工修正 → 樣本庫 → 規則版本 → 離線評估 → 灰度 → 回滾	每年從零開始，AI 也不會變準

2. 資料模型（7 個實體）

實體	關鍵欄位	為什麼需要
Message	id, ts, source, from, subject, body, thread_id, content_hash, cat, severity, conf	hash 去重；cat/severity/conf 可被人工覆寫
Attachment	msg_id, mime, sha256, uri, parsed_text	Excel/Word/PPT 要先抽文字
ProjectLink	msg_id, project_id, role(主/關聯), conf, by(ai/human)	一則訊息可屬多專案；改歸檔不動樹
Project	id, parent_id, path, dept, owner, type, status, due, acl	path 讓子樹查詢變一個 LIKE
Issue	project_id, severity, owner, due, status, hit_count, first_seen	hit_count＝同案被幾個通道提到
DailySnapshot	date, project_id, version, highlights, issues	日報的唯一穩定來源；不可變
Decision	issue_id, options[], due, impact, decided_by	「需要你介入」的資料底

完整 DDL：schema.sql（含不可變快照 trigger、子樹 rollup view、未歸檔池 view）。

3. 分級規則

等級	條件（四維：影響範圍 × 時效 × 不可逆 × 權重）	反應
P0	不可逆／停線・安全・法規／客戶高層關切	1 小時內通知，當日必須裁決
P1	≤3 天時效且影響出貨或驗收	當日回應
P2	有 owner、有 due 的正常工作	本週處理
P3	參考資訊	只進摘要，不通知

4. 三層日報

區塊	總公司（廠長）	部門（主管）	專案（PM）
一句話結論	今天要你決定幾件、幾件逾期	本部門今日風險	本專案今日狀態
重點	昨日重點 5–7 條（跨專案去重）	部門重點 3 條	昨日重點＋今日進展
需要你介入	決策卡：選項／期限／後果	待決與跨部門協調	待解問題 P0–P3
風險	卡點表（逾期、停線、客訴）	逾期清單與趨勢	阻塞項與相依
數據	部門一覽	專案表	歷史履歷與決策紀錄

5. AI 介面契約（重點：不准推測）

欄位	規則
category	六類之一；信心 < 0.75 → low_confidence，進人工
severity	只能給 P0–P3，且必須附 reasons（原文依據）
project	不確定就給 null，不要猜；候選清單由系統提供
summary	≤ 60 字；只寫原文有的事
issues[]	標題／等級／負責人／期限／evidence；needs_decision 時必須附 ≥2 個選項
evidence	每條結論都要能點回原文片段（≤40 字）

6. KPI

對應延遲	指標	目標
偵測	漏接率／事件到立案	< 2%／< 30 分鐘
判斷	首回準時率／非計畫升級率	≥ 95%／< 5%
執行	平均週期／8D 準時率	-30%／≥ 90%
學習	重複問題率／知識重用率	-50%／≥ 30%

7. 實作階段

階段	週次	內容	驗收
P0 定義	W1	清冊、RACI、SLA 基準	每類一個 A
P1 入口	W2–5	共用信箱＋案件清單＋人工摘要（不寫程式）	漏接率可量
P2 節奏	W6–13	擷取、規則分類、23:30 封存、07:30 日報	自動歸檔 ≥ 80%
P3 學習	W14–24	LLM 摘要與問題抽取、灰度、閉環調校	F1 ≥ 0.85

8. 本頁模擬的範圍

這一頁的資料是虛構樣本（37 則、3 天、14 個專案），分類與摘要用關鍵詞規則模擬 AI，操作只存在瀏覽器記憶體，重新整理即還原。真正的 LLM 介面、權限、持久化尚未實作——那正是 P2／P3 的工作。

延伸：理念頁（為什麼這樣設計）　·　日報範例（三層報告長相）