00 Foundations

---

artifact_path: /02-handbook/00-foundations.md document_title: 00 Foundations status: IN_REVIEW version: v0.9.0 last_updated_date: 2026-08-07 timezone: Asia/Ho_Chi_Minh locale: vi-VN country_context: Vietnam currency: VND case_study: Nova Foods Trading & Manufacturing — mô phỏng giáo dục data_classification: Dữ liệu tổng hợp source_classification: Handbook giáo dục có kiểm soát baseline_reference: Chưa có baseline reference tại v0.9.0 approval_reference: Chưa có approval reference tại v0.9.0

---

1. Concept l? g??

Core

Nền tảng của Business Analysis, viết tắt là BA, là cách biến một thay đổi còn mơ hồ thành nội dung đủ rõ để người có thẩm quyền ra quyết định và đội delivery thực hiện đúng. BA không bắt đầu bằng màn hình, bảng dữ liệu hay câu lệnh ERP. BA bắt đầu bằng câu hỏi gốc: tổ chức đang gặp vấn đề gì, muốn đạt kết quả nào, và bằng chứng nào cho thấy thay đổi đề xuất có ích.

Một thay đổi nghiệp vụ tồn tại khi trạng thái hiện tại không đáp ứng nhu cầu. Ví dụ, nhân viên phải tổng hợp số lượng tồn kho từ nhiều tệp, nhưng quản lý cần số liệu kịp thời để quyết định mua hàng. Khoảng cách giữa trạng thái hiện tại và kết quả cần đạt là đối tượng BA phải làm rõ. BA thu thập sự kiện, phân biệt sự kiện với giả định, xác định nhu cầu, rồi mô tả thay đổi có thể kiểm tra được.

BA không tự quyết định thay doanh nghiệp. BA tạo cấu trúc thông tin để quyết định có cơ sở. Cấu trúc này phải chỉ ra phạm vi, ràng buộc, người chịu thẩm quyền, dữ liệu liên quan, kết quả mong đợi và điều kiện kiểm tra. Lý do: cùng một câu nói “cần quản lý tồn kho tốt hơn” có thể dẫn đến thay đổi quy trình, cấu hình ERP, báo cáo, quyền truy cập, dữ liệu chủ hay đào tạo. Nếu không tách các khả năng này, đội kỹ thuật dễ xây đúng chức năng nhưng sai nhu cầu.

Trong corpus Nova Foods Trading & Manufacturing mô phỏng, BA dùng dữ liệu tổng hợp để học cách lập luận; không xác nhận quy trình, cấu hình ERP, quyết định vận hành hay tuân thủ của doanh nghiệp thật. Ví dụ minh họa chỉ là giả định học liệu: một kho mô phỏng ghi nhận tồn kho chậm sau khi nhận hàng. BA cần xác định chậm ở bước nào, dữ liệu nào thiếu, kết quả nào bị ảnh hưởng, và ai có thẩm quyền chọn phương án xử lý. BA chưa được phép kết luận phải sửa hệ thống, đổi quy trình hay áp dụng quy tắc pháp lý.

Ranh giới khái niệm: BA làm rõ nhu cầu và hỗ trợ quyết định thay đổi. BA không thay thế Business Owner trong quyết định nghiệp vụ, Architect trong quyết định kiến trúc, QA trong xác nhận chất lượng, Legal/Compliance Owner trong diễn giải pháp lý, hay Accounting Owner trong kết luận kế toán. Trạng thái IN_REVIEW của tài liệu chỉ cho biết nội dung đang được xem xét có kiểm soát; không phải APPROVED, BASELINED hay được phép dùng production.

Core

Thuật ngữ	Nghĩa từ gốc	Cách dùng BA	Ví dụ Nova Foods mô phỏng
Actor	Tác nhân thực hiện hoặc khởi phát việc	Người, vai trò, hệ thống, hoặc dịch vụ có trách nhiệm tạo hành động. Actor không phải tên phòng ban chung nếu chưa biết ai thực hiện.	Nhân viên kho ghi nhận nhận hàng; ERP kiểm tra mã lô.
Action	Hành động	Việc actor làm, viết bằng động từ quan sát được: tạo, kiểm tra, phê duyệt, cập nhật, gửi. Không dùng từ mơ hồ như “xử lý” khi chưa nêu thao tác.	Nhân viên kho quét mã lô nguyên liệu.
Object	Đối tượng bị tác động	Dữ liệu, chứng từ, hàng hóa, yêu cầu, hoặc bản ghi mà action tác động. Object phải gọi đúng tên nghiệp vụ.	Phiếu nhận hàng, mã lô, số lượng nhận.
Outcome	Kết quả đầu ra	Trạng thái hoặc giá trị có thể kiểm tra sau action. Outcome trả lời: “sau việc này, điều gì đã thay đổi?”	Phiếu nhận hàng có trạng thái Đã ghi nhận; tồn kho lô tăng.
Business Analyst (BA)	Chuyên viên phân tích nghiệp vụ	Người làm rõ nhu cầu, quy tắc, dữ liệu, phạm vi và cách kiểm tra kết quả. BA không tự quyết thay Business Owner, Legal Owner hay Architect.	BA tách yêu cầu “nhận hàng nhanh” thành actor, action, object, outcome và điều kiện lỗi.
Requirement	Yêu cầu	Nhu cầu hoặc điều kiện hệ thống, quy trình, sản phẩm phải đáp ứng. Requirement chưa tự là thiết kế kỹ thuật.	“ERP phải lưu mã lô cho mỗi dòng nhận nguyên liệu.”
Business Rule	Quy tắc nghiệp vụ	Ràng buộc quyết định nghiệp vụ, độc lập tương đối với màn hình hay công nghệ. Chỉ dùng rule canonical đã đăng ký; không tự biến ví dụ thành rule vận hành.	Ví dụ học liệu: không cho hoàn tất nhận hàng khi thiếu mã lô. Đây là giả định mô phỏng, không phải quy định Nova Foods thực tế.
Acceptance Criteria (AC)	Tiêu chí chấp nhận	Điều kiện kiểm tra được để xác định requirement đạt hay chưa. AC phải có dữ kiện vào và kết quả mong đợi.	Với dòng nhận có số lượng 120 kg và mã lô RM-260807-01, khi ghi nhận thành công, hệ thống lưu cả hai giá trị.

Công thức tối thiểu để hiểu một yêu cầu: Actor thực hiện Action trên Object để tạo Outcome. Bốn thành phần này biến câu mong muốn mơ hồ thành câu có thể phân tích. Bằng chứng: thiếu actor thì không biết trách nhiệm; thiếu action thì không biết thay đổi gì; thiếu object thì không biết phạm vi dữ liệu; thiếu outcome thì không thể kiểm tra thành công.

Ví dụ câu mơ hồ: “Cần quản lý lô nguyên liệu.” Câu này chưa cho biết ai làm, làm gì, trên dữ liệu nào, kết quả nào. Câu đã cấu trúc: “Nhân viên kho ghi nhận mã lô trên từng dòng phiếu nhận hàng để ERP lưu lô nguyên liệu phục vụ tra cứu.” Actor là Nhân viên kho; action là ghi nhận; object là mã lô trên từng dòng phiếu nhận hàng; outcome là ERP lưu lô nguyên liệu.

Phân biệt actor với user: user là người dùng đăng nhập hoặc tương tác; actor rộng hơn, có thể là ERP, dịch vụ tích hợp, máy quét, hoặc lịch chạy tự động. Phân biệt outcome với output: output là dữ liệu hay thông báo được tạo ra; outcome là thay đổi có ý nghĩa sau đó. Ví dụ Thông báo lưu thành công là output; phiếu nhận hàng có dữ liệu lô để tra cứu là outcome.

Phạm vi khái niệm ở đây: cách tách và gọi tên thành phần của phát biểu nghiệp vụ. Không bao gồm thiết kế màn hình, chọn API, cấu hình ERP, xác nhận quy tắc pháp lý, kế toán, an toàn thực phẩm, hay phê duyệt requirement. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tên, mã và dữ liệu ví dụ là dữ liệu tổng hợp.

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 của doanh nghiệp thật.

Thành phần	Nội dung mô phỏng
Facts	Nhân viên kho ghi nhận 120 thùng “Sữa hạt Nova 1L” đã nhận tại kho thành phẩm ngày 2026-08-07.
Current Behavior	Nhân viên nhắn số lượng vào nhóm chat; kế toán nhập lại sau. Cùng một sự kiện bị ghi ở hai nơi, nên số lượng có thể lệch.
Underlying Need	Kho cần ghi nhận việc nhận hàng một lần, có người thực hiện, hàng nhận, số lượng và kết quả tồn kho tăng.
Options	(1) Giữ chat và bảng tính. (2) Tạo màn hình ERP ghi nhận nhận hàng.
Decision Criteria	Dữ liệu phải truy vết được người ghi, thời điểm, mặt hàng và số lượng; không nhập lặp; không tự suy diễn số tồn.
Decision	Mô tả nhu cầu ở mức khái niệm: hệ thống cần cho nhân viên kho ghi nhận nhận hàng để cập nhật tồn kho mô phỏng.
Authority	Business Owner xác nhận nhu cầu vận hành; Architect xác nhận thiết kế; Accounting Owner xác nhận ảnh hưởng kế toán nếu có. Các xác nhận này chưa tồn tại trong case study.
Artifact	Một mô tả nhu cầu nghiệp vụ dùng làm đầu vào cho các artifact sau; chưa phải business rule, giao diện, API, cấu hình ERP hay test case.
Consequence if Wrong	Nếu nhầm “ghi nhận nhận hàng” với “tạo bút toán”, team có thể giao sai chức năng, sai quyền hạn hoặc sai thời điểm cập nhật tồn.

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

flowchart TB
    A[Nhân viên kho] -->|ghi nhận hàng thành phẩm đã nhận| B[Phiếu nhận hàng mô phỏng]
    B -->|kết quả mong muốn| C[Tồn kho mô phỏng phản ánh hàng đã nhận]

Ranh giới khái niệm: ví dụ chỉ xác định ai thực hiện, hành động gì, trên đối tượng nào và kết quả mong muốn. Actor là người hoặc vai trò thực hiện, ở đây là nhân viên kho. Action là việc làm, ở đây là ghi nhận nhận hàng. Object là thứ bị tác động, ở đây là hàng thành phẩm và phiếu nhận hàng mô phỏng. Outcome là trạng thái nghiệp vụ mong muốn, ở đây là tồn kho mô phỏng phản ánh hàng đã nhận.

Loại trừ rõ: ví dụ không quyết định mã hàng, trường dữ liệu bắt buộc, luồng phê duyệt, cách tính giá vốn, bút toán kế toán, thuế, chứng từ, quyền truy cập, tích hợp máy quét mã vạch, API, thiết kế màn hình, tiêu chí chấp nhận hay kiểm thử. Lý do: các nội dung đó cần bằng chứng, artifact và thẩm quyền chuyên môn riêng; thêm chúng ở bước khái niệm sẽ biến giả định thành yêu cầu.

Senior Lens

Senior BA tách “nhu cầu ghi nhận hàng đã nhận” khỏi “giải pháp màn hình ERP”. Bằng chứng là cùng outcome có thể đạt bằng nhiều cách; vì vậy chưa chọn giao diện hay tích hợp khi chưa phân tích quy trình và ràng buộc. Không suy ra nghĩa vụ kế toán hoặc pháp lý từ ví dụ này. Mọi diễn giải liên quan kế toán, thuế, an toàn thực phẩm, truy xuất nguồn gốc hoặc dữ liệu cá nhân cần Verification required từ owner có thẩm quyền.

Quick Reference

Đúng phạm vi concept	Ngoài phạm vi concept
Nhân viên kho ghi nhận hàng nhận	Nút “Lưu” có màu nào
Hàng thành phẩm là đối tượng ghi nhận	API nào gửi dữ liệu
Tồn kho cần phản ánh hàng đã nhận	Bút toán nào được sinh
Mục tiêu là giảm nhập lặp	Ai đã phê duyệt giải pháp

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

Core

Concept tồn tại để chặn việc đội dự án nhảy từ câu nói mơ hồ sang giải pháp ERP. Khi chưa xác định actor, action, object và outcome, cùng một câu “cần ghi nhận hàng nhận” có thể bị hiểu thành nhập kho, kiểm tra chất lượng, tạo chứng từ, cập nhật giá vốn hoặc đồng bộ thiết bị quét mã. Mỗi cách hiểu tạo phạm vi khác nhau. Nếu đội phát triển chọn một cách hiểu trước, phần xây sau có thể không giải quyết nhu cầu thật.

Rủi ro đầu tiên là rework, nghĩa là làm lại phần đã xây. Lý do: thiết kế, cấu hình hoặc mã nguồn dựa trên diễn giải chưa được kiểm soát. Khi người dùng làm rõ outcome khác với điều đã xây, BA phải sửa yêu cầu; đội kỹ thuật phải sửa thiết kế; QA phải sửa test basis, tức tập đầu vào dùng để thiết kế kiểm thử. Chi phí không chỉ là sửa màn hình: dữ liệu, phân quyền, tích hợp và tài liệu có thể cùng bị ảnh hưởng.

Rủi ro thứ hai là ambiguity, nghĩa là mơ hồ cho phép nhiều diễn giải hợp lý. Mơ hồ không luôn là lỗi ngôn ngữ; nó là thiếu ranh giới nghiệp vụ. “Hàng nhận” chưa cho biết hàng nào, ai ghi nhận, thời điểm nào và kết quả nào cần đạt. Concept ép BA nêu phần tối thiểu này trước. Nhờ vậy, nhóm có thể phát hiện điểm chưa biết mà không biến chúng thành quy tắc hoặc quyết định giả định.

Rủi ro thứ ba là governance failure, nghĩa là thất bại kiểm soát thẩm quyền và dấu vết quyết định. Nếu khái niệm nhu cầu bị trộn với cách triển khai, người đọc có thể tưởng rằng một ví dụ đào tạo đã là yêu cầu, quyết định kiến trúc hoặc quy định vận hành. Trong corpus Nova Foods mô phỏng, dữ liệu tổng hợp, trạng thái IN_REVIEW và phiên bản v0.9.0 không tạo baseline hoặc approval. Concept giữ câu hỏi ở mức “cần đạt điều gì”; artifact và owner phù hợp mới xử lý câu hỏi “xây thế nào” và “ai quyết định”.

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

flowchart TB
    A[Nhu cầu được nêu] --> B{Có actor, action, object, outcome?}
    A --> C{Nhu cầu có bị trộn với cách triển khai?}

    B -- Không --> D[Ambiguity: nhiều diễn giải hợp lý]
    D --> E[Thiết kế sai phạm vi]
    E --> F[Rework]
    F --> G[BA sửa yêu cầu]
    F --> H[Kỹ thuật sửa thiết kế]
    F --> I[QA sửa test basis]
    F --> J[Dữ liệu, phân quyền, tích hợp và tài liệu bị ảnh hưởng]

    B -- Có --> K[Phạm vi nhu cầu rõ hơn]
    K --> L[Concept giữ câu hỏi ở mức cần đạt điều gì]
    L --> M[Phát hiện điểm chưa biết]
    M --> N[Artifact và owner phù hợp xử lý cách xây và thẩm quyền quyết định]

    C -- Có --> O[Ví dụ đào tạo bị hiểu là yêu cầu, quyết định kiến trúc hoặc quy định vận hành]
    O --> P[Governance failure: sai thẩm quyền và thiếu dấu vết quyết định]
    Q[Dữ liệu tổng hợp, IN_REVIEW, v0.9.0] --> R[Không tạo baseline hoặc approval]
    R --> P

    C -- Không --> S[Khái niệm nhu cầu tách khỏi cách triển khai]

Applied

Nova Foods là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Một nhóm nghe yêu cầu “ghi nhận hàng thành phẩm đã nhận vào kho”. Nếu không dùng concept, BA có thể ghi ngay “xây màn hình nhập kho”. Câu này đã chọn giải pháp nhưng chưa chứng minh màn hình là cách phù hợp, chưa xác định người thực hiện và chưa nêu kết quả nghiệp vụ cần kiểm soát.

Điểm kiểm soát	Khi không có concept	Rủi ro được ngăn bởi concept
Actor	Có thể lẫn nhân viên kho, QC hoặc thủ kho	Xây quyền thao tác cho sai vai trò
Action	“Ghi nhận” có thể là nhận vật lý, xác nhận chất lượng hoặc cập nhật sổ	Thiết kế một thao tác nhưng nghiệp vụ cần thao tác khác
Object	“Hàng thành phẩm” chưa xác định đơn vị ghi nhận hay chứng từ liên quan	Dữ liệu lưu không phục vụ đối chiếu sau này
Outcome	Không nêu trạng thái cần đạt	Không thể biết chức năng đã giải quyết nhu cầu hay chưa
Giải pháp	Màn hình ERP được chọn quá sớm	Bỏ qua quy trình, tích hợp hoặc kiểm soát cần phân tích

Concept không tự giải quyết các khoảng trống này. Nó làm khoảng trống nhìn thấy được, để dự án không che giấu chúng bằng tên chức năng, mockup hoặc cấu hình ERP.

Senior Lens

Senior BA dùng concept như cổng chặn sớm. Cổng này không hỏi “giải pháp có đẹp không”; nó hỏi “nhu cầu có đủ nghĩa để phân tích chưa”. Nếu actor, action, object hoặc outcome thiếu, BA ghi nhận thiếu hụt và giữ phạm vi mở. Không tự thêm điều kiện về kế toán, thuế, an toàn thực phẩm, truy xuất nguồn gốc, dữ liệu cá nhân hoặc production. Các nội dung đó vượt khái niệm ban đầu và cần nguồn, artifact, owner có thẩm quyền cùng xác minh riêng.

Quick Reference

Failure mode	Concept chặn bằng cách nào
Đội kỹ thuật xây theo phỏng đoán	Buộc nêu outcome trước giải pháp
Nhiều vai trò hiểu khác nhau	Tách rõ actor và action
Phạm vi ERP phình không kiểm soát	Giới hạn vào đối tượng và kết quả cần đạt
Ví dụ bị hiểu là quyết định	Tách nhu cầu khỏi thiết kế, rule và approval
Artifact không truy được lý do tồn tại	Giữ liên kết từ nhu cầu đến outcome nghiệp vụ

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi mã đơn, tên khách và số tiền dưới đây là dữ liệu tổng hợp bằng VND. Tình huống so sánh: Sales yêu cầu ERP “chặn giao hàng khi khách vượt hạn mức công nợ”. Nếu câu này đi thẳng vào cấu hình, cùng một câu có thể bị hiểu khác nhau giữa Sales, Kho và Finance.

Điểm quan sát	Trước khi làm rõ concept	Sau khi làm rõ concept
Yêu cầu nhận được	“Chặn giao hàng khi khách vượt hạn mức.”	Yêu cầu được tách thành điều kiện, hành vi hệ thống, ngoại lệ và chủ sở hữu quyết định.
Đơn mô phỏng	SO-NF-2026-0087, khách CUS-NF-014, giá trị đơn 18,000,000 VND.	Cùng đơn SO-NF-2026-0087; ERP kiểm tra hạn mức tại lúc xác nhận giao hàng.
Cách hiểu Sales	Có thể giao nếu đơn đã được Sales tạo trước.	Sales thấy trạng thái Credit Hold; không tự bỏ chặn.
Cách hiểu Kho	Có thể xuất kho vì hàng đã được pick.	Kho không tạo phiếu xuất khi trạng thái đơn là Credit Hold.
Cách hiểu Finance	Có thể hiểu “vượt hạn mức” là chỉ quá hạn thanh toán.	Finance đối chiếu số dư công nợ và hạn mức được duy trì cho khách trước khi quyết định xử lý ngoại lệ.
Hệ quả quan sát được	Cùng SO-NF-2026-0087 có thể bị xuất hàng hoặc bị giữ tùy người thao tác; sau đó phải truy ngược lý do từ trao đổi rời rạc.	Cùng điều kiện tạo cùng trạng thái; lịch sử đơn chỉ rõ thời điểm bị giữ và vai trò được phân quyền xử lý.
Rủi ro còn lại	Tranh cãi “ai hiểu đúng”, sửa cấu hình sau kiểm thử, và thiếu căn cứ để QA viết ca kiểm thử.	Vẫn cần xác minh ngưỡng hạn mức, công thức số dư, ngoại lệ và quyền bỏ chặn trước khi coi là rule triển khai.

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

flowchart TB
    A[Điểm kiểm tra: xác nhận giao hàng] --> B[ERP tính tổng phơi nhiễm theo rule candidate và đối chiếu hạn mức khách]
    B --> C{Vượt hạn mức theo rule candidate?}
    C -- Có --> D[Đặt trạng thái Credit Hold]
    D --> E[Sales thấy Credit Hold và không tự bỏ chặn]
    D --> F[Kho không tạo phiếu xuất]
    D --> G[Chuyển Finance xem xét ngoại lệ]
    G --> H{Quyền bỏ chặn và tiêu chí đã được xác minh?}
    H -- Có --> I[Finance xử lý ngoại lệ hoặc bỏ chặn theo quyền]
    H -- Không --> J[Giữ trạng thái Credit Hold]
    C -- Không --> K[Cho phép tiếp tục giao hàng]

Khác biệt không nằm ở việc viết thêm câu chữ. Khác biệt nằm ở biến câu nói chung thành hành vi có thể quan sát: điểm kiểm tra là xác nhận giao hàng; kết quả chặn là Credit Hold; tác động là Kho không xuất hàng; điểm cần quyết định là quyền xử lý ngoại lệ. Khi các điểm này chưa được ghi trong artifact kiểm soát, cấu hình, tài liệu kiểm thử và hướng dẫn vận hành có thể dùng các cách hiểu khác nhau dù cùng nói về một yêu cầu.

Artifact dự kiến để giữ cùng cách hiểu: requirement record liên kết SO-NF-2026-0087 trong case mô phỏng, kèm rule candidate, trạng thái đơn và test condition. Artifact này vẫn thuộc corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không là baseline, không là approval, không xác nhận rule Nova Foods cho production.

Core

Năm loại phát biểu có giá trị quản trị khác nhau. Trộn chúng làm yêu cầu có vẻ chắc chắn dù chưa có bằng chứng, rồi gây làm lại, tranh chấp phạm vi hoặc quyết định vượt thẩm quyền. 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.

Loại	Định nghĩa	Bằng chứng tối thiểu	Cách ghi	Không được suy diễn thành
Fact đã xác minh	Thông tin kiểm tra được từ nguồn xác định, còn hiệu lực trong phạm vi dùng	URL/tệp nguồn, ngày truy cập 2026-08-07, nội dung đối chiếu	“Đã xác minh: IN_REVIEW không phải APPROVED.”	Quyết định nghiệp vụ, cấu hình ERP
Stakeholder input	Ý kiến, mô tả hiện trạng, nhu cầu từ người liên quan	Vai trò, thời điểm, bối cảnh phát biểu; chưa cần đúng tuyệt đối	“Input Kho vận: cần biết lô hàng khi xuất kho.”	Fact, rule bắt buộc
Project assumption	Điều nhóm dự án tạm giả định để tiếp tục phân tích khi thiếu dữ liệu	Lý do, tác động, người cần xác minh, hạn xác minh	“Giả định dự án: mã lô có thể nhập khi tạo phiếu xuất.”	Fact hoặc quyết định
Decision	Lựa chọn giữa các phương án, có tiêu chí và thẩm quyền	Phương án, tiêu chí, người có quyền quyết, trạng thái quyết định	“Quyết định tài liệu: giữ nhãn Verification required.”	Approval nghiệp vụ hoặc production approval
Verification-required claim	Phát biểu có thể ảnh hưởng pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc vận hành nhưng chưa đủ bằng chứng/thẩm quyền	Nguồn cần kiểm, owner xác minh, điều kiện đóng	“Cần xác minh: trường lô có bắt buộc theo quy định áp dụng.”	Nghĩa vụ pháp lý hay requirement đã chốt

Quy tắc đọc: nguồn chính thức xác minh được trạng thái artifact và tình trạng văn bản nguồn; nguồn đó không tự xác minh cách Nova Foods mô phỏng vận hành ERP. Input từ stakeholder mô tả điều người đó biết hoặc cần; BA phải tách nó khỏi fact bằng cách lưu nguồn và giới hạn. Assumption giúp phân tích không dừng, nhưng phải có đường đóng bằng xác minh. Decision chỉ tồn tại khi ghi rõ authority; người soạn handbook không thay Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA cấp quyết định.

Applied

Facts: /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CANONICAL_BUSINESS_RULES.md đều ghi Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07; các artifact này không có baseline reference hay approval reference. Đây là fact đã xác minh từ artifact kiểm soát, không phải bằng chứng Nova Foods đã chọn quy trình xuất kho.

Current Behavior: Trong ví dụ mô phỏng, stakeholder Kho vận nói: “Phiếu xuất cần có mã lô để truy vết.” Đây là stakeholder input. Câu nói chưa cho biết mọi loại hàng có dùng lô, mã lô lấy từ đâu, hay có phải nghĩa vụ pháp lý.

Underlying Need: BA cần bảo toàn truy vết giữa phát biểu, bằng chứng, giả định và người có thẩm quyền. Lý do: cùng một câu “mã lô bắt buộc” có thể là nhu cầu vận hành, rule ERP, điều kiện chất lượng hoặc diễn giải pháp lý; mỗi nghĩa cần nguồn và owner khác nhau.

Mục	Phân loại đúng	Lý do/bằng chứng
“Artifact corpus đang IN_REVIEW.”	Fact đã xác minh	Metadata upstream ghi trực tiếp trạng thái này.
“Kho vận cần thấy mã lô trên phiếu xuất.”	Stakeholder input	Nguồn là vai trò Kho vận trong case mô phỏng.
“ERP có trường Lot Number khi tạo phiếu xuất.”	Project assumption	Chưa có data dictionary hoặc đặc tả giao diện được xác minh.
“Trường Lot Number phải bắt buộc cho mọi phiếu xuất.”	Verification-required claim	Có tác động quy trình; chưa có phạm vi hàng hóa, rule canonical hoặc authority quyết định.
“Không chuyển claim này thành rule canonical trước khi xác minh.”	Decision tài liệu	Quyết định quản trị phân tích, dựa trên trạng thái IN_REVIEW và thiếu thẩm quyền nghiệp vụ.

Options: (1) ghi ngay “mã lô bắt buộc” thành business rule; (2) bỏ qua input; (3) ghi input, tạo assumption có điều kiện, giữ claim cần xác minh. Phương án (1) tạo rule chưa có authority. Phương án (2) mất nhu cầu truy vết. Phương án (3) giữ được traceability mà không bịa requirement.

Decision Criteria: Phân loại phải phản ánh đúng nguồn; không biến input thành fact; không diễn giải Luật An toàn thực phẩm 55/2010/QH12 thành nghĩa vụ ERP khi chưa có Legal Owner và domain owner xác minh; không gọi IN_REVIEW là approved hoặc baselined.

Decision: Chọn phương án (3): ghi nhu cầu mã lô là stakeholder input; ghi khả năng nhập mã lô là project assumption; gắn “bắt buộc cho mọi phiếu xuất” là Verification required.

Authority: Business Owner quyết phạm vi nghiệp vụ; domain owner và Legal Owner xác minh claim liên quan truy vết/an toàn thực phẩm; Architect xác minh khả năng hệ thống; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì phân loại và traceability.

Artifact: Ghi trong /02-handbook/00-foundations.md; khi có artifact canonical được tạo và có bằng chứng phù hợp, tham chiếu đúng ID CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY, không thay bằng tên tự đặt.

Consequence if Wrong: Nếu stakeholder input bị ghi thành fact, đội cấu hình có thể bắt buộc mã lô cho hàng không thuộc phạm vi đã quyết. Nếu assumption bị ghi thành decision, người review tưởng đã có thẩm quyền chốt. Nếu claim pháp lý chưa xác minh bị ghi là rule, corpus tạo cảm giác tuân thủ sai và khó audit.

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

