15 Reporting Biometrics And Kpi Definition

Trường kiểm soát	Giá trị
Tên tệp được kiểm soát	/02-handbook/15-reporting-biometrics-and-kpi-definition.md
Tiêu đề tài liệu	15 Reporting Biometrics And Kpi Definition
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN; Việt Nam; tiền tệ mô phỏng VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ dữ liệu tổng hợp
Phân loại nguồn	Handbook học liệu có kiểm soát; không thay thế nguồn pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc thẩm quyền production
Baseline	Chưa có baseline reference tại v0.9.0
Approval	Chưa có approval reference; IN_REVIEW không là phê duyệt
Owner	Principal IT Business Analyst / Technical Curriculum Author
Giới hạn Owner	Duy trì nội dung, traceability, version; không xác nhận KPI vận hành, không quyết định cấu hình ERP, không cấp quyền production

1. Concept l? g??

Core

Reporting biometrics and KPI definition là việc định nghĩa thống nhất số đo dùng trong báo cáo và chỉ số dùng để theo dõi mức đạt mục tiêu. Từ “biometric” trong chương này không nghĩa dữ liệu sinh trắc học như vân tay. Nó nghĩa đại lượng đo được của hoạt động: số đơn giao, số đơn giao đúng hạn, giá trị hóa đơn, số lô bị giữ chất lượng.

KPI là viết tắt của Key Performance Indicator, nghĩa là chỉ số hiệu suất then chốt. Một số đo chỉ thành KPI khi nó phục vụ mục tiêu quản trị cụ thể, có người chịu trách nhiệm xem xét, có ngưỡng hoặc mục tiêu, và dẫn tới hành động. Ví dụ, “số đơn giao trong ngày” là số đo. “Tỷ lệ giao đúng hạn tối thiểu 95%” là KPI vì nó đo mức đạt mục tiêu dịch vụ giao hàng.

Khái niệm bắt đầu từ câu hỏi: “Người quản lý cần biết điều gì để quyết định?” Không bắt đầu từ câu hỏi: “ERP có trường dữ liệu nào?” Lý do: một trường dữ liệu chỉ là dữ liệu thô; quyết định cần ý nghĩa đã được định nghĩa. Nếu hai báo cáo cùng ghi “doanh thu” nhưng một báo cáo tính hóa đơn đã phát hành còn báo cáo kia tính đơn hàng đã xác nhận, hai con số có thể khác dù hệ thống không lỗi. Định nghĩa KPI phải chặn loại mơ hồ này trước khi xây dashboard.

Mỗi chỉ số phải nêu rõ bốn thành phần. Actor là tác nhân tạo, kiểm tra hoặc dùng dữ liệu, như Nhân viên Điều phối giao hàng hoặc Trưởng phòng Kinh doanh. Action là hành động nghiệp vụ tạo thay đổi, như xác nhận giao hàng. Object là đối tượng bị tác động hoặc được đo, như đơn bán hàng, dòng đơn hàng, chuyến giao, hóa đơn. Outcome là kết quả cần quan sát, như tỷ lệ giao đúng hạn hoặc giá trị doanh thu tháng. Bốn thành phần nối dữ liệu với nghiệp vụ: ai làm gì với đối tượng nào để tạo kết quả nào.

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

flowchart TB
    A[Actor: Điều phối giao hàng] --> B[Action: xác nhận giao]
    B --> C[Object: đơn bán hàng]
    C --> D[Phạm vi: đơn đã giao trong kỳ báo cáo]
    D --> E[So sánh: ngày giao thực tế không muộn hơn ngày giao cam kết]
    E --> F[Tử số: đơn giao đúng hạn]
    D --> G[Mẫu số: tổng đơn đã giao]
    F --> H[KPI / Outcome: tỷ lệ giao đúng hạn]
    G --> H

Ví dụ tối thiểu, Nova Foods là case study mô phỏng. Trong ngày 2026-08-07, có 100 đơn bán hàng tổng hợp có ngày giao cam kết và 94 đơn được xác nhận giao không muộn hơn ngày cam kết. BA định nghĩa KPI On-Time Delivery Rate là “số đơn giao đúng hạn chia tổng số đơn đã giao trong kỳ báo cáo, nhân 100%”. Kết quả là 94%. Bằng chứng cho mẫu số là 100 đơn đã giao; bằng chứng cho tử số là 94 đơn thỏa điều kiện ngày giao thực tế không muộn hơn ngày cam kết. Không được thay mẫu số bằng mọi đơn đã tạo, vì câu hỏi KPI đang đo chất lượng giao của đơn đã hoàn tất giao.

Ranh giới chương này: tập trung định nghĩa nghiệp vụ của số đo, KPI, công thức, đối tượng đo, kỳ báo cáo và ý nghĩa quyết định. Chương này không xác nhận mục tiêu 95% là mục tiêu thật của Nova Foods, không thiết kế dashboard, không chọn công cụ BI, không cấu hình ERP, không xác nhận dữ liệu production, không diễn giải nghĩa vụ pháp lý hay kế toán. Mọi tên, số liệu và tình huống Nova Foods trong tài liệu là tổng hợp phục vụ học tập.

Core

Reporting là hoạt động tạo, trình bày và phân phối báo cáo từ dữ liệu để người có trách nhiệm hiểu tình hình và quyết định. Biometrics trong chapter này là chỉ số đo sức khỏe vận hành của quy trình hoặc hệ thống, không phải dữ liệu sinh trắc học cá nhân như vân tay hay khuôn mặt. KPI (Key Performance Indicator, chỉ số hiệu suất trọng yếu) là chỉ số được chọn để theo dõi mức đạt mục tiêu cụ thể; không phải mọi số trên báo cáo đều là KPI.

Thuật ngữ	Nghĩa ngắn	Vai trò trong định nghĩa KPI
Actor	Người, vai trò, hệ thống thực hiện hoặc dùng kết quả.	Xác định ai chịu trách nhiệm xem, hành động, hoặc sở hữu chỉ số.
Action	Hành động có thể quan sát, như ghi nhận đơn hàng, xuất kho, phê duyệt.	Xác định sự kiện tạo dữ liệu đo lường.
Object	Đối tượng bị tác động, như đơn hàng, lô hàng, phiếu xuất kho.	Xác định phạm vi dữ liệu của chỉ số.
Outcome	Kết quả cần đạt hoặc cần theo dõi, như giao hàng đúng hẹn.	Xác định ý nghĩa nghiệp vụ của KPI.
Metric	Chỉ số đo lường bất kỳ.	Có thể là dữ liệu đầu vào, chỉ số tham khảo, hoặc KPI.
Measure	Giá trị đo có quy tắc tính rõ, như số đơn giao đúng hẹn.	Thành phần tử số, mẫu số, tổng, trung bình hoặc tỷ lệ.
Target	Mục tiêu cần đạt của KPI.	Dùng đánh giá kết quả; không thay đổi công thức KPI.
Threshold	Ngưỡng cảnh báo hoặc phân loại.	Cho biết khi nào cần chú ý hay hành động.
Dimension	Thuộc tính dùng phân tích, như tháng, kho, vùng bán hàng.	Cho phép cắt KPI theo ngữ cảnh mà không đổi định nghĩa gốc.
Data source	Nguồn dữ liệu tạo chỉ số.	Phải xác định để kiểm tra nguồn gốc và tính nhất quán.

Ví dụ Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dùng dữ liệu tổng hợp: actor là Điều phối viên giao hàng; action là xác nhận giao đơn; object là đơn bán hàng; outcome là đơn được giao đúng hoặc trước ngày cam kết. Từ đó, metric “tỷ lệ giao đúng hẹn” có thể tính bằng số đơn giao đúng hẹn chia tổng đơn đã giao trong kỳ, nhân 100%. Chỉ khi Business Owner xác định giao đúng hẹn là kết quả trọng yếu và đặt mục tiêu, metric này mới là KPI.

Quy tắc đọc từ gốc: actor làm action lên object để tạo outcome; báo cáo đo bằng chứng của chuỗi đó. Nếu không nêu được bốn phần này, tên KPI như “Hiệu quả giao hàng” còn mơ hồ, vì chưa rõ ai, việc gì, đối tượng nào, kết quả nào. Dữ liệu mô phỏng không chứng minh cấu hình ERP, mục tiêu vận hành, hoặc phê duyệt thực tế của Nova Foods.

Core

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. Báo cáo KPI-OTIF-DAILY ghi tỷ lệ giao đơn đúng hạn và đủ số lượng mỗi ngày. Actor là vai trò thực hiện hoặc dùng kết quả: Điều phối giao nhận. Action là hành động đo lường: hệ thống đếm đơn giao đạt điều kiện. Object là đối tượng bị đo: đơn giao hàng. Outcome là kết quả phục vụ quyết định: tỷ lệ OTIF để nhận biết ngày giao nhận lệch mục tiêu.

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

flowchart TB
    A[Đơn giao hàng] --> B[Đánh giá đúng hạn và đủ số lượng]
    B --> C{Đúng hạn AND đủ số lượng?}
    C -->|Có| D[Đơn đạt OTIF]
    C -->|Không| E[Đơn không đạt OTIF]
    D --> F[Đếm đơn đạt OTIF theo ngày]
    D --> G[Tổng đơn giao hàng theo ngày]
    E --> G
    F --> H[Tính tỷ lệ OTIF theo ngày]
    G --> H
    H --> I[KPI-OTIF-DAILY]
    I --> J[So sánh với mục tiêu]
    J --> K[Điều phối giao nhận]
    K --> L[Nhận biết ngày giao nhận lệch mục tiêu]

Applied

Mục	Nội dung mô phỏng
Facts	Ngày 2026-08-07, có 20 đơn giao tổng hợp; 17 đơn vừa giao không muộn hơn thời điểm cam kết, vừa giao đủ số lượng xác nhận.
Current Behavior	Điều phối giao nhận xem từng đơn và tự đếm số đơn đạt. Cùng dữ liệu có thể tạo ra số đếm khác nếu mỗi người hiểu “đúng hạn” khác nhau.
Underlying Need	Cần một định nghĩa KPI dùng chung để hệ thống và người đọc cùng trả lời một câu hỏi: bao nhiêu phần trăm đơn giao đạt cả hai điều kiện dịch vụ.
Options	(1) Chỉ đo đúng hạn. (2) Chỉ đo đủ số lượng. (3) Đo OTIF: một đơn chỉ đạt khi đồng thời đúng hạn và đủ số lượng.
Decision Criteria	Khớp mục tiêu dịch vụ giao hàng; có dữ liệu thời điểm cam kết, thời điểm giao, số lượng xác nhận; kết quả giải thích được tới từng đơn.
Decision	Dùng OTIF. Công thức: OTIF % = số đơn đạt cả đúng hạn và đủ số lượng / tổng đơn có thể đo × 100. Kết quả ví dụ: 17 / 20 × 100 = 85%.
Authority	Business Owner quyết định mục tiêu dịch vụ và ngưỡng KPI. BA ghi định nghĩa, dữ liệu đầu vào, công thức, giả định và điểm cần xác minh; không tự phê duyệt.
Artifact	Bản ghi định nghĩa KPI trong /02-handbook/15-reporting-biometrics-and-kpi-definition.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND.
Consequence if Wrong	Nếu mẫu số gồm đơn bị hủy hoặc đơn chưa có cam kết giao, KPI có thể tăng hoặc giảm sai. Quản lý có thể ưu tiên sai nguyên nhân: vận tải, kho, bán hàng hoặc dữ liệu đơn hàng.

Senior Lens

Ranh giới khái niệm: định nghĩa KPI trả lời đo cái gì, bằng dữ liệu nào, theo công thức nào, ai dùng kết quả nào. KPI không tự sửa nguyên nhân giao trễ, không tự đặt chỉ tiêu, không chứng minh hiệu suất nhân sự, và không thay thế báo cáo chi tiết từng đơn. Lý do: chỉ số là phép tóm tắt; một tỷ lệ 85% cho biết mức kết quả, nhưng không tự chứng minh 3 đơn còn lại trễ do tồn kho, tuyến xe, nhập liệu hay khách đổi lịch.

Loại trừ rõ: ví dụ này không tạo business rule vận hành cho Nova Foods, không là cấu hình ERP, không là cam kết SLA, không là diễn giải kế toán, thuế, pháp lý, an toàn thực phẩm hay bảo vệ dữ liệu cá nhân. “Đúng hạn”, “đủ số lượng”, tập đơn đủ điều kiện đo và ngưỡng mục tiêu là giả định học liệu; cần Business Owner và các owner chuyên môn xác minh trước bất kỳ sử dụng thực tế nào.

Quick Reference

Thành phần	Giá trị ví dụ
KPI	On Time In Full (OTIF) — đúng hạn và đủ số lượng
Đơn vị đo	Phần trăm đơn giao đủ điều kiện đo
Tử số	Đơn đạt đồng thời đúng hạn và đủ số lượng
Mẫu số	Toàn bộ đơn giao có dữ liệu cần để đo
Kết quả tổng hợp	85%
Phạm vi	Báo cáo hiệu quả giao hàng mô phỏng
Ngoài phạm vi	Chẩn đoán nguyên nhân, đặt mục tiêu, phê duyệt, cấu hình production

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

Core

Reporting biometrics và KPI definition tồn tại để biến câu hỏi quản trị thành phép đo có thể lặp lại. Reporting biometrics là tập chỉ dấu đo sức khỏe vận hành. Key Performance Indicator (KPI) là chỉ số hiệu suất trọng yếu dùng theo dõi kết quả ưu tiên. Nếu không định nghĩa trước, cùng nhãn “giao đúng hạn”, “doanh thu”, hoặc “tồn kho chậm luân chuyển” có thể được mỗi người tính khác nhau.

Rủi ro dự án bắt đầu từ mơ hồ dữ liệu. BA có thể viết yêu cầu “hiển thị OTIF theo tháng”, đội dữ liệu lấy ngày tạo đơn, đội kho lấy ngày xuất kho, đội vận tải lấy ngày giao thực tế. Ba báo cáo cùng tên cho ba kết quả khác nhau. Không có lỗi kỹ thuật rõ ràng; lỗi nằm ở việc thiếu nguồn dữ liệu, điều kiện đủ, công thức, thời điểm chốt và người chịu trách nhiệm định nghĩa.

Rủi ro làm lại xuất hiện sau khi dashboard đã xây. Nếu công thức chưa được chốt ở mức nghiệp vụ, thay đổi một khái niệm như “đơn hợp lệ” buộc sửa truy vấn, mô hình dữ liệu, bộ lọc, kiểm thử, tài liệu hướng dẫn và báo cáo đã phát hành. Chi phí không chỉ là sửa màn hình. Hệ quả gồm đối soát lại kết quả cũ, giải thích chênh lệch và mất niềm tin vào báo cáo.

Rủi ro governance là dùng KPI làm căn cứ quyết định khi không truy ngược được. Quản lý cần biết chỉ số lấy từ artifact nào, dữ liệu nguồn nào, phiên bản định nghĩa nào và ai có thẩm quyền quyết định thay đổi. Không có chuỗi này, một chỉnh sửa công thức có thể bị xem như lỗi dữ liệu hoặc thay đổi ngầm mục tiêu. IN_REVIEW của corpus Nova Foods không phải phê duyệt định nghĩa KPI.

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

flowchart TB
    Q[Câu hỏi quản trị] --> H[Artifact định nghĩa KPI<br/>phạm vi • điều kiện đủ • công thức • thời điểm chốt<br/>dữ liệu nguồn • người chịu trách nhiệm định nghĩa]
    H --> D{Định nghĩa phản ánh đúng<br/>câu hỏi quản trị?}
    D -->|Không| H
    D -->|Có| K[Phê duyệt định nghĩa KPI]
    A[Owner có thẩm quyền phê duyệt<br/>và quyết định thay đổi] --> K
    K --> X[Phiên bản định nghĩa KPI]
    X --> S[Dữ liệu nguồn]
    S --> C[Tính toán]
    C --> V{Kết quả đúng theo định nghĩa<br/>đã phê duyệt?}
    V -->|Đạt| P[Báo cáo quản trị]
    V -->|Sai dữ liệu nguồn| S
    V -->|Sai tính toán| C

    G[Quy trình hoặc kích hoạt thay đổi<br/>định nghĩa và phiên bản] --> H
    A --> G

    P -. truy ngược .-> H
    P -. truy ngược .-> S
    P -. truy ngược .-> X

    N[IN_REVIEW không phải phê duyệt<br/>định nghĩa KPI] -. chú thích .-> K

Sơ đồ cho thấy lý do phải định nghĩa trước: báo cáo là đầu cuối. Khi câu hỏi, quy tắc và dữ liệu nguồn chưa rõ, kiểm thử chỉ xác nhận hệ thống tính đúng một công thức chưa được làm rõ; không xác nhận kết quả có đúng ý nghĩa nghiệp vụ.

Applied

Trường	Nội dung áp dụng cho Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Facts	Corpus dùng trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không có baseline reference hoặc approval reference được ghi nhận.
Current Behavior	Các vai trò có thể dùng cùng tên KPI nhưng tự chọn cột ngày, phạm vi đơn hàng hoặc cách xử lý bản ghi thiếu dữ liệu.
Underlying Need	Một định nghĩa kiểm soát được để mọi báo cáo cùng KPI dùng cùng ý nghĩa, cùng logic và cùng đường truy vết.
Options	1. Để từng báo cáo tự định nghĩa. 2. Ghi định nghĩa KPI trong từng dashboard. 3. Duy trì định nghĩa KPI như artifact dùng chung, tham chiếu từ báo cáo.
Decision Criteria	Giảm mơ hồ; truy vết được nguồn và thay đổi; kiểm thử được; không tạo phê duyệt ngầm; không biến giả định học liệu thành quy tắc vận hành.
Decision	Chọn phương án 3 cho nội dung học liệu: định nghĩa dùng chung phải nêu mục đích đo, phạm vi, nguồn dữ liệu, công thức, xử lý ngoại lệ, tần suất và owner đề xuất.
Authority	Business Owner quyết định ý nghĩa nghiệp vụ và mức sử dụng; Data Owner xác nhận dữ liệu nguồn; QA xác nhận khả năng kiểm thử; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability và governance.
Artifact	/02-handbook/15-reporting-biometrics-and-kpi-definition.md là handbook hướng dẫn. Canonical ID, quy tắc hoặc định nghĩa được kiểm soát phải chỉ tồn tại khi registry hoặc catalog canonical đã đăng ký.
Consequence if Wrong	Dashboard có thể đúng về kỹ thuật nhưng sai về ý nghĩa. Nhóm dự án phải làm lại báo cáo, test case, mapping dữ liệu và giải thích khác biệt kết quả; quyết định quản trị có thể dựa trên chỉ số không nhất quán.

Senior Lens

Không gọi mọi số trên dashboard là KPI. Một con số chỉ thành KPI khi có mục tiêu quản trị, cách tính ổn định, phạm vi rõ và khả năng kiểm chứng. Lý do: số không có ngữ cảnh chỉ là dữ liệu tổng hợp; dùng nó để đánh giá hiệu quả tạo tranh cãi thay vì tạo quyết định.

Không dùng dashboard làm nguồn chân lý cho định nghĩa. Dashboard là nơi trình bày; nó có thể đổi bộ lọc, cách hiển thị hoặc cách làm tròn. Định nghĩa phải đứng ngoài màn hình để BA, Data, QA và Business Owner cùng kiểm tra một nội dung. Khi thay đổi, giữ lịch sử phiên bản và đánh giá tác động trước khi thay công thức.

Nova Foods là case mô phỏng giáo dục. Mọi ví dụ KPI, dữ liệu, ngưỡng, quy tắc tính và trách nhiệm vai trò trong handbook là dữ liệu tổng hợp. Chúng không xác nhận cấu hình ERP thực tế, không là cam kết SLA, không là quy định kế toán, pháp lý hoặc vận hành production.

Quick Reference

Rủi ro cần chặn	Cơ chế của KPI definition
Cùng tên, khác cách tính	Ghi công thức, phạm vi, điều kiện và dữ liệu nguồn
Làm lại sau khi build	Chốt logic có thể kiểm thử trước khi tạo báo cáo
Không giải thích được chênh lệch	Lưu traceability từ câu hỏi quản trị đến phép tính
Thay đổi ngầm	Quản trị version, owner và tác động thay đổi
Dùng số liệu sai để quyết định	Phân biệt dữ liệu hiển thị với chỉ số có định nghĩa kiểm soát

Core

KPI (Key Performance Indicator, chỉ số đo mức đạt mục tiêu) tồn tại để biến câu hỏi quản trị thành định nghĩa đo được, truy vết được và kiểm tra lại được. Biometrics báo tín hiệu vận hành như thời gian, số lượng, tỷ lệ; KPI gắn tín hiệu đó với mục tiêu và quy tắc tính. Không có định nghĩa chung, cùng nhãn “giao hàng đúng hạn” có thể dùng ngày đơn hàng, ngày cam kết, ngày xuất kho hoặc ngày giao thực tế. Báo cáo vẫn chạy, nhưng kết quả không cùng nghĩa.

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

flowchart LR
    A[Dữ liệu đơn hàng mô phỏng] --> B{Định nghĩa KPI thống nhất?}
    B -- Không --> C[Mỗi nhóm tự chọn trường ngày]
    C --> D[Báo cáo cùng tên, kết quả khác nghĩa]
    B -- Có --> E[Quy tắc tính và nguồn dữ liệu xác định]
    E --> F[Báo cáo so sánh được]

Applied

Mục	Trước khi định nghĩa KPI	Sau khi định nghĩa KPI
Facts	Nova Foods là case mô phỏng giáo dục; dữ liệu tổng hợp. Báo cáo “Tỷ lệ giao hàng đúng hạn” xuất hiện trong trao đổi vận hành.	Cùng case mô phỏng, cùng nhãn báo cáo; không khẳng định cấu hình ERP thực tế.
Current Behavior	Kho đối chiếu ngày xuất kho với ngày cam kết. Kinh doanh đối chiếu ngày giao hàng với ngày khách yêu cầu.	Một báo cáo ghi rõ trường ngày dùng, mẫu số, điều kiện loại trừ và thời điểm chốt dữ liệu.
Underlying Need	Hai nhóm cần trả lời cùng câu hỏi quản trị: đơn hàng có đến đúng cam kết không. Hai cách đo tạo hai câu trả lời khác nhau.	Cần một nghĩa đo chung trước khi dùng kết quả để ưu tiên xử lý vận hành.
Options	Dùng ngày xuất kho; dùng ngày giao thực tế; tách thành hai chỉ số riêng.	So sánh từng phương án với mục tiêu quản trị và khả năng lấy dữ liệu.
Decision Criteria	Chỉ số phải phản ánh kết quả khách nhận được, xác định được nguồn dữ liệu, và cho phép kiểm tra từng đơn hàng.	Tiêu chí giữ nguyên; BA ghi bằng chứng cho từng lựa chọn.
Decision	Chưa có quyết định được phê duyệt. Ví dụ học liệu chỉ minh họa: nếu mục tiêu là trải nghiệm nhận hàng, ngày giao thực tế phù hợp hơn ngày xuất kho vì hàng rời kho chưa chứng minh khách đã nhận.	Quyết định chỉ có hiệu lực khi Business Owner có thẩm quyền ghi nhận trong artifact kiểm soát.
Authority	Business Owner quyết định nghĩa KPI; Data Owner xác nhận trường dữ liệu; BA duy trì truy vết.	Không suy diễn approval từ tài liệu IN_REVIEW v0.9.0.
Artifact	/02-handbook/15-reporting-biometrics-and-kpi-definition.md ghi contrast học liệu.	Định nghĩa chính thức, nếu được tạo, phải liên kết CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES.
Consequence if Wrong	Kho có thể báo “đúng hạn” vì đã xuất kho đúng ngày, trong khi Kinh doanh báo “trễ” vì khách nhận sau ngày cam kết. Cuộc họp chuyển sang tranh cãi số thay vì tìm nguyên nhân giao trễ.	Quy tắc sai vẫn tạo báo cáo nhất quán, nhưng nhất quán sai; quyết định ưu tiên vận hành có thể dựa trên tín hiệu không phản ánh mục tiêu.

Senior Lens

Contrast trước/sau phải quan sát được tại artifact, không cần số liệu bịa đặt. Dấu hiệu “trước” là cùng tên KPI nhưng khác trường dữ liệu hoặc khác điều kiện tính. Dấu hiệu “sau” là người đọc lần được từ tên KPI đến nguồn dữ liệu, quy tắc tính và bản ghi kiểm tra. Đây là giảm mơ hồ quản trị, không phải cam kết KPI sẽ tốt hơn.

Quick Reference

Câu hỏi kiểm tra	Trước	Sau
“Đúng hạn” dựa vào ngày nào?	Mỗi nhóm tự hiểu.	Artifact nêu một trường ngày hoặc tách KPI.
Có kiểm tra một đơn hàng cụ thể được không?	Không chắc vì thiếu quy tắc chung.	Có, bằng nguồn dữ liệu và điều kiện tính đã ghi.
Báo cáo dùng để quyết định được không?	Rủi ro tranh cãi nghĩa số.	Có thể xem xét, trong phạm vi thẩm quyền và trạng thái IN_REVIEW.

Core

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, mỗi phát biểu về chỉ số báo cáo phải mang đúng loại bằng chứng. Phân loại sai biến ý kiến thành yêu cầu, biến giả định thành sự thật, hoặc biến quyết định chưa có thẩm quyền thành cấu hình ERP. Hậu quả: KPI có thể tính đúng công thức nhưng trả lời sai câu hỏi quản trị.

Loại	Định nghĩa từ nguyên tắc đầu tiên	Bằng chứng tối thiểu	Cách ghi artifact
Verified fact — sự kiện đã xác minh	Điều đã được chứng minh bởi nguồn kiểm soát, có thể kiểm tra lại	URL nguồn chính thức, artifact canonical, bản ghi hệ thống mô phỏng có nguồn gốc rõ	Nêu nguồn, ngày truy cập 2026-08-07, trạng thái nguồn
Stakeholder input — đầu vào bên liên quan	Điều một vai trò cung cấp; giá trị vì phản ánh nhu cầu hoặc vận hành, chưa tự thành sự thật	Tên vai trò, ngữ cảnh, ngày ghi nhận	Ghi nguyên ý nghĩa, không nâng thành business rule
Project assumption — giả định dự án	Điều tạm coi đúng để tiếp tục phân tích khi chưa có bằng chứng đủ	Lý do cần giả định, rủi ro nếu sai, owner xác minh	Gắn Project assumption; nêu điều kiện hết hiệu lực
Decision — quyết định	Lựa chọn giữa các phương án theo tiêu chí và thẩm quyền xác định	Phương án, tiêu chí, authority, trạng thái ghi nhận	Không ghi “đã phê duyệt” nếu artifact chưa có approval reference
Verification-required claim — nhận định cần xác minh	Phát biểu có thể ảnh hưởng pháp lý, kế toán, bảo mật, vận hành hoặc KPI nhưng chưa đủ bằng chứng/thẩm quyền	Câu hỏi xác minh, nguồn hoặc owner cần kiểm tra	Gắn Verification required; không dùng làm logic bắt buộc

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

flowchart TB
    A[Phát biểu về KPI] --> B[Đánh giá từng loại độc lập<br/>Một phát biểu có thể mang nhiều loại]

    B --> C{Có nguồn kiểm soát<br/>có thể kiểm tra lại?}
    C -->|Có| D[Verified fact<br/>Nêu nguồn, ngày truy cập, trạng thái nguồn]
    C -->|Không| E{Do stakeholder cung cấp?}
    D --> E

    E -->|Có| F[Stakeholder input<br/>Vai trò, ngữ cảnh, ngày ghi nhận<br/>Không tự thành business rule]
    E -->|Không| G{Cần tạm coi đúng<br/>để tiếp tục phân tích?}
    F --> G

    G -->|Có| H[Project assumption<br/>Lý do, rủi ro nếu sai, owner xác minh<br/>Điều kiện hết hiệu lực]
    G -->|Không| I{Authority đã chọn phương án<br/>theo tiêu chí và có trạng thái ghi nhận?}
    H --> I

    I -->|Có| J[Decision<br/>Phương án, tiêu chí, authority, trạng thái<br/>Chỉ ghi đã phê duyệt khi có approval reference]
    I -->|Không| K{Thiếu bằng chứng hoặc thẩm quyền<br/>có thể ảnh hưởng pháp lý, kế toán,<br/>bảo mật, vận hành hoặc KPI?}
    J --> K

    K -->|Có| L[Verification required<br/>Câu hỏi xác minh và nguồn hoặc owner cần kiểm tra<br/>Không dùng làm logic bắt buộc]
    K -->|Không| M[Không gắn Verification required<br/>theo thông tin hiện có]

Applied

Facts: /01-curriculum/CHAPTER_MANIFEST.md, status IN_REVIEW, version v0.9.0, ghi Nova Foods là case study mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp. Đây là verified fact vì artifact kiểm soát nêu trực tiếp metadata đó.

Current Behavior: Finance Manager mô phỏng nêu: “Cần dashboard biên lợi nhuận theo tháng và nhà máy.” Đây là stakeholder input, không phải verified fact về công thức biên lợi nhuận, lịch chốt sổ hay quyền xem dữ liệu.

Underlying Need: Người quản lý cần so sánh kết quả lợi nhuận theo kỳ và đơn vị tổ chức để ra quyết định. Suy luận này dựa trên mục đích “theo tháng và nhà máy”; chưa suy ra được doanh thu, giá vốn, chiết khấu hay bút toán điều chỉnh nào thuộc công thức.

Options:

Phương án	Nội dung
O1	Hiển thị Gross Margin = Net Revenue - Cost of Goods Sold
O2	Hiển thị tỷ lệ Gross Margin % = Gross Margin / Net Revenue
O3	Hiển thị cả giá trị VND và tỷ lệ phần trăm

Decision Criteria: Khả năng trả lời nhu cầu so sánh; định nghĩa dữ liệu có thể truy vết; mẫu số khác 0; Accounting Owner xác nhận ý nghĩa kế toán; Business Owner xác nhận mục tiêu quản trị.

Decision: Chưa có decision được ghi nhận. O3 chỉ là phương án đề xuất phân tích, không phải yêu cầu đã phê duyệt.

Authority: Accounting Owner xác minh định nghĩa doanh thu thuần, giá vốn và kỳ ghi nhận; Business Owner chọn KPI phục vụ quản trị; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.

