25 AI Assisted BA Workflow

Metadata Quản trị Tài liệu

Trường kiểm soát	Giá trị
Artifact ID	25_AI_ASSISTED_BA_WORKFLOW
Tên tệp	/02-handbook/25-ai-assisted-ba-workflow.md
Tiêu đề	25 AI Assisted BA Workflow
Trạng thái	IN_REVIEW
Ý nghĩa trạng thái	Nội dung đang được rà soát. Không được dùng trạng thái này làm bằng chứng baseline, approval, xác nhận requirement Nova Foods, hoặc quyền sử dụng production.
Thẩm quyền thay đổi trạng thái	Owner duy trì metadata và lịch sử thay đổi. Owner không có quyền tự thiết lập baseline hoặc ghi nhận approval. Mọi thay đổi trạng thái phải có tham chiếu quản trị corpus Nova Foods khi tham chiếu đó tồn tại.
Phiên bản	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Trách nhiệm Owner	Duy trì tính nhất quán chapter. Kiểm soát định danh artifact, đường dẫn tệp, version, metadata. Bảo toàn liên kết quản trị curriculum architecture. Ghi nhận thay đổi theo cơ chế kiểm soát corpus Nova Foods.
Giới hạn thẩm quyền Owner	Owner không có quyền tự thiết lập baseline. Không ghi nhận approval. Không phê chuẩn nội dung chapter. Không xác nhận requirement Nova Foods. Không diễn giải pháp lý, quyết định kế toán, thuế. Không cho phép sử dụng production.
Last updated date	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale áp dụng	vi-VN; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND
Case study	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	Handbook Chapter
Trạng thái tham chiếu baseline	Chưa có baseline reference tại v0.9.0; IN_REVIEW không được diễn giải là BASELINED.
Trạng thái tham chiếu approval	Chưa có approval reference tại v0.9.0; không có approval ngầm định từ việc Owner duy trì artifact hoặc từ sự tồn tại của metadata này.

Lịch sử phiên bản	Ngày cập nhật	Trạng thái	Người chịu trách nhiệm	Nội dung và lý do
v0.9.0	2026-08-07	IN_REVIEW	Principal IT Business Analyst / Technical Curriculum Author	Ghi nhận phiên bản đang rà soát của handbook chapter. Metadata kiểm soát artifact, trạng thái, phiên bản, ranh giới thẩm quyền, baseline và approval được duy trì để người tiêu thụ phân biệt nội dung giáo dục mô phỏng với artifact đã được phê chuẩn hoặc đưa vào production.

1. Concept là gì?

Core

AI Assisted BA Workflow là quy trình Nghiệp vụ Phân tích (Business Analysis - BA) được hỗ trợ bởi Trí tuệ Nhân tạo (Artificial Intelligence - AI).

BA Workflow (Quy trình BA): Chuỗi các hoạt động BA thực hiện. Mục đích: hiểu vấn đề kinh doanh, xác định giải pháp, chuyển yêu cầu thành thông tin rõ ràng cho đội phát triển. Gồm thu thập yêu cầu, phân tích, thiết kế, kiểm thử, quản lý thay đổi.

Artificial Intelligence (AI - Trí tuệ Nhân tạo): Hệ thống máy tính mô phỏng khả năng tư duy con người. Ví dụ: học, giải quyết vấn đề, hiểu ngôn ngữ. AI: công cụ, không phải con người. Nó dùng thuật toán, dữ liệu để tìm ra mẫu, đưa gợi ý, tự động hóa tác vụ.

Assisted (Được hỗ trợ): AI không thay thế BA. AI đóng vai trò công cụ hỗ trợ. AI giúp BA làm việc hiệu quả hơn, nhanh hơn. BA vẫn là người quyết định cuối cùng, chịu trách nhiệm chính. BA: kiểm tra, xác nhận kết quả AI.

Tổng hợp: AI Assisted BA Workflow là việc BA dùng công cụ AI để: * Tăng hiệu suất: AI tự động hóa tác vụ lặp lại, tốn thời gian. BA tập trung công việc giá trị cao: phân tích chiến lược, giao tiếp, giải quyết xung đột. * Cải thiện tốc độ: AI xử lý lượng lớn dữ liệu nhanh. BA nhận thông tin, bản nháp nhanh chóng. * Nâng cao chất lượng: AI tìm mẫu, gợi ý mà con người khó thấy. BA có cái nhìn sâu hơn, đầy đủ hơn.

Mục tiêu chính: Giúp BA hiệu quả hơn, không phải thay thế BA.

Định nghĩa thuật ngữ nghiệp vụ cốt lõi

Thuật ngữ cốt lõi BA dùng mô tả mọi hoạt động nghiệp vụ hoặc hệ thống:

Thuật ngữ tiếng Anh	Thuật ngữ tiếng Việt	Giải thích	Ví dụ đơn giản
Actor	Tác nhân	Chủ thể khởi xướng, thực hiện hành động. Tác nhân có thể là người dùng (user), hệ thống khác (system), hoặc một sự kiện theo lịch trình (scheduled event). Tác nhân có vai trò, mục tiêu cụ thể trong bối cảnh nghiệp vụ, thường đại diện cho vai trò.	Người dùng "Kế toán viên" đăng nhập. Hệ thống "Quản lý tồn kho" gửi thông báo. Khách hàng thực hiện "Thanh toán".
Action	Hành động	Hoạt động cụ thể tác nhân thực hiện. Hành động mô tả động từ chính trong một quy trình. Nó chuyển đổi trạng thái đối tượng hoặc hệ thống. Hành động phải có mục đích nghiệp vụ rõ ràng, có thể đo lường và quan sát được.	"Đăng nhập", "Tạo đơn hàng", "Gửi báo cáo", "Cập nhật trạng thái", "Phê duyệt yêu cầu".
Object	Đối tượng	Thực thể mà hành động tác động lên. Đối tượng có thể là dữ liệu (data), tài liệu (document), sản phẩm (product), hoặc một trạng thái nghiệp vụ (business state). Đối tượng thường đại diện cho một danh từ trong nghiệp vụ, là trọng tâm của hành động.	"Đơn hàng", "Sản phẩm", "Báo cáo tài chính", "Phiếu xuất kho", "Thông tin khách hàng", "Yêu cầu nghỉ phép".
Outcome	Kết quả	Trạng thái mới đạt được sau khi hành động hoàn tất. Kết quả là mục tiêu cuối cùng của hành động, thể hiện sự thay đổi, thông báo, hoặc hoàn thành một công việc. Kết quả có thể thành công, thất bại, hoặc một trạng thái trung gian cần xử lý.	"Đăng nhập thành công", "Đơn hàng được tạo", "Báo cáo được gửi", "Sản phẩm giảm số lượng tồn kho", "Yêu cầu bị từ chối".

Ví dụ Nova Foods mô phỏng, Giới hạn và Loại trừ

Mô tả khái niệm "AI-Assisted BA Workflow" qua ví dụ Nova Foods mô phỏng, nêu rõ ranh giới và các yếu tố loại trừ.

Applied

Tình huống Nova Foods: Nova Foods, một công ty thực phẩm mô phỏng, quyết định ra mắt chương trình "Ưu đãi combo trưa" cho chuỗi cửa hàng bán lẻ của mình. Chương trình gồm mua một "Bánh mì gà xé" (mã sản phẩm: NF-PM-001) và một "Nước ép cam tươi" (mã sản phẩm: NF-DR-005) với giá ưu đãi cố định 45.000 VND (thay vì 60.000 VND). Chương trình áp dụng từ 11:00 đến 14:00 hàng ngày.

• Facts (Sự thật):

  • Chương trình ưu đãi mới: "Combo trưa".
  • Sản phẩm cấu thành: Bánh mì gà xé (NF-PM-001), Nước ép cam tươi (NF-DR-005).
  • Giá combo: 45.000 VND.
  • Thời gian áp dụng: 11:00 - 14:00 hàng ngày.
  • Mục tiêu kinh doanh: Tăng doanh số bán hàng giờ thấp điểm buổi trưa.
  • Dữ liệu: Mô phỏng, tổng hợp.
  • Tình trạng: IN_REVIEW, v0.9.0, 2026-08-07.

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

  • Business Owner (Chủ nghiệp vụ) trao đổi ý tưởng với BA qua cuộc họp.
  • BA ghi chép, nghe lại cuộc họp (nếu có ghi âm), tổng hợp thông tin thủ công.
  • BA tự viết các user story, business rule và acceptance criteria (tiêu chí chấp nhận) thành tài liệu Word hoặc Jira.
  • Quá trình này mất khoảng 1-2 ngày để ra bản nháp đầu tiên.
  • Có nguy cơ bỏ sót thông tin hoặc hiểu sai yêu cầu do ghi chép không đầy đủ.

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

  • Tăng tốc độ chuyển đổi ý tưởng nghiệp vụ thành yêu cầu phần mềm dạng cấu trúc.
  • Giảm công sức thủ công cho các tác vụ lặp lại (ví dụ: viết user story từ mô tả dài).
  • Cải thiện tính nhất quán và đầy đủ của tài liệu yêu cầu ban đầu.
  • Giảm sai sót trong bản nháp đầu tiên của BA.

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

  1. Manual BA Workflow: BA tiếp tục quy trình hiện tại, tổng hợp và viết yêu cầu thủ công.
  2. AI-Assisted BA Workflow: BA sử dụng công cụ AI để phân tích thông tin đầu vào (ví dụ: biên bản họp, ghi âm chuyển văn bản), đề xuất user story, business rule và acceptance criteria.

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

  • Tốc độ: Tốc độ tạo bản nháp yêu cầu.
  • Độ chính xác: Mức độ phù hợp của bản nháp với ý định nghiệp vụ.
  • Chi phí: Chi phí bản quyền công cụ AI (nếu có) và đào tạo.
  • Bảo mật thông tin: Khả năng bảo mật dữ liệu nghiệp vụ nhạy cảm khi dùng AI.
  • Khả năng kiểm soát: BA có kiểm soát hoàn toàn đầu ra của AI không.

• Decision (Quyết định): Nova Foods chọn triển khai AI-Assisted BA Workflow cho giai đoạn phác thảo yêu cầu ban đầu, đặc biệt là khi có yêu cầu nghiệp vụ rõ ràng nhưng cần chuyển đổi nhanh sang cấu trúc user story.

• Authority (Thẩm quyền): Trưởng phòng BA (Head of Business Analysis) tại Nova Foods.

• Artifact (Sản phẩm tạo ra):

  • Biên bản họp đã được chuyển đổi thành văn bản (meeting_transcript_20260807_promo.txt).
  • Bản nháp User Stories do AI đề xuất (draft_user_stories_promo_20260807.json).
  • Bản nháp Business Rules do AI đề xuất (draft_business_rules_promo_20260807.md).
  • (BA chỉnh sửa) User Stories và Business Rules cuối cùng.

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

  • Nếu chọn Manual: Tốn thời gian hơn, có thể chậm trễ ra mắt chương trình ưu đãi, mất cơ hội doanh thu.
  • Nếu chọn AI-Assisted nhưng AI không chính xác hoặc dữ liệu không bảo mật: Yêu cầu sai, tốn công sửa chữa, rủi ro lộ thông tin nghiệp vụ. BA phải luôn kiểm tra và chịu trách nhiệm cuối cùng.

Senior Lens

Ranh giới khái niệm AI-Assisted BA Workflow (Nova Foods):

Tiêu chí	Mô tả	Bao gồm (IN)	Loại trừ (EXCLUDE)
Vị trí trong quy trình BA	Nơi AI được tích hợp	Hỗ trợ các tác vụ BA, chủ yếu ở giai đoạn Thu thập, Phân tích và Đặc tả yêu cầu.	Thay thế hoàn toàn BA trong bất kỳ giai đoạn nào.
Vai trò của AI	Mục đích sử dụng AI	Tạo bản nháp nội dung (draft generation), tóm tắt thông tin (summarization), trích xuất thực thể (entity extraction), nhận diện mẫu (pattern identification).	Đưa ra quyết định nghiệp vụ (business decisions), phê duyệt tài liệu (document approval), đưa ra lời khuyên pháp lý/kế toán/bảo mật.
Đầu ra của AI	Bản chất sản phẩm AI cung cấp	Đầu ra là đề xuất, bản nháp, thông tin thô cần BA xem xét và tinh chỉnh.	Đầu ra là tài liệu cuối cùng, chính thức, đã được phê duyệt mà không cần con người kiểm tra.
Trách nhiệm	Ai chịu trách nhiệm cuối cùng	BA chịu trách nhiệm cuối cùng về chất lượng và độ chính xác của mọi tài liệu yêu cầu.	AI chịu trách nhiệm về sai sót trong đầu ra.
Phạm vi dữ liệu	Loại dữ liệu AI được phép xử lý	Dữ liệu nghiệp vụ không nhạy cảm hoặc đã được ẩn danh/tổng hợp khi đưa vào AI công cộng. Dữ liệu nhạy cảm chỉ dùng AI nội bộ.	Dữ liệu khách hàng thực, dữ liệu tài chính nhạy cảm hoặc bí mật kinh doanh chưa được xử lý bởi BA.
Tác động lên hệ thống	Quyền hạn thay đổi hệ thống	Đề xuất cấu hình hệ thống hoặc dữ liệu mẫu cho dev/test.	Thay đổi trực tiếp cấu hình hệ thống production, dữ liệu production hoặc đưa ra quyết định triển khai.

Quick Reference

AI-Assisted BA Workflow là việc BA sử dụng công cụ AI để hỗ trợ một số tác vụ nhất định trong quá trình phân tích nghiệp vụ, nhằm tăng hiệu suất, giảm công sức thủ công và cải thiện chất lượng bản nháp ban đầu.

Ví dụ Nova Foods: BA dùng AI để chuyển đổi cuộc họp thành các user story và business rule cho chương trình "Combo trưa".

Giới hạn cốt lõi: * AI TẠO BẢN NHÁP, không tạo bản CHÍNH THỨC. * BA DUYỆT và CHỊU TRÁCH NHIỆM hoàn toàn. * AI KHÔNG đưa ra quyết định nghiệp vụ, KHÔNG phê duyệt, KHÔNG thay thế phán đoán của BA. * Dữ liệu nghiệp vụ nhạy cảm phải được xử lý cẩn thận, không tùy tiện đưa vào AI công cộng.

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

Core

D? án th?t b?i, làm l?i, m? h? và r?i ro qu?n tr? - Business Analyst (BA) t?ng g?p v?n ?? l?n. Yêu c?u nghi?p v? thay ??i liên t?c. Tài li?u l?i th??ng mâu thu?n. BA d?nh nhi?u th?i gian vào vi?c t?o b?n nháp th? công. Ít th?i gian t?p trung phân tích chuyên sâu, giao ti?p bên liên quan.

"AI-assisted BA workflow" (Quy trình BA h? tr? b?i AI) ra ??i. Nó gi?m gánh n?ng t?o tài li?u ban ??u. T?ng t?c ?? chu?n b? yêu c?u. Gi?m s? sai sót th? công. BA t?p trung giá tr? cao.

Nguyên nhân: * Làm l?i (Rework): BA t?o yêu c?u thu? công. B?n nháp ??u thi?u sót, không nh?t quán. D?n ??n phát tri?n sai. S?a ??i t?n th?i gian, chi phí. * M? h? (Ambiguity): Yêu c?u vi?t tay, t? ngôn ng? t? nhiên. D? hi?u nh?m. Dev vi?t code không ?úng mong mu?n. Testers không test ?úng. * R?i ro th?t b?i d? án (Project Failure Risk): Làm l?i và m? h? tích t?. D? án tr? ti?n ??, v??t ngân sách, không ??t m?c tiêu. * R?i ro qu?n tr? (Governance Risk): Thi?u traceability (kh? n?ng truy v?t) gi?a yêu c?u, quy?t ??nh. Tài li?u không th?ng nh?t. Khó ki?m toán, tuân th? (compliance).

AI h? tr? BA gi?i quy?t. Nhanh chóng t?o b?n nháp c?u trúc. Gi?m c?ng s?c. BA có th? ki?m tra, tinh ch?nh tài li?u t? AI. T?ng ch?t l??ng yêu c?u ??u vào.

Applied

Nova Foods, ví d? mô ph?ng, t?ng g?p v?n ?? khi x? ly "Ch??ng trình khách hàng thân thi?t" th? công.

H?ng m?c	Tr??c khi có AI (Ch??ng trình khách hàng thân thi?t)	Sau khi có AI (Ch??ng trình Combo tr?a)
S? th?t (Facts)	BA m?t 3 ngày t?o b?n nháp user story và business rule t? ghi chú h?p.	BA m?t 0.5 ngày dùng AI t?o b?n nháp user story và business rule t? ghi chú h?p.
Hành vi hi?n t?i (Current Behavior)	BA ??c, tóm t?t, gõ l?i, format tài li?u yêu c?u. L? th??ng xuyên.	BA ??a ghi chú h?p vào AI, AI t?o c?u trúc. BA xem xét, ch?nh s?a, thêm b?i c?nh.
Nhu c?u c? b?n (Underlying Need)	T?ng t?c ?? t?o tài li?u ban ??u. Gi?m sai sót nh?p li?u. BA t?p trung giá tr? cao.	T?i ?u hóa quy trình chu?n b? tài li?u. Gi?m th?i gian ch? cho phát tri?n.
Tùy ch?n (Options)	1. Duy trì cách th? công. 2. Thuê thêm BA. 3. Hu?n luy?n BA vi?t nhanh h?n. 4. Áp d?ng AI h? tr?.	1. Không dùng AI. 2. Dùng AI t?o tài li?u. 3. Ch? dùng AI cho tóm t?t h?p.
Tiêu chí quy?t ??nh (Decision Criteria)	Hi?u qu? chi phí, t?c ??, ch?t l??ng tài li?u, r?i ro d? án.	Ti?t ki?m th?i gian BA, gi?m rework c?a dev, ??t m?c tiêu phát tri?n nhanh h?n.
Quy?t ??nh (Decision)	Nova Foods quy?t ??nh áp d?ng "AI-assisted BA workflow" cho các d? án m?i.	Áp d?ng AI cho b?n nháp user story, business rule và test case ban ??u.
Th?m quy?n (Authority)	Tr??ng phòng BA và Giám ??c D? án Nova Foods.	Tr??ng phòng BA, PM, ??i BA.
Artifact (S?n ph?m)	Quy trình làm vi?c AI-assisted BA (tài li?u này). H??ng d?n s? d?ng AI tools.	25-ai-assisted-ba-workflow.md, các h??ng d?n n?i b?.
H?u qu? n?u sai (Consequence if Wrong)	Th?i gian BA không gi?m. R?i ro rò r? d? li?u nh?y c?m n?u dùng AI công c?ng.	D? li?u nh?y c?m Nova Foods rò r?. AI t?o n?i dung sai l?ch nghiêm tr?ng không phát hi?n.

Senior Lens

Phân bi?t thông tin: BA ph?i hi?u ngu?n thông tin. AI ch? là công c?. BA là ng??i ch?u trách nhi?m cu?i cùng.

Lo?i thông tin	??nh ngh?a	Ví d? Nova Foods (t?ng h?p)
S? th?t ?? xác minh (Verified Fact)	Thông tin ?? c? b?ng ch?ng tin c?y, ngu?n chu?n.	Lu?t K? toán Vi?t Nam yêu c?u l?u tr? hóa ??n 10 n?m (Ngu?n: Lu?t 88/2015/QH13).
??u vào t? bên liên quan (Stakeholder Input)	Ý ki?n, mong mu?n, nhu c?u t? ng??i dùng, qu?n ly?.	Tr??ng phòng Marketing mu?n "Combo tr?a" t?ng 15% doanh s? (Ý ki?n Marketing).
Gi? ??nh d? án (Project Assumption)	Gi? ??nh ?? d? án ti?n hành. Ph?i ki?m tra sau.	Khách hàng Nova Foods có smartphone ?? quét mã QR coupon (Gi? ??nh k? thu?t).
Quy?t ??nh (Decision)	K?t lu?n ch?n l?a, ph??ng án th?c hi?n. Có th?m quy?n phê duy?t.	Giám ??c CNTT quy?t ??nh s? d?ng API Gateway cho tích h?p (Quy?t ??nh ki?n trúc).
Yêu c?u xác minh (Verification-required Claim)	Phát bi?u c?n b?ng ch?ng, d? li?u ?? ch?ng minh tính ??ng ??n.	AI s? gi?m 20% th?i gian cho tác v? BA (C?n thu th?p metrics ?? xác minh).

R?i ro qu?n tr?: Không phân bi?t d?n ??n d? án ch?n sai h??ng. AI có th? t?o ra "s? th?t" sai n?u ngu?n d? li?u ban ??u không chu?n. BA c?n phán ?oán.

Quick Reference

T?i sao AI-assisted BA: * Tránh làm l?i: Gi?m sai sót khi t?o b?n nháp tài li?u yêu c?u. * Gi?m m? h?: T?o tài li?u c?u trúc, r? ràng h?n t? ??u. * Gi?m r?i ro d? án: T?ng t?c ??, ch?t l??ng ??u vào, d? án hi?u qu? h?n. * Ki?m soát qu?n tr?: H? tr? traceability, t?o b?n nháp tài li?u nh?t quán.

BA không giao quy?t ??nh cho AI. AI là c?ng c? t?o b?n nháp. BA là ng??i ra quy?t ??nh, ki?m duy?t, ch?u trách nhi?m.

Minh họa Nova Foods: So sánh Trước và Sau (Before/After Contrast)

Core

Việc áp dụng quy trình hỗ trợ AI (AI-assisted workflow) cho BA tồn tại để giải quyết các vấn đề cố hữu của phương pháp truyền thống, đặc biệt trong môi trường nghiệp vụ phức tạp và nhiều quy định pháp lý như Nova Foods. Các vấn đề này bao gồm rủi ro dự án thất bại (project failure), phải làm lại (rework) tốn kém, yêu cầu không rõ ràng (ambiguity) và rủi ro quản trị (governance risk) do thiếu truy vết (traceability). Concept này cung cấp công cụ để tối ưu hóa quá trình thu thập, phân tích và tài liệu hóa yêu cầu, đảm bảo tính đầy đủ, chính xác và nhất quán.

Applied

Nova Foods, một công ty mô phỏng trong lĩnh vực sản xuất và phân phối thực phẩm, đối mặt với thách thức lớn từ việc phải tuân thủ nhiều quy định pháp lý phức tạp và thay đổi liên tục của Việt Nam (ví dụ: Luật An toàn thực phẩm, Luật Kế toán, Nghị định về hóa đơn điện tử).

Thành phần so sánh	Trước khi áp dụng AI-assisted BA workflow	Sau khi áp dụng AI-assisted BA workflow
Facts (Sự thật)	Nova Foods xử lý hàng trăm trang tài liệu pháp lý (Luật 55/2010/QH12 về An toàn thực phẩm, Luật 88/2015/QH13 về Kế toán, Nghị định 123/2020/NĐ-CP về hóa đơn điện tử) và chính sách nội bộ. Dữ liệu tổng hợp từ nhiều hệ thống kế thừa. Dự án ERP lớn.	Các nguồn lực và quy định pháp lý vẫn giữ nguyên, nhưng có thêm công cụ AI để xử lý. Dữ liệu vẫn là tổng hợp và mô phỏng.
Current Behavior (Hành vi hiện tại)	BA đọc, phân tích tài liệu thủ công để trích xuất yêu cầu. Việc đối chiếu giữa các nguồn và tìm kiếm điều khoản liên quan rất tốn thời gian. Yêu cầu thường được viết dựa trên diễn giải cá nhân, dễ thiếu sót hoặc mâu thuẫn.	BA sử dụng công cụ AI để quét tài liệu pháp lý, chính sách nội bộ, ghi chú cuộc họp. AI gợi ý các thực thể (entities), mối quan hệ, các điều khoản liên quan, và cảnh báo về các mâu thuẫn hoặc thiếu sót dựa trên từ khóa, cấu trúc hoặc so sánh với các mẫu yêu cầu chuẩn.
Underlying Need (Nhu cầu cốt lõi)	Đảm bảo tính tuân thủ pháp lý cho các module ERP mới (ví dụ: quản lý kho, kế toán, hóa đơn), giảm thiểu rủi ro bị phạt hoặc gián đoạn hoạt động. Nâng cao chất lượng yêu cầu để giảm làm lại trong giai đoạn phát triển và kiểm thử.	Tự động hóa phần lớn công việc phân tích tài liệu lặp lại, cho phép BA tập trung vào xác minh, làm rõ và tìm giải pháp sáng tạo. Cải thiện độ chính xác và tính đầy đủ của yêu cầu nghiệp vụ và pháp lý ngay từ đầu.
Options (Các lựa chọn)	1. Tăng số lượng BA, kéo dài thời gian dự án, hoặc chấp nhận rủi ro về chất lượng và tuân thủ. 2. Thuê chuyên gia tư vấn pháp lý/nghiệp vụ bên ngoài để đọc và giải thích.	1. Tích hợp AI-assisted tool vào quy trình BA hiện có. 2. Đào tạo BA về cách sử dụng công cụ AI hiệu quả, kết hợp với các phương pháp BA truyền thống.
Decision Criteria (Tiêu chí quyết định)	Tốc độ phân tích yêu cầu; số lượng lỗi (bugs) nghiệp vụ liên quan đến yêu cầu phát hiện ở các giai đoạn sau; khả năng truy vết (traceability) từ yêu cầu đến nguồn gốc (pháp lý, nghiệp vụ); chi phí (nhân lực BA vs chi phí công cụ/đào tạo).
Decision (Quyết định)	Nova Foods quyết định thí điểm tích hợp công cụ AI-assisted BA vào giai đoạn phân tích yêu cầu cho module Quản lý Hóa đơn Điện tử (Electronic Invoice Management) để nâng cao chất lượng yêu cầu tuân thủ Nghị định 123/2020/NĐ-CP.
Authority (Thẩm quyền)	Trưởng phòng BA Nova Foods, Giám đốc Dự án ERP, đại diện phòng Pháp chế và Kế toán (các vai trò mô phỏng).
Artifact (Kết quả làm việc)	Trước: Yêu cầu REQ-NF-HOADON-001 (Yêu cầu khởi tạo hóa đơn điện tử) không nhắc đến việc kiểm tra đầy đủ các trường thông tin "mã số thuế người bán", "mã số thuế người mua" theo Nghị định 123/2020/NĐ-CP, Điều 10. Sau: Yêu cầu REQ-NF-HOADON-001-AI (Yêu cầu khởi tạo hóa đơn điện tử, bản AI hỗ trợ) tự động đề xuất thêm kiểm tra các trường "mã số thuế" và liên kết trực tiếp đến Nghị định 123/2020/NĐ-CP Điều 10.
Consequence if Wrong (Hậu quả nếu sai)	Nếu tiếp tục BA thủ công, hóa đơn điện tử có thể bị cơ quan thuế từ chối do thiếu thông tin bắt buộc, dẫn đến gián đoạn hoạt động kinh doanh của Nova Foods, chậm trễ ghi nhận doanh thu và phát sinh chi phí làm lại. Nếu công cụ AI không hiệu quả hoặc BA không được đào tạo đầy đủ, quá trình phân tích vẫn chậm, có lỗi, và lãng phí chi phí đầu tư công cụ.

Senior Lens

Một BA cao cấp nhìn vào không chỉ kết quả "giảm lỗi" mà còn vào cách AI giúp BA "làm việc thông minh hơn". AI không thay thế tư duy phản biện hay khả năng tương tác với stakeholder của BA, mà nó xử lý khối lượng lớn dữ liệu sơ cấp, cho phép BA dành thời gian cho việc giải quyết các vấn đề phức tạp, thương lượng và đưa ra quyết định chiến lược. Vấn đề truy vết từ nguồn gốc pháp lý đến yêu cầu là một trong những rủi ro lớn nhất mà phương pháp truyền thống thường bỏ qua; AI cung cấp một cầu nối đáng tin cậy.

Quick Reference

Vấn đề chính (Trước)	Cải thiện (Sau AI)	Tham chiếu
Rework do thiếu sót yêu cầu tuân thủ	Phát hiện sớm, tự động gợi ý yêu cầu pháp lý	Nghị định 123/2020/NĐ-CP, Luật Kế toán
Yêu cầu mơ hồ, mâu thuẫn	Xác định các khái niệm khác biệt, gợi ý làm rõ	BABOK Guide v3, Chương 4
Khó khăn truy vết pháp lý	Tự động liên kết yêu cầu với điều khoản nguồn	ISO/IEC/IEEE 29148, Điều 6.3

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

Core

Khi xây dựng hệ thống phần mềm, thông tin là nền tảng. Tuy nhiên, không phải mọi thông tin đều có giá trị và độ tin cậy như nhau. Phân biệt rõ các loại thông tin này giúp BA giảm thiểu rủi ro dự án, tránh làm lại (rework), loại bỏ sự mơ hồ và đảm bảo quản trị hiệu quả. Việc không phân biệt rõ các loại thông tin này có thể dẫn đến việc đưa ra các quyết định sai lầm, lãng phí nguồn lực và không đáp ứng được mục tiêu kinh doanh.

Loại Thông tin	Mô tả	Tính chất	Nguồn gốc phổ biến	Rủi ro nếu nhầm lẫn
Sự kiện đã xác minh (Verified Fact)	Thông tin đã được kiểm chứng độc lập, có bằng chứng khách quan, rõ ràng.	Khách quan, có thể kiểm chứng, ổn định.	Luật pháp (Luật An toàn thực phẩm 55/2010/QH12), quy định, dữ liệu hệ thống (sau kiểm toán), tài liệu phê duyệt chính thức.	Phát triển dựa trên thông tin sai lệch, vi phạm pháp luật, làm lại hệ thống.
Đầu vào từ Bên liên quan (Stakeholder Input)	Yêu cầu, mong muốn, quan điểm, đề xuất từ người dùng cuối, quản lý, chuyên gia nghiệp vụ hoặc các nhóm có lợi ích trong dự án.	Chủ quan, thể hiện nhu cầu hoặc góc nhìn cá nhân/phòng ban, biến động.	Phỏng vấn, workshop, khảo sát, họp nhóm tập trung.	Bỏ lỡ nhu cầu thực, phát triển tính năng không cần thiết, mâu thuẫn giữa các bên liên quan.
Giả định Dự án (Project Assumption)	Điều kiện được chấp nhận là đúng tạm thời để dự án có thể tiến hành, trong khi chờ xác minh hoặc do không có thông tin đầy đủ.	Tạm thời, chưa được kiểm chứng, tiềm ẩn rủi ro cao nếu sai.	BA đưa ra (có lý do hợp lý), team dự án thống nhất, quản lý dự án phê duyệt.	Thiết kế/phát triển dựa trên giả định sai, làm lại lớn, chậm tiến độ, vượt ngân sách.
Quyết định (Decision)	Lựa chọn đã được chính thức thực hiện và phê duyệt bởi thẩm quyền phù hợp, ảnh hưởng đến phạm vi, thiết kế, công nghệ hoặc quy trình của dự án.	Có thẩm quyền, ràng buộc, thể hiện sự đồng thuận hoặc chỉ đạo.	Biên bản họp (Meeting Minutes), tài liệu phê duyệt (Approval Document), Charter dự án.	Phát triển không đúng hướng, tranh cãi về phạm vi, thay đổi yêu cầu liên tục (scope creep).
Tuyên bố cần xác minh (Verification-Required Claim)	Thông tin được trình bày như sự thật nhưng chưa có bằng chứng đầy đủ, cần hành động cụ thể để kiểm tra hoặc thu thập bằng chứng xác thực.	Có thể là thật hoặc sai, cần hành động kiểm chứng, tiềm ẩn rủi ro cao nếu được chấp nhận mà không kiểm tra.	Bên liên quan đưa ra khi không có dữ liệu, BA ghi nhận để theo dõi và đưa vào kế hoạch xác minh.	Đưa thông tin sai vào hệ thống, ra quyết định dựa trên cơ sở không vững chắc, làm giảm độ tin cậy.

Applied

Nova Foods, một công ty sản xuất và kinh doanh thực phẩm mô phỏng, đang có kế hoạch nâng cấp hệ thống quản lý kho (ERP Inventory Module) để tuân thủ quy định truy xuất nguồn gốc và cải thiện hiệu quả vận hành. Việc phân loại thông tin đúng cách trong tình huống này là rất quan trọng để đảm bảo dự án thành công.

Yếu tố	Nội dung	Lý do / Bằng chứng	Loại Thông tin	Phân loại
Sự kiện đã xác minh (Fact)	Luật An toàn thực phẩm (Luật 55/2010/QH12) yêu cầu doanh nghiệp sản xuất thực phẩm phải thiết lập và duy trì hệ thống truy xuất nguồn gốc sản phẩm theo lô. Nova Foods đã từng bị chậm trễ đáng kể khi truy hồi sản phẩm lỗi do quản lý lô thủ công.	Nguồn: /00-research/00_SOURCE_MAP.md liệt kê Luật An toàn thực phẩm, xác nhận yêu cầu pháp lý. Dữ liệu lịch sử vận hành nội bộ Nova Foods về thời gian xử lý sự cố.	Khách quan, có bằng chứng	Verified Fact
Hành vi hiện tại (Current Behavior)	Quy trình truy xuất nguồn gốc sản phẩm theo lô hiện tại của Nova Foods đòi hỏi đối chiếu thủ công nhiều tài liệu (hóa đơn nhập kho, phiếu xuất kho, sổ ghi chép sản xuất), mất trung bình 4-6 giờ cho mỗi trường hợp truy xuất.	Quan sát thực tế quy trình nghiệp vụ. Phỏng vấn nhân viên Kho và QA.	Quan sát/Đầu vào	Stakeholder Input (từ QA/Kho) + Verified Fact (thời gian xử lý)
Nhu cầu cốt lõi (Underlying Need)	Nova Foods cần một giải pháp tự động hóa việc theo dõi lô sản phẩm từ khâu nhập nguyên liệu đến xuất kho thành phẩm, giúp truy xuất nhanh chóng, chính xác để tuân thủ pháp luật, giảm rủi ro thu hồi và nâng cao uy tín thương hiệu.	Phân tích rủi ro tuân thủ (compliance risk) và hiệu quả vận hành (operational efficiency) dựa trên các sự kiện đã xác minh. Mục tiêu chiến lược của Nova Foods về chất lượng và dịch vụ.	Phân tích BA	Derived Need (từ Fact + Stakeholder Input)
Các phương án (Options)	1. Nâng cấp hệ thống "Legacy Stock" hiện có để thêm tính năng truy xuất lô. 2. Triển khai module Quản lý kho mới với tính năng truy xuất lô tự động. 3. Giữ nguyên quy trình thủ công và bổ sung nhân sự để giảm thời gian xử lý.	Đề xuất từ nhóm IT và Business sau khi xem xét chi phí và khả năng kỹ thuật.	Đề xuất	Stakeholder Input (IT/Business)
Tiêu chí ra quyết định (Decision Criteria)	- Khả năng tuân thủ Luật An toàn thực phẩm 100%. - Giảm thời gian truy xuất lô xuống dưới 30 phút cho mỗi trường hợp. - Chi phí triển khai và bảo trì trong ngân sách năm tài chính 2026. - Thời gian triển khai tối đa 6 tháng.	Thống nhất giữa các bên liên quan chính: Business Owner (Quản lý Kho), Ban Pháp chế, Kế toán, Trưởng phòng IT.	Mục tiêu/Nguyên tắc	Decision (Criteria)
Quyết định (Decision)	Triển khai module Quản lý kho mới với tính năng truy xuất lô tự động, tích hợp chặt chẽ với quy trình nhập xuất kho và hệ thống sản xuất. Quyết định này bao gồm việc áp dụng tiêu chuẩn mã vạch GS1 cho tất cả các lô sản phẩm.	Đã được phê duyệt chính thức bởi Ban Giám đốc và Chủ sở hữu nghiệp vụ (Business Owner) trong cuộc họp ngày 2026-08-01 (BBH-007/2026-08-01).	Lựa chọn đã chốt	Decision (Action)
Thẩm quyền (Authority)	Business Owner (Phòng Quản lý Kho), Ban Pháp chế & Tuân thủ (Legal & Compliance Department), Ủy ban Điều hành IT (IT Steering Committee), Giám đốc tài chính (CFO).	Các vai trò có quyền phê duyệt theo quy trình quản trị dự án được định nghĩa trong 01_CURRICULUM_ARCHITECTURE.md.	Vai trò	Verified Fact (governance structure)
Tài liệu (Artifact)	/02-handbook/BRD-INV-001_Batch_Tracking_Requirements_v1.0.md (Tài liệu Yêu cầu Nghiệp vụ) ghi nhận chi tiết các yêu cầu. /03-templates/ADS-INV-002_Inventory_Module_Design_v1.0.md (Đặc tả Thiết kế Kiến trúc) mô tả giải pháp kỹ thuật.	Nơi ghi nhận chi tiết yêu cầu, thiết kế và các quyết định.	Output	Verified Fact (artifact creation)
Tuyên bố cần xác minh (Verification-Required Claim)	Trưởng phòng Kinh doanh cho rằng: "Hơn 70% khách hàng B2B của Nova Foods sẽ mua nhiều hơn nếu họ có thể tự tra cứu thông tin lô sản phẩm và giấy chứng nhận chất lượng trên website B2B."	Cần tiến hành khảo sát khách hàng B2B hoặc phân tích dữ liệu bán hàng trước/sau khi triển khai tính năng này để xác thực tuyên bố.	Yêu cầu kiểm chứng	Verification-Required Claim
Giả định Dự án (Project Assumption)	Hệ thống quản lý kho mới sẽ hỗ trợ tích hợp sẵn (out-of-the-box) với các thiết bị quét mã vạch phổ biến tại kho hàng Nova Foods.	Giả định để ước tính ban đầu về chi phí và thời gian tích hợp, tránh chờ đợi khảo sát chi tiết.	BA và team IT thống nhất	Project Assumption
Hậu quả nếu sai (Consequence if Wrong)	Nếu Giả định Dự án ("hệ thống mới tích hợp sẵn với thiết bị quét") bị sai, chi phí và thời gian phát triển giao diện tích hợp tùy chỉnh sẽ tăng đáng kể, gây chậm trễ dự án. Nếu Tuyên bố cần xác minh ("70% khách hàng B2B mua nhiều hơn nhờ tra cứu online") bị chấp nhận mà không kiểm chứng, Nova Foods có thể đầu tư vào một tính năng không mang lại ROI như kỳ vọng, lãng phí nguồn lực.	Rủi ro lớn do dựa vào thông tin chưa được xác thực hoặc không đúng.	Phân tích rủi ro	BA Responsibility

