11 Data Modeling And Master Data

Trường kiểm soát	Giá trị
Artifact ID	11_DATA_MODELING_AND_MASTER_DATA
Tên tệp được kiểm soát	/02-handbook/11-data-modeling-and-master-data.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Handbook chapter; học liệu có kiểm soát
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp
Nguồn canonical liên quan	CANONICAL_DATA_DICTIONARY; TRACEABILITY_ID_REGISTRY; CANONICAL_BUSINESS_RULES
Baseline	Chưa có baseline reference tại v0.9.0
Approval	Chưa có approval reference. IN_REVIEW không phải APPROVED, BASELINED, production-ready, compliant, hoặc user-approved.
Ranh giới thẩm quyền	Nội dung không xác nhận cấu hình ERP thực, quy tắc vận hành thực, diễn giải pháp lý, kế toán, thuế, bảo mật, hoặc quyền triển khai production.

1. Concept l? g??

Core

Data modeling là mô hình hóa dữ liệu: BA biến thông tin nghiệp vụ thành cấu trúc rõ để người, quy trình và hệ thống cùng hiểu một nghĩa. Từ điểm xuất phát tuyệt đối, doanh nghiệp không xử lý “dữ liệu” như một khối chữ số hoặc bảng tính. Doanh nghiệp cần biết vật gì được quản lý, vật đó có thuộc tính gì, vật nào liên kết vật nào, và giá trị nào được phép tồn tại. Data model trả lời các câu này trước khi đội kỹ thuật tạo bảng DB, API, màn hình hoặc báo cáo.

Master data là dữ liệu chủ dùng lặp lại, tương đối ổn định, làm chuẩn tham chiếu cho giao dịch. Ví dụ, mã hàng, tên hàng, đơn vị tính và nhóm hàng là dữ liệu chủ. Một phiếu bán 240 chai nước ép dùng mã hàng đã có sẵn là dữ liệu giao dịch, không phải master data. Phân biệt này quan trọng vì một lỗi trong dữ liệu chủ có thể lan sang nhiều đơn hàng, tồn kho, giá vốn và báo cáo; bằng chứng là cùng một giá trị chủ được nhiều giao dịch tham chiếu.

Source mermaid — có thể chỉnh sửa

erDiagram
    PRODUCT_MASTER ||--o{ SALES_ORDER_LINE : "được tham chiếu bởi"
    PRODUCT_MASTER {
        string product_code PK
        string product_name
        string base_uom
    }
    SALES_ORDER_LINE {
        string sales_order_id PK
        int line_number PK
        string product_code FK
        decimal ordered_quantity
    }

Mô hình trên là logical data model: mô hình dữ liệu logic. Nó mô tả ý nghĩa nghiệp vụ, chưa quyết định DB nào, tên bảng vật lý nào, kiểu cột nào, API nào, hay ERP nào. PRODUCT_MASTER đại diện tập dữ liệu chủ Sản phẩm. SALES_ORDER_LINE đại diện dòng đơn bán. Quan hệ “được tham chiếu bởi” nêu quy tắc nghĩa: mỗi dòng bán phải chỉ tới một sản phẩm đã xác định; nó chưa tự tạo ràng buộc kỹ thuật.

Mục tiêu chapter là giúp BA xác định cấu trúc và nghĩa dữ liệu đủ rõ để giảm mơ hồ liên phòng ban. Chapter không thay thế thiết kế vật lý DB của Architect hoặc developer; không tự quyết mã hàng, chính sách giá, quyền sửa dữ liệu, quy tắc kế toán, hay nghĩa vụ pháp lý. Các quyết định đó cần artifact canonical và role có thẩm quyền xác nhận.

Nova Foods là case mô phỏng. Dữ liệu ví dụ trong chapter, nếu có, là dữ liệu tổng hợp. Không suy diễn rằng Nova Foods có ERP thật, sản phẩm thật, cấu hình thật, hoặc quy tắc vận hành đã được phê duyệt.

Core

Trong mô hình hóa dữ liệu, BA dùng từ chung để mô tả ai làm gì với dữ liệu nào và kết quả dữ liệu đổi ra sao. Cách nói này tách ý nghĩa nghiệp vụ khỏi màn hình, mã nguồn và cấu hình ERP. Bằng chứng: cùng một nghiệp vụ có thể chạy trên web, mobile hoặc API, nhưng người thực hiện, hành động, dữ liệu và kết quả vẫn phải nhất quán.

Thuật ngữ	Nghĩa tiếng Việt	Vai trò trong phân tích
Actor	Tác nhân: người, phòng ban, hệ thống hoặc dịch vụ thực hiện hay khởi phát hành động.	Xác định trách nhiệm và quyền truy cập. Actor không luôn là người dùng; ERP có thể là actor khi chạy tác vụ tự động.
Action	Hành động: thao tác làm thay đổi, tạo, đọc hoặc kiểm tra dữ liệu.	Nêu động từ nghiệp vụ rõ: tạo, cập nhật, khóa, phê duyệt, tra cứu. Không dùng từ mơ hồ như “xử lý”.
Object	Đối tượng: dữ liệu hoặc thực thể bị tác động.	Xác định danh từ nghiệp vụ, như Sản phẩm, Nhà cung cấp, Đơn vị tính, Kho.
Outcome	Kết quả: trạng thái, dữ liệu hoặc quyết định sau hành động.	Làm rõ điều phải đúng sau xử lý, như bản ghi được tạo, mã không trùng, trạng thái đổi.
Data model	Mô hình dữ liệu: biểu diễn có cấu trúc về dữ liệu, thuộc tính, quan hệ và quy tắc dữ liệu.	Trả lời hệ thống cần lưu gì, các dữ liệu liên hệ thế nào, dữ liệu nào phải hợp lệ.
Master data	Dữ liệu chủ: dữ liệu tham chiếu dùng lặp lại trong nhiều giao dịch.	Ví dụ: Sản phẩm, Khách hàng, Nhà cung cấp, Kho. Dữ liệu này không phải từng đơn bán hàng hay từng phiếu nhập.
Transaction data	Dữ liệu giao dịch: dữ liệu ghi nhận một sự kiện nghiệp vụ cụ thể.	Ví dụ: đơn mua hàng, phiếu xuất kho, hóa đơn. Giao dịch thường tham chiếu đến dữ liệu chủ.
Entity	Thực thể: một loại đối tượng nghiệp vụ cần quản lý riêng.	“Sản phẩm” là entity nếu Nova Foods cần lưu và tái dùng thông tin sản phẩm.
Attribute	Thuộc tính: một mẩu thông tin mô tả entity.	Entity Sản phẩm có thể có thuộc tính ProductCode, ProductName, BaseUoM.
Identifier / ID	Định danh: giá trị phân biệt duy nhất một bản ghi trong phạm vi đã định.	ProductCode chỉ là ID khi quy tắc xác nhận không trùng và phạm vi duy nhất được nêu rõ.
Relationship	Quan hệ: liên kết có ý nghĩa giữa các entity.	Sản phẩm có thể dùng một Đơn vị tính cơ sở; quan hệ này phải được mô tả thay vì lặp tên đơn vị tính tự do.
Business rule	Quy tắc nghiệp vụ: điều kiện nghiệp vụ xác định dữ liệu hoặc hành vi hợp lệ.	Ví dụ dạng cấu trúc: một mã sản phẩm không được trùng trong phạm vi danh mục đã xác định. Đây chưa là quy tắc canonical của Nova Foods.
CRUD	Create, Read, Update, Delete: tạo, đọc, cập nhật, xóa.	Dùng để kiểm tra actor nào được làm hành động nào trên object nào. “Delete” cần xét giữ vết và kiểm soát riêng.

Mẫu câu tối thiểu cho BA: [Actor] thực hiện [Action] trên [Object], kết quả [Outcome]. Ví dụ cấu trúc: “Nhân viên quản trị dữ liệu tạo Sản phẩm, kết quả hệ thống có một bản ghi Sản phẩm định danh được.” Câu này chưa xác lập quyền, quy tắc, cấu hình hay quyết định vận hành cho Nova Foods.

CANONICAL_DATA_DICTIONARY là artifact kế hoạch cho từ điển dữ liệu logic canonical. Trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07 không chứng minh dữ liệu đã baseline, đã phê duyệt hoặc dùng được cho production.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp, không mô tả ERP hay quyết định vận hành thực.

Mục	Nội dung
Facts	Nova Foods bán sản phẩm mô phỏng NF-MILK-01 tại Việt Nam. Ba nhân viên nhập lần lượt Sữa dinh dưỡng 180ml, Sua DD 180 ML, SUA180.
Current Behavior	ERP cho phép mỗi người tự gõ tên hàng. Cùng một sản phẩm có ba tên, nên báo cáo doanh thu theo sản phẩm tách thành ba dòng.
Underlying Need	Hệ thống cần một bản ghi chuẩn duy nhất cho sản phẩm dùng lặp lại ở bán hàng, mua hàng, kho và báo cáo.
Options	(1) Cho nhập tự do; (2) Chuẩn hóa tên bằng hướng dẫn thủ công; (3) Tạo master data sản phẩm có mã duy nhất và bắt buộc chọn từ danh mục.
Decision Criteria	Phải giảm trùng lặp, truy vết được cùng đối tượng qua nhiều giao dịch, không để từng giao dịch tự định nghĩa sản phẩm.
Decision	Dùng một bản ghi master data: ProductID=NF-MILK-01, ProductName=Sữa dinh dưỡng 180ml, UoM=Chai. Giao dịch chỉ lưu ProductID; tên hiển thị lấy từ master data.
Authority	Business Owner xác nhận ý nghĩa sản phẩm; Data Owner chịu trách nhiệm chất lượng bản ghi; BA ghi nhận nhu cầu và quy tắc dữ liệu. Đây không phải phê duyệt hay cấu hình production.
Artifact	Bản ghi logic dự kiến thuộc CANONICAL_DATA_DICTIONARY, tham chiếu bằng đúng Artifact ID CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Nếu NF-MILK-01 bị gán sai tên hoặc đơn vị tính, báo cáo, tồn kho và giao dịch liên quan cùng hiểu sai một đối tượng.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Nhân viên bán hàng] -->|chọn ProductID| B[Đơn bán hàng<br/>lưu ProductID]
    B -->|tham chiếu ProductID| C[Master data sản phẩm<br/>ProductID: NF-MILK-01<br/>ProductName: Sữa dinh dưỡng 180ml<br/>UoM: Chai]
    B -->|ProductID| D[Báo cáo doanh thu]
    C -->|tên chuẩn| D

Ranh giới khái niệm: Data modeling là mô tả có kiểm soát về đối tượng dữ liệu, thuộc tính, định danh và quan hệ để hệ thống cùng hiểu một sự vật. Master data là dữ liệu tham chiếu tương đối ổn định, dùng lại qua nhiều giao dịch, như sản phẩm, khách hàng hoặc nhà cung cấp. Trong ví dụ, NF-MILK-01 là master data; một dòng đơn bán hàng tham chiếu mã này là transaction data, tức dữ liệu phát sinh theo sự kiện.

Loại trừ: Ví dụ không xác định bảng vật lý, kiểu dữ liệu DB, API, quyền truy cập, giá bán, thuế, hạch toán, quy định an toàn thực phẩm, truy xuất nguồn gốc hay cấu hình ERP. Các nội dung đó cần artifact và thẩm quyền chuyên môn riêng; không được suy ra từ bản ghi mô phỏng này.

2. T?i sao concept n?y t?n t?i?

Core

Data modeling tồn tại để ngăn hệ thống lưu cùng một khái niệm theo nhiều cách khác nhau. Master data tồn tại để ngăn mỗi giao dịch tự tạo lại định nghĩa của sản phẩm, khách hàng, nhà cung cấp hoặc đơn vị tính. Nếu không có mô hình dữ liệu và nguồn master data được kiểm soát, ERP không có điểm tham chiếu chung; cùng mã, tên hoặc đơn vị có thể mang nghĩa khác giữa bán hàng, kho và kế toán.

Rủi ro đầu tiên là mơ hồ nghiệp vụ. Ví dụ, trường ProductID chỉ hữu ích khi mọi bên thống nhất nó nhận diện một sản phẩm nào, ai tạo mã, mã có được tái sử dụng không, và giao dịch phải tham chiếu mã nào. Không định nghĩa các điểm này, BA có thể ghi requirement “chọn sản phẩm” nhưng developer, QA và người dùng hiểu khác nhau. Requirement vẫn có chữ, nhưng thiếu nghĩa kiểm tra được.

Rủi ro thứ hai là làm lại. Khi mỗi màn hình tự lưu ProductName, UoM hoặc mô tả sản phẩm, thay đổi một sản phẩm buộc đội dự án dò và sửa nhiều nơi. Lỗi không chỉ nằm ở dữ liệu cũ; API, báo cáo, migration và test case cũng có thể đã dựa vào các bản sao khác nhau. Mô hình dữ liệu xác định một nguồn lưu và quan hệ tham chiếu trước khi thiết kế chi tiết, nên giảm phạm vi sửa dây chuyền.

Rủi ro thứ ba là lỗi tích hợp. Hai hệ thống chỉ trao đổi đúng khi cùng hiểu cấu trúc, định danh và ràng buộc dữ liệu. Nếu hệ thống bán hàng gửi tên tự do còn hệ thống kho cần ProductID, tích hợp phải đoán bản ghi tương ứng. Đoán sai có thể tạo giao dịch gắn nhầm sản phẩm. Data model biến việc “đoán theo tên” thành quy tắc tham chiếu rõ: giao dịch dùng định danh master data.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Đơn bán hàng] --> B{Đơn bán hàng tham chiếu sản phẩm bằng gì?}
    B -->|Tên tự do| C[Tích hợp đoán bản ghi sản phẩm]
    C --> D[Gắn nhầm sản phẩm]
    D --> E[Kho xử lý sai đối tượng]
    E --> F[Báo cáo và đối soát phải làm lại]
    B -->|ProductID chuẩn| G[Tham chiếu master data được kiểm soát]
    G --> H[Kho và báo cáo cùng tham chiếu ProductID]

Rủi ro thứ tư là mất quản trị dữ liệu. Không có Data Owner, quy tắc tạo-sửa-ngừng dùng và nhận diện nguồn canonical, ai cũng có thể sửa dữ liệu tham chiếu. Một thay đổi nhỏ ở master data có thể ảnh hưởng nhiều giao dịch sau đó. BA không tự quyết ý nghĩa nghiệp vụ; BA làm rõ đối tượng, thuộc tính, quan hệ, thẩm quyền và artifact cần kiểm soát.

Applied

Mục	Nội dung
Facts	Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp.
Current Behavior	Nhân viên có thể nhập tên sản phẩm theo cách riêng trong giao dịch.
Underlying Need	Cần một cách nhận diện sản phẩm dùng chung giữa giao dịch và báo cáo.
Options	Lưu tên tự do trong từng giao dịch; hoặc dùng ProductID tham chiếu master data.
Decision Criteria	Một nghĩa cho mỗi sản phẩm; giảm nhập trùng; truy vết được nguồn dữ liệu; thay đổi không gây sai lệch dây chuyền.
Decision	Chưa có quyết định vận hành Nova Foods. Handbook chỉ nêu nguyên tắc: xác định master data và quan hệ tham chiếu trước khi đặc tả giao dịch.
Authority	Business Owner xác nhận nghĩa nghiệp vụ; Data Owner chịu trách nhiệm dữ liệu; Architect xác nhận khả năng kỹ thuật; BA duy trì traceability.
Artifact	CANONICAL_DATA_DICTIONARY là artifact canonical dự kiến cho định nghĩa dữ liệu logic.
Consequence if Wrong	Cùng sản phẩm có thể xuất hiện dưới nhiều tên, làm giao dịch, báo cáo và tích hợp hiểu khác nhau.

Senior Lens

Không coi data model là sơ đồ kỹ thuật riêng của developer. Nó là hợp đồng nghĩa giữa nghiệp vụ, BA, developer, QA và đội tích hợp. Sơ đồ đẹp nhưng thiếu định danh, nguồn canonical, quan hệ và chủ sở hữu vẫn không ngăn lỗi. Ngược lại, mô hình nhỏ nhưng xác định rõ “đối tượng nào”, “thuộc tính nào”, “tham chiếu cái gì” và “ai chịu trách nhiệm” đã đủ tạo test basis, tức cơ sở để QA kiểm tra.

Không dùng dữ liệu master như bằng chứng phê duyệt. IN_REVIEW và v0.9.0 chỉ nói artifact đang được xem xét. Chúng không xác nhận cấu hình ERP, quyết định Nova Foods, baseline, compliance hay quyền dùng production.

Quick Reference

Vấn đề bị ngăn	Cơ chế data modeling và master data
Một khái niệm, nhiều cách hiểu	Định nghĩa đối tượng, thuộc tính, định danh và quan hệ
Nhập trùng, tên không nhất quán	Dùng bản ghi master data làm tham chiếu
Sửa một nơi, sai nhiều nơi	Xác định nguồn canonical thay vì sao chép dữ liệu
API và hệ thống tích hợp không khớp	Thống nhất ProductID và cấu trúc trao đổi
Không rõ ai chịu trách nhiệm dữ liệu	Gán Data Owner và thẩm quyền xác nhận phù hợp

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Không có mô hình dữ liệu chủ (master data) chung, cùng một nguyên liệu có thể được tạo dưới nhiều mã, nhiều tên và đơn vị tính khác nhau. Hệ quả quan sát được là báo cáo mua hàng, tồn kho và giá vốn không thể cộng gộp chắc chắn theo nguyên liệu; người dùng phải tự đối chiếu từng dòng trước khi quyết định.

Trạng thái	Dữ liệu tổng hợp minh họa	Hành vi quan sát được	Hệ quả nghiệp vụ
Trước khi quản trị master data	Đường trắng 50kg, DUONG-50, Sugar White 50 KG được nhập như ba bản ghi vật tư	Phiếu mua, nhận hàng và tồn kho tham chiếu ba mã khác nhau cho cùng cách gọi nghiệp vụ	Không xác định chắc chắn tổng tồn của “đường trắng”; kế hoạch mua có thể dựa trên số thiếu hoặc số thừa giả tạo
Trước khi quản trị master data	Một chứng từ dùng kg; chứng từ khác dùng bao	ERP không có quy tắc quy đổi được kiểm soát giữa bao và kg	Không thể so sánh số lượng trực tiếp; BA không thể viết acceptance criteria kiểm tra tồn khả dụng mà không làm rõ đơn vị
Sau khi lập mô hình logic và dữ liệu chủ	Một bản ghi vật tư canonical: ITEM-SUGAR-WHITE-50KG; tên chuẩn Đường trắng 50 kg; đơn vị tồn kg	Giao dịch phải tham chiếu ID canonical hoặc bị chặn/chuyển vào hàng đợi xử lý dữ liệu	Báo cáo có một khóa tổng hợp xác định; truy vết từ chứng từ về vật tư rõ hơn
Sau khi quản trị quy đổi đơn vị	bao được định nghĩa là đơn vị giao dịch, có quy đổi được quản trị về kg cho đúng vật tư	Hệ thống chỉ chuyển đổi khi có bản ghi quy đổi hợp lệ	Tồn kho và nhu cầu mua được biểu diễn trên cùng đơn vị cơ sở; sai quy đổi trở thành lỗi dữ liệu có thể phát hiện

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Giao dịch vật tư] --> B{Mã vật tư canonical?}
    B -- Không --> C[Chặn giao dịch hoặc chuyển vào hàng đợi xử lý dữ liệu]
    B -- Có --> D{Đơn vị cơ sở hoặc có quy đổi hợp lệ cho đúng vật tư?}
    D -- Không --> C
    D -- Có --> E[Cập nhật giao dịch tồn kho]
    E --> F[Báo cáo theo ITEM-SUGAR-WHITE-50KG]

Đối chiếu trước/sau không khẳng định ERP Nova Foods đang vận hành theo quy tắc này. Nó cho thấy lý do concept tồn tại: mô hình dữ liệu xác định thực thể, khóa và quan hệ; master data cung cấp bản ghi tham chiếu ổn định cho giao dịch. Khi hai phần này thiếu, cùng một sự vật có nhiều cách biểu diễn. Khi chúng có kiểm soát, sai khác được đưa thành ngoại lệ dữ liệu thay vì để người dùng tự suy đoán trong báo cáo.

Core

Phân loại phát biểu giữ mô hình dữ liệu Nova Foods Trading & Manufacturing mô phỏng không biến ý kiến thành quy tắc ERP. Fact đã xác minh có bằng chứng kiểm tra được trong artifact hoặc nguồn chính thức. Stakeholder input là thông tin do người liên quan cung cấp, chưa tự thành sự thật. Project assumption là giả định tạm để tiếp tục phân tích, phải nêu điều kiện vô hiệu. Decision là lựa chọn được ghi nhận cùng tiêu chí và thẩm quyền; không suy ra approval. Verification-required claim là phát biểu cần kiểm tra bởi vai trò có thẩm quyền trước khi dùng làm yêu cầu, nhất là pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Phát biểu về dữ liệu] --> B{Bằng chứng thuộc artifact hoặc nguồn chính thức<br/>và đã được kiểm tra?}

    B -- Có --> C[Fact đã xác minh]
    B -- Không --> D{Nguồn là stakeholder?}
    D -- Có --> E[Stakeholder input]
    D -- Không --> F{Cần giả định để tiếp tục phân tích?}
    F -- Có --> G[Project assumption<br/>Ghi điều kiện làm giả định mất hiệu lực]
    F -- Không --> H[Verification-required claim]

    C --> I{Cần vai trò có thẩm quyền xác minh?<br/>Nhất là pháp lý, kế toán, thuế,<br/>an toàn thực phẩm, bảo mật}
    E --> I
    G --> I
    H --> J[Vai trò có thẩm quyền kiểm tra claim]
    I -- Có --> J
    I -- Không --> K[Đánh giá bằng chứng<br/>theo mục đích dùng làm yêu cầu]
    J --> K

    K --> L{Bằng chứng đủ để dùng làm yêu cầu?}
    L -- Không --> M[Giữ nguyên trạng thái hiện có<br/>Không dùng làm yêu cầu đủ căn cứ]
    L -- Có --> N{Có lựa chọn cần ghi nhận?}

    N -- Không --> O[Không tạo decision]
    N -- Có --> P[Decision được ghi nhận<br/>Kèm tiêu chí và thẩm quyền<br/>Không đồng nghĩa approval]

Applied

Trường	Nội dung case Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	CANONICAL_DATA_DICTIONARY là artifact canonical theo kế hoạch; status corpus là IN_REVIEW, version v0.9.0, ngày 2026-08-07. Không có baseline reference hay approval reference.
Current Behavior	Một người nói “mã khách hàng phải duy nhất” và nhóm ghi thẳng thành ràng buộc dữ liệu. Câu nói không có nguồn, phạm vi, hay chủ thể xác nhận.
Underlying Need	Phân biệt dữ liệu master customer cần định danh duy nhất với khả năng một khách hàng có nhiều địa chỉ, nhiều chi nhánh, hoặc mã từ hệ thống cũ.
Options	(1) Ghi câu nói là fact. (2) Ghi stakeholder input và kiểm tra. (3) Dùng assumption tạm, gắn điều kiện hết hiệu lực.
Decision Criteria	Có bằng chứng artifact; phạm vi định danh rõ; không vượt thẩm quyền Business Owner, Architect, Accounting Owner hoặc Legal Owner; không gọi IN_REVIEW là approved.
Decision	Ghi “mã khách hàng phải duy nhất” là stakeholder input cho đến khi xác định rõ trường nào là mã canonical, phạm vi uniqueness và authority xác nhận.
Authority	Business Owner xác nhận ý nghĩa nghiệp vụ; Architect xác nhận cơ chế định danh và ràng buộc kỹ thuật. Nếu liên quan hồ sơ cá nhân, Legal/Privacy Owner phải xác minh.
Artifact	Ghi phân loại, nguồn, ngày 2026-08-07, trạng thái xác minh và liên kết tới /01-curriculum/CANONICAL_DATA_DICTIONARY.md; không tạo rule canonical mới.
Consequence if Wrong	Gắn nhầm thành fact có thể tạo unique constraint sai, chặn nhập khách hàng hợp lệ hoặc buộc đội dự án sửa migration, API và báo cáo.

Senior Lens

Cầu nối suy luận phải hiện rõ: nguồn nói gì, nguồn thuộc loại nào, phần nào còn chưa biết, ai có quyền xác nhận. Ví dụ, CHAPTER_MANIFEST xác nhận corpus là mô phỏng giáo dục và IN_REVIEW; vì vậy câu “Nova Foods đã áp dụng quy tắc này” không phải fact. Nó là verification-required claim, vì artifact không chứng minh vận hành thực tế.

Không dùng nguồn pháp lý làm rule dữ liệu trực tiếp nếu chưa kiểm tra văn bản hiện hành và owner phù hợp. Seed nguồn xác nhận Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 có hiệu lực từ 2026-01-01, nhưng yêu cầu hệ thống suy ra từ luật vẫn cần Legal Owner xác minh. Đây là verification-required claim, không phải decision kỹ thuật.

Quick Reference

Loại	Cách viết đúng	Không được viết
Fact đã xác minh	“CANONICAL_DATA_DICTIONARY là artifact canonical theo kế hoạch.”	“Từ điển dữ liệu đã được phê duyệt.”
Stakeholder input	“Kho vận nêu rằng mỗi kho cần một mã.”	“Mỗi kho bắt buộc có một mã.”
Project assumption	“Giả định tạm: một kho có một mã; kiểm tra khi có danh sách kho nguồn.”	“Quy tắc kho là một-một.”
Decision	“Chọn giữ phát biểu ở trạng thái stakeholder input, chờ Business Owner và Architect xác nhận.”	“Quy tắc đã được chấp thuận.”
Verification-required claim	“Cần Legal Owner xác minh yêu cầu lưu dữ liệu cá nhân trước khi thiết kế trường.”	“Luật bắt buộc trường này.”

3. V? tr? trong Lifecycle

Core

Data modeling (mô hình dữ liệu) xác định thực thể, thuộc tính, định danh, quan hệ và quy tắc dữ liệu. Master data (dữ liệu chủ) là dữ liệu dùng lặp lại giữa giao dịch, như khách hàng, nhà cung cấp, sản phẩm, kho. Lifecycle đặt mô hình đúng thời điểm: phát hiện nhu cầu trước, làm rõ nghĩa trước, xây dựng sau, kiểm thử theo nghĩa đã chốt, rồi vận hành có kiểm soát.

Giai đoạn	Entry gate: điều kiện vào	Hoạt động dữ liệu	Exit gate: điều kiện ra
Discovery	Có vấn đề nghiệp vụ mô tả được và phạm vi mô phỏng Nova Foods được nêu	Nhận diện dữ liệu nào là chủ, dữ liệu nào là giao dịch, nguồn tạo và người dùng	Danh sách thực thể ứng viên, câu hỏi mở, fact, assumption và verification-required claim được tách
Analysis	Có danh sách thực thể ứng viên và bằng chứng nguồn	Chuẩn hóa tên, định nghĩa, khóa logic, quan hệ, miền giá trị, ownership cần xác minh	Bản nháp tham chiếu CANONICAL_DATA_DICTIONARY đủ truy vết; không có assumption bị viết thành rule
Delivery	Có đặc tả logic đủ cho đội kỹ thuật diễn giải	Chuyển mô hình logic thành schema, API contract, migration hoặc cấu hình ERP theo quyết định kỹ thuật	Thiết kế kỹ thuật truy ngược được về định nghĩa dữ liệu; điểm chưa xác minh còn nhãn
Testing	Có test basis: định nghĩa trường, rule, quan hệ, acceptance criteria	Kiểm tra tạo, sửa, tra cứu, trùng lặp, dữ liệu thiếu, quan hệ sai và phân quyền liên quan	Kết quả test ghi rõ pass, fail hoặc blocked; defect truy về requirement hoặc thiết kế
Release	Test evidence sẵn có và thay đổi dữ liệu được đóng gói	Kiểm tra migration, dữ liệu khởi tạo, rollback và ảnh hưởng tích hợp	Gói phát hành có bằng chứng kỹ thuật; không suy diễn thành approval hay production authorization
Operations	Phiên bản đã được đưa vào môi trường vận hành theo quyết định có thẩm quyền	Theo dõi chất lượng dữ liệu, lỗi trùng, giá trị không hợp lệ, thay đổi danh mục	Vấn đề vận hành tạo đầu vào truy vết cho Discovery hoặc Analysis kế tiếp

Source mermaid — có thể chỉnh sửa

flowchart TB
    D[Discovery<br/>Nhận diện thực thể và câu hỏi]
    A[Analysis<br/>Định nghĩa dữ liệu logic]
    DE[Delivery<br/>Thiết kế kỹ thuật]
    T[Testing<br/>Kiểm tra theo test basis]
    TR{Kết quả test}
    DF{Loại defect}
    R[Release<br/>Kiểm tra migration, dữ liệu khởi tạo,<br/>rollback và ảnh hưởng tích hợp]
    RC{Kiểm tra Release đạt?}
    G{Có quyết định có thẩm quyền<br/>đưa vào vận hành?}
    O[Operations<br/>Theo dõi chất lượng dữ liệu]

    D -->|Danh sách ứng viên có bằng chứng| A
    A -->|Bản nháp truy vết; assumption không thành rule;<br/>điểm chưa xác minh giữ nhãn| DE
    DE -->|Schema hoặc contract truy ngược được| T

    T --> TR
    TR -->|Pass; kết quả truy về requirement hoặc thiết kế| R
    TR -->|Fail; defect truy về nguồn| DF
    TR -->|Blocked; ghi rõ trạng thái| T

    DF -->|Requirement hoặc định nghĩa dữ liệu| A
    DF -->|Schema, API, migration hoặc thiết kế| DE

    R --> RC
    RC -->|Đạt; gói phát hành có bằng chứng kỹ thuật| G
    RC -->|Fail; cần sửa kỹ thuật| DE
    RC -->|Blocked; giữ tại Release| R

    G -->|Có| O
    G -->|Không; chưa được phép vào vận hành| R

    O -->|Issue hoặc nhu cầu thay đổi có bằng chứng| D

Sơ đồ là flowchart Mermaid, không phải BPMN. Lý do: nó mô tả thứ tự gate ở mức học liệu; không tuyên bố ký pháp BPMN 2.0.2.

Applied

Nova Foods là case study mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp.

