Bỏ qua

/03-templates/TMPL-INT-001_integration-mapping.md — Mẫu Đặc Tả Tích Hợp (Integration Mapping)

Bảng dưới đây là metadata quản trị (governance metadata) cho tài liệu này. Metadata này xác định danh tính, phiên bản, chủ sở hữu và các quy tắc kiểm soát của tài liệu, đảm bảo nó được sử dụng đúng mục đích và có thể truy vết được trong toàn bộ vòng đời dự án. Đây là một khái niệm nền tảng trong quản trị tài liệu chuyên nghiệp.

Trường kiểm soát Giá trị Diễn giải và Trách nhiệm
Artifact ID TMPL-INT-001 Mã định danh duy nhất và không thay đổi của tài liệu mẫu này trong toàn bộ corpus. Mọi tham chiếu đến mẫu này phải sử dụng ID này để đảm bảo tính nhất quán.
Tên tệp được kiểm soát /03-templates/TMPL-INT-001_integration-mapping.md Đường dẫn canonical (chính tắc) của tài liệu. Các bản sao hoặc bản xuất khác không được coi là nguồn chân lý (source of truth).
Tiêu đề Mẫu Đặc Tả Tích Hợp (Integration Mapping) Tên gọi đầy đủ của tài liệu. "Integration Mapping" là quá trình đặc tả chi tiết cách dữ liệu di chuyển và được chuyển đổi giữa hai hay nhiều hệ thống.
Trạng thái (Status) IN_REVIEW Tài liệu đang trong giai đoạn xem xét nội bộ. Nội dung có thể thay đổi và chưa được phê duyệt chính thức (approved) hay chốt phiên bản (baselined) để sử dụng.
Phiên bản (Version) v0.9.0 Phiên bản hiện tại của tài liệu. Mọi thay đổi quan trọng sau khi được phê duyệt sẽ yêu cầu tăng số phiên bản theo quy trình quản lý thay đổi.
Chủ sở hữu (Owner) Principal IT Business Analyst / Technical Curriculum Author Vai trò chịu trách nhiệm duy trì tính toàn vẹn của cấu trúc và metadata của mẫu này. Owner không có thẩm quyền phê duyệt nội dung nghiệp vụ.
Ngày cập nhật gần nhất 2026-08-07 Ngày cuối cùng tài liệu này được chỉnh sửa. Luôn được ghi nhận theo múi giờ Asia/Ho_Chi_Minh.
Ranh giới dữ liệu Chỉ sử dụng dữ liệu tổng hợp (synthetic data) Mọi dữ liệu (tên khách hàng, mã sản phẩm, số liệu tài chính...) trong các ví dụ của Nova Foods đều là giả lập cho mục đích đào tạo. Nghiêm cấm sử dụng hoặc suy diễn thành dữ liệu thực tế.

Lịch sử thay đổi (Change History)

Phiên bản Ngày Người thực hiện Tóm tắt thay đổi
v0.9.0 2026-08-07 Principal IT BA / Technical Curriculum Author Khởi tạo tài liệu mẫu ở trạng thái IN_REVIEW. Thiết lập metadata quản trị ban đầu, xác định cấu trúc 4 tầng và phạm vi sử dụng cho case study Nova Foods.

1. Tier 1 – Metadata, Purpose, and Governance

Mục đích, Phạm vi và Quản trị

Mục đích chính của tài liệu "Đặc tả Ánh xạ Tích hợp" (Integration Mapping) là tạo ra một nguồn chân lý (single source of truth) duy nhất, chi tiết và không mơ hồ cho việc di chuyển dữ liệu giữa hai hệ thống phần mềm. Cụ thể trong bối cảnh Nova Foods, tài liệu này đặc tả chính xác cách dữ liệu từ một hệ thống nguồn (ví dụ: hệ thống Quản lý Kho - WMS) được ánh xạ, chuyển đổi và tải vào một hệ thống đích (ví dụ: hệ thống ERP trung tâm). Nó định nghĩa ánh xạ ở cấp độ từng trường dữ liệu (field-level), bao gồm các quy tắc chuyển đổi (transformation rules), kiểu dữ liệu, định dạng, và cách xử lý các trường hợp ngoại lệ như giá trị rỗng (null) hoặc lỗi. Tài liệu này đảm bảo rằng các bên liên quan—từ Business Analyst, đội ngũ phát triển (Development Team), đội ngũ đảm bảo chất lượng (QA Team) đến các bên liên quan nghiệp vụ (Business Stakeholders)—đều có chung một sự hiểu biết thống nhất, giảm thiểu rủi ro hiểu sai và lỗi trong quá trình triển khai tích hợp.

Khi nào sử dụng mẫu này: * Thiết kế tích hợp mới: Khi cần kết nối hai hệ thống chưa từng trao đổi dữ liệu với nhau, ví dụ: tích hợp ERP với một nền tảng thương mại điện tử (e-commerce) mới. * Sửa đổi tích hợp hiện có: Khi có thay đổi lớn về logic nghiệp vụ hoặc cấu trúc dữ liệu của một tích hợp đang hoạt động. Ví dụ: thay đổi cấu trúc API truyền dữ liệu tồn kho giữa WMS và ERP. * Kiểm toán hoặc gỡ bỏ tích hợp: Khi cần phân tích một tích hợp để kiểm tra tính tuân thủ, truy vết dữ liệu, hoặc để hiểu rõ các phụ thuộc trước khi gỡ bỏ (decommission).

Khi nào không sử dụng mẫu này: * Để đặc tả giao diện người dùng (UI): Sử dụng tài liệu đặc tả UI/UX. * Để vẽ luồng quy trình nghiệp vụ cấp cao: Sử dụng sơ đồ BPMN (Business Process Model and Notation) trong các tài liệu như BRD. * Để định nghĩa mô hình dữ liệu logic của một hệ thống: Sử dụng "Từ điển Dữ liệu Canonical" (CANONICAL_DATA_DICTIONARY). Mẫu này dùng để ánh xạ giữa các hệ thống, không phải để định nghĩa dữ liệu bên trong một hệ thống. * Để liệt kê danh sách các điểm cuối API (API endpoints) mà không có ánh xạ chi tiết: Sử dụng một tài liệu đặc tả API tổng quan, ví dụ như định dạng OpenAPI Specification (OAS).

Bảng dưới đây tóm tắt các khía cạnh quản trị quan trọng đối với mỗi tài liệu ánh xạ tích hợp được tạo ra từ mẫu này.

Trường Quản trị (Governance Field) Giá trị / Quy tắc (Value / Rule)
Owner (Người chịu trách nhiệm) Business Analyst được phân công chính thức cho luồng tích hợp tương ứng.
Consumers (Đối tượng sử dụng) - Development Team: Dùng để xây dựng logic tích hợp.
- QA/QC Team: Dùng để tạo kịch bản kiểm thử (test case) và xác minh dữ liệu.
- Technical Architect: Dùng để xem xét, phê duyệt về mặt kiến trúc và kỹ thuật.
- Business Stakeholders: Dùng để xác nhận rằng các quy tắc nghiệp vụ được áp dụng đúng.
- Data Governance Team: Dùng để kiểm tra tính tuân thủ các chính sách dữ liệu của tổ chức.
Prerequisites (Điều kiện tiên quyết) - Phải có Tài liệu Yêu cầu Nghiệp vụ (Business Requirements Document - BRD) đã được xem xét.
- Phải tham chiếu đến "Từ điển Dữ liệu Canonical" (CANONICAL_DATA_DICTIONARY) cho các thực thể dữ liệu liên quan.
- Phải có đặc tả kỹ thuật sơ bộ (ví dụ: đặc tả API) từ cả hệ thống nguồn và hệ thống đích.
- Phải có định danh tích hợp (Integration ID) đã được đăng ký trong sổ định danh TRACEABILITY_ID_REGISTRY.
Downstream Artifacts (Artifact phái sinh) - Đặc tả Thiết kế Kỹ thuật (Technical Design Specification).
- Kịch bản Kiểm thử (Test Cases / Test Scenarios).
- Đặc tả API chi tiết (ví dụ: file OpenAPI/Swagger).
- Tài liệu Hướng dẫn Sử dụng hoặc Đào tạo (nếu có liên quan đến quy trình vận hành).
Authority (Thẩm quyền) - Business Owner: Phê duyệt cuối cùng về các quy tắc chuyển đổi dữ liệu (transformation rules) và logic nghiệp vụ.
- Technical Architect: Phê duyệt cuối cùng về thiết kế kỹ thuật, cấu trúc dữ liệu và các khía cạnh phi chức năng.
- Business Analyst (Owner): Chịu trách nhiệm ghi nhận, tổng hợp và duy trì sự nhất quán của tài liệu. BA không tự phê duyệt nội dung nghiệp vụ hay kỹ thuật.
Escalation (Quy trình leo thang) 1. Mọi xung đột về quy tắc nghiệp vụ phải được leo thang đến Business Owner để quyết định.
2. Mọi xung đột về kiến trúc, công nghệ hoặc hiệu năng phải được leo thang đến Technical Architect.
3. Nếu Business Owner và Technical Architect không thống nhất được giải pháp, vấn đề sẽ được leo thang lên Quản lý Dự án (Project Manager) hoặc Ban chỉ đạo dự án (Steering Committee) để phân xử.

Liên kết quản trị và truy vết nguồn gốc

Template này là một artifact được kiểm soát trong corpus Nova Foods. Mọi định danh, phiên bản, và thay đổi đều được quản lý thông qua các liên kết truy vết nguồn gốc (traceability links) tới các artifact kế hoạch chính. Việc này đảm bảo tính nhất quán và cho phép xác minh mọi yêu cầu từ nguồn gốc đến khi hoàn thiện.

Bảng 1: Định danh và Đăng ký trong Manifest

Bảng này xác định danh tính duy nhất của template và vị trí nó được đăng ký chính thức trong kiến trúc của corpus.

Loại Liên kết Artifact Nguồn Tham chiếu Diễn giải và Trách nhiệm
Đăng ký Template TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md Đây là nguồn chân lý (source of truth) cho sự tồn tại, phiên bản, trạng thái, và owner của template này. Mọi thay đổi về metadata quản trị của TMPL-INT-001 phải được cập nhật trong manifest này trước tiên.
Định danh Canonical TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md ID TMPL-INT-001 là định danh duy nhất, không thể thay đổi, được đăng ký tại đây để đảm bảo khả năng truy vết trên toàn bộ hệ thống tài liệu. Bất kỳ artifact nào khác tham chiếu đến template này đều phải sử dụng chính xác ID này.

Bảng 2: Nguồn Nội dung và Nghĩa vụ Tuân thủ

Khi điền thông tin vào template này (cụ thể là ở Tier 3), người dùng phải đảm bảo nội dung tuân thủ và có thể truy vết về các nguồn canonical dưới đây.

Nguồn Nội dung Artifact Nguồn Tham chiếu Diễn giải và Nghĩa vụ
Quy tắc Nghiệp vụ CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md Mọi logic nghiệp vụ, quy trình, hoặc điều kiện được mô tả trong bản đồ tích hợp phải tham chiếu đến một hoặc nhiều quy tắc đã được định danh trong catalog quy tắc nghiệp vụ canonical. Không được phép tạo ra quy tắc nghiệp vụ mới ngay trong template này.
Định nghĩa Dữ liệu CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md Tất cả các trường dữ liệu (tên, kiểu, định dạng, ràng buộc) được sử dụng trong ánh xạ tích hợp phải tuân thủ nghiêm ngặt định nghĩa trong từ điển dữ liệu. Việc này ngăn chặn sự thiếu nhất quán dữ liệu giữa các hệ thống.
Kiến thức và Kỹ năng CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md Nội dung và cấu trúc của template này hỗ trợ trực tiếp các mục tiêu học tập của các chương trong handbook, đặc biệt là các chương liên quan đến phân tích yêu cầu, thiết kế giải pháp và tích hợp hệ thống.
Tiêu chuẩn và Pháp lý 00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md Bất kỳ tham chiếu nào đến tiêu chuẩn ngành (ví dụ: ISO, OpenAPI) hoặc quy định pháp lý (ví dụ: Luật Kế toán, Luật An toàn thực phẩm) đều phải được liệt kê và xác minh trong bản đồ nguồn. Template không được tự diễn giải hoặc tạo ra các nghĩa vụ tuân thủ mới.