Senior Lens

BA có kinh nghiệm luôn xem xét mọi thông tin với sự hoài nghi lành mạnh. Mục tiêu không phải là phủ nhận, mà là xác định nguồn gốc, độ tin cậy và mức độ rủi ro liên quan đến từng loại thông tin. Ghi lại rõ ràng từng loại thông tin trong các tài liệu dự án (ví dụ: Business Requirements Document, Assumption Log, Decision Log) là bắt buộc. Một Tuyên bố cần xác minh (Verification-Required Claim) cần được chuyển thành một nhiệm vụ cụ thể trong kế hoạch dự án (Project Plan), gán người chịu trách nhiệm và thời hạn. Giả định dự án (Project Assumption) phải được theo dõi liên tục, với kế hoạch dự phòng nếu giả định đó không còn đúng. Thiếu phân loại thông tin rõ ràng là nguyên nhân hàng đầu dẫn đến thay đổi yêu cầu liên tục, phát sinh chi phí ngoài ý muốn và xung đột giữa các bên liên quan, đặc biệt trong các dự án ERP lớn như Nova Foods.

Quick Reference

• Facts (Sự kiện đã xác minh): Thông tin khách quan, có bằng chứng. Ghi rõ nguồn (ví dụ: Luật, quy định).
• Input (Đầu vào từ Bên liên quan): Quan điểm chủ quan, nhu cầu. Ghi rõ tên người/phòng ban đưa ra.
• Assumption (Giả định Dự án): Điều kiện tạm chấp nhận để tiến hành. Cần theo dõi, xác minh. Chuẩn bị kế hoạch dự phòng.
• Claim (Tuyên bố cần xác minh): Thông tin cần kiểm chứng. Chuyển thành nhiệm vụ kiểm chứng cụ thể, có người chịu trách nhiệm.
• Decision (Quyết định): Lựa chọn đã phê duyệt. Ghi rõ thẩm quyền, ngày phê duyệt. Không xem là input hay assumption.

3. Vị trí trong Lifecycle

Core

Vị trí của quy trình BA hỗ trợ bởi AI (AI-assisted BA workflow) trong vòng đời phát triển phần mềm (Software Development Lifecycle - SDLC) là công cụ tăng cường, không thay thế, vai trò BA. Quy trình này tích hợp AI vào các giai đoạn chính của SDLC, từ Khám phá (Discovery) đến Vận hành (Operations), nhằm cải thiện hiệu quả, tốc độ và chất lượng đầu ra của BA. Mỗi giai đoạn có các "cổng vào" (entry gate) và "cổng ra" (exit gate) cụ thể, đánh dấu thời điểm bắt đầu và kết thúc can thiệp của AI.

Mapping các giai đoạn SDLC và AI-assisted BA

Giai đoạn SDLC	Mục tiêu chính	Cổng vào (Entry Gate) AI-assisted BA	Hoạt động AI-assisted BA	Cổng ra (Exit Gate) AI-assisted BA	Người sở hữu (Owner)
Khám phá (Discovery)	Hiểu vấn đề, xác định phạm vi, thu thập yêu cầu sơ bộ.	Yêu cầu nghiệp vụ cấp cao (high-level business requirements) hoặc vấn đề kinh doanh chưa rõ ràng. Ví dụ: tài liệu đề xuất dự án (project proposal) /nova-foods/docs/proposal-v1.2.md.	Phân tích tài liệu hiện có (ví dụ: các báo cáo sự cố trước đây, email), tổng hợp điểm đau (pain points), gợi ý yêu cầu chức năng/phi chức năng ban đầu.	Yêu cầu thô (raw requirements), danh sách tính năng gợi ý, danh sách câu hỏi cần làm rõ. Đầu ra: /nova-foods/docs/discovery/AI_generated_initial_requirements_v0.1.md.	Business Analyst (BA) chính
Phân tích (Analysis)	Phân rã yêu cầu, định nghĩa chi tiết, mô hình hóa.	Yêu cầu thô đã được BA sơ bộ làm rõ, kết quả phỏng vấn, workshop. Ví dụ: /nova-foods/docs/analysis/raw_stakeholder_input_v1.0.md.	Chuyển đổi yêu cầu ngôn ngữ tự nhiên thành User Story, Acceptance Criteria (tiêu chí chấp nhận), sơ đồ luồng công việc (workflow diagram) đơn giản. Hỗ trợ tạo từ điển dữ liệu (data dictionary) từ các trường dữ liệu được đề xuất.	User Stories đã được phân rã, Acceptance Criteria đã định hình, mô hình dữ liệu logic (logical data model) sơ bộ, luồng nghiệp vụ (business process flow) bằng UML/BPMN. Đầu ra: /nova-foods/artifacts/functional-spec/product_module_spec_v0.5.md.	Business Analyst (BA) chính
Triển khai (Delivery)	Phát triển phần mềm theo yêu cầu đã định nghĩa.	Đặc tả yêu cầu chức năng (Functional Specification) đã được baseline. Ví dụ: /nova-foods/artifacts/functional-spec/product_module_spec_v1.0_baseline.md.	Hỗ trợ lập tài liệu kỹ thuật, gợi ý cấu trúc API (API structure) hoặc dữ liệu mẫu (sample data) cho nhà phát triển dựa trên mô hình dữ liệu logic đã phê duyệt.	Tài liệu thiết kế kỹ thuật sơ bộ (preliminary technical design document), định nghĩa API thô (raw API definitions) hoặc các đoạn mã giả (pseudocode) cho các quy tắc nghiệp vụ phức tạp.	Technical Lead / Solution Architect
Kiểm thử (Testing)	Đảm bảo phần mềm đáp ứng yêu cầu và không có lỗi.	Đặc tả yêu cầu, User Stories, Acceptance Criteria đã phê duyệt. Ví dụ: /nova-foods/artifacts/functional-spec/product_module_spec_v1.0_baseline.md.	Gợi ý kịch bản kiểm thử (test scenarios), trường hợp kiểm thử (test cases) dựa trên Acceptance Criteria, dữ liệu kiểm thử (test data) tổng hợp. Hỗ trợ tạo cây quyết định (decision tree) cho các quy tắc phức tạp.	Bộ kịch bản kiểm thử sơ bộ, danh sách dữ liệu kiểm thử gợi ý, báo cáo độ bao phủ yêu cầu (requirements coverage report) ban đầu. Đầu ra: /nova-foods/docs/testing/AI_generated_test_plan_v0.2.md.	QA Analyst / BA
Phát hành (Release)	Triển khai phần mềm vào môi trường sản xuất.	Sản phẩm đã kiểm thử, sẵn sàng cho phát hành. Ví dụ: /nova-foods/artifacts/release/release_candidate_v1.0.0.md.	Hỗ trợ tạo tài liệu hướng dẫn sử dụng (user manual), tài liệu đào tạo (training material) cho người dùng cuối dựa trên các User Story và luồng nghiệp vụ. Gợi ý thông báo phát hành (release notes).	Tài liệu hướng dẫn sử dụng phiên bản nháp, tài liệu đào tạo cơ bản. Đầu ra: /nova-foods/docs/release/user_guide_draft_v0.1.md.	Product Owner / BA
Vận hành (Operations)	Giám sát, bảo trì, hỗ trợ phần mềm sau phát hành.	Phản hồi người dùng, báo cáo sự cố, dữ liệu sử dụng hệ thống.	Phân tích sentiment người dùng từ các kênh phản hồi, tổng hợp các vấn đề thường gặp, gợi ý cải tiến dựa trên dữ liệu vận hành, phân loại yêu cầu hỗ trợ.	Báo cáo tóm tắt phản hồi, danh sách các vấn đề lặp lại, đề xuất cải tiến nhỏ (minor enhancements) cho các vòng lặp sau.	Business Analyst / Support Lead

flowchart LR
    A[Khám phá] --> B{Yêu cầu cấp cao};
    B -- Có --> AI_BA_D[AI-assisted BA (Discovery)];
    AI_BA_D --> C[Phân tích];
    C --> D{Yêu cầu chi tiết/ACs};
    D -- Có --> AI_BA_A[AI-assisted BA (Analysis)];
    AI_BA_A --> E[Triển khai];
    E --> F{Đặc tả baseline};
    F -- Có --> AI_BA_Dev[AI-assisted BA (Delivery)];
    AI_BA_Dev --> G[Kiểm thử];
    G --> H{Yêu cầu/ACs phê duyệt};
    H -- Có --> AI_BA_T[AI-assisted BA (Testing)];
    AI_BA_T --> I[Phát hành];
    I --> J{Sản phẩm Release Candidate};
    J -- Có --> AI_BA_R[AI-assisted BA (Release)];
    AI_BA_R --> K[Vận hành];
    K --> L{Phản hồi/Sự cố};
    L -- Có --> AI_BA_O[AI-assisted BA (Operations)];
    AI_BA_O --> A;

    B -- Không --> C;
    D -- Không --> E;
    F -- Không --> G;
    H -- Không --> I;
    J -- Không --> K;
    L -- Không --> A;

    style AI_BA_D fill:#e0e0ff,stroke:#333,stroke-width:2px,color:#000
    style AI_BA_A fill:#e0e0ff,stroke:#333,stroke-width:2px,color:#000
    style AI_BA_Dev fill:#e0e0ff,stroke:#333,stroke-width:2px,color:#000
    style AI_BA_T fill:#e0e0ff,stroke:#333,stroke-width:2px,color:#000
    style AI_BA_R fill:#e0e0ff,stroke:#333,stroke-width:2px,color:#000
    style AI_BA_O fill:#e0e0ff,stroke:#333,stroke-width:2px,color:#000

Diagram: Mô tả luồng SDLC với điểm tích hợp quy trình BA hỗ trợ AI. Các khối màu xanh nhạt (AI-assisted BA) biểu thị các hoạt động AI tăng cường.

Applied

Nova Foods (mô phỏng) cần tối ưu hóa quá trình tạo mô tả sản phẩm cho trang thương mại điện tử mới. Hiện tại, BA phải đọc hàng chục tài liệu đặc tính kỹ thuật sản phẩm, phỏng vấn chuyên gia, và viết tay từng mô tả. Quá trình này mất nhiều thời gian và dễ sai sót thông tin.

• Facts: Nova Foods có hàng ngàn sản phẩm, mỗi sản phẩm có tài liệu đặc tính kỹ thuật riêng (file PDF, bảng Excel). Ví dụ: NF-SP-2026-08-07-001.pdf (Đặc tính kỹ thuật sản phẩm "Bánh mì hoa cúc 500g").
• Current Behavior: BA đọc thủ công NF-SP-2026-08-07-001.pdf, trích xuất thông tin, viết mô tả sản phẩm cho e-commerce bằng ngôn ngữ tự nhiên.
• Underlying Need: Tăng tốc độ, chuẩn hóa, và giảm lỗi trong việc tạo mô tả sản phẩm cho e-commerce, đảm bảo thông tin chính xác từ tài liệu gốc.
• Options:
  1. Thuê thêm BA để tăng tốc độ (giải pháp thủ công).
  2. Sử dụng công cụ AI (ví dụ: LLM) đọc tài liệu kỹ thuật, tự động tạo mô tả sản phẩm theo mẫu.
• Decision Criteria: Chi phí, thời gian thực hiện, độ chính xác, khả năng mở rộng (scalability), mức độ tự động hóa.
• Decision: Nova Foods chọn Option 2. Tích hợp AI-assisted BA vào giai đoạn Phân tích. AI đọc tài liệu PDF, Excel, trích xuất thuộc tính sản phẩm và tạo mô tả nháp dựa trên các quy tắc đã cấu hình.
• Authority: Trưởng phòng Sản phẩm (Product Manager), phối hợp với Trưởng phòng BA (Head of BA) và Kiến trúc sư giải pháp (Solution Architect).
• Artifact: Quy trình AI-assisted BA (Giai đoạn Phân tích) sẽ tạo ra các bản nháp mô tả sản phẩm, lưu trữ dưới dạng /nova-foods/artifacts/product-description/product_desc_draft_NF001_AI_v0.1.md. Sau đó BA sẽ review, chỉnh sửa và hoàn thiện.
• Consequence if Wrong:
  • Nếu chọn Option 1 (thuê thêm BA): Tốn chi phí nhân sự cao, vẫn chậm và có thể sai sót do yếu tố con người.
  • Nếu chọn Option 2 nhưng AI tạo mô tả sai: Ảnh hưởng uy tín Nova Foods, có thể dẫn đến khiếu nại khách hàng, chi phí chỉnh sửa dữ liệu lớn. Do đó cần quy trình kiểm duyệt chặt chẽ bởi BA.

Senior Lens

Việc tích hợp AI vào quy trình BA không phải phép màu. Với vai trò senior BA, trọng tâm là quản lý rủi ro và tối đa hóa giá trị. AI xuất sắc trong việc xử lý khối lượng lớn dữ liệu, nhận dạng mẫu, và tạo ra các bản nháp nhanh chóng. Tuy nhiên, AI thiếu khả năng hiểu ngữ cảnh kinh doanh sâu sắc, đánh giá cảm xúc hoặc đưa ra quyết định chiến lược. Do đó, "cổng vào" và "cổng ra" của AI-assisted BA phải được định nghĩa chặt chẽ. BA phải là người kiểm soát "cổng", đảm bảo AI được cung cấp đầu vào chất lượng và đầu ra được BA kiểm duyệt, điều chỉnh trước khi sử dụng. Đặc biệt, bất kỳ "quy tắc nghiệp vụ" (business rules) nào do AI gợi ý đều phải được đối chiếu với CANONICAL_BUSINESS_RULES và xác nhận bởi Business Owner. Nguy hiểm lớn nhất là tin tưởng mù quáng vào kết quả của AI mà bỏ qua quy trình xác minh của con người, dẫn đến việc tự động hóa những yêu cầu sai hoặc tạo ra lỗ hổng bảo mật. Luôn coi đầu ra của AI là "nháp", "gợi ý", "điểm khởi đầu".

Quick Reference

• Discovery (Khám phá):
  • Entry: Yêu cầu mơ hồ, tài liệu rời rạc.
  • Exit: Yêu cầu thô, danh sách câu hỏi làm rõ.
  • Role: BA xác định phạm vi, tinh chỉnh đầu ra.
• Analysis (Phân tích):
  • Entry: Yêu cầu thô, ghi chú phỏng vấn.
  • Exit: User Stories, ACs, mô hình sơ bộ.
  • Role: BA chuyển đổi, xác minh, thêm ngữ cảnh.
• Testing (Kiểm thử):
  • Entry: ACs, đặc tả chức năng.
  • Exit: Kịch bản kiểm thử, dữ liệu mẫu.
  • Role: BA/QA đánh giá độ bao phủ, chỉnh sửa.
• Operations (Vận hành):
  • Entry: Phản hồi người dùng, log hệ thống.
  • Exit: Báo cáo tổng hợp vấn đề, đề xuất cải tiến.
  • Role: BA phân tích xu hướng, ưu tiên cải tiến.
• Kiểm soát: BA giữ vai trò giám sát, xác minh, tinh chỉnh mọi đầu ra từ AI.

Chủ sở hữu, Điểm giao, Thẩm quyền và Leo thang trong luồng BA hỗ trợ AI

Core

Hoạt động Business Analyst (BA) hỗ trợ AI tích hợp vào quy trình phát triển sản phẩm. Rõ ràng chủ sở hữu (owner), điểm giao (handoff), giới hạn thẩm quyền (authority limits) và điểm leo thang (escalation points) thiết yếu. Thiết lập các điểm này giảm rủi ro hiểu lầm, tăng tốc độ xử lý, đảm bảo tuân thủ quy trình và pháp lý.

• Chủ sở hữu (Owner): Cá nhân hoặc vai trò chịu trách nhiệm chính về một hoạt động, artifact hoặc quyết định.
• Điểm giao (Handoff): Thời điểm hoặc điều kiện một hoạt động hoặc artifact chuyển từ vai trò này sang vai trò khác. Điểm giao cần rõ ràng đầu vào, đầu ra, trách nhiệm.
• Giới hạn thẩm quyền (Authority Limits): Phạm vi quyết định mà một vai trò có thể đưa ra mà không cần phê duyệt thêm. Vượt giới hạn cần leo thang.
• Điểm leo thang (Escalation Points): Vai trò hoặc quy trình được kích hoạt khi một vấn đề vượt quá giới hạn thẩm quyền, một xung đột xảy ra, hoặc một quyết định quan trọng cần phê duyệt cấp cao hơn.

Bảng 3.1: Các vai trò chính trong luồng BA hỗ trợ AI tại Nova Foods (mô phỏng)

Vai trò	Trách nhiệm chính	Giới hạn thẩm quyền	Điểm leo thang
Business Analyst (BA)	Phân tích yêu cầu, xác thực đầu ra AI, soạn thảo tài liệu yêu cầu.	Không tự ý phê duyệt yêu cầu nghiệp vụ, không thay đổi quy tắc kinh doanh gốc của Nova Foods (từ CANONICAL_BUSINESS_RULES).	BA Lead, Business Owner
AI Assistant (Công cụ)	Tạo bản nháp, gợi ý, tóm tắt dựa trên đầu vào và dữ liệu.	Không có thẩm quyền quyết định, không thay thế BA hoặc Business Owner.	N/A (chỉ là công cụ)
BA Lead	Quản lý đội BA, xem xét chất lượng công việc BA, phê duyệt các yêu cầu cấp thấp.	Không phê duyệt yêu cầu chiến lược hoặc thay đổi quy trình kinh doanh cốt lõi.	Project Manager, Business Owner
Business Owner	Cung cấp quy tắc nghiệp vụ, phê duyệt yêu cầu nghiệp vụ cuối cùng.	Không quyết định kỹ thuật, không thay đổi lộ trình dự án mà không có sự đồng thuận.	Steering Committee, CEO
Solution Architect	Thiết kế giải pháp kỹ thuật, đảm bảo tính khả thi.	Không thay đổi yêu cầu nghiệp vụ gốc, không quyết định phạm vi kinh doanh.	Project Manager, Technical Lead

Applied

Tình huống: Nova Foods cần tự động hóa gợi ý mức tồn kho tối thiểu cho sản phẩm tươi sống dựa trên biến động doanh số. BA sử dụng AI để tạo bản nháp yêu cầu nghiệp vụ.

• Facts: Yêu cầu: Xác định mức tồn kho tối thiểu (Minimum Stock Level - MSL) tự động. Sản phẩm: Cam tươi (ID: NF-PROD-007). AI được cung cấp dữ liệu bán hàng 12 tháng qua.
• Current Behavior: BA thủ công phân tích dữ liệu, phỏng vấn Trưởng phòng Kho vận (Logistics Manager – Business Owner của quy trình này) để xác định công thức MSL. Công việc này tốn nhiều thời gian, dễ sai sót do bỏ qua các yếu tố nhỏ.
• Underlying Need: Nhanh chóng tạo bản nháp yêu cầu MSL, giảm thời gian BA phân tích ban đầu, đảm bảo tính nhất quán của dữ liệu gợi ý.
• Options:
  1. Thủ công hoàn toàn: BA tự viết yêu cầu từ đầu. Chậm, phụ thuộc kinh nghiệm cá nhân.
  2. AI hỗ trợ: AI gợi ý công thức và các yếu tố ảnh hưởng, BA xem xét, chỉnh sửa và xác thực với Business Owner.
  3. AI tự động: AI tạo và tự động gửi yêu cầu đến đội phát triển. Rủi ro cao, không có kiểm soát.
• Decision Criteria: Tốc độ tạo nháp (Draft Speed), độ chính xác (Accuracy), tuân thủ (Compliance với Luật Kế toán 88/2015/QH13 về ghi nhận hàng tồn kho), chấp nhận của Business Owner.
• Decision: Chọn AI hỗ trợ. AI tạo bản nháp, BA xem xét và xác thực.
• Authority: Nova Foods Project Lead và BA Lead thống nhất phương pháp tiếp cận. Logistics Manager (Business Owner) là người phê duyệt cuối cùng nội dung yêu cầu MSL.
• Artifact: AI tạo nháp ban đầu REQ-NF-MSL-001-AI-Draft. Sau khi BA và Business Owner chỉnh sửa, phê duyệt, thành REQ-NF-MSL-001-Approved (ID từ TRACEABILITY_ID_REGISTRY).
• Consequence if Wrong: Nếu bản nháp AI không được BA và Business Owner kiểm tra kỹ, MSL sai. Dẫn đến tồn kho quá nhiều (lãng phí, hàng hết hạn) hoặc quá ít (mất doanh thu, không đáp ứng đơn hàng). Vi phạm quy định về quản lý tài sản, kiểm soát nội bộ theo Luật Kế toán 88/2015/QH13 nếu không có quy trình kiểm soát chặt chẽ.

Bảng 3.2: Luồng điểm giao và leo thang cho yêu cầu MSL hỗ trợ AI

Vai trò upstream	Hoạt động & đầu ra	Điểm giao (Handoff)	Vai trò downstream	Escalation Points
BA	Cung cấp dữ liệu, bối cảnh cho AI. Nhận bản nháp yêu cầu MSL từ AI.	REQ-NF-MSL-001-AI-Draft	BA	BA Lead (nếu AI ra kết quả không phù hợp)
BA	Xem xét, chỉnh sửa bản nháp AI. Soạn BRD-NF-MSL-001-v0.1.	Bản nháp BRD-NF-MSL-001-v0.1	Logistics Manager (Business Owner)	BA Lead, Project Manager (nếu không đạt đồng thuận với Business Owner)
Logistics Manager	Đánh giá, đưa phản hồi cho BRD-NF-MSL-001-v0.1.	Phản hồi/Phê duyệt	BA	Project Manager, Steering Committee (nếu tranh chấp không giải quyết được)
BA	Cập nhật BRD-NF-MSL-001 sang v1.0 dựa trên phản hồi.	BRD-NF-MSL-001-v1.0	Solution Architect, Development Team	BA Lead

Senior Lens

BA giữ trách nhiệm kiểm soát. AI chỉ công cụ, không thay thế tư duy phản biện. Luôn xác minh nguồn dữ liệu AI dùng. Quy tắc nghiệp vụ (Business Rules) trong CANONICAL_BUSINESS_RULES và quy định pháp lý (ví dụ: Luật Kế toán 88/2015/QH13) là nguồn chân lý. AI có thể "ảo giác" (hallucinate) hoặc bỏ qua ngữ cảnh văn hóa, pháp lý. BA cần biết khi nào cần leo thang: khi yêu cầu chạm đến ranh giới pháp lý, tài chính, hoặc chiến lược kinh doanh của Nova Foods. Không bao giờ tin tưởng mù quáng vào kết quả AI. Yêu cầu phê duyệt cuối cùng từ Business Owner luôn cần thiết.

Quick Reference

Bảng 3.3: Tổng hợp chủ sở hữu và điểm leo thang chính

Artifact/Quyết định	Chủ sở hữu chính	Tham gia/Xem xét	Điểm leo thang chính
Bản nháp yêu cầu AI	BA	N/A	BA Lead
Yêu cầu nghiệp vụ (BRD)	BA	Business Owner, Solution Architect	BA Lead, Project Manager
Quyết định sử dụng AI	BA Lead	Project Lead	Steering Committee
Yêu cầu pháp lý/tuân thủ	Legal Owner/Compliance Officer	BA, Business Owner	Legal/Compliance Head
Thay đổi quy tắc nghiệp vụ cốt lõi	Business Owner	BA, BA Lead	Steering Committee
Xung đột thẩm quyền	Project Manager	BA, BA Lead, Business Owner	Steering Committee

Sơ đồ Chu trình Phát triển Hệ thống (SDLC) hỗ trợ AI

Chu trình BA workflow dùng AI. Mỗi giai đoạn SDLC, AI hỗ trợ cụ thể. Sơ đồ minh họa chuỗi hỗ trợ đó.

graph TD
    start(Bắt đầu) --> A[Khám phá (Discovery)];
    A -- BA Xác định Phạm vi --> A_AI[AI: Thu thập dữ liệu, Tóm tắt tài liệu];
    A_AI --> B[Phân tích (Analysis)];
    B -- BA Xây dựng Yêu cầu --> B_AI[AI: Sinh User Story, Phân tích quy tắc, Lập mô hình];
    B_AI --> C[Thiết kế & Triển khai (Design & Delivery)];
    C -- BA Hợp tác Thiết kế --> C_AI[AI: Gợi ý giải pháp, Sơ đồ tích hợp sơ bộ];
    C_AI --> D[Kiểm thử (Testing)];
    D -- BA Xác nhận ACs --> D_AI[AI: Sinh kịch bản kiểm thử, Rà soát Acceptance Criteria];
    D_AI --> E[Phát hành (Release)];
    E -- BA Hỗ trợ Go-Live --> E_AI[AI: Phân tích tác động, Tổng hợp tài liệu phát hành];
    E_AI --> F[Vận hành (Operations)];
    F -- BA Thu thập Phản hồi --> F_AI[AI: Giám sát, Phân tích Log, Tổng hợp Feedback];
    F_AI --> end(Kết thúc / Cải tiến);

    style start fill:#f9f,stroke:#333,stroke-width:2px
    style end fill:#f9f,stroke:#333,stroke-width:2px
    classDef ai_support fill:#e0f7fa,stroke:#00bcd4,stroke-width:1px
    class A_AI,B_AI,C_AI,D_AI,E_AI,F_AI ai_support

Sơ đồ trình bày khái quát vị trí AI. Mỗi bước BA thực hiện, AI cung cấp công cụ hỗ trợ.

Bảng Tổng hợp Hỗ trợ AI theo Giai đoạn:

Giai đoạn SDLC	Vai trò BA (Tổng quát)	Hỗ trợ chính từ AI	Mục đích Hỗ trợ AI
Khám phá (Discovery)	Xác định phạm vi, Thu thập yêu cầu ban đầu	Phân tích tài liệu hiện có, Tóm tắt văn bản, Tìm kiếm thông tin	Tăng tốc thu thập dữ liệu, Tổng hợp tri thức
Phân tích (Analysis)	Xây dựng, Tổ chức, Đặc tả yêu cầu	Sinh User Story, Đề xuất quy tắc nghiệp vụ, Tạo mô hình dữ liệu/quy trình sơ bộ	Chuẩn hóa, Phát hiện thiếu sót, Giảm thời gian mô hình hóa
Thiết kế & Triển khai (Design & Delivery)	Hợp tác kiến trúc, Đánh giá thiết kế, Lập kế hoạch triển khai	Gợi ý mô hình thiết kế, Tạo sơ đồ tích hợp cơ bản, Đánh giá lựa chọn công nghệ	Đẩy nhanh quá trình thiết kế, Cung cấp lựa chọn kỹ thuật
Kiểm thử (Testing)	Xác nhận Acceptance Criteria, Phân tích kịch bản	Sinh kịch bản kiểm thử tự động, Đề xuất ca kiểm thử biên (edge cases), Rà soát độ phủ	Tối ưu kiểm thử, Đảm bảo chất lượng yêu cầu
Phát hành (Release)	Lập kế hoạch Go-Live, Đánh giá sẵn sàng	Phân tích tác động thay đổi, Tổng hợp tài liệu hướng dẫn phát hành	Giảm rủi ro phát hành, Đơn giản hóa tài liệu
Vận hành (Operations)	Giám sát hiệu suất, Thu thập phản hồi, Lập kế hoạch cải tiến	Giám sát hệ thống, Phân tích log bất thường, Tóm tắt phản hồi người dùng	Nâng cao vận hành, Xác định nhu cầu cải tiến

→ skipped: SDLC chi tiết, entry/exit gates, escalation. add when: Nova Foods quy trình cụ thể yêu cầu.

4. Input cần thiết

Core

Input: dữ liệu, thông tin, tài liệu. BA cần thu thập. Trước phân tích, thiết kế hệ thống. Như nguyên liệu nấu ăn. Mục đích: BA hiểu đúng vấn đề, yêu cầu. AI hỗ trợ cần Input chất lượng, mới.

Kiến thức Tiên quyết (Prerequisite Knowledge): Thông tin cơ bản. BA cần biết. Hiểu nghiệp vụ, dự án. Không giả định kiến thức phần mềm. Ví dụ Nova Foods: hiểu quy trình sản xuất thực phẩm, an toàn thực phẩm. Hiểu luật pháp Việt Nam liên quan. Nguồn: Luật pháp (ví dụ: Luật An toàn thực phẩm), tài liệu nghiệp vụ công ty.

Bằng chứng (Evidence): Tài liệu, dữ liệu chứng minh. Không phải ý kiến cá nhân. Ví dụ: biên bản họp, email xác nhận, báo cáo hệ thống cũ.

Artifact Nguồn (Source Artifacts): Tài liệu gốc. Chứa thông tin cần thiết. Như bản vẽ kỹ thuật, hợp đồng. Ví dụ: đặc tả hệ thống cũ, user manual, biểu mẫu giấy.

ID Canonical (Persistent Canonical IDs): Mã định danh duy nhất, ổn định. Cho mọi Input. Giúp truy vết. AI xử lý, phải biết Input gốc, từ đâu. Nguồn: /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /00-research/00_SOURCE_MAP.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Applied

Nova Foods: Bảng Tổng hợp Đầu vào

Nova Foods: case study mô phỏng, dữ liệu tổng hợp.

Input ID	Tên Input	Mô tả	Nguồn gốc	ID Canonical Gắn kết	Tình trạng Xác minh
NF-PRJ-001	Tài liệu Tầm nhìn Dự án ERP	Mục tiêu, phạm vi cấp cao ERP mới Nova Foods.	Ban Giám đốc Nova Foods	00_SOURCE_MAP (Project Vision placeholder)	Chưa phê duyệt chính thức
NF-STK-002	Danh sách Bên liên quan ERP	Các cá nhân, nhóm bị ảnh hưởng, quyền hạn, mức độ quan tâm.	Phòng Tổ chức Nhân sự Nova Foods	TRACEABILITY_ID_REGISTRY (Stakeholder List placeholder)	Cần phỏng vấn thêm Business Owner
NF-PRC-003	Quy trình Bán hàng Hiện tại (As-Is)	Mô tả các bước bán hàng hiện hành của Nova Foods.	Phòng Kinh doanh Nova Foods	CANONICAL_BUSINESS_RULES (SalesProcess_ASIS_001)	Bản nháp, chưa xác nhận Business Owner
NF-LEG-004	Luật An toàn thực phẩm	Yêu cầu pháp lý truy xuất nguồn gốc, vệ sinh an toàn thực phẩm.	Quốc hội Việt Nam	Luật An toàn thực phẩm (55/2010/QH12)	Đã xác minh phiên bản. Cần diễn giải nghiệp vụ cho Nova Foods.
NF-DAT-005	Dữ liệu Danh mục Sản phẩm	Thông tin SKU, giá, mô tả sản phẩm hiện có Nova Foods.	Hệ thống kế thừa Nova Foods (Excel/Access)	CANONICAL_DATA_DICTIONARY (ProductCatalog_Legacy)	Chất lượng dữ liệu không đồng nhất. Cần làm sạch, chuẩn hóa.
NF-ITF-006	Đặc tả API đối tác Vận chuyển	Tài liệu kỹ thuật tích hợp với nhà cung cấp dịch vụ vận chuyển.	Đối tác Vận chuyển (Vận Chuyển Nhanh Corp.)	00_SOURCE_MAP (PartnerAPI_VCN_Docs)	Chỉ bản nháp v1.0. Chờ bản cuối từ đối tác.

Senior Lens

Input chất lượng: AI làm việc hiệu quả. Input xấu: AI đưa ra kết quả sai lệch. BA cần kiểm tra.

Phân loại Nguồn: Nguồn chính thức (luật pháp), nguồn nội bộ (Business Owner), nguồn thứ cấp (báo cáo). Ảnh hưởng độ tin cậy. Ưu tiên nguồn có thẩm quyền cao nhất.

Độ Tươi (Freshness): Input mới nhất. Quan trọng. Luật, quy trình thay đổi. Kiểm tra ngày tạo, ngày sửa đổi. Input cũ, không đáng tin.

Sở hữu (Ownership): Ai chủ Input? Ai thẩm quyền xác nhận? Chủ sở hữu chịu trách nhiệm. Giúp BA tìm người xác nhận, giải quyết mâu thuẫn.

Điều kiện Dừng (Stop Conditions): Khi nào dừng thu thập Input? Khi đủ thông tin. Khi không còn mâu thuẫn lớn. Input không đủ: dự án rủi ro. Dừng kịp thời.

Quick Reference

graph TD
    subgraph "Nguồn Gốc (Source)"
        A[Luật An toàn Thực phẩm]
        B[Phỏng vấn Business Owner]
        C[Hệ thống Kế thừa]
        D[Đối tác (Vendor)]
    end

    subgraph "Artifact Thô (Raw Artifact)"
        A -- Tạo ra --> A1(Bản sao Luật, Nghị định);
        B -- Tạo ra --> B1(Biên bản Họp, Ghi chú);
        C -- Tạo ra --> C1(Báo cáo CSV, Sơ đồ Cũ);
        D -- Tạo ra --> D1(Đặc tả API, User Manual);
    end

    subgraph "Metadata & Định Danh (Canonical IDs)"
        E[00_SOURCE_MAP]
        F[TRACEABILITY_ID_REGISTRY]
        G[CANONICAL_BUSINESS_RULES]
        H[CANONICAL_DATA_DICTIONARY]
    end

    A1 -- Tham chiếu --> E;
    B1 -- Gắn kết --> F;
    B1 -- Xác nhận --> G;
    C1 -- Định nghĩa --> H;
    D1 -- Gắn kết --> E;

