16 Solution Options Tradeoffs And Recommendations

Trường quản trị	Giá trị
Tệp được kiểm soát	/02-handbook/16-solution-options-tradeoffs-and-recommendations.md
Tiêu đề tài liệu	16 Solution Options Tradeoffs And Recommendations
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN
Bối cảnh quốc gia	Việt Nam
Đơn vị 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 nguồn	Handbook chapter; tham chiếu quản trị từ CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY
Traceability nguồn	/01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md
Baseline	Chưa có baseline reference tại v0.9.0
Approval	Chưa có approval reference. IN_REVIEW không nghĩa là được phê duyệt, sẵn sàng production, compliant, hay được người dùng chấp thuận.
Giới hạn thẩm quyền	Nội dung là học liệu BA. Không tạo quyết định vận hành, kiến trúc, pháp lý, kế toán, thuế, bảo mật hoặc triển khai ERP thực tế.

1. Concept l? g??

Core

Solution options, tradeoffs and recommendations là hoạt động BA biến một nhu cầu đã hiểu thành các lựa chọn có thể so sánh, rồi đề xuất lựa chọn phù hợp nhất theo tiêu chí minh bạch. Đây không phải hoạt động “chọn công nghệ mình thích”. Đây là cách giúp người có thẩm quyền thấy rõ: mỗi lựa chọn giải quyết vấn đề nào, phải đánh đổi gì, bằng chứng nào hỗ trợ nhận định, và hậu quả nào có thể phát sinh.

Từ gốc, một solution option là phương án giải pháp. Phương án có thể là thay đổi quy trình, cấu hình ERP, dùng chức năng sẵn có, tích hợp hệ thống, phát triển thêm, hoặc giữ nguyên hiện trạng. Một phương án chỉ có ý nghĩa khi liên kết được với nhu cầu cần giải quyết. Ví dụ, “thêm màn hình mới” là ý tưởng kỹ thuật; nó chưa là phương án BA đầy đủ nếu chưa nêu nhu cầu, phạm vi tác động, chi phí, rủi ro và kết quả mong đợi.

Tradeoff là đánh đổi giữa các giá trị không thể cùng tối đa. Một phương án có thể triển khai nhanh nhưng ít linh hoạt. Phương án khác linh hoạt hơn nhưng tốn chi phí, tăng rủi ro vận hành hoặc kéo dài thời gian kiểm thử. BA không che giấu đánh đổi bằng kết luận chung chung như “phương án tốt nhất”. BA ghi rõ tiêu chí, bằng chứng và tác động để quyết định có thể được kiểm tra lại.

Recommendation là khuyến nghị có căn cứ. Khuyến nghị không phải phê duyệt, không thay thế quyết định của Business Owner, Architect, Security, Legal, Accounting hoặc vai trò có thẩm quyền khác. Khuyến nghị phải nêu phương án được đề xuất, lý do chọn, điều kiện áp dụng, rủi ro còn lại và điểm cần xác minh. Nếu bằng chứng thiếu, kết luận đúng là giữ trạng thái cần xác minh, không biến giả định thành sự thật.

Chuỗi tư duy tối thiểu là: nhu cầu tạo ra các phương án; tiêu chí dùng để so sánh phương án; đánh đổi giải thích phần mất khi chọn; khuyến nghị ghi nhận lựa chọn đề xuất cùng lý do. Chuỗi này tạo decision traceability, nghĩa là truy vết quyết định: người đọc sau này có thể lần từ khuyến nghị về tiêu chí, từ tiêu chí về nhu cầu, rồi về bằng chứng nguồn. Không có truy vết này, quyết định dễ thành ý kiến cá nhân và khó kiểm soát khi phạm vi thay đổi.

Chương này chỉ xử lý cách BA cấu trúc, so sánh và khuyến nghị lựa chọn. Chương không tự xác nhận yêu cầu Nova Foods là đúng, không tự cấp approval, không tự chọn kiến trúc production, không diễn giải nghĩa vụ pháp lý, và không xác nhận cấu hình ERP thực tế. Các kết luận cho Nova Foods chỉ là mô phỏng giáo dục dựa trên dữ liệu tổng hợp; nội dung cần thẩm quyền chuyên môn phải giữ nhãn Verification required cho đến khi vai trò phù hợp xác minh.

Thuật ngữ cốt lõi của quyết định giải pháp

Thuật ngữ	Nghĩa Việt ngắn	Vai trò trong phân tích lựa chọn
Solution option	Phương án giải pháp	Một cách khả thi để đáp ứng nhu cầu, như cấu hình ERP, thay đổi quy trình, báo cáo, tích hợp hoặc giữ nguyên hiện trạng. Phương án không tự là quyết định.
Trade-off	Đánh đổi	Lợi ích nhận được khi chọn phương án đi cùng chi phí, rủi ro, giới hạn hoặc lợi ích bị bỏ. Ví dụ giảm thao tác tay có thể tăng chi phí tích hợp.
Recommendation	Khuyến nghị	Đề xuất BA có lập luận: chọn, không chọn, hoặc cần xác minh thêm. Khuyến nghị không thay thế quyết định của người có thẩm quyền.
Actor	Tác nhân thực hiện hoặc chịu tác động	Người, vai trò, hệ thống hoặc tổ chức làm hành động. Ví dụ Nhân viên kho, ERP, Business Owner. Ghi vai trò thay vì tên cá nhân để phân tích còn dùng được khi đổi nhân sự.
Action	Hành động	Việc actor làm với đối tượng. Dùng động từ kiểm chứng được: tạo, duyệt, đối soát, gửi, chặn, lưu. Tránh từ mơ hồ như “xử lý phù hợp”.
Object	Đối tượng bị tác động	Thứ action xử lý: phiếu nhập kho, lô hàng, đơn bán, dữ liệu tồn kho, API. Object cần đủ cụ thể để xác định dữ liệu và phạm vi thay đổi.
Outcome	Kết quả đầu ra hoặc trạng thái đạt được	Kết quả quan sát được sau action. Ví dụ “ERP tạo phiếu nhập kho ở trạng thái Posted”. Outcome khác action: “duyệt phiếu” là action; “phiếu được duyệt” là outcome.
Decision criteria	Tiêu chí quyết định	Thước đo dùng so sánh phương án cùng một chuẩn: đáp ứng nhu cầu, chi phí, thời gian, rủi ro, khả năng vận hành, bảo mật, khả năng kiểm thử.
Constraint	Ràng buộc	Giới hạn bắt buộc không được vượt, như ngân sách đã cấp, nền tảng ERP hiện có, quyền truy cập, hoặc nghĩa vụ cần xác minh. Ràng buộc không phải sở thích.
Assumption	Giả định dự án	Điều được tạm coi đúng để tiếp tục phân tích nhưng chưa có bằng chứng đủ. Phải gắn nguồn xác minh hoặc người xác minh; không biến giả định thành fact.
Evidence	Bằng chứng	Dữ liệu, quan sát quy trình, artifact, hoặc nguồn đáng tin cậy hỗ trợ nhận định. Bằng chứng nối từ fact đến kết luận, tránh chọn giải pháp theo cảm tính.
ERP	Enterprise Resource Planning — hệ thống hoạch định nguồn lực doanh nghiệp	Hệ thống quản lý dữ liệu và quy trình liên phòng ban. Trong Nova Foods, ERP là bối cảnh mô phỏng, không xác nhận cấu hình hệ thống thật.

Mẫu câu phân tích tối thiểu: Actor thực hiện Action lên Object để tạo Outcome. Câu này buộc BA nêu rõ ai làm gì, với cái gì, đạt kết quả nào; thiếu một phần thì chưa đủ dữ liệu để so sánh giải pháp.

Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp: Nhân viên kho (actor) ghi nhận (action) số lượng lô thành phẩm nhập kho (object) để ERP cập nhật tồn kho khả dụng cho lô đó (outcome). Từ câu này, BA có thể so sánh phương án nhập tay trên ERP với phương án nhận dữ liệu từ thiết bị quét. Bằng chứng cần tìm là tần suất nhập, lỗi ghi nhận, thời gian xử lý và khả năng truy vết; không được suy ra phương án tốt hơn khi chưa có các bằng chứng đó.

Ranh giới khái niệm: phân tích phương án xác định lựa chọn và đánh đổi dựa trên nhu cầu, bằng chứng, tiêu chí. Nó không tự tạo business rule, không tự phê duyệt ngân sách, không quyết định kiến trúc, không xác nhận tuân thủ pháp lý, kế toán, an toàn thực phẩm hay bảo mật. Nova Foods chỉ là case study giáo dục; mọi dữ liệu là tổng hợp, trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, số liệu và giao dịch dưới đây là dữ liệu tổng hợp.

Mục	Nội dung
Facts	Kho nguyên liệu ghi nhận lô RM-SUGAR-260807-01 thiếu 500 kg so với phiếu nhận hàng mô phỏng GRN-SIM-260807-01. Giá trị chênh lệch giả định: 7.500.000 VND.
Current Behavior	Nhân viên kho sửa trực tiếp số lượng đã nhận trong ERP sau khi trao đổi bằng điện thoại với mua hàng. Hệ thống không giữ lý do sửa, người sửa hoặc chứng từ đối chiếu.
Underlying Need	Nova Foods cần chọn cách xử lý chênh lệch nhận hàng: cho phép sửa ngay, chờ xác minh, hay tạo giao dịch điều chỉnh có truy vết. Nhu cầu là kiểm soát quyết định, không phải mặc định chọn tính năng ERP.
Actor	Actor là vai trò khởi tạo, xem xét hoặc quyết định hành động. Ví dụ: Nhân viên kho ghi nhận chênh lệch; Trưởng kho xác minh; Business Owner quyết định quy tắc vận hành.
Action	Action là việc có chủ đích tác động lên đối tượng. Ví dụ: tạo bản ghi chênh lệch, khóa chỉnh sửa trực tiếp, hoặc gửi yêu cầu xác minh.
Object	Object là đối tượng bị tác động. Ví dụ: số lượng nhận của GRN-SIM-260807-01, lô hàng và trạng thái phiếu nhận.
Outcome	Outcome là kết quả đo được sau hành động. Ví dụ: số lượng sổ kho khớp chứng từ đã xác minh và có lịch sử truy vết.
Options	O1: cho phép sửa trực tiếp. O2: khóa sửa sau ghi nhận, tạo yêu cầu điều chỉnh. O3: tự động chấp nhận số lượng phiếu mua hàng.
Decision Criteria	Truy vết người và lý do; giảm sai lệch tồn kho; thời gian xử lý; khả năng đối chiếu chứng từ; mức ảnh hưởng tới quy trình mua hàng và kho.
Decision	Với dữ kiện mô phỏng, O2 là khuyến nghị BA: giữ bản ghi nhận ban đầu, tạo giao dịch điều chỉnh riêng sau xác minh. Lý do: O2 tạo bằng chứng cho số liệu trước và sau thay đổi; O1 mất dấu thay đổi; O3 bỏ qua số lượng thực nhận. Đây là khuyến nghị học liệu, chưa phải quyết định vận hành.
Authority	Business Owner quyết định quy trình nghiệp vụ; Accounting Owner và Legal Owner xác minh tác động kế toán, chứng từ và nghĩa vụ liên quan; Solution Architect xác nhận khả năng ERP; QA xác nhận tiêu chí kiểm thử. BA phân tích lựa chọn và ghi traceability, không tự phê duyệt.
Artifact	Bảng lựa chọn giải pháp, tiêu chí đánh giá, quyết định có thẩm quyền và liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY. Các artifact này đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không là baseline hay approval.
Consequence if Wrong	Nếu chọn O1 khi cần truy vết, tồn kho mô phỏng có thể đúng số cuối nhưng không giải thích được ai đổi, đổi vì sao và dựa trên chứng từ nào. Nếu chọn O3, hệ thống có thể ghi nhận số mua thay vì số thực nhận, làm sai dữ liệu kho.

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

flowchart TB
    N[Nhu cầu: xử lý chênh lệch nhận hàng<br/>có kiểm soát và truy vết]

    subgraph S1[So sánh phương án theo tiêu chí quyết định]
        O1[O1 — Cho phép sửa trực tiếp<br/>Nhanh, ít ảnh hưởng quy trình<br/>Mất truy vết người, lý do và chứng từ<br/>Rủi ro sai lệch khó giải thích]
        O2[O2 — Khóa sửa sau ghi nhận<br/>Tạo giao dịch điều chỉnh riêng<br/>Truy vết và đối chiếu tốt hơn<br/>Xử lý lâu hơn, ảnh hưởng quy trình kho và mua hàng]
        O3[O3 — Tự động nhận số lượng phiếu mua hàng<br/>Xử lý nhanh<br/>Bỏ qua số lượng thực nhận<br/>Rủi ro sai tồn kho và khó đối chiếu]
    end

    N --> O1
    N --> O2
    N --> O3

    O1 --> R[BA khuyến nghị O2 dựa trên dữ kiện mô phỏng<br/>BA ghi traceability, không tự phê duyệt<br/>Khuyến nghị chưa phải quy tắc hay workflow có hiệu lực]
    O2 --> R
    O3 --> R

    R --> AR[Artifact liên kết:<br/>CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY<br/>TRACEABILITY_ID_REGISTRY<br/>IN_REVIEW · v0.9.0 · 2026-08-07<br/>Chưa baseline hoặc approval]
    R --> BO[Business Owner xem xét và quyết định<br/>Accounting Owner và Legal Owner xác minh tác động thuộc thẩm quyền<br/>Solution Architect xác nhận khả năng ERP<br/>QA xác nhận tiêu chí kiểm thử]
    BO --> P[Trạng thái hiện tại: chờ quyết định vận hành]

    R -. Luồng đề xuất nếu O2 được phê duyệt .-> A[Nhân viên kho ghi nhận thực nhận 9.500 kg<br/>Giữ nguyên bản ghi nhận ban đầu]
    A --> B{Khớp số lượng trên phiếu nhận hàng<br/>GRN-SIM-260807-01?}
    B -- Có --> C[Kết thúc đối chiếu<br/>Không tạo giao dịch điều chỉnh]
    B -- Không --> D[Nhân viên kho tạo bản ghi chênh lệch<br/>500 kg · 7.500.000 VND]
    D --> E[Trưởng kho xác minh chứng từ]
    E --> F{Đủ chứng từ và chênh lệch<br/>được xác minh?}
    F -- Không --> G[Giữ trạng thái chờ xác minh<br/>Không điều chỉnh số lượng sổ kho]
    F -- Có --> H[Vai trò thực hiện do Business Owner quyết định<br/>Ghi giao dịch điều chỉnh riêng kèm lý do]
    H --> I[Giữ nguyên bản ghi nhận ban đầu<br/>Số lượng sổ kho thay đổi qua giao dịch điều chỉnh]

Ranh giới concept: Solution options, tradeoffs and recommendations là hoạt động BA so sánh các cách đáp ứng một nhu cầu, nêu tiêu chí, bằng chứng, tác động và thẩm quyền quyết định. Concept này kết thúc ở khuyến nghị có truy vết; không tự biến khuyến nghị thành cấu hình ERP, quy tắc đã phê duyệt, quyết định kế toán, kết luận pháp lý hoặc thay đổi production.

Loại trừ: Không thiết kế màn hình; không viết API; không cấu hình workflow; không xác nhận tuân thủ Luật Kế toán, hóa đơn, bảo vệ dữ liệu cá nhân hay an toàn thực phẩm. Các kết luận pháp lý, kế toán và compliance cần chủ sở hữu thẩm quyền xác minh.

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

Core

Solution options, tradeoffs and recommendations tồn tại để BA không biến nhu cầu chưa rõ thành một cách làm mặc định. Option là phương án đáp ứng nhu cầu. Tradeoff là đánh đổi: phương án tăng lợi ích này nhưng có thể tăng chi phí, rủi ro, thời gian hoặc phụ thuộc. Recommendation là khuyến nghị có lý do, không phải quyết định tự phê duyệt.

Không so sánh phương án, dự án dễ thất bại theo bốn dạng:

Rủi ro	Cơ chế gây lỗi	Hậu quả quan sát được
Chọn sớm	Nhóm kỹ thuật bắt đầu từ giải pháp quen thuộc trước khi chốt nhu cầu	Requirement bị ép theo chức năng sẵn có thay vì mục tiêu nghiệp vụ
Rework	Phương án thiếu tác động dữ liệu, quy trình hoặc kiểm thử	Cấu hình, tài liệu và test case phải sửa khi phát hiện ngoại lệ
Mơ hồ	Không ghi tiêu chí chọn và giới hạn từng phương án	Các bên dùng cùng từ nhưng hiểu khác nhau về “đủ”, “đúng”, “có kiểm soát”
Rủi ro governance	Không nêu người có thẩm quyền quyết định	Khuyến nghị BA bị hiểu nhầm là phê duyệt nghiệp vụ, kế toán, pháp lý hoặc kiến trúc
Mất traceability	Quyết định không liên kết nhu cầu, rule, dữ liệu và bằng chứng	Không giải thích được vì sao hệ thống hoạt động theo cách đã chọn

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Khi cần xử lý chênh lệch số lượng nhận hàng, một nhóm có thể đề xuất “cho nhân viên kho sửa số lượng”. Đề xuất này chưa đủ để triển khai vì chưa trả lời: sửa trực tiếp hay tạo giao dịch điều chỉnh, cần lý do nào, ai xác minh, dữ liệu nào phải lưu, và phương án nào bảo toàn truy vết.

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

flowchart TB
    A[Nhu cầu: xử lý chênh lệch nhận hàng] --> B[Liệt kê phương án]
    B --> C[Sửa trực tiếp số lượng]
    B --> D[Tạo giao dịch điều chỉnh]

    C --> E[Đánh giá từng phương án: lý do, dữ liệu lưu, khả năng bảo toàn truy vết]
    D --> E

    E --> F[Sửa trực tiếp: rủi ro mất dấu vết thay đổi]
    E --> G[Điều chỉnh: cần lưu người thực hiện, thời điểm, lý do và chứng từ]
    F --> H[Xác định người xác minh và vai trò có thẩm quyền]
    G --> H
    H --> I[Khuyến nghị: tạo giao dịch điều chỉnh có đủ dữ liệu truy vết]
    I --> J[Quyết định được ghi nhận bởi vai trò có thẩm quyền]

Nếu bỏ bước đánh giá, nhóm có thể chọn sửa trực tiếp vì nhanh. Hệ quả là dữ liệu cuối có thể khớp vật lý nhưng không còn dấu vết giải thích thay đổi, người thực hiện, thời điểm, lý do và chứng từ liên quan. Đây là lỗi kiểm soát dữ liệu, không phải chỉ lỗi màn hình.

Senior Lens

Khuyến nghị tốt không cố trả lời thay người có thẩm quyền. BA phải tách ba việc: mô tả nhu cầu, phân tích phương án, ghi quyết định. Ví dụ, BA có thể nêu rằng phương án có giao dịch điều chỉnh giữ được lịch sử tốt hơn phương án sửa trực tiếp. BA không được tự kết luận phương án đó đáp ứng nghĩa vụ kế toán, truy xuất thực phẩm, hóa đơn hay bảo vệ dữ liệu cá nhân. Các kết luận này cần Accounting Owner, Legal Owner, Compliance Owner hoặc vai trò thẩm quyền phù hợp xác minh.

IN_REVIEW, v0.9.0, ngày 2026-08-07 là trạng thái quản trị corpus. Chúng không là baseline, approval hay quyền triển khai production.

Quick Reference

Quy tắc	Áp dụng
Không có nhu cầu rõ thì không khuyến nghị giải pháp	Tránh chọn công cụ trước mục tiêu
Mỗi phương án phải nêu lợi ích, chi phí và rủi ro	Làm tradeoff kiểm tra được
Mỗi khuyến nghị phải nêu tiêu chí và bằng chứng	Giảm tranh cãi dựa trên ý kiến
Mỗi quyết định phải có vai trò thẩm quyền	Ngăn BA bị gán quyền phê duyệt
Mỗi lựa chọn phải liên kết artifact canonical khi có	Giữ traceability với CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY

Core

Đối chiếu trước/sau biến lựa chọn giải pháp từ ý kiến rời rạc thành thay đổi có thể quan sát. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu dưới đây là tổng hợp. “Quan sát được” nghĩa là người review nhìn thấy khác biệt trong luồng xử lý, trạng thái đơn hàng, dữ liệu lưu hoặc artifact; không dùng tỷ lệ, thời gian hay số tiền không có nguồn.

Applied

Mục	Trước khi so sánh lựa chọn	Sau khi ghi nhận lựa chọn
Facts	IN_REVIEW, v0.9.0, ngày 2026-08-07; chưa có baseline hay approval.	Giữ nguyên trạng thái quản trị; artifact ghi rõ lựa chọn chỉ là nội dung mô phỏng đang review.
Current Behavior	Nhân viên bán hàng ghi yêu cầu giao gấp trong ghi chú đơn bán. Kho chưa thấy yêu cầu này khi tạo phiếu xuất.	ERP hiển thị trường Delivery Priority trên đơn bán và chuyển giá trị sang danh sách xử lý kho.
Underlying Need	Kho cần biết đơn nào cần ưu tiên trước khi chọn hàng, không phải đọc ghi chú tự do.	Nhu cầu được biểu diễn thành dữ liệu có cấu trúc, đủ cho kho lọc và xử lý.
Options	1. Giữ ghi chú tự do. 2. Thêm trường chọn Normal hoặc Urgent trên đơn bán.	So sánh dựa trên khả năng nhìn thấy tại kho, khả năng lọc, truy vết nguồn yêu cầu, tác động cấu hình ERP.
Decision Criteria	Không mất thông tin ưu tiên; kho nhìn thấy trước khi xuất; không tự diễn giải chữ viết; thay đổi không tạo quy tắc pháp lý hoặc kế toán.	Phương án 2 đáp ứng tiêu chí vì giá trị chọn có cấu trúc và xuất hiện trong luồng kho.
Decision	Chưa có quyết định được phê duyệt. Ví dụ học liệu đề xuất phương án 2 để làm rõ hậu quả có thể kiểm tra.	Artifact phải ghi phương án, tiêu chí và người có thẩm quyền quyết định; không gọi đề xuất là cấu hình đã triển khai.
Authority	Business Owner xác nhận ý nghĩa nghiệp vụ của Urgent; Architect xác nhận điểm tích hợp; QA xác nhận hành vi kiểm thử.	BA duy trì so sánh và traceability, không thay các vai trò trên quyết định.
Artifact	Ghi chú rời trong đơn bán không tạo nguồn chân lý ổn định.	Bảng đánh giá phương án liên kết requirement, quyết định và test basis trong artifact kiểm soát.
Consequence if Wrong	Kho có thể xuất đơn thường trước đơn gấp vì không thấy ưu tiên. Người review không xác định được lỗi nằm ở nhập liệu, hiển thị hay quy tắc xử lý.	Nếu chọn trường nhưng không chuyển sang kho, người dùng thấy ưu tiên tại bán hàng nhưng kho vẫn không có dữ liệu để hành động.

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

flowchart TB
    A[Đơn bán: yêu cầu giao gấp trong ghi chú tự do] --> B[Danh sách kho: không có cột ưu tiên]
    B --> C[Kho không nhận được thông tin ưu tiên]
    C --> D[Rủi ro: xuất đơn thường trước đơn gấp]

    subgraph R[Phương án đề xuất đang review]
        E[Đơn bán: Delivery Priority = Urgent hoặc Normal] --> F[Chuyển Delivery Priority sang danh sách xử lý kho]
        F --> G{Danh sách kho nhận Delivery Priority?}
        G -->|Có| H[Danh sách kho hiển thị Delivery Priority]
        H --> I[Kho lọc và chọn đơn xử lý]
        H --> K[Reviewer đối chiếu Delivery Priority giữa đơn bán và danh sách kho]
        G -->|Không| J[Rủi ro: bán hàng có ưu tiên, kho không có dữ liệu hành động]
    end

Hậu quả trước: cùng một yêu cầu “giao gấp” tồn tại trong ghi chú, nhưng danh sách kho không có cột tương ứng; việc ưu tiên phụ thuộc người đọc nhớ và diễn giải. Hậu quả sau: danh sách kho có giá trị Urgent hoặc Normal; reviewer kiểm tra được dữ liệu đã truyền hay chưa bằng đơn bán và danh sách kho. Đây là khác biệt về khả năng quan sát, không phải khẳng định Nova Foods đã vận hành ERP như vậy.

Senior Lens

So sánh tốt không nói “phương án 2 tốt hơn” mà chỉ ra điều thay đổi được: nơi nhập dữ liệu, nơi dữ liệu xuất hiện, ai hành động theo dữ liệu, artifact nào chứng minh lựa chọn. Nếu phương án không làm thay đổi hành vi, dữ liệu, kiểm soát hoặc chi phí có căn cứ, nó chưa đủ để thành solution option riêng.

Quick Reference

Kiểm tra	Đạt khi
Trước/sau cụ thể	Có cùng một tình huống Nova Foods mô phỏng và khác biệt quan sát được.
Không bịa số liệu	Không có tỷ lệ, SLA, chi phí, số đơn hay kết quả vận hành không được nguồn xác minh.
Không biến đề xuất thành fact	Ghi rõ IN_REVIEW, chưa baseline, chưa có approval.
Có hậu quả sai	Nêu lỗi người dùng hoặc lỗi kiểm soát xảy ra nếu lựa chọn không đáp ứng nhu cầu.

Core

Fact đã xác minh là thông tin có bằng chứng kiểm tra được từ nguồn xác định. Ví dụ: /01-curriculum/CHAPTER_MANIFEST.md có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; bằng chứng nằm trong metadata artifact. Fact không tự biến thành yêu cầu ERP.

Stakeholder input là ý kiến, nhu cầu hoặc mô tả từ vai trò liên quan. Nó là đầu vào cần truy vết, chưa phải sự thật hay quyết định. Không ghi thành rule khi chưa đối chiếu nguồn, dữ liệu hoặc thẩm quyền.

Project assumption là điều tạm dùng để tiếp tục phân tích khi bằng chứng chưa đủ. Assumption phải nêu điều kiện kiểm chứng, owner xác minh và tác động nếu sai. Assumption về thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc không được trình bày như nghĩa vụ pháp lý.

Decision là lựa chọn được ghi nhận giữa các option theo tiêu chí và thẩm quyền xác định. Decision khác với approval. Trong corpus Nova Foods, IN_REVIEW không chứng minh baseline, approval, sẵn sàng production hay tuân thủ.

Verification-required claim là phát biểu có thể ảnh hưởng rule, compliance, kiến trúc hoặc vận hành nhưng chưa được xác minh bằng nguồn hoặc vai trò có thẩm quyền. Nhãn này chặn BA biến suy luận thành sự thật.

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

