Ngăn dữ liệu xấu

🌐 Cũng có bằng 28 ngôn ngữ khác

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 2 trong 6 của chương Chất lượng và quản trị dữ liệu, chương 5 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Quản trị được thiết kế vào org · Tiếp theo: Hiểu dữ liệu của bạn

Câu hỏi mô-đun này trả lời: Làm sao để có dữ liệu tốt, và giữ nó tốt như vậy?

Có hai cách xử lý dữ liệu xấu: chặn nó trước khi nó vào, hoặc dọn dẹp nó sau đó. Bạn sẽ làm cả hai ở mức nào đó. Nhưng nếu được chọn, tôi thà ngăn vấn đề còn hơn xây cả một tổ chức xoay quanh việc dọn dẹp nó mãi mãi. Bản trùng, mã định danh sai, thông tin thiếu, giá trị không chuẩn, người dùng thay đổi các trường mà hệ thống khác sở hữu, tích hợp ghi đè dữ liệu tốt bằng dữ liệu xấu: tất cả đều trở thành dự án dọn dẹp của ai đó. Vì vậy câu hỏi thiết kế là dữ liệu xấu nào tôi có thể ngăn lại ngay từ đầu một cách hợp lý? Và “hợp lý” rất quan trọng, vì câu trả lời không phải là khóa mọi trường cho đến khi hệ thống không dùng được nữa.

“Đủ tốt” là một định nghĩa nghiệp vụ

Trước khi ngăn dữ liệu xấu, hãy định nghĩa thế nào là tốt. Không có một định nghĩa duy nhất. Tốt có thể nghĩa là đủ đầy đủ để chạy quy trình, đủ chính xác để ra quyết định, đủ mới cho khối lượng công việc, đủ nhất quán để kết hợp với các hệ thống khác, đủ duy nhất để biết chúng ta đang nói đến khách hàng nào, đủ chuẩn cho tự động hóa, đủ truy vết được để biết nó đến từ đâu. Nó tùy thuộc vào dữ liệu. Nếu Steve Trucking đang lập hóa đơn cho một Đối tác bán lẻ, danh tính pháp lý của đối tác phải đúng. Nếu một nhân viên kinh doanh đang ghi chú nhanh sau buổi gặp, không ai cần một ủy ban duyệt từng câu. “Đủ tốt” là một định nghĩa nghiệp vụ; kiến trúc sư làm cho nó đo lường được và thực thi được.

Ngăn những lỗi đắt giá

Không phải trường sai nào cũng đáng được chú ý như nhau. Tôi quan tâm nhất đến những lỗi có hệ quả về sau. Một khách hàng bị trùng nghĩa là hai lịch sử bán hàng, hai lịch sử dịch vụ, hai bộ liên hệ, hai ID bên ngoài, hai tích hợp đồng bộ cùng một công ty, hai phiên bản trong kho dữ liệu và trong Data 360, và cuối cùng là một tác tử phải quyết định khách hàng nào là thật. Điều đó đắt hơn nhiều so với một lỗi chính tả trong phần mô tả. Vì vậy đừng bắt đầu với “làm sao xác thực mọi trường?” Hãy bắt đầu với dữ liệu xấu nào tạo ra vấn đề nghiệp vụ hay kiến trúc lớn nhất? và đặt các biện pháp kiểm soát mạnh nhất ở đó.

Mở hay khóa?

Việc tạo tài khoản là ví dụ kinh điển. Có nên cho mọi nhân viên kinh doanh tạo tài khoản không? Câu trả lời của tôi: còn tùy vào việc quản trị quanh dữ liệu. Với phần lớn org nhỏ và vừa, tạo mở là ổn. Một nhân viên gặp một khách hàng tiềm năng, tạo tài khoản, bắt tay vào việc; CRM sinh ra là để làm thế. Quy tắc trùng lặp, thông tin bắt buộc và việc quản lý dữ liệu sẽ lo chất lượng. Tôi không thêm một quy trình phê duyệt nặng nề chỉ vì quản trị nghe có vẻ có trách nhiệm.