Định Nghĩa Tiêu Chuẩn Đầu Vào

Core

Để trợ giúp AI phân tích nghiệp vụ, dữ liệu đầu vào (input data) phải đạt chất lượng cao. Chất lượng này xác định bởi các tiêu chí, nguồn, thời điểm và trách nhiệm.

1. Kiểm Tra Chất Lượng Đầu Vào (Input Quality Checks)

Mọi đầu vào cho quy trình BA đều cần xác minh.

Tiêu chí	Mô tả (Vietnamese explanation)	Kiểm tra tối thiểu (Minimum check)
Hoàn chỉnh (Completeness)	Dữ liệu đầy đủ, không thiếu thông tin bắt buộc.	Mọi trường bắt buộc trong biểu mẫu/API đều có giá trị.
Chính xác (Accuracy)	Dữ liệu phản ánh đúng sự thật, không sai lệch.	So sánh với nguồn tin cậy, dữ liệu gốc.
Nhất quán (Consistency)	Dữ liệu không mâu thuẫn với các thông tin liên quan hoặc quy tắc nghiệp vụ hiện hành.	Quy tắc nghiệp vụ (Business Rules) được áp dụng.
Kịp thời (Timeliness/Freshness)	Dữ liệu còn giá trị sử dụng, chưa quá hạn.	Thời gian tạo/cập nhật < ngưỡng cho phép.
Phù hợp (Relevance)	Dữ liệu liên quan trực tiếp đến phạm vi phân tích.	Phù hợp với định nghĩa phạm vi (Scope Definition).

2. Phân Loại Nguồn (Source Classifications)

Nguồn dữ liệu có độ tin cậy khác nhau. Phân loại giúp xác định mức độ thẩm định.

Phân loại nguồn	Mô tả	Mức độ tin cậy	Ví dụ (Nova Foods)
Chính thức/Pháp lý (Canonical/Legal)	Văn bản pháp luật, quy định nhà nước, chuẩn ngành.	Cao nhất (Highest). Yêu cầu xác minh pháp lý.	Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP.
Nghiệp vụ (Business)	Quy trình nội bộ, chính sách công ty, quyết định ban lãnh đạo, dữ liệu giao dịch từ hệ thống ERP.	Cao. Yêu cầu xác minh từ Chủ sở hữu nghiệp vụ (Business Owner).	Quy trình phê duyệt mua hàng, báo cáo doanh thu sản phẩm.
Kỹ thuật (Technical)	Đặc tả API, sơ đồ kiến trúc hệ thống, nhật ký lỗi, tài liệu kỹ thuật của hệ thống hiện có.	Trung bình-Cao. Yêu cầu xác minh từ Kiến trúc sư (Architect), đội Vận hành (Ops).	Đặc tả tích hợp với cổng thanh toán, nhật ký lỗi sản xuất.
Bên thứ ba/Đối tác (Third-Party/Partner)	Dữ liệu từ nhà cung cấp, khách hàng, đối tác bên ngoài.	Trung bình. Yêu cầu hợp đồng, thỏa thuận SLA.	Dữ liệu đơn hàng từ nhà phân phối, thông tin sản phẩm từ nhà cung cấp nguyên liệu.
Không chính thức (Informal)	Email trao đổi, ghi chú cuộc họp chưa được phê duyệt, bản nháp.	Thấp. Chỉ dùng làm tham khảo ban đầu.	Email yêu cầu thay đổi tính năng, ghi chú từ buổi phỏng vấn ban đầu.

3. Độ Tươi của Dữ liệu (Data Freshness)

Dữ liệu "tươi" là dữ liệu còn giá trị sử dụng.

Khía cạnh	Mô tả	Tiêu chí Nova Foods	Cơ chế kiểm tra
Thời gian hiệu lực (Validity Period)	Khoảng thời gian dữ liệu được coi là hợp lệ.	BR-NF-001: Báo cáo bán hàng không quá 24h.	Kiểm tra ReportTimestamp trong cơ sở dữ liệu.
Chu kỳ xem xét (Review Cycle)	Tần suất cần xem xét lại nguồn để cập nhật.	BR-NF-002: Quy trình nghiệp vụ xem xét hàng năm.	So sánh LastReviewedDate với CurrentDate.
Ngày tạo/Cập nhật (Creation/Update Date)	Thời điểm dữ liệu được tạo hoặc thay đổi gần nhất.	BR-NF-003: Yêu cầu thay đổi không quá 7 ngày.	So sánh CreatedDate hoặc LastModifiedDate.
Tình trạng (Status)	Trạng thái hiện tại của dữ liệu (ví dụ: Active, Obsolete, Draft).	Chỉ chấp nhận yêu cầu thay đổi ở trạng thái Submitted.	Kiểm tra trường Status.

4. Chủ Sở Hữu (Ownership)

Mỗi đầu vào cần có chủ sở hữu rõ ràng để đảm bảo trách nhiệm và nguồn xác thực.

Vai trò Chủ sở hữu	Trách nhiệm	Ví dụ đầu vào Nova Foods
Chủ sở hữu nghiệp vụ (Business Owner)	Xác nhận tính chính xác nghiệp vụ, phê duyệt yêu cầu.	Yêu cầu tính năng mới, quy trình nghiệp vụ.
Chủ sở hữu dữ liệu (Data Owner)	Đảm bảo tính toàn vẹn, quyền riêng tư, định nghĩa dữ liệu.	Định nghĩa trường dữ liệu, quy tắc bảo mật dữ liệu.
Chủ sở hữu hệ thống (System Owner)	Xác nhận tính khả thi kỹ thuật, hiệu năng.	Yêu cầu thay đổi cấu hình hạ tầng, tích hợp hệ thống.
Phòng Pháp lý/Tuân thủ (Legal/Compliance)	Xác nhận tính hợp pháp, tuân thủ quy định.	Yêu cầu báo cáo theo luật, quy định bảo vệ dữ liệu cá nhân.

5. Điều Kiện Dừng (Stop Conditions)

Khi nào nên từ chối hoặc tạm dừng xử lý một đầu vào.

Điều kiện dừng	Mô tả	Hậu quả nếu không dừng
Thiếu thông tin bắt buộc	Dữ liệu không hoàn chỉnh, không đủ để phân tích.	Phân tích sai, thiết kế thiếu sót, lãng phí thời gian BA.
Mâu thuẫn dữ liệu	Thông tin mới mâu thuẫn với nguồn tin cậy đã có.	Phát triển tính năng không nhất quán, tạo lỗi hệ thống.
Không rõ ràng/Mơ hồ	Nội dung không thể hiểu hoặc diễn giải nhất quán.	BA cần nhiều vòng làm rõ, rủi ro hiểu sai yêu cầu.
Nguồn không xác thực	Đầu vào không đến từ chủ sở hữu được ủy quyền.	Thay đổi không có thẩm quyền, vi phạm quy trình quản trị.
Dữ liệu lỗi thời/Hết hạn	Dữ liệu đã quá hạn sử dụng theo tiêu chí độ tươi.	Triển khai dựa trên thông tin không còn đúng, gây lỗi vận hành.

Applied

Tình huống: Nova Foods cần xử lý yêu cầu thay đổi quy trình nghiệp vụ (Business Process Change Request - BPCR). AI-assisted BA workflow cần đầu vào BPCR chất lượng.

Facts: Nova Foods nhận nhiều BPCR hàng ngày. Quy trình hiện tại dùng email và tài liệu Word đính kèm.

Current Behavior: 1. BPCR gửi qua email từ nhiều phòng ban. 2. Nội dung, định dạng, mức độ chi tiết của BPCR không nhất quán. 3. BA phải mất nhiều thời gian tổng hợp, chuẩn hóa thông tin, tìm người xác nhận.

Underlying Need: 1. Cần chuẩn hóa cấu trúc BPCR. 2. Cần xác thực nguồn gửi BPCR. 3. Cần kiểm tra nhanh chất lượng BPCR trước khi đưa vào phân tích AI.

Options: 1. Tạo biểu mẫu email chuẩn: Dễ triển khai, nhưng vẫn phụ thuộc người dùng tự điền đúng. 2. Triển khai cổng thông tin (portal) nội bộ với form nhập liệu có validation: Đảm bảo cấu trúc, xác thực người dùng, tích hợp kiểm tra chất lượng ban đầu. 3. Tích hợp chatbot AI: Thu thập thông tin tương tác, nhưng phức tạp và cần huấn luyện AI ban đầu.

Decision Criteria: Hiệu quả chuẩn hóa dữ liệu, chi phí triển khai, khả năng xác thực nguồn, dễ sử dụng cho người gửi.

Decision: Triển khai cổng thông tin nội bộ với form nhập liệu có validation. Portal đảm bảo dữ liệu có cấu trúc, xác thực người dùng qua hệ thống đăng nhập tập trung, áp dụng validation cơ bản ngay khi nhập.

Authority: Nova Foods Process Governance Committee (Ủy ban Quản trị Quy trình Nova Foods) phê duyệt.

Artifact: * /03-templates/NF-BPCR-FORM-V1.0.docx: Biểu mẫu chuẩn. * /06-qa/NF-INPUT-VALIDATION-RULES.xlsx: Danh sách quy tắc kiểm tra đầu vào. * Mermaid diagram: Sơ đồ kiểm tra BPCR.

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

flowchart TB
    A[Người gửi đăng nhập qua hệ thống tập trung]
    B{Portal xác thực<br/>người gửi?}
    C[Từ chối BPCR:<br/>Nguồn không hợp lệ]
    D[Người gửi nhập BPCR<br/>vào form có cấu trúc]
    E{Portal kiểm tra đủ trường bắt buộc theo<br/>NF-INPUT-VALIDATION-RULES?}
    F[Portal trả lại người gửi:<br/>Bổ sung thông tin]
    G{Portal kiểm tra đúng định dạng theo<br/>NF-INPUT-VALIDATION-RULES?}
    H[Portal trả lại người gửi:<br/>Sửa định dạng]
    I{Portal kiểm tra nhất quán với<br/>nguồn chuẩn Nova Foods?}
    J[Portal trả lại người gửi:<br/>Xử lý mâu thuẫn dữ liệu]
    K[Người gửi gửi BPCR]
    L[BA tiếp nhận BPCR<br/>đạt kiểm tra đầu vào]
    M[BA dùng AI để phân tích BPCR]

    A --> B
    B -- Không --> C
    B -- Có --> D
    D --> E
    E -- Không --> F
    F --> D
    E -- Có --> G
    G -- Không --> H
    H --> D
    G -- Có --> I
    I -- Không --> J
    J --> D
    I -- Có --> K
    K --> L
    L --> M

→ skipped: Web portal implementation details, add when detailed system design phase.

Consequence if Wrong: * Nếu chọn email template: Không giải quyết triệt để vấn đề định dạng, dễ sai sót. AI nhận input rác. * Nếu chọn chatbot: Chi phí cao, độ phức tạp lớn, thời gian triển khai dài, chưa phù hợp giai đoạn đầu.

Senior Lens

Quản trị vòng đời dữ liệu (Data Lifecycle Governance): Input không chỉ là điểm bắt đầu. Cần hiểu nguồn gốc (provenance), cách dữ liệu thay đổi, và khi nào nó hết giá trị. AI phụ thuộc vào dữ liệu "sạch" và "tươi". Dữ liệu không đạt chuẩn sẽ làm hỏng mô hình AI, dẫn đến "Garbage In, Garbage Out".

Cost of Delay (Chi phí chậm trễ): Thời gian BA dành cho việc làm sạch/chuẩn hóa input là chi phí ẩn. Tự động hóa kiểm tra đầu vào giảm đáng kể chi phí này và tăng hiệu quả của AI. Mỗi vòng lặp làm rõ yêu cầu không rõ ràng đều là lãng phí.

Escalation Path (Quy trình leo thang): Luôn xác định ai ra quyết định khi input bị từ chối hoặc cần làm rõ sâu. Không để BA tự mình "đoán" hoặc "phỏng đoán". Quy trình từ chối phải rõ ràng, có thông báo và lý do cụ thể.

Traceability (Khả năng truy vết): Mỗi input phải có ID duy nhất (ví dụ: BPCR-NF-20260807-001). ID này phải được dùng xuyên suốt vòng đời yêu cầu, từ khi tiếp nhận đến khi triển khai, và liên kết với các artifact khác như /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Điều này giúp kiểm toán và gỡ lỗi.

Quick Reference

Khía cạnh	Điểm cần nhớ
Chất lượng	Hoàn chỉnh, Chính xác, Nhất quán, Kịp thời, Phù hợp.
Nguồn	Phân loại rõ: Pháp lý, Nghiệp vụ, Kỹ thuật, Bên thứ ba, Không chính thức.
Độ tươi	Định nghĩa Validity Period, Review Cycle.
Chủ sở hữu	Gán trách nhiệm xác thực cho Business Owner, Data Owner.
Dừng	Từ chối ngay input thiếu, mâu thuẫn, không rõ ràng, nguồn không xác thực.

Bảng Tổng hợp Đầu vào cho Quy trình BA Hỗ trợ bởi AI (Nova Foods Mô phỏng)

Đây là bảng tổng hợp các đầu vào (inputs) cần thiết cho quy trình Phân tích nghiệp vụ (Business Analysis - BA) hỗ trợ bởi Trí tuệ nhân tạo (AI). Mỗi đầu vào được phân loại, gán định danh duy nhất, và có trạng thái chất lượng cùng các mục cần xác minh rõ ràng. Nova Foods là một môi trường mô phỏng giáo dục, mọi dữ liệu đều là tổng hợp (synthetic data).

ID Nguồn	Loại Nguồn (Source Type)	Mô tả Ngắn gọn (Brief Description)	Chủ Sở hữu (Owner)	Ngày Cập nhật (Last Updated)	Tình trạng Chất lượng (Quality Status)	Mục Xác minh (Verification Items)	Kết quả Mong đợi từ AI (Expected AI Output)
NF-LEGAL-001	Pháp lý (Legal)	Luật Bảo vệ dữ liệu cá nhân (PDPL) - Luật 91/2025/QH15	Phòng Pháp chế Nova Foods	2026-08-07	Đã xác minh	VERIFICATION_REQUIRED: Diễn giải chi tiết cho trường hợp Nova Foods. Quy tắc chuyển đổi dữ liệu sản xuất thành dữ liệu ẩn danh cho môi trường thử nghiệm.	Xác định các quy tắc bảo vệ dữ liệu, kiểm soát truy cập và yêu cầu báo cáo cho dữ liệu khách hàng Nova Foods.
NF-PROC-001	Quy trình (Process)	Quy trình Hiện hành: Xử lý Đơn hàng & Xuất Kho (Nova Foods)	Trưởng Bộ phận Vận hành	2026-08-01	Đã xác minh	Không có	Phân tích quy trình hiện tại, xác định điểm tắc nghẽn, đề xuất tối ưu hóa quy trình.
NF-REQ-005	Yêu cầu (Requirement)	Yêu cầu Chức năng Hệ thống Quản lý Kho mới v1.0	Product Owner Quản lý Kho	2026-07-28	Dự thảo	VERIFICATION_REQUIRED: Xác nhận đầy đủ các kịch bản người dùng (user stories) với Trưởng phòng Kho vận. Kiểm tra tính khả thi kỹ thuật các yêu cầu tích hợp ERP hiện có.	Phân tích yêu cầu, gợi ý kịch bản sử dụng bổ sung, tạo Acceptance Criteria (Tiêu chí chấp nhận) và User Stories (Câu chuyện người dùng).
NF-DD-001	Dữ liệu (Data)	Từ điển Dữ liệu Logic Sản phẩm Nova Foods (Logical Data Dictionary)	Kiến trúc sư Dữ liệu	2026-06-15	Đã xác minh	VERIFICATION_REQUIRED: Kiểm tra tính nhất quán với mô hình dữ liệu vật lý hiện tại của hệ thống ERP.	Xác định các thuộc tính dữ liệu cần thiết cho tính năng mới, gợi ý các ràng buộc (constraints) và mối quan hệ giữa các thực thể.
NF-MTG-012	Ghi nhận (Record)	Biên bản Họp Yêu cầu Người dùng về Giao diện Báo cáo Bán hàng	BA Nova Foods	2026-08-05	Cần xem xét	VERIFICATION_REQUIRED: Làm rõ các ưu tiên tính năng với Trưởng phòng Kinh doanh. Xác nhận thuật ngữ chuyên môn.	Tổng hợp các điểm chính, chuyển đổi thành yêu cầu giao diện người dùng (UI requirements) và phân loại theo mức độ ưu tiên.
NF-STD-001	Tiêu chuẩn (Standard)	Tiêu chuẩn An toàn Thực phẩm Quốc tế ISO 22000 (áp dụng nội bộ Nova Foods)	Quản lý Chất lượng Nova Foods	2026-03-10	Đã xác minh	VERIFICATION_REQUIRED: Xác định các điểm kiểm soát quan trọng (Critical Control Points - CCP) cần tích hợp vào hệ thống theo đặc thù sản phẩm Nova Foods.	Đảm bảo các yêu cầu truy xuất nguồn gốc (traceability) và an toàn thực phẩm được phản ánh trong thiết kế hệ thống.
NF-ACCT-002	Pháp lý (Legal)	Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ	Kế toán trưởng Nova Foods	2026-08-07	Đã xác minh	VERIFICATION_REQUIRED: Xác nhận cách xử lý hóa đơn điện tử cho các loại hình giao dịch đặc thù (ví dụ: khuyến mãi, trả hàng).	Đảm bảo tính tuân thủ của module xuất hóa đơn điện tử mới với quy định pháp luật.

5. Step-by-step BA Activities

Core

Hoạt động BA (Business Analyst Activities) liên quan đến hỗ trợ AI tập trung vào việc tận dụng công cụ trí tuệ nhân tạo để tăng tốc, cải thiện chất lượng các đầu ra BA truyền thống, đồng thời duy trì sự giám sát và kiểm soát của con người. Điều này đòi hỏi BA không chỉ hiểu nghiệp vụ mà còn phải biết cách giao tiếp hiệu quả với AI (thông qua prompt engineering – kỹ thuật tạo lời nhắc) và kiểm chứng chặt chẽ kết quả do AI tạo ra. Mục tiêu không phải là để AI thay thế BA mà là để AI trở thành một trợ lý đắc lực, giúp BA tập trung vào các hoạt động có giá trị cao hơn như phân tích sâu, đàm phán, và giải quyết vấn đề phức tạp.

Quy trình BA được trợ giúp bởi AI bao gồm các bước sau, từ chuẩn bị đến bàn giao, mỗi bước đều có vai trò, hành động, đối tượng, bằng chứng, quy tắc ra quyết định, cổng chất lượng và lộ trình leo thang rõ ràng.

1. Chuẩn bị và Lập kế hoạch AI (AI Preparation & Planning)

   • Vai trò (Actor): BA (Business Analyst).
   • Hành động (Action): Xác định mục tiêu cụ thể cho việc sử dụng AI (ví dụ: tạo bản nháp User Story, phân tích tài liệu hiện có, tóm tắt thông tin), phạm vi công việc, loại công cụ AI phù hợp, và thu thập các tài liệu nguồn đầu vào cần thiết.
   • Đối tượng (Object): Yêu cầu kinh doanh ban đầu (Business Requirements), tài liệu quy định (pháp lý, kế toán), quy trình hiện hành (AS-IS process), các ví dụ dữ liệu (sample data).
   • Bằng chứng (Evidence): Kế hoạch sử dụng AI, danh sách tài liệu nguồn (Source Document List – NF-AI-PLAN-001), tiêu chí chấp nhận (Acceptance Criteria) ban đầu cho đầu ra AI.
   • Quy tắc Quyết định (Decision Rule): Chỉ sử dụng AI cho các tác vụ tạo bản nháp hoặc phân tích dữ liệu sơ bộ; BA luôn là người ra quyết định cuối cùng.
   • Cổng chất lượng (Quality Gate): Tài liệu nguồn đầy đủ, không mâu thuẫn, mục tiêu sử dụng AI rõ ràng, phù hợp với chính sách sử dụng AI của tổ chức.
   • Lộ trình Leo thang (Escalation Route): Mục tiêu không rõ ràng, thiếu tài liệu nguồn quan trọng, rủi ro bảo mật dữ liệu đầu vào AI cao → Lead BA (Trưởng nhóm BA) / Project Manager (Quản lý dự án).

2. Thiết kế và Thực thi Lời nhắc AI (AI Prompt Design & Execution)

   • Vai trò (Actor): BA.
   • Hành động (Action): Xây dựng lời nhắc (prompt) chi tiết cho công cụ AI, cung cấp ngữ cảnh, định dạng đầu ra mong muốn và các ràng buộc (constraints). Thực thi lời nhắc trên nền tảng AI đã chọn.
   • Đối tượng (Object): Lời nhắc (Prompt – NF-AI-PROMPT-001), công cụ AI (ví dụ: Copilot, ChatGPT Enterprise), tài liệu nguồn đã chuẩn bị.
   • Bằng chứng (Evidence): Lời nhắc đã nhập, bản ghi tương tác với AI (AI Interaction Log – NF-AI-LOG-001), bản nháp đầu ra từ AI (AI Draft Output – NF-AI-DRAFT-002).
   • Quy tắc Quyết định (Decision Rule): Lời nhắc phải tuân thủ hướng dẫn "prompt engineering" nội bộ, đảm bảo không rò rỉ thông tin nhạy cảm.
   • Cổng chất lượng (Quality Gate): Lời nhắc rõ ràng, không mơ hồ, tạo ra kết quả có thể sử dụng được dưới dạng bản nháp sơ bộ.
   • Lộ trình Leo thang (Escalation Route): AI tạo ra đầu ra không liên quan, định dạng sai, hoặc từ chối xử lý → Technical Support (Hỗ trợ kỹ thuật) / AI Tool Administrator (Quản trị viên công cụ AI).

3. Xem xét, Hiệu chỉnh và Bổ sung Thủ công (Manual Review, Refinement & Augmentation)

   • Vai trò (Actor): BA.
   • Hành động (Action): Đánh giá kỹ lưỡng bản nháp từ AI về tính chính xác nghiệp vụ, độ đầy đủ, tính nhất quán và tuân thủ các quy định. Hiệu chỉnh, bổ sung các chi tiết chỉ BA mới nắm bắt được (ví dụ: sắc thái nghiệp vụ, mối quan hệ phức tạp, các yêu cầu ngầm).
   • Đối tượng (Object): Bản nháp đầu ra từ AI (NF-AI-DRAFT-002), tài liệu nguồn, kiến thức nghiệp vụ của BA.
   • Bằng chứng (Evidence): Bản nháp đã được đánh dấu sửa đổi, bản nháp tài liệu đã hiệu chỉnh (Refined Document Draft – NF-AI-REFINED-003), ghi chú phân tích của BA.
   • Quy tắc Quyết định (Decision Rule): Không bao giờ chấp nhận đầu ra từ AI mà không qua kiểm tra thủ công. BA phải chịu trách nhiệm cuối cùng về nội dung.
   • Cổng chất lượng (Quality Gate): Tài liệu chính xác nghiệp vụ 90% trở lên, không mâu thuẫn với tài liệu nguồn, không chứa lỗi ngữ pháp/logic cơ bản.
   • Lộ trình Leo thang (Escalation Route): AI liên tục tạo nội dung sai lệch nghiêm trọng, không thể sửa chữa hiệu quả → Lead BA (xem xét lại phương pháp hoặc công cụ AI).

4. Xác minh và Phê duyệt Nghiệp vụ (Business Verification & Approval)

   • **Vai trò (Actor): BA, Business Owner (Chủ nghiệp vụ), Subject Matter Expert (Chuyên gia nghiệp vụ – SME).
   • Hành động (Action): Trình bày tài liệu đã hiệu chỉnh cho Business Owner và SME để xác minh, thu thập phản hồi và nhận phê duyệt chính thức.
   • Đối tượng (Object): Tài liệu yêu cầu đã hiệu chỉnh và sẵn sàng để xem xét (NF-REQ-FINAL-DRAFT-001).
   • Bằng chứng (Evidence): Biên bản họp xác minh, email phê duyệt, chữ ký phê duyệt (Approval Signature – NF-APPROVAL-001), danh sách các thay đổi được yêu cầu (Change Request Log – NF-CR-LOG-001).
   • Quy tắc Quyết định (Decision Rule): Tài liệu yêu cầu phải được Business Owner phê duyệt chính thức trước khi chuyển sang giai đoạn phát triển hoặc kiểm thử.
   • Cổng chất lượng (Quality Gate): Tất cả các bên liên quan đã xem xét và đồng ý với nội dung, không còn bất kỳ yêu cầu quan trọng nào chưa được giải quyết.
   • Lộ trình Leo thang (Escalation Route): Business Owner hoặc SME không đồng ý với các yêu cầu cốt lõi, từ chối phê duyệt, hoặc yêu cầu thay đổi lớn ảnh hưởng đến tiến độ/phạm vi → Project Manager / Steering Committee (Ban chỉ đạo dự án).

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

   • Vai trò (Actor): BA.
   • Hành động (Action): Chuyển giao tài liệu yêu cầu đã được phê duyệt cho đội Phát triển (Development Team) và đội Kiểm thử (QA Team). Đảm bảo các đội này hiểu rõ yêu cầu và mục tiêu.
   • Đối tượng (Object): Tài liệu yêu cầu đã phê duyệt cuối cùng (NF-REQ-FINAL-001), ma trận truy vết yêu cầu (Requirement Traceability Matrix – NF-RTM-001).
   • Bằng chứng (Evidence): Thông báo bàn giao chính thức, biên bản họp bàn giao, check-in tài liệu vào hệ thống quản lý tài liệu (ví dụ: Jira, Confluence) với trạng thái "Đã phê duyệt".
   • Quy tắc Quyết định (Decision Rule): Handoff chỉ hoàn tất khi các bên nhận đã xác nhận hiểu rõ yêu cầu và có thể bắt đầu công việc.
   • Cổng chất lượng (Quality Gate): Tài liệu rõ ràng, dễ hiểu, có thể thực thi bởi đội phát triển và QA, không còn câu hỏi lớn chưa được trả lời.
   • Lộ trình Leo thang (Escalation Route): Đội Phát triển/QA không chấp nhận tài liệu do không rõ ràng, không đầy đủ hoặc có mâu thuẫn → Lead BA / Project Manager.

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

flowchart TB
    A["Bắt đầu"] --> B["BA — 1. Chuẩn bị và lập kế hoạch AI"]
    B --> C{"Mục tiêu rõ ràng; tài liệu đầy đủ, nhất quán; tuân thủ chính sách AI; rủi ro bảo mật chấp nhận được?"}
    C -->|Có| D["BA — 2. Thiết kế lời nhắc AI"]
    C -->|Không| E["Leo thang: Trưởng nhóm BA / Quản lý dự án"]
    E -->|Vấn đề đã giải quyết| B

    D --> F{"Lời nhắc rõ ràng, không mơ hồ; tuân thủ hướng dẫn nội bộ; không rò rỉ thông tin nhạy cảm?"}
    F -->|Không| D
    F -->|Có| X["BA — Thực thi lời nhắc AI"]

    X --> H{"Đầu ra liên quan, đúng định dạng, dùng được làm bản nháp và AI không từ chối xử lý?"}
    H -->|Có| G["BA — 3. Xem xét, hiệu chỉnh và bổ sung thủ công"]
    H -->|Không: sai nội dung, sai định dạng hoặc từ chối xử lý| I["Leo thang: Hỗ trợ kỹ thuật / Quản trị viên công cụ AI"]
    I -->|Vấn đề đã giải quyết| D

    G --> J{"Chính xác nghiệp vụ từ 90% trở lên; không mâu thuẫn nguồn; không có lỗi ngữ pháp hoặc logic cơ bản?"}
    J -->|Có| K["BA — 4. Trình bày tài liệu, thu thập phản hồi và điều phối xác minh, phê duyệt"]
    J -->|Không| L{"AI liên tục tạo sai lệch nghiêm trọng và không thể sửa hiệu quả?"}
    L -->|Không| G
    L -->|Có| M["Leo thang: Trưởng nhóm BA xem lại phương pháp hoặc công cụ AI"]
    M -->|Vấn đề đã giải quyết| D

    K --> N["SME — Xác minh nghiệp vụ<br/>Chủ nghiệp vụ — Xem xét và phê duyệt"]
    N --> O{"SME đã xác minh; Chủ nghiệp vụ đã phê duyệt; các bên liên quan đồng ý; không còn yêu cầu quan trọng chưa giải quyết?"}
    O -->|Có| Q["Phê duyệt chính thức<br/>Chữ ký phê duyệt — NF-APPROVAL-001"]
    O -->|Không| R{"Bất đồng cốt lõi, từ chối phê duyệt, hoặc thay đổi lớn ảnh hưởng tiến độ hay phạm vi?"}
    R -->|Không, cần hiệu chỉnh| G
    R -->|Có| S["Leo thang: Quản lý dự án / Ban chỉ đạo dự án"]
    S -->|Vấn đề đã giải quyết| G

    Q --> P["BA — 5. Bàn giao có kiểm soát<br/>Tài liệu yêu cầu đã phê duyệt<br/>Ma trận truy vết yêu cầu"]
    P --> T{"Đội Phát triển và đội Kiểm thử hiểu rõ, chấp nhận và có thể bắt đầu công việc?"}
    T -->|Có| U["Kết thúc: Yêu cầu sẵn sàng"]
    T -->|Không| V["Leo thang: Trưởng nhóm BA / Quản lý dự án"]
    V -->|Vấn đề đã giải quyết| P

Applied

Case Study: Sử dụng AI hỗ trợ phân tích tài liệu và tạo User Story cho Module Quản lý Đơn Đặt Hàng của Nova Foods

Nova Foods (mô phỏng) đang trong quá trình nâng cấp hệ thống ERP với module mới là "Quản lý Đơn Đặt Hàng" từ nhà phân phối. BA được giao nhiệm vụ nhanh chóng phác thảo các User Story ban đầu dựa trên các đơn hàng hiện có dạng Excel và mô tả quy trình thủ công.

Hạng mục	Chi tiết thực hiện
Sự kiện (Facts)	Nova Foods cần module quản lý đơn đặt hàng mới. Đơn hàng hiện đang được xử lý thủ công (ghi nhận trên Excel, email). Yêu cầu tốc độ triển khai nhanh.
Hành vi hiện tại (Current Behavior)	Phòng Kinh doanh (NF-SALES-DEPT) ghi đơn hàng vào NF-FORM-EXCEL-001. Kho vận (NF-WAREHOUSE-DEPT) nhận email từ Sales để xử lý. Tỷ lệ lỗi nhập liệu 5%, thời gian xử lý trung bình 24 giờ/đơn. Không có truy vết trạng thái đơn hàng tự động.
Nhu cầu cốt lõi (Underlying Need)	Giảm lỗi nhập liệu, tự động hóa quy trình, tăng tốc độ xử lý đơn hàng, cải thiện khả năng truy vết trạng thái đơn hàng (NF-ORDER-TRACKING-001).
Các Tùy chọn (Options)	1. BA phân tích tài liệu, phỏng vấn và tự viết User Story thủ công. 2. BA sử dụng công cụ AI để phân tích các mẫu đơn hàng Excel và bản mô tả quy trình thủ công, sau đó hiệu chỉnh kết quả do AI tạo ra.
Tiêu chí Quyết định (Decision Criteria)	1. Hiệu quả thời gian (Time Efficiency): Tối ưu hóa thời gian tạo bản nháp User Story. 2. Chất lượng ban đầu (Initial Quality): Mức độ chính xác và đầy đủ của bản nháp. 3. Rủi ro sai sót (Error Risk): Khả năng AI tạo ra thông tin không chính xác hoặc thiếu ngữ cảnh.
Quyết định (Decision)	Chọn tùy chọn 2: Sử dụng AI để phân tích mẫu đơn hàng Excel và mô tả quy trình thủ công, gợi ý User Story. Sau đó, BA sẽ hiệu chỉnh và bổ sung thủ công. Lý do: Tốc độ tạo bản nháp nhanh hơn, giải phóng thời gian BA cho việc tinh chỉnh và xác minh nghiệp vụ.
Thẩm quyền (Authority)	BA tự quyết định phương pháp luận với sự đồng thuận của Lead BA (NF-LEADBA-001). Quyết định này không yêu cầu phê duyệt từ Business Owner cho đến khi bản nháp yêu cầu hoàn chỉnh.
Tạo tác (Artifact Produced)	1. NF-AI-PROMPT-002: Lời nhắc AI để phân tích các mẫu đơn hàng Excel (NF-FORM-EXCEL-001) và mô tả quy trình hiện có. 2. NF-AI-DRAFT-003: Bản nháp User Story từ AI, ví dụ: "Với tư cách là Nhân viên Kinh doanh, tôi muốn nhập thông tin đơn hàng vào hệ thống để giảm lỗi nhập liệu và gửi đến kho tự động." 3. NF-REQ-US-001: User Story cuối cùng đã được BA hiệu chỉnh và Business Owner phê duyệt, bao gồm các chi tiết về trường dữ liệu, quy tắc nghiệp vụ và tiêu chí chấp nhận.
Hậu quả nếu sai (Consequence if Wrong)	Nếu AI tạo User Story không chính xác hoặc thiếu sót nghiêm trọng, BA sẽ phải dành nhiều thời gian hơn để hiệu chỉnh so với việc viết thủ công từ đầu, dẫn đến chậm trễ tiến độ. Nguy cơ bỏ sót các yêu cầu nghiệp vụ quan trọng hoặc các quy định tuân thủ (ví dụ: Luật Hóa đơn điện tử 123/2020/NĐ-CP về thông tin bắt buộc trên hóa đơn).

Phân tích hoạt động BA với AI

Phần này mô tả chi tiết các bước trong quy trình Business Analysis (BA) được hỗ trợ bởi Trí tuệ Nhân tạo (AI), xác định rõ từng yếu tố như diễn viên (Actor), hành động (Action), đối tượng (Object), bằng chứng tạo ra (Evidence Produced), quy tắc quyết định (Decision Rule), cổng chất lượng (Quality Gate) và lộ trình leo thang (Escalation Route) cho mỗi hoạt động.