Mục	Nội dung
Facts	CANONICAL_DATA_DICTIONARY được định nghĩa là artifact canonical cho từ điển dữ liệu logic trong corpus. Status corpus là IN_REVIEW, version v0.9.0, ngày 2026-08-07.
Current Behavior	Nhóm mô phỏng nhận yêu cầu “quản lý sản phẩm theo mã” nhưng chưa biết mã sản phẩm do đâu cấp, có được tái sử dụng không, hay mỗi biến thể đóng gói có mã riêng không.
Underlying Need	Cần tránh xây schema trước khi biết nghĩa của “sản phẩm”. Nếu “sản phẩm” có thể là hàng bán, nguyên liệu hoặc biến thể đóng gói, một bảng duy nhất chưa chắc phản ánh đúng nhu cầu.
Options	1. Tạo ngay bảng Product với unique constraint cho mã. 2. Ghi “sản phẩm” là thực thể ứng viên, giữ các câu hỏi về mã và biến thể trong Analysis.
Decision Criteria	Chỉ chọn phương án đủ bằng chứng, không biến stakeholder input thành rule, và còn truy vết được về artifact canonical.
Decision	Chọn phương án 2. Discovery chỉ cho phép nhận diện thực thể ứng viên và khoảng trống thông tin. Unique constraint chỉ xem xét sau khi Analysis có định nghĩa và bằng chứng phù hợp.
Authority	Đây là quyết định phạm vi học liệu, không xác nhận rule vận hành Nova Foods. Quy tắc mã, thiết kế constraint và cấu hình ERP cần owner có thẩm quyền xác nhận tại giai đoạn phù hợp.
Artifact	Ghi thực thể ứng viên và câu hỏi vào đầu vào của CANONICAL_DATA_DICTIONARY; giữ IN_REVIEW, v0.9.0; không tạo ID mới.
Consequence if Wrong	Vào Delivery quá sớm có thể tạo constraint sai. Testing sẽ phát hiện dữ liệu hợp lệ bị chặn, hoặc Operations phát sinh mã trùng và phải sửa migration, API, báo cáo.

Senior Lens

Gate không phải thủ tục giấy tờ. Gate là điều kiện giảm rủi ro suy diễn. Discovery kết thúc khi biết điều gì chưa biết; Analysis kết thúc khi nghĩa dữ liệu đủ rõ để thiết kế; Delivery kết thúc khi kỹ thuật còn truy ngược được; Testing kết thúc khi có evidence; Release và Operations chỉ dùng evidence đó, không tự tạo nghĩa mới cho dữ liệu.

Cầu nối suy luận: CANONICAL_DATA_DICTIONARY được mô tả là logical data dictionary plan, không phải schema production. Vì vậy Analysis có thể ghi định nghĩa logic và trạng thái xác minh, nhưng không được tuyên bố database physical design đã đúng hay được phê duyệt.

Quick Reference

Gate	Câu hỏi kiểm tra nhanh	Dừng khi
Discovery vào Analysis	Thực thể ứng viên, nguồn và câu hỏi mở đã tách chưa?	“Sản phẩm”, “khách hàng” hoặc “kho” chưa có nghĩa tối thiểu
Analysis vào Delivery	Mỗi trường quan trọng có định nghĩa, nguồn và trạng thái xác minh chưa?	Assumption đang bị dùng như rule
Delivery vào Testing	Test có truy về định nghĩa dữ liệu và thiết kế không?	Không biết giá trị nào hợp lệ hoặc không hợp lệ
Testing vào Release	Có kết quả test ghi nhận cho thay đổi dữ liệu không?	Defect dữ liệu chưa được phân loại hoặc còn blocked
Operations về Discovery	Issue vận hành có bằng chứng đủ để mở vòng đời mới không?	Chỉ có ý kiến, chưa có dữ liệu hoặc mô tả tái lập được

Core

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu chủ (master data) là dữ liệu dùng lặp lại để giao dịch ERP hiểu cùng một đối tượng, ví dụ mã hàng, khách hàng, nhà cung cấp, kho hoặc đơn vị tính. Handoff là bàn giao có kiểm soát: bên trước giao artifact, bằng chứng và vấn đề mở; bên sau chỉ nhận khi đủ điều kiện thuộc thẩm quyền mình. Dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; chưa có baseline hay approval.

Điểm giao	Upstream owner	Artifact bàn giao	Downstream owner	Quyền quyết định	Escalation khi
Nhu cầu dữ liệu	Business Owner	Mục tiêu nghiệp vụ, thuật ngữ, phạm vi đối tượng	BA	Xác nhận nhu cầu nghiệp vụ mô phỏng	Thuật ngữ giữa phòng ban mâu thuẫn
Mô hình logic	BA	Thực thể, thuộc tính, quan hệ, định nghĩa	Data Owner, Architect	BA làm rõ và truy vết; không tự chốt nghiệp vụ hay kiến trúc	Một thuộc tính có nhiều nguồn chân lý
Quy tắc dữ liệu	Data Owner, Business Owner	Quy tắc sở hữu, giá trị hợp lệ, vòng đời dữ liệu	BA, Architect, QA	Data Owner quyết định quản trị dữ liệu; Business Owner quyết định ý nghĩa nghiệp vụ	Quy tắc ảnh hưởng kế toán, pháp lý, an toàn thực phẩm
Thiết kế kỹ thuật	Architect	Mapping logic-vật lý, tích hợp, phân quyền kỹ thuật	Delivery team	Architect quyết định thiết kế kỹ thuật trong phạm vi đã chấp thuận	Thiết kế đổi ý nghĩa dữ liệu hoặc tạo rủi ro bảo mật
Tiêu chí kiểm thử	BA, QA	Traceability, test basis, tiêu chí chấp nhận	QA	QA quyết định chiến lược và bằng chứng kiểm thử; BA không tuyên bố chất lượng đạt	Không thể kiểm thử vì định nghĩa dữ liệu thiếu
Vận hành dữ liệu	Data Steward, Operations Owner	Quy trình tạo, sửa, ngừng dùng, xử lý lỗi	Operations	Operations Owner quyết định vận hành; Data Steward duy trì chất lượng theo quyền được giao	Lỗi dữ liệu gây giao dịch sai hoặc mất truy vết

Source mermaid — có thể chỉnh sửa

flowchart TB
    STATE["Trạng thái chung của artifacts bàn giao<br/>IN_REVIEW · v0.9.0 · 2026-08-07<br/>Chưa có baseline hoặc approval"]

    BO["Business Owner"]
    BA["BA"]
    DO["Data Owner"]
    AR["Architect"]
    QA["QA"]
    DEV["Delivery team"]
    DS["Data Steward"]
    OO["Operations Owner"]
    OPS["Operations"]

    CONTROL["Handoff có kiểm soát<br/>Bàn giao artifact, bằng chứng và vấn đề mở<br/>Bên sau chỉ nhận khi đủ điều kiện thuộc thẩm quyền"]

    H1["H1 · Nhu cầu dữ liệu<br/>Mục tiêu nghiệp vụ, thuật ngữ, phạm vi đối tượng"]
    BO --> H1
    H1 -->|"Nhận khi đủ điều kiện thuộc thẩm quyền"| BA
    E1["Escalation<br/>Thuật ngữ giữa phòng ban mâu thuẫn"]
    H1 -.-> E1

    H2["H2 · Mô hình logic<br/>Thực thể, thuộc tính, quan hệ, định nghĩa"]
    BA --> H2
    H2 -->|"Nhận khi đủ điều kiện thuộc thẩm quyền"| DO
    H2 -->|"Nhận khi đủ điều kiện thuộc thẩm quyền"| AR
    H2_NOTE["Quyền của BA<br/>Làm rõ và truy vết<br/>Không tự chốt nghiệp vụ hoặc kiến trúc"]
    H2 -.-> H2_NOTE
    E2["Escalation<br/>Một thuộc tính có nhiều nguồn chân lý"]
    H2 -.-> E2

    H3["H3 · Quy tắc dữ liệu<br/>Sở hữu, giá trị hợp lệ, vòng đời dữ liệu"]
    DO --> H3
    BO --> H3
    H3 -->|"Nhận khi đủ điều kiện thuộc thẩm quyền"| BA
    H3 -->|"Nhận khi đủ điều kiện thuộc thẩm quyền"| AR
    H3_NOTE["Quyền quyết định<br/>Data Owner: quản trị dữ liệu<br/>Business Owner: ý nghĩa nghiệp vụ"]
    H3 -.-> H3_NOTE
    E3["Escalation<br/>Quy tắc ảnh hưởng kế toán, pháp lý hoặc an toàn thực phẩm"]
    H3 -.-> E3

    H4["H4 · Thiết kế kỹ thuật<br/>Mapping logic-vật lý, tích hợp, phân quyền kỹ thuật"]
    AR --> H4
    H4 -->|"Nhận trong phạm vi đã chấp thuận"| DEV
    H4_NOTE["Quyền của Architect<br/>Quyết định thiết kế kỹ thuật trong phạm vi đã chấp thuận"]
    H4 -.-> H4_NOTE
    E4["Escalation<br/>Thiết kế đổi ý nghĩa dữ liệu hoặc tạo rủi ro bảo mật"]
    H4 -.-> E4

    H5["H5 · Tiêu chí kiểm thử<br/>Traceability, test basis, tiêu chí chấp nhận"]
    BA --> H5
    QA --> H5
    H5 --> QA
    H5_NOTE["Quyền kiểm thử<br/>QA quyết định chiến lược và bằng chứng kiểm thử<br/>BA không tuyên bố chất lượng đạt"]
    H5 -.-> H5_NOTE
    E5["Escalation<br/>Không thể kiểm thử vì định nghĩa dữ liệu thiếu"]
    H5 -.-> E5

    H6["H6 · Vận hành dữ liệu<br/>Tạo, sửa, ngừng dùng, xử lý lỗi"]
    DS --> H6
    OO --> H6
    H6 -->|"Nhận khi đủ điều kiện thuộc thẩm quyền"| OPS
    H6_NOTE["Quyền vận hành<br/>Operations Owner quyết định vận hành<br/>Data Steward duy trì chất lượng theo quyền được giao"]
    H6 -.-> H6_NOTE
    E6["Escalation<br/>Lỗi dữ liệu gây giao dịch sai hoặc mất truy vết"]
    H6 -.-> E6

    ROUTE_NOTE["Tuyến escalation chưa được xác định trong dữ liệu nguồn"]
    E1 -.-> ROUTE_NOTE
    E2 -.-> ROUTE_NOTE
    E3 -.-> ROUTE_NOTE
    E4 -.-> ROUTE_NOTE
    E5 -.-> ROUTE_NOTE
    E6 -.-> ROUTE_NOTE

    CONTROL -.-> H1
    CONTROL -.-> H2
    CONTROL -.-> H3
    CONTROL -.-> H4
    CONTROL -.-> H5
    CONTROL -.-> H6

    STATE -.-> H1
    STATE -.-> H2
    STATE -.-> H3
    STATE -.-> H4
    STATE -.-> H5
    STATE -.-> H6

Applied

Facts: Nova Foods mô phỏng cần thêm thuộc tính StorageTemperatureBand cho dữ liệu chủ hàng hóa. Kho lạnh cần phân loại bảo quản; đây là nhu cầu nghiệp vụ, chưa phải cấu hình ERP thực tế.

Current Behavior: CANONICAL_DATA_DICTIONARY đang là kế hoạch IN_REVIEW; chưa có mục canonical xác nhận StorageTemperatureBand. Vì chưa có nguồn dữ liệu chủ đã được baseline, Delivery team không được tự thêm cột hoặc suy đoán giá trị.

Underlying Need: Cần xác định một chủ sở hữu ý nghĩa thuộc tính, tập giá trị hợp lệ và nơi tạo-sửa dữ liệu. Bằng chứng: cùng thuộc tính ảnh hưởng mua hàng, kho và chất lượng; nếu mỗi bộ phận tự nhập, một mã hàng có thể mang nhiều phân loại.

Options: (1) Procurement Owner sở hữu; phù hợp nếu thuộc tính chỉ phục vụ mua hàng. (2) Warehouse Owner sở hữu; phù hợp nếu chỉ điều phối kho. (3) Quality Owner là Data Owner, các bộ phận khác là consumer; phù hợp hơn vì nhiệt độ bảo quản là tiêu chí chất lượng xuyên quy trình.

Decision Criteria: Chọn owner theo người chịu trách nhiệm định nghĩa nghiệp vụ, kiểm soát thay đổi giá trị và xử lý ngoại lệ, không theo người nhập liệu nhiều nhất. Nếu lựa chọn chạm nghĩa vụ pháp lý hoặc an toàn thực phẩm, cần Verification required từ Legal Owner và domain owner.

Decision: Đề xuất Quality Owner làm Data Owner cho thuộc tính mô phỏng này; Warehouse Owner cung cấp yêu cầu sử dụng; Architect đánh giá mapping và quyền kỹ thuật. Đây là đề xuất học liệu, không phải quyết định vận hành Nova Foods.

Authority: BA ghi nhận lựa chọn, lý do và traceability; BA không tự phê chuẩn giá trị nhiệt độ, diễn giải Luật An toàn thực phẩm, hay quyết định cấu hình production. Quality Owner không tự phê chuẩn kiến trúc. Architect không tự đổi nghĩa nghiệp vụ.

Artifact: Ghi yêu cầu và vấn đề mở vào /01-curriculum/CANONICAL_DATA_DICTIONARY.md; liên kết quy tắc liên quan tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; dùng ID canonical đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Không tạo ID mới trong micro-batch này.

Consequence if Wrong: Nếu Warehouse Owner trở thành owner chỉ vì nhập liệu, Quality có thể mất quyền kiểm soát nghĩa dữ liệu. Kết quả là báo cáo tồn kho, quy tắc nhận hàng và kiểm thử dùng phân loại khác nhau; lỗi phát hiện muộn khi giao dịch đã phụ thuộc dữ liệu đó.

Senior Lens

Escalation không phải chuyển việc khó cho cấp trên. Escalation là dừng quyết định khi người đang xử lý thiếu thẩm quyền hoặc bằng chứng. BA phải escalation ngay tới Business Owner khi định nghĩa dữ liệu đổi mục tiêu nghiệp vụ; tới Architect khi một nguồn dữ liệu tạo tích hợp hoặc phân quyền mới; tới QA khi acceptance criteria không tạo được test basis; tới Legal Owner, Accounting Owner hoặc domain owner khi quy tắc có thể bị hiểu là nghĩa vụ pháp lý, kế toán, thuế, riêng tư hoặc an toàn thực phẩm.

Không dùng RACI để che mờ quyền quyết định. Với mỗi handoff, ghi rõ: ai soạn, ai kiểm tra, ai quyết định, ai tiêu thụ và điều gì kích hoạt escalation. “Được tham vấn” không có quyền chốt. “Được thông báo” không nhận trách nhiệm sửa artifact. Bằng chứng phải đi cùng handoff: nguồn, phiên bản, trạng thái, giả định và vấn đề mở.

Quick Reference

Quy tắc	Áp dụng
Owner dữ liệu khác người nhập dữ liệu	Chọn theo trách nhiệm định nghĩa và kiểm soát thay đổi
BA giữ traceability, không chiếm quyền quyết định	Ghi rõ giới hạn thẩm quyền trong artifact
Handoff thiếu artifact hoặc vấn đề mở	Không coi là bàn giao hoàn tất
Một thuộc tính có hai nguồn chân lý	Escalation tới Data Owner và Architect
Có tác động pháp lý, kế toán, riêng tư hoặc an toàn thực phẩm	Gắn Verification required; chuyển đúng owner chuyên môn
IN_REVIEW không phải approval	Không gọi nội dung đã baseline, đã phê duyệt hoặc sẵn sàng production

Bản đồ vòng đời dữ liệu chủ và mô hình dữ liệu

Core

Bản đồ vòng đời giúp thấy dữ liệu chủ (master data), như mã hàng, khách hàng, nhà cung cấp và đơn vị tính, được làm rõ dần trước khi ERP dùng dữ liệu đó. Mỗi cổng là điểm kiểm tra đầu ra đã đủ cho pha kế tiếp; cổng không xác nhận phê duyệt hay baseline tại trạng thái IN_REVIEW v0.9.0.

Source mermaid — có thể chỉnh sửa

flowchart TB
    D[Discovery<br/>Nhận diện đối tượng dữ liệu] --> G1{Gate G1<br/>Có phạm vi dữ liệu?}
    G1 -->|Có| A[Analysis<br/>Mô hình logic, thuộc tính,<br/>mã định danh]
    G1 -->|Chưa rõ| D

    A --> G2{Gate G2<br/>Đủ định nghĩa và quy tắc?}
    G2 -->|Có| V[Delivery<br/>Cấu hình, mapping,<br/>đặc tả giao diện]
    G2 -->|Thiếu| A

    V --> G3{Gate G3<br/>Có cấu trúc triển khai<br/>và dữ liệu mẫu?}
    G3 -->|Có| T[Testing<br/>Kiểm tra tạo, sửa,<br/>dùng dữ liệu]
    G3 -->|Thiếu| V

    T --> G4{Gate G4<br/>Đạt bằng chứng kiểm tra?}
    G4 -->|Có| R[Release<br/>Nạp dữ liệu,<br/>chuyển đổi]
    G4 -->|Không đạt| V

    R --> G5{Gate G5<br/>Có gói vận hành dữ liệu?}
    G5 -->|Có| O[Operations<br/>Quản trị, bảo trì,<br/>giám sát]
    G5 -->|Thiếu| R

    N[Giới hạn: các gate không xác nhận<br/>phê duyệt hoặc baseline tại IN_REVIEW v0.9.0]
    N --- G3

Applied

Trường	Nội dung mô phỏng Nova Foods
Facts	Nova Foods là case mô phỏng; dữ liệu tổng hợp. Nhóm bán hàng gọi cùng một sản phẩm là “Sữa Yến Mạch 1L”, kho gọi là “OY-1L”.
Current Behavior	Hai tên tự do được ghi ở hai bảng tính riêng.
Underlying Need	ERP cần một mã sản phẩm ổn định để đơn bán, tồn kho và báo cáo cùng tham chiếu một đối tượng.
Options	Giữ tên tự do; dùng mã sản phẩm canonical; tạo mã khác theo từng phòng ban.
Decision Criteria	Mã phải duy nhất, không đổi khi tên thương mại đổi, dùng được giữa bán hàng và kho.
Decision	Dùng một mã sản phẩm canonical trong mô hình logic; tên hiển thị là thuộc tính thay đổi được.
Authority	Business Owner xác nhận ý nghĩa nghiệp vụ; Data Owner xác nhận dữ liệu chủ; Architect xác nhận cách triển khai. BA ghi nhận và truy vết, không tự quyết định.
Artifact	Tham chiếu CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; ID và trạng thái giữ nguyên.
Consequence if Wrong	Một sản phẩm có nhiều mã làm sai tồn kho, doanh thu và dữ liệu tích hợp.

Senior Lens

Không dùng sơ đồ này để suy ra cấu hình ERP, quy tắc pháp lý, kế toán hay an toàn thực phẩm. Sơ đồ chỉ biểu diễn thứ tự kiểm soát logic: định nghĩa trước, triển khai sau, kiểm tra trước khi dùng vận hành. Khi một thuộc tính ảnh hưởng truy xuất nguồn gốc, dữ liệu cá nhân, hóa đơn hoặc hạch toán, cần gắn nhãn Verification required và chuyển đúng owner chuyên môn.

Quick Reference

Pha	Câu hỏi quét nhanh
Discovery	Đối tượng dữ liệu nào tồn tại và dùng để làm gì?
Analysis	Mã, thuộc tính, quan hệ và quy tắc nào mô tả đối tượng?
Delivery	Cấu trúc logic được chuyển thành cấu hình hoặc mapping nào?
Testing	Dữ liệu có tạo, sửa và được dùng đúng trong luồng mô phỏng không?
Release	Dữ liệu mẫu và gói chuyển đổi có đủ để đưa vào môi trường phát hành không?
Operations	Ai duy trì chất lượng, xử lý trùng lặp và theo dõi thay đổi?

4. Input c?n thi?t

Core

Trước khi mô hình hóa dữ liệu, BA cần tập hợp đầu vào để biết đối tượng nào tồn tại, bằng chứng nào xác nhận đối tượng đó, và mã nào giữ nguyên khi tên hoặc biểu mẫu thay đổi. Không cần biết ERP là gì: hãy xem ERP là hệ thống lưu và dùng chung dữ liệu cho bán hàng, mua hàng, kho, sản xuất và kế toán.

Dữ liệu chủ (master data) là dữ liệu mô tả đối tượng dùng lặp lại, như sản phẩm, khách hàng, nhà cung cấp và kho. Dữ liệu giao dịch là dữ liệu phát sinh theo sự kiện, như đơn bán hàng hoặc phiếu nhập kho. Muốn định nghĩa dữ liệu chủ đúng, BA phải bắt đầu từ bằng chứng nguồn, không bắt đầu từ màn hình phần mềm.

Định danh canonical là mã tham chiếu ổn định được dùng nhất quán giữa artifact. Ví dụ, CANONICAL_DATA_DICTIONARY luôn chỉ kế hoạch từ điển dữ liệu logic tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Tên hiển thị có thể đổi; canonical ID không tự đổi theo tên.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Bằng chứng nguồn] --> B[BA xác minh đối tượng dữ liệu]
    C[Tên hiển thị và mã kho] --> B
    H[Kiến thức nghiệp vụ] --> B
    B --> D{Có bằng chứng liên kết tên–mã?}
    D -->|Có| E[Đối tượng dữ liệu đã xác minh]
    D -->|Chưa có| F[Hai tham chiếu chưa xác minh]
    E --> M[Mô hình dữ liệu logic]
    F --> M
    F --> G[Giữ riêng, không gộp nhầm dữ liệu]
    I[Artifact kiểm soát và canonical ID] --> M
    M --> N[CANONICAL_DATA_DICTIONARY<br/>Kế hoạch từ điển dữ liệu logic<br/>/01-curriculum/CANONICAL_DATA_DICTIONARY.md]

Cầu nối suy luận: nếu người dùng nói “Bột mì đa dụng” nhưng kho dùng “BMD-01”, BA chưa được coi đây là hai sản phẩm. Cần bằng chứng liên kết tên và mã. Nếu không có liên kết, mô hình phải giữ chúng là hai tham chiếu chưa xác minh, tránh gộp nhầm dữ liệu.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; toàn bộ giá trị dưới đây là dữ liệu tổng hợp.

Mục	Nội dung
Facts	Tài liệu học liệu có CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES; tất cả ở IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	Người học có thể thấy cùng một khái niệm qua tên tệp, tiêu đề và mã artifact.
Underlying Need	Cần một mã bền vững để truy vết từ mô hình dữ liệu tới nguồn và artifact liên quan.
Options	Dùng tên hiển thị; dùng đường dẫn tệp; dùng canonical ID.
Decision Criteria	Tham chiếu không mơ hồ; không đổi khi đổi tiêu đề; liên kết được giữa nhiều artifact.
Decision	Dùng canonical ID làm khóa truy vết; giữ đường dẫn canonical làm vị trí nguồn.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì metadata. Business Owner, Data Owner, Architect và owner chuyên môn xác nhận nội dung thuộc thẩm quyền họ. Không có approval được ghi nhận.
Artifact	/01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Consequence if Wrong	BA có thể nối nhầm quy tắc, thuộc tính hoặc nguồn; thay đổi sau đó mất truy vết.

Nhóm đầu vào	Giá trị Nova Foods mô phỏng	Bằng chứng cần đọc	Canonical ID hoặc tham chiếu ổn định	Ý nghĩa cho mô hình
Bối cảnh tổ chức	Nova Foods Trading & Manufacturing	CHAPTER_MANIFEST	CHAPTER_MANIFEST	Giữ đúng tên case study, không suy ra đây là doanh nghiệp thật.
Từ điển dữ liệu logic	Kế hoạch định nghĩa thực thể, thuộc tính, quan hệ	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	CANONICAL_DATA_DICTIONARY	Nguồn chính để ghi nhận tên logic của dữ liệu.
Registry định danh	Kế hoạch quản lý ID truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	TRACEABILITY_ID_REGISTRY	Kiểm tra ID trước khi tạo tham chiếu mới.
Catalog quy tắc	Kế hoạch quản lý business rule	/01-curriculum/CANONICAL_BUSINESS_RULES.md	CANONICAL_BUSINESS_RULES	Tách quy tắc nghiệp vụ khỏi định nghĩa trường dữ liệu.
Kiến thức nghiệp vụ tối thiểu	Sản phẩm, khách hàng, nhà cung cấp, kho là các đối tượng có thể được nhận diện và dùng lặp lại	Mô tả case study và artifact curriculum	Không tự tạo mã đối tượng nghiệp vụ	Xác định ứng viên dữ liệu chủ trước khi vẽ quan hệ.
Bằng chứng pháp lý hoặc ngành	Bảo vệ dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm có thể ảnh hưởng dữ liệu	Verified primary-source seed	URL chính thức đã nêu trong source seed	Chỉ dùng làm bối cảnh; mọi yêu cầu cụ thể phải giữ nhãn Verification required.

Senior Lens

Không biến artifact quản trị thành bằng chứng nghiệp vụ. CANONICAL_DATA_DICTIONARY chứng minh nơi quản lý định nghĩa dữ liệu; nó không chứng minh mã sản phẩm, chính sách giá, cấu hình ERP hay quy tắc kế toán đã đúng cho vận hành.

Không tạo canonical ID mới chỉ vì gặp tên mới. Trước hết kiểm tra TRACEABILITY_ID_REGISTRY; nếu chưa có đăng ký phù hợp, ghi nhận khái niệm là ứng viên cần quản trị. Canonical ID là khóa truy vết của corpus, không phải mã tự động của ERP.

Quick Reference

Cần có trước khi mô hình hóa	Câu hỏi kiểm tra
Kiến thức nghiệp vụ tối thiểu	Đối tượng này là sản phẩm, bên giao dịch, địa điểm hay sự kiện?
Bằng chứng	Artifact hoặc nguồn nào cho thấy đối tượng tồn tại?
Nguồn artifact	Tệp canonical nằm ở đâu và có trạng thái gì?
Canonical ID	ID nào phải giữ nguyên khi tham chiếu?
Ranh giới	Nội dung nào chỉ là mô phỏng, giả định hoặc Verification required?

Core

Đầu vào chỉ được dùng khi BA biết nó đến từ đâu, ai chịu trách nhiệm, còn đủ mới hay không, và có thể dừng phân tích khi thiếu điều kiện tối thiểu. Phân loại nguồn là nhãn mô tả mức độ tin cậy và ranh giới sử dụng; không phải nhãn phê duyệt. Độ mới là thời điểm nguồn còn phản ánh trạng thái cần phân tích. Owner là vai trò giữ trách nhiệm xác nhận nội dung, không phải người tự động phê duyệt quyết định.

Kiểm tra chất lượng	Cách kiểm tra	Đạt khi	Không đạt khi
Nhận diện nguồn	Có artifact ID, đường dẫn canonical, phiên bản, trạng thái	Tham chiếu đúng ID và tệp kiểm soát	Chỉ có ảnh chụp, lời kể, tệp không rõ nguồn
Ranh giới nguồn	Đọc mục scope, authority, safe use boundary	Không suy diễn vượt thẩm quyền nguồn	Dùng tài liệu học liệu làm quy tắc vận hành
Tính nhất quán	So sánh ID, status, version giữa các artifact	IN_REVIEW, v0.9.0, ngày 2026-08-07 khớp	Một nguồn nói đã baseline, nguồn khác nói chưa
Độ mới	Kiểm tra ngày cập nhật và ngày truy cập	Phù hợp mốc phân tích 2026-08-07	Không rõ ngày hoặc dùng thông tin pháp lý cũ
Ownership	Xác định vai trò xác nhận nội dung	Có owner chuyên môn đúng lĩnh vực	BA tự xác nhận pháp lý, kế toán, bảo mật
Khả năng truy vết	Mỗi kết luận chỉ về nguồn cụ thể	Có evidence và reasoning bridge	Kết luận không chỉ ra bằng chứng

Phân loại dùng trong Nova Foods là mô phỏng giáo dục, dữ liệu tổng hợp: primary-source verified là nguồn chính thức đã có URL và ngày truy cập; controlled planning artifact là artifact corpus có metadata kiểm soát; project assumption là giả định học liệu, không phải fact vận hành; Verification required là điểm chưa đủ bằng chứng để quyết định.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Nguồn đầu vào] --> B{Có ID, đường dẫn canonical, version, status?}
    B -- Không --> S[Dừng phân tích — thiếu điều kiện tối thiểu]
    B -- Có --> C{ID, status, version khớp giữa các artifact?}
    C -- Không --> V[Verification required]
    C -- Có --> D{Đúng phân loại và ranh giới sử dụng?}
    D -- Không --> S
    D -- Có --> E{Có ngày cập nhật và ngày truy cập phù hợp mốc 2026-08-07?}
    E -- Không --> V
    E -- Có --> F{Có owner chuyên môn đúng lĩnh vực xác nhận nội dung?}
    F -- Không --> S
    F -- Có --> G[Evidence gắn nguồn cụ thể và reasoning bridge]
    V --> H[Không suy diễn thành rule hoặc quyết định]
    H --> S

Applied

Facts: Nova Foods là case study mô phỏng; corpus ở IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. /01-curriculum/CANONICAL_DATA_DICTIONARY.md được mô tả là kế hoạch từ điển dữ liệu logic canonical. /01-curriculum/TRACEABILITY_ID_REGISTRY.md là registry định danh canonical.

Current Behavior: Người học thấy tên “canonical” và có thể nhầm thành dữ liệu ERP đã xác nhận. Evidence là metadata hai artifact đều ghi IN_REVIEW và chưa có baseline reference. Vì IN_REVIEW không phải BASELINED, không được dùng nội dung đó như fact vận hành Nova Foods.

Underlying Need: BA cần dùng artifact để giữ cùng tên, cùng ID và cùng đường dẫn khi phân tích dữ liệu, nhưng không được biến kế hoạch học liệu thành quyết định nghiệp vụ.

Options: Dùng artifact không kiểm tra metadata; dùng artifact kèm nhãn IN_REVIEW; dừng khi cần xác nhận vận hành hoặc pháp lý.

Decision Criteria: Chọn cách giữ traceability, không vượt authority, không tạo approval ngầm định, và cho phép reviewer kiểm tra lại nguồn.

Decision: Dùng /01-curriculum/CANONICAL_DATA_DICTIONARY.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md như controlled planning artifact. Gắn Verification required cho mọi nội dung cần xác nhận từ Business Owner, Legal Owner, Accounting Owner, Security hoặc Architect.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và liên kết. Vai trò này không xác nhận rule vận hành, pháp lý, kế toán, bảo mật hoặc production.

Artifact: CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Consequence if Wrong: ID bị đổi hoặc nguồn bị hiểu sai làm đứt traceability. Rule chưa xác minh có thể bị đưa vào yêu cầu ERP như bắt buộc. Quyết định thuộc Legal, Accounting hoặc Business Owner có thể bị BA gán sai thẩm quyền.

Senior Lens

Dừng phân tích với trạng thái STOP — PLAN REWORK REQUIRED khi gặp một trong các điều kiện sau:

Điều kiện dừng	Evidence	Lý do dừng	Hành động đúng
ID hoặc đường dẫn mâu thuẫn	Hai artifact ghi khác nhau cho cùng đối tượng	Không thể truy vết nguồn chân lý	Giữ nguyên mâu thuẫn, báo Owner registry
Nguồn pháp lý bị diễn đạt thành rule ERP	Chỉ có URL hoặc tóm tắt, không có xác minh owner chuyên môn	BA không có thẩm quyền diễn giải pháp lý	Gắn Verification required, chuyển Legal Owner
Nguồn quá cũ hoặc không rõ ngày	Không đối chiếu được mốc 2026-08-07	Không biết nội dung còn áp dụng	Tìm nguồn hiện hành hoặc không dùng
Owner không đúng lĩnh vực	Người viết tài liệu tự xác nhận thuế, kế toán, bảo mật	Trách nhiệm xác nhận sai vai trò	Chuyển Accounting Owner, Security hoặc Legal Owner
IN_REVIEW bị gọi là approved hoặc baselined	Metadata không có approval reference hoặc baseline reference	Tạo cam kết không tồn tại	Sửa nhãn trạng thái, không tiếp tục quyết định

Quick Reference

Phân loại	Có thể dùng cho	Không được dùng cho	Freshness tối thiểu
primary-source verified	Thuật ngữ, trạng thái công bố, safe use boundary	Bịa điều khoản, trang, nghĩa vụ chưa kiểm tra	URL truy cập 2026-08-07
controlled planning artifact	Traceability, metadata, phạm vi học liệu	Fact vận hành Nova Foods	v0.9.0, IN_REVIEW, ngày 2026-08-07
project assumption	Minh họa có nhãn giả định	Rule bắt buộc, cấu hình production	Rà soát khi scope thay đổi
Verification required	Danh sách điểm chờ vai trò có thẩm quyền	Quyết định cuối cùng	Không có hiệu lực đến khi xác minh

Core

Bảng dưới là gói đầu vào mô phỏng cho Nova Foods Trading & Manufacturing. Mọi giá trị là dữ liệu tổng hợp, dùng để minh họa cách BA gom dữ liệu trước khi mô hình hóa master data. Mã NF-* là mã bản ghi mô phỏng ổn định trong ví dụ này; không xác nhận mã ERP thực tế.

Nhóm đầu vào	Bản ghi/mã mô phỏng	Giá trị tổng hợp	Artifact nguồn	Phân loại nguồn	Owner ghi nhận	Ngày dữ liệu	Trạng thái xác minh
Pháp nhân	NF-LE-001	Nova Foods Trading & Manufacturing; quốc gia Việt Nam; tiền tệ VND	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Đã nhận diện; không phải xác nhận pháp nhân thực tế
Địa điểm kho	NF-WH-HCM-01	Kho Thành phẩm HCM; Asia/Ho_Chi_Minh	Bảng đầu vào mô phỏng section 4	Synthetic case data	Business Owner mô phỏng	2026-08-07	Verification required: xác định kho có quản lý lô hay không
Đơn vị đo	NF-UOM-KG	Kilogram; loại khối lượng	Bảng đầu vào mô phỏng section 4	Synthetic case data	Supply Chain Owner mô phỏng	2026-08-07	Đủ cho ví dụ; chưa là cấu hình ERP
Nhóm hàng	NF-IC-BEV	Đồ uống đóng chai	Bảng đầu vào mô phỏng section 4	Synthetic case data	Product Owner mô phỏng	2026-08-07	Verification required: cấu trúc nhóm hàng bán hàng và kế toán có dùng chung không
Thành phẩm	NF-ITEM-NUOC-500	Nước uống đóng chai 500 ml; đơn vị tồn NF-UOM-KG không phù hợp với đơn vị bán chai	Bảng đầu vào mô phỏng section 4	Synthetic case data	Product Owner mô phỏng	2026-08-07	Unresolved: cần xác minh đơn vị tồn, đơn vị bán, quy đổi
Nhà cung cấp	NF-SUP-001	Công ty Bao bì Minh An mô phỏng; cung cấp chai PET	Bảng đầu vào mô phỏng section 4	Synthetic case data	Procurement Owner mô phỏng	2026-08-07	Verification required: mã số thuế, điều khoản thanh toán, trạng thái hoạt động
Khách hàng	NF-CUS-001	Siêu thị Ánh Dương mô phỏng; địa chỉ giao tại TP. Hồ Chí Minh	Bảng đầu vào mô phỏng section 4	Synthetic case data	Sales Owner mô phỏng	2026-08-07	Unresolved: địa chỉ giao hàng có khác địa chỉ xuất hóa đơn không
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	Catalog quy tắc dự kiến, IN_REVIEW, v0.9.0	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Không dùng như quy tắc vận hành đã phê duyệt
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	Kế hoạch từ điển dữ liệu logic canonical	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Cần đọc bản đầy đủ trước khi chốt tên thuộc tính
Registry truy vết	TRACEABILITY_ID_REGISTRY	Registry ID canonical của corpus	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Không tự cấp ID canonical mới từ bảng này

Applied

Facts: NF-ITEM-NUOC-500 là thành phẩm chai 500 ml, nhưng dòng dữ liệu đang gắn NF-UOM-KG. Current Behavior: chưa có bằng chứng cho biết tồn kho, bán hàng, mua hàng dùng cùng đơn vị đo hay có quy đổi. Underlying Need: mô hình dữ liệu cần đơn vị đo nhất quán để tránh cộng tồn kho theo kg rồi xuất bán theo chai. Options: dùng NF-UOM-KG; đổi sang đơn vị chai; hoặc giữ hai đơn vị cùng tỷ lệ quy đổi. Decision Criteria: bằng chứng từ quy cách đóng gói, cách đếm kho, chứng từ bán hàng mô phỏng, và owner nghiệp vụ mô phỏng. Decision: chưa chọn đơn vị chuẩn. Authority: Supply Chain Owner và Product Owner mô phỏng xác minh; BA chỉ ghi nhận truy vết. Artifact: cập nhật dự kiến vào CANONICAL_DATA_DICTIONARY và liên kết TRACEABILITY_ID_REGISTRY. Consequence if Wrong: tồn kho, giá vốn, số lượng bán và báo cáo có thể dùng khác đơn vị, tạo số liệu không so sánh được.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A["NF-ITEM-NUOC-500<br/>Nước uống 500 ml"] --> B["Chưa chọn đơn vị chuẩn<br/>Cần xác minh đơn vị tồn, bán, mua<br/>và tỷ lệ quy đổi"]

    C["Bằng chứng<br/>Quy cách đóng gói<br/>Cách đếm kho<br/>Chứng từ bán hàng mô phỏng"] --> D["Supply Chain Owner mô phỏng<br/>và Product Owner mô phỏng xác minh"]
    B --> D

    D --> E{"Kết quả xác minh"}
    E -- "Giữ NF-UOM-KG" --> F["Đơn vị chuẩn<br/>NF-UOM-KG"]
    E -- "Đổi sang chai" --> G["Đơn vị chuẩn<br/>chai"]
    E -- "Giữ nhiều đơn vị" --> H["Đơn vị tồn, bán, mua<br/>và tỷ lệ quy đổi đã xác minh"]
    E -- "Chưa đủ bằng chứng" --> B

    F --> I["BA ghi nhận truy vết<br/>cập nhật dự kiến dictionary<br/>và liên kết bản ghi registry"]
    G --> I
    H --> I

    I --> J["CANONICAL_DATA_DICTIONARY"]
    I --> K["TRACEABILITY_ID_REGISTRY"]

    F -. "Nếu quyết định sai" .-> L["Rủi ro: tồn kho, giá vốn,<br/>số lượng bán, báo cáo dùng khác đơn vị;<br/>số liệu không so sánh được"]
    G -. "Nếu quyết định sai" .-> L
    H -. "Nếu quyết định sai" .-> L

Senior Lens

Không biến ô trống thành giả định. NF-ITEM-NUOC-500 có mô tả “500 ml” là bằng chứng về dung tích sản phẩm, không phải bằng chứng rằng ERP phải tồn theo chai, lít hay kg. Vì bằng chứng không đủ cho lựa chọn đơn vị, nhãn Unresolved giữ nguyên và ngăn BA tạo thuộc tính hoặc quy đổi có vẻ chắc chắn nhưng không có nguồn.

Quick Reference

Nhãn	Ý nghĩa dùng trong bảng
Synthetic case data	Dữ liệu tự tạo cho Nova Foods mô phỏng; không phải bằng chứng doanh nghiệp thật
Controlled planning artifact	Artifact corpus đang IN_REVIEW, v0.9.0; không là baseline hoặc approval
Verification required	Có thông tin ban đầu nhưng thiếu bằng chứng hoặc xác nhận từ owner đúng thẩm quyền
Unresolved	Chưa thể chọn giá trị mô hình; không được suy diễn thành rule hay cấu hình ERP

5. Step-by-step BA Activities

Core

BA thực hiện theo chuỗi kiểm soát: thu thập bằng chứng, mô hình hóa dữ liệu logic, kiểm tra mâu thuẫn, ghi nhận quyết định hoặc điểm chưa xác minh, rồi bàn giao có truy vết. Dữ liệu logic mô tả nghiệp vụ cần biết gì; không tự suy diễn bảng DB, kiểu cột hay cấu hình ERP.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Artifact đích giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Bước	Actor	Action và object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	BA	Đọc /01-curriculum/CHAPTER_MANIFEST.md, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY; xác định domain master data cần phân tích	Danh sách phạm vi, nguồn và ID giữ nguyên	Chỉ dùng nguồn canonical hoặc dữ liệu tổng hợp có nhãn	Không có ID mới, tên tệp mới, rule mới chưa đăng ký	Principal IT Business Analyst / Technical Curriculum Author khi source hoặc ID mâu thuẫn
2. Thu thập facts	BA và domain owner mô phỏng	Ghi nhận đối tượng, thuộc tính, định danh, vòng đời và quan hệ từ evidence	Bảng facts có nguồn, ngày và phân loại evidence	Fact phải phân biệt với suy luận; thiếu nguồn gắn Verification required	Mỗi fact có nguồn hoặc nhãn synthetic	Business Owner mô phỏng khi ý nghĩa nghiệp vụ chưa rõ
3. Lập danh sách thực thể	BA	Nhóm facts thành entity như Item, Supplier, Warehouse; định nghĩa một câu cho từng entity	Entity list và định nghĩa nghiệp vụ	Một entity đại diện một khái niệm nghiệp vụ ổn định, không phải màn hình	Không trùng nghĩa, không dùng tên kỹ thuật làm tên nghiệp vụ	Product Owner mô phỏng khi hai entity có ranh giới chồng lấp
4. Xác định thuộc tính và khóa	BA	Gắn thuộc tính cho entity; phân biệt business identifier với system identifier	Draft data dictionary entries	Khóa nghiệp vụ chỉ chọn khi evidence chứng minh tính duy nhất và ổn định	Mỗi thuộc tính có định nghĩa, kiểu logic, bắt buộc hay không, nguồn	Architect mô phỏng khi đề xuất ảnh hưởng ID kỹ thuật hoặc tích hợp
5. Mô hình quan hệ và rule	BA	Vẽ quan hệ, lực lượng quan hệ và rule kiểm tra dữ liệu	Logical model, rule-to-field mapping	Quan hệ phải giải thích được bằng fact; rule không được suy từ tên trường	Không có quan hệ thiếu hai đầu hoặc rule thiếu evidence	Business Owner, Accounting Owner, Supply Chain Owner mô phỏng theo domain
6. Kiểm tra chất lượng	BA và QA reviewer mô phỏng	Soát completeness, consistency, uniqueness, traceability và terminology	Data-model review log	Lỗi chặn khi mâu thuẫn nguồn, ID trùng, hoặc dữ liệu nhạy cảm chưa phân loại	Mỗi entity và rule liên kết evidence hoặc Unresolved	Security, Legal, Accounting Owner mô phỏng nếu chạm dữ liệu, pháp lý, kế toán
7. Review và controlled handoff	BA	Đóng gói model, dictionary, issue log và traceability để review	Handoff package tham chiếu CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY	Chỉ bàn giao để review; IN_REVIEW không là baseline hay approval	Package có version, trạng thái, owner, open issue và escalation record	Owner đúng thẩm quyền cho từng open issue; BA không tự đóng quyết định chuyên môn

Facts: NF-ITEM-NUOC-500 là mã Item tổng hợp; mô tả là “Nước uống 500 ml”. Current Behavior: evidence chưa nêu đơn vị tồn kho, đơn vị bán, tỷ lệ quy đổi. Underlying Need: ERP cần đơn vị nhất quán để cộng tồn và ghi nhận giao dịch. Options: chọn chai; chọn lít; giữ Unresolved. Decision Criteria: option chỉ hợp lệ khi có evidence về đơn vị vận hành và quy đổi. Decision: giữ Unresolved vì mô tả “500 ml” chỉ chứng minh dung tích, không chứng minh đơn vị quản lý tồn. Authority: Supply Chain Owner và Product Owner mô phỏng xác minh. Artifact: ghi item vào CANONICAL_DATA_DICTIONARY, liên kết TRACEABILITY_ID_REGISTRY. Consequence if Wrong: tồn kho và báo cáo số lượng có thể cộng các đơn vị không cùng thước đo.

Source mermaid — có thể chỉnh sửa

flowchart TD
    A["BA: Chuẩn bị nguồn canonical"] --> B["Ghi facts có evidence"]
    B --> C["Lập entity, thuộc tính, khóa, quan hệ, rule"]
    C --> D{"Evidence đủ cho quyết định?"}
    D -- "Có" --> E["Ghi decision và traceability"]
    D -- "Không" --> F["Gắn Unresolved"]
    F --> K["Risk: Sai cộng tồn kho, báo cáo"]
    K --> G["Escalate owner (theo thẩm quyền)"]
    E --> H["BA/QA: Kiểm tra chất lượng (lỗi chặn)"]
    G --> H
    H -- "Blocking errors" --> G
    H -- "OK" --> I["Handoff: Package (IN_REVIEW v0.9.0, 2026-08-07)"]

Senior Lens

Evidence không phải quyết định. Một mô tả sản phẩm, email mô phỏng hoặc bảng tính chỉ là đầu vào; BA phải ghi rõ bridge từ evidence sang mô hình. Khi bridge thiếu, giữ Verification required hoặc Unresolved; không lấp bằng rule nghe hợp lý.

Quick Reference

Kiểm tra trước handoff	Đạt khi
Traceability	Fact, entity, thuộc tính, rule và issue đều liên kết nguồn hoặc nhãn thiếu xác minh
Thẩm quyền	Legal, Accounting, Security, Architect và Business Owner chỉ nhận quyết định thuộc domain của họ
Kiểm soát trạng thái	Artifact vẫn là IN_REVIEW, v0.9.0; không gọi là baseline hoặc approval

Core

Mỗi hoạt động BA phải tạo bằng chứng kiểm tra được. BA không chỉ ghi “đã trao đổi”; BA ghi ai xử lý, xử lý đối tượng nào, căn cứ nào, điều kiện quyết định nào, cổng chất lượng nào và chuyển vấn đề cho đúng thẩm quyền nào. Cách này biến trao đổi thành truy vết: người review có thể lần từ quyết định về nguồn, từ nguồn về dữ liệu mô phỏng Nova Foods.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	BA	Đọc phạm vi master data, nguồn và ID đã đăng ký; lập danh sách thuộc tính cần phân tích.	Danh sách thực thể và thuộc tính dự kiến, ví dụ Product, Supplier, Customer.	Danh sách phạm vi có tham chiếu CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.	Chỉ dùng ID, tên tệp, trạng thái đã có nguồn canonical.	Không có ID tự tạo, không có dữ liệu thật, mọi mục ngoài nguồn gắn Verification required.	ID hoặc nguồn mâu thuẫn: Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề; nội dung thuộc nghiệp vụ chuyển Business Owner.
2. Thu thập hiện trạng	BA và Data Owner	Ghi nhận nguồn dữ liệu, người tạo, người sửa, cách dùng và lỗi dữ liệu quan sát được.	Bảng tính, biểu mẫu, báo cáo mô phỏng chứa master data tổng hợp.	Bảng fact log: nguồn, ngày, trường, giá trị mẫu, vấn đề, người cung cấp.	Fact chỉ là điều quan sát hoặc tài liệu nguồn nói rõ; suy luận phải tách riêng và nêu cầu nối lý do.	Mỗi fact có nguồn, thời điểm Asia/Ho_Chi_Minh, phân loại synthetic data.	Tranh chấp về hiện trạng: Data Owner xác nhận; dữ liệu cá nhân hoặc nhạy cảm: Security và Legal Owner.
3. Chuẩn hóa định nghĩa	BA	Viết định nghĩa nghiệp vụ, kiểu dữ liệu logic, tính bắt buộc, miền giá trị và quan hệ.	Thuộc tính master data, ví dụ ProductCode, BaseUoM, ShelfLifeDays.	Bản nháp mục từ điển dữ liệu liên kết CANONICAL_DATA_DICTIONARY.	Một thuộc tính chỉ có một định nghĩa canonical; tên hiển thị khác không tạo thuộc tính mới.	Định nghĩa nêu mục đích, chủ sở hữu, nguồn, kiểu, ví dụ tổng hợp, quy tắc null.	Xung đột nghĩa dữ liệu: Business Owner quyết định nghĩa; Architect đánh giá tác động mô hình.
4. Xác định quy tắc chất lượng	BA và Data Owner	Chuyển nhu cầu thành quy tắc kiểm tra rõ đầu vào, điều kiện, kết quả lỗi.	Mã, trạng thái, đơn vị tính, quan hệ tham chiếu.	Bảng quy tắc nháp liên kết CANONICAL_BUSINESS_RULES.	Quy tắc chỉ ghi là project assumption khi chưa có căn cứ được xác minh; không gọi là nghĩa vụ pháp lý.	Mỗi quy tắc có điều kiện áp dụng, thông báo lỗi, ngoại lệ, owner và nguồn.	Thuế, kế toán, an toàn thực phẩm, truy xuất, dữ liệu cá nhân: Accounting Owner, Legal Owner hoặc domain owner xác minh.
5. Phân tích vòng đời dữ liệu	BA và System Architect	Xác định trạng thái, chuyển trạng thái, quyền thực hiện và tác động tích hợp.	Bản ghi Product mô phỏng và trạng thái dữ liệu.	State model, ma trận quyền-trạng thái, danh sách interface bị ảnh hưởng.	Không cho phép chuyển trạng thái nếu thiếu điều kiện dữ liệu hoặc quyền.	Mỗi trạng thái có ý nghĩa, entry criteria, exit criteria, actor; luồng không có trạng thái mồ côi.	Tác động API, DB, tích hợp: System Architect; rủi ro truy cập: Security.
6. Review và handoff có kiểm soát	BA	Đóng gói quyết định, điểm mở, nguồn và kết quả quality gate; chuyển artifact cho consumer đúng vai trò.	Bản nháp dictionary, rule catalog, traceability links.	Review pack, decision log, issue log, handoff record.	Chỉ handoff nội dung qua quality gate; IN_REVIEW không thành baseline hay approval.	Liên kết nguồn, ID, owner, assumption, Verification required đầy đủ; không có claim phê duyệt.	Không đạt gate: trả về bước gây lỗi; quyết định chưa thuộc BA giữ trạng thái mở và chuyển owner có thẩm quyền.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp. BA xử lý thuộc tính ProductCode cho thực thể Product.

Mục	Nội dung thực thi
Facts	Fact log FL-NF-001 ghi ba mã tổng hợp: NF-BEV-001, nf-bev-001, NF-SNK-010. Hai biến thể khác hoa-thường có thể cùng được hiểu là một sản phẩm. Bằng chứng: bảng dữ liệu mô phỏng do Data Owner cung cấp cho bài học.
Current Behavior	Hiện trạng mô phỏng cho phép nhập tự do ProductCode; tìm kiếm phân biệt hoa-thường. Bằng chứng: quan sát mẫu nhập và kết quả tìm kiếm trong kịch bản học liệu.
Underlying Need	Cần một định danh sản phẩm ổn định để báo cáo, đơn hàng và tồn kho mô phỏng cùng tham chiếu một bản ghi. Lý do: hai mã khác cách viết làm phép nối dữ liệu có thể tách cùng một sản phẩm thành hai dòng.
Options	Phương án 1: giữ nguyên nhập tự do. Phương án 2: chuẩn hóa thành chữ hoa khi lưu và cấm trùng sau chuẩn hóa. Phương án 3: cho phép mã hệ thống tự sinh, không cho người dùng nhập.
Decision Criteria	So sánh theo tránh trùng, khả năng người dùng đọc mã, tác động dữ liệu cũ mô phỏng, khả năng triển khai và quyền quyết định nghiệp vụ.
Decision	Đề xuất Phương án 2: lưu ProductCode chữ hoa; kiểm tra duy nhất trên giá trị đã chuẩn hóa. Lý do: xử lý trực tiếp fact NF-BEV-001 và nf-bev-001, vẫn giữ mã nghiệp vụ dễ đọc. Đây là đề xuất IN_REVIEW, không phải cấu hình ERP đã phê duyệt.
Authority	Business Owner xác nhận quy ước mã; System Architect xác nhận cơ chế unique constraint; Data Owner xác nhận chuyển đổi dữ liệu mô phỏng.
Artifact	Draft dictionary entry trong CANONICAL_DATA_DICTIONARY; draft rule trong CANONICAL_BUSINESS_RULES; liên kết ID kiểm tra trong TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Nếu cấm trùng sai, sản phẩm hợp lệ bị chặn. Nếu cho trùng sai, tồn kho và báo cáo mô phỏng có thể lệch theo hai mã. Vì tác động vận hành phụ thuộc thiết kế ERP thực, Architect và Business Owner phải review trước khi gọi là quyết định.

Bước Nova Foods	Actor	Action và object	Evidence produced	Decision rule	Quality gate	Escalation route
1	BA	Lập FL-NF-001 cho ProductCode.	Fact log có ba mã tổng hợp.	Không đổi fact thành rule.	Mỗi dòng có nguồn và nhãn synthetic.	Data Owner nếu fact thiếu ngữ cảnh.
2	BA	Soạn định nghĩa ProductCode: mã nhận diện sản phẩm trong case mô phỏng.	Draft dictionary entry.	Một mã gắn một Product.	Nêu kiểu string, bắt buộc, ví dụ tổng hợp.	Business Owner nếu nghĩa mã tranh chấp.
3	BA, Data Owner	Đề xuất chuẩn hóa chữ hoa và kiểm tra trùng.	Draft rule và ví dụ đầu vào/lỗi.	nf-bev-001 chuẩn hóa thành NF-BEV-001; từ chối nếu mã chuẩn hóa đã tồn tại.	Quy tắc có điều kiện, kết quả, owner.	System Architect nếu cần DB constraint hoặc API thay đổi.
4	BA	Gói review pack, ghi trạng thái IN_REVIEW.	Decision log, issue log, traceability link.	Không ghi APPROVED hoặc BASELINED.	Liên kết artifact canonical còn nguyên.	Principal IT Business Analyst / Technical Curriculum Author nếu ID hoặc traceability mâu thuẫn.

Core

Bảng thực thi biến hoạt động mô hình dữ liệu thành bằng chứng kiểm tra được. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Bảng không xác nhận cấu hình ERP, baseline, approval, tuân thủ pháp lý hay quyết định vận hành thật.

Điểm thực thi	Dữ liệu tổng hợp Nova Foods	Bằng chứng cần có	Tiêu chí quyết định	Kết quả ghi vào artifact
Xác định thực thể master data	Item, Business Partner, Warehouse, UoM	Danh sách thuộc tính và định nghĩa nghiệp vụ	Thuộc tính phải mô tả đối tượng ổn định, dùng lặp lại giữa giao dịch	Đề xuất mục từ trong CANONICAL_DATA_DICTIONARY
Xác định khóa định danh	ItemCode=NF-RM-00021; WarehouseCode=HCM-RM-01	Quy tắc duy nhất, ví dụ bản ghi	Khóa phải duy nhất, bất biến trong phạm vi đã xác định, không chứa nghĩa dễ đổi	Mapping định danh trong TRACEABILITY_ID_REGISTRY
Phân loại nguồn dữ liệu	Mã hàng do quản trị danh mục; tồn kho do giao dịch kho	Ma trận nguồn tạo, cập nhật, tiêu thụ	Một trường chỉ có một nguồn chân lý cho cùng ngữ cảnh	Ghi nguồn sở hữu dữ liệu vào từ điển
Kiểm tra quan hệ	Một Item có nhiều bản ghi tồn kho theo Warehouse	Cardinality, khóa tham chiếu	Quan hệ phải hỗ trợ truy vết tồn theo hàng và kho; không nhân bản thuộc tính hàng hóa	Quan hệ logic và ràng buộc tham chiếu
Kiểm tra quy tắc	BaseUoM bắt buộc trước khi phát sinh tồn kho	Ví dụ hợp lệ và không hợp lệ	Quy tắc có điều kiện, đối tượng áp dụng, hậu quả vi phạm rõ	Liên kết hoặc đề xuất trong CANONICAL_BUSINESS_RULES
Review liên chức năng	Hàng nguyên liệu NF-RM-00021	Biên bản review nêu vấn đề, người xử lý, nguồn	Mâu thuẫn giữa nghiệp vụ, kế toán, pháp lý, bảo mật hoặc kiến trúc phải escalation đúng vai trò	Log quyết định còn trạng thái review

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Danh sách master data tổng hợp] --> B[Xác định thực thể và thuộc tính]
    B --> C[Đặt khóa định danh và quan hệ]
    C --> D[Xác định nguồn tạo, cập nhật, tiêu thụ và nguồn sở hữu dữ liệu]
    D --> E[Kiểm tra quy tắc dữ liệu]
    E --> F[Review liên chức năng: Business Owner, Architect, Accounting Owner, Legal Owner, Security Owner]
    F --> G{Đủ bằng chứng, một nguồn chân lý và không có mâu thuẫn nghiệp vụ, kế toán, pháp lý, bảo mật hoặc kiến trúc?}
    G -->|Có| H[Đề xuất mục từ CANONICAL_DATA_DICTIONARY trạng thái review]
    H --> I[Liên kết đề xuất TRACEABILITY_ID_REGISTRY và CANONICAL_BUSINESS_RULES]
    I --> J[Log quyết định, vấn đề, người xử lý và nguồn trạng thái review]
    G -->|Không| K[Escalation tới Owner phù hợp]
    K --> B

Applied

Thành phần	Thực thi Nova Foods mô phỏng
Facts	Kho HCM cần theo dõi tồn nguyên liệu NF-RM-00021. Danh mục hàng có ItemCode, ItemName, BaseUoM. Dữ liệu tồn có ItemCode, WarehouseCode, Quantity.
Current Behavior	Hai bảng tính tổng hợp cùng lưu tên hàng; một bảng dùng Đường, bảng kia dùng Sugar. So khớp bằng tên làm tăng rủi ro gộp sai tồn kho.
Underlying Need	Tồn kho phải gắn đúng một hàng và một kho để báo cáo, kiểm kê và truy vết giao dịch dùng cùng định danh.
Options	Phương án 1: ghép bằng ItemName. Phương án 2: ghép bằng ItemCode và WarehouseCode; tên hàng chỉ là thuộc tính mô tả.
Decision Criteria	Định danh phải duy nhất; tên được phép đổi; quan hệ phải kiểm tra được; nguồn chân lý không được trùng.
Decision	Chọn phương án 2. ItemCode là khóa nghiệp vụ của hàng trong phạm vi mô phỏng. Cặp ItemCode và WarehouseCode xác định ngữ cảnh tồn kho.
Authority	Business Owner xác nhận nghĩa nghiệp vụ hàng và kho. Architect xác nhận mô hình logic. Accounting Owner xem xét khi dữ liệu ảnh hưởng hạch toán. Legal Owner hoặc Food Safety Owner xem xét yêu cầu pháp lý, an toàn thực phẩm nếu được nêu; Verification required.
Artifact	Ghi định nghĩa, thuộc tính, khóa, quan hệ và nguồn sở hữu vào /01-curriculum/CANONICAL_DATA_DICTIONARY.md; ghi liên kết định danh vào /01-curriculum/TRACEABILITY_ID_REGISTRY.md; ghi quy tắc vào /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Consequence if Wrong	Ghép sai tên hàng có thể báo cáo sai tồn, chọn sai nguyên liệu khi lập kế hoạch, và làm mất liên kết truy vết giữa giao dịch với master data. Đây là rủi ro dữ liệu, không phải kết luận về vận hành thật.

Cầu nối suy luận: tên hàng thay đổi theo ngôn ngữ hoặc cách gọi, còn mã hàng được thiết kế để nhận diện ổn định. Vì dữ liệu tồn cần tham chiếu hàng cụ thể, dùng ItemCode giảm phụ thuộc vào văn bản mô tả. Vì cùng một hàng có thể nằm nhiều kho, thêm WarehouseCode mới đủ ngữ cảnh tồn.

Senior Lens

Không dùng bảng thực thi để biến giả định thành fact. NF-RM-00021, HCM-RM-01 và quan hệ nêu trên là dữ liệu tổng hợp phục vụ học liệu. Nếu nguồn canonical mâu thuẫn, giữ cả bằng chứng mâu thuẫn, không tự chọn theo ý BA. Nếu một trường vừa được ERP tạo vừa được hệ thống khác sửa, đánh dấu xung đột nguồn chân lý và escalation Architect cùng Business Owner. Nếu thuộc tính có thể là dữ liệu cá nhân, yêu cầu Legal Owner và Security xem xét; không suy diễn nghĩa vụ pháp lý từ handbook.

Quick Reference

Kiểm tra nhanh	Đạt khi
Thực thể	Có định nghĩa nghiệp vụ, không chỉ là tên bảng
Khóa	Duy nhất, ổn định, có phạm vi rõ
Quan hệ	Có cardinality và mục đích nghiệp vụ
Nguồn chân lý	Một trường, một nguồn sở hữu trong cùng ngữ cảnh
Quy tắc	Có điều kiện, đối tượng, hậu quả và nơi ghi nhận
Handoff	Artifact canonical giữ IN_REVIEW; không gắn nhãn baseline hoặc approval

6. Output thu ???c

Core

Output của hoạt động mô hình dữ liệu và master data là artifact kiểm soát được: ghi lại dữ liệu nào tồn tại, được nhận diện ra sao, quy tắc nào chi phối, và thay đổi nào đã xảy ra. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, không phản ánh ERP hay vận hành thật.

Artifact canonical	Tệp canonical	Owner	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW, v0.9.0	Tên thực thể, định nghĩa nghiệp vụ, trường dữ liệu, kiểu logic, khóa, bắt buộc/không bắt buộc, quan hệ, nguồn chân lý, phân loại dữ liệu nếu có	Ghi version, ngày theo Asia/Ho_Chi_Minh, người ghi nhận, trường thay đổi, lý do, artifact bị ảnh hưởng
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW, v0.9.0	Canonical ID, loại ID, phạm vi, artifact nguồn, liên kết artifact dùng ID, trạng thái đăng ký	Không tái dùng ID; ghi tạo, sửa, ngừng dùng và lý do; giữ liên kết cũ để truy vết
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW, v0.9.0	Rule ID, điều kiện, đối tượng dữ liệu, hành vi bắt buộc, hậu quả khi vi phạm, nguồn hoặc nhãn Verification required, owner thẩm quyền	Ghi rule mới, rule sửa, rule ngừng hiệu lực, bằng chứng thay đổi và tác động tới data dictionary