Nghĩa vụ Kiểm soát Thay đổi

  1. Trạng thái IN_REVIEW: Template này đang trong quá trình xem xét. Nội dung có thể thay đổi. Không được coi là phiên bản đã được phê duyệt hoặc baseline cho đến khi metadata được cập nhật chính thức.
  2. Quy trình Thay đổi: Mọi đề xuất thay đổi đối với cấu trúc hoặc hướng dẫn của template này phải tuân theo quy trình kiểm soát thay đổi chung của corpus. Thay đổi phải được ghi nhận trong mục Lịch sử Thay đổi (Change History).
  3. Leo thang (Escalation): Các thay đổi có thể ảnh hưởng đến quy tắc nghiệp vụ, định nghĩa dữ liệu, hoặc kiến trúc hệ thống mô phỏng phải được leo thang đến các owner của artifact CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, và các tài liệu kiến trúc liên quan để xem xét và phê duyệt.

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

Đây là mẫu trắng để đặc tả ánh xạ tích hợp giữa hai hệ thống. Sao chép và điền đầy đủ thông tin vào các mục có dấu ngoặc nhọn <...> bên dưới. Xóa các dòng hướng dẫn (bắt đầu bằng chữ nghiêng) trước khi gửi đi review.

2.1 Metadata Tích hợp (Integration Metadata)

Bảng này chứa thông tin định danh và quản trị cho luồng tích hợp. Mỗi luồng tích hợp phải có ID duy nhất.

Thuộc tính Giá trị Hướng dẫn
ID Tích hợp <INT-XXX-NNN> ID duy nhất theo định dạng INT-<TÊN MIỀN>-<SỐ THỨ TỰ>, ví dụ: INT-FIN-001.
Phiên bản <vX.Y.Z> Phiên bản của tài liệu đặc tả này, ví dụ: v1.0.0.
Hệ thống Nguồn <Tên Hệ thống Nguồn> Tên của hệ thống gửi dữ liệu.
Hệ thống Đích <Tên Hệ thống Đích> Tên của hệ thống nhận dữ liệu (ví dụ: Nova Foods ERP).
Loại Tích hợp <API / File / Message Queue / DB Sync> Chọn một: API (REST/SOAP), File (CSV/XML), Message Queue (RabbitMQ/Kafka), DB Sync (Đồng bộ trực tiếp).
Đối tượng Dữ liệu <Tên đối tượng dữ liệu chính> Đối tượng nghiệp vụ được trao đổi, ví dụ: Đơn đặt hàng, Thông tin Khách hàng, Hóa đơn.
Tần suất / Trigger <Real-time / Batch / Event-driven> Khi nào tích hợp được kích hoạt. Real-time (Thời gian thực), Batch (Theo lô, ghi rõ lịch chạy), Event-driven (Kích hoạt bởi sự kiện).
Mô tả <Mô tả ngắn gọn mục đích của tích hợp> Mô tả một câu về chức năng, ví dụ: "Đồng bộ đơn đặt hàng từ hệ thống E-commerce vào Nova Foods ERP".

2.2 Quy tắc Nghiệp vụ và Bối cảnh

Mô tả mục đích nghiệp vụ của tích hợp. Trả lời câu hỏi: "Tích hợp này làm gì và tại sao?". Liệt kê các quy tắc nghiệp vụ liên quan.

Mục đích Nghiệp vụ: <Mô tả chi tiết hơn về lý do nghiệp vụ cần tích hợp này, các bên liên quan và giá trị mang lại. Ví dụ: "Tự động hóa việc tạo hóa đơn trong ERP ngay khi đơn hàng được xác nhận trên sàn thương mại điện tử để giảm sai sót nhập liệu và tăng tốc độ xử lý".>

Quy tắc Nghiệp vụ Áp dụng: Liệt kê ID của các quy tắc từ CANONICAL_BUSINESS_RULES.md có ảnh hưởng đến logic tích hợp. Không diễn giải lại quy tắc ở đây. * <BR-XXX-NNN: Tên Quy tắc> * <BR-YYY-MMM: Tên Quy tắc>

2.3 Chi tiết Kỹ thuật (Technical Details)

Cung cấp thông tin kỹ thuật cần thiết để lập trình viên có thể xây dựng kết nối.

Chi tiết Hệ thống Nguồn Hệ thống Đích
Endpoint / Vị trí <URL API, đường dẫn thư mục SFTP, tên bảng DB> <URL API, đường dẫn thư mục SFTP, tên bảng DB>
Phương thức HTTP <GET / POST / PUT / DELETE> <GET / POST / PUT / DELETE>
Xác thực <Loại xác thực (OAuth2, API Key, Basic Auth)> <Loại xác thực>
Tham chiếu Secret {{secrets.TEN_KHOA_API_NGUON}} {{secrets.TEN_KHOA_API_DICH}}

Lưu ý: Để tham chiếu an toàn đến khóa bí mật (secrets) như API key, hãy sử dụng định dạng {{secrets.TEN_KHOA_TRONG_VAULT}}. Không bao giờ viết giá trị thật của khóa vào tài liệu này.

Định dạng Payload (Nguồn): <JSON / XML / CSV / Khác> Định dạng Payload (Đích): <JSON / XML / CSV / Khác>

2.4 Ánh xạ Trường dữ liệu (Field Mapping)

Đây là phần cốt lõi, định nghĩa cách từng trường dữ liệu nguồn được chuyển đổi và ánh xạ sang trường dữ liệu đích.

STT Trường Nguồn Kiểu Nguồn Trường Đích Kiểu Đích Quy tắc Chuyển đổi / Logic Giá trị Mặc định Ghi chú / Giả định
1 <customer.id> <string(36)> <khachHang.maKhachHang> <NVARCHAR(50)> TRIM(source) <N/A> Mã khách hàng từ nguồn là UUID.
2 <order.date> <timestamp> <donHang.ngayTao> <datetime> CONVERT_TIMEZONE(source, 'UTC', 'Asia/Ho_Chi_Minh') <N/A> Luôn chuyển về múi giờ Việt Nam.
3 <order.total> <decimal(18,2)> <donHang.tongGiaTri> <DECIMAL(18,2)> source 0.00 Ánh xạ trực tiếp 1:1.
4 <N/A> <N/A> <donHang.trangThai> <NVARCHAR(20)> <"Chờ xử lý"> <"Chờ xử lý"> Trường này không có ở nguồn, luôn gán giá trị cố định.
5 <shipping.address_line1> <string> <donHang.diaChiGiaoHang> <NVARCHAR(255)> CONCAT(source.address_line1, ", ", source.city) <N/A> Ghép hai trường từ nguồn.

2.5 Xử lý Ngoại lệ và Lỗi (Exception and Error Handling)

Mô tả cách hệ thống phản ứng khi có lỗi xảy ra trong quá trình tích hợp.

Điều kiện Lỗi / Ngoại lệ Hành động của Hệ thống Người nhận Thông báo Quy trình Xử lý
Hệ thống nguồn không phản hồi Thử lại 3 lần, mỗi lần cách nhau 5 phút. Sau 3 lần thất bại, ghi log lỗi và dừng. <Email nhóm hỗ trợ kỹ thuật> Nhóm hỗ trợ kiểm tra kết nối và trạng thái hệ thống nguồn.
Dữ liệu nguồn không hợp lệ (validation fail) Từ chối bản ghi. Ghi log chi tiết lỗi validation. Chuyển bản ghi lỗi vào "dead-letter queue". <Email người quản trị nghiệp vụ> Quản trị viên nghiệp vụ sửa dữ liệu tại hệ thống nguồn và yêu cầu gửi lại.
Hệ thống đích trả về lỗi 5xx Thử lại 3 lần, mỗi lần cách nhau 5 phút. Ghi log lỗi và dừng. <Email nhóm hỗ trợ kỹ thuật> Nhóm hỗ trợ kiểm tra trạng thái dịch vụ của hệ thống đích.
Khóa ngoại (foreign key) không tồn tại ở đích Từ chối bản ghi. Ghi log chi tiết lỗi. Gửi thông báo. <Email người quản trị nghiệp vụ> Quản trị viên nghiệp vụ kiểm tra và tạo dữ liệu master còn thiếu ở hệ thống đích.

2.6 Bằng chứng và Truy vết (Evidence and Traceability)

Liên kết đặc tả tích hợp này với các yêu cầu, quy tắc nghiệp vụ và các tài liệu khác để đảm bảo tính truy vết từ đầu đến cuối.

ID Truy vết Loại Artifact ID / Liên kết Artifact Mô tả Liên quan
<TRACE-INT-XXX-NNN-01> Yêu cầu Nghiệp vụ <BRQ-FIN-005> Yêu cầu tự động hóa việc tạo hóa đơn từ đơn hàng.
<TRACE-INT-XXX-NNN-02> Quy tắc Nghiệp vụ <BR-FIN-010> Quy tắc về việc làm tròn số tiền trên hóa đơn.
<TRACE-INT-XXX-NNN-03> Từ điển Dữ liệu <CDD-CUST-001> Định nghĩa trường dữ liệu khachHang.maKhachHang.
<TRACE-INT-XXX-NNN-04> Đặc tả Kiến trúc <ARCH-DIAG-002> Sơ đồ kiến trúc tổng thể cho luồng dữ liệu đơn hàng.

2.7 Lịch sử Thay đổi và Phê duyệt (Change History and Sign-off)

Lịch sử Thay đổi

Phiên bản Ngày Tác giả Tóm tắt Thay đổi
<v0.1.0> <YYYY-MM-DD> <Tên tác giả> Tạo bản nháp đầu tiên.

Bảng Phê duyệt

Chữ ký của các bên liên quan bên dưới xác nhận rằng họ đã xem xét và đồng ý với nội dung của đặc tả tích hợp này.

Vai trò Tên Người phê duyệt Chữ ký (ký điện tử hoặc ghi "Đã phê duyệt") Ngày
Business Owner <Tên chủ sở hữu nghiệp vụ>
Technical Architect <Tên kiến trúc sư giải pháp>
Source System Owner <Tên chủ sở hữu hệ thống nguồn>
Target System Owner <Tên chủ sở hữu hệ thống đích>
QA Lead <Tên trưởng nhóm kiểm thử>

Cấu trúc Chi tiết: Bảng Ánh xạ, Quyết định và Quản trị

Phần này cung cấp các bảng trống, sẵn sàng để sao chép, bao gồm tất cả các cấu phần cần thiết để ghi nhận một đặc tả ánh xạ tích hợp hoàn chỉnh. Các cấu phần này không chỉ bao gồm việc ánh xạ trường dữ liệu mà còn cả việc quản trị các quyết định, xử lý lỗi, truy vết yêu cầu và quy trình phê duyệt.

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

Mọi quyết định quan trọng ảnh hưởng đến logic tích hợp phải được ghi lại tại đây để đảm bảo sự đồng thuận và làm cơ sở tham chiếu trong tương lai.

ID Quyết định Vấn đề / Nội dung cần quyết định Quyết định được đưa ra Lý do / Cơ sở Người quyết định Ngày Trạng thái
<DEC-INT-NNN> <Mô tả ngắn gọn vấn đề, ví dụ: 'Xử lý mã khách hàng không tồn tại trong hệ thống đích.'> <Mô tả giải pháp đã chọn, ví dụ: 'Từ chối bản ghi và gửi thông báo lỗi về hệ thống nguồn.'> <Giải thích lý do chọn giải pháp, ví dụ: 'Đảm bảo tính toàn vẹn dữ liệu tại hệ thống đích theo yêu cầu của Business Owner.'> <Chức danh vai trò, ví dụ: 'Business Owner', 'Technical Architect'> <YYYY-MM-DD> <Chờ phê duyệt / Đã đồng ý / Đã hủy>

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

Bảng này định nghĩa cách hệ thống phản ứng với các kịch bản lỗi dự kiến trong quá trình tích hợp.

ID Lỗi Kịch bản gây lỗi Hành vi của hệ thống (System Behavior) Cơ chế thông báo Quy trình xử lý / Khắc phục
<ERR-INT-NNN> <Mô tả điều kiện gây ra lỗi, ví dụ: 'Dữ liệu ngày tháng không đúng định dạng ISO 8601.'> <Mô tả cụ thể hệ thống sẽ làm gì, ví dụ: 'Ghi log lỗi, chuyển bản ghi vào hàng đợi lỗi (dead-letter queue) và tiếp tục xử lý các bản ghi tiếp theo.'> <Mô tả ai/hệ thống nào được thông báo và bằng cách nào, ví dụ: 'Gửi email cảnh báo đến nhóm vận hành IT.'> <Mô tả các bước để con người hoặc hệ thống khác xử lý lỗi này, ví dụ: 'Nhóm vận hành kiểm tra hàng đợi lỗi hàng ngày, sửa dữ liệu và đẩy lại vào luồng tích hợp.'>

Bằng chứng và Truy vết Yêu cầu (Evidence and Traceability)

Phần này đảm bảo mọi quy tắc ánh xạ và logic đều có thể được truy vết ngược về nguồn gốc yêu cầu (requirement) ban đầu. Traceability (truy vết) là một năng lực cốt lõi của BA, giúp chứng minh rằng sản phẩm cuối cùng đáp ứng đúng nhu cầu nghiệp vụ.