Hoạt động (Step)	Diễn viên (Actor)	Hành động (Action)	Đối tượng (Object)	Bằng chứng tạo ra (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. Xác định phạm vi và thu thập tài liệu ban đầu	BA (Business Analyst)	Tiếp nhận đề bài, họp khởi động dự án (kick-off meeting), thu thập tài liệu dự án hiện có, quy trình nghiệp vụ (business process) hiện tại.	Đề xuất dự án (project proposal), điều lệ dự án (project charter), hồ sơ hệ thống hiện tại, mô tả nghiệp vụ từ chủ sở hữu sản phẩm (Product Owner).	Hồ sơ phạm vi dự án (Project Scope Document) sơ bộ, danh mục tài liệu nguồn (Source Document Register) đã phân loại.	Phạm vi được xác định rõ ràng, không mâu thuẫn. Các bên liên quan (stakeholders) chính được nhận diện đầy đủ.	Ký xác nhận từ PM (Project Manager) và Product Owner về phạm vi sơ bộ. Danh mục tài liệu nguồn được kiểm tra tính đầy đủ ban đầu.	Project Sponsor nếu có bất đồng về phạm vi không thể giải quyết nội bộ giữa BA, PM và Product Owner.
2. Tiền xử lý và chuẩn hóa dữ liệu nguồn	BA, chuyên viên dữ liệu (Data Specialist) (nếu cần)	Thu thập, làm sạch (cleanse), chuyển đổi (transform) dữ liệu phi cấu trúc (unstructured data) và bán cấu trúc (semi-structured data) thành định dạng phù hợp cho AI. Phân loại và gán nhãn Thông tin nhận dạng cá nhân (PII - Personally Identifiable Information) hoặc dữ liệu nhạy cảm khác.	Email, ghi chú cuộc họp, bản ghi phỏng vấn, tài liệu yêu cầu cũ, tài liệu thiết kế (design documents).	Corpus dữ liệu nguồn đã được chuẩn hóa, làm sạch và ẩn danh (Standardized and Anonymized Source Data Corpus). Nhật ký kiểm tra dữ liệu (Data Validation Log) và danh sách PII loại trừ (PII Exclusion List).	Dữ liệu phải có liên quan trực tiếp đến phạm vi, chất lượng đủ dùng. Không chứa PII không cần thiết hoặc được che giấu phù hợp theo chính sách bảo mật dữ liệu.	Rà soát ngẫu nhiên 10% dữ liệu đã làm sạch bởi BA. Chuyên gia bảo mật (Security Expert) xác nhận quy trình xử lý PII phù hợp với quy định.	Data Privacy Officer hoặc Legal team nếu phát hiện vi phạm pháp lý về dữ liệu hoặc có rủi ro bảo mật PII nghiêm trọng.
3. Khai thác yêu cầu sơ bộ với AI (AI-Assisted Preliminary Elicitation)	BA, công cụ AI (AI Tool)	Cung cấp Corpus dữ liệu đã chuẩn hóa cho công cụ AI. Yêu cầu AI trích xuất các yêu cầu tiềm năng (potential requirements), xác định khoảng trống thông tin (gaps), mâu thuẫn (conflicts) và đề xuất các câu hỏi cho phỏng vấn.	Corpus dữ liệu nguồn đã chuẩn hóa và ẩn danh, giao diện công cụ AI.	Danh sách yêu cầu thô được AI gợi ý (AI-Suggested Raw Requirements List), danh sách câu hỏi cần làm rõ (Clarification Questions List), báo cáo mâu thuẫn/không nhất quán (Conflict/Inconsistency Report) giữa các nguồn dữ liệu.	Output của AI phải có khả năng truy xuất nguồn gốc (traceable) từ dữ liệu đầu vào. AI không được "sáng tạo" yêu cầu mới không có căn cứ hoặc suy diễn ngoài ngữ cảnh nghiệp vụ được cung cấp.	BA xem xét tính hợp lý và đầy đủ của 20% yêu cầu thô được AI gợi ý. Đánh giá mức độ liên quan và tính hữu ích của các câu hỏi đề xuất.	Senior BA nếu chất lượng gợi ý từ AI thấp một cách đáng kể, hoặc AI tạo ra quá nhiều thông tin không chính xác/không có thật (hallucinations).
4. Phân tích và mô hình hóa yêu cầu (AI-Assisted Requirement Analysis & Modeling)	BA, công cụ AI	Sử dụng AI để nhóm các yêu cầu thô thành các chủ đề (themes), xác định sự phụ thuộc (dependencies) giữa các yêu cầu. Yêu cầu AI đề xuất các mô hình sơ bộ như sơ đồ quy trình (process diagrams) hoặc mô hình dữ liệu (data models).	Danh sách yêu cầu thô đã được gợi ý, báo cáo mâu thuẫn/không nhất quán, công cụ AI.	Các nhóm yêu cầu đã phân loại (Categorized Requirement Groups), sơ đồ mối quan hệ giữa các yêu cầu (Requirement Relationship Diagrams), bản nháp sơ đồ quy trình nghiệp vụ (Draft Business Process Diagrams - ví dụ: BPMN), hoặc mô hình dữ liệu logic (Logical Data Models - ví dụ: UML Class Diagram).	Mô hình phải phản ánh đúng ngữ cảnh nghiệp vụ đã được xác định, tuân thủ các quy ước mô hình hóa (ví dụ: BPMN, UML) nếu được chỉ định và không tạo ra các yêu cầu ngầm định mới.	BA kiểm tra tính nhất quán nội tại của mô hình, so sánh với các mục tiêu cấp cao của dự án. Thực hiện review mô hình sơ bộ với SME (Subject Matter Expert - chuyên gia nghiệp vụ) để kiểm tra tính đúng đắn.	Kiến trúc sư giải pháp (Solution Architect) hoặc Chuyên gia nghiệp vụ nếu có tranh cãi về thiết kế mô hình hoặc cần sâu hơn về nghiệp vụ để đưa ra quyết định kiến trúc.

Đây là biểu đồ quy trình tổng quan cho các hoạt động BA với AI:

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

flowchart TB
    subgraph BA["BA"]
        S1["1. Xác định phạm vi và thu thập tài liệu"]
        E1["Hồ sơ phạm vi sơ bộ<br/>Danh mục tài liệu nguồn"]
        R1["Kiểm tra tính đầy đủ ban đầu<br/>danh mục tài liệu nguồn"]
        D1{"Phạm vi rõ, không mâu thuẫn;<br/>stakeholder chính đã nhận diện;<br/>PM và Product Owner ký xác nhận;<br/>danh mục tài liệu nguồn đủ?"}
        F1["Chỉnh sửa phạm vi hoặc<br/>bổ sung tài liệu nguồn"]

        S2["2. Tiền xử lý và chuẩn hóa dữ liệu nguồn"]
        E2["Corpus đã chuẩn hóa, làm sạch, ẩn danh<br/>Data Validation Log<br/>PII Exclusion List"]
        R2["BA rà soát ngẫu nhiên 10%<br/>dữ liệu đã làm sạch"]
        D2{"Dữ liệu liên quan, đủ dùng;<br/>PII đã loại trừ hoặc che giấu?"}
        F2["Làm sạch, chuẩn hóa hoặc<br/>ẩn danh lại dữ liệu"]

        S3["3. Khai thác yêu cầu sơ bộ"]
        R3["BA kiểm tra tính hợp lý và đầy đủ<br/>của 20% yêu cầu thô;<br/>đánh giá tính hữu ích câu hỏi"]
        D3{"Output truy xuất được nguồn;<br/>không tạo yêu cầu mới không có căn cứ<br/>hoặc suy diễn ngoài ngữ cảnh?"}
        F3["Rà soát corpus hoặc<br/>làm lại khai thác AI"]

        S4["4. Phân tích và mô hình hóa yêu cầu"]
        E4["Nhóm yêu cầu<br/>Sơ đồ quan hệ yêu cầu<br/>Bản nháp quy trình hoặc mô hình dữ liệu"]
        R4["BA kiểm tra tính nhất quán nội tại<br/>và đối chiếu mục tiêu cấp cao"]
        D4{"Mô hình đúng ngữ cảnh, nhất quán;<br/>tuân thủ BPMN/UML khi được chỉ định;<br/>không tạo yêu cầu ngầm định mới?"}
        F4["Chỉnh sửa hoặc<br/>làm lại mô hình"]
        O4["Mô hình sơ bộ đã qua review"]
    end

    subgraph DS["Data Specialist (nếu cần)"]
        DS2["Hỗ trợ làm sạch và chuyển đổi dữ liệu"]
    end

    subgraph AI["Công cụ AI"]
        AI3["Trích xuất yêu cầu tiềm năng,<br/>gaps, conflicts, câu hỏi phỏng vấn"]
        E3["Danh sách yêu cầu thô<br/>Clarification Questions List<br/>Conflict/Inconsistency Report"]
        AI4["Nhóm yêu cầu, xác định phụ thuộc,<br/>đề xuất mô hình sơ bộ"]
    end

    subgraph Review["Xác nhận chất lượng"]
        PMPO["PM và Product Owner<br/>ký xác nhận phạm vi sơ bộ"]
        SEC["Security Expert<br/>xác nhận xử lý PII"]
        SME["SME review tính đúng đắn nghiệp vụ<br/>của mô hình sơ bộ"]
    end

    subgraph Escalation["Leo thang"]
        SP["Project Sponsor<br/>bất đồng phạm vi không giải quyết nội bộ"]
        DPO["Data Privacy Officer hoặc Legal team<br/>rủi ro PII nghiêm trọng / vi phạm pháp lý"]
        SBA["Senior BA<br/>gợi ý AI kém hoặc hallucination nhiều"]
        SA["Solution Architect hoặc SME<br/>tranh cãi thiết kế mô hình hoặc cần<br/>chuyên môn nghiệp vụ sâu hơn để đưa ra<br/>quyết định kiến trúc"]
    end

    S1 --> E1 --> R1 --> PMPO --> D1
    D1 -- "Đạt" --> S2
    D1 -- "Chưa đạt" --> F1 --> S1
    D1 -- "Bất đồng không giải quyết nội bộ" --> SP

    DS2 -. "hỗ trợ" .-> S2
    S2 --> E2 --> R2 --> SEC --> D2
    D2 -- "Đạt: corpus đã chuẩn hóa và ẩn danh" --> S3
    D2 -- "Chưa đạt" --> F2 --> S2
    D2 -- "Rủi ro PII nghiêm trọng / vi phạm pháp lý" --> DPO

    S3 --> AI3 --> E3 --> R3 --> D3
    D3 -- "Đạt: yêu cầu thô + báo cáo mâu thuẫn" --> S4
    D3 -- "Chưa đạt" --> F3 --> S3
    D3 -- "Chất lượng thấp / hallucination nhiều" --> SBA

    S4 --> AI4 --> E4 --> R4 --> SME --> D4
    D4 -- "Đạt" --> O4
    D4 -- "Chưa đạt" --> F4 --> S4
    D4 -- "Tranh cãi thiết kế mô hình / cần chuyên môn nghiệp vụ sâu hơn" --> SA

Ví dụ minh họa: Phân tích tài liệu nguồn có AI cho Quản lý tồn kho lạnh Nova Foods

Applied

Facts: Nova Foods mở rộng sản xuất, cần module ERP Quản lý tồn kho lạnh mới. Nhiều tài liệu nguồn tồn tại: chính sách nội bộ (Nova Foods Internal Policy), quy định pháp luật (Luật An toàn thực phẩm số 55/2010/QH12), đặc tả hệ thống kế thừa.

Current Behavior: BA đọc thủ công hàng trăm trang tài liệu. Ghi chú, tổng hợp yêu cầu. Quá trình này tốn thời gian, dễ bỏ sót yêu cầu, đặc biệt yêu cầu tuân thủ.

Underlying Need: Cần trích xuất yêu cầu nhanh, chính xác từ khối lượng tài liệu lớn. Đảm bảo module mới tuân thủ Luật An toàn thực phẩm và quy trình nghiệp vụ Nova Foods. Giảm rủi ro bỏ sót yêu cầu quan trọng.

Options: 1. Thủ công: BA đọc và phân tích từng tài liệu. Phụ thuộc kinh nghiệm, dễ sai sót. 2. AI hỗ trợ: Dùng công cụ phân tích tài liệu dựa trên Xử lý ngôn ngữ tự nhiên (NLP-based document analyzer). AI trích xuất thực thể, tóm tắt đoạn văn, nhận diện yêu cầu tiềm năng.

Decision Criteria: * Hiệu quả thời gian: Giảm thời gian trích xuất yêu cầu. * Độ chính xác: Phát hiện yêu cầu ẩn, giảm sai sót so với thủ công. * Khả năng tuân thủ: Đảm bảo nhận diện đúng quy định pháp luật, chính sách nội bộ.

Decision: Chọn phương án AI hỗ trợ phân tích tài liệu nguồn. BA vẫn là người kiểm tra, tinh chỉnh cuối cùng.

Authority: Trưởng phòng BA Nova Foods, Giám đốc dự án ERP.

Artifact: Danh sách yêu cầu chức năng (Functional Requirements List - FRL), Ma trận truy vết (Traceability Matrix), Báo cáo tổng hợp từ AI, Danh sách câu hỏi cần làm rõ với chuyên gia nghiệp vụ (SME - Subject Matter Expert).

Consequence if Wrong: * Yêu cầu thiếu/sai: Hệ thống quản lý kho lạnh không hoạt động đúng, gây gián đoạn vận hành, mất hàng hóa, lãng phí tài nguyên Nova Foods. * Thiếu tuân thủ: Vi phạm Luật An toàn thực phẩm, bị phạt hành chính, ảnh hưởng nghiêm trọng uy tín Nova Foods, rủi ro pháp lý.

Quy trình BA chi tiết với AI hỗ trợ:

Bước	Diễn giải	Tác nhâ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	Chuẩn bị tài liệu nguồn	BA	Thu thập, phân loại, xác minh phiên bản	Tài liệu nghiệp vụ (quy trình, chính sách Nova Foods), luật (Luật An toàn thực phẩm), đặc tả hệ thống cũ.	Danh mục tài liệu nguồn đã được xác định (Source Document Register).	Tài liệu là phiên bản chính thức, được phê duyệt bởi Business Owner.	Trưởng nhóm BA kiểm tra tính đầy đủ, hợp lệ của tài liệu.	Thiếu tài liệu quan trọng, tài liệu lỗi thời: Trưởng phòng BA -> Business Owner.
2	Cấu hình công cụ AI	BA	Chọn công cụ AI (ví dụ: NLP-based document analyzer), cấu hình tham số, từ khóa, ngữ cảnh Nova Foods.	Công cụ AI hỗ trợ BA.	Cấu hình công cụ AI đã lưu.	Tham số cấu hình khớp với mục tiêu phân tích, ngôn ngữ (Tiếng Việt) và nghiệp vụ cụ thể.	Chuyên gia công nghệ/Trưởng nhóm BA xem xét cấu hình ban đầu, kiểm tra tính hiệu quả.	Công cụ không hoạt động, không hiểu ngữ cảnh: Chuyên gia AI/Trưởng nhóm BA.
3	Phân tích tài liệu với AI	BA, Công cụ AI	Tải tài liệu nguồn lên, chạy phân tích tự động, xem xét kết quả thô của AI.	Báo cáo phân tích AI (AI Analysis Report) gồm: danh sách thực thể, tóm tắt, yêu cầu tiềm năng.	Báo cáo phân tích AI, danh sách yêu cầu thô được trích xuất.	Yêu cầu thô phải có căn cứ rõ ràng từ tài liệu gốc, không phải suy diễn của AI.	BA kiểm tra chéo 10-20% kết quả tự động, đối chiếu với hiểu biết nghiệp vụ ban đầu.	AI bỏ sót hoặc nhận diện sai yêu cầu trọng yếu: Trưởng nhóm BA -> Chuyên gia nghiệp vụ (SME).
4	Tinh chỉnh yêu cầu	BA	Đọc kỹ kết quả AI, làm rõ các điểm chưa rõ, tổng hợp, đặt câu hỏi cho SME. Chuyển yêu cầu thô thành yêu cầu chức năng (Functional Requirements) hoàn chỉnh.	Danh sách yêu cầu chức năng đã tinh chỉnh (Refined FRL).	Yêu cầu phải cụ thể, đo lường được, khả thi và có thể kiểm thử.	Review nhóm BA nội bộ; SME review các yêu cầu nghiệp vụ để đảm bảo độ chính xác.	Mâu thuẫn giữa kết quả AI và hiểu biết SME, yêu cầu chưa rõ ràng: Trưởng phòng BA -> Business Owner.
5	Phê duyệt và bàn giao	BA	Trình danh sách yêu cầu chức năng cuối cùng cho các bên liên quan, thu thập phê duyệt, bàn giao cho đội phát triển.	Yêu cầu chức năng đã phê duyệt, biên bản phê duyệt, Ma trận truy vết (Traceability Matrix).	Có chữ ký phê duyệt chính thức từ Business Owner và Trưởng phòng BA.	Business Owner phê duyệt chính thức.	Yêu cầu không được phê duyệt, thiếu đồng thuận nghiêm trọng: Giám đốc dự án.

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

graph TB
    subgraph "Quy trình BA có AI hỗ trợ: Phân tích tài liệu nguồn"
        A([Bắt đầu: BA]) --> B["Bước 1: BA chuẩn bị tài liệu nguồn<br/>Bằng chứng: Source Document Register"]
        B --> C{"Trưởng nhóm BA kiểm tra:<br/>tài liệu đầy đủ, hợp lệ?<br/>Business Owner phê duyệt<br/>phiên bản chính thức?"}
        C -- Có --> D["Bước 2: BA cấu hình công cụ AI<br/>Bằng chứng: Cấu hình AI đã lưu"]
        C -- Không --> C1["Leo thang: Trưởng phòng BA,<br/>Business Owner"]
        C1 --> B

        D --> E{"Chuyên gia công nghệ và<br/>Trưởng nhóm BA: cấu hình phù hợp<br/>mục tiêu, tiếng Việt, nghiệp vụ?"}
        E -- Có --> F["Bước 3: BA và công cụ AI<br/>phân tích tài liệu<br/>Bằng chứng: AI Analysis Report,<br/>danh sách yêu cầu thô"]
        E -- Không --> E1["Leo thang: Chuyên gia AI,<br/>Trưởng nhóm BA"]
        E1 --> D

        F --> G{"BA kiểm tra chéo 10–20%:<br/>yêu cầu thô có căn cứ<br/>tài liệu gốc?"}
        G -- Có --> H["Bước 4: BA tinh chỉnh yêu cầu,<br/>tạo FRL và câu hỏi SME"]
        G -- Không --> G1["Leo thang: Trưởng nhóm BA,<br/>SME"]
        G1 --> F

        H --> I{"Review nội bộ nhóm BA:<br/>FRL cụ thể, đo lường được,<br/>khả thi, kiểm thử được?"}
        I -- Có --> M{"SME review nghiệp vụ:<br/>yêu cầu chính xác, rõ ràng?"}
        I -- Không --> I1["Leo thang: Trưởng phòng BA,<br/>Business Owner"]
        I1 --> H

        M -- Có --> J["Bước 5: BA trình phê duyệt và bàn giao<br/>FRL, Ma trận truy vết,<br/>Biên bản phê duyệt"]
        M -- Không --> M1["Leo thang: Trưởng phòng BA,<br/>Business Owner"]
        M1 --> H

        J --> L{"Business Owner và Trưởng phòng BA<br/>đã phê duyệt, ký chính thức?"}
        L -- Có --> K([Kết thúc: Yêu cầu chức năng sẵn sàng])
        L -- Không --> J1["Leo thang: Giám đốc dự án"]
        J1 --> J

        style A fill:#ECECFF,stroke:#333,stroke-width:2px,color:#000
        style K fill:#ECECFF,stroke:#333,stroke-width:2px,color:#000
        style C fill:#FFFFCC,stroke:#333,stroke-width:1px,color:#000
        style E fill:#FFFFCC,stroke:#333,stroke-width:1px,color:#000
        style G fill:#FFFFCC,stroke:#333,stroke-width:1px,color:#000
        style I fill:#FFFFCC,stroke:#333,stroke-width:1px,color:#000
        style M fill:#FFFFCC,stroke:#333,stroke-width:1px,color:#000
        style L fill:#FFFFCC,stroke:#333,stroke-width:1px,color:#000
        style C1 fill:#FFCCCC,stroke:#333,stroke-width:1px,color:#000
        style E1 fill:#FFCCCC,stroke:#333,stroke-width:1px,color:#000
        style G1 fill:#FFCCCC,stroke:#333,stroke-width:1px,color:#000
        style I1 fill:#FFCCCC,stroke:#333,stroke-width:1px,color:#000
        style M1 fill:#FFCCCC,stroke:#333,stroke-width:1px,color:#000
        style J1 fill:#FFCCCC,stroke:#333,stroke-width:1px,color:#000
    end

6. Output thu ???c

Core

Hoạt động phân tích nghiệp vụ (Business Analysis - BA) tạo ra nhiều sản phẩm công việc, được gọi là artifacts (kết quả công việc) hay outputs (đầu ra). Các outputs này là nền tảng cho các giai đoạn tiếp theo của dự án như thiết kế, phát triển và kiểm thử. Việc định nghĩa rõ ràng từng artifact giúp đảm bảo chất lượng, tính nhất quán và khả năng truy vết (traceability) xuyên suốt vòng đời phát triển phần mềm.

Mỗi artifact cần được định nghĩa với các thuộc tính cơ bản sau để đảm bảo quản trị: * Canonical ID (mã định danh chuẩn): Mã duy nhất để tham chiếu đến artifact đó, giúp truy vết và quản lý phiên bản. * Owner (người sở hữu/chịu trách nhiệm chính): Cá nhân hoặc vai trò chịu trách nhiệm chính về nội dung, cập nhật và chất lượng của artifact. * Status (trạng thái): Tình trạng hiện tại của artifact (ví dụ: DRAFT, IN_REVIEW, APPROVED). * Minimum Content (nội dung tối thiểu): Các thông tin bắt buộc phải có trong artifact để nó được coi là hợp lệ và hữu ích. * Change-History Obligation (nghĩa vụ lịch sử thay đổi): Quy định về việc ghi nhận các thay đổi, ai thay đổi, khi nào và tại sao.

Dưới đây là các artifact chính được tạo ra từ quy trình BA hỗ trợ AI:

1. Yêu cầu Thô (Raw Requirement)

   • Mục đích: Ghi nhận các yêu cầu ban đầu từ các bên liên quan hoặc từ kết quả phân tích của AI, thường chưa được tinh chỉnh.
   • Canonical ID: NF-REQ-RAW-YYYYMMDD-SEQ (Ví dụ: NF-REQ-RAW-20260807-001)
   • Owner: Chuyên viên Phân tích Nghiệp vụ (BA)
   • Status: DRAFT (Bản nháp), IN_REVIEW (Đang xem xét)
   • Minimum Content:
     • Tên yêu cầu: Mô tả ngắn gọn về vấn đề hoặc mong muốn.
     • Mô tả sơ bộ: Diễn giải ban đầu, có thể chứa nhiều thông tin chưa rõ ràng hoặc trùng lặp.
     • Nguồn gốc: Chỉ rõ ai đưa ra yêu cầu (ví dụ: SME A, AI Output) và khi nào.
   • Change-History Obligation: Ghi nhận thời điểm tạo, người tạo và mọi chỉnh sửa lớn (ví dụ: hợp nhất các yêu cầu tương tự, tách yêu cầu phức tạp thành các phần nhỏ hơn).

2. Bộ Câu hỏi Bổ sung (Additional Questions Set)

   • Mục đích: Tập hợp các câu hỏi cần làm rõ hoặc khai thác thêm thông tin từ các bên liên quan để biến yêu cầu thô thành yêu cầu tinh chỉnh.
   • Canonical ID: NF-QSET-YYYYMMDD-SEQ (Ví dụ: NF-QSET-20260807-001)
   • Owner: Chuyên viên Phân tích Nghiệp vụ (BA)
   • Status: DRAFT (Bản nháp), SHARED (Đã chia sẻ để thu thập phản hồi)
   • Minimum Content:
     • ID Câu hỏi: Mã định danh duy nhất cho từng câu hỏi.
     • Nội dung câu hỏi: Câu hỏi cụ thể cần trả lời.
     • Liên quan đến yêu cầu: Tham chiếu đến NF-REQ-RAW-YYYYMMDD-SEQ mà câu hỏi này nhằm làm rõ.
     • Đối tượng cần trả lời: Tên hoặc vai trò của SME (Subject Matter Expert - Chuyên gia nghiệp vụ) cần cung cấp thông tin.
     • Trạng thái: PENDING (Đang chờ), ANSWERED (Đã trả lời), CLOSED (Đã đóng).
   • Change-History Obligation: Ghi nhận thời điểm tạo, người tạo và khi câu hỏi được trả lời hoặc trạng thái thay đổi.

3. Danh sách Rủi ro & Giả định (Risk & Assumption List)

   • Mục đích: Xác định và ghi nhận các yếu tố rủi ro tiềm ẩn (risks) có thể ảnh hưởng đến dự án hoặc yêu cầu, và các giả định (assumptions) mà dự án đang dựa vào.
   • Canonical ID: NF-RISK-ASSUMP-YYYYMMDD-SEQ (Ví dụ: NF-RISK-ASSUMP-20260807-001)
   • Owner: Chuyên viên Phân tích Nghiệp vụ (BA)
   • Status: DRAFT (Bản nháp), REVIEWED (Đã xem xét)
   • Minimum Content:
     • ID: Mã định danh duy nhất.
     • Loại: RISK (Rủi ro) hoặc ASSUMPTION (Giả định).
     • Mô tả: Diễn giải chi tiết về rủi ro hoặc giả định.
     • Tác động: Hậu quả nếu rủi ro xảy ra hoặc giả định sai.
     • Mức độ ưu tiên: CAO, TRUNG BÌNH, THẤP.
     • Chiến lược/Hành động: Kế hoạch xử lý rủi ro (ví dụ: giảm thiểu, chấp nhận) hoặc cách xác minh giả định.
   • Change-History Obligation: Ghi nhận thời điểm tạo, người tạo và mọi cập nhật về mức độ, chiến lược hoặc trạng thái xử lý.

4. Danh sách Yêu cầu Chức năng (Functional Requirements List - FRL)

   • Mục đích: Ghi nhận các yêu cầu nghiệp vụ đã được tinh chỉnh, rõ ràng, có thể kiểm thử được, làm cơ sở chính thức cho các hoạt động thiết kế, phát triển và kiểm thử phần mềm.
   • Canonical ID: NF-FRL-YYYYMMDD-SEQ (Ví dụ: NF-FRL-20260807-001)
   • Owner: Chuyên viên Phân tích Nghiệp vụ (BA)
   • Status: DRAFT (Bản nháp), IN_REVIEW (Đang xem xét), FINAL_DRAFT (Bản nháp cuối cùng), APPROVED (Đã phê duyệt).
   • Minimum Content:
     • FR-ID: Mã định danh yêu cầu chức năng duy nhất (ví dụ: FR-NF-ERP-WH-IN-001).
     • Tên yêu cầu: Mô tả ngắn gọn chức năng.
     • Mô tả chi tiết: Chức năng làm gì, tại sao cần, ai dùng.
     • Tiêu chí chấp nhận (Acceptance Criteria - AC): Các điều kiện cụ thể để xác định yêu cầu đã hoàn thành và hoạt động đúng (thường dưới dạng Given-When-Then).
     • Ưu tiên: Mức độ quan trọng (ví dụ: P1 - Must-have, P2 - Should-have, P3 - Could-have).
     • Nguồn gốc: Tham chiếu đến yêu cầu thô (NF-REQ-RAW-YYYYMMDD-SEQ), các cuộc họp, hoặc output từ AI đã hỗ trợ.
   • Change-History Obligation: Mọi thay đổi lớn (thêm, sửa, xóa yêu cầu, thay đổi trạng thái, ưu tiên) phải được ghi nhận đầy đủ kèm lý do, ngày, và người thực hiện.

5. Biên bản Phê duyệt (Approval Minutes)

   • Mục đích: Ghi lại các quyết định quan trọng, đặc biệt là việc phê duyệt các artifact chính (như FRL), đảm bảo có bằng chứng về sự đồng thuận của các bên liên quan.
   • Canonical ID: NF-MM-YYYYMMDD-MEETINGTYPE-SEQ (Ví dụ: NF-MM-20260807-FRL-APP-001)
   • Owner: Chuyên viên Phân tích Nghiệp vụ (BA) hoặc Thư ký cuộc họp.
   • Status: FINAL (Hoàn thành)
   • Minimum Content:
     • Ngày và giờ họp: Thời điểm diễn ra cuộc họp.
     • Thành phần tham dự: Danh sách những người có mặt.
     • Nội dung thảo luận chính: Các điểm được đưa ra bàn bạc.
     • Các quyết định đã được thông qua: Đặc biệt là quyết định phê duyệt FRL kèm theo phiên bản của FRL.
     • Người phê duyệt: Tên và vai trò của người đã phê duyệt.
     • Các hành động tiếp theo (Action Items): Nhiệm vụ được giao, người chịu trách nhiệm và thời hạn.
   • Change-History Obligation: Chỉ có thể sửa để chỉnh lỗi chính tả hoặc làm rõ; mọi thay đổi lớn sau khi ban hành phải thông qua phụ lục hoặc biên bản mới.

Applied

Để hiểu rõ hơn việc định nghĩa artifact, ta xem xét một ví dụ cụ thể cho Danh sách Yêu cầu Chức năng (Functional Requirements List - FRL) trong bối cảnh Nova Foods (mô phỏng).

Thuộc tính	Định nghĩa	Ví dụ cho Nova Foods (mô phỏng)
Canonical ID	Mã định danh chuẩn, duy nhất cho FRL.	NF-FRL-20260807-001
Owner	Cá nhân hoặc vai trò chịu trách nhiệm chính về nội dung và quản lý FRL.	Chuyên viên Phân tích Nghiệp vụ (BA) Mai Thị B.
Status	Tình trạng hiện tại của FRL trong quy trình làm việc.	IN_REVIEW
Minimum Content	Các mục thông tin bắt buộc phải có trong mỗi yêu cầu chức năng thuộc FRL.
FR-ID	Mã định danh duy nhất cho từng yêu cầu chức năng.	FR-NF-ERP-WH-IN-001
Tên yêu cầu	Mô tả ngắn gọn về chức năng.	Ghi nhận nhập kho nguyên liệu thô bằng mã vạch
Mô tả chi tiết	Diễn giải đầy đủ về chức năng, mục đích và người sử dụng.	Người dùng là Thủ kho, muốn quét mã vạch trên mỗi lô nguyên liệu nhập kho để hệ thống tự động ghi nhận số lượng, ngày nhập, hạn sử dụng và ID lô duy nhất, nhằm giảm thiểu sai sót nhập liệu và đảm bảo truy xuất nguồn gốc.
Tiêu chí chấp nhận (AC)	Các điều kiện cụ thể để xác nhận yêu cầu đã hoàn thành.	Given Thủ kho quét mã vạch hợp lệ của lô hàng X (ví dụ: Thịt bò tươi, Lô TB20260807A) And Lô hàng X có liên kết với một Đơn đặt hàng (PO) đang chờ nhập When Hệ thống xác nhận mã vạch và hiển thị thông tin lô, số lượng dự kiến trên PO Then Thủ kho xác nhận số lượng thực tế nhập và ngày hết hạn And Hệ thống tạo bản ghi nhập kho mới với trạng thái "Đã nhập" và gán một ID nhập kho duy nhất (WH-IN-20260807-005) And Hệ thống cập nhật trạng thái PO thành "Đã nhập một phần" hoặc "Đã nhập đủ" And Thông tin lô và hạn sử dụng được lưu trữ.
Ưu tiên	Mức độ quan trọng của yêu cầu.	P1 (Must-have)
Nguồn gốc	Tham chiếu đến yêu cầu thô hoặc nguồn phát sinh yêu cầu.	Yêu cầu thô NF-REQ-RAW-20260806-003, Thảo luận với Thủ kho Nguyễn Văn A.
Change-History Obligation	Quy định về việc ghi nhận các thay đổi đối với FRL.	Mọi thay đổi lớn (thêm, sửa, xóa yêu cầu, thay đổi trạng thái, ưu tiên) phải được ghi nhận kèm lý do, ngày và người thực hiện.

Senior Lens

Việc định nghĩa rõ ràng các outputs là một nguyên tắc cốt lõi của quản trị dự án hiệu quả. Một BA cấp cao hiểu rằng mỗi artifact không chỉ là một tài liệu mà còn là một "hợp đồng" với các bên liên quan. FRL rõ ràng giúp giảm thiểu rủi ro hiểu sai, tránh phát sinh yêu cầu không mong muốn (scope creep) và tạo nền tảng vững chắc cho kiểm thử và phát triển.

Nghĩa vụ lịch sử thay đổi đặc biệt quan trọng. Nó không chỉ là việc ghi lại, mà còn là công cụ để giải quyết mâu thuẫn, truy cứu trách nhiệm khi có vấn đề và đảm bảo rằng mọi quyết định đều có bằng chứng. Sự thiếu hụt hoặc mơ hồ trong định nghĩa outputs sẽ dẫn đến tốn kém thời gian và chi phí trong các giai đoạn sau.

Quick Reference

Artifact Type	Canonical ID Pattern	Owner	Key Status	Change Obligation
Yêu cầu Thô (Raw Req)	NF-REQ-RAW-YYYYMMDD-SEQ	BA	DRAFT	Ghi nhận sửa đổi lớn.
Bộ Câu hỏi (Questions)	NF-QSET-YYYYMMDD-SEQ	BA	SHARED	Ghi nhận trả lời.
Rủi ro & Giả định (R&A)	NF-RISK-ASSUMP-YYYYMMDD-SEQ	BA	REVIEWED	Ghi nhận cập nhật.
Yêu cầu Chức năng (FRL)	NF-FRL-YYYYMMDD-SEQ	BA	APPROVED	Ghi nhận mọi thay đổi lớn.
Biên bản Phê duyệt (MM)	NF-MM-YYYYMMDD-TYPE-SEQ	BA	FINAL	Chỉ sửa lỗi chính tả/làm rõ.

Cấu trúc và Ví dụ về các Đầu ra từ Quy trình BA

Các đầu ra (outputs) của quy trình Phân tích nghiệp vụ (Business Analysis - BA) là các sản phẩm công việc hữu hình (artifacts) được tạo ra hoặc cập suất trong suốt vòng đời dự án. Mỗi đầu ra có một mục đích cụ thể, hỗ trợ việc truyền đạt thông tin, xác nhận yêu cầu và giảm thiểu rủi ro.

Core

Mỗi đầu ra cần tuân thủ một cấu trúc nhất định để đảm bảo tính nhất quán, khả năng truy vết (traceability) và chất lượng. Dưới đây là các thuộc tính cơ bản của một artifact đầu ra:

Thuộc tính (Attribute)	Mô tả (Description)	Ghi chú (Notes)
Artifact ID	Định danh duy nhất, canonical.	Thường có tiền tố dự án (ví dụ: NF- cho Nova Foods), loại artifact (US, BRS, BPMN), số thứ tự. Ví dụ: NF-US-SALES-001.
Tên tệp (Filename)	Đường dẫn và tên file chuẩn của artifact.	Đảm bảo tính nhất quán trong corpus. Ví dụ: /03-templates/nova-foods/us-sales-001-customer-registration.md.
Tiêu đề (Title)	Tên gọi ngắn gọn, mô tả nội dung chính.	Phản ánh rõ ràng mục đích của artifact. Ví dụ: [US] Đăng ký Khách hàng mới.
Chủ sở hữu (Owner)	Cá nhân/vai trò chịu trách nhiệm chính.	Duy trì, cập nhật, đảm bảo chất lượng. Thường là BA, Product Owner (PO) hoặc Data Steward.
Trạng thái (Status)	Tình trạng hiện tại của artifact.	DRAFT (Nháp), IN_REVIEW (Đang xem xét), APPROVED (Đã phê duyệt), BASELINED (Đã chốt phiên bản).
Nội dung tối thiểu	Các thành phần bắt buộc phải có.	Đảm bảo tính hoàn chỉnh và hữu ích cho người dùng hạ nguồn. Ví dụ: User Story cần có "As a.. I want.. so that.." và AC.
Nghĩa vụ lịch sử thay đổi	Cách thức ghi nhận và quản lý thay đổi.	Bao gồm Version, Ngày, Tác giả, Mô tả thay đổi. Đảm bảo tính truy vết và minh bạch.
Cổng chất lượng	Tiêu chí để artifact sẵn sàng cho bước tiếp theo.	Không phải là "phê duyệt sản xuất" hay "sẵn sàng triển khai". Ví dụ: "AC phải testable", "Không có bình luận mở từ SME".
Tham chiếu nguồn	Liên kết đến các nguồn thông tin đầu vào.	Bao gồm các ID từ TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc nguồn pháp lý.

Applied

Dưới đây là một số ví dụ minh họa về các đầu ra trong ngữ cảnh Nova Foods, bao gồm metadata đầy đủ và nội dung mẫu.

Ví dụ 1: User Story (Câu chuyện người dùng)

Mô tả: User Story là một mô tả ngắn gọn, đơn giản về một tính năng từ góc nhìn của người dùng hoặc stakeholder. Nó tập trung vào giá trị mang lại.

Thuộc tính	Giá trị
Artifact ID	NF-US-SALES-001
Tên tệp	/03-templates/nova-foods/us-sales-001-customer-registration.md
Tiêu đề	[US] Đăng ký Khách hàng mới cho hệ thống ERP Nova Foods
Chủ sở hữu	Business Analyst (BA) / Product Owner (PO)
Trạng thái	IN_REVIEW

---

Nội dung User Story (NF-US-SALES-001):

As a Nhân viên Kinh doanh Nova Foods, I want to đăng ký thông tin khách hàng mới vào hệ thống ERP, So that tôi có thể tạo đơn hàng và theo dõi lịch sử mua hàng của họ một cách hiệu quả.

Acceptance Criteria (AC): 1. Hệ thống phải cho phép nhập các thông tin cơ bản của khách hàng: Tên Khách hàng, Địa chỉ giao hàng chính, Số điện thoại liên hệ, Email, và Mã số thuế (nếu khách hàng là doanh nghiệp). 2. Sau khi đăng ký thành công, hệ thống phải tự động sinh Mã Khách hàng duy nhất theo định dạng NF-CYYYYMMDDHHMMSS (ví dụ: NF-C20260807153045). 3. Khi nhập Mã số thuế, hệ thống phải kiểm tra tính hợp lệ của mã theo cấu trúc chuẩn Việt Nam (10 hoặc 13 chữ số, có hoặc không có dấu gạch ngang). Nếu không hợp lệ, hệ thống phải hiển thị thông báo lỗi. 4. Nếu có địa chỉ email được cung cấp, hệ thống phải tự động gửi một email xác nhận đăng ký thành công và cung cấp Mã Khách hàng cho khách hàng. 5. Thông tin khách hàng đã đăng ký phải được lưu trữ trong cơ sở dữ liệu của ERP và có thể truy xuất, cập nhật từ các module Quản lý Đơn hàng, Kế toán và Chăm sóc Khách hàng. 6. Hệ thống phải hiển thị thông báo lỗi rõ ràng và gợi ý khắc phục nếu bất kỳ trường dữ liệu bắt buộc nào bị bỏ trống hoặc dữ liệu nhập vào không đáp ứng các ràng buộc về định dạng/giá trị.

---

Thuộc tính (Attribute)	Giá trị (Value)
Nghĩa vụ lịch sử thay đổi	v0.1 (2026-08-07, BA A. Nguyễn): Khởi tạo User Story. v0.2 (2026-08-10, BA A. Nguyễn): Cập nhật AC #3 theo NF-BR-LEGAL-005 (Quy định về MST), thêm AC #6.
Cổng chất lượng	1. Mỗi Acceptance Criterion rõ ràng, testable, và không mâu thuẫn. 2. Chủ sở hữu nghiệp vụ (Business SME) đã review và không có bình luận mở. 3. Có traceability đầy đủ đến các nguồn và quy tắc nghiệp vụ liên quan.
Tham chiếu nguồn	- NF-BR-LEGAL-005: Quy định về định dạng Mã số thuế (từ CANONICAL_BUSINESS_RULES). - NF-DD-CUSTOMER_CODE: Định nghĩa Mã Khách hàng (từ CANONICAL_DATA_DICTIONARY).

Ví dụ 2: Data Dictionary Entry (Mục từ điển dữ liệu)

Mô tả: Data Dictionary cung cấp định nghĩa chuẩn hóa cho các yếu tố dữ liệu, đảm bảo sự hiểu biết thống nhất giữa các bên liên quan.

Thuộc tính	Giá trị
Artifact ID	NF-DD-ERP-CUSTOMER_CODE
Tên tệp	/03-templates/nova-foods/data-dictionary-customer-v0.1.md
Tiêu đề	[DD] Mã Khách hàng (MaKhachHang)
Chủ sở hữu	Business Analyst (BA) / Data Steward
Trạng thái	DRAFT

---

Nội dung mục từ điển dữ liệu (NF-DD-ERP-CUSTOMER_CODE):

Tên trường logic: MaKhachHang Tên hiển thị: Mã Khách hàng Mô tả: Định danh duy nhất cho mỗi khách hàng trong hệ thống ERP của Nova Foods. Mã này được sử dụng để truy vết các giao dịch, đơn hàng và lịch sử tương tác. Kiểu dữ liệu: VARCHAR(20) Độ dài: Tối đa 20 ký tự. Bắt buộc: CÓ Giá trị hợp lệ: Chuỗi ký tự theo định dạng NF-CYYYYMMDDHHMMSS. Ví dụ: NF-C20260807153045. Mã này không được trùng lặp. Nguồn sinh: Hệ thống tự động sinh khi đăng ký khách hàng mới thành công. Phân loại dữ liệu: Dữ liệu nhận dạng không nhạy cảm (Non-Sensitive Identifier Data), nhưng cần được bảo vệ quyền riêng tư theo Luật Bảo vệ dữ liệu cá nhân (Luật 91/2025/QH15).

---

Thuộc tính (Attribute)	Giá trị (Value)
Nghĩa vụ lịch sử thay đổi	v0.1 (2026-08-07, BA A. Nguyễn): Khởi tạo định nghĩa.
Cổng chất lượng	1. Định nghĩa rõ ràng, không trùng lặp, không mâu thuẫn với các quy tắc nghiệp vụ. 2. Tuân thủ chuẩn đặt tên dữ liệu của Nova Foods. 3. Chủ sở hữu nghiệp vụ (Business SME) đã review và đồng ý với định nghĩa và ràng buộc.
Tham chiếu nguồn	- NF-US-SALES-001: Yêu cầu tự động sinh mã khách hàng. - Luật 91/2025/QH15: Yêu cầu bảo vệ dữ liệu cá nhân.

Ví dụ 3: Business Process Model (Mô hình quy trình nghiệp vụ)

Mô tả: Mô hình quy trình nghiệp vụ (ví dụ: sử dụng PlantUML hoặc BPMN) cung cấp cái nhìn trực quan về các bước, vai trò và luồng thông tin trong một quy trình.

Thuộc tính	Giá trị
Artifact ID	NF-BPMN-SALES-001
Tên tệp	/03-templates/nova-foods/bpmn-sales-001-customer-registration.puml
Tiêu đề	[BPMN] Quy trình Đăng ký Khách hàng mới Nova Foods
Chủ sở hữu	Business Analyst (BA)
Trạng thái	IN_REVIEW

---

Nội dung Mô hình quy trình nghiệp vụ (NF-BPMN-SALES-001):

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

@startuml
skinparam handwritten true
skinparam monochrome true
skinparam defaultFontName "Segoe UI"
skinparam defaultFontSize 14

title [Activity Diagram] Quy trình Đăng ký Khách hàng mới Nova Foods

|Nhân viên Kinh doanh|
start
:Gửi yêu cầu đăng ký khách hàng mới;

|Hệ thống ERP Nova Foods|
:Xác thực dữ liệu đầu vào\n(Tên, SĐT, MST);

if (Dữ liệu hợp lệ?) then (Có)
    :Tự động sinh Mã Khách hàng;

    |Cơ sở dữ liệu|
    :Lưu thông tin Khách hàng;

    |Hệ thống ERP Nova Foods|
    :Hiển thị thông báo\n"Đăng ký thành công"\nvà Mã Khách hàng;

    |Nhân viên Kinh doanh|
    :Nhận thông báo đăng ký thành công\nvà Mã Khách hàng;

    |Hệ thống ERP Nova Foods|
    if (Có email?) then ([có email])
        :Gửi email xác nhận đến Khách hàng;

        |Khách hàng|
        :Nhận email xác nhận;
    else ([không có email])
    endif

    stop
else (Không)
    |Hệ thống ERP Nova Foods|
    :Hiển thị thông báo lỗi\n(ví dụ: "Mã số thuế không hợp lệ");

    |Nhân viên Kinh doanh|
    :Nhận thông báo lỗi;
    stop
endif

@enduml

---

Thuộc tính (Attribute)	Giá trị (Value)
Nghĩa vụ lịch sử thay đổi	v0.1 (2026-08-07, BA A. Nguyễn): Khởi tạo sơ đồ quy trình.
Cổng chất lượng	1. Sơ đồ rõ ràng, thể hiện đúng trình tự các bước nghiệp vụ. 2. Tuân thủ cú pháp PlantUML (hoặc BPMN 2.0.2 nếu là BPMN). 3. Chủ sở hữu nghiệp vụ (Business SME) đã review và xác nhận tính đúng đắn của luồng.
Tham chiếu nguồn	- NF-US-SALES-001: Mô tả tính năng đăng ký khách hàng. - NF-BR-LEGAL-005: Quy tắc xác thực Mã số thuế.

Senior Lens

Thẩm định chặt chẽ: Mỗi đầu ra là một cam kết thông tin. Việc AI hỗ trợ tạo ra các bản nháp (draft) nhanh chóng không làm giảm nghĩa vụ thẩm định kỹ lưỡng. Hallucination (sự bịa đặt thông tin) và bias (thiên vị) từ AI là rủi ro. BA phải so sánh chéo với các nguồn canonical (CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY) và xác minh với Subject Matter Experts (SME). Mạng lưới liên kết: Không có đầu ra nào tồn tại độc lập. Chúng tạo thành một mạng lưới thông tin liên kết chặt chẽ. Thay đổi ở một đầu ra có thể ảnh hưởng đến nhiều đầu ra khác. Khả năng truy vết (traceability) từ requirement đến test case và ngược lại là nền tảng để quản lý sự phức tạp này. Cổng chất lượng không phải phê duyệt: "Cổng chất lượng" là điểm kiểm tra nội bộ của BA để đảm bảo artifact đủ tiêu chuẩn cho bước tiếp theo, không phải là "phê duyệt sản xuất" hay "sẵn sàng triển khai". Các phê duyệt chính thức (approval) phải được ghi nhận rõ ràng bởi chủ sở hữu nghiệp vụ (Business Owner), pháp lý (Legal Owner) hoặc các bên có thẩm quyền khác.

Quick Reference

Loại Đầu ra	Mục đích chính	Chủ sở hữu điển hình	Cổng chất lượng tiêu biểu
User Story	Diễn tả nhu cầu từ góc nhìn người dùng/giá trị.	BA / PO	AC rõ ràng, testable; SME review không có bình luận mở.
Data Dictionary	Chuẩn hóa định nghĩa dữ liệu.	BA / Data Steward	Định nghĩa rõ ràng, thống nhất; SME xác nhận.
Process Model	Trực quan hóa luồng nghiệp vụ.	BA	Logic chính xác, tuân thủ ký hiệu; SME xác nhận quy trình.
Tất cả	Đảm bảo truy vết, chất lượng và minh bạch thông tin.	BA và các stakeholder liên quan	Metadata đầy đủ, lịch sử thay đổi rõ ràng, tham chiếu nguồn đầy đủ.

Các Tiêu Chí Cổng Chất Lượng cho Đầu Ra BA

Core

Cổng chất lượng (Quality Gate) là tập hợp tiêu chí kiểm chứng được, sản phẩm (artifact) phải đạt trước chuyển giai đoạn tiếp theo. Ví dụ: trước xem xét (review) bởi các bên liên quan (stakeholders) hoặc bàn giao đội phát triển/kiểm thử. Mục đích: đảm bảo sản phẩm hoàn thiện, rõ ràng, nhất quán, giảm công sức sửa chữa giai đoạn sau. Cổng chất lượng không phải phê duyệt (approval) hay sẵn sàng sản xuất (production readiness). Đây là kiểm tra nội bộ BA hoặc nhóm BA trước khi đưa sản phẩm ra ngoài.

Tiêu chí chung cổng chất lượng sản phẩm BA: * Tính đầy đủ (Completeness): Các phần bắt buộc điền đủ, không chỗ trống hoặc ghi chú "cần thêm" (TBD). * Tính nhất quán (Consistency): Thông tin nội bộ không mâu thuẫn, nhất quán tài liệu nguồn (source artifacts) đã chấp thuận. * Tính rõ ràng (Clarity): Nội dung dễ hiểu đối tượng mục tiêu, không mơ hồ. Thuật ngữ kỹ thuật/nghiệp vụ phức tạp phải giải thích. * Tính truy vết được (Traceability): Sản phẩm liên kết được đến đầu vào (mục tiêu nghiệp vụ, yêu cầu gốc, quy định pháp luật). * Tuân thủ tiêu chuẩn (Adherence to Standards): Tuân thủ mẫu (templates), ký hiệu (notation) (ví dụ: BPMN, UML), quy ước đặt tên (naming conventions) định nghĩa trong dự án/tổ chức. * Kiểm tra tính khả thi sơ bộ (Preliminary Feasibility Check): Yêu cầu/giải pháp đề xuất không phi thực tế rõ ràng mà không giải thích hợp lý. * Đúng ngữ pháp và định dạng (Syntactic Correctness and Formatting): Không lỗi chính tả, ngữ pháp, định dạng chuyên nghiệp.

Applied

Áp dụng tiêu chí cổng chất lượng cho đầu ra BA điển hình bối cảnh Nova Foods.

1. Tài liệu Yêu cầu Nghiệp vụ (Business Requirements Document - BRD) * Artifact ID: NFS-BRD-ERP-001 * Tên tệp: /03-templates/NFS-BRD-ERP-001-Template.md * Tiêu chí cổng chất lượng: * Mô tả phạm vi đầy đủ: Phần Scope (NFS-BRD-001-SEC-010) trình bày rõ giới hạn, loại trừ, giả định (assumptions) dự án. * Mục tiêu nghiệp vụ rõ ràng: Mục Business Goals (NFS-BRD-001-SEC-020) định nghĩa theo định dạng SMART (Specific, Measurable, Achievable, Relevant, Time-bound). * Yêu cầu nghiệp vụ truy vết được: Mỗi yêu cầu nghiệp vụ (NFS-BRD-001-BR-XXX) liên kết ít nhất một mục tiêu nghiệp vụ và một bên liên quan (stakeholder) đã xác định. * Thuật ngữ thống nhất: Các thuật ngữ chính (NFS-BRD-001-GL-XXX) định nghĩa nhất quán với /05-glossary/, đặc biệt các thuật ngữ Nova Foods như Đơn hàng bán (Sales Order), Kho lạnh (Cold Storage). * Định dạng chuẩn: Tài liệu tuân thủ mẫu BRD của Nova Foods. * Ví dụ Nova Foods: BRD module quản lý kho lạnh sẵn sàng khi mô tả rõ phạm vi (chỉ quản lý hàng hóa đông lạnh), mục tiêu (giảm 15% sai sót tồn kho trong 6 tháng), và mỗi yêu cầu "Hệ thống phải cho phép ghi nhận nhiệt độ thực tế của từng khu vực trong kho lạnh mỗi giờ" liên kết với mục tiêu "Đảm bảo tuân thủ Luật An toàn thực phẩm" và stakeholder "Trưởng phòng QA Nova Foods".

2. Đặc tả Yêu cầu Chức năng (Functional Specification Document - FSD) * Artifact ID: NFS-FSD-ERP-002 * Tên tệp: /03-templates/NFS-FSD-ERP-002-Template.md * Tiêu chí cổng chất lượng: * Liên kết 1:1 hoặc 1:N với BRD: Mỗi yêu cầu chức năng (NFS-FSD-002-FR-XXX) truy vết được đến ít nhất một yêu cầu nghiệp vụ BRD tương ứng. * Mô tả chức năng chi tiết: Mỗi chức năng mô tả rõ: đầu vào (inputs), quá trình xử lý (processing logic), đầu ra (outputs), và các quy tắc nghiệp vụ (business rules) liên quan (ví dụ: CANONICAL_BUSINESS_RULES.md). * Tiêu chí chấp nhận (Acceptance Criteria) đầy đủ: Mỗi yêu cầu chức năng có ít nhất một tiêu chí chấp nhận định dạng GIVEN-WHEN-THEN. * Mô tả giao diện người dùng (UI) / API (nếu có): Bản nháp (wireframe), mô hình (mockup) hoặc mô tả API (dựa trên OpenAPI Specification) có sẵn và rõ ràng. * Xử lý ngoại lệ (Exception Handling): Xác định kịch bản lỗi và cách hệ thống xử lý. * Ví dụ Nova Foods: FSD chức năng "Tạo Đơn Hàng Bán" sẵn sàng khi truy vết được đến yêu cầu nghiệp vụ "Quản lý đơn hàng hiệu quả hơn", mô tả chi tiết các bước nhập thông tin khách hàng, sản phẩm, số lượng, giá (có tham chiếu quy tắc giá từ CANONICAL_BUSINESS_RULES.md), và có tiêu chí chấp nhận như "GIVEN người dùng nhập sản phẩm không tồn kho WHEN tạo đơn hàng THEN hệ thống báo lỗi 'Sản phẩm không đủ tồn kho' và không cho phép hoàn tất đơn hàng".

3. Mô hình Quy trình Nghiệp vụ (Business Process Model - BPMN Diagram) * Artifact ID: NFS-PROC-ERP-003 * Tên tệp: /03-templates/NFS-PROC-ERP-003-Template.md (chứa phần nhúng diagram) * Tiêu chí cổng chất lượng: * Tuân thủ chuẩn BPMN: Mô hình dùng đúng ký hiệu và ngữ nghĩa BPMN 2.0.2 (OMG BPMN 2.0.2) cho tác vụ (tasks), cổng (gateways), sự kiện (events), làn (swimlanes), luồng trình tự (sequence flows), luồng thông điệp (message flows). * Đại diện cho quy trình hiện tại/tương lai: Mô hình phản ánh đúng quy trình nghiệp vụ "as-is" hoặc "to-be" đã thống nhất với Business Owner. * Mỗi tác vụ có mô tả rõ ràng: Tác vụ có tên động từ + danh từ và mô tả ngắn gọn. * Ranh giới rõ ràng: Xác định rõ điểm bắt đầu (start event) và điểm kết thúc (end event) của quy trình. * Được xem xét sơ bộ nội bộ: Không lỗi logic cơ bản (ví dụ: luồng không có điểm kết thúc, cổng không cân bằng). * Ví dụ Nova Foods: Mô hình quy trình "Xử lý khiếu nại khách hàng" sẵn sàng khi vẽ bằng ký hiệu BPMN chuẩn, các làn phân định rõ trách nhiệm (ví dụ: "Bộ phận Chăm sóc khách hàng", "Bộ phận Kho"), mọi tác vụ có tên rõ ràng (ví dụ: "Tiếp nhận khiếu nại", "Kiểm tra thông tin đơn hàng"), và luồng quy trình thể hiện rõ cách khiếu nại được tiếp nhận, xử lý và đóng.

4. Kịch bản Kiểm thử Chấp nhận Người dùng (User Acceptance Test - UAT Scenarios) * Artifact ID: NFS-UAT-SCEN-004 * Tên tệp: /03-templates/NFS-UAT-SCEN-004-Template.md * Tiêu chí cổng chất lượng: * Truy vết đến yêu cầu: Mỗi kịch bản kiểm thử (test scenario) hoặc trường hợp kiểm thử (test case) truy vết được đến ít nhất một yêu cầu chức năng FSD và một yêu cầu nghiệp vụ BRD. * Định dạng GIVEN-WHEN-THEN: Các bước kiểm thử định nghĩa rõ ràng với tiền điều kiện (GIVEN), hành động (WHEN) và kết quả mong đợi (THEN). * Dữ liệu kiểm thử (Test Data) xác định: Liệt kê dữ liệu đầu vào cụ thể cần cho kịch bản (ví dụ: mã sản phẩm NF-SP-001, số lượng 100). * Không có lỗi cú pháp/ngữ pháp: Kịch bản rõ ràng, dễ đọc, không gây hiểu lầm. * Phạm vi bao phủ đầy đủ: Kịch bản bao phủ các luồng chính (happy path) và các luồng thay thế/ngoại lệ (alternate/exception paths). * Ví dụ Nova Foods: Kịch bản UAT chức năng "Xác nhận giao hàng" sẵn sàng khi truy vết được đến yêu cầu FSD "Hệ thống cho phép nhân viên kho xác nhận giao hàng", có các bước như "GIVEN đơn hàng NF-SO-20260807-001 đã sẵn sàng giao WHEN nhân viên kho nhập mã đơn hàng và bấm 'Xác nhận giao hàng' THEN trạng thái đơn hàng chuyển thành 'Đã giao' và hệ thống tạo hóa đơn điện tử".

Senior Lens

Cổng chất lượng không chỉ danh sách kiểm tra. Nó công cụ quản lý rủi ro sớm. * Giảm chi phí sửa chữa: Phát hiện lỗi sớm giảm đáng kể chi phí khắc phục so với khi lỗi tìm thấy giai đoạn phát triển hoặc sau triển khai. * Cải thiện chất lượng đầu vào cho giai đoạn sau: Đảm bảo đội Phát triển (Development), Kiểm thử (QA), Đào tạo (Training) nhận tài liệu rõ ràng, đầy đủ, nhất quán. * Tăng khả năng truy vết: Cổng chất lượng buộc BA đảm bảo liên kết giữa các artifact, giúp dễ dàng kiểm tra tính đúng đắn và thay đổi tương lai. * Thiết lập kỳ vọng rõ ràng: Tất cả bên liên quan hiểu rằng chỉ tài liệu qua cổng chất lượng mới xem xét chính thức. Tránh review tài liệu chưa hoàn thiện, lãng phí thời gian. * Nâng cao tính chuyên nghiệp: BA chịu trách nhiệm chất lượng sản phẩm của mình, phản ánh năng lực, tỉ mỉ. Bỏ qua cổng chất lượng có thể dẫn đến sản phẩm BA bị từ chối, làm chậm trễ dự án, giảm uy tín. * Bảo vệ khỏi các quyết định vội vàng: Các tiêu chí "Không khẳng định Nova Foods là doanh nghiệp có thật" hoặc "Dữ liệu mô phỏng" trong các artifact nguồn (00_SOURCE_MAP.md, 01_CURRICULUM_ARCHITECTURE.md, v.v.) là cổng chất lượng cấp độ siêu dữ liệu (metadata). Ngăn BA và các bên liên quan coi các ví dụ mô phỏng là quy tắc nghiệp vụ hoặc quyết định kiến trúc thực tế của Nova Foods.

Quick Reference

Artifact Output	Tiêu Chí Cổng Chất Lượng Tối Thiểu
BRD (NFS-BRD-ERP-001)	Scope, Business Goals định dạng SMART, Yêu cầu nghiệp vụ truy vết được (đến mục tiêu, stakeholder), Thuật ngữ nhất quán (/05-glossary/), Tuân thủ mẫu.
FSD (NFS-FSD-ERP-002)	Yêu cầu chức năng truy vết được (đến BRD), Mô tả chức năng chi tiết (inputs, logic, outputs, rules), Tiêu chí chấp nhận GIVEN-WHEN-THEN, Mô tả UI/API, Xử lý ngoại lệ.
BPMN Diagram (NFS-PROC-ERP-003)	Tuân thủ chuẩn BPMN 2.0.2, Đại diện đúng quy trình (as-is/to-be), Tên tác vụ rõ ràng, Ranh giới quy trình xác định, Không lỗi logic cơ bản.
UAT Scenarios (NFS-UAT-SCEN-004)	Kịch bản/test case truy vết được (đến FSD/BRD), Định dạng GIVEN-WHEN-THEN, Dữ liệu kiểm thử xác định, Không lỗi cú pháp, Bao phủ luồng chính và thay thế.

7. Who consumes those outputs?

Đầu ra BA, nhiều vai trò sử dụng. Vai trò khác, cách dùng khác. Hiểu để giao tiếp tốt.

Core

BA tạo ra nhiều đầu ra. Mỗi đầu ra, một nhóm đối tượng chính sử dụng. Cách sử dụng khác nhau. Mục đích khác nhau.

Vai trò	Đầu ra BA tiêu thụ chính	Cách tiêu thụ (What they do)
Lập trình viên (Developer)	Đặc tả Chức năng Hệ thống (FSD), Sơ đồ Quy trình Nghiệp vụ (BPMN Diagram)	Đọc FSD hiểu yêu cầu chi tiết. Thiết kế kỹ thuật module, API. Căn cứ BPMN hiểu luồng nghiệp vụ. Viết code, thực hiện unit test.
Kiểm thử viên (QA Specialist)	Yêu cầu Nghiệp vụ (BRD), FSD, Kịch bản UAT, BPMN Diagram	Dùng BRD, FSD xây dựng test plan, test case. Dùng Kịch bản UAT (User Acceptance Test) làm cơ sở thực hiện kiểm thử chấp nhận. Xác minh tính đúng đắn, đầy đủ của hệ thống so với yêu cầu.
Kiến trúc sư (Architect)	BRD, FSD, BPMN Diagram	Đánh giá yêu cầu từ BRD. Phân tích FSD để thiết kế kiến trúc hệ thống, lựa chọn công nghệ. Đảm bảo hệ thống có thể mở rộng, bảo mật.
Quản lý dự án / Chủ sản phẩm (PM / Product Owner)	BRD, FSD, BPMN Diagram	Dùng BRD, FSD để xác định phạm vi dự án, ưu tiên tính năng. Quản lý backlog, lập kế hoạch release. Giao tiếp với stakeholder.
Chủ nghiệp vụ (Business Owner)	BRD, BPMN Diagram	Review, phê duyệt BRD đảm bảo đúng nhu cầu nghiệp vụ. Xem BPMN Diagram để xác nhận quy trình tương lai. Đánh giá giá trị kinh doanh.
Vận hành (Operations)	FSD (phần yêu cầu phi chức năng), BPMN Diagram (quy trình vận hành mới)	Đọc FSD hiểu yêu cầu về hiệu năng, bảo mật, khả năng phục hồi. Dùng BPMN Diagram chuẩn bị quy trình triển khai, hỗ trợ hệ thống.
Chủ sở hữu chuyên môn (Specialist Owner - VD: Pháp lý, Kế toán, Bảo mật)	BRD, FSD, BPMN Diagram (phần liên quan)	Kiểm tra BRD, FSD, BPMN Diagram đảm bảo tuân thủ luật pháp (như Luật Bảo vệ dữ liệu cá nhân Luật 91/2025/QH15, Luật Kế toán Luật 88/2015/QH13), quy định nội bộ Nova Foods, tiêu chuẩn bảo mật (OWASP ASVS).

Applied

Nova Foods triển khai module quản lý kho lạnh mới. BA cần rõ ràng đầu ra cho ai.

• Facts: BRD NFS-BRD-ERP-001 yêu cầu: "Hệ thống phải theo dõi nhiệt độ kho lạnh liên tục, cảnh báo khi vượt ngưỡng". FSD NFS-FSD-ERP-002 chi tiết: "API /warehouse/coldchain/{sensor_id} gửi dữ liệu mỗi 5 phút, ngưỡng cảnh báo cấu hình được." BPMN Diagram NFS-PROC-ERP-003 mô tả luồng kiểm tra nhiệt độ tự động, gửi cảnh báo đến bộ phận Kho vận.
• Current Behavior: Kiểm tra nhiệt độ thủ công, ghi sổ. Rủi ro hỏng hàng.
• Underlying Need: Tuân thủ quy định An toàn thực phẩm Luật 55/2010/QH12, giảm thất thoát hàng hóa, tự động hóa quy trình.
• Options: 1) Hệ thống IoT tự động. 2) Nâng cấp hệ thống ghi chép thủ công. 3) Mua phần mềm quản lý kho lạnh sẵn.
• Decision Criteria: Chi phí, thời gian triển khai, mức độ tuân thủ, độ tin cậy.
• Decision: Triển khai hệ thống IoT tích hợp ERP Nova Foods (lựa chọn 1).
• Authority: Business Owner (Warehouse Manager), Architect (chọn IoT platform), PM (quản lý thời gian, ngân sách), Legal Owner (xác nhận tuân thủ).
• Artifact: FSD NFS-FSD-ERP-002 mô tả chi tiết API tích hợp, giao diện cảnh báo. BPMN Diagram NFS-PROC-ERP-003 thể hiện luồng xử lý cảnh báo.
• Consequence if Wrong: Sản phẩm Nova Foods hỏng, bị phạt hành chính, thu hồi sản phẩm, mất uy tín.

