01 Ba Role Lifecycle And Governance

Trường kiểm soát	Giá trị
Đường dẫn tệp được kiểm soát	/02-handbook/01-ba-role-lifecycle-and-governance.md
Tiêu đề tài liệu	01 Ba Role Lifecycle And Governance
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale	vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp
Phân loại artifact	Handbook chapter có kiểm soát
Owner	Principal IT Business Analyst / Technical Curriculum Author
Baseline reference	Chưa có baseline reference tại v0.9.0
Approval reference	Chưa có approval reference tại v0.9.0; IN_REVIEW không đồng nghĩa với approved, baselined, production-ready hoặc user-approved
Nguồn định hướng	BABOK Guide Version 3 dùng cho thuật ngữ và phạm vi nghề BA; nội dung tiêu chuẩn đầy đủ cần truy cập theo quyền cấp phép
Ranh giới thẩm quyền	Nội dung học liệu không thay thế quyết định của Business Owner, Architect, QA, Legal, Accounting, Security hoặc Compliance; không xác nhận cấu hình ERP hay tuân thủ thực tế của Nova Foods

1. Concept l? g??

Core

Business Analysis, viết tắt BA, là công việc làm rõ vấn đề nghiệp vụ trước khi đội kỹ thuật thay đổi hệ thống. BA không phải người tự quyết định doanh nghiệp cần gì. BA tạo cầu nối có kiểm soát giữa nhu cầu kinh doanh, quy tắc, dữ liệu, người liên quan và giải pháp có thể xây, kiểm thử, vận hành.

BA role lifecycle là vòng đời vai trò BA: BA nhận một nhu cầu, làm rõ nó, ghi thành artifact có thể kiểm tra, hỗ trợ quyết định, rồi giữ truy vết khi nhu cầu thay đổi. Governance là cơ chế quản trị: xác định ai được quyết định gì, artifact nào là nguồn tham chiếu, trạng thái nào được phép dùng, và thay đổi nào phải được ghi nhận. Không có governance, cùng một nhu cầu có thể bị nhiều người hiểu khác nhau; ERP có thể xây đúng màn hình nhưng sai quyết định nghiệp vụ.

Ví dụ trực giác: bộ phận bán hàng nói “cần chặn đơn vượt hạn mức công nợ”. Câu này chưa đủ để lập trình, vì chưa nói khách hàng nào bị áp dụng, hạn mức lấy từ đâu, thời điểm kiểm tra, ai được ngoại lệ, hoặc hệ thống phải ghi nhận kết quả ra sao. BA biến câu nói thành vấn đề được phân tích và kiểm soát. Governance giữ ranh giới: Business Owner quyết định chính sách bán hàng; Accounting Owner xác nhận cách hiểu công nợ; Architect quyết định khả năng kỹ thuật; BA ghi nhận, làm rõ, truy vết và chỉ ra điểm cần quyết định.

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

flowchart TB
    N[Nhu cầu nghiệp vụ] --> B[BA làm rõ và ghi nhận]
    B --> A[Artifact có thể kiểm tra và truy vết]
    A --> D{Owner phù hợp quyết định<br/>Business Owner / Accounting Owner / Architect<br/>BA không quyết định}
    D -- Phê duyệt --> U[Thay đổi hệ thống có kiểm soát]
    D -- Hoãn hoặc cần làm rõ --> B
    D -- Từ chối --> S[Dừng nhu cầu]

    A -. Artifact thay đổi .-> T[Thay đổi được ghi nhận]
    U -. Nhu cầu thay đổi .-> T
    T --> B

    G[Governance] -. Kiểm soát thẩm quyền .-> D
    G -. Kiểm soát trạng thái artifact .-> A
    G -. Kiểm soát thay đổi .-> U
    G -. Kiểm soát ghi nhận thay đổi .-> T
    G -. Nếu thiếu .-> F[Cùng nhu cầu bị hiểu khác nhau<br/>hoặc hệ thống sai quyết định nghiệp vụ]

Trong Nova Foods Trading & Manufacturing mô phỏng, BA có thể nhận nhu cầu “ERP cảnh báo đơn bán khi khách hàng vượt mức công nợ”. Đây là dữ liệu tổng hợp, không phải yêu cầu của doanh nghiệp thật. Khái niệm chương này chỉ bao phủ vòng đời công việc BA và cơ chế quản trị artifact liên quan. Không bao phủ cấu hình ERP, phê duyệt tín dụng, diễn giải kế toán, quy định pháp lý, thiết kế kỹ thuật hoặc xác nhận tuân thủ.

Core

Trong phân tích nghiệp vụ, BA (Business Analyst — Chuyên viên Phân tích Nghiệp vụ) không chỉ “ghi yêu cầu”. BA làm rõ ai cần thay đổi gì, trên đối tượng nào, để đạt kết quả nào; rồi giữ thông tin đó nhất quán qua vòng đời thay đổi và các điểm kiểm soát quản trị.

Thuật ngữ	Nghĩa ngắn	Câu hỏi BA phải trả lời	Ví dụ Nova Foods mô phỏng
Actor	Tác nhân: người, vai trò, hệ thống, hoặc tổ chức thực hiện hay nhận hành động.	Ai khởi tạo, xử lý, phê duyệt, nhận kết quả?	Nhân viên kho là actor ghi nhận hàng nhận. ERP là actor kiểm tra mã hàng.
Action	Hành động: việc actor làm trên đối tượng.	Actor làm động từ gì, tại thời điểm nào, theo điều kiện nào?	Nhân viên kho xác nhận số lượng dầu ăn nhận vào kho.
Object	Đối tượng: dữ liệu, hàng hóa, chứng từ, yêu cầu, hoặc trạng thái bị tác động.	Hành động tác động lên cái gì? Đối tượng có định danh nào?	Phiếu nhận hàng NF-GRN-00041 và mã hàng RM-OIL-001 là object tổng hợp.
Outcome	Kết quả: trạng thái hoặc giá trị có thể quan sát sau hành động.	Sau hành động, cái gì phải đúng, được tạo, đổi trạng thái, hoặc bị chặn?	Phiếu nhận hàng chuyển sang Recorded; tồn kho mô phỏng tăng theo số lượng đã xác nhận.
Business need	Nhu cầu nghiệp vụ: vấn đề hoặc cơ hội cần giải quyết, chưa phải cách làm.	Vì sao cần thay đổi? Nếu không đổi, tổn thất hay rủi ro gì?	Kho cần biết lượng nguyên liệu đã nhận để tránh kế hoạch sản xuất dùng số tồn không đúng.
Requirement	Yêu cầu: nhu cầu, năng lực, điều kiện, hoặc ràng buộc phải được thỏa mãn.	Hệ thống, quy trình, dữ liệu hoặc vai trò phải đáp ứng điều gì?	ERP phải lưu người ghi nhận, thời điểm ghi nhận và số lượng nhận cho từng phiếu.
Lifecycle	Vòng đời: các giai đoạn một thay đổi đi qua từ nhận biết nhu cầu đến kiểm tra kết quả.	Thông tin đi qua các giai đoạn nào? Ai chịu trách nhiệm ở mỗi giai đoạn?	Nhu cầu ghi nhận hàng nhận được làm rõ, đặc tả, xây dựng, kiểm thử và theo dõi kết quả.
Governance	Quản trị kiểm soát: cách xác định thẩm quyền, trạng thái, bằng chứng, thay đổi và truy vết.	Ai được quyết định? Quyết định nào cần bằng chứng? Thay đổi được ghi nhận ở đâu?	IN_REVIEW cho biết artifact đang xem xét; không có nghĩa đã APPROVED hoặc BASELINED.
Traceability	Truy vết: liên kết có kiểm soát giữa nhu cầu, yêu cầu, quy tắc, thiết kế, kiểm thử và kết quả.	Yêu cầu này xuất phát từ đâu, được xây ở đâu, kiểm tra bằng đâu?	Một yêu cầu ghi nhận hàng nhận phải liên kết ngược tới nhu cầu kho và xuôi tới kiểm thử liên quan.
Artifact	Hiện vật công việc: tệp, bảng, sơ đồ, backlog item, đặc tả, biên bản hoặc bằng chứng có thể xem xét.	Thông tin được lưu trong vật chứa nào, phiên bản nào, trạng thái nào?	/02-handbook/01-ba-role-lifecycle-and-governance.md là artifact học liệu được kiểm soát.

Cấu trúc tối thiểu của một phát biểu nghiệp vụ là: actor thực hiện action trên object để tạo outcome. Cấu trúc này buộc BA tách người làm, việc làm, đối tượng và kết quả. Bằng chứng là nếu thiếu một thành phần, câu mô tả không thể kiểm tra đầy đủ: thiếu actor thì không biết trách nhiệm; thiếu action thì không biết thay đổi; thiếu object thì không biết dữ liệu hay hàng hóa bị tác động; thiếu outcome thì không biết tiêu chí thành công.

Ví dụ dữ liệu tổng hợp Nova Foods: Nhân viên kho xác nhận Phiếu nhận hàng NF-GRN-00041 để phiếu có trạng thái Recorded. Đây là mô tả hành vi và kết quả mong muốn trong case study mô phỏng, không phải quy tắc vận hành ERP thực tế, không phải cấu hình production, và không phải quyết định kế toán hay pháp lý.

Ranh giới khái niệm: BA làm rõ, cấu trúc và truy vết thông tin để đúng người có thẩm quyền ra quyết định. BA không tự biến yêu cầu thành phê duyệt, không tự xác nhận tuân thủ, không tự quyết định kế toán, pháp lý, bảo mật hoặc kiến trú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ệ mô phỏng VND là metadata kiểm soát corpus; chúng không chứng minh Nova Foods đã chấp thuận hay áp dụng nội dung.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tên, số liệu và hành vi dưới đây là dữ liệu tổng hợp. Ví dụ tối thiểu: nhân viên mua hàng cần ghi nhận yêu cầu mua PR-NF-0001 cho 100 thùng nguyên liệu. BA không bắt đầu bằng câu “cần làm màn hình tạo phiếu”. BA tách tình huống thành thành phần kiểm tra được.

Thành phần	Giá trị mô phỏng	Ý nghĩa
Actor	Nhân viên mua hàng	Người hoặc vai trò khởi phát việc
Action	Tạo yêu cầu mua	Việc actor thực hiện
Object	PR-NF-0001, 100 thùng nguyên liệu	Đối tượng dữ liệu hoặc nghiệp vụ bị tác động
Outcome	Yêu cầu mua được ghi nhận để xử lý tiếp	Kết quả mong muốn sau action
Evidence	Nhu cầu nguyên liệu do vận hành cung cấp	Căn cứ để BA hỏi, phân tích, truy vết; không phải quyết định hệ thống

Từ các facts trên, concept của chương này là cách BA xác định rõ ai làm gì với cái gì để tạo kết quả nào, trước khi bàn giao diện, API, cơ sở dữ liệu hay cấu hình ERP. Lý do: cùng câu “tạo yêu cầu mua” có thể mang nghĩa khác nếu actor là nhân viên mua hàng, quản lý nhà máy, hoặc hệ thống tự động; outcome cũng khác nếu mục tiêu là lưu nháp hay chuyển xử lý.

Ranh giới khái niệm: ví dụ chỉ mô tả sự kiện nghiệp vụ ở mức hiểu chung. Nó chưa là requirement, business rule, process map, user story, acceptance criteria, thiết kế màn hình, thiết kế API, mô hình dữ liệu, cấu hình ERP, test case hoặc quyết định triển khai. Không suy diễn rằng PR-NF-0001 phải được duyệt, phải có ngưỡng tiền VND, phải tích hợp kho, hay phải tuân thủ quy định pháp lý nào. Các nội dung đó cần facts, nguồn canonical và vai trò có thẩm quyền riêng.

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

flowchart LR
    A[Nhân viên mua hàng<br/>Actor] -->|Tạo<br/>Action| B[PR-NF-0001<br/>Object]
    B --> C[Yêu cầu mua được ghi nhận<br/>Outcome]

Sơ đồ là luồng khái niệm mô phỏng, không phải BPMN. Nó giúp phân biệt bốn thành phần tối thiểu; không xác định trạng thái, bước phê duyệt, quyền truy cập, trường dữ liệu hay tích hợp.

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

Core

Concept Actor–Action–Object–Outcome tồn tại để chặn mơ hồ trước khi mơ hồ biến thành requirement, cấu hình ERP hoặc test case. Một câu nghiệp vụ thiếu một trong bốn thành phần có thể khiến nhiều vai trò hiểu khác nhau: ai được làm, thao tác nào xảy ra, dữ liệu nào bị tác động, và kết quả nào được coi là hoàn thành.

Rủi ro không nằm ở câu chữ ngắn. Rủi ro nằm ở suy diễn ngầm. Nếu BA ghi “tạo yêu cầu mua” nhưng không xác định actor, đội triển khai có thể cấp quyền cho sai vai trò. Nếu không xác định object, hệ thống có thể tạo bản ghi không đúng loại chứng từ. Nếu không xác định outcome, QA không có điểm kết thúc để kiểm tra.

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

flowchart TB
    A[Thiếu actor] -->|có thể dẫn đến| B[Cấp quyền sai vai trò]
    C[Thiếu action] -->|có thể dẫn đến| D[Hiểu khác thao tác]
    E[Thiếu object] -->|có thể dẫn đến| F[Sai loại chứng từ]
    G[Thiếu outcome] -->|có thể dẫn đến| H[QA thiếu điểm kết thúc<br/>để kiểm tra]

Sơ đồ là luồng nguyên nhân khái niệm mô phỏng, không phải BPMN. Nó không xác định quy trình ERP, quyền thực tế, rule Nova Foods hoặc cấu hình production.

Applied

Trong Nova Foods Trading & Manufacturing, case study mô phỏng chỉ dùng dữ liệu tổng hợp, một phát biểu như “tạo yêu cầu mua” chưa đủ để làm đầu vào giao việc. BA cần tách phát biểu thành Actor, Action, Object và Outcome để tránh biến cách hiểu của người ghi chép thành quyết định hệ thống.

Thiếu thành phần	Mơ hồ phát sinh	Rủi ro dự án bị ngăn chặn
Actor	Không rõ nhân viên mua hàng, quản lý hay hệ thống thực hiện	Cấp quyền sai; backlog gán sai người dùng; trách nhiệm bị tranh chấp
Action	“Tạo” có thể là lưu nháp, gửi xử lý hoặc sao chép bản ghi	Dev làm sai chức năng; QA kiểm tra sai hành vi
Object	Không rõ đối tượng là yêu cầu mua, đơn mua hay danh mục nguyên liệu	Trường dữ liệu, tích hợp và báo cáo bị thiết kế sai
Outcome	Không rõ kết quả là ghi nhận, chờ xử lý hay hoàn tất	Không có tiêu chí kết thúc; trạng thái và thông báo bị suy diễn

Mỗi thiếu sót tạo chuỗi rework: BA phải làm rõ lại, đội kỹ thuật sửa thiết kế, QA sửa test basis, rồi stakeholder phải xem lại kết quả. Việc ghi đủ bốn thành phần không quyết định solution; nó khóa phạm vi ý nghĩa tối thiểu để các artifact sau cùng nói về một sự kiện.

Senior Lens

Governance risk là rủi ro quản trị do artifact có vẻ rõ nhưng không truy được ý nghĩa. Requirement không nêu actor dễ bị hiểu là mọi người đều có quyền. Requirement không nêu outcome dễ bị hiểu là một thao tác đã hoàn tất dù chỉ mới tạo dữ liệu. Cả hai trường hợp làm traceability, tức khả năng lần vết từ nhu cầu đến thiết kế và kiểm thử, đứt ở điểm xuất phát.

BA senior không tự lấp chỗ trống bằng kinh nghiệm ngành. Kinh nghiệm chỉ giúp nhận ra câu hỏi cần hỏi. Bằng chứng về actor, action, object và outcome phải nằm trong nguồn nghiệp vụ phù hợp; khi chưa có, nội dung phải giữ trạng thái chưa xác định thay vì bị nâng thành rule, decision hoặc cấu hình ERP.

Quick Reference

Quy tắc kiểm tra	Dấu hiệu đạt	Dấu hiệu phải làm rõ
Actor rõ	Nêu vai trò thực hiện	Chỉ ghi “người dùng”, “bộ phận”
Action rõ	Dùng động từ nghiệp vụ quan sát được	Dùng “xử lý”, “thực hiện” không có nghĩa cụ thể
Object rõ	Nêu đối tượng bị tác động	Dùng “dữ liệu”, “đơn” không phân loại
Outcome rõ	Nêu kết quả sau action	Chỉ nêu mục tiêu chung hoặc ý định

Nguyên tắc: không dùng phát biểu thiếu Actor, Action, Object hoặc Outcome làm căn cứ trực tiếp cho thiết kế, phân quyền, tích hợp hay kiểm thử.

Applied — Đối chiếu trước và sau khi kiểm soát yêu cầu

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Tình huống dưới cho thấy vì sao BA cần biến lời mô tả nghiệp vụ thành artifact có chủ sở hữu, phạm vi và tiêu chí quyết định. Không có kiểm soát này, cùng một câu nói có thể tạo nhiều cách cấu hình ERP khác nhau; đội phát triển, QA và kho không có cùng đối tượng để đối chiếu.

Trường	Trước khi BA làm rõ	Sau khi BA tạo artifact kiểm soát
Facts	Nhân viên kho nói: “Đơn bán cần giữ hàng cho khách.” Hệ thống chưa có tài liệu yêu cầu liên kết câu nói này với hành vi ERP.	Đơn bán mô phỏng SO-NF-2026-001 có mặt hàng RM-COCOA-01; kho cần biết lượng nào được phép xuất.
Current Behavior	Nhân viên tạo đơn; kho vẫn thấy toàn bộ tồn khả dụng. Hai nhân viên có thể cùng chọn cùng lượng hàng trên hai đơn khác nhau.	BA mô tả luồng cần xem xét: tạo đơn, kiểm tra tồn, giữ hàng theo quyết định được ghi nhận, rồi xuất kho theo đơn đủ điều kiện.
Underlying Need	Câu “giữ hàng” chưa nêu thời điểm giữ, phạm vi giữ, điều kiện hủy giữ, hay ai chịu trách nhiệm khi thiếu hàng.	Nhu cầu được giới hạn: tránh kho cam kết cùng một lượng tồn cho nhiều đơn mô phỏng trước khi có quyết định xử lý đơn.
Options	Đội kỹ thuật tự chọn cách hiểu: không giữ hàng, giữ ngay khi tạo đơn, hoặc chỉ giữ khi đơn được xác nhận.	BA ghi ba lựa chọn để Business Owner so sánh: không giữ hàng; giữ khi tạo đơn; giữ khi đơn đạt trạng thái xác nhận nghiệp vụ.
Decision Criteria	Không có tiêu chí chung. Mỗi vai trò tối ưu phần việc riêng.	Tiêu chí: giảm nguy cơ cam kết trùng tồn; không chặn đơn nháp; kho nhìn thấy lượng đã được giữ; có thể truy vết lý do thay đổi giữ hàng.
Decision	Quyết định ngầm, nằm trong cấu hình hoặc trao đổi miệng. Hậu quả không truy được về lý do.	Chưa có quyết định được phê duyệt. Artifact ghi rõ quyết định cần Business Owner xác nhận; trạng thái corpus vẫn IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Authority	Developer hoặc nhân viên kho có thể vô tình thành người quyết định quy tắc nghiệp vụ.	Business Owner quyết định thời điểm giữ hàng; Architect xác nhận khả năng cấu hình; QA dùng quyết định đã ghi nhận làm test basis. BA điều phối và truy vết, không tự quyết thay các vai trò này.
Artifact	Không có nguồn chân lý; lỗi bị mô tả là “hệ thống làm sai” nhưng không xác định được sai so với điều gì.	Bản ghi yêu cầu và decision log dự kiến liên kết với /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md; các artifact này là kế hoạch IN_REVIEW, chưa baseline, chưa approval.
Consequence if Wrong	Kho có thể chọn hàng cho đơn thứ hai dù hàng đã được hứa miệng cho đơn thứ nhất. Sales, kho và QA phát hiện khác biệt muộn; cấu hình và test phải làm lại.	Nếu chọn sai thời điểm giữ, đơn nháp có thể khóa tồn không cần thiết hoặc đơn đã xác nhận vẫn thiếu hàng. Hậu quả được gắn với lựa chọn cụ thể để review trước khi build.

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

flowchart TB
    A[Tạo đơn bán mô phỏng] --> B{Business Owner đã xác nhận thời điểm giữ hàng?}

    B -- Chưa --> C[Dừng build; BA tiếp tục điều phối review]
    C --> D[So sánh lựa chọn, tiêu chí và hậu quả]
    D --> B

    B -- Chưa nhưng vẫn build --> L[Kho và hệ thống diễn giải khác nhau]
    L --> M[Cam kết tồn không nhất quán]

    B -- Đã xác nhận --> E[Quyết định ghi trong requirement artifact và decision log]
    E --> F[Architect xác nhận khả năng cấu hình]
    F --> G[Đội phát triển/cấu hình thực hiện theo quyết định]
    G --> H[Kiểm tra tồn theo quy tắc đã chọn]
    H --> I[Kiểm chứng kho thấy lượng giữ hàng theo tiêu chí]
    I --> J[QA đối chiếu hành vi với quyết định đã ghi nhận]

Khác biệt quan sát được không phải số liệu bịa đặt. Trước kiểm soát, không có nơi xác định “giữ hàng” xảy ra khi nào nên không thể kết luận cấu hình nào đúng. Sau kiểm soát, mỗi lựa chọn có tiêu chí, thẩm quyền và hậu quả sai rõ ràng; đội có thể dừng trước build khi thiếu quyết định, thay vì sửa sau khi kho, sales và QA đã hiểu khác nhau.

Core

Phân loại phát biểu giữ BA không biến lời nói, suy đoán và lựa chọn thành “sự thật”. Mỗi câu về Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dữ liệu tổng hợp, phải mang một nhãn trước khi vào yêu cầu, quy tắc hoặc thiết kế.

Nhãn	Nghĩa từ gốc	Bằng chứng tối thiểu	BA được làm	BA không được làm
Fact đã xác minh	Điều đã được chứng minh bằng nguồn kiểm soát	Artifact canonical, log hệ thống mô phỏng, tài liệu nguồn có định danh	Trích dẫn nguồn, ngày kiểm tra, phạm vi	Suy rộng ngoài phạm vi bằng chứng
Stakeholder input	Ý kiến, mô tả hoặc nhu cầu do bên liên quan cung cấp	Vai trò, ngày ghi nhận, nội dung phát biểu	Ghi nguyên ý nghĩa và người cung cấp	Gọi là fact hoặc requirement đã chốt
Project assumption	Giả định dự án dùng tạm để tiếp tục phân tích	Lý do thiếu dữ liệu, tác động, chủ sở hữu xác minh	Đặt hạn xác minh và rủi ro	Biến thành business rule
Decision	Lựa chọn giữa các phương án theo tiêu chí	Phương án, tiêu chí, người có thẩm quyền, thời điểm	Ghi decision log và phạm vi hiệu lực	Tự quyết thay Business Owner, Architect, Legal Owner, Accounting Owner
Verification-required claim	Phát biểu có thể đúng nhưng chưa đủ bằng chứng hoặc cần thẩm quyền chuyên môn	Nguồn cần kiểm tra, owner xác minh, điều kiện đóng	Giữ nhãn, tạo điểm kiểm tra	Đưa vào cấu hình ERP hoặc cam kết tuân thủ

Fact chỉ trả lời: “đã biết gì và chứng minh bằng gì?” Stakeholder input trả lời: “ai nói cần gì?” Assumption trả lời: “đang tạm tin gì để phân tích không dừng?” Decision trả lời: “ai đã chọn gì theo tiêu chí nào?” Verification-required claim trả lời: “điều gì chưa được phép coi là đúng?”

Applied

Trường	Nội dung Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	CHAPTER_MANIFEST và các artifact upstream có Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07; chưa có baseline reference hoặc approval reference.
Current Behavior	Nhân viên kho nói: “ERP phải chặn xuất hàng nếu lô hết hạn.” Câu này mới là stakeholder input; chưa chứng minh quy trình hiện tại, quy tắc pháp lý, cấu hình hay quyền quyết định.
Underlying Need	Tránh xuất nhầm hàng có rủi ro chất lượng, đồng thời giữ truy vết lý do chặn hoặc cho phép xuất. Đây là nhu cầu cần làm rõ, chưa là rule triển khai.
Options	1. Chặn mọi giao dịch xuất khi ngày hết hạn trước ngày xuất. 2. Cảnh báo, cho phép vai trò được ủy quyền ghi lý do. 3. Không kiểm tra trong ERP, kiểm soát ngoài hệ thống.
Decision Criteria	Bằng chứng quy trình kho; chính sách chất lượng được thẩm quyền xác nhận; khả năng dữ liệu ngày hết hạn; ảnh hưởng đơn hàng; quyền override; yêu cầu truy vết.
Decision	Chưa có decision. Không chọn option nào tại IN_REVIEW.
Authority	Business Owner quyết định vận hành; Quality Owner xác nhận kiểm soát chất lượng; Architect xác nhận khả năng kỹ thuật; Legal Owner xác minh yêu cầu pháp lý nếu được viện dẫn.
Artifact	Ghi từng phát biểu vào artifact kiểm soát phù hợp; giữ liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY khi các artifact này có nội dung được đăng ký.
Consequence if Wrong	Nếu gọi stakeholder input là fact, team có thể xây chặn cứng sai phạm vi. Đơn hàng có thể bị dừng không có quy trình xử lý; hoặc hàng rủi ro vẫn được xuất vì rule thiếu bằng chứng và owner xác nhận.

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

flowchart TB
    A["“ERP phải chặn xuất hàng nếu lô hết hạn”"] --> R["Ghi nhận phát biểu và nguồn cung cấp"]
    R --> E["Stakeholder input"]
    E --> W["Ghi vào artifact kiểm soát phù hợp<br/>Giữ nguyên nhãn"]
    W --> N["Trạng thái hiện tại<br/>IN_REVIEW · v0.9.0 · 2026-08-07<br/>Chưa có Decision<br/>Chưa có baseline hoặc approval reference"]

    N -.->|"Tiếp tục làm rõ"| X["Mở yêu cầu xác minh<br/>bằng chứng và Decision Criteria"]

    X --> B{"Có artifact hoặc nguồn có thẩm quyền<br/>làm bằng chứng?"}
    B -->|Không| H["Verification-required claim"]
    H --> V["Yêu cầu bổ sung hoặc kiểm tra bằng chứng"]
    V --> N
    B -->|Có| C{"Bằng chứng đã được kiểm tra<br/>và owner phù hợp xác nhận đủ?"}
    C -->|Chưa| H
    C -->|Có| F["Bằng chứng hoặc current-state fact<br/>đã xác minh"]

    X --> BO["Business Owner xác nhận<br/>quy trình kho · ảnh hưởng đơn hàng<br/>quyền override"]
    X --> QO["Quality Owner xác nhận<br/>chính sách và kiểm soát chất lượng<br/>yêu cầu truy vết"]
    X --> AR["Architect xác nhận<br/>dữ liệu ngày hết hạn khả dụng<br/>khả năng kỹ thuật"]
    X --> L{"Có viện dẫn yêu cầu pháp lý?"}
    L -->|Có| LO["Legal Owner xác minh<br/>yêu cầu pháp lý"]
    L -->|Không| LR["Xác nhận không cần<br/>xác minh pháp lý"]

    F --> K["Tập hợp bắt buộc<br/>bằng chứng đã xác minh<br/>và đủ xác nhận Decision Criteria"]
    BO --> K
    QO --> K
    AR --> K
    LO --> K
    LR --> K

    K --> J{"Đã đủ bằng chứng và<br/>tất cả xác nhận bắt buộc?"}
    J -->|Chưa| H
    J -->|Đủ| O["Đánh giá Options<br/>1. Chặn mọi giao dịch xuất<br/>2. Cảnh báo, override có lý do<br/>3. Kiểm soát ngoài ERP"]

    O --> P{"Business Owner<br/>đã chọn phương án?"}
    P -->|Chưa| N
    P -->|Có| U["Decision do Business Owner xác nhận"]
    U --> AD["Ghi Decision thành artifact riêng"]

    F --> Z["Khi nội dung được đăng ký<br/>liên kết CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY<br/>TRACEABILITY_ID_REGISTRY"]
    H --> Z
    W --> Z
    AD --> Z

    E -.->|"Nếu gắn nhầm thành fact"| R1["Rủi ro: xây chặn cứng sai phạm vi<br/>và thiếu quy trình xử lý"]
    N -.->|"Nếu thiếu bằng chứng hoặc xác nhận"| R2["Rủi ro: đơn hàng bị dừng không phù hợp<br/>hoặc hàng rủi ro vẫn được xuất"]

    classDef current fill:#fff3cd,stroke:#b7791f,stroke-width:3px,color:#222;
    class A,R,E,W,N current;
    linkStyle 0,1,2,3 stroke:#b7791f,stroke-width:4px;