Không tạo artifact mô hình dữ liệu riêng khi CANONICAL_DATA_DICTIONARY đã chứa đủ thực thể, trường, khóa và quan hệ logic. Lý do: một nguồn canonical giảm nguy cơ mô hình và từ điển lệch nhau.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Hoạt động mô hình dữ liệu và master data]
    S{CANONICAL_DATA_DICTIONARY đã đủ<br/>thực thể, trường, khóa, quan hệ logic?}
    X[Không tạo mô hình dữ liệu riêng<br/>ngoài artifact canonical]
    B[Cập nhật CANONICAL_DATA_DICTIONARY<br/>để đủ thực thể, trường, khóa,<br/>quan hệ logic]
    C[CANONICAL_DATA_DICTIONARY<br/>/01-curriculum/CANONICAL_DATA_DICTIONARY.md]
    D[TRACEABILITY_ID_REGISTRY<br/>/01-curriculum/TRACEABILITY_ID_REGISTRY.md]
    E[CANONICAL_BUSINESS_RULES<br/>/01-curriculum/CANONICAL_BUSINESS_RULES.md]
    G{Quality gate<br/>Owner: Principal IT Business Analyst / Technical Curriculum Author<br/>Đúng ID, đường dẫn canonical, IN_REVIEW, v0.9.0, ngày 2026-08-07<br/>Data dictionary đủ thực thể, định nghĩa, trường, kiểu logic, khóa, tính bắt buộc, quan hệ, nguồn chân lý, phân loại dữ liệu nếu có<br/>Không trống trường bắt buộc; mọi ID đã đăng ký<br/>Quy tắc có nguồn hoặc Verification required<br/>Có dòng lịch sử thay đổi}
    H[Đủ đầu vào cho downstream review<br/>Không phải approval, baseline, production readiness]
    I[Chỉ cập nhật artifact không đạt]

    A --> S
    S -->|Có| X
    S -->|Không| B
    B --> C
    X --> C
    C --> D
    C --> E
    C --> G
    D --> G
    E --> G
    G -->|Đạt| H
    G -->|Không đạt| I
    I --> G

Quality gate cho downstream review: mỗi artifact giữ đúng ID, đúng đường dẫn canonical, IN_REVIEW, v0.9.0, ngày 2026-08-07; không có trường bắt buộc trống; mọi ID được đăng ký; mọi quy tắc có nguồn hoặc nhãn Verification required; mọi thay đổi có dòng lịch sử. Gate này chỉ xác nhận đủ đầu vào để review, không phải approval, baseline hay production readiness.

Applied

Facts: Case Nova Foods mô phỏng cần mô tả nguyên liệu có mã NF-RM-00021 và kho có mã HCM-RM-01. Tên hàng có thể đổi theo cách gọi, nhưng mã cần ổn định để giao dịch tham chiếu nhất quán.

Current Behavior: NF-RM-00021 được ghi như mã nguyên liệu; HCM-RM-01 được ghi như mã kho. Hai mã chưa tự giải thích tên trường, khóa hay quy tắc dùng mã.

Underlying Need: Downstream reviewer cần biết mã nào nhận diện hàng, mã nào nhận diện kho, và quan hệ nào đủ để diễn giải tồn theo vị trí.

Options: Ghi hai mã trong văn bản tự do; tạo bảng tính cục bộ; cập nhật ba artifact canonical.

Decision Criteria: Giải pháp phải giữ ID ổn định, có nguồn chân lý, truy vết được thay đổi, không tạo nguồn dữ liệu thứ hai.

Decision: Cập nhật CANONICAL_DATA_DICTIONARY với thực thể Item và Warehouse; đăng ký NF-RM-00021 và HCM-RM-01 trong TRACEABILITY_ID_REGISTRY; chỉ ghi rule vào CANONICAL_BUSINESS_RULES khi có điều kiện và hậu quả xác định.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và traceability. Business Owner, Architect, Accounting Owner, Legal Owner hoặc Security Owner phải xác minh phần thuộc thẩm quyền tương ứng. Không có xác nhận nào được suy diễn từ ví dụ này.

Artifact: CANONICAL_DATA_DICTIONARY ghi ItemCode là khóa nhận diện hàng trong phạm vi Nova Foods mô phỏng; WarehouseCode là khóa nhận diện kho. TRACEABILITY_ID_REGISTRY ghi hai mã là ID case-study tổng hợp, trạng thái IN_REVIEW.

Consequence if Wrong: Nếu ItemCode bị dùng thay WarehouseCode, tồn kho có thể bị gán nhầm địa điểm. Nếu mã không có registry, artifact sau không biết mã có phải định danh hợp lệ hay văn bản minh họa.

Senior Lens

Phân biệt artifact với nội dung artifact. NF-RM-00021 không phải artifact; nó là giá trị dữ liệu tổng hợp, phải được định nghĩa trong data dictionary và đăng ký khi registry yêu cầu. IN_REVIEW cho biết artifact còn có thể thay đổi có kiểm soát. Nó không chứng minh dữ liệu đúng, rule đã được phê duyệt, hay cấu hình ERP sẵn sàng dùng.

Lịch sử thay đổi không được sửa im lặng. Mỗi dòng tối thiểu nêu: version, thời điểm Asia/Ho_Chi_Minh, người ghi nhận, thay đổi, lý do, tác động. Nếu chưa xác minh nguồn pháp lý, kế toán, an toàn thực phẩm hoặc dữ liệu cá nhân, giữ nhãn Verification required; không biến giả định học liệu thành nghĩa vụ vận hành.

Quick Reference

Kiểm tra	Đạt khi
Artifact	Dùng đúng CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES
Đường dẫn	Giữ nguyên đường dẫn canonical đã đăng ký
Status	IN_REVIEW, không diễn giải thành approved hoặc baselined
ID	Không tái dùng, có phạm vi và liên kết registry
Lịch sử	Có version, ngày, người ghi nhận, lý do, tác động
Review gate	Đủ nội dung tối thiểu, không có approval hay production claim

Core

Output của mô hình dữ liệu phải đủ để người đọc tái dựng cùng một ý nghĩa dữ liệu, không suy đoán từ sơ đồ. Với master data, dữ liệu chủ dùng lặp lại qua giao dịch, như mã hàng, đơn vị tính, nhóm hàng. Anatomy tối thiểu của một dòng từ điển dữ liệu logic:

Thành phần	Nội dung phải ghi	Ví dụ Nova Foods mô phỏng
Artifact liên kết	ID và đường dẫn nguồn chân lý	CANONICAL_DATA_DICTIONARY; /01-curriculum/CANONICAL_DATA_DICTIONARY.md
Đối tượng dữ liệu	Danh từ nghiệp vụ, số ít	Product
Thuộc tính	Tên nghiệp vụ và tên logic ổn định	Product Code; product_code
Định nghĩa	Ý nghĩa, không mô tả màn hình	Mã nhận diện duy nhất sản phẩm bán hoặc sản xuất
Kiểu và miền giá trị	Kiểu dữ liệu, độ dài, tập giá trị	String, tối đa 20 ký tự, chữ hoa-số-dấu gạch nối
Khóa và quan hệ	Khóa chính, khóa tham chiếu, lực lượng	product_code là khóa nghiệp vụ; uom_code tham chiếu Unit of Measure
Quy tắc chất lượng	Điều kiện dữ liệu hợp lệ	Không rỗng; không trùng; đơn vị tính phải tồn tại
Nguồn và phân loại	Nguồn gốc thông tin, mức xác minh	Project assumption; dữ liệu tổng hợp
Traceability	Liên kết yêu cầu, rule, quyết định khi đã đăng ký	Tham chiếu TRACEABILITY_ID_REGISTRY; không tự tạo ID registry

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi giá trị dưới đây là dữ liệu tổng hợp. Nghiệp vụ cần phân biệt thành phẩm bán được, nguyên liệu và bao bì vì mỗi loại có cách dùng khác nhau trong ERP.

Current Behavior: Không có bằng chứng về ERP đang vận hành, mã hàng thực, cấu trúc kho thực hay quy tắc pháp lý đã xác minh của Nova Foods. Vì vậy ví dụ không được diễn giải là cấu hình production.

Underlying Need: Một product master phải cho phép sales, kho, mua hàng và sản xuất nhận ra cùng một sản phẩm bằng cùng mã. Bằng chứng reasoning: nếu tên tự do là khóa nhận diện, “Sữa yến mạch 1L” và “Sữa Yến Mạch 1 Lít” có thể bị hiểu là hai hàng khác nhau.

Options: Dùng tên sản phẩm làm khóa; dùng mã số tự tăng; dùng mã nghiệp vụ có cấu trúc. Tên không ổn định do có thể đổi ngôn ngữ hoặc marketing. Mã số tự tăng ít hỗ trợ đọc nghiệp vụ. Mã nghiệp vụ có cấu trúc hỗ trợ nhận diện, nhưng cần giới hạn để không nhét quá nhiều ý nghĩa thay đổi vào mã.

Decision Criteria: Mã phải duy nhất, đọc được, không chứa dữ liệu cá nhân, giữ ổn định khi tên đổi, và đủ ngắn cho nhập liệu.

Decision: Dùng product_code dạng mã nghiệp vụ mô phỏng. Cấu trúc NF-{TYPE}-{NNNN}; TYPE là RM, PM, FG; NNNN là bốn chữ số. Đây là project assumption, chưa là rule vận hành Nova Foods.

Authority: Business Owner xác nhận phân loại nghiệp vụ; Data Owner xác nhận định nghĩa master data; Architect xác nhận khả năng triển khai; Legal, Accounting và Food Safety Owner phải xác minh khi thuộc tính dẫn tới nghĩa vụ pháp lý, kế toán hoặc truy xuất thực phẩm.

Artifact: Bảng dưới là mẫu điền hoàn chỉnh cho CANONICAL_DATA_DICTIONARY. Không có dòng ẩn hoặc dòng bị bỏ.

Đối tượng	Thuộc tính	Giá trị điền cho Nova Foods mô phỏng	Kiểu/miền	Ràng buộc	Phân loại nguồn
Product Master	product_code	NF-FG-0001	String(20)	Khóa nghiệp vụ; duy nhất; không rỗng	Project assumption; synthetic data
Product Master	product_name	Sữa Yến Mạch Nova 1L	String(150)	Không rỗng	Synthetic data
Product Master	product_type	FG	Enum: RM, PM, FG	Không rỗng	Project assumption
Product Master	base_uom_code	EA	String(10)	Phải tham chiếu Unit of Measure tồn tại	Project assumption
Product Master	product_group_code	BEV-OAT	String(30)	Phải tham chiếu Product Group tồn tại	Project assumption
Product Master	traceability_level	BATCH	Enum: NONE, BATCH	Không rỗng; nghĩa nghiệp vụ cần Food Safety Owner xác minh nếu dùng vận hành thật	Verification required
Unit of Measure	uom_code	EA	String(10)	Khóa nghiệp vụ; duy nhất; không rỗng	Project assumption; synthetic data
Unit of Measure	uom_name	Chai	String(50)	Không rỗng	Synthetic data
Product Group	product_group_code	BEV-OAT	String(30)	Khóa nghiệp vụ; duy nhất; không rỗng	Project assumption; synthetic data
Product Group	product_group_name	Đồ uống yến mạch	String(100)	Không rỗng	Synthetic data

Consequence if Wrong: Nếu NF-FG-0001 trùng sản phẩm khác, tồn kho, giá bán, nhu cầu mua và báo cáo có thể gộp sai. Nếu base_uom_code không tham chiếu EA, số lượng giao dịch mất đơn vị đo thống nhất. Nếu gán BATCH như nghĩa vụ pháp lý khi chưa xác minh, artifact biến giả định học liệu thành yêu cầu sai thẩm quyền.

Senior Lens

“Đầy đủ” không nghĩa là nhiều cột. Đầy đủ nghĩa là mỗi thuộc tính trả lời được: nó là gì, giá trị hợp lệ nào, ai hoặc dữ liệu nào tham chiếu nó, và sai thì hệ quả gì. Tên “Sữa Yến Mạch Nova 1L” là giá trị mô tả; NF-FG-0001 là định danh. Không dùng tên làm khóa vì tên thay đổi theo nhãn hàng, còn khóa phải ổn định để giữ liên kết giao dịch.

Không đưa thuế suất, giá vốn, hạn dùng bắt buộc, điều kiện an toàn thực phẩm hoặc thời hạn lưu chứng từ vào ví dụ như rule đã xác nhận. Các nội dung này có thể chịu kiểm tra theo nguồn pháp lý hoặc thẩm quyền chuyên môn. Nhãn đúng tại giai đoạn này là Project assumption hoặc Verification required.

Quick Reference

Kiểm tra anatomy	Đạt khi
Nhận diện	Có đối tượng, thuộc tính, định nghĩa và mã logic
Chất lượng	Có kiểu, miền giá trị, nullability hoặc uniqueness phù hợp
Quan hệ	Mọi khóa tham chiếu chỉ rõ đối tượng đích
Nguồn	Mọi suy luận Nova Foods gắn Project assumption, Verification required hoặc synthetic data
Traceability	Giữ nguyên CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; không tự nhận ID chưa đăng ký
Phạm vi	Ví dụ là học liệu mô phỏng, không xác nhận cấu hình ERP, tuân thủ hay production readiness

Core

Quality gate là cổng kiểm tra bằng chứng trước khi artifact đi xuống bước review. Cổng này xác nhận artifact đủ để người review hiểu, truy vết và phản biện. Cổng không xác nhận nội dung đúng nghiệp vụ, không tạo APPROVED, BASELINED, compliant, production-ready hoặc user-approved.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Artifact] --> G{Đủ bằng chứng, không mâu thuẫn,<br/>đủ để reviewer hiểu, truy vết<br/>và phản biện?}
    G -->|Có: Qua Quality Gate| O[Đi xuống bước review]
    O --> R[Reviewer review artifact]
    G -->|Không| F[Bổ sung bằng chứng<br/>hoặc xử lý mâu thuẫn]
    F --> G
    O -. Không xác nhận .-> B[Không xác nhận nội dung đúng nghiệp vụ]
    O -. Không tạo .-> L[Không tạo APPROVED, BASELINED,<br/>compliant, production-ready<br/>hoặc user-approved]

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Quality gate áp dụng cho mọi output data modeling và master data có ID canonical đã đăng ký, gồm CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES và artifact liên kết trong TRACEABILITY_ID_REGISTRY.

Mục kiểm tra	Bằng chứng phải có	Điều kiện đạt để gửi review	Không được suy diễn thành
Định danh	Artifact ID, đường dẫn canonical, v0.9.0, IN_REVIEW, ngày 2026-08-07	Khớp metadata nguồn canonical	Baseline hoặc approval
Truy vết	Liên kết nguồn, rule, field hoặc master-data concept liên quan	Mỗi quyết định có nguồn hoặc nhãn Project assumption hoặc Verification required	Quy định Nova Foods thực tế
Tính đầy đủ	Không có hàng thiếu, cột trống không giải thích, hoặc tham chiếu không xác định	Mọi phần tử trong phạm vi ghi đủ giá trị, hoặc nêu rõ không áp dụng	Bao phủ toàn bộ ERP
Tính nhất quán	Tên, ID, kiểu dữ liệu logic, trạng thái, owner không mâu thuẫn artifact canonical	Mâu thuẫn được sửa hoặc giữ thành issue truy vết được	Xác nhận thiết kế kỹ thuật
Lịch sử thay đổi	Dòng thay đổi nêu ngày, người ghi nhận, nội dung thay đổi, lý do	Không có sửa im lặng	Phê duyệt thay đổi
Ranh giới thẩm quyền	Nhãn escalation khi chạm pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc kiến trúc	Không gán kết luận cho BA khi thiếu owner có thẩm quyền	Legal, accounting, security sign-off

Facts: CANONICAL_DATA_DICTIONARY có trạng thái IN_REVIEW, phiên bản v0.9.0, scope Nova Foods mô phỏng, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Current Behavior: Artifact chỉ được chuyển sang downstream review khi metadata, traceability, change history và nhãn xác minh đủ.

Underlying Need: Reviewer cần phân biệt “đủ để review” với “đã được chấp thuận”, vì hai trạng thái có thẩm quyền và rủi ro khác nhau.

Options: Gửi artifact khi viết xong; hoặc gửi khi qua quality gate.

Decision Criteria: Review phải tái lập được nguồn, phát hiện được assumption, và không tạo approval ngầm định.

Decision: Chỉ gửi downstream review khi toàn bộ hàng quality gate đạt.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì bằng chứng và lịch sử; Business Owner, Legal Owner, Accounting Owner, Security, Architect, QA giữ thẩm quyền kết luận chuyên môn tương ứng.

Artifact: /01-curriculum/CANONICAL_DATA_DICTIONARY.md, CANONICAL_DATA_DICTIONARY; /01-curriculum/CANONICAL_BUSINESS_RULES.md, CANONICAL_BUSINESS_RULES; /01-curriculum/TRACEABILITY_ID_REGISTRY.md, TRACEABILITY_ID_REGISTRY.

Consequence if Wrong: Artifact thiếu traceability có thể khiến reviewer xem assumption như rule; artifact gắn sai trạng thái có thể bị hiểu nhầm là baseline hoặc sẵn sàng production.

Senior Lens

Quality gate kiểm tra khả năng review, không kiểm tra quyền phê duyệt. Bằng chứng đủ nghĩa là reviewer biết nội dung đến từ đâu, ai sở hữu phần việc, thay đổi gì và điểm nào còn cần xác minh. Khi nguồn pháp lý hoặc chuẩn chỉ có abstract, không được viết thành nghĩa vụ bắt buộc; giữ nhãn Verification required và chuyển đúng owner.

Quick Reference

Kết quả gate	Ý nghĩa
Pass for review	Đủ bằng chứng để review; vẫn là IN_REVIEW
Rework required	Thiếu, mâu thuẫn hoặc không truy vết được; quay lại sửa
Escalation required	Cần kết luận từ owner pháp lý, kế toán, bảo mật, kiến trúc, QA hoặc nghiệp vụ
Không được kết luận	APPROVED, BASELINED, compliant, production-ready, user-approved

7. Who consumes those outputs?

Core

Đầu ra của Data Modeling and Master Data không phải tài liệu để BA giữ riêng. Mỗi artifact trả lời một loại câu hỏi khác nhau, nên mỗi vai trò Nova Foods mô phỏng dùng khác nhau. Dữ liệu dưới đây là tổng hợp, trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không là cấu hình ERP thực tế.

Output canonical	Consumer	Cách dùng trực tiếp
/01-curriculum/CANONICAL_DATA_DICTIONARY.md — CANONICAL_DATA_DICTIONARY	Developer	Chuyển entity, thuộc tính, kiểu dữ liệu logic, khóa và quan hệ thành model ứng dụng, migration DB và hợp đồng API.
CANONICAL_DATA_DICTIONARY	QA	Lập test basis cho kiểm tra trường bắt buộc, định dạng, giá trị biên, quan hệ dữ liệu và dữ liệu trùng.
CANONICAL_DATA_DICTIONARY	Architect	Đối chiếu mô hình logic với ranh giới service, tích hợp, quyền truy cập và khả năng mở rộng.
/01-curriculum/CANONICAL_BUSINESS_RULES.md — CANONICAL_BUSINESS_RULES	Developer	Xác định rule nào cần kiểm tra tại UI, API hoặc DB; tránh tự suy đoán từ tên trường.
CANONICAL_BUSINESS_RULES	QA	Chuyển điều kiện, kết quả mong đợi và ngoại lệ thành test case.
CANONICAL_BUSINESS_RULES	PM/Product Owner	So sánh phạm vi backlog với rule đã ghi nhận; giữ feature không lệch nhu cầu nghiệp vụ.
CANONICAL_BUSINESS_RULES	Business Owner	Đọc rule bằng ngôn ngữ nghiệp vụ để xác định rule phản ánh chính sách vận hành mô phỏng hay còn là assumption.
/01-curriculum/TRACEABILITY_ID_REGISTRY.md — TRACEABILITY_ID_REGISTRY	PM/Product Owner	Liên kết nhu cầu, rule, dữ liệu, story và phạm vi release; phát hiện hạng mục chưa có nguồn gốc.
TRACEABILITY_ID_REGISTRY	QA	Truy từ test về rule và dữ liệu nguồn; chứng minh test không tự tạo yêu cầu mới.
TRACEABILITY_ID_REGISTRY	Operations và specialist owners	Tìm đúng artifact khi rà soát dữ liệu chủ như sản phẩm, khách hàng, nhà cung cấp, kho hoặc đơn vị tính.

Source mermaid — có thể chỉnh sửa

flowchart TB
    DD[CANONICAL_DATA_DICTIONARY]
    BR[CANONICAL_BUSINESS_RULES]
    TR[TRACEABILITY_ID_REGISTRY]

    DD --> DD_DEV[Developer<br/>Entity, thuộc tính, kiểu dữ liệu logic,<br/>khóa, quan hệ thành model ứng dụng,<br/>migration DB, hợp đồng API]
    DD --> DD_QA[QA<br/>Test field bắt buộc, định dạng, biên,<br/>quan hệ, dữ liệu trùng]
    DD --> DD_ARC[Architect<br/>So model logic với service, tích hợp,<br/>quyền truy cập, mở rộng]

    BR --> BR_DEV[Developer<br/>Xác định rule kiểm tra tại UI, API hoặc DB;<br/>không suy đoán rule từ tên trường]
    BR --> BR_QA[QA<br/>Chuyển điều kiện, kết quả mong đợi,<br/>ngoại lệ thành test case]
    BR --> BR_PO[PM/Product Owner<br/>So phạm vi backlog với rule]
    BR_PO --> BR_PO_OUT[Giữ feature đúng nhu cầu]
    BR --> BR_BO[Business Owner<br/>Xác nhận policy vận hành<br/>hay assumption]

    TR --> TR_PO[PM/Product Owner<br/>Liên kết nhu cầu, rule, dữ liệu,<br/>story và phạm vi release]
    TR_PO --> TR_PO_OUT[Phát hiện hạng mục<br/>chưa có nguồn gốc]
    TR --> TR_QA[QA<br/>Truy test về rule nguồn và dữ liệu nguồn]
    TR_QA --> TR_QA_OUT[Chứng minh test không tự tạo<br/>yêu cầu mới]
    TR --> TR_OPS[Operations và specialist owners<br/>Tìm đúng artifact khi rà soát dữ liệu chủ:<br/>sản phẩm, khách hàng, nhà cung cấp,<br/>kho, đơn vị tính]

Applied

Facts: Nova Foods mô phỏng có dữ liệu chủ Product, gồm mã sản phẩm, tên, đơn vị tính và trạng thái dùng được. CANONICAL_DATA_DICTIONARY mô tả nghĩa dữ liệu; CANONICAL_BUSINESS_RULES giữ quy tắc dùng dữ liệu; TRACEABILITY_ID_REGISTRY giữ liên kết định danh.

Current Behavior: Developer cần biết trường nào tạo cấu trúc kỹ thuật. QA cần biết trường nào phải kiểm thử. Operations cần biết dữ liệu nào phải được duy trì khi sản phẩm thay đổi.

Underlying Need: Một thuật ngữ như “trạng thái sản phẩm” có thể bị hiểu là cờ hiển thị UI, quyền bán hàng, hoặc trạng thái tồn kho. Tách artifact giúp mỗi consumer dùng đúng lớp thông tin.

Options: Dùng một bảng chung không phân vai; hoặc giữ ba artifact canonical và phân phối theo nhu cầu sử dụng.

Decision Criteria: Consumer phải tìm được thông tin cần thiết mà không biến data dictionary thành business rule, hoặc biến business rule thành thiết kế kỹ thuật.

Decision: Dùng CANONICAL_DATA_DICTIONARY cho cấu trúc và nghĩa dữ liệu, CANONICAL_BUSINESS_RULES cho hành vi nghiệp vụ, TRACEABILITY_ID_REGISTRY cho liên kết giữa chúng.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability. Developer, QA, Architect, PM/Product Owner, Business Owner, Operations và specialist owners dùng artifact theo vai trò; việc sử dụng không tạo approval.

Artifact: /01-curriculum/CANONICAL_DATA_DICTIONARY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Consequence if Wrong: Developer có thể mã hóa giả định thành rule. QA có thể test sai basis. Operations có thể sửa dữ liệu chủ mà không hiểu ảnh hưởng downstream.

Senior Lens

Architect tiêu thụ quan hệ và ranh giới dữ liệu, không thay Business Owner xác nhận nghĩa nghiệp vụ. Business Owner tiêu thụ rule và thuật ngữ nghiệp vụ, không tự quyết kiểu dữ liệu kỹ thuật. Operations và specialist owners tiêu thụ định nghĩa dữ liệu chủ để vận hành nhất quán, nhưng không được coi IN_REVIEW là cấu hình đã dùng được.

Quick Reference

Vai trò	Output ưu tiên	Mục đích
Developer	Data dictionary, business rules	Xây đúng dữ liệu và hành vi
QA	Business rules, registry, data dictionary	Test đúng basis và truy vết
Architect	Data dictionary	Kiểm tra ranh giới kiến trúc và tích hợp
PM/Product Owner	Business rules, registry	Quản lý phạm vi và liên kết backlog
Business Owner	Business rules	Đọc và rà soát ý nghĩa nghiệp vụ
Operations	Data dictionary, registry	Duy trì dữ liệu chủ nhất quán
Specialist owners	Data dictionary, business rules	Rà soát dữ liệu theo chuyên môn

Core

Đầu ra mô hình dữ liệu gồm mô hình dữ liệu logic, định nghĩa trường, quan hệ, quy tắc dữ liệu chủ và truy vết về nguồn. Nova Foods là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Người nhận không “phê duyệt” đầu ra chỉ vì đã đọc. Họ dùng bằng chứng để quyết định trong phạm vi vai trò; điểm vượt phạm vi phải escalation, nghĩa là chuyển vấn đề kèm bằng chứng đến người có thẩm quyền.

Người nhận	Có thể quyết định	Bằng chứng phải có	Phải escalation khi
Developer	Cách hiện thực field, kiểu dữ liệu vật lý, validation kỹ thuật, mapping API hoặc DB	CANONICAL_DATA_DICTIONARY, mô hình logic, định nghĩa giá trị hợp lệ, truy vết requirement	Một field thiếu định nghĩa; rule mâu thuẫn; mapping làm mất dữ liệu; yêu cầu đổi nghĩa nghiệp vụ
QA	Test basis, dữ liệu kiểm thử tổng hợp, test điều kiện biên, kiểm tra toàn vẹn tham chiếu	Field definition, cardinality, mandatory flag, rule source, acceptance criteria nếu có	Không thể xác định expected result; rule không kiểm thử được; dữ liệu nhạy cảm cần dùng ngoài phạm vi mô phỏng
Architect	Pattern tích hợp, ownership hệ thống, khóa định danh, đồng bộ, retention kỹ thuật	Data ownership, entity relationship, volume giả định, interface boundary, security classification	Một dữ liệu có nhiều system of record; thay đổi ảnh hưởng kiến trúc; rủi ro bảo mật hoặc hiệu năng chưa có owner
PM/Product Owner	Thứ tự ưu tiên phạm vi, chia nhỏ delivery, chấp nhận trade-off sản phẩm trong phạm vi được giao	Dependency, tác động quy trình, rủi ro, effort estimate, traceability	Trade-off đổi business rule; phạm vi ảnh hưởng pháp lý, kế toán, an toàn thực phẩm hoặc cam kết vận hành
Business Owner	Nghĩa nghiệp vụ, chủ sở hữu dữ liệu, giá trị hợp lệ, thời điểm dữ liệu được dùng	Quy trình nghiệp vụ, ví dụ dữ liệu tổng hợp, ngoại lệ, tác động báo cáo	Rule liên quan chính sách, giá bán, hạn mức hoặc hoạt động thực cần quyết định cấp quản trị khác
Operations	Luồng tạo, sửa, khóa, tra cứu dữ liệu; nhu cầu xử lý lỗi hằng ngày	Role matrix, data lifecycle, exception scenario, màn hình hoặc báo cáo dự kiến	Quy trình gây gián đoạn vận hành; thiếu người chịu trách nhiệm sửa dữ liệu; cần thay đổi phân quyền
Specialist owner	Diễn giải chuyên ngành: kế toán, pháp lý, bảo mật, chất lượng, an toàn thực phẩm	Nguồn chính thức phù hợp, giả định dự án, data classification, truy vết rule	Nội dung bị diễn đạt như nghĩa vụ pháp lý, kế toán hoặc tuân thủ khi chưa được xác minh bởi đúng owner

Source mermaid — có thể chỉnh sửa

flowchart TB
    O[Data-model output] --> E[Required evidence:<br/>definitions, rules, traceability,<br/>role-specific sources]
    E --> D[Developer]
    E --> Q[QA]
    E --> A[Architect]
    E --> P[PM/Product Owner]
    E --> B[Business Owner]
    E --> R[Operations]
    E --> S[Specialist owner]

    D --> GD{Within assigned<br/>technical scope?}
    Q --> GQ{Expected result and<br/>testable rule clear?}
    A --> GA{Single system of record;<br/>architecture risk has owner?}
    P --> GP{Trade-off stays within<br/>assigned product scope?}
    B --> GB{Business meaning and<br/>valid values within authority?}
    R --> GR{Operations process and<br/>data-fix owner clear?}
    S --> GS{Within specialist<br/>authority?}

    GD -->|Yes| VD[Technical decision]
    GQ -->|Yes| VQ[QA test basis decision]
    GA -->|Yes| VA[Architecture decision]
    GP -->|Yes| VP[Scope or delivery decision]
    GB -->|Yes| VB[Business data decision]
    GR -->|Yes| VR[Operations decision]
    GS -->|Yes| VS[Specialist interpretation]

    GD -->|No: undefined field, conflicting rule,<br/>data loss, or changed business meaning| X[Escalation package:<br/>issue + required evidence]
    GQ -->|No: no expected result, untestable rule,<br/>or sensitive data outside simulation| X
    GA -->|No: multiple systems of record,<br/>architecture impact, or unowned security/performance risk| X
    GP -->|No: business-rule change or impact on legal,<br/>accounting, food safety, or operational commitment| X
    GB -->|No: policy, price, limit, or activity needs<br/>another management decision| X
    GR -->|No: operational disruption, no data-fix owner,<br/>or access change needed| X
    GS -->|No: stated as legal, accounting, or compliance<br/>obligation without correct owner verification| X

    X --> T[Authorized decision owner]

Applied

