04 Current State As Is And Process Mapping

Trường quản trị	Giá trị
Tên tệp được kiểm soát	/02-handbook/04-current-state-as-is-and-process-mapping.md
Tiêu đề tài liệu	04 Current State As Is And Process Mapping
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN
Bối cảnh quốc gia	Việt Nam
Đơn vị tiền tệ case study	VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp
Phân loại nguồn	Handbook dẫn xuất học liệu; nguồn chuẩn và pháp lý chỉ dùng trong ranh giới đã xác minh tại /00-research/00_SOURCE_MAP.md
Truy vết quản trị	/01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/01_CURRICULUM_ARCHITECTURE.md; TRACEABILITY_ID_REGISTRY
Baseline	Chưa có baseline reference tại v0.9.0
Approval	Chưa có approval reference. IN_REVIEW không phải phê duyệt, baseline, tuân thủ hay sẵn sàng production.
Ranh giới thẩm quyền	Tài liệu giáo dục không thay thế quyết định Business Owner, Architect, QA, Legal, Accounting, Security, Compliance hoặc vận hành thực tế.

1. Concept l? g??

Core

Current State, còn gọi As-Is, là mô tả có bằng chứng về cách công việc đang diễn ra trước thay đổi. Process Mapping là việc biểu diễn luồng công việc đó thành bản đồ để người đọc thấy điểm bắt đầu, các bước xử lý, điểm quyết định, dữ liệu được dùng, kết quả tạo ra và điểm kết thúc.

Từ gốc, một quy trình tồn tại khi một nhu cầu được xử lý lặp lại theo chuỗi. Ví dụ, cần giao hàng cho khách. Nhân viên nhận yêu cầu, kiểm tra thông tin, tạo chứng từ, kho chuẩn bị hàng, rồi ghi nhận kết quả. Nếu chỉ ghi “quy trình giao hàng” mà không cho biết việc gì đang xảy ra, ai thực hiện, dữ liệu nào đi qua và kết quả nào xuất hiện, đó chưa là As-Is đủ dùng cho BA.

As-Is không mô tả cách quy trình nên vận hành. Nó ghi nhận cách quy trình đang vận hành tại thời điểm khảo sát, gồm cả bước thủ công, bảng tính cá nhân, nhập liệu lặp, chờ phê duyệt, trao đổi qua email và lỗi có thể quan sát. Lý do: thay đổi đúng phải bắt đầu từ thực tế đúng. Nếu BA bỏ qua hiện trạng, giải pháp dễ sửa triệu chứng nhưng giữ nguyên nguyên nhân gây chậm, sai dữ liệu hoặc mất kiểm soát.

Process map không phải ảnh đẹp hay sơ đồ để trình bày. Nó là artifact phân tích. Mỗi phần tử trên sơ đồ phải trả lời được câu hỏi kiểm tra: bước này có xảy ra không, bằng chứng nào xác nhận, kết quả bước này đi đâu, và điều gì xảy ra khi điều kiện không đạt. Bằng chứng có thể là quan sát thao tác, mẫu chứng từ tổng hợp, ảnh chụp màn hình môi trường mô phỏng, log mẫu, hoặc xác nhận được ghi nhận từ người chịu trách nhiệm. Không có bằng chứng, nội dung phải được gắn là giả định hoặc điểm cần xác minh, không được trình bày như sự thật.

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

flowchart TB
    A[Quy trình nghiệp vụ đang vận hành cần khảo sát] --> B[Quan sát và thu thập bằng chứng]
    B --> C{Bằng chứng đủ xác nhận nội dung?}

    C -->|Đủ| D[Lập bản đồ As-Is với nội dung đã xác nhận]
    C -->|Chưa đủ| E[Gắn là giả định hoặc điểm cần xác minh]
    E --> F[Lập bản đồ tạm với nhãn chưa xác nhận]
    F --> G[Thu thập bằng chứng bổ sung và cập nhật nhãn]
    G --> C

    D --> H[Phát hiện điểm chờ, lỗi, lặp hoặc thiếu kiểm soát]
    H --> J[Đầu vào cho phân tích thay đổi sau này]

    subgraph M[Thông tin cần ghi nhận trên bản đồ]
        I[Thông tin cần ghi nhận]
        I -.-> M1[Điểm bắt đầu và điểm kết thúc]
        I -.-> M2[Bước xử lý và vai trò thực hiện]
        I -.-> M3[Điểm quyết định và nhánh không đạt]
        I -.-> M4[Dữ liệu được dùng]
        I -.-> M5[Kết quả tạo ra và nơi kết quả đi đến]
        I -.-> M6[Điểm bàn giao hoặc giao tiếp giữa vai trò]
        I -.-> M7[Nguồn bằng chứng hoặc người xác nhận]
    end

    D -.-> I
    F -.-> I

Ranh giới chương này: tập trung ghi nhận và làm rõ hiện trạng quy trình. Chương này chưa thiết kế To-Be là quy trình tương lai, chưa chọn phần mềm ERP, chưa viết yêu cầu chi tiết, chưa phê duyệt quy tắc nghiệp vụ, chưa kết luận tuân thủ pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo vệ dữ liệu cá nhân. Các kết luận thuộc thẩm quyền chuyên môn phải được xác minh bởi vai trò có thẩm quyền.

Core

As-is là trạng thái đang diễn ra trước thay đổi; không phải quy trình mong muốn. Process mapping là vẽ có cấu trúc luồng công việc hiện tại để thấy ai làm gì, với vật gì, tạo kết quả gì. BA (Business Analyst — Chuyên viên Phân tích Nghiệp vụ) ghi nhận bằng chứng từ người thực hiện, biểu mẫu, màn hình hoặc dữ liệu mô phỏng; BA không tự suy ra quy tắc chưa được xác nhận.

Thuật ngữ	Nghĩa tiếng Việt	Câu hỏi xác định
Actor	Tác nhân: người, vai trò, hệ thống thực hiện hành động	Ai hoặc hệ thống nào làm?
Action	Hành động: việc tác nhân thực hiện	Làm việc gì?
Object	Đối tượng: vật, dữ liệu, chứng từ bị tác động	Làm trên cái gì?
Outcome	Kết quả: trạng thái, dữ liệu hoặc đầu ra sau hành động	Sau đó có gì thay đổi?
Trigger	Sự kiện kích hoạt	Điều gì làm quy trình bắt đầu?
Decision	Điểm quyết định	Điều kiện nào làm luồng rẽ nhánh?
Handoff	Bàn giao	Khi nào trách nhiệm chuyển sang actor khác?
ERP	Enterprise Resource Planning — hệ thống hoạch định nguồn lực doanh nghiệp	Dữ liệu nào được ghi nhận trong hệ thống?
BPMN	Business Process Model and Notation — chuẩn ký pháp mô hình quy trình của OMG	Có cần sơ đồ BPMN chính thức không?

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp.

Thành phần	Nội dung
Facts	Nhân viên kho nhận phiếu xuất kho mô phỏng PXK-SYN-001.
Current Behavior	Nhân viên kho kiểm tra phiếu, lấy hàng, rồi ghi nhận số lượng đã xuất trên ERP mô phỏng.
Underlying Need	Cần thấy rõ trách nhiệm kho và thời điểm tồn kho thay đổi.
Actor	Nhân viên kho.
Action	Kiểm tra phiếu, lấy hàng, ghi nhận xuất kho.
Object	Phiếu PXK-SYN-001, hàng hóa và bản ghi tồn kho mô phỏng.
Outcome	Phiếu có trạng thái đã ghi nhận xuất; tồn kho mô phỏng giảm theo số lượng được ghi nhận.
Options	Mô tả bằng văn bản; vẽ sơ đồ hoạt động; vẽ BPMN 2.0.2.
Decision Criteria	Người đọc cần hiểu luồng cơ bản, chưa yêu cầu ký pháp BPMN chuẩn.
Decision	Dùng sơ đồ hoạt động Mermaid; không gọi sơ đồ này là BPMN.
Authority	Đây là ví dụ học liệu IN_REVIEW, không xác nhận cấu hình hay vận hành ERP thực tế.
Artifact	/02-handbook/04-current-state-as-is-and-process-mapping.md.
Consequence if Wrong	Gán sai actor hoặc outcome làm sai trách nhiệm, sai điểm cập nhật tồn kho và sai phạm vi yêu cầu sau này.

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

flowchart TB
    A[Actor: Nhân viên kho] --> B[Kiểm tra phiếu PXK-SYN-001]
    B --> C[Lấy hàng]
    C --> D[Ghi nhận xuất kho trên ERP mô phỏng]
    D --> E[Phiếu: đã ghi nhận xuất]
    D --> F[Tồn kho mô phỏng giảm theo số lượng được ghi nhận]

Senior Lens

Bốn thành phần actor, action, object, outcome phải tách riêng. Bằng chứng: cùng hành động “ghi nhận” nhưng actor có thể là nhân viên kho hoặc hệ thống ERP; object có thể là phiếu xuất hoặc tồn kho; outcome khác nhau. Gộp chúng thành câu mơ hồ như “kho xử lý hàng” làm mất khả năng kiểm tra trách nhiệm và dữ liệu.

Quick Reference

Mẫu câu as-is: [Actor] thực hiện [Action] trên [Object], tạo hoặc thay đổi [Outcome].

Ranh giới: process mapping mô tả luồng hiện tại; không tự tạo quy tắc nghiệp vụ, thiết kế ERP, quyết định pháp lý, quyết định kế toán hoặc xác nhận tuân thủ.

Applied

Ví dụ tối thiểu — Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp. Ngày 2026-08-07, nhân viên kho nhận 120 thùng nguyên liệu mô phỏng RM-COCOA-01 từ phiếu giao mô phỏng GRN-SIM-0001. Nhân viên ghi số lượng nhận vào ERP. Current State As-Is and Process Mapping không hỏi ngay hệ thống phải sửa gì; nó ghi lại việc đang diễn ra, ai làm, xử lý vật gì, và kết quả hiện có.

Thành phần	Giá trị trong ví dụ	Lý do ghi nhận
Actor	Nhân viên kho	Người hoặc vai trò thực hiện bước
Action	Ghi nhận số lượng nhận	Hành động quan sát được
Object	120 thùng RM-COCOA-01, phiếu GRN-SIM-0001	Đối tượng bị xử lý
Outcome	ERP có bản ghi nhận hàng; tồn kho mô phỏng tăng 120 thùng	Kết quả đầu ra của bước
Bằng chứng nguồn	Quan sát quy trình mô phỏng và bản ghi ERP mô phỏng	Phân biệt fact với suy đoán
Phạm vi thời gian	Trạng thái vận hành được mô tả tại thời điểm khảo sát mô phỏng	As-Is không mặc định đúng mãi mãi

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

flowchart LR
    A[Nhân viên kho] -->|Ghi nhận số lượng nhận| B[ERP mô phỏng]
    C[120 thùng RM-COCOA-01<br/>GRN-SIM-0001] --> B
    B --> D[Bản ghi nhận hàng]
    D --> E[Tồn kho mô phỏng tăng 120 thùng]

Ranh giới khái niệm. Process mapping là bản đồ hóa chuỗi actor thực hiện action trên object để tạo outcome. As-Is là ảnh chụp cách làm hiện hữu được thu thập bằng bằng chứng. Vì ví dụ chỉ chứng minh nhân viên kho ghi nhận số lượng và ERP tạo bản ghi, BA chỉ có thể kết luận đúng mức này: “Quy trình mô phỏng hiện có bước ghi nhận nhận hàng.” BA chưa thể kết luận nguyên nhân lỗi, mức tồn kho đúng, hay quy tắc kiểm tra chất lượng; các kết luận đó cần bằng chứng riêng.

Bao gồm trong As-Is mapping	Loại trừ khỏi As-Is mapping
Trình tự bước đang diễn ra	Thiết kế quy trình tương lai To-Be
Vai trò tham gia, điểm bàn giao, dữ liệu vào và ra	Yêu cầu thay đổi ERP
Ngoại lệ được quan sát hoặc được nguồn nêu rõ	Giả định ngoại lệ chưa có bằng chứng
Nút đau, chậm trễ, nhập lặp nếu ghi nhận được	Chọn giải pháp, cấu hình, ngân sách hoặc lịch triển khai
Liên kết tới artifact nguồn có định danh canonical	Diễn giải pháp lý, kế toán, thuế, an toàn thực phẩm hoặc xác nhận tuân thủ

Không suy diễn rằng GRN-SIM-0001 là chứng từ pháp lý, hóa đơn, hoặc bằng chứng tuân thủ. Đây chỉ là mã dữ liệu tổng hợp trong case Nova Foods mô phỏng. Quy tắc về kiểm soát chất lượng, truy xuất thực phẩm, kế toán, hóa đơn và dữ liệu cá nhân nằm ngoài ví dụ này; cần chủ sở hữu nghiệp vụ, pháp lý hoặc kế toán xác minh trước khi dùng cho vận hành thực tế.

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

Core

As-Is process mapping tồn tại để ngăn dự án sửa sai thứ người dùng không làm, bỏ sót điểm kiểm soát đang có, hoặc biến lời kể rời rạc thành yêu cầu ERP. “As-Is” nghĩa là trạng thái hiện hữu: ai làm gì, theo thứ tự nào, dùng dữ liệu nào, bàn giao cho ai, và ngoại lệ nào đã được ghi nhận. “Process mapping” là bản đồ hóa quy trình: biểu diễn luồng công việc để nhiều vai trò cùng đọc một cách.

Không có As-Is map, mỗi nhóm dễ dùng một phiên bản quy trình trong đầu. Kho có thể hiểu “nhận hàng” là dỡ hàng và nhập số lượng; mua hàng có thể hiểu là đối chiếu đơn mua; kế toán có thể hiểu là thời điểm đủ điều kiện ghi nhận. Cùng một từ, ba phạm vi khác nhau. BA ghi requirement từ một cách hiểu sẽ tạo mơ hồ; đội kỹ thuật phải hỏi lại, cấu hình lại, hoặc xây luồng không khớp vận hành.

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

flowchart TB
    subgraph Không có As-Is map
        A[Diễn đạt rời rạc<br/>từ nhiều vai trò] --> B[Requirement mơ hồ]
        B --> C[Cấu hình hoặc xây luồng ERP<br/>từ requirement mơ hồ]
        C --> D[Luồng ERP thiếu hoặc sai<br/>so với vận hành]
        D --> E[Phân tích lại và làm lại]
    end

    subgraph Có As-Is process map có nguồn
        F[As-Is map ghi nhận bước, dữ liệu,<br/>bàn giao, điểm kiểm soát và ngoại lệ] --> G[Phạm vi và tác động<br/>thay đổi rõ]
        G --> H[Requirement có ngữ cảnh<br/>và dấu vết nguồn]
        H --> I[Đối chiếu requirement và cấu hình ERP<br/>với As-Is map]
        I --> J[Luồng ERP khớp quy trình hiện hữu<br/>hoặc xác định rõ bước cần thay đổi]
    end

Rủi ro quản trị cũng tăng khi không có map. Một thay đổi như tự động tăng tồn kho có thể âm thầm thay đổi điểm kiểm soát giữa kho, mua hàng và kế toán. Nếu artifact không chỉ ra điểm bàn giao hiện hữu, không ai xác định được vai trò nào phải xem xét tác động. Quyết định khi đó thiếu phạm vi, thiếu dấu vết nguồn, và không chứng minh được vì sao một bước bị giữ, đổi hoặc loại bỏ.

Applied

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp GRN-SIM-0001 ghi nhận 120 thùng RM-COCOA-01. Bản đồ As-Is không tự xác nhận đây là quy trình thực tế, chứng từ pháp lý, hay quy tắc kế toán. Nó chỉ đóng gói quan sát nghiệp vụ thành phạm vi có thể kiểm tra: nhân viên kho ghi nhận số lượng nhận trong ERP mô phỏng, sau đó bản ghi nhận hàng được tạo.

Rủi ro không có As-Is map	Hậu quả quan sát được trong case mô phỏng	Cơ chế phòng ngừa của map
“Nhận hàng” không có ranh giới bước	Nhóm kỹ thuật có thể chỉ tạo màn hình nhập số lượng, trong khi nhóm nghiệp vụ đang nói tới cả bàn giao	Tách actor, action, dữ liệu vào, dữ liệu ra, điểm bàn giao
Ngoại lệ không được nêu	Luồng chỉ xử lý 120 thùng khớp kỳ vọng; trường hợp số lượng thực nhận khác không có chỗ để phân tích	Ghi rõ ngoại lệ chỉ khi nguồn quan sát hoặc stakeholder nêu
Thay đổi bị gán nhầm là hiện trạng	Đề xuất tự động hóa bị ghi như thể đang vận hành	Phân biệt bước As-Is với ý tưởng thay đổi
Không truy được nguồn	Reviewer không biết một bước đến từ quan sát, tài liệu hay diễn giải	Gắn liên kết artifact nguồn và giới hạn kết luận

Senior Lens

As-Is map không phải sơ đồ đẹp để trình bày. Nó là kiểm soát chống suy diễn. Mỗi ô quy trình phải trả lời được: actor nào thực hiện, hành động nào xảy ra, object hoặc dữ liệu nào bị tác động, và bằng chứng nào cho phép ghi ô đó. Không trả lời được, BA phải ghi khoảng trống cần làm rõ; không được lấp bằng quy tắc tự nghĩ ra.

Map cũng không cấp thẩm quyền quyết định. Nó không xác nhận Nova Foods mô phỏng tuân thủ pháp luật về kế toán, hóa đơn, an toàn thực phẩm, truy xuất hay bảo vệ dữ liệu cá nhân. Các kết luận đó cần nguồn chính thức hiện hành và chủ sở hữu thẩm quyền xác minh. IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải baseline, approval, hay cho phép dùng production.

Quick Reference

Quy tắc	Áp dụng
Map hiện trạng trước khi đề xuất thay đổi	Tránh thiết kế từ giả định
Một bước phải có actor, action và outcome	Giảm mơ hồ phạm vi
Không có bằng chứng, không ghi như sự thật	Chặn suy diễn thành requirement
Không gọi PlantUML hoặc Mermaid là BPMN	BPMN 2.0.2 là chuẩn ký pháp riêng của OMG
Giữ mã GRN-SIM-0001 và RM-COCOA-01 đúng nguyên dạng	Bảo toàn traceability dữ liệu tổng hợp

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên giao dịch và dữ liệu dưới đây là tổng hợp. So sánh trước/sau cho thấy giá trị của As-Is process map: sơ đồ quy trình hiện tại ghi lại ai làm gì, theo thứ tự nào, dùng dữ liệu nào và điểm nào chuyển giao trách nhiệm. Không có sơ đồ này, nhóm ERP dễ biến lời kể rời rạc thành yêu cầu sai.

Mục	Trước khi lập As-Is map	Sau khi lập As-Is map	Hệ quả quan sát được
Facts	Nhân viên kinh doanh nhận đơn qua email; kho kiểm tra tồn rồi phản hồi bằng chat; kế toán tạo chứng từ sau khi hàng đã xuất.	Luồng nhận đơn, kiểm tra tồn, duyệt xuất và ghi nhận chứng từ được đặt trên cùng một sơ đồ.	Nhóm thấy rõ kế toán nhận thông tin sau sự kiện xuất hàng, không phải đồng thời với kho.
Current Behavior	Một đơn có thể được sửa số lượng trong email sau khi kho đã chuẩn bị hàng.	Điểm chuyển giao từ Sales sang Warehouse và Warehouse sang Accounting được ghi rõ.	Có thể chỉ đúng nơi cần kiểm soát phiên bản đơn, thay vì yêu cầu mọi bộ phận “cập nhật kịp thời”.
Underlying Need	Cần biết trạng thái đơn nào là nguồn để kho xuất hàng và kế toán ghi nhận.	Nhu cầu được tách khỏi cách làm hiện tại qua email và chat.	ERP không bị mặc định hóa theo công cụ cũ.
Options	Cấu hình ERP theo email cuối cùng; hoặc bắt buộc kho tự gọi Sales khi có khác biệt; hoặc xác định một trạng thái đơn dùng chung trước khi xuất.	Các phương án được đánh giá trên luồng thực tế đã quan sát.	Tránh chọn quy tắc chỉ thuận tiện cho một phòng ban.
Decision Criteria	Không làm mất thay đổi số lượng; truy được người chuyển giao; không cho kho xuất theo thông tin mâu thuẫn.	Tiêu chí gắn vào bước và dữ liệu cụ thể.	BA có cơ sở viết yêu cầu và tiêu chí chấp nhận sau này.
Decision	Chưa có quyết định vận hành hay cấu hình ERP. As-Is map chỉ ghi nhận hiện trạng để xem xét.	Không gọi artifact IN_REVIEW là baseline hoặc phê duyệt.	Tránh biến tài liệu phân tích thành mệnh lệnh triển khai.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact; Business Owner, Warehouse Owner và Accounting Owner cần xác nhận phần thuộc thẩm quyền của họ.	Thẩm quyền được tách khỏi người vẽ sơ đồ.	Giảm rủi ro BA tự quyết định quy tắc vận hành hoặc kế toán.
Artifact	Lời kể email, chat và trao đổi miệng không có điểm đối chiếu chung.	/02-handbook/04-current-state-as-is-and-process-mapping.md, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07.	Reviewer có vị trí chung để phát hiện bước thiếu hoặc diễn giải khác nhau.
Consequence if Wrong	ERP có thể cho kho xuất theo bản email cũ, trong khi kế toán ghi nhận theo số lượng khác.	Sơ đồ sai vẫn dẫn nhóm đến yêu cầu sai, nên phải đối chiếu từng lane, trạng thái và handoff với đúng owner.	Rework xảy ra ở cấu hình, kiểm thử, đào tạo và xử lý ngoại lệ.

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

flowchart TB
    A[Sales nhận đơn qua email] --> B[Warehouse kiểm tra tồn]
    B --> T[Warehouse phản hồi tồn qua chat]
    T --> Q{Sales có sửa số lượng<br/>trước khi xuất?}

    Q -- Không --> X[Phiên bản hoặc trạng thái đơn dùng để xuất<br/>và ghi nhận chưa xác định]
    Q -- Có --> C[Sales gửi thay đổi số lượng qua email]
    C --> G{Warehouse nhận thay đổi<br/>trước khi xuất?}

    G -- Có --> X
    G -- Không --> R[Warehouse vẫn dùng phiên bản cũ]
    G -- Chưa xác minh --> U[Handoff thay đổi cần owner xác minh]

    U -. đối chiếu email, chat và owner .-> X
    X --> K[Warehouse chuẩn bị và xuất hàng]
    R --> K
    K --> E[Accounting tạo chứng từ sau khi xuất]

    H[Câu hỏi mở: có điểm duyệt xuất<br/>và owner không?]
    H -. chưa xác minh .-> K

    E -. nếu số lượng ghi nhận khác số lượng đã xuất .-> L[Warehouse và Accounting có thể dùng<br/>số lượng khác nhau]

Trước khi có sơ đồ, mâu thuẫn nằm trong các kênh trao đổi tách rời: Sales thấy email sửa đơn, Warehouse có thể đã làm theo dữ liệu cũ, Accounting chỉ thấy hàng đã xuất. Sau khi biểu diễn luồng, mâu thuẫn trở thành điểm kiểm tra cụ thể giữa C và D: thay đổi số lượng có được Warehouse nhận trước xuất hàng không. Đây là hậu quả có thể quan sát từ cấu trúc quy trình, không phải thống kê hay khẳng định về vận hành thật của Nova Foods.

Phân loại bằng chứng trước khi ghi As-Is

Core

Trong Nova Foods mô phỏng, dữ liệu tổng hợp, mỗi phát biểu As-Is phải có loại bằng chứng. Phân loại này ngăn BA biến lời kể thành sự thật, biến giả định thành quy tắc ERP, hoặc gọi một lựa chọn chưa có thẩm quyền là quyết định. IN_REVIEW, v0.9.0, ngày 2026-08-07 chỉ mô tả trạng thái artifact; chúng không là approval hay baseline.

Loại	Định nghĩa	Bằng chứng tối thiểu	Cách ghi
Verified fact	Sự kiện đã kiểm tra được từ artifact, log, quan sát, hoặc nguồn được kiểm soát	Tham chiếu nguồn và vị trí	“Đã xác minh: …”
Stakeholder input	Thông tin do người liên quan cung cấp	Vai trò, thời điểm, kênh ghi nhận	“Ý kiến stakeholder: …”
Project assumption	Điều tạm giả định để tiếp tục phân tích khi chưa đủ bằng chứng	Lý do, tác động, người cần xác minh	“Giả định dự án: …”
Decision	Lựa chọn đã được vai trò có thẩm quyền ghi nhận	Tiêu chí, authority, artifact quyết định	“Quyết định: …”
Verification-required claim	Nhận định có thể ảnh hưởng phạm vi, pháp lý, kế toán, bảo mật, chất lượng hoặc vận hành nhưng chưa được xác minh	Khoảng trống bằng chứng và owner xác minh	“Cần xác minh: …”

Applied

Trường	Nội dung Nova Foods mô phỏng
Facts	/01-curriculum/CHAPTER_MANIFEST.md có Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07; metadata nêu Nova Foods là case study mô phỏng, dữ liệu tổng hợp. Đây là verified fact vì artifact kiểm soát ghi trực tiếp.
Current Behavior	Nhân viên Kho nói rằng phiếu xuất kho hiện được nhập sau khi xe rời cổng. Đây là stakeholder input; lời kể chưa chứng minh mọi chuyến xe đều như vậy.
Underlying Need	BA cần biết thời điểm ghi nhận xuất kho để mô tả trạng thái hiện tại, xác định dữ liệu nào có thể lệch giữa kho và chứng từ.
Options	Ghi lời kể là fact; ghi đúng nhãn stakeholder input; hoặc dừng ghi nhận cho đến khi có log hay quan sát.
Decision Criteria	Có nguồn quan sát được; phạm vi áp dụng rõ; owner nghiệp vụ xác nhận; không suy diễn nghĩa vụ kế toán hay pháp lý.
Decision	Chưa có quyết định. BA ghi phát biểu dưới nhãn stakeholder input và tạo verification-required claim về thời điểm ghi nhận xuất kho.
Authority	Warehouse Operations Owner xác nhận cách vận hành; Accounting Owner xác nhận tác động hạch toán; Legal Owner xác minh nếu phát biểu bị diễn giải thành nghĩa vụ pháp lý.
Artifact	Ghi trong /02-handbook/04-current-state-as-is-and-process-mapping.md; giữ liên kết quản trị tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi các artifact này có nội dung phù hợp.
Consequence if Wrong	Nếu lời kể bị ghi thành fact, nhóm có thể thiết kế trạng thái ERP sai, viết test sai thời điểm, hoặc gán trách nhiệm kiểm soát cho sai vai trò.

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

flowchart TD
    A["Phát biểu As-Is"] --> B{"Có artifact, log hoặc quan sát kiểm tra được?"}
    B -->|"Có"| FACT["Ghi Verified fact trong artifact"]
    B -->|"Không"| C{"Nguồn phát biểu?"}

    C -->|"Stakeholder"| INPUT["Ghi Stakeholder input và claim cần xác minh trong artifact"]
    C -->|"Tạm dùng phân tích"| ASSUME["Ghi Project assumption và claim cần xác minh trong artifact"]
    C -->|"Chưa rõ"| UNVERIFIED["Ghi Verification-required claim trong artifact"]

    INPUT --> CHECK_INPUT{"Warehouse Operations Owner xác nhận, có nguồn quan sát được và phạm vi rõ?"}
    ASSUME --> CHECK_ASSUME{"Warehouse Operations Owner xác nhận, có nguồn quan sát được và phạm vi rõ?"}
    UNVERIFIED --> CHECK_UNKNOWN{"Warehouse Operations Owner xác nhận, có nguồn quan sát được và phạm vi rõ?"}

    CHECK_INPUT -->|"Không"| PENDING_INPUT["Giữ Stakeholder input và claim cần xác minh trong artifact"]
    CHECK_ASSUME -->|"Không"| PENDING_ASSUME["Giữ Project assumption và claim cần xác minh trong artifact"]
    CHECK_UNKNOWN -->|"Không"| PENDING_UNKNOWN["Giữ Verification-required claim trong artifact"]

    CHECK_INPUT -->|"Có"| FACT
    CHECK_ASSUME -->|"Có"| FACT
    CHECK_UNKNOWN -->|"Có"| FACT

    FACT --> IMPACT{"Có diễn giải tác động hạch toán?"}
    IMPACT -->|"Có"| ACCOUNTING["Accounting Owner xác nhận tác động hạch toán"]
    IMPACT -->|"Không"| LEGAL
    ACCOUNTING --> LEGAL{"Có diễn giải thành nghĩa vụ pháp lý?"}

    LEGAL -->|"Có"| LEGAL_OWNER["Legal Owner xác minh diễn giải pháp lý"]
    LEGAL -->|"Không"| CHOICE
    LEGAL_OWNER --> CHOICE{"Có lựa chọn về cách vận hành cần quyết định?"}

    CHOICE -->|"Không"| NO_DECISION["Không tạo Decision"]
    CHOICE -->|"Có"| CRITERIA{"Đủ nguồn, phạm vi, owner xác nhận và không suy diễn?"}
    CRITERIA -->|"Không"| NO_DECISION
    CRITERIA -->|"Có"| DECISION["Warehouse Operations Owner ghi nhận Decision"]

    PENDING_INPUT -.->|"Nếu nâng sai thành fact"| RISK["Sai trạng thái ERP, thời điểm test hoặc vai trò kiểm soát"]
    PENDING_ASSUME -.->|"Nếu nâng sai thành fact"| RISK
    PENDING_UNKNOWN -.->|"Nếu nâng sai thành fact"| RISK

Senior Lens

Chuỗi suy luận phải nhìn thấy được: nguồn kiểm tra được chỉ hỗ trợ verified fact; lời người dùng chỉ hỗ trợ stakeholder input; thiếu nguồn nhưng cần tiếp tục phân tích chỉ hỗ trợ project assumption. Decision cần authority và artifact ghi nhận, không thể suy ra từ chức danh BA, từ IN_REVIEW, hoặc từ việc nhiều stakeholder đồng ý miệng. Claim liên quan thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc phải giữ nhãn “Cần xác minh”; nguồn pháp lý trong 00_SOURCE_MAP chỉ xác nhận nguồn tồn tại, không tự xác nhận áp dụng cho thiết kế ERP mô phỏng.

Quick Reference

Không viết	Viết đúng
“Nova Foods bắt buộc ghi nhận xuất kho trước khi xe rời cổng.”	“Cần xác minh: thời điểm ghi nhận xuất kho; hiện chỉ có stakeholder input từ Kho.”
“ERP hiện dùng quy tắc này.”	“Ý kiến stakeholder: nhân viên Kho mô tả quy tắc này; chưa có log hoặc cấu hình kiểm tra.”
“Đã quyết định dùng trạng thái Posted.”	“Chưa có quyết định được ghi nhận; cần Business Owner và Accounting Owner xác nhận.”
“Artifact đã được phê duyệt.”	“Artifact ở trạng thái IN_REVIEW; chưa có approval reference.”

3. V? tr? trong Lifecycle

Core

Lifecycle là vòng đời thay đổi: từ phát hiện nhu cầu đến vận hành. Current State As-Is và Process Mapping phải bắt đầu ở Discovery để tránh thiết kế từ giả định, rồi được cập nhật qua Analysis, Delivery, Testing, Release và Operations. Bằng chứng là mỗi pha tạo thông tin mới: Discovery có vấn đề quan sát được; Analysis xác định luồng hiện tại; Delivery biến yêu cầu thành cấu hình hoặc mã; Testing kiểm tra hành vi; Operations cung cấp dữ liệu vận hành thực tế.

