Bỏ qua

/03-templates/TMPL-PROC-001-process-analysis.md — Template: Phân tích Quy trình

Bảng metadata dưới đây là nguồn kiểm soát định danh, phiên bản và quy tắc sử dụng của template này. Mọi thay đổi đối với template phải được ghi nhận trong Lịch sử thay đổi. Việc sử dụng template này để tạo ra một artifact phân tích quy trình mới cho case study Nova Foods phải tuân thủ các ranh giới được định nghĩa ở đây.

Trường kiểm soát Giá trị Diễn giải và quy tắc áp dụng
Artifact ID TMPL-PROC-001 Định danh duy nhất, không thay đổi của template này trong toàn bộ corpus. Khi tham chiếu từ artifact khác, phải dùng chính xác ID này để đảm bảo traceability (khả năng truy vết).
Tên tệp được kiểm soát /03-templates/TMPL-PROC-001-process-analysis.md Đường dẫn canonical (chính tắc) của tệp nguồn. Các bản sao hoặc tệp được tạo ra từ template này phải ghi nhận nguồn gốc từ đây.
Tiêu đề Template: Process Analysis (Mẫu: Phân tích Quy trình) Tên chính thức của template, được sử dụng trong các manifest và tài liệu tham chiếu.
Trạng thái IN_REVIEW Template đang ở trạng thái xem xét có kiểm soát. Trạng thái này không có nghĩa là APPROVED (đã phê duyệt) hay BASELINED (đã chốt phiên bản).
Phiên bản v0.9.0 Phiên bản hiện hành của cấu trúc template tại ngày cập nhật gần nhất.
Owner Principal IT Business Analyst / Technical Curriculum Author Vai trò chịu trách nhiệm duy trì cấu trúc, metadata và tính toàn vẹn của template này.
Trách nhiệm của Owner Owner chịu trách nhiệm quản lý phiên bản, ghi nhận lịch sử thay đổi, và bảo đảm cấu trúc template nhất quán với curriculum architecture.
Giới hạn thẩm quyền của Owner Owner không có quyền phê duyệt nội dung phân tích quy trình được người dùng điền vào, không xác nhận tính đúng đắn của quy trình nghiệp vụ, không diễn giải pháp lý hay kế toán, và không cho phép triển khai production.
Ngày cập nhật gần nhất 2026-08-07 Ngày cập nhật gần nhất của cấu trúc template, được ghi nhận theo múi giờ Asia/Ho_Chi_Minh.
Lịch sử thay đổi v0.9.0 (2026-08-07): Khởi tạo template với cấu trúc 4 tầng, hoàn thiện metadata quản trị (Tier 1) và đưa vào trạng thái IN_REVIEW. Lịch sử này chỉ ghi lại thay đổi trên cấu trúc của template, không phải nội dung do người dùng điền vào.
Ranh giới dữ liệu Chỉ sử dụng dữ liệu tổng hợp, mô phỏng cho case study Nova Foods. Cảnh báo: Nghiêm cấm sử dụng dữ liệu cá nhân thật, dữ liệu tài chính thật, hoặc thông tin vận hành nội bộ của bất kỳ tổ chức nào khi điền vào template này. Mọi dữ liệu phải là hư cấu cho mục đích giáo dục.

1. Tier 1 – Metadata, Purpose, and Governance

Mục đích, Ranh giới và Quản trị Sử dụng

Tài liệu này xác định mục đích, phạm vi, và các quy tắc quản trị khi sử dụng mẫu phân tích quy trình TMPL-PROC-001. Việc tuân thủ các quy tắc này là bắt buộc để đảm bảo tính nhất quán và duy trì nguồn chân lý (single source of truth) trong toàn bộ vòng đời dự án tại Nova Foods.

Mục đích chính của mẫu này là để chuẩn hóa việc ghi nhận kết quả của hoạt động Phân tích Quy trình (Process Analysis), một kỹ thuật cốt lõi trong phân tích nghiệp vụ. Nó cung cấp một cấu trúc thống nhất để mô tả một quy trình nghiệp vụ từ đầu đến cuối, bao gồm các bước thực hiện, vai trò tham gia, các điểm quyết định, dữ liệu đầu vào/đầu ra, và các quy tắc nghiệp vụ liên quan. Việc sử dụng mẫu giúp đảm bảo tất cả các bên liên quan (stakeholders) — từ chủ sở hữu nghiệp vụ đến đội ngũ phát triển và kiểm thử — có chung một cách hiểu, giảm thiểu rủi ro do diễn giải sai và phải làm lại.

Bảng 1: Quy tắc và Phạm vi Sử dụng

Hạng mục Quy định
Khi nào sử dụng
  • Để phân tích và ghi nhận quy trình hiện tại (gọi là quy trình As-Is) nhằm xác định các điểm yếu và cơ hội cải tiến.
  • Để thiết kế và mô tả chi tiết một quy trình tương lai (gọi là quy trình To-Be) sẽ được hỗ trợ bởi hệ thống ERP hoặc phần mềm mới.
  • Làm tài liệu nguồn để tạo các đặc tả yêu cầu chức năng, user story, hoặc ca kiểm thử.
  • Ví dụ: Phân tích quy trình "Mua hàng và Nhận hàng" (Procure-to-Receive) của Nova Foods để cấu hình cho phân hệ Quản lý Mua hàng (Purchasing Module) trong ERP.
Khi nào KHÔNG sử dụng
  • Không dùng để viết Hiến chương Dự án (Project Charter) hoặc Báo cáo Nghiệp vụ (Business Case). Đây là các tài liệu ở giai đoạn khởi tạo dự án và có mẫu riêng.
  • Không dùng để định nghĩa chi tiết Từ điển Dữ liệu (Data Dictionary). Hãy tham chiếu đến artifact CANONICAL_DATA_DICTIONARY.
  • Không dùng để đặc tả kỹ thuật của API. Hãy sử dụng mẫu dựa trên OpenAPI Specification.
  • Không dùng để viết Kế hoạch Kiểm thử (Test Plan) tổng thể hoặc báo cáo kết quả kiểm thử.

Bảng 2: Quản trị, Vai trò và Trách nhiệm

Hạng mục Giá trị/Diễn giải
Owner của Mẫu Principal IT Business Analyst / Technical Curriculum Author. Chịu trách nhiệm duy trì cấu trúc và hướng dẫn của mẫu này.
Owner của Nội dung Business Analyst được phân công cho dự án. Chịu trách nhiệm điền đầy đủ và chính xác nội dung phân tích quy trình vào một bản sao của mẫu.
Người tiêu thụ (Consumers)
  • Business Owner: Xem xét và phê duyệt tính đúng đắn của quy trình và các quy tắc nghiệp vụ.
  • Development Team: Dựa vào mô tả quy trình để xây dựng phần mềm.
  • QA Team: Dựa vào các bước, điều kiện, và quy tắc để thiết kế ca kiểm thử (test cases).
  • Solution Architect: Đảm bảo quy trình được thiết kế phù hợp với kiến trúc hệ thống tổng thể.
Đầu vào Tiên quyết (Prerequisites)
  • Một yêu cầu nghiệp vụ hoặc một vấn đề đã được định nghĩa rõ ràng.
  • Kết quả phỏng vấn các bên liên quan đã được ghi nhận.
  • Tham chiếu đến các quy tắc nghiệp vụ đã tồn tại trong CANONICAL_BUSINESS_RULES.
Tài liệu Đầu ra (Downstream Artifacts)
  • Đặc tả Yêu cầu Chức năng (TMPL-FR-001-functional-requirements.md).
  • Các User Story và Acceptance Criteria trong backlog của dự án.
  • Sơ đồ quy trình nghiệp vụ vẽ bằng BPMN.
  • Các ca kiểm thử trong bộ tài liệu kiểm thử.

Bảng 3: Thẩm quyền Quyết định và Leo thang (Authority & Escalation)

Loại Quyết định/Nội dung Người có Thẩm quyền Phê duyệt Khi nào cần Leo thang (Escalate)
Quy tắc nghiệp vụ (Business Rule) Business Owner / Process Owner Leo thang đến Legal Owner hoặc Accounting Owner nếu quy tắc liên quan đến pháp lý hoặc kế toán. Leo thang đến Architect nếu quy tắc mâu thuẫn với khả năng kỹ thuật.
Phạm vi của quy trình (In/Out of Scope) Business Owner và Project Manager Leo thang khi một thay đổi về phạm vi có nguy cơ ảnh hưởng lớn đến ngân sách, tiến độ, hoặc mâu thuẫn với mục tiêu dự án đã được phê duyệt.
Thiết kế giải pháp kỹ thuật Solution Architect / Technical Lead Leo thang khi giải pháp kỹ thuật được đề xuất không đáp ứng được yêu cầu nghiệp vụ cốt lõi hoặc tạo ra rủi ro vận hành. BA có trách nhiệm báo cáo sự không phù hợp này.
Diễn giải luật/nghị định Legal Owner / Compliance Owner Luôn luôn leo thang. Business Analyst chỉ được phép trích dẫn, không được tự diễn giải các yêu cầu pháp lý, thuế, hoặc kế toán. Mọi diễn giải phải đến từ người có thẩm quyền.

Định danh, Liên kết và Nghĩa vụ Kiểm soát

Template này là một artifact được kiểm soát trong hệ thống tài liệu của corpus Nova Foods. Việc duy trì định danh và liên kết của nó là bắt buộc để đảm bảo tính toàn vẹn và khả năng truy vết (traceability) của toàn bộ curriculum.

Bảng 4: Định danh và Liên kết Quản trị

Mỗi template phải được đăng ký và quản trị thông qua manifest tương ứng. Điều này đảm bảo rằng không có template "mồ côi" hoặc xung đột định danh nào tồn tại trong corpus.

Trường Quản trị Giá trị Canonical Diễn giải và Trách nhiệm
Định danh Artifact TMPL-PROC-001 Định danh duy nhất, không thay đổi của template này. Mọi tham chiếu nội bộ trong corpus phải sử dụng ID này để liên kết.
Tên tệp được kiểm soát /03-templates/TMPL-PROC-001-process-analysis.md Đường dẫn canonical. Không được đổi tên hoặc di chuyển tệp mà không cập nhật manifest và các artifact phụ thuộc.
Manifest Quản trị TEMPLATE_MANIFEST Template này được quản trị bởi /01-curriculum/TEMPLATE_MANIFEST.md. Mọi thay đổi về trạng thái, phiên bản, hoặc sự tồn tại của template phải được ghi nhận tại manifest đó.
Registry Định danh TRACEABILITY_ID_REGISTRY Mọi định danh mới được tạo ra trong ví dụ ở Tier 3 (ví dụ: PROC-ANALYSIS-<PROCESS_ID>, RULE-<NNN>) phải tuân thủ quy tắc và được đăng ký tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Nghĩa vụ Liên kết Nguồn

Nội dung của template này không được tạo ra một cách tùy tiện. Nó phải bắt nguồn từ các tiêu chuẩn ngành, quy định pháp lý, và các artifact canonical trong corpus để đảm bảo tính nhất quán và đúng đắn.

  • Nguồn Kiến thức Chuyên môn: Cấu trúc và các đề mục của template được xây dựng dựa trên các khu vực kiến thức (Knowledge Areas) từ BABOK Guide v3 (ví dụ: Requirements Analysis and Design Definition) và tiêu chuẩn ISO/IEC/IEEE 29148 về Requirements Engineering.
  • Nguồn Sơ đồ hóa: Khi template yêu cầu vẽ sơ đồ quy trình, ký pháp BPMN 2.0.2 là tiêu chuẩn bắt buộc.
  • Nguồn Quy tắc và Dữ liệu: Mọi quy tắc nghiệp vụ (business rule) và định nghĩa dữ liệu (data definition) sử dụng trong ví dụ ở Tier 3 phải tham chiếu đến nguồn chân lý (single source of truth) là /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
  • Nguồn Pháp lý và Tuân thủ: Mọi tham chiếu đến luật (ví dụ: Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP) phải được lấy từ bản đồ nguồn tại /00-research/00_SOURCE_MAP.md và phải giữ nguyên nhãn "Cần xác minh bởi Legal Owner" (Verification required by Legal Owner).

Nghĩa vụ Kiểm soát Thay đổi (Change Control Obligations)

