23 Capstone Nova Foods Delivery Pack

Metadata quản trị artifact

Trường kiểm soát	Giá trị
Artifact ID	HBK-DELIVERY-PACK-CAPSTONE
Tên tệp	/02-handbook/23-capstone-nova-foods-delivery-pack.md
Tiêu đề	23 Capstone Nova Foods Delivery Pack
Trạng thái	IN_REVIEW
Ý nghĩa trạng thái	Nội dung đang được rà soát. Không phải baseline. Không phải phê duyệt. Người tiêu thụ artifact không dùng nội dung này làm bằng chứng đã chấp thuận, requirement Nova Foods đã xác nhận, hay quyền triển khai production.
Phiên bản	v0.9.0
Quy tắc phiên bản	Phiên bản nhận diện trạng thái artifact tại lần cập nhật hiện tại. Owner tăng phiên bản khi thay đổi nội dung, cấu trúc, metadata hoặc truy vết; lịch sử thay đổi phải ghi phạm vi, tác động và trạng thái.
Owner	Principal IT Business Analyst / Technical Curriculum Author
Trách nhiệm Owner	Tạo, duy trì nội dung chương. Bảo toàn cấu trúc, metadata, ngôn ngữ. Ghi nhận thay đổi artifact và lịch sử phiên bản.
Giới hạn thẩm quyền Owner	Không phê duyệt nội dung. Không xác nhận requirement Nova Foods. Không diễn giải pháp lý, kế toán, thuế. Không cấp phép triển khai production.
Last updated date	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale áp dụng	vi-VN
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Phân loại artifact	Chương sách hướng dẫn
Trạng thái baseline	Chưa baseline
Trạng thái phê duyệt	Chưa phê duyệt
Lịch sử thay đổi	v0.9.0 — 2026-08-07 — Principal IT Business Analyst / Technical Curriculum Author cập nhật metadata quản trị: trạng thái, phiên bản và lịch sử artifact. Kết quả: artifact giữ trạng thái IN_REVIEW; không tạo baseline hoặc phê duyệt.
Tham chiếu quản trị	00_SOURCE_MAP, 01_CURRICULUM_ARCHITECTURE, CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY
Ghi chú Nova Foods	Mọi ví dụ Nova Foods mô phỏng. Không phản ánh nghiệp vụ thực tế. Không tạo nghĩa vụ tuân thủ pháp lý hay kế toán.

1. Concept là gì?

Core

"Concept" (khái niệm) là ý tưởng cốt lõi. Một suy nghĩ trừu tượng. Mô tả thứ gì đó. Thứ đó có ý nghĩa riêng. Concept giúp hiểu thực tế. Giúp giao tiếp rõ ràng. Giúp giải quyết vấn đề nghiệp vụ.

Trong phân tích nghiệp vụ (BA), concept là nền tảng. Mọi requirement, mọi giải pháp bắt nguồn từ concept. Concept có ranh giới rõ ràng. Có tính chất đặc trưng.

Ví dụ: "Đơn hàng" là concept. Mô tả ý nghĩa việc khách hàng yêu cầu sản phẩm. Tính chất của "Đơn hàng": mã duy nhất, ngày đặt hàng, trạng thái (mới, đang xử lý, hoàn thành), danh sách sản phẩm.

Concept không phải màn hình giao diện. Không phải trường dữ liệu cụ thể trên hệ thống. Concept không phải mã nguồn lập trình. Không phải cấu trúc bảng cơ sở dữ liệu. Concept tồn tại độc lập. Đại diện một ý nghĩa nghiệp vụ. Là mô hình tinh thần. Hiểu concept giúp tránh nhầm lẫn. Tránh xây dựng sai giải pháp. Concept là bước đầu. Trước mọi chi tiết kỹ thuật.

Thuật ngữ nghiệp vụ cốt lõi

IT Business Analyst (BA) cần hiểu ngôn ngữ nghiệp vụ. Bốn thuật ngữ cốt lõi này dựng nền tảng mô tả yêu cầu. Phân biệt rõ Tác nhân, Hành động, Đối tượng, Kết quả giúp BA nắm bắt đúng bản chất yêu cầu.

Thuật ngữ tiếng Anh	Thuật ngữ tiếng Việt	Giải thích vắn tắt
Actor	Tác nhân	Thực thể khởi xướng hành động hoặc tương tác hệ thống. Tác nhân là người (ví dụ: nhân viên kho Nova Foods, khách hàng), hệ thống ngoài (ví dụ: cổng thanh toán, hệ thống vận chuyển đối tác), hoặc thành phần trong hệ thống (ví dụ: module tự động kiểm tra tồn kho). BA xác định ai/cái gì cần hệ thống hoặc sẽ dùng hệ thống.
Action	Hành động	Hoạt động cụ thể Tác nhân thực hiện. Luôn là động từ mạnh, mô tả chức năng hoặc quá trình nghiệp vụ. Ví dụ: "Tạo đơn hàng", "Duyệt yêu cầu", "Cập nhật trạng thái", "Xuất báo cáo". Hành động chỉ ra Tác nhân làm gì để đạt mục tiêu.
Object	Đối tượng	Thực thể hoặc dữ liệu Hành động tác động lên. Là danh từ, là "thứ" bị thay đổi, tạo ra, hoặc dùng bởi Hành động. Ví dụ: "Đơn hàng" (được tạo, được duyệt), "Sản phẩm" (được cập nhật tồn kho), "Báo cáo doanh thu" (được xuất). Đối tượng là trọng tâm Hành động.
Outcome	Kết quả	Trạng thái cuối cùng hoặc thay đổi quan sát được sau Hành động. Là mục tiêu mong muốn Hành động. Kết quả phải rõ, đo lường được nếu cần, xác định sự thành công Hành động. Ví dụ: "Đơn hàng đã tạo thành công", "Yêu cầu đã duyệt", "Tồn kho đã cập nhật chính xác", "Báo cáo đã có sẵn để xem".

Phân tích yêu cầu nghiệp vụ, BA tách bạch các thành phần này. Tác nhân [thực hiện] Hành động [lên] Đối tượng [để đạt] Kết quả. Cấu trúc này giúp BA và bên liên quan giao tiếp rõ, giảm hiểu lầm chức năng hệ thống.

Ví dụ Nova Foods mô phỏng và Giới hạn Khái niệm

Nova Foods cần tính năng "Theo dõi Đơn hàng Tự phục vụ" (Customer Self-Service Order Tracking). Khách hàng xem trạng thái đơn hàng trên nền tảng số. Business Analyst (BA) thu thập yêu cầu. BA phân tích, lập Bộ Hồ sơ Bàn giao (Delivery Pack). Bộ Hồ sơ này gồm: * Mô tả yêu cầu người dùng (User Stories). * Tiêu chí chấp nhận (Acceptance Criteria) cho mỗi yêu cầu. * Biểu đồ luồng nghiệp vụ (Business Process Flow Diagram) quy trình theo dõi. * Mô hình dữ liệu logic hoặc cập nhật Từ điển Dữ liệu (Data Dictionary). * Đặc tả tích hợp API với hệ thống giao vận nội bộ Nova Foods. * Yêu cầu bảo mật dữ liệu khách hàng (áp dụng Luật Bảo vệ dữ liệu cá nhân Việt Nam, tiêu chuẩn OWASP). * Ma trận truy vết (Traceability Matrix) liên kết yêu cầu với thiết kế.

Bộ Hồ sơ này chuyển đến đội phát triển, đội kiểm thử (QA), Product Owner. Đội phát triển dùng để xây dựng phần mềm. Đội QA dùng để kiểm tra tính năng. Product Owner dùng để xác nhận phạm vi. Lý do: Đảm bảo mọi bên liên quan hiểu đúng, có chung tài liệu gốc, giảm hiểu sai.

Bộ Hồ sơ Bàn giao BA là tập hợp tài liệu BA chuẩn hóa. Nó không phải mọi tài liệu dự án.

Nội dung bao gồm: * Mục đích: Chuyển giao thông tin nghiệp vụ, yêu cầu hệ thống chi tiết. * Người tạo: Business Analyst. * Người nhận: Đội phát triển, kiểm thử, Product Owner, đội triển khai hệ thống. * Trọng tâm: Giải thích "cái gì" hệ thống phải làm, "làm như thế nào" về mặt logic nghiệp vụ. * Phạm vi: Yêu cầu chức năng, yêu cầu phi chức năng, cấu trúc dữ liệu, đặc tả tích hợp, quy trình nghiệp vụ được tự động hóa.

Nội dung loại trừ: * Kế hoạch quản lý dự án: Chi phí, thời gian, phân bổ nguồn lực. Lý do: Trách nhiệm Project Manager, không phải đầu ra trực tiếp BA. * Hợp đồng pháp lý: Hợp đồng với nhà cung cấp phần mềm, đối tác. Lý do: Chức năng Legal/Procurement, không phải BA. * Tài liệu marketing hoặc đào tạo người dùng cuối: Mô tả sản phẩm cho thị trường, hướng dẫn sử dụng chi tiết cho người dùng cuối. Lý do: Phát triển ở giai đoạn sau, bởi đội Marketing hoặc Training. * Quy trình vận hành hỗ trợ IT: Hướng dẫn đội IT vận hành, bảo trì hệ thống sau triển khai. Lý do: Tạo bởi đội vận hành IT khi hệ thống gần go-live hoặc sau go-live.

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

Core

Dự án phần mềm lớn, như Nova Foods ERP, gặp nhiều rủi ro. Rủi ro gồm: thất bại dự án, làm lại (rework) nhiều, mơ hồ yêu cầu, quản trị kém. "Delivery Pack" (Bộ Hồ sơ Bàn giao) ra đời để chống lại rủi ro này.

• Thất bại dự án: Phát triển sai chức năng. Lý do: Thiếu tài liệu chuẩn, không rõ yêu cầu.
• Làm lại (Rework): Code xong, phát hiện sai. Lý do: Business nói một kiểu, IT hiểu một nẻo. Hoặc yêu cầu thay đổi liên tục, không ghi nhận.
• Mơ hồ yêu cầu: Không có nguồn chân lý duy nhất. Lý do: Yêu cầu nằm rải rác: email, chat, cuộc họp, file cá nhân.
• Rủi ro quản trị: Không ai chịu trách nhiệm rõ ràng cho một phần yêu cầu. Lý do: Thiếu quy trình, thiếu kiểm soát tài liệu. Dẫn đến sai phạm pháp luật (ví dụ: Luật Kế toán 88/2015/QH13, Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15).

"Delivery Pack" khắc phục: Tạo một nguồn duy nhất, rõ ràng cho yêu cầu. Giúp đội phát triển, kiểm thử, nghiệp vụ hiểu giống nhau.

Applied

Dự án ERP của Nova Foods, quy mô lớn, tính phức tạp cao.

Mục	Mô tả	Phân loại	Nguồn
Sự thật:	Nova Foods triển khai ERP mới. Hệ thống xử lý hàng ngàn đơn hàng/ngày, quản lý chuỗi cung ứng phức tạp.	Sự thật (Fact)	Tài liệu nội bộ Nova Foods (mô phỏng)
Hành vi hiện tại (trước Delivery Pack):	Yêu cầu khách hàng (user story) gửi qua email, chat nhóm. Quyết định nghiệp vụ ghi trong biên bản họp rời rạc. Kiến trúc giải pháp trao đổi miệng.	Hành vi hiện tại (Current Behavior)	Quan sát nội bộ dự án Nova Foods (mô phỏng)
Hậu quả hành vi hiện tại:	Đội phát triển xây dựng chức năng "Giao hàng", không tính đến "Quản lý tồn kho lạnh" cho sản phẩm đông lạnh. Đội kiểm thử không biết kiểm tra quy định an toàn thực phẩm. Kế toán báo lỗi nhập liệu do không nắm rõ logic nghiệp vụ.	Hậu quả (Consequence)	Báo cáo lỗi nội bộ Nova Foods (mô phỏng)
Nhu cầu cốt lõi:	Cần một bộ tài liệu duy nhất, chính xác. Tập hợp yêu cầu, quyết định, quy trình. Giúp mọi đội hiểu đúng, làm đúng, tuân thủ.	Nhu cầu cốt lõi (Underlying Need)	Phân tích vấn đề nội bộ Nova Foods (mô phỏng)
Lựa chọn:	1. Tiếp tục cách làm cũ (không Delivery Pack). 2. Áp dụng "Delivery Pack".	Lựa chọn (Options)	BA đề xuất (mô phỏng)
Tiêu chí quyết định:	Giảm 20% lỗi sau triển khai. Giảm 30% thời gian làm lại. Đảm bảo tuân thủ Luật Kế toán và Luật Bảo vệ dữ liệu cá nhân.	Tiêu chí quyết định (Decision Criteria)	Đầu vào nghiệp vụ (Stakeholder Input) Nova Foods
Quyết định:	Nova Foods quyết định xây dựng và sử dụng "Delivery Pack" chuẩn hóa.	Quyết định (Decision)	Ban chỉ đạo dự án ERP Nova Foods (mô phỏng)
Thẩm quyền:	Product Owner, Trưởng bộ phận nghiệp vụ, Kiến trúc sư giải pháp (Solution Architect).	Thẩm quyền (Authority)	Điều lệ dự án Nova Foods (mô phỏng)
Artifact:	23-capstone-nova-foods-delivery-pack.md và các tài liệu con bên trong (đặc tả yêu cầu, thiết kế, quy trình).	Artifact	Tài liệu hướng dẫn BA (mô phỏng)
Hậu quả nếu sai (chọn cách làm cũ):	Dự án ERP trễ 6 tháng, vượt ngân sách 2 tỷ VND. Phát sinh lỗi hệ thống nghiêm trọng sau Go-live. Bị phạt do không tuân thủ quy định về hóa đơn điện tử (Nghị định 123/2020/NĐ-CP).	Hậu quả nếu sai (Consequence if Wrong)	Yêu cầu xác minh (Verification Required Claim) - Phân tích rủi ro Nova Foods (mô phỏng)

Senior Lens

Người BA cấp cao hiểu: "Delivery Pack" không chỉ là tập hợp giấy tờ. Nó là công cụ quản trị rủi ro chiến lược. Ngăn chặn nợ kỹ thuật (technical debt) do yêu cầu không rõ. Bảo vệ Nova Foods khỏi rủi ro pháp lý (ví dụ: Luật An toàn thực phẩm 55/2010/QH12 liên quan truy xuất nguồn gốc). Giúp dự án minh bạch, có thể kiểm toán. Đảm bảo mỗi đồng chi phí phát triển tạo ra giá trị đúng.

Quick Reference

Rủi ro dự án	Concept "Delivery Pack" ngăn chặn
Yêu cầu không rõ ràng	Cung cấp nguồn yêu cầu duy nhất, được phê duyệt.
Làm lại (Rework)	Định nghĩa rõ ràng chức năng, giảm hiểu lầm Business-IT.
Xâm phạm tuân thủ	Tổng hợp yêu cầu pháp lý (Luật Kế toán, Luật Bảo vệ dữ liệu cá nhân) vào tài liệu.
Thiếu truy vết	Liên kết yêu cầu với thiết kế, code, kiểm thử.
Vượt ngân sách, trễ hạn	Kiểm soát phạm vi, giảm phát sinh không cần thiết.

Tăng cường kiểm soát chất lượng giao hàng Nova Foods

Core

Khái niệm "Delivery Pack" giải quyết vấn đề thiếu tiêu chuẩn hóa quy trình giao hàng. Thiếu quy trình rõ ràng gây lỗi vận hành, tăng chi phí, giảm chất lượng dịch vụ khách hàng. Lỗi từ khâu đóng gói, vận chuyển không truy vết được.

Applied

Facts * Nova Foods kinh doanh thực phẩm tươi sống, thời gian vận chuyển quan trọng. * Thực phẩm dễ hỏng, cần bảo quản nhiệt độ và điều kiện cụ thể. * Khách hàng kỳ vọng sản phẩm chất lượng, giao đúng giờ. * NF-POLICY-DELIVERY-001: Chính sách giao hàng Nova Foods cam kết "chất lượng sản phẩm đến tay khách hàng". (Điều này là một chính sách nội bộ được xác minh). * NV_PK_003, NV_PK_004, SH_015, SH_016, KH_A001, KH_B002 là mã định danh tổng hợp, không phải cá nhân hoặc khách hàng thực tế.

Current Behavior (Trước khi có Delivery Pack) * Mô tả: Quy trình đóng gói, giao hàng ad-hoc (tùy tiện). Ít tài liệu hướng dẫn cụ thể cho từng loại sản phẩm. Nhân viên tự theo kinh nghiệm. * Ví dụ Nova Foods: * Đơn hàng DH20260807-001: 5kg cá hồi tươi, giao cho KH_A001 (Nguyen Van A, Quận 1). * Hành động: Nhân viên đóng gói NV_PK_003 hoàn thành gói hàng. Không có yêu cầu dán nhãn "Ưu tiên tươi sống" hoặc ghi chú nhiệt độ trên gói. * Hành động: Shipper SH_015 nhận gói, không có checklist kiểm tra đặc biệt cho hàng tươi sống. Chỉ kiểm tra địa chỉ, mã đơn. * Sự cố: Trên đường giao hàng, shipper SH_015 gặp mưa, tìm chỗ trú mưa lâu hơn cần thiết. Điều kiện bảo quản không đảm bảo. * Kết quả: Khách hàng KH_A001 nhận hàng, thấy cá hồi kém tươi, ẩm ướt. Khách hàng gọi tổng đài khiếu nại. * Hậu quả quan sát được: * KH_A001 hủy đơn, yêu cầu hoàn tiền VND 1.500.000. * KH_A001 đánh giá 1 sao, không tiếp tục đặt hàng Nova Foods. * Bộ phận CSKH không xác định được nguyên nhân lỗi rõ ràng (do đóng gói, vận chuyển, hay shipper). * Nova Foods thiệt hại trực tiếp doanh thu và mất uy tín.

Current Behavior (Sau khi có Delivery Pack) * Mô tả: Quy trình đóng gói, giao hàng tiêu chuẩn hóa với "Delivery Pack" hướng dẫn. Bao gồm biểu mẫu, checklist, quy định dán nhãn. * Ví dụ Nova Foods: * Đơn hàng DH20260807-002: 5kg cá hồi tươi, giao cho KH_B002 (Le Thi B, Quận 3). * Hành động: Nhân viên đóng gói NV_PK_004 sử dụng NF-DP-V1.0-FORM-001 (Phiếu Đóng Gói). Form yêu cầu dán NF-LABEL-FRESH-01 (nhãn "Ưu tiên tươi sống"), ghi rõ Nhiệt độ đóng gói: 4°C và kiểm tra độ kín Bao bì đạt chuẩn. NV_PK_004 ký xác nhận. Phiếu này đi kèm gói hàng. * Hành động: Shipper SH_016 nhận gói. Kiểm tra NF-DP-V1.0-CHECKLIST-001 (Checklist Giao Hàng). Checklist có mục kiểm tra nhiệt độ gói tại thời điểm nhận và hướng dẫn xử lý thời tiết xấu: "Sử dụng hộp bảo ôn phụ và che chắn". * Sự cố: Trên đường giao, shipper SH_016 gặp mưa. Theo checklist, shipper sử dụng hộp bảo ôn phụ mang theo và che chắn gói hàng cẩn thận. * Kết quả: Khách hàng KH_B002 nhận hàng, cá hồi tươi ngon, bao bì khô ráo, nguyên vẹn. Khách hàng hài lòng. * Hậu quả quan sát được: * KH_B002 đánh giá 5 sao, chia sẻ kinh nghiệm tốt trên mạng xã hội. * KH_B002 tiếp tục đặt hàng Nova Foods, tăng giá trị khách hàng trọn đời. * "Delivery Pack" với các form và checklist đã ký xác nhận tạo bằng chứng rõ ràng cho từng bước. Dễ dàng truy vết, phân tích để cải tiến liên tục. * Nova Foods giữ vững doanh thu, tăng cường uy tín, giảm chi phí xử lý khiếu nại.

Underlying Need * Giảm sai sót trong quá trình giao hàng thực phẩm tươi sống. * Nâng cao sự hài lòng của khách hàng. * Bảo đảm chất lượng sản phẩm khi đến tay người tiêu dùng. * Cải thiện khả năng truy vết và phân tích nguyên nhân sự cố. * Đảm bảo tuân thủ các quy định về an toàn thực phẩm. (Luật An toàn thực phẩm 55/2010/QH12).

Options 1. Chỉ đào tạo lại nhân viên: Chi phí thấp, nhưng hiệu quả không bền vững do phụ thuộc cá nhân. 2. Đầu tư công nghệ theo dõi: Chi phí cao, cần thời gian triển khai, không giải quyết gốc rễ quy trình. 3. Tiêu chuẩn hóa quy trình với "Delivery Pack": Chi phí vừa phải, tạo bằng chứng, dễ đào tạo, cải thiện hệ thống.

Decision Criteria * Hiệu quả giảm lỗi: Giải pháp nào giảm tỷ lệ khiếu nại về chất lượng và độ tươi sản phẩm? * Chi phí triển khai: Giải pháp có thể thực hiện trong ngân sách dự án. * Dễ áp dụng: Nhân viên hiện tại có thể nhanh chóng làm quen và thực hiện. * Khả năng truy vết: Giải pháp có cung cấp bằng chứng rõ ràng cho việc điều tra sự cố. * Phù hợp với đặc thù sản phẩm: Giải pháp có đáp ứng yêu cầu đặc biệt của thực phẩm tươi sống.

Decision Nova Foods quyết định triển khai concept "Delivery Pack" để tiêu chuẩn hóa quy trình, tập trung vào việc tạo ra các artifacts có thể kiểm tra được (checklist, phiếu đóng gói) nhằm giảm thiểu sai sót và tăng cường kiểm soát chất lượng.

Authority * Trưởng phòng Vận hành Nova Foods (Business Owner) * Quản lý Sản phẩm (Product Owner)

Artifact * NF-DP-V1.0-FORM-001: Phiếu đóng gói có checklist chi tiết. * NF-DP-V1.0-CHECKLIST-001: Checklist giao hàng cho shipper. * NF-LABEL-FRESH-01: Nhãn sản phẩm tươi sống.

Consequence if Wrong Nếu quyết định này sai (ví dụ, "Delivery Pack" không được áp dụng hoặc thiết kế kém): * Tỷ lệ khiếu nại khách hàng tiếp tục cao. * Sản phẩm hư hỏng trong quá trình vận chuyển không giảm. * Uy tín thương hiệu Nova Foods suy giảm nghiêm trọng. * Tăng chi phí bồi thường, quản lý rủi ro và chi phí vận hành. * Có nguy cơ vi phạm Luật An toàn thực phẩm nếu xảy ra sự cố nghiêm trọng.

Senior Lens

"Delivery Pack" không chỉ tài liệu. Nó công cụ quản trị rủi ro vận hành, bằng chứng tuân thủ, cơ sở đào tạo. Giúp biến quy trình ngầm thành tường minh. Tránh lỗi lặp lại, tiết kiệm chi phí dài hạn.

Quick Reference

Hạng mục	Trước "Delivery Pack"	Sau "Delivery Pack"
Rủi ro chính	Lỗi vận hành tùy tiện	Rủi ro được quản lý
Chất lượng giao	Không ổn định, dễ hỏng	Kiểm soát tốt, ổn định
Truy vết lỗi	Khó hoặc không thể	Dễ dàng, có bằng chứng
Uy tín khách hàng	Giảm sút do khiếu nại	Tăng cường do hài lòng
Chi phí	Cao do bồi thường, xử lý lỗi	Giảm do quy trình chuẩn hóa
Tuân thủ	Rủi ro pháp lý tiềm ẩn	Có cơ sở kiểm chứng

Phân biệt Sự thật đã xác minh, Đầu vào từ bên liên quan, Giả định dự án, Quyết định và Tuyên bố cần xác minh

Trong môi trường dự án phức tạp như triển khai ERP (Enterprise Resource Planning - Hệ thống hoạch định nguồn lực doanh nghiệp) tại Nova Foods, việc phân biệt các loại thông tin khác nhau là nền tảng để tránh hiểu lầm, giảm thiểu rủi ro, và đảm bảo các yêu cầu nghiệp vụ (requirements) được xây dựng trên cơ sở vững chắc. Mỗi loại thông tin có nguồn gốc, độ tin cậy và tác động khác nhau đến dự án.

Core

Loại thông tin	Định nghĩa	Tính chất	Ví dụ chung	Rủi ro chính nếu không phân biệt
Sự thật đã xác minh	Thông tin khách quan, có thể kiểm chứng được bằng bằng chứng hoặc nguồn đáng tin cậy.	Khách quan, có bằng chứng, đã được kiểm tra (verified).	Luật pháp, quy định chuẩn, báo cáo hệ thống hiện có.	Xây dựng giải pháp sai cơ sở pháp lý, kỹ thuật.
Đầu vào từ bên liên quan	Thông tin, ý kiến, mong muốn, yêu cầu từ các cá nhân hoặc nhóm có ảnh hưởng/bị ảnh hưởng bởi dự án.	Chủ quan, chưa được kiểm chứng, thể hiện quan điểm.	"Tôi muốn hệ thống làm X", "Khách hàng của tôi cần Y".	Giải pháp không đúng nhu cầu thực, bỏ sót bên liên quan.
Giả định dự án	Một yếu tố được chấp nhận là đúng cho mục đích lập kế hoạch, mặc dù chưa được chứng minh.	Tạm thời đúng, chưa kiểm chứng, có rủi ro.	"Dữ liệu cũ sẽ tương thích với hệ thống mới".	Kế hoạch sai lệch, phát sinh vấn đề lớn khi giả định sai.
Quyết định	Một lựa chọn được đưa ra sau khi xem xét các phương án, thường có mục tiêu và người có thẩm quyền.	Đã lựa chọn, có người chịu trách nhiệm.	"Chúng ta sẽ chọn phương án A để triển khai."	Không có hướng đi rõ ràng, thay đổi liên tục, xung đột.
Tuyên bố cần xác minh	Một khẳng định được đưa ra nhưng cần được kiểm tra, chứng thực hoặc làm rõ trước khi sử dụng.	Chưa được kiểm chứng, cần hành động.	"Tất cả địa chỉ khách hàng đều chuẩn xác."	Yêu cầu nghiệp vụ sai, dẫn đến lỗi hệ thống.

Việc phân biệt rõ ràng các loại thông tin này giúp BA (Business Analyst - Chuyên viên phân tích nghiệp vụ) xây dựng yêu cầu chính xác, quản lý kỳ vọng của bên liên quan, đánh giá rủi ro dự án và hỗ trợ ra quyết định hiệu quả.

Applied

Nova Foods đang xem xét thêm trường "Thời gian giao hàng dự kiến" (Estimated Delivery Time) vào phiếu giao hàng (delivery pack) điện tử để cải thiện trải nghiệm khách hàng.

• Facts (Sự thật đã xác minh)
  • Nguồn: Luật Kế toán 88/2015/QH13 (Luật Kế toán) và Nghị định 123/2020/NĐ-CP (Hóa đơn, chứng từ) quy định các thông tin bắt buộc trên phiếu xuất kho kiêm vận chuyển nội bộ không bao gồm "Thời gian giao hàng dự kiến".
  • Hệ thống hiện tại: ERP Nova Foods (phiên bản mô phỏng v0.9.0) có trường EstimatedDeliveryDateTime trong cơ sở dữ liệu của module Vận chuyển nhưng chưa hiển thị trên các biểu mẫu in ấn hoặc điện tử công khai.
• Current Behavior (Hành vi hiện tại)
  • Khách hàng Nova Foods nhận phiếu giao hàng không có thông tin thời gian giao hàng dự kiến.
  • Hàng ngày, phòng Dịch vụ Khách hàng (Customer Service - CS) nhận trung bình 50 cuộc gọi hỏi về tình trạng giao hàng.
• Underlying Need (Nhu cầu cốt lõi)
  • Giảm số lượng cuộc gọi hỏi tình trạng giao hàng đến phòng CS.
  • Nâng cao sự hài lòng và trải nghiệm của khách hàng thông qua việc cung cấp thông tin minh bạch.
  • Tối ưu hóa quy trình vận chuyển bằng cách cung cấp thông tin kịp thời cho khách hàng.
• Options (Các phương án)
  1. Chỉ hiển thị "Thời gian giao hàng dự kiến" trên phiếu giao hàng điện tử nội bộ cho tài xế.
  2. Hiển thị "Thời gian giao hàng dự kiến" trên tất cả các phiếu giao hàng điện tử gửi cho khách hàng, sử dụng dữ liệu từ module Vận chuyển hiện có.
  3. Tích hợp API (Application Programming Interface - Giao diện lập trình ứng dụng) với nhà cung cấp dịch vụ vận chuyển bên thứ ba để hiển thị thời gian giao hàng dự kiến theo thời gian thực (real-time).
• Decision Criteria (Tiêu chí ra quyết định)
  • Tính tuân thủ: Không vi phạm pháp luật hiện hành.
  • Chi phí: Chi phí phát triển, triển khai và bảo trì.
  • Mức độ cải thiện trải nghiệm khách hàng: Có giảm được cuộc gọi đến CS không?
  • Khả năng triển khai: Mức độ phức tạp kỹ thuật và thời gian cần thiết.
  • Chất lượng dữ liệu: Đảm bảo thông tin dự kiến là đủ chính xác.
• Decision (Quyết định)
  • Nova Foods sẽ triển khai Phương án 2: Hiển thị trường "Thời gian giao hàng dự kiến" trên phiếu giao hàng điện tử gửi cho khách hàng, sử dụng dữ liệu từ module Vận chuyển hiện có của ERP.
• Authority (Thẩm quyền)
  • Giám đốc Kinh doanh (Business Owner) - phê duyệt lợi ích kinh doanh.
  • Trưởng dự án ERP - phê duyệt tính khả thi kỹ thuật và phạm vi dự án.
• Artifact (Kết quả tài liệu)
  • SRS (Software Requirements Specification - Đặc tả yêu cầu phần mềm) được cập nhật: Thêm yêu cầu hiển thị EstimatedDeliveryDateTime trên mẫu phiếu giao hàng điện tử NF-DELIVERY-PACK-V1.2.
  • Bản thiết kế giao diện (UI/UX - User Interface/User Experience) của phiếu giao hàng được cập nhật.
• Consequence if Wrong (Hậu quả nếu sai)
  • Nếu giả định về chất lượng dữ liệu (EstimatedDeliveryDateTime luôn có sẵn và chính xác) là sai: Khách hàng nhận thông tin sai lệch, tăng phàn nàn, làm mất uy tín Nova Foods, và tăng áp lực lên phòng CS thay vì giảm.
  • Nếu không phân biệt đầu vào từ Trưởng phòng CS (mong muốn giảm cuộc gọi) với nhu cầu pháp lý, dự án có thể lãng phí nguồn lực để tích hợp một tính năng không bắt buộc mà không mang lại giá trị thực sự cho khách hàng hoặc không giải quyết được vấn đề cốt lõi.

Quá trình xem xét và đưa ra quyết định này có thể được hình dung qua sơ đồ sau:

graph TD
    A[Yêu cầu/Thông tin mới] --> B{Phân loại?}
    B -- "Dữ liệu khách quan, có nguồn" --> C(Sự thật đã xác minh<br/>- Luật 88/2015/QH13<br/>- Dữ liệu ERP hiện có)
    B -- "Ý kiến, mong muốn từ người dùng" --> D(Đầu vào từ bên liên quan<br/>- Trưởng phòng CS: "Giảm cuộc gọi"<br/>- Trưởng phòng Vận chuyển: "Có thể cập nhật app")
    B -- "Tạm coi là đúng để lập kế hoạch" --> E(Giả định dự án<br/>- Hiệu năng hệ thống<br/>- Chất lượng dữ liệu)
    B -- "Chưa có bằng chứng, cần kiểm tra" --> F(Tuyên bố cần xác minh<br/>- Tích hợp API bên thứ 3?<br/>- Khảo sát khách hàng?)

    C --> G[Xác định ranh giới tuân thủ, khả năng kỹ thuật]
    D --> H[Phân tích nhu cầu cốt lõi, đề xuất phương án]
    E --> I[Đánh giá rủi ro giả định, kế hoạch kiểm chứng]
    F --> J[Kế hoạch xác minh: Kiểm thử, khảo sát]

    G & H --> K{Đánh giá phương án (Tiêu chí: Chi phí, Lợi ích, Khả thi)}
    I & J --> K

    K -- "Chọn Phương án 2" --> L(Quyết định<br/>- Thêm "Thời gian giao hàng dự kiến" từ ERP nội bộ<br/>- Thẩm quyền: Giám đốc KD, Trưởng dự án ERP)
    L --> M[Cập nhật SRS, thiết kế UI/UX phiếu giao hàng]

Senior Lens

Với một BA cấp cao, việc phân biệt các loại thông tin này không chỉ là một kỹ thuật mà là một nguyên tắc quản trị dự án. Nó giúp:

1. Quản lý rủi ro hiệu quả: Giả định được xác định rõ ràng cho phép BA lập kế hoạch dự phòng hoặc kiểm chứng, biến chúng thành sự thật hoặc phát hiện rủi ro sớm.
2. Xây dựng sự tin cậy: Minh bạch về những gì là "sự thật", "giả định" hay "mong muốn" giúp các bên liên quan hiểu rõ cơ sở của các yêu cầu và quyết định, tạo dựng niềm tin.
3. Tránh làm lại (rework): Yêu cầu được xây dựng trên sự thật đã xác minh sẽ giảm thiểu thay đổi và làm lại trong các giai đoạn phát triển và kiểm thử.
4. Tăng cường tính truy xuất nguồn gốc (traceability): Mỗi yêu cầu phải có nguồn gốc rõ ràng (từ sự thật, đầu vào đã được phân tích, hoặc quyết định). Điều này cần thiết cho kiểm toán, tuân thủ và bảo trì hệ thống.
5. Hỗ trợ ra quyết định: BA cấp cao không chỉ thu thập thông tin mà còn phải tổng hợp, phân tích và trình bày nó một cách có cấu trúc để hỗ trợ các Business Owner (Chủ doanh nghiệp) đưa ra quyết định sáng suốt.

Quick Reference

Loại thông tin	Câu hỏi nhanh	Trách nhiệm của BA
Sự thật đã xác minh	Nguồn nào chứng minh điều này? Có bằng chứng không?	Tìm kiếm, tham chiếu, ghi nhận nguồn canonical (Luật, Quy định).
Đầu vào từ bên liên quan	Ai nói điều này? Đó là mong muốn hay nhu cầu?	Thu thập, lắng nghe, phân tích nhu cầu thực sự.
Giả định dự án	Điều gì cần phải đúng để kế hoạch này khả thi?	Ghi nhận, đánh giá rủi ro, lập kế hoạch kiểm chứng.
Quyết định	Ai đã đưa ra quyết định này? Khi nào? Tại sao?	Ghi lại quyết định, người có thẩm quyền, cơ sở và hậu quả dự kiến.
Tuyên bố cần xác minh	Làm thế nào để biết điều này là đúng? Cần kiểm tra gì?	Lập kế hoạch kiểm chứng, yêu cầu dữ liệu, khảo sát.

3. Vị trí trong Lifecycle

Delivery Pack (gói triển khai) có vị trí quan trọng mọi giai đoạn vòng đời dự án phần mềm. BA cần hiểu rõ các cửa ra, cửa vào (entry/exit gates) từng giai đoạn. Hiểu này giúp BA định vị vai trò, hành động phù hợp, đảm bảo thông tin trao đổi chính xác, không mất mát.

Core

Dự án phần mềm trải qua các giai đoạn Discovery (Khám phá), Analysis (Phân tích), Delivery (Triển khai/Phát triển), Testing (Kiểm thử), Release (Triển khai chính thức) và Operations (Vận hành). Delivery Pack, dù tên gọi khác nhau, luôn là tập hợp tài liệu giúp truyền tải thông tin, quyết định, yêu cầu từ giai đoạn này sang giai đoạn khác. Nó là cầu nối giữa nghiệp vụ và kỹ thuật.

• Discovery (Khám phá):

  • Cửa vào: Vấn đề kinh doanh (business problem) hoặc cơ hội kinh doanh (business opportunity) được nhận diện.
  • Vai trò Delivery Pack: Gói mô tả vấn đề cấp cao, phạm vi (scope) dự kiến, mục tiêu kinh doanh (business objective), và lợi ích (benefit) mong đợi. Gói này chưa hoàn chỉnh, chỉ là khởi tạo.
  • Cửa ra: Đề xuất kinh doanh sơ bộ (initial business case) được duyệt, xác nhận vấn đề và tính khả thi (feasibility) cấp cao. Quyết định tiếp tục sang phân tích.

• Analysis (Phân tích):

  • Cửa vào: Đề xuất kinh doanh sơ bộ được duyệt, phạm vi cấp cao đã thỏa thuận.
  • Vai trò Delivery Pack: BA thu thập, phân tích yêu cầu chi tiết (detailed requirements). Gói này chứa tài liệu yêu cầu chức năng (functional requirements), phi chức năng (non-functional requirements), quy trình nghiệp vụ (business process flows), use case (kịch bản sử dụng), acceptance criteria (tiêu chí chấp nhận). Thiết kế giải pháp (solution design) bắt đầu hình thành.
  • Cửa ra: Yêu cầu đã được baseline (baselined requirements), thiết kế giải pháp được phê duyệt. Phạm vi và thiết kế cố định.

• Delivery (Triển khai/Phát triển):

  • Cửa vào: Thiết kế giải pháp được phê duyệt, yêu cầu được baseline.
  • Vai trò Delivery Pack: Cung cấp tài liệu cho đội phát triển (development team) để xây dựng giải pháp. BA hỗ trợ, giải thích yêu cầu, xác nhận hiểu biết kỹ thuật.
  • Cửa ra: Phần mềm/giải pháp được phát triển hoàn tất. Unit test nội bộ (internal unit tests) đã qua. Sẵn sàng cho kiểm thử chính thức.

• Testing (Kiểm thử):

  • Cửa vào: Phần mềm/giải pháp hoàn tất phát triển, kế hoạch kiểm thử (test plan) và tình huống kiểm thử (test cases) sẵn sàng.
  • Vai trò Delivery Pack: Yêu cầu, use case, acceptance criteria từ Delivery Pack là cơ sở kiểm thử (test basis) chính. BA làm việc với QA (Quality Assurance) để xác nhận lỗi (defects) và đảm bảo chất lượng.
  • Cửa ra: UAT (User Acceptance Testing) hoàn thành. Tất cả lỗi nghiêm trọng đã được sửa hoặc chấp nhận. Giải pháp đáp ứng yêu cầu. Phê duyệt triển khai (Go-Live Approval) từ nghiệp vụ.