Artifact: Ghi từng phát biểu trong /02-handbook/15-reporting-biometrics-and-kpi-definition.md; liên kết định danh artifact canonical CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi các artifact này có nội dung kiểm soát phù hợp. Không tự tạo business rule từ input.

Consequence if Wrong: Nếu gọi O3 là verified fact, đội ERP có thể cấu hình dashboard trước khi Accounting Owner xác minh mẫu số và kỳ ghi nhận. Báo cáo vẫn hiện số VND nhưng không còn bằng chứng rằng số đó là “biên lợi nhuận” theo cách tổ chức cần.

Senior Lens

Dùng câu kiểm tra: “Người khác có thể mở đúng nguồn, tại đúng thời điểm, và kết luận lại như vậy không?” Nếu có, đó có thể là verified fact. Nếu câu trả lời phụ thuộc vào lời kể, đó là stakeholder input. Nếu cần tạm chọn để thiết kế tiếp, đó là project assumption. Nếu cần authority chọn giữa phương án, đó là decision. Nếu tác động pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật chưa được owner chuyên môn xác minh, đó là Verification required.

Không dùng Luật Kế toán, Luật Bảo vệ dữ liệu cá nhân, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm hoặc các nguồn chính thức khác để tự suy ra nghĩa vụ cấu hình Nova Foods. Nguồn xác nhận bối cảnh pháp lý; yêu cầu hệ thống dẫn xuất vẫn cần Legal Owner, Accounting Owner hoặc domain owner xác minh.

Quick Reference

Câu viết	Nhãn đúng
“IN_REVIEW không đồng nghĩa BASELINED.”	Verified fact, nguồn /01-curriculum/CHAPTER_MANIFEST.md
“Finance Manager mô phỏng muốn xem KPI theo nhà máy.”	Stakeholder input
“Tạm giả sử mọi nhà máy dùng cùng lịch tháng.”	Project assumption
“Business Owner chọn O3 sau khi có record quyết định.”	Decision
“Công thức doanh thu thuần phải được Accounting Owner xác minh.”	Verification required

3. V? tr? trong Lifecycle

Core

Reporting biometrics là chỉ số đo sức khỏe vận hành; KPI (Key Performance Indicator) là chỉ số hiệu suất then chốt phục vụ quyết định. Hai loại này không xuất hiện khi dashboard đã xong. Chúng đi xuyên suốt Lifecycle vì mỗi pha giảm một loại rủi ro: Discovery giảm rủi ro đo sai vấn đề; Analysis giảm rủi ro hiểu sai công thức; Delivery giảm rủi ro xây sai thiết kế; Testing giảm rủi ro số liệu sai; Release giảm rủi ro đưa báo cáo chưa kiểm soát vào dùng; Operations phát hiện thay đổi dữ liệu hoặc hành vi làm KPI mất tin cậy.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Mọi artifact hiện ở IN_REVIEW, version v0.9.0, ngày 2026-08-07; không phải baseline hay approval.

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

flowchart TB
    D["Discovery<br/>Entry: vấn đề hoặc quyết định nghiệp vụ được ghi nhận"] --> DG{"Exit: có problem statement,<br/>người dùng, quyết định cần hỗ trợ<br/>và giả thuyết chỉ số?"}
    DG -->|Chưa đạt: làm rõ vấn đề và quyết định| D
    DG -->|Đạt| A["Analysis<br/>Entry: có mục tiêu đo<br/>và nguồn dữ liệu ứng viên"]

    A --> AG{"Exit: KPI definition đủ truy vết;<br/>điểm chưa xác minh có nhãn<br/>Verification required hoặc project assumption?"}
    AG -->|Chưa đạt: hoàn thiện định nghĩa hoặc xác minh| A
    AG -->|Đạt: đặc tả đủ build, không mơ hồ| DE["Delivery<br/>Xây báo cáo hoặc dashboard"]

    DE --> DEG{"Exit: bản build đúng đặc tả;<br/>thay đổi kỹ thuật cập nhật traceability?"}
    DEG -->|Chưa đạt: sửa build hoặc traceability| DE
    DEG -->|Đạt: có build và test basis gồm KPI definition,<br/>dữ liệu test tổng hợp, expected result| T["Testing<br/>Đối chiếu số và hành vi"]

    T --> TG{"Exit: pass/fail được ghi nhận;<br/>lỗi chặn release đã xử lý hoặc authority<br/>quyết định xử lý theo kiểm soát?"}
    TG -->|Chưa đạt: sửa lỗi hoặc hoàn thiện test evidence| T
    TG -->|Đạt: test evidence đủ, phạm vi release xác định,<br/>quyết định authority được ghi nhận| R["Release<br/>Đưa bản đã kiểm soát vào môi trường dùng"]

    R --> RG{"Exit: người dùng nhận đúng phiên bản;<br/>release record liên kết KPI definition<br/>và test evidence?"}
    RG -->|Chưa đạt: hoàn thiện release record hoặc phạm vi| R
    RG -->|Đạt: báo cáo đang dùng trong phạm vi release| O["Operations<br/>Theo dõi chất lượng KPI"]

    O --> OG{"Exit: có operational record?"}
    OG -->|Chưa có: ghi nhận độ mới dữ liệu, lỗi tải,<br/>thay đổi nguồn hoặc phản hồi| O
    OG -->|Có| C{"Phát hiện gì?"}
    C -->|Nhu cầu mới| D
    C -->|Lệch dữ liệu hoặc công thức| A
    C -->|Không có lệch cần thay đổi| O

Pha	Entry gate chính xác	Việc của reporting/KPI	Exit gate chính xác
Discovery	Có vấn đề hoặc quyết định nghiệp vụ được ghi nhận, chưa gọi đó là KPI	Xác định ai cần quyết định gì, tần suất nào, hậu quả nếu thiếu số đo	Có problem statement, nhóm người dùng, quyết định cần hỗ trợ và giả thuyết chỉ số
Analysis	Có mục tiêu đo và nguồn dữ liệu ứng viên	Chốt tên, mục đích, công thức, đơn vị VND nếu là tiền, chiều phân tích, kỳ đo, quy tắc thiếu dữ liệu, nguồn hệ thống, acceptance criteria	KPI definition đủ truy vết; điểm chưa xác minh mang nhãn Verification required hoặc project assumption
Delivery	Có đặc tả KPI đủ để build, không có công thức mơ hồ	Cấu hình truy vấn, mô hình dữ liệu, biểu đồ, phân quyền hiển thị và nhãn kỳ báo cáo	Bản build thể hiện đúng đặc tả; mọi thay đổi kỹ thuật cập nhật traceability
Testing	Có bản build và test basis gồm định nghĩa KPI, dữ liệu test tổng hợp, expected result	Kiểm tra công thức, lọc, phân quyền, tổng hợp, làm tròn, dữ liệu trống và hiển thị	Test result ghi nhận pass/fail; lỗi chặn release đã xử lý hoặc được authority quyết định xử lý theo kiểm soát
Release	Có test result đủ, phạm vi release xác định, quyết định release được ghi nhận bởi authority phù hợp	Công bố phiên bản báo cáo, ghi nhận phạm vi, ngày hiệu lực và kênh hỗ trợ	Người dùng nhận đúng phiên bản; release record liên kết KPI definition và test evidence
Operations	Báo cáo đang được dùng trong phạm vi đã release	Theo dõi độ mới dữ liệu, lỗi tải, thay đổi nguồn, phản hồi về diễn giải KPI	Có operational record; lệch dữ liệu, công thức hoặc nhu cầu mới quay lại Discovery hoặc Analysis

Applied

Facts: Nova Foods mô phỏng cần báo cáo “Biên lợi nhuận theo nhà máy” theo tháng, hiển thị VND. Artifact đầu vào chỉ ghi tên báo cáo và nhóm Finance; chưa có công thức biên lợi nhuận, mẫu số, thời điểm ghi nhận, hay nguồn dữ liệu canonical.

Current Behavior: Nhóm Delivery có thể dựng biểu đồ từ doanh thu và giá vốn tổng hợp. Kết quả trông hợp lý nhưng hai người dùng có thể hiểu “biên lợi nhuận” khác nhau: giá trị tiền VND hoặc tỷ lệ phần trăm.

Underlying Need: Cần một KPI definition phân biệt rõ “lợi nhuận gộp” và “tỷ lệ biên lợi nhuận gộp”, vì đơn vị đo khác nhau dẫn đến biểu đồ, phép tính và ngưỡng cảnh báo khác nhau.

Options: O1: xây dashboard ngay với công thức do Delivery chọn. O2: chỉ hiển thị lợi nhuận gộp VND, tạm không gọi là biên lợi nhuận. O3: dừng ở Analysis đến khi Accounting Owner xác minh công thức, mẫu số, kỳ ghi nhận và nguồn dữ liệu.

Decision Criteria: Chọn phương án nào giữ đúng nghĩa chỉ số, có owner chuyên môn cho công thức, có testable expected result, và không biến project assumption thành fact.

Decision: Trong trạng thái IN_REVIEW, dùng O3. Lý do: evidence hiện có không xác định công thức; không thể tạo expected result đáng tin để Testing xác nhận.

Authority: Accounting Owner xác minh công thức và kỳ ghi nhận; Business Owner xác nhận chỉ số có phục vụ quyết định cần thiết; QA xác nhận test evidence, không tự định nghĩa KPI.

Artifact: KPI definition record phải chứa tên chỉ số, loại chỉ số, công thức, đơn vị, nguồn dữ liệu, chiều phân tích, lịch làm mới, owner, trạng thái xác minh và liên kết test case. Không gán ID mới ngoài registry canonical.

Consequence if Wrong: Nếu Delivery chọn công thức trước Analysis, dashboard có thể hiển thị số đúng theo code nhưng sai theo quyết định tài chính. Testing chỉ chứng minh code khớp công thức đã chọn, không chứng minh công thức đúng nghiệp vụ.

Senior Lens

Entry gate kiểm tra “đã đủ điều kiện bắt đầu pha chưa”; exit gate kiểm tra “đầu ra pha này đã đủ tin cậy để pha sau dùng chưa”. Không thay exit gate bằng cuộc họp, cảm giác đồng thuận, hoặc dashboard chạy được. Dashboard chạy được chỉ là bằng chứng Delivery; nó không thay thế định nghĩa KPI, expected result, hay xác minh chuyên môn.

Khi KPI liên quan kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật, BA giữ traceability và nhãn Verification required. BA không tự suy diễn nghĩa vụ từ nguồn pháp lý hoặc tự xác nhận công thức chuyên môn. Luật Kế toán và nguồn pháp lý liên quan chỉ là bối cảnh cần owner có thẩm quyền xác minh trước khi diễn đạt thành yêu cầu hệ thống.

Quick Reference

Gate	Câu hỏi kiểm tra
Discovery entry	Có vấn đề quyết định cụ thể chưa?
Discovery exit	Đã biết ai dùng chỉ số để quyết định gì chưa?
Analysis entry	Có mục tiêu đo và nguồn dữ liệu ứng viên chưa?
Analysis exit	Công thức, đơn vị, kỳ đo, nguồn và acceptance criteria đã đủ chưa?
Delivery entry	Builder có thể build mà không tự đoán nghĩa KPI chưa?
Testing entry	Tester có expected result từ định nghĩa đã kiểm soát chưa?
Release entry	Có test evidence và release decision record chưa?
Operations exit	Có lệch dữ liệu hoặc nhu cầu mới cần quay lại Lifecycle chưa?

Core

Reporting biometrics và KPI definition đi qua nhiều owner vì mỗi người kiểm soát một loại rủi ro khác nhau. Owner là vai trò chịu trách nhiệm tạo, kiểm tra hoặc quyết định trong phạm vi được giao; không đồng nghĩa người đó được tự phê duyệt mọi nội dung. Handoff là bàn giao có bằng chứng: đầu vào, trạng thái, người nhận, điểm còn mở và giới hạn dùng.

Hướng	Owner nguồn	Handoff bắt buộc	Owner nhận	Giới hạn thẩm quyền	Escalation
Upstream	Business Owner	Mục tiêu quyết định, câu hỏi quản trị, phạm vi tổ chức mô phỏng	BA	Business Owner nêu nhu cầu, không tự chọn công thức kỹ thuật	Mục tiêu mâu thuẫn giữa Sales, Finance, Supply Chain
Upstream	Domain Owner	Định nghĩa nghiệp vụ, sự kiện nguồn, ngoại lệ vận hành	BA	Domain Owner không tự xác nhận tính hợp pháp hay cách hạch toán	KPI chạm an toàn thực phẩm, truy xuất, nhân sự
Upstream	Data Owner	Nguồn dữ liệu, ý nghĩa trường, chất lượng, quyền truy cập	BA và Data/BI Owner	Data Owner không tự thay đổi business outcome	Trường dữ liệu không có định nghĩa canonical hoặc chất lượng không đủ
Upstream	Accounting Owner	Cách hiểu chỉ tiêu tài chính và giả định cần kiểm tra	BA	Không có diễn giải kế toán từ BA	Công thức ảnh hưởng doanh thu, giá vốn, thuế, chứng từ
Downstream	BA	KPI definition: mục đích, công thức, grain, filter, owner, ngưỡng, nguồn, giả định, traceability	Architect, Data/BI Owner, QA	BA không chọn kiến trúc production, không cấp quyền dữ liệu	KPI cần dữ liệu mới, tích hợp mới, hoặc thay đổi mô hình dữ liệu
Downstream	Architect	Feasibility, kiến trúc, bảo mật, giới hạn tích hợp	Delivery team	Architect không thay Business Owner quyết định ý nghĩa KPI	Xung đột bảo mật, hiệu năng, retention hoặc tích hợp
Downstream	QA	Test basis và acceptance criteria cho số liệu	Release/Operations	QA xác minh theo tiêu chí; không tự đổi công thức	Số liệu lệch, test data không tái lập, tiêu chí mơ hồ
Downstream	Operations Owner	Runbook, lịch làm mới, cảnh báo lỗi dữ liệu, kênh hỗ trợ	Người dùng báo cáo mô phỏng	Operations không tự sửa định nghĩa KPI	KPI hoạt động khác với định nghĩa đã truy vết

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

flowchart TB
    BO[Business Owner] -->|Mục tiêu quyết định| BA[BA]
    DO[Domain Owner] -->|Sự kiện nguồn và ngoại lệ vận hành| BA
    DATA[Data Owner] -->|Nguồn, ý nghĩa trường, chất lượng, quyền truy cập| BA
    DATA -->|Nguồn, ý nghĩa trường, chất lượng, quyền truy cập| DBI[Data/BI Owner]
    ACC[Accounting Owner] -->|Cách hiểu chỉ tiêu tài chính và giả định cần kiểm tra| BA

    BA -->|KPI definition: mục đích, công thức, grain, filter, owner, ngưỡng, nguồn, giả định, traceability| ARCH[Architect]
    BA -->|KPI definition: mục đích, công thức, grain, filter, owner, ngưỡng, nguồn, giả định, traceability| DBI
    BA -->|KPI definition| QA[QA]

    ARCH -->|Feasibility, kiến trúc, bảo mật, giới hạn tích hợp| DEL[Delivery team]
    QA -->|Test basis và acceptance criteria| REL[Release]
    QA -->|Test basis và acceptance criteria| OPS[Operations Owner]
    OPS -->|Runbook, lịch làm mới, cảnh báo lỗi dữ liệu, kênh hỗ trợ| USERS[Người dùng báo cáo mô phỏng]

    BO --- BONote[Business Owner không tự chọn công thức kỹ thuật]
    DO --- DONote[Domain Owner không tự xác nhận tính hợp pháp hoặc cách hạch toán]
    DATA --- DANote[Data Owner không thay đổi business outcome]
    ACC --- ACNote[BA không diễn giải kế toán]
    BA --- BANote[BA không chọn kiến trúc production hoặc cấp quyền dữ liệu]
    ARCH --- ARNote[Architect không quyết định ý nghĩa KPI]
    QA --- QANote[QA không tự đổi công thức]
    OPS --- OPNote[Operations không tự sửa định nghĩa KPI]

    BO -.Mục tiêu mâu thuẫn giữa Sales, Finance, Supply Chain.-> ESC[Escalation tới owner chuyên môn có thẩm quyền]
    DO -.KPI chạm an toàn thực phẩm, truy xuất, nhân sự.-> ESC
    DATA -.Không có định nghĩa canonical hoặc chất lượng không đủ.-> ESC
    ACC -.Công thức ảnh hưởng doanh thu, giá vốn, thuế, chứng từ.-> ESC
    BA -.KPI cần dữ liệu mới, tích hợp mới hoặc thay đổi mô hình dữ liệu.-> ESC
    ARCH -.Xung đột bảo mật, hiệu năng, retention hoặc tích hợp.-> ESC
    QA -.Số liệu lệch, test data không tái lập, tiêu chí mơ hồ.-> ESC
    OPS -.KPI hoạt động khác định nghĩa đã truy vết.-> ESC

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Business Owner yêu cầu KPI “Tỷ lệ giao hàng đúng hạn” cho báo cáo tuần. Data Owner cho biết dữ liệu đơn hàng có PromisedDeliveryDate, nhưng dữ liệu giao hàng có nhiều lần giao cho một đơn.

Current Behavior: Mỗi nhóm tự chia số đơn “đã giao đúng ngày” cho tổng đơn. Sales tính theo đơn; Warehouse tính theo lần giao. Hai dashboard có cùng tên KPI nhưng khác kết quả.

Underlying Need: Một KPI phải trả lời một câu hỏi quyết định. Nếu mục tiêu là đánh giá cam kết với khách hàng, đơn vị đo phải là đơn hàng, không phải lần giao. Lý do: khách hàng nhận một cam kết giao cho đơn; nhiều lần giao là chi tiết thực hiện.

Options:
1. Tính theo lần giao.
2. Tính theo đơn hàng, chỉ đạt khi toàn bộ lượng cam kết được giao không muộn hơn ngày cam kết.
3. Công bố cả hai KPI với tên và mục đích khác nhau.

Decision Criteria: Khớp câu hỏi quản trị; grain không mơ hồ; dữ liệu tái lập; không che giấu giao từng phần; có owner xác nhận nghĩa nghiệp vụ.

Decision: BA ghi đề xuất dùng option 2 cho KPI cam kết khách hàng; option 1 chỉ dùng nếu tạo KPI vận hành kho riêng. Đây là đề xuất phân tích, chưa là baseline hay approval.

Authority: Business Owner quyết định KPI phục vụ quản trị; Domain Owner xác nhận ý nghĩa “giao đủ”; Data Owner xác nhận trường nguồn; BA duy trì định nghĩa và traceability. Nếu PromisedDeliveryDate bị sửa sau khi đơn xác nhận, escalation tới Business Owner và Architect vì thay đổi làm sai mốc đo và có thể cần lưu lịch sử dữ liệu.

Artifact: Cập nhật định nghĩa KPI trong /02-handbook/15-reporting-biometrics-and-kpi-definition.md, liên kết CANONICAL_DATA_DICTIONARY cho trường dữ liệu và TRACEABILITY_ID_REGISTRY cho ID truy vết. Giữ trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Dashboard có thể báo tỷ lệ cao dù nhiều đơn giao thiếu hoặc trễ. Quản lý sẽ ưu tiên sai vấn đề; Delivery và QA cũng không có cùng test basis để phát hiện lệch.

Senior Lens

Không bàn giao “KPI” bằng tên ngắn. Bàn giao bằng định nghĩa kiểm chứng được: quyết định hỗ trợ, grain, công thức, điều kiện loại trừ, mốc thời gian, nguồn dữ liệu, xử lý dữ liệu thiếu, owner và tiêu chí chấp nhận. Evidence bridge: cùng tên KPI đã cho hai kết quả khi grain khác nhau; vì vậy grain là phần bắt buộc của handoff, không phải ghi chú phụ.

BA dừng và escalation khi yêu cầu vượt thẩm quyền: chỉ tiêu có diễn giải kế toán chuyển Accounting Owner; dữ liệu cá nhân chuyển Legal/Privacy Owner để xác minh; truy xuất hoặc an toàn thực phẩm chuyển Domain Owner và Legal Owner; quyền truy cập hoặc API chuyển Security và Architect. Nguồn luật trong corpus chỉ là nguồn tham chiếu; mọi yêu cầu pháp lý cụ thể cần Verification required từ owner có thẩm quyền.

Quick Reference

Điểm kiểm	Đạt khi	Không đạt khi
Upstream handoff	Có mục tiêu, owner, nguồn dữ liệu và ngoại lệ	Chỉ có tên dashboard hoặc yêu cầu “làm KPI”
BA handoff	Có công thức, grain, thời gian, filter, traceability	Công thức đúng số học nhưng không rõ đơn vị đo
Authority	Người quyết định đúng phạm vi được nêu rõ	BA, developer hoặc QA tự đổi nghĩa KPI
Escalation	Có trigger và owner nhận vấn đề	Mâu thuẫn bị xử lý bằng giả định im lặng
Downstream readiness	Architect và QA nhận đủ definition để thiết kế, test	Delivery phải tự suy đoán rule

Core

Báo cáo sinh trắc học vận hành (operational biometrics) đo trạng thái sức khỏe quy trình bằng số liệu: thời gian xử lý, tỷ lệ lỗi, độ đầy đủ dữ liệu, độ trễ báo cáo. KPI (Key Performance Indicator, chỉ số hiệu quả trọng yếu) chọn một phần nhỏ chỉ số để theo dõi mục tiêu nghiệp vụ. Sơ đồ lifecycle giúp BA thấy chỉ số đi qua các pha nào trước khi xuất hiện trên dashboard.

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, bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND. Nội dung thuộc /02-handbook/15-reporting-biometrics-and-kpi-definition.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline, approval, cấu hình ERP, hay chỉ dẫn production.

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

flowchart LR
    D[Discovery<br/>Nêu vấn đề đo lường] --> A[Analysis<br/>Định nghĩa KPI và dữ liệu]
    A --> DE[Delivery<br/>Xây báo cáo hoặc dashboard]
    DE --> T[Testing<br/>Đối chiếu số liệu và tiêu chí chấp nhận]
    T --> R[Release<br/>Công bố phiên bản báo cáo]
    R --> O[Operations<br/>Theo dõi, dùng, phát hiện lệch]
    O --> D

    D --- D1[Ví dụ: quản lý cần biết đơn hàng giao trễ]
    A --- A1[Ví dụ: công thức tỷ lệ giao đúng hẹn]
    DE --- DE1[Ví dụ: truy vấn, mô hình dữ liệu, dashboard]
    T --- T1[Ví dụ: so mẫu dữ liệu tổng hợp]
    R --- R1[Ví dụ: ghi nhận phiên bản phát hành]
    O --- O1[Ví dụ: phát hiện KPI giảm hoặc dữ liệu trễ]

Sơ đồ dùng vòng lặp thay vì đường thẳng. Bằng chứng: Operations có thể phát hiện số liệu không còn trả lời đúng câu hỏi nghiệp vụ; phát hiện này quay lại Discovery để đánh giá lại nhu cầu, không tự sửa công thức KPI trong dashboard.

Applied

Trường	Nội dung case Nova Foods mô phỏng
Facts	Báo cáo giao hàng có tỷ lệ “đúng hẹn” 92%. Dữ liệu tổng hợp cho thấy 8 đơn hàng chưa có thời điểm giao thực tế.
Current Behavior	Dashboard vẫn chia số đơn giao đúng hẹn cho toàn bộ đơn đã xuất kho.
Underlying Need	Phân biệt “giao trễ” với “chưa đủ dữ liệu xác nhận giao”; hai trạng thái tạo quyết định vận hành khác nhau.
Options	Giữ công thức hiện hữu; loại đơn thiếu thời điểm giao khỏi mẫu số; hiển thị riêng tỷ lệ thiếu dữ liệu cùng KPI đúng hẹn.
Decision Criteria	Công thức phải truy vết được về dữ liệu nguồn; không che giấu dữ liệu thiếu; người dùng đọc được trạng thái trong một màn hình; kiểm thử được bằng dữ liệu tổng hợp.
Decision	Hiển thị KPI giao đúng hẹn và chỉ số chất lượng dữ liệu riêng: tỷ lệ đơn thiếu thời điểm giao.
Authority	BA mô tả lựa chọn và tác động. Business Owner xác nhận ý nghĩa nghiệp vụ KPI. Data Owner xác nhận trường dữ liệu. QA xác nhận kết quả kiểm thử.
Artifact	Định nghĩa KPI, quy tắc tính, nguồn dữ liệu, mẫu kiểm thử và ghi nhận phiên bản báo cáo. Tham chiếu quản trị: CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Nếu gọi đơn thiếu dữ liệu là giao trễ, quản lý có thể ưu tiên sai đội giao nhận thay vì sửa quy trình nhập xác nhận giao hàng. Nếu loại đơn thiếu dữ liệu mà không hiển thị tỷ lệ thiếu, KPI có thể bị tăng giả tạo.

Senior Lens

Không nhầm lifecycle của KPI với lifecycle của dữ liệu. Dữ liệu có thể được tạo liên tục trong Operations, còn định nghĩa KPI chỉ đổi khi nhu cầu, quy tắc, nguồn dữ liệu, hoặc cách diễn giải đổi. Lý do: thay đổi công thức làm số liệu trước và sau thay đổi khó so sánh; vì vậy báo cáo cần ghi nhận phiên bản định nghĩa thay vì thay thế im lặng kết quả cũ.

Không suy diễn nghĩa vụ pháp lý từ dashboard. Nếu KPI dùng dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc, gắn nhãn Verification required và chuyển xác minh cho Legal Owner, Accounting Owner, Security Owner hoặc domain owner phù hợp. Nguồn luật trong corpus chỉ xác định ranh giới cần xác minh, không tự tạo yêu cầu production.

Quick Reference

Pha	Câu hỏi bản đồ cần trả lời	Dấu hiệu cần quay lại pha trước
Discovery	Cần quyết định nào từ chỉ số?	Không nêu được người dùng hoặc quyết định.
Analysis	KPI đo gì, không đo gì, từ dữ liệu nào?	Công thức không tái tính được.
Delivery	Báo cáo hiển thị kết quả và ngữ cảnh nào?	Dashboard không phân biệt dữ liệu thiếu với kết quả xấu.
Testing	Kết quả có khớp dữ liệu tổng hợp và quy tắc đã ghi?	Có chênh lệch không giải thích được.
Release	Người dùng nhận đúng phiên bản định nghĩa nào?	Không biết công thức hoặc nguồn dữ liệu đang dùng.
Operations	KPI còn hỗ trợ quyết định và dữ liệu còn đủ tin cậy?	Thay đổi quy trình, nguồn dữ liệu, hoặc cách dùng chỉ số.

4. Input c?n thi?t

Core

Định nghĩa KPI cần đầu vào trước khi viết công thức. Đầu vào là kiến thức nghiệp vụ, bằng chứng, artifact nguồn và định danh canonical. Không cần biết phần mềm ERP để bắt đầu: BA trước hết cần biết doanh nghiệp muốn quan sát điều gì, sự kiện nào tạo dữ liệu, và mỗi khái niệm được gọi thống nhất ra sao.

Kiến thức nghiệp vụ tiên quyết gồm: mục tiêu quyết định, quy trình tạo sự kiện, đối tượng đo, đơn vị đo và ngoại lệ. Ví dụ, “giao đúng hẹn” không tự có nghĩa. BA cần phân biệt ngày hứa giao, ngày giao thực tế, đơn bán hàng, dòng đơn hàng và giao từng phần. Cầu nối suy luận: KPI so sánh hai giá trị ngày; nếu không biết mỗi ngày thuộc sự kiện nào thì phép so sánh có thể đo sai hành vi.

Bằng chứng (evidence) là nội dung cho thấy một phát biểu có nguồn gốc. Bằng chứng có thể là mô tả quy trình, mẫu báo cáo hiện hữu, danh mục quy tắc, từ điển dữ liệu hoặc đặc tả giao diện. Bằng chứng không phải kết luận. BA ghi “nguồn nói gì”, rồi mới ghi “KPI suy ra gì” và lý do nối hai phần.

Artifact nguồn là tệp được kiểm soát chứa bằng chứng. Chỉ artifact có đường dẫn và ID ổn định mới dùng làm điểm tham chiếu. Bản sao gửi qua chat, ảnh chụp màn hình không có nguồn gốc, hoặc tên tệp tự đặt không thay thế artifact canonical.

Định danh canonical (persistent canonical ID) là mã giữ nguyên khi artifact được tham chiếu từ nhiều nơi. Mã giúp BA phân biệt đúng đối tượng dù tiêu đề được dịch, rút gọn hoặc sửa câu chữ. Ví dụ, CANONICAL_DATA_DICTIONARY luôn chỉ kế hoạch từ điển dữ liệu logic canonical; không thay bằng “data dictionary” hoặc mã tự tạo.

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

flowchart TB
    M[Mục tiêu quyết định] --> K[Kiến thức nghiệp vụ]
    P[Quy trình tạo sự kiện] --> K
    O[Đối tượng đo] --> K
    U[Đơn vị đo] --> K
    X[Ngoại lệ] --> K

    A[Artifact nguồn<br/>tệp kiểm soát có ID và đường dẫn] -->|chứa| E[Bằng chứng<br/>nguồn nói gì]
    I[Định danh canonical<br/>mã ổn định khi tham chiếu] -->|nhận diện| A

    K --> S[Phát biểu KPI suy ra gì]
    E --> S
    R[Lý do nối bằng chứng với KPI] --> S
    S --> D[Định nghĩa KPI<br/>có thể truy vết]

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.