Mọi thay đổi đối với template này đều phải tuân thủ quy trình kiểm soát phiên bản nghiêm ngặt.

  1. Thay đổi Tier 1 & 2 (Metadata và Cấu trúc Template): Bất kỳ chỉnh sửa nào đối với phần metadata, mục đích, hoặc cấu trúc trống của template (Tier 1 và 2) đều cấu thành một phiên bản mới. Owner phải cập nhật số phiên bản và bảng lịch sử thay đổi (Change History). Thay đổi này cũng yêu cầu đánh giá tác động lên các handbook chapter liên quan được liệt kê trong /01-curriculum/CHAPTER_MANIFEST.md.
  2. Thay đổi Tier 3 (Nội dung Ví dụ Nova Foods): Việc cập nhật ví dụ mô phỏng phải đảm bảo không phá vỡ traceability. Mọi dữ liệu phải là dữ liệu tổng hợp và mọi quy tắc phải nhất quán với các catalog canonical của corpus.
  3. Không có thay đổi thầm lặng: Mọi thay đổi phải được ghi nhận. Sửa đổi nội dung mà không cập nhật phiên bản và lịch sử thay đổi là một vi phạm quy trình quản trị.

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

Phần này cung cấp một mẫu (template) trống, sẵn sàng để sao chép-dán và sử dụng cho việc phân tích một quy trình nghiệp vụ cụ thể. Mẫu này được cấu trúc để đảm bảo tính đầy đủ, nhất quán và có khả năng truy vết (traceability) theo chuẩn của corpus Nova Foods.

Hướng dẫn sử dụng: 1. Sao chép toàn bộ nội dung Markdown từ mục 2.1 trở đi vào một tệp mới (ví dụ: /docs/processes/PROC-XXX-Ten-Quy-Trinh.md). 2. Điền thông tin chi tiết vào các vùng có placeholder dạng <...>. 3. Xóa các dòng hướng dẫn trong ngoặc đơn (...) sau khi đã hiểu rõ yêu cầu. 4. Tuân thủ các quy ước về định danh và tham chiếu đến các artifact canonical.

2.1. Tổng quan Quy trình

Thuộc tính Nội dung
ID Quy trình <PROC-XXX>
(Sử dụng định danh duy nhất được đăng ký tại TRACEABILITY_ID_REGISTRY.md)
Tên Quy trình <Tên đầy đủ của quy trình>
Phiên bản <1.0>
(Bắt đầu từ 1.0 cho phiên bản đầu tiên)
Ngày hiệu lực <YYYY-MM-DD>
Chủ sở hữu Quy trình (Process Owner) <Chức danh của người chịu trách nhiệm cuối cùng về hiệu quả và kết quả của quy trình>
Process Owner: Là vai trò nghiệp vụ (business role), không phải vai trò kỹ thuật, có thẩm quyền quyết định về cách quy trình vận hành.
Mô tả & Mục tiêu <Mô tả ngắn gọn quy trình này làm gì, tại sao nó tồn tại, và mục tiêu nghiệp vụ chính mà nó hướng tới. Ví dụ: "Quy trình này quản lý việc tạo và duyệt đơn đặt hàng từ nhà cung cấp, nhằm đảm bảo hàng hóa được mua đúng số lượng, chất lượng và giá cả." >

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

Thành phần Chi tiết
Điểm kích hoạt (Trigger) <Sự kiện cụ thể nào bắt đầu quy trình này? Ví dụ: "Yêu cầu mua hàng (Purchase Requisition) được phê duyệt." >
Các bên liên quan (Actors) <Liệt kê tất cả các vai trò người dùng hoặc hệ thống tham gia trực tiếp vào quy trình. Ví dụ: Nhân viên mua hàng, Kế toán kho, Quản lý cấp duyệt.>
Đầu vào (Inputs) <Liệt kê tất cả thông tin, tài liệu, hoặc dữ liệu cần thiết để bắt đầu và thực hiện quy trình. Ví dụ: Form yêu cầu mua hàng, Báo giá nhà cung cấp.>
Đầu ra (Outputs) <Liệt kê tất cả kết quả, tài liệu, hoặc dữ liệu được tạo ra khi quy trình hoàn tất. Ví dụ: Đơn đặt hàng (Purchase Order) đã được gửi cho nhà cung cấp, bản ghi trong hệ thống ERP.>
Hệ thống liên quan <Liệt kê các hệ thống, module, hoặc ứng dụng phần mềm có tương tác với quy trình. Ví dụ: Module MM của ERP, hệ thống email.>
Ngoài phạm vi (Out of Scope) <Mô tả rõ ràng các hoạt động hoặc bước có liên quan nhưng không thuộc về quy trình này để tránh hiểu lầm. Ví dụ: "Quy trình này không bao gồm việc nhận hàng và thanh toán hóa đơn." >

2.3. Phân tích Quy trình Hiện tại (As-Is)

As-Is: Là thuật ngữ chỉ trạng thái "như hiện tại" của một quy trình, trước khi có bất kỳ sự thay đổi hay cải tiến nào.

Mô tả tường thuật: <Viết một đoạn văn mô tả chi tiết từng bước của quy trình đang diễn ra trong thực tế, bao gồm cả những công việc thủ công, các điểm nghẽn và những gì người dùng đang thực sự làm.>

Sơ đồ Quy trình Hiện tại: * Định dạng: Sơ đồ phải được vẽ bằng ký pháp BPMN 2.0.2. * Tham chiếu: <Dán đường dẫn đến tệp sơ đồ hoặc hình ảnh sơ đồ tại đây. Ví dụ: /diagrams/PROC-XXX_As-Is_v1.0.png>

Phân tích Điểm yếu (Pain Point Analysis):

ID Điểm yếu Mô tả Vấn đề Ảnh hưởng Nghiệp vụ Mức độ Ưu tiên (Cao/Trung bình/Thấp)
<PP-001> <Mô tả một vấn đề cụ thể trong quy trình hiện tại. Ví dụ: "Phải in đơn hàng ra giấy để lấy chữ ký duyệt, gây tốn thời gian và dễ thất lạc."> <Vấn đề này gây ra thiệt hại gì? Ví dụ: "Chậm trễ trong việc đặt hàng, rủi ro mất mát tài liệu, tốn chi phí giấy mực."> <Cao>
<PP-002> <...> <...> <...>

2.4. Thiết kế Quy trình Mục tiêu (To-Be)

To-Be: Là thuật ngữ chỉ trạng thái "sẽ trở thành" hoặc "mục tiêu" của quy trình sau khi được cải tiến.

Mô tả tường thuật: <Viết một đoạn văn mô tả chi tiết quy trình mới sẽ vận hành như thế nào, nhấn mạnh vào các bước được tự động hóa, các điểm cải tiến và vai trò của hệ thống mới.>

Sơ đồ Quy trình Mục tiêu: * Định dạng: Sơ đồ phải được vẽ bằng ký pháp BPMN 2.0.2. * Tham chiếu: <Dán đường dẫn đến tệp sơ đồ hoặc hình ảnh sơ đồ tại đây. Ví dụ: /diagrams/PROC-XXX_To-Be_v1.0.png>

Phân tích Lợi ích (Benefit Analysis):

ID Lợi ích Mô tả Cải tiến Loại Lợi ích (Định tính/Định lượng) Phương pháp đo lường
<BEN-001> <Quy trình duyệt đơn hàng hoàn toàn trên hệ thống, không cần giấy tờ.> <Định lượng> <Giảm thời gian xử lý trung bình từ 4 giờ xuống còn 30 phút. Tiết kiệm 1000 trang giấy mỗi tháng.>
<BEN-002> <Tăng cường tính minh bạch và khả năng theo dõi trạng thái đơn hàng.> <Định tính> <Khảo sát sự hài lòng của người dùng.>

2.5. Luồng Ngoại lệ và Luồng thay thế (Exceptions & Alternate Flows)

ID Ngoại lệ Điều kiện Kích hoạt Mô tả Luồng xử lý
<EX-001> <Nhà cung cấp từ chối đơn hàng do hết hàng.> <Hệ thống gửi thông báo cho nhân viên mua hàng. Nhân viên mua hàng có thể chọn tìm nhà cung cấp khác hoặc hủy yêu cầu mua hàng.>
<EX-002> <Người duyệt đi vắng quá 24 giờ.> <Hệ thống tự động leo thang (escalate) yêu cầu duyệt đến quản lý cấp cao hơn.>

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

Traceability Matrix: Là một bảng dùng để đảm bảo mọi yêu cầu đều được giải quyết bởi một phần nào đó của giải pháp và mọi phần của giải pháp đều có nguồn gốc từ một yêu cầu cụ thể.

ID Bước quy trình (To-Be) Tên Bước quy trình ID Yêu cầu liên quan
<PROC-XXX-STEP-01> <Tạo dự thảo Đơn đặt hàng> <RQ-123, RQ-124>
<PROC-XXX-STEP-02> <Gửi duyệt Đơn đặt hàng> <RQ-125, NFR-010>
<...> <...> <...>

2.7. Dữ liệu và Quy tắc Nghiệp vụ

Thực thể Dữ liệu Chính: * Tham chiếu đến Từ điển Dữ liệu Canonical tại: /01-curriculum/CANONICAL_DATA_DICTIONARY.md

Tên Thực thể Dữ liệu Mô tả
<Purchase Order> <Chứa thông tin chi tiết về một đơn đặt hàng cho nhà cung cấp.>
<Vendor> <Chứa thông tin về nhà cung cấp.>

Quy tắc Nghiệp vụ (Business Rules): * Tham chiếu đến Catalog Quy tắc Nghiệp vụ Canonical tại: /01-curriculum/CANONICAL_BUSINESS_RULES.md

ID Quy tắc Mô tả Quy tắc
<BR-051> <Một đơn đặt hàng có tổng giá trị trên 50,000,000 VND phải được duyệt bởi Trưởng phòng.>
<BR-052> <Không thể đặt hàng từ một nhà cung cấp đang có trạng thái "Tạm ngưng".>

2.8. Xem xét & Phê duyệt (Review & Sign-off)

Vai trò Tên người Review/Phê duyệt Ngày Trạng thái Ghi chú / Nhận xét
<Process Owner> <Điền tên> <YYYY-MM-DD> <Chưa Review / Đã duyệt / Yêu cầu thay đổi> <...>
<Business Analyst> <Điền tên> <YYYY-MM-DD> <Đã soạn thảo / Đã duyệt> <...>
<Technical Lead> <Điền tên> <YYYY-MM-DD> <Chưa Review / Đã duyệt / Yêu cầu thay đổi> <...>
<QA Lead> <Điền tên> <YYYY-MM-DD> <Chưa Review / Đã duyệt / Yêu cầu thay đổi> <...>

Phụ lục: Quản trị, Truy vết, và Quyết định

Phần này cung cấp các bảng trống để ghi nhận lịch sử phiên bản, phê duyệt, truy vết yêu cầu, các trường hợp ngoại lệ, bằng chứng thu thập và các quyết định quan trọng được đưa ra trong quá trình phân tích. Việc duy trì các bảng này là bắt buộc để đảm bảo tính minh bạch, trách nhiệm giải trình và khả năng kiểm soát của tài liệu.

Lịch sử Phiên bản (Version History)

Bảng này ghi lại mọi thay đổi đối với tài liệu phân tích quy trình này. Mỗi thay đổi, dù nhỏ, đều phải được ghi nhận để đảm bảo khả năng truy vết nguồn gốc của các quyết định và yêu cầu.

Phiên bản Ngày cập nhật Người thực hiện Mô tả thay đổi Tham chiếu phê duyệt (nếu có)
<v1.0> <YYYY-MM-DD> <Tên/ID người phân tích> <Khởi tạo tài liệu phân tích cho quy trình X> <N/A>
<v1.1> <YYYY-MM-DD> <Tên/ID người phân tích> <Cập nhật bước 3.2 dựa trên phản hồi từ bộ phận Kế toán> <ID email/ticket phê duyệt>

Theo dõi Xem xét và Phê duyệt (Review and Sign-off)

Việc phê duyệt chính thức từ các bên liên quan là một cột mốc quan trọng, xác nhận rằng tài liệu phân tích đã được thống nhất. Bảng này ghi lại bằng chứng phê duyệt đó. "Sign-off" là một thuật ngữ tiếng Anh chỉ hành động phê duyệt cuối cùng, chính thức xác nhận sự đồng thuận.

Vai trò Tên/ID người review Ngày review Kết quả Ghi chú / Tham chiếu
Business Owner <Tên/ID của chủ quy trình nghiệp vụ> <YYYY-MM-DD> <Chưa review / Đã phê duyệt / Phê duyệt có điều kiện / Từ chối> <Link đến ticket, email hoặc bình luận chi tiết>
Technical Architect <Tên/ID của kiến trúc sư giải pháp> <YYYY-MM-DD> <Chưa review / Đã phê duyệt / Phê duyệt có điều kiện / Từ chối> <Link đến ticket, email hoặc bình luận chi tiết>
QA Lead <Tên/ID của trưởng nhóm kiểm thử> <YYYY-MM-DD> <Chưa review / Đã phê duyệt / Phê duyệt có điều kiện / Từ chối> <Link đến ticket, email hoặc bình luận chi tiết>
Legal/Compliance <Tên/ID của người phụ trách pháp lý/tuân thủ> <YYYY-MM-DD> <Chưa review / Đã phê duyệt / Phê duyệt có điều kiện / Từ chối> <Chỉ review các mục liên quan đến pháp lý/tuân thủ.>

