TMPL-DEP-001 — Mẫu kiểm tra sẵn sàng triển khai (Deployment Readiness Template)

Bảng dưới đây xác định các thuộc tính quản trị và kiểm soát của mẫu tài liệu này. Mọi tham chiếu đến template này từ các tài liệu khác trong corpus phải tuân thủ các định danh và quy tắc được liệt kê tại đây để đảm bảo tính nhất quán và khả năng truy vết.

Trường kiểm soát	Giá trị
Artifact ID	TMPL-DEP-001
Tên tệp được kiểm soát	/03-templates/TMPL-DEP-001_deployment-readiness.md
Tiêu đề	Mẫu kiểm tra sẵn sàng triển khai (Deployment Readiness Template)
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Trách nhiệm của Owner	Chịu trách nhiệm duy trì cấu trúc và tính toàn vẹn của template này. Quản lý phiên bản, ghi nhận lịch sử thay đổi và đảm bảo sự phân định rõ ràng giữa các tầng (Tier) của template.
Giới hạn thẩm quyền của Owner	Owner không có quyền phê duyệt việc triển khai (deployment), không xác nhận trạng thái sẵn sàng của một hệ thống, và không đưa ra quyết định nghiệp vụ hoặc kỹ thuật thay cho các vai trò có thẩm quyền (ví dụ: Project Manager, Technical Architect, Business Owner).
Ngày cập nhật gần nhất	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale áp dụng	vi-VN
Case study tham chiếu	Nova Foods Trading & Manufacturing — mô phỏng cho mục đích giáo dục, chỉ sử dụng dữ liệu tổng hợp (synthetic data).
Phân loại artifact	Controlled Template (Mẫu có kiểm soát).
Lịch sử thay đổi	v0.9.0 (2026-08-07): Khởi tạo template ở trạng thái IN_REVIEW. Thiết lập metadata quản trị, xác định cấu trúc 4 tầng, và đặt ra các quy tắc sử dụng cho từng tầng.
Trạng thái baseline	Chưa có baseline. Trạng thái IN_REVIEW không được hiểu là đã baseline.
Trạng thái phê duyệt	Chưa có phê duyệt. Sự tồn tại của template không ngụ ý sự chấp thuận từ bất kỳ vai trò nào.

Ranh giới dữ liệu mô phỏng Nova Foods

Tất cả thông tin, dữ liệu, quyết định, và các hạng mục kiểm tra liên quan đến case study "Nova Foods" trong tài liệu này, đặc biệt ở Tầng 3 (Tier 3), đều là dữ liệu tổng hợp và hoàn toàn mô phỏng cho mục đích học tập. Chúng không đại diện cho hoạt động, quy trình, quyết định triển khai, hay cấu hình hệ thống thực tế của bất kỳ tổ chức nào. Việc sử dụng các ví dụ này phải luôn đi kèm với ghi chú rằng chúng chỉ mang tính minh họa.

1. Tier 1 ? Metadata, Purpose, and Governance

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

Mẫu này là một checklist (danh sách kiểm tra) chính thức để xác nhận một module, tính năng hoặc thay đổi của hệ thống ERP đã sẵn sàng để triển khai (deployment). Mục đích là đảm bảo mọi tiêu chí về kỹ thuật, nghiệp vụ, kiểm thử, và tài liệu đã được hoàn thành. Nó hoạt động như một "cổng chất lượng" (quality gate) cuối cùng trước khi chuyển giao, tạo ra bằng chứng có thể kiểm tra (auditable evidence) cho thấy sự cẩn trọng cần thiết đã được thực hiện.

Quy tắc sử dụng:

Trường hợp	Hành động	Lý do
NÊN DÙNG: Trước khi yêu cầu phê duyệt triển khai cho một phiên bản (release).	Hoàn thành đầy đủ các mục trong Tier 3.	Cung cấp bằng chứng cho Ban Cố vấn Thay đổi (Change Advisory Board - CAB) và các bên liên quan rằng rủi ro đã được quản lý.
NÊN DÙNG: Khi kết thúc giai đoạn Kiểm thử Chấp nhận người dùng (User Acceptance Testing - UAT).	Lấy chữ ký phê duyệt từ Business Owner.	Chính thức hóa sự chấp thuận của nghiệp vụ về chất lượng và sự hoàn chỉnh của chức năng.
KHÔNG DÙNG: Triển khai bản vá nóng (hotfix) khẩn cấp.	Sử dụng quy trình quản lý sự cố và thay đổi khẩn cấp.	Mẫu này quá toàn diện, tốn thời gian cho một hotfix vốn ưu tiên tốc độ khắc phục.
KHÔNG DÙNG: Thảo luận yêu cầu ở giai đoạn đầu.	Sử dụng các tài liệu như Business Case hoặc Vision & Scope.	Checklist này dùng để xác nhận kết quả đầu ra, không phải định hình yêu cầu đầu vào.

Vai trò, Trách nhiệm và Thẩm quyền:

Vai trò	Người chịu trách nhiệm (Ví dụ Nova Foods)	Trách nhiệm chính
Owner (Chủ sở hữu)	Project Manager hoặc Lead Business Analyst	Điền đầy đủ, chính xác checklist. Thu thập tất cả bằng chứng và chữ ký cần thiết. Đảm bảo checklist phản ánh đúng trạng thái thực tế.
Consumers (Người sử dụng)	Release Manager, QA Lead, IT Operations, Business Owner (ví dụ: Trưởng phòng Mua hàng)	Dùng checklist đã hoàn thành để ra quyết định: phê duyệt lịch triển khai, xác nhận chất lượng, chấp nhận chuyển giao.
Authority (Thẩm quyền phê duyệt)	Business Owner (ví dụ: Giám đốc Chuỗi cung ứng), Project Sponsor	Ký duyệt cuối cùng trên checklist, xác nhận chấp nhận mọi rủi ro còn lại và đồng ý cho việc triển khai.

Điều kiện tiên quyết và Sản phẩm hạ nguồn:

Loại	Chi tiết
Prerequisites (Điều kiện tiên quyết đầu vào)	Tài liệu yêu cầu đã được phê duyệt (ví dụ: TMPL-BRD-001 đã có chữ ký). Báo cáo hoàn thành chu kỳ kiểm thử (QA Test Cycle) với tất cả lỗi nghiêm trọng đã được xử lý. Biên bản nghiệm thu UAT đã được ký. Kế hoạch triển khai (Deployment Plan) và kế hoạch trả ngược (Rollback Plan) đã được soạn thảo.
Downstream Artifacts (Sản phẩm hạ nguồn)	Checklist đã ký duyệt trở thành một phần của hồ sơ gửi lên CAB. Kích hoạt quy trình của Release Manager để đưa vào lịch triển khai. Được lưu trữ trong kho tài liệu dự án làm bằng chứng tuân thủ.

Quy trình Leo thang (Escalation):

Bất kỳ mục nào trong checklist được đánh dấu "Không" hoặc "Chưa sẵn sàng" sẽ tự động chặn việc triển khai. Owner của checklist phải ngay lập tức ghi nhận vấn đề vào hệ thống theo dõi (ví dụ: Jira) với mức độ ưu tiên cao và tổ chức một cuộc họp leo thang với Authority và các trưởng nhóm liên quan. Quyết định cuối cùng (ví dụ: chấp nhận rủi ro và triển khai, hoặc hoãn lại để khắc phục) phải được ghi lại bằng văn bản và có chữ ký của người có thẩm quyền cao nhất.

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

Template này được quản trị như một thành phần có kiểm soát trong corpus học liệu Nova Foods. Định danh, nguồn gốc và các ràng buộc của nó được xác định bởi các artifact kiến trúc trung tâm.

Bảng Định danh và Liên kết Nguồn gốc

Hạng mục Quản trị	Giá trị Canonical / Tham chiếu	Nguồn Kiểm soát (Source of Truth)	Diễn giải và Ràng buộc
Artifact ID	TMPL-DEP-001	/01-curriculum/TEMPLATE_MANIFEST.md	Định danh duy nhất của template này trong toàn bộ corpus. Mọi tham chiếu chéo phải sử dụng ID này nguyên vẹn.
Loại Artifact	Controlled Template	/01-curriculum/TEMPLATE_MANIFEST.md	Là một template được quản trị phiên bản, trạng thái và thay đổi. Không phải là tài liệu ad-hoc.
Đường dẫn tệp Canonical	/03-templates/TMPL-DEP-001_deployment-readiness.md	/01-curriculum/TEMPLATE_MANIFEST.md	Đây là vị trí duy nhất được kiểm soát. Các bản sao hoặc bản xuất khác không có giá trị quản trị.
Chương Sổ tay Liên quan	Tham chiếu dự kiến: HB-CH-24 (Triển khai và Chuyển đổi Giải pháp)	/01-curriculum/CHAPTER_MANIFEST.md	Template này là tài liệu thực hành cốt lõi cho chương sổ tay tương ứng, minh họa cách áp dụng lý thuyết vào thực tế.
Nguồn Kiến trúc	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Sự tồn tại và mục đích của template này được xác định bởi kiến trúc học liệu tổng thể, đảm bảo tính nhất quán và không trùng lặp.

Nghĩa vụ Tuân thủ Định danh và Nguồn Dữ liệu Canonical

Khi sử dụng template này để tạo một tài liệu cụ thể (ví dụ: điền vào tầng 3 cho một dự án Nova Foods mô phỏng), người dùng có nghĩa vụ tuân thủ hệ thống định danh và nguồn dữ liệu canonical của corpus.

Loại Thông tin	Tiền tố ID (Ví dụ)	Nguồn Đăng ký Canonical (Source of Truth)	Yêu cầu Tuân thủ
Quy tắc Nghiệp vụ	BR-...	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Mọi quy tắc nghiệp vụ được tham chiếu phải sử dụng ID đã được định nghĩa trong catalog trung tâm. Không được phát minh quy tắc tại chỗ.
Yêu cầu (Requirement)	REQ-...	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Mọi yêu cầu (nghiệp vụ, chức năng, phi chức năng) phải được liên kết bằng ID đã đăng ký để bảo toàn khả năng truy vết (traceability).
Trường Dữ liệu	DDE-...	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Mọi trường dữ liệu đề cập trong tài liệu phải tuân theo định nghĩa (tên, kiểu, ràng buộc) từ từ điển dữ liệu canonical.
Nguồn Tham khảo	SRC-...	/00-research/00_SOURCE_MAP.md	Khi tham chiếu đến các tiêu chuẩn (ISO, BABOK) hoặc văn bản pháp lý, phải dùng ID và cách diễn giải đã được xác minh trong bản đồ nguồn.

Nghĩa vụ Kiểm soát Thay đổi

Mọi thay đổi đối với template này phải tuân thủ nghiêm ngặt quy trình kiểm soát thay đổi của corpus. 1. Phiên bản: Bất kỳ chỉnh sửa nào (sửa lỗi, bổ sung, thay đổi cấu trúc) đều phải dẫn đến việc tăng số phiên bản (ví dụ: từ v0.9.0 lên v0.9.1) và được ghi lại trong bảng Lịch sử Thay đổi. Không được sửa đổi thầm lặng (silent edit). 2. Trạng thái IN_REVIEW: Trạng thái này khẳng định rằng template chưa được phê duyệt cuối cùng (approved) hoặc chốt phiên bản (baselined). Nội dung có thể thay đổi. Không được coi đây là phiên bản ổn định để sử dụng chính thức. 3. Baseline và Phê duyệt (Approval): Việc chốt baseline hoặc phê duyệt là một sự kiện quản trị chính thức, được thực hiện bởi Authority và ghi nhận trong các artifact kiểm soát cấp cao hơn. Hành động này không được thực hiện bằng cách tự ý thay đổi trạng thái trong chính tài liệu này. Owner không có quyền tự phê duyệt.

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