Thành phần bắt buộc	Giá trị Nova Foods mô phỏng	Bằng chứng hoặc cầu nối suy luận	Tham chiếu canonical
Facts	Báo cáo cần theo dõi tỷ lệ giao đúng hẹn cho đơn bán hàng thành phẩm.	“Đúng hẹn” cần ngày cam kết và ngày hoàn tất giao.	KPI-OTD-001
Current Behavior	Người học có thể gọi chung mọi ngày là “ngày giao”.	Một tên chung che mất khác biệt giữa cam kết và thực tế.	CANONICAL_DATA_DICTIONARY
Underlying Need	Phân biệt sự kiện cam kết giao với sự kiện xác nhận giao.	KPI chỉ có nghĩa khi tử số và mẫu số dùng cùng cấp đo lường.	CANONICAL_BUSINESS_RULES
Options	Đo theo đơn bán hàng; đo theo dòng đơn; đo theo chuyến giao.	Ba lựa chọn tạo mẫu số khác nhau.	KPI-OTD-001
Decision Criteria	Có truy ngược được đơn vị đo, ngày so sánh và nguồn dữ liệu không.	Không truy ngược được thì không tái tính được KPI.	TRACEABILITY_ID_REGISTRY
Decision	Chưa chọn cấp đo lường cho case mô phỏng. Ghi nhãn Verification required.	Artifact hiện có là kế hoạch quản trị, không xác nhận quy tắc vận hành Nova Foods.	KPI-OTD-001
Authority	Business Owner xác nhận ý nghĩa nghiệp vụ; domain owner xác nhận sự kiện giao; BA duy trì truy vết.	Owner corpus không thay thế thẩm quyền vận hành.	CHAPTER_MANIFEST
Artifact	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	Các đường dẫn này là nguồn kiểm soát đã nêu trong corpus.	Giữ nguyên tên tệp
Consequence if Wrong	KPI có thể báo cao dù giao từng phần bị trễ, hoặc báo thấp dù đơn đã hoàn tất đúng cam kết.	Cấp đo lường sai làm tử số và mẫu số đại diện cho tập sự kiện khác nhau.	KPI-OTD-001

Senior Lens

Không biến tên cột thành định nghĩa nghiệp vụ. promised_delivery_date có thể nghe giống “ngày hứa giao”, nhưng chỉ artifact dữ liệu canonical và bằng chứng quy trình mới xác định nó thuộc đơn, dòng đơn hay chuyến giao. Cầu nối suy luận: tên kỹ thuật là nhãn; ngữ nghĩa KPI cần bằng chứng về sự kiện và phạm vi áp dụng.

Không tạo ID mới để làm ví dụ nếu registry chưa cấp mã đó. Với KPI-OTD-001, chỉ dùng như ID case mô phỏng khi nó đã được đặt trong phạm vi học liệu; không suy diễn đây là requirement, baseline, approval hoặc cấu hình ERP thực tế. IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và VND là ngữ cảnh quản trị corpus, không phải bằng chứng vận hành.

Quick Reference

Cần thu thập	Câu hỏi tối thiểu	Kết quả cần có
Khái niệm nghiệp vụ	KPI đang đo đối tượng, sự kiện và khoảng thời gian nào?	Mô tả không phụ thuộc tên màn hình ERP
Bằng chứng	Phát biểu này xuất phát từ artifact nào?	Đường dẫn nguồn và ID artifact
Dữ liệu logic	Mỗi giá trị cần cho KPI biểu diễn điều gì?	Tham chiếu CANONICAL_DATA_DICTIONARY
Quy tắc	Điều kiện tính, loại trừ hoặc ngoại lệ nằm ở đâu?	Tham chiếu CANONICAL_BUSINESS_RULES
Định danh	ID nào giữ liên kết không đổi giữa artifact?	Mã canonical từ TRACEABILITY_ID_REGISTRY
Ranh giới	Nội dung nào chưa được nguồn có thẩm quyền xác nhận?	Nhãn Verification required

Core

Đầu vào cho định nghĩa báo cáo, chỉ số đo lường vận hành (biometrics) và KPI (Key Performance Indicator, chỉ số hiệu suất then chốt) phải qua kiểm tra chất lượng trước khi BA dùng. Lý do: số đúng công thức vẫn sai quyết định nếu nguồn không rõ, cũ, thiếu chủ sở hữu, hoặc không truy vết được. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi giá trị minh họa là dữ liệu tổng hợp.

Kiểm tra	Điều kiện đạt	Phân loại nguồn	Freshness tối đa	Owner xác nhận	Điều kiện dừng
Nhận diện	Có Artifact ID, đường dẫn canonical, version, Status	Canonical controlled artifact	Theo Last updated date của artifact	Principal IT Business Analyst / Technical Curriculum Author	ID hoặc đường dẫn không khớp registry
Nguồn gốc	Phân biệt fact, project assumption, Verification required	Verified primary source; canonical artifact; project assumption; Verification required	Nguồn luật/chuẩn: kiểm tra tại ngày dùng	Legal Owner, Accounting Owner, domain owner tùy nội dung	Assumption bị viết thành fact hoặc nghĩa vụ
Đầy đủ	Có định nghĩa, đơn vị, phạm vi, thời gian, cách tính hoặc lý do chưa có	Canonical artifact hoặc verified evidence	Phù hợp chu kỳ báo cáo	Business Owner	Thiếu phần làm KPI không thể tái lập
Nhất quán	Tên trường, ID, đơn vị VND, locale vi-VN, múi giờ Asia/Ho_Chi_Minh không mâu thuẫn	Canonical controlled artifact	Kiểm tra mỗi lần ghép nguồn	BA phối hợp data owner	Hai nguồn canonical mâu thuẫn
Kịp thời	Dữ liệu nằm trong cửa sổ thời gian đã công bố	Operational evidence mô phỏng	Ngày, tuần, tháng theo định nghĩa KPI	Data Owner	Không biết thời điểm chốt dữ liệu
Thẩm quyền	Người cung cấp có quyền xác nhận loại nội dung đó	Verified owner evidence	Hiệu lực tại thời điểm review	Business Owner, Legal Owner, Accounting Owner, Architect, QA Owner	BA tự kết luận pháp lý, kế toán, kiến trúc hoặc phê duyệt

Applied

Facts: CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY có Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07. Corpus dùng vi-VN, Asia/Ho_Chi_Minh, VND. Chưa có baseline reference hay approval reference.

Current Behavior: BA nhận đề xuất “KPI doanh thu tháng” từ trao đổi mô phỏng, nhưng đề xuất không chỉ rõ nguồn dữ liệu, thời điểm chốt, owner, hay cách xử lý hóa đơn điều chỉnh.

Underlying Need: KPI phải cho người đọc biết con số đến từ đâu, mới đến mức nào, ai chịu trách nhiệm xác nhận, và khi nào không được công bố.

Options: (1) Dùng đề xuất như KPI chính thức. (2) Gắn project assumption và tiếp tục thiết kế. (3) Dừng định nghĩa KPI đến khi có nguồn canonical và owner đúng thẩm quyền.

Decision Criteria: Chọn phương án chỉ khi có truy vết, phân loại nguồn, freshness, owner và không vượt thẩm quyền. Bằng chứng: các artifact upstream ghi IN_REVIEW và chưa có approval; vì vậy không đủ căn cứ gọi KPI là đã phê duyệt.

Decision: Chọn phương án (3) nếu KPI sẽ dùng cho quyết định nghiệp vụ, tài chính hoặc tuân thủ. Chỉ chọn phương án (2) cho ví dụ học liệu, phải giữ nhãn project assumption.

Authority: Business Owner xác nhận mục tiêu và phạm vi KPI. Accounting Owner xác nhận diễn giải doanh thu. Legal Owner xác nhận nội dung pháp lý khi có. Data Owner xác nhận dữ liệu và freshness. Principal IT Business Analyst / Technical Curriculum Author giữ traceability, không thay các thẩm quyền này.

Artifact: Ghi nguồn và trạng thái trong /02-handbook/15-reporting-biometrics-and-kpi-definition.md; liên kết nguyên dạng CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY.

Consequence if Wrong: KPI có thể dùng số cũ, đếm sai phạm vi, hoặc diễn giải sai nghĩa vụ; báo cáo mất khả năng kiểm tra và không được dùng làm căn cứ vận hành hay production.

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

flowchart TB
    A[Nhận đầu vào KPI] --> T[Principal IT Business Analyst / Technical Curriculum Author ghi nguồn, trạng thái và liên kết nguyên dạng<br/>CANONICAL_DATA_DICTIONARY<br/>CANONICAL_BUSINESS_RULES<br/>TRACEABILITY_ID_REGISTRY]
    T --> B{Có ID, đường dẫn canonical,<br/>version, Status?}
    B -- Không --> S1[STOP: thiếu nhận diện]
    B -- Có --> C{Nguồn được phân loại?}
    C -- Không --> S2[STOP: nguồn chưa rõ]
    C -- Có --> D{Freshness có căn cứ canonical<br/>và tiêu chí chốt được xác nhận?}
    D -- Không --> S3[STOP: chưa xác nhận freshness hoặc thời điểm chốt]
    D -- Có --> E{Business Owner xác nhận<br/>mục tiêu và phạm vi?}
    E -- Không --> S4[STOP: thiếu xác nhận Business Owner]
    E -- Có --> F{Accounting Owner xác nhận diễn giải doanh thu,<br/>thời điểm ghi nhận và xử lý hóa đơn điều chỉnh?}
    F -- Không --> S5[STOP: thiếu xác nhận Accounting Owner]
    F -- Có --> G{Data Owner xác nhận<br/>dữ liệu và freshness?}
    G -- Không --> S6[STOP: thiếu xác nhận Data Owner]
    G -- Có --> H{Có nội dung pháp lý?}
    H -- Có --> I{Legal Owner xác nhận?}
    I -- Không --> S7[STOP: thiếu xác nhận Legal Owner]
    I -- Có --> J{Mục đích dùng KPI?}
    H -- Không --> J

    J -- Ví dụ học liệu --> L[Giữ nhãn project assumption]
    L --> L1[Tiếp tục thiết kế minh họa]
    L1 --> L2[Không công bố như KPI chính thức;<br/>không dùng làm căn cứ nghiệp vụ, tài chính, tuân thủ hoặc production]

    J -- Nghiệp vụ, tài chính, tuân thủ hoặc production --> K{Nguồn canonical không còn IN_REVIEW<br/>và có trạng thái phê duyệt theo governance?}
    K -- Không --> S8[STOP: artifact upstream còn IN_REVIEW<br/>hoặc chưa có trạng thái phê duyệt phù hợp]
    K -- Có --> M{Có approval reference từ owner<br/>đúng thẩm quyền?}
    M -- Không --> S9[STOP: chưa có approval reference]
    M -- Có --> N[KPI được dùng đúng mục đích đã phê duyệt;<br/>không suy rộng sang mục đích khác]

    S1 --> R[KPI bị chặn: không đủ căn cứ vận hành hoặc production.<br/>Rủi ro: số cũ, sai phạm vi, sai nghĩa vụ, mất khả năng kiểm tra]
    S2 --> R
    S3 --> R
    S4 --> R
    S5 --> R
    S6 --> R
    S7 --> R
    S8 --> R
    S9 --> R

Senior Lens

Freshness không phải “ngày tệp được sửa”. Freshness là thời điểm dữ liệu phản ánh đúng trạng thái nghiệp vụ theo định nghĩa KPI. Ví dụ, tệp cập nhật ngày 2026-08-07 vẫn không fresh cho KPI tháng 07/2026 nếu dữ liệu chỉ chốt đến 2026-07-15. BA phải ghi cả data through date và artifact last updated date; hai ngày này phục vụ hai câu hỏi khác nhau.

Không nâng cấp phân loại nguồn bằng ngôn ngữ. Verified primary source là nguồn chính thức đã nêu URL và ngày truy cập. Canonical controlled artifact là nguồn nội bộ corpus có ID, đường dẫn, version, Status. Project assumption là giả định học liệu. Verification required là điểm chưa đủ bằng chứng. IN_REVIEW không phải APPROVED, BASELINED, compliant hay production-ready.

Quick Reference

Nhãn dùng trong artifact	Nghĩa	Được dùng để
Verified primary source	Nguồn chính thức, có URL và ngày truy cập 2026-08-07	Thuật ngữ, trạng thái chuẩn, bối cảnh pháp lý cần owner xác minh
Canonical controlled artifact	Artifact corpus có ID và đường dẫn canonical	Traceability, metadata, phạm vi mô phỏng
project assumption	Giả định chưa xác nhận	Ví dụ học liệu không tạo nghĩa vụ
Verification required	Thiếu bằng chứng hoặc thiếu owner xác nhận	Chặn kết luận và kích hoạt escalation
STOP	Không tiếp tục định nghĩa hoặc công bố KPI	Ngăn số liệu không truy vết được đi vào quyết định

Core

Bảng dưới là tập đầu vào đầy đủ cho ví dụ báo cáo KPI của Nova Foods Trading & Manufacturing, case mô phỏng giáo dục. Mọi số liệu là dữ liệu tổng hợp, đơn vị tiền tệ VND, ngày theo Asia/Ho_Chi_Minh. IN_REVIEW và v0.9.0 không phải baseline hay phê duyệt.

Applied

Facts: Nova Foods cần minh họa báo cáo doanh thu, biên lợi nhuận gộp và tỷ lệ giao đúng hẹn tháng 2026-07.

Current Behavior: Corpus mới có artifact kế hoạch; chưa có cấu hình ERP, dữ liệu production, baseline hoặc approval.

Underlying Need: Người học cần biết mỗi KPI phải truy về nguồn, giá trị mẫu, trạng thái xác minh và điểm không được tự suy diễn.

Nhóm đầu vào	Canonical ID / nguồn	Tệp hoặc nguồn	Phân loại nguồn	Giá trị tổng hợp dùng minh họa	Trạng thái xác minh	Hạng mục chưa giải quyết
Quản trị corpus	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Status IN_REVIEW; Version v0.9.0; date 2026-08-07	Đã ghi nhận trong corpus	Không có baseline reference
Định danh truy vết	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	Registry là nguồn canonical cho ID liên artifact	Đã ghi nhận trong corpus	Chưa xác định ID KPI riêng cho báo cáo này
Định nghĩa dữ liệu logic	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Trường minh họa: SalesAmount, COGSAmount, PromisedDeliveryDate, ActualDeliveryDate	Đang xem xét	Verification required: tên trường, kiểu dữ liệu, nguồn hệ thống thực
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Giả định dự án: doanh thu tính từ đơn hoàn tất giao trong tháng	Giả định dự án	Verification required: Business Owner xác nhận thời điểm ghi nhận doanh thu
Doanh thu tháng	Dữ liệu giao dịch Nova Foods tổng hợp	Không có tệp production; mẫu học liệu	Synthetic educational data	1.250.000.000 VND	Chỉ dùng minh họa	Verification required: trạng thái đơn hàng nào được tính doanh thu
Giá vốn tháng	Dữ liệu giao dịch Nova Foods tổng hợp	Không có tệp production; mẫu học liệu	Synthetic educational data	875.000.000 VND	Chỉ dùng minh họa	Verification required: Accounting Owner xác nhận thành phần giá vốn
Đơn giao đúng hẹn	Dữ liệu giao hàng Nova Foods tổng hợp	Không có tệp production; mẫu học liệu	Synthetic educational data	184 đơn đúng hẹn trên 200 đơn giao	Chỉ dùng minh họa	Verification required: định nghĩa “đúng hẹn” khi khách đổi ngày hứa
Bối cảnh pháp lý dữ liệu	Luật 91/2025/QH15	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	Verified legal source	Chỉ dùng để nhắc cần kiểm tra xử lý dữ liệu cá nhân	Nguồn chính thức đã định danh	Verification required: Legal Owner xác nhận yêu cầu áp dụng cho báo cáo thực
Bối cảnh kế toán	Luật 88/2015/QH13	https://vanban.chinhphu.vn/?docid=183198&pageid=27160	Verified legal source	Không dùng để tự kết luận công thức kế toán	Nguồn chính thức đã định danh	Verification required: Accounting Owner xác nhận diễn giải và kỳ ghi nhận

Options: Dùng số tổng hợp có nhãn giả định; hoặc gắn số đó như dữ liệu ERP thực.

Decision Criteria: Không được làm người đọc tin có ERP production, phê duyệt, hay kết luận kế toán/pháp lý chưa xác minh.

Decision: Dùng số tổng hợp; giữ mọi điểm cần xác minh trong bảng.

Authority: Business Owner xác nhận KPI nghiệp vụ; Accounting Owner xác nhận giá vốn; Legal Owner xác nhận dữ liệu cá nhân. Owner corpus chỉ giữ traceability.

Artifact: /02-handbook/15-reporting-biometrics-and-kpi-definition.md, Status IN_REVIEW, Version v0.9.0.

Consequence if Wrong: Báo cáo có thể tính sai KPI, che nguồn số liệu, hoặc biến giả định học liệu thành quyết định vận hành.

Senior Lens

Biên lợi nhuận gộp minh họa là (1.250.000.000 - 875.000.000) / 1.250.000.000 = 30%. Bằng chứng là hai giá trị tổng hợp trong bảng. Suy luận chỉ hợp lệ cho ví dụ học liệu; không chứng minh cách Nova Foods thực ghi nhận doanh thu hay giá vốn.

Tỷ lệ giao đúng hẹn minh họa là 184 / 200 = 92%. Mẫu số chỉ gồm đơn đã giao trong tháng theo giả định dự án. Nếu mẫu số đổi thành mọi đơn đã hứa giao, kết quả đổi; vì vậy điểm này giữ nhãn Verification required.

Quick Reference

KPI minh họa	Công thức	Giá trị tổng hợp	Giới hạn dùng
Doanh thu	Tổng SalesAmount của đơn đủ điều kiện	1.250.000.000 VND	Giả định dự án
Biên lợi nhuận gộp	(Doanh thu - Giá vốn) / Doanh thu	30%	Cần Accounting Owner xác nhận
Giao đúng hẹn	Đơn đúng hẹn / Đơn đã giao	92%	Cần Business Owner xác nhận

5. Step-by-step BA Activities

Applied

Quy trình này biến nhu cầu báo cáo thành định nghĩa KPI có thể kiểm tra. Nova Foods là case mô phỏng giáo dục; mọi số liệu là tổng hợp. Trạng thái artifact giữ IN_REVIEW, Version v0.9.0, ngày 2026-08-07. BA không tự xác nhận quy tắc kế toán, pháp lý, dữ liệu cá nhân hay quyết định vận hành.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1	BA	Lập phạm vi báo cáo, kỳ đo, đơn vị đo và người dùng mục tiêu.	Yêu cầu báo cáo ban đầu, ví dụ KPI doanh thu theo tháng.	Bản ghi phạm vi gồm mục tiêu, nhóm người dùng, kỳ tháng, VND, Asia/Ho_Chi_Minh.	Không nhận KPI nếu chưa nêu người dùng, quyết định cần hỗ trợ và kỳ đo.	Mỗi KPI có một câu hỏi nghiệp vụ trả lời được.	Business Owner khi mục tiêu hoặc người dùng mâu thuẫn.
2	BA	Thu thập nguồn dữ liệu và phân loại nguồn: canonical, giả định dự án, hoặc Verification required.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, yêu cầu stakeholder.	Data-source register ghi nguồn, trường dữ liệu, owner, độ tin cậy, giới hạn dùng.	Không suy diễn trường dữ liệu hay business rule từ tên trường.	Mỗi biến trong công thức truy được về nguồn hoặc mang nhãn giả định.	Data Owner khi thiếu định nghĩa trường; Principal IT Business Analyst / Technical Curriculum Author khi traceability mâu thuẫn.
3	BA	Phân rã KPI thành công thức, tử số, mẫu số, điều kiện lọc, thời điểm chốt và cách xử lý giá trị thiếu.	Định nghĩa KPI nháp.	KPI definition sheet gồm công thức, grain, filter, timezone, currency, ngoại lệ.	Một KPI chỉ có một công thức chuẩn tại một grain.	Tử số và mẫu số không chồng chéo sai; chia cho 0 có quy tắc hiển thị rõ.	Business Owner khi ngưỡng hoặc ý nghĩa KPI chưa rõ; Accounting Owner khi liên quan doanh thu, giá vốn, lợi nhuận.
4	BA	Đối chiếu hành vi hiện tại với nhu cầu gốc; ghi cầu nối bằng chứng-suy luận.	Báo cáo hiện tại, mẫu xuất dữ liệu tổng hợp, ghi chú stakeholder.	Gap log: Facts, Current Behavior, Underlying Need, Options, Decision Criteria.	Facts phải là quan sát hoặc nguồn đã định danh; suy luận phải nêu lý do từ Facts.	Không có câu “hệ thống phải” nếu chưa có nguồn hoặc authority tương ứng.	Architect khi khác biệt cần thay đổi integration hoặc data model; Security Owner khi dữ liệu nhạy cảm xuất hiện.
5	BA	Đánh giá phương án định nghĩa KPI và chọn phương án đề xuất.	Options trong gap log.	Decision record ghi phương án, tiêu chí, trade-off, authority cần xác nhận.	Chọn phương án ít diễn giải thủ công nhất, truy vết tốt nhất, không vượt authority.	Tiêu chí gồm tính nhất quán, khả năng kiểm thử, nguồn dữ liệu, tác động quyền truy cập.	Business Owner quyết định ý nghĩa nghiệp vụ; Accounting Owner quyết định diễn giải kế toán; Legal Owner quyết định nghĩa vụ dữ liệu cá nhân.
6	BA	Kiểm tra bằng bộ dữ liệu tổng hợp và tính lại thủ công.	Công thức KPI, dữ liệu tổng hợp Nova Foods.	Reconciliation sheet: đầu vào, phép tính, kết quả, sai lệch, kết luận kiểm tra.	Kết quả báo cáo phải khớp phép tính tái lập từ cùng tập dữ liệu và cùng filter.	Có thể tái tính bởi người khác mà không cần diễn giải miệng.	QA reviewer khi không tái lập được; Data Owner khi dữ liệu nguồn khác kết quả.
7	BA	Tổ chức review có kiểm soát, ghi người review, phạm vi review, vấn đề và kết quả.	KPI definition sheet, gap log, reconciliation sheet.	Review log với trạng thái từng vấn đề: mở, cần làm rõ, đã xử lý bằng bằng chứng.	IN_REVIEW không đổi thành approval chỉ vì đã họp review.	Mọi phản hồi tác động công thức, nguồn, quyền xem hoặc kỳ chốt đều có traceability.	Authority theo loại quyết định; BA không tự đóng vấn đề thuộc thẩm quyền khác.
8	BA	Handoff gói định nghĩa cho đội tiêu thụ, giữ version và điểm chưa xác minh.	Gói KPI đã review.	Controlled handoff note liên kết /02-handbook/15-reporting-biometrics-and-kpi-definition.md, Status IN_REVIEW, Version v0.9.0.	Handoff chỉ chuyển nội dung để dùng tiếp; không tạo baseline, approval hoặc quyền production.	Gói có công thức, nguồn, rule, giả định, test evidence, owner và escalation route.	Principal IT Business Analyst / Technical Curriculum Author khi thiếu artifact hoặc sai ID; recipient trả lại khi quality gate không đạt.

Ví dụ thực thi: BA nhận yêu cầu “theo dõi biên lợi nhuận gộp tháng”. Facts: ví dụ trước dùng doanh thu tổng hợp 1.250.000.000 VND và giá vốn tổng hợp 875.000.000 VND. Current Behavior: báo cáo chỉ hiển thị doanh thu, chưa nêu giá vốn và công thức. Underlying Need: người quản lý cần biết phần doanh thu còn lại sau giá vốn theo cùng kỳ. Cầu nối suy luận: vì biên lợi nhuận cần cả doanh thu lẫn giá vốn, báo cáo doanh thu đơn lẻ không trả lời được nhu cầu.

Options: dùng (Doanh thu - Giá vốn) / Doanh thu; dùng lợi nhuận trước thuế thay giá vốn; hoặc không công bố KPI cho đến khi xác minh nguồn giá vốn. Decision Criteria: công thức phải phản ánh đúng tên KPI, tái tính được, không tự diễn giải kế toán. Decision: đề xuất công thức thứ nhất cho ví dụ học liệu, kèm nhãn Verification required cho định nghĩa giá vốn. Authority: Business Owner xác nhận mục đích KPI; Accounting Owner xác nhận giá vốn và kỳ ghi nhận. Artifact: KPI definition sheet, reconciliation sheet, review log và controlled handoff note trong /02-handbook/15-reporting-biometrics-and-kpi-definition.md. Consequence if Wrong: có thể hiển thị tỷ lệ 30% nhưng gán sai chi phí vào giá vốn, làm quyết định giá bán hoặc đánh giá hiệu quả bị sai.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. KPI (Key Performance Indicator, chỉ số đo mức đạt mục tiêu) phải có nguồn dữ liệu, công thức, ngưỡng, owner và cách xử lý khi số liệu không đáng tin. IN_REVIEW và v0.9.0 không phải baseline hay phê duyệt.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	BA	Ghi mục tiêu quyết định cần báo cáo hỗ trợ, kỳ đo, đơn vị VND và đối tượng dùng.	Bản nháp định nghĩa KPI trong /02-handbook/15-reporting-biometrics-and-kpi-definition.md	Danh sách câu hỏi quyết định, owner dự kiến, phạm vi dữ liệu tổng hợp	Chỉ nhận KPI trả lời ít nhất một quyết định nghiệp vụ cụ thể; không nhận chỉ số “để theo dõi”.	Mỗi KPI có người dùng và quyết định đích.	Mục tiêu mơ hồ: Business Owner. Phạm vi chạm dữ liệu cá nhân: Legal/Privacy Owner.
2. Thu thập sự thật nguồn	BA	Liệt kê hệ thống nguồn, trường dữ liệu, thời điểm chốt và giới hạn chất lượng.	Bản đồ nguồn logic, tham chiếu CANONICAL_DATA_DICTIONARY	Bảng nguồn-trường-thời điểm, ghi rõ “Verification required” nếu chưa xác minh	Không suy ra trường dữ liệu, ý nghĩa trạng thái hay lịch chốt từ tên cột.	Mỗi biến công thức truy được về một nguồn hoặc bị gắn nhãn giả định dự án.	Nguồn mâu thuẫn: Data Owner. Ý nghĩa nghiệp vụ mâu thuẫn: Business Owner.
3. Định nghĩa phép đo	BA	Viết công thức, tử số, mẫu số, bộ lọc, đơn vị, chiều phân tích và quy tắc làm tròn.	KPI definition	Công thức có ví dụ dữ liệu tổng hợp và quy tắc biên	Mẫu số bằng 0 phải trả về trạng thái “không có dữ liệu”, không trả về 0%; 0% là kết quả đo khác.	Người khác tính lại từ cùng dữ liệu tổng hợp ra cùng kết quả.	Công thức ảnh hưởng doanh thu, giá vốn, thuế hoặc sổ sách: Accounting Owner.
4. Kiểm tra giá trị và khả năng đo	BA cùng Data Owner	Đối chiếu KPI với dữ liệu tổng hợp, kiểm tra thiếu dữ liệu, trùng khóa, kỳ thời gian và đơn vị VND.	Tập dữ liệu kiểm tra tổng hợp	Nhật ký đối chiếu, kết quả tính lại, danh sách ngoại lệ	Không công bố KPI khi khóa định danh không duy nhất, kỳ đo lẫn múi giờ, hoặc nguồn chưa xác định thời điểm chốt.	Tỷ lệ, tổng tiền và số bản ghi khớp quy tắc đã định; ngoại lệ có owner xử lý.	Lỗi tích hợp hay truy vấn: Technical Owner/Architect. Lỗi dữ liệu nguồn: Data Owner.
5. Review và handoff có kiểm soát	BA	Gửi định nghĩa, bằng chứng và điểm chưa xác minh để review; ghi nhận phản hồi theo thẩm quyền.	Gói KPI review liên kết CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY khi có ID đã đăng ký	Log review, quyết định còn mở, nhãn trạng thái IN_REVIEW	Chỉ handoff để tiếp tục thiết kế khi không còn mâu thuẫn về công thức, nguồn, owner hoặc ngưỡng; không gọi là approved.	Gói bàn giao chứa công thức, nguồn, kiểm tra, owner, ngoại lệ và route escalation.	Tranh chấp ngưỡng: Business Owner. Rủi ro bảo mật: Security Owner. Thiếu thẩm quyền: Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề.

Facts: Nova Foods mô phỏng cần KPI doanh thu theo tháng bằng VND. Current Behavior: báo cáo có thể cộng mọi dòng bán hàng, kể cả dòng hủy. Underlying Need: đo doanh thu của giao dịch hợp lệ, không đo hoạt động bị hủy. Options: gồm mọi dòng; hoặc chỉ gồm dòng có trạng thái nghiệp vụ đã được Data Owner xác minh. Decision Criteria: truy vết nguồn, tái tính được, không diễn giải trạng thái theo giả định. Decision: chọn phương án thứ hai khi trạng thái được xác minh; nếu chưa xác minh, gắn Verification required và dừng công bố KPI. Authority: Business Owner xác nhận mục tiêu; Data Owner xác nhận nghĩa trạng thái; Accounting Owner review khi kết quả dùng cho báo cáo kế toán. Artifact: định nghĩa KPI, bảng nguồn-trường-thời điểm, log đối chiếu. Consequence if Wrong: doanh thu bị thổi phồng hoặc thiếu, quyết định quản trị dùng số liệu sai.

Core

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Bảng thực thi biến định nghĩa KPI thành bằng chứng kiểm tra được: số liệu đầu vào, công thức, kỳ báo cáo, người chịu trách nhiệm, ngoại lệ. KPI không đúng vì “trông hợp lý”; KPI đúng khi cùng dữ liệu, cùng quy tắc, cùng thời điểm cho cùng kết quả.

Applied

Facts: Báo cáo giao hàng tháng 07/2026 cần đo tỷ lệ đơn giao đúng hạn và đủ số lượng. Dữ liệu tổng hợp ghi 120 đơn đủ điều kiện; 102 đơn thỏa cả hai điều kiện.

Current Behavior: Bộ phận Kinh doanh đếm đơn giao trễ theo ngày xuất kho; Kho đếm theo ngày xác nhận giao. Hai cách đếm khác mốc thời gian nên cùng tên chỉ số cho kết quả khác.

Underlying Need: Có một định nghĩa KPI dùng chung cho báo cáo ERP, truy vết được đến dữ liệu nguồn và không tự diễn giải thành cam kết vận hành thật.

Hạng mục thực thi	Nội dung Nova Foods mô phỏng	Bằng chứng ghi vào /02-handbook/15-reporting-biometrics-and-kpi-definition.md
KPI	Tỷ lệ giao đúng hạn và đủ số lượng
Tử số	102 đơn giao có ngày xác nhận giao không muộn hơn ngày cam kết giao, đồng thời số lượng xác nhận giao bằng số lượng đặt
Mẫu số	120 đơn có trạng thái giao hoàn tất trong 07/2026; loại đơn hủy trước giao
Công thức	102 / 120 × 100 = 85%
Grain, mức chi tiết dữ liệu	Một dòng cho một đơn giao hoàn tất; không cộng lặp theo dòng hàng
Kỳ đo	01/07/2026–31/07/2026, Asia/Ho_Chi_Minh
Nguồn logic	Đơn bán hàng, cam kết giao, xác nhận giao, trạng thái đơn; tên trường vật lý cần đối chiếu CANONICAL_DATA_DICTIONARY
Ngưỡng hiển thị	Chưa xác lập ngưỡng đạt/không đạt. Ngưỡng là quyết định nghiệp vụ, không suy ra từ 85%.
Chủ dữ liệu	Business Owner xác nhận ý nghĩa KPI; Data Owner xác nhận nguồn và chất lượng dữ liệu
Trạng thái	IN_REVIEW, v0.9.0, ngày 2026-08-07; không phải baseline hay approval

