05 Business Needs Objectives And Scope

Trường kiểm soát	Giá trị
Artifact ID	05_BUSINESS_NEEDS_OBJECTIVES_AND_SCOPE
Tên tệp được kiểm soát	/02-handbook/05-business-needs-objectives-and-scope.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN
Bối cảnh	Việt Nam
Tiền tệ mô phỏng	VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp
Baseline	Chưa có baseline reference tại v0.9.0; IN_REVIEW không phải BASELINED.
Approval	Chưa có approval reference; metadata và nội dung review không tạo phê duyệt ngầm định.
Nguồn quản trị liên quan	CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY
Ranh giới thẩm quyền	Nội dung là học liệu BA. Không phải yêu cầu ERP production, quyết định vận hành, diễn giải pháp lý, kế toán, thuế, bảo mật hoặc xác nhận tuân thủ.

1. Concept l? g??

Core

Một thay đổi hệ thống không nên bắt đầu bằng câu “cần làm màn hình nào”. Câu đó nói về cách làm, chưa nói vì sao phải làm. Chapter này phân biệt ba lớp quyết định nền tảng: business need (nhu cầu nghiệp vụ), business objective (mục tiêu nghiệp vụ) và scope (phạm vi).

Business need là vấn đề, cơ hội hoặc nghĩa vụ mà tổ chức cần xử lý. Nó tồn tại trước giải pháp công nghệ. Ví dụ khái quát: nhân viên mất nhiều thời gian đối chiếu dữ liệu, doanh nghiệp bỏ lỡ cơ hội bán hàng, hoặc quy trình không tạo được bằng chứng cần thiết. Need trả lời: “Điều gì đang thiếu, sai, chậm, rủi ro hoặc có thể cải thiện?”

Business objective là kết quả mong muốn có thể kiểm tra, dùng để chứng minh need đã được xử lý đến mức nào. Objective không phải danh sách chức năng. “Xây chức năng phê duyệt” là giải pháp; “giảm thời gian xử lý yêu cầu theo ngưỡng đã thống nhất” mới là mục tiêu. Cầu nối suy luận là: need mô tả khoảng cách hiện tại; objective đặt trạng thái đích để đo việc thu hẹp khoảng cách đó.

Scope là đường biên có chủ ý của thay đổi: việc, quy trình, dữ liệu, vai trò, đơn vị tổ chức, hệ thống và thời điểm nào được xét; phần nào không được xét. Scope bảo vệ nhóm khỏi mở rộng vô hạn. Không có scope, mỗi bên có thể cùng dùng từ “dự án” nhưng đang hình dung các kết quả khác nhau.

Khái niệm	Câu hỏi gốc	Dạng bằng chứng cần có	Không được nhầm với
Business need	Vì sao phải thay đổi?	Sự kiện, số liệu, lỗi, rủi ro, cơ hội hoặc nghĩa vụ được ghi nhận	Màn hình, báo cáo, API, lựa chọn ERP
Business objective	Thành công trông như thế nào?	Chỉ số, ngưỡng, thời hạn, trạng thái đích, cách đo	Danh sách tính năng
Scope	Thay đổi dừng ở đâu?	In-scope, out-of-scope, ranh giới hệ thống và tổ chức	Danh sách mong muốn không giới hạn

Ba lớp phải liên kết nhưng không suy diễn thay nhau. Có need không tự chứng minh objective đúng; objective không tự cho phép thêm chức năng; scope không tự tạo business rule. BA ghi rõ bằng chứng và người có thẩm quyền cho từng quyết định, vì thay đổi ở một lớp có thể làm lớp khác không còn phù hợp. Trong corpus Nova Foods, mọi nội dung chỉ là mô phỏng giáo dục với dữ liệu tổng hợp; không được diễn giải thành nhu cầu, mục tiêu hoặc phạm vi vận hành thực tế.

Core

Business need là nhu cầu nghiệp vụ: vấn đề, cơ hội hoặc kết quả tổ chức cần đạt. Nó trả lời: “Vì sao phải thay đổi?” Không phải màn hình, trường dữ liệu, API hay cách cấu hình ERP. BA dùng nhu cầu nghiệp vụ làm gốc để tránh biến giải pháp sớm thành yêu cầu.

Thuật ngữ	Nghĩa ngắn	Câu hỏi kiểm tra
Actor	Tác nhân thực hiện, khởi tạo hoặc chịu ảnh hưởng bởi hành vi. Có thể là người, bộ phận, hệ thống ngoài hoặc hệ thống ERP.	Ai làm, ai nhận, ai chịu trách nhiệm?
Action	Hành động tác nhân thực hiện. Dùng động từ quan sát được: tạo, kiểm tra, phê duyệt, ghi nhận, đối soát.	Tác nhân làm gì?
Object	Đối tượng hành động tác động tới. Có thể là đơn bán, lô hàng, phiếu nhập, dữ liệu tồn kho.	Hành động tác động vào cái gì?
Outcome	Kết quả mong muốn, đo được sau hành động. Outcome khác output: output là thứ tạo ra; outcome là giá trị hoặc trạng thái được cải thiện.	Điều gì tốt hơn, đúng hơn, nhanh hơn hoặc ít rủi ro hơn?
Business objective	Mục tiêu nghiệp vụ. Mô tả trạng thái đích có thể đánh giá bằng chỉ số, thời hạn hoặc tiêu chí thành công.	Cần đạt kết quả nào, khi nào, đo bằng gì?
Scope	Phạm vi. Ranh giới phần việc, quy trình, dữ liệu, tổ chức hoặc hệ thống được xem xét.	Bao gồm gì, loại trừ gì?
Requirement	Yêu cầu. Điều hệ thống, quy trình hoặc tổ chức phải đáp ứng để phục vụ nhu cầu. Requirement chỉ hợp lệ khi truy được về need hoặc objective.
ERP	Enterprise Resource Planning — hệ thống hoạch định nguồn lực doanh nghiệp. ERP tích hợp dữ liệu và quy trình như mua hàng, kho, bán hàng, sản xuất, tài chính. ERP là phương tiện; không tự là business need.

Cấu trúc tối thiểu để diễn đạt nhu cầu: actor + action + object + outcome. Ví dụ mô phỏng: “Nhân viên kho (actor) xác nhận nhập (action) từng lô nguyên liệu (object) để tồn kho theo lô được cập nhật đúng trước khi lập kế hoạch sản xuất (outcome).” Câu này nêu hành vi và giá trị; chưa áp đặt dùng màn hình nào, quét mã nào, hay tích hợp với thiết bị nào.

Với Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp — câu “Cần thêm màn hình quét mã lô” là đề xuất giải pháp, không phải business need. Bằng chứng: câu nêu giao diện cụ thể nhưng không nêu vấn đề hiện tại, actor nghiệp vụ, kết quả cần đạt hoặc tiêu chí thành công. BA phải lùi một bước, hỏi nhu cầu phía sau: cần giảm sai lệch nhận hàng, tăng khả năng truy vết, hay rút ngắn thời gian ghi nhận.

Ranh giới khái niệm: phần này chỉ chuẩn hóa ngôn ngữ để nhận diện business need, objective và scope. Không xác định quy trình Nova Foods thực tế, không tạo requirement, business rule, KPI, acceptance criteria, thiết kế ERP, lựa chọn nhà cung cấp, quyết định pháp lý, kế toán hay tuân thủ. Mọi ví dụ Nova Foods chỉ là mô phỏng, không phải xác nhận vận hành hoặc phê duyệt.

Applied

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

Mục	Nội dung
Facts	Kho trung tâm nhận 120 thùng NF-MILK-01 từ nhà cung cấp mô phỏng. Nhân viên kho ghi nhận số nhận thực tế là 118 thùng do 2 thùng hư hỏng.
Current Behavior	Nhân viên ghi Excel riêng, rồi gửi email cho mua hàng. Tồn kho ERP không đổi ngay; mua hàng không có dữ liệu chuẩn để xử lý thiếu hàng.
Underlying Need	Nova Foods cần ghi nhận chênh lệch khi nhận hàng để tồn kho, mua hàng và xử lý nhà cung cấp cùng dựa trên một kết quả nhất quán.
Options	(1) Giữ Excel và email. (2) ERP ghi nhận số nhận, số hư hỏng và trạng thái chênh lệch.
Decision Criteria	Dữ liệu nhập một lần; truy được người ghi nhận; tồn kho không tăng theo số không nhận được; không tự suy diễn nghĩa vụ thanh toán hay quyết định trả hàng.
Decision	Mô tả business need: hệ thống cần hỗ trợ ghi nhận kết quả nhận hàng có chênh lệch so với số đặt. Đây chưa phải yêu cầu màn hình, API hay cấu hình ERP.
Authority	Business Owner xác nhận nhu cầu vận hành. Accounting Owner xác nhận tác động hạch toán. Legal/Compliance Owner xác nhận nghĩa vụ liên quan nếu có. BA không tự xác nhận các quyết định này.
Artifact	Nội dung nhu cầu được ghi trong /02-handbook/05-business-needs-objectives-and-scope.md; trạng thái corpus IN_REVIEW, version v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu nhầm “ghi nhận chênh lệch” thành “tự động giảm hóa đơn”, đội dự án biến nhu cầu thành quyết định kế toán chưa được thẩm quyền xác nhận.

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

flowchart TB
    A[Đơn mua: 120 thùng] --> B[Kho nhận hàng]
    B --> C[Ghi nhận: 118 thực nhận, 2 thùng hư hỏng]
    C --> D[Hiện trạng: Excel riêng, email; ERP không cập nhật ngay]
    D --> E[Rủi ro: dữ liệu nhận hàng không nhất quán; mua hàng thiếu dữ liệu chuẩn]
    E --> F[Business need: ghi nhận chênh lệch khi nhận hàng]

    F --> G[Dữ liệu nhập một lần]
    F --> H[Truy được người ghi nhận]
    F --> I[Kết quả nhận hàng dùng chung: 118 thực nhận, 2 hư hỏng]
    I --> J[Tồn kho phản ánh số thực nhận]
    I --> K[Mua hàng tiếp nhận dữ liệu chênh lệch để xử lý theo quyết định có thẩm quyền]
    I --> L[Xử lý nhà cung cấp dựa trên dữ liệu chênh lệch]

    F -. không tự suy diễn .-> M[Không tự động giảm hóa đơn]
    F -. không tự suy diễn .-> N[Không tự tạo bút toán]
    F -. không tự suy diễn .-> O[Không tự quyết định trả hàng]

    F --> P[Business Owner xác nhận nhu cầu]
    F --> Q[Accounting Owner xác nhận tác động hạch toán]
    F --> R[Legal/Compliance Owner xác nhận nghĩa vụ liên quan nếu có]
    S[BA không tự xác nhận các quyết định] -. ranh giới .-> P
    S -. ranh giới .-> Q
    S -. ranh giới .-> R

Ranh giới concept: Business need là lý do nghiệp vụ cần thay đổi hoặc cần duy trì năng lực. Trong ví dụ, lý do là giảm sai lệch dữ liệu giữa nhận hàng và tồn kho. Nó trả lời “vì sao cần giải quyết”, không trả lời “xây thế nào”.

Loại trừ: Không xác định màn hình nhập liệu, trường dữ liệu, workflow phê duyệt, công thức giá trị, bút toán, thuế, hóa đơn, quy tắc đổi trả, tích hợp nhà cung cấp, phân quyền hay tiêu chí kiểm thử. Các nội dung này cần đầu vào và thẩm quyền riêng; không được suy ra từ business need.

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

Core

Business needs, objectives and scope tồn tại để chặn dự án giải sai vấn đề. Business need là nhu cầu thay đổi năng lực nghiệp vụ; objective là kết quả mong muốn có thể kiểm tra; scope là ranh giới phần việc được làm và không làm. Thiếu ba phần này, một yêu cầu như “cần quản lý nhận hàng tốt hơn” có thể bị mỗi vai trò hiểu khác: kho muốn ghi nhận hàng hư hỏng, mua hàng muốn theo dõi chênh lệch, kế toán có thể hiểu là cần thay đổi xử lý chứng từ, đội kỹ thuật có thể bắt đầu dựng màn hình. Cùng một câu, nhiều hướng xây dựng. Đây là mơ hồ nghiệp vụ.

Rủi ro đầu tiên là rework: làm lại công việc đã hoàn thành vì đầu ra không phục vụ nhu cầu gốc. Ví dụ, đội kỹ thuật hoàn thành màn hình nhận hàng, nhưng Business Owner sau đó nêu mục tiêu cần thấy chênh lệch giữa số đặt và số đạt. Nếu mục tiêu này chưa được ghi trước, dữ liệu, báo cáo, luồng xử lý và kiểm thử đều có thể phải sửa. Rework không chỉ là sửa mã; còn gồm sửa tài liệu, kiểm thử, đào tạo và dữ liệu mô phỏng.

Rủi ro thứ hai là scope creep, tức phạm vi tăng không kiểm soát. Khi scope không nêu phần loại trừ, một nhu cầu ghi nhận chênh lệch có thể bị kéo sang tự động điều chỉnh hóa đơn, trả hàng nhà cung cấp, phân quyền phê duyệt và tích hợp bên ngoài. Các phần này có tác động kế toán, pháp lý, bảo mật hoặc kiến trúc riêng. BA phải ghi ranh giới để nhóm biết điều gì chưa được quyết định, không biến suy đoán thành cam kết.

Rủi ro thứ ba là lỗi quản trị. IN_REVIEW tại v0.9.0 nghĩa là nội dung còn được xem xét; không phải baseline, approval hay quyền triển khai. Nếu không ghi rõ need, objective và scope trong artifact kiểm soát, người đọc khó truy vết vì sao một yêu cầu tồn tại, ai có thẩm quyền quyết định, và thay đổi nào ảnh hưởng mục tiêu nào. Traceability bị đứt khi quyết định kỹ thuật không còn nối được về lý do nghiệp vụ.

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

flowchart TB
    A[Nhu cầu nghiệp vụ chưa rõ] --> B[Diễn giải khác nhau]
    B --> C[Giải pháp xây sai trọng tâm]
    C --> D[Làm lại mã, tài liệu, kiểm thử, đào tạo hoặc dữ liệu mô phỏng]

    A --> E[Phạm vi không có phần loại trừ]
    E --> F[Hạng mục ngoài phạm vi bị suy đoán thành cam kết]
    F --> G[Phạm vi tăng không kiểm soát và rủi ro kế toán, pháp lý, bảo mật hoặc kiến trúc]

    H[Nhu cầu nghiệp vụ rõ:<br/>năng lực cần thay đổi] --> K[Artifact kiểm soát]
    I[Mục tiêu rõ:<br/>kết quả có thể kiểm tra] --> K
    J[Phạm vi rõ:<br/>phần làm và không làm] --> K
    K --> L[Quyết định có căn cứ]
    K --> M[Truy vết yêu cầu và quyết định kỹ thuật<br/>về lý do nghiệp vụ và thẩm quyền quyết định]

    N[Không ghi nhu cầu nghiệp vụ,<br/>mục tiêu và phạm vi trong artifact] --> O[Đứt truy vết về lý do nghiệp vụ<br/>và thẩm quyền quyết định]

    P[`IN_REVIEW` tại `v0.9.0`] --> Q[Artifact còn được xem xét]
    Q --> R[Chưa là baseline, approval<br/>hoặc quyền triển khai]

Applied

Thành phần	Nội dung mô phỏng Nova Foods
Facts	Nova Foods Trading & Manufacturing là case study giáo dục, chỉ dùng dữ liệu tổng hợp. Nội dung corpus hiện IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	Nhân viên kho có thể ghi nhận kết quả nhận hàng, nhưng nhu cầu thay đổi chưa được tách thành mục tiêu và ranh giới phạm vi trong mô tả ban đầu.
Underlying Need	Cần xác định rõ vấn đề nghiệp vụ cần giải quyết trước khi chọn màn hình, báo cáo, API hoặc cấu hình ERP.
Options	(1) Bắt đầu thiết kế chức năng từ mô tả ngắn. (2) Ghi business need, objective và scope trước; chỉ sau đó mới phân tích giải pháp.
Decision Criteria	Phương án phải giảm diễn giải khác nhau, cho phép truy vết thay đổi, không tự quyết định kế toán/pháp lý, và giữ phần chưa xác nhận ngoài phạm vi.
Decision	Chọn phương án (2): xác định business need, objective và scope trước hoạt động thiết kế giải pháp.
Authority	Business Owner xác nhận nhu cầu và ưu tiên nghiệp vụ. Accounting Owner, Legal/Compliance Owner, Architect hoặc Security xác nhận phần thuộc thẩm quyền của họ. BA ghi nhận, phân tích và truy vết; không tự phê duyệt.
Artifact	/02-handbook/05-business-needs-objectives-and-scope.md là tài liệu học liệu đang IN_REVIEW; liên kết quản trị dùng CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY theo phạm vi từng artifact.
Consequence if Wrong	Nếu coi “ghi nhận chênh lệch” là quyết định tự động điều chỉnh chứng từ, dự án có thể xây quy trình vượt nhu cầu ban đầu và vượt thẩm quyền BA.

Senior Lens

Senior BA không hỏi “cần tính năng gì” đầu tiên. Câu hỏi đầu là “vấn đề nào đang gây mất kiểm soát, và kết quả nào chứng minh vấn đề đã được xử lý?”. Reasoning bridge: tính năng là cách thực hiện; nhiều cách có thể cùng phục vụ một need. Khi need chưa rõ, không có tiêu chuẩn khách quan để chọn giữa các cách đó.

Objective phải đủ cụ thể để làm căn cứ quyết định nhưng không ép giải pháp sớm. Scope phải ghi cả in scope và out of scope. Phần ngoài scope không có nghĩa là không quan trọng; nó nghĩa là chưa được cam kết trong phạm vi đang xét và cần quyết định riêng. Với nội dung 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, mọi nghĩa vụ chi tiết chưa được đối chiếu nguồn chính thức hiện hành phải giữ nhãn Verification required hoặc project assumption.

Quick Reference

Nếu thiếu	Hậu quả cần ngăn
Business need	Đội xây tính năng nhưng không chứng minh được lý do nghiệp vụ.
Objective	Không có tiêu chuẩn chung để đánh giá kết quả mong muốn.
In scope	Công việc bị bỏ sót vì không ai biết phải thực hiện phần nào.
Out of scope	Phạm vi tăng ngầm, kéo theo quyết định chưa có thẩm quyền.
Traceability	Không truy được liên hệ giữa nhu cầu, quyết định, thay đổi và kiểm thử.
Nhãn trạng thái IN_REVIEW	Nội dung review bị hiểu sai thành baseline hoặc approval.

Core

Business Needs, Objectives and Scope tồn tại để biến lời đề nghị rộng thành ranh giới quyết định được. Nova Foods Trading & Manufacturing là case study mô phỏng; mọi tình huống dưới đây dùng dữ liệu tổng hợp. Không có ranh giới, nhóm có thể cùng hiểu “quản lý lô hàng” nhưng làm các chức năng khác nhau: kho cần truy xuất lô, bán hàng cần chặn bán hàng không đạt điều kiện, tài chính cần chứng từ. Hậu quả quan sát được là backlog đổi hướng, cùng dữ liệu bị nhập ở nhiều nơi, và test không có tiêu chí xác định đúng hay sai.

Applied

Mục	Trước khi làm rõ business need, objective và scope	Sau khi làm rõ
Facts	Nhân viên kho ghi số lô trên bảng tính; đơn bán hàng được tạo trong ERP mô phỏng nhưng không có bước kiểm tra lô.	Bảng tính và đơn bán hàng mô phỏng được xem là đầu vào hiện trạng; chưa kết luận đây là cấu hình ERP thật.
Current Behavior	Kho chọn lô bằng cách xem bảng tính. Bán hàng có thể xác nhận đơn trước khi kho đối chiếu lô. Khi có chênh lệch, nhân viên trao đổi thủ công để sửa đơn hoặc đổi lô.	Luồng hiện trạng được mô tả tách khỏi luồng mong muốn, nên không nhầm cách làm tạm thời với yêu cầu hệ thống.
Underlying Need	“Cần ERP quản lý lô” quá rộng: chưa nói ai cần quyết định gì, tại thời điểm nào, và lỗi nào phải ngăn chặn.	Nhu cầu được thu hẹp: kho cần chọn lô có thông tin truy xuất; bán hàng cần biết đơn có thể tiếp tục hay phải dừng chờ kho xác nhận.
Options	Nhóm có thể làm màn hình nhập lô mới, sửa bảng tính, hoặc tích hợp quy trình phê duyệt, nhưng chưa có căn cứ chọn.	So sánh phương án theo khả năng ngăn bán nhầm lô, giữ truy vết từ đơn đến lô, số bước thủ công, dữ liệu cần có và quyền quyết định.
Decision Criteria	Tiêu chí ngầm định theo người nói to nhất.	Phương án chỉ phù hợp nếu xác định được lô trên dòng giao hàng, ghi lại người xác nhận, và tạo bằng chứng để kiểm tra sau đó.
Decision	Chưa có quyết định; phát triển có thể bắt đầu từ màn hình được yêu cầu gần nhất.	Chưa được quyết định trong micro-batch này. Business Owner, kho và các owner liên quan phải chọn phương án sau khi xác minh dữ liệu lô, quy trình giao hàng và thẩm quyền kiểm soát.
Authority	Không rõ ai quyết định phạm vi hay chấp nhận rủi ro bán nhầm lô.	BA ghi nhận và phân tích. Business Owner quyết định mục tiêu/phạm vi. Owner vận hành kho xác nhận khả năng vận hành. QA dùng tiêu chí đã quyết định làm test basis.
Artifact	Tin nhắn, trao đổi miệng và bảng tính rời rạc.	Business Needs, Objectives and Scope ghi ranh giới: quản lý lô tại khâu chọn lô và xác nhận giao hàng; không tự mở rộng sang diễn giải pháp lý, cấu hình production hay phê duyệt tuân thủ.
Consequence if Wrong	Có thể xây chức năng nhập số lô nhưng vẫn cho đơn đi tiếp khi lô chưa được kho xác nhận. Lỗi chỉ lộ khi đối chiếu giao hàng; nhóm phải sửa luồng, dữ liệu và test đã viết.	Nếu nhu cầu bị thu hẹp sai, hệ thống có thể chặn hoạt động hợp lệ hoặc bỏ sót điểm kiểm soát cần thiết. Vì vậy quyết định cần bằng chứng vận hành và kiểm tra theo quyền hạn.

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

flowchart TB
    subgraph HT["Hiện trạng được quan sát"]
        A[Tạo đơn bán hàng trong ERP mô phỏng] --> B{Thứ tự xác nhận và đối chiếu lô?}
        B -- Bán hàng xác nhận trước --> C[Đơn có thể được xác nhận<br/>trước khi kho đối chiếu lô]
        B -- Kho đối chiếu trước --> D[Kho xem bảng tính<br/>và đối chiếu lô]
        C --> D
        D --> E{Có chênh lệch?}
        E -- Không --> G[Xác nhận giao hàng]
        E -- Có --> F[Trao đổi thủ công để<br/>sửa đơn hoặc đổi lô]
        F --> R{Đã giải quyết?}
        R -- Đã --> G
        R -- Chưa --> S[Dừng hoặc chờ làm rõ]
    end

    A -.-> T[Đầu vào hiện trạng:<br/>luồng quan sát, bảng tính<br/>và đơn bán hàng mô phỏng]
    G -.-> T
    S -.-> T

    subgraph LC["Làm rõ nhu cầu và phạm vi"]
        T --> H[BA ghi nhận và phân tích]
        H --> N1[Kho cần chọn lô<br/>có thông tin truy xuất]
        H --> N2[Bán hàng cần biết đơn<br/>được tiếp tục hay dừng<br/>chờ kho xác nhận]

        N1 --> O[So sánh phương án]
        N2 --> O
        O --> OC[Tiêu chí so sánh:<br/>ngăn bán nhầm lô;<br/>truy vết đơn và lô;<br/>số bước thủ công;<br/>dữ liệu cần có;<br/>quyền quyết định]
        OC --> P[Phương án chỉ phù hợp nếu<br/>xác định được lô trên dòng giao hàng,<br/>ghi lại người xác nhận<br/>và tạo bằng chứng kiểm tra]

        H --> I[Owner vận hành kho<br/>xác nhận khả năng vận hành]
        H --> J[Owner liên quan xác minh<br/>dữ liệu lô, quy trình giao hàng<br/>và thẩm quyền kiểm soát]
        I --> U[Điểm chưa rõ:<br/>ai có thẩm quyền chấp nhận<br/>rủi ro bán nhầm lô]
        J --> U

        U --> V[Trạng thái hiện tại:<br/>Chưa có quyết định<br/>trong micro-batch này]
        V --> K{Trong tương lai:<br/>đủ bằng chứng và<br/>đã làm rõ thẩm quyền?}

        K -- Chưa --> L[BA ghi nhận khoảng trống;<br/>owner liên quan bổ sung<br/>bằng chứng hoặc thẩm quyền]
        L --> K

        P --> K
        K -- Nếu sau này đủ --> M[Business Owner chọn phương án<br/>và quyết định mục tiêu, phạm vi]
        M --> Q[Quy trình mục tiêu được xác định;<br/>QA dùng tiêu chí đã quyết định<br/>làm test basis]
    end

    subgraph RG["Ranh giới và hệ quả"]
        W[Trong phạm vi:<br/>chọn lô và xác nhận giao hàng]
        X[Ngoài phạm vi:<br/>diễn giải pháp lý;<br/>cấu hình production;<br/>phê duyệt tuân thủ]
        Y[Nếu nhu cầu hoặc quyết định sai:<br/>chặn hoạt động hợp lệ hoặc<br/>bỏ sót điểm kiểm soát cần thiết]
    end

    H -. xác lập ranh giới .-> W
    W -. không tự mở rộng .-> X
    M -. nếu quyết định sai .-> Y

Senior Lens

Đối chiếu trước/sau không nhằm chứng minh phương án sau đã đúng hoặc đã được phê duyệt. Nó làm lộ chi phí của mơ hồ bằng hậu quả quan sát được: ai phải làm lại, dữ liệu nào không liên kết, điểm nào không thể test, và quyết định nào chưa có chủ thể chịu trách nhiệm. Không dùng số liệu hiệu quả, tỷ lệ lỗi, cam kết tuân thủ hoặc yêu cầu pháp lý nếu chưa có nguồn và xác minh phù hợp.

Quick Reference

Câu hỏi kiểm tra	Dấu hiệu đủ rõ
Trước đây việc gì xảy ra?	Có mô tả hành vi, vai trò và dữ liệu đang dùng.
Sau thay đổi khác gì?	Có điểm kiểm soát hoặc kết quả quan sát được, không chỉ có tên tính năng.
Phạm vi ngăn việc gì?	Nêu rõ hoạt động trong phạm vi và hoạt động không tự suy diễn vào phạm vi.
Sai thì hậu quả gì?	Chỉ ra rework, dữ liệu rời rạc, quyết định mơ hồ hoặc test thiếu căn cứ.

Core

Năm nhãn này ngăn BA biến lời nói, suy đoán và lựa chọn đang chờ thẩm quyền thành “sự thật”. Với Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp, mỗi câu phải mang đúng nhãn trước khi đi vào scope, requirement hoặc business rule.

Nhãn	Định nghĩa từ nguyên tắc đầu tiên	Bằng chứng tối thiểu	Không được suy diễn thành
Verified fact — sự kiện đã xác minh	Thông tin khớp với nguồn kiểm soát có thể truy lại.	Artifact canonical, URL chính thức, metadata hoặc bằng chứng kiểm tra.	Nhu cầu nghiệp vụ, quyết định, approval.
Stakeholder input — đầu vào stakeholder	Điều stakeholder cung cấp về vấn đề, mục tiêu, cách làm hoặc ưu tiên.	Vai trò, ngày ghi nhận, nội dung được diễn đạt lại không thêm ý.	Sự thật đã xác minh hoặc yêu cầu được phê duyệt.
Project assumption — giả định dự án	Điều tạm coi đúng để tiếp tục phân tích khi chưa có bằng chứng đủ.	Lý do dùng, tác động nếu sai, owner xác minh.	Business rule bắt buộc hoặc nghĩa vụ pháp lý.
Decision — quyết định	Lựa chọn giữa các phương án theo tiêu chí rõ, do vai trò có thẩm quyền ghi nhận.	Phương án, tiêu chí, authority, artifact quyết định.	Approval nếu artifact không ghi approval.
Verification-required claim — nhận định cần xác minh	Nhận định có thể ảnh hưởng scope, pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc vận hành nhưng nguồn chưa đủ.	Câu hỏi xác minh, nguồn cần kiểm, owner có thẩm quyền.	Fact, rule hay compliance đã đạt.

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

