13 Process Design Workflows And Approvals

Artifact Governance Metadata

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

1. Concept l? g??

Core

Process design là thiết kế quy trình: BA mô tả công việc đi từ sự kiện bắt đầu đến kết quả kết thúc, ai làm từng việc, dữ liệu nào được xử lý, và điều kiện nào làm luồng đi theo nhánh khác. Mục đích không phải vẽ sơ đồ đẹp. Mục đích là biến cách làm nghiệp vụ còn mơ hồ thành luồng có thể kiểm tra, xây dựng và vận hành.

Workflow là luồng công việc cụ thể trong process. Một process có thể gồm nhiều workflow. Ví dụ, process “xử lý đơn mua hàng” có workflow tạo yêu cầu mua, workflow xét duyệt, workflow phát hành đơn mua, và workflow xử lý từ chối. Process trả lời “công việc này vận hành thế nào”; workflow trả lời “các bước cụ thể chạy theo thứ tự nào”.

Approval là kiểm soát phê duyệt. Hệ thống hoặc quy trình chỉ cho phép đối tượng chuyển sang trạng thái tiếp theo khi người hoặc vai trò có thẩm quyền đưa ra quyết định hợp lệ. Approval không đồng nghĩa với thông báo. Thông báo chỉ báo tin; approval tạo quyết định có ảnh hưởng đến trạng thái, quyền tiếp tục xử lý, và bằng chứng kiểm tra sau này.

Một workflow tối thiểu cần bốn phần:

Thành phần	English term	Nghĩa từ đầu	Câu hỏi BA phải làm rõ
Người hoặc vai trò	Actor	Chủ thể thực hiện, nhận việc, hoặc quyết định	Ai được tạo, sửa, duyệt, từ chối?
Việc làm	Action	Hành động thay đổi dữ liệu hoặc trạng thái	Tạo, gửi, duyệt, từ chối, hủy hay ghi nhận gì?
Đối tượng	Object	Bản ghi nghiệp vụ bị tác động	Yêu cầu mua, đơn mua, phiếu nhập hay hóa đơn nào?
Kết quả	Outcome	Trạng thái hoặc dữ liệu sau hành động	Được gửi duyệt, được phê duyệt, bị từ chối hay bị chặn?

Luồng có ý nghĩa khi mỗi bước tạo kết quả kiểm chứng được. Ví dụ, “Quản lý xem yêu cầu” chưa đủ vì không biết dữ liệu hay trạng thái đổi gì. “Quản lý chọn Phê duyệt; yêu cầu chuyển từ PENDING_APPROVAL sang APPROVED; hệ thống ghi người duyệt và thời điểm” đủ rõ hơn vì có actor, action, object và outcome.

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

flowchart TB
    A[Quản lý chọn Phê duyệt cho yêu cầu mua]
    A --> B{Vai trò có thẩm quyền?}
    B -->|Có| C[Hệ thống chuyển yêu cầu mua từ PENDING_APPROVAL sang APPROVED]
    C --> D[Hệ thống lưu người duyệt và thời điểm duyệt]
    B -->|Không| E[Hệ thống từ chối quyết định và giữ PENDING_APPROVAL]

Ranh giới chapter này: thiết kế logic workflow và approval ở mức BA, gồm bước, trạng thái, điều kiện, vai trò, quyết định và bằng chứng cần lưu. Chapter không xác lập cấu hình ERP thực tế, ngưỡng tiền phê duyệt, quyền người dùng, sơ đồ BPMN chuẩn, điều khoản pháp lý, hay thẩm quyền kế toán của Nova Foods. Các nội dung đó cần nguồn canonical, owner có thẩm quyền và xác minh riêng trước khi dùng ngoài case mô phỏng.

Core

Workflow là luồng công việc: chuỗi hành động có thứ tự để biến một đầu vào thành kết quả. Approval là phê duyệt: quyết định của vai trò có thẩm quyền cho phép, từ chối hoặc yêu cầu xử lý lại một đối tượng theo tiêu chí xác định. Workflow không tự tạo approval; workflow chỉ đưa đúng đối tượng đến đúng người, ở đúng thời điểm.

Thuật ngữ	Nghĩa Việt	Vai trò trong mô tả quy trình
Actor	Tác nhân: người, vai trò hệ thống hoặc hệ thống thực hiện hay nhận hành động	Trả lời: ai làm?
Action	Hành động: việc actor thực hiện	Trả lời: làm gì?
Object	Đối tượng: hồ sơ, chứng từ, dữ liệu hoặc yêu cầu bị tác động	Trả lời: tác động lên cái gì?
Outcome	Kết quả: trạng thái hoặc đầu ra sau hành động	Trả lời: kết quả là gì?
Workflow	Luồng công việc	Liên kết actor, action, object, outcome theo trình tự và điều kiện
Approval	Phê duyệt	Quyết định có thẩm quyền trên object
Approver	Người phê duyệt	Actor có quyền đưa ra approval
Status	Trạng thái	Nhãn cho biết object đang ở giai đoạn nào
ERP	Enterprise Resource Planning, hệ thống hoạch định nguồn lực doanh nghiệp	Hệ thống ghi nhận và điều phối dữ liệu quy trình liên phòng ban
BA	Business Analyst, chuyên viên phân tích nghiệp vụ	Làm rõ nhu cầu, quy tắc, luồng và tiêu chí quyết định

Công thức đọc tối thiểu: Actor thực hiện Action trên Object, tạo Outcome. Nếu thiếu một thành phần, câu mô tả chưa đủ để thiết kế workflow hoặc kiểm thử. Ví dụ, câu “quản lý duyệt” thiếu object và outcome; không biết duyệt cái gì, trạng thái sau duyệt là gì, hệ thống phải làm gì.

Applied

Trong corpus Nova Foods Trading & Manufacturing mô phỏng, actor có thể là Purchasing Officer; action là “gửi yêu cầu phê duyệt”; object là “yêu cầu mua hàng”; outcome là trạng thái IN_REVIEW. Đây là ví dụ thuật ngữ với dữ liệu tổng hợp, không xác nhận quy trình ERP thực tế, quyền phê duyệt thực tế hay cấu hình production.

Thành phần	Diễn đạt kiểm tra được
Facts	Có một yêu cầu mua hàng mô phỏng cần được xem xét.
Current Behavior	Purchasing Officer gửi yêu cầu vào luồng xem xét.
Underlying Need	Phân biệt người gửi, đối tượng gửi và trạng thái nhận được.
Options	Mô tả chung “gửi duyệt”; hoặc mô tả đủ actor, action, object, outcome.
Decision Criteria	Câu phải trả lời được ai, làm gì, trên cái gì, kết quả gì.
Decision	Dùng cấu trúc bốn thành phần.
Authority	Business Owner và các vai trò có thẩm quyền xác nhận quy trình thực tế.
Artifact	Workflow description, trạng thái và quy tắc liên quan khi được lập ở artifact phù hợp.
Consequence if Wrong	Sai actor hoặc outcome làm sai quyền, trạng thái, kiểm thử và truy vết.

Senior Lens

Actor là vai trò nghiệp vụ, không mặc định là tên cá nhân. Approver là actor đặc biệt vì có thẩm quyền quyết định. Outcome không phải lúc nào cũng là “đã phê duyệt”; có thể là REJECTED, RETURNED_FOR_REWORK hoặc IN_REVIEW, nếu artifact kiểm soát sau này xác định các trạng thái đó.

Quick Reference

Mẫu câu	Dùng khi
[Actor] [Action] [Object], kết quả [Outcome].	Viết bước workflow tối thiểu
[Approver] quyết định [Approval] cho [Object] theo [Decision Criteria].	Viết điểm phê duyệt
Hệ thống đổi [Status] của [Object] sau [Action].	Viết hành vi ERP cần kiểm thử

Applied

Ví dụ tối thiểu, Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp: nhân viên kho tạo yêu cầu xuất PR-2026-00017 để cấp 120 kg đường cho lệnh sản xuất mô phỏng MO-2026-00042. Quy trình thiết kế workflow xác định ai làm gì với đối tượng nào, kết quả nào chuyển sang bước sau. Trong ví dụ này, actor là vai trò thực hiện; action là hành động; object là đối tượng bị tác động; outcome là trạng thái hoặc kết quả kiểm chứng được.

Thành phần	Giá trị mô phỏng	Lý do
Actor	Nhân viên kho; Quản lý kho	Hai vai trò tách việc tạo và quyết định duyệt.
Action	Tạo yêu cầu; kiểm tra; phê duyệt hoặc từ chối	Hành động phải làm đổi trạng thái hoặc tạo quyết định ghi nhận được.
Object	PR-2026-00017	Yêu cầu xuất là đối tượng workflow theo dõi.
Outcome	DRAFT, PENDING_APPROVAL, APPROVED, REJECTED	Trạng thái cho biết yêu cầu đang ở đâu và bước kế tiếp hợp lệ.

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

stateDiagram-v2
    [*] --> DRAFT: Nhân viên kho tạo PR-2026-00017
    DRAFT --> PENDING_APPROVAL: Nhân viên kho gửi duyệt
    PENDING_APPROVAL --> APPROVED: Quản lý kho phê duyệt
    PENDING_APPROVAL --> REJECTED: Quản lý kho từ chối
    APPROVED --> [*]
    REJECTED --> [*]

Mục	Nội dung
Facts	Yêu cầu có 120 kg đường, tham chiếu MO-2026-00042, đơn vị mô phỏng VND; không dùng dữ liệu thật.
Current Behavior	Người tạo gửi yêu cầu; Quản lý kho chọn phê duyệt hoặc từ chối.
Underlying Need	Ngăn xuất kho khi chưa có người có thẩm quyền quyết định trong case.
Options	Cho tự động duyệt; cho một vai trò quản lý kho duyệt.
Decision Criteria	Có điểm kiểm soát rõ, truy vết được người quyết định, ít bước cho ví dụ nhập môn.
Decision	Dùng một bước duyệt bởi Quản lý kho trong ví dụ mô phỏng.
Authority	Đây là quyết định học liệu, không phải thẩm quyền vận hành, kế toán, pháp lý hoặc production của Nova Foods.
Artifact	Sơ đồ trạng thái và bảng actor-action-object-outcome trong /02-handbook/13-process-design-workflows-and-approvals.md.
Consequence if Wrong	Gán sai actor có thể cho người không phù hợp duyệt; gán sai outcome có thể khiến yêu cầu bị xử lý hai lần hoặc không biết bước kế tiếp.

Ranh giới concept: chapter này nói về cách BA mô tả, phân tích và thiết kế luồng công việc cùng điểm phê duyệt: vai trò, hành động, đối tượng, trạng thái, điều kiện chuyển bước và kết quả. Workflow là chuỗi công việc; approval là quyết định có thẩm quyền cho phép, từ chối, hoặc yêu cầu xử lý lại một đối tượng.

Loại trừ: không cấu hình ERP, không chọn phần mềm workflow, không viết API, không định nghĩa quyền truy cập chi tiết, không ban hành quy tắc xuất kho thật, không xác nhận phân quyền thật, không diễn giải Luật Kế toán, Luật An toàn thực phẩm, hay nghĩa vụ pháp lý. Ngưỡng giá trị, danh sách người duyệt, thời hạn duyệt và bằng chứng tuân thủ chỉ là giả định dự án khi chưa được Business Owner, Accounting Owner, Legal Owner hoặc Compliance Owner xác minh.

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

Core

Workflow và approval tồn tại để biến công việc nhiều người thành luồng có thể hiểu, kiểm tra và truy vết. Nếu BA chỉ ghi “xuất kho cần quản lý duyệt”, đội triển khai chưa biết ai tạo yêu cầu, đối tượng nào được duyệt, trạng thái nào chặn xuất kho, ai xử lý từ chối, hay khi nào yêu cầu kết thúc. Khoảng trống này tạo ambiguity (mơ hồ): hai người cùng hiểu khác nhau nhưng đều tin mình làm đúng.

Mơ hồ gây rework (làm lại). Developer có thể xây nút “Duyệt” trên phiếu xuất; QA lại kiểm tra trạng thái đã duyệt mới cho xuất; vận hành lại mong người tạo sửa phiếu bị từ chối và gửi lại. Ba cách hiểu không cùng một workflow. Khi phát hiện muộn, thay đổi không chỉ nằm ở màn hình mà còn ảnh hưởng trạng thái, thông báo, báo cáo, quyền thao tác và test case.

Approval cũng là điểm governance (quản trị kiểm soát). Không xác định rõ authority, tức vai trò có quyền ra quyết định trong từng bước, hệ thống có thể cho phép hành động sai vai trò hoặc không lưu được quyết định cần truy vết. BA không tự gán authority từ chức danh nghe hợp lý; BA mô tả điểm cần quyết định, nêu rủi ro và chuyển xác nhận cho vai trò có thẩm quyền.

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

stateDiagram-v2
    direction TB
    [*] --> Draft
    Draft --> PendingApproval: Người tạo gửi yêu cầu
    PendingApproval --> Approved: Người duyệt quyết định duyệt
    PendingApproval --> Rejected: Người duyệt quyết định từ chối
    Rejected --> Draft: Người tạo sửa yêu cầu
    Approved --> [*]

Sơ đồ trên là state diagram mô phỏng, không phải BPMN. Giá trị của nó là buộc BA chỉ ra mọi trạng thái và chuyển trạng thái cần thiết trước khi đội kỹ thuật tự suy diễn.

Applied

Mục	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Facts	Ví dụ học liệu dùng đối tượng “yêu cầu xuất kho”. Luồng có người tạo yêu cầu và Quản lý kho thực hiện quyết định duyệt hoặc từ chối.
Current Behavior	Nếu chỉ có mô tả “Quản lý kho duyệt yêu cầu xuất kho”, không có quy định rõ về trạng thái chờ duyệt, hành động sau từ chối, hay điều kiện chặn xuất kho.
Underlying Need	Cần một luồng chung để người tạo, người duyệt, developer và QA cùng biết đối tượng đang ở đâu và hành động nào được phép.
Options	Mô tả bằng câu tự do; hoặc mô tả bằng trạng thái, transition, actor và outcome.
Decision Criteria	Giảm diễn giải khác nhau; chỉ ra điểm kiểm soát; hỗ trợ test được luồng duyệt, từ chối và gửi lại.
Decision	Trong phạm vi học liệu, mô tả workflow bằng trạng thái Draft, PendingApproval, Approved, Rejected cùng actor thực hiện từng transition.
Authority	Đây là quyết định thiết kế học liệu. Không xác nhận phân quyền, quy tắc xuất kho, kiểm soát kế toán, pháp lý hay vận hành thực tế của Nova Foods.
Artifact	/02-handbook/13-process-design-workflows-and-approvals.md ghi sơ đồ trạng thái và bảng transition cho ví dụ.
Consequence if Wrong	Developer có thể cho xuất kho khi yêu cầu còn PendingApproval; QA không có expected result chung; vận hành có thể không biết yêu cầu Rejected cần sửa hay tạo mới.

Trước khi có workflow rõ: người tạo gửi yêu cầu, Quản lý kho nói “đã xem”, kho vẫn có thể xuất hàng vì không có trạng thái hệ thống nào phân biệt “đã xem” với “đã duyệt”. Hậu quả quan sát được là cùng một yêu cầu có thể bị xử lý theo nhiều cách, và không xác định được bước tiếp theo từ dữ liệu màn hình.

Sau khi có workflow rõ: yêu cầu chỉ chuyển từ PendingApproval sang Approved hoặc Rejected bằng quyết định của actor được chỉ định trong ví dụ. Hệ thống, test case và hướng dẫn vận hành có cùng điểm kiểm tra: yêu cầu chưa Approved không đi tới bước kết thúc của luồng xuất kho mô phỏng. Hậu quả quan sát được là QA kiểm tra được từng transition, còn người dùng biết yêu cầu bị từ chối phải quay về Draft.

Senior Lens

Workflow không phải sơ đồ đẹp để trình bày. Nó là hợp đồng hiểu chung giữa nghiệp vụ và delivery: mỗi transition phải trả lời được “ai làm”, “làm gì”, “trên đối tượng nào”, “từ trạng thái nào”, “sang trạng thái nào”, và “nếu không đạt thì đi đâu”. Thiếu một câu trả lời, rủi ro vẫn còn nhưng bị che dưới câu chữ nghiệp vụ.

Approval không mặc định làm quy trình an toàn hơn. Một bước duyệt không có điều kiện, authority và dấu vết quyết định chỉ thêm chậm trễ. BA cần dùng approval khi có quyết định cần kiểm soát hoặc cần truy vết; không thêm approval chỉ vì quy trình cũ có nhiều cấp ký.

Quick Reference

Rủi ro cần ngăn	Dấu hiệu sớm	Artifact BA cần có
Mơ hồ	Các vai trò mô tả bước tiếp theo khác nhau	Sơ đồ trạng thái hoặc workflow có actor và transition
Làm lại	Developer, QA và nghiệp vụ dùng outcome khác nhau	Bảng trạng thái, điều kiện chuyển bước, expected outcome
Bỏ sót xử lý ngoại lệ	Có câu hỏi “bị từ chối thì sao?”	Nhánh từ chối, sửa, gửi lại hoặc kết thúc
Sai kiểm soát	Không rõ ai được duyệt và quyết định được lưu ở đâu	Điểm approval, authority cần xác nhận, dấu vết quyết định
Không test được	QA không xác định được kết quả từng bước	Transition có trạng thái trước, hành động và trạng thái sau

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Quy trình phê duyệt tồn tại để biến câu nói nghiệp vụ thành luồng có trạng thái, người chịu trách nhiệm, điều kiện chuyển bước và bằng chứng. Không có thiết kế này, ERP vẫn có màn hình và nút bấm nhưng không xác định rõ ai được chuyển chứng từ, lúc nào được từ chối, hoặc bản ghi nào là nguồn kiểm soát.

Trường	Nội dung case mô phỏng
Facts	Yêu cầu mua nguyên liệu có giá trị VND được tạo từ bộ phận Mua hàng. Người tạo yêu cầu cũng có thể sửa yêu cầu sau khi gửi. Chưa có trạng thái và người phê duyệt được ghi nhất quán trong cùng bản ghi.
Current Behavior	Nhân viên gửi thông tin qua email hoặc trao đổi trực tiếp. Người quản lý trả lời theo từng kênh. Mua hàng có thể tạo đơn mua khi thấy thông tin “đã đồng ý”.
Underlying Need	Cần một luồng workflow, nghĩa là chuỗi bước và trạng thái có kiểm soát, để mọi yêu cầu mua đi qua cùng điểm quyết định và lưu được dấu vết.
Options	A: Giữ email ngoài ERP. B: ERP lưu trạng thái DRAFT, PENDING_APPROVAL, APPROVED, REJECTED; chỉ người có vai trò phê duyệt mới đổi từ PENDING_APPROVAL.
Decision Criteria	Xác định được người ra quyết định; ngăn người tạo tự phê duyệt; biết yêu cầu đang ở đâu; không cho tạo đơn mua từ yêu cầu chưa được phê duyệt.
Decision	Chọn Option B cho thiết kế minh họa trong tài liệu này. Nội dung ở trạng thái IN_REVIEW, không phải cấu hình ERP hay phê duyệt vận hành.
Authority	Business Owner quyết định quy tắc nghiệp vụ; Process Owner xác nhận luồng vận hành; Architect xác nhận khả năng hệ thống; QA xác nhận hành vi kiểm thử. Chưa có xác nhận thẩm quyền được ghi nhận.
Artifact	Bản thiết kế luồng trong /02-handbook/13-process-design-workflows-and-approvals.md, liên kết quản trị với TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Nếu cho phép tạo đơn mua khi yêu cầu còn PENDING_APPROVAL, bộ phận Mua hàng có thể xử lý yêu cầu chưa qua điểm kiểm soát. Nếu không lưu người từ chối và lý do, người tạo không biết phải sửa nội dung nào.

Trước thiết kế: cùng một yêu cầu mua có thể được gọi là “đã duyệt” vì có email xác nhận, nhưng ERP không có trạng thái tương ứng. Hệ quả quan sát được: Mua hàng phải hỏi lại người quản lý, người tạo có thể sửa nội dung sau trao đổi, và người kiểm tra sau này không đối chiếu được quyết định với phiên bản yêu cầu.

Sau thiết kế: yêu cầu chỉ chuyển sang APPROVED khi người có vai trò phê duyệt thực hiện chuyển trạng thái; yêu cầu bị từ chối giữ REJECTED cùng lý do; đơn mua chỉ được tạo từ APPROVED. Hệ quả quan sát được: màn hình ERP cho biết trạng thái hiện tại, người xử lý biết bước kế tiếp, và kiểm tra có thể đối chiếu trạng thái với người thực hiện.

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

stateDiagram-v2
    direction TB

    [*] --> DRAFT
    DRAFT --> PENDING_APPROVAL: gửi yêu cầu
    PENDING_APPROVAL --> APPROVED: người phê duyệt khác người tạo chấp nhận
    PENDING_APPROVAL --> REJECTED: người phê duyệt khác người tạo từ chối và ghi lý do
    REJECTED --> DRAFT: người tạo sửa
    APPROVED: đủ điều kiện tạo đơn mua

Luồng này không đặt ngưỡng tiền, quy tắc kế toán, thuế, an toàn thực phẩm hoặc yêu cầu pháp lý. Các nội dung đó cần nguồn phù hợp và xác minh bởi chủ thể có thẩm quyền trước khi thành quy tắc vận hành.

Core

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp phải được gắn loại bằng chứng trước khi biến thành workflow, business rule hoặc cấu hình ERP. Mục đích: ngăn lời kể bị ghi nhầm thành fact, giả định bị triển khai như quyết định, hoặc yêu cầu pháp lý bị hiểu là đã xác nhận.

Loại	Định nghĩa từ đầu	Bằng chứng tối thiểu	Cách ghi artifact	Không được suy ra
Verified fact	Thông tin kiểm tra được từ nguồn xác định	URL chính thức, artifact kiểm soát, bản ghi hệ thống hoặc tài liệu có nguồn	Nêu nguồn, ngày truy cập 2026-08-07, phạm vi nguồn	Không suy ra workflow Nova Foods đang áp dụng
Stakeholder input	Ý kiến, nhu cầu hoặc mô tả của người liên quan	Người nói, vai trò, thời điểm, ngữ cảnh	Ghi nguyên ý nghĩa, không nâng thành fact	Không gọi là requirement đã phê duyệt
Project assumption	Điều tạm dùng để thiết kế khi thiếu bằng chứng	Lý do cần giả định, tác động, điều kiện kiểm tra	Gắn nhãn Project assumption	Không triển khai production như rule bắt buộc
Decision	Lựa chọn được ghi nhận giữa các phương án	Tiêu chí, authority có thẩm quyền, artifact quyết định	Ghi phạm vi, người có quyền quyết định, trạng thái	Không gọi là approval nếu không có approval reference
Verification-required claim	Nhận định có thể đúng nhưng chưa đủ bằng chứng hoặc cần chuyên gia xác nhận	Câu hỏi xác minh, owner cần xác nhận, nguồn cần kiểm tra	Gắn nhãn Verification required	Không biến thành compliance, accounting hoặc legal requirement

Applied

Trường	Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	CHAPTER_MANIFEST và CANONICAL_BUSINESS_RULES có Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07; không có baseline reference hoặc approval reference. Luật 88/2015/QH13 là nguồn pháp lý chính thức về kế toán, nhưng diễn giải kế toán cần Accounting Owner hoặc Legal Owner xác nhận.
Current Behavior	Nhân viên kho mô phỏng nói: “Phiếu xuất kho giá trị cao cần quản lý duyệt.” Đây là stakeholder input, chưa phải fact về quy trình hiện hành hay rule ERP.
Underlying Need	Kiểm soát rủi ro xuất hàng sai hoặc vượt thẩm quyền, nhưng ngưỡng giá trị, vai trò duyệt và ngoại lệ chưa có bằng chứng canonical.
Options	Ghi câu nói thành mandatory rule; ghi là project assumption để mô phỏng luồng; dừng thiết kế rule đến khi Business Owner và Accounting Owner xác minh.
Decision Criteria	Có nguồn canonical; thẩm quyền thuộc đúng vai trò; tác động đến kế toán và vận hành; khả năng kiểm thử; không biến IN_REVIEW thành approval.
Decision	Chỉ mô hình hóa bước “chờ xác minh ngưỡng duyệt” trong học liệu. Không đặt ngưỡng VND, không tạo rule bắt buộc.
Authority	Business Owner xác nhận nhu cầu nghiệp vụ; Accounting Owner xác nhận tác động kế toán; Legal Owner xác minh nghĩa vụ pháp lý nếu có; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.
Artifact	Ghi phân loại trong /01-curriculum/CANONICAL_BUSINESS_RULES.md; giữ trạng thái IN_REVIEW, Version v0.9.0.
Consequence if Wrong	Nếu stakeholder input bị ghi thành verified fact, đội ERP có thể cấu hình chặn xuất kho sai phạm vi; nếu project assumption bị gọi là decision, người dùng tưởng đã có thẩm quyền phê duyệt.

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

flowchart TD
    A["Thông tin về rule xuất kho"] --> B{"Có nguồn kiểm tra được?"}
    B -->|"Có"| C{"Nguồn canonical đã được xác nhận?"}
    B -->|"Không"| D{"Thông tin thuộc loại nào?"}

    C -->|"Có"| FACT["Verified fact"]
    C -->|"Không"| VERIFY["Verification required"]
    FACT --> BOUNDARY["Verified fact không tự tạo approval hoặc mandatory rule"]
    BOUNDARY --> AUTH{"Authority phù hợp đã ghi nhận lựa chọn?"}

    D -->|"Ý kiến người liên quan"| INPUT["Stakeholder input"]
    D -->|"Tạm dùng để thiết kế"| ASSUME["Project assumption"]
    D -->|"Chưa xác minh"| VERIFY

    INPUT --> UNRESOLVED["Chưa xác minh ngưỡng duyệt, vai trò duyệt và ngoại lệ"]
    ASSUME --> UNRESOLVED
    UNRESOLVED --> VERIFY

    VERIFY --> BO["Business Owner xác nhận nhu cầu nghiệp vụ"]
    BO --> AO["Accounting Owner xác nhận tác động kế toán"]
    AO --> LEGAL{"Có nghĩa vụ pháp lý cần xác minh?"}
    LEGAL -->|"Có"| LO["Legal Owner xác minh nghĩa vụ pháp lý"]
    LEGAL -->|"Không"| AUTH
    LO --> AUTH

    AUTH -->|"Có"| DECISION["Decision"]
    AUTH -->|"Không"| HOLD["Giữ nhãn và truy vết"]

    HOLD --> SCOPE["Phạm vi học liệu là mô hình hóa bước chờ xác minh"]
    SCOPE --> LIMIT["Không đặt ngưỡng VND và không tạo mandatory rule"]

    DECISION --> RECORD["Ghi phân loại trong CANONICAL_BUSINESS_RULES"]
    LIMIT --> RECORD
    RECORD --> STATUS["Giữ IN_REVIEW và Version v0.9.0"]
    STATUS --> NOAPPROVAL["Không ngụ ý baseline hoặc approval"]

    PITBA["Principal IT Business Analyst và Technical Curriculum Author"] -.->|"Duy trì traceability, không phê duyệt rule nghiệp vụ"| RECORD

    INPUT -.->|"Nếu gắn sai thành Verified fact"| RISK1["ERP có thể chặn xuất kho sai phạm vi"]
    ASSUME -.->|"Nếu gọi sai là Decision"| RISK2["Người dùng có thể tưởng đã có thẩm quyền phê duyệt"]

Senior Lens

Cầu nối suy luận phải hiện rõ: nguồn chính thức chỉ xác nhận nội dung trong safe use boundary; vì vậy nguồn Luật Kế toán xác nhận tồn tại văn bản pháp lý, không tự xác nhận cách Nova Foods mô phỏng phải định tuyến phê duyệt. Tương tự, IN_REVIEW xác nhận trạng thái artifact đang xem xét; không xác nhận business rule đúng, đã baseline hoặc đã được người dùng phê duyệt.

Quick Reference

Câu hỏi kiểm tra	Nhãn đúng
“Tôi đọc được điều này trong artifact hoặc nguồn xác định?”	Verified fact
“Một stakeholder vừa mô tả nhu cầu này?”	Stakeholder input
“Đội cần tạm giả định để tiếp tục phân tích?”	Project assumption
“Authority đã chọn phương án và có record?”	Decision
“Cần Business Owner, Accounting Owner, Legal Owner hoặc nguồn mới xác nhận?”	Verification required

3. V? tr? trong Lifecycle

Core

Workflow và approval design xuất hiện khi nhu cầu đã đủ rõ để biến thành luồng xử lý có kiểm soát. Lifecycle bắt đầu từ Discovery (khám phá): nhận biết vấn đề, mục tiêu và nhóm bị ảnh hưởng. Nó kết thúc ở Operations (vận hành): luồng đã phát hành được theo dõi, lỗi và thay đổi mới quay lại Discovery.

Mỗi pha có entry gate: điều kiện tối thiểu để bắt đầu; và exit gate: bằng chứng tối thiểu để chuyển pha. Gate không phải approval. Gate chỉ trả lời: đầu vào đã đủ, có thể kiểm tra, và còn điểm chưa xác minh nào không.

Pha	Entry gate	Hoạt động workflow và approval	Exit gate
Discovery	Có problem statement mô tả vấn đề mô phỏng Nova Foods; phạm vi ban đầu; dữ liệu tổng hợp	Xác định trigger, kết quả mong muốn, người dùng bị ảnh hưởng, giả định và điểm chưa xác minh	Có stakeholder input được phân biệt với verified fact; chưa gọi là rule hoặc decision
Analysis	Discovery record còn truy vết được; vấn đề không mâu thuẫn phạm vi	Mô hình hóa happy path, ngoại lệ, trạng thái, điểm quyết định, điều kiện phê duyệt và audit trail cần có	Có workflow draft; business rule, data và authority chưa xác minh giữ nhãn Verification required hoặc Project assumption
Delivery	Workflow draft có acceptance criteria kiểm tra được; dependency kỹ thuật được nhận diện	Chuyển luồng thành backlog, cấu hình ERP mô phỏng, UI, API hoặc logic; giữ liên kết từ requirement đến workflow step	Build hoặc cấu hình có thể trình diễn theo workflow draft; thay đổi thiết kế được ghi nhận, không sửa im lặng
Testing	Có test basis: workflow, rule, trạng thái, acceptance criteria; dữ liệu test tổng hợp	Kiểm tra đường đi chính, từ chối, quyền, trạng thái và bằng chứng audit. ISTQB CTFL dùng làm nguồn thuật ngữ testing, không tự tạo test case Nova Foods	Kết quả test ghi rõ pass, fail, blocked; lỗi ảnh hưởng gate được phân loại trước Release
Release	Hạng mục release xác định; test evidence có thể truy vết; ngoại lệ còn mở được hiển thị	Kiểm tra release scope khớp workflow đã test; xác định rollback hoặc xử lý lỗi theo kế hoạch delivery	Bản phát hành mô phỏng được ghi nhận; không suy diễn production approval hoặc compliance sign-off
Operations	Luồng đã release; có cách quan sát trạng thái và lỗi	Theo dõi volume, thời gian xử lý, exception, rework và phản hồi người dùng; phát hiện thay đổi nhu cầu	Vấn đề mới hoặc sai lệch tạo input Discovery mới; không tự sửa business rule trong vận hành

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