Mục	Nội dung
Facts	CANONICAL_DATA_DICTIONARY là artifact canonical dự kiến cho định nghĩa dữ liệu logic. Trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không có baseline hay approval được ghi nhận.
Current Behavior	Developer thấy trường mã khách hàng trong mô hình logic nhưng chưa biết hệ thống nào tạo mã. QA không xác định được bản ghi trùng mã là lỗi hay ngoại lệ.
Underlying Need	Cần xác định ownership trước khi chọn rule tạo mã và test kết quả. Lý do: kiểu dữ liệu không trả lời hệ thống nào là nguồn sự thật.
Options	(1) Developer tự chọn ERP là nguồn tạo mã. (2) Architect xác định system of record từ ranh giới tích hợp. (3) Business Owner xác định chủ sở hữu nghiệp vụ, Architect xác định nơi lưu và đồng bộ.
Decision Criteria	Quyết định phải giữ một nguồn tạo mã, tránh trùng định danh, có thể kiểm thử và không biến giả định kỹ thuật thành rule nghiệp vụ.
Decision	Chọn phương án (3). Business Owner quyết định ownership nghiệp vụ; Architect quyết định ownership kỹ thuật và cơ chế đồng bộ; Developer hiện thực sau khi có kết luận được ghi nhận.
Authority	Business Owner và Architect. BA đóng gói vấn đề, giữ traceability; không thay thẩm quyền hai vai trò này.
Artifact	Cập nhật có kiểm soát tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md và liên kết TRACEABILITY_ID_REGISTRY khi định danh bị ảnh hưởng.
Consequence if Wrong	Hai hệ thống có thể cùng tạo mã khách hàng. Đồng bộ có thể ghi đè dữ liệu, QA kiểm sai expected result, Operations không biết sửa tại đâu.

Senior Lens

Escalation package cần ghi: output bị ảnh hưởng, quyết định cần có, lựa chọn, bằng chứng, owner đề xuất, tác động nếu chậm quyết định. Không ghi “đã được phê duyệt” khi artifact chỉ ở IN_REVIEW. Với dữ liệu liên quan pháp lý, kế toán, bảo mật, an toàn thực phẩm hoặc truy xuất nguồn gốc, nhãn phải là Verification required nếu chưa có xác minh từ specialist owner dựa trên nguồn chính thức hiện hành.

Quick Reference

Tín hiệu	Hành động
Thiếu nghĩa field	Chuyển Business Owner làm rõ nghiệp vụ
Thiếu system of record	Chuyển Architect quyết định ownership kỹ thuật
Thiếu expected result	QA yêu cầu rule và ví dụ dữ liệu tổng hợp
Rule ảnh hưởng pháp lý hoặc kế toán	Chuyển specialist owner; giữ nhãn Verification required
Nhiều vai trò cùng có quyền quyết định	Escalation; BA không tự chọn thay

Core

Sai lệch bàn giao thường xảy ra khi bên nhận biến mô tả dữ liệu thành quyết định chưa có thẩm quyền. Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, artifact ở trạng thái IN_REVIEW, phiên bản v0.9.0, không phải baseline hay phê duyệt. Vì vậy, câu hỏi làm rõ phải chỉ ra: trường nào, nguồn nào, ai sở hữu quyết định, và hậu quả nếu hiểu sai.

Hiểu nhầm bàn giao	Vì sao sai	Câu hỏi làm rõ chính xác
Developer hiểu ProductCode là khóa duy nhất toàn ERP	Từ điển dữ liệu logic có thể mô tả định danh nghiệp vụ, không chứng minh khóa kỹ thuật hay phạm vi duy nhất liên hệ thống.	“ProductCode có duy nhất trong toàn Nova Foods mô phỏng, theo công ty, hay theo nhóm sản phẩm? Canonical source nào xác nhận phạm vi này?”
QA dùng giá trị ví dụ làm dữ liệu hợp lệ duy nhất	Ví dụ dữ liệu tổng hợp minh họa cấu trúc, không thay acceptance criteria hay tập giá trị đầy đủ.	“Giá trị ví dụ này là test data minh họa hay danh sách giá trị được kiểm soát? Test basis nào quy định trường hợp biên và lỗi?”
Architect suy ra tích hợp API từ quan hệ giữa hai thực thể	Quan hệ logic chỉ nói dữ liệu liên quan; không quyết định giao thức, quyền truy cập, đồng bộ hay ownership.	“Quan hệ này yêu cầu trao đổi dữ liệu thật hay chỉ là liên kết báo cáo? Có API contract hoặc quyết định kiến trúc được kiểm soát không?”
PM/Product Owner coi trường Status là trạng thái quy trình đã chốt	Tên trường không xác định chuyển trạng thái, vai trò cho phép chuyển, hay quy tắc ngoại lệ.	“Các giá trị Status nào được phép chuyển qua lại, ai kích hoạt từng chuyển đổi, và quy tắc này nằm trong artifact canonical nào?”
Business Owner cho rằng nhãn Required đồng nghĩa bắt buộc pháp lý	Required có thể là nhu cầu nghiệp vụ hoặc kiểm soát dữ liệu; không đủ bằng chứng cho nghĩa vụ pháp lý.	“Trường này bắt buộc vì quy trình Nova Foods mô phỏng, vì nguồn pháp lý, hay vì thiết kế hệ thống? Nếu là pháp lý, Legal Owner đã xác minh nguồn hiện hành chưa?”
Operations hiểu ngày hiệu lực là dữ liệu tự động có thể sửa lịch sử	Effective date cần xác định múi giờ, quyền sửa, audit trail và cách xử lý bản ghi đã dùng.	“Ngày hiệu lực dùng Asia/Ho_Chi_Minh hay múi giờ khác? Có được sửa bản ghi đã được giao dịch tham chiếu không, và bằng chứng lịch sử nào phải giữ?”
Specialist owner tự chốt đơn vị đo hoặc quy tắc quy đổi	Đơn vị đo ảnh hưởng tồn kho, sản xuất, giá vốn và báo cáo; BA không thay thẩm quyền chuyên môn hoặc kế toán.	“Đơn vị cơ sở là gì, ai sở hữu quy tắc quy đổi, quy đổi có hiệu lực theo ngày không, và Accounting Owner có cần xác minh ảnh hưởng không?”

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Artifact dữ liệu IN_REVIEW] --> B{Bên nhận có suy diễn quyết định?}
    B -->|Không| C[Đọc phạm vi, nguồn, trạng thái]
    C --> D[Tiếp tục sử dụng trong phạm vi IN_REVIEW]
    B -->|Có| E[Đặt câu hỏi: trường, nguồn, owner quyết định, hậu quả hiểu sai]
    E --> F{Có đủ bằng chứng artifact?}
    F -->|Không| G[Ghi thiếu bằng chứng và traceability]
    G --> H[Escalate vai trò có thẩm quyền]
    F -->|Có| I{Người trả lời đúng thẩm quyền?}
    I -->|Không| J[Ghi sai thẩm quyền và traceability]
    J --> H
    I -->|Có| K[Xác nhận: ID, đường dẫn canonical, trạng thái/version, định nghĩa hoặc quy tắc]
    K --> L[Liên kết artifact canonical]
    L --> M[Ghi quyết định làm rõ và traceability]
    H --> N[Ghi phản hồi và traceability]
    N --> F

Escalate khi câu trả lời đòi hỏi quyết định pháp lý, kế toán, an toàn thực phẩm, bảo mật, kiến trúc tích hợp, quyền vận hành, hoặc thay đổi canonical ID. Bằng chứng tối thiểu là artifact nguồn có ID và đường dẫn canonical, trạng thái/version, định nghĩa trường hoặc quy tắc liên quan, cùng vai trò có thẩm quyền trả lời. Không dùng ghi chú miệng, tên trường, hay dữ liệu ví dụ tổng hợp làm thay thế bằng chứng.

8. Detailed Worked Example

Core

Ví dụ này mô tả mô hình dữ liệu master data cho một nguyên liệu nhập kho tại Nova Foods Trading & Manufacturing, doanh nghiệp mô phỏng giáo dục. Master data là dữ liệu dùng lặp lại nhiều giao dịch, như nguyên liệu, đơn vị đo, nhà cung cấp và kho. Transaction data là dữ liệu phát sinh từng lần, như phiếu nhận hàng. Phân biệt này cần thiết vì sai master data sẽ lặp sai trên mọi giao dịch sau đó.

Phạm vi ví dụ: tạo và dùng dữ liệu nguyên liệu RM-SUGAR-001 cho mua hàng, nhận hàng và tồn kho. Dữ liệu đều tổng hợp; không phản ánh ERP, nhà cung cấp, tồn kho hay quyết định vận hành thực tế.

Applied

Scenario: Ngày 2026-08-07, nhân viên mua hàng Nova Foods mô phỏng cần tạo nguyên liệu Đường tinh luyện để lập đơn mua. Kho nhận hàng cần ghi cùng nguyên liệu theo đơn vị KG. Bộ phận chất lượng cần biết lô hàng nào chứa nguyên liệu này khi xảy ra sự cố chất lượng mô phỏng.

Facts

Loại fact	Giá trị tổng hợp	Bằng chứng trong scenario	Ý nghĩa dữ liệu
Tổ chức	Nova Foods Trading & Manufacturing	Case study corpus	Tổ chức mô phỏng sở hữu dữ liệu
Phạm vi	Việt Nam, vi-VN, Asia/Ho_Chi_Minh, VND	Contract corpus	Chuẩn hiển thị ngày, giờ, tiền tệ
Loại item	Nguyên liệu	Nguyên liệu dùng cho sản xuất thực phẩm mô phỏng	Không phải thành phẩm bán ra
Mã nguyên liệu	RM-SUGAR-001	Mã định danh scenario	Khóa nghiệp vụ dễ đọc
Tên nguyên liệu	Đường tinh luyện	Nhãn nghiệp vụ tiếng Việt	Thuộc tính mô tả, không dùng thay khóa
Đơn vị cơ sở	KG	Kho nhận theo kilôgam	Đơn vị chuẩn tồn kho
Kho nhận	WH-RM-HCM-01	Kho nguyên liệu TP. Hồ Chí Minh mô phỏng	Vị trí logic nhận tồn
Nhà cung cấp	SUP-VN-001	Nhà cung cấp tổng hợp	Master data đối tác
Đơn mua	PO-20260807-001	Giao dịch mua mô phỏng	Transaction data tham chiếu nguyên liệu
Phiếu nhận	GRN-20260807-001	Nhận 500 KG nguyên liệu	Transaction data làm tăng tồn
Lô nhà cung cấp	SUPLOT-SG-260801	Nhãn lô trên hàng nhận mô phỏng	Dữ liệu truy xuất theo lô
Lô nội bộ	LOT-RM-SUGAR-20260807-001	Lô ERP tạo khi nhận hàng	Khóa truy xuất tồn kho theo lô

Bộ dữ liệu tối thiểu của nguyên liệu:

Trường	Giá trị	Bắt buộc	Quy tắc scenario
material_id	RM-SUGAR-001	Có	Duy nhất trong tập nguyên liệu mô phỏng
material_name_vi	Đường tinh luyện	Có	Không rỗng
material_type	RAW_MATERIAL	Có	Chỉ phân loại nguyên liệu trong scenario
base_uom_code	KG	Có	Mọi tồn kho nguyên liệu này ghi bằng KG
lot_controlled	true	Có	Mọi lần nhận phải có lô nội bộ
status	ACTIVE	Có	Được phép chọn trên giao dịch mới trong scenario
effective_from	2026-08-07	Có	Diễn giải theo Asia/Ho_Chi_Minh
effective_to	null	Có	null nghĩa chưa xác định ngày kết thúc hiệu lực trong scenario

Payload tổng hợp của master data:

{
  "material_id": "RM-SUGAR-001",
  "material_name_vi": "Đường tinh luyện",
  "material_type": "RAW_MATERIAL",
  "base_uom_code": "KG",
  "lot_controlled": true,
  "status": "ACTIVE",
  "effective_from": "2026-08-07",
  "effective_to": null
}

Payload tổng hợp của phiếu nhận hàng:

{
  "goods_receipt_id": "GRN-20260807-001",
  "purchase_order_id": "PO-20260807-001",
  "warehouse_id": "WH-RM-HCM-01",
  "received_at": "2026-08-07T10:30:00+07:00",
  "lines": [
    {
      "line_no": 1,
      "material_id": "RM-SUGAR-001",
      "quantity": 500,
      "uom_code": "KG",
      "supplier_lot_no": "SUPLOT-SG-260801",
      "internal_lot_id": "LOT-RM-SUGAR-20260807-001"
    }
  ]
}

Current Behavior

Hiện trạng mô phỏng dùng bảng tính riêng cho mua hàng, kho và chất lượng. Mua hàng nhập tên Đường tinh luyện; kho nhập Duong tinh luyen; chất lượng nhập Đường TL. Ba chuỗi khác nhau cùng mô tả một vật liệu, nhưng không có khóa chung bắt buộc. Bằng chứng là ba bảng hiện trạng dưới đây không có cột material_id.

Tệp hiện trạng mô phỏng	Bộ phận dùng	Giá trị nhận diện đang nhập tay	Vấn đề quan sát được
purchasing-material-list.xlsx	Mua hàng	Đường tinh luyện	Tên tự do, không kiểm tra đơn vị cơ sở
warehouse-receiving-log.xlsx	Kho	Duong tinh luyen	Không liên kết chắc chắn tới dòng đơn mua
quality-lot-register.xlsx	Chất lượng	Đường TL	Lô chất lượng không có khóa nguyên liệu chung

Khi nhận 500 KG, kho ghi lô LOT-RM-SUGAR-20260807-001. Tuy nhiên, nếu chất lượng tìm theo tên Đường tinh luyện, hệ thống bảng tính không tự chứng minh Đường TL là cùng nguyên liệu. Suy luận này dựa trên việc tên là dữ liệu mô tả có thể khác dấu, viết tắt hoặc đổi cách gọi; chỉ khóa định danh ổn định mới liên kết đáng tin cậy giữa các bản ghi.

Source mermaid — có thể chỉnh sửa

flowchart LR
    A[Mua hàng<br/>Đường tinh luyện] --> D[Không có material_id chung]
    B[Kho<br/>Duong tinh luyen] --> D
    C[Chất lượng<br/>Đường TL] --> D
    D --> E[Không tự liên kết được đơn mua, phiếu nhận và lô]
    E --> F[Khó truy xuất giao dịch theo một nguyên liệu]

Quy tắc quan sát trong hiện trạng:

Rule ID scenario	Quy tắc hiện trạng	Hệ quả
OBS-MD-001	Tên nguyên liệu được nhập tự do ở từng bảng.	Một nguyên liệu có thể có nhiều tên.
OBS-MD-002	Phiếu nhận không bắt buộc chọn mã nguyên liệu dùng chung.	Không chứng minh chắc chắn dòng nhận thuộc master record nào.
OBS-MD-003	Lô nội bộ được ghi tại kho nhưng không có liên kết bắt buộc tới bản ghi chất lượng.	Tra cứu lô phụ thuộc đối chiếu thủ công.
OBS-MD-004	Đơn vị đo được ghi theo người nhập.	Cùng nguyên liệu có thể xuất hiện với cách ghi đơn vị khác nhau.

Đây là mô tả hiện trạng mô phỏng, không phải kết luận rằng Nova Foods thực tế đang vận hành như vậy. Artifact, quyết định, thẩm quyền và hậu quả quyết định chưa được xác lập trong micro-batch này.

Senior Lens

Đừng bắt đầu bằng bảng dữ liệu lớn. Bắt đầu bằng câu hỏi: cùng một “thứ” có được nhận diện giống nhau khi đi qua mua hàng, kho và chất lượng không? Trong scenario này, bằng chứng là ba tên tự do khác nhau. Vì vậy, rủi ro gốc nằm ở định danh và liên kết dữ liệu, không nằm ở cách viết tên đẹp hay xấu.

RM-SUGAR-001 là mã scenario tổng hợp, không phải canonical ID đã được baseline trong corpus. Trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không có approval hay baseline được suy diễn từ ví dụ này.

Quick Reference

Thành phần	Phân loại	Vai trò trong scenario
RM-SUGAR-001	Master data	Nhận diện nguyên liệu dùng lặp lại
KG	Reference/master data	Đơn vị cơ sở tồn kho
SUP-VN-001	Master data	Nhận diện nhà cung cấp tổng hợp
PO-20260807-001	Transaction data	Đơn mua mô phỏng
GRN-20260807-001	Transaction data	Phiếu nhận mô phỏng
LOT-RM-SUGAR-20260807-001	Transaction data	Lô nội bộ phục vụ truy xuất mô phỏng

Applied

Bối cảnh: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Tình huống tập trung vào master data (dữ liệu chủ): một bản ghi dùng ổn định cho nhiều giao dịch. Đối tượng là thành phẩm bán ra FG-NUOC-CAM-1L, cần chuẩn hóa đơn vị tính để tránh tồn kho và đơn bán hàng ghi khác đơn vị.

Bước	Nội dung thực hiện	Bằng chứng hoặc cầu nối suy luận
Facts	Mã hàng FG-NUOC-CAM-1L; tên Nước cam Nova 1L; loại FINISHED_GOOD; đơn vị tồn kho hiện ghi xen kẽ CHAI và THUNG; quy cách dự kiến 1 THUNG = 12 CHAI; giá bán mô phỏng 240.000 VND/THUNG; kho WH-HCM-FG-01. Ba giao dịch tổng hợp ngày 2026-08-06: SO-SYN-260806-001 bán 10 THUNG, SO-SYN-260806-002 bán 24 CHAI, GR-SYN-260806-001 nhập kho 120 CHAI.	Cùng một hàng có hai đơn vị. Không có quy tắc chuyển đổi được lưu tập trung. Vì vậy hệ thống không thể so sánh trực tiếp số lượng THUNG với CHAI mà không tự suy diễn.
Current Behavior	Nhân viên bán hàng tự đổi 24 CHAI thành 2 THUNG trong bảng tính; nhân viên kho giữ 120 CHAI trong phiếu nhập. Báo cáo tồn kho cộng số 120 với số lượng bán 10 và 24 theo cột số lượng gốc.	Cột số lượng không có đơn vị chuẩn chung. Phép cộng 120 - 10 - 24 = 86 sai ngữ nghĩa vì 10 là thùng, còn 120 và 24 là chai.
Underlying Need	ERP cần một đơn vị tồn kho cơ sở duy nhất, một quy tắc chuyển đổi có kiểm soát, và chỉ cho phép đơn vị giao dịch đã được khai báo cho từng mã hàng.	Nếu chọn CHAI làm đơn vị tồn kho cơ sở, mọi giao dịch đổi được về cùng đơn vị: nhập 120 CHAI, bán 10 THUNG = 120 CHAI, bán 24 CHAI; tồn cuối -24 CHAI. Kết quả âm cho thấy thiếu hàng hoặc sai giao dịch, thay vì bị che bởi phép cộng sai đơn vị.
Options	O1: Cho nhập tự do CHAI, THUNG, LỐC, người dùng tự quy đổi. O2: Chỉ dùng THUNG cho mọi giao dịch. O3: Dùng CHAI làm base unit (đơn vị cơ sở), cho phép THUNG làm alternate unit (đơn vị thay thế), lưu factor 12.	O1 giữ nguyên lỗi kiểm soát. O2 không phù hợp vì nhập kho và kiểm đếm thực tế mô phỏng theo chai. O3 giữ được đơn vị nghiệp vụ, đồng thời chuẩn hóa tồn kho.
Decision Criteria	C1: mọi số lượng tồn đổi được về một đơn vị. C2: không cho phép factor bằng 0 hoặc nhỏ hơn 0. C3: không cho phép giao dịch bằng đơn vị chưa khai báo. C4: truy vết được mã hàng, đơn vị, factor, hiệu lực và người thay đổi. C5: không tự suy diễn giá vốn, thuế, hóa đơn hay nghĩa vụ pháp lý.	C1 xử lý tính đúng của tồn kho. C2 và C3 chặn dữ liệu không dùng được. C4 hỗ trợ kiểm tra thay đổi. C5 giữ đúng ranh giới: case này chỉ quyết định mô hình dữ liệu logic.
Decision	Khuyến nghị BA: chọn O3. CHAI là base_uom_code; THUNG là alternate_uom_code; conversion_factor_to_base = 12; chỉ hai đơn vị này hợp lệ cho FG-NUOC-CAM-1L. Quy tắc đề xuất BR-UOM-001: số lượng giao dịch phải đổi được sang base unit bằng transaction_qty × conversion_factor_to_base.	O3 thỏa C1 đến C4. C5 được giữ vì quyết định không diễn giải kế toán, thuế, an toàn thực phẩm hoặc pháp lý. Đây là khuyến nghị trong artifact IN_REVIEW, chưa là quyết định vận hành được phê duyệt.
Authority	Business Owner quyết định đơn vị nghiệp vụ chấp nhận trên đơn bán và kho. Data Owner quyết định cấu trúc master data và quyền sửa factor. Solution Architect xác nhận mô hình logic khớp ERP mục tiêu. Accounting Owner xem xét tác động nếu factor ảnh hưởng định giá hoặc hạch toán. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận traceability.	Mỗi vai trò có thẩm quyền khác nhau. Không có approval reference tại v0.9.0; không được ghi O3 là “đã phê duyệt”.
Artifact	Bản ghi đề xuất: DM-MD-EX-001. Liên kết dự kiến đến /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Trạng thái liên kết: IN_REVIEW, version v0.9.0, ngày 2026-08-07.	Các tệp canonical là nguồn quản trị kế hoạch. Ví dụ này không tạo baseline, không thay thế nội dung canonical, không tạo cấu hình ERP.
Consequence if Wrong	Nếu chọn THUNG làm base unit nhưng vẫn nhận lẻ CHAI không có factor, tồn kho không thể hiện chính xác. Nếu cho sửa factor 12 thành 10 sau khi đã có giao dịch, lịch sử quy đổi bị sai. Nếu dùng mã hàng chung cho quy cách 12 chai và 24 chai, đơn hàng có thể giao sai quy cách. Nếu báo cáo cộng số lượng không chuẩn hóa, quyết định mua hàng dựa trên tồn kho sai.	Sai master data lan sang mua hàng, bán hàng, kho, kế hoạch và báo cáo. Vì master data được tái sử dụng, lỗi một lần có thể ảnh hưởng nhiều giao dịch.

Dữ liệu chủ logic được đề xuất, chưa được cấp thẩm quyền:

Entity	Khóa	Thuộc tính	Giá trị tổng hợp
ItemMaster	item_code	item_name, item_type, base_uom_code, item_status	FG-NUOC-CAM-1L, Nước cam Nova 1L, FINISHED_GOOD, CHAI, ACTIVE
ItemUomConversion	item_code + uom_code	conversion_factor_to_base, effective_from, status	FG-NUOC-CAM-1L, THUNG, 12, 2026-08-07, ACTIVE
UomMaster	uom_code	uom_name, uom_category	CHAI, Chai, COUNT; THUNG, Thùng, COUNT

Source mermaid — có thể chỉnh sửa

flowchart TB
    subgraph MODEL["Mô hình dữ liệu logic đề xuất"]
        ITEM["ItemMaster<br/>item_code PK<br/>item_name, item_type<br/>base_uom_code FK<br/>item_status"]
        UOM["UomMaster<br/>uom_code PK<br/>uom_name, uom_category"]
        CONV["ItemUomConversion<br/>item_code PK<br/>uom_code PK<br/>conversion_factor_to_base<br/>effective_from<br/>status"]

        ITEM -->|"base_uom_code: đơn vị cơ sở"| UOM
        ITEM -->|"item_code: mã hàng"| CONV
        CONV -->|"uom_code: đơn vị giao dịch"| UOM
    end

    START["DM-MD-EX-001<br/>IN_REVIEW v0.9.0"]
    RULE["BR-UOM-001 đề xuất<br/>Chỉ nhận CHAI hoặc THUNG<br/>CHAI: factor = 1<br/>THUNG: factor = 12<br/>quantity_in_base = transaction_quantity × factor<br/>factor > 0"]

    START -->|"chứa quy tắc đề xuất"| RULE
    ITEM --> RULE
    CONV --> RULE

    CHANGE{"Factor đang hiệu lực đã có<br/>giao dịch tham chiếu?"}
    RULE --> CHANGE
    CHANGE -->|"Có"| BLOCK["Không sửa factor<br/>Tránh làm sai lịch sử quy đổi"]
    CHANGE -->|"Không"| EDIT["Có thể sửa bản ghi đề xuất"]
    BLOCK --> INREVIEW["Giữ trạng thái IN_REVIEW<br/>Rà soát lại đề xuất"]
    EDIT --> INREVIEW

    START --> BO["Business Owner<br/>xác nhận đơn vị nghiệp vụ"]
    START --> DO["Data Owner<br/>xác nhận cấu trúc master data<br/>và quyền sửa factor"]
    START --> SA["Solution Architect<br/>xác nhận mô hình logic<br/>khớp ERP mục tiêu"]

    SA --> IMPACT{"Factor ảnh hưởng<br/>định giá hoặc hạch toán?"}
    IMPACT -->|"Có"| ACCOUNTING["Accounting Owner<br/>xem xét tác động"]
    IMPACT -->|"Không"| SUMMARY{"Đủ xác nhận cần thiết?"}

    BO --> SUMMARY
    DO --> SUMMARY
    ACCOUNTING --> SUMMARY

    SUMMARY -->|"Có"| CANON["Đủ điều kiện đề xuất đưa BR-UOM-001 vào<br/>CANONICAL_BUSINESS_RULES.md<br/>Không phải phê duyệt vận hành<br/>Không phải cấu hình ERP"]
    SUMMARY -->|"Không"| INREVIEW

{
  "artifact_id": "DM-MD-EX-001",
  "status": "IN_REVIEW",
  "version": "v0.9.0",
  "as_of_date": "2026-08-07",
  "case_study": "Nova Foods Trading & Manufacturing - simulated educational case study",
  "item": {
    "item_code": "FG-NUOC-CAM-1L",
    "item_name": "Nước cam Nova 1L",
    "base_uom_code": "CHAI"
  },
  "allowed_uom": [
    {
      "uom_code": "CHAI",
      "conversion_factor_to_base": 1
    },
    {
      "uom_code": "THUNG",
      "conversion_factor_to_base": 12
    }
  ],
  "proposed_rule_id": "BR-UOM-001"
}

BR-UOM-001 là quy tắc đề xuất: với FG-NUOC-CAM-1L, giao dịch chỉ nhận CHAI hoặc THUNG; quantity_in_base = transaction_quantity × conversion_factor_to_base; factor phải lớn hơn 0; không sửa factor đang hiệu lực nếu đã có giao dịch tham chiếu. Cần Business Owner, Data Owner và Solution Architect xác nhận trước khi đưa quy tắc vào catalog canonical.

Applied

Phạm vi ví dụ: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Không có baseline, approval, quyết định vận hành hay cấu hình production.

Core

Dữ liệu chủ (master data) là dữ liệu dùng lặp lại để nhận diện và điều khiển giao dịch: mã hàng, đơn vị tính, nhóm hàng, trạng thái dùng được. Dữ liệu giao dịch chỉ ghi sự kiện phát sinh: đơn mua, nhập kho, hóa đơn. Nếu mã hàng hoặc đơn vị tính sai, giao dịch đúng số học vẫn sai ý nghĩa.

Applied

Scenario SYN-MD-001: Bộ phận Mua hàng nhập nguyên liệu bột mì vào ERP. Cùng một mặt hàng đang có ba tên và hai đơn vị tính. Hệ thống cần một mã hàng chuẩn để mua, nhận và theo dõi tồn kho nhất quán.

Loại	ID hoặc giá trị tổng hợp	Nội dung đầy đủ	Phân loại nguồn
Pháp nhân mô phỏng	NF-VN-001	Nova Foods Trading & Manufacturing	Synthetic data only
Nhà máy mô phỏng	PLANT-HCM-01	Nhà máy TP. Hồ Chí Minh	Synthetic data only
Kho mô phỏng	WH-RM-01	Kho nguyên liệu, PLANT-HCM-01	Synthetic data only
Nhóm hàng	RM-FLOUR	Nguyên liệu bột	Synthetic data only
Đơn vị cơ sở	KG	Kilogram; đơn vị tồn kho và giá mua chuẩn	Project assumption
Mã hàng đề xuất	RM-FLOUR-0001	Bột mì đa dụng Nova 25 kg	Synthetic data only
Nhà cung cấp mô phỏng	SUP-0007	Công ty Bột Mì An Phú	Synthetic data only
Người yêu cầu mô phỏng	USR-PUR-014	Nhân viên Mua hàng	Synthetic data only

Facts. Ba dòng dữ liệu hiện có cùng mô tả hàng hóa nhưng khác mã, tên hoặc đơn vị tính.

Dòng nguồn	Mã đang dùng	Tên đang dùng	Đơn vị tính	Tồn ghi nhận	Bằng chứng
Phiếu nhập GRN-SYN-20260807-001	BOTMI25	Bột mì 25kg	BAO	40	File nhập kho mô phỏng
Đơn mua PO-SYN-20260807-003	BMT-DA-DUNG	Bột mì đa dụng	KG	1.000	File mua hàng mô phỏng
Bảng tính kho INV-SYN-20260807-002	BOT-MI-AP	Bột mì An Phú 25 KG	BAO	20	Bảng tính mô phỏng

Current Behavior. Nhân viên tự gõ mã và đơn vị tính theo chứng từ nhà cung cấp. ERP mô phỏng không chặn mã mới, không có quan hệ quy đổi BAO sang KG, và báo cáo tồn cộng trực tiếp 40 BAO, 1.000 KG, 20 BAO. Bằng chứng là ba mã cùng mô tả nhưng không có khóa liên kết chung.

Underlying Need. Một mặt hàng vật lý cần một định danh chuẩn và một đơn vị tồn kho chuẩn. Lý do: báo cáo tồn chỉ cộng được các lượng cùng đơn vị; BAO và KG không thể cộng nếu chưa có quy tắc quy đổi được kiểm soát.

Options.

Option	Cách làm	Lợi ích	Rủi ro hoặc giới hạn
OPT-1	Giữ ba mã hiện tại	Không cần làm sạch dữ liệu	Tồn kho phân mảnh; không truy vết được tổng tồn một mặt hàng
OPT-2	Giữ một mã chuẩn, lưu BAO là đơn vị thay thế với quy đổi	Tồn kho thống nhất; chứng từ vẫn dùng bao 25 kg	Cần kiểm soát quy đổi và ngày hiệu lực
OPT-3	Dùng BAO làm đơn vị tồn kho chuẩn	Gần cách nhận hàng hiện tại	Không phù hợp đơn mua đang tính theo KG; giá và nhu cầu sản xuất khó so sánh

Decision Criteria.

Tiêu chí	Quy tắc đánh giá	OPT-1	OPT-2	OPT-3
Một khóa hàng hóa	Một vật lý phẩm có một mã hoạt động	Không đạt	Đạt	Đạt
Cộng tồn kho	Mọi lượng quy về một đơn vị cơ sở	Không đạt	Đạt	Không đạt
Tương thích đơn mua KG	Không đổi đơn vị giá mua nguồn	Đạt	Đạt	Không đạt
Kiểm soát nhập liệu	Không cho tự tạo mã hoặc quy đổi tự do	Không đạt	Đạt	Đạt một phần

