/03-templates/TMPL-CR-001_change-request.md — Mẫu Yêu Cầu Thay Đổi (Change Request)

Bảng metadata quản trị dưới đây xác định danh tính, phiên bản, trạng thái, và các quy tắc kiểm soát cho artifact này. Metadata này là nguồn chân lý cho mọi tham chiếu quản trị trong phạm vi corpus của dự án mô phỏng Nova Foods.

Trường kiểm soát	Giá trị kiểm soát	Diễn giải và Ghi chú
Artifact ID	TMPL-CR-001	Định danh duy nhất và không thay đổi của mẫu Yêu Cầu Thay Đổi (CR). Mọi liên kết truy vết (traceability) phải sử dụng ID này.
Tên tệp được kiểm soát	/03-templates/TMPL-CR-001_change-request.md	Đường dẫn canonical của artifact trong cấu trúc kho mã nguồn. Đây là bản gốc được kiểm soát.
Trạng thái (Status)	IN_REVIEW	Artifact đang trong quá trình xem xét có kiểm soát. Trạng thái này không có nghĩa là đã phê duyệt (APPROVED), đã chốt (BASELINED), hoặc sẵn sàng cho sử dụng trong sản xuất.
Phiên bản (Version)	v0.9.0	Phiên bản hiện hành của artifact tại thời điểm cập nhật gần nhất. Mọi thay đổi phải tuân thủ quy trình quản lý phiên bản của corpus.
Owner	Principal IT Business Analyst / Technical Curriculum Author	Vai trò chịu trách nhiệm duy trì tính toàn vẹn của cấu trúc mẫu, metadata quản trị, và hướng dẫn sử dụng.
Ngày cập nhật gần nhất	2026-08-07	Ngày cập nhật gần nhất, được ghi nhận theo múi giờ Asia/Ho_Chi_Minh.
Múi giờ / Locale	Asia/Ho_Chi_Minh / vi-VN	Múi giờ và locale chuẩn cho mọi ngữ cảnh liên quan đến thời gian và định dạng trong case study. Đơn vị tiền tệ mô phỏng là VND.
Ranh giới dữ liệu mô phỏng	Dữ liệu tổng hợp, chỉ cho mục đích giáo dục.	Mọi dữ liệu điền vào mẫu này, đặc biệt là ở Tier 3 (Ví dụ hoàn chỉnh cho Nova Foods), là dữ liệu mô phỏng. Chúng không đại diện cho quyết định nghiệp vụ thực tế, cấu hình ERP thật, dữ liệu tài chính, hoặc trạng thái tuân thủ pháp lý của bất kỳ tổ chức nào.
Lịch sử thay đổi	v0.9.0 (2026-08-07): Khởi tạo artifact. Thiết lập metadata quản trị, cấu trúc 4 tầng, và hoàn thành nội dung cho Mục 1: Tier 1 - Metadata, Purpose, and Governance.	Ghi nhận các thay đổi quan trọng. Không được sửa đổi im lặng (silent modification) các phiên bản đã phát hành.

1. Tier 1 – Metadata, Purpose, and Governance

Metadata quản trị

Trường quản trị	Giá trị	Nguồn hoặc nghĩa vụ kiểm soát
Artifact ID	TMPL-CR-001	/01-curriculum/TEMPLATE_MANIFEST.md
Tên tệp	/03-templates/TMPL-CR-001_change-request.md	/01-curriculum/TEMPLATE_MANIFEST.md
Loại Artifact	Template (Tier 1-4)	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md
Status	IN_REVIEW	Artifact chưa được BASELINED hoặc phê duyệt.
Owner	Owner của template chịu trách nhiệm kiểm soát nội dung, lịch sử thay đổi và thông báo ảnh hưởng cho Owner artifact liên quan.	Nghĩa vụ kiểm soát tại Bảng 3.
Version	Mỗi chỉnh sửa template phải tạo phiên bản mới và được ghi nhận trong mục "Lịch sử Thay đổi" của template.	Nghĩa vụ kiểm soát tại Bảng 3.

Mục đích, Phạm vi sử dụng và Quy trình Quản trị

Mẫu này dùng để lập tài liệu chính thức cho một đề xuất thay đổi có kiểm soát đối với một sản phẩm, hệ thống hoặc cấu phần đã được chốt (baseline). Một Change Request (CR), hay Yêu cầu Thay đổi, là công cụ cốt lõi để quản lý sự thay đổi phạm vi (scope creep) một cách có trật tự. Nó được sử dụng sau khi một phiên bản của tài liệu hoặc sản phẩm đã được phê duyệt chính thức, gọi là baseline. Mọi thay đổi sau baseline phải được ghi nhận trong một CR để phân tích đầy đủ về tác động, chi phí, lợi ích và rủi ro trước khi được phê duyệt và triển khai. Việc này đảm bảo tính minh bạch và khả năng truy vết cho tất cả các bên liên quan.

Ranh giới sử dụng

Bảng sau định nghĩa rõ ràng khi nào nên và không nên sử dụng mẫu Yêu cầu Thay đổi này trong bối cảnh dự án ERP của Nova Foods.

Khi nào SỬ DỤNG mẫu này	Khi nào KHÔNG SỬ DỤNG mẫu này
Đề xuất thay đổi một yêu cầu nghiệp vụ đã được baseline trong tài liệu BRD hoặc SRS.	Thu thập yêu cầu nghiệp vụ trong giai đoạn khởi tạo dự án (sử dụng mẫu BRD).
Yêu cầu thêm một trường dữ liệu mới vào một bảng dữ liệu đã được chốt cấu trúc logic.	Báo cáo một lỗi kỹ thuật (bug) trong quá trình phát triển (sử dụng hệ thống tracking như Jira).
Đề xuất sửa một lỗi được phát hiện trong quá trình Kiểm thử Chấp nhận của Người dùng (UAT) mà việc sửa lỗi đó làm thay đổi phạm vi đã thống nhất.	Đặt câu hỏi hoặc yêu cầu làm rõ một yêu cầu nghiệp vụ chưa rõ ràng (sử dụng Q&A Log hoặc kênh giao tiếp dự án).
Yêu cầu thay đổi một quy tắc nghiệp vụ (business rule) đã được định nghĩa trong CANONICAL_BUSINESS_RULES.	Đề xuất ý tưởng hoặc chức năng mới cho một phân hệ chưa được phân tích hoặc thiết lập baseline.
Thay đổi một giao diện người dùng (UI) đã được phê duyệt bản thiết kế (mockup/prototype).	Tranh luận về một quyết định thiết kế kỹ thuật (sử dụng các buổi họp review kỹ thuật).

Vai trò, Thẩm quyền và Leo thang

Việc quản lý một CR đòi hỏi sự tham gia và phân định trách nhiệm rõ ràng.

Hạng mục	Diễn giải trong bối cảnh Nova Foods
Owner	Người khởi tạo và chịu trách nhiệm về nội dung của CR. Vai trò này thường do Business Analyst, Product Owner hoặc một Business User được ủy quyền đảm nhiệm. Owner phải cung cấp đầy đủ luận cứ, bằng chứng và phân tích tác động sơ bộ.
Consumers	Các bên liên quan đọc, xem xét, và sử dụng thông tin trong CR để ra quyết định. Bao gồm: Project Manager, Technical Architect, QA Lead, Development Team Lead, và các Business Owner bị ảnh hưởng.
Prerequisites (Điều kiện tiên quyết)	Phải có một tham chiếu rõ ràng đến artifact đã được baseline cần thay đổi (ví dụ: BRD-PURCH-01 v1.3 BASELINED). Phải có mã định danh của vấn đề gốc nếu có (ví dụ: UAT-FAIL-1023).
Downstream Artifacts (Sản phẩm đầu ra)	Một CR được phê duyệt sẽ là đầu vào để: cập nhật tài liệu BRD/SRS, tạo hoặc cập nhật User Story/PBI, tạo Test Case mới, cập nhật tài liệu hướng dẫn người dùng, và ghi nhận trong Release Notes.
Approval Authority (Thẩm quyền phê duyệt)	Đối với các thay đổi nhỏ (ước tính < 8 giờ công, không ảnh hưởng ngân sách/tiến độ tổng thể), Product Owner có thể phê duyệt. Đối với các thay đổi lớn hơn, cần có sự phê duyệt từ Change Control Board (CCB), hay Ban Kiểm soát Thay đổi. CCB của dự án ERP Nova Foods bao gồm: Giám đốc Nghiệp vụ liên quan (Business Owner), Kiến trúc sư trưởng (Lead Architect), Trưởng phòng QA, và Quản lý Dự án (Project Manager).
Escalation Path (Lộ trình leo thang)	Nếu CCB không đạt được đồng thuận, vấn đề sẽ được leo thang lên Ban chỉ đạo Dự án (Project Steering Committee) để ra quyết định cuối cùng. Nếu có xung đột về quy trình hoặc thẩm quyền, vấn đề cần được chuyển cho Principal IT Business Analyst để làm rõ và điều chỉnh quy trình quản trị.

Định danh, Nguồn gốc và Nghĩa vụ Kiểm soát

Template này là một artifact được kiểm soát trong corpus Nova Foods. Mọi định danh, tham chiếu và nghĩa vụ của nó phải tuân thủ các nguồn quản trị trung tâm để bảo đảm tính nhất quán và khả năng truy vết (traceability) trong toàn bộ vòng đời phân tích và phát triển. Việc tuân thủ này không phải là lựa chọn, mà là yêu cầu bắt buộc để duy trì tính toàn vẹn của curriculum.

Bảng 1: Định danh Canonical của Template

Bảng này xác định định danh duy nhất của template trong hệ thống quản trị của corpus. Mọi tham chiếu đến template này từ các artifact khác phải sử dụng đúng các giá trị này.

Trường Định danh	Giá trị Canonical	Nguồn Quản trị (Source of Truth)
Artifact ID	TMPL-CR-001	/01-curriculum/TEMPLATE_MANIFEST.md
Tên tệp	/03-templates/TMPL-CR-001_change-request.md	/01-curriculum/TEMPLATE_MANIFEST.md
Loại Artifact	Template (Tier 1-4)	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md

Bảng 2: Liên kết đến các Nguồn Quản trị Canonical

Mỗi Yêu cầu Thay đổi (Change Request - CR) được tạo từ template này phải lấy thông tin từ các nguồn canonical dưới đây. Việc tham chiếu trực tiếp đến các nguồn này bảo đảm rằng CR được xây dựng trên nền tảng thông tin đã được kiểm soát, thay vì các giả định riêng lẻ.

Loại Thông tin Tham chiếu	Nguồn Canonical Bắt buộc	Lý do Kiểm soát
Nguồn bên ngoài (Luật, Chuẩn)	/00-research/00_SOURCE_MAP.md	Bảo đảm mọi lý do thay đổi (ví dụ: tuân thủ Nghị định 123/2020/NĐ-CP) đều dựa trên nguồn đã được xác minh và ghi nhận trong corpus.
Chương handbook hướng dẫn	/01-curriculum/CHAPTER_MANIFEST.md	Cung cấp liên kết đến tài liệu học thuật giải thích cách điền và xử lý một CR, giúp learner hiểu ngữ cảnh và quy trình.
Định danh truy vết (ID)	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Bảo đảm mọi ID được tạo (ví dụ: CR-2026-001) hoặc tham chiếu (ví dụ: REQ-INV-045) là duy nhất, được đăng ký và có thể truy vết ngược.
Quy tắc nghiệp vụ (Business Rule)	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Mọi quy tắc nghiệp vụ bị ảnh hưởng bởi CR phải được tham chiếu bằng ID canonical của nó (ví dụ: BR-FIN-012), không được diễn giải lại.
Từ điển dữ liệu (Data Dictionary)	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Mọi thay đổi liên quan đến cấu trúc dữ liệu, trường dữ liệu phải tham chiếu đến định nghĩa trong từ điển dữ liệu chung để tránh xung đột.

Bảng 3: Nghĩa vụ Kiểm soát Thay đổi

Hệ thống quản trị áp dụng hai lớp kiểm soát: kiểm soát thay đổi đối với chính template này, và kiểm soát đối với từng CR được tạo ra từ nó.

Đối tượng Kiểm soát	Nghĩa vụ Bắt buộc
Bản thân Template này (TMPL-CR-001)	1. Mọi chỉnh sửa phải được ghi nhận trong mục "Lịch sử Thay đổi" của template. 2. Thay đổi phải tạo ra phiên bản mới (ví dụ: từ v0.9.0 lên v0.9.1). 3. Thay đổi có ảnh hưởng đến các artifact khác (ví dụ: thay đổi cấu trúc yêu cầu sửa đổi handbook) phải được báo cáo cho Owner của các artifact đó.
Một CR được tạo từ Template (ví dụ: CR-2026-001)	1. Phải được cấp một ID duy nhất từ TRACEABILITY_ID_REGISTRY.md. 2. Phải luôn có trạng thái rõ ràng (ví dụ: SUBMITTED, IN_REVIEW, APPROVED, REJECTED). 3. Mọi quyết định (phê duyệt, từ chối) phải được ghi lại với người ra quyết định, ngày và lý do. 4. Phải duy trì bằng chứng và liên kết truy vết đến yêu cầu gốc hoặc vấn đề đã gây ra nó.

2. Tier 2 — Blank Copy-Paste-Ready Template

Mục này là mẫu trống, sẵn sàng để sử dụng. Dùng để tạo một Yêu cầu Thay đổi (Change Request - CR) mới. Sao chép toàn bộ nội dung dưới đây và điền thông tin vào các trường có dấu ngoặc nhọn <...>.

Một CR là một tài liệu chính thức dùng để đề xuất một sự thay đổi cho hệ thống. Việc sử dụng CR đảm bảo mọi thay đổi đều được xem xét, phân tích ảnh hưởng, phê duyệt và theo dõi một cách có hệ thống, tránh các sửa đổi tùy tiện gây rủi ro cho dự án.

---

MẪU YÊU CẦU THAY ĐỔI (CHANGE REQUEST)

2.1. Thông tin chung

Bảng này chứa các siêu dữ liệu (metadata) cốt lõi để định danh và quản lý CR.

