24 Capstone Review And Evaluation

Artifact Governance Metadata

Trường kiểm soát	Giá trị
Artifact ID	HD24_CAPSTONE_REVIEW_EVAL
Tên tệp	/02-handbook/24-capstone-review-and-evaluation.md
Tiêu đề tài liệu	24 Capstone Review And Evaluation
Trạng thái	IN_REVIEW
Ý nghĩa trạng thái	Artifact đang được xem xét. Nội dung chưa được phê duyệt, chưa được chấp thuận làm baseline và không tạo approval ngầm định cho yêu cầu, giải pháp hoặc quyết định Nova Foods.
Phiên bản	v0.9.0
Ý nghĩa phiên bản	Phiên bản xác định bản nội dung đang được xem xét. Mọi thay đổi sau bản này phải được ghi nhận bằng phiên bản cập nhật để người review đối chiếu đúng artifact.
Ngày cập nhật cuối	2026-08-07
Ý nghĩa ngày cập nhật	Ngày này xác định mốc mới nhất của nội dung artifact để reviewer, owner và bên nhận bàn giao kiểm tra độ tươi mới trước khi sử dụng.
Owner	Principal IT Business Analyst / Technical Curriculum Author
Trách nhiệm Owner	Duy trì tính nhất quán nội dung chapter này, kiểm soát phiên bản, ghi nhận lịch sử thay đổi, bảo đảm liên kết quản trị. Owner chịu trách nhiệm về nội dung học liệu, không có thẩm quyền nghiệp vụ Nova Foods.
Giới hạn thẩm quyền Owner	Owner không có quyền tự phê duyệt nội dung, xác nhận yêu cầu nghiệp vụ, chấp thuận giải pháp, phê duyệt baseline, quyết định vận hành, quyết định pháp lý, kế toán, bảo mật cho Nova Foods hoặc thay thế thẩm quyền của các bên liên quan.
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale áp dụng	vi-VN; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp
Phân loại artifact	Nội dung chapter trong Handbook
Trạng thái baseline	Chưa baseline. Trạng thái IN_REVIEW không đồng nghĩa BASELINED.
Trạng thái phê duyệt	Chưa phê duyệt. Không có approval ngầm định từ sự tồn tại của metadata.

1. Concept l? g??

Core

Capstone Review And Evaluation (Đánh giá tổng kết cuối cùng) là bài tập lớn cuối khóa. Mục đích kiểm tra toàn diện năng lực Business Analyst (BA). Bài tập yêu cầu BA giải quyết một vấn đề nghiệp vụ phức tạp. Vấn đề có tính thực tế, tích hợp nhiều kiến thức, kỹ năng đã học.

BA phải ứng dụng các quy trình BA. Bao gồm thu thập yêu cầu, phân tích, thiết kế giải pháp. Cũng cần giao tiếp, trình bày, đàm phán. Bài tập mô phỏng môi trường dự án thực tế. BA tự chịu trách nhiệm về toàn bộ vòng đời phân tích của một phân đoạn giải pháp.

Đầu ra bài tập là bằng chứng năng lực BA. Nó cho thấy BA có khả năng: hiểu vấn đề, đề xuất giải pháp, truyền đạt rõ ràng, làm việc độc lập. Đây là kiểm tra tổng hợp. Không chỉ kiến thức lý thuyết, mà cả kỹ năng thực hành, tư duy phản biện. Giúp nhận diện điểm mạnh, điểm yếu BA. Cho phép cải thiện trước khi vào dự án thực.

Giải thích thuật ngữ chuyên môn

Actor (Tác nhân): Cá nhân, nhóm, tổ chức hoặc hệ thống. Tương tác trực tiếp hệ thống/quy trình nghiệp vụ. BA xác định tác nhân để hiểu ai (who) yêu cầu, sử dụng chức năng. Xác định vai trò rõ ràng, tránh chồng chéo trách nhiệm.

Action (Hành động): Hoạt động cụ thể tác nhân hoặc hệ thống thực hiện. Hành động thay đổi trạng thái, thực thi chức năng, xử lý dữ liệu. BA phân tích hành động để mô tả cách (how) nghiệp vụ hoàn thành, quy trình hoạt động.

Object (Đối tượng): Thực thể, dữ liệu hoặc tài nguyên. Bị hành động tác động lên. Đối tượng là cái (what) hành động đang thao tác. Ví dụ: hệ thống Nova Foods, đối tượng có thể "Đơn hàng", "Sản phẩm", "Khách hàng".

Outcome (Kết quả): Trạng thái mong muốn hoặc giá trị đạt được sau hành động hoàn tất. Đây là tại sao (why) hành động thực hiện, lợi ích mang lại. BA đo lường kết quả để đánh giá hiệu quả giải pháp, xác nhận mục tiêu nghiệp vụ đạt được.

Ví dụ Nova Foods và Phạm vi Concept

Ví dụ Nova Foods (Mô phỏng): Quy trình Nhập kho Nguyên vật liệu

Nova Foods: sản xuất thực phẩm đông lạnh. Nhập kho NVL: vấn đề.

• Vấn đề: Thủ kho: ghi sổ tay. Kế toán kho: nhập liệu thủ công. Sai sót nhiều. Tồn kho ảo. NVL thiếu đột xuất, sản xuất khó. NVL thừa, quá hạn, lãng phí.
• Concept (Ý tưởng chung): "Tối ưu nhập kho NVL. Dùng hệ thống số hóa."
  • Mục tiêu:
    • Tồn kho NVL chính xác 98%.
    • Giảm 15% NVL hư hỏng.
    • Giảm 20% thời gian kiểm đếm, nhập liệu.
    • Luôn đủ NVL sản xuất.
  • Actor: Thủ kho, Kế toán kho, Quản lý sản xuất, Nhà cung cấp.
  • Hoạt động: Kế hoạch mua NVL → Đặt hàng → Nhận hàng → Kiểm tra chất lượng → Nhập kho → Cập nhật tồn kho → Thanh toán.
  • Kết quả: Hệ thống tự động theo dõi NVL. Báo tồn kho thấp. Quy trình rõ ràng. Ít lỗi.

Ranh giới Concept (Phạm vi hiện tại):

Concept đầu: nhìn bức tranh lớn. Không chi tiết.

Yếu tố	Bao gồm	Loại trừ
Mục tiêu	Vấn đề cốt lõi. Mục tiêu nghiệp vụ tổng thể.	KPI chi tiết. Cách đo lường. Công thức tính.
Actor	Vai trò chính liên quan vấn đề.	Phân quyền chi tiết. Luồng phê duyệt từng bước.
Quy trình	Các bước nghiệp vụ chính (cấp độ cao).	Luồng xử lý ngoại lệ. Bước nhỏ. Điều kiện rẽ nhánh phức tạp.
Dữ liệu	Loại dữ liệu cần (NVL, đơn hàng, tồn kho).	Trường dữ liệu cụ thể. Kiểu dữ liệu. Ràng buộc. Quan hệ bảng.
Công nghệ	Hướng chung (số hóa, tự động hóa).	Nền tảng cụ thể (ERP, độc lập). Ngôn ngữ lập trình. Kiến trúc hệ thống.
Tích hợp	Cần tương tác hệ thống khác (Kế toán).	Chi tiết API. Định dạng dữ liệu. Cơ chế đồng bộ.

Concept: không "làm thế nào". Chỉ "cần làm gì" và "tại sao". Chi tiết kỹ thuật, giao diện, logic phức tạp: giai đoạn sau.

2. Tại sao concept này tồn tại?

Core

Capstone Review And Evaluation (Đánh giá & rà soát cuối giai đoạn/dự án): Bước kiểm tra cuối cùng dự án hoặc giai đoạn chính. Đảm bảo kết quả đúng, đầy đủ, sẵn sàng vận hành. Không làm bước này, dự án gặp nhiều vấn đề.

• Thất bại dự án (Project failure): Dự án hoàn thành. Sản phẩm không dùng được. Không giải quyết vấn đề nghiệp vụ gốc. Tiêu tốn nguồn lực lớn.
• Làm lại (Rework): Lỗi phát hiện muộn. Sau khi triển khai (Go-live). Sửa tốn nhiều tiền, thời gian. Ảnh hưởng hoạt động kinh doanh.
• Mơ hồ (Ambiguity): Yêu cầu không rõ ràng. Phạm vi dự án không định nghĩa chặt. Các bên hiểu khác nhau. Mỗi đội làm một kiểu.
• Rủi ro quản trị (Governance risk): Thiếu kiểm soát. Thay đổi không theo quy trình. Không tuân thủ quy định pháp luật. Không có trách nhiệm giải trình rõ ràng.

Concept Capstone Review fix lỗi này. Đảm bảo kiểm tra tổng thể.

Applied

Dự án ERP lớn (Nova Foods là case study mô phỏng, dữ liệu tổng hợp). Nhiều module, nhiều nghiệp vụ, nhiều quy định. Capstone Review quan trọng.

• Ngăn mơ hồ, thiếu sót chức năng:
  • Vấn đề: Yêu cầu chung chung "Hệ thống ERP phải tốt hơn". Thiếu đặc tả rõ ràng về hiệu suất, luồng phê duyệt, tích hợp với hệ thống bên ngoài (ví dụ: cổng thanh toán).
  • Rủi ro: Phát triển thừa tính năng không dùng. Bỏ quên tính năng cốt lõi. Người dùng cuối nhận hệ thống không đáp ứng.
• Ngăn làm lại tốn kém:
  • Vấn đề: Module mua hàng, kho, kế toán phát triển riêng. Tích hợp giữa chúng không kiểm tra toàn diện.
  • Rủi ro: Dữ liệu tồn kho lệch với kế toán. Xuất hóa đơn sai định dạng. Nova Foods phải sửa lỗi tích hợp khẩn cấp sau Go-live. Tốn kém hơn nhiều so với sửa trước.
• Ngăn rủi ro tuân thủ:
  • Vấn đề: Việt Nam có nhiều luật. Luật Kế toán (88/2015/QH13), Nghị định về Hóa đơn (123/2020/NĐ-CP). Hệ thống ERP phải tuân thủ.
  • Rủi ro: Báo cáo không đúng mẫu. Thiếu trường thông tin bắt buộc. Hệ thống xử lý chứng từ sai quy định. Nova Foods đối mặt với phạt hành chính, rủi ro pháp lý.
• Ngăn thất bại dự án:
  • Vấn đề: Thiếu kiểm tra tổng thể. Hệ thống chạy. Người dùng không tin cậy. Dữ liệu sai thường xuyên.
  • Rủi ro: Hệ thống ERP bị bỏ. Nova Foods tiếp tục dùng cách thủ công. Đầu tư lãng phí.

Mermaid: Dự án không review cuối giai đoạn so với có review.

graph TD
    subgraph "Trước Capstone Review (Rủi ro cao)"
        A[Yêu cầu mơ hồ] --> B{Phát triển riêng lẻ}
        B --> C[Triển khai Go-Live]
        C --> D{Vấn đề xuất hiện}
        D -- "Sửa lỗi tốn kém" --> E[Làm lại (Rework)]
        D -- "Thiếu tuân thủ" --> F[Rủi ro Pháp lý/Phạt]
        D -- "Người dùng không hài lòng" --> G[Thất bại dự án]
    end

    subgraph "Sau Capstone Review (Kiểm soát rủi ro)"
        H[Yêu cầu rõ ràng] --> I{Phát triển theo kế hoạch}
        I --> J{Capstone Review}
        J -- "Phát hiện thiếu sót sớm" --> K[Điều chỉnh trước Go-Live (Hiệu quả)]
        J -- "Xác nhận sẵn sàng" --> L[Triển khai Go-Live thành công]
        L --> M[Người dùng hài lòng]
        L --> N[Tuân thủ được xác minh]
    end

Senior Lens

Giá trị kinh doanh: Capstone Review là chốt chặn cuối. Đảm bảo ERP mang lại giá trị. Không chỉ hoạt động, mà phải đúng, an toàn, tuân thủ. Tránh phát hiện lỗi khi đã quá muộn. Chi phí sửa lỗi tăng theo cấp số nhân khi dự án đi xa.

Quản lý rủi ro: Giảm rủi ro tài chính, vận hành, pháp lý, danh tiếng. Đặc biệt với ERP. Ảnh hưởng toàn bộ Nova Foods. Không phải chỉ một phòng ban.

Quyết định dựa trên dữ liệu: Review cung cấp dữ liệu khách quan. Cho phép Business Owner, Head of IT ra quyết định Go-live hay chưa. Giảm yếu tố cảm tính. Tăng trách nhiệm giải trình.

Quick Reference

Vấn đề ngăn chặn	Mô tả chung	Hậu quả chính
Thất bại chức năng nghiệp vụ	Hệ thống không đáp ứng yêu cầu cốt lõi.	Người dùng không sử dụng, buộc quay về phương pháp cũ.
Sai lệch / Thiếu dữ liệu	Dữ liệu không khớp giữa các module, không đủ trường.	Quyết định kinh doanh sai, báo cáo tài chính không tin cậy.
Không tuân thủ pháp luật	Hệ thống vi phạm quy định (kế toán, hóa đơn, an toàn thực phẩm).	Nova Foods bị phạt, bị kiện, uy tín giảm.
Trải nghiệm người dùng kém	Hệ thống khó sử dụng, quy trình phức tạp.	User kháng cự, cần đào tạo lại, chi phí hỗ trợ cao.
Làm lại tốn kém	Lỗi phát hiện sau khi triển khai, đòi hỏi chỉnh sửa lớn.	Lãng phí tài chính, chậm tiến độ, gián đoạn kinh doanh.
Rủi ro an ninh	Lỗ hổng bảo mật chưa được vá.	Mất dữ liệu, tấn công mạng, vi phạm Luật Bảo vệ dữ liệu cá nhân (91/2025/QH15).

Minh họa Trước/Sau: Hậu quả quan sát được từ Nova Foods

Concept Đánh giá và Tổng kết Dự án (Capstone Review and Evaluation) tồn tại vì nó giải quyết trực tiếp các vấn đề phát sinh khi dự án được tuyên bố hoàn thành nhưng giá trị thực sự, sự phù hợp với hoạt động vận hành và tính bền vững của giải pháp chưa được kiểm chứng đầy đủ. Thiếu quy trình này dẫn đến chi phí ẩn, làm lại (rework), rủi ro quản trị và giảm niềm tin vào khả năng giao sản phẩm của tổ chức.

Core

Trước khi có Capstone Review, các dự án tại Nova Foods (mô phỏng) thường được xem là "hoàn thành" ngay sau khi triển khai và bàn giao. Việc thiếu một quy trình đánh giá có cấu trúc, độc lập và toàn diện sau vận hành thực tế đã che giấu nhiều vấn đề tiềm ẩn. Các vấn đề này bao gồm: giải pháp không đáp ứng đủ nhu cầu nghiệp vụ thay đổi, tích hợp hệ thống gặp lỗi nhẹ không được phát hiện ngay, hoặc chi phí vận hành tăng do quy trình mới kém hiệu quả. Hậu quả là tổ chức phải gánh chịu nợ kỹ thuật (technical debt), chi phí sửa chữa đột xuất, hoặc thậm chí là thất bại trong việc đạt được mục tiêu kinh doanh chiến lược đã đặt ra cho dự án ban đầu.

Applied

Nova Foods đã triển khai mô-đun "Quản lý Tồn kho" (Inventory Management) trong hệ thống ERP của mình. Phân tích trước/sau (Before/After) cho thấy tầm quan trọng của Capstone Review.

• Facts (Sự thật đã kiểm chứng):

  • Nova Foods vận hành nhiều kho hàng với hàng nghìn SKU (Stock Keeping Unit).
  • Độ chính xác tồn kho ảnh hưởng trực tiếp đến chuỗi cung ứng, sản xuất và tài chính.
  • Hệ thống ERP là công cụ cốt lõi.

• Current Behavior (Hành vi trước Capstone Review):

  • Tình huống trước (Before): Dự án triển khai mô-đun Quản lý Tồn kho v1.0 hoàn thành, go-live tháng 3/2026. Nhóm dự án báo cáo trạng thái "Xanh lá cây" (Green), bàn giao tài liệu và chuyển sang dự án khác.
  • Quan sát (Stakeholder Input): Sau 3 tháng vận hành, phòng Vận hành kho liên tục báo cáo dữ liệu tồn kho trong hệ thống (ERP) lệch 15-20% so với kiểm kê thực tế tại kho. Phòng IT lập luận "hệ thống đúng theo đặc tả yêu cầu (spec)", trong khi phòng Kế toán gặp khó khăn trong đối chiếu sổ sách. Tình trạng hàng tồn kho quá hạn sử dụng không được xử lý kịp thời tăng 10%.
  • Hậu quả quan sát được:
    • Chi phí kiểm kê định kỳ tăng 20% do phải kiểm đếm thủ công nhiều hơn.
    • Quyết định mua hàng sai lệch do thông tin tồn kho không chính xác.
    • Mất mát doanh thu do thiếu hàng bán (stock-out) hoặc hàng quá hạn không bán được.
    • Nhân sự kho và kế toán không tin tưởng vào dữ liệu hệ thống, tạo ra các "excel riêng" để quản lý.

• Underlying Need (Nhu cầu cốt lõi): Xác định liệu giải pháp phần mềm có thực sự mang lại giá trị kinh doanh như mong đợi và hoạt động hiệu quả trong môi trường vận hành thực tế hay không, đồng thời rút ra bài học kinh nghiệm cho các dự án tương lai.

• Options (Các lựa chọn):

  1. Duy trì trạng thái cũ: Chỉ dựa vào báo cáo tiến độ và nghiệm thu ban đầu. (Bị từ chối do hậu quả đã rõ).
  2. Đánh giá định kỳ: Thường xuyên thu thập phản hồi từ người dùng nhưng không có cấu trúc tổng thể. (Không đủ sâu sắc).
  3. Học hỏi sau thất bại (Post-Mortem): Chỉ thực hiện khi dự án đã rõ ràng thất bại. (Quá muộn).
  4. Capstone Review (Đánh giá và Tổng kết Dự án): Thực hiện một đánh giá toàn diện, có cấu trúc sau khi giải pháp đã ổn định trong vận hành thực tế.

• Decision Criteria (Tiêu chí quyết định):

  • Khả năng phát hiện sớm các vấn đề tiềm ẩn sau triển khai.
  • Khả năng đo lường giá trị kinh doanh thực tế.
  • Khả năng cải thiện sự phối hợp liên phòng ban.
  • Khả năng tổng hợp bài học cho dự án tiếp theo.

• Decision (Quyết định): Nova Foods quyết định triển khai quy trình Capstone Review và Evaluation cho tất cả các dự án chiến lược, bắt đầu từ v1.1 của mô-đun Quản lý Tồn kho.

• Authority (Thẩm quyền): Ban Giám đốc và Phòng Quản lý Dự án (PMO) của Nova Foods.

• Artifact (Sản phẩm đầu ra): Tài liệu 24-capstone-review-and-evaluation.md này (quy trình, hướng dẫn), và template GEN-TMPL-CR-001_Capstone_Review_Report.md.

• Consequence if Wrong (Hậu quả nếu sai - không thực hiện Capstone Review): Các vấn đề của mô-đun Quản lý Tồn kho sẽ tiếp tục tích tụ, gây ra tổn thất lớn hơn về tài chính và uy tín, đồng thời làm mất niềm tin vào các dự án ERP tương lai.

Minh họa quy trình:

graph TD
    A[Dự án hoàn thành <br/> & Go-live] --> B{Báo cáo tiến độ <br/> "Xanh lá cây"?};
    B -- Có --> C{Bàn giao & Đóng dự án?};

    subgraph Trước Capstone Review
        C -- KHÔNG Capstone Review --> D[Vấn đề tiềm ẩn <br/> phát sinh từ vận hành thực];
        D --> E[Chi phí vận hành tăng, <br/> rework ẩn, mất niềm tin];
    end

    subgraph Với Capstone Review
        C -- CÓ Capstone Review --> F[Capstone Review <br/> (sau Go-live vài tháng)];
        F --> G{Xác nhận giá trị <br/> kinh doanh thực <br/> & Mục tiêu dự án đạt?};
        G -- Có --> H[Đóng dự án chính thức, <br/> ghi nhận bài học];
        G -- Không / Có vấn đề --> I[Xác định gốc rễ, <br/> kế hoạch cải tiến/sửa chữa];
        I --> J[Tái đánh giá hiệu quả <br/> sau cải tiến];
    end

Senior Lens

Việc thiếu một Capstone Review hiệu quả không chỉ là rủi ro về chất lượng phần mềm mà còn là rủi ro chiến lược kinh doanh. Nó làm mờ đi ranh giới giữa thành công và thất bại thực sự của dự án, dẫn đến việc đưa ra các quyết định sai lầm cho các dự án kế tiếp dựa trên thông tin không chính xác. Các vấn đề ẩn giấu sẽ tích lũy thành nợ kỹ thuật và nợ nghiệp vụ (business debt), làm suy yếu hệ thống và tăng chi phí sở hữu tổng thể (TCO - Total Cost of Ownership) của hệ thống ERP. Capstone Review là cơ chế quản trị (governance mechanism) thiết yếu để đảm bảo đầu tư vào công nghệ thực sự mang lại lợi nhuận bền vững.

Quick Reference

Điểm khác biệt	Trước Capstone Review	Sau khi áp dụng Capstone Review
Phạm vi đánh giá	Chỉ tập trung vào bàn giao deliverable, chức năng đúng spec (đặc tả).	Đánh giá toàn diện giá trị kinh doanh, hiệu quả vận hành thực tế, sự phù hợp với hệ sinh thái tổng thể.
Thời điểm	Ngay sau go-live/bàn giao.	Sau khi hệ thống ổn định trong môi trường vận hành thực tế (thường 1-3 tháng sau go-live).
Phát hiện vấn đề	Vấn đề vận hành thực tế, độ phù hợp nghiệp vụ thường bị bỏ qua hoặc phát hiện muộn.	Phát hiện sớm các vấn đề "sống còn" sau go-live, đặc biệt là lỗi quy trình hoặc sự thiếu ăn khớp giữa hệ thống và nghiệp vụ.
Bài học kinh nghiệm	Không có hoặc không có cấu trúc.	Được tổng hợp, ghi nhận rõ ràng để tránh lặp lại ở dự án sau.
Niềm tin vào hệ thống	Thấp nếu vấn đề tồn đọng nhiều.	Cao hơn, giúp người dùng và quản lý tin tưởng vào dữ liệu và hệ thống.
Chi phí	Chi phí rework, vận hành ẩn tăng cao.	Giảm chi phí rework, giảm nợ kỹ thuật và nghiệp vụ, tăng hiệu quả đầu tư.

Quản lý Nguồn Thông tin: Phân biệt Thực tế, Đóng góp, Giả định, Quyết định và Tuyên bố

Việc phân biệt các loại thông tin khác nhau là cốt lõi để Business Analyst (BA) đưa ra phân tích chính xác, quản lý rủi ro hiệu quả và xây dựng giải pháp khả thi. Nhầm lẫn giữa chúng dẫn đến thiết kế hệ thống sai, làm lại (rework), và thất bại dự án.

### Core

Để đảm bảo tính minh bạch và độ tin cậy của thông tin trong dự án, BA cần hiểu rõ và phân loại chính xác các nguồn thông tin khác nhau:

• Thực tế đã xác minh (Verified Fact): Là thông tin khách quan, đã được chứng minh là đúng thông qua bằng chứng cụ thể và đáng tin cậy. Nguồn gốc của thực tế này thường là tài liệu pháp lý, tiêu chuẩn ngành, dữ liệu lịch sử hệ thống, hoặc kết quả kiểm tra độc lập. Thực tế đã xác minh cung cấp nền tảng vững chắc cho mọi phân tích.
• Đóng góp của bên liên quan (Stakeholder Input): Là thông tin thu thập trực tiếp từ các bên liên quan (stakeholders) về nhu cầu, mong muốn, quan điểm hoặc kinh nghiệm của họ. Đây thường là thông tin chủ quan, phản ánh góc nhìn cá nhân và có thể chưa được xác minh hoặc mâu thuẫn với các đóng góp khác.
• Giả định dự án (Project Assumption): Là một điều kiện hoặc sự kiện mà chúng ta tin là đúng, sẽ đúng hoặc có thể đúng trong tương lai mà không có bằng chứng chắc chắn tại thời điểm hiện tại. Giả định được chấp nhận để phục vụ cho việc lập kế hoạch hoặc thiết kế giải pháp nhưng cần được theo dõi và xác minh sau này. Giả định mang theo rủi ro.
• Quyết định (Decision): Là một lựa chọn được đưa ra một cách chính thức sau khi xem xét các phương án, được ghi nhận và có thẩm quyền phê duyệt. Quyết định cam kết dự án theo một hướng hành động cụ thể và có tính ràng buộc.
• Tuyên bố cần xác minh (Verification-Required Claim): Là một phát biểu hoặc khẳng định được đưa ra như thể là đúng nhưng chưa có bằng chứng xác thực. Tuyên bố này yêu cầu BA phải tiến hành các hoạt động xác minh, kiểm tra hoặc nghiên cứu thêm để chuyển nó thành một "Thực tế đã xác minh" hoặc một "Giả định dự án" được chấp nhận.

Bảng sau minh họa sự khác biệt cơ bản giữa các loại thông tin:

Loại Thông tin	Bản chất	Nguồn gốc điển hình	Rủi ro khi không xử lý đúng	Hành động của BA
Thực tế đã xác minh	Khách quan, đã chứng minh	Luật pháp, tiêu chuẩn, dữ liệu hệ thống, kết quả kiểm tra	Phân tích sai nếu bỏ qua	Sử dụng làm cơ sở lập luận, thiết kế
Đóng góp của bên liên quan	Chủ quan, góc nhìn cá nhân	Phỏng vấn, workshop, khảo sát	Mâu thuẫn, thiếu chính xác, thiên vị	Thu thập, phân tích, xác minh lại với các nguồn khác
Giả định dự án	Tin là đúng, chưa chứng minh	Cuộc họp nhóm, ước tính chuyên gia	Rủi ro dự án nếu sai	Ghi nhận, theo dõi, lập kế hoạch dự phòng, xác minh
Quyết định	Lựa chọn chính thức, có thẩm quyền	Biên bản họp, email phê duyệt	Dự án đi sai hướng nếu không tuân thủ	Thực hiện, theo dõi tác động
Tuyên bố cần xác minh	Khẳng định chưa chứng minh	Yêu cầu nghiệp vụ ban đầu, nhận định không căn cứ	Giải pháp không khả thi, làm lại	Đặt câu hỏi, thu thập bằng chứng, xác minh

### Applied

Nova Foods (mô phỏng, dữ liệu tổng hợp) đang phát triển hệ thống quản lý đơn hàng mới. BA cần phân biệt các loại thông tin để đưa ra khuyến nghị phù hợp.

• Facts (Thực tế đã xác minh):
  • Thực tế: Luật Kế toán 88/2015/QH13 yêu cầu tất cả các giao dịch bán hàng phải có hóa đơn giá trị gia tăng (GTGT) hợp lệ. (Nguồn: Luật Kế toán 88/2015/QH13)
  • Thực tế: Hệ thống ERP hiện tại của Nova Foods (Dynamics 365) có API cho phép tích hợp dữ liệu đơn hàng và xuất hóa đơn điện tử theo Nghị định 123/2020/NĐ-CP. (Nguồn: Tài liệu kỹ thuật hệ thống Nova_Foods_ERP_API_Doc_v2.1.pdf, ngày 2026-08-07)
• Current Behavior (Hành vi hiện tại): Bộ phận kinh doanh Nova Foods ghi nhận đơn hàng vào một file Excel nội bộ trước khi nhập thủ công vào ERP để xuất hóa đơn.
• Underlying Need (Nhu cầu cốt lõi): Nova Foods cần quy trình ghi nhận và xử lý đơn hàng tự động, liền mạch, giảm thiểu sai sót thủ công và đảm bảo tuân thủ pháp luật về hóa đơn điện tử.
• Options (Các phương án):
  1. Phát triển module quản lý đơn hàng độc lập.
  2. Tích hợp trực tiếp module quản lý đơn hàng vào ERP hiện có.
  3. Mua một hệ thống quản lý đơn hàng của bên thứ ba và tích hợp với ERP.
• Decision Criteria (Tiêu chí ra quyết định):
  • Chi phí phát triển/mua sắm và bảo trì.
  • Thời gian triển khai.
  • Mức độ tích hợp với ERP hiện có.
  • Khả năng mở rộng và tuân thủ quy định pháp luật.
  • Ảnh hưởng đến trải nghiệm người dùng cuối.
• Decision (Quyết định): Nova Foods quyết định tích hợp module quản lý đơn hàng mới trực tiếp vào hệ thống ERP hiện có để tận dụng cơ sở hạ tầng sẵn có và API đã có, nhằm giảm chi phí và thời gian triển khai.
  • Authority (Thẩm quyền): Ban Giám đốc Nova Foods.
  • Artifact (Tài liệu): Biên bản cuộc họp phê duyệt dự án số NF-D-20260715-001, ngày 2026-07-15.
• Consequence if Wrong (Hậu quả nếu sai): Nếu quyết định sai, Nova Foods có thể phải đối mặt với chi phí phát triển vượt mức, thời gian triển khai kéo dài, hệ thống không ổn định, và rủi ro bị phạt do không tuân thủ quy định về hóa đơn điện tử.
• Stakeholder Input (Đóng góp của bên liên quan): Trưởng phòng kinh doanh Nova Foods cho biết: "Khách hàng thường yêu cầu cập nhật trạng thái đơn hàng qua SMS ngay lập tức sau khi đặt." (Đây là input, chưa phải requirement hay fact).
• Project Assumption (Giả định dự án): Hệ thống SMS Gateway hiện có của Nova Foods có khả năng xử lý 10.000 tin nhắn mỗi giờ mà không cần nâng cấp thêm. (Giả định này cần được xác minh bởi đội kỹ thuật sau này).
• Verification-Required Claim (Tuyên bố cần xác minh): "Việc tự động gửi thông báo trạng thái đơn hàng qua SMS sẽ giảm 30% cuộc gọi từ khách hàng đến bộ phận chăm sóc khách hàng." (Đây là một tuyên bố chưa có bằng chứng, cần đo lường thực tế hoặc nghiên cứu thị trường để xác minh).

### Senior Lens

Việc không phân biệt rõ ràng các loại thông tin này là nguyên nhân hàng đầu gây ra các lỗi trong đặc tả yêu cầu, dẫn đến lãng phí tài nguyên và làm giảm lòng tin của các bên liên quan. BA cấp cao phải chủ động dán nhãn (label) và theo dõi từng mảnh thông tin xuyên suốt vòng đời dự án. Thực tế đã xác minh cần được tham chiếu rõ ràng đến nguồn gốc (ví dụ: Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15). Giả định phải được ghi lại trong nhật ký giả định (assumption log) và có kế hoạch xác minh. Tuyên bố cần xác minh phải có một lộ trình hành động để thu thập bằng chứng. Bất kỳ quyết định quan trọng nào cũng phải có thẩm quyền phê duyệt rõ ràng và được ghi nhận trong các tài liệu quản trị dự án (ví dụ: 01_CURRICULUM_ARCHITECTURE.md, CANONICAL_BUSINESS_RULES.md).

### Quick Reference

Loại Thông tin	Hỏi để xác định	Ví dụ (Nova Foods)
Thực tế đã xác minh	"Bằng chứng đâu? Nguồn gốc là gì?"	"Luật 88/2015/QH13 quy định..."
Đóng góp của bên liên quan	"Ai nói? Đây là ý kiến hay quy định?"	"Trưởng phòng kinh doanh muốn chức năng X."
Giả định dự án	"Chúng ta cho rằng điều này đúng, nhưng liệu có bằng chứng không?"	"Hệ thống SMS hiện có xử lý được 10.000 tin/giờ."
Quyết định	"Ai đã phê duyệt? Có văn bản không?"	"Ban Giám đốc đã chọn phương án tích hợp ERP."
Tuyên bố cần xác minh	"Điều này có đúng không? Làm sao để kiểm tra?"	"SMS giảm 30% cuộc gọi hỗ trợ khách hàng."

3. Vị trí trong Lifecycle

Capstone Review and Evaluation (Đánh giá và Thẩm định Cuối giai đoạn) là quy trình kiểm tra tổng thể dự án, đảm bảo mọi thành phần phù hợp mục tiêu, chất lượng. Nó diễn ra xuyên suốt vòng đời phát triển phần mềm (Software Development Lifecycle - SDLC), không chỉ ở cuối. Mục đích: xác nhận sản phẩm đúng hướng, đạt yêu cầu ở từng giai đoạn.

Core

Capstone Review and Evaluation là điểm dừng chiến lược. Dự án phải đáp ứng tiêu chí cụ thể để tiến bước. BA dẫn dắt quy trình này, đảm bảo liên kết yêu cầu và giải pháp. BA thu thập bằng chứng, tổ chức phiên đánh giá, tổng hợp phản hồi từ bên liên quan.

Giai đoạn SDLC	Cổng vào (Entry Gate) Capstone Review & Evaluation	Trọng tâm đánh giá	Cổng ra (Exit Gate) Capstone Review & Evaluation
Discovery	Khái niệm dự án hình thành. Mục tiêu sơ bộ.	Xác nhận vấn đề nghiệp vụ Nova Foods rõ ràng. Phạm vi sơ bộ khả thi. Xác định lợi ích kinh doanh (Business Value).	Business Case (Dự thảo Đề xuất Nghiệp vụ) được chấp thuận sơ bộ.
Analysis	Yêu cầu nghiệp vụ (Business Requirements) thu thập.	Đánh giá tính đầy đủ, rõ ràng, nhất quán, khả thi của yêu cầu. Đảm bảo traceability (khả năng truy vết) đến mục tiêu.	Yêu cầu nghiệp vụ và Acceptance Criteria (Tiêu chí Chấp nhận) được baseline (chuẩn hóa).
Delivery	Thiết kế giải pháp (Solution Design) hoàn tất.	Xác minh thiết kế đáp ứng yêu cầu. Kiểm tra sự phù hợp với kiến trúc tổng thể Nova Foods ERP.	Thiết kế kỹ thuật được phê duyệt.
Testing	Test cases (Kịch bản kiểm thử) chuẩn bị. Môi trường kiểm thử sẵn sàng.	Đánh giá kết quả kiểm thử. Xác nhận lỗi được khắc phục. Đảm bảo chất lượng giải pháp đáp ứng Acceptance Criteria.	User Acceptance Test (UAT - Kiểm thử Chấp nhận Người dùng) thành công, được phê duyệt.
Release	Hướng dẫn triển khai. Kế hoạch đào tạo.	Xác nhận sẵn sàng triển khai. Kiểm tra kế hoạch truyền thông, đào tạo. Đảm bảo tác động kinh doanh được quản lý.	Quyết định Go/No-Go (Triển khai/Không triển khai) được thông qua.
Operations	Hệ thống đã đi vào hoạt động.	Đánh giá hiệu suất hệ thống. Xác minh lợi ích kinh doanh đã đạt. Thu thập bài học kinh nghiệm.	Báo cáo đánh giá sau triển khai hoàn tất. Kế hoạch cải tiến (nếu có).

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