flowchart TB
    DG{Discovery entry<br/>Problem statement Nova Foods, phạm vi ban đầu, dữ liệu tổng hợp}
    D[Discovery<br/>Trigger, kết quả mong muốn, người dùng,<br/>giả định và điểm chưa xác minh]
    AG{Analysis entry<br/>Discovery record truy vết được,<br/>không mâu thuẫn phạm vi}
    A[Analysis<br/>Happy path, ngoại lệ, trạng thái,<br/>decision, approval condition, audit trail]
    DEG{Delivery entry<br/>Workflow draft có acceptance criteria kiểm tra được,<br/>dependency kỹ thuật đã nhận diện}
    DE[Delivery<br/>Backlog, cấu hình, UI, API hoặc logic;<br/>liên kết requirement với workflow step]
    TG{Testing entry<br/>Workflow, rule, trạng thái, acceptance criteria;<br/>dữ liệu test tổng hợp}
    T[Testing<br/>Đường chính, từ chối, quyền,<br/>trạng thái và audit evidence]
    RG{Release entry<br/>Release scope xác định, test evidence truy vết được,<br/>ngoại lệ mở hiển thị}
    R[Release<br/>Scope khớp workflow đã test;<br/>rollback hoặc xử lý lỗi theo delivery plan]
    OG{Operations entry<br/>Luồng đã release, có cách quan sát trạng thái và lỗi}
    O[Operations<br/>Theo dõi volume, thời gian xử lý, exception,<br/>rework và phản hồi người dùng]

    DG -->|Đủ: bắt đầu Discovery| D
    DG -->|Chưa đủ: bổ sung problem statement, phạm vi hoặc dữ liệu| DG

    D -->|Exit: stakeholder input phân biệt verified fact;<br/>chưa gọi là rule hoặc decision| AG
    AG -->|Đủ: bắt đầu Analysis| A
    AG -->|Chưa đủ: làm rõ Discovery record hoặc phạm vi| D

    A -->|Exit: có workflow draft; rule, data, authority chưa xác minh<br/>giữ nhãn Verification required hoặc Project assumption| DEG
    DEG -->|Đủ: bắt đầu Delivery| DE
    DEG -->|Chưa đủ: hoàn thiện workflow draft, criteria hoặc dependency| A

    DE -->|Exit: build hoặc cấu hình trình diễn theo workflow draft;<br/>thay đổi thiết kế được ghi nhận| TG
    TG -->|Đủ: bắt đầu Testing| T
    TG -->|Chưa đủ: bổ sung workflow, rule, trạng thái, criteria hoặc test data| DE

    T -->|Exit: kết quả pass, fail hoặc blocked;<br/>lỗi ảnh hưởng gate đã phân loại trước Release| RG
    RG -->|Đủ: bắt đầu Release| R
    RG -->|Chưa đủ: xử lý thiếu test evidence hoặc ngoại lệ mở| T

    R -->|Exit: bản phát hành mô phỏng được ghi nhận;<br/>không suy diễn production approval hoặc compliance sign-off| OG
    OG -->|Đủ: bắt đầu Operations| O
    OG -->|Chưa đủ: ghi nhận release hoặc cách quan sát trạng thái và lỗi| R

    O -->|Exit: sai lệch hoặc nhu cầu mới tạo input Discovery mới;<br/>không tự sửa business rule trong Operations| DG

Applied

Facts: Nova Foods Trading & Manufacturing là case study mô phỏng; mọi dữ liệu là tổng hợp. Một yêu cầu mô phỏng nói rằng phiếu xuất kho nguyên liệu có giá trị từ 50,000,000 VND cần bước kiểm tra bổ sung.

Current Behavior: Discovery chỉ có stakeholder input. Chưa có nguồn canonical xác nhận ngưỡng 50,000,000 VND, người có quyền xác nhận, hoặc điều kiện áp dụng cho từng loại nguyên liệu.

Underlying Need: Analysis cần mô tả luồng “tạo phiếu xuất kho, kiểm tra điều kiện, xử lý đạt hoặc không đạt” mà không biến ý kiến thành policy vận hành.

Options: Giữ một luồng không có kiểm tra bổ sung; thêm kiểm tra với ngưỡng như project assumption; hoặc dừng mô hình điều kiện cụ thể và ghi Verification required.

Decision Criteria: Chỉ chuyển từ Analysis sang Delivery khi điều kiện, trạng thái đầu ra và acceptance criteria có thể kiểm tra. Nếu ngưỡng hoặc authority chưa có nguồn, workflow không được mô tả như rule Nova Foods đã xác nhận.

Decision: Dùng nhánh kiểm tra bổ sung trong workflow draft với nhãn Project assumption; giữ ngưỡng 50,000,000 VND là dữ liệu tổng hợp cần xác minh trước Delivery.

Authority: Không có decision authority được ghi nhận trong micro-batch này. Business Owner và các owner chuyên môn liên quan phải xác nhận nội dung thuộc thẩm quyền của họ trước khi gọi là decision hoặc approval.

Artifact: Workflow draft liên kết CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY và /02-handbook/13-process-design-workflows-and-approvals.md; trạng thái corpus IN_REVIEW, Version v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Nếu stakeholder input bị đưa qua Delivery như verified rule, ERP mô phỏng có thể chặn xuất kho sai; test có thể pass một hành vi không được authority xác nhận; Release record có thể bị hiểu nhầm là approval.

Senior Lens

Không phải mọi pha đều cần workflow hoàn chỉnh. Discovery cần đủ thông tin để biết có nên phân tích luồng; Analysis cần đủ chi tiết để thiết kế; Delivery cần luồng kiểm tra được; Testing cần bằng chứng đối chiếu; Release cần phạm vi đã test; Operations cần tín hiệu để phát hiện sai lệch. Cầu nối suy luận là: workflow kiểm soát chuyển trạng thái, nên thiếu trigger, điều kiện hoặc kết quả sẽ làm test không xác định được expected result. Vì vậy thiếu một phần này thì không qua exit gate Analysis.

Quick Reference

Gate	Câu hỏi quyết định
Vào Discovery	Có vấn đề hoặc cơ hội mô tả được không?
Ra Discovery	Đã phân biệt fact, input, assumption và verification required chưa?
Vào Analysis	Có vấn đề, phạm vi ban đầu và trigger chưa?
Ra Analysis	Luồng, ngoại lệ, trạng thái và criteria có kiểm tra được chưa?
Vào Delivery	Có testable workflow draft chưa?
Ra Delivery	Có bản thực thi bám workflow draft chưa?
Vào Testing	Có test basis và dữ liệu tổng hợp chưa?
Ra Testing	Có test evidence và lỗi được ghi nhận chưa?
Vào Release	Phạm vi phát hành có khớp nội dung đã test chưa?
Ra Operations	Có release record, theo dõi trạng thái và cơ chế nhận sai lệch chưa?

Core

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, mỗi bàn giao phải có người gửi, người nhận, artifact nhận bàn giao và giới hạn quyền quyết định. Lý do: workflow chỉ chuyển được sang vai trò kế tiếp khi đầu ra có chủ sở hữu; BA không được tự biến ý kiến thành quyết định nghiệp vụ, pháp lý, kế toán, bảo mật hay kiến trúc.

Điểm bàn giao	Upstream owner	Artifact bàn giao	Downstream owner	Quyền downstream	Escalation
Nhu cầu quy trình/approval	Business Owner	Nhu cầu, vấn đề, mục tiêu mô phỏng	BA	Làm rõ phạm vi, ghi giả định	Mục tiêu mâu thuẫn hoặc vượt ngân sách giả định: Business Owner
Thiết kế luồng và rule	BA	Workflow, decision log, traceability	Solution Architect, Security Owner	Đánh giá khả thi kỹ thuật, bảo mật	Thay đổi tích hợp, phân quyền, dữ liệu nhạy cảm: Architect hoặc Security Owner
Cấu hình/xây dựng	Solution Architect, Delivery Lead	Thiết kế được review, backlog	Delivery team	Xây dựng trong phạm vi đã ghi	Thiếu quyết định rule hoặc thay đổi phạm vi: BA và Business Owner
Kiểm thử	Delivery team	Build, cấu hình, release note nội bộ	QA Lead	Kiểm thử theo acceptance criteria	Lỗi làm sai rule, số tiền VND mô phỏng, quyền approval: Business Owner và BA
Phát hành	QA Lead, Release Manager	Kết quả kiểm thử, rủi ro còn lại	Operations Owner	Quyết định vận hành trong thẩm quyền được giao	Rủi ro production, rollback, dữ liệu: Release Manager và Operations Owner
Vận hành/cải tiến	Operations Owner	Incident, phản hồi người dùng, số liệu vận hành mô phỏng	BA, Business Owner	Đề xuất thay đổi, không tự đổi rule	Ảnh hưởng pháp lý, kế toán, an toàn thực phẩm: owner chuyên môn phù hợp

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

flowchart TB
    BO[Business Owner]
    BA["BA<br/>Làm rõ phạm vi, ghi giả định<br/>Đề xuất thay đổi, không tự đổi rule"]
    DESIGN["Workflow, decision log<br/>và traceability"]
    ARCH[Solution Architect]
    SEC[Security Owner]
    DL[Delivery Lead]
    REVIEWED["Thiết kế được review<br/>và backlog"]
    DEL["Delivery team<br/>Xây dựng trong phạm vi đã ghi"]
    QA["QA Lead<br/>Kiểm thử theo acceptance criteria"]
    RELEASE["Kết quả kiểm thử<br/>và rủi ro còn lại"]
    RM[Release Manager]
    OPS["Operations Owner<br/>Quyết định vận hành trong<br/>thẩm quyền được giao"]
    FEEDBACK["Incident, phản hồi người dùng<br/>và số liệu vận hành mô phỏng"]

    BO -->|Nhu cầu, vấn đề, mục tiêu mô phỏng| BA
    BA --> DESIGN
    DESIGN -->|Đánh giá khả thi kỹ thuật| ARCH
    DESIGN -->|Đánh giá bảo mật| SEC
    ARCH -->|Kết quả review kỹ thuật| REVIEWED
    SEC -->|Kết quả review bảo mật| REVIEWED
    DL -->|Đồng sở hữu bàn giao| REVIEWED
    REVIEWED --> DEL
    DEL -->|Build, cấu hình, release note nội bộ| QA
    QA -->|Đồng bàn giao| RELEASE
    RM -->|Đồng bàn giao| RELEASE
    RELEASE --> OPS
    OPS --> FEEDBACK
    FEEDBACK -->|Đề xuất thay đổi| BA
    FEEDBACK -->|Nhận và quyết định rule nghiệp vụ| BO

    BA -.->|Mục tiêu mâu thuẫn hoặc vượt ngân sách| BO
    BA -.->|Thay đổi tích hợp| ARCH
    BA -.->|Phân quyền hoặc dữ liệu nhạy cảm| SEC

    DEL -.->|Thiếu quyết định rule hoặc thay đổi phạm vi| BA
    DEL -.->|Thiếu quyết định rule hoặc thay đổi phạm vi| BO

    QA -.->|Lỗi rule, số tiền VND mô phỏng hoặc quyền approval| BO
    QA -.->|Lỗi rule, số tiền VND mô phỏng hoặc quyền approval| BA

    PROD_RISK["Rủi ro production, rollback<br/>hoặc dữ liệu"]
    RELEASE -.-> PROD_RISK
    PROD_RISK -.->|Escalation| RM
    PROD_RISK -.->|Escalation| OPS

    LEGAL[Legal Owner]
    ACCOUNTING[Accounting Owner]
    FOOD[Food Safety Owner]

    FEEDBACK -.->|Ảnh hưởng pháp lý| LEGAL
    FEEDBACK -.->|Ảnh hưởng kế toán| ACCOUNTING
    FEEDBACK -.->|Ảnh hưởng an toàn thực phẩm| FOOD

Applied

Facts: Nova Foods mô phỏng có đề xuất: đơn mua nguyên liệu từ 50.000.000 VND phải có thêm một cấp phê duyệt. Dữ liệu là tổng hợp; mức tiền không phải chính sách thật.

Current Behavior: BA nhận đề xuất từ Purchasing Manager, vẽ luồng approval rồi gửi Delivery team cấu hình. Không có người được chỉ định xác nhận ngưỡng tiền hay quyền phê duyệt.

Underlying Need: Cần xác định ai sở hữu quyết định ngưỡng, ai chuyển workflow thành cấu hình ERP, và khi nào phải dừng bàn giao. Bằng chứng: ngưỡng tiền tác động kiểm soát chi tiêu; BA chỉ có thẩm quyền phân tích và truy vết, không có thẩm quyền quyết định tài chính.

Mục	Nội dung
Options	1. BA tự ghi ngưỡng thành business rule. 2. Business Owner xác nhận mục tiêu, Accounting Owner xác nhận ảnh hưởng kiểm soát, rồi BA ghi rule có nguồn quyết định.
Decision Criteria	Thẩm quyền tài chính rõ; rule truy vết được; Delivery team không suy đoán; không diễn giải luật kế toán.
Decision	Chọn phương án 2. BA ghi Verification required cho tính phù hợp kế toán/pháp lý nếu chưa có xác nhận owner chuyên môn.
Authority	Business Owner quyết định nhu cầu nghiệp vụ; Accounting Owner xác nhận phần thuộc kiểm soát kế toán; Solution Architect quyết định cách cấu hình; BA quản lý artifact và handoff.
Artifact	Workflow approval, decision log, traceability record; giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Delivery cấu hình sai người duyệt hoặc sai ngưỡng; giao dịch mô phỏng đi sai luồng; test basis sai; sửa sau release tốn hơn và làm mất truy vết quyết định.

Senior Lens

Escalation không phải chuyển trách nhiệm. BA đóng gói vấn đề: facts, artifact bị ảnh hưởng, lựa chọn, rủi ro, câu hỏi quyết định và owner cần trả lời. Owner chuyên môn quyết định phần thuộc quyền họ; BA ghi quyết định và liên kết lại workflow. Nếu một thay đổi đồng thời chạm rule nghiệp vụ, quyền truy cập và dữ liệu cá nhân, BA phải escalation tới Business Owner, Security Owner và Legal Owner; không chọn một ý kiến rồi gọi đó là quyết định chung.

Không dùng từ “đã phê duyệt” vì artifact corpus đang IN_REVIEW, v0.9.0. Chỉ ghi “đã được gửi để quyết định” khi có bằng chứng bàn giao; không suy ra approval từ cuộc họp, comment hoặc việc Delivery team đã bắt đầu làm.

Quick Reference

Quy tắc	Áp dụng
Người tạo artifact không mặc nhiên có quyền quyết định nội dung artifact	BA tạo workflow; Business Owner quyết định rule nghiệp vụ
Người nhận phải xác nhận đầu vào đủ dùng trước khi xử lý	Delivery trả lại khi thiếu rule, actor, điều kiện hoặc owner
Quyết định vượt thẩm quyền phải dừng tại điểm handoff	Không cấu hình ngưỡng tiền, quyền truy cập hay retention khi chưa có owner phù hợp
Escalation phải giữ traceability	Gắn artifact nguồn, câu hỏi, owner, ngày 2026-08-07, trạng thái IN_REVIEW

Core

Bản đồ vòng đời làm chuỗi công việc nhìn được trong một khung: từ Discovery đến Operations. Nó không thay thế BPMN. BPMN 2.0.2 của OMG là chuẩn ký pháp quy trình; sơ đồ dưới dùng Mermaid flowchart, chỉ để quét nhanh thứ tự và điểm kiểm soát. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu là tổng hợp.

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

flowchart LR
    D[Discovery<br/>Nêu vấn đề và mục tiêu]
    A[Analysis<br/>Làm rõ yêu cầu và quy tắc]
    V[Delivery<br/>Xây dựng hoặc cấu hình]
    T[Testing<br/>Kiểm tra theo test basis]
    R[Release<br/>Đưa thay đổi đã sẵn sàng]
    O[Operations<br/>Vận hành và ghi nhận phản hồi]

    D -->|Gate D-A: phạm vi đủ rõ để phân tích| A
    A -->|Gate A-V: nội dung đủ rõ để thực hiện| V
    V -->|Gate V-T: thay đổi có bản bàn giao kiểm thử| T
    T -->|Gate T-R: kết quả kiểm thử đủ điều kiện phát hành| R
    R -->|Gate R-O: thay đổi được chuyển sang vận hành| O
    O -->|Phản hồi hoặc sự cố tạo đầu vào mới| D

Tên gate là nhãn định hướng học liệu, không phải trạng thái phê duyệt. Suy luận: mỗi pha tạo đầu ra cho pha kế tiếp; vì vậy đặt gate giữa hai pha giúp người đọc thấy điểm chuyển giao thay vì hiểu sai vòng đời là sáu hoạt động độc lập.

Applied

Mục	Nội dung mô phỏng Nova Foods
Facts	Đề xuất ERP liên quan quy trình duyệt thay đổi giá bán, đi qua Discovery, Analysis, Delivery, Testing, Release và Operations.
Current Behavior	Người mới đọc danh sách pha theo hàng dọc, không thấy Testing nhận đầu vào từ Delivery hay Operations tạo phản hồi cho Discovery.
Underlying Need	Cần một hình duy nhất cho biết thứ tự, điểm chuyển pha và vòng phản hồi.
Options	Bảng văn bản; sơ đồ BPMN; Mermaid flowchart.
Decision Criteria	Đọc nhanh trong Markdown, chạy được trong kho tài liệu hỗ trợ Mermaid, không tuyên bố dùng ký pháp BPMN khi chưa mô hình hóa BPMN đầy đủ.
Decision	Dùng Mermaid flowchart sáu pha và năm gate chuyển pha.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì học liệu. Không có thẩm quyền xác nhận gate là phê duyệt nghiệp vụ, pháp lý, kế toán, bảo mật hay production.
Artifact	/02-handbook/13-process-design-workflows-and-approvals.md, section 03-lifecycle, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.
Consequence if Wrong	Gọi flowchart là BPMN làm sai nguồn chuẩn OMG; bỏ vòng Operations về Discovery làm mất nguồn phản hồi cho thay đổi tiếp theo.

Senior Lens

Sơ đồ vòng đời tốt phải cho thấy chiều đi và vòng quay lại. Chiều đi trả lời “việc đang ở pha nào”; vòng quay lại trả lời “vận hành phát hiện điều gì thì thay đổi bắt đầu lại ở đâu”. Không suy diễn rằng mọi phản hồi vận hành phải thành dự án mới: chỉ phản hồi cần thay đổi mới quay lại Discovery. Chi tiết về điều kiện gate, người giao nhận, giới hạn thẩm quyền và escalation thuộc nội dung vòng đời kế tiếp.

Quick Reference

Quy tắc	Áp dụng
Dùng Mermaid khi thứ tự pha cần nhìn nhanh	Có
Gọi sơ đồ Mermaid là BPMN	Không
Diễn giải IN_REVIEW là đã phê duyệt hoặc baseline	Không
Dùng sơ đồ làm bằng chứng tuân thủ hoặc quyết định production	Không
Nguồn ký pháp BPMN	OMG BPMN 2.0.2: https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/

4. Input c?n thi?t

Core

Input là thông tin BA cần có trước khi mô tả quy trình và luồng phê duyệt. Người mới không cần biết ERP trước: ERP là hệ thống ghi nhận và phối hợp dữ liệu giữa các bộ phận như mua hàng, kho, sản xuất, bán hàng và kế toán. BA không được biến suy đoán thành quy tắc. Mỗi nhận định phải nối được về một artifact nguồn hoặc được gắn rõ là giả định học liệu.

Bằng chứng là nội dung quan sát được trong artifact nguồn, như metadata, sơ đồ, bảng dữ liệu, quy tắc hoặc URL nguồn chuẩn. Artifact nguồn là tệp kiểm soát chứa bằng chứng đó. Canonical ID là định danh bền vững, phải giữ nguyên ký tự để liên kết đúng artifact qua nhiều tài liệu. Ví dụ, CANONICAL_BUSINESS_RULES không được đổi thành “Business Rules”, vì tên dịch làm đứt liên kết máy đọc và liên kết kiểm tra.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Mọi tên, dữ liệu và luồng trong handbook là dữ liệu tổng hợp. IN_REVIEW, v0.9.0 và ngày 2026-08-07 mô tả trạng thái học liệu; chúng không chứng minh baseline, approval, cấu hình ERP, tuân thủ pháp lý hoặc quyền dùng production.

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

flowchart LR
    A[Kiến thức nền] --> D[BA hiểu phạm vi]
    B[Artifact nguồn] --> E[Bằng chứng truy vết]
    C[Canonical ID] --> E
    D --> F[Đầu vào cho thiết kế quy trình]
    E --> F

Sơ đồ là Mermaid flowchart, không phải BPMN. Nó cho thấy BA cần cả hiểu biết nền và bằng chứng có định danh; chỉ một trong hai không đủ để thiết kế luồng có thể kiểm tra.

Applied

Facts: Corpus đang dùng Status IN_REVIEW, Version v0.9.0, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND, ngày 2026-08-07. Các artifact upstream có đường dẫn và ID kiểm soát.

Current Behavior: Người mới dễ đọc một đoạn mô tả rồi tự đặt tên tài liệu, tự diễn giải “review” thành “đã duyệt”, hoặc ghi lại quy tắc bằng tên khác.

Underlying Need: Thiết kế workflow cần biết thông tin nào là nền tảng, thông tin nào là bằng chứng, và nơi nào lưu nguồn chuẩn để người khác kiểm tra lại.

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

Decision Criteria: Liên kết phải không mơ hồ, giữ được khi nội dung dịch sang tiếng Việt, không nâng trạng thái quản trị thành phê duyệt, và không tạo ID mới ngoài registry.

Decision: Dùng đường dẫn kiểm soát và canonical ID đúng nguyên dạng. Chỉ tham chiếu nguồn pháp lý hoặc chuẩn theo safe use boundary đã ghi; không suy diễn điều khoản chưa được xác minh.

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

Artifact: /02-handbook/13-process-design-workflows-and-approvals.md, section 04-inputs, Status IN_REVIEW, Version v0.9.0.

Consequence if Wrong: Đổi hoặc tự tạo ID làm mất traceability. Gọi IN_REVIEW là approved tạo kết luận quản trị sai. Suy diễn yêu cầu pháp lý từ nguồn chưa kiểm chứng tạo rủi ro nội dung.

Nhóm đầu vào cần biết	Artifact nguồn kiểm soát	Canonical ID phải giữ nguyên	BA dùng để làm gì	Cầu nối bằng chứng và suy luận
Cấu trúc chapter và phạm vi học liệu	/01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST	Xác định chapter này thuộc handbook và không biến thành đặc tả triển khai	Manifest nêu đây là controlled planning artifact, IN_REVIEW, chưa có baseline hoặc approval; vì vậy nội dung chỉ là học liệu mô phỏng
Kiến trúc curriculum	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	01_CURRICULUM_ARCHITECTURE	Hiểu vị trí process design trong chuỗi học	Artifact xác định chuỗi từ requirement, rule, data đến traceability; vì vậy workflow cần đầu vào truy vết thay vì mô tả theo cảm tính
Đăng ký định danh	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	TRACEABILITY_ID_REGISTRY	Kiểm tra ID có nguồn canonical trước khi liên kết	Registry định nghĩa canonical ID là định danh quản trị duy nhất; vì vậy không tự đặt biến thể ID
Catalog quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	CANONICAL_BUSINESS_RULES	Nhận diện nơi quy tắc nghiệp vụ sẽ được kiểm soát	Catalog nói Owner không xác nhận quy tắc vận hành thực; vì vậy BA chỉ tham chiếu, không tuyên bố quy tắc đã đúng
Từ điển dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	CANONICAL_DATA_DICTIONARY	Hiểu tên dữ liệu cần dùng trong quy trình	Artifact là nguồn canonical cho dữ liệu logic; vì vậy tên trường và thực thể không nên tự dịch hoặc đổi tên
Danh mục template	/01-curriculum/TEMPLATE_MANIFEST.md	TEMPLATE_MANIFEST	Biết template nào được dự kiến hỗ trợ artifact sau này	Manifest giới hạn template ở trạng thái kế hoạch; vì vậy không gọi template là bằng chứng phê duyệt
Bản đồ nguồn nghiên cứu	/00-research/00_SOURCE_MAP.md	00_SOURCE_MAP	Xác định nguồn chuẩn và ranh giới dùng nguồn	Source map yêu cầu gắn nhãn xác minh và không tạo approval ngầm định; vì vậy BA phải giữ ranh giới nguồn
Ký pháp quy trình	https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/	BPMN 2.0.2	Phân biệt BPMN chuẩn với sơ đồ minh họa	OMG là nguồn chuẩn cho BPMN; vì vậy Mermaid flowchart không được gọi là BPMN
Thuật ngữ BA	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	BABOK Guide Version 3	Dùng thuật ngữ BA nhất quán	IIBA công bố BABOK là nguồn cho knowledge areas và thuật ngữ; vì vậy không gán số trang hoặc điều khoản chưa truy cập văn bản có bản quyền

Senior Lens

Không phải mọi tài liệu liên quan đều là đầu vào hợp lệ. BA cần tách ba lớp: kiến thức nền giúp hiểu thuật ngữ; artifact nguồn cung cấp bằng chứng; canonical ID giữ liên kết bền vững. Ví dụ, URL OMG giải thích nguồn ký pháp, nhưng không chứng minh Nova Foods đã chọn BPMN. CHAPTER_MANIFEST chứng minh phạm vi corpus, nhưng không chứng minh một workflow nghiệp vụ đã được Business Owner chấp thuận.

Khi một thông tin thiếu nguồn, ghi nhận nó là giả định học liệu hoặc Verification required trong artifact phù hợp; không lấp chỗ trống bằng quy tắc mới. Điều này giữ ranh giới giữa phân tích, quyết định nghiệp vụ và thẩm quyền chuyên môn.

Quick Reference

Câu hỏi trước khi dùng thông tin	Cách trả lời
Đây là kiến thức nền hay bằng chứng?	Kiến thức nền giải thích; artifact nguồn chứng minh
Nơi lưu nguồn chuẩn là đâu?	Đường dẫn kiểm soát hoặc URL chính thức đã nêu
ID cần ghi thế nào?	Giữ nguyên, ví dụ TRACEABILITY_ID_REGISTRY
IN_REVIEW có nghĩa approved không?	Không
Nova Foods có phải doanh nghiệp thật không?	Không, chỉ là mô phỏng giáo dục dùng dữ liệu tổng hợp

Core

Đầu vào chỉ đủ dùng khi người đọc biết nó đến từ đâu, còn hiệu lực không, ai chịu trách nhiệm và khi nào phải dừng. Phân loại nguồn là nhãn cho biết mức thẩm quyền của nguồn: PRIMARY_OFFICIAL là nguồn chính thức do tổ chức phát hành; CONTROLLED_CORPUS là artifact được kiểm soát trong corpus; PROJECT_ASSUMPTION là giả định học liệu; VERIFICATION_REQUIRED là thông tin chưa đủ bằng chứng để dùng làm kết luận.

Kiểm tra chất lượng trước khi dùng mỗi đầu vào:

Kiểm tra	Điều kiện đạt	Bằng chứng cần có	Hành động khi không đạt
Định danh	Có Artifact ID, đường dẫn canonical, Status, Version	Header artifact	Không dùng bản sao hoặc tên tệp biến thể
Nguồn gốc	Có issuer hoặc owner xác định	Metadata, URL chính thức, lịch sử artifact	Gắn VERIFICATION_REQUIRED
Tính mới	Ngày truy cập hoặc cập nhật không muộn hơn 2026-08-07	Last updated date hoặc access date	Kiểm tra lại nguồn trước khi suy luận
Phạm vi	Nội dung trả lời đúng câu hỏi workflow hoặc approval	Safe use boundary, phạm vi artifact	Không suy rộng sang pháp lý, kế toán, production
Thẩm quyền	Người/đơn vị sở hữu đúng loại quyết định	Owner và authority boundary	Escalate sang Business Owner, Legal Owner, Accounting Owner, Architect, Security hoặc QA
Truy vết	Có ID hoặc tham chiếu canonical giữ nguyên chuỗi	TRACEABILITY_ID_REGISTRY, artifact ID	Dừng liên kết nếu ID chưa đăng ký hoặc mâu thuẫn

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

flowchart TB
    A[Nhận đầu vào] --> B{Có ID, đường dẫn canonical, Status, Version?}
    B -- Không --> S1[Dừng: thiếu định danh canonical]
    B -- Có --> C{Nguồn và owner rõ?}
    C -- Không --> V[Phân loại: VERIFICATION_REQUIRED]
    V --> S2[Không dùng làm kết luận: chưa đủ bằng chứng]
    C -- Có --> T{Phân loại nguồn}
    T -- Nguồn chính thức --> P[PRIMARY_OFFICIAL]
    T -- Artifact corpus kiểm soát --> K[CONTROLLED_CORPUS]
    T -- Giả định học liệu --> A1[PROJECT_ASSUMPTION]
    T -- Chưa đủ bằng chứng --> V
    P --> D{Còn mới tại 2026-08-07?}
    K --> D
    A1 --> D
    D -- Không --> R{Kiểm tra lại nguồn đạt?}
    R -- Không --> V
    R -- Có --> G{Đúng phạm vi workflow hoặc approval?}
    D -- Có --> G
    G -- Không --> S3[Không suy rộng sang pháp lý, kế toán, production]
    G -- Có --> H{Owner có đúng loại quyết định?}
    H -- Không --> X[Escalate: Business Owner, Legal Owner, Accounting Owner, Architect, Security hoặc QA]
    H -- Có --> I{ID hoặc tham chiếu canonical đã đăng ký và không mâu thuẫn?}
    I -- Không --> S4[Dừng liên kết: ID chưa đăng ký hoặc mâu thuẫn]
    I -- Có --> F[Dùng làm evidence có truy vết]

Applied

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

Current Behavior: BA nhận metadata từ /01-curriculum/CHAPTER_MANIFEST.md, quy tắc từ /01-curriculum/CANONICAL_BUSINESS_RULES.md, định nghĩa dữ liệu từ /01-curriculum/CANONICAL_DATA_DICTIONARY.md, nhưng không được xem các artifact này là phê duyệt nghiệp vụ.