Senior Lens

Chuỗi suy luận phải lộ rõ. Ví dụ: “Luật An toàn thực phẩm có tồn tại” là fact nguồn vì URL chính thức được cung cấp. “Nova Foods phải chặn xuất hàng hết hạn theo luật” là verification-required claim, vì chưa có đối chiếu nội dung luật hiện hành, chưa có Legal Owner và Quality Owner xác nhận áp dụng cho quy trình mô phỏng. Cầu nối này ngăn BA dùng tên luật làm bằng chứng cho một rule cụ thể.

Không dùng trạng thái artifact để nâng cấp bằng chứng. IN_REVIEW chứng minh trạng thái review của artifact, không chứng minh business rule đúng, không tạo baseline, không tạo approval, không cấp quyền production. Một decision chỉ có hiệu lực trong phạm vi ghi nhận; decision về giao diện không tự chứng minh rule kho, accounting treatment hay nghĩa vụ pháp lý.

Quick Reference

Câu kiểm tra	Nhãn đúng
“CHAPTER_MANIFEST ghi Status IN_REVIEW.”	Fact đã xác minh
“Thủ kho muốn thấy cảnh báo trước khi xuất lô.”	Stakeholder input
“Tạm giả định mỗi lô có ngày hết hạn để vẽ luồng.”	Project assumption
“Business Owner chọn cảnh báo kèm override có lý do.”	Decision, chỉ sau ghi nhận người có thẩm quyền
“Quy định pháp luật bắt buộc phải chặn cứng.”	Verification-required claim cho đến khi Legal Owner xác minh nguồn và phạm vi áp dụng

3. V? tr? trong Lifecycle

Core

Lifecycle là vòng đời biến nhu cầu thành thay đổi vận hành được kiểm tra. BA không “xong requirement” tại một điểm; BA giữ chuỗi bằng chứng từ Discovery đến Operations. Mỗi pha có cổng vào và cổng ra. Cổng vào xác nhận đủ điều kiện bắt đầu pha. Cổng ra xác nhận đầu ra pha đủ làm đầu vào cho pha kế tiếp. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

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

flowchart TB
    D[Discovery<br/>Entry: có vấn đề hoặc cơ hội được ghi nhận; chưa coi là requirement] -->|Exit: problem statement, phạm vi ban đầu, câu hỏi cần xác minh được ghi nhận| A[Analysis<br/>Entry: problem statement và phạm vi ban đầu tồn tại]
    A -->|Exit: mỗi requirement liên kết nguồn, giả định, rule, acceptance criteria; điểm chưa xác minh còn nhãn| DE[Delivery<br/>Entry: gói analysis đủ để đội delivery hiểu hành vi cần tạo]
    DE -->|Exit: build hoặc cấu hình mô phỏng tồn tại, có thể kiểm thử và đối chiếu với acceptance criteria| T[Testing<br/>Entry: có requirement, rule, acceptance criteria và build kiểm thử được]
    T -->|Exit: test evidence, xử lý từng defect được ghi nhận; chênh lệch chưa giải quyết không bị che giấu| R[Release<br/>Entry: có bằng chứng testing theo phạm vi release]
    R -->|Exit: release record, phạm vi đưa ra, điều kiện vận hành được ghi nhận| O[Operations<br/>Entry: thay đổi đã được đưa vào bối cảnh vận hành mô phỏng]
    O -->|Exit: outcome, vấn đề vận hành hoặc nhu cầu thay đổi mới trở thành đầu vào Discovery| D

Pha	Entry gate chính xác	BA tập trung	Exit gate chính xác
Discovery	Có vấn đề hoặc cơ hội được ghi nhận; chưa coi là requirement	Tách fact, stakeholder input, project assumption và verification-required claim	Problem statement, phạm vi ban đầu và câu hỏi cần xác minh được ghi nhận
Analysis	Problem statement và phạm vi ban đầu tồn tại	Chuyển nhu cầu thành requirement, business rule, data need và acceptance criteria có thể kiểm tra	Mỗi requirement liên kết được nguồn, giả định, rule và acceptance criteria; điểm chưa xác minh còn nhãn
Delivery	Gói analysis đủ để đội delivery hiểu hành vi cần tạo	Làm rõ câu hỏi phát sinh; kiểm soát thay đổi để không sửa im lặng requirement	Build hoặc cấu hình mô phỏng tồn tại và có thể đối chiếu với acceptance criteria
Testing	Có test basis: requirement, rule, acceptance criteria và build kiểm thử được	Hỗ trợ giải nghĩa ý định nghiệp vụ; phân biệt defect với thay đổi yêu cầu	Test evidence và xử lý từng defect được ghi nhận; chênh lệch chưa giải quyết không bị che giấu
Release	Có bằng chứng testing theo phạm vi release	Kiểm tra release không làm mất traceability giữa nhu cầu và thay đổi	Release record, phạm vi đưa ra và điều kiện vận hành được ghi nhận
Operations	Thay đổi đã được đưa vào bối cảnh vận hành mô phỏng	Đối chiếu kết quả quan sát với nhu cầu ban đầu; thu nhận incident và change input	Outcome, vấn đề vận hành hoặc nhu cầu thay đổi mới trở thành đầu vào Discovery

Applied

Facts: Nova Foods mô phỏng có nhu cầu giảm nhập nhầm ngày hết hạn cho lô nguyên liệu. Chưa có quy tắc đã xác minh nói rằng hệ thống phải chặn giao dịch.

Current Behavior: Nhân viên kho nhập ngày hết hạn thủ công. Màn hình hiện tại không nêu rõ dữ liệu nào bắt buộc.

Underlying Need: Dữ liệu lô phải đủ tin cậy để quy trình sau có thể nhận biết lô cần xem xét trước khi xuất.

Options: (1) chỉ cảnh báo khi để trống ngày hết hạn; (2) bắt buộc nhập ngày hết hạn; (3) chặn nhập khi ngày hết hạn trước ngày nhận hàng.

Decision Criteria: Khả năng kiểm tra tự động, tác động đến kho, bằng chứng nguồn cho rule, và khả năng xử lý ngoại lệ.

Decision: Chưa chọn phương án. Analysis chỉ ghi ba phương án vì chưa có business rule được xác minh và chưa có quyết định có thẩm quyền.

Authority: Không có authority được xác nhận trong micro-batch này. BA không tự chọn mức chặn hay xác nhận nghĩa vụ pháp lý.

Artifact: Requirement draft liên kết stakeholder input; project assumption nếu cần mô phỏng; acceptance criteria riêng cho từng phương án; traceability ghi trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Nếu Delivery nhận “chặn cứng” như fact khi đó chỉ là giả định, Testing có thể xác nhận đúng build nhưng sai nhu cầu. Release mang rủi ro làm dừng nhập kho không có căn cứ.

Senior Lens

Không cho pha sau bù thiếu pha trước. Testing không nên tự phát minh acceptance criteria vì test pass chỉ chứng minh build phù hợp test basis, không chứng minh nhu cầu đúng. Release không biến project assumption thành decision. Operations phát hiện lỗi hoặc kết quả kém phải tạo đầu vào Discovery mới, không sửa lặng requirement cũ.

Cổng ra phải xét “đủ cho bước kế tiếp”, không xét “tài liệu dài”. Ví dụ, một requirement ngắn nhưng có nguồn, phạm vi, rule liên quan và acceptance criteria kiểm thử được vượt gate Analysis tốt hơn tài liệu dài không chỉ ra điều gì đúng hoặc ai cần xác minh.

Quick Reference

Quy tắc	Cách áp dụng
Discovery chưa phải Analysis	Nhu cầu được ghi nhận chưa tự thành requirement
Analysis chưa phải Delivery	Requirement chưa đủ nếu thiếu tiêu chí kiểm tra hoặc còn lẫn fact với giả định
Delivery chưa phải Testing	Build tồn tại chưa đủ; phải có test basis để biết kiểm tra gì
Testing chưa phải Release	Kết quả test phải gắn requirement và chênh lệch được ghi nhận
Release chưa phải Operations	Đưa thay đổi ra không chứng minh thay đổi tạo kết quả mong muốn
Operations quay về Discovery	Incident, phản hồi và kết quả quan sát là evidence cho chu kỳ tiếp theo

Core

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, BA không sở hữu quyết định nghiệp vụ, kiến trúc, kiểm thử, pháp lý hoặc vận hành. BA sở hữu việc làm rõ nhu cầu, ghi nhận bằng chứng, liên kết truy vết và chuyển giao đúng người. Handoff là điểm chuyển giao có kiểm soát: người giao nêu artifact, trạng thái, câu hỏi mở và rủi ro; người nhận xác nhận đã nhận để xử lý, không đồng nghĩa phê duyệt.

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

flowchart TD
    BO["Business Owner"]
    SME["Subject Matter Expert"]
    DO["Data Owner"]
    BA["BA"]
    ARCH["Architect"]
    DL["Delivery Lead"]
    QA["QA Owner"]
    LEGAL["Legal Owner"]
    ACCOUNT["Accounting Owner"]
    SECURITY["Security Owner"]

    BO -->|"Mục tiêu, vấn đề, phạm vi, ưu tiên, giả định"| BA
    SME -->|"Bằng chứng nguồn, quy tắc, ngoại lệ"| BA
    DO -->|"Định nghĩa, chủ sở hữu, phân loại, ràng buộc dữ liệu"| BA

    BA -->|"Làm rõ, ghi nhận bằng chứng, liên kết truy vết"| TRACE["Handoff có kiểm soát: artifact, trạng thái, câu hỏi mở, rủi ro"]

    TRACE -->|"Requirement; quy tắc có bằng chứng hoặc liên kết CANONICAL_BUSINESS_RULES; dữ liệu có liên kết CANONICAL_DATA_DICTIONARY; kết luận chuyên môn và điều kiện áp dụng"| ARCH
    TRACE -->|"Requirement, evidence, trạng thái, câu hỏi mở, rủi ro"| DL
    TRACE -->|"Test basis, acceptance criteria, kết luận chuyên môn và điều kiện áp dụng"| QA
    TRACE -->|"Vấn đề cần quyết định, kết luận chuyên môn và điều kiện áp dụng"| BO

    ARCH -->|"Thiết kế khả thi, phụ thuộc, giới hạn kỹ thuật"| TECH["Handoff giải pháp kỹ thuật"]
    TECH -->|"Thiết kế, phụ thuộc, giới hạn"| BA
    TECH -->|"Thiết kế, phụ thuộc, giới hạn"| DL
    TECH -->|"Thiết kế, phụ thuộc, giới hạn"| QA

    QA -->|"Defect, bằng chứng kiểm thử, kết quả kiểm thử"| BA

    BA -.->|"Mục tiêu, ưu tiên hoặc quy tắc cần quyết định"| BO
    BA -.->|"Diễn giải chuyên môn cần xác nhận"| SME
    BA -.->|"Xung đột định nghĩa hoặc quyền sở hữu dữ liệu"| DO
    BA -.->|"Yêu cầu tích hợp hoặc requirement không được đáp ứng"| ARCH
    BA -.->|"Dữ liệu cá nhân, rủi ro bảo mật hoặc mất dữ liệu"| SECURITY
    BA -.->|"Rủi ro pháp lý"| LEGAL
    BA -.->|"Rủi ro kế toán hoặc hóa đơn"| ACCOUNT
    QA -.->|"Thiếu acceptance criteria hoặc defect làm sai business rule"| BA
    QA -.->|"Tranh chấp expected result nghiệp vụ"| BO
    BA -.->|"Mục tiêu mâu thuẫn hoặc phạm vi vượt thẩm quyền Business Owner"| STOP["Dừng handoff và escalation"]

    LEGAL -->|"Kết luận pháp lý và điều kiện áp dụng"| CONCLUSION["Kết luận chuyên môn có thẩm quyền"]
    ACCOUNT -->|"Kết luận kế toán và điều kiện áp dụng"| CONCLUSION
    SECURITY -->|"Kết luận bảo mật và điều kiện áp dụng"| CONCLUSION
    CONCLUSION -->|"BA ghi nhận và liên kết truy vết"| TRACE

    BO -->|"Xác nhận đã nhận"| ACK["Đã nhận để xử lý, không đồng nghĩa phê duyệt"]
    ARCH -->|"Xác nhận đã nhận"| ACK
    DL -->|"Xác nhận đã nhận"| ACK
    QA -->|"Xác nhận đã nhận"| ACK
    ACK -->|"Cập nhật trạng thái handoff"| BA

Luồng	Upstream owner	Handoff BA nhận hoặc giao	Downstream owner	Giới hạn BA	Escalation
Nhu cầu nghiệp vụ	Business Owner	Mục tiêu, vấn đề, phạm vi, ưu tiên, giả định	Architect, Delivery Lead, QA Owner	Không tự chọn ưu tiên hoặc xác nhận quy tắc đúng cho vận hành	Mục tiêu mâu thuẫn, phạm vi vượt quyết định Business Owner
Quy tắc nghiệp vụ	Subject Matter Expert, Business Owner	Bằng chứng nguồn, diễn giải, điều kiện ngoại lệ, liên kết CANONICAL_BUSINESS_RULES	QA Owner, Delivery Lead	Không tự tạo quy tắc canonical hoặc gọi nội dung là approved	Quy tắc ảnh hưởng giá, tồn kho, hóa đơn, kế toán, truy xuất thực phẩm
Dữ liệu	Data Owner, Security Owner	Thuộc tính logic, chủ sở hữu dữ liệu, phân loại, ràng buộc, liên kết CANONICAL_DATA_DICTIONARY	Architect, QA Owner	Không quyết định mô hình vật lý, quyền truy cập hoặc mức bảo vệ	Có dữ liệu cá nhân, xung đột định nghĩa, yêu cầu tích hợp
Giải pháp kỹ thuật	Architect	Khả thi kỹ thuật, phụ thuộc, giới hạn giao diện	Delivery Lead, BA, QA Owner	Không phê duyệt kiến trúc, API, bảo mật hoặc production design	Thiết kế không đáp ứng requirement, có rủi ro bảo mật hoặc mất dữ liệu
Kiểm thử	QA Owner	Test basis, defect evidence, kết quả kiểm thử	Business Owner, Delivery Lead	Không tự đóng defect hoặc xác nhận chất lượng phát hành	Defect làm sai business rule, thiếu acceptance criteria, tranh chấp expected result
Tuân thủ	Legal Owner, Accounting Owner, Security Owner	Kết luận chuyên môn và điều kiện áp dụng	Business Owner, Architect, QA Owner	Không diễn giải luật hoặc xác nhận compliance	Nội dung liên quan Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật Kế toán, hóa đơn hoặc an toàn thực phẩm

Applied

Facts: Nova Foods mô phỏng cần thay đổi quy tắc chặn xuất kho khi lô hàng không có thông tin truy xuất đầy đủ. Yêu cầu đến từ Subject Matter Expert, nhưng chưa có kết luận pháp lý hay xác nhận cấu hình ERP thật.

Current Behavior: BA ghi nhận nhu cầu “chặn xuất kho” và liên kết với CANONICAL_BUSINESS_RULES; Delivery Lead hỏi có được cho phép người dùng vượt chặn không.

Underlying Need: Cần phân biệt nhu cầu kiểm soát nghiệp vụ với quyết định về quyền override, dữ liệu truy xuất và căn cứ pháp lý.

Options: (1) BA tự ghi rule không cho override; (2) BA ghi hai phương án override và chuyển quyết định; (3) Delivery Lead tự chọn theo khả năng hệ thống.

Decision Criteria: Quyết định phải có Business Owner cho tác động vận hành, Architect cho khả thi kỹ thuật, Security Owner cho quyền override, Legal Owner hoặc domain owner cho ngữ cảnh truy xuất thực phẩm. Bằng chứng là một câu hỏi đồng thời chạm vận hành, quyền truy cập và yêu cầu tuân thủ.

Decision: Chọn phương án (2). BA ghi nhận hai phương án, tác động từng phương án, câu hỏi mở và traceability; không chọn thay.

Authority: Business Owner quyết định mức chấp nhận gián đoạn xuất kho; Architect xác nhận cơ chế kỹ thuật; Security Owner xác nhận quyền override; Legal Owner hoặc domain owner xác minh nghĩa vụ pháp lý. Đây là Verification required, không phải kết luận tuân thủ.

Artifact: BA cập nhật liên kết trong /01-curriculum/CANONICAL_BUSINESS_RULES.md, tham chiếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md cho thông tin lô, và ghi escalation trong artifact đang IN_REVIEW, v0.9.0, ngày 2026-08-07.

Consequence if Wrong: BA tự cấm hoặc cho phép override có thể tạo gián đoạn giao hàng, mở quyền truy cập sai, hoặc biến giả định học liệu thành quyết định vận hành không có thẩm quyền.

Senior Lens

Escalation không phải chuyển trách nhiệm mơ hồ. BA phải chuyển gói quyết định gồm: sự kiện, nguồn, lựa chọn, tác động, người có thẩm quyền, hạn cần phản hồi và artifact bị ảnh hưởng. Nếu thiếu nguồn canonical hoặc nguồn mâu thuẫn, giữ trạng thái IN_REVIEW; không nâng thành baseline, approved, compliant hoặc production-ready.

Quick Reference

Tình huống	BA làm	BA không làm
Business Owner đổi ưu tiên	Ghi thay đổi, tác động, traceability	Tự chấp nhận đổi phạm vi
Architect từ chối giải pháp	Làm rõ requirement và ghi ràng buộc	Ép thiết kế kỹ thuật
QA báo defect	So sánh defect với test basis và rule	Tự đóng defect
Có dữ liệu cá nhân hoặc quyền truy cập	Escalate Security Owner và Legal Owner	Tự kết luận tuân thủ
Có tác động kế toán, hóa đơn, thuế	Escalate Accounting Owner và Legal Owner	Tự diễn giải nghĩa vụ

Core

Bản đồ vòng đời là sơ đồ cho thấy thứ tự công việc từ Discovery đến Operations. Sơ đồ không tự tạo quy tắc, phê duyệt, baseline hay thẩm quyền. Nó giúp BA nhìn thấy điểm một thông tin được làm rõ, chuyển thành nội dung có thể xây dựng, được kiểm thử, đưa vào sử dụng và theo dõi sau phát hành. Với Nova Foods Trading & Manufacturing — mô phỏng giáo dục, mọi dữ liệu trong sơ đồ là tổng hợp.

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

flowchart TB
    D[Discovery<br/>Khám phá vấn đề]
    A[Analysis<br/>Phân tích nhu cầu]
    DE[Delivery<br/>Xây dựng thay đổi]
    T[Testing<br/>Kiểm thử]
    R[Release<br/>Quy trình phát hành]
    O[Operations<br/>Vận hành và theo dõi]

    D -->|Nhu cầu, bối cảnh, giả định| A
    A -->|Yêu cầu, quy tắc, tiêu chí chấp nhận| DE
    DE -->|Thay đổi kỹ thuật đã xây dựng| T
    T -->|Đáp ứng test basis;<br/>chuyển sang quy trình phát hành| R
    T -->|Lỗi xây dựng| DE
    T -->|Yêu cầu, quy tắc hoặc tiêu chí<br/>chưa đúng hoặc chưa rõ| A
    R -->|Phiên bản được phát hành| O
    O -->|Phản hồi, sự cố, số liệu sử dụng| D

Discovery trả lời “vấn đề nào đáng xem xét”. Analysis trả lời “hệ thống và quy trình cần thay đổi thế nào”. Delivery biến nội dung phân tích thành thay đổi kỹ thuật. Testing kiểm tra thay đổi so với test basis — tập yêu cầu, quy tắc và tiêu chí chấp nhận dùng làm căn cứ kiểm thử. Release đưa thay đổi qua môi trường sử dụng theo kiểm soát dự án. Operations quan sát kết quả thực tế và tạo tín hiệu cho vòng khám phá tiếp theo.

Applied

Trường	Nội dung mô phỏng Nova Foods
Facts	Nhân viên kho ghi nhận chênh lệch tồn kho của mã hàng RM-SUGAR-001 sau kiểm đếm.
Current Behavior	Nhóm vận hành gửi mô tả sự cố; BA chưa có sơ đồ chung để phân biệt đây là vấn đề khám phá, yêu cầu thay đổi hay lỗi sau phát hành.
Underlying Need	Cần nhìn một luồng thống nhất để không chuyển thẳng sự cố sang Delivery khi chưa phân tích nguyên nhân và phạm vi.
Options	Dùng danh sách bước văn bản; dùng sơ đồ vòng đời; dùng BPMN đầy đủ.
Decision Criteria	Người mới phải quét nhanh; sơ đồ phải thể hiện vòng phản hồi; không được giả định quy trình vận hành chi tiết chưa được xác minh.
Decision	Dùng Mermaid flowchart vòng đời cấp cao như trên. Evidence: sáu pha được nối tuần tự và Operations quay lại Discovery, nên người đọc thấy thay đổi ERP là chu trình, không phải đường thẳng một chiều.
Authority	Sơ đồ học liệu thuộc /02-handbook/01-ba-role-lifecycle-and-governance.md, trạng thái IN_REVIEW, phiên bản v0.9.0; không cấp quyền quyết định nghiệp vụ, kiến trúc, QA, pháp lý hay production.
Artifact	Bản đồ vòng đời trong section 03-lifecycle; tham chiếu quản trị nguồn từ /00-research/00_SOURCE_MAP.md và cấu trúc chapter từ /01-curriculum/CHAPTER_MANIFEST.md.
Consequence if Wrong	Nếu đặt Testing trước Delivery hoặc bỏ phản hồi Operations, learner có thể suy ra sai rằng kiểm thử không cần sản phẩm xây dựng hoặc sự cố vận hành không tạo đầu vào phân tích mới.

Senior Lens

Không gọi Mermaid flowchart là BPMN. BPMN 2.0.2 của OMG là chuẩn ký pháp riêng; sơ đồ này chỉ là bản đồ học tập dễ quét. Khi cần mô tả luồng nghiệp vụ có sự kiện, cổng quyết định, thông điệp và trách nhiệm chi tiết, dùng BPMN đúng ký pháp và xác minh với owner phù hợp.

Bản đồ này không khẳng định Nova Foods có quy trình ERP thực tế như vậy. Nó chỉ biểu diễn mô hình lifecycle tối thiểu cho dữ liệu tổng hợp. Mọi chi tiết liên quan kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc phải giữ nhãn Verification required cho đến khi owner có thẩm quyền xác minh nguồn chính thức.

Quick Reference

Pha	Câu hỏi định hướng
Discovery	Có vấn đề hoặc cơ hội nào cần hiểu?
Analysis	Nhu cầu nào được diễn đạt thành yêu cầu có thể kiểm tra?
Delivery	Thay đổi nào được xây dựng từ nội dung đã phân tích?
Testing	Thay đổi có đáp ứng test basis không?
Release	Thay đổi nào được đưa vào môi trường sử dụng?
Operations	Dữ liệu sử dụng, phản hồi hoặc sự cố nào cần quay lại Discovery?

4. Input c?n thi?t

Core

Input là thứ BA nhận trước khi phân tích: kiến thức nền, bằng chứng (evidence), artifact nguồn và định danh canonical. Không có input, BA không được biến suy đoán thành yêu cầu.

Người mới không cần biết ERP trước. ERP là hệ thống tích hợp dữ liệu và hoạt động giữa nhiều bộ phận, như mua hàng, kho, bán hàng và kế toán. BA cần hiểu ba câu hỏi trước: nghiệp vụ đang muốn đạt kết quả gì, dữ liệu nào chứng minh hiện trạng, và artifact nào là nguồn được kiểm soát.

Định danh canonical là mã giữ nguyên dạng giữa các artifact. Ví dụ TRACEABILITY_ID_REGISTRY luôn chỉ registry định danh tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Không đổi thành ID Registry, không dịch mã, không tự tạo biến thể. Lý do: một liên kết chỉ đáng tin khi người đọc mở đúng nguồn.

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

flowchart TB
    G[Kết quả nghiệp vụ cần đạt] --> C["Ngữ cảnh phân tích:<br/>mục tiêu, bằng chứng, artifact nguồn"]
    K[Kiến thức nền] --> C
    E[Bằng chứng] --> C
    S[Artifact nguồn kiểm soát] --> C
    I[Định danh canonical] --> T["Traceability:<br/>liên kết định danh với artifact nguồn"]
    S --> T
    C --> R[Phân tích có thể kiểm tra]
    T --> R

Sơ đồ là Mermaid flowchart, không phải BPMN. Nó mô tả quan hệ dữ liệu học tập, không khẳng định quy trình ERP thực tế của Nova Foods.

Applied

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

Thành phần input	Giá trị mô phỏng	Bằng chứng hoặc lý do dùng	Canonical ID / đường dẫn
Kiến thức nghiệp vụ tối thiểu	Đơn bán hàng có thể cần kiểm tra tồn kho trước khi giao	Người học phải hiểu “đơn hàng”, “tồn kho”, “giao hàng” trước khi đọc yêu cầu	NF-CONCEPT-ORDER-001
Kiến thức dữ liệu tối thiểu	Mỗi sản phẩm cần mã nhận diện ổn định, ví dụ NF-SKU-CHILI-500G-001	Tên sản phẩm có thể đổi; mã ổn định mới liên kết được đơn hàng, kho và báo cáo	CANONICAL_DATA_DICTIONARY
Bằng chứng hiện trạng	Bảng mô phỏng ghi 18 đơn bán hàng ngày 2026-08-05; 3 đơn bị giữ vì kho ghi nhận thiếu hàng	Bằng chứng là dữ liệu quan sát được, khác với ý kiến “hệ thống chậm”	NF-EVD-SO-20260805-001
Artifact nguồn quản trị	Danh mục chapter và định danh corpus	Xác định phạm vi chapter, tên tệp và ID được phép tham chiếu	/01-curriculum/CHAPTER_MANIFEST.md; CHAPTER_MANIFEST
Artifact nguồn dữ liệu	Kế hoạch từ điển dữ liệu logic canonical	Là nguồn cho nghĩa logic của thực thể và trường dữ liệu; không phải schema triển khai	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; CANONICAL_DATA_DICTIONARY
Artifact nguồn quy tắc	Kế hoạch catalog quy tắc nghiệp vụ canonical	Tách quy tắc khỏi mô tả quy trình để tránh chép cùng một rule vào nhiều nơi	/01-curriculum/CANONICAL_BUSINESS_RULES.md; CANONICAL_BUSINESS_RULES
Artifact nguồn truy vết	Registry định danh canonical	Kiểm tra mã requirement, rule, data và artifact có thuộc registry hay không	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; TRACEABILITY_ID_REGISTRY
Nguồn chuẩn nghề nghiệp	BABOK Guide, Version 3	Dùng thuật ngữ và phạm vi năng lực BA; không gán số trang hoặc điều khoản chưa kiểm chứng	SRC-BABOK-V3; https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Mục cần xác minh	Ý nghĩa nghiệp vụ của trạng thái ON_HOLD_STOCK	Bằng chứng chỉ cho thấy trạng thái xuất hiện; chưa chứng minh ai được đặt trạng thái hoặc điều kiện chuyển trạng thái	NF-VERIFY-SO-001 — Verification required