graph TB
    BA["BA chủ trì<br/>Thu thập bằng chứng<br/>Tổ chức đánh giá<br/>Tổng hợp phản hồi"]

    A["Discovery - Khám phá"]
    B{"Vấn đề rõ ràng?<br/>Phạm vi khả thi?<br/>Lợi ích kinh doanh xác định?"}
    B1["Bổ sung Business Case<br/>và bằng chứng"]

    C["Analysis - Phân tích"]
    D{"Yêu cầu đầy đủ, rõ ràng,<br/>nhất quán và khả thi?<br/>Truy vết đến mục tiêu?"}
    D1["Làm rõ yêu cầu<br/>và bổ sung truy vết"]

    E["Delivery - Phát triển/Bàn giao giải pháp"]
    F{"Thiết kế đáp ứng yêu cầu?<br/>Phù hợp kiến trúc<br/>Nova Foods ERP?"}
    F1["Điều chỉnh thiết kế<br/>và bổ sung bằng chứng"]

    G["Testing - Kiểm thử"]
    H{"Kết quả kiểm thử đạt?<br/>Lỗi đã khắc phục?<br/>Đạt Acceptance Criteria?"}
    H1["Khắc phục lỗi<br/>và kiểm thử lại"]

    I["Release - Phát hành"]
    J{"Sẵn sàng triển khai?<br/>Truyền thông, đào tạo<br/>và tác động được quản lý?"}
    J1["Hoàn thiện kế hoạch<br/>và xử lý điểm chưa sẵn sàng"]

    K["Operations - Vận hành"]
    L{"Lợi ích kinh doanh đạt?<br/>Hiệu suất đáp ứng?<br/>Bài học kinh nghiệm đầy đủ?"}
    P["Lập kế hoạch cải tiến"]
    R["Báo cáo đánh giá<br/>sau triển khai hoàn tất"]

    A -->|"Cổng vào: Khái niệm dự án,<br/>mục tiêu sơ bộ"| B
    B -->|"Đạt: Business Case<br/>chấp thuận sơ bộ"| C
    B -->|"Chưa đạt"| B1
    B1 --> A

    C -->|"Cổng vào: Yêu cầu<br/>nghiệp vụ đã thu thập"| D
    D -->|"Đạt: Yêu cầu và<br/>Acceptance Criteria baseline"| E
    D -->|"Chưa đạt"| D1
    D1 --> C

    E -->|"Cổng vào: Thiết kế<br/>giải pháp hoàn tất"| F
    F -->|"Đạt: Thiết kế kỹ thuật<br/>được phê duyệt"| G
    F -->|"Chưa đạt"| F1
    F1 --> E

    G -->|"Cổng vào: Test cases và<br/>môi trường sẵn sàng"| H
    H -->|"Đạt: UAT được phê duyệt"| I
    H -->|"Chưa đạt"| H1
    H1 --> G

    I -->|"Cổng vào: Hướng dẫn triển khai<br/>và kế hoạch đào tạo"| J
    J -->|"Go"| K
    J -->|"No-Go"| J1
    J1 --> I

    K -->|"Cổng vào: Hệ thống<br/>đã hoạt động"| L
    L -->|"Không cần cải tiến"| R
    L -->|"Cần cải tiến"| P
    P --> R

    BA -.->|"Điều phối đánh giá"| B
    BA -.->|"Điều phối đánh giá"| D
    BA -.->|"Điều phối đánh giá"| F
    BA -.->|"Điều phối đánh giá"| H
    BA -.->|"Điều phối đánh giá"| J
    BA -.->|"Điều phối đánh giá"| L

Applied

Nova Foods (mô phỏng) xây dựng module Quản lý tồn kho mới trong ERP.

• Facts: Nova Foods cần module quản lý tồn kho để tối ưu hóa chuỗi cung ứng. Hệ thống ERP hiện có (kế thừa) thiếu chức năng theo dõi batch (lô sản xuất) và FIFO (nhập trước xuất trước).
• Current Behavior: Quy trình tồn kho hiện tại thủ công, dùng bảng tính Excel. Dữ liệu không nhất quán. Khó truy vết lô sản xuất.
• Underlying Need: Tự động hóa quản lý tồn kho. Đảm bảo tuân thủ quy định truy xuất nguồn gốc (Luật An toàn thực phẩm 55/2010/QH12). Giảm thất thoát, tăng hiệu quả vận hành.
• Options:
  1. Duy trì quy trình thủ công.
  2. Nâng cấp ERP hiện có bằng cách tùy chỉnh.
  3. Mua module tồn kho từ bên thứ ba tích hợp.
• Decision Criteria: Chi phí, thời gian triển khai, khả năng tích hợp với ERP hiện có, rủi ro, tuân thủ pháp lý.
• Decision: Nâng cấp ERP hiện có bằng cách tùy chỉnh. Lý do: chi phí thấp hơn mua mới, tích hợp dễ hơn, tuân thủ pháp lý theo yêu cầu Nova Foods.
• Authority: Ban Giám đốc Dự án Nova Foods ERP (mô phỏng).
• Artifact: Biên bản cuộc họp Capstone Review giai đoạn Analysis (NovaFoods-ERP-Inv-CR-Analysis-v1.0.docx), Yêu cầu module tồn kho được baseline (NovaFoods-ERP-Inv-REQ-v1.0.xlsx - cập nhật từ TRACEABILITY_ID_REGISTRY).
• Consequence if Wrong: (Nếu quyết định sai hoặc Capstone Review bỏ qua rủi ro) Dữ liệu tồn kho không chính xác. Không thể truy vết lô hàng. Vi phạm quy định an toàn thực phẩm. Dẫn đến thiệt hại tài chính, mất uy tín.

Senior Lens

Capstone Review không phải là sự kiện đơn lẻ, mà là tư duy liên tục xác nhận giá trị. BA cấp cao phải "đọc" được giữa các dòng báo cáo, tìm "điểm mù" (blind spots) của đội dự án. Đừng chỉ tập trung vào "đã làm gì", mà hãy hỏi "đã làm đúng việc chưa" và "việc này có còn giá trị không". CR&E là cơ hội cuối để điều chỉnh trước khi chi phí thay đổi quá lớn. BA sử dụng CANONICAL_BUSINESS_RULES.md và CANONICAL_DATA_DICTIONARY.md để đảm bảo sự nhất quán trong mọi đánh giá.

Quick Reference

Giai đoạn SDLC	Capstone Review Entry Gate	Capstone Review Exit Gate	Vai trò chính BA
Discovery	Khái niệm dự án	Business Case sơ bộ	Dẫn dắt xác định vấn đề, giá trị
Analysis	Yêu cầu thu thập	Yêu cầu & AC baseline	Đảm bảo đầy đủ, rõ ràng, nhất quán yêu cầu
Delivery	Thiết kế giải pháp	Thiết kế kỹ thuật phê duyệt	Xác minh thiết kế đáp ứng yêu cầu
Testing	Test cases & môi trường	UAT Sign-off	Đánh giá chất lượng, khắc phục lỗi
Release	Hướng dẫn triển khai, kế hoạch đào tạo	Go/No-Go	Xác nhận sẵn sàng, quản lý tác động
Operations	Hệ thống vận hành	Báo cáo đánh giá sau triển khai	Đánh giá lợi ích, bài học kinh nghiệm

Chủ sở hữu, Bàn giao, Giới hạn Quyền hạn và Điểm Leo thang trong Đánh giá Capstone

Core

Đánh giá Capstone (Capstone Review) kiểm tra tổng thể. Nhiều bên liên quan tham gia. Bàn giao rõ ràng, giới hạn thẩm quyền, điểm leo thang quan trọng. Tránh tắc nghẽn, đảm bảo đúng người quyết định.

Vai trò	Chủ sở hữu (Upstream/Downstream)	Bàn giao (Handoff)	Giới hạn thẩm quyền	Điểm leo thang (Escalation Point)
Business Owner (BO)	Downstream: Business Ops	Yêu cầu nghiệp vụ, chấp thuận mục tiêu, rủi ro chấp nhận.	Chấp thuận yêu cầu, quyết định nghiệp vụ, rủi ro. Không kỹ thuật, không pháp lý.	Project Sponsor, C-suite (Nova Foods CEO/CFO mô phỏng)
Product Owner (PO)	Upstream: BO. Downstream: Dev Team	Ưu tiên tính năng, chấp thuận User Story, Backlog.	Định nghĩa "Done", ưu tiên Roadmap. Không thiết kế kỹ thuật.	Business Owner, Project Lead
IT Business Analyst (IT BA)	Upstream: PO. Downstream: QA/Dev	Tài liệu yêu cầu (FSD, User Story), Acceptance Criteria, Traceability.	Giải thích yêu cầu, tạo tài liệu. Không quyết định nghiệp vụ, không thiết kế kỹ thuật, không phê duyệt bản phát hành.	Product Owner, Technical Lead
Technical Lead (TL) / Architect	Upstream: IT BA. Downstream: Dev Team	Thiết kế giải pháp, đánh giá khả năng thực thi.	Quyết định kỹ thuật, kiến trúc. Không quyết định nghiệp vụ, không phê duyệt phát hành.	Head of IT, Project Sponsor
QA Lead	Upstream: IT BA/Dev. Downstream: Release Manager	Kế hoạch kiểm thử, Báo cáo lỗi, Chấp thuận chất lượng.	Xác nhận chất lượng, xác nhận đáp ứng Acceptance Criteria. Không quyết định nghiệp vụ, không phê duyệt phát hành.	Project Lead, Head of IT
Security Officer	Upstream: TL/Architect. Downstream: Security Ops	Đánh giá rủi ro bảo mật, yêu cầu tuân thủ (ví dụ: OWASP ASVS).	Chấp thuận yêu cầu bảo mật, đánh giá lỗ hổng. Không nghiệp vụ.	CISO (Nova Foods CISO mô phỏng)
Compliance Officer (Legal/Accounting)	Upstream: BO/PO/IT BA. Downstream: Audit	Xác nhận tuân thủ quy định (ví dụ: Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, Nghị định 123/2020/NĐ-CP).	Chấp thuận tuân thủ pháp lý/kế toán. Không kỹ thuật, không nghiệp vụ.	Legal Counsel, CFO (Nova Foods mô phỏng)

Applied

Facts: Nova Foods phát triển tính năng quản lý đơn hàng. "User Story: Tạo đơn hàng với nhiều kho xuất" cần đánh giá Capstone.

Current Behavior: BA hoàn thành User Story, gửi email cho PO/Dev Lead. Đánh giá không cấu trúc.

Underlying Need: Đảm bảo User Story rõ ràng, khả thi, tuân thủ trước khi Dev bắt đầu. Tránh hiểu nhầm giữa team Dev và Business.

Options: 1. BA tự kiểm tra. 2. BA gửi PO review nhanh. 3. Tổ chức buổi Capstone Review chính thức với nhiều bên.

Decision Criteria: Phức tạp nghiệp vụ (nhiều kho), rủi ro cao (ảnh hưởng tồn kho), tuân thủ (hóa đơn, chứng từ).

Decision: Option 3. Capstone Review chính thức.

Authority: Product Owner và Technical Lead cùng phê duyệt chất lượng User Story, đánh dấu sẵn sàng Dev. Compliance Officer xác nhận không vi phạm quy định Nova Foods mô phỏng.

Artifact: BA tạo /24-capstone-review-report-NF-001.md. Báo cáo ghi nhận phê duyệt, điểm chưa rõ, điểm leo thang.

Consequence if Wrong: Dev sai tính năng, tồn kho ảo, sai báo cáo tài chính Nova Foods, phải làm lại nhiều, tốn kém.

Senior Lens

Handoff, thẩm quyền: rõ ràng. Nhập nhằng dễ làm chậm dự án, tăng chi phí. BA không tự quyết thay Business Owner, Legal, hay Architect. Role của BA: tạo thông tin, điều phối, không phải người phê duyệt cuối. Escalation: dùng sớm. Vấn đề phát hiện sớm, chi phí fix thấp. Một nguồn chân lý (Single Source of Truth) cho yêu cầu, thiết kế. Kiểm soát phiên bản (Version Control) cho mọi artifact. Không có giấy tờ thì không có bằng chứng bàn giao.

Quick Reference

Vai trò	Trách nhiệm Capstone Review (Chính)	Kênh Leo thang Thường gặp
Business Owner	Chấp thuận cuối nghiệp vụ	Project Sponsor
Product Owner	Duyệt yêu cầu, ưu tiên	Business Owner
IT Business Analyst	Trình bày, ghi nhận kết quả	Product Owner / Technical Lead
Technical Lead	Xác nhận khả thi kỹ thuật	Head of IT
QA Lead	Xác nhận kiểm thử được	Project Lead
Compliance Officer	Xác nhận tuân thủ quy định	Legal Counsel / CFO

Vị Trí Của Đánh Giá Tổng Kết Dự Án Trong Vòng Đời Triển Khai ERP Nova Foods

Core

Sơ đồ mô tả vị trí Đánh giá Tổng kết Dự án (Capstone Review & Evaluation) trong vòng đời triển khai một phân hệ ERP mô phỏng của Nova Foods. Đánh giá này hoạt động như một cổng kiểm soát chất lượng chiến lược (strategic quality gate), diễn ra sau khi hoàn tất giai đoạn kiểm thử và trước khi phát hành chính thức. Mục đích cốt lõi là đảm bảo giải pháp đã phát triển đáp ứng toàn bộ yêu cầu nghiệp vụ, kỹ thuật, an toàn và tuân thủ các quy định hiện hành trước khi đưa vào môi trường vận hành thực tế.

Applied

• Facts (Dữ kiện): Nova Foods triển khai phân hệ Kế toán Công nợ (Accounts Payable – AP) mới thuộc hệ thống ERP nội bộ, phiên bản v0.9.0. Phân hệ này xử lý các giao dịch tài chính quan trọng, ảnh hưởng trực tiếp đến báo cáo tài chính và dòng tiền doanh nghiệp.
• Current Behavior (Hành vi hiện tại): Theo quy trình cũ, sau khi Kiểm thử chấp nhận người dùng (User Acceptance Testing – UAT) hoàn tất và các lỗi P1, P2 được khắc phục, hệ thống thường được phát hành trực tiếp mà không qua một đánh giá tổng thể và có thẩm quyền cao.
• Underlying Need (Nhu cầu cốt lõi): Giảm thiểu rủi ro phát sinh các lỗi nghiệp vụ hoặc kỹ thuật nghiêm trọng trong môi trường sản xuất, đặc biệt là các lỗi ảnh hưởng đến dữ liệu tài chính, tuân thủ Luật Kế toán (Luật 88/2015/QH13) và Nghị định Hóa đơn (Nghị định 123/2020/NĐ-CP) của Việt Nam. Cần một điểm dừng để các bên liên quan cấp cao xác nhận sự sẵn sàng tổng thể.
• Options (Các lựa chọn):
  1. Duy trì quy trình hiện tại: phát hành ngay sau khi UAT được thông qua bởi nhóm nghiệp vụ.
  2. Thêm một Đánh giá Tổng kết Dự án nội bộ (Internal Capstone Review) với sự tham gia của đại diện nghiệp vụ, kỹ thuật, QA và quản lý dự án cấp cao trước khi phát hành.
  3. Thêm Đánh giá Tổng kết Dự án nội bộ và yêu cầu kiểm toán độc lập (External Audit) về tính tuân thủ tài chính trước phát hành.
• Decision Criteria (Tiêu chí ra quyết định): Mức độ rủi ro chấp nhận được về tài chính, rủi ro pháp lý, ngân sách và thời gian triển khai dự kiến của Nova Foods.
• Decision (Quyết định): Chọn Lựa chọn 2. Thêm Đánh giá Tổng kết Dự án nội bộ. Quyết định này giúp cân bằng giữa việc giảm thiểu rủi ro và tối ưu hóa chi phí/thời gian, đồng thời củng cố niềm tin về khả năng tuân thủ các quy định nội bộ và pháp luật Việt Nam.
• Authority (Thẩm quyền): Ban Chỉ đạo Dự án (Project Steering Committee) của Nova Foods là cấp ra quyết định cuối cùng về GO/NO-GO.
• Artifact (Sản phẩm tạo ra): Biên bản họp Đánh giá Tổng kết Dự án (NF-CR-MIN-20260807-AP), Danh sách kiểm tra GO/NO-GO (NF-CR-CHK-001) và kế hoạch khắc phục các điểm không chấp nhận (NO-GO) nếu có.
• Consequence if Wrong (Hậu quả nếu sai): Nếu quyết định sai (phát hành hệ thống chưa sẵn sàng), có thể dẫn đến các lỗi tính toán công nợ kéo dài, gây sai lệch báo cáo tài chính, phát sinh phạt hành chính do không tuân thủ quy định về kế toán và hóa đơn, ảnh hưởng nghiêm trọng đến uy tín và hoạt động kinh doanh của Nova Foods.

Senior Lens

Đánh giá Tổng kết Dự án là một bước chuyển đổi từ "sản phẩm đã chạy" sang "sản phẩm đã sẵn sàng vận hành". Đây không phải là một bước kiểm tra thông thường mà là một cổng chất lượng tổng hợp (holistic quality gate). Nó đòi hỏi sự tổng hòa các góc nhìn từ chủ sở hữu nghiệp vụ (Business Owner), đội ngũ phát triển (Development Team), kiểm thử viên (QA Team), và đội ngũ vận hành (Operations Team). Quyết định GO/NO-GO tại đây yêu cầu thẩm quyền cao nhất, thường là từ Ban Chỉ đạo Dự án hoặc các cổ đông cấp cao. Quyết định này không chỉ dựa trên kết quả kiểm thử đơn thuần, mà còn dựa trên sự sẵn sàng của các quy trình nghiệp vụ, tài liệu hướng dẫn, năng lực của người dùng cuối, sự chuẩn bị của hạ tầng kỹ thuật, và mức độ chấp nhận rủi ro tổng thể của tổ chức. Bỏ qua hoặc thực hiện hời hợt bước này sẽ chuyển các rủi ro chưa được xử lý sang môi trường sản xuất, có thể gây ra những hậu quả về tài chính, pháp lý và uy tín lớn hơn nhiều lần so với chi phí đầu tư cho một đánh giá nghiêm túc.

Quick Reference

graph TD
    subgraph Vòng đời Triển khai ERP Nova Foods (Mô phỏng)
        A[Discovery - Khám phá] --> B[Analysis - Phân tích]
        B --> C[Delivery - Phát triển]
        C --> D[Testing - Kiểm thử]
        D -- "UAT Hoàn thành (Dữ liệu tổng hợp Nova Foods)" --> E{Capstone Review & Evaluation}
        E -- "GO (Chấp nhận phát hành)" --> F[Release - Phát hành]
        E -- "NO-GO (Cần sửa đổi/Tái kiểm thử)" --> C
        F --> G[Operations - Vận hành]
    end

4. Input cần thiết

Core

Đánh giá tổng kết dự án (Capstone Review & Evaluation) cần đầu vào có kiểm soát. BA dùng đầu vào để xác định hệ thống ERP Nova Foods (mô phỏng) đã đáp ứng yêu cầu, sẵn sàng vận hành và có bằng chứng tuân thủ hay chưa.

Đầu vào phải đủ, chính xác, còn hiệu lực, có nguồn rõ ràng và truy vết được. Thiếu đầu vào, dùng phiên bản cũ, hoặc dùng nguồn không có thẩm quyền làm sai quyết định GO/NO-GO, tăng rủi ro vận hành, pháp lý, tài chính và uy tín.

Applied

Nova Foods (công ty mô phỏng) sắp hoàn tất dự án ERP.

• Facts: Có nhiều tài liệu dự án từ nghiệp vụ, QA, kỹ thuật, vận hành, pháp chế và quản lý dự án.
• Current Behavior: Tài liệu rải rác; một số artifact chưa xác minh đầy đủ hoặc đang IN_REVIEW.
• Underlying Need: BA phải gom đầu vào gốc, kiểm tra trạng thái, phiên bản, chủ sở hữu, tính truy vết và các điểm chưa xác minh trước quyết định GO/NO-GO.
• Options:
• Chọn vài tài liệu được xem là quan trọng theo nhận định cá nhân. Hậu quả: thiếu bằng chứng, bỏ sót rủi ro, quyết định sai.
• Thu thập mọi đầu vào cần thiết theo danh mục có kiểm soát; kiểm tra chéo nguồn, trạng thái, độ tươi mới và thẩm quyền. Kết quả: đủ bằng chứng để đánh giá.
• Decision Criteria: Đầy đủ, chính xác, mới nhất, nguồn rõ ràng, có chủ sở hữu, có thể truy vết, không có điều kiện dừng chưa xử lý.
• Decision: Chọn phương án 2. BA lập bảng tổng hợp đầu vào, ghi nhận trạng thái xác minh và leo thang các điểm chưa đủ bằng chứng.
• Authority: BA thu thập, phân loại và kiểm tra. Trưởng dự án, Business Owner, Legal Owner, Accounting Owner, Security Lead và các chủ sở hữu artifact xác nhận phần thuộc thẩm quyền.
• Artifact: Bảng tổng hợp đầu vào Capstone Review, bao gồm ID, nguồn, phiên bản, trạng thái, chủ sở hữu, điều kiện dừng và trạng thái xác minh.
• Consequence if Wrong: ERP Nova Foods có thể triển khai khi yêu cầu, kiểm thử, tuân thủ, dữ liệu hoặc vận hành chưa đủ bằng chứng. Hậu quả gồm lỗi vận hành, làm lại tốn kém, mất uy tín và rủi ro liên quan Luật An toàn thực phẩm, Luật Kế toán hoặc quy định hóa đơn.

Senior Lens

Senior BA xem đầu vào không chỉ là giấy tờ. Đầu vào gồm cam kết, quyết định, bằng chứng tuân thủ, kết quả kiểm thử, dữ liệu vận hành và xác nhận của chủ sở hữu.

Senior BA kiểm tra “dòng chảy chân lý” từ yêu cầu nghiệp vụ đến thiết kế, phát triển, kiểm thử, vận hành và báo cáo tuân thủ. Chuỗi truy vết phải cho thấy yêu cầu nào được thiết kế, kiểm thử, chấp nhận hoặc còn rủi ro.

Artifact có trạng thái IN_REVIEW, PENDING, UNVERIFIED, hoặc “chưa xác minh đầy đủ” không phải bằng chứng hoàn tất. BA phải ghi rõ khoảng trống, chủ sở hữu, hành động xử lý, quyết định bị ảnh hưởng và điểm leo thang. Tài liệu pháp lý, kế toán và bảo mật cần chuyên gia có thẩm quyền xem xét trước GO/NO-GO.

Quick Reference

Bảng này liệt kê đầu vào cho “Capstone Review & Evaluation” của Nova Foods ERP mô phỏng. Dùng ID gốc (Canonical ID) để truy vết.

ID Gốc (Canonical ID)	Tên Tài liệu/Phạm vi (Artifact Name/Scope)	Mô tả ngắn gọn (Brief Description)	Nguồn/Người tạo (Source/Creator)	Phiên bản (Version)	Trạng thái (Status)	Trạng thái xác minh (Verification Status)	Lý do cần cho Đánh giá tổng kết (Why needed for Capstone Review)
BRD-NF-V1.0	Yêu cầu Nghiệp vụ (Business Requirement Document)	Ghi chi tiết nhu cầu nghiệp vụ, mục tiêu cho hệ thống ERP Nova Foods.	Business Owners, BA Team	V1.0 (Đã phê duyệt)	APPROVED	Đã xác minh	Đối chiếu hệ thống với yêu cầu gốc, đảm bảo tính năng cốt lõi.
FSD-NF-V1.0	Đặc tả Chức năng (Functional Specification Document)	Mô tả chi tiết cách hệ thống hoạt động để đáp ứng yêu cầu.	BA Team, Solution Architect	V1.0	FINAL	Đã xác minh	Xác nhận thiết kế chức năng đã được phát triển đúng.
UAT-REPORT-NF-V1.0	Báo cáo Kiểm thử Chấp nhận Người dùng (User Acceptance Test Report)	Kết quả kiểm thử UAT bởi người dùng nghiệp vụ Nova Foods. Người dùng đã chấp nhận hệ thống.	QA Team, Business Users	V1.0	PASSED	Đã xác minh	Chứng minh hệ thống đáp ứng mong đợi người dùng cuối.
TEST-PLAN-NF-V1.0	Kế hoạch Kiểm thử (Test Plan)	Chiến lược, phạm vi, các trường hợp kiểm thử (Test Cases), tiêu chí chấp nhận (Acceptance Criteria) cho ERP.	QA Team	V1.0	FINAL	Đã xác minh	Xác nhận mọi mặt đã được kiểm thử theo kế hoạch.
DEPLOY-PLAN-NF-V1.0	Kế hoạch Triển khai (Deployment Plan)	Các bước, tài nguyên, lịch trình để đưa ERP lên môi trường sản xuất.	DevOps Team, Project Manager	V1.0	FINAL	Đã xác minh	Đánh giá khả năng chuyển đổi hệ thống an toàn.
OP-READINESS-NF-V1.0	Danh mục Sẵn sàng Vận hành (Operational Readiness Checklist)	Kiểm tra hạ tầng, hỗ trợ, giám sát cần thiết cho vận hành ERP.	Operations Team	V1.0	COMPLETED	Đã xác minh	Đảm bảo Nova Foods vận hành ổn định sau triển khai.
REG-COMP-REPORT-NF-V1.0	Báo cáo Tuân thủ Quy định (Regulatory Compliance Report)	Xác nhận ERP Nova Foods tuân thủ luật (ví dụ: Luật An toàn thực phẩm 55/2010/QH12, Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP hóa đơn).	Legal & Compliance Team	V1.0	APPROVED	Xác minh pháp lý cần	Đảm bảo hệ thống không vi phạm luật quan trọng.
PRIVACY-IMPACT-NF-V1.0	Đánh giá Tác động Quyền riêng tư (Privacy Impact Assessment Report)	Phân tích hệ thống xử lý dữ liệu cá nhân, tuân thủ Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP.	Data Protection Officer, Legal Team	V1.0	APPROVED	Xác minh pháp lý cần	Bảo vệ dữ liệu cá nhân khách hàng, nhân viên Nova Foods.
00_SOURCE_MAP	Sơ đồ Nguồn (Source Map)	Liệt kê các nguồn chính thức (luật, tiêu chuẩn) dùng trong tài liệu.	Curriculum Author	v0.9.0	IN_REVIEW	Đã xác minh	Cung cấp nguồn gốc cho mọi yêu cầu, quyết định.
CANONICAL_BUSINESS_RULES	Danh mục Quy tắc Nghiệp vụ (Canonical Business Rules Catalog)	Quy tắc nghiệp vụ cốt lõi, không đổi của Nova Foods, ERP phải theo.	Business Owners, BA Team	v0.9.0	IN_REVIEW	Đã xác minh	Xác nhận hệ thống thực thi đúng quy tắc nghiệp vụ.
CANONICAL_DATA_DICTIONARY	Từ điển Dữ liệu Logic (Canonical Logical Data Dictionary)	Định nghĩa các thực thể, thuộc tính dữ liệu và mối quan hệ trong ERP Nova Foods.	BA Team, Data Architect	v0.9.0	IN_REVIEW	Đã xác minh	Đảm bảo cấu trúc, định nghĩa dữ liệu hệ thống nhất quán.
TRACEABILITY_ID_REGISTRY	Registry Định danh Truy vết (Traceability ID Registry)	Danh sách ID duy nhất để truy vết yêu cầu, tính năng, kiểm thử, tài liệu dự án.	BA Team, Project Manager	v0.9.0	IN_REVIEW	Đã xác minh	Đảm bảo khả năng truy vết đầy đủ.
RISK-REGISTER-NF-V1.0	Nhật ký Rủi ro (Risk Register)	Liệt kê rủi ro, ưu tiên, kế hoạch giảm thiểu, trạng thái.	Project Manager, Risk Owner	V1.0	FINAL	Chưa xác minh đầy đủ	Đánh giá rủi ro còn lại, tác động trước khi triển khai.
STAKEHOLDER-REGISTER-NF-V1.0	Danh bạ Các bên liên quan (Stakeholder Register)	Danh sách các bên liên quan, vai trò, quyền hạn.	Project Manager, BA Team	V1.0	FINAL	Đã xác minh	Xác định người cần tham vấn/phê duyệt cuối cùng.

Kiểm soát chất lượng, phân loại, độ tươi mới và quyền sở hữu đầu vào

Core

Trong công việc của Business Analyst (BA), đầu vào (input) là thông tin, dữ liệu, tài liệu hoặc yêu cầu BA thu thập để phân tích, đánh giá và thiết kế giải pháp. Chất lượng đầu vào quyết định chất lượng đầu ra.

1. Kiểm tra chất lượng đầu vào (Input Quality Checks)

Mọi đầu vào phải được kiểm tra trước khi dùng làm bằng chứng hoặc cơ sở quyết định.

Tiêu chí	Giải thích (Tiếng Việt)	Giải thích (Tiếng Anh)	Lý do quan trọng
Tính hợp lệ	Dữ liệu, thông tin có tuân thủ định dạng, quy tắc đã định không?	Validity	Dữ liệu không hợp lệ làm sai lệch kết quả phân tích.
Tính đầy đủ	Có đủ thông tin cần thiết để tiếp tục công việc không?	Completeness	Thiếu thông tin dẫn đến thiếu sót trong yêu cầu, thiết kế.
Tính nhất quán	Thông tin có mâu thuẫn với các nguồn hoặc thông tin đã biết khác không?	Consistency	Mâu thuẫn thông tin gây xung đột yêu cầu, khó khăn trong phát triển.
Tính chính xác	Dữ liệu, thông tin có đúng với thực tế không?	Accuracy	Thông tin sai lệch dẫn đến giải pháp sai.
Tính kịp thời	Thông tin có còn phù hợp với thời điểm hiện tại không?	Timeliness/Freshness	Thông tin cũ có thể không còn giá trị, dẫn đến lãng phí công sức.
Tính khả truy vết	Có thể xác định nguồn gốc, phiên bản và chủ sở hữu thông tin không?	Traceability	Giúp xác minh, giải quyết mâu thuẫn, kiểm toán.

2. Phân loại nguồn (Source Classifications)

Phân loại giúp BA xác định độ tin cậy, phạm vi sử dụng và thẩm quyền của đầu vào.

Phân loại	Mô tả	Ví dụ tại Nova Foods (mô phỏng)	Thẩm quyền
Pháp lý	Văn bản pháp luật, quy định, nghị định, thông tư. Có tính ràng buộc bắt buộc.	Luật An toàn thực phẩm (Luật 55/2010/QH12), Nghị định 123/2020/NĐ-CP về hóa đơn.	Quốc hội, Chính phủ.
Nghiệp vụ	Quy trình kinh doanh, yêu cầu từ người dùng, chính sách công ty.	Yêu cầu quản lý tồn kho từ Phòng Sản xuất, quy trình bán hàng của Phòng Kinh doanh.	Business Owner, Phòng ban nghiệp vụ.
Tiêu chuẩn	Tiêu chuẩn kỹ thuật, ngành nghề, bảo mật (vd: ISO, OWASP, BPMN).	OWASP ASVS 5.0.0 cho bảo mật ứng dụng, BPMN 2.0.2 cho mô hình quy trình.	Tổ chức tiêu chuẩn quốc tế/ngành.
Hệ thống	Dữ liệu từ hệ thống hiện có, tài liệu kiến trúc kỹ thuật.	Dữ liệu khách hàng từ hệ thống CRM cũ, đặc tả API của hệ thống thanh toán.	Kiến trúc sư hệ thống, đội kỹ thuật.
Bên ngoài	Nghiên cứu thị trường, báo cáo ngành, phản hồi khách hàng bên ngoài.	Báo cáo xu hướng tiêu dùng sản phẩm đông lạnh, khảo sát hài lòng khách hàng.	Đơn vị nghiên cứu thị trường, khách hàng.

3. Độ tươi mới (Freshness)

Độ tươi mới là thời gian tối đa thông tin còn đủ giá trị để dùng cho quyết định. Đối với Nova Foods (mô phỏng), văn bản pháp lý phải là bản mới nhất có hiệu lực; thông tin thị trường có thể chấp nhận trong 6-12 tháng; dữ liệu nghiệp vụ phải phản ánh trạng thái hiện hành.

BA phải ghi ngày thu thập, ngày hiệu lực, phiên bản và nguồn. Nếu không xác định được các thông tin này, BA không dùng đầu vào làm bằng chứng cuối cùng.

4. Chủ sở hữu (Ownership)

Chủ sở hữu là cá nhân hoặc phòng ban chịu trách nhiệm cuối cùng về tính chính xác, đầy đủ và hợp lệ của đầu vào. Owner có quyền xác nhận, phê duyệt hoặc yêu cầu thay đổi đầu vào thuộc phạm vi của mình.

Loại Đầu vào	Chủ sở hữu (Nova Foods mô phỏng)
Yêu cầu nghiệp vụ	Business Owner/Product Owner
Quy định pháp luật	Phòng Pháp chế (Legal Department)
Tiêu chuẩn kỹ thuật	Kiến trúc sư hệ thống (System Architect) hoặc Trưởng phòng IT
Dữ liệu hệ thống	Quản trị dữ liệu (Data Administrator)

5. Điều kiện dừng (Stop Conditions)

Khi điều kiện dừng xảy ra, BA không được tiếp tục dùng đầu vào đó làm căn cứ đánh giá cho đến khi chủ sở hữu hoặc bên có thẩm quyền xử lý vấn đề.

Điều kiện dừng	Hậu quả	Hành động BA
Đầu vào mâu thuẫn	Hai nguồn tin cậy đưa ra thông tin đối lập không thể hòa giải.	Dừng sử dụng đầu vào; xác định nguồn gốc, phiên bản, thẩm quyền; leo thang đến chủ sở hữu để quyết định.
Thiếu thẩm quyền	Nguồn cung cấp đầu vào không có quyền quyết định hoặc xác nhận.	Dừng; yêu cầu xác định chủ sở hữu chính thức và lấy xác nhận từ đúng thẩm quyền.
Dữ liệu không hợp lệ	Thông tin sai định dạng nghiêm trọng, không thể phân tích.	Dừng; yêu cầu chỉnh sửa hoặc cung cấp lại từ nguồn chịu trách nhiệm.
Vấn đề bảo mật	Đầu vào chứa thông tin nhạy cảm không được phép xử lý.	Dừng; báo cáo ngay cho Cán bộ Bảo mật Thông tin (CISO); chỉ tiếp tục theo hướng dẫn kiểm soát truy cập được phê duyệt.
Phiên bản cũ	Dùng phiên bản luật, quy trình hoặc đặc tả lỗi thời.	Dừng; yêu cầu phiên bản mới nhất từ nguồn chính thức hoặc chủ sở hữu.

Applied

Tình huống: Nova Foods (mô phỏng) nâng cấp ERP để quản lý đơn hàng. Yêu cầu: “Hệ thống phải tuân thủ việc xuất hóa đơn điện tử theo quy định mới nhất của Việt Nam.”