flowchart TB
    A[Phát biểu mới] --> B{Nguồn và bằng chứng<br/>đủ xác minh claim?}
    B -->|Có| C[Fact đã xác minh]
    B -->|Chưa đủ| D{Nguồn là stakeholder?}

    D -->|Có| E[Stakeholder input]
    D -->|Không| F{Dùng tạm để phân tích?}
    F -->|Có| G[Project assumption]
    F -->|Không| H[Verification-required claim]

    C --> I[Lưu nhãn nguồn, bằng chứng<br/>và traceability]
    E --> I
    G --> I
    H --> I

    I --> IA[Principal IT Business Analyst /<br/>Technical Curriculum Author duy trì<br/>phân loại và traceability]
    IA --> J{Claim cần xác minh loại nào?}

    J -->|Nghiệp vụ| K[Domain owner xác minh claim]
    J -->|Pháp lý hoặc truy vết an toàn thực phẩm| L[Legal Owner và domain owner xác minh]
    J -->|Khả năng hệ thống| M[Architect xác minh]
    J -->|Fact đã xác minh| N[Fact làm bằng chứng khi đánh giá decision]

    K --> O{Bằng chứng và owner<br/>phù hợp hỗ trợ claim?}
    L --> O
    M --> O

    O -->|Chưa có hoặc không đủ| P[Giữ nhãn nguồn;<br/>lập đường xác minh]
    P --> PA[Principal IT Business Analyst /<br/>Technical Curriculum Author duy trì<br/>nhãn và traceability]
    PA --> Q[Không nâng thành canonical rule;<br/>không gọi IN_REVIEW là approved hoặc baselined]
    Q --> R[Rủi ro: bắt buộc mã lô ngoài phạm vi;<br/>tạo cảm giác tuân thủ sai]

    O -->|Có| S{Kết quả xác minh claim}
    S -->|Ủng hộ| T[Claim được xác nhận]
    S -->|Chỉ đúng có điều kiện| U[Thu hẹp phạm vi claim]
    S -->|Không ủng hộ| V[Bác bỏ claim]

    T --> TS[Stakeholder input hoặc project assumption<br/>giữ nhãn nguồn ban đầu;<br/>chỉ nội dung claim có outcome xác minh]
    U --> TS
    V --> TS

    N --> W{Cần decision quản trị<br/>về phạm vi hoặc xử lý outcome?}
    TS --> W

    W -->|Có| X[Business Owner ghi decision riêng;<br/>chỉ tạo trong CANONICAL_BUSINESS_RULES<br/>hoặc CANONICAL_DATA_DICTIONARY khi đủ authority,<br/>bằng chứng và artifact canonical]
    W -->|Chưa có| Y[Giữ outcome và traceability]
    Y --> YA[Principal IT Business Analyst /<br/>Technical Curriculum Author duy trì<br/>phân loại và traceability]

Senior Lens

Fact không đồng nghĩa “đúng cho mọi mục đích”. Ví dụ, fact “Luật An toàn thực phẩm 55/2010/QH12 là nguồn chính thức” chỉ xác minh nguồn tồn tại và được dùng cho bối cảnh truy vết/thu hồi; nó không xác minh trường dữ liệu, thời hạn lưu, luồng phê duyệt hay cấu hình ERP Nova Foods. Cầu nối suy luận phải hiện rõ: nguồn nói gì, stakeholder cần gì, giả định nào đang được dùng, ai quyết và bằng chứng nào còn thiếu.

Không dùng trạng thái tài liệu để nâng cấp nội dung. IN_REVIEW là trạng thái xem xét có kiểm soát. Nó không phải APPROVED, BASELINED, compliant, production-ready hay user-approved. Khi evidence mâu thuẫn, giữ cả hai phát biểu với nguồn riêng, không “dung hòa” bằng câu rule mới.

Quick Reference

Nếu gặp câu này	Gắn nhãn đầu tiên	Việc kế tiếp
“Tài liệu ghi IN_REVIEW.”	Fact đã xác minh	Lưu đường dẫn, version, ngày kiểm tra.
“Kế toán muốn khóa sửa phiếu sau khi ghi sổ.”	Stakeholder input	Hỏi phạm vi, trigger, ngoại lệ, authority.
“Tạm coi một phiếu chỉ có một mã lô.”	Project assumption	Ghi tác động và người xác minh.
“ERP phải khóa sửa phiếu.”	Verification-required claim	Kiểm rule, accounting/legal requirement, thiết kế kỹ thuật.
“Chọn khóa sửa sau khi có tiêu chí và owner quyết.”	Decision	Ghi phương án, tiêu chí, authority, trạng thái.

3. V? tr? trong Lifecycle

Core

Lifecycle là chuỗi biến nhu cầu thành thay đổi vận hành được kiểm tra. Với Nova Foods Trading & Manufacturing, đây là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Concept đang học đi qua sáu pha: Discovery, Analysis, Delivery, Testing, Release, Operations. Mỗi pha có entry gate: điều kiện tối thiểu để bắt đầu; và exit gate: bằng chứng tối thiểu để chuyển pha. Gate ngăn đội chuyển một ý tưởng mơ hồ thành cấu hình ERP, mã nguồn hoặc thay đổi production khi chưa đủ căn cứ.

Pha	Mục đích	Entry gate chính xác	Exit gate chính xác
Discovery	Nhận diện vấn đề, mục tiêu và phạm vi sơ bộ	Có trigger nghiệp vụ được ghi nhận; phân biệt fact, stakeholder input và project assumption	Có problem statement, mục tiêu đo được, phạm vi sơ bộ, giả định và khoảng trống xác minh
Analysis	Biến nhu cầu thành yêu cầu có thể kiểm tra	Discovery exit có traceability; câu hỏi trọng yếu chưa bị che bằng giả định	Có requirement, business rule, dữ liệu, ngoại lệ, acceptance criteria và điểm chưa xác minh được gắn nhãn
Delivery	Cấu hình, xây dựng hoặc tích hợp thay đổi	Analysis exit đủ làm build/test basis; không có rule pháp lý, kế toán hoặc bảo mật bị tự suy diễn	Có increment triển khai được trong môi trường phù hợp và liên kết tới requirement
Testing	Đối chiếu kết quả thực tế với test basis	Có build/increment, test basis, dữ liệu kiểm thử tổng hợp và môi trường kiểm thử	Có kết quả test, defect ghi nhận, trạng thái pass/fail và bằng chứng regression theo phạm vi
Release	Chuẩn bị đưa thay đổi đã kiểm tra vào môi trường đích	Testing exit cho thấy tiêu chí release đã được đánh giá; các rủi ro còn lại được ghi nhận	Có gói release, kế hoạch rollback, hướng dẫn vận hành và quyết định release theo thẩm quyền được ghi nhận
Operations	Vận hành, theo dõi và học từ kết quả	Release hoàn tất theo kế hoạch; monitoring và hỗ trợ sẵn sàng	Có dữ liệu vận hành, incident hoặc feedback; thay đổi mới quay lại Discovery khi xuất hiện nhu cầu mới

IN_REVIEW, v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và VND là fact quản trị corpus. Chúng không phải exit gate cho delivery, testing hay release. Lý do: trạng thái tài liệu chỉ mô tả mức xem xét artifact; gate pha cần bằng chứng về nội dung và kết quả của pha đó.

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

flowchart TB
    D[Discovery<br/>Entry: trigger ghi nhận;<br/>phân biệt fact, stakeholder input,<br/>project assumption]
    A[Analysis<br/>Entry: Discovery exit traceable;<br/>câu hỏi trọng yếu còn tường minh]
    B[Delivery<br/>Entry: build/test basis đủ;<br/>không tự suy diễn rule pháp lý, kế toán, bảo mật]
    T[Testing<br/>Entry: build/increment, test basis,<br/>synthetic data, test environment]
    R[Release<br/>Entry: release criteria evaluated;<br/>residual risks recorded]
    O[Operations<br/>Entry: release hoàn tất;<br/>monitoring và support sẵn sàng]

    D -->|Exit: problem statement, measurable goals,<br/>scope, assumptions, verification gaps| A
    A -->|Exit: requirements, rules, data, exceptions,<br/>acceptance criteria, labeled unverified points| B
    B -->|Exit: increment triển khai được trong môi trường phù hợp;<br/>linked to requirement| T
    T -->|Exit: results, defects recorded, pass/fail,<br/>regression evidence in tested scope| R
    R -->|Exit: release package, rollback plan, operations guidance;<br/>authorized release decision recorded| O
    O -->|Operational data, incident, feedback;<br/>new need returns to Discovery| D

Applied

Facts: Nova Foods mô phỏng có nhu cầu giảm nhập sai mã lô khi ghi nhận nhận hàng nguyên liệu. Dữ liệu ví dụ LOT-SYN-260807-01 là dữ liệu tổng hợp. Corpus đang IN_REVIEW, nên chưa có baseline hoặc approval được ghi nhận.

Current Behavior: Nhân viên có thể ghi mã lô tự do trong màn hình nhận hàng giả định. Đây là mô tả case, không phải xác nhận cấu hình ERP thực.

Underlying Need: Cần xác định liệu nhu cầu đã đủ đi từ Discovery sang Analysis hay chưa. Cầu nối suy luận: lỗi nhập liệu là trigger; nhưng trigger chưa xác định format mã lô, ngoại lệ, dữ liệu nguồn, tác động truy vết hoặc người có thẩm quyền quyết định rule.

Options: (1) Chuyển thẳng sang Delivery để thêm ô kiểm tra mã lô; (2) Dừng ở Discovery và hoàn tất problem statement, phạm vi, giả định; (3) Chuyển sang Analysis với nhãn Verification required cho quy tắc mã lô.

Decision Criteria: Chỉ chuyển Analysis khi có vấn đề xác định được, phạm vi sơ bộ, stakeholder input được phân loại và khoảng trống xác minh hiển thị. Chỉ chuyển Delivery khi Analysis tạo test basis đủ để kiểm tra thay đổi.

Decision: Chọn option 3 cho case học liệu. Lý do: trigger đủ để phân tích, nhưng chưa đủ evidence để tự đặt format mã lô hoặc rule truy vết. Requirement về format mã lô giữ nhãn Verification required.

Authority: Không ghi nhận quyết định nghiệp vụ, pháp lý, kế toán, an toàn thực phẩm hoặc release authority tại v0.9.0. Case này chỉ minh họa gate phân tích.

Artifact: Discovery tạo problem statement và assumption log; Analysis tạo requirement, acceptance criteria và traceability link tới CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY khi các artifact đó có nội dung canonical phù hợp.

Consequence if Wrong: Nếu chuyển Delivery trước Analysis exit, đội có thể xây validation sai format, chặn lô hợp lệ hoặc không hỗ trợ truy vết cần thiết. Nếu gọi IN_REVIEW là approval, đội có thể release dựa trên thẩm quyền không tồn tại.

Senior Lens

Gate không phải cuộc họp mang tên “sign-off”. Gate là kiểm tra bằng chứng. Ví dụ, “đã có requirement” chưa đủ cho Delivery nếu requirement không nêu điều kiện chấp nhận. “Đã test pass” chưa đủ cho Release nếu test không dùng test basis liên kết requirement. Chuỗi bằng chứng phải giữ nguyên: trigger được ghi nhận, nhu cầu được phân tích, thay đổi được xây, kết quả được kiểm tra, release được kiểm soát, vận hành tạo feedback.

Nguồn seed hỗ trợ thuật ngữ BA từ BABOK Guide và thuật ngữ kiểm thử từ ISTQB CTFL Syllabus v4.0.1. ISO/IEC/IEEE 29148:2018 là nguồn cho bối cảnh engineering requirements, nhưng không được suy diễn clause hay tiêu chí Nova Foods chưa xác minh. Khi lifecycle chạm dữ liệu cá nhân, kế toán, hóa đơn hoặc an toàn thực phẩm, giữ Verification required; cần Legal Owner, Accounting Owner hoặc domain owner xác minh trước khi biến thành rule.

Quick Reference

Chuyển pha	Hỏi gate ngắn	Không chuyển khi
Discovery sang Analysis	Vấn đề, phạm vi, giả định đã thấy rõ chưa?	Trigger chỉ là lời kể không có bối cảnh
Analysis sang Delivery	Có requirement và acceptance criteria để build/test chưa?	Rule còn mơ hồ hoặc tự suy diễn
Delivery sang Testing	Có increment và liên kết requirement chưa?	Không biết đang test điều gì
Testing sang Release	Có evidence pass/fail, defect và rủi ro còn lại chưa?	Chỉ có lời nói “đã test”
Release sang Operations	Có rollback, hướng dẫn vận hành và monitoring chưa?	Không có cách xử lý khi thay đổi lỗi
Operations sang Discovery	Có feedback, incident hoặc nhu cầu mới chưa?	Vấn đề vận hành bị sửa ngầm không traceability

Core

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, handoff là điểm bàn giao trách nhiệm, không phải chuyển hết thẩm quyền. BA nhận đầu vào từ owner thượng nguồn, kiểm tra nguồn canonical, ghi nhận quyết định hoặc điểm chưa quyết định, rồi chuyển artifact đủ ngữ cảnh cho owner hạ nguồn. Lý do: người nhận cần biết cái gì đã được xác nhận, cái gì còn là giả định dự án, và ai có quyền kết luận.

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

flowchart TB
    BO[Business Owner]
    BA[Business Analyst]
    AR[Architect]
    DV[Delivery Team]
    QA[QA Owner]
    SP[Specialist Owner<br/>Legal, Accounting, Security,<br/>Compliance hoặc domain owner]

    BO -->|Nhu cầu, ưu tiên, phạm vi mô phỏng| BA
    BO -->|Quyết định nghiệp vụ| BA
    BA --> CK[Kiểm tra nguồn canonical<br/>Ghi nhận đã xác nhận,<br/>giả định và câu hỏi mở]

    CK -->|Requirement, rule, dữ liệu,<br/>ràng buộc, câu hỏi mở| AR
    AR -->|Kết luận khả thi kiến trúc| BA
    CK -->|Acceptance criteria, traceability,<br/>quyết định ghi nhận, giả định| DV
    DV -->|Bản dựng, thay đổi kỹ thuật,<br/>lỗi đã biết| QA
    QA -->|Kết quả kiểm thử, lỗi| BO

    CK --> ESC{Câu hỏi vượt thẩm quyền<br/>owner đang giữ artifact?}
    ESC -->|Có: giữ chưa kết luận| SP
    SP -->|Kết luận thuộc thẩm quyền| BA
    ESC -->|Không| BA

    BA -.-> BAL[BA không tự chốt thiết kế,<br/>chất lượng hoặc kết luận chuyên môn]
    DV -.-> DVL[Delivery Team không tự đổi<br/>business rule]
    QA -.-> QAL[QA Owner kết luận<br/>trạng thái kiểm thử]
    SP -.-> SPL[Specialist Owner kết luận<br/>trong phạm vi mình]

Điểm handoff	Owner thượng nguồn	Owner hạ nguồn	Nội dung bàn giao tối thiểu	Giới hạn thẩm quyền
Nhu cầu sang phân tích	Business Owner	BA	Mục tiêu, vấn đề, ưu tiên, phạm vi mô phỏng	Business Owner quyết định giá trị nghiệp vụ; BA không tự chọn ưu tiên
Phân tích sang giải pháp	BA	Architect	Requirement, rule, dữ liệu, ràng buộc, câu hỏi mở	Architect quyết định khả thi kiến trúc; BA không tự chốt thiết kế
Requirement sang delivery	BA	Delivery Team	Acceptance criteria, traceability, quyết định đã ghi nhận, giả định	Delivery Team không tự đổi business rule
Bản dựng sang kiểm thử	Delivery Team	QA Owner	Phiên bản kiểm thử, thay đổi kỹ thuật, lỗi đã biết	QA Owner kết luận trạng thái kiểm thử; BA không tự xác nhận chất lượng
Ngoại lệ chuyên môn	BA	Legal, Accounting, Security, Compliance hoặc domain owner	Vấn đề, bằng chứng nguồn, tác động, câu hỏi cần kết luận	BA điều phối và truy vết; specialist owner kết luận trong phạm vi mình

Escalation xảy ra khi câu hỏi vượt quyền người đang giữ artifact. Ví dụ, rule ảnh hưởng hóa đơn cần Accounting Owner và Legal Owner xem xét; bằng chứng là nguồn /01-curriculum/CANONICAL_BUSINESS_RULES.md nêu Owner không thay thế thẩm quyền kế toán hoặc pháp lý. BA phải giữ câu hỏi ở trạng thái chưa kết luận, không đổi nó thành rule Nova Foods.

Applied

Facts: Nova Foods mô phỏng cần hiển thị trạng thái “đã xuất hóa đơn” trên đơn bán hàng. Dữ liệu là tổng hợp, không xác nhận quy trình ERP thực tế.

Current Behavior: BA nhận đề nghị từ Business Owner nhưng chưa có kết luận về thời điểm trạng thái được phép đổi.

Underlying Need: Delivery Team cần rule rõ để xây dựng; QA Owner cần test basis để kiểm thử; Accounting Owner cần bảo đảm diễn giải không vượt thẩm quyền kế toán.

Options: (1) BA tự ghi rule; (2) BA ghi giả định dự án và chuyển Accounting Owner; (3) Delivery Team tự suy ra từ giao diện.

Decision Criteria: Rule có ảnh hưởng ghi nhận kế toán không; nguồn canonical có kết luận chưa; owner nhận có thẩm quyền kết luận không; quyết định có thể truy vết không.

Decision: Chọn phương án (2). BA ghi câu hỏi, phạm vi tác động và giả định dự án trong artifact đang IN_REVIEW; không gắn nhãn approved hoặc baselined.

Authority: Accounting Owner kết luận ý nghĩa kế toán; Legal Owner xác minh khi có yêu cầu pháp lý; Business Owner quyết định ưu tiên; Architect quyết định cách kỹ thuật; QA Owner quyết định kết quả kiểm thử.

Artifact: Tham chiếu CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md và TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Hai artifact đều IN_REVIEW, v0.9.0, ngày 2026-08-07; không phải nguồn approval.

Consequence if Wrong: BA tự chốt rule có thể làm Delivery Team xây sai thời điểm đổi trạng thái, QA kiểm thử sai test basis, và tạo diễn giải kế toán không được owner có thẩm quyền xác nhận.

Senior Lens

Không chuyển handoff bằng câu “đã thống nhất” nếu artifact không có quyết định và owner có thẩm quyền. Evidence bridge: IN_REVIEW chỉ cho biết nội dung đang xem xét; nó không chứng minh approval, baseline, compliance hay production readiness. Vì vậy BA tách rõ ba trạng thái: fact từ nguồn, project assumption, và Verification required.

Escalate ngay khi một vấn đề thuộc từ hai thẩm quyền trở lên, nguồn canonical mâu thuẫn, hoặc lựa chọn có thể bị hiểu là quyết định pháp lý, kế toán, bảo mật, kiến trúc hay vận hành. BA đóng gói escalation gồm: câu hỏi quyết định, artifact bị ảnh hưởng, bằng chứng nguồn, lựa chọn, tác động nếu chậm quyết định, và owner cần kết luận. BA không chọn thay specialist owner.

Quick Reference

Tình huống	BA làm	BA không làm	Owner nhận
Business rule chưa rõ	Ghi câu hỏi và giả định dự án	Tự biến giả định thành rule	Business Owner hoặc domain owner
Ảnh hưởng hóa đơn, kế toán	Giữ nhãn Verification required	Diễn giải nghĩa vụ kế toán	Accounting Owner, Legal Owner
Ràng buộc bảo mật	Mô tả dữ liệu, luồng, rủi ro	Tự xác nhận an toàn	Security Owner
Không khả thi kỹ thuật	Chuyển requirement và tác động	Tự chọn kiến trúc	Architect
Lỗi hoặc thiếu test evidence	Cập nhật traceability	Tự tuyên bố đạt kiểm thử	QA Owner

Core

Bản đồ vòng đời giúp người mới thấy luồng công việc trước khi đọc chi tiết từng giai đoạn. Với Nova Foods Trading & Manufacturing, đây là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. Sơ đồ không phải BPMN vì dùng Mermaid; BPMN 2.0.2 của OMG là chuẩn riêng cho ký pháp BPMN. Mục đích sơ đồ là giữ cùng một trình tự tham chiếu giữa BA, nghiệp vụ, kỹ thuật và QA trong trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

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

flowchart TB
    D[Discovery<br/>Phát hiện vấn đề và mục tiêu] --> A[Analysis<br/>Phân tích nhu cầu và yêu cầu]
    A --> DV[Delivery<br/>Xây dựng hoặc cấu hình giải pháp]
    DV --> T[Testing<br/>Kiểm thử theo yêu cầu đã phân tích]
    T --> R[Release<br/>Phát hành có kiểm soát]
    R --> O[Operations<br/>Vận hành, theo dõi và phản hồi]

    T -. lỗi hoặc lệch yêu cầu .-> A
    O -. sự cố hoặc thay đổi nhu cầu .-> D

Luồng chính đi từ Discovery đến Operations vì một thay đổi chỉ tạo giá trị khi đi qua phát hiện, làm rõ, xây dựng, kiểm tra, đưa vào sử dụng và theo dõi hậu quả. Các mũi tên quay lại là phản hồi có kiểm soát: lỗi kiểm thử phải được đối chiếu với yêu cầu đã phân tích, còn vấn đề vận hành có thể là nhu cầu mới thay vì lỗi kỹ thuật.

Applied

Trường	Nội dung mô phỏng
Facts	Nova Foods cần hiển thị thứ tự đời sống của thay đổi ERP cho người học mới.
Current Behavior	Không có sơ đồ chung; người học có thể hiểu sai rằng Release là điểm kết thúc.
Underlying Need	Một hình quét nhanh phải cho thấy Operations tạo phản hồi quay về Discovery hoặc Analysis.
Options	1. Danh sách văn bản. 2. Sơ đồ Mermaid vòng đời. 3. BPMN đầy đủ.
Decision Criteria	Dễ đọc trong Markdown; chạy được trên renderer hỗ trợ Mermaid; không tự nhận là BPMN; không thay thế tài liệu chi tiết.
Decision	Dùng Mermaid flowchart có sáu giai đoạn và ba đường phản hồi.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì học liệu; không có thẩm quyền phê duyệt vận hành, kiến trúc, pháp lý hoặc production.
Artifact	/02-handbook/00-foundations.md, mục 3. V? tr? trong Lifecycle, trạng thái IN_REVIEW, phiên bản v0.9.0.
Consequence if Wrong	Nếu bỏ đường phản hồi, người học có thể coi sự cố vận hành là việc của riêng IT và mất truy vết về nhu cầu ban đầu.

Senior Lens

Sơ đồ vòng đời không chứng minh quy trình Nova Foods thực tế. Bằng chứng: CHAPTER_MANIFEST xác định Nova Foods là mô phỏng giáo dục; metadata corpus ghi IN_REVIEW không đồng nghĩa BASELINED hoặc được phê duyệt. Vì vậy, sơ đồ chỉ là mô hình học tập. Khi dự án thật cần ký pháp nghiệp vụ có tính chuẩn hóa, chọn BPMN theo OMG BPMN 2.0.2 và xác minh người sở hữu quy trình trước khi gọi sơ đồ là quy trình chính thức.

Quick Reference

Ký hiệu	Nghĩa
Mũi tên liền	Trình tự làm việc dự kiến
Mũi tên nét đứt	Phản hồi, làm lại hoặc nhu cầu mới
Discovery	Nhận diện vấn đề, cơ hội, mục tiêu
Analysis	Chuyển nhu cầu thành nội dung có thể hiểu và kiểm tra
Delivery	Xây dựng hoặc cấu hình thay đổi
Testing	Kiểm tra thay đổi dựa trên đầu vào đã xác định
Release	Đưa thay đổi vào phạm vi sử dụng được kiểm soát
Operations	Sử dụng, theo dõi, phát hiện vấn đề và phản hồi

4. Input c?n thi?t

Core

Input là thứ BA cần có trước khi phân tích: kiến thức nền, bằng chứng và artifact nguồn. Không có input, BA chỉ đoán. Đoán có thể tạo requirement sai, test sai và thay đổi sai.

Kiến thức nền không đòi hỏi biết lập trình. Người mới cần hiểu: doanh nghiệp có mục tiêu; quy trình là chuỗi người và việc; dữ liệu là thông tin hệ thống lưu; requirement là nhu cầu cần mô tả để đội delivery xây và kiểm tra. Ví dụ, “biết tồn kho còn bao nhiêu” là nhu cầu; mã hàng, số lượng và kho là dữ liệu phục vụ nhu cầu đó.

Bằng chứng là nội dung cho thấy một phát biểu có căn cứ. Bằng chứng có thể là artifact đã kiểm soát, màn hình được cung cấp, báo cáo mẫu, dữ liệu mô phỏng hoặc trao đổi được ghi nhận. Bằng chứng không tự biến thành quyết định nghiệp vụ, phê duyệt hay quy định pháp lý.

Artifact nguồn là tệp hoặc nguồn được nhận diện để BA đọc, tham chiếu và truy vết. Canonical ID là định danh chuẩn, tồn tại bền vững, không đổi theo cách gọi tắt hay bản sao. BA dùng đúng ID để người khác tìm lại cùng nguồn.

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

flowchart TB
    K[Kiến thức nền] --> Q[Câu hỏi BA]
    A[Artifact nguồn] --> E[Bằng chứng]
    E --> Q
    Q --> N[Nội dung phân tích]
    A -->|định danh bởi| I[Canonical ID]
    N --> T[Liên kết truy vết]
    T -->|dùng| I
    T -->|trỏ về| A

Sơ đồ là Mermaid flowchart, không phải BPMN. Lý do dùng sơ đồ: input, bằng chứng và ID có quan hệ dữ liệu-truy vết; người học cần thấy nguồn nào hỗ trợ nội dung nào.

Applied

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

Mục	Nội dung
Facts	Corpus có các artifact được kiểm soát: CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Current Behavior	Người học có thể gọi cùng artifact bằng tên rút gọn như “registry” hoặc “data dictionary”. Cách gọi này không đủ để truy vết chính xác.
Underlying Need	Cần biết trước khi phân tích: đọc nguồn nào, nguồn đó chứng minh điều gì, và dùng ID nào khi ghi liên kết.
Options	Dùng tên tự đặt; dùng tên tệp không có ID; dùng canonical ID cùng đường dẫn tệp kiểm soát.
Decision Criteria	Phải tìm lại được đúng artifact; không nhầm bản sao với nguồn kiểm soát; không suy diễn approval từ trạng thái IN_REVIEW.
Decision	Dùng canonical ID nguyên dạng và đường dẫn canonical khi artifact là đầu vào phân tích.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và liên kết corpus; không có thẩm quyền xác nhận requirement vận hành Nova Foods.
Artifact	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Requirement có thể trỏ nhầm nguồn, mất truy vết, hoặc bị hiểu sai là nội dung đã baseline hay đã phê duyệt.

Cầu nối suy luận: CHAPTER_MANIFEST xác định Nova Foods là mô phỏng giáo dục và status là IN_REVIEW; vì vậy, tên Nova Foods trong input chỉ tạo bối cảnh học tập, không chứng minh fact vận hành. TRACEABILITY_ID_REGISTRY giữ định danh canonical; vì vậy, liên kết phải dùng TRACEABILITY_ID_REGISTRY, không dùng nhãn tự đặt.

Senior Lens

Không coi tài liệu là bằng chứng chỉ vì có vẻ chính thức. Trước hết phân biệt ba lớp. Kiến thức nền giúp hiểu thuật ngữ. Artifact nguồn cung cấp nội dung để tham chiếu. Bằng chứng hỗ trợ một phát biểu cụ thể. Ví dụ, CANONICAL_DATA_DICTIONARY là artifact đầu vào; một định nghĩa trường dữ liệu được trích đúng vị trí trong artifact mới là bằng chứng cho phát biểu về trường đó.

Không tạo ID mới để “cho dễ nhớ”. Canonical ID là khóa truy vết, giống mã hàng trong kho: đổi nhãn tùy ý làm người khác khó xác định cùng đối tượng. Khi gặp bản sao PDF, đoạn trích hoặc ảnh chụp, giữ liên kết về tệp canonical thay vì coi bản sao là nguồn độc lập.

Quick Reference

Khái niệm	Nghĩa thực hành
Kiến thức nền	Hiểu tối thiểu để đặt câu hỏi đúng, không cần biết phần mềm trước
Bằng chứng	Nội dung có thể chỉ ra nguồn hỗ trợ cho một phát biểu
Artifact nguồn	Tệp hoặc nguồn được nhận diện để tham chiếu
Canonical ID	ID chuẩn phải giữ nguyên chuỗi khi truy vết
CHAPTER_MANIFEST	Manifest kiểm soát cấu trúc chapter
TRACEABILITY_ID_REGISTRY	Registry kế hoạch cho định danh truy vết canonical
CANONICAL_BUSINESS_RULES	Catalog kế hoạch cho quy tắc nghiệp vụ canonical
CANONICAL_DATA_DICTIONARY	Kế hoạch từ điển dữ liệu logic canonical
IN_REVIEW	Đang xem xét; không phải APPROVED, BASELINED hay production-ready

Core

Input là thông tin BA dùng để hiểu vấn đề trước khi viết yêu cầu. Input chỉ dùng được khi biết: nguồn tạo ra nó, ai chịu trách nhiệm, thời điểm còn hiệu lực, mức tin cậy, và điều kiện phải dừng. Không có các thuộc tính này, câu nói trong họp chỉ là thông tin chưa kiểm chứng, không phải bằng chứng.