Recommendation, chưa phải authorized decision: chọn OPT-2. Bằng chứng: chỉ OPT-2 đạt đồng thời bốn tiêu chí. Khuyến nghị không phải quyết định đã được phê duyệt.

Authority. Business Owner quyết định mã hàng còn hiệu lực và quy tắc vận hành mua hàng. Inventory Owner xác nhận đơn vị tồn kho cùng quy đổi vật lý. Accounting Owner xác nhận tác động hạch toán nếu dữ liệu dùng cho sổ kế toán. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận truy vết học liệu. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, không có authorized decision được ghi nhận.

Artifact. Đề xuất cần được ghi vào /01-curriculum/CANONICAL_DATA_DICTIONARY.md và quy tắc vào /01-curriculum/CANONICAL_BUSINESS_RULES.md; hai artifact đều IN_REVIEW, không phải nguồn quyết định đã phê duyệt.

Artifact record	Giá trị đề xuất	Trạng thái
Logical item key	RM-FLOUR-0001	Recommendation
Item name	Bột mì đa dụng Nova 25 kg	Recommendation
Base UoM	KG	Recommendation
Alternate UoM	BAO	Recommendation
Conversion	1 BAO = 25 KG	Project assumption; Inventory Owner verification required
Item status	PROPOSED	Recommendation
Effective date	Không ghi nhận	Không được tự suy diễn
Authorized decision reference	Không có	Không có approval

Payload mô phỏng đầy đủ cho dữ liệu chủ đề xuất:

{
  "itemId": "RM-FLOUR-0001",
  "itemName": "Bột mì đa dụng Nova 25 kg",
  "itemGroupId": "RM-FLOUR",
  "baseUomCode": "KG",
  "alternateUoms": [
    {
      "uomCode": "BAO",
      "numerator": 25,
      "denominator": 1,
      "baseUomCode": "KG",
      "conversionStatus": "PROPOSED"
    }
  ],
  "supplierId": "SUP-0007",
  "plantId": "PLANT-HCM-01",
  "warehouseId": "WH-RM-01",
  "lifecycleStatus": "PROPOSED",
  "dataClassification": "SYNTHETIC",
  "currencyCode": "VND",
  "locale": "vi-VN",
  "timezone": "Asia/Ho_Chi_Minh"
}

Quy tắc đề xuất cần kiểm soát.

Rule ID dữ liệu mô phỏng	Quy tắc	Lý do
SYN-RULE-MD-001	Một itemId hoạt động chỉ có một baseUomCode.	Ngăn cộng tồn giữa đơn vị không cùng nghĩa.
SYN-RULE-MD-002	Mỗi alternateUom phải có tử số, mẫu số, baseUomCode và trạng thái quy đổi.	Ngăn quy đổi không kiểm chứng.
SYN-RULE-MD-003	Giao dịch mới không dùng BOTMI25, BMT-DA-DUNG, BOT-MI-AP sau khi mã thay thế có quyết định thẩm quyền.	Ngăn tạo thêm tồn kho phân mảnh.
SYN-RULE-MD-004	Không tự động hợp nhất tồn lịch sử trước khi Inventory Owner và Accounting Owner xác nhận cách xử lý.	Gộp sai có thể làm sai tồn và số liệu kế toán.

Source mermaid — có thể chỉnh sửa

flowchart TB
    subgraph SRC["Bản ghi nguồn — giữ nguyên để đối chiếu"]
        A["PO-SYN-20260807-003<br/>Mã nguồn: BMT-DA-DUNG<br/>1.000 KG"]
        B["GRN-SYN-20260807-001<br/>Mã nguồn: BOTMI25<br/>40 BAO"]
        C["INV-SYN-20260807-002<br/>Mã nguồn: BOT-MI-AP<br/>20 BAO"]
    end

    subgraph PROP["Phạm vi đề xuất — chưa cập nhật dữ liệu lịch sử"]
        D["Ánh xạ đề xuất<br/>RM-FLOUR-0001<br/>Base UoM: KG"]
        E{"Inventory Owner xác minh<br/>quy đổi BAO sang KG"}
        F["Tính thử<br/>1.000 + 40 × 25 + 20 × 25"]
        H["Cập nhật quy đổi theo xác minh<br/>và tính lại"]
        I["Không dùng quy đổi<br/>khi chưa xác minh"]
    end

    A -. "ánh xạ đề xuất" .-> D
    B -. "ánh xạ đề xuất" .-> D
    C -. "ánh xạ đề xuất" .-> D
    D --> E

    E -- "Đúng: 1 BAO = 25 KG" --> F
    E -- "Khác 25 KG" --> H
    E -- "Chưa xác minh" --> I

    H -. "Nếu vẫn dùng giả định 25 KG" .-> R["Rủi ro: tổng tồn sai<br/>kế hoạch mua thiếu hoặc thừa"]
    I -. "Nếu vẫn dùng quy đổi chưa xác nhận" .-> R

    F --> J{"Business Owner phê duyệt<br/>mã thay thế?"}
    H --> J

    J -- "Chưa phê duyệt" --> K["Giữ trạng thái PROPOSED<br/>không ngừng mã nguồn"]
    J -- "Bác bỏ" --> Q["Ghi nhận bị bác bỏ<br/>không áp dụng mã thay thế hoặc quy đổi"]
    J -- "Phê duyệt" --> S{"Ngày hiệu lực<br/>được phê duyệt?"}

    S -- "Chưa phê duyệt" --> T["Chưa chuyển giao dịch mới<br/>giữ mã nguồn đang dùng"]
    S -- "Đã phê duyệt" --> G["Giao dịch mới dùng RM-FLOUR-0001<br/>từ ngày hiệu lực được phê duyệt"]

    G --> L{"Inventory Owner và Accounting Owner<br/>cho phép hợp nhất lịch sử?"}
    L -- "Chưa cho phép" --> M["Giữ riêng dữ liệu lịch sử<br/>và chứng từ nguồn"]
    L -- "Cho phép, quy đổi 25 KG" --> N["Kết quả mô phỏng có điều kiện: 2.500 KG<br/>chỉ khi 1 BAO = 25 KG được xác nhận<br/>không phải tồn ERP đã cập nhật"]
    L -- "Cho phép, quy đổi khác 25 KG" --> P["Tính lại tổng mô phỏng<br/>theo quy đổi đã xác nhận"]

    N -. "Thực hiện theo quyết định có thẩm quyền" .-> O["Cập nhật dữ liệu lịch sử"]
    P -. "Thực hiện theo quyết định có thẩm quyền" .-> O

Consequence if Wrong. Nếu quy đổi thực tế khác 1 BAO = 25 KG, tồn mô phỏng 2.500 KG sai; kế hoạch mua có thể mua thiếu hoặc thừa. Nếu gộp lịch sử trước khi có thẩm quyền, dữ liệu có thể mất khả năng đối chiếu chứng từ gốc. Nếu dùng recommendation như authorized decision, nhóm triển khai có thể khóa mã hàng hoặc đổi dữ liệu khi chưa có quyền.

Senior Lens

Không suy ra quy đổi từ tên “25 kg” nếu bao thực tế có nhiều quy cách. Tên hàng là bằng chứng mô tả, không phải bằng chứng kỹ thuật cho hệ số quy đổi. Cần bằng chứng từ chủ sở hữu tồn kho hoặc tài liệu nhà cung cấp trước khi biến conversionStatus từ PROPOSED thành trạng thái được thẩm quyền xác nhận.

Quick Reference

Phân biệt	Nghĩa
Recommendation	Kết quả BA đề xuất từ facts và criteria; chưa có hiệu lực vận hành
Authorized decision	Quyết định có tham chiếu thẩm quyền và trạng thái ghi nhận minh bạch
IN_REVIEW	Đang xem xét; không phải APPROVED hoặc BASELINED
Synthetic data only	Dữ liệu học liệu tổng hợp; không dùng làm dữ liệu Nova Foods thực tế

9. Related Concepts & Dependencies

Core

Phụ thuộc (dependency) là quan hệ trong đó artifact này cần dữ liệu, định nghĩa hoặc định danh từ artifact khác để giữ đúng nghĩa. Nguồn chân lý chuẩn (canonical source of truth) là một tệp được chỉ định duy nhất cho mỗi loại nội dung. Ví dụ, định nghĩa trường dữ liệu thuộc CANONICAL_DATA_DICTIONARY; quy tắc nghiệp vụ thuộc CANONICAL_BUSINESS_RULES; mã truy vết thuộc TRACEABILITY_ID_REGISTRY. Chương handbook không chép lại toàn bộ nội dung đó vì hai bản có thể lệch nhau.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là tổng hợp. /02-handbook/11-data-modeling-and-master-data.md giải thích cách BA dùng master data, không phải nơi tạo mã hàng, đổi tên trường dữ liệu hoặc xác nhận cấu hình ERP.

Source mermaid — có thể chỉnh sửa

flowchart TB
    SM["00_SOURCE_MAP<br/>Phạm vi nguồn và giới hạn"]
    CA["01_CURRICULUM_ARCHITECTURE<br/>Cấu trúc học và dependency chapter"]
    CM["CHAPTER_MANIFEST<br/>Tên chapter và đường dẫn handbook"]
    TM["TEMPLATE_MANIFEST<br/>Template đã được định danh"]
    ID["TRACEABILITY_ID_REGISTRY<br/>Persistent ID"]
    BR["CANONICAL_BUSINESS_RULES<br/>Business rule"]
    DD["CANONICAL_DATA_DICTIONARY<br/>Định nghĩa dữ liệu logic"]

    H["Chương 11<br/>Data modeling and master data<br/><br/>Chỉ tiêu thụ canonical content<br/>Không tạo hoặc sửa nội dung chuẩn"]
    OUT["Downstream handbook sections,<br/>templates, QA artifacts"]

    SM -->|"tham chiếu phạm vi nguồn"| H
    CA -->|"liên kết cấu trúc học"| H
    CM -->|"dùng chapter identity"| H
    TM -->|"chỉ dẫn template đã định danh"| H
    ID -->|"dùng ID đã đăng ký"| H
    BR -->|"liên kết rule"| H
    DD -->|"áp dụng data definition"| H
    H -->|"áp dụng dependency"| OUT

    N["Mỗi loại nội dung có một canonical source<br/>Tránh bản sao lệch nhau"]
    N -.-> H

Loại nội dung cần dùng	Canonical artifact	Cách chương này dùng	Không được làm tại đây
Phạm vi nguồn và giới hạn dùng nguồn	/00-research/00_SOURCE_MAP.md — 00_SOURCE_MAP	Tham chiếu phân loại nguồn và giới hạn pháp lý, chuẩn, good practice	Biến nguồn tham khảo thành cam kết tuân thủ Nova Foods
Cấu trúc học và dependency giữa chapter	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md — 01_CURRICULUM_ARCHITECTURE	Liên kết khái niệm master data với lifecycle, requirement, testing	Tự đổi thứ tự hoặc phạm vi curriculum
Tên chapter và đường dẫn handbook	/01-curriculum/CHAPTER_MANIFEST.md — CHAPTER_MANIFEST	Dùng filename, chapter identity đã đăng ký	Tạo chapter ID hoặc filename biến thể
Template dự kiến	/01-curriculum/TEMPLATE_MANIFEST.md — TEMPLATE_MANIFEST	Chỉ dẫn learner đến template phù hợp khi manifest đã định danh	Sao chép template thành bản local không kiểm soát
Persistent ID, tức định danh bền vững qua phiên bản	/01-curriculum/TRACEABILITY_ID_REGISTRY.md — TRACEABILITY_ID_REGISTRY	Dùng đúng ID đã đăng ký khi liên kết artifact	Tự cấp lại, tái sử dụng hoặc đổi nghĩa ID
Business rule	/01-curriculum/CANONICAL_BUSINESS_RULES.md — CANONICAL_BUSINESS_RULES	Nêu rule bằng liên kết đến catalog	Chép rule vào handbook rồi sửa bản chép
Định nghĩa logic của thực thể, thuộc tính, miền giá trị	/01-curriculum/CANONICAL_DATA_DICTIONARY.md — CANONICAL_DATA_DICTIONARY	Giải thích cách đọc và áp dụng data definition	Tự đổi datatype, mandatory status, domain hoặc owner

Applied

Facts. Learner viết ví dụ về nguyên liệu mô phỏng RM-FLOUR-0001 và muốn mô tả đơn vị cơ sở KG. RM-FLOUR-0001 xuất hiện trong nội dung học liệu trước đó, nhưng định nghĩa logic của mã vật tư, trường đơn vị tính và quy tắc chuyển đổi không thuộc quyền sở hữu của chapter này.

Current Behavior. Nếu handbook tự ghi “RM-FLOUR-0001 luôn dùng KG”, câu đó thành bản sao thứ hai của data definition. Bằng chứng là CANONICAL_DATA_DICTIONARY đã được chỉ định là nguồn canonical cho từ điển dữ liệu logic, còn CANONICAL_BUSINESS_RULES là nguồn canonical cho rule.

Underlying Need. Learner cần hiểu quan hệ giữa mã vật tư, đơn vị tính và quy tắc nghiệp vụ mà vẫn biết nơi kiểm tra nghĩa hiện hành. Vì vậy chapter cần liên kết đến artifact chủ quản, không tái công bố định nghĩa như nguồn độc lập.

Options.

Option	Cách làm	Rủi ro
A	Chép toàn bộ định nghĩa RM-FLOUR-0001 vào handbook	Sinh hai nguồn chân lý
B	Chỉ ghi mã không nêu nguồn	Learner không biết kiểm tra nghĩa và trạng thái
C	Nêu mã là ví dụ tổng hợp, liên kết CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES	Giữ một nguồn chân lý cho mỗi loại nội dung

Decision Criteria. Chọn cách giữ nguyên canonical ID, giữ filename đã kiểm soát, phân biệt ví dụ giáo dục với định nghĩa quản trị, và không tạo quyết định nghiệp vụ mới.

Decision. Chọn Option C. Viết: “RM-FLOUR-0001 là mã ví dụ tổng hợp; kiểm tra định nghĩa thuộc tính tại CANONICAL_DATA_DICTIONARY và quy tắc áp dụng tại CANONICAL_BUSINESS_RULES.” Câu này chỉ định vị nguồn; không khẳng định cấu hình ERP thực tế.

Authority. Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết, metadata và nhất quán artifact. Business Owner, Inventory Owner, Accounting Owner, Architect, Legal Owner hoặc QA Owner giữ thẩm quyền theo nội dung chuyên môn tương ứng. IN_REVIEW tại v0.9.0, ngày 2026-08-07, không phải APPROVED hay BASELINED.

Artifact. Liên kết dùng đúng chuỗi: /01-curriculum/CANONICAL_DATA_DICTIONARY.md — CANONICAL_DATA_DICTIONARY; /01-curriculum/CANONICAL_BUSINESS_RULES.md — CANONICAL_BUSINESS_RULES; /01-curriculum/TRACEABILITY_ID_REGISTRY.md — TRACEABILITY_ID_REGISTRY.

Consequence if Wrong. Nếu handbook tự định nghĩa lại KG hoặc đổi nghĩa RM-FLOUR-0001, learner có thể dùng bản cũ thay vì catalog canonical. Nếu tạo ID mới ngoài registry, liên kết giữa chapter, template và artifact sau đó mất khả năng đối chiếu ổn định.

Senior Lens

Phân biệt “tham chiếu” với “sở hữu”. Chapter có thể nói vì sao baseUoM quan trọng, nhưng không sở hữu giá trị, datatype hay miền giá trị của baseUoM. Template có thể chứa ô để nhập mã vật tư, nhưng không sở hữu quy tắc cấp mã. Registry sở hữu tính duy nhất và tính bền vững của ID; data dictionary sở hữu nghĩa dữ liệu; rule catalog sở hữu phát biểu rule.

Không dùng bản sao PDF, trích đoạn, tên rút gọn hay bản dịch tự đặt thay cho đường dẫn canonical. Lý do: chỉ tệp được kiểm soát mới mang metadata Status, Version, owner và lịch sử thay đổi cần thiết để biết nội dung còn hiệu lực xem xét hay không.

Quick Reference

Khi cần	Đi đến nguồn
Xác định chapter filename và phạm vi	CHAPTER_MANIFEST
Xác định template được quy hoạch	TEMPLATE_MANIFEST
Kiểm tra ID có được đăng ký	TRACEABILITY_ID_REGISTRY
Kiểm tra nghĩa dữ liệu master data	CANONICAL_DATA_DICTIONARY
Kiểm tra business rule liên quan dữ liệu	CANONICAL_BUSINESS_RULES
Kiểm tra giới hạn dùng nguồn chuẩn hoặc pháp lý	00_SOURCE_MAP

Core

Traceability (truy vết) là liên kết có hướng giữa nhu cầu và bằng chứng kiểm thử, để biết một thay đổi ảnh hưởng vật nào. Mỗi liên kết giữ ID đã đăng ký nguyên dạng, không chép nội dung nguồn sang bảng này. Bảng chỉ là chỉ mục; nguồn chân lý vẫn nằm ở registry hoặc artifact canonical.

Loại liên kết	Ý nghĩa	Nguồn canonical cần tham chiếu	Đích cần liên kết	Quy tắc tối thiểu
NEED	Nhu cầu vấn đề hoặc kết quả mong muốn	TRACEABILITY_ID_REGISTRY	REQ	Một NEED có thể dẫn nhiều REQ; không tự biến thành yêu cầu hệ thống.
REQ	Requirement, yêu cầu cần đáp ứng	Artifact requirement đã đăng ký ID	BR, AC, DATA/API, TC	Mỗi REQ phải có nguồn và trạng thái riêng.
BR	Business Rule, quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	REQ, AC, DATA/API, TC	Chỉ catalog quy tắc được giữ nội dung quy tắc.
AC	Acceptance Criteria, tiêu chí chấp nhận	Artifact requirement hoặc backlog đã đăng ký	REQ, TC	AC phải kiểm chứng được, không thay thế test case.
DATA/API	Thuộc tính dữ liệu hoặc hợp đồng giao diện	CANONICAL_DATA_DICTIONARY hoặc đặc tả API được kiểm soát	REQ, BR, AC, TC	Giữ tên trường, kiểu dữ liệu, định danh API đúng nguồn.
TC	Test Case, ca kiểm thử	Test artifact đã đăng ký	REQ, BR, AC, DATA/API	TC chứng minh hành vi; không xác nhận business approval.

Applied

Mục	Nội dung
Facts	Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Seed hiện có xác nhận các artifact TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY; không cung cấp instance ID NEED, REQ, BR, AC, DATA/API hoặc TC cụ thể.
Current Behavior	BA có thể thấy cùng một quy tắc về mã hàng trong requirement, data dictionary và test case. Chép lại câu chữ tại ba nơi tạo ba bản cạnh tranh.
Underlying Need	Cần biết requirement nào dùng dữ liệu nào và test nào chứng minh rule nào, nhưng không tạo ID mới hoặc nguồn chân lý mới.
Options	1. Chép toàn văn requirement, rule và field vào bảng traceability. 2. Chỉ ghi liên kết bằng ID canonical, artifact path và loại quan hệ.
Decision Criteria	Bảo toàn ID; tránh lệch nội dung; truy được nguồn; không vượt thẩm quyền Owner; phù hợp trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Decision	Chọn phương án 2. Khi instance ID được đăng ký, bảng traceability chỉ thêm dòng liên kết, không tạo lại nội dung canonical.
Authority	Principal IT Business Analyst / Technical Curriculum Author giữ tính toàn vẹn artifact. Business Owner, Architect, QA, Legal, Accounting hoặc Security giữ quyết định chuyên môn thuộc phạm vi họ.
Artifact	Registry: /01-curriculum/TRACEABILITY_ID_REGISTRY.md; rule catalog: /01-curriculum/CANONICAL_BUSINESS_RULES.md; data dictionary: /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Nếu BA tự đặt ID hoặc sao chép rule, QA có thể test bản cũ, Architect có thể map field sai, và người đọc có thể hiểu nhầm nội dung IN_REVIEW là đã baseline hoặc được phê duyệt.

Senior Lens

Dùng mẫu dòng liên kết sau sau khi registry cấp ID: NEED ID | REQ ID | BR ID | AC ID | DATA/API ID | TC ID | Loại quan hệ | Nguồn canonical. Ô trống chỉ hợp lệ khi loại liên kết không áp dụng; phải ghi N/A — không áp dụng và lý do. Không dùng ô trống để che thiếu phân tích.

Evidence bridge: TRACEABILITY_ID_REGISTRY là registry canonical cho định danh; CANONICAL_BUSINESS_RULES là catalog canonical cho rule; CANONICAL_DATA_DICTIONARY là nguồn canonical cho dữ liệu logic. Vì mỗi artifact có ranh giới riêng, bảng liên kết phải trỏ về chúng thay vì sao chép nội dung.

Quick Reference

Kiểm tra	Đạt khi
ID	Giữ nguyên ID đã đăng ký, không dịch, không đổi tiền tố.
Nguồn	Mỗi liên kết có artifact path canonical.
Rule	Nội dung BR chỉ nằm tại CANONICAL_BUSINESS_RULES.
Data/API	Định nghĩa field hoặc API chỉ nằm tại CANONICAL_DATA_DICTIONARY hoặc đặc tả API được kiểm soát.
Test	Mỗi TC trỏ ngược ít nhất một REQ, BR, AC hoặc DATA/API có liên quan.
Governance	IN_REVIEW không phải baseline, approval, compliance hay production-ready.

Core

Thay đổi phụ thuộc phải lan truyền có kiểm soát. Phụ thuộc là artifact, quy tắc, định nghĩa dữ liệu, API hoặc test dùng cùng một ý nghĩa. Nếu nguồn gốc đổi nhưng artifact tiêu thụ không biết, cùng một dữ liệu bị hiểu khác nhau. Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp.

Ví dụ: CANONICAL_DATA_DICTIONARY đổi nghĩa trường unit_of_measure từ “đơn vị lưu kho” sang “đơn vị bán”. API, quy tắc quy đổi, màn hình nhập đơn và test vẫn dùng nghĩa cũ. Hệ thống có thể lưu THUNG cho tồn kho nhưng tính giá bán theo CAI. Dữ liệu không lỗi cú pháp, nhưng sai nghiệp vụ.

Source mermaid — có thể chỉnh sửa

flowchart TB
    S[Data definition, business rule, persistent ID, source classification, or API version changes] --> I[Assess impacted consumers]
    I --> R[Revise API contracts, mappings, requirements, acceptance criteria, tests, rule catalog, and compliance notes]
    I --> T[Update traceability links]
    R --> VA[Review updated meaning, API compatibility, and rules]
    VA --> V[Run tests]
    T --> VT[Review traceability links and evidence]
    V -->|Artifacts validated| G[Artifacts revised and tested; traceability and evidence reviewed]
    VT -->|Traceability validated| G
    G --> P[Publish controlled version]

    S -. silent change .-> D[Different data meaning, incorrect synchronization, or data loss]
    S -. silent change .-> A[API integration failure or tests validate old rules]
    S -. silent change .-> C[Broken traceability or compliance and authority misinterpretation]

Phụ thuộc đổi im lặng	Artifact vỡ	Dấu hiệu	Hậu quả
Định nghĩa thuộc tính dữ liệu	API contract, mapping tích hợp, test data	Cùng tên trường, khác kiểu hoặc nghĩa	Sai đồng bộ, mất hoặc hiểu sai dữ liệu
Business rule đổi	Requirement, acceptance criteria, test case	Test vẫn pass theo rule cũ	Chức năng chạy nhưng sai quyết định nghiệp vụ
Persistent ID đổi hoặc tái sử dụng	Traceability matrix, defect link, evidence	Link trỏ sang đối tượng khác hoặc không tìm thấy	Không chứng minh được nguồn gốc thay đổi
Source classification đổi	Rule catalog, compliance note	Giả định bị đọc như nghĩa vụ	Quyết định vượt thẩm quyền legal hoặc accounting
API version đổi	Consumer integration, TC API	HTTP request hoặc response không còn khớp	Giao dịch tích hợp thất bại hoặc ghi nhận thiếu

Applied

Facts: CANONICAL_DATA_DICTIONARY là nguồn canonical cho định nghĩa dữ liệu logic; TRACEABILITY_ID_REGISTRY là nguồn canonical cho persistent ID. Cả hai đang IN_REVIEW, v0.9.0, ngày 2026-08-07. Không có baseline hoặc approval được ghi nhận.

Current Behavior: Một bản sao bảng mapping của đơn mua hàng dùng nhãn trường supplier_code. Bản sao không ghi version nguồn, không có liên kết tới dictionary, và API consumer dùng nhãn này để ghép nhà cung cấp.

Underlying Need: Giữ một nghĩa duy nhất cho mã nhà cung cấp xuyên từ dữ liệu master đến API và test. Evidence: mã là khóa liên kết; khóa đổi nghĩa sẽ làm bản ghi ghép sai dù định dạng vẫn hợp lệ.

Options:

Option	Cách làm	Rủi ro
A	Sửa bản sao mapping trực tiếp	Tạo thêm nguồn sự thật, dễ lệch lần sau
B	Tham chiếu CANONICAL_DATA_DICTIONARY, ghi version và impact record	Giữ nguồn canonical duy nhất
C	Đổi tên trường API không đánh giá consumer	Consumer cũ lỗi không được phát hiện

Decision Criteria: Chọn cách không tạo nguồn sự thật thứ hai; giữ persistent ID; xác định consumer trước khi đổi; cập nhật test basis trước khi gọi thay đổi là hoàn tất.

Decision: Chọn Option B. Mapping chỉ ghi tham chiếu tới /01-curriculum/CANONICAL_DATA_DICTIONARY.md; không sao chép định nghĩa. Mọi đổi nghĩa supplier_code phải mở impact record, kiểm tra API consumer và TC liên quan trước khi phát hành version mới.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì traceability và metadata. Business Owner xác nhận nghĩa nghiệp vụ. Architect xác nhận API impact. QA xác nhận test coverage. Không vai trò nào được suy diễn approval từ trạng thái IN_REVIEW.

Artifact: Impact record liên kết CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY, API specification và test artifact. Không tạo ID mới trong micro-batch này.

Consequence if Wrong: Nếu supplier_code đổi từ mã nhà cung cấp nội bộ sang mã do đối tác gửi mà API không đổi mapping, đơn mua hàng có thể gắn nhầm supplier master. Kiểm tra định dạng vẫn pass; đối soát nghiệp vụ và traceability thất bại.

Senior Lens

Không coi “đổi nhãn” là thay đổi nhỏ. Tên, định nghĩa, kiểu dữ liệu, miền giá trị, cardinality, owner, classification và lifecycle đều có thể đổi nghĩa consumer. BA phải hỏi: consumer nào đọc artifact này, họ dùng trường nào để quyết định, và bằng chứng test nào chứng minh nghĩa mới?

Link type	Nguồn cần kiểm tra	Điều cần xác nhận khi đổi
NEED	Need nguồn	Vấn đề gốc còn đúng không
REQ	Requirement	Phạm vi và điều kiện xử lý còn khớp không
BR	CANONICAL_BUSINESS_RULES	Rule còn cùng định nghĩa dữ liệu không
AC	Acceptance criteria	Tiêu chí quan sát được còn kiểm tra đúng không
DATA/API	Dictionary, schema, API contract	Tên, kiểu, bắt buộc, giá trị và version có đổi không
TC	Test case, test data	Test chứng minh nghĩa mới, không chỉ response hợp lệ

Quick Reference

1. Không sửa im lặng nguồn canonical hoặc bản sao tiêu thụ.
2. Ghi impact trước: thay đổi gì, nguồn nào, consumer nào, link NEED/REQ/BR/AC/DATA/API/TC nào.
3. Giữ persistent ID; nếu retire ID, ghi trạng thái và liên kết thay thế trong TRACEABILITY_ID_REGISTRY.
4. Cập nhật consumer và TC cùng đợt thay đổi.
5. Nếu source classification, legal, accounting, security hoặc API contract đổi, escalation đúng owner; không tự kết luận.

10. Common Mistakes & Anti-patterns

Core

Anti-pattern là cách làm lặp lại, nhìn có vẻ nhanh nhưng tạo lỗi hệ thống hoặc lỗi bàn giao. Với data modeling và master data, lỗi thường không nằm ở bảng dữ liệu; lỗi nằm ở nghĩa dữ liệu, quyền quản trị và bằng chứng kiểm tra không khớp nhau.

Mistake	Red flag quan sát được	Root cause	Corrective action
Gộp supplier_code và tên nhà cung cấp thành một trường	Giá trị như SUP-001 - Công ty An Phát xuất hiện trong cột mã	Không tách business key khỏi nhãn hiển thị	Giữ supplier_code là mã ổn định; lưu tên ở supplier_name; cập nhật dictionary và API mapping
Dùng Excel làm master source nhưng ERP cũng cho sửa trực tiếp	Hai danh sách cùng mã có tên, trạng thái hoặc địa chỉ khác nhau	Chưa chỉ định source of truth, tức nguồn dữ liệu quyết định	Chỉ định một nguồn canonical; nguồn còn lại chỉ đọc hoặc đồng bộ có kiểm soát
Đặt mã tự tăng làm business key	Người dùng nói “nhà cung cấp 1042” nhưng mã đổi giữa môi trường test và production	Nhầm technical ID với mã nghiệp vụ	Dùng persistent internal ID cho liên kết kỹ thuật; dùng supplier_code cho nghiệp vụ nếu business owner xác nhận
Cho phép trạng thái tự do bằng text	Có Active, active, Đang hoạt động, A trong cùng trường	Không có controlled vocabulary, tức danh sách giá trị kiểm soát	Định nghĩa code list, giá trị hợp lệ, nghĩa từng giá trị và owner quản trị
Xóa master record đã phát sinh giao dịch	Đơn mua cũ không hiển thị nhà cung cấp hoặc khóa ngoại lỗi	Nhầm retire với delete	Dùng trạng thái inactive/retired; chặn giao dịch mới; giữ lịch sử giao dịch
Chỉ kiểm tra “lưu được”	Demo thành công nhưng báo cáo nhóm sai nhà cung cấp	Test chỉ kiểm tra kỹ thuật, không kiểm tra nghĩa nghiệp vụ	Thêm acceptance criteria và test case cho uniqueness, trạng thái, mapping và báo cáo tiêu thụ
Ghi field “bắt buộc” nhưng không nêu điều kiện	Developer hỏi “bắt buộc khi nào?”	Requirement thiếu điều kiện nghiệp vụ	Viết điều kiện rõ: trường nào, khi nào, ai nhập, lỗi gì khi thiếu
Sửa dictionary nhưng không sửa API contract và test data	API trả trường cũ; test vẫn pass vì mock cũ	Thay đổi không có impact analysis	Liệt kê consumer; cập nhật dictionary, schema/API contract, test case và test data trong cùng change set