flowchart TB
    A[Thông tin nhận được] --> X[Đánh giá từng claim riêng<br/>một thông tin có thể có nhiều claim]

    X --> B{Có bằng chứng kiểm tra được<br/>từ nguồn xác định?}
    B -- Có --> C[Fact đã xác minh]
    B -- Không --> D{Là ý kiến, nhu cầu hoặc mô tả<br/>từ stakeholder?}

    D -- Có --> E[Stakeholder input]
    D -- Không --> F{Cần tạm dùng để tiếp tục phân tích?}

    F -- Có --> G{Đã ghi điều kiện kiểm chứng,<br/>owner xác minh và tác động nếu sai?}
    F -- Không --> T[Chưa thuộc Fact, Stakeholder input<br/>hoặc Project assumption]

    G -- Có --> H[Project assumption]
    G -- Không --> I[Assumption chưa đầy đủ<br/>bổ sung kiểm chứng, owner, tác động]
    I --> G

    H --> Q{Liên quan thuế, kế toán, dữ liệu cá nhân,<br/>an toàn thực phẩm hoặc truy xuất nguồn gốc?}
    Q -- Có --> R[Không dùng như nghĩa vụ pháp lý<br/>khi chưa xác minh]
    Q -- Không --> J

    E --> J{Claim có thể ảnh hưởng rule, compliance,<br/>kiến trúc hoặc vận hành nhưng chưa được<br/>nguồn hoặc vai trò có thẩm quyền xác minh?}
    T --> J
    R --> J

    J -- Có --> K[Verification-required claim]
    J -- Không --> L[Giữ nhãn hiện có và truy vết]

    C --> M[Đầu vào và bằng chứng<br/>cho đánh giá option]
    K --> M
    L --> M

    M --> N{Có các option, tiêu chí,<br/>lựa chọn được ghi nhận<br/>và thẩm quyền xác định?}
    N -- Có --> O[Decision]
    N -- Không --> P[Giữ nhãn, truy vết<br/>và hoàn thiện đánh giá]

    O -.-> S[Decision không phải approval<br/>IN_REVIEW không chứng minh baseline,<br/>approval, sẵn sàng production hoặc compliance]

Applied

Trường	Nội dung Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Facts	/00-research/00_SOURCE_MAP.md, /01-curriculum/CHAPTER_MANIFEST.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md đều ghi IN_REVIEW, v0.9.0, ngày 2026-08-07. Các artifact nêu rõ chưa có baseline reference và approval reference.
Current Behavior	Người soạn có thể đọc cụm “bối cảnh Việt Nam” rồi viết rule ERP như thể đã được Business Owner, Legal Owner hoặc Accounting Owner xác nhận.
Underlying Need	Tách trạng thái bằng chứng khỏi trạng thái quyết định. Lý do: cùng một câu về vận hành có thể là ý kiến, giả định hoặc claim cần xác minh; xử lý chúng như fact làm sai traceability.
Options	(1) Gộp mọi thông tin vào “requirement”; (2) gắn nhãn năm loại: fact, stakeholder input, assumption, decision, verification-required claim.
Decision Criteria	Giữ được nguồn gốc; chỉ rõ bằng chứng; không vượt thẩm quyền; cho phép reviewer biết việc nào cần xác minh; không diễn giải IN_REVIEW thành approval.
Decision	Dùng option (2). Mỗi phát biểu ảnh hưởng rule, dữ liệu, tích hợp, compliance hoặc quyết định phải mang một nhãn phân loại trước khi dùng làm đầu vào tiếp theo.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì nhãn và traceability. Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA xác minh phần thuộc thẩm quyền của họ.
Artifact	Ghi phân loại và bằng chứng trong /02-handbook/16-solution-options-tradeoffs-and-recommendations.md; giữ nguyên tham chiếu nguồn canonical, không tạo approval reference mới.
Consequence if Wrong	Assumption bị triển khai như rule; stakeholder input bị hiểu là cam kết; decision không có thẩm quyền bị coi là phê duyệt; reviewer không biết cần xác minh phần nào. Kết quả là rework, tranh chấp scope và rủi ro governance.

Senior Lens

Cầu nối suy luận phải hiện rõ: “Artifact ghi IN_REVIEW và chưa có approval reference” là fact đã xác minh; “cần business xác nhận cách xử lý lô hàng” là stakeholder input nếu do stakeholder nêu; “ERP sẽ dùng một quy tắc chung cho mọi kho” là project assumption nếu chưa có bằng chứng; “chọn ghi nhãn năm loại trong handbook” là decision về phương pháp tài liệu; “quy tắc đó đáp ứng pháp luật Việt Nam” là verification-required claim cho đến khi Legal Owner xác minh nguồn chính thức hiện hành.

Không nâng cấp nhãn bằng ngôn ngữ. Các cụm “thường dùng”, “có vẻ”, “ngành thực phẩm yêu cầu”, “hệ thống phải” không thay thế bằng chứng, owner thẩm quyền hoặc decision record. Khi nguồn pháp lý hiện có nêu cần diễn giải bởi Legal Owner, Accounting Owner hoặc domain owner, BA giữ claim ở trạng thái cần xác minh.

Quick Reference

Nhãn	Câu hỏi kiểm tra	Cách ghi tối thiểu
Fact đã xác minh	Bằng chứng nằm ở đâu?	Nguồn, vị trí, ngày truy cập hoặc ngày artifact
Stakeholder input	Ai cung cấp ý kiến hoặc nhu cầu?	Vai trò, nội dung tóm tắt, ngữ cảnh
Project assumption	Điều gì đang tạm coi là đúng?	Giả định, lý do, owner xác minh, tác động nếu sai
Decision	Chọn gì thay vì option nào?	Option, tiêu chí, thẩm quyền, trạng thái quyết định
Verification-required claim	Điều gì chưa đủ bằng chứng nhưng có tác động?	Claim, nguồn cần kiểm tra, vai trò xác minh, giới hạn sử dụng

3. V? tr? trong Lifecycle

Core

Solution options, trade-offs and recommendations xuất hiện sau khi BA hiểu vấn đề nhưng trước khi đội delivery cam kết cách xây. “Option” là phương án giải quyết; “trade-off” là lợi ích đạt được và chi phí, rủi ro hoặc giới hạn phải chấp nhận; “recommendation” là đề xuất có lý do, tiêu chí và giới hạn rõ.

Lifecycle không phải chuỗi viết tài liệu một lần. Mỗi pha tăng bằng chứng để loại option yếu. Không được đưa recommendation sang Delivery nếu option còn thiếu tiêu chí, chưa nêu tác động hoặc đang giả định như fact.

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

flowchart TB
    D[Discovery<br/>Hiểu vấn đề]
    A[Analysis<br/>So sánh options]
    GA{Recommendation đủ tiêu chí,<br/>evidence, tác động, option không chọn,<br/>lý do và điểm cần xác minh?}
    GD{Quyết định theo<br/>governance dự án?}
    DE[Delivery<br/>Xây theo decision]
    T[Testing<br/>Kiểm chứng]
    GT{Kết quả test so với<br/>tiêu chí release?}
    GE{Bằng chứng test<br/>đã đủ?}
    GR{Quyết định release?}
    R[Release<br/>Thay đổi được phát hành<br/>theo quy trình áp dụng]
    O[Operations<br/>Theo dõi lợi ích, chi phí và rủi ro]
    GO{Evidence vận hành<br/>cho biết gì?}

    D -->|Có problem statement và phạm vi tác động sơ bộ| A
    A --> GA
    GA -->|Chưa đạt: bổ sung hoặc sửa recommendation| A
    GA -->|Đạt| GD
    GD -->|Đang chờ: IN_REVIEW không phải approval| GD
    GD -->|Không phê duyệt hoặc yêu cầu sửa| A
    GD -->|Đã có quyết định| DE
    DE -->|Build sẵn sàng và có test basis| T
    T --> GT
    GT -->|Đáp ứng tiêu chí| GE
    GT -->|Không đáp ứng; cần sửa solution| DE
    GT -->|Option hoặc recommendation mất hiệu lực| A
    GE -->|Chưa đủ evidence| T
    GE -->|Đủ evidence| GR
    GR -->|Go| R
    GR -->|No-go hoặc yêu cầu sửa solution| DE
    GR -->|Cần xem lại option hoặc recommendation| A
    R -->|Thay đổi đã phát hành| O
    O -->|Có dữ liệu quan sát và phân tích| GO
    GO -->|Giữ recommendation; tiếp tục theo dõi| O
    GO -->|Cần điều chỉnh option| A
    GO -->|Vấn đề mới hoặc cần mở lại Discovery| D

Pha	Entry gate: điều kiện bắt đầu	Hoạt động option	Exit gate: điều kiện rời pha
Discovery	Vấn đề, cơ hội hoặc rủi ro đã được ghi nhận; chưa coi giải pháp là đúng	Tách symptom khỏi underlying need; ghi fact, stakeholder input, assumption và verification-required claim	Problem statement đủ rõ để so sánh cách giải; không cam kết solution
Analysis	Có problem statement và phạm vi tác động sơ bộ	Lập options, tiêu chí, trade-off, dependency, rủi ro và recommendation	Recommendation nêu option không chọn, lý do, evidence, tác động và điểm cần xác minh
Delivery	Recommendation được dùng làm input theo cơ chế quyết định dự án; trạng thái IN_REVIEW không phải approval	Chuyển decision thành backlog, specification hoặc cấu hình; kiểm tra build vẫn giữ đúng trade-off đã chọn	Hạng mục xây xong, có thể kiểm thử theo acceptance criteria và decision record
Testing	Có test basis: requirement, rule, acceptance criteria hoặc decision đã truy vết	Kiểm tra hành vi thực tế so với option được chọn; ghi defect hoặc sai lệch	Kết quả test cho biết solution đáp ứng hay không đáp ứng tiêu chí release
Release	Có bằng chứng test và quyết định release theo governance dự án	Đối chiếu scope phát hành với recommendation; ghi rủi ro còn lại	Thay đổi được phát hành theo quy trình được áp dụng; không suy ra tuân thủ pháp lý hay production approval
Operations	Thay đổi đã phát hành và có dữ liệu quan sát vận hành	So sánh kết quả thực tế với lợi ích, chi phí và rủi ro dự đoán	Evidence mới được ghi nhận để giữ recommendation, điều chỉnh option hoặc mở lại Discovery

Gate là điểm kiểm soát, không phải cuộc họp mặc định. Gate đạt khi evidence tối thiểu tồn tại và không mâu thuẫn; gate chưa đạt khi một giả định quan trọng bị trình bày như fact, hoặc recommendation thiếu tiêu chí quyết định.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu tổng hợp. Artifact governance trong corpus đang IN_REVIEW, version v0.9.0, ngày 2026-08-07. Không có baseline reference hoặc approval reference.

Current Behavior: Nhân viên kho mô phỏng ghi lý do chênh lệch tồn kho tự do. Báo cáo quản trị khó nhóm nguyên nhân vì cùng một ý nghĩa có nhiều cách viết.

Underlying Need: Cần dữ liệu lý do chênh lệch nhất quán để phân tích, nhưng không được tự kết luận đây là quy tắc vận hành Nova Foods thực tế.

Options: Option 1 giữ ô nhập tự do. Option 2 dùng danh sách mã lý do cố định. Option 3 dùng mã cố định kèm ghi chú tự do khi mã không đủ.

Decision Criteria: Khả năng tổng hợp báo cáo, tốc độ nhập, khả năng giải thích ngoại lệ, tác động cấu hình ERP và rủi ro mất ngữ cảnh.

Decision: Khuyến nghị Option 3 trong Analysis. Lý do: mã cố định tạo dữ liệu nhóm được; ghi chú giữ ngữ cảnh ngoại lệ. Đây là recommendation học liệu, chưa là quyết định triển khai.

Authority: Đánh giá tính phù hợp nghiệp vụ và quyết định áp dụng thuộc vai trò có thẩm quyền của dự án. BA chỉ ghi evidence, option, tiêu chí và tác động. Nếu mã lý do liên quan kế toán, chất lượng hoặc truy xuất thực phẩm, cần xác minh bởi Accounting Owner, domain owner và Legal Owner theo phạm vi tương ứng.

Artifact: Ghi phân tích trong /02-handbook/16-solution-options-tradeoffs-and-recommendations.md; liên kết rule hoặc data element chỉ khi đã có ID canonical trong /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Consequence if Wrong: Nếu chọn mã cố định quá sớm, vận hành mất lý do thực tế. Nếu giữ nhập tự do hoàn toàn, báo cáo mất khả năng so sánh. Testing phải kiểm tra cả chọn mã và lưu ghi chú; Operations phải quan sát tỷ lệ ngoại lệ trước khi mở lại decision.

Senior Lens

Evidence thay đổi theo pha. Discovery chấp nhận câu hỏi còn mở nhưng không chấp nhận giải pháp ngầm định. Analysis chấp nhận recommendation IN_REVIEW nhưng không gọi là approved. Delivery cần scope có thể xây. Testing cần hành vi quan sát được. Release cần quyết định phát hành theo governance thực tế. Operations cung cấp evidence mới, không tự viết lại lý do ban đầu.

Khi exit gate thiếu evidence, quay lại pha tạo evidence gần nhất. Không “đẩy tiếp để kịp tiến độ”; việc đó biến uncertainty thành defect, rework hoặc rủi ro vận hành.

Quick Reference

Pha	Câu hỏi gate
Discovery	Đang giải đúng vấn đề, hay đang bảo vệ solution đầu tiên?
Analysis	Có so sánh option bằng tiêu chí rõ, có evidence và giới hạn?
Delivery	Đội xây có thể thực hiện mà không tự đoán trade-off?
Testing	Test có kiểm chứng decision và acceptance criteria không?
Release	Phạm vi phát hành có khác recommendation đã ghi không?
Operations	Evidence thực tế có làm thay đổi giả định, tiêu chí hoặc option không?

Core

Nova Foods Trading & Manufacturing là case 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, pháp lý, kế toán, bảo mật, kiểm thử hay vận hành. BA sở hữu việc làm rõ lựa chọn, ghi bằng chứng, nối handoff và đưa đúng người có thẩm quyền vào điểm quyết định.

Luồng	Upstream owner gửi vào	Handoff do BA điều phối	Downstream owner nhận	Giới hạn thẩm quyền BA	Escalation
Discovery sang Analysis	Business Owner nêu vấn đề, mục tiêu, phạm vi	Problem statement, giả định, stakeholder list	Business Owner, Process Owner, Solution Architect	Không chọn giải pháp thay Business Owner	Mục tiêu mâu thuẫn lợi ích bộ phận: Business Owner quyết định ưu tiên
Analysis sang Delivery	Process Owner xác nhận cách làm hiện tại; Architect nêu ràng buộc kỹ thuật	Option comparison, tiêu chí, recommendation, open decision	Delivery Lead, Solution Architect	Không cam kết effort, kiến trúc hay ngày giao	Option chạm dữ liệu cá nhân: Legal Owner, Security Owner cùng đánh giá
Delivery sang Testing	Delivery Lead mô tả phần đã xây; BA giữ logic nghiệp vụ truy vết được	Requirement-to-test traceability, acceptance criteria	QA Lead, Test Analyst	Không xác nhận phần mềm đạt chất lượng	Test basis mơ hồ hoặc behavior lệch rule: Process Owner và Delivery Lead xử lý
Testing sang Release	QA Lead báo kết quả kiểm thử; Security Owner báo kết quả thuộc phạm vi mình	Known issues, impact assessment, release decision package	Release Manager, Business Owner	Không cho phép release	Defect ảnh hưởng tiền, tồn kho, truy xuất lô hoặc quyền dữ liệu: Business Owner, Accounting Owner, Security Owner theo phạm vi
Release sang Operations	Release Manager bàn giao trạng thái phát hành; Operations Owner nhận vận hành	Runbook reference, support ownership, decision log	Operations Owner, Service Desk	Không tuyên bố production-ready	Sự cố làm sai dữ liệu hoặc gián đoạn vận hành: Operations Owner kích hoạt quy trình sự cố; BA cung cấp traceability

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

flowchart TB
    subgraph "1. Input Phân tích"
        direction LR
        BO[Business Owner] -- vấn đề, mục tiêu --> BA[Business Analyst]
        PO[Process Owner] -- quy trình, rule --> BA
        SA[Solution Architect] -- ràng buộc kỹ thuật --> BA
    end

    BA -- lựa chọn, tiêu chí, bằng chứng --> DEC{Quyết định Giải pháp}

    subgraph "2. Thẩm định & Quyết định"
        direction LR
        BO -- phê duyệt nghiệp vụ --> DEC
        SA -- phê duyệt kiến trúc --> DEC
        Owners[Legal/Security Owner] -- phê duyệt pháp lý, bảo mật --> DEC
    end

    DEC -- quyết định được ghi nhận --> Handoff(Bàn giao Delivery)

    subgraph "3. Pipeline Phát triển & Vận hành"
        direction LR
        Handoff -- traceability --> DL[Delivery Lead]
        DL --> QA[QA Lead] --> RM[Release Manager] --> OO[Operations Owner]
    end

Applied

Facts: Nova Foods mô phỏng cần chọn cách xử lý đơn bán vượt hạn mức tín dụng. Dữ liệu minh họa: đơn SO-SIM-20260807-001, giá trị 125.000.000 VND, hạn mức còn lại 100.000.000 VND.

Current Behavior: Process Owner mô tả nhân viên bán hàng đang gọi điện xin xác nhận ngoại lệ. Bằng chứng là mô tả quy trình mô phỏng, chưa phải quy tắc đã baseline trong CANONICAL_BUSINESS_RULES.

Underlying Need: Cần chọn cách ERP phản ứng khi đơn vượt hạn mức, đồng thời xác định ai được quyết định ngoại lệ. Suy luận: giá trị đơn có thể ảnh hưởng công nợ; vì vậy BA không được tự chọn ngưỡng hay quyền phê duyệt.

Options: Chặn đơn; cho lưu nháp và chuyển duyệt; cho phát hành đơn ngay rồi kiểm tra sau.

Decision Criteria: Kiểm soát rủi ro công nợ, tốc độ xử lý đơn, khả năng audit, khả năng cấu hình ERP, thẩm quyền kế toán.

Decision: Chưa có quyết định được ghi nhận. BA lập comparison và nêu hệ quả từng option; Accounting Owner và Business Owner phải quyết định rule nghiệp vụ. Solution Architect xác nhận khả năng kỹ thuật sau đó.

Authority: Business Owner quyết định ưu tiên nghiệp vụ. Accounting Owner xác nhận tác động kế toán hoặc tín dụng. Solution Architect quyết định tính phù hợp kiến trúc. BA không thay thế ba vai trò này.

Artifact: Ghi traceability vào TRACEABILITY_ID_REGISTRY; tham chiếu rule catalog CANONICAL_BUSINESS_RULES; không tạo ID mới trong micro-batch này.

Consequence if Wrong: BA tự chọn “cho phát hành ngay” có thể biến giả định thành rule, giao sai quyền, tạo rủi ro công nợ và làm QA kiểm thử nhầm behavior.

Senior Lens

Handoff không phải gửi tài liệu. Handoff hoàn tất khi người nhận biết: nhận cái gì, dùng để làm gì, nguồn nào chứng minh, điểm nào chưa quyết, ai quyết và khi nào phải escalation. Nếu một lựa chọn đồng thời ảnh hưởng nghiệp vụ, kiến trúc và dữ liệu cá nhân, không chia nhỏ để né thẩm quyền; mở escalation chung. Quy tắc này phù hợp ranh giới quản trị của TRACEABILITY_ID_REGISTRY: BA lập gói vấn đề và giữ traceability, không thay kết luận chuyên môn.

Quick Reference

Tình huống	BA làm	BA không làm
Owner chưa rõ	Ghi named role, artifact cần bàn giao, escalation owner	Tự nhận owner
Hai owner mâu thuẫn	Ghi facts, options, impact, quyết định cần có	Chọn bên “hợp lý hơn”
Rule có tác động kế toán hoặc pháp lý	Gắn Verification required, chuyển Accounting Owner hoặc Legal Owner	Diễn giải như nghĩa vụ đã xác nhận
Delivery hỏi quyết định nghiệp vụ	Chuyển Business Owner, giữ decision log	Đổi requirement để unblock build

Core

Bản đồ vòng đời giúp BA đặt hoạt động solution options (các phương án giải pháp) đúng thời điểm. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Sơ đồ không xác nhận quy trình ERP thật, baseline hay phê duyệt.

Applied

Mục	Nội dung mô phỏng Nova Foods
Facts	Kho cần thấy tồn kho theo lô khi nhận hàng nguyên liệu.
Current Behavior	Nhân viên ghi lô trong ghi chú tự do; báo cáo tồn kho không tách được từng lô.
Underlying Need	Cần dữ liệu lô có cấu trúc để truy vết nội bộ. Đây là nhu cầu nghiệp vụ, chưa phải quyết định cấu hình ERP hay kết luận tuân thủ pháp lý.
Options	Phương án 1: thêm trường mã lô vào chứng từ nhận hàng. Phương án 2: dùng ghi chú tự do. Phương án 3: tích hợp hệ thống quản lý kho riêng.
Decision Criteria	Khả năng truy vết, chi phí thay đổi, ảnh hưởng quy trình kho, khả năng kiểm thử, rủi ro dữ liệu sai.
Decision	Chưa chọn phương án trong Discovery. Sang Analysis mới so sánh bằng chứng vì Facts chỉ chứng minh có khoảng trống dữ liệu, chưa chứng minh phương án nào phù hợp nhất.
Authority	BA ghi nhận và phân tích; Business Owner quyết định ưu tiên nghiệp vụ; Architect xác nhận khả thi kỹ thuật; QA xác nhận test basis.
Artifact	Bảng so sánh phương án phải liên kết nhu cầu, tiêu chí, giả định, rủi ro và quyết định tại artifact kiểm soát phù hợp.
Consequence if Wrong	Chọn tích hợp quá sớm có thể tăng chi phí và phạm vi; giữ ghi chú tự do có thể làm mất khả năng báo cáo lô nhất quán.

Senior Lens

Không đưa phương án vào Delivery khi Analysis chưa tạo được tiêu chí so sánh. Lý do: Delivery biến lựa chọn thành thay đổi tốn chi phí; nếu tiêu chí chưa rõ, đội kỹ thuật chỉ đang hiện thực hóa giả định. BABOK Guide Version 3 hỗ trợ cách dùng thuật ngữ BA và hoạt động phân tích; ISO/IEC/IEEE 29148:2018 hỗ trợ tư duy về yêu cầu. Không suy diễn điều khoản chi tiết từ các nguồn này.

Quick Reference

Điểm dùng bản đồ	Câu hỏi kiểm soát
Discovery	Vấn đề có đủ bằng chứng để phân tích không?
Analysis	Các phương án có cùng nhu cầu, ràng buộc và tiêu chí để so sánh không?
Delivery	Phương án đã được chuyển thành thay đổi có thể xây dựng không?
Testing	Có test basis từ yêu cầu và tiêu chí chấp nhận không?
Release	Kết quả kiểm thử có được ghi nhận để quyết định phát hành không?
Operations	Dữ liệu vận hành có cho thấy nhu cầu quay lại Discovery không?

4. Input c?n thi?t

Core

Đầu vào là thứ BA nhận trước khi so sánh phương án. Người mới không cần biết ERP trước. ERP là hệ thống gom dữ liệu và quy trình như bán hàng, kho, mua hàng, sản xuất, kế toán vào cùng môi trường. BA không bắt đầu bằng màn hình hay giải pháp. BA bắt đầu bằng bằng chứng: hiện trạng, nhu cầu, quy tắc, dữ liệu và giới hạn.

Nguồn artifact là tệp hoặc tài liệu có xuất xứ xác định. Canonical ID là mã định danh chuẩn, giữ nguyên qua các tài liệu để một nhu cầu không bị đổi tên hoặc mất liên kết. Ví dụ CANONICAL_DATA_DICTIONARY luôn chỉ đúng artifact /01-curriculum/CANONICAL_DATA_DICTIONARY.md; không thay bằng tên dịch hoặc tên rút gọn.

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

flowchart TB
    A[BA có hiểu biết nghiệp vụ tối thiểu]
    B[Bằng chứng mô phỏng<br/>hiện trạng, nhu cầu, quy tắc, dữ liệu, giới hạn]
    C[Artifact nguồn<br/>tệp hoặc tài liệu có xuất xứ xác định]
    D[Canonical ID<br/>mã ổn định định danh artifact]
    E[So sánh phương án<br/>dựa trên bằng chứng và có truy vết]

    A -->|dùng để đọc và kiểm tra| B
    B -->|được ghi trong| C
    C -->|mang| D
    C -->|cung cấp nội dung bằng chứng| E
    D -->|cho khả năng truy vết| E

Cầu nối suy luận: nếu BA chỉ nghe “cần quản lý lô tốt hơn”, chưa thể biết vấn đề nằm ở dữ liệu, quy trình hay tích hợp. Nếu bằng chứng ghi nhận trường lô thiếu cấu trúc, BA mới có cơ sở xét phương án bổ sung dữ liệu lô. Vì vậy, ý kiến là tín hiệu khám phá; artifact nguồn và ID ổn định là nền để phân tích.

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 mô tả doanh nghiệp thật.

Nhóm đầu vào	Giá trị Nova Foods tổng hợp	Artifact nguồn và phân loại	Canonical ID cần giữ nguyên	Bằng chứng hoặc cầu nối suy luận	Trạng thái
Kiến thức nghiệp vụ	Hàng thực phẩm cần nhận diện theo SKU, lô và hạn dùng để truy vết nội bộ	Mô tả case mô phỏng; nguồn nghiệp vụ	CANONICAL_DATA_DICTIONARY	Một SKU có thể có nhiều lô; SKU đơn lẻ không đủ phân biệt từng lần nhập	Có thể dùng để phân tích
Vấn đề hiện trạng	Nhân viên kho ghi mã lô trong ghi chú tự do khi nhận hàng	Quan sát quy trình mô phỏng; bằng chứng hiện trạng	NF-OBS-INV-001	Ghi chú tự do không bảo đảm cùng cấu trúc giữa người nhập; báo cáo lô có nguy cơ không nhất quán	Có thể dùng để phân tích
Đối tượng dữ liệu	SKU NF-MILK-180, lô LOT-260801-A, hạn dùng 2026-12-28	Ví dụ dữ liệu tổng hợp; nguồn dữ liệu logic	CANONICAL_DATA_DICTIONARY	Cùng SKU cần khóa nhận diện lô riêng để phân biệt tồn kho theo lô	Có thể dùng làm ví dụ
Quy tắc nghiệp vụ	Chưa có quy tắc canonical xác nhận lúc nào bắt buộc nhập hạn dùng	Catalog quy tắc đang lập kế hoạch	CANONICAL_BUSINESS_RULES	Thiếu quy tắc xác nhận nên không được biến giả định thành yêu cầu bắt buộc	Verification required
Định danh truy vết	NF-OBS-INV-001 là mã quan sát; không đổi thành OBS-1 trong tài liệu sau	Registry định danh; nguồn quản trị	TRACEABILITY_ID_REGISTRY	Đổi mã làm đứt liên kết giữa quan sát, nhu cầu, phương án và kiểm thử sau này	Có thể dùng để truy vết
Ranh giới pháp lý	Bối cảnh truy xuất thực phẩm có liên quan Luật An toàn thực phẩm	Nguồn pháp lý chính thức; nguồn tham chiếu pháp lý	Luật 55/2010/QH12	Nguồn xác nhận bối cảnh pháp lý, nhưng chưa xác nhận nghĩa vụ ERP cụ thể cho Nova Foods mô phỏng	Verification required
Ranh giới dữ liệu cá nhân	Không dùng tên, số điện thoại, địa chỉ nhân viên hoặc khách hàng thật	Quy tắc corpus; nguồn quản trị	00_SOURCE_MAP	Corpus chỉ dùng dữ liệu tổng hợp; không cần dữ liệu cá nhân để phân tích lô hàng	Có thể dùng để giới hạn dữ liệu