Options: Dùng ngày xuất kho; dùng ngày xác nhận giao; hoặc công bố cả hai KPI riêng. Decision Criteria: Mốc thời gian phải phản ánh sự kiện khách nhận hàng, áp dụng nhất quán, có dữ liệu truy vết. Decision: Đề xuất dùng ngày xác nhận giao cho KPI này; ngày xuất kho không thay thế vì chứng minh hàng rời kho, không chứng minh giao hoàn tất. Authority: Business Owner quyết định ý nghĩa nghiệp vụ; Data Owner xác nhận khả dụng dữ liệu; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết. Artifact: Bảng định nghĩa KPI trong tệp hiện hành, liên kết CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES. Consequence if Wrong: Tử số hoặc mẫu số sai làm 85% không còn so sánh được giữa kỳ, có thể dẫn tới quyết định vận hành sai.

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

flowchart TB
    A["Dữ liệu đơn bán hàng, cam kết giao, xác nhận giao và trạng thái đơn"] --> B{"Đơn hủy trước giao?"}
    B -->|Có| X["Loại khỏi mẫu số"]
    B -->|Không| C{"Giao hoàn tất trong 01/07/2026–31/07/2026 theo Asia/Ho_Chi_Minh?"}
    C -->|Không| X
    C -->|Có| D["Chuẩn hóa một dòng cho một đơn giao hoàn tất; không cộng lặp theo dòng hàng"]
    D --> E{"Ngày xác nhận giao không muộn hơn ngày cam kết giao?"}
    E -->|Không| H["Chỉ đếm mẫu số"]
    E -->|Có| F{"Số lượng xác nhận giao bằng số lượng đặt?"}
    F -->|Không| H
    F -->|Có| G["Đếm tử số và mẫu số"]
    G --> I["Tính KPI: 102 / 120 × 100 = 85%"]
    H --> I
    I --> Q["Chưa xác lập ngưỡng đạt hoặc không đạt; không suy ngưỡng từ 85%"]
    Q --> J["Business Owner xác nhận ý nghĩa KPI"]
    J --> K["Data Owner xác nhận nguồn, khả dụng và chất lượng dữ liệu theo CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES"]
    K --> R["Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết; không phê duyệt ý nghĩa KPI hoặc dữ liệu"]
    R --> L{"Có mâu thuẫn?"}
    L -->|Không| M["Ghi IN_REVIEW, v0.9.0, ngày 2026-08-07; không phải baseline hay approval"]
    L -->|Ý nghĩa KPI| N["Business Owner sửa ý nghĩa KPI"]
    L -->|Nguồn, khả dụng hoặc chất lượng dữ liệu| O["Data Owner sửa nguồn hoặc chất lượng dữ liệu"]
    N --> A
    O --> A
    D -.-> S["Nếu định nghĩa, tử số hoặc mẫu số sai: KPI mất khả năng so sánh giữa kỳ và có thể dẫn tới quyết định vận hành sai"]

Senior Lens

Điểm kiểm soát là quan hệ giữa sự kiện và KPI. “Giao hàng” phải chỉ rõ sự kiện nào tạo bằng chứng: xuất kho hay khách nhận. Nếu dữ liệu không có ngày xác nhận giao đáng tin cậy, không đổi định nghĩa im lặng; ghi chênh lệch, giữ trạng thái IN_REVIEW, chuyển Data Owner và Business Owner xem xét.

Quick Reference

Kiểm tra	Đạt khi
Tái lập	Người khác dùng cùng dữ liệu tính lại được 85%
Không đếm lặp	Một đơn chỉ vào mẫu số một lần
Truy vết	Thành phần dữ liệu tham chiếu CANONICAL_DATA_DICTIONARY
Thẩm quyền	Không gọi KPI là đã phê duyệt hoặc baseline
Nguồn	Thuật ngữ BA tham chiếu BABOK Guide; không suy diễn clause không có văn bản được cấp phép

6. Output thu ???c

Core

Output của hoạt động định nghĩa KPI là artifact có kiểm soát: tài liệu hoặc bản ghi lưu được cách đo, dữ liệu dùng, người chịu trách nhiệm và thay đổi theo thời gian. Output không phải dashboard đẹp; dashboard chỉ hiển thị. Bằng chứng để tính và diễn giải KPI nằm trong định nghĩa, quy tắc và dữ liệu tham chiếu.

Artifact tạo hoặc cập nhật	Owner	Status	Canonical ID hoặc định danh	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Bảng định nghĩa KPI trong /02-handbook/15-reporting-biometrics-and-kpi-definition.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Đường dẫn canonical: /02-handbook/15-reporting-biometrics-and-kpi-definition.md; KPI ID chỉ dùng khi đã đăng ký trong TRACEABILITY_ID_REGISTRY	Tên KPI, mục tiêu đo, công thức, tử số, mẫu số, đơn vị, kỳ đo, điều kiện bao gồm/loại trừ, owner nghiệp vụ, owner dữ liệu, nguồn dữ liệu	Mỗi sửa đổi phải ghi version, ngày Asia/Ho_Chi_Minh, người ghi nhận, trường thay đổi, lý do và ảnh hưởng đến số liệu lịch sử
Mục dữ liệu liên kết trong CANONICAL_DATA_DICTIONARY	Data Owner có thẩm quyền; Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết	IN_REVIEW	CANONICAL_DATA_DICTIONARY	Tên trường logic, ý nghĩa, kiểu dữ liệu, nguồn, quy tắc chất lượng, phân loại dữ liệu và liên kết KPI	Không đổi nghĩa trường hoặc nguồn dữ liệu im lặng; ghi phiên bản, lý do và KPI bị ảnh hưởng
Quy tắc tính liên kết trong CANONICAL_BUSINESS_RULES	Business Owner có thẩm quyền; Principal IT Business Analyst / Technical Curriculum Author duy trì truy vết	IN_REVIEW	CANONICAL_BUSINESS_RULES	Điều kiện nghiệp vụ, sự kiện kích hoạt, ngoại lệ, giả định và bên cần xác minh	Mỗi đổi quy tắc phải ghi tác động tới công thức, kỳ so sánh và số liệu đã tính
Đăng ký định danh và liên kết trong TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	TRACEABILITY_ID_REGISTRY	ID được cấp, loại artifact, nguồn canonical, liên kết tới KPI, quy tắc và dữ liệu	Không tái sử dụng ID; sửa liên kết phải giữ dấu vết ID cũ, ID mới, lý do và ngày đổi

IN_REVIEW nghĩa là artifact đang được kiểm tra có truy vết. Nó không nghĩa APPROVED, BASELINED, sẵn sàng production, đúng pháp lý hoặc được người dùng chấp thuận.

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

flowchart TB
    A["Bảng định nghĩa KPI<br/>Canonical: /02-handbook/15-reporting-biometrics-and-kpi-definition.md<br/>KPI ID chỉ dùng sau khi đăng ký trong TRACEABILITY_ID_REGISTRY<br/>Owner: Principal IT Business Analyst / Technical Curriculum Author<br/>Status: IN_REVIEW"]

    AH["Lịch sử thay đổi: định nghĩa KPI, dữ liệu, quy tắc và liên kết<br/>Version; ngày Asia/Ho_Chi_Minh; người ghi nhận<br/>trường thay đổi; lý do; ảnh hưởng số liệu lịch sử"]

    B["CANONICAL_DATA_DICTIONARY<br/>Owner dữ liệu: Data Owner có thẩm quyền<br/>Duy trì liên kết: Principal IT Business Analyst / Technical Curriculum Author<br/>Status: IN_REVIEW"]

    C["CANONICAL_BUSINESS_RULES<br/>Owner nghiệp vụ: Business Owner có thẩm quyền<br/>Duy trì liên kết: Principal IT Business Analyst / Technical Curriculum Author<br/>Status: IN_REVIEW"]

    D["TRACEABILITY_ID_REGISTRY<br/>Owner: Principal IT Business Analyst / Technical Curriculum Author<br/>Status: IN_REVIEW"]

    BI["Đổi nghĩa trường hoặc nguồn dữ liệu<br/>Không đổi im lặng<br/>Ghi version, lý do, KPI bị ảnh hưởng<br/>Tác động diễn giải KPI và so sánh lịch sử"]

    CI["Đổi quy tắc<br/>Ghi version; ngày Asia/Ho_Chi_Minh; người ghi nhận; lý do<br/>Ghi tác động công thức, kỳ so sánh, số liệu đã tính<br/>Tác động diễn giải KPI và so sánh lịch sử"]

    DI["Đổi liên kết<br/>Giữ ID cũ, ID mới, lý do, ngày đổi<br/>Không tái sử dụng ID"]

    N["IN_REVIEW không đồng nghĩa<br/>APPROVED, BASELINED, sẵn sàng production<br/>đúng pháp lý hoặc được người dùng chấp thuận"]

    A -->|"Liên kết KPI với trường logic, nguồn<br/>và quy tắc chất lượng"| B
    A -->|"Liên kết KPI với điều kiện, ngoại lệ<br/>và giả định tính"| C
    A -->|"Đăng ký KPI ID và liên kết artifact"| D
    A -->|"Mỗi sửa đổi phải ghi"| AH

    B -->|"Khi đổi nghĩa trường hoặc nguồn"| BI
    C -->|"Khi đổi quy tắc"| CI
    D -->|"Khi đổi liên kết KPI"| DI

    BI -->|"Cập nhật lịch sử thay đổi"| AH
    CI -->|"Cập nhật lịch sử thay đổi"| AH
    DI -->|"Cập nhật lịch sử thay đổi KPI"| AH

    A -.-> N
    B -.-> N
    C -.-> N
    D -.-> N

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, dùng vi-VN, Asia/Ho_Chi_Minh và VND.

Thành phần	Nội dung điền mẫu
Facts	Báo cáo giao hàng tháng 07/2026 hiển thị tỷ lệ giao đúng hạn và đủ hàng là 85%. Dữ liệu có 120 đơn hoàn tất, trong đó 102 đơn đạt cả ngày cam kết và số lượng đặt.
Current Behavior	Nhóm vận hành đọc 85% từ dashboard nhưng chưa có bản ghi thống nhất về trạng thái đơn được tính, ngày dùng để so sánh và cách xử lý giao thiếu.
Underlying Need	Cần artifact giúp người đọc tính lại 85%, biết dữ liệu nào tạo số liệu và phát hiện khi định nghĩa thay đổi giữa các kỳ.
Options	Ghi công thức trong dashboard; ghi công thức trong tài liệu tự do; duy trì bảng định nghĩa KPI có liên kết CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY.
Decision Criteria	Có thể tái lập; có owner; giữ lịch sử thay đổi; không tạo ID chưa đăng ký; không biến giả định mô phỏng thành quy định vận hành.
Decision	Duy trì bảng định nghĩa KPI trong tệp hiện hành; giữ trạng thái IN_REVIEW; chỉ dùng KPI ID sau khi TRACEABILITY_ID_REGISTRY ghi nhận.
Authority	Business Owner xác nhận ý nghĩa nghiệp vụ; Data Owner xác nhận dữ liệu; Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc và truy vết. Không vai trò nào trong ví dụ tự tạo approval.
Artifact	Bản ghi KPI: mục tiêu “đo đơn giao đúng hạn và đủ hàng”; công thức 102 / 120 × 100 = 85%; đơn vị %; kỳ đo 01/07/2026–31/07/2026; nguồn dữ liệu tổng hợp; liên kết CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Nếu 120 đơn bao gồm đơn chưa hoàn tất hoặc 102 đơn dùng ngày xuất kho thay vì ngày xác nhận giao, 85% không còn cùng nghĩa. So sánh kỳ, đánh giá vận hành và quyết định tiếp theo có thể sai.

Senior Lens

ID không phải nhãn trang trí. ID là khóa để nối một KPI với quy tắc, trường dữ liệu, thay đổi và bằng chứng review. Vì TRACEABILITY_ID_REGISTRY là nguồn canonical cho định danh, không tự đặt một ID như KPI-OTIF-001 trong tài liệu rồi gọi là canonical. Khi ID chưa được registry ghi nhận, giữ mô tả KPI và ghi rõ liên kết cần đăng ký.

Lịch sử thay đổi phải trả lời được bốn câu hỏi: ai đổi, đổi gì, đổi khi nào và vì sao đổi. Ví dụ, đổi “ngày xác nhận giao” thành “ngày xuất kho” làm thay đổi ý nghĩa KPI, không chỉ thay đổi câu chữ. Bản ghi thay đổi phải nêu kỳ số liệu bị ảnh hưởng và không được ghi đè lịch sử cũ.

Quick Reference

Quy tắc	Áp dụng
Một KPI, một định nghĩa kiểm soát	Không để dashboard, email và bảng tính giữ ba công thức khác nhau
Một ID, một nguồn registry	Chỉ TRACEABILITY_ID_REGISTRY cấp và duy trì định danh canonical
Một thay đổi, một dấu vết	Ghi version, ngày, người ghi nhận, lý do và tác động
Owner khác authority	Owner duy trì artifact; Business Owner và Data Owner xác nhận phần thuộc thẩm quyền của họ
Mô phỏng không thành cam kết	Nova Foods và số liệu 102, 120, 85% chỉ là dữ liệu tổng hợp giáo dục

Core

Output của hoạt động định nghĩa báo cáo, biometrics và KPI là bộ artifact có thể đọc, kiểm tra và truy vết. Anatomy là cấu tạo tối thiểu của từng artifact: ID, tên, mục tiêu đo, công thức, nguồn dữ liệu, quy tắc lọc, tần suất, đơn vị, chiều phân tích, ngưỡng diễn giải, giả định và liên kết nguồn. Thiếu một phần, người đọc có thể cùng nhìn một con số nhưng hiểu khác nghĩa.

Artifact ID	Artifact	Anatomy bắt buộc	Mục đích
KPI-DEF-NF-001	KPI Definition Card	KPI ID, tên, câu hỏi nghiệp vụ, công thức, tử số, mẫu số, đơn vị, tần suất, chiều phân tích, ngưỡng, nguồn	Khóa nghĩa chỉ số trước khi dựng báo cáo
RPT-SPEC-NF-001	Report Specification	Report ID, người dùng mục tiêu, KPI hiển thị, bộ lọc, cột, sắp xếp, lịch chạy, định dạng, xử lý không có dữ liệu	Mô tả báo cáo cần tạo
DATA-MAP-NF-001	KPI Data Mapping	KPI ID, trường nguồn, entity logic, phép biến đổi, điều kiện lọc, chất lượng dữ liệu, giả định	Nối công thức với dữ liệu ERP
KPI-TRACE-NF-001	KPI Traceability Matrix	KPI ID, câu hỏi nghiệp vụ, report ID, data mapping ID, rule/assumption ID, kiểm tra đối chiếu	Chứng minh chuỗi từ nhu cầu đến số đo

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

flowchart TB
    A[Câu hỏi nghiệp vụ] --> B[KPI-DEF-NF-001]
    B --> C[DATA-MAP-NF-001]
    B --> D[RPT-SPEC-NF-001]
    B --> E[KPI-TRACE-NF-001]
    C --> E
    D --> E
    F[Rule/assumption ID] --> E
    G[Kiểm tra đối chiếu] --> E

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Toàn bộ số liệu dưới đây là dữ liệu tổng hợp, đơn vị tiền tệ VND.

Mục	Nội dung
Facts	Bộ phận Kinh doanh cần biết giá trị đơn hàng giao đủ trong tháng 07/2026. Dữ liệu mô phỏng có đơn hàng, dòng đơn hàng, lượng đặt và lượng giao.
Current Behavior	Nhân viên xuất danh sách giao hàng rồi cộng thủ công. Đơn giao một phần vẫn có thể bị cộng như giao đủ.
Underlying Need	Cần một chỉ số thống nhất để phân biệt đơn giao đủ với đơn giao thiếu.
Options	1. Đếm mọi đơn có ít nhất một lần giao. 2. Đếm đơn có tổng lượng giao bằng tổng lượng đặt.
Decision Criteria	Chỉ số phải phản ánh đúng nghĩa “giao đủ”, kiểm tra được từ lượng đặt và lượng giao, không cần suy đoán trạng thái đơn.
Decision	Chọn phương án 2. Một đơn giao đủ khi tổng DeliveredQuantity bằng tổng OrderedQuantity tại thời điểm chốt báo cáo.
Authority	Đây là quyết định học liệu mô phỏng. Business Owner Nova Foods thực tế phải xác nhận nghĩa “giao đủ” trước khi dùng vận hành.
Artifact	KPI-DEF-NF-001, RPT-SPEC-NF-001, DATA-MAP-NF-001, KPI-TRACE-NF-001.
Consequence if Wrong	Nếu cộng đơn giao thiếu là giao đủ, tỷ lệ giao đủ bị tăng sai; quản lý có thể đánh giá sai năng lực giao hàng.

KPI-DEF-NF-001 — Filled KPI Definition Card

Trường	Giá trị
KPI ID	KPI-NF-OTIF-001
Tên KPI	Tỷ lệ đơn hàng giao đủ
Câu hỏi nghiệp vụ	Trong tháng báo cáo, bao nhiêu phần trăm đơn hàng đã giao đủ số lượng khách đặt?
Đối tượng đo	Đơn hàng bán mô phỏng có ngày yêu cầu giao trong kỳ
Tử số	Số đơn có tổng lượng giao bằng tổng lượng đặt
Mẫu số	Tổng số đơn có ngày yêu cầu giao trong kỳ
Công thức	(Số đơn giao đủ / Tổng số đơn yêu cầu giao trong kỳ) × 100
Đơn vị	%
Tần suất	Hàng tháng
Kỳ báo cáo	2026-07-01 đến 2026-07-31, Asia/Ho_Chi_Minh
Chiều phân tích	Kho hàng, khách hàng, nhóm sản phẩm
Điều kiện bao gồm	Đơn có RequestedDeliveryDate trong kỳ và OrderStatus khác Cancelled
Điều kiện loại trừ	Đơn bị hủy; dòng hàng có OrderedQuantity = 0
Giá trị khi mẫu số bằng 0	Hiển thị N/A; không hiển thị 0%, vì không có đơn để đo
Ngưỡng diễn giải mô phỏng	Xanh: >= 95%; vàng: từ 90% đến < 95%; đỏ: < 90%
Nguồn dữ liệu logic	SalesOrder, SalesOrderLine, DeliveryLine
Giả định	Một đơn chỉ được tính giao đủ khi mọi dòng hàng có tổng lượng giao bằng tổng lượng đặt. Verification required với Business Owner thực tế.

DATA-MAP-NF-001 — Filled KPI Data Mapping

Map ID	KPI ID	Entity logic	Trường nguồn	Biến đổi/quy tắc
MAP-NF-OTIF-001	KPI-NF-OTIF-001	SalesOrder	SalesOrderID	Khóa nhóm đơn hàng
MAP-NF-OTIF-002	KPI-NF-OTIF-001	SalesOrder	RequestedDeliveryDate	Lọc từ 2026-07-01 đến 2026-07-31
MAP-NF-OTIF-003	KPI-NF-OTIF-001	SalesOrder	OrderStatus	Loại Cancelled
MAP-NF-OTIF-004	KPI-NF-OTIF-001	SalesOrderLine	OrderedQuantity	Cộng theo SalesOrderID; loại dòng bằng 0
MAP-NF-OTIF-005	KPI-NF-OTIF-001	DeliveryLine	DeliveredQuantity	Cộng theo SalesOrderID và dòng đơn hàng
MAP-NF-OTIF-006	KPI-NF-OTIF-001	Derived	IsCompleteDelivery	true khi tổng giao của mọi dòng bằng tổng đặt của mọi dòng

RPT-SPEC-NF-001 — Filled Report Specification

Trường	Giá trị
Report ID	RPT-NF-OTIF-001
Tên báo cáo	Báo cáo tỷ lệ đơn hàng giao đủ tháng
KPI hiển thị	KPI-NF-OTIF-001
Bộ lọc bắt buộc	Kỳ báo cáo
Bộ lọc tùy chọn	Kho hàng, khách hàng, nhóm sản phẩm
Cột chi tiết	SalesOrderID, RequestedDeliveryDate, WarehouseID, CustomerID, OrderedQuantity, DeliveredQuantity, IsCompleteDelivery
Sắp xếp mặc định	RequestedDeliveryDate tăng dần, SalesOrderID tăng dần
Định dạng KPI	Phần trăm, hai chữ số thập phân
Không có dữ liệu	Hiển thị N/A và thông báo Không có đơn hàng thuộc phạm vi lọc
Dữ liệu minh họa	SO-NF-202607-001: đặt 100, giao 100, giao đủ; SO-NF-202607-002: đặt 80, giao 60, giao thiếu; SO-NF-202607-003: đặt 50, giao 50, giao đủ
Kết quả minh họa	Tử số 2; mẫu số 3; KPI (2 / 3) × 100 = 66.67%

Senior Lens

Công thức phải khóa grain — mức hạt dữ liệu. KPI này đo ở mức đơn hàng, không phải mức dòng hàng. Bằng chứng: câu hỏi hỏi “bao nhiêu phần trăm đơn hàng”, còn một đơn nhiều dòng chỉ đạt khi toàn bộ dòng giao đủ. Nếu đổi sang mức dòng hàng, tử số và mẫu số đổi nghĩa; cùng tên KPI sẽ tạo kết quả sai.

KPI-TRACE-NF-001 phải nối đủ bốn điểm: nhu cầu NED-NF-OTIF-001, KPI KPI-NF-OTIF-001, báo cáo RPT-NF-OTIF-001, mapping DATA-MAP-NF-001. Liên kết này cho phép reviewer lần ngược từ số 66.67% về ba đơn mô phỏng và điều kiện tính.

Quick Reference

Kiểm tra anatomy	Đạt khi
Nghĩa KPI	Một người đọc xác định được tử số, mẫu số, kỳ và đơn vị
Grain	Nêu rõ đo theo đơn, dòng, khách hàng hay ngày
Nguồn dữ liệu	Mỗi biến trong công thức có trường nguồn hoặc biến đổi tương ứng
Biên dữ liệu	Có quy tắc hủy đơn, số lượng bằng 0, giao một phần và mẫu số bằng 0
Ví dụ tính	Có đủ dữ liệu đầu vào và kết quả tính lại được
Truy vết	KPI, report và data mapping dùng đúng ID liên kết

Core

Quality gate là cổng kiểm tra chất lượng trước khi output được chuyển sang downstream review, tức review bởi vai trò nhận artifact ở bước kế tiếp. Cổng này kiểm tra tính đủ, nhất quán, truy vết được và giới hạn thẩm quyền. Cổng không phê duyệt nội dung, không tạo baseline, không xác nhận production-ready.

Điều kiện gate	Bằng chứng bắt buộc	Kết quả nếu thiếu
Định danh giữ nguyên	Canonical ID, tên tệp, source classification và liên kết upstream không bị đổi	RETURN_FOR_REWORK
Metadata khớp corpus	Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND khi có số tiền	RETURN_FOR_REWORK
Dữ liệu có nguồn	Mỗi metric, trường dữ liệu, giả định và suy luận có evidence/reasoning bridge	RETURN_FOR_REWORK
Ranh giới nguồn rõ	Nguồn verified, project assumption và Verification required được gắn nhãn đúng	RETURN_FOR_REWORK
Không vượt thẩm quyền	Không gọi nội dung là legal, accounting, tax, compliance, approval hoặc production decision	ESCALATE
Lịch sử thay đổi có mặt	Có dòng ghi thay đổi, ngày, người ghi nhận, phạm vi thay đổi và lý do	RETURN_FOR_REWORK
Không có lỗi kiểm soát	Không có TODO, TBD, ellipsis, omitted rows, fabricated quotation hoặc fabricated clause	RETURN_FOR_REWORK

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

flowchart TB
    A[Output được soạn hoặc cập nhật] --> B[Kiểm tra Canonical ID, tên tệp, source classification, liên kết upstream]
    B --> C[Kiểm tra metadata: IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND khi có số tiền]
    C --> D[Kiểm tra metric, trường dữ liệu, giả định, suy luận có evidence/reasoning bridge]
    D --> E[Kiểm tra source boundary: verified source, project assumption, Verification required]
    E --> F[Kiểm tra authority, change history: ngày, người ghi nhận, phạm vi, lý do]
    F --> G[Kiểm tra không có TODO, TBD, ellipsis, omitted rows, fabricated quotation, fabricated clause]
    G --> H{Kết quả kiểm tra?}
    H -->|Đủ điều kiện| I[READY_FOR_DOWNSTREAM_REVIEW<br/>Vẫn IN_REVIEW; không phê duyệt, baseline hoặc production]
    H -->|Thiếu bằng chứng hoặc lỗi kiểm soát| J[RETURN_FOR_REWORK]
    H -->|Vượt thẩm quyền| K[ESCALATE]

READY_FOR_DOWNSTREAM_REVIEW chỉ có nghĩa reviewer có đủ vật liệu để đánh giá. Trạng thái này không thay IN_REVIEW, không hàm ý user approval, không tạo baseline, không cho phép cấu hình ERP Nova Foods mô phỏng hay dùng production.

Applied

Mục	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Facts	Output reporting nêu doanh thu tháng theo kênh bán, đơn vị tiền tệ VND, dữ liệu tổng hợp.
Current Behavior	Bản soạn có bảng KPI nhưng chưa phân biệt số liệu nguồn với project assumption.
Underlying Need	Reviewer cần biết số nào kiểm tra được từ nguồn, số nào cần Business Owner hoặc Accounting Owner xác minh.
Options	1. Chuyển bản soạn ngay. 2. Gắn nhãn nguồn và giả định trước khi chuyển.
Decision Criteria	Traceability đủ, không diễn giải kế toán, metadata khớp corpus, không có claim approval.
Decision	Chọn phương án 2. Bằng chứng: thiếu nhãn làm reviewer không thể phân biệt fact với inference.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact; Accounting Owner hoặc Business Owner xác minh nội dung thuộc thẩm quyền của họ.
Artifact	/02-handbook/15-reporting-biometrics-and-kpi-definition.md, Status IN_REVIEW, Version v0.9.0.
Consequence if Wrong	Reviewer có thể hiểu project assumption là số liệu kế toán hoặc quyết định vận hành; traceability bị đứt và phải rework.

Quality gate đạt khi bảng KPI ghi rõ nguồn của từng con số, giả định được nhãn Project assumption, nội dung cần chuyên môn kế toán ghi Verification required, và change history ghi ngày 2026-08-07 theo Asia/Ho_Chi_Minh. Gate không xác nhận KPI đúng cho Nova Foods thực tế.

Senior Lens

Senior BA không dùng quality gate để “làm đẹp” artifact. Gate tồn tại để giảm chi phí review: reviewer tìm được nguồn, hiểu phạm vi và biết điểm nào phải escalation. Nếu một metric dùng thuật ngữ doanh thu, giá vốn, thuế, hóa đơn, truy xuất thực phẩm hoặc dữ liệu cá nhân, BA phải giữ nhãn Verification required khi chưa có xác minh từ owner có thẩm quyền. Evidence không đủ thì trả về rework; thẩm quyền không đúng thì escalation; không tự điền kết luận để làm gate qua.

Quick Reference

Kết quả gate	Ý nghĩa
READY_FOR_DOWNSTREAM_REVIEW	Đủ bằng chứng để review tiếp; chưa approved, chưa baselined, chưa production-ready.
RETURN_FOR_REWORK	Thiếu metadata, traceability, nhãn giả định, change history hoặc có lỗi kiểm soát.
ESCALATE	Nội dung cần quyết định Business Owner, Accounting Owner, Legal Owner, Security, Architect hoặc QA.

7. Who consumes those outputs?

Core

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên KPI, report và dữ liệu là dữ liệu tổng hợp. Output của BA không chỉ để “đọc”. Mỗi vai trò dùng cùng artifact theo mục đích khác nhau. Ví dụ, KPI definition là định nghĩa chỉ số: công thức, đơn vị, kỳ đo, nguồn dữ liệu và phạm vi. Developer dùng để xây logic; QA dùng để kiểm thử; Business Owner dùng để đọc đúng ý nghĩa quản trị.

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

flowchart TB
    KPI[KPI definition]
    DEV[Developer]
    QA[QA]
    BO[Business Owner]

    KPI -->|xây logic| DEV
    KPI -->|kiểm thử| QA
    KPI -->|đọc ý nghĩa quản trị| BO

Applied

Consumer	Output họ dùng	Cách tiêu thụ cụ thể
Developer	KPI definition, report specification, data-source mapping, acceptance criteria	Chuyển công thức KPI thành logic truy vấn, API, batch job hoặc màn hình. Dùng mapping để biết trường nguồn, khóa liên kết, thời điểm chốt dữ liệu và đơn vị VND.
QA	KPI definition, acceptance criteria, ví dụ dữ liệu tổng hợp	Tạo test basis, tức cơ sở để thiết kế test. So sánh kết quả report với công thức, điều kiện lọc, kỳ báo cáo, quy tắc làm tròn và dữ liệu đầu vào.
Architect	Data-source mapping, report specification, non-functional constraints	Đánh giá luồng dữ liệu, ownership hệ thống nguồn, tích hợp, hiệu năng, phân quyền và khả năng truy vết. Không dùng KPI definition để tự quyết định chính sách nghiệp vụ.
PM/Product Owner	KPI definition, report specification, phạm vi phát hành	Sắp xếp ưu tiên backlog, xác định phạm vi release và kiểm tra output có phục vụ mục tiêu sản phẩm không. Dùng định nghĩa để tránh ưu tiên report có tên giống nhau nhưng nghĩa khác.
Business Owner	KPI definition, report mockup hoặc report specification	Đọc ý nghĩa quản trị của chỉ số: chỉ số đo gì, dùng kỳ nào, loại giao dịch nào được tính. Đây là consumer chính của giá trị nghiệp vụ, không phải người tự suy diễn nguồn dữ liệu kỹ thuật.
Operations	Report specification, lịch làm mới, data-source mapping mức vận hành	Chuẩn bị quy trình chạy report, xử lý dữ liệu đến muộn, theo dõi lỗi tải dữ liệu và hỗ trợ người dùng. Họ cần biết report nào phụ thuộc dữ liệu nào để khoanh vùng sự cố.
Specialist owners	KPI definition theo chuyên môn	Accounting Owner, Sales Owner, Supply Chain Owner, Food Safety Owner hoặc Privacy/Security Owner xem phần thuộc chuyên môn. Ví dụ, Accounting Owner xem thuật ngữ doanh thu hoặc giá vốn; nội dung này vẫn là Verification required nếu chưa được owner có thẩm quyền xác minh.