Trường	Hướng dẫn điền
ID Yêu cầu Thay đổi	<Điền ID duy nhất theo định dạng CR-YYYY-NNN. ID này phải được đăng ký và lấy từ /01-curriculum/TRACEABILITY_ID_REGISTRY.md.>
Tiêu đề	<Viết một tiêu đề ngắn gọn, súc tích nhưng mô tả rõ bản chất của thay đổi. Ví dụ: "Thêm trường Mã số thuế cho Đối tượng Nhà cung cấp">
Người gửi	<Ghi rõ Tên và Vai trò của người đưa ra yêu cầu thay đổi. Ví dụ: "Nguyễn Văn A, Kế toán trưởng">
Ngày gửi	<Ngày gửi yêu cầu chính thức, theo định dạng YYYY-MM-DD. Ví dụ: 2026-09-15>
Trạng thái	Chọn một trong các giá trị sau: SUBMITTED, IN_REVIEW, APPROVED, REJECTED, IMPLEMENTED, CLOSED. - SUBMITTED: Mới khởi tạo và gửi đi. - IN_REVIEW: Đang được các bên liên quan xem xét. - APPROVED: Đã được phê duyệt để triển khai. - REJECTED: Đã bị từ chối. - IMPLEMENTED: Đã được đội kỹ thuật phát triển và cài đặt xong. - CLOSED: Đã hoàn tất, nghiệm thu và đóng lại.
Mức độ ưu tiên	Chọn một trong các giá trị sau: CRITICAL, HIGH, MEDIUM, LOW. - CRITICAL: Bắt buộc phải làm ngay lập tức, vì nó đang chặn đứng hoạt động kinh doanh cốt lõi. - HIGH: Rất quan trọng, có ảnh hưởng lớn đến hiệu quả hoạt động hoặc doanh thu. - MEDIUM: Quan trọng, nên được thực hiện trong kỳ kế hoạch hiện tại. - LOW: "Nice-to-have", có thể trì hoãn nếu nguồn lực có hạn.
Module/Hệ thống bị ảnh hưởng	<Liệt kê các phân hệ (module) chính của hệ thống ERP Nova Foods hoặc các hệ thống khác bị ảnh hưởng. Ví dụ: "Quản lý Mua hàng (Purchasing), Kế toán Phải trả (Accounts Payable)">

2.2. Mô tả và Lý do Thay đổi

Phần này giải thích lý do "TẠI SAO" cần phải có sự thay đổi này.

Vấn đề hiện tại

<Mô tả chi tiết vấn đề, sự bất cập trong quy trình hiện tại, hoặc cơ hội kinh doanh đang bị bỏ lỡ. Dùng số liệu cụ thể để chứng minh nếu có. Trả lời câu hỏi: Nếu không thay đổi, hậu quả là gì?>

Đề xuất thay đổi

<Mô tả giải pháp đề xuất một cách cụ thể ở cấp độ nghiệp vụ. Thay đổi này sẽ làm gì? Thêm/sửa/xóa chức năng nào? Thay đổi logic tính toán nào? Mô tả đủ rõ để người đọc hiểu được sự khác biệt trước và sau khi thay đổi.

Lợi ích nghiệp vụ

<Liệt kê những lợi ích cụ thể mà thay đổi này mang lại. Cố gắng định lượng hóa các lợi ích. Ví dụ: "Giảm 2 giờ xử lý hóa đơn mỗi ngày cho 3 kế toán", "Loại bỏ 90% lỗi nhập liệu sai địa chỉ nhà cung cấp", "Đáp ứng Nghị định 123/2020/NĐ-CP về hóa đơn điện tử".>

2.3. Phân tích Ảnh hưởng

Đây là phần quan trọng nhất để đảm bảo thay đổi không gây ra tác dụng phụ không mong muốn.

Lĩnh vực ảnh hưởng	Mô tả chi tiết ảnh hưởng	ID tham chiếu (nếu có)
Quy trình Nghiệp vụ	<Quy trình kinh doanh nào sẽ thay đổi? Các bước nào bị thêm, bớt, hoặc sửa đổi? Ai là người cần được đào tạo lại về quy trình mới?>	<ID quy trình, ví dụ: BP-PUR-001>
Dữ liệu	<Trường dữ liệu nào được thêm mới, sửa đổi hoặc loại bỏ? Có cần chuyển đổi dữ liệu cũ (data migration) không? Tham chiếu ID từ /01-curriculum/CANONICAL_DATA_DICTIONARY.md.>	<ID trường dữ liệu, ví dụ: DD-VEND-015>
Giao diện Người dùng (UI/UX)	<Màn hình nào bị thay đổi? Có thêm nút, trường thông tin, hay thay đổi luồng thao tác không? Thay đổi có làm người dùng khó sử dụng hơn không?>	<ID mock-up hoặc wireframe>
Tích hợp Hệ thống	<Thay đổi này có ảnh hưởng đến các hệ thống khác đang kết nối với ERP không (ví dụ: website bán hàng, hệ thống CRM)? API nào bị ảnh hưởng?>	<ID đặc tả API>
Bảo mật	<Thay đổi có tạo ra lỗ hổng bảo mật nào không? Có ảnh hưởng đến quyền truy cập dữ liệu (phân quyền) không? Dữ liệu nhạy cảm nào bị tác động?>	<Tham chiếu OWASP nếu cần, ví dụ: ASVS V5.0>
Vận hành & Báo cáo	<Các báo cáo hiện tại có cần cập nhật theo logic mới không? Hoạt động vận hành hàng ngày (sao lưu, đối soát cuối ngày) có bị ảnh hưởng không?>	<ID của báo cáo bị ảnh hưởng>

2.4. Bằng chứng và Truy vết (Evidence and Traceability)

Truy vết nguồn gốc (Traceability) giúp liên kết CR này tới các yêu cầu, lỗi, hoặc tài liệu gốc.

Loại liên kết	ID Tham chiếu	Mô tả ngắn
Relates to Requirement	<ID của yêu cầu, ví dụ: REQ-INV-045>	<Yêu cầu nghiệp vụ hoặc hệ thống gốc mà CR này được tạo ra để đáp ứng.>
Fixes Bug	<ID của lỗi trên hệ thống tracking, ví dụ: BUG-FIN-102>	<Lỗi cụ thể mà CR này được tạo ra để sửa chữa.>
Source Document	<ID tài liệu, ví dụ: LAW-VAT-2026>	<Tài liệu gốc (hợp đồng, công văn pháp lý) làm phát sinh nhu cầu thay đổi.>
Depends on	<ID của một CR hoặc Task khác, ví dụ: CR-2026-008>	<CR này chỉ có thể được bắt đầu sau khi một CR/Task khác hoàn thành.>

2.5. Phê duyệt (Sign-off)

Mọi CR phải được các bên có thẩm quyền xem xét và phê duyệt trước khi triển khai.

Vai trò	Người phê duyệt	Quyết định	Ngày	Ghi chú / Lý do
Business Owner <Tên phòng ban nghiệp vụ sở hữu chức năng>	<Để trống, người có thẩm quyền sẽ điền tên>	<APPROVED / REJECTED / INFO_REQUEST>	<YYYY-MM-DD>	<Ghi rõ lý do phê duyệt/từ chối, hoặc thông tin cần yêu cầu bổ sung.>
Technical Architect	<Để trống, người có thẩm quyền sẽ điền tên>	<APPROVED / REJECTED / INFO_REQUEST>	<YYYY-MM-DD>	<Ghi rõ các vấn đề về kỹ thuật, kiến trúc, tính bền vững của giải pháp.>
QA Lead	<Để trống, người có thẩm quyền sẽ điền tên>	<APPROVED / REJECTED / INFO_REQUEST>	<YYYY-MM-DD>	<Ghi rõ các vấn đề về khả năng kiểm thử (testability) của yêu cầu.>
Security Officer (Nếu có ảnh hưởng bảo mật)	<Để trống, người có thẩm quyền sẽ điền tên>	<APPROVED / REJECTED / INFO_REQUEST>	<YYYY-MM-DD>	<Ghi rõ các rủi ro bảo mật và yêu cầu tuân thủ nếu có.>

Các Bảng Biểu và Trường Thông Tin Quản Trị

Các bảng dưới đây là cấu trúc bắt buộc để quản trị, truy vết, và phê duyệt một Yêu cầu Thay đổi (Change Request - CR). Người lập CR phải điền đầy đủ thông tin vào các trường có sẵn để đảm bảo tính minh bạch và khả năng kiểm soát trong suốt vòng đời của thay đổi.

Lịch sử Phiên bản (Version History) Bảng này ghi lại tất cả các thay đổi đối với tài liệu Yêu cầu Thay đổi này.

Phiên bản	Ngày cập nhật	Người thực hiện	Tóm tắt thay đổi
<1.0>	<YYYY-MM-DD>	<Tên và vai trò người khởi tạo>	<Khởi tạo Yêu cầu Thay đổi.>
<Phiên bản tiếp theo>	<YYYY-MM-DD>	<Tên và vai trò người cập nhật>	<Mô tả ngắn gọn về nội dung đã cập nhật.>

Nhật ký Quyết định (Decision Log) Ghi lại các quyết định quan trọng được đưa ra trong quá trình phân tích và thực hiện CR, giúp làm rõ lý do đằng sau các lựa chọn.

ID Quyết định	Ngày	Nội dung Quyết định	Lý do (Rationale)	Người quyết định
<CR-DEC-001>	<YYYY-MM-DD>	<Mô tả quyết định, ví dụ: 'Chấp nhận sử dụng API của bên thứ ba cho việc thanh toán.'>	<Lý do ngắn gọn, ví dụ: 'Tiết kiệm thời gian phát triển và tận dụng giải pháp đã được chứng thực.'>	<Chức danh và Tên, ví dụ: 'Giám đốc Sản phẩm - Nguyễn Văn A'>
<CR-DEC-002>	<YYYY-MM-DD>	<Mô tả quyết định tiếp theo.>	<Giải thích tại sao quyết định này được đưa ra.>	<Chức danh và Tên của người có thẩm quyền.>

Nhật ký Ngoại lệ (Exceptions Log) Ghi lại bất kỳ sự đi chệch nào so với quy trình chuẩn, yêu cầu đã được thống nhất, hoặc kiến trúc hệ thống.

ID Ngoại lệ	Mô tả Ngoại lệ	Ảnh hưởng	Phương án Giảm thiểu (Mitigation)	Trạng thái Phê duyệt
<CR-EXC-001>	<Mô tả ngoại lệ, ví dụ: 'Bỏ qua bước xác thực hai yếu tố cho vai trò quản trị viên kho khi truy cập từ mạng nội bộ.'>	<Rủi ro bảo mật tiềm ẩn nếu có truy cập trái phép vào mạng nội bộ.>	<Giám sát chặt chẽ mọi hoạt động của vai trò này và giới hạn quyền truy cập theo địa chỉ IP tĩnh.	<Chờ phê duyệt / Đã phê duyệt / Từ chối>
<CR-EXC-002>	<Mô tả ngoại lệ tiếp theo.>	<Mô tả các tác động tiêu cực có thể xảy ra.>	<Mô tả hành động để hạn chế hoặc loại bỏ rủi ro.	<Chờ phê duyệt / Đã phê duyệt / Từ chối>

Bằng chứng và Ma trận Truy vết (Evidence and Traceability Matrix) Phần này đảm bảo khả năng Truy vết (Traceability) — liên kết hai chiều từ yêu cầu nghiệp vụ gốc đến các thay đổi và các ca kiểm thử tương ứng.

• Bảng Bằng chứng (Evidence Log): Liệt kê tất cả tài liệu, email, biên bản họp hoặc mô hình làm cơ sở cho CR.

ID Bằng chứng	Tên/Đường dẫn Artifact	Mô tả
<EV-CR-001>	<Định danh tài liệu, ví dụ: 'BR-045 - Yêu cầu báo cáo tồn kho theo lô sản xuất'>	Yêu cầu nghiệp vụ gốc được phê duyệt bởi Business Owner.
<EV-CR-002>	<Đường dẫn tới email hoặc biên bản họp>	Biên bản họp ngày <YYYY-MM-DD> thống nhất về phạm vi thay đổi.

• Ma trận Truy vết (Traceability Matrix):

ID Mục trong CR	Liên kết tới Yêu cầu Nghiệp vụ (BR-ID)	Liên kết tới Quy tắc Nghiệp vụ (RULE-ID)	Liên kết tới Yêu cầu Hệ thống (SR-ID)	Liên kết tới Ca kiểm thử (TC-ID)
<CR-ITEM-001>	<BR-XXX, BR-YYY>	<RULE-INV-005>	<SR-AAA, SR-BBB>	<TC-123, TC-124>
<CR-ITEM-002>	<BR-ZZZ>	<RULE-ORD-011>	<SR-CCC>	<TC-125>

Xem xét và Ký duyệt (Review and Sign-off) Đây là khu vực ghi nhận sự phê duyệt chính thức (gọi là Sign-off) từ các bên liên quan có thẩm quyền trước khi thay đổi được đưa vào triển khai.

Vai trò	Tên người duyệt	Chữ ký (hoặc xác nhận điện tử)	Ngày	Trạng thái
Business Owner	<Tên Business Owner>	<Ký tên hoặc ghi 'Đã duyệt qua email/Jira'>	<YYYY-MM-DD>	<Chờ duyệt / Đã duyệt / Từ chối / Yêu cầu làm rõ>
Project Manager	<Tên Project Manager>	<Ký tên hoặc ghi 'Đã duyệt qua email/Jira'>	<YYYY-MM-DD>	<Chờ duyệt / Đã duyệt / Từ chối / Yêu cầu làm rõ>
Technical Architect / Lead	<Tên Technical Architect>	<Ký tên hoặc ghi 'Đã duyệt qua email/Jira'>	<YYYY-MM-DD>	<Chờ duyệt / Đã duyệt / Từ chối / Yêu cầu làm rõ>
QA Lead	<Tên QA Lead>	<Ký tên hoặc ghi 'Đã duyệt qua email/Jira'>	<YYYY-MM-DD>	<Chờ duyệt / Đã duyệt / Từ chối / Yêu cầu làm rõ>
Legal/Compliance (nếu có)	<Tên người phụ trách>	<Ký tên hoặc ghi 'Đã duyệt qua email/Jira'>	<YYYY-MM-DD>	<Chờ duyệt / Đã duyệt / Từ chối / Không áp dụng>