Phân loại nguồn quyết định mức suy luận được phép dùng:

Phân loại	Ý nghĩa	Ví dụ nguồn Nova Foods mô phỏng	Cách dùng
Primary source	Nguồn gốc do cơ quan, tổ chức chuẩn hoặc chủ sở hữu công bố	https://www.iso.org/standard/72089.html, https://spec.openapis.org/oas/v3.1.1.html, https://vanban.chinhphu.vn/?docid=183198&pageid=27160	Dùng để xác minh trạng thái, phạm vi, thuật ngữ công khai. Không suy diễn điều khoản chưa truy cập.
Controlled internal artifact	Artifact corpus có ID, đường dẫn, version và status xác định	TRACEABILITY_ID_REGISTRY, /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Dùng làm nguồn canonical cho ID và quản trị corpus.
Stakeholder statement	Phát biểu từ người có liên quan	Mô tả giả định từ Business Owner trong case Nova Foods	Ghi nhận nhu cầu hoặc giả thuyết. Cần đối chiếu bằng chứng trước khi thành rule.
Project assumption	Giả định phục vụ học liệu hoặc phân tích	Nova Foods dùng VND; dữ liệu là tổng hợp	Giữ nhãn Project assumption; không gọi là fact vận hành.
Verification required	Điểm chưa đủ bằng chứng hoặc cần thẩm quyền chuyên môn	Diễn giải kế toán, thuế, pháp lý, an toàn thực phẩm	Không chuyển thành requirement bắt buộc trước khi đúng owner xác minh.

Kiểm tra chất lượng input theo năm câu hỏi. Đúng nguồn? URL hoặc artifact có phải nguồn canonical không. Đủ ngữ cảnh? Có version, status, phạm vi và ngày truy cập không. Còn mới? Có dấu hiệu thay thế, sửa đổi hoặc phiên bản mới không. Đúng thẩm quyền? Người cung cấp có quyền xác nhận loại thông tin đó không. Truy vết được? Người đọc khác có thể tìm lại cùng bằng chứng không.

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

flowchart TB
    A[Nhận input] --> B{Có nguồn xác định?}
    B -- Không --> X[STOP: không dùng làm căn cứ]
    B -- Có --> C{Có người chịu trách nhiệm?}
    C -- Không --> X
    C -- Có --> D{Nguồn canonical?}
    D -- Có --> F{Có version, status,<br/>phạm vi và ngày truy cập?}
    D -- Không --> E{Đã phân loại đúng:<br/>stakeholder statement,<br/>project assumption hoặc<br/>verification required?}
    E -- Không --> V[Chờ xác minh:<br/>chưa dùng làm căn cứ]
    E -- Có --> F
    F -- Không --> V
    F -- Có --> G{Có dấu hiệu bị thay thế,<br/>sửa đổi hoặc có phiên bản mới?}
    G -- Có --> V
    G -- Không rõ --> V
    G -- Không --> H{Còn hiệu lực<br/>và đúng phạm vi?}
    H -- Không --> X
    H -- Không rõ --> V
    H -- Có --> I{Đúng thẩm quyền<br/>xác nhận thông tin?}
    I -- Không --> V
    I -- Không rõ --> V
    I -- Có --> J{Truy vết lại<br/>cùng bằng chứng được?}
    J -- Không --> V
    J -- Không rõ --> V
    J -- Có --> K{Mức tin cậy<br/>đã đánh giá?}
    K -- Không --> V
    K -- Không rõ --> V
    K -- Có --> L{Điều kiện phải dừng<br/>đã ghi?}
    L -- Không --> V
    L -- Không rõ --> V
    L -- Có --> M{Mâu thuẫn nguồn canonical?}
    M -- Có --> V
    M -- Không rõ --> V
    M -- Không --> N[Đủ điều kiện phân tích]

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 có status IN_REVIEW, version v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

Current Behavior: BA nhận một yêu cầu: “ERP phải lưu chứng từ bán hàng theo luật.” Phát biểu không kèm số văn bản, thời điểm hiệu lực, người xác nhận kế toán hoặc pháp lý.

Underlying Need: Phân biệt nhu cầu lưu chứng từ với kết luận pháp lý hoặc cấu hình ERP bắt buộc.

Options:
1. Viết ngay business rule từ phát biểu.
2. Gắn nhãn Verification required, đối chiếu nguồn chính thức và chuyển cho Accounting Owner hoặc Legal Owner.
3. Bỏ phát biểu khỏi hồ sơ phân tích.

Decision Criteria: Nguồn phải là primary source; hiệu lực phải phù hợp ngày 2026-08-07; diễn giải phải thuộc đúng thẩm quyền; kết quả phải truy vết đến artifact hoặc URL cụ thể.

Decision: Chọn phương án 2. Dùng Nghị định 123/2020/NĐ-CP tại https://vanban.chinhphu.vn/?docid=201365&pageid=27160 như nguồn chính thức cho bối cảnh hóa đơn, nhưng giữ nhãn Verification required vì các sửa đổi sau cần kiểm tra trước khi dùng production.

Authority: Accounting Owner và Legal Owner xác nhận diễn giải kế toán, thuế, chứng từ. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận nguồn, trạng thái và traceability.

Artifact: Ghi liên kết nguồn trong /00-research/00_SOURCE_MAP.md; giữ quản trị ID trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tự tạo approval, baseline hoặc rule canonical.

Consequence if Wrong: Nếu BA biến phát biểu thành rule khi chưa xác minh, ERP mô phỏng có thể dạy sai phạm vi lưu trữ chứng từ. Nếu mang suy luận đó sang production, rủi ro pháp lý, kế toán và truy vết tăng.

Senior Lens

Freshness, hay độ mới của thông tin, không chỉ là ngày tài liệu. Một nguồn cũ vẫn hữu ích nếu còn hiệu lực; một nguồn mới vẫn không đủ nếu không phải nguồn canonical. Với nguồn pháp lý, chuẩn kỹ thuật và API, kiểm tra đồng thời phiên bản, trạng thái xuất bản, ngày truy cập và dấu hiệu thay thế.

Ownership, hay quyền chịu trách nhiệm xác nhận, không bằng quyền sở hữu tệp. Owner của CANONICAL_BUSINESS_RULES giữ tính nhất quán artifact, không được xác nhận rule là đúng cho vận hành. Business Owner xác nhận ý định nghiệp vụ; Accounting Owner xác nhận diễn giải kế toán; Legal Owner xác nhận diễn giải pháp lý; Architect xác nhận tác động kiến trúc; Security xác nhận kiểm soát bảo mật.

Dừng phân tích (STOP) khi gặp ít nhất một điều kiện: không xác định được nguồn; ID không có trong nguồn canonical; nguồn mâu thuẫn; nguồn pháp lý chưa xác minh nhưng đang bị viết thành nghĩa vụ; owner không có thẩm quyền; hoặc input đòi quyết định production. Dừng không phải thất bại. Dừng ngăn BA biến khoảng trống bằng chứng thành quyết định giả.

Quick Reference

Kiểm tra	Đạt khi	Không đạt thì
Source classification	Đã gắn Primary source, Controlled internal artifact, Stakeholder statement, Project assumption hoặc Verification required	Gắn nhãn chưa xác định và không dùng làm căn cứ quyết định
Freshness	Có version/status, ngày truy cập 2026-08-07 hoặc ngày artifact cập nhật	Kiểm tra nguồn thay thế trước khi suy luận
Ownership	Có vai trò đúng thẩm quyền xác nhận loại nội dung	Escalate đến Business Owner, Legal Owner, Accounting Owner, Architect, Security hoặc QA
Traceability	Có URL chính thức hoặc đường dẫn canonical đầy đủ	Không tạo ID mới, không trích dẫn như fact
Stop condition	Không có mâu thuẫn, thiếu nguồn hoặc vượt thẩm quyền	Đặt STOP hoặc Verification required; không viết requirement bắt buộc

Core

Bảng dưới là inventory đầu vào cho Nova Foods Trading & Manufacturing, case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Mỗi dòng giữ Artifact ID và đường dẫn canonical. Verification required nghĩa là chưa đủ bằng chứng để dùng làm kết luận, rule, cấu hình ERP hay nghĩa vụ pháp lý.

Applied

ID đầu vào	Artifact / bằng chứng	Phân loại nguồn	Giá trị tổng hợp dùng trong ví dụ	Freshness	Owner ghi nhận	Trạng thái xác minh	Mục chưa giải quyết
00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Primary-source map	Access date URL: 2026-08-07	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Có nguồn chính thức, IN_REVIEW	Không thay thế toàn văn chuẩn có license
01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Locale vi-VN; timezone Asia/Ho_Chi_Minh; tiền tệ VND	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Không có baseline reference
CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Authoritative manifest	Chapter mục tiêu: /02-handbook/00-foundations.md	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Không có approval reference
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact	Template là kế hoạch, không phải biểu mẫu production	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Xác minh template nào được dùng khi tạo artifact thực
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical ID registry plan	Dùng nguyên chuỗi ID canonical khi liên kết artifact	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Xác minh ID mới trước khi đăng ký hoặc sử dụng
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan	Không coi rule mô phỏng là rule vận hành	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Verification required: Business Owner xác nhận rule nghiệp vụ
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical logical-data plan	Ví dụ dữ liệu: mã hàng NF-RM-001, số lượng 250, giá trị 12500000 VND	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Verification required: data owner xác nhận định nghĩa và mã dữ liệu
SRC-LAW-PD-001	Luật 91/2025/QH15	Official legal source	Hiệu lực ghi nhận: 2026-01-01	Access date 2026-08-07	Legal Owner cần xác minh diễn giải	Nguồn chính thức có URL trong 00_SOURCE_MAP	Verification required: requirement ERP phát sinh từ luật
SRC-LAW-ACC-001	Luật 88/2015/QH13	Official legal source	Bối cảnh kế toán Việt Nam	Access date 2026-08-07	Accounting Owner cần xác minh diễn giải	Nguồn chính thức có URL trong 00_SOURCE_MAP	Verification required: hạch toán, chứng từ, retention
SRC-LAW-FS-001	Luật 55/2010/QH12	Official legal source	Bối cảnh truy xuất và thu hồi thực phẩm	Access date 2026-08-07	Legal Owner và Food-safety Owner cần xác minh	Nguồn chính thức có URL trong 00_SOURCE_MAP	Verification required: phạm vi traceability của ERP

Applied case field	Nội dung
Facts	Corpus ở IN_REVIEW, version v0.9.0, ngày 2026-08-07; Nova Foods là mô phỏng; bảng có đầu vào legal và nghiệp vụ chưa xác minh.
Current Behavior	Learner có thể thấy artifact tồn tại rồi nhầm thành rule đã đúng hoặc đã được phê duyệt.
Underlying Need	Phân biệt bằng chứng đã ghi nhận với kết luận được vai trò có thẩm quyền xác nhận.
Options	Dùng mọi dòng như fact; chỉ dùng dòng đã xác minh; dùng toàn bộ nhưng gắn nhãn trạng thái.
Decision Criteria	Không làm mất traceability; không tạo approval ngầm; không biến nguồn pháp lý thành diễn giải pháp lý.
Decision	Dùng toàn bộ làm inventory; chỉ dòng có trạng thái phù hợp mới làm căn cứ viết tiếp; giữ nguyên Verification required cho điểm mở.
Authority	Principal IT Business Analyst / Technical Curriculum Author quản trị artifact; Legal Owner, Accounting Owner, Food-safety Owner, Business Owner xác minh nội dung thuộc thẩm quyền.
Artifact	Bảng input inventory trong /02-handbook/00-foundations.md, section 04-inputs.
Consequence if Wrong	Requirement có thể dựa trên dữ liệu cũ, ID sai, hoặc diễn giải pháp lý chưa được xác minh; traceability và quyết định sau đó mất căn cứ.

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

flowchart TB
    A[Input artifact hoặc nguồn pháp lý]

    subgraph GOV["Quản trị artifact — Principal IT Business Analyst / Technical Curriculum Author"]
        P[Giữ mọi đầu vào trong inventory<br/>và ghi trạng thái]
        B{"Truy vết được bằng<br/>canonical ID + artifact path<br/>hoặc official-source URL trong 00_SOURCE_MAP?"}
        T[Chỉ giữ trong inventory<br/>Không dùng làm căn cứ viết tiếp<br/>Bổ sung hoặc sửa thông tin truy vết]
        C{"Freshness đã được đánh giá<br/>cho mục đích sử dụng?"}
        H[Chỉ giữ trong inventory<br/>Không dùng làm căn cứ viết tiếp<br/>Đánh giá lại freshness]
        K[Kiểm tra điểm mở áp dụng<br/>baseline reference; license hoặc toàn văn chuẩn;<br/>template đã dùng; ID mới trước đăng ký hoặc sử dụng]
        L{"Điểm mở material áp dụng<br/>đã được xử lý?"}
        M[Chỉ giữ trong inventory<br/>Không dùng làm căn cứ viết tiếp<br/>Giữ nhãn điểm mở]
        G{"Trạng thái phù hợp với mục đích sử dụng<br/>và nội dung đã được owner có thẩm quyền xác nhận?"}
        D[Dùng làm bằng chứng có truy vết]
        X[Giữ trong inventory với<br/>Verification required hoặc IN_REVIEW<br/>Không dùng làm căn cứ viết tiếp]
        R[Không được chấp nhận làm căn cứ<br/>Vẫn giữ kết quả trong inventory]
    end

    subgraph AUTH["Xác minh nội dung — owner có thẩm quyền"]
        O[Legal Owner: diễn giải pháp lý<br/>Accounting Owner: hạch toán, chứng từ, retention<br/>Food-safety Owner: traceability và thu hồi<br/>Business Owner: rule nghiệp vụ<br/>Data Owner: định nghĩa và mã dữ liệu]
        W{"Kết quả xác minh?"}
    end

    A --> P --> B
    B -- Không --> T
    B -- Có --> C
    T --> B
    C -- Chưa --> H
    C -- Có --> K --> L
    H --> C
    L -- Chưa --> M
    L -- Đã xử lý --> G
    M --> K
    G -- Có --> D
    G -- "IN_REVIEW, Verification required hoặc chưa phù hợp" --> X
    X --> O --> W
    W -- Xác nhận --> G
    W -- Chưa xác nhận --> X
    W -- Không chấp nhận --> R

    Z[Nếu bỏ qua kiểm soát<br/>truy vết, freshness hoặc xác minh] --> U[Requirement có thể dựa trên dữ liệu cũ,<br/>ID sai hoặc diễn giải pháp lý chưa xác minh;<br/>mất traceability và căn cứ quyết định]
    B -. kiểm soát .-> Z
    C -. kiểm soát .-> Z
    G -. kiểm soát .-> Z

Senior Lens

Freshness không chỉ là ngày tệp. Freshness là ngày mà BA biết nguồn được kiểm tra lần cuối. Ví dụ URL pháp lý được truy cập ngày 2026-08-07, nhưng requirement ERP vẫn phải là Verification required nếu Legal Owner chưa kết luận cách áp dụng cho Nova Foods mô phỏng.

Quick Reference

Dùng nguyên IN_REVIEW, v0.9.0, Artifact ID, tên tệp và đường dẫn canonical. Không đổi nhãn chưa xác minh thành rule, approval, baseline, compliance hay cấu hình production.

5. Step-by-step BA Activities

Core

BA biến nhu cầu mơ hồ thành artifact có thể review. Mỗi bước phải nêu người làm, đối tượng, bằng chứng, điều kiện quyết định, cổng chất lượng và tuyến escalation. Evidence là bằng chứng kiểm tra được; quality gate là điểm dừng chỉ cho phép đi tiếp khi điều kiện tối thiểu đạt. Không có evidence thì không suy diễn requirement.

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. Quy trình áp dụng cho yêu cầu ERP: kiểm soát xuất kho theo lô hàng.

Mục	Nội dung
Facts	Kho thành phẩm mô phỏng có thể xuất LO-260801-A trước LO-260731-B dù LO-260731-B có ngày hết hạn sớm hơn.
Current Behavior	Nhân viên kho chọn lô thủ công; ERP mô phỏng chưa hiển thị cảnh báo thứ tự ưu tiên.
Underlying Need	Giảm rủi ro chọn lô không phù hợp bằng quy tắc lựa chọn lô có căn cứ nghiệp vụ.
Options	Cảnh báo không chặn; chặn xuất khi còn lô ưu tiên; tự động đề xuất lô nhưng cho phép ghi nhận ngoại lệ.
Decision Criteria	Không làm mất traceability; ngoại lệ phải có lý do; Business Owner xác nhận ảnh hưởng vận hành; Food-safety Owner xác minh điểm liên quan an toàn thực phẩm.
Decision	Chọn tự động đề xuất lô và yêu cầu lý do khi người dùng đổi lô. Đây là project assumption, IN_REVIEW, không phải cấu hình ERP đã phê duyệt.
Authority	Business Owner quyết định vận hành; Food-safety Owner xác minh ngữ cảnh truy xuất; Architect xác minh khả năng kỹ thuật; QA xác minh test basis.
Artifact	Bản nháp requirement và decision log trong /02-handbook/00-foundations.md; liên kết nguồn quản trị tại /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	ERP có thể ưu tiên lô sai, không lưu được ngoại lệ, hoặc biến giả định học liệu thành quy tắc vận hành.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị	BA	Đọc phạm vi, trạng thái và input canonical trước phiên làm việc.	/01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, source map.	Danh sách input kèm trạng thái IN_REVIEW và điểm Verification required.	Chỉ dùng ID, đường dẫn, trạng thái có trong artifact canonical.	Không có ID sai, không gọi input là baseline hay approval.	ID hoặc nguồn mâu thuẫn: Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề.
2. Ghi nhận facts	BA và Warehouse Representative	Ghi hiện trạng theo quan sát mô phỏng, tách fact khỏi diễn giải.	Thứ tự chọn LO-260801-A, LO-260731-B; ngày hết hạn tổng hợp.	Bảng Facts và Current Behavior.	Fact phải nêu được ai làm gì với dữ liệu nào; chưa rõ thì gắn Verification required.	Không có fact dựa trên suy đoán hoặc lời kể không phân biệt nguồn.	Thiếu bằng chứng vận hành: Business Owner hoặc Warehouse Representative làm rõ.
3. Phân tích nhu cầu	BA	Truy từ hành vi hiện tại đến hậu quả và nhu cầu cần giải quyết.	Rủi ro chọn lô, khả năng truy vết ngoại lệ.	Underlying Need và phạm vi loại trừ.	Nhu cầu mô tả kết quả cần đạt, không khóa trước giao diện hay giải pháp.	Có reasoning bridge: fact dẫn tới hậu quả, hậu quả dẫn tới need.	Có ảnh hưởng an toàn thực phẩm: Food-safety Owner xác minh; có dữ liệu cá nhân: Legal Owner xác minh.
4. So sánh lựa chọn	BA, Business Owner, Architect	Liệt kê phương án và tác động nghiệp vụ, dữ liệu, tích hợp.	Cảnh báo, chặn xuất, tự động đề xuất kèm ngoại lệ.	Options và Decision Criteria.	Không chọn phương án chỉ vì dễ xây; phải so với traceability, vận hành và khả năng kỹ thuật.	Mỗi option có lợi ích, rủi ro, điều kiện và owner xác minh.	Khả năng ERP hoặc tích hợp chưa rõ: Architect xác minh.
5. Đề xuất quyết định	BA	Soạn quyết định có trạng thái, giả định và giới hạn thẩm quyền.	Phương án tự động đề xuất lô, đổi lô cần lý do.	Decision, Authority, Consequence if Wrong.	Chỉ Business Owner quyết định vận hành; BA không tự ghi approval.	Decision mang nhãn IN_REVIEW; project assumption không bị viết thành rule đã xác nhận.	Tranh chấp ưu tiên: Business Owner quyết định; xung đột an toàn thực phẩm: Food-safety Owner quyết định chuyên môn.
6. Review chất lượng	BA và QA Reviewer	Kiểm tra đầy đủ, nhất quán, kiểm thử được và truy vết được.	Requirement draft, rule, dữ liệu lô, ngoại lệ.	Review record nêu lỗi, sửa và điểm mở.	Mỗi requirement phải truy được về fact hoặc need; mỗi ngoại lệ phải có dữ liệu ghi nhận.	Không còn mâu thuẫn giữa Current Behavior, Decision và Consequence; điểm mở còn lại gắn Verification required.	Không viết được acceptance criterion kiểm thử: QA Reviewer trả về BA; rule không rõ: Business Owner làm rõ.
7. Controlled handoff	BA	Bàn giao gói review, không bàn giao như production instruction.	Requirement draft, decision log, review record, nguồn tham chiếu.	Handoff package kèm trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.	Chỉ bàn giao khi evidence, owner và điểm mở đều hiển thị.	Người nhận phân biệt được fact, assumption, decision đang review và Verification required.	Thiếu owner, nguồn hoặc trạng thái: dừng handoff; Principal IT Business Analyst / Technical Curriculum Author điều phối sửa traceability.

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

flowchart TB
    A[Chuẩn bị input canonical<br/>ID, nguồn, trạng thái] --> B[Ghi nhận Facts và Current Behavior]
    B --> C[Phân tích Underlying Need]
    C --> D[So sánh Options và Decision Criteria]

    D --> E{Evidence đủ và đã xác minh?}
    E -- Chưa xác minh --> V[Đánh dấu Verification required<br/>và nêu owner xác minh]
    V --> V1[Owner cung cấp hoặc xác nhận evidence]
    V1 --> E
    E -- Thiếu bằng chứng vận hành --> E1[Business Owner hoặc<br/>Warehouse Representative làm rõ]
    E -- Khả năng kỹ thuật chưa rõ --> E2[Architect xác minh]
    E -- Điểm an toàn thực phẩm --> E3[Food-safety Owner xác minh]
    E -- Dữ liệu cá nhân --> E4[Legal Owner xác minh]
    E -- Nguồn hoặc ID mâu thuẫn --> E5[Principal IT Business Analyst /<br/>Technical Curriculum Author lập gói vấn đề]
    E1 --> B
    E2 --> D
    E3 --> C
    E4 --> C
    E5 --> A

    E -- Có --> F{Đúng authority?}
    F -- Không --> F1[Business Owner quyết định vận hành<br/>Food-safety Owner quyết định chuyên môn]
    F1 --> D
    F -- Có --> G[BA soạn Decision IN_REVIEW:<br/>tự động đề xuất lô;<br/>đổi lô phải ghi lý do;<br/>nêu assumption và giới hạn thẩm quyền]
    G -. Nếu quyết định sai hoặc assumption bị dùng như production rule .-> Z1[Risk: ưu tiên sai lô;<br/>mất ghi nhận ngoại lệ;<br/>assumption thành production rule]
    G --> H[BA và QA Reviewer review<br/>traceability và testability]

    H --> I{Quality gate đạt?}
    I -- Acceptance criterion không kiểm thử được --> J[BA sửa requirement hoặc acceptance criterion]
    I -- Rule không rõ --> K[Business Owner làm rõ rule]
    I -- Requirement chưa truy về fact hoặc need --> L[BA bổ sung traceability<br/>về fact hoặc need]
    I -- Ngoại lệ thiếu dữ liệu ghi nhận --> L1[BA bổ sung dữ liệu ghi nhận ngoại lệ]
    I -- Need chưa nhất quán --> C
    I -- Options chưa nhất quán --> D
    I -- Decision chưa nhất quán --> G
    I -- Traceability thiếu hoặc mâu thuẫn --> M[Principal IT Business Analyst /<br/>Technical Curriculum Author sửa traceability]
    J --> H
    K --> G
    L --> H
    L1 --> H
    M --> A

    I -- Có --> N{Evidence, owner và điểm mở<br/>đều hiển thị?}
    N -- Không --> Q[Dừng handoff]
    Q --> R{Thiếu gì?}
    R -- Evidence hoặc điểm mở chưa xác minh --> V
    R -- Owner thiếu hoặc không rõ --> F
    R -- Nguồn, ID hoặc traceability thiếu --> M
    N -- Có --> O[BA controlled handoff<br/>IN_REVIEW, v0.9.0, 2026-08-07]
    O --> P[Review package<br/>không phải production instruction]

Senior Lens

“Đề xuất lô” là giải pháp; “giảm rủi ro chọn lô không phù hợp và lưu ngoại lệ” là nhu cầu. BA phải giữ hai lớp này tách nhau. Evidence từ kho chỉ chứng minh current behavior; không tự chứng minh nghĩa vụ pháp lý hay quy tắc an toàn thực phẩm. Các kết luận đó cần owner có thẩm quyền xác minh.

Quick Reference

Dừng ngay khi thiếu source canonical, thiếu owner quyết định, hoặc requirement không nối được từ fact đến need. Handoff chỉ chuyển artifact IN_REVIEW; không tạo baseline, approval, compliance hoặc quyền triển khai production.

Applied

Quy trình này dùng cho Nova Foods Trading & Manufacturing mô phỏng, 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, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. BA không tự xác nhận quy tắc, pháp lý, kế toán, kiến trúc hay phê duyệt. “Bằng chứng” là vật ghi nhận được để người khác kiểm tra lại; “quality gate” là cổng chất lượng, không đạt thì không chuyển bước.

Bước	Actor	Action và object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	Business Analyst	Đọc mục tiêu thay đổi, source map và artifact upstream; lập danh sách phạm vi, giả định, câu hỏi và nguồn cho đối tượng yêu cầu.	Phiếu chuẩn bị ghi tham chiếu 00_SOURCE_MAP, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.	Chỉ dùng ID, đường dẫn, trạng thái và phân loại nguồn đã có. Thiếu nguồn canonical thì ghi Verification required, không suy diễn thành quy tắc.	Mỗi nhận định có nguồn hoặc nhãn giả định; không có dữ liệu thật Nova Foods.	Mâu thuẫn ID hoặc nguồn: Principal IT Business Analyst / Technical Curriculum Author. Nội dung pháp lý, kế toán, bảo mật, kiến trúc: owner chuyên môn tương ứng.
2. Thu thập hành vi hiện tại	Business Analyst cùng SME nghiệp vụ	Ghi nhận luồng hiện tại, dữ liệu vào/ra, vai trò, ngoại lệ và điểm đau cho đối tượng nghiệp vụ. SME là chuyên gia miền nghiệp vụ, cung cấp ngữ cảnh nhưng không tự tạo nguồn canonical.	Biên bản fact log: quan sát, người cung cấp, thời điểm, dữ liệu tổng hợp, nguồn và mức tin cậy.	Tách Fact khỏi diễn giải: Fact phải truy về quan sát hoặc nguồn; diễn giải phải nêu cầu nối lý do từ Fact.	Không có phát biểu “hệ thống phải” nếu chưa xác định need, authority và rule nguồn.	Fact mâu thuẫn giữa SME: Business Owner quyết định ý nghĩa nghiệp vụ; BA giữ cả hai bằng chứng và câu hỏi mở.
3. Phân tích need và lựa chọn	Business Analyst	So sánh Current Behavior với Underlying Need, tức nhu cầu gốc cần đạt; lập các phương án và tiêu chí quyết định cho đối tượng thay đổi.	Bảng phân tích gồm Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Authority và risk.	Chọn phương án chỉ khi đáp ứng mục tiêu, không trái nguồn canonical, có owner thẩm quyền và rủi ro được nêu. Không chọn vì “thường làm vậy”.	Mỗi option có hệ quả, dữ liệu ảnh hưởng, dependency và lý do loại/chọn.	Có ảnh hưởng tích hợp hoặc mô hình dữ liệu: Architect. Có kiểm soát truy cập hoặc dữ liệu cá nhân: Security và Legal/Compliance Owner.
4. Soạn yêu cầu kiểm tra được	Business Analyst	Chuyển decision thành requirement, business rule, data requirement hoặc acceptance criterion; gắn ID canonical nếu registry đã cấp.	Bản yêu cầu có truy vết từ need đến evidence, nguồn, owner, giả định và tiêu chí kiểm tra.	Một yêu cầu chỉ diễn đạt một kết quả cần đạt; điều kiện, dữ liệu, actor và kết quả phải phân biệt rõ. ID chưa đăng ký thì không tự tạo biến thể ID.	Reviewer độc lập đọc được cùng nghĩa, xác định được dữ liệu đầu vào và kết quả mong đợi.	Thiếu ID: quản trị TRACEABILITY_ID_REGISTRY. Rule nghiệp vụ: Business Owner. Rule pháp lý/kế toán: Legal hoặc Accounting Owner.
5. Review và handoff có kiểm soát	Business Analyst, reviewer đúng thẩm quyền	Gửi gói review gồm evidence, quyết định, yêu cầu, điểm chưa xác minh và traceability; ghi phản hồi theo từng item. Handoff là bàn giao có kiểm soát, không phải approval.	Review log, danh sách thay đổi, trạng thái từng item và tham chiếu artifact nhận bàn giao.	Chỉ chuyển tiếp item qua quality gate khi phản hồi trọng yếu được xử lý, hoặc còn mở nhưng gắn owner, deadline và nhãn Verification required.	Không gọi là APPROVED hoặc BASELINED; IN_REVIEW vẫn là đang xem xét.	Phản hồi vượt thẩm quyền BA hoặc làm đổi phạm vi: Business Owner và Principal IT Business Analyst / Technical Curriculum Author; tranh chấp chuyên môn chuyển owner chuyên môn.