• Release (Triển khai chính thức):

  • Cửa vào: Phê duyệt triển khai, mọi điều kiện tiên quyết (đào tạo, tài liệu, hạ tầng) đã sẵn sàng.
  • Vai trò Delivery Pack: Tài liệu trong gói (hướng dẫn sử dụng, tài liệu đào tạo) dùng cho triển khai, onboarding người dùng.
  • Cửa ra: Giải pháp đã triển khai lên môi trường production. Người dùng có thể truy cập. Các kiểm tra sau triển khai (post-deployment checks) đã hoàn tất.

• Operations (Vận hành):

  • Cửa vào: Giải pháp đã hoạt động trong môi trường production.
  • Vai trò Delivery Pack: Tài liệu như đặc tả chức năng (functional specifications), thiết kế kỹ thuật (technical design) dùng cho hỗ trợ (support), bảo trì (maintenance) và nâng cấp (enhancements) trong tương lai. BA phân tích dữ liệu vận hành để tìm yêu cầu mới.
  • Cửa ra: Giải pháp ngừng sử dụng (retired) hoặc bắt đầu một vòng đời mới cho nâng cấp lớn.

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

stateDiagram-v2
    direction TB

    state "Khám phá" as KhamPha
    state "Phân tích" as PhanTich
    state "Triển khai/Phát triển" as TrienKhaiPhatTrien
    state "Kiểm thử" as KiemThu
    state "Sẵn sàng Release" as SanSangRelease
    state "Triển khai chính thức" as TrienKhaiChinhThuc
    state "Vận hành" as VanHanh
    state "Kết thúc sử dụng" as KetThucSuDung

    [*] --> KhamPha: Vấn đề hoặc cơ hội kinh doanh
    KhamPha --> PhanTich: Đề xuất sơ bộ duyệt\nKhả thi cấp cao xác nhận\nQuyết định tiếp tục
    PhanTich --> TrienKhaiPhatTrien: Yêu cầu baseline\nThiết kế giải pháp duyệt
    TrienKhaiPhatTrien --> KiemThu: Phát triển hoàn tất\nUnit test nội bộ đã qua\nKế hoạch kiểm thử và test cases sẵn sàng
    KiemThu --> SanSangRelease: UAT hoàn thành\nLỗi nghiêm trọng đã sửa hoặc chấp nhận\nGiải pháp đáp ứng yêu cầu
    SanSangRelease --> TrienKhaiChinhThuc: Nghiệp vụ phê duyệt Go-Live\nĐào tạo, tài liệu, hạ tầng sẵn sàng
    TrienKhaiChinhThuc --> VanHanh: Production đã triển khai\nNgười dùng truy cập được\nKiểm tra sau triển khai hoàn tất
    VanHanh --> KetThucSuDung: Giải pháp ngừng hoạt động
    KetThucSuDung --> [*]
    VanHanh --> KhamPha: Cần nâng cấp hoặc cải tiến lớn

Applied

Nova Foods (mô phỏng) cần hệ thống quản lý giao hàng mới. Delivery Pack cho "Hệ thống Quản lý Giao hàng Nova Foods" phát triển qua từng giai đoạn:

• Fact: Nova Foods muốn giảm thời gian giao hàng, tăng độ chính xác đơn hàng.
• Current Behavior: Quản lý giao hàng thủ công, dùng bảng tính Excel. Nhiều lỗi nhập liệu, khó theo dõi tài xế.
• Underlying Need: Tối ưu hóa quy trình giao hàng, hiển thị trạng thái đơn hàng thời gian thực, tự động hóa phân công tài xế.
• Options: Xây dựng mới, mua phần mềm ngoài, hoặc cải tiến Excel.
• Decision Criteria: Chi phí, thời gian, mức độ phù hợp nghiệp vụ.
• Decision: Xây dựng hệ thống mới (tên mã: NovaDeliverySystem).
• Authority: Business Owner (Chủ nghiệp vụ) Nova Foods.
• Artifact: /02-handbook/23-capstone-nova-foods-delivery-pack.md này.
• Consequence if Wrong: Chi phí phát triển lãng phí, giao hàng chậm, mất khách hàng, giảm uy tín thương hiệu Nova Foods.

Senior Lens

BA cấp cao không chỉ lập bản đồ giai đoạn, mà còn chủ động quản lý các "cửa". Cửa ra một giai đoạn là cửa vào của giai đoạn tiếp theo. BA đảm bảo Delivery Pack chứa đủ thông tin cần thiết, đúng định dạng, tại đúng thời điểm, cho các bên liên quan khác nhau. Cửa "duyệt" là điểm dừng, cần thẩm quyền cao. BA phải xác định ai có thẩm quyền, leo thang vấn đề (escalation points) khi có bế tắc. Nắm rõ quy trình này giúp BA ngăn chặn lãng phí tài nguyên, giảm rủi ro dự án. Việc này cũng đảm bảo tính truy xuất nguồn gốc (traceability) xuyên suốt vòng đời giải pháp.

Quick Reference

Giai đoạn vòng đời	Vai trò của Delivery Pack	Cửa vào	Cửa ra
Discovery (Khám phá)	Đặt nền tảng vấn đề, mục tiêu, phạm vi cấp cao.	Vấn đề/Cơ hội kinh doanh nhận diện	Đề xuất kinh doanh sơ bộ được duyệt
Analysis (Phân tích)	Tập hợp yêu cầu chi tiết, quy trình, thiết kế giải pháp.	Đề xuất kinh doanh sơ bộ duyệt, phạm vi cấp cao	Yêu cầu baseline, thiết kế giải pháp duyệt
Delivery (Triển khai)	Hướng dẫn phát triển giải pháp.	Thiết kế giải pháp duyệt, yêu cầu baseline	Phát triển code hoàn tất, unit test qua
Testing (Kiểm thử)	Cơ sở kiểm thử (test basis) cho QA, UAT.	Phát triển code hoàn tất, test plan/cases sẵn sàng	UAT đạt, lỗi nghiêm trọng xử lý, duyệt Go-Live
Release (Triển khai)	Hỗ trợ triển khai, đào tạo, onboarding người dùng.	Duyệt Go-Live, điều kiện tiên quyết sẵn sàng	Triển khai production, post-deployment checks hoàn tất
Operations (Vận hành)	Tài liệu tham chiếu cho hỗ trợ, bảo trì, nâng cấp.	Giải pháp hoạt động trên production	Giải pháp ngừng sử dụng hoặc bắt đầu chu trình mới

Chủ sở hữu, Bàn giao và Thẩm quyền khái niệm Delivery Pack

Core

Delivery Pack (Gói Bàn giao) là tập hợp artifact cần để triển khai, vận hành, và bảo trì một tính năng hay phiên bản phần mềm. Hiểu rõ chủ sở hữu, điểm bàn giao, giới hạn thẩm quyền, và điểm leo thang giúp quy trình rõ ràng, tránh mâu thuẫn.

Vai trò	Trách nhiệm chính (với khái niệm Delivery Pack)	Giới hạn thẩm quyền	Điểm leo thang (khi vượt giới hạn thẩm quyền)
Principal IT Business Analyst / Technical Curriculum Author (Người viết giáo trình)	Định nghĩa cấu trúc chuẩn, thành phần Delivery Pack (mô phỏng Nova Foods). Hướng dẫn BA sử dụng.	Không phê duyệt triển khai sản phẩm Nova Foods thực tế. Không quyết định nội dung nghiệp vụ Nova Foods.	Không áp dụng (quyết định trong phạm vi giáo trình).
Nova Foods BA Lead (Trưởng nhóm BA dự án mô phỏng)	Tùy chỉnh, áp dụng cấu trúc Delivery Pack vào dự án cụ thể. Đảm bảo BA dự án tạo artifact đúng.	Không phê duyệt các quyết định triển khai, kỹ thuật, pháp lý. Không thay đổi quy định tuân thủ.	Head of Business Analysis (Trưởng phòng BA mô phỏng).
Nova Foods Product Owner (Chủ sản phẩm mô phỏng)	Phê duyệt nội dung nghiệp vụ trong các artifact (User Story, Acceptance Criteria, Release Notes).	Không phê duyệt thiết kế kỹ thuật, kế hoạch kiểm thử, kế hoạch triển khai.	Project Steering Committee (Ban chỉ đạo dự án mô phỏng).
Nova Foods Solution Architect (Kiến trúc sư giải pháp mô phỏng)	Phê duyệt thiết kế kỹ thuật, cấu hình hệ thống trong Delivery Pack (ví dụ: NF-DS-ARCH_BLUEPRINT).	Không phê duyệt nghiệp vụ, kế hoạch kiểm thử, kế hoạch kinh doanh.	Architecture Review Board (Hội đồng kiến trúc mô phỏng).
Nova Foods QA Lead (Trưởng nhóm QA mô phỏng)	Phê duyệt Test Plan, Test Results, QA Sign-off trong Delivery Pack. Đảm bảo chất lượng.	Không phê duyệt nghiệp vụ, thiết kế kỹ thuật, kế hoạch triển khai.	Head of Quality Assurance (Trưởng phòng QA mô phỏng).
Nova Foods Release Manager (Quản lý triển khai mô phỏng)	Tập hợp, kiểm tra tính đầy đủ, nhất quán của Delivery Pack. Xác nhận sẵn sàng triển khai.	Không phê duyệt nội dung nghiệp vụ hoặc thiết kế kỹ thuật. Không đưa ra quyết định pháp lý.	Change Advisory Board (CAB) (Hội đồng tư vấn thay đổi mô phỏng).
Nova Foods Operations Lead (Trưởng nhóm Vận hành mô phỏng)	Phê duyệt Runbook, Deployment Guide trong Pack. Xác nhận khả năng vận hành, giám sát sau triển khai.	Không phê duyệt nghiệp vụ, kỹ thuật, QA.	Head of Operations (Trưởng phòng Vận hành mô phỏng).

Handoff (Bàn giao) trách nhiệm xảy ra khi artifact từ một vai trò được chuyển giao cho vai trò kế tiếp để xem xét, phê duyệt hoặc hành động. Ví dụ: BA bàn giao NF-RQ-USER_STORY cho Dev, Dev bàn giao NF-CD-SOURCE_CODE cho QA, QA bàn giao NF-TS-TEST_REPORT cho Release Manager. Mỗi bàn giao cần ghi nhận, có cơ chế kiểm tra (Review) và chấp nhận (Sign-off).

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

flowchart TD
    LEAD["BA Lead yêu cầu artifact đúng cấu trúc"] --> BA["BA tạo NF-RQ artifacts"]
    LEAD --> DEV["Dev bàn giao NF-CD source code"]
    LEAD --> DS["NF-DS artifacts chờ phê duyệt"]
    LEAD --> TS["Test Plan và Test Results chờ phê duyệt"]
    LEAD --> RD["Runbook và Deployment Guide chờ phê duyệt"]
    LEAD --> RN["Release Notes chờ phê duyệt"]

    BA --> PO["Product Owner phê duyệt nội dung nghiệp vụ"]
    RN --> PO
    DS --> ARCH["Solution Architect phê duyệt thiết kế kỹ thuật và cấu hình"]
    TS --> QA["QA Lead phê duyệt Test Plan và Test Results"]
    QA --> QAS["QA Sign-off"]
    DEV --> DEVREV["QA review và chấp nhận bàn giao source code"]
    RD --> OPS["Operations Lead phê duyệt Runbook và Deployment Guide"]

    PO -->|"Review và Sign-off bàn giao"| PACK["Tập hợp Delivery Pack"]
    ARCH -->|"Review và Sign-off bàn giao"| PACK
    QAS -->|"Review và Sign-off bàn giao"| PACK
    DEVREV -->|"Chấp nhận bàn giao"| PACK
    OPS -->|"Review và Sign-off bàn giao"| PACK

    PACK --> RM["Release Manager kiểm tra tính đầy đủ và nhất quán"]
    RM --> CHECK{"Pack đầy đủ và nhất quán?"}
    CHECK -->|"Thiếu NF-RQ hoặc Release Notes"| BA
    CHECK -->|"Thiếu NF-CD"| DEV
    CHECK -->|"Thiếu NF-DS"| DS
    CHECK -->|"Thiếu NF-TS hoặc QA Sign-off"| TS
    CHECK -->|"Thiếu Runbook hoặc Deployment Guide"| RD
    CHECK -->|"Có"| READY["Release Manager xác nhận sẵn sàng triển khai"]
    READY -->|"Review và chấp nhận bàn giao"| OPERABLE["Operations Lead xác nhận khả năng vận hành"]

    LEAD -.->|"Vượt thẩm quyền"| HEADBA["Head of Business Analysis"]
    PO -.->|"Vượt thẩm quyền"| STEER["Project Steering Committee"]
    ARCH -.->|"Vượt thẩm quyền"| ARB["Architecture Review Board"]
    QA -.->|"Vượt thẩm quyền"| HQA["Head of Quality Assurance"]
    RM -.->|"Vượt thẩm quyền"| CAB["Change Advisory Board"]
    OPS -.->|"Vượt thẩm quyền"| HOPS["Head of Operations"]

ponytail: Mermaid diagram đơn giản hóa luồng phê duyệt và tạo artifact, add chi tiết các bước review, sign-off cụ thể trong mỗi hộp khi cần thiết.

Applied

Case study: Nova Foods cần triển khai bản cập nhật lớn cho chức năng "Quản lý tồn kho thông minh" (NF-FT-SMART_INVENTORY_V2). Delivery Pack cho bản cập nhật này phải rất đầy đủ.

• Facts (Thông tin): Chức năng NF-FT-SMART_INVENTORY_V2 ảnh hưởng đến chuỗi cung ứng, kế toán, và pháp lý (Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP về hóa đơn). Cần thay đổi DB schema, logic nghiệp vụ, API.
• Current Behavior (Thực trạng): Delivery Pack trước đây thiếu sự phối hợp giữa Legal, Accounting, IT Operations. Dẫn đến một lần triển khai phải rollback vì vi phạm quy định về lưu trữ chứng từ.
• Underlying Need (Nhu cầu cốt lõi): Delivery Pack cho NF-FT-SMART_INVENTORY_V2 phải có sự phê duyệt rõ ràng từ các bên liên quan pháp lý, kế toán, vận hành, đảm bảo tuân thủ. Giảm rủi ro rollback.
• Options (Các lựa chọn):
  1. Tiếp tục quy trình cũ, hy vọng không sai.
  2. BA Lead định nghĩa các role phê duyệt mới trong cấu trúc Delivery Pack, thêm check-list.
  3. Tạo hệ thống workflow tự động hóa việc thu thập sign-off.
• Decision Criteria (Tiêu chí quyết định): Rủi ro pháp lý/kế toán, chi phí, thời gian triển khai, tính tuân thủ.
• Decision (Quyết định): Nova Foods BA Lead (mô phỏng) cập nhật cấu trúc Delivery Pack chuẩn. Thêm hai trường phê duyệt bắt buộc: NF-APPR-LEGAL_COMPLIANCE (phê duyệt tuân thủ pháp luật) và NF-APPR-ACCOUNTING_SIGN_OFF (phê duyệt kế toán). Role Legal Owner và Accounting Owner (mô phỏng) phải sign-off trước khi Delivery Pack được chuyển cho Release Manager.
• Authority (Thẩm quyền): Nova Foods BA Lead có thẩm quyền cập nhật cấu trúc Delivery Pack chung. Legal Owner và Accounting Owner có thẩm quyền phê duyệt nội dung pháp lý và kế toán.
• Artifact (Artifact liên quan):
  • /02-handbook/23-capstone-nova-foods-delivery-pack.md (tài liệu này)
  • 03-templates/NF-TP-DELIVERY_PACK_V1.md (template Delivery Pack, cập nhật thêm trường phê duyệt)
  • 01-curriculum/CANONICAL_BUSINESS_RULES.md (có thể cần thêm rule về ký duyệt)
• Consequence if Wrong (Hậu quả nếu sai): Hệ thống không tuân thủ quy định pháp luật (ví dụ Luật Kế toán), bị phạt, thông tin kế toán sai lệch, ảnh hưởng đến báo cáo tài chính của Nova Foods.

Senior Lens

Quy trình và vai trò rõ ràng giảm thiểu sự phỏng đoán và mâu thuẫn. Mỗi quyết định nghiệp vụ, kỹ thuật hay vận hành đều phải có chủ sở hữu duy nhất. Việc thiếu chủ sở hữu hoặc thẩm quyền chồng chéo là nguyên nhân chính gây trì hoãn và lỗi. Delivery Pack không chỉ là tập hợp tài liệu; nó là bằng chứng của quá trình xác nhận và phê duyệt. Thiếu định nghĩa về trách nhiệm gây ra khoảng trống (gap) hoặc trùng lặp (overlap), làm chậm dự án. Quy trình bàn giao rõ ràng, kèm theo sign-off (phê duyệt chính thức) là quan trọng.

Quick Reference

Vai trò	Handoff Input	Output to Handoff	Điểm Leo Thang Chính
Nova Foods BA Lead	Yêu cầu nghiệp vụ (NF-RQ-*)	Cấu trúc Delivery Pack dự án	Head of BA
Nova Foods Product Owner	Mục tiêu kinh doanh, NF-RQ-*	Chấp thuận nghiệp vụ các artifact Pack	Project Steering Committee
Nova Foods Solution Architect	Yêu cầu tính năng, NF-RQ-*	Thiết kế kỹ thuật (NF-DS-*) trong Pack	Architecture Review Board
Nova Foods Dev/QA Lead	Thiết kế kỹ thuật, Test Plan	Code (NF-CD-*), Test Report (NF-TS-*)	Head of Development / Head of QA
Nova Foods Release Manager	Các artifact đã phê duyệt từ Dev/QA/BA/Legal/Accounting	Delivery Pack hoàn chỉnh, NF-APPR-RELEASE	Change Advisory Board (CAB)
Nova Foods Operations Lead	Delivery Pack đã được RM phê duyệt	Báo cáo vận hành (NF-OP-MONITOR_REPORT)	Head of Operations
Nova Foods Legal/Accounting Owner	Yêu cầu tuân thủ (NF-LG-*, NF-AC-*)	Phê duyệt tuân thủ (NF-APPR-LEGAL_COMPLIANCE, NF-APPR-ACCOUNTING_SIGN_OFF)	Legal Director / CFO

ponytail: Bảng Quick Reference tổng hợp các điểm chính. Các artifact ID chỉ là ví dụ; cần tham chiếu chính xác từ TRACEABILITY_ID_REGISTRY khi áp dụng cho dự án thực. ponytail: Đây là kiến thức nền. Chi tiết từng loại artifact và template sẽ có ở các section sau.

Sơ đồ Vòng đời "Delivery Pack" trong Nova Foods ERP