Hướng dẫn điền biểu mẫu, giá trị hợp lệ và quy tắc xác thực

Phần này cung cấp hướng dẫn chi tiết cho từng trường trong biểu mẫu yêu cầu thay đổi (Change Request), bao gồm các giá trị được phép, định dạng bắt buộc, và các quy tắc để đảm bảo tính nhất quán và rõ ràng.

Bảng 1: Hướng dẫn cho các trường thông tin chung

Tên trường	Hướng dẫn và quy tắc xác thực
Mã yêu cầu	Định dạng bắt buộc: CR-NNN. CR là tiền tố cho Change Request. NNN là một số thứ tự duy nhất được cấp từ TRACEABILITY_ID_REGISTRY.md. Mã này không được trùng lặp.
Tên yêu cầu	Tên ngắn gọn, súc tích, tóm tắt bản chất của thay đổi. Ví dụ: "Thêm trường 'Lý do hủy' cho đơn hàng".
Mức độ ưu tiên	Chọn một trong các giá trị sau. Mỗi giá trị có tiêu chí rõ ràng để tránh lạm dụng. - Critical (Cực kỳ khẩn cấp): Hệ thống ngừng hoạt động, mất dữ liệu, lỗ hổng bảo mật nghiêm trọng, không thể thực hiện giao dịch cốt lõi. - High (Cao): Ảnh hưởng lớn đến doanh thu hoặc hoạt động, không có cách giải quyết tạm thời (workaround) hiệu quả. - Medium (Trung bình): Cần thiết cho nghiệp vụ nhưng có thể trì hoãn ngắn hạn; có workaround. - Low (Thấp): Cải tiến nhỏ, "nice-to-have", không ảnh hưởng trực tiếp đến hoạt động hàng ngày.
Loại yêu cầu	Chọn một trong các giá trị sau: - Bug Fix (Sửa lỗi): Sửa một hành vi sai của hệ thống so với yêu cầu đã định nghĩa. - New Feature (Chức năng mới): Thêm một khả năng hoàn toàn mới vào hệ thống. - Enhancement (Cải tiến): Nâng cấp một chức năng hiện có. - Data Change (Thay đổi dữ liệu): Yêu cầu sửa đổi dữ liệu trực tiếp trong cơ sở dữ liệu. Cần quy trình phê duyệt nghiêm ngặt. - Compliance (Tuân thủ): Thay đổi để đáp ứng yêu cầu pháp lý, quy định hoặc tiêu chuẩn mới. Ví dụ: thay đổi theo Nghị định 123/2020/NĐ-CP.
Hệ thống/Module ảnh hưởng	Ghi rõ tên hệ thống và module bị tác động. Ví dụ: ERP - Kho (Inventory), ERP - Kế toán (Accounting), CRM - Quản lý khách hàng.

Tiêu chí chấp nhận (Acceptance Criteria - AC)

Đây là các điều kiện mà phần mềm phải thỏa mãn để yêu cầu thay đổi được coi là hoàn thành. AC phải cụ thể, có thể kiểm chứng được, không mơ hồ.

• Quy tắc: Mỗi AC phải là một kịch bản kiểm thử được.
• Cấu trúc đề xuất: Sử dụng cấu trúc GIVEN-WHEN-THEN để mô tả hành vi.
  • GIVEN (Bối cảnh): Điều kiện ban đầu. Ví dụ: "GIVEN người dùng đã đăng nhập với vai trò kế toán và đang ở màn hình tạo hóa đơn".
  • WHEN (Hành động): Hành động của người dùng. Ví dụ: "WHEN người dùng để trống trường 'Mã số thuế'".
  • THEN (Kết quả): Kết quả mong đợi từ hệ thống. Ví dụ: "THEN hệ thống hiển thị thông báo lỗi 'Mã số thuế không được để trống'".

Bảng 2: Hướng dẫn cho bảng Truy vết (Traceability)

Mã định danh	Hướng dẫn định dạng và nguồn gốc
REQ-ID	Mã yêu cầu nghiệp vụ cấp cao (Business Requirement). Định dạng REQ-NNN. Tham chiếu đến tài liệu đặc tả yêu cầu gốc.
BR-ID	Mã quy tắc nghiệp vụ (Business Rule) bị ảnh hưởng. Định dạng BR-NNN. Tham chiếu đến CANONICAL_BUSINESS_RULES.md.
RULE-ID	Mã quy tắc cụ thể nếu áp dụng. Định dạng RULE-<PREFIX>-NNN. Tham chiếu đến CANONICAL_BUSINESS_RULES.md.
SR-ID	Mã yêu cầu hệ thống (System Requirement) hoặc yêu cầu phi chức năng (Non-Functional Requirement) liên quan. Định dạng SR-NNN hoặc NFR-NNN.
TC-ID	Mã kịch bản kiểm thử (Test Case) sẽ được dùng để xác minh thay đổi này. Định dạng TC-NNN.

Tham chiếu thông tin nhạy cảm (Safe Secret Reference)

Tuyệt đối không đưa mật khẩu, khóa API (API key), hoặc bất kỳ thông tin nhạy cảm nào vào tài liệu này dưới dạng văn bản thuần túy. Sử dụng mẫu tham chiếu an toàn sau đây. Đội ngũ kỹ thuật sẽ sử dụng mẫu này để lấy giá trị thực từ một hệ thống quản lý bí mật tập trung (ví dụ: HashiCorp Vault, Azure Key Vault).

• Định dạng: {{VAULT:<path/to/secret>:<key>}}
• Ví dụ: Thay vì viết api_key = "abc123xyz", hãy viết api_key = {{VAULT:nova-foods/erp/payment-gateway:api_key}}.

Các phần có điều kiện (Conditional Sections)

Mục ký duyệt Legal/Compliance chỉ bắt buộc khi Loại yêu cầu là Compliance hoặc khi thay đổi có tác động đến các vấn đề pháp lý, bảo mật dữ liệu cá nhân (theo Luật 91/2025/QH15), hoặc các quy định tài chính (theo Luật Kế toán 88/2015/QH13). Trong các trường hợp khác, có thể ghi là Không áp dụng.

3. Tier 3 — Fully Completed Nova Foods Case: Core Record

Đây là một ví dụ hoàn chỉnh về tài liệu Yêu cầu Thay đổi (Change Request - CR) cho case study mô phỏng của Nova Foods. Mọi dữ liệu, ID, vai trò và sự kiện đều là giả định cho mục đích học tập.

---

TIÊU ĐỀ: YÊU CẦU THAY ĐỔI HỆ THỐNG ERP NOVA FOODS

Trường siêu dữ liệu (Metadata Field)	Giá trị
CR-ID (Mã CR)	CR-2026-042
Tiêu đề	Bổ sung Hạn sử dụng lô (Lot Expiry Date) cho Module Quản lý Kho
Người yêu cầu	Trần Thị Bích
Chức vụ người yêu cầu	Trưởng phòng Quản lý Kho
Ngày yêu cầu	2026-08-07
Độ ưu tiên	High
Trạng thái	In Review
Loại yêu cầu	Enhancement (Nâng cấp)

1. Bối cảnh và Mô tả (Context and Description)

• Hiện trạng: Hệ thống ERP hiện tại chỉ lưu trữ ngày nhập lô (Lot Import Date) cho mỗi lô hàng trong kho. Quy trình xuất kho đang tuân thủ nghiêm ngặt logic FIFO (First-In, First-Out – Nhập trước, Xuất trước).
• Vấn đề: Logic FIFO không đủ. Nhiều sản phẩm có hạn sử dụng (HSD) khác nhau bất kể ngày nhập. Ví dụ, một lô nhập sau có thể có HSD ngắn hơn lô nhập trước. Việc này dẫn đến rủi ro hàng cận date không được xuất đi trước, gây lãng phí do phải hủy bỏ, làm tăng chi phí và giảm lợi nhuận. Vấn đề này cũng có nguy cơ vi phạm các quy định về an toàn thực phẩm.
• Đề xuất thay đổi:
  1. Mô hình dữ liệu: Thêm trường dữ liệu lot_expiry_date (kiểu date) vào bảng inventory_lots trong cơ sở dữ liệu (database) của ERP.
  2. Giao diện người dùng (UI): Cập nhật màn hình "Nhận hàng" (Goods Receipt) trong Module Kho, bắt buộc người dùng phải nhập Hạn sử dụng lô khi nhận lô hàng mới.
  3. Logic nghiệp vụ: Sửa đổi thuật toán gợi ý xuất kho. Thay vì chỉ dựa vào ngày nhập lô (FIFO), thuật toán phải ưu tiên các lô có Hạn sử dụng lô gần nhất. Quy tắc này được gọi là FEFO (First-Expired, First-Out – Hết hạn trước, Xuất trước).

2. Lý do và Lợi ích (Justification and Benefits)

• Lý do:
  • Nghiệp vụ: Chuyển đổi từ FIFO sang FEFO là yêu cầu cấp thiết để tối ưu hóa quản lý hàng tồn kho cho ngành thực phẩm.
  • Tài chính: Giảm tỷ lệ hàng hóa hết hạn phải hủy bỏ, trực tiếp giảm chi phí thất thoát.
  • Tuân thủ: Đảm bảo tuân thủ tốt hơn các yêu cầu về truy xuất nguồn gốc và an toàn thực phẩm, gián tiếp liên quan đến Luật An toàn thực phẩm 55/2010/QH12.
• Lợi ích định lượng (ước tính):
  • Giảm 70% giá trị hàng hóa phải hủy do hết hạn trong vòng 12 tháng. Ước tính tiết kiệm: 3,500,000,000 VND/năm.
  • Tăng vòng quay hàng tồn kho cho các mặt hàng nhạy cảm với HSD lên 15%.
• Lợi ích định tính:
  • Nâng cao uy tín thương hiệu về chất lượng và độ tươi mới của sản phẩm.
  • Cải thiện tinh thần làm việc của nhân viên kho khi quy trình rõ ràng và hiệu quả hơn.

3. Phân tích Tác động (Impact Analysis)

Hạng mục	Mô tả tác động	Mức độ
Hệ thống	1. Sửa đổi DB schema (inventory_lots). 2. Cập nhật API endpoint /api/v1/warehouse/receipts. 3. Viết lại logic của microservice picking-suggestion-service. 4. Cập nhật báo cáo Stock Aging Report.	High
Quy trình nghiệp vụ	1. Nhập kho: Phải thêm bước nhập Hạn sử dụng. 2. Xuất kho: Nhân viên phải tuân theo gợi ý FEFO từ hệ thống. 3. Kiểm kê: Quy trình kiểm kê phải xác minh cả HSD thực tế.	Medium
Dữ liệu	Cần một kịch bản di trú dữ liệu (data migration script) một lần để cập nhật trường lot_expiry_date cho ~150,000 bản ghi lô hàng đang tồn tại. Giá trị sẽ được tính: lot_expiry_date = lot_import_date + product.shelf_life_days.	High
Chi phí	Ước tính 250 giờ công phát triển và 80 giờ công kiểm thử. Tổng chi phí dự kiến: 412,500,000 VND.	Medium
Rủi ro	1. Di trú dữ liệu sai có thể gây gián đoạn hoạt động. 2. Nhân viên không tuân thủ quy trình nhập HSD mới. 3. Thuật toán FEFO tính toán sai có thể gây ra lỗi xuất hàng.	Medium

4. Ma trận Truy vết Yêu cầu (Requirements Traceability Matrix)

ID Nguồn	Mô tả và Nguồn gốc
REQ-088	Yêu cầu nghiệp vụ: "Hệ thống phải hỗ trợ quản lý tồn kho theo nguyên tắc FEFO." Nguồn: Biên bản họp với Ban Giám đốc chuỗi cung ứng, ngày 2026-07-20.
BR-INV-004	Quy tắc nghiệp vụ: "Gợi ý xuất kho phải ưu tiên lô hàng có hạn sử dụng gần nhất." Nguồn: /01-curriculum/CANONICAL_BUSINESS_RULES.md.
SR-159	Yêu cầu hệ thống: "Hệ thống phải lưu trữ được Hạn sử dụng cho mỗi lô hàng."
SR-160	Yêu cầu hệ thống: "Giao diện nhận hàng phải có trường nhập Hạn sử dụng và đây là trường bắt buộc."
TC-431	Kịch bản kiểm thử: "Xác minh thuật toán gợi ý xuất kho chọn đúng lô có HSD gần nhất khi có nhiều lô cùng một sản phẩm."
TC-432	Kịch bản kiểm thử: "Xác minh kịch bản di trú dữ liệu tính toán chính xác HSD cho các lô hàng hiện có."

5. Tiêu chí Chấp nhận (Acceptance Criteria)

1. Khi một lô hàng mới được nhập, người dùng phải nhập một ngày hợp lệ (không phải quá khứ) vào trường "Hạn sử dụng lô". Hệ thống không cho phép lưu nếu trường này bị bỏ trống.
2. Trên màn hình gợi ý xuất kho, đối với một mã sản phẩm (SKU) cụ thể, hệ thống phải luôn đề xuất lô có lot_expiry_date sớm nhất.
3. Sau khi kịch bản di trú dữ liệu chạy, kiểm tra ngẫu nhiên 100 lô hàng hiện có, HSD phải được tính bằng ngày nhập lô + số ngày HSD tiêu chuẩn của sản phẩm đó.
4. Báo cáo "Tồn kho theo tuổi" (Stock Aging Report) phải hiển thị cột "Ngày hết hạn" và có thể sắp xếp theo cột đó.

6. Người duyệt (Approvers)