Cầu nối suy luận phải viết rõ: “Fact: phiếu nhập kho mô phỏng thiếu mã lô; Current Behavior: truy vết theo tên hàng; Underlying Need: phân biệt các lô cùng tên khi có sự cố; vì tên hàng không là khóa duy nhất nên cần xác minh dữ liệu mã lô trước khi đề xuất yêu cầu.” Câu này không xác nhận nghĩa vụ an toàn thực phẩm; mọi chi tiết pháp lý và truy xuất thực tế giữ nhãn Verification required cho Legal Owner và domain owner.

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. Bảng mô phỏng cách BA biến một vấn đề ERP thành gói xem xét có kiểm soát. IN_REVIEW tại v0.9.0 nghĩa là đang xem xét, không phải baseline hay phê duyệt.

Mục	Nội dung thực hiện
Facts	Kho mô phỏng ghi nhận 120 thùng thành phẩm, nhưng màn hình bán hàng mô phỏng vẫn cho phép hứa giao 150 thùng. Dữ liệu chênh lệch xuất hiện trong bản trích tổng hợp của case study.
Current Behavior	ERP giả định kiểm tra số lượng tồn tổng, không tách số lượng đã giữ cho đơn hàng. Nhân viên bán hàng có thể tạo cam kết giao vượt lượng khả dụng.
Underlying Need	Cần xác định liệu quy tắc phân bổ tồn kho phải dùng “tồn khả dụng” thay vì “tồn tổng”, và vai trò nào sở hữu quyết định nghiệp vụ này. Suy luận: hành vi hiện tại cho phép cam kết 150 khi chỉ có 120; chênh 30 tạo rủi ro giao thiếu.
Options	(1) Giữ kiểm tra tồn tổng. (2) Chặn đơn khi số lượng yêu cầu lớn hơn tồn khả dụng. (3) Cho tạo đơn vượt tồn nhưng bắt buộc trạng thái chờ phê duyệt.
Decision Criteria	Giảm giao thiếu; không tự diễn giải kế toán; giữ traceability; có Business Owner xác nhận chính sách bán hàng; Architect xác nhận khả năng dữ liệu.
Decision	Chưa chọn phương án vận hành. Ghi nhận Option 2 và Option 3 để xem xét vì cả hai xử lý chênh lệch 30 thùng. Không gọi là yêu cầu đã phê duyệt.
Authority	Business Owner quyết định chính sách nhận đơn; Architect xác nhận mô hình dữ liệu và luồng ERP; QA Reviewer kiểm tra tiêu chí kiểm thử; Principal IT Business Analyst / Technical Curriculum Author duy trì gói truy vết.
Artifact	Liên kết vấn đề với /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Các artifact đều IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu hiểu “tồn tổng” là “tồn khả dụng”, ERP mô phỏng có thể hứa giao vượt hàng có thể phân bổ. Nếu BA tự chọn chính sách, artifact vượt thẩm quyền Business Owner.

Bước thực thi mô phỏng	Actor	Action trên object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Ghi nhận chênh lệch	BA	So sánh số lượng yêu cầu 150 với tồn 120 trong dữ liệu tổng hợp	Bảng Facts và phép tính chênh lệch 30 thùng	Chênh lệch khác 0 phải thành vấn đề truy vết	Có nguồn dữ liệu mô phỏng, không gán thành sự kiện thật	Data Owner khi định nghĩa số lượng không rõ
2. Phân tách thuật ngữ	BA	Đối chiếu “tồn tổng”, “tồn giữ chỗ”, “tồn khả dụng” với CANONICAL_DATA_DICTIONARY	Danh sách thuật ngữ và giả định cần xác minh	Không tự đồng nhất hai trường dữ liệu khác nghĩa	Mỗi thuật ngữ có nguồn canonical hoặc nhãn Verification required	Architect và Data Owner
3. Mô hình hóa luồng	BA	Vẽ trạng thái đơn hàng từ kiểm tra tồn đến chờ quyết định	Mermaid diagram dưới đây	Luồng phải chỉ rõ điểm chặn và người quyết định	Diagram chạy được, không gọi là BPMN	Architect khi trạng thái hay tích hợp chưa rõ
4. So sánh phương án	BA	Đánh giá Option 1–3 theo tiêu chí đã nêu	Bảng quyết định trong gói review	Không chọn phương án nếu thiếu thẩm quyền	Tiêu chí gắn trực tiếp Facts và Underlying Need	Business Owner
5. Handoff có kiểm soát	BA	Chuyển gói review, giữ trạng thái IN_REVIEW	Liên kết artifact canonical và vấn đề chưa quyết	Không dùng từ baseline hoặc approved	Không có ID, quy tắc, dữ liệu bị sửa im lặng	Principal IT Business Analyst / Technical Curriculum Author điều phối; quyết định chuyển đúng owner

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

flowchart TB
    A[Đơn bán hàng mô phỏng: yêu cầu 150 thùng] --> B[Đọc tồn tổng: 120 thùng]
    B --> C{Định nghĩa tồn khả dụng đã xác minh trong CANONICAL_DATA_DICTIONARY?}

    C -- Không --> D[Ghi Verification required]
    D --> E[Data Owner và Architect xác minh định nghĩa]
    E --> F{Đã xác minh được định nghĩa?}
    F -- Có --> G[Đọc hoặc tính tồn khả dụng]
    F -- Không --> J[Giữ gói ở trạng thái IN_REVIEW]

    C -- Có --> G
    G --> H{Số lượng yêu cầu có nhỏ hơn hoặc bằng tồn khả dụng?}

    H -- Có --> I[BA ghi nhận để xem xét phân bổ; chưa chấp nhận đơn]
    I --> J

    H -- Không --> K[BA đưa Option 2 và Option 3 vào gói review]
    K --> L[Business Owner quyết định chính sách nhận đơn]
    L --> M{Business Owner chọn phương án nào?}
    M -- Option 2 --> N[Ghi Option 2 vào gói review]
    M -- Option 3 --> O[Ghi Option 3 vào gói review]
    M -- Chưa chọn --> J
    N --> P[Chưa là phê duyệt hay baseline]
    O --> P
    P --> J

Mermaid mô tả luồng, không phải BPMN. Điểm quyết định “có định nghĩa tồn khả dụng đã xác minh” bảo vệ BA khỏi suy diễn dữ liệu; điểm quyết định chính sách thuộc Business Owner bảo vệ ranh giới thẩm quyền.

6. Output thu ???c

Core

Output là artifact có kiểm soát: tệp hoặc phần cập nhật mang bằng chứng BA đã cấu trúc thông tin đầu vào thành nội dung có thể truy vết. Output không tự biến thành quyết định nghiệp vụ, baseline, approval, cấu hình ERP hay bằng chứng sẵn sàng production. Bằng chứng: toàn corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07; suy ra mọi output phải giữ trạng thái này.

Micro-batch này không tạo ID nghiệp vụ mới. Lý do: TRACEABILITY_ID_REGISTRY là nguồn quản lý ID canonical; tự đặt ID cho requirement, rule, data field hoặc interface sẽ phá traceability. Output hợp lệ là cập nhật có kiểm soát vào artifact canonical đã tồn tại.

Artifact canonical	Owner	Status	Nội dung tối thiểu khi cập nhật	Nghĩa vụ lịch sử thay đổi
00_SOURCE_MAP	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Nguồn, issuer, version/status, URL chính thức, ngày truy cập, safe use boundary	Ghi ngày 2026-08-07, version, phần đổi, lý do đổi, nguồn bị ảnh hưởng
TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	ID canonical, loại đối tượng, artifact tham chiếu, trạng thái đăng ký, owner quản trị	Không tái dùng ID; ghi thêm dòng lịch sử thay vì sửa im lặng định nghĩa ID
CANONICAL_BUSINESS_RULES	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Quy tắc, evidence, phạm vi, assumption hoặc Verification required, owner thẩm quyền cần xác nhận	Ghi rule bị thêm, sửa hoặc rút; giữ lý do và liên kết evidence
CANONICAL_DATA_DICTIONARY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Tên dữ liệu, nghĩa nghiệp vụ, nguồn dữ liệu, kiểu logic, phân loại, assumption hoặc Verification required	Ghi field thay đổi, tác động traceability và vai trò cần xác nhận

Mỗi cập nhật phải giữ nguyên Artifact ID, đường dẫn canonical, status, version, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, bối cảnh Việt Nam và tiền tệ mô phỏng VND. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là dữ liệu tổng hợp.

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

flowchart TB
    A[Evidence mô phỏng hoặc nguồn xác minh] --> B[Principal IT Business Analyst /<br/>Technical Curriculum Author xác định artifact bị ảnh hưởng]
    B --> C[Đánh giá độc lập từng artifact canonical<br/>Có thể chọn nhiều]

    C -->|Nguồn bị ảnh hưởng| D[00_SOURCE_MAP]
    C -->|ID hoặc liên kết bị ảnh hưởng| E[TRACEABILITY_ID_REGISTRY]
    C -->|Quy tắc bị ảnh hưởng| F[CANONICAL_BUSINESS_RULES]
    C -->|Field dữ liệu bị ảnh hưởng| G[CANONICAL_DATA_DICTIONARY]
    C -->|Không xác định được artifact| X[Không tạo ID hoặc artifact mới]
    X --> V[Yêu cầu owner xác minh<br/>Verification required]
    V --> C

    D --> D1[Kiểm tra nội dung tối thiểu:<br/>nguồn, issuer, version/status, URL chính thức,<br/>ngày truy cập, safe use boundary]
    D1 --> D2[Ghi change history:<br/>2026-08-07, version, phần đổi, lý do đổi,<br/>nguồn bị ảnh hưởng]

    E --> E1[Kiểm tra nội dung tối thiểu:<br/>ID canonical, loại đối tượng, artifact tham chiếu,<br/>trạng thái đăng ký, owner quản trị]
    E1 --> E2[Không tái dùng ID;<br/>ghi dòng lịch sử mới, không sửa im lặng định nghĩa ID]

    F --> F1[Kiểm tra nội dung tối thiểu:<br/>quy tắc, evidence, phạm vi,<br/>assumption hoặc Verification required,<br/>owner thẩm quyền cần xác nhận]
    F1 --> F2[Ghi rule thêm, sửa hoặc rút;<br/>giữ lý do và liên kết evidence]

    G --> G1[Kiểm tra nội dung tối thiểu:<br/>tên dữ liệu, nghĩa nghiệp vụ, nguồn dữ liệu,<br/>kiểu logic, phân loại,<br/>assumption hoặc Verification required]
    G1 --> G2[Ghi field thay đổi,<br/>tác động traceability và vai trò cần xác nhận]

    D2 --> J[Giữ nguyên:<br/>Artifact ID, đường dẫn canonical, status IN_REVIEW,<br/>version v0.9.0, locale vi-VN, Asia/Ho_Chi_Minh,<br/>bối cảnh Việt Nam, VND]
    E2 --> J
    F2 --> J
    G2 --> J

    J --> K[Artifact canonical cập nhật<br/>vẫn IN_REVIEW]

Applied

Ví dụ Nova Foods mô phỏng dùng đơn bán hàng tổng hợp SO-SIM-20260807-01, yêu cầu 150 thùng hàng. Chuỗi này là dữ liệu ví dụ, không phải ID canonical mới đăng ký.

Mục	Nội dung điền cho micro-example
Facts	Đơn mô phỏng yêu cầu 150 thùng; dữ liệu tồn khả dụng chưa có định nghĩa canonical được xác minh.
Current Behavior	BA có thể ghi nhận chênh lệch yêu cầu và tồn được báo cáo, nhưng chưa thể kết luận có đủ hàng để phân bổ.
Underlying Need	Cần truy vết rõ nguồn số tồn, nghĩa của “tồn khả dụng”, rule phân bổ và ID dùng để liên kết các nội dung này.
Options	Option 1: ghi kết luận đủ hàng. Option 2: tạo output có nhãn Verification required, chưa kết luận.
Decision Criteria	Không suy diễn rule từ dữ liệu chưa xác minh; không tạo ID ngoài registry; không vượt thẩm quyền Data Owner, Business Owner hoặc Architect.
Decision	Chọn Option 2. Cập nhật artifact canonical hiện có, giữ IN_REVIEW.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact. Data Owner xác minh nghĩa dữ liệu. Business Owner quyết định chính sách phân bổ. Architect xác minh tác động hệ thống nếu có.
Artifact	CANONICAL_DATA_DICTIONARY: ghi khái niệm “tồn khả dụng” với nhãn Verification required; CANONICAL_BUSINESS_RULES: ghi nhu cầu rule phân bổ, chưa diễn đạt thành rule đã xác nhận; TRACEABILITY_ID_REGISTRY: kiểm tra liên kết ID, không cấp ID mới; 00_SOURCE_MAP: chỉ cập nhật nếu bổ sung nguồn xác minh.
Consequence if Wrong	Kết luận đủ hàng từ số liệu chưa rõ nghĩa có thể tạo requirement sai, test basis sai, thiết kế phân bổ sai và mất truy vết nguồn.

Senior Lens

Owner của artifact chịu trách nhiệm tính toàn vẹn quản trị, không sở hữu mọi quyết định nội dung. Bằng chứng: metadata upstream giới hạn Owner khỏi legal, accounting, security, architecture, business approval và production authority. Suy ra change history phải ghi cả phần chưa xác minh, không biến assumption thành fact.

Không dùng cụm “đã chốt”, “đã phê duyệt”, “đã baseline”, “tuân thủ” hoặc “sẵn sàng production” cho output này. IN_REVIEW chỉ nói artifact đang được xem xét có kiểm soát.

Quick Reference

Quy tắc	Áp dụng
Giữ ID canonical	Dùng đúng 00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Không tự tạo ID	Chờ đăng ký theo TRACEABILITY_ID_REGISTRY.
Ghi lịch sử thay đổi	Ghi version, ngày, nội dung đổi, lý do, evidence và tác động.
Giữ ranh giới nguồn	Nguồn pháp lý, kế toán, an toàn thực phẩm, privacy phải có owner thẩm quyền xác minh.
Giữ tính mô phỏng	Nova Foods và mọi số liệu chỉ phục vụ học liệu, dữ liệu tổng hợp.

Core

Output là artifact BA tạo mới hoặc cập nhật để người sau đọc, kiểm tra và truy vết quyết định. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp. Một output hoàn chỉnh phải cho thấy nội dung gì đã thay đổi, nằm ở đâu, dựa trên nguồn nào và còn ở trạng thái nào.

Thành phần anatomy	Giá trị bắt buộc	Ví dụ Nova Foods mô phỏng
Canonical ID	Giữ nguyên ID registry, không tự đổi tên	CANONICAL_BUSINESS_RULES
Tệp canonical	Đường dẫn nguồn chân lý	/01-curriculum/CANONICAL_BUSINESS_RULES.md
Loại output	Catalog, dictionary, registry hoặc traceability	Catalog quy tắc nghiệp vụ
Owner	Vai trò duy trì artifact	Principal IT Business Analyst / Technical Curriculum Author
Status	Trạng thái hiện hành	IN_REVIEW
Version	Phiên bản kiểm soát	v0.9.0
Ngày cập nhật	Theo Asia/Ho_Chi_Minh	2026-08-07
Nội dung tối thiểu	ID, mô tả, nguồn, giả định hoặc Verification required, liên kết ảnh hưởng	Quy tắc, phạm vi mô phỏng, nguồn, giới hạn thẩm quyền
Traceability	Liên kết artifact nguồn và artifact nhận	00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY
Change history	Dòng thay đổi không sửa im lặng	Khởi tạo v0.9.0, 2026-08-07, trạng thái IN_REVIEW

Applied

Facts: Nova Foods là case học liệu mô phỏng; ngày kiểm soát 2026-08-07; locale vi-VN; múi giờ Asia/Ho_Chi_Minh; tiền tệ mô phỏng VND; status mọi artifact trong ví dụ là IN_REVIEW.

Current Behavior: Nội dung về quy tắc và dữ liệu nằm trong artifact canonical riêng. 00_SOURCE_MAP phân loại nguồn; không phải nơi thay thế catalog quy tắc hay từ điển dữ liệu.

Underlying Need: Người review cần thấy đủ artifact đầu ra, vị trí canonical, phần đã điền và liên kết nguồn. Nếu một output không có ID hoặc change history, người review không xác định được bản nào đang được xem xét.

Options: Ghi quy tắc trong handbook; ghi trong catalog canonical; ghi trùng cả hai nơi. Handbook chỉ giải thích học liệu, nên không là nguồn chân lý quy tắc. Ghi trùng tạo hai phiên bản cạnh tranh.

Decision Criteria: Giữ ID đã đăng ký; một nguồn chân lý cho mỗi loại nội dung; dữ liệu tổng hợp; không diễn giải luật, kế toán, thuế, bảo mật hoặc vận hành thực tế thành kết luận.

Decision: Dùng artifact canonical hiện có làm output. Handbook chỉ tham chiếu ID và đường dẫn.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và traceability. Business Owner, Legal Owner, Accounting Owner, Security, Architect và QA giữ thẩm quyền chuyên môn tương ứng. Không có approval được ghi nhận.

Artifact:

Output đã điền	Canonical ID	Tệp	Nội dung đã điền	Traceability	Change history
Source map	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Nguồn BABOK, ISO/IEC/IEEE 29148, BPMN, UML, ISTQB, OAS, WCAG, OWASP và nguồn pháp lý Việt Nam; safe use boundary từng nguồn	Nguồn đầu vào cho catalog và handbook	Khởi tạo/duy trì v0.9.0, 2026-08-07, IN_REVIEW
ID registry	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Quy tắc định danh, liên kết artifact, escalation khi ID gây hàm ý quyết định chuyên môn	Nhận liên kết từ catalog canonical	Khởi tạo/duy trì v0.9.0, 2026-08-07, IN_REVIEW
Rule catalog	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Quản trị catalog quy tắc; ranh giới thẩm quyền; điều kiện dùng thuật ngữ baseline hoặc phê duyệt	Tham chiếu 00_SOURCE_MAP và registry	Khởi tạo/duy trì v0.9.0, 2026-08-07, IN_REVIEW
Data dictionary	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Kế hoạch từ điển dữ liệu logic canonical cho Nova Foods mô phỏng	Liên kết với registry và rule catalog khi dữ liệu liên quan quy tắc	Khởi tạo/duy trì v0.9.0, 2026-08-07, IN_REVIEW

Consequence if Wrong: Đổi ID làm gãy traceability. Đưa rule vào handbook thay catalog tạo hai nguồn chân lý. Gọi IN_REVIEW là approved, baselined hoặc production-ready tạo tuyên bố sai về trạng thái.

Senior Lens

Output tốt không phải tài liệu dài. Output tốt cho phép reviewer trả lời bốn câu: artifact nào, bản nào, thay đổi gì, dựa vào đâu. Evidence bridge: 00_SOURCE_MAP có safe use boundary; vì vậy output kế thừa phải giữ nhãn “project assumption” hoặc “Verification required” khi nội dung pháp lý, kế toán, thuế, an toàn thực phẩm, privacy hoặc bảo mật chưa được xác minh bởi owner có thẩm quyền.

Quick Reference

Kiểm tra anatomy	Đạt khi
Identity	Có đúng canonical ID và đường dẫn
Completeness	Có đủ metadata, nội dung tối thiểu, traceability, change history
Consistency	Status IN_REVIEW, version v0.9.0, ngày 2026-08-07 nhất quán
Boundary	Nova Foods được ghi là mô phỏng, dữ liệu tổng hợp
Review readiness	Reviewer đọc được nguồn, thay đổi và giới hạn; chưa hàm ý approval hoặc production readiness

Core

Quality gate là cổng kiểm tra chất lượng trước khi artifact được chuyển cho downstream review, tức review của vai trò nhận đầu ra để đánh giá tiếp. Gate không là phê duyệt, không tạo baseline, không xác nhận production readiness. Với Nova Foods Trading & Manufacturing mô phỏng, mọi dữ liệu là tổng hợp.

Điều kiện gate	Kiểm tra cụ thể	Bằng chứng phải có	Kết quả nếu thiếu
Định danh đúng	Artifact ID, đường dẫn canonical, IN_REVIEW, v0.9.0, ngày 2026-08-07 khớp nguồn kiểm soát	Header hoặc metadata artifact	Không chuyển review
Phạm vi rõ	Nội dung nói rõ artifact trả lời câu hỏi gì, không biến giả định thành fact hoặc quyết định vận hành	Scope và boundary đọc được	Trả về soạn lại
Traceability đủ	Mỗi kết luận nối được tới nguồn, fact, assumption hoặc Verification required	ID nguồn canonical hoặc nhãn phân loại	Không chuyển review
Thẩm quyền đúng	Nội dung pháp lý, kế toán, bảo mật, kiến trúc không bị BA tự xác nhận	Owner phù hợp hoặc nhãn cần xác minh	Escalate, không tự kết luận
Không mâu thuẫn	Không xung đột với CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY	Đối chiếu ID, status, version, terminology	Dừng chuyển review
Lịch sử thay đổi có mặt	Thay đổi ghi ngày, người ghi nhận, phạm vi thay đổi; không sửa im lặng	Change-history entry theo Asia/Ho_Chi_Minh	Không chuyển review

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

flowchart TB
    A[Artifact soạn xong] --> B{Định danh đúng:<br/>Artifact ID, đường dẫn canonical,<br/>IN_REVIEW, v0.9.0, 2026-08-07?}
    B -- Không --> R[Không chuyển review:<br/>trả về chỉnh sửa]
    B -- Có --> C{Phạm vi rõ, boundary đọc được,<br/>không biến assumption thành fact<br/>hoặc quyết định vận hành?}
    C -- Không --> W[Trả về soạn lại]
    C -- Có --> D{Traceability đủ:<br/>mỗi kết luận nối nguồn, fact,<br/>assumption hoặc Verification required?}
    D -- Không --> R
    D -- Có --> E{Có owner phù hợp hoặc nhãn<br/>Verification required,<br/>không do BA tự xác nhận?}
    E -- Không --> X[Escalate,<br/>không tự kết luận]
    X --> B
    E -- Có --> F{Không mâu thuẫn với<br/>CHAPTER_MANIFEST,<br/>TRACEABILITY_ID_REGISTRY,<br/>CANONICAL_BUSINESS_RULES,<br/>CANONICAL_DATA_DICTIONARY?}
    F -- Không --> S[Dừng chuyển review:<br/>chỉnh sửa]
    S --> B
    F -- Có --> G{Lịch sử thay đổi có mặt:<br/>ngày theo Asia/Ho_Chi_Minh,<br/>người ghi nhận, phạm vi thay đổi?}
    G -- Không --> T[Không chuyển review:<br/>bổ sung lịch sử thay đổi]
    T --> B
    G -- Có --> H[Chuyển downstream review<br/>trạng thái vẫn IN_REVIEW]
    R --> B
    W --> B

Applied

Facts: 00_SOURCE_MAP, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều là artifact canonical đang IN_REVIEW, v0.9.0, ngày 2026-08-07.

Current Behavior: Người soạn có thể hoàn tất nội dung nhưng downstream reviewer chưa biết nội dung có đủ nguồn, đúng ID, hay đã vượt thẩm quyền.

Underlying Need: Reviewer cần nhận artifact có thể kiểm tra được, không phải bản nháp thiếu provenance.

Options: (1) Chuyển mọi bản nháp; (2) chỉ chuyển khi qua quality gate.

Decision Criteria: Giữ traceability, không tạo approval ngầm định, phát hiện sai metadata trước review.

Decision: Dùng quality gate chung trước downstream review.

Authority: Principal IT Business Analyst / Technical Curriculum Author kiểm tra tính toàn vẹn quản trị; Legal Owner, Accounting Owner, Security, Architect, Business Owner và QA giữ thẩm quyền chuyên môn riêng.

Artifact: /02-handbook/00-foundations.md, section 06-outputs, trạng thái IN_REVIEW, version v0.9.0.

Consequence if Wrong: Artifact thiếu nguồn hoặc sai thẩm quyền đi vào review; reviewer có thể đánh giá trên giả định sai, làm đứt traceability và tăng rework.

Senior Lens

Gate trả lời: “Có đủ điều kiện để người khác review chưa?” Gate không trả lời: “Nội dung đã đúng nghiệp vụ chưa?”, “Đã được phê duyệt chưa?”, “Được dùng production chưa?”. Bằng chứng cho ranh giới này là mọi artifact nguồn đều ghi IN_REVIEW không đồng nghĩa APPROVED, BASELINED, compliant hoặc production-ready.

Quick Reference

Nhãn kết quả	Ý nghĩa
Ready for downstream review	Đủ metadata, traceability, boundary và change history để chuyển review
Return for correction	Thiếu hoặc sai điều kiện gate
Escalate	Cần vai trò có thẩm quyền chuyên môn kết luận
IN_REVIEW	Vẫn đang xem xét; không là approval, baseline hoặc production readiness

7. Who consumes those outputs?

Core

Output BA không tự tạo giá trị. Giá trị xuất hiện khi đúng vai trò dùng output để thực hiện phần việc thuộc thẩm quyền của họ. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên quy trình, dữ liệu và artifact dưới đây là dữ liệu tổng hợp.

Output từ section 6	Consumer	Cách consumer dùng output
Business requirement, phạm vi và mục tiêu	PM/Product Owner	Xếp ưu tiên, quản lý phạm vi release, lập kế hoạch backlog
Business requirement, acceptance criteria	Developers	Chuyển nhu cầu nghiệp vụ thành hành vi hệ thống, màn hình, API, xử lý dữ liệu
Business rule, exception flow	QA	Tạo test basis, tức cơ sở để thiết kế test case và kiểm tra kết quả mong đợi
Process flow, swimlane, handoff	Operations	Đối chiếu luồng hệ thống với công việc kho, mua hàng, sản xuất, bán hàng hoặc xử lý sự cố
Data dictionary, field definition, data lineage	Architect	Kiểm tra ranh giới dữ liệu, ownership, tích hợp và tác động kiến trúc
Data dictionary, validation rule	Developers và QA	Developer tạo kiểm tra dữ liệu; QA kiểm tra dữ liệu hợp lệ, không hợp lệ và biên
Traceability matrix	PM/Product Owner, QA, Business Owner	Theo dõi liên kết từ nhu cầu đến rule, thiết kế, test và kết quả review
Risk, assumption, dependency log	PM/Product Owner, Architect, Operations	Theo dõi điểm có thể chặn delivery, tích hợp hoặc vận hành
Security, privacy, compliance note có nhãn Verification required	Specialist owners	Security, Legal Owner, Accounting Owner hoặc Food-safety owner rà soát trong phạm vi chuyên môn
OpenAPI contract hoặc integration specification	Developers, QA, Architect, Operations	Developer tích hợp; QA kiểm thử giao tiếp; Architect kiểm tra tương thích; Operations chuẩn bị giám sát và xử lý lỗi

Developer không dùng business requirement như hướng dẫn kỹ thuật hoàn chỉnh. Developer dùng requirement để hiểu kết quả cần đạt, sau đó dùng business rule, data dictionary, process flow và interface contract để xây dựng. Nếu output chỉ nói “hệ thống kiểm tra tồn kho” nhưng không nêu đơn vị tính, thời điểm kiểm tra hoặc cách xử lý thiếu hàng, developer chưa có đủ đầu vào để tạo hành vi xác định.

QA dùng output làm test basis, không dùng suy đoán cá nhân thay cho rule. Acceptance criteria mô tả điều kiện được chấp nhận; business rule mô tả logic cần giữ đúng; data dictionary mô tả dữ liệu cần kiểm tra; process flow mô tả đường đi chính và ngoại lệ. Bốn phần này ghép lại để QA kiểm tra cả chức năng lẫn dữ liệu.

Architect dùng output để đánh giá tính nhất quán giữa nhu cầu và giới hạn hệ thống. Ví dụ, yêu cầu đồng bộ tồn kho giữa ERP và hệ thống kho cần process flow để thấy điểm gửi nhận, data dictionary để thấy trường trao đổi, và integration specification để thấy giao thức. Architect không lấy một câu mô tả nghiệp vụ làm bằng chứng đủ cho quyết định kiến trúc.