graph TD
    subgraph 01. Discovery (Khám phá)
        A[Vấn đề nghiệp vụ Nova Foods] --> B(Đề xuất ý tưởng "Delivery Pack");
        B -- Handoff: Business Owner phê duyệt --> C{Concept "Delivery Pack" được chấp nhận?};
        C -- Có --> D[Phạm vi ban đầu "Delivery Pack"];
        C -- Không --> A;
        D --> E((Entry Gate: Ý tưởng đã xác nhận));
    end

    subgraph 02. Analysis (Phân tích)
        E --> F[BA: Thu thập yêu cầu chi tiết cho "Delivery Pack"];
        F --> G(BA: Phân tích quy trình, tạo mô hình chức năng);
        G -- Handoff: SME, Product Owner --> H{Yêu cầu "Delivery Pack" được phê duyệt?};
        H -- Có --> I[Tài liệu Yêu cầu (SRD) "Delivery Pack"];
        H -- Không --> F;
        I --> J((Entry Gate: Yêu cầu đã phê duyệt));
    end

    subgraph 03. Delivery (Phát triển)
        J --> K[Dev Team: Thiết kế kỹ thuật "Delivery Pack"];
        K --> L(Dev Team: Xây dựng tính năng "Delivery Pack");
        L -- Handoff: Dev Lead, QA Lead --> M{Mã đã sẵn sàng kiểm thử?};
        M -- Có --> N[Mã nguồn, môi trường Test "Delivery Pack"];
        M -- Không --> K;
        N --> O((Entry Gate: Mã đã sẵn sàng kiểm thử));
    end

    subgraph 04. Testing (Kiểm thử)
        O --> P[QA Team: Xây dựng kịch bản kiểm thử "Delivery Pack"];
        P --> Q(QA Team: Thực hiện kiểm thử chức năng, hiệu năng, bảo mật);
        Q -- Handoff: BA, Product Owner --> R{Tính năng "Delivery Pack" đạt kiểm thử?};
        R -- Có --> S[Kết quả kiểm thử Pass, báo cáo lỗi"];
        R -- Không --> K; %% Loop back to Delivery for bug fix
        S --> T((Entry Gate: Kết quả kiểm thử chấp nhận));
    end

    subgraph 05. Release (Triển khai)
        T --> U[DevOps/Release Mgr: Lập kế hoạch triển khai "Delivery Pack"];
        U --> V(DevOps/Release Mgr: Triển khai lên Production Nova Foods);
        V -- Handoff: Ops Lead --> W{Triển khai "Delivery Pack" thành công?};
        W -- Có --> X[Tính năng "Delivery Pack" hoạt động trực tiếp];
        W -- Không --> U; %% Rollback or retry
        X --> Y((Entry Gate: Triển khai thành công));
    end

    subgraph 06. Operations (Vận hành)
        Y --> Z[Ops Team: Giám sát, hỗ trợ người dùng "Delivery Pack"];
        Z --> AA(Support Team: Thu thập phản hồi, báo cáo sự cố);
        AA -- Handoff: BA Lead --> BB{Cần cải tiến hoặc sửa lỗi lớn?};
        BB -- Có --> F; %% Loop back to Analysis for new requirements/improvements
        BB -- Không --> CC[Vận hành "Delivery Pack" ổn định];
    end

Core

Sơ đồ trình bày chuỗi các giai đoạn cốt lõi của vòng đời phát triển tính năng "Delivery Pack" trong môi trường ERP mô phỏng của Nova Foods. Mỗi giai đoạn có mục tiêu, hoạt động chính, chủ sở hữu rõ ràng và các "Entry Gate" (Cổng vào) xác định, đảm bảo tính tuần tự và trách nhiệm giải trình. Các "Handoff" thể hiện điểm chuyển giao công việc và trách nhiệm giữa các vai trò.

Applied

Tính năng "Delivery Pack" tại Nova Foods (mô phỏng) sẽ trải qua các bước trong sơ đồ này. Discovery khởi đầu từ nhu cầu quản lý lô hàng đông lạnh. Analysis định hình các yêu cầu chức năng, phi chức năng cho việc đóng gói và xuất kho. Delivery thực hiện phát triển module trong ERP. Testing kiểm tra tính chính xác của việc ghi nhận thông tin, in tem nhãn theo tiêu chuẩn an toàn thực phẩm. Release triển khai module vào hệ thống ERP chính thức. Operations bao gồm giám sát, hỗ trợ người dùng và thu thập phản hồi để cải tiến.

Senior Lens

Từ góc nhìn của BA cấp cao, sơ đồ này là một cơ chế kiểm soát rủi ro và quản trị thay đổi. Mỗi "Entry Gate" đại diện cho một điểm quyết định quan trọng, nơi các bên liên quan phê duyệt và chuyển giao quyền sở hữu. Các vòng lặp (loop back) từ Testing về Delivery hoặc từ Operations về Analysis thể hiện tính lặp lại của phát triển, nhấn mạnh tầm quan trọng của phản hồi sớm và liên tục. BA cần đảm bảo tính khả năng truy vết (traceability) giữa các giai đoạn và xác định rõ thẩm quyền quyết định tại mỗi cổng.

Quick Reference

• 6 Giai đoạn chính: Khám phá (Discovery), Phân tích (Analysis), Phát triển (Delivery), Kiểm thử (Testing), Triển khai (Release), Vận hành (Operations).
• Entry Gate (Cổng vào): Điểm kiểm soát chính trước chuyển giao sang giai đoạn tiếp theo.
• Handoffs: Chỉ định trách nhiệm chuyển giao công việc giữa các vai trò/đội.
• Vòng lặp (Loops): Cơ chế xử lý lỗi/cải tiến, cho phép quay lại giai đoạn trước.
• Mục tiêu: Đảm bảo tính năng "Delivery Pack" được phát triển có kiểm soát, đáp ứng yêu cầu và hoạt động ổn định trong ERP của Nova Foods.

4. Input cần thiết

Core

Input là nguyên liệu BA dùng. BA biến nguyên liệu này thành yêu cầu, giải pháp. Input cần đúng, đủ, rõ. "Kiến thức nền tảng" (Prerequisite Knowledge) là hiểu biết BA cần trước. "Bằng chứng" (Evidence) là dữ liệu, quan sát thu thập. "Artifact nguồn" (Source Artifacts) là tài liệu gốc, có định danh rõ. "ID định danh" (Canonical IDs) là mã duy nhất cho artifact, giúp truy vết (traceability). BA không giả định kiến thức phần mềm. Mọi thứ phải rõ từ đầu.

Input Nova Foods "Delivery Pack" cần:

1. Kiến thức nền tảng BA:

ID	Loại kiến thức	Diễn giải	Nguồn tham khảo
BA-GEN-001	Nguyên tắc BA	Khái niệm cốt lõi, Kỹ thuật thu thập, phân tích yêu cầu.	BABOK Guide
BA-GEN-002	Vòng đời phát triển	Hiểu giai đoạn phát triển phần mềm, vai trò BA.	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md
BA-GEN-003	Mô hình hóa	Kỹ thuật biểu diễn quy trình, dữ liệu (UML, BPMN).	UML 2.5.1, BPMN 2.0.2

2. Kiến thức nền tảng nghiệp vụ (Nova Foods mô phỏng):

ID	Loại kiến thức	Diễn giải	Nguồn tham khảo
NF-DOM-FOOD-001	Ngành thực phẩm đông lạnh	Quy trình bảo quản, đóng gói, vận chuyển đặc thù.	Nova Foods Business Owner
NF-DOM-LOG-001	Nghiệp vụ Logistics	Quy trình xuất kho, giao hàng, quản lý đội xe (Nova Foods).	Nova Foods Logistics Department
NF-DOM-ACC-001	Nghiệp vụ Kế toán	Quy định về hóa đơn, chứng từ, công nợ liên quan giao hàng.	Nova Foods Accounting Department

3. Artifact nguồn & Bằng chứng (Nova Foods mô phỏng):

ID định danh (Canonical ID)	Tên artifact/bằng chứng	Mô tả	Nguồn gốc	Trạng thái xác minh
NF-BP-DELIVERY-001	Quy trình đóng gói & xuất kho hiện tại	Sơ đồ quy trình, mô tả chi tiết bước đóng gói, tạo phiếu xuất kho thủ công (Nova Foods).	Nova Foods Operations Manager	IN_REVIEW
NF-REG-FOODSAFE-001	Yêu cầu an toàn thực phẩm hàng đông lạnh	Các điều khoản liên quan ghi nhãn, nhiệt độ, truy xuất nguồn gốc.	Luật An toàn thực phẩm 55/2010/QH12	VERIFIED 2026-08-07
NF-REG-INVOICE-001	Quy định Hóa đơn, chứng từ	Yêu cầu pháp lý về nội dung, định dạng hóa đơn, phiếu giao hàng.	Nghị định 123/2020/NĐ-CP	VERIFIED 2026-08-07
NF-DD-PRODUCT-001	Từ điển dữ liệu sản phẩm	Định nghĩa các thuộc tính sản phẩm: mã, tên, đơn vị, trạng thái đông lạnh.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md (chờ hoàn thiện)	IN_REVIEW
NF-DD-ORDER-001	Từ điển dữ liệu đơn hàng	Định nghĩa cấu trúc đơn hàng: khách hàng, sản phẩm, số lượng, ngày giao.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md (chờ hoàn thiện)	IN_REVIEW
NF-SR-LEGACY-001	Tài liệu hệ thống ERP cũ (module tồn kho)	Mô tả các chức năng hiện có của hệ thống ERP Nova Foods liên quan kho.	Nova Foods IT Department	IN_REVIEW
00_SOURCE_MAP	Sơ đồ nguồn chung	Danh sách các nguồn tài liệu BA được phép tham khảo.	/00-research/00_SOURCE_MAP.md	IN_REVIEW
TRACEABILITY_ID_REGISTRY	Registry ID truy vết	Quy tắc tạo, quản lý ID định danh.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	IN_REVIEW

Applied

Facts: Nova Foods, công ty mô phỏng, bán thực phẩm đông lạnh. Cần quy trình đóng gói, giao hàng chặt chẽ. Current Behavior: Nhân viên kho in phiếu xuất, đóng gói thủ công. Ghi nhận chậm, dễ sai, khó truy vết. Underlying Need: Tự động hóa quá trình tạo phiếu giao hàng, phiếu đóng gói trong ERP. Đảm bảo đúng quy định, giảm sai sót, tăng hiệu suất, truy vết dễ. Options: 1. Giữ nguyên quy trình thủ công: Rủi ro cao, không nâng cấp được. 2. Phát triển công cụ bảng tính (Excel): Nhanh nhưng không tích hợp, không mở rộng được. 3. Phát triển module "Delivery Pack" trong ERP: Tích hợp tốt, mở rộng, tuân thủ. Decision Criteria: Chi phí, thời gian, rủi ro tuân thủ pháp luật, khả năng tích hợp, khả năng mở rộng. Decision: Phát triển module "Delivery Pack" trong ERP. Tối ưu lâu dài. Authority: Quản lý Vận hành Nova Foods (Operations Manager), Giám đốc IT Nova Foods (IT Director). Artifact: Tài liệu Yêu cầu Chức năng (Functional Requirement Specification - FRS) cho module Delivery Pack. Consequence if Wrong: Phạt hành chính do không tuân thủ luật (ATTP, hóa đơn), mất khách hàng, hàng hư hỏng do giao sai.

Senior Lens

Input không chỉ là tài liệu. Input là nền tảng. Input yếu, toàn bộ dự án rủi ro. BA cấp cao kiểm tra độ tin cậy nguồn, độ đầy đủ thông tin. Không chỉ hỏi "có tài liệu không?" mà "tài liệu này có đúng không, ai phê duyệt, cập nhật lần cuối khi nào, nó có mâu thuẫn với nguồn khác không?". Phải tìm ra "chủ sở hữu" (Owner) thực sự của mỗi input, người có thẩm quyền quyết định. Sự mâu thuẫn giữa các input (ví dụ: quy trình cũ và quy định mới) cần được giải quyết trước khi BA bắt đầu phân tích sâu. Không giải quyết, kết quả là "rác vào, rác ra" (Garbage In, Garbage Out - GIGO).

Quick Reference

• Input: Nguyên liệu thô BA dùng.
• Kiến thức nền tảng: Hiểu biết BA và nghiệp vụ cần có.
• Artifact nguồn: Tài liệu gốc, có ID rõ ràng.
• ID định danh (Canonical ID): Mã duy nhất, giúp truy vết (traceability).
• Chủ sở hữu (Owner): Người có thẩm quyền phê duyệt input.
• Mục tiêu: Input đúng, đủ, rõ, có thể truy vết.

Kiểm soát chất lượng & Nguồn đầu vào

### Core

Kiểm tra chất lượng đầu vào (Input Quality Checks): Quá trình xác minh input đúng, đủ, phù hợp. Input xấu tạo yêu cầu sai. Ví dụ: Định dạng (format), phạm vi giá trị (range), tính toàn vẹn tham chiếu (referential integrity), tính duy nhất (uniqueness), nhất quán (consistency). Bằng chứng: BABOK Guide (Chất lượng yêu cầu, chất lượng giải pháp), ISO/IEC/IEEE 29148 (Thông tin yêu cầu).

Phân loại nguồn (Source Classifications): Đánh giá độ tin cậy, thẩm quyền nguồn. Biết nguồn nào ưu tiên. * Canonical (Canonical Source): Nguồn chính thức, thẩm quyền cao nhất. Ví dụ: Luật 91/2025/QH15 (Luật Bảo vệ dữ liệu cá nhân), Nghị định 123/2020/NĐ-CP (Hóa đơn, chứng từ), Quy định Nova Foods đã phê duyệt. * Primary (Primary Source): Thông tin trực tiếp từ chủ quy trình, dữ liệu. Ví dụ: Phỏng vấn Subject Matter Expert (SME), quan sát nghiệp vụ. * Secondary (Secondary Source): Phân tích, diễn giải từ nguồn primary. Ví dụ: Báo cáo, tài liệu thiết kế cũ, hướng dẫn sử dụng. * Assumption (Giả định): Chưa xác minh. Cần kiểm chứng. Bằng chứng: BABOK Guide (Quản lý Thông tin BA), ISO/IEC/IEEE 29148.

Độ tươi mới (Freshness): Mức độ cập nhật thông tin. Thông tin cũ gây giải pháp lỗi thời. Yếu tố: Ngày ban hành, ngày sửa đổi, tính thời vụ, chu kỳ kinh doanh Nova Foods.

Chủ sở hữu (Ownership): Vai trò, cá nhân chịu trách nhiệm duy trì, phê duyệt nguồn. Biết người quyết định, người cần tham vấn. Ví dụ: Legal Owner, Business Owner, Data Owner, System Owner Nova Foods.

Điều kiện dừng (Stop Conditions): Khi nào ngừng thu thập, phân tích input. Tránh lãng phí. Tiêu chí: Đạt độ bao phủ yêu cầu, chất lượng input đủ, không mâu thuẫn lớn, đồng thuận chính từ bên liên quan Nova Foods.

### Applied

• Facts (Sự kiện): Nova Foods cần định nghĩa input cho quy trình "Xử lý Đơn hàng Giao hàng Nhanh". Input dự kiến: DOC-PRC-001 "Quy trình Xử lý Đơn Hàng" v2.1, RPT-SLS-005 "Báo cáo bán hàng tháng 07/2026".
• Current Behavior (Hành vi hiện tại): BA lấy DOC-PRC-001, đọc RPT-SLS-005. Không kiểm tra owner, ngày duyệt, tính pháp lý.
• Underlying Need (Nhu cầu cốt lõi): Input quy trình Giao hàng Nhanh chính xác, cập nhật. Tránh xây giải pháp trên thông tin sai.
• Options (Các lựa chọn):
  1. Dùng tài liệu trực tiếp. Rủi ro cao, có thể lỗi thời, sai.
  2. Kiểm tra ngày tài liệu. Chưa đủ thẩm quyền xác nhận.
  3. Áp dụng quy trình kiểm tra chất lượng input chặt chẽ: Phân loại nguồn, xác định owner, kiểm tra độ tươi mới.
• Decision Criteria (Tiêu chí quyết định): Tối thiểu hóa rủi ro sai sót nghiệp vụ, tối ưu hóa thời gian BA, đảm bảo tuân thủ (Luật Kế toán, Nghị định 123/2020/NĐ-CP về hóa đơn).
• Decision (Quyết định): Chọn Option 3. Áp dụng kiểm soát chất lượng input.
• Authority (Thẩm quyền): Business Owner (phê duyệt quy trình), Legal Owner (xác nhận tính hợp pháp), Data Owner (xác nhận dữ liệu báo cáo).
• Artifact (Sản phẩm): Bảng kiểm tra Input Nova Foods, ghi nhận owner, độ tươi mới, phân loại nguồn.
• Consequence if Wrong (Hậu quả nếu sai): Giao hàng sai địa chỉ, sai số lượng. Lỗi thanh toán, vi phạm pháp luật về hóa đơn điện tử.

### Senior Lens

Không mọi input cần độ chính xác như nhau. Tập trung kiểm tra input rủi ro cao, ảnh hưởng lớn đến nghiệp vụ Nova Foods. Input xấu gây lãng phí, rework. Đầu tư kiểm soát input là đầu tư chất lượng yêu cầu. Quy trình kiểm soát input là phần quản lý phạm vi, quản lý rủi ro BA.

### Quick Reference

Tiêu chí kiểm soát Input	Mô tả	Mức độ ưu tiên Nova Foods
Phân loại nguồn	Canonical, Primary, Secondary, Assumption	Cao
Chủ sở hữu	Ai duy trì, phê duyệt nguồn	Cao
Độ tươi mới	Ngày ban hành, cập nhật cuối	Trung bình - Cao
Tính nhất quán	Không mâu thuẫn nội bộ, ngoại bộ	Cao
Tính đầy đủ	Có đủ thông tin phục vụ yêu cầu không	Cao
Định dạng chuẩn	Tuân thủ cấu trúc, kiểu dữ liệu	Trung bình

Bảng Tổng Hợp Đầu Vào Cần Thiết cho Capstone Nova Foods

Đầu vào (Input) là thông tin, tài liệu, dữ liệu hoặc kiến thức cần thiết để một Business Analyst (BA) thực hiện các hoạt động phân tích, thiết kế, hoặc đưa ra khuyến nghị. Đầu vào giúp BA hiểu bối cảnh, vấn đề nghiệp vụ và các yêu cầu hiện có. Chất lượng đầu vào quyết định chất lượng đầu ra của BA.

Core

Để Capstone Nova Foods Delivery Pack đạt chất lượng, các đầu vào cần được phân loại và kiểm tra. Các loại đầu vào bao gồm: * Tài liệu (Documents): Hợp đồng, quy định, chính sách, đặc tả hệ thống hiện tại, báo cáo. * Dữ liệu (Data): Dữ liệu giao dịch lịch sử, dữ liệu Master Data, báo cáo phân tích. * Thông tin từ Stakeholders: Phỏng vấn, khảo sát, quan sát quy trình nghiệp vụ. * Kiến thức miền (Domain Knowledge): Kiến thức về ngành, thị trường, đối thủ cạnh tranh.

Để đảm bảo chất lượng đầu vào, BA cần kiểm tra các yếu tố: * Tính đầy đủ (Completeness): Thông tin có đủ để tiến hành công việc không? * Tính chính xác (Accuracy): Thông tin có đúng sự thật, đúng số liệu không? * Tính nhất quán (Consistency): Thông tin có mâu thuẫn với các nguồn khác không? * Tính kịp thời (Currency/Freshness): Thông tin có còn hiệu lực, cập nhật không? * Nguồn gốc (Source/Ownership): Ai là người cung cấp, ai chịu trách nhiệm về thông tin này?

Bảng 1: Các Loại Đầu Vào Chung và Phân Loại Nguồn Tham Chiếu

ID Canonical	Đầu vào (Input)	Mô tả & Mục đích sử dụng	Phân loại nguồn (Source Classification)
SRC-GOV-001	00_SOURCE_MAP.md	Danh sách nguồn tham chiếu tổng thể, quản trị dự án.	Quản trị Dự án (Project Governance)
SRC-GOV-002	01_CURRICULUM_ARCHITECTURE.md	Kiến trúc tổng thể của chương trình đào tạo.	Quản trị Dự án (Project Governance)
SRC-GOV-003	CHAPTER_MANIFEST.md	Danh mục các chương của handbook.	Quản trị Dự án (Project Governance)
SRC-GOV-004	TEMPLATE_MANIFEST.md	Danh mục các template sử dụng trong dự án.	Quản trị Dự án (Project Governance)
SRC-IDR-001	TRACEABILITY_ID_REGISTRY.md	Quản lý định danh cho truy vết.	Quản trị ID (ID Governance)
SRC-BRC-001	CANONICAL_BUSINESS_RULES.md	Các quy tắc nghiệp vụ cốt lõi.	Nghiệp vụ (Business Rule)
SRC-DDC-001	CANONICAL_DATA_DICTIONARY.md	Từ điển dữ liệu logic.	Dữ liệu (Data Definition)
NOVA-DOC-001	Quy trình giao hàng hiện tại Nova Foods	Hiểu luồng nghiệp vụ hiện có của Nova Foods.	Tài liệu nội bộ (Internal Document)
NOVA-DATA-001	Dữ liệu tồn kho kho lạnh Nova Foods	Phân tích số liệu, mẫu hình tồn kho để lập kế hoạch.	Dữ liệu nghiệp vụ (Business Data)
NOVA-STK-001	Phỏng vấn Trưởng phòng Kho vận Nova Foods	Thu thập yêu cầu, vướng mắc từ người dùng thực tế.	Thông tin từ Stakeholder (Stakeholder Input)
REG-LAW-001	Luật An toàn thực phẩm 55/2010/QH12	Đảm bảo tuân thủ quy định pháp luật về an toàn thực phẩm.	Quy định pháp luật (Regulatory Standard)
REG-LAW-002	Nghị định 123/2020/NĐ-CP về hóa đơn	Quy định về chứng từ, hóa đơn điện tử cho hoạt động bán hàng.	Quy định pháp luật (Regulatory Standard)

Applied

Trong ngữ cảnh Capstone Nova Foods, các đầu vào cụ thể được sử dụng để xây dựng hệ thống ERP mô phỏng. Bảng sau liệt kê các đầu vào chính, kèm theo giá trị tổng hợp (synthetic value) và các mục cần xác minh chưa được giải quyết (unresolved verification items). Các mục xác minh này đại diện cho những công việc mà BA cần thực hiện để đảm bảo đầu vào đủ tin cậy trước khi sử dụng.

Bảng 2: Đầu Vào Cụ Thể của Nova Foods với Dữ Liệu Tổng Hợp và Mục Xác Minh (Chưa Giải Quyết)

ID Đầu Vào	Tên Đầu Vào	Mô tả ngắn gọn	Giá trị Tổng hợp (Synthetic Value)	Nguồn Gốc	Mức độ Tươi mới (Freshness)	Chủ sở hữu (Owner)	Mục Xác Minh (Chưa Giải Quyết)
NF-IN-DOC-001	Quy trình Đặt hàng Năng động Nova Foods	Quy trình xử lý đơn hàng từ khách hàng đến giao nhận, bao gồm các bước kiểm tra tín dụng và tồn kho.	[Tài liệu PDF] "Quy_trinh_DH_v3.2_20260715.pdf"	Phòng Kinh doanh Nova Foods	2026-07-15	Trưởng phòng Kinh doanh	Xác nhận: Áp dụng thực tế cho tất cả loại đơn hàng (bán buôn, bán lẻ)? Chi tiết đủ cho mã hóa hệ thống? Mâu thuẫn với Nghị định 123/2020/NĐ-CP về hóa đơn điện tử không?
NF-IN-DATA-001	Danh mục Sản phẩm Đông lạnh Nova Foods	Danh sách mã SKU, tên sản phẩm, đơn vị tính, giá vốn, giá bán đề xuất, trọng lượng, nhiệt độ bảo quản yêu cầu.	[Tệp CSV] "SP_DongLanh_v20260801.csv" (1500 dòng dữ liệu)	Phòng Sản xuất Nova Foods	2026-08-01	Quản lý Kho sản phẩm	Xác nhận: Độ chính xác giá vốn (liên kết hệ thống kế toán)? Mã SKU có duy nhất? Đủ thuộc tính cho vận chuyển, quản lý lô hàng không?
NF-IN-DATA-002	Lịch sử Giao hàng 6 tháng Nova Foods	Dữ liệu về các đơn hàng đã giao thành công/thất bại, thời gian giao hàng, địa điểm, phương tiện, chi phí vận chuyển.	[Cơ sở dữ liệu] ERPHistory_Delivery_2026Q1-Q2 (120,000 bản ghi)	Phòng Vận tải Nova Foods	2026-08-05	Giám đốc Vận tải	Xác nhận: Định dạng dữ liệu nhất quán? Tỷ lệ thất bại được ghi nhận đúng? Có bỏ sót dữ liệu do hệ thống cũ không?
NF-IN-RGL-001	Danh mục Quy định An toàn Thực phẩm Việt Nam	Các quy định về nhiệt độ bảo quản, điều kiện vận chuyển thực phẩm đông lạnh theo Luật An toàn thực phẩm 55/2010/QH12.	[Tham chiếu Luật] Luật 55/2010/QH12; Nghị định 15/2018/NĐ-CP.	Pháp chế Nova Foods	2026-01-01 (luật), 2018-02-02 (NĐ)	Trưởng phòng Pháp chế	Xác nhận: Có bổ sung/sửa đổi pháp luật gần đây? Phạm vi áp dụng cho từng loại sản phẩm cụ thể của Nova Foods? Có hướng dẫn thực thi từ Cục ATTP không?
NF-IN-STK-001	Phản hồi Khách hàng về Giao hàng Nova Foods	Tổng hợp các khiếu nại, góp ý từ khách hàng về chất lượng dịch vụ giao hàng (trễ, hỏng hóc, sai sót).	[Báo cáo tổng hợp] "Bao_cao_CSKH_GiaoHang_T7_2026.docx"	Phòng Chăm sóc Khách hàng Nova Foods	2026-08-01	Trưởng phòng CSKH	Xác nhận: Dữ liệu được phân loại theo mức độ nghiêm trọng? Có xu hướng lặp lại? Có liên kết với dữ liệu giao hàng (NF-IN-DATA-002) để phân tích nguyên nhân không?

Ví dụ Áp dụng Xác Minh Đầu Vào cho NF-IN-DOC-001: Quy trình Đặt hàng Năng động Nova Foods

• Facts: Tài liệu "Quy_trinh_DH_v3.2_20260715.pdf" mô tả luồng đặt hàng hiện tại của Nova Foods. Đây là bản PDF.
• Current Behavior: Quy trình này được Trưởng phòng Kinh doanh cung cấp và cho biết đang được áp dụng.
• Underlying Need: Đảm bảo quy trình được mã hóa trong hệ thống ERP mới phản ánh đúng nghiệp vụ đang diễn ra và tuân thủ các yêu cầu pháp lý (ví dụ: liên quan đến hóa đơn điện tử theo Nghị định 123/2020/NĐ-CP).
• Options:
  1. Chấp nhận tài liệu PDF như là nguồn chân lý duy nhất.
  2. Phỏng vấn Trưởng phòng Kinh doanh và các nhân viên thực hiện quy trình để đối chiếu nội dung tài liệu với thực tế.
  3. Thực hiện quan sát (shadowing) trực tiếp quy trình tại các chi nhánh hoặc bộ phận liên quan.
  4. Yêu cầu phòng Kế toán và Pháp chế review tài liệu để kiểm tra tính tuân thủ.
• Decision Criteria: Tính chính xác nghiệp vụ, tuân thủ pháp luật, độ đầy đủ chi tiết cho phát triển hệ thống.
• Decision: Chọn kết hợp các phương án 2, 3 và 4. Không thể chỉ chấp nhận tài liệu PDF mà không có xác minh.
• Authority: BA chịu trách nhiệm điều phối xác minh, với sự hỗ trợ từ Trưởng phòng Kinh doanh, Kế toán và Pháp chế để xác nhận nội dung.
• Artifact: Biên bản phỏng vấn, báo cáo quan sát quy trình, email xác nhận review từ Kế toán/Pháp chế.
• Consequence if Wrong: Hệ thống ERP mới triển khai có thể không phù hợp với thực tế vận hành, vi phạm pháp luật về hóa đơn điện tử, hoặc không xử lý được các trường hợp đặt hàng phức tạp, gây lãng phí nguồn lực và ảnh hưởng doanh thu của Nova Foods mô phỏng.

Senior Lens

Người BA cấp cao (Senior BA) không chỉ thu thập đầu vào mà còn quản lý và đánh giá chất lượng đầu vào một cách chiến lược. * Quản lý Nguồn Gốc và Quyền Sở hữu: Mỗi đầu vào phải có chủ sở hữu (Owner) rõ ràng để biết ai là người chịu trách nhiệm xác nhận hoặc cập nhật thông tin. Điều này tránh tình trạng thông tin không rõ ràng, không được duy trì. * Điều kiện Dừng (Stop Conditions): Nếu đầu vào không đủ chất lượng (ví dụ: không chính xác, lỗi thời, mâu thuẫn nghiêm trọng), BA phải tạm dừng công việc phụ thuộc vào đầu vào đó và yêu cầu xử lý từ chủ sở hữu. Điều này ngăn ngừa việc xây dựng giải pháp trên nền tảng thông tin sai lệch, giảm rủi ro làm lại (rework). * Traceability: Luôn liên kết đầu vào với các yêu cầu và giải pháp được tạo ra. Khi có thay đổi ở đầu vào, BA có thể dễ dàng xác định các phần bị ảnh hưởng của hệ thống và đánh giá tác động. * Thẩm định Pháp lý và Kế toán: Đối với các đầu vào liên quan đến pháp luật (Luật An toàn thực phẩm, Nghị định hóa đơn) hoặc tài chính (giá vốn, doanh thu), Senior BA phải đảm bảo có sự thẩm định và xác nhận từ các phòng ban chuyên trách (Pháp chế, Kế toán) thay vì tự diễn giải. Điều này rất quan trọng để đảm bảo Nova Foods mô phỏng tuân thủ và tránh các rủi ro pháp lý, tài chính.

Quick Reference

Checklist Đánh giá Đầu vào Nhanh: * Đầu vào có đủ thông tin (Completeness) không? * Thông tin có chính xác (Accuracy) không? * Có nhất quán (Consistency) với các nguồn khác không? * Thông tin có kịp thời (Currency/Freshness) và còn hiệu lực không? * Nguồn gốc (Source) có rõ ràng và đáng tin cậy không? * Ai là chủ sở hữu (Owner) chịu trách nhiệm về đầu vào này? * Có cần xác minh thêm không (tham khảo cột "Mục Xác Minh")? * Đã được thẩm định bởi chuyên gia (Pháp lý, Kế toán, Nghiệp vụ) khi cần chưa?

5. Step-by-step BA Activities

Applied

Nova Foods, mô phỏng doanh nghiệp thực phẩm, đang cải thiện quy trình vận hành. BA xử lý yêu cầu nghiệp vụ mới.

Facts: Nova Foods cần thu gom vỏ chai tái sử dụng từ khách hàng khi giao đơn mới. Hệ thống ERP (Enterprise Resource Planning) hiện tại không hỗ trợ nghiệp vụ này. Vỏ chai là tài sản có giá trị tái chế, ảnh hưởng tồn kho và môi trường.

Current Behavior: Nhân viên giao hàng ghi nhận thủ công số lượng vỏ chai thu về trên phiếu giao hàng giấy. Không có liên kết trực tiếp với hệ thống quản lý tồn kho ERP. Dẫn đến sai lệch số liệu, khó khăn kiểm soát vỏ chai, mất mát, không tối ưu hóa quy trình luân chuyển.

Underlying Need: Tích hợp quy trình thu gom vỏ chai vào hệ thống. Cần một quy trình rõ ràng, tự động hóa, đồng bộ dữ liệu. Mục đích: giảm thất thoát vỏ chai, tăng hiệu quả vận hành kho, đảm bảo tuân thủ các chính sách môi trường, cải thiện trải nghiệm khách hàng Nova Foods, và có dữ liệu chính xác cho báo cáo.

Options:

1. Tiếp tục Thủ công (Sổ tay/Excel): Cải thiện biểu mẫu ghi chép thủ công. Nhân viên nhập liệu riêng vào Excel sau đó.
2. Ứng dụng di động độc lập: Phát triển một ứng dụng di động riêng cho tài xế. Ứng dụng này không tích hợp trực tiếp với ERP.
3. Tích hợp vào ERP: Mở rộng module quản lý đơn hàng hiện có của ERP để xử lý nghiệp vụ thu gom vỏ chai.

Decision Criteria:

• Tính toàn vẹn dữ liệu: Mức độ đồng bộ với hệ thống dữ liệu cốt lõi của Nova Foods.
• Chi phí phát triển: Chi phí đầu tư ban đầu cho giải pháp.
• Thời gian triển khai: Thời gian từ khi bắt đầu đến khi đưa vào sử dụng.
• Khả năng mở rộng: Khả năng đáp ứng các yêu cầu nghiệp vụ phức tạp hơn trong tương lai.
• Hiệu quả vận hành: Mức độ giảm thiểu thao tác thủ công, sai sót.
• Tuân thủ quy định: Khả năng đáp ứng yêu cầu quản lý môi trường, tài sản.

Decision: Chọn Tích hợp vào ERP. Lý do: Đảm bảo tính toàn vẹn dữ liệu cao nhất, đồng bộ hóa quy trình nghiệp vụ giao hàng và thu gom, hỗ trợ khả năng mở rộng lâu dài. Chi phí ban đầu cao hơn nhưng giảm rủi ro vận hành, tối ưu hóa tổng thể.

Authority: Ban Điều hành Nova Foods, Giám đốc Vận hành, Giám đốc IT phê duyệt.

Artifact: Tài liệu Đặc tả Yêu cầu Phần mềm (Software Requirements Specification - SRS), Biểu đồ quy trình (Process Flow Diagram), User Stories, Tài liệu Thiết kế Giải pháp.

Consequence if Wrong:

• Nếu chọn Thủ công: Tiếp tục mất mát vỏ chai, dữ liệu không đáng tin cậy. Nova Foods không đạt mục tiêu bền vững môi trường.
• Nếu chọn Ứng dụng di động độc lập: Phát sinh silos dữ liệu, khó khăn tích hợp sau này. Chi phí bảo trì hai hệ thống độc lập. Phức tạp cho người dùng cuối.

---

Quy trình Hoạt động BA (Business Analyst Activities) chi tiết:

1. Chuẩn bị (Preparation)

   • Vai trò: BA (Business Analyst).
   • Hành động: Thu thập yêu cầu sơ bộ, xác định bối cảnh nghiệp vụ, các bên liên quan chính.
   • Đối tượng: Yêu cầu ban đầu từ người khởi tạo, thông tin về quy trình giao nhận hiện có, các quy định liên quan đến quản lý vỏ chai.
   • Bằng chứng tạo ra: Email yêu cầu, biên bản họp kick-off, danh sách các câu hỏi ban đầu.
   • Quy tắc quyết định: Yêu cầu có đủ thông tin để bắt đầu các hoạt động khơi gợi chi tiết.
   • Cửa kiểm soát chất lượng: Người khởi tạo yêu cầu (ví dụ: Giám đốc Vận hành Nova Foods) xác nhận phạm vi sơ bộ và mục tiêu chính.
   • Lộ trình leo thang: Nếu phạm vi không rõ ràng, mục tiêu mơ hồ; BA leo thang lên Product Owner (PO - Người đại diện cho tiếng nói khách hàng và nghiệp vụ) hoặc nhà tài trợ dự án để làm rõ.

2. Khơi gợi Yêu cầu (Elicitation)

   • Vai trò: BA, Chủ nghiệp vụ (Business Owner), Người dùng cuối (End-users - ví dụ: tài xế giao hàng, nhân viên kho Nova Foods).
   • Hành động: Thực hiện phỏng vấn, tổ chức workshop, quan sát quy trình thực tế.
   • Đối tượng: Nhu cầu kinh doanh, yêu cầu chức năng (Functional Requirements), yêu cầu phi chức năng (Non-functional Requirements), các ràng buộc và giả định liên quan đến quy trình thu gom vỏ chai.
   • Bằng chứng tạo ra: Ghi chú phỏng vấn, biên bản workshop, sơ đồ quy trình As-Is (hiện tại) và To-Be (mong muốn) nháp, danh sách các câu hỏi mở.
   • Quy tắc quyết định: Đã thu thập đủ yêu cầu để hiểu rõ nghiệp vụ và bắt đầu phân tích. Các yêu cầu không mâu thuẫn lẫn nhau ở cấp độ cao.
   • Cửa kiểm soát chất lượng: Chủ nghiệp vụ và người dùng cuối đồng ý với sơ đồ quy trình To-Be nháp và danh sách yêu cầu mức cao.
   • Lộ trình leo thang: Phát hiện mâu thuẫn lớn giữa các yêu cầu từ các bên liên quan khác nhau; BA leo thang lên PO hoặc Chủ nghiệp vụ để giải quyết.

3. Phân tích Yêu cầu (Analysis)

   • Vai trò: BA.
   • Hành động: Phân rã yêu cầu cấp cao thành các yêu cầu chi tiết, làm rõ các điều kiện nghiệp vụ, mô hình hóa quy trình, dữ liệu, tạo User Story (Mô tả ngắn gọn một tính năng từ góc độ người dùng).
   • Đối tượng: Các yêu cầu chi tiết, tiêu chí chấp nhận (Acceptance Criteria), biểu đồ quy trình (ví dụ: BPMN hoặc sơ đồ trạng thái), từ điển dữ liệu (Data Dictionary) cho các trường dữ liệu mới (ví dụ: mã vỏ chai, số lượng vỏ thu về).
   • Bằng chứng tạo ra: Tài liệu Đặc tả Yêu cầu Phần mềm (SRS - Software Requirements Specification) phiên bản nháp, User Stories, biểu đồ Mermaid hoặc PlantUML cho quy trình, dữ liệu.
   • Quy tắc quyết định: Yêu cầu rõ ràng, đầy đủ, nhất quán, có thể kiểm thử (testable). Không có sự mơ hồ.
   • Cửa kiểm soát chất lượng: BA tự kiểm tra chéo các yêu cầu, thực hiện Peer Review (đánh giá chéo bởi đồng nghiệp) với một BA khác hoặc Kiến trúc sư giải pháp.
   • Lộ trình leo thang: Phát hiện các lỗ hổng lớn trong tài liệu yêu cầu hoặc mâu thuẫn logic nội bộ; BA leo thang để đội dự án đánh giá lại.

4. Xác nhận Yêu cầu (Validation)

   • Vai trò: BA, Chủ nghiệp vụ, Trưởng nhóm QA (Quality Assurance - Đảm bảo chất lượng).
   • Hành động: Trình bày và review tài liệu yêu cầu chi tiết (SRS, User Stories) với các bên liên quan. Kiểm tra các kịch bản nghiệp vụ.
   • Đối tượng: Tài liệu SRS hoàn chỉnh, Tiêu chí chấp nhận cuối cùng.
   • Bằng chứng tạo ra: Biên bản review yêu cầu, email xác nhận phê duyệt từ Chủ nghiệp vụ, danh sách Test Case (Trường hợp kiểm thử) sơ bộ từ QA.
   • Quy tắc quyết định: Tất cả các yêu cầu được các bên liên quan chính thức chấp nhận. Tiêu chí chấp nhận rõ ràng và đủ để QA tạo Test Case.
   • Cửa kiểm soát chất lượng: Chủ nghiệp vụ ký/email đồng ý chính thức với SRS và các User Stories. QA xác nhận có thể tạo Test Case dựa trên tài liệu.
   • Lộ trình leo thang: Chủ nghiệp vụ từ chối yêu cầu hoặc yêu cầu thay đổi lớn; BA leo thang lên PO hoặc Ban Điều hành để đánh giá tác động và quyết định.

5. Quản lý Thay đổi (Change Management)

   • Vai trò: BA, Product Owner, Các bên liên quan (Stakeholders).
   • Hành động: Tiếp nhận, ghi nhận, đánh giá tác động (impact analysis) và xử lý các Yêu cầu Thay đổi (Change Request - CR) sau khi yêu cầu đã được xác nhận.
   • Đối tượng: Yêu cầu Thay đổi (CR), nhật ký thay đổi, phân tích tác động lên phạm vi, thời gian, chi phí dự án.
   • Bằng chứng tạo ra: Biểu mẫu CR đã điền, phân tích tác động, biên bản họp đánh giá CR.
   • Quy tắc quyết định: Thay đổi được đánh giá tác động đầy đủ và được phê duyệt bởi các vai trò có thẩm quyền.
   • Cửa kiểm soát chất lượng: PO hoặc Ban Điều hành phê duyệt CR, sau đó được ghi nhận và cập nhật vào Backlog sản phẩm.
   • Lộ trình leo thang: Yêu cầu thay đổi có tác động lớn đến ngân sách hoặc thời gian dự án, hoặc có mâu thuẫn giữa các bên; BA leo thang lên Ban chỉ đạo dự án.

6. Bàn giao có kiểm soát (Controlled Handoff)

   • Vai trò: BA, Đội Phát triển (Development Team), Đội QA.
   • Hành động: Trình bày, giải thích yêu cầu, chuyển giao toàn bộ tài liệu đã phê duyệt cho đội Phát triển và QA.
   • Đối tượng: Gói tài liệu yêu cầu đã phê duyệt (SRS, User Stories, biểu đồ quy trình), các buổi training/hướng dẫn.
   • Bằng chứng tạo ra: Biên bản họp bàn giao, xác nhận từ Lead Dev (Trưởng nhóm Phát triển) và QA Lead về việc đã nhận và hiểu rõ yêu cầu.
   • Quy tắc quyết định: Đội Phát triển và QA hiểu rõ các yêu cầu, không còn câu hỏi lớn hoặc điểm chưa rõ nào cản trở việc bắt đầu công việc.
   • Cửa kiểm soát chất lượng: Lead Dev và QA Lead xác nhận bằng văn bản (email/hệ thống quản lý dự án) rằng họ đã nhận đủ tài liệu và sẵn sàng bắt đầu.
   • Lộ trình leo thang: Đội Phát triển hoặc QA không thể hiểu rõ yêu cầu sau bàn giao, cần làm rõ liên tục; BA leo thang lên PO để làm rõ lại yêu cầu.

---

Ví dụ thực thi quy trình BA tại Nova Foods (mô phỏng) - Yêu cầu thu gom vỏ chai:

Bước BA	Mô tả Nova Foods	Bằng chứng tạo ra	Quyết định/Kết quả
1. Chuẩn bị	Yêu cầu cải thiện quy trình thu gom vỏ chai phát sinh từ báo cáo môi trường Nova Foods và phản hồi khách hàng về khó khăn khi trả vỏ.	Email từ Giám đốc Vận hành (2026-08-08), Biên bản họp kick-off (HKO-NF-2026-001).	Yêu cầu được chấp nhận sơ bộ, BA bắt đầu thu thập thông tin.
2. Khơi gợi Yêu cầu	Phỏng vấn Tổ trưởng Giao nhận, 2 tài xế chính Nova Foods, và quản lý Kho Vỏ chai. Tổ chức workshop 1 buổi với đại diện 3 phòng ban.	Biên bản phỏng vấn (NF-INT-2026-001), Ghi chú workshop (NF-WOR-2026-001), sơ đồ quy trình As-Is (NF-PROC-ASIS-2026-001).	Xác định các bước chính trong quy trình hiện tại, các điểm đau và yêu cầu của người dùng.
3. Phân tích Yêu cầu	Phân tích yêu cầu, tạo sơ đồ quy trình To-Be, danh sách 12 User Story cho module ERP di động Nova Foods.	Tài liệu đặc tả yêu cầu (NF-SRS-2026-001-v0.1), 12 User Stories (NF-US-2026-001 đến NF-US-2026-012), Biểu đồ Mermaid quy trình To-Be.	Yêu cầu được cấu trúc rõ ràng, sẵn sàng để review và xác nhận.
4. Xác nhận Yêu cầu	Gửi NF-SRS-2026-001-v0.1 cho Giám đốc Vận hành và Trưởng phòng QA Nova Foods. Tổ chức buổi review chuyên sâu.	Email phê duyệt NF-SRS-2026-001-v0.1 từ Giám đốc Vận hành (2026-08-20), Biên bản QA review (NF-QA-REV-2026-001).	Yêu cầu được các bên liên quan chấp thuận, QA có thể bắt đầu lập kế hoạch kiểm thử.
5. Quản lý Thay đổi	Phát sinh CR (Change Request - Yêu cầu thay đổi): Khách hàng Nova Foods muốn có mã QR để tự khai báo số lượng vỏ trả trước.	Biểu mẫu CR (NF-CR-2026-001), Đánh giá tác động (NF-IMP-ASS-2026-001).	Yêu cầu được đánh giá là phát sinh lớn, cần ưu tiên lại trong backlog sản phẩm.
6. Bàn giao có kiểm soát	BA trình bày NF-SRS-2026-001-v0.1 và các User Stories cho đội Phát triển và QA Nova Foods.	Biên bản họp bàn giao (NF-HDO-2026-001), xác nhận của Lead Dev và QA Lead qua email.	Đội Phát triển và QA nắm rõ yêu cầu, sẵn sàng bắt đầu xây dựng và kiểm thử.

---

Biểu đồ quy trình thu gom vỏ chai Nova Foods (mô phỏng):

Mô tả Chi tiết Các Thành phần Của Mỗi Bước Hoạt động BA

Để mỗi hoạt động (activity) của BA có thể được thực thi nhất quán, đánh giá chất lượng và kiểm soát hiệu quả, cần xác định rõ các thành phần cơ bản. Việc này đảm bảo tính minh bạch, khả năng lặp lại và dễ dàng truy vết (traceability) trong toàn bộ vòng đời dự án. Đây là khuôn khổ để mô tả từng bước trong quy trình BA.

Thành phần	Mô tả (Diễn giải tiếng Việt)	Mục đích	Ví dụ Mô phỏng (Nova Foods)
Tác nhân (Actor)	Cá nhân hoặc vai trò chịu trách nhiệm chính thực hiện hoạt động này. Một hoạt động có thể có tác nhân chính và các tác nhân hỗ trợ.	Xác định rõ người chịu trách nhiệm, phân quyền và đảm bảo trách nhiệm giải trình.	BA Chính (Lead BA), BA Chuyên biệt (Domain BA), Chủ doanh nghiệp (Business Owner)
Hành động (Action)	Động từ mô tả công việc cụ thể được thực hiện trong bước này. Cần ngắn gọn, rõ ràng và có thể đo lường được.	Mô tả công việc cần làm, đặt nền tảng cho việc lập kế hoạch và ước tính.	"Thu thập yêu cầu", "Phân tích dữ liệu", "Phác thảo quy trình", "Kiểm tra tính nhất quán"
Đối tượng (Object)	Thực thể hoặc thông tin mà hành động tác động lên. Đây là đầu vào hoặc trung gian của hoạt động.	Xác định phạm vi công việc, nguồn thông tin cần thiết và sản phẩm trung gian.	Yêu cầu nghiệp vụ (Business Requirements), Dữ liệu bán hàng (Sales Data), Quy trình hiện hành (As-Is Process), Phản hồi của người dùng (User Feedback)
Bằng chứng tạo ra (Evidence Produced)	Sản phẩm đầu ra hữu hình và có thể xác minh được sau khi hoàn thành hoạt động. Đây là minh chứng cho việc công việc đã được thực hiện.	Xác nhận hoàn thành công việc, làm cơ sở cho các hoạt động tiếp theo, phục vụ mục đích kiểm toán (audit trail).	Tài liệu đặc tả yêu cầu (Requirement Specification Document - SRS), Mô hình quy trình BPMN, Biên bản cuộc họp (Meeting Minutes), Bảng tổng hợp các vấn đề (Issue Log)
Quy tắc quyết định (Decision Rule)	Tập hợp các tiêu chí hoặc nguyên tắc định hướng cho việc đưa ra các lựa chọn hoặc phán đoán trong quá trình thực hiện hoạt động. Quy tắc này giúp chuẩn hóa việc ra quyết định.	Đảm bảo tính khách quan, nhất quán, giảm thiểu sai sót và đẩy nhanh quá trình ra quyết định.	"Chỉ ưu tiên tính năng (feature) có giá trị nghiệp vụ cao (High Business Value) và tính khả thi kỹ thuật trung bình trở lên (Medium-High Technical Feasibility)", "Mọi thay đổi yêu cầu phải được phê duyệt bởi Business Owner và có tác động ước tính < 5 ngày công (man-days)".
Cổng chất lượng (Quality Gate)	Các điểm kiểm tra bắt buộc (mandatory checkpoint) để đánh giá chất lượng của bằng chứng tạo ra trước khi chuyển sang bước tiếp theo. Nếu bằng chứng không đạt tiêu chuẩn, hoạt động phải được lặp lại hoặc điều chỉnh.	Đảm bảo chất lượng đầu ra, phát hiện sớm sai sót, ngăn ngừa lỗi lan truyền và giảm thiểu rủi ro dự án.	"SRS phải được BA cấp cao (Senior BA) đánh giá và phê duyệt (sign-off)", "Mô hình dữ liệu phải tuân thủ chuẩn đặt tên Nova Foods và được kiến trúc sư dữ liệu (Data Architect) xác nhận", "Tất cả các trường hợp sử dụng (use cases) phải có tiêu chí chấp nhận (acceptance criteria) rõ ràng và kiểm thử được".
Lộ trình leo thang (Escalation Route)	Quy trình và các bên liên quan cần được thông báo hoặc tham gia khi phát sinh vấn đề không thể giải quyết trong phạm vi hoạt động hiện tại hoặc khi không đạt được cổng chất lượng.	Đảm bảo các vấn đề nghiêm trọng được xử lý kịp thời, tránh tắc nghẽn và duy trì tiến độ dự án.	"Vấn đề mâu thuẫn yêu cầu nghiêm trọng (critical requirement conflict) leo thang lên Quản lý dự án (Project Manager) và Chủ sản phẩm (Product Owner)", "Phản hồi tiêu cực lặp lại từ người dùng (repeated negative user feedback) leo thang lên Trưởng phòng nghiệp vụ (Business Department Head) và Trưởng nhóm BA (BA Team Lead)".

Minh họa hoạt động BA: Quy trình giao hàng Nova Foods

Hiểu quy trình nghiệp vụ (Business Process) là hoạt động cốt lõi của BA. BA phải thu thập, phân tích, mô hình hóa các quy trình hiện trạng (As-Is) và đề xuất quy trình tương lai (To-Be). Bảng minh họa dưới đây là một ví dụ cụ thể về cách BA thực hiện bước "Phân tích quy trình giao hàng hiện tại" cho Nova Foods, cùng với sơ đồ quy trình tương ứng.

Bảng minh họa thực thi hoạt động BA: Phân tích quy trình giao hàng Nova Foods

Trường	Mô tả cụ thể cho Nova Foods
Diễn giải hoạt động (Activity Description)	Phân tích quy trình giao hàng hiện tại của Nova Foods để xác định các bước, vai trò, dữ liệu liên quan, và các điểm nghẽn hoặc cải tiến tiềm năng.
Tên hoạt động (Activity Name)	Phân tích Quy trình Giao hàng Nhanh As-Is (Nova Foods Expedited Delivery Process As-Is Analysis)
Mã hoạt động (Activity ID)	NF-BA-PRC-005
Tác nhân (Actor)	Chuyên viên Phân tích nghiệp vụ (BA)
Hành động (Action)	1. Thu thập và xem xét tài liệu hiện có (SOPs, hướng dẫn vận hành). 2. Phỏng vấn các bên liên quan: Trưởng bộ phận Logistics, Trưởng bộ phận Sales, Điều phối viên giao hàng, Tài xế, Nhân viên kho. 3. Quan sát trực tiếp quy trình (nếu có thể). 4. Lập sơ đồ quy trình hiện trạng (As-Is Process Flow Diagram).
Đối tượng (Object)	Quy trình "Xử lý đơn hàng giao nhanh" (TRC-PRC-DEL-001) của Nova Foods, áp dụng cho các sản phẩm đông lạnh cần giao trong 24 giờ tại khu vực TP. Hồ Chí Minh.
Bằng chứng tạo ra (Evidence Produced)	1. NF-ASIS-PRC-DEL-001.pdf: Sơ đồ quy trình giao hàng nhanh As-Is (Mermaid/PlantUML). 2. NF-INTVW-NOTES-DEL-001.docx: Ghi chú phỏng vấn và các phát hiện chính. 3. NF-PAINPOINTS-DEL-001.xlsx: Danh sách các điểm yếu, vấn đề và cơ hội cải tiến.
Luật quyết định (Decision Rule)	1. Sơ đồ quy trình phải thể hiện rõ ràng tất cả các bước chính từ khi đơn hàng được tiếp nhận đến khi giao thành công. 2. Mỗi bước phải được gán cho một vai trò cụ thể (Logistics_Coordinator, Driver, Warehouse_Staff). 3. Các điểm quyết định (decision points) và luồng thay thế (alternative flows) phải được minh họa. 4. Mọi điểm nghẽn (bottlenecks) hoặc lỗi (errors) được xác định phải được ghi lại trong NF-PAINPOINTS-DEL-001.xlsx.
Cổng chất lượng (Quality Gate)	1. Sơ đồ NF-ASIS-PRC-DEL-001.pdf phải được Trưởng bộ phận Logistics của Nova Foods và một đại diện từ bộ phận Sales (Chủ nghiệp vụ) xem xét và xác nhận (Sign-off) là "Phản ánh chính xác thực tế vận hành hiện tại". 2. Danh sách điểm yếu phải được ưu tiên và đánh giá sơ bộ bởi Chủ nghiệp vụ.
Lộ trình leo thang (Escalation Route)	Nếu có bất đồng nghiêm trọng về mô tả quy trình hiện trạng giữa các bộ phận hoặc nếu Chủ nghiệp vụ không thể xác nhận Sơ đồ As-Is do thiếu thông tin/mâu thuẫn dữ liệu, BA phải báo cáo ngay cho Quản lý dự án (Project Manager) và Trưởng phòng nghiệp vụ (Business Department Head) liên quan.

Sơ đồ quy trình giao hàng nhanh Nova Foods (As-Is Process Flow Diagram)

Sơ đồ này minh họa quy trình giao hàng nhanh mô phỏng của Nova Foods, bao gồm các bước từ khi đơn hàng được xác nhận đến khi giao hàng hoàn tất hoặc bị hủy.

graph TD
    A[Bắt đầu: Đơn hàng <br/> [ORD-20260715-001] xác nhận] --> B(Kiểm tra tồn kho <br/> sản phẩm [SKU-NF-SP007])
    B --> C{Tồn kho đủ?};
    C -- Có --> D(Chuẩn bị và đóng gói hàng <br/> tại Kho_ĐôngLạnh_NF);
    C -- Không --> E(Thông báo khách hàng<br/> về [ORD-20260715-001] & Hủy đơn hàng);
    D --> F(Phân công TàiXế_NF_007 và phương tiện);
    F --> G(Vận chuyển hàng đến <br/> địa điểm khách hàng);
    G --> H{Khách hàng nhận hàng và thanh toán/ký nhận?};
    H -- Có --> I(Kết thúc: <br/> Hàng được giao thành công);
    H -- Không --> J(Xử lý đơn hàng bị từ chối/không thành công);
    J --> K(Kết thúc: <br/> Đơn hàng bị hủy do KH từ chối);
    E --> L(Kết thúc: <br/> Đơn hàng bị hủy do hết hàng);

    subgraph Vai trò
        direction LR
        Logistics_Coordinator(Điều phối viên Logistics)
        Warehouse_Staff(Nhân viên kho)
        Driver(Tài xế)
        Customer(Khách hàng)
        Sales_Team(Bộ phận Sales)
    end

    B -- Thực hiện --> Logistics_Coordinator;
    D -- Thực hiện --> Warehouse_Staff;
    F -- Thực hiện --> Logistics_Coordinator;
    G -- Thực hiện --> Driver;
    H -- Tương tác với --> Customer;
    E -- Xử lý --> Sales_Team;
    J -- Xử lý --> Driver & Sales_Team;

→ skipped: phân loại chi tiết hơn các loại đơn hàng Nova Foods (VD: đơn hàng lẻ, đơn hàng sỉ), xử lý trường hợp giao lại; add when yêu cầu chi tiết hóa quy trình con hoặc khi mở rộng phạm vi sản phẩm/khách hàng. → skipped: các cổng kiểm soát chất lượng kỹ thuật trong sơ đồ (VD: kiểm tra nhiệt độ hàng đông lạnh); add when phạm vi bao gồm quản lý chất lượng vận hành hoặc tuân thủ an toàn thực phẩm chuyên sâu. → skipped: chi tiết về hệ thống thông tin hỗ trợ cho từng bước (VD: ERP, WMS, TMS); add when phân tích yêu cầu hệ thống hoặc tích hợp hệ thống là trọng tâm.

6. Output thu ???c

Core

Khi thực hiện Capstone Nova Foods Delivery Pack, chuyên viên Business Analyst (BA) sẽ tạo hoặc cập nhật nhiều sản phẩm bàn giao (artifact) quan trọng. Các artifact này là kết quả của quá trình phân tích yêu cầu nghiệp vụ (business requirements), định nghĩa quy trình, và xác định dữ liệu. Chúng đóng vai trò là cơ sở cho các giai đoạn thiết kế, phát triển và kiểm thử hệ thống ERP.

Artifact ID Chuẩn	Tên Artifact (Tiếng Việt & Anh)	Owner	Trạng thái (Status)	Phiên bản (Version)	Nội dung Tối thiểu	Nghĩa vụ Lịch sử Thay đổi
NF-DLV-REQ-001	Yêu cầu Nghiệp vụ Giao hàng (Business Requirement Document - BRD)	Business Analyst	IN_REVIEW	v0.9.0	Mục tiêu nghiệp vụ; Phạm vi (Scope); Yêu cầu chức năng (Functional Requirements - FRs); Yêu cầu phi chức năng (Non-Functional Requirements - NFRs); Tiêu chí chấp nhận (Acceptance Criteria - ACs); Giả định (Assumptions); Ràng buộc (Constraints).	Mọi thay đổi: ghi nhận tác giả, ngày, lý do, phiên bản mới.
NF-DLV-PROC-001	Đặc tả Quy trình Giao hàng (Process Specification)	Business Analyst, SME nghiệp vụ (Subject Matter Expert)	IN_REVIEW	v0.9.0	Mô tả quy trình hiện tại (As-Is); Quy trình mục tiêu (To-Be) dùng BPMN/UML; Luồng dữ liệu (Data Flows); Điểm quyết định; Vai trò liên quan.	Mọi thay đổi: ghi nhận tác giả, ngày, lý do, phiên bản mới.
CANONICAL_DATA_DICTIONARY	Bản cập nhật Từ điển Dữ liệu (Data Dictionary Update)	Business Analyst, Data Architect	IN_REVIEW	v0.9.0	Định nghĩa thuật ngữ mới liên quan giao hàng (ví dụ: DeliveryOrderIdentifier, DeliveryStatus, VehicleID); thuộc tính, kiểu dữ liệu, ràng buộc, ví dụ dữ liệu, mối quan hệ với các thực thể khác.	Mọi bổ sung/sửa đổi: ghi nhận tác giả, ngày, phiên bản.
NF-DLV-TRAC-001	Ma trận Truy vết Yêu cầu (Requirements Traceability Matrix - RTM)	Business Analyst	IN_REVIEW	v0.9.0	Liên kết giữa yêu cầu nghiệp vụ (FR/NFR) với các trường hợp sử dụng (Use Cases), đặc tả chức năng, test cases, các module hệ thống, và các quy tắc nghiệp vụ.	Mọi cập nhật liên kết: ghi nhận tác giả, ngày, phiên bản.

Applied

Để minh họa, xem xét artifact Yêu cầu Nghiệp vụ Giao hàng (BRD) cho Nova Foods:

• Facts (Sự kiện): Nova Foods cần cải thiện tính minh bạch và độ chính xác của quá trình giao hàng thực phẩm đông lạnh từ kho đến khách hàng.
• Current Behavior (Hành vi Hiện tại): Hiện tại, việc theo dõi trạng thái đơn hàng giao hàng được thực hiện thủ công bằng cách sử dụng bảng tính Excel và liên lạc qua điện thoại. Khách hàng không nhận được thông tin cập nhật tự động. Điều này dẫn đến nhiều cuộc gọi hỗ trợ khách hàng và khiếu nại.
• Underlying Need (Nhu cầu Cốt lõi): Nova Foods cần một hệ thống đáng tin cậy để tự động hóa việc theo dõi trạng thái giao hàng, cung cấp cập nhật theo thời gian thực cho khách hàng và bộ phận nội bộ, giảm thiểu sai sót và nâng cao hiệu quả vận hành. Mục tiêu là cải thiện trải nghiệm khách hàng và giảm chi phí điều hành bộ phận Logistics.
• Options (Các Lựa chọn):
  1. Nâng cấp Module ERP Hiện có: Mở rộng chức năng của module quản lý vận chuyển (Transportation Management System - TMS) tích hợp trong hệ thống ERP hiện tại của Nova Foods.
  2. Tích hợp Hệ thống TMS Bên thứ Ba: Mua và tích hợp một giải pháp TMS chuyên dụng từ nhà cung cấp bên ngoài.
  3. Phát triển Module Riêng: Tự phát triển một module theo dõi giao hàng tùy chỉnh hoàn toàn.
• Decision Criteria (Tiêu chí Quyết định):
  • Chi phí (Cost): Tổng chi phí sở hữu (Total Cost of Ownership - TCO), bao gồm cấp phép, phát triển, triển khai và bảo trì.
  • Thời gian triển khai (Time to Market): Tốc độ đưa giải pháp vào sử dụng.
  • Khả năng Tích hợp (Integration Capability): Mức độ dễ dàng tích hợp với ERP hiện có và các hệ thống khác của Nova Foods.
  • Bảo trì (Maintainability): Khả năng dễ dàng duy trì và cập nhật hệ thống trong tương lai.
  • Mức độ Tùy biến (Customization): Khả năng điều chỉnh hệ thống để phù hợp với các quy trình đặc thù của Nova Foods.
• Decision (Quyết định): Nâng cấp Module ERP Hiện có. Lý do: Giảm thiểu rủi ro tích hợp, tận dụng hạ tầng và dữ liệu hiện có, chi phí ban đầu thấp hơn so với giải pháp bên thứ ba hoặc phát triển mới.
• Authority (Thẩm quyền Quyết định):
  • Chủ sở hữu Nghiệp vụ Logistics (Business Owner Logistics): Ông Trần Văn An.
  • Chủ sở hữu Nghiệp vụ Sales (Business Owner Sales): Bà Nguyễn Thị Bích.
  • Kiến trúc sư Hệ thống (System Architect): Ông Lê Duy Cường.
• Artifact (Sản phẩm Bàn giao): Yêu cầu Nghiệp vụ Giao hàng (BRD) — /03-templates/NF-DLV-REQ-001_Delivery_Tracking_BRD_v0.9.0.md.
  • Nội dung cốt lõi:
    • Mục tiêu: Tự động hóa cập nhật trạng thái đơn hàng từ Kho đến Khách hàng.
    • FR-DLV-001: Hệ thống phải cho phép nhân viên kho cập nhật trạng thái "Đã xuất kho" (OUT_FOR_DELIVERY) cho đơn hàng NF-ORD-20260715-001 khi hàng được tài xế nhận.
    • FR-DLV-002: Hệ thống phải tự động gửi thông báo SMS/Email đến khách hàng KH-NF-0123 khi trạng thái đơn hàng NF-ORD-20260715-001 chuyển sang "Đang giao" (IN_TRANSIT).
    • NFR-SEC-001: Dữ liệu trạng thái giao hàng phải được mã hóa khi truyền tải giữa các hệ thống (tham chiếu OWASP ASVS).
    • AC-DLV-001: Nhân viên kho có thể cập nhật trạng thái đơn hàng trong vòng 5 giây sau khi quét mã vạch sản phẩm.
• Consequence if Wrong (Hậu quả nếu Sai): Khách hàng mất niềm tin vào dịch vụ giao hàng của Nova Foods, tăng chi phí vận hành do xử lý khiếu nại thủ công, có thể dẫn đến thất thoát hàng hóa không truy vết được, và tiềm ẩn vi phạm các điều khoản hợp đồng dịch vụ giao hàng.

Senior Lens

Chất lượng của output quyết định thành công dự án. Mỗi artifact không chỉ là tài liệu mô tả mà là bằng chứng của quá trình phân tích và quyết định.

Quality Gate (Cổng Chất lượng) để sản phẩm bàn giao sẵn sàng cho đánh giá tiếp theo (downstream review) mà không cần phê duyệt hay sẵn sàng sản xuất:

1. Tính nhất quán nội bộ: Mọi phần của artifact không được mâu thuẫn với nhau. Ví dụ, FRs không được trái ngược NFRs, hoặc mô tả quy trình không được trái ngược với các vai trò được định nghĩa.
2. Khả năng truy vết (Traceability): Mọi yêu cầu, quy trình, thuật ngữ mới phải có khả năng truy vết ngược về nguồn gốc (ví dụ: cuộc họp, tài liệu nguồn, luật định như Luật An toàn thực phẩm cho quy trình xử lý thực phẩm, Nghị định 123/2020/NĐ-CP cho thông tin hóa đơn), được ghi nhận trong 00_SOURCE_MAP hoặc TRACEABILITY_ID_REGISTRY.
3. Rõ ràng và không mơ hồ: Ngôn ngữ sử dụng phải chính xác, rõ ràng, không có chỗ cho hiểu lầm. Tránh thuật ngữ kỹ thuật không cần thiết hoặc viết tắt không được giải thích. Mỗi khái niệm quan trọng phải được định nghĩa hoặc tham chiếu đến CANONICAL_DATA_DICTIONARY.
4. Đầy đủ nội dung tối thiểu: Đảm bảo tất cả các phần được yêu cầu trong định nghĩa artifact (như bảng trên) đều được điền đầy đủ. Không bỏ sót mục nào.
5. ID chuẩn hóa: Mọi ID (Artifact ID, FR ID, NFR ID, etc.) phải tuân thủ naming convention được xác định trong TRACEABILITY_ID_REGISTRY và là duy nhất trong phạm vi của chúng.
6. Đã thu thập phản hồi (nhưng chưa phê duyệt): Đã thực hiện review với các bên liên quan và tổng hợp phản hồi. Artifact chưa cần phải "APPROVED" nhưng cần chứng minh đã được xem xét và xử lý các điểm còn thắc mắc.

Việc vượt qua cổng chất lượng này cho phép artifact chuyển sang giai đoạn tiếp theo (ví dụ: Thiết kế hệ thống) với rủi ro thấp hơn về sự hiểu lầm hoặc yêu cầu thay đổi lớn. Nó không đồng nghĩa với việc sản phẩm đã sẵn sàng sản xuất hoặc đã được phê duyệt chính thức.

Quick Reference

• Artifact là gì: Sản phẩm cụ thể tạo ra hoặc cập nhật trong quá trình Business Analysis (BA) (ví dụ: BRD, Process Spec).
• Mục đích: Ghi lại yêu cầu, quy trình, dữ liệu; làm cơ sở cho phát triển hệ thống.
• ID chuẩn: Mỗi artifact có ID duy nhất (NF-DLV-REQ-001, NF-DLV-PROC-001).
• Owner: Vai trò chịu trách nhiệm chính (Business Analyst, SME).
• Trạng thái: IN_REVIEW (đang xem xét), v0.9.0 (phiên bản).
• Lịch sử thay đổi: Bắt buộc ghi lại mọi sửa đổi để truy vết và quản lý phiên bản.
• Chất lượng: Rõ ràng, nhất quán, truy vết được, đủ nội dung tối thiểu, ID chuẩn hóa.

Đặc tả Tính năng Hệ thống Chi tiết (Detailed System Feature Specification)

Core

Đặc tả Tính năng Hệ thống Chi tiết (Detailed System Feature Specification) là một artifact mô tả cụ thể từng tính năng mà hệ thống phần mềm cần có để đáp ứng các yêu cầu nghiệp vụ (business requirements). Đây là tài liệu cốt lõi, làm cơ sở cho đội phát triển (development team) hiểu được cái gì cần xây dựng và đội kiểm thử (QA team) cái gì cần xác minh. Một BA (Business Analyst) tạo và duy trì tài liệu này.

Artifact này cần chứa các thông tin tối thiểu sau:

Thuộc tính	Mô tả	Chuẩn
ID	Mã định danh duy nhất cho tính năng.	NF-FCR-{NNN}. Ví dụ: NF-FCR-001.
Tên tính năng	Tóm tắt rõ ràng về mục đích của tính năng.	Ngắn gọn, dễ hiểu, phản ánh chức năng chính.
Mô tả	Giải thích chi tiết về tính năng, bao gồm các quy tắc nghiệp vụ (business rules) liên quan, các trường hợp sử dụng (use cases) chính, hành vi mong muốn và các ràng buộc (constraints).	Rõ ràng, không mơ hồ, tập trung vào hành vi hệ thống, không đi sâu vào giải pháp kỹ thuật.
Ưu tiên	Mức độ quan trọng của tính năng.	P1 - Critical, P2 - High, P3 - Medium, P4 - Low.
Nguồn gốc	Các yêu cầu nghiệp vụ, stakeholder hoặc văn bản pháp lý làm căn cứ cho tính năng này.	Liên kết truy vết (traceability) đến CANONICAL_BUSINESS_RULES.md hoặc các yêu cầu nghiệp vụ gốc (ví dụ: NF-BR-XXX), hoặc các nguồn luật như Luật ATTP 55/2010/QH12.
Tiêu chí chấp nhận	(Acceptance Criteria - AC) Các điều kiện có thể kiểm thử được (testable conditions) mà tính năng phải thỏa mãn để được coi là hoàn thành và đáp ứng yêu cầu.	Mỗi AC phải rõ ràng, kiểm thử được (SMART: Specific, Measurable, Achievable, Relevant, Time-bound), không mơ hồ, đầy đủ và duy nhất.
Trạng thái	Tình trạng hiện tại của tính năng trong vòng đời phát triển.	NEW, IN_REVIEW, READY_FOR_DEV, IN_DEV, IN_TEST, DONE, BLOCKED, REJECTED.
Owner	Business Analyst	Người chịu trách nhiệm chính về nội dung và chất lượng của đặc tả này.
Nghĩa vụ lịch sử thay đổi	Bắt buộc	Ghi nhận mọi thay đổi, ai thay đổi, khi nào và lý do.

Applied

Nova Foods, trong dự án ERP mô phỏng, đang phát triển phân hệ quản lý kho (Warehouse Management System - WMS) để đảm bảo tuân thủ Luật An toàn thực phẩm 55/2010/QH12 về truy xuất nguồn gốc và tối ưu hóa tồn kho. Một tính năng quan trọng là "Quản lý lô hàng sản phẩm".

• Sự thật (Facts):
  • Hệ thống ERP hiện tại của Nova Foods chỉ quản lý số lượng tổng sản phẩm, không có thông tin chi tiết về từng lô sản xuất (batch/lot).
  • Luật An toàn thực phẩm 55/2010/QH12 yêu cầu mọi thực phẩm phải có khả năng truy xuất nguồn gốc đến cấp lô sản xuất, bao gồm ngày sản xuất và hạn sử dụng.
  • Người quản lý kho (Warehouse Manager) Nova Foods cần biết lô nào sắp hết hạn để ưu tiên xuất kho, áp dụng nguyên tắc FEFO (First-Expired, First-Out).
• Hành vi hiện tại (Current Behavior): Nhân viên Nova Foods đang dùng bảng tính Excel để theo dõi thủ công lô sản xuất, ngày sản xuất và hạn sử dụng. Việc này tốn thời gian, dễ sai sót và khó truy vết nhanh chóng.
• Nhu cầu cơ bản (Underlying Need): Nova Foods cần một giải pháp tự động để lưu trữ, quản lý và truy xuất thông tin lô hàng chính xác, tuân thủ luật pháp, đồng thời hỗ trợ quy trình xuất kho hiệu quả, giảm thiểu lãng phí hàng tồn kho.
• Các lựa chọn (Options):
  1. Mua và tích hợp một hệ thống WMS bên thứ ba.
  2. Phát triển tính năng quản lý lô tùy chỉnh trong module quản lý kho hiện có của ERP.
• Tiêu chí quyết định (Decision Criteria): Chi phí, thời gian triển khai, mức độ tùy chỉnh và tuân thủ pháp luật.
• Quyết định (Decision): Nova Foods quyết định phát triển tính năng tùy chỉnh (Option 2) do chi phí và độ phức tạp tích hợp WMS bên ngoài vượt quá ngân sách và thời gian dự kiến của phiên bản v0.9.0.
• Thẩm quyền (Authority): Business Owner (nghiệp vụ kho Nova Foods) và IT Lead.
• Artifact (Output): Dưới đây là một phần của Đặc tả Tính năng Hệ thống Chi tiết cho tính năng "Quản lý lô hàng tồn kho" tại Nova Foods (dữ liệu tổng hợp):

ID	Tên tính năng	Mô tả	Ưu tiên	Nguồn gốc	Tiêu chí chấp nhận	Trạng thái
NF-FCR-005	Ghi nhận lô hàng nhập kho	Hệ thống cho phép nhân viên kho nhập thông tin lô hàng (Batch Number), ngày sản xuất (Manufacture Date), và hạn sử dụng (Expiry Date) khi nhập kho một mặt hàng.	P1 - Critical	NF-BR-012: Quản lý nhập kho Luật ATTP 55/2010/QH12	1. Khi nhập kho Product X, hệ thống yêu cầu nhập Batch Number (string, tối đa 20 ký tự), Manufacture Date (date), Expiry Date (date). 2. Expiry Date phải sau Manufacture Date. 3. Nếu thiếu thông tin lô, hệ thống hiển thị cảnh báo và không cho phép hoàn thành nhập kho.	READY_FOR_DEV
NF-FCR-006	Truy vấn thông tin lô hàng	Người dùng có thể tìm kiếm, lọc và xem thông tin chi tiết của các lô hàng tồn kho theo Product ID, Batch Number, hoặc khoảng Expiry Date.	P1 - Critical	NF-BR-013: Quản lý tồn kho Luật ATTP 55/2010/QH12	1. Hệ thống cung cấp giao diện tìm kiếm với các trường Product ID, Batch Number, Expiry Date (from/to). 2. Kết quả hiển thị bao gồm: Product Name, Batch Number, Quantity, Manufacture Date, Expiry Date, Warehouse Location. 3. Thời gian phản hồi tìm kiếm dưới 2 giây với 10.000 lô hàng.	READY_FOR_DEV
NF-FCR-007	Gợi ý xuất kho theo FEFO	Khi tạo lệnh xuất kho, hệ thống tự động gợi ý các lô hàng có hạn sử dụng sớm nhất (FEFO) để xuất trước cho cùng một Product ID.	P2 - High	NF-BR-014: Tối ưu hóa xuất kho	1. Trong form xuất kho, khi chọn Product ID, danh sách Batch Number hiển thị mặc định theo thứ tự tăng dần của Expiry Date. 2. Nhân viên kho có thể ghi đè lựa chọn lô mặc định nếu có lý do chính đáng (ví dụ: lô bị lỗi).	IN_DEV
NF-FCR-008	Cảnh báo lô hàng sắp hết hạn	Hệ thống tự động gửi thông báo (email hoặc dashboard) về các lô hàng sẽ hết hạn trong 30 ngày tới.	P3 - Medium	NF-BR-015: Quản lý rủi ro tồn kho	1. Hàng ngày, hệ thống quét các lô hàng có Expiry Date trong vòng 30 ngày tới. 2. Tạo danh sách các lô đó với Product ID, Batch Number, Quantity, Expiry Date. 3. Gửi email thông báo tới "Warehouse Manager" và "Supply Chain Lead" vào 8h sáng Asia/Ho_Chi_Minh.	NEW

• Hậu quả nếu sai (Consequence if Wrong): Nova Foods có thể vi phạm các quy định về an toàn thực phẩm, đối mặt với rủi ro bị phạt hoặc thu hồi sản phẩm. Ngoài ra, việc quản lý tồn kho không hiệu quả dẫn đến lãng phí do sản phẩm hết hạn, ảnh hưởng đến lợi nhuận.
• Cổng chất lượng (Quality Gate): Artifact NF-FCR-XXX được đánh dấu READY_FOR_DEV (sẵn sàng cho phát triển) khi:
  1. Mỗi tính năng có ID, Tên tính năng, Mô tả, Ưu tiên, Nguồn gốc được định nghĩa rõ ràng.
  2. Tiêu chí chấp nhận (AC) cho mỗi tính năng phải CÓ THỂ KIỂM THỬ (testable), RÕ RÀNG (clear), ĐẦY ĐỦ (complete) và KHÔNG TRÙNG LẶP (non-redundant), đồng thời phải có thể truy vết về yêu cầu nghiệp vụ gốc (traceable).
  3. Artifact đã được BA xem xét nội bộ và nhận phản hồi từ ít nhất một đại diện nghiệp vụ (Business Subject Matter Expert - SME) không chính thức. Ở giai đoạn này, không yêu cầu phê duyệt chính thức (formal approval) hay sẵn sàng sản xuất (production readiness).

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

stateDiagram-v2
    direction TB
    [*] --> NEW: BA khởi tạo ID tính năng
    NEW --> IN_REVIEW: BA hoàn thành bản nháp
    IN_REVIEW --> READY_FOR_DEV: BA chỉnh AC theo phản hồi SME, đạt cổng chất lượng
    READY_FOR_DEV --> IN_DEV: Đội phát triển tiếp nhận tính năng

    note right of READY_FOR_DEV
        ID, Tên tính năng, Mô tả, Ưu tiên, Nguồn gốc
        Nguồn gốc và AC truy về yêu cầu nghiệp vụ gốc
        AC testable, rõ ràng, đầy đủ, không trùng lặp
        BA xem xét nội bộ
        Có phản hồi phi chính thức từ ít nhất một Business SME
        Không yêu cầu phê duyệt chính thức
        Không phải production readiness
    end note

Senior Lens

• Tối giản hóa (Simplification): Đặc tả tính năng cần tập trung vào mục tiêu nghiệp vụ và hành vi mong muốn của hệ thống, không phải cách thức kỹ thuật để đạt được nó. Tránh chi tiết hóa quá mức các giải pháp database, API hoặc giao diện người dùng nếu điều đó làm giảm tính linh hoạt của đội phát triển. ponytail: Chỉ định nghĩa "cái gì", không phải "làm thế nào". Add "làm thế nào" khi có thiết kế kỹ thuật cụ thể.
• Tái sử dụng (Reuse): Trước khi tạo một tính năng mới, luôn kiểm tra CANONICAL_BUSINESS_RULES.md và CANONICAL_DATA_DICTIONARY.md để đảm bảo tính nhất quán và tái sử dụng các định nghĩa đã có. Tránh định nghĩa lại dữ liệu hoặc quy tắc.
• Tính nguyên tử (Atomicity): Mỗi NF-FCR-XXX phải là một đơn vị tính năng độc lập, có thể phân phối giá trị và kiểm thử riêng biệt. Việc gộp nhiều chức năng phức tạp vào một tính năng duy nhất làm chậm quá trình phát triển và kiểm thử, khó khăn trong quản lý thay đổi.
• Truy vết (Traceability) hai chiều: Đảm bảo mỗi tính năng có thể truy vết ngược về yêu cầu nghiệp vụ gốc và tiến tới các trường hợp kiểm thử (test cases). Điều này quan trọng để đánh giá tác động khi có thay đổi.
• Ngăn ngừa lãng phí (Waste Prevention): Áp dụng nguyên tắc YAGNI (You Ain't Gonna Need It - Bạn sẽ không cần nó đâu). Chỉ đặc tả những tính năng thực sự cần thiết cho phiên bản hiện tại, tránh "chuẩn bị cho tương lai" bằng cách thêm các yêu cầu chưa có bằng chứng nghiệp vụ. Việc này giảm scope creep và tăng tốc độ giao hàng.

Quick Reference

• Mục đích: Đặc tả rõ ràng các tính năng hệ thống làm đầu vào cho phát triển và kiểm thử.
• Chủ sở hữu: Business Analyst.
• Nội dung cốt lõi: ID, Tên, Mô tả, Ưu tiên, Nguồn gốc, Tiêu chí chấp nhận (AC), Trạng thái.
• Yêu cầu AC: Phải rõ ràng, kiểm thử được, truy vết được về yêu cầu nghiệp vụ.
• Cổng chất lượng: BA xem xét nội bộ, SME phản hồi phi chính thức. Không yêu cầu phê duyệt chính thức hoặc sẵn sàng sản xuất.

Tiêu chí Sẵn sàng Review: Cổng Chất lượng Output BA

BA tạo nhiều output. Mỗi output cần đạt tiêu chuẩn nhất định trước khi gửi review (xem xét) bên ngoài. Tiêu chuẩn này là cổng chất lượng (quality gate). Cổng chất lượng ngăn lỗi nhỏ phát triển thành lỗi lớn, giảm chi phí sửa chữa.

Core

Cổng chất lượng là tập hợp tiêu chí kiểm tra nội bộ. BA tự kiểm, hoặc Senior BA, BA Lead kiểm tra chéo (peer review). Mục tiêu: đảm bảo output đủ rõ ràng, đầy đủ, nhất quán, có thể kiểm chứng, có thể truy vết. Không yêu cầu phê duyệt (approval) hay sẵn sàng sản xuất (production readiness). Chỉ là sẵn sàng cho bước review tiếp theo.

Nguyên tắc cổng chất lượng: 1. Đầy đủ (Completeness): Mọi phần tài liệu yêu cầu có mặt. Không bỏ sót thông tin cần thiết. 2. Rõ ràng (Clarity): Ngôn ngữ chính xác, không mơ hồ. Thuật ngữ thống nhất. 3. Nhất quán (Consistency): Không có mâu thuẫn nội bộ. Nhất quán với các artifact liên quan (ví dụ: Data Dictionary, Business Rules). 4. Có thể kiểm chứng (Verifiability): Nội dung có thể được xác nhận là đúng hoặc sai. 5. Có thể truy vết (Traceability): Kết nối rõ ràng với nguồn gốc (yêu cầu nghiệp vụ, quy tắc kinh doanh, v.v.). Mỗi yêu cầu có ID duy nhất. 6. Định dạng chuẩn (Standard Format): Tài liệu tuân thủ mẫu, cấu trúc đã định.

graph TD
    subgraph Quá trình Sản xuất Artifact BA
        A[BA soạn thảo/cập nhật Artifact] --> B{Artifact hoàn thành bản nháp?};
        B -- Có --> C[Kiểm tra Cổng chất lượng nội bộ (BA/Senior BA)];
        C -- Đạt tiêu chí --> D[Artifact sẵn sàng gửi Review (cho Product Owner, Dev, QA, v.v.)];
        C -- Không đạt --> E[Ghi nhận thiếu sót];
        E --> A;
    end

Applied

Tình huống: Nova Foods cần một Đặc tả Yêu cầu Chức năng (FRS) cho tính năng "Theo dõi nhiệt độ xe giao hàng".

• Facts (Dữ kiện): Nova Foods (mô phỏng) cần hệ thống quản lý giao hàng ghi lại nhiệt độ xe. Artifact FRS NF-FRS-TEMP-001 đang ở v0.9.0, trạng thái IN_REVIEW.
• Current Behavior (Hành vi hiện tại): Bản nháp FRS NF-FRS-TEMP-001 đã được BA soạn thảo. BA cần kiểm tra chất lượng trước khi gửi Product Owner và Đội phát triển (Dev Team) review.
• Underlying Need (Nhu cầu cốt lõi): Đảm bảo FRS không có lỗi cơ bản, rõ ràng, đủ thông tin cho Dev và QA trước khi chính thức review. Việc này tránh lãng phí thời gian review cho tài liệu chưa hoàn thiện.
• Options (Các lựa chọn):
  1. Gửi FRS ngay mà không qua cổng chất lượng nội bộ.
  2. Áp dụng cổng chất lượng nội bộ trước khi gửi review.
• Decision Criteria (Tiêu chí quyết định): Chi phí sửa lỗi (cost of change), hiệu quả quy trình, chất lượng output đầu ra.
• Decision (Quyết định): Lựa chọn 2. Áp dụng cổng chất lượng nội bộ cho FRS.
• Authority (Thẩm quyền): BA (tự kiểm), Senior BA (kiểm tra chéo nếu có).
• Artifact (Artifact): FRS NF-FRS-TEMP-001 (phiên bản được điều chỉnh sau khi qua cổng chất lượng nội bộ).
• Consequence if Wrong (Hậu quả nếu sai): Nếu FRS chứa mâu thuẫn hoặc thiếu thông tin, team Dev/QA sẽ mất thời gian đặt câu hỏi, hiểu sai yêu cầu, hoặc phải sửa đổi lớn sau này. Chi phí phát hiện và sửa lỗi tăng theo giai đoạn muộn hơn trong vòng đời dự án (SDLC).

Tiêu chí Cổng Chất lượng cho FRS NF-FRS-TEMP-001: 1. Mỗi chức năng (Function): Mô tả rõ ràng, không trùng lặp. 2. ID và Truy vết: Mỗi yêu cầu chức năng có ID duy nhất (NF-FRS-TEMP-001-F001), truy vết đến Yêu cầu nghiệp vụ (Business Requirement) (NF-BR-LOGIS-005). 3. Tiêu chí chấp nhận (Acceptance Criteria): Có ít nhất một tiêu chí chấp nhận testable (có thể kiểm thử) cho mỗi chức năng. 4. Ràng buộc (Constraints): Mọi ràng buộc phi chức năng (non-functional constraints) như hiệu năng, bảo mật (ASVS 5.0.0), khả năng mở rộng được liệt kê nếu liên quan đến chức năng này. 5. Thuật ngữ: Nhất quán với CANONICAL_DATA_DICTIONARY.md và CANONICAL_BUSINESS_RULES.md. 6. Sơ đồ luồng (Flow Diagram): Nếu có, sơ đồ (Mermaid/UML Activity) phản ánh đúng luồng logic chức năng.

Senior Lens

Cổng chất lượng không phải thủ tục hành chính. Đây là bước quan trọng để BA tự đánh giá, cải thiện sản phẩm trước khi đưa ra cộng đồng lớn hơn. Phát hiện lỗi sớm nhất có thể. BABOK Guide nhấn mạnh tầm quan trọng của chất lượng thông tin yêu cầu. Không phải mọi lỗi đều là lỗi lớn, nhưng lỗi trong tài liệu căn bản sẽ gây lỗi tầng cao hơn.

BA cao cấp tập trung vào: * Ngữ cảnh (Contextual Quality): Mức độ nghiêm ngặt của cổng chất lượng phụ thuộc vào rủi ro và tầm quan trọng của artifact. Artifact rủi ro cao (quy định pháp lý, tài chính) cần cổng chất lượng chặt chẽ hơn. * Tối ưu hóa (Optimization): Cổng chất lượng không nên là tắc nghẽn (bottleneck). Chuẩn hóa checklist, tự động hóa kiểm tra định dạng/cấu trúc giúp đẩy nhanh quá trình. * Học hỏi (Learning): Phân tích các lần artifact không qua cổng chất lượng. Điều chỉnh quy trình BA để tránh lặp lại.

Quick Reference

Artifact (Loại Output BA)	Tiêu chí Cổng Chất lượng Chính (Sẵn sàng Review)	Tham chiếu liên quan (ví dụ: ID)
Yêu cầu nghiệp vụ (BR)	Đầy đủ phạm vi, mục tiêu rõ, có ID truy vết.	NF-BR-xxxx từ TRACEABILITY_ID_REGISTRY
Đặc tả Yêu cầu Chức năng (FRS)	Mỗi chức năng rõ ràng, có AC ban đầu, truy vết BR.	NF-FRS-xxxx từ TRACEABILITY_ID_REGISTRY
Ca sử dụng (Use Case)	Luồng chính/phụ rõ, Actor định nghĩa, tiền/hậu điều kiện.	/03-templates/UC-TEMPLATE.md
Câu chuyện người dùng (User Story)	Đạt INVEST, có tiêu chí chấp nhận cụ thể, có giá trị nghiệp vụ.	NF-US-xxxx
Mô hình quy trình (Process Model - BPMN)	Tuân thủ BPMN, luồng logic đúng, không mâu thuẫn.	BPMN 2.0.2, NF-PROC-xxxx
Từ điển dữ liệu (Data Dictionary)	Mỗi thuộc tính rõ nghĩa, kiểu dữ liệu, ràng buộc, nhất quán.	CANONICAL_DATA_DICTIONARY.md
Quy tắc nghiệp vụ (Business Rule)	Diễn giải rõ, có điều kiện/hành động, nguồn gốc pháp lý/nghiệp vụ.	CANONICAL_BUSINESS_RULES.md
Đặc tả Giao diện API (API Spec)	Endpoint, method, request/response, trạng thái lỗi, bảo mật API.	OAS 3.1.1, NF-API-xxxx
Đặc tả Giao diện người dùng (UI Spec)	Thành phần, luồng màn hình, trạng thái, yêu cầu UX/UI cơ bản (WCAG 2.2).	NF-UI-xxxx

7. Who consumes those outputs?

Core

Các sản phẩm đầu ra của BA (BA outputs) không phải là tài liệu tự thân mà là công cụ để các bên liên quan khác nhau trong dự án xây dựng, kiểm thử, và triển khai giải pháp. Mỗi vai trò có mục đích tiêu thụ riêng, dựa trên phạm vi công việc và trách nhiệm của họ. Việc BA hiểu rõ ai sẽ dùng gì và dùng để làm gì giúp tạo ra các sản phẩm đầu ra chất lượng, dễ hiểu và phù hợp với nhu cầu từng đối tượng. Điều này giảm thiểu hiểu lầm, tối ưu hóa quá trình bàn giao (handoff) và tăng hiệu quả dự án.

Dưới đây là bảng phân tích cách các vai trò chính tiêu thụ các sản phẩm đầu ra của BA:

Artifact (Sản phẩm BA)	Vai trò tiêu thụ chính (Consumer Role)	Mục đích tiêu thụ (Consumption Purpose)
Yêu cầu Nghiệp vụ (Business Requirements - BR)	Chủ nghiệp vụ (Business Owner)	Xác nhận nhu cầu, mục tiêu nghiệp vụ được BA hiểu và ghi nhận chính xác. Đảm bảo giải pháp đáp ứng mục tiêu chiến lược.
	PM/Chủ sản phẩm (PM/Product Owner)	Hiểu bối cảnh, ưu tiên, định hướng tổng thể của sản phẩm hoặc tính năng.
	Kiến trúc sư (Architect)	Đánh giá tính khả thi, tác động đến kiến trúc tổng thể, xác định các ràng buộc kỹ thuật.
	Nhà phát triển (Developers)	Nắm vững "cái gì" cần xây dựng và "tại sao" cần nó, tạo động lực và hiểu sâu hơn về nghiệp vụ.
	Kiểm thử viên (QA)	Lập kế hoạch kiểm thử tổng thể, xác định các kịch bản kiểm thử cấp cao.
	Đội vận hành (Operations)	Đánh giá tác động vận hành, yêu cầu hỗ trợ, tài nguyên.
	Chủ sở hữu chuyên môn (Specialist Owners)	Ví dụ: Pháp lý (Legal) xem xét tuân thủ quy định (như Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 của Việt Nam).
Đặc tả Yêu cầu Chức năng (Functional Requirements Specification - FRS)	PM/Chủ sản phẩm	Đảm bảo các tính năng chi tiết đáp ứng yêu cầu nghiệp vụ đã đặt ra.
	Kiến trúc sư	Thiết kế chi tiết kiến trúc giải pháp, xác định công nghệ và mô hình dữ liệu.
	Nhà phát triển	Cụ thể hóa "cái gì" cần code, chi tiết hành vi của từng chức năng.
	Kiểm thử viên	Viết test case (kiểm thử nghiệm), kịch bản kiểm thử chi tiết cho từng chức năng.
	Đội vận hành	Lập kế hoạch triển khai, cấu hình hệ thống, chuẩn bị tài liệu hướng dẫn sử dụng.
Ca sử dụng (Use Case)	PM/Chủ sản phẩm	Hiểu luồng người dùng chi tiết, xác định ranh giới và các trường hợp sử dụng.
	Nhà phát triển	Xây dựng logic chức năng theo các bước tương tác của người dùng.
	Kiểm thử viên	Thiết kế test case cho từng luồng chính (main flow) và luồng phụ (alternative/exception flows).
	UX/UI Specialist	Thiết kế giao diện người dùng (user interface) để hỗ trợ các luồng tương tác.
Câu chuyện người dùng (User Story)	PM/Chủ sản phẩm	Ưu tiên công việc trong backlog, quản lý tiến độ, xác nhận giá trị nghiệp vụ nhỏ.
	Nhà phát triển	Phát triển các chức năng nhỏ, dễ quản lý, dễ dàng kiểm tra độc lập.
	Kiểm thử viên	Viết test case dựa trên Acceptance Criteria (Tiêu chí chấp nhận) đính kèm User Story.
	Chủ nghiệp vụ	Xác nhận "giá trị" và "nhu cầu" từ góc nhìn của người dùng cuối.
Mô hình quy trình (Process Model - BPMN)	Chủ nghiệp vụ	Xác nhận quy trình nghiệp vụ hiện tại (As-Is) và tương lai (To-Be) được mô tả đúng.
	PM/Chủ sản phẩm	Hiểu bối cảnh nghiệp vụ, tối ưu hóa và chuẩn hóa các quy trình.
	Kiến trúc sư	Thiết kế hệ thống hỗ trợ các luồng nghiệp vụ, đặc biệt là các hệ thống quản lý quy trình (workflow engine).
	Nhà phát triển	Xây dựng logic điều phối quy trình, tích hợp các hệ thống liên quan.
	Đội vận hành	Đào tạo nhân viên, giám sát hiệu suất và các điểm nghẽn trong quy trình.
Từ điển dữ liệu (Data Dictionary)	Kiến trúc sư	Thiết kế cấu trúc cơ sở dữ liệu (database schema), mô hình dữ liệu vật lý.
	Nhà phát triển	Xây dựng cấu trúc dữ liệu, sử dụng biến, tham số API một cách nhất quán.
	Kiểm thử viên	Lập kế hoạch kiểm thử dữ liệu, tạo dữ liệu giả lập (mock data) và dữ liệu kiểm thử.
	Data Specialist (Chuyên gia Dữ liệu)	Đảm bảo chất lượng dữ liệu, quản trị dữ liệu, tích hợp dữ liệu giữa các hệ thống.
	Chủ sở hữu chuyên môn (Ví dụ: Bảo mật)	Đánh giá yêu cầu bảo mật dữ liệu theo tiêu chuẩn như Tiêu chuẩn Xác minh Bảo mật Ứng dụng (OWASP ASVS), yêu cầu mã hóa, che dấu dữ liệu.
Quy tắc nghiệp vụ (Business Rule)	Chủ nghiệp vụ	Xác nhận tính chính xác, đầy đủ và hiệu lực của các quy tắc.
	PM/Chủ sản phẩm	Ưu tiên và quản lý vòng đời của các quy tắc, đặc biệt khi có thay đổi.
	Kiến trúc sư	Thiết kế hệ thống quản lý quy tắc (Rule Engine) hoặc cách thức tích hợp quy tắc vào hệ thống.
	Nhà phát triển	Cài đặt logic nghiệp vụ, xử lý các điều kiện và hành động theo quy tắc.
	Kiểm thử viên	Viết test case để kiểm tra từng quy tắc nghiệp vụ, bao gồm các trường hợp biên và ngoại lệ.
	Legal/Compliance Specialist	Xác nhận quy tắc tuân thủ các quy định pháp luật (ví dụ: Luật Kế toán 88/2015/QH13) và chính sách nội bộ.
Đặc tả Giao diện API (API Specification - OAS)	Kiến trúc sư	Thiết kế kiến trúc tích hợp hệ thống, xác định các cổng kết nối và giao thức.
	Nhà phát triển (Frontend/Backend)	Phát triển API (Backend), tích hợp và tiêu thụ API (Frontend, các hệ thống khác).
	Kiểm thử viên	Viết test case API, thực hiện kiểm thử tích hợp (integration testing) và kiểm thử hiệu năng.
	Security Specialist (Chuyên gia Bảo mật)	Đánh giá các lỗ hổng bảo mật liên quan đến API theo Tiêu chuẩn bảo mật API Top 10 (OWASP API Security Top 10).
Đặc tả Giao diện người dùng (User Interface Specification - UI Spec)	PM/Chủ sản phẩm	Xác nhận trải nghiệm người dùng (user experience - UX) và các tính năng trực quan.
	Nhà phát triển (Frontend)	Xây dựng giao diện người dùng theo thiết kế, bao gồm bố cục, màu sắc, font chữ và tương tác.
	Kiểm thử viên	Kiểm thử giao diện người dùng (UI testing), kiểm thử khả năng sử dụng (usability testing), và kiểm thử tuân thủ các tiêu chuẩn như WCAG 2.2 về trợ năng (accessibility).
	UX/UI Specialist	Đảm bảo tính nhất quán của thiết kế, tuân thủ các nguyên tắc UX/UI và hướng dẫn thương hiệu.

Applied

Case: Kiến trúc sư tiêu thụ Yêu cầu Nghiệp vụ (BR) cho tính năng Thanh toán trực tuyến Nova Foods

• Facts (Sự kiện): Nova Foods cần nâng cấp hệ thống ERP. Một yêu cầu nghiệp vụ là NF-BR-0010: Hệ thống phải hỗ trợ thanh toán trực tuyến cho các đơn hàng giao tại nhà. BR này được BA thu thập và ghi nhận từ Chủ nghiệp vụ.
• Current Behavior (Hành vi hiện tại): Hầu hết các đơn hàng giao tại nhà của Nova Foods (dữ liệu mô phỏng) được thanh toán bằng tiền mặt (Cash on Delivery - COD). Thanh toán trực tuyến hiện có chỉ là tùy chọn phụ, không tích hợp sâu vào ERP chính.
• Underlying Need (Nhu cầu cốt lõi): Giảm thiểu rủi ro tiền mặt trong quá trình giao hàng, tăng tốc độ đối soát và xử lý tài chính, cải thiện trải nghiệm khách hàng bằng cách cung cấp thêm lựa chọn thanh toán tiện lợi.
• Options (Các lựa chọn):
  1. Tích hợp một hoặc nhiều cổng thanh toán hiện có (Payment Gateway) vào ERP Nova Foods.
  2. Xem xét việc phát triển một module thanh toán trực tuyến riêng, độc lập với các cổng bên ngoài.
  3. Giữ nguyên hệ thống COD và chỉ tích hợp một cách tối thiểu cho mục đích báo cáo.
• Decision Criteria (Tiêu chí quyết định): Thời gian triển khai (time to market), Chi phí phát triển/tích hợp, Khả năng mở rộng (scalability) khi số lượng đơn hàng tăng, Mức độ bảo mật (dựa trên Tiêu chuẩn Xác minh Bảo mật Ứng dụng - OWASP ASVS và tuân thủ PCI DSS - Tiêu chuẩn Bảo mật Dữ liệu Ngành Thẻ Thanh toán), Dễ dàng bảo trì.
• Decision (Quyết định): Kiến trúc sư (Architect) và PM/Chủ sản phẩm (Product Owner) quyết định tích hợp sâu hai cổng thanh toán phổ biến hiện có vào ERP, để đảm bảo tính dự phòng và khả năng đáp ứng cao. Điều này cân bằng giữa chi phí, thời gian và yêu cầu bảo mật.
• Authority (Thẩm quyền): Kiến trúc sư phê duyệt thiết kế kỹ thuật của module tích hợp. PM/Chủ sản phẩm phê duyệt lựa chọn nhà cung cấp dịch vụ thanh toán và roadmap triển khai.
• Artifact (Output BA liên quan): NF-BR-0010, NF-FRS-0045: Đặc tả tích hợp Cổng thanh toán A và Cổng thanh toán B, NF-DD-0021: Các thuộc tính dữ liệu giao dịch thanh toán.
• Consequence if Wrong (Hậu quả nếu sai): Nếu Kiến trúc sư bỏ qua các yếu tố bảo mật hoặc khả năng mở rộng khi thiết kế giải pháp thanh toán trực tuyến, hệ thống Nova Foods có thể gặp rủi ro bị tấn công, mất dữ liệu thanh toán nhạy cảm, hoặc không thể xử lý khi có lượng giao dịch lớn, dẫn đến gián đoạn kinh doanh và tổn thất lớn.

Senior Lens

Hiểu cách các bên liên quan tiêu thụ sản phẩm đầu ra của BA là chìa khóa để tạo ra giá trị thực. Một BA cấp cao không chỉ tạo ra tài liệu, mà còn thiết kế tài liệu để tối ưu hóa quá trình tiêu thụ của từng vai trò. Điều này bao gồm việc:

1. Dự đoán hiểu lầm: Biết những điểm mơ hồ, khó hiểu mà mỗi vai trò có thể gặp phải.
2. Tùy chỉnh thông tin: Cung cấp mức độ chi tiết phù hợp cho từng đối tượng (ví dụ: Nhà phát triển cần chi tiết kỹ thuật hơn Chủ nghiệp vụ).
3. Tạo điều kiện bàn giao hiệu quả: Không chỉ gửi tài liệu mà còn tổ chức các buổi trao đổi, giải thích, đảm bảo thông tin được tiếp nhận và hiểu đúng.
4. Nhận diện các điểm tích hợp chéo: Hiểu rằng đầu ra của mình là đầu vào cho quá trình của người khác, và sự thiếu sót ở một nơi có thể gây ảnh hưởng dây chuyền.

Quick Reference

Vai trò (Role)	Hoạt động tiêu thụ chính (Primary Consumption Activity)
Nhà phát triển (Developers)	Xây dựng tính năng, tích hợp hệ thống, cài đặt logic nghiệp vụ theo yêu cầu.
Kiểm thử viên (QA)	Thiết kế test case, kiểm tra chức năng, xác minh tuân thủ yêu cầu và tiêu chí chấp nhận.
Kiến trúc sư (Architect)	Thiết kế hệ thống tổng thể và chi tiết, lựa chọn công nghệ, đảm bảo tính khả thi và bền vững.
PM/Chủ sản phẩm (PM/Product Owner)	Ưu tiên tính năng, định hướng sản phẩm, quản lý vòng đời sản phẩm, xác nhận giá trị nghiệp vụ.
Chủ nghiệp vụ (Business Owner)	Xác nhận nhu cầu, mục tiêu, giá trị nghiệp vụ, đưa ra quyết định kinh doanh.
Đội vận hành (Operations)	Lập kế hoạch triển khai, cấu hình, giám sát hệ thống, đào tạo người dùng.
Chủ sở hữu chuyên môn (Specialist Owners)	Đánh giá tuân thủ (pháp lý, bảo mật, dữ liệu, UX/UI), đảm bảo chất lượng đặc thù.

Vai trò, Quyết định, Bằng chứng và Leo thang

Mỗi vai trò (role) liên quan quá trình phát triển sản phẩm Nova Foods sẽ sử dụng đầu ra (output) từ gói giao nhận (delivery pack) theo cách riêng. Vai trò đó ra quyết định dựa trên các bằng chứng cụ thể, và biết khi nào cần leo thang (escalate) vấn đề vượt thẩm quyền.

Vai trò (Role)	Quyết định (Decision)	Bằng chứng cần (Evidence Needed)	Cần leo thang (Escalate When)
Lập trình viên (Developer)	Cách triển khai kỹ thuật: chọn thư viện, cấu trúc mã (code), giải pháp thuật toán. Cơ chế tích hợp với hệ thống khác.	Đặc tả yêu cầu chức năng (Functional Requirements Specification - FRS), yêu cầu phi chức năng (Non-Functional Requirements - NFRs). Đặc tả API (OpenAPI Specification). Mô hình dữ liệu logic/vật lý. Sơ đồ luồng xử lý (UML Activity Diagram).	Yêu cầu không rõ ràng, mâu thuẫn kỹ thuật nội bộ, không khả thi về thời gian/chi phí ước tính. Phát hiện rủi ro bảo mật trong thiết kế, vượt tầm giải quyết.
Kiểm thử viên (QA Tester)	Kịch bản kiểm thử, dữ liệu kiểm thử, trường hợp kiểm thử (test case), độ bao phủ kiểm thử. Mức độ nghiêm trọng của lỗi.	Yêu cầu chức năng, Acceptance Criteria (ACs), Bảng hợp lệ (Validity Table), Sơ đồ trạng thái (State Diagram). Sơ đồ luồng xử lý. Quy tắc nghiệp vụ (Business Rules).	AC không rõ, không đo lường được. Không có truy vết (traceability) từ yêu cầu đến test case. Phát hiện lỗi nghiêm trọng, rủi ro lớn hệ thống. Quy tắc nghiệp vụ mơ hồ, không thể kiểm thử.
Kiến trúc sư (Architect)	Thiết kế hệ thống tổng thể, cấu trúc hạ tầng (cloud/on-premise), chọn công nghệ nền tảng, cơ chế tích hợp, tiêu chuẩn bảo mật.	Tất cả Yêu cầu nghiệp vụ (Business Requirements - BRs), FRS, NFRs (đặc biệt hiệu năng, bảo mật, khả năng mở rộng). Sơ đồ kiến trúc hiện tại. Quy tắc nghiệp vụ cốt lõi (Canonical Business Rules).	Yêu cầu đòi hỏi thay đổi kiến trúc lớn, không phù hợp chiến lược công nghệ. Rủi ro hiệu năng, bảo mật, khả năng mở rộng không chấp nhận được. Chi phí triển khai vượt ngân sách phê duyệt.
Quản lý dự án (PM) / Chủ sản phẩm (Product Owner)	Ưu tiên tính năng, phạm vi sản phẩm (scope), lộ trình phát triển (roadmap), nghiệm thu tính năng/sprint. Chấp thuận user story.	Mô tả nghiệp vụ, mục tiêu sản phẩm, giá trị kinh doanh (Business Value), ước tính chi phí/lợi ích. Phân tích tác động (Impact Analysis).	Xung đột ưu tiên giữa các bên liên quan. Thay đổi lớn phạm vi ảnh hưởng cam kết dự án. Rủi ro không đạt mục tiêu kinh doanh. Vấn đề nguồn lực nghiêm trọng.
Chủ nghiệp vụ (Business Owner)	Xác nhận yêu cầu nghiệp vụ chính xác, phù hợp với mục tiêu kinh doanh Nova Foods. Xác nhận tính khả thi nghiệp vụ. Phê duyệt kiểm thử chấp nhận người dùng (User Acceptance Testing - UAT).	Mô tả nghiệp vụ chi tiết, quy trình nghiệp vụ hiện tại/đề xuất (BPMN Diagram). Mockup giao diện, prototype. Kết quả UAT, Báo cáo lỗi (Defect Report).	Yêu cầu thay đổi mục tiêu chiến lược của Nova Foods. Giải pháp không đáp ứng nhu cầu cốt lõi. Phát hiện rủi ro pháp lý/tuân thủ lớn. Ước tính lợi ích kinh doanh không đạt.
Vận hành (Operations)	Tiêu chuẩn vận hành, công cụ giám sát, quy trình hỗ trợ, yêu cầu khả năng vận hành (Operability Requirements). Xác nhận tài liệu vận hành.	Yêu cầu phi chức năng (đặc biệt về khả năng sẵn sàng, phục hồi, giám sát, hỗ trợ). Sơ đồ hạ tầng kỹ thuật. Đặc tả triển khai (Deployment Specification).	Giải pháp khó vận hành, chi phí vận hành cao bất thường. Rủi ro ảnh hưởng dịch vụ Nova Foods. Yêu cầu vận hành không được đáp ứng bởi thiết kế hệ thống.
Chủ chuyên gia Pháp lý (Legal Owner)	Đánh giá tuân thủ pháp luật (Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, Nghị định 356/2025/NĐ-CP của Việt Nam). Phê duyệt điều khoản sử dụng.	Mô tả nghiệp vụ liên quan dữ liệu nhạy cảm. Chính sách bảo mật dữ liệu Nova Foods. Báo cáo đánh giá tác động quyền riêng tư (PIA/DPIA). Danh sách dữ liệu cá nhân (Canonical Data Dictionary).	Rủi ro vi phạm pháp luật, quy định nhà nước. Vấn đề giải thích pháp lý, yêu cầu tư vấn cấp cao.
Chủ chuyên gia Kế toán (Accounting Owner)	Đánh giá tuân thủ chuẩn mực kế toán (Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ). Xác nhận báo cáo tài chính.	Mô tả nghiệp vụ tài chính, quy trình kế toán, luồng dữ liệu tài chính. Bảng kê chứng từ. Báo cáo mẫu. Quy tắc nghiệp vụ kế toán Nova Foods.	Rủi ro sai lệch số liệu kế toán. Hệ thống không tuân thủ chuẩn mực kế toán Việt Nam.
Chủ chuyên gia Bảo mật (Security Owner)	Đánh giá rủi ro bảo mật (dựa OWASP ASVS 5.0.0, OWASP API Security Top 10 2023). Phê duyệt chính sách an toàn thông tin.	Yêu cầu bảo mật (Security Requirements). Mô hình mối đe dọa (Threat Model). Đặc tả API. Kết quả kiểm tra lỗ hổng (Vulnerability Scan Report).	Lỗ hổng bảo mật lớn. Dữ liệu nhạy cảm bị lộ. Thiết kế không đáp ứng tiêu chuẩn bảo mật quy định.

Hiểu lầm phổ biến khi bàn giao và Câu hỏi làm rõ

Core

Khi BA bàn giao các sản phẩm đầu ra (outputs) như tài liệu yêu cầu (requirements documents), user story (câu chuyện người dùng), mô hình nghiệp vụ (business process models) hoặc đặc tả chức năng (functional specifications), mỗi bên liên quan (stakeholders) tiếp nhận thông tin với góc nhìn và ưu tiên riêng. Điều này dễ dẫn đến hiểu lầm, lãng phí nguồn lực và nguy cơ sản phẩm cuối cùng không đáp ứng đúng nhu cầu ban đầu.

Applied

• Facts (Sự thật): BA tạo ra nhiều loại tài liệu. Ví dụ: yêu cầu tính năng (feature requirements) NF-FEAT-001, mô hình quy trình bán hàng của Nova Foods (BPMN), định nghĩa trường dữ liệu (data field definitions) trong CANONICAL_DATA_DICTIONARY.
• Current Behavior (Hành vi hiện tại): Các vai trò khác nhau (Developer, QA, Business Owner) đọc các tài liệu này qua lăng kính công việc của họ. Ví dụ, Developer tập trung vào cách mã hóa, QA tìm kịch bản kiểm thử, Business Owner quan tâm giá trị kinh doanh. Yêu cầu "hệ thống tự động tính toán chi phí vận chuyển" có thể được Developer hiểu là "tạo thuật toán tính giá", còn Operations hiểu là "tạo chi phí hợp lệ với nhà cung cấp vận chuyển Nova Logistics".
• Underlying Need (Nhu cầu cốt lõi): Đảm bảo mọi bên liên quan có cùng hiểu biết về phạm vi, mục tiêu và cách thức hoạt động của tính năng.
• Options (Các lựa chọn):
  1. Chờ đợi hiểu lầm xảy ra: Bàn giao tài liệu và chờ phản hồi. Hiệu quả thấp, chi phí sửa lỗi (rework) cao.
  2. Họp rà soát chung: Trình bày tài liệu. Tốt hơn nhưng vẫn có thể bỏ sót chi tiết.
  3. Hỏi chủ động: BA chủ động đặt câu hỏi cụ thể, nhắm mục tiêu vào từng đối tượng để làm rõ. Hiệu quả cao nhất, giảm thiểu rủi ro.
• Decision Criteria (Tiêu chí quyết định): Giảm thiểu lỗi do hiểu sai yêu cầu; tăng tốc độ phát triển và kiểm thử; nâng cao chất lượng sản phẩm; đáp ứng đầy đủ yêu cầu nghiệp vụ của Nova Foods.
• Decision (Quyết định): Áp dụng chiến lược đặt câu hỏi chủ động và tổ chức các buổi rà soát tài liệu có cấu trúc.
• Authority (Thẩm quyền): BA chịu trách nhiệm dẫn dắt quá trình làm rõ. Các bên liên quan chịu trách nhiệm cung cấp thông tin và xác nhận hiểu biết. PM/Product Owner có thẩm quyền cuối cùng về việc chấp thuận yêu cầu được đáp ứng.
• Artifact (Sản phẩm đầu ra): Các câu hỏi làm rõ và câu trả lời được ghi lại trong biên bản họp hoặc cập nhật trực tiếp vào tài liệu yêu cầu (NF-FEAT-001, NF-PROC-002, v.v.).
• Consequence if Wrong (Hậu quả nếu sai): Chu trình phát triển bị kéo dài; tăng chi phí; hệ thống vận hành sai so với quy trình nghiệp vụ mong muốn của Nova Foods.

Senior Lens

BA cấp cao xem quá trình bàn giao không chỉ là chuyển giao tài liệu mà là một sự kiện liên tục xác nhận hiểu biết chung (shared understanding). Luôn giả định có khả năng hiểu lầm cho đến khi được xác nhận rõ ràng. Sử dụng câu hỏi mở (open-ended questions) để khuyến khích các bên liên quan diễn giải lại yêu cầu bằng ngôn ngữ của chính họ. Ví dụ, hỏi Developer: "Anh/chị sẽ xây dựng tính năng này như thế nào để đảm bảo tính sẵn sàng (availability) và khả năng mở rộng (scalability)?", hoặc hỏi QA: "Chị/anh sẽ kiểm thử tính năng này với những kịch bản nào, đặc biệt là các kịch bản lỗi (error scenarios)?". Mọi sự làm rõ phải được truy nguyên (traceability) về nguồn gốc và cập nhật vào nguồn chân lý duy nhất (canonical source) để tránh sai lệch.

Quick Reference

Vai trò (Role)	Hiểu lầm phổ biến (Common Misunderstanding)	Câu hỏi làm rõ cụ thể (Specific Clarification Question)	Khi nào cần escalation? (When to Escalate?)
Developer (Nhà phát triển)	Chỉ tập trung vào giải pháp kỹ thuật (technical solution), bỏ qua ngữ cảnh nghiệp vụ (business context) hoặc các ràng buộc phi chức năng (non-functional requirements) như hiệu năng (performance), bảo mật (security).	"Anh/chị hiểu yêu cầu NF-FEAT-001: Tự động tính toán chi phí vận chuyển cần xử lý các trường hợp nào? Hệ thống cần phản hồi nhanh đến mức nào (NF-NFR-PERF-001)? Dữ liệu nhạy cảm (PII - Personally Identifiable Information) nào cần bảo vệ theo Luật 91/2025/QH15?"	Khi Developer đề xuất giải pháp kỹ thuật vi phạm quy tắc nghiệp vụ cốt lõi của Nova Foods (CANONICAL_BUSINESS_RULES), ràng buộc pháp lý, hoặc ràng buộc phi chức năng quan trọng (ví dụ: bảo mật OWASP ASVS Level 2), và không thể tìm thấy giải pháp thay thế. Cần PM/Product Owner, Architect hoặc Legal Owner quyết định.
QA/Tester (Kiểm thử viên)	Hiểu sai phạm vi kiểm thử (test scope), thiếu kịch bản kiểm thử biên (edge cases), hoặc không có đủ dữ liệu kiểm thử (test data).	"Anh/chị dự kiến các kịch bản kiểm thử chính (test scenarios) cho NF-FEAT-002: Xác nhận đơn hàng là gì? Chúng ta cần chuẩn bị dữ liệu cho những trường hợp nào (ví dụ: đơn hàng trống, đơn hàng quá lớn, đơn hàng hủy, đơn hàng với sản phẩm hết hàng)? Điều kiện thành công (acceptance criteria) của AC-002.1: Đơn hàng thành công là gì?"	Khi QA nhận thấy mâu thuẫn giữa yêu cầu và tiêu chí chấp nhận, không thể kiểm thử một kịch bản quan trọng do thiếu môi trường/dữ liệu, hoặc khi một khiếm khuyết được phát hiện ảnh hưởng trực tiếp đến quy trình nghiệp vụ cốt lõi của Nova Foods. Cần PM/Product Owner, Business Owner quyết định.
Architect (Kiến trúc sư)	Thiếu thông tin chi tiết về tương tác hệ thống (system interactions) hoặc ràng buộc công nghệ (technical constraints) từ các hệ thống hiện có của Nova Foods.	"Giải pháp kiến trúc cho NF-ARCH-001: Tích hợp hệ thống quản lý kho (WMS) cần xem xét các điểm tích hợp API (API integration points) nào? Có ràng buộc về phiên bản (versioning) hoặc giao thức (protocol) từ WMS hiện tại không? Có rủi ro về hiệu năng khi tải cao không?"	Khi Architect nhận thấy yêu cầu không thể hiện thực hóa với kiến trúc hiện tại, đòi hỏi thay đổi kiến trúc lớn, hoặc phát sinh chi phí/rủi ro kỹ thuật quá cao mà không được chấp thuận rõ ràng. Cần PM/Product Owner, Business Owner, Technical Lead cấp cao quyết định.
PM/Product Owner (Quản lý sản phẩm/Chủ sản phẩm)	Ưu tiên tính năng chưa phù hợp (feature prioritization), không nắm rõ độ phức tạp kỹ thuật hoặc chi phí ẩn.	"Anh/chị hiểu giá trị kinh doanh (business value) của NF-FEAT-003: Chức năng quản lý khuyến mãi là gì? Nếu chúng ta chỉ triển khai NF-FEAT-003.1: Tạo mã giảm giá trước, liệu có đạt được mục tiêu ban đầu của Nova Foods không? Rủi ro nào phát sinh nếu chúng ta trì hoãn tính năng [x]?"	Khi PM/PO thay đổi phạm vi (scope change) hoặc ưu tiên một cách đột ngột mà không có phân tích tác động đầy đủ, hoặc khi yêu cầu gây ra xung đột rõ ràng với chiến lược sản phẩm dài hạn của Nova Foods. Cần Business Owner, các bên liên quan chính xác nhận.
Business Owner (Chủ nghiệp vụ)	Hiểu sai về khả năng công nghệ (technology capabilities), bỏ qua quy định pháp luật (legal compliance) hoặc tác động đến các phòng ban khác của Nova Foods.	"Với NF-PROC-001: Quy trình xử lý đơn hàng đổi trả, anh/chị mong muốn hệ thống sẽ thực hiện đến bước nào? Quy định nào trong Nghị định 356/2025/NĐ-CP (bảo vệ dữ liệu cá nhân) cần được tuân thủ? Việc này ảnh hưởng đến Operations hay Kế toán như thế nào?"	Khi Business Owner đưa ra yêu cầu mâu thuẫn với quy định pháp luật hiện hành (Luật 91/2025/QH15, Nghị định 123/2020/NĐ-CP), chính sách nội bộ của Nova Foods, hoặc gây ra xung đột lớn giữa các phòng ban. Cần Legal Owner, Compliance Officer, C-level executive quyết định.
Operations (Vận hành)	Không nắm rõ quy trình mới (new process) hoặc tác động của hệ thống đến công việc hàng ngày, gây ra khó khăn khi vận hành thực tế.	"Với NF-PROC-002: Quy trình giao hàng và thu COD, anh/chị cần những thông tin gì trên giao diện để xử lý nhanh nhất? Có bước nào trong quy trình hiện tại sẽ thay đổi đáng kể khi dùng hệ thống mới không? Cần đào tạo (training) gì để nhân viên sử dụng hiệu quả?"	Khi Operations báo cáo hệ thống mới sẽ làm gián đoạn nghiêm trọng quy trình vận hành cốt lõi, không thể duy trì dịch vụ khách hàng của Nova Foods, hoặc đòi hỏi nguồn lực không khả thi để vận hành. Cần Business Owner, PM/Product Owner quyết định.
Specialist Owner (Chủ chuyên gia: Legal, Compliance, Accounting)	Giả định hệ thống tự động tuân thủ (automatic compliance) hoặc bỏ qua các quy định chi tiết.	"Với NF-ACCT-001: Báo cáo doanh thu, Luật Kế toán 88/2015/QH13 yêu cầu thông tin gì? Thông tin này có khớp với Nghị định 123/2020/NĐ-CP về hóa đơn điện tử không? Chúng ta cần bằng chứng kiểm toán (audit trail) như thế nào?"	Khi Specialist Owner phát hiện yêu cầu hoặc thiết kế hệ thống tiềm ẩn rủi ro pháp lý, rủi ro tài chính hoặc rủi ro tuân thủ quy định lớn cho Nova Foods. Cần Legal Owner, Accounting Owner, Compliance Officer, hoặc C-level executive quyết định.

8. Detailed Worked Example

Applied

Nova Foods (mô phỏng) hiện vận hành một quy trình giao hàng phức tạp cho các đơn đặt hàng phát sinh từ điện thoại. Quy trình này tồn tại những điểm nghẽn và thiếu sót thông tin cần được hệ thống hóa trong ERP. Kịch bản dưới đây phác thảo sự kiện (Facts) và hành vi hiện tại (Current Behavior) để làm cơ sở cho việc phân tích sâu hơn.

Sự kiện (Facts)

Các sự kiện đã được xác minh liên quan đến quy trình xử lý đơn hàng qua điện thoại tại Nova Foods:

ID sự kiện (Fact ID)	Mô tả sự kiện (Fact Description)	Nguồn gốc (Source / Rationale)
NF-DEL-F-001	Nova Foods tiếp nhận đơn hàng từ ba kênh chính: ứng dụng di động (mobile app), website và điện thoại.	Phỏng vấn nghiệp vụ (Business Interview) với Trưởng phòng Bán hàng (Head of Sales) và Trưởng phòng Vận hành (Head of Operations).
NF-DEL-F-002	Đơn hàng qua điện thoại (ĐHĐT) chiếm trung bình 15% tổng số lượng đơn hàng mỗi ngày, tương đương khoảng 50-70 đơn/ngày trong giờ cao điểm.	Báo cáo phân tích kênh bán hàng Quý 2/2026, Nova Foods Internal Report NF-SALE-Q2-2026.
NF-DEL-F-003	ĐHĐT được ghi nhận thủ công vào một tệp Excel dùng chung (NF_Phone_Orders_Live.xlsx) trên Google Drive.	Quan sát trực tiếp (Direct Observation) quy trình làm việc của nhân viên điều phối (Dispatcher) và nhân viên bán hàng (Sales Agent).
NF-DEL-F-004	Thông tin tài xế giao hàng (delivery driver) được quản lý rời rạc; không có hệ thống theo dõi vị trí tài xế theo thời gian thực (real-time location tracking).	Phỏng vấn nghiệp vụ với Nhân viên Điều phối, xác nhận bởi Trưởng phòng Vận hành.
NF-DEL-F-005	Quy định giao hàng nội thành là 30 phút, ngoại thành là 60 phút kể từ khi xác nhận đơn hàng với khách.	Quy trình vận hành chuẩn (Standard Operating Procedure - SOP) của Nova Foods: NF-OPS-SOP-DELIVERY-V1.2.
NF-DEL-F-006	Các món hàng trong đơn có thể thuộc nhiều kho (warehouse) khác nhau, yêu cầu gom hàng (picking and consolidation).	Phỏng vấn nghiệp vụ với Nhân viên Kho (Warehouse Staff).

Hành vi hiện tại (Current Behavior)

Hành vi hiện tại mô tả các bước mà Nova Foods thực hiện để xử lý một ĐHĐT.

1. Tiếp nhận ĐHĐT: Nhân viên bán hàng (Sales Agent) nhận cuộc gọi từ khách hàng. Nhân viên ghi nhận thông tin đặt hàng gồm: tên khách, số điện thoại, địa chỉ giao hàng, danh sách các món ăn (tên món, số lượng), và yêu cầu đặc biệt (ví dụ: không cay, thêm tương ớt).
2. Tạo ĐHĐT thủ công: Nhân viên bán hàng truy cập tệp NF_Phone_Orders_Live.xlsx trên Google Drive. Tạo một dòng mới với một mã đơn hàng duy nhất (TDH-YYYYMMDD-NNN, ví dụ: TDH-20260807-001). Nhập đầy đủ thông tin khách hàng, chi tiết món hàng, tính tổng tiền. Cập nhật trạng thái ban đầu là "Mới" (New).
3. Gán tài xế (Driver Assignment): Nhân viên điều phối (Dispatcher) liên tục theo dõi tệp Excel, tìm kiếm các ĐHĐT có trạng thái "Mới". Nhân viên điều phối dựa vào kinh nghiệm, gọi điện thoại cho các tài xế khả dụng (available drivers) để hỏi vị trí và khả năng nhận đơn. Việc này mất trung bình 5-10 phút cho mỗi đơn.
4. Cập nhật trạng thái ĐHĐT: Sau khi tài xế xác nhận nhận đơn, nhân viên điều phối cập nhật thủ công cột "Trạng thái" thành "Đã gán" (Assigned) và điền "Mã tài xế" (Driver ID) vào tệp Excel.
5. Thực hiện giao hàng: Tài xế nhận thông tin đơn hàng qua điện thoại hoặc giấy ghi chú từ nhân viên điều phối. Tài xế thực hiện gom hàng từ các kho tương ứng (nếu cần) và giao hàng đến địa chỉ khách. Nếu là đơn thu hộ (Cash on Delivery - COD), tài xế sẽ thu tiền trực tiếp từ khách.
6. Xác nhận hoàn thành: Sau khi giao hàng thành công, tài xế gọi điện thoại về cho nhân viên điều phối để xác nhận. Nhân viên điều phối sau đó cập nhật trạng thái "Đã gán" thành "Đã giao" (Delivered) trong tệp Excel. Đối với đơn COD, nhân viên cũng ghi nhận số tiền đã thu.
7. Tổng hợp báo cáo: Cuối mỗi ca hoặc cuối ngày, nhân viên kế toán (Accountant) truy cập tệp Excel để tổng hợp doanh thu và số lượng đơn hàng, phục vụ cho việc đối soát (reconciliation) và báo cáo nội bộ.
8. Xử lý sai sót: Trong trường hợp thông tin đơn hàng bị sai, địa chỉ không rõ ràng hoặc tài xế không liên lạc được, nhân viên điều phối phải gọi lại cho khách hàng để xác minh, sau đó điều chỉnh thủ công trong Excel và tìm tài xế thay thế nếu cần.

Ví dụ Chi Tiết Thực Tế: Phân Tích Giải Pháp Xử Lý Khiếu Nại Khách Hàng

Core

Detailed Worked Example (Ví dụ làm việc chi tiết) giúp BA (Business Analyst - Chuyên viên Phân tích Nghiệp vụ) áp dụng tư duy cấu trúc vào tình huống giả lập, từ sự thật cho đến hậu quả. Mục tiêu là luyện tập khả năng đi từ vấn đề thực tế đến giải pháp có thẩm quyền, có sản phẩm đầu ra và hiểu rõ rủi ro. Phương pháp này bảo đảm mọi quyết định đều có căn cứ, minh bạch và có thể truy vết.

Applied

Để minh họa, chúng ta sẽ xem xét một tình huống giả lập tại Nova Foods, liên quan đến việc quản lý khiếu nại về giao hàng.

1. Facts (Sự thật)

• Đối tượng: Nova Foods Trading & Manufacturing (mô phỏng).
• Vấn đề: Khách hàng khiếu nại về việc giao sai mặt hàng (sai mã, sai số lượng) hoặc không đầy đủ đơn hàng.
• Tần suất: Trung bình 50 khiếu nại mỗi tuần liên quan đến lỗi giao hàng.
• Hệ thống hiện tại: NovaERP v3.2 không có module quản lý khiếu nại khách hàng.
• Công cụ: Nhân viên Dịch vụ Khách hàng (CSKH - Customer Service Representative) sử dụng tệp Customer_Complaints_2026.xlsx trên SharePoint để ghi nhận.
• Mã định danh: Các đơn hàng Nova Foods có định dạng NF-ORD-YYYYMMDD-XXXX.
• Mã khiếu nại: Chưa có mã định danh chuẩn, nhân viên tự đặt hoặc dùng mã Excel.
• Dữ liệu: Dữ liệu hoàn toàn tổng hợp cho mục đích giáo dục.

2. Current Behavior (Hành vi hiện tại)

Khi khách hàng gọi điện để khiếu nại về việc giao sai hàng, quy trình xử lý tại Nova Foods diễn ra như sau:

1. Tiếp nhận: Nhân viên CSKH nhận cuộc gọi từ khách hàng.
2. Ghi nhận thủ công: Nhân viên CSKH mở tệp Customer_Complaints_2026.xlsx (ID: NF-DOC-COMPLAINTS-2026), nhập thông tin khiếu nại (tên khách hàng, mã đơn hàng NF-ORD-YYYYMMDD-XXXX, mô tả lỗi, ngày). Không có trường chuẩn hóa cho loại lỗi hoặc sản phẩm bị ảnh hưởng.
3. Thông báo kho: Nhân viên CSKH soạn email thủ công gửi tới warehouse@novafoods.vn và support@novafoods.vn, đính kèm thông tin khiếu nại và yêu cầu kiểm tra, xử lý.
4. Phản hồi: Bộ phận kho kiểm tra thủ công lịch sử xuất hàng, sau đó phản hồi email về kết quả kiểm tra và phương án xử lý (ví dụ: giao bù, hoàn tiền).
5. Cập nhật trạng thái: Nhân viên CSKH đọc email phản hồi từ kho, sau đó cập nhật trạng thái khiếu nại (ví dụ: "Đang xử lý", "Đã xử lý") vào cột Status trong tệp Excel.
6. Thông báo khách hàng: CSKH gọi điện lại thông báo cho khách hàng về kết quả xử lý.

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

flowchart TB
    subgraph KH["Khách hàng"]
        A["Khiếu nại giao sai hàng"]
        H["Nhận thông báo kết quả"]
        I["Kết thúc quy trình khiếu nại"]
    end

    subgraph CSKH["Nhân viên CSKH"]
        B["Tiếp nhận khiếu nại"]
        C["Nhập thông tin vào Customer_Complaints_2026.xlsx"]
        D["Gửi email đến warehouse@novafoods.vn và support@novafoods.vn"]
        F["Cập nhật trạng thái khiếu nại trong cột Status"]
        G["Gọi điện thông báo kết quả cho khách hàng"]
    end

    subgraph KHO["Bộ phận kho"]
        E["Kiểm tra thủ công lịch sử xuất hàng"]
        R["Phản hồi email: kết quả kiểm tra và phương án giao bù hoặc hoàn tiền"]
    end

    A --> B
    B --> C
    C --> D
    D --> E
    E --> R
    R --> F
    F --> G
    G --> H
    H --> I

    classDef manual fill:#FFFACD,stroke:#333,stroke-width:1px,stroke-dasharray:5 5
    class C,D,E,R,F manual
    style A fill:#D0E0FF,stroke:#333,stroke-width:2px
    style I fill:#D0E0FF,stroke:#333,stroke-width:2px
    linkStyle 2,3,4,5 stroke-dasharray:5 5

• Vấn đề phát sinh từ hành vi hiện tại:
  • Tỷ lệ lỗi nhập liệu cao (ước tính 15% khiếu nại có sai sót thông tin ban đầu).
  • Thời gian xử lý kéo dài (trung bình 72 giờ), do phụ thuộc vào email và kiểm tra thủ công.
  • Khó khăn trong việc theo dõi trạng thái khiếu nại theo thời gian thực và tổng hợp báo cáo.
  • Không có công cụ tự động để phân loại loại lỗi, dẫn đến khó khăn trong việc phân tích gốc rễ.
  • Thiếu sự tích hợp giữa hệ thống ghi nhận khiếu nại (Excel) và hệ thống vận hành (NovaERP).

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

Nova Foods cần một giải pháp để tự động hóa, chuẩn hóa và tối ưu hóa quy trình quản lý khiếu nại khách hàng.

• Giảm sai sót: Đảm bảo thông tin khiếu nại được ghi nhận chính xác, tránh nhầm lẫn mã đơn hàng, sản phẩm.
• Tăng tốc độ xử lý: Rút ngắn thời gian từ khi nhận đến khi giải quyết khiếu nại.
• Minh bạch và truy vết: Mọi khiếu nại cần được theo dõi trạng thái rõ ràng, dễ dàng truy xuất lịch sử giao tiếp và hành động.
• Tích hợp dữ liệu: Kết nối thông tin khiếu nại với dữ liệu đơn hàng và sản phẩm từ NovaERP để hỗ trợ điều tra.
• Cải thiện trải nghiệm khách hàng: Cung cấp thông tin cập nhật cho khách hàng nhanh chóng, giải quyết vấn đề hiệu quả hơn.
• Phân tích và cải tiến: Thu thập dữ liệu để phân tích các loại khiếu nại phổ biến, từ đó đưa ra các cải tiến quy trình hoặc sản phẩm.

Các yêu cầu nghiệp vụ chính (Canonical Business Rules - CANONICAL_BUSINESS_RULES):

ID Yêu cầu	Mô tả Yêu cầu	Ưu tiên	Nguồn
NF-REQ-CRM-001	Hệ thống phải cho phép ghi nhận khiếu nại với các trường thông tin chuẩn hóa (mã đơn hàng, mã sản phẩm, loại khiếu nại).	Cao	Business Owner
NF-REQ-CRM-002	Hệ thống phải hiển thị trạng thái xử lý của từng khiếu nại theo thời gian thực.	Cao	Business Owner
NF-REQ-CRM-003	Hệ thống phải có khả năng tích hợp với NovaERP để lấy thông tin chi tiết đơn hàng dựa trên mã đơn hàng (NF-ORD-YYYYMMDD-XXXX).	Cao	IT Director
NF-REQ-CRM-004	Hệ thống phải tạo mã khiếu nại duy nhất và tự động (NF-COMP-YYYYMMDD-XXXX).	Trung bình	CS Manager
NF-REQ-CRM-005	Hệ thống phải có báo cáo tổng hợp về số lượng, loại và thời gian xử lý khiếu nại.	Trung bình	CS Manager

4. Options (Các lựa chọn)

Option	Tên Giải pháp	Mô tả	Ưu điểm	Nhược điểm
A	Mua Phần mềm CRM toàn diện	Triển khai một hệ thống CRM (Customer Relationship Management - Quản lý Quan hệ Khách hàng) lớn (ví dụ: Salesforce, Microsoft Dynamics) có module Service Cloud.	Giải pháp toàn diện, tính năng phong phú, hỗ trợ đa kênh.	Chi phí rất cao, thời gian triển khai dài (9-12 tháng), tích hợp phức tạp với hệ thống hiện có, đào tạo tốn kém.
B	Phát triển Module tùy chỉnh trong NovaERP	Thuê hoặc phát triển nội bộ một module quản lý khiếu nại trực tiếp trong NovaERP v3.2.	Tích hợp sâu với dữ liệu ERP, tùy chỉnh hoàn toàn theo nghiệp vụ Nova Foods.	Chi phí phát triển cao, rủi ro dự án phần mềm tùy chỉnh, cần đội ngũ phát triển mạnh, thời gian dài (6-9 tháng).
C	Cải tiến quy trình thủ công + SharePoint/Forms	Nâng cấp tệp Excel thành ứng dụng SharePoint Lists hoặc Google Forms kết hợp tự động hóa cơ bản (ví dụ: qua Power Automate).	Chi phí thấp, triển khai nhanh (1-2 tháng), tận dụng công cụ hiện có.	Khả năng mở rộng hạn chế, vẫn tồn tại nhiều bước thủ công, khó tích hợp sâu với ERP, dữ liệu phân mảnh.
D	Tích hợp Giải pháp Ticketing chuyên biệt	Triển khai một hệ thống ticketing (ví dụ: Zendesk Support, Freshdesk, Zoho Desk) và tích hợp API với NovaERP.	Chuyên biệt về quản lý ticket/khiếu nại, triển khai nhanh hơn CRM toàn diện (3-4 tháng), chi phí hợp lý.	Vẫn cần nỗ lực tích hợp với NovaERP để đồng bộ dữ liệu, có thể phát sinh chi phí API hoặc chi phí kết nối.

5. Decision Criteria (Tiêu chí quyết định)

ID Tiêu chí	Tiêu chí	Mô tả	Độ ưu tiên	Ngưỡng chấp nhận / Mục tiêu
NF-CRIT-001	Giảm thời gian xử lý	Giảm tổng thời gian trung bình từ khi nhận đến khi hoàn tất khiếu nại.	Cao	Giảm 50% (từ 72 giờ xuống 36 giờ).
NF-CRIT-002	Chi phí triển khai & vận hành (năm đầu)	Tổng chi phí cho việc mua sắm, triển khai, tích hợp và vận hành trong 12 tháng đầu tiên.	Cao	Tối đa 500.000.000 VND (bao gồm licenses, phát triển, tư vấn).
NF-CRIT-003	Khả năng tích hợp với NovaERP	Mức độ dễ dàng và hiệu quả khi tích hợp để truy xuất dữ liệu đơn hàng và khách hàng.	Cao	Phải có API (Application Programming Interface - Giao diện Lập trình Ứng dụng) hoặc cơ chế tích hợp chuẩn để tự động lấy NF-ORD-YYYYMMDD-XXXX.
NF-CRIT-004	Thời gian triển khai ban đầu	Thời gian từ khi phê duyệt đến khi hệ thống sẵn sàng hoạt động (go-live) cho module khiếu nại.	Trung bình	Tối đa 6 tháng.
NF-CRIT-005	Khả năng mở rộng	Khả năng đáp ứng khi số lượng khiếu nại tăng lên.	Trung bình	Hỗ trợ 200 khiếu nại/tuần trong vòng 3 năm tới mà không cần thay đổi kiến trúc lớn.
NF-CRIT-006	Trải nghiệm người dùng (CSKH)	Mức độ dễ sử dụng và hiệu quả cho nhân viên CSKH.	Thấp	Giảm ít nhất 30% công việc thủ công so với hiện tại.

6. Decision (Quyết định)

Quyết định được chấp thuận: Triển khai Option D: Tích hợp Giải pháp Ticketing chuyên biệt (ví dụ: Zendesk Support).

Lý do: * Đáp ứng NF-CRIT-001 (Giảm thời gian xử lý): Giải pháp chuyên biệt giúp tự động hóa phân loại, gán việc, và theo dõi trạng thái, dự kiến giảm thời gian xử lý xuống còn 24-36 giờ. * Đáp ứng NF-CRIT-002 (Chi phí): Chi phí cấp phép và tích hợp của các giải pháp ticketing thường thấp hơn đáng kể so với CRM toàn diện (Option A) hoặc phát triển tùy chỉnh (Option B), và nằm trong ngân sách 500.000.000 VND. * Đáp ứng NF-CRIT-003 (Tích hợp NovaERP): Hầu hết các hệ thống ticketing hiện đại đều có API mạnh mẽ, cho phép Nova Foods phát triển kết nối để tự động lấy thông tin đơn hàng từ NovaERP. * Đáp ứng NF-CRIT-004 (Thời gian triển khai): Thời gian triển khai dự kiến 3-4 tháng là phù hợp với mục tiêu 6 tháng. * Đáp ứng NF-CRIT-005 (Khả năng mở rộng): Các giải pháp này được thiết kế để xử lý lượng lớn ticket, dễ dàng mở rộng khi Nova Foods phát triển. * Đáp ứng NF-CRIT-006 (Trải nghiệm người dùng): Giao diện thân thiện, quy trình luân chuyển ticket rõ ràng giúp giảm gánh nặng cho CSKH.

7. Authority (Thẩm quyền)

Vai trò	Trách nhiệm	Người phê duyệt	Ngày phê duyệt	ID Phê duyệt
Đề xuất	Tổng hợp phân tích, đưa ra các lựa chọn và đề xuất quyết định.	BA, PM	2026-07-20	NF-REC-CRM-20260720-001
Phê duyệt Nghiệp vụ	Xác nhận giải pháp đáp ứng các yêu cầu nghiệp vụ và mang lại lợi ích mong muốn.	Trưởng phòng CSKH, Trưởng phòng Kinh doanh	2026-08-07	NF-APPR-BIZ-20260807-001
Phê duyệt Kỹ thuật	Xác nhận tính khả thi kỹ thuật, khả năng tích hợp và kiến trúc giải pháp.	Giám đốc IT	2026-08-07	NF-APPR-IT-20260807-002
Phê duyệt Ngân sách	Xác nhận chi phí phù hợp với ngân sách dự án đã được phân bổ.	Giám đốc Tài chính	2026-08-07	NF-APPR-FIN-20260807-003

8. Artifact (Sản phẩm đầu ra)

Sau quyết định, các sản phẩm (artifact) BA cần tạo hoặc cập nhật bao gồm:

• Tài liệu Đặc tả Yêu cầu (Requirement Specification Document): NF-SRS-CRM-001-v1.0. Chi tiết các yêu cầu NF-REQ-CRM-001 đến NF-REQ-CRM-005 và các yêu cầu phi chức năng.
• Tài liệu Thiết kế Giải pháp (Solution Design Document): NF-SDS-CRM-001-v1.0. Mô tả kiến trúc tổng thể, lựa chọn hệ thống ticketing, và cách thức hoạt động.
• Tài liệu Thiết kế Tích hợp (Integration Design Document): NF-IDD-CRM-001-v1.0. Đặc tả chi tiết về API giữa hệ thống ticketing và NovaERP (ví dụ: định dạng payload JSON, endpoint, cơ chế xác thực).
• Kế hoạch Kiểm thử (Test Plan): NF-TP-CRM-001-v1.0. Bao gồm các kịch bản kiểm thử chức năng, kiểm thử tích hợp, kiểm thử hiệu năng cho module khiếu nại mới.
• Wireframes/Mockups: Bản nháp giao diện cho nhân viên CSKH khi sử dụng hệ thống ticketing mới.

9. Consequence if Wrong (Hậu quả nếu sai)

• Nếu lựa chọn giải pháp không phù hợp (ví dụ: chọn Option C):

  • Hiệu quả thấp: Các vấn đề về sai sót nhập liệu, thời gian xử lý chậm không được cải thiện đáng kể.
  • Khả năng mở rộng kém: Khi số lượng khiếu nại tăng, hệ thống nhanh chóng quá tải, buộc phải thay thế sớm, gây lãng phí đầu tư ban đầu.
  • Ảnh hưởng khách hàng: Khách hàng không hài lòng, có thể chuyển sang đối thủ cạnh tranh.
  • Ảnh hưởng nội bộ: Nhân viên CSKH tiếp tục chịu áp lực công việc thủ công, tinh thần giảm sút.

• Nếu quá trình tích hợp gặp lỗi:

  • Dữ liệu không đồng bộ: CSKH phải tra cứu thông tin đơn hàng thủ công trên NovaERP và nhập lại vào hệ thống ticketing, mất đi lợi ích tự động hóa.
  • Chất lượng dịch vụ giảm: Sai sót thông tin trong quá trình tích hợp dẫn đến giải quyết khiếu nại sai, làm giảm uy tín Nova Foods.

• Nếu không có sự phê duyệt đúng thẩm quyền hoặc không ghi nhận artifact:

  • Thiếu minh bạch: Quyết định không có căn cứ rõ ràng, khó giải trình khi có vấn đề.
  • Rủi ro tuân thủ: Không có tài liệu chứng minh quá trình ra quyết định, gây khó khăn khi cần kiểm tra nội bộ hoặc bên ngoài.
  • Mất kiểm soát: Thiếu các sản phẩm đầu ra chuẩn hóa (ví dụ: tài liệu yêu cầu, thiết kế) dẫn đến hiểu sai yêu cầu, phát triển sai chức năng, hoặc kiểm thử không đầy đủ.

Senior Lens

Với một BA cấp cao, việc thực hiện chuỗi tư duy từ Facts đến Consequence if Wrong không chỉ là một bài tập, mà là một quy trình kiểm soát chất lượng và giảm thiểu rủi ro toàn diện.

1. Toàn cảnh: BA cấp cao luôn xem xét vấn đề trong bối cảnh rộng hơn của chiến lược công ty. Ví dụ, quyết định về hệ thống khiếu nại không chỉ là về CSKH mà còn ảnh hưởng đến danh tiếng, khả năng giữ chân khách hàng và dữ liệu cho phân tích sản phẩm.
2. Quản lý kỳ vọng: Rõ ràng về các Options và Decision Criteria giúp quản lý kỳ vọng của các bên liên quan, tránh những bất ngờ về chi phí, thời gian hoặc tính năng. Việc phân biệt Recommendation và Authorized Decision là cực kỳ quan trọng để tránh BA bị đổ lỗi cho các quyết định ngoài thẩm quyền.
3. Tối ưu hóa nguồn lực: Một BA cấp cao sẽ tìm kiếm giải pháp hiệu quả nhất về chi phí và thời gian, không nhất thiết là giải pháp có nhiều tính năng nhất. Option D là một ví dụ về việc chọn giải pháp cân bằng, chuyên biệt thay vì CRM "đao to búa lớn" (Option A) hoặc phát triển "xe lăn lại bánh xe" (Option B).
4. Minh bạch rủi ro: Mục Consequence if Wrong không phải để đổ lỗi mà để phòng ngừa. Nó buộc BA phải nghĩ về các kịch bản xấu nhất và cách giảm thiểu chúng trong quá trình thiết kế và triển khai, ví dụ, thông qua kế hoạch kiểm thử kỹ lưỡng cho tích hợp.
5. Truy vết (Traceability): Mỗi bước trong chuỗi này đều tạo ra bằng chứng và điểm truy vết. Từ NF-REQ-CRM-001 trong Underlying Need đến NF-SRS-CRM-001-v1.0 trong Artifact, mọi thứ phải liên kết với nhau, đảm bảo không có yêu cầu nào bị bỏ sót và mọi quyết định đều có cơ sở.

Quick Reference

Bước	Mục tiêu	Sản phẩm đầu ra chính
Facts	Thu thập dữ kiện không thể chối cãi	Bảng dữ kiện, thông số
Current Behavior	Hiểu cách hệ thống/quy trình đang hoạt động	Sơ đồ luồng (Mermaid), mô tả quy trình
Underlying Need	Xác định vấn đề cốt lõi, không phải giải pháp	Danh sách yêu cầu nghiệp vụ (NF-REQ-CRM-NNN)
Options	Liệt kê các cách tiếp cận có thể	Bảng so sánh lựa chọn (Ưu/Nhược điểm)
Decision Criteria	Các yếu tố dùng để đánh giá lựa chọn	Bảng tiêu chí với ngưỡng/mục tiêu (NF-CRIT-NNN)
Decision	Quyết định giải pháp được chọn	Tuyên bố quyết định, lý do
Authority	Ai chịu trách nhiệm phê duyệt	Bảng vai trò, người phê duyệt, ID phê duyệt
Artifact	Sản phẩm tài liệu tạo ra	Danh sách tài liệu (SRS, SDS, IDD, TP)
Consequence if Wrong	Hậu quả nếu lựa chọn sai	Mô tả rủi ro, tác động xấu

Định nghĩa Artifact cho Ví dụ Cụ thể: Cập nhật Trạng thái Đơn hàng Giao hàng

1. Sơ đồ Trạng thái Đơn hàng Giao hàng (Delivery Order State Diagram)

Sơ đồ trạng thái (state diagram) trực quan hóa các trạng thái (status) mà một đơn hàng giao hàng (delivery order) tại Nova Foods có thể trải qua và các chuyển đổi (transition) hợp lệ giữa chúng. Đây là bước đầu để hiểu luồng nghiệp vụ.

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

stateDiagram-v2
    direction TB
    [*] --> CREATED: Đơn hàng được tạo
    CREATED --> PENDING_PICKUP: Yêu cầu giao hàng được tạo
    PENDING_PICKUP --> PICKED_UP: Tài xế xác nhận đã nhận hàng
    PICKED_UP --> IN_TRANSIT: Bắt đầu vận chuyển
    IN_TRANSIT --> DELIVERED: Giao hàng thành công
    IN_TRANSIT --> DELIVERY_FAILED: Giao hàng thất bại
    DELIVERY_FAILED --> PENDING_REATTEMPT: Xử lý giao lại
    DELIVERY_FAILED --> [*]: Không giao lại
    PENDING_REATTEMPT --> IN_TRANSIT: Thử giao lại
    PENDING_REATTEMPT --> [*]: Không giao lại
    CREATED --> CANCELLED: Khách hàng hủy
    PENDING_PICKUP --> CANCELLED: Khách hàng hủy
    PICKED_UP --> CANCELLED: Khách hàng hủy
    DELIVERED --> [*]
    CANCELLED --> [*]

Ghi chú: Sơ đồ này là Đề xuất từ Business Analyst (BA) để hình dung luồng. Quyết định cuối cùng về tập hợp trạng thái và chuyển đổi hợp lệ sẽ do Business Owner (Chủ nghiệp vụ) phê duyệt, đảm bảo phù hợp với chính sách vận hành của Nova Foods.

2. Lược đồ Dữ liệu (Payload Schema) Cập nhật Trạng thái Đơn hàng

Lược đồ (schema) này định nghĩa cấu trúc dữ liệu (payload) được gửi qua API (Application Programming Interface - Giao diện lập trình ứng dụng) từ ứng dụng của tài xế Nova Foods khi cập nhật trạng thái đơn hàng. Dữ liệu này được định dạng theo JSON (JavaScript Object Notation).

Trường (Field)	Kiểu dữ liệu (Data Type)	Bắt buộc (Required)	Mô tả (Description)	ID Canonical (Traceability)
orderId	Chuỗi (String)	Có	Định danh duy nhất của đơn hàng giao hàng Nova Foods. (VD: NF-DEL-ORD-20260807-000001)	BR-NF-DD-ORDERID
driverId	Chuỗi (String)	Có	Định danh duy nhất của tài xế thực hiện giao hàng. (VD: NF-DRV-007)	BR-NF-DD-DRIVERID
oldStatus	Chuỗi enum (String Enum)	Có	Trạng thái hiện tại của đơn hàng trước khi cập nhật. Phải khớp với trạng thái ghi nhận trong hệ thống Nova Foods.	BR-NF-DD-OLDSTATUS
newStatus	Chuỗi enum (String Enum)	Có	Trạng thái mới của đơn hàng Nova Foods. Phải là một chuyển đổi hợp lệ theo các quy tắc nghiệp vụ.	BR-NF-DD-NEWSTATUS
timestamp	ISO 8601 DateTime	Có	Thời điểm chính xác cập nhật trạng thái, theo múi giờ Asia/Ho_Chi_Minh.	BR-NF-DD-TIMESTAMP
location	Đối tượng (Object)	Có	Vị trí địa lý của tài xế Nova Foods tại thời điểm cập nhật.	BR-NF-DD-LOCATION
location.latitude	Số thực (Float)	Có	Vĩ độ của vị trí. (VD: 10.762622)	BR-NF-DD-LOCATION-LAT
location.longitude	Số thực (Float)	Có	Kinh độ của vị trí. (VD: 106.660172)	BR-NF-DD-LOCATION-LONG
notes	Chuỗi (String)	Không	Ghi chú bổ sung từ tài xế hoặc hệ thống Nova Foods. (VD: "Khách hàng không có mặt")	BR-NF-DD-NOTES

Ghi chú: Lược đồ dữ liệu này là Đề xuất ban đầu từ BA. Lược đồ cuối cùng và chi tiết kỹ thuật sẽ được Tech Lead (Trưởng nhóm kỹ thuật) và System Architect (Kiến trúc sư hệ thống) của Nova Foods Quyết định sau khi đánh giá các yêu cầu về tính toàn vẹn, hiệu suất và khả năng truy xuất dữ liệu.

3. Các Quy tắc Nghiệp vụ (Business Rules) cho Chuyển đổi Trạng thái Đơn hàng

Các quy tắc nghiệp vụ (business rules) này điều chỉnh và kiểm soát tính hợp lệ của các chuyển đổi trạng thái đơn hàng trong hệ thống Nova Foods. Mọi cập nhật trạng thái phải tuân thủ các quy tắc này.

ID Quy tắc (Rule ID)	Mô tả Quy tắc (Rule Description)	Tham chiếu Nguồn (Source Ref)	Trạng thái
BR-NF-DELIVERY-TRANS-001	Đơn hàng Nova Foods chỉ có thể chuyển từ trạng thái READY_FOR_DELIVERY sang IN_TRANSIT nếu tài xế được chỉ định đã xác nhận nhận đơn và bắt đầu di chuyển từ điểm xuất phát.	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Đã Quyết định (Business Owner: Nguyễn Thị Thanh, 2026-08-01)
BR-NF-DELIVERY-TRANS-002	Đơn hàng Nova Foods không được phép chuyển trực tiếp từ trạng thái DELIVERED về IN_TRANSIT. Mọi trường hợp cần giao lại hoặc xử lý sau giao hàng thành công phải theo luồng nghiệp vụ riêng qua DELIVERY_FAILED hoặc PENDING_REATTEMPT.	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Đã Quyết định (Business Owner: Nguyễn Thị Thanh, 2026-08-01)
BR-NF-DELIVERY-TRANS-003	Tài xế Nova Foods chỉ được phép cập nhật trạng thái của những đơn hàng được giao cho chính họ. Việc này yêu cầu xác thực driverId với orderId trong hệ thống.	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Đã Quyết định (Security Lead: Lê Văn Bảo, 2026-08-03)
BR-NF-DELIVERY-TRANS-004	Thông tin vị trí địa lý (location) là bắt buộc khi tài xế cập nhật trạng thái đơn hàng sang IN_TRANSIT hoặc DELIVERED. Nếu thiếu, hệ thống Nova Foods từ chối cập nhật.	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Đã Quyết định (Operations Lead: Trần Minh Đức, 2026-08-02)

Ghi chú: Các quy tắc nghiệp vụ trên là các Quyết định đã được phê duyệt bởi các vai trò có thẩm quyền (Chủ nghiệp vụ, Trưởng nhóm An ninh, Trưởng nhóm Vận hành) trong bối cảnh Nova Foods mô phỏng.

4. Ví dụ Kịch bản Cập nhật Trạng thái (Scenario Example)

Đây là một ví dụ cụ thể, sử dụng dữ liệu tổng hợp, minh họa cách một payload JSON sẽ được gửi để cập nhật trạng thái đơn hàng Nova Foods từ READY_FOR_DELIVERY sang IN_TRANSIT.

Kịch bản: Tài xế NF-DRV-007 của Nova Foods bắt đầu giao đơn hàng NF-DEL-ORD-20260807-000001. Trạng thái của đơn hàng chuyển từ READY_FOR_DELIVERY sang IN_TRANSIT vào lúc 2026-08-07T10:30:00+07:00 (giờ TP.HCM), tại vị trí hiện tại của tài xế là 10.762622 vĩ độ và 106.660172 kinh độ.

{
  "orderId": "NF-DEL-ORD-20260807-000001",
  "driverId": "NF-DRV-007",
  "oldStatus": "READY_FOR_DELIVERY",
  "newStatus": "IN_TRANSIT",
  "timestamp": "2026-08-07T10:30:00+07:00",
  "location": {
    "latitude": 10.762622,
    "longitude": 106.660172
  },
  "notes": "Tài xế bắt đầu giao hàng, điều kiện đường tốt"
}

Ghi chú: Kịch bản và payload mẫu này là Minh họa cho cấu trúc và loại dữ liệu được sử dụng. Các giá trị thực tế của orderId, driverId, timestamp, và location sẽ thay đổi theo từng sự kiện cập nhật trạng thái trong môi trường Nova Foods.

9. Related Concepts & Dependencies

Core

Dependency (phụ thuộc) nghĩa là một artifact, thông tin, hoặc khái niệm cần thứ khác để tồn tại, hoàn thành, hoặc có ý nghĩa. Delivery Pack này cũng có các phụ thuộc. Có hai loại chính: Upstream (thượng nguồn) và Downstream (hạ nguồn).

Upstream là những gì Delivery Pack cần làm đầu vào. Delivery Pack lấy thông tin từ upstream. Ví dụ: các quy định pháp luật, chuẩn ngành, hoặc các artifact khác như Business Rules.

Downstream là những gì Delivery Pack tạo ra hoặc ảnh hưởng. Các artifact downstream sử dụng Delivery Pack làm đầu vào. Ví dụ: tài liệu kiểm thử, hướng dẫn đào tạo, hoặc các template mới.

Hiểu rõ dependency quan trọng. Giúp biết thay đổi một nơi ảnh hưởng chỗ nào. Giúp tránh làm lại việc (duplication) hoặc mâu thuẫn thông tin (inconsistency). Giúp BA quản lý scope và change hiệu quả.

Applied

Facts: 23 Capstone Nova Foods Delivery Pack (Gói Giao Hàng Nova Foods) là một tài liệu tổng hợp. Tài liệu này cần thông tin từ nhiều nguồn và tạo ra đầu ra cho nhiều tài liệu khác trong dự án Nova Foods mô phỏng. Các nguồn này có ID riêng, phiên bản riêng.

Current Behavior: Không có danh sách phụ thuộc rõ ràng. Nếu nguồn thay đổi, Delivery Pack có thể không còn đúng. BA khó biết khi nào cần cập nhật.

Underlying Need: Cần danh sách rõ ràng các upstream và downstream dependency. Điều này đảm bảo Delivery Pack luôn dựa trên thông tin chính xác, cập nhật. Giúp BA đánh giá tác động thay đổi nhanh.

Options: 1. Không ghi nhận: Rủi ro cao, không biết khi nào thông tin lỗi thời. FAIL. 2. Ghi chú tùy tiện: Thiếu chuẩn, khó theo dõi, dễ bỏ sót. UNRELIABLE. 3. Sử dụng bảng dependency có cấu trúc: Rõ ràng, dễ truy vết, quản lý thay đổi tốt. RELIABLE.

Decision Criteria: Tính toàn vẹn dữ liệu, khả năng truy vết, quản lý tác động thay đổi, giảm thiểu lỗi, hiệu quả công việc.

Decision: Dùng bảng dependency có cấu trúc. Liệt kê rõ ràng ID, đường dẫn canonical, và lý do phụ thuộc.

Authority: Principal IT Business Analyst / Technical Curriculum Author (tôi), với vai trò định hình curriculum.

Artifact: Bảng "Sơ đồ Phụ thuộc cho 23 Capstone Nova Foods Delivery Pack" (xem phần Quick Reference).

Consequence if Wrong: Delivery Pack chứa thông tin lỗi thời hoặc mâu thuẫn. Các tài liệu downstream cũng sai. Learner học kiến thức không chính xác. Mất thời gian khắc phục.

Senior Lens

Delivery Pack không tự tạo ra thông tin. Nó tổng hợp và diễn giải. Canonical sources of truth (nguồn chân lý) là nơi duy nhất giữ thông tin gốc. BA không được duplicate (nhân bản) các nguồn này. Thay vào đó, BA phải reference (tham chiếu) chúng bằng ID và đường dẫn canonical.

Ví dụ, không viết lại "Luật Bảo vệ dữ liệu cá nhân". Chỉ cần tham chiếu Luật này là upstream dependency. Khi Luật thay đổi, BA kiểm tra tác động đến Delivery Pack. Nếu dependency không rõ, thay đổi ngầm (silent change) một nguồn có thể phá vỡ logic trong Delivery Pack mà không ai biết. Điều này dẫn đến inconsistency (mâu thuẫn) và non-compliance (không tuân thủ).

Mọi Artifact ID từ các manifest (00_SOURCE_MAP, CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY) đều là persistent ID (ID bền vững). Chúng không thay đổi. Luôn dùng các ID này để liên kết.

Quick Reference

Sơ đồ Phụ thuộc cho 23 Capstone Nova Foods Delivery Pack

Dưới đây là sơ đồ và bảng liệt kê các phụ thuộc (dependencies) chính của 23-capstone-nova-foods-delivery-pack.md.

graph TD
    subgraph Upstream Concepts (Khái niệm Thượng nguồn)
        C1[BABOK Guide]
        C2[Luật Bảo vệ dữ liệu cá nhân]
        C3[ISO/IEC/IEEE 29148]
        C4[OWASP ASVS]
        C5[OpenAPI Specification]
    end

    subgraph Upstream Artifacts (Artifact Thượng nguồn)
        A1[/00-research/00_SOURCE_MAP.md]
        A2[/01-curriculum/01_CURRICULUM_ARCHITECTURE.md]
        A3[/01-curriculum/CHAPTER_MANIFEST.md]
        A4[/01-curriculum/TEMPLATE_MANIFEST.md]
        A5[/01-curriculum/TRACEABILITY_ID_REGISTRY.md]
        A6[/01-curriculum/CANONICAL_BUSINESS_RULES.md]
        A7[/01-curriculum/CANONICAL_DATA_DICTIONARY.md]
    end

    C1 --> DP
    C2 --> DP
    C3 --> DP
    C4 --> DP
    C5 --> DP

    A1 --> DP
    A2 --> DP
    A3 --> DP
    A4 --> DP
    A5 --> DP
    A6 --> DP
    A7 --> DP

    DP((23 Capstone Nova Foods Delivery Pack))

    subgraph Downstream Artifacts (Artifact Hạ nguồn)
        D1[Các Template - /03-templates/]
        D2[Các Cheatsheet - /04-cheatsheets/]
        D3[Các Artifact QA - /06-qa/]
        D4[Tài liệu Đào tạo Người dùng]
        D5[Hướng dẫn Triển khai]
    end

    DP --> D1
    DP --> D2
    DP --> D3
    DP --> D4
    DP --> D5

Bảng Phụ thuộc của 23 Capstone Nova Foods Delivery Pack

Loại Phụ Thuộc	ID / Tên Artifact (nếu có)	Đường dẫn Canonical / URL	Mô tả Liên quan đến 23 Capstone Nova Foods Delivery Pack	Lý do Phụ Thuộc
Khái niệm Thượng nguồn	BABOK Guide	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Cung cấp các khung kiến thức, kỹ thuật, và nhiệm vụ của Business Analyst (Chuyên viên Phân tích Nghiệp vụ).	Delivery Pack áp dụng phương pháp luận BA chuẩn.
Khái niệm Thượng nguồn	Luật Bảo vệ dữ liệu cá nhân	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	Định hướng các yêu cầu pháp lý về xử lý dữ liệu cá nhân cho hệ thống mô phỏng Nova Foods.	Tuân thủ pháp luật là bắt buộc; ảnh hưởng thiết kế hệ thống.
Khái niệm Thượng nguồn	ISO/IEC/IEEE 29148	https://www.iso.org/standard/72089.html	Cung cấp tiêu chuẩn quốc tế về quy trình kỹ thuật yêu cầu (requirements engineering).	Delivery Pack tuân thủ tiêu chuẩn kỹ thuật yêu cầu.
Khái niệm Thượng nguồn	OWASP ASVS	https://owasp.org/www-project-application-security-verification-standard/	Tiêu chuẩn kiểm thử và xác minh bảo mật ứng dụng.	Delivery Pack có thể định hình yêu cầu bảo mật.
Khái niệm Thượng nguồn	OpenAPI Specification	https://spec.openapis.org/oas/v3.1.1.html	Đặc tả chuẩn để mô tả các API REST.	Delivery Pack có thể chứa đặc tả API cho Nova Foods.
Artifact Thượng nguồn	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Danh mục các nguồn tài liệu chính thức, đã xác minh của corpus.	Đảm bảo Delivery Pack tham chiếu nguồn đáng tin cậy.
Artifact Thượng nguồn	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Cấu trúc tổng thể của toàn bộ chương trình học.	Delivery Pack là một thành phần trong kiến trúc này.
Artifact Thượng nguồn	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Danh sách và metadata (siêu dữ liệu) của các chapter handbook.	Xác định vị trí, số thứ tự, và liên kết của Delivery Pack.
Artifact Thượng nguồn	TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Danh sách các template (mẫu tài liệu) tiêu chuẩn.	Delivery Pack có thể sử dụng template và định nghĩa template mới.
Artifact Thượng nguồn	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Registry định nghĩa các ID duy nhất (ví dụ: BR-, REQ-, AC-).	Đảm bảo tính nhất quán của ID và khả năng truy vết trong Delivery Pack.
Artifact Thượng nguồn	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Catalog các quy tắc nghiệp vụ chuẩn của Nova Foods mô phỏng.	Delivery Pack diễn giải và áp dụng các quy tắc này vào thiết kế.
Artifact Thượng nguồn	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Từ điển định nghĩa dữ liệu logic chuẩn của Nova Foods mô phỏng.	Delivery Pack sử dụng các định nghĩa dữ liệu này trong đặc tả.
Artifact Hạ nguồn	Các Template	/03-templates/ (folder)	Các template cụ thể (ví dụ: NF-TMPL-TESTPLAN.md, NF-TMPL-DEPLGUIDE.md).	Delivery Pack là nguồn gốc cho việc tạo và tùy chỉnh các template này.
Artifact Hạ nguồn	Các Cheatsheet	/04-cheatsheets/ (folder)	Các tài liệu tóm tắt nhanh, hướng dẫn ngắn gọn.	Delivery Pack là nguồn thông tin để tạo các cheatsheet.
Artifact Hạ nguồn	Các Artifact QA	/06-qa/ (folder)	Test cases (ca kiểm thử), test plans (kế hoạch kiểm thử), test data (dữ liệu kiểm thử).	Delivery Pack cung cấp cơ sở để thiết kế và thực hiện QA.
Artifact Hạ nguồn	Tài liệu Đào tạo Người dùng	/02-handbook/ (khác)	Hướng dẫn sử dụng hệ thống Nova Foods cho người dùng cuối.	Delivery Pack là nguồn cho nội dung đào tạo vận hành.
Artifact Hạ nguồn	Hướng dẫn Triển khai	(TBD, có thể trong /03-templates/ hoặc riêng)	Tài liệu kỹ thuật chi tiết cho quá trình triển khai hệ thống Nova Foods.	Delivery Pack là nguồn cho các bước và yêu cầu triển khai.

Bảng Truy Vết và Phụ Thuộc (Dependency & Traceability Table)

### Core

Truy vết (Traceability) là khả năng theo dõi một yêu cầu (Requirement) từ nguồn gốc đến triển khai, kiểm thử, và ngược lại. Bảng truy vết (Traceability Table) tài liệu hóa mối quan hệ giữa các thành phần. Nó giúp BA hiểu tác động thay đổi, đảm bảo mọi phần đều có chủ đích.

Loại liên kết phổ biến: * NEED (Nhu cầu nghiệp vụ): Mục tiêu kinh doanh tổng thể. Lý do gốc tồn tại của yêu cầu. * REQ (Yêu cầu): Điều hệ thống phải làm. Mô tả chức năng hoặc phi chức năng. * BR (Quy tắc nghiệp vụ): Logic ràng buộc hoặc điều kiện. Cách hệ thống phản ứng với dữ liệu hoặc sự kiện. * AC (Tiêu chí chấp nhận): Điều kiện phải thỏa mãn để xác nhận yêu cầu hoàn thành. Kiểm tra yêu cầu. * DATA/API (Dữ liệu/API): Các trường dữ liệu, cấu trúc hoặc giao diện lập trình. Nguồn hoặc đích của thông tin. * TC (Kịch bản kiểm thử): Các bước để xác minh tiêu chí chấp nhận. Xác nhận chức năng.

Bảng truy vết không lặp lại nội dung nguồn chân lý. Nó chỉ liên kết đến các ID, đường dẫn tệp và phiên bản đã được kiểm soát.

### Applied

Facts: Nova Foods ERP là mô phỏng. Tài liệu hướng dẫn này (23 Capstone Nova Foods Delivery Pack) là học liệu. Phần "Related Concepts & Dependencies" (mục 9) cần lập bản đồ các phụ thuộc của chính nó. Current Behavior: Không có bảng truy vết, nội dung trong tài liệu hướng dẫn có thể lỗi thời khi các artifact nguồn thay đổi. Người học không thấy rõ cơ sở lý luận cho từng phần. Underlying Need: Cần cơ chế rõ ràng liên kết nội dung học liệu với các artifact gốc (kiến trúc, manifest, registry). Đảm bảo tính nhất quán và dễ dàng bảo trì curriculum. Options: 1. Mô tả bằng văn xuôi: Khó cập nhật, thiếu cấu trúc. 2. Công cụ chuyên dụng (ví dụ: ALM tool): Quá mức cho một tài liệu tĩnh. 3. Bảng Markdown đơn giản: Dễ đọc, dễ viết, phù hợp cho mục đích học liệu. Decision Criteria: Ưu tiên đơn giản, dễ hiểu cho người học mới, dễ bảo trì cho tác giả, không yêu cầu công cụ mới. Decision: Sử dụng bảng Markdown nội tuyến. Authority: Principal IT Business Analyst / Technical Curriculum Author (chúng ta). Artifact: Bảng truy vết mẫu dưới đây. Consequence if Wrong: Nội dung không nhất quán, khó cập nhật, người học không tin tưởng vào tính chính xác của học liệu.

Mermaid: Cấu trúc phụ thuộc của nội dung (Phần 9: Related Concepts & Dependencies) đến các artifact curriculum upstream.

graph TD
    subgraph "Tài liệu Capstone (23-capstone-nova-foods-delivery-pack.md)"
        A[Phần 9: Related Concepts & Dependencies]
    end

    subgraph "Các Artifact Curriculum Upstream"
        B[/00-research/00_SOURCE_MAP.md]
        C[/01-curriculum/01_CURRICULUM_ARCHITECTURE.md]
        D[/01-curriculum/CHAPTER_MANIFEST.md]
        E[/01-curriculum/TEMPLATE_MANIFEST.md]
        F[/01-curriculum/TRACEABILITY_ID_REGISTRY.md]
        G[/01-curriculum/CANONICAL_BUSINESS_RULES.md]
        H[/01-curriculum/CANONICAL_DATA_DICTIONARY.md]
    end

    A --> F: Tham chiếu cấu trúc ID
    A --> D: Danh sách chương
    A --> C: Kiến trúc tổng thể
    A --> E: Danh sách template
    A --> B: Nguồn gốc tham chiếu
    A --> G: Quy tắc nghiệp vụ liên quan
    A --> H: Từ điển dữ liệu liên quan

Bảng Truy Vết Nội Dung Phần 9 – 23 Capstone Nova Foods Delivery Pack

Mã mục hiện tại (ID)	Loại mục	Mô tả mục	Liên kết đến ID	Loại liên kết đến	Mục đích liên kết	Artifact Nguồn
PACK-23-09-RC-MAP	REQ	Yêu cầu lập bản đồ concept thượng/hạ nguồn	01_CURRICULUM_ARCHITECTURE	CURR_ARCH	Tham chiếu cấu trúc tổng thể curriculum	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md
PACK-23-09-RC-MAP	REQ	Yêu cầu lập bản đồ concept thượng/hạ nguồn	CHAPTER_MANIFEST	CHAPTER_REG	Danh sách chapter, ID chapter	/01-curriculum/CHAPTER_MANIFEST.md
PACK-23-09-RC-MAP	REQ	Yêu cầu lập bản đồ concept thượng/hạ nguồn	TEMPLATE_MANIFEST	TEMPLATE_REG	Danh sách template, ID template	/01-curriculum/TEMPLATE_MANIFEST.md
PACK-23-09-RC-TBL	REQ	Yêu cầu cung cấp bảng truy vết (mục hiện tại)	TRACEABILITY_ID_REGISTRY	REGISTRY	Tham chiếu định dạng ID chuẩn cho truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md
PACK-23-09-RC-TBL	REQ	Yêu cầu cung cấp bảng truy vết (mục hiện tại)	CANONICAL_BUSINESS_RULES	RULE_CAT	Xác định loại BR có thể liên kết	/01-curriculum/CANONICAL_BUSINESS_RULES.md
PACK-23-09-RC-TBL	REQ	Yêu cầu cung cấp bảng truy vết (mục hiện tại)	CANONICAL_DATA_DICTIONARY	DATA_DICT	Xác định loại DATA/API có thể liên kết	/01-curriculum/CANONICAL_DATA_DICTIONARY.md
PACK-23-09-RC-PROP	REQ	Yêu cầu giải thích lan truyền thay đổi	00_SOURCE_MAP	SOURCE_MAP	Nguồn tài liệu được tham chiếu có thể thay đổi	/00-research/00_SOURCE_MAP.md

### Senior Lens

Thay đổi ngầm (silent change) là rủi ro lớn. Nguồn chân lý thay đổi, nhưng tài liệu phụ thuộc không được cập nhật. Kết quả là thông tin lỗi thời, mâu thuẫn. Bảng truy vết hành động như một bức tường phòng thủ. Khi artifact 01_CURRICULUM_ARCHITECTURE phiên bản v0.9.0 đổi, bảng này cho thấy mục nào trong Delivery Pack cần kiểm tra. Không có truy vết, mỗi thay đổi thượng nguồn đòi hỏi rà soát thủ công, tốn thời gian, dễ sai sót. Duy trì bảng truy vết là đầu tư vào chất lượng và khả năng bảo trì nội dung dài hạn.

### Quick Reference

Bảng truy vết liên kết nội dung Capstone Pack với nguồn gốc curriculum. Giúp quản lý phụ thuộc, hiểu tác động thay đổi, đảm bảo tính chính xác. Sử dụng ID chuẩn, đường dẫn canonical. Phòng ngừa rủi ro thay đổi ngầm.

Lan Truyền Thay Đổi Ngầm Và Hậu Quả

Core

Thay đổi lan truyền (change propagation) là hiện tượng khi một điều chỉnh ở một phần hệ thống hoặc nghiệp vụ gây ra ảnh hưởng đến các phần khác. Thay đổi phụ thuộc ngầm (silent dependency change) xảy ra khi một thành phần bị thay đổi mà không thông báo hoặc không được ghi nhận trong các hệ thống liên quan, khiến các thành phần phụ thuộc bị hỏng hoặc hoạt động sai. Nguyên nhân gốc là thiếu nhận biết, thiếu quản lý cấu hình (configuration management), hoặc thiếu truy vết (traceability) giữa các yêu cầu, quy tắc và thành phần hệ thống.

Applied

Nova Foods sử dụng quy tắc giá vận chuyển dựa trên khu vực giao hàng và trọng lượng.

Facts: * BR-NF-LOG-001: Giá vận chuyển tiêu chuẩn cho Quận 1, TP.HCM là 20.000 VND/đơn hàng. * API-NF-SHIP-SVC-001: API Dịch vụ Vận chuyển tính phí dựa trên BR-NF-LOG-001. * APP-NF-ORDER-001: Ứng dụng Đặt hàng gọi API-NF-SHIP-SVC-001 để hiển thị phí.

Current Behavior: Đội logistics quyết định thay đổi BR-NF-LOG-001 thành Giá vận chuyển tiêu chuẩn cho Quận 1, TP.HCM là 25.000 VND/đơn hàng. Thay đổi này được cập nhật trong tài liệu nội bộ của logistics, nhưng không được ghi nhận trong /01-curriculum/CANONICAL_BUSINESS_RULES.md và không thông báo cho đội phát triển phần mềm. API-NF-SHIP-SVC-001 vẫn trả về 20.000 VND.

Underlying Need: Đảm bảo rằng mọi thay đổi nghiệp vụ ảnh hưởng đến hệ thống đều được truyền đạt, ghi nhận và đồng bộ giữa các bên liên quan và các thành phần hệ thống. Tránh sai lệch giữa nghiệp vụ thực tế và hoạt động phần mềm.

Options: 1. Thông báo thủ công: Logistics gửi email, nhưng dễ bỏ sót người hoặc hệ thống liên quan. 2. Quản lý quy tắc tập trung: Mọi Business Rule (quy tắc nghiệp vụ) phải được quản lý trong /01-curriculum/CANONICAL_BUSINESS_RULES.md với version và các liên kết phụ thuộc thông qua /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Hệ thống phụ thuộc tự động hoặc thủ công kiểm tra cập nhật. 3. Hợp đồng API rõ ràng: API Dịch vụ Vận chuyển có hợp đồng (contract) versioned, và mọi thay đổi giá phải tạo version API mới.

Decision Criteria: * Tính toàn vẹn dữ liệu (Data Integrity): Đảm bảo quy tắc nghiệp vụ áp dụng nhất quán. * Truy vết (Traceability): Dễ dàng tìm thấy ai, khi nào, tại sao thay đổi. * Khả năng mở rộng (Scalability): Dễ quản lý khi số lượng quy tắc và hệ thống tăng. * Giảm rủi ro (Risk Reduction): Hạn chế sai sót do thông tin cũ.

Decision: Nova Foods chọn Option 2: Quản lý quy tắc tập trung. Mọi thay đổi Business Rule phải được ghi nhận tại /01-curriculum/CANONICAL_BUSINESS_RULES.md và các dependency được ánh xạ qua /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Quy trình thay đổi bao gồm bước thông báo chính thức đến các bên liên quan và xác minh các hệ thống phụ thuộc.

Authority: Business Owner (Logistics) phê duyệt thay đổi quy tắc. Principal IT Business Analyst ghi nhận thay đổi, cập nhật truy vết và thông báo. Technical Lead xác minh ảnh hưởng đến hệ thống.

Artifact: * /01-curriculum/CANONICAL_BUSINESS_RULES.md (chứa BR-NF-LOG-001 bản mới). * /01-curriculum/TRACEABILITY_ID_REGISTRY.md (ghi nhận API-NF-SHIP-SVC-001 phụ thuộc BR-NF-LOG-001).

Consequence if Wrong: * Nova Foods mất doanh thu do API-NF-SHIP-SVC-001 tính phí vận chuyển thấp hơn thực tế. * Khách hàng có thể bị yêu cầu trả thêm tiền khi nhận hàng, gây mất uy tín. * Sai lệch tài chính giữa doanh thu và chi phí vận chuyển thực tế.

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

sequenceDiagram
    autonumber
    participant BO as "Business Owner (Logistics)"
    participant BA as "Principal IT Business Analyst"
    participant CBR as "Canonical Business Rules (CBR)"
    participant TIR as "Traceability ID Registry (TIR)"
    participant TL as "Technical Lead"
    participant Dev as "SSAPI Development Team"
    participant SSAPI as "Shipping Service API (SSAPI)"
    participant App as "Order App"

    alt Thay đổi được quản lý tập trung
        BO->>BO: Phê duyệt đổi BR-NF-LOG-001 thành 25.000 VND
        BO->>BA: Yêu cầu ghi nhận thay đổi đã phê duyệt
        BA->>TIR: Tra cứu phụ thuộc BR-NF-LOG-001
        TIR-->>BA: API-NF-SHIP-SVC-001 phụ thuộc BR-NF-LOG-001
        BA->>CBR: Ghi nhận BR-NF-LOG-001, version mới
        BA->>TIR: Cập nhật liên kết API-NF-SHIP-SVC-001 với BR-NF-LOG-001 và dấu vết thay đổi
        BA->>TL: Thông báo chính thức thay đổi và phụ thuộc SSAPI
        TL->>TL: Xác minh ảnh hưởng đến SSAPI
        TL->>Dev: Thông báo chính thức và yêu cầu cập nhật theo BR-NF-LOG-001
        Dev->>SSAPI: Cập nhật phí Quận 1 thành 25.000 VND
        Dev->>SSAPI: Triển khai thay đổi phí
        TL->>SSAPI: Xác minh SSAPI áp dụng BR-NF-LOG-001 mới
        SSAPI-->>TL: Xác nhận phí Quận 1 là 25.000 VND
        App->>SSAPI: Yêu cầu phí tiêu chuẩn Quận 1
        SSAPI-->>App: Trả về 25.000 VND
        App->>App: Hiển thị phí chính xác
    else Thay đổi im lặng
        BO->>BO: Chỉ cập nhật tài liệu nội bộ thành 25.000 VND
        Note right of BO: Không ghi vào CBR, không thông báo đội phát triển
        App->>SSAPI: Yêu cầu phí tiêu chuẩn Quận 1
        SSAPI-->>App: Trả về 20.000 VND
        App->>App: Hiển thị phí sai 20.000 VND
        Note right of App: Nova Foods mất 5.000 VND doanh thu mỗi đơn Quận 1
        Note right of App: Khách hàng có thể trả thêm khi nhận hàng, gây mất uy tín
    end

Senior Lens

Với vai trò BA, quản lý sự lan truyền thay đổi và tránh thay đổi ngầm là ưu tiên hàng đầu để duy trì tính ổn định của ERP mô phỏng Nova Foods. Quy tắc vàng là mọi thay đổi liên quan đến quy tắc nghiệp vụ (BR), yêu cầu (REQ), hoặc API (API) phải có một nguồn chân lý duy nhất và được kiểm soát phiên bản. Sử dụng /01-curriculum/CANONICAL_BUSINESS_RULES.md để giữ các quy tắc tập trung và /01-curriculum/TRACEABILITY_ID_REGISTRY.md để xác định rõ ràng các mối quan hệ phụ thuộc. Điều này giúp dễ dàng đánh giá tác động khi một thành phần thay đổi. BABOK Guide nhấn mạnh tầm quan trọng của traceability trong việc quản lý yêu cầu (Requirement Management and Communication Knowledge Area), đặc biệt khi một thay đổi nhỏ có thể ảnh hưởng đến nhiều phần của hệ thống.

Quick Reference

Khái niệm	Mô tả ngắn	Hậu quả nếu không quản lý	Giải pháp BA
Lan truyền thay đổi	Thay đổi một phần ảnh hưởng các phần khác.	Hệ thống hoạt động sai, không nhất quán.	Xác định phụ thuộc, đánh giá tác động.
Thay đổi phụ thuộc ngầm	Thành phần thay đổi không báo cho thành phần phụ thuộc.	Lỗi không mong muốn, mất dữ liệu, sai lệch tài chính.	Canonical sources (CANONICAL_BUSINESS_RULES), Explicit traceability (TRACEABILITY_ID_REGISTRY), Versioning (API, quy tắc), Change communication process.

10. Common Mistakes & Anti-patterns

Core

Trong vai trò Business Analyst (BA), việc nhận diện và tránh các lỗi phổ biến (Common Mistakes) cùng các chống mẫu (Anti-patterns) là rất quan trọng. Các lỗi này thường xuất phát từ sự thiếu kinh nghiệm (novice mistakes) hoặc quy trình làm việc lỏng lẻo của đội triển khai (delivery-team mistakes), dẫn đến rủi ro lớn cho dự án. Chúng gây ra sự mơ hồ (ambiguity), thiếu sót (incompleteness), làm mất niềm tin vào các khẳng định không có căn cứ (unsupported authority claims), lạm dụng ký hiệu (notation misuse) và đứt gãy truy vết (traceability breaks), khiến hệ thống mô phỏng Nova Foods dễ gặp lỗi, chi phí sửa chữa cao và khó bảo trì.

Applied

Dưới đây là các ví dụ cụ thể về lỗi và chống mẫu thường gặp trong dự án ERP mô phỏng Nova Foods, cùng với dấu hiệu cảnh báo (red flags), nguyên nhân gốc rễ (root causes) và hành động khắc phục (corrective actions).

1. Tính mơ hồ (Ambiguity) và Thiếu sót (Incompleteness) trong Yêu cầu

• Lỗi: Viết yêu cầu quá chung chung, không rõ ràng hoặc bỏ sót các trường hợp biên (edge cases).
• Dấu hiệu cảnh báo: Developer thường xuyên hỏi lại, tester khó viết kịch bản kiểm thử, kiểm thử chấp nhận người dùng (UAT - User Acceptance Testing) thất bại vì "hiểu sai yêu cầu".
• Nguyên nhân gốc rễ: Kỹ năng gợi mở yêu cầu (elicitation) yếu, thiếu sự xác nhận từ chủ nghiệp vụ (Business Owner), vội vàng trong giai đoạn phân tích.
• Hành động khắc phục: Áp dụng các mẫu tài liệu yêu cầu có cấu trúc, sử dụng các ví dụ cụ thể và dữ liệu tổng hợp (synthetic data) để minh họa, định nghĩa rõ ràng các thuật ngữ.

Khía cạnh	Mô tả chi tiết
Sự kiện thực tế (Facts)	Yêu cầu REQ-DELIVERY-001 (phiên bản ban đầu): "Hệ thống cần tính phí vận chuyển."
Hành vi hiện tại (Current Behavior)	Developer A triển khai phí vận chuyển cố định 20.000 VND cho mọi đơn hàng Nova Foods.
Nhu cầu tiềm ẩn (Underlying Need)	Nova Foods muốn phí vận chuyển linh hoạt theo khoảng cách, trọng lượng và loại hàng (ví dụ: hàng đông lạnh phí cao hơn).
Lựa chọn (Options)	1. Giữ phí cố định. 2. Phí theo khu vực. 3. Phí theo công thức phức tạp (khoảng cách, trọng lượng, nhiệt độ, giờ giao).
Tiêu chí quyết định (Decision Criteria)	Chi phí vận hành, độ chính xác phí, trải nghiệm khách hàng, khả năng mở rộng.
Quyết định (Decision)	Áp dụng công thức tính phí vận chuyển động, theo BR-SHIPPING-001 (Nova Foods mô phỏng).
Thẩm quyền (Authority)	Trưởng phòng Vận hành Nova Foods (Simulated Operations Lead).
Artifact liên quan (Artifact)	Cập nhật 23-capstone-nova-foods-delivery-pack.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md với BR-SHIPPING-001 và /01-curriculum/TRACEABILITY_ID_REGISTRY.md để liên kết.
Hậu quả nếu sai (Consequence if Wrong)	Nova Foods mô phỏng mất doanh thu 5.000 VND/đơn hàng Quận 1 nếu phí cố định là 20.000 VND nhưng chi phí thực là 25.000 VND; hoặc mất khách hàng do phí cao bất hợp lý.

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

graph TB
    A["REQ-DELIVERY-001 mơ hồ:<br/>chỉ yêu cầu tính phí vận chuyển"]
    B["BA chưa xác nhận với Business Owner<br/>và chưa làm rõ công thức"]
    C["Developer A triển khai phí cố định<br/>20.000 VND cho mọi đơn hàng"]
    E["UAT phát hiện phí cố định<br/>không khớp kỳ vọng nghiệp vụ"]
    R["Rủi ro nếu đưa vào vận hành:<br/>thiếu 5.000 VND/đơn tại Quận 1<br/>hoặc mất khách hàng do phí bất hợp lý"]
    H["Hậu quả chắc chắn:<br/>rework và trì hoãn dự án"]
    D["Business Owner xác nhận nhu cầu:<br/>phí theo khoảng cách, trọng lượng và loại hàng"]
    O["Đánh giá 3 phương án:<br/>1. Phí cố định<br/>2. Phí theo khu vực<br/>3. Công thức theo khoảng cách, trọng lượng,<br/>nhiệt độ và giờ giao"]
    Q["Tiêu chí quyết định:<br/>chi phí vận hành, độ chính xác phí,<br/>trải nghiệm khách hàng, khả năng mở rộng"]
    S["Chọn phương án 3:<br/>công thức tính phí động"]
    I["Trưởng phòng Vận hành có thẩm quyền<br/>phê duyệt BR-SHIPPING-001"]
    J["BA cập nhật artifact:<br/>23-capstone-nova-foods-delivery-pack.md<br/>/01-curriculum/CANONICAL_BUSINESS_RULES.md<br/>/01-curriculum/TRACEABILITY_ID_REGISTRY.md"]
    K["Triển khai phí động theo<br/>BR-SHIPPING-001"]
    U{"UAT kiểm tra phí theo<br/>BR-SHIPPING-001"}
    W["Rework triển khai"]
    T["UAT đạt:<br/>kết thúc"]

    A --> B --> C --> E
    E --> R
    E --> H
    E --> D
    D --> O --> Q --> S --> I --> J --> K --> U
    U -- "Không đạt" --> W --> K
    U -- "Đạt" --> T

2. Khẳng định không có căn cứ (Unsupported Authority Claims)

• Lỗi: BA đưa ra các quy tắc nghiệp vụ (Business Rules) hoặc yêu cầu mà không trích dẫn nguồn gốc rõ ràng, hoặc gán cho một bên không có thẩm quyền. Ví dụ, BA tự ý thêm quy tắc "Khách hàng phải nhập 10 chữ số điện thoại" mà không xác minh với quy định viễn thông hoặc chính sách nội bộ.
• Dấu hiệu cảnh báo: Các bên liên quan (stakeholders) nghi ngờ tính hợp lệ của quy tắc, quy tắc mâu thuẫn với quy định pháp luật (ví dụ: Luật Viễn thông) hoặc chính sách hiện hành của Nova Foods.
• Nguyên nhân gốc rễ: Thiếu kiểm tra chéo (cross-check), ngại hỏi, hoặc tự ý diễn giải.
• Hành động khắc phục: Luôn ghi rõ nguồn gốc của mỗi quy tắc (ví dụ: "Theo Nghị định 123/2020/NĐ-CP", "Theo quyết định của Trưởng phòng Kế toán Nova Foods"), sử dụng /01-curriculum/CANONICAL_BUSINESS_RULES.md để lưu trữ tập trung các quy tắc và nguồn tham chiếu.

CẢNH BÁO: Không bao giờ tự ý diễn giải pháp luật hoặc quy định tài chính/kế toán (ví dụ: Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật Bảo vệ dữ liệu cá nhân). Luôn yêu cầu sự xác nhận từ Legal Owner hoặc Accounting Owner, và đánh dấu rõ ràng là "Verification required" khi chưa có xác nhận.

3. Lạm dụng ký hiệu (Notation Misuse)

• Lỗi: Sử dụng sai các ký hiệu trong biểu đồ (ví dụ: BPMN, UML), trộn lẫn các tiêu chuẩn hoặc tạo ra ký hiệu riêng mà không có chú thích. Ví dụ: Vẽ một flowchart nhưng lại dán nhãn là "BPMN" dù không tuân thủ cú pháp BPMN 2.0.2.
• Dấu hiệu cảnh báo: Developer, tester, hoặc BA khác không hiểu biểu đồ, yêu cầu giải thích lại. Kiến trúc sư (Architect) hoặc chuyên gia chất lượng (QA) chỉ ra lỗi tuân thủ tiêu chuẩn.
• Nguyên nhân gốc rễ: Thiếu kiến thức về các tiêu chuẩn (ví dụ: BPMN 2.0.2 từ OMG, UML 2.5.1 từ OMG), vội vàng, hoặc không coi trọng tính nhất quán.
• Hành động khắc phục: Tuân thủ nghiêm ngặt các tiêu chuẩn ký hiệu quốc tế, sử dụng công cụ hỗ trợ vẽ biểu đồ có kiểm tra cú pháp, cung cấp chú giải (legend) rõ ràng.

4. Đứt gãy truy vết (Traceability Breaks)

• Lỗi: Không liên kết các yêu cầu với các kịch bản kiểm thử, tài liệu thiết kế, hoặc các thành phần hệ thống liên quan. Thay đổi một yêu cầu mà không cập nhật các tài liệu phụ thuộc. Nova Foods (mô phỏng) từng gặp sự cố khi quy tắc khuyến mãi (BR-PROMO-010) thay đổi nhưng các trường hợp kiểm thử liên quan (TC-PROMO-005, TC-PROMO-008) không được cập nhật.
• Dấu hiệu cảnh báo: Khó khăn trong việc xác định liệu một yêu cầu đã được kiểm thử đầy đủ chưa, thay đổi ở một nơi gây ra lỗi không mong muốn ở nơi khác (ví dụ: hệ thống hiển thị khuyến mãi sai trong 3 ngày trước khi được phát hiện).
• Nguyên nhân gốc rễ: Quản lý thay đổi lỏng lẻo, không sử dụng công cụ hoặc quy trình truy vết, bỏ qua tầm quan trọng của traceability.
• Hành động khắc phục: Sử dụng /01-curriculum/TRACEABILITY_ID_REGISTRY.md để quản lý các định danh và mối quan hệ truy vết (ví dụ: liên kết BR-PROMO-010 với các REQ, UC, TC liên quan). Áp dụng quy trình quản lý thay đổi (Change Management Process) chính thức. Giới hạn phục hồi an toàn (safe recovery boundary) trong trường hợp Nova Foods là rollback phiên bản trước của quy tắc và code liên quan, đồng thời thông báo cho bộ phận marketing về sự cố.

Senior Lens

Với kinh nghiệm, tôi nhận thấy các chống mẫu này không chỉ là lỗi kỹ thuật mà còn là dấu hiệu của quy trình làm việc chưa trưởng thành và thiếu kỷ luật. Một BA cấp cao cần nhận diện các dấu hiệu cảnh báo sớm, không chờ đến khi hệ thống Nova Foods mô phỏng gặp sự cố mới khắc phục. Việc xây dựng một Single Source of Truth (Nguồn chân lý duy nhất) cho các quy tắc nghiệp vụ thông qua /01-curriculum/CANONICAL_BUSINESS_RULES.md là tối quan trọng. Tương tự, TRACEABILITY_ID_REGISTRY.md không chỉ là một tài liệu mà là một công cụ quản lý rủi ro, giúp đánh giá tác động của mọi thay đổi một cách có hệ thống. BABOK Guide (Phần Requirement Analysis and Design Definition Knowledge Area và Solution Evaluation Knowledge Area) nhấn mạnh việc đảm bảo yêu cầu là rõ ràng, đầy đủ và có thể kiểm chứng được, cũng như việc đánh giá tính khả thi và hiệu quả của giải pháp. Không có traceability, mọi dự án đều giống như đi trong sương mù, không biết thay đổi nhỏ nhất sẽ dẫn đến hậu quả gì.

Quick Reference

Lỗi/Chống mẫu	Dấu hiệu cảnh báo	Nguyên nhân gốc rễ	Hành động khắc phục BA
Mơ hồ/Thiếu sót	Hỏi nhiều, test khó, UAT fail.	Elicitation yếu, xác nhận kém.	Mẫu chuẩn, ví dụ, định nghĩa thuật ngữ.
Không căn cứ	Stakeholder nghi ngờ, mâu thuẫn.	Thiếu kiểm tra, tự diễn giải.	Ghi rõ nguồn, dùng CANONICAL_BUSINESS_RULES.md.
Lạm dụng ký hiệu	Không hiểu biểu đồ, lỗi chuẩn.	Thiếu kiến thức tiêu chuẩn.	Tuân thủ BPMN 2.0.2/UML 2.5.1, legend.
Đứt gãy truy vết	Khó verify, lỗi phụ thuộc.	Quản lý thay đổi lỏng lẻo.	TRACEABILITY_ID_REGISTRY.md, quản lý thay đổi.

Rủi ro cảnh báo và Biên độ phục hồi

Core

Cảnh báo rủi ro (warning callout): Điểm nhấn nguy hiểm thật. Không chỉ lỗi nhỏ. Lỗi này ảnh hưởng dự án, kinh doanh lớn. BA dùng nó: team hiểu mức độ, không lặp lại lỗi cũ. Giúp stakeholder hiểu rõ mức độ nghiêm trọng. Rủi ro thật (real risk): Không bug giao diện. Nguy cơ làm hỏng mục tiêu nghiệp vụ chính. BABOK nói: BA phải nhận diện, phân tích rủi ro.

Applied

Tình huống Nova Foods: Hệ thống ERP giao hàng ghi nhận sai trạng thái. Sự kiện: Tài xế Nova Foods (giả) đánh "Đã giao" (Delivered) khi hàng mới rời kho, chưa đến tay khách. Hành vi hiện tại: Hệ thống báo "Delivered" sớm. Nhu cầu gốc: Trạng thái đơn hàng phải đúng, minh bạch. Dữ liệu phải phản ánh thực tế để thanh toán, quản lý tồn kho chính xác. Các lựa chọn: 1. Không hành động: Giữ nguyên trạng thái sai. 2. Sửa tài liệu: Hướng dẫn tài xế cẩn thận hơn. 3. Cập nhật hệ thống: Thêm trạng thái "Đang vận chuyển" (In Transit). Buộc tài xế xác nhận vị trí GPS khi chuyển "Đã giao". Tiêu chí quyết định: Giảm sai sót dữ liệu. Tăng hài lòng khách hàng. Đảm bảo tuân thủ (ví dụ, truy vết thực phẩm theo Luật An toàn thực phẩm 55/2010/QH12). Thanh toán chính xác. Quyết định: Cập nhật ERP. Thêm trạng thái trung gian, buộc GPS cho "Đã giao". Thẩm quyền: Business Owner Nova Foods. Artifact liên quan: NovaFoods_BRD_v1.2.docx (Yêu cầu nghiệp vụ), NovaFoods_UserStory_Delivery_v0.9.jira, NovaFoods_ProcessFlow_Delivery_v2.0.bpmn (Quy trình). Hậu quả nếu sai: Khách hàng khiếu nại (mất uy tín). Kế toán xuất hóa đơn sai (ảnh hưởng Luật Kế toán 88/2015/QH13). Hàng hỏng không rõ trách nhiệm. Phạt hành chính (nếu vi phạm quy định truy vết).

graph TD
    subgraph Luồng lỗi (Anti-pattern)
        A_Loi[Đơn hàng: Tạo] --> B_Loi{Tài xế nhận hàng?};
        B_Loi -- Có --> C_Loi[Hàng rời kho];
        C_Loi -- Ghi "Đã Giao" --> D_Loi(Lỗi: Khách chưa nhận);
        D_Loi --> E_RuiRo(Rủi ro: Sai tồn kho, khiếu nại, không truy vết);
    end

    subgraph Ranh giới phục hồi (Recovery Boundary)
        F_PhucHoi[Yêu cầu: Xác nhận giao hàng tại điểm đến] --> G_QuyTrinhMoi[Luồng mới: Ghi "Đang vận chuyển"];
        G_QuyTrinhMoi --> H_XacNhan[Luồng mới: Xác nhận "Đã giao" + GPS/ảnh];
    end

    subgraph Luồng đúng (Corrected Flow)
        A_Dung[Đơn hàng: Tạo] --> B_Dung{Tài xế nhận hàng?};
        B_Dung -- Có --> C_Dung[Hàng rời kho];
        C_Dung -- Ghi "Đang vận chuyển" --> D_Dung[Trên đường];
        D_Dung -- Ghi "Đã giao" (có GPS/ảnh) --> E_Dung[Hoàn tất];
    end

    E_RuiRo --- F_PhucHoi;
    E_RuiRo -- Kích hoạt --> F_PhucHoi;

    style A_Loi fill:#DDF,stroke:#333,stroke-width:2px;
    style B_Loi fill:#FFF,stroke:#333,stroke-width:2px;
    style C_Loi fill:#DDE,stroke:#333,stroke-width:2px;
    style D_Loi fill:#FAA,stroke:#A00,stroke-width:2px;
    style E_RuiRo fill:#F88,stroke:#A00,stroke-width:4px;

    style F_PhucHoi fill:#ACA,stroke:#0A0,stroke-width:2px;

    style A_Dung fill:#DDF,stroke:#333,stroke-width:2px;
    style B_Dung fill:#FFF,stroke:#333,stroke-width:2px;
    style C_Dung fill:#EEE,stroke:#333,stroke-width:2px;
    style D_Dung fill:#EEE,stroke:#333,stroke-width:2px;
    style E_Dung fill:#DDF,stroke:#333,stroke-width:2px;

Senior Lens

Bug lỗi code. Anti-pattern (chống-mô-hình): Cách làm sai, thiết kế sai. BA không chỉ vá bug. BA tìm gốc rễ vấn đề nghiệp vụ. Sai lầm BA hay mắc: Yêu cầu thiếu, không đủ người liên quan, phạm vi dự án trượt, thiếu kiểm tra đầu vào. Ranh giới phục hồi an toàn (safe recovery boundary): Không chỉ sửa lỗi một lần. Cần sửa quy trình, định nghĩa, kiểm soát đầu vào. Ví dụ Nova Foods giao hàng sai: Phục hồi là sửa lại quy trình kiểm tra trạng thái, thêm ràng buộc kỹ thuật (GPS), đào tạo lại tài xế. Đó là sửa gốc.

Quick Reference

Sai lầm (Mistake)	Dấu hiệu (Red Flag)	Nguyên nhân (Root Cause)	Hành động khắc phục (Corrective Action)
Cảnh báo rủi ro chung chung	"Hệ thống có thể lỗi."	Thiếu phân tích ảnh hưởng nghiệp vụ.	Yêu cầu bằng chứng, tác động kinh doanh, ranh giới phục hồi.
Coi nhẹ lỗi dữ liệu	"Chỉ là nhập liệu sai."	Không hiểu tác động chuỗi giá trị (value chain).	Phân tích chi phí (cost of bad data), ràng buộc hệ thống.
Thiếu ví dụ thực Nova Foods	Dùng case study khác, không liên quan.	Không gắn kết với bối cảnh dự án.	Luôn dùng ví dụ Nova Foods (giả), dữ liệu tổng hợp.
Không rõ biên độ phục hồi	"Sửa xong là được."	Thiếu tư duy ngăn ngừa lặp lại.	Xác định hành động phòng ngừa, thay đổi quy trình/hệ thống, đào tạo.

Phân tách Lỗi BA Thường Gặp (Mơ hồ, Không đầy đủ, Khẳng định không căn cứ, Lạm dụng ký hiệu, Đứt gãy truy vết)

Các lỗi thường gặp trong phân tích nghiệp vụ có thể dẫn đến sự hiểu lầm nghiêm trọng, phát triển sai sản phẩm và lãng phí nguồn lực. BA cần nhận diện và khắc phục chúng.

Core

1. Mơ hồ (Ambiguity)

Một mô tả hoặc yêu cầu bị mơ hồ khi nó có thể được diễn giải theo nhiều cách khác nhau, dẫn đến sản phẩm cuối cùng không đáp ứng đúng mong đợi. * Nguyên nhân: Từ ngữ không chính xác, thiếu định nghĩa thuật ngữ, sử dụng đại từ không rõ ràng, không có ví dụ minh họa cụ thể. * Dấu hiệu cảnh báo (Red Flag): Các cụm từ như "hệ thống phải nhanh", "giao diện thân thiện", "xử lý linh hoạt", "dễ sử dụng". * Biện pháp khắc phục: Sử dụng thuật ngữ đã được định nghĩa trong từ điển dữ liệu (Data Dictionary) hoặc bảng thuật ngữ (Glossary). Thêm ví dụ cụ thể, điều kiện và tiêu chí chấp nhận (Acceptance Criteria) có thể đo lường được.

2. Không đầy đủ (Incompleteness)

Thiếu thông tin cần thiết để hiểu hoặc triển khai đầy đủ một yêu cầu, chức năng hoặc quy trình. * Nguyên nhân: Bỏ qua các trường hợp biên (edge cases), thiếu các luồng xử lý lỗi (error flows), không xác định tất cả các vai trò liên quan, thiếu dữ liệu cần thiết cho một hoạt động. * Dấu hiệu cảnh báo: Một yêu cầu quá ngắn gọn hoặc chỉ mô tả luồng chính thành công (happy path) mà không đề cập các kịch bản khác. Ví dụ: "Người dùng đăng nhập." (Thiếu: chuyện gì xảy ra khi đăng nhập thất bại? người dùng không có quyền? tài khoản bị khóa?). * Biện pháp khắc phục: Luôn đặt câu hỏi "điều gì sẽ xảy ra nếu...", sử dụng checklist kiểm tra các kịch bản, xác định tất cả các luồng thay thế (alternative flows) và ngoại lệ.

3. Khẳng định thẩm quyền không có căn cứ (Unsupported Authority Claims)

Đưa ra một tuyên bố (ví dụ: "yêu cầu này là bắt buộc theo luật," "đây là quy tắc nghiệp vụ") mà không có nguồn tham chiếu rõ ràng, được phê duyệt và có thẩm quyền. * Nguyên nhân: BA tự suy diễn, ghi nhận từ một cuộc trò chuyện không chính thức, không xác minh lại với Business Owner (Chủ sở hữu nghiệp vụ) hoặc các vai trò có thẩm quyền như Legal/Compliance (Pháp chế/Tuân thủ), Accounting (Kế toán). * Dấu hiệu cảnh báo: Các câu nói như "Luật bắt buộc phải có...", "Business Owner nói là...", nhưng không có mã định danh luật (SRC-ID) từ /00-research/00_SOURCE_MAP.md, mã quy tắc nghiệp vụ (BR-ID) từ /01-curriculum/CANONICAL_BUSINESS_RULES.md, hoặc bằng chứng phê duyệt (email, tài liệu có chữ ký). * Biện pháp khắc phục: Mọi tuyên bố nghiệp vụ, pháp lý, kế toán, bảo mật phải có SRC-ID hoặc BR-ID được quản lý, hoặc tham chiếu đến một artifact có baseline/approval rõ ràng. Ghi rõ tên và vai trò của người đã phê duyệt.

4. Lạm dụng ký hiệu (Notation Misuse)

Sử dụng sai các ký hiệu chuẩn (ví dụ: UML – Unified Modeling Language, BPMN – Business Process Model and Notation) hoặc sử dụng một công cụ vẽ sơ đồ thay cho một ngôn ngữ mô hình hóa chính thức. * Nguyên nhân: Thiếu hiểu biết về tiêu chuẩn, ưu tiên tốc độ hơn sự chính xác, nhầm lẫn công cụ vẽ với ngôn ngữ mô hình. * Dấu hiệu cảnh báo: Gọi một sơ đồ được vẽ bằng PlantUML là "biểu đồ BPMN" khi nó không tuân thủ đặc tả BPMN (OMG BPMN 2.0.2). Gọi một biểu đồ lớp đơn giản là "mô hình UML" khi nó không theo đúng cú pháp hoặc ngữ nghĩa UML (OMG UML 2.5.1). * Biện pháp khắc phục: Học và tuân thủ các chuẩn quốc tế (UML, BPMN) và hiểu rõ ngữ nghĩa của từng ký hiệu. Nếu không phải là chuẩn, gọi đó là "biểu đồ luồng" hoặc "biểu đồ trạng thái" thông thường để tránh hiểu lầm.

5. Đứt gãy khả năng truy vết (Traceability Breaks)

Mất đi khả năng liên kết ngược hoặc xuôi giữa các artifact liên quan (ví dụ: yêu cầu với kiểm thử, yêu cầu với nguồn gốc, tính năng với mục tiêu kinh doanh). Khả năng truy vết (traceability) giúp hiểu tác động của thay đổi. * Nguyên nhân: Không sử dụng định danh duy nhất (unique ID) cho các yêu cầu, quy tắc nghiệp vụ, test case; không cập nhật các liên kết khi có thay đổi; không có hệ thống quản lý yêu cầu (Requirements Management System - RMS). * Dấu hiệu cảnh báo: Không thể biết yêu cầu NF-REQ-001 bắt nguồn từ mục tiêu kinh doanh nào, hoặc thay đổi quy tắc nghiệp vụ BR-NOVA-015 ảnh hưởng đến những test case nào. * Biện pháp khắc phục: Sử dụng các ID chuẩn (ví dụ: REQ-ID, BR-ID, TC-ID được quản lý trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md). Duy trì ma trận truy vết (traceability matrix) hoặc sử dụng công cụ RMS.

Applied

Ví dụ Nova Foods: Khẳng định Thẩm quyền không có Căn cứ cho Quy trình In Hóa đơn

Nova Foods (mô phỏng) đang phát triển module quản lý đơn hàng cho hệ thống ERP. BA ghi nhận một yêu cầu liên quan đến việc in hóa đơn VAT.

• Tình huống thực tế (Facts): Nova Foods cần in hóa đơn VAT cho các đơn hàng đã giao. BA ghi nhận yêu cầu NF-ORD-005: "Hệ thống phải cho phép in hóa đơn VAT ngay sau khi đơn hàng được giao thành công."
• Hành vi hiện tại (Current Behavior) - Sai lầm: BA bổ sung vào yêu cầu NF-ORD-005 ghi chú: "Yêu cầu này là BẮT BUỘC theo luật Việt Nam về hóa đơn điện tử." Nhưng không trích dẫn cụ thể điều khoản, cũng không có sự xác nhận từ Legal Owner hoặc Accounting Owner của Nova Foods.
• Nhu cầu cốt lõi (Underlying Need): Cần xác định chính xác tính hợp lệ và căn cứ pháp lý của yêu cầu để phân loại ưu tiên, đánh giá rủi ro tuân thủ (compliance risk) và phạm vi ảnh hưởng một cách chính xác. Ngăn chặn việc lãng phí tài nguyên phát triển cho yêu cầu không có căn cứ hoặc bỏ sót yêu cầu quan trọng.
• Các phương án (Options):
  1. Giữ nguyên yêu cầu với khẳng định không có căn cứ.
  2. Xóa bỏ yêu cầu do không có căn cứ.
  3. BA xác minh lại yêu cầu với Legal Owner hoặc Accounting Owner, yêu cầu trích dẫn điều khoản cụ thể trong văn bản pháp luật.
• Tiêu chí quyết định (Decision Criteria):
  • Tính chính xác pháp lý của thông tin.
  • Khả năng truy vết nguồn gốc yêu cầu (là luật, quy định nội bộ hay mong muốn nghiệp vụ).
  • Ảnh hưởng đến chi phí và thời gian triển khai hệ thống ERP.
  • Mức độ rủi ro tuân thủ (compliance risk) nếu bỏ qua hoặc thực hiện sai.
• Quyết định (Decision): Chọn phương án 3. BA tiến hành phỏng vấn Legal Owner của Nova Foods.
• Thẩm quyền (Authority): Legal Owner (Chủ sở hữu Pháp lý) hoặc Accounting Owner (Chủ sở hữu Kế toán) của Nova Foods là nguồn thông tin có thẩm quyền cho yêu cầu pháp lý/kế toán. BA chỉ có thẩm quyền điều phối xác minh.
• Artifact (Sau khi sửa): Yêu cầu được chỉnh sửa và bổ sung:
  • REQ-NF-ORD-005: "Hệ thống phải cho phép tạo và lưu trữ hóa đơn điện tử VAT (Hóa đơn giá trị gia tăng) cho mọi đơn hàng đã hoàn tất giao, theo định dạng hợp lệ của Tổng cục Thuế Việt Nam."
  • REQ-NF-ORD-005.Source: SRC-LAW-123-2020-NDCP (Nghị định 123/2020/NĐ-CP), Điều 9 Khoản 2 (Nguyên tắc lập hóa đơn điện tử) và Nghị định 356/2025/NĐ-CP (Hướng dẫn chi tiết).
  • REQ-NF-ORD-005.ApprovedBy: [Tên Legal Owner Nova Foods], [Chức danh], [Ngày phê duyệt: 2026-08-01].
  • REQ-NF-ORD-005.TraceTo: NF-BR-ACC-001 (Quy tắc nghiệp vụ: Mọi giao dịch bán hàng phải có hóa đơn hợp lệ).
• Hậu quả nếu sai (Consequence if Wrong):
  • Nếu yêu cầu không phải luật bắt buộc nhưng bị gắn nhãn sai: Lãng phí tài nguyên phát triển cho chức năng có độ phức tạp cao không cần thiết, tăng chi phí và thời gian triển khai ERP.
  • Nếu yêu cầu là luật bắt buộc nhưng BA khẳng định sai hoặc bỏ qua: Nguy cơ Nova Foods vi phạm pháp luật, bị phạt hành chính, ảnh hưởng nghiêm trọng đến uy tín và hoạt động kinh doanh.

Senior Lens

BA giỏi không phải người biết tất cả các câu trả lời mà là người biết cách đặt câu hỏi đúng và biết tìm câu trả lời ở đâu, từ ai. * Vai trò cầu nối, không nguồn gốc chân lý: BA là người thu thập, phân tích, tổng hợp thông tin, nhưng không phải là "nguồn gốc của sự thật" (source of truth) cho các quy tắc nghiệp vụ, pháp lý, kế toán hay bảo mật. Nguồn gốc chân lý luôn nằm ở các vai trò có thẩm quyền (Business Owner, Legal Owner, v.v.) và các tài liệu chuẩn (luật, quy định, đặc tả kỹ thuật). * Quy trình thẩm quyền: Thiết lập và tuân thủ một quy trình rõ ràng để xác minh và phê duyệt thông tin là tối quan trọng. Không có "thẩm quyền ngầm định". Mọi khẳng định phải có bằng chứng. * Luôn hỏi "Tại sao?" và "Ai nói vậy?": Đây là hai câu hỏi nền tảng giúp BA đào sâu vấn đề và truy vết nguồn gốc thông tin. * Đánh giá rủi ro: Với mỗi lỗi (mơ hồ, không đầy đủ, không căn cứ), BA cần đánh giá rủi ro tiềm ẩn (ví dụ: rủi ro pháp lý, rủi ro tài chính, rủi ro về chất lượng sản phẩm) để đưa ra biện pháp khắc phục phù hợp. * Quản trị (Governance) là chìa khóa: Trong một hệ thống phức tạp như ERP của Nova Foods, quản trị chặt chẽ các artifact (yêu cầu, quy tắc, dữ liệu) với các ID duy nhất và khả năng truy vết là cách duy nhất để kiểm soát sự thay đổi và duy trì tính toàn vẹn.

Quick Reference

Lỗi Thường Gặp	Dấu hiệu cảnh báo (Red Flags)	Biện pháp khắc phục
Mơ hồ (Ambiguity)	Ngôn ngữ chung chung, không đo lường được ("nhanh", "thân thiện")	Dùng định nghĩa, ví dụ, tiêu chí chấp nhận (AC) cụ thể
Không đầy đủ (Incompleteness)	Thiếu kịch bản lỗi, trường hợp biên, luồng thay thế	Đặt câu hỏi "điều gì nếu...", dùng checklist, sơ đồ đầy đủ
Khẳng định thẩm quyền không căn cứ	"Luật bắt buộc...", "Business Owner nói...", không trích dẫn nguồn	Yêu cầu SRC-ID, BR-ID, bằng chứng phê duyệt từ vai trò có thẩm quyền
Lạm dụng ký hiệu (Notation Misuse)	Gọi PlantUML là BPMN, dùng sai ký hiệu UML	Học chuẩn (UML, BPMN), dùng tên chung nếu không tuân thủ
Đứt gãy khả năng truy vết (Traceability Breaks)	Không biết nguồn gốc yêu cầu, tác động thay đổi	Dùng ID chuẩn (REQ-ID, BR-ID), ma trận truy vết, RMS

Sơ đồ luồng xác minh yêu cầu (ví dụ)

graph TD
    A[Yêu cầu mới NF-REQ-XXX] --> B{Yêu cầu nghiệp vụ/pháp lý?};
    B -- Có --> C{Có nguồn gốc (SRC-ID, BR-ID) và Thẩm quyền không?};
    C -- Không --> D[ESCALATION: Tìm Legal/Accounting/Business Owner];
    D --> E[Lấy xác nhận & SRC-ID/BR-ID];
    E --> F[Ghi nhận vào REQ-NF-XXX.Source & REQ-NF-XXX.ApprovedBy];
    C -- Có --> F;
    B -- Không --> G[Yêu cầu kỹ thuật/khác?];
    F --> H[Tiếp tục phân tích, tạo truy vết];
    G --> H;

→ skipped: Xác minh từng SRC-ID/BR-ID cụ thể, add when cần đảm bảo tính chính xác từng tham chiếu trong dự án thực.

11. Senior BA Notes & Rules of Thumb

Senior Lens

Với vai trò BA cấp cao (Senior BA), việc chỉ ghi nhận yêu cầu không đủ. BA phải phân tích trade-off, rủi ro, xung đột, chất lượng bằng chứng và thẩm quyền trước khi đề xuất giải pháp. Mục tiêu: Decision Maker nhận đủ thông tin để chọn phương án, chấp nhận hậu quả và chịu trách nhiệm quyết định.

1. Đánh đổi (Trade-offs) * Khái niệm: Mọi quyết định thiết kế hoặc triển khai giải pháp đều có đánh đổi. Chọn một lợi ích thường kèm hy sinh lợi ích khác, chi phí hoặc rủi ro mới. * Góc nhìn Senior BA: BA không tìm giải pháp hoàn hảo. BA xác định phương án phù hợp mục tiêu, nguồn lực và giới hạn hiện tại. BA phải nêu rõ lợi ích, chi phí, rủi ro, bên chịu tác động và hậu quả từng lựa chọn trước khi stakeholder quyết định. * Ví dụ Nova Foods: Tính năng theo dõi đơn hàng thời gian thực (Nova-DEL-TRK-001) có thể tăng trải nghiệm khách hàng và giảm cuộc gọi hỗ trợ. Đánh đổi: tăng chi phí phát triển, cần tích hợp GPS bên thứ ba và có thể phát sinh phí duy trì. Business Owner phải cân nhắc lợi ích cạnh tranh với chi phí đầu tư và rủi ro phụ thuộc đối tác. * Cơ sở: Phân tích chi phí-lợi ích (Cost-Benefit Analysis - CBA), phân tích tác động (Impact Analysis), đánh giá rủi ro (Risk Assessment).

2. Các Trường hợp ngoại lệ (Exceptions) * Khái niệm: Tình huống không tuân theo quy trình hoặc quy tắc thông thường. Bỏ qua ngoại lệ có thể gây lỗi hệ thống, thất thoát dữ liệu hoặc không tuân thủ. * Góc nhìn Senior BA: BA cấp dưới thường tập trung happy path. Senior BA phải tìm, xác định và mô tả xử lý lỗi, edge case và điều kiện đặc biệt. Mỗi ngoại lệ cần có điều kiện kích hoạt, actor xử lý, hành động, dữ liệu bị tác động, outcome, bằng chứng và đường leo thang. * Ví dụ Nova Foods: Quy trình xuất hóa đơn điện tử (Nova-INV-ELEC-002) áp dụng cho hầu hết đơn hàng. Ngoại lệ gồm khách hàng yêu cầu hóa đơn giấy trong trường hợp pháp luật cho phép đối với đối tượng đặc biệt, hoặc lỗi hệ thống khiến không thể xuất hóa đơn điện tử ngay. Hệ thống cần lưu trạng thái lỗi, tạo cơ chế phục hồi và tạo báo cáo cho người chịu trách nhiệm. * Cơ sở: Phỏng vấn Business Owner, Legal Owner; phân tích dữ liệu lịch sử giao dịch bất thường; rà soát nguồn được ghi nhận SRC-ID: NĐ 123/2020/NĐ-CP.

3. Xung đột giữa các bên liên quan (Stakeholder Conflict) * Khái niệm: Stakeholder có mục tiêu, ưu tiên hoặc yêu cầu khác nhau, gây mâu thuẫn về giải pháp hoặc phạm vi. * Góc nhìn Senior BA: Xung đột là bình thường. BA phải nhận diện sớm, xác định nguyên nhân gốc, không chọn phe, điều phối để từng bên nêu mục tiêu, ràng buộc và rủi ro. Nếu không thể dung hòa, BA trình bày lựa chọn cùng hậu quả cho người có thẩm quyền. * Ví dụ Nova Foods: Marketing muốn triển khai khuyến mãi “mua 1 tặng 1” (Nova-PROMO-005) trong 3 ngày và yêu cầu hệ thống tự tính giá. Kho vận phản đối vì rủi ro tồn kho, đóng gói phức tạp và sai sót. BA làm rõ mục tiêu tăng doanh số của Marketing, khả năng thực thi của Kho vận, rồi đề xuất giới hạn số lượng áp dụng hoặc điều kiện tồn kho trước khi kích hoạt. * Cơ sở: Phỏng vấn riêng stakeholder, ma trận RACI, mục tiêu kinh doanh Nova Foods.

4. Chất lượng bằng chứng (Evidence Quality) * Khái niệm: Mức độ tin cậy, đầy đủ và chính xác của thông tin dùng để phân tích, thiết kế và quyết định. * Góc nhìn Senior BA: Không phải mọi thông tin có giá trị ngang nhau. BA đánh giá nguồn, tính khách quan, thời điểm, phạm vi và phương pháp thu thập. “Nghe nói” hoặc kinh nghiệm chung chung có chất lượng thấp hơn dữ liệu định lượng, nguồn quy định được kiểm tra hoặc xác nhận từ Business Owner có thẩm quyền. * Ví dụ Nova Foods: Yêu cầu “ERP phải thân thiện với người dùng” (Nova-REQ-GEN-003) thiếu tiêu chí đo và có bằng chứng yếu. Yêu cầu “thời gian hoàn thành tác vụ nhập đơn hàng không quá 90 giây đối với 80% người dùng dựa trên nghiên cứu khảo sát” (Nova-UX-001) có thể kiểm thử và có bằng chứng mạnh hơn. Tuyên bố pháp lý chỉ được dùng làm căn cứ sau khi Legal Owner kiểm tra SRC-ID và xác nhận áp dụng. * Cơ sở: Kiểm tra SRC-ID khi có quy định; đối chiếu data analytics; xác minh chéo bằng nguồn đáng tin cậy; ghi rõ giả định chưa xác minh.

5. Thẩm quyền ra quyết định (Decision Authority) * Khái niệm: Cá nhân hoặc vai trò có quyền và trách nhiệm ra quyết định cuối cùng về một khía cạnh dự án. * Góc nhìn Senior BA: BA không phải Decision Maker nghiệp vụ cuối cùng. BA chuẩn bị facts, giả định, lựa chọn, trade-off, rủi ro và khuyến nghị. BA xác định đúng người quyết định, ghi nhận quyết định cùng căn cứ và leo thang khi vấn đề vượt thẩm quyền. * Ví dụ Nova Foods: Quyết định nghiệp vụ chiết khấu khách hàng (Nova-PROMO-005) thuộc Trưởng phòng Kinh doanh, Business Owner. Quyết định tuân thủ an toàn thực phẩm (Nova-COMPL-003) thuộc Giám đốc Chất lượng, Compliance Owner. Quyết định lựa chọn công nghệ kiến trúc (Nova-ARCH-002) thuộc Technical Architect. * Cơ sở: RACI, cơ cấu tổ chức Nova Foods, điều lệ và quy định nội bộ của công ty Nova Foods mô phỏng.

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

flowchart TB
    A["Vấn đề hoặc yêu cầu NF-REQ-XXX"] --> B["BA xác định facts, giả định, lựa chọn, rủi ro và vấn đề cần xử lý"]

    B --> D["Ngoại lệ: xác định điều kiện kích hoạt, actor, hành động, dữ liệu tác động, outcome và bằng chứng"]
    B --> E{"Có căn cứ pháp lý?"}
    B --> H["Xung đột: làm rõ mục tiêu, ràng buộc và rủi ro của từng stakeholder"]
    B --> T["Trade-off: xác định lợi ích, chi phí, rủi ro, bên chịu tác động và hậu quả từng lựa chọn"]

    D --> D1{"Actor có thể xử lý trong thẩm quyền?"}
    D1 -- "Có" --> D3["Ghi cách xử lý, outcome, bằng chứng và đường escalation khi cần"]
    D1 -- "Không" --> D2["Escalation: xác định actor có thẩm quyền xử lý"]
    D2 --> D4["Actor có thẩm quyền xác định cách xử lý"]
    D4 --> D3
    D3 --> Q{"Còn thiếu góc phân tích nào?"}

    E -- "Có" --> F["Legal Owner kiểm tra SRC-ID và xác nhận phạm vi áp dụng"]
    E -- "Không" --> G["Đánh giá chất lượng bằng chứng"]
    F --> G
    G --> G1["Đánh giá nguồn, tính khách quan, thời điểm, phạm vi và phương pháp thu thập"]
    G1 --> G2{"Bằng chứng đủ tin cậy và đã xác minh?"}
    G2 -- "Có" --> G3["Ghi bằng chứng và phạm vi sử dụng"]
    G2 -- "Không" --> G4{"Có thể bổ sung hoặc xác minh chéo?"}
    G4 -- "Có" --> G5["Đối chiếu dữ liệu và nguồn đáng tin cậy"]
    G5 --> G1
    G4 -- "Không" --> G6["Ghi giả định, điểm yếu, phần chưa xác minh và hạn chế"]
    G6 --> G7["Đưa hạn chế bằng chứng vào nội dung trình Decision Maker"]
    G3 --> Q
    G7 --> Q

    H --> I{"Có thể dung hòa?"}
    I -- "Có" --> Q
    I -- "Không" --> J["Ghi xung đột chưa dung hòa, lựa chọn, hậu quả và nhu cầu escalation"]
    J --> Q

    T --> Q

    Q -- "Thiếu Trade-off" --> T
    Q -- "Thiếu Ngoại lệ" --> D
    Q -- "Thiếu Xung đột" --> H
    Q -- "Thiếu Chất lượng bằng chứng" --> E
    Q -- "Không thiếu" --> K["BA hợp nhất phân tích và chuẩn bị khuyến nghị"]

    K --> L{"Loại quyết định"}
    L -- "Nghiệp vụ" --> L1["Business Owner"]
    L -- "Tuân thủ" --> L2["Compliance Owner"]
    L -- "Kiến trúc" --> L3["Technical Architect"]
    L -- "Khác" --> L4["Tra RACI và cơ cấu tổ chức để xác định Decision Maker"]

    L1 --> M{"Đúng Decision Maker và trong thẩm quyền?"}
    L2 --> M
    L3 --> M
    L4 --> M

    M -- "Không" --> O["Escalation: xác định đúng Decision Maker và yêu cầu nhận trách nhiệm"]
    O --> M
    M -- "Có" --> N["BA trình facts, giả định, lựa chọn, khuyến nghị, trade-off, hậu quả, rủi ro và bằng chứng"]

    N --> U{"Quyết định của Decision Maker"}

    U -- "Chấp thuận" --> V["Ghi quyết định, người quyết định, căn cứ, trách nhiệm, hậu quả và rủi ro được chấp nhận"]
    V --> W["Cập nhật yêu cầu hoặc phương án đã chấp thuận"]
    W --> X["Tiếp tục phân tích hoặc thiết kế"]

    U -- "Từ chối" --> Y["Ghi quyết định từ chối, người quyết định và căn cứ"]
    Y --> Z{"Outcome theo quyết định"}
    Z -- "Sửa yêu cầu hoặc phương án" --> AA["BA cập nhật nội dung theo quyết định"]
    AA --> B
    Z -- "Đóng vấn đề" --> AB["Đóng vấn đề và lưu hồ sơ quyết định"]

    U -- "Yêu cầu bổ sung" --> AC["Ghi nội dung cần bổ sung và căn cứ"]
    AC --> AD["BA bổ sung facts, bằng chứng hoặc lựa chọn"]
    AD --> B

Quy Tắc Rà Soát và Cảnh Báo Sớm

Rà soát nghiệp vụ: Senior BA kiểm tra tài liệu, quy trình, bằng chứng và truy vết trước bàn giao. Mục tiêu: phát hiện lỗi sớm, tránh thiết kế sai, phát triển sai hoặc kiểm thử sai.

Nguyên tắc rà soát (Review Heuristics)	Mô tả BA cao cấp	Lý do áp dụng
Truy vết (Traceability)	Xác nhận yêu cầu gốc, tài liệu phân tích, thiết kế, kiểm thử và quyết định có liên kết rõ. Mỗi phần tử phải có nguồn, owner và artifact liên quan.	Giữ toàn vẹn chuỗi yêu cầu. Phát hiện thiếu sót, thừa thãi, mâu thuẫn.
Đầy đủ (Completeness)	Đánh giá use case, scenario, ngoại lệ, điều kiện kích hoạt, dữ liệu vào, dữ liệu ra và tiêu chí chấp nhận.	Ngăn thiếu chức năng. Giảm rủi ro phát sinh yêu cầu muộn.
Nhất quán (Consistency)	Kiểm tra thuật ngữ, business rules, trạng thái và luồng logic đồng nhất giữa tài liệu.	Tránh hiểu sai, lỗi logic và lãng phí phát triển.
Khả thi (Feasibility)	Đánh giá yêu cầu có thể thực hiện bằng công nghệ, nguồn lực và giới hạn hiện có của Nova Foods.	Tránh cam kết không khả thi. Bảo vệ nguồn lực dự án.
Phù hợp (Alignment)	Xác định yêu cầu đóng góp mục tiêu nghiệp vụ và phù hợp chiến lược Nova Foods.	Giữ dự án đúng hướng. Tạo giá trị cho tổ chức.
Rõ ràng (Clarity)	Đảm bảo ngôn ngữ không mơ hồ; actor, action, object, điều kiện và outcome được nêu rõ.	Giảm hiểu lầm. Tăng tốc phát triển và kiểm thử.

Cảnh báo đỏ (Red Flags): Dấu hiệu cần hành động trước khi artifact được dùng cho thiết kế, phát triển hoặc quyết định.

Cảnh báo đỏ (Red Flag)	Mô tả vấn đề BA cần phát hiện	Hệ quả tiềm tàng nếu bỏ qua
Mâu thuẫn yêu cầu (Requirement Conflicts)	Hai hoặc nhiều yêu cầu không thể cùng tồn tại hoặc cùng thực hiện.	Hệ thống không ổn định. Lỗi logic. Trì hoãn quyết định.
Mơ hồ (Ambiguity)	Câu hoặc đoạn có nhiều cách hiểu.	Thiết kế sai. Phát triển sai. Kiểm thử sai. Làm lại.
Thiếu chi tiết (Missing Details)	Thiếu ràng buộc dữ liệu, điều kiện kích hoạt, ngoại lệ, owner hoặc tiêu chí chấp nhận.	Kỹ sư phải đoán. Thiếu chức năng. Không kiểm thử được.
Phình to phạm vi (Scope Creep)	Yêu cầu mới được thêm không qua kiểm soát thay đổi và không có Decision Maker chấp thuận.	Vượt ngân sách. Trễ tiến độ. Giảm chất lượng.
Giả định chưa xác minh (Unverified Assumptions)	Quyết định quan trọng dựa trên giả định chưa được xác nhận với nghiệp vụ hoặc kỹ thuật.	Quyết định sai hướng. Chi phí sửa chữa lớn.
Thiếu đồng thuận (Lack of Stakeholder Buy-in)	Marketing, Vận hành, Kế toán hoặc stakeholder chính không chấp thuận yêu cầu quan trọng.	Sản phẩm không được sử dụng. Phản đối khi triển khai.

Ngưỡng leo thang (Escalation Thresholds): BA báo đúng owner khi vấn đề vượt khả năng điều phối hoặc vượt thẩm quyền.

• Mâu thuẫn không giải quyết được: Stakeholder không đạt kết luận sau 2–3 buổi họp riêng. BA tổng hợp quan điểm, lựa chọn, trade-off và yêu cầu Decision Maker quyết.
• Ảnh hưởng đường găng (Critical Path Impact): Vấn đề làm chậm tiến độ tổng thể Nova Foods. BA ghi tác động lịch, artifact bị chặn và owner cần quyết.
• Rủi ro pháp lý/tuân thủ cao: Vấn đề liên quan nguồn được ghi nhận Luật 91/2025/QH15 hoặc Nghị định 123/2020/NĐ-CP. BA báo Legal Owner hoặc Compliance Owner; không tự diễn giải nghĩa vụ pháp lý.
• Ảnh hưởng chi phí/thời gian lớn: Thay đổi có thể tăng chi phí hơn 10% hoặc trì hoãn hơn 2 tuần. BA trình Business Owner và Finance Owner để quyết định chấp nhận, giảm phạm vi hoặc dừng thay đổi.
• Thẩm quyền vượt BA: Quyết định về kiến trúc tổng thể, bảo mật tham chiếu OWASP ASVS hoặc chiến lược dài hạn. BA chuyển Architect, Security Owner hoặc Business Owner.

Điều kiện ngoại lệ (Conditions for Exceptions): Quy tắc có thể áp dụng khác, không bị bỏ qua. BA phải ghi lý do, phạm vi, thời hạn, rủi ro, owner và cách phục hồi.

• Nhu cầu nghiệp vụ cấp bách: Lỗi sản xuất gây mất doanh thu trực tiếp. Owner có thẩm quyền chấp nhận quy trình rút gọn; BA vẫn ghi nhận quyết định, tác động và kiểm tra sau khắc phục.
• Proof of Concept (POC) hoặc Pilot Project: Mục tiêu là học hỏi và thử nghiệm. Artifact có thể rút gọn, nhưng giả định, tiêu chí thành công, giới hạn dữ liệu và quyết định chuyển sang triển khai chính thức phải rõ.
• Thay đổi quy định pháp lý đột ngột: Hệ thống cần sửa khẩn để đáp ứng yêu cầu mới. Legal Owner xác nhận phạm vi áp dụng; BA truy vết thay đổi tới yêu cầu, thiết kế, kiểm thử và vận hành.
• Yêu cầu kỹ thuật độc đáo, chưa có tiền lệ: Cần thử nghiệm. BA ghi giả định, tiêu chí đánh giá, rủi ro và authority chấp nhận kết quả thử nghiệm.

Truyền đạt Bất định và Đề xuất Hợp lệ

BA cao cấp không che giấu bất định. BA phân tích, ghi nhận và truyền đạt bất định để Decision Maker hiểu giới hạn bằng chứng, rủi ro và hậu quả. BA không biến giả định thành fact.

1. Nguyên tắc Truyền đạt Bất định

Bất định tồn tại khi thiếu thông tin, dữ liệu không rõ, nguồn không đáng tin cậy hoặc stakeholder mâu thuẫn. Artifact phải phân biệt fact đã xác minh, stakeholder input, assumption, decision và statement cần xác minh.

Yếu tố	Mô tả	BA Hành động
Phạm vi Bất định	Phần yêu cầu, giải pháp hoặc dữ liệu chưa rõ.	Xác định giới hạn kiến thức hiện có và artifact bị ảnh hưởng.
Nguồn Bất định	Thiếu dữ liệu, mâu thuẫn chuyên gia, biến động thị trường hoặc phụ thuộc bên thứ ba.	Ghi nguyên nhân, nguồn thông tin và owner cần xác minh.
Tác động Tiềm năng	Hậu quả nếu bất định diễn ra theo hướng bất lợi.	Đánh giá impact với chi phí, thời gian, tuân thủ, vận hành và khách hàng.
Khả năng Xảy ra	Ước tính xác suất hoặc mức độ xảy ra.	Dùng thang thấp, trung bình, cao; chỉ dùng số liệu khi có nguồn.
Kế hoạch Giảm thiểu	Hành động giảm rủi ro hoặc tăng chất lượng bằng chứng.	Đề xuất nghiên cứu, xác minh, thử nghiệm, giám sát hoặc phương án dự phòng.

2. Đề xuất Hợp lệ Dựa trên Bằng chứng

Đề xuất không cần chắc chắn 100%. Đề xuất phải bảo vệ được: dựa trên bằng chứng khả dụng tốt nhất, giả định minh bạch, trade-off rõ và có hành động nếu giả định sai.

Thành phần	Mục đích	Ví dụ Nova Foods (mô phỏng)
Giả định Minh bạch	Nêu điều kiện được tin là đúng nhưng chưa xác thực đủ.	“Giả định: Tỷ lệ khách hàng khiếu nại về thời gian giao hàng sau 30 phút không vượt 1% tổng đơn.”
Phạm vi Tin cậy	Tránh trình bày ước tính như fact cố định.	“Chi phí vận chuyển tăng ước tính 5–10% nếu ưu tiên đối tác nhanh hơn.”
Kịch bản	Nêu khả năng tốt nhất, xấu nhất và khả thi nhất.	“Tốt nhất: giao nhanh hơn, không tăng chi phí. Tệ nhất: chi phí tăng, hài lòng không tăng.”
Ngưỡng Leo thang	Xác định điều kiện phải báo cấp có thẩm quyền.	“Nếu chi phí vận chuyển trung bình tăng >10% trong 2 tuần liên tiếp.”
Phương án Dự phòng	Xác định hành động khi giả định sai hoặc kịch bản xấu xảy ra.	“Quay lại điều phối thủ công và khởi tạo phân tích A/B testing cho đối tác.”
Thẩm quyền Quyết định	Chỉ rõ vai trò chấp nhận rủi ro và quyết định triển khai.	Trưởng phòng Vận hành và Trưởng phòng Tài chính cân bằng tốc độ với chi phí.

3. Ví dụ Nova Foods: Điều phối Đơn hàng Tự động (Áp dụng)

Tình huống: Nova Foods xem xét tính năng tự động điều phối đơn hàng (NF-ORDER-AUTO-DISPATCH). Mục tiêu: tăng tốc độ giao hàng, tối ưu chi phí vận chuyển.

Sự thật: * Dữ liệu lịch sử (NF-LOG-2026-Q2-DELIVERY-TIMES) cho thấy 15% đơn hàng giao sau 30 phút. * Phân tích trả hàng (NF-RETURNS-2026-Q2-REASON-ANALYSIS) chỉ ra 0.75% tổng đơn hàng bị trả lại có lý do “chờ đợi quá lâu”. * Dữ liệu chi phí đối tác hiện tại (NF-PARTNER-COST-Q2-2026) có chênh lệch 5–15% giữa đối tác giao nhanh nhất và đối tác rẻ nhất.

Hành vi Hiện tại: Nhân viên điều phối đơn hàng thủ công, dựa trên kinh nghiệm cá nhân.

Nhu cầu Nền tảng: Cần tăng hiệu quả vận hành, giảm chi phí lao động thủ công và duy trì mức độ hài lòng khách hàng.

Các Tùy chọn: 1. Tự động chọn đối tác vận chuyển rẻ nhất. 2. Tự động chọn đối tác vận chuyển nhanh nhất. 3. Tự động chọn đối tác cân bằng tốc độ và chi phí, kèm điều kiện cùng ngưỡng giám sát.

Tiêu chí Quyết định: * Chi phí vận chuyển trung bình không tăng quá 5% so với hiện tại. * Tỷ lệ đơn hàng trả lại do “chờ lâu” không tăng quá 0.5%, từ 0.75% lên 1.25%. * Chỉ số hài lòng khách hàng (NF-CUST-SAT-INDEX) không giảm đáng kể.

Quyết định đề xuất, kèm bất định: Chọn tùy chọn 3, tự động điều phối tới đối tác cân bằng tốc độ và chi phí, có giám sát.

• Điều kiện: Hệ thống ưu tiên đối tác rẻ nhất nếu thời gian giao dự kiến dưới 20 phút. Nếu dự kiến 20–30 phút, hệ thống ưu tiên đối tác cân bằng dựa trên đánh giá hiệu suất.
• Giả định: Mối tương quan giữa thời gian giao hàng trên 30 phút và tỷ lệ trả hàng có liên quan trải nghiệm chờ đợi của khách hàng; nguyên nhân khác chưa được khảo sát đầy đủ.
• Trade-off: Phương án có thể tăng nhẹ chi phí vận chuyển để giảm rủi ro giao chậm và trả hàng.
• Rủi ro: Chi phí hoặc tỷ lệ trả hàng có thể tăng nếu giả định không chính xác.

Thẩm quyền: Trưởng phòng Vận hành (BUS-OWNER-OPS-MANAGER) và Trưởng phòng Tài chính (BUS-OWNER-FIN-MANAGER) là authority đồng thuận chấp nhận mức rủi ro theo các ngưỡng giám sát. Artifact vẫn ở trạng thái IN_REVIEW; quyết định triển khai chỉ có hiệu lực khi authority ghi nhận quyết định trong artifact quản trị phù hợp.

Artifact Liên quan: NF-REQ-DELIVERY-AUTO-003 — yêu cầu tính năng điều phối vận chuyển tự động Nova Foods.

Hậu quả nếu sai: Nếu tỷ lệ trả hàng liên quan thời gian chờ tăng vượt 0.5% trong 4 tuần đầu triển khai, hoặc chi phí vận chuyển tăng quá 5%, hệ thống phải dừng tự động điều phối cho đơn hàng dự kiến giao 20–30 phút. Vận hành quay lại điều phối thủ công. BA khởi tạo phân tích nguyên nhân gốc (BA-ACT-ROOT-CAUSE-ANALYSIS) để xác định vấn đề, cập nhật bằng chứng và trình authority quyết định tiếp theo.

12. Associated Template Reference & Completed Artifact

Quick Reference

Mục này liệt kê mẫu tài liệu liên quan Nova Foods Delivery Pack mô phỏng. Mỗi mẫu xác định ID, tên tệp, mục đích, ranh giới dùng, Owner, Consumer và Quality Gate.

Owner duy trì mẫu, kiểm soát thay đổi mẫu và xác nhận artifact dùng đúng mục đích. Consumer dùng mẫu tạo, rà soát hoặc kiểm thử artifact. Quality Gate đánh giá artifact trước khi chuyển cho Consumer; Quality Gate không cấp trạng thái APPROVED hoặc BASELINED cho artifact mô phỏng.

ID Mẫu	Tên tệp dự kiến	Khi sử dụng	Khi KHÔNG sử dụng	Chủ sở hữu (Owner)	Người dùng (Consumer)	Cổng chất lượng (Quality Gate)
GEN-TMPL-BRD-001	NF_DP_BRD_v0.9.0.docx	Ghi nhận Business Requirements Document: mục tiêu, phạm vi, stakeholder, outcome và yêu cầu nghiệp vụ cấp cao của Delivery Pack. Dùng khi Business Owner cần tầm nhìn chung.	Không dùng thay đặc tả kỹ thuật chi tiết, Use Case hoặc Business Rule đơn lẻ.	BUS-OWNER-DELIVERY-LEAD, Lead BA	Project Manager, Solution Architect, Development Lead, QA Lead, Business Stakeholders	Business Owner (BUS-OWNER-DELIVERY-LEAD) rà soát phạm vi và outcome. Lead BA kiểm tra từng yêu cầu truy vết mục tiêu kinh doanh. Artifact nêu rõ phạm vi trong, phạm vi ngoài, giả định và rủi ro.
GEN-TMPL-UC-001	NF_DP_UseCases_v0.9.0.xlsx	Đặc tả Use Case: actor, mục tiêu, trigger, pre-condition, main flow, alternate flow, exception flow và post-condition cho tương tác người dùng với hệ thống.	Không dùng cho hành vi không có actor trực tiếp, cấu trúc dữ liệu hoặc Business Rule độc lập.	BA	System Analyst, UI/UX Designer, Developers, QA Engineers	BA kiểm tra actor, trigger, pre-condition và post-condition. QA Lead kiểm tra mỗi bước có outcome quan sát được. Luồng chính, thay thế và ngoại lệ không mâu thuẫn yêu cầu truy vết.
GEN-TMPL-P-001	NF_DP_ProcessFlow_v0.9.0.svg	Biểu diễn AS-IS hoặc TO-BE cho quy trình giao hàng: bước xử lý, vai trò, handoff, luồng thông tin và điểm quyết định. Dùng khi stakeholder cần thống nhất vận hành.	Không dùng thay Logical Data Dictionary, API contract hoặc kiến trúc hệ thống.	BA, BUS-OWNER-OPS-MANAGER	Business Stakeholders, System Analyst, Developers, QA Engineers	BUS-OWNER-OPS-MANAGER xác nhận quy trình phản ánh mô phỏng đã nêu. BA xác định điểm bắt đầu, kết thúc, actor, handoff và exception. Nếu dùng BPMN, ký hiệu phải nhất quán trong sơ đồ.
GEN-TMPL-DD-001	NF_DP_LogicalDataDict_v0.9.0.xlsx	Định nghĩa logical data entities, attributes, relationships, ngữ nghĩa, kiểu dữ liệu và constraints liên quan giao hàng. Dùng khi các bên cần hiểu dữ liệu nhất quán.	Không dùng thay physical database schema, migration script hoặc quyết định kiến trúc lưu trữ.	BA, Data Architect	System Analyst, Developers, DBAs, QA Engineers	Mỗi trường có định nghĩa, kiểu dữ liệu, nguồn, ràng buộc và owner dữ liệu khi thông tin đó có trong artifact. Data Architect rà soát trùng lặp ngữ nghĩa và quan hệ dữ liệu.
GEN-TMPL-RTM-001	NF_DP_RTM_v0.9.0.xlsx	Liên kết Business Requirements, Functional Requirements, Business Rules, Use Cases, test cases và artifact liên quan. Dùng để kiểm tra coverage và tác động thay đổi.	Không dùng thay nội dung yêu cầu nguồn. RTM quản lý liên kết, không thay BRD hoặc Use Case.	BA, Project Manager	Project Manager, QA Lead, Development Lead, Business Stakeholders	Mỗi yêu cầu có ID duy nhất. Lead BA kiểm tra truy vết hai chiều từ yêu cầu đến test case và ngược lại. QA Lead kiểm tra requirement chưa có test case được ghi nhận là gap, không bị coi là đã kiểm thử.

Danh mục kiểm tra chương và Vị trí Artifact Nova Foods

Bảng này kiểm tra phạm vi chương của handbook. Trạng thái chương 12 giữ IN_REVIEW. Trạng thái này nghĩa là nội dung còn cần Owner chuyên môn xác minh; không phải xác nhận nghiệp vụ, pháp lý, kỹ thuật hoặc vận hành.

ID Chương	Tiêu đề Chương	Trạng thái hiện hành	Mục tiêu chính
1	1. Concept là gì?	Hoàn thành	Hiểu định nghĩa gốc.
2	2. Tại sao concept này tồn tại?	Hoàn thành	Biết mục đích, giá trị cốt lõi.
3	3. Vị trí trong Lifecycle	Hoàn thành	Xác định bối cảnh BA hoạt động.
4	4. Input cần thiết	Hoàn thành	Nắm rõ đầu vào bắt buộc để bắt đầu.
5	5. Step-by-step BA Activities	Hoàn thành	Hướng dẫn quy trình BA từng bước.
6	6. Output thu được	Hoàn thành	Nhận diện sản phẩm đầu ra của BA.
7	7. Who consumes those outputs?	Hoàn thành	Hiểu người dùng, bên liên quan sản phẩm.
8	8. Detailed Worked Example	Hoàn thành	Ví dụ thực tế chi tiết đã qua.
9	9. Related Concepts & Dependencies	Hoàn thành	Mở rộng kiến thức, liên kết khái niệm.
10	10. Common Mistakes & Anti-patterns	Hoàn thành	Học từ sai lầm thường gặp, tránh lỗi.
11	11. Senior BA Notes & Rules of Thumb	Hoàn thành	Rút kinh nghiệm thực chiến từ chuyên gia.
12	12. Associated Template Reference & Completed Artifact	IN_REVIEW	Tổng kết tài liệu, tham chiếu artifact và ghi nhận điểm cần xác minh trước bàn giao.

Vị trí artifact Nova Foods: /07-artifacts/nova-foods/delivery-pack/NF-DELIVERY_PACK-SYNTHETIC_V0.9.0.md.

Artifact là Delivery Pack mô phỏng. Principal IT Business Analyst / Technical Curriculum Author duy trì artifact để học viên thấy cấu trúc đầu ra BA. Artifact không đại diện hồ sơ nghiệp vụ thật Nova Foods, không thay quyết định Owner và không được dùng làm đầu vào production.

Metadata Artifact mô phỏng Nova Foods Delivery Pack:

Trường kiểm soát	Giá trị	Giải thích
Artifact ID	NF_DELIVERY_PACK_SYNTHETIC	Định danh duy nhất gói giao nhận mô phỏng.
Tên tệp	/07-artifacts/nova-foods/delivery-pack/NF-DELIVERY_PACK-SYNTHETIC_V0.9.0.md	Đường dẫn canonical file chứa nội dung gói giao nhận.
Tiêu đề	Nova Foods Capstone ERP Delivery Pack — Synthetic	Tên gói giao nhận. Dữ liệu tổng hợp.
Trạng thái	IN_REVIEW	Artifact đang xem xét. Chưa APPROVED hoặc BASELINED.
Phiên bản	v0.9.0	Đồng bộ phiên bản handbook v0.9.0.
Owner	Principal IT Business Analyst / Technical Curriculum Author	Owner duy trì cấu trúc, ghi nhận giới hạn và điều phối xác minh. Owner không có thẩm quyền phê duyệt nghiệp vụ, pháp lý, kế toán hoặc bảo mật Nova Foods.
Mục đích	Minh họa quá trình và kết quả BA capstone cho học viên.	Không dùng làm tài liệu nghiệp vụ Nova Foods.
Phạm vi dữ liệu	Dữ liệu tổng hợp (synthetic data)	Không phản ánh dữ liệu kinh doanh thật Nova Foods.
Giới hạn thẩm quyền	Không thay thế quyết định nghiệp vụ, pháp lý, kế toán, bảo mật Nova Foods.	Chỉ dùng làm ví dụ giáo dục.
Thời điểm tạo	2026-08-07	Thời điểm artifact khởi tạo nội dung mô phỏng.

Artifact chứa ví dụ cấu trúc Delivery Pack theo nguyên tắc chương 1 đến chương 11: nguồn đầu vào, yêu cầu, quy tắc nghiệp vụ mô phỏng, dữ liệu mô phỏng, truy vết, Consumer và tiêu chí kiểm tra. Người dùng phải đọc metadata, trạng thái IN_REVIEW và bảng xác minh bên dưới trước khi dùng bất kỳ nội dung nào làm căn cứ quyết định.

Đánh giá nội bộ và Điểm cần xác minh trước bàn giao

Rà soát nội bộ xác định các điểm cần xác minh. Mỗi Owner chuyên môn phải kiểm tra nội dung thuộc thẩm quyền của mình, ghi nhận kết quả trong quy trình quản trị phù hợp và yêu cầu sửa artifact khi phát hiện sai lệch. Khi chưa có xác minh đó, Consumer phải coi nội dung là mô phỏng giáo dục.

Mục cần xác minh	Tác động	Chủ sở hữu xác minh	Lý do / Tham chiếu
Quy tắc nghiệp vụ Nova Foods	Ví dụ NF-DELIVERY_PACK-SYNTHETIC_V0.9.0.md có quy tắc nghiệp vụ mô phỏng. Không quy tắc baseline. Sai quy tắc có thể làm BA, Developer hoặc QA hiểu sai outcome vận hành.	Business Owner, Legal Owner (pháp lý), Accounting Owner (kế toán).	/01-curriculum/CANONICAL_BUSINESS_RULES.md là kế hoạch, trạng thái IN_REVIEW. Nội dung Nova Foods là dữ liệu tổng hợp giáo dục. Cần xác nhận nghiệp vụ thực tế.
Định nghĩa dữ liệu Nova Foods	Ví dụ NF-DELIVERY_PACK-SYNTHETIC_V0.9.0.md dùng trường, định dạng, ràng buộc dữ liệu mô phỏng. Sai định nghĩa có thể gây mapping sai, kiểm thử sai hoặc báo cáo sai.	Data Owner, Architect.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md là kế hoạch, trạng thái IN_REVIEW. Cần xác nhận kiến trúc dữ liệu và nghiệp vụ thực tế.
Tuân thủ quy định Nova Foods	Bất kỳ tuyên bố tuân thủ luật pháp Việt Nam về bảo mật dữ liệu, an toàn thực phẩm, hóa đơn hoặc chứng từ trong ví dụ đều cần kiểm tra. Diễn giải sai có thể tạo nhận định pháp lý không có thẩm quyền.	Legal Owner, Compliance Owner, Food Safety Owner.	Luật 91/2025/QH15, Luật 55/2010/QH12, NĐ 123/2020/NĐ-CP yêu cầu xác minh chuyên gia pháp lý. Handbook chỉ là ví dụ giáo dục, không có hiệu lực pháp lý.
Yêu cầu bảo mật Nova Foods	Điểm kiểm soát bảo mật và xử lý dữ liệu nhạy cảm trong ví dụ cần được đối chiếu yêu cầu thực tế. Sai kiểm soát có thể làm Consumer áp dụng biện pháp không đủ hoặc không phù hợp.	Security Owner, Architect.	Tham chiếu OWASP ASVS, OWASP API Security Top 10. /01-curriculum/TRACEABILITY_ID_REGISTRY.md quy định escalation khi có yêu cầu kiểm soát bảo mật.
Tính khả thi kỹ thuật	Mô tả giải pháp và tích hợp, nếu có, trong ví dụ cần được đánh giá. Giải pháp không khả thi có thể làm Development Lead ước lượng hoặc triển khai sai.	Architect, Technical Lead.	Đảm bảo giả định giải pháp hợp lý về mặt kỹ thuật, không xung đột với các nguyên lý kiến trúc hệ thống Nova Foods mô phỏng.
ID truy vết Capstone	ID tham chiếu, gồm REQ-NF-001 và BR-NF-005 nếu xuất hiện trong NF-DELIVERY_PACK-SYNTHETIC_V0.9.0.md, phải đúng cấu trúc kế hoạch. ID sai làm đứt truy vết yêu cầu, kiểm thử và thay đổi.	Principal IT Business Analyst / Technical Curriculum Author.	Kiểm tra định dạng, mục đích sử dụng ID theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md để đảm bảo tính nhất quán và truy vết.
Trạng thái artifact nhất quán	23-capstone-nova-foods-delivery-pack.md và NF-DELIVERY_PACK-SYNTHETIC_V0.9.0.md phải cùng thể hiện IN_REVIEW. Trạng thái sai có thể khiến Consumer coi artifact là sẵn sàng production.	Principal IT Business Analyst / Technical Curriculum Author.	Xác nhận trạng thái không bị hiểu là APPROVED, BASELINED hoặc production-ready. Owner phải nêu rõ giới hạn thẩm quyền cho Consumer.