flowchart TB
    A[Nhận thông tin] --> B{Có nguồn kiểm soát<br/>truy lại được?}

    B -->|Có| C{Thông tin khớp<br/>nguồn kiểm soát?}
    C -->|Có| D[Verified fact]
    C -->|Không| E{Là nội dung<br/>stakeholder cung cấp?}
    B -->|Không| E

    E -->|Có| F{Có vai trò, ngày ghi nhận<br/>và nội dung diễn đạt lại<br/>không thêm ý?}
    F -->|Có| G[Stakeholder input]
    F -->|Không| H[Không đưa vào scope/requirement/<br/>business rule; yêu cầu làm rõ]

    E -->|Không| I{Cần tạm dùng<br/>để phân tích?}
    I -->|Có| J{Có lý do dùng, tác động nếu sai<br/>và owner xác minh?}
    J -->|Có| K[Project assumption]
    J -->|Không| H

    I -->|Không| L{Là nhận định ảnh hưởng scope,<br/>pháp lý, kế toán, an toàn thực phẩm,<br/>bảo mật hoặc vận hành;<br/>nguồn chưa đủ?}
    L -->|Không| H
    L -->|Có| M{Có câu hỏi xác minh,<br/>nguồn cần kiểm và owner<br/>có thẩm quyền?}
    M -->|Không| H
    M -->|Có| N[Verification-required claim]

    N --> O{Đã xác minh<br/>đủ nguồn?}
    O -->|Có| P[Phân loại lại từ đầu<br/>theo kết quả xác minh]
    P --> A
    O -->|Không| Q[Giữ Verification-required claim;<br/>không dùng như fact/rule/compliance]

    D -. đầu vào xem xét; không thay nhãn nguồn .-> R{Có lựa chọn giữa các phương án,<br/>tiêu chí, authority và artifact<br/>ghi nhận?}
    G -. đầu vào xem xét; không thay nhãn nguồn .-> R
    K -. đầu vào xem xét; không thay nhãn nguồn .-> R
    N -. đầu vào xem xét; không thay nhãn nguồn .-> R

    R -->|Có| S[Tạo bản ghi Decision riêng]
    R -->|Không| T[Không tạo Decision;<br/>giữ nhãn nguồn]

    S --> U{Artifact quyết định<br/>ghi rõ approval?}
    U -->|Có| V[Giữ Decision;<br/>ghi approval]
    U -->|Không| W[Giữ Decision;<br/>không suy diễn approval]

Applied

Ví dụ dưới dùng Nova Foods mô phỏng. Không câu nào xác nhận cấu hình ERP thật, nghĩa vụ pháp lý đã áp dụng, hoặc phê duyệt của bất kỳ người dùng nào.

Trường	Nội dung phân loại
Facts	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Các artifact đều ghi chưa có baseline reference và approval reference. Đây là verified fact vì metadata nguồn kiểm soát nêu trực tiếp.
Current Behavior	Đầu vào stakeholder mô phỏng: vai trò Quản lý Kho cho biết cần phân biệt hàng còn dùng được với hàng cần được kiểm tra trước khi xuất. Đây là stakeholder input, chưa phải fact về ERP hiện hữu vì chưa có log, cấu hình hay quy trình được xác minh.
Underlying Need	BA suy luận cần làm rõ trạng thái lô hàng trước khi viết requirement xuất kho. Cầu nối suy luận: nếu cùng một trạng thái bị hiểu khác nhau, điều kiện cho phép xuất sẽ không xác định; vì vậy cần dữ liệu, rule và authority rõ. Đây là nhu cầu phân tích, không phải quyết định triển khai.
Options	(1) Ghi ngay rule “chỉ lô đạt kiểm tra mới được xuất”; (2) ghi đây là project assumption để mô hình hóa luồng; (3) giữ là verification-required claim và yêu cầu domain owner, Legal Owner xác minh quy tắc áp dụng.
Decision Criteria	Chọn theo: có nguồn canonical xác nhận hay không; có ảnh hưởng an toàn thực phẩm, truy xuất hoặc compliance hay không; vai trò nào có thẩm quyền quyết định; việc chọn có làm phát sinh business rule bắt buộc hay không.
Decision	Không tạo canonical business rule tại thời điểm này. Phân loại câu “chỉ lô đạt kiểm tra mới được xuất” là verification-required claim. Lý do: nguồn seed chỉ cho bối cảnh Luật An toàn thực phẩm và yêu cầu domain-owner, legal verification; không cung cấp quy tắc Nova Foods cụ thể.
Authority	Business Owner và domain owner xác nhận nhu cầu vận hành; Legal Owner xác minh diễn giải nghĩa vụ pháp lý; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability, không thay thế các thẩm quyền này.
Artifact	Ghi nhận phân loại và liên kết nguồn trong /01-curriculum/CANONICAL_BUSINESS_RULES.md; dùng ID, trạng thái, version theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Không gọi nội dung này là baseline hoặc approved.
Consequence if Wrong	Nếu stakeholder input bị ghi thành verified fact, team có thể thiết kế sai điều kiện xuất. Nếu assumption bị ghi thành decision, QA có thể test một rule chưa có authority. Nếu verification-required claim bị bỏ nhãn, rủi ro pháp lý hoặc an toàn thực phẩm bị che khuất.

Senior Lens

Không dùng mức độ tự tin để thay thế loại bằng chứng. Một stakeholder rất am hiểu vẫn chỉ tạo stakeholder input cho đến khi có bằng chứng phù hợp. Một URL pháp lý chính thức vẫn chỉ chứng minh văn bản tồn tại và trạng thái công bố; việc suy ra requirement ERP cho Nova Foods cần Legal Owner hoặc domain owner xác minh.

Decision phải có đối tượng quyết định. “BA chọn cách làm” chỉ là thao tác phân tích nếu BA không có thẩm quyền quyết định business rule. Artifact IN_REVIEW chứng minh trạng thái xem xét, không chứng minh nội dung đã đúng, đã baseline hoặc đã được phê duyệt.

Quick Reference

Câu hỏi kiểm tra	Nhãn đúng
“Nguồn nào xác nhận điều này?” và có nguồn truy lại được	Verified fact
“Ai đã nêu điều này, trong bối cảnh nào?”	Stakeholder input
“Điều gì đang tạm coi đúng để phân tích tiếp?”	Project assumption
“Giữa các phương án, ai chọn và theo tiêu chí nào?”	Decision
“Điều gì có tác động lớn nhưng chưa đủ bằng chứng?”	Verification-required claim

3. V? tr? trong Lifecycle

Core

Lifecycle là chuỗi giai đoạn biến một nhu cầu chưa rõ thành thay đổi có thể vận hành. Mỗi giai đoạn cần entry gate (cổng vào): bằng chứng tối thiểu để bắt đầu; và exit gate (cổng ra): bằng chứng tối thiểu để chuyển tiếp. Gate không phải phê duyệt ngầm định. Với Nova Foods Trading & Manufacturing, đây là case mô phỏng giáo dục, dữ liệu tổng hợp, trạng thái corpus IN_REVIEW, version v0.9.0, ngày 2026-08-07.

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

flowchart TB
    E["Nguồn khởi phát bên ngoài<br/>Vấn đề hoặc cơ hội được ghi nhận"]
    G0{"G0 — Entry Discovery<br/>Nguồn đã phân loại"}
    B0["Phân loại hoặc bổ sung nguồn"]
    D["Discovery<br/>Khám phá"]

    G1{"G1 — Entry Analysis<br/>Need statement còn truy vết được<br/>Phạm vi phân tích đủ rõ"}
    B1["Bổ sung nguồn, need statement<br/>hoặc phạm vi phân tích"]
    A["Analysis<br/>Phân tích"]

    G2{"G2 — Entry Delivery<br/>Requirement trong phạm vi<br/>Acceptance criteria dùng được làm test basis"}
    B2["Bổ sung hoặc xác minh<br/>requirement và acceptance criteria"]
    DE["Delivery<br/>Xây dựng"]

    G3{"G3 — Entry Testing<br/>Increment, test basis và dữ liệu kiểm thử tổng hợp sẵn có"}
    B3["Hoàn thiện increment, test basis<br/>hoặc dữ liệu kiểm thử tổng hợp"]
    T["Testing<br/>Kiểm thử"]

    G4{"G4 — Exit Testing<br/>Kết quả kiểm thử, defect còn mở<br/>và rủi ro release đã ghi nhận"}
    S{"Trạng thái acceptance criteria"}
    G5{"G5 — Release decision gate<br/>Quyết định Go hoặc No-go<br/>theo thẩm quyền"}
    R["Release<br/>Phát hành"]
    P["Trạng thái triển khai<br/>Phiên bản đã triển khai theo kế hoạch<br/>Trách nhiệm, phạm vi và điểm theo dõi đã xác định"]
    O["Operations<br/>Vận hành"]
    C{"Phân loại bằng chứng vận hành"}

    E --> G0
    G0 -->|Đủ điều kiện| D
    G0 -->|Chưa đủ| B0
    B0 --> G0

    D -->|Need statement nêu hiện trạng, tác động, đối tượng bị ảnh hưởng và khoảng trống bằng chứng| G1
    G1 -->|Đủ điều kiện| A
    G1 -->|Chưa đủ| B1
    B1 --> D

    A -->|Business needs, objectives, scope boundary, rules, requirement và acceptance criteria truy vết được| G2
    G2 -->|Đủ điều kiện| DE
    G2 -->|Chưa đủ| B2
    B2 --> A

    DE -->|Increment sẵn sàng kiểm thử; chênh lệch đã ghi nhận| G3
    G3 -->|Đủ điều kiện| T
    G3 -->|Chưa đủ| B3
    B3 --> DE

    T -->|Ghi nhận evidence| G4
    G4 -->|Đối chiếu acceptance criteria| S
    S -->|Đạt| G5
    S -->|Chưa đạt| G5

    G5 -->|Go: tiêu chí đạt, hoặc ngoại lệ và rủi ro được chấp nhận và ghi nhận| R
    G5 -->|No-go: defect thuộc increment cần sửa| DE
    G5 -->|No-go: cần tái xác nhận requirement hoặc acceptance criteria| G2
    G5 -->|No-go: sai need, scope boundary hoặc rule| G1

    R -->|Triển khai theo kế hoạch| P
    P --> O
    O -->|Sự cố, phản hồi hoặc kết quả đo lường| C
    C -->|Need mới cần Discovery| G0
    C -->|Cần Analysis; need statement còn truy vết được và phạm vi đủ rõ| G1
    C -->|Vận hành thường ngày| O

Giai đoạn	Entry gate: phải có trước khi bắt đầu	Exit gate: phải có để chuyển tiếp	Lý do
Discovery	Vấn đề hoặc cơ hội được ghi nhận; nguồn được phân loại như stakeholder input, verified fact, project assumption hoặc verification-required claim	Need statement nêu hiện trạng, tác động, đối tượng bị ảnh hưởng và khoảng trống bằng chứng	Không phân loại nguồn, team dễ biến ý kiến thành requirement
Analysis	Need statement còn truy vết được về nguồn; phạm vi phân tích đủ rõ	Business needs, objectives, scope boundary, rule cần xác minh, requirement và acceptance criteria có liên kết	Delivery cần biết phải làm gì, không chỉ biết có vấn đề
Delivery	Requirement trong phạm vi; acceptance criteria dùng được làm test basis, tức cơ sở để thiết kế kiểm thử	Increment có thể kiểm thử; chênh lệch so với requirement được ghi nhận	Code hoặc cấu hình không có tiêu chí kiểm tra không chứng minh đáp ứng nhu cầu
Testing	Increment được bàn giao; test basis và dữ liệu kiểm thử tổng hợp sẵn có	Kết quả kiểm thử, defect còn mở và mức rủi ro release được ghi nhận; tiêu chí đạt hoặc chưa đạt được đối chiếu rõ với acceptance criteria	“Đã test” không đủ; cần bằng chứng so với tiêu chí đã xác định
Release	Evidence kiểm thử, defect còn mở, mức rủi ro và quyết định release được ghi nhận theo thẩm quyền phù hợp	Phiên bản thay đổi đã được triển khai theo kế hoạch; người chịu trách nhiệm, phạm vi triển khai và điểm theo dõi sau release được xác định	Triển khai không tự chứng minh thay đổi tạo giá trị
Operations	Thay đổi đang hoạt động; chỉ số hoặc phản hồi cần theo dõi, người theo dõi và cách ghi nhận đã xác định	Sự cố, phản hồi hoặc kết quả đo lường được phân loại thành vận hành thường ngày hay need mới; bằng chứng được chuyển về Discovery hoặc Analysis khi cần	Vận hành cung cấp bằng chứng thực tế cho vòng Discovery kế tiếp

Applied

Trường	Nội dung case Nova Foods mô phỏng
Facts	Nhân viên kho báo cáo phải đối chiếu thủ công số lô khi chuẩn bị đơn xuất. Đây là stakeholder input, không phải verified fact về tần suất lỗi.
Current Behavior	ERP mô phỏng hiển thị tồn kho theo mặt hàng; thông tin lô cần tra cứu ở màn hình khác.
Underlying Need	Cần xác định liệu người dùng cần xem lô ngay khi chuẩn bị xuất, hay cần quy tắc chặn xuất theo lô. Hai nhu cầu khác nhau vì một nhu cầu là hiển thị, nhu cầu kia là kiểm soát nghiệp vụ.
Options	Phương án 1: bổ sung hiển thị lô. Phương án 2: chặn thao tác xuất khi chưa chọn lô. Phương án 3: giữ quy trình hiện tại và đo dữ liệu lỗi trước.
Decision Criteria	Bằng chứng lỗi thực tế, tác động thời gian xử lý, khả năng truy vết lô, rủi ro vận hành và xác minh cần thiết từ domain owner.
Decision	Chưa chọn phương án. Analysis chỉ được vào khi need statement phân biệt rõ nhu cầu hiển thị với quy tắc chặn xuất.
Authority	BA ghi nhận, phân loại và truy vết. Quyết định rule vận hành không thuộc thẩm quyền BA; cần role có thẩm quyền nghiệp vụ xác nhận.
Artifact	Need statement và liên kết nguồn trong artifact kiểm soát; nếu hình thành rule, tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md; giữ IN_REVIEW, không gọi baseline hay approved.
Consequence if Wrong	Nếu chuyển thẳng từ báo cáo người dùng sang Delivery, team có thể xây chặn xuất dù vấn đề thật chỉ là màn hình khó dùng. Testing khi đó có thể pass acceptance criteria sai.

Senior Lens

Gate tốt đo chất lượng bằng chứng, không đo số lượng tài liệu. Discovery được phép chứa uncertainty, nhưng uncertainty phải có nhãn. Analysis không được đóng gap bằng suy đoán. Delivery không được tự diễn giải business rule còn Verification required. Testing không được xác nhận value business chỉ vì chức năng chạy. Operations không được biến mọi phản hồi thành defect; phản hồi có thể là need mới và phải quay lại Discovery.

Chuỗi lifecycle giữ traceability như sau: nguồn tạo need statement; need statement giới hạn analysis; requirement và acceptance criteria tạo test basis; test evidence hỗ trợ release decision; dữ liệu vận hành kiểm tra giả định ban đầu. Mắt xích thiếu làm team không trả lời được “vì sao xây”, “test theo cái gì”, hoặc “release dựa trên bằng chứng nào”.

Quick Reference

Gate	Câu hỏi chặn
Discovery vào Analysis	Need đã phân biệt fact, input, assumption và claim cần xác minh chưa?
Analysis vào Delivery	Scope, requirement và acceptance criteria đã đủ để xây và test chưa?
Delivery vào Testing	Increment có đối chiếu được với acceptance criteria chưa?
Testing vào Release	Kết quả test, defect, tiêu chí đạt/chưa đạt và rủi ro còn lại đã được ghi nhận chưa?
Release vào Operations	Phiên bản, phạm vi triển khai, owner theo dõi và điểm theo dõi sau triển khai đã xác định chưa?
Operations vào Discovery	Phản hồi là sự cố vận hành, hay bằng chứng của need mới?

Core

Owner là vai trò chịu trách nhiệm xử lý hoặc quyết định trong ranh giới được giao; không phải người có chức danh cao nhất. Handoff là điểm bàn giao có ghi nhận: đầu ra, nguồn, người nhận, điều kiện đủ và vấn đề mở. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, BA giữ truy vết và làm rõ nhu cầu; BA không tự xác nhận quy tắc kế toán, pháp lý, bảo mật, kiến trúc hay vận hành.

Hướng bàn giao	Owner gửi	Artifact bàn giao	Owner nhận	Quyền người gửi	Điểm escalation
Upstream	Business Owner	Mục tiêu, vấn đề, ưu tiên nghiệp vụ	BA	Nêu nhu cầu và ưu tiên nghiệp vụ	Mục tiêu mâu thuẫn giữa Sales, Kho, Sản xuất
Upstream	Domain Owner	Quy trình hiện tại, ngoại lệ, thuật ngữ	BA	Xác nhận thực tế vận hành mô phỏng	Quy tắc liên quan an toàn thực phẩm cần Legal Owner và domain verification
BA sang kỹ thuật	BA	Business need, phạm vi, giả định, câu hỏi mở, traceability	Architect, Delivery Lead	Diễn đạt nhu cầu, không chọn kiến trúc	Giải pháp ảnh hưởng tích hợp, dữ liệu cá nhân, phân quyền
BA sang kiểm thử	BA	Rule, acceptance criteria, ví dụ dữ liệu tổng hợp	QA Lead	Cung cấp test basis, không tự cấp kết quả test	Requirement mơ hồ hoặc thiếu tiêu chí chấp nhận
Downstream	QA Lead	Defect, test evidence, rủi ro phát hành	Business Owner, Delivery Lead, BA	Đánh giá theo test basis	Defect làm sai giá trị tiền tệ VND, tồn kho, truy xuất lô
Downstream	Operations Owner	Sự cố, phản hồi vận hành, yêu cầu thay đổi	BA, Business Owner	Báo tác động vận hành	Sự cố có dữ liệu cá nhân, an ninh, kế toán, thu hồi sản phẩm

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

flowchart TB
    NOTE["Nhãn mũi tên tóm tắt artifact.<br/>Handoff đầy đủ ghi: đầu ra, nguồn, người nhận, điều kiện đủ, vấn đề mở."]
    NOTE -.chú thích.-> BA

    BO[Business Owner] -->|Mục tiêu, vấn đề, ưu tiên nghiệp vụ| BA[Business Analyst]
    BO --- BBO["Quyền: nêu nhu cầu<br/>và ưu tiên nghiệp vụ"]

    DO[Domain Owner] -->|Quy trình hiện tại, ngoại lệ, thuật ngữ| BA
    DO --- DNOTE["Quyền: xác nhận thực tế vận hành mô phỏng"]

    BA -->|Business need, phạm vi, giả định,<br/>câu hỏi mở, traceability| ARCH[Architect]
    BA -->|Business need, phạm vi, giả định,<br/>câu hỏi mở, traceability| DL[Delivery Lead]
    BA --- BTECH["Quyền: diễn đạt nhu cầu,<br/>không chọn kiến trúc"]

    BA -->|Rule, acceptance criteria,<br/>ví dụ dữ liệu tổng hợp| QA[QA Lead]
    BA --- BQA["Quyền: cung cấp test basis,<br/>không tự cấp kết quả test"]
    QA --- QNOTE["Quyền: đánh giá theo test basis"]

    QA -->|Defect, test evidence,<br/>rủi ro phát hành| BO
    QA -->|Defect, test evidence,<br/>rủi ro phát hành| DL
    QA -->|Defect, test evidence,<br/>rủi ro phát hành| BA

    OPS[Operations Owner] -->|Sự cố, phản hồi vận hành,<br/>yêu cầu thay đổi| BA
    OPS -->|Sự cố, phản hồi vận hành,<br/>yêu cầu thay đổi| BO
    OPS --- ONOTE["Quyền: báo tác động vận hành"]

    BO -.Xung đột mục tiêu Sales, Kho, Sản xuất.-> EBO[Escalation: Owner phù hợp<br/>có thẩm quyền phân xử]
    DO -.An toàn thực phẩm.-> EFOOD[Legal Owner<br/>+ Domain Owner verification]
    BA -.Giải pháp ảnh hưởng tích hợp,<br/>dữ liệu cá nhân, phân quyền.-> ETECH[Escalation: Architect<br/>hoặc Delivery Lead]
    QA -.Requirement mơ hồ hoặc thiếu<br/>acceptance criteria.-> BA
    QA -.Sai lệch VND, tồn kho,<br/>truy xuất lô.-> EQ[Escalation: Business Owner,<br/>Delivery Lead, BA]
    OPS -.Dữ liệu cá nhân, an ninh,<br/>kế toán, thu hồi sản phẩm.-> EOPS[Escalation: Owner phù hợp]

Applied

Facts: Nova Foods mô phỏng cần hiển thị trạng thái lô hàng khi Sales tạo đơn bán. Dữ liệu lô, đơn và giá trị VND đều là dữ liệu tổng hợp.

Current Behavior: Sales hỏi Kho bằng tin nhắn trước khi cam kết ngày giao. Không có artifact ghi ai xác nhận trạng thái lô hay ngoại lệ giữ hàng.

Underlying Need: Cần xác định người sở hữu quyết định “lô có thể cam kết bán”, người nhận bàn giao và người xử lý khi trạng thái lô ảnh hưởng quy tắc an toàn thực phẩm.

Options: BA tự ghi quy tắc; Kho xác nhận mọi trường hợp; Business Owner quyết định chính sách, Kho xác nhận trạng thái vận hành, Legal Owner hoặc domain authority xác minh nội dung có yếu tố pháp lý/an toàn thực phẩm.

Decision Criteria: Quyết định phải thuộc đúng chuyên môn; có bằng chứng nguồn; không biến giả định học liệu thành quy định vận hành; giữ traceability đến artifact canonical.

Decision: Business Owner sở hữu chính sách cam kết bán. Kho sở hữu xác nhận trạng thái lô hiện tại. BA ghi nhu cầu, giả định và điểm chưa xác minh. Nội dung liên quan truy xuất hoặc thu hồi thực phẩm mang nhãn Verification required cho Legal Owner và Domain Owner.

Authority: BA không được tuyên bố lô đạt điều kiện pháp lý hay an toàn. Architect không được thay Business Owner chọn chính sách bán hàng. QA không được thay Domain Owner xác nhận quy tắc nghiệp vụ.

Artifact: Ghi liên kết đến CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY trong các artifact canonical tại /01-curriculum/; trạng thái hiện hành IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Sales có thể hứa giao hàng từ lô không sẵn sàng; QA thiếu test basis; đội kỹ thuật biến giả định thành cấu hình ERP; rủi ro nghiệp vụ không đến đúng owner.

Senior Lens

Escalation không phải chuyển trách nhiệm. BA phải gửi gói vấn đề gồm: quyết định cần có, các lựa chọn, bằng chứng nguồn, tác động, owner đề xuất và phần vượt thẩm quyền. Cơ sở: TRACEABILITY_ID_REGISTRY yêu cầu escalation khi đề xuất chồng thẩm quyền hoặc nguồn canonical mâu thuẫn; vì vậy không được dùng ý kiến một vai trò để thay kết luận Legal, Accounting, Security, Architect hay Business Owner.

Không gọi nội dung là “đã phê duyệt” chỉ vì đã bàn giao. IN_REVIEW nghĩa là đang xem xét, không phải BASELINED, production-ready hay approved. Handoff chỉ hoàn tất về quản trị khi người nhận xác nhận đã nhận artifact và vấn đề mở vẫn được ghi rõ; việc này không tạo approval ngầm định.

Quick Reference

Tình huống	BA làm	BA không làm	Escalate đến
Rule mâu thuẫn giữa bộ phận	Ghi hai cách hiểu, bằng chứng, tác động	Tự chọn rule	Business Owner
Quyết định ảnh hưởng API hoặc dữ liệu	Nêu nhu cầu và ràng buộc	Chọn kiến trúc thay Architect	Architect, Security Owner
Yêu cầu liên quan kế toán, thuế	Gắn Verification required	Diễn giải nghĩa vụ	Accounting Owner, Legal Owner
Yêu cầu truy xuất hoặc an toàn thực phẩm	Giữ nguồn và giả định tách biệt	Khẳng định tuân thủ	Domain Owner, Legal Owner
Defect làm sai rule	Liên kết defect với requirement	Tự đóng defect	QA Lead, Business Owner

Core

Bản đồ vòng đời đặt Business Needs, Objectives and Scope vào chuỗi ERP Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp. Nó cho người mới thấy nhu cầu nghiệp vụ không dừng ở tài liệu BA: nhu cầu đi qua phân tích, xây dựng, kiểm thử, phát hành rồi được quan sát trong vận hành. Sơ đồ chỉ mô tả thứ tự và điểm phản hồi; không tự tạo yêu cầu, baseline, phê duyệt hay quyền triển khai.

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

flowchart LR
    D[Discovery<br/>Nhận diện vấn đề, cơ hội, nhu cầu]
    A[Analysis<br/>Làm rõ nhu cầu, mục tiêu, phạm vi]
    DE[Delivery<br/>Xây dựng thay đổi đã được chọn]
    T[Testing<br/>Kiểm tra thay đổi so với test basis]
    R[Release<br/>Đưa thay đổi qua quy trình phát hành]
    O[Operations<br/>Vận hành, đo kết quả, ghi nhận vấn đề]

    D --> A
    A --> DE
    DE --> T
    T --> R
    R --> O
    O --> D
    T --> A

Ký hiệu	Ý nghĩa học liệu	Ranh giới
D → A	Vấn đề hoặc cơ hội được chuyển thành nhu cầu cần phân tích.	Không suy ra solution đã chọn.
A → DE	Nội dung đã được làm rõ trở thành đầu vào để xây dựng.	Không đồng nghĩa được phê duyệt hay baseline.
DE → T	Thay đổi được tạo cần được kiểm tra.	Không khẳng định đạt chất lượng.
T → R	Kết quả kiểm tra là thông tin cho quyết định phát hành.	Không tự cấp quyền phát hành.
R → O	Thay đổi được vận hành và theo dõi trong bối cảnh mô phỏng.	Không phải production.
O → D, T → A	Kết quả vận hành hoặc lỗi kiểm thử có thể làm lộ nhu cầu mới hay cần làm rõ.	Phản hồi không được sửa im lặng nội dung kiểm soát.

Applied

Facts: Nova Foods mô phỏng phát hiện nhân viên bán hàng phải đối chiếu thủ công tồn kho trước khi xác nhận đơn. Current Behavior: thông tin tồn kho được hỏi qua trao đổi nội bộ, nên thời gian phản hồi không ổn định. Underlying Need: giảm thời gian xác nhận đơn bằng thông tin tồn kho phù hợp mục đích nghiệp vụ. Options: giữ thao tác thủ công; hiển thị tồn kho trong ERP; tích hợp nguồn tồn kho khác. Decision Criteria: dữ liệu cần dùng, độ tin cậy, tác động quy trình, rủi ro và khả năng kiểm thử. Decision: sơ đồ đặt việc so sánh các lựa chọn tại Analysis, không chọn sẵn giải pháp. Authority: sơ đồ không cấp thẩm quyền quyết định cho bất kỳ vai trò nào. Artifact: nội dung được truy vết trong /02-handbook/05-business-needs-objectives-and-scope.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Consequence if Wrong: chọn giải pháp trước khi hiểu nhu cầu có thể làm Delivery xây sai thay đổi, Testing kiểm sai cơ sở, Operations tiếp tục không giải quyết vấn đề.

Senior Lens