Giờ thay đổi bản đồ hệ thống. Khách hàng pháp lý được quản lý chủ trong ERP, chảy vào Salesforce với một mã định danh ERP, và ERP có thẩm quyền. Giờ tạo mở nghĩa là có hai cách tạo cùng một thực thể được quản trị. Khi ERP và một nhân viên kinh doanh cùng tạo một công ty, bên nào thắng, tích hợp dùng mã định danh nào, bản ghi nào giữ lịch sử? Tạo mở không còn là câu hỏi về khả năng sử dụng mà trở thành câu hỏi về dữ liệu chủ. Khi tài khoản được quản lý chủ trong ERP hoặc đồng bộ với ERP, hãy khóa việc tạo lại.

Nhưng khóa hoàn toàn cũng thất bại. Nhân viên kinh doanh đã gặp một khách hàng tiềm năng chưa có trong ERP và muốn mở một cơ hội, còn mô hình quản trị nói “không có tài khoản cho bạn”. Vậy là họ chờ ba ngày để Tài chính xử lý, hoặc gắn cơ hội vào sai tài khoản, hoặc giữ khách hàng tiềm năng trong một trường ghi chú hay một bảng tính. Chúng ta đã bảo vệ mô hình dữ liệu và làm hại nghiệp vụ.

Con đường ở giữa: một loại bản ghi tạm thời

Đây là con đường ở giữa mà tôi thích. Cho bộ phận kinh doanh tạo tài khoản dưới một loại bản ghi riêng, loại khách hàng tiềm năng hay loại tạm thời, và kiểm soát việc chuyển đổi nó sang loại được quản trị. Bộ phận kinh doanh ghi nhận công ty và bắt đầu bán hàng. Bản ghi nói rõ ràng: chưa được thiết lập trong hệ thống có thẩm quyền. Rồi một quy trình có kiểm soát chuyển đổi nó: Tài chính phê duyệt, hoặc một tích hợp gửi nó đến ERP, nơi khớp nó với một khách hàng đã có hoặc tạo khách hàng mới và gửi lại mã định danh có thẩm quyền. Giờ bản ghi vượt qua một ranh giới, tạm thời → được quản trị, điều rất khác với việc hai hệ thống mỗi bên tạo ra thứ mà mình tin là bản ghi chủ.

Loại bản ghi là cơ chế tôi giảng dạy. Dù bạn dùng gì, hãy làm cho trạng thái hiện rõ trong dữ liệu: bản ghi đến từ đâu, nó đã vượt qua ranh giới chưa, giờ ai được thay đổi nó, và mã định danh gắn nó với hệ thống có thẩm quyền. ID khách hàng ERP chỉ tồn tại sau khi chuyển đổi là tín hiệu rõ ràng nhất.

Mỗi luồng một loại bản ghi

Đặt toàn bộ luồng lên một bức hình và bạn sẽ thấy vì sao cách này hiệu quả. Khách hàng và sản phẩm đi vào từ ERP. Cơ hội và các mục dòng của chúng đi ra và trở thành đơn hàng của ERP. Còn tài khoản? Một số đi vào, một số đi ra. Vì vậy, một mẫu phổ biến tôi đã thấy qua nhiều dự án triển khai là hai loại bản ghi trên Tài khoản, mỗi chiều một loại. Một tài khoản Sales sinh ra trong Salesforce: nhân viên kinh doanh tạo nó, sửa nó, bán hàng cho nó, và khi nó trở thành khách hàng thì nó được gửi ra ERP. Một tài khoản ERP (tôi từng gọi nó là Customer, hoặc đơn giản là SAP) sinh ra trong ERP và đi vào qua tích hợp. Không ai tạo loại bản ghi đó ngoài tích hợp, và các trường dữ liệu chủ của nó (tên pháp lý, địa chỉ, điều khoản thanh toán) là chỉ đọc với người dùng. Loại bản ghi cho bạn biết bản ghi chảy theo chiều nào, nên chiều quản lý chủ nằm ngay trên bản ghi.

Click to enlarge

Mỗi luồng một loại bản ghi: tài khoản Sales đi ra, tài khoản ERP đi vào.