Pha	Entry gate: được vào khi	Hoạt động As-Is	Exit gate: được rời khi
Discovery	Có vấn đề nghiệp vụ, mục tiêu hoặc tín hiệu vận hành được ghi nhận	Thu thập mô tả ban đầu về quy trình, tác nhân, điểm đau	Phạm vi khảo sát và câu hỏi cần xác minh được ghi nhận; chưa gọi là requirement
Analysis	Có đầu vào Discovery và nguồn bằng chứng xác định được	Vẽ luồng As-Is, phân loại fact, stakeholder input, project assumption, Verification required	Luồng có điểm bắt đầu, kết thúc, quyết định, ngoại lệ và bằng chứng cho từng claim quan trọng
Delivery	Có As-Is được dùng làm test basis hoặc đầu vào thiết kế	Đối chiếu thay đổi dự kiến với bước As-Is bị ảnh hưởng	Mọi thay đổi giữ liên kết về bước As-Is, dữ liệu và quy tắc liên quan
Testing	Có build hoặc cấu hình kiểm thử được và test basis	Dùng As-Is xác định kịch bản bình thường, ngoại lệ, dữ liệu đầu vào và kết quả mong đợi	Kết quả test chỉ rõ hành vi khớp hoặc lệch so với quy trình và rule đã xác minh
Release	Có kết quả testing và phạm vi phát hành rõ	Xác định bước As-Is nào bị thay thế, giữ lại hoặc cần hướng dẫn chuyển đổi	Gói release nêu rõ tác động quy trình; claim chưa xác minh không được biến thành cam kết vận hành
Operations	Giải pháp đã được đưa vào môi trường vận hành theo quyết định có thẩm quyền	So sánh dữ liệu vận hành với As-Is và giả định trước đó	Phát hiện mới quay về Discovery hoặc Analysis; không sửa ngầm sơ đồ đã kiểm soát

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

flowchart TB
    I[Đầu vào được ghi nhận] --> GDisc{Có vấn đề nghiệp vụ,<br/>mục tiêu hoặc tín hiệu vận hành?}
    GDisc -->|Chưa| ND[Chưa vào Discovery]
    GDisc -->|Có| D[Discovery<br/>Thu thập quy trình, tác nhân, điểm đau]

    D --> XD{Phạm vi khảo sát và<br/>câu hỏi cần xác minh đã ghi nhận?}
    XD -->|Chưa| FD[Hoàn thiện phạm vi và câu hỏi] --> D
    XD -->|Có| EA{Có đầu vào Discovery và<br/>nguồn bằng chứng xác định?}
    EA -->|Chưa| FA[Bổ sung đầu vào hoặc<br/>xác định nguồn bằng chứng] --> D
    EA -->|Có| A[Analysis<br/>Vẽ As-Is và phân loại claim]

    A --> XA{Đủ điểm bắt đầu, kết thúc,<br/>quyết định, ngoại lệ và bằng chứng?}
    XA -->|Chưa| FXA[Hoàn thiện luồng, ngoại lệ<br/>hoặc bằng chứng còn thiếu] --> A
    XA -->|Có| ED{As-Is được dùng làm test basis<br/>hoặc đầu vào thiết kế?}
    ED -->|Chưa| FED[Xác định cách dùng As-Is] --> A
    ED -->|Có| DE[Delivery<br/>Đối chiếu thay đổi với As-Is]

    DE --> XDv{Mọi thay đổi có liên kết tới<br/>bước As-Is, dữ liệu và quy tắc?}
    XDv -->|Chưa| FDv[Bổ sung liên kết còn thiếu] --> DE
    XDv -->|Có| ET{Có build hoặc cấu hình kiểm thử được<br/>và có test basis?}
    ET -->|Chưa| FET[Hoàn thiện build, cấu hình<br/>hoặc test basis] --> DE
    ET -->|Có| T[Testing<br/>Kiểm tra luồng, ngoại lệ và dữ liệu]

    T --> XT{Kết quả test chỉ rõ hành vi<br/>khớp hoặc lệch quy trình và rule?}
    XT -->|Chưa| FTest[Hoàn thiện kết quả kiểm thử] --> T
    XT -->|Có| ER{Có kết quả testing và<br/>phạm vi phát hành rõ?}
    ER -->|Chưa| WR[Chưa vào Release<br/>Chờ đủ kết quả và phạm vi]
    WR --> ER
    ER -->|Có| R[Release<br/>Xác định bước thay thế, giữ lại<br/>hoặc cần hướng dẫn chuyển đổi]

    R --> XR{Gói release nêu rõ tác động<br/>và không biến claim chưa xác minh<br/>thành cam kết vận hành?}
    XR -->|Chưa| FR[Hoàn thiện gói release] --> R
    XR -->|Có| EO{Đã triển khai vào môi trường vận hành<br/>theo quyết định có thẩm quyền?}
    EO -->|Chưa| WO[Chờ quyết định hoặc triển khai]
    WO --> EO
    EO -->|Có| O[Operations<br/>So sánh dữ liệu vận hành với<br/>As-Is và giả định]

    O --> FO{Có phát hiện mới?}
    FO -->|Không| O
    FO -->|Có| C[Kiểm soát thay đổi<br/>Ghi nhận phát hiện;<br/>không sửa ngầm sơ đồ đã kiểm soát]
    C --> RT{Phát hiện cần xử lý ở đâu?}
    RT -->|Vấn đề, mục tiêu hoặc<br/>tín hiệu vận hành mới| GDisc
    RT -->|Cần xác minh lại luồng<br/>hoặc bằng chứng As-Is| EA

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp. Artifact corpus đang IN_REVIEW, version v0.9.0, ngày 2026-08-07; không có baseline hoặc approval reference.

Current Behavior: Nhân viên Kho mô tả miệng rằng đơn giao hàng được “kiểm tra rồi xuất”. Đây chỉ là stakeholder input vì chưa có log, cấu hình ERP, biểu mẫu kiểm tra hoặc quan sát kiểm chứng.

Underlying Need: Cần biết bước kiểm tra xảy ra trước hay sau xuất kho. Lý do: vị trí bước quyết định test case, dữ liệu cần lưu và tác động của thay đổi Delivery.

Options: (1) Ghi “kiểm tra trước xuất kho” như fact. (2) Ghi bước kiểm tra với nhãn stakeholder input và điểm cần xác minh. (3) Bỏ bước kiểm tra khỏi sơ đồ.

Decision Criteria: Option phải bảo toàn bằng chứng, không biến lời kể thành quy tắc, và vẫn cho phép phân tích luồng.

Decision: Chọn option 2. Sơ đồ Analysis ghi Kiểm tra giao hàng [stakeholder input; cần xác minh thời điểm]. Suy luận: có mô tả từ stakeholder nên không được bỏ; không có bằng chứng kiểm tra được nên không được nâng thành fact.

Authority: Không có quyết định nghiệp vụ được ghi nhận trong micro-batch này. IN_REVIEW không tạo thẩm quyền xác nhận quy trình.

Artifact: Cập nhật Process Map As-Is trong /02-handbook/04-current-state-as-is-and-process-mapping.md; giữ nguồn phân loại là stakeholder input.

Consequence if Wrong: Nếu gắn sai vị trí kiểm tra, Delivery có thể cấu hình sai thứ tự trạng thái; Testing kiểm tra sai kịch bản; Release truyền đạt sai thay đổi vận hành.

Senior Lens

Exit gate không phải cuộc họp đã diễn ra. Exit gate là điều kiện kiểm tra được để pha sau không phải tự suy diễn. Ví dụ, “đã phỏng vấn Kho” không đủ để rời Analysis; cần biết quy trình có điểm bắt đầu, kết thúc, quyết định, ngoại lệ, nguồn bằng chứng và claim chưa xác minh. Khi thiếu điều kiện này, quay lại Analysis. Không đẩy khoảng trống sang Testing vì tester không có thẩm quyền tự tạo business rule.

Quick Reference

Tình huống	Xử lý lifecycle
Chỉ có lời mô tả của stakeholder	Vào Analysis với nhãn stakeholder input
Có log hoặc cấu hình kiểm tra được	Ghi verified fact, liên kết vào Process Map
Luồng thiếu ngoại lệ	Không qua exit gate Analysis
Test phát hiện hành vi khác sơ đồ	Quay lại Analysis; phân loại lại bằng chứng
Operations phát sinh tình huống mới	Tạo đầu vào Discovery mới; không sửa ngầm As-Is

Core

Chủ sở hữu thượng nguồn tạo hoặc xác nhận đầu vào trước khi BA mô tả hiện trạng. Chủ sở hữu hạ nguồn nhận kết quả để quyết định, xây dựng, kiểm thử hoặc vận hành. Handoff là bàn giao có kiểm tra: người giao nêu phạm vi, bằng chứng và điểm chưa rõ; người nhận xác nhận đã nhận đủ để làm việc, không phải phê duyệt nội dung.

Quan hệ bàn giao	Owner giao	Owner nhận	Nội dung bàn giao	Giới hạn thẩm quyền	Escalation
Hiện trạng kho và sản xuất	Process Owner Kho/Sản xuất	Business Analyst	Quan sát quy trình, biểu mẫu, vai trò, ngoại lệ đang dùng	Process Owner mô tả thực tế, không tự quyết thay đổi ERP	Mâu thuẫn giữa các bộ phận: Business Owner quyết định ưu tiên làm rõ
Quy tắc nghiệp vụ	Business Owner	Business Analyst	Quy tắc, mục tiêu, phạm vi quyết định nghiệp vụ	BA không tự xác nhận quy tắc là chính sách chính thức	Quy tắc ảnh hưởng kế toán, thuế, pháp lý: Accounting Owner hoặc Legal Owner xác minh
Bản đồ As-Is	Business Analyst	Business Owner, Solution Architect, QA	Luồng hiện trạng, pain point, giả định, câu hỏi mở, traceability	BA tổng hợp bằng chứng, không chọn kiến trúc hay ký duyệt yêu cầu	Mâu thuẫn dữ liệu, tích hợp hoặc quyền truy cập: Solution Architect hoặc Security Owner
Test basis cho hiện trạng	Business Analyst	QA	Hành vi hiện tại cần kiểm thử hoặc đối chiếu	QA chọn kỹ thuật kiểm thử, BA không xác nhận chất lượng release	Kết quả test làm thay đổi cách hiểu nghiệp vụ: trả Business Owner và BA
Hướng dẫn vận hành	Delivery Lead	Operations Owner	Thay đổi đã triển khai, giới hạn vận hành, sự cố cần theo dõi	Operations Owner không tự đổi quy tắc nghiệp vụ	Sự cố ảnh hưởng an toàn thực phẩm, dữ liệu cá nhân, sổ sách: gọi domain owner và vai trò pháp lý phù hợp

Applied

Facts: Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Process Owner Kho nói phiếu xuất kho có thể sửa sau khi giao hàng; Accounting Owner nói số liệu đã ghi nhận không được sửa trực tiếp. Hai phát biểu cùng liên quan một bước nhưng thuộc hai thẩm quyền khác nhau.

Current Behavior: BA ghi cả hai phát biểu vào bản đồ As-Is, gắn nguồn vai trò và thời điểm quan sát. BA không gộp thành quy tắc mới vì bằng chứng đang mâu thuẫn.

Underlying Need: Cần xác định ai có quyền giải thích hành vi thao tác kho, ai có quyền xác minh tác động kế toán, và ai quyết định thay đổi quy trình.

Options: Giữ mô tả mâu thuẫn; cho Process Owner tự chọn; hoặc escalation theo thẩm quyền.

Decision Criteria: Quyết định phải thuộc đúng domain, có bằng chứng truy vết, không biến giả định thành quy tắc canonical, không suy diễn nghĩa vụ pháp lý hoặc kế toán.

Decision: Escalation tới Business Owner để quyết định mục tiêu quy trình; Accounting Owner xác minh ảnh hưởng ghi nhận. BA chỉ cập nhật bản đồ sau khi nhận kết luận được ghi nhận trong artifact kiểm soát.

Authority: Business Owner quyết định nghiệp vụ; Accounting Owner xác minh phần kế toán; BA duy trì traceability. CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY đang IN_REVIEW, v0.9.0, không phải baseline hay approval.

Artifact: Bản đồ As-Is trong /02-handbook/04-current-state-as-is-and-process-mapping.md tham chiếu nguồn vai trò; quy tắc chỉ được liên kết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md khi có nội dung phù hợp được ghi nhận.

Consequence if Wrong: BA tự chọn một diễn giải có thể làm đội Delivery xây sai luồng, QA kiểm thử sai test basis, hoặc Operations áp dụng thao tác gây sai lệch dữ liệu mô phỏng.

Senior Lens

Escalate khi câu hỏi vượt quyền người đang trả lời. Dấu hiệu gồm: thay đổi tiền, sổ sách, thuế, dữ liệu cá nhân, an toàn thực phẩm, quyền truy cập, kiến trúc tích hợp hoặc cam kết vận hành. Bằng chứng là mỗi lĩnh vực có owner chuyên môn riêng; vì vậy Process Owner không thay Accounting Owner, Legal Owner, Security Owner hay Solution Architect.

Không dùng từ “được phê duyệt”, “đã baseline” hoặc “tuân thủ” cho Nova Foods. IN_REVIEW chỉ cho biết artifact đang xem xét. Handoff hoàn tất về mặt làm việc khi người nhận xác nhận đủ thông tin để tiếp tục; nó không chuyển thẩm quyền quyết định.

Quick Reference

Tình huống	BA làm	BA không làm
Owner bất đồng	Ghi nguyên nguồn, phạm vi bất đồng, escalation owner phù hợp	Tự chọn ý kiến nghe hợp lý hơn
Thiếu bằng chứng	Gắn nhãn giả định hoặc Verification required	Biến suy đoán thành fact
Vấn đề liên quan hai domain	Tách quyết định theo owner, giữ một traceability record	Ép một owner ký thay domain khác
Người nhận từ chối handoff	Bổ sung nội dung thiếu, ghi rõ điểm chặn	Đẩy tiếp artifact chưa đủ dùng

Core

Bản đồ vòng đời đặt Current State As-Is Process Mapping vào chuỗi làm việc ERP Nova Foods Trading & Manufacturing, case mô phỏng giáo dục, dữ liệu tổng hợp. Sơ đồ này là Mermaid flowchart, không phải BPMN 2.0.2; BPMN thuộc chuẩn OMG riêng. Mục đích: người đọc thấy As-Is map xuất hiện trước khi đội dự án thiết kế thay đổi, rồi tiếp tục làm test basis và tài liệu vận hành.

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

flowchart TB
    D[Discovery<br/>Nhận diện vấn đề và phạm vi] --> A[Analysis<br/>Thu thập, xác thực và mô hình hóa As-Is]
    A --> DL[Delivery<br/>Dùng As-Is làm căn cứ thiết kế thay đổi]
    DL --> T[Testing<br/>Dùng As-Is làm đường cơ sở phân biệt hành vi cũ, lỗi mới và thay đổi dự kiến]
    T --> R[Release<br/>Phát hành thay đổi đã kiểm thử]
    R --> O[Operations<br/>Dùng As-Is đối chiếu vận hành, hỗ trợ tài liệu và ghi nhận lệch thực tế]
    O --> D

As-Is map không mô tả trạng thái tương lai. Nó ghi nhận cách quy trình đang chạy: ai làm, dữ liệu nào đi qua, điểm chờ, ngoại lệ, kiểm soát và điểm đau. Suy luận: Delivery không thể sửa quy trình đáng tin nếu không biết hành vi hiện có; Testing không thể phân biệt lỗi mới với hành vi cũ nếu thiếu điểm so sánh.

Applied

Mục	Nội dung mô phỏng Nova Foods
Facts	Nhân viên kho nhận phiếu nhập từ email, ghi số lô vào bảng tính, rồi nhập ERP cuối ngày.
Current Behavior	Một lô nguyên liệu có thể chờ đến cuối ngày mới xuất hiện trong ERP.
Underlying Need	Cần thấy chuỗi nhận hàng hiện hữu trước khi quyết định thay đổi thời điểm nhập ERP.
Options	Vẽ As-Is chỉ theo bước thao tác; hoặc vẽ cả tác nhân, dữ liệu, chờ đợi và ngoại lệ.
Decision Criteria	Bản đồ phải giúp nhận ra nơi dữ liệu lô bị trễ và đủ chi tiết để tạo test basis.
Decision	Vẽ luồng có tác nhân, phiếu nhập, bảng tính, ERP và điểm chờ cuối ngày.
Authority	Business Owner xác nhận thực tế nghiệp vụ; BA ghi nhận và duy trì traceability. BA không tự xác nhận cấu hình ERP hay quy định an toàn thực phẩm.
Artifact	Current State As-Is Process Map, trạng thái IN_REVIEW, phiên bản v0.9.0.
Consequence if Wrong	Đội Delivery có thể tự động hóa sai điểm nghẽn; QA có thể kiểm thử theo luồng không tồn tại.

Senior Lens

Đặt As-Is map ở Analysis không có nghĩa Discovery không dùng nó. Discovery dùng bản nháp để làm rõ vấn đề. Analysis biến nháp thành mô hình có bằng chứng. Delivery dùng mô hình đã rà soát làm đầu vào thiết kế. Testing dùng mô hình để chọn tình huống kiểm thử hồi quy. Operations dùng phản hồi thực tế để phát hiện mô hình đã cũ.

Không suy diễn nghĩa vụ pháp lý, kế toán, truy xuất thực phẩm từ sơ đồ. Nếu luồng chạm dữ liệu cá nhân, hóa đơn, sổ kế toán hoặc truy xuất lô, gắn nhãn Verification required và chuyển vấn đề cho Legal Owner, Accounting Owner hoặc domain owner phù hợp. Sơ đồ học liệu không chứng minh Nova Foods tuân thủ luật hay đang vận hành ERP thật.

Quick Reference

Thành phần sơ đồ	Câu hỏi phải trả lời
Discovery	Vấn đề nào khiến cần khảo sát quy trình?
Analysis	Quy trình hiện tại thực sự chạy ra sao?
Delivery	Thay đổi nào dựa trên hiểu biết As-Is?
Testing	Hành vi nào cần đối chiếu trước và sau thay đổi?
Release	Thay đổi nào đi vào môi trường vận hành?
Operations	Thực tế mới có còn khớp As-Is map và giả định không?

4. Input c?n thi?t

Core

Đầu vào của As-Is là thứ BA dùng để mô tả quy trình đang xảy ra, không phải thứ BA muốn quy trình phải xảy ra. Người mới không cần biết ERP trước: ERP (Enterprise Resource Planning) là hệ thống quản lý nguồn lực doanh nghiệp; trong As-Is, ERP chỉ là một nguồn có thể lưu dấu vết. Quy trình còn có thể chạy bằng người, giấy, Excel, email hoặc trao đổi trực tiếp.

BA cần lập kiểm kê bốn nhóm đầu vào trước khi vẽ luồng:

Nhóm	Cần có	Mục đích
Kiến thức nền	Tên quy trình, mục tiêu, tác nhân, đầu vào, đầu ra, điểm bắt đầu và kết thúc	Hiểu phạm vi quan sát trước khi gán bước cho người hoặc hệ thống
Bằng chứng	Phiếu, ảnh màn hình, file, nhật ký hệ thống, email nghiệp vụ, quan sát thao tác	Chứng minh bước As-Is có xảy ra thay vì suy đoán
Artifact nguồn	Tệp kiểm soát, biểu mẫu, báo cáo, danh mục dữ liệu, sơ đồ cũ	Cho phép người khác truy ngược cách BA hình thành mô hình
Canonical ID	Định danh giữ nguyên giữa tài liệu	Nối process map với nguồn, quy tắc, dữ liệu và quyết định mà không nhầm bản sao

Canonical ID là mã định danh chuẩn, không đổi vì cách diễn đạt thay đổi. Ví dụ CANONICAL_DATA_DICTIONARY luôn chỉ kế hoạch từ điển dữ liệu logic; không thay bằng “data dictionary” hoặc tên tệp xuất PDF. Cầu nối suy luận: nếu cùng một khái niệm có nhiều tên, người đọc có thể nối sai nguồn; ID cố định loại giảm mơ hồ đó.

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

flowchart TB
    A[Kiến thức nền] --> E[BA xác định phạm vi As-Is]
    B[Bằng chứng] --> F[BA ghi nhận hành vi hiện tại]
    C[Artifact nguồn] --> G[BA truy ngược cách hình thành mô hình]
    D[Canonical ID] --> I[BA nối process map với nguồn, quy tắc, dữ liệu và quyết định]
    C --> I
    E --> H[Current State As-Is Process Map]
    F --> H
    G --> H
    I --> H

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Toàn bộ giá trị dưới đây là dữ liệu tổng hợp, không mô tả doanh nghiệp thật hay cấu hình ERP thật.

Trường	Nội dung
Facts	Nhóm học liệu khảo sát quy trình nhận hàng nguyên liệu tại kho mô phỏng. Có phiếu nhập kho mẫu, bảng Excel theo dõi lô và ảnh màn hình ERP mô phỏng.
Current Behavior	Nhân viên kho nhận hàng, ghi số lô lên phiếu giấy, sau đó nhập lại thông tin vào ERP vào cuối ca.
Underlying Need	Cần biết bước thực tế, chứng cứ của từng bước và ID nguồn trước khi vẽ As-Is map.
Options	Chỉ phỏng vấn nhân viên; chỉ dùng tài liệu có sẵn; kết hợp lời kể với artifact và dấu vết hệ thống.
Decision Criteria	Mỗi bước quan trọng phải truy được ít nhất một nguồn; tên artifact và ID phải giữ nguyên; không biến giả định thành fact.
Decision	Dùng kết hợp lời kể, phiếu mẫu, Excel mẫu và ảnh màn hình mô phỏng. Gắn nhãn mục chưa xác minh thay vì tự điền quy tắc.
Authority	Business Owner mô phỏng xác nhận hành vi nghiệp vụ; BA duy trì mô hình và traceability. Legal Owner, Accounting Owner, domain owner giữ thẩm quyền cho kết luận chuyên môn tương ứng.
Artifact	/02-handbook/04-current-state-as-is-and-process-mapping.md, Current State As-Is Process Map, trạng thái IN_REVIEW, phiên bản v0.9.0.
Consequence if Wrong	BA có thể vẽ bước nhập ERP là thời gian thực dù thực tế nhập cuối ca; Delivery và QA sau đó thiết kế theo hành vi sai.

Canonical ID / tên giữ nguyên	Loại đầu vào	Giá trị tổng hợp Nova Foods	Vai trò khi lập As-Is	Trạng thái xác minh
CHAPTER_MANIFEST	Artifact quản trị	/01-curriculum/CHAPTER_MANIFEST.md	Giữ đúng tên chapter và phạm vi handbook	Có trong dependency
TRACEABILITY_ID_REGISTRY	Registry định danh	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra mã nguồn và liên kết không bị đổi tên	Có trong dependency
CANONICAL_BUSINESS_RULES	Catalog quy tắc	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Phân biệt quy tắc đã catalog với lời kể nghiệp vụ	Có trong dependency; nội dung quy tắc Nova Foods không được suy diễn
CANONICAL_DATA_DICTIONARY	Từ điển dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Giữ nghĩa nhất quán cho LotNumber, ReceiptDate, SupplierCode khi các trường này xuất hiện	Có trong dependency
NF-WH-GRN-2026-0087	Phiếu nhập kho mô phỏng	Phiếu nhận 12.500 kg đường tinh luyện, ngày 2026-08-05	Bằng chứng giấy cho bước nhận hàng và ghi lô	Synthetic evidence
NF-WH-LOT-TRACKER-2026-08.xlsx	Bảng tính mô phỏng	Dòng LOT-SUG-260805-A, trạng thái Chờ nhập ERP	Bằng chứng nhập lại cuối ca	Synthetic evidence
NF-ERP-RCV-IMG-2026-08-05-01	Ảnh màn hình ERP mô phỏng	Giao dịch nhận hàng lúc 17:42 theo Asia/Ho_Chi_Minh	Bằng chứng thời điểm nhập hệ thống	Synthetic evidence
NF-INT-2026-08-06-WH01	Ghi nhận phỏng vấn mô phỏng	Nhân viên kho nói phiếu giấy được ký trước khi nhập ERP	Bổ sung ngữ cảnh cho artifact	Verification required: cần đối chiếu quan sát thao tác
SRC-READY-010	Quy tắc nguồn corpus	Nova Foods là mô phỏng giáo dục	Chặn diễn giải dữ liệu tổng hợp thành sự thật doanh nghiệp	Có trong dependency

Senior Lens

Không coi phỏng vấn là bằng chứng duy nhất. Lời kể cho biết người thực hiện hiểu quy trình thế nào; phiếu, file và dấu vết hệ thống cho biết thứ gì đã được ghi lại. Hai nguồn mâu thuẫn không cho phép BA chọn nguồn “có vẻ hợp lý hơn”. BA phải giữ cả hai, nêu mâu thuẫn và ghi đúng trạng thái Verification required.

Không đổi mã để đẹp câu. NF-WH-GRN-2026-0087 là nhận diện của một chứng cứ mô phỏng; đổi thành “Phiếu nhập tháng 8” làm mất khả năng liên kết từ map về nguồn. Tương tự, URL nguồn chuẩn và phân loại nguồn phải giữ ranh giới: BABOK Guide hỗ trợ thuật ngữ BA; BPMN 2.0.2 là nguồn ký pháp BPMN; PlantUML hoặc Mermaid không tự trở thành BPMN.

Quick Reference

Khi gặp	BA ghi gì
Người dùng nói có một bước	Ghi lời kể, người nói, mã ghi nhận và nhãn chưa đối chiếu
Có phiếu hoặc file	Ghi tên tệp hoặc ID nguyên dạng, loại artifact và bước mà nó hỗ trợ
Có ảnh màn hình hệ thống	Ghi ID ảnh, thời điểm hiển thị và hành vi quan sát được
Có quy tắc hoặc định nghĩa dữ liệu	Tham chiếu CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY, không chép lại thành quy tắc mới
Không có chứng cứ đủ	Giữ mục Verification required; không tự hoàn thiện luồng bằng kiến thức phần mềm

Core

Đầu vào chỉ dùng được khi người đọc biết nó đến từ đâu, còn mới hay không, ai chịu trách nhiệm, và khi nào phải dừng phân tích. Phân loại nguồn là nhãn nói mức thẩm quyền của bằng chứng: PRIMARY là tài liệu chính thức do bên có thẩm quyền phát hành; CONTROLLED_INTERNAL là artifact nội bộ có ID, phiên bản và Owner; WORKING_EVIDENCE là ghi chép quan sát hoặc trao đổi chưa được xác nhận; ASSUMPTION là giả định dự án; VERIFICATION_REQUIRED là thông tin chưa đủ căn cứ để biến thành mô tả current state.

Kiểm tra chất lượng	Câu hỏi kiểm tra	Đạt khi	Không đạt thì
Nhận diện	Có ID, tên tệp hoặc URL canonical?	Truy ngược đúng nguồn	Gắn VERIFICATION_REQUIRED; không suy diễn
Thẩm quyền	Issuer hoặc Owner có quyền xác nhận nội dung?	Vai trò phù hợp lĩnh vực	Escalate đúng Owner
Toàn vẹn	Bản ghi có đủ ngữ cảnh, ngày, phiên bản?	Không bị cắt nghĩa	Không trích rule hay luồng
Tươi mới	Nội dung còn phù hợp mốc 2026-08-07?	Có ngày/version hoặc xác nhận còn hiệu lực	Dừng dùng làm fact
Nhất quán	Có mâu thuẫn nguồn canonical khác?	Không mâu thuẫn chưa giải quyết	Dừng mapping phần bị ảnh hưởng
Ranh giới	Có bị diễn đạt vượt thẩm quyền pháp lý, kế toán, production?	Chỉ nêu fact được chứng minh	Gắn nhãn và escalation

Độ tươi mới không có một số ngày chung cho mọi nguồn. Tài liệu có version dùng version hiện hành tại ngày truy cập; bằng chứng vận hành dùng ngày quan sát; quy định pháp lý cần kiểm tra nguồn chính thức và Owner pháp lý. Lý do: cùng một nội dung có thể đúng lịch sử nhưng sai current state.

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

flowchart TB
    A[Nhận đầu vào] --> B{Phân loại nguồn}
    B -- PRIMARY --> C{Có ID, tên tệp hoặc URL canonical?}
    B -- CONTROLLED_INTERNAL --> C
    B -- WORKING_EVIDENCE --> V[VERIFICATION_REQUIRED<br/>Bổ sung hoặc xác minh nguồn]
    B -- ASSUMPTION --> V
    B -- VERIFICATION_REQUIRED --> V
    V -- Đã bổ sung/xác minh nguồn --> B

    C -- Không --> V
    C -- Có --> D{Issuer hoặc Owner đủ thẩm quyền?}
    D -- Có --> E{Đủ ngữ cảnh, ngày và phiên bản?}
    D -- Không --> Y[Escalate đúng Owner]
    Y --> YA{Đã được Owner xác nhận?}
    YA -- Có --> E
    YA -- Không --> Z[STOP: không dùng làm fact current state]

    E -- Không --> V
    E -- Có --> F{Còn mới tại 2026-08-07?}
    F -- Không --> Z
    F -- Có --> G{Mâu thuẫn nguồn canonical?}
    G -- Không --> H{Vượt ranh giới pháp lý,<br/>kế toán hoặc production?}
    G -- Có --> M[Giải quyết mâu thuẫn nguồn]
    M --> MA{Mâu thuẫn đã giải quyết?}
    MA -- Có --> H
    MA -- Không --> Z

    H -- Không --> J[Accepted current-state fact<br/>Dùng cho current-state mapping]
    H -- Có --> N[Gắn nhãn; escalate Owner phù hợp]
    N --> NA{Đã xác nhận trong ranh giới?}
    NA -- Có --> J
    NA -- Không --> Z

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi giá trị dưới đây là dữ liệu tổng hợp.

Mục	Nội dung
Facts	/01-curriculum/TRACEABILITY_ID_REGISTRY.md có Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07; /01-curriculum/CANONICAL_BUSINESS_RULES.md cũng IN_REVIEW.
Current Behavior	BA chỉ ghi nhận hai artifact là bằng chứng quản trị corpus, không gọi đó là baseline hay quy tắc vận hành ERP.
Underlying Need	Process map cần phân biệt fact đã kiểm soát với nội dung còn chờ xác minh.
Options	Dùng mọi artifact IN_REVIEW như fact vận hành; hoặc chỉ dùng metadata được chứng minh, gắn nhãn phần chưa xác minh.
Decision Criteria	Không tạo approval ngầm định; giữ đúng ID canonical; không vượt thẩm quyền Owner.
Decision	Chọn phương án hai. IN_REVIEW chứng minh trạng thái xem xét, không chứng minh phê duyệt hay hiệu lực vận hành.
Authority	Principal IT Business Analyst / Technical Curriculum Author giữ quản trị artifact; Business Owner, Legal Owner, Accounting Owner hoặc Architect xác nhận nội dung thuộc thẩm quyền họ.
Artifact	00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Process map có thể biến kế hoạch học liệu thành rule ERP, tạo traceability sai và quyết định vượt thẩm quyền.

Senior Lens

Dừng phân tích ngay khi thiếu một trong bốn điều kiện: nguồn định danh được, Owner phù hợp, độ tươi mới kiểm tra được, hoặc mâu thuẫn canonical đã được xử lý. Dừng không phải thất bại. Dừng ngăn BA điền khoảng trống bằng kinh nghiệm cá nhân rồi gọi nó là current state.

Không dùng PRIMARY để tự suy ra nghĩa vụ chi tiết nếu nguồn chỉ có overview hoặc abstract. Ví dụ, URL ISO/IEC/IEEE 29148 xác nhận bibliographic status; không đủ căn cứ để nêu số clause chưa kiểm tra licensed text. Với luật, kế toán, thuế, an toàn thực phẩm và dữ liệu cá nhân, chỉ Legal Owner, Accounting Owner hoặc domain owner phù hợp mới xác nhận diễn giải áp dụng.

Quick Reference