Facts: Có bằng chứng mô phỏng NF-EVD-SO-20260805-001 về 3 đơn bị giữ.

Current Behavior: Nhân viên kho ghi thiếu hàng sau khi đơn đã được tạo.

Underlying Need: Cần hiểu dữ liệu tồn kho nào được dùng trước khi suy ra yêu cầu kiểm tra hàng.

Options: Dùng lời kể không có artifact; dùng bảng chứng cứ nhưng không có ID; dùng chứng cứ, artifact canonical và ID giữ nguyên.

Decision Criteria: Liên kết phải mở được nguồn; dữ liệu mô phỏng phải phân biệt với fact vận hành; mã phải không đổi giữa artifact.

Decision: Dùng NF-EVD-SO-20260805-001 làm bằng chứng mô phỏng, tham chiếu CANONICAL_DATA_DICTIONARY cho nghĩa dữ liệu, giữ NF-VERIFY-SO-001 chưa kết luận.

Authority: Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability. Business Owner xác nhận nhu cầu; Data Owner xác nhận nghĩa dữ liệu; không có approval được ghi nhận.

Artifact: /02-handbook/01-ba-role-lifecycle-and-governance.md, section 04-inputs; các artifact nguồn giữ nguyên đường dẫn nêu trong bảng.

Consequence if Wrong: Nếu BA đổi mã hoặc coi ON_HOLD_STOCK là rule đã xác nhận, requirement sau đó có thể truy sai nguồn và biến giả định mô phỏng thành quyết định vận hành.

Senior Lens

Phân biệt ba mức thông tin. Kiến thức nền giúp hiểu từ ngữ. Bằng chứng cho biết điều đã được quan sát. Artifact nguồn cho biết nội dung nằm ở đâu và chịu kiểm soát nào. Cầu nối suy luận phải hiện rõ: “3 đơn bị giữ” là evidence; “cần kiểm tra tồn kho” là need cần phân tích; không phải rule tự động được xác lập.

IN_REVIEW và v0.9.0 là trạng thái quản trị của corpus ngày 2026-08-07, không phải baseline, approval, xác nhận pháp lý hay quyền dùng production. Các nguồn pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc không được suy diễn thành nghĩa vụ Nova Foods khi chưa có xác minh owner có thẩm quyền.

Quick Reference

Loại	BA cần giữ	Không được làm
Kiến thức nền	Định nghĩa nghiệp vụ tối thiểu	Giả định người đọc biết ERP
Bằng chứng	Quan sát, dữ liệu hoặc bản ghi có ID	Đổi ý kiến thành fact
Artifact nguồn	Tên tệp, đường dẫn, Artifact ID nguyên dạng	Thay nguồn bằng bản sao không kiểm soát
Canonical ID	Chuỗi mã chính xác, ví dụ TRACEABILITY_ID_REGISTRY	Dịch, rút gọn hoặc tự tạo mã
Mục chưa rõ	Nhãn Verification required và ID theo dõi	Kết luận thay owner có thẩm quyền

Core

Input là thông tin BA nhận trước khi phân tích. Chất lượng input quyết định chất lượng requirement: nguồn không rõ, quá cũ, sai owner, hoặc vượt thẩm quyền thì BA không được biến nó thành quy tắc ERP.

Phân loại nguồn:

Phân loại	Ý nghĩa	Cách dùng	Không được suy ra
PRIMARY_OFFICIAL	Nguồn chính thức từ cơ quan, tổ chức phát hành chuẩn, hoặc artifact kiểm soát	Dùng làm bằng chứng cho phạm vi, thuật ngữ, trạng thái, metadata	Điều khoản chi tiết không có trong phần đã xác minh
INTERNAL_CANONICAL	Artifact canonical trong corpus Nova Foods mô phỏng	Dùng giữ ID, filename, source boundary, traceability	Approval, baseline, cấu hình ERP thật
PROJECT_ASSUMPTION	Giả định học liệu chưa được authority xác nhận	Dùng tạo câu hỏi và phương án phân tích	Nghĩa vụ bắt buộc, quyết định vận hành
VERIFICATION_REQUIRED	Thông tin cần owner có thẩm quyền xác minh	Giữ nhãn, lập điểm kiểm tra	Kết luận pháp lý, kế toán, bảo mật, thực phẩm

Kiểm tra chất lượng input theo năm điểm: định danh, nguồn gốc, tính mới, owner, và thẩm quyền. Mỗi input phải có Artifact ID hoặc URL canonical, ngày truy cập hay cập nhật theo Asia/Ho_Chi_Minh, owner chịu trách nhiệm nội dung, trạng thái kiểm chứng, và giới hạn sử dụng. Không có các trường này thì input chỉ là ghi chú, chưa là evidence.

Applied

Facts: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Corpus có trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07. /01-curriculum/TRACEABILITY_ID_REGISTRY.md là nguồn canonical cho định danh; /01-curriculum/CANONICAL_BUSINESS_RULES.md chưa là baseline hay approval.

Current Behavior: BA nhận câu “lô hàng phải truy xuất được” từ ghi chú workshop không định danh, không ngày ghi nhận, không có Food Safety Owner xác nhận.

Underlying Need: Phân biệt ngữ cảnh nghiệp vụ hữu ích với requirement có thể giao cho đội ERP.

Options: (1) Viết ngay business rule; (2) bỏ hẳn ghi chú; (3) ghi nhận là VERIFICATION_REQUIRED, liên kết nguồn pháp lý phù hợp và chuyển đúng owner xác minh.

Decision Criteria: Nguồn có canonical reference; nội dung còn mới; owner có thẩm quyền; diễn giải không vượt safe use boundary; kết quả không tạo approval ngầm định.

Decision: Chọn phương án 3. Ghi chú giữ làm evidence chưa xác minh; không tạo rule bắt buộc.

Authority: Food Safety Owner và Legal Owner xác minh nghĩa vụ áp dụng. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.

Artifact: Ghi nhận trong artifact đang soạn với source classification VERIFICATION_REQUIRED; tham chiếu CANONICAL_BUSINESS_RULES chỉ khi catalog có entry canonical phù hợp.

Consequence if Wrong: Nếu BA gọi ghi chú là rule đã xác nhận, đội ERP có thể thiết kế kiểm soát sai phạm vi; tài liệu học liệu cũng bị hiểu nhầm là hướng dẫn tuân thủ production.

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

flowchart TB
    A[Nhận ghi chú hoặc input] --> B{Có ID hoặc URL canonical?}
    B -- Không --> V[Gắn VERIFICATION_REQUIRED]
    B -- Có --> C{Có owner có thẩm quyền và ngày hiệu lực/cập nhật?}
    C -- Không --> V
    C -- Có --> D{Nguồn còn mới?}
    D -- Không --> V
    D -- Có --> E{Nội dung trong safe use boundary?}
    E -- Không --> V
    E -- Có --> Q[Evidence phân tích đủ điều kiện]

    V --> T[Principal IT Business Analyst / Technical Curriculum Author duy trì traceability]
    T --> L[Liên kết nguồn pháp lý phù hợp; chỉ tham chiếu CANONICAL_BUSINESS_RULES khi catalog có entry canonical phù hợp<br/>Catalog chưa là baseline hay approval]
    L --> F[Food Safety Owner hoặc Legal Owner xác minh nghĩa vụ thuộc thẩm quyền]
    F --> R{Đã xác minh ID/URL canonical, owner có thẩm quyền, ngày hiệu lực/cập nhật, độ mới và safe use boundary?}
    R -- Không --> V
    R -- Có --> Q

    Q --> N[Không là business rule bắt buộc<br/>Không tạo approval ngầm định]
    N --> X{Phân loại sai?}
    X -- Có --> Y[ERP có thể thiết kế kiểm soát sai phạm vi<br/>Học liệu có thể bị hiểu là hướng dẫn tuân thủ production]

Senior Lens

Freshness là độ mới phù hợp với quyết định, không phải chỉ ngày gần nhất. Ví dụ, ISO/IEC/IEEE 29148:2018 vẫn là nguồn thư mục hợp lệ theo seed, nhưng trạng thái “marked to be revised in 2026” buộc BA không mô tả nó là chuẩn mới nhất không điều kiện. Với luật, thuế, kế toán, bảo vệ dữ liệu, an toàn thực phẩm và hóa đơn, ngày hiệu lực và sửa đổi sau ngày kiểm tra là điều kiện bắt buộc trước khi rút ra system requirement.

Stop condition kích hoạt khi có một trong các tình huống: ID không khớp registry; filename không phải đường dẫn canonical; nguồn thứ cấp bị dùng thay nguồn chính thức khi nguồn chính thức đã có; ngày cập nhật không biết; owner không xác định; hai nguồn canonical mâu thuẫn; hoặc input bị diễn đạt thành nghĩa vụ pháp lý, kế toán, bảo mật hay vận hành dù chưa có owner chuyên môn xác minh. Khi dừng, BA chỉ ghi nhận khoảng trống, bằng chứng hiện có, người cần xác minh và ảnh hưởng; không tự điền rule.

Quick Reference

Kiểm tra	Đạt khi	Hành động khi không đạt
Source classification	Có đúng một nhãn PRIMARY_OFFICIAL, INTERNAL_CANONICAL, PROJECT_ASSUMPTION, hoặc VERIFICATION_REQUIRED	Gắn nhãn lại trước phân tích
Freshness	Có ngày truy cập/cập nhật 2026-08-07 hoặc ngày khác được ghi rõ; đánh giá hiệu lực theo loại nguồn	Dừng dùng làm evidence quyết định
Ownership	Có owner nội dung và giới hạn thẩm quyền	Chuyển xác minh đúng vai trò
Traceability	Giữ nguyên Artifact ID, filename, URL canonical	Không tạo ID hoặc đường dẫn biến thể
Stop condition	Không có mâu thuẫn nguồn hay suy diễn vượt authority	Dừng, ghi VERIFICATION_REQUIRED, không tạo requirement

Core

Bảng dưới là tập đầ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. Artifact ID và tên tệp giữ nguyên để truy vết; IN_REVIEW không phải baseline, phê duyệt, hay quyền dùng production.

Input ID	Loại nguồn	Artifact ID / tệp canonical	Giá trị mô phỏng dùng trong case	Owner nguồn	Freshness	Trạng thái xác minh
INP-NF-001	Controlled planning artifact	CHAPTER_MANIFEST /01-curriculum/CHAPTER_MANIFEST.md	Chapter 01, Status IN_REVIEW, Version v0.9.0	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07, Asia/Ho_Chi_Minh	Đã ghi nhận metadata
INP-NF-002	Controlled planning artifact	TRACEABILITY_ID_REGISTRY /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Quy tắc dùng ID canonical, không đổi chuỗi ID khi liên kết	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Đã ghi nhận metadata
INP-NF-003	Controlled planning artifact	CANONICAL_BUSINESS_RULES /01-curriculum/CANONICAL_BUSINESS_RULES.md	Catalog quy tắc nghiệp vụ ở trạng thái kế hoạch	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Chưa là quy tắc vận hành
INP-NF-004	Controlled planning artifact	CANONICAL_DATA_DICTIONARY /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Từ điển dữ liệu logic canonical cho ERP mô phỏng	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Cần xác minh thuộc tính case
INP-NF-005	Legal primary source	Luật 91/2025/QH15	Bối cảnh bảo vệ dữ liệu cá nhân tại Việt Nam	Legal Owner	URL truy cập 2026-08-07	Verification required: Legal Owner xác nhận yêu cầu hệ thống
INP-NF-006	Legal primary source	Nghị định 356/2025/NĐ-CP	Bối cảnh hướng dẫn bảo vệ dữ liệu cá nhân	Legal Owner	URL truy cập 2026-08-07	Verification required: hiệu lực áp dụng chi tiết
INP-NF-007	Legal primary source	Luật 88/2015/QH13	Bối cảnh kế toán, tiền tệ mô phỏng VND	Accounting Owner	URL truy cập 2026-08-07	Verification required: diễn giải kế toán
INP-NF-008	Legal primary source	Nghị định 123/2020/NĐ-CP	Bối cảnh hóa đơn, chứng từ	Accounting Owner, Legal Owner	URL truy cập 2026-08-07	Verification required: sửa đổi sau ngày nguồn
INP-NF-009	Legal primary source	Luật 55/2010/QH12	Bối cảnh truy xuất và thu hồi thực phẩm	Food Safety Owner, Legal Owner	URL truy cập 2026-08-07	Verification required: nghĩa vụ cụ thể
INP-NF-010	Professional standard	BABOK Guide Version 3	Thuật ngữ, nhiệm vụ, năng lực BA	Principal IT Business Analyst / Technical Curriculum Author	URL truy cập 2026-08-07	Không suy diễn trang hoặc điều khoản
INP-NF-011	Professional standard	ISO/IEC/IEEE 29148:2018	Bối cảnh kỹ nghệ yêu cầu	Requirements Owner	URL truy cập 2026-08-07	Cần licensed-text verification cho điều khoản
INP-NF-012	Security good practice	OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	Bối cảnh kiểm tra bảo mật ERP/API mô phỏng	Security Owner	URL truy cập 2026-08-07	Không phải luật Việt Nam

Applied

Facts: Nova Foods là case ERP mô phỏng; locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND; mọi giá trị nghiệp vụ chưa có nguồn canonical đều là dữ liệu tổng hợp.

Current Behavior: BA nhận bảng input trên trước khi viết nội dung. Mỗi dòng chỉ nói điều nguồn chứng minh được.

Underlying Need: Tránh biến tài liệu kế hoạch thành quy tắc ERP, kết luận pháp lý, hoặc phê duyệt giả.

Options: Dùng nguồn không kiểm soát; dùng nguồn canonical có nhãn xác minh; suy diễn từ thực hành phổ biến.

Decision Criteria: Giữ ID, filename, owner, ngày truy cập, ranh giới nguồn; phân biệt fact với Verification required.

Decision: Chỉ dùng option nguồn canonical có nhãn xác minh.

Authority: Legal Owner, Accounting Owner, Food Safety Owner, Security Owner xác nhận nội dung thuộc chuyên môn; Principal IT Business Analyst / Technical Curriculum Author duy trì truy vết.

Artifact: Bảng INP-NF-001 đến INP-NF-012 trong section này.

Consequence if Wrong: Rule sai có thể dẫn BA viết sai requirement, sai test basis, hoặc gán nghĩa vụ pháp lý không được xác minh.

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

flowchart TB
    A[Input source] --> B{Canonical ID, filename, owner, access date, and source boundary present?}
    B -- No --> C[Do not use as controlled input]
    B -- Yes --> D[Principal IT Business Analyst / Technical Curriculum Author maintains traceability]
    D --> E{Content needs subject-matter verification?}
    E -- No --> F[Use only within stated source boundary]
    E -- Yes --> G[Route to applicable authority:<br/>Legal, Accounting, Food Safety, or Security Owner]
    G --> H{Authority confirms content?}
    H -- Yes --> F
    H -- No or pending --> I[Label Verification required]
    I --> J[Use only as unverified statement;<br/>do not treat as confirmed rule or approval]

Senior Lens

Dòng INP-NF-005 đến INP-NF-009 không chứng minh Nova Foods phải cấu hình chức năng ERP cụ thể. Bằng chứng chỉ cho thấy có nguồn pháp lý cần đúng owner kiểm tra. Cầu nối suy luận: nguồn là văn bản chính thức, nhưng bản trích không chứa diễn giải hệ thống đã được thẩm quyền xác nhận; vì vậy kết luận phải giữ nhãn Verification required.

Quick Reference

Nhãn	Nghĩa dùng trong bảng
Đã ghi nhận metadata	Chỉ xác nhận metadata xuất hiện trong artifact nguồn
Chưa là quy tắc vận hành	Không được dùng như business rule thực tế
Verification required	Dừng suy diễn; chờ owner có thẩm quyền xác minh
Canonical	Nguồn tham chiếu chính thức trong corpus, không thay bằng bản sao

5. Step-by-step BA Activities

Core

BA biến input thành requirement có thể review và bàn giao có kiểm soát. Mỗi bước phải giữ cầu nối: fact từ nguồn nào, suy luận nào, ai có thẩm quyền quyết định. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu tổng hợp, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07.

Applied

1. Actor: BA. Action: Mở scope và nguồn đầu vào. Object: /02-handbook/01-ba-role-lifecycle-and-governance.md, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY. Evidence produced: danh sách input giữ nguyên Artifact ID, filename, Status, Version, ngày. Decision rule: chỉ dùng nguồn canonical có metadata; nguồn pháp lý chưa có xác nhận chuyên môn phải gắn Verification required. Quality gate: không có ID hoặc filename bị đổi. Escalation route: mâu thuẫn ID hoặc nguồn gửi Principal IT Business Analyst / Technical Curriculum Author.

2. Actor: BA. Action: Xác định vấn đề nghiệp vụ và ranh giới. Object: hành vi hiện tại, người dùng, dữ liệu, quy trình Nova Foods mô phỏng. Evidence produced: problem statement phân biệt fact, assumption, unknown. Decision rule: fact phải truy được artifact hoặc source seed; assumption không được viết thành rule bắt buộc. Quality gate: mỗi kết luận có evidence/reasoning bridge. Escalation route: vấn đề chạm kế toán gửi Accounting Owner; riêng tư gửi Legal Owner; an toàn thực phẩm gửi Food Safety Owner.

3. Actor: BA cùng Business Owner. Action: Làm rõ underlying need, tức nhu cầu gốc phía sau yêu cầu bề mặt. Object: outcome nghiệp vụ, ngoại lệ, tiêu chí thành công. Evidence produced: danh sách need và decision cần chủ thể có thẩm quyền quyết định. Decision rule: không chọn giải pháp ERP trước khi need rõ. Quality gate: need nêu được tác động nếu không xử lý. Escalation route: scope xung đột hoặc thiếu người quyết định gửi Business Owner.

4. Actor: BA. Action: Soạn requirement, business rule, dữ liệu và acceptance criteria, tức điều kiện chấp nhận có thể kiểm tra. Object: requirement draft và liên kết tới CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY khi có. Evidence produced: bản nháp truy vết từ input đến requirement. Decision rule: không tạo business rule Nova Foods mới khi chưa có authority xác nhận. Quality gate: requirement rõ actor, trigger, outcome, constraint, exception. Escalation route: tác động kiến trúc gửi Architect; bảo mật gửi Security Owner; khả năng kiểm thử gửi QA Reviewer.

5. Actor: BA và reviewer phù hợp. Action: Review tính đúng, đủ, nhất quán, khả thi và kiểm thử được. Object: requirement draft, nguồn truy vết, nhãn Verification required. Evidence produced: review record ghi nhận issue, owner, quyết định, căn cứ. Decision rule: issue thuộc thẩm quyền chuyên môn không được BA tự đóng. Quality gate: không còn mâu thuẫn với nguồn canonical; không có legal, accounting, privacy, food-safety claim chưa gắn nhãn xác minh. Escalation route: gửi owner chuyên môn tương ứng; Principal IT Business Analyst / Technical Curriculum Author chỉ giữ traceability.

6. Actor: BA. Action: Bàn giao có kiểm soát cho nhóm tiêu thụ output. Object: requirement đã review, decision record, traceability, open issue. Evidence produced: handoff package nêu phiên bản v0.9.0, Status IN_REVIEW, phạm vi, unresolved item và owner. Decision rule: chỉ bàn giao để review tiếp; IN_REVIEW không phải baseline, approval, production-ready hoặc xác nhận tuân thủ. Quality gate: người nhận thấy đủ nguồn, quyết định, nhãn xác minh và route xử lý issue. Escalation route: thiếu evidence hoặc sai trạng thái trả về BA để sửa traceability.

Facts: Corpus có Status IN_REVIEW; không có baseline reference hay approval reference.

Current Behavior: Input có thể chứa nguồn chính thức, planning artifact và nội dung mô phỏng với mức thẩm quyền khác nhau.

Underlying Need: BA phải giữ requirement học liệu truy được nguồn nhưng không biến assumption thành cam kết vận hành hay nghĩa vụ pháp lý.

Options: Dùng mọi input như rule; chỉ dùng nguồn canonical và gắn nhãn xác minh khi cần; tự kết luận thay owner chuyên môn.

Decision Criteria: Giữ source boundary, đúng thẩm quyền, đủ evidence, không tạo approval ngầm định.

Decision: Chỉ dùng nguồn canonical trong phạm vi an toàn; giữ Verification required cho nội dung cần Legal Owner, Accounting Owner, Food Safety Owner hoặc Security Owner xác minh.

Authority: Business Owner quyết định need và phạm vi nghiệp vụ; owner chuyên môn quyết định nội dung thuộc lĩnh vực; BA duy trì phân tích và traceability.

Artifact: Requirement draft, review record, handoff package trong /02-handbook/01-ba-role-lifecycle-and-governance.md.

Consequence if Wrong: Requirement sai nguồn hoặc sai thẩm quyền làm sai test basis, thiết kế, quyết định nghiệp vụ, hoặc diễn giải pháp lý.

Senior Lens

Review không phải bước tìm lỗi câu chữ. Review kiểm tra chuỗi bằng chứng. Fact “nguồn pháp lý tồn tại” không đủ để suy ra “ERP phải cấu hình chức năng X”. Cầu nối bị thiếu là diễn giải từ owner có thẩm quyền; vì vậy BA dừng tại Verification required.

Quick Reference

Kiểm tra	Đạt khi
Traceability	Mỗi requirement truy được input và reasoning
Authority	Quyết định thuộc đúng owner
Status	IN_REVIEW không bị gọi là approved hay baselined
Handoff	Gói bàn giao nêu rõ open issue và escalation route

Core

Hoạt động BA biến nhu cầu mơ hồ thành thông tin có thể kiểm tra. Mỗi bước phải có bằng chứng: vật ghi nhận được như nguồn, biên bản, danh sách câu hỏi hoặc log quyết định. Mỗi bước cũng cần quality gate (cổng chất lượng): điều kiện tối thiểu trước khi chuyển bước. Nếu điều kiện không đạt, BA không tự suy đoán; chuyển escalation tới vai trò có thẩm quyền.

Bước	Actor	Action và object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị	BA	Đọc phạm vi, trạng thái IN_REVIEW, version v0.9.0, nguồn canonical và giới hạn thẩm quyền của yêu cầu.	Danh sách nguồn, phạm vi, giả định, câu hỏi mở.	Chỉ dùng nguồn được phân loại; chi tiết pháp lý, kế toán, thuế, an toàn thực phẩm ghi Verification required nếu chưa xác minh.	Có nguồn cho từng nhận định; Nova Foods được ghi là mô phỏng, dữ liệu tổng hợp.	Principal IT Business Analyst / Technical Curriculum Author khi nguồn mâu thuẫn; Legal, Accounting, Compliance hoặc domain owner khi thuộc chuyên môn đó.
2. Thu thập	BA và business representative	Quan sát hoặc hỏi về quy trình, dữ liệu, ngoại lệ và kết quả mong muốn. Object là luồng nghiệp vụ hiện tại.	Ghi chép facts, câu hỏi, nguồn phát biểu, ví dụ dữ liệu tổng hợp.	Tách fact đã có bằng chứng khỏi ý kiến, giả định và đề xuất.	Mỗi fact nêu ai cung cấp, thời điểm theo Asia/Ho_Chi_Minh, phạm vi áp dụng.	Business Owner khi các bên mô tả khác nhau; process owner khi không xác định được luồng hiện tại.
3. Phân tích	BA	So sánh Current Behavior với Underlying Need, tức nhu cầu gốc tạo ra thay đổi. Object là khoảng cách giữa hiện trạng và kết quả cần đạt.	Problem statement, danh sách nguyên nhân, tác động, giả định.	Không biến giải pháp được đề xuất thành nhu cầu nếu chưa chứng minh quan hệ nguyên nhân-kết quả.	Mỗi suy luận nối fact, lập luận và kết luận; không có kết luận chỉ dựa vào một ý kiến.	Business Owner khi cần chọn mục tiêu; Architect khi nguyên nhân có thể thuộc tích hợp hoặc kiến trúc.
4. Đặc tả	BA	Viết requirement, business rule, dữ liệu, ngoại lệ và tiêu chí kiểm tra. Object là yêu cầu có thể kiểm thử.	Bản nháp requirement và liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc TRACEABILITY_ID_REGISTRY khi đã có mục phù hợp.	Không tạo ID, quy tắc canonical hoặc trường dữ liệu mới ngoài registry và catalog được kiểm soát.	Requirement có điều kiện, hành vi, kết quả, nguồn và owner quyết định.	Principal IT Business Analyst / Technical Curriculum Author khi ID hoặc nguồn canonical không rõ; Security, Legal, Accounting hoặc Architect theo loại yêu cầu.
5. Đánh giá lựa chọn	BA, Business Owner, Architect khi cần	So sánh Options theo giá trị nghiệp vụ, rủi ro, khả thi kỹ thuật, tác động dữ liệu và khả năng kiểm thử.	Bảng Options, Decision Criteria, trade-off và Decision record.	BA trình bày bằng chứng; vai trò có thẩm quyền chọn quyết định thuộc phạm vi họ.	Tiêu chí áp dụng nhất quán cho mọi option; hậu quả của option không chọn được ghi rõ.	Business Owner cho ưu tiên nghiệp vụ; Architect cho kiến trúc và tích hợp; Security cho kiểm soát bảo mật.
6. Review	BA và reviewer đúng thẩm quyền	Rà soát tính đúng nguồn, rõ nghĩa, nhất quán, truy vết và khả năng kiểm thử. Object là gói yêu cầu.	Review log gồm nhận xét, nguồn bị ảnh hưởng, quyết định xử lý và người chịu trách nhiệm.	Nhận xét không có bằng chứng phải được phân loại là câu hỏi, không tự chuyển thành requirement.	Không còn mâu thuẫn chưa phân loại; mọi Verification required còn mở được nhìn thấy.	Owner chuyên môn tương ứng khi review chạm pháp lý, kế toán, bảo mật, chất lượng hoặc vận hành.
7. Bàn giao có kiểm soát	BA	Chuyển gói đang IN_REVIEW cho consumer phù hợp, giữ nguyên version, nguồn và các điểm mở. Object là bản yêu cầu cùng evidence.	Danh mục bàn giao, traceability links, review log và danh sách rủi ro mở.	IN_REVIEW không được diễn giải là baseline, xác nhận tuân thủ hoặc cho phép production.	Consumer nhận đủ requirement, rule, data, giả định, quyết định và điểm cần xác minh.	Principal IT Business Analyst / Technical Curriculum Author khi thiếu traceability; Business Owner, Architect, QA hoặc owner chuyên môn khi thiếu quyết định thuộc thẩm quyền họ.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Facts: nhân viên kho mô phỏng nói đơn giao hàng có thể bị sửa sau khi đã chọn lô; Current Behavior: hệ thống giả định chưa chặn thao tác này; Underlying Need: bảo toàn liên kết đơn hàng–lô để truy vết khi có sự cố chất lượng. Options: chặn sửa lô sau xác nhận, hoặc cho sửa nhưng ghi log và yêu cầu quyền cao hơn. Decision Criteria: khả năng truy vết, tác động vận hành kho, rủi ro sửa sai, khả năng kiểm thử. Decision: chưa kết luận nghiệp vụ; BA ghi hai option và bằng chứng cần bổ sung. Authority: Business Owner quyết định luồng kho, Quality/Food-safety owner xác minh nhu cầu truy vết, Architect đánh giá log và phân quyền. Artifact: requirement draft, review log, liên kết nguồn trong /01-curriculum/CANONICAL_BUSINESS_RULES.md nếu có rule phù hợp. Consequence if Wrong: lô giao thực tế có thể không truy ngược được đúng dữ liệu, nhưng đây là rủi ro mô phỏng; yêu cầu pháp lý phải Verification required.

Senior Lens