ID Phần tử Ánh xạ ID Artifact Nguồn Loại Artifact Nguồn Ghi chú / Diễn giải
<ID dòng trong bảng ánh xạ chính hoặc ID của quy tắc> <ID của yêu cầu, ví dụ: BR-SALE-021, UC-005, NFR-SEC-010> <Loại yêu cầu, ví dụ: 'Business Rule', 'Use Case', 'Non-Functional Requirement', 'Pháp lý'> <Ghi chú làm rõ mối liên hệ nếu cần.>

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

Bảng này theo dõi tất cả các thay đổi được thực hiện đối với tài liệu đặc tả ánh xạ này.

Phiên bản Ngày cập nhật Tác giả Tóm tắt thay đổi
v0.1.0 <YYYY-MM-DD> <Tên và vai trò người tạo> <Mô tả thay đổi, ví dụ: 'Bản nháp đầu tiên, định nghĩa các trường cho đối tượng Khách hàng.'>
v1.0.0 <YYYY-MM-DD> <Tên và vai trò người cập nhật> <Mô tả thay đổi, ví dụ: 'Phiên bản được phê duyệt để triển khai. Hoàn thiện xử lý ngoại lệ và logic chuyển đổi.'>

Bảng Ghi nhận Xem xét và Phê duyệt (Review and Sign-off)

Việc ký nhận chính thức là cột mốc quan trọng, xác nhận rằng các bên liên quan đã xem xét và đồng ý với nội dung đặc tả trước khi chuyển sang giai đoạn triển khai.

Vai trò Tên Người phê duyệt Chữ ký / Xác nhận Ngày Trạng thái
Business Owner <Tên người đại diện nghiệp vụ> <Ghi 'Đã ký' hoặc để trống> <YYYY-MM-DD> <Approved / Rejected / Comments>
Technical Architect <Tên kiến trúc sư giải pháp> <Ghi 'Đã ký' hoặc để trống> <YYYY-MM-DD> <Approved / Rejected / Comments>
QA Lead <Tên trưởng nhóm kiểm thử> <Ghi 'Đã ký' hoặc để trống> <YYYY-MM-DD> <Approved / Rejected / Comments>
Security Officer <Tên người phụ trách an ninh thông tin> <Ghi 'Đã ký' hoặc để trống> <YYYY-MM-DD> <Approved / Rejected / Comments>

Hướng dẫn chi tiết, quy tắc xác thực và giá trị được phép

Phần này cung cấp các quy tắc và hướng dẫn bắt buộc để điền vào biểu mẫu. Tuân thủ các quy tắc này để đảm bảo tính nhất quán, rõ ràng và giảm thiểu lỗi khi đặc tả tích hợp.

Quy tắc chung và định dạng

Quy tắc Hướng dẫn Lý do
Định dạng Placeholder Luôn sử dụng dấu ngoặc nhọn: <MÔ TẢ NGẮN GỌN, VIẾT HOA>. Ví dụ: <TÊN HỆ THỐNG NGUỒN>. Dễ dàng tìm kiếm và thay thế, phân biệt rõ ràng nội dung mẫu và nội dung cần điền.
Định dạng Ngày (Date) Sử dụng chuẩn YYYY-MM-DD (ISO 8601). Ví dụ: 2026-08-07. Chuẩn quốc tế, không gây nhầm lẫn, được hỗ trợ bởi hầu hết các hệ thống.
Định dạng Thời gian (Timestamp) Sử dụng chuẩn YYYY-MM-DDTHH:mm:ss.sssZ (ISO 8601 UTC). Ví dụ: 2026-08-07T14:30:00.000Z. Đảm bảo tính chính xác về múi giờ trên toàn cầu, loại bỏ sai lệch khi hệ thống ở các khu vực khác nhau.
Phiên bản tài liệu Sử dụng Phiên bản Ngữ nghĩa (Semantic Versioning - SemVer) MAJOR.MINOR.PATCH. Ví dụ: 1.2.0. MAJOR cho thay đổi phá vỡ tương thích, MINOR cho thêm tính năng, PATCH cho sửa lỗi. Cung cấp sự rõ ràng về mức độ thay đổi.
Ngôn ngữ Sử dụng tiếng Việt. Giữ nguyên thuật ngữ tiếng Anh chuẩn khi không có từ thay thế tương đương và giải thích lần đầu. Đảm bảo sự thống nhất và dễ hiểu cho đội ngũ tại Việt Nam.

Tham chiếu Bí mật An toàn (Safe Secret Reference)

KHÔNG BAO GIỜ điền trực tiếp thông tin nhạy cảm như mật khẩu, API key, hoặc token vào tài liệu này. Thay vào đó, sử dụng một tham chiếu đến kho chứa bí mật (Secret Vault) như HashiCorp Vault, Azure Key Vault, hoặc AWS Secrets Manager.

Định dạng tham chiếu: {{vault:<tên-dự-án>/<đường-dẫn-bí-mật>:<tên-khóa>}}

Ví dụ: Để tham chiếu API key cho hệ thống SAP S/4HANA trong dự án Nova Foods ERP, sử dụng: {{vault:nova-foods-erp/sap-s4hana/api-credentials:api_key}}

Vai trò của Business Analyst là ghi lại tham chiếu này. Vai trò DevOps/Security chịu trách nhiệm cấu hình giá trị thực tế trong Vault và đảm bảo ứng dụng có thể truy xuất nó khi chạy.

Hướng dẫn điền Bảng Ánh xạ Dữ liệu (Data Mapping Table)

Đây là phần cốt lõi của tài liệu, mô tả cách dữ liệu được chuyển đổi từ nguồn sang đích.

Tên cột Hướng dẫn điền Ví dụ giá trị
Source Field Tên định danh chính xác của trường trong hệ thống nguồn, bao gồm cả cấu trúc lồng nhau nếu có. order.customer.id
Transformation Logic Mô tả logic chuyển đổi. Sử dụng ngôn ngữ có cấu trúc, rõ ràng. Bắt đầu bằng động từ. - Map directly (Ánh xạ trực tiếp)
- Concatenate: [sourceField1] + " - " + [sourceField2]
- Calculate: [quantity] * [unitPrice]
- Lookup: Find product name from Product Master using [product_sku]
- Conditional: IF [status] == "A" THEN "Active" ELSE "Inactive"
Target Field Tên định danh chính xác của trường trong hệ thống đích. invoice.customerIdentifier
Data Type (Target) Kiểu dữ liệu của trường đích. Chỉ sử dụng các kiểu được định nghĩa trước. String, Integer, Decimal(18,2), Boolean, Date, Timestamp (ISO 8601)
Validation & Constraints Các quy tắc xác thực và ràng buộc áp dụng cho trường đích. - NOT NULL
- UNIQUE
- ENUM: [PENDING, CONFIRMED, SHIPPED]
- REGEX: '^[A-Z]{2}[0-9]{8}$'
- MIN_LENGTH: 5
- MAX_VALUE: 999.99

Các mục có điều kiện (Conditional Sections)

Một số mục trong template được đánh dấu là [CONDITIONAL]. Chỉ điền các mục này khi điều kiện được mô tả được thỏa mãn. Nếu không, hãy ghi rõ Không áp dụng.

Ví dụ: Mục 4.3. OAuth 2.0 Configuration chỉ được điền khi trường Authentication Method tại mục 4.1 có giá trị là OAuth 2.0. Đối với các phương thức khác như API Key, mục này sẽ được ghi là Không áp dụng.

Bảng giá trị được phép cho các trường quan trọng

Để đảm bảo tính nhất quán, các trường lựa chọn (enumeration) phải sử dụng các giá trị được định nghĩa sẵn dưới đây.

Tên trường Giá trị được phép
Integration Status DRAFT, IN_REVIEW, APPROVED, DEPRECATED
Data Sync Method BATCH, REAL_TIME, EVENT_DRIVEN
HTTP Method GET, POST, PUT, PATCH, DELETE
Error Handling Strategy RETRY_WITH_EXPONENTIAL_BACKOFF, MOVE_TO_DEAD_LETTER_QUEUE, FAIL_FAST, LOG_AND_IGNORE

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

Phần này cung cấp một ví dụ hoàn chỉnh về tài liệu đặc tả tích hợp, sử dụng kịch bản mô phỏng của Nova Foods. Mục đích là minh họa cách điền vào mẫu trống ở Tier 2 bằng dữ liệu và quyết định cụ thể trong một dự án thực tế.

Kịch bản: Tích hợp đồng bộ đơn đặt hàng (Sales Order) mới từ hệ thống "Cổng B2B Nova Portal" sang hệ thống ERP SAP S/4HANA (mô phỏng). Khi một khách hàng doanh nghiệp (ví dụ: siêu thị) tạo và xác nhận đơn hàng trên portal, thông tin đơn hàng đó phải được tự động tạo trong ERP để bộ phận kế toán và kho vận xử lý.

3.1. Thông tin chung (General Information)

Mục Giá trị (Case study Nova Foods) Diễn giải
Integration ID INT-SO-001 Định danh duy nhất cho tích hợp này. SO = Sales Order.
Integration Name Đồng bộ Đơn đặt hàng từ Cổng B2B sang ERP Tên mô tả ngắn gọn mục đích của tích hợp.
Business Owner Lê Minh Tuấn - Giám đốc Kinh doanh Người chịu trách nhiệm về mặt nghiệp vụ cho luồng dữ liệu này.
Technical Owner Đội ngũ ERP (Phụ trách: Nguyễn Anh Dũng) Đội ngũ kỹ thuật chịu trách nhiệm về hệ thống đích (ERP).
Business Request ID BRQ-SALES-2026-004 Tham chiếu đến yêu cầu nghiệp vụ ban đầu đã được phê duyệt.
Integration Status APPROVED Tích hợp đã được phê duyệt để triển khai.
Version 1.0.0 Phiên bản đầu tiên của đặc tả này.
Last Updated 2026-08-07 Ngày cập nhật gần nhất.
Data Sync Method EVENT_DRIVEN Dữ liệu được đẩy từ nguồn sang đích ngay khi có sự kiện xảy ra (đơn hàng được xác nhận).

3.2. Các hệ thống liên quan (Systems Involved)

Vai trò Thông tin hệ thống (Case study Nova Foods)
Hệ thống Nguồn (Source System) Tên hệ thống: Cổng B2B Nova Portal
Mô tả: Nền tảng web cho khách hàng doanh nghiệp đặt hàng trực tuyến.
Đầu mối kỹ thuật: Đội ngũ Portal (Phụ trách: Trần Thị Bích)
Hệ thống Đích (Target System) Tên hệ thống: ERP SAP S/4HANA (mô phỏng)
Mô tả: Hệ thống hoạch định nguồn lực doanh nghiệp lõi, quản lý tài chính, kho vận và bán hàng.
Đầu mối kỹ thuật: Đội ngũ ERP (Phụ trách: Nguyễn Anh Dũng)

3.3. Xác thực và Phân quyền (Authentication and Authorization)

Mục Cấu hình (Case study Nova Foods)
Phương thức xác thực (Authentication Method) API Key
Chi tiết API Key Tên Header: X-API-Key
Quản lý khóa: Khóa được tạo bởi Đội ngũ ERP, lưu trữ trong dịch vụ quản lý bí mật (ví dụ: Azure Key Vault) và cấp cho Đội ngũ Portal. Khóa có thời hạn 1 năm.
Quy tắc phân quyền (Authorization Rules) API Key được cấp chỉ có quyền thực hiện hành động POST trên endpoint /api/v1/sales-orders. Mọi hành động khác (GET, PUT, DELETE) hoặc truy cập endpoint khác sẽ bị từ chối với lỗi 403 Forbidden.

3.4. Ánh xạ dữ liệu (Data Mapping)

Đây là bảng ánh xạ chi tiết các trường dữ liệu từ đơn hàng trên B2B Portal sang đối tượng Sales Order trong ERP.

Source Field (B2B Portal) Transformation Logic (Logic chuyển đổi) Target Field (ERP SAP) Data Type (Target) Validation & Constraints
orderId Direct mapping (Ánh xạ trực tiếp). ExternalOrderID String NOT NULL, UNIQUE
customerCode Direct mapping. SoldToParty String NOT NULL, Tồn tại trong Customer Master.
orderDate Convert from ISO 8601 UTC to YYYYMMDD. DocumentDate Date NOT NULL
currency Validate value is VND. DocumentCurrency String ENUM: [VND]
items (array) Loop through each item in the array to create an Order Item in ERP. OrderItems (table) Table Must have at least 1 item.
items[].sku Direct mapping. OrderItems[].MaterialNumber String NOT NULL, Tồn tại trong Material Master.
items[].quantity Direct mapping. OrderItems[].RequestedQuantity Decimal(13,3) NOT NULL, > 0
items[].unitPrice Direct mapping. OrderItems[].NetPrice Decimal(18,2) NOT NULL, >= 0
totalAmount CALCULATION: Re-calculate SUM(items[].quantity * items[].unitPrice) and verify it matches this source value. OrderHeader.TotalNetAmount Decimal(18,2) NOT NULL, Phải khớp với tổng tính lại.