Nhãn	Được dùng để	Không được dùng để
PRIMARY	Xác nhận nguồn chính thức, version, phạm vi công bố	Tự tạo clause, nghĩa vụ hoặc diễn giải ngoài nguồn
CONTROLLED_INTERNAL	Truy vết ID, metadata, lịch sử quản trị	Khẳng định approval hoặc baseline khi status là IN_REVIEW
WORKING_EVIDENCE	Ghi nhận quan sát để hỏi lại	Khẳng định quy trình chuẩn
ASSUMPTION	Giữ giả định minh bạch trong phân tích	Viết thành fact hoặc business rule
VERIFICATION_REQUIRED	Đánh dấu khoảng trống cần Owner xác nhận	Bỏ qua rồi tiếp tục suy diễn
STOP	Chặn map phần thiếu căn cứ hoặc mâu thuẫn	Tự giải quyết thay vai trò có thẩm quyền

Core

Bảng dưới là bộ đầu vào hoàn chỉnh cho phân tích As-Is của Nova Foods Trading & Manufacturing, case mô phỏng giáo dục. Mọi giá trị Nova Foods là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. IN_REVIEW và v0.9.0 chỉ nói trạng thái corpus, không xác nhận vận hành thật, baseline hay phê duyệt.

ID liên kết bền vững	Đầu vào Nova Foods mô phỏng	Giá trị tổng hợp dùng phân tích	Phân loại nguồn	Artifact/tệp nguồn canonical	Chủ sở hữu nguồn	Độ mới tại 2026-08-07	Trạng thái xác minh	Hạng mục chưa giải quyết
CHAPTER_MANIFEST	Phạm vi chapter As-Is	Chapter 04, section 4/12; chỉ mô tả đầu vào cho current state	Nguồn quản trị nội bộ corpus	/01-curriculum/CHAPTER_MANIFEST.md	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Đã ghi nhận metadata	Không phải bằng chứng quy trình ERP thật
TRACEABILITY_ID_REGISTRY	Quy ước giữ ID khi nối nguồn, phát hiện, yêu cầu	Giữ nguyên ID artifact; không tạo ID thay thế cho nguồn canonical	Nguồn quản trị nội bộ corpus	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Đã ghi nhận metadata	Verification required: registry chi tiết không xuất hiện trong trích đoạn đầu vào
CANONICAL_BUSINESS_RULES	Catalog quy tắc cần đối chiếu	Chưa dùng rule nào làm fact vận hành	Nguồn quản trị nội bộ corpus	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Chỉ có kế hoạch catalog	Verification required: rule nhận hàng, xuất kho, duyệt giá chưa có nội dung rule được xác minh
CANONICAL_DATA_DICTIONARY	Tên và nghĩa dữ liệu nghiệp vụ	Mã hàng, Số lô, Số lượng, Kho, Nhà cung cấp là nhãn khảo sát mô phỏng	Nguồn quản trị nội bộ corpus	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Chỉ có kế hoạch dictionary	Verification required: kiểu dữ liệu, độ dài, khóa chính, danh mục giá trị
00_SOURCE_MAP	Ranh giới dùng nguồn ngoài	BABOK Guide dùng thuật ngữ BA; BPMN 2.0.2 chỉ dùng khi vẽ BPMN chuẩn	Nguồn nghiên cứu đã xác minh URL	/00-research/00_SOURCE_MAP.md	Principal IT Business Analyst / Technical Curriculum Author	Truy cập URL 2026-08-07	URL và boundary đã ghi nhận	Không suy diễn điều khoản, trang, hay nghĩa vụ pháp lý
Không có ID nghiệp vụ được đăng ký	Nhật ký nhận nguyên liệu mô phỏng	Ngày 2026-08-05; nguyên liệu Bột mì; số lượng 1.200 kg; kho Kho NL-01; nhà cung cấp NCC-MP-01	Bằng chứng vận hành tổng hợp	Dòng dữ liệu tổng hợp trong bảng này	Business Owner mô phỏng	2 ngày	Fact mô phỏng, không phải chứng từ thật	Verification required: ai lập, ai kiểm, thời điểm ghi sổ và hệ thống nguồn
Không có ID nghiệp vụ được đăng ký	Bảng tồn kho cuối ngày mô phỏng	Bột mì: 8.450 kg; Đường: 2.100 kg; thời điểm 17:00 ngày 2026-08-05	Bằng chứng dữ liệu tổng hợp	Dòng dữ liệu tổng hợp trong bảng này	Warehouse Owner mô phỏng	2 ngày	Fact mô phỏng, không phải tồn kho thật	Verification required: tồn khả dụng có trừ hàng giữ chỗ hay không
Không có ID nghiệp vụ được đăng ký	Trao đổi nghiệp vụ được cấu trúc mô phỏng	Nhân viên kho ghi nhận nhận hàng trước; kế toán đối chiếu chứng từ sau	Quan sát/phỏng vấn tổng hợp	Dòng dữ liệu tổng hợp trong bảng này	Warehouse Owner và Accounting Owner mô phỏng	Không có timestamp gốc	Giả định minh họa	Verification required: thứ tự bước, ngoại lệ thiếu hàng, quyền sửa số lượng
Không có ID nghiệp vụ được đăng ký	Ảnh chụp màn hình ERP	Không có ảnh chụp được cung cấp	Bằng chứng thiếu	Không có artifact nguồn	System Owner mô phỏng	Không áp dụng	Không đủ dùng	Verification required: tên màn hình, trường bắt buộc, trạng thái chứng từ, audit trail

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

flowchart TB
    subgraph OP["Bằng chứng và quan sát mô phỏng"]
        A["Nhật ký nhận hàng<br/>fact mô phỏng<br/>Chủ sở hữu: Business Owner mô phỏng"]
        B["Bảng tồn kho cuối ngày<br/>fact mô phỏng<br/>Chủ sở hữu: Warehouse Owner mô phỏng"]
        D["Trao đổi nghiệp vụ<br/>giả định minh họa<br/>Chủ sở hữu: Warehouse Owner và Accounting Owner mô phỏng"]
    end

    subgraph GOV["Nguồn quản trị corpus — không phải bằng chứng vận hành"]
        E["CHAPTER_MANIFEST<br/>metadata phạm vi chapter<br/>Chủ sở hữu: Principal IT Business Analyst / Technical Curriculum Author"]
        G["TRACEABILITY_ID_REGISTRY<br/>registry chi tiết chưa xuất hiện<br/>Chủ sở hữu: Principal IT Business Analyst / Technical Curriculum Author"]
        H["CANONICAL_BUSINESS_RULES<br/>catalog chưa có rule xác minh<br/>Chủ sở hữu: Principal IT Business Analyst / Technical Curriculum Author"]
        I["CANONICAL_DATA_DICTIONARY<br/>dictionary chưa có định nghĩa xác minh<br/>Chủ sở hữu: Principal IT Business Analyst / Technical Curriculum Author"]
        J["00_SOURCE_MAP<br/>BABOK: thuật ngữ BA<br/>BPMN 2.0.2: chỉ khi vẽ BPMN chuẩn<br/>Chủ sở hữu: Principal IT Business Analyst / Technical Curriculum Author"]
    end

    subgraph MISS["Bằng chứng thiếu"]
        K["Ảnh chụp màn hình ERP<br/>không được cung cấp<br/>Chủ sở hữu: System Owner mô phỏng"]
    end

    A --> L["Phân loại đầu vào<br/>fact mô phỏng và giả định minh họa"]
    B --> L
    D --> L

    E --> M["Ranh giới phân tích<br/>metadata, catalog chưa xác minh<br/>nguồn ngoài không là fact vận hành"]
    G --> M
    H --> M
    I --> M
    J --> M

    L --> N["Phân tích As-Is<br/>không xác nhận vận hành thật"]
    M --> N

    A --> W["Chưa có ID nghiệp vụ được đăng ký"]
    B --> W
    D --> W
    K --> W

    N --> O["Hạng mục chưa xác minh"]
    K --> O
    W --> O

    O --> P["Nhật ký nhận hàng<br/>ai lập, ai kiểm, thời điểm ghi sổ, hệ thống nguồn<br/>Chủ sở hữu: Business Owner mô phỏng"]
    O --> Q["Tồn kho cuối ngày<br/>tồn khả dụng có trừ hàng giữ chỗ<br/>Chủ sở hữu: Warehouse Owner mô phỏng"]
    O --> R["Trao đổi nghiệp vụ<br/>thứ tự bước, thiếu hàng, quyền sửa số lượng<br/>Chủ sở hữu: Warehouse Owner và Accounting Owner mô phỏng"]
    O --> S["ERP<br/>tên màn hình, trường bắt buộc, trạng thái, audit trail<br/>Chủ sở hữu: System Owner mô phỏng"]
    O --> T["TRACEABILITY_ID_REGISTRY<br/>registry chi tiết không xuất hiện trong trích đoạn<br/>Chủ sở hữu: Principal IT Business Analyst / Technical Curriculum Author"]
    O --> U["CANONICAL_BUSINESS_RULES<br/>rule nhận hàng, xuất kho, duyệt giá chưa xác minh<br/>Chủ sở hữu: Principal IT Business Analyst / Technical Curriculum Author"]
    O --> V["CANONICAL_DATA_DICTIONARY<br/>kiểu dữ liệu, độ dài, khóa chính, danh mục giá trị<br/>Chủ sở hữu: Principal IT Business Analyst / Technical Curriculum Author"]

Applied

Facts: Nova Foods mô phỏng có nhận 1.200 kg bột mì ngày 2026-08-05; bảng tồn ghi 8.450 kg lúc 17:00. Current Behavior: bằng chứng mô phỏng nói kho ghi nhận trước, kế toán đối chiếu sau. Underlying Need: mô tả hiện trạng mà không biến giả định thành fact. Options: dùng dữ liệu tổng hợp có nhãn; hoặc dừng phân tích đến khi có chứng từ thật. Decision Criteria: học liệu cần minh họa đầy đủ, không được khẳng định vận hành thật. Decision: dùng dữ liệu tổng hợp, gắn từng khoảng trống là Verification required. Authority: Business Owner, Warehouse Owner, Accounting Owner mô phỏng chỉ là vai trò cần xác minh; không có phê duyệt được ghi nhận. Artifact: bảng đầu vào này trong /02-handbook/04-current-state-as-is-and-process-mapping.md. Consequence if Wrong: BA có thể vẽ sai luồng nhận hàng, sai nguồn số tồn, rồi truyền sai test basis cho bước sau.

Senior Lens

Một bảng đầu vào không phải bằng chứng tự thân. Cột “Phân loại nguồn” tách fact, giả định, nguồn quản trị và bằng chứng thiếu; vì mỗi loại có sức nặng khác nhau. Bridge suy luận: dữ liệu tồn chỉ có số lượng và thời điểm, không có định nghĩa “tồn khả dụng”; vì vậy không thể kết luận số đó dùng được để bán hay sản xuất.

Quick Reference

Nhãn	Nghĩa dùng trong bảng
Fact mô phỏng	Giá trị tổng hợp để học, không chứng minh Nova Foods thật
Nguồn quản trị	Xác định ID, phạm vi, trạng thái artifact; không xác nhận quy trình
Verification required	Thiếu bằng chứng hoặc thiếu thẩm quyền để kết luận
Bằng chứng thiếu	Không được thay bằng suy đoán

5. Step-by-step BA Activities

Core

BA thực hiện theo chuỗi: chuẩn bị bằng chứng, thu thập hiện trạng, mô hình hóa, kiểm tra chéo, review, rồi bàn giao có kiểm soát. Mỗi kết luận phải nối được từ bằng chứng đến nhận định; thiếu bằng chứng phải giữ nhãn Verification required, không tự lấp khoảng trống.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp. Artifact đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Facts: kho mô phỏng nhận 1.200 kg bột mì ngày 2026-08-05; bảng tồn mô phỏng ghi 8.450 kg lúc 17:00.
Current Behavior: kho ghi nhận nhận hàng trước; kế toán đối chiếu sau.
Underlying Need: xác định luồng thực tế, điểm bàn giao, dữ liệu tạo ra và khoảng trống kiểm soát.
Options: mô hình hóa theo bằng chứng hiện có; hoặc dừng kết luận tại điểm thiếu bằng chứng.
Decision Criteria: không biến dữ liệu tổng hợp thành fact vận hành thật; không suy diễn quy tắc kế toán, pháp lý, an toàn thực phẩm hoặc cấu hình ERP.
Decision: lập as-is flow từ bằng chứng mô phỏng; đánh dấu mọi quy tắc chưa xác minh là Verification required.
Authority: Business Owner, Warehouse Owner và Accounting Owner mô phỏng là vai trò cần cung cấp hoặc xác minh bằng chứng; không có phê duyệt được ghi nhận.
Artifact: /02-handbook/04-current-state-as-is-and-process-mapping.md.
Consequence if Wrong: sai nguồn số tồn hoặc sai điểm đối chiếu; requirement, traceability và test basis sau đó có thể sai.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	BA	Đọc mục tiêu phân tích, artifact upstream và giới hạn nguồn.	Phạm vi nhận hàng và đối chiếu tồn mô phỏng.	Danh sách phạm vi, ngoài phạm vi, nguồn và nhãn phân loại.	Chỉ nhận nguồn có phân loại: Fact mô phỏng, Nguồn quản trị, Bằng chứng thiếu, Verification required.	Không có nguồn nào bị gọi là fact vận hành thật.	Mâu thuẫn phạm vi hoặc ID: Principal IT Business Analyst / Technical Curriculum Author.
2. Lập inventory bằng chứng	BA	Liệt kê từng dữ liệu, người cung cấp mô phỏng, thời điểm và điều dữ liệu chứng minh.	1.200 kg, 8.450 kg, thời điểm 17:00, mô tả kho trước kế toán sau.	Bảng evidence inventory kèm bridge suy luận.	Số lượng chỉ chứng minh giá trị được ghi; không chứng minh “tồn khả dụng”, giá vốn hay quyền bán.	Mỗi nhận định có ít nhất một bằng chứng nguồn hoặc nhãn thiếu bằng chứng.	Thiếu chứng từ nhận hàng: Warehouse Owner mô phỏng. Thiếu căn cứ đối chiếu: Accounting Owner mô phỏng.
3. Phỏng vấn và quan sát mô phỏng	BA	Hỏi theo thứ tự tác nhân, kích hoạt, đầu vào, hành động, đầu ra, ngoại lệ và bàn giao.	Luồng nhận bột mì từ kho sang kế toán.	Ghi chú phiên làm việc, câu trả lời được phân loại là fact mô phỏng hoặc Verification required.	Không chuyển lời kể thành business rule khi chưa có nguồn canonical hoặc owner xác minh.	Kho và kế toán mô tả cùng một điểm bắt đầu, kết thúc và vật thể bàn giao.	Hai vai trò mô tả khác nhau: Business Owner mô phỏng quyết định ưu tiên làm rõ; BA giữ cả hai phiên bản bằng chứng.
4. Vẽ luồng as-is	BA	Chuyển bằng chứng thành bước tuần tự, tác nhân, dữ liệu và điểm chờ.	Quy trình nhận hàng, cập nhật tồn, đối chiếu kế toán.	Sơ đồ as-is và bảng bước quy trình.	Chỉ vẽ hành động được bằng chứng hỗ trợ; dùng “chưa xác minh” cho bước suy đoán.	Mỗi hộp luồng liên kết được về evidence inventory.	Tranh chấp về trình tự hoặc trách nhiệm: Warehouse Owner và Accounting Owner mô phỏng.
5. Phân tích điểm kiểm soát	BA	So sánh dữ liệu đầu vào, đầu ra và thời điểm giữa kho với kế toán.	Phiếu nhận mô phỏng, số tồn mô phỏng, bản ghi đối chiếu.	Danh sách điểm kiểm soát, chênh lệch và rủi ro.	Chênh lệch số lượng, đơn vị tính hoặc thời điểm phải là issue; không tự gán nguyên nhân.	Mỗi issue nêu tác động, bằng chứng, owner cần xác minh và trạng thái.	Nội dung kế toán: Accounting Owner. Nội dung pháp lý hoặc hóa đơn: Legal Owner và Accounting Owner.
6. Xác nhận review	BA	Gửi gói review có phạm vi, luồng, bằng chứng, giả định và câu hỏi mở.	Bản nháp as-is trong artifact hiện hành.	Review log: người review, ngày, nhận xét, phản hồi, trạng thái.	Nhận xét chỉ đóng khi có bằng chứng mới hoặc quyết định từ đúng authority.	Không ghi “approved”; IN_REVIEW giữ nguyên khi chưa có approval reference.	Không thống nhất nội dung: Business Owner mô phỏng. Vấn đề kiến trúc, bảo mật hoặc tích hợp: Architect hoặc Security Owner.
7. Bàn giao có kiểm soát	BA	Đóng gói bản review, evidence inventory, issue log và liên kết traceability cho bước sau.	/02-handbook/04-current-state-as-is-and-process-mapping.md và artifact liên quan.	Handoff record ghi phiên bản v0.9.0, trạng thái IN_REVIEW, ngày 2026-08-07, mục chưa xác minh.	Bên nhận chỉ dùng nội dung làm test basis hoặc phân tích tiếp khi giữ nguyên nhãn nguồn và khoảng trống.	Handoff không làm baseline, không tạo approval, không cho phép production.	Thiếu traceability hoặc thay đổi không kiểm soát: Principal IT Business Analyst / Technical Curriculum Author.

Bridge suy luận: bằng chứng mô phỏng nói kho ghi nhận trước và kế toán đối chiếu sau. Vì bằng chứng không nêu thời điểm khóa sổ, cách tính tồn khả dụng, hay quy tắc ghi nhận kế toán, BA chỉ kết luận thứ tự hoạt động quan sát được. Các kết luận còn lại giữ Verification required.

Senior Lens

Review không phải bước xin đồng ý chung chung. Review kiểm tra ba thứ: bằng chứng có đủ không, suy luận có vượt bằng chứng không, đúng authority có xử lý đúng loại quyết định không. BA quản lý câu hỏi và traceability; BA không thay Business Owner, Accounting Owner, Legal Owner, Architect hoặc Security Owner ra quyết định.

Quick Reference

Kiểm tra trước bàn giao	Điều kiện đạt
Nguồn	Mỗi dữ liệu có phân loại nguồn
Suy luận	Có bridge từ bằng chứng đến nhận định
Khoảng trống	Gắn Verification required
Review	Có review log, không tuyên bố approval
Handoff	Giữ IN_REVIEW, v0.9.0, 2026-08-07

Core

Thủ tục As-Is phải biến quan sát thành bằng chứng kiểm tra được. Mỗi bước nêu rõ người làm, vật được xử lý, quy tắc quyết định, cổng chất lượng và tuyến escalation. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu dưới đây là dữ liệu tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị	BA	Xác định phạm vi, vai trò, nguồn và lịch quan sát	Quy trình As-Is, stakeholder, artifact đầu vào	Danh sách phạm vi và nguồn	Chỉ dùng nguồn có chủ sở hữu hoặc dấu vết tạo lập	Không trộn giả định với fact	Business Owner khi phạm vi nghiệp vụ mơ hồ; Principal IT Business Analyst / Technical Curriculum Author khi xung đột artifact
2. Thu thập	BA, Process Owner	Phỏng vấn, quan sát, đọc chứng từ mẫu	Hành động, dữ liệu, ngoại lệ, điểm bàn giao	Ghi chú nguồn, ảnh chứng từ đã che dữ liệu, log quan sát	Fact cần ít nhất một nguồn xác định; suy luận phải ghi cầu nối chứng cứ	Mỗi phát biểu phân loại fact, inference hoặc Verification required	Process Owner khi mô tả vận hành mâu thuẫn; Legal Owner, Accounting Owner hoặc Security khi nội dung thuộc thẩm quyền chuyên môn
3. Mô hình hóa	BA	Vẽ luồng hiện tại và ghi input, output, quyết định	Chuỗi công việc As-Is	Bản đồ quy trình nháp và bảng bước	Không thêm bước mong muốn; giữ đúng hành vi hiện tại	Mỗi nút có actor, trigger, input, output và ngoại lệ	Architect khi có tích hợp hoặc ranh giới hệ thống; Data Owner khi nghĩa dữ liệu không rõ
4. Xác thực	BA, Process Owner	Đối chiếu mô hình với bằng chứng và diễn viên thực hiện	Bản đồ nháp, ghi chú nguồn	Danh sách chênh lệch và bản cập nhật	Chênh lệch không được tự chọn theo ý BA; phải ghi hai cách hiểu và nguồn	Không còn bước không có evidence hoặc owner	Business Owner khi hai cách vận hành đều được xác nhận nhưng phạm vi chuẩn chưa quyết định
5. Rà soát và handoff có kiểm soát	BA	Đóng gói artifact, giới hạn và vấn đề mở	Bản đồ As-Is, bảng evidence, issue log	Gói bàn giao liên kết /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Chỉ bàn giao nội dung đạt quality gate; nội dung chưa xác minh giữ nhãn Verification required	Không gọi BASELINED hoặc phê duyệt khi chưa có tham chiếu ghi nhận	Principal IT Business Analyst / Technical Curriculum Author điều phối; đúng owner quyết định nội dung chuyên môn

Applied

Trường	Nova Foods ERP mô phỏng: luồng tiếp nhận đơn bán
Facts	Nhân viên Sales nhận đơn qua email; nhập đơn vào ERP; kho kiểm tra tồn; đơn thiếu tồn được giữ chờ. Ghi chú quan sát và email mẫu đã che dữ liệu là evidence.
Current Behavior	Sales nhập đơn trước khi có xác nhận tồn kho. Warehouse phản hồi sau đó bằng email nội bộ.
Underlying Need	Cần mô tả đúng điểm tạo đơn và điểm quyết định tồn kho để nhận diện rủi ro giao hàng sai hẹn. Suy luận này dựa trên fact: xác nhận tồn xuất hiện sau nhập đơn.
Options	Giữ một bước “kiểm tra tồn” sau tạo đơn; hoặc tách thành kiểm tra tự động và kiểm tra thủ công.
Decision Criteria	Chỉ chọn mức chi tiết được evidence hỗ trợ; không suy diễn ERP có kiểm tra tự động khi chưa có log hoặc cấu hình.
Decision	Ghi một bước “Warehouse kiểm tra tồn sau khi Sales tạo đơn”; nhãn Verification required cho cơ chế ERP.
Authority	Process Owner xác nhận hành vi; Architect xác minh cơ chế hệ thống; Business Owner xử lý khác biệt quy trình.
Artifact	Bản đồ As-Is và evidence register tham chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Consequence if Wrong	Đặt sai điểm kiểm tra tồn làm sai phân tích nguyên nhân đơn chờ, sai requirement tương lai và sai test basis.

Senior Lens

Evidence không phải ý kiến phổ biến. Email, log, chứng từ mẫu, quan sát có thời điểm và xác nhận từ Process Owner là bằng chứng có thể đối chiếu. Khi Sales nói “luôn kiểm tra tồn trước”, nhưng email cho thấy Warehouse phản hồi sau tạo đơn, BA ghi mâu thuẫn thay vì chọn lời nói thuận tiện.

Quick Reference

• Fact: điều quan sát hoặc nguồn ghi nhận trực tiếp.
• Inference: kết luận BA; phải nêu fact làm cầu nối.
• Quality gate: điều kiện bắt buộc trước khi chuyển bước.
• Escalation: chuyển vấn đề đến đúng thẩm quyền, không phải chuyển trách nhiệm phán đoán của BA.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Bảng này ghi nhận thực thi As-Is cho luồng xử lý đơn bán hàng có nguy cơ xuất kho vượt tồn khả dụng. “As-Is” nghĩa là cách đang diễn ra; không phải quy trình mục tiêu hay cấu hình ERP đã xác nhận.

Mục	Nội dung thực thi Nova Foods mô phỏng	Bằng chứng và cầu nối suy luận
Facts	Nhân viên Kinh doanh nhận đơn SO-NF-SYN-001; số lượng yêu cầu 1.200 thùng. Báo cáo tồn kho tổng hợp ghi tồn vật lý 1.500 thùng, đã giữ chỗ cho đơn khác 600 thùng.	Bằng chứng: đơn mô phỏng và báo cáo tồn kho mô phỏng. Suy luận: tồn khả dụng là 900 thùng, vì 1.500 trừ 600; đơn 1.200 thùng không đủ tồn khả dụng.
Current Behavior	Nhân viên Kinh doanh gửi email hỏi Kho. Nhân viên Kho kiểm tra file theo dõi riêng, rồi trả lời khả năng giao một phần. Kế toán chỉ biết đơn khi nhận yêu cầu lập hóa đơn.	Bằng chứng: chuỗi trao đổi mô phỏng và mô tả thao tác tay. Suy luận: dữ liệu đơn hàng, giữ chỗ và hóa đơn không được kiểm tra trong cùng một điểm kiểm soát.
Underlying Need	Cần nhận diện sớm chênh lệch giữa số lượng đặt và tồn khả dụng, giữ vết quyết định giao một phần hoặc chờ hàng, trước khi Kho xuất hàng và Kế toán lập hóa đơn.	Cầu nối: chênh lệch 300 thùng tạo rủi ro cam kết giao vượt khả năng. Nhu cầu là kiểm soát quyết định, không phải kết luận ERP phải dùng chức năng cụ thể.
Options	1. Tiếp tục email và file riêng. 2. Ghi nhận kiểm tra tồn khả dụng trong đơn hàng, chặn chuyển xuất kho khi thiếu tồn. 3. Cho phép chuyển xuất kho dù thiếu tồn, rồi xử lý ngoại lệ sau.	Ba lựa chọn mô tả phương án phân tích. Không phương án nào là quyết định triển khai hoặc phê duyệt.
Decision Criteria	Đủ tồn khả dụng; có dấu vết người quyết định; không tạo yêu cầu xuất kho vượt số được cam kết; Kế toán nhận đúng số lượng giao thực tế; ngoại lệ có người chịu trách nhiệm.	Tiêu chí xuất phát từ Facts: tồn khả dụng 900 thấp hơn 1.200. Tiêu chí không diễn giải nghĩa vụ pháp lý hay kế toán.
Decision	Đề xuất mô hình As-Is ghi nhận: chỉ tạo yêu cầu xuất kho tối đa 900 thùng; 300 thùng còn lại chuyển trạng thái chờ quyết định giao phần sau hoặc hủy phần thiếu.	Quyết định ở đây là kết luận phân tích cho case mô phỏng. Cần Business Owner xác nhận nghiệp vụ; Architect xác nhận khả năng hệ thống; Accounting Owner xác nhận tác động chứng từ.
Authority	Business Owner quyết định chính sách giao một phần. Warehouse Manager xác nhận tồn thực tế. Accounting Owner xác nhận thời điểm và số lượng lập chứng từ. Architect xác nhận điểm tích hợp.	BA tổng hợp bằng chứng, không thay các vai trò này quyết định. Nếu bất đồng, giữ cả hai cách hiểu trong artifact và escalation đến đúng authority.
Artifact	Cập nhật mô tả luồng As-Is, bảng quyết định ngoại lệ, điểm đau, nguồn bằng chứng và liên kết đến CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.	Các artifact canonical đang IN_REVIEW, v0.9.0, ngày 2026-08-07; không được gọi là baseline hoặc approved.
Consequence if Wrong	Nếu nhầm tồn vật lý là tồn khả dụng, Kho có thể nhận yêu cầu xuất 1.200 thùng khi chỉ 900 thùng sẵn sàng. Kinh doanh có thể cam kết sai; Kế toán có thể nhận số lượng giao không khớp.	Hậu quả suy ra trực tiếp từ chênh lệch 300 thùng. Đây là rủi ro mô phỏng, không phải khẳng định sự cố thực tế.

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

flowchart TB
    subgraph ASIS["As-Is quan sát mô phỏng"]
        A[Sales nhận đơn SO-NF-SYN-001:<br/>1.200 thùng] --> B[Sales gửi email hỏi Kho]
        B --> C[Kho kiểm tra file theo dõi riêng]
        C --> D[Kho trả lời khả năng giao một phần]
        E[Yêu cầu lập hóa đơn:<br/>điểm kích hoạt chưa xác định] -.-> F[Kế toán biết đơn khi nhận yêu cầu lập hóa đơn]
        D -.-> G[Không có điểm kiểm soát chung<br/>cho đơn, giữ chỗ và hóa đơn]
        F -.-> G
        G --> H[Rủi ro cam kết giao vượt tồn khả dụng]
        G --> I[Rủi ro Kế toán nhận số lượng giao<br/>không khớp]
    end

    subgraph ANALYSIS["Phân tích As-Is; kết luận cần xác nhận"]
        J[Tồn vật lý:<br/>1.500 thùng] --> K[Trừ giữ chỗ:<br/>600 thùng]
        K --> L[Tồn khả dụng:<br/>900 thùng]
        L --> M{Đủ cho đơn<br/>1.200 thùng?}
        M -->|Không; thiếu 300 thùng| N[Đề xuất kiểm soát:<br/>không tạo yêu cầu xuất vượt 900 thùng]
        N --> O{Business Owner cho phép<br/>giao một phần?}

        O -->|Có| P[Ghi vết quyết định giao một phần<br/>và người quyết định]
        P -->|Phần giao| Q[Tạo yêu cầu xuất kho<br/>tối đa 900 thùng]
        Q --> R[Kho xác nhận<br/>số lượng giao thực tế]
        R --> S[Kế toán xử lý chứng từ<br/>theo số lượng giao thực tế]
        P -->|Phần thiếu 300 thùng| T[Ghi nhận ngoại lệ:<br/>chờ giao sau hoặc hủy]
        T --> U[Business Owner chịu trách nhiệm<br/>quyết định ngoại lệ]

        O -->|Không| V[Ghi vết quyết định<br/>không giao một phần]
        V --> W[Không tạo yêu cầu xuất 900 thùng]
        W --> X[Toàn bộ đơn chờ hàng hoặc hủy<br/>theo quyết định Business Owner]
    end

    subgraph AUTHORITY["Trách nhiệm xác nhận"]
        WM[Warehouse Manager<br/>xác nhận tồn thực tế]
        BO[Business Owner<br/>xác nhận chính sách giao một phần]
        AC[Accounting Owner<br/>xác nhận tác động chứng từ]
        AR[Architect xác nhận khả năng hệ thống<br/>và điểm tích hợp]
        Y[Handoff Kho sang Kế toán<br/>cần xác nhận]
        AR -.-> Y
    end

    D -.-> J
    H -.-> M
    WM -.-> J
    BO -.-> O
    AC -.-> S
    BO -.-> U
    BO -.-> X
    Y -.-> R
    Y -.-> S

Sơ đồ là Mermaid flowchart, không phải BPMN. Nó mô tả quan sát As-Is mô phỏng; không xác nhận workflow ERP, tích hợp, chính sách giao hàng, chứng từ hay tuân thủ production.

6. Output thu ???c

Core

Output là artifact, tức sản phẩm có kiểm soát được tạo mới hoặc cập nhật sau khi BA mô tả quy trình hiện tại As-Is. Output không phải ghi chú rời. Nó phải có ID canonical, owner, trạng thái, nội dung tối thiểu và lịch sử thay đổi. Bằng chứng là output sẽ được người review dùng để kiểm tra luồng, quy tắc, dữ liệu và điểm đau; thiếu nguồn hoặc lịch sử làm reviewer không phân biệt được quan sát với suy luận.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Mọi dữ liệu dưới đây là dữ liệu tổng hợp. Trạng thái chung hiện hành: IN_REVIEW; phiên bản v0.9.0; ngày 2026-08-07; múi giờ Asia/Ho_Chi_Minh; locale vi-VN; tiền tệ mô phỏng VND. IN_REVIEW không có nghĩa APPROVED, BASELINED, sẵn sàng production, hay đã được người dùng chấp thuận.