Ma trận Truy vết Yêu cầu (Requirements Traceability Matrix - RTM)

Traceability (truy vết) là khả năng theo dõi một yêu cầu từ nguồn gốc ban đầu, qua các giai đoạn phát triển, cho đến khi hoàn thiện và được kiểm thử. Ma trận này liên kết các bước quy trình với quy tắc nghiệp vụ, yêu cầu chức năng và phi chức năng, và các kịch bản kiểm thử, đảm bảo không có yêu cầu nào bị "rơi rớt" hoặc được tạo ra mà không có mục đích rõ ràng.

ID Quy trình/Bước ID Quy tắc nghiệp vụ (Business Rule) ID Yêu cầu (Requirement) ID Kịch bản Kiểm thử (Test Case) Ghi chú
<PROC-001-S01> <BR-FIN-005> <REQ-INV-012> <TC-INV-025> <Bước xác thực hóa đơn liên quan đến quy tắc tính thuế GTGT.>
<PROC-001-S02> <BR-SEC-001> <REQ-SEC-003> <TC-SEC-008> <Bước đăng nhập phải tuân thủ chính sách mật khẩu của hệ thống.>

Bảng Xử lý Ngoại lệ (Exception Handling)

Không quy trình nào hoàn hảo. Bảng này dùng để xác định trước các tình huống ngoại lệ có thể xảy ra, cách xử lý dự kiến và người chịu trách nhiệm, giúp giảm thiểu rủi ro khi vận hành thực tế.

ID Ngoại lệ Bước quy trình xảy ra Mô tả tình huống ngoại lệ Cách xử lý dự kiến / Giải pháp Mức độ ưu tiên Owner xử lý
<EX-01> <Tên hoặc ID của bước quy trình> <Nhà cung cấp gửi hóa đơn điện tử sai định dạng XML theo quy định.> <Hệ thống từ chối hóa đơn, gửi thông báo lỗi tự động cho NCC và nhân viên kế toán.> <Cao> <Bộ phận Kế toán>
<EX-02> <Tên hoặc ID của bước quy trình> <Hệ thống ERP không thể kết nối đến API của dịch vụ kho vận bên thứ ba.> <Thử lại 3 lần, mỗi lần cách nhau 5 phút. Nếu vẫn lỗi, ghi nhận giao dịch vào hàng đợi và báo cho admin hệ thống.> <Trung bình> <Đội ngũ IT>

Danh mục Bằng chứng (Evidence Log)

Mọi phân tích và đề xuất phải dựa trên bằng chứng cụ thể. Bảng này là nơi tập hợp các tài liệu, biên bản họp, ảnh chụp màn hình, hay các nguồn tham chiếu đã được sử dụng để xây dựng tài liệu này.

ID Bằng chứng Tên / Mô tả Bằng chứng Loại Nguồn / Đường dẫn Ngày thu thập
<EV-01> <Biên bản họp với bộ phận Kế toán về quy trình đối soát công nợ> <Biên bản họp> <link/to/meeting_minutes.docx> <YYYY-MM-DD>
<EV-02> <Ảnh chụp màn hình hệ thống cũ đang gặp lỗi> <Ảnh chụp màn hình> <link/to/screenshot.png> <YYYY-MM-DD>
<EV-03> <Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ> <Văn bản pháp quy> <https://vanban.chinhphu.vn/?docid=201365> <YYYY-MM-DD>

Nhật ký Quyết định (Decision Log)

Ghi lại các quyết định quan trọng đã được đưa ra, các lựa chọn đã được xem xét và lý do cho quyết định cuối cùng. Điều này giúp tránh việc phải tranh luận lại những vấn đề đã được giải quyết.

ID Quyết định Vấn đề cần quyết định Các phương án đã xem xét Quyết định cuối cùng Lý do lựa chọn Người quyết định Ngày quyết định
<DEC-01> <Chọn phương thức xác thực cho API nhập hàng tồn kho.> <1. Basic Auth. 2. API Key. 3. OAuth 2.0 Client Credentials.> <Sử dụng OAuth 2.0 Client Credentials.> <Cung cấp mức độ bảo mật cao hơn, quản lý vòng đời token tốt hơn, phù hợp với tiêu chuẩn ngành.> <Technical Architect> <YYYY-MM-DD>
<DEC-02> <Ngôn ngữ mặc định cho giao diện người dùng.> <1. Chỉ tiếng Việt. 2. Tiếng Việt và tiếng Anh.> <Ưu tiên tiếng Việt, có kế hoạch hỗ trợ tiếng Anh trong tương lai.> <Phù hợp với đối tượng người dùng chính hiện tại (Nova Foods Việt Nam), tối ưu chi phí phát triển giai đoạn đầu.> <Business Owner> <YYYY-MM-DD>

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

Hướng dẫn này đảm bảo các tài liệu phân tích quy trình tuân thủ cấu trúc, có thể kiểm tra chéo và duy trì tính toàn vẹn theo yêu cầu quản trị của corpus. Việc áp dụng nhất quán các quy tắc này là bắt buộc để tài liệu được coi là hợp lệ.

Bảng hướng dẫn và quy tắc xác thực cho các trường chính:

Tên trường (Placeholder) Hướng dẫn điền Quy tắc xác thực / Giá trị cho phép
Mã quy trình (<PROC-ID-NNN>) Sử dụng định danh duy nhất đã được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Đây là khóa chính để liên kết và truy vết. Định dạng: PROC-ID- theo sau là số nguyên dương. Quy tắc: Phải tồn tại trong registry. Không được tự ý tạo mã mới.
Phiên bản (<Major.Minor.Patch>) Tuân thủ nghiêm ngặt theo Semantic Versioning 2.0.0. Major cho thay đổi phá vỡ tương thích, Minor cho chức năng mới tương thích ngược, Patch cho sửa lỗi. Định dạng: X.Y.Z với X, Y, Z là số nguyên không âm. Ví dụ: 1.0.0, 2.11.3.
Trạng thái (<Trạng thái quy trình>) Phản ánh trạng thái hiện tại của tài liệu trong vòng đời. Trạng thái này quyết định các hành động tiếp theo được phép. Giá trị cho phép (danh sách kiểm soát): DRAFT, IN_REVIEW, APPROVED, DEPRECATED.
Mức độ rủi ro (<Mức độ rủi ro>) Đánh giá mức độ rủi ro nghiệp vụ nếu quy trình thất bại hoặc thực hiện sai. Cần có sự đồng thuận từ Chủ sở hữu nghiệp vụ (Business Owner). Giá trị cho phép: Low, Medium, High, Critical. Logic có điều kiện: Kích hoạt các mục bắt buộc khác.
Mã truy vết yêu cầu (<REQ-ID-{NNN}>) Liệt kê tất cả các mã định danh yêu cầu (requirement) mà quy trình này thực thi hoặc bị ảnh hưởng. Định dạng: Tương ứng với định dạng yêu cầu trong TRACEABILITY_ID_REGISTRY. Quy tắc: Mọi ID phải hợp lệ và có thể truy vết ngược về nguồn.

Quy tắc hiển thị có điều kiện

Các mục trong tài liệu có thể trở thành bắt buộc dựa trên giá trị của các trường khác. Điều này đảm bảo mức độ phân tích phù hợp với rủi ro và độ phức tạp.

  • Điều kiện: Khi trường Mức độ rủi ro có giá trị là High hoặc Critical.
  • Hành động bắt buộc: Các mục con trong phần Phân tích Rủi ro & Kế hoạch Giảm thiểu (ví dụ: mục 3.7 trong bản hoàn chỉnh) phải được điền đầy đủ và chi tiết. Không được để trống hoặc ghi "N/A".

Mẫu tham chiếu thông tin mật an toàn (Safe Secret-Reference Pattern)

Tuyệt đối không nhúng trực tiếp thông tin nhạy cảm như khóa API, mật khẩu, chuỗi kết nối (connection string) hoặc token vào tài liệu. Việc này vi phạm nguyên tắc bảo mật cơ bản và tạo ra rủi ro rò rỉ thông tin.

Thay vào đó, sử dụng mẫu tham chiếu đến một hệ thống quản lý bí mật (secret management system) như HashiCorp Vault hoặc dịch vụ tương đương.

  • Định dạng tham chiếu: {{SECRET_VAULT:<path/to/secret_name>}}
  • Diễn giải:
    • SECRET_VAULT là từ khóa chỉ định rằng đây là một tham chiếu đến hệ thống quản lý bí mật.
    • <path/to/secret_name> là đường dẫn đến bí mật cụ thể trong vault, theo quy ước đặt tên của Nova Foods.
  • Ví dụ thực tế (mô phỏng):
    • Để tham chiếu khóa API của cổng thanh toán: {{SECRET_VAULT:nova-foods/prod/payment-gateway/api-key}}
    • Để tham chiếu mật khẩu của tài khoản dịch vụ SAP: {{SECRET_VAULT:nova-foods/prod/sap-connector/service-account-password}}

Cách tiếp cận này tách biệt tài liệu phân tích khỏi dữ liệu nhạy cảm, cho phép kiểm soát truy cập và luân chuyển bí mật một cách an toàn mà không cần cập nhật tài liệu.

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

Phần này trình bày một ví dụ hoàn chỉnh về tài liệu phân tích quy trình, áp dụng cho một kịch bản mô phỏng tại Nova Foods. Mọi thông tin, dữ liệu, tên người và ID đều là giả định cho mục đích đào tạo.

Bản ghi Phân tích Quy trình Nova Foods

Trường Dữ liệu Giá trị
Process ID NOVA-P2P-03
Tên Quy trình Quy trình Xử lý và Phê duyệt Hóa đơn Nhà cung cấp (Vendor Invoice Processing and Approval)
Owner Quy trình (Nghiệp vụ) Trần Văn Hùng (Trưởng phòng Kế toán)
Ngày Phân tích 2026-08-07
Người Phân tích Nguyễn Bảo An (IT Business Analyst)
Hệ thống Liên quan ERP-LEGACY-01 (Hệ thống ERP cũ), Email Outlook
Phiên bản 1.0 (As-Is Analysis)

3.1. Bối cảnh và Vấn đề Hiện tại

Quy trình xử lý hóa đơn của nhà cung cấp tại Nova Foods hiện đang được thực hiện phần lớn thủ công. Phòng Kế toán Phải trả (Accounts Payable - AP) nhận hóa đơn dưới dạng giấy hoặc tệp PDF đính kèm qua email từ nhà cung cấp. Nhân viên kế toán, cụ thể là Lê Thị Minh Anh, phải tự đọc thông tin trên hóa đơn (số tiền, ngày tháng, mã số thuế nhà cung cấp) và nhập liệu thủ công vào hệ thống ERP cũ (ERP-LEGACY-01).

Quá trình này tồn tại nhiều vấn đề nghiêm trọng: 1. Tốn thời gian: Thời gian trung bình để xử lý một hóa đơn từ khi nhận được đến khi sẵn sàng để thanh toán là 7 ngày làm việc. 2. Sai sót nhập liệu: Việc nhập liệu thủ công thường xuyên gây ra lỗi, dẫn đến việc phải đối chiếu và sửa chữa mất thời gian, đôi khi gây ra thanh toán sai. 3. Thiếu minh bạch: Không có một hệ thống trung tâm để theo dõi trạng thái của một hóa đơn cụ thể. Khi nhà cung cấp hoặc phòng Mua hàng hỏi về tình trạng thanh toán, phòng Kế toán phải kiểm tra thủ công trong email và file Excel. 4. Rủi ro kinh doanh: Gần đây, một hóa đơn trị giá 55.000.000 VND từ nhà cung cấp chiến lược NCC-0118 (Công ty TNHH Thực phẩm Sạch An Tâm) đã bị thanh toán trễ 15 ngày do hóa đơn bị thất lạc trong email. Sự cố này đã làm ảnh hưởng tiêu cực đến mối quan hệ với nhà cung cấp và suýt gây gián đoạn nguồn cung nguyên liệu sản xuất.

Sự cố với nhà cung cấp An Tâm là tác nhân chính thúc đẩy việc phân tích và cải tiến quy trình này.