Ví dụ Payload (Payload Example)

Payload từ Source (B2B Portal gửi đi): 

{
  "orderId": "B2B-ORD-20260807-9875",
  "customerCode": "KH-BIGC-001",
  "orderDate": "2026-08-07T14:30:00Z",
  "currency": "VND",
  "totalAmount": 78500000.00,
  "items": [
    {
      "sku": "NF-DRI-01L-WAT",
      "description": "Nước khoáng thiên nhiên Nova 1L",
      "quantity": 5000,
      "unitPrice": 8500.00
    },
    {
      "sku": "NF-SNCK-50G-POTATO",
      "description": "Snack khoai tây Nova 50g",
      "quantity": 2000,
      "unitPrice": 18000.00
    }
  ]
}

3.5. Xử lý lỗi (Error Handling)

Mã lỗi HTTP Tên lỗi Chiến lược xử lý (Error Handling Strategy)
400 Bad Request LOG_AND_IGNORE: Ghi log lỗi chi tiết, gửi thông báo cho đội ngũ Portal, không thử lại. Lỗi này do dữ liệu đầu vào sai (ví dụ: quantity < 0).
401/403 Unauthorized / Forbidden FAIL_FAST: Dừng ngay lập tức, gửi cảnh báo khẩn cấp đến đội ngũ ERP và An ninh thông tin. Lý do: API Key sai hoặc hết hạn.
422 Unprocessable Entity LOG_AND_IGNORE: Ghi log, thông báo cho đội ngũ Portal. Dữ liệu đúng định dạng nhưng sai về mặt logic nghiệp vụ (ví dụ: customerCode không tồn tại).
500/503 Internal Server Error / Service Unavailable RETRY_WITH_EXPONENTIAL_BACKOFF: Thử lại 3 lần (chờ 2s, 8s, 30s). Nếu vẫn thất bại, chuyển message vào hàng đợi lỗi (Dead-Letter Queue - DLQ) để xử lý thủ công.

Ví dụ Hoàn chỉnh: Ánh xạ Tích hợp Đơn hàng (SO) sang Yêu cầu Giao hàng

Phần này điền đầy đủ mẫu với kịch bản mô phỏng của Nova Foods. Kịch bản là tích hợp hệ thống ERP của Nova Foods với hệ thống Quản lý Kho (WMS) của một đối tác logistics (3PL) bên ngoài. Mục tiêu là tự động gửi thông tin đơn hàng cần xử lý từ ERP sang WMS.

Thông tin Tích hợp Giá trị
Mã Tích hợp INT-SO-WMS-001
Hệ thống Nguồn NovaFoods ERP (Mô phỏng NetSuite)
Đối tượng Nguồn SalesOrder
Hệ thống Đích Hệ thống WMS của Đối tác 3PL
Đối tượng Đích ShipmentRequest
Tác nhân Kích hoạt (Trigger) Trạng thái SalesOrder đổi thành Pending Fulfillment.
Tần suất Gần thời gian thực (Near Real-time), độ trễ < 1 phút.
Phương thức REST API
Định dạng Dữ liệu JSON
Owner Nghiệp vụ Giám đốc Chuỗi cung ứng (vai trò mô phỏng)

Bảng Ánh xạ Dữ liệu Chi tiết

Bảng ánh xạ trực tiếp. Logic phức tạp nằm ở phần quy tắc nghiệp vụ bên dưới.

Trường Nguồn (ERP) Ví dụ Nguồn Trường Đích (WMS) Ví dụ Đích Quy tắc Chuyển đổi / Ghi chú
tranId SO-2026-08734 clientReferenceId SO-2026-08734 REQUIRED. Sao chép trực tiếp. Dùng để đối soát.
tranDate 2026-08-07 requestedAt 2026-08-07T14:30:00+07:00 REQUIRED. Chuyển đổi sang định dạng ISO 8601 với múi giờ Asia/Ho_Chi_Minh.
shippingAddress.addressee Nguyễn Văn An shipTo.recipientName Nguyễn Văn An REQUIRED. Sao chép trực tiếp.
shippingAddress.addr1 123 Đường Lê Lợi shipTo.street1 123 Đường Lê Lợi REQUIRED. Sao chép trực tiếp.
shippingAddress.city Quận 1 shipTo.city Quận 1 REQUIRED. Sao chép trực tiếp.
shippingAddress.state TP. Hồ Chí Minh shipTo.province TP. Hồ Chí Minh REQUIRED. Sao chép trực tiếp.
shippingAddress.zip 700000 shipTo.postalCode 700000 REQUIRED. Sao chép trực tiếp.
shippingAddress.country VN shipTo.countryCode VN REQUIRED. Sao chép trực tiếp. ERP đã dùng mã ISO 3166-1 alpha-2.
shipMethod.name Giao Hàng Tiêu Chuẩn serviceLevel NF-STD REQUIRED. Ánh xạ theo bảng quy tắc BR-INT001-03.
itemList.item[].item.name NF-COF-RB-001 lineItems[].sku NF-COF-RB-001 REQUIRED. Sao chép trực tiếp mã sản phẩm (SKU).
itemList.item[].quantity 5 lineItems[].quantity 5 REQUIRED. Phải là số nguyên dương. Xem quy tắc BR-INT001-02.
itemList.item[].amount 1.250.000 (không có) (không có) Bỏ qua. WMS không xử lý thông tin tài chính/giá cả.

Các Quy tắc Nghiệp vụ và Logic Xử lý

Quy tắc định hình payload, không chỉ ánh xạ 1-1.

  • BR-INT001-01 (Điều kiện gửi): Chỉ gửi yêu cầu tích hợp khi trường orderStatus trong SalesOrder của ERP có giá trị là Pending Fulfillment. Các trạng thái khác (Pending Approval, Cancelled, Billed) bị bỏ qua.
  • BR-INT001-02 (Xác thực dữ liệu dòng hàng): Toàn bộ thông điệp tích hợp sẽ bị từ chối (Rejected) nếu bất kỳ dòng hàng (lineItem) nào có quantity <= 0. Một cảnh báo lỗi phải được gửi đến hệ thống giám sát nội bộ với mã lỗi E-INT001-QTY-INVALID.
  • BR-INT001-03 (Ánh xạ dịch vụ vận chuyển): Chuyển đổi giá trị shipMethod.name từ ERP sang mã serviceLevel của WMS theo bảng sau. Nếu không tìm thấy, mặc định là NF-STD và gửi một cảnh báo (Warning) đến hệ thống giám sát.
shipMethod.name (ERP) serviceLevel (WMS)
Giao Hàng Tiêu Chuẩn NF-STD
Giao Hàng Nhanh NF-EXP
Giao Hàng Hỏa Tốc NF-SAMEDAY

Ví dụ Payload (JSON)

Dữ liệu mẫu từ ERP gửi đến API của WMS.

{
  "clientReferenceId": "SO-2026-08734",
  "requestedAt": "2026-08-07T14:30:00+07:00",
  "serviceLevel": "NF-STD",
  "shipTo": {
    "recipientName": "Nguyễn Văn An",
    "phone": "0903123456",
    "street1": "123 Đường Lê Lợi",
    "street2": "Phường Bến Nghé",
    "city": "Quận 1",
    "province": "TP. Hồ Chí Minh",
    "postalCode": "700000",
    "countryCode": "VN"
  },
  "lineItems": [
    {
      "sku": "NF-COF-RB-001",
      "quantity": 5,
      "description": "Cà Phê Rang Xay Robusta - 1kg"
    },
    {
      "sku": "NF-TEA-GT-050",
      "quantity": 10,
      "description": "Trà Xanh Thái Nguyên Đặc Biệt - 500g"
    }
  ]
}

2.3. Bối cảnh, Phân tích và Quyết định

Phần này phân tích hiện trạng, nhu cầu, các phương án và quyết định lựa chọn giải pháp tích hợp.

2.3.1. Bối cảnh và Hiện trạng (As-Is)

Hiện trạng (As-Is) là quy trình thủ công hoàn toàn.

  • Hành vi: Nhân viên Mua hàng nhận thông tin Nhà cung cấp (NCC) mới qua email hoặc Zalo. Thông tin này không có cấu trúc chuẩn.
  • Hành vi: Nhân viên nhập tay thông tin vào file Excel chia sẻ có tên DANH_SACH_NCC_2026.xlsx. File này không có quy tắc xác thực dữ liệu (validation rule).
  • Hành vi: Kế toán Công nợ định kỳ (hàng ngày) sao chép dữ liệu từ file Excel vào hệ thống Nova ERP.
  • Vấn đề: Dữ liệu không nhất quán. Thường xuyên xảy ra sai sót mã số thuế, số tài khoản ngân hàng, địa chỉ.
  • Vấn đề: Chậm trễ trong vận hành. Một NCC mới cần 2-3 ngày làm việc mới có mã trong Nova ERP để Phòng Mua hàng tạo được Đơn Mua hàng (Purchase Order).
  • Bằng chứng: Ghi nhận từ buổi Phỏng vấn (Interview) bà Nguyễn Thị Bích, Trưởng phòng Kế toán, vào ngày 2026-07-15. Mã bằng chứng: EVC-INT-004.

2.3.2. Nhu cầu nghiệp vụ (Business Need)

Nhu cầu Nghiệp vụ (Business Need) là tự động hóa và đảm bảo tính nhất quán của dữ liệu NCC.

  • Mục tiêu: Dữ liệu NCC phải được đồng bộ hóa tự động từ hệ thống bán hàng Sapo (nguồn) sang Nova ERP (đích).
  • Mục tiêu: Giảm thời gian chờ từ khi có NCC mới trên Sapo đến khi NCC sẵn sàng trong Nova ERP xuống dưới 5 phút.
  • Mục tiêu: Loại bỏ 100% lỗi nhập liệu thủ công liên quan đến việc sao chép dữ liệu NCC.
  • Mã yêu cầu nghiệp vụ liên quan: RQ-SUP-001 - Tự động hóa đồng bộ Nhà cung cấp.

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

Ba phương án được xem xét để giải quyết nhu cầu RQ-SUP-001.

  1. Phương án 1: Giữ nguyên quy trình thủ công.

    • Mô tả: Không thay đổi hệ thống. Có thể bổ sung các bước kiểm tra chéo thủ công.
    • Ưu điểm: Không tốn chi phí phát triển phần mềm.
    • Nhược điểm: Không giải quyết được vấn đề gốc (root cause) là sự chậm trễ và sai sót. Rủi ro nghiệp vụ vẫn ở mức cao.

  2. Phương án 2: Tích hợp theo lô (Batch Integration) qua file CSV.

    • Mô tả: Sapo định kỳ xuất một file CSV chứa danh sách NCC mới hoặc có cập nhật. Một tiến trình tự động (batch job) trên Nova ERP sẽ đọc file này và cập nhật vào cơ sở dữ liệu.
    • Ưu điểm: Chi phí phát triển ở mức trung bình. Giảm đáng kể lỗi nhập liệu.
    • Nhược điểm: Dữ liệu vẫn có độ trễ (latency) nhất định (ví dụ: 24 giờ). Cần xây dựng quy trình giám sát và xử lý lỗi khi file hỏng hoặc dữ liệu không hợp lệ.

  3. Phương án 3: Tích hợp thời gian thực (Real-time Integration) qua API.

    • Mô tả: Khi một NCC được tạo hoặc cập nhật trên Sapo, hệ thống Sapo sẽ ngay lập tức gọi một API (Application Programming Interface) do Nova ERP cung cấp để đồng bộ dữ liệu.
    • Ưu điểm: Dữ liệu được đồng bộ gần như tức thì. Loại bỏ hoàn toàn độ trễ và sai sót do nhập liệu. Tăng cường khả năng tự động hóa toàn diện.
    • Nhược điểm: Chi phí phát triển cao nhất. Yêu cầu hệ thống nguồn (Sapo) phải có khả năng gọi webhook hoặc API ngoài.

Bảng Tiêu chí Quyết định (Decision Criteria):