Mẫu này là công cụ kiểm soát. Dùng để đánh giá mức độ sẵn sàng triển khai một cách có cấu trúc. Mục đích: giảm rủi ro, chuẩn hóa quy trình, và đảm bảo khả năng truy vết nguồn gốc (traceability) cho mọi quyết định. Business Analyst (BA) phải điền đầy đủ mọi trường với thông tin cụ thể hoặc ghi Không áp dụng. Không được bỏ trống.

---

A. Thông tin nhận dạng triển khai (Deployment Identification)

Bảng này định danh duy nhất gói triển khai. Thông tin phải khớp với các hệ thống quản lý thay đổi (change management) hoặc quản lý phiên bản (version control).

Trường thông tin	Giá trị (Điền vào)	Hướng dẫn / Diễn giải
Deployment ID	<DEP-ID-YYYYMMDD-NNN>	Mã định danh duy nhất cho lần triển khai này. Dùng để truy vết và kiểm toán.
Tên Module / Tính năng	<Tên của module, tính năng hoặc hệ thống con được triển khai>	Tên phải rõ ràng, dễ hiểu cho cả bên kinh doanh và kỹ thuật.
Phiên bản (Version)	<Số phiên bản, ví dụ: v1.2.1 hoặc mã commit Git>	Tham chiếu chính xác đến phiên bản mã nguồn hoặc gói phần mềm sẽ được triển khai.
Môi trường Đích	<Production / Staging / UAT>	Môi trường hệ thống nơi việc triển khai sẽ diễn ra.
Ngày/Giờ Triển khai	<YYYY-MM-DD HH:mm (Asia/Ho_Chi_Minh)>	Thời điểm dự kiến bắt đầu quá trình triển khai chính thức.
Người yêu cầu	<Tên và vai trò của người yêu cầu triển khai>	Người chịu trách nhiệm về mặt nghiệp vụ cho sự thay đổi này.
Người thực hiện	<Tên và vai trò của người chịu trách nhiệm kỹ thuật>	Người hoặc đội ngũ sẽ thực hiện các bước triển khai kỹ thuật.

B. Danh mục kiểm tra mức độ sẵn sàng (Readiness Checklist)

Đây là phần cốt lõi của tài liệu. Mỗi mục phải được đánh giá và cung cấp bằng chứng cụ thể. Trạng thái Bị chặn (Blocked) phải được giải quyết trước khi tiến hành triển khai.

Mã	Hạng mục	Nội dung kiểm tra	Trạng thái	Bằng chứng & ID truy vết	Ghi chú / Lý do
DEP-CHK-001	Yêu cầu	Tất cả yêu cầu nghiệp vụ (Business Requirements) đã được xác nhận hoàn thành bởi Business Owner.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link đến tài liệu ký duyệt, ID yêu cầu trong Jira/Azure DevOps>	<Ghi lý do nếu N/A hoặc Blocked>
DEP-CHK-002	Yêu cầu	Tất cả yêu cầu chức năng (Functional Requirements) đã được hiện thực.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<ID các REQ-..., USR-...>	<Ghi lý do nếu N/A hoặc Blocked>
DEP-CHK-003	Yêu cầu	Tất cả yêu cầu phi chức năng (Non-Functional Requirements) (hiệu năng, bảo mật, v.v.) đã được đáp ứng.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link báo cáo kiểm thử hiệu năng, kết quả quét bảo mật>	<Ghi lý do nếu N/A hoặc Blocked>
DEP-CHK-004	Kiểm thử	Tất cả các ca kiểm thử (Test Cases) quan trọng đã được thực thi và đạt (Pass).	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link đến báo cáo kết quả kiểm thử (Test Report), ID trong TestRail/Zephyr>	<Ghi lý do nếu N/A hoặc Blocked>
DEP-CHK-005	Kiểm thử	Không còn lỗi nghiêm trọng (Critical/Blocker bug) nào chưa được xử lý.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link đến query danh sách bug trong Jira>	<Ghi rõ các lỗi đã biết và được chấp nhận (nếu có)>
DEP-CHK-006	Kiểm thử	Kiểm thử hồi quy (Regression Testing) trên các chức năng bị ảnh hưởng đã hoàn tất.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link đến Test Execution Report cho regression suite>	<Ghi lý do nếu N/A hoặc Blocked>
DEP-CHK-007	Tài liệu	Tài liệu hướng dẫn người dùng cuối (User Manual) đã được cập nhật và sẵn sàng.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link đến tài liệu trên Confluence/SharePoint>	<Ghi lý do nếu N/A hoặc Blocked>
DEP-CHK-008	Tài liệu	Tài liệu kỹ thuật (Technical Documentation, Release Notes) đã hoàn tất.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link đến Release Notes, tài liệu kiến trúc>	<Ghi lý do nếu N/A hoặc Blocked>
DEP-CHK-009	Dữ liệu	Kế hoạch di chuyển dữ liệu (Data Migration), nếu có, đã được kiểm thử và phê duyệt.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link đến kế hoạch di chuyển dữ liệu và kết quả chạy thử>	<Ghi "Không có di chuyển dữ liệu" nếu N/A>
DEP-CHK-010	Cấu hình	Mọi cấu hình cần thiết cho môi trường đích (biến môi trường, feature flag) đã được chuẩn bị.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link đến file cấu hình hoặc pull request>	<Ghi lý do nếu N/A hoặc Blocked>
DEP-CHK-011	Đào tạo	Kế hoạch đào tạo người dùng (User Training) đã được xác định và thông báo.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Link đến kế hoạch đào tạo, email thông báo>	<Ghi lý do nếu N/A hoặc Blocked>
DEP-CHK-012	Phụ thuộc	Các hệ thống phụ thuộc (dependencies) đã sẵn sàng và tương thích.	[ ] Sẵn sàng [ ] Không áp dụng [ ] Bị chặn	<Xác nhận từ các đội sở hữu hệ thống phụ thuộc>	<Liệt kê các hệ thống phụ thuộc và trạng thái của chúng>

C. Đánh giá rủi ro và Kế hoạch Rollback

Việc triển khai luôn tiềm ẩn rủi ro. Phải xác định trước và có kế hoạch hành động.

C.1. Rủi ro đã nhận dạng (Identified Risks)

ID Rủi ro	Mô tả rủi ro	Mức độ Ảnh hưởng (Cao/Trung bình/Thấp)	Kế hoạch giảm thiểu / Hành động ứng phó
<RISK-001>	<Mô tả rủi ro tiềm ẩn, ví dụ: Hệ thống thanh toán bên thứ ba có thể chậm phản hồi>	<Trung bình>	<Hành động, ví dụ: Thông báo trước cho đội hỗ trợ, chuẩn bị quy trình xử lý thủ công tạm thời>
<RISK-002>	<Mô tả rủi ro tiềm ẩn>	<Cao / Trung bình / Thấp>	<Hành động>

C.2. Quy trình Rollback (Khôi phục)

Kế hoạch này phải được thống nhất với đội kỹ thuật. Nó mô tả các bước để trả hệ thống về trạng thái ổn định trước đó nếu việc triển khai thất bại.

1. Điều kiện kích hoạt Rollback: <Mô tả ngưỡng lỗi hoặc sự cố sẽ kích hoạt quy trình rollback, ví dụ: Tỷ lệ lỗi API vượt 5% trong 10 phút đầu tiên>
2. Bước 1: <Mô tả hành động cụ thể đầu tiên, ví dụ: Chuyển hướng traffic về phiên bản ổn định trước đó>
3. Bước 2: <Mô tả hành động cụ thể thứ hai, ví dụ: Thực thi script để khôi phục cơ sở dữ liệu từ bản sao lưu (backup) đã tạo trước khi triển khai>
4. Bước 3: <Mô tả hành động cụ thể thứ ba, ví dụ: Xác minh hệ thống đã hoạt động bình thường trở lại>
5. Người chịu trách nhiệm thông báo: <Tên và vai trò của người sẽ thông báo cho các bên liên quan khi có quyết định rollback>

D. Bảng ký xác nhận triển khai (Deployment Sign-off)

Sự đồng ý từ các vai trò chủ chốt là bắt buộc trước khi triển khai. Chữ ký điện tử hoặc xác nhận qua email/hệ thống có thể được tham chiếu trong cột Ghi chú.

Vai trò (Role)	Họ tên	Quyết định	Ngày xác nhận	Ghi chú / Tham chiếu xác nhận
Business Owner	<Tên người đại diện nghiệp vụ>	[ ] Approved [ ] Rejected	<YYYY-MM-DD>	<Link đến email xác nhận hoặc chữ ký số>
Product Owner	<Tên Product Owner>	[ ] Approved [ ] Rejected	<YYYY-MM-DD>	<Link đến email xác nhận hoặc chữ ký số>
Technical Lead	<Tên trưởng nhóm kỹ thuật>	[ ] Approved [ ] Rejected	<YYYY-MM-DD>	<Link đến email xác nhận hoặc chữ ký số>
QA Lead	<Tên trưởng nhóm kiểm thử>	[ ] Approved [ ] Rejected	<YYYY-MM-DD>	<Link đến email xác nhận hoặc chữ ký số>

Cấu trúc Quản trị, Truy vết và Phê duyệt

Phần này cung cấp các bảng trống cần thiết để quản trị, theo dõi, ghi nhận bằng chứng và ký duyệt cho một lần triển khai. Cấu trúc này đảm bảo mọi quyết định đều dựa trên bằng chứng và có sự truy vết rõ ràng.

Lịch sử Phiên bản Tài liệu

Bảng này ghi lại mọi thay đổi đối với tài liệu đánh giá mức độ sẵn sàng, đảm bảo tính toàn vẹn và khả năng kiểm tra lại lịch sử quyết định.

Phiên bản	Ngày cập nhật	Người thực hiện	Tóm tắt thay đổi	Tham chiếu Phê duyệt
<vX.Y.Z>	<YYYY-MM-DD>	<Tên và vai trò người cập nhật>	<Mô tả ngắn gọn, súc tích về nội dung đã thay đổi trong phiên bản này>	<ID của ticket, email, hoặc biên bản phê duyệt cho thay đổi nếu có>

Bảng Theo dõi Xem xét và Ký duyệt (Sign-off)

Mọi quyết định Go/No-Go phải được ghi nhận chữ ký từ các bên liên quan có thẩm quyền.

Vai trò ký duyệt	Tên người ký duyệt	Ngày ký duyệt	Quyết định	Ghi chú / Điều kiện
<Product Owner / Business Owner>	<Họ và tên>	<YYYY-MM-DD>	<Approved / Rejected / Approved with Conditions>	<Ghi rõ điều kiện phê duyệt hoặc lý do từ chối. Ví dụ: 'Approved, on condition that EXC-001 is resolved within 3 business days.'>
<Technical Architect / Tech Lead>	<Họ và tên>	<YYYY-MM-DD>	<Approved / Rejected / Approved with Conditions>	<Đánh giá về mặt kỹ thuật, kiến trúc. Ví dụ: 'Rejected due to performance degradation observed in load test results.'>
<QA Lead / Test Manager>	<Họ và tên>	<YYYY-MM-DD>	<Approved / Rejected / Approved with Conditions>	<Xác nhận về chất lượng và độ bao phủ kiểm thử. Ví dụ: 'Approved. All critical and high priority test cases passed.'>
<Security Lead>	<Họ và tên>	<YYYY-MM-DD>	<Approved / Rejected / Approved with Conditions>	<Đánh giá về mặt bảo mật. Ví dụ: 'Approved. Penetration testing results show no critical vulnerabilities.'>

Bảng Quản lý Bằng chứng (Evidence)

Mỗi mục trong checklist phải được hỗ trợ bởi bằng chứng cụ thể. Bảng này tập trung tất cả các bằng chứng.

ID Bằng chứng	Mô tả Bằng chứng	Đường dẫn / Tham chiếu
<DEP-EVD-001>	<Mô tả ngắn gọn về bằng chứng. Ví dụ: 'Báo cáo kết quả Smoke Test cho build 2.5.1'>	<Đường dẫn tới tệp, trang wiki, hoặc ID ticket. Ví dụ: '/reports/smoke-test_build-2.5.1.pdf'>