Sơ đồ là công cụ định hướng, không phải BPMN. BPMN là ký pháp quy trình chuẩn của OMG; Mermaid flowchart ở đây chỉ ưu tiên quét nhanh chuỗi học liệu. Bằng chứng cho giới hạn này là sơ đồ không có pool, lane, event hay quy tắc token của BPMN. Vì vậy không được dùng nó để tuyên bố trách nhiệm vận hành, cam kết thời gian, kiểm soát pháp lý, cấu hình ERP hay tuân thủ thực tế.

Quick Reference

Câu hỏi khi đọc sơ đồ	Cách trả lời đúng
Nhu cầu xuất hiện ở đâu?	Bắt đầu được nhận diện tại Discovery, rồi được làm rõ tại Analysis.
Có phải đi thẳng một chiều?	Không. Testing và Operations có thể trả thông tin về Analysis hoặc Discovery.
Mũi tên có phải phê duyệt?	Không. Mũi tên chỉ là luồng thông tin hoặc chuyển pha học liệu.
Dữ liệu Nova Foods có thật không?	Không. Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp.

4. Input c?n thi?t

Core

Input là thông tin BA nhận trước khi xác định business need, objective và scope. Người mới không cần biết ERP là gì: ERP là phần mềm tập hợp dữ liệu và thao tác của nhiều bộ phận như bán hàng, kho, mua hàng, sản xuất và kế toán. BA không bắt đầu bằng màn hình hay chức năng. BA bắt đầu bằng bằng chứng cho thấy vấn đề, mục tiêu hoặc ranh giới thay đổi có tồn tại.

Bốn nhóm cần kiểm kê:

Nhóm	Cần có	Vì sao cần
Kiến thức tiền đề	Khái niệm stakeholder, quy trình, dữ liệu, business rule, scope	Giúp đọc đúng bằng chứng trước khi suy luận nhu cầu.
Bằng chứng	Quan sát quy trình, số liệu tổng hợp, ví dụ giao dịch mô phỏng, vấn đề được ghi nhận	Nối nhận định BA với dữ kiện kiểm tra được.
Source artifact	Tệp kiểm soát, catalog, registry, nguồn chuẩn hoặc nguồn pháp lý	Xác định nơi thông tin xuất phát; bản sao không thay thế nguồn canonical.
Canonical ID	Định danh ổn định, duy nhất, giữ nguyên chuỗi	Giữ liên kết giữa nhu cầu, quy tắc, dữ liệu, nguồn và artifact khi nội dung đổi phiên bản.

Canonical ID không phải tên gọi tự do. Ví dụ TRACEABILITY_ID_REGISTRY luôn chỉ registry định danh tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Suy luận: vì artifact này tự công bố Artifact ID và đường dẫn kiểm soát, BA dùng đúng chuỗi đó thay vì viết “registry ID” hoặc tạo biến thể tiếng Việt. Việc giữ nguyên ID ngăn một liên kết trỏ nhầm sang artifact khác cùng chủ đề.

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

flowchart TB
    A[Kiến thức tiền đề]
    B[Bằng chứng]
    C[Source artifact]
    D[Canonical ID]
    E[Xác định business need, objective và scope]
    F[Liên kết nhu cầu, quy tắc, dữ liệu, nguồn và artifact]

    A --> E
    B --> E
    C --> E
    C --> D
    D --> F
    E --> F

Sơ đồ là Mermaid flowchart, không phải BPMN. Nó mô tả quan hệ thông tin trong học liệu, không phân công vận hành Nova Foods.

Applied

Facts: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Bằng chứng: metadata của các artifact kiểm soát nêu rõ các giá trị này.

Current Behavior: Người học có thể thấy câu “cần cải thiện kiểm soát tồn kho” nhưng chưa biết câu này dựa trên tài liệu nào. Khi không có source artifact và canonical ID, câu đó chỉ là nhận định chưa truy vết được.

Underlying Need: Cần lập inventory đầu vào trước khi viết nhu cầu, mục tiêu hoặc scope. Lý do: một nhu cầu chỉ kiểm tra lại được khi người đọc lần ngược tới bằng chứng và artifact nguồn.

Options: Dùng ghi chú tự do không ID; dùng tên tệp không kiểm soát; dùng canonical artifact ID cùng đường dẫn kiểm soát.

Decision Criteria: Liên kết phải ổn định khi tiêu đề đổi; người đọc phải tìm được nguồn; ID không được tạo ra thẩm quyền hoặc approval; dữ liệu phải còn là mô phỏng.

Decision: Dùng ID canonical và đường dẫn canonical đã có trong corpus. Không tạo ID mới trong section này.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và liên kết quản trị. Vai trò này không xác nhận requirement Nova Foods, không thiết lập baseline, không ghi nhận approval, không thay thế Business Owner, Legal Owner, Accounting Owner, Security hoặc Architect.

Artifact: /02-handbook/05-business-needs-objectives-and-scope.md tham chiếu các nguồn sau.

Mục cần biết	Evidence hoặc source artifact	Canonical ID giữ nguyên	Suy luận được phép
Cấu trúc chapter và tên tệp	/01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST	Chapter thuộc corpus có kiểm soát. Không suy ra chapter đã được phê duyệt.
ID và quy tắc truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	TRACEABILITY_ID_REGISTRY	ID phải ổn định và truy vết được. Không tự tạo biến thể ID.
Quy tắc nghiệp vụ canonical	/01-curriculum/CANONICAL_BUSINESS_RULES.md	CANONICAL_BUSINESS_RULES	Rule chỉ là nguồn tham chiếu khi đã tồn tại trong catalog. Không suy ra rule là quyết định vận hành thực.
Định nghĩa dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	CANONICAL_DATA_DICTIONARY	Thuật ngữ dữ liệu phải bám dictionary. Không suy ra schema triển khai.
Nguồn BA chuẩn	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	BABOK Guide	Dùng thuật ngữ và phạm vi kiến thức BA. Không bịa số trang hay điều khoản.
Nguồn yêu cầu chuẩn	https://www.iso.org/standard/72089.html	ISO/IEC/IEEE 29148:2018	Dùng abstract và trạng thái thư mục. Điều khoản chi tiết cần văn bản được cấp phép.

Consequence if Wrong: Nếu BA dùng tên tự đặt thay canonical ID, truy vết có thể đứt; người review không xác định được nguồn; scope có thể dựa trên giả định; Testing và Delivery nhận sai test basis.

Senior Lens

Phân biệt ba thứ dễ bị lẫn: evidence, inference và decision. Evidence là dữ kiện nguồn, như metadata ghi IN_REVIEW. Inference là kết luận có cầu nối, như “chưa được baseline” vì metadata nói IN_REVIEW không đồng nghĩa BASELINED. Decision là lựa chọn cần thẩm quyền, như chọn thay đổi quy trình tồn kho. BA được ghi evidence và inference có lý do; BA không biến inference thành decision.

Không dùng canonical ID để làm nội dung có vẻ đáng tin hơn thực tế. ID chỉ định danh. Ví dụ CANONICAL_BUSINESS_RULES xác định đúng catalog; nó không chứng minh từng rule trong catalog hợp pháp, được phê duyệt hoặc sẵn sàng production.

Quick Reference

Câu hỏi	Trả lời
Chưa biết ERP có bắt đầu BA được không?	Có. Bắt đầu từ vấn đề, người liên quan, dữ liệu, quy trình và bằng chứng.
Source artifact là gì?	Tệp hoặc nguồn chuẩn nơi thông tin được kiểm soát hoặc công bố.
Canonical ID dùng làm gì?	Giữ một định danh ổn định để liên kết và truy vết.
Nova Foods có phải doanh nghiệp thật không?	Không. Đây là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.
IN_REVIEW có phải approval không?	Không. IN_REVIEW không phải APPROVED hoặc BASELINED.

Core

Chất lượng input là mức đủ tin cậy để BA dùng nguồn làm căn cứ phân tích. Input không phải “đúng vì có tệp”; phải rõ nguồn gốc, chủ sở hữu, ngày hiệu lực, phạm vi và trạng thái. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; IN_REVIEW và v0.9.0 không phải phê duyệt hay baseline.

Kiểm tra	Điều kiện đạt	Bằng chứng cần có	Không đạt
Định danh	Giữ nguyên Artifact ID, tên tệp, URL canonical	TRACEABILITY_ID_REGISTRY, metadata tệp	Không tự đổi tên, không tạo ID thay thế
Nguồn gốc	Biết ai phát hành và loại nguồn	Issuer, URL chính thức, phân loại nguồn	Gắn Verification required
Phạm vi	Nội dung trả lời đúng câu hỏi đang phân tích	Safe use boundary, phạm vi artifact	Không suy diễn ngoài phạm vi
Tính mới	Ngày kiểm tra còn phù hợp quyết định	Ngày 2026-08-07, phiên bản, trạng thái	Kiểm tra lại trước khi dùng
Thẩm quyền	Owner nguồn có quyền xác nhận loại nội dung đó	Legal Owner, Accounting Owner, Business Owner, Architect, QA	Escalate đúng vai trò
Nhất quán	Không mâu thuẫn nguồn canonical khác	So sánh ID, status, version, rule	Dừng phân tích phần mâu thuẫn

Phân loại nguồn quyết định cách dùng. Nguồn primary là nguồn do tổ chức có thẩm quyền phát hành, như URL ISO, OMG, W3C, OWASP hoặc văn bản Chính phủ Việt Nam trong source seed. Nguồn controlled internal là artifact corpus có metadata kiểm soát, như CHAPTER_MANIFEST và CANONICAL_BUSINESS_RULES; chúng xác định cấu trúc học liệu, không xác nhận vận hành Nova Foods. Nguồn simulated case là dữ liệu tổng hợp của Nova Foods; chỉ dùng minh họa. Nguồn assumption là giả định dự án; không được viết thành fact. Nguồn Verification required là điểm cần vai trò có thẩm quyền xác minh trước khi thành requirement.

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

flowchart TB
    A[Nhận input] --> B{Artifact ID, tên tệp và URL canonical giữ nguyên, khớp registry/metadata?}
    B -- Không --> X[STOP: không đổi định danh; chưa dùng làm căn cứ]
    B -- Có --> C{Biết issuer và đã phân loại nguồn?}
    C -- Không --> Y[Verification required: chờ xác minh; không dùng làm requirement/evidence]
    C -- Có --> D{Đúng safe use boundary?}
    D -- Không --> W[STOP: ngoài phạm vi; không suy diễn]
    D -- Có --> E{Ngày kiểm tra, version và status còn phù hợp?}
    E -- Không --> V[Kiểm tra lại trước khi dùng; không dùng làm requirement/evidence]
    E -- Có --> F{Owner có thẩm quyền xác nhận nội dung?}
    F -- Không --> U[Escalate đúng owner; chờ xác minh; không dùng làm requirement/evidence]
    F -- Có --> G{Mâu thuẫn nguồn canonical khác?}
    G -- Có --> T[STOP: giữ traceability; không suy diễn]
    G -- Không --> H{Loại nguồn?}
    H -- Primary --> I[Dùng làm evidence trong phạm vi đã xác minh]
    H -- Controlled internal --> J[Dùng xác định cấu trúc học liệu; không xác nhận vận hành Nova Foods]
    H -- Simulated case --> K[Chỉ dùng minh họa; không xác nhận vận hành Nova Foods]
    H -- Assumption --> L[Ghi là assumption; không viết thành fact]
    H -- Verification required --> M[Chờ xác minh; không dùng làm requirement/evidence]

Applied

Trường	Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	/01-curriculum/CHAPTER_MANIFEST.md có Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07; CANONICAL_BUSINESS_RULES cũng IN_REVIEW.
Current Behavior	BA dùng metadata này để biết artifact nào kiểm soát cấu trúc và rule catalog.
Underlying Need	Tránh gọi rule hay chapter plan là requirement đã phê duyệt.
Options	Dùng như fact vận hành; dùng như nguồn controlled internal; dừng chờ xác minh.
Decision Criteria	Có approval reference, baseline reference, quyền quyết định nghiệp vụ hay không.
Decision	Dùng như nguồn controlled internal; không dùng làm xác nhận rule vận hành. Lý do: cả hai artifact nêu rõ chưa baseline, chưa approval.
Authority	Principal IT Business Analyst / Technical Curriculum Author giữ metadata; Business Owner xác nhận nghiệp vụ; Legal, Accounting, Security hoặc Architect xác nhận phần thuộc thẩm quyền họ.
Artifact	CHAPTER_MANIFEST; CANONICAL_BUSINESS_RULES; /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Consequence if Wrong	Requirement giả định bị đưa sang thiết kế, test hoặc đào tạo như quyết định thật; traceability sai và escalation muộn.

Senior Lens

Độ mới không có một ngưỡng chung. Metadata corpus phải khớp v0.9.0 và 2026-08-07. URL pháp lý phải kiểm tra phiên bản hiện hành trước khi suy ra yêu cầu hệ thống, vì source seed nêu rõ một số nội dung cần legal-owner verification hoặc cần kiểm tra sửa đổi sau này. Tài liệu không ngày, không owner, không URL canonical, hoặc mâu thuẫn trạng thái là evidence yếu; BA ghi nhận nó để truy vết nhưng không dùng nó chốt scope, objective, rule hay compliance.

Stop condition: dừng phần phân tích liên quan khi thiếu ID canonical; nguồn mâu thuẫn; nguồn pháp lý bị diễn đạt thành nghĩa vụ nhưng chưa có xác minh Legal Owner; hoặc quyết định vượt quyền Owner artifact. Khi dừng, ghi nguồn, điểm mâu thuẫn, owner cần xử lý và nhãn Verification required; không lấp khoảng trống bằng giả định ngầm.

Quick Reference

Loại input	Cách dùng	Freshness	Owner
Primary source	Căn cứ thuật ngữ, chuẩn, trạng thái công bố trong safe use boundary	Kiểm tra URL ngày 2026-08-07; kiểm tra lại trước quyết định production	Tổ chức phát hành; chuyên gia thẩm quyền diễn giải
Controlled internal	Căn cứ ID, filename, trạng thái, cấu trúc corpus	Phải khớp IN_REVIEW, v0.9.0	Owner ghi trong metadata
Simulated case	Minh họa Nova Foods, dữ liệu tổng hợp	Chỉ hiệu lực trong case học liệu	Curriculum Owner
Assumption	Nêu rõ điều chưa chứng minh	Hết hiệu lực khi có evidence mới	Người đưa giả định, owner xác minh
Verification required	Không chốt quyết định	Mở đến khi owner xác minh	Vai trò chuyên môn phù hợp

Core

Bảng dưới là tập đầu vào hoàn chỉnh cho phạm vi học liệu Nova Foods Trading & Manufacturing mô phỏng. Mọi giá trị Nova Foods là dữ liệu tổng hợp; trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. “Đầu vào chưa xác minh” nghĩa là chưa đủ bằng chứng để biến thành yêu cầu, quy tắc, cam kết pháp lý hay cấu hình ERP.

Nhóm đầu vào	Artifact ID / định danh giữ nguyên	Tệp hoặc URL nguồn	Phân loại nguồn	Giá trị mô phỏng dùng trong case	Trạng thái kiểm tra	Hạng mục chưa xác minh
Quản trị corpus	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Chapter 05 có 12 section; section hiện tại là 04-inputs	Khớp metadata	Không có
Định danh và truy vết	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	Chỉ dùng ID đã đăng ký; không tự tạo ID thay thế	Cần đối chiếu registry đầy đủ	Verification required: ID requirement, process, data field cụ thể chưa được cung cấp trong lô này
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Có catalog quy tắc canonical dự kiến	Có boundary thẩm quyền	Verification required: Không có quy tắc Nova Foods nào được xác nhận cho tồn kho, giá bán, hóa đơn
Dữ liệu logic	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Có kế hoạch từ điển dữ liệu logic canonical	Có artifact identity	Verification required: Thuộc tính mã hàng, lô hàng, hạn dùng chưa được xác nhận
Kiến thức BA	BABOK Guide	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Primary professional source	Dùng thuật ngữ và phạm vi kiến thức BA	URL xác minh ngày 2026-08-07	Nội dung đầy đủ có thể cần quyền truy cập
Chất lượng yêu cầu	ISO/IEC/IEEE 29148	https://www.iso.org/standard/72089.html	Primary standards source	Dùng abstract và trạng thái thư mục của 29148:2018	URL xác minh ngày 2026-08-07	Verification required: Điều khoản chính xác cần licensed text
Ký pháp quy trình	BPMN 2.0.2	https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/	Normative specification source	BPMN là chuẩn cho ký pháp BPMN	URL xác minh ngày 2026-08-07	Không dùng sơ đồ Mermaid để tuyên bố là BPMN
An toàn thực phẩm	Luật An toàn thực phẩm	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Official legal source	Bối cảnh truy xuất và thu hồi thực phẩm	URL xác minh ngày 2026-08-07	Verification required: Legal Owner và domain owner phải xác nhận diễn giải áp dụng
Kế toán	Luật Kế toán	https://vanban.chinhphu.vn/?docid=183198&pageid=27160	Official legal source	Bối cảnh chứng từ và ghi nhận kế toán	URL xác minh ngày 2026-08-07	Verification required: Accounting Owner phải xác nhận mọi yêu cầu nghiệp vụ suy ra
Hóa đơn	Nghị định 123/2020/NĐ-CP	https://vanban.chinhphu.vn/?docid=201365&pageid=27160	Official legal source	Bối cảnh hóa đơn, chứng từ	URL xác minh ngày 2026-08-07	Verification required: Kiểm tra sửa đổi sau văn bản gốc trước production use

Applied

Facts: Nova Foods mô phỏng cần xác định đầu vào trước khi mô tả nhu cầu ERP cho hàng thực phẩm. Bằng chứng hiện có là artifact quản trị corpus và nguồn chuẩn, pháp lý đã liệt kê.

Current Behavior: Người học có thể thấy thuật ngữ “truy xuất lô hàng” rồi suy ra hệ thống phải có mã lô, hạn dùng, luồng thu hồi và hóa đơn điện tử.

Underlying Need: Tách dữ kiện đã có khỏi suy luận. Dữ kiện là có nguồn pháp lý và chuẩn; suy luận là Nova Foods phải áp dụng trường dữ liệu hay quy trình cụ thể.

Options: (1) Viết requirement từ giả định; (2) ghi mọi điểm thiếu là Verification required; (3) bỏ toàn bộ bối cảnh pháp lý.

Decision Criteria: Giữ traceability, không bịa quy tắc, vẫn cho learner thấy ranh giới giữa nguồn và quyết định.

Decision: Chọn phương án 2. Bảng đầu vào ghi nguồn, giá trị mô phỏng, trạng thái kiểm tra và điểm chưa xác minh.

Authority: Principal IT Business Analyst / Technical Curriculum Author quản lý artifact. Legal Owner, Accounting Owner, domain owner xác minh nội dung thuộc thẩm quyền tương ứng.

Artifact: /02-handbook/05-business-needs-objectives-and-scope.md, section 04-inputs, status IN_REVIEW, version v0.9.0.

Consequence if Wrong: Nếu biến nguồn pháp lý thành rule ERP chưa xác minh, requirement có thể sai, vượt thẩm quyền và tạo rủi ro compliance giả.

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

flowchart TB
    M[Principal IT Business Analyst / Technical Curriculum Author<br/>quản lý artifact và trạng thái IN_REVIEW] --> B

    A[Nguồn canonical hoặc nguồn chính thức] --> B[Ghi mọi đầu vào vào bảng:<br/>nguồn<br/>giá trị mô phỏng<br/>trạng thái kiểm tra<br/>điểm chưa xác minh]

    B --> C{Có bằng chứng?}

    C -->|Không| D[Yêu cầu bổ sung bằng chứng]
    D --> E[Cập nhật bảng đầu vào và trạng thái kiểm tra]
    E --> C

    C -->|Có| F{Owner đúng thẩm quyền<br/>đã xác minh?}

    F -->|Có| G[Đầu vào dùng để phân tích]
    F -->|Không| H[Gắn nhãn Verification required]
    H --> I[Không tạo rule hay cấu hình ERP]
    I --> J{Nội dung thuộc thẩm quyền nào?}

    J -->|Pháp lý| K[Legal Owner xác minh]
    J -->|Kế toán| L[Accounting Owner xác minh]
    J -->|Nghiệp vụ khác| N[domain owner xác minh]

    K --> O[Cập nhật bảng đầu vào và trạng thái kiểm tra]
    L --> O
    N --> O
    O --> C

    H -. Nếu vẫn dùng dữ kiện chưa xác minh .-> P[Requirement có thể sai,<br/>vượt thẩm quyền và tạo rủi ro compliance giả]

Senior Lens

“Đầy đủ” không có nghĩa mọi thông tin nghiệp vụ đã biết. Đầy đủ nghĩa là mỗi loại đầu vào cần cho phạm vi hiện tại đều có dòng quản trị: nguồn, phân loại, giá trị dùng được, trạng thái và khoảng trống. Dòng Verification required là dữ liệu quản trị hợp lệ, không phải lỗi cần che giấu.

Không dùng URL nguồn pháp lý để kết luận Nova Foods tuân thủ luật. URL chỉ chứng minh nguồn được xác định tại ngày truy cập 2026-08-07. Cầu nối từ văn bản đến requirement phải do người có thẩm quyền xác minh và được ghi trong artifact kiểm soát.

Quick Reference

Quy tắc	Áp dụng
Giữ nguyên ID canonical	Dùng đúng CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY
Phân biệt nguồn và quyết định	Nguồn cung cấp bằng chứng; Business Owner, Legal Owner, Accounting Owner hoặc domain owner quyết định phần thuộc thẩm quyền
Gắn nhãn khoảng trống	Dùng đúng nhãn Verification required
Không suy diễn production	Nova Foods là mô phỏng giáo dục, dữ liệu tổng hợp, không xác nhận cấu hình ERP hay tuân thủ thực tế

5. Step-by-step BA Activities

Core

BA thực hiện chuỗi hoạt động có kiểm soát để biến đầu vào thành nhu cầu, mục tiêu và phạm vi có thể xem xét. Mỗi bước phải để lại bằng chứng, áp dụng quy tắc quyết định, qua cổng chất lượng và có tuyến escalation khi thiếu thẩm quyền hoặc mâu thuẫn nguồn. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Applied

1. Chuẩn bị phiên phân tích. Actor: BA. Action: mở phạm vi phân tích, kiểm tra trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Object: nguồn từ /00-research/00_SOURCE_MAP.md, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY. Evidence produced: danh sách đầu vào kèm URL hoặc đường dẫn canonical, phân loại nguồn và trạng thái xác minh. Decision rule: chỉ dùng nội dung trong ranh giới safe use của nguồn. Quality gate: mỗi đầu vào có nguồn, ngày truy cập hoặc đường dẫn, owner và nhãn xác minh. Escalation route: nguồn pháp lý, kế toán, thuế, bảo mật hoặc an toàn thực phẩm chưa đủ căn cứ chuyển Legal Owner, Accounting Owner, Security hoặc domain owner; giữ nhãn Verification required.

2. Ghi nhận tình huống hiện tại. Actor: BA cùng business representative. Action: mô tả hành vi hiện tại bằng dữ kiện quan sát được, không diễn giải thành lỗi hay rule. Object: quy trình bán hàng, tồn kho, sản xuất hoặc truy vết mô phỏng Nova Foods. Evidence produced: bảng Facts gồm tác nhân, sự kiện, dữ liệu dùng, kết quả hiện tại và nguồn bằng chứng. Decision rule: một fact phải trả lời được “ai thấy gì, khi nào, từ đâu”. Quality gate: tách fact khỏi ý kiến và giải pháp đề xuất. Escalation route: hai nguồn canonical mâu thuẫn chuyển Principal IT Business Analyst / Technical Curriculum Author để lập gói vấn đề; không tự chọn nguồn thắng.

3. Phân tích nhu cầu gốc. Actor: BA. Action: nối từng fact với tác động nghiệp vụ, nguyên nhân giả định và nhu cầu cần đáp ứng. Object: Current Behavior, Underlying Need, rủi ro phạm vi. Evidence produced: cầu nối suy luận dạng “fact có bằng chứng X; tác động Y; do đó cần xác minh hoặc đáp ứng Z”. Decision rule: nhu cầu mô tả kết quả cần đạt, không khóa sớm vào màn hình, API, bảng DB hay cấu hình ERP. Quality gate: mỗi nhu cầu có ít nhất một fact làm căn cứ; suy luận không có căn cứ bị loại hoặc gắn Verification required. Escalation route: tác động liên quan doanh thu, giá vốn, hóa đơn, dữ liệu cá nhân hoặc truy xuất thực phẩm chuyển đúng owner chuyên môn.

4. Xác định mục tiêu và đo lường. Actor: BA cùng Business Owner. Action: viết mục tiêu theo kết quả, đối tượng chịu tác động, thước đo, mốc thời gian và giới hạn mô phỏng. Object: business objective và chỉ số đo. Evidence produced: mục tiêu có baseline hiện trạng nếu có bằng chứng, target đề xuất, cách đo và owner đo. Decision rule: không ghi target như cam kết nếu chưa có thẩm quyền Business Owner; dùng “đề xuất để xem xét”. Quality gate: mục tiêu không mâu thuẫn fact, không biến yêu cầu pháp lý chưa xác minh thành KPI bắt buộc. Escalation route: Business Owner quyết định ưu tiên nghiệp vụ; BA chỉ ghi nhận quyết định và bằng chứng, không tự xác nhận.

5. Đặt ranh giới phạm vi. Actor: BA cùng Business Owner và Architect khi có ảnh hưởng kỹ thuật. Action: phân loại nội dung thành in-scope, out-of-scope, assumption hoặc Verification required. Object: quy trình, vai trò, dữ liệu, tích hợp, báo cáo và migration mô phỏng. Evidence produced: scope boundary table, mỗi dòng có lý do và dependency. Decision rule: một mục chỉ in-scope khi trực tiếp hỗ trợ nhu cầu và mục tiêu đã có bằng chứng. Quality gate: mọi out-of-scope nêu rõ không xử lý gì; mọi assumption nêu owner xác minh. Escalation route: phạm vi đụng kiến trúc, tích hợp, phân quyền hoặc bảo mật chuyển Architect và Security; BA không quyết định thiết kế.

6. So sánh phương án. Actor: BA điều phối; Business Owner, Architect, QA hoặc owner chuyên môn cung cấp đánh giá thuộc thẩm quyền. Action: lập Options tối thiểu gồm không thay đổi, thay đổi quy trình và thay đổi hệ thống khi phù hợp. Object: phương án đáp ứng nhu cầu. Evidence produced: Decision Criteria gồm giá trị nghiệp vụ, rủi ro, dữ liệu bị ảnh hưởng, khả năng kiểm thử, phụ thuộc và thẩm quyền. Decision rule: không chọn phương án chỉ vì quen thuộc; chọn theo tiêu chí đã công khai và bằng chứng. Quality gate: phương án không vượt safe use của nguồn, không ngụ ý production-ready hoặc compliant. Escalation route: điểm hòa, trade-off lớn hoặc rủi ro pháp lý chuyển owner quyết định tương ứng.

7. Ghi quyết định có kiểm soát. Actor: BA ghi nhận; người có thẩm quyền cung cấp quyết định. Action: cập nhật Decision, Authority, Artifact và Consequence if Wrong. Object: decision record và traceability. Evidence produced: dòng quyết định nêu phương án, lý do, bằng chứng, authority, ngày theo Asia/Ho_Chi_Minh, trạng thái và liên kết artifact canonical. Decision rule: không dùng từ “đã phê duyệt”, “đã baseline” hoặc “đã tuân thủ” nếu artifact không có tham chiếu minh bạch. Quality gate: Authority không phải BA khi quyết định thuộc Business Owner, Legal Owner, Accounting Owner, Architect, Security hoặc QA. Escalation route: thiếu authority giữ trạng thái IN_REVIEW và mở vấn đề cần xác minh.