3.2. Quy trình Hiện tại (As-Is Process)

Quy trình hiện tại diễn ra theo các bước sau:

  1. Nhận hóa đơn: Nhà cung cấp gửi hóa đơn giấy qua đường bưu điện hoặc gửi file PDF/ảnh chụp qua email đến địa chỉ chung ketoan@novafoods.vn.
  2. Phân loại và In ấn: Nhân viên kế toán (Lê Thị Minh Anh) kiểm tra email hàng ngày, tải về các tệp hóa đơn. Nếu là hóa đơn giấy, cô lưu trữ vào một khay tài liệu.
  3. Nhập liệu vào ERP: Dựa trên bản cứng hoặc file PDF, nhân viên kế toán đăng nhập vào hệ thống ERP-LEGACY-01 và tạo một bản ghi hóa đơn mới. Quá trình này bao gồm việc nhập thủ công các trường: Mã nhà cung cấp, Số hóa đơn, Ngày hóa đơn, Tổng tiền trước thuế, Thuế GTGT, Tổng tiền thanh toán.
  4. Đối chiếu thủ công: Nhân viên kế toán tự tra cứu Đơn đặt hàng (Purchase Order - PO) và Phiếu nhập kho (Goods Receipt Note - GRN) tương ứng trong hệ thống ERP để xác nhận tính hợp lệ của hóa đơn (khớp 3 chiều: hóa đơn, PO, GRN). Quá trình này được ghi nhận bằng cách ghi chú vào một file Excel theo dõi riêng.
  5. Trình ký phê duyệt: Sau khi đối chiếu, nhân viên kế toán in bản ghi hóa đơn từ ERP, kẹp cùng hóa đơn gốc và mang đến cho Trưởng phòng Kế toán (Trần Văn Hùng) để ký duyệt bằng tay.
  6. Chờ phê duyệt: Nếu Trưởng phòng vắng mặt hoặc bận, bộ chứng từ sẽ nằm trên bàn chờ.
  7. Phê duyệt và Lưu trữ: Sau khi được ký duyệt, nhân viên kế toán cập nhật trạng thái "Đã duyệt, chờ thanh toán" vào file Excel. Chứng từ giấy được lưu vào tủ hồ sơ.

3.3. Các Bên Liên Quan (Stakeholders)

ID Stakeholder Tên Vai trò Mức độ Ảnh hưởng Mức độ Quan tâm
STK-ACC-001 Trần Văn Hùng Trưởng phòng Kế toán Cao Cao
STK-ACC-002 Lê Thị Minh Anh Kế toán Phải trả (AP) Trung bình Cao
STK-PUR-001 Hoàng Minh Quân Trưởng phòng Mua hàng Trung bình Trung bình
STK-VDR-018 NCC An Tâm Nhà cung cấp Cao Cao

3.4. Nhu cầu Nghiệp vụ và Mục tiêu (Business Needs & Objectives)

Nhu cầu cốt lõi là tự động hóa và tối ưu hóa quy trình xử lý hóa đơn để giảm thiểu rủi ro vận hành và cải thiện hiệu quả tài chính.

  • Mục tiêu chính (SMART Objectives):
    • Giảm thời gian xử lý hóa đơn trung bình từ 7 ngày xuống còn tối đa 2 ngày làm việc trước cuối Quý 4/2027.
    • Loại bỏ 100% lỗi nhập liệu thủ công bằng cách tự động hóa việc trích xuất dữ liệu từ hóa đơn.
    • Cung cấp khả năng theo dõi trạng thái hóa đơn theo thời gian thực cho phòng Kế toán và Mua hàng thông qua một dashboard tập trung.
    • Giảm 95% số lượng hóa đơn bị thanh toán trễ do các nguyên nhân thuộc quy trình nội bộ.

3.5. Phạm vi Phân tích

  • Trong phạm vi (In-Scope):

    • Tiếp nhận hóa đơn điện tử từ nhà cung cấp (qua cổng portal hoặc email được chỉ định).
    • Tự động trích xuất dữ liệu (OCR - Optical Character Recognition) từ hóa đơn.
    • Quy tắc tự động đối chiếu hóa đơn với PO và GRN (3-way matching).
    • Luồng phê duyệt điện tử (digital approval workflow) dựa trên các quy tắc được định nghĩa (ví dụ: tự động duyệt hóa đơn dưới 20.000.000 VND nếu khớp 3 chiều).
    • Tích hợp để đẩy dữ liệu hóa đơn đã được phê duyệt vào module AP của hệ thống ERP mới (SAP S/4HANA).

  • Ngoài phạm vi (Out-of-Scope):

    • Quy trình tạo và phê duyệt Đơn đặt hàng (PO).
    • Quy trình quản lý và onboarding nhà cung cấp.
    • Quy trình thực hiện thanh toán (lập lệnh chuyển tiền, xử lý ngân hàng).
    • Quản lý và lưu trữ hóa đơn giấy.

Ví dụ hoàn chỉnh: Phân tích Quy trình Yêu cầu Mua hàng

Phần này điền đầy đủ mẫu phân tích quy trình cho một trường hợp mô phỏng tại Nova Foods: tạo yêu cầu mua hàng (Purchase Requisition) cho các mặt hàng không thuộc tồn kho (non-inventory items).

Trường Dữ liệu Giá trị Ghi chú
ID Quy trình PROC-MRO-001 MRO: Bảo trì, Sửa chữa, Vận hành.
Tên Quy trình Yêu cầu Mua hàng cho Hàng hóa & Dịch vụ (Non-Inventory) Áp dụng cho chi tiêu không quản lý qua tồn kho.
Owner Quy trình Trưởng phòng Mua hàng (ID vai trò: ROLE-PROC-LEAD) Chịu trách nhiệm về hiệu quả và tuân thủ.
Phiên bản Phân tích 1.0 Phiên bản khởi tạo của tài liệu phân tích này.
Ngày Phân tích 2026-08-07 Ngày hoàn thành phân tích hiện trạng.
Phạm vi Trong phạm vi (In-Scope): Tạo, phê duyệt, và chuyển yêu cầu mua hàng cho vật tư tiêu hao, dịch vụ, tài sản cố định nhỏ.
Ngoài phạm vi (Out-of-Scope): Quy trình mua nguyên vật liệu sản xuất, quản lý nhà cung cấp, đàm phán hợp đồng, xử lý thanh toán.		 Giữ cho phân tích tập trung. Các quy trình ngoài phạm vi được xử lý riêng.

Mô tả Quy trình Hiện tại (As-Is)

Nhân viên cần hàng hóa/dịch vụ. Họ điền thông tin vào một tệp Excel mẫu (F-PROC-01_Request_Form_v2.xlsx). Tệp này được gửi qua email cho quản lý trực tiếp để phê duyệt. Nếu được duyệt, quản lý chuyển tiếp (forward) email đó cho bộ phận Mua hàng. Nhân viên mua hàng phải nhập lại thông tin thủ công từ tệp Excel vào một hệ thống theo dõi nội bộ khác.

Vấn đề chính (Pain Points): * Chậm trễ: Luồng email gây trễ, đặc biệt khi quản lý vắng mặt. * Thiếu minh bạch: Người yêu cầu không biết trạng thái xử lý yêu cầu của mình. * Rủi ro sai sót: Việc nhập liệu thủ công dễ gây lỗi về số lượng, mã hàng, giá cả. * Thất lạc thông tin: Email có thể bị bỏ sót, dẫn đến yêu cầu không được xử lý.

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

Vai trò Ví dụ Tác nhân (Actor) Trách nhiệm chính trong quy trình
Người yêu cầu Nguyễn Văn An (ID: NV-RD-11021) Tạo và gửi yêu cầu mua hàng với đầy đủ thông tin.
Quản lý phê duyệt Trần Thị Bích (ID: QL-RD-0238) Xem xét tính hợp lý, kiểm tra ngân sách, và ra quyết định Duyệt hoặc Từ chối.
Nhân viên Mua hàng Lê Minh Cường (ID: NV-PROC-007) Tiếp nhận yêu cầu đã được duyệt. Xác thực thông tin và tạo Đơn đặt hàng (Purchase Order).

Quy tắc Nghiệp vụ Chính (Key Business Rules)

Quy tắc nghiệp vụ (Business Rule) là các ràng buộc hoặc chỉ dẫn cụ thể quyết định cách thức hoạt động của quy trình.

ID Quy tắc Nội dung Quy tắc Lý do / Nguồn gốc
BR-PROC-MRO-001 Mọi yêu cầu có tổng giá trị ước tính > 50.000.000 VND phải được phê duyệt thêm bởi Trưởng phòng ban. Giảm thiểu rủi ro tài chính đối với các chi tiêu lớn. (Nguồn: ASSUMPTION-FIN-CTRL-01)
BR-PROC-MRO-002 Yêu cầu phải chỉ định một nhà cung cấp từ danh sách nhà cung cấp đã được phê duyệt của Nova Foods. Đảm bảo chất lượng đầu vào và tuân thủ các thỏa thuận khung đã đàm phán. (Nguồn: BR-SUPPLIER-MGMT-004)
BR-PROC-MRO-003 Không cho phép tạo yêu cầu cho các mặt hàng đang được quản lý tồn kho (inventory items) thông qua quy trình này. Tách biệt rõ ràng giữa quy trình mua hàng MRO và quy trình bổ sung tồn kho chiến lược. (Nguồn: PROC-INV-MGMT-001)

Trạng thái và Luồng chuyển đổi (States and Transitions)

Một yêu cầu mua hàng sẽ đi qua các trạng thái sau. Bảng này mô tả cách nó chuyển từ trạng thái này sang trạng thái khác.

Trạng thái Hiện tại Hành động Kích hoạt (Trigger) Trạng thái Tiếp theo Người thực hiện
(Không có) Người dùng tạo yêu cầu DRAFT Người yêu cầu
DRAFT Gửi yêu cầu đi duyệt PENDING_APPROVAL Người yêu cầu
PENDING_APPROVAL Quản lý phê duyệt APPROVED Quản lý phê duyệt
PENDING_APPROVAL Quản lý từ chối REJECTED Quản lý phê duyệt
APPROVED Nhân viên Mua hàng tạo PO PROCESSED Nhân viên Mua hàng

Cấu trúc Dữ liệu Chính (Core Data / Payload)

Payload là gói dữ liệu cần thiết để thực hiện một bước trong quy trình, ví dụ như dữ liệu gửi lên hệ thống khi tạo mới một yêu cầu.

Đối tượng: PurchaseRequisition | Tên trường (Field Name) | Kiểu dữ liệu (Data Type) | Mô tả | Ví dụ | | :--- | :--- | :--- | :--- | | requisitionId | string | Định danh duy nhất do hệ thống tạo ra. | REQ-2026-08-00123 | | requesterId | string | Mã nhân viên của người yêu cầu. | NV-RD-11021 | | departmentId | string | Mã phòng ban chịu chi phí. | DEPT-RD-01 | | requestDate | string (ISO 8601) | Ngày và giờ tạo yêu cầu. | 2026-08-07T14:30:00Z | | status | string | Trạng thái hiện tại của yêu cầu (DRAFT, PENDING_APPROVAL, etc.). | PENDING_APPROVAL | | supplierId | string | Mã nhà cung cấp được đề xuất. | SUP-GLW-0045 | | totalEstimatedValue | number | Tổng giá trị ước tính của yêu cầu, đơn vị VND. | 45700000 | | justification | string | Lý do mua hàng. | "Mua máy ly tâm mới thay thế máy hỏng." | | lineItems | array(object) | Mảng chứa các mặt hàng chi tiết. | [{ "itemName": "Máy ly tâm...", "quantity": 1, ... }] |

Hiện trạng, Nhu cầu, và Lựa chọn Giải pháp

Phân tích này dựa trên quan sát trực tiếp quy trình, phỏng vấn Trưởng phòng Mua hàng (ID nhân viên mô phỏng: NVF-0012), và hai nhân viên bộ phận Sản xuất (ID: NVF-0158, NVF-0160).

1. Sự thật và Hành vi Hiện tại (Facts and Current Behavior)

Quy trình P-PROCURE-01: Tạo Yêu Cầu Mua Hàng (PR) hiện tại là thủ công. Người dùng từ các bộ phận tải biểu mẫu Excel F-PROC-001-v1.2.xlsx từ ổ đĩa mạng. Họ điền thông tin, sau đó gửi email cho quản lý để duyệt. Quản lý duyệt bằng cách chuyển tiếp email tới Trưởng phòng Mua hàng.

