TMPL-OPS-HANDOVER-001: Biểu Mẫu Bàn Giao Vận Hành

Bảng Metadata Quản Trị Artifact (Artifact Governance Metadata)

Bảng này xác định danh tính, phiên bản, chủ sở hữu và các quy tắc quản trị cốt lõi của biểu mẫu. Nó đảm bảo rằng mọi người dùng biểu mẫu đều hiểu rõ nguồn gốc, trạng thái và giới hạn sử dụng của nó.

Trường kiểm soát	Giá trị
Artifact ID	`TMPL-OPS-HANDOVER-001`
Tên tệp	`/03-templates/TMPL-OPS-HANDOVER-001_operational-handover.md`
Tiêu đề	Biểu Mẫu Bàn Giao Vận Hành (Operational Handover 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, tính nhất quán và metadata quản trị của biểu mẫu. Owner đảm bảo rằng biểu mẫu tuân thủ kiến trúc curriculum và các nguyên tắc của corpus Nova Foods, đồng thời quản lý lịch sử thay đổi.
Giới hạn thẩm quyền của Owner	Owner không có quyền tự xác nhận baseline, ghi nhận phê duyệt (approval), diễn giải yêu cầu pháp lý hoặc kế toán, hay đưa ra quyết định vận hành cho Nova Foods. Vai trò này chỉ giới hạn ở việc quản trị học liệu.
Ngày cập nhật gần nhất	`2026-08-07`
Lịch sử thay đổi	Khởi tạo tài liệu tại `v0.9.0` ngày `2026-08-07`. Thiết lập metadata quản trị ban đầu và cấu trúc 4 tầng (Tier 1-4).
Múi giờ quản trị	`Asia/Ho_Chi_Minh`
Locale áp dụng	`vi-VN`; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng `VND`.
Case study áp dụng	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp.
Phân loại Artifact	Biểu mẫu có kiểm soát (Controlled Template)
Trạng thái Baseline	Chưa có baseline reference tại `v0.9.0`. Trạng thái `IN_REVIEW` không được diễn giải là đã được chốt (baselined).
Trạng thái Phê duyệt	Chưa có phê duyệt (approval) được ghi nhận. Sự tồn tại của metadata này không cấu thành phê duyệt ngầm định từ bất kỳ vai trò nào.

Ranh Giới Dữ Liệu Mô Phỏng (Simulated Data Boundary)

Toàn bộ nội dung liên quan đến "Nova Foods Trading & Manufacturing", bao gồm tên nhân viên, vai trò, quy trình, dữ liệu tài chính, thông số kỹ thuật và các quyết định nghiệp vụ, đều là dữ liệu tổng hợp (synthetic data). Chúng được tạo ra hoàn toàn cho mục đích giáo dục trong khuôn khổ curriculum "IT Business Analyst — Zero to Delivery Ready". Các ví dụ và case study không đại diện cho bất kỳ tổ chức, cá nhân hay hoạt động kinh doanh có thật nào. Việc sử dụng chúng bên ngoài mục đích học tập đã định sẵn là không được phép và có thể dẫn đến hiểu lầm.

1. Tier 1 ― Metadata, Purpose, and Governance

Metadata Quản trị Tier 1

Thuộc tính	Giá trị
Template ID	`TMPL-OPS-HANDOVER-001`
Tên tệp	`TMPL-OPS-HANDOVER-001_operational-handover.md`
Đường dẫn canonical	`/03-templates/`
Phiên bản	`v0.9.0`
Trạng thái	`IN_REVIEW`
Owner	`Principal IT Business Analyst`
Phạm vi kiểm soát	Cấu trúc, các mục, bảng biểu và hướng dẫn trong Tier 2 của template.
Hệ quả trạng thái	Artifact chưa được baseline hoặc phê duyệt chính thức. Người sử dụng phải ghi nhận và xem xét mọi thay đổi cấu trúc theo quy trình kiểm soát thay đổi.

Mục đích, Phạm vi và Nguyên tắc Sử dụng

Tài liệu này định nghĩa mục đích, phạm vi và các quy tắc quản trị cho biểu mẫu Chuyển giao Vận hành (Operational Handover). Mục tiêu là thiết lập một quy trình chuẩn hóa, có kiểm soát để bàn giao một hệ thống, tính năng hoặc dịch vụ công nghệ thông tin (CNTT) từ đội ngũ dự án (Project Team) sang đội ngũ vận hành và hỗ trợ (Operations/Support Team). Việc chuẩn hóa đảm bảo đội ngũ vận hành nhận đủ thông tin cần thiết để quản lý, hỗ trợ và duy trì dịch vụ một cách hiệu quả ngay sau khi hệ thống đi vào hoạt động (go-live).

Thành phần	Diễn giải và Quy tắc áp dụng
Mục đích	Cung cấp một bản ghi duy nhất, được kiểm soát (`single source of truth`) cho các thông tin vận hành quan trọng. Biểu mẫu này không thay thế tài liệu yêu cầu, thiết kế hay kiểm thử, mà là một "gói" tổng hợp, trỏ đến các tài liệu đó và bổ sung các hướng dẫn dành riêng cho đội vận hành.
Khi nào sử dụng	Bắt buộc sử dụng biểu mẫu này trong các trường hợp sau: • Trước khi triển khai một hệ thống CNTT mới lên môi trường production. • Trước khi phát hành một phân hệ (module) lớn hoặc một bản nâng cấp quan trọng làm thay đổi quy trình vận hành. • Khi chuyển giao trách nhiệm hỗ trợ một hệ thống từ đội này sang đội khác.
Khi nào KHÔNG sử dụng	Không dùng cho: • Các bản vá lỗi nhỏ (`minor bug fix`) hoặc thay đổi cấu hình không ảnh hưởng đến quy trình vận hành. • Thay thế cho báo cáo tiến độ dự án. • Ghi nhận yêu cầu nghiệp vụ mới. Đây là tài liệu bàn giao, không phải tài liệu thu thập yêu cầu.

Các bên liên quan và Trách nhiệm

Bảng dưới đây xác định các vai trò chính liên quan đến quy trình chuyển giao vận hành.

Vai trò	Trách nhiệm chính trong quy trình
Owner (Chủ sở hữu biểu mẫu)	`Project Manager` hoặc `Lead Business Analyst` của dự án chịu trách nhiệm điền đầy đủ, chính xác và thu thập đủ phê duyệt cho tài liệu này trước khi go-live.
Consumers (Bên tiếp nhận)	• IT Operations/Support Team: Sử dụng tài liệu làm cơ sở để hỗ trợ kỹ thuật, giám sát và xử lý sự cố. • IT Service Desk (Help Desk): Sử dụng thông tin liên hệ và hướng dẫn xử lý cấp 1 (Tier 1).
Authority (Bên phê duyệt)	• Head of IT Operations (hoặc tương đương): Phê duyệt cuối cùng, xác nhận đội vận hành đã sẵn sàng tiếp nhận hệ thống. • Business Owner: Xác nhận các quy trình hỗ trợ và liên hệ khẩn cấp phù hợp với nhu cầu nghiệp vụ.

Yêu cầu đầu vào, Đầu ra và Leo thang

Để đảm bảo quy trình diễn ra suôn sẻ, các điều kiện và quy trình sau phải được tuân thủ.

Hạng mục	Chi tiết
Điều kiện tiên quyết	Biểu mẫu này chỉ được hoàn thiện sau khi các tài liệu sau đã được chốt và sẵn sàng: • Biên bản nghiệm thu người dùng (UAT Sign-off). • Tài liệu đặc tả hệ thống (System Specification) phiên bản cuối. • Kế hoạch triển khai (Deployment Plan). • Sổ tay vận hành (Runbooks) cho các tác vụ phổ biến, ví dụ: `TMPL-OPS-RUNBOOK-001`. • Tài liệu đào tạo người dùng cuối (End-user Training Materials).
Tài liệu đầu ra	Thông tin từ biểu mẫu này sẽ là đầu vào cho: • Các bài viết trong cơ sở tri thức (Knowledge Base) của IT Service Desk. • Cấu hình hệ thống quản lý dịch vụ CNTT (ITSM Tool), ví dụ: tạo mục dịch vụ mới. • Báo cáo Đánh giá sau triển khai (Post-Implementation Review).
Quy trình leo thang	Nếu có bất đồng hoặc thiếu thông tin không thể giải quyết giữa đội dự án và đội vận hành: 1. Cấp 1: `Project Manager` và `Operations Team Lead` trực tiếp giải quyết. 2. Cấp 2: Nếu không thành công, vấn đề được leo thang lên `Project Sponsor` và `Head of IT Operations`. 3. Cấp 3: Quyết định cuối cùng thuộc về Ban chỉ đạo dự án (Steering Committee). Mọi bất đồng phải được giải quyết dứt điểm trước ngày go-live.

Liên kết Quản trị và Truy vết Nguồn gốc

Mẫu này được kiểm soát trong hệ thống quản trị của corpus Nova Foods để đảm bảo tính nhất quán và truy vết. Mọi tham chiếu đến mẫu này phải sử dụng các định danh canonical được quy định.

1. Định danh trong Manifest

Template này được đăng ký chính thức trong TEMPLATE_MANIFEST. Bảng này xác định định danh và vị trí canonical của nó.

Thuộc tính Quản trị	Giá trị Canonical	Nguồn kiểm soát
Template ID	`TMPL-OPS-HANDOVER-001`	`/01-curriculum/TEMPLATE_MANIFEST.md`
Tên tệp	`TMPL-OPS-HANDOVER-001_operational-handover.md`	`/01-curriculum/TEMPLATE_MANIFEST.md`
Đường dẫn	`/03-templates/`	`/01-curriculum/TEMPLATE_MANIFEST.md`
Phân loại	Template Vận hành (Operational Template)	`/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`

2. Liên kết đến Handbook Chapters

Việc sử dụng template này đòi hỏi kiến thức nền tảng từ các chương handbook tương ứng. Hoàn thành template mà không nắm vững các chương này có thể dẫn đến bàn giao không đầy đủ, thiếu sót hoặc sai lệch.

Chapter ID (Giả định)	Tên Chapter (Giả định)	Lý do liên quan
`HB-CH-22`	Quản lý Triển khai và Phát hành (Deployment and Release Management)	Template ghi nhận phiên bản phần mềm được bàn giao, môi trường đích và các kết quả kiểm thử triển khai.
`HB-CH-23`	Quản lý Mức độ Dịch vụ (Service Level Management)	Tài liệu bàn giao phải xác định các Cam kết Mức độ Dịch vụ (SLA) và Chỉ số Hoạt động Chính (KPI) mà đội vận hành cần theo dõi.
`HB-CH-24`	Quản lý Dịch vụ CNTT và Hỗ trợ (ITSM and Support)	Template cấu trúc thông tin cho đội hỗ trợ Tier 1 và Tier 2, bao gồm các kịch bản lỗi thường gặp và quy trình leo thang.
`HB-CH-26`	Quản trị, Rủi ro và Tuân thủ (Governance, Risk, and Compliance)	Cần tham chiếu đến các nghĩa vụ tuân thủ (ví dụ: bảo vệ dữ liệu, an toàn thực phẩm) mà hệ thống được bàn giao phải đáp ứng.

3. Nguồn Chuẩn và Tài liệu Canonical Áp dụng

Cấu trúc và nội dung của template được định hình bởi các tiêu chuẩn ngành và các tài liệu canonical nội bộ. Điều này đảm bảo việc bàn giao tuân thủ các good practice và nhất quán với kiến trúc tổng thể của Nova Foods.

Nguồn tham chiếu	Tổ chức phát hành / ID Artifact	Lý do áp dụng cho việc bàn giao vận hành
BABOK Guide	IIBA	Cung cấp thuật ngữ và khuôn khổ cho việc giao tiếp với các bên liên quan (stakeholders) trong quá trình bàn giao.
ISO/IEC/IEEE 29148	ISO/IEC/IEEE	Đặt ra tiêu chuẩn cho nội dung của tài liệu yêu cầu, đảm bảo các yêu cầu được bàn giao một cách rõ ràng và đầy đủ.
ISTQB CTFL Syllabus	ISTQB	Cung cấp nền tảng cho việc bàn giao các kết quả kiểm thử (test artifacts), đảm bảo đội vận hành hiểu rõ phạm vi và chất lượng đã được xác minh.
`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	`CANONICAL_BUSINESS_RULES`	Các quy tắc nghiệp vụ đã được xác thực là nguồn chân lý (source of truth) cho logic hệ thống. Tài liệu bàn giao phải tham chiếu đến ID của các quy tắc này.
`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	`CANONICAL_DATA_DICTIONARY`	Định nghĩa chính xác về các trường dữ liệu, đảm bảo đội vận hành hiểu đúng ý nghĩa dữ liệu họ đang quản lý.

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

Template này là một artifact được kiểm soát. Mọi thay đổi đối với cấu trúc (các mục trong Tier 2) phải tuân theo quy trình kiểm soát thay đổi nghiêm ngặt.

Trạng thái: IN_REVIEW tại phiên bản v0.9.0. Template chưa được baseline hay phê duyệt chính thức.
Quy trình thay đổi: Mọi đề xuất thay đổi cấu trúc template phải được ghi nhận, xem xét bởi Owner (Principal IT Business Analyst), và cập nhật phiên bản tương ứng trong metadata và TEMPLATE_MANIFEST.md.
Phân biệt:
Thay đổi Template (Controlled): Sửa đổi, thêm, hoặc xóa các đầu mục, bảng biểu, hoặc hướng dẫn trong phần Tier 2 của template này.
Sử dụng Template (Usage): Điền thông tin vào một bản sao của template để tạo một tài liệu bàn giao cụ thể cho case study Nova Foods (nội dung Tier 3). Đây là hành động sử dụng, không phải thay đổi template gốc.
Truy vết: Mọi thay đổi phải có lý do rõ ràng và được ghi lại trong Lịch sử Thay đổi (Change History). Không được phép sửa đổi "im lặng" (silent edits) đối với các phiên bản đã được baseline trong tương lai.

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

A. Metadata và Kiểm soát Tài liệu

Bảng này ghi nhận các thông tin định danh và quản trị cốt lõi của tài liệu bàn giao cụ thể.

Trường thông tin	Giá trị	Hướng dẫn
Tên Hệ thống / Tính năng	`<Tên đầy đủ của hệ thống hoặc tính năng được bàn giao>`	Ví dụ: "Hệ thống Quản lý Đơn hàng (OMS) - Module Xử lý Thanh toán"
ID Bàn giao	`OH-<YYYYMMDD>-<ID_DỰ_ÁN>`	ID duy nhất để truy vết. Ví dụ: `OH-20261025-NOVA-ERP-OMS`
Phiên bản Tài liệu	`v1.0`	Bắt đầu từ v1.0 cho lần bàn giao đầu tiên. Tăng phiên bản nếu có cập nhật quan trọng.
Ngày Bàn giao	`<YYYY-MM-DD>`	Ngày tài liệu này được chính thức chuyển cho đội vận hành.
Bên Bàn giao	`<Tên đội/phòng ban bàn giao>`	Ví dụ: "Đội Phát triển ERP", "Product Team - Supply Chain"
Bên Nhận Bàn giao	`<Tên đội/phòng ban nhận bàn giao>`	Ví dụ: "Đội Vận hành IT (IT Operations)", "Tier 1 Support"
Mô tả chung	`<Mô tả ngắn gọn mục đích và chức năng chính của hệ thống/tính năng.>`	Tóm tắt trong 2-3 câu: Hệ thống này làm gì? Nó phục vụ mục tiêu nghiệp vụ nào?

B. Phạm vi và Ranh giới

Phần này xác định rõ những gì được và không được bao gồm trong lần bàn giao này để tránh hiểu lầm.

1. Trong phạm vi (In-Scope) * <Liệt kê các module, chức năng, hoặc thành phần cụ thể được bàn giao. Mỗi mục một dòng.> * <Ví dụ: Chức năng tạo mới đơn hàng cho nhà cung cấp.> * <Ví dụ: API endpoint /api/v1/orders để lấy danh sách đơn hàng.> * <Ví dụ: Quy trình sao lưu và phục hồi cho cơ sở dữ liệunova_orders_db.>

2. Ngoài phạm vi (Out-of-Scope) * <Liệt kê rõ các phần có liên quan nhưng không thuộc trách nhiệm hỗ trợ của đội nhận bàn giao sau lần này.> * <Ví dụ: Hệ thống CRM của đối tác tích hợp.> * <Ví dụ: Báo cáo tài chính cuối tháng (do đội Kế toán phụ trách).> * <Ví dụ: Các thay đổi về hạ tầng vật lý của máy chủ.>

C. Mô hình Hỗ trợ và Quy trình Leo thang

Mô tả cấu trúc các cấp hỗ trợ và cách liên hệ, leo thang khi có sự cố.

1. Các Cấp Hỗ trợ (Support Tiers)

Cấp	Vai trò / Đội	Kênh liên hệ chính	Giờ làm việc (VN)	Trách nhiệm chính
Tier 1	`<Tên đội hỗ trợ cấp 1>`	`<Email, Số điện thoại, Kênh chat>`	`<Ví dụ: 24/7 hoặc 8:00 - 17:30>`	Tiếp nhận sự cố ban đầu, ghi nhận ticket, giải quyết các vấn đề đã có hướng dẫn trong runbook.
Tier 2	`<Tên đội hỗ trợ cấp 2>`	`<Kênh liên hệ khi được T1 leo thang>`	`<Ví dụ: 8:00 - 17:30, T2-T6>`	Phân tích các sự cố phức tạp hơn, truy cập log, kiểm tra cấu hình.
Tier 3	`<Tên đội hỗ trợ cấp 3 (thường là đội phát triển)>`	`<Kênh liên hệ khi được T2 leo thang>`	`<Ví dụ: 8:00 - 17:30, T2-T6>`	Xử lý lỗi mã nguồn (bug), các vấn đề về kiến trúc, các sự cố chưa từng gặp.

2. Quy trình Leo thang (Escalation Path)

Sự cố được leo thang từ Tier 1 -> Tier 2 -> Tier 3. Một sự cố chỉ được leo thang khi: * <Điều kiện 1, ví dụ: Đã hết thời gian xử lý cam kết (SLA) tại cấp hiện tại.> * <Điều kiện 2, ví dụ: Vấn đề không nằm trong phạm vi kiến thức hoặc quyền hạn của cấp hiện tại.> * <Điều kiện 3, ví dụ: Sự cố có mức độ ảnh hưởng nghiêm trọng (Critical/High).>

D. Tổng quan Kỹ thuật

Cung cấp các thông tin kỹ thuật cần thiết để đội vận hành hiểu và quản lý hệ thống.

Mục	Chi tiết / Đường dẫn	Hướng dẫn
Sơ đồ Kiến trúc	`<Link đến diagram trong Confluence, Miro, hoặc kho lưu trữ>`	Sơ đồ phải thể hiện rõ các thành phần chính và luồng dữ liệu giữa chúng.
Kho mã nguồn (Repo)	`<Link đến Git repository>`	Link đến nhánh chính (main/master) đang được triển khai trên production.
Pipeline Triển khai (CI/CD)	`<Link đến CI/CD pipeline (Jenkins, GitLab CI, etc.)>`	Cung cấp link để theo dõi trạng thái build và deploy.
Truy cập Logs	`<Link đến công cụ log (ELK, Splunk, Graylog) và query mẫu>`	Hướng dẫn cách lọc log theo `request_id`, `user_id` hoặc các mã định danh quan trọng khác.
Cấu hình & Biến môi trường	`<Link đến file config hoặc trang quản lý cấu hình (Vault, Consul, App Configuration)>`	Mô tả quy trình thay đổi cấu hình một cách an toàn (ví dụ: cần review, chỉ áp dụng giờ thấp điểm).
Tham chiếu Bí mật (Secrets)	`Sử dụng định dạng: <Tên-vault>::<đường-dẫn-bí-mật>#<key>`	Cảnh báo: Không bao giờ ghi trực tiếp giá trị bí mật (password, API key) vào đây. Chỉ sử dụng tham chiếu.

E. Giám sát và Cảnh báo (Monitoring & Alerting)

Cách theo dõi sức khỏe hệ thống và ý nghĩa của các cảnh báo tự động.

Dashboard Giám sát chính: <Link đến dashboard Grafana, Datadog, etc.>

Các cảnh báo quan trọng cần chú ý:

Tên Cảnh báo (Alert Name)	Mức độ	Ý nghĩa và Tác động	Hành động Đề xuất Ngay lập tức
`<Ví dụ: HighRequestLatency>`	`Warning`	Thời gian phản hồi API trung bình vượt 2s. Người dùng có thể cảm thấy chậm.	Kiểm tra tải CPU/Memory của service, kiểm tra query DB chậm.
`<Ví dụ: API_5xx_ErrorRateHigh>`	`Critical`	Tỷ lệ lỗi 5xx vượt 5%. Nhiều request đang thất bại, chức năng bị gián đoạn.	Kiểm tra logs để tìm exception, xem xét rollback phiên bản vừa triển khai.
`<Ví dụ: DatabaseConnectionFailed>`	`Critical`	Service không thể kết nối đến cơ sở dữ liệu. Hệ thống ngừng hoạt động hoàn toàn.	Kiểm tra trạng thái DB, cấu hình kết nối, network firewall.
`<Điền cảnh báo thực tế...>`	`<Critical/Warning/Info>`	`<Mô tả cảnh báo có ý nghĩa gì với nghiệp vụ.>`	`<Các bước xử lý ban đầu, ví dụ: "Khởi động lại pod X", "Thông báo cho đội Y".>`

F. Sổ tay Vận hành (Runbooks) - Xử lý Sự cố Thường gặp

Hướng dẫn từng bước để xử lý các vấn đề đã biết.

Triệu chứng	Nguyên nhân có thể	Bước Kiểm tra (để xác nhận)	Bước Khắc phục (để giải quyết)
`<Người dùng báo không thể đăng nhập.>`	1. Service xác thực bị lỗi. 2. Hết kết nối trong connection pool.	1. Gọi API health check của service xác thực. 2. Kiểm tra dashboard monitoring mục "DB Connections".	1. Khởi động lại pod/container của service xác thực. 2. Leo thang cho Tier 2/3 để điều chỉnh cấu hình.
`<Báo cáo X xuất ra dữ liệu trống.>`	Job xử lý dữ liệu ban đêm bị lỗi.	Kiểm tra log của job `daily-report-generator` trong khoảng thời gian 2-3 giờ sáng.	Chạy lại job theo tài liệu `<Link đến tài liệu chạy job thủ công>`.
`<Điền triệu chứng thực tế...>`	`<Nguyên nhân kỹ thuật hoặc nghiệp vụ.>`	`<Câu lệnh, query, hoặc link dashboard để xác minh.>`	`<Các bước thực hiện có thứ tự để khắc phục sự cố.>`

G. Liên kết Truy vết (Traceability Links)

Liên kết đến các tài liệu gốc để đội vận hành hiểu bối cảnh nghiệp vụ đằng sau tính năng.

Loại Artifact	ID Tham chiếu / Đường dẫn	Mô tả Mối liên quan
Quy tắc Nghiệp vụ	`<ID từ CANONICAL_BUSINESS_RULES, ví dụ: BR-ORDER-001>`	Quy tắc này định nghĩa logic tính toán thuế VAT cho đơn hàng, được áp dụng trong service này.
Yêu cầu Chức năng	`<ID từ tài liệu đặc tả, ví dụ: REQ-PAY-005>`	Tính năng này được xây dựng để đáp ứng yêu cầu về thanh toán qua cổng VNPAY.
Từ điển Dữ liệu	`<ID từ CANONICAL_DATA_DICTIONARY, ví dụ: DDE-ORDER-STATUS>`	Mô tả các trạng thái (`PENDING`, `CONFIRMED`, `SHIPPED`) của một đơn hàng.
Đặc tả API	`<Link đến file OpenAPI/Swagger>`	Định nghĩa các endpoint, request, và response của API được bàn giao.
Bằng chứng Kiểm thử (QA)	`<Link đến Test Plan/Test Report>`	Kết quả kiểm thử xác nhận tính năng hoạt động đúng trước khi bàn giao.

H. Xác nhận Hoàn tất Bàn giao (Handover Sign-off)

Các bên liên quan ký xác nhận đã nhận, hiểu, và đồng ý với nội dung của tài liệu bàn giao.

Vai trò	Tên Người ký	Ngày	Ghi chú / Xác nhận
Trưởng nhóm Bên Bàn giao (Lead, Handing Over Team)	`<Tên>`	`<YYYY-MM-DD>`	Tôi xác nhận đã cung cấp đầy đủ và chính xác các thông tin cần thiết.
Trưởng nhóm Bên Nhận Bàn giao (Lead, Receiving Team)	`<Tên>`	`<YYYY-MM-DD>`	Tôi xác nhận đã nhận, đọc, và hiểu nội dung bàn giao. Đội của tôi đã sẵn sàng để hỗ trợ.
Chủ sở hữu Nghiệp vụ (nếu có) (Business Owner, if applicable)	`<Tên>`	`<YYYY-MM-DD>`	Tôi xác nhận quy trình hỗ trợ phù hợp với nhu cầu nghiệp vụ.

2.2. Bảng Theo Dõi Phiên Bản, Rà Soát, Phê Duyệt và Truy Vết

Đây là khu vực bắt buộc để ghi nhận vòng đời của tài liệu chuyển giao vận hành. Mọi thay đổi, rà soát, phê duyệt và liên kết với các artifact khác phải được ghi nhận đầy đủ để đảm bảo tính toàn vẹn và có thể kiểm chứng.

2.2.1. Lịch Sử Phiên Bản (Version History)

Bảng này ghi lại các thay đổi quan trọng của tài liệu. Mỗi khi có cập nhật, một dòng mới phải được thêm vào.

Phiên bản	Ngày Cập Nhật	Tác giả	Tóm Tắt Thay Đổi
`<vX.Y.Z>`	`<YYYY-MM-DD>`	`<Tên Tác Giả>`	`<Mô tả ngắn gọn về các thay đổi chính trong phiên bản này. Ví dụ: "Khởi tạo tài liệu với cấu trúc cơ bản" hoặc "Cập nhật quy trình xử lý đơn hàng trả lại theo BR-RET-005".>`
`<Phiên bản trước đó>`	`<YYYY-MM-DD>`	`<Tên Tác Giả>`	`<Mô tả thay đổi của phiên bản trước.>`

2.2.2. Nhật Ký Rà Soát và Phê Duyệt (Review and Sign-off Log)

Bảng này theo dõi quá trình rà soát và phê duyệt chính thức từ các bên liên quan. "Sign-off" là một thuật ngữ tiếng Anh chuyên ngành, có nghĩa là sự chấp thuận hoặc xác nhận chính thức bằng chữ ký hoặc hành động tương đương, đánh dấu việc hoàn thành một giai đoạn hoặc chấp nhận một sản phẩm.

Vai Trò Rà Soát	Tên Người Rà Soát	Ngày Rà Soát	Kết Quả	Ghi Chú / Điều Kiện Phê Duyệt
`<Tên vai trò, ví dụ: Business Owner>`	`<Tên đầy đủ>`	`<YYYY-MM-DD>`	`<Chọn một: Approved / Approved with Conditions / Rejected / Pending>`	`<Ghi rõ các điều kiện nếu có, hoặc lý do từ chối. Ví dụ: "Phê duyệt với điều kiện quy trình dự phòng phải được kiểm thử trước ngày go-live". Nếu không có, ghi "Không có".>`
`<Tên vai trò, ví dụ: Operations Lead>`	`<Tên đầy đủ>`	`<YYYY-MM-DD>`	`<Chọn một: Approved / Approved with Conditions / Rejected / Pending>`	`<Ghi chú cụ thể.>`
`<Tên vai trò, ví dụ: QA Lead>`	`<Tên đầy đủ>`	`<YYYY-MM-DD>`	`<Chọn một: Approved / Approved with Conditions / Rejected / Pending>`	`<Ghi chú cụ thể.>`
`<Tên vai trò, ví dụ: Security Officer>`	`<Tên đầy đủ>`	`<YYYY-MM-DD>`	`<Chọn một: Approved / Approved with Conditions / Rejected / Pending>`	`<Ghi chú cụ thể.>`

2.2.3. Ma Trận Truy Vết Nguồn Gốc (Traceability Matrix)

Ma trận này liên kết các nội dung trong tài liệu chuyển giao với các artifact nguồn như yêu cầu nghiệp vụ, quy tắc nghiệp vụ, đặc tả kỹ thuật, hoặc kịch bản kiểm thử. Điều này đảm bảo mọi thứ được xây dựng và chuyển giao đều có nguồn gốc rõ ràng. "Traceability" (truy vết) là khả năng theo dõi một yêu cầu từ lúc khởi tạo cho đến khi hoàn thành và ngược lại.

ID Hạng Mục Chuyển Giao	Mô Tả Hạng Mục	ID Artifact Nguồn	Loại Artifact Nguồn	Mô Tả Liên Kết
`<OPS-HDO-ITEM-NNN>`	`<Mô tả ngắn gọn hạng mục được chuyển giao, ví dụ: "Quy trình tạo báo cáo tồn kho cuối ngày".>`	`<Ví dụ: REQ-FIN-015, BR-INV-002, TCASE-INV-031>`	`<Yêu cầu nghiệp vụ (Business Requirement), Quy tắc nghiệp vụ (Business Rule), Ca kiểm thử (Test Case), Thiết kế Giao diện (UI/UX Design), v.v.>`	`<Giải thích mối liên hệ. Ví dụ: "Quy trình này hiện thực hóa yêu cầu REQ-FIN-015 và tuân thủ quy tắc BR-INV-002. Đã được xác minh bởi TCASE-INV-031.">`
`<OPS-HDO-ITEM-NNN+1>`	`<Mô tả hạng mục tiếp theo.>`	`<ID artifact nguồn liên quan.>`	`<Loại artifact nguồn.>`	`<Giải thích mối liên hệ.>`

2.2.4. Bảng Ghi Nhận Các Ngoại Lệ và Sai Lệch (Exceptions and Deviations Log)

Ghi lại bất kỳ sự sai lệch nào đã được thống nhất so với quy trình chuẩn, yêu cầu ban đầu hoặc thiết kế. Điều này giúp đội vận hành biết trước các trường hợp đặc biệt cần xử lý.

ID Ngoại Lệ	Mô Tả Ngoại Lệ / Sai Lệch	Lý Do / Bối Cảnh	Tác Động Dự Kiến	Phương Án Xử Lý / Giảm Thiểu	Người Phê Duyệt Ngoại Lệ
`<EXC-NNN>`	`<Mô tả rõ vấn đề. Ví dụ: "Báo cáo A-05 không hiển thị dữ liệu từ kho phụ XYZ do giới hạn kỹ thuật của phiên bản hiện tại.">`	`<Giải thích tại sao phải chấp nhận sự sai lệch này. Ví dụ: "Tính năng sẽ được bổ sung trong Quý 4/2027. Ưu tiên hiện tại là cho các chức năng cốt lõi.">`	`<Mô tả ảnh hưởng đến nghiệp vụ hoặc vận hành. Ví dụ: "Đội vận hành phải xuất tay dữ liệu từ kho XYZ và tổng hợp vào báo cáo hàng tuần.">`	`<Các bước đội vận hành cần làm. Ví dụ: "Sử dụng script 'export_xyz_stock.sh' hàng ngày và gửi email kết quả cho bộ phận kế toán.">`	`<Tên và vai trò của người có thẩm quyền chấp nhận rủi ro này, ví dụ: Giám đốc Vận hành.>`
`<EXC-NNN+1>`	`<Mô tả ngoại lệ tiếp theo.>`	`<Lý do chấp nhận.>`	`<Tác động dự kiến.>`	`<Phương án xử lý.>`	`<Người phê duyệt.>`

2.2.5. 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à thiết kế có ảnh hưởng trực tiếp đến vận hành sau này. Mục đích là để người tiếp nhận hiểu được "tại sao" hệ thống hoạt động theo cách này mà không phải cách khác.

ID Quyết Định	Vấn Đề Cần Quyết Định	Các Phương Án Đã Xem Xét	Quyết Định Được Chọn	Lý Do Chọn	Người Ra Quyết Định	Ngày Quyết Định
`<DEC-NNN>`	`<Mô tả câu hỏi hoặc vấn đề. Ví dụ: "Lựa chọn phương thức xác thực cho nhà cung cấp khi truy cập cổng thông tin.">`	`<Liệt kê các lựa chọn. Ví dụ: 1. Mật khẩu tĩnh. 2. Xác thực hai yếu tố (2FA) qua SMS. 3. Tích hợp SSO với hệ thống hiện có.>`	`<Ghi rõ quyết định cuối cùng. Ví dụ: "Phương án 2: Xác thực hai yếu tố (2FA) qua SMS.">`	`<Giải thích tại sao. Ví dụ: "Cân bằng giữa an ninh và chi phí triển khai. Mật khẩu tĩnh không đủ an toàn. SSO quá phức tạp cho giai đoạn 1.">`	`<Tên và vai trò, ví dụ: Giám đốc CNTT, Chủ sản phẩm.>`	`<YYYY-MM-DD>`
`<DEC-NNN+1>`	`<Vấn đề cần quyết định tiếp theo.>`	`<Các phương án đã xem xét.>`	`<Quyết định được chọn.>`	`<Lý do chọn.>`	`<Người ra quyết định.>`	`<YYYY-MM-DD>`

Hướng dẫn điền trường, quy tắc xác thực và tham chiếu an toàn

Phần này cung cấp hướng dẫn chi tiết để điền các trường trong biểu mẫu chuyển giao, bao gồm các quy tắc xác thực bắt buộc, cách xử lý các mục có điều kiện và mẫu tham chiếu thông tin bí mật an toàn. Việc tuân thủ các quy tắc này đảm bảo tính nhất quán và đầy đủ của tài liệu chuyển giao cho đội vận hành.

Mỗi trường có placeholder (trình giữ chỗ) trong dấu ngoặc nhọn, ví dụ <Điền giá trị tại đây>, phải được thay thế bằng thông tin thực tế, cụ thể cho chức năng đang được chuyển giao. Không được để trống các trường bắt buộc. Nếu một trường không áp dụng, hãy ghi rõ N/A (Not Applicable - Không áp dụng) và nêu lý do ngắn gọn nếu cần.

Bảng quy tắc xác thực cho các trường chính

Bảng dưới đây định nghĩa các quy tắc xác thực dữ liệu đầu vào cho các trường quan trọng nhất trong tài liệu. Dữ liệu không hợp lệ sẽ bị từ chối trong quá trình xem xét.

Tên trường	Quy tắc xác thực	Ví dụ hợp lệ	Ghi chú
`Feature ID`	Phải khớp với định danh đã đăng ký trong `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`. Định dạng `FEAT-NNN`.	`FEAT-042`	Đảm bảo traceability (khả năng truy vết) đến yêu cầu gốc.
`Version`	Phải tuân theo Semantic Versioning 2.0.0. Định dạng `vX.Y.Z`.	`v1.10.3`	Phiên bản của thành phần phần mềm được chuyển giao.
`Handover Date`	Phải theo định dạng ISO 8601. Định dạng `YYYY-MM-DD`.	`2026-11-20`	Ngày chính thức chuyển giao trách nhiệm vận hành.
`SLA Tier`	Chỉ chấp nhận các giá trị: `Gold`, `Silver`, `Bronze`, `N/A`.	`Silver`	`SLA` là viết tắt của Service Level Agreement (Thỏa thuận mức độ dịch vụ). Phải tham chiếu đến tài liệu SLA tương ứng nếu có.
`Primary Contact`	Phải là một email định danh nhóm hoặc email cá nhân hợp lệ của Nova Foods.	`erp-support-team@nova-foods.vn`	Điểm liên hệ chính cho các sự cố vận hành.

Xử lý các mục có điều kiện

Một số phần trong tài liệu này là có điều kiện. Chúng chỉ cần được điền khi một điều kiện cụ thể được đáp ứng.

Phần 4.2. Database Changes: Chỉ điền phần này nếu trường Có thay đổi CSDL? ở mục 4.1 được chọn là Có. Nếu không, toàn bộ phần 4.2 có thể được đánh dấu là N/A.
Phần 4.3. API Endpoint Changes: Chỉ điền phần này nếu trường Có thay đổi API? ở mục 4.1 được chọn là Có. Nếu không, đánh dấu là N/A.
Phần 6. Exceptions and Rollback Plan: Bắt buộc điền nếu đây là một bản phát hành có rủi ro cao hoặc thay đổi các thành phần hệ thống cốt lõi.

Mẫu tham chiếu thông tin bí mật an toàn

Cảnh báo an ninh: KHÔNG BAO GIỜ dán trực tiếp mật khẩu, khóa API (API key), chuỗi kết nối (connection string), token, hoặc bất kỳ thông tin bí mật (secret) nào vào tài liệu này. Việc này tạo ra rủi ro bảo mật nghiêm trọng và vi phạm chính sách an toàn thông tin.

Tất cả thông tin bí mật phải được lưu trữ trong một hệ thống quản lý bí mật được phê duyệt (ví dụ: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Trong tài liệu này, chỉ sử dụng định dạng tham chiếu an toàn để trỏ đến vị trí của bí mật đó.

Mẫu tham chiếu an toàn	Diễn giải
`[VAULT]/production/erp/database/main_password`	Tham chiếu đến khóa `main_password` tại đường dẫn `production/erp/database` trong Vault.
`[AWS_SM]/nova-foods/prod/sap-connector/api-key`	Tham chiếu đến bí mật `api-key` cho `sap-connector` trong AWS Secrets Manager.

Ví dụ thực tế trong tài liệu:

SAI: Password: P@ssw0rd123!
ĐÚNG: Password: [VAULT]/production/auth-service/service-account/password

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

Đây là ví dụ hoàn chỉnh cho một phiếu chuyển giao vận hành, sử dụng kịch bản mô phỏng tại Nova Foods.

Kịch bản: Triển khai thay đổi trên hệ thống NovaERP để xác thực định dạng Mã Số Thuế (MST) mới của nhà cung cấp trong phân hệ Kế toán Phải trả (Accounts Payable).

3.1. Bảng Tóm Tắt Chuyển Giao

Trường Thông Tin	Giá Trị (Dữ liệu mô phỏng Nova Foods)
ID Thay đổi	`CHG-2026-0418`
ID Bản phát hành	`REL-ERP-2026.Q3.1`
Hệ thống	`NovaERP`
Phân hệ/Module	`Accounts Payable (AP) / Kế toán Phải trả`
Tóm tắt thay đổi	Thêm quy tắc xác thực mã số thuế (MST) của nhà cung cấp theo định dạng 10 hoặc 13 chữ số. Chặn tạo mới/cập nhật hóa đơn đầu vào nếu MST của nhà cung cấp không hợp lệ.
Người yêu cầu	Lê Thị Ngọc Mai (Trưởng phòng Kế toán)
Lý do nghiệp vụ	Bắt buộc tuân thủ: Tuân thủ quy định mới của cơ quan thuế về định dạng MST. Giảm rủi ro: Tránh nguy cơ bị phạt do kê khai sai và giảm thiểu các hóa đơn không được khấu trừ thuế. Tham chiếu quy tắc nghiệp vụ: `BR-ACCT-017`.
Ngày/Giờ triển khai	`2026-09-15 02:00 (Asia/Ho_Chi_Minh)`
Cửa sổ bảo trì	`2026-09-15 02:00 - 04:00 (Asia/Ho_Chi_Minh)`
Mức độ ưu tiên	`Cao`
Người phê duyệt chuyển giao	Nguyễn Văn Hùng (Trưởng phòng Vận hành CNTT)
Ngày phê duyệt	`2026-09-12`

3.2. Tác Động Kỹ Thuật

Thành phần	Loại thay đổi	Mô tả chi tiết (Dữ liệu mô phỏng)	Commit Hash
`NovaERP Backend Service` (module: `erp-core-invoicing`)	Logic Change	Cập nhật hàm `validateSupplierTaxCode()` trong service `SupplierValidationService.java`. Logic mới sử dụng biểu thức chính quy (`regex`) `^(\d{10}\|\d{13})$` để kiểm tra định dạng MST. Ném ra ngoại lệ `InvalidTaxCodeFormatException` nếu không khớp.	`a8d3e4f5c1b2`
`NovaERP UI` (module: `ap-invoice-entry-form`)	UI Change	Thêm thông báo lỗi phía người dùng trên form nhập hóa đơn: "Mã số thuế không hợp lệ. Vui lòng kiểm tra lại (phải đủ 10 hoặc 13 chữ số)."	`c7b1a9f0d3e5`

3.3. Cấu hình Môi trường

Các thay đổi cấu hình này sẽ được áp dụng bởi đội DevOps trong cửa sổ bảo trì.

Môi trường	Tệp cấu hình	Tham số	Giá trị mới	Ghi chú
`Production`	`erp-prod-config.properties`	`feature.validation.newTaxCodeFormat.enabled`	`true`	Feature flag để kích hoạt logic xác thực MST mới.

3.4. Các Bên Liên Quan và Liên Hệ Hỗ Trợ

Vai trò	Tên/Nhóm	Kênh liên hệ	Trách nhiệm chính khi có sự cố
Hỗ trợ nghiệp vụ Cấp 1	Nhóm Hỗ trợ Kế toán	`hotro.ketoan@nova-foods.vn`	Tiếp nhận và ghi nhận ticket từ người dùng cuối (phòng Kế toán) liên quan đến lỗi tạo hóa đơn.
Hỗ trợ kỹ thuật Cấp 2	Đội Vận hành ERP (Ops)	`erp.ops@nova-foods.vn`	Kiểm tra log hệ thống, trạng thái dịch vụ, xác minh feature flag đã được bật đúng hay chưa.
Leo thang Cấp 3	Nhóm Phát triển ERP Core	`PAGERDUTY: ERP Core On-Call`	Phân tích và sửa lỗi khẩn cấp nếu sự cố nghiêm trọng (ví dụ: toàn bộ chức năng tạo hóa đơn bị dừng).
Business Owner	Lê Thị Ngọc Mai	`mai.ltn@nova-foods.vn`	Ra quyết định nghiệp vụ nếu cần tạm thời vô hiệu hóa tính năng (rollback) để đảm bảo hoạt động kinh doanh.

Bản Ghi Chuyển Giao Vận Hành: Module Hợp Đồng Nhà Cung Cấp

Đây là bản ghi chuyển giao vận hành đã hoàn thiện cho module mới trong hệ thống ERP của Nova Foods (dữ liệu mô phỏng). Tài liệu này cung cấp thông tin cốt lõi cho đội Hỗ trợ Cấp 1 (Tier 1 Support) và các bên liên quan để quản lý và hỗ trợ module sau khi đi vào hoạt động.

Trường Thông Tin	Giá Trị
Tên Tính Năng	Quản lý Hợp đồng Nhà cung cấp Nguyên vật liệu v1.0
Mã Truy Vết Tính Năng	`FEAT-PROC-004`
Hệ thống	Nova Foods ERP - Phân hệ Mua hàng (Procurement)
Ngày Chuyển Giao	`2026-08-07`
Ngày Dự Kiến Go-Live	`2026-09-01`
Chủ sở hữu Nghiệp vụ (Business Owner)	Nguyễn Thị Lan (Trưởng phòng Mua hàng)
Chủ sở hữu Kỹ thuật (Technical Owner)	Trần Văn Hùng (Trưởng nhóm ERP Core)
Đội Hỗ trợ Cấp 1	Đội Hỗ trợ IT Nội bộ

1. Mục Đích Nghiệp Vụ và Phạm Vi

Module này được xây dựng để giải quyết việc quản lý hợp đồng nhà cung cấp nguyên vật liệu đang phân mảnh trên nhiều file Excel, dẫn đến rủi ro bỏ lỡ thời hạn gia hạn, áp sai giá và thiếu kiểm soát tuân thủ.

Mục tiêu chính: * Tập trung hóa: Lưu trữ toàn bộ hợp đồng và phụ lục tại một nơi duy nhất. * Tự động hóa: Tự động gửi email thông báo cho Chủ sở hữu Nghiệp vụ trước khi hợp đồng hết hạn 90, 60 và 30 ngày. * Kiểm soát: Ràng buộc việc tạo Đơn Mua hàng (Purchase Order - PO) phải dựa trên một hợp đồng đang có hiệu lực.

Phạm vi của phiên bản 1.0 bao gồm việc tạo mới, xem, sửa hợp đồng, quản lý phiên bản và các trạng thái жизненного цикла hợp đồng. Việc tích hợp chữ ký số và phân quyền chi tiết theo từng điều khoản sẽ được xem xét ở phiên bản sau.

2. Các Trạng Thái Hợp Đồng

Hệ thống quản lý hợp đồng thông qua một luồng trạng thái được định nghĩa rõ ràng. Đội hỗ trợ cần hiểu rõ các trạng thái này để trả lời câu hỏi từ người dùng.

Trạng Thái	Mã Trạng Thái	Diễn Giải	Hành Động Kế Tiếp
Nháp	`DRAFT`	Hợp đồng đang được soạn thảo. Chưa có hiệu lực pháp lý và không thể dùng để tạo PO.	Gửi đi xem xét (`Submit for Review`).
Đang Xem Xét	`IN_REVIEW`	Hợp đồng đã được gửi cho các bên liên quan (pháp chế, kế toán) để xem xét.	Phê duyệt (`Approve`) hoặc Yêu cầu Chỉnh sửa (`Request Changes`).
Có Hiệu Lực	`ACTIVE`	Hợp đồng đã được phê duyệt và đang trong thời gian hiệu lực. Có thể dùng làm cơ sở để tạo PO.	Tự động chuyển sang `EXPIRED` khi hết hạn.
Yêu Cầu Chỉnh Sửa	`CHANGES_REQUESTED`	Hợp đồng bị trả về để chỉnh sửa. Trở về trạng thái `DRAFT` với phiên bản phụ tăng lên (ví dụ: v1.1).	Chỉnh sửa và gửi lại để xem xét.
Đã Hết Hạn	`EXPIRED`	Hợp đồng đã qua ngày kết thúc hiệu lực. Không thể dùng để tạo PO.	Tạo phiên bản mới để gia hạn.
Đã Hủy	`CANCELLED`	Hợp đồng bị hủy trước thời hạn. Không thể dùng để tạo PO và không thể kích hoạt lại.	Tạo hợp đồng mới nếu cần.

3. Quy Tắc Nghiệp Vụ Chính (Key Business Rules)

Các quy tắc sau là xương sống của module. Vi phạm các quy tắc này có thể gây gián đoạn quy trình mua hàng hoặc rủi ro tài chính.

Mã Truy Vết	Quy Tắc Nghiệp Vụ	Nguồn Yêu Cầu	Hậu Quả nếu Vi Phạm
BR-PROC-015	Một Đơn Mua hàng (PO) không được phép tạo với một nhà cung cấp nếu không tồn tại hợp đồng ở trạng thái `ACTIVE` với nhà cung cấp đó.	`REQ-PROC-078`	Rủi ro mua hàng không có ràng buộc pháp lý, sai giá, sai điều khoản thanh toán. Gây lỗi hệ thống khi xử lý thanh toán.
BR-PROC-016	Hệ thống phải tự động gửi email thông báo cho Business Owner và người tạo hợp đồng vào các mốc 90, 60, và 30 ngày trước ngày `expiry_date` của hợp đồng.	`REQ-PROC-081`	Bỏ lỡ thời hạn gia hạn hợp đồng, gây gián đoạn chuỗi cung ứng nguyên vật liệu. Phải đàm phán lại trong thế bị động.
BR-PROC-017	Giá trị trên mỗi dòng hàng của PO không được vượt quá giá đã được thỏa thuận trong hợp đồng `ACTIVE` tương ứng.	`REQ-PROC-092`	Chi tiêu vượt ngân sách, sai lệch dữ liệu tài chính, gây khó khăn cho việc đối soát công nợ cuối kỳ.
BR-SHARED-005	Mọi thay đổi về các trường tài chính (giá trị hợp đồng, điều khoản thanh toán) phải tạo một phiên bản (version) mới của hợp đồng và yêu cầu quy trình phê duyệt lại từ đầu.	`CANONICAL_BUSINESS_RULES`	Mất dấu vết kiểm toán (audit trail), không thể truy xuất được ai đã thay đổi và thay đổi vào lúc nào, rủi ro gian lận.

3.3 Phân tích Hiện trạng, Nhu cầu, và Quyết định

Phần này phân tích bối cảnh, lý do và quyết định dẫn đến thay đổi hệ thống được bàn giao.

Hiện trạng (Facts & Current Behavior)

Hệ thống ERP hiện tại, cụ thể là mô-đun kế toán phải trả (AP-AccountsPayable), áp dụng một quy tắc thanh toán cứng: tất cả hóa đơn nhà cung cấp được xử lý với điều khoản thanh toán mặc định là Net 30 (thanh toán đủ trong vòng 30 ngày kể từ ngày xuất hóa đơn). Quy tắc nghiệp vụ này được đăng ký với định danh BR-ACCT-PAY-001. Do đó, bộ phận Kế toán Công nợ không thể cấu hình các điều khoản thanh toán linh hoạt hơn cho các nhà cung cấp khác nhau hoặc cho các hóa đơn riêng lẻ một cách tự động trên hệ thống. Mọi trường hợp ngoại lệ đều phải được theo dõi và xử lý thủ công bên ngoài ERP, dẫn đến tốn thời gian và rủi ro sai sót cao.

Nhu cầu Cốt lõi (Underlying Need)

Nhu cầu nghiệp vụ (định danh REQ-FIN-015) xuất phát từ phòng Tài chính nhằm tối ưu hóa chi phí bằng cách tận dụng các chính sách chiết khấu thanh toán sớm từ nhà cung cấp. Nhiều nhà cung cấp chiến lược của Nova Foods đưa ra các điều khoản hấp dẫn, ví dụ 2/10 Net 30, nghĩa là Nova Foods sẽ được giảm 2% trên tổng giá trị hóa đơn nếu thanh toán trong vòng 10 ngày. Phòng Tài chính ước tính Nova Foods đang bỏ lỡ một khoản tiết kiệm tiềm năng lên tới 450.000.000 VND mỗi năm do quy trình hiện tại không hỗ trợ thanh toán sớm một cách có hệ thống. Bằng chứng cho phân tích này được ghi nhận tại TRACE-MEET-FIN-20260715-01 (Biên bản họp giữa phòng Tài chính và phòng Mua hàng ngày 15/07/2026).

Các Phương án, Tiêu chí, và Quyết định

Hai phương án chính đã được xem xét để giải quyết nhu cầu REQ-FIN-015.

Phương án	Mô tả
Phương án 1: Xử lý thủ công	Kế toán công nợ sẽ theo dõi các hóa đơn có điều khoản chiết khấu trên một file Excel riêng. Họ sẽ phải tự tính toán ngày hết hạn chiết khấu và tạo lệnh thanh toán thủ công để kịp thời hạn.
Phương án 2: Nâng cấp hệ thống ERP	Sửa đổi mô-đun `AP-AccountsPayable` để hỗ trợ định nghĩa và tự động áp dụng các điều khoản thanh toán có chiết khấu. Hệ thống có thể được cấu hình ở cấp nhà cung cấp và ghi đè ở cấp hóa đơn.

Quyết định được đưa ra dựa trên các tiêu chí sau:

Tiêu chí	Trọng số	Phương án 1 (Thủ công)	Phương án 2 (Hệ thống)
Khả năng hiện thực hóa tiết kiệm	Cao	Thấp (Rủi ro quên, sai sót cao)	Cao (Tự động, nhất quán)
Rủi ro vận hành	Cao	Cao (Lỗi con người, khó kiểm soát)	Thấp (Quy trình chuẩn, có audit trail)
Chi phí triển khai ban đầu	Trung bình	Rất thấp (Không tốn chi phí IT)	Trung bình (Chi phí phát triển và kiểm thử)
Chi phí vận hành dài hạn	Cao	Cao (Tốn giờ làm việc của nhân sự)	Rất thấp (Tự động hóa)
Khả năng mở rộng	Thấp	Rất thấp (Không thể mở rộng khi số lượng NCC tăng)	Cao (Dễ dàng áp dụng cho toàn bộ NCC)

Đề xuất và Quyết định được phê duyệt:

Quyết định: Lựa chọn Phương án 2: Nâng cấp hệ thống ERP.
Lý do: Mặc dù có chi phí triển khai ban đầu, Phương án 2 giảm thiểu rủi ro vận hành, tối đa hóa lợi ích tài chính, và cung cấp một giải pháp bền vững có thể mở rộng. Chi phí nhân sự để xử lý thủ công được dự báo sẽ vượt chi phí triển khai hệ thống chỉ sau 18 tháng vận hành.

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

Vai trò	Tên (Mô phỏng)	Quyết định đã phê duyệt	Ngày phê duyệt
Trưởng phòng Tài chính	Nguyễn Thị Lan Anh	Phê duyệt nhu cầu nghiệp vụ, lợi ích tài chính và ngân sách dự án.	2026-07-28
Giám đốc CNTT	Trần Văn Hùng	Phê duyệt giải pháp kỹ thuật, nguồn lực triển khai và tiến độ.	2026-07-29

Hậu quả nếu Quyết định sai (Consequence if Wrong)

Nếu chọn Phương án 1 và quy trình thủ công thất bại: Tổn thất tài chính trực tiếp do không nhận được chiết khấu; rủi ro thanh toán sai (trả thừa/thiếu); ảnh hưởng tiêu cực đến uy tín và mối quan hệ với các nhà cung cấp chiến lược.
Nếu chọn Phương án 2 nhưng triển khai sai: Lỗi phần mềm có thể gây ra các khoản thanh toán không chính xác trên diện rộng, dẫn đến tranh chấp pháp lý và tổn thất tài chính lớn hơn cả khoản chiết khấu. Dự án có nguy cơ vượt ngân sách và chậm tiến độ, ảnh hưởng đến các hoạt động kinh doanh khác.

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

Phần này liên kết bản ghi cốt lõi từ mục trước với các bằng chứng cụ thể hỗ trợ nó. Nó cung cấp khả năng truy vết đầu cuối, liệt kê các rủi ro có thể xảy ra, ghi lại các giả định đã được đưa ra và đánh dấu các mục cần chuyên gia xác minh.

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

Ma trận truy vết (Traceability Matrix) là một công cụ để đảm bảo không có yêu cầu nào bị bỏ sót. Nó kết nối nhu cầu nghiệp vụ ban đầu (Need) với yêu cầu hệ thống (Requirement), quy tắc nghiệp vụ (Business Rule), tiêu chí chấp nhận (Acceptance Criteria), và các kịch bản kiểm thử (Test Case). Việc này đảm bảo mọi thứ được xây dựng đều có lý do và mọi lý do đều được kiểm chứng.

ID Nhu cầu (Need)	ID Yêu cầu (Requirement)	ID Quy tắc (Rule)	ID Tiêu chí (AC)	ID Kiểm thử (TC)	ID Dữ liệu/API (Data)
`NEED-FIN-001`	`REQ-FIN-001`	`BR-FIN-CALC-001`	`AC-FIN-001-01`	`TC-FIN-001-04`	`supplier.isEligibleForDiscount`
`NEED-FIN-001`	`REQ-FIN-001`	`BR-FIN-CALC-001`	`AC-FIN-001-02`	`TC-FIN-001-01`, `TC-FIN-001-05`	`invoice.total`, `contract.discountRate`
`NEED-FIN-001`	`REQ-FIN-001`	`BR-FIN-CALC-001`	`AC-FIN-001-03`	`TC-FIN-001-02`, `TC-FIN-001-03`	`invoice.issueDate`, `payment.executionDate`, `contract.discountWindowDays`
`NEED-FIN-001`	`REQ-FIN-001`	`BR-FIN-CALC-001`	`AC-FIN-001-04`	`TC-FIN-001-06`	`invoice.currency`, `API:GET /fx-rates/latest`

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

Luồng xử lý tiêu cực (Negative Path) mô tả cách hệ thống phản ứng khi gặp lỗi hoặc dữ liệu không hợp lệ. Việc định nghĩa trước các trường hợp này là bắt buộc để xây dựng một hệ thống ổn định và đáng tin cậy.

ID Ngoại lệ	Mô tả (Case Study Nova Foods)	Cách xử lý đề xuất
`EX-FIN-CALC-001`	Hệ thống không tìm thấy hóa đơn với ID được cung cấp.	Ghi log lỗi với mã `ERR_INVOICE_NOT_FOUND`. Gửi thông báo đến nhóm Kế toán Công nợ. Không xử lý tiếp.
`EX-FIN-CALC-002`	Nhà cung cấp của hóa đơn không có trong danh sách được hưởng chiết khấu.	Bỏ qua hóa đơn. Ghi nhận vào log nghiệp vụ với lý do `SUPPLIER_NOT_ELIGIBLE`.
`EX-FIN-CALC-003`	Dữ liệu hợp đồng của nhà cung cấp thiếu thông tin về tỷ lệ hoặc thời hạn chiết khấu.	Ghi log lỗi với mã `ERR_CONTRACT_DATA_INCOMPLETE`. Tạo một tác vụ trong hệ thống cho bộ phận Mua hàng để bổ sung thông tin.
`EX-FIN-CALC-004`	API cung cấp tỷ giá ngoại tệ không phản hồi hoặc trả về lỗi.	Thử lại 3 lần, mỗi lần cách nhau 5 giây. Nếu cả 3 lần đều thất bại, sử dụng tỷ giá đóng cửa của ngày làm việc trước đó và ghi cảnh báo (`WARN_STALE_FX_RATE`) vào log hệ thống.

4.3 Các giả định (Assumptions)

Giả định (Assumption) là những điều kiện chúng ta coi là đúng mà không cần chứng minh trong phạm vi dự án này. Nếu giả định sai, giải pháp có thể bị ảnh hưởng nghiêm trọng.

ID Giả định	Mô tả Giả định	Lý do & Giới hạn
`ASMP-FIN-001`	Dữ liệu master của nhà cung cấp (mã số thuế, điều khoản thanh toán, trạng thái hợp lệ) trong ERP là nguồn thông tin chính xác và duy nhất.	Đã có một quy trình riêng để quản lý và kiểm soát chất lượng dữ liệu master nhà cung cấp, được thực hiện bởi bộ phận Mua hàng và Kế toán. Tính năng này chỉ đọc, không sửa đổi dữ liệu đó.
`ASMP-FIN-002`	Ngày phát hành hóa đơn và ngày thanh toán được ghi nhận vào hệ thống một cách chính xác.	Quy trình nhập liệu hiện tại yêu cầu kiểm tra đối chiếu (ví dụ: 2 người nhập hoặc 1 người nhập, 1 người duyệt) cho các chứng từ kế toán quan trọng.

4.4 Các mục cần xác minh (Verification-Required Items)

Đây là danh sách các điểm chưa rõ ràng hoặc cần sự phê duyệt từ chuyên gia có thẩm quyền (pháp lý, kế toán, nghiệp vụ) trước khi đi vào thiết kế chi tiết hoặc triển khai.

ID Mục	Nội dung cần xác minh	Vai trò xác minh	Trạng thái
`VERIFY-FIN-001`	Cách hạch toán khoản chiết khấu thanh toán vào sổ sách kế toán và ảnh hưởng đến thuế GTGT, đối chiếu với Thông tư 200/2014/TT-BTC và các văn bản sửa đổi.	Kế toán trưởng	`PENDING_VERIFICATION`
`VERIFY-LEG-001`	Điều khoản "Chiết khấu thanh toán sớm" trong hợp đồng mẫu của Nova Foods có phù hợp với Luật Thương mại Việt Nam hiện hành hay không.	Phụ trách Pháp chế	`PENDING_VERIFICATION`
`VERIFY-SEC-001`	Dịch vụ API tỷ giá ngoại tệ của bên thứ ba có đáp ứng yêu cầu về bảo mật và độ tin cậy của Nova Foods không (theo tiêu chuẩn ASVS).	Trưởng phòng An ninh thông tin	`PENDING_VERIFICATION`

4.5 Ghi nhận các vấn đề leo thang (Escalation Records)

Nhật ký về các vấn đề quan trọng phát sinh trong quá trình phân tích đã cần phải leo thang (escalate) lên cấp quản lý để có quyết định.

ID Leo thang	Ngày	Vấn đề	Leo thang tới	Kết quả/Quyết định
`ESC-FIN-ARCH-001`	2026-08-01	Xung đột về nguồn lấy tỷ giá ngoại tệ: giữa tỷ giá tham khảo của Ngân hàng Nhà nước và tỷ giá giao dịch thực tế của ngân hàng thương mại (Vietcombank).	Giám đốc CNTT, Trưởng phòng Tài chính	Quyết định: Thống nhất sử dụng tỷ giá BÁN RA của Vietcombank tại thời điểm tạo lệnh thanh toán để đảm bảo tính thực tế của giao dịch.

Bằng chứng và Truy vết nguồn gốc (Traceability)

Truy vết nguồn gốc, hay Traceability trong tiếng Anh, là khả năng liên kết và theo dõi một yêu cầu trong suốt vòng đời của dự án, từ nhu cầu nghiệp vụ ban đầu đến yêu cầu chi tiết, quy tắc nghiệp vụ, tiêu chí chấp nhận, thiết kế, mã nguồn, kịch bản kiểm thử, và bất kỳ lỗi hay yêu cầu thay đổi nào phát sinh. Việc này đảm bảo mọi thành phần của hệ thống được xây dựng đều có mục đích rõ ràng, đáp ứng đúng nhu cầu đã xác định và được kiểm chứng đầy đủ. Nó giúp trả lời các câu hỏi quản trị quan trọng: "Tại sao chúng ta làm chức năng này?", "Yêu cầu này đã được kiểm thử chưa?", và "Nếu thay đổi yêu cầu này, những thành phần nào sẽ bị ảnh hưởng?".

Ma trận Truy vết (Traceability Matrix) dưới đây là một ví dụ cụ thể cho quy trình "PO to Cash" của Nova Foods. Nó thể hiện các liên kết hai chiều giữa các loại artifact khác nhau, sử dụng ID đã được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Mỗi dòng trong bảng đại diện cho một liên kết đơn lẻ, tạo thành một chuỗi logic xuyên suốt.

Ma trận Truy vết nguồn gốc cho Quy trình "PO to Cash" (Mô phỏng)

ID Nguồn (Source ID)	Loại	ID Đích (Destination ID)	Loại	Loại liên kết	Ghi chú (Mô phỏng Nova Foods)
`NEED-NF-001`	NEED	`REQ-FUN-NF-005`	REQ	`Dẫn xuất từ (Derived from)`	Nhu cầu tự động hóa quy trình PO dẫn đến yêu cầu hệ thống phải có khả năng nhận và xử lý PO.
`NEED-NF-001`	NEED	`REQ-NFR-NF-PER-002`	REQ	`Dẫn xuất từ (Derived from)`	Nhu cầu tăng tốc độ xử lý dẫn đến yêu cầu phi chức năng về hiệu năng xử lý PO.
`REQ-FUN-NF-005`	REQ	`BR-NF-VAL-011`	BR	`Ràng buộc bởi (Constrained by)`	Yêu cầu xử lý PO phải tuân thủ quy tắc xác thực thông tin nhà cung cấp có trong hệ thống.
`REQ-FUN-NF-005`	REQ	`AC-NF-005-01`	AC	`Xác minh bởi (Verified by)`	Yêu cầu xử lý PO được xác minh qua tiêu chí chấp nhận về việc tạo PO thành công với dữ liệu hợp lệ.
`REQ-FUN-NF-005`	REQ	`AC-NF-005-02`	AC	`Xác minh bởi (Verified by)`	Yêu cầu xử lý PO được xác minh qua tiêu chí chấp nhận về việc từ chối PO với dữ liệu không hợp lệ.
`BR-NF-VAL-011`	BR	`AC-NF-005-03`	AC	`Xác minh bởi (Verified by)`	Quy tắc nghiệp vụ được xác minh qua tiêu chí chấp nhận về việc hệ thống báo lỗi khi mã nhà cung cấp không tồn tại.
`BR-NF-VAL-011`	BR	`DATA-SUPPLIER-001`	DATA	`Sử dụng (Uses)`	Quy tắc xác thực nhà cung cấp sử dụng trường dữ liệu `supplier_id` từ Từ điển Dữ liệu.
`AC-NF-005-01`	AC	`TC-NF-005-HP-01`	TC	`Kiểm thử bởi (Tested by)`	Tiêu chí chấp nhận "happy path" được kiểm thử bằng kịch bản kiểm thử luồng thành công.
`AC-NF-005-03`	AC	`TC-NF-005-NP-01`	TC	`Kiểm thử bởi (Tested by)`	Tiêu chí chấp nhận "negative path" được kiểm thử bằng kịch bản kiểm thử với mã nhà cung cấp không tồn tại.
`TC-NF-005-NP-01`	TC	`DEF-NF-015`	DEF	`Phát hiện (Found by)`	Thực thi kịch bản kiểm thử phát hiện lỗi: hệ thống bị treo thay vì báo lỗi thân thiện.
`DEF-NF-015`	DEF	`CR-NF-004`	CR	`Dẫn đến (Leads to)`	Lỗi được ghi nhận dẫn đến một yêu cầu thay đổi (Change Request) để sửa cơ chế xử lý lỗi.
`REQ-NFR-NF-PER-002`	REQ	`AC-NF-PER-002-01`	AC	`Xác minh bởi (Verified by)`	Yêu cầu hiệu năng được xác minh qua tiêu chí chấp nhận: hệ thống xử lý 100 PO/phút với tải thường.
`AC-NF-PER-002-01`	AC	`TC-NF-PER-002-LT`	TC	`Kiểm thử bởi (Tested by)`	Tiêu chí chấp nhận về hiệu năng được kiểm thử bằng kịch bản kiểm thử tải (Load Test).

Bằng chứng Vận hành: Dữ liệu Kiểm thử và Payload API

Để bàn giao một chức năng cho đội Vận hành (Operations - Ops), việc cung cấp bằng chứng cụ thể là rất quan trọng. Bằng chứng này không chỉ là tài liệu mô tả mà còn bao gồm dữ liệu thực tế được sử dụng để kiểm thử và tái tạo sự cố. Payload là thuật ngữ chỉ khối dữ liệu được gửi đi trong một yêu cầu API (Application Programming Interface - Giao diện Lập trình Ứng dụng) hoặc nhận về trong một phản hồi.

Dưới đây là các payload JSON (JavaScript Object Notation - một định dạng trao đổi dữ liệu gọn nhẹ, dễ đọc) mẫu cho chức năng "Tạo mới Đơn Mua Hàng" (tương ứng REQ-NF-005). Các payload này được dùng trong các kịch bản kiểm thử đã tham chiếu ở bảng truy vết và là bằng chứng cốt lõi để đội Ops hiểu cách hệ thống hoạt động, cách chẩn đoán lỗi và dữ liệu đầu vào/đầu ra mong đợi.

1. Kịch bản Luồng thành công (Happy Path)

Kịch bản này minh họa trường hợp người dùng tạo thành công một Đơn Mua Hàng (Purchase Order - PO) với dữ liệu hoàn toàn hợp lệ. Đây là luồng nghiệp vụ chính mà hệ thống phải hỗ trợ ổn định.

Tham chiếu Kịch bản Kiểm thử: TC-NF-005-HP-01
Mô tả: Hệ thống nhận yêu cầu tạo PO với mã nhà cung cấp (supplier_id) hợp lệ và tồn tại trong hệ thống ERP. Hệ thống xử lý thành công, tạo bản ghi PO mới trong cơ sở dữ liệu và trả về thông tin của PO vừa được tạo cùng mã trạng thái HTTP xác nhận thành công.

Yêu cầu API (Request Payload) Gửi tới điểm cuối (endpoint) POST /api/v1/purchase-orders

{
  "supplier_id": "NCC-2024-0118",
  "order_date": "2026-08-15",
  "requested_delivery_date": "2026-09-01",
  "deliver_to_warehouse_id": "KHO-HCM-01",
  "currency": "VND",
  "notes": "Yêu cầu giao hàng trước 16:00. Lô hàng bột mì nhập khẩu từ Úc.",
  "items": [
    {
      "product_id": "SP-BOTMI-005",
      "description": "Bột mì đa dụng cao cấp - Lô 25kg",
      "quantity": 200,
      "unit_price": 350000
    },
    {
      "product_id": "SP-DUONG-002",
      "description": "Đường tinh luyện Biên Hòa - Bao 50kg",
      "quantity": 150,
      "unit_price": 980000
    }
  ]
}

Phản hồi Mong đợi (Expected Response) Mã trạng thái HTTP 201 Created

{
  "status": "success",
  "data": {
    "po_id": "PO-2026-48152",
    "status": "PENDING_APPROVAL",
    "supplier_id": "NCC-2024-0118",
    "order_date": "2026-08-15",
    "total_amount": 217000000,
    "currency": "VND",
    "created_by": "user_api_automation",
    "created_at": "2026-08-15T10:30:05Z"
  }
}

2. Kịch bản Luồng Thất bại (Negative Path)

Kịch bản này minh họa cách hệ thống xử lý một cách an toàn và tường minh khi người dùng cung cấp dữ liệu không hợp lệ. Đây là bằng chứng cho việc hệ thống có cơ chế xác thực đầu vào (input validation) mạnh mẽ, một yêu cầu bảo mật cơ bản theo OWASP API Security Top 10 (cụ thể là API5:2023 - Broken Function Level Authorization và các lỗi liên quan đến xác thực dữ liệu).

Tham chiếu Kịch bản Kiểm thử: TC-NF-005-NP-01
Mô tả: Hệ thống nhận yêu cầu tạo PO với mã nhà cung cấp (supplier_id) không tồn tại trong cơ sở dữ liệu. Hệ thống phải từ chối yêu cầu và trả về một thông báo lỗi rõ ràng, có cấu trúc, thay vì bị treo hoặc trả về lỗi chung 500 Internal Server Error. Việc xử lý lỗi này là kết quả của việc sửa lỗi DEF-NF-015 thông qua yêu cầu thay đổi CR-NF-004.

Yêu cầu API (Request Payload) Gửi tới điểm cuối POST /api/v1/purchase-orders

{
  "supplier_id": "NCC-9999-INVALID",
  "order_date": "2026-08-15",
  "requested_delivery_date": "2026-09-01",
  "deliver_to_warehouse_id": "KHO-HCM-01",
  "currency": "VND",
  "notes": "Kiểm thử với nhà cung cấp không tồn tại.",
  "items": [
    {
      "product_id": "SP-BOTMI-005",
      "description": "Bột mì đa dụng cao cấp - Lô 25kg",
      "quantity": 10,
      "unit_price": 350000
    }
  ]
}

Phản hồi Mong đợi (Expected Response) Mã trạng thái HTTP 422 Unprocessable Entity

Ghi chú chuyên môn: Lý do chọn mã 422 thay vì 400 Bad Request là vì cú pháp của JSON là hoàn toàn hợp lệ (không phải là một Bad Request), nhưng dữ liệu bên trong không thể xử lý được về mặt logic nghiệp vụ (mã nhà cung cấp không tồn tại). Đây là cách thực hành tốt nhất được khuyến nghị cho các API RESTful hiện đại để phân biệt lỗi cú pháp và lỗi logic.

{
  "status": "error",
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Không thể xử lý yêu cầu do lỗi xác thực dữ liệu.",
    "details": [
      {
        "field": "supplier_id",
        "value": "NCC-9999-INVALID",
        "issue": "Mã nhà cung cấp không tồn tại trong hệ thống."
      }
    ]
  }
}

5. Tier 4 – Senior BA Quality Gate

Mục đích của cổng chất lượng này là để đảm bảo một artifact (sản phẩm tạo tác, ví dụ: tài liệu đặc tả yêu cầu) đạt chất lượng tối thiểu trước khi được xem xét đưa vào baseline. Baseline là một phiên bản của artifact đã được xem xét và đồng thuận chính thức, đóng vai trò là điểm tham chiếu cho các hoạt động phát triển và kiểm thử tiếp theo.

Senior Business Analyst (BA Cấp cao) sử dụng danh mục kiểm tra dưới đây để đánh giá. Một hạng mục có thể Pass (Đạt), Fail (Không Đạt), hoặc dẫn đến hành động Stop (Dừng) hoặc Escalate (Chuyển giao).

Đạt (Pass): Artifact thỏa mãn tiêu chí và có thể chuyển sang bước tiếp theo trong quy trình.
Không Đạt (Fail): Artifact có lỗi cần được BA tác giả sửa chữa. Lỗi không đủ nghiêm trọng để dừng toàn bộ quy trình.
Dừng (Stop): Lỗi nghiêm trọng, ngăn cản việc xem xét tiếp. Toàn bộ quy trình đánh giá dừng lại cho đến khi lỗi được khắc phục.
Chuyển giao (Escalate): Vấn đề nằm ngoài thẩm quyền của nhóm BA và phải được chuyển đến Owner có chuyên môn phù hợp (ví dụ: Phòng Pháp lý, Kế toán, Kiến trúc sư hệ thống) để xử lý.

Danh mục Kiểm tra Chất lượng Artifact

Hạng mục kiểm tra	Tiêu chí Đạt (Pass)	Tiêu chí Không Đạt (Fail)	Hành động (Stop / Escalate)
Tính Đầy đủ (Completeness)	Tất cả các mục trong template đều được điền đầy đủ. Mọi yêu cầu đều có tiêu chí chấp nhận (acceptance criteria). Không có mục nào ghi "TBD" (To Be Determined), "TODO" hoặc bị bỏ trống.	Có mục bị bỏ trống, còn ghi chú TBD/TODO, hoặc yêu cầu thiếu tiêu chí chấp nhận.	STOP. Yêu cầu BA tác giả bổ sung thông tin còn thiếu. Không xem xét tiếp cho đến khi hoàn thiện.
Tính Nhất quán (Consistency)	Thuật ngữ, định danh (ID), và quy tắc nghiệp vụ được sử dụng thống nhất trong toàn bộ tài liệu và khớp với các nguồn canonical như Từ điển Dữ liệu (`CANONICAL_DATA_DICTIONARY`) và Catalog Quy tắc (`CANONICAL_BUSINESS_RULES`).	Sử dụng thuật ngữ hoặc ID mâu thuẫn. Nội dung của một yêu cầu xung đột với yêu cầu khác hoặc một quy tắc nghiệp vụ đã được định nghĩa.	STOP. Yêu cầu BA tác giả sửa lỗi mâu thuẫn. Nếu mâu thuẫn với một artifact canonical, ESCALATE đến Owner của artifact đó.
Tính Khả kiểm (Testability)	Mỗi yêu cầu đều rõ ràng, cụ thể, không mơ hồ, có thể đo lường và xác minh được bằng một hoặc nhiều ca kiểm thử (test case). Ví dụ: "API `GET /products/{id}` phải trả về phản hồi trong vòng 200ms ở mức tải 95%".	Yêu cầu mang tính chủ quan, không thể đo lường. Ví dụ: "Hệ thống phải nhanh và thân thiện với người dùng".	STOP. Yêu cầu BA tác giả viết lại yêu cầu và tiêu chí chấp nhận để chúng trở nên cụ thể và có thể kiểm chứng được.
Khả năng Truy vết (Traceability)	Mỗi yêu cầu, quy tắc, và quyết định đều có một định danh duy nhất từ `TRACEABILITY_ID_REGISTRY`. Có liên kết rõ ràng từ yêu cầu đến nguồn gốc của nó (ví dụ: phỏng vấn bên liên quan, điều khoản luật) và đến các artifact phụ thuộc (ví dụ: thiết kế, test case).	Tồn tại "yêu cầu mồ côi" (orphan requirement) không rõ nguồn gốc hoặc không được liên kết đến bất kỳ thành phần nào khác.	STOP. Yêu cầu BA tác giả bổ sung định danh và liên kết truy vết. Nếu không thể tìm ra nguồn gốc, ESCALATE đến Business Owner để xác nhận hoặc loại bỏ yêu cầu.
Thẩm quyền Nguồn (Source Authority)	Các yêu cầu có nguồn gốc từ một nguồn có thẩm quyền được ghi nhận rõ ràng (ví dụ: yêu cầu tuân thủ từ Phòng Pháp lý, quy trình tài chính từ Kế toán trưởng). Các giả định (assumptions) được đánh dấu và phân biệt rõ với yêu cầu đã được xác thực.	Yêu cầu dựa trên diễn giải cá nhân nhưng được trình bày như một quy định bắt buộc. Diễn giải quy định pháp luật hoặc kế toán mà không có xác nhận từ Owner có thẩm quyền.	ESCALATE. Đánh dấu yêu cầu là `Verification Required` và chuyển đến Owner chuyên môn (Pháp lý, Kế toán, Bảo mật) để xác minh. Không coi yêu cầu này là đã được phê duyệt.
Quyền sở hữu (Ownership)	Mỗi nhóm yêu cầu hoặc quyết định nghiệp vụ quan trọng đều xác định rõ một vai trò hoặc cá nhân chịu trách nhiệm (Owner).	Một quyết định nghiệp vụ có ảnh hưởng lớn được đưa ra nhưng không rõ ai là người chịu trách nhiệm cuối cùng cho quyết định đó.	ESCALATE. Chuyển vấn đề cho Project Manager hoặc Business Sponsor để chỉ định Owner chính thức. Không tiến hành triển khai các yêu cầu liên quan cho đến khi có Owner.
Ranh giới (Boundaries)	Các yêu cầu có tác động đến Bảo mật (Security), Quyền riêng tư (Privacy), Pháp lý (Legal), hoặc Kế toán (Accounting) được xác định, đánh dấu và đã tham vấn Owner liên quan.	Một tính năng xử lý dữ liệu cá nhân nhưng không đề cập đến các yêu cầu của Luật Bảo vệ dữ liệu cá nhân. Một quy trình thay đổi luồng tiền nhưng không có phân tích tác động về mặt kế toán.	STOP & ESCALATE. Dừng ngay lập tức. Gắn cờ các yêu cầu liên quan và chuyển cho các Owner chuyên môn để đánh giá rủi ro và tác động. Không tiếp tục cho đến khi có phản hồi chính thức.
Tác động Thay đổi (Change Impact)	Các tác động của yêu cầu đến quy trình vận hành hiện tại, các hệ thống khác, và các nhóm người dùng cuối đã được phân tích và ghi nhận.	Một yêu cầu được định nghĩa một cách cô lập mà không xem xét việc nó sẽ làm thay đổi công việc hàng ngày của nhân viên kho hoặc bộ phận bán hàng như thế nào.	STOP. Yêu cầu BA tác giả thực hiện phân tích tác động thay đổi (change impact analysis) và bổ sung kết quả vào tài liệu.

Các Tiêu chí Chất lượng Tổng thể của Cổng Đánh giá

Bảng này định nghĩa các tiêu chí chất lượng cốt lõi mà một Senior BA sử dụng để đánh giá tài liệu bàn giao vận hành trước khi thiết lập baseline. Mỗi tiêu chí có điều kiện "Đạt" rõ ràng và hành động cụ thể nếu không đạt. Đây không phải là phê duyệt, mà là một cổng kiểm soát chất lượng nội bộ.

Hạng mục Kiểm tra	Tiêu chí Đạt (Pass)	Hành động nếu Không Đạt (Fail)	Nguồn/Công cụ Tham chiếu
Tính đầy đủ (Completeness)	Mọi mục trong Tier 3 của template đã được điền. Không chứa giá trị placeholder như `TBD`, `<chưa điền>`, hoặc `N/A` không có giải thích.	`STOP`. Trả lại cho người soạn thảo. Yêu cầu hoàn thiện các mục còn trống.	`TMPL-OPS-HANDOVER-001`
Tính nhất quán (Consistency)	Định danh (ID), thuật ngữ, tên trường dữ liệu và quy tắc nghiệp vụ phải khớp với các nguồn canonical của corpus. Ví dụ: `RULE-INV-005` trong tài liệu này phải khớp với định nghĩa trong `CANONICAL_BUSINESS_RULES.md`.	`FAIL`. Gắn cờ (flag) các điểm mâu thuẫn. Yêu cầu chỉnh sửa để đồng bộ với nguồn canonical.	`CANONICAL_BUSINESS_RULES.md`, `CANONICAL_DATA_DICTIONARY.md`, `TRACEABILITY_ID_REGISTRY.md`
Khả năng kiểm thử (Testability)	Mỗi tiêu chí chấp nhận (acceptance criterion) phải đơn nhất, rõ ràng, có thể đo lường, không mơ hồ. QA có thể viết test case trực tiếp từ tiêu chí mà không cần hỏi lại.	`FAIL`. Yêu cầu viết lại tiêu chí. Loại bỏ các từ chủ quan như "nhanh", "tốt", "dễ sử dụng" và thay bằng các chỉ số cụ thể.	`ISTQB CTFL`
Khả năng truy vết (Traceability)	Mọi yêu cầu, quy tắc, quyết định phải có một `trace-id` hợp lệ, liên kết ngược về nguồn gốc (yêu cầu nghiệp vụ, điều khoản pháp lý) và xuôi tới artifact kiểm thử.	`FAIL`. Yêu cầu bổ sung hoặc sửa các `trace-id` còn thiếu/sai. Truy vết là bắt buộc, không phải tùy chọn.	`TRACEABILITY_ID_REGISTRY.md`, `ISO/IEC/IEEE 29148`
Thẩm quyền nguồn (Source Authority)	Nguồn trích dẫn phải phù hợp với bản chất của yêu cầu. Quy tắc pháp lý phải trích dẫn văn bản luật (`vanban.chinhphu.vn`). Yêu cầu nghiệp vụ phải có Business Owner xác nhận.	`FAIL`. Yêu cầu thay nguồn có thẩm quyền hơn. Nếu không có, phải đánh dấu rõ là "Giả định dự án, cần xác minh" (`Verification required`).	`/00-research/00_SOURCE_MAP.md`
Quyền sở hữu (Ownership)	Mỗi quy tắc nghiệp vụ, miền dữ liệu (data domain) và quyết định chính sách phải có một vai trò sở hữu (Owner) được định danh rõ ràng, ví dụ: `Accounting Owner`, `Legal Owner`.	`STOP`. Gửi lại để xác định Owner. Không có Owner nghĩa là không có người chịu trách nhiệm phê duyệt và trả lời câu hỏi.	`/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`
Ranh giới (Boundaries)	Tài liệu không tự diễn giải pháp lý, kế toán, hoặc bảo mật. Thay vào đó, nó xác định các điểm cần review bởi vai trò có thẩm quyền. Dữ liệu nhạy cảm được đánh dấu và xử lý theo quy định.	`STOP & ESCALATE`. Nếu BA vượt ranh giới thẩm quyền (ví dụ: tự quyết định một vấn đề pháp lý), phải dừng và leo thang lên cấp quản lý.	`Luật Bảo vệ dữ liệu cá nhân`, `Luật Kế toán`, `OWASP ASVS`
Tác động thay đổi (Change Impact)	Phần phân tích tác động phải xác định đầy đủ các hệ thống, quy trình, và nhóm người dùng khác bị ảnh hưởng bởi thay đổi được đề xuất. Có kế hoạch thông báo/đào tạo cho các bên liên quan.	`FAIL`. Yêu cầu thực hiện và ghi lại phân tích tác động còn thiếu. Không thể đánh giá rủi ro nếu không biết tác động.	`BABOK Guide` (Knowledge Area: Strategy Analysis)

Kết quả áp dụng checklist lên ví dụ Nova Foods

Phần này ghi lại kết quả áp dụng checklist chất lượng ở mục trên vào nội dung ví dụ hoàn chỉnh của Nova Foods (Tier 3). Đây là một hoạt động rà soát chất lượng nội bộ của BA, không phải là phê duyệt (approval) chính thức từ bất kỳ bên liên quan nào. Kết quả nhằm xác định các điểm cần cải thiện trước khi tài liệu được đưa vào quy trình baseline.

Bảng kết quả rà soát chất lượng ví dụ Nova Foods Ngày rà soát: 2026-08-07 Phiên bản tài liệu được rà soát: v0.9.0

Mã kiểm tra	Hạng mục	Nội dung kiểm tra	Kết quả	Ghi chú & Hành động đề xuất
QG-NF-01	Tính đầy đủ (Completeness)	Tất cả các trường trong template Tier 3 (Mục 3 và 4) đã được điền đầy đủ, không còn placeholder như `<...>` hoặc `TBD`.	Đạt	Tất cả các mục, bảng và trường dữ liệu đã được điền với dữ liệu mô phỏng của Nova Foods. Điều này đáp ứng yêu cầu của một ví dụ hoàn chỉnh.
QG-NF-02	Tính nhất quán (Consistency)	Thuật ngữ nghiệp vụ (ví dụ: `Purchase Order`, `Vendor`, `Invoice`) và định danh (ví dụ: `REQ-NF-...`, `BR-NF-...`) có nhất quán với các artifact quản trị trung tâm không (`CANONICAL_GLOSSARY`, `TRACEABILITY_ID_REGISTRY`).	Không Đạt	Ví dụ sử dụng thuật ngữ `Supplier` ở một vài chỗ trong khi `CANONICAL_GLOSSARY` định nghĩa thuật ngữ chuẩn là `Vendor`. Hành động: Cập nhật tài liệu để sử dụng thống nhất thuật ngữ `Vendor`.
QG-NF-03	Khả năng kiểm thử (Testability)	Các tiêu chí chấp nhận (Acceptance Criteria - AC) được viết dưới dạng có thể kiểm chứng, có thể đo lường, không mơ hồ.	Đạt	Các AC đều cụ thể. Ví dụ: `AC-01` cho `REQ-NF-INV-005` nêu rõ "Hệ thống phải xác thực mã số thuế nhà cung cấp theo định dạng 10 hoặc 13 chữ số". Điều này là một quy tắc rõ ràng, có thể viết test case pass/fail.
QG-NF-04	Khả năng truy vết (Traceability)	Mọi yêu cầu (`Requirement`) trong ví dụ đều có liên kết truy vết ngược về mục tiêu nghiệp vụ (`Business Objective`) và truy vết xuôi đến các mục khác (ví dụ: quy tắc nghiệp vụ, test case).	Đạt	Bảng truy vết tại Mục 4.1 cho thấy rõ `REQ-NF-PROC-012` liên kết ngược về `OBJ-NF-03` (Giảm thời gian xử lý) và liên kết xuôi đến `BR-NF-PROC-045` (Quy tắc tự động đối chiếu). Cấu trúc truy vết hoàn chỉnh.
QG-NF-05	Thẩm quyền nguồn (Source Authority)	Các yêu cầu tuân thủ pháp lý hoặc kế toán có trích dẫn đúng nguồn luật và có ghi chú về việc cần xác minh bởi người có thẩm quyền không.	Đạt	Yêu cầu `REQ-NF-ACC-001` về hóa đơn điện tử đã tham chiếu chính xác đến `Nghị định 123/2020/NĐ-CP`. Quan trọng là tài liệu đã ghi rõ "Cần xác minh bởi Kế toán trưởng trước khi baseline".
QG-NF-06	Quyền sở hữu (Ownership)	Mỗi quy trình, yêu cầu và quyết định chính có được gán một vai trò sở hữu (Owner) rõ ràng không.	Đạt	Mọi yêu cầu đều có trường `Business Owner` được xác định, ví dụ `Trưởng phòng Mua hàng` cho các yêu cầu liên quan đến đơn hàng. Điều này đảm bảo trách nhiệm giải trình.
QG-NF-07	Bảo mật & Riêng tư (Security & Privacy)	Các yêu cầu liên quan đến dữ liệu nhạy cảm, đặc biệt là Thông tin nhận dạng cá nhân (PII - Personally Identifiable Information), có được xác định và có biện pháp bảo vệ đề xuất không.	Đạt (Cần xem xét thêm)	Yêu cầu `REQ-NF-SEC-002` về bảo vệ thông tin nhà cung cấp có đề cập đến việc mã hóa dữ liệu liên hệ. Ghi chú: Đề xuất tham chiếu đến một control cụ thể trong OWASP ASVS (ví dụ: V4.1 Data Classification) để làm rõ hơn yêu cầu. Cần chuyên gia bảo mật rà soát lại.
QG-NF-08	Tác động thay đổi (Change Impact)	Tài liệu có mô tả đầy đủ tác động của hệ thống mới lên các quy trình, vai trò người dùng và các hệ thống liên quan khác không.	Không Đạt	Phân tích tác động chỉ đề cập đến người dùng trong phòng Kế toán và Mua hàng. Tài liệu không đề cập đến tác động tới hệ thống Kho vận (WMS) hiện tại, vốn cần dữ liệu đơn hàng từ ERP để hoạt động. Hành động: Bổ sung mục phân tích tác động tới hệ thống WMS.

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

6.1. Đối chiếu tính nhất quán giữa các Artifact (Cross-File Consistency Check)

Kiểm tra chéo (cross-file check) là bước kiểm soát chất lượng. BA hoặc Reviewer đối chiếu metadata và nội dung giữa artifact nền tảng để phát hiện mâu thuẫn trước khi dùng tài liệu cho bước review tiếp theo. Kiểm tra này xác nhận phiên bản, trạng thái và ngày cập nhật đồng bộ; đồng thời xác nhận nội dung không tuyên bố thẩm quyền hoặc trạng thái trái với metadata. Mâu thuẫn metadata có thể làm sai nguồn tham chiếu, truy vết thay đổi và quyết định review.

Bảng dưới ghi kết quả kiểm tra artifact quản trị trung tâm của dự án Nova Foods ERP. Giá trị kỳ vọng lấy từ hợp đồng đóng băng của tài liệu này: Version v0.9.0, Status IN_REVIEW, date 2026-08-07.

Artifact ID & Tên tệp	Thuộc tính kiểm tra	Giá trị kỳ vọng	Giá trị thực tế	Kết quả	Ghi chú
00_SOURCE_MAP `/00-research/00_SOURCE_MAP.md`	`Version`	`v0.9.0`	`v0.9.0`	Đạt	Nhất quán.
	`Status`	`IN_REVIEW`	`IN_REVIEW`	Đạt	Nhất quán.
	`Last updated date`	`2026-08-07`	`2026-08-07`	Đạt	Nhất quán.
01_CURRICULUM_ARCHITECTURE `/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`	`Version`	`v0.9.0`	`v0.9.0`	Đạt	Nhất quán.
	`Status`	`IN_REVIEW`	`IN_REVIEW`	Đạt	Nhất quán.
	`Last updated date`	`2026-08-07`	`2026-08-07`	Đạt	Nhất quán.
CHAPTER_MANIFEST `/01-curriculum/CHAPTER_MANIFEST.md`	`Version`	`v0.9.0`	`v0.9.0`	Đạt	Nhất quán.
	`Status`	`IN_REVIEW`	`IN_REVIEW`	Đạt	Nhất quán.
	`Last updated date`	`2026-08-07`	`2026-08-07`	Đạt	Nhất quán.
TEMPLATE_MANIFEST `/01-curriculum/TEMPLATE_MANIFEST.md`	`Version`	`v0.9.0`	`v0.9.0`	Đạt	Nhất quán.
	`Status`	`IN_REVIEW`	`IN_REVIEW`	Đạt	Nhất quán.
	`Last updated date`	`2026-08-07`	`2026-08-07`	Đạt	Nhất quán.
TRACEABILITY_ID_REGISTRY `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	`Version`	`v0.9.0`	`v0.9.0`	Đạt	Nhất quán.
	`Status`	`IN_REVIEW`	`IN_REVIEW`	Đạt	Nhất quán.
	`Last updated date`	`2026-08-07`	`2026-08-07`	Đạt	Nhất quán.
CANONICAL_BUSINESS_RULES `/01-curriculum/CANONICAL_BUSINESS_RULES.md`	`Version`	`v0.9.0`	`v0.9.0`	Đạt	Nhất quán.
	`Status`	`IN_REVIEW`	`IN_REVIEW`	Đạt	Nhất quán.
	`Last updated date`	`2026-08-07`	`2026-08-07`	Đạt	Nhất quán.
CANONICAL_DATA_DICTIONARY `/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	`Version`	`v0.9.0`	`v0.9.0`	Đạt	Nhất quán.
	`Status`	`IN_REVIEW`	`IN_REVIEW`	Đạt	Nhất quán.
	`Last updated date`	`2026-08-07`	`2026-08-07`	Đạt	Nhất quán.

Kết luận kiểm tra chéo:

Tất cả artifact quản trị trung tâm (source map, architecture, manifests, registries, catalogs) nhất quán về phiên bản, trạng thái và ngày cập nhật. Nội dung kiểm tra không chứa tuyên bố mâu thuẫn với metadata; không artifact nào tự nhận BASELINED hoặc APPROVED khi trạng thái chung là IN_REVIEW. Không phát hiện mâu thuẫn trong phạm vi kiểm tra này. Corpus có tính nhất quán nội tại tại thời điểm 2026-08-07.

Kết quả chỉ xác nhận nhất quán giữa artifact đã liệt kê. Kết quả không phải phê duyệt nghiệp vụ, pháp lý, kỹ thuật hoặc vận hành; không thay đổi trạng thái IN_REVIEW.

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

Bảng dưới ghi toàn bộ vấn đề mở, giả định dự án và hạng mục cần xác minh tại thời điểm bàn giao. Mục đích: minh bạch rủi ro, chỉ rõ owner, action, artifact ảnh hưởng và hậu quả nếu không xử lý. Không hạng mục nào tự trở thành yêu cầu được phê duyệt nếu chưa được owner có thẩm quyền xác minh và phê duyệt theo quy trình quản trị.

Một giả định là điều kiện được dùng để tiếp tục phân tích nhưng chưa có bằng chứng xác thực. Một hạng mục cần xác minh là diễn giải hoặc yêu cầu dựa trên nguồn bên ngoài cần chuyên gia có thẩm quyền xác nhận. Một vấn đề mở là câu hỏi về phạm vi, chức năng hoặc quyết định chưa được giải quyết.

ID	Loại	Mô tả Chi Tiết	ID/Artifact Bị Ảnh Hưởng	Owner Chịu Trách Nhiệm	Tác Động Nếu Không Giải Quyết	Hành Động Tiếp Theo
ISSUE-OPS-001	Vấn đề mở	Phạm vi truy xuất nguồn gốc (traceability) theo lô sản phẩm chưa được định nghĩa rõ: chưa có quyết định truy vết đến lô nguyên vật liệu của nhà cung cấp hay chỉ đến lô hàng nhập kho Nova Foods.	`BR-TRACE-001` đến `BR-TRACE-015`, yêu cầu module Quản lý Kho (WMS).	Business Owner (Supply Chain)	Yêu cầu không hoàn chỉnh; đội delivery không thể xây dựng và kiểm thử phạm vi truy vết thống nhất. Rủi ro không đáp ứng kỳ vọng nghiệp vụ và `Luật An toàn thực phẩm 55/2010/QH12`.	Business Owner tổ chức buổi quyết định phạm vi với BA và bên vận hành kho. BA ghi quyết định, phạm vi được chọn, artifact bị ảnh hưởng và bằng chứng xác nhận vào nhật ký quyết định trước khi cập nhật business rules.
ASSUME-OPS-001	Giả định	Định dạng và trường dữ liệu hóa đơn điện tử trong ERP được giả định phù hợp với `Nghị định 123/2020/NĐ-CP` và thông tư hướng dẫn hiện hành. Giả định này chưa phải xác nhận tuân thủ.	`BR-FIN-005`, `API-SPEC-EINVOICE-001`, `CANONICAL_DATA_DICTIONARY`	Accounting Owner	Hóa đơn có thể không hợp lệ; quy trình thanh toán khách hàng có thể gián đoạn; Nova Foods có thể chịu rủi ro xử phạt hành chính về thuế.	BA gửi data dictionary và business rules liên quan hóa đơn cho Accounting Owner. Accounting Owner xác nhận bằng văn bản, hoặc trả thay đổi cần thiết. BA cập nhật artifact liên quan theo kết quả xác nhận.
VERIFY-OPS-001	Cần xác minh	Phân loại trường dữ liệu là Dữ liệu Cá Nhân (PII - Personally Identifiable Information) trong `CANONICAL_DATA_DICTIONARY` dựa trên diễn giải sơ bộ của `Luật 91/2025/QH15`. Legal Owner phải xác nhận hoặc hiệu chỉnh phân loại này.	`CANONICAL_DATA_DICTIONARY` (thực thể Customer, Employee), `NFR-SEC-005`	Legal Owner (Data Privacy)	Phân loại sai có thể tạo rủi ro vi phạm yêu cầu bảo vệ dữ liệu cá nhân, trách nhiệm pháp lý và tổn hại uy tín Nova Foods.	BA gửi danh sách trường được đề xuất là PII, mục đích xử lý và artifact liên quan cho Legal Owner. Legal Owner cung cấp xác nhận hoặc hiệu chỉnh bằng chứng bằng văn bản. BA chỉ cập nhật yêu cầu sau khi nhận kết quả đó.
ASSUME-OPS-002	Giả định	Artifact hiện tại không xác định nền tảng công nghệ ERP. Vì vậy, khả năng đáp ứng các NFR bảo mật, gồm kiểm soát chống BOLA (Broken Object Level Authorization) theo `OWASP API Security Top 10 2023`, mới là giả định và chưa được chứng minh trên nền tảng cụ thể.	`NFR-SEC-001` đến `NFR-SEC-010`, `CURRICULUM_ARCHITECTURE`	Technical Architect	Khi nền tảng được chọn, thiết kế bảo mật có thể không khả thi hoặc cần làm lại; hậu quả gồm chi phí tăng và rủi ro bảo mật chưa được xử lý.	Technical Architect xác định nền tảng áp dụng trong artifact có thẩm quyền, sau đó tạo POC kiểm tra xác thực, phân quyền đối tượng và từ chối truy cập trái phép. Kết quả POC phải liên kết tới các NFR bị ảnh hưởng.
VERIFY-OPS-002	Cần xác minh	Đặc tả API trao đổi dữ liệu với đối tác logistics bên thứ ba (3PL) dựa trên thảo luận không chính thức. Đối tác 3PL chưa xác nhận endpoint, payload, xác thực, mã lỗi và luồng xác nhận giao hàng.	`API-SPEC-3PL-SHIP-001`, `API-SPEC-3PL-CONFIRM-001`	3PL Partner Technical Contact	Tích hợp có thể thất bại; xử lý và vận chuyển đơn hàng có thể bị đình trệ; hoạt động kinh doanh Nova Foods bị ảnh hưởng trực tiếp.	BA hoặc Integration Owner gửi bản nháp OpenAPI phiên bản `0.1` cho 3PL Partner Technical Contact. Hai bên rà soát API; liên hệ kỹ thuật 3PL xác nhận hoặc trả danh sách thay đổi bằng văn bản. BA cập nhật đặc tả và truy vết quyết định.

Danh sách này phải được xem xét và cập nhật trong mọi yêu cầu thay đổi ảnh hưởng artifact liên quan. Giải quyết hạng mục không tự động đổi trạng thái artifact. Chỉ quy trình phê duyệt và chốt baseline có thẩm quyền mới được xem xét chuyển artifact từ IN_REVIEW.

Quy tắc Bàn giao và Lan truyền Thay đổi (Trạng thái IN_REVIEW)

Phần này định nghĩa quy tắc bàn giao có kiểm soát cho TMPL-OPS-HANDOVER-001_operational-handover.md và cách thay đổi từ nguồn canonical lan truyền vào tài liệu. Trong trạng thái IN_REVIEW, “bàn giao” (Handoff) là chuyển trách nhiệm review hoặc thực hiện bước tiếp theo trong phát triển học liệu. Bàn giao không phải cho phép đưa nội dung vào vận hành. “Lan truyền thay đổi” (Change Propagation) là cơ chế giữ artifact nhất quán với nguồn canonical của corpus.

Mục tiêu: giữ kiểm soát, toàn vẹn và truy vết trong giai đoạn review. Artifact chưa được phê duyệt và chưa được chốt baseline.

Bảng 1: Quy tắc bàn giao có kiểm soát

ID Quy tắc	Mô tả	Điều kiện kích hoạt	Hành động	Bên nhận	Trách nhiệm Bên nhận
`HO-RULE-01`	Bàn giao `TMPL-OPS-HANDOVER-001` v0.9.0 để review.	Owner hoàn thành trường bắt buộc của template theo hợp đồng tài liệu và hoàn thành self-check.	Owner gửi thông báo qua kênh dự án được chỉ định, kèm liên kết đến bản `v0.9.0` đang được review và danh sách issue còn mở trong section này.	Senior BA Reviewer hoặc QA Reviewer được phân công trong kế hoạch dự án.	Reviewer đối chiếu checklist và yêu cầu section; ghi mọi phát hiện thành comment hoặc issue có thể truy vết; phân loại phát hiện theo tác động; không tự đổi trạng thái `IN_REVIEW`.

Bảng 2: Quy tắc xử lý và lan truyền thay đổi

ID Quy tắc	Loại thay đổi	Quy trình xử lý	Nguồn gốc thay đổi	Ảnh hưởng & Ghi chú
`CP-RULE-01`	Sửa lỗi nhỏ (Typo/Grammar)	Owner sửa trên branch làm việc và commit với message mô tả thay đổi. Không tăng phiên bản nếu sửa không thay đổi ý nghĩa nghiệp vụ, logic, ID, liên kết nguồn hoặc trạng thái.	Phát hiện trong review hoặc self-check.	Thấp. Git lưu lịch sử. Nếu sửa thay đổi ý nghĩa hoặc truy vết, xử lý theo `CP-RULE-02` hoặc `CP-RULE-03`.
`CP-RULE-02`	Cập nhật từ nguồn Canonical	Owner đánh giá tác động khi nguồn canonical thay đổi; cập nhật nội dung bị ảnh hưởng; tạo phiên bản mới, ví dụ `v0.9.1`; ghi lịch sử thay đổi và liên kết nguồn gốc.	`CANONICAL_DATA_DICTIONARY`, `CANONICAL_BUSINESS_RULES`, `TRACEABILITY_ID_REGISTRY` hoặc artifact canonical khác được cập nhật.	Cao. Lan truyền bắt buộc khi thay đổi ảnh hưởng nội dung, ID, quy tắc, dữ liệu hoặc truy vết. Trạng thái artifact vẫn là `IN_REVIEW` cho đến khi quy trình có thẩm quyền quyết định khác.
`CP-RULE-03`	Yêu cầu mâu thuẫn hoặc vượt thẩm quyền	Không cập nhật nội dung mâu thuẫn. Owner tạo issue, ghi yêu cầu, artifact nguồn, bằng chứng mâu thuẫn, tác động, quyết định cần có và owner có thẩm quyền.	Yêu cầu từ reviewer hoặc bên liên quan mâu thuẫn với quy tắc đã xác định hoặc đòi hỏi quyết định ngoài thẩm quyền BA, gồm pháp lý, kế toán hoặc nghiệp vụ.	Bị chặn. Curriculum Architect, Business Owner hoặc owner có thẩm quyền xử lý quyết định. Artifact chỉ được cập nhật sau khi có quyết định được ghi nhận và có thể truy vết.

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

Tuân thủ quy tắc trên là bắt buộc. Trạng thái IN_REVIEW của TMPL-OPS-HANDOVER-001_operational-handover.md phiên bản v0.9.0 không đổi qua quy trình bàn giao, self-check, review hoặc xử lý issue trong section này. Chỉ quy trình phê duyệt và chốt baseline chính thức được định nghĩa trong tài liệu quản trị cấp cao hơn của corpus, gồm /01-curriculum/01_CURRICULUM_ARCHITECTURE.md, mới có thẩm quyền thay đổi trạng thái.

Nội dung Nova Foods trong artifact là mô phỏng giáo dục. Không dùng nội dung này làm chỉ dẫn vận hành, triển khai sản phẩm, xác nhận pháp lý, quyết định kế toán hoặc quyết định kinh doanh thực tế.