Chức vụ	Họ và tên	Chữ ký/Xác nhận	Ngày	Ghi chú
Business Owner (Chủ sở hữu nghiệp vụ)	Nguyễn Văn Hùng (Giám đốc Chuỗi cung ứng)	Pending Review
IT Lead (Trưởng nhóm Kỹ thuật)	Lê Minh Tuấn (Lead Engineer, ERP)	Pending Review		Yêu cầu đánh giá kỹ thuật chi tiết về tác động DB.
QA Lead (Trưởng nhóm Kiểm thử)	Mai Anh Thư (QA Manager)	Pending Review
Legal/Compliance	Không áp dụng			Thay đổi không trực tiếp tạo ra nghĩa vụ pháp lý mới, chỉ cải thiện tuân thủ hiện có.

3.1. Ví dụ Hoàn chỉnh: Yêu cầu Thay đổi CR-2026-042

Phần này cung cấp một ví dụ hoàn chỉnh về một Yêu cầu Thay đổi (Change Request - CR) trong bối cảnh mô phỏng của Nova Foods. Mọi dữ liệu, nhân vật, và quy trình đều là giả định cho mục đích đào tạo.

TIÊU ĐỀ: Nâng ngưỡng phê duyệt tự động cho Đơn Mua Hàng (PO) từ Nhà Cung Cấp (NCC) chiến lược

Trường Dữ liệu	Giá trị	Nguồn/Ghi chú
ID Yêu cầu Thay đổi (CR ID)	CR-2026-042	ID được cấp phát bởi hệ thống Jira, theo định dạng CR-YYYY-NNN.
Ngày yêu cầu	2026-08-05	Ngày Trưởng phòng Mua hàng chính thức gửi yêu cầu.
Người yêu cầu	Lê Thị Minh Hằng	EMP-0118, Trưởng phòng Mua hàng (Procurement Manager).
Business Owner	Nguyễn Văn Dũng	EMP-0042, Giám đốc Cung ứng (Head of Procurement).
Hệ thống/Module bị ảnh hưởng	ERP NovaFoods / Phân hệ Mua hàng (Procurement Module)	SYS-ERP, MOD-PROCURE.
Mức độ ưu tiên của nghiệp vụ	High	Tác động trực tiếp đến hiệu suất chuỗi cung ứng và có thể gây gián đoạn sản xuất.
Ngày mục tiêu hoàn thành	2026-10-01	Để kịp áp dụng cho chu kỳ mua sắm cao điểm Quý 4.
Loại thay đổi	Standard Change (Thay đổi tiêu chuẩn)	Quy trình đã được định nghĩa trước, rủi ro thấp, tác động có thể dự đoán được.
Tham chiếu Yêu cầu Nghiệp vụ	BRD-PROC-2026-007	Tham chiếu đến Tài liệu Yêu cầu Nghiệp vụ (Business Requirements Document) chi tiết.

---

3.1.1. Bối cảnh và Hiện trạng

Hiện trạng (As-Is): Tất cả các Đơn Mua Hàng (Purchase Order - PO) có tổng giá trị trên 50,000,000 VND đều yêu cầu phê duyệt thủ công từ Giám đốc Cung ứng (EMP-0042) trong hệ thống ERP. Quy tắc này được định nghĩa là BR-PO-APPROVAL-001. Quy trình này không phân biệt nhà cung cấp (NCC), dù đó là NCC mới hay NCC chiến lược đã được thẩm định và có hợp đồng dài hạn.

Vấn đề: Giám đốc Cung ứng đang trở thành điểm nghẽn (bottleneck) trong quy trình. Các PO cho vật tư sản xuất định kỳ từ các NCC tin cậy (ví dụ: SUPP-003 - Bao bì Toàn Cầu, SUPP-015 - Hương liệu Việt) thường xuyên bị chậm trễ từ 1-2 ngày làm việc chỉ để chờ phê duyệt. Việc này gây rủi ro thiếu hụt vật tư cho dây chuyền sản xuất, ảnh hưởng đến kế hoạch sản xuất tổng thể (REF: PROD-PLAN-2026-Q3).

3.1.2. Mô tả Thay đổi Yêu cầu (To-Be)

Mô tả chi tiết: Cập nhật logic phê duyệt PO trong phân hệ Mua hàng của ERP để áp dụng một bộ quy tắc có điều kiện. Thay đổi này sẽ phân biệt giữa các NCC thông thường và các NCC chiến lược đã được xác định trước.

Quy tắc nghiệp vụ mới (Proposed Business Rules):

ID Quy tắc mới	Tên Quy tắc	Điều kiện Kích hoạt	Hành động
BR-PO-APPROVAL-004	Phê duyệt tự động cho PO từ NCC chiến lược dưới ngưỡng mới	1. PO thuộc về một NCC trong danh sách Strategic Supplier List. 2. Tổng giá trị PO nhỏ hơn hoặc bằng 200,000,000 VND.	Hệ thống tự động phê duyệt PO. Trạng thái PO chuyển từ Pending Approval sang Approved.
BR-PO-APPROVAL-001 (Cập nhật)	Phê duyệt thủ công cho PO thông thường/vượt ngưỡng	1. PO thuộc về một NCC không nằm trong Strategic Supplier List VÀ có giá trị trên 50,000,000 VND. HOẶC 2. PO thuộc về NCC chiến lược nhưng giá trị trên 200,000,000 VND.	Yêu cầu phê duyệt thủ công từ Giám đốc Cung ứng (EMP-0042).

Danh sách Strategic Supplier List phải là một danh sách có thể cấu hình trong ERP, do Phòng Mua hàng quản lý.

3.1.3. Lý do và Lợi ích Nghiệp vụ

Lý do (Justification): - Giảm tải cho quản lý cấp cao: Cho phép Giám đốc Cung ứng tập trung vào các giao dịch mua sắm có giá trị cao, đàm phán hợp đồng chiến lược và quản lý rủi ro NCC, thay vì xử lý các PO lặp lại, có rủi ro thấp. - Tăng tốc độ chuỗi cung ứng: Giảm thời gian chờ xử lý PO từ 1-2 ngày xuống còn vài phút, đảm bảo vật tư được đặt hàng kịp thời, giảm thiểu nguy cơ gián đoạn sản xuất. - Tối ưu hóa quy trình: Tự động hóa một bước thủ công không còn mang lại nhiều giá trị kiểm soát đối với các đối tác đã được tin cậy.

Lợi ích có thể đo lường được (Measurable Benefits): - Giảm thời gian phê duyệt trung bình cho các PO đủ điều kiện từ ~30 giờ xuống dưới 1 giờ. - Giảm số lượng PO cần phê duyệt thủ công hàng tuần khoảng 40% (dựa trên phân tích dữ liệu PO 6 tháng gần nhất). - Loại bỏ các sự cố chậm trễ sản xuất do chờ phê duyệt PO vật tư từ NCC chiến lược (dự kiến).

3.1.4. Tiêu chí Chấp thuận (Acceptance Criteria)

Các tiêu chí sau đây, được viết theo cú pháp Gherkin, định nghĩa điều kiện để thay đổi này được coi là hoàn thành.

ID Tiêu chí	Mô tả Tiêu chí Chấp thuận (Acceptance Criterion)
AC-CR2026042-01	Given một PO được tạo với giá trị 150,000,000 VND từ NCC trong danh sách Strategic Supplier List, When PO được lưu, Then trạng thái của PO phải tự động chuyển thành Approved.
AC-CR2026042-02	Given một PO được tạo với giá trị 250,000,000 VND từ NCC trong danh sách Strategic Supplier List, When PO được lưu, Then trạng thái của PO phải là Pending Approval và một yêu cầu phê duyệt được gửi đến Giám đốc Cung ứng.
AC-CR2026042-03	Given một PO được tạo với giá trị 60,000,000 VND từ một NCC không có trong danh sách Strategic Supplier List, When PO được lưu, Then trạng thái của PO phải là Pending Approval và một yêu cầu phê duyệt được gửi đến Giám đốc Cung ứng.
AC-CR2026042-04	Given một PO được tạo với giá trị 45,000,000 VND từ một NCC không có trong danh sách Strategic Supplier List, When PO được lưu, Then trạng thái của PO phải tự động chuyển thành Approved.
AC-CR2026042-05	Given người dùng có quyền Quản lý Mua hàng truy cập màn hình quản lý NCC, When họ tìm một NCC, Then họ phải thấy một tùy chọn (ví dụ: checkbox "NCC Chiến lược") để thêm/xóa NCC đó khỏi danh sách Strategic Supplier List.

3.4. Phân tích Chi tiết và Đề xuất

Phần này phân tích hiện trạng, nhu cầu, các phương án khả thi, và đưa ra đề xuất thay đổi dựa trên tiêu chí đã xác định. Đây là hoạt động cốt lõi của BA, chuyển hóa vấn đề thành giải pháp có thể triển khai.

3.4.1. Bối cảnh và Hiện trạng (As-Is State)

Hiện trạng (As-Is) là cách hệ thống và quy trình hoạt động trước khi có thay đổi.

• Hệ thống: ERPNext v15, module Bán hàng (Selling).
• Quy trình: Quy trình tạo Khách hàng mới (New Customer).
• Quy tắc nghiệp vụ liên quan: BR-SALE-015: Default Credit Limit for New Customers.
• Mô tả hiện trạng:
  1. Nhân viên kinh doanh (Sales) tạo một khách hàng mới thuộc nhóm "Khách hàng Sỉ" (Customer Group = 'Wholesale').
  2. Hệ thống ERP tự động áp dụng quy tắc BR-SALE-015, thiết lập Hạn mức tín dụng (Credit Limit) của khách hàng này là 0 VND. Hạn mức tín dụng là số tiền tối đa mà khách hàng được phép nợ Nova Foods.
  3. Để khách hàng có thể đặt đơn hàng đầu tiên theo công nợ, nhân viên Sales phải gửi yêu cầu qua email đến Phòng Kế toán.
  4. Kế toán viên tiếp nhận, kiểm tra thủ công thông tin khách hàng (đăng ký kinh doanh, lịch sử), sau đó trình Trưởng phòng Kế toán phê duyệt.
  5. Sau khi được duyệt, Kế toán viên cập nhật hạn mức tín dụng mới cho khách hàng trong hệ thống ERP.
• Vấn đề: Quy trình này chậm, mất từ 2-3 ngày làm việc, làm trì hoãn đơn hàng đầu tiên và tạo ra workload thủ công lớn cho cả đội Sales và Kế toán. Điều này làm giảm khả năng cạnh tranh và gây ấn tượng không tốt với khách hàng mới.

3.4.2. Nhu cầu Nghiệp vụ Cơ bản (Underlying Business Need)

• Mục tiêu: Tự động hóa việc cấp một hạn mức tín dụng tạm thời và có kiểm soát cho các khách hàng sỉ mới, đáng tin cậy để đẩy nhanh quá trình bán hàng.
• Yêu cầu từ các bên liên quan:
  • Trưởng phòng Kinh doanh (An Nguyễn): Cần giảm thời gian từ lúc tạo khách hàng mới đến lúc có thể chốt đơn hàng đầu tiên xuống dưới 1 giờ làm việc.
  • Trưởng phòng Kế toán (Lê Thị Bích): Phải đảm bảo rủi ro công nợ được kiểm soát. Mọi hạn mức tự động phải dựa trên tiêu chí rõ ràng và chỉ áp dụng cho số tiền nhỏ ban đầu.
  • Quản lý ERP (Trần Văn Hùng): Giải pháp phải có tính khả thi kỹ thuật trong ERPNext, không yêu cầu tùy chỉnh (customization) quá phức tạp và phải có log ghi lại việc cấp hạn mức tự động.

3.4.3. Phân tích các Phương án (Options Analysis)

ID	Phương án	Ưu điểm	Nhược điểm
PA-1	Giữ nguyên hiện trạng	Không tốn chi phí phát triển. Rủi ro công nợ bằng không.	Không giải quyết được vấn đề gốc rễ: quy trình chậm, mất cơ hội kinh doanh, workload thủ công cao.
PA-2	Cấp hạn mức cố định	Rất đơn giản để triển khai (chỉ cần thay đổi giá trị mặc định). Tốc độ bán hàng rất nhanh.	Rủi ro tài chính cao. Cấp hạn mức 50,000,000 VND cho mọi khách hàng mới không phân biệt sẽ dễ dẫn đến nợ xấu. Phòng Kế toán không chấp nhận.
PA-3	Cấp hạn mức tự động theo điều kiện	Cân bằng giữa tốc độ và rủi ro. Tự động hóa các trường hợp phổ biến, giảm tải thủ công. Rủi ro được kiểm soát trong giới hạn chấp nhận được.	Phức tạp hơn trong triển khai (cần thêm logic và có thể cần thêm trường dữ liệu BRC Verified). Yêu cầu nhân viên Sales thực hiện thêm một bước xác minh.

Chi tiết Phương án 3 (Đề xuất): Một quy tắc nghiệp vụ mới, BR-SALE-021, sẽ được tạo: * NẾU một Customer mới thuộc Customer Group = 'Wholesale' * VÀ có cung cấp bản sao Giấy chứng nhận Đăng ký Kinh doanh (Business Registration Certificate - BRC) * VÀ ngày thành lập trên BRC > 2 năm so với ngày hiện tại * THÌ hệ thống tự động gán Credit Limit = 25,000,000 VND và ghi log "Provisional credit limit applied by BR-SALE-021". * NGƯỢC LẠI, Credit Limit vẫn là 0 VND và quy trình thủ công được áp dụng.

3.4.4. Tiêu chí Quyết định (Decision Criteria)

Một ma trận quyết định được sử dụng để đánh giá các phương án một cách khách quan.

Tiêu chí	Trọng số	PA-1: Giữ nguyên	PA-2: Cố định	PA-3: Theo điều kiện
Tốc độ Onboarding Khách hàng	40%	1 (Rất chậm)	5 (Rất nhanh)	4 (Nhanh)
Kiểm soát Rủi ro Tài chính	35%	5 (Tối đa)	1 (Rất rủi ro)	4 (Tốt)
Chi phí/Nỗ lực Triển khai	15%	5 (Không tốn)	4 (Rất thấp)	2 (Trung bình)
Giảm Workload Thủ công	10%	1 (Không giảm)	5 (Tối đa)	4 (Giảm đáng kể)
Tổng điểm có trọng số	100%	3.05	3.25	3.90

