Master Data ERP là lớp dữ liệu nền được nhiều quy trình cùng tham chiếu: khách hàng, nhà cung cấp, sản phẩm, vật tư, BOM, tài khoản kế toán, cost center, đơn vị tính, kho và các danh mục dùng chung. Nếu master data không có owner và governance, ERP có thể chạy đúng kỹ thuật nhưng vẫn tạo duplicate, sai mapping, báo cáo lệch và nhiều thao tác đối soát.
Master data governance khác Data Migration ERP. Migration tập trung vào việc chuyển dữ liệu trong một chương trình thay hệ thống; governance quyết định cách dữ liệu được tạo, thay đổi, duyệt, phân phối, theo dõi chất lượng và retire trong suốt vòng đời vận hành.
Master data trong ERP gồm những domain nào?
| Domain | Ví dụ | Process bị ảnh hưởng |
|---|---|---|
| Customer | Tên pháp nhân, tax code, địa chỉ, payment term | Sales, AR, shipping, reporting |
| Vendor | Thông tin NCC, bank, payment term, tax | Procurement, AP, payment |
| Item/Material | SKU, UoM, category, planning attributes | Sales, Inventory, Purchase, MRP |
| BOM/Routing | Cấu trúc sản phẩm, version, công đoạn | Planning, Production, Costing |
| Finance | Chart of accounts, cost center, profit center | Posting, controlling, reporting |
| Reference data | UoM, tax code, currency, location | Nhiều module cùng sử dụng |
Với manufacturing, BOM và item master là dependency trực tiếp của MRP và costing. Xem ERP cho doanh nghiệp sản xuất để hiểu tác động của master data tới kế hoạch và thực thi.
Master data governance cần trả lời 6 câu hỏi
- Ai có quyền yêu cầu tạo hoặc thay đổi record?
- Ai là data owner có quyền phê duyệt?
- Field nào bắt buộc và validation rule là gì?
- Làm sao phát hiện duplicate trước khi tạo mới?
- Record được phân phối sang hệ thống nào và theo contract nào?
- Khi nào record bị khóa, retire hoặc archive?
Nếu câu trả lời chỉ là “team IT quản lý”, ownership thường chưa đủ rõ. IT có thể quản trị platform và workflow, nhưng quyết định một vendor có hợp lệ, một SKU nên retire hay một cost center được dùng ở đâu cần business owner phù hợp.
Bước 1: Xác định owner theo data domain
| Domain | Data owner có thể là | Data steward có thể làm |
|---|---|---|
| Customer | Sales Ops/Finance | Kiểm tra duplicate, field bắt buộc |
| Vendor | Procurement/Finance | Kiểm tra hồ sơ và thay đổi bank/payment |
| Item | Product/Supply Chain | Chuẩn hóa UoM/category/planning field |
| BOM | Engineering/Manufacturing | Version/effectivity/change control |
| Finance structure | Finance/Controlling | Kiểm tra mapping và trạng thái sử dụng |
Owner chịu trách nhiệm về rule và quyết định; steward thực hiện hoặc kiểm soát quy trình hằng ngày. Hai vai trò có thể nằm ở cùng một người trong doanh nghiệp nhỏ nhưng trách nhiệm vẫn cần tách rõ.
Bước 2: Thiết kế create/change workflow
Một workflow master data nên có requester, validation, duplicate check, approval, activation và audit trail. Với field nhạy cảm như bank account hoặc payment term, có thể cần approval khác với thay đổi mô tả thông thường.
- Request reason và effective date.
- Field thay đổi trước/sau.
- Validation rule tự động.
- Approval theo domain/field.
- Activation và distribution.
- Audit log: ai yêu cầu, ai duyệt, khi nào.
Bước 3: Duplicate prevention trước duplicate cleanup
Chỉ chạy deduplication định kỳ sẽ không giải quyết nguyên nhân nếu quy trình vẫn cho phép người dùng tạo record tùy ý. Duplicate prevention nên dùng business key, search-before-create và rule matching phù hợp với từng domain.
Ví dụ customer có thể cần kiểm tra tax code, legal name và địa chỉ; item có thể cần manufacturer part number, specification hoặc internal classification. Không nên dùng một rule similarity duy nhất cho mọi loại master.
Bước 4: Chuẩn hóa field và data dictionary
Data dictionary mô tả field có nghĩa gì, format nào hợp lệ, ai sở hữu, source of truth và downstream system nào dùng. Điều này đặc biệt quan trọng khi cùng một khái niệm có tên khác nhau giữa ERP, CRM, WMS hoặc BI.
| Field | Definition | Rule | Owner |
|---|---|---|---|
| Customer Type | Phân nhóm mô hình khách hàng | Chọn từ danh mục chuẩn | Sales Ops |
| Base UoM | Đơn vị tồn kho chuẩn của item | Không đổi sau giao dịch nếu không có migration plan | Supply Chain |
| Payment Term | Điều kiện thanh toán mặc định | Chỉ dùng code đã duyệt | Finance |
Bước 5: Quản trị lifecycle — active không phải mãi mãi active
Master data cần trạng thái lifecycle: requested, active, blocked/inactive, retired và archived tùy domain. Retire record không nên đồng nghĩa xóa lịch sử; mục tiêu là ngăn phát sinh giao dịch mới trong khi vẫn bảo toàn reference của giao dịch cũ.
- Không phát sinh giao dịch trong khoảng thời gian do business định nghĩa.
- Vendor/customer không còn quan hệ hoạt động.
- SKU đã end-of-life.
- BOM/version đã hết hiệu lực.
- Cost center hoặc structure đã thay đổi tổ chức.
Bước 6: Phân phối master data sang hệ thống khác
Khi master data được tạo trong một hệ thống và dùng ở nhiều hệ thống khác, governance phải đi cùng integration. Cần xác định source of record, field ownership, direction, latency, retry và reconciliation. Xem tích hợp ERP để thiết kế lớp phân phối này.
Không phải mọi field đều phải sync hai chiều. Field tài chính có thể do ERP sở hữu trong khi CRM chỉ đọc; field sales segmentation có thể do CRM sở hữu và ERP chỉ nhận bản cần thiết.
Đo chất lượng Master Data ERP bằng gì?
Không có một “data quality score” chuẩn cho mọi doanh nghiệp. Hãy đo theo rule của từng domain và tác động tới process.
- Duplicate rate theo business key.
- Completeness của field bắt buộc.
- Invalid value ngoài taxonomy chuẩn.
- Orphan/reference mismatch.
- Thời gian xử lý create/change request.
- Số giao dịch lỗi do master data.
- Số record active nhưng không còn sử dụng.
- Reconciliation mismatch giữa các hệ thống.
Master data và Data Migration liên kết thế nào?
Migration là cơ hội sửa dữ liệu trước go-live, nhưng nếu governance sau go-live không thay đổi thì duplicate và inconsistency sẽ quay lại. Vì vậy data migration nên bàn giao ít nhất data dictionary, ownership, cleansing rule và unresolved issue cho operating model master data.
Checklist exit gate cho Master Data ERP
- Domain và owner đã được phê duyệt.
- Data dictionary cho field trọng yếu đã có.
- Create/change workflow và approval path đã rõ.
- Duplicate prevention rule đã test.
- Lifecycle/retire rule đã xác định.
- Integration ownership theo field/domain đã rõ.
- Data quality metric có baseline.
- Migration handover sang governance đã hoàn thành.
- Audit trail và access control phù hợp với mức nhạy cảm của data domain.
Kết luận
Master Data ERP tạo nền cho mọi module: nếu customer, vendor, item, BOM và finance structure không có owner, workflow và quality rule, các process phía trên sẽ phải bù bằng đối soát thủ công. Hãy xây governance trước go-live và đưa ownership, data quality, migration và integration requirements vào RFP ERP ngay từ giai đoạn lựa chọn.
Đi tiếp theo data lifecycle ERP
Master data nên được đọc cùng Bảo mật ERP để khóa quyền create/change và audit, KPI ERP sau go-live để đo data-quality impact, và Change Management ERP khi ownership hoặc cách nhập liệu thay đổi theo vai trò. Với manufacturing, dùng thêm ERP vs MRP vs MES để xác định nơi BOM/item master được sử dụng và đồng bộ.
Khi master data thuộc chương trình Odoo
Bài này tiếp tục sở hữu intent Master Data ERP vendor-neutral. Khi doanh nghiệp cần chuẩn hóa customer, vendor, item, BOM và reference data để migrate hoặc nâng cấp Odoo, xem dịch vụ nâng cấp và migration Odoo để đưa data cleansing, mapping và reconciliation vào đúng workstream.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.
