把壞資料擋在門外
另有 28 種語言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 2 個模組，共 6 個，屬於 Data Architect 課程第 5 章資料品質與治理。每個模組都可以單獨閱讀。 上一篇：治理要設計進 org · 下一篇：瞭解你的資料
**本模組回答的問題：**如何讓資料保持良好，並一直保持下去？
處理壞資料有兩種方式：在它進來之前攔住，或者事後清理。兩種你都會做一些。但如果可以選，我寧願預防問題，也不願圍繞著永無止境的清理去建立一個組織。重複、錯誤的識別符號、缺失的資訊、不標準的值、使用者修改了另一個系統擁有的欄位、整合用壞資料覆蓋了好資料：這一切都會變成某人的清理專案。所以設計問題是：**我從一開始能合理地把哪些壞資料擋在門外？**而「合理」很重要，因為答案並不是把每個欄位都鎖死，直到系統沒法用。
足夠好是一個業務定義
Section titled “足夠好是一個業務定義 ”在防止壞資料之前，先定義什麼是好。沒有唯一的定義。好可能意味著：完整到足以執行流程，準確到足以據此決策，新到足以滿足工作負載，一致到足以與其他系統結合，唯一到足以知道我們說的是哪個客戶，標準到足以支援自動化，可追溯到足以知道它從哪裡來。這取決於資料。如果 Steve Trucking 要給一個零售合作夥伴開票，合作夥伴的法定身分就必須正確。如果一位銷售代表在會後隨手記筆記，沒人需要一個委員會來批准每一句話。**足夠好是一個業務定義；**架構師讓它變得可度量、可執行。
預防代價高昂的錯誤
Section titled “預防代價高昂的錯誤 ”並不是每個壞欄位都值得同樣的關注。我最關心的是會在下游造成後果的錯誤。一個重複的客戶意味著兩份銷售歷史、兩份服務歷史、兩組連絡人、兩個外部 ID、兩個同步同一家公司的整合、資料倉儲和 Data 360 裡的兩個版本，最終還有一個代理程式要決定哪個客戶才是真的。這比描述裡的一個錯別字代價高得多。所以不要從「我們如何驗證每一個欄位？」開始。要從**哪些壞資料會造成最大的業務或架構問題？**開始，把最強的控制放在那裡。
開放還是鎖定？
Section titled “開放還是鎖定？ ”客戶的建立是一個經典的例子。每個銷售人員都應該能建立客戶嗎？我的回答是：**這取決於資料周圍的治理。**對大多數中小型 org 來說，開放建立就可以。銷售代表遇到一個潛在客戶，建立客戶記錄，開始工作；這正是 CRM 的用途。重複規則、必填資訊和資料專員負責管理品質。我不會因為治理聽起來很負責任，就加上一套繁重的審批流程。
現在改變一下全景。法定客戶在 ERP 中主控，帶著一個 ERP 識別符號流入 Salesforce，而 ERP 是權威的。這時，開放建立就意味著建立同一個受治理實體有兩種途徑。當 ERP 和一位銷售代表都建立了同一家公司時，以哪個為準，整合用哪個識別符號，哪條記錄儲存歷史？開放建立就不再是一個可用性問題，而是一個主資料問題。當客戶在 ERP 中主控或與 ERP 同步時，就鎖定建立。
但完全鎖死也會失敗。銷售代表遇到了一個不在 ERP 裡的潛在客戶，想開一個商機，而治理模型說「你不能建客戶」。於是他們要麼等財務部門三天，要麼把商機掛到錯誤的客戶上，要麼把潛在客戶記在備註欄位或電子表格裡。我們保護了資料模型，卻傷害了業務。
折中的做法：臨時記錄類型
Section titled “折中的做法：臨時記錄類型 ”這是我喜歡的折中做法。**讓銷售在一個特定的記錄類型下建立客戶，即潛在客戶或臨時類型，並控制它向受治理類型的轉換。**銷售錄入公司並開始銷售。記錄清楚地表明：尚未在權威系統中確立。然後一個受控的流程來轉換它：由財務部門批准，或者由整合提交給 ERP，ERP 要麼把它與一個已有客戶比對上，要麼建立一個新客戶，並回傳權威的識別符號。現在，這條記錄跨越了一條邊界：臨時 → 受治理，這與兩個系統各自建立它們認為是主記錄的東西截然不同。
記錄類型是我講授的機制。不管你用什麼，都要讓這個狀態在資料中可見：記錄從哪裡來，它是否已經跨越了邊界，現在誰可以修改它，以及把它與權威系統聯絡起來的識別符號。只有在轉換之後才存在的 ERP 客戶 ID，是所有訊號中最清晰的一個。
每個資料流一個記錄類型
Section titled “每個資料流一個記錄類型 ”把整個資料流放進一張圖裡，你就會明白為什麼這樣做行得通。客戶和產品從 ERP 流入。商機及其明細項目流出，成為 ERP 的訂單。那客戶呢？有些流入，有些流出。所以我在各個實施項目中見過的一種常見模式，是在客戶上設兩個記錄類型，每個方向一個。Sales 客戶誕生在 Salesforce 中：銷售代表建立它、編輯它、向它銷售，當它成為正式客戶時，就被髮送到 ERP。ERP 客戶（我曾把它叫作 Customer，或者乾脆叫 SAP）誕生在 ERP 中，通過整合流入。除了整合，沒有人會建立這個記錄類型，而它的主資料欄位（法定名稱、地址、付款條件）對使用者是隻讀的。記錄類型告訴你記錄朝哪個方向流動，所以主控的方向就直接寫在記錄上。
每個資料流一個記錄類型：Sales 客戶流出，ERP 客戶流入。
這並不能消除那個難辦的情況。一位銷售代表為 Steve’s Plumbing 轉換了一個潛在客戶，但 Steve’s Plumbing 早已作為 ERP 客戶存在，而重複檢查不知怎麼沒有發現它。現在你得合併記錄、給子記錄重設父級，並決定哪條記錄存活下來（第 6 章，模組 3）。
也不要糾結於記錄類型本身。通常，除非有充分的理由，我會避免使用記錄類型。我在這裡用它，是因為在 Dynamic Forms 出現之前，記錄類型決定頁面配置，而一個佈局可以把 ERP 欄位顯示為只讀。有了 Dynamic Forms，可見性規則可以按某個欄位的值顯示或隱藏欄位，一個欄位可以在特定頁面上設為只讀，而且 Salesforce 自己也說 Dynamic Forms 能減少你需要的頁面配置和記錄類型的數量（Break Up Your Record Details with Dynamic Forms (opens in a new tab)（英文）；Required and Read-Only Fields in Dynamic Forms (opens in a new tab)（英文））。但頁面上的只讀只在那個頁面上只讀：API、一次資料載入或一個整合仍然可以寫入這個欄位。真正的執行靠的是欄位級安全性或驗證規則；介面驗證不等於資料驗證（第 3 章，模組 9）。當兩類客戶需要不同的挑選清單值或業務流程時，記錄類型仍然有它的價值。真正重要的是，有某個欄位清楚地說明記錄來自哪裡：ERP 鍵本身、一個主資料標誌，或一個來源挑選清單。然後由這個欄位來決定能否編輯。
從臨時到受治理：銷售立即開始銷售；只有權威流程才能讓記錄變為受治理。
保護受治理的記錄
Section titled “保護受治理的記錄 ”一旦客戶從 ERP 回來，它的 ERP ID、法定名稱、稅號和計費詳情就是受治理的屬性。銷售代表應該修改它們嗎？如果 ERP 擁有它們，就不應該。這就是模組 1 中那項需要執行點的策略：ERP ID 只讀，法定身分受控，而銷售代表仍然可以編輯區域、關係備註和 Salesforce 自己的分類。目標不是一個碰不得的客戶記錄，而是在Salesforce 擁有的資料和Salesforce 引用的資料之間劃出一條清晰的界線。（第 4 章的 erp_ 字首讓這條界線在結構中可見。）
最終你得到的黃金記錄其實是一個混合體。ERP 的主資料欄位流入：法定名稱、賬單地址和送貨地址、付款條件。然後 Salesforce 加上自己那些永遠不會回傳的欄位：銷售評級、最近訂單日期，以及營銷用到的幾乎所有東西。同一個客戶，兩類欄位，每一類都只有一個來源。
最難的是雙向同步。假設一位銷售代表需要把 ERP 中的法定名稱從 Steve’s Plumbing 改成 Steve’s Plumbing LLC。就在同樣的五分鐘裡，ERP 中有人把它改成了 Steve’s Plumbing L.L.C.。誰的修改勝出？思路是這樣的：如果一個欄位在 ERP 中主控，**你不是在修改這個欄位，而是在請求修改它。**決定請求發生衝突時會怎樣：ERP 勝出；如果值在此期間已經改變，就拒絕請求；或者等待一個人來解決。還要決定相關欄位是作為一次變更一起傳遞，還是逐個傳遞。第 6 章會更深入地討論衝突（迴圈與衝突）。
在門口攔住重複
Section titled “在門口攔住重複 ”重複會不斷累積。在建立之前攔住一個，它是個小問題。兩年後才發現它，而兩邊都掛著商機、案例、連絡人、發票、整合和分析，它就是個大問題了。第 3 章的模組 7 講過這些機制（比對規則、重複規則、唯一的外部 ID），我就不再重複了。治理問題是：**我們必須在哪裡防止重複，又在哪裡容忍它、之後再解決？**一個隨意的營銷線索可以容忍模糊。一個有財務交易、受 ERP 治理的客戶則不行。
把機器要讀的東西標準化
Section titled “把機器要讀的東西標準化 ”自由文字對人來說很棒，但當系統必須解讀它時就很糟糕。在一個驅動路線安排的欄位裡放上 Arizona、AZ、Ariz.、Phoenix area 和 Southwest，你就有了一個品質問題。如果一個值驅動自動化、整合、報表、安全、分配或代理程式的行動，就要認真想一想它必須標準到什麼程度。不是每個文字欄位都要變成挑選清單，但要區分給人讀的資訊和**讓機器據此做決定的資訊。**後者值得更強的控制。
不要讓必填欄位製造假資料
Section titled “不要讓必填欄位製造假資料 ”我們認定一個欄位很重要，於是把它設為必填。使用者不知道答案，系統又不讓他們繼續，於是他們輸入 N/A、Unknown、999999 或 test@test.com。欄位是完整了；資料卻是垃圾。在要求必填之前，先問使用者在那個時間點是否真的知道它。如果不知道，就在流程的後面再要求它，讓另一個系統來提供它，使用臨時狀態，或者在「未知」是一個合理答案時，提供一個明確的未知選項。驗證規則可以執行一項策略，但它沒法讓人知道他們不知道的東西。
每一條資料邊界都需要一個品質決定
Section titled “每一條資料邊界都需要一個品質決定 ”壞資料的來源不只是人；整合產生壞資料的速度更快。一個零售合作夥伴的裝貨清單到了，有幾百行。其中幾行郵政編碼無效，有兩行寫的是一個未知的配送中心，還有兩行重複了同一個訂單編號。怎麼辦？拒絕整個檔案？接受好的行，退回壞的行？全部載入，之後再清理？把例外隔離起來？通知誰，合作夥伴如何得知哪些失敗了？沒有通用的答案，但必須有一個答案。第 4 章說每一個箭頭都需要一個機制。再加一句：**每一條資料邊界都需要一個品質決定：**我們接受、拒絕還是隔離什麼，以及誰擁有這個例外。
每一條資料邊界都需要一個品質決定。
歷史資料不一樣
Section titled “歷史資料不一樣 ”RouteDesk 存著 Steve Trucking 八年的歷史，而它的品質因配送中心而異。我們應該在遷移之前把八年的資料都清理到今天的標準嗎？多半不應該自動這樣做。它是用來做什麼的：日常運營、參考、索賠、報表、趨勢分析？它是否都需要放在 Salesforce 裡，還是有一部分可以留在別處？遷移那一章會深入討論。治理上的要點是：**歷史資料並不自動需要和活躍資料同樣的標準。**如果你要根據它做決定，品質就很重要。如果你保留它只是為了參考，一個不同的標準也許就夠了。在花大錢清理過去之前，先弄清楚它的用途。
度量有人會據此行動的東西
Section titled “度量有人會據此行動的東西 ”治理永遠做不完，所以你需要看到品質何時下滑：重複率上升，被隔離的記錄增多，整合拒收增多，佔位值蔓延，繞過請求增多，報表不再對得上。但不要建 150 個指標然後忽略其中的 143 個。對 Steve Trucking 來說，也許是：沒有有效合作夥伴編號的配送，沒有可用地址的配送，重複的訂單編號，被拒絕的合作夥伴報文，卡在臨時狀態的客戶。一個滿是綠色圓圈的儀表板並不意味著資料是好的。度量那些有人準備據此行動的東西。
**考試之外：AI 改變了什麼。**壞資料越來越多地變成壞行動。一個人在撥打電話之前也許會注意到號碼看起來不對；代理程式則直接使用它拿到的值。重複的客戶、過時的狀態、虛假的必填值和錯誤的識別符號，會直接變成錯誤的訊息或錯誤的更新。這提高了預防的價值，但並沒有消除對資料專員的需要。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 哪些品質問題造成的危害大到足以證明需要預防性的控制。
- 受治理的記錄是自由建立、只能由權威系統建立，還是通過一條從臨時到受治理的路徑建立。
- 哪些屬性歸 Salesforce 所有，哪些它只是引用。
- 沒通過檢查的入站資料會怎樣（接受、拒絕還是隔離），以及誰擁有這個例外。
- 度量哪些品質訊號，讓資料專員看到下滑。
你永遠無法阻止每一條壞記錄。這份工作不是追求完美的資料，而是**防止可以避免的壞資料變成代價高昂的資料。**在重複記錄積累兩年曆史之前攔住它。在十個整合依賴上錯誤的識別符號之前保護好它。讓銷售建立潛在客戶，但在它真正成為受治理的客戶之前，不要假裝它是。而當有壞東西漏進來時，確保有人能看到它、負責它、修復它。
- Salesforce Help，Things to Know About Duplicate Rules (opens in a new tab)（英文），查閱日期 2026-10-14。
- Salesforce Help，Break Up Your Record Details with Dynamic Forms (opens in a new tab)（英文）和 Required and Read-Only Fields in Dynamic Forms (opens in a new tab)（英文），查閱日期 2026-10-14。