Artifact tạo hoặc cập nhật	Canonical ID	Owner	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Bản mô tả quy trình As-Is trong handbook	Chưa có Artifact ID riêng được đăng ký; dùng đường dẫn canonical /02-handbook/04-current-state-as-is-and-process-mapping.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Phạm vi quy trình, tác nhân, trigger, bước thực tế, quyết định, đầu ra, ngoại lệ, bằng chứng, giả định và giới hạn	Ghi ngày, version, phần thay đổi, lý do, nguồn bằng chứng; không sửa im lặng nội dung đã review
Registry liên kết nguồn và output	TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Liên kết artifact nguồn, quan sát As-Is, rule, dữ liệu, issue và output liên quan	Mỗi liên kết thêm, sửa, xóa phải có ngày Asia/Ho_Chi_Minh, lý do và tác động traceability
Catalog quy tắc nghiệp vụ được phát hiện	CANONICAL_BUSINESS_RULES	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	ID rule, câu rule, điều kiện, ngoại lệ, nguồn, trạng thái xác minh, authority cần xác nhận	Không đổi câu rule hoặc nguồn mà không ghi version, lý do và trạng thái xác minh mới
Từ điển dữ liệu logic được phát hiện	CANONICAL_DATA_DICTIONARY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Tên dữ liệu, nghĩa nghiệp vụ, nguồn tạo, nơi dùng, phân loại, chất lượng và điểm cần xác minh	Ghi thay đổi field, nghĩa, nguồn hoặc phân loại; giữ liên kết đến quan sát As-Is

Không cấp ID mới trong section này. Lý do: TRACEABILITY_ID_REGISTRY là nguồn kiểm soát ID canonical; tự đặt ID ngoài registry tạo hai nguồn chân lý. Nếu cần artifact mới, BA lập đề nghị đăng ký ID và giữ artifact ở trạng thái chưa có ID canonical cho đến khi registry được cập nhật có kiểm soát.

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

flowchart TB
    O[Principal IT Business Analyst / Technical Curriculum Author]
    A[Quan sát As-Is có bằng chứng]
    B[Cập nhật bản mô tả quy trình As-Is]
    C[Cập nhật TRACEABILITY_ID_REGISTRY]
    D[Phát hiện quy tắc nghiệp vụ]
    E[Phát hiện dữ liệu logic]
    F[Cập nhật CANONICAL_BUSINESS_RULES]
    G[Cập nhật CANONICAL_DATA_DICTIONARY]
    N{Phát sinh artifact mới chưa có ID canonical?}
    R[Đề nghị đăng ký ID canonical ngoài section này]
    U[Artifact giữ trạng thái chưa có ID canonical]
    W[Owner cập nhật TRACEABILITY_ID_REGISTRY có kiểm soát]
    X[Registry xác nhận ID canonical cho artifact]
    Y[Ghi lịch sử: ngày, version, lý do, nguồn, tác động traceability]
    H[Kiểm tra nội dung tối thiểu, nguồn bằng chứng và traceability]
    LB[Ghi handbook: ngày, version, phần thay đổi, lý do, nguồn]
    LC[Ghi registry: thời gian Asia/Ho_Chi_Minh, lý do, tác động traceability]
    LF[Ghi rules: version, lý do, nguồn, trạng thái xác minh]
    LG[Ghi dictionary: field, nghĩa, nguồn hoặc phân loại thay đổi; giữ liên kết quan sát As-Is]
    I[IN_REVIEW]
    Z[Không phải APPROVED, BASELINED, production-ready hay user-accepted]

    O --> A
    A --> B
    A --> C
    A --> D
    A --> E
    D --> F
    E --> G
    A --> N
    N -- Có --> R
    R --> U
    U --> W
    W --> X
    X --> Y
    Y --> H
    N -- Không --> H
    B --> LB
    C --> LC
    F --> LF
    G --> LG
    LB --> H
    LC --> H
    LF --> H
    LG --> H
    H --> I
    I --> Z

Sơ đồ là Mermaid flowchart, không phải BPMN. Nó mô tả vòng đời artifact học liệu mô phỏng, không mô tả workflow ERP production.

Applied

Thành phần	Nova Foods micro-example mô phỏng
Facts	Đơn bán hàng mô phỏng yêu cầu 1.200 thùng. Kho báo tồn vật lý 1.500 thùng và số lượng đã giữ chỗ 600 thùng.
Current Behavior	Nhân viên Kinh doanh kiểm tra tồn vật lý trước khi tạo yêu cầu xuất. Kho kiểm tra lại khả năng giao trước khi xác nhận số lượng giao thực tế.
Underlying Need	Reviewer cần thấy rõ vì sao tồn vật lý không đủ làm căn cứ cam kết giao hàng. Bằng chứng: 1.500 - 600 = 900 thùng tồn khả dụng mô phỏng, thấp hơn 1.200 thùng yêu cầu.
Options	Ghi nhận chỉ tồn vật lý; ghi nhận tồn vật lý và tồn đã giữ chỗ; hoặc ghi nhận tồn khả dụng suy ra từ hai số liệu.
Decision Criteria	Output phải phân biệt fact với suy luận, giữ phép tính kiểm tra được, liên kết nguồn và không tự khẳng định chính sách ERP.
Decision	Cập nhật mô tả As-Is bằng cả ba giá trị: tồn vật lý 1.500, giữ chỗ 600, tồn khả dụng suy ra 900 thùng.
Authority	Business Owner xác nhận ý nghĩa nghiệp vụ của “giữ chỗ”; Warehouse Owner xác nhận cách ghi nhận số lượng; Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability. Không vai trò nào được ngầm hiểu đã phê duyệt.
Artifact	/02-handbook/04-current-state-as-is-and-process-mapping.md; TRACEABILITY_ID_REGISTRY; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY. Tất cả giữ IN_REVIEW, v0.9.0.
Consequence if Wrong	Nếu output gọi 1.500 là tồn khả dụng, Kinh doanh có thể cam kết dư 300 thùng. Số 300 suy ra từ 1.200 - 900. Đây là rủi ro mô phỏng.

Senior Lens

Owner chịu trách nhiệm duy trì artifact, không tự xác nhận tính đúng nghiệp vụ. Authority xác nhận nội dung thuộc thẩm quyền, không thay Owner quản lý version và traceability. Tách hai vai trò này ngăn việc “người viết” bị hiểu sai thành “người quyết định”.

Lịch sử thay đổi tối thiểu gồm: Version, ngày theo Asia/Ho_Chi_Minh, người ghi nhận, artifact hoặc mục thay đổi, lý do, nguồn bằng chứng, tác động đến liên kết. Nếu bằng chứng mới mâu thuẫn bằng chứng cũ, giữ cả hai tham chiếu và ghi trạng thái cần xác minh; không xóa dấu vết để tạo cảm giác nhất quán giả.

Quick Reference

Quy tắc	Kiểm tra
Artifact phải truy vết được	Có canonical ID hoặc đường dẫn canonical đã xác định
Fact không được biến thành rule	Có nguồn, phép tính hoặc ghi rõ suy luận
Output chưa được approval	Status còn IN_REVIEW; không có approval reference
Không sửa im lặng	Có dòng change history cho mọi thay đổi nội dung hoặc liên kết
Không vượt thẩm quyền	Legal, Accounting, Security, Architect, Business Owner xác nhận phần việc thuộc vai trò mình khi cần

Core

Output của phân tích As-Is là gói bằng chứng mô tả quy trình hiện tại, không phải thiết kế ERP tương lai. Gói phải cho người review lần được từ quan sát đến kết luận: nguồn nào nói gì, ai làm bước nào, dữ liệu nào đổi trạng thái nào, điểm đau nằm đâu. Bằng chứng thiếu làm suy luận không kiểm tra được; vì vậy mỗi thành phần phải có vị trí, nguồn và liên kết rõ.

Thành phần giải phẫu	Nội dung bắt buộc	Bằng chứng hoặc lý do
Phạm vi quy trình	Tên quy trình, điểm bắt đầu, điểm kết thúc, ngoại lệ nằm trong phạm vi	Ngăn map kéo sang quy trình khác khi bước có cùng tên
Tác nhân	Vai trò nghiệp vụ, hệ thống, đối tác ngoài	Làm rõ trách nhiệm thao tác, không suy diễn cá nhân cụ thể
Luồng công việc	Bước tuần tự, quyết định, bàn giao, vòng lặp sửa	Cho thấy hành vi hiện tại thay vì quy trình mong muốn
Dữ liệu và chứng từ	Dữ liệu vào, dữ liệu tạo hoặc sửa, chứng từ tham chiếu	Dữ liệu là đối tượng di chuyển qua quy trình
Điểm đau	Triệu chứng, tác động, nguyên nhân quan sát được	Tách fact khỏi giả định nguyên nhân gốc
Ranh giới nguồn	Nguồn primary, project assumption, Verification required	Tránh biến thông tin mô phỏng thành fact pháp lý hoặc vận hành
Liên kết truy vết	00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi phù hợp	Giữ một nguồn chuẩn cho nguồn, ID, rule, data

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

flowchart TB
    S([Bắt đầu: xác định phạm vi As-Is])

    S --> B[Phạm vi:<br/>tên quy trình · sự kiện bắt đầu · điểm kết thúc]
    B --> E[Ngoại lệ trong phạm vi:<br/>ngoại lệ quan sát được;<br/>thiếu bằng chứng là gap]
    E --> X[Boundary:<br/>mô tả hiện tại từ quan sát đến kết luận;<br/>không thiết kế ERP tương lai]

    X --> I[BA/PM thu thập gói bằng chứng]
    I --> W[Luồng công việc:<br/>bước · quyết định · bàn giao · vòng lặp sửa]
    I --> O[Trách nhiệm và bàn giao:<br/>vai trò nghiệp vụ · hệ thống · đối tác ngoài]
    I --> DA[Dữ liệu và chứng từ:<br/>dữ liệu vào · dữ liệu tạo/sửa · trạng thái]
    I --> PA[Điểm đau:<br/>triệu chứng · tác động · nguyên nhân quan sát được]

    W --> C{Claim có ranh giới nguồn?}
    O --> C
    DA --> C
    PA --> C

    C -- Primary --> PR[Nguồn primary:<br/>dùng làm bằng chứng]
    C -- Project assumption --> AS[Project assumption:<br/>gắn nhãn rõ, không coi là fact]
    C -- Thiếu nguồn --> G[Verification required:<br/>gap mở · BA/PM xác minh]

    PR --> M[Map As-Is:<br/>bước, owner, bàn giao;<br/>dữ liệu, chứng từ, trạng thái, điểm đau]
    AS --> M
    AS -. Cần xác minh .-> G

    G --> V[BA/PM xác minh:<br/>nguồn · bước · trách nhiệm · dữ liệu · ngoại lệ]
    V --> Q{Đã xác minh?}
    Q -- Có --> U[Ghi nguồn xác nhận;<br/>đổi claim thành nguồn primary]
    U --> M
    Q -- Chưa --> GL[Gap mở:<br/>nội dung thiếu · BA/PM xử lý xác minh]

    M --> D[Quyết định và điều kiện:<br/>gắn business rule khi phù hợp]
    M --> T[Liên kết truy vết:<br/>nguồn · ID · rule · data]
    D --> R[BA/PM review gói bằng chứng]
    T --> R
    GL --> R

    R --> F([Kết thúc: review lần được<br/>từ quan sát đến kết luận;<br/>hoặc gap mở được gắn nhãn])

    T --- SM[00_SOURCE_MAP]
    T --- ID[TRACEABILITY_ID_REGISTRY]
    D --- BR[CANONICAL_BUSINESS_RULES]
    T --- DD[CANONICAL_DATA_DICTIONARY]

    classDef boundary fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
    classDef verified fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
    classDef verify fill:#fff3e0,stroke:#ef6c00,color:#e65100
    classDef assumption fill:#fce4ec,stroke:#c2185b,color:#880e4f

    class S,B,E,X,F boundary
    class PR,U,M,D,T,R verified
    class C,G,V,Q,GL verify
    class AS assumption

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, số liệu, hành vi dưới đây là dữ liệu tổng hợp.

Mục	Nội dung đã điền
Facts	Nhân viên bán hàng nhận đơn mua 120 thùng nước ép từ khách hàng mô phỏng KH-SYN-014. Nhân viên nhập mã đơn SO-SYN-20260807-014 vào bảng theo dõi bán hàng. Kho xác nhận tồn qua điện thoại trước khi chuẩn bị hàng.
Current Behavior	Khi tồn khả dụng đủ, nhân viên bán hàng gửi phiếu yêu cầu xuất kho qua email nội bộ. Khi kho báo thiếu, nhân viên sửa số lượng hoặc ngày giao trong bảng theo dõi. Không có trường ghi lý do sửa trong fact quan sát này.
Underlying Need	Người review cần thấy nơi đơn bị sửa, ai biết thay đổi, dữ liệu nào là bản đang dùng. Evidence: số lượng và ngày giao có thể đổi sau trao đổi điện thoại; bảng theo dõi là nơi nhân viên cập nhật.
Options	Giữ bảng theo dõi và email; dùng một màn hình ERP cho đơn và xác nhận tồn; tích hợp bảng theo dõi với ERP.
Decision Criteria	Khả năng truy vết sửa số lượng; một nguồn dữ liệu đang hiệu lực; giảm nhập lại; quyền thay đổi phù hợp; chi phí thay đổi.
Decision	Chưa chọn phương án. As-Is chỉ ghi hiện trạng và tiêu chí cần cho phân tích To-Be.
Authority	Business Owner quyết định ưu tiên nghiệp vụ; Architect đánh giá phương án hệ thống; Security đánh giá quyền; Principal IT Business Analyst / Technical Curriculum Author duy trì truy vết học liệu.
Artifact	Process map As-Is cho luồng nhận đơn đến giao hàng; bảng điểm đau; liên kết 00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY. Không gán canonical ID mới khi registry chưa ghi nhận ID đó.
Consequence if Wrong	Gán nhầm bước xác nhận tồn là tự động có thể làm scope ERP sai. Bỏ qua sửa đơn sau điện thoại có thể che mất nhu cầu audit trail, quyền sửa và đồng bộ tồn.

Bản đồ ví dụ đầy đủ có năm bước, không ngụ ý Nova Foods đang vận hành ERP thật.

Thứ tự	Tác nhân	Hành động hiện tại	Dữ liệu/chứng từ	Kết quả quan sát	Phân loại nguồn
1	Nhân viên bán hàng	Nhận đơn từ KH-SYN-014	Mã khách, mặt hàng nước ép, số lượng 120 thùng, ngày giao yêu cầu	Có thông tin đơn để xử lý	Synthetic fact
2	Nhân viên bán hàng	Nhập SO-SYN-20260807-014 vào bảng theo dõi bán hàng	Mã đơn, khách hàng, số lượng, ngày giao	Bảng theo dõi có bản ghi đơn	Synthetic fact
3	Nhân viên bán hàng và kho	Xác nhận tồn qua điện thoại	Mã hàng, số lượng yêu cầu, tồn kho được kho thông báo	Có hoặc không có khả năng chuẩn bị hàng	Synthetic fact
4	Nhân viên bán hàng	Gửi phiếu yêu cầu xuất kho qua email khi kho báo đủ	Mã đơn, mã hàng, số lượng, ngày giao	Kho nhận yêu cầu chuẩn bị	Synthetic fact
5	Kho	Chuẩn bị, giao hàng, thông báo hoàn tất để nhân viên cập nhật bảng theo dõi	Phiếu yêu cầu xuất kho, trạng thái giao hàng	Bảng theo dõi được cập nhật trạng thái giao	Synthetic fact

Senior Lens

Không suy ra “nguyên nhân gốc là thiếu ERP” từ email và điện thoại. Fact chỉ chứng minh tồn tại thao tác thủ công và kênh trao đổi phân tán. Nhận định “cần một nguồn dữ liệu đang hiệu lực” là inference vì cùng số lượng, ngày giao được dùng qua nhiều kênh; inference này phải giữ liên kết đến năm bước trên.

Không gắn rule pháp lý, thuế, kế toán, an toàn thực phẩm hoặc bảo vệ dữ liệu cá nhân vào ví dụ này. Không có evidence nguồn chính thức nào trong micro-example chứng minh nghĩa vụ cụ thể. Nếu quy trình sau này chứa dữ liệu cá nhân, hóa đơn hoặc truy xuất lô thực phẩm, gắn nhãn Verification required và chuyển vai trò Legal Owner, Accounting Owner hoặc domain owner xác minh.

Quick Reference

Kiểm tra anatomy	Đạt khi
Có điểm đầu và điểm cuối	Nhận đơn là đầu; cập nhật trạng thái giao là cuối
Có đủ người hoặc hệ thống tham gia	Nhân viên bán hàng, kho, bảng theo dõi, email, điện thoại đều được nêu
Có dữ liệu tại từng bước	Mỗi hàng có dữ liệu hoặc chứng từ cụ thể
Có fact và inference tách riêng	Current Behavior là fact mô phỏng; Underlying Need nêu reasoning bridge
Có ranh giới nguồn	Mọi nội dung Nova Foods gắn Synthetic fact; không diễn giải thành vận hành thật
Có liên kết canonical	Giữ nguyên 00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY

Core

Quality gate là cổng kiểm tra chất lượng trước khi chuyển artifact sang downstream review, tức review của vai trò nhận đầu ra ở bước kế tiếp. Gate kiểm tra “đủ để xem xét”, không xác nhận “đúng cuối cùng”. Bằng chứng: mọi artifact corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07; các manifest nêu rõ trạng thái này không phải APPROVED, BASELINED, production-ready, compliant, hoặc user-approved.

Điều kiện gate	Kiểm tra cụ thể	Bằng chứng phải có	Kết quả nếu thiếu
Nhận diện kiểm soát	Giữ đúng Artifact ID, filename canonical, IN_REVIEW, v0.9.0, Asia/Ho_Chi_Minh	Header hoặc metadata artifact	Không chuyển review
Traceability	Mỗi nhận định current state nối tới nguồn, quan sát, hoặc giả định được gắn nhãn	Link tới artifact nguồn canonical; nhãn Project assumption hoặc Verification required khi thiếu xác minh	Không chuyển review
Ranh giới nguồn	Không biến nguồn học liệu, luật, chuẩn, hoặc dữ liệu mô phỏng thành quyết định Nova Foods thật	Phân loại nguồn còn nguyên; Nova Foods ghi mô phỏng, dữ liệu tổng hợp	Không chuyển review
Tính nhất quán	Thuật ngữ, actor, bước quy trình, dữ liệu và vấn đề không mâu thuẫn trong artifact liên quan	Đối chiếu /01-curriculum/CHAPTER_MANIFEST.md, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi áp dụng	Ghi lỗi và sửa trước review
Khả năng review	Reviewer đọc được phạm vi, bằng chứng, câu hỏi mở, tác động và giới hạn thẩm quyền	Nội dung không mơ hồ; câu hỏi cần xác minh nêu rõ owner phù hợp	Có thể chuyển review
Lịch sử thay đổi	Mọi sửa đổi có ngày, người ghi nhận, lý do và phạm vi thay đổi	Change-history entry theo Asia/Ho_Chi_Minh	Không chuyển review

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

flowchart TB
    A[Artifact current state<br/>IN_REVIEW v0.9.0] --> B{Đúng Artifact ID, filename canonical,<br/>IN_REVIEW v0.9.0 và<br/>Asia/Ho_Chi_Minh?}

    B -- Không --> C[Sửa artifact<br/>ghi change-history entry]
    C --> A

    B -- Có --> D{Mỗi nhận định nối tới nguồn,<br/>quan sát hoặc giả định?<br/>Thiếu xác minh đã gắn nhãn?}
    D -- Không --> C

    D -- Có --> E{Giữ đúng ranh giới nguồn?<br/>Không biến nguồn hoặc dữ liệu mô phỏng<br/>thành quyết định Nova Foods thật?}
    E -- Không --> C

    E -- Có --> F{Thuật ngữ, actor, bước quy trình,<br/>dữ liệu và vấn đề nhất quán<br/>với artifact liên quan?}
    F -- Không --> G[Ghi lỗi]
    G --> C

    F -- Có --> H{Phạm vi, bằng chứng, câu hỏi mở,<br/>tác động và giới hạn thẩm quyền<br/>đủ rõ để review?}
    H -- Không --> I[Nêu rõ câu hỏi cần xác minh<br/>và owner phù hợp]
    I --> J

    H -- Có --> J{Mọi sửa đổi có change-history entry<br/>gồm ngày, người ghi nhận,<br/>lý do và phạm vi thay đổi?}
    J -- Không --> C
    J -- Có --> K[Ready for downstream review<br/>vẫn IN_REVIEW v0.9.0]

    K --> M[Reviewer xem xét]
    K -. không đồng nghĩa .-> N[APPROVED, BASELINED,<br/>production-ready, compliant<br/>hoặc user-approved]
    M -. không đồng nghĩa .-> N

Applied

Trường	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Facts	BA ghi nhận quy trình nhập phiếu giao hàng nhà cung cấp từ trao đổi mô phỏng. Một bước “đối chiếu số lượng” chưa có nguồn xác minh chính thức.
Current Behavior	Artifact current-state có mô tả bước đối chiếu, nhưng chưa gắn nhãn cho phần chưa được xác minh.
Underlying Need	Downstream reviewer cần phân biệt fact có bằng chứng với giả định để không xem mô tả học liệu là quy tắc ERP thực.
Options	(1) Chuyển artifact ngay; (2) Xóa bước chưa xác minh; (3) Giữ bước, gắn Verification required, nêu nguồn thiếu và câu hỏi review.
Decision Criteria	Giữ traceability; không mất quan sát; không tuyên bố rule chưa xác minh; reviewer có đủ ngữ cảnh để quyết định việc cần làm tiếp.
Decision	Chọn phương án 3. Artifact qua quality gate khi metadata giữ IN_REVIEW/v0.9.0, bước đối chiếu có nhãn Verification required, và change history ghi lý do thêm nhãn.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability. Business Owner xác minh hành vi nghiệp vụ. Legal, Accounting, Security, Architect, QA chỉ xác minh phần thuộc thẩm quyền tương ứng. Không vai trò nào được suy ra đã phê duyệt từ việc artifact qua gate.
Artifact	Chỉ tham chiếu artifact canonical đã có: /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Nếu bỏ nhãn, reviewer có thể hiểu hành vi mô phỏng là rule vận hành. Nếu xóa quan sát, reviewer mất điểm cần xác minh. Nếu gọi gate là approval, corpus sai trạng thái quản trị.

Senior Lens

Gate tốt không đo số lượng bảng hay độ đẹp sơ đồ. Gate đo khả năng reviewer lần ngược từ kết luận về bằng chứng, biết phần nào chưa chắc, và biết ai có thẩm quyền xác minh. Nếu một nhận định liên quan pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm, bảo mật, kiến trúc, hoặc production, gate chỉ đạt khi nhận định giữ nhãn Verification required và chỉ đúng owner chuyên môn. Không dùng quality gate để thay legal sign-off, accounting interpretation, QA acceptance, baseline, hoặc approval.

Quick Reference

Ready for downstream review khi đủ năm điểm: metadata đúng, nguồn truy được, giả định được gắn nhãn, mâu thuẫn được xử lý hoặc nêu rõ, change history đầy đủ.
Không được suy ra: approved, baselined, compliant, production-ready, user-approved.
Nova Foods: case study mô phỏng giáo dục; toàn bộ dữ liệu tổng hợp; bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND.

7. Who consumes those outputs?

Core

Đầu ra As-Is là bằng chứng về quy trình đang diễn ra, không phải thiết kế To-Be. Người nhận dùng cùng một đầu ra cho mục đích khác nhau. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Nhóm người nhận	Đầu ra As-Is họ dùng	Cách dùng
Developers	Sơ đồ quy trình hiện tại, mô tả bước, quy tắc nghiệp vụ quan sát được, từ điển dữ liệu logic	Hiểu luồng xử lý hiện hữu, trường dữ liệu, điểm nhập liệu, ngoại lệ và phụ thuộc trước khi ước lượng hoặc xây dựng thay đổi.
QA	Sơ đồ quy trình, tình huống thực tế, ngoại lệ, pain point, giả định cần xác minh	Tạo test basis, tức nền tảng để suy ra điều kiện kiểm thử; bao phủ luồng chính, luồng lỗi và dữ liệu biên.
Architect	Sơ đồ luồng liên phòng ban, hệ thống liên quan, điểm trao đổi dữ liệu, ràng buộc quan sát được	Nhận diện biên hệ thống, tích hợp, nguồn dữ liệu và rủi ro kiến trúc.
PM/Product Owner	Pain point, thời gian chờ, bước thủ công, phạm vi hiện tại, stakeholder map	So sánh vấn đề với mục tiêu sản phẩm, sắp thứ tự ưu tiên và quản lý phạm vi.
Business Owner	Hành vi vận hành hiện tại, quy tắc quan sát được, ngoại lệ, điểm kiểm soát	Đối chiếu mô tả với thực tế nghiệp vụ mô phỏng và xác định phần cần xác minh chuyên môn.
Operations	Handoff giữa vai trò, thao tác tay, điểm nghẽn, dữ liệu đầu vào và đầu ra	Chuẩn bị thay đổi quy trình, hướng dẫn vận hành và theo dõi tác động đến công việc hằng ngày.
Specialist owners	Đầu ra chạm lĩnh vực chuyên môn: dữ liệu, kế toán, pháp lý, bảo mật, chất lượng, an toàn thực phẩm	Rà soát phần thuộc chuyên môn riêng. Ví dụ, Accounting Owner xem cách diễn đạt dữ liệu hạch toán; Security Owner xem luồng dữ liệu và quyền truy cập.

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

flowchart LR
    ASIS[Đầu ra As-Is]
    DEV[Developers]
    QA[QA]
    ARC[Architect]
    PO[PM/Product Owner]
    BO[Business Owner]
    OPS[Operations]
    SPO[Specialist owners]

    ASIS --> DEV
    ASIS --> QA
    ASIS --> ARC
    ASIS --> PO
    ASIS --> BO
    ASIS --> OPS
    ASIS --> SPO

Sơ đồ trên là sơ đồ luồng Mermaid, không phải BPMN. Nó chỉ thể hiện phân phối đầu ra. Bằng chứng cho việc phân phối là mỗi vai trò cần cùng mô tả hiện trạng nhưng biến mô tả đó thành công việc khác: xây dựng, kiểm thử, kiến trúc, ưu tiên, xác minh nghiệp vụ, vận hành hoặc rà soát chuyên môn.

Applied

Trường	Nội dung
Facts	Trong quy trình mô phỏng “xử lý đơn bán hàng”, nhân viên kinh doanh ghi đơn; kho kiểm tra tồn; kế toán nhận thông tin để xử lý chứng từ. Có bước trao đổi thủ công khi tồn không đủ.
Current Behavior	Sơ đồ As-Is ghi rõ người thực hiện, dữ liệu đầu vào, dữ liệu đầu ra và điểm chuyển giao giữa Kinh doanh, Kho và Kế toán.
Underlying Need	Các nhóm cần cùng hiểu hiện trạng trước khi diễn giải nhu cầu thay đổi. Nếu mỗi nhóm dùng một phiên bản mô tả khác nhau, phạm vi và kiểm thử sẽ lệch.
Options	Dùng sơ đồ As-Is riêng cho từng nhóm; hoặc dùng một artifact canonical, rồi mỗi nhóm tham chiếu phần liên quan.
Decision Criteria	Cùng nguồn sự thật; truy được về quan sát; không biến nhận định mô phỏng thành quy tắc vận hành đã xác nhận.
Decision	Dùng một bộ đầu ra As-Is có kiểm soát, tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md khi nội dung tương ứng tồn tại.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability. Mỗi consumer chỉ dùng đầu ra trong phạm vi vai trò; nội dung chuyên môn vẫn thuộc owner tương ứng.
Artifact	Sơ đồ quy trình As-Is, bảng bước xử lý, ghi nhận pain point, giả định và liên kết artifact canonical.
Consequence if Wrong	Developer có thể xây sai điểm tích hợp; QA bỏ sót luồng ngoại lệ; Operations nhận quy trình không vận hành được; Business Owner bị gán nhầm một hành vi mô phỏng thành quy tắc đã xác nhận.

Senior Lens

Không phải mọi consumer cần toàn bộ chi tiết với cùng độ sâu. Developer cần dữ liệu, điều kiện và điểm gọi hệ thống. QA cần hành vi quan sát được và biến thể. Architect cần biên hệ thống và luồng dữ liệu. PM/Product Owner cần tác động và phạm vi. Business Owner cần tính đúng của hành vi nghiệp vụ. Operations cần thao tác và handoff. Specialist owner chỉ nhận phần chạm thẩm quyền chuyên môn.

Tách “người dùng đầu ra” khỏi “người sở hữu quyết định”. Ví dụ QA dùng quy tắc nghiệp vụ làm test basis, nhưng QA không tự xác nhận quy tắc đó đúng cho Nova Foods. Architect dùng luồng tích hợp để phân tích, nhưng không vì vậy mà sơ đồ As-Is trở thành quyết định kiến trúc. IN_REVIEW tại v0.9.0 ngày 2026-08-07 không là baseline, approval, hay production authority.

Quick Reference

Đầu ra	Consumer chính	Mục đích tiêu thụ
Sơ đồ quy trình As-Is	Developers, QA, Architect, Operations	Hiểu bước, handoff, ngoại lệ và biên hệ thống
Bảng bước xử lý	Business Owner, QA, Operations	Đối chiếu thao tác, dữ liệu và trách nhiệm
Pain point	PM/Product Owner, Business Owner, Operations	Nhìn tác động và vùng cần cải thiện
Quy tắc quan sát được	Developers, QA, Business Owner, specialist owners	Diễn giải hành vi hiện tại trong đúng phạm vi
Từ điển dữ liệu logic	Developers, QA, Architect, specialist owners	Hiểu nghĩa dữ liệu và điểm dùng dữ liệu

Core

Đầu ra As-Is chỉ hữu ích khi người nhận biết phạm vi quyết định. Nova Foods là case mô phỏng giáo dục, dữ liệu tổng hợp; mọi artifact ở IN_REVIEW, v0.9.0, ngày 2026-08-07, không là baseline hay phê duyệt. Bằng chứng là dữ kiện quan sát, nguồn ghi nhận, quy tắc có ID canonical, điểm chưa rõ và owner xác minh; diễn giải BA không thay thế thẩm quyền chuyên môn.

Người nhận	Có thể quyết định	Bằng chứng tối thiểu cần dùng	Phải escalation khi
Developer	Ước lượng kỹ thuật, cách hiện thực trong ràng buộc đã rõ	Luồng As-Is, điều kiện vào/ra, ngoại lệ, CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES	Rule mâu thuẫn, dữ liệu thiếu nghĩa, thay đổi ảnh hưởng bảo mật, API, dữ liệu lịch sử
QA	Xác định test basis, rủi ro test, dữ liệu test tổng hợp	Luồng, trạng thái, rule, lỗi hiện tại, bằng chứng thao tác	Không có kết quả mong đợi kiểm chứng được; rule có nhiều cách hiểu; lỗi có nguy cơ mất dữ liệu
Architect	Đánh giá tác động kiến trúc, tích hợp, quyền truy cập, phi chức năng	Sơ đồ luồng, hệ thống liên quan, điểm trao đổi dữ liệu, volume giả định	Cần chọn kiến trúc, thay đổi system-of-record, tích hợp mới, dữ liệu cá nhân hoặc rủi ro bảo mật
PM/Product Owner	Ưu tiên, chia phạm vi, quản lý phụ thuộc và rủi ro delivery	Pain point có bằng chứng, tác động, giả định, dependency	Trade-off làm đổi mục tiêu, chi phí, thời gian, phạm vi hoặc lợi ích kỳ vọng
Business Owner	Xác nhận mục tiêu nghiệp vụ, ưu tiên pain point, quyết định ngoại lệ nghiệp vụ	Quy trình thực tế được ghi nhận, tác động vận hành, owner của rule	Thay đổi chính sách, quyền phê duyệt, KPI, trách nhiệm đơn vị
Operations	Xác nhận tính khả thi vận hành, thời điểm cut-off, xử lý sự cố	Tần suất, khối lượng, thao tác tay, ngoại lệ, vai trò thực hiện	Thay đổi ca làm, phân quyền, quy trình kho, quy trình sản xuất hoặc dữ liệu đối soát
Specialist owner	Diễn giải phần thuộc chuyên môn: kế toán, pháp lý, an toàn thực phẩm, bảo mật	Nguồn chính thức phù hợp, fact mô phỏng, câu hỏi quyết định	Nội dung có thể thành nghĩa vụ pháp lý, hạch toán, thuế, truy xuất, thu hồi hoặc kiểm soát bảo mật