PM/Product Owner dùng output để điều phối delivery, không thay Business Owner xác nhận ý nghĩa nghiệp vụ. Phạm vi, dependency, assumption và traceability matrix giúp nhận biết hạng mục nào có thể vào release, hạng mục nào còn thiếu đầu vào, và thay đổi nào tác động nhiều artifact.

Business Owner dùng output để kiểm tra nhu cầu nghiệp vụ đã được diễn đạt đúng. Business Owner đọc process flow, business rule, exception flow và acceptance criteria theo góc nhìn kết quả kinh doanh: người dùng nào thực hiện việc gì, hệ thống phản hồi ra sao, ngoại lệ nào được phép. Business Owner không cần quyết định chi tiết mã API hoặc cấu trúc bảng dữ liệu.

Operations dùng output để chuẩn bị cách vận hành sau delivery. Process flow cho biết điểm handoff giữa người và hệ thống; exception flow cho biết khi nào cần can thiệp; support note cho biết dữ liệu hoặc log nào cần tra cứu. Operations cần output đủ cụ thể để phân biệt lỗi thao tác, lỗi dữ liệu và lỗi tích hợp.

Specialist owners là các chủ sở hữu chuyên môn như Security Owner, Legal Owner, Accounting Owner và Food-safety owner. Họ dùng phần output liên quan để rà soát rủi ro và giới hạn chuyên môn. Một rule về lưu dữ liệu cá nhân, hạch toán hoặc truy xuất lô hàng không được coi là kết luận chuyên môn chỉ vì BA đã ghi trong artifact. Nếu chưa có kiểm chứng nguồn chính thức và người có thẩm quyền, output phải giữ nhãn Verification required.

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

flowchart TB
    subgraph OUTPUTS["BA outputs"]
        REQ[Business requirement<br/>scope, goal, acceptance criteria]
        RULE[Business rule<br/>exception flow]
        DATA[Data dictionary<br/>field definition, validation, lineage]
        FLOW[Process flow<br/>swimlane, handoff]
        CONTRACT[OpenAPI contract or<br/>integration specification]
        TRACE[Traceability matrix]
        RISK[Risk, assumption,<br/>dependency log]
        SUPPORT[Support note<br/>data and log lookup]
        NOTE[Security, privacy, compliance note<br/>Verification required]
    end

    REQ --> DEVIN[Combined inputs for<br/>system behavior]
    RULE --> DEVIN
    DATA --> DEVIN
    FLOW --> DEVIN
    CONTRACT --> DEVIN
    DEVIN --> DEV[Developers define<br/>system behavior]

    REQ --> BASIS[Test basis]
    RULE --> BASIS
    DATA --> BASIS
    FLOW --> BASIS
    CONTRACT --> BASIS
    TRACE --> QA[QA designs tests]
    BASIS --> QA

    FLOW --> ARC[Architect assesses<br/>integration boundaries]
    DATA --> ARC
    CONTRACT --> ARC
    RISK --> ARC

    REQ --> PM[PM/Product Owner plans<br/>scope and delivery]
    TRACE --> PM
    RISK --> PM

    REQ --> BO[Business Owner reviews<br/>business fit]
    RULE --> BO
    FLOW --> BO
    TRACE --> BO

    FLOW --> OPS[Operations prepares<br/>operational readiness]
    RULE --> OPS
    CONTRACT --> OPS
    RISK --> OPS
    SUPPORT --> OPS

    NOTE --> HOLD[Not a validated<br/>conclusion]
    HOLD --> SO[Authoritative specialist owner<br/>reviews within specialty scope]

Applied

Facts: Nova Foods mô phỏng có yêu cầu theo dõi tồn kho nguyên liệu theo Item ID, Warehouse ID, Lot ID, số lượng và đơn vị tính. BA đã tạo process flow, business rule, data dictionary, acceptance criteria, risk log và traceability matrix.

Current Behavior: Developer dùng acceptance criteria để xây dựng màn hình nhận hàng. QA dùng business rule và data dictionary để thiết kế kiểm thử. Architect dùng integration specification để xem xét trao đổi dữ liệu với hệ thống kho mô phỏng. Operations dùng exception flow để nhận biết trường hợp quét sai Lot ID.

Underlying Need: Mỗi consumer cần nhận đúng artifact cho đúng mục đích. Lý do: cùng một output không có cùng độ chi tiết cho mọi vai trò.

Options: (1) Gửi toàn bộ artifact cho mọi người; (2) lập consumer map, chỉ rõ artifact nào mỗi vai trò cần dùng.

Decision Criteria: Consumer map phải giữ traceability, không thay thế thẩm quyền chuyên môn, và không biến trạng thái IN_REVIEW thành approval.

Decision: Dùng consumer map theo bảng Core; mỗi output ghi consumer chính và consumer phối hợp.

Authority: Đây là quyết định tổ chức handoff học liệu. Không xác nhận rule Nova Foods là đúng vận hành, pháp lý, kế toán, bảo mật hoặc production.

Artifact: /02-handbook/00-foundations.md, section 07-consumers, IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.

Consequence if Wrong: QA có thể thiếu rule để test; developer có thể tự suy diễn dữ liệu; Operations không chuẩn bị được xử lý ngoại lệ; specialist owner không thấy nội dung cần rà soát.

Senior Lens

Consumer map là bản đồ sử dụng output, không là ma trận phê duyệt. Bằng chứng: cùng business rule có thể được Developer dùng để code, QA dùng để test, Business Owner dùng để kiểm tra ý nghĩa và Accounting Owner dùng để rà soát chuyên môn. Một người đọc artifact không làm artifact trở thành approved.

Vai trò	Consumer chính khi	Không phải consumer chính khi
Developers	Cần xây dựng hành vi hệ thống	Cần xác nhận chính sách nghiệp vụ
QA	Cần kiểm tra hành vi và dữ liệu	Cần quyết định ưu tiên release
Architect	Cần đánh giá ranh giới kỹ thuật và tích hợp	Cần xác nhận quy tắc vận hành
PM/Product Owner	Cần quản lý phạm vi, ưu tiên, dependency	Cần diễn giải pháp lý hoặc kế toán
Business Owner	Cần kiểm tra nhu cầu nghiệp vụ	Cần quyết định chi tiết kỹ thuật
Operations	Cần chuẩn bị vận hành và hỗ trợ	Cần thay Architect quyết định tích hợp
Specialist owners	Cần rà soát phạm vi chuyên môn	Cần tự xác nhận toàn bộ solution

Quick Reference

Output	Consumer chính	Mục đích dùng
Requirement và acceptance criteria	Developers, QA, Business Owner	Build, test, kiểm tra business fit
Business rule và exception flow	Developers, QA, Operations	Xử lý đúng logic và ngoại lệ
Process flow	Business Owner, Operations, QA	Hiểu luồng công việc và handoff
Data dictionary	Developers, QA, Architect	Xây dựng, kiểm thử, kiểm soát dữ liệu
Integration specification	Developers, QA, Architect	Xây dựng và kiểm tra giao tiếp hệ thống
Traceability matrix	PM/Product Owner, QA, Business Owner	Theo dõi liên kết và phạm vi
Risk, assumption, dependency log	PM/Product Owner, Architect, Operations	Điều phối rủi ro và phụ thuộc

Core

Đầu ra BA chỉ tạo giá trị khi người nhận dùng nó để ra quyết định trong đúng thẩm quyền. Bằng chứng phải đủ để kiểm tra quyết định, không phải để suy đoán. Với Nova Foods Trading & Manufacturing là case mô phỏng, mọi dữ liệu dưới đây là dữ liệu tổng hợp; trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, chưa là baseline hay phê duyệt.

Người nhận	Có thể quyết định	Bằng chứng cần có	Phải escalation khi
Developer	Cách hiện thực trong ranh giới requirement; xử lý lỗi kỹ thuật; ước lượng kỹ thuật	Requirement ID, business rule ID, acceptance criteria, dữ liệu mẫu, ràng buộc API hoặc UI đã ghi	Rule mơ hồ; yêu cầu mâu thuẫn; đổi logic nghiệp vụ; thay đổi dữ liệu canonical; lộ dữ liệu cá nhân hoặc bí mật
QA	Phạm vi kiểm thử, test condition, expected result, mức chặn lỗi	Acceptance criteria có điều kiện-kết quả; business rule; trạng thái dữ liệu; traceability requirement-to-test	Không xác định expected result; requirement không kiểm thử được; lỗi ảnh hưởng tiền, truy xuất lô, quyền truy cập hoặc dữ liệu
Architect	Ranh giới hệ thống, tích hợp, mô hình dữ liệu, bảo mật phi chức năng	Luồng nghiệp vụ, volume giả định, data dictionary, dependency, yêu cầu bảo mật và hiệu năng	Đề xuất thay đổi kiến trúc; giao diện tích hợp chưa có chủ sở hữu; yêu cầu vượt ràng buộc bảo mật hoặc vận hành
PM/Product Owner	Ưu tiên, phạm vi release, trade-off thời gian-chi phí-giá trị	Mục tiêu nghiệp vụ, impact, dependency, estimate, risk, acceptance criteria	Thay đổi scope; ưu tiên làm mất kiểm soát nghiệp vụ; conflict giữa nhóm sử dụng
Business Owner	Chính sách nghiệp vụ, ngoại lệ, mức chấp nhận rủi ro nghiệp vụ	Facts, quy trình hiện tại, pain point, option, tác động định lượng hoặc định tính	Quyết định liên quan chính sách doanh nghiệp, giá bán, phê duyệt, quyền hạn, cam kết khách hàng
Operations	Tính khả thi vận hành, lịch chạy, xử lý sự cố, phân quyền tác nghiệp	Quy trình mục tiêu, exception flow, vai trò, SLA giả định, dữ liệu đầu vào-đầu ra	Quy trình làm gián đoạn kho, sản xuất, giao nhận; không có người xử lý ngoại lệ; thay đổi cần đào tạo hoặc chuyển đổi dữ liệu
Specialist owner: Kế toán, Pháp chế, An toàn thực phẩm, Bảo mật	Diễn giải chuyên môn trong phạm vi được giao	Requirement liên quan, nguồn chính thức, giả định dự án, dữ liệu ảnh hưởng, rủi ro	Requirement bị diễn đạt như nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm hoặc tuân thủ khi chưa được vai trò có thẩm quyền xác minh

BA không tự thay quyết định của người nhận. BA giữ reasoning bridge: “Requirement cần trường batch_id vì nghiệp vụ mô phỏng yêu cầu phân biệt từng lô; bằng chứng là luồng nhận hàng và dữ liệu mẫu; quyết định định dạng, lưu giữ và quyền truy cập thuộc Architect, Operations và specialist owner.” Nếu một vấn đề chạm từ hai thẩm quyền trở lên, lập gói escalation gồm ID liên quan, facts, option, tác động, câu hỏi quyết định và người cần quyết định.

Dấu hiệu	Câu hỏi escalation chính xác
Developer hỏi “có cho sửa số lô không?”	“Business Owner xác nhận điều kiện nào cho phép sửa batch_id, ai có quyền sửa, và thay đổi có cần lưu lịch sử không?”
QA không có expected result	“Với đơn hàng mô phỏng vượt ngưỡng phê duyệt, hệ thống phải chặn, cảnh báo hay cho lưu chờ; kết quả nào là đúng?”
Architect thấy tích hợp chưa rõ	“Hệ thống nào là source of truth cho mã hàng, chủ sở hữu API là ai, và lỗi đồng bộ phải được xử lý theo cơ chế nào?”
Operations báo quy trình không chạy được	“Khi quét mã lô thất bại tại kho, nhân viên được tiếp tục bằng thao tác nào, ai xử lý ngoại lệ, và thời gian xử lý chấp nhận được là bao lâu?”
Có yếu tố pháp lý hoặc kế toán	“Nội dung này là giả định học liệu hay yêu cầu áp dụng; Legal Owner hoặc Accounting Owner nào xác minh nguồn và kết luận?”

Core

Hiểu lầm bàn giao xảy ra khi người nhận biến artifact (tài liệu đầu ra có kiểm soát) thành kết luận ngoài bằng chứng ghi trong artifact. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, IN_REVIEW và v0.9.0 ngày 2026-08-07, mọi câu chưa được ghi rõ phải là điểm cần làm rõ, không phải giả định để triển khai. Bằng chứng là trạng thái IN_REVIEW không đồng nghĩa APPROVED hay BASELINED; vì vậy không vai trò nào được coi nội dung review là quyết định vận hành, pháp lý, kế toán hay kiến trúc.

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

flowchart TB
    A[Nhận artifact IN_REVIEW v0.9.0] --> B{Câu trả lời ghi rõ trong artifact?}
    B -->|Có| C[Dùng đúng phạm vi và điều kiện đã ghi]
    B -->|Không| D[Đặt câu hỏi làm rõ chính xác]
    D --> E{Câu trả lời thuộc thẩm quyền chuyên môn?}
    E -->|Có| F[Escalate kèm artifact ID, bằng chứng và tác động]
    E -->|Không| G[Ghi nhận giả định dự án để review, không dùng để triển khai]
    C --> H[Chỉ dùng để review, không coi là APPROVED hoặc BASELINED]
    F --> I[Không tự đổi rule hoặc thiết kế; không coi IN_REVIEW là quyết định vận hành, pháp lý, kế toán hoặc kiến trúc]
    G --> I
    H --> I

Applied

Mục	Nội dung
Facts	Một handoff nói: “Đơn bán vượt hạn mức tín dụng phải được chặn.” Không có ngưỡng VND, thời điểm kiểm tra, ngoại lệ, nguồn dữ liệu tín dụng, hay vai trò được phép vượt.
Current Behavior	Developer hiểu “chặn” là không cho lưu đơn. QA hiểu là cho lưu nhưng không cho xác nhận. Operations hiểu là có thể giao hàng nếu quản lý gọi điện. Ba cách hiểu tạo ba hệ thống hành vi khác nhau.
Underlying Need	Cần biến từ mệnh đề nghiệp vụ thành hành vi kiểm chứng được: trạng thái đơn nào bị tác động, điều kiện nào kích hoạt, ai có quyền xử lý ngoại lệ, và bằng chứng nào lưu lại.
Options	(1) Chặn lưu đơn. (2) Cho lưu, chặn xác nhận đơn. (3) Cho xác nhận, chặn phát hành giao hàng.
Decision Criteria	So sánh theo điểm kiểm soát mong muốn, tác động dữ liệu nháp, khả năng xử lý ngoại lệ, truy vết quyết định, và thẩm quyền Business Owner cùng Accounting Owner.
Decision	Chưa chọn phương án. Artifact không chứa đủ bằng chứng để chọn.
Authority	Business Owner xác nhận mục tiêu nghiệp vụ; Accounting Owner xác nhận cách hiểu hạn mức và công nợ; Architect đánh giá điểm kiểm soát kỹ thuật.
Artifact	Ghi vấn đề vào artifact kiểm soát liên quan; giữ liên kết tới CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY, không tự tạo rule canonical mới.
Consequence if Wrong	Chặn quá sớm có thể cản đơn nháp hợp lệ. Chặn quá muộn có thể tạo cam kết giao hàng trước khi kiểm soát tín dụng hoàn tất.

Câu hỏi làm rõ chính xác: “Khi nói ‘chặn’, Nova Foods mô phỏng phải chặn thao tác nào: lưu đơn, xác nhận đơn hay phát hành giao hàng?”; “Hạn mức lấy từ trường dữ liệu canonical nào, tại thời điểm nào?”; “Vai trò nào được vượt hạn mức, bằng chứng phê duyệt nào phải lưu?”. Không hỏi “Anh/chị muốn xử lý thế nào?” vì câu hỏi rộng không buộc người trả lời xác định điều kiện, thẩm quyền và bằng chứng.

Senior Lens

Hiểu lầm handoff	Dấu hiệu	Câu hỏi làm rõ chính xác	Escalate khi
“Theo thời gian thực” bị hiểu là đồng bộ ngay	Không có độ trễ tối đa, sự kiện kích hoạt, xử lý lỗi	“‘Thời gian thực’ ở đây là phản hồi đồng bộ cho người dùng hay đồng bộ bất đồng bộ; độ trễ chấp nhận tối đa là bao nhiêu?”	Câu trả lời ảnh hưởng kiến trúc tích hợp, khả năng chịu lỗi hoặc dữ liệu tài chính
“Không được sửa” bị hiểu là cấm mọi cập nhật	Không nêu trạng thái, trường dữ liệu, vai trò	“Đối tượng nào bất biến sau trạng thái nào; sửa trường nào bị cấm; cơ chế điều chỉnh thay thế là gì?”	Liên quan chứng từ kế toán, truy vết hoặc nghĩa vụ pháp lý; cần Accounting Owner hoặc Legal Owner xác minh
“Chỉ người có quyền mới xem” bị hiểu là một vai trò chung	Không có ma trận quyền theo dữ liệu và hành động	“Vai trò nào được xem, tạo, sửa, xuất dữ liệu; phạm vi theo đơn vị, kho hay khách hàng là gì?”	Có dữ liệu cá nhân, dữ liệu nhạy cảm, phân quyền API hoặc rủi ro bảo mật; cần Security Owner
“Tính đúng thuế” bị hiểu là BA tự chọn công thức	Không có nguồn luật, diễn giải kế toán, ngày hiệu lực	“Quy tắc thuế này là giả định dự án hay yêu cầu đã được Accounting Owner và Legal Owner xác minh theo nguồn hiện hành?”	Bất kỳ kết luận thuế, hóa đơn, kế toán hoặc hiệu lực pháp lý nào
“Dễ dùng” bị hiểu là bỏ kiểm soát	Không có luồng tác vụ, đối tượng dùng, tiêu chí truy cập	“Người dùng hoàn thành tác vụ nào, trong điều kiện nào, với tiêu chí quan sát hoặc kiểm thử nào?”	Có yêu cầu trợ năng; đối chiếu WCAG 2.2 khi phạm vi yêu cầu xác nhận tuân thủ

Quy tắc senior: câu làm rõ phải khóa bốn biến: đối tượng, điều kiện, hành động, bằng chứng. Nếu thiếu một biến, handoff vẫn mở. Ví dụ “hệ thống gửi cảnh báo khi tồn kho thấp” chưa đủ; hỏi: “Mặt hàng nào, ngưỡng nào, tại thời điểm nào, gửi cho vai trò nào, qua kênh nào, và lưu bằng chứng gửi thành công hoặc thất bại ở đâu?”

Quick Reference

Không được suy diễn	Phải làm
IN_REVIEW là đã phê duyệt	Giữ trạng thái review; yêu cầu quyết định có thẩm quyền
Cụm từ nghiệp vụ là acceptance criteria	Tách điều kiện, hành động, kết quả, ngoại lệ, bằng chứng
Im lặng là đồng ý	Ghi câu hỏi mở và escalation cần thiết
Ví dụ dữ liệu tổng hợp là rule thật	Gắn là mô phỏng; yêu cầu nguồn canonical hoặc xác nhận owner
BA tự chốt pháp lý, kế toán, bảo mật, kiến trúc	Escalate đúng owner; BA bảo toàn vấn đề và traceability

8. Detailed Worked Example

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing là case study giáo dục, chỉ 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 bán thành phẩm sữa chua uống cần xuất kho cho đơn bán hàng. Mục tiêu ở đây là ghi nhận sự thật và hành vi hiện tại, chưa đề xuất giải pháp hay xác nhận quyết định vận hành.

Facts

Nhóm	Sự thật tổng hợp	Bằng chứng trong tình huống
Đơn bán hàng	Nhân viên kinh doanh tạo đơn SO-NF-20260807-001 ngày 2026-08-07 cho khách hàng mô phỏng CUS-NF-001 — Siêu thị An Bình.	Đơn yêu cầu giao 480 thùng SKU-NF-YD-180ML, mỗi thùng 24 chai.
Mặt hàng	SKU-NF-YD-180ML là sữa chua uống vị dâu, đơn vị tồn kho là thùng.	Tên hàng, đơn vị và số lượng xuất nằm trên đơn bán hàng tổng hợp.
Kho nguồn	Kho thành phẩm WH-NF-HCM-FG đang giữ tồn kho khả dụng 350 thùng cho SKU-NF-YD-180ML.	Báo cáo tồn kho thủ công lúc 09:00 ngày 2026-08-07 ghi On hand = 500, Reserved = 150, nên Available = 350.
Nhu cầu giao	Đơn cần 480 thùng, cao hơn tồn kho khả dụng 130 thùng.	480 - 350 = 130. Đây là phép tính từ hai số liệu nêu trên, không phải kết luận về nguyên nhân thiếu hàng.
Theo dõi lô	Nhân viên kho ghi lô và hạn dùng trong bảng tính riêng khi chuẩn bị giao.	Bảng tính có cột Lot No., Manufacture Date, Expiry Date, Picked Qty; ERP hiện tại không khóa việc chọn lô khi tạo phiếu xuất.
Vai trò	Nhân viên kinh doanh tạo đơn; điều phối kho kiểm tra tồn; thủ kho soạn hàng; kế toán nhận chứng từ giao hàng sau giao.	Các bước đang diễn ra qua ERP, bảng tính và email nội bộ.
Kênh trao đổi	Điều phối kho báo thiếu hàng bằng email cho nhân viên kinh doanh.	Email không có trường cấu trúc để liên kết trực tiếp số lượng thiếu với dòng đơn hàng.
Phạm vi pháp lý	Khả năng truy xuất lô có liên quan bối cảnh an toàn thực phẩm.	Đây là nhận diện rủi ro nghiệp vụ. Yêu cầu pháp lý cụ thể cần Legal Owner và domain owner xác minh theo nguồn hiện hành.

Current Behavior

Khi đơn SO-NF-20260807-001 được tạo, ERP chỉ kiểm tra tồn kho tổng ở mức mặt hàng. Hệ thống không tự tính tồn khả dụng theo đơn, không giữ hàng cho đơn và không chặn người dùng tiếp tục tạo yêu cầu xuất khi số lượng yêu cầu vượt lượng có thể cấp. Vì vậy, đơn 480 thùng vẫn chuyển sang trạng thái chờ kho xử lý dù kho chỉ có 350 thùng khả dụng.

Điều phối kho mở báo cáo tồn kho, tự trừ Reserved khỏi On hand, rồi phát hiện thiếu 130 thùng. Điều phối kho gửi email báo thiếu cho nhân viên kinh doanh. Nhân viên kinh doanh sau đó phải hỏi khách hàng về giao một phần, đổi ngày giao hoặc đổi mặt hàng. Không có bản ghi ERP tập trung cho lý do thiếu, lựa chọn khách hàng, hay thay đổi cam kết giao.

Nếu khách hàng đồng ý giao một phần qua email, thủ kho tạo phiếu xuất cho số lượng có thể soạn. Thủ kho chọn lô trong bảng tính riêng và ghi số lượng đã lấy. ERP chỉ nhận tổng số lượng xuất; không nhận quan hệ giữa dòng xuất, lô hàng và hạn dùng trong tình huống mô phỏng này. Kế toán nhận chứng từ giao hàng sau khi hàng rời kho, nên đối chiếu giữa đơn gốc 480 thùng và số thực giao 350 thùng phụ thuộc vào trao đổi thủ công.

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

flowchart TB
    A[Nhân viên kinh doanh tạo SO-NF-20260807-001: 480 thùng] --> B[ERP kiểm tra tồn tổng theo SKU]
    B --> C[Đơn chuyển chờ kho xử lý]
    C --> D[Điều phối kho mở báo cáo tồn]
    D --> E[Tự tính 500 On hand - 150 Reserved = 350 Available]
    E --> F[Phát hiện thiếu 130 thùng]
    F --> G[Gửi email cho nhân viên kinh doanh]
    G --> H[Nhân viên kinh doanh hỏi khách hàng: giao một phần, đổi ngày giao hoặc đổi mặt hàng]
    H -. ERP không có bản ghi tập trung .-> X[Thiếu bản ghi: lý do thiếu, lựa chọn khách hàng, thay đổi cam kết giao]
    H --> Q{Khách hàng đồng ý giao một phần qua email?}
    Q -- Có --> P[Thủ kho tạo phiếu xuất cho số lượng có thể soạn]
    P --> I[Thủ kho soạn 350 thùng]
    I --> J[Ghi Lot No. và hạn dùng trong bảng tính ngoài ERP]
    J --> K[ERP chỉ ghi tổng số lượng xuất]
    K -. ERP không nhận .-> Y[Không có liên kết: dòng xuất, lô hàng, hạn dùng]
    K --> R[Hàng rời kho]
    R --> L[Kế toán nhận chứng từ giao hàng]
    L --> M[Đối chiếu thủ công đơn 480 thùng với thực giao 350 thùng]
    Q -- Không --> N[Tiếp tục trao đổi phương án khác qua email]
    N --> O[Thay đổi cam kết không có bản ghi ERP tập trung]

Ranh giới quan sát: sơ đồ là flowchart Mermaid mô tả hành vi hiện tại, không phải BPMN. Các con số, khách hàng, SKU, kho, đơn bán hàng và vai trò đều là dữ liệu tổng hợp của Nova Foods mô phỏng. Không có nội dung nào xác nhận cấu hình ERP thực tế, tuân thủ pháp lý, phê duyệt người dùng hoặc quyết định vận hành.

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, tiền tệ VND. Tình huống xử lý lô sữa chua thành phẩm gần hạn dùng tại kho thành phẩm.

Mục	Giá trị
Mã tình huống	NF-EX-08-001
Sản phẩm	Sữa chua Nova 100g
Mã SKU	NF-YOG-100
Lô thành phẩm	LOT-NF-260801-A
Hạn dùng	2026-08-11
Ngày kiểm tra	2026-08-07
Tồn kho khả dụng	4.800 hũ
Đơn giá bán chuẩn	8.000 VND/hũ
Kênh bán	Siêu thị và đại lý
Ngưỡng giao hàng hiện hành	Không có rule hệ thống
Trạng thái artifact	IN_REVIEW, v0.9.0; chưa baseline, chưa có approval

Facts (Sự kiện). Báo cáo kho ngày 2026-08-07 cho thấy LOT-NF-260801-A còn bốn ngày trước hạn dùng. Nhân viên kho nhìn hạn dùng trên nhãn lô rồi tự quyết định xuất hàng. Ba đơn hàng cùng ngày có nhu cầu tổng 3.600 hũ. Không có trường bắt buộc ghi “số ngày còn lại trước hạn dùng” khi xác nhận xuất kho. Bằng chứng là phiếu xuất mô phỏng GI-NF-20260807-014 chỉ có SKU, số lượng, lô và khách hàng.

Current Behavior (Hành vi hiện tại). ERP cho phép chọn mọi lô có tồn kho dương. Nhân viên kho chọn lô theo vị trí kệ, không theo hạn dùng. Quản lý kho chỉ biết lô gần hạn sau khi xem báo cáo cuối ngày. Đây là hành vi hiện tại, không phải quy tắc đã được phê duyệt.

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

flowchart TB
    A[Đơn bán hàng]
    B[Nhân viên kho chọn lô theo vị trí kệ]
    C[Nhân viên kho xem hạn dùng trên nhãn lô<br/>LOT-NF-260801-A: còn 4 ngày]
    D[Nhân viên kho tự quyết định xuất hàng]
    E[ERP chỉ kiểm tra tồn kho > 0]
    F[ERP cho phép xác nhận xuất kho<br/>Không kiểm tra số ngày còn lại trước hạn dùng]
    G[Hàng giao khách]
    H[Quản lý kho xem báo cáo cuối ngày]
    I[Chỉ sau khi đã cho phép xuất/giao:<br/>phát hiện lô gần hạn]
    J[Phiếu xuất mô phỏng<br/>SKU, số lượng, lô, khách hàng<br/>Không có số ngày còn lại trước hạn dùng]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> I
    F -. tạo .-> J

Underlying Need (Nhu cầu gốc). Nova Foods cần ngăn xuất lô có thời gian sử dụng còn lại thấp hơn mức khách hàng có thể nhận. Suy luận: lô còn bốn ngày, trong khi hàng còn có thể nằm trên đường, tại điểm bán và chờ người mua; kiểm tra “tồn kho dương” chỉ chứng minh có hàng, không chứng minh hàng phù hợp để giao. Nhu cầu không phải “thêm cảnh báo” đơn thuần; nhu cầu là kiểm soát quyết định xuất kho bằng dữ liệu hạn dùng.

