/03-templates/TMPL-OPS-SUPPORT-READINESS-001_support-readiness.md — Mẫu Sẵn Sàng Hỗ Trợ Vận Hành 001
Bảng dưới đây định nghĩa các thuộc tính quản trị cốt lõi, định danh và lịch sử thay đổi của tài liệu mẫu này. Việc tuân thủ các quy tắc này là bắt buộc để duy trì tính nhất quán và khả năng truy vết trong toàn bộ corpus của dự án Nova Foods.
| Trường kiểm soát | Giá trị |
|---|---|
| Artifact ID | TMPL-OPS-SUPPORT-READINESS-001 |
| Tên tệp được kiểm soát | /03-templates/TMPL-OPS-SUPPORT-READINESS-001_support-readiness.md |
| Tiêu đề artifact | Mẫu Sẵn Sàng Hỗ Trợ Vận Hành 001: Sẵn Sàng Hỗ Trợ (Support Readiness) |
| Trạng thái (Status) | IN_REVIEW |
| Phiên bản (Version) | v0.9.0 |
| Owner | Principal IT Business Analyst / Technical Curriculum Author |
| Trách nhiệm của Owner | Duy trì tính toàn vẹn của mẫu này, bao gồm cấu trúc 4 tầng (Tier 1-4), metadata quản trị, phiên bản, lịch sử thay đổi, và đảm bảo các liên kết traceability tới các artifact nguồn (ví dụ: yêu cầu, quy tắc nghiệp vụ) được bảo toàn. |
| Giới hạn thẩm quyền của Owner | Việc sở hữu artifact không đồng nghĩa với thẩm quyền phê duyệt nội dung nghiệp vụ, xác nhận tính tuân thủ pháp lý/kế toán, quyết định kiến trúc hệ thống, hay cho phép triển khai production. Vai trò Owner chỉ giới hạn ở việc quản trị vòng đời của template. |
| 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; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND |
| Case study tham chiếu | Nova Foods Trading & Manufacturing — case study mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp. |
| Phân loại artifact | Controlled Template Artifact (Tài liệu mẫu được kiểm soát) |
| Lịch sử thay đổi | v0.9.0 (2026-08-07): Khởi tạo tài liệu tại trạng thái IN_REVIEW. Thiết lập metadata quản trị và cấu trúc 4 tầng (governance, blank template, completed example, quality gate). |
| Giới hạn dữ liệu mô phỏng | Mọi thông tin, dữ liệu, quy trình liên quan đến "Nova Foods" trong tài liệu này (đặc biệt ở Tier 3) đều là dữ liệu tổng hợp, hư cấu cho mục đích giáo dục. Chúng không đại diện cho hoạt động, quyết định, hoặc cấu hình hệ thống của bất kỳ tổ chức thực tế nào và không được sử dụng làm cơ sở cho quyết định vận hành hay sản xuất. |
| Tham chiếu 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à BASELINED. |
| Tham chiếu phê duyệt | Chưa có approval reference tại v0.9.0. Sự tồn tại của metadata, Owner và nội dung review không tạo ra phê duyệt ngầm định từ bất kỳ vai trò nào. |
1. Tier 1 – Metadata, Purpose, and Governance
Mục đích, Phạm vi sử dụng và Quản trị
Tài liệu này xác định mục đích, các quy tắc sử dụng và cấu trúc quản trị cho biểu mẫu TMPL-OPS-SUPPORT-READINESS-001. Mục tiêu là đảm bảo mọi tính năng, phân hệ hoặc thay đổi lớn của hệ thống ERP Nova Foods được chuyển giao cho các đội Vận hành (Operations) và Hỗ trợ (Support) một cách có kiểm soát. Nó cung cấp một nguồn chân lý (single source of truth) duy nhất, cô đọng về các khía cạnh vận hành của một thay đổi, giúp giảm thiểu rủi ro gián đoạn dịch vụ khi triển khai.
Biểu mẫu này phải được sử dụng như một checklist bàn giao chính thức. Mọi thông tin trong một biểu mẫu đã điền phải có thể truy vết ngược về các artifact gốc như tài liệu yêu cầu nghiệp vụ (Business Requirements Document - BRD), đặc tả yêu cầu phần mềm (Software Requirements Specification - SRS), hoặc kết quả kiểm thử chấp nhận người dùng (User Acceptance Testing - UAT).
Metadata Quản trị Bắt buộc
| Thuộc tính | Giá trị | Trách nhiệm và hệ quả |
|---|---|---|
| Artifact ID | TMPL-OPS-SUPPORT-READINESS-001 |
Định danh ổn định của artifact. Mọi tham chiếu, thay đổi và lịch sử phải dùng ID này. |
| Tên tệp Canonical | /03-templates/TMPL-OPS-SUPPORT-READINESS-001_support-readiness.md |
Đường dẫn này là nguồn chân lý của template. Bản sao hoặc bản xuất không thay thế artifact canonical. |
| Trạng thái | IN_REVIEW |
Artifact đang được xem xét. Artifact không được xem là BASELINED, được phê duyệt, hoặc dùng làm bằng chứng phê duyệt triển khai. |
| Owner | Principal IT Business Analyst / Technical Curriculum Author |
Owner duy trì cấu trúc, phiên bản, lịch sử thay đổi, hướng dẫn sử dụng và liên kết canonical của template. Owner không tự quyết nội dung nghiệp vụ, kỹ thuật, pháp lý hoặc kế toán trong biểu mẫu đã điền. |
| Nguồn kiểm soát | /01-curriculum/TEMPLATE_MANIFEST.md |
Manifest quản lý sự tồn tại, phiên bản và trạng thái của template. Nếu metadata giữa tệp này và manifest khác nhau, phải leo thang theo quản trị curriculum trước khi sử dụng thay đổi. |
| Phạm vi authority | Business Owner, Technical Architect, và các chủ sở hữu có thẩm quyền theo lĩnh vực |
Business Owner quyết nội dung nghiệp vụ. Technical Architect quyết chi tiết kỹ thuật. Chủ sở hữu pháp lý hoặc kế toán quyết nội dung thuộc lĩnh vực của họ. IT BA ghi nhận quyết định và nguồn quyết định. |
| Artifact đầu vào | BRD, SRS, UI Mockups, kết quả UAT, CANONICAL_BUSINESS_RULES, registry định danh, từ điển dữ liệu và nguồn đã được kiểm soát |
IT BA phải truy vết nội dung điền vào về artifact nguồn. Không dùng template để tạo quy tắc, ID, định nghĩa dữ liệu hoặc phê duyệt mới. |
| Artifact đầu ra | Knowledge Base Articles, kịch bản Tier 1, tài liệu huấn luyện vận hành, thông báo phát hành | Đầu ra phải phản ánh nội dung đã được xác nhận trong biểu mẫu đã điền. Đầu ra không thay thế BRD, SRS, báo cáo kiểm thử hoặc biên bản nghiệm thu. |
Lịch sử Thay đổi
Bảng này ghi nhận lịch sử quản trị của artifact. Owner phải cập nhật bảng khi thay đổi nội dung, cấu trúc, liên kết canonical, metadata hoặc hướng dẫn sử dụng. Không ghi nhận thay đổi làm mất truy vết, gây nhầm lẫn về phiên bản, hoặc khiến Tier 2 và Tier 3 không còn khớp.
| Trạng thái lịch sử | Artifact / Phiên bản | Actor chịu trách nhiệm | Hành động đã ghi nhận | Đối tượng thay đổi | Kết quả và hệ quả |
|---|---|---|---|---|---|
| Hiện hành | TMPL-OPS-SUPPORT-READINESS-001 tại /03-templates/TMPL-OPS-SUPPORT-READINESS-001_support-readiness.md |
Principal IT Business Analyst / Technical Curriculum Author |
Duy trì artifact ở trạng thái IN_REVIEW. |
Template sẵn sàng hỗ trợ vận hành và metadata quản trị. | Artifact còn đang xem xét. Không có baseline hoặc phê duyệt được ghi nhận trong section này. |
| Kiểm soát thay đổi bắt buộc | Mọi phiên bản tiếp theo | Owner của artifact | Ghi thay đổi vào lịch sử trước khi phát hành bản thay đổi cho người sử dụng. | Phiên bản, cấu trúc, hướng dẫn, liên kết và nội dung template. | Người dùng có thể xác định actor, thay đổi, authority và ảnh hưởng của thay đổi. |
| Thay đổi cấu trúc | Tier 2 và Tier 3 | Owner phối hợp các chủ sở hữu có thẩm quyền | Cập nhật Tier 3 khi Tier 2 thêm, bớt hoặc sửa cấu trúc. | Cột, trường, phần hoặc quy tắc điền trong template trống. | Ví dụ Nova Foods tiếp tục phản ánh đúng template. Không đồng bộ tạo rủi ro bàn giao sai hoặc thiếu thông tin. |
| Thay đổi liên artifact | Artifact bị ảnh hưởng trong corpus | Owner và chủ sở hữu artifact liên quan | Leo thang theo /01-curriculum/01_CURRICULUM_ARCHITECTURE.md. |
Thay đổi ảnh hưởng artifact khác, quy tắc nghiệp vụ, ID, dữ liệu hoặc nguồn. | Owner không đơn phương phê duyệt thay đổi vượt authority. Quyết định phải thuộc đúng chủ sở hữu. |
Quy tắc sử dụng
| Tình huống | Khi nào sử dụng | Khi nào KHÔNG sử dụng |
|---|---|---|
| Phát hành | Chuẩn bị cho việc triển khai một phân hệ ERP mới, một tính năng lớn, hoặc một luồng nghiệp vụ được thay đổi đáng kể. | Cho các bản vá lỗi nhỏ không làm thay đổi giao diện người dùng hoặc quy trình nghiệp vụ. |
| Thay đổi | Khi một thay đổi cấu hình hệ thống (ví dụ: quy tắc thuế, luồng phê duyệt) có ảnh hưởng trực tiếp đến người dùng cuối. | Cho các thay đổi hạ tầng hoặc tái cấu trúc kỹ thuật (refactoring) nội bộ không có tác động ra bên ngoài. |
| Mục đích | Để tổng hợp thông tin vận hành cho đội hỗ trợ, tạo tài liệu hướng dẫn và kịch bản xử lý sự cố. | Thay thế cho tài liệu đặc tả yêu cầu, thiết kế kỹ thuật, báo cáo kiểm thử chi tiết hoặc biên bản nghiệm thu dự án. |
Quản trị, Đầu vào và Đầu ra
Bảng này xác định các vai trò, trách nhiệm và luồng thông tin liên quan đến biểu mẫu. Việc tuân thủ cấu trúc này là bắt buộc để duy trì tính nhất quán và khả năng truy vết trong toàn bộ vòng đời sản phẩm tại Nova Foods.
| Hạng mục quản trị | Mô tả và Trách nhiệm |
|---|---|
| Owner (Biểu mẫu gốc) | Principal IT Business Analyst / Technical Curriculum Author. Chịu trách nhiệm duy trì cấu trúc, phiên bản, lịch sử thay đổi và hướng dẫn của biểu mẫu này. Không có thẩm quyền quyết định nội dung trong các biểu mẫu đã điền. |
| Owner (Biểu mẫu đã điền) | IT Business Analyst của dự án/tính năng cụ thể. Chịu trách nhiệm thu thập, điền đầy đủ thông tin, truy vết về artifact nguồn, và lấy xác nhận từ các bên liên quan. |
| Người sử dụng (Consumers) | Đội Hỗ trợ Kỹ thuật Cấp 1 & 2 (Tier 1 & 2 Support), Đội Vận hành Hệ thống (System Operations), Chủ sở hữu Nghiệp vụ (Business Owner), Chủ sản phẩm (Product Owner). |
| Điều kiện tiên quyết (Prerequisites) | Tính năng đã hoàn thành UAT và được ký duyệt. Tài liệu yêu cầu (BRD/SRS), thiết kế giao diện (UI Mockups) và các quy tắc nghiệp vụ (CANONICAL_BUSINESS_RULES) đã được baseline. |
| Sản phẩm đầu ra (Downstream Artifacts) | Các bài viết trong cơ sở tri thức (Knowledge Base Articles), kịch bản hỗ trợ cho Tier 1, tài liệu huấn luyện cho đội vận hành, thông báo phát hành cho người dùng cuối. |
| Thẩm quyền (Authority) | Business Owner của tính năng có thẩm quyền cao nhất đối với nội dung nghiệp vụ (ví dụ: quy trình, quy tắc). Technical Architect có thẩm quyền đối với các chi tiết kỹ thuật. IT BA là người tổng hợp và ghi nhận, không tự quyết định các nội dung này. |
| Leo thang (Escalation) | Mọi mâu thuẫn về nội dung hoặc sự không rõ ràng phải được leo thang đến đúng chủ sở hữu có thẩm quyền (ví dụ: nghiệp vụ, pháp lý, kế toán, kỹ thuật). IT BA chịu trách nhiệm ghi lại vấn đề và quyết định cuối cùng, không tự diễn giải hay đưa ra kết luận thay cho vai trò có thẩm quyền. |
Định danh Canonical, Liên kết và Nghĩa vụ Kiểm soát Thay đổi
Template này không tồn tại độc lập. Nó là một phần được kiểm soát của bộ học liệu Nova Foods, với định danh, nguồn gốc và các ràng buộc được quản trị chặt chẽ.
1. Định danh và Manifest
Sự tồn tại và định danh của template này được đăng ký và quản lý bởi một manifest trung tâm. Điều này đảm bảo rằng không có các phiên bản trôi nổi, không được kiểm soát.
| Thuộc tính Quản trị | Giá trị Canonical | Diễn giải |
|---|---|---|
| Artifact ID | TMPL-OPS-SUPPORT-READINESS-001 |
Mã định danh duy nhất của template trong toàn bộ corpus. |
| Tên tệp Canonical | /03-templates/TMPL-OPS-SUPPORT-READINESS-001_support-readiness.md |
Đường dẫn tệp là nguồn chân lý (source of truth). Mọi bản sao hoặc xuất bản khác đều là thứ cấp. |
| Nguồn kiểm soát | /01-curriculum/TEMPLATE_MANIFEST.md |
Sự tồn tại, phiên bản và trạng thái của template này được đăng ký và theo dõi tại Template Manifest. |
| Trạng thái quản trị | IN_REVIEW |
Template đang được xem xét. Trạng thái này không phải baseline hoặc phê duyệt. |
2. Liên kết Nguồn và Traceability
Template này không tự tạo ra quy tắc hay định nghĩa. Nó sử dụng các đối tượng đã được định nghĩa và kiểm soát ở nơi khác trong corpus để đảm bảo tính nhất quán và truy vết nguồn gốc (traceability). Khi điền vào ví dụ ở Tier 3, người dùng phải tuân thủ các quy tắc sau:
| Nguồn Canonical Phải Tuân thủ | Quy tắc Bắt buộc | Ví dụ Áp dụng trong Tier 3 |
|---|---|---|
/01-curriculum/TRACEABILITY_ID_REGISTRY.md |
Mọi định danh yêu cầu, use case, test case, v.v. được sử dụng phải tồn tại trong registry định danh. | Khi tham chiếu một yêu cầu, phải dùng ID đã đăng ký như RQ-NOVA-SCM-105, không được tự tạo ID mới. |
/01-curriculum/CANONICAL_BUSINESS_RULES.md |
Mọi quy tắc nghiệp vụ (business rule) được đề cập phải là một quy tắc đã được định nghĩa và gán mã trong catalog quy tắc nghiệp vụ. | Không được viết "Hệ thống phải tính thuế theo luật", mà phải tham chiếu BR-NOVA-FIN-007: Tính thuế GTGT đầu ra cho hóa đơn bán hàng. |
/01-curriculum/CANONICAL_DATA_DICTIONARY.md |
Mọi trường dữ liệu (data element) được đề cập phải được định nghĩa trong từ điển dữ liệu. | Thay vì nói "tên khách hàng", phải sử dụng định danh chính tắc như DE-NOVA-CUST-004: Customer Legal Name. |
/00-research/00_SOURCE_MAP.md |
Mọi tuyên bố về việc tuân thủ một tiêu chuẩn bên ngoài (ví dụ: ISO, OWASP) phải có nguồn gốc rõ ràng từ Source Map. | Nếu một checklist hỗ trợ nhắc đến tiêu chuẩn bảo mật, nó phải tham chiếu đến nguồn như OWASP ASVS đã được xác minh. |
3. Nghĩa vụ Kiểm soát Thay đổi
Mọi thay đổi đối với template này đều phải tuân theo một quy trình kiểm soát nghiêm ngặt để bảo toàn tính toàn vẹn của học liệu.
- Không sửa đổi thầm lặng: Mọi thay đổi, dù nhỏ, đều phải được ghi nhận trong bảng Lịch sử Thay đổi ở đầu tài liệu. Owner ghi actor, hành động, đối tượng thay đổi, lý do, authority và hệ quả của thay đổi.
- Quản lý phiên bản:
- Sửa lỗi chính tả, làm rõ câu chữ không ảnh hưởng cấu trúc: Tăng phiên bản phụ (ví dụ:
v0.9.0->v0.9.1). - Thay đổi cấu trúc của template (thêm/bớt/sửa cột ở Tier 2): Phải tăng phiên bản chính sau khi được baseline (ví dụ:
v1.0.0->v2.0.0). - Đồng bộ hóa các Tier: Nếu cấu trúc của Tier 2 (template trống) bị thay đổi, Tier 3 (ví dụ Nova Foods) phải được cập nhật lại toàn bộ để phản ánh cấu trúc mới. Đây là yêu cầu bắt buộc để đảm bảo ví dụ luôn khớp với template.
- Thẩm quyền: Owner của artifact này có trách nhiệm thực thi quy trình thay đổi nhưng không có quyền đơn phương phê duyệt các thay đổi về cấu trúc hoặc nội dung có ảnh hưởng đến các artifact khác. Mọi thay đổi lớn phải tuân theo quy trình quản trị chung được mô tả trong
/01-curriculum/01_CURRICULUM_ARCHITECTURE.md. - Hệ quả khi không tuân thủ: Thay đổi không có lịch sử, không có truy vết nguồn, vượt authority, hoặc làm Tier 2 và Tier 3 lệch nhau không được xem là thay đổi được kiểm soát. IT BA phải ghi nhận vấn đề và leo thang đến Owner cùng chủ sở hữu có thẩm quyền.
2. Tier 2 ? Blank Copy-Paste-Ready Template
Đây là mẫu tài liệu trống, dùng để sao chép và điền thông tin khi chuẩn bị bàn giao một hệ thống hoặc tính năng mới cho đội Vận hành (Operations) và Hỗ trợ (Support). Mục tiêu là đảm bảo đội hỗ trợ có đủ thông tin cần thiết để xử lý sự cố và trả lời câu hỏi của người dùng.
MẪU CHUẨN BỊ SẴN SÀNG HỖ TRỢ VẬN HÀNH (OPERATIONAL SUPPORT READINESS TEMPLATE)
Phần A: Thông tin chung
Bảng này chứa các metadata cơ bản để định danh và theo dõi tài liệu.
| Trường thông tin | Hướng dẫn điền |
|---|---|
| ID Chuẩn Bị Hỗ Trợ | <Điền ID theo định dạng: SR-YYYYMMDD-XXX, ví dụ: SR-20261025-001> |
| Tên Hệ Thống / Tính Năng | <Ghi tên đầy đủ, rõ ràng của hệ thống/tính năng được bàn giao, ví dụ: Hệ thống Quản lý Khuyến mãi (Promotions Management System)> |
| Phiên Bản (Version) | <Ghi phiên bản của hệ thống/tính năng đang được bàn giao, ví dụ: v1.0.0> |
| Mã Định Danh Yêu Cầu Gốc | <Tham chiếu đến ID của yêu cầu nghiệp vụ hoặc user story gốc, ví dụ: REQ-SALES-042> |
| Ngày Chuẩn Bị | <YYYY-MM-DD> |
| Người Chuẩn Bị | <Tên và vai trò của người điền mẫu, ví dụ: Nguyễn Văn An, Development Lead> |
Phần B: Tổng quan về Hệ thống / Tính năng
Mô tả ngắn gọn mục đích, người dùng và các môi trường mà hệ thống hoạt động.
| Trường thông tin | Hướng dẫn điền |
|---|---|
| Mô Tả Chức Năng | <Mô tả ngắn gọn mục đích kinh doanh. Hệ thống này làm gì? Giải quyết vấn đề gì cho Nova Foods? Ví dụ: Tính năng này cho phép phòng Marketing tạo và quản lý các chương trình khuyến mãi theo sản phẩm, khu vực và nhóm khách hàng.> |
| Người Dùng Chính | <Liệt kê các vai trò người dùng chính sẽ tương tác với hệ thống. Ví dụ: Nhân viên Marketing, Quản lý Bán hàng, Nhân viên Kế toán.> |
| Kiến Trúc & Sơ Đồ | <Dẫn link đến tài liệu kiến trúc hoặc sơ đồ hệ thống (nếu có). Ví dụ: Xem tài liệu kiến trúc tại /docs/architecture/promotions-system.md> |
| Môi Trường Triển Khai | <Đánh dấu (x) vào các môi trường có triển khai tính năng này: [ ] Production, [ ] Staging, [ ] UAT> |
Phần C: Lộ trình Leo thang Hỗ trợ (Support Escalation Path)
Escalation Path là quy trình chuyển một sự cố từ cấp hỗ trợ thấp lên cấp cao hơn khi không thể giải quyết.
| Cấp Hỗ Trợ (Tier) | Đội/Vai Trò Chịu Trách Nhiệm | Kênh Liên Hệ & SLA Phản Hồi | Giờ Hoạt Động |
|---|---|---|---|
| Tier 1 (T1) | <Ví dụ: IT Helpdesk> |
<Ví dụ: Email: helpdesk@nova-foods.vn; SLA: 1 giờ> |
<Ví dụ: 8:00 - 17:30, Thứ 2 - Thứ 6> |
| Tier 2 (T2) | <Ví dụ: Application Support Team> |
<Ví dụ: Slack: #app-support; SLA: 30 phút> |
<Ví dụ: 24/7 (theo ca trực)> |
| Tier 3 (T3) | <Ví dụ: Development Team (Backend)> |
<Ví dụ: Jira ticket; PagerDuty; SLA: 15 phút (cho sự cố P1)> |
<Ví dụ: 24/7 (on-call)> |
Phần D: Giám sát, Cảnh báo và Sổ tay Vận hành (Runbook)
Runbook là tài liệu hướng dẫn chi tiết cách xử lý các sự cố hoặc thực hiện các tác vụ vận hành đã biết trước.
| Tên Cảnh Báo / Triệu Chứng Sự Cố | Công Cụ Giám Sát | Ý Nghĩa và Mức Độ Ưu Tiên | Các Bước Chẩn Đoán & Khắc Phục (Runbook) |
|---|---|---|---|
<Ví dụ: API_Latency_High_P2> |
<Ví dụ: Datadog, Prometheus> |
<Ví dụ: P2 - Độ trễ API khuyến mãi > 2s. Ảnh hưởng trải nghiệm người dùng nhưng hệ thống vẫn hoạt động.> |
<1. Kiểm tra log của service promotions-api để tìm lỗi. 2. Kiểm tra tải của DB. 3. Nếu DB quá tải, liên hệ đội T2 DBA. 4. Link đến runbook chi tiết: /runbooks/RB-PROMO-001.md> |
<Ví dụ: Người dùng báo không tạo được khuyến mãi> |
<Không áp dụng (User-reported)> |
<Ví dụ: P3 - Lỗi chức năng. Cần điều tra trong vòng 4 giờ làm việc.> |
<1. Yêu cầu người dùng cung cấp payload JSON đã gửi. 2. Thử tái hiện lỗi trên môi trường Staging. 3. Kiểm tra log ứng dụng với correlation ID. 4. Link đến runbook chi tiết: /runbooks/RB-PROMO-002.md> |
<Điền thêm các cảnh báo và sự cố dự kiến khác> |
<...> |
<...> |
<...> |
Phần E: Các Phụ thuộc Hệ thống (System Dependencies)
Liệt kê các hệ thống, API, hoặc cơ sở dữ liệu khác mà hệ thống này phụ thuộc để hoạt động.
| Tên Hệ Thống Phụ Thuộc | Điểm cuối (Endpoint) / Vị trí | Ảnh Hưởng Khi Lỗi | Owner Liên Hệ |
|---|---|---|---|
<Ví dụ: API Xác thực Người dùng> |
<Ví dụ: https://auth.api.nova-foods.vn/v1/token> |
<Toàn bộ chức năng yêu cầu đăng nhập sẽ thất bại.> |
<Đội Identity & Access Management> |
<Ví dụ: Cơ sở dữ liệu Sản phẩm> |
<Ví dụ: Host: pg-products.db.nova-foods.internal, DB: products_db> |
<Không thể lấy thông tin sản phẩm để áp dụng khuyến mãi.> |
<Đội Data Platform> |
<Điền thêm các phụ thuộc khác> |
<...> |
<...> |
<...> |
Phần F: Xem xét và Ký duyệt (Review and Sign-off)
Sự ký duyệt xác nhận rằng các bên liên quan đã xem xét thông tin và đồng ý rằng hệ thống đã sẵn sàng để được hỗ trợ.
| Vai Trò | Người Ký Duyệt | Ngày Ký Duyệt | Ghi Chú / Điều Kiện |
|---|---|---|---|
| Development Lead | <Tên người đại diện đội phát triển> |
<YYYY-MM-DD> |
<Xác nhận thông tin kỹ thuật là chính xác.> |
| QA Lead | <Tên người đại diện đội kiểm thử> |
<YYYY-MM-DD> |
<Xác nhận hệ thống đã đạt các tiêu chí chất lượng và các sự cố đã biết đã được ghi nhận.> |
| Operations/Support Lead | <Tên người đại diện đội vận hành/hỗ trợ> |
<YYYY-MM-DD> |
<Xác nhận đã nhận đủ thông tin và đội hỗ trợ đã sẵn sàng tiếp nhận.> |
Các cấu phần quản trị, truy vết và phê duyệt
Các bảng dưới đây là khung sườn bắt buộc để quản lý vòng đời, truy vết nguồn gốc, ghi nhận các quyết định quan trọng, và theo dõi quá trình phê duyệt của tài liệu sẵn sàng vận hành. Mọi trường phải được điền đầy đủ, không được để trống hoặc dùng các giá trị chung chung như "N/A" trừ khi được quy định rõ.
1. Lịch sử Phiên bản (Version History)
Bảng này ghi lại mọi thay đổi quan trọng của tài liệu, đảm bảo tính toàn vẹn và khả năng kiểm tra lại lịch sử. Mỗi khi nội dung có sự thay đổi về yêu cầu, quyết định, hoặc phạm vi, một dòng mới phải được thêm vào.
| Phiên bản | Ngày cập nhật | Người thay đổi | Tóm tắt thay đổi |
|---|---|---|---|
<vX.Y.Z> |
<YYYY-MM-DD> |
<Họ tên và vai trò> |
<Mô tả ngắn gọn, súc tích về các thay đổi chính trong phiên bản này. Ví dụ: "Khởi tạo tài liệu", "Cập nhật mục 3.2 theo quyết định EXC-001".> |
2. Truy vết Yêu cầu và Bằng chứng (Traceability & Evidence)
Mục đích của bảng này là tạo ra một "ma trận truy vết" (traceability matrix), liên kết từng hạng mục sẵn sàng vận hành ngược về yêu cầu nghiệp vụ, quy tắc, hoặc tài liệu nguồn đã sinh ra nó. Điều này cực kỳ quan trọng cho việc kiểm thử, quản lý thay đổi và kiểm toán (audit).
ID Mục Sẵn sàng (SRR-ID) |
Mô tả mục sẵn sàng vận hành | ID Yêu cầu/Quy tắc nguồn | ID Bằng chứng (EVD-ID) |
Ghi chú |
|---|---|---|---|---|
SRR-<NNN> |
<Mô tả cụ thể hạng mục cần kiểm tra. Ví dụ: "Tài liệu đào tạo cho nhân viên hỗ trợ Tier 1 đã được phê duyệt và đăng tải lên hệ thống LMS."> |
<ID của yêu cầu nghiệp vụ (FR), phi chức năng (NFR), hoặc quy tắc nghiệp vụ (BR) liên quan. Ví dụ: NFR-TRAIN-001, BR-SUPPORT-005> |
<ID định danh của bằng chứng. Ví dụ: EVD-LMS-015, là link đến tài liệu trên hệ thống hoặc biên bản phê duyệt.> |
<Ghi chú làm rõ bối cảnh hoặc các chi tiết quan trọng khác nếu cần thiết.> |
3. Quyết định và Ngoại lệ (Decisions & Exceptions)
Ghi nhận lại một cách chính thức các quyết định quan trọng và các trường hợp ngoại lệ được chấp thuận trong quá trình chuẩn bị. Điều này giúp tránh tranh cãi và hiểu lầm về sau.
- Quyết định (Decision): Sự lựa chọn một phương án trong số nhiều phương án khả thi.
- Ngoại lệ (Exception): Sự chấp thuận cho một hạng mục không tuân thủ hoàn toàn theo một quy định hoặc tiêu chuẩn đã đặt ra.
| ID | Loại | Người/Vai trò quyết định | Ngày | Mô tả, Lý do và Tác động |
|---|---|---|---|---|
<DEC/EXC-NNN> |
<Quyết định / Ngoại lệ> |
<Tên và vai trò của người có thẩm quyền phê duyệt. Ví dụ: Giám đốc Vận hành, Trưởng phòng Kỹ thuật.> |
<YYYY-MM-DD> |
<Mô tả rõ ràng quyết định/ngoại lệ là gì, tại sao nó được đưa ra, và các tác động (tích cực, tiêu cực, rủi ro chấp nhận) của nó đến dự án hoặc hệ thống.> |
4. Xem xét và Phê duyệt (Review & Sign-off)
Bảng này ghi lại sự phê duyệt chính thức từ các bên liên quan có thẩm quyền. "Sign-off" là hành động xác nhận cuối cùng rằng tài liệu đã đầy đủ, chính xác và được chấp thuận để đưa vào triển khai. Thiếu sign-off từ các vai trò bắt buộc, kế hoạch sẵn sàng vận hành không có hiệu lực.
| Vai trò | Người xem xét | Ngày xem xét | Kết quả | Ghi chú / Điều kiện phê duyệt |
|---|---|---|---|---|
<Vai trò nghiệp vụ/kỹ thuật có thẩm quyền, ví dụ: Business Owner, Operations Lead, QA Lead, Security Officer> |
<Họ và tên người đại diện cho vai trò đó> |
<YYYY-MM-DD> |
<Chọn một: Đã duyệt / Yêu cầu thay đổi / Đã duyệt với điều kiện> |
<Nếu "Yêu cầu thay đổi", ghi rõ các điểm cần sửa. Nếu "Đã duyệt với điều kiện", ghi rõ các điều kiện phải được đáp ứng trước hoặc sau go-live.> |
Hướng dẫn điền và Quy tắc Validate cho các trường
Phần này cung cấp hướng dẫn chi tiết, các giá trị được phép, và quy tắc validate (xác thực) cho từng trường trong template. Việc tuân thủ các quy tắc này đảm bảo tính nhất quán, rõ ràng và khả năng kiểm toán (auditability) của tài liệu.
1. Hướng dẫn chung cho Metadata của tài liệu
Các trường metadata phải được điền đầy đủ và chính xác để xác định phạm vi và phiên bản của tài liệu.
| Tên trường | Hướng dẫn và Quy tắc Validate | Ví dụ |
|---|---|---|
Support Readiness ID |
Bắt buộc. Định dạng: SRR-<MÃ_HỆ_THỐNG>-YYYYMMDD-NNN. <MÃ_HỆ_THỐNG> phải khớp với mã trong TRACEABILITY_ID_REGISTRY. NNN là số thứ tự. |
SRR-ERPCORE-20261020-001 |
System / Feature Name |
Bắt buộc. Tên đầy đủ của hệ thống hoặc tính năng. Phải nhất quán với các tài liệu kiến trúc và yêu cầu khác. | Nova Foods ERP - Core Accounting Module |
Version |
Bắt buộc. Phải tuân theo quy tắc Semantic Versioning (SemVer) vX.Y.Z. SemVer là một tiêu chuẩn để đánh số phiên bản phần mềm. |
v1.2.0 |
Go-Live Date |
Bắt buộc. Ngày dự kiến triển khai lên môi trường production. "Go-Live" là thuật ngữ chỉ thời điểm một hệ thống chính thức đi vào hoạt động. Định dạng: YYYY-MM-DD. |
2026-10-20 |
Impact Level |
Bắt buộc. Mức độ ảnh hưởng tới nghiệp vụ nếu hệ thống/tính năng gặp sự cố. Giá trị cho phép: CRITICAL (nghiêm trọng, dừng toàn bộ hoạt động kinh doanh chính), HIGH (cao, ảnh hưởng lớn đến nhiều người dùng), MEDIUM (trung bình, ảnh hưởng một phần), LOW (thấp, ảnh hưởng nhỏ). |
HIGH |
Document Status |
Bắt buộc. Trạng thái của tài liệu này. Giá trị cho phép: DRAFT, IN_REVIEW, APPROVED, SUPERSEDED. |
IN_REVIEW |
2. Hướng dẫn cho các bảng nội dung
| Tên bảng / Mục | Tên trường | Hướng dẫn và Quy tắc Validate |
|---|---|---|
| Support Contact Matrix | Support Tier |
Giá trị cho phép: L1 (Hỗ trợ cấp 1), L2 (Hỗ trợ cấp 2), L3 (Kỹ sư phát triển), Vendor (Nhà cung cấp). |
Contact Info |
Ưu tiên email nhóm, kênh chat chung (vd: MS Teams Channel, Slack Channel) thay vì thông tin cá nhân để đảm bảo tính liên tục khi có thay đổi nhân sự. | |
| Key Scenarios & Runbooks | Runbook Link |
"Runbook" là tài liệu hướng dẫn từng bước để xử lý một sự cố hoặc thực hiện một tác vụ vận hành cụ thể. Link phải trỏ đến phiên bản được kiểm soát của Runbook trong hệ thống quản lý tài liệu (vd: Confluence, SharePoint), không dùng link tới máy cá nhân. |
| Quyết định và Ngoại lệ | ID |
Bắt buộc. Định dạng DEC-NNN cho quyết định, EXC-NNN cho ngoại lệ. |
Approver Role |
Phải là một vai trò chính thức trong tổ chức (vd: Operations Director, Head of Finance), không phải tên cá nhân. |
|
| Xem xét và Phê duyệt | Kết quả |
Giá trị cho phép: Đã duyệt, Yêu cầu thay đổi, Đã duyệt với điều kiện. |
Ghi chú / Điều kiện phê duyệt |
Bắt buộc phải điền nếu Kết quả là Yêu cầu thay đổi hoặc Đã duyệt với điều kiện. |
3. Quy tắc tham chiếu Bí mật an toàn (Safe Secret Reference)
Tuyệt đối KHÔNG ghi trực tiếp mật khẩu, API key, token, hoặc bất kỳ thông tin nhạy cảm nào vào tài liệu này. Thay vào đó, sử dụng định dạng tham chiếu an toàn để trỏ tới vị trí của bí mật trong một hệ thống quản lý bí mật (secret management system) như HashiCorp Vault hoặc Azure Key Vault.
- Định dạng bắt buộc:
SECRET_REF::<vault_name>@<secret_path>#<key> - Giải thích:
SECRET_REF::là tiền tố cố định để nhận diện đây là một tham chiếu bí mật.<vault_name>: Tên của hệ thống quản lý bí mật (ví dụ:corp-vault,azure-prod-kv).<secret_path>: Đường dẫn đến nơi lưu trữ nhóm bí mật.<key>: Tên của khóa (key) chứa giá trị bí mật cụ thể.
- Ví dụ: Thay vì viết
password: "p@ssw0rd123", hãy viếtpassword: SECRET_REF::corp-vault@nova-foods/erp/prod-db#password.
Việc sử dụng tham chiếu này đảm bảo rằng tài liệu không chứa thông tin nhạy cảm, và việc truy cập vào bí mật thực sự được kiểm soát bởi quyền trên hệ thống quản lý bí mật. Đội hỗ trợ sẽ cần quyền truy cập riêng vào vault để lấy giá trị khi cần thiết.
3. Tier 3 ? Fully Completed Nova Foods Case: Core Record
Phần này cung cấp ví dụ hoàn chỉnh, điền đầy đủ dữ liệu mô phỏng của Nova Foods vào mẫu trống từ Tier 2. Kịch bản chỉ mang tính giáo dục, không đại diện hoạt động thực tế của bất kỳ tổ chức nào.
ID Sự vụ / Yêu cầu: OPS-20260815-001
Bảng 1: Thông tin chung về Sự vụ
| Trường dữ liệu | Giá trị | Nguồn / Người xác nhận |
|---|---|---|
| Hệ thống / Module bị ảnh hưởng | NovaFoods ERP (Module INV) và Hệ thống WMS | Trần Thị Bích (IT Business Analyst) |
| Mức độ ưu tiên | Cao |
Nguyễn Văn An (Điều phối kho), được xác nhận bởi Lê Minh Tuấn (Trưởng phòng Vận hành) |
| Người báo cáo | Nguyễn Văn An |
Quan sát trực tiếp |
| Vai trò người báo cáo | Nhân viên điều phối kho | Hồ sơ nhân sự Nova Foods |
| Ngày báo cáo | 2026-08-15 09:15 AM (Asia/Ho_Chi_Minh) |
Dữ liệu hệ thống ticket Jira-OPS-3441 |
| Người phụ trách (BA/Support) | Trần Thị Bích |
Phân công từ IT Helpdesk |
Bảng 2: Mô tả Vấn đề và Ảnh hưởng Nghiệp vụ
| Trường dữ liệu | Giá trị | Nguồn / Phân loại |
|---|---|---|
| Mô tả Vấn đề (As-Is) | Phiếu xuất kho (PXK-2026-08-12345) được tạo tự động từ đơn hàng bán (SO-98765) gửi từ ERP sang WMS có tổng khối lượng (gross weight) bị làm tròn sai. ERP tính toán và hiển thị đúng là 150.75 KG, nhưng dữ liệu gửi qua API tới WMS là 150 KG. |
Log-ID: ERP-API-OUT-20260815-AEF891 |
| Nhu cầu Nghiệp vụ (To-Be) | Tổng khối lượng trên phiếu xuất kho trong ERP phải được gửi và ghi nhận chính xác trong WMS với đầy đủ hai chữ số thập phân, tuân thủ quy tắc nghiệp vụ RULE-INV-017. |
CANONICAL_BUSINESS_RULES.md |
| Ảnh hưởng Nghiệp vụ | 1. Sai lệch tồn kho: Gây chênh lệch giữa sổ sách ERP và tồn kho vật lý tại kho WMS. 2. Trì hoãn vận hành: Nhân viên kho phải kiểm tra và điều chỉnh thủ công, làm chậm quá trình xuất hàng. 3. Rủi ro tài chính: Chi phí kiểm kê thủ công đột xuất ước tính 8,000,000 VND/tuần. Nguy cơ phạt hợp đồng do giao hàng trễ. |
Phỏng vấn Lê Minh Tuấn (Trưởng phòng Vận hành) |
Bảng 3: Phân tích Nguyên nhân Gốc rễ (Root Cause Analysis - RCA)
| Sự kiện / Quan sát (Fact) | Nguồn Bằng chứng | Phân tích / Suy luận | Quy tắc liên quan |
|---|---|---|---|
1. Payload JSON gửi từ ERP tới endpoint POST /api/v1/dispatch-notes của WMS chứa trường "grossWeight": 150. |
Log-ID: ERP-API-OUT-20260815-AEF891 |
Dữ liệu mất phần thập phân trước khi WMS nhận payload. | REQ-INT-004 |
2. Đặc tả API nova-wms-api-spec-v1.2.yaml định nghĩa grossWeight là kiểu number. |
/specs/nova-wms-api-spec-v1.2.yaml |
WMS nhận dữ liệu theo đặc tả. Bằng chứng không chỉ ra lỗi thuộc WMS. | OAS 3.1.1 |
3. Mã nguồn lớp DispatchService trong ERP có đoạn code: payload.setGrossWeight((int) order.calculateTotalWeight());. |
Rà soát mã nguồn file erp/src/inv/DispatchService.java |
Ép kiểu từ Decimal hoặc Double sang Integer xảy ra trước khi serialize JSON. Phần thập phân bị loại bỏ. Đây là nguyên nhân gốc rễ. |
RULE-INV-017 |
Bảng 4: Phân tích Phương án, Tiêu chí và Quyết định
| # | Phương án | Ưu điểm | Nhược điểm | Chi phí ước tính (giờ công) |
|---|---|---|---|---|
| 1 | Sửa lỗi tại ERP: Thay đổi logic trong DispatchService để không ép kiểu grossWeight thành int. |
- Xử lý tại nguồn gốc. - Tuân thủ kiến trúc: ERP là nguồn chân lý. - Chi phí thấp nhất trong phương án đã phân tích. |
- Cần chu kỳ deploy ERP. - Cần kiểm thử hồi quy luồng tạo phiếu xuất kho và tích hợp WMS. |
- Dev: 16 - Test: 8 |
| 2 | Workaround tại WMS: WMS nhận phiếu xuất kho, sau đó gọi API khác để lấy chi tiết dòng hàng từ ERP và tự tính lại tổng khối lượng. | - Không cần thay đổi ERP. | - Trùng lặp logic nghiệp vụ. - Vi phạm nguyên tắc nguồn chân lý duy nhất. - Tăng độ trễ xử lý và tải hệ thống. - Chi phí cao hơn. |
- Dev: 24 - Test: 12 |
| Tiêu chí Quyết định theo thứ tự ưu tiên |
|---|
| 1. Tuân thủ nguyên tắc kiến trúc "Nguồn chân lý duy nhất" (Single Source of Truth). |
| 2. Xử lý triệt để nguyên nhân gốc rễ. |
| 3. Tổng chi phí triển khai và bảo trì thấp nhất. |
| 4. Rủi ro hồi quy (regression risk) thấp nhất. |
| Quyết định / Đề xuất | Lý do, Thẩm quyền và Hậu quả |
|---|---|
ID Quyết định: DEC-OPS-042 Nội dung: Chọn Phương án 1. Sửa lỗi ép kiểu dữ liệu trong DispatchService của ERP. Tạo yêu cầu thay đổi CR-ERP-891 để đội phát triển thực hiện. Trạng thái: IN_REVIEW. |
Lý do: Phương án 1 sửa nguyên nhân gốc tại ERP, giữ ERP là nguồn chân lý, có chi phí triển khai thấp hơn Phương án 2. Thẩm quyền phê duyệt yêu cầu: Head of IT, Operations Director, dựa trên phân tích tác động và chi phí. Artifact đầu ra: CR-ERP-891, bản sửa erp/src/inv/DispatchService.java, bằng chứng kiểm thử payload ERP-WMS và cập nhật ticket Jira-OPS-3441. |
| Hậu quả nếu quyết định sai: Chọn Phương án 2 tạo nợ kỹ thuật, tăng chi phí bảo trì và rủi ro sai lệch dữ liệu nếu logic tính toán ERP hoặc WMS thay đổi độc lập. Không sửa lỗi tạo điều kiện cho phiếu xuất kho khác tiếp tục mất phần thập phân, gây điều chỉnh kho thủ công và rủi ro giao hàng trễ. | Phân tích của Trần Thị Bích (IT Business Analyst). |
3.1. Bản ghi Lõi - Case Study Nova Foods: Module Quản lý Nhà Cung cấp (MOD-PROC-02)
Bản ghi này mô phỏng tài liệu sẵn sàng hỗ trợ cho triển khai module mới trong ERP của Nova Foods. Dữ liệu là tổng hợp. Bản ghi phục vụ IT Helpdesk, Application Support - ERP Team, Business Owner và nhóm vận hành trong tiếp nhận, phân loại, chuyển cấp, xử lý và truy vết sự cố sau Go-Live.
3.1.1. Metadata Sẵn sàng Hỗ trợ
| Trường | Giá trị |
|---|---|
| ID Tính năng | FEAT-PROC-001 |
| Tên Tính năng | Module Quản lý Vòng đời Nhà cung cấp |
| Module ERP liên quan | MOD-PROC-02: Supplier Lifecycle Management |
| Ngày Go-Live dự kiến | 2026-09-01T00:00:00+07:00 |
| Trạng thái sẵn sàng hỗ trợ | IN_REVIEW |
| Business Owner | Lê Minh Tuấn (Trưởng phòng Mua hàng) |
| Yêu cầu nghiệp vụ gốc | REQ-PROC-015: Tự động hóa quy trình giới thiệu và quản lý hợp đồng nhà cung cấp |
| Liên hệ Hỗ trợ Tier 1 | IT Helpdesk (Nội bộ) |
| Liên hệ Hỗ trợ Tier 2 | Application Support - ERP Team (Nội bộ) |
| Tài liệu người dùng | HDSD-PROC-001_Supplier-Onboarding.pdf |
| Artifact hỗ trợ cần dùng khi xử lý | Ticket sự cố, supplier_id, contract_id, ảnh chụp màn hình lỗi, thời điểm xảy ra lỗi, tài khoản người dùng và tài liệu người dùng HDSD-PROC-001_Supplier-Onboarding.pdf |
| Chủ thể xác nhận nghiệp vụ | Lê Minh Tuấn (Trưởng phòng Mua hàng) |
| Chủ thể thực hiện hỗ trợ tuyến đầu | IT Helpdesk |
| Chủ thể điều tra lỗi ứng dụng | Application Support - ERP Team |
3.1.2. Mô tả Chức năng và Tác động
Tính năng FEAT-PROC-001 số hóa quy trình từ đăng ký, thẩm định, phê duyệt đến kích hoạt nhà cung cấp mới. Hệ thống thay thế quy trình thủ công qua email và spreadsheet. Module lưu thông tin nhà cung cấp trong ERP để tạo nguồn chân lý duy nhất (single source of truth) cho dữ liệu nhà cung cấp.
Nhân viên Mua hàng tạo lời mời hoặc theo dõi hồ sơ. Nhà Cung cấp dùng Supplier Portal để khai báo thông tin và tải tài liệu. Trưởng phòng Mua hàng xem xét, phê duyệt hoặc từ chối hồ sơ trên ERP. Kế toán Công nợ nhận thông tin nhà cung cấp đã được phê duyệt từ module thay vì nhập tay từ email.
Tác động nghiệp vụ chính:
- Chuẩn hóa luồng giới thiệu nhà cung cấp, giảm phụ thuộc vào trao đổi email và file theo dõi cá nhân.
- Tăng khả năng truy vết trạng thái hồ sơ, người thực hiện và bước phê duyệt.
- Giảm sai sót nhập liệu lại giữa Mua hàng và Kế toán Công nợ.
- Tạo phụ thuộc vận hành vào khả năng truy cập
MOD-PROC-02, Supplier Portal, luồng phê duyệt và trao đổi dữ liệu nội bộ. - Nếu module hoặc portal lỗi, quy trình giới thiệu nhà cung cấp mới bị chậm hoặc dừng; bộ phận Mua hàng cần ghi nhận ticket và chuyển cấp theo quy tắc triage thay vì tự ý sửa dữ liệu.
3.1.3. Vai trò Người dùng và Thay đổi
| Vai trò | Hành động trên hệ thống | Tác động và Thay đổi Chính | Artifact / Kết quả cần tạo |
|---|---|---|---|
| Nhân viên Mua hàng | Mời nhà cung cấp, kiểm tra hồ sơ, theo dõi tiến độ xử lý. | Không còn dùng file Excel Danh_sach_NCC_theo_doi.xlsx. Phải điền trường bắt buộc trên hệ thống và theo dõi trạng thái trong module. |
Hồ sơ nhà cung cấp, trạng thái hồ sơ, supplier_id khi báo sự cố. |
| Trưởng phòng Mua hàng | Xem xét và phê duyệt nhà cung cấp trên ERP. | Thay phê duyệt qua email bằng phê duyệt trong hệ thống. Có dashboard xem tình trạng và hiệu suất nhà cung cấp. | Quyết định phê duyệt hoặc từ chối, trạng thái workflow. |
| Nhà Cung cấp (Bên ngoài) | Dùng Supplier Portal để khai báo thông tin, tải tài liệu pháp lý và theo dõi trạng thái. | Phải dùng định dạng tệp được hỗ trợ và giới hạn dung lượng. Không gửi tài liệu qua email thay cho bước tải lên portal. | Hồ sơ portal, tài liệu PDF, DOCX hoặc JPG, ảnh chụp lỗi khi tải thất bại. |
| Kế toán Công nợ | Nhận dữ liệu nhà cung cấp đã phê duyệt từ module. | Không nhập tay thông tin từ email của Mua hàng. Phải kiểm tra dữ liệu nhận được trước khi dùng cho nghiệp vụ công nợ. | Dữ liệu nhà cung cấp đã phê duyệt, thông tin sai lệch để chuyển hỗ trợ nếu có. |
| IT Helpdesk | Tiếp nhận, xác minh thông tin ban đầu, hướng dẫn thao tác chuẩn và tạo ticket. | Không sửa trực tiếp dữ liệu nghiệp vụ hoặc workflow. Phải thu thập định danh, thời điểm và bằng chứng trước khi chuyển Tier 2. | Ticket hỗ trợ chứa triệu chứng, supplier_id, contract_id khi có, ảnh lỗi và hành động đã thực hiện. |
| Application Support - ERP Team | Kiểm tra lỗi ứng dụng, trạng thái workflow và dữ liệu tích hợp sau khi Tier 1 chuyển cấp. | Chịu trách nhiệm điều tra kỹ thuật, xác định lỗi thuộc ứng dụng hoặc dữ liệu liên module, cập nhật kết quả vào ticket. | Phân tích kỹ thuật, kết quả xử lý hoặc yêu cầu chuyển tiếp theo thẩm quyền kỹ thuật. |
3.1.4. Quy tắc Phân loại Hỗ trợ (Triage Rules)
Đây là hướng dẫn cho đội IT Helpdesk (Tier 1). Tier 1 phải tạo hoặc cập nhật ticket trước khi chuyển cấp. Ticket phải nêu người báo cáo, thời điểm xảy ra, môi trường bị ảnh hưởng, triệu chứng, định danh bản ghi liên quan, bằng chứng lỗi và hành động Tier 1 đã thực hiện. Tier 1 không được tuyên bố nguyên nhân gốc khi chưa có bằng chứng từ Application Support - ERP Team.
| Triệu chứng Báo cáo | Hành động của Tier 1 | Điều kiện Chuyển cấp lên Tier 2 | Artifact bắt buộc khi chuyển cấp | Kết quả mong đợi |
|---|---|---|---|---|
| Người dùng không thể đăng nhập vào Supplier Portal. | Kiểm tra tài khoản có bị khóa không. Hướng dẫn dùng chức năng "Quên mật khẩu". Xác nhận email đăng ký có đúng trong hệ thống không. Ghi nhận thời điểm lỗi và thông báo hiển thị. | Tài khoản hoạt động, đã thử reset mật khẩu nhưng vẫn báo lỗi "Invalid credentials". |
Ticket, email đăng ký, thời điểm lỗi, ảnh chụp thông báo "Invalid credentials", kết quả kiểm tra khóa tài khoản và reset mật khẩu. |
Tier 2 kiểm tra xác thực hoặc liên kết tài khoản; Tier 1 cập nhật người dùng theo ticket. |
| Nhà cung cấp không tải lên được tài liệu. | Yêu cầu ảnh chụp màn hình lỗi. Xác minh định dạng (PDF, DOCX, JPG) và dung lượng file dưới 10MB. Xác nhận nhà cung cấp đang thực hiện đúng thao tác trong portal. |
File hợp lệ nhưng hệ thống vẫn báo lỗi Upload failed with error code 500. |
Ticket, supplier_id nếu có, tên và loại file, dung lượng file, thời điểm lỗi, ảnh lỗi chứa Upload failed with error code 500. |
Tier 2 kiểm tra lỗi ứng dụng hoặc xử lý tệp; không yêu cầu nhà cung cấp đổi dữ liệu nếu file đã đáp ứng quy định. |
| Luồng phê duyệt bị "kẹt" ở một bước quá 48 giờ. | Ghi nhận supplier_id và contract_id liên quan. Xác nhận người dùng đã kiểm tra tab "Nhiệm vụ cần làm" của người phê duyệt kế tiếp. Ghi nhận bước workflow đang hiển thị và thời điểm bắt đầu chờ. |
Chuyển cấp ngay lập tức sau khi có supplier_id và contract_id, vì vượt ngưỡng 48 giờ của luồng phê duyệt. |
Ticket, supplier_id, contract_id, tên bước workflow, người phê duyệt kế tiếp nếu hiển thị, thời điểm bắt đầu chờ và bằng chứng người dùng đã kiểm tra tab "Nhiệm vụ cần làm". |
Tier 2 kiểm tra trạng thái workflow trong database và ghi nhận nguyên nhân hoặc biện pháp khôi phục trong ticket. |
| Dữ liệu nhà cung cấp hiển thị sai. | Yêu cầu người dùng cung cấp supplier_id, trường dữ liệu sai, giá trị đang hiển thị và giá trị người dùng cho là đúng. Xác nhận nguồn đối chiếu do người dùng cung cấp. |
Dữ liệu sai lệch giữa module này và module khác, ví dụ Tài chính. | Ticket, supplier_id, tên trường dữ liệu, giá trị hiện tại, giá trị đối chiếu, module đối chiếu và ảnh chụp nếu có. |
Tier 2 xác định phạm vi sai lệch, nguồn dữ liệu cần kiểm tra và cập nhật kết quả điều tra. |
Toàn bộ MOD-PROC-02 hoặc Supplier Portal không thể truy cập. |
Xác nhận phạm vi người dùng bị ảnh hưởng, thời điểm bắt đầu, URL hoặc màn hình không truy cập được và thông báo lỗi. Không hướng dẫn người dùng tạo dữ |
4. Tier 3 ? Fully Completed Nova Foods Case: Evidence and Traceability
Phần này ghi lại các bằng chứng, giả định, và đường đi của quyết định liên quan đến quy tắc nghiệp vụ BR-WH-001. Nó đảm bảo mọi người hiểu bối cảnh, các rủi ro đã được xem xét, và cách truy vết yêu cầu từ gốc đến ngọn.
4.1. Bảng Truy vết Yêu cầu (Traceability Matrix)
Bảng này kết nối nhu cầu kinh doanh ban đầu với các yêu cầu, quy tắc, tiêu chí chấp nhận và ca kiểm thử tương ứng. Việc này tuân thủ nguyên tắc cốt lõi của BA: mọi thay đổi hệ thống phải có nguồn gốc rõ ràng.
| ID Nhu cầu (NEED) | ID Yêu cầu (REQ) | ID Quy tắc (BR) | ID Tiêu chí Chấp nhận (AC) | ID Ca kiểm thử (TC) |
|---|---|---|---|---|
NEED-FIN-002: Giảm thất thoát doanh thu do hủy đơn hàng vì hết hàng. |
REQ-SALES-005: Hệ thống phải ngăn chặn tạo đơn hàng bán với số lượng sản phẩm vượt quá tồn kho khả dụng. |
BR-WH-001: Không cho phép tạo đơn hàng bán nếu quantity > quantity_on_hand. |
AC-SALES-005.1: Khi API tạo đơn hàng nhận được quantity > quantity_on_hand của product_id tương ứng, nó phải trả về mã lỗi HTTP 400 Bad Request. |
TC-SALES-005.POS.1: Tạo đơn hàng với quantity = quantity_on_hand. Kết quả mong muốn: Thành công (HTTP 201 Created). |
NEED-OPS-004: Cải thiện độ chính xác của dữ liệu tồn kho. |
REQ-SALES-005 |
BR-WH-001 |
AC-SALES-005.2: Payload lỗi phải chứa một mã lỗi máy có thể đọc được (ví dụ: INSUFFICIENT_STOCK) và một thông báo cho người dùng bằng tiếng Việt. |
TC-SALES-005.NEG.1: Tạo đơn hàng với quantity = quantity_on_hand + 1. Kết quả mong muốn: Thất bại (HTTP 400), payload chứa mã lỗi và thông báo. |
NEED-CX-001: Giảm trải nghiệm tiêu cực của khách hàng khi đơn hàng bị hủy. |
REQ-SALES-005 |
BR-WH-001 |
AC-SALES-005.3: Giao diện người dùng phải gọi API kiểm tra tồn kho và vô hiệu hóa nút "Đặt hàng" nếu số lượng không hợp lệ trước khi gửi yêu cầu. |
TC-SALES-005.NEG.2: Thử tạo hai đơn hàng đồng thời cho cùng một sản phẩm có quantity_on_hand = 1. Kết quả mong muốn: Chỉ một đơn được tạo, đơn còn lại thất bại. |
4.2. Ngoại lệ, Giả định, và các mục cần xác minh
Đây là các ràng buộc và điểm chưa chắc chắn của giải pháp, cần được làm rõ với các bên liên quan.
Ngoại lệ cho BR-WH-001
- Hiện tại: Không có ngoại lệ nào được áp dụng. Quy tắc này được thực thi nghiêm ngặt cho tất cả các loại đơn hàng và kênh bán hàng để đảm bảo tính toàn vẹn dữ liệu. Quyết định này nhằm đơn giản hóa việc triển khai ban đầu.
Giả định (Assumptions)
| ID Giả định | Nội dung Giả định | Lý do/Tác động |
|---|---|---|
ASM-DATA-001 |
Trường quantity_on_hand trong bảng products là nguồn chân lý duy nhất và cuối cùng cho tồn kho khả dụng. |
Loại bỏ sự phức tạp của các khái niệm như "hàng đang giữ" (on-hold) hoặc "hàng đang về" (incoming). Nếu sai, quy tắc sẽ không chính xác. |
ASM-SCOPE-002 |
Quy tắc này áp dụng cho mọi kênh bán hàng (B2C web, B2B portal, API cho đối tác). | Đảm bảo tính nhất quán. Cần kiểm tra kỹ thuật để chắc chắn mọi entrypoint đều đi qua lớp logic xác thực chung. |
ASM-PROCESS-003 |
Nova Foods không có quy trình "đặt hàng trước" (pre-order) hoặc "đặt hàng chờ" (back-order) cho phép tồn kho âm. | Đơn giản hóa luồng xử lý. Nếu tương lai có nhu cầu này, quy tắc BR-WH-001 phải được thiết kế lại hoàn toàn. |
Các mục cần xác minh (Items for Verification)
| ID Xác minh | Nội dung cần xác minh | Người chịu trách nhiệm xác minh (Owner) | Lý do cần xác minh |
|---|---|---|---|
VER-PROC-007 |
Quy trình nghiệp vụ chính thức cho "đặt hàng chờ" (back-ordering) trong tương lai. | Trưởng phòng Kinh doanh | Quyết định này sẽ thay đổi căn bản logic của BR-WH-001 và cần được phân tích như một yêu cầu mới. |
VER-DATA-004 |
Xử lý quantity_on_hand trong trường hợp có nhiều kho hàng vật lý. |
Kiến trúc sư Giải pháp, Trưởng phòng Kho vận | Mô hình dữ liệu hiện tại giả định một giá trị tồn kho tổng. Cần làm rõ nếu tồn kho được tính theo từng kho riêng lẻ. |
4.3. Luồng tiêu cực và Ghi nhận Escalation
Luồng tiêu cực (Negative Paths)
| Kịch bản | Mô tả | Cách giảm thiểu/xử lý |
|---|---|---|
| Race Condition | Hai yêu cầu API đồng thời cùng lúc đặt mua số lượng cuối cùng của một sản phẩm. | Sử dụng cơ chế khóa bi quan (pessimistic locking) hoặc các mức cô lập giao dịch (transaction isolation level) SERIALIZABLE ở tầng cơ sở dữ liệu khi cập nhật số lượng tồn kho. |
| Dữ liệu cache cũ (Stale Cache) | Lớp ứng dụng cache lại giá trị quantity_on_hand và không được cập nhật kịp thời khi có thay đổi từ một giao dịch khác (ví dụ: nhập hàng). |
Thiết kế một chiến lược xóa cache (cache invalidation) hiệu quả. Ví dụ: xóa cache của sản phẩm liên quan mỗi khi một đơn hàng được tạo thành công hoặc một phiếu nhập kho được xác nhận. |
Ghi nhận Escalation
Bảng này ghi lại việc đưa vấn đề lên cấp cao hơn để ra quyết định, đảm bảo sự minh bạch.
| ID Escalation | Ngày | Vấn đề | Người quyết định | Kết quả |
|---|---|---|---|---|
ESC-BR-WH-001-01 |
2026-08-05 | Lựa chọn phương án kỹ thuật tối ưu để triển khai BR-WH-001 giữa UI-only, Backend-only, và kết hợp. |
Trưởng phòng Kinh doanh, Kiến trúc sư Giải pháp | Đã giải quyết: Chọn phương án xác thực tại Backend (API) làm nguồn kiểm soát chính, và bổ sung xác thực ở UI để cải thiện trải nghiệm người dùng. |
Ma trận truy vết yêu cầu (Requirements Traceability Matrix - RTM)
Ma trận truy vết yêu cầu (thường gọi là RTM) là một công cụ cốt lõi để đảm bảo tính toàn vẹn của dự án. Nó trực quan hóa mối liên kết hai chiều giữa các đối tượng phân tích nghiệp vụ, từ nhu cầu kinh doanh ban đầu cho đến các ca kiểm thử cụ thể. Việc này giúp xác nhận mọi yêu cầu đều được giải quyết, không có yêu cầu "mồ côi" nào bị bỏ sót, và hỗ trợ phân tích tác động khi có thay đổi. Ma trận này sử dụng các định danh (ID) chuẩn hóa được quản lý trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md để đảm bảo tính nhất quán trên toàn bộ corpus tài liệu Nova Foods.
Dưới đây là một ví dụ ma trận truy vết được điền đầy đủ cho kịch bản mô phỏng tại Nova Foods: "Hệ thống ERP phải tự động gắn cờ các đơn đặt hàng nguyên vật liệu thô có giá trị cao để yêu cầu một bước phê duyệt bổ sung từ cấp quản lý, nhằm giảm thiểu rủi ro gian lận tài chính".
| ID Nhu cầu (NEED) | ID Yêu cầu (REQ) | ID Quy tắc (BR) | ID Tiêu chí (AC) | ID Dữ liệu/API (DATA/API) | ID Ca kiểm thử (TC) |
|---|---|---|---|---|---|
NEED-NF-001: Cần cơ chế kiểm soát chặt chẽ hơn đối với các giao dịch mua hàng giá trị lớn để phòng chống rủi ro tài chính. |
REQ-NF-FIN-015: Hệ thống phải cung cấp chức năng để tự động đánh dấu các đơn đặt hàng (PO) vượt một ngưỡng giá trị xác định để yêu cầu phê duyệt bổ sung. |
BR-NF-ACCT-021: Một đơn đặt hàng được định nghĩa là "giá trị cao" nếu tổng giá trị trước thuế của nó lớn hơn hoặc bằng 500.000.000 VND. |
AC-NF-FIN-015.1: Khi người dùng tạo một PO có tổng giá trị là 500.000.000 VND, hệ thống phải tự động cập nhật trạng thái của PO thành "Chờ phê duyệt cấp cao" và không cho phép gửi đến nhà cung cấp. |
DATA-NF-PO-008: PurchaseOrder.totalValue (Kiểu: Numeric, Đơn vị: VND). DATA-NF-PO-012: PurchaseOrder.status (Kiểu: Enum, Giá trị: PENDING_HIGH_VALUE_APPROVAL). |
TC-NF-FIN-015.1.1: Kiểm tra tạo PO với totalValue = 500.000.000 VND. Kết quả mong đợi: status là PENDING_HIGH_VALUE_APPROVAL. |
NEED-NF-001 |
REQ-NF-FIN-015 |
BR-NF-ACCT-021 |
AC-NF-FIN-015.2: Khi người dùng tạo một PO có tổng giá trị là 499.999.999 VND, hệ thống phải giữ nguyên quy trình phê duyệt chuẩn, không yêu cầu phê duyệt bổ sung. |
DATA-NF-PO-008: PurchaseOrder.totalValue. DATA-NF-PO-012: PurchaseOrder.status. |
TC-NF-FIN-015.2.1: Kiểm tra tạo PO với totalValue = 499.999.999 VND. Kết quả mong đợi: status là PENDING_STANDARD_APPROVAL. |
NEED-NF-001 |
REQ-NF-FIN-016: Hệ thống phải gửi thông báo qua email và trên giao diện dashboard cho người quản lý được phân quyền khi có một PO cần phê duyệt cấp cao. |
Không có BR riêng, là một phần của luồng quy trình. | AC-NF-FIN-016.1: Ngay sau khi một PO được chuyển sang trạng thái "Chờ phê duyệt cấp cao", một email thông báo phải được gửi đến địa chỉ trong trường Approver.email của người quản lý cấp cao tương ứng. |
API-NF-NOTIF-SEND-V1: Endpoint gửi thông báo. DATA-NF-USER-005: User.emailAddress. DATA-NF-PO-012: PurchaseOrder.status. |
TC-NF-FIN-016.1.1: Giả lập sự kiện thay đổi trạng thái PO và xác minh rằng dịch vụ API-NF-NOTIF-SEND-V1 được gọi với đúng payload chứa email người nhận. |
Diễn giải truy vết:
* Truy vết xuôi (Forward Traceability): Từ NEED đến REQ đến AC và TC. Ví dụ, NEED-NF-001 được hiện thực hóa bởi REQ-NF-FIN-015. Yêu cầu này được kiểm chứng qua các tiêu chí chấp nhận AC-NF-FIN-015.1 và AC-NF-FIN-015.2, và cuối cùng được xác minh bằng các ca kiểm thử TC-NF-FIN-015.1.1 và TC-NF-FIN-015.2.1. Điều này chứng minh rằng nhu cầu ban đầu đã được chuyển thành một giải pháp có thể kiểm tra được.
* Truy vết ngược (Backward Traceability): Từ TC ngược về NEED. Ví dụ, nếu ca kiểm thử TC-NF-FIN-016.1.1 thất bại, chúng ta có thể truy ngược lại AC-NF-FIN-016.1, rồi đến REQ-NF-FIN-016 và cuối cùng là NEED-NF-001 để hiểu được tác động nghiệp vụ của lỗi này. Nó trả lời câu hỏi: "Tại sao chúng ta lại xây dựng và kiểm thử chức năng này?".
Bằng chứng: Bảng Quyết định và Dữ liệu Kiểm thử
Phần này cung cấp bằng chứng kỹ thuật trực tiếp cho kịch bản hỗ trợ. Bảng quyết định và dữ liệu kiểm thử được dùng làm nguồn chân lý (source of truth) cho logic nghiệp vụ, đảm bảo đội hỗ trợ, đội phát triển và đội kiểm thử có cùng một cách hiểu.
Bảng này truy vết trực tiếp từ quy tắc nghiệp vụ đến các yêu cầu liên quan, bảo toàn tính nhất quán từ đầu cuối.
| Yếu tố | ID Tham chiếu Canonical | Ghi chú |
|---|---|---|
| Quy tắc Nghiệp vụ (Business Rule) | BR-SALES-004 |
Quy tắc gốc xác định logic chiết khấu thể tích tự động. |
| Yêu cầu (Requirement) | REQ-SALES-012 |
Yêu cầu hệ thống tự động tính và áp dụng chiết khấu thể tích cho đơn hàng B2B. |
| Tiêu chí Chấp nhận (Acceptance Criteria) | AC-SALES-012.1, AC-SALES-012.2, AC-SALES-012.3, AC-SALES-012.4 |
Các tiêu chí xác minh từng ngưỡng chiết khấu và trường hợp không áp dụng. |
| Trường hợp Kiểm thử (Test Case) | TC-SALES-035 |
Bộ kiểm thử chức năng xác minh logic trong bảng quyết định này. |
Bảng Quyết định: BR-SALES-004 - Áp dụng Chiết khấu Thể tích B2B
Bảng quyết định (Decision Table) là công cụ đặc tả logic một cách phi kỹ thuật, không mơ hồ. Nó mô tả các tổ hợp điều kiện đầu vào và các hành động tương ứng của hệ thống. Bảng dưới đây là đặc tả chính thức cho BR-SALES-004. Dữ liệu trong bảng là dữ liệu tổng hợp cho mục đích mô phỏng của Nova Foods.
| Quy tắc 1 | Quy tắc 2 | Quy tắc 3 | Quy tắc 4 | Quy tắc 5 | |
|---|---|---|---|---|---|
| Điều kiện | |||||
C1: customer.type là 'B2B' |
N | Y | Y | Y | Y |
C2: order.subtotal_vnd >= 250,000,000 |
- | N | N | N | Y |
C3: order.subtotal_vnd >= 100,000,000 |
- | N | N | Y | - |
C4: order.subtotal_vnd >= 50,000,000 |
- | N | Y | - | - |
| Hành động | |||||
A1: Áp dụng discount.percentage = 7% |
X | ||||
A2: Áp dụng discount.percentage = 5% |
X | ||||
A3: Áp dụng discount.percentage = 3% |
X | ||||
A4: Áp dụng discount.percentage = 0% |
X | X | |||
| A5: Ghi log hệ thống "BR-SALES-004 Evaluated" | X | X | X | X |
Diễn giải: * Y/N: Điều kiện là Đúng (Yes) / Sai (No). * -: Điều kiện không quan trọng (don't care) cho quy tắc này. * X: Hành động được thực thi.
Dữ liệu Kiểm thử Dẫn xuất từ Bảng Quyết định
Bảng quyết định là cơ sở kiểm thử (test basis) để tạo ra các trường hợp kiểm thử (test cases). Mỗi quy tắc trong bảng tương ứng với ít nhất một trường hợp kiểm thử, bao gồm cả phân vùng tương đương (equivalence partitioning) và phân tích giá trị biên (boundary value analysis).
| ID Test Case | Quy tắc tham chiếu | Loại kiểm thử | Dữ liệu đầu vào (Input) | Kết quả mong đợi (Expected Outcome) |
|---|---|---|---|---|
TC-SALES-035.1 |
R1 | Phân vùng | customer.type = 'B2C', order.subtotal_vnd = 300,000,000 |
discount.percentage = 0%. Không ghi log. |
TC-SALES-035.2 |
R2 | Giá trị biên | customer.type = 'B2B', order.subtotal_vnd = 49,999,999 |
discount.percentage = 0%. Ghi log "BR-SALES-004 Evaluated". |
TC-SALES-035.3 |
R3 | Giá trị biên | customer.type = 'B2B', order.subtotal_vnd = 50,000,000 |
discount.percentage = 3%. Ghi log "BR-SALES-004 Evaluated". |
TC-SALES-035.4 |
R3 | Phân vùng | customer.type = 'B2B', order.subtotal_vnd = 75,000,000 |
discount.percentage = 3%. Ghi log "BR-SALES-004 Evaluated". |
TC-SALES-035.5 |
R3 | Giá trị biên | customer.type = 'B2B', order.subtotal_vnd = 99,999,999 |
discount.percentage = 3%. Ghi log "BR-SALES-004 Evaluated". |
TC-SALES-035.6 |
R4 | Giá trị biên | customer.type = 'B2B', order.subtotal_vnd = 100,000,000 |
discount.percentage = 5%. Ghi log "BR-SALES-004 Evaluated". |
TC-SALES-035.7 |
R4 | Giá trị biên | customer.type = 'B2B', order.subtotal_vnd = 249,999,999 |
discount.percentage = 5%. Ghi log "BR-SALES-004 Evaluated". |
TC-SALES-035.8 |
R5 | Giá trị biên | customer.type = 'B2B', order.subtotal_vnd = 250,000,000 |
discount.percentage = 7%. Ghi log "BR-SALES-004 Evaluated". |
5. Tier 4 – Senior BA Quality Gate
Đây là cổng kiểm soát chất lượng do Senior BA (Business Analyst cấp cao) thực hiện. Mục đích: xác nhận artifact (sản phẩm công việc, ở đây là tài liệu này) đủ chất lượng để tạo baseline (phiên bản nền tảng, có kiểm soát thay đổi chặt chẽ) và sẵn sàng chuyển giao cho các nhóm khác (phát triển, kiểm thử, vận hành). Checklist dưới đây định nghĩa tiêu chí ĐẠT, KHÔNG ĐẠT, và khi nào cần Dừng (Stop) hoặc Leo thang (Escalate) tới các vai trò có thẩm quyền.
Checklist Đánh giá Chất lượng Artifact
| Hạng mục kiểm tra | Tiêu chí đánh giá chi tiết | Điều kiện ĐẠT (Pass) | Điều kiện KHÔNG ĐẠT (Fail) | Hành động khi KHÔNG ĐẠT |
|---|---|---|---|---|
| Tính đầy đủ (Completeness) | Tất cả các mục, trường thông tin bắt buộc trong template đã được điền đầy đủ. Không có placeholder, TODO, TBD. | Mọi trường trong Tier 3 đều có dữ liệu mô phỏng Nova Foods cụ thể. Mọi bằng chứng yêu cầu trong Tier 4 đều được cung cấp. | Còn ít nhất một mục bắt buộc bị bỏ trống, hoặc chứa placeholder như <chưa xác định>, TBD. |
Trả lại cho người soạn thảo (author) để bổ sung. |
| Tính nhất quán (Consistency) | Thuật ngữ, định danh (ID), và dữ liệu phải nhất quán trong toàn bộ tài liệu và khớp với các nguồn canonical của corpus (Data Dictionary, Rule Catalog). | Mọi ID (BR-, REQ-, UC-) đều khớp với TRACEABILITY_ID_REGISTRY. Tên quy trình, hệ thống, vai trò người dùng được dùng thống nhất. |
Tồn tại ID không hợp lệ, thuật ngữ được dùng với nhiều nghĩa khác nhau, hoặc dữ liệu mâu thuẫn giữa các phần (ví dụ: cùng một quy tắc nhưng mô tả khác nhau ở hai nơi). | Trả lại cho author để điều chỉnh. Nếu mâu thuẫn với nguồn canonical, Dừng (Stop) và leo thang (Escalate) cho Owner của artifact canonical đó. |
| Khả năng kiểm thử (Testability) | Yêu cầu và tiêu chí chấp nhận phải rõ ràng, cụ thể, đo lường được, không mơ hồ để có thể viết được test case xác minh. | Mỗi tiêu chí chấp nhận đều có thể được chuyển thành ít nhất một test case với kết quả mong đợi rõ ràng (pass/fail). Các điều kiện biên và luồng lỗi đã được xác định. | Yêu cầu chứa các từ không xác định được như "nhanh", "thân thiện người dùng", "linh hoạt" mà không có chỉ số đo lường cụ thể. | Trả lại cho author để làm rõ. Yêu cầu phải được viết lại để có thể kiểm chứng được. |
| Khả năng truy vết (Traceability) | Traceability là khả năng theo dõi một yêu cầu từ nguồn gốc (nhu cầu nghiệp vụ, luật định) qua các giai đoạn cho đến triển khai. Mọi artifact phải có liên kết ngược (backward) và xuôi (forward). | Mọi yêu cầu (REQ-) liên kết tới nguồn gốc (ví dụ: BR-). Mọi test case (TC-) liên kết tới yêu cầu hoặc tiêu chí chấp nhận (AC-). Không có yêu cầu "mồ côi" (orphan). |
Tồn tại yêu cầu không rõ nguồn gốc. Tồn tại test case không kiểm tra cho yêu cầu nào. Liên kết bị đứt gãy. | Dừng (Stop). Đây là lỗi nghiêm trọng. Trả lại cho author để thiết lập lại chuỗi truy vết. Nếu có tranh cãi về nguồn gốc, Leo thang (Escalate) tới Business Owner. |
| Thẩm quyền nguồn (Source Authority) | Nguồn gốc của các quy tắc nghiệp vụ, đặc biệt là các quy tắc liên quan đến pháp lý, kế toán, tuân thủ, phải được trích dẫn đúng và rõ ràng. | Các quy tắc có nguồn từ luật (Luật Kế toán, Luật An toàn thực phẩm,...) được ghi rõ tham chiếu. Các giả định của dự án được đánh dấu rõ là Verification required. |
Một quy tắc pháp lý/kế toán được nêu ra như một sự thật mà không có tham chiếu nguồn, hoặc một giả định được trình bày như một quy tắc đã được xác minh. | Trả lại cho author để bổ sung nguồn. Nếu cố tình diễn giải sai lệch thẩm quyền, Leo thang (Escalate) tới Principal BA. |
| Quyền sở hữu (Ownership) | Phải xác định rõ ai là người sở hữu (owner) của quy trình nghiệp vụ, dữ liệu, và các quyết định liên quan. | Mỗi quy trình nghiệp vụ và nhóm dữ liệu chính (major data entity) đều có một Business Owner được chỉ định rõ ràng. | Không rõ ai chịu trách nhiệm phê duyệt thay đổi cho một quy trình hoặc quyết định ý nghĩa dữ liệu. | Trả lại cho author để làm rõ. Nếu có xung đột về quyền sở hữu, Leo thang (Escalate) tới cấp quản lý chương trình (program management). |
| Ranh giới & Tuân thủ (Boundaries & Compliance) | Các tác động về bảo mật, quyền riêng tư, pháp lý, kế toán phải được xác định và đánh dấu để các chuyên gia liên quan xem xét. | Các trường dữ liệu có chứa thông tin cá nhân (PII) được nhận diện. Các yêu cầu liên quan đến tài chính, thuế được đánh dấu cần Accounting Owner review. Các rủi ro bảo mật tiềm tàng được ghi nhận. |
Xử lý dữ liệu khách hàng nhưng không đề cập đến Luật Bảo vệ dữ liệu cá nhân. Thay đổi quy trình thanh toán mà không đánh dấu cho Kế toán xem xét. |
Dừng (Stop). Tài liệu không được đi tiếp nếu chưa xác định và khoanh vùng đúng các ranh giới tuân thủ. Leo thang (Escalate) ngay lập tức cho các Owner chuyên môn (Legal, Security, Accounting). |
| Tác động thay đổi (Change Impact) | Phải phân tích và ghi nhận tác động của thay đổi lên các hệ thống, quy trình, và vai trò người dùng hiện có. | Có một mục riêng mô tả hệ thống/quy trình nào bị ảnh hưởng, người dùng nào cần được đào tạo lại, và mức độ thay đổi là lớn hay nhỏ. | Một tính năng mới được đề xuất mà không có phân tích về việc nó sẽ ảnh hưởng đến công việc hàng ngày của nhân viên kho hay nhân viên bán hàng như thế nào. | Trả lại cho author để hoàn thành phân tích tác động. Đây là đầu vào quan trọng cho quản lý thay đổi (change management). |
Định nghĩa và Tiêu chí Kiểm soát Chất lượng
Bảng này xác định các tiêu chí chất lượng cho việc review của Senior BA. Mỗi mục trong template đã điền ở Tier 3 phải được đánh giá theo các tiêu chí này.
| Tiêu chí | Định nghĩa & Mục tiêu | Điều kiện Đạt (Pass) | Điều kiện Dừng & Leo thang (Stop & Escalate) |
|---|---|---|---|
| Tính đầy đủ (Completeness) | Tài liệu không có lỗ hổng. Mọi mục yêu cầu đều được điền. Mục tiêu là đảm bảo baseline không chứa nội dung dang dở. | Mọi trường trong Tier 3 có giá trị cụ thể, không dùng TBD, TODO. Mọi tham chiếu bằng chứng (EVD-xxx) đều có file tương ứng ở Mục 4. |
Còn mục trống hoặc placeholder góc nhọn. Tham chiếu bằng chứng nhưng không cung cấp. Thiếu một phần bắt buộc của template. |
| Tính nhất quán (Consistency) | Thuật ngữ, ID, quy tắc phải đồng nhất. Không có mâu thuẫn nội tại hoặc mâu thuẫn với nguồn canonical. Mục tiêu là tạo một nguồn chân lý duy nhất. | Thuật ngữ (Nhà Cung Cấp) dùng thống nhất. Quy tắc (BR-INV-001) khớp với CANONICAL_BUSINESS_RULES.md. Định dạng dữ liệu khớp CANONICAL_DATA_DICTIONARY.md. |
Một yêu cầu mâu thuẫn với yêu cầu khác. ID hoặc quy tắc ở đây khác với nguồn canonical. Dùng tên định danh khác nhau cho cùng một đối tượng. |
| Tính khả kiểm (Testability) | Yêu cầu phải rõ ràng, đo lường được, đơn nghĩa. Tester có thể tạo test case để xác minh Đạt/Trượt. Mục tiêu là tránh yêu cầu mơ hồ, không thể nghiệm thu. | Yêu cầu: "Hệ thống phải tính thuế GTGT 10% trên tổng tiền hàng." Có thể kiểm tra bằng phép toán. | Yêu cầu: "Hệ thống phải thân thiện." hoặc "Xử lý phải nhanh." Không đo được. Dùng tính từ chủ quan. |
| Tính truy vết (Traceability) | Mọi yêu cầu phải liên kết ngược về nguồn gốc (nhu cầu nghiệp vụ, luật). Mọi đối tượng (REQ, BR, UC) phải có ID duy nhất đã đăng ký. |
Yêu cầu REQ-SALES-015 có nguồn là STAKE-REQ-088 (Yêu cầu từ Trưởng phòng Kinh doanh). Mọi ID đều tồn tại trong TRACEABILITY_ID_REGISTRY.md. |
Yêu cầu không có nguồn. Nguồn là "nghiệp vụ muốn thế". Dùng ID chưa đăng ký hoặc tự chế. Chuỗi truy vết bị đứt. |
| Thẩm quyền nguồn (Source Authority) | Nguồn của quy tắc hoặc yêu cầu phải đáng tin cậy và có thẩm quyền. Mục tiêu là đảm bảo yêu cầu dựa trên thực tế, không phải suy diễn. | Quy tắc thuế trích dẫn Nghị định 123/2020/NĐ-CP. Yêu cầu bảo mật dữ liệu trích dẫn Luật 91/2025/QH15. Nguồn được liệt kê và xác minh trong 00_SOURCE_MAP.md. |
Quy tắc pháp lý trích dẫn bài blog. Yêu cầu nghiệp vụ dựa trên "tôi nghĩ là". Nguồn không được xác thực. |
| Quyền sở hữu (Ownership) | Phân định rõ ai là người ra quyết định cuối cùng cho một quy tắc nghiệp vụ, yêu cầu pháp lý, hoặc ràng buộc kỹ thuật. BA là người ghi nhận, không phải người quyết định. | Quy tắc nghiệp vụ có Owner là Trưởng phòng liên quan. Yêu cầu tuân thủ có Owner là Phòng Pháp chế. Tài liệu ghi rõ vai trò Owner cho từng mục. | BA tự "phê duyệt" một quy trình tài chính. Tài liệu ngụ ý BA có thẩm quyền pháp lý. Owner ghi là "Team" hoặc để trống. |
| Ranh giới chuyên môn (Boundaries) | Các vấn đề thuộc lĩnh vực chuyên môn (Bảo mật, Pháp lý, Kế toán, Quyền riêng tư) phải được xác định và chuyển cho đúng Owner. | Trường dữ liệu cá nhân (PII) được đánh dấu, yêu cầu Legal review. Yêu cầu bảo mật tham chiếu OWASP ASVS. Luồng xử lý tài chính được đánh dấu cần Accounting review. | Dữ liệu khách hàng bị coi là dữ liệu chung, không có cờ PII. API không có ghi chú review bảo mật. BA tự tạo quy tắc kế toán. |
| Tác động thay đổi (Change Impact) | Tài liệu phải chỉ rõ thay đổi này ảnh hưởng đến hệ thống, quy trình, hoặc người dùng nào khác. Mục tiêu là quản lý rủi ro và chuẩn bị cho sự thay đổi. | Mô tả rõ: "Thay đổi này ảnh hưởng Team Kế toán, cần đào tạo lại. API của Hệ thống X cần cập nhật." Có danh sách các đối tượng bị ảnh hưởng. | Một quy trình bị thay đổi nhưng không phân tích ai bị ảnh hưởng. Ghi "Không có tác động" mà không có bằng chứng phân tích. |
Áp dụng Checklist vào Case Study Nova Foods
Bảng này ghi nhận kết quả rà soát chất lượng (Quality Gate) của Senior BA đối với ví dụ Nova Foods đã hoàn thiện trong Mục 3 và Mục 4, dựa trên checklist đã định nghĩa. Đây là hoạt động ghi nhận, không phải phê duyệt baseline.
| ID Check | Hạng mục kiểm tra | Kết quả | Ghi nhận, Bằng chứng & Tham chiếu | Hành động đề xuất |
|---|---|---|---|---|
| QG-NF-01 | Tính đầy đủ (Completeness) | ĐẠT |
Tất cả trường bắt buộc trong Tier 2 đã được điền đủ trong Tier 3. Không có trường TBD hay bỏ trống. |
Không cần. |
| QG-NF-02 | Tính nhất quán (Consistency) | CẢNH BÁO |
Thuật ngữ "Ngày hết hạn sản phẩm" trong Mục 3 không khớp với thuật ngữ "Hạn sử dụng (HSD)" trong CANONICAL_DATA_DICTIONARY (CDD-NF-0481). Gây nhầm lẫn tiềm tàng. |
Chỉnh sửa tài liệu để dùng thuật ngữ canonical "Hạn sử dụng (HSD)". |
| QG-NF-03 | Khả năng kiểm thử (Testability) | CẢNH BÁO |
Tiêu chí chấp nhận AC-INV-015 ghi: "Hệ thống phải xử lý nhanh các báo cáo tồn kho lớn". "Nhanh" không định lượng, không thể kiểm thử. |
Sửa AC-INV-015: "Hệ thống phải tạo báo cáo tồn kho 10,000 dòng trong vòng dưới 30 giây". |
| QG-NF-04 | Khả năng truy vết (Traceability) | LỖI |
Quy tắc nghiệp vụ "Mọi chiết khấu trên 20% phải được Trưởng phòng Kinh doanh duyệt" trong Mục 3 không có ID tham chiếu BR-NF-XXX về CANONICAL_BUSINESS_RULES. Không truy vết được nguồn gốc quy tắc. |
DỪNG. Thêm ID quy tắc nghiệp vụ BR-NF-SALES-007 vào tài liệu. Nếu quy tắc chưa có trong catalog, phải đăng ký trước. |
| QG-NF-05 | Thẩm quyền nguồn (Source Authority) | ĐẠT |
Các tham chiếu đến Nghị định 123/2020/NĐ-CP về hóa đơn điện tử chỉ dừng ở mức nhận diện, không diễn giải. Có nhãn Verification required từ bộ phận Kế toán. Đúng thẩm quyền. |
Không cần. Giữ nguyên nhãn xác minh. |
| QG-NF-06 | Quyền sở hữu (Ownership) | ĐẠT |
Vai trò Data Owner cho các thực thể dữ liệu Khách hàng và Nhà cung cấp được gán rõ ràng cho "Giám đốc Kinh doanh". |
Không cần. |
| QG-NF-07 | Ranh giới Bảo mật / Riêng tư (Security/Privacy) | LỖI, LEO THANG |
Mục 4 mô tả payload API chứa số điện thoại khách hàng (customerPhone) ở dạng cleartext. Vi phạm nguyên tắc bảo vệ dữ liệu cá nhân (PII). Tham chiếu: Luật 91/2025/QH15, OWASP API Security Top 10 API5:2023 - Broken Function Level Authorization. |
DỪNG & LEO THANG. Yêu cầu review từ Kiến trúc sư Giải pháp và Chuyên gia Bảo mật. Dữ liệu PII phải được che giấu (masking) hoặc mã hóa. |
| QG-NF-08 | Ranh giới Kế toán / Pháp lý (Acc./Legal) | ĐẠT |
Tài liệu phân định rõ các yêu cầu về báo cáo thuế là giả định mô phỏng, cần xác thực bởi Kế toán trưởng. Không tự diễn giải Luật Kế toán 88/2015/QH13. |
Không cần. |
| QG-NF-09 | Phân tích tác động thay đổi (Change Impact) | CẢNH BÁO |
Phân tích tác động chỉ đề cập đến đội ngũ Bán hàng và Kế toán. Bỏ qua tác động đến đội Kho vận, những người cần in báo cáo tồn kho mới để đối chiếu khi xuất hàng. | Bổ sung "Quy trình đối chiếu xuất kho của Bộ phận Kho vận" vào mục các đối tượng bị ảnh hưởng. |
Tóm tắt kết quả:
ĐẠT: 4CẢNH BÁO: 3LỖI: 2 (1 lỗi yêu cầuDỪNG, 1 lỗi yêu cầuDỪNG & LEO THANG)
Kết luận: Tài liệu chưa đạt chất lượng để baseline. Cần xử lý các điểm LỖI và CẢNH BÁO trước khi xem xét lại.
6. Cross-File Checks, Open Issues, and Escalation
6.1. Đối chiếu tính nhất quán liên tệp (Cross-File Consistency Check)
Kiểm tra này đảm bảo tài liệu nhất quán với các nguồn chuẩn (canonical sources). Nó ngăn mâu thuẫn gây hiểu lầm, làm lại (rework), và quyết định sai. Mỗi thông tin, quy tắc, hoặc định danh quan trọng phải có một nguồn sự thật duy nhất (Single Source of Truth - SSoT). Bảng dưới đây ghi kết quả đối chiếu cho TMPL-OPS-SUPPORT-READINESS-001 trong case study mô phỏng Nova Foods.
| Hạng mục Kiểm tra | Tệp Nguồn Chuẩn (Canonical Source) | Tệp Đích để Đối chiếu | Tiêu chí Kiểm tra | Kết quả & Bằng chứng | Hành động Bắt buộc |
|---|---|---|---|---|---|
| Metadata Quản trị | /01-curriculum/TEMPLATE_MANIFEST.md |
Metadata của tài liệu này | Status, Version, Last updated date phải khớp chính xác với TEMPLATE_MANIFEST. |
ĐẠT.Cả hai tệp ghi: Status: IN_REVIEW, Version: v0.9.0, Last updated date: 2026-08-07. Tính nhất quán quản trị được bảo toàn. |
Không cần hành động. Giữ trạng thái IN_REVIEW. |
| Định nghĩa Quy tắc Nghiệp vụ | /01-curriculum/CANONICAL_BUSINESS_RULES.md |
Mục 3.3 - Case Study Nova Foods: Quy trình Hỗ trợ Cập nhật Tồn kho trong tài liệu này |
Diễn giải BR-INV-005 phải khớp định nghĩa gốc trong catalog quy tắc chuẩn. |
MÂU THUẪN (CONFLICT).Tài liệu này mô tả: “Bộ phận Hỗ trợ phải cập nhật số lượng tồn kho trong vòng 1 giờ làm việc”. Nguồn chuẩn CANONICAL_BUSINESS_RULES.md định nghĩa BR-INV-005: “Hệ thống ERP phải tự động cập nhật tồn kho theo thời gian thực (real-time) ngay khi giao dịch xuất/nhập kho được xác nhận thành công”.Mâu thuẫn nằm ở actor và hành động: quy tắc chuẩn giao hệ thống ERP tự động cập nhật; mô tả đích giao bộ phận Hỗ trợ cập nhật thủ công trong thời hạn 1 giờ. Hai cơ chế tạo outcome khác nhau và không thể cùng là định nghĩa của một quy tắc. |
SỬA LỖI. Owner của TMPL-OPS-SUPPORT-READINESS-001 phải sửa nội dung Mục 3.3 để phản ánh đúng BR-INV-005: hệ thống ERP tự động cập nhật tồn kho khi giao dịch xuất/nhập được xác nhận thành công.Nếu cần quy trình hỗ trợ khi cập nhật tự động thất bại, quy trình đó phải được ghi là xử lý sự cố, không được thay thế hoặc diễn giải lại quy tắc hệ thống. |
| Định nghĩa Phần tử Dữ liệu | /01-curriculum/CANONICAL_DATA_DICTIONARY.md |
Mục 4.1 - Case Study Nova Foods: Bằng chứng (Payload API) trong tài liệu này |
Kiểu dữ liệu và ràng buộc supplier.taxCode phải khớp Từ điển Dữ liệu Chuẩn. |
ĐẠT.CANONICAL_DATA_DICTIONARY.md định nghĩa supplier.taxCode là string, pattern: ^\d{10}(-\d{3})?$. Ví dụ payload trong Mục 4.1 dùng "0312345678", khớp định dạng. |
Không cần hành động. Khi payload thay đổi, Owner phải đối chiếu lại kiểu dữ liệu và pattern trước khi bàn giao. |
| Đăng ký Định danh Truy vết | /01-curriculum/TRACEABILITY_ID_REGISTRY.md |
Mục 4.2 - Case Study Nova Foods: Bảng Truy vết Yêu cầu trong tài liệu này |
Mọi ID yêu cầu, gồm REQ-..., phải tồn tại trong Sổ Đăng ký Định danh Chuẩn. |
THIẾU (MISSING).Bảng truy vết tham chiếu REQ-SUPPORT-003: Yêu cầu về báo cáo hỗ trợ hàng ngày. ID này chưa được đăng ký trong TRACEABILITY_ID_REGISTRY.md.Thiếu ID làm đứt liên kết giữa yêu cầu, bằng chứng và trách nhiệm xác minh. |
SỬA LỖI. Owner của TMPL-OPS-SUPPORT-READINESS-001 phải gửi yêu cầu đăng ký REQ-SUPPORT-003 cho Owner của TRACEABILITY_ID_REGISTRY.md, là Principal IT BA.Principal IT BA phải quyết định đăng ký ID hoặc yêu cầu thay bằng ID đã đăng ký. Sau khi registry cập nhật, Owner phải đối chiếu lại Mục 4.2. Không được baseline tài liệu này khi ID chưa hợp lệ. |
Kết luận:
Kiểm tra phát hiện hai lỗi nghiêm trọng:
- Mâu thuẫn logic giữa diễn giải hỗ trợ và quy tắc chuẩn
BR-INV-005. REQ-SUPPORT-003chưa tồn tại trongTRACEABILITY_ID_REGISTRY.md.
Owner phải xử lý cả hai lỗi, lưu bằng chứng sửa đổi trong hệ thống quản lý phiên bản, rồi chạy lại đối chiếu. Artifact vẫn ở trạng thái IN_REVIEW. Artifact không được dùng làm cơ sở cấu hình production, cam kết dịch vụ, hoặc phê duyệt triển khai khi hai lỗi còn mở.
Vấn đề Mở, Giả định và Yêu cầu Xác minh
Bảng này theo dõi mọi điểm chưa giải quyết trước bàn giao. Mỗi mục phải có owner, hành động, outcome mong đợi và trạng thái. Không mục nào tự đóng khi tài liệu đổi phiên bản hoặc được chia sẻ cho bên nhận.
| ID Vấn đề | Loại & Nội dung | Artifacts/ID bị ảnh hưởng | Owner chịu trách nhiệm | Mức độ ảnh hưởng | Hành động tiếp theo | Trạng thái |
|---|---|---|---|---|---|---|
ISSUE-SR-001 |
Giả định: Toàn bộ corpus tài liệu lõi đang ở trạng thái IN_REVIEW. Không artifact nào là BASELINED. Nội dung còn có thể thay đổi theo review. |
00_SOURCE_MAP, 01_CURRICULUM_ARCHITECTURE, CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY |
Principal IT BA / Technical Curriculum Author | Cao: Thay đổi artifact kiến trúc lõi có thể phá tính nhất quán của tài liệu phái sinh. | Hoàn tất review Phase 1. Principal IT BA và Technical Curriculum Author phải trình kế hoạch baseline cho artifact kiến trúc, manifest và registry. Kế hoạch phải nêu artifact, owner, bằng chứng review và quyết định trạng thái. | OPEN |
ISSUE-SR-002 |
Yêu cầu xác minh: Quy tắc nghiệp vụ suy ra từ luật Việt Nam cần được vai trò có thẩm quyền xác nhận trước khi dùng làm test basis. |
CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và yêu cầu liên quan đến Luật Kế toán (88/2015/QH13), Luật Bảo vệ dữ liệu cá nhân (91/2025/QH15) |
Legal Owner, Accounting Owner | Cao: Diễn giải sai luật hoặc quy định kế toán có thể gây không tuân thủ, rủi ro pháp lý và tài chính cho Nova Foods. | Principal IT BA phải đóng gói quy tắc liên quan, gửi review chính thức cho Legal Owner và Accounting Owner, ghi nhận phản hồi và phạm vi xác nhận. Chỉ quy tắc được xác nhận mới được dùng làm test basis. |
PENDING_VERIFICATION |
ISSUE-SR-003 |
Giả định: TMPL-OPS-SUPPORT-READINESS-001 đáp ứng đúng và đủ nhu cầu của đội Vận hành và Hỗ trợ, dù chưa có xác nhận chính thức. |
TMPL-OPS-SUPPORT-READINESS-001 |
Business Owner (Head of Operations/Support) | Trung bình: Template có thể không phù hợp thực tế, dẫn đến làm lại hoặc không được áp dụng. | Business Owner phải tham gia walkthrough với đại diện Vận hành/Hỗ trợ, đánh giá trường thông tin, trách nhiệm Tier và bằng chứng bàn giao. Owner phải ghi nhận phản hồi, quyết định chấp nhận hoặc yêu cầu sửa, và liên kết bằng chứng review. | PENDING_FEEDBACK |
ISSUE-SR-004 |
Vấn đề mở: CANONICAL_DATA_DICTIONARY chưa định nghĩa đầy đủ trường dữ liệu và kiểu dữ liệu cho phân hệ ERP Nova Foods. |
CANONICAL_DATA_DICTIONARY, mọi FR và NFR tham chiếu thuộc tính dữ liệu cụ thể |
Principal IT BA, Data Architect | Cao: Thiếu định nghĩa dữ liệu chuẩn gây mâu thuẫn trong yêu cầu, thiết kế giao diện, logic xử lý, API payload và báo cáo. | Principal IT BA và Data Architect phải ưu tiên định nghĩa đối tượng dữ liệu lõi: Sản phẩm, Đơn hàng, Khách hàng và Nhà cung cấp. Mỗi định nghĩa phải nêu tên trường, kiểu, ràng buộc và nguồn thẩm quyền trước khi tài liệu phụ thuộc dùng làm nguồn chuẩn. | OPEN |
ISSUE-SR-005 |
Yêu cầu xác minh: Phạm vi trách nhiệm Tier 1, Tier 2 và Tier 3 trong template cần được trưởng bộ phận liên quan xác nhận. | TMPL-OPS-SUPPORT-READINESS-001, đặc biệt bảng phân chia trách nhiệm |
Head of Tier 1 Support, Head of Tier 2/3 Application Support | Trung bình: Trách nhiệm không rõ hoặc không đồng thuận gây chậm xử lý sự cố cho người dùng cuối. | Owner phải gửi bản dự thảo phân chia trách nhiệm cho các Head of Support. Mỗi Head phải xác nhận trách nhiệm nhận việc, điều kiện leo thang, artifact bàn giao và outcome xử lý thuộc Tier của mình. | PENDING_VERIFICATION |
ISSUE-SR-006 |
Vấn đề mở: Diễn giải BR-INV-005 tại Mục 3.3 mâu thuẫn CANONICAL_BUSINESS_RULES.md. |
BR-INV-005, Mục 3.3 - Case Study Nova Foods: Quy trình Hỗ trợ Cập nhật Tồn kho |
Owner của TMPL-OPS-SUPPORT-READINESS-001 |
Cao: Hỗ trợ có thể xử lý cập nhật tồn kho như thao tác thủ công thay vì nhận diện lỗi cập nhật tự động, gây sai quy trình và sai kỳ vọng vận hành. | Owner phải sửa Mục 3.3 theo định nghĩa canonical. Nếu có xử lý khi ERP không cập nhật, Owner phải mô tả đó là quy trình sự cố với trigger, actor, escalation và outcome riêng. Chạy lại kiểm tra BR-INV-005 sau sửa. |
OPEN |
ISSUE-SR-007 |
Vấn đề mở: REQ-SUPPORT-003 được tham chiếu nhưng chưa đăng ký trong TRACEABILITY_ID_REGISTRY.md. |
REQ-SUPPORT-003, Mục 4.2 - Case Study Nova Foods: Bảng Truy vết Yêu cầu, TRACEABILITY_ID_REGISTRY.md |
Principal IT BA | Cao: Không thể chứng minh truy vết hợp lệ từ yêu cầu báo cáo hỗ trợ hàng ngày đến bằng chứng, kiểm thử và quyết định review. | Principal IT BA phải đăng ký REQ-SUPPORT-003 hoặc chỉ định ID đã đăng ký thay thế. Owner của template phải cập nhật Mục 4.2 theo quyết định registry và xác nhận ID tồn tại trước khi đóng vấn đề. |
OPEN |
Quy tắc Bàn giao và Lan truyền Thay đổi
Mục này xác định bàn giao có kiểm soát khi artifact ở trạng thái IN_REVIEW và xử lý thay đổi để giữ nhất quán trong corpus Nova Foods. “Bàn giao” (Handoff) nghĩa là cung cấp tài liệu cho nhóm liên quan, gồm Vận hành và Hỗ trợ Kỹ thuật, để review và chuẩn bị. Bàn giao không chuyển quyền sở hữu, không phê duyệt nội dung, không cấp phép triển khai.
Bảng 1: Quy tắc Bàn giao cho Artifact có trạng thái IN_REVIEW
| Quy tắc ID | Điều kiện & Hành động | Lý do & Diễn giải Kiểm soát |
|---|---|---|
HNDF-RULE-01 |
Điều kiện: Tài liệu có trạng thái IN_REVIEW.Hành động: Bàn giao chỉ bằng liên kết URL tới vị trí canonical của artifact trong hệ thống quản lý phiên bản. Không gửi bản sao tệp, gồm .md, .pdf, .docx. |
Bên nhận truy cập phiên bản đang được review. Bản sao tĩnh có thể lỗi thời, gây sai lệch trong chuẩn bị hoặc phân tích tác động. |
HNDF-RULE-02 |
Điều kiện: Bên nhận đã được cấp quyền truy cập. Hành động: Bên nhận phải xác nhận qua kênh có ghi vết, như ticket Jira hoặc email trả lời, rằng họ đã nhận liên kết và hiểu artifact là IN_REVIEW, chưa baseline, chưa phê duyệt, không dùng cho production. |
Tạo audit trail cho bàn giao. Xác nhận ngăn diễn giải sai trạng thái và giảm rủi ro hành động dựa trên nội dung chưa hoàn thiện. |
HNDF-RULE-03 |
Điều kiện: Tài liệu đã được bàn giao. Hành động: Không dùng nội dung làm cơ sở cấu hình production, đào tạo người dùng cuối, hoặc tạo cam kết dịch vụ chính thức. |
Nội dung IN_REVIEW có thể thay đổi đáng kể. Dùng cho production trước review hoàn tất có thể gây sai sót, lãng phí và rủi ro vận hành. |
HNDF-RULE-04 |
Điều kiện: Bảng kiểm tra liên tệp ghi CONFLICT hoặc MISSING còn mở.Hành động: Owner phải nêu rõ ID vấn đề mở, artifact bị ảnh hưởng và giới hạn sử dụng trong thông báo bàn giao. |
Bên nhận cần biết ranh giới tin cậy của artifact. Che giấu lỗi mở làm bên nhận dùng thông tin chưa hợp lệ làm đầu vào vận hành hoặc kiểm thử. |
“Lan truyền Thay đổi” (Change Propagation) là cơ chế bắt buộc khi artifact nguồn, như /01-curriculum/CANONICAL_BUSINESS_RULES.md, thay đổi. Owner phải phân tích và áp dụng thay đổi nhất quán cho artifact phụ thuộc, gồm tài liệu này.
Bảng 2: Quy tắc Lan truyền Thay đổi
| Quy tắc ID | Kịch bản Thay đổi | Hành động Bắt buộc |
|---|---|---|
CHNG-PROP-01 |
Artifact nguồn (upstream dependency) được cập nhật, ví dụ quy tắc trong CANONICAL_BUSINESS_RULES thay đổi. |
Owner của TMPL-OPS-SUPPORT-READINESS-001 phải được thông báo qua kênh có ghi vết. Owner phải đánh giá actor, hành động, object, outcome, artifact truy vết và kiểm thử bị ảnh hưởng; cập nhật tài liệu khi cần; ghi lịch sử phiên bản; tăng phiên bản, ví dụ v0.9.0 thành v0.9.1. |
CHNG-PROP-02 |
TMPL-OPS-SUPPORT-READINESS-001 được cập nhật. |
Owner phải thông báo cho mọi bên đã nhận bàn giao. Thông báo phải chứa liên kết canonical, ID phiên bản mới, tóm tắt thay đổi, ID vấn đề được xử lý hoặc còn mở, và hành động cần thiết của bên nhận. |
CHNG-PROP-03 |
Change request được đề xuất cho tài liệu khi đang IN_REVIEW. |
Yêu cầu thay đổi phải được ghi trong hệ thống theo dõi. Owner phải ghi quyết định chấp nhận hoặc từ chối, lý do, artifact bị ảnh hưởng và bằng chứng review. Nếu chấp nhận, Owner cập nhật tài liệu, lịch sử phiên bản và đối chiếu liên tệp liên quan. |
CHNG-PROP-04 |
Thay đổi ảnh hưởng BR-INV-005 hoặc ID trong TRACEABILITY_ID_REGISTRY.md. |
Owner phải chạy lại đối chiếu Mục 3.3 và Mục 4.2. ISSUE-SR-006 chỉ đóng khi diễn giải khớp nguồn chuẩn. ISSUE-SR-007 chỉ đóng khi REQ-SUPPORT-003 được đăng ký hoặc được thay bằng ID hợp lệ trong registry. |
CHNG-PROP-05 |
Thay đổi làm tăng phạm vi trách nhiệm Tier 1, Tier 2 hoặc Tier 3. | Owner phải gửi thay đổi cho Head of Tier 1 Support và Head of Tier 2/3 Application Support. Các Head phải xác nhận trách nhiệm, điều kiện escalation và artifact bàn giao trước khi thay đổi được dùng trong hướng dẫn hỗ trợ. |
Bàn giao và lan truyền thay đổi phải bảo toàn ranh giới thẩm quyền trong artifact quản trị của corpus. Owner của tài liệu này, Principal IT Business Analyst / Technical Curriculum Author, điều phối và duy trì toàn vẹn tài liệu; Owner không thay thẩm quyền phê duyệt của Legal Owner, Accounting Owner, Business Owner hoặc Head of Support. Artifact giữ trạng thái IN_REVIEW. Chuyển sang BASELINED hoặc APPROVED đòi hỏi phê duyệt chính thức từ vai trò có thẩm quyền.