Hành vi này gây ra các vấn đề: - Dữ liệu không nhất quán: Mã vật tư, tên nhà cung cấp, đơn vị tính thường bị gõ sai, không theo chuẩn trong Từ điển Dữ liệu (CANONICAL_DATA_DICTIONARY). - Khó theo dõi: Không có hệ thống trung tâm để xem trạng thái yêu cầu. Việc theo dõi phụ thuộc vào tìm kiếm chuỗi email. - Duyệt chậm: Email có thể bị bỏ lỡ, trì hoãn, làm kéo dài thời gian mua hàng. - Lãng phí công sức: Phòng Mua hàng phải nhập lại dữ liệu từ Excel vào file theo dõi riêng. Tăng nguy cơ lỗi.

2. Nhu cầu Nghiệp vụ Cơ bản (Underlying Business Need)

Nhu cầu nghiệp vụ cốt lõi, định danh là REQ-PROC-005, là thiết lập quy trình mua hàng hiệu quả, minh bạch, có khả năng kiểm toán. - Truy vết (Traceability): Phải truy vết được yêu cầu từ lúc tạo qua phê duyệt, đặt hàng, nhận hàng và thanh toán. - Nguồn Chân lý Duy nhất (Single Source of Truth): Tất cả dữ liệu phải được lưu tại một nơi duy nhất, đáng tin cậy. Loại bỏ mâu thuẫn, phục vụ báo cáo. - Hiệu quả: Giảm thời gian chu trình, giảm các bước thủ công lặp lại. - Tuân thủ: Đảm bảo quy trình và dữ liệu tuân thủ Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP về chứng từ.

3. Phân tích Phương án và Tiêu chí Quyết định

Ba phương án được xem xét để đáp ứng nhu cầu REQ-PROC-005.

Tiêu chí Phương án 1: Giữ nguyên Phương án 2: Cải tiến Excel/SharePoint Phương án 3: Module mới trên ERP Ghi chú Tiêu chí
Chi phí triển khai Rất thấp Thấp Cao Chi phí nhân lực, giấy phép, hạ tầng.
Thời gian triển khai Không có Ngắn (1-2 tuần) Dài (3-4 tháng) Thời gian từ lúc quyết định đến khi hoạt động.
Toàn vẹn dữ liệu Rất thấp Thấp Rất cao Khả năng đảm bảo dữ liệu đúng, đủ, nhất quán.
Khả năng truy vết Rất thấp Thấp Rất cao Khả năng theo dõi lịch sử và trạng thái yêu cầu.
Khả năng mở rộng Rất thấp Thấp Rất cao Khả năng đáp ứng khi công ty tăng trưởng.
Trải nghiệm người dùng Kém Trung bình Tốt Mức độ dễ dàng và hiệu quả khi dùng.

4. Đề xuất, Thẩm quyền và Hậu quả

  • Đề xuất: Chọn Phương án 3: Xây dựng module Yêu cầu Mua hàng mới trên hệ thống ERP. Giải pháp này giải quyết triệt để vấn đề cốt lõi. Nó tạo ra giá trị bền vững và nền tảng cho tự động hóa tương lai.
  • Thẩm quyền quyết định: Giám đốc Chuỗi Cung ứng (Supply Chain Director). Quyết định sau khi tham vấn Trưởng phòng Mua hàng, Kế toán và CNTT.
  • Hậu quả nếu quyết định sai: Nếu chọn Phương án 1 hoặc 2, Nova Foods tiếp tục gặp rủi ro vận hành do dữ liệu sai, quy trình chậm. Nguy cơ gián đoạn sản xuất vì thiếu vật tư. Không có dữ liệu kiểm toán đáng tin cậy. Giải pháp tạm thời sẽ nhanh chóng quá tải, buộc phải làm lại dự án với chi phí cao hơn.

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

Phần này ghi lại các bằng chứng, giả định, và đường dẫn truy vết (traceability) cho phân tích quy trình Yêu cầu Mua hàng. Truy vết là khả năng liên kết một yêu cầu từ gốc tới ngọn, đảm bảo mọi thứ được xây dựng đều có lý do và được kiểm chứng.

Bảng Truy vết Yêu cầu

Bảng này liên kết nhu cầu nghiệp vụ ban đầu (NEED) với các yêu cầu (REQ), quy tắc (BR), tiêu chí chấp nhận (AC), và ca kiểm thử (TC) tương ứng.

ID Nguồn (Source) Mô tả Nguồn ID Đích (Destination) Mô tả Đích
NEED-PROC-001 Cần quy trình mua hàng tập trung, có kiểm soát và truy vết. REQ-PROC-005 Hệ thống phải cho phép tạo, duyệt, theo dõi Yêu cầu Mua hàng (PR) điện tử.
REQ-PROC-005 Hệ thống cho phép tạo, duyệt, theo dõi PR điện tử. BR-PROC-007 Mọi PR trên 50,000,000 VND phải được Giám đốc Chuỗi Cung ứng duyệt.
BR-PROC-007 PR > 50M VND cần duyệt cấp cao. AC-PROC-012 Khi PR có TotalValue > 50,000,000 VND, hệ thống tự động định tuyến đến Giám đốc Cung ứng.
AC-PROC-012 Tự động định tuyến PR > 50M VND. TC-POS-031 Kiểm tra luồng phê duyệt thành công cho PR 55,000,000 VND.
AC-PROC-012 Tự động định tuyến PR > 50M VND. DATA-PR-001 Yêu cầu dữ liệu PurchaseRequest.TotalValue để kích hoạt quy tắc.

4.1. Ngoại lệ và Luồng Tiêu cực (Exceptions and Negative Paths)

Luồng tiêu cực (Negative Path) là các kịch bản mà người dùng hoặc hệ thống gặp lỗi hoặc đi chệch khỏi luồng xử lý chuẩn. Phân tích các luồng này giúp thiết kế hệ thống vững chắc hơn.

ID Ngoại lệ Kịch bản Gây lỗi (Trigger) Hành vi Hệ thống Mong muốn Tham chiếu Ca kiểm thử
EXCP-PR-001 Người dùng nhập mã nhà cung cấp không tồn tại trong master data. Hệ thống hiển thị thông báo lỗi: "Mã nhà cung cấp không hợp lệ. Vui lòng chọn từ danh sách." Không cho phép lưu. TC-NEG-015
EXCP-PR-002 Người dùng tạo yêu cầu mua hàng vượt quá ngân sách đã được phân bổ cho phòng ban. Hệ thống hiển thị cảnh báo: "Yêu cầu vượt ngân sách tháng còn lại [Số tiền]. Yêu cầu sẽ cần phê duyệt bổ sung từ Kế toán trưởng." TC-NEG-016
EXCP-PR-003 API kiểm tra tồn kho của nhà cung cấp (API-SUP-002) trả về lỗi 503 (Service Unavailable). Hệ thống thử lại 2 lần, mỗi lần cách nhau 5 giây. Nếu vẫn lỗi, ghi nhận yêu cầu ở trạng thái "Chờ xác nhận tồn kho" và thông báo cho người dùng. TC-NEG-017
EXCP-PR-004 Người phê duyệt từ chối (reject) một yêu cầu mua hàng. Hệ thống yêu cầu người phê duyệt nhập lý do từ chối (bắt buộc). Trạng thái yêu cầu chuyển thành "Đã từ chối" và gửi thông báo kèm lý do cho người tạo. TC-NEG-018

4.2. Giả định (Assumptions)

Giả định (Assumption) là những điều chúng ta tin là đúng nhưng chưa được xác minh 100%. Ghi lại giả định giúp quản lý rủi ro nếu chúng sai.

ID Giả định Nội dung Giả định Tác động nếu Sai Hành động Giảm thiểu Rủi ro
ASM-PR-001 Dữ liệu nhà cung cấp hiện tại trong file Excel là chính xác và có thể được di chuyển (migrate) sang hệ thống ERP. Dữ liệu sai gây gián đoạn quá trình đặt hàng và thanh toán. Chi phí làm sạch dữ liệu cao. Lên kế hoạch cho một bước làm sạch và xác minh dữ liệu trước khi di chuyển. Giao cho phòng Mua hàng chịu trách nhiệm.
ASM-PR-002 Tất cả các trưởng phòng ban đều có và sử dụng email công ty để nhận thông báo phê duyệt. Người phê duyệt không nhận được yêu cầu, gây trì trệ quy trình. Xác nhận lại với phòng Nhân sự về danh sách email và chính sách sử dụng. Thiết kế thêm thông báo trong ứng dụng (in-app notification).
ASM-PR-003 Hệ thống ERP hiện tại có API để tích hợp module mới mà không cần thay đổi lớn ở phần lõi. Chi phí và thời gian phát triển tăng vọt nếu phải tùy chỉnh lõi ERP. Yêu cầu đội kỹ thuật thực hiện một bằng chứng khái niệm (Proof of Concept - PoC) nhỏ để xác minh khả năng tích hợp.

4.3. Các mục cần Xác minh (Verification-Required Items)

Đây là danh sách các thông tin quan trọng cần được xác nhận bởi người có thẩm quyền trước khi chốt yêu cầu.

ID Xác minh Mục cần Xác minh Người/Vai trò chịu trách nhiệm Xác minh Hạn chót Trạng thái
VER-PR-001 Xác nhận ma trận phê duyệt chi tiết (approval matrix) theo cấp giá trị và loại hàng hóa. Giám đốc Chuỗi Cung ứng 2026-08-21 Chưa bắt đầu
VER-PR-002 Xác nhận danh mục các mã chi phí (cost center codes) sẽ được sử dụng trong form Yêu cầu Mua hàng. Kế toán trưởng 2026-08-25 Chưa bắt đầu
VER-PR-003 Xác nhận các yêu cầu về báo cáo và dashboard cho quản lý cấp cao từ dữ liệu yêu cầu mua hàng. Trưởng phòng Mua hàng 2026-08-28 Chưa bắt đầu

4.4. Ghi nhận Leo thang (Escalation Records)

Ghi nhận các vấn đề cần quyết định ở cấp cao hơn do vượt quá thẩm quyền của nhóm dự án hoặc có ảnh hưởng chéo lớn.

ID Leo thang Vấn đề được Leo thang Các bên Liên quan Người ra Quyết định Ngày Quyết định Kết quả
ESC-PR-001 Lựa chọn giữa việc mua giấy phép phân hệ Mua hàng có sẵn (P2P module) của nhà cung cấp ERP và việc tự phát triển một module tùy chỉnh. Trưởng phòng CNTT, Giám đốc Tài chính (CFO), Giám đốc Chuỗi Cung ứng Giám đốc Điều hành (CEO) 2026-07-30 Quyết định: Phê duyệt phương án phát triển module tùy chỉnh (Phương án 3) để đáp ứng chính xác quy trình đặc thù của Nova Foods và kiểm soát chi phí bản quyền dài hạn.

Ma trận Truy vết Yêu cầu End-to-End

Truy vết (Traceability) liên kết các artifact với nhau. Từ nhu cầu nghiệp vụ ban đầu đến yêu cầu, quy tắc, tiêu chí chấp nhận, và cuối cùng là kiểm thử. Bảng này cho thấy các liên kết đó. Giúp tìm nguồn gốc của yêu cầu và đánh giá tác động khi thay đổi. Đây là thực hành cốt lõi theo hướng dẫn BABOK.

Ma trận dưới đây minh họa một luồng truy vết hoàn chỉnh cho kịch bản mô phỏng "Nhập kho Nguyên vật liệu" tại Nova Foods.

Bảng 4.1: Ma trận Truy vết cho luồng Nhập kho Nguyên vật liệu