Ghi chú: Điểm từ 1 (tệ nhất) đến 5 (tốt nhất).

3.4.5. Đề xuất và Thẩm quyền Quyết định (Recommendation and Authority)

• Đề xuất: Lựa chọn Phương án 3 (PA-3). Phương án này đạt điểm cao nhất trong ma trận quyết định, đáp ứng tốt nhất các yêu cầu mâu thuẫn giữa Kinh doanh và Kế toán.
• Thẩm quyền quyết định (Decision Authority):
  • Business Owner (Chủ sở hữu nghiệp vụ): Trưởng phòng Kinh doanh (An Nguyễn) và Trưởng phòng Kế toán (Lê Thị Bích). Cần sự đồng thuận của cả hai.
  • Technical Approver (Người duyệt kỹ thuật): Quản lý ERP (Trần Văn Hùng) xác nhận tính khả thi.
  • Người chịu trách nhiệm triển khai: Đội ngũ phát triển ERP.

3.4.6. Hệ quả nếu Quyết định Sai (Consequence of Error)

• Nếu triển khai sai logic (quá lỏng lẻo): Có thể cấp nhầm hạn mức cho khách hàng không đủ điều kiện, làm tăng rủi ro nợ xấu. Thiệt hại tài chính tiềm tàng có thể lên tới 25,000,000 VND cho mỗi trường hợp sai.
• Nếu triển khai sai (quá chặt chẽ hoặc lỗi): Quy tắc tự động không được kích hoạt. Hệ thống quay về trạng thái như cũ. Hậu quả là chi phí phát triển bị lãng phí và vấn đề kinh doanh không được giải quyết.
• Nếu quyết định không làm gì (chọn PA-1): Công ty tiếp tục mất cơ hội kinh doanh và chịu chi phí vận hành không hiệu quả. Ước tính mỗi tháng mất 3-4 khách hàng tiềm năng do quy trình chậm.

4. Tier 3 – Fully Completed Nova Foods Case: Evidence and Traceability

Phần này ghi lại các bằng chứng, liên kết truy vết, và các yếu tố quản trị rủi ro liên quan đến yêu cầu thay đổi CR-2026-07-001.

4.1. Bảng Truy vết Yêu cầu (Requirements Traceability Matrix)

Bảng này đảm bảo mọi thứ được phát triển đều xuất phát từ một nhu cầu nghiệp vụ đã được ghi nhận. Nó liên kết Yêu cầu Thay đổi (Change Request - CR) ngược về Yêu cầu (Requirement - REQ), Quy tắc nghiệp vụ (Business Rule - BR), và Nhu cầu (Need).

ID của Yêu cầu Thay đổi	Liên kết đến ID cấp cao hơn	Loại liên kết	Mô tả
CR-2026-07-001	REQ-SAL-045	Satisfies	Yêu cầu thay đổi này triển khai logic được định nghĩa trong yêu cầu REQ-SAL-045.
REQ-SAL-045	BR-ACCT-017	Constrained by	Yêu cầu này phải tuân thủ quy tắc BR-ACCT-017 về điều kiện ghi nhận công nợ.
REQ-SAL-045	NEED-012	Derives from	Yêu cầu này bắt nguồn từ nhu cầu NEED-012 nhằm tăng tốc độ phản hồi cho khách hàng.

4.2. Giả định (Assumptions)

Giả định (Assumption) là những điều kiện chúng ta tin là đúng nhưng chưa có bằng chứng xác thực 100%. Nếu giả định sai, giải pháp có thể thất bại.

ID Giả định	Giả định	Tác động nếu sai	Hành động giảm thiểu
ASMP-01	Hệ thống Kế toán (SAP B1) luôn sẵn sàng và API cung cấp dữ liệu lịch sử thanh toán hoạt động ổn định.	Quy trình tự động sẽ thất bại, không thể tính toán payment_discipline (kỷ luật thanh toán). Không khách hàng nào được cập nhật hạn mức.	Thiết lập cơ chế thử lại (retry) 3 lần, nếu vẫn lỗi thì ghi log, gửi cảnh báo cho quản trị viên ERP và bỏ qua khách hàng đó trong lần chạy.
ASMP-02	Dữ liệu customer_category (phân loại khách hàng) trong ERP đã đầy đủ và chính xác cho tất cả khách hàng đang hoạt động.	Quy tắc không thể áp dụng cho khách hàng thiếu dữ liệu, bỏ sót các khách hàng đủ điều kiện.	Chạy báo cáo định kỳ hàng tuần để tìm các khách hàng có customer_category bị trống và yêu cầu bộ phận Sales cập nhật.
ASMP-03	Các ngưỡng giá trị (150,000,000 VND doanh số 6 tháng, 95% kỷ luật thanh toán) đã được Business Owner phê duyệt cuối cùng.	Phải làm lại logic nếu ngưỡng thay đổi sau khi triển khai, gây lãng phí chi phí phát triển.	Yêu cầu Business Owner ký xác nhận các ngưỡng này trong biên bản nghiệm thu yêu cầu (sign-off).

4.3. Các trường hợp ngoại lệ và Luồng xử lý tiêu cực (Exceptions and Negative Paths)

Ngoại lệ (Exception) là các sự kiện lỗi không mong muốn. Luồng xử lý tiêu cực (Negative Path) là cách hệ thống phải hành xử một cách an toàn khi ngoại lệ xảy ra.

Tình huống ngoại lệ	Luồng xử lý tiêu cực (hành vi hệ thống)
API Kế toán không phản hồi hoặc trả về lỗi 500: Không lấy được dữ liệu thanh toán.	1. Ghi log lỗi chi tiết với mã khách hàng và mã lỗi HTTP. 2. Gửi thông báo khẩn cấp đến kênh của đội kỹ thuật ERP. 3. Giữ nguyên hạn mức tín dụng hiện tại của khách hàng. 4. Chuyển sang xử lý khách hàng tiếp theo.
Tính toán ra hạn mức tín dụng mới là một số âm: Lỗi logic nghiêm trọng.	1. Ghi log lỗi mức CRITICAL với toàn bộ dữ liệu đầu vào (doanh số, công nợ). 2. Gửi thông báo khẩn cấp đến cả đội kỹ thuật và Business Owner. 3. Tuyệt đối không cập nhật hạn mức. Sử dụng giá trị cũ. 4. Dừng xử lý khách hàng này và gắn cờ để điều tra thủ công.
Người dùng cố gắng duyệt thay đổi hạn mức bằng tay nhưng không có quyền: Ví dụ: nhân viên kinh doanh cố duyệt.	1. Từ chối hành động. 2. Hiển thị thông báo lỗi: "Bạn không có quyền thực hiện hành động này. Yêu cầu quyền từ Trưởng phòng Kinh doanh hoặc Trưởng phòng Kế toán." 3. Ghi lại sự kiện vào nhật ký bảo mật (security log).
Khách hàng không tồn tại trong hệ thống Kế toán: Dữ liệu không đồng nhất giữa ERP và Kế toán.	1. Ghi log cảnh báo (WARNING). 2. Gắn cờ khách hàng này vào một báo cáo "Dữ liệu không đồng nhất" để các bên liên quan xử lý. 3. Giữ nguyên hạn mức tín dụng.

4.4. Các mục cần xác minh (Items Requiring Verification)

Đây là danh sách các điểm mà nhóm BA/Dev không có đủ thẩm quyền quyết định và cần sự xác nhận từ các vai trò chuyên môn khác.

ID Mục	Mục cần xác minh	Vai trò chịu trách nhiệm xác minh	Trạng thái
VRF-01	Định nghĩa "kỷ luật thanh toán" (payment_discipline) có phù hợp với chuẩn mực kế toán Việt Nam (VAS) hay không.	Trưởng phòng Kế toán (Lê Thị Bích)	VERIFIED
VRF-02	Việc tự động tăng hạn mức tín dụng có vi phạm điều khoản nào trong hợp đồng phân phối đã ký với các khách hàng lớn không.	Phòng Pháp chế (Legal)	PENDING_VERIFICATION
VRF-03	Ngưỡng 150,000,000 VND có cần được điều chỉnh theo mùa hoặc theo chiến dịch kinh doanh cụ thể không.	Trưởng phòng Kinh doanh (An Nguyễn)	VERIFIED

4.5. Lịch sử leo thang (Escalation History)

Ghi lại các vấn đề đã phải cần đến cấp quản lý cao hơn để giải quyết trong quá trình phân tích.

ID Leo thang	Vấn đề được leo thang	Người ra quyết định	Kết quả/Quyết định	Ngày quyết định
ESC-01	Mâu thuẫn giữa mục tiêu của phòng Kinh doanh (muốn quy tắc lỏng hơn để bán được hàng) và phòng Kế toán (muốn quy tắc chặt hơn để kiểm soát rủi ro).	An Nguyễn (TP Kinh doanh), Lê Thị Bích (TP Kế toán)	Thống nhất chọn Phương án 3 (PA-3) từ ma trận quyết định, cân bằng giữa rủi ro và cơ hội.	2026-07-25

Ma trận Truy vết Nguồn gốc (Traceability Matrix)

Ma trận truy vết nguồn gốc (tiếng Anh: Traceability Matrix) là một công cụ trực quan, thường ở dạng bảng, dùng để liên kết hai chiều giữa các thành phần trong vòng đời phát triển sản phẩm. Mục đích chính là đảm bảo mọi yêu cầu đều được kiểm thử và mọi thay đổi đều được phân tích tác động đầy đủ. Theo hướng dẫn của IIBA BABOK Guide, việc duy trì ma trận này là một nhiệm vụ cốt lõi trong quản lý yêu cầu.

Trong bối cảnh của Yêu cầu Thay đổi CR-SYS-20260807-001, ma trận dưới đây chứng minh mối liên kết từ lỗi được báo cáo (DEFECT), đến yêu cầu thay đổi để sửa lỗi (CR), ngược về yêu cầu chức năng (REQ) và quy tắc nghiệp vụ (BR) bị ảnh hưởng, và xuôi đến các tiêu chí chấp nhận (AC) và ca kiểm thử (TC) dùng để xác minh việc sửa lỗi đã thành công. Bảng này là bằng chứng cho việc phạm vi thay đổi đã được kiểm soát và chất lượng được đảm bảo.

Bảng 4.1: Ma trận Truy vết cho CR-SYS-20260807-001 (Mô phỏng Nova Foods)

ID & Loại Nguồn	Mô tả Nguồn	Loại Liên kết	ID & Loại Đích	Mô tả Đích
DEF-PROD-20260715-011 (Defect)	Lỗi hệ thống tính sai chiết khấu theo số lượng cho nhà cung cấp An Bình Food (A-123) trên đơn hàng mua.	is addressed by (được giải quyết bởi)	CR-SYS-20260807-001 (Change Request)	Yêu cầu sửa logic tính chiết khấu trên đơn hàng mua để áp dụng đúng bậc thang chiết khấu của nhà cung cấp.
CR-SYS-20260807-001 (Change Request)	Sửa logic tính chiết khấu trên đơn hàng mua.	corrects implementation of (sửa lỗi triển khai của)	REQ-FUNC-1138 (Functional Requirement)	Hệ thống phải tự động áp dụng chiết khấu theo số lượng khi tạo dòng đơn hàng mua.
CR-SYS-20260807-001 (Change Request)	Sửa logic tính chiết khấu trên đơn hàng mua.	implements fix for (triển khai sửa lỗi cho)	BR-SYS-217 (Business Rule)	"Khi số lượng mặt hàng NF-MILK-UHT-1L > 500 thùng từ NCC A-123, áp dụng chiết khấu 5% trên đơn giá."
AC-SYS-1138.3 (Acceptance Criterion)	Với NCC A-123, khi tạo PO có số lượng NF-MILK-UHT-1L là 501 thùng, hệ thống phải tự động áp dụng chiết khấu 5%.	is acceptance criterion for (là tiêu chí chấp nhận cho)	CR-SYS-20260807-001 (Change Request)	Yêu cầu sửa logic tính chiết khấu trên đơn hàng mua.
CR-SYS-20260807-001 (Change Request)	Sửa logic tính chiết khấu trên đơn hàng mua.	is verified by (được xác minh bởi)	TC-FUNC-2501 (Test Case)	Kiểm thử ca thành công: Tạo PO với 501 thùng sữa NF-MILK-UHT-1L từ NCC A-123, xác minh chiết khấu 5% được áp dụng.
CR-SYS-20260807-001 (Change Request)	Sửa logic tính chiết khấu trên đơn hàng mua.	is verified by (được xác minh bởi)	TC-FUNC-2502 (Test Case)	Kiểm thử ca phủ định (negative test): Tạo PO với 500 thùng sữa, xác minh không có chiết khấu nào được áp dụng.
BR-SYS-217 (Business Rule)	Quy tắc tính chiết khấu 5% khi số lượng > 500.	uses (sử dụng)	DATA-PO-015 (Data Element)	Dữ liệu discountRate (Tỷ lệ chiết khấu) trong cấu hình nhà cung cấp và đơn hàng mua.
BR-SYS-217 (Business Rule)	Quy tắc tính chiết khấu 5% khi số lượng > 500.	calculates (tính toán)	DATA-PO-016 (Data Element)	Dữ liệu finalLineItemPrice (Đơn giá cuối cùng của dòng hàng) sau khi đã áp dụng chiết khấu.

4.3 Bằng chứng kỹ thuật và nghiệp vụ cho CR-20260807-001

Phần này cung cấp các bằng chứng cụ thể, có thể kiểm chứng được, làm cơ sở cho yêu cầu thay đổi CR-20260807-001. Đối với yêu cầu thêm chức năng mã khuyến mãi vào đơn hàng mới, bằng chứng cốt lõi bao gồm hai phần: (1) sự thay đổi về mặt kỹ thuật trên giao diện lập trình ứng dụng (API) và (2) các quy tắc nghiệp vụ (business rules) chi phối việc áp dụng mã khuyến mãi đó.