Lựa chọn	Cơ chế	Lợi ích	Giới hạn
OPT-01	Cảnh báo khi còn dưới 5 ngày	Nhanh, ít chặn vận hành	Người dùng vẫn có thể bỏ qua
OPT-02	Chặn xuất khi còn dưới ngưỡng tối thiểu theo kênh	Kiểm soát nhất quán	Cần ngoại lệ có thẩm quyền
OPT-03	Chỉ ưu tiên FEFO	Giảm nguy cơ tồn lô cũ	Không bảo đảm số ngày còn lại đủ

Decision Criteria (Tiêu chí quyết định). FEFO, “First Expired First Out”, nghĩa là xuất lô hết hạn sớm trước, chỉ giải quyết thứ tự chọn lô. Tiêu chí cần xét gồm: ngăn giao hàng quá gần hạn; không chặn lô còn hợp lệ cho kênh phù hợp; ghi nhận ngoại lệ; truy vết ai quyết định; không tự diễn giải nghĩa vụ pháp lý hay chất lượng thực phẩm. Yêu cầu pháp lý, an toàn thực phẩm và điều khoản khách hàng cần Verification required bởi Legal Owner và Food Safety Owner.

Tiêu chí	OPT-01	OPT-02	OPT-03
Ngăn xuất không phù hợp	Thấp	Cao	Trung bình
Truy vết ngoại lệ	Thấp	Cao	Thấp
Hỗ trợ FEFO	Không	Có thể kết hợp	Cao
Phụ thuộc kỷ luật cá nhân	Cao	Thấp	Trung bình

Decision (Quyết định đề xuất). Đề xuất OPT-02 kết hợp ưu tiên FEFO: ERP chặn xác nhận xuất kho khi expiry_date - shipment_date < minimum_remaining_days. Đây là khuyến nghị BA, chưa phải quyết định được ủy quyền. Giá trị ngưỡng giả định phục vụ học liệu: siêu thị 5 ngày, đại lý 3 ngày. Với LOT-NF-260801-A, giao ngày 2026-08-07 còn 4 ngày; ERP phải chặn đơn siêu thị, cho phép đánh giá đơn đại lý.

Authority (Thẩm quyền). Business Owner quyết định chính sách bán hàng và ngưỡng theo kênh. Food Safety Owner xác nhận phù hợp an toàn thực phẩm. Legal Owner xác minh nghĩa vụ pháp lý. Solution Architect xác nhận cách cấu hình ERP. Principal IT Business Analyst ghi nhận nhu cầu, tiêu chí và truy vết; không có thẩm quyền phê duyệt hay tự đặt ngưỡng vận hành.

Artifact (Artifact đầu ra). Ghi nhận đề xuất vào /02-handbook/00-foundations.md dưới mã tình huống NF-EX-08-001; liên kết quản trị tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY. Các artifact này đang IN_REVIEW, v0.9.0; không phải baseline hay approval.

{
  "shipment_id": "GI-NF-20260807-014",
  "sku": "NF-YOG-100",
  "lot_id": "LOT-NF-260801-A",
  "shipment_date": "2026-08-07",
  "expiry_date": "2026-08-11",
  "sales_channel": "SUPERMARKET",
  "minimum_remaining_days": 5,
  "remaining_days": 4,
  "proposed_system_result": "BLOCK"
}

Consequence if Wrong (Hậu quả nếu sai). Nếu dùng cảnh báo thay vì chặn, nhân viên có thể xuất lô bốn ngày cho siêu thị; hàng có thể bị từ chối, trả về hoặc gây lãng phí. Nếu đặt ngưỡng quá cao, ERP có thể chặn hàng vẫn phù hợp và tăng tồn gần hạn. Vì vậy ngưỡng chỉ là giả định học liệu đến khi đúng owner xác minh và ra quyết định 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à dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. ID trong bảng là ID mô phỏng của ví dụ này, chưa phải ID canonical đã baseline.

Thành phần	Giá trị đầy đủ
Scenario ID	SCN-NF-08-001
Tên scenario	Chặn xuất kho thành phẩm khi lô chưa đạt kiểm tra chất lượng
Process	Sales Order → Delivery → Goods Issue
Sản phẩm	FG-MILK-01 — Sữa hạt Nova Oat 1L
Kho	WH-HCM-FG-01 — Kho thành phẩm TP.HCM
Lô hàng	LOT-20260805-017
Số lượng tồn	480 chai
Đơn bán	SO-20260807-042
Số lượng giao	120 chai
Khách hàng	CUS-SYN-014 — Cửa hàng Minh An
Trạng thái kiểm tra lô	PENDING_QC
Người tạo giao hàng	USR-SYN-WH-003 — Nhân viên kho mô phỏng
Thời điểm ví dụ	2026-08-07T09:15:00+07:00

Fact ID	Fact — sự kiện quan sát được	Bằng chứng mô phỏng	Suy luận có căn cứ
FACT-NF-08-001	Lô LOT-20260805-017 có 480 chai tồn khả dụng trong kho.	Bản ghi tồn kho mô phỏng của WH-HCM-FG-01.	Tồn kho đủ số lượng cho SO-20260807-042.
FACT-NF-08-002	Lô có trạng thái PENDING_QC.	Bản ghi kiểm tra chất lượng mô phỏng.	Lô chưa có kết quả đạt hoặc không đạt.
FACT-NF-08-003	ERP hiện chỉ kiểm tra số lượng tồn khi xác nhận xuất kho.	Luồng hiện trạng mô phỏng bên dưới.	ERP không dùng trạng thái QC làm điều kiện chặn xuất kho.
FACT-NF-08-004	Nhân viên kho có thể chọn lô PENDING_QC để giao đơn bán.	Kịch bản thao tác SO-20260807-042.	Hàng chưa hoàn tất kiểm tra có thể tới khách hàng.

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

flowchart TB
    A[SO-20260807-042<br/>Yêu cầu giao 120 chai] --> B[Nhân viên kho chọn<br/>LOT-20260805-017]
    B --> C[Nhân viên kho xác nhận xuất kho]
    C --> D{Tồn kho >= 120?}
    D -- Không --> E[Từ chối do thiếu tồn]
    D -- Có: 480 chai --> F[ERP chỉ kiểm tra tồn kho]
    F --> G[ERP không đánh giá<br/>qcStatus = PENDING_QC]
    G --> H[ERP tạo Goods Issue]
    H --> I[Hàng có thể được giao]

Current Behavior ID	Current Behavior — hành vi hiện tại	Điều kiện hệ thống	Kết quả
CB-NF-08-001	ERP cho phép xác nhận Goods Issue khi tồn lô đủ.	availableQuantity >= deliveryQuantity	120 chai được xuất.
CB-NF-08-002	ERP không đánh giá qcStatus của lô trước Goods Issue.	Không có điều kiện QC trong kiểm tra xuất kho.	PENDING_QC không chặn giao hàng.

Underlying Need — nhu cầu nền tảng: trước khi hàng rời kho, ERP cần phân biệt “có hàng” với “được phép giao”. Bằng chứng là FACT-NF-08-002 và FACT-NF-08-003: tồn kho đáp ứng số lượng nhưng trạng thái chất lượng chưa xác nhận. Nhu cầu này là kiểm soát quy trình mô phỏng, không phải kết luận tuân thủ pháp luật hay an toàn thực phẩm. Việc suy ra nghĩa vụ pháp lý hoặc vận hành thực tế cần Legal Owner và Food Safety Owner xác minh.

Option ID	Phương án	Thay đổi	Lợi ích	Hạn chế
OPT-NF-08-001	Chỉ cảnh báo	Hiện cảnh báo khi qcStatus != RELEASED; người dùng vẫn xác nhận xuất kho.	Thay đổi nhỏ, ít gián đoạn.	Không ngăn giao hàng sai.
OPT-NF-08-002	Chặn tại Goods Issue	Từ chối xác nhận xuất kho khi lô không có qcStatus = RELEASED.	Kiểm soát ngay điểm hàng rời kho.	Cần quy trình xử lý ngoại lệ được thẩm quyền quyết định.
OPT-NF-08-003	Ẩn lô chưa đạt QC khỏi chọn lô	Chỉ hiển thị lô RELEASED trong màn hình cấp phát.	Giảm lỗi chọn lô trước khi xác nhận.	Không đủ nếu API hoặc thao tác khác bỏ qua màn hình.

Criterion ID	Decision Criteria — tiêu chí quyết định	Cách đánh giá
DC-NF-08-001	Ngăn giao lô chưa được phát hành chất lượng.	Không thể tạo Goods Issue với PENDING_QC, FAILED_QC, QUARANTINED.
DC-NF-08-002	Áp dụng nhất quán qua giao diện và API.	Cùng quy tắc chạy tại service xác nhận xuất kho.
DC-NF-08-003	Không chặn lô đạt QC.	RELEASED và tồn đủ số lượng vẫn xuất được.
DC-NF-08-004	Có thông báo xử lý được.	Lỗi nêu lô, trạng thái, hành động kế tiếp.

Rule ID mô phỏng	Quy tắc đề xuất	Input	Kết quả
BR-NF-08-001	ERP phải từ chối Goods Issue nếu bất kỳ lô nào có qcStatus khác RELEASED.	lotId, qcStatus, deliveryQuantity	Không tạo Goods Issue; ghi lỗi nghiệp vụ.
BR-NF-08-002	ERP chỉ xác nhận Goods Issue khi lô có qcStatus = RELEASED và availableQuantity >= deliveryQuantity.	qcStatus, availableQuantity, deliveryQuantity	Tạo Goods Issue khi cả hai điều kiện đúng.

{
  "deliveryOrderId": "SO-20260807-042",
  "warehouseId": "WH-HCM-FG-01",
  "lines": [
    {
      "productId": "FG-MILK-01",
      "lotId": "LOT-20260805-017",
      "deliveryQuantity": 120,
      "uom": "BOTTLE",
      "qcStatus": "PENDING_QC",
      "availableQuantity": 480
    }
  ]
}

{
  "errorCode": "QC_STATUS_NOT_RELEASED",
  "message": "Không thể xác nhận xuất kho: lô LOT-20260805-017 có trạng thái PENDING_QC, yêu cầu RELEASED.",
  "deliveryOrderId": "SO-20260807-042",
  "rejectedLotIds": [
    "LOT-20260805-017"
  ]
}

Decision record	Nội dung
Recommendation	BA khuyến nghị OPT-NF-08-002, bổ sung BR-NF-08-001 và BR-NF-08-002. Lý do: đáp ứng toàn bộ DC-NF-08-001 đến DC-NF-08-004; chặn tại điểm kiểm soát chung cho UI và API.
Authorized Decision	Chưa có quyết định được ủy quyền. Status corpus là IN_REVIEW, version v0.9.0; không có baseline reference hoặc approval reference.
Authority cần quyết định	Business Owner quyết định chính sách giao hàng; Quality Owner quyết định nghĩa RELEASED và luồng ngoại lệ; Solution Architect xác nhận điểm thực thi UI/API; QA xác nhận test basis.
Không thuộc thẩm quyền BA curriculum owner	Phê duyệt quy tắc vận hành Nova Foods, xác nhận tuân thủ an toàn thực phẩm, cho phép production.

Artifact ID mô phỏng	Artifact	Nội dung hoàn chỉnh	Traceability
ART-NF-08-001	Quy tắc kiểm soát xuất kho theo QC	BR-NF-08-001, BR-NF-08-002, payload yêu cầu và payload lỗi.	FACT-NF-08-001 đến FACT-NF-08-004; DC-NF-08-001 đến DC-NF-08-004.
ART-NF-08-002	Decision record mô phỏng	Recommendation OPT-NF-08-002; Authorized Decision chưa tồn tại.	SCN-NF-08-001.
ART-NF-08-003	Test basis mô phỏng	Case chặn lô PENDING_QC; case cho phép lô RELEASED.	BR-NF-08-001, BR-NF-08-002.

Consequence ID	Consequence if Wrong — hậu quả nếu quyết định hoặc rule sai
CON-NF-08-001	Nếu chọn cảnh báo thay vì chặn, nhân viên vẫn có thể giao lô PENDING_QC; kiểm soát không đạt mục tiêu DC-NF-08-001.
CON-NF-08-002	Nếu chỉ ẩn lô trên UI nhưng API không kiểm tra, tích hợp có thể tạo Goods Issue sai; vi phạm DC-NF-08-002.
CON-NF-08-003	Nếu chặn cả lô RELEASED, giao hàng hợp lệ bị dừng; vi phạm DC-NF-08-003.
CON-NF-08-004	Nếu trạng thái RELEASED được định nghĩa mơ hồ, QA không có test basis xác định; Quality Owner phải làm rõ trước khi quyết định.

9. Related Concepts & Dependencies

Core

Dependency là quan hệ phụ thuộc: artifact sau chỉ đúng khi artifact trước còn đúng. Traceability là khả năng lần từ nội dung đang đọc về nguồn kiểm soát và lần tiếp đến nơi nội dung được dùng. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; dependency không xác nhận quy trình ERP thật hay phê duyệt vận hành.

Nguồn chân lý canonical là tệp được chỉ định giữ nội dung gốc. Handbook không chép lại định nghĩa ID, business rule, trường dữ liệu hay metadata từ registry. Handbook chỉ ghi liên kết nguyên dạng. Lý do: hai bản cùng chứa “sự thật” sẽ có thể lệch phiên bản khi một bản đổi im lặng.

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

flowchart TB
    U["Upstream canonical<br/>CHAPTER_MANIFEST<br/>TEMPLATE_MANIFEST<br/>TRACEABILITY_ID_REGISTRY<br/>CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY"]

    H["Handbook<br/>00-foundations.md"]

    D["Artifact downstream<br/>đúng cấu trúc chapter<br/>hoàn chỉnh theo template<br/>dùng ID, rule và dữ liệu canonical"]

    U -->|"tham chiếu nguyên dạng<br/>Handbook chỉ đúng khi nguồn còn đúng"| H
    H -->|"cung cấp nội dung áp dụng<br/>artifact chỉ đúng khi Handbook còn đúng"| D

    H -->|"nếu sao chép ID, rule, dữ liệu<br/>hoặc metadata canonical"| C["Bản sao nội dung canonical"]
    C --> R["Nguồn canonical thứ hai"]
    R --> V["Rủi ro lệch phiên bản<br/>khi một bản đổi im lặng"]

    B["Boundary toàn mô hình<br/>Nova Foods dùng dữ liệu tổng hợp<br/>dependency không xác nhận quy trình ERP thật<br/>hay phê duyệt vận hành"] -.-> H

Loại phụ thuộc	Upstream canonical	Handbook dùng gì	Downstream nhận gì	Không được làm
Cấu trúc chapter	/01-curriculum/CHAPTER_MANIFEST.md	Tên chapter, filename, phạm vi đã công bố	Handbook chapter, liên kết chapter khác	Tự đổi title, slug, filename
Template	/01-curriculum/TEMPLATE_MANIFEST.md	ID và mục đích template đã đăng ký	Artifact hoàn chỉnh theo template	Tạo template cùng chức năng, ID khác
Định danh	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Chuỗi ID nguyên dạng và quy tắc cấp ID	Liên kết giữa artifact	Tái sử dụng hoặc tự dịch ID
Business rule	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Tham chiếu rule và trạng thái kiểm soát	Requirement, test basis, quyết định	Chép rule thành bản “canonical” thứ hai
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên entity, field, nghĩa dữ liệu đã công bố	UI, API, báo cáo, kiểm thử	Tự đổi kiểu dữ liệu hoặc nghĩa field

Applied

Facts: ART-NF-08-001 mô phỏng kiểm soát xuất kho theo QC tham chiếu BR-NF-08-001 và BR-NF-08-002; case dùng trạng thái lô PENDING_QC và RELEASED.

Current Behavior: Nếu section 9 chép lại toàn văn hai rule và định nghĩa trạng thái lô, handbook trở thành bản sao cạnh tranh với /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Underlying Need: Người học cần biết artifact nào cung cấp rule, ID và data meaning để tìm đúng nguồn khi đọc ART-NF-08-001.

Options: (1) Chép toàn văn rule vào handbook; (2) chỉ ghi ID không có đường dẫn; (3) ghi ID nguyên dạng, đường dẫn canonical và vai trò dependency.

Decision Criteria: Không tạo nguồn chân lý thứ hai; giữ được ID ổn định; learner tìm được nguồn; không diễn giải trạng thái IN_REVIEW thành baseline hoặc approval.

Decision: Chọn option 3. BR-NF-08-001, BR-NF-08-002, PENDING_QC và RELEASED được nêu như tham chiếu mô phỏng; nghĩa canonical thuộc artifact registry, rule catalog hoặc data dictionary tương ứng.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết. Business Owner, Quality Owner, Solution Architect và QA giữ thẩm quyền chuyên môn theo loại nội dung. Không có authority nào được ghi nhận là đã phê duyệt tại v0.9.0, trạng thái IN_REVIEW.

Artifact: ART-NF-08-001 nhận rule reference; ART-NF-08-002 nhận decision context; ART-NF-08-003 nhận test basis reference. Các artifact không thay thế /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Consequence if Wrong: Nếu BR-NF-08-001 đổi ở catalog nhưng handbook giữ bản chép cũ, QA có thể test theo rule cũ, API có thể chặn sai lô, và learner không biết bản nào đáng tin.

Senior Lens

Quy tắc đọc dependency: “tham chiếu, không sao chép; mở rộng cách dùng, không viết lại nghĩa canonical.” Bằng chứng là TRACEABILITY_ID_REGISTRY được mô tả là registry định danh canonical, CANONICAL_BUSINESS_RULES là catalog rule canonical, và CANONICAL_DATA_DICTIONARY là từ điển dữ liệu logic canonical. Vì vậy section này chỉ làm bản đồ liên kết.

Khi artifact upstream đổi, trước hết kiểm tra ID, đường dẫn, version, trạng thái và phạm vi thay đổi. Nếu ID bị thay, liên kết downstream có thể đứt. Nếu nghĩa business rule đổi, artifact áp dụng có thể vẫn mở được nhưng mang logic cũ. Nếu field dữ liệu đổi, UI, API và báo cáo có thể hiểu cùng tên field theo nghĩa khác. Không sửa im lặng liên kết để “khớp” nội dung mới; ghi nhận thay đổi theo cơ chế quản trị của artifact canonical.

Quick Reference

Cần tìm	Đi tới nguồn canonical	Dùng trong handbook
Chapter nào tồn tại, tên tệp nào đúng	/01-curriculum/CHAPTER_MANIFEST.md	Liên kết chapter và boundary
Template nào được dự kiến	/01-curriculum/TEMPLATE_MANIFEST.md	Gọi đúng template, không tạo bản song song
ID nào hợp lệ	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Giữ nguyên ID khi tham chiếu
Rule nghiệp vụ thuộc đâu	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nêu rule reference, không chép thành canonical
Nghĩa dữ liệu thuộc đâu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Nêu entity, field và dependency theo nguồn

Core

Ma trận truy vết liên kết Need (nhu cầu), Requirement (yêu cầu), Business Rule (quy tắc nghiệp vụ), Acceptance Criteria (tiêu chí chấp nhận), Data/API (dữ liệu hoặc giao diện lập trình ứng dụng) và Test Case (ca kiểm thử). Mỗi ô phải chứa persistent ID đã đăng ký trong TRACEABILITY_ID_REGISTRY; không tạo ID mới trong handbook. Bằng chứng: nguồn seed chỉ xác nhận registry canonical, không cung cấp bản ghi ID Nova Foods cụ thể. Vì vậy, gán mã ví dụ sẽ tạo nguồn sự thật giả.

Loại liên kết	ID nguồn	ID đích	Canonical source	Trạng thái tại v0.9.0	Quy tắc ghi nhận
NEED → REQ	Chưa có NEED đã đăng ký trong nguồn seed	Chưa có REQ đã đăng ký trong nguồn seed	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	IN_REVIEW	Chỉ liên kết khi cả hai ID tồn tại trong registry.
REQ → BR	Chưa có REQ đã đăng ký trong nguồn seed	Chưa có BR đã đăng ký trong nguồn seed	/01-curriculum/CANONICAL_BUSINESS_RULES.md	IN_REVIEW	REQ dẫn chiếu BR; không chép nội dung BR vào bảng.
REQ → AC	Chưa có REQ đã đăng ký trong nguồn seed	Chưa có AC đã đăng ký trong nguồn seed	Registry và artifact requirement tương ứng	IN_REVIEW	AC chứng minh kết quả có thể kiểm tra của REQ.
REQ → DATA/API	Chưa có REQ đã đăng ký trong nguồn seed	Chưa có DATA/API đã đăng ký trong nguồn seed	/01-curriculum/CANONICAL_DATA_DICTIONARY.md và đặc tả API được kiểm soát	IN_REVIEW	Ghi đúng ID trường dữ liệu, thực thể hoặc endpoint đã đăng ký.
AC → TC	Chưa có AC đã đăng ký trong nguồn seed	Chưa có TC đã đăng ký trong nguồn seed	Registry và test artifact tương ứng	IN_REVIEW	Mỗi TC phải chỉ ra AC được kiểm tra; một AC có thể có nhiều TC.
BR → TC	Chưa có BR đã đăng ký trong nguồn seed	Chưa có TC đã đăng ký trong nguồn seed	CANONICAL_BUSINESS_RULES và test artifact tương ứng	IN_REVIEW	Dùng khi TC kiểm tra trực tiếp điều kiện hoặc ngoại lệ của BR.

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

flowchart TB
    subgraph TRACE["Ma trận truy vết · v0.9.0 · IN_REVIEW"]
        NEED["NEED<br/>nhu cầu"]
        REQ["REQ<br/>yêu cầu"]
        BR["BR<br/>quy tắc nghiệp vụ"]
        AC["AC<br/>tiêu chí chấp nhận"]
        DATA["DATA/API<br/>dữ liệu hoặc giao diện"]
        TC["TC<br/>ca kiểm thử"]

        NEED -->|"Hai đầu: persistent ID trong registry<br/>Nguồn: TRACEABILITY_ID_REGISTRY"| REQ
        REQ -->|"Hai đầu: persistent ID trong registry<br/>Chỉ dẫn chiếu, không sao chép BR<br/>Nguồn: CANONICAL_BUSINESS_RULES"| BR
        REQ -->|"Hai đầu: persistent ID trong registry<br/>Nguồn: registry + artifact requirement tương ứng"| AC
        REQ -->|"Hai đầu: persistent ID trong registry<br/>Nguồn: CANONICAL_DATA_DICTIONARY + đặc tả API được kiểm soát"| DATA
        AC -->|"Hai đầu: persistent ID trong registry<br/>Một AC có thể liên kết nhiều TC<br/>Nguồn: registry + test artifact tương ứng"| TC
        BR -->|"Hai đầu: persistent ID trong registry<br/>TC kiểm tra trực tiếp điều kiện hoặc ngoại lệ BR<br/>Nguồn: CANONICAL_BUSINESS_RULES + test artifact tương ứng"| TC
    end

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp; TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều IN_REVIEW, v0.9.0, ngày 2026-08-07. Current Behavior: nguồn seed không công bố NEED, REQ, BR, AC, DATA/API hoặc TC Nova Foods có mã cụ thể. Underlying Need: learner cần thấy đủ chuỗi truy vết nhưng không được biến mã minh họa thành mã canonical. Options: tạo mã mới trong handbook; hoặc ghi nhận trạng thái chưa đăng ký và trỏ về canonical source. Decision Criteria: giữ đúng persistent ID, không trùng nguồn sự thật, không ngầm tạo baseline hay approval. Decision: dùng bảng trạng thái trên; chỉ thay “chưa có” bằng ID đã đăng ký từ registry. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì registry; không có thẩm quyền tự xác nhận requirement, rule, approval hoặc baseline. Artifact: /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Consequence if Wrong: ID tự tạo có thể bị test, tài liệu và triển khai tham chiếu như nguồn thật, làm đứt truy vết và tạo quyết định giả cho Nova Foods.

Senior Lens

Liên kết là quan hệ tham chiếu, không phải bản sao nội dung. Ví dụ, ô REQ → BR chỉ giữ hai ID và vị trí canonical; nội dung điều kiện nghiệp vụ vẫn thuộc CANONICAL_BUSINESS_RULES. Lý do: một BR được sửa tại một nơi, còn mọi REQ và TC tìm được qua registry. Không dùng IN_REVIEW để suy ra rằng NEED, REQ, BR, AC, DATA/API hoặc TC đã được chấp thuận.

Quick Reference

Khi cần liên kết	Ghi gì	Không ghi
NEED đến REQ	Persistent ID NEED, persistent ID REQ, artifact canonical	Diễn giải lại toàn bộ nhu cầu
REQ đến BR	Persistent ID REQ, persistent ID BR	Bản sao quy tắc nghiệp vụ
REQ đến AC	Persistent ID REQ, persistent ID AC	Kết luận “đã đạt”
REQ đến DATA/API	Persistent ID REQ, ID dữ liệu hoặc API đã đăng ký	Tên trường hoặc endpoint tự đặt
AC hoặc BR đến TC	Persistent ID AC hoặc BR, persistent ID TC	Kết quả test không có bằng chứng

Core

Phụ thuộc là quan hệ trong đó artifact sau dùng ý nghĩa, ID, cấu trúc dữ liệu hoặc quy tắc từ artifact trước. Thay đổi phải lan truyền có kiểm soát vì output sau được xây trên input trước. Nếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md đổi kiểu, tên hoặc ý nghĩa trường dữ liệu mà không ghi nhận thay đổi, requirement, API, acceptance criteria và test case tham chiếu trường cũ vẫn có thể trông hợp lệ nhưng kiểm tra sai đối tượng.

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

flowchart LR
    A["Nguồn canonical thay đổi"] --> B["Đánh giá phạm vi ảnh hưởng"]
    B --> C["Cập nhật artifact phụ thuộc"]
    C --> D["Kiểm tra traceability"]
    D --> E["Ghi nhận version và lịch sử thay đổi"]
    A -. thay đổi im lặng .-> F["REQ, AC, DATA/API, TC lệch nhau"]
    F --> G["Build hoặc test sai hành vi"]

Thay đổi im lặng là sửa nội dung, ID, đường dẫn, phân loại nguồn hoặc ý nghĩa mà không có version, lịch sử thay đổi và đánh giá tác động. Bằng chứng rủi ro: TRACEABILITY_ID_REGISTRY là nguồn kiểm soát ID, CANONICAL_BUSINESS_RULES là nguồn quy tắc, còn CANONICAL_DATA_DICTIONARY là nguồn nghĩa dữ liệu. Artifact phụ thuộc không được tự giữ bản sao rồi sửa riêng, vì hai nguồn chân lý sẽ sinh diễn giải mâu thuẫn.

Applied

Facts: Nova Foods là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. /01-curriculum/CANONICAL_DATA_DICTIONARY.md thay đổi nghĩa logic của trường ngày giao hàng từ “ngày dự kiến” sang “ngày giao thực tế”.

Current Behavior: Một requirement tham chiếu trường này để tính đơn giao trễ; acceptance criteria và test case dùng cùng tên trường nhưng không nêu nghĩa ngày.

Underlying Need: Giữ phép tính “giao trễ” đo đúng sự kiện nghiệp vụ, không chỉ giữ nguyên tên kỹ thuật.

Options: Giữ tên trường và cập nhật toàn bộ diễn giải phụ thuộc; tạo trường mới cho ngày giao thực tế; đảo ngược thay đổi nếu chưa đủ thẩm quyền xác nhận nghĩa mới.

Decision Criteria: Nghĩa dữ liệu có thay đổi không; requirement và business rule còn đúng không; API có thay đổi contract không; test case còn kiểm tra đúng kết quả không; ai có thẩm quyền xác nhận.

Decision: Dừng sử dụng tham chiếu cũ cho đến khi đánh giá tác động hoàn tất. Nếu hai mốc thời gian cùng cần thiết, tách hai thuộc tính logic thay vì đổi nghĩa một trường đang được tham chiếu.

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

Artifact: Cập nhật tại nguồn canonical /01-curriculum/CANONICAL_DATA_DICTIONARY.md; kiểm tra liên kết tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md; ghi ảnh hưởng trong artifact phụ thuộc, không sao chép định nghĩa canonical.

Consequence if Wrong: Báo cáo có thể gắn nhãn đơn “trễ” theo ngày dự kiến thay vì ngày thực tế; API gửi nghĩa khác cho consumer; TC vẫn pass nhưng xác nhận hành vi sai.

Senior Lens

Dấu hiệu cần chặn thay đổi: ID biến mất, tên tệp đổi, nghĩa trường đổi nhưng schema không đổi, business rule đổi ngưỡng, hoặc API đổi enum. Mỗi dấu hiệu có thể phá traceability theo cách khác: ID biến mất làm liên kết không truy ra được; nghĩa đổi làm liên kết vẫn chạy nhưng sai; API đổi enum làm consumer gửi giá trị không còn hợp lệ.