Quality gate không phải thủ tục hình thức. Gate ngăn BA chuyển một nhận định chưa chứng minh thành cam kết thiết kế. Khi business representative yêu cầu “làm như hệ thống cũ”, BA cần hỏi mục tiêu, ngoại lệ, dữ liệu đầu vào và hậu quả lỗi; bằng chứng này cho biết cần giữ hành vi cũ hay chỉ giữ kết quả nghiệp vụ.

Escalation không phải chuyển trách nhiệm. BA chuẩn bị facts, lựa chọn và tác động để người có thẩm quyền quyết định nhanh. BA không tự kết luận nghĩa vụ pháp lý, hạch toán, kiến trúc, bảo mật hoặc an toàn thực phẩm vì bằng chứng nghiệp vụ không thay thế thẩm quyền chuyên môn.

Quick Reference

• Fact có nguồn; inference có cầu nối lập luận; decision có authority.
• Không qua quality gate thì giữ trạng thái mở, không suy đoán.
• Giữ IN_REVIEW, v0.9.0, ngày 2026-08-07 nguyên nghĩa kiểm soát.
• Nova Foods chỉ là mô phỏng; dữ liệu chỉ là tổng hợp.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp. Bảng biến hoạt động BA thành bằng chứng kiểm tra được. Mỗi quyết định dựa trên fact ghi nhận, không dựa trên suy đoán hay xác nhận ngầm.

Điểm thực thi	Facts và Current Behavior	Underlying Need	Options	Decision Criteria	Decision và Authority	Artifact, bằng chứng, Consequence if Wrong
Làm rõ lô hàng	Đơn bán SO-SIM-20260807-01 có 120 thùng nước ép; kho ghi nhận 100 thùng khả dụng, 20 thùng đang kiểm tra chất lượng. ERP mô phỏng chưa chỉ rõ có được hứa giao phần đang kiểm tra hay không.	Sales cần ngày giao tin cậy; Kho cần tránh cam kết hàng chưa đạt điều kiện xuất.	Giữ toàn bộ đơn chờ; hứa giao 100 thùng; hứa giao 120 thùng.	Chỉ chọn phương án có trạng thái tồn kho, người chịu trách nhiệm và điều kiện chuyển trạng thái được chứng minh.	BA ghi nhận phương án “hứa giao 100 thùng, 20 thùng chờ kết quả kiểm tra”. Business Owner quyết định chính sách giao một phần; QA Owner xác nhận điều kiện giải phóng hàng.	Cập nhật nháp trong /01-curriculum/CANONICAL_BUSINESS_RULES.md, liên kết CANONICAL_DATA_DICTIONARY. Sai sẽ tạo cam kết giao vượt tồn kho khả dụng hoặc xuất hàng chưa được QA giải phóng.
Kiểm tra dữ liệu	Fact: số lượng khả dụng và số lượng kiểm tra là hai trạng thái khác nhau. Suy luận: cùng một số lượng không thể vừa “có thể cấp phát” vừa “chờ QA” nếu không có quy tắc chuyển trạng thái.	Data model phải phân biệt tồn kho theo trạng thái.	Một trường tổng tồn; các trường số lượng theo trạng thái; bảng tồn kho theo lô và trạng thái.	Chọn mô hình truy vết được lô, trạng thái và thời điểm thay đổi; không biến suy luận BA thành cấu hình ERP.	BA đề xuất thuộc tính logic; Architect đánh giá mô hình; QA Owner xác nhận trạng thái kiểm tra.	Tham chiếu CANONICAL_DATA_DICTIONARY; evidence là bản ghi dữ liệu tổng hợp và sơ đồ trạng thái. Sai sẽ làm báo cáo tồn kho, cấp phát và kiểm thử dùng cùng một số nhưng hiểu khác nhau.
Kiểm tra giao diện và tích hợp	Current Behavior giả định: Sales nhìn tổng tồn, Kho xác nhận xuất theo tồn khả dụng. Không có evidence rằng API hay màn hình ERP thực tế tồn tại.	Cần nêu rõ điểm hiển thị và điểm kiểm soát trước khi viết requirement tích hợp.	Hiện tổng tồn; hiện tồn khả dụng và tồn chờ QA; ẩn tồn chờ QA.	Màn hình phải giúp người dùng tránh hứa sai; tích hợp chỉ mô tả sau khi Architect xác nhận ranh giới hệ thống.	BA chọn hiển thị riêng hai trạng thái trong prototype mô phỏng. Architect quyết định hợp đồng API; Security Owner review nếu API xử lý dữ liệu nhạy cảm.	Prototype mô phỏng và traceability trong TRACEABILITY_ID_REGISTRY. Sai sẽ khiến Sales hiểu “tồn vật lý” là “tồn có thể giao”.
Chuyển giao kiểm soát	Fact: IN_REVIEW, v0.9.0, ngày 2026-08-07; chưa có baseline hay approval reference.	Người nhận cần biết thứ gì là fact, assumption, quyết định chờ thẩm quyền.	Gửi ghi chú tự do; gửi gói review có trạng thái; đánh dấu đã phê duyệt.	Không dùng từ “đã phê duyệt” khi không có approval reference; giữ nguyên source boundary.	BA lập gói review; Business Owner, QA Owner, Architect xem xét phần thuộc thẩm quyền. Không vai trò nào được suy diễn approval từ việc nhận tài liệu.	Gói review tham chiếu /02-handbook/01-ba-role-lifecycle-and-governance.md, CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY. Sai sẽ biến giả định học liệu thành chỉ dẫn vận hành hoặc quyết định production.

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

stateDiagram-v2
    direction TB

    [*] --> Available: Nhập lô; QA phân loại khả dụng
    [*] --> QA_Hold: Nhập lô; chờ kiểm tra chất lượng

    Available --> Allocated: Sales yêu cầu cấp phát
    Allocated --> Released: Kho xác nhận đủ điều kiện xuất
    Released --> Shipped: Kho xác nhận xuất hàng
    Shipped --> [*]

    QA_Hold --> Available: QA Owner giải phóng lô
    QA_Hold --> Rejected: QA Owner từ chối lô
    Rejected --> [*]

    note right of QA_Hold
      Không cấp phát hoặc cam kết giao.
      Business Owner quyết định
      chính sách giao một phần.
      QA Owner xác nhận
      điều kiện giải phóng lô.
    end note

Sơ đồ là Mermaid state diagram, không phải BPMN. Nó chứng minh reasoning bridge: fact “20 thùng chờ QA” dẫn tới trạng thái QA_Hold; vì QA_Hold chưa có bằng chứng giải phóng, BA không mô tả 20 thùng là hàng có thể giao.

6. Output thu ???c

Core

Output là artifact, tức tệp hoặc bản ghi có cấu trúc để người sau kiểm tra được BA đã nhận gì, suy luận gì và cập nhật nguồn nào. 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, dùng vi-VN, Asia/Ho_Chi_Minh, VND.

Artifact tạo hoặc cập nhật	Canonical ID / tệp	Owner quản trị	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Gói truy vết đầu ra	TRACEABILITY_ID_REGISTRY / /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	ID nguồn, ID output, quan hệ truy vết, loại bằng chứng, điểm cần escalation	Thêm dòng nêu ngày 2026-08-07, v0.9.0, người ghi nhận, thay đổi, lý do, artifact bị ảnh hưởng
Catalog quy tắc cập nhật	CANONICAL_BUSINESS_RULES / /01-curriculum/CANONICAL_BUSINESS_RULES.md	Principal IT Business Analyst / Technical Curriculum Author quản trị; Business Owner xác nhận nội dung nghiệp vụ khi có thẩm quyền	IN_REVIEW	Quy tắc, điều kiện kích hoạt, ngoại lệ, nguồn hoặc nhãn giả định, owner quyết định	Không sửa im lặng quy tắc đã ghi; mỗi thay đổi phải giữ phiên bản cũ, lý do và liên kết truy vết
Từ điển dữ liệu cập nhật	CANONICAL_DATA_DICTIONARY / /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Principal IT Business Analyst / Technical Curriculum Author quản trị; Data Owner xác nhận nghĩa dữ liệu khi có thẩm quyền	IN_REVIEW	Tên dữ liệu, định nghĩa, kiểu logic, nguồn, trạng thái, ràng buộc, phân loại dữ liệu	Ghi trường thay đổi, tác động tới rule và consumer; không đổi nghĩa trường chỉ bằng đổi nhãn
Cập nhật cấu trúc chapter	CHAPTER_MANIFEST / /01-curriculum/CHAPTER_MANIFEST.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Đường dẫn chapter, section, dependency, trạng thái, version	Ghi thay đổi phạm vi hoặc dependency; không gọi là baseline khi chưa có baseline reference

Canonical ID là chuỗi định danh được registry kiểm soát. Lý do phải dùng đúng chuỗi: CANONICAL_BUSINESS_RULES khác CANONICAL_DATA_DICTIONARY; nhầm ID làm người review kiểm sai nguồn chân lý. Status IN_REVIEW chỉ nói artifact đang được xem xét có kiểm soát. Nó không chứng minh approval, baseline, tuân thủ, production readiness hoặc chấp thuận từ người dùng.

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

flowchart TB
    A["ID nguồn · ID output · quan hệ truy vết<br/>loại bằng chứng"] --> K{"ID, nguồn hoặc bằng chứng<br/>chưa xác định hay xung đột?"}
    K -->|"Có"| X["Ghi điểm cần escalation"]
    K -->|"Không"| R["Tạo hoặc cập nhật<br/>TRACEABILITY_ID_REGISTRY"]
    X --> R

    R --> RH["Ghi lịch sử: 2026-08-07 · v0.9.0<br/>người ghi nhận · thay đổi · lý do<br/>artifact bị ảnh hưởng"]
    R --> P["Đánh giá độc lập từng loại thay đổi"]

    P --> C{"Quy tắc hoặc ngoại lệ<br/>thay đổi?"}
    P --> DQ{"Định nghĩa, ràng buộc hoặc<br/>phân loại dữ liệu thay đổi?"}
    P --> MQ{"Phạm vi hoặc dependency<br/>chapter thay đổi?"}

    C -->|"Có"| B["Cập nhật<br/>CANONICAL_BUSINESS_RULES"]
    C -->|"Không"| BN["Không cập nhật<br/>CANONICAL_BUSINESS_RULES"]
    B --> BH["Giữ phiên bản cũ · ghi lý do<br/>và liên kết truy vết"]

    DQ -->|"Có"| D["Cập nhật<br/>CANONICAL_DATA_DICTIONARY"]
    DQ -->|"Không"| DN["Không cập nhật<br/>CANONICAL_DATA_DICTIONARY"]
    D --> DH["Ghi trường thay đổi · tác động tới rule và consumer<br/>Không đổi nghĩa trường chỉ bằng đổi nhãn"]

    MQ -->|"Có"| M["Cập nhật<br/>CHAPTER_MANIFEST"]
    MQ -->|"Không"| MN["Không cập nhật<br/>CHAPTER_MANIFEST"]
    M --> MH["Ghi thay đổi phạm vi hoặc dependency<br/>Không gọi baseline khi chưa có baseline reference"]

    RH --> T["Hoàn tất lịch sử registry và đánh giá<br/>rule · data · chapter"]
    BH --> T
    BN --> T
    DH --> T
    DN --> T
    MH --> T
    MN --> T

    T --> J["Tạo gói review downstream<br/>gồm registry và artifact áp dụng<br/>sau khi mọi nhánh Có hoặc Không được xử lý"]

    G["Principal IT Business Analyst /<br/>Technical Curriculum Author"] -. "Quản trị" .-> R
    G -. "Quản trị" .-> B
    G -. "Quản trị" .-> D
    G -. "Quản trị" .-> M
    BO["Business Owner"] -. "Xác nhận nội dung nghiệp vụ<br/>khi có thẩm quyền" .-> B
    DO["Data Owner"] -. "Xác nhận nghĩa dữ liệu<br/>khi có thẩm quyền" .-> D

    J --> S["Artifact cập nhật: IN_REVIEW"]
    S --> N["Không chứng minh approval · baseline · compliance<br/>production readiness · user acceptance"]

Applied

Facts: Nova Foods mô phỏng có 20 thùng thành phẩm đang chờ kiểm tra chất lượng; dữ liệu tổng hợp ghi trạng thái QA_Hold. Current Behavior: Sales có thể nhìn thấy số lượng tồn, nhưng chưa có bằng chứng lô được giải phóng để giao. Underlying Need: Phân biệt tồn vật lý với tồn có thể cam kết giao để tránh hứa giao sai.

Thành phần	Giá trị điền mẫu
Options	Ghi 20 thùng là tồn có thể giao; ẩn toàn bộ tồn; giữ QA_Hold riêng với tồn có thể giao
Decision Criteria	Không làm sai trạng thái lô; truy được nguồn; không tự tạo quyết định QA; người downstream hiểu giới hạn sử dụng
Decision	Cập nhật quy tắc mô phỏng: lô QA_Hold không được dùng làm cơ sở cam kết giao cho đến khi có bằng chứng giải phóng từ QA Owner
Authority	BA ghi nhận và truy vết; QA Owner có thẩm quyền chuyên môn với quyết định giải phóng lô; Business Owner xem xét tác động cam kết giao
Artifact	Cập nhật CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY; liên kết từ CHAPTER_MANIFEST
Consequence if Wrong	Sales có thể cam kết 20 thùng chưa đủ điều kiện xuất; kho, QA và khách hàng nhận thông tin mâu thuẫn

Reasoning bridge: fact là trạng thái QA_Hold; trạng thái này chưa phải bằng chứng giải phóng. Vì vậy output không đổi 20 thùng thành hàng sẵn giao. Đây là inference từ trạng thái dữ liệu, không phải kết luận về vận hành thực tế Nova Foods.

Senior Lens

Mỗi output phải có owner quản trị, nhưng owner quản trị không mặc nhiên là người có quyền quyết định nội dung. BA sở hữu tính hoàn chỉnh của traceability; QA Owner, Business Owner, Data Owner, Architect, Legal Owner hoặc Accounting Owner chỉ xác nhận phần thuộc thẩm quyền của họ khi có ghi nhận rõ ràng. Không dùng tên vai trò để suy diễn approval.

Quality gate cho downstream review: ID đúng registry; đường dẫn canonical đúng; status là IN_REVIEW; nội dung tối thiểu đủ; nguồn, fact, assumption và quyết định chờ thẩm quyền được tách rõ; lịch sử thay đổi có ngày 2026-08-07, version v0.9.0 và lý do. Qua gate nghĩa là đủ để review, không nghĩa là đã được phê duyệt hay sẵn sàng production.

Quick Reference

Kiểm tra	Đạt khi
ID	Dùng nguyên dạng TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, CHAPTER_MANIFEST
Tệp	Dùng đúng đường dẫn canonical đã đăng ký
Status	Ghi IN_REVIEW, không thay bằng APPROVED hoặc BASELINED
Lịch sử	Có version, ngày, người ghi nhận, lý do và tác động
Thẩm quyền	Không biến BA owner thành QA, pháp lý, kế toán hoặc production authority
Nova Foods	Gắn nhãn mô phỏng giáo dục, dữ liệu tổng hợp

Core

Output anatomy là cấu trúc đầy đủ của một artifact đầu ra: người đọc biết artifact nói gì, dựa vào đâu, thay đổi gì, và có thể dùng nó để review tiếp mà không tự suy diễn. Với 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.

Thành phần anatomy	Nội dung phải có	Ví dụ điền cho Nova Foods
Artifact ID	ID canonical, giữ nguyên khi cập nhật cùng artifact	NF-REQ-017
Tên artifact	Tên nghiệp vụ ngắn, mô tả đúng phạm vi	Yêu cầu duyệt chênh lệch giá mua
Loại artifact	Phân loại để người dùng chọn cách đọc	Business requirement
Phạm vi	Điểm bắt đầu, điểm kết thúc, đối tượng chịu tác động	Từ khi người mua nhập giá đơn mua đến khi chênh lệch được quyết định
Facts	Sự kiện quan sát được, không trộn kết luận	Giá đơn mua có thể cao hơn giá tham chiếu
Current Behavior	Hệ thống hoặc quy trình hiện tại đang làm gì	Người mua ghi chú thủ công ngoài ERP
Underlying Need	Nhu cầu gốc cần giải quyết	Ghi nhận quyết định nhất quán, có thể truy vết
Rule hoặc requirement	Điều hệ thống hoặc quy trình phải đáp ứng	Chênh lệch từ 5% trở lên phải tạo yêu cầu review
Dữ liệu liên quan	Trường dữ liệu, nguồn và ý nghĩa	purchase_order.unit_price, item.reference_price, variance_percent
Ngoại lệ	Trường hợp không áp dụng và lý do	Hàng mẫu giá 0 VND không tính tỷ lệ chênh lệch
Acceptance criteria	Điều kiện kiểm tra được	ERP tạo review khi variance_percent >= 5
Traceability	Liên kết bằng ID đến nguồn hoặc artifact liên quan	SRC-READY-010, CANONICAL_BUSINESS_RULES
Change history	Mỗi thay đổi có ngày, nội dung, lý do	2026-08-07 | v0.9.0 | Khởi tạo ví dụ mô phỏng

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

flowchart TB
    A[Người mua nhập đơn mua] --> B{Hàng mẫu giá 0 VND?}
    B -- Có --> C[Không tính variance_percent]
    C --> H[Tiếp tục xử lý đơn]
    B -- Không --> D[Tính variance_percent]
    D --> E{variance_percent >= 5<br/>ngưỡng giả định mô phỏng?}
    E -- Có --> F[Tạo yêu cầu review]
    F --> G[Ghi nhận quyết định review]
    G --> H
    E -- Không --> H

Sơ đồ là flowchart Mermaid, không phải BPMN. Điều kiện >= 5 là giả định dự án mô phỏng; chưa phải quy tắc vận hành Nova Foods, quyết định kế toán, hay yêu cầu pháp lý.

Applied

Mục	Nội dung đã điền
Facts	Đơn mua mô phỏng PO-NF-20260807-014 có mặt hàng RM-COCOA-001, số lượng 500 kg, giá đơn vị 82.000 VND/kg. Giá tham chiếu tổng hợp là 76.000 VND/kg.
Current Behavior	Người mua ghi lý do tăng giá trong email nội bộ. ERP không lưu tỷ lệ chênh lệch và không tạo điểm review. Evidence: quyết định nằm ngoài bản ghi đơn mua nên người review không có một nguồn kiểm tra tập trung.
Underlying Need	ERP cần hiển thị và lưu chênh lệch giá để reviewer đối chiếu số liệu gốc, lý do và quyết định. Reasoning: cùng một đơn mua phải chứa dữ liệu tính toán và dấu vết review, nếu không truy vết bị đứt giữa giá nhập và quyết định.
Options	1. Người mua tiếp tục ghi email. 2. ERP chỉ cảnh báo trên màn hình. 3. ERP tính chênh lệch, tạo yêu cầu review và lưu quyết định.
Decision Criteria	Khả năng truy vết theo ID đơn mua; giảm nhập tay; reviewer thấy giá nguồn; không tự động chặn đơn mua khi chưa có thẩm quyền quyết định.
Decision	Chọn option 3 cho case mô phỏng. variance_percent = (82.000 - 76.000) / 76.000 × 100 = 7,89%; vượt ngưỡng giả định 5%, nên tạo review.
Authority	Business Owner xác nhận ngưỡng nghiệp vụ; Purchasing Lead xác nhận quy trình mua; Architect xác nhận thiết kế ERP; QA xác nhận test basis. Các vai trò này chưa xác nhận nội dung ví dụ.
Artifact	NF-REQ-017 — Yêu cầu duyệt chênh lệch giá mua; liên kết CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Nếu công thức, ngưỡng, hoặc giá tham chiếu sai, reviewer có thể review sai đơn mua; dữ liệu quyết định không còn đáng tin để đối chiếu.

Bản ghi artifact đã điền

Trường	Giá trị
Artifact ID	NF-REQ-017
Artifact title	Yêu cầu duyệt chênh lệch giá mua
Case	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Requirement	ERP phải tính variance_percent khi người mua nhập purchase_order.unit_price và có item.reference_price. ERP phải tạo yêu cầu review khi variance_percent >= 5.
Calculation	(purchase_order.unit_price - item.reference_price) / item.reference_price × 100
Input example	purchase_order.unit_price = 82.000 VND/kg; item.reference_price = 76.000 VND/kg
Expected result	variance_percent = 7,89; tạo yêu cầu review gắn PO-NF-20260807-014
Exception	Nếu item.reference_price bằng 0 hoặc trống, ERP không tính tỷ lệ; ghi lỗi dữ liệu để xử lý theo quy trình dữ liệu.
Assumption	Ngưỡng 5% là giả định dự án. Verification required từ Business Owner trước khi dùng ngoài học liệu.
Source boundary	Không suy diễn nghĩa vụ thuế, kế toán, pháp lý, an toàn thực phẩm hoặc production từ ví dụ này.
Change history	2026-08-07 | v0.9.0 | Khởi tạo NF-REQ-017 cho corpus mô phỏng | Dữ liệu tổng hợp

Senior Lens

Output tốt không phải tài liệu dài. Output tốt giữ đủ bằng chứng để người review tái tạo logic: giá đơn mua 82.000 VND/kg, giá tham chiếu 76.000 VND/kg, công thức, kết quả 7,89%, ngưỡng giả định 5%, và hành động tạo review. Nếu chỉ viết “giá tăng cần duyệt”, người đọc không biết tăng so với giá nào, tính thế nào, hay khi nào kích hoạt.

Không biến giả định thành fact. 5% xuất hiện vì ví dụ cần ngưỡng kiểm thử; evidence không có nguồn Nova Foods xác nhận ngưỡng này. Vì vậy artifact phải gắn nhãn giả định và chỉ rõ vai trò xác minh. Đây là cầu nối reasoning: thiếu bằng chứng nghiệp vụ thì BA mô tả khoảng trống và người có thẩm quyền, không tự điền thành quy tắc canonical.

Quick Reference

Kiểm tra anatomy	Đạt khi
Có thể tính lại	Người review dùng input và công thức để ra 7,89%
Có thể truy vết	NF-REQ-017 liên kết đơn mua, dữ liệu và catalog canonical
Có thể phân biệt	Fact, giả định, requirement và ngoại lệ nằm ở trường riêng
Có thể review tiếp	Có decision criteria, authority cần xác minh, và consequence if wrong
Không vượt thẩm quyền	Không gọi ví dụ là approved, baselined, compliant hoặc production-ready

Core

Quality gate là tập kiểm tra tối thiểu trước khi output được chuyển sang downstream review, tức review bởi vai trò dùng output làm đầu vào kế tiếp. Gate xác nhận artifact đủ để đọc, truy vết và phản biện; không xác nhận nội dung đúng nghiệp vụ, không tạo APPROVED, BASELINED, compliant hoặc production-ready.

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

stateDiagram-v2
    direction TB
    [*] --> Draft
    Draft --> IN_REVIEW: đạt mọi kiểm tra bắt buộc
    Draft --> Draft: chưa đạt quality gate\nsửa thiếu hoặc mâu thuẫn
    IN_REVIEW --> Draft: reviewer trả lại
    note right of IN_REVIEW
        Chỉ chuyển sang downstream review
        Không tạo APPROVED, BASELINED,
        compliant hoặc production-ready
    end note

Kiểm tra gate	Bằng chứng bắt buộc	Kết quả đạt
Định danh	Artifact ID, đường dẫn canonical, version v0.9.0	Không nhầm nguồn kiểm soát
Trạng thái	Ghi IN_REVIEW, ngày 2026-08-07, Asia/Ho_Chi_Minh	Không diễn giải thành phê duyệt
Traceability	Liên kết ID nguồn, requirement, rule, data hoặc decision đang có	Reviewer kiểm tra được căn cứ
Tính đầy đủ	Mọi trường bắt buộc có giá trị, không có hàng thiếu	Không phải suy đoán dữ liệu
Tính nhất quán	Thuật ngữ, ID, locale vi-VN, tiền tệ VND khớp artifact nguồn	Không tạo xung đột corpus
Boundary	Nội dung pháp lý, kế toán, thuế, bảo mật chưa xác minh gắn Verification required hoặc project assumption	Không vượt thẩm quyền
Lịch sử thay đổi	Có dòng thay đổi nêu ngày, người ghi nhận, phạm vi thay đổi	Không sửa im lặng

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. Output CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md đang IN_REVIEW, v0.9.0, ngày 2026-08-07.

Current Behavior: BA soạn output rồi gửi review khi còn thiếu nguồn hoặc thiếu nhãn thẩm quyền. Reviewer phải đoán căn cứ, nên review biến thành truy tìm dữ liệu.

Underlying Need: Downstream reviewer cần artifact đủ kiểm tra mà không bị hiểu nhầm là quyết định vận hành ERP Nova Foods.

Mục	Giá trị đã điền
Options	Gửi ngay khi có nội dung; hoặc chỉ chuyển khi qua quality gate
Decision Criteria	Truy vết được, đủ trường, đúng canonical ID, giữ boundary thẩm quyền
Decision	Chỉ đổi trạng thái sang IN_REVIEW sau khi tất cả kiểm tra Core đạt
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì gate; Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA giữ thẩm quyền kết luận chuyên môn tương ứng
Artifact	CANONICAL_BUSINESS_RULES — /01-curriculum/CANONICAL_BUSINESS_RULES.md
Consequence if Wrong	Output thiếu căn cứ có thể dẫn reviewer suy diễn rule mô phỏng thành rule vận hành, pháp lý hoặc kế toán

Lý do chọn gate trước review: output thiếu ID hoặc nguồn không thể được đối chiếu; không đối chiếu được thì reviewer không thể phản biện có căn cứ. Gate chặn lỗi hình thức và traceability trước; reviewer vẫn kiểm tra nội dung sau đó.

Senior Lens

Không dùng quality gate để lách approval. Câu “đủ điều kiện downstream review” chỉ có nghĩa: artifact có thể được xem xét. Câu này không có nghĩa: stakeholder đã đồng ý, rule đã đúng, thiết kế đã khả thi, kiểm thử đã đạt, hoặc hệ thống được phép triển khai.

Nếu nguồn pháp lý Việt Nam ảnh hưởng output, gate phải kiểm tra nhãn Verification required trừ khi có xác minh hiện hành từ nguồn chính thức và kết luận thuộc đúng thẩm quyền. Evidence là nguồn seed phân biệt nguồn pháp lý với quyền diễn giải; suy ra BA chỉ bảo toàn traceability, không tự biến nguồn thành kết luận tuân thủ.

Quick Reference

Quy tắc	Áp dụng
Gate đạt	Chuyển IN_REVIEW; ghi lịch sử thay đổi
Gate không đạt	Giữ trạng thái soạn thảo; sửa thiếu sót trước khi gửi
Không có approval reference	Không dùng từ “đã phê duyệt”
Không có baseline reference	Không dùng từ “đã baseline”
Dữ liệu Nova Foods	Luôn ghi mô phỏng giáo dục, dữ liệu tổng hợp

7. Who consumes those outputs?

Core

Output BA không kết thúc khi được viết. Output trở thành đầu vào để vai trò khác hiểu cùng một vấn đề và tạo phần việc riêng. Với Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, dữ liệu tổng hợp, cùng một output có nhiều người dùng nhưng mỗi người đọc theo mục tiêu khác nhau.