Chúng ta sẽ sử dụng hai công cụ chuyên nghiệp để trình bày các bằng chứng này một cách rõ ràng và không mơ hồ. Thứ nhất là một đoạn trích từ Đặc tả OpenAPI (OpenAPI Specification - OAS), một tiêu chuẩn công nghiệp để mô tả các API. Thứ hai là Bảng quyết định (Decision Table), một kỹ thuật được mô tả trong cẩm nang BABOK Guide để làm rõ các logic nghiệp vụ phức tạp.

4.3.1 Đặc tả Payload cho API Endpoint

Để hệ thống có thể tiếp nhận mã khuyến mãi khi tạo đơn hàng mới, cấu trúc dữ liệu (payload) gửi đến API endpoint POST /api/v1/orders phải được cập nhật. Dưới đây là trích đoạn đặc tả kỹ thuật theo chuẩn OpenAPI 3.1, chỉ rõ việc thêm trường mới promotionCode.

Tệp tham chiếu: specs/nova-foods-erp-api-v1.2.oas.yaml (Mô phỏng) Thay đổi: Thêm trường promotionCode vào schema NewOrderRequest.

#
# Đây là một trích đoạn từ đặc tả OpenAPI, không phải toàn bộ tệp.
# Nó chỉ tập trung vào phần thân yêu cầu (request body) của thao tác tạo đơn hàng mới.
#
components:
  schemas:
    NewOrderRequest:
      type: object
      description: "Payload để tạo một đơn hàng mới trong hệ thống ERP của Nova Foods."
      properties:
        customerId:
          type: string
          format: uuid
          description: "ID định danh khách hàng (định dạng UUIDv4)."
          example: "a1b2c3d4-e5f6-7890-1234-567890abcdef"
        orderItems:
          type: array
          minItems: 1
          items:
            $ref: "#/components/schemas/OrderItem"
        shippingAddressId:
          type: string
          format: uuid
          description: "ID của địa chỉ giao hàng đã được lưu."
        # --- THAY ĐỔI BẮT ĐẦU ---
        # Thêm trường mới theo CR-20260807-001
        promotionCode:
          type: string
          description: "Mã khuyến mãi do khách hàng nhập. Có thể để trống (nullable)."
          nullable: true
          example: "NOVA2026"
        # --- THAY ĐỔI KẾT THÚC ---
      required:
        - customerId
        - orderItems
        - shippingAddressId

Việc định nghĩa trong OAS đảm bảo đội ngũ phát triển hiểu rõ kiểu dữ liệu (string), tính tùy chọn (nullable: true), và mục đích của trường mới mà không cần diễn giải thêm.

4.3.2 Bảng quyết định cho Logic áp dụng Mã khuyến mãi

Bảng quyết định sau đây làm rõ các điều kiện và hành động tương ứng khi xử lý mã khuyến mãi, dựa trên các quy tắc nghiệp vụ đã được định danh. Bảng này là nguồn chân lý (source of truth) cho cả BA, đội phát triển (dev) và đội kiểm thử (tester).

Tham chiếu quy tắc nghiệp vụ: BR-PROMO-001, BR-PROMO-002, BR-PROMO-003

	Quy tắc 1	Quy tắc 2	Quy tắc 3	Quy tắc 4
Điều kiện
1. promotionCode được cung cấp?	Có	Có	Có	Không
2. promotionCode tồn tại và hợp lệ trong hệ thống?	Có	Không	Có	-
3. Tổng giá trị đơn hàng ≥ 500,000 VND?	Có	-	Không	-
Hành động
1. Áp dụng giảm giá 10% vào tổng đơn hàng	X
2. Từ chối yêu cầu với mã lỗi nghiệp vụ		X (PROMO_CODE_INVALID)	X (ORDER_VALUE_TOO_LOW)
3. Xử lý đơn hàng (không có khuyến mãi)				X

Diễn giải bảng: * Quy tắc 1 (Thành công): Nếu khách hàng cung cấp một mã hợp lệ và giá trị đơn hàng đạt ngưỡng, hệ thống sẽ áp dụng giảm giá 10%. * Quy tắc 2 (Mã không hợp lệ): Nếu mã được cung cấp nhưng không tồn tại hoặc đã hết hạn, hệ thống sẽ từ chối yêu cầu với lỗi PROMO_CODE_INVALID. Điều kiện về giá trị đơn hàng không cần xét đến (được đánh dấu -). * Quy tắc 3 (Không đủ điều kiện): Nếu mã hợp lệ nhưng giá trị đơn hàng không đủ lớn, hệ thống từ chối áp dụng khuyến mãi với lỗi ORDER_VALUE_TOO_LOW. * Quy tắc 4 (Mặc định): Nếu khách hàng không cung cấp mã khuyến mãi, hệ thống xử lý đơn hàng như bình thường, không có giảm giá.

5. Tier 4 ? Senior BA Quality Gate

Mục này là cổng kiểm soát chất lượng (Quality Gate) của Senior BA. Mục đích là để rà soát Yêu cầu thay đổi (Change Request - CR) một cách có cấu trúc trước khi nó được chốt (baseline). Việc này ngăn các yêu cầu chất lượng thấp đi vào giai đoạn phát triển và kiểm thử, giúp tiết kiệm chi phí và giảm thiểu rủi ro cho dự án. Checklist dưới đây định nghĩa các tiêu chí và hành động cần thực hiện. Một CR chỉ được coi là "sẵn sàng để review" (ready for review) khi vượt qua tất cả các hạng mục trong checklist này.

Bảng kiểm tra chất lượng Yêu cầu thay đổi (CR Quality Checklist)

Hạng mục kiểm tra	Mô tả & Tiêu chí cốt lõi	Điều kiện Đạt/Không Đạt	Hành động nếu Không Đạt
1. Tính đầy đủ (Completeness)	Tất cả các mục trong template phải được điền đầy đủ. Không có ghi chú "TODO", "TBD" hoặc bỏ trống. Mọi trường dữ liệu, thuộc tính trong payload API hoặc cấu trúc dữ liệu phải được định nghĩa rõ ràng.	Đạt: Không có mục nào bị bỏ trống hoặc chứa giá trị giữ chỗ. Không Đạt: Tồn tại bất kỳ mục nào chưa hoàn thiện.	STOP: Trả lại CR cho người soạn thảo để hoàn thành. Yêu cầu không được xử lý tiếp cho đến khi đầy đủ.
2. Tính nhất quán (Consistency)	Thuật ngữ sử dụng phải khớp với từ điển dữ liệu (CANONICAL_DATA_DICTIONARY). Quy tắc nghiệp vụ (Business Rule) phải tham chiếu đến ID đã đăng ký trong CANONICAL_BUSINESS_RULES. Nội dung CR không được mâu thuẫn với các yêu cầu khác đã được phê duyệt.	Đạt: Mọi thuật ngữ, ID và quy tắc đều nhất quán trong toàn bộ CR và với các artifact liên quan. Không Đạt: Phát hiện mâu thuẫn hoặc sử dụng thuật ngữ không nhất quán.	STOP: Nếu mâu thuẫn trong phạm vi CR. ESCALATE: Nếu mâu thuẫn với hệ thống khác hoặc yêu cầu đã có, cần leo thang để chủ sở hữu nghiệp vụ (Business Owner) hoặc kiến trúc sư (Architect) ra quyết định.
3. Tính khả kiểm (Testability)	Tiêu chí chấp nhận (Acceptance Criteria - AC) phải rõ ràng, cụ thể, đo lường được và không mơ hồ. Một kiểm thử viên (Tester) phải có thể viết được ca kiểm thử (test case) cụ thể từ mỗi AC. Tránh các từ ngữ chủ quan như "nhanh", "dễ sử dụng", "thân thiện".	Đạt: Mọi AC đều có thể kiểm chứng bằng kết quả "pass" hoặc "fail" rõ ràng. Không Đạt: AC mang tính chủ quan hoặc không thể kiểm chứng.	STOP: Trả lại CR để viết lại AC. Gợi ý sử dụng các cấu trúc như Gherkin (Given-When-Then) để tăng tính rõ ràng.
4. Truy vết (Traceability)	CR phải có ID duy nhất. Yêu cầu phải liên kết ngược (trace back) đến một mục tiêu nghiệp vụ hoặc một vấn đề cần giải quyết. Mọi yêu cầu chức năng bên trong phải có ID duy nhất (vd: FR-UCO-001.1) để có thể liên kết tới (trace forward) các ca kiểm thử.	Đạt: Mọi liên kết truy vết (từ mục tiêu -> CR -> yêu cầu -> ca kiểm thử) đều tồn tại và hợp lệ. Không Đạt: Thiếu ID hoặc liên kết bị đứt gãy.	STOP: Trả lại CR để sửa ID và các liên kết truy vết theo quy định trong TRACEABILITY_ID_REGISTRY.md.
5. Nguồn xác thực (Source Authority)	Các tuyên bố, đặc biệt là các quy tắc liên quan đến pháp lý, tài chính, tuân thủ, phải trích dẫn nguồn từ 00_SOURCE_MAP.md. Các giả định phải được ghi rõ là "Giả định dự án" (Project Assumption) và cần được xác minh.	Đạt: Các quy tắc có nguồn gốc rõ ràng, giả định được đánh dấu minh bạch. Không Đạt: Đưa ra quy tắc như một sự thật mà không có bằng chứng hoặc nguồn xác thực.	STOP: Yêu cầu người soạn thảo cung cấp bằng chứng hoặc đánh dấu là giả định cần xác minh.
6. Quyền sở hữu (Ownership)	Phải xác định rõ một Chủ sở hữu nghiệp vụ (Business Owner) duy nhất chịu trách nhiệm ra quyết định. Danh sách các bên liên quan (stakeholder) cần review và phê duyệt phải được liệt kê đầy đủ.	Đạt: Owner và các stakeholder được định danh rõ ràng. Không Đạt: Vai trò Owner bị bỏ trống, không rõ ràng hoặc có nhiều hơn một người cùng chịu trách nhiệm cuối cùng.	ESCALATE: Leo thang lên Quản lý dự án (Project Manager) hoặc người bảo trợ (Sponsor) để chỉ định Owner. Công việc không thể tiếp tục nếu không có Owner.
7. Ranh giới (Boundaries)	CR phải xác định rõ liệu thay đổi có ảnh hưởng đến Dữ liệu cá nhân (theo Luật 91/2025/QH15), tính toán tài chính-kế toán, hay an ninh hệ thống (tham chiếu OWASP) hay không. Nếu có, phải ghi rõ yêu cầu review từ chủ sở hữu tương ứng (Pháp chế, Kế toán, An ninh thông tin).	Đạt: Các tác động liên quan đến ranh giới được xác định và yêu cầu review được đánh dấu. Không Đạt: Bỏ qua một tác động tiềm tàng đến các lĩnh vực nhạy cảm này.	STOP & ESCALATE: Dừng ngay lập tức và leo thang CR đến chủ sở hữu chức năng có liên quan (Pháp chế, Kế toán...). Không tiến hành cho đến khi có xác nhận từ họ.
8. Tác động thay đổi (Change Impact)	CR phải có một mục phân tích tác động đến các hệ thống khác, quy trình nghiệp vụ, vai trò người dùng và tài liệu hướng dẫn. Phạm vi của thay đổi ("in scope" và "out of scope") phải được định nghĩa rõ ràng.	Đạt: Có phân tích tác động đầy đủ và hợp lý. Không Đạt: Phân tích tác động bị thiếu hoặc hời hợt, không đủ chi tiết.	STOP: Trả lại CR để thực hiện phân tích tác động chi tiết hơn. Có thể cần tổ chức buổi làm việc (workshop) với các đội ngũ liên quan.

Bảng kiểm soát chất lượng yêu cầu thay đổi (Senior BA Quality Gate)

Bảng này định nghĩa các tiêu chí chất lượng tối thiểu mà một Yêu cầu thay đổi (Change Request - CR) phải đạt trước khi được xem xét đưa vào baseline. Mục tiêu là để chặn các CR chưa hoàn chỉnh, mâu thuẫn hoặc rủi ro ngay từ đầu, tiết kiệm thời gian cho tất cả các bên. Bất kỳ tiêu chí nào trong cột "Dừng & Leo thang" bị vi phạm sẽ ngay lập tức chuyển trạng thái CR thành STOP - REWORK REQUIRED.