ID Nhu cầu (NEED) ID Yêu cầu (REQ) ID Quy tắc (BR) ID Tiêu chí (AC) Thành phần Dữ liệu/API (DATA/API) ID Ca kiểm thử (TC) ID Lỗi/CR (DEF/CR)
NEED-001 Ghi nhận nhập kho NVL chính xác, kịp thời, đảm bảo truy xuất nguồn gốc lô hàng theo quy định an toàn thực phẩm. REQ-FUNC-015 Hệ thống phải cho phép nhân viên kho tạo Phiếu Nhập Kho (PNK) từ một Đơn đặt hàng (PO) đã duyệt. BR-ACC-007 PNK chỉ có giá trị khi được xác nhận bởi Quản lý kho. AC-039 (thuộc REQ-FUNC-015) WHEN tôi nhấn nút "Hoàn tất" trên PNK THEN hệ thống phải chuyển trạng thái PNK thành "Chờ duyệt" và gửi thông báo cho Quản lý kho. API-POST-GRN-V1 POST /api/v1/inventory/receipts TC-085 Kiểm tra quy trình duyệt PNK. N/A
NEED-001 (như trên) REQ-FUNC-016 Hệ thống phải ghi nhận được số lô, ngày sản xuất, hạn sử dụng của từng NVL nhận được. BR-INV-003 Không được phép nhập kho NVL có hạn sử dụng còn lại dưới 30 ngày tính từ ngày nhập. AC-041 (thuộc REQ-FUNC-016) GIVEN tôi đang ở màn hình tạo PNK WHEN tôi nhập Hạn sử dụng còn lại dưới 30 ngày THEN hệ thống báo lỗi "Hạn sử dụng không hợp lệ" và không cho lưu. DATA-ELEM-101 GoodsReceipt.batchNumber DATA-ELEM-102 GoodsReceipt.expiryDate TC-088 Kiểm tra việc từ chối NVL có HSD ngắn. DEF-012 Hệ thống từ chối sai khi HSD còn đúng 30 ngày. Lỗi logic so sánh (< thay vì <=).
NEED-001 (như trên) REQ-NFR-004 Mọi thao tác tạo/sửa/xóa PNK phải được ghi nhật ký (audit log) để phục vụ thanh tra. BR-AUD-002 Nhật ký phải ghi rõ: ID người dùng, thời gian, hành động (CREATE/UPDATE/DELETE), và ID của PNK bị tác động. AC-065 (thuộc REQ-NFR-004) GIVEN tôi đã tạo thành công PNK-2026-08-158 WHEN tôi truy vấn bảng audit_logs THEN tôi thấy một bản ghi với action='CREATE' và record_id='PNK-2026-08-158'. DATA-ELEM-210 audit_logs (table) DATA-ELEM-211 audit_logs.user_id TC-112 Xác minh bản ghi nhật ký được tạo sau khi tạo PNK thành công. N/A

Bảng này cho thấy cách một nhu cầu NEED-001 phân rã thành nhiều yêu cầu chức năng (REQ-FUNC) và phi chức năng (REQ-NFR). Mỗi yêu cầu lại được cụ thể hóa bằng quy tắc nghiệp vụ (BR) và tiêu chí chấp nhận (AC). Các thành phần dữ liệu và API hiện thực hóa chúng, và các ca kiểm thử (TC) xác minh chúng. Khi kiểm thử thất bại, một lỗi (DEF) được tạo ra và liên kết ngược lại, cho phép truy vết tác động từ lỗi đó lên tận nhu cầu kinh doanh ban đầu.

Phụ lục: Bảng Quyết Định và Dữ liệu Test

Phần này cung cấp một ví dụ cụ thể về kỹ thuật Phân tích Quy tắc Nghiệp vụ (Business Rules Analysis) thông qua một Bảng Quyết Định (Decision Table). Bảng Quyết Định là công cụ dùng để mô hình hóa logic nghiệp vụ phức tạp, đảm bảo mọi trường hợp đều được xem xét và không có sự mập mờ. Bảng này trực tiếp chuyển hóa các quy tắc nghiệp vụ thành các điều kiện và hành động rõ ràng, làm cơ sở vững chắc cho việc phát triển và kiểm thử hệ thống.

Bối cảnh là quy trình phê duyệt một Nhà Cung Cấp (NCC) mới cho Nova Foods, được theo vết từ yêu cầu REQ-PROCURE-004.

Bảng 4.1: Bảng Quyết Định cho Quy trình Phê duyệt Nhà Cung Cấp Mới

Bảng này ánh xạ các điều kiện đầu vào với các hành động đầu ra tương ứng, đảm bảo tính nhất quán trong việc ra quyết định. Mỗi cột "R" (Rule) đại diện cho một kịch bản có thể xảy ra.

ID Diễn giải Loại R1 R2 R3 R4 R5 R6
Điều kiện
C1 Hồ sơ pháp lý đầy đủ? (MST, GPKD) (BR-COMPLIANCE-011) Điều kiện Có Không Có Có Có Có
C2 Chứng nhận VSATTP hợp lệ & còn hạn? (BR-FOOD-SAFETY-001) Điều kiện Có - Không Có Có Có
C3 Năng lực tài chính đạt ngưỡng? (BR-FIN-SUP-002) Điều kiện Có - - Không Có Có
C4 Kết quả đánh giá xưởng sản xuất? (BR-QA-AUDIT-005) Điều kiện Đạt - - - Không Đạt Cần Cải Thiện
Hành động
A1 Cập nhật trạng thái NCC trong ERP Hành động Đã Phê Duyệt Từ Chối Từ Chối Chờ Xem Xét Từ Chối Chờ Khắc Phục
A2 Gửi email thông báo tự động cho NCC Hành động ✓ ✓ ✓ - ✓ ✓
A3 Tạo tác vụ cho Kế toán Trưởng Hành động - - - ✓ - -
A4 Tạo tác vụ cho Trưởng phòng Mua hàng Hành động - - - ✓ - ✓

Ghi chú: Dấu - (dash) trong bảng có nghĩa là điều kiện đó không cần xem xét để đưa ra quyết định cho quy tắc tương ứng. Đây là một kỹ thuật để đơn giản hóa bảng. Ví dụ, ở R2, nếu hồ sơ pháp lý đã không hợp lệ, hệ thống sẽ từ chối ngay lập tức mà không cần kiểm tra các điều kiện khác.

Bảng 4.2: Dữ liệu Test Tương ứng với Bảng Quyết Định

Dữ liệu test được tạo ra trực tiếp từ các quy tắc trong Bảng 4.1. Mỗi bộ dữ liệu test được thiết kế để kiểm tra một quy tắc cụ thể.

Test Case ID Quy tắc được Test Dữ liệu đầu vào (Mô phỏng) Kết quả mong đợi
TC-SUP-APPROVAL-001 R1 NCC "An Bình Foods" có đủ GPKD, MST; chứng nhận VSATTP còn hạn 12 tháng; báo cáo tài chính tốt; đánh giá xưởng đạt 95/100 điểm. Trạng thái NCC: APPROVED. Email thông báo phê duyệt được gửi.
TC-SUP-APPROVAL-002 R2 NCC "Tân Phát Farm" thiếu mã số thuế trong hồ sơ đăng ký. Trạng thái NCC: REJECTED. Email thông báo từ chối với lý do "Hồ sơ pháp lý không hợp lệ".
TC-SUP-APPROVAL-003 R3 NCC "Rau Sạch Hưng Thịnh" có hồ sơ pháp lý đầy đủ, nhưng chứng nhận VietGAP đã hết hạn 2 tuần. Trạng thái NCC: REJECTED. Email thông báo từ chối với lý do "Chứng nhận an toàn thực phẩm hết hạn".
TC-SUP-APPROVAL-004 R4 NCC "Gia Vị Việt" đạt mọi tiêu chí về pháp lý, VSATTP, sản xuất nhưng báo cáo tài chính cho thấy dòng tiền âm trong 2 quý liên tiếp. Trạng thái NCC: PENDING_REVIEW. Tạo tác vụ chuyển leo thang (escalation) đến Kế toán Trưởng và Trưởng phòng Mua hàng để xem xét đặc biệt. Không gửi email cho NCC.
TC-SUP-APPROVAL-005 R5 Đánh giá xưởng của NCC "Thủy sản Minh Long" phát hiện vi phạm nghiêm trọng về quy trình xử lý chất thải. Trạng thái NCC: REJECTED. Email thông báo từ chối với lý do "Không đạt đánh giá cơ sở sản xuất".
TC-SUP-APPROVAL-006 R6 Đánh giá xưởng của NCC "Nông sản Vàng" đạt các tiêu chí chính, nhưng khu vực đóng gói cần cải thiện về vệ sinh. Điểm: 78/100. Trạng thái NCC: PENDING_CORRECTIVE_ACTION. Email yêu cầu NCC nộp kế hoạch hành động khắc phục. Tạo tác vụ cho Trưởng phòng Mua hàng theo dõi.

5. Tier 4 – Cổng chất lượng BA cấp cao

Mục này là cổng chất lượng. Senior BA dùng để duyệt phân tích quy trình. Đảm bảo chất lượng trước khi baseline. Không qua cổng này, artifact không đi tiếp.

Nguyên tắc đánh giá

  • Đạt (Pass): Toàn bộ tiêu chí được đáp ứng. Không có lỗi nghiêm trọng. Artifact sẵn sàng cho bước tiếp theo.
  • Không Đạt (Fail): Có lỗi nghiêm trọng, sai lệch lớn hoặc thiếu thông tin cốt lõi. Phải sửa lại. Ví dụ: Sơ đồ mâu thuẫn với mô tả văn bản, hoặc tiêu chí chấp nhận không thể kiểm thử.
  • Chuyển Leo Thang (Escalate): Vấn đề nằm ngoài thẩm quyền của BA. Cần ý kiến của chuyên gia hoặc người có thẩm quyền khác (ví dụ: Pháp lý, Kế toán, Kiến trúc sư, Business Owner). Artifact bị tạm giữ cho đến khi vấn đề được giải quyết.
  • Dừng (Stop): Toàn bộ quy trình duyệt bị Dừng nếu có bất kỳ một mục nào bị đánh giá là Không Đạt, hoặc có từ 3 mục trở lên cần Chuyển Leo Thang. Yêu cầu làm lại đáng kể trước khi trình duyệt lại.

Danh sách kiểm tra chất lượng (Quality Checklist)

Bảng này là công cụ để Senior BA đánh giá một tài liệu phân tích quy trình. Mỗi mục phải được xem xét kỹ lưỡng.

ID Hạng mục kiểm tra Tiêu chí đánh giá & Kết quả có thể có
QG-PROC-01 Tính đầy đủ (Completeness) Tiêu chí: Mọi phần bắt buộc của template phải được điền đầy đủ, không có mục trống. Sơ đồ quy trình phải có điểm bắt đầu và kết thúc rõ ràng. Tất cả tác nhân, bước xử lý, luồng đi, quyết định, đầu vào và đầu ra phải được xác định.
Kết quả: Đạt / Không Đạt
QG-PROC-02 Tính nhất quán (Consistency) Tiêu chí: Thuật ngữ sử dụng trong tài liệu phải nhất quán và tuân thủ CANONICAL_DATA_DICTIONARY. Các quy tắc nghiệp vụ phải khớp với định nghĩa trong CANONICAL_BUSINESS_RULES. Thông tin trên sơ đồ (ví dụ: BPMN) phải khớp 100% với mô tả chi tiết trong văn bản.
Kết quả: Đạt / Không Đạt
QG-PROC-03 Tính khả kiểm (Testability) Tiêu chí: Mọi tiêu chí chấp nhận (Acceptance Criteria) phải SMART (Cụ thể, Đo lường được, Khả thi, Liên quan, Có giới hạn thời gian). Đội ngũ QA phải có thể dựa vào các tiêu chí này để viết test case mà không cần phải đặt thêm giả định. (Nguồn tham chiếu: ISTQB CTFL).
Kết quả: Đạt / Không Đạt
QG-PROC-04 Khả năng truy vết (Traceability) Tiêu chí: Mọi yêu cầu (REQ-), quy tắc nghiệp vụ (BR-), và phần tử dữ liệu quan trọng (DATA-) phải có định danh duy nhất từ TRACEABILITY_ID_REGISTRY. Phải có khả năng truy vết từng yêu cầu về nguồn gốc của nó (ví dụ: một cuộc họp, một email từ business owner, một điều khoản pháp lý). (Nguồn tham chiếu: ISO/IEC/IEEE 29148).
Kết quả: Đạt / Không Đạt
QG-PROC-05 Thẩm quyền nguồn (Source Authority) Tiêu chí: Nguồn gốc của các ràng buộc nghiệp vụ quan trọng (đặc biệt là các ràng buộc pháp lý, tài chính, an toàn) phải được ghi rõ và xác minh. Ví dụ: một quy tắc về hóa đơn điện tử phải tham chiếu đến Nghị định 123/2020/NĐ-CP và phải có nhãn Verification required by Accounting Owner. BA không được tự diễn giải luật hoặc các quy định phức tạp.
Kết quả: Đạt / Không Đạt / Chuyển Leo Thang
QG-PROC-06 Quyền sở hữu (Ownership) Tiêu chí: Phải xác định rõ ai là Chủ sở hữu nghiệp vụ (Business Owner) của toàn bộ quy trình. Phải rõ ai là người có thẩm quyền ra quyết định cuối cùng khi có mâu thuẫn hoặc yêu cầu thay đổi.
Kết quả: Đạt / Không Đạt / Chuyển Leo Thang
QG-PROC-07 Ranh giới Bảo mật & Riêng tư Tiêu chí: Các bước xử lý dữ liệu cá nhân (PII) phải được đánh dấu. Các rủi ro bảo mật tiềm ẩn (tham chiếu OWASP API Security Top 10 nếu có API) phải được xác định. Ranh giới truy cập dữ liệu giữa các vai trò/hệ thống phải được làm rõ. (Nguồn tham chiếu pháp lý: Luật Bảo vệ dữ liệu cá nhân).
Kết quả: Đạt / Không Đạt / Chuyển Leo Thang
QG-PROC-08 Ranh giới Pháp lý & Kế toán Tiêu chí: Các bước có ảnh hưởng đến nghĩa vụ pháp lý (ví dụ: khai báo, báo cáo) hoặc ghi nhận sổ sách kế toán phải được đánh dấu rõ ràng. Tài liệu phải nêu rõ các điểm này cần được phê duyệt bởi Phòng Pháp lý hoặc Phòng Kế toán.
Kết quả: Đạt / Chuyển Leo Thang
QG-PROC-09 Tác động thay đổi (Change Impact) Tiêu chí: Phân tích phải xác định và mô tả tác động của quy trình mới/thay đổi lên các quy trình, hệ thống, hoặc phòng ban khác đang tồn tại. Mức độ tác động phải được ước tính (ví dụ: Cao, Trung bình, Thấp) để các bên liên quan có thể chuẩn bị.
Kết quả: Đạt / Không Đạt