8. Review và handoff có kiểm soát. Actor: BA bàn giao; reviewer theo vai trò xem xét. Action: kiểm tra tính nhất quán giữa facts, needs, objectives, scope, options và decision record; chuyển artifact sang người tiêu thụ tiếp theo kèm khoảng trống. Object: gói bàn giao gồm scope statement, decision log, assumption log, Verification required log và liên kết traceability. Evidence produced: review record ghi người review, phạm vi review, phát hiện, quyết định xử lý và trạng thái. Decision rule: chỉ handoff nội dung phù hợp thẩm quyền người nhận; handoff không tạo approval hay baseline. Quality gate: không còn ID sai, nguồn không phân loại, suy luận không có cầu nối bằng chứng hoặc requirement pháp lý chưa xác minh bị viết như nghĩa vụ. Escalation route: lỗi traceability chuyển Principal IT Business Analyst / Technical Curriculum Author; lỗi chuyên môn chuyển owner chuyên môn trước khi nội dung được dùng tiếp.

Senior Lens

Không coi workshop là bằng chứng tự đủ. Workshop tạo dữ kiện cần được phân loại: fact quan sát, ý kiến stakeholder, giả định, quyết định hoặc khoảng trống. Senior BA giữ các loại này tách nhau để người review biết phần nào cần xác minh và ai có quyền kết luận.

Handoff tốt không phải gửi tài liệu dài. Handoff tốt giúp người nhận truy được từ quyết định về nhu cầu, từ nhu cầu về fact, từ fact về nguồn, đồng thời thấy rõ phần chưa xác minh. IN_REVIEW là trạng thái làm việc có kiểm soát, không phải approval, baseline hay quyền triển khai.

Quick Reference

Thành phần bắt buộc	Kiểm tra trước handoff
Fact	Có nguồn và mô tả hành vi hiện tại
Underlying Need	Có cầu nối từ fact đến tác động
Objective	Có kết quả, thước đo và owner phù hợp
Scope	Có in-scope, out-of-scope, assumption, Verification required
Decision	Có options, criteria, authority và consequence if wrong
Traceability	Giữ nguyên CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY
Governance	Status IN_REVIEW; version v0.9.0; không suy diễn approval hoặc baseline

Core

Quy trình này biến nhu cầu mơ hồ thành gói phạm vi có thể review và bàn giao có kiểm soát. Mỗi bước phải để lại bằng chứng. Suy luận chỉ hợp lệ khi nối được từ bằng chứng nguồn đến kết luận; ý kiến không có nguồn chỉ là giả định cần xác minh. 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, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị	BA	Xác định mục tiêu phiên làm việc, phạm vi cần làm rõ, vai trò tham gia, nguồn canonical.	Business need draft, stakeholder list, /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Agenda, danh sách nguồn, nhật ký giả định	Chỉ dùng ID, tên tệp, trạng thái từ nguồn canonical; thiếu nguồn thì ghi Verification required.	Agenda nêu mục tiêu, thời gian, người chịu trách nhiệm, đầu vào.	ID hoặc nguồn mâu thuẫn: Principal IT Business Analyst / Technical Curriculum Author.
2. Thu thập sự kiện	BA; Process Owner mô phỏng	Ghi nhận sự kiện quan sát được, số liệu tổng hợp, điểm đau và tác động. Không biến nhận định thành fact.	Current-state evidence	Fact log, nguồn từng fact, bản ghi câu hỏi mở	Fact phải có nguồn, thời điểm, người cung cấp hoặc dữ liệu tổng hợp xác định; không có thì là assumption.	Mỗi fact phân biệt rõ fact, assumption, question.	Sự kiện liên quan kế toán, thuế, pháp lý, an toàn thực phẩm, dữ liệu cá nhân: Accounting Owner, Legal Owner, Compliance Owner hoặc Food-safety Owner.
3. Mô tả hành vi hiện tại	BA; SME mô phỏng	Chuyển fact thành luồng hiện tại: ai làm gì, khi nào, dùng dữ liệu nào, kết quả gì.	Current behavior	Current-state narrative, danh sách ngoại lệ	Mỗi hành vi phải truy ngược ít nhất một fact; ngoại lệ chưa có bằng chứng không được gọi là rule.	Không lẫn hiện trạng với giải pháp ERP mong muốn.	Luồng ảnh hưởng tích hợp hoặc kiến trúc: Solution Architect.
4. Suy ra nhu cầu gốc	BA	Tách triệu chứng khỏi nhu cầu. Nêu cầu nối: fact nào gây hành vi nào, hành vi nào tạo tác động nào, từ đó cần khả năng gì.	Underlying need	Need statement, reasoning bridge	Nhu cầu mô tả kết quả cần đạt, không khóa màn hình, bảng dữ liệu, API hay nhà cung cấp.	Một need trả lời được “vì sao tồn tại?” và không chứa thiết kế sớm.	Tranh chấp ưu tiên hoặc giá trị: Business Owner.
5. Xác định ranh giới	BA; Business Owner mô phỏng	Liệt kê in-scope, out-of-scope, dependency, constraint và câu hỏi chưa quyết.	Scope boundary	Scope statement, dependency log, assumption log	Chỉ đưa vào phạm vi khi hỗ trợ trực tiếp need; phần không chứng minh được liên kết phải ngoài phạm vi hoặc chờ xác minh.	Không có mục nào vừa in-scope vừa out-of-scope; dependency có owner.	Phạm vi chạm production, ngân sách, vận hành thực: Business Owner và Sponsor có thẩm quyền.
6. So sánh lựa chọn	BA; Solution Architect; Business Owner mô phỏng	Ghi các lựa chọn khả thi, lợi ích, chi phí, rủi ro, dependency và tiêu chí chọn.	Options and criteria	Option matrix, risk log	Không chọn theo sở thích. Chọn lựa chọn đạt tiêu chí bắt buộc và có rủi ro chấp nhận được bởi đúng thẩm quyền.	Tiêu chí đo được, nhất quán mục tiêu, không giả định tuân thủ pháp lý.	Bảo mật: Security Owner. Tích hợp: Solution Architect. Pháp lý: Legal Owner.
7. Review và handoff có kiểm soát	BA; reviewers theo thẩm quyền	Đối chiếu gói nhu cầu với bằng chứng, ghi comment, quyết định review và phần còn mở; bàn giao bản IN_REVIEW cho artifact kế tiếp.	Needs-and-scope package	Review log, traceability links, handoff note	Chỉ ghi “được review” khi review log có người, ngày, nhận xét; không gọi là approved hoặc baselined nếu chưa có tham chiếu rõ.	Mỗi need có fact nguồn, scope, owner quyết định, trạng thái xác minh.	Comment chưa giải quyết: trả về actor sở hữu; xung đột thẩm quyền: Principal IT Business Analyst / Technical Curriculum Author điều phối, không tự kết luận chuyên môn.

Applied

Bảng trên áp dụng như khuôn thao tác cho Nova Foods mô phỏng. Khi BA ghi “cần giảm nhập lại dữ liệu”, bằng chứng phải chỉ ra nguồn ghi nhận việc nhập lặp, hành vi hiện tại bị ảnh hưởng và hậu quả đo được bằng dữ liệu tổng hợp. Nếu chỉ có nhận xét của một người tham gia, kết quả đúng là assumption cần xác minh, không phải business need đã xác nhận.

Senior Lens

Quality gate không phải cuộc họp hình thức. Gate chặn suy luận nhảy cóc: fact thiếu nguồn, need chứa sẵn giải pháp, phạm vi không có liên kết với need, hoặc quyết định vượt thẩm quyền. BA duy trì traceability và nêu rõ khoảng trống; Business Owner, Architect, Legal Owner, Accounting Owner, Security Owner, QA hoặc Compliance Owner mới quyết định phần thuộc chuyên môn họ.

Quick Reference

Kiểm tra	Đạt khi
Fact	Có nguồn và phân loại rõ
Need	Nêu kết quả cần đạt, không nêu thiết kế
Scope	Có in-scope, out-of-scope, dependency, constraint
Decision	Có tiêu chí, thẩm quyền, bằng chứng
Handoff	Có review log và trạng thái IN_REVIEW; không ngầm định approval hoặc baseline

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Bảng dưới diễn tả BA thực thi nhu cầu giảm nhập lại dữ liệu đơn bán hàng vào ERP. Đây không xác nhận quy trình, cấu hình, phê duyệt hay tuân thủ thực tế của Nova Foods.

Mục	Nội dung thực thi	Bằng chứng và cầu nối suy luận
Facts	Nhân viên kinh doanh nhập SO-NF-20260807-001 vào biểu mẫu bán hàng mô phỏng; kế toán nhập lại số đơn, khách hàng, số tiền 12.500.000 VND vào ERP mô phỏng. Hai bản ghi có cùng số đơn nhưng khác trường ghi chú.	Nhật ký thao tác tổng hợp cho thấy một giao dịch bị nhập hai lần. Khác biệt ghi chú chứng minh sao chép thủ công không bảo toàn toàn bộ dữ liệu.
Current Behavior	Dữ liệu đi từ biểu mẫu bán hàng sang bảng tính, rồi sang ERP bằng thao tác người dùng.	Có ba điểm chuyển giao và không có kiểm tra tự động giữa nguồn gửi và ERP. Rủi ro sai lệch nằm tại bước sao chép.
Underlying Need	Cần một luồng tiếp nhận đơn có kiểm tra trường bắt buộc, phát hiện trùng số đơn và trả lỗi cho người gửi trước khi tạo đơn ERP.	Không suy ra cần thay ERP. Bằng chứng chỉ chỉ ra lỗi tại nhập lại và thiếu kiểm tra đầu vào.
Options	1. Giữ nhập tay, thêm checklist. 2. Nhập tệp bảng tính có kiểm tra. 3. Tích hợp API giữa biểu mẫu và ERP.	Phương án 1 giảm lỗi phụ thuộc người dùng. Phương án 2 giảm nhập lại nhưng còn tệp trung gian. Phương án 3 loại bỏ nhập lại nếu API ERP hỗ trợ. Khả năng API là Verification required.
Decision Criteria	Giảm bước nhập lại; chặn trùng SalesOrderNumber; lưu lỗi có thể truy vết; không tự suy diễn thay đổi kế toán; có khả năng kiểm thử.	Tiêu chí liên kết trực tiếp với bằng chứng lỗi, phạm vi BA và nhu cầu test basis.
Decision	Ghi nhận phương án 2 làm giả định phạm vi để phân tích tiếp: tệp nhập có kiểm tra trùng trước khi tạo đơn ERP mô phỏng. Không quyết định kiến trúc production.	Phương án 2 đáp ứng lỗi đã thấy mà chưa đòi hỏi xác nhận API. Đây là quyết định học liệu IN_REVIEW, không phải baseline.
Authority	Business Owner xác nhận giá trị nghiệp vụ; Architect xác nhận cách tích hợp; Accounting Owner xác nhận ảnh hưởng ghi nhận; QA xác nhận test basis.	BA tổng hợp bằng chứng và giữ traceability. BA không thay thế thẩm quyền các vai trò này.
Artifact	Cập nhật liên kết tới CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY; giữ tại trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.	Các artifact canonical là nguồn kiểm soát dự kiến. Không tạo ID mới hoặc gọi nội dung là đã phê duyệt.
Consequence if Wrong	Nếu chọn tích hợp API khi ERP không hỗ trợ, phạm vi và chi phí bị phóng đại. Nếu giữ nhập tay không có kiểm tra trùng, đơn có thể bị tạo sai hoặc bỏ sót dữ liệu.	Hai hậu quả xuất phát từ hai điểm chưa xác minh: năng lực API và lỗi sao chép đã quan sát trong dữ liệu tổng hợp.

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

flowchart TB
    subgraph BA[BA phân tích phạm vi IN_REVIEW]
        A1[Biểu mẫu bán hàng mô phỏng: Facts và Current Behavior] --> B[BA đối chiếu bằng chứng]
        B --> C{Loại xác nhận hoặc bằng chứng còn thiếu?}

        C -- Giá trị nghiệp vụ --> D1[Yêu cầu Business Owner xác nhận giá trị nghiệp vụ]
        C -- Cách tích hợp hoặc API ERP nếu xét phương án 3 --> D2[Yêu cầu Architect xác nhận cách tích hợp]
        C -- Ảnh hưởng ghi nhận --> D3[Yêu cầu Accounting Owner xác nhận ảnh hưởng ghi nhận]
        C -- Test basis --> D4[Yêu cầu QA xác nhận test basis]

        D1 --> V{Đã xác nhận?}
        D2 --> V
        D3 --> V
        D4 --> V
        V -- Có --> B
        V -- Không --> W[IN_REVIEW: dừng nhánh liên quan, giữ nội dung chờ xác minh]

        C -- Không còn --> K[Đánh giá: giảm nhập lại, kiểm tra trùng SalesOrderNumber, chưa phụ thuộc API ERP]
        K --> P[Giả định phạm vi: phương án 2, tệp nhập có kiểm tra trùng]
    end

    subgraph FILE[Luồng nhập tệp bảng tính mô phỏng theo giả định phương án 2]
        P --> A2[Người dùng xuất dữ liệu sang tệp bảng tính]
        A2 --> Y[Luồng nhập tệp tiếp nhận tệp]
        Y --> E[Kiểm tra trường bắt buộc và SalesOrderNumber]
        E --> F{Trùng hoặc thiếu dữ liệu?}
        F -- Có --> G[Trả lỗi nguồn gửi, lưu bằng chứng]
        G --> Z[Không tạo đơn ERP mô phỏng; giữ bằng chứng để truy vết]
        F -- Không --> H[ERP mô phỏng tạo đơn]
    end

    P --> T[Cập nhật liên kết tới CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY; giữ IN_REVIEW]
    Z --> T
    H --> T

Core

Bảng thực thi biến quan sát thành quyết định có kiểm soát. Facts là dữ kiện kiểm chứng được; Underlying Need là vấn đề cần giải quyết, không phải giải pháp đã chọn. Mermaid mô tả luồng dữ liệu và điểm quyết định để QA, Architect và Business Owner cùng đọc một cách hiểu.

Senior Lens

Không gọi kiểm tra trùng là yêu cầu pháp lý hay kiểm soát kế toán. Nó là nhu cầu dựa trên dữ liệu mô phỏng. Nếu luồng chạm hóa đơn, chứng từ, dữ liệu cá nhân hoặc truy xuất thực phẩm, ghi Verification required và chuyển Legal Owner, Accounting Owner hoặc domain owner xác minh theo nguồn chính thức.

Quick Reference

Kiểm tra	Đạt khi	Không đạt khi
Facts	Có dữ liệu tổng hợp hoặc quan sát nguồn	Chỉ có ý kiến
Decision	Có tiêu chí và giới hạn thẩm quyền	Chọn giải pháp theo sở thích
Artifact	Giữ IN_REVIEW, v0.9.0, traceability canonical	Gọi là baseline hoặc approved
Diagram	Có nhánh lỗi, nhánh escalation, đầu ra	Chỉ vẽ happy path

6. Output thu ???c

Core

Output là artifact, tức tài liệu hoặc bản ghi có cấu trúc để chuyển nhu cầu nghiệp vụ thành đầu vào có thể review. 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, không mô tả ERP thật.

Artifact tạo hoặc cập nhật	Canonical ID	Owner duy trì	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Business Needs & Objectives Record	NOVA-BNO-001	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Business problem, mục tiêu đo được, bằng chứng, stakeholder, ràng buộc, giả định, câu hỏi mở	Ghi version, ngày 2026-08-07, người sửa, trường thay đổi, lý do, artifact nguồn
Scope Boundary Record	NOVA-SCP-001	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	In-scope, out-of-scope, interface bị ảnh hưởng, dependency, rủi ro vượt phạm vi	Không sửa ranh giới im lặng; mỗi thêm, bỏ, đổi scope phải có lý do và impact
Stakeholder Need Register	NOVA-SNR-001	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Stakeholder, need, evidence, priority, authority boundary, unresolved conflict	Ghi nguồn của need; phân biệt fact, assumption và Verification required
Traceability Update	TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Liên kết NOVA-BNO-001, NOVA-SCP-001, NOVA-SNR-001 với nguồn và artifact kế tiếp	Giữ ID nguyên dạng; thêm dòng liên kết, không đổi nghĩa ID cũ

Owner duy trì artifact không có quyền baseline, approval, quyết định nghiệp vụ, legal sign-off, accounting sign-off hoặc production release. IN_REVIEW nghĩa là nội dung đang được review có kiểm soát; không nghĩa APPROVED, BASELINED, compliant hay production-ready.

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

flowchart TB
    A[Evidence nguồn mô phỏng]
    B[NOVA-BNO-001<br/>IN_REVIEW]
    C[NOVA-SCP-001<br/>IN_REVIEW]
    D[NOVA-SNR-001<br/>IN_REVIEW]
    E[TRACEABILITY_ID_REGISTRY<br/>IN_REVIEW]
    F[Artifact kế tiếp<br/>Downstream review input]

    G[Owner duy trì<br/>Principal IT Business Analyst /<br/>Technical Curriculum Author]
    H[Boundary quyền owner<br/>Không baseline, approval, quyết định nghiệp vụ,<br/>legal/accounting sign-off hoặc production release]

    I[Lịch sử BNO<br/>Ghi version, ngày 2026-08-07, người sửa,<br/>trường thay đổi, lý do, artifact nguồn]
    J[Lịch sử scope<br/>Mỗi thêm, bỏ, đổi scope: ghi lý do và impact;<br/>không sửa ranh giới im lặng]
    K[Lịch sử stakeholder need<br/>Ghi nguồn need; phân biệt fact, assumption<br/>và Verification required]
    L[Lịch sử registry<br/>Giữ ID nguyên dạng; thêm liên kết;<br/>không đổi nghĩa ID cũ]

    M[Boundary trạng thái<br/>IN_REVIEW không là APPROVED, BASELINED,<br/>compliant hoặc production-ready]

    A -->|cung cấp bằng chứng cho| B
    B -->|xác lập ranh giới scope| C
    B -->|thông tin cho stakeholder needs| D
    B -->|liên kết traceability| E
    C -->|liên kết traceability| E
    D -->|liên kết traceability| E
    E -->|liên kết tới artifact kế tiếp| F

    G -. duy trì .-> B
    G -. duy trì .-> C
    G -. duy trì .-> D
    G -. duy trì .-> E
    H -. giới hạn quyền .-> G

    I -. áp dụng .-> B
    J -. áp dụng .-> C
    K -. áp dụng .-> D
    L -. áp dụng .-> E

    M -. trạng thái .-> B
    M -. trạng thái .-> C
    M -. trạng thái .-> D
    M -. trạng thái .-> E

Applied

Thành phần	Nội dung Nova Foods mô phỏng
Facts	Bộ phận Sales nhập đơn bán từ biểu mẫu tổng hợp. Một số dòng có SalesOrderNumber trùng trong dữ liệu mẫu.
Current Behavior	Nhân viên đối chiếu thủ công trước khi nhập ERP mô phỏng. Không có bản ghi tập trung về nhu cầu kiểm tra trùng.
Underlying Need	Giảm nguy cơ tạo hai đơn mô phỏng từ cùng một SalesOrderNumber; giữ bằng chứng để review.
Options	Giữ đối chiếu thủ công; kiểm tra trùng trong màn hình nhập; kiểm tra trùng tại API.
Decision Criteria	Ngăn bản ghi trùng, lưu được bằng chứng lỗi, không suy diễn năng lực API chưa xác minh, không thay quyết định Architect.
Decision	Ghi nhu cầu kiểm tra trùng và giới hạn phạm vi phân tích; chưa chọn cơ chế UI, API hoặc DB.
Authority	Business Owner xác nhận ưu tiên nghiệp vụ; Architect đánh giá vị trí kiểm tra; QA review test basis.
Artifact	NOVA-BNO-001 ghi need và evidence; NOVA-SCP-001 ghi kiểm tra trùng thuộc phạm vi đơn bán mô phỏng; NOVA-SNR-001 ghi stakeholder Sales, Architect, QA.
Consequence if Wrong	Nếu ghi sai evidence hoặc scope, team có thể xây kiểm tra sai điểm, bỏ sót lỗi trùng, hoặc hiểu nhầm quyết định kỹ thuật đã được chốt.

Senior Lens

Anatomy tối thiểu của mỗi artifact gồm: metadata kiểm soát, canonical ID, owner, status, version v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, phạm vi Việt Nam, tiền tệ mô phỏng VND, nguồn evidence, nội dung chính, dependency, giới hạn thẩm quyền và change history. Evidence phải nêu artifact nguồn hoặc quan sát dữ liệu tổng hợp. Suy luận phải nêu cầu nối: dữ liệu có SalesOrderNumber trùng nên cần ghi nhận need kiểm tra trùng; dữ liệu đó chưa chứng minh giải pháp UI, API hay DB phù hợp.

Change history là phần bắt buộc vì reviewer cần biết nội dung nào đổi, ai ghi nhận, đổi lúc nào và vì sao. Dòng khởi tạo cho mọi artifact mới: v0.9.0 | 2026-08-07 | Principal IT Business Analyst / Technical Curriculum Author | Khởi tạo artifact ở trạng thái IN_REVIEW | Nguồn: nhu cầu section 6. Không gọi dòng này là baseline hay approval.

Quick Reference

Quy tắc	Áp dụng
ID	Dùng đúng NOVA-BNO-001, NOVA-SCP-001, NOVA-SNR-001, TRACEABILITY_ID_REGISTRY; không tự đổi tên giữa artifact.
Source classification	Dữ liệu Nova Foods: simulated educational case study, synthetic data only. Nguồn pháp lý hoặc chuẩn: chỉ tham chiếu theo safe use boundary.
Fact và assumption	Fact cần evidence. Assumption phải gắn nhãn. Nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm chưa xác minh phải ghi Verification required.
Status	Giữ IN_REVIEW cho đến khi artifact kiểm soát ghi nhận trạng thái khác theo thẩm quyền.
Change history	Mọi sửa đổi nội dung, phạm vi, evidence, owner hoặc traceability phải có dòng lịch sử mới.

Core

Artifact là vật phẩm bàn giao có cấu trúc, để người khác đọc, kiểm tra và truy vết. Một output hoàn chỉnh phải cho biết vấn đề nào được ghi nhận, bằng chứng nào dẫn đến nhu cầu, quyết định nào còn là giả định, và phần ERP nào bị ảnh hưởng.

Thành phần anatomy	Nội dung bắt buộc	Ví dụ Nova Foods mô phỏng
Business Need ID	Mã nhu cầu duy nhất, không đổi khi sửa diễn đạt	BUS-NEED-NF-001
Tên nhu cầu	Câu ngắn mô tả kết quả nghiệp vụ cần đạt	Theo dõi tồn kho theo lô nguyên liệu
Bối cảnh	Đơn vị, quy trình, thời điểm phát sinh	Kho nguyên liệu, quy trình nhận hàng
Facts	Sự kiện quan sát được; không lẫn suy đoán	Nhân viên nhập kho ghi mã lô trên phiếu giấy
Current Behavior	Cách quy trình đang chạy	Excel tổng hợp tồn kho chỉ theo mã hàng
Underlying Need	Nhu cầu gốc gây ra yêu cầu thay đổi	Cần biết số lượng tồn theo từng lô
Scope impact	Quy trình, dữ liệu, vai trò hoặc hệ thống bị tác động	Goods Receipt, Inventory Balance, Warehouse Clerk
Evidence	Nguồn hoặc giả định dẫn đến nội dung	Project assumption; dữ liệu tổng hợp
Open verification	Điểm chưa đủ bằng chứng hoặc cần thẩm quyền khác	Verification required: thời hạn lưu vết lô
Related artifact	ID artifact canonical liên quan	CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES
Change record	Lý do, ngày, người ghi nhận thay đổi	Khởi tạo 2026-08-07, Asia/Ho_Chi_Minh

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

flowchart TB
    A["Giả định: Mã lô ghi trên phiếu nhận hàng giấy"]
    B["Current Behavior: Excel tổng hợp tồn kho theo mã hàng"]
    A -->|"Mã lô trên phiếu giấy không được phản ánh trong tổng hợp theo mã hàng"| B
    C["Khoảng trống: Không thấy tồn theo lô"]
    B --> C
    D["BUS-NEED-NF-001<br/>Underlying Need: Cần biết số lượng tồn theo từng lô"]
    C --> D

    EA["Evidence: Project assumption"]
    EB["Evidence: Dữ liệu tổng hợp"]
    EA -.-> A
    EB -.-> B

    subgraph S["Scope impact"]
        S1["Goods Receipt"]
        S2["Inventory Balance"]
        S3["Warehouse Clerk"]
    end
    D --> S1
    D --> S2
    D --> S3

    E["Related artifact: CANONICAL_DATA_DICTIONARY"]
    F["Related artifact: CANONICAL_BUSINESS_RULES"]
    D -.-> E
    D -.-> F

    V["Open verification: Thời hạn lưu vết lô"]
    V --> W["Nguồn xác minh: Chưa xác định<br/>Người/phê duyệt xác minh: Chưa xác định"]
    D -.-> V

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, dùng vi-VN, Asia/Ho_Chi_Minh, VND.

Mục	Nội dung đã điền
Facts	Ngày 2026-08-07, Kho nguyên liệu nhận 500 kg đường trắng mã RM-SUGAR-001, lô LOT-SUG-260807-A. Nhân viên kho ghi lô trên phiếu giấy. File Excel tổng hợp chỉ có Item Code, Item Name, Quantity.
Current Behavior	Khi cần kiểm tra lượng đường của lô LOT-SUG-260807-A, nhân viên đối chiếu phiếu giấy với Excel. ERP mô phỏng chưa có output xác định tồn theo lô.
Underlying Need	Kho cần xem số lượng tồn, giao dịch nhập và giao dịch xuất theo từng mã lô để hỗ trợ truy vết nghiệp vụ. Đây là nhu cầu, chưa phải quyết định cấu hình ERP.
Options	1. Chỉ lưu mã hàng. 2. Lưu mã lô trong ghi chú tự do. 3. Lưu mã lô thành thuộc tính dữ liệu có cấu trúc trên giao dịch nhận và số dư tồn.
Decision Criteria	Truy vấn được tồn theo lô; tránh nhập mã lô không nhất quán; liên kết được giao dịch nhận với số dư tồn; không suy diễn nghĩa vụ pháp lý hoặc cấu hình production.
Decision	Chọn Option 3 cho output phân tích: mô hình dữ liệu logic phải có trường Lot Number liên kết với Item Code, giao dịch nhận hàng và số dư tồn. Lý do: ghi chú tự do không bảo đảm truy vấn hay kiểm soát định dạng; chỉ lưu mã hàng không đáp ứng nhu cầu truy vết theo lô.
Authority	Business Owner xác nhận nhu cầu vận hành. Data Owner và Architect xác nhận mô hình dữ liệu. Legal/Compliance Owner xác minh nghĩa vụ lưu vết nếu có. Không có xác nhận nào được ghi nhận trong ví dụ này.
Artifact	BUS-NEED-NF-001; liên kết dự kiến đến CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES.
Consequence if Wrong	Nếu mã lô chỉ nằm trong ghi chú hoặc giấy, báo cáo tồn theo lô có thể sai hoặc không lập được. Quyết định xuất, kiểm kê và truy vết mô phỏng sẽ thiếu dữ liệu đáng tin cậy.

Senior Lens

Cấu trúc output phải tách fact khỏi decision. Fact nói “Excel không có cột lô”; decision nói “cần trường Lot Number có cấu trúc”. Cầu nối là tiêu chí: cần truy vấn và liên kết giao dịch theo lô. Không có cầu nối này, BA có thể biến một quan sát nhỏ thành thiết kế ERP quá mức.

Project assumption không phải bằng chứng pháp lý, kế toán, an toàn thực phẩm hay vận hành thực tế. Mọi yêu cầu về thời gian lưu vết, thu hồi, chứng từ hoặc tuân thủ phải giữ nhãn Verification required cho đến khi owner có thẩm quyền xác minh theo nguồn chính thức.

Quick Reference

Kiểm tra anatomy	Đạt khi
Nhận diện	Có một ID duy nhất và tên nhu cầu đọc được
Logic	Facts, Current Behavior, Underlying Need không mâu thuẫn
Quyết định	Options và Decision có Decision Criteria giải thích
Truy vết	Có evidence hoặc nhãn Project assumption / Verification required
Phạm vi	Nêu rõ dữ liệu, quy trình hoặc vai trò bị ảnh hưởng
Ranh giới	Không gọi output là approved, baselined, compliant hoặc production-ready