Underlying Need: Phân biệt evidence quản trị corpus với quyết định vận hành ERP. Evidence nói artifact tồn tại, có owner và trạng thái; không chứng minh workflow Nova Foods được phép chạy production.

Nguồn	Phân loại	Freshness	Owner	Dùng được cho	Không được suy ra
00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md	CONTROLLED_CORPUS	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Ranh giới nguồn, URL chính thức	Điều khoản pháp lý cụ thể
CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	CONTROLLED_CORPUS	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Tên, đường dẫn, cấu trúc chapter	Baseline, approval
TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	CONTROLLED_CORPUS	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Kiểm tra ID canonical	Quyết định nghiệp vụ
Luật 91/2025/QH15	PRIMARY_OFFICIAL	Access date 2026-08-07	Quốc hội Việt Nam	Bối cảnh pháp lý cần xem xét	Requirement hệ thống nếu Legal Owner chưa xác minh
Ngưỡng duyệt đơn mua mô phỏng 50.000.000 VND	PROJECT_ASSUMPTION	2026-08-07	Chưa có Business Owner xác nhận	Ví dụ phân tích	Chính sách Nova Foods thực tế

Options: Dùng mọi nguồn như sự thật; chỉ dùng nguồn chính thức; hoặc dùng nguồn theo phân loại và gắn nhãn giới hạn.

Decision Criteria: Không làm sai thẩm quyền, giữ truy vết, không biến giả định thành rule, không diễn giải luật ngoài thẩm quyền.

Decision: Dùng phân loại và kiểm tra chất lượng trước khi đưa đầu vào vào workflow hoặc approval.

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

Artifact: Bảng kiểm đầu vào của section 4 trong /02-handbook/13-process-design-workflows-and-approvals.md.

Consequence if Wrong: Workflow có thể dùng rule hết hạn, nhầm giả định thành chính sách, hoặc ghi nhận approval không tồn tại.

Senior Lens

Điều kiện dừng không phải lỗi hành chính. Nó chặn BA biến khoảng trống bằng suy đoán. Dừng ngay khi có một điều kiện sau:

• Artifact không có canonical ID, đường dẫn kiểm soát, Status hoặc Version.
• Nguồn pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật bị dùng để tạo nghĩa vụ hệ thống nhưng thiếu xác minh từ owner có thẩm quyền.
• Giá trị mô phỏng bị trình bày như dữ liệu Nova Foods thực tế.
• IN_REVIEW bị diễn giải thành APPROVED hoặc BASELINED.
• Hai nguồn canonical mâu thuẫn về cùng ID, trạng thái, owner hoặc version.
• Nguồn cũ hơn 2026-08-07 nhưng không có xác nhận còn hiệu lực.
• Quyết định approval không có authority được nêu rõ.

Khi dừng, BA ghi nhận nguồn, lỗi kiểm tra, tác động và owner cần xác minh. BA không tự sửa nội dung chuyên môn của Legal, Accounting, Business Owner hoặc Architect.

Quick Reference

Nhãn	Nghĩa	Có thể dùng ngay?
PRIMARY_OFFICIAL	Nguồn chính thức từ issuer	Có, trong safe use boundary
CONTROLLED_CORPUS	Artifact quản trị corpus	Có, cho traceability và phạm vi
PROJECT_ASSUMPTION	Giả định mô phỏng	Có, chỉ khi giữ nhãn giả định
VERIFICATION_REQUIRED	Chưa đủ bằng chứng hoặc thẩm quyền	Không dùng làm quyết định
IN_REVIEW	Đang xem xét có kiểm soát	Không phải approval hoặc baseline

Core

Bảng dưới là bộ đầu vào hoàn chỉnh cho ví dụ thiết kế workflow và approval của Nova Foods Trading & Manufacturing, case study mô phỏng giáo dục. Mọi giá trị Nova Foods là dữ liệu tổng hợp, không xác nhận cấu hình ERP, quyết định vận hành, tuân thủ hay phê duyệt thực tế.

Nhóm đầu vào	Giá trị mô phỏng	ID hoặc tên canonical	Tệp/nguồn	Phân loại nguồn	Owner nguồn	Ngày ghi nhận	Trạng thái xác minh	Hạng mục chưa giải quyết
Bối cảnh corpus	Việt Nam, vi-VN, Asia/Ho_Chi_Minh, VND	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Canonical planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Đã ghi nhận metadata	Không phải quyết định vận hành Nova Foods
Trạng thái tài liệu	IN_REVIEW, v0.9.0	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Canonical planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Đã ghi nhận metadata	Chưa có baseline reference; chưa có approval reference
Danh mục định danh	Registry định danh truy vết	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Đã ghi nhận metadata	Không cấp ID mới khi chưa đăng ký
Danh mục quy tắc	Catalog quy tắc nghiệp vụ canonical	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Đã ghi nhận metadata	Không có quy tắc workflow Nova Foods được xác nhận để áp dụng
Từ điển dữ liệu	Kế hoạch từ điển dữ liệu logic	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Đã ghi nhận metadata	Tên trường, khóa và dữ liệu ERP thực tế cần xác minh
Nguồn BA	Thuật ngữ và phạm vi hoạt động Business Analysis	BABOK Guide Version 3	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Nguồn chuyên môn chính thức	IIBA	2026-08-07	URL đã cung cấp	Nội dung có bản quyền; không gán số trang hoặc điều khoản chưa kiểm tra
Nguồn mô hình quy trình	Ký pháp BPMN 2.0.2	BPMN 2.0.2	https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/	Nguồn chuẩn chính thức	OMG	2026-08-07	URL đã cung cấp	Chưa xác định Nova Foods cần BPMN hay sơ đồ hoạt động khác
Bằng chứng nghiệp vụ	Đề nghị duyệt chi phí mua nguyên liệu: 125.000.000 VND; người tạo mô phỏng: NVF-USER-014; ngày tạo: 2026-08-06 09:15	Chưa có canonical ID	Chưa có artifact nguồn được kiểm soát	Dữ liệu ví dụ tổng hợp	Chưa xác định Business Owner mô phỏng	2026-08-06	VERIFICATION REQUIRED	Chưa có bằng chứng nguồn, loại yêu cầu, ngưỡng duyệt, vai trò duyệt, trạng thái và ID đăng ký
Ràng buộc pháp lý	Bối cảnh bảo vệ dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm	Luật và nghị định trong 00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Nguồn pháp lý chính thức, qua source map	Cơ quan ban hành; diễn giải cần owner có thẩm quyền	2026-08-07	VERIFICATION REQUIRED	Không suy ra rule workflow, retention, chữ ký, thuế hoặc truy xuất từ source map

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

flowchart TB
    subgraph Nguon["4 loại nguồn đầu vào"]
        A["Artifact canonical<br/>CHAPTER_MANIFEST · registry ID<br/>catalog quy tắc · từ điển dữ liệu<br/>Owner: Principal IT Business Analyst / Technical Curriculum Author"]
        B["Nguồn chuyên môn<br/>BABOK Guide Version 3 · BPMN 2.0.2<br/>Owner: IIBA · OMG"]
        C["Bằng chứng tổng hợp<br/>Đề nghị duyệt chi phí mua nguyên liệu<br/>125.000.000 VND · tạo 2026-08-06 09:15<br/>Người tạo mô phỏng: NVF-USER-014<br/>Business Owner: chưa xác định"]
        D["Nguồn pháp lý qua 00_SOURCE_MAP<br/>Dữ liệu cá nhân · kế toán · hóa đơn<br/>an toàn thực phẩm<br/>Owner: cơ quan ban hành;<br/>diễn giải cần owner có thẩm quyền"]
    end

    A --> A1["Đã ghi nhận metadata"]
    B --> B1["URL đã cung cấp"]
    C --> C1["VERIFICATION REQUIRED"]
    D --> D1["VERIFICATION REQUIRED"]

    A1 --> A2["Dùng làm bối cảnh và truy vết<br/>Không là quyết định vận hành Nova Foods"]
    B1 --> B2["Dùng cho thuật ngữ và ký pháp<br/>Không gán nội dung chưa kiểm tra"]
    C1 --> C2["Chưa dùng làm rule hay approval<br/>Thiếu owner, artifact nguồn,<br/>loại yêu cầu, ngưỡng, vai trò,<br/>trạng thái và ID đăng ký"]
    D1 --> D2["Không suy ra workflow, retention,<br/>chữ ký, thuế hoặc truy xuất"]

    A2 --> N["Thiết kế workflow/approval<br/>chỉ dùng dữ liệu đã xác minh"]
    B2 --> N
    C2 --> C3["Hành động tiếp theo<br/>Xác định Business Owner; lấy artifact;<br/>xác minh rule và đăng ký ID"]
    D2 --> D3["Hành động tiếp theo<br/>Lấy diễn giải từ owner có thẩm quyền"]

Applied

Mục	Nội dung
Facts	Có metadata corpus, source map và artifact canonical. Có một ví dụ đề nghị chi phí 125.000.000 VND, nhưng ví dụ không có artifact nguồn hay ID canonical.
Current Behavior	BA chỉ ghi ví dụ vào bảng, không gọi nó là rule, workflow hiện hành hay yêu cầu đã được duyệt.
Underlying Need	Phân biệt dữ kiện được kiểm soát với dữ liệu minh họa tổng hợp trước khi thiết kế luồng duyệt.
Options	Dùng ví dụ như rule; loại ví dụ; giữ ví dụ nhưng gắn nhãn chưa xác minh.
Decision Criteria	Không bịa nguồn, không tạo ID mới, không biến dữ liệu tổng hợp thành quyết định Nova Foods.
Decision	Giữ ví dụ để minh họa cấu trúc input; gắn VERIFICATION REQUIRED; không dùng nó để chốt ngưỡng hay quyền duyệt.
Authority	Business Owner, Accounting Owner, Legal Owner, Security và Architect xác minh phần thuộc thẩm quyền họ.
Artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /00-research/00_SOURCE_MAP.md.
Consequence if Wrong	Workflow có thể gán sai người duyệt, ngưỡng tiền, dữ liệu cần bảo vệ hoặc trách nhiệm pháp lý.

Senior Lens

Chuỗi suy luận phải giữ rõ: artifact canonical chứng minh tên, trạng thái, phiên bản và ranh giới corpus; nó không chứng minh rule vận hành. Ví dụ 125.000.000 VND chỉ là dữ liệu tổng hợp vì thiếu nguồn nghiệp vụ được kiểm soát và canonical ID. Vì vậy, BA được phép ghi nhận nó làm điểm cần xác minh, không được suy diễn approval matrix.

Quick Reference

Nhãn	Nghĩa dùng trong bảng
Canonical planning artifact	Nguồn kiểm soát cho định danh, metadata hoặc kế hoạch corpus
Nguồn chuẩn chính thức	Nguồn định nghĩa thuật ngữ hoặc ký pháp, không tự tạo rule Nova Foods
Dữ liệu ví dụ tổng hợp	Số liệu mô phỏng phục vụ học tập
VERIFICATION REQUIRED	Chưa đủ bằng chứng hoặc chưa có owner có thẩm quyền xác nhận

5. Step-by-step BA Activities

Core

BA thiết kế workflow và approval bằng chuỗi hoạt động kiểm soát được: chuẩn bị bằng chứng, mô hình hóa trạng thái, xác định quyết định, kiểm tra mâu thuẫn, review và handoff có kiểm soát. Approval là quyết định của vai trò có thẩm quyền; BA ghi nhận điều kiện và bằng chứng, không tự cấp approval.

Mọi nội dung Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Status corpus IN_REVIEW, Version v0.9.0, ngày 2026-08-07; không có baseline hay approval ngầm định.

Applied

1. Chuẩn bị phạm vi và nguồn. Actor: BA. Action: lập danh sách quy trình, artifact upstream và owner cần tham vấn. Object: phạm vi workflow, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /00-research/00_SOURCE_MAP.md. Evidence produced: bảng nguồn và ranh giới bằng chứng. Decision rule: chỉ dùng ID, filename, trạng thái và phân loại nguồn đúng artifact canonical. Quality gate: mỗi nhận định phân biệt rõ fact, project assumption và VERIFICATION REQUIRED. Escalation route: Principal IT Business Analyst / Technical Curriculum Author khi ID, nguồn canonical hoặc phạm vi mâu thuẫn.

2. Thu thập hành vi hiện tại. Actor: BA cùng Process Owner. Action: ghi nhận trigger, tác nhân, đầu vào, đầu ra, trạng thái, ngoại lệ và điểm chờ quyết định. Object: quy trình mô phỏng Nova Foods. Evidence produced: ghi chú discovery có nguồn người cung cấp thông tin và dữ liệu tổng hợp. Decision rule: điều quan sát được là current behavior, không tự biến thành business rule. Quality gate: mỗi bước phải có actor và object; không có bước “hệ thống xử lý” thiếu điều kiện. Escalation route: Process Owner khi thiếu người chịu trách nhiệm hoặc trạng thái không xác định.

3. Tách quyết định khỏi thao tác. Actor: BA. Action: đánh dấu nơi workflow cần chọn tiếp tục, từ chối, trả lại hoặc chuyển cấp. Object: điểm quyết định và quyền quyết định. Evidence produced: decision log gồm điều kiện, lựa chọn, bằng chứng đầu vào và authority dự kiến. Decision rule: chỉ authority có thẩm quyền mới quyết ngưỡng tiền, kế toán, pháp lý, an toàn thực phẩm, bảo mật hoặc kiến trúc. Quality gate: mỗi nhánh có điều kiện có thể kiểm tra và kết quả trạng thái rõ. Escalation route: Business Owner, Accounting Owner, Legal Owner, Security hoặc Architect theo loại quyết định.

4. Thiết kế trạng thái và chuyển trạng thái. Actor: BA. Action: mô tả trạng thái nghiệp vụ trước và sau từng hành động. Object: workflow draft và dữ liệu logic liên quan. Evidence produced: state transition list, gồm trạng thái nguồn, action, điều kiện, trạng thái đích và người thực hiện. Decision rule: không cho phép chuyển trạng thái nếu thiếu dữ liệu bắt buộc hoặc authority. Quality gate: không có trạng thái mồ côi, vòng lặp không điều kiện, hoặc trạng thái cuối không xác định. Escalation route: Process Owner khi hành vi vận hành không rõ; Architect khi trạng thái phụ thuộc thiết kế hệ thống.

5. Gắn dữ liệu và kiểm soát truy cập. Actor: BA cùng Data Owner và Security. Action: xác định dữ liệu được tạo, sửa, xem, truyền và lưu tại mỗi bước. Object: field logic, vai trò và integration boundary. Evidence produced: data-touchpoint list liên kết /01-curriculum/CANONICAL_DATA_DICTIONARY.md khi có mục canonical phù hợp. Decision rule: không suy diễn nghĩa vụ pháp lý hoặc mức bảo vệ từ dữ liệu ví dụ; gắn VERIFICATION REQUIRED khi cần xác minh. Quality gate: mỗi dữ liệu nhạy cảm hoặc dữ liệu ảnh hưởng quyết định có owner và mục đích sử dụng. Escalation route: Security, Legal Owner hoặc Data Owner.

6. Soạn workflow có khả năng review. Actor: BA. Action: chuyển discovery thành luồng tuần tự với trigger, precondition, action, decision, exception, audit evidence và handoff. Object: workflow draft. Evidence produced: bản nháp reviewable kèm decision log. Decision rule: mô tả phải cho QA suy ra test basis nhưng không tạo test case hoặc acceptance criterion chưa có nguồn. Quality gate: từng bước trả lời được ai làm gì, trên object nào, bằng chứng nào được lưu, khi nào chuyển cấp. Escalation route: QA reviewer khi không thể kiểm thử hành vi; Architect khi integration chưa xác định.

7. Review chéo và xử lý khác biệt. Actor: BA điều phối; Process Owner, Business Owner, QA reviewer, Architect và owner chuyên môn tham gia theo phạm vi. Action: đối chiếu workflow với evidence và ghi từng khác biệt. Object: workflow draft, decision log, source list. Evidence produced: review record nêu nhận xét, nguồn, owner xử lý và trạng thái IN_REVIEW. Decision rule: khác biệt không được giải bằng giả định im lặng; giữ nhãn VERIFICATION REQUIRED đến khi authority cung cấp bằng chứng phù hợp. Quality gate: không còn mâu thuẫn chưa ghi nhận giữa trạng thái, authority, dữ liệu và exception. Escalation route: authority tương ứng; BA chỉ đóng gói vấn đề và bảo toàn traceability.

8. Handoff có kiểm soát. Actor: BA. Action: bàn giao workflow draft, source list, decision log, open verification list và review record cho consumer tiếp theo. Object: gói handoff. Evidence produced: danh mục tệp, version v0.9.0, status IN_REVIEW, ngày 2026-08-07, phạm vi dữ liệu tổng hợp. Decision rule: handoff xác nhận chuyển giao artifact, không xác nhận baseline, approval, compliance hoặc production readiness. Quality gate: consumer nhận đủ liên kết artifact canonical và danh sách điểm chưa xác minh. Escalation route: Principal IT Business Analyst / Technical Curriculum Author khi thiếu traceability hoặc metadata kiểm soát.

Applied case: Nova Foods mô phỏng	Nội dung thực thi
Facts	Có yêu cầu mô tả luồng duyệt điều chỉnh đơn mua hàng; ví dụ 125.000.000 VND là dữ liệu tổng hợp. Corpus chỉ xác nhận governance artifact ở trạng thái IN_REVIEW, không xác nhận ngưỡng duyệt.
Current Behavior	Người cung cấp thông tin mô tả người mua tạo yêu cầu, quản lý xem xét, sau đó đơn được cập nhật. Chưa có bằng chứng canonical cho ngưỡng, vai trò phê duyệt cuối hoặc ngoại lệ.
Underlying Need	Cần workflow cho thấy khi nào yêu cầu được tạo, ai quyết định, dữ liệu nào cần có, khi nào trả lại và bằng chứng nào phải lưu.
Options	Dùng 125.000.000 VND làm rule; bỏ hoàn toàn ví dụ; giữ ví dụ là dữ liệu tổng hợp và gắn VERIFICATION REQUIRED.
Decision Criteria	Không bịa business rule; không gán authority ngoài bằng chứng; giữ workflow đủ rõ để review; bảo toàn traceability tới artifact canonical.
Decision	Giữ số tiền làm dữ liệu minh họa, không dùng làm approval threshold. Workflow ghi điều kiện “ngưỡng do Business Owner và Accounting Owner xác minh”.
Authority	Business Owner quyết nhu cầu nghiệp vụ; Accounting Owner xác minh tác động kế toán; Legal Owner xác minh nghĩa vụ pháp lý nếu phát sinh; Architect xác minh khả thi kỹ thuật.
Artifact	Workflow draft, decision log, review record; tham chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	ERP mô phỏng có thể định tuyến sai người duyệt, khóa sai trạng thái, dùng sai dữ liệu hoặc diễn đạt dữ liệu tổng hợp như cam kết vận hành.

Senior Lens

Workflow tốt không phải sơ đồ đẹp. Nó là chuỗi quyết định có bằng chứng: trigger tạo nhu cầu, dữ liệu chứng minh điều kiện, authority chọn kết quả, trạng thái ghi kết quả, audit evidence cho phép kiểm tra lại. Nếu một mắt xích thiếu, BA phải ghi khoảng trống và escalation; không điền bằng kinh nghiệm cá nhân.

Quick Reference

Kiểm tra trước handoff	Đạt khi
Traceability	Mỗi rule hoặc giả định có nguồn, owner hoặc nhãn VERIFICATION REQUIRED
Authority	Không gán quyền duyệt cho vai trò chưa được xác minh
State	Mỗi chuyển trạng thái có điều kiện và kết quả
Evidence	Mỗi quyết định có dữ liệu hoặc record cần lưu
Governance	Gói bàn giao giữ IN_REVIEW, v0.9.0, 2026-08-07; không tuyên bố approval

Core

Mỗi bước BA phải tạo được dấu vết kiểm tra. Actor là vai trò thực hiện. Action là việc làm quan sát được. Object là quy trình, quy tắc, dữ liệu hoặc quyết định đang xử lý. Evidence là bằng chứng lưu được. Decision rule là điều kiện chọn hoặc dừng. Quality gate là điểm chặn chất lượng trước bước kế tiếp. Escalation route là vai trò nhận vấn đề khi BA không có thẩm quyền kết luận.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	Business Analyst	Đọc mục tiêu, ranh giới và nguồn canonical	Yêu cầu thay đổi quy trình Nova Foods mô phỏng	Danh sách nguồn đã đọc, phạm vi trong/ngoài phạm vi	Chỉ dùng nguồn có đường dẫn, trạng thái và owner xác định	Không có nguồn mâu thuẫn hoặc thiếu định danh	Principal IT Business Analyst / Technical Curriculum Author khi nguồn canonical mâu thuẫn
2. Thu thập hiện trạng	Business Analyst; Subject Matter Expert	Ghi nhận luồng công việc hiện hữu và điểm quyết định	Quy trình nghiệp vụ mô phỏng, vai trò, dữ liệu vào/ra	Ghi chú phiên làm việc, bảng hiện trạng, giả định được gắn nhãn	Tách fact khỏi assumption; không biến ý kiến thành rule	Mỗi bước có trigger, actor, input, output và exception	Business Owner khi mục tiêu hoặc ưu tiên nghiệp vụ chưa rõ
3. Phân tích vấn đề	Business Analyst	So sánh hiện trạng với nhu cầu đã chứng minh	Điểm nghẽn, lỗi kiểm soát, dữ liệu thiếu	Bảng fact–need–impact	Chỉ kết luận need khi fact chỉ ra tác động hoặc rủi ro cụ thể	Mỗi inference có cầu nối evidence → reasoning → conclusion	Business Owner; Accounting Owner; Legal Owner; Security theo loại tác động
4. Thiết kế phương án	Business Analyst; Solution Architect khi có hệ thống	Mô tả phương án quy trình và điểm kiểm soát	Luồng đề xuất, trạng thái, quyền, tích hợp	Danh sách options, tiêu chí đánh giá, quyết định đang chờ	Không chọn phương án vượt thẩm quyền BA; không gọi assumption là requirement	Mỗi option nêu lợi ích, chi phí, rủi ro, dependency và owner quyết định	Architect cho kiến trúc/tích hợp; Security cho truy cập/dữ liệu; Business Owner cho trade-off
5. Kiểm tra tính đầy đủ	Business Analyst; QA Reviewer	Đối chiếu bước, rule, dữ liệu và exception	Bản thiết kế quy trình	Danh sách kiểm tra, lỗi phát hiện, sửa đổi có truy vết	Không chuyển review nếu còn bước không có evidence hoặc route escalation	Không còn mâu thuẫn nội bộ; thuật ngữ và nguồn giữ nguyên	QA Reviewer khi tiêu chí kiểm tra thiếu; đúng owner chuyên môn khi rule thuộc pháp lý, kế toán, an toàn thực phẩm
6. Review có kiểm soát	Business Analyst; các owner liên quan	Trình bày evidence, options và điểm cần quyết định	Gói review trạng thái IN_REVIEW	Biên bản review, quyết định ghi nhận, issue log	Chỉ ghi nhận kết quả theo thẩm quyền thực tế; không suy diễn approval	Mỗi issue có owner, căn cứ và hướng xử lý	Principal IT Business Analyst / Technical Curriculum Author khi thiếu owner hoặc xung đột thẩm quyền
7. Bàn giao có kiểm soát	Business Analyst	Liên kết output với artifact canonical và nêu giới hạn dùng	Gói thiết kế, evidence, issue còn mở	Danh mục bàn giao, liên kết tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi phù hợp	Không gọi IN_REVIEW là baseline, approval hoặc sẵn sàng production	Người nhận xác định được nguồn, trạng thái v0.9.0, ngày 2026-08-07, giới hạn giả định	Owner artifact đích khi liên kết, version hoặc trạng thái không khớp

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu tổng hợp; status corpus IN_REVIEW, version v0.9.0. Current Behavior: BA nhận đề nghị đổi luồng phê duyệt nhưng chỉ có mô tả miệng, chưa có nguồn canonical chỉ ra rule. Underlying Need: phân biệt nhu cầu kiểm soát với quy tắc đã được xác nhận, vì một cấu hình ERP sai có thể đổi quyền phê duyệt hoặc dữ liệu. Options: giữ đề nghị như assumption; ghi thành rule; dừng để escalation. Decision Criteria: có evidence truy vết, owner có thẩm quyền, không mâu thuẫn CANONICAL_BUSINESS_RULES, không suy diễn nghĩa vụ pháp lý hoặc kế toán. Decision: dừng ở assumption và escalation; không tạo rule mới. Authority: Business Owner xác nhận mục tiêu; Accounting Owner, Legal Owner hoặc Security xác nhận phần thuộc chuyên môn; BA chỉ tổng hợp evidence. Artifact: ghi trong gói review, liên kết đúng artifact canonical khi đã tồn tại. Consequence if Wrong: assumption bị đưa thành rule có thể tạo quyền sai, kiểm soát sai hoặc claim tuân thủ không có căn cứ.

Senior Lens

Quality gate không phải cuộc họp. Gate là điều kiện nhị phân: đạt thì đi tiếp, không đạt thì giữ lại hoặc escalation. Evidence không phải “đã trao đổi”; evidence phải chỉ ra ai cung cấp gì, nguồn nào, ngày nào theo Asia/Ho_Chi_Minh, và kết luận nào được phép suy ra.

Quick Reference

Mẫu ghi nhanh mỗi bước: Actor | Action | Object | Evidence | Decision rule | Quality gate | Escalation route. Thiếu một cột, bước chưa đủ để review hoặc bàn giao có kiểm soát.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Bảng dưới ghi một lần chạy mẫu để BA biến nhu cầu “kiểm soát phê duyệt đơn mua nguyên liệu” thành workflow có thể review. Workflow là luồng công việc gồm trạng thái, người xử lý, điều kiện chuyển và bằng chứng. Không suy ra chính sách tiền tệ, kế toán hay thẩm quyền thật từ ví dụ này.

Mục	Nội dung chạy mẫu
Facts	Yêu cầu mua PR-2026-0817 tạo ngày 2026-08-07, nguyên liệu mô phỏng RM-SUGAR-001, tổng giá trị 48.500.000 VND, bộ phận yêu cầu: Sản xuất.
Current Behavior	Người mua gửi email riêng cho Trưởng mua hàng; không có trạng thái chung, không biết ai đang giữ hồ sơ, không lưu lý do từ chối nhất quán.
Underlying Need	Cần một nguồn theo dõi duy nhất cho yêu cầu mua, chặn đơn vượt ngưỡng trước khi thành đơn mua, lưu bằng chứng quyết định để QA và Finance review.
Options	A: Email thủ công. B: Workflow ERP gồm DRAFT, SUBMITTED, IN_REVIEW, APPROVED, REJECTED, CANCELLED. C: Tự động tạo đơn mua ngay khi gửi.
Decision Criteria	Truy vết người quyết định; kiểm tra ngưỡng; tách người yêu cầu khỏi người phê duyệt; có lý do từ chối; không tự diễn giải quy định kế toán.
Decision	Chọn B. PR-2026-0817 chỉ được tạo đơn mua sau APPROVED; trạng thái hiện tại của artifact là IN_REVIEW, không phải phê duyệt nghiệp vụ.
Authority	Business Owner xác nhận ngưỡng và người phê duyệt; Accounting Owner kiểm tra tác động hạch toán; Security Owner kiểm tra quyền; QA Reviewer kiểm tra test basis. BA chỉ ghi nhận và duy trì truy vết.
Artifact	Workflow draft trong /02-handbook/13-process-design-workflows-and-approvals.md; liên kết thuật ngữ và ID với TRACEABILITY_ID_REGISTRY, quy tắc với CANONICAL_BUSINESS_RULES, trường dữ liệu với CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Đơn mua có thể được tạo không đúng quyền, bị chậm do không rõ người xử lý, hoặc không đủ bằng chứng khi kiểm tra nội bộ. Điều này là rủi ro mô phỏng, không phải kết luận tuân thủ pháp lý.

Lần thực thi	Actor	Action trên object	Evidence produced	Decision rule	Quality gate	Escalation route
1	Requester Sản xuất	Tạo PR-2026-0817, nhập mã nguyên liệu, số lượng, đơn giá giả định và lý do mua	Bản ghi yêu cầu mua trạng thái DRAFT	Không gửi nếu thiếu mã hàng, số lượng, đơn vị tính hoặc lý do	BA đối chiếu trường bắt buộc với CANONICAL_DATA_DICTIONARY	Thiếu định nghĩa trường: Data Owner
2	Requester Sản xuất	Gửi yêu cầu	Dấu thời gian gửi theo Asia/Ho_Chi_Minh, trạng thái SUBMITTED	Chỉ Requester được gửi yêu cầu do mình tạo	Không có trường trống; tổng tiền = số lượng × đơn giá	Sai phép tính: ERP Functional Lead
3	ERP workflow	Định tuyến PR-2026-0817 vào IN_REVIEW	Nhật ký chuyển trạng thái, người nhận review	Tổng 48.500.000 VND vượt ngưỡng giả định 20.000.000 VND, cần Trưởng mua hàng review	Ngưỡng là project assumption; chưa dùng cho vận hành thật	Ngưỡng hoặc thẩm quyền chưa xác nhận: Business Owner
4	Trưởng mua hàng	Review nhu cầu, giá và nhà cung cấp dự kiến	Nhận xét review; quyết định APPROVED hoặc REJECTED	Phê duyệt khi thông tin đủ và nhu cầu hợp lệ theo quy tắc đã được Business Owner xác nhận	Người review khác Requester; từ chối bắt buộc có lý do	Xung đột nhu cầu hay ngưỡng: Business Owner
5	Purchasing Officer	Tạo đơn mua từ yêu cầu đã APPROVED	Liên kết yêu cầu mua–đơn mua, mã đơn mua mô phỏng	Cấm tạo đơn mua từ DRAFT, SUBMITTED, IN_REVIEW, REJECTED, CANCELLED	QA kiểm tra liên kết nguồn và trạng thái	Lỗi trạng thái hoặc quyền: ERP Functional Lead và Security Owner
6	BA	Gói workflow, bảng quyết định và bằng chứng review để handoff có kiểm soát	Bản review package, traceability link, danh sách điểm Verification required	Không gắn nhãn baseline hay approval khi chưa có tham chiếu được ghi nhận	QA Reviewer kiểm tra đủ trạng thái, vai trò, điều kiện, bằng chứng	Mâu thuẫn source canonical: Principal IT Business Analyst / Technical Curriculum Author điều phối; chuyển đúng owner quyết định

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