Mục Applied	Nội dung
Facts	Kho mô phỏng Nova Foods ghi lô trong ghi chú tự do; ví dụ SKU NF-MILK-180 có lô LOT-260801-A.
Current Behavior	Nhân viên nhập cùng loại thông tin bằng văn bản không có cấu trúc cố định.
Underlying Need	Cần phân biệt tồn kho theo lô bằng dữ liệu có cấu trúc, không chỉ theo SKU.
Options	Giữ ghi chú tự do; thêm trường lô và hạn dùng có cấu trúc; tích hợp hệ thống quản lý kho.
Decision Criteria	Khả năng truy vết lô, nhất quán dữ liệu, ảnh hưởng quy trình kho, khả năng kiểm thử, rủi ro nhập sai.
Decision	Chưa chọn phương án. Inputs hiện có chứng minh khoảng trống dữ liệu; chưa đủ bằng chứng chọn giải pháp.
Authority	BA tổng hợp bằng chứng; Business Owner quyết định nhu cầu; Architect đánh giá kỹ thuật; Legal hoặc domain owner xác minh nghĩa vụ chuyên ngành.
Artifact	/01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Consequence if Wrong	Nhầm SKU với lô làm báo cáo tồn kho sai mức chi tiết; đổi ID làm mất traceability; suy diễn luật thành yêu cầu ERP tạo rủi ro quyết định sai.

Senior Lens

Không coi artifact đang IN_REVIEW là bằng chứng đã phê duyệt. v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND và Nova Foods mô phỏng là metadata kiểm soát corpus, không phải quyết định vận hành ERP.

BABOK Guide Version 3 dùng được cho thuật ngữ và hoạt động BA. ISO/IEC/IEEE 29148:2018 dùng được cho tư duy về yêu cầu. Hai nguồn không tự xác nhận quy tắc lô hàng Nova Foods. Luật An toàn thực phẩm là nguồn pháp lý chính thức cho ngữ cảnh; mọi nghĩa vụ cụ thể vẫn cần xác minh bởi vai trò có thẩm quyền.

Quick Reference

Cần có trước khi phân tích phương án	Cách nhận biết
Kiến thức nghiệp vụ tối thiểu	Hiểu đối tượng nào đang được quản lý, như SKU, lô, hạn dùng
Bằng chứng hiện trạng	Có quan sát, dữ liệu hoặc mô tả hành vi; không chỉ có mong muốn
Artifact nguồn	Có đường dẫn và phân loại nguồn rõ
Canonical ID	Có mã giữ nguyên giữa artifact liên quan
Ranh giới suy luận	Phân biệt fact, giả định và Verification required
Dữ liệu an toàn	Chỉ dùng dữ liệu tổng hợp của Nova Foods mô phỏng

Kiểm tra chất lượng, phân loại nguồn, độ mới, ownership và điều kiện dừng

Đầu vào là thông tin BA dùng để so sánh các phương án giải pháp. Trước khi dùng, BA kiểm tra nguồn nói gì, ai chịu trách nhiệm, còn mới không, có đủ bằng chứng không. Không có kiểm tra này, bảng trade-off có thể dựa trên giả định nhưng bị trình bày như sự thật.

Phân loại nguồn xác định mức được phép suy luận. Primary source là nguồn gốc trực tiếp, như văn bản pháp luật chính thức hoặc artifact canonical được kiểm soát. Secondary source diễn giải hay tổng hợp từ nguồn khác; chỉ dùng để định hướng, không thay nguồn gốc. Project assumption là giả định học liệu mô phỏng; không biến thành quy tắc Nova Foods. Verification required là thông tin chưa đủ bằng chứng hoặc cần vai trò có thẩm quyền xác nhận.

Kiểm tra	Quy tắc đạt	Không đạt khi	Hành động BA
Định danh	Có Artifact ID hoặc URL chính thức, tên tệp và phiên bản khớp nguồn	ID bị đổi, tên tệp rút gọn, URL không chính thức	Dừng dùng nội dung; quay về artifact canonical
Phân loại nguồn	Gắn đúng Primary source, Secondary source, Project assumption hoặc Verification required	Nguồn pháp lý bị gọi là quyết định dự án; giả định bị gọi là fact	Sửa nhãn; không suy luận thêm
Độ mới	Ngày truy cập, ngày cập nhật và version rõ; đánh giá theo 2026-08-07, Asia/Ho_Chi_Minh	Không rõ version hoặc nguồn có dấu hiệu thay đổi	Gắn Verification required; không chốt tiêu chí
Ownership	Có Owner quản trị artifact và authority chuyên môn phù hợp	Owner tài liệu bị hiểu là người phê duyệt nghiệp vụ, pháp lý, kế toán	Escalate đúng vai trò; giữ trạng thái IN_REVIEW
Đủ bằng chứng	Claim, nguồn và lý do nối được với nhau	Kết luận không chỉ ra evidence/reasoning bridge	Loại claim khỏi so sánh phương án
Ranh giới sử dụng	Không vượt safe use boundary của nguồn	Trích điều khoản không có licensed-text verification; diễn giải luật như tư vấn pháp lý	Dừng claim; yêu cầu Legal Owner hoặc vai trò chuyên môn xác minh

Độ mới không chỉ là ngày cũ hay mới. BA hỏi: “Thông tin này còn đại diện cho trạng thái quyết định không?” Ví dụ, ISO/IEC/IEEE 29148:2018 vẫn là Edition 2 theo nguồn đã xác minh, nhưng được đánh dấu sẽ revised trong 2026. Vì vậy BA có thể dùng abstract và bibliographic status, nhưng không được tự tạo clause reference hay coi tiêu chuẩn này là requirement Nova Foods.

Nguồn/Artifact	Classification	Freshness tại 2026-08-07	Owner quản trị	Authority cần xác minh	Cách dùng được phép
/01-curriculum/TRACEABILITY_ID_REGISTRY.md — TRACEABILITY_ID_REGISTRY	Primary source nội bộ corpus	v0.9.0, IN_REVIEW, cập nhật 2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Không tự tạo approval hay baseline	Kiểm tra canonical ID và traceability
/01-curriculum/CANONICAL_BUSINESS_RULES.md — CANONICAL_BUSINESS_RULES	Primary source nội bộ corpus	v0.9.0, IN_REVIEW, cập nhật 2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Business Owner; Legal, Accounting, Security khi phạm vi kích hoạt	Xác định rule catalog đang là kế hoạch, chưa là rule vận hành
Luật 91/2025/QH15	Primary source pháp lý	Hiệu lực 2026-01-01; URL truy cập 2026-08-07	Quốc hội Việt Nam phát hành	Legal Owner	Nhận diện nghĩa vụ có thể ảnh hưởng dữ liệu cá nhân; không tự diễn giải requirement
Nghị định 123/2020/NĐ-CP	Primary source pháp lý	Hiệu lực 2022-07-01; cần kiểm tra sửa đổi trước production use	Chính phủ Việt Nam phát hành	Legal Owner, Accounting Owner	Nhận diện phạm vi hóa đơn, chứng từ; không chốt cấu hình ERP
“Đơn hàng bán phải được duyệt trước khi xuất kho”	Project assumption, dữ liệu tổng hợp	Có hiệu lực học liệu tại lô hiện tại, không phải fact vận hành	Principal IT Business Analyst / Technical Curriculum Author	Business Owner, Warehouse Owner	Dùng minh họa phương án; gắn rõ giả định
“Nova Foods đã dùng ERP X”	Verification required	Không có artifact chứng minh	Chưa xác định	Business Owner, Architect	Không dùng làm tiêu chí chọn giải pháp

Điều kiện dừng bảo vệ quyết định khỏi bằng chứng yếu. Dừng phân tích phương án, ghi trạng thái STOP — INPUT VERIFICATION REQUIRED, khi có ít nhất một điều kiện sau: canonical ID không tra được trong TRACEABILITY_ID_REGISTRY; hai nguồn canonical mâu thuẫn; nguồn pháp lý, kế toán, thuế, dữ liệu cá nhân hoặc an toàn thực phẩm bị dùng để kết luận bắt buộc nhưng chưa có authority phù hợp xác minh; thông tin quá hạn hoặc không có ngày/version; giả định bị biến thành fact; hoặc người ghi nhận không có quyền quyết định nhưng đang được gán Authority.

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

flowchart TB
    A[Nhận input và claim] --> B{ID/URL chính thức, tên tệp và version khớp nguồn?}
    B -- Không --> S[STOP — INPUT VERIFICATION REQUIRED]
    B -- Có --> C{Hai nguồn canonical mâu thuẫn?}
    C -- Có --> S
    C -- Không --> D{Phân loại nguồn rõ?}
    D -- Không --> S
    D -- Có --> E{Giả định bị biến thành fact?}
    E -- Có --> S
    E -- Không --> F{Freshness, ngày và version rõ?}
    F -- Không --> S
    F -- Có --> G{Nguồn quá hạn hoặc có dấu hiệu thay đổi?}
    G -- Có --> S
    G -- Không --> H{Owner quản trị artifact được xác định và không bị coi là authority chuyên môn?}
    H -- Không --> S
    H -- Có --> I{Authority chuyên môn phù hợp với claim?}
    I -- Không --> P[Escalate authority phù hợp]
    I -- Có --> J{Người ghi nhận bị gán Authority nhưng không có quyền?}
    J -- Có --> S
    J -- Không --> K{Claim nối được nguồn và reasoning bridge?}
    K -- Không --> L[Loại claim khỏi so sánh]
    L --> Z[Kết thúc claim]
    K -- Có --> M{Có trích điều khoản nhưng thiếu licensed-text verification, hoặc claim vượt safe use boundary?}
    M -- Có --> N[Dừng claim; yêu cầu vai trò chuyên môn xác minh]
    N --> R[IN_REVIEW]
    M -- Không --> O{Kết luận bắt buộc thuộc pháp lý, kế toán, thuế, dữ liệu cá nhân hoặc an toàn thực phẩm chưa được authority phù hợp xác minh?}
    O -- Có --> P
    O -- Không --> Q[Được dùng làm evidence có nhãn]
    P --> R
    R --> T{Claim/input cần để tiếp tục phân tích?}
    T -- Có --> S
    T -- Không --> Z
    Q --> W[Tiếp tục phân tích phương án]

IN_REVIEW nghĩa là đang xem xét có kiểm soát. Nó không nghĩa APPROVED, BASELINED, compliant, production-ready, hay đã được người dùng phê duyệt. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dùng trong kiểm tra trên là dữ liệu tổng hợp.

Core

Bảng đầu vào dưới đây là mẫu đầy đủ cho Nova Foods Trading & Manufacturing, case mô phỏng giáo dục, toàn bộ dữ liệu tổng hợp. Mỗi dòng giữ ID canonical, tệp nguồn và trạng thái IN_REVIEW để BA truy được nguồn gốc trước khi so sánh phương án ERP.

Input ID	Đầu vào	Giá trị mô phỏng	Nguồn/tệp canonical	Phân loại nguồn	Owner nguồn	Ngày hiệu lực hoặc cập nhật	Trạng thái xác minh	Mục đích khi đánh giá phương án
SRC-001	Bối cảnh curriculum và case study	Việt Nam, vi-VN, Asia/Ho_Chi_Minh, VND; Nova Foods là mô phỏng	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Đã ghi nhận metadata; không phải approval	Chặn suy diễn đây là ERP thật hoặc dữ liệu production
SRC-002	Danh mục chapter và đường dẫn handbook	Chapter 16, /02-handbook/16-solution-options-tradeoffs-and-recommendations.md	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	IN_REVIEW	Giữ đúng phạm vi tài liệu và traceability
SRC-003	Registry định danh	Quy tắc dùng ID canonical, không tự tạo biến thể ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	IN_REVIEW	Liên kết requirement, rule, dữ liệu và quyết định
SRC-004	Catalog quy tắc nghiệp vụ	Quy tắc Nova Foods chưa phải quy định vận hành thật	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	IN_REVIEW	Không chọn phương án dựa trên rule chưa được xác minh
SRC-005	Từ điển dữ liệu logic	Thuật ngữ dữ liệu canonical cần giữ nguyên nguồn	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	IN_REVIEW	So khớp dữ liệu hàng hóa, lô hàng, khách hàng và chứng từ
SRC-006	Kiến thức BA	Thuật ngữ và phạm vi công việc BA	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Primary professional source	IIBA	2026-08-07	Chỉ dùng overview và errata công khai	Phân biệt nhu cầu, yêu cầu, giả định và quyết định
SRC-007	Chuẩn yêu cầu	ISO/IEC/IEEE 29148:2018, Edition 2	https://www.iso.org/standard/72089.html	Primary standard source	ISO/IEC/IEEE	2026-08-07	Cần licensed-text verification nếu viện dẫn điều khoản	Kiểm tra yêu cầu trước khi chấm phương án
SRC-008	Bối cảnh truy xuất thực phẩm	Luật An toàn thực phẩm 55/2010/QH12	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Official legal source	Quốc hội Việt Nam	2026-08-07	Verification required từ Legal Owner và domain owner	Xác định nhu cầu truy vết và thu hồi ở mức giả định học liệu
SRC-009	Bối cảnh hóa đơn, chứng từ	Nghị định 123/2020/NĐ-CP	https://vanban.chinhphu.vn/?docid=201365&pageid=27160	Official legal source	Chính phủ Việt Nam	2026-08-07	Verification required về sửa đổi và áp dụng thực tế	Không kết luận phương án ERP đáp ứng nghĩa vụ hóa đơn
SRC-010	Bối cảnh dữ liệu cá nhân	Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=; https://vanban.chinhphu.vn/?classid=1&docid=216387&pageid=27160	Official legal source	Quốc hội Việt Nam; Chính phủ Việt Nam	2026-08-07	Verification required từ Legal Owner	Đánh dấu dữ liệu khách hàng cần kiểm soát, không tự kết luận compliance
NF-ASSUMP-001	Quy mô vận hành mô phỏng	2 kho: WH-HCM-01, WH-BD-01; 1 nhà máy PLANT-BD-01	Bảng giả định case study	Project assumption	Business Owner mô phỏng	2026-08-07	Chưa xác minh	So sánh khả năng đa kho và tồn kho theo địa điểm
NF-ASSUMP-002	Danh mục sản phẩm mô phỏng	FG-NF-001 Nước trái cây 350 ml; theo dõi lô LOT-NF-202608-001	Bảng giả định case study	Project assumption	Supply Chain Owner mô phỏng	2026-08-07	Chưa xác minh	So sánh khả năng quản lý lô và truy xuất
NF-VERIFY-001	Quy tắc xuất kho FEFO	Chưa xác định có bắt buộc xuất theo hạn dùng sớm nhất hay không	Chưa có artifact canonical	Unresolved verification item	Supply Chain Owner mô phỏng	2026-08-07	Cần xác minh	Không chấm phương án về FEFO khi chưa có quy tắc nguồn
NF-VERIFY-002	Tích hợp hóa đơn điện tử	Chưa xác định nhà cung cấp, API hay phương thức trao đổi	Chưa có artifact canonical	Unresolved verification item	Accounting Owner mô phỏng; Architect	2026-08-07	Cần xác minh	Không tuyên bố phương án tích hợp được hóa đơn điện tử
NF-VERIFY-003	Thẩm quyền phê duyệt đơn bán	Chưa xác định ngưỡng giá trị VND và vai trò phê duyệt	Chưa có artifact canonical	Unresolved verification item	Sales Owner mô phỏng	2026-08-07	Cần xác minh	Không thiết kế workflow phê duyệt như rule đã chốt

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

flowchart TB
    A["Nguồn canonical<br/>SRC-001 đến SRC-010"] --> C["Bảng đầu vào phương án"]
    B["Giả định mô phỏng<br/>NF-ASSUMP-001 đến NF-ASSUMP-002"] --> C
    C --> E["So sánh phương án có traceability"]

    D1["NF-VERIFY-001<br/>FEFO<br/>Supply Chain Owner"] --> F1{"Đã được Supply Chain Owner xác minh?"}
    F1 -- "Chưa" --> G1["Chặn chấm phương án về FEFO"]
    F1 -- "Đã xác minh" --> H1["Cập nhật nguồn và trạng thái"]
    H1 --> C

    D2["NF-VERIFY-002<br/>Tích hợp hóa đơn điện tử<br/>Accounting Owner và Architect"] --> F2{"Đã được Accounting Owner và Architect xác minh?"}
    F2 -- "Chưa" --> G2["Chặn tuyên bố phương án tích hợp được hóa đơn điện tử"]
    F2 -- "Đã xác minh" --> H2["Cập nhật nguồn và trạng thái"]
    H2 --> C

    D3["NF-VERIFY-003<br/>Thẩm quyền phê duyệt đơn bán<br/>Sales Owner"] --> F3{"Đã được Sales Owner xác minh?"}
    F3 -- "Chưa" --> G3["Chặn thiết kế workflow như rule đã chốt"]
    F3 -- "Đã xác minh" --> H3["Cập nhật nguồn và trạng thái"]
    H3 --> C

Applied

Trường áp dụng	Nội dung
Facts	Nova Foods mô phỏng có WH-HCM-01, WH-BD-01, PLANT-BD-01, hàng FG-NF-001 và lô LOT-NF-202608-001.
Current Behavior	Chưa có evidence canonical về cách xuất kho FEFO, phê duyệt đơn bán hoặc tích hợp hóa đơn điện tử.
Underlying Need	BA cần phân biệt dữ liệu đã có nguồn với giả định và điểm chưa xác minh trước khi đánh giá phương án.
Options	Chấm mọi tiêu chí như yêu cầu đã chốt; hoặc giữ tiêu chí chưa xác minh ở trạng thái mở.
Decision Criteria	Chỉ nguồn canonical hoặc xác minh từ đúng owner mới được dùng làm cơ sở kết luận.
Decision	Giữ NF-VERIFY-001, NF-VERIFY-002, NF-VERIFY-003 là Cần xác minh.
Authority	Supply Chain Owner, Sales Owner, Accounting Owner, Architect, Legal Owner theo từng nội dung.
Artifact	Bảng đầu vào section 4 tại /02-handbook/16-solution-options-tradeoffs-and-recommendations.md.
Consequence if Wrong	Phương án có thể bị chấm sai, biến giả định học liệu thành cam kết vận hành hoặc kết luận pháp lý không có thẩm quyền.

Senior Lens

IN_REVIEW chỉ nói artifact đang được xem xét. Nó không chứng minh dữ liệu đúng, đã baseline, được phê duyệt, tuân thủ pháp luật hay sẵn sàng production. Một ô có nhãn Cần xác minh vẫn là đầu vào hữu ích: nó ngăn BA lấp khoảng trống bằng suy đoán và chỉ rõ owner phải cung cấp evidence nào.

Quick Reference

Nhãn	Nghĩa sử dụng
Controlled planning artifact	Nguồn quản trị corpus, dùng giữ ID, phạm vi và traceability
Primary professional source	Nguồn chuyên môn gốc, dùng thuật ngữ và khung BA
Official legal source	Nguồn pháp lý chính thức; diễn giải áp dụng cần owner có thẩm quyền
Project assumption	Giả định mô phỏng, không phải fact vận hành
Unresolved verification item	Điểm chưa có evidence đủ; không dùng làm kết luận phương án

5. Step-by-step BA Activities

Core

BA thực hiện đánh giá phương án theo chuỗi kiểm soát: chuẩn bị đầu vào, tách fact khỏi giả định, lập phương án, chấm theo tiêu chí, xử lý điểm chưa xác minh, review và handoff có kiểm soát. Evidence là bằng chứng có thể kiểm tra lại, không phải ý kiến ghi nhớ. Decision rule là quy tắc quyết định trước khi chọn phương án. Quality gate là điều kiện tối thiểu để bước được chuyển tiếp.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Phạm vi: đánh giá phương án xử lý điểm chưa xác minh NF-VERIFY-001, NF-VERIFY-002, NF-VERIFY-003; không xác nhận cấu hình ERP, nghĩa vụ pháp lý hay quyết định vận hành thực tế.

Thành phần	Nội dung
Facts	/01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md đều có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Current Behavior	Chưa có baseline reference hoặc approval reference. Các điểm NF-VERIFY-001, NF-VERIFY-002, NF-VERIFY-003 còn cần xác minh từ đúng owner.
Underlying Need	Cần chọn cách ghi nhận và xử lý điểm thiếu evidence mà không biến giả định học liệu thành requirement ERP hoặc kết luận thuộc thẩm quyền chuyên môn khác.
Options	Giữ điểm chưa xác minh ở trạng thái mở; hoặc chấm chúng như fact đã xác nhận.
Decision Criteria	Chỉ source canonical hoặc evidence từ owner có thẩm quyền được dùng làm cơ sở kết luận. IN_REVIEW không đủ điều kiện thay thế baseline hay approval.
Decision	Giữ ba điểm NF-VERIFY-001, NF-VERIFY-002, NF-VERIFY-003 ở trạng thái Cần xác minh; không đưa chúng thành tiêu chí chấm đạt.
Authority	Supply Chain Owner, Sales Owner, Accounting Owner, Architect, Legal Owner theo nội dung từng điểm.
Artifact	/02-handbook/16-solution-options-tradeoffs-and-recommendations.md, liên kết ngược tới các artifact canonical nêu trên.
Consequence if Wrong	BA có thể chọn phương án trên giả định, tạo traceability sai, hoặc diễn đạt kết luận pháp lý, kế toán, kiến trúc như fact.

1. Principal IT Business Analyst / Technical Curriculum Author kiểm tra phạm vi đánh giá, phiên bản và trạng thái của object nguồn. Object gồm /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md và các điểm NF-VERIFY-001 đến NF-VERIFY-003. Evidence tạo ra là danh sách đầu vào có đường dẫn, IN_REVIEW, v0.9.0, 2026-08-07. Decision rule: chỉ dùng ID và filename đúng canonical. Quality gate: không có ID mới, filename biến thể hoặc source không phân loại. Escalation route: source mâu thuẫn hoặc ID không tra được gửi Principal IT Business Analyst / Technical Curriculum Author để bảo toàn registry.

2. BA phân loại từng phát biểu thành fact, project assumption hoặc unresolved verification item. Object là nội dung liên quan vận hành, dữ liệu, kế toán, pháp lý hoặc kiến trúc Nova Foods mô phỏng. Evidence tạo ra là bảng phân loại kèm nguồn và lý do: IN_REVIEW chứng minh trạng thái review, không chứng minh nội dung đã được xác nhận. Decision rule: thiếu nguồn canonical hoặc evidence từ owner thì gắn Cần xác minh. Quality gate: mỗi suy luận có cầu nối evidence-reasoning. Escalation route: nội dung chạm pháp lý gửi Legal Owner; kế toán gửi Accounting Owner; kiến trúc gửi Architect.

3. BA xác định nhu cầu quyết định và ranh giới quyết định. Object là câu hỏi: xử lý điểm chưa xác minh thế nào khi so sánh phương án. Evidence tạo ra là problem statement: “Không dùng điểm chưa xác minh làm fact chấm phương án.” Decision rule: nhu cầu phải mô tả kết quả cần đạt, không gài sẵn giải pháp. Quality gate: câu hỏi không biến thành yêu cầu production, cam kết tuân thủ hoặc quyết định ERP thực tế. Escalation route: nhu cầu có tác động vận hành gửi Business Owner phù hợp.

4. BA lập các phương án loại trừ nhau và mô tả hệ quả. Object gồm phương án giữ điểm mở để xác minh và phương án coi điểm mở là fact. Evidence tạo ra là option list, phạm vi áp dụng, lợi ích, rủi ro và dependency. Decision rule: mỗi phương án phải có thể so sánh theo cùng tiêu chí. Quality gate: không có phương án trùng nghĩa, không có “không làm gì” bị che thành quyết định. Escalation route: phương án thay đổi luồng tích hợp hoặc dữ liệu gửi Architect; phương án ảnh hưởng kiểm soát tài chính gửi Accounting Owner.

5. BA chấm phương án theo tiêu chí evidence sufficiency, traceability, thẩm quyền và rủi ro diễn giải sai. Object là option list và bảng evidence. Evidence tạo ra là decision record nêu tiêu chí, kết quả chấm và reasoning bridge. Decision rule: phương án không có evidence đủ không được kết luận là đúng; phải ghi là Cần xác minh hoặc loại khỏi quyết định. Quality gate: kết quả không gọi IN_REVIEW là approved hoặc baselined. Escalation route: tiêu chí mâu thuẫn giữa các owner gửi các owner liên quan; BA chỉ ghi nhận mâu thuẫn và không tự phân xử chuyên môn.

6. Reviewer theo đúng thẩm quyền review decision record. Object là facts, current behavior, underlying need, options, criteria, decision và consequence if wrong. Evidence tạo ra là review comment có owner, phạm vi và điểm cần xác minh; review không tạo approval. Decision rule: comment chỉ đóng khi có evidence mới hoặc owner xác định rõ phạm vi. Quality gate: không có fabricated quotation, fabricated clause hoặc suy diễn luật từ source seed. Escalation route: nội dung pháp lý cần diễn giải áp dụng gửi Legal Owner; nội dung an toàn thực phẩm hoặc truy xuất gửi domain owner và Legal Owner.

7. BA handoff có kiểm soát sang bước đánh giá chi tiết. Object là decision record đã review cùng danh sách điểm mở. Evidence tạo ra là handoff package gồm source path, canonical ID, trạng thái IN_REVIEW, decision rationale, owner cần xác minh và giới hạn sử dụng. Decision rule: handoff chỉ chuyển nội dung có traceability; điểm mở giữ nhãn Cần xác minh. Quality gate: package không tuyên bố baseline, approval, compliance hoặc production readiness. Escalation route: thiếu owner, thiếu evidence hoặc thay đổi scope gửi Principal IT Business Analyst / Technical Curriculum Author để cập nhật kiểm soát artifact.

Senior Lens

Senior BA không “lấp chỗ trống” để bảng phương án trông hoàn chỉnh. Evidence yếu làm quyết định yếu, dù cách chấm có đẹp. Khi authority chưa rõ, quyết định đúng là dừng kết luận chuyên môn, giữ traceability và chuyển đúng escalation route.

Quick Reference