Tiêu chí Trọng số Phương án 1 (Thủ công) Phương án 2 (Batch CSV) Phương án 3 (API)
Tốc độ đồng bộ hóa 40% 1/5 (Rất chậm) 3/5 (Chấp nhận được) 5/5 (Tức thì)
Độ chính xác dữ liệu 30% 1/5 (Thấp) 4/5 (Cao) 5/5 (Rất cao)
Chi phí triển khai ban đầu 20% 5/5 (Không có) 3/5 (Trung bình) 2/5 (Cao)
Khả năng mở rộng 10% 1/5 (Rất thấp) 3/5 (Trung bình) 5/5 (Rất tốt)
Tổng điểm có trọng số 100% 1.8 3.3 4.3

2.3.4. Quyết định và Hậu quả

  • Đề xuất (Recommendation): Chọn Phương án 3: Tích hợp thời gian thực qua API.
  • Lý do: Phương án này đạt điểm đánh giá cao nhất (4.3/5.0). Nó giải quyết triệt để các vấn đề gốc về tốc độ và độ chính xác, đồng thời phù hợp với chiến lược dài hạn về tự động hóa của Nova Foods. Chi phí cao hơn được chấp nhận để đổi lấy lợi ích nghiệp vụ và khả năng mở rộng trong tương lai.
  • Thẩm quyền quyết định (Decision Authority): Giám đốc Công nghệ (CTO), sau khi có sự đồng thuận từ Trưởng phòng Kế toán và Trưởng phòng Mua hàng. Quyết định này được ghi nhận với mã DEC-INT-001.
  • Hậu quả nếu quyết định sai (Consequence of Wrong Decision): Nếu triển khai Phương án 3 thất bại (ví dụ: logic xử lý lỗi API kém), hệ thống có thể tạo ra dữ liệu hỏng hàng loạt, gây gián đoạn quy trình mua hàng và thanh toán. Do đó, yêu cầu phải có kế hoạch kiểm thử (testing) chi tiết và phương án phục hồi (rollback) trước khi triển khai chính thức (go-live).

4. Tier 3 — Trường hợp Nova Foods Hoàn chỉnh: Bằng chứng và Truy vết

Phần này cung cấp các bằng chứng, giả định, mục cần xác minh, và các kịch bản lỗi để hoàn thiện đặc tả tích hợp INT-001. Mục tiêu là đảm bảo mọi khía cạnh của giải pháp đều được xem xét, truy vết và giảm thiểu rủi ro trước khi chuyển sang giai đoạn phát triển.

4.1. Ma trận Truy vết Nguồn (Source Traceability Matrix)

Ma trận truy vết (Traceability Matrix) là một công cụ cốt lõi của BA để liên kết yêu cầu với các nguồn gốc và các sản phẩm công việc khác. Bảng này chứng minh rằng đặc tả tích hợp INT-001 được xây dựng dựa trên các nhu cầu nghiệp vụ, quy tắc và quyết định đã được ghi nhận, không phải là suy diễn tùy ý.

ID Sản phẩm công việc (Artifact ID) Liên kết tới (Traces To) Loại liên kết Ghi chú
TMPL-INT-001 (phiên bản này) NEED-ACC-001 Satisfies Giải pháp tích hợp API đáp ứng trực tiếp nhu cầu tự động hóa việc đối chiếu hóa đơn và đơn hàng.
TMPL-INT-001 (phiên bản này) BR-ACC-FIN-003 Implements Logic tích hợp phải tuân thủ quy tắc nghiệp vụ về việc đồng bộ dữ liệu tài chính trong vòng 5 phút.
TMPL-INT-001 (phiên bản này) DEC-INT-001 Constrained By Đặc tả này phải được xây dựng dựa trên quyết định đã chọn là "Phương án 3: Tích hợp thời gian thực qua API".
TMPL-INT-001 (phiên bản này) Nghị định 123/2020/NĐ-CP Constrained By Các trường dữ liệu trao đổi qua API (như mã số thuế, tên công ty, địa chỉ) phải tuân thủ quy định về hóa đơn điện tử.
TMPL-INT-001 (phiên bản này) DATA-API-EINV-001 Depends On Đặc tả này phụ thuộc vào tài liệu đặc tả kỹ thuật API của đối tác cung cấp dịch vụ hóa đơn điện tử (dữ liệu mô phỏng).

4.2. Giả định, Mục cần Xác minh, và Leo thang

4.2.1. Giả định (Assumptions)

Đây là những điều kiện chúng ta tin là đúng mà không có bằng chứng đầy đủ tại thời điểm này. Nếu một giả định sai, giải pháp có thể gặp rủi ro.

  • ASN-INT-001: Đối tác cung cấp dịch vụ hóa đơn điện tử đảm bảo thời gian hoạt động của API (API uptime) đạt 99.9% theo cam kết chất lượng dịch vụ (SLA) chưa được ký kết chính thức.
  • ASN-INT-002: Dữ liệu trong hệ thống ERP của Nova Foods là chính xác và đầy đủ tại thời điểm được gửi qua API. Hệ thống không có trách nhiệm làm sạch dữ liệu cũ trước khi gửi.
  • ASN-INT-003: Băng thông mạng giữa máy chủ ERP của Nova Foods và máy chủ của đối tác đủ ổn định để không gây ra tình trạng timeout (hết thời gian chờ) thường xuyên.

4.2.2. Các mục cần xác minh (Verification-Required Items)

Đây là những câu hỏi hoặc điểm chưa rõ cần được xác nhận bởi các bên liên quan có thẩm quyền.

ID Mục cần xác minh Câu hỏi/Yêu cầu Người/Vai trò cần xác minh Trạng thái
VRF-INT-001 Tuân thủ pháp lý Yêu cầu Phòng Kế toán xác nhận các trường dữ liệu Mã số thuế, Tổng tiền thanh toán và Ngày lập hóa đơn được ánh xạ qua API là tuân thủ đầy đủ Nghị định 123/2020/NĐ-CP. Trưởng phòng Kế toán OPEN
VRF-INT-002 An ninh và bảo mật Yêu cầu Bộ phận An ninh Thông tin phê duyệt phương thức xác thực OAuth 2.0 Client Credentials được đề xuất để gọi API của đối tác có an toàn không. Trưởng phòng An ninh TT OPEN
VRF-INT-003 Giới hạn kỹ thuật Yêu cầu Đối tác cung cấp tài liệu chính thức về rate limit (giới hạn số lượng yêu cầu API mỗi phút) để thiết kế cơ chế retry (thử lại) phù hợp. Technical Account Manager (Đối tác) OPEN

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

Leo thang (Escalation) xảy ra khi một vấn đề vượt quá thẩm quyền của nhóm dự án và cần sự can thiệp từ cấp quản lý cao hơn.

  • ID Leo thang: ESC-INT-002
  • Vấn đề: Đối tác hóa đơn điện tử thông báo API của họ không hỗ trợ trường tùy chỉnh cho "Mã lô sản xuất nội bộ" (Internal Lot Code) của Nova Foods.
  • Tác động: Không thể tự động truy vết nguồn gốc sản phẩm từ hóa đơn về lô sản xuất trong hệ thống ERP, ảnh hưởng đến yêu cầu NEED-SCM-005 về truy xuất nguồn gốc.
  • Bên liên quan: Trưởng phòng Mua hàng, Trưởng phòng Kế toán, Trưởng phòng Quản lý Chuỗi cung ứng.
  • Leo thang tới: Giám đốc Công nghệ (CTO), Giám đốc Vận hành (COO).
  • Câu hỏi cần quyết định: Chấp nhận thiếu sót này và thực hiện truy vết thủ công, hay yêu cầu đối tác nâng cấp API (có thể phát sinh chi phí), hay tìm một đối tác khác?
  • Trạng thái: ESCALATED

4.3. Xử lý Ngoại lệ và Luồng Tiêu cực (Exception Handling and Negative Paths)

Luồng tiêu cực (Negative Path) mô tả cách hệ thống phản ứng khi có lỗi xảy ra. Việc định nghĩa rõ các kịch bản này là tối quan trọng để hệ thống hoạt động ổn định.

Kịch bản lỗi Tác nhân (Trigger) Phản hồi hệ thống dự kiến Truy vết tới Yêu cầu/Quy tắc
Mất kết nối mạng / Dịch vụ không sẵn sàng Hệ thống ERP nhận mã lỗi HTTP 503 Service Unavailable hoặc không thể kết nối tới máy chủ API. 1. Ghi nhận lỗi vào log với mã INT-ERR-503.
2. Lưu payload (dữ liệu yêu cầu) vào một hàng đợi (retry queue).
3. Tự động thử lại sau 5 phút, 15 phút, và 30 phút.
4. Nếu sau 3 lần vẫn thất bại, chuyển trạng thái giao dịch thành FAILED_SYNC và gửi cảnh báo tới quản trị viên hệ thống.		 BR-ACC-FIN-003
Xác thực thất bại Hệ thống ERP nhận mã lỗi HTTP 401 Unauthorized do token hết hạn hoặc không hợp lệ. 1. Ghi nhận lỗi vào log với mã INT-ERR-401.
2. Yêu cầu một access token mới từ endpoint xác thực.
3. Dùng token mới để thử lại yêu cầu ngay lập tức.
4. Nếu vẫn thất bại, đánh dấu token là không hợp lệ và gửi cảnh báo khẩn cấp tới quản trị viên.		 AC-SEC-015
Dữ liệu gửi lên không hợp lệ Hệ thống ERP nhận mã lỗi HTTP 400 Bad Request kèm theo thông báo lỗi từ API (ví dụ: "Thiếu trường taxCode"). 1. Ghi nhận lỗi vào log với mã INT-ERR-400 và toàn bộ nội dung phản hồi từ API.
2. Giao dịch được chuyển sang trạng thái VALIDATION_FAILED.
3. Gửi thông báo tới người dùng đã tạo hóa đơn/đơn hàng gốc trong ERP để họ sửa lại dữ liệu.
4. Không tự động thử lại.		 AC-DATA-007
Xung đột nghiệp vụ (VD: Trùng số hóa đơn) Hệ thống ERP nhận mã lỗi HTTP 409 Conflict từ API. 1. Ghi nhận lỗi vào log với mã INT-ERR-409.
2. Giao dịch được chuyển sang trạng thái CONFLICT.
3. Tạo một tác vụ (task) trong ERP cho Phòng Kế toán để điều tra và xử lý thủ công.
4. Không tự động thử lại.		 BR-ACC-FIN-005

Ma Trận Truy Vết Toàn Diện (End-to-End Traceability Matrix)

Traceability (truy vết) là khả năng liên kết và theo dõi một yêu cầu từ lúc hình thành (nhu cầu nghiệp vụ) qua các giai đoạn phân tích, thiết kế, triển khai và kiểm thử. Việc này đảm bảo mọi yêu cầu đều được xử lý và kiểm tra, đồng thời giúp đánh giá tác động khi có thay đổi. Ma trận truy vết là công cụ trực quan hóa các liên kết này.

Bảng dưới đây là một ví dụ minh họa cho kịch bản tích hợp "Tạo Đơn Mua Hàng (Purchase Order - PO)" của Nova Foods. Bảng này liên kết các định danh (ID) từ nhu cầu (NEED), yêu cầu (REQ), quy tắc nghiệp vụ (BR), tiêu chí chấp nhận (AC), đặc tả dữ liệu/API (DATA/API) và ca kiểm thử (TC). Các ID này là giả định, được tạo ra dựa trên cấu trúc đã hoạch định trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md và các tài liệu liên quan. Đây là dữ liệu mô phỏng cho mục đích học tập, không phải là baseline đã được phê duyệt.

ID Nhu Cầu (NEED) ID Yêu Cầu (REQ) ID Quy Tắc (BR) ID Tiêu Chí (AC) ID Dữ Liệu/API (DATA/API) ID Kiểm Thử/Lỗi (TC/DEF) Ghi Chú Luồng
NEED-001 REQ-001 BR-PUR-001 AC-001.1 DATA-API-001 TC-001 Luồng thành công: Tạo PO hợp lệ qua API.
NEED-001 REQ-001 BR-GEN-003 AC-001.2 DATA-API-001 TC-002 Luồng lỗi: Request thiếu trường bắt buộc supplierId.
NEED-001 REQ-001 BR-PUR-002 AC-001.3 DATA-DICT-015 TC-003 Luồng lỗi: supplierId không tồn tại trong hệ thống.
NEED-001 REQ-001 BR-ACC-004 AC-001.4 DATA-DICT-021 TC-004 Luồng lỗi: Tổng giá trị các line item không khớp với tổng tiền của PO.
NEED-001 REQ-001 BR-DAT-005 AC-001.5 DATA-DICT-016 TC-005 Luồng lỗi: Định dạng orderDate không hợp lệ (không theo ISO 8601).
NEED-001 REQ-001 BR-SEC-002 AC-001.6 DATA-API-001 TC-SEC-011 Luồng bảo mật: Tạo PO khi chưa xác thực (thiếu token).