Facts: Report “Doanh thu thuần theo tháng” dùng đơn vị VND, kỳ tháng dương lịch, dữ liệu tổng hợp Nova Foods.
Current Behavior: Developer có công thức; QA chỉ có tên report; Operations không biết dữ liệu được làm mới khi nào.
Underlying Need: Cùng một KPI phải được xây, test, vận hành và đọc theo cùng nghĩa.
Options: Gửi một ảnh report; hoặc gửi KPI definition, report specification, data-source mapping và acceptance criteria liên kết nhau.
Decision Criteria: Consumer phải tìm được mục đích dùng artifact mà không tự đoán công thức, nguồn hoặc kỳ đo.
Decision: Dùng bộ artifact liên kết; mỗi output ghi consumer chính và consumer phụ.
Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì traceability; nội dung nghiệp vụ, kế toán, pháp lý, bảo mật và kiến trúc thuộc owner chuyên môn tương ứng.
Artifact: /02-handbook/15-reporting-biometrics-and-kpi-definition.md, Status IN_REVIEW, Version v0.9.0.
Consequence if Wrong: Developer có thể tính khác QA test; Business Owner đọc sai KPI; Operations không khoanh vùng được lỗi dữ liệu.

Senior Lens

Một report có thể có nhiều consumer, nhưng không có nhiều nguồn chân lý. KPI definition là nguồn nghĩa; report specification là nguồn hành vi hiển thị; data-source mapping là nguồn liên kết dữ liệu; acceptance criteria là nguồn kiểm tra mong đợi. Khi cùng một câu hỏi xuất hiện ở nhiều artifact, BA phải liên kết về artifact canonical thay vì chép lại rồi để các bản lệch nhau.

Quick Reference

Output	Consumer chính	Consumer phụ
KPI definition	Business Owner, Developer, QA	PM/Product Owner, specialist owners
Report specification	Developer, Business Owner	Operations, PM/Product Owner
Data-source mapping	Developer, Architect, Operations	QA
Acceptance criteria	QA, Developer	PM/Product Owner, Business Owner

Core

Mỗi đầu ra định nghĩa báo cáo, chỉ số sinh học nghiệp vụ (biometrics) và KPI phải cho người nhận biết: họ được quyết gì, phải nhìn bằng chứng nào, và khi nào không được tự quyết. Nova Foods Trading & Manufacturing là mô phỏng giáo dục; mọi số 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.

Người nhận	Có thể quyết	Bằng chứng phải có	Phải escalation khi
Developer	Cách tính, truy vấn, API, lịch chạy và hiển thị theo định nghĩa đã khóa	Công thức KPI, trường dữ liệu từ CANONICAL_DATA_DICTIONARY, quy tắc từ CANONICAL_BUSINESS_RULES, tiêu chí chấp nhận	Công thức thiếu mẫu dữ liệu, trường nguồn mâu thuẫn, yêu cầu làm lộ dữ liệu cá nhân hoặc cần thay đổi kiến trúc
QA	Test basis, dữ liệu kiểm thử tổng hợp, ca biên và kết quả mong đợi	Định nghĩa KPI, điều kiện lọc, mẫu tính tay, traceability ID, tiêu chí chấp nhận	Không xác định được kết quả đúng, quy tắc nghiệp vụ mâu thuẫn, dữ liệu test chạm dữ liệu thật
Architect	Mẫu tích hợp, quyền truy cập, hiệu năng, lưu trữ và đường dữ liệu	Nguồn dữ liệu, tần suất làm mới, khối lượng dự kiến, phân loại dữ liệu, ràng buộc API	Cần kết nối hệ thống mới, vượt ngưỡng hiệu năng, có dữ liệu nhạy cảm, xung đột chuẩn kiến trúc hoặc bảo mật
PM/Product Owner	Ưu tiên phạm vi, thứ tự giao và tiêu chí hoàn thành sản phẩm	Giá trị nghiệp vụ, người dùng mục tiêu, phụ thuộc, rủi ro, ước lượng	Đổi phạm vi, xung đột ưu tiên, cần đổi thời hạn hoặc tác động cam kết sản phẩm
Business Owner	Ý nghĩa quản trị, ngưỡng cảnh báo, hành động khi KPI lệch	Mục tiêu nghiệp vụ, giả định đo lường, mẫu kết quả, tác động quyết định	Ngưỡng ảnh hưởng doanh thu, chính sách bán hàng, trách nhiệm đơn vị hoặc quy tắc nghiệp vụ chưa rõ
Operations Owner	Quy trình theo dõi, lịch xử lý ngoại lệ, phân công phản ứng	Tần suất cập nhật, ngưỡng, danh sách ngoại lệ, hướng dẫn vận hành	KPI yêu cầu thay đổi ca làm, quy trình kho, quy trình sản xuất hoặc tạo rủi ro gián đoạn
Specialist Owner: Accounting, Legal, Security, Food Safety	Diễn giải phần thuộc chuyên môn được giao	Nguồn chính thức, phân loại dữ liệu, luồng xử lý, rule và tác động	Có diễn giải 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 chưa được xác minh

CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đang IN_REVIEW; chúng là đầu vào kiểm soát, không phải xác nhận quy tắc Nova Foods đã được phê duyệt. Nội dung pháp lý, kế toán, quyền riêng tư và an toàn thực phẩm phải giữ nhãn Verification required nếu chưa được owner chuyên môn xác minh theo nguồn chính thức.

Applied

Mục	Nội dung
Facts	Báo cáo mô phỏng KPI-OTIF-01 hiển thị tỷ lệ giao đủ và đúng hẹn cho đơn giao hàng. Dữ liệu tổng hợp có OrderID, PromisedDeliveryDate, ActualDeliveryDate, DeliveredQuantity, OrderedQuantity.
Current Behavior	Developer hiểu “đúng hẹn” là ActualDeliveryDate <= PromisedDeliveryDate. Operations Owner hiểu ngày giao phải theo thời điểm xe đến kho khách. Hai cách hiểu có thể khác nếu hệ thống ghi nhận lúc xác nhận chứng từ.
Underlying Need	Business Owner cần một KPI để quyết định nơi cần xử lý chậm giao. Vì KPI dẫn tới quyết định quản trị, mốc thời gian phải phản ánh sự kiện nghiệp vụ được chọn, không phải trường dữ liệu thuận tiện nhất.
Options	Dùng thời điểm xác nhận chứng từ; dùng thời điểm xe đến kho khách; tách hai KPI để quan sát cả chứng từ và giao thực tế.
Decision Criteria	Sự kiện có thể kiểm chứng, nguồn dữ liệu ổn định, phù hợp mục đích quản trị, không che giấu độ trễ giữa giao thực tế và ghi nhận chứng từ.
Decision	Không tự chọn trường. Ghi nhận hai lựa chọn và yêu cầu Business Owner xác định sự kiện đo lường; Architect xác nhận khả năng lấy dữ liệu; QA chuẩn bị ca kiểm thử cho trường hợp hai thời điểm khác nhau.
Authority	Business Owner quyết ý nghĩa nghiệp vụ. Architect quyết khả thi kỹ thuật. QA quyết đủ test basis. BA duy trì truy vết và gói escalation.
Artifact	Định nghĩa KPI-OTIF-01, liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, tiêu chí chấp nhận và log quyết định đang IN_REVIEW.
Consequence if Wrong	Báo cáo có thể báo tỷ lệ giao đúng hẹn cao giả tạo; Operations Owner xử lý sai điểm nghẽn; PM/Product Owner ưu tiên sai hạng mục.

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

flowchart TB
    A[BA: Trình bày lựa chọn] --> B{BO: Chọn sự kiện đo?}
    B -- Ý nghĩa rõ --> C[Log quyết định IN_REVIEW]
    B -- Ý nghĩa chưa rõ --> G[BA: Gói escalation]

    subgraph "Khảo sát & Chuẩn bị"
        C --> C_Arch{Architect: Khả thi dữ liệu?}
        C --> C_QA[QA: Chuẩn bị test basis]
    end

    C_Arch -- Không khả thi --> B

    subgraph "Xây dựng & Kiểm thử"
        direction TB
        D_Join((Sẵn sàng))
        C_Arch -- Khả thi --> D_Join
        C_QA --> D_Join
        D_Join --> E[Dev: Xây dựng]
        E --> F{QA: Kiểm thử}
        F -- Sai --> E
    end

    F -- Đúng --> H[Ops: Dùng KPI]

Senior Lens

Escalation không phải chuyển trách nhiệm. BA phải gửi gói bằng chứng đủ để owner quyết: câu hỏi quyết định, hai hoặc nhiều lựa chọn, trường dữ liệu bị ảnh hưởng, ví dụ dữ liệu tổng hợp, rủi ro nếu chọn sai và traceability ID. Không dùng cụm “theo thông lệ” thay cho bằng chứng. Với dữ liệu cá nhân, thuế, kế toán, an toàn thực phẩm hoặc truy xuất nguồn gốc, chỉ owner chuyên môn mới kết luận; nguồn pháp lý trong corpus chỉ xác định phạm vi cần xác minh, không thay thế tư vấn pháp lý hay thẩm quyền vận hành.

Quick Reference

Tình huống	Quy tắc xử lý
Developer có hai trường đều có thể tính KPI	Escalate cho Business Owner chọn ý nghĩa sự kiện; Architect xác nhận trường khả dụng
QA không tính được expected result độc lập	Chặn test execution cho KPI đó; yêu cầu công thức, điều kiện lọc và mẫu tính tay
PM/Product Owner muốn giao nhanh dù ngưỡng KPI chưa rõ	Ghi rủi ro phạm vi; Business Owner quyết ngưỡng hoặc loại ngưỡng khỏi phạm vi hiện tại
Specialist Owner thấy tác động pháp lý hoặc chuyên môn	Gắn Verification required; không chuyển suy đoán thành rule hay cấu hình ERP

Core

Handoff là chuyển giao đầu ra giữa vai trò, không phải chuyển trách nhiệm suy đoán. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, lỗi thường phát sinh khi người nhận đọc cùng thuật ngữ nhưng hiểu khác phạm vi, đơn vị đo, thời điểm chốt hoặc thẩm quyền quyết định. Bằng chứng cần là artifact nguồn có định danh, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không suy diễn IN_REVIEW thành đã baseline hay đã phê duyệt.

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

flowchart TB
    BA[BA gửi KPI definition] --> R[Đối chiếu artifact nguồn:<br/>định danh, `IN_REVIEW`, `v0.9.0`, `2026-08-07`]
    R --> S[`IN_REVIEW` không phải baseline<br/>hoặc đã phê duyệt]
    S --> Q{Rõ công thức, phạm vi,<br/>đơn vị đo, thời điểm,<br/>owner và thẩm quyền quyết định?}
    Q -- Có --> U[Dùng artifact trong phạm vi vai trò<br/>và trạng thái hiện tại]
    Q -- Không --> C[Đặt câu hỏi làm rõ chính xác]
    C --> D{Câu hỏi cần quyết định<br/>vượt thẩm quyền người nhận hoặc BA?}
    D -- Không --> BA
    D -- Có --> E[Escalate tới owner có thẩm quyền:<br/>Architect, PM/Product Owner,<br/>Business Owner hoặc specialist owner]
    E --> R

Hiểu nhầm khi handoff	Rủi ro cụ thể	Câu hỏi làm rõ phải dùng
Developer hiểu “doanh thu” là tổng giá trị đơn hàng tạo mới; BA đang nói doanh thu đã ghi nhận.	API, truy vấn hoặc dashboard tính sai tập dữ liệu.	“KPI này tính từ thời điểm tạo đơn, giao hàng, xuất hóa đơn hay ghi nhận kế toán? Hãy chỉ rõ trường ngày và trạng thái chứng từ được dùng.”
QA xem “theo tháng” là tháng dương lịch; nghiệp vụ có thể cần kỳ chốt khác.	Test pass sai kỳ; báo cáo lệch kỳ quản trị.	“Tháng KPI dùng từ 00:00 ngày nào đến 23:59:59 ngày nào theo Asia/Ho_Chi_Minh, và có quy tắc khóa sổ nào không?”
Architect hiểu dữ liệu báo cáo được đọc trực tiếp từ ERP; BA chỉ mô tả nhu cầu nghiệp vụ.	Thiết kế tích hợp tự suy diễn nguồn dữ liệu, độ trễ, quyền truy cập.	“Nguồn dữ liệu logic đã được xác định trong CANONICAL_DATA_DICTIONARY chưa? Nếu chưa, đây là giả định kiến trúc cần Architect quyết định hay chỉ là yêu cầu báo cáo?”
PM/Product Owner xem chỉ số là cam kết phạm vi sprint.	Đội phát triển bắt đầu khi tiêu chí chưa đủ hoặc chưa có quyết định ưu tiên.	“Chỉ số này đang là nhu cầu được mô tả, mục tiêu release hay hạng mục đã ưu tiên? Artifact nào ghi nhận quyết định ưu tiên?”
Business Owner nói “tỷ lệ hủy thấp” nhưng không nêu ngưỡng.	Không có acceptance criteria kiểm chứng.	“Ngưỡng ‘thấp’ là bao nhiêu phần trăm, mẫu số là gì, và ai có thẩm quyền xác nhận ngưỡng đó?”
Operations hiểu báo cáo gần thời gian thực; đầu ra chỉ nêu báo cáo ngày.	Thiết kế lịch chạy, nhân sự xử lý sự cố, kỳ vọng SLA sai.	“Dữ liệu cần cập nhật theo sự kiện, theo giờ hay theo ngày? Thời điểm dữ liệu được xem là hoàn tất là khi nào?”
Specialist owner về kế toán, pháp lý, an toàn thực phẩm hoặc dữ liệu cá nhân bị yêu cầu xác nhận ngoài thẩm quyền.	Diễn giải sai nghĩa vụ; dùng nội dung học liệu như quyết định vận hành.	“Nội dung này là giả định dự án hay yêu cầu phải xác minh? Owner chuyên môn nào xác nhận trước khi chuyển thành quy tắc triển khai?”

Applied

Facts: Nova Foods mô phỏng có KPI “Tỷ lệ hoàn tất giao hàng đúng hẹn”. Mô tả hiện có nói: số đơn giao đúng hẹn chia tổng đơn giao trong tháng. Không nêu “đúng hẹn” so với ngày hứa giao nào, trạng thái nào được tính là đã giao, hay cách xử lý giao nhiều đợt.

Current Behavior: Developer chuẩn bị dùng delivery_date <= promised_date trên mọi dòng giao hàng. QA chuẩn bị tạo test theo đơn hàng. Operations hiểu báo cáo phản ánh từng chuyến giao. Ba cách hiểu dùng ba đơn vị tính khác nhau: dòng giao hàng, đơn hàng và chuyến giao.

Underlying Need: Cần một định nghĩa có thể kiểm tra. Lý do: tử số và mẫu số chỉ so sánh được khi cùng đơn vị đo, cùng phạm vi và cùng thời điểm chốt.

Options: (1) Tính theo đơn hàng: đơn hoàn tất khi toàn bộ số lượng đã giao. (2) Tính theo dòng giao hàng: từng dòng được đánh giá riêng. (3) Tính theo chuyến giao: từng chuyến được đánh giá riêng.

Decision Criteria: Chọn đơn vị đo phải khớp câu hỏi quản trị cần trả lời; phải xác định được từ dữ liệu logic; phải tạo được dữ liệu test; không được suy diễn nghĩa vụ kế toán, pháp lý hay SLA vận hành.

Decision: Chưa chọn phương án. Artifact hiện ở IN_REVIEW, v0.9.0; không có bằng chứng về đơn vị đo được Business Owner xác nhận.

Authority: Business Owner quyết định mục tiêu nghiệp vụ và đơn vị đo. Operations cung cấp bằng chứng quy trình giao thực tế. Architect xác nhận khả năng truy xuất dữ liệu. QA xác nhận khả năng kiểm thử. BA ghi nhận câu hỏi, nguồn và traceability; không tự chọn thay các vai trò này.

Artifact: Cập nhật định nghĩa KPI chỉ sau khi có câu trả lời được ghi nhận trong artifact kiểm soát; tham chiếu dữ liệu logic giữ tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md, quy tắc nghiệp vụ giữ tại /01-curriculum/CANONICAL_BUSINESS_RULES.md.

Consequence if Wrong: Dashboard có thể báo tỷ lệ cao theo dòng giao hàng nhưng Operations vẫn có đơn giao thiếu. PM/Product Owner có thể ưu tiên sai. QA có thể xác nhận sản phẩm khớp công thức kỹ thuật nhưng không khớp nhu cầu nghiệp vụ.

Senior Lens

Không hỏi “Anh/chị xác nhận giúp em KPI này đúng không?” vì câu hỏi cho phép xác nhận mơ hồ. Hỏi thành phần có thể quyết định và kiểm chứng: “Mẫu số gồm đơn nào?”, “Sự kiện nào chốt kết quả?”, “Ngoại lệ nào bị loại?”, “Ai quyết định ngoại lệ?”. Cầu nối suy luận là: KPI là phép đo; phép đo cần tập đối tượng, điều kiện đưa vào, công thức và thời điểm; thiếu một phần thì hai người có thể cùng nói “đúng” nhưng tạo kết quả khác.

Escalate khi câu trả lời làm thay đổi nguồn dữ liệu, định nghĩa trạng thái, quyền truy cập, cách xử lý dữ liệu cá nhân, diễn giải kế toán, nghĩa vụ pháp lý hoặc truy xuất an toàn thực phẩm. Các nội dung pháp lý, kế toán, dữ liệu cá nhân và an toàn thực phẩm trong Nova Foods mô phỏng cần Verification required bởi owner có thẩm quyền; handbook không thay thế kết luận chuyên môn.

Quick Reference

Trước khi nhận handoff	Câu hỏi chặn hiểu nhầm
Tên KPI	“Tên này đo kết quả nghiệp vụ nào, không phải chỉ đo trường dữ liệu nào?”
Phạm vi	“Đối tượng nào vào mẫu số, đối tượng nào bị loại và vì sao?”
Công thức	“Tử số, mẫu số, đơn vị đo, quy tắc làm tròn là gì?”
Thời gian	“Dùng mốc thời gian nào và múi giờ nào?”
Trạng thái	“Giá trị trạng thái nào đủ điều kiện tính, nguồn canonical ở đâu?”
Ngoại lệ	“Hoàn, hủy, giao một phần, sửa dữ liệu sau chốt xử lý thế nào?”
Thẩm quyền	“Ai quyết định khi evidence mâu thuẫn hoặc chưa tồn tại?”

8. Detailed Worked Example

Core

Ví dụ này thuộc Nova Foods Trading & Manufacturing, doanh nghiệp mô phỏng giáo dục. Dữ liệu là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Trạng thái tài liệu: IN_REVIEW; phiên bản: v0.9.0; ngày: 2026-08-07. Ví dụ chưa là cấu hình ERP, baseline, approval hay quy định vận hành.

Applied

Tình huống: nhóm Sales Operations đang báo cáo KPI giao hàng tháng 07/2026 cho khách hàng kênh siêu thị. Tên KPI đang dùng trong email là “Tỷ lệ giao đủ đúng hẹn”. Đây là cách gọi nghiệp vụ; chưa có công thức KPI canonical được ghi nhận trong artifact kiểm soát.

Facts

Nhóm fact	Giá trị tổng hợp	Evidence hiện có
Đơn vị báo cáo	Nova Foods Trading & Manufacturing — mô phỏng giáo dục	Bối cảnh corpus Nova Foods
Kỳ báo cáo	2026-07-01 00:00:00 đến 2026-07-31 23:59:59	File Excel tháng 07 do Sales Operations tổng hợp
Múi giờ	Asia/Ho_Chi_Minh	Metadata corpus
Đối tượng đo	Đơn bán hàng giao cho khách hàng kênh siêu thị	Danh sách đơn trong file Excel
Nguồn đơn	Màn hình ERP mô phỏng Sales Order List	Sales Operations xuất thủ công
Nguồn giao hàng	Màn hình ERP mô phỏng Delivery Note List	Warehouse xuất thủ công
Người lập báo cáo	Vai trò Sales Operations Analyst	Email nội bộ mô phỏng
Người dùng báo cáo	Sales Manager, Warehouse Manager	Danh sách người nhận email mô phỏng
Tần suất	Mỗi tháng một lần, ngày làm việc thứ ba của tháng kế tiếp	Thói quen báo cáo được mô tả bởi Sales Operations
Tệp làm việc	OTIF_July_2026_Working.xlsx	Tệp tổng hợp mô phỏng, không phải artifact canonical
Tệp gửi quản lý	Monthly_Service_KPI_2026-07.xlsx	Tệp báo cáo mô phỏng, không phải artifact canonical

Dữ liệu nguồn tổng hợp gồm năm đơn bán hàng. Requested Delivery Date là ngày khách hàng yêu cầu nhận. Actual Delivery Date là ngày trên phiếu giao hàng được Warehouse nhập. Ordered Quantity và Delivered Quantity cùng dùng đơn vị case.

Sales Order ID	Customer	Requested Delivery Date	Ordered Quantity	Delivery Note ID	Actual Delivery Date	Delivered Quantity	Trạng thái đơn trên export
SO-2026-0701	SM-ANPHU-001	2026-07-03	100	DN-2026-0701-A	2026-07-03	100	Delivered
SO-2026-0702	SM-ANPHU-001	2026-07-05	80	DN-2026-0702-A	2026-07-06	80	Delivered
SO-2026-0703	SM-BINHMINH-002	2026-07-08	120	DN-2026-0703-A	2026-07-08	100	Partially Delivered
SO-2026-0704	SM-BINHMINH-002	2026-07-12	60	DN-2026-0704-A	2026-07-12	60	Delivered
SO-2026-0705	SM-HOANGGIA-003	2026-07-15	90	Không có	Không có	0	Open

Fact quan sát được: SO-2026-0703 có một giao hàng 100 case cho đơn đặt 120 case. Fact này chứng minh dữ liệu có thể chứa giao thiếu. Fact chưa chứng minh đơn này phải được tính là “không giao đủ đúng hẹn”, vì định nghĩa chính thức của KPI chưa tồn tại trong đầu vào hiện có.

Fact quan sát được: SO-2026-0705 chưa có Delivery Note ID và đang Open. Fact này chứng minh báo cáo có thể gặp đơn chưa giao tại thời điểm xuất dữ liệu. Fact chưa chứng minh đơn mở phải vào hay ra khỏi mẫu số KPI; cần định nghĩa phạm vi sau này.

Current Behavior

Sales Operations Analyst mở màn hình Sales Order List, lọc đơn theo tháng hiển thị trên Requested Delivery Date, rồi xuất Excel. Analyst mở tiếp Delivery Note List, lọc theo Actual Delivery Date, xuất Excel thứ hai và dùng XLOOKUP theo Sales Order ID để ghép ngày giao cùng số lượng giao vào file OTIF_July_2026_Working.xlsx.

Analyst tự thêm cột On Time bằng so sánh ngày giao với ngày khách yêu cầu. Nếu Actual Delivery Date nhỏ hơn hoặc bằng Requested Delivery Date, analyst nhập Y; nếu lớn hơn, nhập N. Với đơn chưa có ngày giao, analyst để trống. Đây là thao tác bảng tính hiện thời, không phải business rule canonical.

Analyst tự thêm cột In Full bằng so sánh Delivered Quantity với Ordered Quantity. Nếu số lượng giao bằng số lượng đặt, analyst nhập Y; nếu nhỏ hơn, nhập N. Khi một đơn có nhiều phiếu giao, file hiện tại chỉ lấy một dòng giao hàng được XLOOKUP trả về. Evidence: cách ghép dùng một khóa Sales Order ID nhưng không có bước cộng tổng nhiều Delivery Note ID.

Sales Order ID	On Time do analyst nhập	In Full do analyst nhập	Lý do từ dữ liệu hiện có
SO-2026-0701	Y	Y	Giao 2026-07-03; yêu cầu 2026-07-03; 100/100 case
SO-2026-0702	N	Y	Giao 2026-07-06; yêu cầu 2026-07-05; 80/80 case
SO-2026-0703	Y	N	Giao 2026-07-08; yêu cầu 2026-07-08; 100/120 case
SO-2026-0704	Y	Y	Giao 2026-07-12; yêu cầu 2026-07-12; 60/60 case
SO-2026-0705	Trống	N	Chưa có giao hàng; 0/90 case

Sau khi nhập hai cột, analyst đếm số dòng có cả On Time = Y và In Full = Y. File báo cáo gửi quản lý ghi kết quả 2/5 = 40%. Cầu nối evidence: bảng trên có hai đơn đồng thời mang giá trị Y, là SO-2026-0701 và SO-2026-0704; file đang dùng năm đơn export làm mẫu số.

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

flowchart TB
    A[Sales Operations Analyst]

    subgraph M[Thao tác bảng tính hiện thời<br/>không phải business rule canonical]
        B[Export Sales Order List<br/>lọc tháng theo Requested Delivery Date]
        C[Export Delivery Note List<br/>lọc tháng theo Actual Delivery Date]
        D[OTIF_July_2026_Working.xlsx]
        E[XLOOKUP theo Sales Order ID<br/>chỉ lấy một dòng Delivery Note khi có nhiều Delivery Note ID]
        F{Actual Delivery Date?}
        FY[Đúng hạn: Actual Delivery Date ≤ Requested Delivery Date<br/>On Time: Y]
        FN[Trễ: Actual Delivery Date > Requested Delivery Date<br/>On Time: N]
        FB[Chưa giao: không có Actual Delivery Date<br/>On Time: Trống]
        K[Nhập In Full:<br/>Delivered Quantity = Ordered Quantity: Y<br/>Delivered Quantity < Ordered Quantity: N]
        G[Đếm dòng On Time = Y và In Full = Y<br/>mẫu số: 5 đơn export<br/>kết quả: 2/5 = 40%]
        H[Monthly_Service_KPI_2026-07.xlsx]
    end

    A --> B
    A --> C
    B --> D
    C --> D
    D --> E
    E --> F
    F --> FY
    F --> FN
    F --> FB
    FY --> K
    FN --> K
    FB --> K
    K --> G
    G --> H
    H --> I[Sales Manager]
    H --> J[Warehouse Manager]

    R[Risk kiểm soát:<br/>chỉnh sửa thủ công; không ghi nhận nguồn dữ liệu,<br/>thời điểm export, phiên bản công thức,<br/>hoặc kiểm tra độc lập] -.-> D
    R -.-> F
    R -.-> H

    N[Chưa có rule canonical cho:<br/>chọn tháng; nhiều đợt giao; giao thiếu rồi bù;<br/>đơn hủy; đơn còn mở] -.-> B
    N -.-> C
    N -.-> G

Current behavior có ba điểm chưa được kiểm soát bằng artifact canonical. Thứ nhất, không có nguồn định nghĩa chính thức cho việc chọn tháng theo ngày yêu cầu hay ngày giao thực tế. Thứ hai, không có quy tắc cho đơn giao nhiều đợt, giao thiếu rồi bù sau, đơn hủy, hoặc đơn còn mở. Thứ ba, tệp Excel do một analyst chỉnh sửa thủ công; không có dấu vết dữ liệu nguồn, thời điểm export, phiên bản công thức hoặc kiểm tra độc lập được ghi nhận.

Senior Lens

Không gọi kết quả 40% là KPI chính thức. Evidence chỉ chứng minh phép đếm hiện tại trong Monthly_Service_KPI_2026-07.xlsx; không chứng minh phạm vi, công thức, ngoại lệ và thẩm quyền đã được xác lập. Senior BA tách “số đang được báo cáo” khỏi “định nghĩa cần quản trị” để tránh biến thói quen Excel thành yêu cầu ERP ngầm định.

XLOOKUP lấy một giá trị khớp đầu tiên. Vì vậy, nếu một đơn có nhiều phiếu giao, kết quả có thể không phản ánh tổng lượng giao. Đây là rủi ro dữ liệu của current behavior, không phải kết luận rằng ERP mô phỏng có lỗi.

Quick Reference

Thành phần	Hiện trạng đã quan sát	Chưa được xác lập
Tên chỉ số	“Tỷ lệ giao đủ đúng hẹn”	Tên KPI canonical
Tử số hiện dùng	Đơn có On Time = Y và In Full = Y	Định nghĩa chính thức
Mẫu số hiện dùng	Năm đơn trong export tháng 07/2026	Điều kiện đưa vào hoặc loại trừ
Nguồn dữ liệu	Hai export ERP mô phỏng	Nguồn dữ liệu canonical
Cách tính	Excel, XLOOKUP, nhập tay	Quy tắc xử lý giao nhiều đợt và ngoại lệ
Kết quả hiện có	2/5 = 40%	Kết quả KPI được ủy quyền

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, Việt Nam, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Báo cáo cần xét là tỷ lệ giao hàng đúng hẹn theo tháng, gọi là On-Time Delivery Rate (OTD): tỷ lệ đơn giao hoàn tất không muộn hơn ngày khách hàng cam kết.