Kiểm tra	Đạt khi
Source control	Dùng đúng canonical ID và filename
Evidence control	Fact, giả định và điểm cần xác minh tách riêng
Decision control	Tiêu chí có trước kết luận
Authority control	Legal, Accounting, Architect và Business Owner xử lý nội dung thuộc thẩm quyền
Handoff control	Điểm mở, owner và trạng thái IN_REVIEW đi cùng artifact

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. BA không chọn phương án thay người có thẩm quyền. BA làm rõ lựa chọn, bằng chứng, tiêu chí và hệ quả để đúng vai trò quyết định chọn phương án.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	Business Analyst	Đọc mục tiêu, vấn đề, ràng buộc và artifact nguồn; lập danh sách điểm chưa rõ.	Problem statement, scope, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.	Log đầu vào, danh sách giả định, danh sách câu hỏi.	Không biến giả định thành fact. Mỗi nhận định phải gắn nguồn hoặc nhãn Verification required.	Nguồn có đường dẫn canonical; status nguồn vẫn IN_REVIEW; không có ID mới tự tạo.	Xung đột nguồn hoặc thiếu chủ sở hữu nghiệp vụ: Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề; chuyển Business Owner.
2. Xác nhận fact và hành vi hiện tại	Business Analyst cùng SME nghiệp vụ	Tách fact quan sát được khỏi diễn giải; mô tả current behavior bằng điều kiện, tác nhân, dữ liệu vào và kết quả.	Quy trình ERP mô phỏng Nova Foods, mẫu dữ liệu tổng hợp.	Bảng Facts và Current Behavior, liên kết nguồn.	Fact phải kiểm tra được từ artifact hoặc mô phỏng được xác định rõ; ý kiến không phải fact.	Mỗi dòng có nguồn, ngày 2026-08-07, phạm vi và người cung cấp thông tin.	Tranh chấp về hành vi nghiệp vụ: Business Owner quyết định; BA giữ cả hai cách hiểu trong issue log.
3. Suy ra underlying need	Business Analyst	Hỏi “vì sao hành vi hiện tại không đạt mục tiêu”; nối fact với tác động đo được hoặc rủi ro.	Facts, mục tiêu nghiệp vụ, pain point.	Need statement, reasoning bridge: fact, tác động, nhu cầu.	Need mô tả kết quả cần đạt, không khóa sớm vào màn hình, API hay nhà cung cấp.	Không có solution name trong need statement; tác động không bị suy diễn ngoài bằng chứng.	Cần diễn giải kế toán, thuế, pháp lý, an toàn thực phẩm hoặc dữ liệu cá nhân: chuyển Accounting Owner, Legal Owner, Compliance Owner hoặc domain owner.
4. Lập phương án tối thiểu	Business Analyst phối hợp Solution Architect	Liệt kê phương án gồm giữ nguyên, thay đổi cấu hình, thay đổi quy trình, tích hợp hoặc phát triển; chỉ giữ phương án đáp ứng need.	Underlying Need, ràng buộc ERP, dữ liệu, tích hợp.	Options register, phạm vi bị ảnh hưởng, phụ thuộc, rủi ro.	Luôn xét “không thay đổi” trước. Ưu tiên cấu hình nền tảng trước phát triển mới khi cùng đáp ứng need và không phá kiểm soát.	Mỗi option nêu lợi ích, chi phí/rủi ro, dữ liệu ảnh hưởng, owner kỹ thuật; không khẳng định khả thi nếu chưa có xác minh.	Nghi ngờ kiến trúc, bảo mật, hiệu năng hoặc API: Solution Architect và Security Owner xác minh; tham chiếu OWASP chỉ là good practice, không phải xác nhận tuân thủ.
5. Chấm tiêu chí và khuyến nghị	Business Analyst	So sánh option theo tiêu chí đã công bố trước khi chấm: đáp ứng need, rủi ro, khả năng vận hành, tác động dữ liệu, chi phí mô phỏng, thời gian và traceability.	Options register, decision criteria.	Decision matrix, recommendation, lý do loại từng option.	Không chọn option có điểm cao nếu vi phạm ràng buộc bắt buộc. Không dùng điểm số để che thiếu bằng chứng.	Trọng số, thang điểm, dữ liệu đầu vào và ngoại lệ đều nhìn thấy được; recommendation truy ngược được tới fact và need.	Tiêu chí mâu thuẫn giữa bộ phận: Business Owner ưu tiên; Architect quyết định phần kiến trúc trong thẩm quyền; BA không tự hòa giải thành quyết định.
6. Review và handoff có kiểm soát	Business Analyst	Review tính đầy đủ, ghi nhận phản hồi, đóng hoặc mở issue; chuyển package cho vai trò tiếp nhận.	Decision package, issue log, traceability links.	Review record, handoff record, danh sách open items và owner.	Handoff chỉ hoàn tất khi người nhận xác nhận đã nhận artifact; việc nhận không phải approval hay baseline.	Không có fact không nguồn; không có quyết định vượt thẩm quyền; mọi Verification required còn mở có owner và hạn xử lý.	Thiếu người nhận, thiếu thẩm quyền, hoặc yêu cầu gọi nội dung là approved/baselined: dừng handoff quyết định; chuyển Principal IT Business Analyst / Technical Curriculum Author để giữ traceability và yêu cầu owner có thẩm quyền.

Bằng chứng dẫn tới khuyến nghị phải giữ chuỗi: fact có nguồn xác định, fact cho thấy tác động, tác động chứng minh need, need là tiêu chí loại hoặc chọn option. Đứt một mắt xích thì kết luận chỉ là giả định, phải gắn Verification required.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây tổng hợp, tiền tệ VND. Bảng biến facts thành lựa chọn: facts chứng minh hành vi hiện tại; tiêu chí đo nhu cầu; quyết định chỉ hợp lệ trong IN_REVIEW, không là baseline hay phê duyệt.

Mục	Thực thi Nova Foods	Bằng chứng và cầu nối suy luận
Facts	Đơn bán SO-SIM-260807-014 gồm 500 thùng thành phẩm NF-MILK-01; kho còn 300 thùng lô LOT-SIM-260801-A, 250 thùng lô LOT-SIM-260802-B.	Dữ liệu tổng hợp cho thấy tổng tồn 550 thùng, nhưng không tự chứng minh lô nào được phép xuất trước.
Current Behavior	Nhân viên kho chọn lô thủ công trên phiếu xuất. ERP chỉ kiểm tra tổng tồn.	Tổng tồn đủ nhưng không có kiểm soát thứ tự lô; sai khác có thể chỉ xuất hiện khi đối chiếu sau giao hàng.
Underlying Need	Kiểm soát cấp phát lô theo quy tắc nghiệp vụ, giữ truy vết đơn hàng, lô xuất và giao dịch kho.	Nhu cầu suy ra từ chênh lệch giữa kiểm tra tổng tồn và yêu cầu chứng minh lô đã cấp phát. Đây không phải kết luận tuân thủ pháp lý.
Options	O1: giữ chọn lô thủ công; O2: ERP đề xuất lô theo ngày nhập tăng dần, kho xác nhận; O3: ERP tự động khóa lô theo ngày nhập tăng dần.	Ba phương án khác nhau ở mức tự động hóa, quyền ngoại lệ và rủi ro sai thao tác.
Decision Criteria	Truy vết lô; ngăn xuất vượt tồn; xử lý lô bị chặn; khả năng kho xử lý ngoại lệ; tác động tích hợp tồn kho.	Tiêu chí đo trực tiếp nhu cầu, không dùng sở thích cá nhân làm căn cứ.
Decision	Chọn O2 cho thiết kế đang xem xét: ERP đề xuất LOT-SIM-260801-A 300 thùng và LOT-SIM-260802-B 200 thùng; kho được đổi lô khi ghi lý do.	O2 giữ kiểm soát hệ thống nhưng còn đường xử lý thực tế. Quy tắc thứ tự lô và lý do đổi lô cần Business Owner xác nhận.
Authority	Business Owner xác nhận quy tắc cấp phát; Solution Architect xác nhận khả năng ERP và tích hợp; QA xác nhận tiêu chí kiểm thử; Legal/Compliance Owner xác minh nghĩa vụ truy xuất nếu áp dụng.	BA ghi rõ người có thẩm quyền vì BA không tự xác nhận vận hành, pháp lý hoặc kiến trúc.
Artifact	Ghi phương án, tiêu chí, quyết định đang xem xét và liên kết nguồn vào /02-handbook/16-solution-options-tradeoffs-and-recommendations.md; tham chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.	Các artifact canonical giữ nguồn chân lý riêng; chương handbook không thay thế catalog quy tắc hay từ điển dữ liệu.
Consequence if Wrong	Chọn O1 có thể không phát hiện cấp phát sai lô trước giao hàng. Chọn O3 có thể chặn xuất hợp lệ khi có ngoại lệ kho chưa được mô hình hóa.	Sai lựa chọn tạo rủi ro khác nhau; vì vậy không được gọi O2 là phương án đã phê duyệt.

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

flowchart TD
    REVIEW["O2 đang IN_REVIEW"]
    REVIEW --> BO["Business Owner xác nhận quy tắc cấp phát và yêu cầu lý do đổi lô"]
    BO --> ARCH["Solution Architect xác nhận khả năng ERP và tích hợp"]
    ARCH --> QA["QA xác nhận tiêu chí kiểm thử"]
    QA --> LAW{"Nghĩa vụ truy xuất có áp dụng?"}
    LAW -->|"Có"| LEGAL["Legal hoặc Compliance Owner xác minh nghĩa vụ"]
    LAW -->|"Không"| STATUS
    LEGAL --> STATUS["Các xác nhận không phải phê duyệt vận hành"]
    STATUS --> BOUNDARY["O2 vẫn IN_REVIEW và luồng sau chỉ là thiết kế dự kiến"]

    BOUNDARY --> RULE_READY{"Quy tắc cấp phát đã được Business Owner xác nhận?"}
    RULE_READY -->|"Không"| WAIT_RULE["Chờ quyết định về quy tắc và không cấp phát"]
    RULE_READY -->|"Có"| ORDER["Nhận đơn 500 thùng"]
    ORDER --> STOCK{"Tổng tồn có đủ 500 thùng?"}
    STOCK -->|"Không"| STOP["Chặn cấp phát và ghi thiếu tồn"]
    STOCK -->|"Có"| PROPOSE["ERP đề xuất lô A 300 thùng và lô B 200 thùng"]

    PROPOSE --> CANDIDATE["Kiểm tra từng lô và số lượng đề xuất"]
    CANDIDATE --> BLOCKED{"Lô đang kiểm tra bị chặn?"}
    BLOCKED -->|"Có"| REPLACE["Kho chọn lô thay thế và số lượng"]
    BLOCKED -->|"Không"| AVAILABLE{"Tồn khả dụng của lô đủ cho số lượng chọn?"}
    REPLACE --> REASON["Ghi lý do đổi lô và trạng thái cần Business Owner xác nhận"]
    REASON --> BLOCKED

    AVAILABLE -->|"Không"| NEXT["Chọn lô tiếp theo hoặc giảm số lượng lấy từ lô"]
    NEXT --> BLOCKED
    AVAILABLE -->|"Có"| RULE{"Lô và thứ tự cấp phát đúng quy tắc?"}
    RULE -->|"Không"| EXCEPTION["Ghi lý do đổi lô và trạng thái cần Business Owner xác nhận"]
    RULE -->|"Có"| COUNT["Cộng số lượng từ lô hợp lệ"]
    EXCEPTION --> COUNT

    COUNT --> SUM{"Tổng số lượng khả dụng từ các lô hợp lệ đủ 500?"}
    SUM -->|"Không"| MORE["ERP hoặc kho chọn lô tiếp theo và số lượng"]
    MORE --> BLOCKED
    SUM -->|"Có"| ALLOC["Ghi cấp phát và giao dịch kho"]
    ALLOC --> TRACE["Giữ liên kết đơn hàng lô và giao dịch"]

6. Output thu ???c

Core

Output là artifact được tạo hoặc cập nhật để biến phân tích phương án thành thông tin có thể truy vết. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. IN_REVIEW nghĩa là đang xem xét có kiểm soát, không phải APPROVED, BASELINED, sẵn sàng production, hay được người dùng chấp thuận.

Artifact tạo/cập nhật	Owner	Status	Nội dung tối thiểu	ID, nguồn canonical	Nghĩa vụ lịch sử thay đổi
Hồ sơ phân tích phương án trong /02-handbook/16-solution-options-tradeoffs-and-recommendations.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Vấn đề, phương án, tiêu chí, trade-off, giả định, rủi ro, quyết định đang xem xét, thẩm quyền cần xác nhận	Đường dẫn tệp là định danh canonical; tham chiếu TRACEABILITY_ID_REGISTRY	Ghi version, ngày 2026-08-07, người ghi nhận, nội dung đổi, lý do đổi, liên kết artifact bị ảnh hưởng
Bản cập nhật quy tắc nghiệp vụ	Owner của CANONICAL_BUSINESS_RULES	IN_REVIEW	Quy tắc bị ảnh hưởng, điều kiện kích hoạt, ngoại lệ, nguồn chứng cứ, trạng thái xác minh, authority cần xác nhận	CANONICAL_BUSINESS_RULES; không tạo rule ID mới ngoài registry	Ghi rule cũ/mới, lý do, nguồn, tác động requirement và test basis
Bản cập nhật từ điển dữ liệu logic	Owner của CANONICAL_DATA_DICTIONARY	IN_REVIEW	Entity, field, định nghĩa, kiểu logic, nguồn dữ liệu, liên kết quy tắc và tác động tích hợp	CANONICAL_DATA_DICTIONARY; ID field/entity theo TRACEABILITY_ID_REGISTRY	Ghi field thay đổi, lý do, tương thích dữ liệu, consumer bị ảnh hưởng
Bản cập nhật liên kết truy vết	Owner của TRACEABILITY_ID_REGISTRY	IN_REVIEW	Liên kết vấn đề, phương án, rule, data, requirement, rủi ro và authority	TRACEABILITY_ID_REGISTRY là nguồn ID canonical	Ghi liên kết thêm, sửa, ngừng dùng; không tái sử dụng ID đã đăng ký
Gói điểm cần xác minh chuyên môn	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Câu hỏi, chứng cứ hiện có, khoảng trống, vai trò cần xác nhận, hậu quả nếu không xác minh	Tham chiếu artifact nguồn; không thay kết luận Legal, Accounting, Security, Architect hay Business Owner	Ghi thời điểm phát hiện, thay đổi phạm vi, phản hồi được ghi nhận nếu có

Applied

Trường	Nội dung Nova Foods mô phỏng
Facts	Đơn SO-SIM-260807-014 cần 500 thùng. Tồn tổng mô phỏng là 550 thùng, gồm LOT-SIM-260801-A 300 thùng và LOT-SIM-260802-B 250 thùng.
Current Behavior	Phân tích trước đó nêu ba phương án cấp phát lô: kiểm tra tổng tồn, đề xuất FEFO có thể sửa, hoặc chặn ngoại lệ.
Underlying Need	Cần giữ liên kết đơn hàng, lô và giao dịch kho để reviewer đánh giá trade-off giữa kiểm soát truy xuất và khả năng xử lý ngoại lệ kho.
Options	O1 kiểm tra tổng tồn; O2 đề xuất FEFO và cho ghi lý do đổi lô; O3 chặn mọi đổi lô.
Decision Criteria	Khả năng truy vết, vận hành kho, rủi ro giao sai lô, khả năng ERP, khả năng kiểm thử.
Decision	Ghi nhận O2 là phương án đang xem xét. Lý do: O2 giữ đề xuất có kiểm soát và lưu lý do ngoại lệ; O1 thiếu kiểm soát lô, O3 có thể chặn ngoại lệ hợp lệ chưa được mô hình hóa.
Authority	Business Owner xác nhận quy tắc cấp phát; Solution Architect xác nhận khả năng ERP; QA xác nhận test basis; Legal/Compliance Owner xác minh nghĩa vụ truy xuất nếu áp dụng.
Artifact	Cập nhật /02-handbook/16-solution-options-tradeoffs-and-recommendations.md; liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	O1 có thể giao sai lô mà không phát hiện sớm. O3 có thể chặn giao hợp lệ. O2 thiếu lý do đổi lô sẽ làm đứt truy vết.

Senior Lens

BA tạo output để giữ ranh giới quyết định. BA ghi phương án và chứng cứ; không tự biến phương án thành quy tắc vận hành, kết luận pháp lý, quyết định kế toán, xác nhận kiến trúc, hay phê duyệt. Nếu một thay đổi đồng thời ảnh hưởng rule, data và tích hợp, phải cập nhật liên kết trong TRACEABILITY_ID_REGISTRY; ghi riêng từng artifact tránh handbook trở thành nguồn chân lý thay thế.

Quick Reference

• Giữ nguyên ID và đường dẫn canonical.
• Mọi artifact mới hoặc cập nhật giữ IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.
• Lịch sử thay đổi phải nêu: thay đổi gì, vì sao, ai ghi nhận, artifact nào bị ảnh hưởng.
• Nova Foods chỉ là mô phỏng giáo dục, dữ liệu tổng hợp; không suy ra cấu hình ERP hay nghĩa vụ pháp lý thực tế.

Applied

Output của phân tích phương án không phải quyết định đã có hiệu lực. Output là gói bằng chứng để vai trò có thẩm quyền review: nêu vấn đề, phương án, tiêu chí, khuyến nghị, tác động và liên kết nguồn. Nova Foods Trading & Manufacturing là case mô phỏng; mọi số liệu dưới đây là dữ liệu tổng hợp.

Thành phần output	Artifact canonical cập nhật	ID canonical	Nội dung phải có trong output	Giá trị Nova Foods mô phỏng
Bản ghi phương án và khuyến nghị	/02-handbook/16-solution-options-tradeoffs-and-recommendations.md	Chưa có Artifact ID được nguồn cung cấp xác nhận	Vấn đề, phạm vi, phương án, tiêu chí, điểm mạnh, giới hạn, khuyến nghị, thẩm quyền review, hệ quả	Đề xuất chặn xuất kho khi lô thành phẩm chưa có trạng thái QC đạt
Liên kết quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	CANONICAL_BUSINESS_RULES	Quy tắc bị ảnh hưởng, điều kiện kích hoạt, ngoại lệ, owner nghiệp vụ cần xác nhận	Quy tắc dự kiến: chỉ lô có QC status PASS mới được cấp phát cho Sales Order
Liên kết dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	CANONICAL_DATA_DICTIONARY	Thực thể, trường dữ liệu, trạng thái, nguồn cập nhật, tác động dữ liệu	Thực thể ProductionLot; trường dự kiến qc_status; giá trị dự kiến PENDING, PASS, FAIL
Liên kết truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	TRACEABILITY_ID_REGISTRY	Nguồn phát hiện, nhu cầu, phương án, khuyến nghị, artifact đích	Nguồn là quan sát quy trình mô phỏng; chưa liên kết requirement canonical vì requirement chưa được cung cấp
Lịch sử thay đổi	Artifact chứa output	ID artifact tương ứng	Ngày, version, người ghi nhận, thay đổi, lý do, tác động traceability	2026-08-07, v0.9.0, Principal IT Business Analyst / Technical Curriculum Author, khởi tạo phân tích phương án, chưa thay đổi baseline

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

flowchart TB
    A[Khuyến nghị O2 đang chờ review<br/>Không phải quy tắc hiệu lực hoặc cấu hình production]
    A --> B[Sales Order cần xuất hàng]
    B --> C{ProductionLot.qc_status}

    C -->|PASS| D[Đề xuất: cho phép cấp phát lô]
    C -->|PENDING hoặc FAIL| E[Đề xuất: chặn cấp phát lô]
    E --> F[Hiển thị lý do cho Sales]
    F --> G[QA/QC cập nhật qc_status của ProductionLot]
    G --> C

    H[Ngoại lệ: chưa xác nhận<br/>Không suy ra mọi trạng thái khác PASS bị chặn vĩnh viễn] -.-> E
    I[QA/QC Owner xác nhận nghĩa trạng thái<br/>PASS, PENDING, FAIL] -.-> C
    J[Business Owner xác nhận quy tắc vận hành] -.-> E
    K[Solution Architect xác nhận điểm chặn kỹ thuật] -.-> E
    L[Security Owner review quyền đổi qc_status] -.-> G

    M[Rủi ro chặn quá rộng:<br/>chậm giao hàng hợp lệ] -.-> E
    N[Rủi ro chặn quá hẹp:<br/>lô chưa đạt QC được cấp phát] -.-> C

Trường Applied bắt buộc	Nội dung đã điền
Facts	Sales có thể chọn lô thành phẩm trước khi QC hoàn tất trong quy trình mô phỏng. Dữ liệu cần để phân biệt lô là mã lô và qc_status.
Current Behavior	Hệ thống giả định chỉ cảnh báo người dùng khi qc_status là PENDING; người dùng vẫn có thể tiếp tục cấp phát.
Underlying Need	Ngăn lô chưa đạt QC đi vào giao hàng. Suy luận này dựa trên chênh lệch: cảnh báo không ngăn thao tác, còn mục tiêu kiểm soát cần ngăn thao tác.
Options	O1: giữ cảnh báo. O2: chặn cấp phát khi trạng thái khác PASS. O3: cho phép cấp phát nhưng gửi báo cáo cuối ngày.
Decision Criteria	Hiệu lực ngăn lỗi, khả năng audit, tác động vận hành Sales, phụ thuộc tích hợp, khả năng xử lý ngoại lệ.
Decision	Khuyến nghị O2. Chặn tại bước cấp phát tạo kiểm soát trước giao hàng; O1 và O3 chỉ phát hiện hoặc nhắc sau khi thao tác có thể đã xảy ra. Đây là khuyến nghị review, không phải cấu hình ERP.
Authority	Business Owner xác nhận quy tắc vận hành; QA/QC Owner xác nhận nghĩa trạng thái QC; Solution Architect xác nhận điểm kiểm soát kỹ thuật; Security Owner review quyền đổi qc_status.
Artifact	Bản ghi phương án trong /02-handbook/16-solution-options-tradeoffs-and-recommendations.md; liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Chặn quá rộng có thể làm chậm giao hàng hợp lệ. Chặn quá hẹp có thể cho phép lô chưa đạt QC được cấp phát. Vì trạng thái QC và ngoại lệ chưa được vai trò thẩm quyền xác nhận, không được gọi thiết kế này là production-ready.

Core

Cổng chất lượng (quality gate) xác nhận output đủ rõ, đủ truy vết, đủ kiểm tra để chuyển sang downstream review, tức bước xem xét tiếp theo. Cổng này không phải approval, baseline, xác nhận tuân thủ, production readiness hay quyết định vận hành Nova Foods. Nova Foods là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Điều kiện cổng	Kiểm tra bắt buộc	Bằng chứng đạt	Không đạt khi
Nhận diện	ID, tên tệp, Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh khớp artifact kiểm soát	Liên kết đúng artifact canonical	Dùng ID mới chưa có trong TRACEABILITY_ID_REGISTRY hoặc đổi tên tệp
Nguồn gốc	Mỗi kết luận chỉ rõ fact, giả định, nguồn hoặc điểm cần xác minh	Fact không bị trình bày thành quy định	Suy diễn pháp lý, kế toán, thuế, an toàn thực phẩm thành nghĩa vụ đã xác nhận
So sánh	Mọi phương án có cùng tiêu chí, phạm vi, tác động và giới hạn	Reviewer so sánh được trên cùng cơ sở	Một phương án thiếu chi phí, rủi ro, dependency hoặc consequence
Quyết định	Khuyến nghị nêu lý do liên kết tiêu chí; authority chỉ là vai trò cần xem xét	Không gán quyết định cho BA hoặc Owner	Ghi “đã phê duyệt”, “đã chấp thuận”, “sẵn sàng production”
Truy vết	Thay đổi có ngày, người ghi nhận, lý do, artifact bị ảnh hưởng	Change history không bị sửa im lặng	Kết luận thay đổi nhưng không cập nhật lịch sử

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

flowchart TB
    A[Output IN_REVIEW] --> B{Nhận diện: ID, tên tệp, Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07 và Asia/Ho_Chi_Minh khớp artifact canonical; ID có trong TRACEABILITY_ID_REGISTRY?}
    B -- Không: ID mới, tên tệp hoặc metadata không khớp --> X1[Không đạt cổng: nhận diện không truy vết được]
    B -- Có --> C{Nguồn gốc: mỗi kết luận nêu fact, giả định, nguồn hoặc điểm cần xác minh; không suy diễn nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm?}
    C -- Không: thiếu nguồn gốc hoặc trình bày suy diễn thành nghĩa vụ đã xác nhận --> X2[Không đạt cổng: kết luận không đủ căn cứ]
    C -- Có --> D{So sánh: mọi phương án cùng tiêu chí, phạm vi, tác động, giới hạn, chi phí, rủi ro, dependency và consequence?}
    D -- Không: phương án thiếu cơ sở so sánh --> X3[Không đạt cổng: so sánh không cùng cơ sở]
    D -- Có --> E{Quyết định: khuyến nghị nêu lý do liên kết tiêu chí; authority chỉ là vai trò cần xem xét; không gán quyết định cho BA hoặc Owner?}
    E -- Không: thiếu lý do hoặc gán phê duyệt, chấp thuận, production readiness --> X4[Không đạt cổng: khuyến nghị vượt giới hạn authority]
    E -- Có --> F{Truy vết: thay đổi có ngày, người ghi nhận, lý do và artifact bị ảnh hưởng; change history không bị sửa im lặng?}
    F -- Không: thiếu thông tin thay đổi hoặc lịch sử bị sửa im lặng --> X5[Không đạt cổng: thay đổi không truy vết được]
    F -- Có --> G[Sẵn sàng downstream review]
    G --> H[Reviewer xem xét theo thẩm quyền]

Applied

Trường	Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	Bộ phận bán hàng cần giữ đơn khi khách vượt hạn mức tín dụng mô phỏng.
Current Behavior	Nhân viên kiểm tra hạn mức ngoài ERP bằng bảng tính.
Underlying Need	ERP cần chặn hoặc chuyển review đơn vượt hạn mức để giảm quyết định không nhất quán.
Options	O1: cảnh báo nhưng vẫn cho lưu; O2: chặn đơn; O3: chuyển đơn sang review tín dụng.
Decision Criteria	Kiểm soát rủi ro, thời gian xử lý đơn, khả năng truy vết, tác động cấu hình ERP.
Decision	Khuyến nghị O3 vì giữ kiểm soát và tạo điểm review; đây là khuyến nghị phân tích, không phải quyết định vận hành.
Authority	Business Owner và Credit/Finance Owner cần xem xét; Architect xác minh khả năng cấu hình.
Artifact	Output phải giữ ID canonical đã đăng ký, trạng thái IN_REVIEW, v0.9.0, change-history và liên kết tới CANONICAL_BUSINESS_RULES nếu có rule được đăng ký.
Consequence if Wrong	Chọn O1 có thể giảm kiểm soát; chọn O2 có thể chặn đơn hợp lệ; chọn O3 sai thiết kế có thể tạo tồn đọng review.

Output ví dụ qua cổng khi O1, O2, O3 đều có cùng tiêu chí, lý do O3 nêu rõ từ facts, và mọi giới hạn pháp lý hoặc kế toán giữ nhãn Verification required. Output chưa qua cổng nếu gọi O3 là “đã phê duyệt” hoặc suy diễn hạn mức tín dụng là quy định Nova Foods thực tế.

Senior Lens

Cổng chất lượng kiểm tra khả năng review, không kiểm tra tính đúng cuối cùng của quyết định. Lý do: reviewer cần input có cấu trúc để phản biện; reviewer mới có thẩm quyền xác nhận phần thuộc nghiệp vụ, kiến trúc, tài chính, pháp lý hoặc bảo mật. Nếu evidence thiếu, phải trả output về soạn thảo thay vì lấp khoảng trống bằng giả định không gắn nhãn.

Quick Reference

• Đạt cổng: định danh đúng, evidence rõ, so sánh công bằng, thay đổi truy vết được.
• Chưa đạt cổng: thiếu nguồn, thiếu tiêu chí, dùng ID chưa đăng ký, hoặc ngôn ngữ ngụ ý approval.
• Kết quả cổng: Ready for downstream review; vẫn là IN_REVIEW, không phải APPROVED hay BASELINED.

7. Who consumes those outputs?

Core

Output của phân tích phương án gồm: danh sách phương án, ma trận tiêu chí, bằng chứng, khuyến nghị, tác động và liên kết truy vết. Người nhận không “đọc để biết”; họ dùng output làm đầu vào công việc tiếp theo. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, trạng thái corpus là IN_REVIEW, phiên bản v0.9.0.

Consumer	Output tiêu thụ chính	Cách dùng trong công việc
Developers	Phương án được chọn, hành vi mong đợi, tác động dữ liệu và tích hợp	Chuyển thành cấu hình, code, API contract hoặc task kỹ thuật; không tự đổi rule nghiệp vụ.
QA	Tiêu chí quyết định, behavior từng phương án, consequence if wrong	Tạo test basis, test condition và kiểm tra regression giữa hành vi cũ với hành vi đề xuất.
Architect	Ma trận trade-off, tác động integration, data, security, performance	Đánh giá tính khả thi kỹ thuật và ranh giới kiến trúc trước khi thiết kế chi tiết.
PM/Product Owner	Khuyến nghị, tiêu chí ưu tiên, phạm vi tác động, dependency	Sắp thứ tự backlog, lập kế hoạch delivery và quản lý trade-off phạm vi, thời gian, chi phí.
Business Owner	Facts, underlying need, phương án và tác động nghiệp vụ	Đánh giá phương án có giải quyết đúng nhu cầu vận hành hay không.
Operations	Current behavior, quy trình mục tiêu, ngoại lệ và tác động thao tác	Chuẩn bị SOP, phân quyền vận hành, đào tạo và xử lý tình huống ngoại lệ.
Specialist owners	Phần evidence thuộc chuyên môn: Finance, Credit, Legal, Security, Food Safety	Review phần nằm trong thẩm quyền chuyên ngành; không suy diễn từ khuyến nghị BA thành kết luận chuyên môn.

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