Applied

Facts: Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. Master nhà cung cấp có supplier_code = SUP-001, supplier_name = Công ty TNHH Thực phẩm Minh An, status = Active.

Current Behavior: Delivery team thêm cột supplier_display_name và dùng nó làm giá trị gửi trong đơn mua hàng. Giá trị gửi là SUP-001 - Công ty TNHH Thực phẩm Minh An.

Underlying Need: Người mua cần nhìn đồng thời mã và tên để chọn đúng nhà cung cấp. Nhu cầu là hiển thị dễ nhận biết, không phải thay business key.

Options: (1) Lưu chuỗi ghép vào đơn mua hàng; (2) Gửi supplier_code, giao diện hiển thị chuỗi ghép; (3) Gửi internal ID, API tự tra mã và tên.

Decision Criteria: Mã phải ổn định khi tên đổi; đơn mua hàng phải liên kết đúng supplier master; báo cáo phải nhóm theo một khóa; API phải kiểm tra được dữ liệu đầu vào.

Decision: Chọn phương án 2 cho artifact mô phỏng: đơn mua hàng lưu supplier_code; giao diện tạo supplier_display_name từ mã và tên. Đây là quyết định thiết kế học liệu, không phải cấu hình ERP thực tế.

Authority: Business Owner xác nhận mã nghiệp vụ cần dùng; Data Owner xác nhận định nghĩa và lifecycle supplier master; Architect xác nhận API contract. Không có approval được ghi nhận tại IN_REVIEW v0.9.0.

Artifact: Cập nhật định nghĩa trường trong CANONICAL_DATA_DICTIONARY; giữ liên kết định danh trong TRACEABILITY_ID_REGISTRY; cập nhật consumer API và test case liên quan.

Consequence if Wrong: Khi tên nhà cung cấp đổi nhưng chuỗi ghép đã lưu trong đơn mua hàng, dữ liệu lịch sử và master có thể khác nhau. Khi consumer tách chuỗi theo dấu -, tên có dấu - làm parsing sai. Khôi phục an toàn: dừng ghi giá trị ghép mới, xác định giao dịch bị ảnh hưởng, đối chiếu supplier_code với supplier master, rồi sửa mapping có kiểm soát. Không xóa giao dịch lịch sử để che lỗi.

Source mermaid — có thể chỉnh sửa

flowchart TB
    DEC{"Chọn phương án định danh supplier"}

    O1["Phương án 1<br/>Lưu supplier_display_name trong purchase order<br/>hoặc consumer parse chuỗi ghép"]
    O2["Phương án 2 — Được chọn<br/>API payload và purchase order dùng supplier_code"]
    O3["Phương án 3<br/>Gửi internal ID; API tra supplier_code và supplier_name"]

    DEC --> O1
    DEC --> O2
    DEC --> O3

    O1 --> O1R["Loại<br/>Tên đổi làm chuỗi lịch sử lệch supplier master<br/>Dấu - trong tên làm parsing sai"]
    O3 --> O3R["Không chọn cho artifact mô phỏng"]

    subgraph UI["UI"]
        U1["Buyer chọn supplier"]
        U2["Đọc supplier_code và supplier_name"]
        U3["Tạo supplier_display_name<br/>SUP-001 - Công ty TNHH Thực phẩm Minh An"]
        U4["Chỉ dùng supplier_display_name để hiển thị"]
        U5["Tạo API payload với supplier_code"]
        U1 --> U2 --> U3 --> U4 --> U5
    end

    subgraph API["Consumer API"]
        A1["Nhận supplier_code"]
        A2{"supplier_code tồn tại trong supplier master?"}
        A3["Từ chối dữ liệu đầu vào"]
        A1 --> A2
        A2 -- "Không" --> A3
    end

    subgraph MASTER["Supplier master canonical"]
        M1["supplier_code = SUP-001<br/>supplier_name = Công ty TNHH Thực phẩm Minh An<br/>status = Active"]
        M2["Tên supplier có thể đổi"]
        M1 --> M2
    end

    subgraph PO["Purchase order"]
        P1["Lưu supplier_code"]
        P2["Liên kết supplier master bằng supplier_code"]
        P1 --> P2
    end

    subgraph REPORT["Reporting"]
        G1["Đọc purchase order"]
        G2["Nhóm theo supplier_code"]
        G1 --> G2
    end

    O2 --> U1
    M1 -. "Dữ liệu hiển thị" .-> U2
    U5 --> A1
    A2 -. "Kiểm tra" .-> M1
    A2 -- "Có" --> P1
    P2 --> G1
    M2 --> K1["Liên kết vẫn đúng<br/>purchase order giữ supplier_code"]

    subgraph GOVERNANCE["Governance"]
        V1["Trạng thái: IN_REVIEW"]
        V2["Phiên bản: v0.9.0"]
        V3["Chưa ghi nhận approval"]
        V1 --> V2 --> V3
    end

    subgraph OWNERSHIP["Xác nhận chuyên môn"]
        R1["Business Owner<br/>Xác nhận supplier_code là business key"]
        R2["Data Owner<br/>Xác nhận định nghĩa và lifecycle supplier master"]
        R3["Architect<br/>Xác nhận Consumer API contract"]
    end

    R1 -. "Approval chưa được ghi nhận" .-> V3
    R2 -. "Approval chưa được ghi nhận" .-> V3
    R3 -. "Approval chưa được ghi nhận" .-> V3

    subgraph ARTIFACTS["Artifacts cập nhật"]
        T1["CANONICAL_DATA_DICTIONARY<br/>Định nghĩa trường"]
        T2["TRACEABILITY_ID_REGISTRY<br/>Giữ liên kết định danh"]
        T3["Consumer API<br/>Contract và validation"]
        T4["Test case liên quan"]
    end

    P1 -. "Cập nhật" .-> T1
    P2 -. "Giữ liên kết" .-> T2
    A2 -. "Cập nhật" .-> T3
    A2 -. "Kiểm thử" .-> T4

    subgraph RECOVERY["Khôi phục purchase order cũ lưu chuỗi ghép"]
        X1["Dừng ghi giá trị ghép mới"]
        X2["Xác định giao dịch bị ảnh hưởng"]
        X3["Đối chiếu supplier_code với supplier master"]
        X4["Sửa mapping có kiểm soát"]
        X5["Không xóa giao dịch lịch sử"]
        X1 --> X2 --> X3 --> X4 --> X5
    end

    O1R -. "Nếu đã phát sinh dữ liệu" .-> X1

Senior Lens

Lỗi novice thường là thiếu mô hình hóa. Lỗi delivery-team thường là biết mô hình nhưng bỏ qua consumer. Cùng một thay đổi supplier_name có thể không ảnh hưởng khóa liên kết, nhưng vẫn ảnh hưởng tìm kiếm, báo cáo, tích hợp và test data. Vì vậy corrective action phải nêu artifact cần sửa, consumer bị ảnh hưởng và kiểm tra chứng minh sửa đúng.

Dấu hiệu	Câu hỏi senior BA phải hỏi	Hành động tối thiểu
Một field chứa nhiều nghĩa	Field này có thể tách thành key, name, status hoặc classification không?	Tách thuộc tính; ghi định nghĩa từng thuộc tính
Có hai nơi cùng sửa dữ liệu	Nơi nào quyết định khi giá trị mâu thuẫn?	Chỉ định nguồn canonical và hướng đồng bộ
Rule chỉ tồn tại trong lời nói hoặc chat	Rule có ID, owner, điều kiện và test evidence không?	Ghi vào CANONICAL_BUSINESS_RULES theo phạm vi được kiểm soát
Test pass nhưng báo cáo sai	Test kiểm tra business outcome hay chỉ response kỹ thuật?	Bổ sung dữ liệu biên và kiểm tra báo cáo
Người triển khai tự chọn nghĩa dữ liệu	Ai có thẩm quyền quyết định nghĩa và lifecycle dữ liệu?	Escalate đúng Data Owner hoặc Business Owner

Quick Reference

• Một field, một nghĩa chính. Nếu cần nhiều nghĩa, tách field.
• Một master domain, một nguồn canonical.
• Không dùng display text làm khóa liên kết.
• Không xóa master đã có lịch sử giao dịch; retire có kiểm soát.
• Mọi sửa data model phải kiểm tra dictionary, rule, API/schema, báo cáo và test evidence.

Core

[!WARNING] Sai dữ liệu master (dữ liệu dùng chung, như mã hàng, đơn vị tính, nhà cung cấp) có thể làm sai tồn kho, giá trị VND, truy xuất lô và chứng từ. Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp; không dùng ví dụ này làm cấu hình production.

Rủi ro thật	Ví dụ lỗi tại Nova Foods mô phỏng	Dấu hiệu quan sát được	Hành động khôi phục an toàn	Ranh giới an toàn
Gộp sai mã hàng	RM-SUGAR-001 bị đổi tên thành “Đường”, trùng nghĩa nhưng không chứng minh cùng quy cách	Hai mã cùng xuất hiện trên báo cáo tồn	Khóa tạo giao dịch mới cho mã nghi vấn; đối chiếu lịch sử, quy cách, đơn vị tính; lập quyết định hợp nhất bởi Data Owner	Không tự gộp, xóa hoặc đổi mã đã có giao dịch
Đổi đơn vị tính không kiểm soát	Đơn vị cơ sở của nguyên liệu đổi từ KG sang G sau khi đã ghi nhận tồn	Tồn kho hoặc định mức tăng/giảm 1.000 lần	Dừng interface liên quan; khôi phục bản sao dữ liệu đã kiểm soát; kiểm tra giao dịch ảnh hưởng trước khi mở lại	Không sửa trực tiếp số dư để “cân” báo cáo
Gán sai trạng thái hiệu lực	Nhà cung cấp tổng hợp SUP-00027 bị đặt Inactive khi còn đơn mua mở	Đơn mua mới bị chặn, đơn cũ lỗi đồng bộ	Khôi phục trạng thái trước thay đổi; xác định đơn mở và interface lỗi; ghi nhận change log	Không kích hoạt lại nếu có cờ rủi ro từ Security, Legal hoặc Procurement Owner
Mất liên kết truy xuất lô	Mã thành phẩm không còn liên kết với nhóm truy xuất lô	Báo cáo không truy được lô nguyên liệu đầu vào	Chặn phát hành lô mới thuộc phạm vi lỗi; tái lập liên kết từ artifact kiểm soát; kiểm tra mẫu giao dịch	Không tuyên bố đáp ứng yêu cầu an toàn thực phẩm; cần domain-owner và legal verification

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Phát hiện sai dữ liệu master] --> B{Có giao dịch hoặc interface bị ảnh hưởng?}

    B -- Không --> C[Đính chính bản ghi qua change log]

    B -- Có --> D[Khóa thay đổi và giao dịch mới trong phạm vi lỗi]
    D --> E{Interface thuộc phạm vi ảnh hưởng?}
    E -- Có --> F[Dừng interface liên quan]
    E -- Không --> G[Đối chiếu bản ghi, lịch sử thay đổi, dữ liệu liên quan]
    F --> G

    G --> H{Loại rủi ro?}

    H -- Gộp sai mã hàng --> I[Đối chiếu lịch sử, quy cách và đơn vị tính]
    I --> J[Data Owner quyết định hợp nhất hoặc giữ nguyên<br/>Không tự gộp, xóa hoặc đổi mã đã có giao dịch]
    J --> K[Ghi nhận change log]
    K --> L[Kiểm tra giao dịch và interface bị ảnh hưởng]

    H -- Đổi đơn vị tính --> M[Chỉ khôi phục dữ liệu thuộc phạm vi lỗi từ bản sao đã kiểm soát<br/>Không sửa trực tiếp số dư để “cân” báo cáo]
    M --> N[Kiểm tra giao dịch và interface bị ảnh hưởng]
    N --> O[Xác nhận an toàn trước khi khởi động lại]
    O --> P[Mở lại phạm vi đã kiểm tra]

    H -- Trạng thái nhà cung cấp --> Q[Procurement Owner xem xét đơn mua mở và interface lỗi]
    Q --> R{Còn cờ Security, Legal hoặc Procurement Owner?}
    R -- Có --> S[Giữ trạng thái Inactive và xử lý cờ rủi ro]
    R -- Không --> T[Khôi phục trạng thái trước thay đổi]
    T --> U[Ghi nhận change log]
    U --> L

    H -- Truy xuất lô --> V[Chặn phát hành lô mới trong phạm vi lỗi]
    V --> W[Tái lập liên kết từ artifact kiểm soát]
    W --> X[Kiểm tra mẫu giao dịch]
    X --> Y[Domain Owner và Legal verification]
    Y --> Z{Verification đạt?}
    Z -- Có --> AA[Ghi nhận change log]
    AA --> P
    Z -- Không --> AB[Giữ khóa; không tuyên bố đáp ứng yêu cầu an toàn thực phẩm]

    H -- Khác --> AC[Data Owner quyết định sửa hoặc giữ nguyên]
    AC --> AD[Ghi nhận change log]
    AD --> L

    L --> P

Applied

Facts: Nova Foods mô phỏng phát hiện FG-JUICE-330ML có đơn vị tính bán hàng BOX, nhưng quy đổi 1 BOX = 6 EA bị sửa thành 1 BOX = 12 EA. Báo cáo tồn khả dụng theo BOX vì vậy giảm một nửa.

Current Behavior: ERP tiếp tục quy đổi theo giá trị mới. Không có bằng chứng trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md rằng 12 EA là giá trị đúng.

Underlying Need: Khôi phục tính nhất quán dữ liệu trước khi tạo đơn mới, đồng thời giữ lịch sử để điều tra. Suy luận: số quy đổi tác động trực tiếp phép tính tồn theo đơn vị bán; sửa đè không lưu dấu sẽ làm mất khả năng giải thích chênh lệch.

Options: (1) sửa ngay về 6 EA; (2) khóa mã hàng, kiểm tra change log và giao dịch từ thời điểm sửa; (3) tạo mã hàng mới. Phương án (2) an toàn hơn vì giá trị đúng chưa được chứng minh và có thể đã phát sinh giao dịch theo giá trị sai.

Decision Criteria: Có nguồn canonical chứng minh quy đổi; số giao dịch bị ảnh hưởng; khả năng đảo hoặc điều chỉnh giao dịch; quyết định Data Owner; ảnh hưởng interface kho và bán hàng.

Decision: Khóa giao dịch mới cho FG-JUICE-330ML; giữ nguyên lịch sử; Data Owner xác minh quy đổi từ nguồn được kiểm soát; thực hiện sửa có change log; kiểm tra lại giao dịch và interface trong phạm vi ảnh hưởng.

Authority: Data Owner quyết định giá trị master data. Business Owner xác nhận nhu cầu vận hành. Architect đánh giá interface. QA xác nhận kiểm tra. BA không tự xác nhận 6 EA hoặc 12 EA là đúng.

Artifact: Ghi issue và liên kết đến CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY; status vẫn IN_REVIEW, version v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Tồn khả dụng sai, đơn bán hứa sai số lượng, điều chỉnh kho sai VND. Đây là rủi ro vận hành; không phải lỗi trình bày.

Senior Lens

Chỉ dùng cảnh báo khi hậu quả có thể gây mất dữ liệu, sai giao dịch, sai phân quyền, sai tích hợp, sai truy xuất hoặc quyết định vận hành sai. Không dùng cảnh báo cho lỗi chính tả, thuật ngữ chưa thống nhất, hoặc nội dung cần làm rõ nhưng chưa tác động dữ liệu.

Khôi phục an toàn luôn giữ ba thứ: bản ghi gốc, lịch sử thay đổi và phạm vi ảnh hưởng. “Sửa cho khớp” không phải khôi phục nếu không biết giá trị nào đúng, ai có thẩm quyền xác nhận, và giao dịch nào đã dùng giá trị sai.

Quick Reference

Quy tắc	Áp dụng
Khóa phạm vi lỗi trước, không khóa toàn hệ thống nếu chưa có bằng chứng	Giảm lan truyền sai dữ liệu
Không xóa mã master đã có giao dịch	Giữ audit trail và traceability
Không tự suy diễn yêu cầu pháp lý, kế toán, thuế hoặc an toàn thực phẩm	Chuyển Legal, Accounting hoặc domain owner xác minh
Mở lại giao dịch chỉ sau kiểm tra dữ liệu và interface bị ảnh hưởng	Ngăn lỗi lặp lại

Core

Năm lỗi phải tách riêng vì cách sửa khác nhau. Mơ hồ là câu có nhiều cách hiểu hợp lý. Không đầy đủ là thiếu dữ kiện để thực hiện hoặc kiểm thử. Khẳng định thẩm quyền không có bằng chứng là gán quyết định cho vai trò, luật, hoặc nguồn chưa xác minh. Dùng sai ký pháp là gọi sai loại sơ đồ hoặc diễn giải sai ý nghĩa ký hiệu. Đứt truy vết là không nối được yêu cầu, quy tắc, dữ liệu, nguồn và kiểm thử bằng ID canonical.

Loại lỗi	Dấu hiệu quan sát được	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp	Sửa đúng
Mơ hồ	Từ “hợp lệ”, “đủ”, “kịp thời” không có điều kiện đo	ProductCode phải hợp lệ	Nêu tập giá trị, định dạng, nguồn kiểm tra, thời điểm kiểm tra
Không đầy đủ	Có trường nhưng thiếu kiểu dữ liệu, độ dài, bắt buộc, owner	SupplierTaxCode được ghi nhưng không rõ có bắt buộc	Ghi thuộc tính logic và trạng thái Verification required nếu chưa có nguồn quyết định
Thẩm quyền không có bằng chứng	Câu “Luật yêu cầu” nhưng không có nguồn chính thức và Legal Owner	BA ghi mã lô phải giữ 10 năm	Đổi thành giả định dự án; chuyển Legal Owner và Food-safety Owner xác minh
Sai ký pháp	Sơ đồ hoạt động PlantUML bị gọi là BPMN	Mũi tên activity diagram được ghi là BPMN sequence flow	Gọi đúng PlantUML activity diagram; chỉ gọi BPMN khi dùng ký pháp BPMN 2.0.2
Đứt truy vết	ID tự đặt, liên kết tới tên tệp rút gọn, thiếu nguồn	BR-LOT-01 không đăng ký trong TRACEABILITY_ID_REGISTRY	Dùng ID đã đăng ký; liên kết artifact canonical và trạng thái nguồn

Applied

Trường	Nội dung
Facts	Nova Foods là case mô phỏng. Dòng dữ liệu LotCode được đề xuất cho FinishedGoodLot; CANONICAL_DATA_DICTIONARY đang IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	Bản nháp ghi: “LotCode chuẩn theo luật và được QA phê duyệt.” Không có URL luật, không có approval reference, không có ID quy tắc đăng ký.
Underlying Need	Hệ thống cần nhận diện lô thành phẩm nhất quán để liên kết sản xuất, tồn kho và truy vết mô phỏng. Nhu cầu này suy ra từ tên thuộc tính và quan hệ dữ liệu; chưa suy ra được thời hạn lưu, định dạng hay nghĩa vụ pháp lý.
Options	(1) Chốt định dạng LotCode như rule bắt buộc. (2) Ghi định dạng là giả định dự án. (3) Chỉ mô tả thuộc tính logic, chờ owner xác minh rule.
Decision Criteria	Có nguồn canonical; ID có trong TRACEABILITY_ID_REGISTRY; thẩm quyền Business Owner, Food-safety Owner hoặc Legal Owner được ghi nhận; không nhầm IN_REVIEW với approval.
Decision	Chọn (3). Ghi LotCode là thuộc tính logic; mọi rule định dạng và lưu giữ là Verification required.
Authority	Principal IT Business Analyst / Technical Curriculum Author chỉ giữ governance. Không có bằng chứng Business Owner, Food-safety Owner hoặc Legal Owner đã quyết định.
Artifact	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Consequence if Wrong	Rule sai có thể tạo lô không đối soát được, test sai basis, hoặc diễn đạt giả định học liệu thành nghĩa vụ pháp lý.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Phát hiện mô tả LotCode] --> B{Có nguồn canonical và ID trong TRACEABILITY_ID_REGISTRY?}
    B -- Không --> C[Giữ LotCode là thuộc tính logic]
    C --> D[Đánh dấu rule định dạng và lưu giữ: Verification required]
    D --> E[Không tạo rule pháp lý, approval, baseline hoặc cấu hình ERP]
    B -- Có --> F{Business Owner, Food-safety Owner hoặc Legal Owner có authority và approval reference ghi nhận?}
    F -- Không --> C
    F -- Có --> H{Nhãn và liên kết tới artifact canonical đúng?}
    H -- Không --> I[Sửa nhãn và khôi phục liên kết artifact canonical]
    I --> H
    H -- Có --> J[Đạt kiểm tra governance]
    M[Artifact trạng thái IN_REVIEW] --> N[IN_REVIEW không đồng nghĩa đã phê duyệt]
    N --> C
    O[Áp rule sai] --> P[Lô không đối soát được]
    O --> Q[Test sai basis]
    O --> R[Biến giả định học liệu thành nghĩa vụ pháp lý]
    L[Principal IT Business Analyst / Technical Curriculum Author] -. Chỉ giữ governance .-> F

[!WARNING] Không nâng IN_REVIEW thành “đã phê duyệt”. IN_REVIEW chỉ nói artifact đang được xem xét. Ranh giới phục hồi an toàn: sửa nhãn, khôi phục liên kết tới artifact canonical, ghi Verification required; không tự tạo approval, baseline, rule pháp lý hoặc cấu hình ERP.

Senior Lens

Chuỗi bằng chứng phải đi từ phát biểu tới nguồn, ID, artifact và owner thẩm quyền. Nếu thiếu một mắt xích, BA không lấp bằng kinh nghiệm cá nhân. Ví dụ, Luật An toàn thực phẩm là bối cảnh nguồn chính thức cho truy vết và thu hồi, nhưng chi tiết requirement hệ thống vẫn cần Food-safety Owner và Legal Owner xác minh. Đây là khác biệt giữa nguồn tham khảo và quyết định áp dụng.

Quick Reference

Kiểm tra trước khi giữ một dòng data model	Đạt khi
Nghĩa	Một người đọc nêu được cùng điều kiện và kết quả
Đủ dữ liệu	Có entity, thuộc tính, định nghĩa, nguồn và trạng thái xác minh
Thẩm quyền	Không gán quyết định cho owner chưa có bằng chứng
Ký pháp	Tên sơ đồ khớp chuẩn đã dùng
Truy vết	ID và đường dẫn giữ nguyên: CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES

11. Senior BA Notes & Rules of Thumb

Senior Lens

Data model không phải danh sách cột. Nó là quyết định: dữ liệu nào được xem là cùng một đối tượng, ai được sửa, thay đổi nào phải giữ lịch sử, và hệ thống nào là nguồn sự thật. Với Nova Foods là case study mô phỏng, dữ liệu đều tổng hợp. Senior BA tách rõ evidence (bằng chứng), inference (suy luận từ bằng chứng) và decision (quyết định thuộc thẩm quyền).

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Phát biểu nhu cầu dữ liệu] --> B[Senior BA thu thập evidence]
    B --> C{Evidence đủ và nhất quán?}

    C -- Không --> D[Ghi Verification required<br/>và khoảng trống]
    D --> E[Chuyển yêu cầu xác minh<br/>đến authority phù hợp]
    E --> U2[Ghi recommendation có điều kiện<br/>Inference, không phải decision]

    C -- Có --> H[Phân tích lựa chọn<br/>và tác động: Inference]
    H --> I[Chọn authority theo phạm vi<br/>không mặc định tất cả owner]

    I -- nếu thuộc phạm vi --> J[Business Owner<br/>nghĩa và ưu tiên]
    I -- nếu thuộc phạm vi --> K[Data Owner<br/>chất lượng và stewardship]
    I -- nếu thuộc phạm vi --> L[Architect<br/>tích hợp và nguồn sự thật]
    I -- nếu thuộc phạm vi --> M[Legal Owner<br/>nghĩa vụ pháp lý]
    I -- nếu thuộc phạm vi --> N[Accounting Owner<br/>nghĩa vụ hạch toán]
    I -- nếu thuộc phạm vi --> O[Food-safety Owner<br/>nghĩa vụ an toàn thực phẩm]

    J --> P[Senior BA tổng hợp authority review]
    K --> P
    L --> P
    M --> P
    N --> P
    O --> P

    P --> Q{Đề xuất thuộc phạm vi<br/>từ hai authority trở lên?}
    Q -- Có --> R[Escalation:<br/>điều phối decision giữa<br/>authority liên quan]
    Q -- Không --> S[Authority liên quan xem xét]

    R --> T{Còn xung đột hoặc<br/>chưa có decision?}
    T -- Có --> U2
    T -- Không --> X{Kết quả từ authority?}
    S --> X

    X -- Xác nhận decision --> U1[Ghi decision đã được<br/>authority xác nhận]
    X -- Từ chối recommendation --> U3[Ghi recommendation bị từ chối<br/>và authority quyết định]
    X -- Yêu cầu thêm evidence --> D
    X -- Chưa có decision --> U2

    U2 --> V2[Lưu traceability trạng thái chờ:<br/>evidence, inference, authority<br/>và khoảng trống]
    V2 --> G[Chờ verification hoặc decision]
    G --> W{Verification hoặc decision<br/>đã đến?}
    W -- Verification --> B
    W -- Decision --> X

    U1 --> V[Lưu traceability kết quả:<br/>evidence, inference, status,<br/>authority và khoảng trống]
    U3 --> V

Điểm review senior	Trade-off cần nêu	Không áp dụng quy tắc thường khi	Authority quyết định
Một Customer dùng một khóa canonical	Khóa chung giảm trùng lặp; sai hợp nhất làm lộ hoặc gộp nhầm dữ liệu	Hai pháp nhân, kênh bán hoặc chính sách định danh chưa xác minh là cùng khách hàng	Business Owner và Data Owner
Sửa LotCode thay vì tạo bản ghi mới	Sửa trực tiếp dễ vận hành; mất lịch sử truy vết	Thu hồi, kiểm soát chất lượng hoặc đối soát cần biết giá trị tại thời điểm trước	Food-safety Owner, Quality Owner
Đặt giá bán trong Product	Đọc nhanh; không biểu diễn được thời hạn, kênh, khách hàng	Giá thay đổi theo ngày hiệu lực, đơn vị bán, chương trình hoặc khách hàng	Sales Owner, Finance Owner
ERP là source of truth	Giảm xung đột; có thể không phù hợp dữ liệu do hệ thống chuyên ngành sở hữu	MES, WMS hoặc hệ thống đối tác tạo dữ liệu gốc và có bằng chứng ownership	Architect và Data Owner
Dùng mã nghiệp vụ làm primary key	Dễ đọc; mã có thể đổi theo chính sách	Mã được tái sử dụng, đổi cấu trúc hoặc chứa ý nghĩa nghiệp vụ biến động	Data Owner, Architect

Xung đột stakeholder thường không phải tranh luận “bảng nào đúng”. Sales có thể muốn một Customer duy nhất để xem doanh số; Finance có thể cần tách thực thể thanh toán; Security có thể yêu cầu hạn chế người xem thông tin liên hệ. Senior BA không chọn theo người nói lớn nhất. BA lập bảng tác động: mục tiêu, bằng chứng, rủi ro nếu sai, dữ liệu bị ảnh hưởng, authority. Nếu một lựa chọn chạm đồng thời dữ liệu cá nhân, hạch toán hoặc truy vết thực phẩm, phải escalation. Lý do: TRACEABILITY_ID_REGISTRY quy định escalation khi đề xuất thuộc từ hai authority trở lên; BA giữ traceability, không thay kết luận chuyên môn.

Red flag: yêu cầu dùng từ “luôn”, “mọi”, “không bao giờ” nhưng không có phạm vi; tên field trùng nghĩa khác nhau như CustomerCode và CustomerID; nguồn dữ liệu được gọi canonical chỉ vì đang được dùng nhiều; rule pháp lý được ghi thành cấu hình ERP mà chưa có Legal Owner xác minh. Khi gặp các dấu hiệu này, không chuẩn hóa bằng giả định ngầm.

Khuyến nghị có thể phòng vệ phải ghi mức chắc chắn. Ví dụ: “Khuyến nghị giữ LotCode bất biến sau khi phát hành, vì yêu cầu truy vết cần liên kết ổn định giữa lô, giao dịch và sự kiện chất lượng. Bằng chứng hiện có: nhu cầu truy vết được nêu trong phạm vi case study và Luật An toàn thực phẩm là nguồn bối cảnh chính thức. Chi tiết nghĩa vụ hệ thống: Verification required bởi Food-safety Owner và Legal Owner.” Câu này nêu lý do, giới hạn bằng chứng và người có quyền quyết định; không biến suy luận thành fact hay approval.

Senior Lens

Senior BA rà mô hình dữ liệu và master data theo bằng chứng, không theo số người đồng ý. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES đang IN_REVIEW, v0.9.0, ngày 2026-08-07, chưa phải baseline hay phê duyệt.

Heuristic rà soát	Cách kiểm tra	Red flag	Ngưỡng escalation
Một khái niệm, một nguồn canonical	So Customer, Supplier, Item, UoM giữa UI, API, báo cáo và từ điển dữ liệu	Cùng mã có hai nghĩa; hai mã cùng đại diện một đối tượng	Escalate khi ảnh hưởng khóa tích hợp, báo cáo tài chính, truy xuất lô hoặc migration
Thuộc tính phải có owner nghiệp vụ	Mỗi field có Business Owner hoặc Data Steward chịu trách nhiệm chất lượng	Field bắt buộc nhưng không ai sửa được; nhiều nhóm cùng sửa	Escalate khi ownership xung đột hoặc quyền sửa tạo rủi ro gian lận
Master data khác transaction data	Master data mô tả thực thể ổn định; transaction ghi nhận sự kiện theo thời điểm	Dùng giá hiện hành để thay giá đã chốt trên đơn; sửa tên hàng làm sai chứng từ cũ	Escalate khi cần lịch sử, audit, kế toán hoặc truy xuất nguồn gốc
Mã định danh không mang logic dễ đổi	Kiểm tra ID không nhúng tên tỉnh, phòng ban, năm hoặc trạng thái	ITEM-HCM-2026-001 thành vô nghĩa khi đổi kho, địa bàn hoặc năm	Escalate khi ID đã đi qua API, file import hoặc dữ liệu lịch sử
Quy tắc kiểm tra đặt gần nguồn lỗi nhất	Ưu tiên DB constraint, unique key, foreign key trước kiểm tra giao diện	API hoặc batch import bỏ qua kiểm tra UI	Escalate khi một kênh tạo dữ liệu không áp dụng cùng rule
Giá trị danh mục có vòng đời	Xác định trạng thái active/inactive và ngày hiệu lực nếu nghiệp vụ cần	Xóa cứng mã đã được tham chiếu; tái sử dụng mã cũ	Escalate khi có chứng từ, tồn kho, lô hàng hoặc tích hợp tham chiếu mã

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Đề xuất field hoặc master data] --> B{Có khái niệm canonical?}
    B -- Có --> C[Đối chiếu CANONICAL_DATA_DICTIONARY<br/>IN_REVIEW v0.9.0: chỉ là bằng chứng rà soát,<br/>không phải nguồn đã phê duyệt]
    B -- Không --> D[Đăng ký vấn đề dữ liệu]
    C --> E{Có tác động lịch sử, tích hợp, pháp lý,<br/>kế toán, security hoặc food traceability?}
    D --> E
    E -- Có --> F[Escalate Business, Data, Architect, Legal,<br/>Accounting hoặc Security Owner theo tác động]
    E -- Không --> G[Senior BA rà uniqueness, owner,<br/>validation và lifecycle]
    G --> I{Migration không map được vượt 1%<br/>mẫu hoặc hai owner có rule trái ngược?}
    I -- Có --> F
    I -- Không --> J{Có exception: legacy_id, party chung,<br/>supplier item reference, dữ liệu cá nhân<br/>hoặc snapshot chứng từ?}
    J -- Có --> K[Xử lý theo exception và owner có thẩm quyền]
    J -- Không --> H[Chỉ ghi nhận quyết định khi owner<br/>có thẩm quyền xác nhận]
    F --> H
    K --> H