Hạng mục kiểm tra	Định nghĩa và Tiêu chí Đạt (Pass)	Tiêu chí Dừng & Leo thang (Stop & Escalate)
Tính Toàn vẹn (Completeness)	Tất cả các mục trong template được điền đầy đủ, không có ghi chú giữ chỗ như [TBD], [chưa xác định] hoặc bỏ trống các trường bắt buộc. Bằng chứng và traceability link được cung cấp đầy đủ.	CR chứa bất kỳ mục giữ chỗ nào. Thiếu thông tin trọng yếu để hiểu mục đích, phạm vi, hoặc tiêu chí chấp nhận. Lý do: Không thể review một tài liệu chưa hoàn thiện.
Tính Nhất quán (Consistency)	Thuật ngữ, định danh (ví dụ: BR-NF-xxxx, UC-NF-xxxx), và dữ liệu nhất quán trong toàn bộ tài liệu và khớp với các nguồn canonical như /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md.	Một thuật ngữ có nhiều nghĩa. Một định danh được sử dụng không nhất quán. Dữ liệu trong ví dụ mâu thuẫn với quy tắc nghiệp vụ được mô tả. Lý do: Mâu thuẫn tạo ra sự mơ hồ và lỗi triển khai.
Tính Khả thi Kiểm thử (Testability)	Mỗi tiêu chí chấp nhận (Acceptance Criteria) đều rõ ràng, có thể đo lường, và đủ cụ thể để một kỹ sư QA có thể viết kịch bản kiểm thử (test case) mà không cần phải giả định thêm. Tiêu chí phải là có/không, đúng/sai, hoặc một kết quả có thể xác minh được.	Tiêu chí chấp nhận mang tính chủ quan (ví dụ: "giao diện phải thân thiện"), không thể đo lường ("hệ thống phải nhanh"), hoặc quá mơ hồ ("xử lý đơn hàng một cách chính xác"). Lý do: Yêu cầu không thể kiểm thử là yêu cầu không thể hoàn thành.
Tính Truy vết (Traceability)	Mọi yêu cầu chức năng và phi chức năng phải có liên kết ngược (backward traceability) đến một nhu cầu nghiệp vụ, mục tiêu dự án, hoặc nguồn có thẩm quyền. Phải có định danh duy nhất (ví dụ: CR-NF-ERP-001) để liên kết xuôi (forward traceability) tới các hạng mục thiết kế, code, và kiểm thử.	Một yêu cầu "mồ côi" xuất hiện mà không có nguồn gốc rõ ràng. Không thể xác định tại sao yêu cầu này tồn tại. Lý do: Yêu cầu không truy vết được có thể là "gold plating" (thêm tính năng không cần thiết) và nằm ngoài phạm vi.
Thẩm quyền Nguồn (Source Authority)	Nguồn của mỗi quy tắc hoặc ràng buộc phải được ghi nhận và có thẩm quyền phù hợp. Ví dụ, một yêu cầu pháp lý phải trích dẫn văn bản luật cụ thể (ví dụ: Luật 91/2025/QH15), một quy tắc kế toán phải do Kế toán trưởng xác nhận.	Một quy tắc nghiệp vụ quan trọng được trích dẫn từ một cuộc trò chuyện không chính thức hoặc một nguồn không có thẩm quyền (ví dụ: một bài blog). BA tự diễn giải luật hoặc chuẩn mực kế toán. Lý do: Sai thẩm quyền dẫn đến rủi ro tuân thủ và vận hành.
Ranh giới & Quyền sở hữu (Boundaries & Ownership)	CR phải tôn trọng ranh giới về chuyên môn. BA chỉ ghi nhận yêu cầu, không tự quyết định về kiến trúc hệ thống, lựa chọn công nghệ, quy trình kế toán, hoặc diễn giải pháp lý. Owner của từng quyết định phải được xác định rõ.	CR chứa các quyết định thuộc thẩm quyền của kiến trúc sư (ví dụ: "sử dụng database X"), kế toán (ví dụ: "hạch toán vào tài khoản Y"), hoặc pháp chế. BA tự chỉ định owner mà không có xác nhận. Lý do: Vượt thẩm quyền gây ra quyết định sai và xung đột trong dự án.
Tác động Thay đổi (Change Impact)	Phân tích tác động phải xác định rõ ràng các hệ thống, quy trình, vai trò người dùng, và các tài liệu khác bị ảnh hưởng bởi thay đổi. Mức độ ảnh hưởng (cao, trung bình, thấp) phải được ước tính.	Phần phân tích tác động bị bỏ trống, hoặc chỉ ghi chung chung "ảnh hưởng đến hệ thống ERP". Không liệt kê các module hoặc nhóm người dùng cụ thể. Lý do: Bỏ sót tác động dẫn đến lỗi hồi quy và gián đoạn vận hành.

Áp dụng Checklist vào Case Study Nova Foods (CR-2026-02-15-001)

Đây là kết quả ghi nhận từ việc áp dụng checklist Cổng chất lượng của Senior BA (Senior BA Quality Gate) cho ví dụ yêu cầu thay đổi CR-2026-02-15-001: Bổ sung trường 'Nước xuất xứ' vào dữ liệu master Nguyên vật liệu. Ghi nhận này chỉ mang tính đánh giá chất lượng yêu cầu, không cấu thành phê duyệt để triển khai.

Bảng dưới đây tổng hợp các phát hiện dựa trên 8 hạng mục kiểm soát chất lượng chính.

Hạng mục Kiểm tra (Checklist Item)	Kết quả Ghi nhận (Finding)	Trạng thái (Status)	Hành động Đề xuất (Recommended Action)
Tính Toàn vẹn (Completeness)	Mọi trường trong các mục 3 và 4 của template đã được điền đầy đủ. Không có mục nào bị bỏ trống hoặc ghi "TBD" (To Be Determined - Sẽ xác định sau).	PASS	Không cần hành động.
Tính Nhất quán (Consistency)	Mục tiêu (tuân thủ truy xuất nguồn gốc), giải pháp đề xuất (thêm trường Z_ORIGIN_COUNTRY vào bảng MARA) và các tiêu chí chấp nhận (Acceptance Criteria) đều đồng nhất và logic với nhau.	PASS	Không cần hành động.
Tính Khả kiểm (Testability)	Hầu hết các tiêu chí chấp nhận đều cụ thể và có thể kiểm thử. Tuy nhiên, tiêu chí AC-05: Hệ thống phải hoạt động ổn định sau khi thay đổi là mơ hồ, không thể đo lường được.	PASS WITH COMMENT	Chỉnh sửa AC-05 thành một yêu cầu phi chức năng (Non-functional Requirement) cụ thể. Ví dụ: "Thời gian phản hồi của màn hình MM01 và MM02 phải dưới 2 giây với 95% yêu cầu trong điều kiện tải thông thường."
Tính Truy vết (Traceability)	Yêu cầu thay đổi đã liên kết chính xác tới nhu cầu nghiệp vụ BN-PUR-2026-004 và quy tắc nghiệp vụ BR-FOOD-TRACE-003. Quy tắc này cũng được ghi nhận là bắt nguồn từ Luật An toàn thực phẩm, đảm bảo truy vết được đến nguồn gốc pháp lý.	PASS	Không cần hành động.
Thẩm quyền Nguồn & Chủ sở hữu (Source Authority & Ownership)	Chủ sở hữu Nghiệp vụ (Business Owner) được xác định là 'Trưởng phòng Mua hàng'. Vai trò này có đủ thẩm quyền để đưa ra yêu cầu liên quan đến dữ liệu master của nguyên vật liệu.	PASS	Không cần hành động.
Ranh giới (Boundaries)	Bảo mật: Phân quyền (đọc/ghi cho Mua hàng, chỉ đọc cho Quản lý Chất lượng) đã được xác định, phù hợp với rủi ro thấp của dữ liệu. Riêng tư: Yêu cầu không liên quan đến Dữ liệu Cá nhân theo Luật 91/2025/QH15. Pháp lý: CR ghi nhận yêu cầu xuất phát từ tuân thủ pháp luật. Kế toán: Phân tích tác động hoàn toàn bỏ qua ảnh hưởng tiềm tàng đến phân hệ Kế toán (FI/CO).	FAIL	STOP - ESCALATION REQUIRED: Phải chuyển yêu cầu đến bộ phận Kế toán để phân tích tác động đến việc tính thuế nhập khẩu, chi phí đích (landed cost) và các báo cáo tài chính liên quan. CR không được tiếp tục cho đến khi có xác nhận từ Chủ sở hữu phân hệ Kế toán.
Phân tích Tác động (Impact Analysis)	Phân tích tác động chỉ đề cập đến phân hệ Quản lý Kho (MM) và một báo cáo tùy chỉnh. Đã bỏ sót các tác động tiềm tàng đến: 1. Phân hệ Kế toán (FI/CO) như đã nêu trên. 2. Phân hệ Bán hàng và Phân phối (SD), nếu thông tin xuất xứ cần hiển thị trên chứng từ giao hàng hoặc hóa đơn cho khách.	FAIL	ACTION REQUIRED: Cập nhật lại mục phân tích tác động để bao gồm các phân hệ FI, CO, SD và các kho dữ liệu (BW) có thể bị ảnh hưởng. Việc này chỉ được thực hiện sau khi có kết quả từ bước leo thang cho Kế toán.

Tóm tắt kết quả cổng chất lượng

Trạng thái tổng thể: STOP - ACTION REQUIRED

Yêu cầu thay đổi CR-2026-02-15-001 được soạn thảo tốt về mặt cấu trúc và truy vết nhưng có lỗ hổng nghiêm trọng trong việc phân tích tác động đến tài chính và các phân hệ liên quan. Yêu cầu này phải dừng lại tại cổng chất lượng và không được chuyển sang giai đoạn thiết kế kỹ thuật cho đến khi: 1. Vấn đề được leo thang (escalate) và có xác nhận từ bộ phận Kế toán về tác động tài chính. 2. Mục phân tích tác động được cập nhật đầy đủ và chính xác.

6. Cross-File Checks, Open Issues, and Escalation

Phần này là kiểm soát cuối trước khi Yêu cầu thay đổi (Change Request - CR) được chuyển giao để xem xét. Mục đích: kiểm tra nhất quán liên tài liệu, ghi nhận vấn đề mở, xác định bằng chứng cần xác minh, phân công Owner, và quy định leo thang trước khi thay đổi lan sang thiết kế kỹ thuật, kiểm thử hoặc triển khai.

Trạng thái hiện tại của artifact này là IN_REVIEW. Trạng thái này cho phép review có kiểm soát; không xác nhận phê duyệt, không cho phép triển khai, và không thay thế quyết định của Business Owner, Solution Architect, Legal Owner, Accounting Owner, Security Architect hoặc Change Control Board (CCB).

6.1. Kiểm tra mâu thuẫn liên tài liệu (Cross-File Contradiction Check)

Kiểm tra này xác minh CR không mâu thuẫn với artifact quản trị trung tâm. Mục tiêu là duy trì Nguồn chân lý duy nhất (Single Source of Truth - SSOT), ngăn nhóm nghiệp vụ, kỹ thuật và kiểm thử dùng giả định khác nhau, và giảm làm lại do nguồn tham chiếu sai.

Bảng ghi nhận kết quả kiểm tra cho CR CR-2026-02-15-001.

Tài liệu tham chiếu được kiểm tra (Checked Artifact)	Nội dung kiểm tra cụ thể (Specific Checkpoint)	Kết quả	Ghi chú / Hành động bắt buộc (Notes / Required Action)
/01-curriculum/CHAPTER_MANIFEST.md /01-curriculum/TEMPLATE_MANIFEST.md /01-curriculum/TRACEABILITY_ID_REGISTRY.md /01-curriculum/CANONICAL_BUSINESS_RULES.md /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Kiểm tra metadata quản trị: các tài liệu kế hoạch trung tâm dùng Version: v0.9.0 và Status: IN_REVIEW.	PASS	Metadata quản trị nhất quán trong các artifact được kiểm tra. Kết quả này chỉ xác nhận tính nhất quán metadata; không xác nhận nội dung đã được phê duyệt.
/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Xác minh định danh CR CR-2026-02-15-001 đã đăng ký trong sổ đăng ký định danh.	PASS	ID CR-2026-02-15-001 đã đăng ký. ID này phải được giữ nguyên trong mọi artifact hạ nguồn tạo từ CR.
/01-curriculum/CANONICAL_BUSINESS_RULES.md	Đối chiếu quy tắc nghiệp vụ bị ảnh hưởng BR-Sourcing-003. CR mô tả quy tắc là “ghi nhận quốc gia xuất xứ”, trong khi catalog định nghĩa “ghi nhận và xác minh quốc gia xuất xứ theo chứng từ nhập khẩu hợp lệ”.	FAIL	Hành động bắt buộc: IT Business Analyst phải cập nhật “Mô tả thay đổi” của CR để phản ánh đầy đủ BR-Sourcing-003: hệ thống phải ghi nhận quốc gia xuất xứ và xác minh quốc gia đó theo chứng từ nhập khẩu hợp lệ. Không xử lý mâu thuẫn này có thể làm Solution Architect hoặc đội phát triển bỏ bước xác minh trong thiết kế và triển khai.
/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Xác minh trường dữ liệu mới country_of_origin tồn tại và được định nghĩa đúng: định danh, kiểu dữ liệu ISO 3166-1 alpha-2 code, ràng buộc.	PASS	Trường material.country_of_origin nhất quán với yêu cầu dữ liệu của CR. Khi cập nhật CR theo BR-Sourcing-003, IT Business Analyst phải bảo đảm mô tả xác minh không thay đổi định danh hoặc kiểu dữ liệu đã đăng ký.
Các tài liệu hạ nguồn (Downstream Consumers), gồm /specs/TECH_SPEC-MM-012.md nếu artifact này được tạo cho CR	Kiểm tra tài liệu đặc tả kỹ thuật hoặc kế hoạch kiểm thử đã tạo từ CR; kiểm tra tham chiếu đúng ID và phiên bản CR.	N/A	Tại thời điểm kiểm tra, chưa có tài liệu hạ nguồn được ghi nhận cho CR-2026-02-15-001. Khi tạo artifact hạ nguồn, Owner của artifact phải ghi ID CR, phiên bản CR được dùng, phạm vi ảnh hưởng, và kết quả review liên quan.
/00-research/00_SOURCE_MAP.md	Xác minh nguồn pháp lý được tham chiếu trong CR, gồm Luật An toàn thực phẩm, khớp nguồn đã được lập bản đồ trong 00_SOURCE_MAP.md.	PASS	Tham chiếu nguồn trong CR phù hợp với 00_SOURCE_MAP.md. Kết quả này xác nhận liên kết nguồn trong corpus; không phải ý kiến pháp lý, không thay thế xác minh của Legal Owner cho CR có ảnh hưởng tuân thủ.

Kết luận kiểm tra: CR-2026-02-15-001 còn một mâu thuẫn nghiệp vụ FAIL liên quan BR-Sourcing-003. IT Business Analyst phải sửa nội dung CR, Senior BA phải kiểm tra lại đối chiếu với /01-curriculum/CANONICAL_BUSINESS_RULES.md, và kết quả kiểm tra lại phải được ghi trong lịch sử thay đổi trước khi CR được chuyển cho CCB quyết định.

Các Vấn đề Tồn đọng, Giả định và Yêu cầu Xác minh

Bảng này ghi nhận hạng mục mở cần được giải quyết hoặc được chấp nhận rủi ro một cách tường minh trước khi CR dùng template này được xem xét phê duyệt. Mỗi hạng mục có Owner: vai trò chịu trách nhiệm quyết định, thu thập bằng chứng, hoặc leo thang đúng thẩm quyền. Owner không được tự mở rộng thẩm quyền ngoài ma trận ở mục 6.3.