Senior Lens

BA phải chủ động dẫn dắt, không chỉ giao tài liệu. Hiểu ai dùng gì, dùng làm gì. BA cần đảm bảo mỗi vai trò nhận đủ, đúng thông tin. Không cung cấp thừa, không cung cấp thiếu. Tránh lãng phí thời gian review. Xác minh rằng mỗi đầu ra giúp vai trò tiếp theo tiến hành công việc.

Quick Reference

Vai trò	Đầu ra BA quan trọng
Lập trình viên	FSD, BPMN Diagram
Kiểm thử viên	BRD, FSD, Kịch bản UAT, BPMN Diagram
Kiến trúc sư	BRD, FSD, BPMN Diagram
Quản lý dự án / Chủ sản phẩm	BRD, FSD, BPMN Diagram
Chủ nghiệp vụ	BRD, BPMN Diagram
Vận hành	FSD (yêu cầu phi chức năng), BPMN Diagram
Chủ sở hữu chuyên môn	BRD, FSD, BPMN Diagram (phần liên quan)

Vai trò người tiêu thụ, thẩm quyền quyết định và tiêu chí leo thang

Core

Sau khi phân tích và thu thập yêu cầu, Business Analyst (BA) tạo ra nhiều sản phẩm đầu ra (outputs). Các sản phẩm này không chỉ là tài liệu tĩnh; chúng là căn cứ để nhiều vai trò khác nhau trong dự án đưa ra các quyết định quan trọng. "Người tiêu thụ" (consumer) ở đây là bất kỳ cá nhân hay nhóm nào sử dụng các outputs của BA để thực hiện công việc của họ. Mỗi vai trò có thẩm quyền quyết định riêng, cần những "bằng chứng" (evidence) cụ thể để ra quyết định, và phải biết khi nào cần "leo thang" (escalation) một vấn đề lên cấp quản lý hoặc vai trò có thẩm quyền cao hơn.

Applied

Tình huống mô phỏng Nova Foods: Nova Foods (mô phỏng giáo dục) đang phát triển tính năng "Xác minh đơn hàng nhập khẩu tự động" để cải thiện quy trình nhập nguyên liệu từ nước ngoài. BA đã hoàn thành "Tài liệu Đặc tả Yêu cầu Chức năng (FSD) cho Xác minh Đơn hàng Nhập khẩu Tự động" (ID: NF-FSD-001, Version v1.0.0).

• Sự kiện: FSD NF-FSD-001 được trình bày cho các bên liên quan để phê duyệt.
• Hành vi hiện tại (Current Behavior): Xác minh đơn hàng nhập khẩu nguyên liệu thực phẩm được thực hiện thủ công, chậm trễ, dễ sai sót, dẫn đến chi phí phát sinh và rủi ro không tuân thủ các quy định về An toàn thực phẩm (Luật An toàn thực phẩm 55/2010/QH12).
• Nhu cầu cốt lõi (Underlying Need): Giảm thiểu sai sót, tăng tốc độ xử lý đơn hàng, đảm bảo tuân thủ các quy định pháp luật và tối ưu hóa chi phí vận hành cho Nova Foods.
• Các lựa chọn (Options):
  1. Tự động hóa hoàn toàn: Sử dụng công nghệ OCR và AI để đọc và xác minh tài liệu tự động.
  2. Tự động hóa bán phần: Hệ thống tự động trích xuất dữ liệu, nhưng yêu cầu con người xác minh cuối cùng.
  3. Cải thiện quy trình thủ công: Đào tạo nhân viên và chuẩn hóa biểu mẫu mà không phát triển phần mềm mới.
• Tiêu chí quyết định (Decision Criteria):
  • Hiệu quả: Giảm sai sót (số lỗi/đơn hàng).
  • Tốc độ: Thời gian xử lý trung bình/đơn hàng.
  • Chi phí: Chi phí phát triển và vận hành (Capex/Opex).
  • Tuân thủ: Khả năng đáp ứng Luật An toàn thực phẩm 55/2010/QH12 và các quy định hải quan.
  • Rủi ro: Rủi ro công nghệ và rủi ro thay đổi quy trình.
• Quyết định (Decision): Trưởng phòng Thu mua và Trưởng phòng IT của Nova Foods cùng quyết định chọn "Tự động hóa bán phần" (lựa chọn 2) vì cân bằng giữa hiệu quả, chi phí và rủi ro.
• Thẩm quyền (Authority): Trưởng phòng Thu mua (Business Owner) phê duyệt yêu cầu nghiệp vụ và quy trình mới. Trưởng phòng IT (Kiến trúc sư/PM) phê duyệt phương án kỹ thuật và phạm vi triển khai.
• Sản phẩm đầu ra (Artifact): FSD NF-FSD-001 được cập nhật trạng thái APPROVED với version v1.1.0, có chữ ký phê duyệt của cả Trưởng phòng Thu mua và Trưởng phòng IT, và được lưu trữ tại /nova-foods-erp/docs/requirements/NF-FSD-001-v1.1.0.md.
• Hậu quả nếu sai (Consequence if Wrong): Nếu quyết định sai, ví dụ chọn tự động hóa hoàn toàn mà không đánh giá đủ chi phí, có thể dẫn đến lãng phí ngân sách và dự án không hoàn thành. Ngược lại, nếu chỉ cải thiện thủ công, rủi ro sai sót và không tuân thủ pháp luật vẫn cao, gây phạt hành chính hoặc thu hồi sản phẩm.

Senior Lens

Với góc nhìn của một Senior BA, việc xác định rõ người tiêu thụ, thẩm quyền quyết định của họ và các tiêu chí leo thang là tối quan trọng để đảm bảo dự án tiến triển hiệu quả. BA phải chủ động định hình các cuộc họp phê duyệt thành các buổi ra quyết định có cấu trúc, nơi mọi bằng chứng được trình bày rõ ràng và các bên liên quan hiểu rõ hậu quả của từng lựa chọn. Tránh "phát triển theo ủy ban" (development by committee) nơi không ai thực sự chịu trách nhiệm cuối cùng. Một Senior BA luôn đảm bảo có một "Accountable" (người chịu trách nhiệm) rõ ràng cho mỗi quyết định quan trọng, không phải chỉ "Responsible" (người thực hiện). Điều này giúp tránh tình trạng xung đột lợi ích giữa các phòng ban làm trì trệ dự án hoặc đưa ra các quyết định không tối ưu. Khi có bất đồng không thể tự giải quyết, việc leo thang phải được thực hiện theo quy trình rõ ràng, minh bạch, có ghi nhận bằng chứng và các phương án đã xem xét.

Quick Reference

Bảng dưới đây tóm tắt các vai trò tiêu biểu, thẩm quyền quyết định, bằng chứng cần thiết và tiêu chí leo thang:

Vai trò (Consumer)	Quyết định tiêu biểu	Bằng chứng cần (Evidence)	Tiêu chí Leo thang (Escalation Criteria)
Business Owner (Chủ nghiệp vụ)	Phê duyệt yêu cầu nghiệp vụ, thay đổi quy trình kinh doanh, xác nhận giá trị lợi ích.	Báo cáo phân tích nghiệp vụ, mô hình quy trình (BPMN 2.0.2), tài liệu đặc tả yêu cầu, phân tích lợi ích/chi phí, ma trận tuân thủ (ví dụ: Luật Kế toán 88/2015/QH13, Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15).	Mâu thuẫn với mục tiêu chiến lược của Nova Foods, vượt ngân sách/thời gian phê duyệt, xung đột với quy định pháp luật chưa có hướng giải quyết, không đạt được sự đồng thuận giữa các phòng ban.
Product Owner / Project Manager (PM) (Chủ sản phẩm / Quản lý dự án)	Ưu tiên tính năng, chấp thuận phạm vi dự án, phê duyệt bản nháp (mockup/prototype), ra quyết định liên quan đến tiến độ, tài nguyên.	Product backlog, User Story, tài liệu đặc tả yêu cầu (FSD), Acceptance Criteria, báo cáo tiến độ, kế hoạch tài nguyên, ma trận rủi ro.	Thay đổi lớn về phạm vi (scope creep) ảnh hưởng đến mục tiêu dự án, rủi ro dự án cao không thể tự quản lý, mâu thuẫn về ưu tiên không tự giải quyết được giữa các bên liên quan.
Developer (Lập trình viên)	Quyết định chi tiết kỹ thuật triển khai, cấu trúc dữ liệu, lựa chọn thư viện/framework (nếu không được chỉ định bởi Architect).	Tài liệu thiết kế kỹ thuật, đặc tả API (OpenAPI Specification 3.1.1), mô hình dữ liệu (UML 2.5.1 class diagram), đặc tả yêu cầu chức năng.	Không thể triển khai kỹ thuật theo yêu cầu trong phạm vi thời gian/ngân sách, ảnh hưởng hiệu năng/bảo mật nghiêm trọng (OWASP ASVS 5.0.0), cần thay đổi kiến trúc hệ thống, phát hiện vấn đề bảo mật API (OWASP API Security Top 10).
Architect (Kiến trúc sư)	Phê duyệt thiết kế kiến trúc tổng thể và chi tiết, lựa chọn công nghệ lõi, định hướng kỹ thuật.	Sơ đồ kiến trúc (UML 2.5.1 component/deployment diagram), tài liệu thiết kế kỹ thuật, phân tích tác động, tài liệu tiêu chuẩn công nghệ, đánh giá rủi ro bảo mật.	Quyết định thiết kế ảnh hưởng đến toàn bộ hệ sinh thái Nova Foods, rủi ro bảo mật cao, không khả năng mở rộng/bảo trì, xung đột với các tiêu chuẩn công nghệ đã thiết lập.
QA (Kiểm thử - Quality Assurance)	Phê duyệt kế hoạch kiểm thử, chấp thuận chất lượng phần mềm, phê duyệt kết quả kiểm thử, xác nhận độ bao phủ kiểm thử.	Kế hoạch kiểm thử (ISTQB CTFL v4.0.1 syllabus), Test cases, Test reports, báo cáo lỗi, đặc tả yêu cầu, Acceptance Criteria, nhật ký kiểm thử.	Lỗi nghiêm trọng (blocker, critical) không thể khắc phục, không đạt tiêu chí chấp nhận chất lượng (Quality Gates), rủi ro ảnh hưởng đến an toàn dữ liệu cá nhân (Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15), tính năng không hoạt động theo yêu cầu.
Operations (Vận hành)	Chấp thuận yêu cầu vận hành, phê duyệt quy trình triển khai (deployment) và quy trình quản lý sự cố, xác nhận khả năng vận hành hệ thống.	Tài liệu đặc tả vận hành (Operation Manual), yêu cầu hạ tầng, quy trình giám sát, kế hoạch sao lưu/phục hồi, phân tích SLA (Service Level Agreement).	Yêu cầu không khả thi về mặt vận hành, ảnh hưởng đến độ ổn định/sẵn sàng hệ thống (downtime), chi phí vận hành vượt quá ngân sách, rủi ro về an ninh mạng không thể chấp nhận.

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

### Core

Hiểu lầm khi chuyển giao (handoff misunderstanding) xảy ra khi thông tin được truyền từ một bên (ví dụ: BA) sang bên khác (ví dụ: Developer, QA) nhưng bên nhận hiểu sai hoặc thiếu ngữ cảnh so với ý định ban đầu. Điều này thường do yêu cầu không rõ ràng, giả định ngầm định (implicit assumptions), hoặc thiếu thông tin cần thiết về mục tiêu nghiệp vụ. Câu hỏi làm rõ (clarification question) là công cụ BA dùng để xác định và khắc phục những hiểu lầm này, đảm bảo mọi bên có cùng sự hiểu biết về yêu cầu. BA cần chủ động đặt câu hỏi xuyên suốt vòng đời dự án, không chỉ ở giai đoạn đầu, để tránh lãng phí thời gian và nguồn lực do làm lại (rework).

### Applied

Tình huống Nova Foods: Cập nhật trạng thái đơn hàng

• Facts (Sự thật): Nova Foods cần khách hàng thấy trạng thái đơn hàng (Order Status) được cập nhật trên cổng thông tin khách hàng. BA đã ghi nhận Người dùng có thể xem trạng thái đơn hàng mới nhất trên cổng thông tin.
• Current Behavior (Hành vi hiện tại):
  • Developer A triển khai tính năng dựa trên giả định trạng thái mới nhất nghĩa là cập nhật ngay lập tức (real-time) sau mỗi bước xử lý đơn hàng trong hệ thống ERP.
  • QA B lên kế hoạch kiểm thử dựa trên giả định trạng thái mới nhất nghĩa là cập nhật một lần mỗi ngày thông qua một tác vụ xử lý hàng loạt (daily batch job).
  • Sự không nhất quán này dẫn đến sai lệch kết quả kiểm thử và xung đột về kỳ vọng.
• Underlying Need (Nhu cầu cốt lõi): Nova Foods muốn tăng sự hài lòng của khách hàng (customer satisfaction) bằng cách cung cấp thông tin kịp thời về đơn hàng, nhưng cũng cần duy trì hiệu suất hệ thống (system performance) ổn định khi có hàng ngàn đơn hàng mỗi giờ. Nhu cầu thực sự là gần như tức thời (near real-time) cho các trạng thái quan trọng và cập nhật định kỳ cho các trạng thái ít quan trọng hơn, không phải ngay lập tức cho mọi thứ.
• Options (Các lựa chọn):
  1. Cập nhật trạng thái ngay lập tức (true real-time): Mỗi sự kiện thay đổi trạng thái kích hoạt cập nhật ngay lập tức lên cổng thông tin. (Chi phí cao, độ phức tạp cao, tốn tài nguyên).
  2. Cập nhật theo sự kiện (event-driven updates): Các sự kiện quan trọng (ví dụ: Đã đóng gói, Đã gửi đi) kích hoạt thông báo và cập nhật. Các sự kiện ít quan trọng hơn (ví dụ: Đã xác nhận thanh toán) được tổng hợp và cập nhật định kỳ. (Cân bằng chi phí, độ phức tạp trung bình, hiệu quả).
  3. Cập nhật theo lô (scheduled batch updates): Chỉ một lần cập nhật mỗi ngày. (Chi phí thấp, độ phức tạp thấp, nhưng rủi ro hài lòng khách hàng thấp).
• Decision Criteria (Tiêu chí quyết định): Mức độ ảnh hưởng đến khách hàng, hiệu suất hệ thống, công sức phát triển, mức độ phù hợp với quy trình nghiệp vụ hiện tại của Nova Foods.
• Decision (Quyết định): Áp dụng cập nhật theo sự kiện cho các trạng thái quan trọng ảnh hưởng trực tiếp đến kỳ vọng của khách hàng (ví dụ: Đang giao hàng, Đã giao). Các trạng thái nội bộ ít quan trọng hơn sẽ được cập nhật định kỳ 4 tiếng một lần.
• Authority (Thẩm quyền): Product Owner (chủ sản phẩm) xác nhận nhu cầu kinh doanh, Architect (kiến trúc sư) xác nhận khả năng kỹ thuật và hiệu suất.
• Artifact (Tạo phẩm): US-NF-ORD-003: Cập nhật trạng thái đơn hàng cho khách hàng (User Story).
• Consequence if Wrong (Hậu quả nếu sai):
  • Nếu chọn ngay lập tức: Tốn kém chi phí phát triển và vận hành hệ thống, nguy cơ quá tải hệ thống khi có lượng đơn hàng lớn.
  • Nếu chọn theo lô: Khách hàng không hài lòng, khiếu nại nhiều, làm giảm uy tín Nova Foods.
  • Nếu Developer và QA mỗi người hiểu một kiểu: Rework lớn, chậm trễ dự án.

### Senior Lens

Phòng ngừa hiểu lầm bắt đầu từ việc làm rõ các Yêu cầu phi chức năng (Non-Functional Requirements - NFRs) ngay từ đầu, đặc biệt là các khía cạnh về hiệu suất (performance), khả năng mở rộng (scalability), tính kịp thời (timeliness) và độ chính xác (accuracy). Các Tiêu chí chấp nhận (Acceptance Criteria) phải được viết tường minh, định lượng và có thể kiểm chứng được. BA có kinh nghiệm luôn tập trung vào việc đặt câu hỏi "Tại sao?" (Why?) để khám phá các giả định ngầm định hoặc nhu cầu kinh doanh chưa được phát biểu rõ ràng. Mọi hiểu lầm không được giải quyết sẽ phá vỡ tính truy vết (traceability) của yêu cầu, khiến việc kiểm thử không hiệu quả và hệ thống không đáp ứng được mục tiêu kinh doanh.

### Quick Reference

Bảng dưới đây liệt kê các hiểu lầm phổ biến và các câu hỏi làm rõ cụ thể mà BA nên sử dụng để khắc phục chúng trong bối cảnh Nova Foods.

Hiểu lầm phổ biến (Common Misunderstanding)	Câu hỏi làm rõ chính xác (Exact Clarification Questions)
Dữ liệu sẽ được hiển thị cho người dùng.	1. Dữ liệu này được hiển thị khi nào? Ngay lập tức, theo lịch, hay khi có sự kiện? 2. Ai là người dùng có thể xem? Vai trò, nhóm nào? 3. Chính xác hiển thị thông tin gì? (Tên trường dữ liệu, định dạng hiển thị) 4. Dữ liệu này cần mới nhất đến mức nào? (Độ trễ tối đa cho phép) 5. Nguồn dữ liệu từ đâu? (Hệ thống nào, API nào)
Hệ thống phải nhanh.	1. Nhanh có nghĩa là thời gian phản hồi (response time) tối đa là bao nhiêu cho thao tác nào? (Ví dụ: Dưới 2 giây cho tìm kiếm đơn hàng) 2. Hệ thống phải phục vụ được bao nhiêu người dùng đồng thời? 3. Tải (load) hệ thống trung bình/cao nhất là bao nhiêu (số giao dịch/giây, số đơn hàng/ngày)? 4. Độ trễ mạng (network latency) có được tính đến không?
Dữ liệu sẽ được xác thực.	1. Dữ liệu này được xác thực theo quy tắc nào? (Ví dụ: Không được để trống, Phải là số nguyên dương, Phải nằm trong danh mục sản phẩm của Nova Foods) 2. Ai định nghĩa các quy tắc xác thực này? (Chủ nghiệp vụ, phòng ban nào) 3. Khi dữ liệu không hợp lệ thì xử lý thế nào? (Báo lỗi, từ chối, ghi log, bỏ qua) 4. Xác thực này được thực hiện ở đâu? (Frontend, Backend, Database)
Chức năng này cần bảo mật.	1. Mức độ bảo mật cần thiết là gì? (Ví dụ: Chỉ cho phép vai trò quản lý, Mã hóa dữ liệu nhạy cảm) 2. Loại dữ liệu nào cần được bảo vệ? (Dữ liệu khách hàng, tài chính, đơn hàng) 3. Hệ thống có cần tuân thủ tiêu chuẩn bảo mật nào không? (Ví dụ: OWASP ASVS cấp độ 2 cho các API công khai của Nova Foods) 4. Kịch bản tấn công nào cần được ngăn chặn? (SQL Injection, XSS, truy cập trái phép)

8. Detailed Worked Example

Applied

Nova Foods: Thực tế (Facts)

• Nova Foods công ty mô phỏng. Sản xuất, phân phối thực phẩm. Dữ liệu tổng hợp.
• Hai cơ sở chính: NF_HQ (trụ sở chính TP.HCM), NF_Factory_DN (nhà máy Đà Nẵng).
• Múi giờ vận hành: Asia/Ho_Chi_Minh. Tiền tệ: VND.
• Vấn đề: Quản lý Đơn đặt hàng (Purchase Order - PO) hiện tại chậm, sai.
• Hệ thống hiện có: NF_LegacyPO (tự xây dựng nội bộ). Tạo PO, in tệp PDF.
• Quy tắc nghiệp vụ PO (Simulated BR_NF_PO_001):
  • PO dưới 50.000.000 VND: Trưởng phòng tạo PO phê duyệt.
  • PO từ 50.000.000 VND đến 200.000.000 VND: Trưởng phòng và Giám đốc bộ phận phê duyệt.
  • PO trên 200.000.000 VND: Trưởng phòng, Giám đốc bộ phận và Giám đốc tài chính (CFO) phê duyệt.
  • Mỗi PO có định danh duy nhất: PO-NF-YYYYMMDD-XXXX.

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

• Bước 1: Khởi tạo PO. Người dùng tạo PO trong NF_LegacyPO. Nhập thông tin thủ công. Hệ thống sinh tệp PDF.

• Bước 2: Gửi phê duyệt. NF_LegacyPO gửi email kèm PDF tới người phê duyệt theo quy tắc BR_NF_PO_001.

  Chủ đề: Yêu cầu phê duyệt Đơn đặt hàng PO-NF-20260807-001
  Kính gửi [Tên người phê duyệt],
  Vui lòng phê duyệt Đơn đặt hàng đính kèm PO-NF-20260807-001, tổng 150.000.000 VND.
  Trả lời email này "Approved" hoặc "Rejected".
  Trân trọng,
  [Tên người tạo PO]
  

• Bước 3: Phê duyệt. Người phê duyệt xem PDF, trả lời email "Approved" hoặc "Rejected".

• Bước 4: Cập nhật trạng thái. Người tạo PO nhận email trả lời. Thủ công cập nhật trạng thái PO trong NF_LegacyPO.
• Hậu quả:
  • Delay: Phê duyệt chậm 1-3 ngày làm việc.
  • Error: Nhập sai trạng thái PO.
  • Audit Trail: Không lịch sử rõ ràng, khó truy vết. Email bằng chứng duy nhất, dễ mất.
  • Lack of Control: Không đảm bảo quy tắc phê duyệt tuân thủ nghiêm ngặt.

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

flowchart TB
    A[Người tạo PO] --> B[Tạo PO trong NF_LegacyPO]
    B --> C[Nhập thông tin PO thủ công]
    C --> D[NF_LegacyPO sinh PDF PO]
    D --> E[NF_LegacyPO gửi email kèm PDF theo BR_NF_PO_001]
    E --> F[Người phê duyệt xem PDF]
    F --> G{Trả lời email}
    G -- Approved --> H[Người tạo PO nhận email Approved]
    G -- Rejected --> I[Người tạo PO nhận email Rejected]
    H --> J[Thủ công cập nhật trạng thái Approved trong NF_LegacyPO]
    I --> K[Thủ công cập nhật trạng thái Rejected trong NF_LegacyPO]
    J --> L(PO trạng thái Approved)
    K --> M(PO trạng thái Rejected)

    E -. Email là bằng chứng duy nhất,<br/>dễ mất và khó truy vết .-> R1[Thiếu Audit Trail]
    J -. Cập nhật thủ công .-> R2[Sai trạng thái PO]
    K -. Cập nhật thủ công .-> R2
    F -. Phê duyệt qua email<br/>chậm 1-3 ngày làm việc .-> R3[Delay]
    E -. Không đảm bảo tuân thủ<br/>quy tắc phê duyệt .-> R4[Lack of Control]

Ví dụ Chi Tiết: Quản lý Số Lô Nguyên Liệu Dễ Hỏng

### Applied

Facts (Sự kiện)

Nova Foods sản xuất thực phẩm đông lạnh. Nguyên liệu Thịt bò tươi: SKU (Stock Keeping Unit - mã hàng tồn kho) NF-ING-BEEF-001. Thịt bò tươi: Thực phẩm dễ hỏng (perishable food). Cần truy vết số lô (lot number) Thịt bò tươi từ nhập kho đến thành phẩm. ERP hiện tại: NovaFoods_ERP (v3.2). Module kho: NovaFoods_INV_001.

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

ERP ghi nhập kho Thịt bò tươi theo SKU, số lượng. Số lô chỉ ghi phiếu nhập giấy. Không nhập hệ thống. Liên kết số lô nguyên liệu, lô sản xuất thành phẩm làm thủ công.

Underlying Need (Nhu cầu Cơ bản)

Nhu cầu: Tuân thủ Luật An toàn thực phẩm (Luật 55/2010/QH12), Điều 24. Truy xuất nguồn gốc thực phẩm.
Lý do: Giảm phạm vi thu hồi sản phẩm.
Rủi ro: Thu hồi diện rộng nếu số lô lỗi. Gây thiệt hại tài chính, ảnh hưởng uy tín Nova Foods.

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

1. Ghi nhận Thủ công:
2. Mô tả: Tiếp tục ghi số lô giấy. Đối chiếu thủ công.
3. Ưu điểm: Không tốn chi phí hệ thống ban đầu.

4. Nhược điểm: Độ chính xác thấp, tốn thời gian, khó mở rộng, rủi ro sai sót cao.

5. Mở rộng Module ERP Kho Hiện có:

6. Mô tả: Thêm trường Số Lô vào giao diện nhập kho NovaFoods_INV_001. Liên kết số lô với lô sản xuất thành phẩm trong module sản xuất (NovaFoods_PROD_001).
7. Ưu điểm: Tận dụng hệ thống hiện có, chi phí thấp, thời gian triển khai nhanh.

8. Nhược điểm: Tính năng hạn chế so với WMS (Warehouse Management System - hệ thống quản lý kho) chuyên dụng.

9. Tích hợp Hệ thống WMS bên thứ ba:

10. Mô tả: Triển khai WMS độc lập. Quản lý lô, vị trí kho, chiến lược xuất kho. Tích hợp WMS với ERP NovaFoods_ERP qua API (Application Programming Interface - giao diện lập trình ứng dụng).
11. Ưu điểm: Quản lý kho tối ưu, độ chính xác cao, tính năng nâng cao.
12. Nhược điểm: Chi phí cao, thời gian triển khai dài, phức tạp tích hợp.

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

Tiêu chí	Mô tả
Chi phí	Tổng chi phí sở hữu (TCO: Total Cost of Ownership) ban đầu, vận hành.
Thời gian Triển khai	Thời gian đưa vào sử dụng hệ thống.
Độ chính xác Dữ liệu	Tỷ lệ lỗi ghi nhận, truy vết số lô.
Tuân thủ	Mức độ đáp ứng Luật An toàn thực phẩm.
Phức tạp Tích hợp	Độ khó, rủi ro khi kết nối hệ thống.

Decision (Quyết định)

Lựa chọn: Mở rộng Module ERP Kho Hiện có.
Lý do: Đạt tuân thủ luật nhanh nhất. Chi phí thấp, rủi ro tích hợp thấp. Đủ chức năng nhu cầu hiện tại.
Không chọn Thủ công: Rủi ro cao, không tuân thủ.
Không chọn WMS: Quá mức cần thiết, chi phí lớn, thời gian dài.

Authority (Thẩm quyền)

Người ra quyết định: Giám đốc Vận hành (COO: Chief Operating Officer), Giám đốc Sản xuất Nova Foods.
Ngày: 2026-08-01.
Mã định danh Quyết định: NF-DEC-INV-LOT-001.
Trạng thái: IN_REVIEW. Quyết định chưa được phê duyệt hoặc baselined.

Artifact (Tạo tác)

Tạo tác chính: Tài liệu Đặc tả Chức năng (FSD: Functional Specification Document).
Định danh: /03-templates/NF-FSD-INV-LOT-003.md.
Mô tả: Chi tiết cách số lô nhập, lưu trữ, liên kết trong module kho, module sản xuất.
Quy tắc nghiệp vụ mới: BR_INV_005: Mọi nguyên liệu thuộc nhóm Thực phẩm dễ hỏng phải có số lô hợp lệ tại thời điểm nhập kho. (Tham chiếu: /01-curriculum/CANONICAL_BUSINESS_RULES.md)

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

flowchart TB
    A["Nhập kho"] --> B{"Nguyên liệu thuộc<br/>item_category = 'Thực phẩm dễ hỏng'?"}

    B -- "Có" --> C{"Có lot_id?"}
    C -- "Không" --> D["Từ chối ghi nhận nhập kho<br/>Thiếu số lô"]
    C -- "Có" --> E{"lot_id hợp lệ<br/>theo FSD?"}
    E -- "Không" --> F["Từ chối ghi nhận nhập kho<br/>Số lô không hợp lệ"]
    E -- "Có" --> G["Ghi INV_LOT<br/>lot_id PK<br/>item_id FK"]

    B -- "Không" --> H["BR_INV_005 không áp dụng"]

    subgraph MAP["Ánh xạ lưu trữ và truy xuất số lô"]
        direction TB
        I["INV_ITEM<br/>item_id PK<br/>item_category<br/>is_perishable"]
        L["INV_LOT<br/>lot_id PK<br/>item_id FK"]
        O["PROD_ORDER<br/>prod_order_id PK<br/>finished_good_sku FK"]
        P["PROD_ORDER_MATERIAL<br/>prod_order_id FK<br/>item_id FK<br/>lot_id FK"]

        I -->|"item_id"| L
        I -->|"item_id = finished_good_sku"| O
        I -->|"item_id"| P
        L -->|"lot_id"| P
        O -->|"prod_order_id"| P
    end

    G -.->|"lưu vào"| L
    N["Giới hạn ERD: không có thực thể giao dịch nhập kho.<br/>FSD quy định kiểm tra tại thời điểm nhập kho."] -.- A

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

Nếu quyết định sai (chọn thủ công):
Rủi ro: Nova Foods không thể truy vết hiệu quả lô nguyên liệu lỗi.
Hậu quả trực tiếp: Thu hồi sản phẩm rộng khắp, lãng phí hàng hóa, tổn thất doanh thu lớn.
Hậu quả pháp lý: Vi phạm Luật An toàn thực phẩm. Phạt tiền, đình chỉ hoạt động.
Hậu quả thương hiệu: Mất lòng tin khách hàng, ảnh hưởng dài hạn uy tín, thị phần.

Applied

Quy tắc Nghiệp vụ Chuẩn tắc (Canonical Business Rule)

ID Quy tắc: NF-BR-MM-001
Tên Quy tắc: Chọn Lô Nguyên liệu Tự động theo FEFO
Mô tả: Hệ thống Nova Foods ERP tự động chọn lô nguyên liệu xuất kho cho lệnh sản xuất. Cơ chế dùng nguyên tắc FEFO (First-Expired, First-Out - Lô hạn sử dụng sớm nhất xuất trước). Lô có hạn sử dụng gần nhất được ưu tiên xuất. Kết quả giảm lãng phí, giảm rủi ro chất lượng sản phẩm.
Trigger: Lệnh sản xuất được duyệt, yêu cầu xuất kho nguyên liệu.
Output: Danh sách lô nguyên liệu, số lượng được phân bổ.
Thẩm quyền dự kiến: Phó Tổng Giám đốc Vận hành là người có thẩm quyền xem xét quy tắc.
Trạng thái: IN_REVIEW. Quy tắc thuộc phạm vi quyết định tự động hóa truy vết lô, chưa được phê duyệt.

Kịch bản Chi tiết (Detailed Scenario)

ID Kịch bản: NF-SC-MM-001a
Tên Kịch bản: Phân bổ Nguyên liệu cho Lệnh Sản xuất (FEFO)
Tác nhân (Actor): Hệ thống Nova Foods ERP (tự động).
Mục tiêu (Goal): Phân bổ nguyên liệu theo lô cho Lệnh Sản xuất NF-PO-20260807-001.

Điều kiện tiên quyết (Pre-conditions):

• Lệnh Sản xuất NF-PO-20260807-001 trạng thái READY_FOR_MATERIAL_ALLOCATION.
• Lệnh Sản xuất yêu cầu 100kg Bột mì loại A (ITEM-BM-001).
• Tồn kho Bột mì loại A:
• LOT-BM-001-202601: 50kg, HSD: 2026-09-01.
• LOT-BM-001-202602: 70kg, HSD: 2026-10-15.
• LOT-BM-001-202603: 120kg, HSD: 2026-12-30.

Luồng Chính (Main Flow):

1. Hệ thống Nova Foods ERP nhận yêu cầu phân bổ nguyên liệu cho Lệnh Sản xuất NF-PO-20260807-001, cần 100kg ITEM-BM-001.
2. Hệ thống truy vấn dữ liệu tồn kho cho ITEM-BM-001.
3. Hệ thống sắp xếp lô theo Hạn sử dụng tăng dần (FEFO): LOT-BM-001-202601, LOT-BM-001-202602, LOT-BM-001-202603.
4. Hệ thống phân bổ theo thứ tự FEFO:
5. LOT-BM-001-202601 có 50kg, phân bổ hết. Còn thiếu 50kg.
6. LOT-BM-001-202602 có 70kg, phân bổ 50kg. Còn thiếu 0kg.
7. Hệ thống cập nhật số lượng tồn kho, tạo bản ghi phân bổ cho từng lotId.

Điều kiện hậu (Post-conditions):

• Lệnh Sản xuất NF-PO-20260807-001 có 100kg ITEM-BM-001 được phân bổ từ LOT-BM-001-202601 (50kg), LOT-BM-001-202602 (50kg).
• Tồn kho LOT-BM-001-202601: 0kg.
• Tồn kho LOT-BM-001-202602: 20kg.
• Tồn kho LOT-BM-001-202603: 120kg.
• Hệ thống lưu transactionId để truy vết tác nhân, lệnh sản xuất, lô và lượng đã phân bổ.

Ví dụ Dữ liệu Trao đổi (Example Data Payload)

API: POST /api/v1/production-orders/{prodOrderId}/allocate-material

Yêu cầu Phân bổ Nguyên liệu (Request Payload - JSON):

{
  "productionOrderId": "NF-PO-20260807-001",
  "materialRequirements": [
    {
      "itemId": "ITEM-BM-001",
      "requiredQuantity": 100,
      "uom": "kg"
    }
  ],
  "allocationStrategy": "FEFO",
  "requestedBy": "NovaERP_System"
}

Phản hồi Phân bổ Thành công (Response Payload - JSON):

{
  "status": "SUCCESS",
  "message": "Nguyên liệu đã được phân bổ thành công.",
  "productionOrderId": "NF-PO-20260807-001",
  "allocatedMaterials": [
    {
      "itemId": "ITEM-BM-001",
      "allocatedLots": [
        {
          "lotId": "LOT-BM-001-202601",
          "quantity": 50,
          "uom": "kg",
          "expiryDate": "2026-09-01"
        },
        {
          "lotId": "LOT-BM-001-202602",
          "quantity": 50,
          "uom": "kg",
          "expiryDate": "2026-10-15"
        }
      ]
    }
  ],
  "transactionId": "NF-ALLOC-20260807-001"
}

Biểu đồ Hoạt động (Activity Diagram)

Quá trình phân bổ lô tự động theo FEFO:

graph TD
    A[Bắt đầu: Lệnh SX cần nguyên liệu] --> B{Có nguyên liệu yêu cầu?};
    B -- Có --> C[Truy vấn tồn kho lô theo ITEM_ID];
    C --> D[Sắp xếp các lô theo Hạn sử dụng (HSD) tăng dần];
    D --> E{Còn số lượng cần phân bổ?};
    E -- Có --> F[Chọn lô đầu tiên (HSD gần nhất)];
    F --> G{Số lượng lô hiện tại >= Số lượng cần phân bổ?};
    G -- Có --> H[Phân bổ đủ từ lô];
    G -- Không --> I[Phân bổ hết lô hiện tại];
    I --> J[Cập nhật số lượng cần phân bổ còn lại];
    H --> K[Kết thúc: Nguyên liệu phân bổ đủ];
    J --> E;
    B -- Không --> L[Kết thúc: Không đủ nguyên liệu];

9. Related Concepts & Dependencies

Core

Khái niệm AI-assisted BA Workflow (Quy trình BA được hỗ trợ bởi AI) không đứng độc lập. Nó phụ thuộc vào nhiều khái niệm nghiệp vụ nền tảng (upstream concepts) và tạo ra đầu ra (outputs) được các quy trình, tài liệu khác sử dụng (downstream concepts). Hiểu rõ các liên kết này giúp BA đảm bảo tính nhất quán, khả năng truy vết (traceability) và đánh giá tác động thay đổi (change impact assessment) hiệu quả.

Applied

Để đảm bảo quy trình BA được hỗ trợ bởi AI tại Nova Foods (mô phỏng) hoạt động hiệu quả và có thể kiểm soát, cần lập bản đồ các thành phần liên quan. * Facts: Chương này mô tả quy trình BA sử dụng AI tạo các artifact. * Current Behavior: BA tạo bản nháp tài liệu (ví dụ: yêu cầu, tiêu chí chấp nhận) dùng công cụ AI. * Underlying Need: Đảm bảo đầu ra AI tuân thủ cấu trúc corpus, quy tắc nghiệp vụ Nova Foods, và có tính truy vết. * Options: 1. Không định nghĩa dependency: AI tạo output độc lập, không kiểm soát. 2. Định nghĩa dependency thủ công, không chuẩn hóa: Dễ sai sót, khó cập nhật. 3. Định nghĩa dependency có cấu trúc, tham chiếu canonical source: Tăng tính nhất quán, dễ quản lý thay đổi. * Decision Criteria: Khả năng truy vết, tính nhất quán dữ liệu, hiệu quả quản trị thay đổi. * Decision: Áp dụng định nghĩa dependency có cấu trúc, sử dụng các registry và manifest làm nguồn chân lý (canonical sources of truth). * Authority: Principal IT Business Analyst / Technical Curriculum Author. * Artifact: Bảng dependency dưới đây. * Consequence if Wrong: AI tạo nội dung sai cấu trúc, lặp lại thông tin, thiếu truy vết, dẫn đến rework lớn, mất niềm tin vào công cụ AI.

Bản đồ Dependency của Chương 25-ai-assisted-ba-workflow.md

Bảng sau liệt kê các phụ thuộc (dependencies) ngược dòng (upstream) và xuôi dòng (downstream) của chương 25-ai-assisted-ba-workflow.md, cùng với các registry, template, và ID liên quan.

Loại Dependency	ID / Tên File	Mô tả ngắn gọn	Lý do phụ thuộc
UPSTREAM: Khái niệm Nền tảng	BABOK Guide	Kiến thức nghiệp vụ BA chung.	Cung cấp nền tảng lý thuyết cho các hoạt động BA.
	ISO/IEC/IEEE 29148	Tiêu chuẩn về quy trình yêu cầu.	Đảm bảo quy trình tuân thủ chuẩn quốc tế về quản lý yêu cầu.
UPSTREAM: Cấu trúc Corpus	00_SOURCE_MAP	Bản đồ nguồn canonical.	Đảm bảo AI tham chiếu nguồn chính xác, không tạo thông tin sai lệch.
	01_CURRICULUM_ARCHITECTURE	Kiến trúc tổng thể chương trình.	Đảm bảo quy trình phù hợp với cấu trúc tổng thể của corpus.
	CHAPTER_MANIFEST	Danh sách chapter chính tắc.	Đảm bảo chapter này được đăng ký và liên kết đúng.
	TEMPLATE_MANIFEST	Danh sách template chính tắc.	Các template là đầu vào/đầu ra của workflow AI.
UPSTREAM: Registry & Rule Base	TRACEABILITY_ID_REGISTRY	Đăng ký ID truy vết chính tắc.	AI phải tạo hoặc tham chiếu ID theo quy tắc định nghĩa ở đây (ví dụ: AC-, BR-, REQ-).
	CANONICAL_BUSINESS_RULES	Catalog quy tắc nghiệp vụ Nova Foods.	AI dùng các quy tắc này làm cơ sở tạo acceptance criteria, requirement, test cases.
	CANONICAL_DATA_DICTIONARY	Từ điển dữ liệu logic Nova Foods.	AI cần định nghĩa dữ liệu chuẩn để tạo các đặc tả.
DOWNSTREAM: Các Chương khác	26-writing-effective-requirements.md	Chương viết yêu cầu hiệu quả.	Đầu ra của AI-assisted BA workflow là đầu vào cho việc viết yêu cầu.
	27-designing-acceptance-criteria.md	Chương thiết kế tiêu chí chấp nhận.	AI hỗ trợ tạo Acceptance Criteria (AC).
	28-test-case-design.md	Chương thiết kế kịch bản kiểm thử.	AC và Requirement (REQ) từ AI là cơ sở thiết kế test case.
DOWNSTREAM: Templates	GEN-TMPL-REQ-001	Template tài liệu Yêu cầu.	AI có thể sinh bản nháp dựa trên template này.
	GEN-TMPL-AC-001	Template tiêu chí chấp nhận.	AI có thể sinh bản nháp dựa trên template này.
	GEN-TMPL-TC-001	Template kịch bản kiểm thử.	AI có thể sinh bản nháp dựa trên template này.
DOWNSTREAM: Persistent IDs	REQ-{NNN}	Định danh yêu cầu.	AI sinh ra hoặc tham chiếu.
	AC-{NNN}	Định danh tiêu chí chấp nhận.	AI sinh ra hoặc tham chiếu.
	TC-{NNN}	Định danh kịch bản kiểm thử.	AI sinh ra hoặc tham chiếu.
	BR-{NNN}	Định danh quy tắc nghiệp vụ.	AI tham chiếu từ CANONICAL_BUSINESS_RULES.

Senior Lens

Hiểu biết về dependency không chỉ là lý thuyết. Trong thực tế, đây là công cụ chính để quản lý rủi ro thay đổi. Khi một thành phần ngược dòng (upstream) thay đổi (ví dụ: một quy tắc nghiệp vụ tại CANONICAL_BUSINESS_RULES được điều chỉnh), BA cần nhanh chóng xác định các chapter, template, và ID nào sẽ bị ảnh hưởng. Việc này đặc biệt quan trọng với AI, khi AI có thể học từ dữ liệu cũ và tạo ra kết quả không chính xác nếu nguồn chân lý thay đổi mà không được cập nhật. Bản đồ này giúp BA tránh việc AI tạo ra các artifact vi phạm quy tắc mới, đảm bảo tính liên tục của dữ liệu và quy trình.

Quick Reference

• Upstream: Các nguồn đầu vào, quy tắc, cấu trúc mà chapter này dựa vào.
• Downstream: Các chapter, template, ID sẽ sử dụng hoặc bị ảnh hưởng bởi đầu ra của chapter này.
• Canonical Source of Truth (Nguồn chân lý): Tài liệu duy nhất chứa thông tin chính xác và có thẩm quyền cho một loại dữ liệu cụ thể (ví dụ: TRACEABILITY_ID_REGISTRY cho cấu trúc ID).
• Traceability (Truy vết): Khả năng theo dõi một yêu cầu từ nguồn gốc đến triển khai và kiểm thử, và ngược lại.

Bảng Truy vết và Phụ thuộc trong Quy trình BA Hỗ trợ AI (Nova Foods)

Mọi hoạt động BA đều có phụ thuộc (dependencies) và cần truy vết (traceability). Truy vết liên kết các artifact, cho thấy một mục nào đó đến từ đâu (upstream) và ảnh hưởng đến những gì (downstream). Bảng này minh họa cách các bước trong quy trình BA hỗ trợ AI kết nối với các yếu tố khác, bao gồm yêu cầu nghiệp vụ (NEED), yêu cầu chức năng/phi chức năng (REQ), quy tắc nghiệp vụ (BR), tiêu chí chấp nhận (AC), dữ liệu (DATA/API), kịch bản kiểm thử (TC), các chương trong handbook, template, và registry ID. Thay đổi không báo động ở một phụ thuộc ngược dòng có thể phá vỡ tính đúng đắn của các mục phụ thuộc xuôi dòng, dẫn đến sai sót nghiệp vụ hoặc lãng phí công sức làm lại.