Cách này không xóa được trường hợp khó. Một nhân viên kinh doanh chuyển đổi một khách hàng tiềm năng cho Steve’s Plumbing, nhưng Steve’s Plumbing đã tồn tại dưới dạng tài khoản ERP, và bằng cách nào đó việc kiểm tra trùng lặp đã không bắt được. Giờ bạn phải hợp nhất, gắn lại cha cho các bản ghi con và quyết định bản ghi nào được giữ lại (chương 6, mô-đun 3).

Và đừng mắc kẹt ở chính loại bản ghi. Bình thường tôi tránh loại bản ghi trừ khi có lý do mạnh mẽ. Tôi dùng chúng ở đây vì, trước khi có Biểu mẫu động (Dynamic Forms), loại bản ghi chọn bố cục trang, và một bố cục hiển thị các trường ERP ở dạng chỉ đọc. Với Dynamic Forms, quy tắc hiển thị có thể hiện và ẩn trường theo giá trị của một trường, một trường có thể là chỉ đọc trên một trang nhất định, và chính Salesforce nói Dynamic Forms giảm số bố cục trang và loại bản ghi bạn cần (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), tiếng Anh). Nhưng chỉ đọc trên một trang là chỉ đọc trên trang đó: API, một lần nạp dữ liệu hay một tích hợp vẫn có thể ghi vào trường. Việc thực thi thật sự là bảo mật cấp trường hoặc một quy tắc xác thực; xác thực trên giao diện không phải là xác thực dữ liệu (chương 3, mô-đun 9). Loại bản ghi vẫn xứng đáng với vị trí của nó khi hai kiểu tài khoản cần giá trị danh sách chọn hoặc quy trình nghiệp vụ khác nhau. Điều thực sự quan trọng là có một trường nói rõ bản ghi đến từ đâu: chính khóa ERP, một cờ dữ liệu chủ, hoặc một danh sách chọn nguồn. Rồi dựa vào trường đó để quyết định ai được sửa.

Click to enlarge

Từ tạm thời đến được quản trị: bộ phận kinh doanh bắt đầu bán hàng ngay; chỉ quy trình có thẩm quyền mới làm cho bản ghi được quản trị.

Bảo vệ bản ghi được quản trị

Một khi khách hàng quay về từ ERP, ID ERP, tên pháp lý, mã số thuế và thông tin thanh toán của nó là các thuộc tính được quản trị. Nhân viên kinh doanh có nên thay đổi chúng không? Không, nếu ERP sở hữu chúng. Đó là chính sách của mô-đun 1 cần điểm thực thi của nó: ID ERP chỉ đọc, danh tính pháp lý được kiểm soát, trong khi nhân viên kinh doanh vẫn sửa lãnh thổ, ghi chú quan hệ và các phân loại riêng của Salesforce. Mục tiêu không phải là một tài khoản bất khả xâm phạm. Mà là một đường ranh rõ ràng giữa dữ liệu Salesforce sở hữu và dữ liệu Salesforce tham chiếu. (Tiền tố erp_ từ chương 4 làm cho đường ranh đó hiện rõ trong lược đồ.)

Kết quả bạn có là một bản ghi vàng thực chất là kết hợp. Các trường dữ liệu chủ của ERP đi vào: tên pháp lý, địa chỉ thanh toán và giao hàng, điều khoản thanh toán. Rồi Salesforce thêm các trường riêng của nó, những trường không bao giờ quay ngược lại: xếp hạng bán hàng, ngày đặt hàng gần nhất, gần như mọi thứ bộ phận marketing dùng. Cùng một tài khoản, hai kiểu trường, và mỗi kiểu có một nguồn.

Điều khó nhất là các trường hai chiều. Giả sử một nhân viên kinh doanh cần đổi tên pháp lý trong ERP từ Steve’s Plumbing thành Steve’s Plumbing LLC. Trong cùng năm phút đó, một người trong ERP đổi nó thành Steve’s Plumbing L.L.C. Thay đổi của ai thắng? Đây là tư duy cần có: nếu một trường được quản lý chủ trong ERP, bạn không thay đổi trường đó, bạn đang yêu cầu thay đổi nó. Hãy quyết định điều gì xảy ra khi yêu cầu va chạm: ERP thắng, yêu cầu bị từ chối nếu giá trị đã thay đổi trong lúc đó, hoặc nó chờ một người giải quyết. Và hãy quyết định liệu các trường liên quan đi cùng nhau như một thay đổi hay từng trường một. Chương 6 đi xa hơn về xung đột (Vòng lặp và xung đột).