Điều kiện	Không áp dụng quy tắc thường dùng	Lý do và xử lý
Dữ liệu lịch sử từ hệ cũ thiếu khóa ổn định	Không ép chuẩn hóa đầy đủ trước migration	Giữ legacy_id, ghi mapping và mức tin cậy; không tự suy ra liên kết
Một khách hàng vừa mua vừa bán	Không tạo hai thực thể độc lập chỉ vì hai quy trình	Dùng party dùng chung, tách vai trò Customer và Supplier nếu evidence cho thấy cùng pháp nhân
Mã hàng nhà cung cấp thay đổi theo hợp đồng	Không dùng mã nhà cung cấp làm Item ID nội bộ	Giữ mã nội bộ ổn định; quản lý supplier item reference có hiệu lực thời gian
Trường có khả năng là dữ liệu cá nhân	Không coi là field nghiệp vụ thông thường	Escalate Legal/Privacy Owner; Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP cần xác minh bởi owner có thẩm quyền
Giá trị cần giữ nguyên trên chứng từ	Không đọc lại master data hiện hành khi hiển thị lịch sử	Lưu snapshot transaction; Accounting Owner xác minh nếu tác động hạch toán theo Luật Kế toán

Escalate ngay khi một field đồng thời tác động accounting, legal, security, integration hoặc food traceability; khi tỷ lệ bản ghi không map được vượt 1% mẫu migration; hoặc khi hai owner đưa rule trái ngược. Senior BA lập issue có ID traceability, evidence nguồn, dữ liệu mẫu tổng hợp, tác động và câu hỏi quyết định. Senior BA không tự chọn thay Business Owner, Architect, Legal Owner, Accounting Owner, Security Owner hoặc Data Owner.

Senior Lens

Senior BA không biến dữ liệu chưa đủ thành kết luận chắc chắn. Với Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp chỉ chứng minh tình huống học tập; không chứng minh cấu hình ERP, tuân thủ pháp lý hay quyết định vận hành thật. Khuyến nghị phải tách rõ fact (sự kiện có nguồn), assumption (giả định dự án), unknown (chưa biết), và Verification required (cần vai trò có thẩm quyền xác minh).

Thành phần ghi nhận	Cách viết phòng thủ được	Cách viết không được
Sự kiện	“CANONICAL_DATA_DICTIONARY đang IN_REVIEW, v0.9.0, ngày 2026-08-07; chưa có baseline reference.”	“Từ điển dữ liệu đã chốt.”
Suy luận	“Vì chưa có baseline reference, không nên dùng thuộc tính master data làm cam kết build.”	“ERP chắc chắn sẽ dùng cấu trúc này.”
Giả định	“Project assumption: mã hàng có một đơn vị tính cơ sở; cần Business Owner xác minh.”	“Mã hàng luôn chỉ có một đơn vị tính.”
Điều cần xác minh	“Verification required: Accounting Owner xác minh cách hạch toán; Legal Owner xác minh nghĩa vụ pháp lý.”	“BA xác nhận quy định kế toán/pháp lý.”
Khuyến nghị	“Khuyến nghị giữ trường trạng thái IN_REVIEW; chưa khóa giá trị until authority record exists.”	“Phê duyệt dùng ngay.”

Ghi khuyến nghị theo chuỗi bằng chứng: nguồn nào nói gì, phần nào suy ra từ nguồn, phần nào chưa được nguồn phủ. Ví dụ: CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES đều ở IN_REVIEW; vì vậy BA có thể đề xuất cấu trúc logic cho master data, nhưng không thể gọi cấu trúc đó là baseline hay yêu cầu production. Đây là suy luận từ trạng thái quản trị đã ghi nhận, không phải đánh giá chất lượng nghiệp vụ.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Identify claim and controlled or verified source] --> B{Source metadata recorded?<br/>Path, status, version, date}

    B -->|No| B1[Record missing metadata<br/>and Verification required]
    B1 --> U[Record residual uncertainty]

    B -->|Yes| C{Source supports claim scope?}
    C -->|Yes| D[Record fact and source-supported inference]
    D --> U

    C -->|No or incomplete| E{Explicit project assumption?}
    E -->|Yes| F[Record assumption and required owner confirmation]
    F --> F1[Keep conclusion conditional;<br/>do not call it source-supported]
    F1 --> U

    E -->|No| G[Record unknown and Verification required]
    G --> G1[Do not infer unsupported conclusion]
    G1 --> U

    U --> H[State conditional recommendation<br/>and scope boundary]

    H --> I[Identify applicable scopes and owners:<br/>Business Owner, Architect, Accounting Owner,<br/>Legal Owner, Security, Compliance]

    I --> J[For each applicable scope,<br/>record owner separately]
    J --> K{Per-scope outcome?}

    K -->|Verified| L[Record verification or decision reference<br/>for this scope]
    K -->|Rejected| M[Record rejection status, scope,<br/>owner, and reference]
    K -->|Cannot verify| N[Record unknown and Verification required<br/>for this scope]
    K -->|Pending| O[Record pending verification or decision<br/>for this scope]

    L --> L1[Reference does not itself grant approval]
    L1 --> P{Governance authority record<br/>for this scope?}
    P -->|Approval reference| Q[Mark this scope APPROVED]
    P -->|Baseline reference| R[Mark this scope BASELINED]
    P -->|None| S[Keep this scope IN_REVIEW]

    M --> M1[Keep this scope rejected;<br/>do not claim approval]
    N --> N1[Keep this scope IN_REVIEW]
    O --> O1[Keep this scope IN_REVIEW]

    Q --> T[Add per-scope status and reference<br/>to outcome set]
    R --> T
    S --> T
    M1 --> T
    N1 --> T
    O1 --> T

    T --> V{More applicable scopes?}
    V -->|Yes| J
    V -->|No| W[Summarize mixed outcomes<br/>without promoting unresolved scopes]

    M1 --> X[Do not use rejected scope as build commitment,<br/>production configuration, or compliance claim]
    S --> Y[Do not use IN_REVIEW scope as build commitment,<br/>production configuration, or compliance claim]
    N1 --> Y
    O1 --> Y

    W --> Z[Only scopes with recorded approval or baseline reference<br/>are APPROVED or BASELINED]
    Z --> AA[APPROVED or BASELINED does not inherently prove<br/>legal compliance, production readiness, or ERP configuration]

Mẫu ghi nhận dùng trong review note:

Trường	Nội dung mẫu
Evidence	/01-curriculum/CANONICAL_DATA_DICTIONARY.md, Status IN_REVIEW, Version v0.9.0, date 2026-08-07
Observation	Chưa thấy baseline reference hoặc approval reference trong dependency được cung cấp.
Inference	Thiết kế master data chỉ là kế hoạch học liệu; chưa đủ căn cứ để khóa mapping ERP.
Recommendation	Duy trì thuộc tính và quy tắc ở trạng thái đề xuất; ghi rõ Verification required cho điểm ảnh hưởng kế toán, pháp lý, bảo mật hoặc vận hành.
Decision authority	Business Owner quyết định nhu cầu nghiệp vụ; Architect quyết định khả thi kỹ thuật; Accounting Owner, Legal Owner, Security hoặc Compliance xác minh phần thuộc chuyên môn họ.
Residual uncertainty	Chưa xác minh đơn vị tính, vòng đời mã hàng, quyền sửa dữ liệu và hệ quả hạch toán trong môi trường thực.
Status boundary	IN_REVIEW không phải APPROVED, BASELINED, compliant hay production-ready.

Ngôn ngữ khuyến nghị phải nêu mức chắc chắn: “bằng chứng hiện có hỗ trợ”, “chưa đủ bằng chứng để kết luận”, “đề xuất có điều kiện”, “cần xác minh bởi [vai trò]”. Không ghi “đã được chấp thuận” nếu artifact không có approval reference. Không dùng im lặng để biến giả định thành business rule.

12. Associated Template Reference & Completed Artifact

Core

Template là khuôn điền có cấu trúc. Canonical artifact là nguồn kiểm soát chính thức của một loại thông tin. Hai loại không thay thế nhau.

Bằng chứng: dependency chỉ xác nhận TEMPLATE_MANIFEST là danh mục template dự kiến; không cung cấp ID hoặc đường dẫn của template master-data cụ thể. BA không được tự tạo ID TMPL-*, tên tệp /03-templates/..., hoặc diễn giải template chưa đăng ký thành completed artifact.

Nova Foods Trading & Manufacturing là case study mô phỏng. Mọi dữ liệu là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Status IN_REVIEW, Version v0.9.0, date 2026-08-07 không phải baseline, approval, compliance hay production-ready.

Completed artifact của chapter là worked example đã được điền trong phạm vi học liệu, không phải template master-data được phê duyệt hoặc cấu hình ERP. Artifact này nằm tại /02-handbook/11-data-modeling-and-master-data.md, mục ## 8. Detailed Worked Example. Mục 12 chỉ liên kết, xác định source boundary và kiểm soát cách dùng artifact.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[BA cần ghi master data] --> B{Cần khuôn điền?}

    B -->|Có| C[Tìm ID và file trong TEMPLATE_MANIFEST]
    C --> E{ID và file đã đăng ký?}
    E -->|Có| F[Điền template theo quality gate]
    F --> H[Trace template đã điền tới<br/>canonical artifact của loại thông tin đó]
    E -->|Không| G[Không có template hợp lệ để điền<br/>Không tự tạo TMPL-* hoặc /03-templates/...<br/>Không coi template chưa đăng ký là completed artifact]

    B -->|Không| D[Tham chiếu canonical artifact]
    D --> I[Completed artifact trong phạm vi học liệu:<br/>/02-handbook/11-data-modeling-and-master-data.md<br/>## 8. Detailed Worked Example]
    I --> J[Không phải template master-data phê duyệt<br/>hoặc cấu hình ERP]
    J --> K[IN_REVIEW · v0.9.0 · 2026-08-07<br/>Không phải baseline, approval, compliance<br/>hoặc production-ready]
    I --> L[Canonical source phải được xác định riêng<br/>Worked example không được ngầm coi là canonical artifact]
    I --> M[Nova Foods Trading & Manufacturing là case study mô phỏng<br/>Dữ liệu tổng hợp · vi-VN · Asia/Ho_Chi_Minh · VND]

Applied

Thành phần bắt buộc	Nội dung áp dụng cho Nova Foods mô phỏng
Facts	Có TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md; seed không nêu template ID hay file template riêng cho Data Modeling And Master Data. Có CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md, CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md, và TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Current Behavior	BA dùng artifact canonical để kiểm tra định nghĩa dữ liệu, rule và ID. BA không có căn cứ để điền template master-data xác định. Người học dùng worked example tại mục 8 để hiểu cách áp dụng, không dùng ví dụ này làm template đăng ký.
Underlying Need	Cần biết nơi tìm template được đăng ký và nơi kiểm tra nội dung trước khi tạo field như mã hàng, đơn vị tính, nhóm hàng hoặc trạng thái hiệu lực. Cần tách worked example học liệu khỏi template vận hành và nguồn canonical.
Options	1. Tự đặt template ID và file. 2. Dùng artifact canonical như template. 3. Tra cứu TEMPLATE_MANIFEST, chỉ dùng template khi manifest đăng ký ID và file; dùng mục 8 như completed worked example trong chapter.
Decision Criteria	Giữ đúng ID, file, status và source boundary; không tạo nguồn chân lý thứ hai; không biến kế hoạch thành quyết định ERP; không gọi ví dụ mô phỏng là template đã được phê duyệt.
Decision	Chọn phương án 3. Chưa dùng template master-data cụ thể vì bằng chứng được cung cấp chưa đăng ký template đó. Dùng /02-handbook/11-data-modeling-and-master-data.md, mục ## 8. Detailed Worked Example, làm artifact Nova Foods đã điền trong phạm vi học liệu.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì manifest và traceability. Business Owner xác nhận nhu cầu nghiệp vụ; Architect xác minh mô hình kỹ thuật; Accounting Owner, Legal Owner, Security hoặc Compliance xác minh phần thuộc thẩm quyền. Không vai trò nào trong bảng này tự cấp baseline hoặc approval.
Artifact	Điểm tra cứu template: /01-curriculum/TEMPLATE_MANIFEST.md. Điểm đối chiếu dữ liệu: /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Completed worked example: /02-handbook/11-data-modeling-and-master-data.md, ## 8. Detailed Worked Example.
Consequence if Wrong	Tự tạo ID hoặc file làm đứt traceability, tạo bản sao không kiểm soát, và có thể bị hiểu sai là cấu hình ERP hoặc template đã được phê duyệt. Gọi worked example là canonical artifact hoặc template vận hành làm sai authority, scope và status IN_REVIEW.

Senior Lens

Quality gate là điều kiện tối thiểu trước khi dùng artifact làm đầu vào tiếp theo. Gate không phải approval.

Với template master data, BA chỉ chuyển tiếp khi xác minh được: ID có trong manifest; đường dẫn tệp khớp manifest; owner được chỉ rõ; consumer nhận đúng phạm vi; trường dữ liệu liên kết được dictionary; rule liên kết được rule catalog; và trạng thái IN_REVIEW được giữ nguyên nếu chưa có baseline reference.

Với completed worked example, BA chỉ chuyển tiếp như học liệu khi xác minh được: vị trí artifact là mục 8 của chapter; Nova Foods được ghi là mô phỏng; dữ liệu được ghi là tổng hợp; locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND giữ đúng bối cảnh; ví dụ không tự nhận là cấu hình ERP, quyết định vận hành, baseline hoặc approval.

Không dùng CANONICAL_DATA_DICTIONARY để thay template nhập liệu. Lý do: dictionary mô tả nghĩa logic của dữ liệu, không xác nhận layout, workflow hay quyền vận hành.

Không dùng TRACEABILITY_ID_REGISTRY để quyết định mã hàng. Lý do: registry kiểm soát định danh truy vết, không phải thẩm quyền nghiệp vụ.

Không dùng worked example Nova Foods để xác nhận rule production. Lý do: ví dụ minh họa cách phân tích, không xác nhận hành vi hệ thống thực tế.

Mọi yêu cầu về thuế, kế toán, bảo vệ dữ liệu, an toàn thực phẩm hoặc truy xuất nguồn gốc phải giữ nhãn Verification required khi chưa được owner chuyên môn xác minh từ nguồn chính thức hiện hành.

Quick Reference

ID / file liên quan	Khi dùng	Không dùng khi	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST /01-curriculum/TEMPLATE_MANIFEST.md	Tra cứu template đã đăng ký trước khi tạo hoặc điền khuôn master data.	Không dùng làm template điền dữ liệu hoặc bằng chứng approval.	Principal IT Business Analyst / Technical Curriculum Author	BA, curriculum author, reviewer	ID template, file, dependency và phạm vi phải được manifest ghi nhận; status vẫn IN_REVIEW.
CANONICAL_DATA_DICTIONARY /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Đối chiếu tên, nghĩa, kiểu logic, ownership và boundary của thuộc tính master data.	Không dùng để suy ra schema ERP, API contract hoặc quyền sửa production.	Principal IT Business Analyst / Technical Curriculum Author	BA, Architect, QA, data reviewer	Thuộc tính phải giữ canonical ID; điểm chưa xác minh ghi Verification required.
CANONICAL_BUSINESS_RULES /01-curriculum/CANONICAL_BUSINESS_RULES.md	Đối chiếu rule áp dụng cho tạo, sửa, hiệu lực hoặc kiểm soát master data.	Không dùng để tự xác nhận rule là quyết định vận hành thực.	Principal IT Business Analyst / Technical Curriculum Author	Business Owner, BA, QA, Accounting Owner, Legal Owner	Rule giữ đúng canonical ID, authority và trạng thái; rule pháp lý hoặc kế toán cần owner chuyên môn xác minh.
TRACEABILITY_ID_REGISTRY /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra ID requirement, rule, data element và liên kết giữa artifact.	Không dùng để cấp ID mới ngoài registry hoặc quyết định nghĩa nghiệp vụ.	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, Architect	Không có ID trùng; liên kết nguồn rõ; mâu thuẫn ID phải escalation.
/02-handbook/11-data-modeling-and-master-data.md, ## 8. Detailed Worked Example	Đọc completed worked example Nova Foods để học cách áp dụng mô hình dữ liệu và master data.	Không dùng như template master-data đăng ký, canonical source, cấu hình ERP hoặc bằng chứng approval.	Principal IT Business Analyst / Technical Curriculum Author	Người học, BA, reviewer	Giữ phạm vi mô phỏng, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND.
Template master-data cụ thể	Chỉ dùng sau khi TEMPLATE_MANIFEST ghi rõ template ID và đường dẫn canonical.	Không tự tạo, đoán tên tệp, hoặc gọi template chưa đăng ký là completed artifact.	Owner được manifest chỉ định	BA và consumer được manifest chỉ định	ID, file, owner, consumer và gate phải có bằng chứng trong manifest.

Quick Reference

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Artifact đã điền của chapter là worked example tại /02-handbook/11-data-modeling-and-master-data.md, mục ## 8. Detailed Worked Example.

Lý do: mục 8 là vị trí blueprint dành cho ví dụ hoàn chỉnh. Mục 12 chỉ tra cứu, liên kết và kiểm soát source boundary; mục 12 không tạo template master-data mới, không tạo canonical data source thứ hai, không xác nhận approval.

Core

Danh sách tra cứu đầy đủ cho chapter này:

Điểm cần tra	Vị trí canonical	Kiểm tra phải đạt
Cấu trúc 12 mục chapter	/02-handbook/11-data-modeling-and-master-data.md	Có đủ mục 1 đến 12, tiêu đề giữ đúng blueprint
Case đã điền Nova Foods	/02-handbook/11-data-modeling-and-master-data.md, ## 8. Detailed Worked Example	Nêu rõ mô phỏng, dữ liệu tổng hợp, không diễn giải thành ERP thực tế, template vận hành, baseline hoặc approval
Định nghĩa logical data dictionary, từ điển dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Dùng đúng Artifact ID CANONICAL_DATA_DICTIONARY; không tự đặt tên thực thể, trường, kiểu dữ liệu canonical
Định danh truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID được tham chiếu nguyên dạng; không dùng ID chưa đăng ký
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Không biến ví dụ học liệu thành business rule canonical
Danh mục chapter	/01-curriculum/CHAPTER_MANIFEST.md	Đường dẫn và phạm vi chapter khớp manifest
Danh mục template dự kiến	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ dùng để tra template đã đăng ký; không coi kế hoạch template là artifact đã hoàn tất
Nguồn và ranh giới sử dụng nguồn	/00-research/00_SOURCE_MAP.md	Nguồn pháp lý, chuẩn, good practice giữ đúng phân loại và safe use boundary

flowchart TD
    A[Người học cần tra dữ liệu chapter 11] --> B{Cần ví dụ Nova Foods đã điền?}
    B -->|Có| C[/02-handbook/11-data-modeling-and-master-data.md<br/>Mục 8]
    B -->|Không| D{Cần nguồn canonical?}
    D -->|Định nghĩa dữ liệu| E[CANONICAL_DATA_DICTIONARY]
    D -->|ID truy vết| F[TRACEABILITY_ID_REGISTRY]
    D -->|Quy tắc nghiệp vụ| G[CANONICAL_BUSINESS_RULES]
    D -->|Phạm vi chapter hoặc template| H[CHAPTER_MANIFEST hoặc TEMPLATE_MANIFEST]

Applied

Facts: Chapter 11 dạy mô hình dữ liệu và master data; artifact Nova Foods đã điền là worked example nằm trong mục 8 của cùng tệp. CANONICAL_DATA_DICTIONARY là nguồn quy hoạch canonical, không phải cấu hình ERP production. TEMPLATE_MANIFEST là danh mục template dự kiến; bằng chứng hiện có không nêu template ID hoặc file riêng cho Data Modeling And Master Data.

Current Behavior: Người học đọc thực thể, thuộc tính, khóa định danh và quan hệ trong ví dụ mục 8, rồi tra artifact canonical khi cần xác minh ID hoặc nghĩa thuật ngữ. BA không dùng mục 8 để tạo template mới, cấp ID hoặc xác nhận rule vận hành.

Underlying Need: Tách ví dụ học tập khỏi nguồn chân lý quản trị. Bằng chứng: CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY và CANONICAL_DATA_DICTIONARY đều là artifact kiểm soát IN_REVIEW, v0.9.0, ngày 2026-08-07.

Options: Tra riêng mục 8; sao chép toàn bộ registry vào chapter; hoặc liên kết mục 8 với artifact canonical.

Decision Criteria: Không nhân bản nguồn chân lý; giữ canonical ID; người mới tìm được ví dụ đã điền; không suy ra baseline, approval hay cấu hình thực; không gọi worked example là template master-data đã đăng ký.

Decision: Dùng mục 8 làm vị trí artifact Nova Foods đã điền trong phạm vi học liệu. Dùng các tệp canonical trong bảng tra cứu cho xác minh chi tiết. Chưa xác định template master-data cụ thể vì TEMPLATE_MANIFEST chưa cung cấp template ID và đường dẫn tương ứng.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Vai trò này không xác nhận rule nghiệp vụ, pháp lý, kế toán, bảo mật hoặc vận hành thực tế. Business Owner, Legal Owner, Accounting Owner, Security, Architect và QA reviewer xác minh nội dung thuộc thẩm quyền của họ.

Artifact: /02-handbook/11-data-modeling-and-master-data.md, ## 8. Detailed Worked Example.

Consequence if Wrong: Sao chép registry vào chapter gây lệch phiên bản; gọi ví dụ là canonical gây nhầm thẩm quyền; gọi ví dụ là template đã đăng ký gây nhầm file và owner; dùng dữ liệu mô phỏng như cấu hình thật có thể tạo quyết định ERP sai.

Senior Lens

Quy tắc tra cứu: chapter giải thích và minh họa; registry, catalog, dictionary giữ định danh và định nghĩa kiểm soát. Worked example tại mục 8 chứng minh cách trình bày phân tích trong học liệu, không xác nhận data model production.

Nếu tên thực thể hoặc trường trong mục 8 khác CANONICAL_DATA_DICTIONARY, không tự sửa ID trong chapter để “khớp cho đẹp”. Ghi nhận mâu thuẫn theo artifact canonical; giữ nhãn IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND và phạm vi dữ liệu tổng hợp.

Nếu TEMPLATE_MANIFEST sau này đăng ký template master-data, BA phải đối chiếu ID, file, owner, consumer, dependency và quality gate trước khi liên kết template đó vào chapter. Trước thời điểm đó, mục 8 vẫn là completed worked example duy nhất được xác định trong source boundary hiện có.

Core

Trước khi bàn giao chapter, BA chạy cross-file self-review: đối chiếu nội dung chapter với artifact canonical liên quan để phát hiện lệch ID, đường dẫn, trạng thái, phiên bản, nguồn và thẩm quyền. Mục tiêu không phải phê duyệt nội dung.

Bằng chứng: mọi artifact nguồn đều ở IN_REVIEW, v0.9.0, ngày 2026-08-07, chưa có baseline hoặc approval. Vì vậy chapter chỉ được bàn giao để review khi giữ đúng nhãn trạng thái này.

Self-review cũng kiểm tra ranh giới giữa template và completed worked example. BA phải xác nhận chapter không tự tạo template ID, không đoán filename, không gọi template chưa đăng ký là artifact hoàn tất, và không gọi worked example tại mục 8 là canonical source hoặc template vận hành.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A["BA thực hiện cross-file self-review trước bàn giao chapter"] --> B["Đối chiếu chapter với artifact canonical liên quan"]
    B --> C["Kiểm tra ID, đường dẫn, filename, nguồn và thẩm quyền"]
    C --> D["Xác nhận mọi artifact nguồn:<br/>`IN_REVIEW` · `v0.9.0` · `2026-08-07`<br/>Chưa có baseline hoặc approval"]
    D --> E["Kiểm tra ranh giới template và completed worked example"]
    E --> F["Không tự tạo template ID<br/>Không đoán filename<br/>Không gọi template chưa đăng ký là artifact hoàn tất<br/>Không gọi worked example mục 8 là canonical source hoặc template vận hành"]
    F --> G{"Bằng chứng khớp và không có kết luận vượt thẩm quyền?"}
    G -- "Có" --> H["Bàn giao chapter để review<br/>Giữ nhãn `IN_REVIEW`<br/>Không phải phê duyệt nội dung"]
    G -- "Không" --> I["Mở open issue"]
    I --> J["Chuyển đúng owner"]
    J --> K["Gắn `Verification required`"]
    K --> G

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; corpus dùng vi-VN, Asia/Ho_Chi_Minh, VND. CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều là nguồn controlled planning ở IN_REVIEW v0.9.0.

Current Behavior: Section 12 chuẩn bị liên kết dữ liệu master với rule, ID, template liên quan và worked example tại mục 8. Section không đăng ký template mới, không cấp ID mới và không chuyển ví dụ mô phỏng thành quyết định vận hành.

Underlying Need: Người đọc cần biết chapter không tự tạo ID, không biến giả định thành rule vận hành, không gọi review là approval, và không nhầm completed worked example với template master-data.

Options: (1) bàn giao không kiểm tra; (2) kiểm tra từng file canonical và ghi issue; (3) tự sửa hoặc tự xác nhận nội dung chuyên môn. Option 2 được chọn. Lý do: option 1 làm đứt traceability; option 3 vượt thẩm quyền Owner.

Decision Criteria: Giữ nguyên canonical ID và filename; không có trạng thái sai; mọi kết luận pháp lý, kế toán, bảo mật, kiến trúc hoặc vận hành có owner xác minh; không có phát biểu Nova Foods đã tuân thủ hoặc đã được phê duyệt; template chỉ được nêu khi manifest có ID và file.

Decision: Bàn giao chapter ở IN_REVIEW kèm kết quả review và nhãn Verification required cho điểm chưa xác minh. Giữ mục 8 là completed worked example trong phạm vi học liệu. Không xác định template master-data cụ thể khi TEMPLATE_MANIFEST chưa đăng ký ID và đường dẫn.

Authority: Principal IT Business Analyst / Technical Curriculum Author điều phối và ghi nhận; không thay thế quyết định của Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA reviewer.

Artifact: Ghi kết quả trong /02-handbook/11-data-modeling-and-master-data.md; đối chiếu nguồn tại /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Consequence if Wrong: ID sai làm liên kết tới artifact khác; rule chưa xác minh bị hiểu là cấu hình ERP; diễn giải luật hoặc kế toán thiếu owner có thể bị hiểu nhầm là hướng dẫn production; template chưa đăng ký có thể bị hiểu nhầm là artifact hoàn tất hoặc được phê duyệt.

Senior Lens

Kiểm tra liên file	Bằng chứng phải khớp	Kết quả hiện tại	Xử lý khi lệch
Metadata quản trị	IN_REVIEW, v0.9.0, 2026-08-07	Khớp nguồn seed	Dừng handoff; escalation Principal IT Business Analyst / Technical Curriculum Author
Định danh	Canonical ID không đổi ký tự	Cần xác minh tại bản chapter hoàn chỉnh	Ghi Verification required; escalation Principal IT Business Analyst / Technical Curriculum Author
Template boundary	Template ID và file phải có trong TEMPLATE_MANIFEST; mục 8 chỉ là worked example	Không có template master-data cụ thể được đăng ký trong bằng chứng hiện có	Không tạo ID hoặc filename; giữ worked example tách khỏi template; escalation Principal IT Business Analyst / Technical Curriculum Author
Quy tắc dữ liệu	Không gọi rule catalog là quyết định vận hành	Mở issue	Escalation Business Owner và Principal IT Business Analyst / Technical Curriculum Author
Dữ liệu cá nhân	Không suy diễn nghĩa vụ pháp lý từ case mô phỏng	Mở issue	Escalation Legal Owner
Thuộc tính kế toán, tiền tệ, hạch toán	VND chỉ là bối cảnh mô phỏng, không phải kết luận kế toán	Mở issue	Escalation Accounting Owner
Quyền truy cập, phân loại dữ liệu, API	Không tự xác nhận kiểm soát bảo mật	Mở issue	Escalation Security và Architect
Khả năng kiểm thử	Rule, field và traceability phải tạo được test basis	Cần xác minh	Escalation QA reviewer

Open issues trước handoff: chưa có baseline reference; chưa có approval reference; nội dung pháp lý về dữ liệu cá nhân cần Legal Owner xác minh; bất kỳ mapping field nào có tác động hạch toán cần Accounting Owner xác minh; bất kỳ mô tả phân quyền hoặc tích hợp cần Security và Architect xác minh. Template master-data cụ thể chưa có ID và file được đăng ký trong TEMPLATE_MANIFEST. Các issue này không chặn giá trị học liệu, nhưng chặn mọi diễn giải thành quyết định Nova Foods thực tế.

Quick Reference

Checklist bàn giao:

1. Kiểm tra đúng filename.
2. Kiểm tra canonical ID giữ nguyên.
3. Kiểm tra IN_REVIEW không bị đổi thành approved hoặc baselined.
4. Kiểm tra dữ liệu Nova Foods được ghi là mô phỏng và tổng hợp.
5. Kiểm tra worked example tại mục 8 không bị gọi là template vận hành hoặc canonical artifact.
6. Kiểm tra template chỉ được tham chiếu khi TEMPLATE_MANIFEST ghi ID và file.
7. Kiểm tra mọi suy luận có bằng chứng.
8. Kiểm tra issue có owner cụ thể.
9. Kiểm tra mục cần xác minh mang nhãn Verification required.

Chỉ bàn giao khi không có lỗi định danh, nguồn, trạng thái hoặc thẩm quyền chưa được ghi nhận. Handoff giữ trạng thái IN_REVIEW; handoff không tạo baseline, approval hoặc xác nhận production readiness.