flowchart TB
    ART["Artifact: phân tích phương án<br/>Phương án · ma trận tiêu chí · bằng chứng<br/>Khuyến nghị · tác động · liên kết truy vết"]

    DEV["Developers<br/>Chuyển thành cấu hình, code, API contract hoặc task kỹ thuật"]
    QA["QA<br/>Tạo test basis, test condition, kiểm tra regression"]
    ARC["Architect<br/>Đánh giá khả thi kỹ thuật và ranh giới kiến trúc"]
    PO["PM/Product Owner<br/>Sắp backlog, lập kế hoạch delivery, quản lý trade-off"]
    BO["Business Owner<br/>Đánh giá phương án giải quyết nhu cầu vận hành"]
    OPS["Operations<br/>Chuẩn bị SOP, phân quyền, đào tạo, xử lý ngoại lệ"]
    SO["Specialist owners<br/>Review evidence trong thẩm quyền chuyên môn"]

    ART -->|"Phương án chọn · hành vi · data · integration impact"| DEV
    ART -->|"Tiêu chí quyết định · behavior · consequence if wrong"| QA
    ART -->|"Trade-off matrix · integration · data · security · performance impact"| ARC
    ART -->|"Khuyến nghị · tiêu chí ưu tiên · impact · dependency"| PO
    ART -->|"Facts · underlying need · phương án · business impact"| BO
    ART -->|"Current behavior · target process · exceptions · operational impact"| OPS
    ART -->|"Evidence: Finance · Credit · Legal · Security · Food Safety"| SO

    DEV -.->|"Không tự đổi rule nghiệp vụ"| DEV
    SO -.->|"Không suy diễn khuyến nghị BA thành kết luận chuyên môn"| SO

Applied

Facts: Đơn bán hàng mô phỏng có tổng giá trị 85.000.000 VND; dữ liệu tổng hợp cho thấy quy trình hiện tại chỉ ghi trạng thái kiểm tra tín dụng bằng thao tác thủ công.

Current Behavior: Nhân viên có thể tiếp tục xử lý đơn khi chưa có điểm kiểm tra rõ trong ERP mô phỏng.

Underlying Need: Cần một phương án tạo điểm kiểm tra có thể truy vết mà không tự khẳng định đây là quy định tín dụng thực tế của Nova Foods.

Options: O1 cho phép tiếp tục đơn; O2 chặn đơn; O3 đưa đơn vào hàng chờ review.

Decision Criteria: Khả năng truy vết, tác động vận hành, nguy cơ chặn đơn hợp lệ, khả năng cấu hình và khả năng test.

Decision: Output khuyến nghị O3 để downstream review; không phải quyết định vận hành hay phê duyệt.

Authority: Business Owner tiêu thụ để xác nhận nhu cầu nghiệp vụ; Credit/Finance Owner tiêu thụ phần kiểm soát tín dụng; Architect tiêu thụ phần khả thi cấu hình; QA tiêu thụ behavior O3 để lập test basis.

Artifact: Ma trận phương án và khuyến nghị giữ liên kết tới CANONICAL_BUSINESS_RULES khi rule được đăng ký; giữ trạng thái IN_REVIEW, v0.9.0 và traceability.

Consequence if Wrong: Developer có thể cấu hình sai trạng thái; QA có thể bỏ sót đường đi review; Operations có thể xử lý đơn không nhất quán; Business Owner không nhận đủ thông tin để đánh giá tác động.

Senior Lens

Cùng một output phải đổi “góc đọc” theo vai trò. Developer cần hành vi có thể xây. QA cần điều kiện có thể kiểm thử. Architect cần tác động liên thành phần. Business Owner cần giá trị và rủi ro nghiệp vụ. Operations cần thao tác thực tế. Specialist owner cần bằng chứng đúng phạm vi chuyên môn. Lý do: một ma trận tốt nhưng thiếu góc đọc của người nhận sẽ tạo handoff có tệp đính kèm nhưng không tạo quyết định hoặc delivery đúng.

Quick Reference

Output	Người tiêu thụ đầu tiên	Kết quả mong đợi
Danh sách phương án	PM/Product Owner, Business Owner	Hiểu phạm vi lựa chọn.
Ma trận tiêu chí và trade-off	Architect, specialist owners	Review tác động theo chuyên môn.
Khuyến nghị phân tích	Business Owner, PM/Product Owner	Định hướng ưu tiên và review tiếp theo.
Hành vi phương án	Developers, QA, Operations	Build, test và vận hành nhất quán.
Liên kết traceability	QA, BA, PM/Product Owner	Theo dõi từ need đến thay đổi và kiểm thử.

Core

Đầu ra của phân tích phương án gồm bảng so sánh phương án, tiêu chí quyết định, khuyến nghị, giả định, rủi ro, phụ thuộc và liên kết truy vết. Mỗi vai trò không “phê duyệt toàn bộ” đầu ra. Họ dùng phần thuộc thẩm quyền để quyết định, kiểm tra bằng chứng và chuyển cấp điểm vượt quyền. Nova Foods là case mô phỏng; mọi dữ liệu là tổng hợp; trạng thái artifact IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07 không phải phê duyệt hay baseline.

Người tiêu thụ	Có thể quyết định	Bằng chứng phải cần	Phải escalation khi
Developers	Chọn cách hiện thực trong ràng buộc đã chọn; ước lượng kỹ thuật; nêu API, dữ liệu, lỗi và giới hạn xử lý.	Acceptance criteria, quy tắc trong CANONICAL_BUSINESS_RULES, trường dữ liệu trong CANONICAL_DATA_DICTIONARY, phụ thuộc tích hợp, khuyến nghị đã ghi rõ phạm vi.	Requirement mâu thuẫn; thiếu quy tắc; phương án làm đổi dữ liệu, quyền, chi phí hoặc trải nghiệm nghiệp vụ; cần ngoại lệ cho business rule.
QA	Chọn phạm vi kiểm thử, test condition và dữ liệu kiểm thử tổng hợp; xác định rủi ro cần regression test.	Acceptance criteria có thể kiểm thử, expected result, quy tắc nghiệp vụ, trạng thái dữ liệu, liên kết truy vết. Thuật ngữ kiểm thử dùng theo ISTQB CTFL v4.0.1.	Không có kết quả kỳ vọng; tiêu chí không đo được; rule mơ hồ; lỗi cho thấy khuyến nghị không đáp ứng nhu cầu gốc.
Architect	Đánh giá khả thi kiến trúc, tích hợp, hiệu năng, bảo mật, khả năng vận hành và nợ kỹ thuật.	Sơ đồ luồng/dữ liệu, interface contract, tải giả định, phân loại dữ liệu, ràng buộc hệ thống hiện hữu và rủi ro. Với API, cần đặc tả HTTP/OAS phù hợp; không suy diễn API từ bảng nghiệp vụ.	Lựa chọn tác động kiến trúc doanh nghiệp; tạo tích hợp mới; thay đổi kiểm soát truy cập; rủi ro bảo mật; chi phí nền tảng vượt ngưỡng được giao.
PM/Product Owner	Ưu tiên phương án, phạm vi release, thứ tự backlog và trade-off thời gian–chi phí–giá trị.	Mục tiêu nghiệp vụ, tiêu chí quyết định có trọng số hoặc thứ tự ưu tiên, ước lượng, phụ thuộc, rủi ro và hậu quả nếu không làm.	Cần đổi mục tiêu, ngân sách, mốc giao, phạm vi cam kết hoặc chấp nhận rủi ro nghiệp vụ lớn.
Business Owner	Quyết định phương án nào đáp ứng mục tiêu nghiệp vụ trong quyền hạn; xác nhận owner của quy tắc và ngoại lệ nghiệp vụ.	Current behavior, underlying need, tác động quy trình, chỉ số thành công, chi phí/rủi ro và giả định được ghi nhãn rõ.	Quyết định liên quan chính sách doanh nghiệp, giá bán, tín dụng, cam kết khách hàng, phân quyền trách nhiệm hoặc ngoại lệ có tác động tài chính.
Operations	Đánh giá khả năng chạy hằng ngày: thao tác, xử lý sự cố, báo cáo, phân quyền tác nghiệp, dữ liệu đầu vào và thời gian chốt.	Luồng vận hành, volume tổng hợp, cut-off giả định, cảnh báo, xử lý lỗi, hướng dẫn rollback và ownership sau bàn giao.	Phương án tăng thao tác thủ công, tạo điểm nghẽn, thiếu khả năng khôi phục, làm gián đoạn chuỗi cung ứng hoặc cần thay đổi quy trình vận hành thực.
Specialist owners	Kết luận phần chuyên môn thuộc lĩnh vực: Accounting, Legal, Security, Data, Food Safety hoặc Compliance.	Nguồn chính thức, dữ kiện phạm vi, dữ liệu bị ảnh hưởng, giả định dự án và câu hỏi quyết định cụ thể.	Có diễn giải pháp luật, thuế, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất hoặc kiểm soát bảo mật. BA chỉ ghi nhận quyết định và traceability, không thay kết luận chuyên môn.

Quy tắc bằng chứng: quyết định chỉ mạnh bằng liên kết giữa nhu cầu, tiêu chí và nguồn chứng minh. Ví dụ, chọn phương án “kiểm tra tồn kho trước xác nhận đơn” cần bằng chứng nhu cầu tránh bán vượt tồn, quy tắc tồn kho canonical nếu đã có, dữ liệu tồn kho cần đọc và giới hạn tích hợp. Nếu chỉ có nhận định “có vẻ nhanh hơn”, đó là giả định, không phải căn cứ quyết định.

Quy tắc escalation: chuyển cấp trước khi ghi khuyến nghị thành quyết định khi điểm tranh chấp làm thay đổi owner, quy tắc, dữ liệu, kiến trúc, nghĩa vụ chuyên môn, chi phí hoặc rủi ro. Gói escalation phải nêu: vấn đề, phương án, bằng chứng hiện có, giả định còn mở, vai trò có thẩm quyền và hậu quả của mỗi lựa chọn. Không gắn nhãn “đã phê duyệt” khi chưa có tham chiếu approval được ghi nhận.

Core

Handoff là bàn giao đầu ra giữa vai trò. Lỗi thường không nằm ở tệp thiếu, mà ở cùng một câu nhưng mỗi bên hiểu phạm vi khác nhau. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, mọi đầu ra còn IN_REVIEW, v0.9.0, ngày 2026-08-07; không được hiểu thành quyết định đã phê duyệt.

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

flowchart TB
    BA[BA ghi nhận phương án và trade-off] --> R[Người nhận đọc artifact]
    R --> Q{Phạm vi, tiêu chí, giả định,<br/>bằng chứng và vai trò trả lời rõ?}

    Q -->|Có| U[Dùng artifact cho bước công việc tiếp theo<br/>Không coi là phê duyệt]
    Q -->|Không| C[Hỏi làm rõ: thuật ngữ, phạm vi,<br/>bằng chứng và vai trò trả lời]
    C --> A{BA có thể làm rõ<br/>trong thẩm quyền?}

    A -->|Có| BA
    A -->|Không; chạm pháp lý, kế toán,<br/>an toàn thực phẩm, bảo mật,<br/>kiến trúc hoặc vận hành thực tế| E[Escalation đến specialist owner phù hợp]
    E --> V[Ghi Verification required<br/>và câu trả lời cần xác minh]
    V --> BA

Hiểu nhầm bàn giao	Vì sao sai	Câu hỏi làm rõ chính xác
“Khuyến nghị” bị hiểu là quyết định phải triển khai	Khuyến nghị chỉ là kết luận BA dựa trên tiêu chí và bằng chứng hiện có; không tự tạo thẩm quyền quyết định.	“Phương án này là khuyến nghị để xem xét, hay là quyết định đã được ghi nhận bởi vai trò có thẩm quyền? Nếu là quyết định, artifact nào ghi nhận người quyết định, ngày và phạm vi?”
“Không thay đổi quy trình” bị hiểu là không có thay đổi hệ thống	Quy trình nghiệp vụ có thể giữ bước chính nhưng thay đổi dữ liệu, quyền, tích hợp hoặc kiểm soát lỗi.	“Cụm ‘không thay đổi quy trình’ chỉ áp dụng luồng nghiệp vụ nào? Có thay đổi trường dữ liệu, phân quyền, API, báo cáo, đối soát hoặc xử lý ngoại lệ không?”
Tiêu chí “chi phí thấp” bị hiểu là chọn phương án rẻ nhất	Chi phí ban đầu không phản ánh chi phí vận hành, rủi ro lỗi, đào tạo và bảo trì.	“Chi phí đang tính gồm cấu hình, phát triển, kiểm thử, vận hành và xử lý lỗi chưa? Khoảng thời gian so sánh là bao lâu và dữ liệu nào là giả định?”
“Đáp ứng tuân thủ” bị hiểu là đã được xác nhận pháp lý	Nguồn pháp lý cần Legal Owner hoặc specialist owner diễn giải cho tình huống cụ thể.	“Yêu cầu này là project assumption, Verification required, hay kết luận đã được Legal Owner xác minh? Nguồn chính thức và phạm vi áp dụng nào hỗ trợ kết luận?”
“Tích hợp được” bị hiểu là API đã sẵn sàng	Khả năng kỹ thuật cần endpoint, hợp đồng dữ liệu, xác thực, lỗi và ownership; ý tưởng tích hợp chưa là thiết kế tích hợp.	“Hệ thống nguồn và đích nào tham gia? Hợp đồng API hoặc đặc tả dữ liệu nào xác định trường bắt buộc, xác thực, tần suất, retry và xử lý bản ghi lỗi?”
“Dữ liệu khách hàng” bị hiểu là một loại dữ liệu đồng nhất	Dữ liệu có thể gồm định danh, liên hệ, lịch sử mua và dữ liệu nhạy cảm; mỗi loại cần kiểm soát khác nhau.	“Trường dữ liệu nào được truyền, lưu hoặc hiển thị? Ai là owner phân loại dữ liệu và yêu cầu bảo vệ nào còn cần Verification required?”
“Chấp nhận được” bị hiểu là đủ điều kiện kiểm thử	Acceptance criteria cần điều kiện, hành động, kết quả quan sát được và biên lỗi; nhận xét chung không tạo test basis.	“Kết quả nào phải quan sát được để coi là đạt? Dữ liệu đầu vào, điều kiện biên, thông báo lỗi và dữ liệu sau xử lý là gì?”
“Giữ nguyên số dư” bị hiểu là BA xác nhận quy tắc kế toán	Số dư, bút toán và kỳ hạch toán thuộc thẩm quyền Accounting Owner; BA chỉ giữ traceability của vấn đề và phương án.	“Khái niệm ‘số dư’ là số dư nào, tại thời điểm nào, theo nguồn dữ liệu nào? Accounting Owner cần xác nhận quy tắc hạch toán hay đối soát nào?”

Quy tắc: câu hỏi phải chỉ rõ thuật ngữ mơ hồ, phạm vi bị ảnh hưởng, bằng chứng cần thấy và vai trò phải trả lời. “Có ổn không?” không đủ vì không xác định tiêu chí kiểm tra. Khi câu trả lời chạm pháp lý, kế toán, an toàn thực phẩm, bảo mật, kiến trúc hoặc vận hành thực tế, ghi Verification required và escalation; không tự chuyển giả định thành quy tắc Nova Foods.

8. Detailed Worked Example

Core

Ví dụ làm việc chi tiết biến khái niệm thành chuỗi bằng chứng kiểm tra được. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, mã, số lượng, thời điểm và dữ liệu dưới đây là tổng hợp. Nội dung không xác nhận cấu hình ERP thực tế, tuân thủ pháp lý hay phê duyệt từ bất kỳ vai trò nào.

Applied

Bối cảnh thống nhất: kho thành phẩm WH-HCM-01 của Nova Foods mô phỏng xuất hàng cho khách CUS-20018. Đơn bán hàng (Sales Order, yêu cầu bán đã được ghi nhận) có mã SO-20260807-0142, gồm sản phẩm sữa hạt FG-NF-ALM-1L, số lượng 120 thùng. Mỗi thùng có 12 hộp. Lô hàng được yêu cầu truy vết theo mã lô sản xuất.

Nhóm fact	Giá trị tổng hợp	Bằng chứng và phân loại
Thời điểm case	2026-08-07 09:15:00 Asia/Ho_Chi_Minh	Dữ liệu mô phỏng
Đơn bán hàng	SO-20260807-0142	Dữ liệu mô phỏng
Khách hàng	CUS-20018 — Siêu thị An Phú	Dữ liệu mô phỏng; không phải khách hàng thật
Kho xuất	WH-HCM-01	Dữ liệu mô phỏng
Sản phẩm	FG-NF-ALM-1L — Sữa hạt hạnh nhân 1L	Dữ liệu mô phỏng
Đơn vị bán	CTN	Dữ liệu mô phỏng; 1 CTN = 12 EA
Số lượng yêu cầu	120 CTN	Dữ liệu mô phỏng
Lô đủ điều kiện	LOT-ALM-260801-A, tồn khả dụng 80 CTN	Dữ liệu mô phỏng
Lô đủ điều kiện	LOT-ALM-260803-B, tồn khả dụng 70 CTN	Dữ liệu mô phỏng
Nguồn tham chiếu	Luật An toàn thực phẩm, Luật 55/2010/QH12	Nguồn pháp lý cho ngữ cảnh truy vết; quy tắc áp dụng cụ thể cần Verification required từ domain owner và Legal Owner
Artifact quản trị liên quan	CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY	Artifact kế hoạch, trạng thái IN_REVIEW, phiên bản v0.9.0

Facts: nhân viên kho nhận yêu cầu xuất 120 CTN. Hai lô có tổng tồn khả dụng 150 CTN, nên hàng hóa vật lý đủ số lượng: 80 + 70 = 150 CTN; phần dư sau xuất dự kiến là 30 CTN. Đây là phép tính từ dữ liệu mô phỏng, không phải xác nhận tồn kho thật.

Current Behavior: màn hình xuất kho hiện chỉ cho nhập một mã lô trên mỗi dòng đơn bán hàng. Nhân viên chọn LOT-ALM-260801-A vì lô này có hạn dùng gần hơn. Hệ thống kiểm tra tồn lô là 80 CTN, so với yêu cầu 120 CTN, rồi chặn thao tác xuất toàn bộ đơn. Nhân viên không thể phân bổ 80 CTN từ lô đầu và 40 CTN từ lô thứ hai trong cùng lần xuất.

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

flowchart TB
    A[SO-20260807-0142<br/>120 CTN] --> B[Nhân viên mở dòng xuất kho]
    B --> C[Chọn LOT-ALM-260801-A<br/>80 CTN khả dụng]
    C --> D[Hệ thống so tồn lô 80 CTN<br/>với yêu cầu 120 CTN]
    D --> E[Hệ thống chặn xuất toàn bộ đơn]
    E --> F[Không thể ghi thêm 40 CTN từ<br/>LOT-ALM-260803-B trên cùng dòng xuất<br/>trong cùng lần xuất]
    F --> G[Đơn chưa xuất dù tổng tồn 150 CTN]

Luồng trên mô tả hành vi hiện tại, không phải BPMN. Bằng chứng suy luận là: hệ thống giới hạn một mã lô cho một dòng xuất; lô đã chọn thiếu 40 CTN; trong khi lô khác còn 70 CTN. Vì giới hạn dữ liệu ngăn ghi nhận phân bổ hai lô, tổng tồn đủ không chuyển thành khả năng hoàn tất xuất hàng.

Ranh giới case: ví dụ chỉ xét khả năng ghi nhận phân bổ lô cho một dòng xuất kho. Không suy diễn giá vốn, bút toán kế toán, hóa đơn, thuế, hạn dùng thực tế, nguyên tắc FEFO (First Expired, First Out — xuất lô hết hạn trước), hay nghĩa vụ truy vết pháp lý. Các nội dung này cần owner có thẩm quyền xác minh riêng.

Senior Lens

Không kết luận “thiếu tồn kho” khi dữ liệu cho thấy tổng tồn đủ. Phân biệt ba lớp: tồn vật lý theo lô, quy tắc chọn lô, và khả năng màn hình hoặc dữ liệu ghi nhận nhiều lô. Case này mới chứng minh lỗi chặn do giới hạn ghi nhận một lô trên một dòng; chưa chứng minh nguyên nhân kỹ thuật, quy tắc nghiệp vụ mong muốn hay phương án cần chọn.

Quick Reference

Mục	Giá trị
Case	Xuất 120 CTN từ hai lô tại WH-HCM-01
Tổng tồn khả dụng	150 CTN
Thiếu tại lô được chọn	40 CTN
Hành vi hiện tại	Chỉ cho một mã lô trên một dòng xuất
Điều đã chứng minh	Giới hạn ghi nhận lô chặn xuất dù tổng tồn đủ
Điều chưa được kết luận	Nhu cầu nền, phương án, tiêu chí, quyết định, thẩm quyền, artifact, hậu quả

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Tình huống xét quy trình chặn xuất kho khi lệnh bán vượt hạn mức tín dụng khách hàng.

Bước	Nội dung	Bằng chứng hoặc cầu nối suy luận
Facts	Khách hàng mô phỏng CUS-2048 đặt đơn SO-2026-0817 lúc 2026-08-07 10:15:00. Giá trị đơn: 180.000.000 VND. Hạn mức tín dụng được nhập trong hồ sơ khách hàng: 500.000.000 VND. Công nợ mở ghi nhận trong báo cáo mô phỏng: 390.000.000 VND. Đơn chưa thu tiền, chưa xuất kho.	Tổng phơi nhiễm nếu xuất đơn = 390.000.000 + 180.000.000 = 570.000.000 VND, lớn hơn hạn mức 500.000.000 VND là 70.000.000 VND.
Current Behavior	Nhân viên kho thấy đơn ở trạng thái “Sẵn sàng xuất” vì ERP chỉ kiểm tra tồn kho. Nhân viên tự hỏi kế toán qua ứng dụng nhắn tin trước khi in phiếu xuất. Không có trường quyết định, người quyết định, thời điểm quyết định hoặc lý do chặn trong ERP.	Kiểm tra thủ công không tạo dấu vết kiểm toán nhất quán. Hai nhân viên có thể nhận hai câu trả lời khác nhau cho cùng đơn.
Underlying Need	Cần kiểm soát quyết định xuất hàng theo phơi nhiễm tín dụng, không phải chỉ hiển thị cảnh báo. “Underlying need” là nhu cầu gốc: ngăn xuất kho vượt ngưỡng khi chưa có người có thẩm quyền chấp nhận rủi ro, đồng thời giữ được bằng chứng quyết định.	Chênh 70.000.000 VND cho thấy cảnh báo đơn thuần không đủ nếu kho vẫn được xuất hàng. Nhu cầu không suy ra nghĩa vụ pháp lý hay chính sách thực tế; đây là giả định dự án mô phỏng cần Business Owner và Accounting Owner xác minh.

Giả định dự án mô phỏng cần xác minh: Credit Exposure = Open Receivables + Unpaid Confirmed Sales Orders. Đơn bị hủy, đã giao đủ, đã thanh toán đủ không tính vào Open Receivables. Không áp dụng công thức này cho vận hành thật nếu chưa được Accounting Owner xác nhận.

Option	Mô tả	Lợi ích	Giới hạn
OPT-01	Chỉ hiện cảnh báo đỏ khi vượt hạn mức; kho vẫn xuất được.	Nhanh, ít thay đổi.	Không ngăn rủi ro; không chứng minh ai chấp nhận ngoại lệ.
OPT-02	Tự chặn chuyển đơn sang xuất kho khi phơi nhiễm vượt hạn mức. Finance Manager mở chặn từng đơn bằng quyết định có lưu vết.	Kiểm soát nhất quán; kho không tự bỏ qua; có audit trail.	Cần quy tắc tính phơi nhiễm và luồng ngoại lệ rõ.
OPT-03	Tự chặn toàn bộ khách hàng có công nợ mở, không xét hạn mức.	Dễ cấu hình.	Chặn quá mức; bỏ qua chính sách hạn mức đã tồn tại trong dữ liệu mô phỏng.

Decision Criteria	Cách đo	OPT-01	OPT-02	OPT-03
Ngăn xuất vượt hạn mức	Kho không thể tạo phiếu xuất khi chưa có ngoại lệ hợp lệ	Không đạt	Đạt	Đạt
Dấu vết quyết định	Lưu người, thời điểm, lý do, đơn liên quan	Không đạt	Đạt	Không đạt
Phù hợp dữ liệu hiện có	Dùng hạn mức và công nợ mở đã có	Đạt	Đạt	Không đạt
Tránh chặn sai	Chỉ chặn khi vượt ngưỡng	Đạt	Đạt	Không đạt

Recommendation: chọn OPT-02. Lý do: chỉ OPT-02 đồng thời ngăn hành động xuất kho, dùng đúng dữ liệu hiện có, và lưu được quyết định ngoại lệ. Đây là khuyến nghị BA, chưa phải quyết định được ủy quyền.

Decision: chưa có quyết định được ủy quyền tại IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không được cấu hình ERP, gọi OPT-02 là approved, hoặc cho rằng Nova Foods đã áp dụng kiểm soát này.

Authority	Quyền cần có	Trạng thái
Business Owner	Xác nhận mức chấp nhận rủi ro và việc có cho phép xuất ngoại lệ	Chưa ghi nhận
Accounting Owner	Xác nhận công thức Credit Exposure, nguồn số dư công nợ, xử lý đơn trả hàng và bút toán liên quan	Chưa ghi nhận
Finance Manager	Chỉ được mở chặn sau khi Business Owner và Accounting Owner xác định quyền này trong artifact được kiểm soát	Chưa ghi nhận
Solution Architect	Xác nhận cách ERP khóa trạng thái và lưu audit trail	Chưa ghi nhận
Principal IT Business Analyst / Technical Curriculum Author	Ghi nhận traceability và duy trì artifact	Không có quyền phê duyệt nghiệp vụ hoặc production

Artifact đề xuất để review: /02-handbook/16-solution-options-tradeoffs-and-recommendations.md, trạng thái IN_REVIEW, phiên bản v0.9.0. Nội dung cần truy vết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; các artifact này hiện là kế hoạch kiểm soát, không phải cấu hình ERP hay phê duyệt.

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