Bảng Quản lý Ngoại lệ (Exceptions)

Bất kỳ mục kiểm tra nào có trạng thái FAIL phải được ghi nhận như một ngoại lệ chính thức, đi kèm kế hoạch xử lý.

ID Ngoại lệ	Hạng mục bị ảnh hưởng (ID)	Mô tả Vấn đề & Phân tích Nguyên nhân	Mức độ Ảnh hưởng	Kế hoạch Khắc phục / Giảm thiểu	Người chịu trách nhiệm	Hạn xử lý	Trạng thái
<DEP-EXC-001>	<ID của hạng mục trong checklist, ví dụ: DEP-CHK-042>	<Mô tả cụ thể tại sao hạng mục này FAIL và nguyên nhân gốc rễ nếu đã xác định được>	<Critical / High / Medium / Low>	<Mô tả hành động cần thực hiện, ví dụ: 'Deploy hotfix 2.5.2' hoặc 'Business Owner chấp nhận rủi ro và sẽ xử lý trong Sprint kế tiếp'>	<Tên người hoặc đội chịu trách nhiệm xử lý>	<YYYY-MM-DD>	<Open / In Progress / Resolved / Closed>

Bảng Truy vết Yêu cầu và Rủi ro (Traceability)

Bảng này liên kết các hạng mục kiểm tra mức độ sẵn sàng ngược về các yêu cầu nghiệp vụ, yêu cầu phi chức năng, hoặc rủi ro đã được xác định. Điều này đảm bảo việc triển khai thực sự đáp ứng mục tiêu ban đầu.

ID Hạng mục Kiểm tra	Truy vết tới Yêu cầu / Rủi ro	Loại liên kết	Ghi chú
<DEP-CHK-XXX>	<ID của yêu cầu (ví dụ: F-REQ-005) hoặc rủi ro (ví dụ: RISK-SEC-002)>	<Verifies / Mitigates>	<Ghi chú diễn giải mối quan hệ, ví dụ: 'Hạng mục này xác minh yêu cầu F-REQ-005 đã được cài đặt đúng.'>

Quyết định Go/No-Go Cuối cùng

Đây là phần chốt hạ, ghi nhận quyết định cuối cùng dựa trên tất cả thông tin đã được thu thập và xem xét.

Quyết định cuối cùng	Người quyết định (có thẩm quyền)	Ngày quyết định	Căn cứ và Lý do
<GO / NO-GO>	<Họ và tên, Chức vụ>	<YYYY-MM-DD>	<Tóm tắt lý do cho quyết định. Ví dụ: 'GO: Tất cả hạng mục critical đều PASS. Ngoại lệ DEP-EXC-001 có ảnh hưởng thấp và đã được Business Owner chấp nhận rủi ro.' hoặc 'NO-GO: Tồn tại 2 ngoại lệ Critical chưa được xử lý.'>

Hướng dẫn điền Template, Quy tắc xác thực và Giá trị hợp lệ

Phần này cung cấp các quy tắc, giá trị được phép và hướng dẫn chi tiết để điền vào template trống. Tuân thủ các quy tắc này để đảm bảo tính nhất quán và khả năng kiểm tra (auditability) của tài liệu.

Nguyên tắc chung: * Placeholder: Mọi trường có dấu ngoặc nhọn <...> là một placeholder (trình giữ chỗ). Thay thế toàn bộ chuỗi, bao gồm cả dấu ngoặc, bằng giá trị thực tế. Ví dụ: <Tên hệ thống> trở thành Hệ thống ERP Nova Foods. * Định dạng ngày: Sử dụng định dạng YYYY-MM-DD theo chuẩn ISO 8601 cho mọi trường ngày tháng để tránh nhầm lẫn. * Phiên bản: Sử dụng Semantic Versioning (SemVer) cho các phiên bản phần mềm. SemVer là một quy ước đặt tên phiên bản theo định dạng MAJOR.MINOR.PATCH. * MAJOR: Tăng khi có thay đổi không tương thích ngược (breaking change). * MINOR: Tăng khi thêm chức năng mới nhưng vẫn tương thích ngược. * PATCH: Tăng khi sửa lỗi và vẫn tương thích ngược. * Ví dụ: 1.2.0.

---

Giá trị hợp lệ cho các trường có lựa chọn

Sử dụng các giá trị chính xác từ bảng dưới đây. Không tự ý thêm hoặc sửa đổi các giá trị này.

Tên trường	Giá trị cho phép	Diễn giải
Trạng thái Hạng mục	Not Started	Chưa bắt đầu thực hiện.
	In Progress	Đang trong quá trình thực hiện.
	Blocked	Bị chặn, không thể tiếp tục. Phải ghi rõ lý do trong phần ghi chú.
	Completed	Đã hoàn thành và được xác minh.
	Not Applicable	Không áp dụng cho lần triển khai này.
Môi trường	Development	Môi trường phát triển nội bộ.
	Staging	Môi trường kiểm thử nội bộ, gần giống Production.
	Production	Môi trường hoạt động chính thức cho người dùng cuối.
Trạng thái Tiêu chí	MET	Đã đạt ngưỡng yêu cầu.
	NOT MET	Chưa đạt ngưỡng yêu cầu.
Quyết định Phê duyệt	GO	Đồng ý triển khai không điều kiện.
	NO-GO	Không đồng ý triển khai. Phải dừng lại.
	GO WITH CONDITIONS	Đồng ý triển khai nhưng phải kèm theo các điều kiện được liệt kê.

---

Quy tắc cho các trường và sección có điều kiện

• Bảng Risk Assessment and Mitigation Plan (Đánh giá Rủi ro và Kế hoạch Giảm thiểu): Mục này là bắt buộc. Phải xác định ít nhất một rủi ro liên quan đến vận hành hoặc kỹ thuật, ngay cả khi mức độ ảnh hưởng thấp. Không được để trống.

• Bảng Rollback Plan (Kế hoạch Quay lui):

  • Bắt buộc nếu: Chiến lược triển khai là Big Bang, Phased Rollout hoặc Canary Release.
  • Không bắt buộc nếu: Chiến lược triển khai là Blue/Green và đã có cơ chế chuyển đổi traffic tự động để quay lui. Tuy nhiên, vẫn cần ghi rõ "Sử dụng cơ chế chuyển đổi của Blue/Green" trong phần ghi chú.

• Trường Conditional Notes trong Bảng Sign-off:

  • Bắt buộc nếu: Cột Quyết định có giá trị là GO WITH CONDITIONS.
  • Phải để trống nếu: Cột Quyết định có giá trị là GO hoặc NO-GO.

---

Mẫu tham chiếu an toàn cho thông tin nhạy cảm (Secrets)

QUY TẮC TUYỆT ĐỐI: Không bao giờ ghi giá trị bí mật (ví dụ: mật khẩu, API key, token) trực tiếp vào tài liệu này dưới dạng văn bản thuần túy. Việc này tạo ra rủi ro bảo mật nghiêm trọng.

Thay vào đó, sử dụng một mẫu tham chiếu đến hệ thống quản lý bí mật (ví dụ: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).

Cú pháp tham chiếu: VAULT::{project_or_team}/{environment}/{secret_name}

Ví dụ:

Môi trường	Tham số	Giá trị / Tham chiếu
Staging	DATABASE_URL	VAULT::nova-erp/staging/database-url
Production	PAYMENT_GATEWAY_API_KEY	VAULT::nova-erp/production/payment-gateway-api-key
Production	ENABLE_FEATURE_X	true

Cách làm này đảm bảo tài liệu chỉ chứa con trỏ đến bí mật, còn giá trị thực tế được lưu trữ và quản lý an toàn trong một hệ thống chuyên dụng. Chỉ những hệ thống và nhân sự có thẩm quyền mới có thể truy xuất giá trị thực từ vault tại thời điểm chạy (runtime).

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

Ví dụ hoàn chỉnh. Kịch bản: triển khai tính năng tích hợp cổng thanh toán MoMo cho đơn hàng B2C lên môi trường Production của hệ thống ERP Nova Foods.

Nguồn gốc yêu cầu: BR-FIN-018: Cung cấp thêm phương thức thanh toán điện tử cho khách hàng B2C.

---

Bảng 1: Metadata Triển khai

Trường dữ liệu	Giá trị (Dữ liệu mô phỏng)	Diễn giải
Deployment ID	DEP-2026-Q3-015	Định danh duy nhất cho lần triển khai này.
Tiêu đề triển khai	Tích hợp Cổng thanh toán MoMo cho Đơn hàng B2C	Mô tả ngắn gọn phạm vi công việc.
Yêu cầu bởi	Lê Thị Minh Anh (Trưởng phòng Kinh doanh B2C)	Người khởi tạo yêu cầu nghiệp vụ.
Business Owner	Trần Ngọc Bảo (Giám đốc Kinh doanh)	Người có thẩm quyền phê duyệt cuối cùng về mặt nghiệp vụ.
Component bị ảnh hưởng	erp-api-gateway (v3.1.2), erp-b2c-checkout-service (v1.5.0), erp-finance-module (v4.8.3)	Danh sách các dịch vụ hoặc module phần mềm được cập nhật.
Môi trường mục tiêu	Production	Môi trường triển khai cuối cùng.
Chiến lược triển khai	Blue/Green Deployment	Triển khai song song phiên bản mới (Blue) và cũ (Green), chuyển traffic sau khi xác minh. Giảm thiểu downtime.
Thời gian triển khai	2026-09-15 từ 02:00 đến 04:00 (Asia/Ho_Chi_Minh)	Khung giờ ít ảnh hưởng người dùng nhất.
Downtime dự kiến	0 phút	Blue/Green không yêu cầu downtime hệ thống.
Kế hoạch quay lui (Rollback)	Chuyển traffic DNS về môi trường Green (phiên bản v1.4.9 của checkout-service). Thời gian thực hiện < 5 phút.	Hành động cụ thể nếu có sự cố nghiêm trọng.
Rủi ro chính	1. API MoMo không ổn định: Gây lỗi thanh toán. 2. Lỗi logic xử lý callback: Dẫn đến sai lệch công nợ.	Rủi ro có xác suất cao hoặc tác động lớn nhất.
Kế hoạch giảm thiểu	1. Health check API MoMo trước khi chuyển traffic. 2. Triển khai dashboard giám sát giao dịch MoMo thời gian thực. 3. Kịch bản đối soát giao dịch thủ công đã sẵn sàng.	Hành động chuẩn bị trước để giảm thiểu rủi ro.

Bảng 2: Danh mục Kiểm tra Sẵn sàng Triển khai (Readiness Checklist)