Các hạng mục chất lượng cốt lõi và tiêu chí đánh giá

Bảng này định nghĩa các tiêu chí chất lượng cho việc xem xét tài liệu phân tích quy trình. Mỗi hạng mục là một cổng kiểm soát chất lượng (quality gate) mà tài liệu phải vượt qua trước khi được xem xét baseline.

Hạng mục kiểm tra Tiêu chí đánh giá chi tiết Nguồn tham chiếu / Lý do
Tính đầy đủ (Completeness) Phân tích phải bao gồm tất cả các thành phần cần thiết: mục tiêu quy trình, vai trò tham gia, điều kiện bắt đầu, điều kiện kết thúc, các bước chính, các luồng ngoại lệ, dữ liệu đầu vào và sản phẩm đầu ra. Không có bước nào được ghi là "TBD" (To Be Determined - Sẽ xác định sau). Một quy trình thiếu sót dẫn đến yêu cầu không đầy đủ, gây ra lỗi trong quá trình phát triển và kiểm thử. Phải đảm bảo bức tranh toàn cảnh được mô tả.
Tính nhất quán (Consistency) Thuật ngữ, định danh (ID), và quy tắc nghiệp vụ phải nhất quán trong toàn bộ tài liệu và khớp với các artifact khác của corpus như Từ điển Dữ liệu (CANONICAL_DATA_DICTIONARY) và Catalog Quy tắc (CANONICAL_BUSINESS_RULES). Sự mâu thuẫn tạo ra sự mơ hồ, dẫn đến việc các đội (phát triển, kiểm thử, nghiệp vụ) hiểu sai yêu cầu. Nguồn chân lý (single source of truth) phải được tôn trọng.
Tính kiểm thử được (Testability) Mỗi yêu cầu chức năng hoặc quy tắc nghiệp vụ phải được diễn đạt đủ rõ ràng và cụ thể để một QA/Tester có thể viết các ca kiểm thử (test case) tương ứng. Tiêu chí chấp nhận (acceptance criteria) phải có thể xác minh được (ví dụ: "Hệ thống phải phản hồi trong vòng 2 giây", thay vì "Hệ thống phải nhanh"). Yêu cầu không thể kiểm thử là yêu cầu không thể hoàn thành. Tiêu chí phải định lượng được để xác nhận thành công hay thất bại. Tham chiếu syllabus ISTQB CTFL v4.0.1.
Khả năng truy vết (Traceability) Mọi yêu cầu phải có khả năng truy vết ngược về nguồn gốc (ví dụ: yêu cầu nghiệp vụ, quy định pháp lý) và truy vết xuôi tới các artifact sau này (ví dụ: thiết kế, test case). Mỗi yêu cầu phải có một định danh duy nhất từ TRACEABILITY_ID_REGISTRY. Truy vết đảm bảo không có yêu cầu "mồ côi" và mọi thay đổi đều được quản lý tác động. Tuân thủ nguyên tắc từ ISO/IEC/IEEE 29148.
Thẩm quyền nguồn (Source Authority) Nguồn gốc của các quy tắc và ràng buộc phải được xác định rõ ràng và có thẩm quyền. Ví dụ, quy tắc kế toán phải đến từ phòng kế toán hoặc Luật Kế toán, quy định bảo mật phải tham chiếu chuẩn ngành (OWASP) hoặc luật định. Một yêu cầu dựa trên ý kiến cá nhân hoặc nguồn không chính thống không có giá trị. Phải dựa trên nguồn có thẩm quyền để đảm bảo tính đúng đắn và tuân thủ.
Quyền sở hữu (Ownership) Phải xác định rõ ai là chủ sở hữu quy trình (Business Process Owner) và ai chịu trách nhiệm phê duyệt các quyết định liên quan. Vai trò này phải là một vai trò nghiệp vụ, không phải BA hay đội dự án. Không có chủ sở hữu, quy trình sẽ không có ai chịu trách nhiệm về hiệu quả hoạt động và quyết định cuối cùng khi có tranh chấp hoặc thay đổi.
Ranh giới (Boundaries) Phân tích phải xác định và tôn trọng các ranh giới quan trọng:
- Bảo mật/Riêng tư: Dữ liệu nhạy cảm (PII) phải được đánh dấu và xử lý theo quy định của Luật Bảo vệ dữ liệu cá nhân (Luật 91/2025/QH15).
- Pháp lý/Kế toán: Các bước liên quan đến hóa đơn, chứng từ, báo cáo thuế phải tuân thủ Luật Kế toán và Nghị định 123/2020/NĐ-CP.
- An toàn thực phẩm: Các bước liên quan truy xuất nguồn gốc phải xem xét yêu cầu của Luật An toàn thực phẩm 55/2010/QH12.		 Vượt qua các ranh giới này có thể gây ra rủi ro pháp lý, tài chính hoặc vận hành nghiêm trọng cho doanh nghiệp. BA có trách nhiệm nhận diện và gắn cờ các khu vực này để chuyên gia xem xét.
Tác động thay đổi (Change Impact) Phân tích phải đánh giá tác động của quy trình mới hoặc quy trình được thay đổi đến các hệ thống, quy trình, vai trò và bộ phận khác trong tổ chức. Phải có một danh sách các bên liên quan bị ảnh hưởng. Bỏ qua phân tích tác động có thể gây gián đoạn hoạt động ở những nơi không ngờ tới. Việc quản lý thay đổi (change management) bắt đầu từ việc nhận diện đúng các đối tượng bị ảnh hưởng.

Áp dụng Checklist vào Case Study Nova Foods

Bảng dưới đây ghi nhận kết quả áp dụng checklist kiểm soát chất lượng của Senior BA lên ví dụ phân tích quy trình Mua hàng đến Thanh toán (Procure-to-Pay) đã hoàn thiện tại Tier 3. Đây là ghi nhận xem xét, không phải phê duyệt. Trạng thái của tài liệu này vẫn là IN_REVIEW. Dữ liệu Nova Foods là mô phỏng cho mục đích giáo dục.

Hạng mục kiểm tra Tiêu chí Kết quả Ghi chú và Bằng chứng Hành động đề xuất
1. Tính đầy đủ (Completeness) Mọi mục trong template Tier 2 đã được điền đầy đủ dữ liệu mô phỏng Nova Foods tại Tier 3. Pass Tất cả các trường chính đã có dữ liệu. Luồng quy trình, vai trò, business rule và dữ liệu vào/ra đều được định nghĩa. Không cần hành động.
2. Tính nhất quán (Consistency) Thuật ngữ, định danh (ID), và quy tắc nghiệp vụ (business rule) nhất quán trong tài liệu và với các artifact canonical của corpus. Pass Định danh quy trình PROC-P2P-01 và các quy tắc BR-P2P-TAX-01, BR-P2P-INV-02 khớp với /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CANONICAL_BUSINESS_RULES.md. Không cần hành động.
3. Tính khả kiểm (Testability) Mỗi yêu cầu và tiêu chí chấp nhận (acceptance criteria) đều có thể được xác minh một cách khách quan, không mơ hồ. Fail Tiêu chí chấp nhận AC-P2P-UI-05 ghi: "Giao diện người dùng phải thân thiện và dễ sử dụng". Đây là tiêu chí chủ quan, không đo lường được. STOP. Yêu cầu viết lại AC-P2P-UI-05 theo hướng có thể kiểm chứng, ví dụ: "Người dùng mới có thể hoàn thành tác vụ tạo đơn hàng trong vòng 5 phút mà không cần hướng dẫn, với tỷ lệ thành công 90% trong User Acceptance Test."
4. Khả năng truy vết (Traceability) Mọi quy tắc, yêu cầu, dữ liệu đều có thể truy vết về nguồn gốc (ví dụ: phỏng vấn, luật, tài liệu nghiệp vụ). Pass Bảng "Evidence and Traceability" đã liên kết yêu cầu REQ-P2P-007 về hóa đơn điện tử với Nghị định 123/2020/NĐ-CP (Source ID: SRC-LEGAL-VN-004). Không cần hành động.
5. Thẩm quyền nguồn & Ownership Vai trò Owner cho mỗi quy tắc nghiệp vụ và quyết định được xác định rõ ràng và phù hợp với thẩm quyền chuyên môn. Fail Quy tắc BR-P2P-TAX-01 (Tính thuế GTGT đầu vào) được gán Owner là Business Analyst. Đây là sai thẩm quyền. Thẩm quyền về thuế phải thuộc về Kế toán. STOP. Escalation đến Accounting Owner. Yêu cầu Accounting Owner xác nhận quy tắc và chính thức nhận quyền sở hữu. Cập nhật lại vai trò Owner trong tài liệu.
6. Ranh giới (Bảo mật, Pháp lý, Kế toán) Các ranh giới về bảo mật, pháp lý, kế toán được xác định. Dữ liệu nhạy cảm được đánh dấu và có tham chiếu đến chính sách bảo vệ. Pass Dữ liệu nhà cung cấp (thông tin tài khoản ngân hàng, mã số thuế) được phân loại Confidential theo /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Có tham chiếu OWASP API Security Top 10:2023 cho các API liên quan. Xác nhận với Security Owner về các biện pháp kiểm soát cụ thể sẽ được áp dụng trong giai đoạn thiết kế kỹ thuật.
7. Tác động thay đổi (Change Impact) Phân tích tác động đến các quy trình, hệ thống, và vai trò người dùng khác đã được thực hiện ở mức độ ban đầu. Pass Đã xác định quy trình Quản lý Tồn kho (Inventory Management) và vai trò Nhân viên kho bị ảnh hưởng khi thay đổi quy trình nhận hàng (Goods Receipt). Thông báo cho Inventory Process Owner về thay đổi đã được ghi nhận để chuẩn bị cho phân tích chi tiết ở giai đoạn sau.

Tổng kết kết quả xem xét:

Tài liệu có cấu trúc và khả năng truy vết tốt. Tuy nhiên, có hai điểm STOP nghiêm trọng cần được giải quyết trước khi có thể xem xét chuyển sang trạng thái BASELINED: 1. Yêu cầu không thể kiểm chứng: Tiêu chí chấp nhận AC-P2P-UI-05 mang tính chủ quan. 2. Sai thẩm quyền: Quy tắc nghiệp vụ về thuế BR-P2P-TAX-01 bị gán sai Owner.

Các hành động này phải được hoàn thành và ghi nhận lại kết quả. Tài liệu tiếp tục được giữ ở trạng thái IN_REVIEW.

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

Mục này thực hiện kiểm tra chéo (cross-file checks) để đảm bảo tính nhất quán của tài liệu phân tích quy trình này với các nguồn thông tin chuẩn (canonical sources) khác trong kho tài liệu của dự án. Việc này là một bước kiểm soát chất lượng quan trọng trước khi chuyển giao tài liệu, nhằm phát hiện và xử lý sớm các mâu thuẫn, ngăn ngừa lỗi lan truyền sang các giai đoạn sau như thiết kế kỹ thuật, kiểm thử, và triển khai. Mỗi kiểm tra được thực hiện trên một bản sao của tài liệu này (phiên bản v0.9.0 cho quy trình Procure-to-Pay của case study Nova Foods) và đối chiếu với các artifact quản trị trung tâm.

Bảng kết quả kiểm tra chéo (Cross-File Check Result Matrix) Ngày thực hiện: 2026-08-07 Người thực hiện: Senior Business Analyst