flowchart TB
    A[Giả định dự án: Credit Exposure] --> B[Accounting Owner xác minh công thức và nguồn dữ liệu]
    B --> C{Đã xác minh trong artifact được kiểm soát?}
    C -->|Chưa| D[Không cấu hình ERP; giữ IN_REVIEW]
    C -->|Rồi| E[Business Owner quyết định chấp nhận rủi ro và quyền xuất ngoại lệ]
    E --> F{Đã có quyết định được ủy quyền trong artifact được kiểm soát?}
    F -->|Chưa| D
    F -->|Rồi| G[Solution Architect xác nhận thiết kế khóa trạng thái và audit trail]
    G --> H{Đã xác nhận thiết kế trong artifact được kiểm soát?}
    H -->|Chưa| D
    H -->|Rồi| I[SO-2026-0817 xác nhận]
    I --> J[Tính Credit Exposure]
    J --> K{570.000.000 VND <= 500.000.000 VND?}
    K -->|Có| L[Cho phép tạo phiếu xuất]
    K -->|Không| M[Khóa chuyển sang xuất kho]
    M --> N[Finance Manager xem ngoại lệ]
    N --> O{Finance Manager có quyền đã được xác lập?}
    O -->|Chưa| P[Giữ BLOCKED_PENDING_AUTHORITY]
    O -->|Rồi| Q{Phê duyệt ngoại lệ?}
    Q -->|Có| R[Finance Manager ghi phê duyệt, lý do, thời điểm và đơn trong audit trail]
    R --> S[Finance Manager mở chặn đơn]
    S --> L
    Q -->|Không| T[Finance Manager ghi từ chối, lý do, thời điểm và đơn trong audit trail]
    T --> P

Artifact field tối thiểu cho ngoại lệ	Giá trị ví dụ mô phỏng
Sales order	SO-2026-0817
Customer	CUS-2048
Exposure trước đơn	390.000.000 VND
Giá trị đơn	180.000.000 VND
Exposure sau đơn	570.000.000 VND
Hạn mức	500.000.000 VND
Mức vượt	70.000.000 VND
Trạng thái kiểm soát	BLOCKED_PENDING_AUTHORITY
Lý do	CREDIT_LIMIT_EXCEEDED
Quyết định ngoại lệ	Chưa ghi nhận
Người quyết định	Chưa ghi nhận
Thời điểm quyết định	Chưa ghi nhận

Consequence if Wrong: Nếu chọn OPT-01, kho có thể xuất đơn vượt hạn mức mà không có bằng chứng chấp nhận rủi ro. Nếu chọn OPT-03, đơn hợp lệ trong hạn mức có thể bị chặn, làm chậm giao hàng và tạo xử lý thủ công. Nếu công thức phơi nhiễm sai, ERP có thể chặn thiếu hoặc chặn thừa; vì vậy Accounting Owner phải xác minh dữ liệu và công thức trước bất kỳ quyết định cấu hình nào.

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. Scenario: ERP phải chọn lô nguyên liệu cacao khi tạo phiếu xuất cho lệnh sản xuất MO-2026-00871.

Thành phần	Giá trị đầy đủ	Phân loại nguồn
Artifact chứa ví dụ	/02-handbook/16-solution-options-tradeoffs-and-recommendations.md	Handbook, IN_REVIEW, v0.9.0
Lệnh sản xuất	MO-2026-00871	Dữ liệu mô phỏng
Sản phẩm cần sản xuất	FG-CHO-70-100G, Chocolate đen 70%, 100 g	Dữ liệu mô phỏng
Nguyên liệu cần cấp	RM-COCOA-POWDER, 500 kg	Dữ liệu mô phỏng
Kho nguồn	RM-HCM-01	Dữ liệu mô phỏng
Ngày cấp nguyên liệu	2026-08-10	Dữ liệu mô phỏng
Đơn vị quyết định nghiệp vụ	Business Owner Nova Foods mô phỏng	Vai trò mô phỏng, chưa phê duyệt
Quy tắc tham chiếu	CANONICAL_BUSINESS_RULES	Artifact canonical, IN_REVIEW, v0.9.0
Từ điển dữ liệu tham chiếu	CANONICAL_DATA_DICTIONARY	Artifact canonical, IN_REVIEW, v0.9.0

Lô	Mã nguyên liệu	Tồn khả dụng	Ngày hết hạn	Trạng thái chất lượng	Vị trí
LOT-COC-260701-A	RM-COCOA-POWDER	300 kg	2026-08-15	RELEASED	RM-HCM-01-A-01
LOT-COC-260625-B	RM-COCOA-POWDER	400 kg	2026-08-12	RELEASED	RM-HCM-01-A-02
LOT-COC-260720-C	RM-COCOA-POWDER	600 kg	2026-09-30	QUARANTINED	RM-HCM-01-Q-01

Facts. Lệnh cần 500 kg. Hai lô RELEASED có tổng 700 kg, đủ lượng. Lô LOT-COC-260625-B hết hạn trước lô LOT-COC-260701-A. Lô LOT-COC-260720-C có 600 kg nhưng QUARANTINED, nghĩa là đang chờ quyết định chất lượng; không được coi là tồn sẵn sàng cấp phát.

Current Behavior. Nhân viên kho xem danh sách lô theo vị trí lưu kho tăng dần, rồi chọn đủ lượng. Kết quả hiện tại chọn 300 kg từ LOT-COC-260701-A và 200 kg từ LOT-COC-260625-B. Bằng chứng: vị trí A-01 đứng trước A-02; cách sắp xếp không dùng ngày hết hạn. Hệ quả suy ra: còn lại 200 kg của lô hết hạn 2026-08-12, chỉ còn hai ngày tại thời điểm 2026-08-10.

Underlying Need. Hệ thống cần đề xuất cấp phát theo FEFO (First Expired, First Out — lô hết hạn sớm xuất trước), nhưng chỉ trong tập lô có cùng mã nguyên liệu, cùng kho, đủ trạng thái chất lượng và còn tồn khả dụng. Nhu cầu này không phải kết luận pháp lý hay xác nhận tuân thủ an toàn thực phẩm; đây là project assumption cần Business Owner và Quality Owner xác minh.

Rule ID	Quy tắc mô phỏng đầy đủ	Trạng thái
BR-INV-001	Chỉ lô có qualityStatus = RELEASED mới được đề xuất cấp cho lệnh sản xuất.	Project assumption; Verification required
BR-INV-002	Với cùng itemCode và warehouseCode, hệ thống sắp lô đủ điều kiện theo expiryDate tăng dần; nếu trùng ngày thì theo lotCode tăng dần.	Project assumption; Verification required
BR-INV-003	Hệ thống không đề xuất lô có availableQuantityKg <= 0 hoặc expiryDate < issueDate.	Project assumption; Verification required
BR-INV-004	Tổng lượng đề xuất phải bằng requiredQuantityKg; nếu không đủ, hệ thống trả trạng thái INSUFFICIENT_ELIGIBLE_STOCK và không tự dùng lô QUARANTINED.	Project assumption; Verification required

Option	Cách làm	Kết quả với MO-2026-00871	Nhận định
OPT-01	Giữ chọn tay theo vị trí kho	300 kg LOT-COC-260701-A; 200 kg LOT-COC-260625-B	Không bảo đảm FEFO
OPT-02	ERP tự đề xuất FEFO; nhân viên có thể ghi đè với lý do	400 kg LOT-COC-260625-B; 100 kg LOT-COC-260701-A	Cân bằng kiểm soát và ngoại lệ
OPT-03	ERP tự chọn FEFO, cấm mọi ghi đè	400 kg LOT-COC-260625-B; 100 kg LOT-COC-260701-A	Kiểm soát cao, thiếu xử lý ngoại lệ

Tiêu chí quyết định	Trọng số	OPT-01	OPT-02	OPT-03
Giảm nguy cơ tồn lô gần hết hạn	40%	1	5	5
Cho phép xử lý ngoại lệ vận hành có truy vết	25%	2	5	1
Dễ triển khai và đào tạo	20%	5	4	3
Khả năng kiểm toán quyết định cấp phát	15%	1	5	5
Điểm có trọng số, thang 5	100%	2.15	4.80	3.80

Recommendation. BA đề xuất OPT-02. Lý do: OPT-02 đạt 4.80, cao nhất; nó áp dụng FEFO cho luồng chuẩn và vẫn buộc ghi lý do khi vận hành cần khác đề xuất.

Decision. Chưa có quyết định được ủy quyền. OPT-02 là recommendation trong artifact IN_REVIEW, không phải authorized decision, không phải baseline, không phải approval.

Authority cần xác nhận	Phạm vi xác nhận	Trạng thái ngày 2026-08-07
Business Owner	Chấp nhận FEFO và quyền ghi đè	Chưa ghi nhận
Quality Owner	Điều kiện RELEASED, xử lý QUARANTINED	Chưa ghi nhận
Solution Architect	Khả năng ERP lưu thứ tự đề xuất và lý do ghi đè	Chưa ghi nhận
QA Owner	Test basis cho BR-INV-001 đến BR-INV-004	Chưa ghi nhận

Artifact. Payload đề xuất cấp phát phải lưu đủ dữ liệu kiểm toán sau:

{
  "productionOrderCode": "MO-2026-00871",
  "itemCode": "RM-COCOA-POWDER",
  "warehouseCode": "RM-HCM-01",
  "issueDate": "2026-08-10",
  "requiredQuantityKg": 500,
  "allocationMethod": "FEFO",
  "allocationStatus": "PROPOSED",
  "allocations": [
    {
      "lotCode": "LOT-COC-260625-B",
      "quantityKg": 400,
      "expiryDate": "2026-08-12",
      "qualityStatus": "RELEASED"
    },
    {
      "lotCode": "LOT-COC-260701-A",
      "quantityKg": 100,
      "expiryDate": "2026-08-15",
      "qualityStatus": "RELEASED"
    }
  ],
  "overrideReason": null
}

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

flowchart TB
    A[IN_REVIEW: project assumption<br/>Chờ Business Owner và Quality Owner xác minh] --> B[MO-2026-00871 cần 500 kg]
    B --> C[Lọc toàn bộ lô RM-COCOA-POWDER<br/>tại RM-HCM-01]
    C --> D[Chỉ giữ: RELEASED<br/>availableQuantityKg > 0<br/>expiryDate >= 2026-08-10]
    D --> E[Loại lô không đủ điều kiện<br/>LOT-COC-260720-C: QUARANTINED]
    D --> F[Tập lô đủ điều kiện]
    F --> G[Sắp expiryDate tăng dần<br/>Hòa ngày: lotCode tăng dần]
    G --> H[Tính tổng lượng đủ điều kiện]
    H --> I{Tổng lượng >= 500 kg?}
    I -->|Không| J[allocationStatus = INSUFFICIENT_ELIGIBLE_STOCK<br/>Không tự dùng QUARANTINED]
    I -->|Có| K[Đề xuất FEFO:<br/>400 kg LOT-COC-260625-B<br/>100 kg LOT-COC-260701-A]
    K --> L[Giảm tồn lô gần hết hạn]
    K --> M{Nhân viên ghi đè?}
    M -->|Không| N[Payload allocationStatus = PROPOSED<br/>allocationMethod = FEFO<br/>overrideReason = null]
    M -->|Có| O[Ghi đè thứ tự hoặc lượng<br/>chỉ trong tập đủ điều kiện<br/>tổng vẫn đúng 500 kg]
    O --> P[Lưu allocations và overrideReason]
    E --> Q[Không tự dùng QUARANTINED<br/>Bảo toàn ranh giới kiểm soát chất lượng]

Consequence if Wrong. Nếu chọn theo vị trí thay vì FEFO, 200 kg của LOT-COC-260625-B còn lại gần ngày hết hạn. Nếu cho phép tự dùng lô QUARANTINED, ERP phá ranh giới kiểm soát chất lượng mô phỏng. Nếu gọi recommendation là authorized decision, tài liệu tạo bằng chứng phê duyệt không tồn tại.

9. Related Concepts & Dependencies

Core

Dependency là quan hệ phụ thuộc: artifact này cần thông tin ổn định từ artifact khác để giữ đúng nghĩa. Upstream là nguồn đầu vào; downstream là nơi dùng kết quả. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Nguồn chân lý canonical chỉ tồn tại một nơi. Handbook này giải thích cách dùng, không sao chép lại catalog, registry hay manifest. Lý do: cùng một quy tắc hoặc ID xuất hiện ở nhiều nơi sẽ tạo hai bản có thể lệch nhau khi sửa.

Loại nội dung	Nguồn canonical	Handbook này dùng thế nào	Không được làm
Cấu trúc 26 chapter, tên tệp chapter	/01-curriculum/CHAPTER_MANIFEST.md	Tham chiếu chapter liên quan	Tự đổi tên chapter hoặc tạo filename biến thể
Template được quy hoạch	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ dẫn learner chọn đúng template	Chép lại định nghĩa template thành bản thay thế
Persistent ID, quy ước cấp ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Giữ nguyên ID khi liên kết	Tự cấp lại, dịch, rút gọn hoặc tái sử dụng ID
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nêu ID quy tắc và tác động lên lựa chọn	Viết lại rule như nguồn chính
Thuật ngữ, thực thể, thuộc tính dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Dùng đúng tên logical data	Tạo định nghĩa dữ liệu cạnh tranh
Nguồn chuẩn, luật, giới hạn sử dụng nguồn	/00-research/00_SOURCE_MAP.md	Dẫn nguồn và giữ nhãn Verification required	Diễn giải thành nghĩa vụ pháp lý Nova Foods

Persistent ID là định danh bền vững, ví dụ BR-INV-001. ID giữ nguyên dù tiêu đề mô tả được làm rõ. Tiêu đề giúp người đọc hiểu; ID giúp BA, QA và kỹ thuật biết đang nói về đúng cùng một đối tượng. Vì vậy, liên kết tốt có dạng “áp dụng BR-INV-001 từ /01-curriculum/CANONICAL_BUSINESS_RULES.md”, không phải chép nội dung rule vào mọi chapter.

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

flowchart TB
    C["Nguồn canonical chỉ tồn tại một nơi"] -->|Giải thích cách dùng; không lưu bản canonical| H["Handbook chapter"]

    SM["/00-research/00_SOURCE_MAP.md"] -->|Dẫn nguồn; giữ nhãn<br/>Verification required| H
    CM["/01-curriculum/CHAPTER_MANIFEST.md"] -->|Tham chiếu chapter liên quan| H
    TM["/01-curriculum/TEMPLATE_MANIFEST.md"] -->|Chỉ dẫn learner chọn đúng template| H
    IDR["/01-curriculum/TRACEABILITY_ID_REGISTRY.md"] -->|Giữ nguyên persistent ID| H
    BR["/01-curriculum/CANONICAL_BUSINESS_RULES.md"] -->|Nêu ID rule và tác động| H
    DD["/01-curriculum/CANONICAL_DATA_DICTIONARY.md"] -->|Dùng đúng tên logical data| H

    H -->|Liên kết, không sao chép| O["Template/artifact delivery dùng liên kết đến<br/>nguồn canonical; giữ nguyên ID khi có ID"]

    SM -.-> X["Không diễn giải thành nghĩa vụ<br/>pháp lý Nova Foods"]

    H -.->|Không được làm| R["Tạo bản thay thế hoặc cạnh tranh:<br/>đổi tên chapter/filename; chép định nghĩa template;<br/>cấp lại, dịch, rút gọn hoặc tái sử dụng ID;<br/>viết lại rule; tạo định nghĩa dữ liệu cạnh tranh"]
    R -.-> Q["Nhiều bản cùng quy tắc hoặc ID<br/>có thể lệch nhau khi sửa"]

Applied

Facts. Case mô phỏng Nova Foods có đề xuất cấp phát MO-2026-00871 cho RM-COCOA-POWDER; ví dụ trước dùng BR-INV-001 đến BR-INV-004 và các giá trị RELEASED, QUARANTINED, PROPOSED.

Current Behavior. BA viết lại điều kiện FEFO trong solution-options document, đồng thời ghi tên field khác với payload đã dùng: expiry thay cho expiryDate.

Underlying Need. Người đọc cần đánh giá option cấp phát tồn kho mà vẫn truy được rule, data term và template gốc.

Options. Option 1: chép toàn bộ rule và field vào chapter. Option 2: chỉ ghi persistent ID, đường dẫn canonical và ngữ cảnh áp dụng. Option 2 tốt hơn vì một thay đổi tại catalog không cần sửa nhiều bản sao.

Decision Criteria. Chọn cách giữ một nguồn chân lý, không đổi ID, cho phép QA đối chiếu cùng thuật ngữ, và không biến ví dụ học liệu thành cấu hình ERP.

Decision. Document này ghi BR-INV-001 đến BR-INV-004 nguyên dạng, dùng expiryDate nguyên dạng trong payload minh họa, và tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Nội dung đầy đủ của rule, field definition và quy tắc cấp ID nằm ở các artifact đó.

Authority. Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Business Owner, Quality Owner, Solution Architect và QA Owner chưa được ghi nhận approval tại IN_REVIEW, v0.9.0, ngày 2026-08-07.

Artifact. Liên kết trong decision record phải có dạng kiểm tra được:

Thành phần được dùng	Tham chiếu canonical	Mục đích tại đây
Rule FEFO và quality gate	BR-INV-001 đến BR-INV-004; /01-curriculum/CANONICAL_BUSINESS_RULES.md	Đánh giá tác động option cấp phát
Đơn hàng sản xuất	MO-2026-00871; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Ví dụ dữ liệu tổng hợp
Trạng thái lô	RELEASED, QUARANTINED; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Không đổi nghĩa trạng thái
Payload field	expiryDate, allocationStatus; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Giữ hợp đồng dữ liệu logic
Quy ước ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Chống tạo ID trùng hoặc biến thể

Consequence if Wrong. Nếu chapter dùng expiry còn data dictionary dùng expiryDate, đội API có thể map sai field hoặc QA kiểm thử sai payload. Nếu BR-INV-001 bị diễn đạt lại khác catalog, option được chọn có thể dựa trên rule không còn cùng nghĩa. Nếu tạo BR-FEFO-01 cho cùng rule, traceability bị tách đôi; người review không biết ID nào là canonical.

Senior Lens

Không phải mọi quan hệ đều là dependency. Một link chỉ là tham khảo nếu bỏ nó không đổi quyết định. Một dependency tồn tại khi thay đổi nguồn có thể đổi nghĩa, phạm vi, dữ liệu, lựa chọn hoặc kiểm tra của artifact đang đọc.

BA senior kiểm tra theo ba câu: “Nội dung này có nguồn canonical nào?”, “Tôi có đang sao chép thay vì tham chiếu không?”, “Nếu nguồn đổi, người dùng downstream có biết phần nào phải xem lại không?”. Có ít nhất một câu trả lời không rõ thì không tạo rule mới; ghi nhận dependency và giữ boundary IN_REVIEW.

Quick Reference

Quy tắc	Hành động
Cần dùng rule	Ghi persistent ID và đường dẫn catalog
Cần dùng data field	Giữ nguyên logical name từ data dictionary
Cần dùng template	Tham chiếu filename trong template manifest
Cần nói về chapter khác	Dùng tên và filename từ chapter manifest
Nguồn pháp lý chưa được xác minh cho tình huống cụ thể	Gắn Verification required
Không có approval hoặc baseline reference	Không dùng “đã phê duyệt” hoặc “đã baseline”

Core

Bảng truy vết phụ thuộc nối NEED (nhu cầu), REQ (yêu cầu), BR (business rule, quy tắc nghiệp vụ), AC (acceptance criteria, tiêu chí chấp nhận), DATA/API (dữ liệu hoặc giao diện lập trình) và TC (test case, ca kiểm thử). Mỗi liên kết chỉ tham chiếu ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; bảng handbook không tạo ID mới, không thay nguồn canonical.

Loại liên kết	Nguồn canonical	Đích sử dụng	ID/link hiện có từ source seed	Quy tắc truy vết
NEED	Nhu cầu đã được registry đăng ký	REQ và quyết định phương án	Chưa có ID NEED cụ thể trong source seed	Không viết NEED mới trong bảng này. Ghi link sau khi registry cấp ID.
REQ	Requirement đã được registry đăng ký	BR, AC, DATA/API, TC	Chưa có ID REQ cụ thể trong source seed	Một REQ phải chỉ được diễn giải bởi artifact canonical của nó.
BR	/01-curriculum/CANONICAL_BUSINESS_RULES.md	REQ, AC, TC	CANONICAL_BUSINESS_RULES; chưa có BR ID cụ thể trong source seed	Không chép nguyên văn hoặc sửa nghĩa BR tại handbook.
AC	Requirement artifact hoặc registry	TC và bằng chứng nghiệm thu	Chưa có AC ID cụ thể trong source seed	AC phải kiểm chứng được; không dùng nhận xét chủ quan như “hệ thống chạy tốt”.
DATA/API	/01-curriculum/CANONICAL_DATA_DICTIONARY.md và đặc tả API canonical khi được đăng ký	REQ, AC, TC	CANONICAL_DATA_DICTIONARY; chưa có DATA/API ID cụ thể trong source seed	Tên trường, kiểu dữ liệu, quyền truy cập không được suy diễn từ ví dụ.
TC	Test artifact/registry khi được đăng ký	AC, REQ, BR, DATA/API	Chưa có TC ID cụ thể trong source seed	TC chứng minh điều kiện; TC không thay thế requirement hoặc business rule.

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

flowchart TB
    NOTE["Quy ước: mũi tên chỉ liên kết truy vết từ artifact nguồn đến artifact/điểm sử dụng"]
    NEED[NEED: nhu cầu] --> REQ[REQ: yêu cầu]
    NEED --> OPTION[Quyết định phương án]
    REQ --> BR[BR: quy tắc nghiệp vụ]
    REQ --> AC[AC: tiêu chí chấp nhận]
    REQ --> DATA[DATA/API: dữ liệu hoặc giao diện]
    REQ --> TC[TC: ca kiểm thử]
    BR --> AC
    BR --> TC
    DATA --> AC
    DATA --> TC
    AC --> TC

Applied

Facts: Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Source seed xác nhận TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; source seed không cung cấp ID NEED, REQ, BR, AC, DATA/API hoặc TC cụ thể.

Current Behavior: Một BA có thể thấy nhu cầu “theo dõi lô hàng” trong ví dụ ERP rồi tự đặt mã như REQ-001. Hành vi này tạo mã ngoài registry, nên không chứng minh được mã có duy nhất, đúng phạm vi hay có chủ sở hữu.

Underlying Need: Cần liên kết từ nhu cầu đến kiểm thử mà không biến handbook thành nguồn sự thật thứ hai. Bằng chứng: registry được chỉ định là canonical identifier registry; catalog rule và data dictionary được chỉ định là vị trí canonical riêng.

Options: (1) Tự tạo ID trong handbook; (2) chỉ ghi loại liên kết, artifact canonical và trạng thái chưa đăng ký; (3) sao chép toàn bộ rule, field và test vào handbook. Phương án (1) phá kiểm soát ID. Phương án (3) tạo nhiều bản có thể lệch nhau.

Decision Criteria: Giữ ID duy nhất; giữ nghĩa rule và data tại nguồn canonical; cho phép QA truy ngược; không diễn giải IN_REVIEW thành baseline hoặc approval.

Decision: Chọn phương án (2). Bảng truy vết tại section này chỉ chứa đường dẫn canonical, loại liên kết và trạng thái đăng ký. Khi ID được đăng ký hợp lệ, thêm đúng ID đó vào cột liên kết, không đổi tên và không tạo biến thể dịch thuật.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Business Owner xác nhận nhu cầu nghiệp vụ; Architect xác nhận DATA/API; QA xác nhận TC; Legal, Accounting, Security hoặc Compliance xác nhận nội dung thuộc thẩm quyền họ. Không có approval được ghi nhận.

Artifact: /01-curriculum/TRACEABILITY_ID_REGISTRY.md giữ ID; /01-curriculum/CANONICAL_BUSINESS_RULES.md giữ BR; /01-curriculum/CANONICAL_DATA_DICTIONARY.md giữ định nghĩa dữ liệu logic.

Consequence if Wrong: Nếu REQ đổi nghĩa âm thầm nhưng AC và TC vẫn theo nghĩa cũ, kiểm thử có thể pass trong khi giải pháp không đáp ứng nhu cầu. Nếu field DATA/API đổi tên hoặc kiểu dữ liệu âm thầm, tích hợp có thể gửi dữ liệu sai, test fixture sai, hoặc báo cáo truy xuất lô không khớp. Đây là rủi ro học liệu mô phỏng, không phải kết luận về hệ thống Nova Foods thực tế.

Senior Lens

Quy tắc tối thiểu: mỗi hàng truy vết phải trả lời được bốn câu: liên kết từ đâu, đến đâu, ID canonical nào, và artifact nào sở hữu nghĩa của ID. Không có ID trong registry thì trạng thái đúng là “chưa đăng ký”, không phải mã tạm. Mã tạm dễ bị sao chép vào REQ, AC và TC rồi trở thành phụ thuộc giả.

IN_REVIEW chỉ cho biết artifact đang được xem xét. Nó không xác nhận requirement đúng, rule hợp lệ, API sẵn sàng, test pass, baseline tồn tại hoặc người dùng đã phê duyệt. Khi cần kết luận pháp lý, kế toán, an toàn thực phẩm, quyền riêng tư hoặc bảo mật, giữ nhãn Verification required và chuyển đúng owner có thẩm quyền.

Quick Reference

Kiểm tra trước khi ghi link	Kết quả hợp lệ
ID có trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md?	Dùng nguyên dạng ID.
Nghĩa BR có thuộc /01-curriculum/CANONICAL_BUSINESS_RULES.md?	Chỉ tham chiếu artifact và ID BR đã đăng ký.
Field hoặc API có thuộc /01-curriculum/CANONICAL_DATA_DICTIONARY.md hoặc đặc tả API canonical?	Không suy diễn tên field, schema hoặc contract.
AC có thể quan sát và TC có thể kiểm tra?	Liên kết AC–TC được phép ghi khi cả hai ID đã đăng ký.
ID chưa có trong source canonical?	Ghi “chưa đăng ký”; không tự tạo mã.

Core

Lan truyền thay đổi là chuỗi tác động khi artifact nguồn đổi và các artifact dùng nó phải được đánh giá lại. Một dependency đổi im lặng khi người sửa không ghi lịch sử, không thông báo consumer, không kiểm tra liên kết, hoặc thay nội dung dưới cùng ID. Hậu quả: traceability còn chỉ tới ID cũ nhưng ý nghĩa đã khác; test, API, dữ liệu và quyết định không còn cùng một sự thật.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi ID và dữ liệu dưới đây là tổng hợp. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, không artifact nào được hiểu là baseline, approval, cấu hình ERP thật, hay quyết định production.

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

flowchart TB
    A["Dependency nguồn đổi<br/>BR · DATA dictionary · TRACEABILITY_ID_REGISTRY<br/>OpenAPI contract · AC · nguồn pháp lý/chuẩn"]
    A --> B[Change record]
    B --> C[Impact analysis]
    C --> D["Rà REQ, BR, AC, DATA/API, TC<br/>TRACEABILITY_ID_REGISTRY và OpenAPI contract<br/>Dữ liệu nhạy cảm: Architect, Security<br/>Nguồn pháp lý/chuẩn: Legal, Accounting, Compliance hoặc domain owner"]
    D --> E{Có tác động?}
    E -->|Có| F[Consumer cập nhật]
    E -->|Không| G[Ghi no-impact evidence]
    F --> H[Traceability check]
    G --> H
    H --> I[Controlled version update]

    A -. đổi im lặng .-> J[Semantic drift]
    J --> K["Test sai hoặc thiếu<br/>coverage giả; release gate sai"]
    J --> L["API/data mismatch<br/>lộ dữ liệu nhạy cảm"]
    J --> M["Link chết hoặc một ID có hai nghĩa"]
    J --> N[Decision dựa nguồn cũ]