Output BA	Người tiêu thụ	Cách dùng output
Business requirement, phạm vi và outcome mong muốn	PM/Product Owner, Business Owner	Ưu tiên phạm vi, ghép mục tiêu vào release, kiểm tra giá trị nghiệp vụ dự kiến
User story, use case và acceptance criteria (tiêu chí chấp nhận)	Developers, QA, PM/Product Owner	Developers xây hành vi; QA tạo test basis; PM/Product Owner theo dõi phạm vi
CANONICAL_BUSINESS_RULES	Developers, QA, Business Owner, specialist owners	Developers mã hóa rule; QA kiểm tra rule; Business Owner và chuyên gia đối chiếu ý nghĩa nghiệp vụ
CANONICAL_DATA_DICTIONARY	Developers, QA, Architect, Operations	Developers ánh xạ field; QA chuẩn bị dữ liệu test; Architect đánh giá dữ liệu và tích hợp; Operations hiểu dữ liệu vận hành
Process flow hoặc activity diagram	Developers, QA, Operations, specialist owners	Developers xác định luồng xử lý; QA xác định nhánh test; Operations xác định điểm bàn giao; chuyên gia kiểm tra bước nghiệp vụ
Integration requirement và API contract	Developers, Architect, QA, Operations	Developers xây client/server; Architect đánh giá ranh giới hệ thống; QA kiểm tra request/response; Operations chuẩn bị giám sát và xử lý lỗi
Traceability matrix (ma trận truy vết)	QA, PM/Product Owner, Business Owner	QA nối requirement với test; PM/Product Owner theo dõi coverage; Business Owner kiểm tra nhu cầu không bị mất
Non-functional requirement	Architect, Developers, QA, Operations	Architect chọn hướng kỹ thuật; Developers thực hiện; QA xác minh; Operations chuẩn bị vận hành

Applied

Facts: Nova Foods mô phỏng có yêu cầu ERP ghi nhận lô hàng nguyên liệu khi nhập kho. BA tạo process flow, user story, acceptance criteria, mục trong CANONICAL_BUSINESS_RULES, và field definition trong CANONICAL_DATA_DICTIONARY.

Current Behavior: Mỗi vai trò nhận cùng bộ output nhưng chỉ đọc phần liên quan công việc. Developers cần biết màn hình và validation. QA cần điều kiện đầu vào, hành vi kỳ vọng và kết quả kiểm tra. Architect cần biết dữ liệu lô có đi qua hệ thống khác hay không. Operations cần biết ai xử lý khi nhập lô lỗi.

Underlying Need: Một requirement chỉ tạo giá trị khi người xây, người kiểm tra và người vận hành dùng cùng nghĩa. Evidence là cùng Lot ID, cùng rule, cùng acceptance criteria; suy ra giảm nguy cơ Developers tạo một cách, QA kiểm tra cách khác.

Options: Dùng một tài liệu mô tả dài cho mọi vai trò; hoặc tách output theo mục đích nhưng liên kết bằng ID canonical. Nova Foods dùng lựa chọn thứ hai trong học liệu vì mỗi vai trò cần mức chi tiết khác nhau, nhưng traceability vẫn giữ được.

Decision Criteria: Output phải trả lời được câu hỏi công việc của consumer, giữ ID và thuật ngữ nhất quán, không biến giả định thành rule vận hành, và không diễn giải pháp lý hoặc kế toán ngoài thẩm quyền.

Decision: Process flow và requirement làm nguồn mô tả hành vi; CANONICAL_BUSINESS_RULES làm nguồn tham chiếu rule; CANONICAL_DATA_DICTIONARY làm nguồn tham chiếu field logic; traceability matrix nối các output này với kiểm thử.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner giữ thẩm quyền nghĩa nghiệp vụ. Architect giữ thẩm quyền kiến trúc. QA giữ thẩm quyền đánh giá kiểm thử. Operations và specialist owners giữ thẩm quyền về khả năng vận hành và chuyên môn tương ứng.

Artifact: /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, và /01-curriculum/TRACEABILITY_ID_REGISTRY.md ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Nếu QA dùng field name khác Developers, test có thể đạt trên dữ liệu không đúng. Nếu Operations không nhận biết điểm lỗi tích hợp, sự cố mô phỏng có thể không có người xử lý rõ. Không kết luận đây là cấu hình hay quy trình ERP thực tế.

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

flowchart TD
    PF["Process flow"]
    REQ["Requirement và acceptance criteria"]
    RULE["CANONICAL_BUSINESS_RULES"]
    DATA["CANONICAL_DATA_DICTIONARY"]
    TRACE["Traceability matrix"]

    RULE -->|"Tham chiếu rule"| REQ
    DATA -->|"Tham chiếu field logic"| REQ
    PF -->|"Nguồn hành vi"| LINK
    REQ -->|"Nguồn hành vi"| LINK
    RULE -->|"ID canonical"| LINK
    DATA -->|"ID canonical"| LINK
    TRACE -->|"Liên kết output với kiểm thử"| LINK

    LINK{"ID và thuật ngữ nhất quán?"}
    LINK -->|"Không"| FIX["BA sửa liên kết hoặc metadata"]
    FIX --> LINK

    LINK -->|"Có"| DEVOUT["Hành vi, màn hình và validation"]
    LINK -->|"Có"| QAOUT["Đầu vào, hành vi kỳ vọng và kết quả kiểm tra"]
    LINK -->|"Có"| ARCHOUT["Luồng dữ liệu lô qua hệ thống khác"]
    LINK -->|"Có"| BOOUT["Nghĩa nghiệp vụ"]
    LINK -->|"Có"| OPSOUT["Owner và escalation khi nhập lô lỗi"]
    LINK -->|"Có"| SPECOUT["Nội dung chuyên môn"]

    DEVOUT --> DEV["Developers xây hành vi"]
    QAOUT --> QA["QA đánh giá kiểm thử"]
    ARCHOUT --> ARCH["Architect quyết định kiến trúc"]
    BOOUT --> BO["Business Owner quyết định nghĩa nghiệp vụ"]
    OPSOUT --> OPS["Operations quyết định khả năng vận hành"]
    SPECOUT --> SPEC["Specialist owners quyết định chuyên môn"]

    BA["BA duy trì liên kết và metadata"] --> LINK
    TRACE -->|"Căn cứ kiểm thử"| QAOUT

Senior Lens

Không gửi “tài liệu BA” như một khối không phân loại. Gửi hoặc liên kết đúng output cho đúng consumer. Developers không nên suy ra rule từ sơ đồ màn hình. QA không nên suy ra expected result từ lời kể miệng. Architect không nên phải đoán field ownership từ user story.

Consumer không phải người phê duyệt mặc định. Việc Developers đọc CANONICAL_BUSINESS_RULES không trao quyền đổi rule. Việc Operations đọc flow không xác nhận flow đã sẵn sàng vận hành. Trạng thái IN_REVIEW cho biết artifact còn được xem xét, không phải BASELINED, APPROVED hay production-ready.

Quick Reference

Vai trò	Output ưu tiên	Mục tiêu sử dụng
Developers	User story, acceptance criteria, rule, data dictionary, API contract	Xây đúng hành vi và dữ liệu
QA	Acceptance criteria, rule, process flow, traceability	Tạo và đánh giá kiểm thử
Architect	Data dictionary, integration requirement, non-functional requirement	Đánh giá ranh giới kỹ thuật
PM/Product Owner	Business requirement, scope, traceability	Ưu tiên và kiểm soát phạm vi
Business Owner	Business requirement, rule, process flow	Kiểm tra ý nghĩa và giá trị nghiệp vụ
Operations	Process flow, exception flow, integration requirement	Chuẩn bị vận hành và xử lý sự cố
Specialist owners	Rule, data definition, flow thuộc chuyên môn	Kiểm tra nội dung chuyên ngành

Core

Người nhận đầu ra BA không tự động có quyền quyết định mọi phần. Họ dùng bằng chứng để quyết định trong phạm vi vai trò; phần vượt phạm vi phải chuyển cấp. Bằng chứng là liên kết kiểm tra được giữa yêu cầu, quy tắc, dữ liệu, rủi ro và nguồn canonical. Với Nova Foods Trading & Manufacturing mô phỏng, mọi dữ liệu là tổng hợp; IN_REVIEW tại v0.9.0 không phải 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 ràng buộc kiến trúc đã có; ước lượng kỹ thuật; lỗi khả thi	Requirement rõ, acceptance criteria, tham chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, API hoặc giao diện liên quan	Rule mơ hồ; dữ liệu thiếu nguồn; yêu cầu đổi hành vi nghiệp vụ; lộ dữ liệu cá nhân hoặc bí mật
QA	Test basis, kỹ thuật kiểm thử, mức bao phủ rủi ro, defect severity theo quy ước dự án	Acceptance criteria, rule, luồng, dữ liệu kiểm thử tổng hợp, traceability	Không có kết quả mong đợi kiểm tra được; conflict giữa rule và requirement; lỗi có thể làm sai sổ sách, truy xuất hoặc dữ liệu cá nhân
Architect	Tương thích kiến trúc, tích hợp, bảo mật kỹ thuật, phi chức năng	Sơ đồ luồng/dữ liệu, interface contract, tải dự kiến, phân loại dữ liệu, ràng buộc hệ thống	Đổi kiến trúc; mở kết nối mới; rủi ro OWASP; xung đột nguồn dữ liệu canonical
PM/Product Owner	Ưu tiên, phạm vi release, trade-off thời gian/chi phí trong quyền hạn	Giá trị nghiệp vụ, dependency, ước lượng, rủi ro, impact traceability	Đổi mục tiêu kinh doanh; vượt ngân sách/thời hạn được giao; cần chấp nhận rủi ro cấp doanh nghiệp
Business Owner	Ý nghĩa nghiệp vụ, quy tắc vận hành, acceptance nghiệp vụ	Quy trình hiện tại, quyết định chính sách, ví dụ dữ liệu tổng hợp, tác động KPI	Quy tắc chạm pháp luật, kế toán, thuế, an toàn thực phẩm hoặc quyền khách hàng
Operations	Tính vận hành được, quyền xử lý ngoại lệ, hỗ trợ và khôi phục	Runbook, luồng ngoại lệ, phân quyền, SLA dự kiến, tác động ca vận hành	Không có owner xử lý; gián đoạn vận hành; cần quyền production hoặc thay đổi quy trình thực
Specialist owner	Diễn giải chuyên môn thuộc lĩnh vực: Legal, Accounting, Security, Food Safety	Nguồn chính thức hiện hành, hồ sơ tình huống, phạm vi áp dụng	Thiếu nguồn chính thức; nguồn mâu thuẫn; kết luận bị dùng như nghĩa vụ pháp lý hoặc production

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

flowchart TB
  BA[BA gói bằng chứng] --> C[Người nhận xem xét]
  C --> D{Người nhận có thẩm quyền?}

  D -->|Có| V{Bằng chứng đủ và nhất quán?}
  D -->|Không| E[Chuyển đến owner có thẩm quyền tương ứng]
  E --> O[Owner có thẩm quyền xem xét]
  O --> V

  V -->|Có| R[Owner có thẩm quyền ra quyết định có truy vết]
  V -->|Không| K{Xung đột nguồn canonical?}

  K -->|Có| X[Chuyển đến owner nguồn canonical xử lý xung đột]
  X --> V
  K -->|Không| N[Không thể ra quyết định; trạng thái bị chặn]

Applied

Facts: Nova Foods mô phỏng có yêu cầu hiển thị lịch sử lô hàng cho nhân viên kho. CANONICAL_DATA_DICTIONARY là nguồn canonical của định nghĩa dữ liệu, nhưng chưa có baseline. Dữ liệu lô hàng là tổng hợp.

Current Behavior: Developer hiểu “lịch sử lô hàng” là toàn bộ thay đổi trạng thái. QA hiểu là chỉ các lần xuất kho. Hai cách hiểu tạo hai kết quả kiểm thử khác nhau.

Underlying Need: Xác định tập sự kiện phải hiển thị, ai được xem, và kết quả đúng để kiểm thử.

Options: Hiển thị mọi thay đổi; chỉ hiển thị sự kiện xuất kho; hiển thị tập sự kiện do Business Owner xác định.

Decision Criteria: Quyết định phải có owner nghiệp vụ; khớp định nghĩa dữ liệu canonical; kiểm thử được; không suy diễn nghĩa vụ truy xuất hay pháp lý từ học liệu.

Decision: BA không chọn thay Business Owner. BA ghi nhận hai diễn giải, bằng chứng thiếu, và chuyển câu hỏi quyết định.

Authority: Business Owner quyết định ý nghĩa nghiệp vụ. Architect xác nhận tác động truy cập dữ liệu. QA xác nhận acceptance criteria kiểm thử được. Nếu yêu cầu được diễn giải là nghĩa vụ truy xuất thực phẩm, chuyển Food Safety owner và Legal owner để xác minh.

Artifact: Cập nhật liên kết truy vết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và gói câu hỏi; giữ trạng thái IN_REVIEW, phiên bản v0.9.0.

Consequence if Wrong: Developer xây sai màn hình; QA kiểm thử sai test basis; Operations nhận luồng không xử lý được; quyết định mô phỏng có thể bị hiểu nhầm là quy định vận hành.

Senior Lens

Escalation không phải né quyết định. Nó là kiểm soát ranh giới: người quyết định phải chịu trách nhiệm đúng loại quyết định. BA phải chuyển kèm bằng chứng, phương án, tác động và câu hỏi cụ thể; không chuyển một câu “cần làm rõ” không có ngữ cảnh. Khi CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY mâu thuẫn, không chọn tài liệu thuận tiện hơn; ghi nhận xung đột và chuyển owner của nguồn canonical.

Quick Reference

Hiểu nhầm handoff	Câu hỏi làm rõ chính xác
“Developer tự chọn rule hợp lý.”	“Business Owner xác nhận sự kiện nào thuộc ‘lịch sử lô hàng’, và kết quả hiển thị mong đợi cho từng sự kiện là gì?”
“QA tự suy ra expected result.”	“Acceptance criteria nào xác định kết quả pass/fail cho trường hợp này?”
“Architect phê duyệt nghiệp vụ.”	“Đây là quyết định kiến trúc hay quyết định chính sách nghiệp vụ; owner nào có thẩm quyền ghi nhận?”
“Operations có thể tự sửa ngoại lệ.”	“Operations được phép xử lý ngoại lệ nào, trong thời hạn nào, và khi nào phải chuyển Business Owner?”
“Nguồn pháp lý đã đủ rõ.”	“Yêu cầu này dựa trên nguồn chính thức nào, phạm vi áp dụng nào, và Legal hoặc specialist owner nào xác minh?”

Core

Handoff là chuyển giao đầu ra BA kèm ngữ cảnh quyết định, không phải chỉ gửi liên kết tệp. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, hiểu nhầm thường xuất hiện khi người nhận suy diễn ý nghĩa ngoài artifact. Vì /02-handbook/01-ba-role-lifecycle-and-governance.md đang IN_REVIEW, v0.9.0, ngày 2026-08-07, không nội dung nào được hiểu là baseline, phê duyệt, cấu hình ERP hay chỉ dẫn production.

Hiểu nhầm khi bàn giao	Rủi ro suy diễn	Câu hỏi làm rõ chính xác
“Màn hình đã mô tả” bị hiểu là mọi trường đều bắt buộc	Developer tự đặt validation	“Trường nào bắt buộc tại thời điểm lưu, trường nào chỉ bắt buộc trước khi gửi duyệt, và evidence nào xác nhận từng điều kiện?”
Acceptance criteria bị hiểu là toàn bộ quy tắc nghiệp vụ	QA bỏ sót ngoại lệ hoặc test điều không được yêu cầu	“Acceptance criteria này kiểm chứng hành vi nào; quy tắc nguồn nào giới hạn phạm vi; ngoại lệ nào chưa được xác định?”
Tên dữ liệu giống nhau bị hiểu là cùng định nghĩa	Integration map sai khóa hoặc sai đơn vị	“Supplier ID ở hai hệ thống có cùng chủ sở hữu, định dạng, tính duy nhất và vòng đời không?”
“Theo quy định” bị hiểu là yêu cầu pháp lý đã xác minh	Nhóm kỹ thuật triển khai nghĩa vụ chưa đủ căn cứ	“Đây là project assumption hay requirement đã được Legal Owner xác minh theo nguồn chính thức nào?”
“Real-time” bị hiểu là đồng bộ tức thời	Architect chọn kiến trúc quá mức cần thiết	“Độ trễ tối đa chấp nhận được là bao nhiêu phút, từ sự kiện nào đến thời điểm nào, và ai chịu tác động khi trễ?”
Lỗi “không được mất dữ liệu” bị hiểu là cách xử lý cụ thể	Developer tự chọn retry, rollback hoặc queue	“Dữ liệu nào không được mất, điểm ghi nhận thành công là đâu, và ai quyết định xử lý khi hệ thống đích không phản hồi?”

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

flowchart TB
    A[BA bàn giao artifact kèm ngữ cảnh quyết định] --> B{Có evidence xác nhận cùng phạm vi?}
    B -- Có --> C[Ghi nhận evidence, nguồn xác minh và traceability trong artifact]
    B -- Không hoặc còn suy diễn --> D[Đặt câu hỏi làm rõ chính xác]
    D --> E[Ghi nhận câu trả lời và nguồn xác minh]
    E --> F{Câu trả lời đúng thẩm quyền và làm rõ phạm vi?}
    F -- Có --> C
    F -- Không --> G[Chuyển câu hỏi đến owner chuyên môn]
    G --> H{Owner chuyên môn đã xác minh và làm rõ?}
    H -- Có --> C
    H -- Chưa --> I[Ghi assumption hoặc unresolved trong artifact]
    I --> J[Chờ owner cung cấp evidence]
    J --> H
    C --> K[Tiếp nhận artifact ở trạng thái IN_REVIEW]
    K --> L[Chỉ dùng cho review; không phải baseline, phê duyệt, cấu hình ERP hay chỉ dẫn production]

Applied

Facts: Case Nova Foods mô phỏng có yêu cầu nhập phiếu nhận nguyên liệu. Artifact dùng thuật ngữ “chặn nhận nếu lô hết hạn”. Không nêu mốc thời gian, múi giờ, cách tính hạn hay quyền ngoại lệ.

Current Behavior: Developer có thể tự so sánh ngày hết hạn với ngày máy chủ. QA có thể test một ngày dương lịch. Hai cách đều có thể khác ý nghĩa nghiệp vụ khi lô hết hạn trong ngày.

Underlying Need: Xác định điều kiện chặn có thể kiểm thử, không tự suy diễn quy tắc an toàn thực phẩm. Evidence thiếu gồm định nghĩa ngày hiệu lực, nguồn dữ liệu hạn dùng, vai trò được phép ngoại lệ, và thẩm quyền xác nhận.

Options: (1) Developer tự chọn so sánh ngày. (2) BA ghi project assumption. (3) Escalate specialist owner để xác nhận quy tắc và ghi kết quả vào artifact kiểm soát.

Decision Criteria: Chọn phương án chỉ khi có evidence về nguồn hạn dùng, thời điểm đánh giá theo Asia/Ho_Chi_Minh, tác động vận hành, và thẩm quyền domain-owner. Nếu liên quan nghĩa vụ pháp lý hoặc an toàn thực phẩm, cần Legal Owner và domain owner xác minh; handbook không thay thế thẩm quyền này.

Decision: Chọn phương án (3). Không tạo rule mới trong handoff.

Authority: Specialist owner chịu trách nhiệm kết luận nghiệp vụ; Legal Owner xác minh diễn giải pháp lý nếu được nêu; BA giữ câu hỏi, evidence và traceability. Không vai trò nào được suy ra là đã phê duyệt.

Artifact: Ghi câu hỏi vào artifact đang kiểm soát, liên kết CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi các artifact này có nội dung phù hợp. Giữ trạng thái IN_REVIEW, v0.9.0.

Consequence if Wrong: Lô hợp lệ có thể bị chặn, lô không phù hợp có thể được nhận, test không phản ánh nhu cầu vận hành, và traceability không chứng minh căn cứ quyết định.

Senior Lens

Không hỏi “Anh/chị xác nhận giúp”. Câu này không khóa đối tượng, điều kiện, evidence hay thẩm quyền. Hỏi theo cấu trúc: đối tượng nào, điều kiện nào, nguồn nào, quyết định của ai, và hậu quả nếu chọn sai.

Tín hiệu cần escalation	Không tự giải quyết vì	Câu hỏi escalation
Mâu thuẫn giữa quy tắc và acceptance criteria	Có thể là thay đổi phạm vi hoặc sai traceability	“CANONICAL_BUSINESS_RULES và acceptance criteria mô tả hai kết quả khác nhau cho cùng điều kiện. Artifact nào là nguồn canonical, và cần cập nhật artifact nào?”
Quy tắc tác động kế toán, thuế, pháp lý, dữ liệu cá nhân, an toàn thực phẩm	BA và kỹ thuật không có thẩm quyền chuyên môn thay thế	“Quy tắc này là project assumption hay đã được owner có thẩm quyền xác minh? Vui lòng nêu evidence và phạm vi áp dụng.”
Interface thiếu mã lỗi, retry hoặc ownership dữ liệu	Quyết định ảnh hưởng kiến trúc, mất dữ liệu, bảo mật	“Khi hệ thống đích trả lỗi hoặc hết thời gian chờ, hệ thống nguồn phải ghi trạng thái nào, ai sở hữu khôi phục, và tiêu chí không mất dữ liệu là gì?”

Quick Reference

• Không suy diễn từ nhãn ngắn như “real-time”, “bắt buộc”, “theo quy định”, “đồng bộ”.
• Không đổi source classification, ID, filename hay trạng thái artifact trong lúc làm rõ.
• Câu trả lời không có evidence hoặc đúng authority: ghi là chưa xác định và escalate.
• Nova Foods là mô phỏng giáo dục; mọi dữ liệu là tổng hợp; không dùng ví dụ làm quyết định production.

8. Detailed Worked Example

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Tình huống: nhân viên bán hàng cần biết hàng có thể giao trước khi xác nhận đơn bán, nhưng ERP hiện chưa giữ chỗ tồn kho theo đơn.

Trường	Giá trị
Scenario ID	SCN-NF-ERP-008-01
Quy trình	Kiểm tra tồn kho khi tạo Sales Order
Kho áp dụng	WH-HCM-01 — Kho thành phẩm Hồ Chí Minh
Sản phẩm	FG-CHILI-500G — Tương ớt 500 g
Đơn vị tính	BOT
Ngày giao khách yêu cầu	2026-08-10
Khách hàng mô phỏng	CUS-MINH-001 — Siêu thị Minh An
Đơn bán mô phỏng	SO-20260807-0042
Số lượng khách yêu cầu	1,200 BOT
Giá bán dự kiến	18.000 VND/BOT
Giá trị đơn dự kiến	21.600.000 VND

Facts — sự kiện quan sát được. Tại 2026-08-07 09:15:00 theo Asia/Ho_Chi_Minh, báo cáo tồn kho của WH-HCM-01 hiển thị 1,500 BOT cho FG-CHILI-500G. Cùng thời điểm, đơn SO-20260807-0038 của khách khác đã được nhân viên tạo trước đó, yêu cầu 900 BOT, trạng thái màn hình là Draft. Hệ thống hiện không có trường ReservedQuantity và không có bản ghi phân bổ kho theo Sales Order. Evidence là kết quả truy vấn mô phỏng EV-SCN-NF-ERP-008-01-01.

Evidence ID	Nguồn dữ liệu mô phỏng	Thời điểm	Giá trị
EV-SCN-NF-ERP-008-01-01	Báo cáo Inventory On Hand	2026-08-07 09:15:00	OnHandQuantity = 1,500 BOT
EV-SCN-NF-ERP-008-01-02	Sales Order SO-20260807-0038	2026-08-07 09:12:00	OrderedQuantity = 900 BOT; trạng thái Draft
EV-SCN-NF-ERP-008-01-03	Sales Order SO-20260807-0042	2026-08-07 09:15:00	RequestedQuantity = 1,200 BOT; trạng thái Draft

Current Behavior — hành vi hiện tại. Màn hình tạo đơn chỉ so sánh số lượng khách yêu cầu với OnHandQuantity. Công thức hiện tại là AvailableToPromise = OnHandQuantity; hệ thống không trừ số lượng đã xuất, đã phân bổ, đang kiểm đếm, bị khóa chất lượng hoặc đã được đơn khác yêu cầu. Vì 1,200 BOT <= 1,500 BOT, hệ thống hiển thị “đủ hàng” cho SO-20260807-0042.

Cầu nối suy luận: evidence EV-SCN-NF-ERP-008-01-02 chứng minh đã có nhu cầu 900 BOT từ đơn trước; evidence EV-SCN-NF-ERP-008-01-01 chỉ phản ánh tồn thực tế 1,500 BOT; công thức hiện tại không dùng nhu cầu 900 BOT. Do đó cùng một lượng tồn có thể được hứa giao cho tổng 2,100 BOT, vượt 600 BOT so với tồn hiển thị. Đây là kết luận từ dữ liệu mô phỏng, chưa phải quy tắc nghiệp vụ được phê duyệt.

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

flowchart TB
    A[SO-20260807-0042: yêu cầu 1.200 BOT] --> B[ERP đọc OnHandQuantity = 1.500 BOT]
    B --> C[AvailableToPromise = OnHandQuantity = 1.500 BOT]
    C --> D{1.200 BOT <= 1.500 BOT?}
    D -->|Có, case mô phỏng| E[Hiển thị AVAILABLE / đủ hàng]
    D -->|Không| F[Hiển thị không đủ hàng]
    G[SO-20260807-0038: yêu cầu 900 BOT, Draft] -. Không được trừ khỏi AvailableToPromise .-> C
    H[Không có ReservedQuantity hoặc phân bổ kho] -. Giới hạn dữ liệu đầu vào .-> C
    A --> I[Tổng lượng yêu cầu hai đơn = 2.100 BOT]
    G --> I
    I --> J[Nguy cơ hứa vượt tồn hiển thị: 600 BOT]

Payload mô phỏng mà màn hình hiện nhận được:

{
  "warehouseId": "WH-HCM-01",
  "productId": "FG-CHILI-500G",
  "onHandQuantity": 1500,
  "uom": "BOT",
  "requestedQuantity": 1200,
  "availableToPromise": 1500,
  "availabilityResult": "AVAILABLE"
}

Payload trên không chứa reservedQuantity, allocatedQuantity, qualityHoldQuantity hoặc danh sách đơn cạnh tranh. Vì thiếu các dữ liệu này, kết quả AVAILABLE chỉ có nghĩa “số lượng yêu cầu không vượt tồn hiển thị”; không có nghĩa “Nova Foods có thể cam kết giao hàng”.

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing là case học liệu mô phỏng; mọi dữ liệu dưới đây là dữ liệu tổng hợp, dùng locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Tình huống: nhân viên kho xác nhận xuất lô hàng nhưng có thể chọn lô nguyên liệu thành phẩm bằng ghi chú tự do, làm truy vết lô giao khách hàng không tin cậy.