Applied

Facts: Trong quy trình As-Is mô phỏng, nhân viên kho ghi nhận lô nguyên liệu sau khi nhận hàng; khi thiếu số lô, nhân viên ghi chú tự do để nhập lại sau. Bằng chứng cần có là ảnh chụp màn hình tổng hợp, nhật ký thao tác tổng hợp, tần suất thiếu lô và tên trường dữ liệu trong CANONICAL_DATA_DICTIONARY.

Current Behavior: ERP cho phép lưu phiếu nhận hàng khi trường số lô trống. Hệ quả quan sát cần ghi tách khỏi suy luận: số lô không có tại thời điểm nhận; suy luận là truy vết sau đó có thể thiếu dữ liệu đầu vào.

Underlying Need: Cần quyết định liệu số lô có là điều kiện bắt buộc tại bước nhận hàng hay chỉ bắt buộc trước bước sử dụng nguyên liệu. Đây là quyết định nghiệp vụ và chuyên môn truy xuất, không phải quyết định của Developer.

Options: Giữ cho phép trống; chặn lưu ngay khi thiếu số lô; cho phép lưu trạng thái chờ bổ sung nhưng chặn xuất dùng.

Decision Criteria: Khả năng tiếp nhận hàng, khả năng truy vết, tác động vận hành kho, quyền xử lý ngoại lệ, quy định áp dụng. Điều kiện pháp lý và an toàn thực phẩm là Verification required với specialist owner và nguồn chính thức phù hợp.

Decision: Chưa quyết định trong artifact IN_REVIEW. BA ghi đủ option, evidence và owner; không tự biến suy luận thành rule.

Authority: Business Owner quyết định chính sách nghiệp vụ; Operations xác nhận khả thi; specialist owner xác minh truy xuất/an toàn thực phẩm; Architect xem tác động trạng thái và tích hợp; QA xác định kiểm thử từ quyết định đã được ghi nhận.

Artifact: Luồng As-Is, issue log, giả định có nhãn, tham chiếu CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY. Không tạo rule ID mới trong phần này.

Consequence if Wrong: Chặn quá sớm có thể làm gián đoạn nhận hàng; cho phép quá rộng có thể tạo khoảng trống truy vết. Vì hai hậu quả thuộc owner khác nhau, BA phải escalation thay vì chọn thay.

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

flowchart TB
    BA[BA ghi fact, evidence, option<br/>và giả định có nhãn]
    BA --> IR[Artifact IN_REVIEW<br/>Chưa quyết định]
    IR --> EV{Evidence đủ để<br/>trình quyết định?}

    EV -->|Chưa| ADD[BA bổ sung evidence]
    ADD --> IR
    EV -->|Chưa, cần xử lý owner| ESC[Escalation đến Business Owner]
    ESC --> IR

    EV -->|Đủ| SV{Cần xác minh điều kiện<br/>truy xuất/pháp lý/an toàn thực phẩm?}
    SV -->|Có| SO[Specialist owner xác minh<br/>bằng nguồn chính thức]
    SV -->|Không| CONS[Tham vấn Operations<br/>và Architect]
    SO --> CONS

    CONS --> OPS[Operations xác nhận<br/>khả thi vận hành kho]
    CONS --> ARC[Architect đánh giá tác động<br/>trạng thái và tích hợp]

    OPS --> ASSESS[Đánh giá tiêu chí và rủi ro]
    ARC --> ASSESS
    SO -->|Kết quả xác minh khi có| ASSESS

    CRIT[Tiêu chí:<br/>tiếp nhận hàng, truy vết,<br/>tác động kho, quyền ngoại lệ,<br/>quy định áp dụng] --> ASSESS
    R1[Rủi ro: chặn sớm<br/>gián đoạn nhận hàng] --> ASSESS
    R2[Rủi ro: cho phép quá rộng<br/>khoảng trống truy vết] --> ASSESS

    ASSESS --> BO{Business Owner quyết định<br/>chính sách nghiệp vụ}
    BO -->|Cho phép trống| ALLOW[Cho phép lưu khi thiếu số lô]
    BO -->|Chặn lưu| BLOCK[Chặn lưu khi thiếu số lô]
    BO -->|Chờ bổ sung| HOLD[Cho phép chờ bổ sung<br/>nhưng chặn xuất dùng]

    ALLOW --> REC[Quyết định nghiệp vụ<br/>được ghi nhận]
    BLOCK --> REC
    HOLD --> REC

    REC --> DEV[Developer dùng làm đầu vào]
    REC --> QA[QA xác định kiểm thử]

Senior Lens

Escalation không là chuyển trách nhiệm. BA phải đóng gói vấn đề để người có thẩm quyền quyết định được: fact nào đã quan sát, nguồn nào hỗ trợ, giả định nào chưa xác minh, option nào tồn tại, tác động của từng option và câu hỏi cần trả lời. Không escalation bằng câu “cần làm rõ”; dùng câu hỏi có ranh giới quyết định.

Hiểu nhầm handoff	Rủi ro	Câu hỏi làm rõ chính xác
Developer xem sơ đồ As-Is là yêu cầu To-Be	Xây lại hành vi lỗi hiện tại hoặc tự sửa policy	“Bước này mô tả hành vi hiện tại hay hành vi mục tiêu? Nếu mục tiêu, Business Owner nào xác nhận thay đổi?”
QA xem ghi chú nghiệp vụ là expected result	Test theo suy đoán	“Khi số lô trống, trạng thái mong đợi nào được owner xác định: cho lưu, chặn lưu, hay chờ bổ sung?”
Architect xem pain point là yêu cầu tích hợp	Chọn giải pháp trước quyết định nghiệp vụ	“Hệ thống nào là system-of-record cho số lô, và owner nào xác nhận quyền sửa dữ liệu?”
PM/Product Owner xem giả định là cam kết	Lập kế hoạch sai phạm vi	“Giả định này có evidence nào, owner xác minh là ai, và ngày quyết định cần trước mốc nào?”
Operations xem rule là hướng dẫn vận hành đã hiệu lực	Thay đổi thao tác thực tế không được phép	“Nội dung này đang IN_REVIEW hay có quyết định vận hành được ghi nhận ở artifact kiểm soát?”
Specialist owner bị yêu cầu xác nhận toàn bộ luồng	Xác nhận vượt chuyên môn	“Phần nào cần xác minh chuyên môn cụ thể: điều kiện dữ liệu, thời hạn lưu, quyền truy cập hay xử lý ngoại lệ?”

Quick Reference

Quy tắc bàn giao: người nhận chỉ quyết định trong thẩm quyền; evidence phải phân biệt fact, suy luận và giả định; nội dung pháp lý, kế toán, thuế, bảo mật, an toàn thực phẩm cần specialist owner xác minh. Nếu một lựa chọn đồng thời đổi rule nghiệp vụ và kiến trúc, escalation song song tới Business Owner và Architect; BA giữ traceability, không thay quyết định.

Core

Bàn giao sai thường không do thiếu tài liệu, mà do mỗi vai trò đọc cùng một câu theo nghĩa khác. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp; mọi artifact đang IN_REVIEW, v0.9.0, ngày 2026-08-07, chưa là baseline hay phê duyệt.

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

flowchart TB
    A[BA ghi Current State As-Is] --> B{Nội dung mô tả<br/>vận hành hiện tại?}
    B -- Không: thay đổi mong muốn --> C[BA tách thành Future State<br/>Không ghi là As-Is]
    B -- Có --> D[Người nhận đối chiếu<br/>nguồn canonical, evidence<br/>hoặc project assumption]
    D --> E{Nội dung rõ?}
    E -- Không --> F[Người nhận đặt câu hỏi làm rõ]
    E -- Có --> G{Trạng thái nguồn<br/>được ghi đúng?}
    G -- Không --> F
    G -- Có --> H[Dùng làm đầu vào dự thảo<br/>Không là baseline hay<br/>quyết định đã phê duyệt]
    F --> I[BA cập nhật artifact]
    I --> J{Loại nguồn?}
    J -- Evidence --> K[Đối chiếu với người tham gia<br/>hoặc phụ trách vận hành]
    J -- Nguồn canonical --> L[Đối chiếu với nguồn canonical<br/>hoặc owner kiểm soát nguồn]
    J -- Business Owner decision --> Q[Business Owner xác nhận<br/>quyết định]
    J -- Project assumption --> M[Ghi assumption, owner<br/>và trạng thái chưa xác nhận]
    K --> R[Ghi evidence là phát biểu đầu vào<br/>Không là quy tắc canonical]
    R --> N{Đã xác nhận<br/>hoặc ghi rõ trạng thái?}
    L --> N
    Q --> N
    M --> P{Business Owner<br/>chấp nhận, bác bỏ<br/>hay chuyển thành quyết định?}
    P --> N
    N -- Có --> G
    N -- Không/chưa xác nhận --> O[Ghi rõ chưa xác nhận<br/>và tiếp tục làm rõ]
    O --> F

Sai lầm: coi sơ đồ quy trình hiện tại là thiết kế tương lai. Current State As-Is mô tả hành vi đang diễn ra, gồm cả thao tác tay, ngoại lệ và điểm nghẽn; không tự tạo yêu cầu thay đổi. Câu hỏi chính xác: “Bước này đang xảy ra trong vận hành mô phỏng hiện tại, hay là thay đổi mong muốn cho trạng thái tương lai?”

Sai lầm: coi ghi chú phỏng vấn là quy tắc nghiệp vụ đã xác nhận. Một phát biểu của người tham gia là evidence đầu vào, không phải nguồn chân lý. Câu hỏi chính xác: “Nguồn canonical nào xác nhận quy tắc này: quy trình kiểm soát, catalog quy tắc, quyết định Business Owner, hay đây mới là project assumption?”

Applied

Trường	Nội dung case mô phỏng Nova Foods
Facts	Sơ đồ As-Is ghi nhân viên Kho kiểm tra hạn dùng bằng bảng tính trước khi xuất hàng. Ghi chú không nêu ai xử lý khi bảng tính không truy cập được.
Current Behavior	Kiểm tra thủ công diễn ra trước xuất hàng; ngoại lệ chưa có evidence xác nhận trong artifact đầu vào.
Underlying Need	Người nhận cần phân biệt “quy trình đang có” với “quy tắc hệ thống phải xây”.
Options	1. Developer tự thêm kiểm tra hạn dùng vào ERP. 2. Giữ mô tả As-Is và yêu cầu làm rõ.
Decision Criteria	Có nguồn canonical xác nhận quy tắc, owner có thẩm quyền, phạm vi thay đổi, và xử lý ngoại lệ.
Decision	Chọn phương án 2. As-Is không đủ bằng chứng để biến thành yêu cầu triển khai.
Authority	Business Owner xác nhận mục tiêu nghiệp vụ; specialist owner Kho xác nhận thao tác; Architect quyết định tác động kỹ thuật nếu có thay đổi.
Artifact	/02-handbook/04-current-state-as-is-and-process-mapping.md; tham chiếu quản trị CANONICAL_BUSINESS_RULES khi quy tắc được đăng ký.
Consequence if Wrong	ERP có thể chặn xuất hàng khác hành vi được phép, hoặc bỏ sót ngoại lệ vận hành.

Câu hỏi làm rõ ghi nguyên văn trong điểm bàn giao: “Khi bảng tính kiểm tra hạn dùng không truy cập được, nhân viên Kho được phép xuất hàng không? Nếu có, ai quyết định và evidence nào phải được lưu?” Câu này xác định điều kiện, thẩm quyền và bằng chứng; không ép người nhận tự suy diễn.

Senior Lens

Sai lầm: Developer hiểu “người dùng nhập lại dữ liệu” là lỗi cần tự động hóa. Nhập lại có thể là kiểm soát bốn mắt, đối soát nguồn, hoặc chỉ là lãng phí. Câu hỏi chính xác: “Lần nhập thứ hai có mục đích kiểm soát nào được xác nhận không; nếu có, ai thực hiện kiểm soát và kết quả kiểm soát được ghi ở đâu?”

Sai lầm: QA biến mọi nhánh trong As-Is thành expected result cho hệ thống mới. As-Is là test basis để hiểu rủi ro và dữ liệu thực tế, không phải acceptance criteria. Câu hỏi chính xác: “Nhánh này là hành vi hiện tại cần được giữ, hành vi cần loại bỏ, hay ngoại lệ chưa có quyết định cho trạng thái tương lai?”

Sai lầm: Architect đọc tên hệ thống trong sơ đồ như bằng chứng có integration. Mũi tên trao đổi thông tin có thể là email, tệp bảng tính hoặc API. Câu hỏi chính xác: “Dữ liệu được chuyển bằng thao tác tay, tệp, API hay DB; tần suất, định dạng, hệ thống nguồn và hệ thống nhận là gì?”

Sai lầm: PM hoặc Product Owner coi pain point là cam kết phạm vi. Pain point chứng minh vấn đề, chưa chứng minh ưu tiên, ngân sách hay quyết định thay đổi. Câu hỏi chính xác: “Pain point này gây tác động đo được nào trong case mô phỏng, và ai có thẩm quyền quyết định nó thuộc phạm vi thay đổi?”

Sai lầm: Operations hiểu “không thấy trong sơ đồ” là “không cần vận hành”. Sơ đồ có thể chưa ghi quyền truy cập, giám sát, sao lưu hoặc khôi phục. Câu hỏi chính xác: “Để bước này chạy hằng ngày, cần quyền, lịch chạy, cảnh báo, xử lý lỗi và người trực nào?”

Quick Reference

Hiểu nhầm khi bàn giao	Câu hỏi làm rõ bắt buộc
As-Is là To-Be	“Đây là hành vi hiện tại hay thay đổi mong muốn?”
Ghi chú là rule đã xác nhận	“Nguồn canonical và owner xác nhận là gì?”
Mũi tên là API	“Cơ chế truyền dữ liệu thực tế là gì?”
Thao tác tay là lỗi	“Thao tác này có mục đích kiểm soát đã xác nhận không?”
Ngoại lệ không vẽ là không tồn tại	“Khi bước thất bại, ai xử lý, trong thời hạn nào, bằng evidence nào?”
Pain point là scope	“Ai quyết định ưu tiên và phạm vi thay đổi?”

Quy tắc: câu trả lời chưa có nguồn, owner hoặc evidence phải giữ nhãn Verification required hoặc project assumption. Không biến câu trả lời chưa xác nhận thành quy tắc Nova Foods, yêu cầu ERP, kết luận pháp lý, kế toán, an toàn thực phẩm, riêng tư hay phê duyệt.

8. Detailed Worked Example

Core

Ví dụ này ghi As-Is: hành vi đang diễn ra, không phải thiết kế ERP mong muốn. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, số tiền, người, mã và dữ liệu dưới đây là tổng hợp. Trạng thái tài liệu: IN_REVIEW; phiên bản: v0.9.0; ngày: 2026-08-07; locale: vi-VN; múi giờ: Asia/Ho_Chi_Minh; tiền tệ: VND.

Applied

Kịch bản ASIS-NF-008-01 — Nhận hàng nguyên liệu bột cacao cho lệnh sản xuất. Phạm vi bắt đầu khi xe giao đến kho nguyên liệu và kết thúc khi kế toán nhận được bảng nhận hàng qua email. Không mô tả quyết định thay đổi, cấu hình ERP, phê duyệt hay tuân thủ pháp lý.

Thuộc tính	Giá trị
Scenario ID	ASIS-NF-008-01
Tên scenario	Nhận nguyên liệu bột cacao bằng bảng tính
Đơn vị mô phỏng	Nova Foods Trading & Manufacturing
Kho	WH-RM-HCM-01 — Kho nguyên liệu TP.HCM
Nhà cung cấp	SUP-014 — Công ty TNHH Nguyên liệu Mặt Trời
Mặt hàng	RM-COCOA-25KG — Bột cacao, bao 25 kg
Đơn mua hàng	PO-20260807-014
Lệnh sản xuất tham chiếu	MO-20260808-006
Chứng từ giao hàng	DN-MT-20260807-118
Số lượng đặt	200 bao
Số lượng giao	198 bao
Số lượng hỏng khi nhận	2 bao
Số lượng nhận đạt	196 bao
Đơn giá tham chiếu	1.250.000 VND/bao
Giá trị nhận đạt tham chiếu	245.000.000 VND
Lô nhà cung cấp	MT-COC-260801
Hạn dùng nhà cung cấp ghi	2027-08-01
Người nhận kho	NV-KHO-021 — Trần Minh An
Người kiểm tra chất lượng	NV-QA-009 — Lê Thu Hà
Người nhận bảng tính kế toán	NV-ACC-014 — Phạm Quốc Bảo
Hệ thống đang dùng	Email nội bộ và tệp Microsoft Excel
Nguồn chính cho số lượng thực nhận	Đếm thủ công tại cửa kho
Nguồn chính cho trạng thái chất lượng	Phiếu kiểm tra giấy QC-RM-20260807-031
Phân loại bằng chứng	Quan sát mô phỏng và dữ liệu tổng hợp
Trạng thái xác nhận	Verification required; chưa có xác nhận từ Business Owner, Accounting Owner, QA Owner hoặc Legal Owner

Facts — sự kiện quan sát được. Lúc 09:10 ngày 2026-08-07, xe của SUP-014 giao 198 bao cho WH-RM-HCM-01. Nhân viên kho đối chiếu mã PO trên giấy giao hàng với bản PDF PO-20260807-014.pdf trong email. Kho đếm 198 bao. QA kiểm tra ngoại quan, ghi 2 bao rách mép và đánh dấu không đạt trên phiếu giấy QC-RM-20260807-031. Kho đưa 196 bao đạt vào vị trí RM-A-03; 2 bao hỏng để tại khu HOLD-RM-01. Không có giao dịch nhận hàng trong ERP mô phỏng tại thời điểm này.

Evidence ID	Tên evidence	Kênh	Dữ liệu chứng minh	Phân loại nguồn
EVD-ASIS-008-01	PO-20260807-014.pdf	Email nội bộ	Mã PO, nhà cung cấp, hàng, số lượng đặt, đơn giá	Tệp nghiệp vụ mô phỏng
EVD-ASIS-008-02	DN-MT-20260807-118.pdf	Bản giấy scan	Số lượng giao 198, lô MT-COC-260801, hạn dùng	Chứng từ nhà cung cấp mô phỏng
EVD-ASIS-008-03	QC-RM-20260807-031.jpg	Ảnh phiếu giấy	2 bao không đạt ngoại quan	Bằng chứng QA mô phỏng
EVD-ASIS-008-04	GRN_20260807.xlsx	Thư mục dùng chung	Số lượng nhận đạt 196, vị trí kho, giá trị tham chiếu	Bảng tính vận hành mô phỏng
EVD-ASIS-008-05	Email RE: GRN 20260807 - SUP-014	Email nội bộ	Kho gửi bảng nhận hàng cho kế toán	Trao đổi vận hành mô phỏng

Current Behavior — cách quy trình đang chạy. Nhân viên kho tạo một dòng mới trong GRN_20260807.xlsx sau khi QA ghi phiếu giấy. Tệp không khóa ô, không có mã giao dịch hệ thống, không có trường bắt buộc do ERP kiểm soát. Kho lưu bản hiện hành tại thư mục dùng chung và gửi email đính kèm cho kế toán. Kế toán dùng dòng bảng tính làm đầu vào để nhập nghiệp vụ nhận hàng vào công cụ kế toán mô phỏng. Bảng tính không tự kiểm tra rằng Số lượng giao = Số lượng nhận đạt + Số lượng hỏng; người dùng tự tính.

Bước	Vai trò	Hành động hiện tại	Input	Output	Điểm ghi nhận
ASIS-008-01-S01	Bảo vệ	Cho xe vào theo lịch giao giấy	Thông tin xe, nhà cung cấp	Xe đến cửa kho	Sổ cổng giấy
ASIS-008-01-S02	Kho	So PO PDF với phiếu giao	PO-20260807-014.pdf, DN-MT-20260807-118	Xác định hàng cần nhận	Không có log hệ thống
ASIS-008-01-S03	Kho	Đếm bao giao thực tế	Hàng vật lý	198 bao giao	Ghi tay trên phiếu giao
ASIS-008-01-S04	QA	Kiểm tra ngoại quan, tách hàng hỏng	198 bao giao	196 đạt, 2 hỏng	QC-RM-20260807-031
ASIS-008-01-S05	Kho	Đưa hàng đạt vào vị trí kho	196 bao đạt	Tồn vật lý tại RM-A-03	Nhãn vị trí kho
ASIS-008-01-S06	Kho	Nhập dòng Excel	Phiếu QA, số đếm kho	Dòng nhận hàng	GRN_20260807.xlsx
ASIS-008-01-S07	Kho	Gửi email cho kế toán	Tệp Excel đính kèm	Kế toán nhận dữ liệu	EVD-ASIS-008-05
ASIS-008-01-S08	Kế toán	Nhập lại dữ liệu vào công cụ kế toán mô phỏng	Excel nhận từ kho	Bản ghi kế toán riêng	Ngoài phạm vi quan sát chi tiết

Dòng dữ liệu hiện có trong GRN_20260807.xlsx:

receipt_date	po_id	supplier_id	item_id	supplier_lot	qty_delivered	qty_accepted	qty_rejected	uom	storage_location	status	receiver_id
2026-08-07	PO-20260807-014	SUP-014	RM-COCOA-25KG	MT-COC-260801	198	196	2	BAG	RM-A-03	ACCEPTED_WITH_REJECTION	NV-KHO-021

Quy tắc tính đang được người dùng áp dụng thủ công:

qty_delivered = qty_accepted + qty_rejected
198 = 196 + 2

Sơ đồ As-Is dùng Mermaid flowchart, không phải BPMN:

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

flowchart TB
    A[Xe SUP-014 đến cổng kho] --> B[Bảo vệ cho xe vào theo lịch giao giấy]
    B --> C[Kho đối chiếu PO-20260807-014.pdf với DN-MT-20260807-118]
    C --> D[Kho đếm thực tế: 198 bao]
    D --> E[QA kiểm tra ngoại quan]
    E --> Q[QA ghi QC-RM-20260807-031:<br/>2 bao không đạt]
    Q --> F[Kho đặt 196 bao đạt tại RM-A-03]
    Q --> G[Kho đặt 2 bao hỏng tại HOLD-RM-01]
    F --> H[Kho nhập GRN_20260807.xlsx]
    G --> H
    H --> K[Kho lưu bản hiện hành tại thư mục dùng chung]
    K --> I[Kho gửi email đính kèm GRN_20260807.xlsx]
    I --> J[Kế toán nhận GRN_20260807.xlsx]

    H -. rủi ro kiểm soát .-> R[Excel không tự xác thực:<br/>Số giao = Số đạt + Số hỏng]
    H -. trạng thái quan sát .-> S[Không có giao dịch nhận hàng ERP<br/>tại thời điểm này]

Cầu nối bằng chứng: DN-MT-20260807-118 ghi 198 bao giao; QC-RM-20260807-031 ghi 2 bao không đạt; vì 198 - 2 = 196, dòng Excel ghi qty_accepted = 196. Đây là suy luận số học từ evidence mô phỏng, chưa xác nhận quy tắc kiểm soát tồn kho hay ghi nhận kế toán.

Senior Lens

Điểm As-Is quan trọng là tách ba sự thật: hàng vật lý 196 bao ở RM-A-03, hàng hỏng 2 bao ở HOLD-RM-01, và dữ liệu nhận hàng nằm trong Excel rồi được nhập lại. Ba nơi này có thể không đồng nhất vì không có một giao dịch hệ thống chung được quan sát trong scenario.

ACCEPTED_WITH_REJECTION là nhãn mô tả trong bảng tính mô phỏng, không phải trạng thái ERP canonical, quyết định chất lượng, điều khoản trả hàng, kết luận an toàn thực phẩm hay căn cứ kế toán. Việc xử lý 2 bao hỏng cần xác minh bởi owner có thẩm quyền.

Quick Reference

Mục	Giá trị As-Is
Một scenario nhất quán	ASIS-NF-008-01
Sự kiện chính	Nhận 198 bao bột cacao
Kết quả vật lý	196 đạt, 2 hỏng
Công cụ ghi nhận hiện tại	Phiếu giấy, Excel, email
Điểm chuyển dữ liệu	Kho gửi GRN_20260807.xlsx cho kế toán
Kết luận được phép	Mô tả hành vi mô phỏng hiện tại
Kết luận không được phép	Không gọi đây là thiết kế ERP, rule canonical, phê duyệt hoặc tuân thủ

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND, ngày 2026-08-07. Đây là phân tích hiện trạng, không phải quyết định vận hành, pháp lý, kế toán hay production.

Bước suy luận	Nội dung hoàn chỉnh	Bằng chứng hoặc cầu nối suy luận
Facts	Kho thành phẩm WH-HCM-01 nhận 120 thùng FG-NUOCXOAI-1L từ lệnh sản xuất MO-20260807-014. Nhân viên kho ghi lô LOT-MX-260807-A vào Excel, rồi nhập tổng số lượng 120 vào ERP cuối ca. ERP hiện chỉ lưu mã hàng, kho, số lượng; không lưu mã lô trên dòng nhận kho.
Current Behavior	Khi sales tạo đơn SO-20260807-031, kho chọn 50 thùng theo số lượng tồn tổng. Nhân viên tìm lô qua Excel và ghi mã lô vào ghi chú giao hàng tự do. Nếu Excel và tồn ERP lệch, quản lý kho gọi điện xác minh trước khi xuất.
Underlying Need	Nova Foods cần liên kết số lượng nhận, tồn và xuất với cùng một mã lô. Lý do: tồn tổng 120 không cho biết 50 thùng đã xuất thuộc lô nào; ghi chú tự do không tạo dữ liệu có cấu trúc để truy ngược. Nhu cầu truy xuất lô phù hợp bối cảnh Luật An toàn thực phẩm, nhưng nghĩa vụ chi tiết phải do Legal Owner và Food Safety Owner xác minh.
Options	OPT-01: tiếp tục Excel và ghi chú tự do. OPT-02: thêm trường mã lô bắt buộc ở nhận kho, điều chuyển và xuất kho; ERP kiểm tra số lượng theo tổ hợp mã hàng, kho, lô. OPT-03: quét mã vạch lô bằng thiết bị kho và tự tạo giao dịch ERP.
Decision Criteria	Đánh giá theo năm tiêu chí: truy vết đầu-cuối; giảm nhập lại; khả năng kiểm soát tồn âm theo lô; chi phí thay đổi; mức sẵn sàng thiết bị. Tiêu chí không tự chứng minh tuân thủ pháp luật hay phù hợp production.
Decision	Khuyến nghị BA: chọn OPT-02 cho phạm vi học liệu. Nó tạo dữ liệu cấu trúc đủ để nối nhận và xuất lô, không giả định Nova Foods có máy quét hay tích hợp thiết bị. Đây không phải quyết định được phê duyệt.
Authority	Business Owner quyết định ưu tiên nghiệp vụ. Warehouse Manager xác nhận luồng kho. Solution Architect xác nhận mô hình dữ liệu và khả năng ERP. Food Safety Owner cùng Legal Owner xác minh yêu cầu truy xuất và nguồn luật. Không có authority nào được ghi nhận đã phê duyệt tại IN_REVIEW, v0.9.0.
Artifact	Ghi nhận phân tích trong /02-handbook/04-current-state-as-is-and-process-mapping.md, section 08-worked-example; liên kết quản trị với CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY. Các artifact này đang IN_REVIEW; không phải baseline hay approval.
Consequence if Wrong	Nếu kết luận rằng ghi chú tự do đủ cho truy xuất, đội dự án có thể chọn thiết kế không truy vết được số lượng theo lô. Khi có yêu cầu xác định lô đã giao, nhân viên phải đối chiếu thủ công ERP, Excel và chứng từ; thời gian phản hồi tăng, nguy cơ nhầm lô tăng.

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

flowchart TB
    A[MO-20260807-014<br/>Sản xuất 120 thùng] --> B[Nhận kho WH-HCM-01]
    B --> D[Excel lưu lô<br/>LOT-MX-260807-A: 120]
    D --> C[Cuối ca nhập ERP tồn tổng<br/>FG-NUOCXOAI-1L: 120]

    E[Sales tạo SO-20260807-031<br/>Yêu cầu xuất 50 thùng] --> F[Kho chọn 50 thùng<br/>theo tồn tổng ERP]
    C --> F
    D --> G[Nhân viên kho tìm lô<br/>trong Excel]
    F --> H{Excel và tồn ERP<br/>có lệch?}
    G --> H

    H -- Không --> J[Tiếp tục xuất kho 50 thùng]
    H -- Có --> I[Warehouse Manager gọi điện<br/>xác minh trước khi xuất]
    I --> X[Kết quả xử lý sai lệch<br/>chưa được mô tả]

    J --> K[Nhân viên kho ghi<br/>LOT-MX-260807-A vào ghi chú<br/>giao hàng tự do]
    K --> L[Không có liên kết cấu trúc<br/>giữa giao dịch xuất 50 thùng<br/>và mã lô]

ID	Phương án	Truy vết đầu-cuối	Kiểm soát tồn theo lô	Phụ thuộc mới	Kết luận
OPT-01	Excel + ghi chú	Không	Không	Không	Loại: không đáp ứng Underlying Need
OPT-02	Mã lô bắt buộc trong ERP	Có	Có	Thay đổi dữ liệu và quy tắc ERP	Khuyến nghị
OPT-03	Quét mã vạch lô	Có	Có	Thiết bị, tích hợp, đào tạo	Chưa chọn: vượt bằng chứng sẵn có

Quy tắc đề xuất BR-LOT-001: giao dịch nhận kho, điều chuyển kho và xuất kho của FG-NUOCXOAI-1L phải có lot_id; hệ thống không cho xuất nếu số lượng xuất lớn hơn tồn khả dụng của cùng item_id, warehouse_id, lot_id. Quy tắc là đề xuất học liệu; Business Owner, Warehouse Manager, Solution Architect và Food Safety Owner phải xem xét trước khi đưa vào catalog canonical hoặc triển khai.

Applied

Phạm vi case: Nova Foods Trading & Manufacturing là mô phỏng giáo dục; toàn bộ dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Đây là ví dụ As-Is cho luồng nhận nguyên liệu bột mì tại kho WH-HCM-01. Các mã dưới đây là mã làm việc trong ví dụ, chưa phải ID canonical đã baseline.

Thành phần	Giá trị đầy đủ
Scenario ID	NF-ASIS-REC-001
Process	Nhận nguyên liệu có kiểm tra chất lượng
Purchase Order	PO-NF-20260807-001
Supplier	SUP-GRAIN-001 — Công ty TNHH Ngũ Cốc An Phú
Item	RM-FLOUR-001 — Bột mì đa dụng, đơn vị KG
Kho nhận	WH-HCM-01 — Kho nguyên liệu Hồ Chí Minh
Lô nhà cung cấp	AP-LOT-260807-A
Số lượng đặt	5,000 KG
Số lượng giao	5,000 KG
Đơn giá mô phỏng	18,500 VND/KG
Giá trị mô phỏng	92,500,000 VND
Thời điểm nhận	2026-08-07T09:15:00+07:00
Trạng thái artifact	IN_REVIEW
Phiên bản artifact	v0.9.0

Quy tắc đang quan sát, chưa phải quy tắc được phê duyệt:

Working Rule ID	Quy tắc As-Is	Bằng chứng trong scenario	Phân loại
WR-NF-ASIS-001	Thủ kho tạo phiếu nhận trước khi QA hoàn tất kiểm tra.	Phiếu nhận được nhập lúc 09:15; QA dự kiến có kết quả sau thời điểm này.	Current behavior
WR-NF-ASIS-002	Hệ thống bảng tính không chặn số lượng nhận vượt số lượng đơn mua.	Người dùng phải tự đối chiếu 5,000 KG với PO.	Current behavior
WR-NF-ASIS-003	Lô nguyên liệu chưa có kết quả QA không được cấp phát cho sản xuất.	Đây là nhu cầu kiểm soát được suy ra từ nguy cơ dùng lô chưa đạt; cần Business Owner và QA Owner xác nhận.	Project assumption; Verification required
WR-NF-ASIS-004	Mỗi lô nhận phải giữ liên kết PO, nhà cung cấp, mã hàng, lô nhà cung cấp và trạng thái QA để truy vết.	Dữ liệu trên cần để nhận diện phạm vi lô khi có vấn đề chất lượng.	Project assumption; Verification required với QA Owner, Food Safety Owner và Legal Owner

Payload ghi nhận As-Is: payload là gói dữ liệu trao đổi giữa bước nghiệp vụ; ví dụ này mô tả dữ liệu cần nhìn thấy, không phải hợp đồng API hay cấu hình ERP.

{
  "receiptReference": "GRN-NF-20260807-001",
  "purchaseOrderNumber": "PO-NF-20260807-001",
  "supplierId": "SUP-GRAIN-001",
  "warehouseId": "WH-HCM-01",
  "receivedAt": "2026-08-07T09:15:00+07:00",
  "currency": "VND",
  "lines": [
    {
      "lineNumber": 1,
      "itemId": "RM-FLOUR-001",
      "uom": "KG",
      "orderedQuantity": 5000,
      "receivedQuantity": 5000,
      "unitPrice": 18500,
      "supplierLotNumber": "AP-LOT-260807-A",
      "qaStatus": "PENDING"
    }
  ],
  "recordedByRole": "Warehouse Clerk"
}

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

flowchart TB
    A["Nhà cung cấp giao 5,000 KG bột mì"] --> B["Thủ kho đối chiếu số lượng với PO-NF-20260807-001 bằng mắt"]
    B --> C{"Số lượng nhận vượt PO?"}
    C -->|Không| D["Thủ kho ghi GRN-NF-20260807-001 trên bảng tính"]
    C -->|Có — bảng tính vẫn cho ghi nhận| D
    C -.-> X["Chưa xác minh: cách xử lý ngoại lệ vượt PO<br/>Owner xác minh: Business Owner và Warehouse Owner hoặc đại diện vận hành kho"]

    D --> E["Quan sát: QA = PENDING"]
    E --> F["QA lấy mẫu và kiểm tra ngoài hệ thống ERP"]
    E -.-> R["Rủi ro suy ra: có thể cấp phát lô chưa đạt<br/>Cần Business Owner và QA Owner xác nhận"]
    F --> G{"Đã có kết quả QA?"}
    G -->|Chưa| H["Chờ kết quả QA"]
    H --> G
    G -->|Có| I["Kết quả và xử lý tiếp theo: chưa xác minh"]

    subgraph V["Ranh giới bằng chứng As-Is — các điểm chưa xác minh"]
        J["Chưa xác minh: PASSED hoặc FAILED được ghi như thế nào?<br/>Owner xác minh: QA Owner"]
        K["Chưa xác minh: ai ghi quyết định QA và ghi lúc nào?<br/>Owner xác minh: QA Owner"]
        L["Chưa xác minh: lô được cấp phát thế nào sau kết quả QA?<br/>Owner xác minh: Business Owner và QA Owner"]
        M["Chưa xác minh: lô QA không đạt được xử lý thế nào và liên hệ qua kênh nào?<br/>Owner xác minh: QA Owner, Food Safety Owner và Legal Owner"]
    end

    I -.-> J
    I -.-> K
    I -.-> L
    I -.-> M

    classDef verify fill:#fff4cc,stroke:#b8860b,stroke-dasharray:5 5,color:#000
    class X,R,I,J,K,L,M verify

Tiêu chí đánh giá phương án	Cách đo trong scenario	Ngưỡng đánh giá	Lý do
Chặn cấp phát lô PENDING	Lô có qaStatus: PENDING không xuất được cho sản xuất	Phải chặn	Giảm rủi ro sử dụng nguyên liệu chưa có kết quả QA.
Truy vết lô	Tra được PO, supplier, item, supplier lot, kho và trạng thái QA từ một phiếu nhận	Đủ 6 trường	Cho phép điều tra theo lô thay vì tìm thủ công qua bảng tính và email.
Kiểm soát số lượng	So sánh receivedQuantity với orderedQuantity	Báo ngoại lệ khi vượt PO	Giảm phụ thuộc vào kiểm tra bằng mắt của thủ kho.
Dấu vết quyết định QA	Có vai trò, thời điểm và trạng thái QA	Phải có	Phân biệt ghi nhận kho với kết luận chất lượng.

Phương án	Mô tả	Đáp ứng tiêu chí	Nhận định
OPT-NF-ASIS-001	Giữ bảng tính và email; thêm cột QA thủ công.	Không bảo đảm chặn cấp phát; truy vết phụ thuộc nhập liệu.	Không khuyến nghị.
OPT-NF-ASIS-002	ERP lưu phiếu nhận và trạng thái QA; ERP chặn cấp phát khi qaStatus khác PASSED.	Đáp ứng chặn, truy vết, kiểm soát số lượng và dấu vết QA nếu được cấu hình, kiểm thử và phê duyệt.	Khuyến nghị để đánh giá.

Khuyến nghị BA: đánh giá OPT-NF-ASIS-002 vì trực tiếp xử lý ba điểm yếu quan sát được: ghi nhận trước QA, đối chiếu số lượng thủ công và truy vết phân tán. Đây không phải quyết định được ủy quyền.

Loại kết luận	Nội dung	Thẩm quyền cần có	Trạng thái
Recommendation	Đánh giá ERP chặn cấp phát khi QA chưa đạt.	BA ghi nhận và trình bày.	IN_REVIEW
Authorized Decision	Chưa có quyết định được ủy quyền trong corpus.	Business Owner, QA Owner, Architect; Legal Owner hoặc Food Safety Owner khi có nghĩa vụ pháp lý.	Không được suy diễn là đã phê duyệt
Artifact liên quan	/02-handbook/04-current-state-as-is-and-process-mapping.md; tham chiếu quản trị TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết.	IN_REVIEW

Hệ quả nếu sai: nếu BA ghi WR-NF-ASIS-003 hoặc WR-NF-ASIS-004 như quy tắc đã phê duyệt, đội ERP có thể cấu hình chặn kho dựa trên giả định chưa được QA Owner, Food Safety Owner hoặc Legal Owner xác nhận. Nếu bỏ liên kết lô với PO và nhà cung cấp, điều tra lô lỗi có thể cần ghép dữ liệu thủ công, làm tăng nguy cơ xác định sai phạm vi hàng bị ảnh hưởng.

9. Related Concepts & Dependencies

Core

Phụ thuộc (dependency) là quan hệ trong đó artifact này cần thông tin, định danh hoặc quyết định từ artifact khác để giữ đúng nghĩa. Nguồn chân lý canonical là tệp được chỉ định giữ bản gốc có kiểm soát; chapter này chỉ liên kết, không chép lại quy tắc, cấu trúc dữ liệu hoặc danh mục ID.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Mọi dữ liệu là tổng hợp. IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND là metadata quản trị, không phải baseline hay phê duyệt.

Hướng	Concept hoặc artifact	Canonical ID / tệp	Chapter này dùng để làm gì	Không được làm gì
Upstream	Cấu trúc chapter	CHAPTER_MANIFEST — /01-curriculum/CHAPTER_MANIFEST.md	Xác nhận tên, vị trí, phạm vi chapter 04	Tự đổi tên, số section hoặc đường dẫn
Upstream	Kiến trúc curriculum	01_CURRICULUM_ARCHITECTURE — /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Giữ chuỗi học từ current state sang requirement, testing, delivery	Suy diễn requirement production
Upstream	Danh mục template	TEMPLATE_MANIFEST — /01-curriculum/TEMPLATE_MANIFEST.md	Xác định template có thể nhận đầu ra process mapping	Tạo template ID mới trong chapter
Upstream	Registry ID	TRACEABILITY_ID_REGISTRY — /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra format, nghĩa, lifecycle ID	Tái sử dụng hoặc tự cấp ID
Upstream	Rule catalog	CANONICAL_BUSINESS_RULES — /01-curriculum/CANONICAL_BUSINESS_RULES.md	Liên kết business rule được quản trị	Chép rule thành bản thứ hai
Upstream	Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY — /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Liên kết tên thực thể, field, trạng thái logic	Tự đổi nghĩa qaStatus, lô, PO
Downstream	Requirement và rule analysis	Chapter sau trong handbook	Nhận pain point, actor, bước hiện tại, gap đã quan sát	Nhận kết luận như quyết định đã duyệt
Downstream	API, data, test artifacts	Template và chapter chuyên biệt	Dùng process map làm test basis và input phân tích	Suy diễn schema, endpoint, test case hoàn chỉnh

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

flowchart TB
    CA["01_CURRICULUM_ARCHITECTURE"] -->|upstream reference| ASIS["Chapter 04<br/>Current State As-Is"]
    CM["CHAPTER_MANIFEST"] -->|upstream reference| ASIS
    TM["TEMPLATE_MANIFEST"] -->|template reference| ASIS
    IDR["TRACEABILITY_ID_REGISTRY"] -->|ID reference| ASIS
    BR["CANONICAL_BUSINESS_RULES"] -->|rule reference| ASIS
    DD["CANONICAL_DATA_DICTIONARY"] -->|data reference| ASIS

    ASIS -->|quan sát pain point, actor,<br/>bước hiện tại, gap| RA["Requirement và rule analysis"]
    ASIS -->|test basis và input phân tích| ADA["API, data, test artifacts"]

    NOTE["Boundary: chỉ liên kết nguồn canonical<br/>Không sao chép hoặc tái định nghĩa rule, cấu trúc dữ liệu, ID"]
    ASIS -.-> NOTE

Applied

Facts: Process nhận nguyên liệu mô phỏng dùng các mã đã xuất hiện: WR-NF-ASIS-003, WR-NF-ASIS-004, OPT-NF-ASIS-001, OPT-NF-ASIS-002. Chapter 04 quan sát qaStatus, liên kết lô, PO và nhà cung cấp.

Current Behavior: BA ghi bước hiện tại và điểm yếu: ghi nhận trước QA, đối chiếu số lượng thủ công, truy vết phân tán.

Underlying Need: Giữ một đường truy vết từ quan sát process đến rule, dữ liệu, template và chapter sau; không tạo nhiều bản định nghĩa cho qaStatus.

Options:

Option	Cách làm	Rủi ro
A	Chép định nghĩa qaStatus và rule QA vào process map	Bản sao lệch canonical khi catalog đổi
B	Ghi ID, đường dẫn canonical, ngữ cảnh dùng trong process map	Người đọc phải mở artifact nguồn
C	Tạo ID mới cho cùng observation trong mỗi chapter	Đứt traceability, trùng ý nghĩa

Decision Criteria: Giữ ID ổn định; một nguồn chân lý cho mỗi loại nội dung; reader truy đến artifact gốc; không biến quan sát thành requirement, rule hay quyết định được ủy quyền.

Decision: Chọn B. Chapter 04 ghi WR-NF-ASIS-003 và WR-NF-ASIS-004 như tham chiếu quan sát; nghĩa ID, lifecycle và liên kết chính thức phải tra tại TRACEABILITY_ID_REGISTRY. qaStatus phải tra tại CANONICAL_DATA_DICTIONARY. Quy tắc QA phải tra tại CANONICAL_BUSINESS_RULES khi catalog có entry phù hợp.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Business Owner, QA Owner, Architect, Legal Owner, Accounting Owner hoặc Food Safety Owner giữ thẩm quyền theo loại quyết định. Không có phê duyệt được ghi nhận.

Artifact: /02-handbook/04-current-state-as-is-and-process-mapping.md liên kết đến /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TEMPLATE_MANIFEST.md.

Consequence if Wrong: Nếu chapter tự định nghĩa qaStatus = PASSED như rule canonical, catalog sau này đổi trạng thái hoặc thẩm quyền QA nhưng process map không đổi. Đội phân tích có thể map sai field, QA viết test theo trạng thái cũ, ERP cấu hình chặn cấp phát theo giả định chưa được xác nhận.

Senior Lens

Phân biệt liên kết với sao chép. Liên kết nói: “artifact này phụ thuộc vào định nghĩa tại đây.” Sao chép nói: “artifact này cũng sở hữu định nghĩa.” Sao chép chỉ hợp lệ khi artifact nguồn quy định rõ bản trích xuất được kiểm soát và có version đồng bộ.

Một ID bền vững phải giữ nguyên chuỗi khi ý nghĩa còn nguyên. Nếu thay đổi nghĩa của WR-NF-ASIS-003, không sửa im lặng nội dung dưới cùng ID. Registry phải quyết định giữ, thay thế hoặc ngừng dùng ID theo cơ chế kiểm soát. Evidence là ID tồn tại để truy vết một thực thể qua nhiều artifact; đổi nghĩa làm lịch sử truy vết sai.

Khi dependency đổi im lặng, lỗi lan truyền không chỉ là lỗi tài liệu. Rule catalog đổi điều kiện QA nhưng process map giữ flow cũ; data dictionary đổi field hoặc enum nhưng API analysis dùng tên cũ; template đổi cột bắt buộc nhưng BA handoff thiếu dữ liệu. Kết quả là reader không biết bản nào đúng, dù từng artifact nhìn riêng lẻ vẫn hợp lý.

Quick Reference

Quy tắc	Thực hiện
Cần nghĩa ID	Tra TRACEABILITY_ID_REGISTRY, không tự giải mã hoặc tạo biến thể
Cần business rule	Liên kết CANONICAL_BUSINESS_RULES, không chép thành rule chapter
Cần field, entity, status	Liên kết CANONICAL_DATA_DICTIONARY, không tự định nghĩa schema
Cần template	Tra TEMPLATE_MANIFEST, không tự đặt template ID
Cần đổi dependency	Ghi change impact, giữ liên kết cũ và mới theo governance artifact
Chưa có authority	Gắn IN_REVIEW; không gọi là baseline, approved hoặc production-ready

Core

Traceability (truy vết) nối một nhu cầu với yêu cầu, quy tắc, tiêu chí nghiệm thu, dữ liệu/API và kiểm thử. Mỗi liên kết giữ ID canonical tại nguồn gốc; chương này chỉ ghi tham chiếu, không sao chép nội dung nguồn. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu dưới đây là tổng hợp.

Loại liên kết	Ý nghĩa	Nguồn canonical	Bằng chứng phải giữ	Đích dùng
NEED	Nhu cầu nghiệp vụ: vấn đề hoặc kết quả cần đạt	Nguồn NEED đã đăng ký trong TRACEABILITY_ID_REGISTRY	Stakeholder, vấn đề hiện trạng, tác động đo được hoặc quan sát được	REQ, BR
REQ	Requirement: yêu cầu hệ thống hoặc nghiệp vụ đáp ứng NEED	Nguồn REQ đã đăng ký trong TRACEABILITY_ID_REGISTRY	NEED cha, phạm vi, điều kiện áp dụng	AC, DATA/API, TC
BR	Business Rule: quy tắc nghiệp vụ quyết định hành vi	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Chủ sở hữu quy tắc, điều kiện, kết quả, nhãn Verification required nếu cần	REQ, AC, TC
AC	Acceptance Criteria: điều kiện chấp nhận để xác nhận REQ	Artifact yêu cầu hoặc backlog được kiểm soát	REQ cha, tình huống, kết quả mong đợi	TC
DATA/API	Thuộc tính dữ liệu hoặc hợp đồng giao tiếp hệ thống	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; OpenAPI nếu có đặc tả API	Entity, field, định dạng, quyền truy cập, hệ thống gửi/nhận	REQ, AC, TC
TC	Test Case: trường hợp kiểm thử xác minh AC, BR hoặc REQ	Test artifact được kiểm soát	Test basis, dữ liệu kiểm thử tổng hợp, kết quả mong đợi	Bằng chứng kiểm thử

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

flowchart TB
    LINK["Chú giải<br/>Mũi tên = liên kết truy vết<br/>Không biểu thị trình tự hoặc quan hệ nhân quả"]

    NEED[NEED<br/>Nhu cầu]
    BR[BR<br/>Quy tắc nghiệp vụ]
    REQ[REQ<br/>Yêu cầu]
    DATA[DATA/API<br/>Dữ liệu hoặc giao tiếp]
    AC[AC<br/>Tiêu chí nghiệm thu]
    TC[TC<br/>Test Case]

    NEED --> REQ
    NEED --> BR
    BR --> REQ
    BR --> AC
    BR --> TC
    REQ --> AC
    REQ --> DATA
    REQ --> TC
    DATA --> REQ
    DATA --> AC
    DATA --> TC
    AC --> TC

    classDef note fill:#f8f8f8,stroke:#888,stroke-dasharray: 4 3,color:#333;
    class LINK note

Applied

Mục bắt buộc	Nội dung case mô phỏng Nova Foods
Facts	Nhân viên kho đang ghi nhận lô hàng thủ công trước khi tạo phiếu nhập. Một lỗi nhập tay có thể làm mã lô trên phiếu nhập khác mã lô trên nhãn hàng.
Current Behavior	Quy trình hiện tại cho phép nhập mã lô tự do. Không có bằng chứng trong đầu vào đã cung cấp về validation ERP đang tồn tại.
Underlying Need	Cần giảm sai lệch mã lô giữa thao tác kho và hồ sơ nhận hàng. Suy luận này dựa trên Facts: cùng một mã lô được ghi nhiều lần bằng tay.
Options	(1) Cho nhập tự do và đối chiếu sau. (2) Chọn mã lô từ danh sách dữ liệu nhận hàng. (3) Quét mã vạch.
Decision Criteria	Độ chính xác, thời gian thao tác kho, khả năng có dữ liệu nguồn, chi phí thiết bị, khả năng kiểm thử.
Decision	Chưa chọn phương án. Facts chưa xác nhận dữ liệu nhận hàng có sẵn để chọn danh sách hay nhãn hỗ trợ quét mã vạch.
Authority	Business Owner xác nhận ưu tiên vận hành; Architect xác nhận tích hợp; Data Owner xác nhận mã lô; QA xác nhận test basis.
Artifact	Ghi NEED, REQ, BR, AC, DATA/API và TC bằng ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Quy tắc mã lô chỉ tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md; định nghĩa trường mã lô chỉ tham chiếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Nếu nối TC trực tiếp với NEED mà bỏ REQ và AC, kiểm thử có thể chứng minh thao tác chạy được nhưng không chứng minh yêu cầu được chấp nhận. Nếu gán sai DATA/API, kho có thể nhận dữ liệu lô không khớp nguồn.

Senior Lens

Bảng truy vết không phải danh sách ID để đủ cột. Mỗi hàng phải trả lời được: “TC này kiểm tra điều kiện nào, điều kiện phục vụ REQ nào, REQ giải quyết NEED nào?” Nếu không trả lời bằng tham chiếu canonical, liên kết chưa đủ bằng chứng.

Không tự tạo NEED-*, REQ-*, BR-*, AC-*, DATA-*, API-* hoặc TC-* trong chương này. Lý do: TRACEABILITY_ID_REGISTRY là nguồn quản lý định danh; CANONICAL_BUSINESS_RULES là nguồn quy tắc; CANONICAL_DATA_DICTIONARY là nguồn định nghĩa dữ liệu. IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và VND là metadata corpus, không phải bằng chứng phê duyệt hay baseline.

Quick Reference

Kiểm tra	Đạt khi	Không đạt khi
NEED–REQ	Mỗi REQ chỉ rõ NEED cha hoặc lý do không cần NEED	REQ tồn tại độc lập, không nêu vấn đề cần giải quyết
REQ–BR	REQ tham chiếu BR khi hành vi bị chi phối bởi quy tắc	Chép lại BR vào REQ, tạo hai nguồn chân lý
REQ–AC	AC mô tả điều kiện quan sát được để chấp nhận REQ	AC chỉ ghi “hoạt động đúng”
DATA/API–TC	TC dùng field, định dạng, giao diện từ nguồn canonical	TC tự đặt tên field hoặc payload khác data dictionary/API
Trạng thái	Liên kết ghi đúng IN_REVIEW và không gọi là approved/baselined	Suy diễn approval từ tồn tại artifact hoặc metadata

Core

Thay đổi lan truyền khi artifact nguồn thay đổi ý nghĩa, cấu trúc, trạng thái, định danh hoặc liên kết mà artifact phụ thuộc vẫn giữ giả định cũ. Ví dụ, CANONICAL_BUSINESS_RULES đổi điều kiện áp dụng một quy tắc; mô tả quy trình as-is, requirement, acceptance criteria và test case tham chiếu quy tắc đó phải được đánh giá lại. Lý do: mỗi artifact không tự sở hữu ý nghĩa quy tắc; nó chỉ dùng tham chiếu đến nguồn canonical.

Thay đổi im lặng là thay đổi không có version, lịch sử thay đổi, thông báo ảnh hưởng, hoặc đánh giá liên kết. Đây là lỗi quản trị, không phải chỉ lỗi tài liệu. Artifact sau thay đổi có thể vẫn “đúng chữ” nhưng sai ngữ nghĩa so với nguồn canonical hiện hành.

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

flowchart TB
    A[Nguồn canonical thay đổi] --> B[Ghi version và lịch sử thay đổi]
    B --> C[Xác định artifact phụ thuộc]
    C --> D[Đánh giá liên kết và tác động ngữ nghĩa]
    D --> E[Thông báo owner artifact bị ảnh hưởng]
    E --> F[Cập nhật tham chiếu bị ảnh hưởng<br/>hoặc đánh dấu xung đột]
    F --> G[Review bởi authority phù hợp]
    G --> H[Lưu bằng chứng truy vết]

    A -. Thiếu quản trị thay đổi .-> I[Thay đổi im lặng]
    I --> J[Artifact phụ thuộc giữ giả định cũ]
    J --> K[Quy trình, requirement, test<br/>hoặc sử dụng dữ liệu sai ngữ nghĩa]

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. /01-curriculum/CANONICAL_DATA_DICTIONARY.md là nguồn canonical cho nghĩa logic dữ liệu; /01-curriculum/CANONICAL_BUSINESS_RULES.md là nguồn canonical cho catalog quy tắc; /01-curriculum/TRACEABILITY_ID_REGISTRY.md kiểm soát ID. Tất cả đang IN_REVIEW, v0.9.0, ngày 2026-08-07.

Current Behavior: Mô tả as-is trong handbook ghi nhận người dùng kiểm tra thông tin đơn hàng trước khi tạo chứng từ. Nội dung này chỉ mô tả hành vi hiện tại mô phỏng, không tự tạo business rule, data definition hay quyết định cấu hình ERP.

Underlying Need: Khi nguồn canonical đổi, BA phải biết mô tả as-is nào đã dựa vào giả định cũ. Bằng chứng là cùng một tên trường dữ liệu hoặc cùng một quy tắc có thể xuất hiện ở process map, requirement và test basis. Không kiểm tra liên kết sẽ làm các artifact kể chuyện khác nhau về cùng nghiệp vụ.

Options:
1. Sửa trực tiếp mọi bản sao nội dung.
2. Giữ tham chiếu nguồn canonical, ghi nhận ảnh hưởng rồi cập nhật từng artifact phụ thuộc.
3. Bỏ qua vì artifact đang IN_REVIEW.

Decision Criteria: Phương án phải giữ một nguồn chân lý, bảo toàn ID, không suy diễn approval, và cho thấy artifact nào dùng giả định cũ.

Decision: Chọn phương án 2. Chỉ nguồn canonical đổi nội dung định nghĩa. Artifact phụ thuộc cập nhật tham chiếu, mô tả tác động hoặc ghi nhận mâu thuẫn chờ xử lý. Không sao chép lại định nghĩa canonical vào process map.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì traceability và lịch sử thay đổi. Business Owner xác nhận ý nghĩa nghiệp vụ. Architect xác nhận tác động tích hợp. QA xác nhận test basis. Legal, Accounting, Security hoặc Compliance Owner phải xác minh nội dung thuộc thẩm quyền họ. Không vai trò nào được suy ra approval từ IN_REVIEW.

Artifact: /02-handbook/04-current-state-as-is-and-process-mapping.md phải giữ liên kết tới artifact canonical bằng đúng đường dẫn và ID. Không đổi CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES hoặc TRACEABILITY_ID_REGISTRY thành tên rút gọn.

Consequence if Wrong: Nếu data dictionary đổi nghĩa trường mà process map không được rà soát, BA có thể mô tả sai dữ liệu người dùng xem hoặc nhập. Nếu business rule đổi nhưng acceptance criteria không đổi, QA có thể kiểm thử hành vi cũ và báo đạt sai. Nếu registry đổi ID im lặng, liên kết giữa NEED, REQ, BR, AC, DATA/API và TC có thể trỏ sai hoặc đứt hoàn toàn.

Senior Lens

Không phải mọi thay đổi chữ đều cần lan truyền. BA phân loại trước: thay đổi trình bày không đổi nghĩa có thể chỉ cần ghi lịch sử; thay đổi nghĩa, điều kiện, chủ sở hữu, ID, data field, API contract, trạng thái hoặc nguồn thẩm quyền phải đánh giá toàn bộ phụ thuộc. Cầu nối suy luận: các thành phần này quyết định cách đọc hoặc thực thi nội dung; đổi chúng làm kết luận ở artifact sau có thể không còn hợp lệ.

Không được “sửa cho khớp” bằng cách thay ID cũ trong process map khi chưa kiểm tra registry. ID là khóa truy vết, không phải nhãn trang trí. Nếu ID bị thay, giữ ID cũ như tham chiếu lịch sử khi governance yêu cầu; tạo liên kết thay thế chỉ tại nguồn kiểm soát thay đổi phù hợp.

Quick Reference

Thay đổi im lặng tại nguồn	Thành phần dễ vỡ	Dấu hiệu phát hiện	Hành động tối thiểu
Đổi nghĩa data field	Process map, DATA/API, AC, TC	Cùng tên trường nhưng mô tả khác nhau	Rà soát mọi nơi dùng field
Đổi điều kiện business rule	REQ, AC, TC	Test pass nhưng không phản ánh quy tắc mới	Đánh giá lại test basis
Đổi ID registry	Liên kết NEED, REQ, BR, AC, DATA/API, TC	Link đứt hoặc trỏ nhầm	Đối chiếu registry canonical
Đổi nguồn thẩm quyền	Nội dung pháp lý, kế toán, bảo mật	Nội dung cũ bị diễn đạt như nghĩa vụ chắc chắn	Gắn Verification required; chuyển đúng owner
Đổi trạng thái/version không ghi nhận	Toàn bộ artifact phụ thuộc	Không biết bản nào đang được dùng	Dừng lan truyền; khôi phục lịch sử thay đổi

10. Common Mistakes & Anti-patterns

Core

Sai lầm as-is thường không nằm ở vẽ sơ đồ đẹp hay xấu. Sai ở việc mô tả hành vi quan sát được thành suy đoán, rồi đội giao hàng dùng suy đoán đó làm đầu vào thiết kế. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Sai lầm	Dấu hiệu quan sát được	Nguyên nhân gốc	Hành động sửa
Hỏi “quy trình chuẩn là gì?” thay vì ghi nhận việc đang xảy ra	Sơ đồ chỉ có luồng thành công; không có làm lại, chờ, Excel, email hoặc xử lý tay	BA lẫn lộn as-is hiện trạng với to-be trạng thái mong muốn	Ghi từng bước theo bằng chứng: ai làm, dùng đâu, input, output, điểm chờ, ngoại lệ
Gom nhiều vai trò thành một “Người dùng”	Không biết ai tạo, kiểm tra, duyệt, sửa hoặc chịu lỗi	Muốn sơ đồ ngắn hơn thực tế	Tách vai trò theo hành động và trách nhiệm, không theo chức danh chung
Ghi “hệ thống tự động kiểm tra” không nêu điều kiện	Không có dữ liệu đầu vào, điều kiện quyết định hoặc kết quả khi fail	Người ghi chép tin mô tả miệng nhưng không kiểm tra ví dụ	Ghi rõ trigger, dữ liệu kiểm tra, kết quả pass/fail và nơi lưu kết quả
Bỏ qua ngoại lệ vì “ít xảy ra”	Không có luồng hàng thiếu, sai mã hàng, trùng đơn hoặc mất kết nối	Đội dự án chỉ ưu tiên demo luồng chính	Ghi ngoại lệ có tác động tiền, tồn kho, giao hàng hoặc dữ liệu; nêu cách xử lý hiện tại
Dùng sơ đồ để thay biên bản quan sát	Node trên sơ đồ không có nguồn, thời điểm hoặc người cung cấp thông tin	Coi diagram là bằng chứng tự đủ	Gắn mỗi phát hiện với ghi chép quan sát hoặc nguồn artifact đã biết
Sửa hiện trạng để “hợp lý hơn” trước khi xác minh	Người vận hành nói một cách, sơ đồ viết cách khác	BA vô thức thiết kế giải pháp khi đang phân tích	Giữ mô tả hiện trạng; tách đề xuất cải tiến sang artifact khác
Kết luận nguyên nhân từ một lần phỏng vấn	Một ý kiến cá nhân thành “quy trình công ty”	Thiếu đối chiếu giữa vai trò, dữ liệu và chứng cứ	Đánh dấu là nhận định cần kiểm tra; đối chiếu giao dịch mẫu tổng hợp và vai trò liên quan

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

flowchart TB
    A[BA quan sát bước làm việc hiện tại] --> B[BA ghi vai trò, trigger, input, output, nguồn bằng chứng, thời điểm và người cung cấp]
    B --> C{Có bằng chứng kiểm tra được?}

    C -- Chưa có --> N[Giữ là nhận định cần xác minh; không đưa vào as-is map hoặc requirement]
    N --> E[BA ghi câu hỏi xác minh]
    E --> J[BA đối chiếu quan sát, giao dịch mẫu tổng hợp, người liên quan hoặc artifact đã biết]
    J --> M{Bằng chứng xác nhận bước hiện tại?}
    M -- Có --> C
    M -- Không --> K[BA lưu kết luận không được xác nhận kèm nguồn và loại khỏi as-is map]
    M -- Chưa đủ --> N

    C -- Có --> D[BA đối chiếu ngoại lệ và điểm bàn giao]
    D --> F{Có ngoại lệ hoặc điểm bàn giao chưa ghi nhận?}
    F -- Có --> L[BA ghi tác động, cách xử lý hiện tại và nhận định cần xác minh]
    L --> E
    F -- Không --> H[BA cập nhật bản đồ hiện trạng]

Applied

Facts: Trong Nova Foods mô phỏng, nhân viên kho nhận phiếu xuất hàng từ email, tra tồn kho trên ERP, rồi ghi chênh lệch vào bảng tính khi số lượng không khớp.

Current Behavior: Bản as-is đầu tiên chỉ ghi: “ERP kiểm tra tồn kho, kho xuất hàng.” Bản này bỏ mất email, bảng tính, thao tác ghi chênh lệch và điểm chờ phản hồi.

Underlying Need: Đội giao hàng cần biết luồng hiện tại thật để xác định nơi dữ liệu tồn kho có thể lệch. Cầu nối suy luận: bảng tính nằm ngoài ERP; nếu không ghi nhận, thiết kế sau có thể giả định ERP là nguồn duy nhất.

Options:
1. Giữ sơ đồ rút gọn, không nêu bảng tính.
2. Ghi bảng tính như bước hiện trạng và đánh dấu cần xác minh chi tiết.
3. Đổi ngay thành chức năng ERP mới.

Decision Criteria: Chọn phương án giữ đúng hành vi quan sát được, không tạo giải pháp sớm, cho phép truy ngược phát hiện.