Dependency thay đổi im lặng	Cái gì gãy	Dấu hiệu kiểm tra	Hành động bắt buộc
CANONICAL_BUSINESS_RULES đổi ý nghĩa BR	REQ diễn giải sai; AC kiểm tra sai hành vi	BR ID còn tồn tại nhưng điều kiện, ngoại lệ, hiệu lực đổi	So sánh phiên bản; rà mọi REQ, AC, TC tham chiếu BR
CANONICAL_DATA_DICTIONARY đổi tên, kiểu, độ dài, phân loại dữ liệu	Mapping API lỗi; validation sai; dữ liệu nhạy cảm lộ qua màn hình hoặc log	DATA ID giữ nguyên nhưng thuộc tính logic đổi	Architect và Security review; rà DATA/API, field mapping, TC
TRACEABILITY_ID_REGISTRY thay ID hoặc trạng thái ID	Link chết; một ID bị gán hai nghĩa; coverage giả	Artifact dùng ID không còn registry xác nhận	Dừng dùng ID đó; khôi phục mapping hoặc đăng ký thay thế theo registry
OpenAPI contract đổi request, response, status code	Consumer gọi sai endpoint; integration test fail hoặc bỏ sót lỗi	API schema và DATA/API link không cùng version	Rà client, contract test, error handling, TC
AC đổi điều kiện đạt	TC pass nhưng không chứng minh nhu cầu; release gate sai	TC không còn kiểm tra từng AC	Cập nhật test basis; map lại AC–TC; QA xác nhận phạm vi kiểm tra
Source pháp lý hoặc chuẩn đổi trạng thái	Rule bị diễn đạt thành nghĩa vụ khi chưa xác minh	Nguồn cũ, superseded assumption, hoặc thiếu owner review	Gắn Verification required; Legal, Accounting, Compliance hoặc domain owner xác minh

Applied

Facts: BR-NF-INV-014 trong CANONICAL_BUSINESS_RULES được dùng bởi REQ-NF-INV-032, AC-NF-INV-032-02 và TC-NF-INV-032-05. DATA-NF-LOT-003 trong CANONICAL_DATA_DICTIONARY mô tả mã lô hàng. API-NF-INV-007 trả dữ liệu lô cho màn hình xuất kho mô phỏng.

Current Behavior: Tài liệu API đổi trường lotCode từ chuỗi 20 ký tự thành chuỗi 30 ký tự. Không có change record. TC-NF-INV-032-05 vẫn chỉ kiểm tra 20 ký tự; màn hình cắt phần cuối mã lô. Traceability vẫn “xanh” vì các ID chưa đổi.

Underlying Need: Bảo đảm mã lô hiển thị, truyền qua API và kiểm thử cùng một định nghĩa dữ liệu; không suy diễn rằng thay đổi độ dài là vô hại. Bằng chứng: DATA-NF-LOT-003 là nguồn logic cho thuộc tính; API và TC là consumer của thuộc tính đó.

Mục	Nội dung
Options	1. Giữ UI và TC 20 ký tự. 2. Đổi UI, API mapping và TC theo DATA-NF-LOT-003. 3. Đổi data dictionary để giữ 20 ký tự.
Decision Criteria	Canonical source nào sở hữu định nghĩa; dữ liệu có bị mất; API consumer có bị phá vỡ; có evidence kiểm thử; thẩm quyền quyết định dữ liệu và kiến trúc.
Decision	Không tự chọn phương án. Tạo impact record, khóa phát hành consumer bị ảnh hưởng, xác minh DATA-NF-LOT-003 là định nghĩa hiện hành, rồi owner có thẩm quyền quyết định.
Authority	Data Owner xác nhận nghĩa dữ liệu; Architect xác nhận API compatibility; QA xác nhận TC; Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và lịch sử.
Artifact	Change record tham chiếu DATA-NF-LOT-003, API-NF-INV-007, REQ-NF-INV-032, AC-NF-INV-032-02, TC-NF-INV-032-05; không sửa im lặng các ID này.
Consequence if Wrong	Mã lô bị cắt, truy vết lô mô phỏng sai, test pass giả, consumer API xử lý sai. Với hệ thống thật, đây cần domain-owner và legal review; không kết luận nghĩa vụ pháp lý từ case này.

Senior Lens

Quy tắc: ID ổn định không chứng minh ý nghĩa ổn định. ID chỉ là khóa tham chiếu. Consumer phải kiểm tra version, trạng thái, trường thay đổi và semantic delta, tức chênh lệch ý nghĩa giữa hai phiên bản.

Không sao chép rule, định nghĩa dữ liệu, schema API, hay tiêu chí test sang artifact consumer để “an toàn”. Bản sao tạo hai nguồn sự thật. Consumer chỉ giữ ID canonical, phiên bản đã xem xét, phạm vi ảnh hưởng, quyết định, owner và evidence kiểm tra. Nội dung chuẩn vẫn nằm tại artifact sở hữu nó.

Khi dependency thay đổi im lặng, không “vá” TC trước. Thứ tự đúng: xác định source owner, xác nhận thay đổi có thật, phân tích impact, cập nhật REQ/BR/AC/DATA/API/TC bị ảnh hưởng, rồi kiểm tra traceability. Vá test trước che drift nhưng không sửa nguyên nhân.

Quick Reference

Kiểm tra trước khi dùng dependency	Kết quả hợp lệ
ID có trong TRACEABILITY_ID_REGISTRY?	Có một định nghĩa, trạng thái và owner rõ
Artifact nguồn có đúng đường dẫn canonical?	Dùng đúng filename, không dùng bản sao hoặc tên rút gọn
Version và ngày xem xét được ghi?	Consumer biết mình đã xem bản nào
Thay đổi có change record và impact analysis?	Có danh sách consumer hoặc evidence không ảnh hưởng
REQ, BR, AC, DATA/API, TC còn khớp nghĩa?	Mỗi link chứng minh được cùng hành vi hoặc dữ liệu
Có thay đổi pháp lý, kế toán, privacy, food safety?	Gắn Verification required; chuyển đúng owner thẩm quyền

10. Common Mistakes & Anti-patterns

Core

Sai lầm phổ biến không nằm ở việc có nhiều phương án, mà ở việc nhóm không biến phương án thành quyết định có thể kiểm tra. Một anti-pattern là cách làm lặp lại, nhìn có vẻ nhanh nhưng tạo lỗi giao hàng: quyết định thiếu căn cứ, scope trôi, cấu hình ERP sai hoặc test không chứng minh được hành vi cần có.

Sai lầm	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Chọn phương án ngay sau workshop	Biên bản chỉ ghi “dùng cấu hình chuẩn” nhưng không có tiêu chí so sánh	Nhầm ý kiến đầu tiên với quyết định	Ghi tối thiểu vấn đề, phương án, tiêu chí, trade-off và người có thẩm quyền quyết định
So sánh phương án bằng cảm tính	Cột đánh giá ghi “dễ dùng”, “tốt hơn”, “linh hoạt” không có điều kiện đo	Không tách nhu cầu khỏi giải pháp	Đổi mô tả thành tiêu chí kiểm tra được: thời gian xử lý, số bước, dữ liệu bắt buộc, rủi ro kiểm soát
Đưa custom code thành lựa chọn mặc định	Đề xuất phát triển trước khi kiểm tra cấu hình ERP và quy trình hiện hữu	Nhóm thiên về công cụ quen thuộc	Kiểm tra theo thứ tự: thay đổi quy trình, cấu hình chuẩn, báo cáo chuẩn, tích hợp hiện hữu, rồi mới phát triển
Không ghi consequence nếu chọn sai	Quyết định không nêu dữ liệu, người dùng hay quy trình bị ảnh hưởng	Chỉ tập trung lợi ích ngắn hạn	Nêu hậu quả cụ thể: sai tồn kho, chậm xuất hàng, lệch báo cáo, tăng thao tác tay hoặc khó test
Gộp nhiều quyết định thành một dòng	Một dòng vừa chọn luồng phê duyệt, quyền sửa giá và cách tích hợp	Phạm vi quyết định quá rộng	Tách từng decision point; mỗi điểm có một nhu cầu và một kết quả rõ

[!WARNING] Với Nova Foods mô phỏng, chọn custom code để bỏ qua kiểm soát lô hàng có thể làm luồng xuất kho không còn chứng minh được lô nào đã được chọn. Phục hồi an toàn: dừng cấu hình chưa phát hành, ghi impact analysis, quay về phương án có truy vết lô trong phạm vi mô phỏng. Không suy diễn đây là kết luận tuân thủ pháp lý hay an toàn thực phẩm thực tế.

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

flowchart TB
    A[Nhu cầu đã làm rõ] --> B[Nhóm: tách thành từng điểm quyết định]
    B --> C[Nhóm: chọn điểm quyết định chưa đóng]
    C --> D[Nhóm: đặt tiêu chí kiểm tra được]

    D --> E[Nhóm: lập hoặc cập nhật phương án<br/>theo thứ tự ưu tiên:<br/>thay đổi quy trình, cấu hình chuẩn,<br/>báo cáo chuẩn, tích hợp hiện hữu, phát triển]
    E --> F[Nhóm: xác nhận phương án cần so sánh]
    F --> G[Nhóm: chọn phương án chưa đánh giá<br/>hoặc cần đánh giá lại]
    G --> H[Nhóm: thu thập bằng chứng theo tiêu chí]
    H --> I{Bằng chứng đủ?}

    I -- Có --> J[Nhóm: đánh giá tiêu chí, trade-off,<br/>consequence và impact nếu chọn sai]
    J --> K[Nhóm: ghi kết quả riêng cho phương án]
    K --> L{Còn phương án cần đánh giá?}
    L -- Có --> G
    L -- Không --> M[Nhóm: lập khuyến nghị dựa trên<br/>tiêu chí, trade-off, consequence, impact<br/>và mức đủ bằng chứng]

    I -- Không: tiêu chí chưa kiểm tra được --> N[Nhóm: điều chỉnh tiêu chí]
    N --> O[Nhóm: đánh dấu kết quả theo tiêu chí cũ<br/>là cần đánh giá lại]
    O --> G

    I -- Không: thiếu dữ liệu --> P{Có thể thu thập thêm bằng chứng?}
    P -- Có --> Q[Nhóm: thu thập thêm bằng chứng]
    Q --> H
    P -- Không --> R[Nhóm: ghi thiếu bằng chứng,<br/>impact và rủi ro]
    R --> M

    M --> S{Người có thẩm quyền quyết định}
    S -- Chọn phương án --> W[Người có thẩm quyền:<br/>chọn phương án]
    S -- Không chọn phương án --> U[Người có thẩm quyền:<br/>từ chối chọn phương án]
    S -- Yêu cầu đánh giá lại --> G
    S -- Yêu cầu phương án mới --> V[Nhóm: bổ sung phương án]
    V --> E
    S -- Hoãn --> T[Trạng thái: hoãn hoặc chờ bằng chứng]

    W --> X[Nhóm: cập nhật hồ sơ quyết định<br/>và kết quả chọn]
    U --> U1[Nhóm: cập nhật hồ sơ quyết định<br/>và kết quả không chọn]
    X --> Y[Nhóm: cập nhật liên kết truy vết<br/>nhu cầu – điểm quyết định – phương án – kết quả]
    U1 --> Y

    T --> T1[Nhóm: ghi lý do hoãn,<br/>người quyết định và bằng chứng còn thiếu]
    T1 --> T2[Nhóm: cập nhật liên kết truy vết<br/>và giữ điểm quyết định ở trạng thái mở]
    T2 --> T3{Còn điểm khác có thể xử lý?}
    T3 -- Có --> C
    T3 -- Không --> AB[Chưa hoàn tất:<br/>còn điểm hoãn hoặc chờ bằng chứng]

    Y --> Z{Còn điểm quyết định chưa đóng?}
    Z -- Có --> C
    Z -- Không --> AA[Hoàn tất]

Applied

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

Thành phần	Nội dung
Facts	Kho mô phỏng cần chọn lô cho đơn xuất hàng. Nhóm delivery đề xuất thêm màn hình nhập lô tự do.
Current Behavior	Người dùng chọn lô còn tồn trong danh sách ERP mô phỏng; hệ thống giữ liên kết giữa dòng xuất và lô.
Underlying Need	Nhân viên kho cần xử lý đơn nhanh khi có nhiều lô cùng một mặt hàng.
Options	1. Giữ danh sách chọn lô. 2. Cấu hình ưu tiên lô theo quy tắc nghiệp vụ đã được xác nhận. 3. Phát triển ô nhập lô tự do.
Decision Criteria	Tốc độ thao tác; khả năng ngăn chọn lô không tồn tại; khả năng truy vết; chi phí thay đổi; khả năng test.
Decision	Chưa chọn phương án 3. Phương án 2 chỉ được xem xét sau khi nhu cầu ưu tiên lô được làm rõ và có evidence.
Authority	Business Owner xác nhận nhu cầu vận hành; Architect đánh giá thay đổi kỹ thuật; QA xác nhận test basis. Không có approval được ghi nhận tại IN_REVIEW v0.9.0.
Artifact	Ghi trong /02-handbook/16-solution-options-tradeoffs-and-recommendations.md; liên kết ID đã đăng ký trong TRACEABILITY_ID_REGISTRY khi artifact quyết định được tạo.
Consequence if Wrong	Ô nhập tự do có thể nhận lô không tồn tại hoặc sai trạng thái, làm dữ liệu xuất kho mô phỏng không đáng tin và tạo test case giả.

Senior Lens

Đừng sửa triệu chứng bằng câu “cần thêm linh hoạt”. “Linh hoạt” thường che một trong bốn vấn đề: rule chưa rõ, dữ liệu nguồn thiếu, quyền quyết định chưa đúng, hoặc quy trình hiện tại có bước thừa. Senior BA hỏi: “Ai gặp lỗi, tại bước nào, với dữ liệu nào, bao nhiêu lần, và phương án nào loại lỗi mà không tạo kiểm soát mới?”

Recovery boundary phải rõ. BA có thể ghi nhận sai lệch, đề xuất rollback, lập impact analysis và điều phối review. BA không tự sửa rule nghiệp vụ, tự xác nhận cấu hình ERP, tự kết luận pháp lý hoặc tự gọi quyết định là đã phê duyệt.

Quick Reference

Khi thấy	Làm ngay
“Đây là best practice” không có bối cảnh	Hỏi nhu cầu, evidence và tiêu chí áp dụng
“Cần custom để nhanh hơn”	Đo thời gian hiện tại; kiểm tra cấu hình và quy trình trước
Một option không có nhược điểm	Yêu cầu nêu ít nhất một trade-off thực tế
Quyết định không có consumer bị ảnh hưởng	Lập danh sách process, data, API, report và test bị tác động
Nhóm muốn tiếp tục khi tiêu chí chưa rõ	Dừng quyết định; làm rõ nhu cầu trước

Core

[!WARNING] Rủi ro thật: dùng phương án chưa có thẩm quyền làm cấu hình ERP có thể tạo sai sổ sách, sai tồn kho, lộ dữ liệu cá nhân hoặc chặn truy xuất lô hàng. Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp; IN_REVIEW tại v0.9.0 không phải baseline, không phải phê duyệt, không cho phép production.

Dấu hiệu lỗi trong tài liệu phương án	Ví dụ lỗi Nova Foods mô phỏng	Hậu quả có thể quan sát	Ranh giới phục hồi an toàn
Ghi “đã chọn” nhưng không có quyết định được ghi nhận	BA viết “ERP sẽ tự động khóa sửa giá sau xuất hóa đơn”	Dev cấu hình khóa; bộ phận bán hàng không sửa được đơn sai	Dừng cấu hình chưa phát hành; đánh dấu phương án là đề xuất; chuyển Business Owner và Accounting Owner xác nhận
Dùng nguồn pháp lý như lệnh cấu hình mà thiếu Legal Owner	Tài liệu nói ERP “đã tuân thủ” Luật 91/2025/QH15	Nhóm delivery hiểu sai nghĩa vụ bảo vệ dữ liệu	Không tuyên bố tuân thủ; chỉ ghi Verification required; Legal Owner xác minh diễn giải trước khi tạo requirement
Đổi đường dẫn hoặc ID canonical khi sao chép	Ghi /01-curriculum/CANONICAL_DATA_DICTIONARY.md thành tên tệp rút gọn	Liên kết review trỏ sai nguồn kiểm soát	Khôi phục đúng chuỗi canonical; rà toàn bộ liên kết trước khi tiếp tục review
Vẽ sơ đồ hoạt động rồi gọi là BPMN	Dùng Mermaid flowchart cho luồng phê duyệt giá nhưng gắn nhãn “BPMN”	Reader suy ra sai ký hiệu chuẩn OMG BPMN 2.0.2	Đổi nhãn thành “Mermaid flowchart”; chỉ dùng BPMN khi mô hình dùng đúng ký pháp BPMN và được kiểm tra

Applied

Facts: Nova Foods mô phỏng có đề xuất tự động chặn xuất kho khi số lượng lô khả dụng nhỏ hơn số lượng giao. Dữ liệu số lượng, lô và đơn giao đều tổng hợp.

Current Behavior: Nhóm delivery ghi phương án “bắt buộc chặn” trong tài liệu thiết kế. Không có tham chiếu quyết định từ Business Owner, Warehouse Owner hoặc Architect.

Underlying Need: Cần giảm nguy cơ giao vượt lượng hàng được hệ thống ghi nhận. Đây là nhu cầu kiểm soát vận hành, chưa phải quy tắc đã xác nhận.

Options: Cảnh báo nhưng cho phép tiếp tục; chặn cứng; cho phép override có ghi nhận người thực hiện và lý do.

Decision Criteria: Tính liên tục giao hàng, khả năng kiểm soát sai lệch tồn, quyền override, tác động tích hợp ERP và thẩm quyền quyết định.

Decision: Chưa chọn phương án. Bằng chứng: artifact corpus đang IN_REVIEW, không có baseline reference hoặc approval reference.

Authority: Business Owner quyết định chấp nhận rủi ro vận hành; Warehouse Owner xác nhận quy trình kho; Architect đánh giá khả thi kỹ thuật. BA ghi lựa chọn và bằng chứng, không thay các vai trò này quyết định.

Artifact: Ghi trạng thái đề xuất trong /02-handbook/16-solution-options-tradeoffs-and-recommendations.md; giữ liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY khi các artifact đó có nội dung được kiểm soát.

Consequence if Wrong: Chặn cứng sai có thể ngừng giao hàng hợp lệ; cảnh báo yếu có thể tạo giao vượt số liệu. Không sửa dữ liệu kho, không phát hành cấu hình, không gọi phương án là phê duyệt khi chưa có quyết định được ghi nhận.

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

flowchart TB
    A["Nhu cầu: giảm nguy cơ giao vượt lượng hàng hệ thống ghi nhận"] --> B["So sánh phương án"]

    B --> O1["Cảnh báo, vẫn cho tiếp tục"]
    B --> O2["Chặn cứng"]
    B --> O3["Override có ghi người thực hiện và lý do"]

    C["Tiêu chí đánh giá:<br/>• Liên tục giao hàng<br/>• Kiểm soát sai lệch tồn<br/>• Quyền override<br/>• Tác động tích hợp ERP<br/>• Thẩm quyền quyết định"] -. áp dụng cho .-> B

    O1 -. rủi ro .-> R1["Cảnh báo yếu có thể cho giao vượt số liệu"]
    O2 -. rủi ro .-> R2["Chặn cứng sai có thể ngừng giao hàng hợp lệ"]

    O1 --> D["Chờ quyết định"]
    O2 --> D
    O3 --> D

    BO["Business Owner<br/>quyết định chấp nhận rủi ro vận hành"] --> D
    WO["Warehouse Owner<br/>xác nhận quy trình kho"] --> D
    AR["Architect<br/>đánh giá khả thi kỹ thuật"] --> D

    D --> E{"Có quyết định được ghi nhận?"}

    E -- "Chưa" --> IR["Chưa chọn phương án<br/>IN_REVIEW"]
    IR --> N["Không sửa dữ liệu kho<br/>Không phát hành cấu hình<br/>Không gọi phương án là đã phê duyệt"]
    IR --> F["Làm rõ nhu cầu, tiêu chí và bằng chứng"]
    F --> B

    X["Hiện chưa có:<br/>• decision reference<br/>• baseline reference<br/>• approval reference"] -. bằng chứng hiện trạng .-> IR

    E -- "Có" --> BA["BA ghi lựa chọn, trạng thái và bằng chứng<br/>BA không thay các vai trò quyết định"]
    BA --> Z["Hồ sơ quyết định được ghi nhận"]

Senior Lens

Cảnh báo chỉ dùng khi hành động sai có thể gây thiệt hại, mất kiểm soát, vi phạm bảo mật hoặc tạo cam kết thẩm quyền giả. Không dùng cảnh báo cho khác biệt văn phong. Phục hồi an toàn nghĩa là giữ nguyên bằng chứng, dừng thay đổi có tác động, cô lập cấu hình chưa phát hành, rồi đưa vấn đề về đúng owner. Không được “phục hồi” bằng cách xóa lịch sử, sửa im lặng nguồn canonical hoặc tự gán approval.

Quick Reference

Khi thấy	Làm ngay	Không làm
Phương án bị mô tả như quyết định	Đổi thành đề xuất và ghi owner cần xác nhận	Ghi “đã phê duyệt”
Claim pháp lý hoặc tuân thủ	Gắn Verification required; chuyển Legal Owner	Suy diễn nghĩa vụ cấu hình từ nguồn chưa xác minh
Cấu hình có nguy cơ tác động dữ liệu	Dừng phát hành, giữ log và phạm vi ảnh hưởng	Sửa dữ liệu hoặc bật production để “thử”
Sơ đồ dùng Mermaid hoặc PlantUML	Ghi đúng tên loại sơ đồ	Gọi sơ đồ đó là BPMN hoặc UML khi chưa dùng đúng ký pháp

Core

Năm lỗi khác nhau, không gộp thành “thiếu rõ ràng”. Mơ hồ là một câu có nhiều cách hiểu. Không đầy đủ là thiếu thông tin cần để xây, kiểm thử hoặc quyết định. Tuyên bố thẩm quyền không có bằng chứng là gọi nội dung là “đã phê duyệt”, “bắt buộc” hoặc “tuân thủ” khi artifact không có tham chiếu phê duyệt, baseline hoặc vai trò có thẩm quyền. Dùng sai ký pháp là gắn nhãn sơ đồ sai chuẩn. Đứt truy vết là không nối được nhu cầu, quy tắc, dữ liệu, quyết định và kiểm thử về nguồn canonical.

Loại lỗi	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Mơ hồ	“Xử lý nhanh đơn hàng lớn” không có ngưỡng, thời điểm, chủ thể	Viết theo cảm nhận, không tách điều kiện và kết quả	Hỏi “ai, làm gì, khi nào, với dữ liệu nào, kết quả đo được là gì”; ghi giả định nếu chưa xác minh
Không đầy đủ	Có quy tắc kiểm tra hạn dùng nhưng thiếu hành vi khi lô bị chặn	Chỉ ghi happy path, bỏ ngoại lệ	Bổ sung tiền điều kiện, ngoại lệ, thông báo, trạng thái, dữ liệu lưu và tiêu chí nghiệm thu
Thẩm quyền không có bằng chứng	“Đã được Legal duyệt” nhưng không có approval reference	Nhầm IN_REVIEW với phê duyệt	Đổi thành “Verification required”; nêu đúng owner cần xác minh
Sai ký pháp	Sơ đồ PlantUML activity được gọi là BPMN	Nhầm mục đích minh họa với chuẩn ký pháp	Gọi đúng tên sơ đồ; chỉ gọi BPMN khi dùng ký pháp BPMN 2.0.2 phù hợp
Đứt truy vết	Requirement dùng tên trường khác CANONICAL_DATA_DICTIONARY; không có liên kết rule	Sao chép cục bộ, không kiểm tra nguồn canonical	Tham chiếu nguyên dạng artifact ID, đường dẫn và trạng thái; dừng khi nguồn mâu thuẫn

Applied

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

Mục	Nội dung
Facts	Phiếu xuất kho mô phỏng ghi: “Cảnh báo nếu hạn dùng ngắn.” Artifact ở IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	Nhóm delivery tự diễn giải “ngắn” là dưới 30 ngày và chặn xuất kho.
Underlying Need	Business cần biết ngưỡng cảnh báo, ngưỡng chặn, vai trò được phép xử lý ngoại lệ và bằng chứng truy vết lô.
Options	A: giữ câu mơ hồ. B: ghi ngưỡng 30 ngày như quy tắc chính thức. C: ghi ngưỡng là project assumption, mở điểm xác minh với Business Owner và Food-safety/Legal Owner phù hợp.
Decision Criteria	Không tạo quy tắc vận hành từ suy đoán; giữ được kiểm thử; không tuyên bố tuân thủ pháp lý khi chưa xác minh nguồn và thẩm quyền.
Decision	Chọn C. Không cấu hình chặn xuất kho từ giả định.
Authority	Principal IT Business Analyst / Technical Curriculum Author chỉ quản trị artifact; không có quyền xác nhận quy tắc thực tế, legal/compliance sign-off hoặc production use.
Artifact	Liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY; giữ trạng thái IN_REVIEW, v0.9.0.
Consequence if Wrong	Chặn nhầm lô hàng, xuất nhầm lô, hoặc tạo bằng chứng giả rằng Nova Foods đã phê duyệt hay tuân thủ.

Cảnh báo: Không dùng cụm “đã phê duyệt”, “đã baseline”, “bắt buộc theo luật” hoặc “tuân thủ” nếu artifact không ghi tham chiếu xác minh tương ứng. Sai tuyên bố có thể dẫn tới quyết định triển khai sai và rủi ro pháp lý.

Ranh giới khôi phục an toàn: dừng cấu hình hoặc test đang dựa trên câu mơ hồ; giữ dữ liệu mô phỏng; ghi Verification required; chuyển câu hỏi và bằng chứng nguồn cho đúng owner. Không tự thay ngưỡng, không sửa lịch sử để làm như quyết định đã tồn tại.

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

flowchart TB
    A[Nhận requirement hoặc sơ đồ] --> B{Chỉ có một diễn giải vận hành?}
    B -- Không --> R[Giữ IN_REVIEW; dừng cấu hình hoặc test dựa trên câu mơ hồ; giữ dữ liệu mô phỏng; ghi Verification required; không tự thay ngưỡng; không sửa lịch sử]
    B -- Có --> D{Đủ điều kiện, ngoại lệ, dữ liệu và kết quả?}
    D -- Không --> R
    D -- Có --> F{Có nguồn canonical?}
    F -- Không --> R
    F -- Có --> U{Xác định đúng owner có thẩm quyền?}
    U -- Không --> R
    U -- Có --> P[Principal IT Business Analyst / Technical Curriculum Author chỉ quản trị artifact; không có quyền xác nhận rule thực tế]
    P --> O[Chọn phương án C; không cấu hình chặn xuất kho từ giả định]
    O --> OA[Loại A: giữ mơ hồ; không kiểm thử chắc chắn]
    O --> OB[Loại B: biến 30 ngày thành rule chưa xác minh; rủi ro chặn nhầm lô, xuất nhầm lô hoặc tạo bằng chứng phê duyệt/tuân thủ giả]
    O --> OC[Ghi ngưỡng 30 ngày là project assumption]
    OA --> R
    OB --> R
    OC --> Q[Mở xác minh: ngưỡng cảnh báo; ngưỡng chặn; vai trò xử lý ngoại lệ; bằng chứng truy vết lô]
    R --> Q
    Q --> E[Chuyển câu hỏi và bằng chứng nguồn cho Business Owner và Food-safety/Legal Owner phù hợp]
    E --> W[Business Owner và Food-safety/Legal Owner phù hợp mới có quyền xác nhận quy tắc thực tế]
    W --> T[Liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, decision, test và TRACEABILITY_ID_REGISTRY]
    T --> L[Giữ IN_REVIEW v0.9.0; chờ owner review; không hàm ý phê duyệt, baseline hoặc tuân thủ]