Diễn giải các liên kết: * Hàng 1: Nhu cầu NEED-001 (tự động hóa tạo PO) được cụ thể hóa thành yêu cầu hệ thống REQ-001 (cung cấp API tạo PO). Để tạo thành công, cần tuân thủ quy tắc BR-PUR-001 (PO phải có thông tin cơ bản). Tiêu chí AC-001.1 xác nhận điều này thông qua API DATA-API-001 và được kiểm thử bởi TC-001. * Hàng 3: Yêu cầu REQ-001 phải tuân thủ quy tắc nghiệp vụ BR-PUR-002 (nhà cung cấp phải hợp lệ). Trường dữ liệu liên quan là PurchaseOrder.supplierId (DATA-DICT-015). Tiêu chí AC-001.3 mô tả hành vi mong muốn khi quy tắc bị vi phạm, và TC-003 là ca kiểm thử để xác minh hành vi đó.

Ma trận này cho thấy một mạng lưới liên kết chặt chẽ, đảm bảo mọi khía cạnh của nhu cầu nghiệp vụ đều được ánh xạ tới một hoặc nhiều thành phần cụ thể trong giải pháp và được kiểm chứng.

Bằng chứng kỹ thuật: Payload mẫu và Dữ liệu kiểm thử

Payload mẫu JSON cho API tạo đơn hàng mới. Dùng cho điểm cuối (endpoint) POST /api/v1/sales-orders. Cấu trúc tuân theo Đặc tả OpenAPI (OpenAPI Specification - OAS), là một tiêu chuẩn ngành để mô tả các API HTTP.

Payload mẫu (Sample Payload)

{
  "externalReference": "PO-2026-XYZ-987",
  "customerCode": "CUS-BHX-001",
  "orderDate": "2026-10-20T10:00:00+07:00",
  "requestedDeliveryDate": "2026-10-22",
  "deliveryAddress": {
    "recipientName": "Cửa hàng Bách Hóa Xanh 123",
    "street": "123 Đường Nguyễn Huệ, Phường Bến Nghé",
    "ward": "Phường Bến Nghé",
    "district": "Quận 1",
    "city": "Thành phố Hồ Chí Minh",
    "phone": "0908123456"
  },
  "lineItems": [
    {
      "productCode": "NF-BTM-001",
      "quantity": 200,
      "unitOfMeasure": "KG",
      "notes": "Lô sản xuất không sớm hơn 2026-10-01"
    },
    {
      "productCode": "NF-PGH-005",
      "quantity": 50,
      "unitOfMeasure": "BOX",
      "notes": null
    }
  ],
  "paymentTerms": "NET30",
  "salespersonId": "EMP-SALES-042"
}

Ánh xạ và Diễn giải Trường Dữ liệu

Bảng này ánh xạ các trường trong payload với từ điển dữ liệu và giải thích ý nghĩa của chúng. Mục đích là để đảm bảo tất cả các bên liên quan hiểu dữ liệu theo cùng một cách.

Trường JSON Nguồn/Định dạng Tham chiếu Từ điển Dữ liệu Diễn giải cho người học
externalReference String. Mã tham chiếu từ hệ thống của đối tác. DATA-SO-005 Mã đơn hàng của khách hàng (ví dụ: Purchase Order Number). Dùng để đối soát chéo.
customerCode String. Mã khách hàng trong ERP Nova Foods. DATA-CUS-001 Mã định danh duy nhất cho mỗi khách hàng. Giá trị này phải tồn tại trong hệ thống.
lineItems Array of Objects. Danh sách các mặt hàng trong đơn. DATA-SOL-001 Một mảng chứa các sản phẩm được đặt hàng. Mỗi sản phẩm là một đối tượng riêng.
lineItems.productCode String. Mã sản phẩm trong ERP Nova Foods. DATA-PROD-001 Mã định danh duy nhất cho mỗi sản phẩm. Giá trị phải tồn tại và đang hoạt động.
lineItems.quantity Number. Số lượng sản phẩm đặt mua. DATA-SOL-003 Số lượng sản phẩm khách hàng muốn mua theo đơn vị tính (unitOfMeasure).
paymentTerms String (Enum). Điều khoản thanh toán. DATA-SO-008 Quy định thời hạn thanh toán được thỏa thuận, ví dụ NET30 nghĩa là trả sau 30 ngày.

Bảng Dữ liệu Kiểm thử (Test Data)

Bảng này cung cấp các kịch bản kiểm thử dựa trên kỹ thuật kiểm thử hộp đen (Black-box testing), tức là kiểm thử chức năng mà không cần xem mã nguồn bên trong.

ID Kịch bản Mô tả Dữ liệu đầu vào (tóm tắt) Kết quả mong đợi Tham chiếu Yêu cầu / Quy tắc
TC-SO-CREATE-01 Kịch bản thành công (Happy Path) Payload hợp lệ như mẫu, productCode tồn tại, tồn kho đủ. HTTP Status 201 Created. Response body chứa orderId mới được tạo. AC-SO-01
TC-SO-CREATE-02 Lỗi nghiệp vụ: Mã sản phẩm không tồn tại lineItems chứa một productCode là "INVALID-CODE". HTTP Status 400 Bad Request. Response body chứa mã lỗi E400_PRODUCT_NOT_FOUND. AC-SO-03
TC-SO-CREATE-03 Lỗi nghiệp vụ: Số lượng tồn kho không đủ quantity của sản phẩm NF-BTM-001 lớn hơn tồn kho hiện có. HTTP Status 409 Conflict. Response body chứa mã lỗi E409_INSUFFICIENT_STOCK. BR-INV-02
TC-SO-CREATE-04 Lỗi xác thực dữ liệu: Thiếu trường bắt buộc Thiếu trường customerCode trong payload đầu vào. HTTP Status 400 Bad Request. Response body chứa mã lỗi E400_VALIDATION_FAILED và chi tiết trường bị lỗi. AC-SO-04
TC-SO-CREATE-05 Lỗi xác thực dữ liệu: Sai định dạng ngày requestedDeliveryDate có giá trị "22-10-2026" (sai định dạng YYYY-MM-DD). HTTP Status 400 Bad Request. Response body chứa mã lỗi E400_VALIDATION_FAILED. AC-SO-04

5. Tier 4 – Senior BA Quality Gate

Đây là cổng chất lượng. Senior BA dùng danh sách này để kiểm tra tài liệu mapping tích hợp trước khi đưa vào baseline. Tài liệu phải ĐẠT tất cả các điểm kiểm tra. Nếu một điểm không đạt, trạng thái sẽ là DỪNG & SỬA (Stop & Rework) cho đến khi vấn đề được giải quyết. Leo thang (escalate) tới vai trò được chỉ định nếu bị chặn hoặc quyết định nằm ngoài thẩm quyền của BA.

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

Mã kiểm tra Hạng mục Tiêu chí "Đạt" (Pass) Tiêu chí "Dừng & Sửa" (Stop & Rework) Vai trò leo thang (Escalate To)
QG-INT-01 Tính đầy đủ (Completeness) Mọi trường trong Tier 2 template đã được điền đủ trong Tier 3. Không còn placeholder <...> hoặc ghi chú TBD. Còn sót placeholder hoặc trường trống không có giải thích. BA viết tài liệu
QG-INT-02 Tính đầy đủ (Completeness) Mọi section yêu cầu của template (metadata, core record, evidence, testability) đều có nội dung. Thiếu section hoặc section trống. Senior BA
QG-INT-03 Tính nhất quán (Consistency) Tên trường, kiểu dữ liệu, enum trong mapping khớp với CANONICAL_DATA_DICTIONARY. Tên trường hoặc kiểu dữ liệu tự chế, không khớp từ điển hoặc không được đăng ký. Data Architect / BA Lead
QG-INT-04 Tính nhất quán (Consistency) Quy tắc nghiệp vụ (BR-...) được tham chiếu khớp với định nghĩa trong CANONICAL_BUSINESS_RULES. Diễn giải hoặc áp dụng quy tắc nghiệp vụ mâu thuẫn với catalog quy tắc gốc. Business Owner
QG-INT-05 Tính nhất quán (Consistency) Payload JSON ví dụ khớp hoàn toàn với định nghĩa cấu trúc, kiểu dữ liệu và mapping trường đã mô tả. Payload ví dụ chứa trường không có trong mapping, hoặc thiếu trường bắt buộc, hoặc sai kiểu dữ liệu. Technical Lead / Architect
QG-INT-06 Khả năng kiểm thử (Testability) Mỗi Acceptance Criterion (AC) là nguyên tử, có thể xác minh được (kết quả chỉ có thể là đúng/sai). Tiêu chí chấp nhận mơ hồ, gộp nhiều điều kiện, hoặc không thể viết một test case cụ thể để xác minh. QA Lead / Senior BA
QG-INT-07 Khả năng kiểm thử (Testability) Bảng kịch bản kiểm thử (TC-...) bao phủ đủ luồng thành công (happy path), lỗi xác thực và lỗi nghiệp vụ. Chỉ có kịch bản "happy path". Thiếu các trường hợp lỗi hoặc kiểm thử giá trị biên. QA Lead
QG-INT-08 Truy vết (Traceability) Mọi AC, BR, DATA đều có ID đã được đăng ký trong TRACEABILITY_ID_REGISTRY. Sử dụng ID chưa đăng ký, tự tạo ID không theo định dạng, hoặc ID bị trùng lặp. Senior BA / Curriculum Owner
QG-INT-09 Truy vết (Traceability) Bằng chứng và nguồn (Source of Truth) được liên kết rõ ràng cho các yêu cầu, quy tắc và quyết định chính. Yêu cầu quan trọng không có nguồn gốc, không rõ ai quyết định hoặc tại sao. Business Owner / Project Manager
QG-INT-10 Thẩm quyền nguồn (Source Authority) Các quy tắc liên quan pháp lý (thuế, hóa đơn) hoặc kế toán được đánh dấu rõ ràng "Cần xác minh" (Verification Required). BA tự diễn giải luật hoặc chuẩn mực kế toán và trình bày như một sự thật đã được xác nhận. Legal Owner / Accounting Owner
QG-INT-11 Quyền sở hữu (Ownership) Chủ sở hữu nghiệp vụ (Business Owner) cho các quy tắc và quyết định kinh doanh chính được xác định. Không rõ ai là người ra quyết định cuối cùng về một quy tắc nghiệp vụ. Project Manager / Program Lead
QG-INT-12 Ranh giới (Boundaries) Dữ liệu nhạy cảm (PII - Personally Identifiable Information) được xác định và đánh dấu. Bỏ qua việc xác định PII trong luồng dữ liệu, có nguy cơ vi phạm bảo mật dữ liệu cá nhân. Security Officer / Data Protection Officer
QG-INT-13 Ranh giới (Boundaries) Thiết kế API có xem xét các rủi ro bảo mật cơ bản (tham chiếu OWASP API Security Top 10). Thiết kế API bỏ qua các vấn đề như Broken Object Level Authorization (BOLA) hoặc Broken Authentication. Security Architect / Technical Lead
QG-INT-14 Tác động thay đổi (Change Impact) Các hệ thống, API hoặc quy trình nghiệp vụ bị ảnh hưởng bởi tích hợp được liệt kê và mô tả tác động. Không phân tích tác động, gây rủi ro bất ngờ cho các hệ thống liên quan khi triển khai. Architect / Program Manager

Các Tiêu chí Chất lượng Chi tiết

Bảng sau đây định nghĩa các tiêu chí chất lượng mà Senior BA sử dụng để rà soát tài liệu đặc tả tích hợp. Mỗi tiêu chí có một mã định danh duy nhất (QG-ID), nội dung kiểm tra cụ thể, và các điều kiện để xác định trạng thái Đạt, Cảnh báo hoặc Dừng (Stop - yêu cầu làm lại). Các tiêu chí này đảm bảo tài liệu tuân thủ các chuẩn mực ngành như BABOK, ISO và các quy định pháp lý liên quan đến bối cảnh mô phỏng Nova Foods.