Mục Quy trình BA Hỗ trợ AI	Loại Artifact	Mã Định danh/Tham chiếu	Mô tả ngắn gọn	Phụ thuộc Ngược dòng (Upstream)	Phụ thuộc Xuôi dòng (Downstream)	Hậu quả Thay đổi Không báo
Phác thảo Yêu cầu (REQ) ban đầu với AI	WF-ACTIVITY	WF-AI-BA-010	AI tạo dự thảo user stories/yêu cầu dựa trên NEED và tài liệu đầu vào.	NEED: NF-NEED-001 (Yêu cầu nghiệp vụ: Tự động hóa Đơn hàng Nova Foods) BR: NF-BR-001 (Quy tắc duyệt đơn hàng Nova Foods) DATA: NF-DATA-005 (Dữ liệu lịch sử đơn hàng Nova Foods) CHAPTER: /02-handbook/04-input-artifacts.md (Hướng dẫn về Input)	REQ: NF-REQ-USR-010 (User Story: Tự động duyệt đơn hàng nhỏ) CHAPTER: /02-handbook/06-output-artifacts.md (Mô tả Output)	Nếu NF-NEED-001 thay đổi trọng tâm mà không báo, AI phác thảo yêu cầu không còn phù hợp mục tiêu kinh doanh. Nếu NF-BR-001 sửa đổi ngưỡng duyệt, các REQ do AI tạo ra sẽ sai luật nghiệp vụ Nova Foods.
Xây dựng Tiêu chí Chấp nhận (AC) cho REQ với AI	WF-ACTIVITY	WF-AI-BA-020	AI đề xuất các tiêu chí chấp nhận cụ thể, kiểm tra được, cho từng yêu cầu.	REQ: NF-REQ-USR-010 (User Story: Tự động duyệt đơn hàng nhỏ) BR: NF-BR-001 (Quy tắc duyệt đơn hàng Nova Foods) TEMPLATE: /03-templates/GEN-TMPL-003-AC.md (Mẫu AC) CHAPTER: /02-handbook/05-step-by-step-ba-activities.md (Hướng dẫn Step-by-step BA)	AC: NF-AC-010 (AC cho NF-REQ-USR-010: Duyệt đơn hàng < 5tr VND) TC: NF-TC-010 (Kịch bản kiểm thử sơ bộ từ AC) CHAPTER: /02-handbook/07-consumers.md (Ai sử dụng AC)	Nếu NF-REQ-USR-010 thay đổi phạm vi mà AC không cập nhật, kiểm thử dựa trên yêu cầu cũ, dẫn đến tính năng mới không được kiểm tra hoặc lỗi không phát hiện. Nếu NF-BR-001 thay đổi, AC sai nghiệp vụ.
Gợi ý Kịch bản Kiểm thử (TC) từ AC với AI	WF-ACTIVITY	WF-AI-BA-030	AI phân tích AC để đề xuất các trường hợp kiểm thử, bao gồm cả kịch bản biên.	AC: NF-AC-010 (AC cho NF-REQ-USR-010) BR: NF-BR-002 (Quy tắc xác nhận trạng thái kho Nova Foods) REGISTRY: /01-curriculum/TRACEABILITY_ID_REGISTRY.md (Hướng dẫn ID) ISTQB CTFL: (Nguồn tham khảo nguyên tắc kiểm thử)	TC: NF-TC-010 (Kiểm thử chức năng Duyệt đơn hàng tự động) CHAPTER: /02-handbook/07-consumers.md (Ai sử dụng TC) TEMPLATE: /03-templates/GEN-TMPL-004-TC.md (Mẫu TC)	Nếu NF-AC-010 sửa đổi mà TC không phản ánh, kiểm thử sẽ không bao phủ tiêu chí chấp nhận mới, gây rủi ro phát hành lỗi. Nếu NF-BR-002 về kho thay đổi, TC liên quan đến tích hợp kho sẽ không còn giá trị, dẫn đến sai sót nghiệp vụ ở quy trình xuất kho.

Core

Dependency (Phụ thuộc): Một yếu tố (artifact, quy tắc, hệ thống) cần có yếu tố khác để hoạt động đúng. Nếu yếu tố gốc (upstream) đổi, yếu tố dựa vào nó (downstream) cũng đổi theo. Không đổi, sẽ sai.

Lan truyền thay đổi (Change Propagation): Thay đổi một chỗ, nó kéo theo thay đổi chỗ khác. Giống như gạch domino. Cái đầu đổ, cái sau đổ.

Upstream (Nguồn gốc): Yếu tố ban đầu. Thay đổi ở đây bắt đầu. Downstream (Hệ quả): Yếu tố chịu ảnh hưởng từ nguồn gốc. Nó phải cập nhật theo nguồn gốc.

Nếu BR NF-BR-101 ("Điều kiện giao hàng miễn phí") đổi, thì NF-REQ-SYS-050 ("Yêu cầu hệ thống tính phí giao hàng") phải đổi. Kèm theo đó, test case, code và tài liệu người dùng cũng đổi.

Applied

Tình huống Nova Foods: Thay đổi thuế VAT.

• Facts (Sự thật): Chính phủ Việt Nam ban hành Nghị định mới. Mức thuế VAT cho một số mặt hàng từ 10% giảm còn 8% (Nghị định 356/2025/NĐ-CP, ví dụ). Nova Foods kinh doanh mặt hàng đó. BR (NF-BR-VAT-001: "Mức VAT sản phẩm đông lạnh") bị ảnh hưởng.
• Current Behavior (Hành vi hiện tại): Hệ thống ERP Nova Foods (mô phỏng) tính VAT 10% cho sản phẩm đông lạnh. Dựa trên BR NF-BR-VAT-001 trong CANONICAL_BUSINESS_RULES.md.
• Underlying Need (Nhu cầu cốt lõi): Nova Foods cần tuân thủ pháp luật thuế (Luật Kế toán 88/2015/QH13, các Nghị định liên quan). Tránh phạt, đảm bảo báo cáo tài chính đúng.
• Options (Các lựa chọn):
  1. Không làm gì: Tiếp tục tính 10%.
  2. Cập nhật BR, Requirement, Code, Test.
• Decision Criteria (Tiêu chí quyết định):
  • Tuân thủ quy định pháp luật Việt Nam.
  • Đảm bảo chính xác tài chính kế toán.
  • Giảm thiểu rủi ro pháp lý.
• Decision (Quyết định): Cập nhật toàn bộ hệ thống để tính VAT 8% theo luật mới.
• Authority (Thẩm quyền): Bộ Tài chính (ban hành luật). Legal Owner, Accounting Owner của Nova Foods (chấp thuận thay đổi nội bộ).
• Artifact (Thành phần ảnh hưởng):
  • Upstream: Nghị định 356/2025/NĐ-CP.
  • BR: NF-BR-VAT-001 trong /01-curriculum/CANONICAL_BUSINESS_RULES.md.
  • Requirement: NF-REQ-SYS-TAX-001 ("Hệ thống phải tính thuế VAT đúng").
  • Design: Tài liệu thiết kế hệ thống tính thuế.
  • Code: Module tính thuế trong ERP Nova Foods.
  • Test Cases: NF-TC-TAX-005 ("Xác minh VAT 8% cho hóa đơn X").
  • User Manual: Hướng dẫn sử dụng cho nhân viên kế toán.
• Consequence if Wrong (Hậu quả nếu sai): Nova Foods bị cơ quan thuế phạt nặng. Báo cáo tài chính sai lệch. Khách hàng Nova Foods có thể khiếu nại. Uy tín doanh nghiệp giảm.

Senior Lens

Thay đổi ngầm (Silent Change): Thay đổi một dependency (phụ thuộc) nhưng không thông báo, không cập nhật các yếu tố liên quan (downstream artifacts). Rất nguy hiểm.

Điều gì vỡ khi dependency đổi ngầm? * Tính đúng đắn (Correctness): Hệ thống tính toán sai (ví dụ: VAT). Báo cáo sai. * Tính pháp lý (Compliance): Vi phạm luật pháp (ví dụ: luật thuế, bảo vệ dữ liệu Luật 91/2025/QH15). Dẫn đến phạt, kiện tụng. * Tính toàn vẹn dữ liệu (Data Integrity): Dữ liệu lưu trữ bị lỗi, không nhất quán. Khó sửa. * Hiệu suất (Performance): Hệ thống chạy chậm, lỗi. Do không tối ưu cho thay đổi. * An ninh (Security): Lỗ hổng mới xuất hiện. Kẻ xấu lợi dụng. * Uy tín (Reputation): Khách hàng, đối tác mất niềm tin.

Phòng ngừa: * Kiểm soát thay đổi chính thức (Formal Change Control): Mọi thay đổi qua quy trình rõ ràng. Có người phê duyệt. * Quản lý phiên bản (Versioning): Mỗi artifact có phiên bản rõ ràng. Biết khi nào đổi. * Truy vết (Traceability): Liên kết rõ ràng các dependency. Dùng TRACEABILITY_ID_REGISTRY. Biết cái nào dựa cái nào. * Truyền thông rõ ràng (Clear Communication): Thông báo cho tất cả bên liên quan.

Quick Reference

Sơ đồ Lan truyền Thay đổi VAT Nova Foods:

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

flowchart TD
    subgraph LEGAL["Nguồn pháp lý"]
        LAW["Luật hoặc nghị định mới"]
    end

    subgraph INTERNAL["Nova Foods"]
        CHANGE{"Mức VAT thay đổi?"}
        CONFIRM["Pháp chế và BA xác nhận mức VAT mới"]
        RULEFIX["BA cập nhật NF-BR-VAT-001 và tài liệu canonical"]
        VALIDATE{"Rule khớp mức VAT đã xác nhận?"}
        ANALYZE{"Nguồn sai lệch?"}
        ASSESS["BA đánh giá tác động và lưu evidence"]
        DOC{"Tài liệu bị tác động?"}
        DOCFIX["BA cập nhật tài liệu bị tác động"]
        CLOSE["Kết thúc đánh giá"]
        RISK["Rủi ro tính sai VAT, sai hóa đơn hoặc vi phạm pháp luật"]
    end

    LAW --> CHANGE
    CHANGE -->|"Có"| CONFIRM
    CHANGE -->|"Không"| ASSESS
    CONFIRM --> RULEFIX
    RULEFIX --> VALIDATE
    VALIDATE -->|"Đạt"| ASSESS
    VALIDATE -->|"Không đạt"| ANALYZE
    ANALYZE -->|"Xác nhận mức VAT"| CONFIRM
    ANALYZE -->|"Rule canonical"| RULEFIX
    VALIDATE -.->|"Nếu dùng rule chưa đạt"| RISK
    ASSESS --> DOC
    DOC -->|"Có"| DOCFIX
    DOC -->|"Không"| CLOSE
    DOCFIX --> CLOSE

Bảng Tổng hợp Tác động Thay đổi Ngầm:

Loại Dependency	Ảnh hưởng khi đổi ngầm	Ví dụ Nova Foods (mô phỏng)	ID tham chiếu
Quy tắc nghiệp vụ (BR)	Tính toán sai, vi phạm pháp luật	Mức VAT 10% thay vì 8%	NF-BR-VAT-001
Yêu cầu (REQ)	Tính năng sai, không đúng nhu cầu	Chức năng đặt hàng không kiểm tra kho tồn	NF-REQ-BIZ-ORDER-003
Dữ liệu/Cấu trúc (DATA)	Dữ liệu hỏng, không tương thích	Trường 'mã sản phẩm' đổi kiểu dữ liệu, hệ thống cũ crash	CANONICAL_DATA_DICTIONARY.md
API/Giao diện (API)	Kết nối thất bại, trao đổi dữ liệu lỗi	API đối tác vận chuyển đổi endpoint, đơn hàng không chuyển đi	TEMPLATE_MANIFEST.md
Pháp luật/Chính sách	Rủi ro pháp lý, phạt hành chính	Bỏ qua luật bảo vệ dữ liệu cá nhân (PDPA) mới	Luật 91/2025/QH15

10. Common Mistakes & Anti-patterns

Core

AI là công cụ mạnh mẽ, nhưng không phải giải pháp toàn năng. BA mới (novice BA) và nhóm triển khai (delivery team) thường mắc phải các sai lầm nghiêm trọng khi dựa vào AI mà không hiểu rõ giới hạn của nó. Mục này liệt kê các lỗi phổ biến, dấu hiệu nhận biết (observable red flags), nguyên nhân gốc rễ (root causes) và hành động khắc phục (corrective actions) để đảm bảo chất lượng và tính chính xác của tài liệu nghiệp vụ (business requirement) trong môi trường Nova Foods (mô phỏng). AI giúp tăng tốc đáng kể, nhưng không thể và không nên thay thế tư duy phản biện (critical thinking) và xác minh (validation) của BA.

Applied

• Tình huống: Dự án ERP tại Nova Foods (mô phỏng) có mục tiêu tự động hóa quy trình quản lý kho. Một BA mới được giao nhiệm vụ viết yêu cầu cho module nhập/xuất kho. Để tiết kiệm thời gian, BA này sử dụng công cụ AI để tạo bản nháp (draft) các yêu cầu, dựa trên tài liệu quy trình cũ và một số thông tin sơ bộ về kho.
• Hành vi hiện tại: BA nhận bản nháp từ AI, thấy các yêu cầu "có vẻ hợp lý" về mặt cấu trúc và ngôn ngữ. BA chỉnh sửa một vài lỗi chính tả, câu từ cho mượt mà mà không thực hiện phỏng vấn sâu (in-depth interview) hoặc xác minh (validation) chi tiết với quản lý kho thực tế hay người dùng nghiệp vụ tại Nova Foods.
• Nhu cầu cơ bản: Tăng tốc độ tạo yêu cầu (requirement generation speed) nhưng vẫn phải đảm bảo tính chính xác nghiệp vụ (business accuracy) và phù hợp với quy trình vận hành kho đặc thù của Nova Foods, bao gồm cả các quy định về hạn sử dụng, lô sản xuất, v.v.
• Các phương án:
  1. AI hỗ trợ nháp + BA xác minh kỹ: Dùng AI tạo bản nháp đầu tiên, sau đó BA chủ động phỏng vấn, thu thập thêm thông tin, đối chiếu với người dùng nghiệp vụ (Business User) và các quy tắc nghiệp vụ trong CANONICAL_BUSINESS_RULES.md.
  2. AI tạo nháp + BA chỉnh sửa nhẹ: Dùng AI tạo bản nháp, BA chỉ đọc và chỉnh sửa ngôn ngữ mà không xác minh nghiệp vụ chuyên sâu với stakeholder.
  3. BA viết yêu cầu thủ công: Không dùng AI, BA tự viết toàn bộ yêu cầu qua các buổi phỏng vấn và phân tích truyền thống.
• Tiêu chí quyết định:
  • Tốc độ (Speed): Thời gian để hoàn thành tài liệu yêu cầu.
  • Độ chính xác nghiệp vụ (Business Accuracy): Mức độ phản ánh đúng thực tế vận hành và nhu cầu của Nova Foods.
  • Rủi ro triển khai (Implementation Risk): Khả năng yêu cầu sai sót dẫn đến phải sửa đổi code (rework) sau này.
  • Chi phí sửa lỗi (Cost of Rework): Sửa lỗi càng muộn, chi phí càng cao.
• Quyết định: Chọn phương án 1. Dùng AI để tạo bản nháp yêu cầu nhập/xuất kho ban đầu. Sau đó, BA phải dành thời gian phỏng vấn trực tiếp quản lý kho, kiểm tra các quy tắc nghiệp vụ đặc thù (ví dụ: quy định FIFO/LIFO của Nova Foods), đối chiếu với các định nghĩa dữ liệu trong CANONICAL_DATA_DICTIONARY.md và ghi nhận các ID truy vết (traceability ID) theo TRACEABILITY_ID_REGISTRY.md trước khi hoàn thiện.
• Thẩm quyền (Authority): Quyết định về quy trình BA do Trưởng phòng BA (Senior BA) đưa ra. Xác nhận tính chính xác nghiệp vụ cuối cùng do Business Owner (Chủ nghiệp vụ) của module kho thực hiện.
• Artifact liên quan: /02-handbook/25-ai-assisted-ba-workflow.md (hướng dẫn quy trình BA dùng AI), /01-curriculum/CANONICAL_BUSINESS_RULES.md (nơi chứa các quy tắc nghiệp vụ), /01-curriculum/CANONICAL_DATA_DICTIONARY.md (định nghĩa dữ liệu), /01-curriculum/TRACEABILITY_ID_REGISTRY.md (hướng dẫn gắn ID truy vết).
• Hậu quả nếu sai (Consequence if Wrong - chọn phương án 2): Hệ thống quản lý kho được triển khai theo yêu cầu sai lệch do AI tạo ra và BA không xác minh. Ví dụ, hệ thống không tính đúng hạn sử dụng (expiration date) hoặc không hỗ trợ quy trình kiểm kê đột xuất (ad-hoc inventory check) đặc thù của Nova Foods. Điều này dẫn đến tồn kho ảo, hàng hóa hết hạn không được xử lý, gây thiệt hại tài chính lớn và cần tốn rất nhiều chi phí, thời gian để sửa lỗi khi đã triển khai (post-deployment rework).

Senior Lens

BA cấp cao (Senior BA) có vai trò then chốt trong việc định hướng sử dụng AI một cách hiệu quả và an toàn. Họ phải xây dựng quy trình, hướng dẫn và tiêu chuẩn (guidelines and standards) rõ ràng cho việc tích hợp AI vào quy trình phân tích nghiệp vụ. Điều này bao gồm việc nhấn mạnh rằng AI là công cụ tăng cường (augmentation tool), không phải thay thế tư duy và kinh nghiệm của BA. Senior BA cần đào tạo đội ngũ về tầm quan trọng của bối cảnh nghiệp vụ (business context), quản lý stakeholder (stakeholder management), và khả năng phán đoán chuyên môn (professional judgment) – những kỹ năng mà AI chưa thể sao chép. Đồng thời, phải thiết lập các rào chắn (guardrails) và quy trình kiểm soát chất lượng (quality control process) để tránh các "ảo giác" (hallucinations) hoặc thông tin sai lệch do AI tạo ra, đảm bảo mọi đầu ra của AI đều được xác minh độc lập trước khi trở thành tài liệu chính thức.

Quick Reference

Bảng dưới đây tổng hợp các sai lầm phổ biến khi sử dụng AI trong công việc BA, dấu hiệu nhận biết và cách khắc phục:

Sai lầm (Mistake)	Dấu hiệu đỏ (Red Flag)	Nguyên nhân gốc (Root Cause)	Hành động khắc phục (Corrective Action)	Tham chiếu (Reference)
1. Phụ thuộc AI quá mức vào bối cảnh nghiệp vụ (Over-reliance on AI for business context)	Yêu cầu (requirements) chung chung, thiếu chi tiết đặc thù Nova Foods (mô phỏng). Stakeholder từ chối, không xác nhận yêu cầu.	BA bỏ qua phỏng vấn, thu thập thông tin trực tiếp. Coi AI là nguồn duy nhất, không thực hiện validation (xác minh).	Luôn xác minh kết quả AI với Business User và các chuyên gia nghiệp vụ. Đặt AI làm công cụ hỗ trợ, không thay thế BA.	BABOK Guide (KA: Elicitation and Collaboration)
2. Sử dụng nguồn đầu vào cũ/không chính xác cho AI	Output của AI mâu thuẫn với quy trình/chính sách hiện hành của Nova Foods. Thông tin lỗi thời, không nhất quán.	Quy trình quản lý version (phiên bản) tài liệu đầu vào cho AI lỏng lẻo. BA không kiểm tra tính cập nhật của nguồn.	Chỉ dùng tài liệu đã được baseline (chốt phiên bản) hoặc approved (phê duyệt) từ 00_SOURCE_MAP.md làm input cho AI.	01-curriculum/01_CURRICULUM_ARCHITECTURE.md
3. Thiếu truy vết (traceability) cho output từ AI	Không thể giải thích nguồn gốc của yêu cầu. Khó khăn khi phân tích tác động (impact analysis) của thay đổi.	BA xem AI là "hộp đen". Bỏ qua quy trình gắn ID và liên kết nguồn gốc của thông tin do AI tạo.	Áp dụng TRACEABILITY_ID_REGISTRY.md để gắn ID duy nhất và liên kết mọi output của AI với mục tiêu, stakeholder hoặc nguồn gốc ban đầu.	01-curriculum/TRACEABILITY_ID_REGISTRY.md
4. "Ảo giác" (hallucination) của AI gây hiểu lầm	AI tạo ra thông tin không có thật, quy trình không tồn tại, hoặc dữ liệu bịa đặt.	AI không có khả năng hiểu ngữ cảnh (contextual understanding) sâu sắc. Thiếu kiểm tra thực tế (fact-checking) của con người.	Luôn cross-reference (đối chiếu chéo) thông tin từ AI với các nguồn đáng tin cậy. Tuyệt đối không chấp nhận thông tin AI không có bằng chứng.	Nguyên tắc BA cơ bản về xác minh thông tin.

Sơ đồ quy trình tạo yêu cầu (Requirement Generation Process) lỗi khi lạm dụng AI:

graph TD
    subgraph BA Hoạt động kém hiệu quả
        A[BA nhập Prompt/Tài liệu CŨ/THIẾU vào AI]
        B(AI tạo Requirement Draft "có vẻ hợp lý")
        C{BA chỉ chỉnh sửa bề mặt?}
        C -- CÓ (KHÔNG xác minh nghiệp vụ) --> D(Requirement SAI LỆCH/THIẾU SÓT)
    end

    subgraph Hậu quả (Nova Foods mô phỏng)
        D --> E[Dev code sai yêu cầu nghiệp vụ]
        E --> F[QA/Testing phát hiện lỗi MUỘN]
        F --> G[Chi phí sửa lỗi RẤT CAO, dự án trễ]
        G --> H[Hệ thống ERP triển khai không hiệu quả]
        H --> I[Thiệt hại tài chính, mất niềm tin người dùng]
    end

    subgraph Đúng cách (tham khảo)
        C -- KHÔNG (Xác minh với Business User) --> J[Requirement CHÍNH XÁC, được phê duyệt]
        J --> K[Triển khai thành công, hiệu quả]
    end

Nguy cơ từ Kết quả AI Sai lệch hoặc Thiếu Tính Thẩm Quyền

AI công cụ, không chuyên gia nghiệp vụ. AI tạo văn bản. AI không "hiểu" ngữ cảnh, luật pháp, hoặc quy trình đặc thù Nova Foods (mô phỏng). Kết quả AI có thể sai, thiếu, lạc hậu, hoặc viện dẫn nguồn không có thật. BA không được tin tưởng mù quáng.

Core

AI hoạt động dựa trên các mẫu ngôn ngữ từ dữ liệu huấn luyện. Dữ liệu này có thể chứa thông tin không chính xác, lỗi thời, hoặc diễn giải sai lệch các quy định pháp luật, quy tắc kế toán, hoặc yêu cầu an toàn thực phẩm. AI không có khả năng kiểm tra tính hợp lệ pháp lý, tính đúng đắn nghiệp vụ, hoặc thẩm quyền của một yêu cầu. Việc sử dụng AI mà không kiểm chứng tạo rủi ro lớn.

Applied

Nova Foods (mô phỏng) cần hệ thống quản lý kho đông lạnh. Hệ thống cần khả năng truy vết lô sản xuất (batch traceability), quản lý ngày hết hạn (expiry date management), và theo dõi nhiệt độ bảo quản.

• Facts: Nova Foods nhập hàng hóa đông lạnh, bán hàng cho siêu thị. Yêu cầu truy vết nguồn gốc, hạn sử dụng, điều kiện bảo quản.
• Current Behavior: BA dùng AI để tạo bản nháp đầu tiên của tài liệu yêu cầu (requirements document) cho "module quản lý kho". AI gợi ý các trường dữ liệu chung như product_id, quantity, warehouse_location.
• Underlying Need: Tăng tốc độ soạn thảo yêu cầu ban đầu.
• Options:
  1. Dùng yêu cầu do AI tạo làm bản chính thức, không kiểm tra thêm.
  2. Dùng yêu cầu do AI tạo làm bản nháp, sau đó BA rà soát, bổ sung, xác minh với Business Owner, Legal Owner.
• Decision Criteria: Tuân thủ pháp luật (compliance), khả năng thu hồi sản phẩm (product recall), giảm thiểu tổn thất hàng hóa, uy tín doanh nghiệp.
• Decision: Chọn Option 2. Mọi yêu cầu liên quan đến luật pháp, an toàn thực phẩm phải được kiểm tra lại.
• Authority: Business Owner Nova Foods (quyết định nghiệp vụ), Legal/Compliance Owner (xác nhận tuân thủ pháp luật), BA (đảm bảo yêu cầu đầy đủ).
• Artifact: Yêu cầu chức năng (Functional Requirements Document), /01-curriculum/CANONICAL_BUSINESS_RULES.md (quy tắc nghiệp vụ), /01-curriculum/CANONICAL_DATA_DICTIONARY.md (từ điển dữ liệu), 00-research/00_SOURCE_MAP.md (nguồn pháp lý tham chiếu).
• Consequence if Wrong:
  • Hệ thống quản lý kho được xây dựng không có các trường batch_number, expiry_date, temperature_zone.
  • Nếu phát hiện lô hàng bị nhiễm khuẩn, Nova Foods không thể nhanh chóng xác định sản phẩm liên quan để thu hồi. Vi phạm Luật An toàn thực phẩm (Luật 55/2010/QH12). Nova Foods (mô phỏng) bị phạt, mất uy tín.
  • Hàng hóa hết hạn sử dụng có thể được xuất đi, gây tổn thất tài chính, ảnh hưởng sức khỏe người tiêu dùng.
  • Không quản lý được điều kiện bảo quản chính xác dẫn đến hỏng hóc hàng hóa.

Senior Lens

[!WARNING] Không bao giờ để AI đưa ra quyết định hoặc xác nhận nghiệp vụ, pháp lý, kế toán, bảo mật. AI công cụ, không thẩm quyền. BA chịu trách nhiệm cuối cùng. Luôn xem AI output là bản nháp đầu tiên cần kiểm tra nghiêm ngặt.

BA có kinh nghiệm luôn đặt câu hỏi phản biện với mọi thông tin, đặc biệt từ AI. Các miền nhạy cảm như luật pháp, tài chính, an toàn sản phẩm yêu cầu BA phải tự tra cứu nguồn gốc (canonical source) và tham vấn người có thẩm quyền. AI tăng tốc soạn thảo, không thay thế tư duy và trách nhiệm kiểm chứng.

Quick Reference

Lỗi phổ biến (Common Mistake)	Dấu hiệu cảnh báo (Red Flag)	Nguyên nhân gốc (Root Cause)	Hành động khắc phục (Corrective Action)	Ranh giới phục hồi an toàn (Safe Recovery Boundary)
AI đưa thông tin nghiệp vụ sai/thiếu.	Yêu cầu chung chung, thiếu chi tiết định lượng (số lượng, thời gian, ngưỡng), không tham chiếu nguồn.	AI không có kiến thức miền sâu. Dữ liệu huấn luyện lỗi thời/không đủ.	BA phỏng vấn stakeholder. Đọc tài liệu hiện có. Đối chiếu với quy trình nghiệp vụ thực tế Nova Foods.	Trước khi chuyển giao yêu cầu cho đội phát triển (dev team) để thiết kế hệ thống.
AI viện dẫn nguồn luật, quy định sai/không có thật.	AI nói "theo luật..." hoặc "quy định yêu cầu..." nhưng không cung cấp điều khoản, số luật, ngày ban hành cụ thể hoặc văn bản không tồn tại/lạc hậu.	AI tổng hợp thông tin, có thể sai lệch, không có khả năng hiểu ngữ cảnh pháp lý.	BA tự tra cứu văn bản pháp luật gốc (00-research/00_SOURCE_MAP.md). Tham vấn Legal Owner/Compliance Owner.	Trước khi bất kỳ yêu cầu pháp lý nào được biến thành thiết kế hệ thống hoặc mã code.
AI tạo yêu cầu không nhất quán với quy tắc nghiệp vụ đã có.	Yêu cầu mới mâu thuẫn với CANONICAL_BUSINESS_RULES.md hoặc CANONICAL_DATA_DICTIONARY.md.	AI không có khả năng giữ "tính chân lý" (single source of truth) qua các artifact.	BA so sánh yêu cầu AI với các artifact gốc. Chỉnh sửa để đảm bảo tính nhất quán.	Trước khi tạo User Story hoặc Test Case từ yêu cầu AI.

Phân tách Lỗi Phổ biến: Mơ hồ, Thiếu, Không Căn cứ, Sai Ký pháp, Đứt Gãy Truy Vết

Core

BA gặp lỗi. Lỗi phổ biến: mơ hồ (ambiguity), không đầy đủ (incompleteness), khẳng định không căn cứ (unsupported authority claims), sai ký pháp (notation misuse), đứt gãy truy vết (traceability breaks). Hiểu lỗi, sửa lỗi, BA làm việc tốt.

Mơ hồ (Ambiguity)

Yêu cầu/thông tin có nhiều cách hiểu. BA viết chung chung. Ví dụ Nova Foods: "Hệ thống cần xử lý đơn hàng nhanh chóng." Từ "nhanh chóng" không rõ. Không biết là 1 giây, 5 giây hay hơn.

• Dấu hiệu (Red Flag): Từ ngữ không định lượng ("dễ dàng", "hiệu quả", "linh hoạt"). Thiếu số liệu, điều kiện cụ thể.
• Nguyên nhân gốc (Root Cause): BA không đào sâu yêu cầu (elicitation). Không xác nhận kỹ với chủ nghiệp vụ (Business Owner). Suy đoán thông tin.
• Hành động sửa chữa (Corrective Action): Định nghĩa thuật ngữ rõ. Dùng bảng từ vựng (glossary). Yêu cầu định lượng (ví dụ: "dưới 2 giây"). Tham chiếu CANONICAL_DATA_DICTIONARY (/01-curriculum/CANONICAL_DATA_DICTIONARY.md) chuẩn hóa định nghĩa.

Không đầy đủ (Incompleteness)

Tạo phẩm (artifact) thiếu thông tin triển khai, kiểm thử. Ví dụ Nova Foods: "Khách hàng được giảm giá 10% khi mua nhiều." Yêu cầu thiếu: "mua nhiều" là bao nhiêu, áp dụng cho sản phẩm nào, khách hàng nào.

• Dấu hiệu: Thiếu Tiêu chí chấp nhận (Acceptance Criteria). Thiếu điều kiện biên (boundary conditions). Không đủ kịch bản (scenario).
• Nguyên nhân gốc: BA không phân tích toàn diện. Thiếu checklist (danh sách kiểm tra). Bỏ qua trường hợp đặc biệt.
• Hành động sửa chữa: Dùng mô hình hóa (UML Use Case Diagram, Decision Table). Dùng checklist yêu cầu (ví dụ GEN-TMPL-REQ-001). Thu thập đủ điều kiện biên.

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

BA nói thông tin là sự thật hoặc quy tắc, nhưng không có nguồn xác thực. Ví dụ Nova Foods: "Luật pháp Việt Nam yêu cầu Nova Foods phải báo cáo hàng tồn kho mỗi tuần." BA không có bằng chứng luật, chỉ nghe.

• Dấu hiệu: Không tham chiếu tài liệu nguồn (luật, chính sách công ty, quyết định của Business Owner). Dùng từ "Tôi nghĩ...", "Có lẽ...".
• Nguyên nhân gốc: BA không hiểu ranh giới thẩm quyền. Thiếu kỷ luật truy vết (traceability) nguồn thông tin.
• Hành động sửa chữa: Luôn ghi rõ nguồn gốc quy tắc. Nguồn phải từ người có thẩm quyền (Legal Owner, Accounting Owner). Tham chiếu 00_SOURCE_MAP (/00-research/00_SOURCE_MAP.md). Mọi quy tắc nghiệp vụ phải có trong CANONICAL_BUSINESS_RULES (/01-curriculum/CANONICAL_BUSINESS_RULES.md) với thông tin thẩm quyền.

Sai ký pháp (Notation Misuse)

Dùng sai cú pháp, ngữ nghĩa của ký pháp mô hình hóa chuẩn. Ví dụ Nova Foods: BA dùng ký hiệu "Start Event" của BPMN (Business Process Model and Notation) trong biểu đồ Activity Diagram của UML (Unified Modeling Language).

• Dấu hiệu: Biểu đồ khó hiểu. Không tuân thủ chuẩn quốc tế. Người khác không hiểu đúng ý nghĩa mô hình.
• Nguyên nhân gốc: BA không nắm vững chuẩn ký pháp. Thiếu thực hành, không được review (xem xét lại) bởi người có kinh nghiệm.
• Hành động sửa chữa: Học chuẩn UML và BPMN từ 00_SOURCE_MAP. Tìm người kinh nghiệm review mô hình.

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

Mất liên kết giữa các tạo phẩm (yêu cầu, thiết kế, test case, tài liệu nguồn). Ví dụ Nova Foods: Yêu cầu NF-REQ-ACC-003 ghi nhưng không có liên kết đến test case nào kiểm thử nó.

• Dấu hiệu: Không thể biết yêu cầu từ đâu, tính năng giải quyết cái gì, test case kiểm thử cái nào. ID trong tài liệu không nhất quán.
• Nguyên nhân gốc: Quản lý yêu cầu lỏng lẻo. Không dùng ID chuẩn. Không dùng công cụ quản lý vòng đời ứng dụng (ALM tool).
• Hành động sửa chữa: Áp dụng TRACEABILITY_ID_REGISTRY (/01-curriculum/TRACEABILITY_ID_REGISTRY.md). Liên kết các tạo phẩm qua ID duy nhất. Dùng công cụ hỗ trợ truy vết.

Applied

Ví dụ Thực tế Nova Foods: Lỗi "Không đầy đủ" trong Quy trình Đặt hàng

• Facts (Sự kiện): Nova Foods cần hệ thống mới cho đặt hàng online.
• Current Behavior (Hành vi hiện tại): Khách hàng đặt hàng qua điện thoại, nhân viên sales ghi thủ công Excel, lỗi nhiều.
• Underlying Need (Nhu cầu cốt lõi): Tự động hóa đặt hàng, giảm lỗi, tăng tốc độ xử lý.
• Options (Các lựa chọn):
  1. Website đặt hàng đơn giản.
  2. Hệ thống e-commerce đầy đủ (giỏ hàng, chiết khấu, thanh toán).
  3. Phần mềm CRM tích hợp module đặt hàng.
• Decision Criteria (Tiêu chí quyết định): Chi phí, thời gian triển khai, khả năng mở rộng, tích hợp ERP hiện có, tính năng cần cho Nova Foods.
• Decision (Quyết định): Phát triển hệ thống e-commerce đầy đủ (lựa chọn 2) cho Nova Foods.
• Authority (Thẩm quyền): Ban Giám đốc Nova Foods, Trưởng phòng Kinh doanh, Trưởng phòng Marketing.