Decision: Chọn phương án 2. Process map ghi bước “Ghi chênh lệch vào bảng tính” sau bước tra tồn kho. Nội dung không kết luận bảng tính là nguồn dữ liệu chính thức.

Authority: Không có thẩm quyền nào được suy ra từ process map. Business Owner xác nhận thực tế vận hành; Architect xác nhận thiết kế; Accounting Owner xác nhận ảnh hưởng hạch toán nếu có.

Artifact: Cập nhật /02-handbook/04-current-state-as-is-and-process-mapping.md tại phần as-is của case Nova Foods mô phỏng. Giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Nếu bỏ bước bảng tính, đội kỹ thuật có thể chỉ kiểm thử ERP. Chênh lệch vẫn phát sinh ngoài hệ thống, nhưng không có test case hoặc quyết định xử lý tương ứng.

Senior Lens

Dấu hiệu mạnh nhất của as-is yếu: sơ đồ không có ma sát. Quy trình thật thường có chờ duyệt, nhập lại dữ liệu, đối chiếu thủ công, trao đổi ngoài hệ thống hoặc ngoại lệ. Không phải mọi ma sát đều là lỗi cần số hóa. BA ghi nhận trước, đánh giá cải tiến sau.

Sai lầm đội giao hàng hay gặp: gọi phát hiện quan sát là “requirement đã chốt”. Phát hiện as-is chỉ trả lời hiện tại diễn ra thế nào. Requirement trả lời thay đổi nào cần có. Hai loại nội dung cần tách để tránh biến mô tả thành cam kết.

[!WARNING] Không xóa bước xử lý tay khỏi as-is chỉ vì bước đó không mong muốn. Xóa làm mất đường điều tra khi tồn kho, đơn hàng hoặc giao hàng sai. Ranh giới khôi phục an toàn: khôi phục bước theo bằng chứng đã ghi; không tự thêm quy tắc, quyền duyệt hoặc cấu hình ERP.

Quick Reference

Red flag khi review	Câu hỏi kiểm tra	Sửa tối thiểu
Mọi bước đều “tự động”	Ai xử lý khi kiểm tra thất bại?	Thêm nhánh fail và người xử lý hiện tại
Không có công cụ ngoài ERP	Có email, bảng tính, giấy hoặc chat không?	Ghi công cụ và dữ liệu được chuyển
Không có thời gian chờ	Bước nào chờ người khác phản hồi?	Ghi điểm bàn giao và trạng thái chờ
Một actor làm toàn bộ	Ai tạo, ai kiểm tra, ai quyết định?	Tách swimlane hoặc nhãn vai trò
Sơ đồ đọc như giải pháp	Đây là việc đang làm hay việc đề xuất?	Đổi về mô tả quan sát được; tách đề xuất

Rủi ro thật và ranh giới phục hồi an toàn

Cảnh báo — rủi ro vận hành: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp. Không được biến ví dụ thành cấu hình ERP, quy tắc pháp lý, kế toán, thuế, an toàn thực phẩm hoặc quyết định production.

Cảnh báo chỉ dùng khi lỗi có thể gây sai giao dịch, mất khả năng kiểm soát, tiết lộ dữ liệu, tạo số liệu sai hoặc dẫn đội triển khai hành động sai. Lỗi diễn đạt chưa đẹp không cần cảnh báo; ghi nhận và sửa trong vòng review bình thường.

Tình huống lỗi tại Nova Foods mô phỏng	Dấu hiệu quan sát được	Rủi ro thật	Phục hồi an toàn	Ranh giới không được vượt
Sơ đồ As-Is ghi “Kho tự động xuất hàng khi đơn bán được tạo” nhưng không có bằng chứng bước kiểm tra tồn kho	Không có nguồn, người thực hiện, thời điểm hoặc điều kiện ngoại lệ	Đội thiết kế hiểu sai điểm kiểm soát tồn kho; có thể tự động hóa bước chưa được xác nhận	Đánh dấu phát biểu là giả định học liệu; quay về nguồn ghi nhận; tách “đơn bán tạo” và “xuất kho” thành hai hoạt động chưa xác minh liên kết	Không tự kết luận cần tích hợp hoặc tự động xuất kho
Bảng quy trình ghi “đã tuân thủ Nghị định 123/2020/NĐ-CP”	Không có xác minh từ Legal Owner hoặc Accounting Owner; không có tham chiếu điều khoản đã kiểm tra	Tạo tuyên bố tuân thủ không có thẩm quyền	Xóa tuyên bố tuân thủ; ghi Verification required; chuyển câu hỏi sang Legal Owner và Accounting Owner	Không diễn giải luật, thuế, hóa đơn thay vai trò có thẩm quyền
Luồng hoàn trả dùng mũi tên từ “Nhận hàng trả” thẳng đến “Hoàn tiền”	Thiếu kiểm tra hàng, phê duyệt, chứng từ hoặc ngoại lệ	Sai tiền, sai tồn kho, mất dấu vết kiểm toán	Khôi phục trạng thái trung gian “Kiểm tra hàng trả”; ghi rõ chưa xác nhận điều kiện hoàn tiền	Không bịa điều kiện phê duyệt hoặc ngưỡng tiền VND
Nhóm sửa tên bước trong sơ đồ nhưng không sửa liên kết artifact	ID bước, nguồn hoặc tham chiếu khác nhau giữa sơ đồ và bảng mô tả	Đứt traceability; QA và đội build kiểm tra khác đối tượng	Khôi phục ID canonical từ artifact nguồn; ghi thay đổi trong phạm vi IN_REVIEW; kiểm tra lại tất cả tham chiếu	Không tạo ID mới hoặc gọi nội dung là baseline, approved

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

flowchart TB
    A[Phát hiện phát biểu rủi ro] --> B{Có bằng chứng nguồn và thẩm quyền đã xác minh?}
    B -- Có --> C[Giữ phát biểu và liên kết bằng chứng nguồn, Owner hoặc thẩm quyền đã xác minh]
    B -- Không --> D[Ngừng suy diễn]
    D --> E{Đây là quyết định thiết kế đã triển khai?}
    E -- Có --> F[Ghi nhận issue]
    F --> G[Sửa hoặc khôi phục artifact theo bằng chứng hiện có]
    G --> H[Chuyển đúng Owner theo loại phát biểu, ví dụ Legal hoặc Accounting]
    E -- Không --> I[Đánh dấu giả định hoặc Verification required]
    I --> H
    H --> J[Chỉ cập nhật khi có bằng chứng ghi nhận]

Phục hồi an toàn nghĩa là sửa artifact để phản ánh mức biết hiện có, không “vá” khoảng trống bằng quy tắc tự nghĩ ra. Với Nova Foods mô phỏng, có thể giữ ví dụ tổng hợp và nhãn Verification required; không được dùng nhãn này để che một quyết định thiết kế đã triển khai. Trạng thái IN_REVIEW, Version v0.9.0, ngày 2026-08-07 cho biết nội dung còn xem xét; không phải bằng chứng phê duyệt hay baseline.

Core

Năm lỗi khác loại, không gộp thành “thiếu rõ ràng”. Phân loại đúng giúp sửa đúng chỗ và không biến suy đoán của BA thành quy tắc ERP Nova Foods mô phỏng.

Loại lỗi	Dấu hiệu quan sát được	Nguyên nhân gốc	Hành động sửa trong artifact
Mơ hồ (ambiguity)	Câu “duyệt đơn lớn” không nêu ngưỡng, người duyệt, thời điểm	Từ định tính chưa có điều kiện kiểm chứng	Tách thành câu hỏi mở; ghi giá trị chưa xác minh, owner cần xác minh và nguồn cần đối chiếu
Không đầy đủ (incompleteness)	Luồng có “tạo phiếu giao hàng” nhưng không có ngoại lệ thiếu tồn kho	Chỉ phỏng vấn happy path, tức luồng thành công	Bổ sung nhánh ngoại lệ, đầu vào, đầu ra, trạng thái và điểm bàn giao; không tự đặt business rule
Khẳng định thẩm quyền không có chứng cứ	Ghi “Kế toán đã phê duyệt” nhưng chỉ có ghi chú họp không định danh	Nhầm người tham dự, Owner artifact và người có quyền quyết định	Đổi thành “ghi nhận ý kiến”; nêu Authority là Verification required; giữ nguồn gốc ghi chú
Dùng sai ký pháp (notation misuse)	Sơ đồ PlantUML được gọi là BPMN	Nhầm công cụ vẽ với chuẩn mô hình	Gọi đúng là “PlantUML activity diagram”; chỉ gọi BPMN khi ký pháp tuân BPMN 2.0.2 của OMG
Đứt truy vết (traceability break)	Bước AS-IS nhắc “kiểm tra hạn mức” nhưng không liên kết rule, dữ liệu hay nguồn	Sao chép nội dung giữa tài liệu, đổi tên ID hoặc dùng nguồn không canonical	Giữ nguyên ID, liên kết tới artifact canonical, ghi source classification và trạng thái xác minh

⚠️ Rủi ro thực: Không được đổi IN_REVIEW thành “đã phê duyệt”, “đã baseline” hoặc “được Nova Foods áp dụng”. Theo /01-curriculum/CHAPTER_MANIFEST.md, IN_REVIEW không tạo approval ngầm định. Phục hồi an toàn: giữ trạng thái hiện hữu, xóa tuyên bố không có chứng cứ, ghi rõ vai trò cần xác minh. Không tự tạo approval reference.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp.

Trường	Nội dung artifact-ready
Facts	Bản nháp AS-IS ghi: “Kho tạo phiếu xuất khi Sales duyệt đơn lớn.” Sơ đồ có nút quyết định “Đơn lớn?” nhưng không có ngưỡng, không nêu Sales role, không có nguồn.
Current Behavior	Người đọc có thể hiểu “lớn” là giá trị VND, số lượng thùng hoặc mức rủi ro khách hàng. Hai người triển khai có thể tạo hai cấu hình khác nhau.
Underlying Need	Cần mô tả hành vi hiện tại có bằng chứng, không cần phát minh ngưỡng duyệt hay thẩm quyền duyệt.
Options	1. Tự đặt ngưỡng 100000000 VND. 2. Bỏ nút quyết định. 3. Giữ nút quyết định với nhãn “Tiêu chí đơn lớn — Verification required”, liên kết nguồn phỏng vấn hoặc artifact được kiểm soát khi có.
Decision Criteria	Không suy diễn quy tắc; mô hình vẫn phản ánh điểm quyết định được quan sát; người đọc thấy rõ khoảng trống; traceability không bị đứt.
Decision	Chọn phương án 3. Không ghi ngưỡng, không gán quyền duyệt, không tạo ID quy tắc mới.
Authority	Business Owner xác minh tiêu chí nghiệp vụ; Accounting Owner xác minh nếu tiêu chí liên quan hạn mức tín dụng hoặc giá trị tiền; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact và truy vết.
Artifact	/02-handbook/04-current-state-as-is-and-process-mapping.md; tham chiếu quản trị TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY. Các artifact này đều IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Tự đặt ngưỡng có thể làm sai luồng AS-IS, tạo test case sai và bị diễn giải nhầm là quyết định vận hành hoặc kế toán.

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

flowchart TB
    A["Bản nháp ghi nhận:<br/>Sales duyệt đơn lớn;<br/>Kho tạo phiếu xuất<br/>Chưa xác minh"] --> B["Ghi nhận điểm quyết định AS-IS<br/>Không gán ngưỡng hoặc quyền duyệt"]
    B --> C["Principal IT Business Analyst / Technical Curriculum Author<br/>chuyển Business Owner xác minh tiêu chí nghiệp vụ"]
    C --> D{"Tiêu chí liên quan hạn mức tín dụng<br/>hoặc giá trị tiền?"}
    D -->|Có| E["Accounting Owner xác minh bổ sung"]
    D -->|Không| F{"Có nguồn phỏng vấn hoặc artifact được kiểm soát,<br/>Business Owner đã xác nhận,<br/>và Accounting Owner đã xác nhận nếu cần?"}
    E --> F
    F -->|Chưa đủ| G["Giữ trạng thái Verification required<br/>Duy trì artifact và truy vết"]
    F -->|Đủ| H["Chỉ cập nhật ngưỡng hoặc quyền duyệt<br/>được nguồn và owner có thẩm quyền xác nhận"]
    H --> I["Cập nhật artifact có truy vết"]
    B -.->|Nếu tự suy diễn| R["Sai luồng AS-IS<br/>Tạo test case sai<br/>Bị hiểu nhầm thành quyết định vận hành hoặc kế toán"]

Sơ đồ trên là Mermaid flowchart, không phải BPMN. Nó chỉ biểu diễn khoảng trống quan sát trong mô tả AS-IS.

Senior Lens

Phân biệt mơ hồ với không đầy đủ bằng câu hỏi kiểm tra. Mơ hồ xảy ra khi câu đã có nội dung nhưng có nhiều cách hiểu, như “duyệt nhanh”. Không đầy đủ xảy ra khi thông tin cần để tái hiện hành vi không tồn tại, như thiếu nhánh từ chối, trigger hoặc dữ liệu đầu vào. Bằng chứng là: nếu thay một từ bằng giá trị cụ thể giải quyết vấn đề, đó thường là mơ hồ; nếu phải thêm một bước, trạng thái hoặc ngoại lệ, đó là không đầy đủ.

Không dùng nguồn chuẩn để bù cho sự kiện Nova Foods chưa được chứng minh. BABOK Guide của IIBA hỗ trợ thuật ngữ và thực hành BA; BPMN 2.0.2 của OMG là nguồn chuẩn cho ký pháp BPMN. Các nguồn này không chứng minh quy trình, quyền hạn hoặc cấu hình ERP của Nova Foods mô phỏng. Luật, thuế, kế toán, dữ liệu cá nhân và an toàn thực phẩm chỉ được ghi thành yêu cầu sau khi owner có thẩm quyền xác minh nguồn chính thức hiện hành.

Ranh giới phục hồi an toàn: BA có thể sửa nhãn sơ đồ, thêm câu hỏi xác minh, ghi nguồn, giữ ID canonical và tạo liên kết bị thiếu. BA không được tự điền ngưỡng tiền VND, tự chỉ định người phê duyệt, suy diễn nghĩa vụ pháp lý, hay thay trạng thái artifact thành baseline hoặc approval.

Quick Reference

Kiểm tra trước khi giữ một câu AS-IS	Kết quả cần có
Ai thực hiện?	Vai trò quan sát được hoặc Verification required
Khi nào kích hoạt?	Sự kiện, thời điểm hoặc khoảng trống được gắn nhãn
Dữ liệu nào đổi?	Tên dữ liệu giữ khớp CANONICAL_DATA_DICTIONARY khi đã có mục canonical
Quy tắc nào chi phối?	ID canonical giữ nguyên hoặc ghi chưa có nguồn xác minh
Sơ đồ thuộc chuẩn nào?	BPMN chỉ khi dùng BPMN 2.0.2; Mermaid/PlantUML phải gọi đúng tên
Ai có quyền kết luận?	Authority theo loại quyết định, không suy ra từ người viết hoặc người dự họp
Liên kết đi đâu?	Đúng filename, artifact ID, source classification và trạng thái IN_REVIEW

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn “mô tả nghe hợp lý”; Senior BA chọn kết luận chịu được phản biện. Với AS-IS, mỗi kết luận phải tách ba lớp: fact (sự kiện quan sát được), inference (suy luận từ fact) và decision (quyết định cần đúng authority). Ví dụ, “kế toán kiểm tra đơn trước khi xuất hóa đơn” chỉ là fact khi có quan sát, mẫu chứng từ, log hệ thống hoặc xác nhận nguồn có thẩm quyền. Từ fact này, BA có thể suy luận kiểm tra là điểm kiểm soát; suy luận không tự chứng minh đây là quy tắc bắt buộc hay cấu hình ERP.

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

flowchart TB
    A[Fact được quan sát] --> C[Đối chiếu bằng chứng]
    B[Nguồn hoặc artifact<br/>kèm thời điểm, phạm vi, cách tạo] --> C

    C --> D{Bằng chứng đủ chất lượng?}
    D -- Không --> V[Record: Verification required]
    D -- Có --> E{Nhất quán với nguồn khác?}

    E -- Có --> F[Inference có giới hạn<br/>nêu căn cứ và điều chưa kết luận]
    E -- Không --> V

    F --> G{Cần bước tiếp theo?}
    G -- Chỉ ghi nhận --> H[Giữ fact, inference và giới hạn<br/>không tạo decision]
    G -- Xác minh thêm --> V
    G -- Cần quyết định --> K[Kiểm tra điều kiện escalation]

    V --> K

    K --> L{Có red flag?}
    L -- Không, chỉ thiếu hoặc yếu evidence --> W[Xác minh thêm<br/>chưa chốt thiết kế]
    L -- Có --> X[Escalation package<br/>nguồn, phạm vi, bất định, rủi ro,<br/>option và decision authority]

    R[Red flags:<br/>nhiều authority;<br/>canonical source mâu thuẫn thực hành;<br/>thiếu evidence nhưng bị yêu cầu chốt thiết kế;<br/>tác động quyền truy cập, phê duyệt, tiền, tồn kho,<br/>hóa đơn, dữ liệu cá nhân, truy xuất, tích hợp hoặc bảo mật] --> L

    L -- Không, đủ evidence và không có red flag --> M{Owner miền nào?}
    X --> M

    M -- Nghiệp vụ --> N[Business Owner hoặc Process Owner]
    M -- Hệ thống hoặc tích hợp --> O[System Owner hoặc Architect]
    M -- Kế toán, thuế hoặc pháp lý --> P[Accounting Owner, Legal Owner<br/>hoặc Compliance Owner]
    M -- Rủi ro --> Q[Risk Owner]
    M -- Bảo mật --> S[Security]
    M -- Chất lượng --> T[QA]
    M -- Nhiều miền --> Z[Phối hợp các owner miền liên quan]

    N --> U[Review evidence, inference,<br/>risk và option]
    O --> U
    P --> U
    Q --> U
    S --> U
    T --> U
    Z --> U

    U --> Y{Evidence đủ để authority quyết định?}
    Y -- Có --> AA[Authority phù hợp ra quyết định<br/>và giữ traceability]
    Y -- Không --> W

Trade-off thường nằm giữa tốc độ ghi nhận và độ tin cậy. Ghi nhanh từ một buổi phỏng vấn giúp khám phá luồng, nhưng không đủ để khẳng định quyền phê duyệt, ngưỡng tiền VND, nghĩa vụ hóa đơn, lưu vết truy xuất hoặc xử lý dữ liệu cá nhân. Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; vì vậy BA ghi “nhân viên kho cho biết” như bằng chứng phỏng vấn, không đổi thành “Nova Foods áp dụng” khi chưa có artifact hoặc authority xác nhận.

Tình huống	Quy tắc thường dùng	Ngoại lệ cần giữ	Authority quyết định	Cách ghi trong artifact
Hai vai trò mô tả khác nhau về bước duyệt	Không chọn theo chức danh cao hơn	Một người có thể mô tả quy trình mục tiêu, người kia mô tả AS-IS	Business Owner xác định thực hành nghiệp vụ; Process Owner xác nhận vận hành	Ghi hai phiên bản, nguồn, thời điểm Asia/Ho_Chi_Minh, phạm vi và Verification required
Log ERP khác với phỏng vấn	Ưu tiên bằng chứng hệ thống cho hành vi ghi nhận	Log có thể thiếu thao tác ngoài hệ thống hoặc sai phạm vi truy xuất	System Owner và Process Owner	Nêu tập log, kỳ thời gian, trường dữ liệu, giới hạn truy xuất; không gọi log là toàn bộ quy trình
Yêu cầu liên quan kế toán, thuế, pháp lý	Không suy diễn nghĩa vụ từ kinh nghiệm dự án	Nguồn chính thức có thể đã thay đổi hoặc cần diễn giải chuyên môn	Accounting Owner, Legal Owner hoặc Compliance Owner	Gắn Verification required; liên kết nguồn chính thức, không tự tạo clause
Giải pháp nhanh mâu thuẫn kiểm soát	Không hy sinh kiểm soát chỉ để giảm bước	Có thể chấp nhận rủi ro nếu owner có thẩm quyền quyết định và ghi nhận	Risk Owner cùng owner miền liên quan	Tách option, rủi ro, hậu quả, decision authority; không gọi là approval nếu chưa có tham chiếu

Chất lượng bằng chứng đo bằng khả năng kiểm tra lại, không đo bằng mức tự tin người nói. Bằng chứng mạnh thường có nguồn xác định, thời điểm, phạm vi, cách tạo và khả năng đối chiếu độc lập. Bằng chứng yếu gồm trí nhớ không định thời điểm, ảnh chụp màn hình không có ngữ cảnh, file xuất không rõ nguồn, hoặc câu “luôn làm như vậy”. Bằng chứng yếu vẫn hữu ích để tạo câu hỏi, nhưng không đủ để biến thành canonical business rule trong CANONICAL_BUSINESS_RULES hoặc định nghĩa dữ liệu trong CANONICAL_DATA_DICTIONARY.

Red flag cần escalation khi kết luận AS-IS làm thay đổi quyền truy cập, trách nhiệm phê duyệt, số tiền, tồn kho, hóa đơn, dữ liệu cá nhân, truy xuất thực phẩm, tích hợp hoặc kiểm soát bảo mật. Escalation cũng bắt buộc khi một đề xuất thuộc đồng thời nhiều authority, khi nguồn canonical mâu thuẫn với thực hành được kể lại, hoặc khi thiếu evidence nhưng nhóm yêu cầu BA chốt thiết kế. Principal IT Business Analyst / Technical Curriculum Author chỉ đóng gói vấn đề, giữ traceability và phân loại nguồn; vai trò này không thay Business Owner, Architect, Legal Owner, Accounting Owner, Security hay QA.

Senior BA viết bất định theo cấu trúc có thể bảo vệ: “Quan sát từ [nguồn] trong [phạm vi] cho thấy [fact]. Vì [lý do nối fact với inference], khả năng cao [inference]. Chưa đủ bằng chứng để kết luận [giới hạn]. Khuyến nghị [option] để giảm [risk]; quyết định cần [authority].” Cách viết này không tạo chắc chắn giả, vẫn cho đội dự án biết cần xác minh gì và ai phải quyết định. Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07 không phải baseline, approval, xác nhận tuân thủ hay quyền dùng production.

Senior Lens

Senior BA rà soát As-Is không tìm quy trình “đẹp”. Mục tiêu: xác định hành vi đang xảy ra, bằng chứng đủ tin cậy, điểm kiểm soát thiếu, và nơi quyết định vượt thẩm quyền BA. Nova Foods là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp; IN_REVIEW và v0.9.0 không phải baseline hay phê duyệt.

Heuristic rà soát	Cách kiểm tra	Dấu hiệu đỏ	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Một bước As-Is phải có bằng chứng	Đối chiếu quan sát, mẫu chứng từ tổng hợp, log mô phỏng, hoặc xác nhận từ người thực hiện	Bước chỉ dựa vào “mọi người vẫn làm vậy”	Không có bằng chứng độc lập cho bước tạo, sửa, duyệt, hoặc xóa dữ liệu	Quy trình khẩn cấp có thể thiếu log tức thời; vẫn phải ghi nhận ngoại lệ và người chịu trách nhiệm sau sự kiện
Tách “đang làm” khỏi “nên làm”	Dùng động từ mô tả hiện trạng: nhập, gửi, đối chiếu, phê duyệt	Sơ đồ As-Is chứa giải pháp ERP, control mong muốn, hoặc rule chưa xác minh	Stakeholder yêu cầu sửa sơ đồ để che workaround	Không tách khi artifact được gắn rõ là To-Be; section này chỉ lập As-Is
Một quyết định phải có owner	Ghi vai trò quyết định, dữ liệu đầu vào, tiêu chí, kết quả	“Hệ thống tự quyết” nhưng không rõ rule, quyền, hoặc cấu hình	Quyết định ảnh hưởng giá, tồn kho, thanh toán, dữ liệu cá nhân, truy xuất thực phẩm	BA không thay Business Owner, Accounting Owner, Legal Owner, Security, Architect
Một handoff phải có điểm nhận	Xác định ai gửi, ai nhận, vật mang tin, thời điểm	Email, chat, giấy, hoặc lời nói là nguồn dữ liệu không kiểm soát	Handoff làm mất dấu vết đơn hàng, lô hàng, hoặc trạng thái phê duyệt	Handoff nội bộ tức thời có thể không cần artifact riêng nếu hệ thống lưu audit trail đầy đủ
Đo khác biệt, không đo cảm giác	Ghi số lượng mẫu tổng hợp, tần suất, thời gian, tỷ lệ lỗi	Kết luận “thường xuyên”, “chậm”, “nhiều lỗi” không có phạm vi đo	Tranh luận ưu tiên chỉ dựa vào cấp bậc hoặc cảm nhận	Không suy ra KPI khi mẫu quá nhỏ; ghi giới hạn bằng chứng thay vì ngoại suy
Nguồn canonical thắng bản sao	Kiểm tra ID, tệp, trạng thái trong registry và manifest	Rule, data field, hoặc ID xuất hiện với nhiều tên	Mâu thuẫn với /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, hoặc /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Không tự chọn bản “có vẻ mới hơn”; dừng và đối chiếu artifact kiểm soát

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

flowchart TB
    A[Phát hiện bước As-Is] --> B{Có bằng chứng kiểm tra được?}
    B -->|Có| C{Đây có phải điểm quyết định?}
    B -->|Không| D[Gắn khoảng trống bằng chứng]
    D --> E{Bước tạo, sửa, duyệt hoặc xóa dữ liệu không có bằng chứng độc lập?}
    E -->|Có| F[Escalate theo thẩm quyền phù hợp]
    E -->|Không| G[Không suy diễn quy tắc hoặc kiểm soát]
    F --> G

    C -->|Không| H{Workaround là kiểm soát bù trừ duy nhất?}
    C -->|Có| I{Có người chịu trách nhiệm quyết định rõ?}
    I -->|Không| J[Escalate xác định người chịu trách nhiệm quyết định]
    I -->|Có| H

    H -->|Có| K[Giữ workaround trong As-Is, nêu rủi ro, chuyển quyết định thay đổi cho người chịu trách nhiệm phù hợp]
    H -->|Không| L{Có trigger escalation bắt buộc?}
    K --> L

    L -->|Không| M[Ghi vào process map As-Is]
    L -->|Có| N[Escalate đến Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner phù hợp; owner xác minh diễn giải pháp lý]

    O[Giao thoa hai thẩm quyền; pháp lý; kế toán; bảo mật; dữ liệu cá nhân; an toàn thực phẩm; quyền truy cập; API; dữ liệu giá trị bằng VND] -.-> L

Escalate ngay khi một phát hiện đồng thời chạm hai thẩm quyền, ví dụ thay đổi trạng thái giao hàng vừa ảnh hưởng ghi nhận kế toán vừa ảnh hưởng truy xuất lô. Escalate cũng bắt buộc khi có dữ liệu cá nhân, quyền truy cập, API, dữ liệu giá trị bằng VND, hoặc diễn giải từ Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, quy định hóa đơn, hay Luật An toàn thực phẩm. Nguồn pháp lý trong corpus chỉ là ranh giới tham chiếu; kết luận áp dụng cần Legal Owner, Accounting Owner, Compliance Owner, hoặc domain owner xác minh.

Không áp dụng quy tắc “phải chuẩn hóa ngay” khi workaround đang là kiểm soát bù trừ duy nhất. Ví dụ, nhân viên kho Nova Foods mô phỏng đối chiếu phiếu xuất tổng hợp với số lô trước khi giao. Dù thao tác thủ công gây chậm, xóa nó trước khi xác minh control thay thế có thể làm mất khả năng phát hiện lệch lô. Khi đó, map As-Is phải giữ workaround, nêu rủi ro và chuyển quyết định thay đổi cho owner phù hợp.

Senior Lens

Senior BA không biến thiếu bằng chứng thành kết luận. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, khuyến nghị phải tách rõ: fact là điều quan sát hoặc tài liệu chứng minh được; inference là suy luận nối từ fact đến khả năng; assumption là giả định dự án chưa được xác minh; Verification required là điểm cần vai trò có thẩm quyền xác nhận. Cách tách này giúp người đọc kiểm tra lập luận thay vì tin vào độ tự tin của người viết.

Trường ghi nhận	Nội dung artifact-ready	Ví dụ Nova Foods mô phỏng
Issue ID	Mã vấn đề ổn định	ASIS-ISS-017
Fact	Bằng chứng, nguồn, ngày, phạm vi mẫu	Ba phiếu xuất kho tổng hợp ngày 2026-07-15 cho thấy nhân viên nhập lại mã lô từ giấy vào ERP.
Inference	Lý do fact dẫn đến nhận định	Nhập lại dữ liệu tạo điểm sao chép thủ công; vì vậy có nguy cơ sai mã lô. Ba mẫu không chứng minh tần suất toàn bộ kho.
Uncertainty	Điều chưa biết, ảnh hưởng nếu sai	Chưa có nhật ký lỗi hoặc số lượng giao dịch đủ lớn để đo tỷ lệ sai.
Assumption	Điều tạm dùng để phân tích	Giả định kho có thiết bị quét mã vạch dùng được trong ca xuất hàng.
Recommendation	Hành động đề xuất, giới hạn hiệu lực	Đề xuất khảo sát nhật ký giao dịch 30 ngày trước khi quyết định thay đổi luồng ERP.
Authority	Vai trò quyết định hoặc xác minh	Warehouse Manager xác nhận thao tác; Architect đánh giá tích hợp; Business Owner quyết định ưu tiên.
Status	Trạng thái không hàm ý phê duyệt	IN_REVIEW, Version v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.

Mẫu câu phòng vệ: “Dựa trên ba phiếu xuất kho tổng hợp đã xem, có bằng chứng về nhập lại mã lô tại mẫu quan sát. Chưa có dữ liệu đủ rộng để kết luận mức độ lỗi hoặc lợi ích tài chính. Khuyến nghị thu thập nhật ký 30 ngày và để Warehouse Manager xác nhận luồng thực tế trước khi Business Owner quyết định ưu tiên.” Câu này nêu fact, giới hạn mẫu, hành động kế tiếp, đúng thẩm quyền; không nói “đã được duyệt”, “chắc chắn giảm lỗi”, hoặc “tuân thủ pháp luật”.

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

flowchart TB
    A[Fact có nguồn, ngày và phạm vi mẫu] --> B[Inference nêu cầu nối lý luận]
    B --> C[Uncertainty: điều chưa biết và ảnh hưởng nếu sai]
    C --> D[Assumption: giả định tạm dùng để phân tích]
    D --> E[Recommendation có điều kiện]

    E --> F{Có thay đổi hoặc cần xác nhận luồng kho?}
    F -- Có --> FW[Warehouse Manager xác nhận luồng thực tế]
    F -- Không --> G{Có tác động tích hợp?}
    FW --> G

    G -- Có --> GA[Architect đánh giá tích hợp]
    G -- Không --> H{Chạm phạm vi chuyên môn cần xác minh?}
    GA --> H

    H -- Không --> K[Không cần owner chuyên môn]
    H -- Có --> L{Chạm luật?}

    L -- Có --> LO[Verification required<br/>Legal Owner xác minh]
    L -- Không --> M{Chạm kế toán hoặc thuế?}
    LO --> M

    M -- Có --> AO[Verification required<br/>Accounting Owner xác minh]
    M -- Không --> N{Chạm bảo mật hoặc dữ liệu cá nhân?}
    AO --> N

    N -- Có --> SO[Verification required<br/>Security xác minh]
    N -- Không --> P{Chạm an toàn thực phẩm?}
    SO --> P

    P -- Có --> DO[Verification required<br/>Domain owner xác minh]
    P -- Không --> Q[Hoàn tất các xác minh áp dụng]
    DO --> Q

    K --> R[Business Owner quyết định ưu tiên]
    Q --> R
    R --> S[Artifact: IN_REVIEW v0.9.0]
    S --> T[Không tạo baseline hoặc approval]