stateDiagram-v2
    direction TB
    [*] --> DRAFT: Requester tạo PR-2026-0817
    DRAFT --> SUBMITTED: Requester gửi yêu cầu do mình tạo; đủ trường bắt buộc
    DRAFT --> CANCELLED: Requester hủy bản nháp
    SUBMITTED --> IN_REVIEW: Tổng 48.500.000 VND > ngưỡng giả định 20.000.000 VND
    SUBMITTED --> CANCELLED: Requester hủy trước quyết định
    IN_REVIEW --> APPROVED: Trưởng mua hàng phê duyệt; thông tin đủ và nhu cầu hợp lệ
    IN_REVIEW --> REJECTED: Trưởng mua hàng từ chối; bắt buộc ghi lý do
    APPROVED --> PURCHASE_ORDER_CREATED: Purchasing Officer tạo đơn mua
    REJECTED --> [*]
    CANCELLED --> [*]
    PURCHASE_ORDER_CREATED --> [*]

Sơ đồ là Mermaid state diagram, không phải BPMN. Điều kiện ngưỡng 20.000.000 VND là project assumption để học; Business Owner phải xác nhận trước khi biến thành quy tắc vận hành.

6. Output thu ???c

Core

Output là artifact, tức tài liệu hoặc cấu trúc dữ liệu có kiểm soát, được tạo hay cập nhật sau hoạt động thiết kế workflow và approval. Output không phải ý kiến trao đổi. Output phải có ID canonical, Owner, trạng thái, nội dung tối thiểu và lịch sử thay đổi để reviewer truy được: nội dung nào, dựa trên đầu vào nào, ai chịu trách nhiệm duy trì.

Evidence: workflow mua hàng có trạng thái, ngưỡng tiền và vai trò ở bước trước. Reasoning: nếu chỉ lưu sơ đồ, reviewer không kiểm tra được điều kiện chuyển trạng thái, quyền quyết định và liên kết requirement. Vì vậy cần bộ artifact tách theo mục đích kiểm tra.

Artifact ID canonical	Artifact tạo/cập nhật	Owner duy trì	Status	Nội dung tối thiểu	Nghĩa vụ change history
WF-PR-001	Workflow Specification cho Purchase Requisition	BA	IN_REVIEW	Mục tiêu, phạm vi, trigger, actor, trạng thái, transition, exception, assumption, link nguồn	Mỗi sửa đổi ghi version, ngày Asia/Ho_Chi_Minh, người sửa, trường đổi, lý do, ID liên quan
DT-PR-001	Decision Table, bảng quyết định cho routing approval	BA	IN_REVIEW	Điều kiện, giá trị điều kiện, kết quả routing, người quyết định, ngoại lệ, assumption	Ghi rõ dòng quyết định thêm, sửa hoặc bỏ; không sửa im lặng ngưỡng hay authority
RM-PR-001	Responsibility Matrix, ma trận trách nhiệm	BA	IN_REVIEW	Hoạt động, vai trò thực hiện, vai trò quyết định, reviewer, escalation owner	Ghi thay đổi vai trò, lý do và ảnh hưởng segregation of duties
TR-PR-001	Traceability Matrix, ma trận truy vết	BA	IN_REVIEW	Link từ nhu cầu, rule, workflow state, decision row đến output liên quan	Ghi ID liên kết thêm, bỏ hoặc đổi; giữ ID cũ để truy lịch sử
RP-PR-001	Review Package, gói review	BA	IN_REVIEW	Danh sách artifact, version, điểm cần review, assumption, Verification required, open issue	Ghi artifact vào hoặc ra khỏi gói, lý do, ngày và người cập nhật

IN_REVIEW nghĩa artifact đang được kiểm tra có kiểm soát. Nó không nghĩa APPROVED, BASELINED, production-ready hay được người dùng chấp thuận. Owner duy trì artifact và traceability; Owner không tự xác nhận rule nghiệp vụ, legal interpretation, accounting treatment, security compliance hoặc quyền triển khai.

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

flowchart TB
    N[Nhu cầu]
    R[Rule]
    A[Thiết kế workflow và approval]

    subgraph O[Output tạo hoặc cập nhật]
        B[WF-PR-001<br/>Workflow Specification]
        C[DT-PR-001<br/>Decision Table]
        D[RM-PR-001<br/>Responsibility Matrix]
        E[TR-PR-001<br/>Traceability Matrix]
        F[RP-PR-001<br/>Review Package]
    end

    M[Metadata mọi artifact<br/>Owner: BA<br/>Status: IN_REVIEW<br/>ID canonical<br/>Change history]
    S[IN_REVIEW không phải<br/>APPROVED, BASELINED,<br/>production-ready, user-accepted]
    V[Assumption<br/>Verification required<br/>Open issue]

    N -->|đầu vào thiết kế| A
    R -->|đầu vào thiết kế| A

    A -->|tạo/cập nhật| B
    A -->|tạo/cập nhật| C
    A -->|tạo/cập nhật| D

    N -->|traceability link| E
    R -->|traceability link| E
    B -->|workflow state| E
    C -->|decision row| E
    D -->|responsibility link| E

    B -->|bằng chứng review| F
    C -->|bằng chứng review| F
    D -->|bằng chứng review| F
    E -->|bằng chứng review| F
    V -->|điểm cần review| F

    M -.-> B
    M -.-> C
    M -.-> D
    M -.-> E
    M -.-> F
    S -.-> M

Sơ đồ mô tả quan hệ artifact, không phải BPMN. TR-PR-001 nối output với nguồn và quyết định; RP-PR-001 gom bằng chứng cho downstream review.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là synthetic data. Facts: yêu cầu mua PR-2026-0817 có tổng giá trị mô phỏng 25.000.000 VND; workflow trước đó nêu chuyển sang IN_REVIEW khi tổng lớn hơn 20.000.000 VND. Current Behavior: Purchasing Officer chỉ tạo đơn mua sau trạng thái APPROVED. Underlying Need: reviewer cần kiểm tra được ngưỡng, authority và liên kết từ yêu cầu mua đến output thiết kế.

Trường Applied bắt buộc	Giá trị
Facts	PR-2026-0817; 25.000.000 VND; ngưỡng project assumption 20.000.000 VND; locale vi-VN; timezone Asia/Ho_Chi_Minh
Current Behavior	SUBMITTED chuyển IN_REVIEW khi tổng lớn hơn ngưỡng; Purchasing Officer chỉ tạo đơn mua từ APPROVED
Underlying Need	Tách logic workflow, logic quyết định, trách nhiệm và truy vết để review không suy diễn từ sơ đồ
Options	Một tài liệu duy nhất; hoặc năm artifact kiểm soát WF-PR-001, DT-PR-001, RM-PR-001, TR-PR-001, RP-PR-001
Decision Criteria	Truy được nguồn; kiểm tra độc lập; không nhân bản rule; Owner rõ; đổi ngưỡng không làm mất lịch sử
Decision	Dùng năm artifact kiểm soát; DT-PR-001 là nguồn cho routing decision, không chép rule độc lập vào artifact khác
Authority	Business Owner xác nhận ngưỡng và authority; BA duy trì artifact; QA Reviewer kiểm tra tính đủ; không có approval được ghi nhận
Artifact	WF-PR-001, DT-PR-001, RM-PR-001, TR-PR-001, RP-PR-001; tất cả IN_REVIEW, v0.9.0, ngày 2026-08-07
Consequence if Wrong	Ngưỡng có thể bị áp dụng khác nhau, người không có thẩm quyền có thể được gán quyền, hoặc downstream reviewer không truy được quyết định về nguồn

Change-history khởi tạo cho từng artifact: v0.9.0 | 2026-08-07 | Principal IT Business Analyst / Technical Curriculum Author | Khởi tạo output workflow purchase requisition cho case Nova Foods mô phỏng | Status IN_REVIEW. Dòng này ghi nhận khởi tạo quản trị, không ghi nhận approval hay baseline.

Senior Lens

Không dùng filename thay cho canonical ID. Filename có thể đổi do cấu trúc thư mục; ID là khóa truy vết. Không dùng trạng thái workflow nghiệp vụ như APPROVED để mô tả trạng thái tài liệu. Ví dụ, PR-2026-0817 có thể đạt APPROVED trong mô phỏng, nhưng WF-PR-001 vẫn là IN_REVIEW.

Không tạo artifact mới chỉ để chép lại nội dung. Evidence: DT-PR-001 đã chứa routing logic. Reasoning: chép ngưỡng sang WF-PR-001 mà không ghi nguồn tạo hai nguồn chân lý. WF-PR-001 chỉ tham chiếu DT-PR-001 cho điều kiện routing; thay đổi ngưỡng phải bắt đầu tại decision table, rồi cập nhật traceability và change history.

Quick Reference

Quy tắc	Áp dụng
Mỗi output có một ID canonical	Dùng đúng WF-PR-001, DT-PR-001, RM-PR-001, TR-PR-001, RP-PR-001 khi liên kết
Mỗi output có một Owner duy trì	Owner duy trì không đồng nghĩa Owner có authority quyết định
Mỗi output giữ IN_REVIEW	Không suy diễn approval, baseline hay production readiness
Mỗi thay đổi có history	Ghi version, ngày, người sửa, nội dung đổi, lý do và ID bị ảnh hưởng
Mỗi rule có nguồn rõ	Rule chưa được Business Owner xác nhận giữ nhãn project assumption hoặc Verification required

Core

Output workflow là artifact ghi được quy trình đã phân tích để vai trò sau review cùng đọc một nguồn. Anatomy tối thiểu: mục tiêu, phạm vi, trigger, actor, bước xử lý, quyết định, dữ liệu vào/ra, quy tắc tham chiếu, ngoại lệ, handoff, giả định và liên kết nguồn. Mỗi trường trả lời một câu: quy trình làm gì, ai làm, khi nào làm, dùng dữ liệu nào, chọn theo tiêu chí nào, và lỗi ở đâu.

Sơ đồ trên là Mermaid flowchart, không phải BPMN. Nó diễn đạt luồng logic để reviewer kiểm tra thiếu bước, không xác nhận cấu hình ERP.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Không gán canonical ID mới vì dependency cung cấp chưa đăng ký ID riêng cho workflow này. Artifact giữ liên kết canonical tới nguồn đã có.

Thành phần anatomy	Nội dung đã điền
Facts	Bộ phận Mua hàng tạo đơn mua hàng mô phỏng PO-NF-2026-00017; tổng tiền 68.400.000 VND; nhà cung cấp tổng hợp SUP-NF-014.
Current Behavior	Đơn mua hàng có thể được chuyển sang đặt hàng dù tổng tiền vượt ngưỡng kiểm soát; không có điểm ghi nhận quyết định trong mô tả hiện tại.
Underlying Need	Cần làm rõ điều kiện nào đưa đơn sang bước xử lý của Trưởng phòng Mua hàng, để người xây dựng, QA và nghiệp vụ cùng kiểm tra một luồng.
Trigger	Nhân viên Mua hàng hoàn tất nhập đơn mua hàng.
Actor	Nhân viên Mua hàng tạo đơn; Trưởng phòng Mua hàng xử lý đơn vượt ngưỡng; ERP lưu trạng thái xử lý mô phỏng.
Input data	purchaseOrderNo=PO-NF-2026-00017; supplierId=SUP-NF-014; totalAmount=68400000; currency=VND; createdAt=2026-08-07T09:30:00+07:00.
Process steps	1. ERP nhận đơn đã hoàn tất nhập. 2. ERP đọc totalAmount. 3. ERP so sánh tổng tiền với 50.000.000 VND. 4. Nếu lớn hơn ngưỡng, ERP đưa đơn vào hàng chờ của Trưởng phòng Mua hàng. 5. Nếu không lớn hơn, ERP chuyển đơn sang bước đặt hàng.
Decision	totalAmount > 50000000 theo VND.
Options	Giữ cùng một luồng cho mọi đơn; hoặc tách luồng khi đơn vượt ngưỡng.
Decision Criteria	Luồng phải cho thấy người xử lý khác nhau theo giá trị đơn; điểm quyết định phải dùng một trường dữ liệu và một phép so sánh kiểm tra được.
Decision	Chọn tách luồng khi totalAmount > 50.000.000 VND. Bằng chứng: Facts có tổng tiền 68.400.000 VND, lớn hơn ngưỡng 50.000.000 VND; vì vậy đơn ví dụ đi vào hàng chờ của Trưởng phòng Mua hàng.
Authority	Ngưỡng và vai trò là giả định dự án cho học liệu. Business Owner phải xác nhận nếu dùng cho vận hành; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.
Output data	purchaseOrderNo; totalAmount; routingResult; assignedRole; decisionRecordedAt.
Exception	Thiếu totalAmount, sai định dạng số, hoặc tiền tệ khác VND: không tự chuyển luồng; ghi lỗi dữ liệu để người tạo đơn sửa.
Artifact	Bản mô tả workflow trong /02-handbook/13-process-design-workflows-and-approvals.md, section 06-outputs; nguồn quản trị: CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Nếu so sánh sai hoặc thiếu ngoại lệ, đơn vượt ngưỡng có thể đi sai người xử lý; QA không có điều kiện rõ để kiểm thử; traceability từ rule sang workflow bị đứt.
Change history entry	2026-08-07, Asia/Ho_Chi_Minh, v0.9.0, IN_REVIEW: bổ sung anatomy workflow mô phỏng cho đơn PO-NF-2026-00017; không baseline, không approval, không production-ready.

Senior Lens

Đừng viết “cần duyệt đơn lớn” rồi dừng. Câu đó thiếu ngưỡng, toán tử, dữ liệu nguồn, actor và nhánh lỗi. Reviewer không thể biết 50.000.000 VND có bao gồm thuế, chiết khấu hay phí vận chuyển không nếu artifact không nêu. Trong ví dụ này, totalAmount chỉ là tên trường mô phỏng; nghĩa dữ liệu chi tiết phải được kiểm soát tại CANONICAL_DATA_DICTIONARY, còn ngưỡng phải được kiểm soát tại CANONICAL_BUSINESS_RULES khi có nội dung được đăng ký.

Quick Reference

Kiểm tra anatomy	Giá trị trong ví dụ
Có trigger	Có: hoàn tất nhập đơn
Có actor	Có: Nhân viên Mua hàng, Trưởng phòng Mua hàng, ERP
Có dữ liệu quyết định	Có: totalAmount
Có điều kiện kiểm tra được	Có: totalAmount > 50000000
Có nhánh ngoại lệ	Có: thiếu hoặc sai totalAmount, tiền tệ khác VND
Có nguồn canonical	Có: CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY
Có khẳng định approval hoặc production	Không

Core

Cổng chất lượng là tập điều kiện kiểm tra trước khi một output được chuyển sang downstream review, tức xem xét bởi vai trò dùng output làm đầu vào tiếp theo. Cổng này xác nhận output đủ rõ, đủ truy vết, đủ nhất quán để review; không xác nhận approval, baseline, tuân thủ pháp lý, cấu hình ERP hay production readiness.

Điều kiện bắt buộc	Cách kiểm tra	Bằng chứng tối thiểu	Kết quả khi không đạt
Định danh đúng	ID và filename khớp registry/manifest canonical	Canonical ID, controlled path, v0.9.0, IN_REVIEW	Không chuyển review
Phạm vi rõ	Nêu process boundary, trigger, outcome, ngoại lệ	Mục tiêu và boundary viết rõ	Trả lại làm rõ
Nội dung kiểm tra được	Mỗi bước, rule, dữ liệu, quyết định có tiêu chí xác minh	Reference nguồn hoặc project assumption/Verification required	Không để reviewer tự suy diễn
Truy vết đủ	Liên kết input, quyết định và output liên quan	ID canonical của nguồn liên quan	Gắn lỗi traceability
Không vượt thẩm quyền	Không biến giả định thành quyết định pháp lý, kế toán, bảo mật hoặc vận hành	Nhãn escalation hoặc Verification required	Dừng chuyển review
Dữ liệu an toàn	Chỉ dùng Nova Foods mô phỏng, dữ liệu tổng hợp	Không có dữ liệu cá nhân hay dữ liệu doanh nghiệp thật	Loại bỏ dữ liệu không hợp lệ

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Current Behavior: BA hoàn thành output mô tả luồng duyệt yêu cầu mua hàng nhưng chưa kiểm tra liên kết nguồn và giả định.

Underlying Need: Reviewer cần biết luồng có thể đọc, kiểm tra và phản biện được mà không phải đoán rule, thẩm quyền hoặc dữ liệu.

Thành phần	Giá trị micro-example
Options	Chuyển ngay sang review; kiểm cổng chất lượng trước
Decision Criteria	Có ID canonical; status IN_REVIEW; nguồn/giả định rõ; không có quyết định vượt thẩm quyền; dữ liệu tổng hợp
Decision	Chỉ chuyển khi mọi điều kiện cổng đạt
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact; Business Owner, Legal Owner, Accounting Owner, Security, Architect và QA giữ thẩm quyền chuyên môn tương ứng
Artifact	Output giữ canonical ID và filename đã đăng ký; không tạo ID thay thế
Consequence if Wrong	Reviewer dựa vào rule không có nguồn, nhầm giả định thành yêu cầu, hoặc dùng output chưa đủ kiểm tra làm đầu vào tiếp theo

Lý do: IN_REVIEW chỉ nói artifact đang được xem xét. Vì chưa có baseline reference và approval reference, cổng chất lượng không được đổi status thành APPROVED, BASELINED hoặc production-ready.

Senior Lens

Không dùng “đã qua QA” nếu chỉ có kiểm tra hình thức. Output chỉ sẵn sàng review khi reviewer độc lập có thể lần từ một kết luận về input, nguồn, giả định và người có thẩm quyền mà không cần hỏi tác giả để hiểu ý nghĩa. Nếu nguồn pháp lý, kế toán, an toàn thực phẩm, dữ liệu cá nhân hoặc bảo mật chưa được xác minh từ nguồn chính thức hiện hành, ghi Verification required; không thay nhãn này bằng câu khẳng định.

Quick Reference

Quy tắc	Áp dụng
Ready for downstream review	Đủ định danh, phạm vi, truy vết, bằng chứng, boundary thẩm quyền, dữ liệu tổng hợp
Not ready	Thiếu nguồn, ID không canonical, rule mơ hồ, giả định không gắn nhãn, dữ liệu không an toàn
Status hợp lệ hiện tại	IN_REVIEW
Không được suy ra	Approval, baseline, compliance, production readiness, user approval

7. Who consumes those outputs?

Core

Output của thiết kế quy trình không tự tạo giá trị. Giá trị xuất hiện khi đúng vai trò dùng output để làm quyết định hoặc công việc tiếp theo. Trong Nova Foods Trading & Manufacturing, đây là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Các output vẫn ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline, approval hay chỉ dẫn production.

Consumer	Output tiêu thụ	Cách dùng trong công việc
Developers	Luồng nghiệp vụ, quy tắc nghiệp vụ, yêu cầu dữ liệu, acceptance criteria	Chuyển hành vi mong muốn thành màn hình, API, kiểm tra dữ liệu và trạng thái hệ thống
QA	Luồng nghiệp vụ, ngoại lệ, acceptance criteria, traceability	Lập test basis, thiết kế test case và kiểm tra hành vi thực tế so với yêu cầu
Architect	Luồng liên phòng ban, điểm tích hợp, dữ liệu dùng chung, yêu cầu phi chức năng	Đánh giá ranh giới hệ thống, ownership dữ liệu, tích hợp, bảo mật và khả năng vận hành
PM/Product Owner	Phạm vi quy trình, ưu tiên, phụ thuộc, acceptance criteria	Sắp xếp backlog, kế hoạch phát hành và trade-off giữa phạm vi, thời gian, chi phí
Business Owner	Luồng nghiệp vụ mục tiêu, quy tắc, điểm phê duyệt, ngoại lệ	Xác nhận quy trình có phục vụ mục tiêu kinh doanh mô phỏng và chịu trách nhiệm quyết định nghiệp vụ
Operations	Hướng dẫn luồng thao tác, điều kiện chuyển trạng thái, xử lý ngoại lệ	Chuẩn bị vận hành, phân vai người dùng và nhận diện tình huống cần can thiệp thủ công
Specialist owners	Quy tắc và dữ liệu thuộc chuyên môn: kế toán, pháp lý, an toàn thực phẩm, bảo mật, dữ liệu cá nhân	Kiểm tra nội dung thuộc thẩm quyền chuyên môn; không để BA hoặc Developer tự diễn giải thay

Applied

Facts: Nova Foods mô phỏng có luồng “Tạo đơn bán hàng → Kiểm tra tồn kho → Chờ phê duyệt giá → Xuất hàng”. Output gồm sơ đồ luồng, điều kiện phê duyệt giá, trường dữ liệu đơn hàng và acceptance criteria.

Current Behavior: Developer đọc “chờ phê duyệt giá” như một màn hình nhập ghi chú. QA đọc đây là trạng thái phải kiểm thử. Operations đọc đây là điểm nhân viên phải dừng xử lý. Cùng một output được tiêu thụ khác nhau vì mỗi vai trò chịu trách nhiệm cho phần khác nhau của kết quả.

Underlying Need: Một quy trình cần giữ cùng ý nghĩa khi đi từ nghiệp vụ sang cấu hình, phát triển, kiểm thử và vận hành. Nếu mỗi consumer tự diễn giải, cùng một trạng thái có thể thành ba hành vi khác nhau.

Options: (1) Chỉ gửi sơ đồ quy trình. (2) Gửi sơ đồ kèm quy tắc, dữ liệu và acceptance criteria liên kết. (3) Gửi mô tả tự do trong email.

Decision Criteria: Consumer phải nhìn thấy hành vi cần thực hiện, điểm bắt đầu và kết thúc, dữ liệu liên quan, ngoại lệ, và ranh giới trách nhiệm. Output không được biến giả định thành quy tắc canonical.

Decision: Dùng gói output liên kết: luồng quy trình cho trình tự; quy tắc nghiệp vụ cho điều kiện; từ điển dữ liệu cho ý nghĩa trường; acceptance criteria cho kết quả kiểm thử được.

Authority: Business Owner giữ quyết định nghiệp vụ. Architect giữ quyết định kiến trúc. QA giữ đánh giá kiểm thử. Specialist owner giữ kết luận chuyên môn. Principal IT Business Analyst / Technical Curriculum Author duy trì traceability, không thay thế các thẩm quyền này.

Artifact: Tham chiếu đúng artifact canonical: /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Không tạo ID hoặc filename thay thế.

Consequence if Wrong: Developer có thể cho xuất hàng khi giá chưa được phê duyệt; QA có thể bỏ sót trạng thái; Operations có thể xử lý sai hàng chờ. Đây là lỗi diễn giải output, không phải bằng chứng rằng Nova Foods có quy trình thật.

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

flowchart TB
    subgraph PROC["Luồng quy trình"]
        START([Bắt đầu])
        CREATE["Tạo đơn bán hàng"]
        STOCK["Kiểm tra tồn kho"]
        WAIT["Trạng thái: Chờ phê duyệt giá"]
        APPROVED{"Giá đã được phê duyệt?"}
        SHIP["Xuất hàng"]
        END([Kết thúc])

        START --> CREATE
        CREATE --> STOCK
        STOCK --> WAIT
        WAIT --> APPROVED
        APPROVED -- "Đã phê duyệt" --> SHIP
        APPROVED -- "Chưa phê duyệt: giữ đơn" --> WAIT
        SHIP --> END
    end

    subgraph OUT["Gói output liên kết"]
        PKG["Gói output"]
        FLOW["Luồng quy trình"]
        RULES["Quy tắc nghiệp vụ"]
        DATA["Từ điển dữ liệu"]
        AC["Acceptance criteria"]

        PKG -->|"gồm"| FLOW
        PKG -->|"gồm"| RULES
        PKG -->|"gồm"| DATA
        PKG -->|"gồm"| AC
    end

    FLOW -->|"trình tự, điểm bắt đầu và kết thúc"| START
    RULES -->|"điều kiện chuyển trạng thái"| APPROVED
    DATA -->|"ý nghĩa trường đơn hàng"| CREATE
    AC -->|"kiểm thử trạng thái chờ"| WAIT
    AC -->|"kiểm thử chuyển tiếp phê duyệt"| APPROVED

    subgraph CONSUMERS["Cùng trạng thái, trách nhiệm khác nhau"]
        DEV["Developer: xây hành vi giữ đơn và chuyển trạng thái"]
        QA["QA: kiểm thử trạng thái chờ và chuyển tiếp"]
        OPS["Operations: dừng xử lý đơn đang chờ"]
    end

    WAIT -->|"consumer phát triển"| DEV
    WAIT -->|"consumer kiểm thử"| QA
    WAIT -->|"consumer vận hành"| OPS

    subgraph RISKS["Hậu quả khi diễn giải sai"]
        BADSHIP["Developer cho xuất hàng khi giá chưa được phê duyệt"]
        MISSED["QA bỏ sót trạng thái chờ"]
        BADOPS["Operations xử lý sai đơn đang chờ"]
    end

    WAIT -. "nếu bị đọc như ghi chú thay vì trạng thái" .-> BADSHIP
    WAIT -. "nếu không được kiểm thử như trạng thái" .-> MISSED
    WAIT -. "nếu không nhận biết điểm phải dừng" .-> BADOPS

    subgraph CANON["Artifact canonical"]
        ART_RULES["/01-curriculum/CANONICAL_BUSINESS_RULES.md"]
        ART_DATA["/01-curriculum/CANONICAL_DATA_DICTIONARY.md"]
        ART_TRACE["/01-curriculum/TRACEABILITY_ID_REGISTRY.md"]
    end

    RULES -->|"tham chiếu"| ART_RULES
    DATA -->|"tham chiếu"| ART_DATA
    PKG -->|"duy trì traceability"| ART_TRACE

    subgraph AUTH["Ranh giới trách nhiệm và thẩm quyền"]
        BA["Principal IT Business Analyst / Technical Curriculum Author"]
        BO["Business Owner"]
        ARC["Architect"]
        SPO["Specialist owner"]
    end

    BA -->|"duy trì traceability; không thay thế thẩm quyền"| PKG
    BO -->|"quyết định nghiệp vụ"| RULES
    ARC -->|"quyết định kiến trúc; đánh giá ranh giới và tích hợp"| PKG
    QA -->|"đánh giá kiểm thử"| AC
    SPO -->|"kết luận chuyên môn"| PKG

Senior Lens

Không giao “workflow” như một hình vẽ độc lập. Developer cần biết trạng thái nào phải lưu; QA cần biết điều kiện nào phân biệt pass và fail; Operations cần biết ai làm gì tại điểm dừng. Cùng một output chỉ hữu dụng nếu cách dùng của consumer được chỉ rõ ngay trong gói bàn giao.

Tách consumer khỏi authority. Ví dụ, PM/Product Owner có thể dùng quy tắc giá để ưu tiên backlog, nhưng không vì thế có quyền tự xác nhận diễn giải kế toán hoặc pháp lý. Consumer là người dùng output; authority là người chịu trách nhiệm quyết định trong phạm vi được giao.

Quick Reference

Output	Consumer chính	Mục đích dùng
Sơ đồ workflow	Developers, QA, Operations	Hiểu thứ tự bước, trạng thái và điểm bàn giao
Quy tắc nghiệp vụ	Developers, QA, Business Owner, specialist owners	Áp dụng điều kiện và kiểm tra ngoại lệ
Từ điển dữ liệu	Developers, Architect, QA	Thống nhất nghĩa, nguồn và cách dùng dữ liệu
Acceptance criteria	QA, Developers, PM/Product Owner	Xác định kết quả phải quan sát được
Traceability	BA, QA, PM/Product Owner, Architect	Theo từ output về nguồn và dependency

Core

Đầu ra thiết kế quy trình Nova Foods là mô phỏng giáo dục, 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. Người nhận không được coi đầu ra review là phê duyệt, baseline, cấu hình ERP hay chỉ dẫn production. Mỗi quyết định phải có bằng chứng truy vết về nguồn, giả định, quy tắc, dữ liệu và thẩm quyền.

Người nhận	Có thể quyết định	Bằng chứng cần có	Phải escalation khi
Developer	Cách hiện thực màn hình, API, kiểm tra dữ liệu, xử lý lỗi trong phạm vi yêu cầu	Luồng quy trình, điều kiện vào/ra, quy tắc từ CANONICAL_BUSINESS_RULES, trường dữ liệu từ CANONICAL_DATA_DICTIONARY, tiêu chí chấp nhận	Quy tắc mơ hồ; API ảnh hưởng hệ thống khác; yêu cầu lưu hoặc lộ dữ liệu cá nhân
QA	Phạm vi kiểm thử, dữ liệu kiểm thử tổng hợp, test case, mức độ truy hồi lỗi	Acceptance criteria, nhánh ngoại lệ, trạng thái, quyền, traceability	Không xác định kết quả mong đợi; rủi ro an toàn thực phẩm, kế toán, dữ liệu cá nhân; không có owner xác nhận quy tắc
Architect	Mẫu tích hợp, ranh giới hệ thống, quyền kỹ thuật, phi chức năng	Sơ đồ luồng, hệ thống nguồn/đích, dữ liệu trao đổi, tải dự kiến, rủi ro bảo mật	Thay đổi kiến trúc; tích hợp mới; dữ liệu nhạy cảm; xung đột với chuẩn kỹ thuật
PM/Product Owner	Ưu tiên, phạm vi release, thứ tự giao, chấp nhận trade-off sản phẩm	Giá trị nghiệp vụ, phụ thuộc, ước lượng, rủi ro, tiêu chí hoàn thành	Trade-off làm đổi mục tiêu nghiệp vụ; vượt ngân sách hoặc mốc giao; xung đột ưu tiên giữa đơn vị
Business Owner	Ý nghĩa quy tắc, ngoại lệ nghiệp vụ, mức chấp nhận quy trình	Mục tiêu, ví dụ giao dịch tổng hợp, tác động vận hành, chỉ số thành công	Quyết định ảnh hưởng doanh thu, khách hàng, chính sách giá, trách nhiệm phê duyệt
Operations	Khả năng vận hành hằng ngày, xử lý ngoại lệ, phân quyền tác nghiệp, báo cáo theo dõi	Khối lượng công việc, thời gian xử lý, tình huống lỗi, hướng dẫn vận hành dự kiến	Quy trình tăng thao tác tay, tạo tắc nghẽn, thiếu người xử lý hoặc không có đường khôi phục
Specialist owner	Kết luận chuyên môn thuộc kế toán, pháp lý, bảo mật, an toàn thực phẩm hoặc dữ liệu cá nhân	Nguồn chính thức, phạm vi áp dụng, giả định dự án, phân tích tác động	Nội dung bị diễn đạt như nghĩa vụ pháp lý, kế toán, thuế, tuân thủ hoặc an toàn thực phẩm

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