• Facts: Có yêu cầu về hóa đơn điện tử.
• Current Behavior: ERP cũ của Nova Foods dùng hóa đơn giấy; chức năng hóa đơn điện tử chưa được cập nhật theo quy định hiện hành.
• Underlying Need: Nova Foods cần tuân thủ pháp luật Việt Nam về hóa đơn điện tử, bảo đảm tính hợp pháp giao dịch và tự động hóa quy trình kế toán. Nhu cầu liên quan Luật Kế toán và Nghị định 123/2020/NĐ-CP.
• Options:
• Tham khảo Luật Kế toán trên website tin tức không chính thức và tự diễn giải.
• Dùng Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ từ trang Chính phủ (vanban.chinhphu.vn).
• Chờ Phòng Kế toán hoặc Phòng Pháp chế Nova Foods cung cấp bản tóm tắt hoặc diễn giải.
• Decision Criteria: Tính pháp lý, độ tin cậy nguồn, độ chính xác, khả năng cập nhật, xác nhận của chủ sở hữu pháp lý và kế toán.
• Decision: Dùng Option 2 làm nguồn văn bản gốc; yêu cầu Phòng Pháp chế và Phòng Kế toán xác nhận cách áp dụng cho ERP Nova Foods. Nguồn Chính phủ cung cấp văn bản gốc; Legal và Accounting Owner xác nhận diễn giải nghiệp vụ.
• Authority: Phòng Pháp chế và Phòng Kế toán Nova Foods (mô phỏng) cùng xác nhận đầu vào và cách áp dụng.
• Artifact: Nghị định 123/2020/NĐ-CP; effective 2022-07-01 (URL: https://vanban.chinhphu.vn/?docid=201365&pageid=27160).
• Consequence if Wrong: Nếu dùng nguồn không chính thức hoặc diễn giải sai, ERP có thể xuất hóa đơn không hợp lệ. Nova Foods có thể chịu xử lý từ cơ quan thuế, mất uy tín với đối tác và tốn chi phí sửa hệ thống sau triển khai.

Senior Lens

Kiểm soát đầu vào là quản lý rủi ro. Đầu vào mơ hồ, không đáng tin cậy, thiếu thẩm quyền hoặc lỗi thời dẫn đến phát triển sai yêu cầu, trì hoãn và tăng chi phí làm lại.

Senior BA phải:

• Giảm rủi ro pháp lý và nghiệp vụ bằng nguồn chính thức và xác nhận từ chủ sở hữu.
• Không coi trạng thái tài liệu là bằng chứng duy nhất; phải kiểm tra nội dung, phiên bản, phạm vi và liên kết truy vết.
• Ghi nhận rõ đầu vào chưa xác minh, tác động, người xử lý và điều kiện cần đáp ứng trước GO/NO-GO.
• Bảo đảm mỗi quyết định thiết kế hoặc chấp nhận có thể truy ngược về nguồn đáng tin cậy.
• Phân biệt nguồn văn bản gốc với diễn giải áp dụng. Văn bản gốc xác định nguồn; chủ sở hữu pháp lý, kế toán hoặc bảo mật xác nhận việc áp dụng.

Quick Reference

Khía cạnh	Câu hỏi nhanh	Quan trọng nhất (Nova Foods mô phỏng)
Chất lượng	Đầu vào có hợp lệ, đầy đủ, chính xác, nhất quán không?	Kiểm tra với Nghị định 123/2020/NĐ-CP
Phân loại	Nguồn gốc là gì: Pháp lý, Nghiệp vụ, Kỹ thuật?	Pháp lý (Ví dụ: Luật 55/2010/QH12) và Nghiệp vụ (Ví dụ: quy trình sản xuất Nova Foods).
Độ tươi mới	Thông tin này có còn cập nhật không?	Luật pháp và quy định phải là bản có hiệu lực mới nhất.
Chủ sở hữu	Ai chịu trách nhiệm chính về đầu vào này?	Phòng Pháp chế/Kế toán cho luật, Business Owner cho nghiệp vụ.
Dừng	Có điều kiện nào khiến tôi phải dừng sử dụng đầu vào này không?	Mâu thuẫn với nguồn chính thức, thiếu thẩm quyền xác nhận, hoặc có vấn đề bảo mật.

Bảng Đầu vào Tiêu chuẩn và Trạng thái Xác minh cho Đánh giá Capstone Nova Foods

Bảng dưới liệt kê đầu vào cần thiết cho hoạt động đánh giá tổng thể (capstone review and evaluation) của dự án ERP mô phỏng tại Nova Foods. Mỗi đầu vào gồm định danh chuẩn (canonical ID), mô tả, nguồn gốc, chủ sở hữu, giá trị mô phỏng, tiêu chí chất lượng, độ tươi mới, điều kiện dừng và trạng thái xác minh hiện tại. Dữ liệu là mô phỏng, không phản ánh hệ thống thực tế của Nova Foods.

Mã ID Canonical	Tên Đầu vào	Mục đích cho Capstone	Phân loại Nguồn	Nguồn Gốc/Đường dẫn	Chủ sở hữu	Giá trị Mô phỏng	Tiêu chí Chất lượng	Độ Tươi	Điều kiện Dừng	Trạng thái Xác minh
NF-BRD-ERP-001	Tài liệu Yêu cầu Nghiệp vụ (BRD)	Đánh giá phạm vi, mục tiêu dự án đã được định nghĩa và đồng ý.	Nghiệp vụ, Nội bộ	/03-templates/ERP-BRD-v1.0.md (phiên bản đã điền cho Module Kho)	Business Owner, BA	Yêu cầu NF-REQ-001: "Hệ thống quản lý kho Nova Foods phải tự động áp dụng phương pháp FIFO cho tất cả sản phẩm dễ hư hỏng."	Bao gồm tất cả yêu cầu, có chữ ký phê duyệt từ Business Owner. Mỗi yêu cầu phải có ID truy vết.	Phiên bản cuối cùng, không quá 3 tháng kể từ phê duyệt.	Thiếu chữ ký phê duyệt. Thay đổi yêu cầu cốt lõi không được ghi nhận sau baseline.	Cần xác minh phê duyệt cuối cùng từ Business Owner đối với yêu cầu NF-REQ-001 và các yêu cầu liên quan.
NF-FSD-ERP-001	Tài liệu Đặc tả Chức năng (FSD)	Xác định cách giải pháp kỹ thuật đáp ứng các yêu cầu nghiệp vụ.	Kỹ thuật, Nội bộ	/03-templates/ERP-FSD-v1.0.md (phiên bản đã điền cho Module Kho)	System Architect, BA	Mô tả chức năng module kho: "Hệ thống tự động ghi nhận nhập xuất lô hàng, tính toán giá trị tồn kho theo FIFO, tích hợp API với máy quét mã vạch Honeywell tại kho hàng Nova Foods."	Đặc tả rõ ràng, không mâu thuẫn với BRD. Mỗi chức năng phải có ID truy vết.	Phiên bản mới nhất, không quá 1 tháng kể từ phê duyệt thiết kế.	Mâu thuẫn với BRD. Thiếu đặc tả cho chức năng quan trọng đã nêu trong BRD.	Chưa xác minh đầy đủ về tích hợp API máy quét mã vạch Honeywell với phần cứng thực tế và luồng dữ liệu.
NF-TEST-PLAN-001	Kế hoạch Kiểm thử Tổng thể (Test Plan)	Đánh giá chiến lược và phạm vi kiểm thử để đảm bảo chất lượng hệ thống.	QA, Nội bộ	/03-templates/ERP-TestPlan-v1.0.md (kế hoạch kiểm thử cho Module Kho và Đơn hàng)	QA Lead	Kế hoạch kiểm thử: "Kiểm thử tích hợp (SIT) và Kiểm thử chấp nhận người dùng (UAT) cho Module Quản lý Kho và Đơn hàng, bao gồm 250 test case bao phủ 90% yêu cầu nghiệp vụ cốt lõi."	Bao phủ đầy đủ yêu cầu BRD. Định nghĩa rõ ràng loại kiểm thử (unit, SIT, UAT, performance).	Phiên bản mới nhất trước khi kiểm thử.	Thiếu chiến lược cho kiểm thử hiệu năng. Phạm vi kiểm thử không bao phủ yêu cầu cốt lõi.	Chưa xác minh phạm vi kiểm thử cho các kịch bản ngoại lệ (edge cases) trong quản lý kho và xử lý đơn hàng.
NF-UAT-REPORT-001	Báo cáo Kiểm thử Chấp nhận Người dùng (UAT Report)	Đánh giá sự chấp nhận của người dùng cuối đối với hệ thống đã triển khai.	Nghiệp vụ, QA, Nội bộ	/03-templates/UAT-Report-v1.0.md (báo cáo UAT Module Đơn hàng v1.0)	Business Owner, End Users, QA	Báo cáo UAT Module Đơn hàng: "15/20 user story PASS, 5 FAIL (Critical) liên quan đến quy trình hủy đơn hàng và hoàn tiền không đồng bộ."	Tất cả user story chính được PASS. Có chữ ký chấp nhận từ Business Owner.	Mới nhất sau khi hoàn thành UAT.	Có lỗi "Critical" chưa được giải quyết. Không có chữ ký chấp nhận chính thức từ Business Owner.	Chưa có phê duyệt UAT chính thức từ toàn bộ Business Owner. 5 lỗi Critical cần được giải quyết và kiểm thử lại.
NF-COMPL-CHECK-001	Danh mục Kiểm tra Tuân thủ (Compliance Checklist)	Đảm bảo hệ thống tuân thủ các quy định pháp luật hiện hành của Việt Nam.	Pháp lý, Bên ngoài	Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP (hóa đơn), Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15	Legal Dept, Compliance Officer	Danh mục kiểm tra: "Đảm bảo hệ thống ERP phát hành hóa đơn điện tử theo NĐ 123/2020/NĐ-CP; xử lý dữ liệu cá nhân của khách hàng và nhân viên theo Luật 91/2025/QH15."	Đối chiếu với văn bản pháp luật hiện hành và diễn giải của chuyên gia pháp lý.	Cập nhật theo thời gian thực (real-time) với các thay đổi pháp luật.	Có bất kỳ điểm không tuân thủ nào được xác định.	Cần xác minh phiên bản pháp luật cập nhật nhất và sự diễn giải chính thức của Legal Dept về Luật 91/2025/QH15 có áp dụng cụ thể cho dữ liệu khách hàng và nhân viên của Nova Foods.
NF-STAKE-INT-003	Ghi chú Phỏng vấn Stakeholder	Thu thập thông tin trực tiếp, các yêu cầu ẩn hoặc thông tin ngữ cảnh quan trọng từ người dùng.	Nghiệp vụ, Nội bộ	/05-stakeholder-interviews/Transcript-WarehouseMgr-20260715.pdf	BA	Ghi chú phỏng vấn Thủ kho: "Yêu cầu cảnh báo tự động khi tồn kho một lô sản phẩm cụ thể (ví dụ, lô sữa chua hết hạn trong 30 ngày) dưới mức tối thiểu an toàn để tránh hết hạn sử dụng."	Rõ ràng, dễ hiểu, có ghi nhận ngày phỏng vấn.	Không quá 1 tháng kể từ phỏng vấn để đảm bảo tính thời sự.	Ghi chú mơ hồ, không rõ ràng về yêu cầu. Mâu thuẫn với yêu cầu đã được ghi nhận.	Cần chuyển yêu cầu này thành yêu cầu chính thức, có ID truy vết và được phê duyệt để đưa vào BRD/FSD.
NF-DM-PLAN-001	Kế hoạch Di chuyển Dữ liệu (Data Migration Plan)	Đánh giá chiến lược chuyển đổi dữ liệu từ hệ thống cũ sang ERP mới.	Kỹ thuật, Nội bộ	/03-templates/DataMigrationPlan-v1.0.md	Data Architect, Tech Lead	Kế hoạch: "Di chuyển dữ liệu sản phẩm (master data), dữ liệu kho (transactional data) từ hệ thống cũ (tập tin Excel và Access DB) sang ERP Database (PostgreSQL), với quy trình làm sạch dữ liệu 3 bước (chuẩn hóa, loại bỏ trùng lặp, xác thực)."	Xác định rõ ràng nguồn, đích, quy tắc chuyển đổi, kế hoạch kiểm tra dữ liệu sau di chuyển.	Phiên bản cuối cùng trước khi di chuyển dữ liệu chính thức.	Thiếu kế hoạch kiểm tra dữ liệu sau di chuyển. Thiếu chiến lược xử lý dữ liệu lỗi.	Chưa xác minh kế hoạch kiểm tra và đối chiếu dữ liệu sau khi di chuyển thử nghiệm (mock migration).

5. Step-by-step BA Activities

Core

Capstone Review and Evaluation (Đánh giá Cuối kỳ và Thẩm định) — quá trình BA kiểm tra, xác nhận hệ thống hoặc tính năng mới trước bàn giao. Mục đích: đảm bảo tính năng đáp ứng yêu cầu, chất lượng, sẵn sàng triển khai. Bao gồm: thu thập bằng chứng, xác minh, đối chiếu với tiêu chuẩn đã đặt ra. Mỗi bước cần rõ ràng: ai làm (actor), làm gì (action), trên đối tượng nào (object), bằng chứng gì (evidence), quy tắc quyết định (decision rule), cổng chất lượng (quality gate) và lộ trình leo thang (escalation route).

Applied

Nova Foods triển khai module tự động hóa trạng thái hợp đồng đông lạnh (NOVA-MOD-FCA-001). Module này thay thế quy trình thủ công cập nhật trạng thái hợp đồng mua bán/phân phối sản phẩm đông lạnh (ví dụ: chuyển từ PENDING_REVIEW sang ACTIVE_FROZEN hoặc EXPIRED dựa trên ngày hiệu lực, ngày hết hạn và cờ tuân thủ chuỗi lạnh).

Nova Foods Case: Tự động hóa Trạng thái Hợp đồng Đông lạnh

• Facts (Sự kiện): Module NOVA-MOD-FCA-001 phát triển hoàn tất. Trạng thái hợp đồng mô phỏng là IN_REVIEW, phiên bản v0.9.0. Ngày hiện tại 2026-08-07.
• Current Behavior (Hành vi Hiện tại): Nhân viên thủ công kiểm tra ngày hiệu lực/hết hạn hợp đồng, cập nhật trạng thái. Tỷ lệ lỗi cao, chậm.
• Underlying Need (Nhu cầu Cơ bản): Tự động hóa cập nhật trạng thái hợp đồng. Tăng tốc độ, độ chính xác. Giảm thiểu sai sót thủ công. Tuân thủ pháp lý về thời hạn sản phẩm đông lạnh.
• Options (Các Tùy chọn):
  1. Cải thiện thủ công: Đào tạo, checklist mới.
  2. Bán tự động: Script báo cáo, kích hoạt thủ công.
  3. Tự động hoàn toàn: Hệ thống tự động kích hoạt cập nhật theo tiêu chí.
• Decision Criteria (Tiêu chí Quyết định): Chi phí, tốc độ, độ chính xác, mức độ tuân thủ, rủi ro vận hành.
• Decision (Quyết định): Tự động hoàn toàn (Option 3). Cung cấp lợi ích lớn nhất về hiệu quả, tuân thủ.
• Authority (Thẩm quyền): Business Owner (Chủ sở hữu Nghiệp vụ), Product Owner (Chủ sở hữu Sản phẩm), Legal (Bộ phận Pháp chế).
• Artifact (Tài liệu Đầu ra): Functional Specification Document (FS-NF-FCA-001-v1.0), Test Plan (TP-NF-FCA-001-v1.0), User Acceptance Test Report (UATR-NF-FCA-001-v1.0).
• Consequence if Wrong (Hậu quả nếu Sai): Phạt hành chính từ cơ quan quản lý (do vi phạm Luật An toàn thực phẩm 55/2010/QH12 về kiểm soát hàng hóa), bán sản phẩm hết hạn cho khách hàng, tổn thất tồn kho sản phẩm không bán được.

Quy trình BA cho Capstone Review module NOVA-MOD-FCA-001:

1. Chuẩn bị Tài liệu (Preparation):
   • Actor: Business Analyst (BA).
   • Action: Thu thập và xác minh tất cả tài liệu cần thiết.
   • Object: FSD (FS-NF-FCA-001-v1.0), Test Cases (trường hợp kiểm thử) từ QA (TC-NF-FCA-001-v1.0), quyền truy cập hệ thống ERP Nova Foods.
   • Evidence (Bằng chứng): Danh sách tài liệu kiểm kê hoàn tất (CHECK-NF-FCA-001-v1.0).
   • Decision Rule (Quy tắc Quyết định): Tất cả tài liệu đầu vào có sẵn, phiên bản chính xác.
   • Quality Gate (Cổng Chất lượng): BA xác nhận đầy đủ đầu vào.
   • Escalation Route (Lộ trình Leo thang): Thiếu tài liệu hoặc tài liệu không đúng phiên bản → Project Manager (Quản lý Dự án).
2. Đánh giá Yêu cầu Chức năng (Review Functional Requirements):
   • Actor: Business Analyst.
   • Action: So sánh tính năng đã phát triển với tài liệu FSD. Đảm bảo module làm đúng như đặc tả.
   • Object: Module NOVA-MOD-FCA-001 trên môi trường Test/Staging, FSD (FS-NF-FCA-001-v1.0).
   • Evidence: Báo cáo đánh giá chức năng (REV-NF-FCA-001-v1.0).
   • Decision Rule: Chức năng hệ thống khớp 100% FSD. Không có chức năng dư thừa hoặc thiếu.
   • Quality Gate: Chức năng hoạt động như mô tả trong FSD.
   • Escalation Route: Chức năng không khớp FSD hoặc có sai sót → Development Lead (Trưởng nhóm Phát triển).
3. Xác nhận Kết quả Test (Validate Test Results):
   • Actor: Business Analyst.
   • Action: Xem xét kết quả kiểm thử từ nhóm QA. Đảm bảo kiểm thử đầy đủ, lỗi được xử lý.
   • Object: Báo cáo kết quả kiểm thử (TR-NF-FCA-001-v1.0), ma trận truy vết (traceability matrix) giữa yêu cầu và test case.
   • Evidence: Xác nhận kết quả test (Test result sign-off) từ BA (BA-SO-TR-NF-FCA-001-v1.0).
   • Decision Rule: Tất cả test case mức độ nghiêm trọng Critical và High đều Passed. Không còn lỗi tồn đọng có tác động lớn.
   • Quality Gate: Báo cáo QA không có lỗi Critical hoặc High chưa được giải quyết.
   • Escalation Route: Có lỗi Critical/High chưa khắc phục → QA Lead (Trưởng nhóm QA).
4. Hỗ trợ UAT Người dùng Nghiệp vụ (UAT Facilitation):
   • Actor: Business Analyst.
   • Action: Hướng dẫn và hỗ trợ người dùng nghiệp vụ (Business Users) thực hiện UAT. Thu thập phản hồi.
   • Object: Kịch bản UAT (UATS-NF-FCA-001-v1.0), module NOVA-MOD-FCA-001 trên môi trường UAT.
   • Evidence: Biên bản nghiệm thu người dùng (UAT sign-off form) (UAT-SO-NF-FCA-001-v1.0).
   • Decision Rule: Người dùng nghiệp vụ xác nhận module đáp ứng nhu cầu, sẵn sàng sử dụng.
   • Quality Gate: Người dùng nghiệp vụ phê duyệt UAT.
   • Escalation Route: Người dùng nghiệp vụ từ chối nghiệm thu → Business Owner, Project Manager.
5. Bàn giao có Kiểm soát (Controlled Handoff):
   • Actor: Business Analyst.
   • Action: Hoàn tất tài liệu phê duyệt, chuẩn bị cho triển khai (deployment).
   • Object: FSD cuối cùng đã được phê duyệt, biên bản UAT sign-off, danh sách kiểm tra sẵn sàng triển khai (PRC-NF-FCA-001-v1.0).
   • Evidence: Tài liệu bàn giao (HND-NF-FCA-001-v1.0).
   • Decision Rule: Tất cả các bên liên quan đã ký xác nhận bàn giao.
   • Quality Gate: Project Manager phê duyệt triển khai.
   • Escalation Route: Thiếu bất kỳ phê duyệt nào → Stakeholder (Các bên liên quan) bị thiếu.

Nova Foods Execution Table: Capstone Review NOVA-MOD-FCA-001

Bước	Actor	Action	Object	Evidence Produced	Decision Rule	Quality Gate	Escalation Route
1. Chuẩn bị Tài liệu	BA	Thu thập, xác minh tài liệu	FSD, Test Cases, ERP Access	CHECK-NF-FCA-001-v1.0	Tài liệu đủ, đúng version	BA xác nhận đủ đầu vào	Thiếu tài liệu → Project Manager
2. Đánh giá Yêu cầu Chức năng	BA	So sánh module với FSD	Module NOVA-MOD-FCA-001, FSD	REV-NF-FCA-001-v1.0	Chức năng khớp FSD	Chức năng hoạt động như mô tả	Chức năng không khớp → Development Lead
3. Xác nhận Kết quả Test	BA	Xem xét báo cáo test QA	TR-NF-FCA-001-v1.0, Traceability Matrix	BA-SO-TR-NF-FCA-001-v1.0	Critical/High test Passed	QA không báo lỗi Critical/High	Test lỗi Critical/High → QA Lead
4. Hỗ trợ UAT Người dùng	BA	Hướng dẫn UAT người dùng nghiệp vụ	Kịch bản UAT, Module ERP	UAT-SO-NF-FCA-001-v1.0	Người dùng chấp nhận module	Người dùng nghiệp vụ phê duyệt UAT	UAT thất bại → Business Owner, Project Manager
5. Bàn giao có Kiểm soát	BA	Hoàn tất phê duyệt, chuẩn bị triển khai	FSD cuối, UAT Sign-off, PRC	HND-NF-FCA-001-v1.0	Tất cả ký xác nhận bàn giao	Project Manager phê duyệt triển khai	Thiếu phê duyệt → Stakeholder liên quan

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

graph TB
    A[Bắt đầu: Capstone Review NOVA-MOD-FCA-001] --> B[1. BA: Chuẩn bị Tài liệu<br/>Evidence: CHECK-NF-FCA-001-v1.0]
    B --> C{Tài liệu đầy đủ và đúng phiên bản?}
    C -- Có --> D[2. BA: Đánh giá Yêu cầu Chức năng<br/>Evidence: REV-NF-FCA-001-v1.0]
    C -- Không --> E[Leo thang: Project Manager]
    D --> F{Khớp 100% FSD, không thừa hoặc thiếu chức năng?}
    F -- Có --> G[3. BA: Xác nhận Kết quả Test QA<br/>Evidence: BA-SO-TR-NF-FCA-001-v1.0]
    F -- Không --> H[Leo thang: Development Lead]
    G --> I{Mọi test Critical/High Passed và không còn lỗi Critical/High chưa giải quyết?}
    I -- Có --> J[4. BA: Hỗ trợ UAT Người dùng Nghiệp vụ<br/>Evidence: UAT-SO-NF-FCA-001-v1.0]
    I -- Không --> K[Leo thang: QA Lead]
    J --> L{UAT được người dùng nghiệp vụ phê duyệt?}
    L -- Có --> M[5. BA: Bàn giao có Kiểm soát<br/>Evidence: HND-NF-FCA-001-v1.0]
    L -- Không --> N[Leo thang: Business Owner và Project Manager]
    M --> O{Đủ chữ ký và Project Manager phê duyệt triển khai?}
    O -- Có --> P[Kết thúc: Sẵn sàng Triển khai]
    O -- Không --> Q[Leo thang: Stakeholder còn thiếu phê duyệt]

Senior Lens

Quy trình đánh giá không chỉ để check box (đánh dấu hoàn thành). Mục tiêu chính: giảm rủi ro trước khi triển khai. Capstone Review là cơ hội cuối cùng để phát hiện và sửa lỗi chi phí thấp. BA cần xác định sớm các vấn đề. Tối ưu hóa "cổng chất lượng" (Quality Gate) tại mỗi bước. Tập trung vào "Consequence if Wrong". Vấn đề nhỏ nay, vấn đề lớn mai. Không bỏ qua lỗi nhỏ, nhất là khi liên quan tuân thủ (ví dụ: Luật An toàn thực phẩm, Luật Kế toán). Phê duyệt không phải thủ tục, là trách nhiệm pháp lý, nghiệp vụ. Baseline (điểm chuẩn) rõ ràng từ FSD giúp đối chiếu khách quan.

Quick Reference

• Capstone Review: Xác nhận hệ thống/tính năng sẵn sàng.
• 5 Bước Chính: Chuẩn bị, Đánh giá Chức năng, Xác nhận Test, Hỗ trợ UAT, Bàn giao.
• Mỗi bước: Rõ ràng Actor, Action, Object, Evidence, Decision Rule, Quality Gate, Escalation.
• Mục tiêu: Giảm rủi ro, đảm bảo chất lượng, tuân thủ.
• Quan trọng: Phê duyệt đầy đủ, tài liệu minh bạch.

Mô tả Hoạt động BA (BA Activities Description)

Core

Capstone Review (Đánh giá Đầu cuối) là một hoạt động thiết yếu của Chuyên viên Phân tích Nghiệp vụ (BA) trong giai đoạn cuối của dự án. Mục đích chính là tổng hợp, kiểm tra, và xác nhận toàn bộ các tài liệu (artifacts) nghiệp vụ đã được tạo ra, đảm bảo chúng đầy đủ, nhất quán, chính xác, và phản ánh đúng yêu cầu đã được thống nhất. Hoạt động này giúp giảm thiểu rủi ro phát sinh lỗi muộn, cung cấp bằng chứng truy vết rõ ràng, và chuẩn bị cho quá trình bàn giao dự án một cách hiệu quả. Chuyên viên BA đóng vai trò trung tâm trong việc tổ chức, thực hiện, và điều phối đánh giá này để đảm bảo sản phẩm đáp ứng kỳ vọng nghiệp vụ và các tiêu chuẩn chất lượng.

Applied

Quy trình Đánh giá Đầu cuối cho Capstone tại Nova Foods (mô phỏng giáo dục) bao gồm các bước sau, mỗi bước được định nghĩa rõ ràng về người thực hiện, hành động, đối tượng, bằng chứng, quy tắc quyết định, cổng chất lượng và kênh leo thang.

1. Chuẩn bị Hồ sơ Đánh giá Đầu cuối (Capstone Review Package Preparation)

Thuộc tính	Mô tả
Người thực hiện (Actor)	Chuyên viên Phân tích Nghiệp vụ (BA) chính của dự án.
Hành động (Action)	Tập hợp toàn bộ các tài liệu nghiệp vụ (business artifacts) đã được tạo ra xuyên suốt vòng đời dự án. Bao gồm đặc tả yêu cầu (BRD, SRS), mô hình quy trình (BPMN), mô hình dữ liệu (ERD logic), ma trận truy vết (RTM), tiêu chí chấp nhận (Acceptance Criteria), các biên bản họp liên quan đến quyết định nghiệp vụ, và bất kỳ tài liệu hỗ trợ nào khác (ví dụ: tài liệu khảo sát, phân tích khoảng cách).
Đối tượng (Object)	CAPSTONE_REVIEW_PACKAGE_{PROJECT_ID}: Bộ hồ sơ đánh giá đầu cuối, thường là một thư mục được tổ chức trên hệ thống quản lý tài liệu (DMS - Document Management System).
Bằng chứng tạo ra (Evidence Produced)	/02-handbook/24-capstone-review-and-evaluation/{PROJECT_ID}/CapstoneReviewPackage_v{VERSION}.zip (tệp nén chứa tất cả tài liệu) HOẶC URL_TO_DMS_FOLDER/{PROJECT_ID}/CapstoneReviewPackage (liên kết đến thư mục trên hệ thống). Kèm theo một CHECKLIST_PREP_{PROJECT_ID}.md đã hoàn thành, có chữ ký điện tử xác nhận của BA.
Quy tắc quyết định (Decision Rule)	Hồ sơ được coi là hoàn chỉnh nếu tất cả các tài liệu được định nghĩa trong /01-curriculum/TEMPLATE_MANIFEST.md và /01-curriculum/CHAPTER_MANIFEST.md là bắt buộc cho phạm vi dự án này đều có mặt, hoặc có ghi chú lý do thiếu được Lead BA phê duyệt.
Cổng chất lượng (Quality Gate)	Danh mục tài liệu trong hồ sơ phải khớp với danh mục tiêu chuẩn của tổ chức cho một dự án có quy mô và độ phức tạp tương đương. Tỷ lệ hoàn thành tài liệu theo danh mục chuẩn phải đạt tối thiểu 95%.
Kênh leo thang (Escalation Route)	Nếu cổng chất lượng không đạt, BA phải thông báo cho Trưởng nhóm BA (Lead BA) và Quản lý Dự án (Project Manager). Cần lập báo cáo các mục còn thiếu và đề xuất phương án khắc phục (ví dụ: bổ sung tài liệu, điều chỉnh phạm vi đánh giá).

2. Xem xét Sơ bộ Hồ sơ (Preliminary Review)

Thuộc tính	Mô tả
Người thực hiện (Actor)	Trưởng nhóm BA (Lead BA) hoặc một BA cấp cao được chỉ định độc lập với dự án.
Hành động (Action)	Tiến hành xem xét nhanh (walk-through) CAPSTONE_REVIEW_PACKAGE_{PROJECT_ID} để kiểm tra tính logic tổng thể, sự nhất quán giữa các tài liệu chính (ví dụ: yêu cầu cấp cao và mô hình quy trình), và xác định các khu vực có rủi ro cao cần đánh giá chuyên sâu hơn. Không đi sâu vào từng chi tiết.
Đối tượng (Object)	CAPSTONE_REVIEW_PACKAGE_{PROJECT_ID} đã được chuẩn bị bởi BA.
Bằng chứng tạo ra (Evidence Produced)	PRELIM_REVIEW_REPORT_{PROJECT_ID}.md hoặc email tóm tắt các điểm cần chú ý, với danh sách các khu vực rủi ro tiềm tàng và các câu hỏi cần làm rõ.
Quy tắc quyết định (Decision Rule)	Nếu không có bất kỳ mâu thuẫn lớn, thiếu sót rõ ràng, hoặc khu vực rủi ro cực kỳ cao nào có thể làm đình trệ toàn bộ quá trình đánh giá chi tiết, thì hồ sơ được chấp nhận để chuyển sang bước đánh giá chi tiết.
Cổng chất lượng (Quality Gate)	Báo cáo sơ bộ không được chứa quá 3 "major finding" (lỗi lớn) về tính nhất quán hoặc đầy đủ tổng thể. Tất cả các điểm cần làm rõ phải được Lead BA hoặc Project Manager đồng ý rằng có thể giải quyết trong giai đoạn đánh giá chi tiết mà không cần dừng dự án.
Kênh leo thang (Escalation Route)	Nếu có nhiều hơn 3 "major finding" hoặc có một "critical finding" (lỗi nghiêm trọng) ảnh hưởng đến khả năng tiếp tục dự án, Lead BA phải ngay lập tức thông báo cho Giám đốc Dự án (Program Director) và Khối nghiệp vụ (Business Unit Head) để quyết định phương án tiếp theo, có thể là tạm dừng đánh giá hoặc yêu cầu chỉnh sửa khẩn cấp.

3. Đánh giá Chi tiết và Xác thực (Detailed Evaluation & Validation)

Thuộc tính	Mô tả
Người thực hiện (Actor)	Nhóm đánh giá chéo (Cross-functional Review Team) bao gồm BA, Kiến trúc sư (Architect), Đại diện nghiệp vụ (Business Representative), và Quản lý chất lượng (QA Lead).
Hành động (Action)	Thực hiện đánh giá từng tài liệu trong CAPSTONE_REVIEW_PACKAGE_{PROJECT_ID} theo các tiêu chí đã định (tính đầy đủ, nhất quán, chính xác, khả thi, có thể kiểm thử được). Sử dụng các kỹ thuật như phân tích kịch bản (scenario analysis), kiểm tra truy vết (traceability matrix review), đối chiếu yêu cầu với các quy định pháp luật (ví dụ: Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán cho Nova Foods) và chuẩn ngành (ví dụ: OWASP ASVS cho bảo mật).
Đối tượng (Object)	Từng tài liệu BA trong CAPSTONE_REVIEW_PACKAGE_{PROJECT_ID}.
Bằng chứng tạo ra (Evidence Produced)	DETAILED_REVIEW_REPORT_{PROJECT_ID}.xlsx (báo cáo chi tiết các phát hiện, mức độ ưu tiên, chủ sở hữu và trạng thái) và UPDATED_RTM_{PROJECT_ID}.xlsx (ma trận truy vết được cập nhật hoặc xác nhận) và các ISSUE_LOG_{PROJECT_ID}.csv ghi nhận chi tiết các vấn đề phát sinh.
Quy tắc quyết định (Decision Rule)	Mỗi phát hiện (finding) phải được ghi lại rõ ràng, gán mức độ ưu tiên (P1-Critical, P2-High, P3-Medium, P4-Low) và chỉ định chủ sở hữu (owner). Hồ sơ được chấp nhận để chuyển sang bước xử lý nếu không có phát hiện P1, và tổng số phát hiện P2 không vượt quá 5% tổng số yêu cầu đã được xem xét.
Cổng chất lượng (Quality Gate)	Tất cả phát hiện P1 phải được giải quyết hoặc có kế hoạch giải quyết được phê duyệt. Ít nhất 80% phát hiện P2 phải có kế hoạch khắc phục rõ ràng và được Team Lead đồng ý.
Kênh leo thang (Escalation Route)	Nếu không đạt cổng chất lượng, BA phải triệu tập cuộc họp khẩn cấp với các chủ sở hữu liên quan và Lead BA để đánh giá lại rủi ro. Nếu vấn đề không thể giải quyết nội bộ, phải leo thang lên Giám đốc Dự án và Khối nghiệp vụ để cân nhắc các lựa chọn như trì hoãn dự án, giảm phạm vi (scope reduction) hoặc tăng cường nguồn lực.

4. Xử lý Vấn đề và Thay đổi (Issue & Change Resolution)

Thuộc tính	Mô tả
Người thực hiện (Actor)	BA (điều phối), Chủ sở hữu phát hiện (owner), các bên liên quan (stakeholders) như Business Owner, Development Team, QA Team.
Hành động (Action)	BA phối hợp với các chủ sở hữu để giải quyết các phát hiện đã ghi nhận. Bao gồm cập nhật tài liệu, điều chỉnh yêu cầu, làm rõ nghiệp vụ hoặc đề xuất thay đổi. Đối với các yêu cầu thay đổi lớn, cần tuân thủ quy trình quản lý thay đổi (Change Control Process) của tổ chức.
Đối tượng (Object)	DETAILED_REVIEW_REPORT_{PROJECT_ID}.xlsx, các tài liệu BA bị ảnh hưởng (BRD_{PROJECT_ID}.md, SRS_{PROJECT_ID}.md, BPMN_{PROJECT_ID}.bpmn).
Bằng chứng tạo ra (Evidence Produced)	UPDATED_DETAILED_REVIEW_REPORT_{PROJECT_ID}.xlsx với trạng thái "Closed" hoặc "Mitigated" cho các phát hiện. CHANGE_REQUEST_LOG_{PROJECT_ID}.xlsx cho các thay đổi lớn, và các phiên bản tài liệu BA đã được cập nhật (BRD_vX.Y.md, SRS_vX.Y.md).
Quy tắc quyết định (Decision Rule)	Tất cả các phát hiện P1 và P2 đều phải có trạng thái "Closed" hoặc "Mitigated" với phê duyệt từ chủ sở hữu và Lead BA. Các thay đổi đối với tài liệu gốc phải được ghi lại rõ ràng trong lịch sử phiên bản của tài liệu.
Cổng chất lượng (Quality Gate)	Không còn phát hiện P1. Tất cả phát hiện P2 đã được xử lý hoặc có kế hoạch xử lý được phê duyệt chính thức. Các tài liệu đã chỉnh sửa phải được kiểm tra lại nhanh (spot-check) bởi Lead BA để đảm bảo không phát sinh vấn đề mới.
Kênh leo thang (Escalation Route)	Nếu không thể đóng hoặc giảm thiểu các phát hiện P1, P2 mà không ảnh hưởng đến phạm vi, thời gian hoặc chi phí, BA phải leo thang lên Quản lý Dự án và Business Owner để đưa ra quyết định cuối cùng về việc chấp nhận rủi ro hoặc điều chỉnh kế hoạch dự án.

5. Báo cáo và Đề xuất (Reporting & Recommendation)

Thuộc tính	Mô tả
Người thực hiện (Actor)	BA chính và Lead BA.
Hành động (Action)	Tổng hợp kết quả đánh giá, bao gồm các điểm mạnh, điểm yếu, các rủi ro còn lại và các đề xuất cải tiến. Chuẩn bị một báo cáo tổng thể để trình bày cho các bên liên quan cấp cao.
Đối tượng (Object)	CAPSTONE_REVIEW_REPORT_{PROJECT_ID}.md hoặc CAPSTONE_REVIEW_SUMMARY_PRESENTATION_{PROJECT_ID}.pptx.
Bằng chứng tạo ra (Evidence Produced)	CAPSTONE_REVIEW_REPORT_{PROJECT_ID}_vX.Y.md đã được Lead BA phê duyệt, và REVIEW_MEETING_MINUTES_{PROJECT_ID}.md ghi nhận các quyết định và hành động tiếp theo từ cuộc họp trình bày báo cáo.
Quy tắc quyết định (Decision Rule)	Báo cáo phải bao gồm tất cả các phát hiện quan trọng (major findings), tình trạng giải quyết, các rủi ro còn lại được chấp nhận, và phải được Lead BA xác nhận tính chính xác và đầy đủ.
Cổng chất lượng (Quality Gate)	Báo cáo phải rõ ràng, súc tích, khách quan và cung cấp đủ thông tin cho các bên liên quan cấp cao để đưa ra quyết định chấp thuận cuối cùng. Báo cáo được gửi đến Giám đốc Dự án và Business Owner ít nhất 3 ngày làm việc trước cuộc họp trình bày.
Kênh leo thang (Escalation Route)	Nếu báo cáo không được Lead BA phê duyệt, hoặc các bên liên quan cấp cao yêu cầu làm rõ thêm các vấn đề tồn đọng mà BA không thể cung cấp, cần tổ chức các buổi họp bổ sung hoặc yêu cầu Lead BA trực tiếp làm việc với các bên liên quan để làm rõ.

6. Bàn giao Chính thức (Formal Handoff)

Thuộc tính	Mô tả
Người thực hiện (Actor)	Quản lý Dự án (Project Manager) và Lead BA (thay mặt BA).
Hành động (Action)	Tổ chức buổi bàn giao chính thức CAPSTONE_REVIEW_PACKAGE_{PROJECT_ID} và CAPSTONE_REVIEW_REPORT_{PROJECT_ID} cho nhóm vận hành (Operations Team), nhóm hỗ trợ (Support Team), và các bên liên quan khác cần duy trì hệ thống sau triển khai.
Đối tượng (Object)	Toàn bộ hồ sơ đánh giá đầu cuối đã được chỉnh sửa và báo cáo cuối cùng.
Bằng chứng tạo ra (Evidence Produced)	FORMAL_HANDOFF_SIGN_OFF_{PROJECT_ID}.md hoặc EMAIL_CONFIRMATION_OF_HANDOFF_{PROJECT_ID}.eml có chữ ký của đại diện các bên nhận bàn giao, xác nhận đã nhận và hiểu rõ nội dung.
Quy tắc quyết định (Decision Rule)	Việc bàn giao được coi là thành công khi tất cả các bên liên quan đã ký xác nhận vào tài liệu bàn giao, đồng thời không có câu hỏi mở nào liên quan đến các tài liệu trong CAPSTONE_REVIEW_PACKAGE_{PROJECT_ID} từ các bên nhận.
Cổng chất lượng (Quality Gate)	Tài liệu bàn giao phải được ký xác nhận bởi Business Owner, Project Manager, Lead BA, và đại diện nhóm Vận hành/Hỗ trợ. Tất cả các tài liệu được bàn giao phải được lưu trữ trên hệ thống DMS với quyền truy cập phù hợp cho các nhóm nhận.
Kênh leo thang (Escalation Route)	Nếu bất kỳ bên nào từ chối ký xác nhận bàn giao hoặc có các vấn đề lớn chưa được giải quyết, Project Manager phải triệu tập cuộc họp với các bên liên quan cấp cao để giải quyết. Điều này có thể dẫn đến việc trì hoãn bàn giao hoặc tái cấu trúc một phần dự án.

Biểu đồ mô tả luồng Capstone Review:

graph TD
    A[Bắt đầu: Chuẩn bị Hồ sơ Đánh giá] --> B{Hồ sơ Hoàn chỉnh?};
    B -- Có --> C[Xem xét Sơ bộ bởi Lead BA];
    B -- Không --> D[Thông báo & Sửa chữa];
    D --> A;
    C -- Sơ bộ Đạt --> E[Đánh giá Chi tiết & Xác thực];
    C -- Sơ bộ Không Đạt --> F[Leo thang Khẩn cấp];
    E -- Có Phát hiện P1, P2? --> G{Phát hiện Quan trọng?};
    G -- Có --> H[Xử lý Vấn đề & Thay đổi];
    G -- Không (Đạt) --> I[Báo cáo & Đề xuất];
    H -- Vấn đề đã giải quyết? --> I;
    H -- Vấn đề chưa giải quyết --> J[Leo thang: Điều chỉnh Kế hoạch];
    I --> K{Báo cáo chấp thuận?};
    K -- Có --> L[Bàn giao Chính thức];
    K -- Không --> J;
    L --> M[Kết thúc];
    F --> M_Error[Kết thúc (Lỗi)];
    J --> M_Adjust[Kết thúc (Kế hoạch Điều chỉnh)];

Tình huống Phát hiện Yêu cầu Thiếu Sót trong Nova Foods (Nova Foods Missing Requirement Detection Scenario)

• Sự kiện (Facts): Trong quá trình "Đánh giá Chi tiết và Xác thực" (Bước 3), nhóm đánh giá chéo của Nova Foods phát hiện yêu cầu NF-REQ-ACC-005: "Hệ thống phải hỗ trợ xuất báo cáo tài chính theo chuẩn IFRS" không có mặt trong /docs/nova_foods_erp_srs_v0.9.md, nhưng có trong danh sách yêu cầu cấp cao ban đầu của Business Owner. Yêu cầu này ảnh hưởng đến việc tuân thủ pháp luật kế toán (Luật Kế toán 88/2015/QH13) cho các công ty con quốc tế của Nova Foods (dữ liệu mô phỏng).
• Hành vi Hiện tại (Current Behavior): SRS hiện tại chỉ tập trung vào chuẩn kế toán Việt Nam (VAS) và bỏ sót hoàn toàn yêu cầu IFRS. Các báo cáo tài chính dự kiến sẽ chỉ được tạo ra theo VAS.
• Nhu cầu Cơ bản (Underlying Need): Nova Foods cần một hệ thống ERP có khả năng tạo báo cáo tài chính tuân thủ cả chuẩn VAS cho thị trường nội địa và IFRS cho các hoạt động quốc tế, đảm bảo tính pháp lý và minh bạch tài chính. Việc thiếu IFRS là một thiếu sót nghiêm trọng.
• Các Tùy chọn (Options):
  1. Chấp nhận rủi ro: Triển khai hệ thống như hiện tại, chấp nhận việc không tuân thủ IFRS và xử lý thủ công các báo cáo IFRS.
  2. Hoãn triển khai: Tạm dừng triển khai hệ thống cho đến khi yêu cầu IFRS được thêm vào SRS, được phát triển và kiểm thử đầy đủ.
  3. Triển khai theo giai đoạn: Triển khai tính năng VAS trước, sau đó phát triển IFRS trong giai đoạn 2.
  4. Tăng nguồn lực: Nhanh chóng bổ sung yêu cầu IFRS vào SRS hiện có, tái phân bổ nguồn lực để phát triển và kiểm thử IFRS trong phạm vi dự án hiện tại.
• Tiêu chí Quyết định (Decision Criteria):
  • Mức độ rủi ro pháp lý (Legal risk, tham chiếu Luật Kế toán 88/2015/QH13).
  • Ảnh hưởng đến thời gian triển khai (Time to market).
  • Chi phí bổ sung (Additional cost).
  • Khả năng đáp ứng nhanh chóng của đội phát triển (Development team agility).
  • Đánh giá về tính thiết yếu của IFRS cho hoạt động quốc tế của Nova Foods.
• Quyết định (Decision): Sau khi tham vấn Legal Owner và Business Owner, quyết định chọn Tùy chọn 4: Tăng nguồn lực để bổ sung yêu cầu IFRS vào SRS và phát triển trong phạm vi dự án hiện tại, coi đây là một phát hiện P1 (Critical) cần được xử lý ngay lập tức.
• Thẩm quyền (Authority): Business Owner (Trưởng khối Tài chính), Project Manager, và Cố vấn Pháp lý (Legal Counsel). Lead BA điều phối quá trình đưa ra quyết định.
• Tài liệu (Artifact):
  • ISSUE_LOG_{PROJECT_ID}.csv được cập nhật với NF-ISSUE-001: Missing IFRS Requirement.
  • CHANGE_REQUEST_LOG_{PROJECT_ID}.xlsx ghi nhận yêu cầu thay đổi.
  • /docs/nova_foods_erp_srs_v0.9.md được cập nhật thành /docs/nova_foods_erp_srs_v1.0.md bao gồm NF-REQ-ACC-005 và các yêu cầu liên quan.
  • Biên bản cuộc họp quyết định (DECISION_MEETING_MINUTES_{PROJECT_ID}.md).
• Hậu quả nếu Sai (Consequence if Wrong): Nếu chọn Tùy chọn 1 (Chấp nhận rủi ro), Nova Foods có thể đối mặt với phạt hành chính, thiếu minh bạch tài chính, và mất uy tín với các nhà đầu tư hoặc đối tác quốc tế. Các công ty con quốc tế không thể tuân thủ luật pháp nước sở tại, dẫn đến đình chỉ hoạt động hoặc đóng cửa chi nhánh.

Senior Lens

Capstone Review không chỉ là danh sách kiểm tra (checklist). BA cấp cao hiểu rằng đây là cơ hội cuối cùng để xác nhận giá trị (value) của sản phẩm trước khi nó đến tay người dùng, đảm bảo mọi khoản đầu tư BA đã bỏ ra mang lại kết quả như mong đợi. Đánh giá này giúp phát hiện các vấn đề tiềm ẩn, không chỉ về tài liệu mà còn về sự hiểu biết chung giữa các bên, trước khi chúng trở thành các lỗi tốn kém hơn khi sản phẩm đi vào vận hành. Việc từ chối phê duyệt (sign-off) một hồ sơ không đạt chuẩn là trách nhiệm pháp lý và đạo đức, dù có thể gây khó chịu trong ngắn hạn, nhưng bảo vệ tổ chức khỏi rủi ro lớn hơn trong dài hạn. BA phải là người bảo vệ chất lượng cuối cùng.

Quick Reference

Các điểm chính: * Chất lượng toàn diện: Đánh giá Capstone kiểm tra mọi khía cạnh của tài liệu BA từ chuẩn bị đến bàn giao. * Truy vết rõ ràng: Đảm bảo mọi yêu cầu đều có nguồn gốc và được theo dõi xuyên suốt. * Giảm thiểu rủi ro: Phát hiện và giải quyết vấn đề sớm, tránh lỗi phát sinh muộn, đặc biệt là các rủi ro pháp lý và nghiệp vụ. * Bàn giao có kiểm soát: Chuẩn bị đầy đủ hồ sơ để đảm bảo việc vận hành và hỗ trợ sau triển khai diễn ra suôn sẻ.

Applied

Ví dụ ứng dụng: Quy trình rà soát yêu cầu chức năng mới cho hệ thống quản lý kho Nova Foods

• Sự kiện (Facts): Nova Foods, một doanh nghiệp sản xuất và phân phối thực phẩm đông lạnh (mô phỏng), đang trong quá trình triển khai module quản lý kho mới cho hệ thống ERP. Một yêu cầu nghiệp vụ quan trọng được đưa ra là: "Hệ thống phải tự động đề xuất vị trí lưu trữ tối ưu cho sản phẩm mới nhập kho dựa trên chủng loại, kích thước, trọng lượng và yêu cầu nhiệt độ bảo quản." Dữ liệu Nova Foods là tổng hợp và chỉ dùng cho mục đích giáo dục.
• Hành vi hiện tại (Current Behavior): Hiện tại, nhân viên kho Nova Foods tự quyết định vị trí lưu trữ sản phẩm mới nhập kho. Quyết định này dựa vào kinh nghiệm cá nhân, dẫn đến thời gian xử lý lâu, khả năng xảy ra lỗi cao (ví dụ: đặt sản phẩm cần bảo quản lạnh ở khu vực nhiệt độ thường), và không tối ưu hóa được không gian lưu trữ sẵn có.
• Nhu cầu cốt lõi (Underlying Need): Cần giảm thiểu lỗi trong quá trình nhập kho, tối ưu hóa việc sử dụng không gian kho, giảm thời gian xử lý thủ công, đảm bảo các sản phẩm dễ hỏng (như thực phẩm đông lạnh) được bảo quản đúng điều kiện từ khi nhập kho, và nâng cao hiệu quả vận hành tổng thể của kho.
• Các lựa chọn (Options):
  1. Lựa chọn 1: Cải thiện chương trình đào tạo và quy trình vận hành thủ công cho nhân viên kho.
  2. Lựa chọn 2: Phát triển tính năng đề xuất vị trí lưu trữ tự động trong module quản lý kho của hệ thống ERP.
  3. Lựa chọn 3: Kết hợp Lựa chọn 1 và 2 (đào tạo bổ sung cho nhân viên về cách sử dụng tính năng mới và các quy trình dự phòng).
• Tiêu chí ra quyết định (Decision Criteria):
  • Hiệu quả: Giảm tỷ lệ lỗi nhập kho xuống dưới 1% trong vòng 3 tháng sau triển khai.
  • Tốc độ: Giảm ít nhất 20% thời gian xử lý nhập kho trung bình.
  • Chi phí: Tổng chi phí phát triển và triển khai tính năng không vượt quá 500 triệu VND.
  • Tuân thủ: Đảm bảo tuân thủ các quy định về an toàn thực phẩm, đặc biệt là Luật An toàn thực phẩm Luật 55/2010/QH12 liên quan đến bảo quản sản phẩm.
  • Khả năng mở rộng: Có thể dễ dàng tích hợp với các loại sản phẩm và quy tắc lưu trữ mới trong tương lai.
• Quyết định (Decision): Nova Foods quyết định chọn Lựa chọn 2: Phát triển tính năng đề xuất vị trí tự động. Lựa chọn 3 sẽ được xem xét và bổ sung vào lộ trình sau khi tính năng tự động hoạt động ổn định và được đánh giá hiệu quả.
• Thẩm quyền (Authority): Business Owner (Giám đốc Vận hành Kho của Nova Foods), Product Owner (Đại diện nghiệp vụ), Trưởng phòng Business Analyst.
• Sản phẩm tạo ra (Artifact):
  • REQ-WHS-0012-v1.0.docx: Tài liệu Đặc tả Yêu cầu Chi tiết (Detailed Requirement Specification) cho tính năng đề xuất vị trí kho tự động.
  • NovaFoods_Warehouse_Storage_Optimization_Process.mmd: Sơ đồ quy trình rà soát yêu cầu sử dụng Mermaid.
  • Biên bản họp rà soát yêu cầu (Meeting Minutes) ghi nhận các quyết định và hạng mục hành động (Action Item).
• Hậu quả nếu sai (Consequence if Wrong): Nếu quyết định phát triển tính năng sai hoặc quá trình rà soát không kỹ lưỡng, Nova Foods có thể đối mặt với: tăng chi phí vận hành kho do kém hiệu quả, lãng phí không gian lưu trữ, hư hỏng hàng hóa (đặc biệt là thực phẩm đông lạnh) do sai điều kiện bảo quản, và rủi ro bị phạt hành chính vì không tuân thủ các quy định về an toàn thực phẩm.

Bảng thực thi quy trình rà soát yêu cầu cho Nova Foods (mô phỏng):

Bước	Diễn viên (Actor)	Hành động (Action)	Đối tượng (Object)	Bằng chứng (Evidence Produced)	Quy tắc quyết định (Decision Rule)	Cổng chất lượng (Quality Gate)	Lộ trình leo thang (Escalation Route)
1	BA	Chuẩn bị gói tài liệu rà soát (Review Pack)	REQ-WHS-0012-v0.9.docx, danh sách stakeholders	Review_Pack_WHS_0012_v1.0.zip	Gói tài liệu đủ thông tin cho cuộc rà soát.	Review Pack hoàn chỉnh và đã gửi cho các stakeholders trước 2 ngày họp.	BA Senior / Product Owner
2	BA, Business Owner, QA Lead, Dev Lead	Tổ chức họp rà soát yêu cầu	REQ-WHS-0012-v0.9.docx, NovaFoods_Warehouse_Storage_Optimization_Process.mmd	Biên bản họp (Meeting Minutes), danh sách vấn đề phát sinh (Issue), hạng mục hành động (Action Item)	Mọi stakeholder hiểu rõ và đồng ý về phạm vi, mục tiêu của yêu cầu.	Tất cả vấn đề phát sinh được ghi nhận và có chủ sở hữu, hạng mục hành động được phân công.	Product Owner / Trưởng phòng BA
3	Business Owner	Xác nhận nghiệp vụ (Business Sign-off)	REQ-WHS-0012-v0.9.docx	Email xác nhận, chữ ký trên tài liệu	Yêu cầu nghiệp vụ giải quyết đúng vấn đề, phù hợp chiến lược kinh doanh và tuân thủ các quy định (Luật An toàn thực phẩm Luật 55/2010/QH12).	Không có xung đột với các quy định pháp lý hoặc các yêu cầu nghiệp vụ hiện có.	Giám đốc Vận hành
4	QA Lead	Đánh giá khả năng kiểm thử (Testability Assessment)	REQ-WHS-0012-v0.9.docx	Danh sách Tiêu chí chấp nhận (Acceptance Criteria - AC) có thể kiểm thử	Mọi yêu cầu có ít nhất một AC rõ ràng, cụ thể và có thể kiểm thử độc lập.	Ít nhất 80% AC được xác định là kiểm thử được và không có AC nào mơ hồ.	BA Senior / QA Manager
5	BA	Cập nhật và ban hành yêu cầu	REQ-WHS-0012-v0.9.docx	REQ-WHS-0012-v1.0.docx (phiên bản cơ sở - Baseline), thông báo ban hành	Mọi thay đổi và quyết định từ cuộc rà soát được tích hợp chính xác vào tài liệu.	Tài liệu yêu cầu được ban hành chính thức dưới dạng phiên bản cơ sở (Baseline) và thông báo đến tất cả stakeholders.	Product Owner / BA Senior

Sơ đồ quy trình rà soát yêu cầu (Mermaid):

graph TD
    A[BA: Chuẩn bị gói tài liệu rà soát (Review Pack)] --> B{Gói Review hoàn chỉnh?}
    B -- Có --> C[BA: Lên lịch & Chủ trì họp rà soát]
    B -- Không --> D[BA: Cập nhật yêu cầu, Quay lại A]

    C --> E[Stakeholders: Đánh giá & Phản hồi yêu cầu]
    E --> F{Có vấn đề (Issue)/câu hỏi?}
    F -- Có --> G[BA: Ghi nhận Issue & Hạng mục hành động (Action Item)]
    G --> H[Stakeholders: Xác nhận Giải pháp/Quyết định]
    H --> I{Issue được giải quyết?}
    I -- Có --> F
    I -- Không --> J[BA: Leo thang (Escalation) - đến Product Owner/BA Senior]
    J --> H

    F -- Không --> K[Business Owner: Phê duyệt nghiệp vụ]
    K --> L[QA Lead: Xác nhận khả năng kiểm thử (Testability)]
    L --> M{Yêu cầu sẵn sàng cho Phát triển?}
    M -- Có --> N[BA: Ban hành Yêu cầu (Phiên bản cơ sở - Baseline)]
    M -- Không --> O[BA: Cập nhật yêu cầu, Quay lại C]

    N --> P[REQ-WHS-0012-v1.0 sẵn sàng cho Phát triển]

6. Output thu được

Các vật phẩm (artifacts) đầu ra từ quá trình Rà soát và Đánh giá Cuối kỳ là bằng chứng cụ thể cho sự thống nhất và quyết định. Chúng không chỉ là tài liệu mà là các điểm kiểm soát chất lượng, xác nhận yêu cầu sẵn sàng cho các giai đoạn tiếp theo (phát triển, kiểm thử).

Core

Vật phẩm đầu ra chính từ quy trình Rà soát và Đánh giá Cuối kỳ bao gồm Gói Tài liệu Rà soát, Biên bản Họp Rà soát và Tài liệu Yêu cầu được Cập nhật/Baseline. Mỗi vật phẩm có vai trò, nội dung tối thiểu, và cổng chất lượng riêng.

Vật phẩm Đầu ra (Artifact)	Chủ sở hữu (Owner)	Trạng thái (Status)	Nội dung Tối thiểu (Minimum Content)	Định danh Chuẩn (Canonical ID)	Nghĩa vụ Lịch sử Thay đổi (Change History Obligation)	Cổng Chất lượng (Quality Gate)
Gói Tài liệu Rà soát (Review Pack)	Business Analyst (BA)	DRAFT, FINALIZED, ARCHIVED	- Tài liệu Yêu cầu dự thảo (REQ-NF-WHS-0012-v0.9.0.docx) - Tài liệu hỗ trợ (quy trình, wireframes, user stories) - Chương trình họp (Agenda) - Danh sách người tham dự	RP-{MãDựÁn}-{MãModule}-{PhiênBản} Ví dụ: RP-NF-WHS-INV-v0.9.0	Mỗi gói là một bản ghi (snapshot) trước họp. Duy trì phiên bản gói.	Mọi tài liệu thành phần là phiên bản dự thảo mới nhất, đầy đủ, nhất quán. Sẵn sàng phân phối trước họp 2 ngày làm việc.
Biên bản Họp Rà soát (Review Meeting Minutes)	Business Analyst (BA)	DRAFT, IN_REVIEW, FINALIZED	- Thông tin họp (ngày, giờ, người tham dự, mục đích) - Thảo luận chính, các quyết định kèm lý do - Vấn đề (Issues) và trạng thái xử lý - Hạng mục hành động (Action Items): người phụ trách, thời hạn, trạng thái	MM-{MãDựÁn}-{MãModule}-{NgàyHọp}-{SốThứTự} Ví dụ: MM-NF-WHS-INV-20260807-001	Phiên bản hóa biên bản (v0.1 draft, v1.0 finalized). Không sửa đổi bản chính thức.	Tất cả bên liên quan chính đã rà soát và xác nhận tính chính xác trong vòng 24-48 giờ sau họp.
Tài liệu Yêu cầu Được Cập nhật/Baseline (Updated/Baselined Requirement Document)	Product Owner / Business Owner (nội dung), Business Analyst (quản lý phiên bản)	DRAFT, IN_REVIEW, FINALIZED, BASELINED	- Yêu cầu (chức năng, phi chức năng) đã cập nhật - Tiêu chí chấp nhận (Acceptance Criteria) - Phạm vi (Scope), Ngoài phạm vi (Out of Scope) - Bảng thuật ngữ (Glossary), Nhật ký thay đổi (Change Log)	REQ-{MãDựÁn}-{MãModule}-{SốThứTự}-{PhiênBản} Ví dụ: REQ-NF-WHS-0012-v1.0	Duy trì nhật ký thay đổi chi tiết trong tài liệu và hệ thống quản lý phiên bản. Mọi thay đổi sau Baseline phải có lý do, phê duyệt.	Mọi vấn đề từ rà soát đã xử lý/có kế hoạch. Business Owner đã phê duyệt nội dung nghiệp vụ. QA Lead xác nhận khả năng kiểm thử (testability).

Applied

Tình huống Nova Foods (Mô phỏng): Cập nhật Yêu cầu Chuyển Kho trong Hệ thống ERP

• Sự kiện (Facts): Nova Foods cần điều chỉnh quy trình chuyển kho nội bộ. Tài liệu yêu cầu REQ-NF-WHS-0012 về quản lý tồn kho trong Hệ thống Quản lý Kho (WHS) đang ở phiên bản dự thảo v0.9.0. Quy trình hiện tại cho phép kế toán kho điều chỉnh tồn kho trực tiếp không qua phê duyệt, gây rủi ro thất thoát hàng hóa.
• Hành vi Hiện tại (Current Behavior): Đội phát triển nhận bản v0.9.0 và bắt đầu viết code. Kiểm thử viên tự hiểu và viết test cases. Thiếu rà soát chính thức dẫn đến sai lệch với ý định nghiệp vụ, buộc phải sửa lại nhiều lần.
• Nhu cầu Cốt lõi (Underlying Need): Đảm bảo yêu cầu cập nhật về quy trình chuyển kho được các bên liên quan thống nhất và phê duyệt trước khi phát triển để giảm thiểu làm lại (rework), đảm bảo chất lượng và tuân thủ quy trình nội bộ của Nova Foods.
• Các Tùy chọn (Options):
  1. Tiếp tục hành vi hiện tại: Đội phát triển tự triển khai từ v0.9.0 không rà soát chính thức.
  2. Rà soát không chính thức: Gửi email bản v0.9.0 để lấy ý kiến.
  3. Rà soát và Đánh giá Cuối kỳ chính thức (Formal Capstone Review): Tổ chức cuộc họp chính thức, thu thập phản hồi, cập nhật và ban hành phiên bản yêu cầu đã được Baseline.
• Tiêu chí Quyết định (Decision Criteria): Giảm thiểu chi phí làm lại; mức độ thống nhất giữa các bên; khả năng truy vết và tuân thủ quy trình nội bộ (ví dụ: bằng chứng phê duyệt nghiệp vụ); sự rõ ràng cho đội phát triển và kiểm thử.
• Quyết định (Decision): Nova Foods chọn Tùy chọn 3: Thực hiện Rà soát và Đánh giá Cuối kỳ chính thức.
• Thẩm quyền (Authority): Product Owner, BA Senior.
• Vật phẩm Đầu ra (Artifacts Produced - Mô phỏng):
  • RP-NF-WHS-INV-v0.9.0: Gói Tài liệu Rà soát, chuẩn bị cho cuộc họp ngày 2026-08-07.
  • MM-NF-WHS-INV-20260807-001: Biên bản Họp Rà soát, ghi nhận các phản hồi và quyết định từ cuộc họp ngày 2026-08-07.
  • REQ-NF-WHS-0012-v1.0: Tài liệu Yêu cầu Quản lý Kho đã được cập nhật và Baseline, ban hành ngày 2026-08-07 sau phê duyệt.
• Hậu quả nếu Quyết định sai (Consequence if Wrong - chọn Tùy chọn 1 hoặc 2): REQ-NF-WHS-0012-v0.9.0 chứa logic chuyển kho chưa được phê duyệt. Đội phát triển triển khai sai tính năng dẫn đến sửa chữa tốn kém; kiểm thử viên viết test cases không chính xác, bỏ lỡ lỗi nghiệp vụ; người dùng nghiệp vụ (kế toán kho, quản lý kho) từ chối tính năng, gây trì hoãn dự án, tăng chi phí và có thể vi phạm quy định tài chính nội bộ.

Senior Lens

Góc nhìn BA Senior: Tầm quan trọng của Đầu ra được kiểm soát

Đầu ra của quy trình rà soát và đánh giá không chỉ là tập hợp tài liệu, mà là các điểm kiểm soát (control points) quan trọng trong vòng đời phát triển sản phẩm. Đối với BA Senior, việc quản lý chặt chẽ các đầu ra này là bắt buộc vì nhiều lý do:

1. Ổn định Dự án (Project Stability): Việc thiết lập Baseline (đường cơ sở) cho tài liệu yêu cầu (ví dụ REQ-NF-WHS-0012-v1.0) tạo ra một "phiên bản chân lý" được thống nhất. Mọi thay đổi sau Baseline đều phải tuân theo quy trình kiểm soát thay đổi (Change Control Process), ngăn chặn sự thay đổi tùy tiện làm mất ổn định phạm vi (Scope Creep) và lịch trình dự án.
2. Truy vết & Trách nhiệm (Traceability & Accountability): Biên bản họp (Minutes) và nhật ký thay đổi cung cấp bằng chứng về ai đã quyết định gì, khi nào, và tại sao. Điều này không chỉ giúp giải quyết tranh chấp mà còn là yếu tố then chốt cho việc tuân thủ các quy định nội bộ (corporate governance) và quy định pháp luật (ví dụ: Luật Kế toán Việt Nam, Luật An toàn thực phẩm đối với Nova Foods).
3. Ngăn ngừa Lãng phí (Waste Prevention): Các cổng chất lượng (Quality Gates) cho mỗi đầu ra đảm bảo rằng chỉ có thông tin đã được kiểm định mới đi vào giai đoạn tiếp theo. Điều này giúp tránh lãng phí nguồn lực do phát triển sai, kiểm thử không hiệu quả hoặc triển khai tính năng không phù hợp.
4. Tuân thủ (Compliance): Trong các ngành nghề như thực phẩm (Nova Foods) hoặc các quy định tài chính, các đầu ra đã được phê duyệt trở thành bằng chứng quan trọng cho các cuộc kiểm toán (audit). Việc tài liệu hóa rõ ràng các yêu cầu, quyết định và phê duyệt giúp doanh nghiệp chứng minh sự tuân thủ các chuẩn mực và quy định pháp luật Việt Nam.

Quick Reference

Tham khảo Nhanh: Các Vật phẩm Đầu ra Chính

Bảng dưới đây tóm tắt các vật phẩm đầu ra quan trọng nhất từ quá trình Rà soát và Đánh giá Cuối kỳ, cùng với định danh chuẩn và vai trò chính.

Vật phẩm Đầu ra	Mục đích Chính	Định danh Chuẩn (Ví dụ)	Chủ sở hữu (Chính)	Cổng Chất lượng Chính
Gói Tài liệu Rà soát (Review Pack)	Tập hợp tài liệu cho họp rà soát	RP-NF-WHS-INV-v0.9.0	BA	Mọi tài liệu thành phần mới nhất, đầy đủ, nhất quán.
Biên bản Họp Rà soát (Review Meeting Minutes)	Ghi nhận thảo luận, quyết định, hành động	MM-NF-WHS-INV-20260807-001	BA	Các bên liên quan chính đã rà soát và xác nhận.
Tài liệu Yêu cầu Baseline (Baselined Req. Document)	Phiên bản yêu cầu chính thức cho phát triển	REQ-NF-WHS-0012-v1.0	Product Owner / Business Owner	BO phê duyệt nội dung, QA xác nhận testability.

Cấu trúc đầu ra và ví dụ ma trận truy vết yêu cầu Nova Foods

Mỗi đầu ra (output artifact) trong quy trình phân tích nghiệp vụ tuân thủ cấu trúc chuẩn. Điều này giúp đảm bảo tính nhất quán, dễ truy vết và quản lý trong môi trường dự án ERP như Nova Foods.

Cấu trúc chuẩn của một đầu ra

Trường thông tin	Mô tả	Trạng thái bắt buộc	Lý do
ID Artifact	Mã định danh duy nhất, canonical.	CÓ	Truy vết, nhận diện không nhầm lẫn.
Tên Artifact	Tên mô tả, rõ ràng.	CÓ	Hiểu ngay mục đích, nội dung.
Chủ sở hữu (Owner)	Vai trò chịu trách nhiệm chính duy trì.	CÓ	Xác định người/team chịu trách nhiệm.
Trạng thái (Status)	Tình trạng hiện tại (VD: DRAFT, IN_REVIEW, BASELINED).	CÓ	Quản lý vòng đời artifact.
Phiên bản (Version)	Số phiên bản, tuân thủ Semantic Versioning (SemVer) nếu có.	CÓ	Quản lý thay đổi, tham chiếu chính xác.
Mô tả ngắn	Tóm tắt mục đích, phạm vi chính.	CÓ	Nhanh chóng nắm bắt ngữ cảnh.
Nội dung tối thiểu	Các phần, mục cốt lõi phải có trong artifact.	CÓ	Đảm bảo đầy đủ thông tin cần thiết.
Cổng chất lượng (Quality Gate)	Các tiêu chí để artifact sẵn sàng cho review hoặc giai đoạn tiếp theo.	CÓ	Đảm bảo chất lượng đầu ra.
Nghĩa vụ lịch sử thay đổi	Quy tắc ghi nhận mọi thay đổi (Ngày, Người, Nội dung, Lý do).	CÓ	Kiểm toán, phục hồi, hiểu tiến hóa.
Tham chiếu nguồn	Nguồn gốc thông tin, tài liệu liên quan.	NẾU CÓ	Xác thực thông tin, truy vết ngược.
ID tham chiếu	Các ID của artifact khác có liên quan trực tiếp.	NẾU CÓ	Đảm bảo tính liên kết toàn cục.

Ví dụ minh họa: Ma trận Truy vết Yêu cầu (RTM) cho Nova Foods

Một Ma trận Truy vết Yêu cầu (Requirement Traceability Matrix - RTM) là đầu ra quan trọng, đặc biệt sau các buổi đánh giá như Capstone Review. RTM giúp đảm bảo mọi yêu cầu nghiệp vụ đều được truy vết đến thiết kế, phát triển và kiểm thử.

Thông tin quản trị artifact

Trường thông tin	Giá trị
ID Artifact	NF-ARTF-RTM-WMS-001
Tên Artifact	Ma trận Truy vết Yêu cầu - Phân hệ Quản lý Kho (WMS) Nova Foods
Chủ sở hữu (Owner)	BA Dự án ERP Nova Foods
Trạng thái (Status)	IN_REVIEW
Phiên bản (Version)	v1.1.0
Mô tả ngắn	Tổng hợp các yêu cầu nghiệp vụ WMS, liên kết với ID thiết kế chức năng, test case và các thành phần hệ thống. Cập nhật sau Capstone Review v0.9.0.
Nội dung tối thiểu	Metadata quản trị RTM; Bảng chi tiết truy vết yêu cầu; Mục tóm tắt thay đổi từ v1.0.0.
Cổng chất lượng (Quality Gate)	Mọi yêu cầu có trạng thái "Đã hiện thực" phải có ít nhất một ID thiết kế và một ID test case liên quan. Mọi yêu cầu có trạng thái "DRAFT" hoặc "IN_REVIEW" phải có ghi chú rõ ràng về hành động tiếp theo. Mọi thay đổi từ phiên bản trước phải được ghi nhận trong mục "Lịch sử thay đổi".
Nghĩa vụ lịch sử thay đổi	Mỗi thay đổi ghi: Ngày (Asia/Ho_Chi_Minh), Người thực hiện, ID Yêu cầu bị ảnh hưởng, Loại thay đổi (Thêm/Sửa/Xóa), Lý do thay đổi (tham chiếu Biên bản Capstone Review NF-CAP-REC-001 hoặc các tài liệu liên quan).
Tham chiếu nguồn	Biên bản Capstone Review v0.9.0 (ID: NF-CAP-REC-001); Tài liệu Yêu cầu nghiệp vụ WMS v1.2 (ID: NF-REQ-DOC-WMS-001).
ID tham chiếu	NF-DES-WMS-010 (ví dụ ID thiết kế); NF-TC-WMS-005 (ví dụ ID test case).

Bảng chi tiết truy vết yêu cầu (trích đoạn, dữ liệu mô phỏng)

ID Yêu cầu	Mô tả Yêu cầu	Nguồn	Ưu tiên	Trạng thái	ID Thiết kế	ID Test Case	ID Chức năng	Ghi chú
NF-REQ-001	Hệ thống tự động ghi nhận số lượng hàng nhập từ phiếu giao hàng	Người dùng kho	Cao	Đã hiện thực	NF-DES-WMS-010	NF-TC-WMS-005	WMS.Receive.AutoUpdate	Capstone review: Đạt
NF-REQ-002	Cho phép kiểm tra tồn kho theo lô sản xuất hoặc hạn sử dụng	Quản lý kho	Cao	Đã hiện thực	NF-DES-WMS-011	NF-TC-WMS-006	WMS.Inventory.BatchExp	Capstone review: Đạt
NF-REQ-003	Báo cáo chênh lệch tồn kho định kỳ hàng ngày	Kế toán kho	Trung bình	IN_REVIEW	NF-DES-WMS-012	NF-TC-WMS-007	WMS.Report.InvDiff	Capstone review: Cần xác định chu kỳ báo cáo (NF-BR-ACC-005).
NF-REQ-004	Tích hợp với hệ thống vận chuyển đối tác để cập nhật trạng thái đơn hàng	Vận hành logistics	Cao	DRAFT	NF-DES-WMS-013	N/A	WMS.Integration.Log	Capstone review: Thiếu đặc tả API endpoint (NF-INTEG-002).
NF-REQ-005	Hệ thống gửi cảnh báo tự động khi tồn kho dưới mức an toàn	Quản lý kho	Cao	Đã hiện thực	NF-DES-WMS-014	NF-TC-WMS-008	WMS.Alert.SafetyStock	Capstone review: Đạt

Lịch sử thay đổi (từ v1.0.0 lên v1.1.0, dữ liệu mô phỏng)

Ngày (Asia/Ho_Chi_Minh)	Người thực hiện	ID Yêu cầu bị ảnh hưởng	Loại thay đổi	Lý do thay đổi
2026-08-07 14:30	Nguyen Van A (BA)	NF-REQ-003	Sửa trạng thái	Cập nhật từ DRAFT sang IN_REVIEW sau Capstone Review để làm rõ quy tắc nghiệp vụ.
2026-08-07 14:35	Nguyen Van A (BA)	NF-REQ-004	Cập nhật ghi chú	Bổ sung ghi chú về yêu cầu đặc tả API endpoint dựa trên feedback Capstone Review.

Tiêu chí Sẵn sàng Review cho Artifact Đầu ra

Cổng chất lượng (Quality Gate): Điểm kiểm soát chính thức. Artifact cần đủ hoàn chỉnh, chính xác. Mới chuyển giao hạ nguồn review. Tránh lãng phí thời gian review tài liệu chưa xong. Tăng hiệu quả. Sẵn sàng review không phải phê duyệt. Không phải sẵn sàng sản xuất.

Core

Mục đích Cổng chất lượng: Đảm bảo artifact đủ chất lượng, sẵn sàng review. Giảm rework (làm lại). Tăng hiệu quả quy trình. Bảo toàn truy vết (traceability), nhất quán.

Tiêu chí chung: 1. Hoàn thiện cấu trúc (Structural Completeness): Artifact đủ phần bắt buộc. Không có chỗ trống nội dung cốt lõi ("TBD" hoặc "placeholder"). 2. Tuân thủ định dạng (Format Compliance): Dùng đúng template (biểu mẫu), định dạng (ví dụ: BPMN 2.0, UML 2.5), quy ước đặt tên, các quy tắc trình bày theo tiêu chuẩn dự án. 3. Đồng bộ định danh (ID Synchronization): Định danh chuẩn (Canonical IDs) đã gán. Truy vết chính xác theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md. 4. Tính nhất quán nội tại (Internal Consistency): Không mâu thuẫn logic trong artifact. Ví dụ: yêu cầu không mâu thuẫn yêu cầu khác trong cùng đặc tả. 5. Dễ hiểu (Clarity): Ngôn ngữ rõ, không mơ hồ. Không dùng biệt ngữ không giải thích. Dễ hiểu cho đối tượng review. 6. Đầy đủ bằng chứng (Evidence Sufficiency): Mọi tuyên bố, quyết định quan trọng có bằng chứng, nguồn tham chiếu (phỏng vấn, khảo sát, tài liệu nguồn). 7. Lịch sử thay đổi (Change History): Lịch sử thay đổi ghi đủ, chính xác đến thời điểm hiện tại.

Applied

Artifact: NOVA-PROC-ERP-INV-001.bpmn — Quy trình Quản lý Nhập kho Thành phẩm (Phiên bản cập nhật sau Capstone Review)

• Nova Foods mô phỏng.
• Facts (Thực tế): ERP Nova Foods cần cập nhật quy trình nhập kho thành phẩm. Mục đích tích hợp hệ thống kiểm soát chất lượng (QA) mới.
• Current Behavior (Hành vi hiện tại): Quy trình nhập kho cũ không có bước kiểm tra chất lượng tự động. Sản phẩm lỗi có thể vào kho thành phẩm.
• Underlying Need (Nhu cầu cốt lõi): Giảm chi phí xử lý hàng lỗi. Đảm bảo tuân thủ tiêu chuẩn chất lượng (Luật An toàn thực phẩm 55/2010/QH12) trước nhập kho.
• Options (Các lựa chọn):
  1. Thêm bước kiểm tra thủ công.
  2. Tích hợp hệ thống QA tự động vào quy trình nhập kho.
  3. Kiểm tra chất lượng sau nhập kho, trước xuất.
• Decision Criteria (Tiêu chí quyết định): Chi phí, thời gian triển khai, mức độ tự động hóa, giảm lỗi, tuân thủ pháp luật.
• Decision (Quyết định): Tích hợp hệ thống QA tự động vào quy trình nhập kho.
• Authority (Thẩm quyền): Giám đốc Vận hành Nova Foods (Ông Trần Văn A).
• Artifact (Artifact): Mô hình quy trình nghiệp vụ (BPMN) đã cập nhật, sẵn sàng review.
• Consequence if Wrong (Hậu quả nếu sai): Sản phẩm lỗi không phát hiện. Vi phạm Luật An toàn thực phẩm. Ảnh hưởng uy tín Nova Foods. Chi phí thu hồi sản phẩm cao.

Cổng chất lượng cho NOVA-PROC-ERP-INV-001.bpmn sẵn sàng review:

Tiêu chí	Mô tả Cổng chất lượng	Trạng thái Nova Foods (Mô phỏng)	Nguồn tham chiếu/Bằng chứng
1. Hoàn thiện cấu trúc	Mọi pool, lane, activity, event, gateway định nghĩa rõ. Không flow chưa kết thúc/bắt đầu.	Tất cả element có nhãn. Flow logic rõ ràng.	BPMN diagram hoàn chỉnh.
2. Tuân thủ định dạng	Dùng đúng ký hiệu, quy tắc BPMN 2.0.2.	Tất cả ký hiệu BPMN chuẩn.	OMG BPMN 2.0.2 spec.
3. Đồng bộ định danh	Diagram ID NOVA-PROC-ERP-INV-001 đăng ký. Task/event truy vết yêu cầu (ví dụ: NOVA-REQ-QA-005).	ID truy vết đến /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md
4. Tính nhất quán nội tại	Quy trình logic. Không vòng lặp vô hạn. Không bước mâu thuẫn. Các nhánh (gateway) có điều kiện rõ ràng.	Dòng flow hợp lý. Không deadlock (tắc nghẽn).	BA nội bộ review chéo.
5. Dễ hiểu	Tên hoạt động, chú thích rõ. Dễ hiểu cho Business Owner, QA Lead.	Thuật ngữ chuẩn. Không viết tắt.	Đã review bởi 2 BA khác.
6. Đầy đủ bằng chứng	Quyết định tích hợp QA tự động ghi nhận trong NOVA-DEC-QA-001.	Refer đến Decision Log.	/03-templates/NOVA-DEC-QA-001.md (Mô phỏng)
7. Lịch sử thay đổi	Phiên bản v0.9.1 cập nhật trong phần lịch sử.	History Log cập nhật.	Header của NOVA-PROC-ERP-INV-001.bpmn

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

graph TB
    subgraph ERP["ERP Nova Foods"]
        A([Bắt đầu])
        B[Nhận lô sản phẩm]
        C[Gửi yêu cầu kiểm tra QA tự động]
        F{Kết quả QA đạt?}
        G[Nhập kho thành phẩm]
        H[Chuyển hàng lỗi sang khu vực hàng lỗi]
        I([Kết thúc: nhập kho thành phẩm])
        J([Kết thúc: hàng lỗi đã chuyển])
    end

    subgraph QA["Hệ thống QA tự động"]
        D[Nhận yêu cầu kiểm tra]
        E[Thực hiện kiểm tra chất lượng]
        K[Trả kết quả kiểm tra]
    end

    A --> B --> C
    C -. Yêu cầu kiểm tra .-> D
    D --> E --> K
    K -. Kết quả kiểm tra .-> F
    F -- Đạt --> G --> I
    F -- Không đạt --> H --> J

→ skipped: chi tiết lỗi và luồng xử lý hàng lỗi; add when Nova Foods định nghĩa luồng xử lý chi tiết theo quy định nội bộ và Luật An toàn thực phẩm.

Senior Lens

Giá trị Cổng chất lượng: BA cấp cao biết bỏ qua cổng chất lượng tạo "Technical Debt" (nợ kỹ thuật) sớm. Sửa lỗi thiết kế, yêu cầu giai đoạn muộn (phát triển, kiểm thử) tốn gấp nhiều lần. Artifact sẵn sàng review giúp Developers, Testers, Solution Architects làm việc hiệu quả. Tránh hiểu sai, xây dựng sai. Bằng chứng chuyên nghiệp, cẩn trọng của BA.

Quy tắc ngón tay cái (Rule of Thumb): Không muốn tự review hai lần, đừng gửi người khác review lần đầu. Luôn tự kiểm tra kỹ artifact trước gửi đi. Chi phí vòng review thất bại (phải làm lại) thường cao gấp 3-5 lần thời gian tự kiểm tra ban đầu.

Quick Reference

Artifact	Chủ sở hữu	Tiêu chí Sẵn sàng Review	Ghi chú Nova Foods (Mô phỏng)
Đặc tả Yêu cầu (FRS/SRS)	BA Chính	SMART (Specific, Measurable, Achievable, Relevant, Time-bound). Không mâu thuẫn. Có Acceptance Criteria (AC). Truy vết nguồn.	NOVA-REQ-ERP-001.md phải đủ ID, mô tả, AC.
Mô hình Quy trình (BPMN)	BA / Chuyên gia Quy trình	Tuân thủ BPMN. Logic rõ ràng. Đủ đường dẫn.	NOVA-PROC-ERP-INV-001.bpmn phải đúng cú pháp.
Ma trận Truy vết (Traceability Matrix)	BA Chính	Liên kết đầy đủ. Không đứt gãy. Nhất quán ID.	NOVA-TRC-001.xlsx phải liên kết Req, Test Case, Design.
Mô hình Dữ liệu Logic (LDM)	BA / Kiến trúc sư	Tuân thủ chuẩn UML. Thuộc tính rõ ràng. Quan hệ đúng.	NOVA-LDM-INV-001.puml phải có tất cả entities, attributes.
Tiêu chí Chấp nhận (AC)	BA / Product Owner	Đo lường được. Kiểm thử được. Rõ ràng. Độc lập.	NOVA-AC-ERP-001.md phải có GIVEN/WHEN/THEN.

7. Who consumes those outputs?

Core

Đầu ra BA (Business Analyst outputs) là nguồn thông tin chính. Mỗi vai trò dự án dùng đầu ra này theo cách riêng. Developers (Nhà phát triển) xây code. QA (Kiểm thử viên) xác minh chất lượng. Architects (Kiến trúc sư) thiết kế hệ thống. PM/Product Owners (Quản lý dự án/Chủ sản phẩm) điều hành dự án, quản lý phạm vi. Business Owners (Chủ nghiệp vụ) xác nhận giá trị kinh doanh. Operations (Vận hành) chuẩn bị triển khai. Specialist Owners (Chủ sở hữu chuyên môn, ví dụ: an ninh, pháp lý, kế toán) đảm bảo tuân thủ. Đầu ra BA là cầu nối hiểu biết chung.

Applied

Nova Foods phát triển mô-đun quản lý tồn kho mới. BA đã tạo NOVA-REQ-ERP-005.md (Đặc tả Yêu cầu cho chức năng cập nhật tồn kho theo lô) và NOVA-AC-ERP-005-001.md (Tiêu chí Chấp nhận cho việc ghi nhận số lượng tồn kho đầu kỳ).

• Facts (Sự thật):
  • BA hoàn thành NOVA-REQ-ERP-005.md, NOVA-AC-ERP-005-001.md.
  • Developer cần logic viết code.
  • QA cần điều kiện test chức năng.
• Current Behavior (Hành vi hiện tại): BA gửi email tài liệu đính kèm. Developer hỏi lại chi tiết. QA thiếu test case cho trường hợp biên.
• Underlying Need (Nhu cầu cốt lõi): Các vai trò cần hiểu chính xác nghiệp vụ để hoàn thành việc không cần hỏi lại, tránh hiểu sai.
• Options (Các lựa chọn):
  1. Gửi tài liệu tĩnh (PDF, Word).
  2. Tổ chức họp thuyết trình, hỏi đáp.
  3. Cập nhật tài liệu vào hệ thống quản lý yêu cầu (ví dụ Jira) với liên kết rõ ràng.
• Decision Criteria (Tiêu chí quyết định):
  • Độ rõ ràng, chi tiết tài liệu.
  • Hiệu quả truyền đạt (giảm hiểu nhầm).
  • Khả năng truy vết (traceability) từ yêu cầu đến code, test.
  • Chi phí thời gian BA, nhóm.
• Decision (Quyết định): BA tổ chức workshop ngắn trình bày yêu cầu. Sau đó, upload NOVA-REQ-ERP-005.md và NOVA-AC-ERP-005-001.md vào Confluence/Jira, kèm đường dẫn đến user story tương ứng.
• Authority (Thẩm quyền): Product Owner phê duyệt cách truyền đạt thông tin cho nhóm phát triển.
• Artifact (Tạo tác): NOVA-REQ-ERP-005.md và NOVA-AC-ERP-005-001.md liên kết trong Jira.
• Consequence if Wrong (Hậu quả nếu sai): Developer viết code sai nghiệp vụ. QA bỏ sót test case. Dẫn đến lỗi hệ thống sau triển khai. Ví dụ: Nova Foods tính sai tồn kho lô hàng INV-BATCH-20260807-001. Báo cáo tài chính sai lệch.

Senior Lens

BA cấp cao không chỉ tạo đầu ra, mà còn định hình cách đầu ra đó được tiêu thụ. Hiểu ai cần gì và tại sao rất quan trọng. Developers cần chi tiết kỹ thuật. Business Owners cần tác động nghiệp vụ. BA phải tối ưu hóa Artifact (tạo tác) cho từng đối tượng, tránh "chuyện bếp núc" kỹ thuật cho nghiệp vụ, và ngược lại. Điều này giúp giảm hiểu lầm, tăng hiệu quả nhóm.

Quick Reference

Vai trò (Role)	Đầu ra BA (BA Output)	Cách sử dụng (Consumption)	Mục đích (Purpose)
Developers (Nhà phát triển)	Đặc tả Yêu cầu (FRS/SRS) (NOVA-REQ-ERP-00X.md)	Đọc, hiểu yêu cầu chức năng, phi chức năng. Phân tích logic code.	Viết code, thiết kế chi tiết kỹ thuật, lập trình tính năng đúng nghiệp vụ.
	Tiêu chí Chấp nhận (AC) (NOVA-AC-ERP-00X-00Y.md)	Hiểu kết quả mong đợi của tính năng, logic kiểm thử.	Đảm bảo code đáp ứng yêu cầu, viết unit test.
	Mô hình Dữ liệu Logic (LDM) (NOVA-LDM-INV-00X.puml)	Hiểu cấu trúc dữ liệu, quan hệ bảng.	Thiết kế cơ sở dữ liệu, định nghĩa đối tượng (object) trong code.
	Mô hình Quy trình (BPMN) (NOVA-PROC-ERP-00X.bpmn)	Hiểu luồng nghiệp vụ, thứ tự các bước thực hiện.	Xây dựng luồng công việc, tích hợp các thành phần.
QA (Kiểm thử viên)	Đặc tả Yêu cầu (FRS/SRS) (NOVA-REQ-ERP-00X.md)	Đọc, hiểu để lập kế hoạch kiểm thử tổng thể.	Thiết kế chiến lược kiểm thử, xác định phạm vi test.
	Tiêu chí Chấp nhận (AC) (NOVA-AC-ERP-00X-00Y.md)	Chuyển đổi thành test cases (trường hợp kiểm thử) cụ thể.	Viết test scripts, thực hiện kiểm thử chức năng, xác nhận yêu cầu.
	Ma trận Truy vết (Traceability Matrix) (NOVA-TRC-00X.xlsx)	Đảm bảo mọi yêu cầu đều được kiểm thử.	Xác minh độ bao phủ của test, liên kết test case với yêu cầu.
	Mô hình Quy trình (BPMN) (NOVA-PROC-ERP-00X.bpmn)	Hiểu luồng end-to-end, xác định các kịch bản kiểm thử.	Kiểm thử tích hợp (integration testing), kiểm thử quy trình.
Architect (Kiến trúc sư)	Đặc tả Yêu cầu (FRS/SRS) (NOVA-REQ-ERP-00X.md)	Đánh giá yêu cầu phi chức năng (hiệu năng, bảo mật, khả năng mở rộng).	Thiết kế kiến trúc hệ thống, chọn công nghệ, thành phần.
	Mô hình Dữ liệu Logic (LDM) (NOVA-LDM-INV-00X.puml)	Hiểu cấu trúc dữ liệu lõi, định nghĩa các lược đồ.	Thiết kế kiến trúc dữ liệu, tích hợp hệ thống.
	Mô hình Quy trình (BPMN) (NOVA-PROC-ERP-00X.bpmn)	Đánh giá tác động đến hệ thống hiện có, điểm tích hợp.	Đảm bảo tính khả thi kỹ thuật, tính bền vững của giải pháp.
PM/Product Owner (Quản lý dự án/Chủ sản phẩm)	Đặc tả Yêu cầu (FRS/SRS) (NOVA-REQ-ERP-00X.md)	Xác nhận phạm vi (scope), mức độ ưu tiên (priority).	Quản lý kỳ vọng (expectation), lập kế hoạch phát hành (release plan), quản lý backlog.
	Tiêu chí Chấp nhận (AC) (NOVA-AC-ERP-00X-00Y.md)	Phê duyệt kết quả nghiệp vụ mong muốn.	Xác nhận tính năng đã hoàn thành đúng theo yêu cầu.
	Ma trận Truy vết (Traceability Matrix) (NOVA-TRC-00X.xlsx)	Theo dõi tiến độ, đảm bảo không bỏ sót yêu cầu quan trọng.	Quản lý rủi ro dự án, báo cáo trạng thái.
Business Owner (Chủ nghiệp vụ)	Đặc tả Yêu cầu (FRS/SRS) (NOVA-REQ-ERP-00X.md)	Kiểm tra, xác nhận yêu cầu phản ánh đúng nhu cầu kinh doanh.	Đảm bảo hệ thống giải quyết vấn đề nghiệp vụ, mang lại giá trị.
	Tiêu chí Chấp nhận (AC) (NOVA-AC-ERP-00X-00Y.md)	Xác nhận các điều kiện để coi một tính năng là "hoàn thành". Phê duyệt UAT (User Acceptance Testing - kiểm thử chấp nhận người dùng).	Phê duyệt nghiệm thu UAT.
	Mô hình Quy trình (BPMN) (NOVA-PROC-ERP-00X.bpmn)	Đánh giá tính hiệu quả của quy trình mới/cải tiến.	Đảm bảo quy trình đáp ứng mục tiêu kinh doanh, tối ưu vận hành.
Operations (Vận hành)	Đặc tả Yêu cầu (FRS/SRS) (NOVA-REQ-ERP-00X.md)	Đánh giá tác động đến vận hành, quy trình hỗ trợ.	Lập kế hoạch vận hành, đào tạo, quy trình xử lý sự cố.
	Mô hình Quy trình (BPMN) (NOVA-PROC-ERP-00X.bpmn)	Hiểu luồng công việc để hỗ trợ người dùng cuối, giải quyết vấn đề.	Chuẩn bị tài liệu hướng dẫn sử dụng, SOP (Standard Operating Procedures - quy trình vận hành chuẩn).
Specialist Owners (Chủ sở hữu chuyên môn)	Đặc tả Yêu cầu (FRS/SRS) (NOVA-REQ-ERP-00X.md)	Đánh giá yêu cầu tuân thủ (compliance) pháp lý, an ninh, kế toán. Ví dụ: yêu cầu NOVA-REQ-ERP-001 về định dạng hóa đơn điện tử phải tuân thủ Nghị định 123/2020/NĐ-CP.	Đảm bảo hệ thống tuân thủ quy định chuyên ngành (Legal: Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, Accounting: Luật Kế toán 88/2015/QH13, Security: OWASP ASVS).
	Tiêu chí Chấp nhận (AC) (NOVA-AC-ERP-00X-00Y.md)	Xác nhận điều kiện kiểm thử liên quan đến tuân thủ.	Đảm bảo biện pháp bảo mật, pháp lý, kế toán được kiểm tra đầy đủ.

Quyết định, Bằng chứng, Leo thang cho Bên liên quan

Core

Mỗi bên liên quan xem xét kết quả Capstone review. Quyết định, bằng chứng cần, vấn đề leo thang khác nhau.

Bên liên quan	Quyết định gì?	Bằng chứng cần?	Leo thang khi nào?
Nhà phát triển (Developers)	Phương án code. Chọn thư viện/framework. Cấu hình kỹ thuật.	Đặc tả yêu cầu. Thiết kế kiến trúc. Đặc tả API. Mô hình dữ liệu (DB model).	Yêu cầu không rõ/mâu thuẫn. Giới hạn kỹ thuật không thể. Rủi ro bảo mật mới.
Kiểm thử viên (QA - Quality Assurance)	Kịch bản kiểm thử. Loại kiểm thử. Dữ liệu test.	Tiêu chí chấp nhận (Acceptance Criteria). Use Case. Flow nghiệp vụ. Yêu cầu phi chức năng (NFR).	Tiêu chí chấp nhận không test được. Lỗi nghiêm trọng bỏ sót. Độ bao phủ kiểm thử thiếu.
Kiến trúc sư (Architect)	Điều chỉnh kiến trúc tổng thể. Công nghệ nền tảng. Phương án tích hợp hệ thống.	Yêu cầu phi chức năng (NFR). Đặc tả giao diện (API contracts). Biểu đồ hệ thống (deployment, component). Phân tích hiệu năng, bảo mật.	Thay đổi yêu cầu ảnh hưởng lớn kiến trúc. Rủi ro công nghệ mới. Xung đột kiến trúc với chiến lược.
Quản lý dự án/Chủ sản phẩm (PM/Product Owner)	Ưu tiên tính năng. Phạm vi sản phẩm (scope). Lịch trình. Truyền thông bên liên quan.	Đánh giá lợi ích kinh doanh. Ước tính chi phí/thời gian. Phân tích rủi ro. Phản hồi người dùng.	Phạm vi bị phình to (scope creep). Thiếu nguồn lực. Rủi ro dự án lớn. Mâu thuẫn giữa các bên.
Chủ nghiệp vụ (Business Owner)	Xác nhận nghiệp vụ. Chấp thuận giải pháp. Thay đổi quy trình vận hành.	Mô tả giải pháp. Quy trình nghiệp vụ mới. Báo cáo phân tích tác động. ROI (lợi tức đầu tư).	Giải pháp không đáp ứng mục tiêu nghiệp vụ. Rủi ro vận hành cao. Ảnh hưởng lớn đến khách hàng/doanh thu.
Vận hành (Operations)	Kế hoạch triển khai. Giám sát hệ thống. Quy trình hỗ trợ. SLA (thỏa thuận mức dịch vụ).	Tài liệu vận hành. Hướng dẫn sử dụng. Yêu cầu phi chức năng (khả năng vận hành, bảo trì). Kế hoạch dự phòng.	Khả năng vận hành không đảm bảo. Rủi ro downtime. Thiếu tài liệu vận hành cần thiết.
Chủ sở hữu chuyên môn (Specialist Owners)	Xác nhận tuân thủ pháp lý/quy định. Phê duyệt bảo mật. Xác nhận chuẩn mực kế toán.	Phân tích tác động pháp lý/quy định. Đánh giá bảo mật. Báo cáo kiểm toán nội bộ.	Không tuân thủ quy định. Lỗ hổng bảo mật nghiêm trọng. Sai lệch chuẩn mực tài chính.

Applied

Nova Foods (mô phỏng): Chủ nghiệp vụ xem xét báo cáo Capstone review cho quản lý kho lạnh mới. * Facts: Nova Foods ra mắt "Kem Tươi Cao Cấp Nova" (NF-PRF-CRM-001). Cần kho lạnh chuyên dụng (-18°C), quy trình nhập xuất nghiêm ngặt. Hệ thống ERP hiện tại không theo dõi nhiệt độ, lô sản xuất phụ, hạn sử dụng chi tiết vị trí kho. * Current Behavior: Thủ công ghi chép nhiệt độ. Excel theo dõi lô sản phẩm phụ. Rủi ro thu hồi sản phẩm (recall) cao do thiếu dữ liệu truy xuất. * Underlying Need: Đảm bảo tuân thủ Luật An toàn thực phẩm (Luật 55/2010/QH12). Giảm rủi ro chất lượng. Tăng hiệu quả quản lý kho lạnh. Truy xuất nguồn gốc "từ trang trại đến bàn ăn". * Options: 1. Nâng cấp module kho ERP hiện tại (phát triển tùy chỉnh). 2. Tích hợp Hệ thống WMS (Warehouse Management System) chuyên biệt với ERP. 3. Giữ nguyên thủ công (rủi ro cao, không mở rộng). * Decision Criteria: Chi phí, thời gian triển khai, mức độ tuân thủ, rủi ro vận hành, khả năng tích hợp. * Decision: Chọn Option 1. Nâng cấp module kho ERP để bổ sung trường dữ liệu nhiệt độ, lô phụ, vị trí chính xác mỗi item. (Cân bằng chi phí, tuân thủ ban đầu). * Authority: Bà Nguyễn Thị Minh, Trưởng phòng Quản lý Chuỗi cung ứng, Nova Foods (Chủ nghiệp vụ). * Artifact: Báo cáo Capstone đánh giá giải pháp (CAP-REP-INV-001). Tài liệu Đặc tả Yêu cầu Chi tiết (REQ-INV-002) cập nhật. Bản phân tích tác động (IMP-INV-003). * Consequence if Wrong: Sản phẩm không đạt chuẩn an toàn thực phẩm. Bị thu hồi (recall). Mất uy tín thương hiệu. Phạt hành chính (Luật An toàn thực phẩm).

Senior Lens

Hiểu nhầm thường gặp: BA cung cấp tài liệu là đủ. Thay vào đó, tài liệu BA khởi tạo thảo luận, không kết thúc chúng. * Nhà phát triển: "Tài liệu này không nói rõ xử lý lỗi X (edge case) như thế nào?" * Làm rõ: "Điều kiện lỗi X phát sinh khi nào? Dữ liệu đầu vào nào? Kết quả mong muốn khi lỗi? Có quy tắc nghiệp vụ đặc biệt cho X không?" * Kiểm thử viên: "Tiêu chí chấp nhận Y có bao gồm trường hợp dữ liệu âm hoặc trống không?" * Làm rõ: "Với nghiệp vụ này, dữ liệu âm/trống có hợp lệ không? Nếu không, hệ thống phản ứng gì? Nếu có, kết quả mong đợi ra sao?" * Chủ nghiệp vụ: "Thay đổi quy trình A ảnh hưởng thế nào đến phòng ban B?" * Làm rõ: "Mức độ ảnh hưởng là gì (con người, thời gian, chi phí)? Có cần đào tạo lại không? Cần họp với phòng ban B để làm rõ tác động và kế hoạch thay đổi."

Quy trình Leo thang Quyết định:

Quick Reference

Trigger Leo thang: * Phạm vi: Yêu cầu mới, không nằm trong thỏa thuận ban đầu. * Chi phí/Thời gian: Vượt quá ước tính ban đầu đáng kể. * Rủi ro: Rủi ro kỹ thuật, nghiệp vụ, pháp lý mới, ảnh hưởng lớn. * Mâu thuẫn: Xung đột quyết định giữa các bên liên quan. * Tuân thủ: Không đáp ứng quy định pháp lý, chuẩn mực ngành.

Hiểu lầm chuyển giao và câu hỏi làm rõ

### Core Mỗi đầu ra (output) từ phân tích nghiệp vụ, như tài liệu yêu cầu (requirements documents) hay mô hình, là cơ sở để các bên liên quan (stakeholders) thực hiện việc. "Chuyển giao" (handoff) các đầu ra này dễ sinh "hiểu lầm" (misunderstandings). Lý do: mỗi vai trò có góc nhìn, chuyên môn, ưu tiên khác nhau. Hiểu lầm làm chậm tiến độ, tăng chi phí sửa lỗi, giảm chất lượng sản phẩm.

### Applied Để giảm rủi ro, cần nhận diện hiểu lầm phổ biến, đặt câu hỏi làm rõ chính xác. Bảng dưới tổng hợp tình huống thường gặp trong Nova Foods (mô phỏng, dữ liệu tổng hợp):

Vai trò (Role)	Hiểu lầm phổ biến (Common Misunderstanding)	Câu hỏi làm rõ chính xác (Exact Clarification Question)	Căn nguyên vấn đề (Root Cause)
Lập trình viên (Developers)	Yêu cầu chức năng chưa đủ chi tiết để viết mã. Ví dụ: "Hệ thống cần tính chiết khấu cho khách hàng VIP."	"Thuật toán tính chiết khấu loại 'VIP_GOLD' cụ thể là gì? Áp dụng trên giá niêm yết hay giá sau khuyến mãi khác? Trường hợp lỗi (exception) khi không có dữ liệu VIP thì xử lý thế nào?"	Thiếu quy tắc nghiệp vụ tường minh (explicit business rules) hoặc kịch bản ngoại lệ (exception scenarios).
Kiểm thử viên (QA - Quality Assurance)	Tiêu chí chấp nhận (acceptance criteria) không kiểm thử được hoặc không bao phủ đủ trường hợp. Ví dụ: "Hệ thống phải thân thiện với người dùng."	"Làm sao đo lường 'thân thiện'? Có tiêu chí cụ thể nào (ví dụ: số click tối đa cho tác vụ, thời gian phản hồi dưới X giây) để kiểm tra không? Với 'Đặt hàng', trường hợp giỏ hàng trống hoặc hết hàng thì kết quả mong đợi gì để kiểm thử?"	Tiêu chí quá chung chung, thiếu định lượng (quantifiable metrics) hoặc thiếu kịch bản kiểm thử tiêu cực/cạnh biên (negative/edge cases).
Kiến trúc sư (Architect)	Yêu cầu phi chức năng (non-functional requirements - NFRs) không rõ ràng, dẫn đến thiết kế quá mức hoặc không đủ. Ví dụ: "Hệ thống Nova Foods cần hoạt động nhanh."	"Nhanh nghĩa là gì đối với 'Tìm kiếm sản phẩm'? Thời gian phản hồi tối đa 95% yêu cầu là bao nhiêu mili giây? Số người dùng đồng thời tối đa là bao nhiêu? Khả năng mở rộng (scalability), tính sẵn sàng (availability) là bao nhiêu phần trăm (ví dụ: 99.9%) trong một năm?"	Thiếu định nghĩa cụ thể về hiệu năng (performance), khả năng chịu tải (load), tính sẵn sàng hoặc bảo mật.
Quản lý Dự án / Chủ sản phẩm (PM/Product Owner)	Phạm vi (scope) công việc mơ hồ hoặc thay đổi liên tục, ảnh hưởng kế hoạch, cam kết. Ví dụ: "Cần thêm báo cáo doanh thu theo khu vực."	"Báo cáo này cần hiển thị thông tin gì? Dữ liệu lấy từ đâu? Độ chi tiết dữ liệu (theo ngày, tuần, tháng)? Ai dùng báo cáo này để ra quyết định gì?"	Thiếu thống nhất về mục tiêu (objective) và giá trị nghiệp vụ (business value) của từng tính năng bổ sung.
Chủ nghiệp vụ (Business Owner)	Giải pháp đề xuất không giải quyết đúng "nhu cầu gốc" (underlying need) hoặc không phù hợp quy trình hiện tại. Ví dụ: "Hệ thống mới vẫn bắt nhân viên nhập liệu thủ công quá nhiều."	"Phần nhập liệu nào cụ thể tốn thời gian? Quy trình hiện tại tự động hóa được phần nào? Mục tiêu chính khi muốn giảm nhập liệu là gì (ví dụ: giảm lỗi, tăng tốc độ, giảm chi phí nhân sự)?"	Không xác định rõ vấn đề cốt lõi (root problem) hoặc quy trình làm việc thực tế không phân tích đầy đủ.
Vận hành (Operations)	Thiếu thông tin về cách triển khai, giám sát hoặc xử lý sự cố. Ví dụ: "Hệ thống mới triển khai vào cuối tuần."	"Quy trình triển khai (deployment process) có yêu cầu gì đặc biệt? Cần chuẩn bị công cụ giám sát (monitoring tools) nào? Danh sách loại lỗi (error codes) và cách khắc phục ban đầu (initial troubleshooting steps) cho hệ thống này là gì?"	Thiếu yêu cầu về khả năng vận hành (operability), bảo trì (maintainability) hoặc thông tin hỗ trợ kỹ thuật.
Chủ sở hữu chuyên môn (Specialist Owners, ví dụ: Bảo mật, Pháp lý)	Yêu cầu tuân thủ (compliance) không tích hợp hoặc diễn giải sai. Ví dụ: "Dữ liệu khách hàng phải bảo mật."	"Theo Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, dữ liệu khách hàng phân loại mức độ nhạy cảm nào? Cần mã hóa (encryption) ở đâu (lúc lưu trữ, lúc truyền tải)? Ai có quyền truy cập (access control) vào dữ liệu này, quy trình cấp/thu hồi quyền ra sao?"	Thiếu tham chiếu trực tiếp đến quy định pháp lý, tiêu chuẩn ngành (industry standards) hoặc chính sách bảo mật cụ thể.

### Senior Lens Hiểu lầm chuyển giao (handoff misunderstandings) thường phát sinh từ giả định ngầm định (implicit assumptions), giao tiếp không đầy đủ. BA cấp cao phải chủ động dự đoán các điểm mờ này, đưa ra câu hỏi làm rõ (clarification questions) cụ thể, kiểm chứng được (verifiable). Luôn yêu cầu "bằng chứng" (evidence) hoặc "ví dụ" (examples) để kiểm tra hiểu biết. Nếu hiểu lầm dẫn đến rủi ro lớn (ví dụ: vi phạm pháp luật, mất dữ liệu, ảnh hưởng nghiêm trọng doanh thu Nova Foods), cần "leo thang" (escalate) ngay lập tức đến các bên có thẩm quyền để ra quyết định. Ghi lại quyết định và lý do vào artifact quản trị (ví dụ: /01-curriculum/TRACEABILITY_ID_REGISTRY.md).

### Quick Reference Sơ đồ dòng chảy giao tiếp và điểm làm rõ quan trọng trong chuyển giao:

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

sequenceDiagram
    autonumber
    participant BA as BA (Tác giả Yêu cầu)
    participant Stakeholders as Các Bên liên quan
    participant Authority as Bên có thẩm quyền

    BA->>Stakeholders: Chuyển giao Output BA
    Note right of Stakeholders: Mỗi vai trò có góc nhìn riêng.

    alt Hiểu lầm phát sinh
        Stakeholders-->>BA: Nêu điểm chưa rõ
        BA->>BA: Phân tích căn nguyên và giả định ngầm
        BA->>Stakeholders: Hỏi giả định, tiêu chí, ngoại lệ
        BA->>Stakeholders: Yêu cầu bằng chứng hoặc ví dụ
        Stakeholders-->>BA: Cung cấp chi tiết, bằng chứng hoặc ví dụ
        BA->>BA: Đánh giá mức rủi ro

        alt Rủi ro cao: pháp luật, mất dữ liệu, doanh thu
            BA->>Authority: Leo thang vấn đề và rủi ro
            Authority-->>BA: Quyết định
            BA->>BA: Ghi quyết định, lý do, liên kết truy vết vào /01-curriculum/TRACEABILITY_ID_REGISTRY.md
            BA->>BA: Cập nhật Output BA, làm rõ giả định
            BA->>Stakeholders: Thông báo quyết định và xác nhận cách hiểu
            Stakeholders-->>BA: Xác nhận đủ rõ để thực hiện công việc
        else Rủi ro không cao
            BA->>BA: Ghi nội dung làm rõ, lý do, liên kết truy vết vào /01-curriculum/TRACEABILITY_ID_REGISTRY.md
            BA->>BA: Cập nhật Output BA, làm rõ giả định
            BA->>Stakeholders: Xác nhận làm rõ
            Stakeholders-->>BA: Xác nhận đủ rõ để thực hiện công việc
        end
    else Handoff thành công
        Stakeholders-->>BA: Xác nhận đủ rõ để thực hiện công việc
    end

8. Detailed Worked Example

Core

Mục này trình bày ví dụ chi tiết về quá trình xem xét và đánh giá của Business Analyst (BA) tại Nova Foods mô phỏng. Ví dụ cho thấy BA xác định vấn đề, phân tích bằng chứng, làm rõ nhu cầu, so sánh phương án, ghi nhận thẩm quyền, tạo artifact và đánh giá hậu quả khi quyết định sai.

Mọi dữ liệu Nova Foods trong mục này là dữ liệu mô phỏng. Artifact có trạng thái IN_REVIEW; chưa artifact nào là BASELINED hoặc thể hiện phê duyệt.

Applied

Tình huống tại Nova Foods: Quản lý tồn kho nguyên vật liệu

Facts (Sự kiện thực tế):

Nova Foods (mô phỏng) là công ty sản xuất thực phẩm. Hệ thống ERP hiện tại là NovaERP-Legacy, đã triển khai từ 2018. Module Quản lý Tồn kho (NovaERP-Legacy.INV_MOD) theo dõi nguyên vật liệu (Raw Materials - RM) và thành phẩm.

Loại vật liệu	Mã ID (Synthetic)	Tên vật liệu	Đơn vị
Nguyên vật liệu	NF_RM_FLOUR001	Bột mì đa dụng	KG
Nguyên vật liệu	NF_RM_SUGAR001	Đường tinh luyện	KG
Nguyên vật liệu	NF_RM_OIL001	Dầu ăn thực vật	Lít

Đơn đặt hàng nhà cung cấp (Purchase Order - PO) được tạo qua NovaERP-Legacy.PO_MOD. Khi hàng về kho, thủ kho nhập số lượng thực nhận. Quy trình sản xuất tiêu thụ nguyên vật liệu theo lệnh sản xuất (Production Order) và ghi nhận vào NovaERP-Legacy.INV_MOD sau khi mẻ sản xuất hoàn tất.

Ngày 2026-07-28, phòng Kế toán phát hiện chênh lệch lớn giữa báo cáo tồn kho nguyên vật liệu từ NovaERP-Legacy.INV_MOD và kiểm kê thực tế. Giá trị tồn kho âm xuất hiện thường xuyên cho NF_RM_FLOUR001 và NF_RM_SUGAR001.

Current Behavior (Hành vi hiện tại của hệ thống/quy trình):

1. Nhập kho không khớp: Nhà cung cấp giao thiếu, ví dụ thiếu 100KG bột mì. Thủ kho đôi khi vẫn ghi số lượng trên phiếu đặt hàng vào NovaERP-Legacy.INV_MOD để hoàn tất thủ tục, rồi dự định điều chỉnh sau. Hành động này tạo sai lệch dữ liệu đầu vào.
2. Xuất kho không kiểm soát đủ: Khi sản xuất cần nguyên vật liệu, nhân viên sản xuất yêu cầu xuất kho dù hệ thống báo tồn thấp hoặc bằng 0. Thủ kho đôi khi ghi nhận xuất vượt số lượng tồn hệ thống. Quy tắc hiện tại của NovaERP-Legacy.INV_MOD cho phép QUANTITY_ON_HAND < 0 khi ITEM_TYPE = 'RM'; hệ thống không chặn giao dịch.
3. Điều chỉnh thủ công và chậm: Phòng Kế toán phát hiện và điều chỉnh tồn âm theo tuần hoặc tháng bằng đối chiếu sổ sách, bản tính Excel và bút toán điều chỉnh (Journal Entries). Quy trình tốn thời gian và dễ sai.
4. Tác động lập kế hoạch: Dữ liệu tồn kho không chính xác buộc bộ phận kế hoạch sản xuất và mua hàng kiểm tra kho thực tế thay vì dùng dữ liệu hệ thống. Hậu quả là chậm chuỗi cung ứng và đặt hàng không tối ưu.

Ví dụ Chi tiết (Detailed Worked Example)

Applied

Sự kiện (Facts)

Nova Foods sản xuất và kinh doanh thực phẩm đông lạnh. Mỗi lô sản phẩm có hạn sử dụng (HSD) riêng.

Ví dụ dữ liệu mô phỏng:

Đối tượng	Giá trị
Mã sản phẩm	NF-SP001
Tên sản phẩm	Bò viên đông lạnh
Lô sản xuất	LSP-20260715-001
HSD	2027-01-15

Quản lý bán hàng cũng xác định nhu cầu tự động hóa quy tắc chiết khấu.

Đối tượng	ID	Giá trị
Loại khách hàng	CUST-TYPE-001	Khách hàng Bán lẻ (Retail)
Loại khách hàng	CUST-TYPE-002	Khách hàng Bán buôn (Wholesale)
Loại khách hàng	CUST-TYPE-003	Khách hàng thân thiết (Loyal Customer)
Nhóm sản phẩm	PROD-GROUP-001	Thực phẩm đóng hộp (Canned Foods)
Nhóm sản phẩm	PROD-GROUP-002	Thực phẩm đông lạnh (Frozen Foods)
Quy tắc chiết khấu	RULE-DISCOUNT-LOYAL-001	Khách hàng CUST-TYPE-003 được chiết khấu 5% khi mua PROD-GROUP-001

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

Kiểm soát HSD:

Nhân viên kho đọc HSD trên bao bì bằng mắt thường khi xuất hàng. Quy trình không có kiểm tra tự động và không có cảnh báo hệ thống khi lô gần đến HSD. Nhân viên có thể xuất nhầm lô có HSD sắp hết hoặc đã hết hạn.

Áp dụng chiết khấu:

Khi nhân viên kinh doanh tạo Sales Order trong ERP, nhân viên phải:

1. Kiểm tra thủ công loại khách hàng.
2. Kiểm tra sản phẩm có thuộc PROD-GROUP-001 không.
3. Tự tính và nhập chiết khấu 5% cho từng dòng đủ điều kiện.

Hậu quả là sai sót, mất thời gian và áp dụng RULE-DISCOUNT-LOYAL-001 không nhất quán.

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

Nova Foods cần kiểm soát tự động dữ liệu quyết định xuất kho và tính chiết khấu.

Nhu cầu	Hành động hệ thống cần có	Kết quả cần đạt
Kiểm soát HSD	Kiểm tra HSD lô hàng trước khi cho phép xuất kho	Không xuất lô không đủ HSD theo quy tắc nghiệp vụ được ghi nhận
Áp dụng chiết khấu	Tự động đánh giá khách hàng, nhóm sản phẩm và RULE-DISCOUNT-LOYAL-001	Áp dụng chiết khấu 5% nhất quán cho giao dịch đủ điều kiện
Truy vết	Lưu yêu cầu, đặc tả, kiểm thử và quyết định	BA, QA, nghiệp vụ và CNTT có bằng chứng review
Kiểm soát rủi ro	Chặn hoặc thông báo khi giao dịch không đáp ứng quy tắc	Giảm sai sót thủ công và giảm xử lý điều chỉnh sau giao dịch

Nhu cầu kiểm soát HSD có liên quan mục tiêu an toàn thực phẩm. Luật An toàn thực phẩm, Luật số 55/2010/QH12, được ghi nhận là nguồn tham khảo; artifact không diễn giải hoặc khẳng định điều khoản cụ thể của luật.

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

1. Thủ công tăng cường
2. Hành động: Tăng đào tạo nhân viên kho và kinh doanh; áp dụng kiểm tra kép cho xuất kho và đơn hàng.
3. Lợi ích: Chi phí thấp, triển khai nhanh.

4. Trade-off: Độ chính xác vẫn phụ thuộc con người; khó mở rộng; không loại bỏ nhập liệu và kiểm tra thủ công.

5. Excel hoặc phần mềm đơn giản

6. Hành động: Dùng bảng tính Excel hoặc phần mềm quản lý kho đơn giản để theo dõi HSD và cảnh báo; theo dõi quy tắc chiết khấu ngoài ERP.
7. Lợi ích: Cải thiện khả năng theo dõi so với hoàn toàn thủ công; chi phí vừa phải.

8. Trade-off: Vẫn cần nhập liệu thủ công; dữ liệu có thể lệch ERP; khó tích hợp; kiểm soát giao dịch không nhất quán.

9. Tích hợp module WMS và cấu hình ERP hiện có

10. Hành động: Tích hợp hoặc nâng cấp module Quản lý Kho (Warehouse Management System - WMS) để kiểm tra HSD trước xuất kho; dùng module quản lý giá/chiết khấu ERP để cấu hình RULE-DISCOUNT-LOYAL-001.
11. Lợi ích: Tự động hóa cao; kiểm tra trước giao dịch; khả năng mở rộng; liên kết tốt với ERP.

12. Trade-off: Chi phí và thời gian triển khai cao hơn; cần cấu hình, kiểm thử và xác thực tính khả thi kỹ thuật.

13. Phát triển tùy chỉnh

14. Hành động: Viết mã trong hoặc ngoài ERP để xử lý kiểm soát HSD và chiết khấu.
15. Lợi ích: Linh hoạt cao cho logic phức tạp.
16. Trade-off: Chi phí cao; bảo trì khó; tạo gánh nặng kỹ thuật; không chọn khi cấu hình chuẩn ERP đáp ứng nhu cầu.

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

Tiêu chí ID	Tên tiêu chí	Mô tả	Mức độ ưu tiên
DC-ACC-001	Độ chính xác (Accuracy)	Quy tắc HSD và chiết khấu phải được áp dụng đúng theo đặc tả.	Cao nhất
DC-AUT-001	Mức độ tự động hóa (Automation)	Giảm can thiệp thủ công trong giao dịch.	Cao
DC-COST-001	Chi phí (Cost)	Chi phí triển khai và bảo trì.	Trung bình
DC-TIM-001	Thời gian triển khai (Time)	Thời gian từ bắt đầu đến vận hành ổn định.	Trung bình
DC-SCL-001	Khả năng mở rộng (Scalability)	Hỗ trợ thêm lô hàng, kho, quy tắc, loại khách hàng và nhóm sản phẩm.	Cao
DC-AUD-001	Khả năng kiểm toán (Auditability)	Truy vết lịch sử kiểm tra HSD và áp dụng chiết khấu.	Cao
DC-CMP-001	Tuân thủ (Compliance)	Hỗ trợ kiểm soát nghiệp vụ liên quan an toàn thực phẩm và kiểm soát nội bộ.	Cao

Quyết định (Decision)

Khuyến nghị BA: BA khuyến nghị lựa chọn 3.

• Module WMS phải kiểm tra HSD trước khi cho phép xuất kho.
• Module giá/chiết khấu ERP phải cấu hình RULE-DISCOUNT-LOYAL-001.
• Không phát triển tùy chỉnh nếu cấu hình chuẩn ERP đáp ứng yêu cầu đã đặc tả.
• Kiểm thử phải chứng minh giao dịch không đủ điều kiện bị chặn hoặc xử lý theo thông báo đã đặc tả.

Khuyến nghị cân bằng DC-ACC-001, DC-AUT-001, DC-SCL-001, DC-AUD-001, DC-CMP-001 với chi phí và thời gian triển khai. Chi phí ban đầu cao hơn phương án thủ công, nhưng giảm rủi ro dữ liệu và giảm phụ thuộc vào thao tác con người.

Quyết định chưa được đánh dấu phê duyệt. Trạng thái review của khuyến nghị và artifact liên quan là IN_REVIEW.

Thẩm quyền (Authority)

Vai trò	ID	Hành động và phạm vi thẩm quyền cần xác nhận trong phiên review
Giám đốc Vận hành (COO)	Không có ID được cung cấp	Xác nhận chủ sở hữu nghiệp vụ và quyết định chấp nhận hoặc từ chối trade-off vận hành.
Trưởng phòng Kho	Không có ID được cung cấp	Xác nhận quy trình xuất kho, dữ liệu lô và tác động vận hành WMS.
Trưởng phòng Kinh doanh	BO-SALES-001	Xác nhận tính đúng đắn chính sách RULE-DISCOUNT-LOYAL-001.
Giám đốc CNTT	IT-DIR-001	Xác nhận khả thi kỹ thuật, kiến trúc và nguồn lực CNTT.
Tư vấn ERP Chức năng	ERP-FC-001	Xác nhận tính khả thi của cấu hình chuẩn ERP.
Trưởng phòng BA	Không có ID được cung cấp	Kiểm tra tính đầy đủ yêu cầu, truy vết và hồ sơ review.
Giám đốc Dự án ERP	Không có ID được cung cấp	Điều phối quyết định dự án, rủi ro và bàn giao.

Không suy diễn thẩm quyền từ tên vai trò, ID hay trạng thái artifact. Biên bản review phải ghi người ra quyết định, phạm vi thẩm quyền được xác nhận, artifact đã xem xét, trade-off và hậu quả nếu quyết định sai.

Artifact

Artifact ghi nhận yêu cầu, khuyến nghị, bằng chứng kiểm thử và trạng thái review. Trạng thái chung: IN_REVIEW.

Artifact	Mục đích	Chủ thể dùng	Nội dung bắt buộc
NF-BRD-WH-001 v1.0.0	Business Requirement Document - BRD	BA, chủ sở hữu nghiệp vụ, nhóm triển khai	Đối tượng là lô hàng; hành động cần kiểm soát là xuất kho; kết quả là không xuất lô không đủ HSD theo quy tắc đã ghi nhận.
NF-FS-WMS-EXPIRY-001 v1.0.0	Functional Specification - FS	BA, nhóm WMS/ERP, QA	Liên kết yêu cầu nghiệp vụ với hành vi kiểm tra HSD, điều kiện chặn, thông báo lỗi và cập nhật tồn kho ERP.
NF-TC-WMS-EXPIRY-001 v1.0.0	Test Case	QA hoặc người kiểm thử	Dữ liệu lô, điều kiện HSD, hành động xuất kho, kết quả mong đợi, kết quả thực tế và bằng chứng kiểm thử.
FS-ERP-PRICING-V1.0.0.md	Functional Specification - ERP Pricing	BA, tư vấn ERP chức năng, QA	Cấu hình module giá/chiết khấu ERP để tự động áp dụng RULE-DISCOUNT-LOYAL-001.
DOC-FS-PRICING-001	ID tài liệu FS chiết khấu	BA, tư vấn ERP chức năng, QA	Quy tắc, điều kiện khách hàng, điều kiện nhóm sản phẩm, tỷ lệ chiết khấu, hành vi hệ thống và truy vết kiểm thử.
Ma trận truy vết	Liên kết BRD, FS và Test Case	BA, QA, người review	Phát hiện yêu cầu chưa có đặc tả, đặc tả chưa có kiểm thử, hoặc kiểm thử không chứng minh yêu cầu.
Biên bản quyết định capstone	Ghi nhận review	Người có thẩm quyền, BA, quản lý dự án	Người quyết định, thẩm quyền đã xác nhận, artifact đã xem xét, trade-off, trạng thái IN_REVIEW, hậu quả nếu sai.

Ví dụ cấu hình cần đặc tả trong DOC-FS-PRICING-001:

ID Quy tắc	Mô tả	Loại khách hàng	Nhóm sản phẩm	Tỷ lệ chiết khấu	Trạng thái review	Nguồn gốc chính sách
BR-PRC-001	Chiết khấu 5% cho khách hàng thân thiết	CUST-TYPE-003	PROD-GROUP-001	5%	IN_REVIEW	RULE-DISCOUNT-LOYAL-001

Luồng kiểm tra HSD trong WMS:

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

flowchart TB
    AR["NF-BRD-WH-001 v1.0.0<br/>NF-FS-WMS-EXPIRY-001 v1.0.0<br/>Quy tắc HSD: IN_REVIEW"]

    subgraph USER["Nhân viên kho"]
        A["Gửi yêu cầu xuất lô hàng"]
        N["Nhận thông báo lỗi HSD"]
        R["Kiểm tra và chọn lại lô hàng"]
    end

    subgraph WMS["WMS"]
        B{"Lô hàng còn đủ HSD<br/>theo quy tắc trong BRD/FS?"}
        D["Chặn xuất hàng"]
        F["Gửi thông báo lỗi HSD"]
        C["Cho phép xuất hàng"]
        G["Gửi yêu cầu cập nhật tồn kho"]
    end

    subgraph ERP["ERP"]
        E["Cập nhật tồn kho"]
    end

    Z["Xuất kho hoàn tất"]

    A --> B
    B -->|Không| D
    D --> F
    F --> N
    N --> R
    R -->|Gửi lại yêu cầu| A
    B -->|Có| C
    C --> G
    G --> E
    E --> Z
    AR -.->|Căn cứ đang IN_REVIEW| B

Hậu quả khi thiếu liên kết giữa artifact: nhóm triển khai có thể cho phép xuất lô không đủ HSD; QA không có bằng chứng xác thực hành vi; người có thẩm quyền không đủ cơ sở chấp nhận rủi ro hoặc yêu cầu sửa.

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

Nếu Nova Foods chọn phương án không đáp ứng nhu cầu, hoặc cấu hình và kiểm thử không chứng minh yêu cầu:

• Nhân viên có thể tiếp tục xuất nhầm lô có HSD không đáp ứng quy tắc.
• Khách hàng có thể nhận sản phẩm không phù hợp; Nova Foods đối mặt khiếu nại, xử lý sự cố và tổn hại lòng tin.
• Dữ liệu tồn kho và trạng thái lô có thể không phản ánh đúng giao dịch thực tế.
• Chính sách RULE-DISCOUNT-LOYAL-001 có thể bị áp dụng sai, làm phát sinh sai lệch doanh thu, quyền lợi khách hàng hoặc đối soát.
• Phòng Kế toán, Kho, Kinh doanh và CNTT phải tăng xử lý thủ công, đối chiếu và điều chỉnh.
• Người có thẩm quyền không có đủ bằng chứng để chấp nhận rủi ro nếu BRD, FS, Test Case và ma trận truy vết không liên kết đầy đủ.

Core

Chuỗi phân tích Facts → Current Behavior → Underlying Need → Options → Decision Criteria → Decision → Authority → Artifact → Consequence if Wrong giúp BA:

• Tách bằng chứng khỏi giả định và khuyến nghị.
• Xác định nhu cầu gốc thay vì chỉ xử lý triệu chứng.
• Ghi rõ đối tượng, hành động, kết quả, thẩm quyền và trade-off.
• Tạo truy vết từ nhu cầu nghiệp vụ tới đặc tả và kiểm thử.
• Giữ quyết định ở trạng thái IN_REVIEW khi chưa có bằng chứng hoặc thẩm quyền xác nhận đầy đủ.

Senior Lens

BA cấp cao kiểm tra các điểm sau:

• Vấn đề HSD là kiểm soát xuất kho; không chỉ là đào tạo nhân viên đọc nhãn kỹ hơn.
• Vấn đề chiết khấu là áp dụng quy tắc nhất quán và truy vết được; không chỉ là giảm thời gian nhập đơn.
• Cấu hình ERP chuẩn được ưu tiên trước phát triển tùy chỉnh khi tính năng chuẩn đáp ứng yêu cầu.
• Cảnh báo không đủ nếu hệ thống vẫn cho phép giao dịch sai; FS phải nêu rõ điều kiện chặn, ngoại lệ được phép và bằng chứng kiểm thử.
• Thẩm quyền phải được xác nhận trong phiên review; BA không tự gán quyền phê duyệt cho vai trò.
• Trạng thái IN_REVIEW không phải bằng chứng phê duyệt, không thay thế kiểm thử và không cho phép gọi artifact là BASELINED.

Quick Reference

Bước	Actor	Action	Object	Outcome
Facts	BA	Thu thập và phân loại bằng chứng	Dữ liệu lô, HSD, tồn kho, quy tắc chiết khấu	Bối cảnh kiểm chứng được
Current Behavior	BA và người vận hành	Mô tả giao dịch hiện tại	Xuất kho, nhập liệu HSD, nhập chiết khấu	Điểm lỗi và thao tác thủ công rõ ràng
Underlying Need	BA và Business Owner	Xác định mục tiêu nghiệp vụ	Kiểm soát HSD, chiết khấu, truy vết	Nhu cầu không lẫn với giải pháp
Options	BA	So sánh phương án	Thủ công, Excel, cấu hình ERP/WMS, tùy chỉnh	Trade-off minh bạch
Decision Criteria	BA và người review	Đánh giá phương án	Accuracy, Automation, Cost, Time, Scalability, Auditability, Compliance	Cơ sở khuyến nghị
Decision	BA	Ghi khuyến nghị	Lựa chọn 3	Khuyến nghị IN_REVIEW
Authority	Người có thẩm quyền	Xác nhận hoặc từ chối quyết định	Phạm vi nghiệp vụ, kỹ thuật, nguồn lực	Trách nhiệm giải trình
Artifact	BA, QA, nhóm triển khai	Tạo và liên kết BRD, FS, Test Case, biên bản	NF-BRD-WH-001 v1.0.0, NF-FS-WMS-EXPIRY-001 v1.0.0, NF-TC-WMS-EXPIRY-001 v1.0.0, DOC-FS-PRICING-001	Bằng chứng review và truy vết
Consequence if Wrong	BA và quản lý dự án	Đánh giá rủi ro	Khách hàng, dữ liệu, vận hành, kiểm soát nội bộ	Cơ sở quyết định và kế hoạch giảm rủi ro

T-TYPE-003|PROD-GROUP-001| 5% |2026-09-01| ACTIVE |RULE-DISCOUNT-LOYAL-001|ponytail:` Quy tắc này đơn giản. Để mở rộng, cần thêm các trường như: điều kiện số lượng tối thiểu, giá trị đơn hàng tối thiểu, loại bỏ chiết khấu nếu đã có khuyến mãi khác, thứ tự ưu tiên khi có nhiều quy tắc áp dụng cùng lúc.

Mô hình quyết định quy tắc chiết khấu (Mermaid Decision Diagram):

graph TD
    A[Bắt đầu] --> B{Khách hàng là "CUST-TYPE-003"?};
    B -- Có --> C{Sản phẩm thuộc "PROD-GROUP-001"?};
    B -- Không --> D[Áp dụng giá niêm yết];
    C -- Có --> E[Áp dụng Chiết khấu 5%];
    C -- Không --> D;
    E --> F[Kết thúc];
    D --> F;

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

Nếu quyết định sai (ví dụ: chọn Option 1 hoặc Option 3 khi Option 2 là tối ưu), Nova Foods có thể đối mặt với các hậu quả sau: * Tài chính: Thất thoát doanh thu do chiết khấu sai, hoặc mất khách hàng do không áp dụng chiết khấu đúng. * Vận hành: Tăng thời gian xử lý đơn hàng, công sức điều chỉnh đơn hàng sai. * Danh tiếng: Giảm sự hài lòng của khách hàng và uy tín thương hiệu Nova Foods (mô phỏng). * Pháp lý/Tuân thủ: Nếu quy tắc chiết khấu là một phần của hợp đồng với khách hàng hoặc quy định ngành, việc áp dụng sai có thể dẫn đến các vấn đề pháp lý hoặc không tuân thủ.

9. Related Concepts & Dependencies

Core

Khái niệm liên quan (Related Concepts) là những ý tưởng hoặc chủ đề khác có mối liên hệ mật thiết với "Capstone Review And Evaluation" (Đánh giá và Thẩm định Capstone). Việc hiểu các khái niệm này giúp BA nhìn nhận bức tranh tổng thể, biết Capstone Review nằm ở đâu trong luồng công việc. Ví dụ, Capstone Review cần các khái niệm về "Yêu cầu nghiệp vụ" (Business Requirements), "Tiêu chí chấp nhận" (Acceptance Criteria) và "Kịch bản kiểm thử" (Test Cases) làm đầu vào.

Phụ thuộc (Dependencies) là mối quan hệ khi một phần tử (ví dụ: một chương, một tài liệu, một quy tắc) cần một phần tử khác để hoàn thành chức năng hoặc cung cấp giá trị. Phụ thuộc ngược dòng (Upstream Dependency) là những thứ phải có sẵn hoặc hoàn thành trước khi Capstone Review bắt đầu (ví dụ: tài liệu yêu cầu đã được lập). Phụ thuộc xuôi dòng (Downstream Dependency) là những thứ sẽ sử dụng kết quả của Capstone Review (ví dụ: báo cáo sẵn sàng triển khai). Việc lập bản đồ các phụ thuộc này rất quan trọng để đảm bảo tính truy vết (traceability), đánh giá tác động thay đổi và duy trì tính nhất quán của toàn bộ hệ thống Nova Foods (mô phỏng).

Applied

Facts (Thực tế)

• Chapter này (24-capstone-review-and-evaluation.md) định nghĩa quy trình Capstone Review và Evaluation cho BA.
• Nova Foods (mô phỏng) là một dự án ERP giả định cần các quy trình BA rõ ràng.
• Chương trình học BA này cần đảm bảo học viên hiểu luồng công việc từ đầu đến cuối.

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

Học viên có thể đọc chapter này mà không hiểu rõ nó lấy đầu vào từ đâu và kết quả của nó sẽ được dùng như thế nào trong các giai đoạn tiếp theo của dự án hoặc các chapter khác của chương trình học.

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

Cần một bản đồ rõ ràng các khái niệm, chapter, template, registry và ID liên quan đến Capstone Review. Điều này giúp học viên mới vào nghề (zero-entry learner) dễ dàng hình dung mối quan hệ giữa các phần khác nhau của dự án và chương trình học, từ đó nâng cao khả năng truy vết, hiểu tác động của thay đổi và biết cách điều hướng giữa các artifact.

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

1. Không lập bản đồ phụ thuộc: Để học viên tự tìm hiểu mối liên hệ giữa các chapter/artifact.
2. Lập bản đồ phụ thuộc không chính thức: Liệt kê các mối quan hệ bằng văn bản dạng tự do hoặc bullet point.
3. Lập bản đồ phụ thuộc chính thức bằng bảng: Sử dụng một bảng có cấu trúc để hiển thị rõ ràng ID, loại, tên và hướng phụ thuộc.

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

• Tính rõ ràng cho học viên mới: Phương pháp nào dễ hiểu nhất.
• Tính truy vết: Dễ dàng theo dõi nguồn gốc và tác động của thay đổi.
• Không trùng lặp nguồn chân lý: Tránh tạo ra dữ liệu trùng lặp với các registry hay manifest đã có.
• Tính quản trị: Dễ dàng duy trì và cập nhật khi chương trình học thay đổi.
• Khả năng phân tích tác động: Dễ dàng xác định phần nào bị ảnh hưởng khi một dependency thay đổi.

Decision (Quyết định)

Chọn Lựa chọn 3: Lập bản đồ phụ thuộc chính thức bằng bảng. Bản đồ dạng bảng cung cấp cấu trúc rõ ràng, dùng các định danh cố định (persistent IDs) từ các registry đã được kiểm soát (TRACEABILITY_ID_REGISTRY, CHAPTER_MANIFEST, TEMPLATE_MANIFEST, v.v.) để đảm bảo tính nhất quán và không trùng lặp thông tin.

Authority (Thẩm quyền)

Principal IT Business Analyst / Technical Curriculum Author – vai trò có trách nhiệm thiết kế và duy trì cấu trúc chương trình học.

Artifact (Tài liệu kết quả)

Bảng phụ thuộc thể hiện mối liên hệ giữa chapter 24-capstone-review-and-evaluation.md với các chapter, registry và template liên quan, bao gồm các định danh cố định (persistent IDs).

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

Nếu không lập bản đồ phụ thuộc một cách chính thức, học viên có thể gặp khó khăn trong việc kết nối kiến thức giữa các chapter, dẫn đến hiểu sai hoặc thiếu sót về quy trình BA. Việc không có bản đồ rõ ràng cũng làm tăng rủi ro khi thay đổi một chapter hoặc registry, gây ra sự không nhất quán, gián đoạn trong chương trình học và giảm khả năng phân tích tác động. Đối với Nova Foods (mô phỏng), điều này có thể dẫn đến việc các BA không hiểu rõ các giai đoạn chuyển giao giữa các phòng ban, ảnh hưởng đến chất lượng dự án.

Senior Lens

Trong các dự án ERP lớn như Nova Foods (mô phỏng), việc lập bản đồ phụ thuộc không chỉ là một nhiệm vụ học thuật mà là một thực hành quản trị dự án BA bắt buộc. Mỗi chapter trong handbook, mỗi template hay registry là một artifact có thể có tác động dây chuyền. BA cấp cao phải chủ động xác định và duy trì các mối quan hệ này để:

1. Truy vết (Traceability): Đảm bảo mọi yếu tố trong Capstone Review đều có thể truy ngược về nguồn gốc (ví dụ: yêu cầu trong CANONICAL_BUSINESS_RULES hoặc định nghĩa dữ liệu trong CANONICAL_DATA_DICTIONARY).
2. Phân tích tác động (Impact Analysis): Khi một yêu cầu thay đổi, BA có thể nhanh chóng xác định Capstone Review (và các artifact đầu vào của nó như tài liệu yêu cầu, kịch bản kiểm thử) bị ảnh hưởng như thế nào.
3. Quản trị thay đổi (Change Governance): Giúp ra quyết định có căn cứ về việc phê duyệt thay đổi, tránh những thay đổi "ngầm" phá vỡ tính nhất quán của hệ thống.
4. Tái sử dụng (Reusability): Hiểu rõ phụ thuộc giúp tái sử dụng các artifact hiệu quả hơn trong các dự án hoặc giai đoạn khác.

Việc phụ thuộc vào các Registry như /01-curriculum/TRACEABILITY_ID_REGISTRY.md là tối quan trọng, nó đảm bảo mỗi ID dùng trong Capstone Review (ví dụ: REQ-001, AC-005) đều là duy nhất và có thể truy vết trên toàn bộ chương trình học. Bất kỳ thay đổi im lặng nào trong một dependency ngược dòng (ví dụ: một quy tắc nghiệp vụ trong CANONICAL_BUSINESS_RULES.md) mà không được truyền đạt hoặc phân tích tác động có thể làm mất hiệu lực toàn bộ Capstone Review, dẫn đến hệ thống Nova Foods (mô phỏng) không đạt được mục tiêu ban đầu.

Quick Reference

Bảng dưới đây minh họa các khái niệm, chapter, registry và template có mối liên hệ ngược dòng (đầu vào) và xuôi dòng (đầu ra) với chapter 24-capstone-review-and-evaluation.md.

Artifact ID	Loại Artifact	Tên tệp / Chapter / Registry	Mô tả	Hướng phụ thuộc	ID liên quan (nếu có)
24-capstone-review-and-evaluation.md	Chapter	24 Capstone Review And Evaluation	Chapter hiện tại	N/A	HANDBOOK-24-CRVE
00_SOURCE_MAP	Registry	/00-research/00_SOURCE_MAP.md	Nguồn chân lý cho các tài liệu tham khảo	Ngược dòng (Đầu vào)	SRC-MAP-V090
01_CURRICULUM_ARCHITECTURE	Registry	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Cấu trúc tổng thể chương trình học BA	Ngược dòng (Đầu vào)	CURR-ARCH-V090
CHAPTER_MANIFEST	Registry	/01-curriculum/CHAPTER_MANIFEST.md	Danh sách định danh và đường dẫn các chapter	Ngược dòng (Đầu vào)	CHAP-MAN-V090
TEMPLATE_MANIFEST	Registry	/01-curriculum/TEMPLATE_MANIFEST.md	Danh sách định danh và đường dẫn các template	Ngược dòng (Đầu vào)	TEMP-MAN-V090
TRACEABILITY_ID_REGISTRY	Registry	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Đăng ký định danh truy vết toàn corpus	Ngược dòng (Đầu vào)	TID-REG-V090
CANONICAL_BUSINESS_RULES	Registry	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Catalog quy tắc nghiệp vụ chuẩn Nova Foods (mô phỏng)	Ngược dòng (Đầu vào)	CBR-V090
CANONICAL_DATA_DICTIONARY	Registry	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Từ điển dữ liệu logic chuẩn Nova Foods (mô phỏng)	Ngược dòng (Đầu vào)	CDD-V090
18-requirement-documentation.md	Chapter	18 Requirement Documentation	Tài liệu yêu cầu (ví dụ: SRS/BRD)	Ngược dòng (Đầu vào)	CHAP-18-REQD
17-acceptance-criteria-definition.md	Chapter	17 Acceptance Criteria Definition	Tiêu chí chấp nhận (Acceptance Criteria)	Ngược dòng (Đầu vào)	CHAP-17-ACDF
21-test-case-design.md	Chapter	21 Test Case Design	Thiết kế kịch bản kiểm thử (Test Cases)	Ngược dòng (Đầu vào)	CHAP-21-TCD
GEN-TMPL-APP (Conceptual)	Template	Approval/Sign-off Template	Template phê duyệt Capstone Review	Xuôi dòng (Đầu ra)	TMPL-APP-001
Release Plan (Conceptual)	Chapter/Artifact	Release and Deployment Planning	Kế hoạch phát hành/triển khai	Xuôi dòng (Đầu ra)	CHAP-XX-RELPL

Bảng Truy Vết và Phụ Thuộc

Core

Bảng truy vết (Traceability Table) công cụ quan trọng. Giúp thấy liên hệ giữa các phần dự án. Mọi yêu cầu (requirement), quy tắc nghiệp vụ (business rule), tiêu chí chấp nhận (acceptance criteria), trường hợp kiểm thử (test case) phải liên kết. Đảm bảo không bỏ sót. Đảm bảo thay đổi một chỗ, biết chỗ khác bị ảnh hưởng.

Loại liên kết phổ biến:

• NEED (Nhu Cầu): Lý do gốc. Tại sao cần tính năng.
• REQ (Yêu Cầu): Mô tả giải pháp cho nhu cầu. Hệ thống làm gì.
• BR (Quy Tắc Nghiệp Vụ - Business Rule): Quy tắc quyết định hành vi hệ thống. Ví dụ: Nova Foods BR-NF-TEMP-001. Nguồn 01-curriculum/CANONICAL_BUSINESS_RULES.md.
• AC (Tiêu Chí Chấp Nhận - Acceptance Criteria): Điều kiện phải đạt để yêu cầu hoàn thành. Kiểm thử dựa vào đây.
• DATA/API (Dữ liệu/API): Dữ liệu cần, hoặc giao diện lập trình ứng dụng (Application Programming Interface - API) hệ thống dùng.
• TC (Trường Hợp Kiểm Thử - Test Case): Các bước để xác minh AC.

Mỗi mục bảng có ID duy nhất. ID nguồn từ 01-curriculum/TRACEABILITY_ID_REGISTRY.md cho Nova Foods.

Applied

Nova Foods cần theo dõi nhiệt độ kho đông lạnh. Hiện tại, ghi sổ tay. Sai sót nhiều.

• Facts: Kho đông lạnh Nova Foods trữ sản phẩm đông lạnh. Nhiệt độ cần ổn định.
• Current Behavior (Hành vi Hiện tại): Nhân viên thủ công kiểm tra, ghi nhiệt độ mỗi giờ. Dễ quên, ghi sai.
• Underlying Need (Nhu Cầu Cơ bản): Tự động hóa ghi nhận nhiệt độ. Đảm bảo tuân thủ tiêu chuẩn an toàn thực phẩm. Giảm lỗi con người.
• Options (Các Lựa chọn): 1) Hệ thống giám sát riêng. 2) Tích hợp cảm biến vào ERP hiện có. 3) Giữ thủ công, thêm giám sát chéo.
• Decision Criteria (Tiêu chí Quyết định): Chi phí triển khai, độ chính xác, tốc độ cảnh báo, tích hợp ERP.
• Decision (Quyết định): Tích hợp cảm biến nhiệt độ vào module Kho của ERP. Dùng API hiện có.
• Authority (Thẩm quyền Quyết định): Quản lý Kho (Business Owner), Kiến trúc sư Hệ thống (Technical Architect).
• Artifact (Sản phẩm): Bảng Truy Vết dưới đây.
• Consequence if Wrong (Hậu quả nếu sai): Hỏng hàng đông lạnh. Tổn thất kinh tế. Bị phạt hành chính. Mất uy tín Nova Foods.

Bảng Truy Vết Nhiệt Độ Kho Lạnh Nova Foods (Mô phỏng)

ID Liên Kết	Mô Tả Ngắn	Loại Liên Kết	Nguồn Tham Chiếu	Liên Kết Đến
NEED-NF-005	Nova Foods cần giám sát nhiệt độ kho đông lạnh tự động.	NEED	24-capstone-review-and-evaluation.md (P.9)	-
REQ-NF-FR-012	Hệ thống tự động ghi nhận nhiệt độ kho mỗi 15 phút.	REQ	03-templates/REQ-NF-FR-012.md	NEED-NF-005
BR-NF-TEMP-001	Nhiệt độ kho đông lạnh phải duy trì -18°C đến -22°C.	BR	01-curriculum/CANONICAL_BUSINESS_RULES.md	REQ-NF-FR-012
AC-NF-FR-012.1	Hệ thống lưu trữ 192 bản ghi nhiệt độ/ngày/cảm biến.	AC	03-templates/REQ-NF-FR-012.md	REQ-NF-FR-012, BR-NF-TEMP-001
AC-NF-FR-012.2	Gửi cảnh báo email nếu nhiệt độ > -18°C hoặc < -22°C trong 5 phút liên tục.	AC	03-templates/REQ-NF-FR-012.md	REQ-NF-FR-012, BR-NF-TEMP-001
DATA-NF-API-WMS-003	API POST /api/wms/temperature-log nhận dữ liệu { "sensorId", "timestamp", "tempC" }.	DATA/API	04-cheatsheets/API-WMS-003-spec.md	REQ-NF-FR-012
TC-NF-SMOKE-TEMP-001	Xác minh API temperature-log ghi nhận nhiệt độ hợp lệ.	TC	06-qa/TEST-PLAN-WMS-001.md	DATA-NF-API-WMS-003, AC-NF-FR-012.1
TC-NF-ALERT-TEMP-002	Kiểm tra hệ thống gửi email cảnh báo khi nhiệt độ vượt ngưỡng.	TC	06-qa/TEST-PLAN-WMS-001.md	AC-NF-FR-012.2

Senior Lens

Truy vết không chỉ bảng. Là công cụ quản lý thay đổi (Change Management). Mối liên hệ rõ ràng, giúp ước tính tác động khi có thay đổi. Nếu BR-NF-TEMP-001 thay đổi (ví dụ, tiêu chuẩn mới cho -20°C đến -25°C), truy vết chỉ ra: AC-NF-FR-012.1, AC-NF-FR-012.2, TC-NF-ALERT-TEMP-002 bị ảnh hưởng. Cần cập nhật.

Lỗi âm thầm (Silent Break): xảy ra khi một phụ thuộc thay đổi nhưng không ai biết. Ví dụ: database field thay đổi kiểu dữ liệu, nhưng API DATA-NF-API-WMS-003 không cập nhật. Frontend gửi sai, backend lỗi ngầm. Không có truy vết, khó tìm nguyên nhân. Quy tắc từ 01-curriculum/TRACEABILITY_ID_REGISTRY.md yêu cầu ID duy nhất, tránh nhầm lẫn, giúp tra cứu nhanh. Luôn duy trì tính nhất quán ID để đảm bảo toàn vẹn.

Quick Reference

• Truy vết = bản đồ dự án.
• Liên kết = mối quan hệ.
• Mục đích = hiểu tác động thay đổi, không bỏ sót.
• Quan trọng = để tránh lỗi âm thầm, giảm rủi ro Nova Foods.

Lan Truy Thay Đổi và Hậu Quả khi Phụ Thuộc Thay Đổi Thầm Lặng

Core

Phụ thuộc (Dependency) là mối quan hệ giữa các yếu tố trong một hệ thống hoặc quy trình, trong đó sự thay đổi của một yếu tố (yếu tố nguồn) sẽ ảnh hưởng đến yếu tố khác (yếu tố đích). Trong phân tích nghiệp vụ, các phụ thuộc có thể là giữa yêu cầu, quy tắc nghiệp vụ, định nghĩa dữ liệu, tài liệu đặc tả, hoặc thậm chí các tính năng hệ thống. Ví dụ, một Yêu cầu (Requirement) có thể phụ thuộc vào một Quy tắc nghiệp vụ (Business Rule) cụ thể. Để theo dõi các mối quan hệ này, Sổ đăng ký định danh truy vết (TRACEABILITY_ID_REGISTRY) là công cụ thiết yếu.

Lan truyền thay đổi (Change Propagation) mô tả quá trình một thay đổi ở yếu tố nguồn sẽ dẫn đến một chuỗi các thay đổi ở các yếu tố phụ thuộc. Nếu Quy tắc nghiệp vụ (Business Rule) thay đổi, các Yêu cầu (Requirement), Tiêu chí chấp nhận (Acceptance Criteria), và Trường dữ liệu (Data Field) liên quan cũng phải được xem xét để cập nhật. Việc không kiểm soát quá trình này sẽ gây ra mất đồng bộ và lỗi hệ thống.

Thay đổi thầm lặng (Silent Change) xảy ra khi một yếu tố phụ thuộc thay đổi mà không được ghi nhận, thông báo, hoặc đánh giá tác động đầy đủ. Đây là một rủi ro lớn vì các yếu tố khác phụ thuộc vào nó sẽ tiếp tục hoạt động dựa trên thông tin cũ, dẫn đến kết quả sai lệch, lỗi hệ thống, hoặc thất bại trong kiểm thử. Mục tiêu của việc quản lý phụ thuộc là loại bỏ hoàn toàn thay đổi thầm lặng.

Applied

Tình huống Nova Foods: Đội BA đang xây dựng tính năng quản lý kho cho Hệ thống ERP mô phỏng của Nova Foods. * Facts: Nova Foods có Yêu cầu REQ-INV-001: Hệ thống phải cảnh báo khi số lượng tồn kho của một SKU xuống dưới ngưỡng an toàn. Quy tắc nghiệp vụ BR-WH-005: Ngưỡng tồn kho an toàn mặc định là 10 đơn vị cho mỗi SKU thực phẩm đông lạnh. Định nghĩa dữ liệu DATA-INV-001: NovaFoods.SKU.CurrentStock là số lượng hiện có của SKU. Tiêu chí chấp nhận AC-INV-001: Khi NovaFoods.SKU.CurrentStock < 10, hệ thống phải gửi thông báo đến Quản lý Kho. Trường hợp kiểm thử TC-INV-001: Kiểm tra cảnh báo khi tồn kho đạt 9 đơn vị. * Current Behavior (Hành vi hiện tại): Do điều kiện kinh tế thay đổi, Quản lý Kho Nova Foods quyết định "thay đổi thầm lặng" ngưỡng tồn kho an toàn cho SKU thực phẩm đông lạnh lên 15 đơn vị, nhưng không cập nhật BR-WH-005 trong tài liệu nghiệp vụ, không thông báo cho đội BA. * Underlying Need (Nhu cầu cốt lõi): Nova Foods cần duy trì lượng hàng tồn kho tối ưu để đáp ứng nhu cầu thị trường và giảm thiểu rủi ro hết hàng, đồng thời kiểm soát chi phí lưu kho. * Options (Các lựa chọn): 1. Duy trì thay đổi thầm lặng: Hệ thống tiếp tục dùng ngưỡng 10, người dùng thực tế dùng 15. 2. Cập nhật chính thức BR-WH-005 và các yếu tố phụ thuộc. * Decision Criteria (Tiêu chí quyết định): Độ chính xác dữ liệu, tuân thủ quy tắc nghiệp vụ, hiệu quả vận hành, khả năng kiểm thử. * Decision (Quyết định): Mọi thay đổi quy tắc nghiệp vụ phải được ghi nhận và truyền đạt chính thức, dẫn đến cập nhật các yếu tố liên quan. * Authority (Thẩm quyền): Business Owner và Quản lý Kho. * Artifact (Tạo tác bị ảnh hưởng): BR-WH-005, REQ-INV-001, DATA-INV-001, AC-INV-001, TC-INV-001. * Consequence if Wrong (Hậu quả nếu sai): * Hệ thống ERP cảnh báo khi tồn kho dưới 10 đơn vị, trong khi thực tế cần cảnh báo khi dưới 15. Điều này dẫn đến mua hàng chậm trễ, mất cơ hội bán hàng. * TC-INV-001 (kiểm tra cảnh báo ở 9 đơn vị) vẫn "pass" (đạt) mặc dù hệ thống đã hoạt động sai với kỳ vọng mới của nghiệp vụ. * Dữ liệu NovaFoods.SKU.CurrentStock có thể bị diễn giải sai nếu các báo cáo kinh doanh dùng ngưỡng 15 trong khi hệ thống vận hành theo ngưỡng 10.

Senior Lens

Thay đổi thầm lặng là nguyên nhân hàng đầu gây ra các lỗi không mong muốn trong hệ thống. Khi một quy tắc nghiệp vụ thay đổi mà không cập nhật tài liệu 01-curriculum/CANONICAL_BUSINESS_RULES.md, không điều chỉnh 01-curriculum/CANONICAL_DATA_DICTIONARY.md (nếu có ảnh hưởng đến định nghĩa dữ liệu), và quan trọng nhất là không ghi nhận trong 01-curriculum/TRACEABILITY_ID_REGISTRY.md, hậu quả sẽ lan truyền như sau: 1. Phía Nghiệp vụ (Business): Quyết định kinh doanh dựa trên thông tin lỗi thời, giảm hiệu quả, mất doanh thu, hoặc tăng chi phí. 2. Phía Phát triển (Development): Mã nguồn xây dựng dựa trên yêu cầu cũ, dẫn đến broken builds (lỗi biên dịch/tích hợp) hoặc production bugs (lỗi hệ thống khi triển khai). Phát sinh rework (làm lại) tốn kém và missed deadlines (trễ thời hạn). 3. Phía Kiểm thử (QA): Test cases (các trường hợp kiểm thử) trở nên vô dụng hoặc đưa ra kết quả sai lệch. Các test case tự động có thể vẫn "pass" dù hệ thống không đáp ứng đúng kỳ vọng nghiệp vụ mới.

Để tránh những rủi ro này, quy trình quản lý thay đổi (change control process) và phân tích tác động (impact analysis) phải được thực hiện nghiêm ngặt. Mọi thay đổi, dù nhỏ, đều phải được đánh giá tác động lên các phụ thuộc và cập nhật tài liệu liên quan thông qua TRACEABILITY_ID_REGISTRY.

graph TD
    subgraph "Nguồn Thay Đổi"
        A[BR-WH-005: Ngưỡng tồn kho an toàn] --> B{Quyết định: Nâng ngưỡng từ 10 lên 15};
    end

    subgraph "Lan Truyền Thay Đổi Chính Thức (mong muốn)"
        B -- Cập nhật --> C[01-curriculum/CANONICAL_BUSINESS_RULES.md];
        C --> D[REQ-INV-001: Yêu cầu cảnh báo tồn kho];
        C --> E[DATA-INV-001: Định nghĩa NovaFoods.SKU.CurrentStock];
        D --> F[AC-INV-001: Tiêu chí chấp nhận cảnh báo];
        F --> G[TC-INV-001: Test Case cảnh báo];
        subgraph "Quản trị"
            C & D & E & F & G -- Ghi nhận & theo dõi --> TRACEABILITY_ID_REGISTRY[Sổ đăng ký định danh truy vết];
        end
    end

    subgraph "Hậu Quả Thay Đổi Thầm Lặng (Thực tế)"
        B -- KHÔNG cập nhật --> H[Hệ thống ERP hoạt động với ngưỡng cũ (10)];
        H --> I[Quyết định nghiệp vụ sai lệch (mua hàng chậm)];
        H --> J[Kiểm thử TC-INV-001 vẫn PASS (dù kỳ vọng thay đổi)];
        I --> K[Thiệt hại kinh doanh cho Nova Foods];
    end

Quick Reference

Loại phụ thuộc	Mô tả	Hậu quả của Thay đổi Thầm lặng
REQ (Yêu cầu)	Phụ thuộc vào BR, DATA, API.	Tính năng sai, không đáp ứng nhu cầu.
BR (Quy tắc nghiệp vụ)	Phụ thuộc vào DATA, các quy định pháp luật.	Quy trình kinh doanh sai, không tuân thủ.
AC (Tiêu chí chấp nhận)	Phụ thuộc vào REQ, BR.	Kiểm thử không phát hiện lỗi, bàn giao hệ thống sai.
DATA/API	Phụ thuộc vào BR, REQ khác.	Dữ liệu không nhất quán, tích hợp lỗi, hệ thống bị crash.
TC (Test Case)	Phụ thuộc vào AC, REQ.	Kiểm thử "pass" nhưng hệ thống hoạt động sai so với kỳ vọng hiện tại.

Các hành động phòng ngừa thay đổi thầm lặng: 1. Luôn ghi nhận: Mọi thay đổi phải được ghi nhận vào hệ thống quản lý thay đổi. 2. Phân tích tác động: Đánh giá kỹ lưỡng các yếu tố phụ thuộc trước khi thực hiện thay đổi. 3. Truyền thông: Thông báo thay đổi đến tất cả các bên liên quan. 4. Cập nhật tài liệu: Cập nhật 01-curriculum/CANONICAL_BUSINESS_RULES.md, 01-curriculum/CANONICAL_DATA_DICTIONARY.md, TRACEABILITY_ID_REGISTRY, và các tài liệu khác. 5. Tái kiểm thử: Thực hiện kiểm thử hồi quy (regression testing) để đảm bảo không có lỗi mới phát sinh.

10. Common Mistakes & Anti-patterns

Core

Business Analyst (BA) mới vào nghề hoặc nhóm triển khai (delivery team) thường mắc lỗi cơ bản. Nhận biết "Anti-patterns" (các mô hình chống lại hiệu quả) và "red flags" (dấu hiệu cảnh báo) sớm giúp giảm rủi ro dự án.

Bảng 10.1: Lỗi phổ biến, Dấu hiệu cảnh báo và Hành động khắc phục

Lỗi phổ biến (Common Mistakes)	Dấu hiệu cảnh báo (Red Flags)	Nguyên nhân gốc (Root Causes)	Hành động khắc phục (Corrective Actions)
1. Tính không rõ ràng (Ambiguity)	Yêu cầu viết chung chung ("hệ thống cần thân thiện", "phải nhanh")	Thiếu kỹ thuật khai thác yêu cầu; không dùng định lượng; sợ cam kết.	Định lượng (ví dụ: "thân thiện" là đạt WCAG 2.2 Level AA; "nhanh" là tải dưới 3 giây cho 90% người dùng); dùng ví dụ cụ thể; xác nhận với Business Owner.
2. Tính không đầy đủ (Incompleteness)	Thiếu các trường dữ liệu quan trọng; không có trường hợp lỗi (error case) được đặc tả; không đủ tiêu chí chấp nhận (acceptance criteria).	BA chưa hiểu sâu nghiệp vụ; bỏ qua edge cases; quá tập trung vào luồng chính (happy path).	Sử dụng checklist khai thác; phỏng vấn các bên liên quan (stakeholders) khác nhau; phân tích luồng dữ liệu (data flow) và trạng thái (state transition); kiểm tra tài liệu 01-curriculum/CANONICAL_BUSINESS_RULES.md.
3. Tuyên bố không có thẩm quyền (Unsupported Authority Claims)	BA tự ý "quyết định" hoặc "suy diễn" quy tắc nghiệp vụ (business rule); gán yêu cầu cho "khách hàng nói thế" mà không có bằng chứng.	Thiếu quy trình phê duyệt yêu cầu; thiếu hiểu biết về vai trò ra quyết định; không theo dõi TRACEABILITY_ID_REGISTRY.md.	Luôn xác nhận với Business Owner hoặc Product Owner; yêu cầu phê duyệt rõ ràng cho các quy tắc quan trọng; ghi lại người phê duyệt, thời điểm và bằng chứng phê duyệt (ví dụ: email, biên bản họp).
4. Lạm dụng/Sai ký hiệu (Notation Misuse)	Dùng biểu đồ BPMN cho luồng giao diện người dùng (UI flow); dùng sai quan hệ trong UML; dùng PlantUML như BPMN.	Thiếu đào tạo về các chuẩn ký hiệu (BPMN, UML); không hiểu mục đích của từng loại biểu đồ.	Học các chuẩn ký hiệu (tham khảo BABOK Guide, OMG BPMN/UML); hiểu rõ mục đích từng loại biểu đồ; chỉ dùng ký hiệu phù hợp.
5. Đứt gãy truy vết (Traceability Breaks)	Không thể liên kết yêu cầu với tiêu chí chấp nhận, test case, hoặc thiết kế; thay đổi yêu cầu mà không cập nhật tài liệu liên quan.	Thiếu công cụ quản lý yêu cầu; không tuân thủ quy trình quản lý thay đổi; không hiểu tầm quan trọng của truy vết.	Sử dụng công cụ quản lý yêu cầu (ALM); áp dụng TRACEABILITY_ID_REGISTRY.md cho mọi artifact; thực hiện phân tích tác động (impact analysis) khi có thay đổi.

Applied

Tình huống mô phỏng Nova Foods: Đặc tả không rõ ràng cho quy trình Kiểm kê kho nguyên liệu

• Facts (Sự thật): Nova Foods (mô phỏng) đang nâng cấp module kiểm kê kho (Inventory Module) trong ERP. BA được giao nhiệm vụ đặc tả quy tắc nghiệp vụ cho quy trình "Xác nhận số lượng nguyên liệu nhập kho".
• Current Behavior (Hành vi hiện tại): BA viết yêu cầu: "Hệ thống phải kiểm tra số lượng nguyên liệu nhận được với phiếu đặt hàng". Nhưng không đặc tả rõ ràng "kiểm tra" nghĩa là gì khi có sai lệch. (Ví dụ: Chênh lệch < 1% thì tự động điều chỉnh, hay luôn phải báo lỗi?)
• Underlying Need (Nhu cầu cốt lõi): Nova Foods cần quy trình nhập kho hiệu quả, tránh sai sót dữ liệu, giảm thiểu sự can thiệp thủ công, nhưng vẫn đảm bảo tính chính xác cao cho nguyên liệu sản xuất.
• Options (Các lựa chọn):
  1. Để đặc tả mơ hồ, phó mặc cho Dev tự suy diễn.
  2. Hỏi Business Owner (ví dụ: Trưởng phòng Thu mua) để làm rõ giới hạn sai lệch chấp nhận được và hành động tương ứng.
  3. Tham khảo quy trình kiểm kê cũ (nếu có) hoặc tiêu chuẩn kế toán (ví dụ: Luật Kế toán 88/2015/QH13) để tìm hướng dẫn.
• Decision Criteria (Tiêu chí ra quyết định):
  • Độ chính xác: Quy trình phải đảm bảo số liệu kho đúng với thực tế.
  • Hiệu quả: Giảm thời gian xử lý thủ công cho sai lệch nhỏ.
  • Tuân thủ: Phù hợp với quy định nội bộ và pháp luật (nếu có).
  • Rủi ro: Nguy cơ sai sót dữ liệu, thất thoát nguyên liệu.
• Decision (Quyết định): BA tổ chức họp với Trưởng phòng Thu mua và Kế toán để định lượng rõ ràng:
  • Nếu số lượng thực nhận khác biệt < 0.5% so với phiếu đặt hàng, hệ thống tự động ghi nhận số lượng thực nhận và tạo cảnh báo thông tin cho Kế toán.
  • Nếu số lượng thực nhận khác biệt >= 0.5%, hệ thống từ chối nhập kho và yêu cầu người dùng nhập lý do, sau đó trình duyệt lên Trưởng phòng Thu mua.
• Authority (Thẩm quyền): Trưởng phòng Thu mua (Business Owner) và Kế toán trưởng (Accounting Owner) Nova Foods (mô phỏng) phê duyệt quy tắc này.
• Artifact (Tạo phẩm):
  • Cập nhật REQ-NF-INV-005: Xử lý sai lệch số lượng nguyên liệu nhập kho trong tài liệu đặc tả yêu cầu.
  • Tạo BR-NF-INV-005.01: Quy tắc chênh lệch số lượng nhập kho trong /01-curriculum/CANONICAL_BUSINESS_RULES.md.
  • Thêm DATA-NF-INV-QTY-DIFF-PCT (ngưỡng phần trăm chênh lệch) vào /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
  • Ghi nhận ID và phê duyệt vào TRACEABILITY_ID_REGISTRY.md.
• Consequence if Wrong (Hậu quả nếu sai):
  • Hệ thống không xử lý nhất quán các trường hợp sai lệch số lượng.
  • Nhân viên kho phải xử lý thủ công, tốn thời gian, dễ sai sót.
  • Số liệu kho không chính xác, ảnh hưởng đến kế hoạch sản xuất và báo cáo tài chính.
  • Nova Foods có thể phải đối mặt với sai lệch tồn kho lớn, gây thất thoát hoặc thiếu hụt nguyên liệu nghiêm trọng.

Senior Lens

BA cấp cao nhìn nhận lỗi không rõ ràng, không đầy đủ hay sai thẩm quyền không chỉ là lỗi kỹ thuật đơn thuần mà là dấu hiệu của điểm yếu trong quy trình, quản trị hoặc văn hóa dự án. Một đặc tả mơ hồ có thể che giấu sự thiếu quyết đoán từ phía nghiệp vụ (business), hoặc sự thiếu hiểu biết về giới hạn công nghệ từ phía BA. Việc khắc phục không chỉ là sửa tài liệu mà còn là củng cố kênh truyền thông, nâng cao kỹ năng BA, và thiết lập cơ chế phê duyệt chặt chẽ. BA cấp cao ưu tiên ngăn ngừa lỗi từ gốc bằng cách thúc đẩy sự hợp tác đa chức năng, sử dụng các chuẩn mực tài liệu (ví dụ: 01-curriculum/CHAPTER_MANIFEST.md, 01-curriculum/TEMPLATE_MANIFEST.md), và đảm bảo mọi quyết định quan trọng đều được ghi nhận bằng TRACEABILITY_ID_REGISTRY.md với thẩm quyền rõ ràng.

Quick Reference

Bảng 10.2: Tóm tắt hành động phòng ngừa

Anti-pattern	Hành động chính của BA	Artifact liên quan	Lợi ích cho Nova Foods
Ambiguity (Không rõ ràng)	Định lượng, cụ thể hóa: Sử dụng con số, ví dụ, giới hạn trên/dưới.	REQ, BR, DATA (trong CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md)	Giảm hiểu lầm, giảm rework, tăng chất lượng sản phẩm/tính năng.
Incompleteness (Không đầy đủ)	Phân tích toàn diện: Bao quát luồng chính và các trường hợp ngoại lệ.	REQ, AC, TC	Giảm thiếu sót, tăng độ bao phủ của giải pháp, giảm lỗi sau triển khai.
Unsupported Authority (Thiếu thẩm quyền)	Xác nhận, phê duyệt: Luôn có xác nhận từ Business Owner/Product Owner.	BR, REQ (ghi rõ người duyệt, thời điểm)	Đảm bảo giải pháp phù hợp với mục tiêu nghiệp vụ, tránh tranh cãi sau này.
Notation Misuse (Sai ký hiệu)	Tuân thủ chuẩn: Áp dụng đúng BPMN, UML, PlantUML theo mục đích.	DIAGRAM (Flowchart, Sequence Diagram)	Tăng khả năng đọc hiểu tài liệu, giảm rủi ro diễn giải sai thiết kế.
Traceability Breaks (Đứt gãy truy vết)	Liên kết, quản lý thay đổi: Tạo liên kết rõ ràng giữa các tạo phẩm, theo dõi thay đổi.	REQ, AC, TC, DESIGN, TRACEABILITY_ID_REGISTRY.md	Dễ dàng theo dõi tiến độ, đánh giá tác động thay đổi, đảm bảo tính toàn vẹn hệ thống.

Rủi ro thực và ranh giới phục hồi an toàn trong Capstone Review

Core

Rủi ro (Risk) trong Capstone Review là sự kiện hoặc điều kiện không chắc chắn, nếu xảy ra, sẽ có tác động tiêu cực đến mục tiêu dự án hoặc hoạt động nghiệp vụ của Nova Foods. Một "rủi ro thực" (real risk) là rủi ro có khả năng xảy ra cao và hậu quả nghiêm trọng, được xác định dựa trên bằng chứng cụ thể, không phải suy đoán mơ hồ. "Ranh giới phục hồi an toàn" (safe recovery boundary) là các ngưỡng hoặc điểm kiểm soát đã được xác định trước, cho phép hệ thống hoặc quy trình trở lại trạng thái hoạt động bình thường, bảo toàn tính toàn vẹn (data integrity) của dữ liệu, tuân thủ (compliance) quy định và giảm thiểu thiệt hại, nếu một rủi ro xảy ra. Việc nhận diện rủi ro thật và thiết lập ranh giới phục hồi giúp nhóm dự án và nghiệp vụ chủ động phòng ngừa, có kế hoạch ứng phó, tránh các quyết định ứng phó vội vàng gây hậu quả khó lường.

Applied

Tình huống lỗi Nova Foods (mô phỏng): Dữ liệu Product ID không hợp lệ

• Facts (Sự thật): Nova Foods triển khai mô-đun Quản lý Kho (Inventory Management) trong ERP mới. Khi chuyển đổi dữ liệu, trường Product ID (Mã sản phẩm) từ hệ thống cũ có định dạng P_YYNNN (ví dụ P_23001). Quy tắc nghiệp vụ mới cho ERP yêu cầu định dạng NF-YY-NNNN (ví dụ NF-24-0001) và Product ID phải là duy nhất (unique) trên toàn hệ thống. Nhóm BA (Business Analyst) đã bỏ sót việc kiểm tra quy tắc định dạng và tính duy nhất này trong giai đoạn lập kế hoạch Capstone Review ban đầu.
• Current Behavior (Hành vi hiện tại): Dữ liệu cũ với định dạng P_YYNNN được nhập vào ERP mới. Hệ thống chấp nhận các ID này nhưng gắn cờ "ngoại lệ" (exception) trong các báo cáo tổng hợp tồn kho hoặc khi cố gắng tạo đơn hàng mới với ID cũ. Điều này làm gián đoạn quy trình nghiệp vụ, mất thời gian tra cứu và gây ra báo cáo không chính xác.
• Underlying Need (Nhu cầu cốt lõi): Đảm bảo tính toàn vẹn dữ liệu (data integrity) của trường Product ID trong ERP mới, tuân thủ các quy tắc nghiệp vụ đã định trong 01-curriculum/CANONICAL_BUSINESS_RULES.md (ví dụ: BR-INV-001: Product ID Format) và 01-curriculum/CANONICAL_DATA_DICTIONARY.md (định nghĩa Product ID).
• Options (Các lựa chọn):
  1. Tiếp tục chấp nhận định dạng cũ: Tạo các script tùy chỉnh để chuyển đổi định dạng khi xuất báo cáo hoặc tích hợp với hệ thống khác.
  2. Chỉnh sửa thủ công Product ID: Yêu cầu đội vận hành chỉnh sửa từng Product ID cũ sang định dạng mới.
  3. Tự động hóa kiểm tra và chuẩn hóa: Xây dựng một quy trình tự động để kiểm tra, gắn cờ và chuẩn hóa Product ID không đúng định dạng trong quá trình nhập liệu hoặc như một tác vụ định kỳ.
• Decision Criteria (Tiêu chí quyết định):
  • Chi phí: Thời gian phát triển, chi phí bảo trì.
  • Rủi ro lỗi dữ liệu: Khả năng gây ra sai sót trong dữ liệu.
  • Hiệu quả vận hành: Mức độ ảnh hưởng đến người dùng cuối và quy trình nghiệp vụ.
  • Tuân thủ: Đảm bảo phù hợp với Luật Kế toán và các quy định nội bộ Nova Foods về quản lý hàng tồn kho.
• Decision (Quyết định): Chọn lựa chọn 3. Áp dụng quy trình tự động hóa kiểm tra và chuẩn hóa Product ID.

graph TD
    A[Bắt đầu quá trình nhập/cập nhật Product ID] --> B{Product ID có đúng định dạng NF-YY-NNNN không?};
    B -- Có --> C{Product ID đã tồn tại trong hệ thống không?};
    B -- Không --> D[Gắn cờ lỗi "Định dạng không hợp lệ", chuyển vào hàng đợi xử lý ngoại lệ];
    C -- Có --> D;
    C -- Không --> E[Ghi Product ID vào ERP; Trạng thái: Hợp lệ];
    D --> F[Thông báo cho Data Owner và nhóm BA; Cập nhật NOVA-FOODS-RISK-LOG.xlsx];
    E --> G[Kết thúc];
    F --> G;

• Authority (Thẩm quyền): Business Owner (Phòng Kho vận, Phòng Kế toán), Data Owner (Phòng IT), BA Lead (Trưởng nhóm Phân tích nghiệp vụ).
• Artifact (Sản phẩm):
  • Cập nhật quy tắc định dạng Product ID trong 01-curriculum/CANONICAL_DATA_DICTIONARY.md (Field: Product ID, Quy tắc: Định dạng 'NF-YY-NNNN', duy nhất).
  • Tạo mới một file NOVA-FOODS-DATA-VALIDATION-RULE.xlsx (dữ liệu tổng hợp) mô tả chi tiết quy tắc kiểm tra và xử lý ngoại lệ.
  • Ghi nhận lỗi này như một "Bài học kinh nghiệm" (Lesson Learned) trong /02-handbook/24-capstone-review-and-evaluation.md dưới phần "Những sai lầm phổ biến".
• Consequence if Wrong (Hậu quả nếu sai): Dữ liệu tồn kho không chính xác, báo cáo tài chính sai lệch, ảnh hưởng đến quyết định mua hàng và sản xuất. Nova Foods (mô phỏng) có thể đối mặt với rủi ro vi phạm Luật Kế toán của Việt Nam về quản lý tài sản, gây ra phạt hành chính và mất uy tín.

Senior Lens

Sai lầm trong việc xử lý dữ liệu Product ID của Nova Foods minh họa rủi ro về tính toàn vẹn dữ liệu (data integrity) và khả năng truy vết (traceability) xuyên suốt hệ thống ERP. Một BA cấp cao không chỉ nhận diện được sự thiếu sót này mà còn phải lường trước hậu quả dài hạn: chi phí bảo trì hệ thống tăng cao do phải liên tục xử lý ngoại lệ, mất niềm tin của người dùng vào hệ thống, và khả năng phát sinh vấn đề tuân thủ pháp luật. Việc xây dựng Capstone Review hiệu quả đòi hỏi sự chủ động trong việc xác định các điểm tích hợp dữ liệu quan trọng, thẩm định lại các quy tắc nghiệp vụ đã có và đảm bảo chúng được phản ánh chính xác trong thiết kế hệ thống. Luôn đặt câu hỏi về nguồn gốc dữ liệu, quy tắc chuyển đổi và mục tiêu cuối cùng của dữ liệu đó. Tránh "thả nổi" (ad-hoc) các vấn đề dữ liệu, vì chúng sẽ tích tụ và gây ra "nợ kỹ thuật" (technical debt) lớn hơn nhiều so với việc khắc phục sớm.

Quick Reference

Rủi ro thực tế (Real Risk)	Cờ đỏ (Red Flag) quan sát được	Nguyên nhân gốc (Root Cause)	Ranh giới phục hồi an toàn (Safe Recovery Boundary)
Dữ liệu Product ID không tuân thủ định dạng và không duy nhất	Báo cáo tồn kho có ngoại lệ, lỗi khi tạo đơn hàng, người dùng phàn nàn khó tra cứu.	Thiếu kiểm tra và xác nhận quy tắc nghiệp vụ Product ID giữa hệ thống cũ và ERP mới; thiếu quy trình chuyển đổi và xác thực dữ liệu chặt chẽ.	1. Dữ liệu: Product ID được chuẩn hóa theo NF-YY-NNNN. 2. Hệ thống: ERP từ chối nhập Product ID không hợp lệ hoặc không duy nhất. 3. Quy trình: Có quy trình tự động gắn cờ, xử lý ngoại lệ và thông báo cho Data Owner. 4. Pháp lý: Tuân thủ Luật Kế toán về mô tả hàng tồn kho (cho Nova Foods mô phỏng).
Mất khả năng truy vết (Traceability) đơn hàng/lô hàng	Khó khăn xác định nguồn gốc nguyên liệu hoặc điểm đến sản phẩm cuối cùng khi có sự cố.	Không ghi nhận đầy đủ thông tin về lô sản xuất, nguyên liệu đầu vào hoặc chuỗi cung ứng trong ERP.	1. Dữ liệu: Mọi giao dịch sản xuất/kho đều gắn Batch ID (Mã lô), Supplier ID (Mã nhà cung cấp), Customer ID (Mã khách hàng). 2. Quy trình: Có quy trình tra cứu ngược/xuôi dựa trên các ID này. 3. Pháp lý: Tuân thủ Luật An toàn thực phẩm (ví dụ: truy xuất nguồn gốc nông sản, sản phẩm chế biến cho Nova Foods mô phỏng).
Quyết định nghiệp vụ sai lệch do thông tin không đáng tin cậy	Ban quản lý ra quyết định dựa trên báo cáo không chính xác (ví dụ: sản xuất quá mức hoặc thiếu nguyên liệu).	Dữ liệu đầu vào không được kiểm soát chất lượng, thiếu logic kiểm tra chéo giữa các module, hệ thống không đồng bộ.	1. Báo cáo: Mọi báo cáo quan trọng có cơ chế kiểm tra chéo (ví dụ: đối chiếu số liệu tồn kho với kế toán). 2. Quy trình: Quy trình phê duyệt báo cáo bao gồm bước kiểm tra tính hợp lệ của dữ liệu nguồn. 3. Hệ thống: Dữ liệu giữa các module có cơ chế đồng bộ và xử lý xung đột rõ ràng.

Tách biệt lỗi Mơ hồ, Thiếu đủ, Tuyên bố thẩm quyền không xác thực, Lạm dụng ký pháp và Đứt gãy truy vết

BA mới gặp lỗi diễn đạt, thiếu kiểm soát. Hiểu loại lỗi, sửa nhanh, giữ dự án đi.

Core

Mỗi thông tin BA thu thập, phân tích, đặc tả phải rõ. Mơ hồ, thiếu, không bằng chứng, dùng sai ký pháp hoặc đứt truy vết: lỗi cơ bản, dẫn đến sai sót lớn.

Loại lỗi	Dấu hiệu nhận biết	Nguyên nhân gốc	Biện pháp khắc phục
Mơ hồ (Ambiguity)	Thuật ngữ không rõ, câu chung chung, không đo lường được (ví dụ: "nhanh", "dễ dùng", "linh hoạt"). Nhiều bên hiểu khác nhau.	BA không đào sâu, ngại hỏi "Tại sao?", "Như thế nào?". Chủ doanh nghiệp không cam kết chi tiết.	Hỏi "Cái gì chính xác?", "Đo lường bằng gì?". Dùng bảng quyết định. Giải thích thuật ngữ qua 05-glossary/.
Thiếu đủ (Incompleteness)	Thiếu kịch bản lỗi, trường dữ liệu, điều kiện, giới hạn. Dùng "v.v.", "trừ...", "TBD".	BA chỉ tập trung kịch bản chính, thiếu kiến thức nghiệp vụ sâu. Quy trình thu thập yêu cầu hời hợt.	Dùng checklist (ví dụ: INVEST). Phân tích kịch bản ngoại lệ. Đối chiếu CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES.
Tuyên bố thẩm quyền không xác thực (Unsupported Authority Claims)	Khẳng định "Theo quy định..." hoặc "Chính sách công ty là..." nhưng không có văn bản, số hiệu, ngày ban hành hoặc người phê duyệt cụ thể.	BA truyền đạt thông tin nghe được, không kiểm chứng. Thiếu hiểu biết về 00_SOURCE_MAP.	Luôn yêu cầu bằng chứng: "Văn bản nào? Phiên bản mấy? Ai phê duyệt?". Liên kết đến 00_SOURCE_MAP và CANONICAL_BUSINESS_RULES.
Lạm dụng ký pháp (Notation Misuse)	Dùng sai ký hiệu BPMN/UML (ví dụ: dùng ký hiệu luồng tin nhắn cho luồng điều khiển, vẽ không đúng chuẩn). Sơ đồ khó hiểu, không nhất quán.	BA không học chuẩn ký pháp (ví dụ: BPMN 2.0.2, UML 2.5.1). Tự ý sáng tạo biểu đồ.	Học và tuân thủ chuẩn ký pháp. Dùng công cụ hỗ trợ kiểm tra. Nhờ chuyên gia xem lại.
Đứt gãy truy vết (Traceability Breaks)	Yêu cầu không có ID duy nhất. Test case không trỏ về yêu cầu. Thay đổi một chỗ, chỗ khác không cập nhật. Không biết "Tại sao chức năng này có?".	Không dùng công cụ quản lý yêu cầu. Thiếu kỷ luật gắn ID. Coi truy vết là việc phụ.	Gán ID duy nhất cho mọi artifact theo TRACEABILITY_ID_REGISTRY. Dùng ma trận truy vết. Buộc phải liên kết.

Applied

Nova Foods ERP, module Quản lý Kho, gặp lỗi mơ hồ. Yêu cầu "hệ thống phải xử lý lô hàng nhanh chóng".

• Facts: Nova Foods có yêu cầu hệ thống "nhanh chóng" khi nhập lô hàng vào kho.
• Current Behavior: Hệ thống mất 15-30 giây xử lý mỗi lô hàng có 100+ mặt hàng. Kho cho là "chậm". Dev nói "đã nhanh rồi".
• Underlying Need: Kho cần nhập nhiều lô hàng mỗi giờ, tránh tắc nghẽn khi nhận hàng.
• Options:
  1. Tối ưu hóa hệ thống hiện tại, hy vọng nhanh hơn.
  2. Định nghĩa rõ "nhanh chóng" là gì.
  3. Tăng phần cứng máy chủ.
• Decision Criteria: Chi phí, thời gian triển khai, khả năng mở rộng. BA phải giảm mơ hồ trước.
• Decision: Chọn 2. BA làm việc với Kho để định nghĩa "nhanh chóng".
• Authority: Trưởng phòng Kho, Trưởng phòng IT.
• Artifact: Yêu cầu cập nhật NF-REQ-WH-005 trong /02-handbook/24-capstone-review-and-evaluation.md đổi từ "Hệ thống phải xử lý lô hàng nhanh chóng" thành "Hệ thống phải xử lý lô hàng nhập kho (có đến 100 mặt hàng) trong vòng 5 giây đối với 95% các giao dịch trong giờ cao điểm (13:00 - 15:00 hàng ngày, theo múi giờ Asia/Ho_Chi_Minh)". Cập nhật CANONICAL_BUSINESS_RULES với rule BR-WH-003.
• Consequence if Wrong: Tiếp tục tranh cãi "nhanh hay chậm", tốn thời gian tối ưu không hiệu quả, hoặc mua phần cứng không cần thiết, làm chậm quy trình nhận hàng thực tế, ảnh hưởng đến chuỗi cung ứng Nova Foods.

Senior Lens

BA kinh nghiệm không để những lỗi này kéo dài. Họ chủ động tìm kiếm, ngăn chặn.

• Ngăn ngừa mơ hồ: BA dùng ngôn ngữ cụ thể, số liệu. Dùng ví dụ. Tạo 05-glossary/ cho thuật ngữ chuyên ngành Nova Foods. Dùng bản mẫu có cấu trúc để định nghĩa yêu cầu (ví dụ: GEN-TMPL-REQ-001).
• Kiểm tra tính đủ: BA dùng checklists, khung phân tích (ví dụ: PESTLE, SWOT, 5 Whys), đảm bảo bao quát mọi khía cạnh. Luôn hỏi "Còn gì nữa không?".
• Yêu cầu bằng chứng: BA không ngại hỏi nguồn gốc pháp lý, chính sách, quyết định. Mỗi yêu cầu phải có tham chiếu cụ thể đến 00_SOURCE_MAP hoặc quyết định của Business Owner.
• Tuân thủ ký pháp: BA dùng công cụ chuẩn. Hiểu ý nghĩa từng ký hiệu. Kiểm tra chéo với chuẩn quốc tế (ví dụ: BPMN 2.0.2, UML 2.5.1).
• Xây dựng truy vết: Ngay từ đầu, BA thiết lập cấu trúc ID theo TRACEABILITY_ID_REGISTRY. Yêu cầu mọi tài liệu phải liên kết. Truy vết không phải việc cuối cùng, là nền tảng.

Quick Reference

Lỗi	Ngăn chặn chính	Tài liệu liên quan
Mơ hồ	Định nghĩa rõ, dùng số liệu, ví dụ.	05-glossary/, GEN-TMPL-REQ-001
Thiếu đủ	Checklists, phân tích kịch bản đầy đủ.	CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES
Thẩm quyền không xác thực	Yêu cầu bằng chứng nguồn gốc.	00_SOURCE_MAP, CANONICAL_BUSINESS_RULES
Lạm dụng ký pháp	Tuân thủ chuẩn quốc tế.	BPMN 2.0.2, UML 2.5.1
Đứt gãy truy vết	Gán ID duy nhất, xây ma trận.	TRACEABILITY_ID_REGISTRY

11. Senior BA Notes & Rules of Thumb

Senior Lens

BA cấp cao nhìn vấn đề qua lăng kính phân tích sâu, không chỉ mô tả bề mặt. Họ hiểu rằng mọi quyết định có rủi ro, yêu cầu bằng chứng và thẩm quyền rõ ràng.

• Đánh đổi (Trade-offs): BA cấp cao luôn nhận diện các điểm đánh đổi. Không có giải pháp "tối ưu tuyệt đối", chỉ có giải pháp phù hợp nhất trong bối cảnh cụ thể.
  • Phân tích: Cân nhắc giữa các yếu tố cạnh tranh như chi phí, thời gian, chất lượng, rủi ro, khả năng mở rộng. Ví dụ tại Nova Foods, việc ưu tiên "triển khai nhanh tính năng khuyến mãi" (tốc độ) có thể dẫn đến "giảm chi tiết trong kiểm tra dữ liệu đầu vào" (chất lượng dữ liệu), tăng rủi ro sai sót tồn kho hoặc báo cáo tài chính.
  • Bằng chứng/Lý do: Các phân tích lợi ích-chi phí (Cost-Benefit Analysis), đánh giá rủi ro (Risk Assessment) và ma trận quyết định. Ghi nhận rõ các giả định (assumptions) và ràng buộc (constraints).
• Ngoại lệ (Exceptions): Quy tắc nghiệp vụ (Business Rules) luôn tồn tại ngoại lệ. BA cấp cao chủ động tìm kiếm và ghi nhận chúng một cách rõ ràng, tránh để mặc định hoặc suy đoán.
  • Phân tích: Không chỉ ghi "luật chung", mà còn hỏi "có trường hợp nào khác biệt không?". Ví dụ tại Nova Foods, quy tắc "mọi khoản chi trên 20 triệu VND phải qua ba cấp phê duyệt" có thể có ngoại lệ "mua nguyên liệu khẩn cấp theo hợp đồng khung đã ký".
  • Bằng chứng/Lý do: Phát hiện qua phỏng vấn chuyên sâu với các Subject Matter Experts (SMEs - chuyên gia nghiệp vụ) có kinh nghiệm, phân tích các trường hợp sử dụng (use cases) biên hoặc dữ liệu giao dịch lịch sử.
• Xung đột Bên liên quan (Stakeholder Conflict): Các bên liên quan (stakeholders) thường có mục tiêu, ưu tiên khác nhau, dẫn đến xung đột. BA cấp cao đứng ở vị trí trung lập, không "chọn phe", mà làm rõ các quan điểm, hậu quả và tạo điều kiện để các bên ra quyết định.
  • Phân tích: Ví dụ tại Nova Foods, nhóm Bán hàng muốn tính năng "thay đổi giá linh hoạt trên đơn hàng" để đáp ứng khách hàng, trong khi nhóm Kế toán muốn "giá cố định, mọi thay đổi phải có phê duyệt chặt chẽ". BA trình bày cả hai yêu cầu, minh bạch hóa điểm mâu thuẫn và tác động đến các quy trình khác.
  • Bằng chứng/Lý do: Ma trận ảnh hưởng-quan tâm (Influence-Interest Matrix), phân tích yêu cầu từ các nhóm, lập sơ đồ quy trình hiện tại và đề xuất, chỉ rõ điểm va chạm. Dùng RACI matrix để làm rõ trách nhiệm.
• Chất lượng Bằng chứng (Evidence Quality): Mọi khuyến nghị hoặc yêu cầu phải dựa trên bằng chứng tin cậy. BA cấp cao đánh giá nguồn thông tin. Không thể xây giải pháp trên suy đoán hoặc bằng chứng yếu.
  • Phân tích: Nguồn pháp lý (Luật Bảo vệ dữ liệu cá nhân Luật 91/2025/QH15), các tiêu chuẩn ngành (ISO, OWASP), hoặc hợp đồng đã ký kết là bằng chứng chất lượng cao. Email cá nhân, tin đồn, hoặc suy đoán cá nhân là bằng chứng chất lượng thấp.
  • Bằng chứng/Lý do: Tham chiếu các nguồn đã được xác minh trong /00-research/00_SOURCE_MAP.md. Yêu cầu các bên liên quan cung cấp nguồn gốc chính thức của thông tin.
• Thẩm quyền Quyết định (Decision Authority): BA cấp cao hiểu rõ giới hạn thẩm quyền của mình. Không tự đưa ra các quyết định nghiệp vụ, mà làm rõ ai là người có quyền quyết định cuối cùng cho từng vấn đề. Thực hiện escalation (leo thang) khi vấn đề vượt quá thẩm quyền hoặc không thể giải quyết ở cấp hiện tại.
  • Phân tích: Tại Nova Foods, BA có thể đề xuất các tùy chọn cho quy trình phê duyệt đơn hàng, nhưng Kế toán trưởng hoặc Giám đốc Điều hành mới có thẩm quyền ra quyết định cuối cùng.
  • Bằng chứng/Lý do: Dựa vào cơ cấu tổ chức, biểu đồ phân quyền, RACI matrix của dự án, và chính sách nội bộ của Nova Foods. Luôn ghi nhận quyết định và người ra quyết định vào các artifact liên quan (ví dụ: /01-curriculum/TRACEABILITY_ID_REGISTRY.md cho các ID hoặc /01-curriculum/CANONICAL_BUSINESS_RULES.md cho các quy tắc nghiệp vụ).

Senior Lens

Senior BA review Capstone: tìm rủi ro, tối ưu giá trị. Không chỉ kiểm checklist. Tập trung vào logic, khả thi, giá trị nghiệp vụ (business value), rủi ro.

Nguyên tắc phán đoán (Heuristics):

• Logic nhất quán: Giải pháp, yêu cầu (requirement), artifact khớp nhau. Truy vết (traceability) rõ ràng: từ cần (need) đến giải pháp, kiểm thử (test).
• Tính khả thi (Feasibility): Thực tế nguồn lực (ngân sách, người), công nghệ. Không chỉ nói "cái gì" mà phải có "làm thế nào".
• Giá trị nghiệp vụ: Lợi ích so với chi phí. Có giải quyết vấn đề cốt lõi Nova Foods không? Tránh giải pháp không mang lại lợi ích rõ ràng.
• Tính đầy đủ (Completeness): Bao quát mọi trường hợp, kể cả trường hợp ngoại lệ (edge cases). Không chỉ đường đi "happy path".
• Rõ ràng (Clarity): Mọi bên liên quan hiểu. Không mơ hồ.

Dấu hiệu nguy hiểm (Red Flags) — Cảnh báo, cần kiểm tra sâu:

Dấu hiệu	Mô tả	Hậu quả tiềm tàng
Yêu cầu mơ hồ	"Hệ thống dễ dùng," "báo cáo nhanh." Không định lượng.	Giải pháp sai, tốn kém, không đáp ứng.
Thiếu chủ sở hữu	Yêu cầu, quyết định, artifact không có người chịu trách nhiệm chính.	Quyết định không được thực thi, mâu thuẫn không giải quyết.
Mâu thuẫn dữ liệu	Giữa các tài liệu (ví dụ: /01-curriculum/CANONICAL_BUSINESS_RULES.md và tài liệu thiết kế), giữa các bên.	Triển khai sai, gây lỗi, tốn công sửa.
Phình to phạm vi (Scope Creep)	Yêu cầu mới liên tục mà không đánh giá tác động.	Trễ tiến độ, vượt ngân sách, chất lượng giảm.
Kế hoạch thiếu thực tế	Lịch trình quá lạc quan, không đủ thời gian, không có dự phòng.	Burnout nhóm, sản phẩm lỗi, thất bại dự án.
Thiếu truy vết	Không liên kết được yêu cầu, thiết kế, kiểm thử.	Không biết giải pháp đáp ứng yêu cầu nào, kiểm thử thiếu.
Chất lượng bằng chứng kém	Quyết định dựa trên suy đoán yếu, dữ liệu không đáng tin.	Quyết định sai, rủi ro cao.
Bỏ qua ràng buộc	Không tính đến ràng buộc pháp lý (Luật 91/2025/QH15) hoặc kỹ thuật.	Vi phạm pháp luật, hệ thống không hoạt động.

Ngưỡng leo thang (Escalation Thresholds) — Khi cần báo cáo cấp cao:

Tình huống	Ngưỡng kích hoạt	Lý do leo thang
Mâu thuẫn không giải quyết	Hai bên trở lên không đồng ý, BA không dàn xếp được.	Ảnh hưởng quyết định chính, đình trệ dự án.
Thay đổi phạm vi lớn	Thay đổi ảnh hưởng >10% chi phí, thời gian, tài nguyên.	Cần phê duyệt cấp cao, điều chỉnh kế hoạch tổng thể.
Rủi ro pháp lý/tuân thủ	Giải pháp vi phạm Luật 88/2015/QH13 (Kế toán), Luật 91/2025/QH15 (Dữ liệu cá nhân), hoặc quy định nội bộ Nova Foods.	Tránh phạt, ảnh hưởng uy tín công ty.
Hạn chế kỹ thuật nghiêm trọng	Công nghệ không đáp ứng yêu cầu cốt lõi, không có giải pháp thay thế.	Cần quyết định kiến trúc cấp cao, thay đổi hướng đi.
Mất giá trị nghiệp vụ	Giải pháp không còn mang lại lợi ích kinh doanh như kỳ vọng ban đầu.	Dự án không có ý nghĩa, lãng phí tài nguyên.
Tác động liên chức năng	Quyết định ảnh hưởng nhiều phòng ban, cần sự thống nhất toàn diện.	Đảm bảo tính toàn vẹn hệ thống, quy trình nghiệp vụ tổng thể.

Trường hợp ngoại lệ quy tắc thường (Exceptions to Normal Rules):

• Tình huống khẩn cấp: Khủng hoảng, cần phản ứng nhanh. Quy trình chuẩn quá chậm. Ví dụ: Nova Foods cần khắc phục lỗ hổng bảo mật nghiêm trọng ngay. Làm giải pháp tạm thời, ghi lại nợ kỹ thuật (technical debt), hoàn thiện sau.
• Đánh giá PoC (Proof of Concept) / Thử nghiệm: Mục tiêu học hỏi, không phải sản phẩm cuối. Giảm bớt thủ tục, tập trung thu thập phản hồi nhanh.
• Thay đổi nhỏ, biệt lập: Tác động hạn chế. Áp dụng quy trình tinh gọn (streamlined process). Vẫn phải ghi nhận, nhưng không cần qua mọi bước rườm rà.
• Hạn chót pháp lý/quy định (Regulatory Deadline): Không thể thương lượng. Ưu tiên tuân thủ dù giải pháp chưa tối ưu hoàn hảo.
• Không chắc chắn cao (High Uncertainty): Thị trường mới, công nghệ chưa trưởng thành. Áp dụng cách tiếp cận linh hoạt (agile), điều chỉnh liên tục.

Ghi nhận Khuyến nghị Không Chắc Chắn

BA gặp không chắc chắn: thông tin thiếu, dữ liệu không đủ, quan điểm khác biệt. Không được bịa đặt chắc chắn. BA nói sự thật.

1. Ngôn ngữ Chính xác Dùng từ ngữ định lượng, tránh mơ hồ. * "Ước tính X-Y%": Khi có dải giá trị. * "Khả năng cao/thấp": Nêu rõ bằng chứng hỗ trợ. * "Dựa trên dữ liệu A": Luôn chỉ nguồn. * "Phụ thuộc điều kiện B": Xác định yếu tố phụ thuộc. * "Rủi ro C có thể xảy ra": Xác định rủi ro tiềm ẩn.

2. Cấu trúc Khuyến nghị Phòng thủ (Defensible Recommendation) Mọi khuyến nghị cần minh bạch bằng chứng, điều kiện, rủi ro.

Mục	Mô tả
Vấn đề	Mô tả rõ vấn đề/cơ hội. BA xác định.
Bằng chứng	Liệt kê nguồn tham khảo: SRC-LAW-91-2025 (Luật Bảo vệ dữ liệu cá nhân), NF-INT-PHAPCHE-001 (biên bản phỏng vấn Pháp chế Nova Foods mô phỏng), báo cáo NF-RISK-ASSESS-003 (đánh giá rủi ro nội bộ Nova Foods mô phỏng).
Chất lượng Bằng chứng	Đánh giá độ tin cậy nguồn: cao, trung bình, thấp, cần xác minh thêm. Ví dụ: NF-INT-PHAPCHE-001 là "trung bình", cần xác nhận chính thức.
Các Lựa chọn	Liệt kê các phương án khả thi. Đề xuất tối thiểu hai.
Ưu/Nhược điểm	Phân tích mặt lợi, hại mỗi lựa chọn.
Tiêu chí Quyết định	Định nghĩa các yếu tố sẽ dùng để đánh giá lựa chọn: tuân thủ (ví dụ: Luật 91/2025/QH15), chi phí tổng thể (TCO), thời gian triển khai, rủi ro (ví dụ: OWASP ASVS 5.0).
Đánh giá	So sánh các lựa chọn theo từng tiêu chí đã nêu.
Khuyến nghị	Đề xuất giải pháp tối ưu trong điều kiện không chắc chắn. Có thể là "ít rủi ro nhất" hoặc "phù hợp nhất".
Điều kiện/Giả định	Ghi rõ các yếu tố phải đúng để khuyến nghị có hiệu lực. Ví dụ: "Nếu phòng Pháp chế phê duyệt diễn giải pháp lý".
Rủi ro Còn lại	Rủi ro vẫn tồn tại sau khi thực hiện khuyến nghị.
Bước Tiếp theo	Các hành động cần làm để giảm sự không chắc chắn hoặc xác nhận giả định. Ví dụ: "Yêu cầu Phòng Pháp chế xác nhận chính thức".
Thẩm quyền Quyết định	Xác định vai trò sẽ ra quyết định cuối cùng. BA chỉ cung cấp thông tin, không quyết định.

3. Ví dụ Nova Foods (mô phỏng): Quyết định lưu trữ dữ liệu khách hàng mới

Vấn đề: Nova Foods (mô phỏng) cần hệ thống lưu trữ dữ liệu khách hàng mới. Yêu cầu tuân thủ Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15.

Bằng chứng: * Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 (SRC-LAW-91-2025) * Biên bản phỏng vấn sơ bộ Pháp chế Nova Foods (mô phỏng) (NF-INT-PHAPCHE-001) * Báo giá sơ bộ nhà cung cấp Cloud A và giải pháp On-premise B (giả định) (NF-QUOTE-CLOUD-A-01, NF-QUOTE-ONPREM-B-01) * OWASP ASVS 5.0 (Tham khảo tiêu chí bảo mật ứng dụng)

Chất lượng Bằng chứng: Pháp luật "cao". Phỏng vấn Pháp chế "trung bình" (chưa phải văn bản chính thức). Báo giá sơ bộ "thấp" (chưa thương lượng).

Các Lựa chọn: 1. On-premise: Dữ liệu đặt trên máy chủ nội bộ Nova Foods (mô phỏng). 2. Cloud trong nước: Dữ liệu lưu trữ tại Cloud Provider A, đặt tại Việt Nam.

Tiêu chí Quyết định (theo thứ tự ưu tiên): 1. Tuân thủ pháp luật (Luật 91/2025/QH15): Mức độ chắc chắn khi kiểm toán. 2. An toàn bảo mật: Theo tiêu chuẩn ASVS L1. 3. Chi phí tổng thể (TCO): Chi phí 3 năm. 4. Thời gian triển khai.

Đánh giá: * On-premise: Chắc chắn tuân thủ cao (kiểm soát hoàn toàn hạ tầng). Bảo mật phụ thuộc năng lực IT nội bộ. TCO cao hơn. Thời gian triển khai lâu. * Cloud trong nước: Tuân thủ cần Phòng Pháp chế Nova Foods xác nhận cụ thể việc "xử lý dữ liệu bởi bên thứ ba" và "chuyển giao dữ liệu ra nước ngoài" (nếu có sub-processor). Bảo mật dựa vào SLA và chứng nhận nhà cung cấp (cần đánh giá ASVS). TCO thấp hơn. Triển khai nhanh.

Khuyến nghị: Nova Foods (mô phỏng) nên ưu tiên lựa chọn Cloud trong nước cho hệ thống dữ liệu khách hàng mới. Khuyến nghị này có điều kiện tiên quyết là Phòng Pháp chế Nova Foods (mô phỏng) xác nhận chính thức tính tuân thủ pháp luật của mô hình này theo Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15. Đồng thời, Phòng An ninh thông tin Nova Foods (mô phỏng) cần phê duyệt chính sách bảo mật của Cloud Provider A, xác nhận tuân thủ ASVS L1.

Điều kiện/Giả định: * Phòng Pháp chế Nova Foods (mô phỏng) ban hành văn bản xác nhận diễn giải luật. * Cloud Provider A cung cấp đủ bằng chứng ASVS L1 hoặc tương đương.

Rủi ro Còn lại: * Chi phí Cloud tăng ngoài dự kiến nếu khối lượng dữ liệu phát sinh quá nhanh. * Pháp luật có thay đổi diễn giải, đòi hỏi điều chỉnh hệ thống.

Bước Tiếp theo: 1. Pháp chế: Văn bản xác nhận diễn giải Luật 91/2025/QH15 cho Cloud trong nước. (REQ-NF-LEGAL-CONFIRM-001) 2. An ninh thông tin: Đánh giá chi tiết báo cáo bảo mật của Cloud Provider A, xác nhận tuân thủ ASVS L1. (REQ-NF-SECURITY-ASSESS-001) 3. Mua sắm: Yêu cầu báo giá và SLA chính thức từ Cloud Provider A. (REQ-NF-PROCURE-CLOUD-001)

Thẩm quyền Quyết định: Giám đốc Điều hành Nova Foods (mô phỏng) và Trưởng phòng Pháp chế Nova Foods (mô phỏng).

12. Associated Template Reference & Completed Artifact

Quick Reference

Mỗi template (mẫu tài liệu) là một công cụ chuẩn hóa, giúp Business Analyst (BA) thu thập, phân tích và trình bày thông tin nghiệp vụ một cách nhất quán. Việc sử dụng template đúng cách đảm bảo chất lượng đầu ra, giảm thiểu sai sót và tăng cường sự phối hợp giữa các bên liên quan. Bảng dưới đây cung cấp tổng quan nhanh về các template cốt lõi cho dự án Nova Foods (mô phỏng), bao gồm mục đích, giới hạn, chủ sở hữu, người tiêu thụ và cổng chất lượng.

Mã ID Template	Tên Tệp / Đường dẫn	Mục đích sử dụng	Không sử dụng khi	Chủ sở hữu (Owner)	Người tiêu thụ (Consumers)	Cổng chất lượng (Quality Gate)
GEN-TMPL-001	/03-templates/NF_BRD_v1.0_Vi.docx	Tài liệu Đặc tả Yêu cầu Nghiệp vụ (Business Requirement Document - BRD). Ghi lại các yêu cầu chức năng (functional requirements), phi chức năng (non-functional requirements) và yêu cầu nghiệp vụ (business requirements) của Nova Foods (mô phỏng).	Mô tả chi tiết kỹ thuật của giải pháp công nghệ; thay thế tài liệu thiết kế hệ thống (System Design Document - SDD).	BA chính	Business Owner, Kiến trúc sư Giải pháp (Solution Architect - SA), Đội Phát triển (Development Team), Đội Đảm bảo Chất lượng (Quality Assurance - QA).	Yêu cầu phải rõ ràng, kiểm thử được (testable); BA chính và Business Owner của Nova Foods (mô phỏng) phê duyệt bằng văn bản (REQ-NF-BOSIGN-001).
GEN-TMPL-002	/03-templates/NF_BPMN_Process_v1.0_Vi.bpmn	Mô hình Quy trình Nghiệp vụ (Business Process Model) sử dụng chuẩn BPMN 2.0.2 (Business Process Model and Notation). Minh họa luồng công việc hiện tại (As-Is) và luồng công việc tương lai (To-Be) của các quy trình nghiệp vụ Nova Foods (mô phỏng).	Mô tả logic điều kiện cấp thấp trong mã nguồn; thay thế sơ đồ trạng thái (State Diagram) hoặc sơ đồ luồng dữ liệu (Data Flow Diagram).	BA chính, Chuyên gia Nghiệp vụ (Subject Matter Expert - SME)	Business Owner, SA, QA.	Phản ánh chính xác quy trình nghiệp vụ thực tế hoặc mong muốn; tuân thủ các quy tắc mô hình hóa BPMN 2.0.2; được SME của Nova Foods (mô phỏng) xác nhận.
GEN-TMPL-003	/03-templates/NF_DataDict_v1.0_Vi.xlsx	Từ điển Dữ liệu (Data Dictionary). Định nghĩa chi tiết các trường dữ liệu quan trọng, kiểu dữ liệu (data type), ràng buộc (constraints), giá trị hợp lệ (valid values) và mối quan hệ. Liên kết với /01-curriculum/CANONICAL_DATA_DICTIONARY.md.	Ghi nhận cấu trúc cơ sở dữ liệu vật lý (physical database structure); thay thế mô hình dữ liệu quan hệ (Entity-Relationship Diagram - ERD).	BA chính, Kiến trúc sư Dữ liệu (Data Architect)	SA, Đội Phát triển, QA, Người quản lý dữ liệu (Data Steward).	Tất cả các trường dữ liệu liên quan được định nghĩa đầy đủ, nhất quán; tuân thủ các quy tắc nghiệp vụ trong /01-curriculum/CANONICAL_BUSINESS_RULES.md; được Data Steward của Nova Foods (mô phỏng) xác nhận.
GEN-TMPL-004	/03-templates/NF_Traceability_Matrix_v1.0_Vi.xlsx	Ma trận Truy vết (Traceability Matrix). Liên kết yêu cầu nghiệp vụ (Business Requirements), yêu cầu hệ thống (System Requirements), thiết kế, test case (kiểm thử) và các tính năng của Nova Foods (mô phỏng).	Quản lý dự án tổng thể (project management); quản lý tác vụ hàng ngày (daily task management).	BA chính, QA	QA, Quản lý Dự án (Project Manager - PM), BA.	Mọi yêu cầu đã được ghi nhận đều có ít nhất một liên kết truy vết ngược và một liên kết truy vết xuôi; bao quát toàn bộ phạm vi dự án; QA kiểm tra và phê duyệt.
GEN-TMPL-005	/03-templates/NF_Acceptance_Criteria_v1.0_Vi.docx	Định nghĩa các Tiêu chí Chấp nhận (Acceptance Criteria) cho từng yêu cầu hoặc user story (câu chuyện người dùng). Dùng làm cơ sở cho Kiểm thử Chấp nhận Người dùng (User Acceptance Testing - UAT) tại Nova Foods (mô phỏng).	Danh sách các bước kiểm thử chi tiết (test steps); kịch bản kiểm thử (test script) cụ thể.	BA chính, Chủ sản phẩm (Product Owner)	QA, Business Owner, Đội Phát triển.	Các tiêu chí phải rõ ràng, đo lường được, cụ thể; đủ để xác định thành công hay thất bại của tính năng; Product Owner của Nova Foods (mô phỏng) phê duyệt.

Việc lựa chọn và áp dụng các template này cần dựa trên giai đoạn dự án, độ phức tạp của nghiệp vụ và loại hình giải pháp. Mỗi template không chỉ là biểu mẫu, mà là một công cụ tư duy, giúp BA cấu trúc hóa thông tin và truyền đạt hiệu quả. Luôn tham khảo các bản mẫu mới nhất và hướng dẫn sử dụng trong thư mục /03-templates/ của corpus Nova Foods (mô phỏng).

Danh mục tra cứu chương và vị trí Artifact Nova Foods

Phần này cung cấp danh sách đầy đủ các chương trong handbook cùng vị trí tệp, giúp người học tra cứu nhanh. Đồng thời, nó chỉ rõ vị trí của một artifact Nova Foods mô phỏng đã hoàn chỉnh, minh họa kết quả của quy trình đánh giá Capstone.

1. Danh sách kiểm tra tra cứu chương Handbook

Bảng dưới liệt kê tất cả 26 chương thuộc handbook chính, cùng định danh (Chapter ID), tiêu đề (Tiêu đề chương) và đường dẫn tệp (Đường dẫn tệp handbook). Đây là nguồn kiểm soát chính để xác định vị trí từng chapter trong cấu trúc curriculum.

Chapter ID	Tiêu đề chương	Đường dẫn tệp handbook
CHAP-01	1. Concept l? g??	/02-handbook/01-concept-la-gi.md
CHAP-02	2. T?i sao concept n?y t?n t?i?	/02-handbook/02-tai-sao-concept-nay-ton-tai.md
CHAP-03	3. V? tr? trong Lifecycle	/02-handbook/03-vi-tri-trong-lifecycle.md
CHAP-04	4. Input c?n thi?t	/02-handbook/04-input-can-thiet.md
CHAP-05	5. Step-by-step BA Activities	/02-handbook/05-step-by-step-ba-activities.md
CHAP-06	6. Output thu ???c	/02-handbook/06-output-thu-duoc.md
CHAP-07	7. Who consumes those outputs?	/02-handbook/07-who-consumes-those-outputs.md
CHAP-08	8. Detailed Worked Example	/02-handbook/08-detailed-worked-example.md
CHAP-09	9. Related Concepts & Dependencies	/02-handbook/09-related-concepts-dependencies.md
CHAP-10	10. Common Mistakes & Anti-patterns	/02-handbook/10-common-mistakes-anti-patterns.md
CHAP-11	11. Senior BA Notes & Rules of Thumb	/02-handbook/11-senior-ba-notes-rules-of-thumb.md
CHAP-12	12. Associated Template Reference & Completed Artifact	/02-handbook/12-associated-template-reference-completed-artifact.md
CHAP-13	13. Concept l? g?? (Ph?n 2)	/02-handbook/13-concept-la-gi-phan-2.md
CHAP-14	14. T?i sao concept n?y t?n t?i? (Ph?n 2)	/02-handbook/14-tai-sao-concept-nay-ton-tai-phan-2.md
CHAP-15	15. V? tr? trong Lifecycle (Ph?n 2)	/02-handbook/15-vi-tri-trong-lifecycle-phan-2.md
CHAP-16	16. Input c?n thi?t (Ph?n 2)	/02-handbook/16-input-can-thiet-phan-2.md
CHAP-17	17. Step-by-step BA Activities (Ph?n 2)	/02-handbook/17-step-by-step-ba-activities-phan-2.md
CHAP-18	18. Output thu ???c (Ph?n 2)	/02-handbook/18-output-thu-duoc-phan-2.md
CHAP-19	19. Who consumes those outputs? (Ph?n 2)	/02-handbook/19-who-consumes-those-outputs-phan-2.md
CHAP-20	20. Detailed Worked Example (Ph?n 2)	/02-handbook/20-detailed-worked-example-phan-2.md
CHAP-21	21. Related Concepts & Dependencies (Ph?n 2)	/02-handbook/21-related-concepts-dependencies-phan-2.md
CHAP-22	22. Common Mistakes & Anti-patterns (Ph?n 2)	/02-handbook/22-common-mistakes-anti-patterns-phan-2.md
CHAP-23	23. Senior BA Notes & Rules of Thumb (Ph?n 2)	/02-handbook/23-senior-ba-notes-rules-of-thumb-phan-2.md
CHAP-24	24. Capstone Review And Evaluation	/02-handbook/24-capstone-review-and-evaluation.md
CHAP-25	25. Tổng kết và các bước tiếp theo	/02-handbook/25-tong-ket-va-cac-buoc-tiep-theo.md
CHAP-26	26. Thuật ngữ và từ viết tắt	/02-handbook/26-thuat-ngu-va-tu-viet-tat.md

2. Vị trí Artifact Nova Foods Capstone đã hoàn chỉnh

Artifact mô phỏng dưới đây đại diện cho báo cáo đánh giá Capstone đã hoàn thiện cho dự án ERP Nova Foods. Artifact này tạo ra từ việc áp dụng nguyên tắc, hoạt động BA thảo luận trong chapter 24-capstone-review-and-evaluation.md. Mục đích là cung cấp ví dụ cụ thể về output mà Business Analyst có thể tạo sau khi thực hiện quá trình đánh giá cuối kỳ.

• Định danh Artifact (Artifact ID): NF-ART-CAP-20260807-V0.1
• Tên Artifact: Báo cáo Đánh giá Capstone Dự án Nova Foods ERP
• Mô tả: Báo cáo tổng hợp phát hiện, khuyến nghị, kết quả đánh giá cuối kỳ cho hệ thống ERP mô phỏng của Nova Foods, phiên bản v0.1, hoàn thành ngày 2026-08-07. Dữ liệu trong báo cáo là tổng hợp, không phản ánh hoạt động thực tế.
• Đường dẫn tệp: /02-handbook/24-capstone-review-and-evaluation/nova-foods-artifacts/NF_Capstone_ERP_Evaluation_Report_2026-08-07_v0.1.md
• Trạng thái: SYNTHETIC_COMPLETED (Mô phỏng đã hoàn thành)
• Phiên bản: v0.1

Đánh giá chéo và Vấn đề cần xác minh

Trước bàn giao chương, cần rà soát chéo, xác định vấn đề mở, yêu cầu xác minh. Bảng dưới liệt kê những mục cần chú ý, lý do và vai trò chịu trách nhiệm leo thang (escalation owner) nếu vấn đề chưa được giải quyết.

Mục kiểm tra	Mô tả vấn đề mở / Yêu cầu xác minh	Chủ sở hữu leo thang
Trạng thái Corpus chung	Toàn bộ các artifact nguồn (00_SOURCE_MAP, 01_CURRICULUM_ARCHITECTURE, CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY) trạng thái IN_REVIEW, phiên bản v0.9.0. Corpus chưa baseline, chưa phê duyệt.	Principal IT Business Analyst / Technical Curriculum Author (tính nhất quán tài liệu đào tạo); Business Owner, Legal Owner, Accounting Owner, Security Owner, Architect, Compliance Officer (mọi quyết định nghiệp vụ, pháp lý, kế toán, bảo mật, kiến trúc)
Phạm vi Nova Foods	Mọi dữ liệu, quy tắc, quy trình Nova Foods chỉ là mô phỏng giáo dục. Không phải yêu cầu nghiệp vụ thực, cam kết pháp lý hoặc cấu hình ERP đang hoạt động.	Business Owner, Legal Owner, Accounting Owner, Compliance Officer (nếu Nova Foods bị hiểu là thực tế vận hành)
Tính toàn vẹn ID/Dữ liệu	Mọi ID mới hoặc thay đổi ID hiện có trong chương này phải tuân thủ TRACEABILITY_ID_REGISTRY. Cần kiểm tra trùng lặp ID, xung đột đặt tên, hoặc tham chiếu ID không tồn tại.	Technical Architect, Data Owner, Principal IT Business Analyst / Technical Curriculum Author (tính nhất quán định danh hệ thống)
Giải thích pháp lý/kế toán	Các tham chiếu luật pháp (Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm) chỉ dùng minh họa học liệu. Không thay thế diễn giải pháp lý chính thức.	Legal Owner, Accounting Owner, Compliance Officer (mọi diễn giải nguồn pháp lý/kế toán)
Artifact Nova Foods hoàn thiện	Artifact hoàn thiện như Nova Foods ERP Capstone Review Summary v0.9.0.docx cần xem xét nội dung. Đảm bảo khớp mục tiêu học liệu. Không được đưa ra quyết định nghiệp vụ ngoài thẩm quyền chương.	Principal IT Business Analyst / Technical Curriculum Author (tính đúng đắn artifact mô phỏng); Business Owner (nếu artifact bị hiểu thành yêu cầu nghiệp vụ thực)
Xác minh chéo	Bất kỳ phát hiện mâu thuẫn nào giữa các artifact nguồn hoặc giữa chương này với các chapter khác cần được ghi nhận.	Principal IT Business Analyst / Technical Curriculum Author (quản lý mâu thuẫn học liệu); vai trò chuyên môn liên quan (nếu mâu thuẫn về chuyên môn)