Core

Cổng chất lượng (quality gate) là tập kiểm tra tối thiểu trước khi artifact được chuyển sang downstream review, tức bước xem xét của vai trò nhận đầu vào. Cổng này xác nhận artifact đủ để đọc, truy vết và phản biện; không xác nhận đúng nghiệp vụ, không tạo approval, baseline, tuân thủ pháp lý hay production readiness.

Kiểm tra bắt buộc	Điều kiện đạt	Bằng chứng trong artifact	Không đạt thì xử lý
Nhận dạng	Giữ đúng Artifact ID, filename canonical, IN_REVIEW, v0.9.0, ngày 2026-08-07	Metadata đầu artifact	Trả về người soạn để sửa metadata
Phạm vi	Nội dung chỉ nêu nhu cầu, mục tiêu, phạm vi đã có bằng chứng; không biến giả định thành fact	Nhãn Project assumption hoặc Verification required tại nội dung chưa xác minh	Tách nội dung chưa đủ bằng chứng
Truy vết	Mỗi nhận định liên kết tới nguồn hoặc artifact upstream canonical	Tham chiếu /00-research/00_SOURCE_MAP.md, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY khi phù hợp	Không chuyển review nếu thiếu đường truy
Khả năng đọc	Thuật ngữ tiếng Anh giải thích lần đầu; số liệu ghi rõ synthetic, vi-VN, VND khi có tiền	Bảng, định nghĩa, nhãn mô phỏng	Viết lại phần mơ hồ
Lịch sử thay đổi	Có dòng thay đổi nêu ngày, người ghi nhận, phần đổi, lý do	Change history theo Asia/Ho_Chi_Minh	Không sửa im lặng

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

stateDiagram-v2
    direction TB
    [*] --> Draft
    Draft --> IN_REVIEW: hoàn tất bản nháp; đặt metadata IN_REVIEW
    IN_REVIEW --> DownstreamReviewReady: nhận dạng, phạm vi, truy vết, khả năng đọc, lịch sử thay đổi đạt
    IN_REVIEW --> Draft: bất kỳ kiểm tra nào không đạt; trả về người soạn
    note right of DownstreamReviewReady
        Sẵn sàng chuyển sang downstream review
        Không xác nhận đúng nghiệp vụ
        Không tạo approval, baseline,
        tuân thủ pháp lý hay production readiness
    end note
    DownstreamReviewReady --> [*]

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là synthetic. Facts: artifact đang ở IN_REVIEW, v0.9.0, ngày 2026-08-07. Current Behavior: người nhận review cần biết nội dung đến từ đâu trước khi phản biện. Underlying Need: tránh reviewer suy diễn rằng trạng thái review là phê duyệt. Options: chuyển artifact khi soạn xong; hoặc chuyển sau cổng chất lượng. Decision Criteria: metadata đúng, nguồn truy được, nhãn xác minh còn nguyên, lịch sử thay đổi có mặt. Decision: chỉ chuyển sau cổng chất lượng đạt. Authority: Principal IT Business Analyst / Technical Curriculum Author kiểm tra tính đầy đủ quản trị; không cấp approval. Artifact: /02-handbook/05-business-needs-objectives-and-scope.md. Consequence if Wrong: downstream reviewer có thể review nhầm phiên bản, dùng giả định như fact, hoặc hiểu sai IN_REVIEW thành trạng thái sẵn sàng production.

Senior Lens

Cổng chất lượng kiểm tra reviewability, không kiểm tra acceptance. Reviewability nghĩa là người nhận có đủ ngữ cảnh để phát hiện lỗi. Acceptance nghĩa là vai trò có thẩm quyền chấp nhận nội dung. Hai việc khác nhau vì artifact có thể rõ ràng, truy vết đủ, nhưng vẫn bị Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA phản biện.

Quick Reference

Kết quả gate	Ý nghĩa
Đạt	Sẵn sàng chuyển downstream review; vẫn là IN_REVIEW
Không đạt	Quay lại sửa artifact; không chuyển review
Có nội dung pháp lý, kế toán, thuế, an toàn thực phẩm chưa xác minh	Gắn Verification required; không diễn đạt như nghĩa vụ Nova Foods
Có thay đổi	Ghi change history; không sửa im lặng

7. Who consumes those outputs?

Core

Consumer là vai trò nhận và dùng output để thực hiện công việc tiếp theo. Output của Business Needs, Objectives and Scope gồm: nhu cầu nghiệp vụ, mục tiêu, phạm vi in-scope/out-of-scope, giả định, ràng buộc, stakeholder và tiêu chí thành công. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là synthetic.

Consumer	Output dùng	Cách dùng trong công việc
Developers	Nhu cầu, phạm vi, ràng buộc, giả định	Chuyển nhu cầu thành hành vi hệ thống, màn hình, xử lý dữ liệu và tích hợp. Phạm vi ngăn xây chức năng ngoài yêu cầu.
QA	Mục tiêu, phạm vi, tiêu chí thành công, ràng buộc	Lập test basis, tức cơ sở để thiết kế kiểm thử. QA kiểm tra hệ thống có đạt kết quả mong muốn và không xử lý nhầm phần out-of-scope.
Architect	Mục tiêu, nhu cầu, ràng buộc kỹ thuật và vận hành	Đánh giá kiến trúc có đáp ứng tải, bảo mật, tích hợp, khả năng mở rộng và giới hạn nền tảng hay không.
PM/Product Owner	Mục tiêu, phạm vi, ưu tiên, stakeholder	Lập kế hoạch, quản lý backlog, thứ tự giao hàng và trade-off giữa thời gian, chi phí, phạm vi. Product Owner là người tối ưu giá trị sản phẩm; PM là người quản lý việc giao hàng.
Business Owner	Nhu cầu, mục tiêu, tiêu chí thành công, phạm vi	Đối chiếu output với kết quả nghiệp vụ cần đạt. Vai trò này dùng mục tiêu để xem đề xuất còn phục vụ nghiệp vụ hay đã lệch sang tính năng kỹ thuật.
Operations	Phạm vi thay đổi quy trình, giả định, ràng buộc vận hành	Chuẩn bị quy trình làm việc, hướng dẫn thao tác, dữ liệu vận hành và hỗ trợ sau triển khai. Operations không tự suy diễn quy trình mới từ một câu mô tả phạm vi.
Specialist owners	Ràng buộc và phần nội dung thuộc chuyên môn	Legal, Accounting, Security, Food Safety, Data hoặc Integration owner kiểm tra nội dung thuộc thẩm quyền. BA giữ traceability, không thay kết luận chuyên môn.

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

flowchart TB
    A[Business Needs Objectives Scope outputs]

    A -->|Needs, scope, constraints, assumptions| D[Developers]
    A -->|Objectives, scope, success criteria, constraints| Q[QA]
    A -->|Objectives, needs, technical and operational constraints| H[Architect]
    A -->|Objectives, scope, priorities, stakeholders| P[PM and Product Owner]
    A -->|Needs, objectives, success criteria, scope| B[Business Owner]
    A -->|Process-change scope, assumptions, operational constraints| O[Operations]
    A -->|Specialist constraints and content| S[Specialist owners]

    D --> DX[Define system behavior, screens, data handling and integrations]
    D --> DY[Prevent work outside requirements]

    Q --> QX[Create test basis]
    Q --> QY[Check intended outcomes and exclude out-of-scope processing]

    H --> HX[Assess load, security, integrations, scalability and platform limits]

    P --> PX[Plan backlog, delivery order and trade-offs]
    P --> PO[Product Owner]
    P --> PM[PM]
    PO --> POX[Optimize product value]
    PM --> PMX[Manage delivery]

    B --> BX[Check proposal serves business outcomes]
    BX --> BY[Check proposal has not drifted into technical features]

    O --> OX[Prepare processes, work instructions, operational data and post-launch support]
    O --> OY[Do not infer new processes from scope description alone]

    S --> SX[Check content within specialist authority]
    SX --> SC[Specialist conclusions]

    BA[BA] -->|Keeps| TX[Traceability]
    A --> TX
    BA -.->|Does not replace| SC

Applied

Trường	Nội dung
Facts	Nova Foods mô phỏng có nhu cầu giảm nhập tay đơn bán hàng từ kênh đại lý vào ERP. Mục tiêu ghi nhận là giảm thời gian nhập đơn; phạm vi chỉ gồm tiếp nhận đơn và kiểm tra dữ liệu bắt buộc.
Current Behavior	Nhân viên bán hàng nhận đơn qua tệp tổng hợp rồi nhập lại vào ERP.
Underlying Need	Giảm thao tác lặp và lỗi nhập liệu, nhưng không tự động mở rộng sang phê duyệt tín dụng, xuất hóa đơn hay điều phối giao hàng.
Options	Developers xây nhận tệp; QA kiểm thử dữ liệu bắt buộc; Architect đánh giá điểm tích hợp; PM/Product Owner ưu tiên backlog; Business Owner kiểm tra giá trị; Operations chuẩn bị quy trình xử lý lỗi; specialist owners kiểm tra phần thuộc chuyên môn.
Decision Criteria	Mỗi vai trò chỉ dùng output trong ranh giới chuyên môn; không biến mục tiêu giảm thời gian thành yêu cầu kỹ thuật chưa được ghi nhận.
Decision	Chuyển cùng một output có kiểm soát cho từng consumer, nhưng mỗi consumer tạo kết quả downstream khác nhau.
Authority	Business Owner sở hữu kết quả nghiệp vụ; Architect sở hữu kết luận kiến trúc; QA sở hữu đánh giá kiểm thử; specialist owner sở hữu kết luận chuyên môn. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability học liệu.
Artifact	/02-handbook/05-business-needs-objectives-and-scope.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Developer có thể xây cả quy trình giao hàng; QA có thể kiểm thử chức năng ngoài phạm vi; Operations có thể chuẩn bị sai quy trình; Business Owner có thể nhận kết quả không phục vụ mục tiêu ban đầu.

Senior Lens

Một output không có một người dùng duy nhất. Cùng câu “giảm thời gian nhập đơn” có nghĩa khác theo vai trò: Business Owner đọc nó như kết quả cần đạt; Developer đọc nó như động lực thiết kế; QA đọc nó như điều kiện cần chứng minh; Architect đọc nó như tải và tích hợp cần đánh giá; Operations đọc nó như thay đổi thao tác. Bằng chứng là các vai trò tạo ra deliverable downstream khác nhau dù dùng cùng nguồn.

Không chuyển “scope” như danh sách tính năng cô lập. Chuyển kèm mục tiêu và out-of-scope. Nếu chỉ có tính năng, Developer dễ tối ưu hành vi cục bộ; QA dễ viết test không đo giá trị; PM/Product Owner dễ ưu tiên theo độ lớn kỹ thuật thay vì giá trị nghiệp vụ.

Quick Reference

Output	Consumer chính	Kết quả downstream mong đợi
Business needs	Business Owner, PM/Product Owner, Developers	Giá trị cần bảo vệ, ưu tiên và hướng thiết kế
Objectives	Business Owner, QA, PM/Product Owner	Đo lường thành công, test basis, kế hoạch giao hàng
In-scope/out-of-scope	Developers, QA, Architect, Operations	Ranh giới build, test, kiến trúc và vận hành
Assumptions	Architect, Operations, specialist owners	Điểm cần xác thực trước khi dùng để thiết kế hoặc vận hành
Constraints	Architect, Developers, QA, specialist owners	Giới hạn kỹ thuật, dữ liệu, bảo mật, pháp lý hoặc vận hành cần kiểm tra
Stakeholder map	PM/Product Owner, Business Owner, Operations	Đúng người nhận review và đúng owner cho nội dung chuyên môn

Core

Mỗi đầu ra của BA là bằng chứng quyết định: mô tả nhu cầu, phạm vi, quy tắc, dữ liệu, tiêu chí chấp nhận và truy vết. Người nhận không tự suy diễn ngoài bằng chứng. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp; trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07 không phải baseline hay phê duyệt.

Người tiêu thụ	Có thể quyết định	Bằng chứng cần đọc	Phải escalation khi
Developers	Cách hiện thực trong giới hạn requirement; chia nhỏ công việc; xử lý lỗi kỹ thuật	Mục tiêu nghiệp vụ, in-scope/out-of-scope, business rule có ID, data field, acceptance criteria, traceability	Rule mơ hồ; hai rule mâu thuẫn; thiếu nguồn dữ liệu; yêu cầu làm lộ dữ liệu cá nhân; lựa chọn ảnh hưởng kiến trúc
QA	Test basis; test condition; phạm vi kiểm thử; dữ liệu kiểm thử tổng hợp	Acceptance criteria, business rule, luồng hiện tại/đích, data dictionary, lỗi và ngoại lệ	Acceptance criterion không kiểm thử được; expected result thiếu; rule không có owner; test phát hiện hành vi khác requirement
Architect	Khả thi kiến trúc; ranh giới hệ thống; tích hợp; non-functional requirement	Scope, context, interface need, data classification, volume/latency assumption, security constraint	Thay đổi ảnh hưởng nhiều hệ thống; API/identity/data ownership chưa rõ; rủi ro bảo mật; chi phí hoặc khả năng vận hành vượt giả định
PM/Product Owner	Ưu tiên, thứ tự giao, trade-off phạm vi-thời gian-chi phí, chấp nhận rủi ro delivery	Business objective, value, dependency, scope boundary, impact, decision criteria	Mục tiêu xung đột; scope tăng; dependency không có cam kết; quyết định làm đổi outcome nghiệp vụ
Business Owner	Xác nhận nhu cầu, rule nghiệp vụ, mức ưu tiên giá trị, ngoại lệ nghiệp vụ	Problem statement, current behavior, proposed outcome, rule source, impact mô phỏng, options	Rule ảnh hưởng doanh thu, giá bán, chính sách khách hàng, phân quyền nghiệp vụ hoặc quy trình liên phòng ban
Operations	Chuẩn bị vận hành, quyền truy cập, support flow, monitoring, rollback need	To-be process, role matrix, operational scenario, exception path, service/support impact	Thiếu owner xử lý lỗi; không có quy trình khôi phục; thay đổi làm gián đoạn kho, bán hàng, sản xuất hoặc đối soát
Specialist owner	Xác nhận chuyên môn hẹp: kế toán, pháp lý, bảo mật, dữ liệu, chất lượng thực phẩm	Quy tắc liên quan, nguồn chính thức, data flow, giả định dự án, tác động và câu hỏi cụ thể	Nội dung bị hiểu như kết luận pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc compliance

Quy tắc escalation: BA đóng gói vấn đề, không tự thay thẩm quyền. Gói phải nêu ID artifact, câu hỏi quyết định, bằng chứng hiện có, mâu thuẫn, tác động nếu không quyết định và owner cần trả lời. Nếu nguồn là luật, chuẩn hay đặc tả, chỉ dùng đúng ranh giới nguồn đã xác minh; diễn giải áp dụng cho Nova Foods cần Verification required bởi specialist owner phù hợp.

Core

Bàn giao sai thường vì người nhận đọc output như quyết định cuối cùng, dù artifact đang IN_REVIEW, v0.9.0, ngày 2026-08-07. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, BA phải ghi rõ: nội dung nào là fact, nội dung nào là project assumption, nội dung nào cần Verification required, và ai có thẩm quyền kết luận. Không dùng cuộc họp miệng thay traceability trong artifact kiểm soát.

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

flowchart TB
    A[BA bàn giao output] --> B[Kiểm tra IN_REVIEW<br/>phiên bản, ngày, fact, project assumption<br/>và Verification required]
    B --> C{Evidence đủ và đúng authority<br/>đã kết luận?}
    C -- Có --> D[Ra quyết định trong thẩm quyền]
    C -- Thiếu evidence hoặc authority --> E[Đặt câu hỏi làm rõ]
    E --> F{Xung đột nguồn hoặc vượt thẩm quyền?}
    F -- Không --> H[Ghi câu trả lời và traceability<br/>trong artifact kiểm soát]
    F -- Có --> G[Escalate Business Owner<br/>hoặc specialist owner phù hợp]
    G --> I{Owner xác nhận đủ evidence?}
    I -- Có --> H
    I -- Không, giữ Verification required --> J[Không ra quyết định<br/>Ghi unresolved, Verification required<br/>và owner chịu trách nhiệm tiếp theo]
    H --> C

Hiểu nhầm bàn giao	Rủi ro	Câu hỏi làm rõ phải ghi nguyên văn
Developer coi business need là rule triển khai	Code tự chọn ngưỡng, trạng thái, dữ liệu bắt buộc	“Business need này có business rule canonical nào trong /01-curriculum/CANONICAL_BUSINESS_RULES.md không? Nếu chưa có, ai quyết định rule và trạng thái nào hiện là Verification required?”
QA coi acceptance criteria là toàn bộ test basis	Bỏ sót ngoại lệ, quyền, dữ liệu biên	“Acceptance criteria này có bao phủ luồng từ chối, dữ liệu không hợp lệ, phân quyền và lỗi tích hợp không? Nếu không, artifact nào là nguồn cho từng điều kiện còn thiếu?”
Architect coi scope là quyết định kiến trúc	Chọn integration, lưu trữ, bảo mật vượt thẩm quyền	“Scope chỉ xác định capability hay đã có quyết định kiến trúc? Interface, data ownership, NFR và security constraint nào đã có evidence?”
PM/Product Owner coi ưu tiên là phê duyệt phạm vi	Đưa item vào sprint dù chưa rõ authority	“Ưu tiên này là đề xuất học liệu hay quyết định delivery? Người có thẩm quyền nào xác nhận value, deadline và scope boundary?”
Business Owner coi mockup là cam kết quy trình	Chấp nhận UI nhưng rule nền chưa đúng	“Màn hình này minh họa thao tác hay xác nhận quy trình nghiệp vụ? Rule, ngoại lệ và người chịu trách nhiệm từng bước đã được xác định ở đâu?”
Operations coi requirement là hướng dẫn production	Vận hành theo nội dung chưa baseline	“Nội dung đang IN_REVIEW; bước vận hành nào là project assumption, và điều kiện nào cần xác nhận bởi Operations Owner trước khi dùng?”
Specialist owner coi tham chiếu luật là kết luận tuân thủ	Sai pháp lý, kế toán, an toàn thực phẩm, riêng tư	“Yêu cầu này được suy ra từ nguồn nào, nguồn có xác minh điều khoản cụ thể chưa, và Legal Owner, Accounting Owner hoặc domain owner nào phải kết luận?”

Applied

Trường	Nội dung
Facts	Developer nhận mô tả “ERP phải chặn xuất kho khi lô hàng không đủ điều kiện”. Artifact chưa nêu “đủ điều kiện” là trạng thái nào, ai cập nhật trạng thái, hay ngoại lệ khi thu hồi.
Current Behavior	Developer định nghĩa “đủ điều kiện” là tồn kho lớn hơn 0. QA viết test chỉ kiểm tra số lượng tồn.
Underlying Need	Cần tách điều kiện số lượng khỏi điều kiện chất lượng và truy vết lô. Evidence: câu “lô hàng” nói về đối tượng lô; “đủ điều kiện” chưa định nghĩa tiêu chí. Suy luận này phải được xác minh, không tự biến thành rule.
Options	(1) Code theo tồn kho; (2) dừng implementation phần chặn và yêu cầu rule; (3) dùng trạng thái lô nếu rule canonical đã tồn tại.
Decision Criteria	Chỉ chọn khi có nguồn canonical, owner có thẩm quyền, định nghĩa dữ liệu và acceptance criteria kiểm thử được.
Decision	Chọn phương án (2) khi chưa có rule canonical. Ghi Verification required; không suy diễn trạng thái lô.
Authority	Business Owner quyết định quy tắc nghiệp vụ; Operations và specialist owner xác nhận khả năng vận hành; Architect quyết định tác động kiến trúc; QA xác định test basis sau khi rule rõ.
Artifact	Tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md; cả hai đang IN_REVIEW, v0.9.0, không phải baseline hay approval.
Consequence if Wrong	Hệ thống có thể xuất lô không phù hợp hoặc chặn lô hợp lệ. Đây là rủi ro mô phỏng; xác nhận food-safety, traceability và pháp lý cần domain owner và Legal Owner.

Senior Lens

Escalate ngay khi câu trả lời làm thay đổi rule, data ownership, quyền truy cập, tích hợp, hạch toán, nghĩa vụ pháp lý, hay quy trình vận hành. BA không chọn hộ owner. BA đóng gói vấn đề gồm artifact nguồn, câu đang mơ hồ, các phương án, evidence thiếu, tác động và câu hỏi quyết định.

Không hỏi “Anh/chị xác nhận giúp?” vì không xác định đối tượng xác nhận. Hỏi: “Ai có thẩm quyền quyết định tiêu chí đủ điều kiện cho lô hàng trong phạm vi Nova Foods mô phỏng, và quyết định đó cần được ghi vào artifact canonical nào?” Câu này buộc rõ authority, decision và nơi lưu traceability.

Quick Reference

Khi thấy	Làm ngay
Từ mơ hồ: “hợp lệ”, “đủ”, “nhanh”, “đúng quy định”	Hỏi định nghĩa, dữ liệu chứng minh, ngoại lệ, owner quyết định.
Artifact IN_REVIEW	Không gọi là approved, baselined hoặc production-ready.
Rule chạm thuế, kế toán, riêng tư, an toàn thực phẩm	Gắn Verification required; escalate Legal Owner, Accounting Owner hoặc domain owner phù hợp.
Người nhận muốn tự điền chỗ trống	Dừng suy diễn; ghi câu hỏi làm rõ vào traceability.

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 có thể kiểm tra. Nova Foods Trading & Manufacturing là doanh nghiệp mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

Phạm vi micro-batch này chỉ lập Facts (sự kiện có bằng chứng) và Current Behavior (hành vi hiện tại). Chưa suy ra nhu cầu gốc, chưa đề xuất phương án, chưa tạo quyết định hay xác nhận thẩm quyền.

Applied

Kịch bản mô phỏng: Kho Bình Dương nhận đơn bán 120 thùng nước ép xoài 1L cho khách hàng siêu thị. Nhân viên kho phân bổ hàng theo số tồn tổng trên bảng tính. ERP hiện tại chỉ lưu tồn theo mã hàng và kho, không lưu tồn khả dụng theo lô.

Thuộc tính	Giá trị
Case ID	NF-SCOPE-EX-001
Tên kịch bản	Phân bổ đơn bán theo tồn tổng, chưa kiểm tra trạng thái lô
Đơn vị mô phỏng	Nova Foods Trading & Manufacturing
Kho	WH-BD-01 — Kho Bình Dương
Mã hàng	FG-MANGO-1L — Nước ép xoài 1L
Đơn vị tính	Thùng
Ngày giao dự kiến	2026-08-08
Đơn bán	SO-20260807-0142
Khách hàng	CUS-MART-028 — Siêu thị Minh Tâm
Số lượng đơn	120 thùng
Nguồn dữ liệu hiện tại	Bảng tính tồn kho WH-BD-01_Stock_2026-08-07.xlsx; email nội bộ; ERP mô phỏng
Phân loại nguồn	Dữ liệu vận hành mô phỏng, chưa baseline, không phải bằng chứng tuân thủ pháp lý

Facts

Fact ID	Sự kiện tổng hợp	Bằng chứng mô phỏng	Ý nghĩa quan sát
FACT-NF-001	ERP hiển thị tồn tổng FG-MANGO-1L tại WH-BD-01 là 180 thùng lúc 09:10 ngày 2026-08-07.	Màn hình báo cáo tồn ERP mô phỏng INV-ONHAND-01.	ERP đủ dữ liệu để biết tổng số lượng vật lý theo mã hàng và kho.
FACT-NF-002	Bảng tính kho ghi ba lô thuộc cùng mã hàng, tổng cộng 180 thùng.	WH-BD-01_Stock_2026-08-07.xlsx, sheet LotStatus.	Tồn tổng 180 thùng khớp tổng ba lô trong bảng tính kho.
FACT-NF-003	Lô LOT-MG-260701-A có 80 thùng, trạng thái ghi tay Released.	Cùng sheet LotStatus, dòng 2.	Kho đang quản lý trạng thái lô ngoài ERP.
FACT-NF-004	Lô LOT-MG-260703-B có 40 thùng, trạng thái ghi tay Quality Hold.	Cùng sheet LotStatus, dòng 3.	Có hàng vật lý tồn kho nhưng chưa được kho đánh dấu sẵn sàng xuất.
FACT-NF-005	Lô LOT-MG-260705-C có 60 thùng, trạng thái ghi tay Released.	Cùng sheet LotStatus, dòng 4.	Tổng hàng được ghi Released là 140 thùng.
FACT-NF-006	Đơn SO-20260807-0142 yêu cầu 120 thùng.	Email nội bộ Sales-to-Warehouse_2026-08-07_0905.eml.	Nhu cầu đơn hàng thấp hơn tồn tổng 180 thùng và thấp hơn 140 thùng được ghi Released.
FACT-NF-007	ERP không có trường số lô, trạng thái chất lượng lô, ngày hết hạn hoặc lượng khả dụng theo lô trên màn hình tạo phiếu xuất.	Quan sát cấu hình ERP mô phỏng ERP-SALES-SHIP-01.	Người lập phiếu xuất không thấy dữ liệu phân biệt lô trong cùng mã hàng.

Dữ liệu lô hiện tại

Lot ID	Mã hàng	Kho	Tồn vật lý	Trạng thái ghi trong bảng tính	Hạn dùng mô phỏng	Có được ERP hiển thị khi tạo xuất kho?
LOT-MG-260701-A	FG-MANGO-1L	WH-BD-01	80	Released	2027-01-01	Không
LOT-MG-260703-B	FG-MANGO-1L	WH-BD-01	40	Quality Hold	2027-01-03	Không
LOT-MG-260705-C	FG-MANGO-1L	WH-BD-01	60	Released	2027-01-05	Không
Tổng	FG-MANGO-1L	WH-BD-01	180	Không áp dụng	Không áp dụng	ERP chỉ hiển thị tổng 180

Quy tắc hiện hành được quan sát, không phải quy tắc đã phê duyệt

Rule ID	Mô tả hành vi hiện tại	Evidence bridge
OBS-RULE-001	Nhân viên kho cho rằng đơn có thể xuất khi số lượng đơn không vượt tồn tổng ERP.	FACT-NF-001 cho tồn 180; FACT-NF-006 cho đơn 120; ERP không cảnh báo theo lô theo FACT-NF-007.
OBS-RULE-002	Trạng thái Quality Hold chỉ được kiểm tra bằng bảng tính kho trước khi lấy hàng.	FACT-NF-004 đặt trạng thái ngoài ERP; FACT-NF-007 xác nhận ERP không hiển thị trạng thái này.
OBS-RULE-003	Phiếu xuất ERP không giữ liên kết giữa SO-20260807-0142 và Lot ID được lấy thực tế.	FACT-NF-007 xác nhận không có trường số lô trên luồng tạo xuất kho.

Current Behavior

Nhân viên bán hàng gửi email yêu cầu xuất 120 thùng. Nhân viên kho mở ERP, thấy tồn tổng 180 thùng, rồi tạo phiếu xuất cho toàn bộ 120 thùng. ERP chấp nhận vì 120 không vượt 180. Sau đó nhân viên kho mở bảng tính riêng để xem trạng thái lô, chọn hàng tại khu vực kho và ghi nhận xuất hàng. Liên kết giữa đơn bán, lô đã chọn và trạng thái lô không được lưu trong ERP.

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

flowchart TB
    A["Nhân viên bán hàng gửi SO-20260807-0142: 120 thùng"] --> B["Nhân viên kho xem ERP INV-ONHAND-01"]
    B --> C["ERP hiển thị tồn vật lý tổng: 180 thùng"]
    C --> D["Nhân viên kho đối chiếu: nhu cầu 120 thùng không vượt tồn tổng 180 thùng"]
    D --> E["ERP chấp nhận tạo phiếu xuất 120 thùng"]
    E --> F["ERP không hiển thị Lot ID hoặc trạng thái Quality Hold"]
    F --> G["Nhân viên kho mở WH-BD-01_Stock_2026-08-07.xlsx"]
    G --> H["Bảng tính ghi 140 thùng Released và 40 thùng Quality Hold"]
    H --> I["140 thùng ghi Released lớn hơn nhu cầu 120 thùng"]
    I --> J["Nhân viên kho chọn lô thủ công sau khi xem trạng thái lô"]
    J --> K["ERP không hiển thị và không lưu Lot ID hoặc trạng thái lô trên phiếu xuất"]
    K --> L["ERP ghi nhận xuất 120 thùng nhưng không lưu Lot ID thực tế gắn với SO-20260807-0142"]