Chặn bản trùng ngay tại cửa

Bản trùng tích tụ dần. Bắt được một bản trùng trước khi nó được tạo thì đó là vấn đề nhỏ. Tìm thấy nó hai năm sau, với cơ hội, trường hợp, liên hệ, hóa đơn, tích hợp và phân tích treo trên cả hai, thì đó là vấn đề lớn. Mô-đun 7 của chương 3 đã trình bày các cơ chế (quy tắc khớp, quy tắc trùng lặp, ID bên ngoài duy nhất), nên tôi sẽ không dạy lại. Câu hỏi quản trị là chúng ta phải ngăn trùng lặp ở đâu, và ở đâu chúng ta chấp nhận nó rồi giải quyết sau? Một khách hàng tiềm năng marketing thông thường có thể sống chung với sự mơ hồ. Một khách hàng được ERP quản trị với các giao dịch tài chính thì không.

Chuẩn hóa những gì máy móc đọc

Văn bản tự do tuyệt vời cho con người và tệ hại khi một hệ thống phải diễn giải nó. Đặt Arizona, AZ, Ariz., Phoenix area và Southwest vào một trường điều khiển việc định tuyến, và bạn có một vấn đề chất lượng. Nếu một giá trị điều khiển tự động hóa, tích hợp, báo cáo, bảo mật, giao việc hay hành động của tác tử, hãy suy nghĩ kỹ về mức độ chuẩn mà nó phải có. Không phải trường văn bản nào cũng trở thành danh sách chọn, nhưng hãy phân biệt thông tin con người đọc với thông tin máy móc dựa vào để quyết định. Loại thứ hai xứng đáng được kiểm soát chặt hơn.

Đừng để trường bắt buộc tạo ra dữ liệu giả

Chúng ta quyết định một trường quan trọng và đặt nó là bắt buộc. Người dùng không biết câu trả lời, hệ thống không cho họ đi tiếp, nên họ gõ N/A, Unknown, 999999 hoặc test@test.com. Trường đã đầy đủ; dữ liệu là rác. Trước khi bắt buộc điều gì, hãy hỏi liệu người dùng có thực sự biết nó vào thời điểm đó không. Nếu không, hãy bắt buộc nó muộn hơn trong quy trình, để một hệ thống khác cung cấp nó, dùng trạng thái tạm thời, hoặc đưa ra một giá trị Unknown rõ ràng khi “không biết” là một câu trả lời hợp lệ. Một quy tắc xác thực có thể thực thi một chính sách. Nó không thể làm cho ai đó biết điều họ không biết.

Mỗi ranh giới dữ liệu cần một quyết định chất lượng

Con người không phải là nguồn dữ liệu xấu duy nhất; tích hợp tạo ra nó nhanh hơn. Bảng kê hàng của một Đối tác bán lẻ đến với vài trăm dòng. Một số dòng có mã bưu chính không hợp lệ, một vài dòng ghi một trung tâm phân phối không xác định, hai dòng lặp lại cùng một mã tham chiếu đơn hàng. Chuyện gì xảy ra? Từ chối cả tệp? Chấp nhận các dòng tốt và trả lại các dòng xấu? Nạp hết rồi dọn sau? Cách ly các ngoại lệ? Ai được thông báo, và đối tác biết cái gì thất bại bằng cách nào? Không có câu trả lời chung cho mọi trường hợp, nhưng phải có một câu trả lời. Chương 4 nói mỗi mũi tên cần một cơ chế. Thêm vào: mỗi ranh giới dữ liệu cần một quyết định chất lượng: chúng ta chấp nhận, từ chối hay cách ly cái gì, và ai sở hữu ngoại lệ.

Click to enlarge