Mã	Hạng mục kiểm tra	Trạng thái	Người xác nhận	Bằng chứng (Link tham chiếu mô phỏng)
DRC-01	Mã nguồn đã được merge vào nhánh release/v2.5.0.	HOÀN THÀNH	Nguyễn Hoàng Sơn (Tech Lead)	Git Commit: a1b2c3d
DRC-02	Build pipeline cho các component đã chạy thành công.	HOÀN THÀNH	DevOps Team	Jenkins Build #815 - SUCCESS
DRC-03	Toàn bộ kịch bản kiểm thử (UAT) đã pass trên môi trường Staging.	HOÀN THÀNH	Phạm Thuỳ Dương (QA Lead)	Jira Test Cycle: ERP-TC-205
DRC-04	Tài liệu hướng dẫn xử lý sự cố thanh toán đã được cập nhật.	HOÀN THÀNH	Trần Văn Hùng (Lead BA)	Confluence: KB-FIN-012 v1.1
DRC-05	Kế hoạch truyền thông cho người dùng cuối đã được phê duyệt.	HOÀN THÀNH	Lê Thị Minh Anh (Kinh doanh)	Email Approval ID: MKT-20260912-003
DRC-06	Cấu hình tham số môi trường đã được tạo trong vault.	HOÀN THÀNH	Security Officer	Vault Path: nova-erp/production/momo/*

Bảng 3: Phê duyệt Triển khai (Sign-off)

Vai trò	Người ký (Mô phỏng)	Quyết định	Ngày ký	Ghi chú có điều kiện
Business Owner	Trần Ngọc Bảo	GO	2026-09-14
Tech Lead	Nguyễn Hoàng Sơn	GO	2026-09-14
QA Lead	Phạm Thuỳ Dương	GO	2026-09-14
Deployment Owner	Đội DevOps	GO	2026-09-14

Bảng 4: Tham số Môi trường (Production)

CẢNH BÁO BẢO MẬT: Giá trị bí mật không bao giờ được ghi trực tiếp. Luôn dùng tham chiếu đến hệ thống quản lý bí mật.

Môi trường	Tham số	Giá trị / Tham chiếu
Production	MOMO_PARTNER_CODE	VAULT::nova-erp/production/momo-partner-code
Production	MOMO_ACCESS_KEY	VAULT::nova-erp/production/momo-access-key
Production	MOMO_SECRET_KEY	VAULT::nova-erp/production/momo-secret-key
Production	MOMO_API_ENDPOINT	https://business.momo.vn/v2/gateway/api
Production	ENABLE_MOMO_PAYMENT	true

3. Bản Ghi Readiness Triển Khai Hoàn Chỉnh: Module Mua Hàng (P2P)

Đây là một ví dụ đã điền đầy đủ của biểu mẫu đánh giá mức độ sẵn sàng triển khai, áp dụng cho case study mô phỏng của Nova Foods. Biểu mẫu này minh họa cách một Business Analyst (BA) ghi lại các tiêu chí, bằng chứng và quyết định cuối cùng trước khi một phân hệ phần mềm lớn được đưa vào vận hành chính thức (go-live). Kịch bản mô phỏng việc triển khai phân hệ "Procure-to-Pay" (P2P), tức là quy trình từ Mua hàng đến Thanh toán, trong hệ thống ERP của Nova Foods.

Bảng 1: Chi Tiết Gói Triển Khai (Deployment Package)

Thuộc tính	Giá trị (Dữ liệu mô phỏng)
Tên Gói Triển Khai	ERP Wave 1: Procure-to-Pay (P2P) Go-Live
Mã Định Danh	DEP-2026-Q4-001
Hệ thống/Phân hệ	NovaERP v1.2
Phạm vi	Kích hoạt phân hệ Quản lý Đơn Mua hàng (Purchase Order), Nhận hàng (Goods Receipt), và Đối chiếu Hóa đơn Nhà cung cấp (Supplier Invoice Matching). Ngừng sử dụng hệ thống mua hàng qua Excel.
Ngày Triển Khai	2026-10-28 @ 02:00 AM (Asia/Ho_Chi_Minh)
Loại Triển Khai	Big Bang (Triển khai toàn bộ phạm vi cùng một lúc) cho các phân hệ trong phạm vi.
Người Yêu Cầu	Lê Minh Tuấn (Trưởng phòng Mua hàng)
Người Phụ Trách Kỹ Thuật	Nguyễn Việt Anh (Trưởng phòng CNTT)

Bảng 2: Tiêu Chí Quyết Định Triển Khai (Go/No-Go Criteria)

"Go/No-Go" là các điều kiện bắt buộc phải thỏa mãn để đưa ra quyết định cuối cùng là "Triển khai" (Go) hay "Dừng lại" (No-Go).

Mã Tiêu Chí	Tiêu Chí Đánh Giá	Ngưỡng Yêu Cầu (Expected)	Kết Quả Thực Tế (Actual)	Trạng Thái	Bằng Chứng (Traceability ID)
GNG-FUNC-01	Kiểm thử Chấp nhận Người dùng (UAT) hoàn tất và đạt.	Tỷ lệ pass >= 95% cho các kịch bản kiểm thử critical-path.	98% (147/150 kịch bản critical-path đạt). 3 kịch bản low-priority thất bại, đã tạo defect.	GO	UAT-REPORT-P2P-W1-FINAL
GNG-TECH-01	Hiệu năng hệ thống đáp ứng yêu cầu phi chức năng (NFR).	Thời gian phản hồi trung bình của API tạo đơn hàng < 500ms với 100 người dùng đồng thời.	Trung bình 420ms, P95 485ms.	GO	PERF-TEST-20261015-P2P
GNG-DATA-01	Di chuyển dữ liệu nhà cung cấp đang hoạt động hoàn tất.	100% bản ghi nhà cung cấp đang hoạt động (trạng thái ACTIVE) được chuyển và xác thực thành công.	100% (2,512 bản ghi).	GO	DATA-MIG-VALIDATION-SUPP-20261020
GNG-COMP-01	Tích hợp Hóa đơn Điện tử tuân thủ Nghị định 123/2020/NĐ-CP.	Gửi thành công hóa đơn thử nghiệm lên môi trường sandbox của nhà cung cấp M-Invoice và nhận được mã xác thực hợp lệ.	Hoàn thành.	GO	SR-INT-012, TEST-CASE-INV-077
GNG-OPS-01	Đào tạo người dùng cuối hoàn tất.	>= 90% nhân viên phòng Mua hàng và Kế toán Thanh toán hoàn thành khóa đào tạo.	96% (48/50 nhân viên). 2 nhân viên nghỉ phép sẽ được đào tạo sau.	GO	TRAINING-LOG-2026-Q4-P2P

Bảng 3: Phê Duyệt Triển Khai từ các Bên Liên Quan (Stakeholder Sign-off)

Tên Bên Liên Quan (Stakeholder)	Vai Trò	Quyết Định	Ngày Phê Duyệt	Ghi Chú
Lê Minh Tuấn	Business Owner (Trưởng phòng Mua hàng)	GO	2026-10-25	Xác nhận quy trình nghiệp vụ đáp ứng yêu cầu.
Trần Thị Bích Thảo	Finance & Compliance Owner (Kế toán trưởng)	GO	2026-10-25	Xác nhận quy trình tuân thủ quy định kế toán và hóa đơn.
Nguyễn Việt Anh	Technical Owner (Trưởng phòng CNTT)	GO	2026-10-26	Xác nhận hệ thống ổn định và sẵn sàng về mặt kỹ thuật.
Phạm Văn Dũng	Project Manager	GO (Recommended)	2026-10-26	Đề xuất triển khai dựa trên tất cả tiêu chí đã đạt.

Quyết định cuối cùng: GO. Triển khai theo kế hoạch.

3.1 Bối cảnh, Phân tích và Quyết định

Phần này ghi lại bối cảnh, phân tích lựa chọn, và quyết định cuối cùng cho việc triển khai chức năng tự động hóa quy trình duyệt Đơn Mua Hàng (Purchase Order - PO) trong hệ thống ERP của Nova Foods.

1. Hiện trạng và Nhu cầu Nghiệp vụ

• Hiện trạng (As-Is): Quy trình duyệt PO hiện tại hoàn toàn thủ công qua email. Nhân viên Kế toán Mua hàng tạo file PO (PDF), gửi email cho Trưởng phòng Mua hàng. Sau khi nhận được duyệt, email được chuyển tiếp cho Kế toán trưởng. Đối với các PO có giá trị lớn hơn 500.000.000 VND, cần có sự phê duyệt bổ sung từ Giám đốc Tài chính (CFO). Quy trình này chậm, trung bình mất 3-5 ngày làm việc, dễ thất lạc thông tin và không có khả năng truy vết (traceability) tập trung để phục vụ kiểm toán.
• Nhu cầu (To-Be): Cần một quy trình tự động, được tích hợp trong ERP để:
  • Rút ngắn thời gian duyệt PO xuống dưới 24 giờ.
  • Cung cấp một bản ghi lịch sử (audit trail) không thể thay đổi về các bước phê duyệt, tuân thủ yêu cầu về chứng từ kế toán. (Tham chiếu: SRC-ID: LAW-VN-ACC-01, Luật Kế toán 88/2015/QH13).
  • Giảm thiểu rủi ro vận hành do chậm trễ trong việc cung ứng nguyên vật liệu.

2. Phân tích các phương án và Tiêu chí Quyết định

Nhóm dự án đã xem xét ba phương án chính. Việc lựa chọn dựa trên các tiêu chí được xác định và có trọng số bởi các bên liên quan chính (stakeholders) là phòng Mua hàng và phòng Kế toán.

Tiêu chí	Trọng số	Phương án 1: Giữ nguyên (Email)	Phương án 2: Xây dựng tùy chỉnh (Custom)	Phương án 3: Cấu hình chuẩn (Standard)
Tổng chi phí sở hữu (TCO)	30%	Chi phí thấp nhất (chỉ chi phí vận hành gián tiếp).	Chi phí cao nhất (phát triển, kiểm thử, triển khai). Ước tính 950.000.000 VND.	Chi phí trung bình (chỉ chi phí tư vấn cấu hình và đào tạo). Ước tính 150.000.000 VND.
Thời gian triển khai	25%	0 ngày.	Dài nhất (3-4 tháng).	Ngắn nhất (2-3 tuần).
Tính tuân thủ & Khả năng kiểm toán	25%	Rất thấp. Rủi ro cao.	Cao. Có thể thiết kế theo yêu cầu kiểm toán cụ thể.	Cao. Tính năng chuẩn đã được chứng thực.
Rủi ro bảo trì & Nâng cấp	15%	Không có rủi ro kỹ thuật.	Cao. Phụ thuộc vào đội phát triển, khó nâng cấp ERP.	Rất thấp. Được nhà cung cấp ERP hỗ trợ.
Mức độ đáp ứng yêu cầu	5%	Thấp. Không giải quyết được vấn đề gốc rễ.	100%. Đáp ứng mọi yêu cầu chi tiết.	~95%. Đáp ứng tất cả yêu cầu cốt lõi. Một số yêu cầu "nice-to-have" không được hỗ trợ.
Tổng điểm (có trọng số)	100%	1.40	3.35	4.45

3. Quyết định & Thẩm quyền

• Quyết định được đề xuất: Triển khai Phương án 3: Cấu hình workflow phê duyệt PO tiêu chuẩn có sẵn trong hệ thống ERP.
• Lý do: Phương án này mang lại giá trị cao nhất với điểm số 4.45, cân bằng tối ưu giữa chi phí, thời gian triển khai, và rủi ro thấp, trong khi vẫn đáp ứng đầy đủ các yêu cầu nghiệp vụ cốt lõi và yêu cầu tuân thủ.
• Thẩm quyền quyết định: Quyết định được phê duyệt bởi Hội đồng dự án, đại diện bởi:
  • Bà Nguyễn Thị Lan, Giám đốc Tài chính (Vai trò: Business Owner)
  • Ông Trần Văn Hùng, Trưởng phòng Mua hàng (Vai trò: Domain Owner)
• Ngày quyết định: 2026-07-20. Biên bản họp NOVA-ERP-MOM-20260720-01 đã được lưu trữ.

4. Hậu quả nếu Quyết định sai

Nếu lựa chọn Phương án 3 (cấu hình chuẩn) nhưng trong tương lai phát sinh các quy trình ngoại lệ phức tạp mà workflow chuẩn không thể xử lý, Nova Foods sẽ phải đối mặt với các lựa chọn: a) Chấp nhận thực hiện các quy trình ngoại lệ đó một cách thủ công, làm giảm hiệu quả chung. b) Quay lại đầu tư chi phí và thời gian đáng kể để xây dựng giải pháp tùy chỉnh (Phương án 2).

Rủi ro này được đánh giá là thấp sau khi phân tích 2 năm dữ liệu lịch sử về các yêu cầu mua hàng và không tìm thấy trường hợp ngoại lệ nào không thể xử lý bằng logic cấu hình linh hoạt của module chuẩn.

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

Phần này cung cấp các bằng chứng, giả định, và đường dẫn truy vết (traceability) để xác nhận trạng thái sẵn sàng triển khai của chức năng "Quy trình Phê duyệt Đơn Mua Hàng (PO)".

4.1. Ma trận truy vết (Traceability Matrix)

Ma trận truy vết là một công cụ để đảm bảo mọi yêu cầu ban đầu đều được xử lý và kiểm thử trong suốt vòng đời dự án. Nó tạo ra một chuỗi liên kết không thể phá vỡ từ nhu cầu nghiệp vụ gốc đến sản phẩm cuối cùng.

ID Nguồn (Source)	Loại	Mô tả	ID Đích (Target)	Loại	Ghi chú
NEED-001	Business Need	Cần chuẩn hóa và tự động hóa quy trình phê duyệt PO để tăng tốc độ, giảm sai sót thủ công, và đảm bảo tuân thủ.	REQ-004	Functional Req	Hệ thống phải cung cấp một quy trình phê duyệt PO điện tử dựa trên các cấp bậc và giá trị đơn hàng.
REQ-004	Functional Req	Hệ thống phải cung cấp một quy trình phê duyệt PO điện tử dựa trên các cấp bậc và giá trị đơn hàng.	BR-PUR-002	Business Rule	Mọi PO có giá trị > 5,000,000 VND phải được Trưởng phòng phê duyệt.
BR-PUR-002	Business Rule	Mọi PO có giá trị > 5,000,000 VND phải được Trưởng phòng phê duyệt.	AC-004.1	Acceptance Crit	Khi một PO với giá trị 5,000,001 VND được tạo, hệ thống tự động gửi yêu cầu phê duyệt đến Trưởng phòng của người tạo.
/03-templates/TMPL-DEC-001_decision-log.md	Decision Record	Quyết định chọn "Phương án 3: Cấu hình workflow chuẩn" ngày 2026-07-20.	/03-templates/TMPL-DEP-001_deployment-readiness.md	Readiness Check	Việc kiểm tra readiness này dựa trên quyết định đã được phê duyệt là sử dụng cấu hình chuẩn của ERP.

4.2. Các trường hợp ngoại lệ và Luồng xử lý lỗi (Exceptions & Negative Paths)

Một "luồng xử lý lỗi" (Negative Path) mô tả cách hệ thống phản ứng khi có sự cố xảy ra, thay vì đi theo "luồng hạnh phúc" (Happy Path) nơi mọi thứ hoạt động hoàn hảo. Việc xác định các luồng này rất quan trọng để đảm bảo hệ thống mạnh mẽ và thân thiện với người dùng.

ID Tình huống	Mô tả Tình huống (Luồng lỗi)	Cách xử lý dự kiến của hệ thống	Rủi ro còn lại / Ghi chú
EXC-PO-01	Người phê duyệt được chỉ định đang nghỉ phép.	Hệ thống tự động leo thang yêu cầu phê duyệt đến người quản lý cấp trên trực tiếp của người nghỉ phép sau 24 giờ không có phản hồi. Cấu hình này là một phần của module ERP chuẩn.	Thấp. Cần đảm bảo dữ liệu về cấu trúc quản lý và lịch nghỉ phép trong hệ thống luôn được cập nhật từ phòng Nhân sự.
EXC-PO-02	PO được tạo với giá trị vượt quá giới hạn phê duyệt của tất cả các cấp trong phòng ban.	Hệ thống sẽ đánh dấu PO là "Yêu cầu phê duyệt đặc biệt" và gửi thông báo đến Giám đốc Tài chính (CFO) để xử lý thủ công.	Trung bình. Tình huống này nên hiếm khi xảy ra nếu ma trận phê duyệt được định nghĩa đúng. Cần có quy trình vận hành rõ ràng cho CFO.
EXC-PO-03	Người dùng cố gắng phê duyệt một PO mà họ không có thẩm quyền.	Giao diện hệ thống sẽ không hiển thị nút "Phê duyệt". Nếu cố gắng truy cập qua API, hệ thống trả về lỗi 403 Forbidden với mã lỗi AUTH_INSUFFICIENT_PERMISSIONS.	Rất thấp. Đây là chức năng bảo mật cốt lõi của ERP.
EXC-PO-04	Dữ liệu nhà cung cấp trên PO không hợp lệ (ví dụ: mã số thuế không tồn tại trong danh mục).	Hệ thống sẽ chặn không cho gửi PO đi phê duyệt và hiển thị thông báo lỗi cho người tạo: "Nhà cung cấp không hợp lệ. Vui lòng chọn nhà cung cấp từ danh mục đã được phê duyệt."	Thấp. Yêu cầu này đảm bảo tính toàn vẹn dữ liệu đầu vào.

4.3. Bằng chứng và Tài liệu tham chiếu (Evidence & References)

ID Bằng chứng	Tên tài liệu / Artifact	Phiên bản / Ngày	Mục đích / Nội dung	Vị trí lưu trữ
EVID-01	TMPL-DEC-001_decision-log.md	v1.0 / 2026-07-20	Ghi nhận quyết định chính thức chọn phương án cấu hình ERP chuẩn.	/03-templates/
EVID-02	NOVA-CFG-PO-APPROVAL-v1.2.docx	v1.2 / 2026-08-01	Tài liệu đặc tả chi tiết cấu hình ma trận phê duyệt đã được Trưởng phòng Mua hàng và Giám đốc Tài chính ký duyệt.	SharePoint://Project-ERP/Configurations/
EVID-03	NOVA-UAT-TEST-RESULTS-PO-v1.0.xlsx	v1.0 / 2026-08-05	Kết quả kiểm thử chấp nhận người dùng (UAT), xác nhận tất cả các kịch bản kiểm thử (bao gồm cả luồng lỗi) đều đạt.	SharePoint://Project-ERP/Testing/UAT/

4.4. Giả định (Assumptions)

ID Giả định	Nội dung Giả định	Lý do / Cơ sở	Ai chịu trách nhiệm xác minh?
ASM-01	Chức năng phê duyệt chuẩn của hệ thống ERP đủ linh hoạt để đáp ứng 99% các trường hợp mua hàng của Nova Foods.	Phân tích dữ liệu mua hàng 2 năm qua không tìm thấy quy trình ngoại lệ nào không thể xử lý bằng cấu hình chuẩn.	Business Owner (Giám đốc Tài chính)
ASM-02	Dữ liệu về cấu trúc phòng ban, chức danh và quan hệ báo cáo trong hệ thống ERP được đồng bộ chính xác và kịp thời từ hệ thống HRIS (Human Resource Information System).	Đây là yêu cầu nền tảng cho việc định tuyến phê duyệt tự động. Nhóm kỹ thuật đã xác nhận có API đồng bộ.	Technical Owner (Trưởng nhóm ERP)
ASM-03	Tất cả người dùng có vai trò phê duyệt đều đã được đào tạo và hiểu rõ cách sử dụng hệ thống mới.	Kế hoạch đào tạo đã được thực hiện vào tuần 2026-07-27.	Change Manager / Project Manager

4.5. Các hạng mục cần xác minh trước Go-Live (Verification-Required Items)

ID Hạng mục	Hạng mục cần xác minh	Tiêu chí hoàn thành	Người chịu trách nhiệm	Hạn chót
VER-01	Xác minh tài khoản người dùng và phân quyền cho toàn bộ 25 nhân sự có vai trò phê duyệt đã được thiết lập chính xác trên môi trường Production.	Biên bản kiểm tra có chữ ký của Trưởng nhóm ERP và Trưởng phòng Mua hàng.	Trưởng nhóm ERP	2026-08-10
VER-02	Xác minh cấu hình ma trận phê duyệt trên môi trường Production khớp 100% với tài liệu NOVA-CFG-PO-APPROVAL-v1.2.docx.	Một người khác trong nhóm kỹ thuật thực hiện kiểm tra chéo và ký xác nhận.	Kỹ sư ERP (không phải người cấu hình)	2026-08-11
VER-03	Xác minh kênh thông báo (email/notification trong app) hoạt động cho các yêu cầu phê duyệt mới và các trường hợp leo thang.	Gửi thành công một PO thử nghiệm trên Production (sẽ được hủy ngay sau đó) và người phê duyệt xác nhận đã nhận được thông báo.	Project Manager	2026-08-12

4.6. Hồ sơ Leo thang (Escalation Records)

"Leo thang" (Escalation) là quy trình chính thức để đưa một vấn đề, rủi ro hoặc quyết định lên cấp quản lý cao hơn khi nhóm dự án không thể tự giải quyết.

ID Leo thang	Vấn đề được leo thang	Ngày leo thang	Người/Cấp nhận leo thang	Kết quả / Quyết định	Ngày giải quyết
ESC-01	Phòng Marketing yêu cầu một quy trình phê duyệt PO "siêu tốc" (dưới 1 giờ) cho các chiến dịch đột xuất, điều mà cấu hình chuẩn không hỗ trợ mà không có rủi ro.	2026-07-25	Giám đốc Tài chính (CFO) và Trưởng phòng Mua hàng	Quyết định: Giữ nguyên quy trình chuẩn để đảm bảo tuân thủ. Các trường hợp khẩn cấp của Marketing sẽ được Trưởng phòng Mua hàng xử lý ngoại lệ thủ công và ghi nhận. Không thay đổi cấu hình hệ thống.	2026-07-28

Ma trận truy vết yêu cầu (Requirements Traceability Matrix - RTM)

Ma trận Truy vết Yêu cầu, hay RTM, là một công cụ lập bản đồ mối quan hệ giữa các đối tượng (artifact) trong vòng đời dự án, từ nhu cầu kinh doanh ban đầu đến ca kiểm thử cuối cùng. Mục đích là đảm bảo mọi yêu cầu đều được hiện thực hóa và kiểm thử, và mọi nỗ lực phát triển đều có thể truy ngược về một mục tiêu kinh doanh đã được xác định. Việc này giúp kiểm soát phạm vi, tránh phát triển các tính năng thừa ("gold plating"), và chứng minh rằng hệ thống đáp ứng đúng nhu cầu.

Bảng dưới đây là một ví dụ RTM cho hai luồng yêu cầu trong dự án ERP của Nova Foods, sử dụng các mã định danh (ID) được quản lý trong sổ đăng ký của dự án mô phỏng (/01-curriculum/TRACEABILITY_ID_REGISTRY.md).

ID Nhu cầu (NEED)	ID Yêu cầu (REQ)	ID Quy tắc (BR)	Tiêu chí Chấp nhận (AC)	Dữ liệu/API (DATA/API)	Ca kiểm thử (TC)	ID Lỗi (DEF)	ID Yêu cầu Thay đổi (CR)
NEED-ACC-001: Tự động hóa tính thuế GTGT để giảm sai sót và đảm bảo tuân thủ.	REQ-FN-FIN-003: Hệ thống phải tính thuế GTGT 10% cho các mặt hàng chịu thuế trong hóa đơn bán hàng.	BR-TAX-001: Thuế GTGT là 10% cho hàng hóa không thuộc danh mục miễn thuế. BR-FIN-005: Số tiền làm tròn đến đơn vị đồng gần nhất.	AC-FIN-003.1: Với hóa đơn có một mặt hàng giá 100,000 VND, thuế GTGT phải là 10,000 VND. AC-FIN-003.2: Với mặt hàng miễn thuế, thuế GTGT là 0 VND.	DATA-INV-015 (Invoice.totalVatAmount), DATA-PROD-007 (Product.isVatExempt), API-INV-001 (POST /invoices)	TC-FN-FIN-012: Kiểm tra tính thuế cho mặt hàng chịu thuế. TC-FN-FIN-013: Kiểm tra hóa đơn chỉ có mặt hàng miễn thuế.	DEF-FIN-1098: Lỗi làm tròn sai khi tổng tiền lẻ dưới 500 VND. (Đã sửa ở build v1.2.3-alpha).	CR-FIN-2025-045: Yêu cầu ban đầu để tự động hóa quy trình thủ công.
NEED-OPS-004: Đảm bảo quy trình xuất hóa đơn nhanh chóng để không làm gián đoạn hoạt động bán hàng tại quầy.	REQ-NFN-PERF-001: Hệ thống phải tạo và hoàn tất một hóa đơn (10+ dòng) trong vòng dưới 500 mili giây ở P95.	Không áp dụng	AC-PERF-001.1: Dưới tải mô phỏng 50 người dùng đồng thời, thời gian phản hồi API tạo hóa đơn phải < 500ms cho 95% yêu cầu.	API-INV-001 (POST /invoices)	TC-NFN-PERF-005: Chạy kịch bản kiểm thử tải với 50 VUs trong 10 phút, xác minh thời gian phản hồi P95.	Không áp dụng	Không áp dụng

Ma trận này minh họa truy vết hai chiều (bidirectional traceability). Theo chiều xuôi, ta có thể thấy nhu cầu NEED-ACC-001 được phân rã thành yêu cầu REQ-FN-FIN-003, được chi tiết hóa bởi quy tắc BR-TAX-001, và được xác minh bởi ca kiểm thử TC-FN-FIN-012. Theo chiều ngược, nếu một tester phát hiện lỗi DEF-FIN-1098, họ có thể truy ngược lại ca kiểm thử đã thất bại, từ đó tìm ra yêu cầu và nhu cầu kinh doanh gốc bị ảnh hưởng. Điều này đảm bảo tính minh bạch và trách nhiệm giải trình trong suốt quá trình phát triển.

Bảng Quyết Định (Decision Table) cho Logic Chiết Khấu Đơn Hàng

Bảng quyết định là một kỹ thuật phân tích nghiệp vụ dùng để trình bày các quy tắc nghiệp vụ (business rules) phức tạp một cách rõ ràng và đầy đủ. Kỹ thuật này được mô tả trong BABOK Guide, giúp Business Analyst xác định các điều kiện (conditions) và các hành động (actions) tương ứng. Thay vì viết văn xuôi dài dòng, bảng quyết định nhóm các quy tắc lại với nhau, đảm bảo không có trường hợp nào bị bỏ sót hay mâu thuẫn. Đây là bằng chứng quan trọng cho thấy logic nghiệp vụ đã được định nghĩa rõ ràng và sẵn sàng để đội kỹ thuật phát triển và kiểm thử.

Trong bối cảnh hệ thống ERP của Nova Foods (dữ liệu mô phỏng), bảng quyết định dưới đây đặc tả logic tính chiết khấu tự động cho các đơn hàng bán. Nó là một phần bằng chứng cho yêu cầu REQ-SALES-015: Hệ thống phải tự động áp dụng chiết khấu theo số lượng và loại khách hàng. Bảng này cũng là phần diễn giải chi tiết cho quy tắc nghiệp vụ BR-SODISC-001: Quy tắc chiết khấu đơn hàng bán.

Bảng Quyết Định: BR-SODISC-001

Mã Quy Tắc	Điều kiện: Loại khách hàng	Điều kiện: Số lượng đặt (đơn vị)	Điều kiện: Danh mục sản phẩm	Hành động: Áp dụng chiết khấu (%)	Hành động: Ghi chú hệ thống
R1	Bán sỉ	> 500	Thành phẩm	10.0	Chiết khấu cấp cao nhất cho đối tác bán sỉ.
R2	Bán sỉ	101 - 500	Thành phẩm	5.0	Chiết khấu cấp trung bình cho đối tác bán sỉ.
R3	Bán sỉ	<= 100	Thành phẩm	0.0	Không đủ số lượng tối thiểu.
R4	Bán lẻ	> 50	Thành phẩm	3.0	Chiết khấu khuyến khích cho khách hàng lẻ.
R5	Bán lẻ	<= 50	Thành phẩm	0.0	Không đủ số lượng tối thiểu.
R6	-	-	!= 'Thành phẩm'	0.0	Sản phẩm không thuộc danh mục được chiết khấu.

Bảng này là nguồn chân lý (source of truth) cho logic chiết khấu. Mỗi cột "Điều kiện" là một yếu tố đầu vào, và mỗi cột "Hành động" là kết quả đầu ra mong muốn. Ký tự - trong quy tắc R6 có nghĩa là "không quan tâm" (don't care), tức là quy tắc đó được áp dụng bất kể giá trị của điều kiện tương ứng là gì. Việc sử dụng bảng đảm bảo tất cả các tổ hợp chính đã được xem xét, bao gồm cả trường hợp ngoại lệ (R6 - sản phẩm không được áp dụng chiết khấu). Bảng này trở thành Test Basis (cơ sở kiểm thử) — một thuật ngữ từ ISTQB — cho phép đội QA tạo các ca kiểm thử (Test Cases) có độ bao phủ cao mà không cần phải suy diễn lại yêu cầu.

Bảng Truy Vết Nguồn Gốc và Phụ Thuộc

Bảng dưới đây minh họa cách bảng quyết định này kết nối với các artifact khác trong dự án, đảm bảo tính truy vết từ đầu đến cuối (end-to-end traceability).

Loại liên kết	ID Tham chiếu	Diễn giải
Nguồn gốc Yêu cầu (derived from)	REQ-SALES-015	Bảng này cụ thể hóa yêu cầu nghiệp vụ về việc tính chiết khấu tự động.
Chi tiết hóa Quy tắc (details)	BR-SODISC-001	Bảng này là định nghĩa chi tiết, có thể thực thi của quy tắc nghiệp vụ tổng quát về chiết khấu.
Cơ sở cho Tiêu chí Chấp nhận (basis for)	AC-SALES-015-01 đến AC-SALES-015-06	Mỗi quy tắc từ R1 đến R6 tương ứng trực tiếp với một Tiêu chí Chấp nhận (Acceptance Criterion).
Cơ sở cho Kiểm thử (basis for)	TC-SALES-DISC-P-001 đến P-005, TC-SALES-DISC-N-001	Các quy tắc là cơ sở để thiết kế các ca kiểm thử dương tính (positive) và âm tính (negative).
Phụ thuộc Dữ liệu (depends on)	DATA-API-SalesOrder-v1.2	Các điều kiện trong bảng yêu cầu các trường dữ liệu (customerType, orderQuantity, productCategory) từ API hoặc cấu trúc dữ liệu của đơn hàng.

5. Tier 4 – Cổng Chất lượng của Senior BA

Cổng chất lượng này là bước kiểm soát cuối cùng của Senior Business Analyst (BA) trước khi một tài liệu được xem xét để baseline (phiên bản nền được công nhận). Mục đích là phát hiện các lỗi nghiêm trọng về cấu trúc, tính nhất quán và khả năng truy vết trước khi chúng gây ra chi phí lớn hơn ở giai đoạn sau. Đây không phải là phê duyệt nội dung mà là kiểm tra tính sẵn sàng của tài liệu.

5.1. Checklist Đánh giá Chất lượng

Bảng dưới đây định nghĩa các hạng mục kiểm tra, tiêu chí đạt/không đạt, và hành động xử lý cần thiết. Mỗi mục không đạt cần được ghi nhận và xử lý trước khi tài liệu có thể đi tiếp.

Mã	Hạng mục	Nội dung kiểm tra	Tiêu chí Đạt (Pass)	Tiêu chí Không Đạt (Fail) & Hành động
QG-DEP-01	Tính đầy đủ (Completeness)	Tất cả các phần trong template (Tier 2) đã được điền đầy đủ trong bản sao (Tier 3) chưa? Có còn placeholder, TODO, TBD không?	Mọi trường bắt buộc đều có dữ liệu mô phỏng Nova Foods cụ thể. Không có placeholder trống hoặc ghi chú chưa hoàn thành.	Còn placeholder hoặc nội dung bị bỏ trống. Hành động: FAIL. Trả lại cho người soạn để hoàn thiện.
QG-DEP-02	Tính nhất quán (Consistency)	Thuật ngữ, ID, và quy tắc nghiệp vụ có nhất quán với các artifact đã được kiểm soát khác không (ví dụ: CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY)?	Mọi ID (REQ-, BR-, AC-) khớp với registry. Thuật ngữ (Customer, Sales Order) được dùng thống nhất.	ID không tồn tại hoặc sai. Thuật ngữ mâu thuẫn giữa các phần. Hành động: FAIL. Yêu cầu người soạn đồng bộ lại với nguồn canonical.
QG-DEP-03	Khả năng kiểm thử (Testability)	Tiêu chí Chấp nhận (Acceptance Criteria) có rõ ràng, đo lường được, và không mơ hồ không? QA có thể viết test case trực tiếp từ đó mà không cần suy diễn không?	Mỗi AC là một khẳng định có thể kiểm tra (đúng/sai) với đầu vào và kết quả mong đợi rõ ràng. Không chứa các từ mơ hồ như "dễ sử dụng", "nhanh", "linh hoạt".	AC mô tả ý định ("hệ thống nên...") thay vì kết quả có thể xác minh ("hệ thống sẽ..."). Hành động: STOP. Yêu cầu viết lại AC. Đây là lỗi chặn (blocker).
QG-DEP-04	Truy vết (Traceability)	Có thể truy vết từ đầu-cuối (end-to-end traceability) từ yêu cầu (REQ-ID) đến quy tắc (BR-ID), tiêu chí (AC-ID), và dữ liệu (DATA-ID) không? Bảng truy vết có đầy đủ không?	Mọi yêu cầu đều có liên kết đến nguồn gốc và các artifact phát sinh. Không có thành phần "mồ côi" (orphan).	Liên kết truy vết bị đứt hoặc thiếu. Bảng truy vết sai. Hành động: STOP. Yêu cầu bổ sung và xác minh lại toàn bộ chuỗi. Lỗi nghiêm trọng.
QG-DEP-05	Thẩm quyền nguồn (Source Authority)	Các quy tắc liên quan đến pháp lý (Luật Kế toán), thuế, hoặc an toàn thực phẩm có được ghi rõ là Verification required và chỉ định Owner có thẩm quyền không?	Nguồn gốc yêu cầu được trích dẫn rõ ràng. Phân định rạch ròi giữa quy tắc nghiệp vụ và diễn giải pháp lý/kế toán.	BA tự diễn giải luật hoặc quy định kế toán. Không trích dẫn nguồn chính thức. Hành động: ESCALATE. Chuyển cho Legal/Accounting Owner để xác nhận. BA không có thẩm quyền này.
QG-DEP-06	Ranh giới & Bảo mật (Boundaries & Security)	Các yêu cầu có tạo ra rủi ro về bảo mật hoặc quyền riêng tư không? Có xử lý dữ liệu cá nhân mà không tuân thủ Luật Bảo vệ dữ liệu cá nhân không?	Các trường dữ liệu nhạy cảm được xác định. Các yêu cầu về quyền truy cập được định nghĩa. Tham chiếu đến chuẩn (ví dụ: OWASP ASVS) khi phù hợp.	Yêu cầu ngầm định lưu trữ mật khẩu dạng plain text hoặc hiển thị dữ liệu cá nhân không cần thiết. Hành động: ESCALATE. Chuyển cho Security/Data Privacy Owner. Lỗi nghiêm trọng.
QG-DEP-07	Tác động thay đổi (Change Impact)	Phân tích tác động của thay đổi tới các hệ thống, quy trình hoặc vai trò người dùng khác đã được thực hiện và ghi nhận chưa?	Tài liệu có mục riêng hoặc tham chiếu đến tài liệu phân tích tác động, chỉ rõ các khu vực bị ảnh hưởng và mức độ.	Thay đổi được mô tả như một chức năng độc lập, bỏ qua các hệ thống tích hợp hoặc quy trình nghiệp vụ liên quan. Hành động: STOP. Yêu cầu thực hiện và ghi nhận phân tích tác động.

5.2. Định nghĩa các hành động

• FAIL (Không đạt): Lỗi nhỏ, có thể sửa chữa nhanh mà không cần thay đổi cấu trúc hay logic cốt lõi. Người soạn tự sửa và gửi lại để kiểm tra lại.
• STOP (Dừng): Lỗi nghiêm trọng, mang tính cấu trúc hoặc logic. Toàn bộ quy trình tạm dừng. Cần phải làm lại (rework) phần bị lỗi, không chỉ sửa chi tiết.
• ESCALATE (Chuyển cấp): Vấn đề vượt quá thẩm quyền của nhóm dự án (BA, Dev, QA). Cần chuyển lên cấp quản lý cao hơn hoặc các bên liên quan có thẩm quyền (ví dụ: Legal, Head of Department, Architect) để ra quyết định.

Các Hạng mục và Tiêu chí Đánh giá Chất lượng

Bảng này là checklist chất lượng cho cổng soát xét Tier 4. Dùng để soát xét tài liệu đã điền ở Tier 3 dựa trên các khía cạnh chất lượng theo tiêu chuẩn phân tích nghiệp vụ. Mỗi mục phải được kiểm tra kỹ lưỡng.

Hạng mục	Tiêu chí cốt lõi	Nguồn kiểm tra tham chiếu	Diễn giải và ví dụ (Case study Nova Foods)
Tính đầy đủ (Completeness)	Mọi trường, mục, quyết định trong mẫu Tier 3 phải được điền đầy đủ. Không có placeholder như TBD, N/A không giải thích, hoặc ô trống.	Toàn bộ tài liệu TMPL-DEP-001 đã điền ở Tier 3.	Đạt: Mục Deployment Window ghi rõ 2026-10-26 22:00 đến 2026-10-27 02:00 Asia/Ho_Chi_Minh. Không đạt: Mục Rollback Plan bị bỏ trống.
Tính nhất quán (Consistency)	Thuật ngữ, định danh, và quy tắc nghiệp vụ phải đồng nhất với các nguồn canonical của corpus.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	Đạt: Tài liệu tham chiếu BR-INV-005: Deny order if stock is insufficient khớp với định nghĩa trong CANONICAL_BUSINESS_RULES. Không đạt: Dùng thuật ngữ "Mã sản phẩm" trong khi CANONICAL_DATA_DICTIONARY định nghĩa là SKU.
Tính khả kiểm (Testability)	Mỗi yêu cầu chức năng hoặc tiêu chí chấp nhận (acceptance criterion) phải cụ thể, đo lường được, và có thể xác minh bằng một kịch bản kiểm thử.	Mục Acceptance Criteria trong tài liệu. Tiêu chuẩn ISTQB CTFL.	Khả kiểm: "Hệ thống phải tính thuế GTGT 10% cho các mặt hàng chịu thuế." Không khả kiểm: "Giao diện phải dễ sử dụng."
Tính truy vết (Traceability)	Mọi yêu cầu, rủi ro, và quyết định phải có liên kết rõ ràng ngược về nguồn gốc (yêu cầu nghiệp vụ, quyết định họp, quy định pháp luật).	Mục Evidence and Traceability. TRACEABILITY_ID_REGISTRY.	Đạt: Yêu cầu REQ-FIN-001 có traceability ID liên kết đến Luật Kế toán 88/2015/QH13. Không đạt: Một rủi ro được liệt kê mà không có nguồn gốc hay ID định danh.
Thẩm quyền nguồn (Source Authority)	Nguồn của một quy tắc phải có thẩm quyền phù hợp với bản chất của quy tắc đó.	/00-research/00_SOURCE_MAP.md.	Đúng: Yêu cầu về truy xuất nguồn gốc thực phẩm tham chiếu Luật An toàn thực phẩm 55/2010/QH12. Sai: Yêu cầu về định dạng hóa đơn điện tử lại tham chiếu một bài viết trên blog thay vì Nghị định 123/2020/NĐ-CP.
Quyền sở hữu (Ownership)	Mỗi quyết định nghiệp vụ, rủi ro, và yêu cầu phải có một chủ sở hữu (Owner) được chỉ định rõ ràng từ phía nghiệp vụ hoặc kỹ thuật.	Mục Stakeholders và các trường Owner trong tài liệu.	Đạt: "Quyết định về chính sách giá khuyến mãi" có Owner là Business Owner – Head of Sales. Không đạt: "Quyết định về cấu trúc API" không có Owner được chỉ định.
Ranh giới (Boundaries)	Các yêu cầu liên quan đến an ninh (Security), quyền riêng tư (Privacy), pháp lý (Legal), và kế toán (Accounting) phải được xác định rõ ràng, đánh dấu và có ghi chú cần xác minh từ vai trò có thẩm quyền.	/00-research/00_SOURCE_MAP.md (đặc biệt là các luật, nghị định, và tiêu chuẩn như OWASP).	Đạt: Yêu cầu lưu trữ dữ liệu cá nhân khách hàng được đánh dấu Privacy Impact và có ghi chú Verification required from Legal Owner cùng tham chiếu Luật 91/2025/QH15.
Tác động thay đổi (Change Impact)	Phân tích tác động của việc triển khai đến các hệ thống, quy trình nghiệp vụ, và nhóm người dùng liên quan phải được hoàn thành và ghi nhận.	Mục Impact Analysis trong tài liệu.	Đạt: Ghi rõ "Thay đổi API GET /api/v2/inventory sẽ ảnh hưởng đến hệ thống Báo cáo Kho vận" và có kế hoạch thông báo cho các bên liên quan. Không đạt: Chỉ ghi chung chung "Có thể ảnh hưởng hệ thống khác".

Kết quả áp dụng checklist cho case study Nova Foods

Bảng dưới đây ghi nhận kết quả xem xét của Senior BA đối với nội dung ví dụ Nova Foods đã hoàn thiện (Tier 3), dựa trên checklist chất lượng đã định nghĩa. Việc xem xét này không cấu thành phê duyệt baseline.

ID Kiểm tra	Hạng mục kiểm tra	Kết quả tìm thấy	Bằng chứng / Lý do	Trạng thái
QG-NF-01	Tính đầy đủ (Completeness)	Trường deployment_window_utc trong bảng Core Record (Mục 3) bị bỏ trống.	Mẫu Tier 2 yêu cầu trường này để xác định khung giờ triển khai theo giờ quốc tế. Kế hoạch triển khai không có thông tin này là không đầy đủ.	CẦN LÀM RÕ
QG-NF-02	Tính nhất quán (Consistency)	version (v0.9.0) và status (IN_REVIEW) trong metadata của Tier 3 khớp với các manifest quản trị của corpus.	Dữ liệu khớp với TEMPLATE_MANIFEST và 01_CURRICULUM_ARCHITECTURE.md. Điều này đảm bảo tính nhất quán quản trị trong toàn bộ hệ thống tài liệu.	ĐẠT
QG-NF-03	Tính có thể kiểm thử (Testability)	Tiêu chí chấp nhận AC-NF-DEP-005.1 ("Quy trình rollback phải hoàn tất trong vòng 5 phút") có thể kiểm thử được.	Tiêu chí này có định lượng rõ ràng (thời gian <= 5 phút, trạng thái "hoàn tất"), cho phép QA viết test case chính xác. Phù hợp nguyên tắc SMART và hướng dẫn của ISTQB.	ĐẠT
QG-NF-04	Truy vết (Traceability)	Yêu cầu REQ-NF-DEP-011 (lưu trữ log truy cập) chưa có liên kết truy vết (traceability link) trực tiếp đến điều khoản pháp lý cụ thể.	Mục 4 (Bằng chứng và Truy vết) chỉ ghi nguồn là "Tuân thủ Luật Bảo vệ dữ liệu cá nhân", nhưng không trỏ đến ID quy tắc trong CANONICAL_BUSINESS_RULES hoặc điều khoản của Luật 91/2025/QH15. Thiếu truy vết làm tăng rủi ro diễn giải sai hoặc bỏ sót nghĩa vụ.	CẦN LÀM RÕ
QG-NF-05	Thẩm quyền nguồn (Source Authority)	Yêu cầu REQ-NF-DEP-012 trích dẫn OWASP API Security Top 10 làm nguồn cho một nghĩa vụ pháp lý.	OWASP API Security Top 10 là một good practice (thực hành tốt) của ngành, không phải văn bản pháp quy tại Việt Nam. 00_SOURCE_MAP.md đã phân định ranh giới này. Yêu cầu pháp lý phải trích dẫn luật gốc (ví dụ: Luật An toàn thông tin mạng), còn OWASP chỉ nên dùng làm tham chiếu kỹ thuật.	KHÔNG ĐẠT
QG-NF-06	Quyền sở hữu (Ownership)	Vai trò "Deployment Approver" được ghi là "Business Owner", không có định danh cá nhân hay chức danh cụ thể.	"Business Owner" là một vai trò chung. Để có thể hành động, cần xác định rõ ai là người có thẩm quyền phê duyệt cuối cùng (ví dụ: NF-COO-01, Chief Operating Officer). Thiếu sự rõ ràng này gây rủi ro cho quá trình phê duyệt thật.	CẦN LÀM RÕ
QG-NF-07	Ranh giới (Boundaries)	Quyết định DEC-NF-DEP-003 về thời gian lưu trữ dữ liệu tài chính (5 năm) chưa có xác nhận từ vai trò Kế toán.	Thời gian lưu trữ chứng từ, sổ sách kế toán bị chi phối trực tiếp bởi Luật Kế toán. Quyết định này thuộc thẩm quyền của Kế toán trưởng (Accounting Owner), không phải của nhóm dự án. Cần có bằng chứng xác nhận.	KHÔNG ĐẠT
QG-NF-08	Tác động thay đổi (Change Impact)	Phân tích tác động thay đổi xác định ảnh hưởng đến "Nhóm Kho vận" nhưng chưa có kế hoạch hành động cụ thể.	Tài liệu chỉ ghi "cần đào tạo" mà không có kế hoạch chi tiết (ví dụ: nội dung, thời lượng, người phụ trách, lịch trình). Một kế hoạch sẵn sàng triển khai đòi hỏi mức độ chi tiết cao hơn để đảm bảo người dùng cuối sẵn sàng.	CẦN LÀM RÕ

Kết luận tổng hợp: Tài liệu ví dụ Nova Foods (Tier 3) đã đáp ứng một số tiêu chí chất lượng cơ bản về tính nhất quán và khả năng kiểm thử. Tuy nhiên, nhiều điểm quan trọng liên quan đến thẩm quyền nguồn, ranh giới pháp lý/kế toán, truy vết và tính đầy đủ cần được làm rõ hoặc sửa đổi. Tài liệu chưa sẵn sàng để được xem xét baseline. Các điểm KHÔNG ĐẠT và CẦN LÀM RÕ phải được giải quyết trước khi chuyển sang bước tiếp theo.

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

Kiểm tra chéo (cross-file check) là rà soát mâu thuẫn giữa tài liệu này và các nguồn thông tin canonical (nguồn chuẩn) khác trong corpus. Mục đích: đảm bảo tính nhất quán, phát hiện sai lệch sớm. Một quyết định trong tài liệu này không được trái với quy tắc, định danh, hoặc định nghĩa đã được kiểm soát ở nơi khác.

6.1. Bảng Kiểm tra Chéo

Bảng này ghi lại kết quả rà soát tài liệu TMPL-DEP-001_deployment-readiness.md với các artifact quản trị trung tâm của dự án mô phỏng Nova Foods.

ID Kiểm tra	Artifact Nguồn Tham chiếu	Điểm Kiểm tra Chính	Kết quả cho TMPL-DEP-001	Bằng chứng / Lý do
XF-NF-01	/01-curriculum/TEMPLATE_MANIFEST.md	Nhất quán Phiên bản và Trạng thái	ĐẠT	Trạng thái IN_REVIEW và phiên bản v0.9.0 của tài liệu này khớp với metadata được ghi nhận trong TEMPLATE_MANIFEST. Không có mâu thuẫn về quản trị phiên bản.
XF-NF-02	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Đăng ký Định danh (ID)	CẦN XÁC MINH	Phần 5 sử dụng các ID như QG-NF-07 và DEC-NF-DEP-003. Cần đối chiếu với TRACEABILITY_ID_REGISTRY để xác nhận chúng đã được đăng ký và tuân thủ quy tắc định dạng. Registry đang ở dạng kế hoạch, chưa có dữ liệu cuối.
XF-NF-03	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nhất quán Quy tắc Nghiệp vụ	MÂU THUẪN	Điểm QG-NF-07 tại Phần 5 đề cập quyết định DEC-NF-DEP-003 (lưu trữ dữ liệu 5 năm) mà không có xác nhận từ vai trò Kế toán. Điều này mâu thuẫn với nguyên tắc của CANONICAL_BUSINESS_RULES yêu cầu mọi quy tắc phải có owner nghiệp vụ được ủy quyền xác nhận.
XF-NF-04	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Nhất quán Định nghĩa Dữ liệu	CẦN XÁC MINH	Tài liệu này ngầm định sự tồn tại của các trạng thái sẵn sàng triển khai. Cần kiểm tra CANONICAL_DATA_DICTIONARY để đảm bảo các trường dữ liệu liên quan (ví dụ: deployment_status) và bộ giá trị của chúng (enum) được định nghĩa và sử dụng nhất quán.
XF-NF-05	Các artifact hạ nguồn (Downstream Artifacts)	Tác động đến người dùng cuối	MÂU THUẪN	Điểm QG-NF-08 tại Phần 5 chỉ ghi "cần đào tạo", không đủ chi tiết. Điều này tạo ra vấn đề cho các nhóm hạ nguồn (ví dụ: nhóm soạn tài liệu đào tạo) vì họ thiếu đầu vào để làm việc. Yêu cầu "sẵn sàng" của tài liệu này mâu thuẫn với sự thiếu hụt thông tin cho các bước tiếp theo.

Kết luận kiểm tra chéo: Phát hiện hai mâu thuẫn (XF-NF-03, XF-NF-05) và hai điểm cần xác minh (XF-NF-02, XF-NF-04). Các mâu thuẫn này phải được giải quyết. Tài liệu chưa thể chuyển trạng thái hoặc được xem là nguồn đáng tin cậy cho các bước sau cho đến khi các xung đột được xử lý.

Các Vấn Đề Tồn Đọng, Giả Định, và Hạng Mục Cần Xác Minh

Danh sách các vấn đề, giả định và hạng mục cần xác minh tại thời điểm v0.9.0. Các mục này phải được xử lý hoặc chấp nhận rủi ro một cách tường minh trước khi chuyển artifact này ra khỏi trạng thái IN_REVIEW. Một artifact (sản phẩm công việc được kiểm soát, ví dụ: một tài liệu, sơ đồ, hoặc tệp mã nguồn) được coi là đã baseline khi nó được xem xét, đồng thuận, và "đóng băng" tại một phiên bản cụ thể để làm tham chiếu chính thức.

ID	Loại	Mô tả chi tiết	Artifacts Bị Ảnh Hưởng	Người Chịu Trách Nhiệm (Owner)	Mức Độ Ảnh Hưởng	Hành Động Tiếp Theo
ASSUMP-DEP-001	Giả định	Toàn bộ corpus, bao gồm các manifest và nguồn canonical, đang ở trạng thái IN_REVIEW phiên bản v0.9.0. Không có nội dung nào được baseline hay phê duyệt chính thức.	Toàn bộ corpus, bao gồm TMPL-DEP-001, CHAPTER_MANIFEST, TEMPLATE_MANIFEST.	Principal IT Business Analyst / Technical Curriculum Author	Cao	Duy trì trạng thái IN_REVIEW trên mọi artifact đầu ra. Truyền thông rõ trạng thái này trong mọi hoạt động chuyển giao.
VERIFY-DEP-001	Cần xác minh	Các artifact canonical (TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY) đều là các kế hoạch (plan), không phải nguồn đã hoàn thiện. Mọi quy tắc, ID hoặc trường dữ liệu cụ thể được dùng trong template này đều là tạm thời.	TMPL-DEP-001, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.	Business Owner, Technical Architect	Cao	Trước khi chuyển template từ IN_REVIEW sang BASELINED, tất cả quy tắc, ID và định nghĩa dữ liệu được tham chiếu phải được xác nhận và baseline trong artifact canonical tương ứng của chúng.
VERIFY-DEP-002	Cần xác minh	Mọi yêu cầu phát sinh từ luật và quy định của Việt Nam (ví dụ: Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm 55/2010/QH12) chỉ là diễn giải cho mục đích giáo dục, không phải nghĩa vụ pháp lý ràng buộc cho Nova Foods.	TMPL-DEP-001 (các phần liên quan tuân thủ), CANONICAL_BUSINESS_RULES.	Legal Owner, Accounting Owner, Compliance Owner	Cao	Tất cả yêu cầu liên quan đến tuân thủ được tạo ra từ template này phải được xem xét và phê duyệt chính thức bởi các vai trò pháp lý và kế toán được chỉ định trước khi đưa vào bất kỳ kế hoạch triển khai production nào.
VERIFY-DEP-003	Cần xác minh	Dữ liệu tài chính và tồn kho cho "Biên bản nhập kho" (GRN-2026-08-4311) và "Nhà cung cấp" (SUP-VNVN-0018) là dữ liệu tổng hợp chỉ dành cho mục đích minh họa. Các giá trị (ví dụ: 1,848,000,000 VND, đơn giá) không dựa trên giá thị trường hoặc hồ sơ kế toán thực tế.	TMPL-DEP-001 (Mục 3 và 4, nơi dữ liệu này được sử dụng).	Business Owner, Accounting Owner	Trung bình	Đảm bảo tất cả các bên liên quan hiểu rằng dữ liệu này hoàn toàn là mô phỏng. Đối với bất kỳ ứng dụng nào trong thế giới thực, phải thay thế bằng dữ liệu đã được xác thực từ các hệ thống tài chính/mua hàng thực tế.

Quy tắc Chuyển giao, Lan truyền Thay đổi, và Bảo toàn Thẩm quyền

Phần này xác định cơ chế chuyển giao có kiểm soát cho tài liệu khi đang ở trạng thái IN_REVIEW. Mục tiêu là cho phép các nhóm downstream (phụ thuộc) như Kiểm thử (QA) và Phát triển (Development) bắt đầu các hoạt động chuẩn bị mà không sử dụng các yêu cầu, quy tắc hoặc dữ liệu chưa được phê duyệt chính thức. Quy trình này bảo toàn các ranh giới thẩm quyền và đảm bảo mọi thay đổi được lan truyền một cách minh bạch, có truy vết.

Bảng 1: Quy tắc Chuyển giao Artifact ở trạng thái IN_REVIEW

Việc chuyển giao này chỉ nhằm mục đích thông tin và chuẩn bị, không phải là một chỉ thị để triển khai.

Vai trò nhận	Hoạt động được phép (Permitted Activities)	Hoạt động bị cấm (Prohibited Activities)
Trưởng nhóm Kiểm thử (QA Lead) và nhóm	Đọc và phân tích tài liệu để lập kế hoạch kiểm thử (test plan), xác định các kịch bản kiểm thử (test scenario) và viết các ca kiểm thử (test case) nháp.	Thực thi kiểm thử (test execution) trên bất kỳ môi trường nào. Coi các tiêu chí chấp nhận (acceptance criteria) là cuối cùng. Báo cáo lỗi (bug) dựa trên phiên bản IN_REVIEW.
Trưởng nhóm Phát triển (Development Lead) và nhóm	Đọc tài liệu để ước tính sơ bộ (preliminary estimation), xác định các phụ thuộc kỹ thuật (technical dependencies), và lên kế hoạch cho các hoạt động nghiên cứu (spike/investigation).	Viết mã nguồn cho môi trường production hoặc staging. Tạo các cấu trúc dữ liệu trong cơ sở dữ liệu. Cam kết về ngày hoàn thành dựa trên tài liệu này.
Business Analyst (BA) liên quan	Xem xét để phát hiện các ảnh hưởng chéo (cross-functional impact) với các phân hệ hoặc dự án khác. Góp ý về tính nhất quán và đầy đủ.	Phê duyệt hoặc bác bỏ các yêu cầu ngoài phạm vi thẩm quyền của mình. Tự ý sao chép quy tắc nghiệp vụ sang các tài liệu canonical khác.

Bảng 2: Quy trình Lan truyền Thay đổi (Change Propagation Protocol)

Mọi thay đổi trên artifact này trong khi đang IN_REVIEW phải tuân thủ quy trình dưới đây để đảm bảo tính nhất quán.

Kích hoạt (Trigger)	Hành động của Owner Artifact	Nội dung Thông báo Thay đổi	Kênh Phân phối	Trách nhiệm của Người nhận
Owner thực hiện một commit thay đổi nội dung của tệp TMPL-DEP-001_deployment-readiness.md.	Tạo một "Bản ghi Thông báo Thay đổi" (Change Notification Record) và cập nhật phiên bản phụ của artifact (ví dụ: từ v0.9.0 lên v0.9.1).	- Artifact ID: TMPL-DEP-001 - Phiên bản cũ: v0.9.0 - Phiên bản mới: v0.9.1 - Tóm tắt thay đổi: Mô tả ngắn gọn các mục đã được thêm, sửa, hoặc xóa. - Danh sách ID bị ảnh hưởng: Liệt kê ID của quy tắc, yêu cầu, trường dữ liệu bị thay đổi.	Kênh MS Teams hoặc Jira board được chỉ định cho dự án Nova Foods ERP.	Các vai trò nhận được liệt kê ở Bảng 1 phải xác nhận đã nhận được thông báo. Việc xác nhận này chỉ ghi nhận đã biết về sự thay đổi, không có nghĩa là đồng ý hay phê duyệt.

Bảo toàn Trạng thái và Ranh giới Thẩm quyền

Việc áp dụng các quy tắc trên không làm thay đổi trạng thái của artifact từ IN_REVIEW sang bất kỳ trạng thái nào khác (ví dụ: BASELINED hay APPROVED). Việc thay đổi trạng thái phải thông qua một quy trình phê duyệt chính thức, có sự tham gia của các vai trò có thẩm quyền được định nghĩa dưới đây.

Bảng 3: Phân định Thẩm quyền Xác nhận Nội dung

Business Analyst chịu trách nhiệm ghi nhận và diễn giải yêu cầu, nhưng việc xác nhận cuối cùng thuộc về các vai trò có thẩm quyền chuyên môn.

Lĩnh vực Chuyên môn	Vai trò có Thẩm quyền Xác nhận	Yêu cầu Bắt buộc trước khi Baseline/Approve
Pháp lý và Tuân thủ (ví dụ: Luật Bảo vệ dữ liệu cá nhân)	Giám đốc Pháp chế (Legal Counsel) / Cán bộ Bảo vệ Dữ liệu (DPO)	Phải có xác nhận bằng văn bản rằng các yêu cầu liên quan tuân thủ đúng quy định pháp luật hiện hành.
Kế toán và Thuế (ví dụ: Luật Kế toán, Nghị định 123/2020/NĐ-CP)	Kế toán trưởng (Chief Accountant)	Phải có xác nhận bằng văn bản rằng các quy tắc nghiệp vụ và luồng dữ liệu tài chính phù hợp với chuẩn mực kế toán và quy định thuế của Việt Nam.
An toàn Thực phẩm và Truy xuất Nguồn gốc (ví dụ: Luật An toàn thực phẩm)	Trưởng phòng Quản lý Chất lượng (Head of Quality Assurance/Compliance)	Phải có xác nhận bằng văn bản rằng các yêu cầu về truy xuất nguồn gốc đáp ứng tiêu chuẩn ngành và quy định pháp luật.
Kiến trúc Hệ thống và Tích hợp	Kiến trúc sư Giải pháp (Solution Architect)	Phải có xác nhận rằng các yêu cầu phi chức năng (non-functional requirements) và mô hình dữ liệu là khả thi về mặt kỹ thuật và phù hợp với kiến trúc tổng thể.
Bảo mật Thông tin (ví dụ: OWASP ASVS, OWASP API Security Top 10)	Trưởng phòng An ninh Thông tin (Head of Information Security)	Phải có xác nhận rằng các yêu cầu về kiểm soát truy cập, mã hóa và xử lý dữ liệu nhạy cảm đáp ứng chính sách bảo mật của công ty.