Điểm cần giữ nguyên khi phân tích tiếp: 180 là tồn vật lý tổng; 140 là tổng lượng được bảng tính ghi Released; 40 thuộc LOT-MG-260703-B được ghi Quality Hold. Các trạng thái này là sự kiện mô phỏng từ nguồn vận hành nội bộ, chưa phải quy tắc canonical hoặc xác nhận an toàn thực phẩm.

Senior Lens

Không suy luận “40 thùng không được xuất” thành quy định bắt buộc. Bằng chứng hiện có chỉ cho thấy bảng tính gắn nhãn Quality Hold và ERP không kiểm soát nhãn đó. Ý nghĩa vận hành, an toàn thực phẩm, traceability và thẩm quyền xử lý lô cần domain owner, Legal Owner và vai trò chất lượng xác minh.

Quick Reference

Thành phần	Giá trị cần nhớ
Sự kiện chắc chắn	ERP thấy tồn tổng 180; bảng tính ghi ba lô; đơn cần 120.
Khoảng cách quan sát	ERP không lưu Lot ID, trạng thái lô, hạn dùng hoặc liên kết lô với phiếu xuất.
Không được kết luận lúc này	Nhu cầu gốc, phương án ERP, tiêu chí chọn phương án, quyết định, approval hoặc compliance.
Trạng thái artifact	IN_REVIEW, v0.9.0, ngày 2026-08-07; không phải baseline hay approval.

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, tiền tệ VND. Kịch bản SCN-NF-INV-001: kho thành phẩm cần chặn xuất bán lô hàng có ngày hết hạn trước ngày giao dự kiến.

Bước	Nội dung đã phân tích	Bằng chứng hoặc cầu nối suy luận
Facts	Đơn bán SO-NF-202608-0142 gồm 120 thùng SKU NF-NUOCMAM-500ML, ngày giao dự kiến 2026-08-12. Kho WH-HCM-01 có lô LOT-NM-260810-A, tồn khả dụng 180 thùng, hạn dùng 2026-08-10; và lô LOT-NM-260930-B, tồn khả dụng 70 thùng, hạn dùng 2026-09-30.	Lô A đủ số lượng nhưng hết hạn trước ngày giao. Lô B còn hạn nhưng không đủ toàn bộ số lượng.
Current Behavior	Nhân viên kho xem tồn theo SKU, không bị ERP chặn khi chọn lô. Có thể xác nhận xuất 120 thùng từ lô A vì tồn khả dụng lớn hơn số lượng đơn.	Điều kiện hiện tại chỉ kiểm tra available_quantity >= requested_quantity; không so sánh expiry_date với planned_delivery_date.
Underlying Need	Doanh nghiệp cần ngăn xác nhận xuất khi hạn dùng của lô nhỏ hơn ngày giao dự kiến, đồng thời cho phép xử lý ngoại lệ có kiểm soát.	Vấn đề không phải thiếu báo cáo tồn. Vấn đề là điểm kiểm soát nằm tại thao tác xác nhận xuất, nơi giao dịch có thể tạo hậu quả giao hàng sai.
Options	OPT-01: cảnh báo mềm, vẫn cho xác nhận. OPT-02: chặn xác nhận xuất từng lô không đạt hạn dùng. OPT-03: chặn như OPT-02 và cho phép override có lý do, quyền riêng, nhật ký kiểm toán.	OPT-01 giảm ma sát nhưng không ngăn lỗi. OPT-02 ngăn lỗi nhưng không có đường xử lý tình huống hợp lệ. OPT-03 giữ kiểm soát và tạo bằng chứng cho ngoại lệ.
Decision Criteria	C1 ngăn xuất lô hết hạn trước ngày giao; C2 không cho người chọn lô tự bỏ qua chặn; C3 lưu được người, thời điểm, lý do override; C4 không tự diễn giải nghĩa vụ pháp lý hay kế toán; C5 hỗ trợ xuất một phần hoặc đổi lô.	C1 xử lý nhu cầu cốt lõi. C2-C3 giảm rủi ro thao tác và hỗ trợ truy vết. C4 giữ đúng ranh giới thẩm quyền. C5 tránh biến quy tắc thành chặn toàn bộ đơn khi vẫn có phương án giao hợp lệ.
Decision	Khuyến nghị BA: chọn OPT-03. Quy tắc đề xuất: khi lot.expiry_date < shipment.planned_delivery_date, ERP chặn xác nhận dòng xuất của lô đó. Override chỉ mở cho vai trò được Business Owner và Quality Owner chỉ định, bắt buộc nhập lý do, lưu audit log.	OPT-03 đạt đủ C1-C5. Đây là khuyến nghị phân tích, chưa là quyết định được ủy quyền.
Authority	Business Owner quyết định chấp nhận mục tiêu vận hành. Quality Owner xác nhận tiêu chí hạn dùng và ngoại lệ. Solution Architect xác nhận khả năng cấu hình ERP và audit log. Legal/Compliance Owner xác minh nếu quy tắc được viện dẫn cho nghĩa vụ pháp lý hoặc an toàn thực phẩm.	Artifact corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07; không có baseline hay approval reference. Không vai trò nào trong ví dụ đã phê duyệt.
Artifact	Cập nhật đề xuất vào /01-curriculum/CANONICAL_BUSINESS_RULES.md dưới ID chỉ được đăng ký sau khi registry xác nhận; liên kết phân tích tại /02-handbook/05-business-needs-objectives-and-scope.md, section 08-worked-example. Payload logic dưới đây là dữ liệu mô phỏng.	Tách rule canonical khỏi ví dụ học liệu. Không dùng ví dụ để tự tạo rule production.
Consequence if Wrong	Nếu chỉ dùng cảnh báo mềm, 120 thùng lô A có thể được giao ngày 2026-08-12 dù hạn dùng 2026-08-10. Nếu chặn tuyệt đối không có override, đơn có thể bị dừng dù có ngoại lệ nghiệp vụ hợp lệ được Quality Owner xác nhận. Nếu cho override không audit, không truy được ai đã bỏ qua chặn và vì sao.	Hai cực đoan cùng sai: kiểm soát quá yếu gây xuất sai; kiểm soát quá cứng gây gián đoạn vận hành.

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

flowchart TB
    subgraph REVIEW[IN_REVIEW — chưa áp dụng production]
        A[Nhân viên kho chọn lô cho dòng xuất] --> B{Tồn khả dụng đủ số lượng xuất?}
        B -- Không --> C[Đổi lô hoặc xuất một phần]
        C --> A
        B -- Có --> D{expiry_date >= planned_delivery_date?}

        D -- Có --> E[Xác nhận dòng xuất bình thường]
        D -- Không --> F[ERP chặn xác nhận dòng xuất]
        F --> G{Vai trò override được chỉ định và cấp quyền?}

        G -- Không --> C
        G -- Có --> H[Nhập lý do override]
        H --> I[Kiểm tra và thực hiện override theo quyền được cấp]
        I --> J[Ghi audit log:<br/>người, thời điểm, lý do override, kết quả]
        J --> K[Xác nhận dòng xuất ngoại lệ]
    end

    subgraph RESPONSIBILITY[Trách nhiệm xác minh thiết kế]
        L[Business Owner và Quality Owner:<br/>xác nhận mục tiêu, tiêu chí<br/>và chỉ định vai trò override]
        M[Solution Architect:<br/>xác nhận cấu hình ERP và audit log]
        N[Legal/Compliance Owner:<br/>xác minh khi viện dẫn nghĩa vụ pháp lý<br/>hoặc an toàn thực phẩm]
    end

    L -.-> G
    M -.-> F
    M -.-> J
    N -.-> D

Payload kiểm tra đề xuất

{
  "scenario_id": "SCN-NF-INV-001",
  "sales_order_id": "SO-NF-202608-0142",
  "warehouse_id": "WH-HCM-01",
  "sku": "NF-NUOCMAM-500ML",
  "requested_quantity": 120,
  "uom": "THUNG",
  "planned_delivery_date": "2026-08-12",
  "selected_lot": {
    "lot_id": "LOT-NM-260810-A",
    "available_quantity": 180,
    "expiry_date": "2026-08-10"
  },
  "validation_result": "BLOCK",
  "validation_message": "Lô LOT-NM-260810-A hết hạn trước ngày giao dự kiến 2026-08-12."
}

Quy tắc đề xuất: BLOCK khi selected_lot.expiry_date < planned_delivery_date. Không suy ra quy tắc này là yêu cầu pháp lý. Xác minh pháp lý, an toàn thực phẩm và cấu hình ERP vẫn cần owner có thẩm quyền.

Applied

Tình huống mô phỏng: Nova Foods Trading & Manufacturing nhận đơn bán SO-NF-20260807-001 từ khách hàng tổng hợp CUS-NF-001. Đơn yêu cầu giao 120 thùng sữa hạt OatPlus 1L, mã hàng FG-OAT-1L-12, từ kho thành phẩm WH-HCM-FG. Mọi dữ liệu dưới đây là dữ liệu tổng hợp, dùng cho học liệu; không phải cấu hình ERP, quy định vận hành, hay quyết định đã phê duyệt.

Trường	Giá trị
Scenario ID	SCN-NF-ORDER-ALLOCATION-001
Ngày ghi nhận	2026-08-07
Locale	vi-VN
Múi giờ	Asia/Ho_Chi_Minh
Tiền tệ	VND
Trạng thái scenario	IN_REVIEW
Artifact liên quan	/02-handbook/05-business-needs-objectives-and-scope.md
Artifact quản trị tham chiếu	TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY
Phân loại nguồn	Tình huống mô phỏng giáo dục; không phải primary source, không phải bằng chứng vận hành Nova Foods

Thực thể	ID	Dữ liệu đầy đủ
Khách hàng	CUS-NF-001	Công ty Phân phối Minh An, kênh GT, địa chỉ tổng hợp tại TP. Hồ Chí Minh
Đơn bán	SO-NF-20260807-001	Ngày đơn 2026-08-07; khách hàng CUS-NF-001; kho giao WH-HCM-FG; yêu cầu giao 2026-08-08
Dòng đơn bán	SOL-NF-20260807-001-01	Hàng FG-OAT-1L-12; số lượng đặt 120 thùng; đơn giá 348000 VND/thùng; thành tiền 41760000 VND
Hàng thành phẩm	FG-OAT-1L-12	Sữa hạt OatPlus 1L, quy cách 12 chai/thùng
Kho thành phẩm	WH-HCM-FG	Kho thành phẩm TP. Hồ Chí Minh
Lô tồn kho khả dụng	LOT-OAT-20260720-A	Số lượng vật lý 80 thùng; đã giữ chỗ 0; khả dụng 80; hạn dùng 2027-01-20
Lô tồn kho khả dụng	LOT-OAT-20260725-B	Số lượng vật lý 50 thùng; đã giữ chỗ 0; khả dụng 50; hạn dùng 2027-01-25
Tổng tồn khả dụng	INV-AVAIL-FG-OAT-1L-12	130 thùng; đủ đáp ứng đơn 120 thùng

Quy tắc dùng trong scenario. Đây là quy tắc đề xuất để phân tích, chưa phải quy tắc được thẩm quyền Nova Foods xác nhận.

Rule ID làm việc	Quy tắc	Bằng chứng trong dữ liệu
WRK-BR-001	Chỉ cho phép xác nhận phân bổ khi tổng số lượng khả dụng lớn hơn hoặc bằng số lượng dòng đơn.	130 >= 120
WRK-BR-002	Phân bổ theo FEFO, First Expired, First Out: ưu tiên lô có hạn dùng gần hơn.	2027-01-20 sớm hơn 2027-01-25
WRK-BR-003	Tổng lượng phân bổ phải bằng lượng đơn đã xác nhận; không tạo giao thiếu im lặng.	80 + 40 = 120
WRK-BR-004	Hệ thống phải lưu ID lô trên từng dòng phân bổ để truy vết hàng giao.	Hai lô LOT-OAT-20260720-A, LOT-OAT-20260725-B

Payload đề xuất cho dịch vụ phân bổ nội bộ. Payload minh họa cấu trúc dữ liệu; không phải đặc tả OpenAPI, không phải hợp đồng API đã phê duyệt.

{
  "allocationRequestId": "ALR-NF-20260807-001",
  "salesOrderId": "SO-NF-20260807-001",
  "salesOrderLineId": "SOL-NF-20260807-001-01",
  "warehouseId": "WH-HCM-FG",
  "itemId": "FG-OAT-1L-12",
  "requestedQuantity": 120,
  "uom": "CARTON",
  "allocationMethod": "FEFO",
  "allocations": [
    {
      "lotId": "LOT-OAT-20260720-A",
      "allocatedQuantity": 80,
      "expiryDate": "2027-01-20"
    },
    {
      "lotId": "LOT-OAT-20260725-B",
      "allocatedQuantity": 40,
      "expiryDate": "2027-01-25"
    }
  ],
  "allocationStatus": "PROPOSED",
  "currency": "VND",
  "recordedAt": "2026-08-07T09:30:00+07:00"
}

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

flowchart TB
    A[Đơn SO-NF-20260807-001<br/>120 thùng] --> B[Đọc tồn khả dụng<br/>130 thùng]
    B --> C{130 thùng đủ 120 thùng?}

    C -- Có --> D[Ưu tiên FEFO<br/>LOT-OAT-20260720-A: 80 thùng]
    D --> E[Phân bổ còn lại<br/>LOT-OAT-20260725-B: 40 thùng]
    E --> F{Tổng phân bổ<br/>80 + 40 = 120?}

    F -- Có --> G[Lưu 2 dòng phân bổ<br/>kèm lotId và allocatedQuantity]
    G --> H[Trạng thái PROPOSED<br/>chờ Business Owner và Warehouse Owner xác nhận]

    F -- Không --> I[Không xác nhận phân bổ<br/>xử lý ngoại lệ theo WRK-BR-003]
    C -- Không --> J[Không xác nhận phân bổ<br/>xử lý thiếu hàng chờ quyết định]

Lựa chọn	Mô tả	Đáp ứng WRK-BR-001	Đáp ứng WRK-BR-002	Kết quả đánh giá
OPT-1	Phân bổ 120 thùng từ lô LOT-OAT-20260725-B	Không; lô chỉ có 50 thùng	Không	Loại
OPT-2	Phân bổ 80 thùng từ lô A và 40 thùng từ lô B theo FEFO	Có	Có	Khuyến nghị
OPT-3	Phân bổ 80 thùng từ lô A, giao thiếu 40 thùng	Không; lượng phân bổ không bằng lượng đơn	Có một phần	Loại

Khuyến nghị BA: chọn OPT-2, tạo hai dòng phân bổ, giữ trạng thái PROPOSED đến khi Business Owner và Warehouse Owner xác nhận quy tắc phân bổ, ưu tiên FEFO, và cách xử lý giao thiếu.

Quyết định được thẩm quyền: chưa có. Status IN_REVIEW, version v0.9.0, ngày 2026-08-07 không phải APPROVED hay BASELINED. Không được diễn giải khuyến nghị OPT-2 là quyết định vận hành Nova Foods.

Artifact đầu ra đề xuất	ID tham chiếu	Nội dung phải lưu	Authority cần xác nhận
Bảng phân bổ đơn	ALR-NF-20260807-001	Đơn, dòng đơn, kho, hàng, lô, lượng phân bổ, hạn dùng, trạng thái	Warehouse Owner
Catalog quy tắc	CANONICAL_BUSINESS_RULES	Xác nhận hoặc từ chối WRK-BR-001 đến WRK-BR-004	Business Owner, Warehouse Owner
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	Định nghĩa allocatedQuantity, availableQuantity, lotId, expiryDate	Data Owner
Registry truy vết	TRACEABILITY_ID_REGISTRY	Đăng ký ID chính thức nếu scenario chuyển thành artifact kiểm soát	Principal IT Business Analyst / Technical Curriculum Author

Nếu chọn sai, hệ thống có thể giữ chỗ vượt tồn, giao sai lô, mất liên kết lô-hàng giao, hoặc ghi nhận đủ đơn khi thực tế giao thiếu. Đây là hệ quả phân tích từ WRK-BR-001 đến WRK-BR-004; không phải kết luận về vận hành thực tế hay tuân thủ pháp lý của Nova Foods.

9. Related Concepts & Dependencies

Core

Phụ thuộc là quan hệ một artifact cần thông tin, định nghĩa hoặc định danh từ artifact khác để giữ cùng nghĩa. Nguồn chân lý canonical là tệp được chỉ định duy nhất để sở hữu nội dung đó. Artifact này chỉ liên kết, không chép lại nội dung canonical. Lý do: bản sao có thể lệch sau thay đổi, khiến cùng một thuật ngữ mang hai nghĩa.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tên, ID và dữ liệu dưới đây là tổng hợp. Status corpus là IN_REVIEW, version v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Các trạng thái này không tạo baseline, approval hoặc thẩm quyền vận hành.

Applied

Facts: Scenario kho của Nova Foods dùng WRK-BR-001 đến WRK-BR-004 và artifact phân bổ ALR-NF-20260807-001. Các chuỗi này xuất hiện trong worked example trước, nhưng chưa được khẳng định là ID canonical đã đăng ký.

Current Behavior: BA có thể ghi lại câu “ưu tiên FEFO” trong chapter, template và test note. Ba bản ghi độc lập tạo ba điểm phải cập nhật.

Underlying Need: Cần biết nơi sở hữu từng loại thông tin để chapter giải thích được dependency nhưng không biến thành catalog quy tắc, registry ID hoặc từ điển dữ liệu.

Options:
1. Chép toàn bộ quy tắc và định nghĩa dữ liệu vào chapter.
2. Chỉ ghi ID, đường dẫn canonical, vai trò dependency và ranh giới sử dụng.
3. Đặt ID mới trực tiếp trong chapter khi thiếu registry.

Decision Criteria: Không trùng nguồn chân lý; giữ nguyên ID và filename; phân biệt ID minh họa với ID đã đăng ký; không suy diễn approval; cho phép reader lần về artifact sở hữu nội dung.

Decision: Chọn option 2. Section này dùng liên kết kiểm soát. Nội dung đầy đủ của quy tắc thuộc CANONICAL_BUSINESS_RULES; nghĩa trường dữ liệu thuộc CANONICAL_DATA_DICTIONARY; tính hợp lệ và trạng thái ID thuộc TRACEABILITY_ID_REGISTRY.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Business Owner, Warehouse Owner, Data Owner, Architect, QA và các owner chuyên môn giữ thẩm quyền nội dung thuộc phạm vi họ. Không có authority nào được ghi nhận đã phê duyệt scenario này.

Artifact: /02-handbook/05-business-needs-objectives-and-scope.md, section 09-dependencies, tham chiếu manifest và registry bên dưới.

Consequence if Wrong: Nếu chapter tự sao chép WRK-BR-001, một thay đổi tại catalog có thể không tới chapter. Learner hoặc team sau đó dùng quy tắc cũ để thiết kế phân bổ, dù catalog đã đổi. Lỗi là lệch nguồn chân lý, không phải bằng chứng Nova Foods vận hành sai.

Loại dependency	Upstream canonical	Section này dùng gì	Downstream tiêu thụ gì	Không được làm
Cấu trúc chapter	/01-curriculum/CHAPTER_MANIFEST.md	Tên chapter, filename, phạm vi section	Handbook và QA corpus	Đổi filename hoặc chapter title cục bộ
Template	/01-curriculum/TEMPLATE_MANIFEST.md	ID template và mục đích template khi có liên kết	/03-templates/	Tạo tên template biến thể
Định danh persistent	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Chuỗi ID nguyên dạng, trạng thái đăng ký	Artifact, QA, registry	Tự gọi ID minh họa là canonical
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	ID rule và tóm tắt dependency	Requirement, scenario, test basis	Chép lại rule như bản authoritative
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên data element và liên kết định nghĩa	Data mapping, API, test data	Tự định nghĩa lại kiểu, nghĩa, ownership
Nguồn ngoài	/00-research/00_SOURCE_MAP.md	Phân loại nguồn và safe use boundary	Nội dung học liệu liên quan	Gán clause, nghĩa vụ pháp lý chưa xác minh

Senior Lens

Persistent ID là định danh giữ nguyên qua các lần tham chiếu, không phải nhãn mô tả tùy ý. Ví dụ CANONICAL_BUSINESS_RULES là Artifact ID của catalog; /01-curriculum/CANONICAL_BUSINESS_RULES.md là đường dẫn canonical; WRK-BR-001 là mã quy tắc xuất hiện trong scenario. Ba giá trị có chức năng khác nhau, nên không thay thế cho nhau.

Khi artifact chưa xác nhận việc đăng ký một ID scenario, phải ghi đúng mức chắc chắn. ALR-NF-20260807-001 là ID tham chiếu trong ví dụ mô phỏng; chỉ registry mới xác nhận ID có được đăng ký hay không. Cầu nối lập luận là: registry sở hữu quy tắc định danh, còn chapter chỉ tiêu thụ định danh để dạy cách liên kết.

Quick Reference

Khi cần	Tham chiếu đúng	Cách ghi trong chapter
Xác định chapter và filename	CHAPTER_MANIFEST	Giữ nguyên /02-handbook/05-business-needs-objectives-and-scope.md
Kiểm tra ID	TRACEABILITY_ID_REGISTRY	Ghi nguyên ID, nêu rõ nếu chỉ là minh họa
Đọc nội dung rule	CANONICAL_BUSINESS_RULES	Ghi ID rule, không tạo bản rule thứ hai
Đọc nghĩa dữ liệu	CANONICAL_DATA_DICTIONARY	Ghi tên data element, liên kết canonical
Kiểm tra nguồn và giới hạn trích dẫn	00_SOURCE_MAP	Không suy diễn clause hoặc nghĩa vụ chưa xác minh

Core

Ma trận truy vết (traceability matrix) nối mỗi nhu cầu nghiệp vụ với yêu cầu, quy tắc, tiêu chí chấp nhận, dữ liệu/giao diện và ca kiểm thử. Mục tiêu: chứng minh mỗi chi tiết có nguồn, có cách kiểm tra, không tự tạo bản sao nguồn chuẩn.

Loại liên kết	Ý nghĩa	ID/nguồn chuẩn phải tham chiếu	Đầu ra sử dụng
NEED	Nhu cầu nghiệp vụ cần giải quyết	TRACEABILITY_ID_REGISTRY; bản ghi NEED đã đăng ký	Mục tiêu, phạm vi, ưu tiên
REQ	Requirement, yêu cầu hệ thống hoặc nghiệp vụ	TRACEABILITY_ID_REGISTRY; yêu cầu đã đăng ký	Thiết kế, backlog, kiểm thử
BR	Business Rule, quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	Logic xử lý và điều kiện kiểm soát
AC	Acceptance Criteria, tiêu chí chấp nhận	Bản ghi REQ liên quan hoặc artifact yêu cầu canonical	Điều kiện nghiệm thu chức năng
DATA/API	Thuộc tính dữ liệu hoặc giao diện lập trình ứng dụng	CANONICAL_DATA_DICTIONARY; đặc tả API nếu đã tồn tại	Mapping dữ liệu, tích hợp, kiểm thử hợp đồng
TC	Test Case, ca kiểm thử	Registry hoặc test artifact đã đăng ký	Bằng chứng kiểm tra AC và REQ

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

flowchart TB
    NEED[NEED: Nhu cầu nghiệp vụ]
    REQ[REQ: Yêu cầu]
    BR[BR: Quy tắc nghiệp vụ]
    AC[AC: Tiêu chí chấp nhận]
    DATA[DATA/API: Dữ liệu hoặc giao diện]
    TC[TC: Ca kiểm thử]

    NEED -->|truy vết tới| REQ
    BR -->|quy tắc cho| REQ
    REQ -->|tiêu chí cho| AC
    REQ -->|liên kết dữ liệu/giao diện| DATA
    REQ -->|được kiểm tra bởi| TC
    AC -->|được kiểm tra bởi| TC
    BR -->|được kiểm tra bởi| TC
    DATA -->|được kiểm tra bởi| TC

Applied

Mục bắt buộc	Nội dung case Nova Foods
Facts	Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp. Seed hiện có xác nhận các registry canonical, nhưng không cung cấp bản ghi NEED, REQ, BR, AC, DATA/API hoặc TC cụ thể cho nghiệp vụ ERP.
Current Behavior	Không có ID nghiệp vụ Nova Foods cụ thể được phép suy ra từ tên artifact. IN_REVIEW, v0.9.0, ngày 2026-08-07 không tạo requirement hay approval.
Underlying Need	Người học cần biết nối đúng loại bản ghi, không viết lại quy tắc trong bảng scope hoặc tự tạo ID để làm ví dụ có vẻ hoàn chỉnh.
Options	(1) Tự đặt ID Nova Foods. (2) Dùng ID placeholder. (3) Chỉ ghi loại liên kết, nguồn canonical và trạng thái thiếu bản ghi.
Decision Criteria	Phải giữ ID ổn định; không bịa dữ liệu; không biến kế hoạch curriculum thành quyết định ERP; mỗi liên kết phải truy được nguồn chuẩn.
Decision	Chọn phương án 3. Chưa có bản ghi canonical thì ghi Chưa có bản ghi được đăng ký trong seed hiện hành, không tạo NEED/REQ/BR/AC/DATA/API/TC mới.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner, Architect, QA, Legal, Accounting hoặc Security xác nhận nội dung thuộc thẩm quyền tương ứng.
Artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	ID tự đặt làm đứt truy vết, TC có thể kiểm thử sai REQ, BR bị nhân bản mâu thuẫn, và người đọc hiểu nhầm case mô phỏng thành cấu hình ERP thật.

Senior Lens

Liên kết không phải nội dung thay thế. CANONICAL_BUSINESS_RULES giữ văn bản BR; bảng truy vết chỉ giữ ID BR và quan hệ với REQ. CANONICAL_DATA_DICTIONARY giữ định nghĩa trường dữ liệu; bảng truy vết chỉ chỉ ra REQ nào dùng dữ liệu đó. Bằng chứng là mỗi artifact đã được định danh riêng trong seed; suy ra chép nội dung sang nhiều nơi sẽ tạo nhiều nguồn có thể mâu thuẫn.

Một REQ không có AC thì chưa có điều kiện kiểm tra rõ. Một AC không có TC thì chưa có bằng chứng kiểm tra dự kiến. Một REQ liên quan dữ liệu hoặc tích hợp mà thiếu DATA/API link thì Architect và QA không biết phạm vi mapping hoặc hợp đồng giao diện cần xem xét. Đây là khoảng trống truy vết, không được lấp bằng giả định Nova Foods.

Quick Reference

Kiểm tra	Đạt khi
NEED đến REQ	REQ tham chiếu đúng NEED đã đăng ký
REQ đến BR	Có link BR khi REQ bị ràng buộc bởi quy tắc
REQ đến AC	AC diễn đạt kết quả quan sát được
REQ đến DATA/API	Có link khi REQ đọc, ghi, truyền hoặc xác thực dữ liệu
AC đến TC	TC kiểm tra từng điều kiện AC áp dụng
ID	Giữ nguyên ID từ /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tự đặt hoặc đổi dạng

Core

Lan truyền thay đổi là chuỗi tác động khi nguồn phụ thuộc đổi. Một thay đổi chỉ an toàn khi artifact phụ thuộc được nhận diện, đánh giá và cập nhật nhất quán. Lý do: requirement, business rule, dữ liệu, API và test không tự đồng bộ.

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