Mỗi ranh giới dữ liệu cần một quyết định chất lượng.

Dữ liệu lịch sử thì khác

RouteDesk giữ tám năm lịch sử của Steve Trucking, và chất lượng của nó khác nhau theo từng trung tâm phân phối. Chúng ta có nên làm sạch cả tám năm theo tiêu chuẩn hôm nay trước khi chuyển nó không? Có lẽ không tự động như vậy. Nó dùng để làm gì: vận hành hằng ngày, tham chiếu, khiếu nại, báo cáo, phân tích xu hướng? Có cần tất cả nằm trong Salesforce không, hay một phần có thể ở lại nơi khác? Chương về chuyển đổi dữ liệu đi sâu. Điểm về quản trị: lịch sử không tự động cần cùng tiêu chuẩn như dữ liệu đang hoạt động. Nếu bạn sẽ ra quyết định dựa trên nó, chất lượng quan trọng. Nếu bạn giữ nó để tham chiếu, một tiêu chuẩn khác có thể là đủ. Hãy biết mục đích trước khi tiêu cả một gia tài để làm sạch quá khứ.

Đo những gì có người sẽ hành động

Quản trị không bao giờ kết thúc, nên bạn cần thấy khi chất lượng trượt xuống: tỷ lệ trùng lặp tăng, nhiều bản ghi bị cách ly hơn, nhiều lần tích hợp từ chối hơn, giá trị giữ chỗ lan rộng, nhiều yêu cầu miễn trừ hơn, báo cáo không còn khớp nhau. Nhưng đừng xây 150 chỉ số rồi phớt lờ 143 cái. Với Steve Trucking, có thể đó là các lần giao hàng không có mã tham chiếu đối tác hợp lệ, các lần giao hàng không có địa chỉ dùng được, mã tham chiếu đơn hàng lặp lại, thông điệp đối tác bị từ chối, tài khoản kẹt ở trạng thái tạm thời. Một bảng điều khiển đầy vòng tròn xanh không có nghĩa là dữ liệu tốt. Hãy đo những gì có người sẵn sàng hành động.

Ngoài kỳ thi: AI thay đổi điều gì. Dữ liệu xấu ngày càng trở thành hành động xấu. Một người có thể nhận ra số điện thoại trông sai trước khi gọi; một tác tử thì đơn giản dùng giá trị được đưa cho nó. Khách hàng trùng lặp, trạng thái cũ, giá trị bắt buộc giả và mã định danh sai biến thẳng thành thông điệp sai hay cập nhật sai. Điều đó làm tăng giá trị của việc phòng ngừa. Nó không xóa bỏ nhu cầu quản lý dữ liệu.

Kiến trúc sư quyết định gì ở đây

• Những thất bại chất lượng nào gây đủ tác hại để biện minh cho các biện pháp kiểm soát phòng ngừa.
• Bản ghi được quản trị được tạo tự do, chỉ bởi hệ thống có thẩm quyền, hay qua một con đường từ tạm thời đến được quản trị.
• Những thuộc tính nào Salesforce sở hữu và những thuộc tính nào nó chỉ tham chiếu.
• Chuyện gì xảy ra với dữ liệu đầu vào không qua được kiểm tra (chấp nhận, từ chối hay cách ly) và ai sở hữu ngoại lệ.
• Những tín hiệu chất lượng nào được đo, để người quản lý dữ liệu thấy được sự trượt dốc.

Bạn sẽ không bao giờ ngăn được mọi bản ghi xấu. Công việc không phải là dữ liệu hoàn hảo; mà là không để dữ liệu xấu tránh được trở thành dữ liệu đắt giá. Chặn bản trùng trước khi nó có hai năm lịch sử. Bảo vệ mã định danh trước khi mười tích hợp phụ thuộc vào cái sai. Cho bộ phận kinh doanh tạo khách hàng tiềm năng, nhưng đừng giả vờ nó là khách hàng được quản trị cho đến khi nó thực sự là. Và khi có thứ xấu lọt qua, hãy đảm bảo có ai đó thấy được nó, sở hữu nó và sửa nó.

Tìm hiểu thêm

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) và Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.