flowchart TB
    BA[BA ghi đầu ra IN_REVIEW] --> C[Người nhận kiểm tra nguồn, giả định,<br/>quy tắc, dữ liệu và thẩm quyền]
    C --> D{Bằng chứng đủ<br/>và quy tắc rõ?}
    D -->|Không| B[BA và người nhận phối hợp<br/>owner nguồn bổ sung hoặc làm rõ bằng chứng]
    B --> S[Đầu ra tiếp tục IN_REVIEW]
    S --> C
    D -->|Có| A{Quyết định trong thẩm quyền<br/>và không chạm ngưỡng<br/>rủi ro/chuyên môn?}
    A -->|Có| R[Người nhận ghi quyết định<br/>và traceability: nguồn, giả định,<br/>quy tắc, dữ liệu, thẩm quyền]
    A -->|Không: vượt thẩm quyền hoặc<br/>chạm ngưỡng rủi ro/chuyên môn| E[Escalation tới owner<br/>có thẩm quyền phù hợp]
    E --> I[Đầu ra tiếp tục IN_REVIEW]
    I --> V[Owner xác minh bằng chứng<br/>và làm rõ quy tắc]
    V --> O{Owner có đủ bằng chứng<br/>để quyết định?}
    O -->|Không| B
    O -->|Có| RO[Owner ghi quyết định<br/>và traceability: nguồn, giả định,<br/>quy tắc, dữ liệu, thẩm quyền]
    R --> N[Không phải phê duyệt, baseline,<br/>cấu hình ERP hoặc chỉ dẫn production]
    RO --> N

Applied

Facts: Nova Foods mô phỏng có yêu cầu: đơn bán hàng vượt 50.000.000 VND cần bước xem xét trước khi xuất kho.

Current Behavior: Luồng ghi “quản lý duyệt” nhưng không nêu quản lý nào, dữ liệu nào chứng minh ngưỡng, hay đơn bị sửa sau duyệt xử lý ra sao.

Underlying Need: Developer cần điều kiện kỹ thuật. QA cần kết quả mong đợi. Operations cần biết ai xử lý đơn treo. Business Owner cần xác định ngoại lệ có hợp lệ không.

Options: Giữ ngưỡng cố định trong mã; cấu hình ngưỡng trong ERP; dừng yêu cầu đến khi Business Owner xác định ngưỡng và vai trò duyệt.

Decision Criteria: Quyết định chỉ hợp lệ khi có owner nghiệp vụ, nguồn dữ liệu giá trị đơn, trạng thái sau duyệt, xử lý sửa đơn, và bằng chứng thẩm quyền.

Decision: Không chọn cách hiện thực. Ghi giả định dự án: ngưỡng 50.000.000 VND là dữ liệu tổng hợp phục vụ học liệu; cần xác minh trước khi thành quy tắc.

Authority: Business Owner quyết định mục tiêu và ngoại lệ. Architect quyết định cách tích hợp hoặc cấu hình. Specialist owner phải xác minh nếu giá trị đơn liên quan diễn giải kế toán, thuế hoặc pháp lý.

Artifact: Liên kết quy tắc dự kiến với CANONICAL_BUSINESS_RULES; liên kết trường giá trị đơn với CANONICAL_DATA_DICTIONARY; giữ trạng thái IN_REVIEW.

Consequence if Wrong: Developer có thể chặn đơn hợp lệ hoặc cho xuất kho đơn cần kiểm soát. QA không có oracle kiểm thử. Operations xử lý tay không nhất quán. Không được suy diễn đây là chính sách thật của Nova Foods.

Senior Lens

Escalation không phải chuyển trách nhiệm. BA đóng gói vấn đề để owner quyết định: câu hỏi, lựa chọn, bằng chứng, tác động, deadline và traceability. BA không tự kết luận pháp lý, kế toán, bảo mật, an toàn thực phẩm hoặc thẩm quyền phê duyệt.

Quick Reference

Hiểu nhầm bàn giao	Câu hỏi làm rõ chính xác
“Developer tự chọn luồng duyệt.”	“Vai trò nào có thẩm quyền xác định người duyệt, điều kiện duyệt và ngoại lệ?”
“QA tự suy ra kết quả đúng.”	“Với đơn bị sửa sau duyệt, trạng thái mong đợi, người xử lý và bằng chứng chấp nhận là gì?”
“Architect xác nhận mọi quy tắc.”	“Đây là quyết định kiến trúc hay quyết định nghiệp vụ; owner nào chịu trách nhiệm nội dung?”
“Operations xử lý mọi ngoại lệ.”	“Ngoại lệ nào được phép xử lý vận hành, ngoại lệ nào phải chuyển Business Owner hoặc specialist owner?”
“IN_REVIEW đủ để phát triển.”	“Bằng chứng nào cho phép bắt đầu build, và điểm nào phải dừng vì chưa có quyết định thuộc thẩm quyền?”

Core

Hiểu nhầm bàn giao xảy ra khi người nhận biến output của BA thành loại tài liệu khác: sơ đồ luồng bị đọc như quyết định phân quyền, quy tắc nghiệp vụ bị đọc như chi tiết kỹ thuật, hoặc acceptance criteria bị đọc như bằng chứng kiểm thử đã đạt. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, mọi câu hỏi làm rõ phải giữ ranh giới: artifact IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, không phải baseline hay phê duyệt.

Hiểu nhầm khi bàn giao	Vì sao sai, dựa trên bằng chứng	Câu hỏi làm rõ chính xác	Escalation bắt buộc khi
Developer đọc workflow là thiết kế API	Workflow chỉ mô tả trình tự nghiệp vụ và điểm quyết định; không chứng minh endpoint, payload, xác thực hoặc lỗi HTTP.	“Bước Gửi duyệt cần tạo, cập nhật hay chỉ hiển thị bản ghi nào; trường dữ liệu, chủ sở hữu dữ liệu và điều kiện lỗi nào đã được xác định trong CANONICAL_DATA_DICTIONARY?”	Cần chọn giao thức, tích hợp, quyền API hoặc cơ chế bảo mật. Escalate Architect và Security Owner.
QA đọc acceptance criteria là test case hoàn chỉnh	Acceptance criteria nêu điều kiện chấp nhận; test case cần dữ liệu kiểm thử, bước thực hiện, kết quả mong đợi, phạm vi âm và bằng chứng chạy test.	“Tiêu chí này xác nhận hành vi nào; dữ liệu biên nào phải thử; kết quả nào là pass; và nguồn nào xác nhận quy tắc?”	Quy tắc mâu thuẫn, không đo được, hoặc cần diễn giải pháp lý, kế toán, an toàn thực phẩm.
Architect đọc business rule là kiến trúc đã chốt	Business rule nêu ràng buộc nghiệp vụ; không tự quyết nơi xử lý tại ERP, service, database hay workflow engine.	“Quy tắc cần được thực thi tại điểm nào để không bị bỏ qua bởi giao diện, import và API; lựa chọn đó dựa trên ràng buộc kỹ thuật nào?”	Quyết định ảnh hưởng tích hợp, hiệu năng, bảo mật, tính sẵn sàng hoặc nhiều hệ thống.
PM/Product Owner đọc mô tả quy trình là phạm vi sprint đã cam kết	Mô tả quy trình cho biết nhu cầu; chưa có ước lượng, ưu tiên, dependency kỹ thuật hoặc cam kết phát hành.	“Phần nào là kết quả tối thiểu cần có cho mục tiêu phát hành; dependency nào chặn delivery; tiêu chí nào quyết định cắt phạm vi?”	Thay đổi làm lệch mục tiêu sản phẩm, thời hạn, chi phí hoặc thứ tự ưu tiên.
Business Owner đọc prototype là hành vi ERP đã được xác nhận	Prototype minh họa để kiểm tra hiểu biết; không phải bằng chứng cấu hình, kiểm soát nghiệp vụ, kế toán hay pháp lý đã hợp lệ.	“Quyết định nghiệp vụ nào prototype đang minh họa; ngoại lệ nào phải được xử lý; ai có thẩm quyền xác nhận quy tắc này?”	Quy tắc tác động giá, hạn mức, ghi nhận kế toán, thuế hoặc nghĩa vụ khách hàng.
Operations đọc trạng thái quy trình là hướng dẫn vận hành production	Trạng thái mô tả mô hình mục tiêu; thiếu phân quyền thực, hướng dẫn sự cố, đào tạo, dữ liệu chuyển đổi và kiểm soát ca vận hành.	“Nhân viên vận hành làm gì khi bản ghi kẹt ở trạng thái này; ai xử lý; thời gian phản hồi nào là giả định dự án và bằng chứng nào xác nhận?”	Cần thay đổi SOP, quyền truy cập thực, xử lý sự cố hoặc ảnh hưởng liên tục vận hành.
Specialist Owner đọc nhãn Verification required là quy tắc đã đủ căn cứ	Nhãn này xác nhận chưa kiểm tra đủ nguồn hoặc thẩm quyền; không được chuyển thành yêu cầu bắt buộc.	“Nguồn chính thức nào cần kiểm tra; phiên bản và ngày hiệu lực nào áp dụng; kết luận cần do Legal Owner, Accounting Owner hay Food Safety Owner xác nhận?”	Có liên quan pháp luật dữ liệu cá nhân, kế toán, hóa đơn chứng từ, thuế, truy xuất hoặc thu hồi thực phẩm.

Applied

Facts: Workflow mô phỏng có bước “Xác nhận chênh lệch kiểm kê” trước khi điều chỉnh tồn kho. Developer hiểu rằng mọi chênh lệch phải tự động cập nhật tồn kho. QA viết test chỉ kiểm tra nút “Xác nhận” hoạt động.

Current Behavior: Artifact workflow chỉ nêu trạng thái và người xử lý. Không nêu công thức tồn kho, bút toán, quyền phê duyệt, API hay điều kiện chênh lệch.

Underlying Need: Cần tách rõ ý nghĩa nghiệp vụ “xác nhận chênh lệch” khỏi cách ERP thực hiện điều chỉnh.

Options: (1) Developer tự suy diễn cập nhật tồn kho. (2) BA ghi câu hỏi làm rõ và giữ trạng thái Verification required.

Decision Criteria: Chọn phương án không biến workflow thành quyết định kế toán, không tự tạo thiết kế kỹ thuật, và giữ traceability tới nguồn canonical.

Decision: Chọn phương án (2). Câu hỏi ghi nguyên văn: “Sau khi xác nhận chênh lệch kiểm kê, hệ thống chỉ ghi nhận kết quả kiểm kê hay tạo điều chỉnh tồn kho; điều kiện, người có thẩm quyền và ảnh hưởng kế toán nào áp dụng?”

Authority: Business Owner xác nhận ý nghĩa nghiệp vụ; Accounting Owner xác nhận ảnh hưởng kế toán; Architect quyết định vị trí thực thi; QA chuyển kết quả đã rõ thành test basis.

Artifact: Ghi câu hỏi, câu trả lời có nguồn, owner và trạng thái vào artifact kiểm soát phù hợp; tham chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY. Không gắn nhãn baseline hay approval.

Consequence if Wrong: Tồn kho mô phỏng có thể bị điều chỉnh sai, QA kiểm tra sai đối tượng, và team hiểu nhầm workflow là chỉ dẫn cấu hình ERP.

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

flowchart TB
    W[Workflow: Xác nhận chênh lệch] --> Q[BA: ghi câu hỏi làm rõ]
    Q --> QD[Chỉ ghi nhận kết quả hay tạo điều chỉnh tồn kho?<br/>Điều kiện, thẩm quyền, ảnh hưởng kế toán?]
    QD --> V[Trạng thái: Verification required]

    V --> N[Không tự suy diễn thành điều chỉnh tồn kho]
    V --> B[Business Owner: xác nhận ý nghĩa nghiệp vụ]
    V --> A[Accounting Owner: xác nhận ảnh hưởng kế toán]
    V --> R[Architect: quyết định vị trí thực thi]

    B --> X[Câu trả lời nghiệp vụ có nguồn]
    A --> Y[Câu trả lời kế toán có nguồn]
    R --> Z[Quyết định vị trí thực thi có nguồn]

    X --> G[Artifact kiểm soát:<br/>câu hỏi, câu trả lời, nguồn, owner, trạng thái]
    Y --> G
    Z --> G

    CBR[CANONICAL_BUSINESS_RULES] -. tham chiếu .-> G
    CDD[CANONICAL_DATA_DICTIONARY] -. tham chiếu .-> G
    TIR[TRACEABILITY_ID_REGISTRY] -. tham chiếu .-> G

    G --> OK{Đủ câu trả lời có nguồn<br/>và owner có thẩm quyền?}
    OK -- Không --> V
    OK -- Có --> CL[Trạng thái: Đã làm rõ]
    CL --> T[QA: test basis]
    CL --> D[Developer: thiết kế kỹ thuật]

    W -. không quyết định .-> BND[Không quyết định:<br/>công thức tồn kho, bút toán,<br/>quyền phê duyệt, API]
    G -. không gắn nhãn .-> NA[Không gắn nhãn baseline hay approval]

    SD[Tự suy diễn thành điều chỉnh tồn kho] -. dẫn tới .-> RISK[Nguy cơ: điều chỉnh tồn kho sai;<br/>QA kiểm tra sai đối tượng;<br/>workflow bị hiểu là chỉ dẫn cấu hình ERP]

Senior Lens

Câu hỏi tốt không hỏi “có làm được không”. Câu hỏi tốt khóa đối tượng, điều kiện, ngoại lệ, thẩm quyền và bằng chứng. Ví dụ, thay vì hỏi “Có cần duyệt không?”, hỏi: “Ai duyệt điều chỉnh tồn kho, với ngưỡng chênh lệch nào, ngoại lệ nào được phép, và nguồn nào xác nhận?” Cầu nối suy luận: không có ngưỡng và owner thì Developer không thể tạo kiểm soát nhất quán, QA không thể tạo dữ liệu biên, Operations không biết xử lý ngoại lệ.

Không dùng câu trả lời miệng không có nguồn làm quy tắc. Ghi tối thiểu: câu hỏi, artifact liên quan, người trả lời, vai trò có thẩm quyền, nguồn bằng chứng, quyết định hoặc Verification required, tác động tới workflow. Nếu câu trả lời vượt thẩm quyền người trả lời, BA giữ câu hỏi mở và escalation; không “điền hộ” để bàn giao nhanh.

Quick Reference

Trước khi bàn giao	Câu hỏi kiểm tra
Phân biệt artifact	“Đây là workflow, business rule, acceptance criteria hay thiết kế kỹ thuật?”
Xác định thiếu hụt	“Thông tin nào người nhận phải suy diễn nếu không được làm rõ?”
Xác định owner	“Ai có thẩm quyền quyết định nội dung này, không chỉ ai hiểu quy trình?”
Xác định bằng chứng	“Câu trả lời dựa trên nguồn canonical nào hoặc còn Verification required?”
Xác định escalation	“Nội dung có chạm pháp lý, kế toán, bảo mật, kiến trúc hoặc vận hành thực không?”

8. Detailed Worked Example

Core

Ví dụ này thuộc Nova Foods Trading & Manufacturing, case mô phỏng giáo dục, toàn bộ dữ liệu tổng hợp. Phạm vi chỉ ghi nhận facts (sự kiện có bằng chứng) và current behavior (cách quy trình đang vận hành). Chưa suy ra nhu cầu, phương án, tiêu chí, quyết định, thẩm quyền, artifact đích hay hậu quả.

Applied

Kịch bản: Kho Bình Dương phát hiện chênh lệch tồn kho thành phẩm NF-NUOC-500ML khi kiểm đếm cuối ngày 2026-08-07. Giao dịch dùng VND, thời gian ghi nhận theo Asia/Ho_Chi_Minh.

Nhóm fact	Giá trị mô phỏng	Bằng chứng trong kịch bản
Đơn vị vận hành	Nova Foods Trading & Manufacturing	Case mô phỏng giáo dục
Kho	Kho Bình Dương	Người kiểm kê chọn kho này trên phiếu đếm
Mã hàng	NF-NUOC-500ML	Mã in trên nhãn vị trí và phiếu đếm
Tên hàng	Nước giải khát Nova 500 ml	Dữ liệu tổng hợp
Đơn vị tính	Chai	Phiếu đếm dùng đơn vị chai
Lô hàng	LOT-NF-260805-A	Nhãn pallet hiển thị lô này
Vị trí	FG-BD-A03-02	Nhãn kệ kho
Số lượng hệ thống	1.200 chai	Nhân viên kho tra màn hình ERP lúc 16:35 ngày 2026-08-07
Số lượng đếm thực tế	1.164 chai	Hai nhân viên kho đếm lại lúc 16:42
Chênh lệch	-36 chai	1.164 - 1.200 = -36
Đơn giá quản trị mô phỏng	8.500 VND/chai	Dữ liệu giá trị minh họa, không phải giá kế toán
Giá trị chênh lệch mô phỏng	-306.000 VND	-36 × 8.500 VND
Người ghi nhận	WH-BD-014	ID nhân sự mô phỏng trên phiếu đếm
Người đếm đối chiếu	WH-BD-022	ID nhân sự mô phỏng trên phiếu đếm
Thời điểm tạo phiếu	2026-08-07T16:45:00+07:00	Dấu thời gian mô phỏng
Phiếu kiểm đếm	SIM-COUNT-BD-20260807-004	ID tình huống, không phải canonical ID
Trạng thái phiếu hiện tại	OPEN	Phiếu chưa được đóng trong kịch bản

Current Behavior — cách đang diễn ra. Nhân viên kho tạo phiếu kiểm đếm sau khi thấy lệch giữa số đếm và số ERP. Hệ thống cho phép lưu chênh lệch âm ngay trên phiếu SIM-COUNT-BD-20260807-004; chưa thấy bước bắt buộc ghi nguyên nhân, đính kèm ảnh, hoặc liên kết chứng từ xuất kho. Bằng chứng: dữ liệu phiếu chỉ có kho, mã hàng, lô, vị trí, số hệ thống, số thực đếm và người ghi nhận.

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

flowchart TB
    A[Tra ERP lúc 16:35: 1.200 chai] --> B[Nhân viên kho đếm ban đầu: phát hiện chênh lệch]
    B --> C[Hai nhân viên kho đếm lại lúc 16:42: 1.164 chai]
    C --> D[Nhân viên kho tạo phiếu<br/>SIM-COUNT-BD-20260807-004 lúc 16:45]
    D --> E[Nhân viên kho lưu chênh lệch -36 chai]
    E -. Không bắt buộc trước khi lưu .-> X[Nguyên nhân, ảnh, liên kết chứng từ xuất kho]
    E --> F[Phiếu ở trạng thái OPEN]
    F -. Chưa chứng minh .-> G[Thay đổi tồn kho sổ cái hoặc tạo bút toán]

Quy trình hiện tại chưa chứng minh có thay đổi tồn kho sổ cái, tạo bút toán, phát hành hóa đơn, hay xử lý thu hồi hàng. Các nội dung này không được suy diễn từ phiếu đếm. Luật Kế toán, quy định hóa đơn, Luật An toàn thực phẩm và yêu cầu bảo vệ dữ liệu cá nhân không được diễn giải thành quy tắc cho kịch bản này; cần xác minh bởi owner có thẩm quyền nếu phạm vi sau này chạm các nội dung đó.

Senior Lens

Facts khác nhận định. “Chênh -36 chai” là fact vì phép tính có đầu vào kiểm tra được. “Nhân viên lấy nhầm hàng” không phải fact vì kịch bản chưa có camera, chứng từ xuất, biên bản điều tra hoặc xác nhận owner. BA phải giữ riêng hai loại thông tin để tránh biến giả thuyết thành quy tắc ERP.

Current behavior không đồng nghĩa quy trình đúng hoặc được phê duyệt. Phiếu đang OPEN chỉ mô tả trạng thái quan sát được. IN_REVIEW của corpus v0.9.0 ngày 2026-08-07 cũng không tạo baseline, approval, quyền vận hành hay quyền dùng production.

Quick Reference

Kiểm tra	Kết quả trong ví dụ
Dữ liệu có phải tổng hợp?	Có
Có phân biệt số hệ thống và số đếm?	Có: 1.200 và 1.164 chai
Chênh lệch có tính lại được?	Có: -36 chai
Có tách fact khỏi giả thuyết nguyên nhân?	Có
Có khẳng định quy tắc pháp lý hoặc kế toán?	Không
Có ghi nhận quyết định hoặc phê duyệt?	Không

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing là case học liệu, dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Ví dụ không là cấu hình ERP thật, quyết định vận hành thật, hay xác nhận tuân thủ.

Bước phân tích	Nội dung truy vết
Facts — sự kiện kiểm chứng được	Đơn bán SO-NF-2026-0817 cho khách CUS-NF-0042; tổng trước thuế 48.000.000 VND; nhân viên bán hàng tạo lúc 2026-08-07 09:15; khách còn hạn mức tín dụng mô phỏng 30.000.000 VND; kho thành phẩm có đủ 120 thùng SKU-NF-DRK-330; đơn yêu cầu giao ngày 2026-08-08.
Current Behavior — hành vi hiện tại	ERP mô phỏng cho phép Sales xác nhận đơn dù vượt hạn mức. Sales gửi ảnh chụp màn hình qua email cho Finance. Finance trả lời thủ công. Sales tự sửa trạng thái đơn thành CONFIRMED. Kho thấy đơn đã xác nhận và tạo phiếu xuất.
Evidence bridge	Dữ kiện cho thấy giá trị đơn 48.000.000 VND lớn hơn hạn mức còn lại 30.000.000 VND là 18.000.000 VND. Hành vi hiện tại không chặn xác nhận, không tạo yêu cầu phê duyệt có ID, không lưu người quyết định trong ERP. Vì vậy không thể chứng minh ai chấp nhận rủi ro tín dụng trước xuất kho.
Underlying Need — nhu cầu gốc	Cần kiểm soát ngoại lệ tín dụng trước cam kết giao hàng. Mục tiêu không phải thêm nhiều bước phê duyệt; mục tiêu là chỉ chặn đơn vượt hạn mức, lưu quyết định có thẩm quyền, và đưa đơn được chấp thuận trở lại luồng kho không cần Sales sửa trạng thái.
Options — phương án	OPT-01: giữ email và Sales tự cập nhật trạng thái. OPT-02: chặn mọi đơn bán chờ Finance duyệt. OPT-03: chỉ tạo yêu cầu phê duyệt khi tổng dư nợ dự kiến vượt hạn mức; ERP tự chuyển trạng thái sau quyết định.
Decision Criteria — tiêu chí chọn	DC-01 kiểm soát đúng ngoại lệ; DC-02 có dấu vết người quyết định, thời điểm, lý do; DC-03 không làm chậm đơn trong hạn mức; DC-04 không cho Sales tự vượt kiểm soát; DC-05 dữ liệu đủ cho kiểm tra sau này.
Recommendation — khuyến nghị BA	Chọn OPT-03. OPT-01 không đáp ứng DC-02 và DC-04. OPT-02 đáp ứng kiểm soát nhưng không đáp ứng DC-03. OPT-03 đáp ứng cả năm tiêu chí nếu quyền trạng thái và nhật ký quyết định được hệ thống cưỡng chế.
Decision — quyết định được ghi nhận	Chưa có quyết định được phê duyệt. Trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. OPT-03 là khuyến nghị thiết kế, không phải quy tắc đã được Nova Foods ủy quyền.
Authority — thẩm quyền	Finance Manager mô phỏng quyết định chấp nhận ngoại lệ tín dụng. Sales Manager mô phỏng quyết định ưu tiên giao hàng nhưng không tự bỏ chặn tín dụng. ERP Product Owner mô phỏng xác nhận hành vi quy trình. Accounting Owner và Legal Owner phải xác minh nếu thiết kế ảnh hưởng hạch toán, hóa đơn, lưu trữ chứng từ, hoặc nghĩa vụ pháp lý.
Artifact — hiện vật đầu ra	Yêu cầu quy trình PRC-NF-CREDIT-001; quy tắc dự kiến BR-NF-CREDIT-001; bản ghi phê duyệt APR-NF-CREDIT-001; ma trận trạng thái STM-NF-SO-001; payload tích hợp dự kiến PAY-NF-CREDIT-001. Các ID là định danh mô phỏng trong tài liệu IN_REVIEW, chưa là baseline.
Consequence if Wrong — hậu quả nếu sai	Nếu ngưỡng hoặc quyền phê duyệt sai, kho có thể xuất hàng khi rủi ro tín dụng chưa được chấp nhận đúng thẩm quyền. Nếu chặn toàn bộ đơn, giao hàng hợp lệ bị chậm. Nếu Sales tự xác nhận, nhật ký ERP không phản ánh quyết định tín dụng thật; kiểm tra sau này không phân biệt được lỗi quy trình với quyết định có chủ đích.

ID	Quy tắc dự kiến	Điều kiện	Hành vi dự kiến
BR-NF-CREDIT-001	Kiểm soát vượt hạn mức tín dụng	orderGrossAmount + openReceivableAmount > creditLimit	Đơn chuyển PENDING_CREDIT_APPROVAL; không được tạo phiếu xuất.
BR-NF-CREDIT-002	Chỉ Finance Manager xử lý ngoại lệ	Đơn ở PENDING_CREDIT_APPROVAL	Finance Manager chọn APPROVED hoặc REJECTED, nhập lý do.
BR-NF-CREDIT-003	Không sửa thủ công trạng thái kiểm soát	Người dùng thuộc Sales hoặc Warehouse	Không được đổi PENDING_CREDIT_APPROVAL thành CONFIRMED hay RELEASED.
BR-NF-CREDIT-004	Phê duyệt có thời hạn	Ngoại lệ được chấp thuận	Ngoại lệ chỉ áp dụng cho SO-NF-2026-0817; không tái dùng cho đơn khác.

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

flowchart TB
    A[Sales tạo SO-NF-2026-0817] --> B{Dư nợ dự kiến vượt hạn mức?}
    B -- Không --> C[CONFIRMED]
    C --> D[Warehouse tạo phiếu xuất]
    B -- Có: 48.000.000 VND lớn hơn 30.000.000 VND --> E[PENDING_CREDIT_APPROVAL]
    E --> F[Tạo APR-NF-CREDIT-001 với decision PENDING qua PAY-NF-CREDIT-001]
    F --> G[Chặn tạo phiếu xuất; Sales và Warehouse không được tự đổi sang CONFIRMED hoặc RELEASED]
    G --> H[Finance Manager chọn APPROVED hoặc REJECTED; decisionReason bắt buộc]
    H --> I[Cập nhật APR-NF-CREDIT-001: quyết định, lý do, người quyết định, thời điểm]
    I --> J{Quyết định}
    J -- APPROVED --> K[Chỉ áp dụng cho SO-NF-2026-0817; không tái dùng]
    K --> L[ERP tự chuyển đơn sang RELEASED]
    L --> D
    J -- REJECTED --> M[CREDIT_REJECTED; đơn tiếp tục bị chặn xuất kho]

Payload dự kiến PAY-NF-CREDIT-001:

{
  "approvalId": "APR-NF-CREDIT-001",
  "salesOrderId": "SO-NF-2026-0817",
  "customerId": "CUS-NF-0042",
  "currency": "VND",
  "orderGrossAmount": 48000000,
  "availableCreditLimit": 30000000,
  "creditExposureExcess": 18000000,
  "requestedByRole": "Sales",
  "decisionRole": "Finance Manager",
  "decision": "PENDING",
  "decisionReason": null,
  "requestedAt": "2026-08-07T09:15:00+07:00"
}

decisionReason là null khi chờ quyết định; khi APPROVED hoặc REJECTED, trường này phải có giá trị. Đây là suy luận từ DC-02: không có lý do thì bản ghi không giải thích được vì sao ngoại lệ được chấp nhận hoặc từ chối.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Scenario SCN-NF-APP-001: duyệt yêu cầu mua nguyên liệu đóng gói vượt ngưỡng ngân sách.

Loại	ID	Nội dung đầy đủ	Phân loại nguồn
Scenario	SCN-NF-APP-001	PR PR-20260807-0042 mua 12.000 kg màng bao bì RM-PKG-014, tổng giá trị 648.000.000 VND	Dữ liệu mô phỏng
Đơn vị yêu cầu	ORG-NF-PLANT-HCM	Nhà máy Nova Foods TP.HCM	Dữ liệu mô phỏng
Người yêu cầu	USR-NF-0187	Nguyễn Minh An, Production Planner	Dữ liệu mô phỏng
Ngân sách	BGT-2026-HCM-PKG-03	Ngân sách bao bì tháng 08/2026: 1.200.000.000 VND; đã cam kết: 780.000.000 VND	Dữ liệu mô phỏng
Nhà cung cấp	SUP-NF-0021	Công ty Bao bì Minh Phát	Dữ liệu mô phỏng
Quy tắc	BR-NF-APP-001	PR có tổng giá trị từ 500.000.000 VND đến dưới 1.000.000.000 VND cần Finance Manager và Plant Director duyệt tuần tự trước khi phát hành PO	Quy tắc dự kiến, IN_REVIEW
Quy tắc	BR-NF-APP-002	Không được phát hành PO khi ngân sách khả dụng nhỏ hơn tổng giá trị PR	Quy tắc dự kiến, IN_REVIEW
Artifact	WF-NF-PR-APP-001	Luồng duyệt PR vượt ngưỡng ngân sách	Artifact mô phỏng, IN_REVIEW

Facts: PR-20260807-0042 cần giao trước 2026-08-15T17:00:00+07:00. Ngân sách khả dụng là 420.000.000 VND, tính bằng 1.200.000.000 - 780.000.000. Giá trị PR là 648.000.000 VND, cao hơn ngân sách khả dụng 228.000.000 VND.

Current Behavior: Production Planner gửi email cho Finance Manager và Plant Director. Email không khóa phát hành PO. Buyer có thể tạo PO từ PR đang chờ phản hồi email. Bằng chứng duyệt nằm trong hộp thư cá nhân, không gắn trạng thái PR.

Underlying Need: ERP cần chặn phát hành PO khi PR chưa đủ duyệt hoặc vượt ngân sách. Bằng chứng duyệt phải truy vết được theo PR, người duyệt, thời điểm, quyết định và lý do.

Option	Cách làm	Bằng chứng đánh giá	Kết quả
OPT-NF-APP-001	Giữ email, Buyer tự kiểm tra	Không có kiểm soát hệ thống; bằng chứng phân tán	Không chọn
OPT-NF-APP-002	ERP duyệt tuần tự, chặn PO theo trạng thái	Đáp ứng BR-NF-APP-001, BR-NF-APP-002; tạo audit trail	Khuyến nghị
OPT-NF-APP-003	ERP duyệt song song Finance và Plant Director	Giảm thời gian, nhưng không phản ánh yêu cầu tuần tự của BR-NF-APP-001	Không chọn

Decision Criteria ID	Tiêu chí	OPT-NF-APP-001	OPT-NF-APP-002	OPT-NF-APP-003
DC-NF-APP-001	Chặn PO trước đủ duyệt	Không	Có	Có
DC-NF-APP-002	Lưu bằng chứng trong ERP	Không	Có	Có
DC-NF-APP-003	Duyệt tuần tự Finance rồi Plant Director	Không	Có	Không
DC-NF-APP-004	Hiển thị chênh lệch ngân sách	Không	Có	Có