Bước	Nội dung thực hiện	Bằng chứng và suy luận
Facts	Tháng 2026-07 có 100 đơn bán đã giao. ERP lưu promised_delivery_date tại Sales Order và actual_delivery_date tại Delivery Note. Có 12 đơn giao sau ngày hứa, 3 đơn bị giao hai lần do tách chuyến.	Dữ liệu tổng hợp từ SO-NF-2026-0701 đến SO-NF-2026-0800; 100 đơn logic nhưng 103 dòng giao hàng. Đếm dòng Delivery Note sẽ làm mẫu số thành 103, sai đối tượng đo.
Current Behavior	Nhân viên xuất Excel, đếm 91 dòng giao đúng hẹn trên 103 dòng giao hàng, rồi báo OTD 88,35%. Không có quy tắc chọn dòng giao cuối cùng cho đơn tách chuyến.	91 / 103 × 100 = 88,35%. Chỉ số đang đo dòng giao hàng, không đo đơn bán đã hoàn tất.
Underlying Need	Trưởng phòng Vận hành cần biết khách hàng có nhận đủ đơn đúng cam kết hay không để ưu tiên sửa lịch giao, không cần biết số chuyến xe đúng hẹn.	Đối tượng quyết định là Sales Order hoàn tất. Một đơn giao tách nhiều chuyến chỉ được coi đúng hẹn khi mọi lượng hàng cam kết đã giao không muộn hơn ngày hứa.
Options	OPT-KPI-001: giữ cách đếm Delivery Note. OPT-KPI-002: đếm Sales Order, dùng ngày giao hoàn tất cuối cùng. OPT-KPI-003: đếm từng dòng Sales Order.	OPT-KPI-001 nhanh nhưng sai đơn vị đo. OPT-KPI-003 hữu ích cho phân tích SKU nhưng không trả lời câu hỏi cấp khách hàng.
Decision Criteria	So sánh theo: phù hợp câu hỏi quản trị; không đếm trùng đơn tách chuyến; truy vết được về chứng từ; tái lập được từ dữ liệu ERP; chi phí vận hành báo cáo.	Năm tiêu chí này kiểm tra chỉ số có đo đúng điều cần quản trị, có thể kiểm toán nội bộ, và không phụ thuộc thao tác Excel cá nhân.
Decision	Khuyến nghị BA: chọn OPT-KPI-002. Công thức: OTD = số Sales Order hoàn tất đúng hẹn / tổng Sales Order hoàn tất trong kỳ × 100. Một đơn đúng hẹn khi actual_completion_date <= promised_delivery_date.	Với 100 đơn hoàn tất, 88 đơn đúng hẹn và 12 đơn trễ: 88 / 100 × 100 = 88,00%. Chênh 0,35 điểm phần trăm với báo cáo cũ xuất phát từ đơn vị đo sai.
Authority	Chưa có quyết định được ủy quyền. Business Owner phải xác nhận định nghĩa “hoàn tất”; Sales Operations Owner xác nhận xử lý đơn tách chuyến; Data Owner xác nhận nguồn trường; Finance/Accounting Owner chỉ tham gia nếu KPI được dùng cho thưởng hoặc ghi nhận tài chính.	Artifact corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không có baseline hoặc approval reference. Khuyến nghị BA không phải authorized decision.
Artifact	Ghi vào KPI definition sheet với ID KPI-OTD-001; liên kết logic tới CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY. Tệp handbook: /02-handbook/15-reporting-biometrics-and-kpi-definition.md.	ID và tệp canonical được giữ nguyên. Nội dung KPI chỉ là artifact học liệu mô phỏng, không phải cấu hình ERP production.
Consequence if Wrong	Nếu dùng dòng Delivery Note, OTD bị báo 88,35% thay vì 88,00%; quản lý có thể kết luận hiệu suất giao hàng tốt hơn thực tế. Nếu dùng ngày giao đầu tiên thay ngày hoàn tất, đơn giao thiếu hàng vẫn có thể bị tính đúng hẹn.	Sai đơn vị đo làm sai quyết định ưu tiên vận hành. Sai logic hoàn tất che giấu rủi ro khách hàng nhận không đủ hàng đúng cam kết.

Trường KPI	Giá trị đề xuất trong KPI-OTD-001
Tên	Tỷ lệ giao hàng đúng hẹn
Đối tượng đo	Sales Order hoàn tất
Tử số	Sales Order có actual_completion_date <= promised_delivery_date
Mẫu số	Sales Order có trạng thái hoàn tất giao hàng trong kỳ báo cáo
Kỳ báo cáo ví dụ	2026-07-01 00:00:00 đến 2026-07-31 23:59:59 theo Asia/Ho_Chi_Minh
Loại trừ	Đơn hủy trước hoàn tất; đơn chưa hoàn tất tại cuối kỳ
Đơn vị	Phần trăm, làm tròn 2 chữ số thập phân
Ngưỡng mục tiêu	Verification required từ Business Owner; không suy diễn mục tiêu từ dữ liệu mô phỏng
Nguồn dữ liệu logic	Sales Order, Sales Order Line, Delivery Note
Phân loại	Dữ liệu vận hành mô phỏng; không chứa dữ liệu cá nhân trong ví dụ này

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

flowchart TB
    A["Sales Order<br/>sales_order_id, promised_delivery_date, trạng thái"]
    B["Sales Order Line<br/>sales_order_id, ordered_quantity"]
    C["Delivery Note<br/>sales_order_id, actual_delivery_date,<br/>delivered_quantity, trạng thái"]
    C --> D["Lọc Delivery Note hợp lệ<br/>quy tắc cần Data Owner xác nhận"]
    A --> E["Ghép theo sales_order_id"]
    B --> E
    D --> E
    E --> F{"Đơn hủy trước hoàn tất?"}
    F -- "Có" --> G["Loại trừ khỏi KPI OTD"]
    F -- "Không" --> H{"Tổng delivered_quantity hợp lệ<br/>≥ tổng ordered_quantity?"}
    H -- "Không" --> I["Chưa hoàn tất<br/>Loại khỏi mẫu số kỳ này"]
    H -- "Có" --> J["actual_completion_date<br/>MAX(actual_delivery_date hợp lệ)"]
    J --> K{"Ngày hoàn tất thuộc kỳ báo cáo<br/>theo Asia/Ho_Chi_Minh?"}
    K -- "Không" --> L["Ngoài kỳ báo cáo<br/>Loại khỏi mẫu số kỳ này"]
    K -- "Có" --> M{"Ngày hoàn tất ≤ ngày hứa?"}
    M -- "Có" --> N["Đơn đúng hẹn<br/>Tử số và mẫu số OTD"]
    M -- "Không" --> O["Đơn trễ<br/>Chỉ mẫu số OTD"]
    N --> P["OTD = số đơn đúng hẹn /<br/>số đơn hoàn tất trong kỳ × 100<br/>Làm tròn 2 chữ số"]
    O --> P

    Q["Khuyến nghị — chưa được phê duyệt<br/>Business Owner: định nghĩa hoàn tất<br/>Sales Operations Owner: đơn tách chuyến<br/>Data Owner: nguồn và Delivery Note hợp lệ"]
    Q -. "Xác nhận quy tắc KPI" .-> P

Quy tắc đề xuất BR-KPI-OTD-001: với mỗi sales_order_id, hệ thống báo cáo chỉ tạo một bản ghi KPI khi tổng delivered_quantity của các Delivery Note hợp lệ bằng hoặc lớn hơn tổng ordered_quantity của Sales Order. actual_completion_date là giá trị MAX(actual_delivery_date) trong các Delivery Note hợp lệ của đơn. Quy tắc này là khuyến nghị phân tích; cần Business Owner, Sales Operations Owner và Data Owner xác nhận trước khi thành quyết định được ủy quyền.

Applied

Tình huống mô phỏng: Nova Foods Trading & Manufacturing là case học liệu mô phỏng, chỉ dùng dữ liệu tổng hợp. Báo cáo KPI giao hàng cần đo OTIF (On Time In Full, giao đúng hẹn và đủ số lượng) cho đơn bán hàng khách hàng trong tháng 07/2026. KPI là chỉ số đo kết quả; không tự chứng minh chất lượng vận hành nếu dữ liệu nguồn sai.

Trường kiểm soát	Giá trị
Artifact đang soạn	/02-handbook/15-reporting-biometrics-and-kpi-definition.md
Status / Version	IN_REVIEW / v0.9.0
Ngày / múi giờ	2026-08-07 / Asia/Ho_Chi_Minh
Locale / tiền tệ	vi-VN / VND
Phạm vi	Nova Foods mô phỏng; dữ liệu tổng hợp
Kỳ báo cáo	2026-07-01T00:00:00+07:00 đến 2026-07-31T23:59:59+07:00
KPI ID học liệu	KPI-OTIF-001
Report ID học liệu	RPT-OTIF-DAILY-001
Rule ID học liệu	BR-KPI-OTIF-001

Facts — dữ kiện. Ba đơn hàng có dòng giao hoàn tất trong kỳ. requested_delivery_date là ngày khách yêu cầu trong đơn; actual_delivery_timestamp là thời điểm xác nhận giao; ordered_qty và delivered_qty dùng cùng đơn vị tính CS (case, thùng). Đây là giả định dự án phục vụ học liệu, không phải quy tắc vận hành Nova Foods thực.

sales_order_id	sales_order_line_id	customer_id	requested_delivery_date	ordered_qty	delivered_qty	actual_delivery_timestamp	delivery_status
SO-2026-0701	SOL-2026-0701-01	CUS-001	2026-07-05	100	100	2026-07-05T14:20:00+07:00	DELIVERED
SO-2026-0702	SOL-2026-0702-01	CUS-002	2026-07-08	80	75	2026-07-08T10:15:00+07:00	DELIVERED
SO-2026-0703	SOL-2026-0703-01	CUS-003	2026-07-10	120	120	2026-07-11T09:00:00+07:00	DELIVERED

Current Behavior — hành vi hiện tại. Báo cáo hiện đếm mọi dòng DELIVERED là “đạt giao hàng”. Bằng chứng: cả ba dòng đều có delivery_status = DELIVERED; báo cáo hiện tại trả 3 / 3 = 100%. Cách đếm này không kiểm tra ngày hẹn và số lượng, nên không đo OTIF.

{
  "report_id": "RPT-OTIF-DAILY-001",
  "as_of_timestamp": "2026-08-07T09:00:00+07:00",
  "current_metric_name": "Delivery Completion Rate",
  "numerator": 3,
  "denominator": 3,
  "result_percent": 100.00,
  "source_rows": [
    "SOL-2026-0701-01",
    "SOL-2026-0702-01",
    "SOL-2026-0703-01"
  ]
}

Underlying Need — nhu cầu gốc. Quản lý vận hành cần phân biệt giao hoàn tất với giao đúng hẹn và đủ lượng để tìm nguyên nhân thiếu hàng hoặc trễ giao. Suy luận dựa trên dữ kiện: SOL-2026-0702-01 thiếu 5 CS; SOL-2026-0703-01 giao trễ một ngày. Vì vậy, tỷ lệ hoàn tất 100% che mất hai ngoại lệ cần quản trị.

Rules — quy tắc tính đề xuất.

Rule ID	Quy tắc đầy đủ	Phân loại nguồn
BR-KPI-OTIF-001	Một dòng đạt OTIF khi delivery_status = DELIVERED, delivered_qty >= ordered_qty, và ngày địa phương của actual_delivery_timestamp không muộn hơn requested_delivery_date.	Giả định dự án
BR-KPI-OTIF-002	Mẫu số là mọi dòng có requested_delivery_date trong kỳ báo cáo và không có trạng thái CANCELLED.	Giả định dự án
BR-KPI-OTIF-003	OTIF % = (số dòng đạt OTIF / số dòng trong mẫu số) × 100, làm tròn hai chữ số thập phân.	Giả định dự án
BR-KPI-OTIF-004	Múi giờ đánh giá ngày giao là Asia/Ho_Chi_Minh.	Giả định dự án

Options — phương án.

Option ID	Cách đo	Kết quả với 3 dòng	Điểm mạnh	Giới hạn
OPT-OTIF-001	Đếm DELIVERED	100,00%	Dễ tính	Không đo đúng hẹn hoặc đủ lượng
OPT-OTIF-002	OTIF theo dòng đơn hàng, dùng BR-KPI-OTIF-001 đến BR-KPI-OTIF-004	33,33%	Phát hiện thiếu và trễ	Cần dữ liệu ngày hẹn, lượng đặt, lượng giao tin cậy
OPT-OTIF-003	OTIF theo toàn bộ đơn hàng nhiều dòng	Không áp dụng cho bộ dữ liệu này vì mỗi đơn chỉ có một dòng	Phù hợp khi đơn nhiều dòng	Cần quy tắc gom dòng và xử lý giao từng phần

Decision Criteria — tiêu chí chọn.

Criterion ID	Tiêu chí	OPT-OTIF-001	OPT-OTIF-002	OPT-OTIF-003
DC-OTIF-001	Đo đủ lượng	Không đạt	Đạt	Đạt
DC-OTIF-002	Đo đúng hẹn	Không đạt	Đạt	Đạt
DC-OTIF-003	Phù hợp dữ liệu một dòng mỗi đơn hiện có	Đạt	Đạt	Đạt
DC-OTIF-004	Không cần quy tắc gom nhiều dòng chưa có	Đạt	Đạt	Không đạt

Recommendation — khuyến nghị BA. Chọn OPT-OTIF-002 cho báo cáo học liệu RPT-OTIF-DAILY-001. Lý do: phương án này đạt cả DC-OTIF-001 và DC-OTIF-002, đồng thời không giả định dữ liệu nhiều dòng chưa tồn tại. Khuyến nghị này chưa là quyết định được ủy quyền.

Decision và Authority — quyết định và thẩm quyền. Chưa có quyết định được ủy quyền, baseline, hoặc approval tại IN_REVIEW v0.9.0. Business Owner cần quyết định định nghĩa nghiệp vụ OTIF; Data Owner cần xác nhận nghĩa trường nguồn; Reporting Owner cần chấp nhận cách hiển thị. BA chỉ ghi nhận khuyến nghị và traceability, không tự phê duyệt KPI.

Decision ID	Nội dung	Trạng thái	Vai trò có thẩm quyền	Bằng chứng cần có
DEC-OTIF-001	Dùng OPT-OTIF-002 cho KPI-OTIF-001	PROPOSED	Business Owner	Quyết định được ghi nhận
DEC-OTIF-002	Xác nhận bốn trường nguồn	PROPOSED	Data Owner	Data mapping được kiểm tra
DEC-OTIF-003	Phát hành báo cáo KPI	NOT_AUTHORIZED	Reporting Owner	Approval reference minh bạch

Artifact — đầu ra tính được.

{
  "kpi_id": "KPI-OTIF-001",
  "kpi_name": "OTIF theo dòng đơn hàng",
  "period_start": "2026-07-01",
  "period_end": "2026-07-31",
  "timezone": "Asia/Ho_Chi_Minh",
  "numerator": 1,
  "denominator": 3,
  "result_percent": 33.33,
  "passing_lines": [
    "SOL-2026-0701-01"
  ],
  "failing_lines": [
    {
      "sales_order_line_id": "SOL-2026-0702-01",
      "failure_reason": "SHORT_QUANTITY",
      "ordered_qty": 80,
      "delivered_qty": 75
    },
    {
      "sales_order_line_id": "SOL-2026-0703-01",
      "failure_reason": "LATE_DELIVERY",
      "requested_delivery_date": "2026-07-10",
      "actual_delivery_timestamp": "2026-07-11T09:00:00+07:00"
    }
  ],
  "decision_status": "NOT_AUTHORIZED"
}

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

flowchart TB
    A[Dòng có requested_delivery_date trong kỳ] --> B{delivery_status = CANCELLED?}
    B -- Có --> X[Loại khỏi mẫu số]
    B -- Không --> C[Đếm mẫu số]
    C --> D{delivery_status = DELIVERED?}
    D -- Không --> F[Không đạt OTIF]
    D -- Có --> E{delivered_qty >= ordered_qty?}
    E -- Không --> F
    E -- Có --> G{Ngày giao Asia/Ho_Chi_Minh<br/>&lt;= requested_delivery_date?}
    G -- Không --> F
    G -- Có --> H[Đạt OTIF]
    H --> I[Đếm tử số]
    I --> J[OTIF % = tử số / mẫu số × 100,<br/>làm tròn 2 chữ số]
    F --> J

Consequence if Wrong — hậu quả nếu sai. Nếu dùng OPT-OTIF-001, báo cáo ghi 100,00% dù một dòng thiếu lượng và một dòng trễ. Quản lý có thể bỏ sót vấn đề kho hoặc vận tải; hành động cải tiến dựa trên KPI sẽ sai hướng. Nếu áp dụng OPT-OTIF-002 khi chưa xác nhận trường nguồn, KPI 33,33% cũng chưa đủ căn cứ cho vận hành thực tế; cần giữ trạng thái PROPOSED cho đến khi đúng vai trò ghi nhận quyết định.

9. Related Concepts & Dependencies

Core

KPI (Key Performance Indicator, chỉ số hiệu suất trọng yếu) không tự là nguồn dữ liệu hay quy tắc nghiệp vụ. KPI chỉ tính và trình bày kết quả từ nguồn đã được kiểm soát. Nova Foods là case study mô phỏng; mọi dữ liệu là tổng hợp, dùng vi-VN, Asia/Ho_Chi_Minh và VND.

Chuỗi phụ thuộc bắt đầu từ phạm vi học liệu, định danh, quy tắc và dữ liệu. /01-curriculum/CHAPTER_MANIFEST.md là nguồn canonical cho chapter và filename. /01-curriculum/TEMPLATE_MANIFEST.md là nguồn canonical cho template dự kiến. /01-curriculum/TRACEABILITY_ID_REGISTRY.md là nguồn canonical cho cấu trúc và quản trị persistent ID. /01-curriculum/CANONICAL_BUSINESS_RULES.md giữ quy tắc nghiệp vụ. /01-curriculum/CANONICAL_DATA_DICTIONARY.md giữ nghĩa logic, kiểu, nguồn và ràng buộc dữ liệu.

Chapter này không sao chép định nghĩa của KPI-OTIF-001, không tạo biến thể như OTIF-KPI-01, không chép rule giao đủ hoặc giao đúng hạn vào nhiều nơi. Chapter chỉ ghi liên kết đến nguồn canonical và giải thích KPI tiêu thụ nội dung đó thế nào. Lý do: một khái niệm có nhiều bản sẽ tạo kết quả khác nhau dù cùng tên báo cáo.

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

flowchart TB
    A["/01-curriculum/CHAPTER_MANIFEST.md<br/>chapter, filename"] --> E["Handbook explanation<br/>links canonical sources; explains KPI consumption"]
    B["/01-curriculum/TEMPLATE_MANIFEST.md<br/>expected template"] --> E
    C["/01-curriculum/TRACEABILITY_ID_REGISTRY.md<br/>persistent ID"] --> E
    D["/01-curriculum/CANONICAL_BUSINESS_RULES.md<br/>business rule"] --> E
    F["/01-curriculum/CANONICAL_DATA_DICTIONARY.md<br/>field meaning, source"] --> E
    E --> G["KPI definition and report output"]
    G --> H["Consumer decision or follow-up"]

Applied

Facts. Ví dụ OTIF dùng persistent ID KPI-OTIF-001; mẫu dữ liệu trước đó dùng SOL-2026-0701-01, SOL-2026-0702-01, SOL-2026-0703-01. Các ID này nhận diện đối tượng xuyên artifact, không phải tên hiển thị có thể dịch hoặc đổi.

Current Behavior. Chapter báo cáo diễn giải OTIF theo dòng đơn hàng, dùng số lượng đặt, số lượng giao, ngày hẹn và thời điểm giao. Chapter không sở hữu nghĩa của các trường này.

Underlying Need. Người đọc cần lần từ kết quả 33.33% về đúng định nghĩa KPI, rule đánh giá và trường dữ liệu. Bằng chứng là kết quả chỉ đáng tin nếu tử số, mẫu số và điều kiện đạt cùng dùng một nguồn nghĩa.

Options.
1. Chép định nghĩa field và rule vào chapter KPI.
2. Liên kết chapter KPI đến artifact canonical, chỉ ghi cách tiêu thụ.

Decision Criteria. Chọn phương án giữ một nguồn chân lý, bảo toàn ID, giảm sửa trùng và cho phép kiểm tra thay đổi.

Decision. Chọn phương án 2. KPI-OTIF-001 được tham chiếu nguyên dạng. Rule giao đủ, giao đúng hạn và nghĩa field phải truy vấn từ catalog hoặc dictionary canonical khi artifact đó có nội dung được kiểm soát.

Authority. Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết, ID, version và metadata. Vai trò này không xác nhận rule Nova Foods cho vận hành thực tế, không tự baseline, không ghi nhận approval.

Artifact.

Thành phần phụ thuộc	Nguồn canonical	Chapter này dùng để làm gì	Không được làm gì
Chapter identity	/01-curriculum/CHAPTER_MANIFEST.md	Giữ đúng chapter và filename /02-handbook/15-reporting-biometrics-and-kpi-definition.md	Tự đổi tên chapter hoặc tạo filename thay thế
Template identity	/01-curriculum/TEMPLATE_MANIFEST.md	Xác định template báo cáo/KPI khi được manifest đăng ký	Tạo template ID mới trong chapter
Persistent ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Giữ nguyên KPI-OTIF-001 và SOL-2026-0701-01	Đổi tiền tố, tái sử dụng ID, tạo ID suy đoán
Business rule	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Tham chiếu điều kiện đạt OTIF	Chép rule thành bản cạnh tranh
Logical data meaning	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Xác định nghĩa ordered_qty, delivered_qty, ngày hẹn, thời điểm giao	Tự suy diễn field nguồn hoặc kiểu dữ liệu
Governance and source boundary	/00-research/00_SOURCE_MAP.md	Giữ Nova Foods mô phỏng, dữ liệu tổng hợp, nhãn xác minh	Diễn giải nguồn thành nghĩa vụ pháp lý hoặc production rule

Consequence if Wrong. Nếu một báo cáo đổi delivered_qty thành lượng xuất kho nhưng không đổi nguồn canonical, OTIF có thể tăng giả khi hàng xuất nhưng chưa giao. Nếu đổi KPI-OTIF-001 trong một template mà không đổi registry, reviewer không thể nối kết quả với định nghĩa gốc. Nếu chép rule vào chapter rồi catalog đổi âm thầm, hai công thức cùng tên sẽ cho hai kết quả khác nhau.

Senior Lens

Phụ thuộc upstream là artifact cung cấp nghĩa, ID hoặc ràng buộc cho KPI. Phụ thuộc downstream là report, dashboard, quyết định, test basis hoặc template tiêu thụ KPI. Không suy ra rằng downstream được phê duyệt vì upstream tồn tại: toàn corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Quy tắc kiểm tra nhanh: khi cần sửa tên, công thức, field, timezone hoặc đơn vị đo, tìm persistent ID trước, tìm artifact canonical sau, rồi mới sửa nơi tham chiếu. Nếu không xác định được nguồn canonical, giữ nội dung ở trạng thái cần xác minh; không lấp khoảng trống bằng quy tắc Nova Foods tự tạo.

Quick Reference

Cần biết	Tra ở đâu
Chapter, section, filename chính thức	/01-curriculum/CHAPTER_MANIFEST.md
Template được quy hoạch	/01-curriculum/TEMPLATE_MANIFEST.md
Cấu trúc và tính duy nhất của ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md
Nghĩa và nguồn dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md
Ranh giới nguồn, pháp lý, chuẩn	/00-research/00_SOURCE_MAP.md

Core

Traceability là khả năng lần ngược từ chỉ số KPI đến nhu cầu, yêu cầu, quy tắc, dữ liệu, giao diện và kiểm thử đã tạo ra nó. Mỗi liên kết dùng ID canonical từ /01-curriculum/TRACEABILITY_ID_REGISTRY.md; bảng này chỉ tham chiếu, không thay thế nguồn chân lý của NEED, REQ, BR, AC, DATA/API hay TC.

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, trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Loại liên kết	ID liên kết	Vai trò trong định nghĩa KPI	Nguồn canonical cần tra cứu	Bằng chứng liên kết
NEED	NEED-REP-001	Nhu cầu xem tỷ lệ giao hàng đúng hẹn để nhận biết độ tin cậy giao hàng mô phỏng	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	KPI đo kết quả người nhận hàng cần theo dõi
REQ	REQ-REP-001	Yêu cầu hệ thống tính OnTimeDeliveryRate theo kỳ báo cáo	Registry ID và artifact yêu cầu canonical khi được tạo	NEED cần số đo nhất quán, REQ xác định hành vi hệ thống
BR	BR-REP-001	Quy tắc: đơn giao đúng hẹn khi ActualDeliveryDate <= ConfirmedDeliveryDate	/01-curriculum/CANONICAL_BUSINESS_RULES.md	REQ không thể tính tỷ lệ nếu thiếu điều kiện phân loại đúng hẹn
AC	AC-REP-001	Tiêu chí chấp nhận: báo cáo hiển thị tử số, mẫu số, tỷ lệ phần trăm và kỳ lọc	Artifact acceptance criteria canonical khi được tạo	AC kiểm tra REQ có tạo kết quả quan sát được
DATA	DATA-SO-001	Dữ liệu đơn hàng: SalesOrderID, ConfirmedDeliveryDate, ActualDeliveryDate, OrderStatus	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	BR cần các trường ngày và trạng thái để phân loại
API	API-REP-001	API hoặc data contract trả tập dữ liệu KPI theo kỳ	Đặc tả API canonical; dùng OpenAPI 3.1.1 khi có API HTTP	Giao diện báo cáo cần nhận dữ liệu có cấu trúc
TC	TC-REP-001	Kiểm thử tỷ lệ đúng hẹn với dữ liệu tổng hợp có đơn đúng hẹn, trễ hẹn, chưa giao	Test basis và test case canonical khi được tạo	TC xác minh BR, REQ và AC cùng hoạt động

Quy tắc đọc bảng: NEED-REP-001 trả lời “vì sao đo”; REQ-REP-001 trả lời “hệ thống phải làm gì”; BR-REP-001 trả lời “tính đúng hẹn theo điều kiện nào”; AC-REP-001 trả lời “quan sát kết quả đạt ra sao”; DATA-SO-001 và API-REP-001 trả lời “lấy dữ liệu ở đâu, theo cấu trúc nào”; TC-REP-001 trả lời “chứng minh bằng kiểm thử nào”. Chuỗi đủ giúp BA phát hiện KPI có số nhưng thiếu định nghĩa, dữ liệu hoặc kiểm thử.

Applied

Mục	Nội dung
Facts	Báo cáo mô phỏng tháng 2026-07 có 100 đơn hoàn tất; 92 đơn có ActualDeliveryDate <= ConfirmedDeliveryDate.
Current Behavior	REQ-REP-001 tính OnTimeDeliveryRate = 92 / 100 × 100 = 92%.
Underlying Need	NEED-REP-001 cần số liệu giao hàng đúng hẹn có thể giải thích và kiểm tra lại.
Options	(1) Chỉ lưu giá trị 92%; (2) lưu KPI cùng liên kết NEED, REQ, BR, AC, DATA/API, TC.
Decision Criteria	Truy ngược được công thức; xác định được nguồn dữ liệu; kiểm thử được biên ngày bằng; không nhân bản định nghĩa canonical.
Decision	Chọn phương án 2. Báo cáo giữ ID liên kết; công thức và định nghĩa trường vẫn nằm tại artifact canonical.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết. Business Owner xác nhận nhu cầu nghiệp vụ khi có quy trình thẩm quyền. QA xác nhận kiểm thử. Owner dữ liệu xác nhận nghĩa trường.
Artifact	/02-handbook/15-reporting-biometrics-and-kpi-definition.md tham chiếu NEED-REP-001, REQ-REP-001, BR-REP-001, AC-REP-001, DATA-SO-001, API-REP-001, TC-REP-001.
Consequence if Wrong	Nếu BR-REP-001 dùng < thay vì <= nhưng TC-REP-001 không có ca ngày bằng nhau, đơn giao đúng ngày bị tính trễ. KPI 92% có thể sai mà giao diện vẫn hoạt động.

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

flowchart LR
    NEED[NEED-REP-001<br/>Theo dõi giao đúng hẹn]
    REQ[REQ-REP-001<br/>Tính OnTimeDeliveryRate]
    BR[BR-REP-001<br/>ActualDeliveryDate <= ConfirmedDeliveryDate]
    DATA[DATA-SO-001<br/>Ngày hẹn, ngày giao, trạng thái]
    API[API-REP-001<br/>Data contract báo cáo]
    AC[AC-REP-001<br/>Hiển thị tử số, mẫu số, tỷ lệ]
    TC[TC-REP-001<br/>Kiểm thử biên và tỷ lệ]

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

Senior Lens

Không tạo ID mới trong handbook để bù khoảng trống registry. Lý do: ID tự phát phá vỡ định danh bền vững và làm người đọc không biết đâu là nguồn canonical. Nếu một ID chưa đăng ký, ghi nhận vấn đề vào registry theo quy trình corpus; không diễn đạt nó như requirement, rule hay test case đã tồn tại.

DATA và API không luôn cùng áp dụng. Báo cáo đọc trực tiếp kho dữ liệu logic chỉ cần liên kết DATA; báo cáo gọi dịch vụ HTTP cần thêm API. Bằng chứng chọn API là có endpoint, request, response hoặc data contract; tên màn hình hay tên bảng không đủ chứng minh có API.

TC phải bám cả quy tắc và tiêu chí chấp nhận. Với BR-REP-001, tối thiểu cần dữ liệu tổng hợp cho ba trường hợp: giao sớm, giao đúng ngày, giao trễ. Nếu chỉ thử giao sớm và trễ, toán tử <= chưa được chứng minh tại biên bằng ngày.

Quick Reference

Kiểm tra trước khi xuất bản liên kết KPI	Kết quả cần có
Mỗi ID có đúng tiền tố và nguyên dạng canonical?	Có; không dịch, không đổi số, không tạo biến thể
KPI có NEED và REQ?	Có; biết lý do đo và hành vi cần có
Công thức hoặc phân loại có BR?	Có; tránh suy diễn quy tắc từ tên KPI
Dữ liệu đầu vào có DATA và API khi áp dụng?	Có; biết nghĩa trường và đường lấy dữ liệu
Kết quả hiển thị có AC?	Có; kiểm được đầu ra người dùng nhìn thấy
Có TC kiểm tra quy tắc, biên và kết quả?	Có; chứng minh thay vì giả định
Có khẳng định baseline, approval hoặc tuân thủ?	Không; tất cả vẫn IN_REVIEW tại v0.9.0

Thay đổi im lặng làm đứt chuỗi đo lường

Core

Thay đổi lan truyền là việc một sửa đổi tại nguồn phụ thuộc làm thay đổi ý nghĩa, dữ liệu đầu vào, cách tính, kết quả hiển thị hoặc kiểm thử của KPI. Nguồn phụ thuộc là artifact mà báo cáo dựa vào, như quy tắc nghiệp vụ, từ điển dữ liệu, API hoặc tiêu chí chấp nhận. Nova Foods là case study mô phỏng; mọi dữ liệu dưới đây là tổng hợp.