Mã Tiêu chí Hạng mục Chất lượng Nội dung Kiểm tra Nguồn tham chiếu / Lý do Tiêu chí Đạt (Pass) Tiêu chí Cảnh báo (Warn) / Dừng (Stop)
QG-ID-01 Tính đầy đủ (Completeness) Tất cả các trường trong template (Mục 2) đã được điền đầy đủ trong ví dụ Nova Foods (Mục 3) chưa? Có tồn tại TBD, TODO hoặc các giá trị giữ chỗ khác không? BABOK Guide: Task "Specify and Model Requirements". Thiếu sót thông tin ở giai đoạn này sẽ tạo ra diễn giải sai ở giai đoạn phát triển và kiểm thử. Mọi trường đều có dữ liệu mô phỏng hoặc được đánh dấu "Không áp dụng" (N/A) với lý do rõ ràng. Dừng: Tồn tại TBD hoặc trường trống không có lý do. Cần bổ sung thông tin trước khi tiếp tục.
QG-ID-02 Tính nhất quán (Consistency) Định danh, tên và kiểu dữ liệu của các trường có khớp với CANONICAL_DATA_DICTIONARY.md không? Định danh quy tắc nghiệp vụ có khớp với CANONICAL_BUSINESS_RULES.md không? ISO/IEC/IEEE 29148:2018. Thiếu nhất quán giữa các tài liệu tạo ra nhiều "nguồn chân lý" (sources of truth), gây lỗi tích hợp. Mọi định danh (Data Element ID, Business Rule ID) đều tham chiếu chính xác đến artifact gốc tương ứng. Dừng: Phát hiện ID không tồn tại hoặc nội dung mô tả mâu thuẫn với artifact gốc. Phải đồng bộ hóa trước.
QG-ID-03 Khả năng kiểm thử (Testability) Các tiêu chí chấp nhận (acceptance criteria) có đủ rõ ràng, cụ thể, đo lường được để đội ngũ QA có thể viết kịch bản kiểm thử (test case) không? ISTQB CTFL Syllabus: "Test Analysis and Design". Tiêu chí mơ hồ như "hệ thống chạy đúng" là không thể kiểm thử và vô giá trị. Mỗi tiêu chí chấp nhận mô tả một kết quả có thể quan sát và xác minh được. Cảnh báo: Tiêu chí quá chung chung. Dừng: Tiêu chí chấp nhận không tồn tại hoặc không thể xác minh được.
QG-ID-04 Khả năng truy vết (Traceability) Mỗi yêu cầu, quy tắc và ánh xạ dữ liệu có định danh truy vết (Traceability ID) hợp lệ, liên kết ngược về một yêu cầu nghiệp vụ, quy định pháp lý, hoặc quyết định đã được ghi nhận không? BABOK Guide: "Requirements Traceability". Truy vết giúp quản lý sự thay đổi và đảm bảo mọi thứ được làm ra đều có lý do. Mỗi mục trong bảng ánh xạ đều có Traceability ID hợp lệ, đã được đăng ký trong TRACEABILITY_ID_REGISTRY.md. Dừng: Thiếu ID truy vết hoặc ID tham chiếu đến một nguồn không tồn tại.
QG-ID-05 Thẩm quyền nguồn (Source Authority) Nguồn của các quy tắc nghiệp vụ quan trọng (ví dụ: tính thuế, quy tắc công nợ) có đến từ đúng vai trò có thẩm quyền (Kế toán, Pháp chế) thay vì suy diễn của BA/Dev không? Nguyên tắc quản trị. Gán sai thẩm quyền có thể dẫn đến vi phạm pháp lý hoặc sai sót tài chính nghiêm trọng. Nguồn của quy tắc tuân thủ (compliance) phải là văn bản pháp quy (Luật Kế toán 88/2015/QH13) hoặc Accounting Owner. Dừng: Một quy tắc pháp lý/kế toán được ghi nhận với nguồn là "BA assumption" hoặc "Developer decision". Cần escalation ngay lập tức.
QG-ID-06 Quyền sở hữu (Ownership) Mỗi quy tắc nghiệp vụ và nhóm dữ liệu có xác định rõ Business Owner (người sở hữu về mặt nghiệp vụ) không? BABOK Guide: "Stakeholder Analysis". Owner là người có quyền ra quyết định cuối cùng về sự thay đổi của quy tắc/dữ liệu đó. Trường Owner được điền với một vai trò nghiệp vụ cụ thể (ví dụ: Trưởng phòng Mua hàng) cho các logic nghiệp vụ. Cảnh báo: Owner được ghi chung chung là "Nova Foods" hoặc "IT Department". Cần xác định rõ hơn.
QG-ID-07 Ranh giới Bảo mật (Security Boundary) Các trường dữ liệu nhạy cảm (ví dụ: thông tin tài khoản ngân hàng) có được đánh dấu phân loại (ví dụ: Confidential) và có tham chiếu đến các rủi ro bảo mật liên quan (ví dụ: OWASP API Security Top 10) không? OWASP ASVS & API Security Top 10. Bỏ qua việc phân loại dữ liệu là nguyên nhân gốc của các lỗ hổng rò rỉ thông tin. Dữ liệu nhạy cảm được nhận diện và gắn nhãn phân loại rõ ràng. Có ghi chú về yêu cầu kiểm soát truy cập. Dừng: Dữ liệu thanh toán hoặc thông tin cá nhân không được phân loại, bị đối xử như dữ liệu thông thường.
QG-ID-08 Ranh giới Riêng tư (Privacy Boundary) Dữ liệu có chứa Thông tin Nhận dạng Cá nhân (PII - Personally Identifiable Information) không? Nếu có, nó có được đánh dấu và ghi chú cần tuân thủ Luật 91/2025/QH15 không? Luật Bảo vệ dữ liệu cá nhân (Luật 91/2025/QH15). Xử lý sai PII có thể dẫn đến chế tài pháp lý nặng. Mọi PII (tên, SĐT, email liên hệ) đều được đánh dấu và có ghi chú Verification required từ vai trò Pháp chế/Tuân thủ. Dừng: PII không được nhận diện. Cần có sự xem xét từ chuyên gia pháp lý trước khi đưa vào thiết kế chi tiết.
QG-ID-09 Tác động Thay đổi (Change Impact) Tài liệu có phân tích và ghi nhận tác động của việc tích hợp này lên các hệ thống, quy trình hoặc vai trò người dùng khác trong Nova Foods không? BABOK Guide: Task "Assess Risks". Mọi thay đổi đều có hiệu ứng gợn sóng; bỏ qua chúng sẽ gây ra các vấn đề không lường trước khi triển khai. Phần Change Impact Analysis có mô tả cụ thể các đối tượng bị ảnh hưởng (ví dụ: "Quy trình đối chiếu công nợ cuối tháng của Kế toán phải được cập nhật"). Cảnh báo: Phần phân tích tác động bị bỏ trống hoặc ghi "Không có". Một tích hợp luôn có tác động.

5.1. Kết quả áp dụng Checklist vào Case Study Nova Foods

Bảng dưới đây ghi nhận kết quả xem xét của Senior BA đối với ví dụ tích hợp INT-MAP-001 (Tạo Phiếu Nhập Kho trong WMS từ Đơn Mua Hàng SAP) đã được hoàn thiện tại Mục 3 và 4. Việc ghi nhận này nhằm mục đích đảm bảo chất lượng và tính sẵn sàng của tài liệu trước khi trình baseline, không cấu thành phê duyệt baseline hoặc phê duyệt kỹ thuật.

Mã kiểm tra Hạng mục kiểm tra Nội dung kiểm tra Kết quả Ghi chú và Bằng chứng (Dựa trên dữ liệu mô phỏng tại Mục 3 và 4)
QG-01 Tính đầy đủ (Completeness) Tất cả các trường trong Mục 3 và 4 đã được điền đầy đủ, không có placeholder như TBD hoặc <chưa điền>? Đạt Xác nhận: Các mục con từ 3.1 đến 4.2 đã điền dữ liệu mô phỏng cho Nova Foods. Ví dụ: 3.1.3. Source System là SAP-S4H, 3.1.4. Target System là WMS-HIGHJUMP. Payload JSON tại 3.3 đầy đủ các trường.
QG-02 Tính nhất quán (Consistency) Định danh, thuật ngữ, quy tắc có nhất quán với các artifact canonical của corpus (Data Dictionary, Business Rules) không? Đạt với ghi chú Đạt: Định danh INT-MAP-001 đã được đăng ký. Ghi chú: Trường delivery_tolerance_percent: 0.05 trong payload ví dụ cần được liên kết chính thức tới quy tắc nghiệp vụ BR-PUR-004: Chấp nhận sai số giao hàng +/- 5% và định nghĩa trường trong CANONICAL_DATA_DICTIONARY.md với mã DD-PO-027.
QG-03 Khả năng kiểm thử (Testability) Các Tiêu chí Chấp nhận (Acceptance Criteria) có đủ cụ thể, đo lường được để bộ phận QA viết test case không? Cần làm rõ Vấn đề: Tiêu chí AC-03: Hệ thống xử lý lỗi một cách duyên dáng quá chung chung. Hành động: Cần định nghĩa rõ các trường hợp lỗi cụ thể: mã lỗi HTTP trả về (ví dụ: 400 Bad Request nếu thiếu po_number, 409 Conflict nếu GR đã tồn tại), cấu trúc payload lỗi, và cơ chế retry mong muốn. Tham chiếu ISTQB CTFL cho các kỹ thuật thiết kế test case dựa trên đặc tả.
QG-04 Khả năng truy vết (Traceability) Tích hợp có liên kết ngược (trace back) tới một yêu cầu nghiệp vụ hoặc quy trình nguồn đã được định danh không? Đạt Tài liệu đã liên kết tích hợp INT-MAP-001 tới yêu cầu nghiệp vụ BR-SCM-011: Tự động hóa tạo phiếu nhập kho từ đơn mua hàng. Liên kết này tuân thủ cấu trúc định danh trong TRACEABILITY_ID_REGISTRY.md.
QG-05 Thẩm quyền & Ownership Các vai trò Business Owner và Technical Owner đã được định danh rõ ràng và phù hợp với phạm vi tích hợp chưa? Đạt Business Owner là Trưởng phòng Mua hàng và Technical Owner là ERP Integration Lead là các chỉ định hợp lý cho luồng nghiệp vụ này. Ranh giới trách nhiệm đã được phân định.
QG-06 Ranh giới Pháp lý & Kế toán Các yếu tố liên quan đến Luật Kế toán hoặc Nghị định 123/2020/NĐ-CP có được xác định và gắn nhãn "Cần xác minh bởi vai trò có thẩm quyền" không? Đạt với ghi chú Đạt: Tài liệu đã đúng khi chỉ ghi nhận việc tạo Phiếu Nhập Kho (Goods Receipt - GR) là một chứng từ kho, không tự quyết định ghi nhận tài chính. Ghi chú: Cần bổ sung một cảnh báo rõ ràng tại mục 3.1.13. Assumptions and Constraints rằng việc ghi nhận giá trị hàng nhập kho vào sổ sách phải được Kế toán trưởng xác minh, tuân thủ Luật Kế toán 88/2015/QH13.
QG-07 Ranh giới Bảo mật & Riêng tư Cơ chế xác thực và các rủi ro bảo mật API tiềm tàng (theo OWASP) có được đề cập và có biện pháp giảm thiểu đề xuất không? Đạt Mục 3.1.8. Authentication đã chỉ định OAuth 2.0 Client Credentials, phù hợp cho giao tiếp server-to-server. Mục 4.2. Risk Analysis đã tham chiếu tới API1:2023 Broken Object Level Authorization (từ OWASP API Security Top 10) và đề xuất biện pháp: WMS phải xác thực service account gọi API có quyền thao tác trên purchase_order_id tương ứng. Không có Dữ liệu Cá nhân (PII) được xác định trong luồng này.
QG-08 Tác động thay đổi (Change Impact) Tác động đến các hệ thống/quy trình phụ thuộc (downstream/upstream) đã được phân tích và ghi nhận chưa? Cần làm rõ Vấn đề: Tài liệu chỉ tập trung vào luồng một chiều SAP -> WMS. Hành động: Cần làm rõ trong mục Out of Scope rằng các luồng liên quan như "cập nhật trạng thái Đơn Mua Hàng trong SAP sau khi nhập kho thành công" hoặc "gửi thông tin lô hàng tới hệ thống Quản lý Chất lượng (QM)" sẽ được xử lý trong các đặc tả tích hợp khác (ví dụ INT-MAP-002, INT-MAP-003).

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

6.1. Kiểm tra chéo với các Artifact nguồn (Cross-File Contradiction Check)

Kiểm tra chéo là cổng chất lượng cuối cùng. Mục đích: so sánh tài liệu này (INT-MAP-001) với các artifact nguồn (canonical artifacts) của dự án để tìm mâu thuẫn. Một mâu thuẫn nhỏ, ví dụ tên trường dữ liệu không nhất quán, có thể gây lỗi nghiêm trọng và tốn công làm lại. Quy trình này đảm bảo tính nhất quán toàn bộ corpus.

Bảng dưới đây ghi lại kết quả kiểm tra chéo cho đặc tả tích hợp INT-MAP-001 (Đơn Mua Hàng từ SAP sang WMS) của Nova Foods.