Bước	Nội dung thực hiện	Bằng chứng hoặc cầu nối suy luận
Facts	Đơn bán SO-NF-20260807-001 yêu cầu giao 120 thùng sữa hạt Oat Plus 1L cho khách hàng mô phỏng CUS-NF-001. Kho Bình Tân có hai lô khả dụng: LOT-OP1L-20260720-A còn 80 thùng, hết hạn 2027-01-20; LOT-OP1L-20260725-B còn 100 thùng, hết hạn 2027-01-25. Phiếu xuất DN-NF-20260807-001 được tạo ngày 2026-08-07.	Số lượng đơn 120 lớn hơn tồn lô A 80. Kho phải lấy từ ít nhất hai lô hoặc đơn không thể giao đủ.
Current Behavior	Nhân viên kho nhập tổng số lượng 120 vào phiếu xuất, rồi ghi “A 80, B 40” trong trường deliveryNote. ERP giảm tồn tổng SKU từ 180 xuống 60, không lưu liên kết dòng xuất với từng lô.	Trường ghi chú là văn bản tự do. Hệ thống không thể tính lại số lượng theo lô, không thể chặn xuất vượt tồn lô, không thể truy vấn chính xác khách nhận lô nào.
Underlying Need	Cần liên kết từng dòng xuất với lotId và quantity, kiểm tra tồn từng lô trước khi xác nhận, lưu dấu vết phục vụ tra soát và thu hồi. “Underlying Need” là nhu cầu gốc, không phải giải pháp giao diện.	Sai lệch nằm ở thiếu dữ liệu cấu trúc và kiểm soát trước khi ghi nhận xuất; thêm hướng dẫn nhập ghi chú không sửa được thiếu hụt này. Bối cảnh truy vết thực phẩm cần Legal Owner và Food Safety Owner xác minh trước production.
Options	O1: giữ ghi chú tự do, bổ sung mẫu câu chuẩn. O2: thêm hai trường văn bản lot1, lot2. O3: tạo dòng phân bổ lô có cấu trúc, kiểm tra tồn và tổng lượng trước xác nhận.	O1 không máy-đọc được. O2 cố định số lô, không xử lý đơn dùng ba lô. O3 mô hình hóa quan hệ một dòng xuất có nhiều lô.
Decision Criteria	C1: truy vấn được khách hàng theo lotId; C2: chặn tổng xuất theo lô vượt tồn; C3: hỗ trợ từ một đến nhiều lô; C4: không cho xác nhận khi tổng phân bổ khác lượng yêu cầu; C5: giữ nguyên số đơn và phiếu xuất hiện có.	C1-C4 đo trực tiếp nhu cầu gốc. C5 giới hạn thay đổi, tránh tạo tài liệu giao nhận song song.
Decision	Khuyến nghị BA: chọn O3. Thêm dữ liệu phân bổ lô dưới mỗi dòng xuất; không dùng ghi chú làm nguồn sự thật cho lô xuất. Đây là recommendation, chưa là quyết định được ủy quyền.	O3 đạt C1-C5. O1 trượt C1-C4. O2 trượt C3 và tăng rủi ro cấu trúc cứng.
Authority	Business Owner quyết định ưu tiên nghiệp vụ và chấp nhận thay đổi quy trình. Solution Architect xác nhận mô hình dữ liệu và tích hợp. Food Safety Owner cùng Legal Owner xác minh nghĩa vụ truy vết. QA Owner xác nhận test basis. Không có approval, baseline, hoặc production authorization tại IN_REVIEW, v0.9.0.	Quyết định có ảnh hưởng vận hành, dữ liệu và khả năng diễn giải pháp lý; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì phân tích và traceability.
Artifact	BA ghi nhận requirement, rule, payload mẫu, tiêu chí chấp nhận và traceability trong artifact kiểm soát tương ứng của corpus. Nguồn quản trị: TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY; tất cả đang IN_REVIEW, v0.9.0.	Tách artifact phân tích khỏi quyết định thẩm quyền. Không suy diễn rằng catalog kế hoạch là cấu hình ERP.
Consequence if Wrong	Nếu chọn O1 hoặc O2 rồi coi là đủ, Nova Foods không truy xuất chắc chắn khách nào nhận LOT-OP1L-20260720-A. Khi có sự cố chất lượng mô phỏng, phạm vi liên hệ khách hàng có thể thiếu hoặc quá rộng; tồn lô có thể âm dù tồn SKU còn dương; đối soát kho và điều tra sai lệch mất căn cứ dữ liệu.	Hậu quả phát sinh từ thiếu liên kết cấu trúc giữa xuất hàng, lô và khách hàng, không phải từ việc nhân viên “nhập sai ghi chú”.

Quy tắc đề xuất để review:

Rule ID mô phỏng	Quy tắc	Kiểm tra
BR-NF-LOT-001	Mỗi dòng xuất hàng đã xác nhận phải có ít nhất một phân bổ lô.	Từ chối xác nhận nếu danh sách phân bổ rỗng.
BR-NF-LOT-002	Tổng quantity của các phân bổ lô phải bằng requestedQuantity của dòng xuất.	Với 120 thùng, tổng phân bổ phải đúng 120.
BR-NF-LOT-003	quantity phân bổ cho mỗi lotId không được vượt số lượng khả dụng của lô tại thời điểm xác nhận.	Lô A tối đa 80; lô B tối đa 100.
BR-NF-LOT-004	lotId phải thuộc đúng SKU của dòng xuất và trạng thái lô phải cho phép xuất theo quyết định nghiệp vụ được ủy quyền.	Không dùng lô của SKU khác hoặc lô bị chặn.

Payload minh họa cấu trúc đề xuất, không phải đặc tả API đã phê duyệt:

{
  "deliveryNoteId": "DN-NF-20260807-001",
  "salesOrderId": "SO-NF-20260807-001",
  "warehouseId": "WH-NF-BT-001",
  "confirmedAt": "2026-08-07T14:30:00+07:00",
  "currency": "VND",
  "lines": [
    {
      "lineNo": 1,
      "sku": "SKU-OP1L-001",
      "requestedQuantity": 120,
      "uom": "THUNG",
      "lotAllocations": [
        {
          "lotId": "LOT-OP1L-20260720-A",
          "quantity": 80
        },
        {
          "lotId": "LOT-OP1L-20260725-B",
          "quantity": 40
        }
      ]
    }
  ]
}

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

flowchart TB
    BA["BA ghi nhận recommendation O3<br/>và duy trì analysis, traceability"]
    LIMIT["BA không phê duyệt requirement,<br/>thay đổi ERP hoặc điều kiện xuất lô"]
    S["Đề xuất O3<br/>IN_REVIEW — v0.9.0"]
    C5["Giữ nguyên SO-NF-20260807-001<br/>và DN-NF-20260807-001"]

    BA --> S
    BA -. "ranh giới trách nhiệm" .-> LIMIT
    S --> C5
    C5 --> V{"Đã hoàn tất xác minh chuyên môn?<br/>Solution Architect: mô hình dữ liệu và tích hợp<br/>Food Safety Owner, Legal Owner: truy vết<br/>QA Owner: test basis"}

    V -- "Chưa" --> RI["Giữ IN_REVIEW<br/>BA cập nhật analysis và traceability"]
    RI --> V

    V -- "Rồi" --> TBO["Trình Business Owner<br/>quyết định ưu tiên nghiệp vụ và<br/>chấp nhận thay đổi quy trình"]
    TBO --> D{"Business Owner quyết định?"}

    D -- "Chưa quyết định" --> RI
    D -- "Không chấp thuận<br/>hoặc yêu cầu sửa" --> RI
    D -- "Chấp thuận thay đổi quy trình" --> AP["Ghi nhận chấp thuận<br/>thay đổi quy trình"]

    AP --> P["Vẫn cần baseline và<br/>production authorization"]
    P --> STOP["Dừng tại ranh giới pre-production<br/>chưa suy diễn quyền triển khai"]

    subgraph PF["Luồng nghiệp vụ đề xuất — chưa được phê duyệt cho production"]
        A["Nhân viên kho mở<br/>DN-NF-20260807-001"] --> B["Nhập lotId và quantity<br/>cho từng phân bổ lô"]
        B --> C{"Có ít nhất một<br/>phân bổ lô?"}
        C -- "Không" --> X["ERP từ chối xác nhận<br/>DN vẫn chưa xác nhận"]
        C -- "Có" --> Q{"Tổng phân bổ<br/>bằng 120?"}
        Q -- "Không" --> X
        Q -- "Có" --> E{"Mỗi lô đủ tồn,<br/>đúng SKU và trạng thái cho phép xuất?"}
        E -- "Không" --> X
        E -- "Có" --> F["ERP ghi phân bổ lô<br/>có cấu trúc"]
        F --> G["ERP xác nhận DN"]
        G --> H["ERP cập nhật tồn từng lô<br/>và lưu truy vết"]
    end

    C5 -. "phạm vi đang được review" .-> A

    N["Nếu tiếp tục dùng ghi chú tự do<br/>làm nguồn sự thật cho lô xuất"]
    N --> R1["Không truy xuất chắc chắn<br/>khách hàng nhận lô nào"]
    N --> R2["Tồn lô có thể âm<br/>dù tồn SKU còn dương"]
    N --> R3["Phạm vi thu hồi có thể<br/>thiếu hoặc quá rộng"]
    N --> R4["Đối soát kho và điều tra sai lệch<br/>mất căn cứ dữ liệu"]
    S -. "rủi ro cần xử lý" .-> N

Ranh giới quyết định: BA có thể chứng minh O3 phù hợp tiêu chí bằng dữ liệu trên. BA không tự tuyên bố BR-NF-LOT-001 đến BR-NF-LOT-004 là nghĩa vụ pháp lý, không tự phê duyệt thay đổi ERP, không tự xác nhận lô đủ điều kiện xuất. Verification required từ Food Safety Owner, Legal Owner, Business Owner, Solution Architect và QA Owner.

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, VND. Case NFS-EX-08-001 xử lý yêu cầu xuất bán lô sữa hạt khi kho không đủ hàng khả dụng. ID này chỉ dùng trong ví dụ học liệu, không phải ID canonical hay cấu hình ERP thực.

Thành phần	Giá trị đầy đủ
Đơn bán hàng	SO-NF-20260807-001
Khách hàng	CUS-NF-001, Siêu thị Bình Minh
Kho xuất	WH-HCM-01
Mặt hàng	FG-SHAT-1L, Sữa hạt 1 lít
Số lượng đặt	240 chai
Tồn khả dụng tại thời điểm kiểm tra	180 chai
Lô khả dụng	LOT-SHAT-260801-A, 180 chai, hạn dùng 2026-11-01
Lô đang chờ kiểm tra chất lượng	LOT-SHAT-260805-B, 120 chai
Ngày giao khách yêu cầu	2026-08-08
Giá trị đơn mô phỏng	12.000.000 VND
Trạng thái artifact	IN_REVIEW, v0.9.0, ngày 2026-08-07

ID case-local	Quy tắc hoặc tiêu chí	Nội dung đầy đủ	Phân loại
BR-NFS-EX-001	Chỉ giữ hàng khả dụng	Hệ thống chỉ được phân bổ từ lô có trạng thái AVAILABLE. Lô QUALITY_HOLD không được phân bổ.	Project assumption; cần Business Owner và Quality Owner xác minh trước production.
BR-NFS-EX-002	Không tạo giao vượt tồn khả dụng	Nếu số lượng yêu cầu lớn hơn tồn khả dụng, hệ thống phải chặn xác nhận giao đủ và yêu cầu chọn giao một phần, chờ kiểm tra chất lượng, hoặc điều chỉnh đơn.	Project assumption.
DC-NFS-EX-001	Đúng hẹn giao	Phương án phải đánh giá khả năng giao ngày 2026-08-08.	Tiêu chí quyết định.
DC-NFS-EX-002	An toàn chất lượng	Phương án không được dùng lô chưa được Quality Owner xác nhận khả dụng.	Tiêu chí quyết định.
DC-NFS-EX-003	Giảm rủi ro hủy đơn	Phương án phải cho khách biết số lượng và ngày giao thực tế trước khi tạo chứng từ giao hàng.	Tiêu chí quyết định.

Facts: Đơn yêu cầu 240 chai. Kho chỉ có 180 chai ở trạng thái AVAILABLE. Thiếu 60 chai. Lô LOT-SHAT-260805-B có 120 chai nhưng đang QUALITY_HOLD; bằng chứng là trạng thái lô khác AVAILABLE. Vì vậy 120 chai này chưa phải tồn có thể hứa giao.

Current Behavior: Nhân viên bán hàng sửa số lượng phân bổ thành 240 chai bằng ghi chú tay, rồi gửi kho chuẩn bị hàng. Hệ thống không chặn lô QUALITY_HOLD. Bằng chứng là quy trình hiện tại không kiểm tra trạng thái lô trước bước tạo phiếu xuất. Hệ quả là kho có thể nhận lệnh xuất vượt hàng hợp lệ.

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

flowchart TB
    A[SO-NF-20260807-001: yêu cầu 240 chai] --> B{Tồn AVAILABLE đủ 240 chai?}

    B -- Có --> C[Phân bổ 240 chai chỉ từ lô AVAILABLE]
    C --> N1[Thông báo khách số lượng 240 chai và ngày giao thực tế]
    N1 --> P[Tạo phiếu xuất]

    B -- Không: chỉ có 180 chai --> D[Thiếu 60 chai]
    D --> E{Đã có quyết định được ủy quyền của Business Owner?}
    E -- Chưa --> W[Chờ Business Owner quyết định<br/>authorizedDecision = null]
    E -- Có --> F{Phương án Business Owner chọn}

    F -- Giao một phần --> G[Business Owner chấp nhận giao 180 chai]
    G --> H[Phân bổ 180 chai từ LOT-SHAT-260801-A<br/>trạng thái AVAILABLE]
    H --> N2[Thông báo khách giao 180 chai ngày 2026-08-08<br/>và giao bù 60 chai sau]
    N2 --> I{Khách chấp nhận giao một phần?}
    I -- Có --> P
    I -- Không --> R[Đánh giá lại số lượng hoặc ngày giao<br/>và xác nhận lại với khách]

    F -- Chờ kiểm tra chất lượng --> J{Quality Owner đã xác nhận<br/>chuyển LOT-SHAT-260805-B sang AVAILABLE?}
    J -- Chưa: QUALITY_HOLD --> K[Tiếp tục chờ xác nhận của Quality Owner]
    J -- Có --> L[Phân bổ 180 chai từ LOT-SHAT-260801-A<br/>và thêm 60 chai từ LOT-SHAT-260805-B]
    L --> N3[Thông báo khách số lượng 240 chai và ngày giao thực tế]
    N3 --> P

    F -- Điều chỉnh đơn hoặc ngày giao --> R

Underlying Need: Cần kiểm soát phân bổ theo trạng thái lô để lời hứa giao hàng dựa trên hàng có thể xuất. Suy luận này đi từ chênh lệch 240 - 180 = 60 chai và từ rủi ro dùng lô QUALITY_HOLD; nhu cầu không phải “có thêm nút xuất hàng”.

Phương án	Mô tả	Đánh giá theo DC-NFS-EX-001	Đánh giá theo DC-NFS-EX-002	Đánh giá theo DC-NFS-EX-003
OPT-NFS-EX-001	Giao 180 chai ngày 2026-08-08; tạo dòng giao bù 60 chai sau khi có hàng khả dụng.	Đạt một phần	Đạt	Đạt nếu khách nhận giao một phần
OPT-NFS-EX-002	Phân bổ cả 240 chai, gồm 60 chai từ lô QUALITY_HOLD.	Có thể đạt ngày giao	Không đạt	Không đạt
OPT-NFS-EX-003	Chờ Quality xác nhận lô LOT-SHAT-260805-B, rồi xác nhận lại ngày giao.	Chưa xác định	Đạt	Đạt nếu thông báo lại khách

Recommendation của BA: Chọn OPT-NFS-EX-001 làm phương án mặc định khi chưa có xác nhận chất lượng. Lý do: phương án này dùng đúng 180 chai AVAILABLE, không suy diễn chất lượng cho 120 chai đang giữ, và ghi rõ phần thiếu 60 chai. Đây là khuyến nghị phân tích, không phải quyết định đã được thẩm quyền ban hành.

Authorized Decision: Chưa có quyết định được ủy quyền ghi nhận trong case này. Business Owner quyết định chấp nhận giao một phần hay đổi ngày giao. Quality Owner quyết định chuyển LOT-SHAT-260805-B từ QUALITY_HOLD sang AVAILABLE. BA không được ghi khuyến nghị là quyết định, approval, baseline, hay cấu hình production.

Artifact đề xuất để review: /03-templates/ chưa được dùng làm nơi lưu artifact vì không có filename canonical được cung cấp cho case này. Gói review case-local gồm dữ liệu sau, phải được liên kết về CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY trước khi thành artifact kiểm soát.

{
  "salesOrderId": "SO-NF-20260807-001",
  "warehouseId": "WH-HCM-01",
  "itemId": "FG-SHAT-1L",
  "requestedQuantity": 240,
  "availableQuantity": 180,
  "shortQuantity": 60,
  "allocation": [
    {
      "lotId": "LOT-SHAT-260801-A",
      "lotStatus": "AVAILABLE",
      "quantity": 180
    }
  ],
  "blockedLot": {
    "lotId": "LOT-SHAT-260805-B",
    "lotStatus": "QUALITY_HOLD",
    "quantity": 120
  },
  "baRecommendation": "OPT-NFS-EX-001",
  "authorizedDecision": null,
  "currency": "VND",
  "timezone": "Asia/Ho_Chi_Minh",
  "dataClassification": "SYNTHETIC_EDUCATIONAL"
}

Consequence if Wrong: Nếu hệ thống cho phân bổ từ QUALITY_HOLD, kho có thể xuất lô chưa đủ điều kiện nội bộ. Nếu hệ thống không báo thiếu 60 chai, bán hàng có thể hứa giao đủ khi chỉ có 180 chai hợp lệ. Nếu BA ghi OPT-NFS-EX-001 là quyết định đã được ủy quyền, traceability sai vì Business Owner và Quality Owner chưa có quyết định được ghi nhận.

9. Related Concepts & Dependencies

Core

Dependency là quan hệ phụ thuộc: artifact này cần artifact khác làm nguồn để giữ nghĩa, ID, phạm vi hoặc quyết định nhất quán. Upstream là nguồn đi vào. Downstream là nơi dùng kết quả đi ra. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Section này không sao chép nội dung canonical. Nó chỉ chỉ vị trí nguồn chân lý và quy tắc tham chiếu. Ví dụ, handbook không tự định nghĩa lại trường lotStatus; phải trỏ tới CANONICAL_DATA_DICTIONARY. Lý do: hai định nghĩa khác nhau cho cùng trường dữ liệu làm BA, Dev và QA kiểm tra hai hành vi khác nhau.

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

flowchart TB
    SM["00_SOURCE_MAP<br/>Nguồn và ranh giới dùng nguồn"]
    CA["01_CURRICULUM_ARCHITECTURE<br/>Cấu trúc curriculum"]
    CM["CHAPTER_MANIFEST<br/>Chapter, filename, phạm vi"]
    TM["TEMPLATE_MANIFEST<br/>Danh mục template"]
    IDR["TRACEABILITY_ID_REGISTRY<br/>Đăng ký ID truy vết"]
    BR["CANONICAL_BUSINESS_RULES<br/>Nguồn chân lý business rule"]
    DD["CANONICAL_DATA_DICTIONARY<br/>Nguồn chân lý dữ liệu logic"]
    HB["02-handbook/01-ba-role-lifecycle-and-governance.md<br/>Section 9"]

    SM --> CA
    CA --> CM
    CM --> HB
    TM --> HB
    IDR --> HB
    BR --> HB
    DD --> HB

Applied

Facts: Case mô phỏng dùng SO-NF-20260807-001, WH-HCM-01, FG-SHAT-1L, LOT-SHAT-260801-A, LOT-SHAT-260805-B. LOT-SHAT-260805-B có lotStatus là QUALITY_HOLD. Các chuỗi này là persistent ID, nghĩa là định danh giữ nguyên khi artifact khác cùng tham chiếu cùng đối tượng.

Current Behavior: Case-local JSON ghi availableQuantity là 180, shortQuantity là 60, và không phân bổ từ lô QUALITY_HOLD. Handbook dùng các giá trị này để minh họa phân tích, không biến JSON thành nguồn chân lý dữ liệu hay quy tắc.

Underlying Need: Learner cần biết nơi kiểm tra nghĩa của ID, trạng thái lô, quy tắc phân bổ và filename chapter. Bằng chứng: các artifact upstream đã chỉ định registry ID, catalog business rule, data dictionary, chapter manifest và template manifest là artifact kiểm soát riêng.

Options:
1. Chép định nghĩa QUALITY_HOLD vào handbook.
2. Tham chiếu artifact canonical và chỉ diễn giải tác động trong ngữ cảnh BA.
3. Tạo ID mới trong handbook cho cùng lô hoặc cùng đơn hàng.

Decision Criteria: Chọn cách không tạo hai nguồn chân lý; giữ nguyên ID đã có; không suy diễn approval, baseline, cấu hình ERP hay quy tắc vận hành thực.

Decision: Chọn option 2. TRACEABILITY_ID_REGISTRY quản lý cấu trúc và tính duy nhất ID. CANONICAL_DATA_DICTIONARY quản lý nghĩa logic của lotStatus, availableQuantity và shortQuantity. CANONICAL_BUSINESS_RULES quản lý quy tắc nghiệp vụ. CHAPTER_MANIFEST quản lý chapter và filename. TEMPLATE_MANIFEST quản lý danh mục template dự kiến.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner, Quality Owner, Architect, QA, Legal, Accounting hoặc Security Owner giữ thẩm quyền chuyên môn tương ứng. Không có approval hay baseline được ghi nhận tại IN_REVIEW, v0.9.0, ngày 2026-08-07.

Artifact: Section này thuộc /02-handbook/01-ba-role-lifecycle-and-governance.md. Các nguồn tham chiếu giữ nguyên đường dẫn:

Vai trò dependency	Artifact ID	Canonical filename/path	Handbook được phép làm gì	Handbook không được làm gì
Nguồn và giới hạn nguồn	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Nêu nguồn phù hợp, nhãn xác minh	Bịa điều khoản, trang, trích dẫn
Cấu trúc học liệu	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Liên kết lifecycle chapter	Đổi phạm vi curriculum
Danh mục chapter	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Giữ title, section, filename	Tự đổi canonical chapter ID
Danh mục template	TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ dẫn template liên quan khi đã đăng ký	Tạo filename template không đăng ký
Registry ID	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Dùng nguyên dạng ID đã cấp	Đổi, tái sử dụng, tự cấp persistent ID
Catalog rule	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nêu rule cần tham chiếu	Chép hoặc sửa rule canonical
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Nêu field và tác động phân tích	Tự định nghĩa kiểu, miền giá trị, nghĩa field

Consequence if Wrong: Nếu handbook tự định nghĩa QUALITY_HOLD khác data dictionary, Dev có thể chặn xuất hàng theo một nghĩa còn QA kiểm thử theo nghĩa khác. Nếu LOT-SHAT-260805-B bị đổi ID trong một artifact, liên kết tới lô bị đứt và bằng chứng phân tích không còn chỉ cùng đối tượng. Nếu template chưa đăng ký bị gọi là canonical, learner có thể dùng nhầm tệp và bỏ qua kiểm soát manifest.

Senior Lens

Quy tắc senior: trích dẫn định danh, không nhân bản định nghĩa. Một artifact chỉ nên sở hữu một loại sự thật: registry sở hữu ID; data dictionary sở hữu nghĩa dữ liệu; rule catalog sở hữu business rule; manifest sở hữu vị trí và phạm vi artifact.

Khi cần diễn giải, ghi cầu nối bằng chứng: “Case ghi LOT-SHAT-260805-B là QUALITY_HOLD; nghĩa và hành vi chuẩn của trạng thái phải xác minh tại CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES.” Câu này tách rõ fact case-local khỏi canonical definition.

Không suy ra nghĩa nghiệp vụ chỉ từ tên ID. SO-NF-20260807-001 cho thấy định dạng định danh trong case mô phỏng, không chứng minh đây là khóa ERP production, số chứng từ pháp lý, hay quy tắc đánh số đã được phê duyệt.

Quick Reference

Cần biết	Xem nguồn nào	Không dùng handbook để quyết định
ID có hợp lệ, duy nhất, đúng loại	TRACEABILITY_ID_REGISTRY	Cấp ID mới
Field nghĩa gì, có giá trị nào	CANONICAL_DATA_DICTIONARY	Định nghĩa lại field
Rule nghiệp vụ nói gì	CANONICAL_BUSINESS_RULES	Tự xác nhận rule đúng
Chapter/template nằm ở đâu	CHAPTER_MANIFEST, TEMPLATE_MANIFEST	Đổi filename canonical
Nguồn chuẩn hay pháp lý dùng ra sao	00_SOURCE_MAP	Kết luận pháp lý hoặc compliance

Core

Truy vết (traceability) là liên kết có kiểm soát giữa nhu cầu và bằng chứng kiểm thử. Mỗi liên kết giữ ID tại nguồn canonical; handbook chỉ tham chiếu, không sao chép hay tự cấp ID. Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp; mọi artifact hiện IN_REVIEW, v0.9.0, ngày 2026-08-07.

Loại liên kết	Ý nghĩa	Nguồn canonical giữ ID	Đích dùng liên kết	Quy tắc kiểm soát
NEED	Nhu cầu nghiệp vụ, nói vấn đề cần giải quyết	TRACEABILITY_ID_REGISTRY	REQ, BR	Không đổi câu NEED trong handbook.
REQ	Requirement, yêu cầu hệ thống hoặc nghiệp vụ kiểm chứng được	TRACEABILITY_ID_REGISTRY	BR, AC, DATA/API, TC	Một REQ phải có ít nhất một NEED hoặc nguồn thẩm quyền ghi rõ.
BR	Business Rule, quy tắc nghiệp vụ quyết định cách xử lý	CANONICAL_BUSINESS_RULES	REQ, AC, TC	Không biến giả định học liệu thành BR canonical.
AC	Acceptance Criteria, điều kiện chấp nhận đo được	Artifact requirement được registry liên kết	REQ, TC	AC phải kiểm tra được, không thay thế REQ.
DATA/API	Trường dữ liệu, thực thể logic hoặc hợp đồng API	CANONICAL_DATA_DICTIONARY và đặc tả API được đăng ký	REQ, AC, TC	Không suy diễn kiểu dữ liệu, endpoint, quyền truy cập.
TC	Test Case, ca kiểm thử tạo bằng chứng đạt hoặc không đạt	Registry test/traceability được đăng ký	AC, REQ, BR	TC không tạo rule mới; phát hiện thiếu rule phải trả về nguồn canonical.

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

flowchart TB
  C["Nét liền: liên kết truy vết<br/>Nét đứt: luồng xem xét thiếu rule"]
  O["Nguồn thẩm quyền ghi rõ"]

  subgraph NF["Nova Foods — mọi artifact: IN_REVIEW | v0.9.0 | 2026-08-07"]
    N["NEED<br/>ID từ TRACEABILITY_ID_REGISTRY"]
    R["REQ<br/>ID từ TRACEABILITY_ID_REGISTRY"]
    B["BR<br/>CANONICAL_BUSINESS_RULES"]
    A["AC<br/>Artifact requirement được registry liên kết"]
    D["DATA/API<br/>Data: CANONICAL_DATA_DICTIONARY<br/>API: đặc tả API được đăng ký"]
    T["TC<br/>Registry test/traceability được đăng ký"]
  end

  M["Thiếu rule: trả về CANONICAL_BUSINESS_RULES<br/>để xem xét, không tạo rule mới"]

  N --> R
  N --> B
  O -->|ghi nhận khi REQ không có NEED| R

  R --> B
  R --> A
  R --> D
  R --> T

  B --> R
  B --> A
  B --> T

  A --> R
  A --> T

  D --> R
  D --> A
  D --> T

  T --> A
  T --> R
  T --> B
  T -.->|phát hiện thiếu rule| M
  M -.->|trả về để xem xét| B

Applied

Mục	Nội dung mô phỏng Nova Foods
Facts	Quy trình tạo đơn bán cần liên kết NEED, REQ, BR, AC, DATA/API và TC trước khi QA viết kiểm thử. ID cụ thể phải lấy từ /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Current Behavior	Người viết handbook có thể thấy cùng một khái niệm trong requirement, rule catalog và data dictionary. Sao chép nội dung sang nhiều nơi tạo nhiều nguồn sự thật.
Underlying Need	QA cần biết TC kiểm chứng AC nào; BA cần biết AC hiện thực hóa REQ nào; Data/API owner cần biết thay đổi trường nào ảnh hưởng yêu cầu nào.
Options	1. Chép toàn văn NEED, REQ, BR vào handbook. 2. Chỉ lưu ID và đường dẫn canonical, kèm mô tả vai trò liên kết.
Decision Criteria	Một nguồn sửa được; ID ổn định; người đọc truy ngược được; không ngầm tạo approval hoặc baseline.
Decision	Chọn phương án 2. Bảng handbook chỉ làm ma trận tham chiếu. Nội dung chuẩn giữ tại registry, rule catalog, data dictionary và artifact requirement/test được đăng ký.
Authority	Principal IT Business Analyst / Technical Curriculum Author giữ governance ID. Business Owner, Architect, QA, Legal, Accounting hoặc Security xác nhận phần thuộc thẩm quyền họ; chưa có approval được ghi nhận.
Artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	TC có thể kiểm tra hành vi cũ, API đổi trường nhưng AC không đổi, hoặc rule bị diễn giải khác nhau. Kết quả “pass” không còn chứng minh REQ được đáp ứng.