flowchart TB
    A["Nguồn canonical đổi<br/>CANONICAL_DATA_DICTIONARY"] --> B["Phân tích tác động"]
    B --> C["Requirement, business rule,<br/>dữ liệu, API và test phụ thuộc"]
    C --> D["Đánh giá và cập nhật artifact"]
    D --> E["Ghi nhận version, lịch sử thay đổi<br/>và artifact bị ảnh hưởng"]
    E --> F{"Artifact phụ thuộc đã được nhận diện,<br/>đánh giá, cập nhật nhất quán<br/>và ghi nhận thay đổi?"}
    F -->|Có| G["Review có ghi nhận"]
    F -->|Không| H["Rủi ro thay đổi im lặng"]
    H --> I["API có thể truyền đúng JSON<br/>nhưng sai ý nghĩa nghiệp vụ"]
    H -. "Phân tích và cập nhật lại" .-> B

Thay đổi im lặng là sửa nội dung, ý nghĩa, trạng thái hoặc liên kết của dependency nhưng không ghi nhận version, lịch sử thay đổi hay danh sách artifact bị ảnh hưởng. Đây là lỗi quản trị, không phải lỗi định dạng. Ví dụ, nếu định nghĩa logic của trường dữ liệu đổi nhưng API vẫn dùng nghĩa cũ, hệ thống có thể truyền đúng JSON nhưng tạo kết quả nghiệp vụ sai.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng, chỉ dùng dữ liệu tổng hợp. /01-curriculum/CANONICAL_DATA_DICTIONARY.md đổi diễn giải một thuộc tính lô hàng từ “ngày nhận hàng” thành “ngày sản xuất”.

Current Behavior: Một đặc tả API, acceptance criteria và test case đang kiểm tra thuộc tính này theo nghĩa “ngày nhận hàng”. Các artifact vẫn liên kết tới cùng nguồn canonical nhưng không được rà tác động.

Underlying Need: Giữ cùng một nghĩa dữ liệu xuyên suốt nghiệp vụ, tích hợp và kiểm thử. Bằng chứng: data dictionary là nguồn định nghĩa logic; artifact sau nó chỉ được tham chiếu, không tự tạo nghĩa cạnh tranh.

Options:

Phương án	Hệ quả
Sửa data dictionary im lặng	API, test và báo cáo có thể diễn giải khác nhau
Giữ nghĩa cũ trong artifact phụ thuộc	Tạo hai nguồn chân lý
Ghi nhận thay đổi, rà tác động, cập nhật artifact phụ thuộc	Giữ traceability và phát hiện điểm cần quyết định

Decision Criteria: Chọn phương án bảo toàn source of truth, giữ lịch sử thay đổi, nêu rõ artifact bị ảnh hưởng và không tự xác nhận quyết định nghiệp vụ.

Decision: Dùng phương án ghi nhận thay đổi và rà tác động. Không sao chép định nghĩa dữ liệu sang artifact phụ thuộc; chỉ cập nhật tham chiếu và nội dung cần đổi theo nguồn canonical.

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

Artifact: Ghi thay đổi tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; đối chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md; kiểm tra liên kết trong /02-handbook/05-business-needs-objectives-and-scope.md. Status hiện hành: IN_REVIEW; Version: v0.9.0; ngày: 2026-08-07.

Consequence if Wrong: Báo cáo có thể gán sai tuổi lô; API có thể gửi dữ liệu hợp lệ về cấu trúc nhưng sai nghĩa; AC và TC có thể cùng “pass” trên giả định sai. Sai lệch này khó phát hiện vì mỗi artifact riêng lẻ vẫn có vẻ hợp lý.

Senior Lens

Không sửa im lặng dependency đã được tham chiếu. Thay đổi nhỏ về tên trường, đơn vị, định nghĩa, trạng thái, quyền truy cập hoặc điều kiện rule đều phải coi là thay đổi ngữ nghĩa cho đến khi có bằng chứng ngược lại.

Quy tắc rà tác động: bắt đầu từ nguồn canonical đổi, tìm toàn bộ liên kết đi xuống, rồi kiểm tra từng artifact xem nó dùng giá trị, định nghĩa, hay quyết định từ nguồn đó. Lý do: đổi nhãn có thể chỉ ảnh hưởng hiển thị; đổi định nghĩa có thể phá nghiệp vụ và kiểm thử.

Không dùng IN_REVIEW như bằng chứng nội dung ổn định. IN_REVIEW cho biết artifact đang được xem xét; không cho biết requirement, rule, data definition hay API contract đã baseline hoặc được phê duyệt.

Quick Reference

Dependency đổi im lặng	Thứ có thể hỏng	Dấu hiệu sớm	Hành động tối thiểu
Data dictionary	Mapping API, báo cáo, kiểm thử dữ liệu	Cùng trường nhưng mô tả khác nhau	Rà artifact dùng định nghĩa trường
Business rule catalog	Điều kiện xử lý, AC, TC	Test pass nhưng kết quả nghiệp vụ bị tranh cãi	Đối chiếu rule với AC và test basis
ID registry	Liên kết traceability	ID trỏ sai hoặc không truy ra nguồn	Khôi phục ID canonical, ghi nhận tác động
Template manifest	Cấu trúc artifact đầu ra	Template yêu cầu trường không còn nguồn	Đồng bộ tham chiếu, không tự tạo nguồn mới

10. Common Mistakes & Anti-patterns

Core

Sai lầm phổ biến là viết mục tiêu như khẩu hiệu, biến nhu cầu thành giải pháp sớm, hoặc để phạm vi không có ranh giới kiểm tra được. Người mới thường ghi “ERP phải nhanh, dễ dùng, hỗ trợ kho” nhưng không nêu người dùng, quyết định nghiệp vụ, kết quả đo được, điều kiện bắt đầu và kết thúc. Delivery team sau đó tự điền giả định; phạm vi phình ra hoặc build sai vấn đề.

Sai lầm	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Mục tiêu không đo được	Có từ “tối ưu”, “nhanh”, “hiệu quả” nhưng không có kết quả cần đổi	Nhầm mục tiêu với mong muốn	Viết lại theo kết quả nghiệp vụ, đối tượng hưởng lợi, chỉ số và mốc đo
Nêu giải pháp trước nhu cầu	“Cần màn hình mới” xuất hiện trước mô tả vấn đề	Team bị neo vào hệ thống quen thuộc	Hỏi “quyết định nào đang bị cản trở?”; ghi nhu cầu trước, giải pháp là option
Phạm vi chỉ có in-scope	Không có điều bị loại trừ	Sợ từ chối yêu cầu hoặc chưa chốt ranh giới	Thêm out-of-scope, interface bị ảnh hưởng và điểm handoff
Gom nhiều vấn đề vào một need	Một câu chứa kho, bán hàng, kế toán và báo cáo	Muốn giảm số lượng artifact	Tách theo outcome; mỗi need phải có kiểm tra độc lập
Dùng số liệu tổng hợp như dữ kiện thật	Ví dụ Nova Foods bị ghi như vận hành đã xác nhận	Không phân biệt case học liệu với evidence	Gắn nhãn “mô phỏng giáo dục, dữ liệu tổng hợp”; yêu cầu evidence thật trước delivery
Sửa scope không rà tác động	Scope statement đổi nhưng AC, process và test basis không đổi	Không có bước impact check	Rà toàn bộ artifact liên kết trước khi phát hành bản sửa

Cảnh báo: Scope sai có thể tạo build sai, test sai và chi phí sửa muộn. Với Nova Foods mô phỏng, chỉ được sửa artifact học liệu và liên kết của nó; không diễn giải ví dụ thành chỉ dẫn vận hành, kế toán, pháp lý hoặc production.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Nhóm ghi business need: “Triển khai dashboard tồn kho để giảm hết hàng.”

Current Behavior: Nhân viên kho xem số lượng theo vị trí; bộ phận bán hàng hỏi tồn kho qua trao đổi thủ công. Câu mô tả không nêu loại hàng, thời điểm cần quyết định, người chịu tác động, hay cách nhận biết “hết hàng” đã giảm.

Underlying Need: Bộ phận bán hàng cần thấy thông tin tồn kho đủ tin cậy để quyết định có nhận đơn hay không. Suy luận này dựa trên hành vi hỏi kho thủ công; dashboard chỉ là một cách đáp ứng, không phải nhu cầu tự thân.

Options: Giữ trao đổi thủ công có biểu mẫu chuẩn; cung cấp báo cáo tồn kho định kỳ; hoặc cung cấp màn hình tra cứu tồn kho gần thời gian thực.

Decision Criteria: Độ kịp thời cho quyết định nhận đơn; khả năng truy ra nguồn dữ liệu; phạm vi dữ liệu cần hiển thị; tác động đến quy trình kho; chi phí và rủi ro delivery.

Decision: Chưa chọn option. Viết need trung lập: “Cung cấp thông tin tồn kho theo mặt hàng và vị trí cho người có quyền, phục vụ quyết định nhận đơn.” Lý do: facts hiện có chứng minh điểm đau trao đổi thủ công, chưa chứng minh dashboard là phương án tốt nhất.

Authority: Không có quyết định nghiệp vụ, baseline hoặc approval được ghi nhận tại IN_REVIEW v0.9.0. Business Owner và các vai trò có thẩm quyền mới quyết định option cho delivery.

Artifact: Cập nhật business needs và scope statement trong /02-handbook/05-business-needs-objectives-and-scope.md; giữ nhãn Nova Foods mô phỏng, dữ liệu tổng hợp.

Consequence if Wrong: Nếu khóa “dashboard” thành need, team có thể build giao diện mới nhưng vẫn dùng dữ liệu trễ hoặc sai phạm vi. Quyết định nhận đơn không cải thiện dù output kỹ thuật được bàn giao.

Senior Lens

Senior BA tách ba lớp: problem là điều đang cản trở; need là khả năng cần có để xử lý problem; solution là cách cụ thể để tạo khả năng đó. Tách lớp giúp so sánh option công bằng và ngăn delivery team biến công nghệ quen thuộc thành yêu cầu bắt buộc.

Recovery an toàn bắt đầu bằng việc đóng băng thay đổi triển khai liên quan phần scope chưa rõ. Sau đó thay câu khẳng định bằng fact có nguồn, xác định câu hỏi chưa được trả lời, rồi rà artifact phụ thuộc. Không xóa lịch sử để làm tài liệu “sạch”; giữ bản ghi thay đổi để người đọc biết quyết định nào còn đang xem xét.

Quick Reference

Kiểm tra trước khi phát hành	Đạt khi
Need có nêu outcome	Người đọc biết khả năng nào cần có và vì sao
Goal có thể đo	Có chỉ số, đối tượng và thời điểm đánh giá
Scope có ranh giới	Có in-scope, out-of-scope và handoff
Solution không giả dạng need	Có ít nhất một option khác có thể đáp ứng cùng need
Ví dụ Nova Foods an toàn	Ghi rõ mô phỏng giáo dục, dữ liệu tổng hợp
Trạng thái được diễn giải đúng	IN_REVIEW không bị gọi là baseline hoặc approval

Core

Cảnh báo chỉ dùng khi sai sót có thể làm sai quyết định, mất khả năng kiểm soát thay đổi, tạo dữ liệu ERP không tin cậy, hoặc khiến nhóm diễn giải nội dung mô phỏng thành nghĩa vụ pháp lý hay quyết định vận hành. Cảnh báo không dùng cho lỗi trình bày nhỏ. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi số liệu, vai trò và dữ liệu dưới đây là tổng hợp.

[!WARNING] Rủi ro thật: đưa giả định thành quyết định đã có thẩm quyền. Câu “Finance đã chấp thuận ngưỡng chặn đơn hàng 50.000.000 VND” gây rủi ro nếu artifact không có bằng chứng quyết định, người có thẩm quyền và tham chiếu kiểm soát. IN_REVIEW tại v0.9.0 không phải APPROVED hay BASELINED.

Applied

Trường	Nội dung
Facts	Bản nháp nhu cầu ERP ghi: “Đơn bán vượt 50.000.000 VND phải bị chặn.” Không có nguồn quyết định, ngày hiệu lực, vai trò quyết định, hoặc tiêu chí ngoại lệ.
Current Behavior	Nhóm cấu hình chặn mọi đơn vượt ngưỡng dựa trên câu viết này.
Underlying Need	Cần kiểm soát rủi ro tín dụng trước khi giao hàng, không phải mặc định chặn theo một số tiền chưa được xác nhận.
Options	1. Giữ chặn cứng 50.000.000 VND. 2. Ghi là giả định dự án và chưa cấu hình. 3. Chuyển vấn đề cho Business Owner và Accounting Owner xác định chính sách mô phỏng.
Decision Criteria	Có nguồn quyết định; vai trò có thẩm quyền; phạm vi khách hàng; điều kiện ngoại lệ; ảnh hưởng đơn đang xử lý; khả năng truy vết đến artifact kiểm soát.
Decision	Chọn phương án 2 và 3. Không cấu hình quy tắc. Gắn nhãn Verification required cho ngưỡng và ngoại lệ.
Authority	Business Owner quyết định chính sách nghiệp vụ mô phỏng; Accounting Owner xác nhận ảnh hưởng kế toán. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết, không thay thế hai thẩm quyền này.
Artifact	Tham chiếu CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY; giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Đơn hợp lệ có thể bị giữ sai; nhóm hiểu sai đây là chính sách đã phê duyệt; cấu hình ERP mô phỏng bị dùng làm bằng chứng thẩm quyền không tồn tại.

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

flowchart TB
    Start([Bản nháp nhu cầu]) --> Review["Kiểm soát tài liệu<br/>IN_REVIEW · v0.9.0 · 2026-08-07"]
    Review --> Verify["Verification required<br/>Thiếu bằng chứng hoặc thẩm quyền"]

    Verify -->|Quyết định hiện tại| Boundary["Ranh giới phục hồi an toàn<br/>Dừng cấu hình<br/>Giữ bản nháp, nhãn và lịch sử<br/>Ghi tác động chưa quyết định<br/>Không đặt APPROVED<br/>Không tạo quyết định hồi tố"]

    Boundary --> Risk["Rủi ro cần tránh<br/>Giữ sai đơn hợp lệ<br/>Biến cấu hình ERP thành bằng chứng thẩm quyền giả"]
    Boundary -->|Chuyển đúng vai trò| Authority{"Xác minh có thẩm quyền<br/>Business Owner quyết định chính sách<br/>Accounting Owner xác nhận ảnh hưởng kế toán"}

    Authority -->|Chưa quyết định hoặc thiếu xác nhận| Verify
    Authority -->|Bác bỏ ngưỡng hoặc thay đổi chính sách| NoConfig["Không cấu hình<br/>Cập nhật bản nháp và truy vết<br/>Artifact vẫn IN_REVIEW"]
    Authority -->|Xác nhận quy tắc, phạm vi, ngoại lệ<br/>và ảnh hưởng đơn đang xử lý| Recorded["Ghi nhận quyết định<br/>Cập nhật CANONICAL_BUSINESS_RULES<br/>Cập nhật TRACEABILITY_ID_REGISTRY"]

    Recorded --> Ready["Sẵn sàng cấu hình"]
    Ready --> Configure([Cấu hình quy tắc])

    Review -. "IN_REVIEW không đồng nghĩa sẵn sàng cấu hình" .-> Verify

Ranh giới phục hồi an toàn: dừng cấu hình, giữ bản nháp và nhãn Verification required, ghi rõ tác động chưa quyết định, rồi chuyển đúng vai trò. Không xóa lịch sử câu sai, không đổi trạng thái thành APPROVED, không tạo quyết định hồi tố.

Senior Lens

Ví dụ thất bại Nova Foods: BA ghi “ERP phải lưu dữ liệu truy xuất lô theo luật an toàn thực phẩm” nhưng không nêu yêu cầu nào đã được đối chiếu với nguồn hiện hành. Cầu nối suy luận: nguồn Luật An toàn thực phẩm cho bối cảnh truy xuất và thu hồi; seed quy định domain-owner và legal verification vẫn bắt buộc. Vì vậy câu trên chỉ được ghi là nhu cầu cần xác minh, không phải yêu cầu tuân thủ đã xác nhận.

[!WARNING] Rủi ro thật: triển khai kiểm soát pháp lý từ diễn giải chưa xác minh. Sai sót có thể làm hệ thống lưu thiếu, lưu thừa, hoặc áp dụng quy trình không phù hợp. Phục hồi an toàn: giữ nhu cầu ở trạng thái xác minh; Legal Owner và domain owner xác nhận diễn giải trước khi biến thành rule, cấu hình hoặc tiêu chí nghiệm thu.

Quick Reference

Dấu hiệu cần cảnh báo	Không làm	Phục hồi an toàn
Câu khẳng định “đã phê duyệt” nhưng không có tham chiếu approval	Không coi IN_REVIEW là phê duyệt	Đổi thành trạng thái thực tế, giữ bằng chứng thiếu và chuyển đúng owner
Rule có số tiền, ngày hiệu lực hoặc ngoại lệ chưa có nguồn	Không cấu hình ERP theo rule	Gắn Verification required; chờ quyết định được ghi nhận
Yêu cầu pháp lý hoặc kế toán không có xác minh chuyên môn	Không gọi là tuân thủ	Giữ phạm vi giáo dục mô phỏng; yêu cầu Legal Owner hoặc Accounting Owner xác minh
Sai sót đã lan sang tài liệu khác	Không sửa im lặng hoặc xóa lịch sử	Ghi liên kết artifact bị ảnh hưởng, sửa có truy vết, kiểm tra lại trạng thái

Core

Năm lỗi khác loại, không được gộp thành “thiếu rõ ràng”. Mơ hồ là câu có nhiều cách hiểu hợp lệ; không đầy đủ là thiếu dữ kiện bắt buộc để xây, kiểm thử hoặc quyết định; khẳng định thẩm quyền không có bằng chứng là gán approval, baseline, kết luận pháp lý hoặc quyết định vận hành cho người hay artifact không được ghi nhận; dùng sai ký pháp là gọi sai loại sơ đồ hoặc suy diễn nghĩa không thuộc chuẩn; đứt traceability là không nối được nhu cầu, requirement, rule, thiết kế và kiểm thử bằng ID 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”, “duyệt đúng”, “tồn kho thấp” không có ngưỡng, chủ thể, thời điểm	Viết theo cảm nhận, không hỏi điều kiện biên	Tách thành actor, trigger, dữ liệu, điều kiện, kết quả đo được
Không đầy đủ	Requirement có màn hình nhưng thiếu dữ liệu đầu vào, lỗi, ngoại lệ, acceptance criteria	Nhầm mô tả happy path là đủ	Liệt kê luồng chính, lỗi, dữ liệu bắt buộc, rule, owner quyết định
Khẳng định thẩm quyền không có bằng chứng	“đã Legal duyệt”, “đã baseline”, “theo luật phải” nhưng không có tham chiếu kiểm soát	Nhầm owner tài liệu với người phê duyệt	Đổi thành Verification required; ghi đúng vai trò cần xác nhận
Dùng sai ký pháp	Sơ đồ PlantUML activity được gọi BPMN; mũi tên không có nghĩa rõ	Chọn công cụ trước khi chọn notation	Gọi đúng tên sơ đồ; đối chiếu BPMN 2.0.2 hoặc UML 2.5.1 khi tuyên bố dùng chuẩn
Đứt traceability	Requirement không có ID nguồn; test case không chỉ ra requirement hay rule	Sao chép nội dung giữa file, bỏ registry	Liên kết ID canonical; sửa tại nguồn canonical, không tạo bản sao cạnh tranh

[!WARNING] Rủi ro thật: gọi IN_REVIEW là “đã phê duyệt” có thể khiến delivery team build theo quyết định chưa tồn tại. Trong corpus Nova Foods mô phỏng, v0.9.0 ngày 2026-08-07 chưa có baseline hay approval reference. Biên phục hồi an toàn: dừng mọi kết luận approval, giữ trạng thái IN_REVIEW, mở mục xác minh cho vai trò có thẩm quyền.

Applied

Facts: Nova Foods là case mô phỏng, dữ liệu tổng hợp. Draft ghi: “Hệ thống tự khóa lô sắp hết hạn và Finance đã duyệt quy tắc này.” Không có ngưỡng “sắp hết hạn”, múi giờ đánh giá, phạm vi lô, ID rule, bằng chứng Finance approval hay baseline reference.

Current Behavior: Dev hiểu “sắp hết hạn” là 30 ngày; QA hiểu 7 ngày; kho hiểu chỉ lô xuất bán. Ba cách hiểu cùng hợp lệ vì câu draft không ràng buộc nghĩa.

Underlying Need: Cần xác định điều kiện chặn giao dịch theo lô, phạm vi nghiệp vụ, nguồn rule và người có quyền quyết định. Đây không phải lúc BA tự đặt ngưỡng.

Options: (1) Chọn 30 ngày theo giả định; (2) Ghi Verification required, tạo câu hỏi quyết định và liên kết artifact canonical; (3) Gọi draft là quy định pháp lý hoặc approval Finance.

Decision Criteria: Có bằng chứng nguồn; đúng owner nghiệp vụ; đủ điều kiện kiểm thử; không biến giả định thành quyết định; không vượt thẩm quyền.

Decision: Chọn (2). Viết lại: “Ngưỡng cảnh báo hoặc chặn giao dịch theo hạn dùng lô: Verification required. Cần Business Owner và Quality/Food-safety Owner mô phỏng xác định phạm vi giao dịch, ngưỡng ngày, ngoại lệ và thời điểm đánh giá.” Không gắn ID mới khi registry chưa cấp.

Authority: Principal IT Business Analyst / Technical Curriculum Author chỉ giữ traceability và nhãn xác minh. Business Owner, Quality/Food-safety Owner và vai trò pháp lý phù hợp mới xác nhận nội dung thuộc thẩm quyền họ. Luật An toàn thực phẩm là nguồn ngữ cảnh truy xuất/thu hồi; không đủ để BA tự suy ra ngưỡng ERP.

Artifact: Ghi liên kết tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và /01-curriculum/CHAPTER_MANIFEST.md; giữ nguyên trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Cấu hình chặn sai có thể ngăn xuất hàng hợp lệ hoặc cho phép giao dịch trái quyết định nghiệp vụ chưa được xác nhận. Không được gọi đây là lỗi tuân thủ pháp lý khi chưa có xác minh Legal Owner.

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

flowchart TB
    A[Draft: ngưỡng cảnh báo/chặn theo hạn dùng lô] --> B{Đủ phạm vi giao dịch,<br/>ngưỡng ngày, ngoại lệ,<br/>thời điểm đánh giá?}

    B -- Không --> C[Giữ Verification required]
    C --> D[BA ghi câu hỏi, traceability<br/>và nhãn xác minh]
    D --> E[Chuyển Business Owner và<br/>Quality/Food-safety Owner mô phỏng]
    E --> F[Owner xác định phạm vi giao dịch,<br/>ngưỡng ngày, ngoại lệ,<br/>thời điểm đánh giá]
    F --> G{Có quyết định owner<br/>và nguồn xác minh?}

    B -- Đủ thông tin --> G
    G -- Không --> C
    G -- Có --> H[BA cập nhật draft theo<br/>quyết định và nguồn xác minh]

    H --> I{Registry đã cấp ID?}
    I -- Có --> J[Liên kết ID registry và<br/>artifact canonical]
    I -- Chưa --> K[Không gắn ID mới;<br/>liên kết artifact canonical]
    J --> L[Giữ liên kết TRACEABILITY_ID_REGISTRY,<br/>CANONICAL_BUSINESS_RULES và<br/>/01-curriculum/CHAPTER_MANIFEST.md]
    K --> L

    L --> M[Artifact: IN_REVIEW<br/>v0.9.0 · 2026-08-07]

    N[Luật An toàn thực phẩm:<br/>ngữ cảnh truy xuất/thu hồi] -. không đủ suy ra ngưỡng ERP .-> E
    O[Chỉ Legal Owner phù hợp<br/>xác minh nội dung pháp lý] -. chưa xác minh: không gọi lỗi tuân thủ .-> C

    P[Không biến giả định thành quyết định] -. tránh .-> Q[Risk: chặn xuất hàng hợp lệ<br/>hoặc cho phép giao dịch trái quyết định<br/>nghiệp vụ chưa được xác nhận]
    C -. chưa có quyết định owner .-> Q

Senior Lens

Không dùng câu “Finance đã duyệt” nếu artifact chỉ ghi Owner là Principal IT Business Analyst / Technical Curriculum Author. Evidence bridge: metadata của 00_SOURCE_MAP, CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY và CANONICAL_BUSINESS_RULES đều nêu IN_REVIEW không đồng nghĩa APPROVED hoặc BASELINED; vì vậy mọi claim ngược lại là unsupported authority claim.

Không sửa traceability bằng cách chép rule vào requirement. Bản chép tạo hai nguồn chân lý. Giữ requirement tham chiếu ID canonical sau khi ID tồn tại; nếu chưa tồn tại, ghi khoảng trống xác minh thay vì tự tạo rule. Không gọi activity diagram là BPMN. BPMN 2.0.2 là nguồn chuẩn cho BPMN; UML 2.5.1 là nguồn chuẩn cho ngữ nghĩa UML.

Quick Reference

Kiểm tra trước khi chuyển giao	Đạt khi
Mơ hồ	Mỗi thuật ngữ quyết định có định nghĩa, điều kiện và kết quả
Không đầy đủ	Có luồng lỗi, ngoại lệ, dữ liệu, rule và acceptance criteria cần thiết
Thẩm quyền	Claim approval, baseline, legal, accounting hoặc compliance có bằng chứng và đúng owner
Ký pháp	Tên sơ đồ khớp notation thực dùng và nguồn chuẩn được nêu đúng
Traceability	Liên kết dùng ID canonical, không dùng tên tệp thay ID, không tạo nguồn chân lý thứ hai

11. Senior BA Notes & Rules of Thumb

Senior Lens

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Senior BA không chọn phương án “tốt nhất” chung chung. Senior BA chọn phương án có lợi ích, chi phí, rủi ro và thẩm quyền rõ trong phạm vi quyết định đang xem xét. Evidence bridge: một yêu cầu nhanh hơn có thể tăng chi phí kiểm soát; một quy tắc chặt hơn có thể giảm sai sót nhưng chặn vận hành hợp lệ. Vì vậy, recommendation phải nêu trade-off, không chỉ nêu kết quả mong muốn.

Tình huống	Trade-off cần phân tích	Ngoại lệ không áp dụng quy tắc thường	Bằng chứng tối thiểu	Người có thẩm quyền quyết định
Finance muốn khóa sửa giá bán sau khi phát hành đơn	Giảm sai giá và tranh chấp; tăng thời gian xử lý điều chỉnh	Điều chỉnh do lỗi dữ liệu hệ thống cần luồng kiểm soát riêng	Mẫu đơn tổng hợp, nhật ký lỗi mô phỏng, tác động doanh thu mô phỏng	Business Owner và Accounting Owner
Sales muốn cho phép vượt hạn mức tín dụng để giữ khách	Tăng cơ hội bán; tăng rủi ro công nợ	Khách chiến lược không tự tạo ngoại lệ; cần tiêu chí được xác định bởi owner có thẩm quyền	Báo cáo công nợ tổng hợp, giá trị đơn mô phỏng, chính sách được xác minh	Business Owner và Accounting Owner
IT muốn tích hợp đồng bộ tồn kho tức thời	Giảm độ trễ thông tin; tăng độ phức tạp, chi phí và điểm lỗi tích hợp	Không áp dụng nếu nguồn tồn kho canonical chưa xác định	Sơ đồ nguồn dữ liệu, tần suất cập nhật, lỗi đồng bộ tổng hợp	Architect và Business Owner
Legal hoặc Compliance nêu yêu cầu dữ liệu cá nhân	Giảm rủi ro xử lý dữ liệu; có thể tăng ma sát thao tác	BA không tự diễn giải nghĩa vụ pháp lý thành rule ERP	Nguồn luật chính thức, mục đích xử lý, loại dữ liệu, ý kiến Legal Owner	Legal Owner hoặc Compliance Owner

Xung đột stakeholder không phải lỗi cần “dung hòa” ngay. Đây là tín hiệu có tiêu chí quyết định chưa được làm rõ. Khi Sales nói “cần giao ngay” và Warehouse nói “chỉ giao sau kiểm đếm”, Senior BA tách hai claim: mục tiêu doanh thu và kiểm soát tồn kho. Evidence bridge: hai bên bảo vệ hai outcome khác nhau; nếu ép thành một rule mà không đo tác động, rule sẽ che giấu quyết định kinh doanh. BA ghi options, tiêu chí, dữ liệu còn thiếu và người quyết định; không tự chọn thay Business Owner.