Recommendation: REC-NF-APP-001 đề xuất OPT-NF-APP-002. Lý do: chỉ phương án này thỏa cả bốn tiêu chí, đặc biệt DC-NF-APP-003.

Authorized Decision: Chưa có. WF-NF-PR-APP-001, BR-NF-APP-001 và BR-NF-APP-002 có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không được diễn giải khuyến nghị là phê duyệt, baseline, cấu hình ERP thực tế hoặc quyền phát hành PO.

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

flowchart TB
    T[Đề xuất — IN_REVIEW — v0.9.0<br/>WF-NF-PR-APP-001] --> A[Production Planner tạo và gửi PR<br/>PR-20260807-0042<br/>648.000.000 VND]

    A --> B{ERP kiểm tra ngân sách khả dụng<br/>420.000.000 VND}

    B -->|Không đủ<br/>Thiếu 228.000.000 VND| C[ERP chuyển trạng thái<br/>PENDING_FINANCE_APPROVAL]
    B -->|Đủ| C

    C --> D{Finance Manager phê duyệt?<br/>BR-NF-APP-001}

    D -->|Không| E[ERP lưu audit trail<br/>PR, người duyệt, thời điểm,<br/>quyết định, lý do, quy tắc]
    E --> F[ERP chuyển trạng thái REJECTED<br/>ERP chặn phát hành PO]

    D -->|Có| G[ERP lưu audit trail<br/>PR, người duyệt, thời điểm,<br/>quyết định, lý do, quy tắc]
    G --> H[ERP chuyển trạng thái<br/>PENDING_PLANT_DIRECTOR_APPROVAL]
    H --> I{Plant Director phê duyệt?<br/>BR-NF-APP-001}

    I -->|Không| J[ERP lưu audit trail<br/>PR, người duyệt, thời điểm,<br/>quyết định, lý do, quy tắc]
    J --> F

    I -->|Có| K[ERP lưu audit trail<br/>PR, người duyệt, thời điểm,<br/>quyết định, lý do, quy tắc]
    K --> L{Đủ duyệt tuần tự theo<br/>BR-NF-APP-001?}

    L -->|Có| M{Ngân sách khả dụng đủ<br/>648.000.000 VND?<br/>BR-NF-APP-002}
    L -->|Không| F

    M -->|Có| N[ERP chuyển trạng thái<br/>APPROVED_FOR_PO]
    N --> O[Buyer được phép phát hành PO]

    M -->|Không<br/>Thiếu 228.000.000 VND| P[ERP chặn phát hành PO<br/>Chưa đạt APPROVED_FOR_PO]

Payload audit mô phỏng cho lần duyệt Finance:

{
  "approvalId": "APR-NF-20260807-0091",
  "requestId": "PR-20260807-0042",
  "ruleId": "BR-NF-APP-001",
  "decision": "APPROVE",
  "actorId": "USR-NF-0044",
  "actorRole": "Finance Manager",
  "decisionAt": "2026-08-07T14:30:00+07:00",
  "amountVND": 648000000,
  "availableBudgetVND": 420000000,
  "budgetVarianceVND": -228000000,
  "comment": "Chuyển Plant Director xem xét vì PR vượt ngân sách khả dụng."
}

Artifact: cập nhật dự kiến vào WF-NF-PR-APP-001; liên kết quy tắc BR-NF-APP-001, BR-NF-APP-002; lưu payload APR-NF-20260807-0091 theo PR-20260807-0042.

Consequence if Wrong: nếu ERP cho phép Buyer phát hành PO trước APPROVED_FOR_PO, Nova Foods mô phỏng có thể cam kết thêm 648.000.000 VND khi ngân sách còn thiếu 228.000.000 VND. Nếu không lưu audit payload, BA không thể chứng minh ai đã quyết định, lúc nào, theo quy tắc nào.

9. Related Concepts & Dependencies

Core

Thiết kế workflow và approval không tự đứng một mình. Workflow chỉ mô tả luồng trạng thái, điểm quyết định, vai trò và điều kiện chuyển bước. Nguồn chân lý canonical là artifact được chỉ định duy nhất để định nghĩa từng loại thông tin. Ví dụ, BR-NF-APP-001 thuộc catalog quy tắc, không chép lại công thức ngưỡng duyệt vào sơ đồ WF-NF-PR-APP-001.

Nova Foods Trading & Manufacturing là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, mọi liên kết dưới đây là kế hoạch học liệu; không phải baseline, approval, cấu hình ERP hay quyết định vận hành.

Hướng	Khái niệm/artifact phụ thuộc	Vai trò với workflow	Nguồn canonical
Upstream	Kiến trúc curriculum	Xác định chapter nào cung cấp lifecycle, requirement, data, test basis	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md
Upstream	Danh mục chapter	Giữ đúng filename, phạm vi chapter, thứ tự học	/01-curriculum/CHAPTER_MANIFEST.md
Upstream	Registry định danh	Cấp và kiểm soát ID như WF-NF-PR-APP-001, BR-NF-APP-001, PR-20260807-0042	/01-curriculum/TRACEABILITY_ID_REGISTRY.md
Upstream	Catalog business rule	Định nghĩa điều kiện duyệt, chặn PO, ngưỡng giá trị	/01-curriculum/CANONICAL_BUSINESS_RULES.md
Upstream	Data dictionary	Định nghĩa requestId, approvalId, actorRole, decisionAt, kiểu dữ liệu và ý nghĩa	/01-curriculum/CANONICAL_DATA_DICTIONARY.md
Upstream	Source map	Phân loại nguồn chuẩn, pháp lý, good practice và giới hạn sử dụng	/00-research/00_SOURCE_MAP.md
Downstream	Template manifest	Chỉ ra template được phép dùng để ghi workflow, approval log, rule mapping	/01-curriculum/TEMPLATE_MANIFEST.md
Downstream	Requirement và test artifact	Dùng workflow làm đầu vào để mô tả hành vi, tiêu chí chấp nhận và kiểm thử	Artifact được đăng ký trong manifest và registry
Downstream	API/data contract	Dùng trạng thái, ID, trường dữ liệu canonical để thiết kế tích hợp	Data dictionary và API artifact được đăng ký

Không tạo “bản sao tiện đọc” của business rule, data field hay ID trong handbook. Handbook chỉ ghi tham chiếu, phạm vi sử dụng và diễn giải tác động. Lý do: hai nơi cùng định nghĩa một điều kiện sẽ tạo hai phiên bản sự thật; người phát triển có thể làm theo workflow cũ trong khi QA kiểm theo rule mới.

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

flowchart TB
    subgraph UP[Upstream]
        SM[00_SOURCE_MAP]
        CA[01_CURRICULUM_ARCHITECTURE]
        CM[CHAPTER_MANIFEST]
        ID[TRACEABILITY_ID_REGISTRY]
        BR[CANONICAL_BUSINESS_RULES<br/>BR-NF-APP-001, BR-NF-APP-002]
        DD[CANONICAL_DATA_DICTIONARY]
    end

    WF[WF-NF-PR-APP-001<br/>Workflow approval]

    subgraph DOWN[Downstream]
        TM[TEMPLATE_MANIFEST]
        RA[Requirement and acceptance artifacts]
        API[API/data contract]
        TS[Test artifacts]
    end

    SM -->|source scope| WF
    CA -->|curriculum scope| WF
    CM -->|chapter scope| WF
    ID -->|ID control| WF
    BR -->|approval rules| WF
    DD -->|canonical fields| WF

    WF -->|allowed templates| TM
    WF -->|behavior basis| RA
    WF -->|states and fields| API
    WF -->|test basis| TS

Applied

Facts: WF-NF-PR-APP-001 mô tả Purchase Requisition PR-20260807-0042 trị giá 648.000.000 VND. Workflow dùng BR-NF-APP-001 và BR-NF-APP-002; payload duyệt dùng APR-NF-20260807-0091.

Current Behavior: handbook mô tả Finance Manager duyệt trước Plant Director khi PR vượt ngân sách khả dụng. Workflow không giữ bản sao định nghĩa “ngân sách khả dụng”, không tự đặt ngưỡng tiền, không đổi format ID.

Underlying Need: người đọc cần lần từ luồng duyệt sang rule, dữ liệu và template mà không suy đoán. Bằng chứng: mỗi quyết định workflow cần điều kiện nghiệp vụ; mỗi điều kiện cần trường dữ liệu; mỗi bản ghi cần ID ổn định để audit mô phỏng.

Options: chép đầy đủ rule và cấu trúc payload vào workflow; hoặc chỉ tham chiếu artifact canonical bằng ID và đường dẫn.

Decision Criteria: một nguồn được sửa; ID giữ ổn định; người đọc truy được định nghĩa; thay đổi rule không buộc sửa nhiều bản sao; không biến handbook thành đặc tả API.

Decision: WF-NF-PR-APP-001 giữ trạng thái, vai trò, thứ tự và liên kết. CANONICAL_BUSINESS_RULES giữ nội dung BR-NF-APP-001 và BR-NF-APP-002. CANONICAL_DATA_DICTIONARY giữ nghĩa và cấu trúc dữ liệu approval. TRACEABILITY_ID_REGISTRY giữ quyền cấp và kiểm soát ID.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner, Finance/Accounting Owner, Architect, Security và QA xác nhận nội dung thuộc thẩm quyền tương ứng khi artifact đủ điều kiện review. Không có approval được ghi nhận.

Artifact: /02-handbook/13-process-design-workflows-and-approvals.md tham chiếu WF-NF-PR-APP-001, BR-NF-APP-001, BR-NF-APP-002, PR-20260807-0042, APR-NF-20260807-0091; không định nghĩa lại chúng.

Consequence if Wrong: nếu handbook tự ghi “PR trên 500.000.000 VND phải qua Plant Director” nhưng catalog rule đổi ngưỡng khác, developer, Finance và QA có thể dùng ba giá trị khác nhau. PO có thể bị chặn sai hoặc được tạo sai trong mô phỏng.

Senior Lens

Phân biệt tham chiếu với sao chép. Tham chiếu nói “workflow áp dụng BR-NF-APP-001”. Sao chép nói lại điều kiện chi tiết của rule. Chỉ sao chép khi artifact nguồn cho phép snapshot có version, mục đích snapshot rõ và cơ chế đồng bộ được kiểm soát. Micro-batch này không tạo snapshot.

ID persistent là định danh không đổi của đối tượng qua các lần chỉnh sửa. Tên hiển thị có thể đổi để rõ hơn; ID không đổi để liên kết lịch sử không đứt. Không đổi WF-NF-PR-APP-001 thành ID mới chỉ vì sửa nhãn trạng thái. Chỉ registry quyết định cấp, thay thế hoặc ngừng dùng ID.

Khi không tìm thấy nguồn canonical, không tự tạo rule trong workflow. Ghi nhận khoảng trống tại artifact quản trị phù hợp và dừng suy diễn. Điều này bảo vệ ranh giới giữa tài liệu học liệu, quyết định nghiệp vụ, diễn giải pháp lý và cấu hình ERP.

Quick Reference

Thành phần cần nêu	Cách ghi trong workflow	Không làm
Rule	Áp dụng BR-NF-APP-001	Chép lại toàn bộ logic rule
Data field	Theo CANONICAL_DATA_DICTIONARY	Tự đổi nghĩa decisionAt hoặc actorRole
ID	Giữ nguyên PR-20260807-0042	Dịch, rút gọn hoặc cấp lại ID
Template	Dẫn /01-curriculum/TEMPLATE_MANIFEST.md	Tạo template không đăng ký
Chapter dependency	Dẫn /01-curriculum/CHAPTER_MANIFEST.md	Đổi filename hoặc phạm vi chapter
Nguồn chuẩn/pháp lý	Dẫn /00-research/00_SOURCE_MAP.md	Suy diễn nghĩa vụ pháp lý từ handbook

Core

Ma trận phụ thuộc và truy vết liên kết nhu cầu với kiểm thử qua ID ổn định. Mỗi loại ID trả lời một câu khác nhau: NEED nêu vấn đề cần giải quyết; REQ nêu khả năng hệ thống cần có; BR nêu quy tắc nghiệp vụ; AC nêu điều kiện chấp nhận; DATA/API nêu dữ liệu hoặc giao diện tích hợp; TC nêu ca kiểm thử. Bảng không thay thế nguồn canonical: ID, định nghĩa và trạng thái vẫn thuộc registry hoặc catalog gốc. 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.

Lớp truy vết	ID ví dụ	Liên kết bắt buộc	Mục đích kiểm soát	Nguồn canonical
Need	NEED-NF-AP-001	Ít nhất một REQ	Chứng minh tính cần thiết nghiệp vụ	TRACEABILITY_ID_REGISTRY
Requirement	REQ-NF-AP-001	Một NEED; AC phù hợp	Mô tả năng lực ERP cần cung cấp	TRACEABILITY_ID_REGISTRY
Business Rule	BR-NF-AP-001	REQ chịu tác động; AC kiểm chứng	Tách quy tắc khỏi màn hình và quy trình	CANONICAL_BUSINESS_RULES
Acceptance Criteria	AC-NF-AP-001	Một REQ; BR khi có	Đặt kết quả quan sát được để đánh giá	TRACEABILITY_ID_REGISTRY
Data/API	DATA-NF-AP-001, API-NF-AP-001	REQ, BR, AC liên quan	Làm rõ trường dữ liệu và hợp đồng trao đổi	CANONICAL_DATA_DICTIONARY; registry
Test Case	TC-NF-AP-001	Một hay nhiều AC; BR khi cần	Cung cấp bằng chứng kiểm thử	TRACEABILITY_ID_REGISTRY

Applied

Facts: Nova Foods mô phỏng cần luồng duyệt đề nghị thanh toán nhà cung cấp theo giá trị VND. Current Behavior: người tạo có thể gửi đề nghị thiếu mã nhà cung cấp, làm người duyệt không xác định được đối tượng thanh toán. Underlying Need: ngăn đề nghị thiếu dữ liệu định danh trước khi vào trạng thái chờ duyệt. Options: cho phép gửi rồi sửa sau; hoặc chặn gửi khi thiếu mã. Decision Criteria: giảm lỗi định danh, tạo điều kiện kiểm thử rõ, không suy diễn chính sách thanh toán thực tế. Decision: chọn chặn gửi khi thiếu supplier_id vì tiêu chí kiểm tra được trực tiếp từ dữ liệu đầu vào. Authority: đây là ví dụ học liệu IN_REVIEW, không phải quyết định vận hành Nova Foods hay phê duyệt của Business Owner. Artifact: liên kết trong bảng dưới. Consequence if Wrong: thiếu một liên kết có thể khiến đội phát triển làm sai kiểm tra, QA không kiểm thử lỗi, hoặc thay đổi trường dữ liệu không được phát hiện.

NEED	REQ	BR	AC	DATA/API	TC	Cầu nối bằng chứng
NEED-NF-AP-001	REQ-NF-AP-001	BR-NF-AP-001	AC-NF-AP-001	DATA-NF-AP-001	TC-NF-AP-001	Nhu cầu ngăn đề nghị không xác định nhà cung cấp dẫn tới yêu cầu kiểm tra trước khi gửi.
NEED-NF-AP-001	REQ-NF-AP-001	BR-NF-AP-001	AC-NF-AP-002	DATA-NF-AP-001	TC-NF-AP-002	Cùng quy tắc cần phản hồi lỗi rõ khi supplier_id rỗng để người tạo sửa được.
NEED-NF-AP-001	REQ-NF-AP-001	BR-NF-AP-001	AC-NF-AP-003	DATA-NF-AP-001, API-NF-AP-001	TC-NF-AP-003	Chỉ đề nghị hợp lệ mới được gửi qua API mô phỏng sang hàng chờ duyệt.

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

flowchart TB
    SCOPE[IN_REVIEW<br/>Ví dụ học liệu]
    CREATOR[Người tạo]
    NEED[NEED-NF-AP-001<br/>Ngăn đề nghị thiếu nhà cung cấp]
    REQ[REQ-NF-AP-001<br/>Kiểm tra trước khi gửi]
    BR[BR-NF-AP-001<br/>supplier_id bắt buộc]
    DATA[DATA-NF-AP-001<br/>supplier_id]
    CHECK{supplier_id có giá trị?}

    ERROR[Phản hồi lỗi để người tạo sửa]
    BLOCKED[Không gửi;<br/>không vào hàng chờ duyệt]

    API[API-NF-AP-001<br/>Gửi đề nghị mô phỏng]
    QUEUE[Hàng chờ duyệt mô phỏng]

    AC1[AC-NF-AP-001<br/>Chặn gửi khi thiếu supplier_id]
    AC2[AC-NF-AP-002<br/>Báo lỗi khi supplier_id rỗng]
    AC3[AC-NF-AP-003<br/>Chỉ đề nghị hợp lệ được gửi]
    TC1[TC-NF-AP-001]
    TC2[TC-NF-AP-002]
    TC3[TC-NF-AP-003]

    SCOPE -. phạm vi .-> API
    SCOPE -. phạm vi .-> QUEUE

    NEED --> REQ --> BR
    DATA --> BR
    CREATOR --> CHECK
    BR --> CHECK
    DATA --> CHECK

    CHECK -->|Thiếu hoặc rỗng| BLOCKED
    CHECK -->|Thiếu hoặc rỗng| ERROR
    ERROR --> CREATOR
    CREATOR -->|sửa rồi gửi lại| CHECK

    CHECK -->|Hợp lệ| API --> QUEUE

    CHECK -. bằng chứng .-> AC1
    BLOCKED -. kết quả .-> AC1
    ERROR -. bằng chứng .-> AC2
    CHECK -. bằng chứng .-> AC2
    API -. bằng chứng .-> AC3
    QUEUE -. kết quả .-> AC3

    AC1 --> TC1
    AC2 --> TC2
    AC3 --> TC3

Senior Lens

Không suy ra quan hệ chỉ vì ID cùng tiền tố. Mỗi dòng phải có cầu nối bằng chứng: nhu cầu nào tạo yêu cầu nào, quy tắc nào giới hạn yêu cầu, tiêu chí nào chứng minh kết quả, dữ liệu hay API nào làm tiêu chí kiểm tra được, và ca kiểm thử nào tạo bằng chứng. Nếu chưa có bằng chứng, ghi liên kết là chưa xác lập trong nguồn canonical, không tự tạo BR, AC hay TC.

BR-NF-AP-001 là nội dung quy tắc giả định của case mô phỏng. Tính bắt buộc pháp lý, kế toán, thuế, bảo mật hoặc vận hành thực tế cần Verification required từ owner có thẩm quyền. IN_REVIEW tại v0.9.0, ngày 2026-08-07, không là baseline hay approval.

Quick Reference

Kiểm tra	Đạt khi	Không đạt khi
Chiều truy vết	Mỗi TC quay ngược được tới ít nhất một AC và REQ	TC chỉ gắn tên chức năng hoặc màn hình
Quy tắc	BR tham chiếu đúng CANONICAL_BUSINESS_RULES	Quy tắc bị chép lại rồi sửa khác nghĩa
Dữ liệu	DATA-NF-AP-001 tham chiếu đúng CANONICAL_DATA_DICTIONARY	Trường dữ liệu được định nghĩa lại trong bảng
API	API-NF-AP-001 có REQ, dữ liệu và TC liên quan	API tồn tại không có tiêu chí kiểm chứng
Phạm vi	Chỉ dùng dữ liệu Nova Foods tổng hợp	Bảng bị diễn giải thành cấu hình ERP production

Core

Phụ thuộc là quan hệ khi một artifact chỉ còn đúng nếu artifact khác giữ nguyên ý nghĩa, ID, cấu trúc dữ liệu hoặc trạng thái. Thay đổi lan truyền xảy ra vì artifact hạ nguồn đã dùng dependency làm cơ sở thiết kế, kiểm thử hoặc quyết định. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Thay đổi im lặng là sửa dependency nhưng không ghi version, lịch sử thay đổi, phạm vi ảnh hưởng hoặc liên kết truy vết. Đây là lỗi quản trị: người dùng artifact hạ nguồn tiếp tục tin vào nguồn cũ, dù nguồn canonical đã đổi.

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

flowchart TB
    H["Sự kiện thay đổi không được ghi nhận<br/>không version, lịch sử, phạm vi ảnh hưởng hoặc truy vết"] --> X{"Artifact bị thay đổi"}

    X --> A["CANONICAL_BUSINESS_RULES<br/>quy tắc canonical đã đổi"]
    X --> C["CANONICAL_DATA_DICTIONARY<br/>định nghĩa dữ liệu đã đổi"]

    A -->|"quy định điều kiện duyệt"| B["Quy trình phê duyệt<br/>vẫn dùng quy tắc cũ"]
    C -->|"định nghĩa dữ liệu dùng để định tuyến hoặc đánh giá"| B
    B -->|"làm cơ sở"| D["Acceptance criteria<br/>vẫn theo quy trình cũ"]

    C -->|"định nghĩa ý nghĩa trường"| E["Hợp đồng API<br/>vẫn theo nghĩa dữ liệu cũ"]
    D -->|"định hình hành vi API"| E
    D -->|"làm cơ sở kiểm thử"| F["Test case<br/>vẫn theo acceptance criteria cũ"]

    B --> G["Workflow có thể gửi sai người duyệt"]
    E --> K["Giá trị hợp lệ về kỹ thuật<br/>nhưng sai nghĩa nghiệp vụ"]
    F -->|"nếu chạy theo acceptance criteria cũ"| N["Kết quả kiểm thử vẫn xanh"]

    G --> R["Lỗi chỉ lộ khi vận hành mô phỏng"]
    K --> R
    N --> R

Ví dụ, nếu CANONICAL_BUSINESS_RULES đổi điều kiện duyệt đơn mua nhưng quy trình không được cập nhật, workflow có thể gửi sai người duyệt. Nếu CANONICAL_DATA_DICTIONARY đổi ý nghĩa trường dữ liệu mà API không đổi hợp đồng, hệ thống tích hợp có thể truyền giá trị hợp lệ về kỹ thuật nhưng sai nghĩa nghiệp vụ. Test case vẫn xanh vì kiểm thử theo acceptance criteria cũ; lỗi chỉ lộ khi vận hành mô phỏng.

Applied

Mục	Nội dung
Facts	Workflow mua hàng tham chiếu quy tắc canonical và dữ liệu người duyệt. Artifact nguồn đang IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	Workflow dựa trên điều kiện duyệt đã ghi tại thời điểm soạn; test case dùng cùng điều kiện đó làm test basis, tức cơ sở kiểm thử.
Underlying Need	Khi dependency đổi, mọi artifact tiêu thụ phải biết phần nào còn đúng, phần nào cần sửa hoặc kiểm thử lại.
Options	1. Sửa nguồn im lặng. 2. Ghi thay đổi, phân tích ảnh hưởng, cập nhật liên kết và kiểm thử lại phần ảnh hưởng.
Decision Criteria	Giữ ID canonical; bảo toàn lịch sử; xác định owner có thẩm quyền; không biến IN_REVIEW thành approval; có bằng chứng phần hạ nguồn đã được đánh giá.
Decision	Chọn phương án 2. Mỗi thay đổi phải tạo bản ghi thay đổi tại artifact canonical và impact assessment trước khi dùng nội dung mới ở workflow.
Authority	Principal IT Business Analyst / Technical Curriculum Author giữ traceability. Business Owner, Architect, QA, Legal, Accounting hoặc Security quyết định phần thuộc thẩm quyền họ.
Artifact	/01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, và handbook hiện tại.
Consequence if Wrong	Sai người duyệt, sai quyền truy cập, sai dữ liệu tích hợp, test case lỗi thời, báo cáo kiểm soát mâu thuẫn. Không được coi lỗi này là bằng chứng tuân thủ hay quyết định production.

Senior Lens

Không sao chép rule hoặc định nghĩa dữ liệu sang workflow để “cho tiện”. Bản sao tạo hai nguồn chân lý. Workflow chỉ giữ tham chiếu ổn định tới artifact canonical, phiên bản được dùng và tác động đã biết.

Phân biệt thay đổi câu chữ với thay đổi nghĩa. Sửa chính tả không đổi nghĩa có thể chỉ cần ghi lịch sử. Đổi ngưỡng, người chịu trách nhiệm, trạng thái, định nghĩa trường, kiểu dữ liệu, API contract hoặc điều kiện acceptance là thay đổi nghĩa. Bằng chứng là các thành phần này quyết định hành vi hệ thống hoặc kết quả kiểm thử; vì vậy phải phân tích ảnh hưởng.

Dấu hiệu dependency đổi im lặng gồm: ID vẫn giống nhưng nội dung khác; đường dẫn canonical bị thay bằng bản sao; test case không nêu phiên bản test basis; API payload có trường mới nhưng data dictionary chưa cập nhật; workflow hiển thị trạng thái không còn trong nguồn kiểm soát. Khi có dấu hiệu này, dừng dùng artifact hạ nguồn làm căn cứ quyết định. So sánh bản nguồn, xác định phạm vi ảnh hưởng, ghi nhận chênh lệch và chuyển đúng owner.

Quick Reference

Thay đổi dependency	Thành phần có thể vỡ	Kiểm soát tối thiểu
Quy tắc nghiệp vụ đổi nghĩa	Workflow, acceptance criteria, test case, báo cáo	Ghi lịch sử thay đổi; đánh giá impact; QA xem lại test basis
Định nghĩa dữ liệu đổi	Mapping, API, validation, báo cáo	Kiểm tra field name, kiểu, miền giá trị, ý nghĩa
Trạng thái quy trình đổi	Routing, quyền, thông báo, audit trail	Kiểm tra state transition và người chịu trách nhiệm
ID hoặc đường dẫn canonical đổi	Liên kết truy vết, automation, tài liệu tham chiếu	Giữ ID ổn định; cập nhật registry có kiểm soát
Nguồn pháp lý hoặc chuẩn đổi	Requirement dẫn xuất, kiểm soát tuân thủ	Gắn Verification required; Legal Owner hoặc vai trò chuyên môn xác minh

10. Common Mistakes & Anti-patterns

Core

Sai lầm quy trình thường không bắt đầu từ sơ đồ xấu. Nó bắt đầu khi nhóm biến giả định thành yêu cầu, bỏ qua ngoại lệ, hoặc coi tài liệu đang IN_REVIEW là quyết định đã có thẩm quyền. Với Nova Foods Trading & Manufacturing, mọi ví dụ dưới đây là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Sai lầm	Dấu hiệu quan sát được	Nguyên nhân gốc	Hành động sửa
Viết workflow theo cách người trình bày kể	Bước có động từ mơ hồ như “xử lý”, “kiểm tra”; không biết ai làm gì	BA chưa tách tác nhân, quyết định, dữ liệu vào và dữ liệu ra	Viết lại mỗi bước theo mẫu: vai trò, hành động, điều kiện, kết quả
Chỉ mô tả luồng thành công	Sơ đồ chỉ có một đường từ tạo đến hoàn tất	Nhóm sợ tăng độ phức tạp hoặc chưa hỏi ngoại lệ	Bổ sung từ chối, trả lại, hủy, lỗi tích hợp và người xử lý
Gán người duyệt theo tên cá nhân	Workflow ghi “Anh Nam duyệt”	Nhầm người hiện tại với vai trò nghiệp vụ	Dùng vai trò như Sales Manager; quản trị phân quyền ở artifact khác
Đặt ngưỡng duyệt không có nguồn	Ghi “đơn trên 50.000.000 VND cần duyệt” nhưng không có nguồn kiểm soát	BA suy diễn từ trao đổi hoặc ví dụ đào tạo	Gắn là giả định dự án; chuyển Business Owner xác nhận trước khi thành rule
Dùng sơ đồ như nguồn chân lý duy nhất	Diagram khác acceptance criteria hoặc rule catalog	Không liên kết artifact canonical	Liên kết ID nguồn; kiểm tra chéo trước khi chuyển QA hoặc Development
Vẽ ký hiệu không đúng nghĩa	Hình thoi dùng cho bước nhập liệu; mũi tên không nêu điều kiện	Người viết dùng công cụ vẽ nhưng không hiểu notation	Chọn BPMN 2.0.2 khi cần BPMN; nếu dùng Mermaid, gọi đúng là flowchart, không gọi là BPMN
Không chỉ rõ điểm ghi dữ liệu	Đơn được duyệt nhưng không biết trạng thái nào lưu vào ERP	Tập trung người dùng, bỏ qua system behavior	Ghi rõ trạng thái, bản ghi cập nhật, audit trail và sự kiện thông báo
Sửa workflow nhưng không kiểm tra ảnh hưởng	Quy trình đổi trạng thái, test case vẫn kiểm tra trạng thái cũ	Không có phân tích impact	Dừng handoff; so sánh phiên bản nguồn, cập nhật artifact phụ thuộc, rồi QA xem lại test basis

Cảnh báo: Gán ngưỡng phê duyệt, quyền phê duyệt, nghĩa vụ kế toán, thuế, dữ liệu cá nhân hoặc an toàn thực phẩm như sự thật Nova Foods tạo rủi ro quyết định sai. IN_REVIEW tại v0.9.0 không phải APPROVED hay BASELINED. Ranh giới khôi phục an toàn: giữ nội dung là giả định hoặc Verification required, không cấu hình production, chuyển đúng Business Owner, Legal Owner, Accounting Owner hoặc Security Owner.

Applied

Facts: Nova Foods mô phỏng có đơn bán SO-SIM-00128, tổng giá trị tổng hợp 62.000.000 VND. BA mới vẽ luồng “Nhân viên tạo đơn, Quản lý duyệt, ERP xuất hóa đơn”.

Current Behavior: Sơ đồ không nêu điều kiện duyệt, không có trạng thái trả lại, không xác định hệ thống có được xuất hóa đơn sau khi đơn bị từ chối hay không.

Underlying Need: Nhóm cần workflow đủ rõ để Development, QA và Business Owner phân biệt tạo đơn, phê duyệt đơn, từ chối đơn và hành động tiếp theo.

Options:
1. Giữ sơ đồ ngắn, giả định mọi đơn đều được duyệt.
2. Thêm điều kiện và ngoại lệ, nhưng tự đặt ngưỡng 50.000.000 VND.
3. Mô tả trạng thái và điểm quyết định; gắn ngưỡng là giả định dự án chờ xác minh thẩm quyền.

Decision Criteria: Luồng phải kiểm thử được, không tự tạo business rule, nêu rõ ai chịu trách nhiệm và không diễn giải IN_REVIEW thành phê duyệt.

Decision: Chọn phương án 3. Dùng điều kiện trung tính Yêu cầu phê duyệt theo rule được xác minh; chưa ghi ngưỡng số tiền là quy tắc Nova Foods.

Authority: Business Owner xác nhận chính sách phê duyệt. Accounting Owner xác nhận tác động chứng từ. BA duy trì workflow và traceability, không tự xác nhận các quyết định này.

Artifact: /02-handbook/13-process-design-workflows-and-approvals.md, trạng thái IN_REVIEW, phiên bản v0.9.0; tham chiếu catalog dự kiến CANONICAL_BUSINESS_RULES khi rule có nguồn hợp lệ.