Senior Lens

Ma trận tối thiểu phải trả lời hai hướng: từ NEED đi xuống tìm mọi REQ, BR, AC, DATA/API và TC; từ TC đi ngược lên tìm lý do tồn tại. Liên kết thiếu không tự chứng minh lỗi, nhưng là tín hiệu cần phân loại: chưa có artifact, ID chưa đăng ký, hoặc dependency chưa được xác minh.

Kiểm tra	Bằng chứng đạt	Dấu hiệu lỗi
NEED đến REQ	REQ tham chiếu đúng NEED-ID đăng ký	REQ không có lý do nghiệp vụ hoặc dùng ID tự đặt
REQ đến BR/AC	BR và AC nêu đúng REQ-ID	AC kiểm tra tính năng không thuộc REQ
REQ đến DATA/API	Trường hoặc API tham chiếu data dictionary	Tên trường khác nhau giữa BA và kỹ thuật
AC đến TC	TC nêu AC-ID và kết quả kỳ vọng	TC chỉ kiểm tra màn hình, không chứng minh AC
BR đến TC	TC có dữ liệu biên cho rule	Rule thay đổi nhưng không biết test nào chạy lại

Quick Reference

Khi cần ghi liên kết	Ghi gì	Không ghi gì
Handbook	ID, loại liên kết, đường dẫn nguồn canonical, trạng thái IN_REVIEW	Bản sao canonical rule hoặc ID mới
Requirement artifact	NEED-ID, BR-ID, AC-ID, DATA/API-ID khi áp dụng	Diễn giải pháp lý chưa được owner thẩm quyền xác minh
Test artifact	REQ-ID, AC-ID, BR-ID, DATA/API-ID khi ca test phụ thuộc dữ liệu hoặc tích hợp	Kết luận approval, compliance hoặc production-ready

Core

Phụ thuộc là quan hệ trong đó artifact sau dùng ý nghĩa, ID, cấu trúc hoặc trạng thái của artifact trước. Thay đổi phải lan truyền vì đầu ra cũ có thể không còn đúng khi nguồn canonical đổi. Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp; mọi artifact hiện IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, chưa là baseline hay approval.

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

flowchart TB
    A["Nguồn canonical đổi"] --> B["Ghi thay đổi có ID và thời điểm"]
    B --> C["Phân tích artifact và liên kết bị ảnh hưởng"]
    C --> D{"Có ảnh hưởng?"}
    D -->|Có| E["Cập nhật liên kết NEED/REQ/BR/AC/DATA/API/TC"]
    E --> F["Review theo thẩm quyền"]
    F --> G["Cập nhật artifact phụ thuộc hoặc chặn sử dụng"]
    D -->|Không| H["Ghi nhận không ảnh hưởng và giữ artifact hiện tại"]

Thay đổi im lặng là sửa nội dung, ID, đường dẫn, định nghĩa dữ liệu hoặc trạng thái mà không ghi nhận thay đổi và không rà soát liên kết. Nó phá truy vết: REQ vẫn trỏ tới BR cũ; AC kiểm tra hành vi cũ; TC cho kết quả đạt nhưng không còn chứng minh yêu cầu hiện hành. Nếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md đổi định nghĩa trường dữ liệu mà đặc tả API không được rà soát, tích hợp có thể gửi đúng tên trường nhưng sai kiểu, ý nghĩa hoặc quy tắc kiểm tra.

Applied

Mục	Nội dung
Facts	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY đều IN_REVIEW, v0.9.0. Chúng là nguồn kiểm soát riêng, không được sao chép thành nguồn mới trong handbook.
Current Behavior	Một người sửa diễn giải quy tắc trong catalog nhưng không ghi ảnh hưởng tới REQ, AC, DATA/API và TC.
Underlying Need	Bảo đảm mọi consumer biết nội dung nào phải xem lại trước khi dùng artifact phụ thuộc.
Options	1. Sửa trực tiếp không ghi nhận. 2. Ghi thay đổi, xác định liên kết ảnh hưởng, chặn artifact chưa rà soát.
Decision Criteria	Giữ ID canonical; giữ lịch sử; không suy diễn approval; không cho test hoặc tích hợp dựa trên nghĩa cũ.
Decision	Chọn phương án 2. Ghi thay đổi tại nguồn canonical; đánh dấu liên kết phụ thuộc cần rà soát; không gọi bất kỳ đầu ra nào là đã phê duyệt.
Authority	Principal IT Business Analyst / Technical Curriculum Author điều phối traceability. Business Owner, Architect, QA, Legal, Accounting hoặc Security xác nhận phần thuộc thẩm quyền họ.
Artifact	/01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Consequence if Wrong	Requirement sai nghĩa, acceptance criteria sai kỳ vọng, test pass giả, API lệch hợp đồng, hoặc nội dung học liệu bị diễn giải thành quyết định vận hành Nova Foods.

Senior Lens

Không lan truyền bằng cách chép lại nội dung nguồn vào mọi nơi. Chỉ nguồn canonical được sửa định nghĩa; artifact phụ thuộc giữ liên kết và ghi trạng thái tác động. Lý do: nhiều bản sao tạo nhiều “sự thật”, rồi không thể biết bản nào điều khiển REQ, AC hay TC.

Khi thay đổi đụng dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm, bảo mật hoặc API, BA không tự kết luận hiệu lực. Bằng chứng: các nguồn pháp lý và chuyên môn có owner riêng; source seed yêu cầu legal, accounting, domain hoặc security verification khi áp dụng. Gắn nhãn Verification required cho phần chưa được vai trò có thẩm quyền xác minh.

Quick Reference

Dấu hiệu thay đổi	Cần kiểm tra	Hỏng nếu bỏ qua
Đổi ID hoặc đường dẫn canonical	Liên kết registry và artifact tham chiếu	Link chết, mất traceability
Đổi business rule	REQ, BR, AC, TC liên quan	Xây và test theo logic cũ
Đổi định nghĩa dữ liệu	DATA/API, mapping, validation	Sai dữ liệu hoặc lỗi tích hợp
Đổi trạng thái/version	Metadata consumer và lịch sử thay đổi	Nhầm IN_REVIEW là baseline hoặc approval
Đổi nguồn pháp lý/chuyên môn	Nhãn xác minh và owner review	Claim tuân thủ không có căn cứ

10. Common Mistakes & Anti-patterns

Core

Anti-pattern là cách làm lặp lại tạo lỗi giao hàng dù tài liệu trông có vẻ hoàn chỉnh. BA mới thường ghi chép nhiều nhưng không tạo được đầu vào kiểm chứng cho đội build và test. Đội delivery cũng có thể gây lỗi khi biến ghi chú workshop thành yêu cầu triển khai mà không kiểm tra nguồn, phạm vi và người có thẩm quyền.

Sai lầm cụ thể	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Viết yêu cầu theo giải pháp có sẵn	“Cần thêm nút duyệt” nhưng không nêu ai duyệt, điều kiện nào, kết quả gì	Nhầm giao diện với nhu cầu nghiệp vụ	Viết lại theo mục tiêu, actor, điều kiện, kết quả; để Architect và delivery đánh giá giải pháp
Gộp nhiều quyết định vào một requirement	Một dòng chứa tạo đơn, kiểm tra tồn kho, tính giá, xuất hóa đơn	Muốn “viết nhanh”, không tách hành vi kiểm thử được	Tách theo kết quả nghiệp vụ độc lập; mỗi phần phải có thể review và test riêng
Chép yêu cầu từ chat hoặc họp miệng vào tài liệu kiểm soát	Không có nguồn, ngày ghi nhận, người cung cấp thông tin hoặc liên kết artifact	Coi trao đổi là nguồn chân lý	Ghi nguồn là ghi nhận trao đổi, giữ trạng thái IN_REVIEW; yêu cầu owner phù hợp xác nhận trước khi dùng làm quyết định
QA tự đoán tiêu chí chấp nhận	Test case có expected result nhưng requirement không có điều kiện tương ứng	Handoff thiếu, QA cố lấp khoảng trống	BA và Business Owner làm rõ; QA chỉ tạo test basis từ nội dung có thể truy vết
Developer sửa logic nghiệp vụ trực tiếp từ ticket lỗi	Pull request đổi quy tắc nhưng không cập nhật artifact canonical	Tối ưu tốc độ cục bộ hơn kiểm soát thay đổi	Dừng merge phần thay đổi nghiệp vụ; cập nhật liên kết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md và đánh giá tác động
Gọi tài liệu đang review là “đã chốt”	Người nhận dùng v0.9.0 làm đầu vào build bắt buộc	Nhầm IN_REVIEW với baseline hoặc approval	Sửa nhãn trạng thái; chỉ dùng “đã baseline” hoặc “đã phê duyệt” khi artifact kiểm soát có tham chiếu tương ứng
Dùng số liệu ví dụ như dữ liệu vận hành	Giá 125.000 VND trong ví dụ bị đưa vào cấu hình	Không phân biệt dữ liệu tổng hợp và master data	Gắn “mô phỏng giáo dục, dữ liệu tổng hợp”; cấm dùng ví dụ làm cấu hình production

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

flowchart TB
    A[BA hoặc delivery: Phát hiện sai lệch] --> B[BA: Khoanh vùng artifact và phiên bản]
    B --> C{Nguồn và owner có thẩm quyền hợp lệ?}
    C -- Thiếu hoặc chưa xác nhận --> D[BA: Giữ nội dung IN_REVIEW và yêu cầu owner phù hợp xác nhận]
    D --> C
    C -- Hợp lệ --> E{Ảnh hưởng build, test, merge hoặc cấu hình?}
    E -- Có --> F[QA và delivery: Dừng dùng nội dung sai làm test basis, merge hoặc cấu hình]
    F --> G[BA và Business Owner: Cập nhật artifact canonical hoặc artifact kiểm soát phù hợp]
    E -- Không --> G
    G --> H[Ghi nguồn, trạng thái và liên kết truy vết]
    H --> I[BA, QA và delivery: Review phạm vi tác động]
    I --> J[Chỉ dùng lại khi nội dung được review, baseline hoặc phê duyệt theo kiểm soát tương ứng]

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.

Mục	Nội dung
Facts	Ticket ghi: “ERP tự chặn đơn bán nếu khách vượt hạn mức tín dụng.” Không có nguồn quy tắc, điều kiện tính hạn mức, vai trò được phép xử lý ngoại lệ, hay liên kết tới artifact canonical.
Current Behavior	Developer thêm kiểm tra credit_limit trước khi lưu đơn; QA tạo test pass/fail theo giả định riêng.
Underlying Need	Cần ngăn đơn có rủi ro tín dụng, nhưng phải xác định dữ liệu tính toán, thời điểm kiểm tra và thẩm quyền xử lý.
Options	1. Giữ kiểm tra hiện tại. 2. Tắt kiểm tra. 3. Đưa ticket về trạng thái làm rõ, giữ hành vi cũ nếu chưa có quyết định kiểm soát.
Decision Criteria	Không tạo quy tắc nghiệp vụ mới; không suy diễn thẩm quyền tài chính; không để test case thay thế requirement; giữ traceability.
Decision	Chọn phương án 3. Không merge logic chặn mới khi chưa có nội dung được quản trị trong /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Authority	Business Owner xác nhận nhu cầu; Accounting Owner xác nhận cách hiểu tài chính; Architect xác nhận cách thực hiện; QA xác nhận test basis. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì liên kết và trạng thái.
Artifact	Ticket lỗi phải liên kết /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md và ghi Verification required cho nội dung chưa được owner phù hợp xác minh.
Consequence if Wrong	Đơn hợp lệ có thể bị chặn, đơn rủi ro có thể lọt, QA báo pass giả, hoặc ví dụ học liệu bị hiểu nhầm là chính sách Nova Foods thực tế.

Cảnh báo: Không đưa logic tín dụng, kế toán, thuế, hóa đơn hoặc dữ liệu cá nhân vào production từ tài liệu IN_REVIEW. Ranh giới khôi phục an toàn: dừng thay đổi chưa phát hành, hoàn nguyên cấu hình hoặc mã nếu có thể, bảo toàn log và escalation tới owner có thẩm quyền. Không tự sửa dữ liệu tài chính hoặc dữ liệu cá nhân để “khớp” với giả định.

Senior Lens

Sai lầm nguy hiểm nhất không phải thiếu câu chữ mà là giao nhầm quyền quyết định. Bằng chứng là source seed quy định Legal Owner, Accounting Owner, Security, Architect và Business Owner có phạm vi xác minh riêng. BA phải biến phát hiện thành vấn đề có cấu trúc: điều gì quan sát được, artifact nào bị ảnh hưởng, nguồn nào chưa đủ, ai cần quyết định.

Sửa đúng không đồng nghĩa viết thêm tài liệu. Nếu requirement trùng, xóa bản sao và giữ một nguồn canonical. Nếu ticket đã chứa giả định chưa xác minh, giữ ticket như bằng chứng phát hiện nhưng không nâng nó thành business rule. Cách này giảm nhiều nguồn chân lý và tránh delivery xây theo nội dung cũ.

Quick Reference

Khi thấy	Làm ngay	Không làm
Requirement chứa nhiều hành vi	Tách thành đơn vị review và test được	Chia nhỏ câu chữ nhưng giữ logic lẫn lộn
Ticket không có nguồn	Ghi nguồn thiếu và yêu cầu làm rõ	Tự điền quy tắc theo kinh nghiệm
Test case có expected result không có basis	Chặn test basis và liên kết lại requirement	Gọi test pass là xác nhận nghiệp vụ
IN_REVIEW bị gọi là “đã chốt”	Sửa trạng thái trong giao tiếp và artifact	Suy diễn approval từ Owner hoặc version
Ví dụ tổng hợp bị dùng làm cấu hình	Loại khỏi cấu hình, giữ nhãn mô phỏng	Xem dữ liệu học liệu là master data

Core

Cảnh báo — rủi ro thật: Không dùng lỗi học liệu Nova Foods để sửa trực tiếp cấu hình ERP, dữ liệu giao dịch, quyền truy cập, chứng từ, tồn kho hoặc sổ kế toán. Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dữ liệu tổng hợp; /02-handbook/01-ba-role-lifecycle-and-governance.md đang IN_REVIEW, v0.9.0, ngày 2026-08-07, không phải lệnh vận hành.

Sai sót cần cảnh báo khi hậu quả có thể làm đội giao hàng hiểu nhầm nội dung review là quyết định đã hiệu lực. Dấu hiệu: tài liệu ghi “đã áp dụng”, “đã phê duyệt”, “bắt buộc theo luật”, hoặc mô tả thao tác sửa dữ liệu production nhưng không có tham chiếu approval, baseline hay thẩm quyền. Bằng chứng quản trị: CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY cùng xác nhận IN_REVIEW không phải APPROVED hay BASELINED.

Applied

Facts: Ví dụ tổng hợp: BA ghi trong ghi chú Nova Foods rằng đơn bán SO-NF-2026-081 phải tự giảm tồn kho ngay khi tạo đơn.

Current Behavior: Nội dung được chuyển cho đội cấu hình như quyết định triển khai, dù chưa có artifact canonical xác nhận quy tắc và chưa có thẩm quyền Business Owner hoặc Accounting Owner.

Underlying Need: Cần ngăn bán vượt tồn, nhưng nhu cầu không tự chứng minh thời điểm giữ hàng, thời điểm xuất kho, hay bút toán liên quan.

Options: Giữ nội dung là giả định học liệu; đưa vấn đề vào artifact kiểm soát để xem xét; sửa cấu hình ERP thực.

Decision Criteria: Chỉ chọn phương án có nguồn canonical, owner đúng thẩm quyền, traceability và trạng thái cho phép.

Decision: Giữ là giả định mô phỏng; không sửa ERP.

Authority: Business Owner xác nhận chính sách giữ hàng; Architect xác nhận khả năng hệ thống; Accounting Owner xác nhận tác động kế toán. BA chỉ ghi nhận và liên kết bằng chứng.

Artifact: Ghi nguồn và trạng thái vào /02-handbook/01-ba-role-lifecycle-and-governance.md; tham chiếu nguyên dạng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.

Consequence if Wrong: Cấu hình giảm tồn khi tạo đơn có thể khóa hàng sai, làm lệch tồn khả dụng và tạo quyết định vận hành dựa trên nội dung chưa được phê duyệt.

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

flowchart TB
    A["Nội dung: đơn SO-NF-2026-081<br/>tự giảm tồn kho khi tạo đơn"] --> B["Đã chuyển cho đội cấu hình<br/>như quyết định triển khai"]
    B --> C["Thu hồi hoặc chặn chỉ thị triển khai<br/>không sửa ERP"]
    C --> D["Giữ nội dung là giả định mô phỏng"]

    D --> E["Nhu cầu: ngăn bán vượt tồn<br/>Chưa xác định thời điểm giữ hàng,<br/>xuất kho và bút toán liên quan"]
    E --> F["BA ghi nguồn và trạng thái vào<br/>/02-handbook/01-ba-role-lifecycle-and-governance.md"]
    F --> G["Đưa vấn đề vào artifact kiểm soát<br/>để xem xét"]
    G --> H["Đối chiếu CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY<br/>TRACEABILITY_ID_REGISTRY"]
    H --> I{"Đủ nguồn canonical<br/>và traceability?"}

    I -->|Không| J["Giữ trạng thái giả định mô phỏng<br/>không sửa ERP"]
    I -->|Có| K["Thu thập xác nhận<br/>từ đúng thẩm quyền"]

    K --> L["Business Owner: chính sách giữ hàng<br/>Architect: khả năng hệ thống<br/>Accounting Owner: tác động kế toán"]
    L --> M{"Đủ xác nhận đúng thẩm quyền<br/>và trạng thái cho phép?"}

    M -->|Không| J
    M -->|Có| N["Ghi từng xác nhận vào<br/>/02-handbook/01-ba-role-lifecycle-and-governance.md<br/>và cập nhật trạng thái"]
    N --> O["BA liên kết bằng chứng<br/>không tự cho phép sửa ERP"]
    O --> Q["Quyết định hiện tại:<br/>không sửa ERP"]

    J -.-> P["Nếu chỉ thị vẫn được thực hiện:<br/>có thể khóa hàng sai, lệch tồn khả dụng<br/>và gây quyết định vận hành<br/>từ nội dung chưa được phê duyệt"]

Senior Lens

Ranh giới khôi phục an toàn: chỉ hoàn tác thay đổi trong artifact mô phỏng hoặc môi trường được cấp quyền rõ. Không tự xóa giao dịch, sửa số dư, đảo chứng từ, cấp lại quyền, hay gọi API production. Nếu đã lan truyền thông tin sai, dừng dùng bản đó, đánh dấu trạng thái cần xem xét, lưu bằng chứng phiên bản, rồi phát hành bản sửa có lịch sử thay đổi. Không gọi việc khôi phục là “đã được phê duyệt” khi approval chưa được ghi nhận.

Quick Reference

Tình huống	Hành động an toàn	Không làm
Ghi chú bị hiểu là lệnh cấu hình	Dừng handoff, gắn IN_REVIEW, chuyển owner đúng thẩm quyền	Tự sửa ERP
Ví dụ tổng hợp gây ảnh hưởng dữ liệu	Xóa hoặc sửa trong artifact học liệu, lưu lịch sử thay đổi	Đụng dữ liệu thực
Không rõ cách khôi phục	Cô lập thay đổi, lập gói bằng chứng, escalation	Đoán thao tác đảo
Có hậu quả kế toán, pháp lý, bảo mật	Chuyển Accounting Owner, Legal Owner, Security hoặc Architect	BA tự kết luận

Core

Năm lỗi này khác nhau vì loại thiếu hụt khác nhau. Mơ hồ (ambiguity) có nhiều cách hiểu hợp lý; không đầy đủ (incompleteness) thiếu điều kiện, dữ liệu hoặc kết quả cần thiết; khẳng định thẩm quyền không có bằng chứng gán quyết định cho người hoặc nguồn chưa xác nhận; dùng sai ký pháp (notation misuse) làm sơ đồ nói khác nội dung; đứt truy vết (traceability break) khiến không lần được từ nhu cầu đến rule, dữ liệu, kiểm thử hoặc nguồn.

Loại lỗi	Dấu hiệu quan sát được	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp	Cách sửa an toàn
Mơ hồ	Có từ “nhanh”, “đủ”, “hợp lệ”, “quản lý duyệt” nhưng không có tiêu chí	“Đơn bán chỉ được giao khi tín dụng hợp lệ.” Không nêu ngưỡng, thời điểm kiểm tra, vai trò xử lý ngoại lệ	Tách thành điều kiện đo được; ghi nguồn hoặc nhãn Verification required
Không đầy đủ	Có happy path nhưng thiếu lỗi, ngoại lệ, đầu ra hoặc owner	Luồng tạo đơn bán có bước “kiểm tra tồn kho” nhưng thiếu trường hợp thiếu hàng và trạng thái đơn	Bổ sung trigger, đầu vào, quy tắc, ngoại lệ, trạng thái sau xử lý và consumer
Khẳng định thẩm quyền không có bằng chứng	Viết “đã được phê duyệt”, “luật bắt buộc”, “kế toán xác nhận” mà artifact không có approval/reference	“Nova Foods đã phê duyệt giới hạn công nợ 50.000.000 VND.” Corpus chỉ ở IN_REVIEW, v0.9.0	Đổi thành “project assumption” hoặc Verification required; chỉ định Business Owner/Accounting Owner xác nhận
Dùng sai ký pháp	Gọi sơ đồ PlantUML là BPMN; dùng hình thoi như kho dữ liệu; nối mũi tên không rõ điều kiện	Activity diagram mô tả “Cập nhật tồn kho” nhưng chú thích “BPMN 2.0.2”	Đổi nhãn thành “PlantUML activity diagram”; chỉ gọi BPMN khi dùng đúng BPMN theo OMG BPMN 2.0.2
Đứt truy vết	Requirement có ID nhưng rule, field, test hoặc source không có liên kết; dùng ID tự đặt	Requirement nói kiểm tra lô hàng nhưng không liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc TRACEABILITY_ID_REGISTRY	Giữ ID canonical; liên kết artifact nguồn; không tạo ID, baseline hoặc approval ngầm định

Cảnh báo: Khẳng định sai về pháp lý, kế toán, an toàn thực phẩm hoặc phê duyệt có thể biến học liệu thành chỉ dẫn vận hành sai. Nova Foods là case study mô phỏng; không dùng dữ liệu thật, không suy diễn tuân thủ, không đưa nội dung vào production. Ranh giới phục hồi: dừng sử dụng phát biểu đó làm quyết định, gắn Verification required, rồi chuyển đúng Legal Owner, Accounting Owner, Business Owner hoặc domain owner.

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

flowchart TB
    A[Phát hiện phát biểu hoặc sơ đồ lỗi] --> S[Dừng dùng phát biểu làm quyết định]
    S --> B{Lỗi thuộc loại nào?}

    B -->|Nhiều cách hiểu| C[Mơ hồ: lấy tiêu chí từ nguồn có thẩm quyền<br/>hoặc gắn Verification required]
    B -->|Thiếu trigger, dữ liệu, quy tắc,<br/>ngoại lệ, trạng thái, đầu ra hoặc owner| D[Không đầy đủ: bổ sung trigger, đầu vào, quy tắc,<br/>ngoại lệ, trạng thái sau xử lý, đầu ra, consumer và owner]
    B -->|Thiếu bằng chứng quyết định| E[Thẩm quyền: gắn Verification required<br/>và chuyển đúng owner]
    B -->|Tên hoặc ký hiệu sai chuẩn| F[Ký pháp: sửa nhãn hoặc vẽ lại đúng chuẩn]
    B -->|Đứt liên kết requirement, rule,<br/>data, test hoặc source| G[Truy vết: khôi phục liên kết bị đứt<br/>bằng ID canonical]

    C --> H{Liên quan pháp lý, kế toán,<br/>an toàn thực phẩm hoặc phê duyệt?}
    D --> H
    E --> H
    F --> H
    G --> H

    H -->|Có| I[Gắn Verification required<br/>và chuyển đúng Legal Owner, Accounting Owner,<br/>Business Owner hoặc domain owner]
    H -->|Không| J[Kiểm tra source boundary<br/>và ID canonical]
    I --> J

    J --> K{Nguồn hỗ trợ phát biểu?}
    K -->|Không| L[Giữ Verification required<br/>và không dùng làm quyết định]
    K -->|Có| N{Quyết định nghiệp vụ<br/>cần phê duyệt?}

    N -->|Có| O[Chuyển đúng owner<br/>để review và phê duyệt]
    O --> P{Đúng owner đã phê duyệt?}
    P -->|Chưa| L
    P -->|Có| Q{Trạng thái thẩm quyền<br/>cho phép sử dụng?}
    N -->|Không| Q

    Q -->|Không hoặc vẫn IN_REVIEW| L
    Q -->|Có| M[Cập nhật artifact<br/>và duy trì truy vết]

Không được “sửa” mơ hồ bằng cách BA tự chọn một giá trị nghiệp vụ. Suy luận này dựa trên ranh giới thẩm quyền của CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY: các artifact ở IN_REVIEW, v0.9.0, ngày 2026-08-07, không phải bằng chứng APPROVED hay BASELINED.

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn phương án “được nhiều người thích nhất”. Senior BA tách sự kiện (fact: dữ liệu có thể kiểm tra), diễn giải (interpretation: cách hiểu từ sự kiện), quyết định (decision: lựa chọn có thẩm quyền) và giả định dự án (project assumption: điều tạm dùng khi chưa đủ bằng chứng). Tách bốn lớp này giúp tránh biến ý kiến của một bên thành quy tắc ERP Nova Foods. Nova Foods Trading & Manufacturing là case study mô phỏng; mọi dữ liệu đều tổng hợp.

Tình huống xung đột	Trade-off cần nhìn	Bằng chứng tối thiểu	Thẩm quyền quyết định	Cách BA ghi nhận
Kho muốn cho sửa số lô sau khi nhập kho; QA muốn khóa	Sửa nhanh giảm gián đoạn; khóa giữ khả năng truy vết	Luồng hiện tại, mẫu lỗi tổng hợp, tác động báo cáo, ý kiến QA	Business Owner quyết định vận hành; domain owner xác nhận truy vết	Ghi hai lựa chọn, rủi ro từng lựa chọn, Verification required nếu nghĩa vụ pháp lý chưa xác minh
Kế toán muốn đổi ngày chứng từ; vận hành muốn giữ ngày giao hàng	Thuận tiện vận hành có thể làm sai kỳ ghi nhận	Ví dụ giao dịch tổng hợp, quy trình kế toán hiện hành, yêu cầu từ Accounting Owner	Accounting Owner; Legal Owner nếu có diễn giải pháp lý	Không gọi là yêu cầu bắt buộc khi chưa có xác nhận thẩm quyền
IT muốn dùng một trường status; nghiệp vụ cần phân biệt duyệt, giao, hủy	Mô hình đơn giản giảm công xây dựng; trạng thái gộp làm mất ý nghĩa kiểm soát	State diagram, báo cáo cần dùng, trường trong CANONICAL_DATA_DICTIONARY	Business Owner quyết định nghĩa nghiệp vụ; Architect quyết định thiết kế kỹ thuật	Tách “nghĩa nghiệp vụ cần giữ” khỏi “cách lưu kỹ thuật”
Người dùng yêu cầu hiển thị dữ liệu khách hàng rộng hơn	Tiện thao tác đối nghịch với tối thiểu hóa truy cập	Vai trò truy cập, loại dữ liệu, mục đích sử dụng, rủi ro	Security và Legal Owner; Business Owner xác nhận nhu cầu	Gắn Verification required; không tự kết luận tuân thủ pháp luật