ID	Phân loại	Mô tả và Bằng chứng	Thành phần Bị ảnh hưởng	Tác động Tiềm tàng	Người phụ trách (Owner)	Hành động Tiếp theo
ISSUE-001	Vấn đề tồn đọng (Open Issue)	Artifact lập kế hoạch của corpus, gồm 00_SOURCE_MAP, 01_CURRICULUM_ARCHITECTURE, CHAPTER_MANIFEST, đang ở IN_REVIEW, phiên bản v0.9.0. Đây là trạng thái làm việc có kiểm soát; không phải cơ sở đã được phê duyệt cho quyết định triển khai.	Toàn bộ corpus, gồm TMPL-CR-001.	Rủi ro không nhất quán nếu CR hoặc artifact hạ nguồn dựa vào nội dung đang thay đổi. Có thể phát sinh làm lại khi review thay đổi yêu cầu, quy tắc hoặc dữ liệu tham chiếu.	Principal IT BA / Curriculum Author	Duy trì trạng thái IN_REVIEW. Principal IT BA phải điều phối review các artifact kế hoạch cốt lõi, ghi nhận thay đổi và bằng chứng review. Không dùng trạng thái hiện tại làm bằng chứng rằng CR đã được phê duyệt hoặc sẵn sàng triển khai.
ISSUE-002	Vấn đề tồn đọng (Open Issue)	CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY được mô tả là artifact kế hoạch, chưa phải nguồn ổn định cho toàn bộ logic nghiệp vụ và định nghĩa dữ liệu. CR phức tạp có thể thiếu nguồn chân lý đủ chi tiết.	TMPL-CR-001 và CR tương lai liên quan logic nghiệp vụ hoặc cấu trúc dữ liệu.	Mâu thuẫn logic, định nghĩa dữ liệu không nhất quán giữa chức năng, tăng nợ kỹ thuật và chi phí bảo trì.	Principal IT BA	Soạn thảo, review và duy trì nội dung quy tắc nghiệp vụ, định nghĩa dữ liệu cốt lõi cho Nova Foods. Với mỗi CR bị ảnh hưởng, IT Business Analyst phải ghi rõ rule ID, data field ID, giả định còn lại và Owner xác minh.
ASSUMP-001	Giả định dự án (Project Assumption)	Case study Nova Foods và dữ liệu đi kèm là mô phỏng phục vụ giáo dục. Giả định: mức độ mô phỏng đủ để kiểm tra kỹ năng phân tích nghiệp vụ mà không dùng dữ liệu production.	Toàn bộ nội dung case study Nova Foods trong corpus.	Nếu mô phỏng quá đơn giản hoặc sai lệch, người học có thể áp dụng sai quy trình, hiểu sai ranh giới nghiệp vụ, hoặc bỏ qua rủi ro vận hành thực tế.	Principal IT BA / Curriculum Author	Nêu giới hạn mô phỏng trong các chương có case study. Khi review quy trình nghiệp vụ chính, Curriculum Author phải tham vấn SME khi cần kiểm chứng tính hợp lý nghiệp vụ. Kết quả tham vấn phải được ghi như bằng chứng review, không được mô tả như phê duyệt nếu SME không có thẩm quyền phê duyệt.
VERIFY-001	Yêu cầu xác minh (Verification Required)	CR xử lý dữ liệu cá nhân của khách hàng hoặc nhân viên phải được kiểm tra theo Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Bằng chứng nguồn: 00_SOURCE_MAP liệt kê các văn bản này.	CR cho module Nhân sự (HR), Quản lý Quan hệ Khách hàng (CRM), hoặc tính năng thu thập thông tin người dùng.	Trong vận hành thực tế: rủi ro pháp lý và tài chính. Trong curriculum: rủi ro truyền đạt nội dung tuân thủ sai hoặc thiếu.	Legal Owner (Vai trò mô phỏng)	IT Business Analyst phải gắn VERIFY-LEGAL-PRIVACY, mô tả dữ liệu cá nhân bị ảnh hưởng, mục đích xử lý, luồng dữ liệu và bằng chứng cần review. Legal Owner phải ghi kết quả xác minh hoặc yêu cầu sửa. CR giữ IN_REVIEW cho đến khi bằng chứng xác minh được ghi nhận.
VERIFY-002	Yêu cầu xác minh (Verification Required)	CR ảnh hưởng hóa đơn, báo cáo tài chính hoặc thuế phải được kiểm tra theo Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP. Bằng chứng nguồn: 00_SOURCE_MAP.	CR cho Tài chính-Kế toán (FI/CO), Bán hàng & Phân phối (SD), Mua hàng (MM).	Dữ liệu tài chính không chính xác, sai quy trình báo cáo thuế, sai sót vận hành và tuân thủ.	Accounting Owner (Vai trò mô phỏng)	IT Business Analyst phải gắn VERIFY-ACCT, xác định dữ liệu, quy tắc tính toán, chứng từ, báo cáo và luồng phê duyệt bị ảnh hưởng. Accounting Owner phải review tác động trước khi CR được bàn giao cho đội phát triển.
VERIFY-003	Yêu cầu xác minh (Verification Required)	CR ảnh hưởng xác thực, phân quyền hoặc dữ liệu nhạy cảm phải được đánh giá theo OWASP ASVS hoặc OWASP API Security Top 10. Bằng chứng nguồn: 00_SOURCE_MAP và TRACEABILITY_ID_REGISTRY.	API endpoint, màn hình đăng nhập, chức năng quản lý người dùng, quy trình xử lý thanh toán.	Lỗ hổng như API5:2023 - Broken Function Level Authorization hoặc API1:2023 - Broken Object Level Authorization; truy cập trái phép, lộ dữ liệu hoặc thay đổi dữ liệu không được phép.	Security Architect (Vai trò mô phỏng)	IT Business Analyst phải gắn VERIFY-SEC, xác định actor, đối tượng cần bảo vệ, quyền truy cập, dữ liệu nhạy cảm, luồng lỗi và bằng chứng kiểm thử dự kiến. Security Architect phải review kiểm soát bảo mật trước khi CR được chuyển cho CCB.

Quy tắc xử lý hạng mục mở:

1. IT Business Analyst phải ghi ID hạng mục mở trong CR khi phạm vi CR bị ảnh hưởng.
2. Owner phải ghi quyết định, bằng chứng, điều kiện chấp nhận rủi ro hoặc yêu cầu sửa trong artifact review phù hợp.
3. Senior BA phải xác minh CR không mô tả hạng mục chưa xác minh như sự thật đã được xác nhận.
4. Project Manager hoặc CR Coordinator phải leo thang hạng mục chưa giải quyết cho CCB khi hạng mục ảnh hưởng phạm vi, chi phí, lịch, tuân thủ, bảo mật hoặc khả năng triển khai.
5. CR giữ IN_REVIEW khi còn FAIL liên tài liệu hoặc khi bằng chứng bắt buộc cho tag VERIFY-LEGAL-PRIVACY, VERIFY-ACCT hoặc VERIFY-SEC chưa được ghi nhận.

Quy tắc Chuyển giao, Lan truyền Thay đổi và Ranh giới Thẩm quyền

Quy tắc này xác định luồng công việc, trách nhiệm và thẩm quyền cho CR-2026-02-15-001 từ soạn thảo đến thi hành nếu CCB quyết định chấp thuận. IN_REVIEW là trạng thái làm việc có kiểm soát, không phải trạng thái phê duyệt, không phải ủy quyền thay đổi production.

1. Quy trình Chuyển giao (Handoff Process)

Chuyển giao là bàn giao chính thức CR và bằng chứng liên quan cho vai trò tiếp theo để thực hiện hành động xác định. Người chuyển giao phải cung cấp ID CR, phiên bản, phạm vi, artifact tham chiếu, kết quả kiểm tra, hạng mục mở và quyết định đang chờ. Người nhận phải ghi kết quả review, yêu cầu sửa hoặc khuyến nghị.

Giai đoạn	Trạng thái CR	Vai trò thực hiện	Vai trò nhận chuyển giao	Hành động mong đợi của người nhận	Kết quả đầu ra
1. Soạn thảo và xem xét nội bộ	IN_REVIEW	IT Business Analyst	Senior BA (Peer Reviewer)	Kiểm tra đầy đủ, rõ ràng, nhất quán, tuân thủ template và liên kết truy vết. Xác minh CR nêu rõ actor, action, object, outcome, authority, artifact, trade-off và consequence. Gắn VERIFICATION_REQUIRED cho giả định cần bằng chứng.	Danh sách điểm cần sửa hoặc làm rõ; kết quả kiểm tra liên tài liệu; danh sách tag xác minh bắt buộc.
2. Xem xét bởi bên liên quan	IN_REVIEW	Senior BA	Business Owner, Solution Architect, QA Lead	Business Owner đánh giá giá trị nghiệp vụ và phạm vi. Solution Architect đánh giá khả thi kỹ thuật và tác động kiến trúc. QA Lead đánh giá khả năng kiểm thử, tiêu chí chấp thuận và negative path. Các Owner chuyên môn review hạng mục được gắn tag.	Báo cáo đánh giá tác động (Impact Assessment Report), bằng chứng review và khuyến nghị chấp thuận, từ chối hoặc yêu cầu sửa.
3. Ra quyết định	IN_REVIEW	Project Manager / CR Coordinator	Ban Quản lý Thay đổi (Change Control Board - CCB)	Xem xét CR, kết quả kiểm tra liên tài liệu, báo cáo tác động, hạng mục mở, trade-off và khuyến nghị. CCB quyết định theo thẩm quyền quản trị thay đổi.	Biên bản quyết định CCB lưu làm bằng chứng. Nếu CCB quyết định chấp thuận hoặc từ chối, CR Coordinator ghi quyết định và tham chiếu biên bản; artifact hiện tại không tự đổi trạng thái chỉ vì đã chuyển giao.

2. Quy tắc Lan truyền Thay đổi (Change Propagation Rules)

Lan truyền thay đổi là cập nhật có kiểm soát các artifact và cấu phần bị ảnh hưởng sau khi CCB có quyết định chấp thuận được ghi nhận. Không bắt đầu lan truyền chỉ dựa trên trạng thái IN_REVIEW, khuyến nghị của reviewer hoặc đánh giá kỹ thuật chưa có quyết định CCB.

ID Quy tắc	Nội dung quy tắc
PROP-RULE-01	Project Manager hoặc CR Coordinator phải lưu quyết định CCB và tham chiếu quyết định đó trong lịch sử thay đổi của CR-2026-02-15-001. IT Business Analyst duy trì nội dung CR và bảo đảm version, trạng thái và lịch sử thay đổi phản ánh quyết định được ghi nhận.
PROP-RULE-02	Owner của mỗi artifact bị ảnh hưởng phải cập nhật artifact thuộc trách nhiệm của mình. IT Business Analyst điều phối phạm vi và liên kết truy vết; không thay Owner artifact tự quyết nội dung ngoài thẩm quyền. Artifact có thể bị ảnh hưởng gồm /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, và chương handbook được liệt kê trong /01-curriculum/CHAPTER_MANIFEST.md.
PROP-RULE-03	Owner của artifact cập nhật phải thêm ID CR-2026-02-15-001 vào metadata hoặc lịch sử thay đổi của artifact đó. Tham chiếu phải cho biết artifact nào đổi, nội dung nào đổi và quyết định CR nào là căn cứ.
PROP-RULE-04	IT Business Analyst và Owner các artifact phụ thuộc phải xác nhận liên kết truy vết, quy tắc nghiệp vụ, định nghĩa dữ liệu, tiêu chí chấp thuận và bằng chứng kiểm thử còn nhất quán sau cập nhật. Nếu phát hiện mâu thuẫn mới, CR Coordinator phải đưa hạng mục về quy trình review và leo thang cho CCB khi tác động vượt thẩm quyền Owner.
PROP-RULE-05	Chỉ khi artifact phụ thuộc đã cập nhật, kiểm tra lại hoàn tất, và bằng chứng xác nhận được lưu, CR Coordinator mới được đề xuất CCB xem xét kết thúc vòng đời triển khai. Trạng thái kết thúc phải dựa trên bằng chứng hoàn tất, không dựa trên giả định.

3. Ma trận Ranh giới Thẩm quyền (Authority Boundaries Matrix)

Liệt kê vai trò trong quy trình chuyển giao không trao quyền quyết định ngoài phạm vi dưới đây. Vai trò tư vấn phải cung cấp bằng chứng, phân tích tác động hoặc thực thi theo quyết định được phê duyệt; không được tự thay đổi phạm vi, ngân sách, kiến trúc hoặc trạng thái CR.

Hoạt động	Vai trò có thẩm quyền quyết định	Vai trò không có thẩm quyền quyết định (Chỉ tư vấn hoặc thực thi)
Phê duyệt yêu cầu nghiệp vụ và phạm vi thay đổi	Chủ sở hữu Nghiệp vụ (Business Owner)	IT Business Analyst, Solution Architect
Phê duyệt giải pháp kỹ thuật và kiến trúc	Kiến trúc sư Giải pháp (Solution Architect) / Tech Lead	IT Business Analyst, Business Owner
Phê duyệt ngân sách và nguồn lực cho thay đổi	Ban Điều hành Dự án / Giám đốc Tài chính (CFO)	IT Business Analyst, Solution Architect, Business Owner
Phê duyệt CR để đưa vào triển khai	Ban Quản lý Thay đổi (CCB)	Cá nhân tham gia tư vấn, gồm IT Business Analyst, Business Owner, Solution Architect, QA Lead, Security Architect, Legal Owner và Accounting Owner
Phê duyệt triển khai lên môi trường Production	Quản lý Phát hành (Release Manager) / CCB	IT Business Analyst, Lập trình viên, QA
Soạn thảo và duy trì tài liệu CR	IT Business Analyst (Owner của CR)	Business Owner, Solution Architect
Xác minh nghĩa vụ pháp lý về dữ liệu cá nhân khi CR có VERIFY-LEGAL-PRIVACY	Legal Owner (Vai trò mô phỏng)	IT Business Analyst, Solution Architect, QA Lead
Xác minh tác động kế toán, hóa đơn, thuế khi CR có VERIFY-ACCT	Accounting Owner (Vai trò mô phỏng)	IT Business Analyst, Solution Architect, QA Lead
Xác minh kiểm soát bảo mật khi CR có VERIFY-SEC	Security Architect (Vai trò mô phỏng)	IT Business Analyst, Business Owner, QA Lead