Mã kiểm tra Artifact đối chiếu Nội dung kiểm tra Kết quả Ghi chú & Hành động
XFC-01 /01-curriculum/TRACEABILITY_ID_REGISTRY.md ID tích hợp INT-MAP-001 có được đăng ký trong sổ định danh (ID registry) với mô tả chính xác không? Đạt ID INT-MAP-001 đã được đăng ký. Mô tả "Tích hợp Đơn Mua Hàng từ SAP S/4HANA sang WMS" là chính xác. Không cần hành động.
XFC-02 /01-curriculum/CANONICAL_DATA_DICTIONARY.md Các trường dữ liệu trong mục 3.1.5. Payload Mapping (ví dụ: purchase_order_id, vendor_code, line_items.product_code, uom) có khớp với định nghĩa trong từ điển dữ liệu nguồn (canonical data dictionary) không? Đạt, có ghi chú Đạt: Tất cả các trường đều tồn tại. Ghi chú: Từ điển dữ liệu định nghĩa uom (Đơn vị tính) là một danh sách có giới hạn (enum: EA, BOX, PALLET). Đặc tả tích hợp cần nói rõ rằng giá trị uom phải tuân thủ danh sách này. Hành động: Thêm một ghi chú ràng buộc trong mục 3.1.5 tham chiếu đến CANONICAL_DATA_DICTIONARY.md cho trường uom.
XFC-03 /01-curriculum/CANONICAL_BUSINESS_RULES.md Logic xử lý trong đặc tả này có mâu thuẫn với quy tắc nghiệp vụ nguồn nào không? Cụ thể là BR-WH-005 (Xử lý nhận hàng từng phần) và BR-ACC-011 (Bút toán ghi nhận nhập kho). Đạt Đặc tả đã ghi nhận đúng: WMS chỉ nhận dữ liệu Đơn Mua Hàng. Việc ghi nhận tài chính khi nhập kho là một quy trình riêng thuộc về Kế toán, phù hợp với BR-ACC-011. Luồng dữ liệu một chiều không vi phạm quy tắc nào.
XFC-04 /05-glossary/GLOSSARY.md Các thuật ngữ chuyên ngành (ví dụ: Goods Receipt, Purchase Order, WMS) được sử dụng trong tài liệu có nhất quán với định nghĩa trong bảng thuật ngữ chung của dự án không? Đạt Các thuật ngữ được sử dụng nhất quán với định nghĩa và bản dịch Việt-Anh trong GLOSSARY.md. Không tìm thấy mâu thuẫn.
XFC-05 Kế hoạch tích hợp INT-MAP-002 (luồng phụ thuộc) Dữ liệu được cung cấp bởi INT-MAP-001 có đủ cho luồng tích hợp phụ thuộc là INT-MAP-002 (Xác nhận Nhập kho từ WMS về SAP) không? Đạt, có ghi chú Đạt: Định danh chính purchase_order_id có mặt. Đây là yêu cầu tối thiểu để INT-MAP-002 có thể đối chiếu thông tin xác nhận với đơn hàng gốc trên SAP. Ghi chú: Mục Ngoài phạm vi (Out of Scope) đã xác định chính xác rằng INT-MAP-002 chịu trách nhiệm cho luồng dữ liệu ngược lại. Sự phụ thuộc này đã được ghi nhận và quản lý.

6.2. Các vấn đề mở, giả định và hạng mục cần xác minh

Bảng dưới đây ghi nhận tất cả các điểm chưa được giải quyết tại thời điểm tài liệu này được cập nhật (2026-08-07). Các hạng mục này phải được xử lý và đóng trước khi tài liệu có thể được đề xuất chuyển sang trạng thái BASELINED. Các phân loại được định nghĩa như sau:

  • Vấn đề Mở (Open Issue): Một mâu thuẫn, xung đột hoặc thiếu sót đã được xác định giữa các tài liệu (artifacts) hoặc yêu cầu, cần được giải quyết để đảm bảo tính nhất quán.
  • Giả định (Assumption): Một tuyên bố được coi là đúng khi chưa có bằng chứng xác thực, nhưng phải được xác minh để giảm thiểu rủi ro cho dự án.
  • Cần xác minh (Verification Required): Một yêu cầu hoặc quy tắc có nguồn gốc từ các quy định bên ngoài (pháp lý, kế toán, tuân thủ) hoặc quyết định nghiệp vụ cần sự phê duyệt chính thức từ vai trò có thẩm quyền (Owner).
ID Vấn đề Phân loại Mô tả chi tiết ID bị ảnh hưởng Bên chịu trách nhiệm (Owner) Mức độ ảnh hưởng Hành động tiếp theo Hạn chót
ISS-001 Vấn đề Mở Giá trị trạng thái của Đơn đặt hàng (Purchase Order) không nhất quán. CANONICAL_DATA_DICTIONARY định nghĩa là PENDING_APPROVAL trong khi CANONICAL_BUSINESS_RULES lại tham chiếu đến AWAITING_APPROVAL. DATA-ELEM-PurchaseOrder.status, BR-PROC-011 Principal IT Business Analyst Cao Tổ chức họp với Business Owner để thống nhất giá trị chuẩn (canonical value), sau đó cập nhật tất cả các tài liệu liên quan để đảm bảo tính nhất quán. 2026-08-25
ASM-001 Giả định Luồng tích hợp API giữa các dịch vụ nội bộ (service-to-service) giả định sử dụng cơ chế xác thực OAuth 2.0 Client Credentials Grant. Giả định này chưa được Technical Architect phê duyệt chính thức. TMPL-INT-001, API-SPEC-PurchaseOrder, API-SPEC-Supplier Technical Architect Trung bình Technical Architect xem xét và phê duyệt cơ chế xác thực hoặc đề xuất phương án thay thế phù hợp với kiến trúc hệ thống tổng thể. 2026-09-01
VRF-001 Cần xác minh Thời gian lưu trữ hóa đơn, chứng từ kế toán đang được giả định là 10 năm theo Luật Kế toán 88/2015/QH13. Cần có xác nhận chính thức từ bộ phận Kế toán để đảm bảo tuân thủ đầy đủ Nghị định 123/2020/NĐ-CP và các quy định hiện hành. BR-ACC-004, DATA-ELEM-SupplierInvoice.retentionPolicy Accounting Owner, Legal Owner Cao Legal Owner và Accounting Owner phối hợp ra quyết định chính thức bằng văn bản về chính sách lưu trữ, cung cấp cho nhóm dự án. 2026-09-15
VRF-002 Cần xác minh Các yêu cầu chi tiết về truy xuất nguồn gốc lô sản phẩm (định dạng batch_id, các điểm dữ liệu bắt buộc) mới chỉ dựa trên diễn giải chung của Luật An toàn thực phẩm 55/2010/QH12. Cần có đặc tả chính thức từ bộ phận quản lý chất lượng. DATA-ELEM-FinishedGood.batch_id, BR-TRACE-001, BR-TRACE-002 Quality & Compliance Owner Rất cao Quality & Compliance Owner cung cấp đặc tả chi tiết và yêu cầu dữ liệu bắt buộc cho việc truy xuất nguồn gốc để tích hợp vào ERP. 2026-09-30

Quy tắc Bàn giao, Quản lý Thay đổi và Phân định Thẩm quyền

Phần này xác định các quy tắc quản trị để bàn giao tài liệu này cho các bên liên quan xem xét, cách xử lý các thay đổi, và quan trọng nhất là làm rõ ranh giới thẩm quyền để đảm bảo việc bàn giao không bị diễn giải sai thành phê duyệt. Mục tiêu là duy trì kiểm soát trong khi vẫn ở trạng thái IN_REVIEW.

Quy trình Bàn giao để Xem xét (Handoff for Review)

Việc bàn giao tài liệu này là một hành động có kiểm soát để thu thập phản hồi chuyên môn, không phải là bước cuối cùng để "hoàn thành" công việc.

Giai đoạn Điều kiện tiên quyết Hành động của Owner Trạng thái của tài liệu
1. Chuẩn bị Bàn giao Các mục 1, 2, 3, 4, và 5 của tài liệu đã được điền đầy đủ. Mọi mục trong 6.2 Các vấn đề mở đã có chủ sở hữu (Owner) và hành động tiếp theo (Next Action) được chỉ định. Owner của TMPL-INT-001 thực hiện kiểm tra chéo cuối cùng với CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES để đảm bảo tính nhất quán. IN_REVIEW
2. Thực hiện Bàn giao Hoàn thành Giai đoạn 1. Owner gửi thông báo chính thức (ví dụ: qua Jira, email) kèm theo liên kết đến phiên bản này của tài liệu cho các vai trò được liệt kê trong Bảng Phân định Thẩm quyền bên dưới. IN_REVIEW. Việc bàn giao chỉ khởi động quy trình xem xét; nó không thay đổi trạng thái hay phiên bản của tài liệu.

Quy tắc Lan truyền Thay đổi (Change Propagation Rules)

  1. Thay đổi từ Nguồn Thượng nguồn (Upstream Changes): Khi một tài liệu canonical mà TMPL-INT-001 phụ thuộc vào (ví dụ: CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES) được cập nhật, Owner của tài liệu nguồn đó có trách nhiệm thông báo cho Owner của TMPL-INT-001. Owner của TMPL-INT-001 phải đánh giá tác động, cập nhật lại bản đồ tích hợp này cho phù hợp và ghi lại thay đổi trong lịch sử phiên bản.
  2. Thông báo Thay đổi Nội tại (Downstream Notification): Bất kỳ thay đổi nào đối với tài liệu này sau lần bàn giao đầu tiên đều yêu cầu Owner phải thông báo lại cho tất cả các bên liên quan đã nhận bàn giao. Thông báo phải nêu rõ số phiên bản mới và tóm tắt các thay đổi (hoặc cung cấp một bản so sánh diff). Nghiêm cấm việc thay đổi "im lặng" sau khi đã gửi đi xem xét.

Bảng Phân định Thẩm quyền khi Bàn giao

Bảng này làm rõ mục đích của việc bàn giao cho từng vai trò và những gì KHÔNG được suy diễn từ hành động đó. Đây là một cơ chế kiểm soát quan trọng để bảo vệ ranh giới thẩm quyền.

Vai trò Nhận Bàn giao Mục đích Yêu cầu Xem xét (Hành động mong đợi) KHÔNG phải là (Hành động KHÔNG được suy diễn)
Technical Architect / Tech Lead Xem xét tính khả thi kỹ thuật, tính nhất quán với kiến trúc hệ thống, các tác động tiềm tàng về hiệu năng/bảo mật. Xác định các yêu cầu phi chức năng cần bổ sung. Yêu cầu phê duyệt thiết kế kỹ thuật cuối cùng hoặc cam kết nguồn lực để triển khai. Bản đồ này là đặc tả logic, không phải là lệnh sản xuất.
QA Lead / Test Lead Xem xét để xác nhận tính có thể kiểm thử (testability) của các quy tắc ánh xạ và tiêu chí chấp nhận. Dùng làm cơ sở kiểm thử (test basis) để lập kế hoạch kiểm thử. Đây không phải là bộ yêu cầu cuối cùng đã được phê duyệt. Các kịch bản kiểm thử (test case) dựa trên tài liệu này chỉ là bản nháp cho đến khi yêu cầu được chốt baseline.
Business Owner / Process Owner Xem xét để xác nhận bản đồ ánh xạ phản ánh chính xác quy trình nghiệp vụ và các quy tắc như đã hiểu. Xác thực các trường dữ liệu phục vụ đúng mục đích kinh doanh. Việc BA hoàn thành tài liệu này không cấu thành phê duyệt về mặt nghiệp vụ. Phê duyệt nghiệp vụ là một hành động chính thức được ghi nhận riêng.
Security / Compliance Officer Xem xét các trường dữ liệu và luồng dữ liệu đối chiếu với chính sách bảo mật và nghĩa vụ tuân thủ (ví dụ: Luật Bảo vệ dữ liệu cá nhân). Xác định các rủi ro hoặc biện pháp kiểm soát cần thiết. Bản đồ này không phải là một Đánh giá Tác động Bảo vệ Dữ liệu (DPIA) chính thức; nó là một đầu vào cho việc đó. BA không có thẩm quyền pháp lý hay tuân thủ.

Trạng thái IN_REVIEW được duy trì trong suốt chu kỳ soạn thảo và xem xét. Tài liệu này chỉ có thể chuyển sang trạng thái BASELINED hoặc APPROVED thông qua một quy trình kiểm soát thay đổi chính thức, được điều chỉnh bởi các tài liệu quản trị cấp cao hơn của corpus (ví dụ: 01-curriculum/01_CURRICULUM_ARCHITECTURE.md) và đòi hỏi sự phê duyệt rõ ràng, có ghi nhận từ các vai trò có thẩm quyền.