Chất lượng bằng chứng quyết định theo thứ tự: nguồn chính thức hoặc artifact canonical có kiểm soát; dữ liệu vận hành tổng hợp có thể tái kiểm; quan sát được ghi ngày và người cung cấp; ý kiến chuyên gia; ý kiến cá nhân. Ý kiến chuyên gia vẫn chưa là quyết định nếu người nói không có thẩm quyền quyết định. Suy luận này dựa trên ranh giới của CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY: các artifact đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, nên không chứng minh APPROVED hoặc BASELINED.

Ngoại lệ với quy tắc “lấy Business Owner làm quyết định cuối” xuất hiện khi quyết định chạm ranh giới chuyên môn bắt buộc. Business Owner quyết định ưu tiên nghiệp vụ, nhưng không thay Legal Owner diễn giải Luật Bảo vệ dữ liệu cá nhân, không thay Accounting Owner xác nhận hạch toán theo Luật Kế toán, không thay Security quyết định kiểm soát truy cập, và không thay Architect quyết định kiến trúc. Nếu một yêu cầu đồng thời đổi quy trình giao hàng, cách ghi nhận doanh thu và quyền xem dữ liệu khách hàng, BA phải chia quyết định thành các phần thuộc đúng thẩm quyền; không gom thành một phiếu “đồng ý chung”.

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

flowchart TB
    A[Đề xuất thay đổi mô phỏng Nova Foods] --> B[BA tách fact, interpretation, assumption và decision]
    B --> C[Đánh giá chất lượng bằng chứng: canonical/chính thức; dữ liệu tổng hợp; quan sát; chuyên gia; ý kiến cá nhân]
    C --> D{Bằng chứng đủ mạnh?}
    D -->|Không| E[Gắn Verification required; ghi mức tin cậy thấp hơn]
    D -->|Có| F[Ghi mức tin cậy theo chất lượng bằng chứng]
    E --> G[Phân tích tác động nghiệp vụ, dữ liệu, kiểm soát]
    F --> G
    G --> H[Chia thay đổi thành từng phần quyết định]
    H --> I[Phân loại ranh giới và xác định owner cho từng phần]

    I --> J{Phần quyết định thuộc ranh giới nào?}
    J -->|Legal| K[Legal Owner quyết định phần diễn giải pháp lý]
    J -->|Accounting| L[Accounting Owner xác nhận phần hạch toán]
    J -->|Security| M[Security quyết định phần kiểm soát truy cập]
    J -->|Architecture| N[Architect quyết định phần kiến trúc]
    J -->|Ưu tiên hoặc quy trình nghiệp vụ| O[Business Owner quyết định nghiệp vụ]
    J -->|Truy vết| P[Business Owner quyết định vận hành]
    P --> Q[Domain Owner xác nhận yêu cầu truy vết]

    K --> R[Kết quả phần Legal]
    L --> S[Kết quả phần Accounting]
    M --> T[Kết quả phần Security]
    N --> U[Kết quả phần Architecture]
    O --> V[Kết quả phần nghiệp vụ]
    Q --> W{Đủ cả quyết định vận hành và xác nhận truy vết?}
    W -->|Có| X[Kết quả phần truy vết]
    W -->|Không| Y[Giữ IN_REVIEW cho phần truy vết]

    R --> Z[Tổng hợp các phần độc lập]
    S --> Z
    T --> Z
    U --> Z
    V --> Z
    X --> Z
    Y --> Z

    Z --> AA{Kết quả tương thích, đủ xác nhận bắt buộc và không có phần bị chặn?}
    AA -->|Không| AB[Giữ IN_REVIEW cho phần chưa giải quyết; chuyển đúng owner xử lý]
    AB --> I
    AA -->|Có| AC[Lập decision record]

    AC --> AD{Kiểm tra bằng chứng tương lai của artifact canonical}
    AD -->|Chưa có APPROVED hoặc BASELINED| AE[Giữ artifact IN_REVIEW; không suy diễn approval]
    AD -->|Có bằng chứng APPROVED hoặc BASELINED| AF[Ghi trạng thái theo bằng chứng artifact]
    AD -.-> AG[Hiện tại: CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY đều IN_REVIEW, v0.9.0, 2026-08-07]
    AG --> AE

Mâu thuẫn stakeholder không phải lỗi cần xóa ngay. Nó là tín hiệu có trade-off chưa được quyết định. Senior BA làm rõ: bên nào chịu hậu quả, hậu quả đo bằng gì, điều kiện nào đổi lựa chọn, và ai có quyền chấp nhận rủi ro. Ví dụ, “khóa sửa số lô” bảo vệ truy vết nhưng tăng số ticket sửa lỗi; phương án cân bằng có thể là không sửa trực tiếp, chỉ tạo giao dịch điều chỉnh có lý do và dấu vết. Đây là khuyến nghị thiết kế cho case mô phỏng, không phải quy tắc Nova Foods đã được phê duyệt.

Khi bằng chứng chưa đủ, câu viết phòng thủ được là: “Dựa trên sơ đồ trạng thái tổng hợp và nhu cầu truy vết do QA nêu, khuyến nghị không cho sửa trực tiếp số lô sau xác nhận nhập kho. Độ tin cậy: trung bình vì chưa có xác nhận domain owner. Điều kiện thay đổi: domain owner xác nhận quy trình điều chỉnh khác hoặc Legal Owner xác nhận nghĩa vụ liên quan. Quyết định cần: Business Owner và domain owner.” Câu này nêu cầu nối từ bằng chứng tới khuyến nghị, giới hạn độ chắc chắn, điều kiện đảo quyết định và đúng người cần quyết định; không bịa sự chắc chắn hoặc phê duyệt.

Senior Lens

Senior BA không dùng “ý kiến nhiều người” làm bằng chứng. Quy tắc thường dùng: chỉ chốt yêu cầu khi có nguồn gốc, phạm vi, chủ sở hữu quyết định và tác động kiểm tra được. Lý do: một yêu cầu có vẻ rõ nhưng không truy được nguồn hoặc thẩm quyền sẽ thành giả định, không phải quyết định. Trong Nova Foods mô phỏng, mọi dữ liệu là tổng hợp; trạng thái IN_REVIEW, phiên bản v0.9.0 ngày 2026-08-07 chưa là baseline hay phê duyệt.

Heuristic rà soát senior	Kiểm tra cụ thể	Red flag (dấu hiệu rủi ro)	Ngưỡng escalation	Không áp dụng quy tắc thường khi
Một nguồn chân lý	Rule, data field và process step phải trỏ về artifact canonical phù hợp	Cùng một mã, trạng thái hoặc công thức có hai giá trị khác nhau	Dừng phân tích chi tiết; chuyển xung đột tới owner của CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc TRACEABILITY_ID_REGISTRY	Khám phá ban đầu chưa có artifact canonical; ghi rõ là giả định dự án, không gọi là rule
Tách fact khỏi diễn giải	Fact có bằng chứng quan sát được; diễn giải nêu người suy luận và lý do	Câu “hệ thống phải” chỉ dựa vào trao đổi miệng hoặc sở thích cá nhân	Escalate khi diễn giải tạo chi phí, thay đổi kiểm soát, hoặc ảnh hưởng dữ liệu	Sự cố khẩn cấp có biện pháp tạm thời được owner vận hành ghi nhận; biện pháp vẫn cần review sau đó
Đúng người quyết định	Business Owner quyết định ưu tiên nghiệp vụ; Architect quyết định kiến trúc; Legal, Accounting, Security quyết định phạm vi chuyên môn	BA bị yêu cầu tự xác nhận tuân thủ, thuế, kế toán, bảo mật hoặc kiến trúc	Escalate ngay khi đề xuất chạm từ hai thẩm quyền chuyên môn trở lên	BA có thể đề xuất phương án và ghi tác động; không thay kết luận chuyên môn
Kiểm thử được	Mỗi quyết định phải có điều kiện, kết quả mong đợi và ngoại lệ đủ để QA suy ra test basis	“Nhanh”, “dễ dùng”, “an toàn” không có tiêu chí đo hoặc điều kiện	Escalate khi không thể viết acceptance criteria mà không tự bịa rule	Discovery chỉ nhằm thu thập vấn đề; giữ mô tả hiện trạng, chưa biến thành requirement
Tác động chéo được thấy	Kiểm tra process, dữ liệu, báo cáo, tích hợp, quyền truy cập và audit trail	Một thay đổi “nhỏ” sửa trạng thái nhưng không xét báo cáo hoặc interface	Escalate khi ảnh hưởng interface, dữ liệu lịch sử, phân quyền, tài chính, an toàn thực phẩm hoặc dữ liệu cá nhân	Prototype tách biệt, không dùng dữ liệu thật và không kết nối hệ thống khác; vẫn ghi giới hạn prototype

Ngưỡng escalation không dựa vào cấp bậc người phản đối. Escalate khi có mâu thuẫn bằng chứng, thiếu người có thẩm quyền, không xác định được hậu quả sai, hoặc yêu cầu bị diễn đạt thành nghĩa vụ pháp lý mà chưa có xác minh. Ví dụ, đề xuất lưu thông tin khách hàng lâu hơn để “tiện tra cứu” phải chuyển Legal Owner và Security Owner xem xét. Bằng chứng ở đây chỉ cho thấy có thay đổi lưu trữ và truy cập; bằng chứng đó không đủ để BA kết luận tuân thủ Luật Bảo vệ dữ liệu cá nhân hoặc Nghị định hướng dẫn.

Không áp dụng máy móc nguyên tắc “mọi yêu cầu cần chi tiết hoàn toàn trước khi làm”. Với rủi ro thấp, phạm vi đảo ngược được và không tác động dữ liệu, nhóm có thể ghi giả định có kiểm soát để tiếp tục discovery. Điều kiện bắt buộc: giả định nêu phạm vi, người cần xác minh, hạn xác minh theo Asia/Ho_Chi_Minh, và hậu quả nếu sai. Không dùng ngoại lệ này cho dữ liệu cá nhân, số liệu kế toán, hóa đơn chứng từ, truy xuất thực phẩm, quyền truy cập, tích hợp production hoặc quyết định không đảo ngược được.

Senior Lens

Senior BA không biến khoảng trống bằng chứng thành kết luận. Ghi tách: sự kiện là dữ liệu quan sát hoặc tài liệu truy vết được; giả định dự án là điều tạm dùng để phân tích; câu hỏi mở là điều chưa đủ chứng cứ; khuyến nghị là lựa chọn có điều kiện. Cầu nối suy luận phải nêu rõ: nguồn nào nói gì, nguồn đó đủ hay thiếu gì, thiếu đó ảnh hưởng quyết định nào.

Trường ghi nhận	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp
Vấn đề	Cần xác định thời điểm khóa phiếu xuất kho trước khi tạo hóa đơn.
Sự kiện	Mẫu luồng nghiệp vụ ghi nhận phiếu xuất kho có trạng thái POSTED; chưa có quy tắc canonical về thời điểm tạo hóa đơn. CANONICAL_BUSINESS_RULES có trạng thái IN_REVIEW, v0.9.0, chưa phải baseline.
Điều chưa biết	Chưa có xác nhận từ Business Owner và Accounting Owner về xử lý xuất từng phần, điều chỉnh hoặc hủy hóa đơn.
Rủi ro	Chọn thời điểm khóa sai có thể làm lệch tồn kho, doanh thu hoặc chứng từ mô phỏng. Diễn giải kế toán và hóa đơn cần Accounting Owner hoặc Legal Owner xác minh.
Khuyến nghị có điều kiện	Dùng POSTED làm điểm chặn kỹ thuật tạm thời cho bản phân tích, không gọi đây là quy tắc vận hành. Chỉ chuyển thành requirement khi Accounting Owner và Business Owner ghi quyết định trong artifact kiểm soát.
Mức tin cậy	Trung bình cho luồng kỹ thuật vì trạng thái đã xuất hiện trong mẫu; thấp cho tác động kế toán vì chưa có nguồn quyết định có thẩm quyền.
Quyết định cần có	Business Owner quyết định thời điểm nghiệp vụ; Accounting Owner xác nhận cách hạch toán; Legal Owner xác minh nghĩa vụ hóa đơn nếu áp dụng.
Traceability	Tham chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, /01-curriculum/TRACEABILITY_ID_REGISTRY.md; giữ trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.

Mẫu diễn đạt phòng review: “Dựa trên trạng thái POSTED trong tài liệu đầu vào, nhóm có cơ sở mô hình hóa điểm chặn kỹ thuật. Tuy nhiên, tài liệu chưa chứng minh đây là thời điểm ghi nhận doanh thu hoặc lập hóa đơn. Khuyến nghị dùng phương án này cho phân tích luồng, kèm giả định dự án và điểm quyết định dành cho Business Owner, Accounting Owner, Legal Owner. Không có xác nhận nào được ghi nhận tại thời điểm 2026-08-07.”

Không viết “đã tuân thủ”, “bắt buộc theo luật”, “được phê duyệt”, “đã baseline”, hoặc “Nova Foods áp dụng” khi chỉ có suy luận, nguồn tổng quan, hay dữ liệu mô phỏng. Với Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, Nghị định 356/2025/NĐ-CP và Luật An toàn thực phẩm, ghi Verification required nếu chưa có người có thẩm quyền xác minh văn bản hiện hành và khả năng áp dụng. Handbook này là học liệu Nova Foods mô phỏng, không thay thế thẩm quyền pháp lý, kế toán hoặc production.

12. Associated Template Reference & Completed Artifact

Core

Quick Reference là bảng tra nhanh để chọn đúng template trước khi BA ghi nội dung. Template là khuôn tệp có cấu trúc lặp lại; không phải nguồn chân lý cho rule, data hoặc ID. Bằng chứng: các nguồn canonical đã nêu tách riêng manifest template, registry ID, rule catalog và data dictionary. Vì vậy, BA chỉ dùng template đã đăng ký; không tự đặt Template ID, tên tệp, hoặc bản sao cục bộ.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Mọi dữ liệu là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Trạng thái corpus IN_REVIEW, version v0.9.0, ngày 2026-08-07; không phải baseline hay approval.

Applied

Thành phần	Nội dung
Facts	Nguồn đầu vào xác nhận TEMPLATE_MANIFEST là manifest quản trị template dự kiến. Compact dependency không cung cấp dòng đăng ký Template ID hoặc tên tệp template cụ thể cho chapter này.
Current Behavior	BA có thể cần tra template để ghi requirement, rule, data, traceability hoặc review, nhưng chưa được phép suy diễn template chưa đăng ký.
Underlying Need	Chọn đúng khuôn, đúng owner và đúng cổng chất lượng để tránh một bảng ghi đè nguồn canonical.
Options	Dùng artifact canonical làm tham chiếu; hoặc tự tạo template mới.
Decision Criteria	ID và filename phải có trong manifest; mục đích khớp loại nội dung; owner có thẩm quyền review; quality gate kiểm được traceability và source boundary.
Decision	Chỉ map các artifact được xác nhận trong dependency. Không tạo GEN-TMPL-* hay filename template mới vì không có đăng ký nguồn.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì manifest và metadata. Business Owner, Architect, QA Reviewer, Legal Owner, Accounting Owner, Security Owner xác minh nội dung thuộc chuyên môn của họ.
Artifact	/01-curriculum/TEMPLATE_MANIFEST.md là điểm tra đăng ký template. Các artifact canonical bên dưới là nguồn tham chiếu, không phải template thay thế.
Consequence if Wrong	Dùng ID tự đặt làm đứt traceability; dùng rule hoặc data không canonical tạo mâu thuẫn; gọi IN_REVIEW là approved tạo sai governance.

Senior Lens

Quality gate là điều kiện tối thiểu trước khi dùng template: kiểm đúng ID và filename trong /01-curriculum/TEMPLATE_MANIFEST.md; kiểm version v0.9.0 và trạng thái IN_REVIEW; kiểm consumer nhận đúng loại nội dung; kiểm liên kết tới nguồn canonical; giữ nhãn Verification required cho pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm, bảo mật hoặc quyết định production chưa có xác minh chuyên môn.

Quick Reference

Template ID / Artifact ID	Tệp canonical	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Cần xác minh template đã đăng ký, ID, filename, dependency và phạm vi dùng	Cần định nghĩa business rule, data field hoặc quyết định vận hành	Principal IT Business Analyst / Technical Curriculum Author	BA Author, QA Reviewer, Curriculum Reviewer	ID và filename phải khớp manifest; không suy diễn template chưa có dòng đăng ký
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm ID requirement, rule, data, test hoặc liên kết traceability	Cần tạo ID mới ngoài registry hoặc dùng làm rule catalog	Principal IT Business Analyst / Technical Curriculum Author	BA Author, QA Reviewer, Technical Architect	Giữ nguyên canonical ID; xung đột ID phải escalation
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Cần tham chiếu quy tắc nghiệp vụ đã catalog hóa	Cần diễn giải pháp lý, kế toán, thuế hoặc tự xác nhận rule vận hành	Principal IT Business Analyst / Technical Curriculum Author	Business Owner, BA Author, QA Reviewer	Rule phải giữ trạng thái nguồn; nội dung pháp lý/kế toán cần Verification required
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Cần kiểm tên dữ liệu logic, nghĩa, phân loại và liên kết data	Cần suy diễn schema vật lý, API payload hoặc quyền production	Principal IT Business Analyst / Technical Curriculum Author	BA Author, Data/Technical Reviewer, QA Reviewer	Tên field và nghĩa phải khớp canonical; dữ liệu cá nhân cần Security Owner và Legal Owner xác minh
CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Cần kiểm chapter scope, filename và dependency	Cần coi chapter entry là baseline hoặc approval	Principal IT Business Analyst / Technical Curriculum Author	Handbook Author, Curriculum Reviewer, QA Reviewer	Đúng chapter, đúng filename, đúng dependency; IN_REVIEW không đổi thành APPROVED

Quick Reference

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Artifact đã điền cho chương này nằm tại /02-handbook/01-ba-role-lifecycle-and-governance.md, mục 12. Associated Template Reference & Completed Artifact. Đây là vị trí tra cứu kết quả đã ghi trong handbook, không phải registry canonical, không phải baseline, không phải approval.

Kiểm tra	Vị trí tra cứu	Kết quả phải xác nhận
Đúng chapter và tệp	/02-handbook/01-ba-role-lifecycle-and-governance.md	Tên tệp, 12 H2 và thứ tự H2 không đổi
Đúng trạng thái quản trị	CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	IN_REVIEW, v0.9.0, ngày 2026-08-07
Đúng ID và đường dẫn tham chiếu	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Không tự tạo ID hoặc đổi canonical ID
Đúng quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Chỉ tham chiếu rule đã đăng ký; rule chưa xác minh giữ nhãn Verification required
Đúng dữ liệu logic	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Không biến ví dụ dữ liệu tổng hợp thành cấu hình ERP thực
Đúng nguồn và ranh giới nguồn	00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md	Không gọi nguồn học thuật, chuẩn, luật là approval Nova Foods
Đúng catalog template dự kiến	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Chỉ tra ID, tệp và phạm vi đã đăng ký; không chép toàn bộ manifest vào chapter

Checklist tra cứu đủ 12 phần chapter:

#	H2 cần có	Mục đích kiểm tra
1	1. Concept l? g??	Định nghĩa vai trò BA và ranh giới trách nhiệm
2	2. T?i sao concept n?y t?n t?i?	Lý do lifecycle và governance cần tồn tại
3	3. V? tr? trong Lifecycle	Vị trí BA trong chuỗi khám phá đến bàn giao
4	4. Input c?n thi?t	Đầu vào, nguồn và điều kiện dùng đầu vào
5	5. Step-by-step BA Activities	Hoạt động BA theo bước và traceability
6	6. Output thu ???c	Output, giới hạn và bằng chứng tạo output
7	7. Who consumes those outputs?	Vai trò nhận, dùng và phản hồi output
8	8. Detailed Worked Example	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp
9	9. Related Concepts & Dependencies	Dependency với rule, data, test, architecture
10	10. Common Mistakes & Anti-patterns	Sai lầm, hậu quả và cách nhận biết
11	11. Senior BA Notes & Rules of Thumb	Phán đoán senior, ranh giới thẩm quyền
12	12. Associated Template Reference & Completed Artifact	Tra cứu template liên quan và artifact đã điền

Bằng chứng cho việc dùng checklist này: CHAPTER_MANIFEST là manifest kiểm soát chapter; TEMPLATE_MANIFEST chỉ là danh mục template dự kiến; các catalog canonical giữ source of truth riêng. Vì vậy chapter chỉ ghi đường dẫn tra cứu và vị trí artifact đã điền, không sao chép registry, không tạo nguồn chân lý thứ hai.

Core

Rà soát liên tệp là kiểm tra cùng một факт mô phỏng Nova Foods có giữ nguyên định danh, trạng thái, nguồn và giới hạn thẩm quyền giữa các artifact hay không. Mục tiêu không phải tìm lỗi văn phong; mục tiêu là chặn một nội dung IN_REVIEW bị diễn đạt thành đã baseline, đã phê duyệt, tuân thủ pháp luật hoặc sẵn sàng production. Bằng chứng: mọi artifact nguồn đều ghi IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND, và Nova Foods là case mô phỏng dùng dữ liệu tổng hợp. Suy ra mọi khác biệt với các giá trị này phải dừng handoff để làm rõ.

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

flowchart TB
    A[Rà soát liên tệp] --> B[So khớp ID, trạng thái IN_REVIEW và version v0.9.0]
    B --> C[So khớp ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và VND]
    C --> D[So khớp Nova Foods là case mô phỏng dùng dữ liệu tổng hợp]
    D --> E[Kiểm tra không diễn đạt IN_REVIEW thành baseline, phê duyệt, tuân thủ pháp luật hoặc sẵn sàng production]
    E --> F{Mọi định danh, trạng thái, nguồn và giới hạn thẩm quyền có nhất quán?}
    F -- Có --> G[Handoff ở trạng thái IN_REVIEW]
    F -- Không --> H[Dừng handoff để làm rõ khác biệt]

Applied

Facts: Chapter /02-handbook/01-ba-role-lifecycle-and-governance.md đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Artifact phụ thuộc gồm /00-research/00_SOURCE_MAP.md, /01-curriculum/01_CURRICULUM_ARCHITECTURE.md, /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, và /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Current Behavior: Các artifact xác nhận metadata quản trị và ranh giới nguồn; không artifact nào được cung cấp xác nhận baseline, approval, cấu hình ERP thật, nghĩa vụ pháp lý đã diễn giải, hay quyết định vận hành Nova Foods.

Underlying Need: Handoff chapter cần giữ traceability, tức khả năng lần ngược từ nội dung về artifact nguồn và thẩm quyền kiểm tra. Nếu không, người học có thể nhầm ví dụ tổng hợp thành quy tắc triển khai thật.

Options: (1) Handoff không rà soát; nhanh nhưng mất bằng chứng. (2) Rà soát metadata riêng; phát hiện lệch tên hoặc phiên bản nhưng bỏ sót claim vượt thẩm quyền. (3) Rà soát metadata, source boundary, thẩm quyền và issue log; đủ cho trạng thái IN_REVIEW.

Decision Criteria: Không đổi canonical ID hoặc path; không tạo approval ngầm định; phân biệt “project assumption” với “Verification required”; escalation có owner chuyên môn rõ; không chặn việc học vì câu hỏi chưa cần quyết định.

Decision: Chọn phương án 3. Handoff chỉ kèm kết quả rà soát và issue log; không tuyên bố chapter được phê duyệt.

Authority: Principal IT Business Analyst / Technical Curriculum Author điều phối review và duy trì traceability. Legal Owner, Accounting Owner, Security Owner, Architect, Business Owner, QA Reviewer giữ thẩm quyền kết luận theo lĩnh vực.

Artifact: Bảng kiểm dưới đây là bằng chứng rà soát cho chapter, không thay thế canonical registry hoặc nguồn pháp lý.

Consequence if Wrong: Sai ID làm đứt traceability. Sai trạng thái làm phát sinh approval ngầm định. Diễn giải sai nguồn pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm có thể khiến học liệu bị hiểu nhầm là chỉ dẫn production.

Hạng mục liên tệp	Bằng chứng kiểm tra	Kết quả hiện tại	Hành động trước handoff
Danh tính artifact	ID, path, title giữ nguyên theo manifest	Cần đối chiếu khi hợp nhất chapter	Không tự đổi tên hoặc tạo ID mới
Trạng thái và phiên bản	IN_REVIEW; v0.9.0; 2026-08-07	Phù hợp nguồn đã cấp	Giữ nguyên; không dùng APPROVED hoặc BASELINED
Bối cảnh Nova Foods	Mô phỏng giáo dục, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND	Phù hợp nguồn đã cấp	Gắn nhãn mô phỏng khi có ví dụ
Nguồn và tiêu chuẩn	00_SOURCE_MAP phân loại nguồn và safe use boundary	Cần kiểm tra từng claim chuyên ngành	Không bịa trang, điều khoản, trích dẫn hoặc nghĩa vụ
Định danh và truy vết	TRACEABILITY_ID_REGISTRY là nguồn canonical cho ID	Không có ID mới trong lô này	Escalate nếu nội dung cần ID chưa đăng ký
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES là nguồn canonical	Không suy diễn rule vận hành	Gắn project assumption hoặc Verification required
Dữ liệu logic	CANONICAL_DATA_DICTIONARY là nguồn canonical	Không suy diễn schema hay field production	Escalate khi cần định nghĩa dữ liệu
Template liên quan	TEMPLATE_MANIFEST chỉ là kế hoạch controlled	Không xác nhận template đã được phê duyệt	Không gọi template là baseline

Senior Lens

Open issue không phải lỗi bị che đi; đó là câu hỏi có ảnh hưởng nhưng chưa có bằng chứng hoặc thẩm quyền kết luận. Verification required dùng khi claim có thể kiểm tra bằng nguồn hoặc review chuyên môn nhưng hiện chưa được xác minh. Cả hai nhãn phải đi cùng phạm vi và owner; không dùng nhãn mơ hồ như “cần xem lại”.

Loại	Vấn đề mở hoặc mục cần xác minh	Lý do và bằng chứng	Escalation owner	Điều kiện đóng
Governance	Chưa có baseline reference hoặc approval reference cho chapter và artifact phụ thuộc	Các manifest nêu rõ IN_REVIEW không đồng nghĩa baseline hay approval	Principal IT Business Analyst / Technical Curriculum Author	Có tham chiếu baseline hoặc approval được ghi trong artifact kiểm soát
Legal/privacy	Bất kỳ requirement nào suy ra từ Luật 91/2025/QH15 hoặc Nghị định 356/2025/NĐ-CP	Source seed yêu cầu legal-owner verification cho requirement suy ra từ luật	Legal Owner	Legal Owner xác nhận diễn giải, phạm vi và nhãn áp dụng
Accounting/tax	Bất kỳ rule về hạch toán, thuế, hóa đơn hoặc chứng từ	Luật Kế toán và Nghị định 123/2020/NĐ-CP không tự tạo diễn giải nghiệp vụ ERP	Accounting Owner	Accounting Owner xác nhận nội dung; Legal Owner kiểm tra khi có diễn giải pháp lý
Food safety	Bất kỳ claim về truy xuất hoặc thu hồi thực phẩm	Luật An toàn thực phẩm cần domain-owner và legal verification	Business Owner và Legal Owner	Hai owner ghi nhận kết luận phù hợp phạm vi mô phỏng
Security/API	Bất kỳ control về phân quyền, API, dữ liệu cá nhân hoặc OWASP	OWASP là good practice; không phải xác nhận tuân thủ pháp lý	Security Owner và Architect	Security Owner xác nhận control; Architect xác nhận khả thi kỹ thuật
Quality	Claim rằng artifact “đủ chất lượng”, “đã test” hoặc “sẵn sàng giao”	IN_REVIEW chưa là bằng chứng quality sign-off	QA Reviewer	QA Reviewer ghi kết quả review và phạm vi kiểm tra
Requirement ownership	Quy tắc Nova Foods bị trình bày như quyết định nghiệp vụ thật	Case study chỉ dùng dữ liệu tổng hợp, không có quyết định vận hành thật	Business Owner	Business Owner xác nhận đây là assumption mô phỏng hoặc cung cấp quyết định được kiểm soát