Paul Digital Hub – nền tảng kết nối công nghệ, dữ liệu và con người, được sáng lập bởi Nghĩa Nguyễn (Paul). Với hơn 10 năm kinh nghiệm trong lĩnh vực ERP, Business Intelligence và Chuyển đổi số, tôi xây dựng hub này nhằm chia sẻ kiến thức, cung cấp tài nguyên học tập, công cụ hữu ích và dịch vụ tư vấn chuyên sâu – giúp doanh nghiệp Việt ứng dụng công nghệ hiệu quả và phát triển bền vững.
Master Data không phải việc riêng của IT – dữ liệu gốc cần một người chịu trách nhiệm rõ ràng
Một nhân viên bán hàng cần tạo gấp mã khách hàng để lên đơn. Kế toán kiểm tra lại thì phát hiện khách hàng đó đã có trên hệ thống, nhưng tên viết khác và mã số thuế chưa được cập nhật.
Một yêu cầu tưởng như rất nhỏ lại kéo theo câu hỏi không dễ trả lời: Ai mới là người chịu trách nhiệm cho Master Data của doanh nghiệp?
Một mã khách hàng được tạo trong vài phút
Bộ phận bán hàng vừa nhận được đơn từ một khách hàng mới. Để kịp giao hàng, nhân viên gửi yêu cầu tạo mã khách hàng trên ERP. Thông tin được cung cấp khá ngắn: tên công ty, số điện thoại và địa chỉ giao hàng.
Mã được tạo trong vài phút. Sales Order được nhập, kho chuẩn bị hàng và quy trình tiếp tục chạy. Vài ngày sau, kế toán cần phát hành hóa đơn và phát hiện một số vấn đề:
Tên pháp lý của khách hàng chưa đúng
Mã số thuế bị thiếu
Địa chỉ hóa đơn khác địa chỉ giao hàng
Khách hàng đã tồn tại dưới một tên viết tắt khác
Điều khoản thanh toán đang được chọn không đúng
Lúc này, doanh nghiệp phải quyết định giữ mã nào, chuyển chứng từ ra sao và ai sẽ cập nhật lại dữ liệu. – Bán hàng cho rằng việc tạo mã nằm trên ERP nên IT phải chịu trách nhiệm.
– IT cho rằng thông tin khách hàng do bộ phận kinh doanh cung cấp.
– Kế toán lại là bộ phận phải xử lý hậu quả khi hóa đơn và công nợ bị sai.
Vấn đề không chỉ nằm ở một mã khách hàng bị trùng. Vấn đề nằm ở chỗ doanh nghiệp chưa xác định rõ ai là người sở hữu dữ liệu đó.
Master Data là gì?
Master Data thường được dịch là dữ liệu chủ hoặc dữ liệu gốc. Đây là những dữ liệu được nhiều giao dịch và nhiều bộ phận sử dụng lặp lại trong thời gian dài.
Trong một hệ thống ERP, Master Data thường gồm:
Khách hàng
Nhà cung cấp
Hàng hóa và nguyên vật liệu
Đơn vị tính
Kho và vị trí kho
Bảng giá
Điều khoản thanh toán
Tài khoản kế toán
Cost Center và Dimension
Nhân viên và bộ phận
Định mức nguyên vật liệu
Danh mục tài sản
Master Data khác với dữ liệu giao dịch. Sales Order, hóa đơn, phiếu nhập kho hoặc phiếu thanh toán là những giao dịch phát sinh theo thời điểm. Trong khi đó, dữ liệu khách hàng, mã hàng, đơn vị tính hoặc điều khoản thanh toán được dùng lại trong rất nhiều giao dịch khác nhau.
Chỉ một dữ liệu gốc bị sai cũng có thể làm hàng trăm chứng từ phía sau sai theo.
Giao dịch sai thường ảnh hưởng đến một lần xử lý. Master Data sai có thể làm cả một chuỗi giao dịch, báo cáo và quyết định sai theo.
Khi mỗi phòng ban nhìn cùng một dữ liệu theo cách khác nhau
Một khách hàng đối với bộ phận bán hàng là người mua sản phẩm và tạo ra doanh thu.
– Đối với kế toán, khách hàng còn gắn với tên pháp lý, mã số thuế, điều khoản thanh toán, hạn mức tín dụng và tài khoản công nợ.
– Đối với kho, khách hàng liên quan đến địa chỉ giao hàng, yêu cầu đóng gói và lịch giao nhận.
– Đối với bộ phận chăm sóc khách hàng, dữ liệu còn gồm người liên hệ, lịch sử tương tác và nhóm dịch vụ.
Không bộ phận nào nhìn thấy toàn bộ dữ liệu theo cùng một cách.
Điều tương tự cũng xảy ra với hàng hóa. Bán hàng quan tâm tên thương mại, giá bán và nhóm sản phẩm. Kho quan tâm kích thước, trọng lượng, đơn vị tính, phương pháp quản lý batch hoặc serial. Mua hàng quan tâm nhà cung cấp, thời gian cung ứng và quy cách mua. Kế toán quan tâm tài khoản doanh thu, giá vốn, tồn kho và thuế. Sản xuất quan tâm BOM, định mức, loại cấp phát và khả năng thay thế.
Vì vậy, không thể giao toàn bộ trách nhiệm cho một bộ phận chỉ vì bộ phận đó có quyền tạo dữ liệu trên hệ thống.
Vì sao dữ liệu gốc sai làm ERP sai theo?
ERP vận hành dựa trên việc tái sử dụng dữ liệu.
Khi người dùng chọn một mã hàng, hệ thống có thể tự lấy theo nhiều thông tin:
Nhóm hàng
Đơn vị tính
Kho mặc định
Phương pháp định giá
Tài khoản kế toán
Thuế suất
Phương pháp quản lý tồn kho
Quy tắc batch hoặc serial
Nếu dữ liệu gốc đúng, người dùng giảm được nhiều thao tác và hệ thống vận hành nhất quán hơn. Nếu dữ liệu gốc sai, hệ thống vẫn có thể chạy rất nhanh nhưng kết quả được tạo ra không đúng.
Một mã hàng được gán sai nhóm có thể đi vào sai tài khoản doanh thu hoặc giá vốn.
Một khách hàng được chọn sai điều khoản thanh toán có thể làm lệch báo cáo công nợ và dự báo dòng tiền.
Một đơn vị tính sai có thể gây lệch số lượng tồn kho, kế hoạch mua hàng và định mức sản xuất.
Đến cuối kỳ, doanh nghiệp thường thấy sai ở báo cáo. Nhưng nguyên nhân thật có thể đã phát sinh từ lúc dữ liệu gốc được tạo nhiều tháng trước.
IT không thể là người sở hữu toàn bộ dữ liệu
Trong nhiều doanh nghiệp, IT hoặc đội ERP được giao quyền tạo và chỉnh sửa Master Data. Điều này hợp lý ở góc độ kiểm soát hệ thống. Không phải người dùng nào cũng nên có quyền thay đổi dữ liệu gốc.
Nhưng có quyền thao tác không đồng nghĩa với quyền quyết định nội dung. IT có thể kiểm tra trường bắt buộc, phân quyền người dùng, lưu lịch sử thay đổi và thiết lập workflow phê duyệt. IT không thể tự quyết định:
Hai khách hàng có phải cùng một pháp nhân hay không
Sản phẩm thuộc nhóm kinh doanh nào
Điều khoản tín dụng nào được phép áp dụng
Mặt hàng phải quản lý theo batch hay serial
Chi phí cần ghi nhận vào Cost Center nào
Nhà cung cấp còn đủ điều kiện giao dịch hay không
Đó là các quyết định nghiệp vụ.
Nếu doanh nghiệp giao toàn bộ trách nhiệm dữ liệu cho IT, đội IT sẽ phải ra quyết định dựa trên thông tin do các phòng ban gửi đến mà không có đủ thẩm quyền hoặc ngữ cảnh. Khi dữ liệu sai, trách nhiệm lại trở nên không rõ ràng.
Ba vai trò cần được phân biệt
1. Data Owner
Data Owner là người hoặc bộ phận chịu trách nhiệm về ý nghĩa, chính sách và chất lượng tổng thể của một nhóm dữ liệu.
Ví dụ:
Kinh doanh có thể là Data Owner của phân nhóm khách hàng
Kế toán có thể là Data Owner của mã số thuế, điều khoản thanh toán và tài khoản công nợ
Kho hoặc Supply Chain có thể là Data Owner của quy cách, đơn vị tính và phương pháp quản lý tồn kho
Kế toán trưởng có thể là Data Owner của hệ thống tài khoản
Data Owner không nhất thiết là người trực tiếp nhập dữ liệu. Đây là người có quyền đưa ra quy định và chịu trách nhiệm khi dữ liệu không đáp ứng yêu cầu nghiệp vụ.
2. Data Steward
Data Steward là người trực tiếp duy trì chất lượng dữ liệu hằng ngày.
Họ có thể thực hiện:
Kiểm tra yêu cầu tạo mới
Phát hiện dữ liệu trùng
Kiểm tra trường bắt buộc
Đối chiếu hồ sơ
Chuẩn hóa cách đặt tên
Theo dõi dữ liệu thiếu
Đề xuất khóa hoặc hợp nhất dữ liệu
Trong doanh nghiệp nhỏ, Data Steward có thể là một vai trò kiêm nhiệm. Điều quan trọng là trách nhiệm phải được gọi tên rõ, thay vì để mọi người nghĩ rằng “ai tạo cũng được”.
3. System Owner hoặc IT
IT chịu trách nhiệm về nền tảng kỹ thuật.
Vai trò này gồm:
Thiết lập quyền truy cập
Cấu hình trường bắt buộc
Thiết lập workflow
Quản lý tích hợp
Lưu lịch sử thay đổi
Sao lưu và bảo mật dữ liệu
Hỗ trợ công cụ kiểm tra trùng
IT bảo đảm quy trình dữ liệu được thực thi đúng trên hệ thống. Nhưng nội dung nghiệp vụ vẫn phải do Data Owner quyết định.
Những dữ liệu nào cần xác định chủ sở hữu?
Không phải mọi trường dữ liệu đều cần một hội đồng phê duyệt.
Doanh nghiệp nên ưu tiên những dữ liệu:
Được nhiều phòng ban sử dụng
Ảnh hưởng đến tài chính hoặc pháp lý
Khó sửa sau khi đã phát sinh giao dịch
Dễ bị tạo trùng
Ảnh hưởng đến báo cáo quản trị
Được dùng trong tích hợp giữa nhiều hệ thống
Một ma trận trách nhiệm đơn giản có thể gồm:
Khách hàng: Kinh doanh, kế toán và pháp chế
Nhà cung cấp: Mua hàng, kế toán và kiểm soát chất lượng
Hàng hóa: Kinh doanh, kho, mua hàng, sản xuất và kế toán
Tài khoản kế toán: Kế toán trưởng
Cost Center: Tài chính và quản lý vận hành
Nhân viên: Nhân sự
Kho: Supply Chain và kế toán
Một nhóm dữ liệu có thể có nhiều bộ phận tham gia.
Tuy nhiên, vẫn cần một người chịu trách nhiệm cuối cùng, tránh tình trạng mọi phòng ban đều có ý kiến nhưng không ai có quyền kết luận.
Master Data cũng có một vòng đời
Dữ liệu gốc không chỉ được tạo một lần rồi tồn tại mãi mãi. Nó có một vòng đời gồm nhiều trạng thái.
Tạo mới
Doanh nghiệp cần xác định điều kiện nào đủ để tạo một mã mới.
Ví dụ, khách hàng có cần mã số thuế không? Khách hàng cá nhân và doanh nghiệp có dùng cùng một quy trình không? Một sản phẩm thử nghiệm có được tạo mã chính thức không?
Kiểm tra và phê duyệt
Trước khi dữ liệu được sử dụng, các trường quan trọng cần được kiểm tra.
Không nhất thiết mọi trường hợp đều phải qua nhiều cấp duyệt. Nhưng các dữ liệu ảnh hưởng đến tín dụng, tài khoản hoặc thuế cần có người có thẩm quyền xác nhận.
Thay đổi
Thay đổi tên, nhóm, đơn vị tính hoặc điều khoản thanh toán có thể ảnh hưởng đến các giao dịch mới và báo cáo lịch sử.
Doanh nghiệp cần quy định trường nào được sửa, trường nào phải tạo mã mới và thay đổi nào cần lưu lý do.
Tạm khóa hoặc ngừng sử dụng
Khách hàng ngừng giao dịch, nhà cung cấp không còn đạt chuẩn hoặc sản phẩm dừng kinh doanh không nên bị xóa nếu đã có chứng từ.
Giải pháp phù hợp thường là chuyển trạng thái không hoạt động, đồng thời giữ nguyên dữ liệu lịch sử.
Hợp nhất và làm sạch
Dữ liệu trùng cần được rà soát định kỳ.
Doanh nghiệp phải xác định mã chính, chuyển thông tin liên quan và ngăn người dùng tiếp tục sử dụng mã không còn hợp lệ.
Một quy trình tạo mã khách hàng nên có gì?
Quy trình không cần quá phức tạp, nhưng phải đủ để ngăn lỗi phổ biến.
Một flow tham khảo:
Bán hàng gửi yêu cầu tạo khách hàng.
Hệ thống hoặc Data Steward kiểm tra tên, mã số thuế, số điện thoại và địa chỉ để phát hiện trùng.
Kế toán kiểm tra thông tin pháp lý, thuế và điều khoản thanh toán.
Người có thẩm quyền xác nhận hạn mức tín dụng nếu có.
Mã được tạo theo quy tắc thống nhất.
Người yêu cầu nhận thông báo và bắt đầu sử dụng.
Không phải khách hàng nào cũng cần đầy đủ cùng một bộ thông tin.
Doanh nghiệp có thể phân loại:
Khách hàng tiềm năng
Khách hàng bán lẻ
Khách hàng doanh nghiệp
Khách hàng có công nợ
Khách hàng chỉ thanh toán ngay
Mỗi loại có thể có yêu cầu dữ liệu và mức phê duyệt khác nhau.
Điều quan trọng là không dùng áp lực “cần lên đơn gấp” để bỏ qua toàn bộ kiểm soát, rồi xử lý hậu quả về sau.
Một mã hàng còn phức tạp hơn
Tạo mã hàng thường liên quan đến nhiều bộ phận hơn tạo mã khách hàng.
Một yêu cầu tạo mới có thể cần xác định:
Tên hàng chuẩn
Tên thương mại
Nhóm hàng
Loại hàng hóa, nguyên liệu hoặc dịch vụ
Đơn vị tính mua, bán và tồn kho
Quy cách đóng gói
Quản lý batch hoặc serial
Thời hạn sử dụng
Phương pháp định giá
Tài khoản kế toán
Thuế suất
Kho mặc định
Nhà cung cấp ưu tiên
Nếu giao toàn bộ cho một nhân viên IT, họ sẽ phải hỏi lại từng phòng ban.
Nếu cho mọi phòng ban tự tạo, dữ liệu rất dễ thiếu nhất quán.
Cách phù hợp hơn là dùng biểu mẫu hoặc workflow tập hợp thông tin từ các Data Owner liên quan, sau đó Data Steward kiểm tra trước khi mã được kích hoạt.
Không phải trường hợp nào cũng nên cho tạo tự do
Quyền tạo nhanh giúp hoạt động kinh doanh linh hoạt hơn.
Nhưng một số dữ liệu có mức rủi ro cao và không nên được tạo tùy ý.
Ví dụ:
Tài khoản kế toán
Nhóm hàng ảnh hưởng đến G/L Determination
Đơn vị tính và hệ số quy đổi
Điều khoản thanh toán
Thuế suất
Cost Center
Loại tài sản
Mã hàng quản lý batch hoặc serial
Một thay đổi nhỏ ở các dữ liệu này có thể ảnh hưởng đến nhiều giao dịch và báo cáo.
Doanh nghiệp nên giới hạn quyền, yêu cầu phê duyệt hoặc ít nhất lưu lại lịch sử người thay đổi.
Xử lý dữ liệu trùng không chỉ là xóa một dòng
Khi phát hiện hai mã khách hàng hoặc hai mã hàng trùng nhau, phản ứng đầu tiên thường là xóa một mã.
Nhưng nếu mã đã có giao dịch, việc xử lý phức tạp hơn.
Doanh nghiệp cần kiểm tra:
Mã nào có thông tin đầy đủ hơn?
Mã nào đã phát sinh chứng từ?
Công nợ đang nằm ở mã nào?
Báo cáo lịch sử sẽ bị ảnh hưởng ra sao?
Các hệ thống khác đang dùng mã nào?
Có cần chuyển người liên hệ, địa chỉ hoặc bảng giá không?
Trong nhiều ERP, dữ liệu đã có giao dịch không nên hoặc không thể xóa.
Giải pháp thường là chọn một mã chính, khóa mã còn lại và ghi chú rõ quan hệ giữa hai mã.
Nếu cần hợp nhất dữ liệu, phải có quy trình kỹ thuật và nghiệp vụ riêng, không nên sửa trực tiếp thiếu kiểm soát.
Khi nào nên chặn, khi nào chỉ nên cảnh báo?
Không phải lỗi dữ liệu nào cũng cần chặn người dùng.
Nếu đặt quá nhiều rule bắt buộc, quy trình có thể trở nên nặng nề và người dùng tìm cách lách hệ thống.
Có thể phân loại:
Nên chặn
Thiếu mã số thuế trong trường hợp bắt buộc
Trùng mã số thuế với khách hàng đang hoạt động
Hệ số quy đổi đơn vị tính không hợp lệ
Thiếu tài khoản kế toán bắt buộc
Dữ liệu vi phạm quy định pháp lý
Nên cảnh báo
Tên gần giống một khách hàng đã có
Địa chỉ chưa đầy đủ
Sản phẩm có tên gần giống mã hiện hữu
Điều khoản thanh toán khác với nhóm khách hàng
Một trường mô tả chưa được điền
Rule tốt không chỉ chặn sai.
Nó phải giúp người dùng hiểu vì sao dữ liệu chưa hợp lệ và cần bổ sung điều gì.
Master Data và chất lượng dashboard
Dashboard thường là nơi doanh nghiệp nhìn thấy hậu quả của Master Data không nhất quán.
Một khách hàng có ba mã sẽ xuất hiện như ba khách hàng khác nhau.
Một sản phẩm được gán hai nhóm sẽ làm doanh thu theo ngành hàng bị phân tán.
Một chi nhánh được viết nhiều cách sẽ tạo ra nhiều dòng trên báo cáo.
Đội BI có thể dùng Power Query, mapping table hoặc logic DAX để gộp dữ liệu. Nhưng đó thường chỉ là xử lý phần biểu hiện. Nếu dữ liệu gốc tiếp tục được tạo sai, mỗi kỳ báo cáo lại phải bổ sung một lớp mapping mới.
Doanh nghiệp nhỏ và vừa không nhất thiết phải xây dựng một bộ máy Data Governance lớn.
Có thể bắt đầu bằng một mô hình gọn:
Lập danh sách các nhóm Master Data quan trọng.
Chỉ định một Data Owner cho mỗi nhóm.
Chọn một hoặc một vài Data Steward kiêm nhiệm.
Chuẩn hóa biểu mẫu tạo và thay đổi dữ liệu.
Giới hạn quyền tạo trực tiếp trên ERP.
Thiết lập một số rule phát hiện trùng và thiếu dữ liệu.
Rà soát dữ liệu định kỳ.
Theo dõi các lỗi lặp lại để cải tiến quy trình.
Mục tiêu ban đầu không phải làm dữ liệu hoàn hảo.
Mục tiêu là tạo ra một cơ chế mà mỗi dữ liệu quan trọng đều có người chịu trách nhiệm và có cách kiểm tra.
Một checklist để bắt đầu
Doanh nghiệp đang có những nhóm Master Data nào?
Dữ liệu nào thường xuyên bị trùng hoặc thiếu?
Ai đang có quyền tạo và chỉnh sửa?
Ai hiểu rõ ý nghĩa nghiệp vụ nhất?
Ai chịu hậu quả khi dữ liệu sai?
Trường nào bắt buộc trước khi kích hoạt?
Thay đổi nào cần phê duyệt?
Dữ liệu ngừng dùng được xử lý ra sao?
Có lưu lịch sử thay đổi hay không?
ERP, CRM và BI đang dùng chung mã như thế nào?
Chỉ cần trả lời rõ những câu hỏi này, doanh nghiệp đã có thể phát hiện nhiều khoảng trống trong cách quản lý dữ liệu hiện tại.
Đọc thêm về ERP, BI và dữ liệu doanh nghiệp
Master Data nằm ở giao điểm của nghiệp vụ, ERP và phân tích dữ liệu.
Có thể xem thêm các bài trong chuyên mục ERP, Power BI và Chuyển đổi số để hiểu thêm cách dữ liệu được tạo, vận hành và chuyển thành thông tin quản trị.