Quy tắc: không sửa im lặng artifact IN_REVIEW. IN_REVIEW cho phép thay đổi, không cho phép bỏ dấu vết. Khi nguồn canonical thay đổi, ghi ít nhất: phần tử thay đổi, nghĩa cũ và mới, artifact bị ảnh hưởng, người có thẩm quyền cần xem xét, kết quả kiểm tra. Nếu chưa xác định được phạm vi, đánh dấu Verification required; không tuyên bố requirement, rule hay API đã đúng.

Quick Reference

Tín hiệu thay đổi	Có thể hỏng	Kiểm tra bắt buộc
Đổi business rule	REQ, AC, TC kiểm tra logic cũ	Đối chiếu rule với mọi AC và TC liên quan
Đổi nghĩa dữ liệu	DATA/API truyền đúng tên nhưng sai nghĩa	Đối chiếu định nghĩa canonical với payload và test data
Đổi enum hoặc trường API	Consumer lỗi tích hợp hoặc bỏ lọc dữ liệu	Kiểm tra contract API và xử lý giá trị không hợp lệ
Đổi ID hoặc đường dẫn	Liên kết traceability bị đứt	Kiểm tra registry và toàn bộ tham chiếu
Đổi phân loại nguồn	Kết luận vượt thẩm quyền hoặc dùng nguồn sai	Kiểm tra /00-research/00_SOURCE_MAP.md và owner phù hợp

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 giao nhận. Người mới thường ghi “hệ thống xử lý đơn hàng nhanh” rồi gọi đó là requirement. Câu này không nêu điều kiện, thời điểm đo, đối tượng đo, ngưỡng hay bằng chứng kiểm tra. Delivery team không thể thiết kế, test hoặc nghiệm thu nhất quán.

Sai lầm	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Ghi nhu cầu thành giải pháp	“Cần thêm nút duyệt” nhưng chưa nêu ai duyệt, duyệt việc gì	Nhầm UI với business need, nhu cầu nghiệp vụ	Hỏi mục tiêu, actor, trigger, outcome trước; chỉ chọn UI sau khi xác định need
Requirement mơ hồ	Dùng “nhanh”, “đủ quyền”, “phù hợp”, “kịp thời”	Không xác định tiêu chí đo	Đổi thành điều kiện kiểm tra được: ngưỡng, đơn vị, thời điểm, dữ liệu
Requirement thiếu	Có happy path, không có lỗi, hủy, trùng dữ liệu, phân quyền	Workshop chỉ theo luồng thuận lợi	Lập danh sách exception, trạng thái, validation, quyền và audit cần kiểm tra
Gán thẩm quyền không có bằng chứng	“Kế toán đã chấp thuận”, “luật bắt buộc” nhưng không có record	BA suy diễn từ trao đổi không chính thức hoặc nguồn không đủ	Ghi Verification required; chuyển đúng Legal Owner, Accounting Owner hoặc Business Owner
Dùng sai notation	Gọi PlantUML activity diagram là BPMN	Nhầm công cụ vẽ với chuẩn ký pháp	Gắn đúng loại sơ đồ; chỉ gọi BPMN khi tuân BPMN 2.0.2
Đứt traceability	REQ đổi nhưng AC, TC, API hoặc data definition không đổi	Không phân tích impact trước khi sửa	Đối chiếu liên kết trong TRACEABILITY_ID_REGISTRY; ghi artifact ảnh hưởng và kết quả kiểm tra

Warning: Claim pháp lý, kế toán, thuế, bảo mật hoặc an toàn thực phẩm không có xác minh có thể dẫn team xây sai kiểm soát. Dừng claim đó. Giữ nguyên nhãn Verification required đến khi owner có thẩm quyền cung cấp kết luận được ghi nhận.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp. Team ghi: “ERP tự động khóa đơn bán nếu khách hàng vượt hạn mức công nợ.”

Current Behavior: Requirement không có định nghĩa “hạn mức”, thời điểm tính công nợ, loại đơn bị khóa, ngoại lệ, vai trò mở khóa, hay nguồn thẩm quyền. Developer hiểu là khóa tại lúc tạo đơn. QA hiểu là khóa lúc xác nhận giao hàng.

Underlying Need: Ngăn đơn bán làm tăng rủi ro công nợ vượt mức doanh nghiệp chấp nhận. Suy luận này dựa trên cụm “vượt hạn mức công nợ”; câu gốc chưa chứng minh cách tính, thời điểm kiểm tra hay quyền quyết định.

Mục	Nội dung
Options	1. Khóa khi tạo đơn. 2. Cảnh báo khi tạo, khóa khi xác nhận. 3. Không khóa, yêu cầu phê duyệt ngoại lệ.
Decision Criteria	Chính sách tín dụng được xác minh; thời điểm phát sinh cam kết; khả năng hoàn tác; quyền phê duyệt; tác động vận hành bán hàng
Decision	Chưa chọn option. Ghi Verification required vì chưa có chính sách tín dụng và Business Owner xác nhận.
Authority	Business Owner quyết định chính sách; Accounting Owner xác nhận cách xác định công nợ; BA ghi nhận và duy trì traceability.
Artifact	Requirement draft, business-rule reference trong CANONICAL_BUSINESS_RULES, định nghĩa dữ liệu trong CANONICAL_DATA_DICTIONARY, liên kết trong TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Đơn hợp lệ có thể bị chặn; đơn rủi ro có thể lọt; báo cáo công nợ, test case và xử lý ngoại lệ dùng các quy tắc khác nhau.

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

flowchart TB
    R[Requirement draft] --> N[Trạng thái hiện tại:<br/>Chưa chọn option]
    N --> V[Verification required]

    V --> BO[Business Owner xác minh:<br/>định nghĩa hạn mức<br/>loại đơn áp dụng<br/>ngoại lệ và vai trò mở khóa<br/>nguồn thẩm quyền]
    V --> AO[Accounting Owner xác minh:<br/>cách xác định công nợ<br/>thời điểm tính công nợ]

    BO --> G{Cả hai owner đã hoàn tất<br/>và đủ nội dung cần xác minh?}
    AO --> G

    G -- Chưa --> S[Giữ Verification required:<br/>không cấu hình khóa đơn<br/>không chốt test pass/fail<br/>không coi rule đã phê duyệt]
    S --> V

    G -- Rồi --> C[Đánh giá options theo:<br/>chính sách tín dụng đã xác minh<br/>thời điểm phát sinh cam kết<br/>khả năng hoàn tác<br/>quyền phê duyệt<br/>tác động vận hành bán hàng]

    C --> D{Business Owner quyết định<br/>chính sách và option sau xác minh}

    D -- Option 1 --> O1[Khóa khi tạo đơn]
    D -- Option 2 --> O2[Cảnh báo khi tạo<br/>khóa khi xác nhận]
    D -- Option 3 --> O3[Không khóa<br/>yêu cầu phê duyệt ngoại lệ]

    D -.-> K[Rủi ro nếu chọn sai:<br/>chặn đơn hợp lệ<br/>lọt đơn rủi ro<br/>báo cáo công nợ, test case và xử lý ngoại lệ<br/>dùng quy tắc khác nhau]

    O1 --> BA[BA ghi nhận quyết định<br/>và duy trì traceability]
    O2 --> BA
    O3 --> BA

    BA --> RD[Requirement draft]
    BA --> CBR[Business-rule reference<br/>trong CANONICAL_BUSINESS_RULES]
    BA --> CDD[Data definition<br/>trong CANONICAL_DATA_DICTIONARY]
    BA --> TIR[Liên kết AC, test case, data và API<br/>trong TRACEABILITY_ID_REGISTRY]

    RD --> F[Trạng thái sau cập nhật:<br/>vẫn là draft<br/>chưa được coi là phê duyệt]
    CBR --> F
    CDD --> F
    TIR --> F

Ranh giới phục hồi an toàn: không cấu hình khóa đơn, không viết test pass/fail cuối cùng, không gọi rule là đã phê duyệt. Có thể ghi câu hỏi quyết định, owner cần xác minh và artifact bị ảnh hưởng.

Senior Lens

Một lỗi nguy hiểm là “điền cho đủ template”. Bảng đầy hàng không chứng minh requirement đủ. Bằng chứng đủ là mỗi quyết định có nguồn, owner, điều kiện, kết quả và liên kết đến phần tử bị ảnh hưởng.

Team cũng hay sửa tên trường để “dễ hiểu” nhưng không sửa định nghĩa canonical. Ví dụ đổi “Ngày giao hàng” thành “Ngày giao dự kiến” trong màn hình, trong khi API và test vẫn hiểu ngày giao thực tế. Tên gần giống che lỗi nghĩa dữ liệu. Sửa bằng cách đối chiếu nghĩa, không chỉ đối chiếu chuỗi ký tự.

Không dùng trạng thái IN_REVIEW như bằng chứng approval. IN_REVIEW chỉ cho biết artifact đang được xem xét. Không có baseline reference hoặc approval reference được ghi nhận thì không được nói Nova Foods đã chấp thuận rule, thiết kế hay kiểm soát.

Quick Reference

Kiểm tra trước handoff	Đạt khi
Requirement	Có actor, trigger, điều kiện, outcome, ngoại lệ và tiêu chí kiểm tra
Authority	Claim có nguồn và owner đúng thẩm quyền, hoặc mang nhãn Verification required
Notation	Tên sơ đồ khớp chuẩn hoặc công cụ đã dùng
Traceability	Thay đổi REQ được rà AC, TC, data, API và rule liên quan
Nova Foods scope	Ví dụ ghi rõ mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp

Core

[!WARNING] Cảnh báo chỉ dùng khi sai sót có thể gây mất dữ liệu, phát hành sai, quyết định sai thẩm quyền, hoặc làm mất khả năng truy vết. Không dùng cảnh báo cho lỗi trình bày hay câu chữ chưa đẹp.

Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Một cảnh báo tốt nêu đủ: rủi ro thật, bằng chứng quan sát được, tác hại, điểm dừng an toàn, người có thẩm quyền xử lý. IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải APPROVED hay BASELINED; suy ra không được dùng nội dung handbook làm lệnh cấu hình ERP, quyết định kế toán, pháp lý, thuế, an toàn thực phẩm, hoặc production.

Rủi ro thật	Dấu hiệu quan sát	Tác hại	Ranh giới khôi phục an toàn
Ghi đè artifact kiểm soát	Tệp /01-curriculum/CANONICAL_BUSINESS_RULES.md bị sửa nhưng không ghi version hoặc lịch sử thay đổi	Mất bằng chứng phiên bản; team không biết rule nào đang được review	Dừng dùng bản bị ghi đè; khôi phục từ bản kiểm soát gần nhất; ghi nhận chênh lệch trước khi tiếp tục
Diễn đạt giả định thành nghĩa vụ pháp lý	Requirement nói “phải tuân thủ” nhưng không có xác minh Legal Owner	ERP có thể xây sai; tạo tuyên bố tuân thủ không có thẩm quyền	Đổi nhãn thành Project assumption hoặc Verification required; chuyển Legal Owner xác minh nguồn chính thức
Xóa liên kết nguồn	Rule hoặc field không còn liên kết tới ID nguồn canonical	QA, dev, tester không xác định được căn cứ	Không suy đoán lại từ trí nhớ; phục hồi liên kết từ artifact nguồn hoặc ghi Verification required
Chạy thao tác phá hủy trên dữ liệu mô phỏng	Import xóa hoặc hợp nhất bản ghi mà không có bản xuất đối chiếu	Không kiểm tra được kết quả case study	Dừng batch; giữ bản xuất trước thao tác; chỉ chạy lại trên dữ liệu tổng hợp đã xác định phạm vi

Applied

Facts: Trong Nova Foods mô phỏng, BA ghi: “Hệ thống phải tự khóa hóa đơn sau 24 giờ để tuân thủ pháp luật.” Câu này nằm trong artifact trạng thái IN_REVIEW, không có tham chiếu xác minh từ Legal Owner hoặc Accounting Owner.

Current Behavior: Dev chuẩn bị cấu hình job tự khóa mọi hóa đơn sau 24 giờ. Tester viết test theo câu đó.

Underlying Need: Team cần ngăn sửa chứng từ sau điểm kiểm soát hợp lệ, nhưng chưa biết điểm kiểm soát, loại chứng từ, ngoại lệ, hay thẩm quyền quyết định.

Options: Giữ câu như requirement bắt buộc; đổi thành giả định dự án; dừng cấu hình và yêu cầu xác minh.

Decision Criteria: Có nguồn pháp lý hiện hành đã được vai trò có thẩm quyền xác minh không; có quyết định nghiệp vụ được ghi nhận không; có thể hoàn tác cấu hình mà không làm hỏng dữ liệu không.

Decision: Dừng cấu hình tự khóa. Gắn câu là Verification required. Không tạo rule Nova Foods mới từ suy đoán.

Authority: Legal Owner và Accounting Owner xác minh nghĩa vụ; Business Owner quyết định quy trình; Architect đánh giá cách cấu hình; BA giữ traceability. Không vai trò nào được suy ra là đã phê duyệt.

Artifact: Giữ nguyên nguồn tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; liên kết quản trị dùng CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY. Không đổi trạng thái IN_REVIEW thành baseline.

Consequence if Wrong: Khóa sai có thể chặn sửa chứng từ hợp lệ hoặc tạo cấu hình không có căn cứ. Khôi phục an toàn chỉ gồm: vô hiệu hóa job chưa chạy, giữ log cấu hình, đối chiếu bản xuất dữ liệu tổng hợp, rồi chờ xác minh. Không tự mở khóa dữ liệu production hoặc tự diễn giải luật.

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

flowchart TB
    A[Phát hiện phát biểu có tác động cao] --> B{Nguồn hiện hành đã được<br/>Legal Owner và Accounting Owner xác minh?}

    B -- Không --> C[Gắn Verification required]
    C --> D[Dừng cấu hình tự khóa<br/>Tester không dùng phát biểu làm test oracle]
    D --> E[Legal Owner và Accounting Owner<br/>xác minh nghĩa vụ]
    E --> V{Kết quả xác minh?}
    V -- Chưa có kết quả --> W[Tiếp tục dừng cấu hình tự khóa<br/>Chờ xác minh]
    W --> E
    V -- Không có căn cứ hoặc không áp dụng --> R[Loại bỏ đề xuất rule<br/>Không cấu hình tự khóa]
    V -- Có căn cứ và áp dụng --> F

    B -- Có --> F{Business Owner đã ghi nhận<br/>quyết định quy trình?}
    F -- Không --> H[Business Owner quyết định<br/>và ghi nhận quy trình]
    H --> I
    F -- Có --> I[Architect đánh giá tác động<br/>và khả năng hoàn tác cấu hình]

    I --> J{Đủ xác minh, quyết định nghiệp vụ<br/>và khả năng hoàn tác?}
    J -- Không --> Q[Dừng cấu hình tự khóa<br/>Chuyển đúng Owner xử lý điểm còn thiếu]
    J -- Có --> K[Chỉ cấu hình theo nghĩa vụ<br/>và quyết định đã ghi nhận]

    C --> T["BA giữ traceability<br/>Nguồn: /01-curriculum/CANONICAL_BUSINESS_RULES.md<br/>Liên kết: CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY<br/>Giữ IN_REVIEW; không baseline khi chưa đủ xác minh"]
    R --> T
    I --> T
    K --> T
    Q --> T

    D -. Nếu vẫn cấu hình sai .-> Y[Job tự khóa đã được cấu hình sai]
    Q -. Nếu vẫn cấu hình sai .-> Y
    Y --> Z[Nguy cơ chặn sửa chứng từ hợp lệ<br/>hoặc tạo cấu hình không có căn cứ]
    Z --> N{Job đã chạy?}
    N -- Chưa chạy --> O[Vô hiệu hóa job chưa chạy<br/>Giữ log cấu hình<br/>Đối chiếu bản xuất dữ liệu tổng hợp<br/>Chờ xác minh]
    N -- Đã chạy --> P[Không tự mở khóa dữ liệu production<br/>Không tự diễn giải luật<br/>Chuyển Owner có thẩm quyền xử lý]

Senior Lens

Cảnh báo không thay thế phân tích. Dùng cảnh báo khi hành động tiếp theo có thể gây hại trước khi đủ bằng chứng. Bằng chứng tối thiểu phải chỉ ra artifact nguồn, trạng thái, version, người có thẩm quyền và giới hạn quyết định. Nếu thiếu một phần, biện pháp an toàn là dừng tác động không thể đảo ngược, không phải viết thêm câu chắc chắn.

[!WARNING] Không khôi phục bằng cách sửa im lặng, xóa log, đổi ID, hoặc tuyên bố “đã được phê duyệt”. Các hành động này phá bằng chứng kiểm soát, kể cả khi kết quả kỹ thuật trông đúng.

Quick Reference

Quy tắc	Áp dụng
Cảnh báo phải có rủi ro cụ thể	Nêu tác hại và hành động dừng rõ
IN_REVIEW không tạo thẩm quyền	Không gọi là approved, baselined, compliant, production-ready
Khôi phục trước, sửa sau	Giữ bản xuất, log, version và liên kết nguồn
Thiếu xác minh chuyên môn	Dùng Verification required; chuyển đúng Owner
Dữ liệu Nova Foods	Chỉ là dữ liệu tổng hợp trong case mô phỏng giáo dục

Core

Năm lỗi khác loại, phải ghi riêng vì cách sửa và người quyết định khác nhau. 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.

Loại lỗi	Dấu hiệu quan sát	Ví dụ lỗi Nova Foods	Nguyên nhân gốc	Sửa trong artifact	Ranh giới an toàn
Mơ hồ (ambiguity)	Hai người đọc cho hai kết quả hợp lý	“Kho bị khóa khi lô gần hết hạn.”	Từ “gần”, “khóa”, “lô” chưa có định nghĩa, ngưỡng, phạm vi	Tách thành điều kiện đo được: mã trạng thái, đơn vị thời gian, tác động màn hình và giao dịch	BA không tự chọn ngưỡng hạn dùng; ghi câu hỏi, bằng chứng cần có, người có thẩm quyền
Thiếu thông tin (incompleteness)	Có luồng chính nhưng thiếu ngoại lệ, dữ liệu, kết quả lỗi hoặc vai trò	Yêu cầu chuyển kho chỉ nói “tạo phiếu chuyển” nhưng không nói xử lý thiếu tồn, lô hết hạn, người hủy	Thu thập yêu cầu chỉ hỏi “làm gì”, không hỏi “khi nào không làm được”	Bổ sung trigger, precondition, postcondition, ngoại lệ, trường dữ liệu, acceptance criteria	Không lấp chỗ trống bằng giả định rồi gọi là rule
Khẳng định thẩm quyền không có chứng cứ	Câu dùng “đã duyệt”, “bắt buộc pháp luật”, “kế toán xác nhận” nhưng thiếu nguồn và người xác nhận	“Nova Foods đã phê duyệt giữ hóa đơn 10 năm.”	Nhầm Owner artifact với Business Owner, Legal Owner hoặc Accounting Owner	Đổi thành Project assumption hoặc Verification required; liên kết nguồn chính thức và vai trò cần xác nhận	IN_REVIEW tại v0.9.0 không phải approval hay baseline
Dùng sai ký pháp (notation misuse)	Sơ đồ gắn nhãn BPMN nhưng dùng hình không theo BPMN; mũi tên không có nghĩa rõ	Activity diagram PlantUML được gọi “BPMN quy trình thu hồi lô”	Ưu tiên hình đẹp hơn ngữ nghĩa chuẩn; không nêu loại sơ đồ	Gắn đúng loại: “PlantUML activity diagram” hoặc tạo BPMN 2.0.2 hợp lệ; thêm chú giải	Không suy ra control vận hành hay compliance chỉ từ sơ đồ
Đứt truy vết (traceability break)	Requirement không nối tới nguồn, rule, data, test hoặc thay đổi	REQ-INV-014 nhắc “chặn xuất lô” nhưng không chỉ nguồn, tiêu chí hay test	Copy nội dung giữa file, sửa ID, hoặc tạo ID ngoài registry	Giữ ID canonical; nối nguồn, quyết định, requirement, acceptance criteria và test basis	Không đổi tên, tái sử dụng, hay tự tạo canonical ID

Applied

Trường	Nội dung
Facts	Artifact mô phỏng ghi: “ERP tự động khóa xuất kho lô sắp hết hạn.” Không có số ngày, loại hàng, kho áp dụng, ngoại lệ đơn hàng đã xác nhận, nguồn quyết định hay test case.
Current Behavior	Developer có thể hiểu là khóa mọi giao dịch; QA có thể kiểm tra chỉ màn hình xuất hàng; vận hành có thể hiểu là cảnh báo. Ba cách hiểu khác nhau cùng tồn tại.
Underlying Need	Cần ngăn xuất lô không còn phù hợp theo chính sách chất lượng được người có thẩm quyền xác nhận, đồng thời vẫn xử lý được trường hợp nghiệp vụ hợp lệ.
Options	A: ghi “sắp hết hạn”. B: BA tự đặt 30 ngày. C: ghi điều kiện chưa xác minh, tạo điểm quyết định và giữ truy vết.
Decision Criteria	Có bằng chứng nguồn; ngưỡng đo được; phạm vi giao dịch rõ; vai trò có quyền quyết định; có đường đến test basis.
Decision	Chọn C. Ghi: Verification required — ngưỡng hạn dùng, phạm vi kho và quyền override cần Quality Owner và Business Owner xác nhận. Không tạo business rule mới.
Authority	Quality Owner quyết định chính sách chất lượng; Business Owner quyết định tác động vận hành; Architect đánh giá cách chặn; QA dùng nội dung đã xác nhận làm test basis. Principal IT Business Analyst / Technical Curriculum Author chỉ giữ artifact và traceability.
Artifact	Tham chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY; giữ trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Khóa quá rộng làm dừng xuất hàng mô phỏng; khóa quá hẹp cho phép giao dịch không đúng chính sách; claim sai thẩm quyền biến giả định học liệu thành cam kết giả.

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

flowchart TB
    A["Artifact hiện tại:<br/>yêu cầu khóa xuất kho lô sắp hết hạn"] --> B{"Có bằng chứng nguồn, loại hàng,<br/>ngưỡng hạn dùng và phạm vi kho, giao dịch?"}

    B -- Không --> V["Ghi Verification required:<br/>nguồn, loại hàng, ngưỡng hạn dùng,<br/>phạm vi kho và giao dịch"]
    B -- Có --> C{"Quyền override và cách xử lý<br/>đơn hàng đã xác nhận đã rõ?"}

    C -- Không --> V
    C -- Có --> D{"Quality Owner đã xác nhận<br/>chính sách chất lượng?"}

    D -- Không --> V
    D -- Có --> E{"Business Owner đã xác nhận<br/>tác động vận hành và ngoại lệ?"}

    E -- Không --> V
    E -- Có --> F["Nội dung đã được<br/>hai owner xác nhận"]

    F --> G{"Có approval reference<br/>được kiểm soát?"}
    G -- Không --> W["Giữ xác nhận nội dung;<br/>không ghi “đã phê duyệt”"]
    G -- Có --> H["Ghi approval reference;<br/>không suy diễn trạng thái phê duyệt"]

    V --> R["Principal IT Business Analyst / Technical Curriculum Author<br/>giữ artifact và traceability;<br/>không tự xác nhận rule"]
    W --> R
    H --> R

    R --> U["Giữ trạng thái IN_REVIEW<br/>version v0.9.0 · ngày 2026-08-07"]
    U --> I{"Ký pháp, ID và liên kết registry<br/>đúng canonical?"}

    I -- Không --> J["Sửa loại sơ đồ, ID<br/>hoặc liên kết registry"]
    J --> I
    I -- Có --> K["Duy trì artifact và traceability"]

    K --> L["Liên kết nguồn và business rule<br/>với CANONICAL_BUSINESS_RULES"]
    L --> M["Liên kết data definition<br/>với CANONICAL_DATA_DICTIONARY"]
    M --> N["Liên kết acceptance criteria và test basis<br/>bằng TRACEABILITY_ID_REGISTRY"]

    N --> AA{"Quality Owner và Business Owner<br/>đã xác nhận đủ nội dung?"}
    AA -- Không --> X["Chờ xác nhận nội dung còn thiếu;<br/>giữ Verification required và IN_REVIEW"]
    AA -- Có --> O["Architect đánh giá cách chặn"]

    O --> P["QA dùng nội dung đã xác nhận<br/>làm test basis"]
    P --> Q{"Rule và cấu hình có đúng chính sách,<br/>phạm vi và ngoại lệ đã xác nhận?"}

    Q -- Có --> Z["Ngăn xuất lô không phù hợp;<br/>xử lý override và đơn hàng đã xác nhận<br/>theo ngoại lệ đã xác nhận"]
    Q -- Không --> Y{"Sai theo hướng nào?"}

    Y -- "Khóa quá rộng" --> S["Dừng xuất hàng mô phỏng"]
    Y -- "Khóa quá hẹp" --> T["Cho phép giao dịch không đúng chính sách"]

[!WARNING] Rủi ro thật: câu “đã phê duyệt” không có approval reference tạo bằng chứng quản trị giả. Không ghi approval suy diễn từ metadata, Owner, IN_REVIEW, version hoặc cuộc họp không có record kiểm soát.

Senior Lens

Mơ hồ khác thiếu thông tin. Mơ hồ có chữ nhưng nhiều nghĩa; thiếu thông tin chưa có phần bắt buộc để thực hiện hoặc kiểm thử. Ví dụ “chỉ người phù hợp được override” là mơ hồ vì “phù hợp” chưa xác định. Yêu cầu không nói ai override, lưu lý do ở đâu, ai xem log là thiếu thông tin.

Claim về pháp lý, kế toán, thuế, bảo mật, an toàn thực phẩm phải tách nội dung nguồn khỏi kết luận dự án. URL Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm là nguồn chính thức đã ghi nhận, nhưng không tự tạo yêu cầu ERP cụ thể. Cầu nối hợp lệ cần: nội dung nguồn được xác minh hiện hành, diễn giải của Legal Owner hoặc Accounting Owner khi thuộc thẩm quyền, rồi quyết định dự án được ghi trong artifact kiểm soát.

Notation là ngôn ngữ có ngữ nghĩa, không phải trang trí. BPMN 2.0.2 của OMG là chuẩn cho BPMN; UML 2.5.1 là chuẩn cho UML. PlantUML có thể tạo activity diagram dễ đọc, nhưng không được gọi là BPMN. Nếu người đọc cần biết trách nhiệm, điểm quyết định, ngoại lệ và message flow theo BPMN, dùng BPMN hợp lệ hoặc nêu rõ sơ đồ hiện tại không thay thế BPMN.

Quick Reference

Kiểm tra trước khi chuyển artifact	Đạt khi	Không đạt thì
Ngôn ngữ	Mỗi từ định tính có định nghĩa hoặc câu hỏi xác minh	Gắn ambiguity
Độ đầy đủ	Có trigger, input, rule, output, ngoại lệ, actor và tiêu chí kiểm tra phù hợp	Gắn incompleteness
Thẩm quyền	Claim có nguồn, record và vai trò đúng thẩm quyền	Gắn Verification required
Ký pháp	Tên sơ đồ khớp chuẩn hoặc công cụ đã dùng	Đổi nhãn hoặc vẽ lại
Truy vết	ID giữ nguyên; nối được source, rule, data, requirement và test basis	Dừng chuyển giao, sửa liên kết

Phục hồi an toàn: không sửa im lặng requirement để “khớp” sơ đồ hoặc test. Giữ lỗi được phát hiện, xác định artifact nguồn, sửa tại nguồn canonical, cập nhật liên kết phụ thuộc theo cơ chế kiểm soát. Không gọi nội dung là baseline, approved, compliant hoặc production-ready tại IN_REVIEW v0.9.0.

11. Senior BA Notes & Rules of Thumb

Core

Senior BA không chọn phương án “được nhiều người thích nhất”. Senior BA chọn khuyến nghị có bằng chứng đủ mạnh, đúng thẩm quyền, nêu rõ đánh đổi. Bằng chứng là dữ liệu, tài liệu nguồn, quan sát quy trình, kết quả thử nghiệm hoặc quyết định được ghi nhận; ý kiến đơn lẻ không tự trở thành fact.

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. IN_REVIEW tại v0.9.0 không phải baseline, approval, xác nhận tuân thủ hay quyền triển khai production.

Applied