Consequence if Wrong: Nếu ERP cho xuất hóa đơn trước khi điều kiện phê duyệt được xác minh, nhóm có thể xây sai routing, QA thiếu test case từ chối, và Accounting Owner phải xử lý hậu quả quy trình. Ví dụ này không kết luận nghĩa vụ pháp lý hay cấu hình ERP thực tế.

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

flowchart TB
    A[Sales tạo đơn SO-SIM-00128] --> B[ERP kiểm tra dữ liệu bắt buộc]

    B -->|Thiếu dữ liệu| C[Trả Sales sửa đơn]
    B -->|Đủ dữ liệu| D{Rule phê duyệt<br/>đã được xác minh?}

    D -->|Chưa xác minh| E[Giữ IN_REVIEW;<br/>không quyết định phê duyệt;<br/>ERP không xuất hóa đơn]
    D -->|Có| F{Đơn cần phê duyệt<br/>theo rule đã xác minh?}

    F -->|Có| R{Vai trò phê duyệt<br/>đã được Business Owner xác nhận?}
    R -->|Chưa xác nhận| S[Giữ đơn;<br/>không quyết định phê duyệt;<br/>ERP không xuất hóa đơn]
    R -->|Đã xác nhận| G[Approver quyết định]

    G -->|Từ chối| H[Đơn bị từ chối;<br/>ERP không xuất hóa đơn]
    G -->|Phê duyệt| K{Accounting Owner đã xác nhận<br/>hành động hóa đơn/chứng từ?}

    F -->|Không| K

    K -->|Chưa xác nhận| J[Chưa xuất hóa đơn;<br/>chưa thực hiện hành động chứng từ]
    K -->|Đã xác nhận| L[ERP thực hiện hành động<br/>hóa đơn/chứng từ theo xác nhận]

    subgraph GOV[Governance và artifact]
        V[Workflow artifact v0.9.0:<br/>IN_REVIEW không phải phê duyệt đơn]
        BA[BA duy trì workflow<br/>và traceability]
        BO[Business Owner xác nhận<br/>chính sách và vai trò phê duyệt]
        AO[Accounting Owner xác nhận<br/>tác động chứng từ]
    end

    BO -. xác nhận rule .-> D
    BO -. xác nhận vai trò .-> R
    AO -. xác nhận hành động .-> K
    BA -. duy trì .-> V
    BA -. traceability .-> BO
    BA -. traceability .-> AO

Senior Lens

Senior BA không cố làm sơ đồ đẹp trước. Senior BA tìm điểm mà một người khác có thể hành động sai. Bằng chứng là lỗi delivery thường xuất hiện tại quyết định, ngoại lệ, quyền và dữ liệu cập nhật; đây là nơi hành vi hệ thống đổi khác.

Quy tắc rà nhanh: nếu một bước không trả lời được “ai làm”, “dựa vào điều kiện nào”, “cập nhật gì”, “nếu thất bại thì sao”, bước đó chưa sẵn sàng làm test basis. Không bù khoảng trống bằng suy đoán. Ghi giả định, nguồn cần xác minh và owner có thẩm quyền.

Quick Reference

Kiểm tra trước handoff	Đạt khi
Vai trò	Mỗi bước có vai trò, không gán tên cá nhân
Quyết định	Mỗi nhánh có điều kiện rõ và kết quả rõ
Ngoại lệ	Có đường xử lý từ chối, trả lại hoặc lỗi phù hợp
Dữ liệu	Biết trạng thái hoặc bản ghi nào đổi sau từng bước chính
Thẩm quyền	Rule, ngưỡng và quyền duyệt có nguồn hoặc nhãn Verification required
Tính kiểm thử	QA có thể tạo test case từ luồng mà không tự đoán hành vi

Core

[!WARNING] Rủi ro thật: luồng phê duyệt tự động có thể giải phóng giao dịch sai. Nếu điều kiện phê duyệt thiếu dữ liệu đầu vào, ERP có thể chuyển chứng từ sang trạng thái được xử lý dù người có thẩm quyền chưa quyết định. Với Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp, hậu quả mô phỏng gồm xuất kho sai, ghi nhận công nợ sai hoặc mất dấu người quyết định.

Cảnh báo chỉ dùng khi lỗi có thể gây mất dữ liệu, sai quyền, sai trạng thái hoặc xử lý giao dịch không thể đảo trực tiếp. Không dùng cảnh báo cho lỗi trình bày, sở thích sơ đồ, hoặc câu chữ chưa đẹp. “Safe recovery boundary” là ranh giới khôi phục an toàn: dừng tự động hóa, giữ bằng chứng hiện có, không sửa đè lịch sử, không tự tuyên bố phê duyệt, rồi chuyển xử lý cho vai trò có thẩm quyền.

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

stateDiagram-v2
    direction TB
    [*] --> IN_REVIEW
    IN_REVIEW --> APPROVED: Quyết định phê duyệt hợp lệ của người có thẩm quyền
    IN_REVIEW --> REJECTED: Quyết định từ chối của người có thẩm quyền
    IN_REVIEW --> HOLD: Thiếu dữ liệu hoặc lỗi định tuyến
    HOLD --> IN_REVIEW: Bổ sung dữ liệu hoặc sửa định tuyến; bàn giao người có thẩm quyền; giữ audit trail
    HOLD --> HOLD: Dừng tự động hóa; giữ bằng chứng; không sửa đè lịch sử; không tự tuyên bố phê duyệt
    APPROVED --> [*]
    REJECTED --> [*]

Applied

Trường	Nội dung
Facts	Phiếu đề nghị xuất kho mô phỏng NF-WR-2026-081 trị giá tổng hợp 85.000.000 VND ở IN_REVIEW.
Current Behavior	Workflow kiểm tra approver_id có giá trị, rồi chuyển sang APPROVED; không kiểm tra quyết định, thời điểm, hay quyền phê duyệt còn hiệu lực.
Underlying Need	Chỉ chuyển trạng thái khi có bằng chứng quyết định đủ để truy vết: người quyết định, hành động, thời điểm Asia/Ho_Chi_Minh, đối tượng và quyền phù hợp.
Options	(1) Tắt workflow và phê duyệt ngoài hệ thống. (2) Giữ workflow, chặn chuyển trạng thái nếu thiếu bằng chứng quyết định. (3) Tự động APPROVED theo giá trị approver_id.
Decision Criteria	Không tự giải phóng giao dịch; giữ lịch sử; cho phép khôi phục không sửa đè; không gán thẩm quyền mà artifact không chứng minh.
Decision	Chọn (2). Khi thiếu bằng chứng, chuyển HOLD, không chuyển APPROVED.
Authority	Business Owner xác nhận chính sách phê duyệt; System Owner hoặc Architect xác nhận cơ chế workflow; BA ghi nhận yêu cầu và traceability. Không có approval được suy diễn từ trạng thái IN_REVIEW, Owner artifact, hay tồn tại của sơ đồ.
Artifact	Ghi liên kết tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và /01-curriculum/CANONICAL_DATA_DICTIONARY.md; các artifact đều IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Phiếu có thể được xuất kho mô phỏng khi chưa có quyết định hợp lệ; audit trail không chứng minh ai chịu trách nhiệm.

[!WARNING] Rủi ro thật: sửa trực tiếp trạng thái hoặc xóa log để “khôi phục nhanh”. Cách này phá bằng chứng xử lý, khiến không phân biệt được lỗi hệ thống với quyết định nghiệp vụ. Ranh giới khôi phục an toàn: khóa giao dịch bị ảnh hưởng, giữ log gốc, tạo bản ghi điều chỉnh hoặc yêu cầu xử lý mới theo quy trình được xác nhận. Không tự sửa APPROVED thành IN_REVIEW trong dữ liệu gốc nếu chưa có cơ chế audit được thẩm quyền kỹ thuật xác nhận.

Senior Lens

Ví dụ thất bại Nova Foods mô phỏng: đội delivery cấu hình quy tắc “đơn xuất kho trên 50.000.000 VND cần quản lý kho phê duyệt”, nhưng workflow chỉ kiểm tra ngưỡng tiền. Bằng chứng cho lỗi là giao dịch 85.000.000 VND chuyển APPROVED dù không có quyết định được ghi nhận. Suy luận: ngưỡng chỉ xác định khi nào cần xét duyệt; ngưỡng không chứng minh xét duyệt đã xảy ra. Hành động sửa: dừng chuyển trạng thái tự động, đưa giao dịch vào HOLD, bảo toàn nhật ký, xác định phạm vi giao dịch bị ảnh hưởng, rồi yêu cầu vai trò có thẩm quyền quyết định xử lý từng giao dịch.

Không gọi đây là vi phạm pháp luật, quy tắc kế toán hay chính sách thực tế. Case chỉ là học liệu mô phỏng. Nếu workflow liên quan hóa đơn, dữ liệu cá nhân, truy xuất thực phẩm hoặc bút toán, cần Verification required từ Legal Owner, Accounting Owner hoặc domain owner trước khi dùng như yêu cầu production.

Quick Reference

Tình huống	Có dùng cảnh báo?	Khôi phục an toàn
Workflow tự chuyển APPROVED không có quyết định	Có	Chuyển HOLD, giữ log, rà phạm vi ảnh hưởng
Người dùng không hiểu ký hiệu sơ đồ	Không	Sửa chú giải hoặc đào tạo
Xóa lịch sử để chạy lại workflow	Có	Giữ lịch sử, dùng bản ghi điều chỉnh hoặc xử lý mới
Artifact IN_REVIEW bị gọi là đã phê duyệt	Có, nếu dẫn tới thực thi	Gỡ tuyên bố, ghi đúng trạng thái, yêu cầu authority phù hợp

Core

Năm lỗi này khác nhau. Tách đúng loại lỗi giúp sửa đúng chỗ, không biến khoảng trống thông tin thành “quy tắc ERP”.

Loại lỗi	Dấu hiệu quan sát	Nguyên nhân gốc	Hành động sửa
Mơ hồ (ambiguity)	Câu “duyệt nhanh”, “đơn lớn”, “kịp thời” không có ngưỡng, thời hạn, chủ thể	Dùng từ nghiệp vụ cảm tính thay điều kiện kiểm chứng	Viết điều kiện đo được: dữ liệu vào, ngưỡng, người quyết định, kết quả
Không đầy đủ (incompleteness)	Có bước duyệt nhưng thiếu nhánh từ chối, hết hạn, lỗi tích hợp, người vắng mặt	Mô tả luồng thành công duy nhất	Bổ sung mọi kết quả trạng thái và chủ sở hữu xử lý
Khẳng định thẩm quyền không có chứng cứ	Tài liệu ghi “Kế toán đã yêu cầu”, “pháp luật bắt buộc” nhưng không có nguồn hoặc quyết định ghi nhận	Nhầm ý kiến workshop, thông lệ, hoặc giả định với quyết định có thẩm quyền	Gắn nhãn Project assumption hoặc Verification required; chuyển câu hỏi đúng owner
Dùng sai ký pháp (notation misuse)	Gọi sơ đồ hoạt động PlantUML là BPMN; dùng hình thoi nhưng không nêu điều kiện rẽ nhánh	Chọn hình trước khi xác định nghĩa mô hình	Ghi rõ loại sơ đồ; dùng BPMN 2.0.2 khi tuyên bố BPMN; đặt điều kiện trên từng nhánh
Đứt truy vết (traceability break)	Workflow có bước “kiểm tra hạn mức” nhưng không liên kết rule, dữ liệu, requirement hay test basis	Sao chép sơ đồ độc lập khỏi artifact kiểm soát	Liên kết đúng ID canonical hoặc ghi khoảng trống cần xác minh; không tự tạo ID biến thể

Mơ hồ là có câu nhưng nhiều cách hiểu. Không đầy đủ là thiếu câu cần thiết. Khẳng định thẩm quyền không chứng cứ là có câu nghe chắc chắn nhưng không có nguồn hoặc owner hợp lệ. Dùng sai ký pháp làm người đọc hiểu sai nghĩa sơ đồ. Đứt truy vết làm thay đổi không thể đánh giá tác động.

Applied

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

Trường	Nội dung
Facts	Sơ đồ yêu cầu mua hàng ghi: “Đơn mua nguyên liệu giá trị lớn phải được Giám đốc Tài chính duyệt.” Không có ngưỡng VND, nguồn hạn mức, nhánh từ chối, hay liên kết rule.
Current Behavior	BA đưa sơ đồ vào /02-handbook/13-process-design-workflows-and-approvals.md và chú thích là “BPMN”. Sơ đồ thực tế là PlantUML activity diagram.
Underlying Need	Người dùng cần biết đơn nào cần duyệt, ai quyết định, khi nào đơn dừng, và dữ liệu nào chứng minh quyết định.
Options	(1) Giữ câu mơ hồ; (2) BA tự chọn ngưỡng 500.000.000 VND; (3) ghi điều kiện chưa xác minh, tách decision cần Business Owner và Accounting Owner xác nhận.
Decision Criteria	Điều kiện phải kiểm thử được; thẩm quyền phải có bằng chứng; ký pháp phải gọi đúng tên; workflow phải truy được tới rule và dữ liệu canonical.
Decision	Chọn (3). Đổi nhãn sơ đồ thành PlantUML activity diagram. Ghi Verification required cho ngưỡng và thẩm quyền. Không tạo quy tắc mới.
Authority	Business Owner xác nhận chính sách duyệt; Accounting Owner xác nhận ảnh hưởng kế toán; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact và traceability.
Artifact	Tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md; các artifact đều IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Đơn hợp lệ có thể bị chặn sai hoặc đơn rủi ro có thể đi tiếp; test không xác định được expected result; tài liệu có thể bị hiểu nhầm là quyết định kế toán hoặc phê duyệt thực.

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

@startuml
start
:Create purchase request;
:Check approval rule verification;

if (Threshold, authority, rule ID, canonical data field,\nand non-approval outcome/status verified?) then (yes)
  :Evaluate verified approval condition\nusing verified rule ID and canonical data field;
  if (Purchase request meets verified approval condition?) then (yes)
    :Route to verified named approver\nusing verified approval rule;
    if (Approved?) then (yes)
      :Outcome: approved request continues\npurchase workflow;
    else (no)
      :Set status to verified non-approval outcome;
    endif
  else (no)
    :Outcome: request does not require approval\nunder verified rule;
    :Continue purchase workflow\nwithout approval;
  endif
else (no)
  :Set status to Pending verification;
  :Escalate decision package to\nBusiness Owner and Accounting Owner;
  :Trace required:\nCANONICAL_BUSINESS_RULES.md,\nCANONICAL_DATA_DICTIONARY.md,\nTRACEABILITY_ID_REGISTRY.md;
  :Workflow stopped — no ERP configuration\nor test expected result issued;
endif

stop
@enduml

Cảnh báo: Không thay Verification required bằng số tiền, chức danh, hay nghĩa vụ pháp lý tự suy diễn. Sai ngưỡng duyệt có thể đổi quyền chi tiêu hoặc tạo diễn giải kế toán không được thẩm quyền xác nhận.

Ranh giới phục hồi an toàn: dừng tại Pending verification; giữ nguyên bằng chứng workshop như đầu vào chưa xác minh; ghi owner cần quyết định; không cấu hình ERP, không phát hành test expected result như rule đã chốt.

Senior Lens

Kiểm tra câu workflow bằng bốn câu hỏi. “Ai” phải là vai trò xác định, không phải nhóm chung chung như “quản lý”. “Khi nào” phải có sự kiện hoặc điều kiện dữ liệu. “Theo cái gì” phải dẫn tới rule, policy, hoặc quyết định có nguồn. “Nếu không” phải có trạng thái và người xử lý.

Không viết “Theo quy định pháp luật” nếu chưa đối chiếu nguồn chính thức và chưa có Legal Owner xác nhận áp dụng. Verified primary-source seed phân loại Luật Kế toán, Luật An toàn thực phẩm, Luật Bảo vệ dữ liệu cá nhân và Nghị định hướng dẫn là nguồn pháp lý; nhưng diễn giải thành yêu cầu hệ thống vẫn cần owner pháp lý, kế toán, hoặc nghiệp vụ phù hợp. Nguồn BABOK Guide hỗ trợ thuật ngữ BA; BPMN 2.0.2 là nguồn chuẩn cho ký pháp BPMN; không nguồn nào tự tạo approval Nova Foods.

Traceability tối thiểu cho mỗi điểm quyết định là: bước workflow, điều kiện, dữ liệu dùng để đánh giá, rule hoặc quyết định nguồn, owner thẩm quyền, và test basis. Thiếu một phần thì ghi khoảng trống rõ ràng, không lấp bằng giả định.

Quick Reference

Không viết	Viết an toàn
“Đơn lớn cần duyệt.”	“Ngưỡng duyệt: Verification required; Business Owner và Accounting Owner cần xác nhận nguồn và owner.”
“CFO yêu cầu kiểm tra ngân sách.”	“Ý kiến workshop chưa có quyết định được ghi nhận; không phải nguồn thẩm quyền.”
“Sơ đồ BPMN dưới đây” cho PlantUML	“PlantUML activity diagram mô tả luồng học liệu; không phải BPMN.”
“Hệ thống kiểm tra hạn mức.”	“Cần xác định dữ liệu hạn mức, rule nguồn, thời điểm kiểm tra, kết quả khi vượt hạn mức và owner xử lý.”
“Đã được phê duyệt.”	“IN_REVIEW, v0.9.0; chưa có baseline reference hoặc approval reference.”

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn workflow “nhiều kiểm soát nhất”. Mục tiêu là kiểm soát đủ để giảm rủi ro mà không làm chậm quyết định hợp lệ. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi ví dụ và dữ liệu dưới đây là tổng hợp. Với mỗi bước duyệt, phân tích bốn đánh đổi: tốc độ xử lý, phân tách nhiệm vụ, chất lượng dữ liệu, và khả năng truy vết. Bước duyệt thêm giá trị khi nó đổi kết quả quyết định bằng bằng chứng hoặc thẩm quyền mới. Nếu chỉ lặp lại kiểm tra đã có, Senior BA đề xuất bỏ bước hoặc gộp bước.

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

flowchart TB
    A[Đề xuất thay đổi workflow] --> X{Có ngoại lệ?}

    X -- Có --> XA[Kiểm tra điều kiện, bằng chứng, thời hạn]
    XA --> XB{Chất lượng bằng chứng?}
    XB -- Trung bình hoặc yếu --> XC[Verification required: ghi dữ liệu còn thiếu]
    XC --> XD[Đã bổ sung hoặc xác minh bằng chứng]
    XD --> XB
    XB -- Mâu thuẫn --> XE[Dừng quyết định thiết kế; ghi nguồn mâu thuẫn]
    XE --> XF[Owner phù hợp phân xử nguồn]
    XF --> XB
    XB -- Mạnh --> XG[Map owner liên quan theo phạm vi]
    XG --> XH{Ngoại lệ do tình huống khẩn?}
    XH -- Có --> XI[Owner theo phạm vi xác nhận tình huống khẩn]
    XI --> XJ{Mọi owner liên quan đã xác nhận ngoại lệ?}
    XH -- Không --> XJ
    XJ -- Có --> XK[Thực hiện ngoại lệ và lưu traceability]
    XK --> XL[Đối soát sau khi hết hiệu lực]
    XL --> J[BA ghi decision record và traceability]
    XJ -- Không --> XM[Không thực hiện ngoại lệ; đánh giá thay đổi theo luồng chuẩn]
    XM --> P

    X -- Không --> B{Chất lượng bằng chứng?}
    B -- Trung bình hoặc yếu --> C[Verification required: ghi dữ liệu còn thiếu]
    C --> D[Đã bổ sung hoặc xác minh bằng chứng]
    D --> B
    B -- Mâu thuẫn --> E[Dừng quyết định thiết kế; ghi nguồn mâu thuẫn]
    E --> F[Owner phù hợp phân xử nguồn]
    F --> B
    B -- Mạnh --> P[BA nêu facts, inference, unknowns, phương án và tiêu chí]

    P --> G1{Liên quan nghiệp vụ?}
    G1 -- Có --> H[Business Owner quyết định phần nghiệp vụ]
    G1 -- Không --> G2{Có kiểm soát tài chính?}
    H --> G2
    G2 -- Có --> I[Accounting Owner xác nhận kiểm soát tài chính]
    G2 -- Không --> G3{Liên quan dữ liệu hoặc chất lượng dữ liệu?}
    I --> G3
    G3 -- Có --> K[Data Owner xác nhận dữ liệu]
    G3 -- Không --> G4{Liên quan pháp lý hoặc dữ liệu cá nhân?}
    K --> G4
    G4 -- Có --> L[Legal Owner xác nhận ràng buộc]
    G4 -- Không --> G5{Liên quan kiến trúc hoặc bảo mật?}
    L --> G5
    G5 -- Có --> M[Architect hoặc Security Owner quyết định hoặc xác nhận ràng buộc]
    G5 -- Không --> Q{Mọi owner liên quan đã quyết định hoặc xác nhận?}
    M --> Q
    Q -- Có --> J
    Q -- Không --> R[Chờ quyết định hoặc xác nhận còn thiếu]
    R --> Q

Tình huống	Đánh đổi cần nêu rõ	Bằng chứng tối thiểu	Thẩm quyền quyết định	Khuyến nghị BA
Thêm cấp duyệt cho đơn mua	Giảm rủi ro chi sai nhưng tăng thời gian chờ	Số giao dịch bị trả lại, thời gian xử lý hiện tại, loại rủi ro cần chặn	Business Owner; Accounting Owner nếu ảnh hưởng kiểm soát tài chính	Chỉ đề xuất cấp duyệt nếu người duyệt có thông tin hoặc quyền quyết định khác cấp trước
Tự động duyệt theo ngưỡng VND	Tăng tốc độ nhưng có nguy cơ áp sai ngưỡng hoặc dữ liệu đầu vào	Nguồn ngưỡng, trường dữ liệu, thời điểm kiểm tra, xử lý khi thiếu dữ liệu	Business Owner; Accounting Owner khi ngưỡng là kiểm soát tài chính	Ghi ngưỡng là Verification required nếu chưa có nguồn canonical
Cho phép duyệt thay khi người duyệt vắng mặt	Duy trì vận hành nhưng có nguy cơ phá phân tách nhiệm vụ	Vai trò thay thế, thời hạn, log ủy quyền, phạm vi quyền	Business Owner; Security Owner nếu ảnh hưởng quyền truy cập	Không suy luận rằng quản lý cấp trên luôn có quyền duyệt thay
Chặn đơn khi thiếu dữ liệu	Tăng chất lượng dữ liệu nhưng có thể dừng giao dịch khẩn	Danh sách trường bắt buộc, lý do nghiệp vụ, ngoại lệ và người xử lý	Business Owner; Data Owner	Phân biệt “cảnh báo” với “chặn”; hai lựa chọn tạo hậu quả vận hành khác nhau

Xung đột stakeholder không phải lỗi cần che. Ví dụ mô phỏng: Sales muốn bỏ bước kiểm tra tín dụng để giao hàng nhanh; Finance muốn chặn mọi đơn chưa có kết quả kiểm tra. Senior BA tách ý kiến khỏi bằng chứng. Sales cung cấp tác động thời gian và đơn bị chậm. Finance cung cấp rủi ro tín dụng, rule nguồn và hậu quả tài chính. BA không tự chọn bên thắng; BA lập phương án, chỉ ra dữ liệu còn thiếu, nêu tiêu chí quyết định, rồi chuyển đúng Business Owner và Accounting Owner.

Chất lượng bằng chứng	Dấu hiệu	Cách dùng trong recommendation
Mạnh	Quyết định được ghi nhận, rule canonical, dữ liệu nguồn có thời điểm và phạm vi rõ	Có thể dùng làm cơ sở đề xuất, vẫn không gọi là approval nếu chưa có tham chiếu approval
Trung bình	Biên bản workshop, số liệu vận hành chưa đối soát, ý kiến nhiều vai trò cùng hướng	Dùng để tạo giả thuyết và yêu cầu xác minh
Yếu	Phát biểu miệng, ảnh chụp không rõ nguồn, “hệ thống cũ làm vậy”	Không chuyển thành requirement hoặc rule
Mâu thuẫn	Hai nguồn canonical cho kết quả khác nhau, hoặc nguồn không khớp phạm vi	Dừng quyết định thiết kế; escalation tới owner phù hợp

Ngoại lệ không là “đường tắt”. Ngoại lệ là luồng có điều kiện kích hoạt, thời hạn, người cấp quyền, bằng chứng, và hậu quả sau khi hết hiệu lực. Quy tắc bình thường “mọi đơn phải qua phê duyệt” không áp dụng nguyên dạng khi có sự cố an toàn thực phẩm, gián đoạn sản xuất, hoặc yêu cầu khẩn được owner có thẩm quyền xác nhận. Tuy nhiên, việc một tình huống có vẻ khẩn không tự tạo quyền bỏ kiểm soát. Cần xác định ai xác nhận khẩn, dữ liệu nào chứng minh, và bước đối soát sau đó.

Senior BA ghi recommendation theo cấu trúc có thể bảo vệ: Facts là dữ liệu quan sát được; Inference là kết luận nối từ facts; Unknowns là phần chưa xác minh; Decision needed là quyết định cần owner đưa ra; Authority là vai trò có quyền quyết định; Artifact là nơi lưu traceability. Ví dụ: “Facts: luồng mô phỏng có hai bước duyệt nhưng chưa có rule nguồn phân biệt phạm vi hai bước. Inference: chưa đủ bằng chứng để cấu hình hai bước như kiểm soát bắt buộc. Unknowns: ngưỡng, dữ liệu đánh giá và quyền duyệt thay. Decision needed: giữ, gộp, hoặc bỏ bước thứ hai. Authority: Business Owner và Accounting Owner. Artifact: decision record liên kết CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY.” Cách ghi này nêu rõ mức chắc chắn, không bịa certainty, baseline, hoặc approval.

Senior Lens

Senior BA rà soát workflow bằng câu hỏi: “Quyết định nào có thể gây tổn thất, ai chịu hậu quả, bằng chứng nào đủ để cho phép chuyển trạng thái?” Quy trình không tốt không phải quy trình có ít bước; nó là quy trình không kiểm soát đúng rủi ro. Với Nova Foods mô phỏng, dữ liệu tổng hợp, ưu tiên kiểm tra điểm chuyển trạng thái, quyền quyết định, dữ liệu bắt buộc và ngoại lệ trước khi tranh luận màn hình hay câu chữ.

Heuristic rà soát	Kiểm tra cụ thể	Red flag	Ngưỡng escalation	Khi không áp dụng quy tắc thường
Một quyết định, một owner chịu trách nhiệm	Mỗi bước phê duyệt phải chỉ rõ vai trò quyết định cuối cùng, không chỉ người thao tác	“Finance và Sales cùng duyệt” nhưng không có quyền quyết định cuối	Hai vai trò cùng có quyền phủ quyết hoặc không rõ ai xử lý bế tắc	Sự kiện khẩn cấp có thể dùng quyền ủy quyền đã được kiểm soát; vẫn phải ghi nhận người quyết định và lý do
Approval phải đổi trạng thái hoặc giảm rủi ro	Xác định approval mở khóa hành động nào: xuất kho, ghi nhận công nợ, sửa giá, hủy chứng từ	Approval chỉ là nút bấm, không đổi quyền, dữ liệu hoặc trạng thái	Không giải thích được hậu quả nếu bỏ bước approval	Bước thông báo thuần túy không cần gọi là approval; dùng acknowledgement nếu chỉ xác nhận đã đọc
Bằng chứng phải gần nguồn phát sinh	So sánh dữ liệu workflow với chứng từ, giao dịch ERP, log tích hợp hoặc nguồn canonical	Quyết định dựa vào chat, ảnh chụp rời, file không rõ phiên bản	Bằng chứng tài chính, pháp lý, an toàn thực phẩm hoặc dữ liệu cá nhân không truy được nguồn	Trong sự cố hệ thống, có thể dùng bằng chứng tạm thời; phải gắn nhãn Verification required và đối soát sau
Ngoại lệ phải có đường quay lại kiểm soát	Mỗi bypass cần lý do, người cho phép, thời hạn, bước đối soát	“Cho qua lần này” không có mã lý do, thời hạn hoặc hậu kiểm	Bypass cho phép phát hành hàng, thay đổi giá, sửa dữ liệu hoặc bỏ kiểm tra bắt buộc	Không cho phép bypass nếu làm mất audit trail, vượt quyền truy cập, hoặc tạo nghĩa vụ pháp lý chưa được xác minh
Phân tách nhiệm vụ theo rủi ro	Kiểm tra một người có thể tạo, duyệt và thực hiện cùng giao dịch hay không	Cùng tài khoản tạo yêu cầu, duyệt và xác nhận hoàn tất	Một vai trò kiểm soát toàn bộ giao dịch có ảnh hưởng tiền, tồn kho hoặc dữ liệu nhạy cảm	Nhóm nhỏ có thể không tách hoàn toàn; cần kiểm soát bù trừ như review độc lập sau giao dịch
Rule phải kiểm thử được	Mỗi điều kiện có dữ liệu đầu vào, kết quả mong đợi, owner và ngoại lệ	“Hệ thống tự kiểm tra hợp lý” không có tiêu chí đo	Không thể viết acceptance criteria hoặc test case từ rule	Khám phá ban đầu có thể giữ giả định; không được chuyển thành rule triển khai
Trạng thái không được che giấu quyết định	IN_REVIEW phải cho biết đang chờ ai, chờ bằng chứng gì, điều kiện thoát là gì	IN_REVIEW được dùng như nơi chứa mọi việc chưa rõ	Item ở IN_REVIEW nhưng không có owner, ngày rà soát hoặc tiêu chí quyết định	Nghiên cứu mở có thể chưa có ngày hoàn tất; vẫn cần nêu câu hỏi quyết định và nguồn cần kiểm tra

Escalate khi thay đổi workflow chạm đồng thời business rule và quyền hệ thống; khi tác động dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc; khi hai nguồn canonical mâu thuẫn; hoặc khi một ngoại lệ có thể tạo giao dịch không thể đảo ngược. Senior BA lập gói vấn đề gồm workflow hiện tại, dữ liệu ảnh hưởng, lựa chọn, rủi ro và câu hỏi cần quyết định. Senior BA không tự kết luận pháp lý, kế toán, bảo mật hay cấp approval.

Không áp dụng nguyên tắc “chuẩn hóa mọi đường đi” khi tình huống có rủi ro thấp, tần suất thấp và chi phí tự động hóa lớn hơn lợi ích kiểm soát. Khi đó giữ xử lý thủ công có log, owner và tiêu chí xem xét lại. Không áp dụng nguyên tắc “thêm approval để an toàn hơn” nếu approval không có thẩm quyền, không có bằng chứng mới hoặc chỉ kéo dài lead time; bước đó phải bỏ, đổi thành notification, hoặc chuyển thành kiểm soát dữ liệu tự động.