Senior Lens

Bằng chứng quyết định phải đi trước câu khẳng định. IN_REVIEW chỉ nói artifact đang được xem xét; không chứng minh approval, baseline, compliance hoặc sẵn sàng production. Nguồn pháp lý Việt Nam trong source seed chỉ tạo bối cảnh xác minh; diễn giải yêu cầu hệ thống cần Legal Owner, Accounting Owner hoặc domain owner phù hợp xác minh.

Ký pháp phục vụ giao tiếp, không tự tạo thẩm quyền. BPMN 2.0.2 là nguồn chuẩn cho BPMN; UML 2.5.1 là nguồn chuẩn cho UML. PlantUML tạo sơ đồ được, nhưng sơ đồ activity PlantUML không tự thành BPMN. Ghi “sơ đồ activity PlantUML” khi đó là nội dung thực tế.

Quick Reference

Kiểm tra trước khi dùng nội dung	Đạt khi
Ambiguity	Một người đọc độc lập xác định cùng chủ thể, điều kiện, hành động và kết quả
Incompleteness	Có luồng chính, ngoại lệ, dữ liệu, trạng thái và tiêu chí kiểm thử cần thiết
Authority	Có artifact kiểm soát ghi rõ nguồn, owner, trạng thái và tham chiếu phù hợp
Notation	Tên sơ đồ khớp ký pháp đã dùng
Traceability	Liên kết dùng đúng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY khi áp dụng

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn phương án “tốt nhất” chung chung. Senior BA so sánh phương án với mục tiêu, ràng buộc, rủi ro và thẩm quyền quyết định đã ghi nhận. Khuyến nghị chỉ phòng thủ được khi mỗi kết luận nối tới bằng chứng: nguồn canonical, dữ liệu tổng hợp Nova Foods, biên bản làm rõ được kiểm soát, hoặc giả định dự án có nhãn rõ. Nova Foods Trading & Manufacturing là case study mô phỏng; mọi dữ liệu chỉ là dữ liệu tổng hợp.

Khía cạnh	Câu hỏi senior review	Bằng chứng cần có	Khi không áp dụng quy tắc thường
Trade-off, đánh đổi	Phương án giảm chi phí nào làm tăng rủi ro, thời gian hoặc thao tác thủ công?	Bảng tiêu chí, tác động định lượng hoặc định tính, giả định ghi rõ	Không chọn phương án rẻ nhất nếu làm mất kiểm soát dữ liệu, audit trail hoặc khả năng truy vết cần xác minh
Exception, ngoại lệ	Ngoại lệ có hiếm, hợp lệ và có owner xử lý không?	Điều kiện kích hoạt, trạng thái, người xử lý, kết quả mong đợi	Không mã hóa ngoại lệ thành luồng chính khi chưa có tần suất hoặc Business Owner xác nhận
Xung đột stakeholder	Ai chịu chi phí, ai chịu rủi ro, ai có quyền quyết định?	RACI hoặc decision log ghi vai trò và phạm vi	Không dùng ý kiến số đông thay quyết định của owner có thẩm quyền
Chất lượng bằng chứng	Bằng chứng là quan sát, yêu cầu đã xác nhận, giả định hay diễn giải?	URL nguồn chính thức, artifact canonical, ngày truy cập 2026-08-07, nhãn Verification required	Không suy diễn nghĩa vụ pháp lý, kế toán, thuế, bảo mật hoặc an toàn thực phẩm từ nguồn thứ cấp
Decision authority, thẩm quyền quyết định	Quyết định thuộc Business Owner, Architect, Legal Owner, Accounting Owner, Security hay QA?	Decision log nêu quyết định, owner, đầu vào, trạng thái IN_REVIEW	BA không thay chủ thể có thẩm quyền để kết luận compliance, kiến trúc hay vận hành production

Ví dụ đánh đổi mô phỏng: bộ phận Kho muốn cho phép sửa trực tiếp số lượng lô sau khi hoàn tất nhập kho để xử lý nhanh; bộ phận Tài chính muốn chặn sửa để giữ dấu vết kiểm toán. Senior BA không kết luận bên nào đúng trước. Lý do: hai bên tối ưu mục tiêu khác nhau, tốc độ xử lý và khả năng truy vết. Khuyến nghị có thể là “đề xuất cơ chế điều chỉnh có lý do, người phê duyệt và lịch sử thay đổi”, nhưng đây chỉ là phương án thiết kế cần Architect, Business Owner và Accounting Owner xem xét. Nếu yêu cầu được diễn giải là nghĩa vụ pháp lý hoặc kế toán, gắn Verification required; nguồn Luật Kế toán chỉ là bối cảnh, không tự xác nhận rule hệ thống.

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

flowchart TB
    A[Nhận đề xuất và bằng chứng] --> B{Bằng chứng đã phân loại rõ?}
    B -- Không --> C[Ghi giả định hoặc Verification required]
    B -- Có --> D[So sánh lợi ích, chi phí, rủi ro và ngoại lệ]
    C --> D

    D --> E{Cần chuyển quyết định?<br/>Xung đột mục tiêu hoặc quy tắc canonical;<br/>vượt thẩm quyền BA; ảnh hưởng dữ liệu cá nhân,<br/>bút toán, hóa đơn, truy vết thực phẩm,<br/>phân quyền hoặc tích hợp}
    E -- Có --> G[Xác định và chuyển vấn đề tới owner phù hợp:<br/>Business Owner, Architect, Legal Owner,<br/>Accounting Owner, Security hoặc QA]
    E -- Không --> L{Đủ bằng chứng, thuộc phạm vi được giao<br/>và phù hợp quy tắc canonical?}
    L -- Không --> G
    L -- Có --> M[Soạn khuyến nghị có điều kiện;<br/>nêu dữ liệu thiếu và hậu quả nếu giả định sai]
    M --> R[Gửi khuyến nghị tới owner có thẩm quyền<br/>để review và quyết định]

    G --> N{Owner có thẩm quyền<br/>đã quyết định?}
    R --> N
    N -- Có --> O[Cập nhật decision log:<br/>owner, đầu vào và bằng chứng, quyết định,<br/>phương án bị loại và lý do, dữ liệu thiếu,<br/>hậu quả nếu giả định sai]
    N -- Chưa --> K[Cập nhật decision log với trạng thái IN_REVIEW:<br/>owner cần quyết định, đầu vào và bằng chứng,<br/>phương án đang xem xét, dữ liệu thiếu,<br/>hậu quả nếu giả định sai]
    K --> Q[Không coi khuyến nghị BA hoặc IN_REVIEW<br/>là phê duyệt, baseline hay quyền triển khai production]

    O --> P[Cập nhật traceability theo artifact canonical]
    Q --> P

Dấu hiệu đỏ gồm: yêu cầu dùng từ “bắt buộc” nhưng không có nguồn hoặc owner xác nhận; stakeholder yêu cầu bỏ audit trail để nhanh hơn; một người vừa đề xuất vừa tự phê duyệt; số liệu lợi ích không nêu cách tính; hoặc quy tắc mâu thuẫn với CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hay TRACEABILITY_ID_REGISTRY. Escalate khi lựa chọn ảnh hưởng dữ liệu cá nhân, bút toán, hóa đơn, truy vết thực phẩm, phân quyền, tích hợp, hoặc khi hai vai trò có thẩm quyền khác nhau không thống nhất. Không escalate mọi chi tiết giao diện; chỉ escalate khi BA không thể giải quyết bằng evidence, phạm vi đã được giao, hoặc quy tắc canonical.

Ngôn ngữ senior phải phản ánh độ chắc chắn. Dùng “bằng chứng hiện có cho thấy”, “giả định dự án”, “Verification required”, “khuyến nghị có điều kiện” thay vì “đã tuân thủ”, “đã được phê duyệt” hoặc “chắc chắn đúng”. Decision record cần tách rõ: phương án bị loại, lý do loại, dữ liệu còn thiếu, owner cần quyết định và hậu quả nếu giả định sai. IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải approval, baseline hay quyền triển khai production.

Senior Lens

Senior BA rà từng lựa chọn bằng câu hỏi: bằng chứng nào chứng minh lựa chọn đáp ứng nhu cầu, ai chịu hậu quả nếu sai, và điều gì chưa biết. Không suy từ ý kiến họp thành fact. Fact cần nguồn truy vết: quy trình hiện hành được quan sát, dữ liệu tổng hợp Nova Foods, artifact có ID, hoặc xác nhận từ vai trò có thẩm quyền. Ý kiến người dùng là input; không phải bằng chứng đủ để chốt tác động pháp lý, kế toán, bảo mật, kiến trúc hay an toàn thực phẩm.

Heuristic review	Áp dụng	Dấu hiệu đỏ	Ngưỡng escalation
Tách need khỏi solution	Viết nhu cầu theo kết quả cần đạt trước khi so sánh cấu hình ERP, tích hợp, thay đổi quy trình hoặc phát triển	Requirement chỉ nêu tên màn hình, module, vendor hoặc API nhưng không nêu kết quả nghiệp vụ	Escalate Business Owner khi hai bên cùng nhận nhu cầu nhưng đòi solution trái nhau
So sánh cùng tiêu chí	Chấm từng option theo phạm vi, chi phí, thời gian, rủi ro, khả năng vận hành, dữ liệu và kiểm soát	Một option có lợi ích định tính, option khác bị đòi số liệu định lượng	Escalate khi tiêu chí hoặc trọng số làm đảo quyết định nhưng chưa có owner xác nhận
Kiểm tra nguồn canonical	Đối chiếu rule với CANONICAL_BUSINESS_RULES, dữ liệu với CANONICAL_DATA_DICTIONARY, ID với TRACEABILITY_ID_REGISTRY	Hai artifact nêu khác nhau cho cùng đối tượng, rule hoặc trường dữ liệu	Dừng khuyến nghị; escalate Principal IT Business Analyst / Technical Curriculum Author để bảo toàn traceability và owner chuyên môn để kết luận
Phân quyền quyết định	BA phân tích, ghi nhận và đề xuất; owner đúng miền quyết định	BA bị yêu cầu “tự chốt” thuế, hạch toán, bảo mật, kiến trúc hoặc tuân thủ	Escalate ngay đến Legal, Accounting, Security, Architect, Compliance hoặc Business Owner tương ứng
Đo hậu quả sai	Nêu lỗi có thể gây mất dữ liệu, sai số VND, lộ dữ liệu cá nhân, gián đoạn kho hay sai truy xuất lô	“Có thể xử lý sau go-live” nhưng chưa có phương án khôi phục hoặc kiểm soát	Escalate ngay khi có nguy cơ mất dữ liệu, truy cập trái phép, sai chứng từ hoặc ảnh hưởng truy xuất/thu hồi thực phẩm

Quy tắc thường dùng: ưu tiên cấu hình chuẩn ERP hơn tùy biến. Lý do: ít mã hơn, ít chi phí bảo trì hơn, nâng cấp ít rủi ro hơn. Không áp dụng quy tắc này khi cấu hình chuẩn không đáp ứng kiểm soát bắt buộc đã được owner có thẩm quyền xác minh, làm hỏng traceability lô hàng, hoặc buộc vận hành ngoài hệ thống bằng bảng tính không kiểm soát. Khi đó, không tự suy ra “bắt buộc tùy biến”; yêu cầu Architect đánh giá khả năng kỹ thuật, Security đánh giá kiểm soát, Business Owner xác nhận trade-off vận hành.

Tình huống Nova Foods mô phỏng, dữ liệu tổng hợp	Không được chốt bằng	Cần escalation đến	Điều kiện mở lại quyết định
Luồng duyệt giảm giá có thể ảnh hưởng doanh thu VND	Ý kiến riêng Sales hoặc IT	Business Owner và Finance/Accounting Owner	Tiêu chí biên lợi nhuận, quyền duyệt, audit trail được xác nhận
Đồng bộ dữ liệu khách hàng qua API	Mô tả endpoint không có phân loại dữ liệu	Architect và Security	Data classification, quyền truy cập, lỗi tích hợp, log và chủ sở hữu vận hành rõ
Lưu dữ liệu cá nhân khách hàng	Diễn giải tự do từ nguồn pháp lý	Legal/Compliance Owner	Yêu cầu được legal-owner verification; nguồn chính thức còn hiệu lực được kiểm tra
Sửa trạng thái lô kho sau xuất hàng	Tiện lợi thao tác người dùng	Warehouse Owner, QA/Food-safety Owner, Architect	Tác động truy xuất, audit trail, quyền sửa và phương án khắc phục được đánh giá

Red flag mạnh: quyết định có từ hai miền thẩm quyền trở lên. Ví dụ, “mở API cho đối tác để tra cứu lô hàng” đồng thời là kiến trúc, bảo mật, dữ liệu và vận hành. BA lập decision log, không chọn thay các owner. Red flag khác: số liệu không có kỳ thời gian, mẫu dữ liệu quá nhỏ, giả định bị viết như fact, “compliant” không có xác minh, hoặc trạng thái IN_REVIEW bị gọi là approved hay baselined. Với corpus Nova Foods, v0.9.0 ngày 2026-08-07 vẫn là học liệu mô phỏng; không tạo approval, baseline hay quyền dùng production.

Senior Lens

Senior BA không biến thiếu dữ liệu thành kết luận. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; vì vậy khuyến nghị phải tách rõ fact (sự kiện đã có bằng chứng), assumption (giả định dự án), Verification required (cần xác minh) và recommendation (đề xuất có điều kiện). Cách tách này cho người đọc biết phần nào có thể kiểm tra ngay, phần nào chưa đủ để cam kết.

Thành phần ghi nhận	Nội dung artifact-ready	Cầu nối lập luận
Fact	Báo cáo tổng hợp cho thấy 18/120 đơn bán mô phỏng bị giữ vì mã khách hàng chưa đồng bộ giữa CRM và ERP.	Số lượng xuất phát từ bộ dữ liệu mô phỏng được trích dẫn trong artifact đang xem xét; không suy ra lỗi production.
Assumption	API đồng bộ có thể trả kết quả trong tối đa 5 phút.	Đây là giả định thiết kế để so sánh phương án, chưa phải cam kết kỹ thuật.
Verification required	Architect cần xác minh giới hạn tải, cơ chế retry và khả năng định danh khách hàng duy nhất.	Các điểm này quyết định liệu đồng bộ gần thời gian thực có khả thi hay không.
Recommendation	Ưu tiên phương án đồng bộ bất đồng bộ có hàng đợi, kèm màn hình trạng thái ngoại lệ.	Phương án giảm thao tác nhập lại theo fact, nhưng chỉ phù hợp nếu xác minh kỹ thuật đạt.
Confidence	Trung bình.	Bằng chứng vận hành đủ chỉ ra vấn đề, nhưng chưa có kết quả kiểm thử tải hay đặc tả API đã xác nhận.

Ngôn ngữ phải phản ánh mức chắc chắn. Viết: “Khuyến nghị có điều kiện chọn phương án B vì dữ liệu mô phỏng chỉ ra số đơn bị giữ; cần xác minh giới hạn API trước khi chốt.” Không viết: “Phương án B chắc chắn xử lý toàn bộ lỗi đồng bộ.” Câu thứ hai biến giả định thành cam kết và che mất điều kiện thất bại.

Một khuyến nghị phòng thủ được phải lưu trong artifact kiểm soát, giữ nguyên liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY khi các artifact này là nguồn liên quan. Tại v0.9.0, trạng thái IN_REVIEW, ngày 2026-08-07, không có baseline hoặc approval được suy diễn từ việc ghi khuyến nghị. Nếu bằng chứng mâu thuẫn, Senior BA ghi cả hai nguồn, mô tả ảnh hưởng của từng cách hiểu, và giữ quyết định ở trạng thái chờ xác minh thay vì chọn nguồn thuận tiện hơn.

12. Associated Template Reference & Completed Artifact

Core

Template là khung ghi nhận lặp lại được kiểm soát. Template không tự chứng minh nội dung đúng, không tạo baseline, không tạo approval. Với Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp; trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Liên kết template phải giữ đủ: ID, tệp canonical, mục đích, Owner, người dùng đầu ra, cổng chất lượng. Thiếu một trường làm người đọc không biết dùng biểu mẫu nào, ai chịu trách nhiệm, hoặc khi nào dừng chuyển giao.

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

flowchart TB
    A[Chọn template cho công việc] --> B[Đối chiếu nguồn template canonical]
    B --> C{Đủ ID, tệp canonical,<br/>mục đích, Owner, người dùng đầu ra,<br/>và cổng chất lượng?}
    C -- Có --> D[Liên kết đủ sáu trường]
    D --> E[Owner kiểm tra cổng chất lượng]
    E --> F[Người dùng đầu ra dùng artifact<br/>theo mục đích template]
    C -- Không --> G[Dừng chuyển giao]
    G --> H[Không xác định được biểu mẫu,<br/>trách nhiệm hoặc điểm dừng]

Applied

Facts: Nguồn đã xác minh nêu TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md, nhưng dữ liệu đầu vào không cung cấp ID template hay đường dẫn template riêng cho chapter 16.

Current Behavior: Chapter 16 cần nơi tra cứu template liên quan khuyến nghị phương án, đánh đổi và quyết định, nhưng không được tự đặt tên tệp hoặc ID.

Underlying Need: Người học cần biết artifact nào là nguồn đăng ký template và ai kiểm tra liên kết, thay vì nhầm handbook với template vận hành.

Options: Dùng ID/tệp tự tạo; sao chép toàn bộ registry; hoặc liên kết manifest canonical và ghi rõ giới hạn bằng chứng.

Decision Criteria: Không làm sai ID canonical; không suy diễn template chưa đăng ký; vẫn cho phép truy vết Owner, người dùng và quality gate.

Decision: Liên kết TEMPLATE_MANIFEST; không nêu template ID hoặc tệp template riêng khi chưa có đăng ký được cung cấp.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và liên kết corpus. Vai trò này không có quyền baseline, approval, xác nhận requirement Nova Foods, quyết định pháp lý, kế toán, bảo mật, kiến trúc hay production.

Artifact: /01-curriculum/TEMPLATE_MANIFEST.md, Artifact ID TEMPLATE_MANIFEST.

Consequence if Wrong: ID hoặc tệp bịa đặt làm đứt traceability, khiến người dùng điền sai biểu mẫu và có thể diễn giải nội dung học liệu mô phỏng thành quyết định ERP thực.

Senior Lens

Không dùng template chỉ vì có tên gần giống. Dùng khi đầu ra cần so sánh có cấu trúc giữa phương án, tiêu chí, bằng chứng, rủi ro và thẩm quyền quyết định. Không dùng khi chỉ cần giải thích khái niệm, khi chưa có template được đăng ký, hoặc khi việc điền biểu mẫu có thể bị hiểu nhầm là quyết định đã được phê duyệt.

Quality gate không phải chữ ký phê duyệt. Quality gate là điều kiện kiểm tra tối thiểu trước khi artifact được người khác dùng: đúng ID và đường dẫn canonical; phân biệt fact, assumption và Verification required; không biến nguồn pháp lý thành nghĩa vụ chưa có Legal Owner xác minh; không gọi IN_REVIEW là baseline hoặc approval.

Quick Reference

Template ID / tệp	Khi dùng	Khi không dùng	Owner	Người dùng đầu ra	Quality gate
TEMPLATE_MANIFEST /01-curriculum/TEMPLATE_MANIFEST.md	Tra cứu template đã được lập kế hoạch, metadata, phạm vi và ranh giới dùng template trong corpus.	Không dùng thay template đã điền; không dùng làm bằng chứng approval, baseline hay quyết định Nova Foods.	Principal IT Business Analyst / Technical Curriculum Author.	Handbook author, curriculum maintainer, QA reviewer.	ID và đường dẫn khớp đúng; status giữ IN_REVIEW; version giữ v0.9.0; không suy diễn template chưa đăng ký.
Không có template ID/tệp riêng được cung cấp cho chapter 16	Chỉ ghi nhận khoảng trống nguồn để tránh tạo định danh giả.	Không tự tạo OPT-*, REC-* hoặc tên tệp mới.	Principal IT Business Analyst / Technical Curriculum Author quản lý liên kết; không thay thẩm quyền chuyên môn.	Người soạn chapter, reviewer truy vết.	Mọi ID/tệp mới phải xuất hiện trước trong artifact canonical có kiểm soát; nếu chưa có, giữ trạng thái chưa liên kết.
TRACEABILITY_ID_REGISTRY /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra định danh được dùng trong liên kết liên-artifact.	Không dùng như template để ghi quyết định phương án.	Principal IT Business Analyst / Technical Curriculum Author.	BA, QA reviewer, curriculum maintainer.	Chuỗi ID giữ nguyên; xung đột ID phải escalation theo registry; không đổi tên dịch thuật.
CANONICAL_BUSINESS_RULES /01-curriculum/CANONICAL_BUSINESS_RULES.md	Đối chiếu quy tắc nghiệp vụ khi phương án tác động rule.	Không dùng để tự xác nhận rule là vận hành thật hoặc đã phê duyệt.	Principal IT Business Analyst / Technical Curriculum Author duy trì governance; Business Owner xác nhận nghiệp vụ khi cần.	BA, Business Owner, QA reviewer.	Rule được phân biệt với assumption; vấn đề pháp lý, kế toán, vận hành giữ nhãn Verification required.
CANONICAL_DATA_DICTIONARY /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Đối chiếu dữ liệu logic khi phương án tác động field, định nghĩa hoặc trao đổi dữ liệu.	Không dùng thay đặc tả API, thiết kế DB hay cấu hình ERP.	Principal IT Business Analyst / Technical Curriculum Author duy trì governance; Architect xác minh kỹ thuật khi cần.	BA, Architect, QA reviewer.	Tên dữ liệu và định nghĩa không bị đổi ngầm; giới hạn kỹ thuật cần Architect xác minh.

Quick Reference

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Artifact đã điền cho chương này nằm tại /02-handbook/16-solution-options-tradeoffs-and-recommendations.md, mục 12. Associated Template Reference & Completed Artifact, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Checklist tra cứu chương đầy đủ. Mục đích: tìm đúng nguồn chân lý trước khi dùng kết luận phương án. Không sao chép registry canonical vào chapter; chỉ liên kết ID và tệp kiểm soát.

Kiểm tra	Tra cứu tại	Bằng chứng cần thấy	Không dùng để kết luận
Định danh chapter, filename, dependency	/01-curriculum/CHAPTER_MANIFEST.md	Entry khớp chapter 16 và đường dẫn handbook	Approval, baseline, quyết định ERP
Cấu trúc học phần và vị trí lifecycle	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Chapter 16 nằm đúng chuỗi học từ requirement đến quyết định	Quy tắc vận hành Nova Foods
ID traceability	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID được đăng ký, loại ID đúng mục đích	Tạo ID mới hoặc đổi ID cũ
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Rule ID, phạm vi, nhãn xác minh còn nguyên	Diễn giải pháp lý, kế toán độc lập
Thuật ngữ và thuộc tính dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên logical data, định nghĩa, owner dữ liệu	Schema triển khai hoặc API contract
Nguồn và giới hạn trích dẫn	/00-research/00_SOURCE_MAP.md	Nguồn chính thức, version, safe use boundary	Bịa điều khoản, số trang, nghĩa vụ pháp lý
Template liên quan	/01-curriculum/TEMPLATE_MANIFEST.md	Template ID và filename đã đăng ký	Xem template plan là artifact đã phê duyệt
Artifact đã điền	/02-handbook/16-solution-options-tradeoffs-and-recommendations.md	Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Decision, Authority, Artifact, Consequence if Wrong	Bằng chứng user approval hoặc production readiness

Quy tắc đọc: manifest trả lời “tệp nào đúng”; registry trả lời “ID nào đúng”; catalog trả lời “nội dung canonical nào được tham chiếu”; source map trả lời “nguồn nào được dùng và giới hạn ra sao”. Vì mỗi artifact có thẩm quyền khác nhau, không suy ra approval từ IN_REVIEW, từ Owner, hoặc từ việc artifact tồn tại.

Senior Lens

Rà soát liên tệp trước handoff kiểm tra cùng một sự thật có giữ nguyên ID, trạng thái, phiên bản, nguồn và giới hạn thẩm quyền ở các artifact liên quan. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; vì vậy khớp tên hay số liệu không chứng minh ERP thực tế, tuân thủ hay phê duyệt.

Mã kiểm tra	Tệp kiểm tra chéo	Bằng chứng phải khớp	Kết quả tại 2026-08-07	Vấn đề mở hoặc Verification required	Owner escalation
XREV-01	/01-curriculum/CHAPTER_MANIFEST.md	Chapter, tên tệp, dependency của handbook phải khớp manifest	Verification required	Cần xác minh entry canonical của /02-handbook/16-solution-options-tradeoffs-and-recommendations.md; không suy diễn từ tên chương	Principal IT Business Analyst / Technical Curriculum Author
XREV-02	/01-curriculum/TEMPLATE_MANIFEST.md	Template ID và filename phải tồn tại trong manifest trước khi tham chiếu	Open issue	Chưa có bằng chứng trong gói đầu vào về template đã điền cho chương 16; không được tạo ID hoặc đường dẫn thay thế	Principal IT Business Analyst / Technical Curriculum Author
XREV-03	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID requirement, rule, data, integration phải giữ nguyên chuỗi canonical	Verification required	Cần kiểm tra mọi ID được chương 16 dùng có đăng ký và đúng loại; không đổi tiền tố để “dễ đọc”	Principal IT Business Analyst / Technical Curriculum Author; đúng lĩnh vực thì Business Owner, Architect, Security Owner, Legal Owner hoặc Accounting Owner
XREV-04	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Lựa chọn giải pháp không biến project assumption thành business rule	Open issue	Không có rule Nova Foods được xác nhận trong đầu vào; mọi tác động thuế, kế toán, hóa đơn, thực phẩm, dữ liệu cá nhân giữ nhãn Verification required	Business Owner; Accounting Owner; Legal Owner; Compliance Owner
XREV-05	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên thực thể, trường dữ liệu, phân loại dữ liệu không bị suy diễn thành schema triển khai	Verification required	Cần xác minh dữ liệu cá nhân, quyền truy cập, retention và luồng tích hợp trước khi kết luận option	Data Owner; Security Owner; Technical Architect
XREV-06	/00-research/00_SOURCE_MAP.md	Nguồn được dùng đúng safe use boundary và URL chính thức	Pass có điều kiện	Nguồn pháp lý chỉ tạo bối cảnh; diễn giải nghĩa vụ hệ thống cần đối chiếu văn bản hiện hành	Legal Owner; Compliance Owner
XREV-07	Metadata corpus	IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND phải nhất quán	Pass	Không có baseline reference hay approval reference; cấm mô tả nội dung là đã phê duyệt	Principal IT Business Analyst / Technical Curriculum Author

Quy tắc handoff: chỉ chuyển chapter sang vòng review khi từng dòng Open issue có owner nhận xử lý, từng dòng Verification required giữ nguyên nhãn, và không có xung đột ID hay source boundary. Nếu lựa chọn ảnh hưởng đồng thời nghiệp vụ và kiến trúc, Principal IT Business Analyst / Technical Curriculum Author lập gói bằng chứng, còn Business Owner và Technical Architect kết luận trong phạm vi thẩm quyền riêng. Nếu ảnh hưởng dữ liệu cá nhân, kế toán, thuế, hóa đơn, an toàn thực phẩm hoặc bảo mật, không thay kết luận chuyên môn bằng suy luận BA; escalation đến Legal Owner, Accounting Owner, Compliance Owner hoặc Security Owner tương ứng.