Mục	Nội dung
Facts	Kho mô phỏng đề nghị cho phép sửa số lượng lô sau khi phiếu nhập đã ghi nhận. Kế toán mô phỏng yêu cầu giữ dấu vết điều chỉnh. Chưa có nguồn canonical xác nhận quy tắc vận hành.
Current Behavior	Đặc tả hiện tại chỉ ghi “người dùng có thể sửa số lượng”. Không nêu thời điểm khóa, actor, lý do sửa, audit trail hoặc ảnh hưởng tồn kho.
Underlying Need	Cần sửa sai số nhập liệu mà không làm mất khả năng đối chiếu lịch sử.
Options	A: cho sửa trực tiếp. B: khóa bản ghi, tạo giao dịch điều chỉnh có lý do. C: cấm sửa và xử lý ngoài ERP.
Decision Criteria	Khả năng truy vết; tác động tồn kho; khả năng vận hành; chi phí phát triển; thẩm quyền kế toán; bằng chứng kiểm tra.
Decision	Khuyến nghị tạm thời B vì giữ giá trị ban đầu và ghi nhận thay đổi. Đây không phải quyết định kế toán hay rule Nova Foods đã xác nhận.
Authority	Business Owner quyết định nhu cầu vận hành. Accounting Owner xác nhận cách phản ánh điều chỉnh. Architect xác nhận khả thi kỹ thuật. Senior BA ghi nhận phân tích và traceability.
Artifact	Ghi trong artifact kiểm soát với trạng thái Verification required; liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY khi các nội dung tương ứng được đăng ký.
Consequence if Wrong	Sửa trực tiếp có thể làm mất dấu vết. Khóa quá sớm có thể chặn xử lý lỗi hợp lệ. Chọn sai thẩm quyền có thể biến giả định học liệu thành chỉ dẫn vận hành sai.

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

flowchart TB
    A[BA ghi nhận nhu cầu và bằng chứng] --> B[Senior BA so sánh phương án<br/>A: sửa trực tiếp<br/>B: khóa bản ghi và tạo giao dịch điều chỉnh<br/>C: cấm sửa và xử lý ngoài ERP]

    B --> C[Đánh giá theo tiêu chí<br/>khả năng truy vết; tác động tồn kho<br/>khả năng vận hành; chi phí phát triển<br/>thẩm quyền kế toán; bằng chứng kiểm tra]

    C --> D[Đối chiếu hậu quả nếu chọn sai<br/>mất audit trail<br/>chặn sửa lỗi hợp lệ<br/>biến giả định học liệu thành chỉ dẫn vận hành]
    D --> E{Bằng chứng đủ và đúng nguồn?}

    E -- Không --> F[Khuyến nghị tạm thời B<br/>giữ giá trị ban đầu và ghi nhận thay đổi]
    F --> G[Gắn Verification required<br/>không coi là quyết định kế toán<br/>hoặc rule Nova Foods đã xác nhận]

    E -- Có --> H[Ghi phương án được khuyến nghị<br/>từ đánh giá tiêu chí]
    G --> I[Tách nội dung cần xác nhận<br/>theo phạm vi thẩm quyền]
    H --> I

    I --> J[Business Owner quyết định<br/>nhu cầu vận hành]
    I --> K[Accounting Owner xác nhận bắt buộc<br/>cách phản ánh điều chỉnh]
    I --> L[Architect xác nhận<br/>khả thi kỹ thuật]

    J --> M[Senior BA ghi riêng<br/>kết quả và thẩm quyền]
    K --> M
    L --> M

    M --> N{Đủ xác nhận cho<br/>từng phạm vi áp dụng?}
    N -- Không --> O[Giữ Verification required<br/>cho nội dung còn thiếu]
    N -- Có --> P[Ghi quyết định nhu cầu vận hành<br/>và xác nhận kế toán riêng biệt]

    O --> Q[Senior BA cập nhật phân tích<br/>đánh đổi và traceability]
    P --> Q

    Q --> R[Chỉ liên kết nội dung đã đăng ký<br/>CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY<br/>TRACEABILITY_ID_REGISTRY]
    R --> S[Artifact phân biệt khuyến nghị và quyết định<br/>trạng thái xác minh; Owner; traceability]

Senior Lens

Quy tắc thường dùng: ưu tiên phương án bảo toàn dữ liệu gốc, có traceability, rồi tối ưu thao tác. Ngoại lệ: khi dữ liệu gốc chứa thông tin cá nhân không cần giữ, yêu cầu lưu vết phải được Legal Owner và Security xác nhận; Senior BA không tự suy ra thời hạn lưu giữ từ nguồn pháp lý. Cầu nối lập luận là: nguồn pháp lý xác định bối cảnh, chuyên gia có thẩm quyền diễn giải áp dụng, artifact dự án ghi quyết định kiểm soát.

Xung đột stakeholder không phải lỗi cần “dung hòa” ngay. Ví dụ, Kho muốn sửa trực tiếp để nhanh, Kế toán muốn khóa để đối chiếu. Hai yêu cầu đo hai rủi ro khác nhau: thời gian xử lý và mất dấu vết. Senior BA tách claim, bằng chứng, tác động và owner trước khi đề xuất. Không dùng chức danh cao hơn làm bằng chứng thay cho dữ liệu.

Dấu hiệu	Nhận định Senior BA	Ngưỡng escalation
“Hệ thống phải tuân thủ luật” nhưng không có diễn giải áp dụng	Claim quá rộng, chưa thành requirement kiểm tra được	Escalate Legal Owner trước khi viết rule
Hai artifact dùng cùng ID cho hai ý nghĩa	Traceability bị hỏng	Dừng cập nhật, kiểm tra TRACEABILITY_ID_REGISTRY
Rule ảnh hưởng giá trị VND, sổ sách hoặc hóa đơn	Có khả năng thuộc thẩm quyền kế toán/pháp lý	Escalate Accounting Owner và Legal Owner
API trả dữ liệu định danh cá nhân	Có rủi ro privacy và security	Escalate Security và Legal Owner
Quyết định dựa trên một cuộc họp không có record	Bằng chứng yếu, không tái kiểm tra được	Ghi là assumption hoặc Verification required

Khuyến nghị phòng thủ được viết theo mẫu: “Dựa trên [evidence], khuyến nghị [option] để đạt [criterion]. Chưa xác nhận [unknown]. Quyết định cuối thuộc [authority].” Ví dụ: “Dựa trên nhu cầu giữ lịch sử điều chỉnh và thiếu rule canonical đã xác minh, khuyến nghị giao dịch điều chỉnh thay cho sửa trực tiếp để bảo toàn traceability. Chưa xác nhận cách hạch toán. Quyết định cuối thuộc Accounting Owner và Business Owner.”

Quick Reference

Không làm	Làm
Gọi assumption là fact	Gắn nguồn, ngày, chất lượng bằng chứng và khoảng trống
Tự kết luận legal, accounting, security	Chuyển đúng owner; giữ record quyết định
Ép đồng thuận khi xung đột lợi ích	So sánh tiêu chí, tác động và decision authority
Ghi “đã phê duyệt” khi không có record	Giữ IN_REVIEW, v0.9.0, Verification required khi phù hợp

Senior Lens

Senior BA không dùng “best practice” như quy tắc tuyệt đối. Quy tắc mặc định chỉ áp dụng khi bằng chứng đủ tin cậy, phạm vi rõ, quyết định thuộc đúng thẩm quyền, và không xung đột nguồn canonical. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải baseline hay phê duyệt.

Heuristic review	Cách kiểm tra	Red flag	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Một nguồn chân lý	Đối chiếu rule với CANONICAL_BUSINESS_RULES, dữ liệu với CANONICAL_DATA_DICTIONARY, ID với TRACEABILITY_ID_REGISTRY	Hai artifact dùng cùng tên nhưng khác nghĩa, hoặc cùng ID nhưng khác đối tượng	Escalate ngay khi xung đột có thể đổi phạm vi, dữ liệu, kiểm thử hoặc trách nhiệm	Chưa có artifact canonical: ghi là giả định dự án, không tự tạo rule canonical
Tách fact và diễn giải	Fact phải có nguồn, ngày, owner hoặc bản ghi quan sát; diễn giải phải nêu logic suy ra	“Người dùng cần” nhưng không có bằng chứng nhu cầu, tần suất, tác động	Escalate khi diễn giải dẫn tới thay đổi tiền, tồn kho, hóa đơn, quyền truy cập hoặc truy xuất nguồn gốc	Sự cố khẩn cấp có thể ghi workaround tạm; vẫn phải tạo bản ghi quyết định và xác định owner sau đó
Đúng người quyết định	BA xác định Business Owner, Architect, Security, Legal, Accounting, QA theo loại quyết định	BA bị yêu cầu tự chốt thuế, bút toán, tuân thủ, kiến trúc hoặc kiểm soát bảo mật	Escalate ngay khi đề xuất thuộc từ hai thẩm quyền chuyên môn trở lên	Quyết định cách trình bày artifact, nếu không đổi rule hay phạm vi, thuộc trách nhiệm quản trị tài liệu
Kiểm tra tác động đầu-cuối	Lần từ trigger, dữ liệu, rule, màn hình/API, acceptance criteria đến test basis	Requirement chỉ có mô tả giao diện; không có rule, dữ liệu hoặc tiêu chí kiểm thử	Escalate khi không thể tạo test basis mà không tự suy diễn	Proof of concept kỹ thuật giới hạn có thể chưa đủ test basis; phải ghi rõ không phải cam kết nghiệp vụ
Ưu tiên kiểm soát rủi ro	Xác định hậu quả sai: mất dữ liệu, sai tiền, lộ dữ liệu cá nhân, sai traceability	“Để sau” với phân quyền, audit trail, validation hoặc lỗi tích hợp	Escalate trước khi chốt phạm vi nếu sai có thể gây tác động tài chính, pháp lý, an toàn thực phẩm hoặc bảo mật	Dữ liệu demo không có dữ liệu cá nhân thật vẫn cần phân loại rõ là synthetic; không suy ra miễn trừ production

Red flag mạnh là stakeholder dùng cùng từ với mục tiêu khác nhau. Ví dụ, Kho nói “khóa phiếu xuất” để tránh âm tồn; Kế toán nói “khóa” để ngăn sửa chứng từ sau ghi nhận. Từ giống nhau, đối tượng kiểm soát và hậu quả khác nhau. Senior BA tách thành: đối tượng nào bị khóa, trạng thái nào kích hoạt, ai có quyền mở khóa, dữ liệu nào còn được sửa, và hệ thống nào bị ảnh hưởng. Không gộp hai nhu cầu thành một rule vì giảm số dòng tài liệu.

Ngưỡng escalation không phụ thuộc số người phản đối. Một ý kiến đơn lẻ vẫn phải escalation nếu có thể tạo nghĩa vụ pháp lý, diễn giải kế toán, lộ dữ liệu, thay đổi quyền phê duyệt, hoặc làm ERP phát sinh số liệu không thể đối soát. Với nội dung liên quan Luật Kế toán, hóa đơn/chứng từ, dữ liệu cá nhân hoặc an toàn thực phẩm, BA chỉ ghi Verification required và chuyển đúng Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner. Nguồn luật trong corpus cho bối cảnh giáo dục, không thay thẩm quyền chuyên môn.

Quy tắc “hỏi tất cả stakeholder trước khi viết” không áp dụng khi quyết định đã có owner rõ và phạm vi hẹp. Khi đó BA hỏi người chịu trách nhiệm quyết định, rồi kiểm tra nhóm bị ảnh hưởng để phát hiện tác động. Ngược lại, quy tắc “owner nói là đủ” không áp dụng nếu quyết định tác động giao diện, tích hợp, dữ liệu dùng chung, kiểm thử, phân quyền hoặc vận hành. Một owner quyết định mục tiêu nghiệp vụ; không tự xác nhận tính khả thi kỹ thuật, bảo mật hay kế toán.

Bản ghi review phải giữ nguyên ranh giới: nguồn nào là fact, artifact nào là canonical, ai có thẩm quyền, điều kiện nào kích hoạt escalation. Không dùng IN_REVIEW làm bằng chứng rằng rule đúng, đã baseline hoặc được phê duyệt.

Senior Lens

Senior BA không biến thiếu bằng chứng thành khẳng định. Mỗi khuyến nghị phải tách: fact (sự kiện có nguồn), assumption (giả định dự án), unknown (điểm chưa biết), và decision (quyết định thuộc đúng thẩm quyền). Cầu nối suy luận phải ghi rõ: “Vì 00_SOURCE_MAP xác nhận Luật 91/2025/QH15 là nguồn chính thức nhưng chưa xác minh điều khoản áp dụng cho luồng ERP mô phỏng, yêu cầu lưu trường consent_reference chỉ là giả định thiết kế; cần Legal Owner xác minh trước khi gọi là nghĩa vụ.”

Thành phần ghi nhận	Nội dung tối thiểu	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp
Claim ID	ID truy vết đã đăng ký hoặc tham chiếu artifact canonical	Tham chiếu CANONICAL_DATA_DICTIONARY; không tự tạo ID
Fact và nguồn	Sự kiện kiểm chứng được, URL hoặc artifact nguồn	00_SOURCE_MAP ghi Luật 91/2025/QH15 có hiệu lực 2026-01-01
Khoảng trống	Điều nguồn chưa chứng minh	Chưa xác minh điều khoản nào bắt buộc trường dữ liệu cụ thể
Giả định	Điều tạm dùng để phân tích, không phải rule	Giả định đơn hàng có thể chứa thông tin liên hệ người mua
Tác động	Điều gì bị ảnh hưởng nếu giả định sai	Mô hình dữ liệu, quyền xem dữ liệu, chi phí chỉnh sửa
Khuyến nghị	Lựa chọn có điều kiện và lý do	Thiết kế trường logic có thể cấu hình, chưa bật bắt buộc
Authority	Vai trò quyết định, không phải BA	Legal Owner xác minh nghĩa vụ; Business Owner quyết định quy trình; Architect quyết định cách triển khai
Trạng thái	Mức chắc chắn và điều kiện đóng	Verification required; chưa phải APPROVED hay BASELINED

Câu viết phòng vệ được dùng khi bằng chứng chưa đủ: “Khuyến nghị hiện tại là phương án giảm rủi ro thiết kế, dựa trên giả định nêu trên; không xác nhận tuân thủ pháp lý, không thay thế quyết định Legal Owner, và phải được cập nhật khi có kết quả xác minh.” Câu này nêu phạm vi hiểu biết, nguồn suy luận, hậu quả và người có quyền quyết định; không gán chắc chắn giả.

Không viết “hệ thống phải tuân thủ luật” khi chưa có diễn giải được Legal Owner xác minh. Không viết “người dùng yêu cầu” nếu chỉ có ý kiến trong workshop chưa được ghi nhận như quyết định. Không viết “đã phê duyệt” vì IN_REVIEW tại v0.9.0 không tạo approval hay baseline. Với Nova Foods, mọi ví dụ là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, không chứng minh cấu hình ERP thật hay nghĩa vụ vận hành thật.

12. Associated Template Reference & Completed Artifact

Core

Template là biểu mẫu có cấu trúc, dùng để ghi nhận cùng loại thông tin theo cùng quy tắc. Manifest là danh mục kiểm soát, không phải template để điền. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu chỉ là tổng hợp; IN_REVIEW tại v0.9.0, ngày 2026-08-07, không tạo baseline hay approval.

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

flowchart TB
    A[Thông tin cần ghi nhận] --> B{Đã xác định template canonical?}
    B -->|Có| C[Dùng đúng ID và file]
    B -->|Chưa| D[Tra TEMPLATE_MANIFEST]
    D --> E{Có ID và file đã đăng ký?}
    E -->|Có| C
    E -->|Không| F[Không tự tạo ID hoặc file]
    F --> G[Dừng ghi nhận theo template]
    C --> H[Owner soạn nội dung]
    H --> I[Consumer kiểm tra quality gate]

Applied

Thành phần	Nội dung
Facts	Corpus có TEMPLATE_MANIFEST, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY; tất cả IN_REVIEW, v0.9.0. Seed không cung cấp ID template điền cụ thể cho chương này.
Current Behavior	Tác giả cần biết nguồn nào kiểm soát template, ID, rule và dữ liệu trước khi tham chiếu artifact Nova Foods.
Underlying Need	Tránh tự đặt tên file, tự tạo ID, hoặc dùng catalog quản trị như biểu mẫu nghiệp vụ.
Options	Dùng file canonical; dùng bản sao không kiểm soát; tự tạo template mới.
Decision Criteria	Giữ nguyên ID, đường dẫn, trạng thái, owner, source boundary; không vượt thẩm quyền.
Decision	Chỉ tham chiếu artifact canonical đã có trong seed. Không tạo template ID hay filename mới.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì governance; Business Owner, Architect, QA, Legal Owner, Accounting Owner xác nhận phần thuộc thẩm quyền họ.
Artifact	Các artifact trong bảng ### Quick Reference.
Consequence if Wrong	Traceability đứt, nhầm nguồn chân lý, hoặc nội dung mô phỏng bị hiểu sai là quyết định ERP, pháp lý hay kế toán thực tế.

Senior Lens

Không dùng TEMPLATE_MANIFEST để ghi requirement, rule hoặc data field. Bằng chứng: artifact này tự phân loại là controlled planning artifact cho template manifest. Suy ra nó chỉ trả lời “template nào được dự kiến và được kiểm soát”, không trả lời “Nova Foods phải vận hành thế nào”.

Không dùng CANONICAL_BUSINESS_RULES để tự xác nhận luật, thuế, kế toán, an toàn thực phẩm hoặc quyền riêng tư. Bằng chứng: owner của catalog không thay Legal Owner, Accounting Owner hay Business Owner. Suy ra rule có nhãn Verification required phải giữ nguyên nhãn cho đến khi đúng owner xác minh.

Quick Reference

Template/artifact ID	File canonical	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Cần xác định template dự kiến, governance template, phạm vi và ranh giới tạo file	Cần điền requirement, acceptance criteria, rule hay dữ liệu nghiệp vụ	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, template author, QA reviewer	ID, filename, status IN_REVIEW, version v0.9.0 khớp manifest; không suy diễn approval
CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Cần kiểm tra chapter identity, cấu trúc corpus, dependency chapter	Cần tạo rule Nova Foods hoặc xác nhận nội dung đã baseline	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, curriculum reviewer	Slug, title, file path giữ nguyên; không đổi thứ tự hay identity chapter
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm tra định dạng, phạm vi và ownership của ID truy vết	Cần tự cấp ID chưa đăng ký hoặc biến registry thành quyết định nghiệp vụ	Principal IT Business Analyst / Technical Curriculum Author	BA author, QA reviewer, traceability reviewer	ID tham chiếu đúng chuỗi canonical; xung đột ID phải escalation
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Cần liên kết rule nghiệp vụ canonical và trạng thái xác minh	Cần diễn giải pháp luật, kế toán, thuế hoặc công bố rule là đã phê duyệt	Principal IT Business Analyst / Technical Curriculum Author	BA, Business Owner, QA, Legal Owner, Accounting Owner	Rule giữ source boundary, authority và nhãn Verification required khi bằng chứng chưa đủ
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Cần liên kết định nghĩa dữ liệu logic canonical	Cần quyết định schema vật lý, API contract, quyền production hoặc retention pháp lý	Principal IT Business Analyst / Technical Curriculum Author	BA, Architect, QA, Security reviewer	Tên data element, định nghĩa, phân loại và ID không bị đổi im lặng
00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Cần kiểm tra nguồn chính, URL, phiên bản và safe use boundary	Cần bịa điều khoản, số trang, nghĩa vụ pháp lý hoặc trích dẫn không có trong nguồn	Principal IT Business Analyst / Technical Curriculum Author	BA, researcher, Legal Owner, domain owner	URL đúng; ngày truy cập 2026-08-07; tuyên bố pháp lý cần Legal Owner xác minh

Quick Reference

Checklist tra cứu hoàn chỉnh cho /02-handbook/00-foundations.md. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là 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ệ mô phỏng VND.

Kiểm tra	Vị trí trong chapter	Bằng chứng cần thấy
Khái niệm	## 1. Concept l? g??	Định nghĩa, ranh giới, thuật ngữ Anh giải thích lần đầu
Lý do tồn tại	## 2. T?i sao concept n?y t?n t?i?	Vấn đề nghiệp vụ hoặc delivery mà concept xử lý
Lifecycle	## 3. V? tr? trong Lifecycle	Điểm vào, điểm ra, dependency trước và sau
Input	## 4. Input c?n thi?t	Artifact nguồn, chất lượng đầu vào, giới hạn nguồn chân lý
Hoạt động BA	## 5. Step-by-step BA Activities	Trình tự hành động, quyết định, người chịu trách nhiệm
Output	## 6. Output thu ???c	Deliverable, định danh, nội dung tối thiểu, traceability
Người dùng output	## 7. Who consumes those outputs?	Vai trò tiêu thụ và mục đích dùng artifact
Ví dụ Nova Foods	## 8. Detailed Worked Example	Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Decision, Authority, Artifact, Consequence if Wrong
Dependency	## 9. Related Concepts & Dependencies	Liên kết artifact, điều kiện dùng, không tự suy diễn rule
Sai lầm	## 10. Common Mistakes & Anti-patterns	Dấu hiệu sai, hậu quả, cách chặn
Senior BA	## 11. Senior BA Notes & Rules of Thumb	Lý do quyết định, giới hạn thẩm quyền, điểm escalation
Template và artifact	## 12. Associated Template Reference & Completed Artifact	Tra cứu template, checklist, vị trí artifact hoàn chỉnh, trạng thái review

Nguồn tra cứu canonical cho chapter: /01-curriculum/CHAPTER_MANIFEST.md xác nhận cấu trúc chapter; /01-curriculum/TEMPLATE_MANIFEST.md là nguồn tra cứu template dự kiến; /01-curriculum/TRACEABILITY_ID_REGISTRY.md kiểm soát ID; /01-curriculum/CANONICAL_BUSINESS_RULES.md kiểm soát rule; /01-curriculum/CANONICAL_DATA_DICTIONARY.md kiểm soát thuật ngữ dữ liệu logic.

Vị trí artifact Nova Foods đã điền: chưa được đăng ký trong nguồn canonical được cung cấp. TEMPLATE_MANIFEST là planned manifest, không chứng minh tệp completed artifact tồn tại. Không được tự tạo đường dẫn /03-templates/, ID template, hoặc gọi artifact là completed. Trước khi liên kết, đối chiếu TEMPLATE_MANIFEST và CHAPTER_MANIFEST; chỉ ghi vị trí khi tệp, ID, version và trạng thái xuất hiện nhất quán trong artifact kiểm soát.

Quick Reference

Trước handoff chương, chạy self-review liên tệp. Mục tiêu: phát hiện mâu thuẫn trước khi nội dung học liệu dẫn người học tạo requirement, rule hoặc kết luận vượt thẩm quyền. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp. IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải baseline hay approval.

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

flowchart TB
    A[Principal IT BA / Technical Curriculum Author soát chapter và artifact link] --> B[Đối chiếu artifact canonical]
    B --> C{ID, đường dẫn, trạng thái và phạm vi khớp?}
    C -->|Không| E[Log issue và giữ nhãn Verification required]
    C -->|Có| D{Có suy diễn hoặc kết luận chưa có evidence hay thẩm quyền?}
    D -->|Có| E
    D -->|Không| I{Mọi lỗi có owner, mọi suy diễn có evidence bridge, mọi điểm chưa xác minh có nhãn rõ?}
    I -->|Không| E
    I -->|Có| F[Handoff chapter với traceability]

    E --> Q[Principal IT BA / Technical Curriculum Author đóng gói issue, link artifact và giữ traceability]
    Q --> J[Xác định tập owner bắt buộc theo miền issue]

    J -->|Định danh, nguồn, traceability, template| T[Principal IT BA / Technical Curriculum Author]
    J -->|Legal| K[Legal Owner]
    J -->|Kế toán, hóa đơn| L[Accounting Owner]
    J -->|Diễn giải kế toán, hóa đơn, chứng từ| L
    J -->|Diễn giải kế toán, hóa đơn, chứng từ| K
    J -->|Business rule, assumption| M[Business Owner]
    J -->|Truy xuất, thu hồi| M
    J -->|Truy xuất, thu hồi| K
    J -->|Architecture, API| N[Technical Architect]
    J -->|API, dữ liệu nhạy cảm| N
    J -->|API, dữ liệu nhạy cảm| O[Security Owner]
    J -->|Security, dữ liệu nhạy cảm| O
    J -->|Mâu thuẫn dữ liệu logic, schema ERP| N
    J -->|Dữ liệu logic nhạy cảm| O
    J -->|Accessibility| P[QA Owner]
    J -->|Accessibility| N
    J -->|Acceptance criteria, test evidence| P
    J -->|Acceptance criteria, test evidence| M

    T --> R{Đã nhận đủ phản hồi từ mọi owner áp dụng?}
    K --> R
    L --> R
    M --> R
    N --> R
    O --> R
    P --> R

    R -->|Không| J
    R -->|Có| S[Tổng hợp phản hồi có thẩm quyền]
    S --> V{Evidence đủ và mâu thuẫn đã xử lý?}
    V -->|Không| W[Giữ Verification required và issue mở]
    W --> J
    V -->|Có| U[Cập nhật artifact, evidence bridge và đóng issue]
    U --> B

Điểm soát liên tệp	Đối chiếu với	Bằng chứng phải khớp	Lỗi phải ghi nhận	Owner escalation
Định danh và đường dẫn	/01-curriculum/CHAPTER_MANIFEST.md	Tên chapter, /02-handbook/00-foundations.md, trạng thái IN_REVIEW, version v0.9.0	Chapter bị gọi là baseline, approved hoặc production-ready	Principal IT Business Analyst / Technical Curriculum Author
Nguồn và ranh giới nguồn	/00-research/00_SOURCE_MAP.md	URL chính thức, issuer, version/status, safe use boundary	Gán số trang, điều khoản hoặc nghĩa vụ không được source seed xác minh	Principal IT Business Analyst / Technical Curriculum Author; Legal Owner khi có diễn giải luật
ID truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical ID giữ nguyên, không tự tạo biến thể	ID không đăng ký, một ID mang hai nghĩa, link sai artifact	Principal IT Business Analyst / Technical Curriculum Author
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Rule chỉ được mô tả là kế hoạch học liệu khi chưa có authority	Biến giả định Nova Foods thành quy tắc vận hành bắt buộc	Business Owner; Principal IT Business Analyst / Technical Curriculum Author
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Thuật ngữ dữ liệu, entity, thuộc tính không mâu thuẫn	Suy diễn schema ERP, retention hoặc quyền truy cập thực tế	Technical Architect; Security Owner khi có dữ liệu nhạy cảm
Template planning	/01-curriculum/TEMPLATE_MANIFEST.md	Template chỉ được gọi theo ID, filename đã đăng ký	Nêu template chưa có trong manifest như artifact canonical	Principal IT Business Analyst / Technical Curriculum Author
Luật và compliance	Official URLs trong source seed	Nội dung pháp lý giữ nhãn Verification required nếu chưa kiểm tra văn bản hiện hành	Khẳng định tuân thủ Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật Kế toán, Nghị định 123/2020/NĐ-CP hoặc Luật An toàn thực phẩm	Legal Owner; Accounting Owner cho kế toán, hóa đơn
Kiểm thử, bảo mật, accessibility	ISTQB CTFL, OWASP, WCAG	Chuẩn được mô tả đúng phạm vi, không biến good practice thành luật	Claim chứng nhận, compliance hoặc thiết kế security đã xác thực	QA Owner; Security Owner; Technical Architect

Open issues trước handoff

Issue	Lý do mở	Trạng thái cần giữ	Escalation owner
Hiệu lực áp dụng chi tiết luật dữ liệu cá nhân cho ERP mô phỏng	Source seed xác nhận luật và nghị định, không xác nhận cách áp dụng cho từng field, process hoặc integration	Verification required	Legal Owner
Diễn giải kế toán, hóa đơn và chứng từ	Source seed nêu nguồn pháp lý, không cấp diễn giải nghiệp vụ hay cấu hình ERP	Verification required	Accounting Owner; Legal Owner
Rule truy xuất nguồn gốc và thu hồi thực phẩm	Luật An toàn thực phẩm chỉ tạo bối cảnh; chưa có quyết định domain Nova Foods	Project assumption hoặc Verification required	Business Owner; Legal Owner
API, quyền truy cập và dữ liệu nhạy cảm	OpenAPI, OWASP và data dictionary là nguồn/plan; chưa có architecture decision	Verification required	Technical Architect; Security Owner
Test evidence và acceptance criteria	ISTQB là nguồn thuật ngữ; chưa có test basis được authority xác nhận	Verification required	QA Owner; Business Owner

Handoff chỉ được thực hiện khi mọi lỗi có owner, mọi suy diễn có evidence bridge, và mọi điểm chưa xác minh còn nhãn rõ. Principal IT Business Analyst / Technical Curriculum Author đóng gói issue, link artifact và giữ traceability; không thay Legal Owner, Accounting Owner, Business Owner, Technical Architect, Security Owner hoặc QA Owner kết luận chuyên môn.