Thay đổi im lặng xảy ra khi artifact nguồn bị sửa nhưng không có version mới, lịch sử thay đổi, đánh giá tác động hoặc thông báo cho artifact dùng nó. Ví dụ, đổi nghĩa trường delivery_date từ “ngày giao thực tế” thành “ngày dự kiến giao” mà dashboard vẫn dùng công thức cũ. Dashboard vẫn chạy, nhưng KPI giao đúng hạn đổi nghĩa. Đây nguy hiểm hơn lỗi kỹ thuật dễ thấy vì số liệu sai vẫn trông hợp lý.

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

flowchart TB
    A[CANONICAL_DATA_DICTIONARY<br/>Đổi nghĩa delivery_date] --> V{Tạo version mới?}

    V -->|Không| S[Sửa đè nghĩa canonical<br/>không tạo version mới]
    S --> X[Dữ liệu delivery_date<br/>mang nghĩa mới]
    S --> T[Artifact phụ thuộc không được thông báo<br/>tham chiếu không đổi hoặc không ghim version]
    T --> B0[Đặc tả KPI OTIF<br/>logic vẫn theo nghĩa cũ]
    T --> C0[API báo cáo<br/>contract vẫn theo nghĩa cũ]
    T --> E0[Tiêu chí chấp nhận<br/>vẫn theo nghĩa cũ]
    E0 --> F0[Ca kiểm thử<br/>vẫn kiểm tra nghĩa cũ]
    B0 --> D0[Dashboard Nova Foods<br/>công thức vẫn theo nghĩa cũ]
    X --> M[Lệch ngữ nghĩa:<br/>dữ liệu mới, contract và công thức cũ]
    C0 --> M
    M --> D0
    D0 --> R[Dashboard vẫn chạy<br/>OTIF đổi nghĩa, số liệu sai vẫn có vẻ hợp lý]
    F0 --> R

    V -->|Có| P[Tạo và công bố version canonical mới]
    P --> Q{Đủ lịch sử thay đổi,<br/>đánh giá tác động và thông báo?}
    Q -->|Không| Q0[Bổ sung lịch sử thay đổi,<br/>đánh giá tác động và thông báo]
    Q0 --> Q
    Q -->|Có| U{Áp dụng version mới?}

    U -->|Giữ version cũ có chủ đích| K[Giữ tham chiếu version cũ]
    K --> K1[Mỗi artifact phụ thuộc ghi<br/>ID, version, vị trí tham chiếu, tác động]
    K1 --> O[Thay đổi được kiểm soát]

    U -->|Có| B1[Đặc tả KPI OTIF<br/>cập nhật ID/version và logic khi bị tác động]
    U -->|Có| C1[API báo cáo<br/>cập nhật ID/version và API contract khi bị tác động]
    U -->|Có| D1[Dashboard Nova Foods<br/>cập nhật ID/version và công thức khi bị tác động]
    U -->|Có| E1[Tiêu chí chấp nhận<br/>cập nhật ID/version khi bị tác động]
    U -->|Có| F1[Ca kiểm thử<br/>cập nhật ID/version và kiểm thử khi bị tác động]

    B1 --> W[Mỗi artifact phụ thuộc ghi<br/>ID, version, vị trí tham chiếu, tác động]
    C1 --> W
    D1 --> W
    E1 --> W
    F1 --> W
    W --> O[Thay đổi được kiểm soát]

Quy tắc: không tự sửa bản sao định nghĩa trong dashboard, tài liệu yêu cầu hoặc test case để “khớp nhanh”. Bản sao tạo hai nguồn chân lý. Artifact dùng phụ thuộc chỉ ghi ID, version, vị trí tham chiếu và tác động; định nghĩa đầy đủ vẫn thuộc artifact canonical.

Applied

Facts: Dashboard mô phỏng Nova Foods tính KPI OTIF theo số đơn giao đúng ngày cam kết và đủ số lượng. delivery_date lấy từ API báo cáo. CANONICAL_DATA_DICTIONARY đổi mô tả trường này từ ngày giao thực tế sang ngày dự kiến giao, nhưng API, dashboard và test case không được cập nhật.

Current Behavior: Tử số OTIF tăng vì hệ thống so ngày dự kiến với ngày cam kết. Người xem thấy KPI tốt hơn, dù hiệu suất giao thực tế không đổi.

Underlying Need: KPI phải đo kết quả giao thực tế, không đo kế hoạch. Bằng chứng: mục đích quản trị OTIF là đánh giá mức đáp ứng cam kết khách hàng; ngày dự kiến chỉ phản ánh kế hoạch.

Options:

Phương án	Cách xử lý	Rủi ro
Giữ delivery_date	Dùng tiếp trường đã đổi nghĩa	KPI sai nghĩa
Đổi tên trường trong dashboard	Gắn nhãn khác nhưng giữ dữ liệu dự kiến	Che lỗi nguồn
Khôi phục nghĩa hoặc dùng trường ngày giao thực tế riêng	Cập nhật nguồn, API, KPI và test đồng bộ	Cần đánh giá tác động

Decision Criteria: Chọn phương án giữ đúng nghĩa KPI; phân biệt dữ liệu kế hoạch và thực tế; có thể kiểm thử; không tạo nguồn chân lý thứ hai.

Decision: Dừng xuất bản KPI bị ảnh hưởng trong môi trường học liệu. Ghi nhận thay đổi tại nguồn canonical, xác định trường đại diện ngày giao thực tế, rồi cập nhật toàn bộ artifact phụ thuộc theo cùng version.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì traceability và gói tác động. Business Owner xác nhận nghĩa KPI. Data Owner xác nhận nghĩa trường. QA xác nhận test case. Không vai trò nào tự gọi nội dung là approved hoặc baselined tại IN_REVIEW, v0.9.0.

Artifact: Ghi thay đổi trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md; cập nhật liên kết kiểm soát trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; rà soát định nghĩa KPI trong /02-handbook/15-reporting-biometrics-and-kpi-definition.md.

Consequence if Wrong: Dashboard báo OTIF cao giả tạo; quyết định vận hành dựa trên tín hiệu sai; acceptance criteria và test case có thể xác nhận sai chức năng; truy vết không còn chứng minh được KPI dùng dữ liệu nào.

Senior Lens

Im lặng không chỉ là không gửi thông báo. Im lặng còn gồm đổi kiểu dữ liệu, múi giờ, đơn vị tiền, giá trị mã, điều kiện lọc, quyền API hoặc thứ tự làm mới dữ liệu mà không đánh giá ảnh hưởng. Với corpus này, Asia/Ho_Chi_Minh, vi-VN và VND là metadata kiểm soát. Đổi sang UTC, đổi định dạng ngày, hoặc đổi đơn vị tiền mà KPI không đổi công thức có thể làm lệch kỳ báo cáo hoặc nhân sai giá trị.

Thay đổi cần bị chặn khi không xác định được: nguồn canonical, owner xác nhận nghĩa, artifact tiêu thụ, hoặc bằng chứng kiểm thử sau thay đổi. Không suy diễn quy tắc pháp lý, kế toán, thuế, riêng tư hay an toàn thực phẩm từ thay đổi KPI. Các nội dung đó cần Verification required và owner có thẩm quyền.

Quick Reference

Dấu hiệu thay đổi im lặng	Thứ có thể vỡ	Hành động tối thiểu
Đổi nghĩa trường dữ liệu	Công thức KPI đúng cú pháp nhưng sai nghiệp vụ	Đối chiếu data dictionary và định nghĩa KPI
Đổi API payload hoặc mã trạng thái	Dashboard trống, lọc sai, đếm trùng	Kiểm thử hợp đồng API và dữ liệu mẫu tổng hợp
Đổi business rule	Chỉ số không còn phản ánh quyết định cần hỗ trợ	Business Owner xác nhận lại nghĩa đo lường
Đổi acceptance criteria	Test pass nhưng không chứng minh giá trị nghiệp vụ	Rà soát test basis và test case
Đổi version không ghi lịch sử	Không biết số liệu thuộc định nghĩa nào	Ghi version, ngày 2026-08-07, tác động và liên kết registry

10. Common Mistakes & Anti-patterns

Core

Sai lầm KPI thường không nằm ở phép tính, mà ở việc đo nhầm thứ cần quyết định. KPI (Key Performance Indicator, chỉ số hiệu quả then chốt) chỉ hữu ích khi mỗi kết quả trả lời được một câu hỏi vận hành xác định. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Sai lầm novice hoặc đội giao hàng	Dấu hiệu quan sát được	Nguyên nhân gốc	Hành động sửa
Đặt tên KPI theo cảm tính	Doanh thu tốt, Tồn kho ổn xuất hiện trên dashboard	Không viết câu hỏi quyết định trước khi chọn số đo	Viết tên đo được, đơn vị, kỳ đo, công thức, điều kiện lọc
Dùng số tổng thay KPI	Báo cáo chỉ có tổng doanh thu VND	Nhầm báo cáo mô tả với chỉ số phục vụ hành động	Xác định ngưỡng, xu hướng, đối tượng chịu trách nhiệm và hành động khi lệch
Chọn dữ liệu dễ lấy thay dữ liệu đúng nghĩa	KPI giao đúng hạn dùng ngày tạo đơn thay ngày giao thực tế	Đội kỹ thuật bắt đầu từ bảng dữ liệu, không bắt đầu từ định nghĩa nghiệp vụ	Đối chiếu từng biến công thức với nghĩa trường trong CANONICAL_DATA_DICTIONARY
Đếm trùng bản ghi	Tổng đơn tăng khi một đơn có nhiều dòng hàng	Không xác định hạt dữ liệu, tức một dòng đại diện cho đơn, dòng hàng hay lô hàng	Ghi rõ đơn vị đếm: SalesOrderID, SalesOrderLineID hoặc BatchID; kiểm thử mẫu có quan hệ một-nhiều
Lẫn kỳ báo cáo	Số tháng thay đổi khi chạy lại cùng dashboard	Không khóa thời điểm chốt dữ liệu và múi giờ	Ghi kỳ đo, thời điểm làm mới, Asia/Ho_Chi_Minh, quy tắc dữ liệu phát sinh sau chốt
Hiển thị tỷ lệ thiếu mẫu số	Dashboard ghi 95% nhưng không biết trên bao nhiêu đơn	Tối ưu giao diện hơn khả năng kiểm tra	Hiển thị tử số, mẫu số, tỷ lệ, tập bị loại và lý do loại
Dùng màu thay nghĩa	Ô đỏ nhưng không có ngưỡng hay mức độ ưu tiên	Không định nghĩa điều kiện cảnh báo	Ghi ngưỡng số học và hành động dự kiến cạnh KPI
Sao chép KPI giữa bộ phận	KPI kho dùng cho bán hàng mà không đổi điều kiện lọc	Cho rằng cùng tên nghĩa là cùng mục tiêu	Xác nhận người tiêu thụ, quyết định và phạm vi nghiệp vụ trước khi tái sử dụng

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

flowchart TB
    Q[Câu hỏi quyết định] --> D[Định nghĩa KPI:<br/>tên đo được, đơn vị, kỳ đo,<br/>múi giờ, thời điểm chốt,<br/>người tiêu thụ, phạm vi nghiệp vụ,<br/>người chịu trách nhiệm]
    D --> M[Đối chiếu nghĩa trường với<br/>CANONICAL_DATA_DICTIONARY]
    M --> G[Hạt dữ liệu và điều kiện lọc:<br/>SalesOrderID, SalesOrderLineID<br/>hoặc BatchID]
    G --> F[Công thức và ngưỡng cảnh báo]
    F --> V[Kiểm thử dữ liệu:<br/>mẫu quan hệ một-nhiều,<br/>chạy lại cùng kỳ và thời điểm chốt]
    V --> T{Kiểm thử đạt?}
    T -->|Sai nghĩa trường| M
    T -->|Sai hạt hoặc lọc| G
    T -->|Sai công thức| F
    T -->|Sai kỳ hoặc chốt| D
    T -->|Đạt| K{KPI là tỷ lệ?}
    K -->|Có| P[Hiển thị truy vết:<br/>tử số, mẫu số,<br/>tập bị loại và lý do]
    K -->|Không| R[Báo cáo hoặc dashboard:<br/>ngưỡng cảnh báo và<br/>hành động khi lệch]
    P --> R
    R --> A[Hành động vận hành theo ngưỡng]
    A --> Q

Applied

Facts: Dashboard mô phỏng Nova Foods hiển thị Tỷ lệ giao đúng hạn = 96% cho tháng 07/2026. Dữ liệu tổng hợp có 100 SalesOrderID; 96 đơn có DeliveryCreatedDate không muộn hơn RequestedDeliveryDate.

Current Behavior: Đội giao hàng dùng tỷ lệ này để kết luận hoạt động giao nhận đạt mục tiêu.

Underlying Need: Quản lý cần biết bao nhiêu đơn đã được giao cho khách đúng ngày cam kết, không phải bao nhiêu chứng từ giao hàng được tạo đúng ngày.

Options: Dùng DeliveryCreatedDate; dùng ngày giao thực tế nếu nguồn canonical xác định trường này; hoặc không công bố KPI cho đến khi xác định được trường phù hợp.

Decision Criteria: Trường phải biểu diễn sự kiện giao thực tế, liên kết một-một hoặc có quy tắc gom rõ với SalesOrderID, có thời điểm theo Asia/Ho_Chi_Minh, và kiểm thử được bằng dữ liệu tổng hợp.

Decision: Không dùng DeliveryCreatedDate làm bằng chứng giao đúng hạn. Gắn KPI là chưa đủ điều kiện công bố cho đến khi xác minh nghĩa trường và hạt dữ liệu trong CANONICAL_DATA_DICTIONARY.

Authority: Business Owner xác nhận nghĩa “đúng hạn”; Data Owner xác nhận nghĩa và chất lượng trường; Owner của handbook chỉ ghi nhận vấn đề, không tự xác nhận KPI.

Artifact: Cập nhật bản ghi định nghĩa KPI, liên kết CANONICAL_DATA_DICTIONARY, và ghi trạng thái Verification required; không gọi là baseline hay approved.

Consequence if Wrong: KPI có thể báo xanh khi hàng chưa đến khách. Quản lý bỏ qua chậm giao thật; đội kiểm thử xác nhận công thức đúng nhưng xác nhận sai mục tiêu nghiệp vụ.

Cảnh báo: Không thay thế trường dữ liệu bằng suy đoán để kịp phát hành dashboard. Ranh giới khôi phục an toàn: dừng công bố KPI bị ảnh hưởng, giữ số liệu thô có timestamp, sửa định nghĩa sau xác minh, rồi chạy lại kiểm thử trên dữ liệu tổng hợp. Không sửa lịch sử để tạo cảm giác KPI luôn đúng.

Senior Lens

Đội delivery hay mắc lỗi “dashboard-first”: dựng biểu đồ trước, rồi hợp thức hóa định nghĩa sau. Red flag là câu hỏi “cần lấy cột nào?” xuất hiện trước câu hỏi “quyết định nào sẽ đổi khi KPI lệch?”. Nguyên nhân là nhầm đầu ra trực quan với đo lường có kiểm soát. Sửa bằng cách chặn thiết kế giao diện đến khi có tên KPI, câu hỏi quyết định, đơn vị đo, hạt dữ liệu, kỳ đo và chủ thể hành động.

Một sai lầm khác là coi một lần đối chiếu Excel là kiểm thử đầy đủ. Đối chiếu này chỉ chứng minh phép tính trên mẫu đang xem; không chứng minh xử lý đơn hủy, đơn tách giao, dữ liệu trễ hoặc giá trị rỗng. Hành động sửa là lập dữ liệu tổng hợp chứa từng tình huống biên và lưu kết quả tính mong đợi. Không suy diễn nghĩa nghiệp vụ từ kết quả tính khớp.

Quick Reference

Red flag	Kiểm tra ngay	Sửa tối thiểu
KPI không có đơn vị	Giá trị là số lượng, tỷ lệ, thời gian hay VND	Ghi đơn vị cạnh tên KPI
KPI không có người hành động	Ai đổi quyết định khi chỉ số lệch	Gán vai trò tiêu thụ và hành động dự kiến
Tỷ lệ không có mẫu số	Tập dữ liệu nào tạo ra tỷ lệ	Hiển thị tử số, mẫu số, điều kiện loại trừ
Số liệu đổi sau khi làm mới	Kỳ đo và thời điểm chốt có được ghi không	Ghi timestamp, Asia/Ho_Chi_Minh, quy tắc làm mới
Một đơn tạo nhiều dòng dữ liệu	Đang đếm đơn, dòng hay lô	Khóa hạt dữ liệu trong định nghĩa KPI

Core

Cảnh báo — rủi ro quyết định sai: Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. KPI sai định nghĩa có thể làm người học mô phỏng quyết định sai về tồn kho, doanh thu hoặc hiệu suất. Không dùng ví dụ này làm cấu hình ERP, kết luận kế toán, pháp lý, thuế hoặc vận hành production.

“Recovery boundary” là ranh giới khôi phục an toàn: phần nào được sửa trong artifact đang IN_REVIEW, phần nào phải dừng tính KPI, giữ bằng chứng và chuyển đúng owner. Sửa công thức chưa được xác nhận không được làm mất giá trị lịch sử, che dữ liệu nguồn, hay đổi trạng thái v0.9.0 thành baseline hoặc approval.

Lỗi thực tế	Ví dụ lỗi Nova Foods mô phỏng	Dấu hiệu quan sát	Rủi ro thật	Khôi phục an toàn
Cảnh báo cho lỗi nhỏ	Gắn cảnh báo cho việc nhãn biểu đồ ghi VND thay vì VND/tháng	Tài liệu đầy cảnh báo, người đọc bỏ qua cảnh báo	Cảnh báo mất tác dụng khi lỗi nghiêm trọng xuất hiện	Sửa nhãn trực tiếp; chỉ dùng cảnh báo khi lỗi có thể dẫn tới quyết định sai, lộ dữ liệu, mất tiền hoặc vi phạm kiểm soát
Không cảnh báo lỗi nguồn dữ liệu	KPI Tỷ lệ giao đúng hẹn lấy ngày tạo đơn bán thay vì ngày cam kết giao	Tỷ lệ đạt 98% nhưng nhiều đơn giao trễ theo lịch giao	Điều hành tin sai mức phục vụ khách hàng	Dừng công bố KPI; lưu snapshot dữ liệu tổng hợp; xác định trường ngày canonical trong CANONICAL_DATA_DICTIONARY; tính lại, ghi phiên bản định nghĩa
Gọi nội dung là đã phê duyệt	Bảng KPI ghi “Finance approved” nhưng không có approval reference	Không có ID quyết định, người có thẩm quyền, ngày, hoặc artifact kiểm soát	Nhóm delivery dùng chỉ tiêu chưa được xác nhận	Xóa claim; ghi IN_REVIEW; chuyển Business Owner và Accounting Owner xác nhận nếu KPI ảnh hưởng diễn giải tài chính
Sửa ngược lịch sử	Đổi công thức Gross Margin rồi thay số tháng trước mà không giữ bản cũ	Báo cáo tháng 06/2026 đổi số sau khi xuất	Không đối chiếu được quyết định đã dựa trên số nào	Giữ snapshot, kỳ báo cáo, công thức cũ và mới; tái phát hành có ghi thay đổi; không ghi đè artifact kiểm soát
Dùng biểu đồ như bằng chứng	Dashboard xanh nhưng không có công thức, bộ lọc, thời điểm chốt dữ liệu	Không truy được nguồn, điều kiện lọc, múi giờ	Không tái lập kết quả	Gắn KPI definition, dataset ID, as-of timestamp Asia/Ho_Chi_Minh, phiên bản artifact và truy vết nguồn

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

flowchart TB
    A[Phát hiện KPI hoặc báo cáo có rủi ro] --> B{Có thể dẫn tới quyết định sai, mất dữ liệu, lộ dữ liệu hoặc claim thẩm quyền sai?}

    B -- Không --> C[BA sửa mô tả, liên kết hoặc cách trình bày]
    C --> D[Lưu traceability]
    D --> E{Nội dung cần xác nhận chuyên môn?}
    E -- Có --> F[Chuyển owner phù hợp xác nhận phần thuộc phạm vi]
    F --> G[Sửa phần đã được xác nhận]
    G --> H[Lưu traceability phần sửa]
    H --> I[Giữ artifact IN_REVIEW]
    E -- Không --> I

    B -- Có --> J[Dừng công bố hoặc sử dụng KPI]
    J --> K[Giữ snapshot dữ liệu tổng hợp và bằng chứng công thức]
    K --> L[Xác định owner có thẩm quyền]
    L --> M{Có claim approval không có bằng chứng?}
    M -- Có --> N[Xóa claim approval và giữ IN_REVIEW]
    M -- Không --> O{Lỗi liên quan nguồn dữ liệu hoặc trường dữ liệu?}
    N --> O
    O -- Có --> P[Xác định nguồn và trường canonical trong CANONICAL_DATA_DICTIONARY]
    O -- Không --> Q{Có mất dữ liệu hoặc lộ dữ liệu không phải dữ liệu cá nhân?}
    P --> Q

    Q -- Có --> R[Owner có thẩm quyền xác minh xử lý mất hoặc lộ dữ liệu]
    Q -- Không --> S{Liên quan VND, doanh thu, chi phí, biên lợi nhuận, thuế hoặc hóa đơn?}
    R --> S
    S -- Có --> T[Accounting Owner xác minh diễn giải tài chính]
    S -- Không --> U{Liên quan nghĩa vụ pháp lý hoặc mức tuân thủ?}
    T --> U
    U -- Có --> V[Legal/Compliance Owner xác minh diễn giải hoặc kiểm soát chuyên môn]
    U -- Không --> W{Có dữ liệu cá nhân?}
    V --> W
    W -- Có --> X[Privacy Owner xác minh kiểm soát dữ liệu cá nhân]
    W -- Không --> Y{KPI cần Business Owner xác nhận?}
    X --> Y
    Y -- Có --> Z[Business Owner xác nhận định nghĩa KPI]
    Y -- Không --> AA[Owner có thẩm quyền xác nhận phần cần đính chính]
    Z --> AB[Đính chính theo phần đã được xác nhận]
    AA --> AB

    AB --> AC[Tính lại và ghi phiên bản thay đổi]
    AC --> AD[Giữ công thức cũ và mới; không ghi đè artifact kiểm soát]
    AD --> AE[Owner đã xác nhận phần liên quan kiểm tra kết quả tính lại]
    AE --> AF{Định nghĩa hoặc nguồn đã được owner phù hợp xác nhận; kết quả đã kiểm tra; snapshot và lịch sử phiên bản được giữ?}
    AF -- Có --> AG[Tái phát hành có ghi thay đổi]
    AF -- Không --> AH[Tiếp tục dừng công bố hoặc sử dụng KPI]

Ranh giới dừng: BA được sửa mô tả, liên kết và cách trình bày trong /02-handbook/15-reporting-biometrics-and-kpi-definition.md; BA không tự xác nhận diễn giải kế toán, nghĩa vụ pháp lý, mức tuân thủ, hoặc approval. Khi KPI dùng số tiền VND, ghi nhận doanh thu, chi phí, biên lợi nhuận, thuế, hóa đơn hoặc dữ liệu cá nhân, cần xác minh với Accounting Owner, Legal/Compliance Owner hoặc Privacy Owner phù hợp.

Core — Phân tách năm lỗi làm hỏng định nghĩa KPI

Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. Một KPI chỉ kiểm thử và truy vết được khi mỗi câu khẳng định chỉ rõ nghĩa, phạm vi dữ liệu, thẩm quyền, ký pháp và liên kết nguồn. IN_REVIEW tại v0.9.0 ngày 2026-08-07 cho biết artifact còn xem xét; không chứng minh baseline, phê duyệt hay hiệu lực vận hành.

Loại lỗi	Biểu hiện quan sát được	Vì sao sai	Sửa trong artifact
Mơ hồ	“Doanh thu giao đúng hạn” không nêu mốc giao, đơn vị tính, tập đơn	Hai người có thể tính hai kết quả đúng theo hai cách khác nhau	Ghi công thức, trường dữ liệu, điều kiện bao gồm/loại trừ, mốc thời gian
Thiếu thông tin	Có công thức % giao đúng hạn nhưng không nêu xử lý đơn hủy, giao một phần, dữ liệu trễ	Không tạo được tập kiểm thử đầy đủ	Bổ sung quy tắc biên, dữ liệu đầu vào, tần suất chốt và chủ sở hữu xác nhận
Khẳng định thẩm quyền không có bằng chứng	“Theo luật, phải giữ KPI này 10 năm” nhưng không có kết luận Legal Owner	BA biến giả định thành nghĩa vụ pháp lý	Gắn Verification required; chuyển tới Legal Owner; không đưa vào acceptance criterion bắt buộc
Dùng sai ký pháp	Sơ đồ PlantUML activity được ghi là BPMN; % dùng cho cả tỷ lệ và điểm phần trăm	Người đọc suy ra sai ngữ nghĩa mô hình hoặc sai đơn vị	Ghi đúng loại sơ đồ; dùng tỷ lệ = 0,95 hoặc tỷ lệ phần trăm = 95%, không trộn
Đứt truy vết	KPI ghi KPI-OTD-01 nhưng không liên kết requirement, rule, data field, test	Không chứng minh được số đo đến từ đâu hoặc thay đổi ảnh hưởng gì	Liên kết đúng ID canonical trong TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY

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

flowchart TB
  R[Canonical Requirement ID<br/>TRACEABILITY_ID_REGISTRY]
  B[Canonical Business Rule ID<br/>CANONICAL_BUSINESS_RULES]
  D[Canonical Data Field ID<br/>CANONICAL_DATA_DICTIONARY]
  K[KPI Definition ID]

  R --- K
  B --- K
  D --- K
  K --> T[Test Case ID]
  K --> A[Report Artifact ID]

Cảnh báo: Không thay nhãn Verification required bằng câu “đã tuân thủ”. Với dữ liệu cá nhân, kế toán, thuế, an toàn thực phẩm hoặc truy xuất nguồn gốc, suy diễn không có xác nhận từ vai trò có thẩm quyền có thể tạo yêu cầu sai và thiết kế sai.

Applied

Mục	Nội dung
Facts	Báo cáo mô phỏng Nova Foods ghi: KPI-OTD-01 = đơn giao đúng hạn / tổng đơn. Không có định nghĩa “đúng hạn”, không có nguồn trường dữ liệu, và ghi “đã được Finance phê duyệt”.
Current Behavior	Nhóm báo cáo lấy ActualDeliveryDate <= RequestedDeliveryDate; nhóm vận hành lấy thời điểm xe rời kho. Hai tỷ lệ khác nhau cùng xuất hiện là 95%.
Underlying Need	Cần một KPI giao hàng có kết quả lặp lại được, biết rõ dữ liệu nào tạo số và ai có quyền xác nhận quy tắc.
Options	1. Giữ hai cách tính. 2. Chọn một cách tính nhưng không ghi nguồn. 3. Định nghĩa KPI, liên kết dữ liệu, giữ trạng thái xác minh thẩm quyền.
Decision Criteria	Cùng input phải cùng output; xử lý được giao một phần và đơn hủy; không suy diễn phê duyệt; liên kết được tới ID canonical.
Decision	Chọn phương án 3. Ghi: KPI-OTD-01 chỉ tính dòng giao hoàn tất trong kỳ; “đúng hạn” là ActualDeliveryDate <= ConfirmedDeliveryDate; đơn hủy loại trừ. Đây là quy tắc mô phỏng, cần Business Owner xác nhận trước khi thành rule vận hành.
Authority	Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact. Business Owner xác nhận nghĩa nghiệp vụ; Data Owner xác nhận trường nguồn; Legal, Accounting hoặc Compliance Owner xác nhận phần thuộc phạm vi họ.
Artifact	Liên kết KPI-OTD-01 tới requirement, rule và field bằng ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tự tạo biến thể ID.
Consequence if Wrong	Báo cáo có thể thúc đẩy giao sớm sai cam kết, che dữ liệu giao một phần, hoặc bị trình bày nhầm là số đã phê duyệt.
Safe recovery boundary	Dừng phát hành KPI như số chính thức. Giữ dữ liệu thô, ghi phiên bản công thức, gắn IN_REVIEW, mở vấn đề xác nhận. Không sửa lịch sử để làm hai kết quả cũ trông giống nhau.

Senior Lens

Cầu nối suy luận phải nhìn thấy được: câu “giao đúng hạn” là khái niệm; ActualDeliveryDate và ConfirmedDeliveryDate là bằng chứng dữ liệu; toán tử <= là quy tắc tính; KPI-OTD-01 là định danh báo cáo. Thiếu một mắt xích, kết quả không còn chứng minh được.

Không dùng tên vai trò như bằng chứng. “Finance”, “Legal” hoặc “Management” trong ghi chú không phải approval reference. Bằng chứng tối thiểu cần artifact kiểm soát, người có thẩm quyền, trạng thái và tham chiếu quyết định. Nếu chưa có, ghi đúng trạng thái: IN_REVIEW hoặc Verification required.

Quick Reference

Kiểm tra trước khi giữ KPI	Đạt khi
Nghĩa	Người mới diễn đạt lại được cùng một cách
Đủ thông tin	Có công thức, đơn vị, kỳ đo, biên xử lý, nguồn dữ liệu
Thẩm quyền	Không có câu “đã phê duyệt” khi thiếu approval reference
Ký pháp	Tên sơ đồ và ký hiệu toán học đúng nghĩa
Truy vết	Từ KPI đi được tới requirement, rule, data và test qua ID canonical

11. Senior BA Notes & Rules of Thumb

Senior Lens

KPI tốt không phải KPI có công thức phức tạp. KPI tốt tạo cùng một kết quả khi cùng dữ liệu, cùng kỳ đo và cùng quy tắc. Với Nova Foods mô phỏng, Senior BA tách ba lớp: ý nghĩa nghiệp vụ, bằng chứng dữ liệu và quyết định quản trị. Ví dụ, KPI-OTD-01 chỉ đáng tin khi “đúng hạn”, ngày cam kết, ngày giao thực tế, đơn vị đo và biên giao một phần đều được ghi rõ. Không suy ra ý nghĩa từ tên cột.