Nếu nhận định chạm luật, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân hoặc bảo mật, Senior BA ghi Verification required; không diễn giải thành nghĩa vụ Nova Foods. Nguồn luật chỉ cho bối cảnh học liệu. Legal Owner, Accounting Owner, Security hoặc domain owner phải xác minh nội dung thuộc thẩm quyền họ. /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md là artifact kiểm soát tham chiếu; trạng thái IN_REVIEW không tạo baseline hay approval.

12. Associated Template Reference & Completed Artifact

Core

Template là khuôn tệp dùng lặp lại để ghi nhận cùng loại thông tin theo cấu trúc nhất quán. Chapter As-Is Process Mapping chỉ dùng template khi cần lưu evidence, bước quy trình, vai trò, điểm đau, ngoại lệ, hệ thống, dữ liệu hoặc traceability có thể kiểm tra lại. Không tạo template riêng chỉ để chép lại nội dung chapter. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Không có template ID hoặc filename As-Is Process Mapping đã được đăng ký trong nguồn dependency được cung cấp. Vì vậy không được tự tạo ID như TMPL-ASIS-001, không suy diễn đường dẫn /03-templates/, và không gọi tệp chưa đăng ký là canonical. Nguồn kiểm soát để xác định template hợp lệ là /01-curriculum/TEMPLATE_MANIFEST.md, trạng thái IN_REVIEW, Version v0.9.0, ngày 2026-08-07.

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

flowchart TB
    A[BA cần ghi nhận As-Is] --> B[Kiểm tra /01-curriculum/TEMPLATE_MANIFEST.md<br/>IN_REVIEW · v0.9.0 · 2026-08-07]
    B --> C{Có Template ID và filename<br/>As-Is Process Mapping?}
    C -->|Hiện không có| D[Không tạo ID, filename hoặc đường dẫn mới trong chapter]
    D --> E[Không gọi template là canonical]
    E --> F[Chỉ đăng ký qua quy trình kiểm soát trong manifest]
    C -->|Có| G[Dùng đúng ID, filename, owner, quality gate]
    G --> H[Dùng template khi cần lưu evidence, quy trình, vai trò, điểm đau, ngoại lệ, hệ thống, dữ liệu hoặc traceability]
    H --> I[Artifact As-Is liên kết rule, data, traceability có thể kiểm tra lại]
    A --> J[Không tạo template chỉ để chép lại nội dung chapter]

Applied

Thành phần	Nội dung
Facts	BA ghi nhận mô phỏng: nhân viên kho nhập lại mã lô khi xuất hàng; bằng chứng là ba phiếu quan sát tổng hợp. Nguồn cung cấp không nêu template As-Is đã đăng ký.
Current Behavior	BA có thể mô tả luồng trong chapter và liên kết artifact kiểm soát, nhưng chưa có quyền đặt template ID hoặc filename mới.
Underlying Need	Cần giữ cấu trúc ghi nhận nhất quán để QA reviewer, Architect và Business Owner hiểu cùng evidence, không biến quan sát nhỏ thành quy tắc ERP.
Options	Dùng template đã đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md; ghi nhận trực tiếp trong chapter khi chưa có template; tự tạo template không đăng ký.
Decision Criteria	ID và filename phải có trong manifest; owner phải rõ; consumer phải xác định; quality gate phải kiểm tra được; không vượt thẩm quyền baseline hoặc approval.
Decision	Chỉ dùng template có đăng ký canonical. Với nguồn hiện có, ghi nhận bằng chapter và tham chiếu manifest; không tạo template ID mới.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì manifest và traceability. Business Owner xác nhận nghiệp vụ; Warehouse Manager xác nhận thao tác kho; Architect xác minh tác động hệ thống.
Artifact	/01-curriculum/TEMPLATE_MANIFEST.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Template tự đặt tên phá vỡ traceability; consumer dùng sai nguồn; mô tả mô phỏng có thể bị hiểu sai thành cấu hình ERP, rule đã duyệt hoặc baseline.

Senior Lens

Quality gate là điều kiện kiểm tra trước khi artifact được dùng làm đầu vào tiếp theo. Với As-Is mapping, gate tối thiểu kiểm tra: evidence có nguồn; bước quy trình có actor; hệ thống và dữ liệu chỉ nêu khi quan sát được; inference tách khỏi fact; assumption hoặc Verification required có nhãn; ID liên kết giữ đúng chuỗi canonical. Gate không xác nhận quy trình Nova Foods là đúng ngoài đời, không tạo compliance, không tạo approval.

Quick Reference

Template ID / file	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
Không có ID template As-Is được đăng ký trong dependency đã cung cấp	Không áp dụng cho đến khi /01-curriculum/TEMPLATE_MANIFEST.md đăng ký ID và filename	Không tự tạo ID, filename hoặc thư mục template trong chapter	Principal IT Business Analyst / Technical Curriculum Author duy trì manifest, không phê duyệt nội dung nghiệp vụ	BA, QA reviewer, Business Owner chỉ dùng sau khi manifest có mục hợp lệ	ID, filename, status và owner phải khớp manifest
/01-curriculum/TEMPLATE_MANIFEST.md	Tra cứu template hợp lệ, phạm vi, dependency và kiểm soát sử dụng	Không dùng như completed artifact hoặc bằng chứng quy trình	Principal IT Business Analyst / Technical Curriculum Author	BA author, QA reviewer, curriculum maintainer	Status phải là IN_REVIEW; không diễn giải là baseline hay approval
/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra ID rule, requirement, data, interface hoặc issue đã tồn tại	Không dùng để cấp ID mới ngoài quy trình registry	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, Architect, domain owner	Chuỗi ID phải giữ nguyên; liên kết phải truy ngược được
/01-curriculum/CANONICAL_BUSINESS_RULES.md	Liên kết quy tắc nghiệp vụ đã được catalog hóa	Không suy diễn rule từ quan sát As-Is chưa xác minh	Principal IT Business Analyst / Technical Curriculum Author; Business Owner xác nhận nội dung nghiệp vụ khi cần	BA, QA reviewer, Business Owner	Rule phải tách fact, assumption và Verification required
/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Liên kết tên dữ liệu logic như mã lô, phiếu xuất kho, trạng thái	Không dùng để xác nhận schema ERP, kiểu dữ liệu vật lý hoặc cấu hình production	Principal IT Business Analyst / Technical Curriculum Author; Architect xác minh kỹ thuật khi cần	BA, QA reviewer, Architect	Tên dữ liệu phải khớp canonical; không thêm trường chưa đăng ký

Danh mục tra cứu chương và vị trí artifact Nova Foods đã điền

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Tra cứu bắt đầu từ artifact kiểm soát, không từ bản sao hay suy luận cá nhân. Lý do: current-state map chỉ đáng tin khi ID, rule, dữ liệu và dependency trỏ về nguồn canonical.

Mục cần tra cứu	Artifact canonical	Vị trí	Dùng để kiểm gì trong chương 04	Kết quả cần thấy
Cấu trúc chapter	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Xác nhận /02-handbook/04-current-state-as-is-and-process-mapping.md thuộc corpus, đúng tên và dependency	Không đổi số chapter, slug, tên tệp
Cấu trúc học liệu	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Xác nhận As-Is Process Mapping nằm trước requirement, rule, data và testing	Không dùng process map để tự tạo requirement chưa có nguồn
Nguồn tham chiếu	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Phân loại nguồn primary, official, guidance; giữ safe-use boundary	Không gán điều khoản, nghĩa vụ pháp lý, approval không được xác minh
ID truy vết	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra ID process, actor, pain point, system, data object nếu đã đăng ký	Giữ nguyên ID; không tự đặt ID trông giống canonical
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Đối chiếu rule được nêu trong luồng hiện trạng	Rule chưa xác minh giữ nhãn giả định dự án hoặc Verification required
Dữ liệu logic	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Đối chiếu tên dữ liệu, ý nghĩa, owner và boundary	Không biến field mô phỏng thành cấu hình ERP thật
Danh mục template	TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Tìm template đã được manifest liên quan process mapping	Chỉ dùng ID và filename đã đăng ký
Chương đang hoàn thiện	Không có Artifact ID riêng được cung cấp trong nguồn seed	/02-handbook/04-current-state-as-is-and-process-mapping.md	Kiểm tra đủ 12 H2 blueprint, traceability và ranh giới mô phỏng	Không gọi nội dung APPROVED hoặc BASELINED

Luồng tra cứu tối thiểu:

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

flowchart TB
    A["/02-handbook/04-current-state-as-is-and-process-mapping.md"]

    A --> B["CHAPTER_MANIFEST"]
    A --> C["01_CURRICULUM_ARCHITECTURE"]
    A --> D["TRACEABILITY_ID_REGISTRY"]
    A --> E["CANONICAL_BUSINESS_RULES"]
    A --> F["CANONICAL_DATA_DICTIONARY"]
    A --> G["TEMPLATE_MANIFEST"]
    A --> H["00_SOURCE_MAP"]

    B --> I["Giữ tên tệp, cấu trúc chương và dependency"]
    C --> J["Giữ thứ tự As-Is Process Mapping trước requirement, quy tắc, dữ liệu và kiểm thử; không tự tạo requirement chưa có nguồn"]
    D --> K["Giữ ID truy vết"]
    E --> L["Giữ nhãn quy tắc và trạng thái xác minh"]
    F --> M["Giữ nghĩa dữ liệu logic"]
    G --> N["Chỉ dùng template ID và filename đã đăng ký"]
    H --> O["Giữ ranh giới sử dụng nguồn"]

    A --> P{"Completed current-state artifact đã được đăng ký canonical?"}
    P -->|Không| Q["Không bịa Artifact ID, filename hoặc đường dẫn canonical"]
    Q --> R["Chỉ liên kết chapter đang xây dựng"]
    P -->|Có| S["Ghi vị trí sau khi TEMPLATE_MANIFEST hoặc artifact kiểm soát đăng ký"]

Checklist tra cứu hoàn chỉnh trước khi tham chiếu artifact đã điền:

• [ ] Mở /02-handbook/04-current-state-as-is-and-process-mapping.md; xác nhận đang làm chapter 04, không thay tên hoặc đường dẫn.
• [ ] Mở /01-curriculum/CHAPTER_MANIFEST.md; xác nhận chapter và dependency vẫn ở IN_REVIEW, v0.9.0.
• [ ] Mở /01-curriculum/TRACEABILITY_ID_REGISTRY.md; đối chiếu mọi ID đã xuất hiện trong process map.
• [ ] Mở /01-curriculum/CANONICAL_BUSINESS_RULES.md; phân biệt fact quan sát, giả định dự án và nội dung cần xác minh.
• [ ] Mở /01-curriculum/CANONICAL_DATA_DICTIONARY.md; kiểm tra tên dữ liệu không bị đổi nghĩa giữa sơ đồ và bảng mô tả.
• [ ] Mở /00-research/00_SOURCE_MAP.md; kiểm tra nguồn pháp lý, kế toán, an toàn thực phẩm, privacy chỉ được dùng trong safe-use boundary.
• [ ] Mở /01-curriculum/TEMPLATE_MANIFEST.md; chỉ tra template đã đăng ký, không sao chép toàn bộ registry vào chapter.
• [ ] Ghi rõ Nova Foods là mô phỏng; không diễn giải artifact thành cấu hình, vận hành, compliance hoặc approval thực tế.

Vị trí artifact Nova Foods đã điền: chưa được đăng ký trong nguồn seed được cung cấp. Không có filename, Artifact ID hoặc đường dẫn canonical cho completed current-state artifact. Vì vậy không được bịa vị trí hoặc gọi artifact đã tồn tại. Chỉ được liên kết tới /02-handbook/04-current-state-as-is-and-process-mapping.md như chapter đang xây dựng; completed artifact chỉ được ghi vị trí sau khi TEMPLATE_MANIFEST hoặc artifact kiểm soát khác đăng ký canonical filename và ID.

Senior Lens

Rà soát liên tệp trước handoff kiểm tra cùng một sự thật xuất hiện nhất quán trong các artifact kiểm soát. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; vì vậy phát hiện nhất quán chỉ chứng minh corpus không tự mâu thuẫn, không chứng minh quy trình ERP thực, tuân thủ pháp luật hay được phê duyệt.

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

flowchart TB
    A[Soát chapter 04 As-Is] --> B[Đối chiếu chapter manifest]
    B --> C[Đối chiếu traceability ID registry]
    C --> D[Đối chiếu canonical business rules]
    D --> E[Đối chiếu canonical data dictionary]
    E --> F[Đối chiếu source map]
    F --> G[Đối chiếu curriculum architecture]

    G --> H{Nguồn canonical mâu thuẫn?}
    H -- Có --> I[Dừng handoff nội dung bị ảnh hưởng]
    I --> J[Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề]
    J --> K[Chuyển đúng owner]
    K --> L[Sửa artifact nguồn chân lý]
    L --> M[Cập nhật liên kết và giữ lịch sử thay đổi]
    M --> B

    H -- Không --> N{Có suy diễn hoặc mục cần xác minh?}
    N -- Không --> Z{Đủ điều kiện handoff?}
    N -- Có --> O[Đăng ký open issue và phân loại]

    O --> P{Loại vấn đề?}
    P -- Pháp lý --> Q[Legal Owner]
    P -- Kế toán, thuế, hóa đơn --> R[Accounting Owner]
    P -- An toàn thực phẩm, truy xuất --> S[Domain Owner]
    P -- Quy tắc As-Is hoặc To-Be --> T[Business Owner]
    P -- Tích hợp, bảo mật hoặc quyền truy cập API --> U[Technical Architect và Security Owner]
    P -- Testability --> V[QA Owner]
    P -- ID, tên tệp, version hoặc trạng thái --> W[Principal IT Business Analyst / Technical Curriculum Author]

    W --> X[Sửa registry hoặc manifest]
    X --> M

    Q --> Y{Owner đã xác nhận?}
    R --> Y
    S --> Y
    T --> Y
    U --> Y
    V --> Y

    Y -- Có --> AA[Ghi xác nhận trong artifact kiểm soát]
    AA --> AB[Đóng open issue đủ điều kiện]
    AB --> Z

    Y -- Chưa --> AC[Giữ open issue mở và chapter IN_REVIEW]
    AC --> AD[Không dùng APPROVED, BASELINED, compliant hoặc production-ready]
    AD --> Z

    Z -- Không --> AE[Chưa handoff; bổ sung open issue hoặc owner]
    AE --> Z
    Z -- Có --> AF[Handoff chapter với trạng thái IN_REVIEW]

    Z:::gate
    classDef gate fill:#fff4cc,stroke:#8a6d00,stroke-width:2px

    note1[Điều kiện: mọi open issue còn mở được liệt kê<br/>mọi Verification required có owner] -.-> Z

Điểm soát liên tệp	Artifact nguồn chân lý	Kiểm tra cụ thể	Kết quả tại v0.9.0
Định danh chapter, đường dẫn, trạng thái	/01-curriculum/CHAPTER_MANIFEST.md	04-current-state-as-is-and-process-mapping.md, IN_REVIEW, v0.9.0 phải khớp manifest	Verification required: cần đối chiếu entry chapter đầy đủ trước handoff
ID truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Không tạo ID mới, không đổi chuỗi ID canonical, không dùng ID như quyết định nghiệp vụ	Đạt phạm vi soạn: không phát sinh ID Nova Foods mới trong mục này
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Mô tả As-Is không được biến thành business rule bắt buộc nếu catalog chưa xác nhận	Open issue: mọi rule suy ra từ quan sát mô phỏng phải giữ trạng thái giả định
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên dữ liệu, chủ thể dữ liệu, dữ liệu cá nhân, tiền tệ VND không được suy diễn thành schema ERP	Verification required: Data Owner xác nhận khi có thuộc tính dữ liệu cụ thể
Nguồn và giới hạn dùng nguồn	/00-research/00_SOURCE_MAP.md	Không gọi hướng dẫn BABOK, ISO, OWASP hay luật là phê duyệt Nova Foods	Đạt phạm vi soạn: giữ ranh giới nguồn và mô phỏng
Cấu trúc học liệu	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	As-Is phải làm đầu vào cho requirement, traceability và test basis; không tự tạo requirement triển khai	Verification required: Curriculum Owner kiểm tra chuỗi học không đứt

Open issue hoặc mục cần xác minh	Bằng chứng và cầu nối suy luận	Escalation owner chính xác	Điều kiện đóng
Diễn giải nghĩa vụ pháp lý về dữ liệu cá nhân, an toàn thực phẩm, hóa đơn hoặc kế toán	Source seed nêu luật và nghị định là nguồn chính thức, nhưng cấm tự diễn giải chi tiết chưa xác minh	Legal Owner cho pháp lý; Accounting Owner cho kế toán, thuế, hóa đơn; Domain Owner cho an toàn thực phẩm và truy xuất	Có xác nhận chuyên môn được ghi trong artifact kiểm soát; không suy diễn từ handbook
Quy tắc As-Is bị trình bày như quy tắc To-Be	Quan sát hiện trạng chỉ mô tả hành vi đang giả định; không đủ thẩm quyền quyết định tương lai	Business Owner	Business Owner xác nhận phạm vi nghiệp vụ mô phỏng hoặc rule được giữ nhãn giả định
Luồng tích hợp, quyền truy cập, bảo mật API	Source seed chỉ cung cấp chuẩn tham chiếu; không xác nhận kiến trúc Nova Foods	Technical Architect và Security Owner	Có quyết định kiến trúc hoặc kiểm soát bảo mật được ghi riêng; chapter chỉ liên kết
Testability của hành vi As-Is	Mô tả quy trình cần tiêu chí quan sát được trước khi thành test basis	QA Owner	QA Owner xác nhận điều kiện kiểm thử, dữ liệu tổng hợp và kết quả mong đợi
Mâu thuẫn ID, tên tệp, version hoặc trạng thái	Registry và manifest là nguồn canonical; chapter không được tự sửa định danh	Principal IT Business Analyst / Technical Curriculum Author	Sửa tại artifact nguồn chân lý, cập nhật liên kết, giữ lịch sử thay đổi

Quy tắc handoff: chỉ chuyển chapter với nhãn IN_REVIEW, danh sách open issue còn mở, và từng mục Verification required có owner nêu trên. Không ghi APPROVED, BASELINED, compliant, production-ready hay xác nhận người dùng. Nếu nguồn canonical mâu thuẫn, dừng handoff nội dung bị ảnh hưởng; Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề và chuyển đúng owner, không tự kết luận thay họ.

Quy trình và điểm quyết định

Sơ đồ BPMN làm rõ vai trò, sự kiện và điểm quyết định được mô tả trong phần này.

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

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="Definitions_AsIsProcessMapping"
                  targetNamespace="https://example.org/nova-foods/as-is-process-mapping">

  <bpmn:collaboration id="Collaboration_AsIsProcessMapping">
    <bpmn:participant id="Participant_AsIsMapping"
                      name="Lập As-Is process map — case mô phỏng Nova Foods"
                      processRef="Process_AsIsMapping"/>
  </bpmn:collaboration>

  <bpmn:process id="Process_AsIsMapping" name="Lập As-Is process map" isExecutable="false">

    <bpmn:laneSet id="LaneSet_AsIsMapping">
      <bpmn:lane id="Lane_BA" name="BA">
        <bpmn:flowNodeRef>StartEvent_Survey</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>Task_CollectEvidence</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>Task_RecordEvidenceSource</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>Gateway_EvidenceConfirmed</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>Task_RecordUnverifiedStatus</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>Task_MapCurrentState</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>Task_RecordObservedIssues</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>EndEvent_AsIsMap</bpmn:flowNodeRef>
      </bpmn:lane>

      <bpmn:lane id="Lane_ProcessOwner" name="Người thực hiện hoặc chủ quy trình">
        <bpmn:flowNodeRef>Task_DescribeCurrentWork</bpmn:flowNodeRef>
      </bpmn:lane>
    </bpmn:laneSet>

    <bpmn:startEvent id="StartEvent_Survey" name="Khảo sát quy trình">
      <bpmn:outgoing>Flow_StartToCollect</bpmn:outgoing>
    </bpmn:startEvent>

    <bpmn:task id="Task_CollectEvidence" name="Thu thập bằng chứng">
      <bpmn:incoming>Flow_StartToCollect</bpmn:incoming>
      <bpmn:outgoing>Flow_CollectToRecordSource</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Task_RecordEvidenceSource" name="Ghi nguồn bằng chứng">
      <bpmn:incoming>Flow_CollectToRecordSource</bpmn:incoming>
      <bpmn:outgoing>Flow_RecordSourceToGateway</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="Gateway_EvidenceConfirmed"
                           name="Bằng chứng đủ để ghi là fact?"
                           gatewayDirection="Diverging">
      <bpmn:incoming>Flow_RecordSourceToGateway</bpmn:incoming>
      <bpmn:outgoing>Flow_EvidenceYesToDescribe</bpmn:outgoing>
      <bpmn:outgoing>Flow_EvidenceNoToUnverified</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="Task_DescribeCurrentWork" name="Mô tả công việc hiện tại">
      <bpmn:incoming>Flow_EvidenceYesToDescribe</bpmn:incoming>
      <bpmn:outgoing>Flow_DescribeToMap</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Task_RecordUnverifiedStatus"
               name="Ghi bước với trạng thái&#10;giả định hoặc cần xác minh">
      <bpmn:incoming>Flow_EvidenceNoToUnverified</bpmn:incoming>
      <bpmn:outgoing>Flow_UnverifiedToMap</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Task_MapCurrentState"
               name="Lập As-Is: actor, action,&#10;object, outcome và handoff">
      <bpmn:incoming>Flow_DescribeToMap</bpmn:incoming>
      <bpmn:incoming>Flow_UnverifiedToMap</bpmn:incoming>
      <bpmn:outgoing>Flow_MapToIssues</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Task_RecordObservedIssues"
               name="Ghi nhận điểm đã quan sát, nếu có:&#10;chờ, lỗi, lặp hoặc thiếu kiểm soát">
      <bpmn:incoming>Flow_MapToIssues</bpmn:incoming>
      <bpmn:outgoing>Flow_IssuesToEnd</bpmn:outgoing>
    </bpmn:task>

    <bpmn:endEvent id="EndEvent_AsIsMap" name="As-Is map có nguồn và trạng thái">
      <bpmn:incoming>Flow_IssuesToEnd</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:dataObject id="DataObject_Evidence"/>
    <bpmn:dataObjectReference id="DataObjectReference_Evidence"
                              name="Bằng chứng: quan sát, mẫu chứng từ,&#10;màn hình, log hoặc xác nhận ghi nhận"
                              dataObjectRef="DataObject_Evidence"/>

    <bpmn:dataObject id="DataObject_Unverified"/>
    <bpmn:dataObjectReference id="DataObjectReference_Unverified"
                              name="Trạng thái chưa xác minh"
                              dataObjectRef="DataObject_Unverified"/>

    <bpmn:dataObject id="DataObject_AsIsMap"/>
    <bpmn:dataObjectReference id="DataObjectReference_AsIsMap"
                              name="As-Is map"
                              dataObjectRef="DataObject_AsIsMap"/>

    <bpmn:dataObject id="DataObject_ObservedIssues"/>
    <bpmn:dataObjectReference id="DataObjectReference_ObservedIssues"
                              name="Điểm đã quan sát, nếu có"
                              dataObjectRef="DataObject_ObservedIssues"/>

    <bpmn:sequenceFlow id="Flow_StartToCollect"
                       sourceRef="StartEvent_Survey"
                       targetRef="Task_CollectEvidence"/>
    <bpmn:sequenceFlow id="Flow_CollectToRecordSource"
                       sourceRef="Task_CollectEvidence"
                       targetRef="Task_RecordEvidenceSource"/>
    <bpmn:sequenceFlow id="Flow_RecordSourceToGateway"
                       sourceRef="Task_RecordEvidenceSource"
                       targetRef="Gateway_EvidenceConfirmed"/>
    <bpmn:sequenceFlow id="Flow_EvidenceYesToDescribe"
                       name="Có"
                       sourceRef="Gateway_EvidenceConfirmed"
                       targetRef="Task_DescribeCurrentWork"/>
    <bpmn:sequenceFlow id="Flow_EvidenceNoToUnverified"
                       name="Không"
                       sourceRef="Gateway_EvidenceConfirmed"
                       targetRef="Task_RecordUnverifiedStatus"/>
    <bpmn:sequenceFlow id="Flow_DescribeToMap"
                       sourceRef="Task_DescribeCurrentWork"
                       targetRef="Task_MapCurrentState"/>
    <bpmn:sequenceFlow id="Flow_UnverifiedToMap"
                       sourceRef="Task_RecordUnverifiedStatus"
                       targetRef="Task_MapCurrentState"/>
    <bpmn:sequenceFlow id="Flow_MapToIssues"
                       sourceRef="Task_MapCurrentState"
                       targetRef="Task_RecordObservedIssues"/>
    <bpmn:sequenceFlow id="Flow_IssuesToEnd"
                       sourceRef="Task_RecordObservedIssues"
                       targetRef="EndEvent_AsIsMap"/>

    <bpmn:association id="Association_EvidenceToRecordSource"
                      sourceRef="DataObjectReference_Evidence"
                      targetRef="Task_RecordEvidenceSource"
                      associationDirection="One"/>
    <bpmn:association id="Association_UnverifiedOutput"
                      sourceRef="Task_RecordUnverifiedStatus"
                      targetRef="DataObjectReference_Unverified"
                      associationDirection="One"/>
    <bpmn:association id="Association_AsIsMapOutput"
                      sourceRef="Task_MapCurrentState"
                      targetRef="DataObjectReference_AsIsMap"
                      associationDirection="One"/>
    <bpmn:association id="Association_ObservedIssuesOutput"
                      sourceRef="Task_RecordObservedIssues"
                      targetRef="DataObjectReference_ObservedIssues"
                      associationDirection="One"/>

  </bpmn:process>

  <bpmndi:BPMNDiagram id="BPMNDiagram_AsIsProcessMapping">
    <bpmndi:BPMNPlane id="BPMNPlane_AsIsProcessMapping"
                      bpmnElement="Collaboration_AsIsProcessMapping">

      <bpmndi:BPMNShape id="Participant_AsIsMapping_di"
                         bpmnElement="Participant_AsIsMapping"
                         isHorizontal="true">
        <dc:Bounds x="30" y="30" width="1420" height="650"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Lane_BA_di"
                         bpmnElement="Lane_BA"
                         isHorizontal="true">
        <dc:Bounds x="60" y="30" width="1390" height="310"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Lane_ProcessOwner_di"
                         bpmnElement="Lane_ProcessOwner"
                         isHorizontal="true">
        <dc:Bounds x="60" y="340" width="1390" height="340"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="StartEvent_Survey_di" bpmnElement="StartEvent_Survey">
        <dc:Bounds x="100" y="155" width="36" height="36"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="65" y="198" width="105" height="20"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Task_CollectEvidence_di" bpmnElement="Task_CollectEvidence">
        <dc:Bounds x="180" y="135" width="145" height="75"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Task_RecordEvidenceSource_di" bpmnElement="Task_RecordEvidenceSource">
        <dc:Bounds x="375" y="135" width="145" height="75"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Gateway_EvidenceConfirmed_di"
                         bpmnElement="Gateway_EvidenceConfirmed"
                         isMarkerVisible="true">
        <dc:Bounds x="565" y="145" width="55" height="55"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="520" y="207" width="145" height="38"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Task_RecordUnverifiedStatus_di"
                         bpmnElement="Task_RecordUnverifiedStatus">
        <dc:Bounds x="670" y="235" width="205" height="75"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Task_DescribeCurrentWork_di"
                         bpmnElement="Task_DescribeCurrentWork">
        <dc:Bounds x="690" y="425" width="175" height="75"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Task_MapCurrentState_di"
                         bpmnElement="Task_MapCurrentState">
        <dc:Bounds x="930" y="135" width="190" height="75"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="Task_RecordObservedIssues_di"
                         bpmnElement="Task_RecordObservedIssues">
        <dc:Bounds x="1170" y="125" width="230" height="95"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="EndEvent_AsIsMap_di" bpmnElement="EndEvent_AsIsMap">
        <dc:Bounds x="1410" y="155" width="36" height="36"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="1345" y="198" width="105" height="34"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="DataObjectReference_Evidence_di"
                         bpmnElement="DataObjectReference_Evidence">
        <dc:Bounds x="365" y="565" width="170" height="65"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="DataObjectReference_Unverified_di"
                         bpmnElement="DataObjectReference_Unverified">
        <dc:Bounds x="665" y="565" width="150" height="65"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="DataObjectReference_AsIsMap_di"
                         bpmnElement="DataObjectReference_AsIsMap">
        <dc:Bounds x="940" y="565" width="110" height="65"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNShape id="DataObjectReference_ObservedIssues_di"
                         bpmnElement="DataObjectReference_ObservedIssues">
        <dc:Bounds x="1185" y="565" width="145" height="65"/>
      </bpmndi:BPMNShape>

      <bpmndi:BPMNEdge id="Flow_StartToCollect_di" bpmnElement="Flow_StartToCollect">
        <di:waypoint x="136" y="173"/>
        <di:waypoint x="180" y="173"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_CollectToRecordSource_di" bpmnElement="Flow_CollectToRecordSource">
        <di:waypoint x="325" y="173"/>
        <di:waypoint x="375" y="173"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_RecordSourceToGateway_di" bpmnElement="Flow_RecordSourceToGateway">
        <di:waypoint x="520" y="173"/>
        <di:waypoint x="565" y="173"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_EvidenceYesToDescribe_di" bpmnElement="Flow_EvidenceYesToDescribe">
        <di:waypoint x="593" y="200"/>
        <di:waypoint x="593" y="462"/>
        <di:waypoint x="690" y="462"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="600" y="315" width="25" height="20"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_EvidenceNoToUnverified_di" bpmnElement="Flow_EvidenceNoToUnverified">
        <di:waypoint x="620" y="173"/>
        <di:waypoint x="645" y="173"/>
        <di:waypoint x="645" y="272"/>
        <di:waypoint x="670" y="272"/>
        <bpmndi:BPMNLabel>
          <dc:Bounds x="628" y="218" width="40" height="20"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_DescribeToMap_di" bpmnElement="Flow_DescribeToMap">
        <di:waypoint x="865" y="462"/>
        <di:waypoint x="900" y="462"/>
        <di:waypoint x="900" y="173"/>
        <di:waypoint x="930" y="173"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_UnverifiedToMap_di" bpmnElement="Flow_UnverifiedToMap">
        <di:waypoint x="875" y="272"/>
        <di:waypoint x="900" y="272"/>
        <di:waypoint x="900" y="173"/>
        <di:waypoint x="930" y="173"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_MapToIssues_di" bpmnElement="Flow_MapToIssues">
        <di:waypoint x="1120" y="173"/>
        <di:waypoint x="1170" y="173"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Flow_IssuesToEnd_di" bpmnElement="Flow_IssuesToEnd">
        <di:waypoint x="1400" y="173"/>
        <di:waypoint x="1410" y="173"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Association_EvidenceToRecordSource_di"
                         bpmnElement="Association_EvidenceToRecordSource">
        <di:waypoint x="450" y="565"/>
        <di:waypoint x="450" y="210"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Association_UnverifiedOutput_di"
                         bpmnElement="Association_UnverifiedOutput">
        <di:waypoint x="772" y="310"/>
        <di:waypoint x="740" y="565"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Association_AsIsMapOutput_di"
                         bpmnElement="Association_AsIsMapOutput">
        <di:waypoint x="1025" y="210"/>
        <di:waypoint x="995" y="565"/>
      </bpmndi:BPMNEdge>

      <bpmndi:BPMNEdge id="Association_ObservedIssuesOutput_di"
                         bpmnElement="Association_ObservedIssuesOutput">
        <di:waypoint x="1285" y="220"/>
        <di:waypoint x="1257" y="565"/>
      </bpmndi:BPMNEdge>

    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>

</bpmn:definitions>

Đọc từ sự kiện bắt đầu qua từng swimlane; gateway tách các kết quả theo điều kiện đã nêu trong nội dung.