ID Kiểm tra Artifact Nguồn Chuẩn (Canonical Source) Nội dung Kiểm tra Kết quả (Case Nova Foods) Hành động Khắc phục / Ghi chú
XCHK-01 /01-curriculum/TRACEABILITY_ID_REGISTRY.md Tất cả định danh (ID) được sử dụng trong tài liệu này (ví dụ: PROC-, BR-, AC-, ROLE-) phải được đăng ký và tuân thủ quy tắc định dạng trong sổ đăng ký định danh. Pass Đã đối chiếu tất cả ID sử dụng trong tài liệu phân tích quy trình Mua hàng (P2P), bao gồm PROC-P2P-001, BR-P2P-INV-01, AC-P2P-INV-01, ROLE-AP-CLERK. Các ID đều hợp lệ và đã được đăng ký.
XCHK-02 /01-curriculum/CANONICAL_BUSINESS_RULES.md Các quy tắc nghiệp vụ (BR-) được tham chiếu hoặc định nghĩa phải khớp với phiên bản, nội dung, và Owner được ghi nhận trong danh mục quy tắc nghiệp vụ chuẩn. Không được tự diễn giải hoặc định nghĩa lại quy tắc đã có. FAIL Phát hiện mâu thuẫn nghiêm trọng. Quy tắc BR-P2P-TAX-01 trong tài liệu này có ghi chú "mặc định thuế GTGT 10%". Tuy nhiên, trong catalog chuẩn, quy tắc này chỉ tham chiếu đến nguồn pháp lý (Nghị định 123/2020/NĐ-CP) và ghi rõ "áp dụng theo luật thuế hiện hành". Việc ghi cứng "10%" là một diễn giải nghiệp vụ sai thẩm quyền và tạo ra rủi ro tuân thủ khi luật thay đổi.
XCHK-03 /01-curriculum/CANONICAL_DATA_DICTIONARY.md Tên các trường dữ liệu (data fields) được sử dụng trong yêu cầu và quy tắc (ví dụ: supplier_tax_code, invoice_amount) phải khớp chính xác với tên, kiểu dữ liệu, và mô tả trong từ điển dữ liệu chuẩn. Pass Các trường dữ liệu chính như supplier_id, invoice_date, payment_term, invoice_total_amount đều khớp với định nghĩa trong từ điển dữ liệu. Không phát hiện việc định nghĩa trường dữ liệu mới hoặc sử dụng tên tùy chỉnh.
XCHK-04 /01-curriculum/CHAPTER_MANIFEST.md
/01-curriculum/TEMPLATE_MANIFEST.md		 Vai trò và phạm vi của tài liệu này phải nhất quán với kiến trúc chương trình học và danh mục mẫu biểu đã được hoạch định. Pass Tài liệu này là một bản thể hiện (instance) của TMPL-PROC-001 như đã đăng ký. Mục đích phân tích quy trình Procure-to-Pay của Nova Foods hoàn toàn phù hợp với cấu trúc học liệu được mô tả trong các manifest.
XCHK-05 Các artifact hạ nguồn (Downstream Consumers) - ví dụ: kế hoạch kiểm thử, đặc tả API. Các quyết định ghi trong tài liệu này (đặc biệt là tiêu chí chấp nhận - Acceptance Criteria) phải có khả năng được kiểm chứng và không tạo ra bế tắc cho các đội ngũ sau này (QA, Development). Warning Tiêu chí chấp nhận AC-P2P-UI-05 ("Giao diện phải thân thiện, dễ sử dụng") mang tính chủ quan cao, không thể lượng hóa. Điều này sẽ khiến đội QA không thể xây dựng được kịch bản kiểm thử (test case) rõ ràng và có thể dẫn đến tranh cãi khi nghiệm thu. Đây là một rủi ro tiềm tàng cho quá trình phát triển.

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

Đây là sổ theo dõi các điểm chưa chốt trong tài liệu. Giả định Dự án là điều ta tạm coi là đúng để tiếp tục, nhưng phải xác nhận. Cần Xác minh là mục đòi hỏi chuyên gia (pháp lý, kế toán) ra quyết định cuối cùng. Bảng này đảm bảo mọi thứ được bàn giao có kiểm soát, không có quyết định ngầm.

ID Vấn đề Phân loại Mô tả & ID Bị ảnh hưởng Owner Chuyên môn Mức độ Ảnh hưởng Hành động Tiếp theo & Ngày mục tiêu
ISSUE-PROC-001 Giả định Dự án Quy tắc nghiệp vụ BR-ACC-015 (tính thuế GTGT cho hàng khuyến mãi) được giả định là phù hợp với Nghị định 123/2020/NĐ-CP. Quy tắc này ảnh hưởng trực tiếp đến logic xử lý trong TMPL-PROC-001 và CANONICAL_BUSINESS_RULES. Accounting Owner Cao Chuyển cho Accounting Owner để xem xét và xác nhận chính thức. Mục tiêu: 2026-08-21.
ISSUE-PROC-002 Cần Xác minh Trường dữ liệu DDE-CUST-005 (số điện thoại khách hàng) được phân loại là dữ liệu cá nhân nhạy cảm theo Luật 91/2025/QH15. Việc này đòi hỏi quy trình thu thập sự đồng ý rõ ràng. Ảnh hưởng: CANONICAL_DATA_DICTIONARY, các quy trình liên quan đến khách hàng. Legal Owner / DPO Cao Gửi trích đoạn từ điển dữ liệu và sơ đồ quy trình cho Legal Owner để thẩm định pháp lý. Mục tiêu: 2026-08-28.
ISSUE-PROC-003 Cần Xác minh Cơ chế truy xuất nguồn gốc lô hàng đề xuất trong quy trình PROC-WH-RECEIVING-01 (Nhận hàng) cần được xác minh tính tuân thủ với Luật 55/2010/QH12 và khả năng kỹ thuật của hệ thống WMS. Ảnh hưởng: TMPL-PROC-001, BR-TRACE-001, DDE-INV-050. Production Owner & QA Owner Cao Tổ chức buổi làm việc với Production và QA để xác thực luồng quy trình. Mục tiêu: 2026-09-04.
ISSUE-PROC-004 Giả định Dự án Quy trình giả định rằng API tích hợp nhà cung cấp API-SUP-001 sẽ triển khai cơ chế kiểm soát xác thực và phân quyền theo OWASP API Security Top 10 (2023), cụ thể là API1:2023 Broken Object Level Authorization. Ảnh hưởng đến mọi yêu cầu phi chức năng (NFR). Technical Architect Trung bình Yêu cầu Technical Architect xem xét và phê duyệt các NFR liên quan đến API-SUP-001. Mục tiêu: 2026-08-25.
ISSUE-PROC-005 Cần Xác minh Định dạng và thời hạn lưu trữ cho "Chứng từ khấu trừ thuế TNCN" được tạo ra bởi quy trình PROC-HR-PAYROLL phải được Accounting Owner xác nhận dựa trên các thông tư hướng dẫn Luật Kế toán 88/2015/QH13 hiện hành. Ảnh hưởng: CANONICAL_DATA_DICTIONARY, BR-ACC-021. Accounting Owner Trung bình Lập yêu cầu làm rõ gửi Accounting Owner kèm theo ví dụ chứng từ đề xuất. Mục tiêu: 2026-09-10.

Quy tắc Bàn giao, Lan truyền Thay đổi và Ranh giới Thẩm quyền

Tài liệu này bàn giao để xem xét. Không cho mục đích khác. Trạng thái giữ nguyên IN_REVIEW. Không phải APPROVED hoặc BASELINED. Mọi nội dung Nova Foods là mô phỏng, cần xác minh bởi vai trò có thẩm quyền.

Bảng 6.3.1: Quy tắc bàn giao tài liệu ở trạng thái IN_REVIEW

Bảng này xác định cách tài liệu được chia sẻ trong giai đoạn xem xét mà không thay đổi trạng thái hoặc phá vỡ ranh giới thẩm quyền.

Điều kiện Bàn giao Bên nhận (Receiver) Mục đích Bàn giao Trạng thái Artifact sau Bàn giao
Bản nháp phân tích quy trình hoàn tất. Senior BA Reviewer Xem xét chất lượng và tính đầy đủ theo tiêu chí tại Mục 5 (Senior BA Quality Gate). Giữ nguyên IN_REVIEW
Cần xác minh quy tắc hoặc dữ liệu nghiệp vụ chuyên sâu. Chủ sở hữu Nghiệp vụ (Business Owner) / Chuyên gia (Subject Matter Expert - SME) Xác thực tính đúng đắn của logic nghiệp vụ, dữ liệu, hoặc quy tắc trong phạm vi của họ. Giữ nguyên IN_REVIEW
Cần đánh giá khả thi hoặc tác động kỹ thuật. Kiến trúc sư Kỹ thuật (Technical Architect) Đánh giá tính khả thi kỹ thuật, ước tính tác động đến hệ thống ERP, và xác định các ràng buộc. Giữ nguyên IN_REVIEW
Cần xác minh tính tuân thủ pháp lý, kế toán. Chủ sở hữu Pháp lý (Legal Owner) / Kế toán (Accounting Owner) Xác minh các diễn giải và yêu cầu tuân thủ có nguồn gốc từ luật định (ví dụ: Luật Kế toán 88/2015/QH13). Giữ nguyên IN_REVIEW

Quy trình Lan truyền Thay đổi (Change Propagation)

Thay đổi trong giai đoạn IN_REVIEW phải tuân thủ quy tắc nghiêm ngặt để bảo toàn truy vết.

  1. Ghi nhận Vấn đề: Mọi yêu cầu thay đổi phải được ghi nhận là một "Vấn đề mở" (Open Issue) tại mục 6.2 của tài liệu này. Mỗi vấn đề có một ID duy nhất.
  2. Liên kết Truy vết: ID của vấn đề mở phải liên kết trực tiếp đến (các) định danh của thành phần bị ảnh hưởng (ví dụ: yêu cầu thay đổi quy tắc BR-PROC-005 phải ghi rõ ID này).
  3. Leo thang Thẩm quyền: Thay đổi vượt thẩm quyền của IT Business Analyst (ví dụ: diễn giải pháp lý, quyết định kiến trúc) phải được leo thang (escalate) đến vai trò Owner phù hợp. BA chỉ ghi nhận quyết định của Owner, không tự quyết.
  4. Quản lý Phiên bản: Một thay đổi nội dung quan trọng, sau khi được Owner thẩm quyền xác nhận, sẽ kích hoạt việc tăng phiên bản phụ (minor version) của tài liệu (ví dụ: từ v0.9.0 lên v0.9.1). Thay đổi này phải được ghi nhận trong lịch sử phiên bản của artifact.

Bảo toàn Ranh giới Thẩm quyền

Việc bàn giao để xem xét không phải là chuyển giao thẩm quyền.

Vai trò Phạm vi Thẩm quyền trong Giai đoạn Review Hành động Bị cấm tại Giai đoạn IN_REVIEW
IT Business Analyst (Template Owner) Ghi nhận yêu cầu, phân tích quy trình, điều phối xem xét, duy trì quản trị artifact. Tự phê duyệt quy tắc nghiệp vụ; xác nhận tuân thủ pháp lý/kế toán; quyết định kiến trúc cuối cùng.
Reviewer (Senior BA, Peer) Cung cấp phản hồi về chất lượng, tính rõ ràng, tính đầy đủ, và sự tuân thủ template. Đưa ra quyết định nghiệp vụ cuối cùng thay cho Business Owner; phê duyệt tài liệu.
Business Owner / SME Xác nhận hoặc hiệu chỉnh logic, quy tắc và dữ liệu nghiệp vụ thuộc lĩnh vực của mình là chính xác. Thay đổi cấu trúc template; thay đổi quy tắc quản trị của corpus; tự phê duyệt các yêu cầu ngoài phạm vi.
Technical Architect Đánh giá tính khả thi kỹ thuật và đề xuất các giải pháp kỹ thuật phù hợp với yêu cầu. Thay đổi yêu cầu nghiệp vụ cốt lõi; xác nhận một quy trình nghiệp vụ mà không có sự đồng thuận từ Business Owner.

Kết luận Bàn giao: Tài liệu TMPL-PROC-001 phiên bản v0.9.0 này được bàn giao dưới dạng bản nháp có kiểm soát. Việc chuyển nó sang trạng thái BASELINED hoặc APPROVED là một quy trình quản trị riêng, yêu cầu bằng chứng phê duyệt chính thức từ tất cả các vai trò có thẩm quyền liên quan, và phải được ghi nhận trong các artifact quản trị trung tâm như TEMPLATE_MANIFEST.