Senior Lens

Senior BA không biến khoảng trống bằng chứng thành kết luận. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, khuyến nghị phải tách rõ: Fact là sự kiện có nguồn kiểm tra được; Assumption là giả định dự án; Verification required là nội dung cần vai trò có thẩm quyền xác minh; Recommendation là lựa chọn BA đề xuất từ bằng chứng hiện có. Cầu nối suy luận phải hiện diện: “Luồng duyệt hiện mô tả hai cấp duyệt trong bản nháp quy trình; chưa có bằng chứng về ngưỡng giá trị VND; vì vậy đề xuất cấu hình ngưỡng như tham số chờ Business Owner xác nhận, không ghi thành business rule.”

Trường ghi nhận	Nội dung artifact-ready
Claim	“Đơn mua vượt ngưỡng cần duyệt cấp hai.”
Evidence	Bản mô phỏng quy trình mua hàng Nova Foods ghi bước “Duyệt bổ sung”; không nêu ngưỡng, vai trò hay hiệu lực.
Confidence	Thấp với ngưỡng và người duyệt; trung bình với nhu cầu có bước duyệt bổ sung.
Reasoning bridge	Có bước duyệt bổ sung chứng minh nhu cầu kiểm soát tăng cường; thiếu điều kiện kích hoạt nên không đủ căn cứ xác định rule.
Recommendation	Giữ trạng thái IN_REVIEW; thiết kế điểm cấu hình approvalThresholdVND; yêu cầu Business Owner quyết định ngưỡng, Accounting Owner đánh giá ảnh hưởng ghi nhận, Architect đánh giá khả năng cấu hình.
Verification required	Xác minh thẩm quyền, ngưỡng VND, ngoại lệ khẩn cấp và dấu vết kiểm toán.
Decision authority	Business Owner quyết định chính sách nghiệp vụ; Accounting Owner xác nhận phần thuộc kế toán; Architect xác nhận giải pháp; Senior BA ghi nhận traceability, không tự phê duyệt.
Record location	Liên kết CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY và artifact workflow đang IN_REVIEW, v0.9.0, ngày 2026-08-07.

Ngôn ngữ khuyến nghị phải đo được mức chắc chắn. Dùng “bằng chứng hiện có cho thấy”, “có khả năng”, “chưa đủ bằng chứng để kết luận”, “cần xác minh bởi [vai trò]”. Không dùng “đã được chấp thuận”, “bắt buộc theo luật”, “cấu hình chuẩn” khi artifact không có approval, baseline hoặc xác minh nguồn phù hợp. Với nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc, ghi Verification required; handbook giáo dục không thay thế thẩm quyền pháp lý, kế toán hay production.

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

flowchart TB
    A[Evidence có nguồn kiểm tra được] --> B{Đủ evidence và confidence để kết luận business rule?}

    B -- Có --> C[Recommendation dựa trên evidence và reasoning bridge]
    B -- Không --> D{Có thể kiểm chứng bởi vai trò có thẩm quyền?}

    D -- Có --> E[Verification required bởi vai trò có thẩm quyền]
    D -- Không --> F[Assumption dự án]

    E --> G[Reasoning bridge: điều chưa biết, rủi ro nếu sai, điều kiện thay đổi]
    F --> G
    G --> H[Recommendation có điều kiện]
    C --> I[Senior BA ghi traceability]
    H --> I

    I --> J[Business Owner quyết định chính sách nghiệp vụ]
    I --> K{Có nội dung kế toán?}
    K -- Có --> L[Accounting Owner xác nhận nội dung kế toán]
    K -- Không --> M[Bỏ qua xác nhận kế toán]

    I --> N[Architect xác nhận phạm vi giải pháp]
    J --> O{Các quyết định hoặc xác minh bắt buộc theo phạm vi đã hoàn tất?}
    L --> O
    M --> O
    N --> O

    O -- Chưa --> P[Giữ artifact IN_REVIEW]
    P --> Q[Không gọi là approved hoặc baselined]
    Q --> R[Verification hoặc thay đổi có traceability]
    R --> A

    O -- Rồi --> S{Có approval hoặc baseline tương ứng?}
    S -- Chưa --> T[Ghi outcome; giữ trạng thái IN_REVIEW]
    S -- Có --> U[Ghi outcome và trạng thái tương ứng với approval hoặc baseline]

Khuyến nghị có thể bảo vệ được không cần chắc chắn tuyệt đối. Nó cần nêu phạm vi, bằng chứng, điều chưa biết, tác động nếu giả định sai, người có quyền quyết định và điều kiện thay đổi. Ví dụ: “Khuyến nghị không cho phép tự động vượt bước duyệt trong tình huống khẩn cấp, vì chưa có bằng chứng về kiểm soát bù trừ. Nếu Business Owner xác nhận ngoại lệ khẩn cấp và Security cùng Architect xác nhận audit trail, cập nhật workflow qua thay đổi có truy vết.” Câu này không dựng certainty, vẫn cho nhóm biết quyết định nào còn mở và bằng chứng nào đóng quyết định.

12. Associated Template Reference & Completed Artifact

Core

Template là khuôn điền lặp lại để giữ cấu trúc, trường bắt buộc và kiểm tra chất lượng nhất quán. Template không tự tạo quy tắc nghiệp vụ, quyền duyệt hay phê duyệt. Bằng chứng: TEMPLATE_MANIFEST đang IN_REVIEW, v0.9.0, ngày 2026-08-07, chưa có baseline hoặc approval. Vì compact dependency chưa cung cấp ID và filename của template workflow/approval đã đăng ký, không được tự tạo ID dạng TMPL-WF-001 hoặc suy diễn đường dẫn /03-templates/.

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

flowchart TB
    A[Đối chiếu TEMPLATE_MANIFEST] --> B["Trạng thái: IN_REVIEW<br/>Phiên bản: v0.9.0<br/>Ngày: 2026-08-07<br/>Chưa có baseline<br/>Chưa có approval"]
    B --> C{Compact dependency có cung cấp<br/>ID và filename đã đăng ký?}
    C -- "Không — hiện tại" --> D[Không tạo ID hoặc filename mới]
    C -. "Có — khi dữ liệu được cung cấp" .-> E[Dùng đúng ID và filename đã đăng ký]
    D --> F[Không suy diễn đường dẫn /03-templates/]
    E --> G[Template chỉ giữ cấu trúc,<br/>trường bắt buộc và kiểm tra chất lượng]
    F --> G
    G --> H[Template không tạo quy tắc nghiệp vụ,<br/>quyền duyệt hoặc phê duyệt]

Applied

Trường	Nội dung Nova Foods Trading & Manufacturing — mô phỏng, dữ liệu tổng hợp
Facts	TEMPLATE_MANIFEST là nguồn quản trị template dự kiến; dependency cung cấp Artifact ID và filename /01-curriculum/TEMPLATE_MANIFEST.md, nhưng không cung cấp template workflow/approval cụ thể.
Current Behavior	Chapter 13 cần tham chiếu template liên quan quy trình và phê duyệt, nhưng chưa có bằng chứng về template ID hoặc tệp /03-templates/ đã đăng ký.
Underlying Need	Người viết cần biết dùng khuôn nào mà không biến kế hoạch học liệu thành cấu hình ERP hay tự tạo nguồn chân lý mới.
Options	Dùng ID tự đặt; chép template không có registry; hoặc chỉ tham chiếu artifact quản trị đã xác minh.
Decision Criteria	Giữ canonical ID, filename, source classification; không claim baseline, approval hoặc template đã tồn tại khi chưa có bằng chứng.
Decision	Chỉ map TEMPLATE_MANIFEST như manifest quản trị; không map template workflow/approval cụ thể cho đến khi manifest đăng ký ID và filename.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì manifest; không có quyền tự baseline, approval, xác nhận nghiệp vụ Nova Foods hoặc production use.
Artifact	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md; trạng thái IN_REVIEW, version v0.9.0.
Consequence if Wrong	ID hoặc filename bịa làm đứt traceability, khiến learner dùng sai nguồn, và có thể bị hiểu nhầm là template đã được phê duyệt.

Senior Lens

Không dùng manifest như completed template. Manifest trả lời “template nào được quản trị”; completed artifact trả lời “ai đã điền gì, dựa trên bằng chứng nào, quyết định bởi ai”. Hai chức năng khác nhau. Khi template workflow được đăng ký, BA phải kiểm tra tối thiểu: ID không trùng TRACEABILITY_ID_REGISTRY, rule tham chiếu đúng CANONICAL_BUSINESS_RULES, dữ liệu logic không mâu thuẫn CANONICAL_DATA_DICTIONARY, và quyền quyết định không bị gán cho Owner quản trị tài liệu.

Quick Reference

Associated ID	Filename	Phân loại nguồn	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact; template manifest	Cần xác minh template nào đã được đăng ký, phạm vi template, metadata và boundary sử dụng	Cần điền workflow, gán approver, hoặc chứng minh completed artifact	Principal IT Business Analyst / Technical Curriculum Author	BA curriculum author, reviewer quản trị corpus	ID, filename, status IN_REVIEW, version v0.9.0, ngày 2026-08-07 khớp manifest; không suy diễn template chưa đăng ký
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical identifier registry plan	Cần kiểm tra ID artifact hoặc liên kết traceability	Cần tạo ID template mới không qua registry	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, curriculum reviewer	Giữ nguyên canonical ID; escalation khi ID có thể thành quyết định nghiệp vụ, pháp lý, kế toán, kiến trúc hoặc bảo mật
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan	Cần đối chiếu rule tác động bước duyệt hoặc điều kiện chuyển trạng thái	Cần tự xác nhận rule Nova Foods là vận hành thực	Principal IT Business Analyst / Technical Curriculum Author	BA, Business Owner, QA reviewer	Rule giữ IN_REVIEW; nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm ghi Verification required khi chưa được vai trò có thẩm quyền xác minh
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical logical data dictionary plan	Cần kiểm tra trường dữ liệu workflow, approver, trạng thái hoặc audit evidence	Cần suy diễn schema ERP vật lý hay cấu hình production	Principal IT Business Analyst / Technical Curriculum Author	BA, Architect, QA reviewer	Phân biệt dữ liệu logic với schema triển khai; không thêm field hoặc constraint không có nguồn canonical

Quick Reference

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Artifact đã điền của chương này nằm tại /02-handbook/13-process-design-workflows-and-approvals.md, mục 8. Detailed Worked Example. Đây là nơi tra cứu ví dụ workflow và approval đã được điền; không suy diễn đó là cấu hình ERP thật, quyết định vận hành, baseline hay phê duyệt.

Mục tra cứu	Vị trí trong chapter	Kiểm tra phải đạt
Khái niệm workflow và approval	1. Concept l? g??	Phân biệt workflow là luồng công việc với approval là quyết định của người có thẩm quyền.
Lý do tồn tại	2. T?i sao concept n?y t?n t?i?	Nêu rủi ro kiểm soát khi không có bước, trạng thái hoặc người quyết định rõ.
Lifecycle	3. V? tr? trong Lifecycle	Xác định workflow xuất hiện sau khi hiểu quy trình và trước khi đặc tả build, test.
Input	4. Input c?n thi?t	Có process, actor, business rule, dữ liệu, exception và giới hạn thẩm quyền.
Hoạt động BA	5. Step-by-step BA Activities	Có bước khảo sát current state, thiết kế future state, quyết định và traceability.
Output	6. Output thu ???c	Có workflow diagram, trạng thái, approval matrix, rule và acceptance criteria khi phù hợp.
Người dùng output	7. Who consumes those outputs?	Business Owner, Architect, developer, QA, Security và vận hành đọc đúng phần thuộc trách nhiệm.
Artifact đã điền	8. Detailed Worked Example	Đối chiếu Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Decision, Authority, Artifact, Consequence if Wrong.
Dependency	9. Related Concepts & Dependencies	Liên kết process, requirement, business rule, data, integration, test và governance.
Sai lầm thường gặp	10. Common Mistakes & Anti-patterns	Không biến sơ đồ thành quy tắc chưa xác minh; không gán approval ngầm định.
Senior review	11. Senior BA Notes & Rules of Thumb	Kiểm tra quyền quyết định, exception, audit trail và điểm escalation.
Template và artifact	12. Associated Template Reference & Completed Artifact	Dùng checklist này để tìm đúng phần; không thay thế CHAPTER_MANIFEST, TEMPLATE_MANIFEST hoặc registry canonical.

Tra cứu quản trị chapter trước khi dùng artifact: xác nhận Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Bằng chứng là metadata corpus quy định các giá trị này; vì IN_REVIEW không phải BASELINED hay APPROVED, người đọc chỉ dùng nội dung cho học liệu và review có kiểm soát.

Khi cần xác định ID, dependency hoặc nguồn chân lý, tra cứu đúng artifact canonical: /01-curriculum/CHAPTER_MANIFEST.md cho cấu trúc chapter, /01-curriculum/TEMPLATE_MANIFEST.md cho template dự kiến, /01-curriculum/TRACEABILITY_ID_REGISTRY.md cho ID, /01-curriculum/CANONICAL_BUSINESS_RULES.md cho rule và /01-curriculum/CANONICAL_DATA_DICTIONARY.md cho dữ liệu logic. Checklist chỉ chỉ đường; không sao chép hay thay thế canonical registry.

Senior Lens

Trước handoff chapter, BA kiểm chéo các nguồn canonical. Mục tiêu: phát hiện mâu thuẫn trước khi nội dung học liệu bị hiểu nhầm thành quyết định ERP Nova Foods. Nova Foods là case mô phỏng; 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 approval.

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

flowchart TB
    A[Đọc chapter workflow] --> B[Đối chiếu ID, file, status, version]
    B --> C{Mâu thuẫn hoặc suy diễn vượt nguồn?}

    C -- Không --> D[Giữ nhãn Verification required]
    C -- Có --> E[Ghi issue và evidence]
    E --> F[Chọn owner theo loại evidence hoặc domain]
    F --> G[Escalate owner chuyên môn]
    G --> H{Đủ evidence theo điều kiện đóng issue?}

    H -- Có --> I[Cập nhật issue theo evidence xác nhận]
    H -- Chưa đủ --> J[Giữ issue mở và nhãn Verification required]
    I --> D
    J --> K[Không đóng issue bằng suy đoán hoặc chỉ bằng escalation]
    K --> L[Không ghi nhận user approval]
    L --> D

    D --> M[Package handoff review:<br/>chapter + bảng issue + evidence path<br/>+ nhãn Verification required]

Hạng mục kiểm chéo	Bằng chứng cần đối chiếu	Kết quả hiện tại	Owner escalation nếu sai
Danh tính chapter	/01-curriculum/CHAPTER_MANIFEST.md; đường dẫn /02-handbook/13-process-design-workflows-and-approvals.md	Cần xác minh chapter entry giữ đúng filename và cấu trúc 12 H2.	Principal IT Business Analyst / Technical Curriculum Author
ID và traceability	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Không được tự tạo ID workflow, approval, rule hay requirement ngoài registry.	Principal IT Business Analyst / Technical Curriculum Author
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Không có bằng chứng trong input cho phép khẳng định rule approval Nova Foods là vận hành thật.	Business Owner; Principal IT Business Analyst / Technical Curriculum Author
Dữ liệu workflow	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên trạng thái, trường dữ liệu, actor phải giữ nhãn mô phỏng nếu chưa có định nghĩa canonical được xác minh.	Data Owner; Principal IT Business Analyst / Technical Curriculum Author
Ranh giới nguồn	/00-research/00_SOURCE_MAP.md	BPMN chỉ dùng khi gọi đúng BPMN 2.0.2; sơ đồ Mermaid không được gọi là BPMN.	Principal IT Business Analyst / Technical Curriculum Author
Pháp lý, kế toán, hóa đơn, an toàn thực phẩm	URL nguồn chính thức trong 00_SOURCE_MAP	Nội dung có thể cần diễn giải chuyên môn. Không được biến nguồn tham khảo thành nghĩa vụ cấu hình ERP.	Legal Owner; Accounting Owner; Compliance Owner; Food Safety Domain Owner
Bảo mật và API	OWASP ASVS 5.0.0; OWASP API Security Top 10 2023; OAS 3.1.1 nếu có API	Chưa có bằng chứng kiến trúc hay security design để kết luận control cụ thể.	Security Owner; Technical Architect
Khả năng kiểm thử	Acceptance criteria, rule, state transition phải truy vết được	Chưa được xác nhận test basis hoặc test result.	QA Reviewer
Governance	CHAPTER_MANIFEST, TEMPLATE_MANIFEST, 01_CURRICULUM_ARCHITECTURE	Tất cả artifact nguồn là IN_REVIEW, v0.9.0; không ghi “approved”, “baselined”, “compliant”, hay production-ready.	Principal IT Business Analyst / Technical Curriculum Author

Open issues trước handoff

ID	Issue	Evidence và reasoning	Escalation owner	Điều kiện đóng
ISS-13-001	Thẩm quyền approval workflow chưa được xác nhận	Input chỉ xác nhận corpus học liệu mô phỏng. Không có ma trận ủy quyền Nova Foods đã được phê duyệt.	Business Owner	Business Owner cung cấp hoặc xác nhận nguồn authority dùng cho case học liệu.
ISS-13-002	Nghĩa vụ pháp lý cho dữ liệu cá nhân, kế toán, hóa đơn và truy xuất chưa được diễn giải chuyên môn	Source map nêu luật và nghị định, nhưng cấm tự suy diễn chi tiết chưa kiểm chứng.	Legal Owner; Accounting Owner; Compliance Owner; Food Safety Domain Owner	Mỗi owner xác nhận phạm vi diễn giải hoặc yêu cầu giữ Verification required.
ISS-13-003	Security control cho luồng phê duyệt chưa có architecture evidence	OWASP là good practice; không phải bằng chứng Nova Foods đã chọn cơ chế xác thực, phân quyền, audit log.	Security Owner; Technical Architect	Có security/architecture decision traceable, hoặc giữ nội dung ở mức giả định học liệu.
ISS-13-004	Test evidence chưa tồn tại	Không có test case, test execution, defect log hay QA sign-off trong input.	QA Reviewer	QA Reviewer xác định test basis và trạng thái review; không thay bằng claim pass.

Verification required: kiểm tra mọi ID tồn tại trong registry; kiểm tra mọi filename khớp manifest; kiểm tra trạng thái IN_REVIEW và version v0.9.0 nhất quán; kiểm tra mô tả workflow không tạo requirement, approval hay compliance claim mới; kiểm tra mọi escalation giữ đúng owner chuyên môn.

Handoff chỉ chuyển package review gồm chapter, bảng issue, evidence path và nhãn Verification required. Không đóng issue bằng suy đoán. Không ghi nhận user approval.

Quy trình và điểm quyết định

Sơ đồ BPMN làm rõ vai trò, sự kiện và điểm quyết định được mô tả trong phần này.

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

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
  id="Definitions_ProcessDesignWorkflowsApprovals"
  targetNamespace="http://novafoods.example/handbook/process-design-workflows-approvals">

  <bpmn:collaboration id="Collaboration_WarehouseIssueRequest">
    <bpmn:participant id="Participant_WarehouseIssueWorkflow"
      name="Workflow yêu cầu xuất kho mô phỏng"
      processRef="Process_WarehouseIssueRequest"/>
  </bpmn:collaboration>

  <bpmn:process id="Process_WarehouseIssueRequest"
    name="Yêu cầu xuất kho: tạo, gửi duyệt, quyết định"
    isExecutable="false">

    <bpmn:laneSet id="LaneSet_WarehouseIssueWorkflow">
      <bpmn:lane id="Lane_WarehouseStaff" name="Nhân viên kho">
        <bpmn:flowNodeRef>StartEvent_CreateRequest</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>UserTask_CreateRequest</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>UserTask_SubmitForApproval</bpmn:flowNodeRef>
      </bpmn:lane>

      <bpmn:lane id="Lane_WarehouseManager" name="Quản lý kho">
        <bpmn:flowNodeRef>UserTask_DecideRequest</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>Gateway_DecisionOutcome</bpmn:flowNodeRef>
      </bpmn:lane>

      <bpmn:lane id="Lane_System" name="Hệ thống">
        <bpmn:flowNodeRef>ServiceTask_RecordDraft</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>ServiceTask_RecordPendingApproval</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>ServiceTask_RecordApproval</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>EndEvent_Approved</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>ServiceTask_RecordRejection</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>EndEvent_Rejected</bpmn:flowNodeRef>
      </bpmn:lane>
    </bpmn:laneSet>

    <bpmn:startEvent id="StartEvent_CreateRequest" name="Cần yêu cầu xuất kho">
      <bpmn:outgoing>Flow_Start_Create</bpmn:outgoing>
    </bpmn:startEvent>

    <bpmn:userTask id="UserTask_CreateRequest" name="Tạo yêu cầu xuất kho">
      <bpmn:incoming>Flow_Start_Create</bpmn:incoming>
      <bpmn:outgoing>Flow_Create_RecordDraft</bpmn:outgoing>
    </bpmn:userTask>

    <bpmn:serviceTask id="ServiceTask_RecordDraft" name="Ghi trạng thái DRAFT">
      <bpmn:incoming>Flow_Create_RecordDraft</bpmn:incoming>
      <bpmn:outgoing>Flow_RecordDraft_Submit</bpmn:outgoing>
    </bpmn:serviceTask>

    <bpmn:userTask id="UserTask_SubmitForApproval" name="Gửi yêu cầu duyệt">
      <bpmn:incoming>Flow_RecordDraft_Submit</bpmn:incoming>
      <bpmn:outgoing>Flow_Submit_RecordPending</bpmn:outgoing>
    </bpmn:userTask>

    <bpmn:serviceTask id="ServiceTask_RecordPendingApproval" name="Ghi trạng thái PENDING_APPROVAL">
      <bpmn:incoming>Flow_Submit_RecordPending</bpmn:incoming>
      <bpmn:outgoing>Flow_RecordPending_Decide</bpmn:outgoing>
    </bpmn:serviceTask>

    <bpmn:userTask id="UserTask_DecideRequest" name="Quyết định phê duyệt hoặc từ chối">
      <bpmn:incoming>Flow_RecordPending_Decide</bpmn:incoming>
      <bpmn:outgoing>Flow_Decide_Gateway</bpmn:outgoing>
    </bpmn:userTask>

    <bpmn:exclusiveGateway id="Gateway_DecisionOutcome" name="Kết quả quyết định?"
      gatewayDirection="Diverging">
      <bpmn:incoming>Flow_Decide_Gateway</bpmn:incoming>
      <bpmn:outgoing>Flow_Approved_Record</bpmn:outgoing>
      <bpmn:outgoing>Flow_Rejected_Record</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:serviceTask id="ServiceTask_RecordApproval"
      name="Ghi APPROVED, người quyết định và thời điểm">
      <bpmn:incoming>Flow_Approved_Record</bpmn:incoming>
      <bpmn:outgoing>Flow_RecordApproval_End</bpmn:outgoing>
    </bpmn:serviceTask>

    <bpmn:endEvent id="EndEvent_Approved" name="Yêu cầu APPROVED">
      <bpmn:incoming>Flow_RecordApproval_End</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:serviceTask id="ServiceTask_RecordRejection"
      name="Ghi REJECTED, người quyết định, thời điểm và lý do">
      <bpmn:incoming>Flow_Rejected_Record</bpmn:incoming>
      <bpmn:outgoing>Flow_RecordRejection_End</bpmn:outgoing>
    </bpmn:serviceTask>

    <bpmn:endEvent id="EndEvent_Rejected" name="Yêu cầu REJECTED">
      <bpmn:incoming>Flow_RecordRejection_End</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:sequenceFlow id="Flow_Start_Create"
      sourceRef="StartEvent_CreateRequest"
      targetRef="UserTask_CreateRequest"/>

    <bpmn:sequenceFlow id="Flow_Create_RecordDraft"
      sourceRef="UserTask_CreateRequest"
      targetRef="ServiceTask_RecordDraft"/>

    <bpmn:sequenceFlow id="Flow_RecordDraft_Submit"
      sourceRef="ServiceTask_RecordDraft"
      targetRef="UserTask_SubmitForApproval"/>

    <bpmn:sequenceFlow id="Flow_Submit_RecordPending"
      sourceRef="UserTask_SubmitForApproval"
      targetRef="ServiceTask_RecordPendingApproval"/>

    <bpmn:sequenceFlow id="Flow_RecordPending_Decide"
      sourceRef="ServiceTask_RecordPendingApproval"
      targetRef="UserTask_DecideRequest"/>

    <bpmn:sequenceFlow id="Flow_Decide_Gateway"
      sourceRef="UserTask_DecideRequest"
      targetRef="Gateway_DecisionOutcome"/>

    <bpmn:sequenceFlow id="Flow_Approved_Record"
      name="Phê duyệt"
      sourceRef="Gateway_DecisionOutcome"
      targetRef="ServiceTask_RecordApproval"/>

    <bpmn:sequenceFlow id="Flow_Rejected_Record"
      name="Từ chối"
      sourceRef="Gateway_DecisionOutcome"
      targetRef="ServiceTask_RecordRejection"/>

    <bpmn:sequenceFlow id="Flow_RecordApproval_End"
      sourceRef="ServiceTask_RecordApproval"
      targetRef="EndEvent_Approved"/>

    <bpmn:sequenceFlow id="Flow_RecordRejection_End"
      sourceRef="ServiceTask_RecordRejection"
      targetRef="EndEvent_Rejected"/>
  </bpmn:process>

  <bpmndi:BPMNDiagram id="BPMNDiagram_WarehouseIssueRequest">
    <bpmndi:BPMNPlane id="BPMNPlane_WarehouseIssueRequest"
      bpmnElement="Collaboration_WarehouseIssueRequest">

      <bpmndi:BPMNShape id="Participant_WarehouseIssueWorkflow_di"
        bpmnElement="Participant_WarehouseIssueWorkflow"
        isHorizontal="true">
        <dc:Bounds x="80" y="80" width="1450" height="600"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Lane_WarehouseStaff_di"
        bpmnElement="Lane_WarehouseStaff"
        isHorizontal="true">
        <dc:Bounds x="110" y="80" width="1420" height="190"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Lane_WarehouseManager_di"
        bpmnElement="Lane_WarehouseManager"
        isHorizontal="true">
        <dc:Bounds x="110" y="270" width="1420" height="190"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Lane_System_di"
        bpmnElement="Lane_System"
        isHorizontal="true">
        <dc:Bounds x="110" y="460" width="1420" height="220"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="StartEvent_CreateRequest_di"
        bpmnElement="StartEvent_CreateRequest">
        <dc:Bounds x="160" y="157" width="36" height="36"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="120" y="198" width="115" height="28"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="UserTask_CreateRequest_di"
        bpmnElement="UserTask_CreateRequest">
        <dc:Bounds x="260" y="135" width="150" height="80"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="ServiceTask_RecordDraft_di"
        bpmnElement="ServiceTask_RecordDraft">
        <dc:Bounds x="465" y="495" width="150" height="80"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="UserTask_SubmitForApproval_di"
        bpmnElement="UserTask_SubmitForApproval">
        <dc:Bounds x="670" y="135" width="150" height="80"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="ServiceTask_RecordPendingApproval_di"
        bpmnElement="ServiceTask_RecordPendingApproval">
        <dc:Bounds x="875" y="495" width="180" height="80"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="UserTask_DecideRequest_di"
        bpmnElement="UserTask_DecideRequest">
        <dc:Bounds x="1105" y="325" width="190" height="80"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Gateway_DecisionOutcome_di"
        bpmnElement="Gateway_DecisionOutcome"
        isMarkerVisible="true">
        <dc:Bounds x="1350" y="340" width="50" height="50"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="ServiceTask_RecordApproval_di"
        bpmnElement="ServiceTask_RecordApproval">
        <dc:Bounds x="1120" y="485" width="195" height="100"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="EndEvent_Approved_di"
        bpmnElement="EndEvent_Approved">
        <dc:Bounds x="1385" y="517" width="36" height="36"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="1345" y="558" width="115" height="20"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="ServiceTask_RecordRejection_di"
        bpmnElement="ServiceTask_RecordRejection">
        <dc:Bounds x="1120" y="600" width="195" height="65"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="EndEvent_Rejected_di"
        bpmnElement="EndEvent_Rejected">
        <dc:Bounds x="1385" y="615" width="36" height="36"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="1340" y="650" width="125" height="20"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNEdge id="Flow_Start_Create_di" bpmnElement="Flow_Start_Create">
        <di:waypoint x="196" y="175"/>
        <di:waypoint x="260" y="175"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_Create_RecordDraft_di" bpmnElement="Flow_Create_RecordDraft">
        <di:waypoint x="410" y="175"/>
        <di:waypoint x="440" y="175"/>
        <di:waypoint x="440" y="535"/>
        <di:waypoint x="465" y="535"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_RecordDraft_Submit_di" bpmnElement="Flow_RecordDraft_Submit">
        <di:waypoint x="615" y="535"/>
        <di:waypoint x="645" y="535"/>
        <di:waypoint x="645" y="175"/>
        <di:waypoint x="670" y="175"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_Submit_RecordPending_di" bpmnElement="Flow_Submit_RecordPending">
        <di:waypoint x="820" y="175"/>
        <di:waypoint x="850" y="175"/>
        <di:waypoint x="850" y="535"/>
        <di:waypoint x="875" y="535"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_RecordPending_Decide_di" bpmnElement="Flow_RecordPending_Decide">
        <di:waypoint x="1055" y="535"/>
        <di:waypoint x="1080" y="535"/>
        <di:waypoint x="1080" y="365"/>
        <di:waypoint x="1105" y="365"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_Decide_Gateway_di" bpmnElement="Flow_Decide_Gateway">
        <di:waypoint x="1295" y="365"/>
        <di:waypoint x="1350" y="365"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_Approved_Record_di" bpmnElement="Flow_Approved_Record">
        <di:waypoint x="1375" y="390"/>
        <di:waypoint x="1375" y="450"/>
        <di:waypoint x="1218" y="450"/>
        <di:waypoint x="1218" y="485"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="1280" y="430" width="65" height="20"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_Rejected_Record_di" bpmnElement="Flow_Rejected_Record">
        <di:waypoint x="1375" y="390"/>
        <di:waypoint x="1375" y="632"/>
        <di:waypoint x="1315" y="632"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="1378" y="480" width="55" height="20"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_RecordApproval_End_di" bpmnElement="Flow_RecordApproval_End">
        <di:waypoint x="1315" y="535"/>
        <di:waypoint x="1385" y="535"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_RecordRejection_End_di" bpmnElement="Flow_RecordRejection_End">
        <di:waypoint x="1315" y="632"/>
        <di:waypoint x="1385" y="633"/>
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Đọc từ sự kiện bắt đầu qua từng swimlane; gateway tách các kết quả theo điều kiện đã nêu trong nội dung.