• Artifact (Tạo phẩm) - Minh họa Lỗi "Không đầy đủ":

  Yêu cầu ban đầu (không đầy đủ - NF-REQ-ORD-001): "Hệ thống cho phép khách hàng chọn sản phẩm và thêm vào giỏ hàng."

  • Dấu hiệu đỏ (Red Flag): Yêu cầu này thiếu nhiều chi tiết. Không định nghĩa: Khách hàng (đăng nhập/chưa)? Số lượng tối thiểu/tối đa? Sản phẩm hết hàng? Giá hiển thị? Thao tác xóa/cập nhật số lượng? Yêu cầu thiếu Tiêu chí chấp nhận (Acceptance Criteria) cụ thể.

  • Corrected Artifact (Tạo phẩm đã sửa - ví dụ): NF-REQ-ORD-001 (Đã tinh chỉnh): "Hệ thống cho phép khách hàng (đã/chưa đăng nhập) chọn một hoặc nhiều sản phẩm có sẵn, thêm vào giỏ hàng. Số lượng tối đa 999 cho mỗi sản phẩm. Nếu sản phẩm hết hàng, không cho phép thêm vào giỏ. Giá hiển thị là giá niêm yết theo danh mục sản phẩm Nova Foods. Khách hàng có thể xóa hoặc thay đổi số lượng sản phẩm trong giỏ hàng trước khi thanh toán."

    Tiêu chí chấp nhận (Acceptance Criteria) cho NF-REQ-ORD-001: * AC-1: Người dùng chưa đăng nhập thêm tối đa 10 sản phẩm vào giỏ. * AC-2: Người dùng đã đăng nhập thêm không giới hạn sản phẩm vào giỏ. * AC-3: Sản phẩm hết hàng (tồn kho = 0), nút "Thêm vào giỏ" vô hiệu hóa, thông báo "Hết hàng". * AC-4: Người dùng chỉnh sửa số lượng trong giỏ, tổng tiền cập nhật ngay. * AC-5: Người dùng xóa sản phẩm khỏi giỏ.

  Ví dụ về cách TRACEABILITY_ID_REGISTRY giúp liên kết các tạo phẩm:

  graph TD
      subgraph "Tài liệu Nguồn"
          A[NF-POL-PRC-001: Chính sách Giá & Chiết khấu Nova Foods]
          B[Luật Kế toán Việt Nam 88/2015/QH13]
      end
      subgraph "Tài liệu Yêu cầu"
          C[NF-REQ-ORD-001: Yêu cầu Đặt hàng Online]
          D[NF-BR-DISC-001: Quy tắc Chiết khấu Đơn hàng]
      end
      subgraph "Tài liệu Thiết kế"
          E[NF-DES-UI-005: Thiết kế Giao diện Giỏ hàng]
          F[NF-DES-DB-002: Thiết kế CSDL Đơn hàng]
      end
      subgraph "Tài liệu Kiểm thử"
          G[NF-TC-ORD-010: Test Case Thêm SP vào Giỏ]
          H[NF-TC-ORD-011: Test Case Chiết khấu SP]
      end
  
      A -- "Dẫn chiếu bởi" --> D
      B -- "Dẫn chiếu bởi" --> F
      C -- "Quy định" --> E
      C -- "Quy định" --> F
      D -- "Áp dụng cho" --> C
      C -- "Được kiểm thử bởi" --> G
      D -- "Được kiểm thử bởi" --> H
  
      linkStyle 0 stroke:#00a,stroke-width:2px;
      linkStyle 1 stroke:#00a,stroke-width:2px;
      linkStyle 2 stroke:#00a,stroke-width:2px;
      linkStyle 3 stroke:#00a,stroke-width:2px;
      linkStyle 4 stroke:#00a,stroke-width:2px;
      linkStyle 5 stroke:#00a,stroke-width:2px;
      linkStyle 6 stroke:#00a,stroke-width:2px;
  

  * Consequence if Wrong (Hậu quả nếu sai): Khách hàng khó dùng. Đơn hàng sai. Nhân viên sales can thiệp thủ công nhiều. Phát sinh chi phí phát triển lại. Ảnh hưởng uy tín Nova Foods.

Senior Lens

BA kinh nghiệm không chỉ sửa lỗi. Phòng ngừa lỗi. Mơ hồ, không đầy đủ, không căn cứ: BA thiếu sâu, thiếu kỷ luật. Sai ký pháp: BA thiếu kiến thức. Đứt gãy truy vết: lỗi quy trình, công cụ. BA cao cấp hiểu, sửa lỗi sớm giảm chi phí lớn. Yêu cầu càng chi tiết, càng sớm, càng ít lỗi. BA là cầu nối, không ban hành quy tắc. Quyết định nghiệp vụ, pháp lý thuộc chủ sở hữu (owner).

Quick Reference

Bảng tóm tắt lỗi, dấu hiệu, hành động sửa chữa.

Lỗi Phổ biến	Mô tả ngắn	Dấu hiệu (Red Flag)	Hành động Sửa chữa	Liên kết Artifact Chính
Mơ hồ (Ambiguity)	Thông tin nhiều cách hiểu, không rõ.	Từ ngữ chung chung ("dễ dàng", "nhanh").	Định nghĩa thuật ngữ, ví dụ, định lượng.	CANONICAL_DATA_DICTIONARY
Không đầy đủ (Incompleteness)	Thiếu thông tin triển khai/kiểm thử.	Thiếu Acceptance Criteria, điều kiện biên.	Mô hình hóa (Decision Table), checklist, thu thập đủ.	GEN-TMPL-REQ-001
Khẳng định không căn cứ (Unsupported Authority Claims)	Thông tin không nguồn xác thực.	"Tôi nghĩ...", không tham chiếu nguồn.	Ghi nhận nguồn (Business Owner, Luật).	00_SOURCE_MAP, CANONICAL_BUSINESS_RULES
Sai ký pháp (Notation Misuse)	Dùng sai cú pháp/ngữ nghĩa ký pháp.	Biểu đồ khó hiểu, không chuẩn (UML, BPMN).	Học chuẩn, tìm người review.	UML, BPMN
Đứt gãy truy vết (Traceability Breaks)	Mất liên kết giữa các tạo phẩm.	Không tìm nguồn/đích của yêu cầu.	TRACEABILITY_ID_REGISTRY, liên kết ID, dùng công cụ.	TRACEABILITY_ID_REGISTRY

11. Senior BA Notes & Rules of Thumb

Senior Lens

1. Đánh đổi (Trade-offs) AI hỗ trợ BA tăng tốc độ tạo bản nháp yêu cầu. Đổi lại, BA cấp cao cần phân tích kỹ lưỡng đánh đổi giữa tốc độ và độ chính xác, tính phù hợp ngữ cảnh Nova Foods, rủi ro thiên vị (bias) từ dữ liệu huấn luyện. Việc chấp nhận rủi ro sai sót cho yêu cầu nhanh cần được kiểm soát chặt chẽ, đặc biệt với nghiệp vụ cốt lõi hoặc dữ liệu nhạy cảm của Nova Foods. Lý do: AI học từ dữ liệu chung, có thể không phản ánh chính xác ngữ cảnh kinh doanh hoặc quy định mới của tổ chức.

2. Ngoại lệ (Exceptions) Quy trình AI hỗ trợ không áp dụng khi: * Dữ liệu cá nhân nhạy cảm cao (Highly sensitive data): Xử lý Thông tin nhận dạng cá nhân (PII - Personally Identifiable Information) của khách hàng Nova Foods, thông tin nhân sự. Rủi ro rò rỉ cao, vi phạm Luật Bảo vệ dữ liệu cá nhân. * Quy trình/chiến lược mới hoàn toàn (Novel processes/strategy): Yêu cầu chưa từng có tiền lệ, cần sự sáng tạo hoặc tương tác trực tiếp, sâu sắc với Business Owner để định hình tầm nhìn. AI không có dữ liệu huấn luyện phù hợp để tạo yêu cầu chính xác. * Vấn đề pháp lý phức tạp (Complex legal matters): Diễn giải Luật Kế toán hoặc Nghị định 123/2020/NĐ-CP về hóa đơn. Cần tham vấn trực tiếp Legal Owner hoặc Accounting Owner, không dựa vào gợi ý AI.

3. Xung đột bên liên quan (Stakeholder Conflict) AI tạo ra thông tin nhanh, có thể gây xung đột. BA cấp cao giải quyết bằng cách: * Xác minh bằng chứng (Evidence verification): Khi đầu ra AI mâu thuẫn với nhận định chuyên gia, thu thập bằng chứng từ 00_SOURCE_MAP và CANONICAL_BUSINESS_RULES. Tập trung vào nhu cầu nghiệp vụ gốc. * Làm rõ vai trò (Role clarification): Bên liên quan lo ngại AI thay thế công việc. BA nhấn mạnh AI là công cụ hỗ trợ, không thay thế phán đoán con người. * Điều hòa mong đợi (Expectation management): Giải thích rõ AI tạo bản nháp, cần xác minh, không phải chân lý cuối cùng.

4. Chất lượng bằng chứng (Evidence Quality) Đầu ra AI là gợi ý ban đầu, không phải sự thật tuyệt đối. BA cấp cao phải đánh giá chất lượng bằng chứng để đảm bảo tính xác thực: * Đối chiếu nguồn (Source Cross-Reference): So sánh yêu cầu từ AI với các nguồn tin cậy: tài liệu hiện hành, quy tắc nghiệp vụ (CANONICAL_BUSINESS_RULES), từ điển dữ liệu (CANONICAL_DATA_DICTIONARY), phỏng vấn trực tiếp chủ sở hữu nghiệp vụ. * Truy tìm gốc (Origin Tracing): AI không nêu nguồn gốc cụ thể của thông tin. BA phải tự tìm nguồn gốc xác thực cho mọi yêu cầu, đặc biệt về pháp lý, tuân thủ. * Độ đầy đủ (Completeness): AI có thể bỏ sót trường hợp biên (edge case) hoặc yêu cầu ngầm định. BA cần rà soát kỹ để đảm bảo không bỏ sót. Yêu cầu có bằng chứng từ ít nhất hai nguồn độc lập, xác thực được xem là chất lượng tốt.

5. Thẩm quyền quyết định (Decision Authority) AI hỗ trợ BA đưa ra khuyến nghị. Quyết định cuối cùng luôn thuộc về con người có thẩm quyền. BA cấp cao phải xác định rõ thẩm quyền cho từng loại quyết định:

Loại Quyết định	Thẩm quyền chính	Tài liệu tham khảo
Yêu cầu nghiệp vụ (Business requirements)	Business Owner	CANONICAL_BUSINESS_RULES
Yêu cầu pháp lý (Legal requirements)	Legal Owner	Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán
Yêu cầu kỹ thuật (Technical requirements)	IT Architect	01_CURRICULUM_ARCHITECTURE
Yêu cầu bảo mật (Security requirements)	Security Officer	OWASP ASVS
Dữ liệu/Định danh (Data/Identifier)	Data Owner / IT Architect	CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY

BA cấp cao ghi nhận rõ thẩm quyền phê duyệt trong TRACEABILITY_ID_REGISTRY và các artifact khác, đặc biệt khi có rủi ro hoặc độ không chắc chắn cao trong khuyến nghị.

Kiểm tra cấp cao: Heuristics, Dấu hiệu cảnh báo và Ngưỡng leo thang

BA cấp cao: đánh giá yêu cầu bằng kinh nghiệm. Không chỉ đúng/sai, mà tốt/tối ưu.

Heuristics (Nguyên tắc đánh giá nhanh)

BA cấp cao dùng nguyên tắc sau, đánh giá nhanh chất lượng yêu cầu.

Heuristic (Nguyên tắc)	Mô tả	Bằng chứng/Cơ sở	Áp dụng Nova Foods (mô phỏng)
Tính nhất quán (Consistency)	Yêu cầu không mâu thuẫn nội bộ hoặc với yêu cầu khác.	CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY liên kết đúng.	Lô sản phẩm có mã riêng, nhưng quy trình nhập kho gộp chung. Mâu thuẫn.
Tính hoàn chỉnh (Completeness)	Mọi kịch bản nghiệp vụ chính, thay thế, ngoại lệ được xét.	Luồng nghiệp vụ (Business Process Flow) bao quát mọi điểm dừng.	Quy trình xử lý đơn hàng thiếu bước hủy đơn khi khách hàng thay đổi. Thiếu.
Tính rõ ràng (Clarity/Unambiguity)	Yêu cầu chỉ có một cách hiểu. Loại bỏ từ ngữ mơ hồ.	Kiểm tra thuật ngữ chuyên môn định nghĩa trong CANONICAL_DATA_DICTIONARY.	"Hệ thống phải nhanh" mơ hồ; "thời gian phản hồi < 2 giây cho 95% giao dịch" rõ ràng.
Tính truy vết (Traceability)	Mỗi yêu cầu liên kết rõ ràng đến nguồn gốc nghiệp vụ hoặc pháp lý.	Liên kết đến stakeholder, CANONICAL_BUSINESS_RULES, Luật Kế toán (Việt Nam).	Yêu cầu lưu trữ hóa đơn điện tử không ghi rõ dựa Nghị định 123/2020/NĐ-CP.
Tính tuân thủ (Compliance)	Yêu cầu đáp ứng luật, quy định, chính sách doanh nghiệp.	Kiểm tra với Luật Bảo vệ dữ liệu cá nhân, Luật An toàn thực phẩm (Nova Foods).	Quy trình đăng ký khách hàng mới thu thập quá nhiều thông tin cá nhân không cần.
Khả thi (Feasibility)	Yêu cầu có thể triển khai với nguồn lực, công nghệ hiện có.	Đánh giá sơ bộ với kiến trúc sư giải pháp.	Yêu cầu phân tích dữ liệu kho lạnh theo thời gian thực, nhưng hệ thống không có sensor.

Dấu hiệu cảnh báo (Red Flags)

Phát hiện dấu hiệu này, BA cấp cao dừng, đánh giá kỹ.

Dấu hiệu cảnh báo	Mô tả	Rủi ro tiềm ẩn
Yêu cầu chỉ qua lời nói	Không có tài liệu, văn bản hóa.	Hiểu sai, quên, không truy vết được nguồn gốc.
Xung đột stakeholder chưa giải quyết	Các bên liên quan có yêu cầu mâu thuẫn, không thỏa hiệp.	Dự án đình trệ, lãng phí tài nguyên, giải pháp không chấp nhận.
Phạm vi thay đổi không kiểm soát	Yêu cầu mới liên tục xuất hiện, không qua quy trình thay đổi.	Vượt ngân sách, trễ thời hạn, chất lượng giảm sút.
Thiếu bằng chứng, dữ liệu nguồn	Yêu cầu dựa trên giả định, không có dữ liệu nghiệp vụ chứng minh.	Giải pháp không phù hợp, không giải quyết vấn đề thật.
Ước tính nỗ lực không thực tế	Đội phát triển ước tính quá thấp hoặc quá cao.	Kế hoạch dự án sai lệch, không hoàn thành đúng hạn.
Không có tiêu chí chấp nhận rõ ràng	Không xác định khi nào yêu cầu được coi là hoàn thành.	Không biết khi nào sản phẩm sẵn sàng, chất lượng không đảm bảo.

Ngưỡng leo thang (Escalation Thresholds)

Khi gặp tình huống sau, BA cấp cao phải leo thang (escalate) lên quản lý dự án, stakeholder chủ chốt hoặc các bên thẩm quyền.

Điều kiện leo thang	Ví dụ Nova Foods (mô phỏng)	Vai trò/Thẩm quyền cần leo thang
Rủi ro pháp lý/Tuân thủ	Quy trình giao nhận hàng không ghi nhận đầy đủ thông tin truy xuất nguồn gốc theo Luật An toàn thực phẩm.	Ban Pháp chế (Legal Department), Ban Quản lý Chất lượng (Quality Management).
Thay đổi phạm vi lớn	Yêu cầu thêm tích hợp hệ thống POS mới vào ERP hiện có, tăng 25% công sức.	Giám đốc Dự án (Project Manager), Giám đốc Nghiệp vụ (Business Owner).
Xung đột stakeholder không giải quyết	Trưởng phòng Kế toán và Trưởng phòng Sales không thống nhất quy trình phê duyệt chiết khấu.	Giám đốc Nghiệp vụ, Giám đốc Điều hành (CEO).
Ảnh hưởng ngân sách/Thời gian lớn	Một tính năng cần thiết kéo dài thời gian dự án thêm 3 tháng, tăng chi phí 20%.	Giám đốc Dự án, Ban Giám đốc (Steering Committee).
Rủi ro bảo mật dữ liệu	Xử lý thông tin nhạy cảm khách hàng (VD: địa chỉ, số điện thoại) không có mã hóa, không theo Luật Bảo vệ dữ liệu cá nhân.	Trưởng phòng An ninh thông tin (CISO), Ban Pháp chế.
Vấn đề kiến trúc kỹ thuật nghiêm trọng	Giải pháp nghiệp vụ đòi hỏi thay đổi lớn hạ tầng cơ bản, không tương thích.	Kiến trúc sư trưởng (Chief Architect), Giám đốc Công nghệ (CTO).

Ngoại lệ quy tắc thông thường (Exceptions to Normal Rules)

Một số tình huống, quy tắc BA thông thường (tài liệu chi tiết, quy trình phê duyệt nhiều bước) có thể được giảm bớt hoặc thay đổi.

Trường hợp ngoại lệ	Thay đổi quy tắc BA thông thường	Lý do
Sửa lỗi khẩn cấp (Emergency Fix)	Tập trung vào giải pháp nhanh, tài liệu tối thiểu, phê duyệt nhanh.	Ngăn chặn ngừng hoạt động sản xuất, mất doanh thu Nova Foods.
Yêu cầu pháp lý cấp bách	Ưu tiên tuân thủ, quy trình rút gọn, bỏ qua tối đa bước không bắt buộc.	Đáp ứng thời hạn pháp luật (Luật 91/2025/QH15 về Bảo vệ dữ liệu cá nhân) để tránh phạt.
POC (Proof of Concept) / Thử nghiệm	Tài liệu linh hoạt, không yêu cầu độ hoàn chỉnh cao, không cần phê duyệt production.	Khám phá ý tưởng, công nghệ mới; không cam kết nguồn lực dài hạn cho Nova Foods.
Thay đổi nhỏ, cô lập, rủi ro thấp	Áp dụng quy trình thay đổi nhẹ (lightweight change management), phê duyệt bởi 1-2 stakeholder chính.	Giảm chi phí quản lý cho thay đổi có tác động rất nhỏ.

Senior Lens

BA cấp cao không chỉ tập hợp yêu cầu; họ quản lý sự không chắc chắn (uncertainty), phân tích dữ liệu không hoàn chỉnh, và đưa ra khuyến nghị có căn cứ (defensible recommendation) cho Nova Foods. Điều cốt lõi là phải truyền đạt rõ ràng những gì đã biết, những gì cần làm rõ, và rủi ro liên quan, mà không tạo ra sự chắc chắn giả tạo (fabricating certainty).

Quản lý và Truyền đạt Sự Không Chắc Chắn (Managing and Communicating Uncertainty)

BA cấp cao phân loại sự không chắc chắn để chọn cách truyền đạt phù hợp, đảm bảo người ra quyết định hiểu rõ cơ sở thông tin.

Mức độ Chắc chắn (Certainty Level)	Bằng chứng / Nguồn (Evidence / Source)	Cách diễn đạt khuyến nghị (Recommendation Expression)	Rủi ro nếu sai (Risk if Wrong)
Cao (High)	Dữ liệu định lượng đầy đủ, tài liệu pháp lý (ví dụ: Luật Kế toán 88/2015/QH13), đã được các bên liên quan chính (Business Owner, Legal) xác nhận.	"Yêu cầu này được xác nhận bởi [Nguồn] và phù hợp với [Quy tắc]."	Thấp; sai sót do diễn giải hoặc thay đổi quy định.
Trung bình (Medium)	Dữ liệu định tính từ phỏng vấn key stakeholder, quy trình hiện hành (AS-IS), một phần dữ liệu định lượng, chưa có sự đồng thuận tuyệt đối.	"Khuyến nghị này dựa trên hiểu biết hiện tại từ [Nguồn], cần xác minh thêm từ [Vai trò/Dữ liệu] để giảm rủi ro [Rủi ro cụ thể]."	Trung bình; sai lệch yêu cầu, bỏ lỡ ngoại lệ, ảnh hưởng hiệu suất Nova Foods.
Thấp (Low)	Giả định ban đầu (initial assumption), nhu cầu chưa phân tích sâu, bằng chứng mơ hồ, thông tin chưa xác minh.	"Đây là một giả định ban đầu dựa trên [Thông tin ban đầu], yêu cầu phân tích/xác minh chuyên sâu để đánh giá tính khả thi và tác động."	Cao; phát triển sai chức năng, lãng phí tài nguyên, không đáp ứng nhu cầu thực Nova Foods.
Không biết (Unknown)	Chưa có bất kỳ thông tin nào về một khía cạnh quan trọng.	"Chúng tôi chưa có thông tin về [Chủ đề] và cần [Hành động tiếp theo] để làm rõ."	Rất cao; blind spot, bỏ qua yêu cầu quan trọng, rủi ro vận hành lớn cho Nova Foods.

Ghi nhận Khuyến nghị có Căn cứ (Recording Defensible Recommendations)

Để đưa ra một khuyến nghị có thể bảo vệ được (defensible recommendation) mà không giả tạo sự chắc chắn, BA cấp cao cần tuân thủ cấu trúc minh bạch sau:

1. Bối cảnh & Vấn đề (Context & Problem):

   • Mô tả rõ ràng tình hình hiện tại (current state) và vấn đề mà Nova Foods đang đối mặt. Điều này bao gồm bằng chứng về vấn đề (ví dụ: dữ liệu lỗi, báo cáo không chính xác).
   • Ví dụ: Nova Foods ghi nhận sai lệch 15-20% giữa tồn kho vật lý và hệ thống ERP cho mặt hàng nguyên liệu NF-ING-001 hàng tháng, dẫn đến gián đoạn sản xuất và báo cáo tài chính không chính xác.

2. Các Tùy chọn Khả thi (Viable Options):

   • Trình bày ít nhất hai đến ba giải pháp tiềm năng, bao gồm cả lựa chọn "không làm gì" (do nothing option) nếu nó thực sự là một lựa chọn.
   • Ví dụ: A) Tích hợp tự động hệ thống ERP với Hệ thống quản lý kho (WMS); B) Triển khai quy trình đối chiếu tồn kho thủ công hàng ngày; C) Duy trì quy trình hiện tại và chấp nhận sai lệch.

3. Tiêu chí Quyết định (Decision Criteria):

   • Nêu rõ các yếu tố khách quan sẽ được sử dụng để đánh giá các tùy chọn (ví dụ: Chi phí triển khai, thời gian thực hiện, mức độ giảm thiểu sai lệch, tuân thủ Nghị định 123/2020/NĐ-CP về hóa đơn điện tử, rủi ro nghiệp vụ).

4. Phân tích & Căn cứ (Analysis & Reasoning Bridge):

   • Đánh giá từng tùy chọn dựa trên tiêu chí đã nêu.
   • Trình bày bằng chứng (evidence), dữ liệu (data), và các giả định (assumptions) hỗ trợ cho đánh giá.
   • Thừa nhận rõ ràng những điểm yếu, thách thức hoặc rủi ro của từng tùy chọn.
   • Ví dụ: Tùy chọn A (Tích hợp ERP-WMS) có chi phí ban đầu cao (~500M VND) nhưng có tiềm năng giảm sai lệch tồn kho xuống dưới 1% và tự động hóa báo cáo. Giả định: API WMS hiện tại của Nova Foods đủ mạnh và ổn định. Rủi ro: Thời gian triển khai có thể kéo dài nếu có độ phức tạp bất ngờ trong việc ánh xạ dữ liệu.

5. Khuyến nghị (Recommendation):

   • Đề xuất giải pháp được cho là tốt nhất dựa trên phân tích.
   • Sử dụng ngôn ngữ cân nhắc, không tuyệt đối hóa. Ví dụ: "Chúng tôi khuyến nghị, dựa trên thông tin hiện có, [Tùy chọn X] vì [lý do chính]."
   • Ví dụ: "Dựa trên phân tích chi phí-lợi ích và mục tiêu dài hạn của Nova Foods về độ chính xác dữ liệu và hiệu quả vận hành, chúng tôi khuyến nghị ưu tiên Tùy chọn A (Tích hợp tự động ERP-WMS) trong giai đoạn tiếp theo."

6. Rủi ro & Sự Không Chắc chắn Còn Lại (Remaining Risks & Uncertainty):

   • Liệt kê rõ ràng các rủi ro và các điểm không chắc chắn vẫn tồn tại sau khi khuyến nghị được thực hiện, kèm theo mức độ tác động tiềm ẩn.
   • Ví dụ: Rủi ro còn lại: Sự phụ thuộc vào nhà cung cấp WMS bên thứ ba. Không chắc chắn: Khả năng hệ thống WMS hiện tại có thể xử lý tải dữ liệu tăng lên trong tương lai mà không cần nâng cấp đáng kể.

7. Bước tiếp theo & Thẩm quyền Quyết định (Next Steps & Decision Authority):

   • Đề xuất các hành động cụ thể để giảm thiểu rủi ro hoặc làm rõ sự không chắc chắn (ví dụ: thực hiện Proof of Concept - PoC, tổ chức workshop sâu hơn với nhà cung cấp, thu thập dữ liệu bổ sung).
   • Xác định rõ vai trò hoặc nhóm người có thẩm quyền ra quyết định cuối cùng cho khuyến nghị này.
   • Ví dụ: "Cần sự phê duyệt từ Trưởng phòng Vận hành và Giám đốc Tài chính Nova Foods để cấp ngân sách cho giai đoạn PoC của giải pháp tích hợp. Kết quả PoC sẽ là cơ sở cho quyết định triển khai chính thức."

BA cấp cao không tạo ra sự chắc chắn khi nó không tồn tại. Thay vào đó, họ cung cấp cái nhìn rõ ràng về trạng thái thông tin, các lựa chọn khả thi, và con đường tốt nhất để tiến lên dựa trên dữ liệu hiện có, luôn đi kèm với sự minh bạch về rủi ro và các bước cần thiết để làm rõ cho Nova Foods.

12. Associated Template Reference & Completed Artifact

Quick Reference

Bảng này liệt kê mẫu và tài liệu liên quan đến luồng công việc BA được hỗ trợ bởi AI. Mỗi mục nêu mục đích, giới hạn, owner, consumer và cổng chất lượng kiểm tra trước khi nội dung được dùng làm đầu vào nghiệp vụ.

Mã Template	Tên tệp	Khi dùng	Khi không dùng	Owner	Consumer	Quality Gate
GEN-TMPL-AI-001	03-templates/ai-assisted-ba/ai-prompt-engineering-template.md	BA tạo prompt cho công cụ AI để phân tích nguồn, tổng hợp thông tin, soạn nháp yêu cầu hoặc user story. Prompt phải nêu nguồn đầu vào, mục tiêu, giới hạn dữ liệu, định dạng đầu ra và yêu cầu gắn nhãn nội dung cần xác minh.	Không dùng prompt để tạo quyết định nghiệp vụ cuối cùng, thay thế xác nhận stakeholder hoặc đưa dữ liệu nhạy cảm vào AI công cộng.	Principal IT Business Analyst	BA, Team Leader	BA tự kiểm tra prompt về mục tiêu, dữ liệu đầu vào và giới hạn. Đồng nghiệp kiểm tra prompt tác động phạm vi, dữ liệu hoặc quyết định quan trọng.
GEN-TMPL-AI-002	03-templates/ai-assisted-ba/ai-output-validation-checklist.md	BA kiểm tra nội dung AI tạo sau mỗi lần nhận nháp yêu cầu, user story hoặc tài liệu phân tích. Checklist đối chiếu đầu ra với nguồn, phân biệt fact, giả định, đề xuất và nội dung chưa xác minh.	Không thay thế thẩm định chuyên môn của SME hoặc Business Owner. Không dùng checklist để tuyên bố AI output đã được phê duyệt.	Principal IT Business Analyst	BA, SME	BA hoàn thành checklist và ghi kết quả xác minh. SME hoặc Business Owner xác nhận nội dung nghiệp vụ thuộc thẩm quyền của họ.
GEN-TMPL-AI-003	03-templates/ai-assisted-ba/ai-ethics-compliance-review-log.md	BA ghi nhận rủi ro đạo đức, tuân thủ và bảo mật khi AI xử lý dữ liệu hoặc tạo nội dung nhạy cảm; gồm rủi ro liên quan Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và sai lệch dữ liệu.	Không dùng log để bỏ qua quy định pháp lý, chính sách bảo mật dữ liệu nội bộ hoặc quyết định của Legal/Compliance và Security. Nova Foods là môi trường mô phỏng.	Principal IT Business Analyst	BA, Legal/Compliance, Security	Legal/Compliance hoặc Security kiểm tra khi BA ghi nhận rủi ro cao, dữ liệu nhạy cảm hoặc khả năng vi phạm chính sách.
GEN-TMPL-AI-004	03-templates/ai-assisted-ba/ai-elicitation-log.md	BA ghi tương tác, nguồn đầu vào, phân tích AI hỗ trợ, thay đổi, giả định và quyết định trong quá trình thu thập yêu cầu. Log phục vụ truy vết nguồn gốc và kiểm tra thay đổi.	Không thay thế biên bản họp chính thức, xác nhận stakeholder hoặc quyết định nghiệp vụ đã được phê duyệt.	Business Analyst	BA, Project Manager, Stakeholders (chỉ xem)	BA kiểm tra tính đầy đủ của nguồn, ngày ghi nhận, phân loại nội dung và liên kết artifact. Stakeholder kiểm tra khi cần truy vết yêu cầu hoặc làm rõ nguồn gốc.

Tra cứu Chapter và Vị trí Artifact Mô phỏng Nova Foods

BA sử dụng CHAPTER_MANIFEST.md làm nguồn tra cứu chính để tìm chapter, dependency, owner, output và trạng thái quản trị. Manifest chỉ hỗ trợ định vị và đánh giá trạng thái; không thay thế thẩm quyền phê duyệt của owner từng artifact.

Tiêu chí Tra cứu	Mục đích	Cách sử dụng trong CHAPTER_MANIFEST.md
Chủ đề cụ thể	Tìm chapter giải quyết vấn đề, khái niệm hoặc quy trình.	Xem cột Tiêu đề chapter và Phạm vi chapter. Ví dụ: tìm "Requirements Elicitation" hoặc "Data Modeling".
Đầu vào cần thiết	Xác định chapter cung cấp thông tin, artifact hoặc kiến thức nền cho hoạt động BA.	Xem cột Dependency đầu vào chính để nhận diện chapter cần hoàn thành trước hoặc cần tham chiếu.
Kết quả mong đợi	Tìm chapter tạo output hoặc artifact cụ thể.	Xem cột Outcome / output chính và Loại artifact chính. Ví dụ: tìm chapter tạo "User Story" hoặc "Process Flow Diagram".
Vai trò liên quan	Xác định owner nội dung và người tiêu thụ output.	Xem cột Owner nội dung và tham chiếu mục Who consumes those outputs? trong chapter tương ứng.
Trạng thái & Phiên bản	Kiểm tra độ ổn định và tính cập nhật của chapter.	Xem cột Trạng thái và Phiên bản. IN_REVIEW nghĩa nội dung còn đang xem xét; BASELINED hoặc APPROVED mới là trạng thái ổn định theo manifest.

Vị trí Artifact Mô phỏng Nova Foods đã hoàn chỉnh:

Artifact mô phỏng minh họa quy trình BA có hỗ trợ AI trong chapter này được lưu tại:

• Đường dẫn: /03-templates/nova-foods/25-nova-foods-ai-assisted-user-story-summary-v0.9.0.md
• Mục đích: Tổng hợp user story cho phân hệ quản lý kho Nova Foods. Artifact ghi yêu cầu chức năng và phi chức năng sơ bộ, nguồn đầu vào phi cấu trúc, phần AI hỗ trợ soạn nháp và nội dung cần stakeholder xác minh. BA dùng artifact để minh họa cách chuyển đầu vào thành yêu cầu có thể kiểm tra, không dùng artifact làm quyết định nghiệp vụ cuối cùng.
• Trạng thái: IN_REVIEW, v0.9.0.
• Owner: Principal IT Business Analyst / Technical Curriculum Author chịu trách nhiệm nội dung chính. Nova Foods Warehouse Business Owner chịu trách nhiệm xác nhận nội dung nghiệp vụ thuộc phạm vi kho.
• Consumer: BA dùng làm ví dụ học tập; Warehouse Business Owner, Technical Architect và Project Manager dùng để kiểm tra phạm vi, truy vết và tính khả thi trước khi quyết định dùng nội dung cho mục đích tiếp theo.
• Nguồn và ranh giới: Artifact dùng dữ liệu tổng hợp trong bối cảnh Nova Foods mô phỏng. Artifact không đại diện yêu cầu nghiệp vụ thực tế, cấu hình ERP hoặc xác nhận vận hành của Nova Foods.
• Trade-off: AI tăng tốc tổng hợp và tạo nháp nhưng có thể diễn giải sai nguồn, bỏ sót ngoại lệ hoặc tạo nội dung không có căn cứ. BA phải giữ liên kết nguồn, đánh dấu giả định và gửi nội dung nghiệp vụ cho owner có thẩm quyền xác minh.
• Hậu quả nếu dùng sai: Dùng artifact IN_REVIEW như yêu cầu đã phê duyệt có thể tạo sai phạm vi, sai thiết kế, đứt truy vết hoặc quyết định dựa trên nội dung chưa được xác nhận.

Kiểm Tra Chéo và Xác Minh Trước Bàn Giao

Trước khi bàn giao chapter 25-ai-assisted-ba-workflow.md, Principal IT Business Analyst / Technical Curriculum Author kiểm tra chéo để bảo đảm chapter khớp curriculum, template, registry và artifact mô phỏng. Kiểm tra này xác định rủi ro và chủ sở hữu xử lý; không chuyển chapter hoặc artifact sang BASELINED hay APPROVED.

Vấn Đề Mở (Open Issues)

ID Vấn Đề	Mô Tả Vấn Đề	Mối Quan Tâm & Ảnh Hưởng	Chủ Sở Hữu Escalation	Trạng Thái
25-12-ISS-001	Tính nhất quán của các bước quy trình BA có hỗ trợ AI với 01_CURRICULUM_ARCHITECTURE.md.	Quy trình trong chapter có thể mâu thuẫn với cấu trúc chương trình học hoặc mục tiêu học liệu. Mâu thuẫn có thể làm người học áp dụng sai thứ tự hoạt động hoặc dùng sai artifact.	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW
25-12-ISS-002	Mọi tham chiếu ID hoặc định danh mới trong chapter phải được đăng ký trong TRACEABILITY_ID_REGISTRY.md.	Thiếu đăng ký ID có thể phá vỡ truy vết, gây nhầm lẫn giữa artifact và làm consumer không xác định được nguồn hoặc trạng thái nội dung.	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW

Điểm Cần Xác Minh (Verification-Required Items)

ID Xác Minh	Mô Tả Điểm Cần Xác Minh	Nguồn Cần Xác Minh	Chủ Sở Hữu Xác Minh	Trạng Thái
25-12-VRF-001	User story summary tại /03-templates/nova-foods/25-nova-foods-ai-assisted-user-story-summary-v0.9.0.md: kiểm tra quy tắc nghiệp vụ, thuật ngữ dữ liệu, giả định, acceptance criteria và phân định nội dung AI tạo nháp với nội dung đã xác minh.	CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md, quy tắc nghiệp vụ mô phỏng Nova Foods.	Business Owner (mô phỏng), Technical Architect (mô phỏng)	PENDING_VERIFICATION
25-12-VRF-002	Hướng dẫn sử dụng GEN-TMPL-AI-001 đến GEN-TMPL-AI-004, gồm owner, consumer, điều kiện dùng, giới hạn và quality gate.	TEMPLATE_MANIFEST.md, yêu cầu chất lượng tổng thể của curriculum.	Principal IT Business Analyst / Technical Curriculum Author	PENDING_VERIFICATION
25-12-VRF-003	Mọi diễn giải pháp lý hoặc tuân thủ được nêu trong chapter, gồm nội dung liên quan bảo vệ dữ liệu, hóa đơn hoặc AI. Việc xác minh xác định nguồn, phạm vi áp dụng và giới hạn của diễn giải; không suy diễn nghĩa vụ pháp lý mới.	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP (mô phỏng) hoặc nguồn pháp lý tương đương.	Legal Owner (mô phỏng)	PENDING_VERIFICATION
25-12-VRF-004	Các khẳng định về hiệu suất hoặc tối ưu hóa của quy trình BA có AI đối với nghiệp vụ Nova Foods. Việc xác minh đối chiếu khẳng định với dữ liệu mô phỏng và xác định điều kiện áp dụng, trade-off và giới hạn.	Phân tích nghiệp vụ mô phỏng Nova Foods, mô hình tối ưu hóa nghiệp vụ.	Business Owner (mô phỏng)	PENDING_VERIFICATION

Khi owner xử lý từng vấn đề mở và ghi kết quả xác minh cho từng ID, Principal IT Business Analyst / Technical Curriculum Author đánh giá lại tính nhất quán của chapter. Trạng thái hiện tại của chapter và artifact vẫn là IN_REVIEW; không có xác nhận phê duyệt trong section này.