Chất lượng evidence quyết định độ mạnh của recommendation. Quan sát một người dùng là evidence hành vi, không chứng minh quy tắc áp dụng cho toàn bộ Nova Foods. Báo cáo tổng hợp có thời gian, phạm vi và cách tính rõ là evidence mạnh hơn nhận định truyền miệng. Nguồn pháp lý chính thức chứng minh nguồn tồn tại, nhưng requirement ERP vẫn cần Legal Owner xác nhận cách áp dụng. CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY đang IN_REVIEW; chúng không chứng minh rule đã APPROVED hoặc BASELINED.

Mức evidence	Có thể kết luận	Không được kết luận
Ý kiến stakeholder không kèm dữ liệu	Có nhu cầu hoặc rủi ro cần khám phá	Quy tắc đã được chấp thuận
Dữ liệu tổng hợp có nguồn, kỳ đo và phạm vi	Có xu hướng để so sánh option	Kết quả chắc chắn trong production
Nguồn canonical có ID và owner phù hợp	Có nơi truy vết để review	Nội dung đã baseline
Xác nhận bằng văn bản từ owner đúng thẩm quyền	Quyết định được ghi nhận trong phạm vi xác nhận	Tuân thủ pháp lý hoặc triển khai production, nếu owner không có thẩm quyền đó

Senior BA dùng ngưỡng escalation khi sai quyết định có thể tạo tác động liên phòng ban, tài chính, pháp lý, bảo mật, an toàn thực phẩm hoặc kiến trúc. Escalation cũng bắt buộc khi một option yêu cầu đồng thời Business Owner, Accounting Owner, Legal Owner, Security hoặc Architect quyết định; không role nào tự thay role khác. Không áp dụng quy tắc “ưu tiên nhu cầu người dùng” khi nhu cầu đó xung đột với kiểm soát được xác minh, nguồn canonical, hoặc thẩm quyền chuyên môn bắt buộc.

Mẫu ghi recommendation defensible:

Trường	Nội dung ghi nhận
Vấn đề	Sales đề nghị cho phát hành đơn vượt hạn mức tín dụng trong case Nova Foods mô phỏng.
Facts	Dữ liệu tổng hợp cho thấy một số đơn có giá trị vượt hạn mức giả định; chưa có rule canonical được baseline.
Bất định	Chưa có xác nhận của Accounting Owner về tiêu chí ngoại lệ và hậu quả hạch toán.
Options	Chặn toàn bộ; cho phép vượt có phê duyệt; cho phép tự động theo ngưỡng.
Recommendation	Không chọn tự động theo ngưỡng trước khi có tiêu chí và owner xác nhận; phân tích tiếp option phê duyệt có kiểm soát.
Reasoning bridge	Option tự động cần rule ngưỡng; rule chưa có ID canonical và chưa có thẩm quyền accounting xác nhận.
Authority	Accounting Owner và Business Owner quyết định; BA duy trì traceability và gói quyết định.
Status	Verification required; không diễn giải là approval, baseline hoặc cấu hình production.

Senior Lens

Senior BA review không kiểm tra văn phong trước. Kiểm tra khả năng quyết định. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, mỗi business need chỉ đủ mạnh khi nối được: bằng chứng quan sát được, tác động định lượng hoặc định tính, phạm vi bị ảnh hưởng, người có thẩm quyền quyết định, và artifact nguồn. Thiếu một mắt xích thì giữ trạng thái IN_REVIEW, không nâng thành objective hay scope cam kết.

Heuristic review	Cách kiểm tra	Red flag	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Need trước solution	Viết lại nhu cầu không chứa tên ERP, màn hình, API hoặc nhà cung cấp.	“Cần thêm màn hình” nhưng không nêu vấn đề nghiệp vụ.	Solution được yêu cầu trước khi underlying need được ghi nhận.	Ràng buộc kỹ thuật đã được Architect xác nhận trong artifact có kiểm soát.
Evidence trước số liệu	Đối chiếu số liệu với báo cáo, log, mẫu giao dịch hoặc biên bản nguồn.	Một con số VND, tỷ lệ lỗi, thời gian xử lý không có nguồn và thời điểm.	Số liệu quyết định scope, ngân sách, tuân thủ hoặc ưu tiên nhưng không truy được nguồn.	Dữ liệu lịch sử chưa tồn tại; ghi rõ là project assumption, phạm vi dùng và Verification required.
Scope có biên	Nêu in-scope, out-of-scope, quy trình, tổ chức, dữ liệu và tích hợp bị ảnh hưởng.	“Áp dụng toàn công ty” không có đơn vị, quy trình, thời điểm hiệu lực.	Scope chạm từ hai domain trở lên nhưng không có owner liên domain.	Pilot được cố ý giới hạn; phải nêu tiêu chí kết thúc pilot, không gọi là rollout toàn diện.
Objective đo được	Mỗi objective có chỉ số, baseline, mục tiêu, thời hạn và owner đo lường.	Mục tiêu “tăng hiệu quả” không có cách đo.	Objective dùng để chấp nhận delivery nhưng baseline hoặc owner đo chưa xác định.	Chương trình khám phá đầu kỳ; chỉ dùng learning objective, không dùng làm cam kết lợi ích.
Authority đúng vai	Kiểm tra người đề xuất khác người quyết định nếu quyền hạn khác nhau.	BA hoặc curriculum owner tự kết luận pháp lý, kế toán, bảo mật, kiến trúc.	Quyết định có tác động pháp lý, thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm, bảo mật hoặc production.	Không có ngoại lệ. Chuyển đúng Legal Owner, Accounting Owner, Security, Architect hoặc Business Owner.
Traceability còn nguyên	Liên kết need với nguồn và artifact canonical, giữ nguyên ID, tên tệp, phân loại nguồn.	Chép nội dung sang tài liệu mới làm mất nguồn gốc hoặc đổi ID.	Hai artifact đưa kết luận khác nhau cho cùng một need.	Không có ngoại lệ; dừng hợp nhất cho đến khi nguồn canonical được xác định.

Ngưỡng dừng bắt buộc: không đưa need vào baseline, backlog cam kết hay phạm vi delivery khi có ít nhất một điều kiện sau: nguồn là ý kiến đơn lẻ nhưng ảnh hưởng nhiều bộ phận; dữ liệu tổng hợp bị trình bày như dữ liệu vận hành thật; requirement suy ra nghĩa vụ từ luật mà chưa có xác minh của legal owner; hoặc một scope change làm thay đổi quyền truy cập, lưu giữ hay truyền dữ liệu. Các nguồn như CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY đang IN_REVIEW tại v0.9.0; chúng là nguồn quản trị tham chiếu, không là bằng chứng phê duyệt hay baseline.

Quy tắc “ưu tiên nhu cầu có lợi ích lớn nhất” không áp dụng khi lợi ích lớn dựa trên số liệu không kiểm chứng, khi phương án làm tăng rủi ro an toàn thực phẩm hoặc dữ liệu cá nhân, hoặc khi chi phí cơ hội của việc trì hoãn quyết định thấp hơn chi phí sửa sai. Khi đó, Senior BA giữ need trong phạm vi khám phá, ghi rõ bằng chứng còn thiếu, owner cần xác minh, artifact cần cập nhật và điều kiện mở lại quyết định.

Senior Lens

Senior BA không biến thiếu bằng chứng thành kết luận. Khuyến nghị có thể bảo vệ phải tách rõ: fact (sự kiện có nguồn), assumption (giả định dự án), inference (suy luận từ fact), unknown (chưa biết), và decision required (quyết định cần đúng thẩm quyền). Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải baseline hay approval.

Thành phần ghi nhận	Nội dung phải viết	Cấm viết
Fact	Nguồn, ngày, người cung cấp, phạm vi quan sát	“Hệ thống hiện luôn làm như vậy” khi chỉ có một ảnh chụp màn hình
Inference	Chuỗi lập luận từ fact đến tác động	Kết luận như fact
Assumption	Điều kiện tạm dùng và tác động nếu sai	Gọi assumption là business rule
Unknown	Câu hỏi chưa có bằng chứng và người cần xác minh	Che giấu khoảng trống
Recommendation	Phương án, tiêu chí, rủi ro còn lại, authority	“BA phê duyệt”
Decision record	Quyết định, decision owner, trạng thái bằng chứng, artifact liên kết	Ghi APPROVED khi chưa có tham chiếu approval

Ví dụ artifact-ready cho nhu cầu chặn xuất kho khi lô hàng chưa có trạng thái kiểm tra chất lượng.

Trường	Ghi nhận
Decision ID	Chưa tạo ID mới; ghi nhận trong artifact quyết định đã được kiểm soát khi có ID canonical
Facts	Dữ liệu tổng hợp của Nova Foods cho thấy 3 phiếu xuất kho mô phỏng có trường QC Status trống. Không có bằng chứng xác nhận hành vi ERP hiện tại, cấu hình kho, hay rule đã được phê duyệt.
Inference	Nếu hệ thống cho xuất khi QC Status trống, kho có thể xuất lô chưa được xác nhận chất lượng. Suy luận này dựa trên ý nghĩa nghiệp vụ dự kiến của trường, không xác nhận nghĩa vụ pháp lý hay vận hành thực tế.
Unknown	“Trống” nghĩa là chưa kiểm tra, lỗi đồng bộ, hay không áp dụng kiểm tra? Kho nào, loại hàng nào, và ngoại lệ nào được phép?
Options	A: chặn mọi phiếu xuất có QC Status trống. B: chỉ cảnh báo. C: chặn theo loại hàng và cho phép override có lý do.
Recommendation	Chọn C như giả định thiết kế để phân tích tiếp. Cân bằng kiểm soát chất lượng với nguy cơ dừng xuất kho do lỗi dữ liệu; chưa phải quyết định triển khai.
Evidence gap	Cần quy trình QC được Business Owner xác nhận, mô hình dữ liệu từ CANONICAL_DATA_DICTIONARY, và xác nhận ảnh hưởng tích hợp từ Architect. Nếu có nghĩa vụ an toàn thực phẩm hoặc truy xuất, cần Legal Owner và domain owner xác minh theo Luật An toàn thực phẩm.
Decision authority	Business Owner quyết định chính sách xuất kho; Quality Owner xác nhận tiêu chí QC; Architect xác nhận khả thi kỹ thuật; Legal Owner xác minh diễn giải pháp lý khi được kích hoạt. Senior BA ghi nhận, không thay quyền các vai trò này.
Status	IN_REVIEW; không có baseline reference, approval reference, hay production authorization.
Consequence if wrong	Chặn quá rộng làm chậm giao hàng; chặn quá hẹp làm tăng nguy cơ xuất lô chưa đủ điều kiện theo chính sách được phê duyệt sau này.

Ngôn ngữ khuyến nghị phải phản ánh độ mạnh bằng chứng. Dùng “dữ liệu tổng hợp cho thấy”, “đề xuất này phụ thuộc giả định”, “cần xác minh”, “không đủ bằng chứng để kết luận”. Không dùng “chắc chắn”, “tuân thủ”, “bắt buộc theo luật”, hoặc “đã được phê duyệt” nếu artifact nguồn không chứa xác nhận hợp lệ từ đúng authority.

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

flowchart TB
    F[Fact có nguồn] --> I[Inference ghi rõ lập luận]
    F --> U[Unknown hoặc evidence gap]
    A[Assumption và tác động nếu sai] --> I
    A --> R0[Dự thảo recommendation có điều kiện]
    I --> R0

    U --> E[Evidence gap cần xử lý]
    I --> E
    A --> E
    R0 --> E

    E --> X[Authority xử lý gap theo loại:<br/>Business Owner: chính sách<br/>Quality Owner: tiêu chí QC<br/>Architect: khả thi kỹ thuật<br/>Legal Owner và domain owner: sàng lọc nghĩa vụ pháp lý hoặc truy xuất khi được kích hoạt]
    X --> V[Evidence gap đã được xử lý;<br/>khoảng trống còn lại được ghi rõ]
    V --> R[Recommendation có điều kiện;<br/>rủi ro còn lại và hậu quả nếu quyết định sai]

    R --> DA[Decision bởi decision owner đúng thẩm quyền:<br/>Business Owner quyết định chính sách;<br/>Quality Owner, Architect xác nhận;<br/>Legal Owner xác minh khi được kích hoạt]
    DA --> O{Kết quả từ authority}

    O -->|Yêu cầu sửa| BA1[Senior BA ghi nhận;<br/>không thay quyền quyết định]
    BA1 --> IR[Giữ IN_REVIEW khi chưa có approval reference]
    IR --> E

    O -->|Từ chối| BA2[Senior BA ghi nhận;<br/>không thay quyền quyết định]
    BA2 --> DRR[Decision record: quyết định, decision owner,<br/>trạng thái bằng chứng, artifact liên kết]
    DRR --> GS[Trạng thái governance theo decision record;<br/>không mặc định IN_REVIEW hoặc APPROVED]

    O -->|Phê duyệt| AR{Có approval reference<br/>từ đúng authority?}
    AR -->|Không| IR
    AR -->|Có| BA3[Senior BA ghi nhận;<br/>không thay quyền quyết định]
    BA3 --> DRA[Decision record: quyết định, decision owner,<br/>trạng thái bằng chứng, artifact liên kết]
    DRA --> AP[APPROVED theo approval reference hợp lệ]

Khuyến nghị phòng thủ được khi người đọc truy ngược được từng mệnh đề: fact nằm ở nguồn nào, inference dựa fact nào, giả định nào có thể làm đổi kết luận, ai có quyền quyết định, và hậu quả nếu chọn sai. Nếu không trả lời được một mắt xích, ghi khoảng trống; không lấp bằng kinh nghiệm cá nhân.

12. Associated Template Reference & Completed Artifact

Core

Template là biểu mẫu chuẩn để ghi nhận cùng loại thông tin theo cấu trúc lặp lại. Chương này chỉ tham chiếu template đã có ID và đường dẫn canonical. Evidence: nguồn đã cung cấp chỉ xác nhận TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md; không cung cấp ID hoặc filename template riêng cho Business Needs, Objectives and Scope. Vì vậy không được tự tạo mã như TMPL-... hoặc suy đoán tệp biểu mẫu.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. Facts: TEMPLATE_MANIFEST có trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07; chưa có baseline hay approval reference. Current Behavior: chapter ghi nhận nhu cầu, mục tiêu và scope dưới dạng handbook content. Underlying Need: cần chỉ đúng template để người dùng không nhầm handbook với artifact vận hành. Options: dùng template chưa đăng ký; dùng manifest làm điểm tra cứu; tự tạo template mới. Decision Criteria: ID canonical, filename canonical, owner, trạng thái và quality gate phải có evidence. Decision: chỉ dùng manifest làm tham chiếu hiện có; không gắn template riêng khi chưa có đăng ký. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì manifest; không có quyền tự baseline hay approval. Artifact: /01-curriculum/TEMPLATE_MANIFEST.md. Consequence if Wrong: template tự đặt tên làm đứt traceability, bị hiểu nhầm là biểu mẫu đã được phê duyệt.

Senior Lens

Không dùng TEMPLATE_MANIFEST để thay thế business case, scope statement, requirement specification hoặc quyết định Nova Foods. Nó là controlled planning artifact, nghĩa là danh mục kế hoạch có kiểm soát, không phải biểu mẫu đã hoàn thiện hay bằng chứng phê duyệt. Khi một template mới được đăng ký hợp lệ, chapter chỉ được liên kết sau khi ID, filename và mục đích dùng khớp manifest cùng version đang review.

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

flowchart TB
    C[Chapter 05] --> M[TEMPLATE_MANIFEST]
    M --> B[Danh mục kế hoạch có kiểm soát]
    B --> X[Không thay thế business case, scope statement, requirement specification hoặc quyết định Nova Foods]
    M --> I{ID và filename canonical khớp manifest?}

    I -->|Không| N[Không tạo ID hoặc filename mới]
    N --> U[Không liên kết chapter]

    I -->|Có| V{Mục đích dùng và version đang review khớp?}
    V -->|Không| U
    V -->|Có| G{Đã kiểm tra owner, consumer và quality gate?}

    G -->|Không| U
    G -->|Có| L[Liên kết chapter theo đăng ký hợp lệ]

Quick Reference

Template ID / file	Khi dùng	Khi không dùng	Owner	Consumers	Quality gate
TEMPLATE_MANIFEST — /01-curriculum/TEMPLATE_MANIFEST.md	Tra cứu template đã được đăng ký cho corpus, kiểm tra ID, đường dẫn, phạm vi và trạng thái	Không dùng như template điền nội dung business need, objective hoặc scope; không dùng làm approval record	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, template author, QA reviewer, curriculum reviewer	ID và filename phải tồn tại nguyên dạng trong manifest; status phải là IN_REVIEW; không diễn giải là baseline hoặc approval
Không có template riêng được xác minh trong source seed cho chapter này	Không áp dụng cho đến khi manifest cung cấp ID và filename canonical	Không tự tạo template ID, filename, owner hoặc quality gate từ suy đoán	Không áp dụng	Không áp dụng	Dừng liên kết template riêng nếu thiếu canonical evidence

Quy tắc dùng nhanh: giữ nguyên TEMPLATE_MANIFEST, /01-curriculum/TEMPLATE_MANIFEST.md, IN_REVIEW, v0.9.0, 2026-08-07. Không suy diễn template completed artifact từ việc manifest tồn tại.

Core

Checklist này tra cứu đủ 12 chương của /02-handbook/05-business-needs-objectives-and-scope.md. Mỗi mục xác định nơi tìm bằng chứng, không tạo nguồn chân lý mới. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07.

#	H2 canonical	Tra cứu để xác nhận
1	1. Concept l? g??	Định nghĩa business needs, objectives, scope và ranh giới thuật ngữ.
2	2. T?i sao concept n?y t?n t?i?	Vấn đề nghiệp vụ và lý do cần xác định nhu cầu trước giải pháp.
3	3. V? tr? trong Lifecycle	Điểm dùng trong vòng đời từ discovery đến delivery.
4	4. Input c?n thi?t	Nguồn đầu vào, giả định, constraint và stakeholder evidence.
5	5. Step-by-step BA Activities	Trình tự hoạt động BA để phân tích need, objective và scope.
6	6. Output thu ???c	Output, định danh và điều kiện đủ để chuyển giao.
7	7. Who consumes those outputs?	Vai trò nhận output và mục đích sử dụng.
8	8. Detailed Worked Example	Artifact Nova Foods đã điền và reasoning từ fact đến scope decision.
9	9. Related Concepts & Dependencies	Liên hệ với requirement, stakeholder, process, rule, data và traceability.
10	10. Common Mistakes & Anti-patterns	Dấu hiệu nhầm need với solution, objective với scope, hoặc assumption với fact.
11	11. Senior BA Notes & Rules of Thumb	Quy tắc quyết định, escalation boundary và senior judgment.
12	12. Associated Template Reference & Completed Artifact	Liên kết template, vị trí artifact điền sẵn và kiểm tra trước handoff.

Applied

Facts: Chapter hiện hành là /02-handbook/05-business-needs-objectives-and-scope.md; H2 8. Detailed Worked Example là vị trí artifact Nova Foods đã điền trong cùng chapter. Current Behavior: Người học có thể tìm ví dụ ở H2 8 nhưng dễ nhầm ví dụ với canonical rule hoặc template registry. Underlying Need: Cần chỉ rõ vị trí artifact mà không sao chép registry. Options: Tra cứu theo H2 trong chapter; sao chép toàn bộ TEMPLATE_MANIFEST; tạo đường dẫn artifact mới. Decision Criteria: Giữ filename canonical, không bịa template ID, không nhân bản source of truth, cho phép kiểm tra nhanh. Decision: Dùng /02-handbook/05-business-needs-objectives-and-scope.md, H2 8. Detailed Worked Example, làm location của completed Nova Foods artifact cho chapter này. Evidence: đây là H2 duy nhất blueprint định nghĩa worked example; không có dependency nào cung cấp filename completed-template riêng. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết; không có approval, baseline hay xác nhận nghiệp vụ thực tế. Artifact: Lookup checklist trong mục này. Consequence if Wrong: Trỏ sai location làm learner dùng planning manifest như artifact điền sẵn, đứt traceability và có thể suy diễn nhầm rule mô phỏng thành quyết định ERP.

Senior Lens

Không gọi H2 8 là production artifact, approved artifact hoặc baseline artifact. CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều là nguồn quản trị riêng; tra cứu khi cần kiểm tra ID, filename, rule hoặc data term. Chúng không thay thế worked example trong chapter.

Quick Reference

Mục cần tìm	Location canonical	Kết quả mong đợi
Completed Nova Foods artifact	/02-handbook/05-business-needs-objectives-and-scope.md → H2 8. Detailed Worked Example	Ví dụ đã điền cho phân tích business needs, objectives và scope.
Danh mục 26 chapter	/01-curriculum/CHAPTER_MANIFEST.md	Kiểm tra chapter ID, filename và dependency.
Danh mục template dự kiến	/01-curriculum/TEMPLATE_MANIFEST.md	Kiểm tra template có được đăng ký hay không; không coi là filled artifact.
ID truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra canonical ID trước khi tạo liên kết.
Rule catalog	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Kiểm tra nguồn rule; không tự suy diễn rule từ worked example.
Data term	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Kiểm tra nghĩa dữ liệu logic và tên canonical.

Core

Trước handoff chương, chạy self-review xuyên tệp. Mục tiêu: phát hiện mâu thuẫn giữa chapter và nguồn canonical trước khi reviewer đọc nội dung. Nova Foods là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp; IN_REVIEW tại v0.9.0, ngày 2026-08-07, không phải baseline hay phê duyệt.

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

flowchart TB
    A[Bản nháp chapter] --> B[So khớp metadata: IN_REVIEW, v0.9.0, 2026-08-07, Nova Foods mô phỏng, dữ liệu tổng hợp]
    B --> C[So khớp canonical: không đổi ID hoặc đường dẫn; không tạo alias; không suy diễn field, classification, retention, quyền truy cập; không biến rule kế hoạch thành rule vận hành]
    C --> D{Nguồn pháp lý là source seed chính thức và không cần diễn giải nghĩa vụ?}

    D -->|Có| E[Cho từng hạng mục review, ghi nhận phát hiện độc lập]
    D -->|Không hoặc cần diễn giải| H[Ghi nhận Open issue: thiếu nguồn hoặc cần diễn giải pháp lý]

    E -->|Pass| F[Pass hạng mục: không có mismatch ngoài issue đã ghi nhận]
    E -->|Verification required| G[Ghi nhận Verification required]
    E -->|Open issue| H
    E -->|Editorial mismatch| I[Principal IT Business Analyst / Technical Curriculum Author sửa theo governance metadata]
    E -->|Authority required| J[Tra governance metadata upstream và escalate đúng owner]

    I --> K[So khớp lại xuyên tệp]
    J --> L{Owner authority đã quyết định?}
    L -->|Có| K
    L -->|Chưa có| M[Ghi nhận Authority required]

    K --> E

    F --> N[Tổng hợp issue log]
    G --> N
    H --> N
    M --> N

    N --> O[Handoff chapter kèm issue log; không mô tả review là approval hoặc baseline]

Hạng mục review	Đối chiếu	Điều kiện pass	Kết quả hiện tại
Trạng thái, version, ngày	00_SOURCE_MAP, CHAPTER_MANIFEST, TEMPLATE_MANIFEST	Giữ đúng IN_REVIEW, v0.9.0, 2026-08-07	Pass
Case-study boundary	CHAPTER_MANIFEST, 00_SOURCE_MAP	Gọi Nova Foods là mô phỏng; chỉ dữ liệu tổng hợp	Pass
ID và filename canonical	TRACEABILITY_ID_REGISTRY, manifest liên quan	Không đổi ID, không đổi đường dẫn, không tạo alias	Verification required
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	Không diễn đạt rule kế hoạch như rule vận hành thật	Verification required
Thuật ngữ dữ liệu	CANONICAL_DATA_DICTIONARY	Không suy diễn field, classification, retention hoặc quyền truy cập	Verification required
Nguồn pháp lý Việt Nam	Source seed chính thức	Nêu giới hạn nguồn; không tự diễn giải nghĩa vụ pháp lý	Open issue
Handoff authority	Governance metadata upstream	Không gọi review là approval hoặc baseline	Pass

Applied

Facts: Section 12 chuẩn bị handoff; corpus có CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY; tất cả đang IN_REVIEW. Current Behavior: Chapter có thể tham chiếu nhiều artifact, nên sai một ID hoặc diễn đạt quá thẩm quyền sẽ lan sang template và traceability. Underlying Need: Handoff phải giữ được nguồn chân lý và biết ai quyết định từng loại sai lệch.

Options	Decision Criteria	Decision	Authority	Artifact	Consequence if Wrong
BA tự sửa mọi mismatch	Mismatch có thuộc thẩm quyền nội dung và không đổi quyết định chuyên môn	Chỉ sửa lỗi editorial, link, metadata rõ ràng	Principal IT Business Analyst / Technical Curriculum Author	Chapter draft và issue log	BA vô tình xác nhận legal, accounting, security hoặc architecture
Escalate theo domain	Mismatch chạm pháp lý, kế toán, bảo mật, kiến trúc, QA hoặc quyết định nghiệp vụ	Dùng option này cho mọi nội dung cần kết luận chuyên môn	Owner theo bảng dưới	Issue log liên kết artifact nguồn	Handoff chứa claim không được xác minh

Senior Lens

Open issue không phải lỗi bị che đi. Open issue là thông tin chưa đủ bằng chứng hoặc chưa đúng thẩm quyền để kết luận. Giữ nhãn Verification required khi evidence chỉ là source seed, abstract công khai, kế hoạch artifact, hoặc giả định dự án. Không nâng nhãn thành compliant, approved, baselined, production-ready.

ID issue	Vấn đề mở hoặc cần xác minh	Evidence/reasoning bridge	Escalation owner chính xác	Điều kiện đóng
ISS-12-001	Diễn giải nghĩa vụ bảo vệ dữ liệu cá nhân cho ERP Nova Foods	Source seed có Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP, nhưng handbook không có kết luận pháp lý được ủy quyền	Legal Owner	Legal Owner xác minh against official current text và ghi kết luận
ISS-12-002	Diễn giải kế toán, thuế, hóa đơn	Luật Kế toán và Nghị định 123/2020/NĐ-CP là nguồn chính thức, nhưng source seed yêu cầu authorized accounting/legal role xác minh	Accounting Owner; Legal Owner nếu có diễn giải pháp lý	Owner ghi phạm vi, giả định và kết luận
ISS-12-003	Data classification, access control, API security	CANONICAL_DATA_DICTIONARY là kế hoạch; OWASP là good practice, không phải xác nhận cấu hình ERP	Security	Security xác minh control và boundary mô phỏng
ISS-12-004	Kiến trúc, integration, interface ownership	Chapter không được suy diễn cấu hình hoặc integration thực tế từ case study	Architect	Architect xác minh quyết định kiến trúc hoặc giữ nhãn giả định
ISS-12-005	Testability của acceptance criteria và traceability	ISTQB CTFL là nguồn thuật ngữ; test basis cụ thể cần QA review	QA reviewer	QA reviewer xác minh criterion có thể kiểm thử
ISS-12-006	Business priority và quy tắc vận hành	CANONICAL_BUSINESS_RULES đang IN_REVIEW, không xác nhận rule thật	Business Owner	Business Owner xác nhận hoặc từ chối quyết định nghiệp vụ mô phỏng

Quick Reference

Checklist trước handoff:

• [x] Giữ IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND.
• [x] Gọi Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dữ liệu tổng hợp.
• [x] Không tuyên bố baseline, approval, compliance, production readiness hoặc user approval.
• [ ] Xác minh ID, filename, liên kết canonical với TRACEABILITY_ID_REGISTRY.
• [ ] Xác minh rule reference với CANONICAL_BUSINESS_RULES.
• [ ] Xác minh data-term reference với CANONICAL_DATA_DICTIONARY.
• [ ] Escalate ISS-12-001 đến ISS-12-006 trước khi đóng review chuyên môn.