Tình huống xung đột	Trade-off cần phân tích	Bằng chứng cần có	Thẩm quyền quyết định
Sales muốn tính đơn giao một phần là đúng hạn	KPI cao hơn nhưng có thể che phần hàng chưa giao	Định nghĩa cam kết giao hàng, mẫu đơn hàng tổng hợp, quy tắc xử lý giao một phần	Business Owner
Operations muốn loại đơn bị thiếu dữ liệu ngày giao	Chỉ số sạch hơn nhưng giảm khả năng thấy lỗi dữ liệu	Tỷ lệ bản ghi thiếu, nguồn trường, nguyên nhân thiếu	Business Owner quyết định phạm vi; Data Owner xác nhận nguồn
Finance yêu cầu đối chiếu doanh thu theo kỳ	Kỳ KPI vận hành có thể khác kỳ ghi nhận kế toán	Quy tắc kỳ báo cáo, dữ liệu tổng hợp, diễn giải từ Accounting Owner	Accounting Owner
Legal hoặc Compliance nêu rủi ro dữ liệu cá nhân	Báo cáo chi tiết giúp điều tra nhưng tăng rủi ro lộ dữ liệu	Phân loại dữ liệu, mục đích sử dụng, kiểm soát truy cập	Legal/Compliance Owner; Security Owner
Architect nêu độ trễ đồng bộ ERP	Báo cáo gần thời gian thực có thể dùng dữ liệu chưa hoàn tất	Tần suất đồng bộ, dấu thời gian, trạng thái dữ liệu	Architect; Business Owner chấp nhận mức trễ nghiệp vụ

Ngoại lệ không được biến thành quy tắc ngầm. Nếu ActualDeliveryDate đến từ giao diện quét kho nhưng chưa có bằng chứng giao nhận cuối cùng, Senior BA không gọi dữ liệu là “ngày giao thực tế đã xác nhận”. Ghi: “Dữ liệu quan sát được từ nguồn quét kho; cần xác minh quan hệ với sự kiện giao nhận.” Cách ghi này bảo toàn sự thật dữ liệu, không đẩy kết luận vận hành sang người đọc.

Độ mạnh bằng chứng quyết định độ mạnh khuyến nghị. Một ảnh chụp màn hình, trao đổi miệng hoặc một lần chạy báo cáo chỉ là tín hiệu. Nguồn đáng tin hơn gồm artifact kiểm soát có phiên bản, mẫu dữ liệu tổng hợp truy xuất được, định nghĩa trường từ CANONICAL_DATA_DICTIONARY, quy tắc từ CANONICAL_BUSINESS_RULES, và liên kết ID trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Nếu các nguồn mâu thuẫn, không lấy nguồn mới hơn làm đúng mặc định; lập vấn đề, nêu mâu thuẫn và chuyển đúng chủ thể có thẩm quyền.

Senior BA khuyến nghị theo mẫu: “Khuyến nghị dùng mẫu số gồm đơn hoàn tất trong kỳ, vì báo cáo hiện hữu cho thấy trạng thái hoàn tất phân biệt được đơn hủy trong dữ liệu tổng hợp. Độ tin cậy trung bình vì chưa có tham chiếu quyết định của Business Owner về đơn giao một phần. Trạng thái: IN_REVIEW; Verification required với quy tắc giao một phần.” Khuyến nghị có lý do, giới hạn và điều kiện thay đổi; không có tuyên bố chắc chắn giả tạo.

Không áp dụng quy tắc “một KPI, một chủ sở hữu” khi KPI đồng thời quyết định vận hành, kế toán hoặc nghĩa vụ pháp lý. Một vai trò có thể sở hữu mục tiêu nghiệp vụ, nhưng định nghĩa và phát hành vẫn cần xác nhận theo ranh giới chuyên môn. Escalate khi công thức đổi làm thay đổi doanh thu, nghĩa vụ pháp lý, quyền truy cập dữ liệu cá nhân, truy xuất thực phẩm, hoặc khi hai nguồn canonical cho kết quả khác nhau.

Senior Lens

Senior BA không xem KPI chỉ là công thức. KPI là cam kết đo lường dùng để quyết định. Trước khi chấp nhận định nghĩa, kiểm tra đủ năm điểm: mục tiêu nghiệp vụ, đối tượng đo, nguồn dữ liệu, thời điểm chốt dữ liệu, quyền quyết định khi số liệu mâu thuẫn. Ví dụ, “Tỷ lệ giao hàng đúng hẹn” chỉ đáng dùng nếu đơn hàng, ngày hứa giao và thời điểm giao thực tế có định nghĩa thống nhất; thiếu một điểm, tỷ lệ vẫn tính được nhưng không đủ tin cậy để đánh giá vận hành.

Heuristic review cấp Senior	Kiểm tra cụ thể	Dấu hiệu đỏ	Ngưỡng escalation	Không áp dụng quy tắc thường khi
Một KPI, một mục tiêu quyết định	Ghi rõ quyết định nào dùng KPI: điều phối giao hàng, đánh giá nhà máy, dự báo tồn kho	Một KPI phục vụ đồng thời thưởng cá nhân, báo cáo tài chính và cảnh báo vận hành	Mỗi bên dùng cùng KPI để ra quyết định trái ngược	Cần dashboard điều hành tổng quan; vẫn phải tách chỉ số thành phần và không dùng nó làm chỉ tiêu thưởng
Công thức phải tái lập	Cùng dữ liệu đầu vào phải cho cùng kết quả ở mọi lần chạy	Công thức chứa “xử lý thủ công”, “loại trừ hợp lý”, hoặc không nêu múi giờ	Hai lần chạy cùng kỳ lệch bất kỳ giá trị nào chưa giải thích được	Báo cáo khám phá dữ liệu; phải gắn nhãn không dùng cho quyết định kiểm soát
Mẫu số phải phản ánh phạm vi	Nêu điều kiện đưa bản ghi vào và loại ra	Mẫu số bằng 0, thay đổi theo người lập báo cáo, hoặc loại trừ đơn không có lý do	Tỷ lệ loại trừ vượt 5% số bản ghi kỳ báo cáo	Sự cố dữ liệu đã được xác nhận; báo cáo riêng tỷ lệ loại trừ và không che số liệu gốc
Nguồn có thể truy vết	Mỗi trường KPI liên kết nguồn canonical hoặc ghi Verification required	Dùng file cá nhân, ảnh chụp màn hình, hoặc số tổng hợp không có khóa đối chiếu	Không truy được nguồn cho bất kỳ trường đầu vào trọng yếu nào	Báo cáo tạm phục vụ xử lý sự cố; ghi rõ thời hạn dùng và owner xác minh
Quyền quyết định đúng vai trò	Business Owner quyết định mục tiêu; Data Owner xác nhận nghĩa dữ liệu; Finance, Legal, Security xác nhận phần thuộc thẩm quyền	BA tự chọn ngưỡng, tự diễn giải kế toán hoặc gọi nội dung là tuân thủ	KPI tác động tiền, dữ liệu cá nhân, nghĩa vụ pháp lý, an toàn thực phẩm, hoặc quyền truy cập	Không có ngoại lệ thẩm quyền; chỉ có thể ghi giả định dự án và mở escalation

Không dùng quy tắc “càng nhiều dữ liệu càng tốt” khi dữ liệu không liên quan quyết định hoặc làm lộ dữ liệu cá nhân. Nova Foods là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; mọi KPI liên quan dữ liệu cá nhân phải dừng ở mức thiết kế học liệu và ghi Verification required cho Legal Owner, Security Owner và Data Owner. Không suy diễn nghĩa vụ pháp lý từ tên KPI, vì nguồn pháp lý cần được người có thẩm quyền xác minh.

Escalation không chờ đến cuối kỳ báo cáo. Mở vấn đề khi có một trong các điều kiện: KPI thay đổi hành vi thưởng hoặc phạt; chênh lệch giữa hai nguồn vượt 1% mẫu số hoặc vượt 1.000.000 VND trong dữ liệu mô phỏng; hơn 5% bản ghi bị loại; dữ liệu bị trễ quá kỳ chốt; định nghĩa “đúng hẹn”, “hoàn thành”, “doanh thu” hoặc “tồn kho” khác nhau giữa các bên; hoặc KPI được dùng để kết luận về kế toán, thuế, pháp lý, bảo mật hay an toàn thực phẩm. Ngưỡng 1% và 1.000.000 VND là giả định dự án cho Nova Foods mô phỏng, không phải chuẩn pháp lý hay ngưỡng vận hành thực tế.

Khi Sales muốn giữ đơn giao trễ do khách đổi lịch ngoài mẫu số nhưng Operations muốn giữ để phản ánh tải giao hàng, Senior BA không chọn bên thắng bằng ý kiến. Tách hai câu hỏi: hiệu quả cam kết nội bộ và trải nghiệm giao hàng của khách. Bằng chứng cần có là quy tắc ghi nhận ngày hứa giao, lý do đổi lịch, thời điểm đổi và nguồn lưu từng dữ liệu. Nếu bằng chứng chưa đủ, khuyến nghị dùng hai chỉ số tạm: tỷ lệ đúng hẹn theo ngày hứa ban đầu và tỷ lệ đúng hẹn theo ngày hứa mới, cả hai gắn nhãn giả định dự án. Business Owner quyết định KPI nào dùng điều hành; Data Owner xác nhận khả năng lấy dữ liệu; BA ghi nhận xung đột, bằng chứng, phương án và tác động.

Red flag lớn nhất là số đẹp nhưng không kiểm chứng được. Senior BA yêu cầu mỗi KPI có dấu vết tối thiểu: mã KPI, phiên bản định nghĩa, kỳ báo cáo, nguồn đầu vào, quy tắc loại trừ, người sở hữu dữ liệu, thời điểm trích xuất theo Asia/Ho_Chi_Minh, và trạng thái xác minh. Không gọi KPI là “chính thức”, “đã phê duyệt” hoặc “tuân thủ” khi artifact còn IN_REVIEW, Version v0.9.0, ngày 2026-08-07, chưa có baseline reference và chưa có approval reference.

Senior Lens

Senior BA không biến thiếu bằng chứng thành kết luận. Với Nova Foods mô phỏng, dữ liệu tổng hợp, khuyến nghị phải tách rõ fact (sự kiện có nguồn), inference (suy luận từ fact), assumption (giả định chưa xác minh) và verification required (cần xác minh). Cách viết này cho người đọc biết phần nào đủ dùng để quyết định, phần nào không được hiểu là quy tắc ERP, nghĩa vụ pháp lý, kết luận kế toán hay phê duyệt.

Thành phần ghi nhận	Nội dung artifact-ready
Vấn đề	KPI OTIF chưa thống nhất mốc “giao hàng” để đo.
Fact	/01-curriculum/CANONICAL_DATA_DICTIONARY.md đang là kế hoạch IN_REVIEW, v0.9.0; không cung cấp baseline cho trường thời gian giao hàng.
Inference	Không có định nghĩa canonical đã baseline nên không thể kết luận dùng ActualDeliveryDate, thời điểm xuất kho, hay thời điểm khách nhận hàng.
Assumption	Ví dụ học liệu tạm dùng thời điểm khách xác nhận nhận hàng để minh họa công thức.
Verification required	Business Owner xác nhận ý nghĩa dịch vụ; Architect xác nhận nguồn timestamp; Accounting Owner xem xét khi KPI tác động ghi nhận doanh thu.
Khuyến nghị	Không công bố KPI vận hành chính thức. Chỉ ghi “candidate definition” trong tài liệu học liệu, kèm danh sách xác minh.
Mức tin cậy	Thấp, vì thiếu nguồn canonical và thiếu quyết định có thẩm quyền.
Hệ quả nếu sai	Báo cáo có thể gọi đơn đã xuất kho là giao đúng hẹn dù khách chưa nhận; quản lý ra quyết định sai từ KPI.

Mẫu câu phòng thủ được phép dùng: “Dựa trên dữ liệu tổng hợp hiện có, phương án này phù hợp để minh họa; chưa đủ bằng chứng để xác nhận đây là định nghĩa Nova Foods.” Không dùng “đã thống nhất”, “bắt buộc”, “tuân thủ”, “đúng theo luật” hoặc “được phê duyệt” khi artifact IN_REVIEW không có tham chiếu approval hoặc baseline.

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

flowchart TB
    A[Fact có nguồn và ngày ghi nhận] --> B[BA nêu inference]
    B --> C{Đủ bằng chứng về nguồn dữ liệu<br/>và quy tắc tính?}

    C -- Không --> D[Ghi assumption chưa xác minh]
    D --> J[Candidate definition chỉ dùng cho học liệu<br/>khi chưa đủ xác minh]
    D --> R[Rủi ro: coi xuất kho là giao hàng,<br/>làm sai OTIF và quyết định quản lý]
    J --> E[Verification required]

    C -- Có --> F{Có quyết định có thẩm quyền<br/>trong artifact kiểm soát?}
    F -- Không --> E
    F -- Có --> L[Artifact kiểm soát ghi nguồn dữ liệu,<br/>quy tắc tính và chủ thể quyết định]
    L --> M{Artifact có approval hoặc baseline?}
    M -- Không --> E
    M -- Có --> N[Được dùng định nghĩa KPI]
    N --> O[KPI vận hành chính thức]

    E --> G[Business Owner xác nhận ý nghĩa dịch vụ]
    E --> H[Architect xác nhận nguồn timestamp]
    G --> V{Business Owner và Architect<br/>đều đã xác nhận?}
    H --> V
    V -- Không --> E
    V -- Có --> P{KPI có tác động<br/>ghi nhận doanh thu?}

    P -- Có --> I[Accounting Owner xem xét]
    I --> W{Accounting Owner<br/>đã xem xét?}
    W -- Không --> E
    W -- Có --> Q[Cập nhật artifact kiểm soát]

    P -- Không --> Q
    Q --> C

Khuyến nghị phòng thủ phải nêu điều kiện hiệu lực: “Chỉ dùng định nghĩa KPI sau khi nguồn dữ liệu, quy tắc tính và chủ thể quyết định được ghi nhận trong artifact kiểm soát.” Điều này không trì hoãn phân tích; nó ngăn BA biến ví dụ, ý kiến stakeholder, hoặc dữ liệu thiếu ngữ cảnh thành nguồn chân lý.

12. Associated Template Reference & Completed Artifact

Core

Template là biểu mẫu có cấu trúc để ghi nhận dữ liệu nhất quán. Template ID là mã nhận diện ổn định; filename là vị trí tệp được kiểm soát. Hai thứ không thay thế nhau: ID giữ traceability, filename cho biết nơi đọc artifact.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, không có bằng chứng trong nguồn được cấp về template KPI đã đăng ký với ID và filename riêng. Vì vậy không được tự tạo mã như KPI_TEMPLATE_001, không gọi bản nháp là canonical template, không suy diễn artifact đã hoàn tất.

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

flowchart TB
    A[Nhu cầu định nghĩa KPI] --> B{Template ID và filename đã đăng ký?}
    B -- Có --> C[Dùng template đúng ID và đường dẫn]
    B -- Không --> D[Chỉ dùng nguồn đã được cấp làm tham chiếu]
    D --> E[Ghi nhận ID và filename cần xác minh trước khi sử dụng]
    E --> F[Không tự tạo Template ID]
    F --> G[Không suy diễn artifact đã hoàn tất]

Applied

Thành phần	Nội dung
Facts	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md là planned template manifest, trạng thái IN_REVIEW, version v0.9.0. Nguồn cấp không nêu ID hoặc filename riêng cho template reporting, biometrics hoặc KPI.
Current Behavior	Chapter có thể tham chiếu artifact kiểm soát hiện hữu để giữ nguồn chân lý, nhưng chưa có template KPI được đăng ký để điền.
Underlying Need	Người viết cần nơi chuẩn để ghi định nghĩa KPI, nguồn dữ liệu, công thức, owner, tần suất và điều kiện kiểm tra.
Options	Dùng template KPI đã đăng ký; dùng artifact canonical liên quan làm nguồn tham chiếu; tự đặt template ID mới.
Decision Criteria	ID và filename phải có trong nguồn canonical; owner phải thuộc thẩm quyền; quality gate phải kiểm tra được; không biến kế hoạch thành approval.
Decision	Chỉ map các artifact đã có ID và filename xác minh được. Không tạo template KPI mới trong chapter này.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì manifest và traceability; không có quyền tự baseline, approval, quyết định nghiệp vụ, kế toán, pháp lý hoặc production.
Artifact	TEMPLATE_MANIFEST — /01-curriculum/TEMPLATE_MANIFEST.md; TRACEABILITY_ID_REGISTRY — /01-curriculum/TRACEABILITY_ID_REGISTRY.md; CANONICAL_BUSINESS_RULES — /01-curriculum/CANONICAL_BUSINESS_RULES.md; CANONICAL_DATA_DICTIONARY — /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Template chưa đăng ký có thể tạo ID trùng, công thức KPI không truy được nguồn, hoặc bị hiểu sai là yêu cầu Nova Foods đã được phê duyệt.

Senior Lens

Không dùng CANONICAL_BUSINESS_RULES để thay template khi cần cấu trúc nhập liệu lặp lại. Artifact này là catalog quy tắc canonical dự kiến, không phải bằng chứng rằng KPI rule đã tồn tại. Không dùng CANONICAL_DATA_DICTIONARY để quyết định business meaning của KPI; nó phục vụ định nghĩa dữ liệu logic. Không dùng TRACEABILITY_ID_REGISTRY để chứa công thức; registry kiểm soát định danh và liên kết.

Cầu nối suy luận: template KPI chưa được map vì TEMPLATE_MANIFEST là nguồn phân loại planned template, nhưng compact dependency không cung cấp dòng đăng ký template KPI. Thiếu dòng đăng ký nghĩa là thiếu ID, filename, owner và quality gate xác minh được. Kết luận phù hợp là “Verification required”, không phải “không cần template”.

Quick Reference

Template hoặc artifact ID	Filename canonical	Dùng khi	Không dùng khi	Owner quản trị	Consumer chính	Quality gate tối thiểu
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Cần xác minh template ID, filename, phạm vi template dự kiến và trạng thái đăng ký.	Cần định nghĩa KPI, công thức hoặc quyết định nghiệp vụ.	Principal IT Business Analyst / Technical Curriculum Author	BA tác giả chapter, curriculum reviewer	ID và filename phải khớp manifest; trạng thái phải còn IN_REVIEW; không diễn giải là baseline hoặc approval.
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm tra ID, liên kết requirement-rule-data-test và owner escalation.	Cần tạo ID mới khi chưa có đăng ký canonical.	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, Technical Architect	Giữ nguyên chuỗi ID; không dùng biến thể dịch; escalation khi ID tác động pháp lý, kế toán, bảo mật, kiến trúc hoặc vận hành.
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	KPI phụ thuộc điều kiện nghiệp vụ, ngoại lệ, ngưỡng hoặc cách diễn giải business event.	Cần xác nhận rule là quyết định Nova Foods thực tế hoặc đã phê duyệt.	Principal IT Business Analyst / Technical Curriculum Author	Business Owner, BA, QA reviewer	Rule phải có nguồn, trạng thái, chủ thể xác minh và liên kết traceability; thiếu căn cứ phải gắn Verification required.
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	KPI cần xác định entity, field, kiểu dữ liệu, timestamp, grain và nguồn dữ liệu logic.	Cần suy ra công thức, SLA hoặc ý nghĩa nghiệp vụ từ tên field.	Principal IT Business Analyst / Technical Curriculum Author	Data analyst, BA, Architect, QA reviewer	Field phải giữ đúng tên canonical; grain và timestamp phải đủ để tính; khác biệt giữa source system phải được ghi nhận.
Chưa có ID template KPI được xác minh	Chưa có filename template KPI được xác minh	Cần đề xuất đăng ký template mới qua governance corpus.	Không tự tạo file, ID, version hoặc tuyên bố có completed template.	Principal IT Business Analyst / Technical Curriculum Author điều phối; thẩm quyền nội dung thuộc owner chuyên môn phù hợp	BA tác giả, curriculum reviewer	Manifest phải có ID, filename, owner, phạm vi, dependency và quality gate trước khi chapter tham chiếu như template.

Core

Checklist tra cứu chương này xác nhận người học đang đọc đúng artifact, đúng trạng thái và đúng nguồn kiểm soát. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi số liệu KPI, tiền tệ VND và tên quy trình chỉ là dữ liệu tổng hợp. Artifact đã điền nội dung chương nằm tại /02-handbook/15-reporting-biometrics-and-kpi-definition.md, Section 12; trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh.

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

flowchart TB
    A[Artifact hướng dẫn: checklist tra cứu] --> B[Tra artifact đã điền<br/>/02-handbook/15-reporting-biometrics-and-kpi-definition.md]
    B --> C{Đúng Section 12?}
    C -- Không --> X[Không xác nhận<br/>Tra lại đúng Section 12]
    C -- Có --> D{Metadata khớp?<br/>IN_REVIEW · v0.9.0 · 2026-08-07<br/>vi-VN · Asia/Ho_Chi_Minh}
    D -- Không --> Y[Không xác nhận<br/>Tra lại metadata artifact]
    D -- Có --> E{Đúng nguồn kiểm soát?<br/>Artifact đã điền tại đường dẫn trên}
    E -- Không --> Z[Không xác nhận<br/>Không dùng artifact khác]
    E -- Có --> F[Áp dụng boundary Nova Foods:<br/>case mô phỏng; KPI, VND, tên quy trình<br/>là dữ liệu tổng hợp]
    F --> G[Xác nhận người học đọc đúng artifact,<br/>đúng trạng thái, đúng nguồn kiểm soát]

Applied

Facts: Chapter nói về reporting biometrics và KPI. KPI, Key Performance Indicator, là chỉ số đo mức đạt mục tiêu. Biometrics trong ngữ cảnh này là tín hiệu vận hành đo được, không phải dữ liệu sinh trắc học cá nhân.

Current Behavior: Người học có thể nhầm filename chapter với nguồn canonical của ID, quy tắc hoặc định nghĩa dữ liệu.

Underlying Need: Mỗi KPI phải truy ngược được từ chapter đến artifact kiểm soát. Bằng chứng là CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY được phân loại là nguồn canonical riêng.

Options: Dùng trí nhớ; sao chép registry vào chapter; dùng checklist liên kết.

Decision Criteria: Không đổi canonical ID; không tạo nguồn chân lý thứ hai; đủ đường dẫn để kiểm tra; không diễn giải IN_REVIEW thành phê duyệt.

Decision: Dùng checklist dưới đây. Không sao chép toàn bộ registry.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết artifact. Owner này không xác nhận KPI là quyết định vận hành, kế toán, pháp lý hoặc production.

Artifact: /02-handbook/15-reporting-biometrics-and-kpi-definition.md.

Consequence if Wrong: KPI có thể dùng sai ID, sai định nghĩa dữ liệu, sai business rule hoặc bị hiểu nhầm là chỉ số đã được Nova Foods phê duyệt.

Senior Lens

#	Điểm tra cứu bắt buộc	Vị trí canonical	Kiểm tra đạt
1	Định danh chapter, filename, dependency	/01-curriculum/CHAPTER_MANIFEST.md	Chapter 15 khớp filename hiện hành
2	Trạng thái, version, ngày corpus	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	IN_REVIEW, v0.9.0, 2026-08-07
3	Boundary nguồn, chuẩn, pháp lý	/00-research/00_SOURCE_MAP.md	Không suy diễn clause, nghĩa vụ pháp lý hoặc compliance
4	ID requirement, KPI, data, rule khi được tham chiếu	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Giữ nguyên ID canonical; không tự tạo biến thể
5	Quy tắc nghiệp vụ tác động công thức KPI	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Không biến assumption thành rule vận hành
6	Entity, field, định nghĩa và chất lượng dữ liệu KPI	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Không tự suy ra nguồn dữ liệu ERP
7	Template được phép dùng trong corpus	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ dùng template đã đăng ký
8	Nội dung đã điền cho Nova Foods mô phỏng	/02-handbook/15-reporting-biometrics-and-kpi-definition.md	Đọc đúng Section 12, không dùng như approval record

Quick Reference

Vị trí artifact đã điền: /02-handbook/15-reporting-biometrics-and-kpi-definition.md.

Quy tắc lookup: đọc chapter trước, rồi kiểm tra manifest, registry, rule catalog và data dictionary theo bảng. Nếu KPI nêu công thức, field, rule hoặc ID nhưng không tìm được nguồn canonical tương ứng, giữ nội dung ở mức giả định học liệu; không gán giá trị bắt buộc cho Nova Foods.

Core

Rà soát liên tệp là đối chiếu nội dung chapter với nguồn canonical để tìm mâu thuẫn trước handoff. Mục tiêu không phải xác nhận phê duyệt; mục tiêu là giữ traceability, tức khả năng lần ngược từ một phát biểu đến artifact nguồn. Áp dụng cho Nova Foods Trading & Manufacturing, case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND.

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

flowchart TB
    A[Chapter draft] --> B[Đối chiếu canonical IDs và filenames]
    B --> C[Xác nhận bằng chứng trỏ đúng tệp canonical, không dùng bản sao hoặc tên rút gọn]
    C --> D[Xác nhận trạng thái artifact là IN_REVIEW, version và source boundary]
    D --> E{Mâu thuẫn hoặc suy diễn vượt thẩm quyền?}
    E -- Không --> F[Sẵn sàng handoff review, không phải APPROVED, BASELINED, compliant hoặc production-ready]
    E -- Có --> G[Ghi issue, bằng chứng và owner escalation]
    G --> H[Người có thẩm quyền xác minh]
    H --> I{Mâu thuẫn đã được xử lý?}
    I -- Có --> B
    I -- Chưa --> H

Bằng chứng kiểm tra phải trỏ đúng tệp canonical, không dùng bản sao hoặc tên rút gọn. IN_REVIEW chỉ nói artifact đang được xem xét; không đồng nghĩa APPROVED, BASELINED, compliant hoặc production-ready.

Applied

Facts: Chapter 15 nói về reporting, biometrics và KPI cho Nova Foods mô phỏng. Upstream artifacts gồm /00-research/00_SOURCE_MAP.md, /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Current Behavior: Corpus đang IN_REVIEW tại v0.9.0; chưa có baseline reference hoặc approval reference. Nguồn pháp lý, kế toán, an toàn thực phẩm và dữ liệu cá nhân chỉ được dùng trong safe use boundary đã ghi.

Underlying Need: KPI có thể tác động quyết định vận hành, tài chính, quyền riêng tư hoặc truy xuất thực phẩm. Vì vậy chapter không được biến ví dụ học liệu thành rule vận hành hay kết luận tuân thủ.

Options: (1) Handoff khi chỉ tự kiểm tra nội dung chapter. (2) Handoff sau đối chiếu liên tệp và ghi issue. Chọn (2), vì option (1) không chứng minh ID, nguồn và thẩm quyền còn nhất quán.

Decision Criteria: Giữ nguyên canonical ID và filename; không tạo approval ngầm định; mọi suy luận pháp lý, kế toán, bảo mật, kiến trúc phải có owner xác minh; mọi KPI phải phân biệt dữ liệu tổng hợp với dữ liệu thực.

Decision: Chỉ handoff khi bảng kiểm dưới đây hoàn tất, issue được ghi rõ, và mục cần xác minh có escalation owner.

Authority: Principal IT Business Analyst / Technical Curriculum Author điều phối review và giữ traceability. Business Owner, Legal Owner, Accounting Owner, Security Owner, Architect và QA Reviewer giữ thẩm quyền kết luận theo lĩnh vực; không vai trò nào được suy diễn thay vai trò khác.

Artifact: Ghi kết quả trong chapter review record gắn với /02-handbook/15-reporting-biometrics-and-kpi-definition.md; tham chiếu nguyên dạng các artifact nguồn.

Consequence if Wrong: KPI bị gắn sai rule có thể làm learner hiểu nhầm dữ liệu mô phỏng là chỉ dẫn ERP thực, nhầm IN_REVIEW thành phê duyệt, hoặc dùng diễn giải pháp lý/kế toán chưa được xác minh.

Senior Lens

Hạng mục tự review	Bằng chứng phải kiểm	Kết quả hiện hành	Escalation owner
Định danh và đường dẫn	CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY	Verification required: cần xác nhận chapter ID và filename được đăng ký đúng	Principal IT Business Analyst / Technical Curriculum Author
Trạng thái và version	Metadata nguồn đều ghi IN_REVIEW, v0.9.0	Pass về diễn đạt: không gọi baseline hoặc approval	Principal IT Business Analyst / Technical Curriculum Author
Quy tắc KPI	CANONICAL_BUSINESS_RULES	Open issue: không được coi ngưỡng KPI là quyết định vận hành thật	Business Owner
Định nghĩa dữ liệu KPI	CANONICAL_DATA_DICTIONARY	Verification required: field, công thức, grain và kỳ đo cần nguồn canonical	Data Owner và Architect
Dữ liệu cá nhân trong reporting	Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP	Verification required: mọi yêu cầu xử lý dữ liệu cá nhân cần xác minh pháp lý	Legal Owner và Security Owner
Số liệu tài chính, doanh thu, chi phí	Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP	Verification required: không suy diễn cách hạch toán, hóa đơn hoặc thuế	Accounting Owner và Legal Owner
KPI chất lượng, truy xuất, recall	Luật 55/2010/QH12	Verification required: không khẳng định nghĩa vụ an toàn thực phẩm từ ví dụ	Food Safety Domain Owner và Legal Owner
Kiểm thử báo cáo	ISTQB CTFL Syllabus v4.0.1	Open issue: tiêu chí kiểm thử KPI cần test basis được traceable	QA Reviewer
API hoặc tích hợp nguồn KPI	OpenAPI Specification 3.1.1; OWASP API Security Top 10 2023	Verification required: chỉ Architect và Security Owner xác nhận contract, quyền truy cập, rủi ro	Architect và Security Owner

Quy tắc dừng: không handoff như nội dung hoàn tất nếu một KPI thiếu nguồn dữ liệu, thiếu owner nghiệp vụ, đổi canonical ID, hoặc chứa kết luận pháp lý, kế toán, bảo mật, an toàn thực phẩm chưa xác minh. Principal IT Business Analyst / Technical Curriculum Author lập gói issue gồm phát biểu bị ảnh hưởng, artifact nguồn, lý do mâu thuẫn, tác động học liệu và owner; vai trò này không tự đóng issue chuyên môn.

Quick Reference

• Cross-file review tối thiểu: metadata, canonical ID, filename, source classification, traceability, authority boundary, nhãn Verification required.
• Open issues hiện có: ngưỡng KPI vận hành; test basis cho KPI.
• Verification-required hiện có: data definition; privacy; accounting/tax; food safety; API/integration security.
• Handoff condition: không có phát biểu vượt thẩm quyền hoặc làm mất traceability; mọi issue có escalation owner ghi rõ.