BA Atlas — 48 bài học

# BA 101 — 48 bài học từ số 0 đến áp dụng

> Đây là sách học, không phải curriculum tóm tắt. Case xuyên suốt: **một doanh nghiệp xử lý đơn hàng chậm, hay sai và khó đối soát**. Đọc theo thứ tự vì mỗi lớp là đầu vào của lớp kế tiếp.

# Route 1 — Foundation & problem framing

Ở giai đoạn này, BA học cách dừng solution-first. Với case đơn hàng chậm, câu “cần mua hệ thống mới” chỉ là một giả thuyết; việc đầu tiên là xác định outcome, evidence và nguyên nhân có thể tác động.

```mermaid
flowchart LR
N0["SDLC"]
N1["Objective"]
N0 --> N1
N2["Problem"]
N1 --> N2
N3["Evidence"]
N2 --> N3
N4["Options"]
N3 --> N4
```

## Bài 1 — SDLC & năm vai trò

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **SDLC & năm vai trò** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Hiểu vòng đời từ ý tưởng đến vận hành. BA làm rõ nhu cầu và thay đổi; PO tối ưu giá trị sản phẩm; PM điều phối delivery; SA quyết kiến trúc; QA kiểm chứng chất lượng.

Nói đơn giản: khái niệm này giúp BA không nhìn case bằng trực giác đơn lẻ. Nó buộc bạn hỏi “điều gì đã biết, điều gì chưa biết, ai bị ảnh hưởng và nếu sai thì hậu quả là gì?”. Đó là khác biệt giữa ghi chép yêu cầu và phân tích nghiệp vụ.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng sdlc & năm vai trò, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Viết lại yêu cầu ban đầu thành problem hoặc outcome.
2. Đánh dấu evidence, assumption, constraint và decision trước khi phân tích.
3. So sánh ít nhất hai option trước khi chốt solution.

Đừng cố làm mọi thứ cùng lúc. Chọn một quyết định thật cần hỗ trợ, dùng khái niệm của bài để giảm bất định cho quyết định đó, rồi mới đi tiếp.

### Bẫy thường gặp

Đừng biến ranh giới vai trò thành “ai không làm cái gì”: dự án nhỏ thường chồng vai, nhưng quyền quyết định vẫn phải rõ.

Bẫy cấp senior là dùng một từ đúng nhưng không kèm boundary, evidence hoặc owner. Một phân tích chỉ đáng tin khi người khác có thể kiểm tra bạn đã dựa vào đâu và điều gì sẽ làm kết luận thay đổi.

### Tự kiểm tra

- Khái niệm này trả lời câu hỏi nào trong case đơn hàng?
- Evidence nào sẽ khiến bạn đổi kết luận?
- Nó khác gì với khái niệm dễ nhầm nhất?
- Output của bài này là input của bài sau ở đâu?

---

## Bài 2 — Business objective, value chain, capability

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Business objective, value chain, capability** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Objective là kết quả tổ chức muốn đạt; value chain là chuỗi hoạt động tạo giá trị; capability là năng lực ổn định để thực hiện hoạt động đó.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng business objective, value chain, capability, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Capability không phải một team, một phần mềm, hay một task. Nó trả lời “tổ chức làm được gì?”.

### Tự kiểm tra

---

## Bài 3 — Problem, solution, symptom, root cause

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Problem, solution, symptom, root cause** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Problem là trạng thái cản outcome; solution là một cách can thiệp. Symptom thấy được nhưng chưa giải thích nguyên nhân. Root cause phải có bằng chứng và khả năng tác động.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng problem, solution, symptom, root cause, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

“Cần app mới” gần như luôn là solution hypothesis, không phải problem statement.

### Tự kiểm tra

---

## Bài 4 — Fact, assumption, constraint, decision

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Fact, assumption, constraint, decision** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Fact có evidence; assumption chưa xác nhận; constraint giới hạn lựa chọn; decision đã được người có thẩm quyền chốt. RAID theo dõi risk, assumption, issue, dependency; decision log giữ lý do chốt.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng fact, assumption, constraint, decision, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Đừng ghi assumption như fact rồi thiết kế cả solution dựa trên nó.

### Tự kiểm tra

---

## Bài 5 — Opportunity brief & discovery scope

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Opportunity brief & discovery scope** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Opportunity brief đặt business context, ai bị ảnh hưởng và giá trị kỳ vọng. Discovery scope nói rõ điều cần tìm hiểu, ranh giới và câu hỏi mở.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng opportunity brief & discovery scope, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Scope discovery không phải scope build: mục tiêu của nó là giảm bất định trước.

### Tự kiểm tra

---

## Bài 6 — Outcome, KPI, capability & options

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Outcome, KPI, capability & options** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Outcome mô tả thay đổi có ích; KPI đo outcome; outcome tree nối mục tiêu với đòn bẩy; options analysis so sánh nhiều cách xử lý cùng problem.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng outcome, kpi, capability & options, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Ra mắt dashboard là output. Giảm thời gian ra quyết định mới là outcome.

### Tự kiểm tra

---

# Route 2 — People, research & process discovery

Sau khi có giả thuyết, BA phải quan sát cách công việc thực sự diễn ra. Điều người vận hành làm khác với SOP và điều quản lý tin thường là nguồn insight quan trọng nhất.

```mermaid
flowchart LR
N0["Stakeholder"]
N1["Research"]
N0 --> N1
N2["Evidence"]
N1 --> N2
N3["As-Is"]
N2 --> N3
N4["Gap"]
N3 --> N4
```

## Bài 7 — Stakeholder analysis

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Stakeholder analysis** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Phân biệt người bị ảnh hưởng, người có kiến thức, người có quyền quyết và người có thể chặn. Power/interest map chỉ là điểm bắt đầu cho engagement strategy.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng stakeholder analysis, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Chọn stakeholder theo knowledge, impact và authority.
2. Thu thập hành vi quá khứ trước khi hỏi preference.
3. Vẽ boundary và exception của As-Is process.

### Bẫy thường gặp

Người nói to nhất không nhất thiết là owner của vấn đề.

### Tự kiểm tra

---

## Bài 8 — Governance: RACI, RAPID, DACI

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Governance: RACI, RAPID, DACI** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

RACI làm rõ trách nhiệm; RAPID nhấn quyền quyết; DACI giúp điều phối quyết định. Hãy đọc kỹ chữ “D” hoặc “A”: ai thực sự chốt.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng governance: raci, rapid, daci, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Chọn stakeholder theo knowledge, impact và authority.
2. Thu thập hành vi quá khứ trước khi hỏi preference.
3. Vẽ boundary và exception của As-Is process.

### Bẫy thường gặp

Nhiều người “consulted” không biến một quyết định thành đồng thuận vô hạn.

### Tự kiểm tra

---

## Bài 9 — Research plan & sampling

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Research plan & sampling** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Research plan bắt đầu bằng quyết định cần hỗ trợ, rồi mới chọn research question, population, sample và phương pháp. Sample luôn có bias và limitation.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng research plan & sampling, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Chọn stakeholder theo knowledge, impact và authority.
2. Thu thập hành vi quá khứ trước khi hỏi preference.
3. Vẽ boundary và exception của As-Is process.

### Bẫy thường gặp

Mười người thuận tiện gặp không đại diện cho toàn bộ user base.

### Tự kiểm tra

---

## Bài 10 — Interview & observation

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Interview & observation** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Câu hỏi tốt khai thác hành vi quá khứ, bối cảnh và exception: “Lần gần nhất xảy ra là khi nào?”. Observation cho thấy work-around mà interview có thể bỏ sót.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng interview & observation, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Chọn stakeholder theo knowledge, impact và authority.
2. Thu thập hành vi quá khứ trước khi hỏi preference.
3. Vẽ boundary và exception của As-Is process.

### Bẫy thường gặp

Tránh “Anh/chị có thích tính năng X không?” vì nó dẫn dắt solution.

### Tự kiểm tra

---

## Bài 11 — Synthesis & confidence

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Synthesis & confidence** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Từ note thô đến theme, insight và implication. Insight phải nêu evidence, mức confidence và limitation; không chỉ là quote hay ý kiến của một người.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng synthesis & confidence, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Chọn stakeholder theo knowledge, impact và authority.
2. Thu thập hành vi quá khứ trước khi hỏi preference.
3. Vẽ boundary và exception của As-Is process.

### Bẫy thường gặp

Tần suất không luôn đồng nghĩa với mức tác động.

### Tự kiểm tra

---

## Bài 12 — SIPOC & value stream

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **SIPOC & value stream** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

SIPOC đặt biên process: supplier, input, process, output, customer. Value stream nhìn flow time, wait time và handoff để phát hiện lãng phí.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng sipoc & value stream, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Chọn stakeholder theo knowledge, impact và authority.
2. Thu thập hành vi quá khứ trước khi hỏi preference.
3. Vẽ boundary và exception của As-Is process.

### Bẫy thường gặp

Đừng vẽ process quá sâu khi chưa khóa được boundary.

### Tự kiểm tra

---

# Route 3 — Process, requirements & rules

Evidence chỉ tạo giá trị khi được chuyển thành process, requirement và rule mà team có thể kiểm tra. Mục tiêu là rõ ràng nhưng chưa ép team vào một implementation cụ thể.

```mermaid
flowchart LR
N0["As-Is"]
N1["Gap"]
N0 --> N1
N2["Need"]
N1 --> N2
N3["Requirement"]
N2 --> N3
N4["Rule"]
N3 --> N4
N5["Test"]
N4 --> N5
```

## Bài 13 — BPMN 2.0 để đọc flow

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **BPMN 2.0 để đọc flow** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Đọc event là chuyện kích hoạt/kết thúc, task là việc làm, gateway là rule rẽ nhánh, lane là owner. Luôn dò happy path, exception, handoff và record tạo ra.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng bpmn 2.0 để đọc flow, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Tìm trigger, owner, rule, exception và control trong flow.
2. Tách business need, functional behavior, rule, NFR và transition.
3. Kiểm impact trước khi baseline hoặc thay đổi requirement.

### Bẫy thường gặp

Gateway không phải “bước ai đó suy nghĩ”; nó biểu đạt điều kiện quyết định flow.

### Tự kiểm tra

---

## Bài 14 — As-Is, To-Be & controls

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **As-Is, To-Be & controls** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

As-Is ghi cái đang xảy ra, bao gồm workaround. To-Be chỉ thay đổi cần thiết. Control point giảm risk: approval, validation, reconciliation hoặc audit trail.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng as-is, to-be & controls, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

To-Be không phải sơ đồ đẹp hơn; phải giải quyết một gap đo được.

### Tự kiểm tra

---

## Bài 15 — Time, exception & SOP impact

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Time, exception & SOP impact** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Cycle time là thời gian xử lý; wait time là thời gian chờ. Exception thường tạo rework và control bypass. SOP impact cho biết hướng dẫn vận hành nào phải đổi.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng time, exception & sop impact, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Đừng tối ưu happy path rồi quên 20% case gây 80% đau đầu.

### Tự kiểm tra

---

## Bài 16 — Requirement taxonomy

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Requirement taxonomy** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Business requirement nói why; stakeholder requirement nói need của nhóm; functional nói system does what; NFR nói quality; transition nói chuyển đổi.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng requirement taxonomy, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Một requirement functional không tự bao hàm security, performance hay migration.

### Tự kiểm tra

---

## Bài 17 — Quality, baseline & change

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Quality, baseline & change** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Requirement tốt rõ, cần thiết, feasible, testable và traceable. Baseline là mốc đã đồng thuận; change control đánh giá impact trước khi sửa baseline.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng quality, baseline & change, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Version number không thay thế quyết định change đã được duyệt.

### Tự kiểm tra

---

## Bài 18 — Use case & requirement catalogue

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Use case & requirement catalogue** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Use case hữu ích cho main, alternate và exception flow. Catalogue quản từng requirement có ID, source, rationale, priority và status.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng use case & requirement catalogue, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

User story ngắn không luôn thay thế use case có nhiều nhánh.

### Tự kiểm tra

---

## Bài 19 — Business rules & state

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Business rules & state** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Decision table làm rule phức tạp nhìn được tổ hợp điều kiện. State machine làm rõ object ở trạng thái nào, hành động nào hợp lệ và ai làm được.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng business rules & state, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Đừng nhét policy dài vào acceptance criteria rồi gọi đó là rule management.

### Tự kiểm tra

---

# Route 4 — Stories, UX & data model

Người dùng phải hoàn thành công việc qua flow, còn hệ thống phải giữ được object và state đúng. Vì vậy UX, business rule và data model luôn phải được đọc cùng nhau.

```mermaid
flowchart LR
N0["User goal"]
N1["Story"]
N0 --> N1
N2["Flow"]
N1 --> N2
N3["Object"]
N2 --> N3
N4["Data model"]
N3 --> N4
```

## Bài 20 — User stories & Gherkin

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **User stories & Gherkin** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Story diễn đạt giá trị theo góc nhìn actor; Gherkin làm ví dụ hành vi rõ bằng Given–When–Then. Acceptance criteria là boundary, không phải toàn bộ thiết kế.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng user stories & gherkin, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Bắt đầu từ user goal, không bắt đầu từ screen.
2. Kiểm tra mỗi action có rule, state và data object tương ứng.
3. Đưa error path và accessibility vào flow ngay từ đầu.

### Bẫy thường gặp

“Xây API X” là task kỹ thuật, không mặc nhiên là user story.

### Tự kiểm tra

---

## Bài 21 — Story map & vertical slice

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Story map & vertical slice** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Story map đặt hoạt động lớn theo chiều ngang và mức detail/priority theo chiều dọc. Vertical slice đi xuyên UI, rule, data và integration để tạo giá trị hoàn chỉnh.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng story map & vertical slice, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Chia theo layer UI/API/DB thường tạo slice ngang, khó cho feedback sớm.

### Tự kiểm tra

---

## Bài 22 — Persona & journey map

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Persona & journey map** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Persona tóm tắt pattern mục tiêu, context và pain đã có evidence. Journey map nhìn stage, touchpoint, emotion, friction và opportunity.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng persona & journey map, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Persona không phải profile hư cấu với tuổi và sở thích cho đẹp.

### Tự kiểm tra

---

## Bài 23 — User flow & information architecture

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **User flow & information architecture** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

User flow là đường người dùng đi để hoàn thành mục tiêu. IA tổ chức nội dung/chức năng để họ tìm đúng thứ. Flow phải có error, cancel và return path.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng user flow & information architecture, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Sitemap không đủ để mô tả state và quyết định trong flow.

### Tự kiểm tra

---

## Bài 24 — Wireframe, prototype, usability

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Wireframe, prototype, usability** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Wireframe làm rõ hierarchy và behavior; prototype kiểm chứng interaction; usability xem hiệu quả, hiệu suất và satisfaction. Accessibility là khả năng dùng cho nhiều năng lực khác nhau.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng wireframe, prototype, usability, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Pixel đẹp không chứng minh flow dễ dùng.

### Tự kiểm tra

---

## Bài 25 — Business object & ERD

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Business object & ERD** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Business object là thứ có ý nghĩa nghiệp vụ. ERD conceptual nói relationship; logical thêm attribute/key. Cardinality trả lời một đối tượng liên hệ bao nhiêu đối tượng khác.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng business object & erd, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Bảng database không phải lúc nào cũng là business object tốt.

### Tự kiểm tra

---

# Route 5 — Data quality & analytics

Một số liệu chỉ đáng tin khi biết nó đếm ai, ở grain nào, từ nguồn nào và còn giới hạn gì. Đây là điểm BA chuyển từ “có dashboard” sang “có quyết định đáng tin”.

```mermaid
flowchart LR
N0["Source"]
N1["Profile"]
N0 --> N1
N2["Quality"]
N1 --> N2
N3["Metric"]
N2 --> N3
N4["Decision"]
N3 --> N4
```

## Bài 26 — Keys, normalization & dictionary

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Keys, normalization & dictionary** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Primary key định danh duy nhất; foreign key nối entity. Normalization giảm lặp và anomaly. Dictionary định nghĩa field, type, allowed values, owner và meaning.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng keys, normalization & dictionary, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Nêu population, grain và formula trước khi đọc metric.
2. Profile dữ liệu trước khi ra kết luận.
3. Reconcile bằng exception record chứ không chỉ so tổng.

### Bẫy thường gặp

Tên field giống nhau không đảm bảo meaning giống nhau.

### Tự kiểm tra

---

## Bài 27 — CRUD & lineage

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **CRUD & lineage** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

CRUD chỉ ai/đâu tạo, đọc, sửa, xóa object. Lineage theo nguồn, transform, đích và report để biết số đến từ đâu.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng crud & lineage, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Nêu population, grain và formula trước khi đọc metric.
2. Profile dữ liệu trước khi ra kết luận.
3. Reconcile bằng exception record chứ không chỉ so tổng.

### Bẫy thường gặp

System of entry không nhất thiết là source of truth.

### Tự kiểm tra

---

## Bài 28 — SQL như ngôn ngữ đặt câu hỏi

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **SQL như ngôn ngữ đặt câu hỏi** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

SELECT chọn cột, WHERE lọc population, JOIN nối record, GROUP BY đổi grain và aggregation. Học SQL để thấy câu hỏi business được dịch thành dữ liệu thế nào.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng sql như ngôn ngữ đặt câu hỏi, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Nêu population, grain và formula trước khi đọc metric.
2. Profile dữ liệu trước khi ra kết luận.
3. Reconcile bằng exception record chứ không chỉ so tổng.

### Bẫy thường gặp

JOIN sai cardinality có thể nhân đôi tiền mà không báo lỗi.

### Tự kiểm tra

---

## Bài 29 — Data profiling

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Data profiling** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Profile kiểm tra distribution, null, duplicate, format, range và outlier trước khi tin dữ liệu. Nó trả lời dữ liệu thật sự trông ra sao.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng data profiling, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Nêu population, grain và formula trước khi đọc metric.
2. Profile dữ liệu trước khi ra kết luận.
3. Reconcile bằng exception record chứ không chỉ so tổng.

### Bẫy thường gặp

Null không luôn là lỗi: có thể là “chưa áp dụng”, “chưa biết” hoặc defect.

### Tự kiểm tra

---

## Bài 30 — Data quality & reconciliation

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Data quality & reconciliation** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Completeness, validity, consistency, uniqueness và timeliness là các dimension chất lượng. Reconciliation giải thích chênh lệch giữa source/target hoặc hai report.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng data quality & reconciliation, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Nêu population, grain và formula trước khi đọc metric.
2. Profile dữ liệu trước khi ra kết luận.
3. Reconcile bằng exception record chứ không chỉ so tổng.

### Bẫy thường gặp

Hai tổng bằng nhau chưa chứng minh từng record đúng.

### Tự kiểm tra

---

## Bài 31 — Metric & dashboard spec

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Metric & dashboard spec** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Metric cần công thức, grain, population, dimension, filter, freshness, owner và caveat. Dashboard spec bảo đảm mọi người đọc cùng nghĩa.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng metric & dashboard spec, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Nêu population, grain và formula trước khi đọc metric.
2. Profile dữ liệu trước khi ra kết luận.
3. Reconcile bằng exception record chứ không chỉ so tổng.

### Bẫy thường gặp

“Doanh thu tháng” mơ hồ nếu không biết booking hay recognized revenue, timezone và refund rule.

### Tự kiểm tra

---

# Route 6 — Systems, API & integration

Hành vi business đi qua nhiều system boundary. BA dùng context, sequence và API contract để phát hiện điểm mà rule, data hoặc exception có thể bị mất.

```mermaid
flowchart LR
N0["Context"]
N1["Component"]
N0 --> N1
N2["Sequence"]
N1 --> N2
N3["API"]
N2 --> N3
N4["Error path"]
N3 --> N4
```

## Bài 32 — System context & component

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **System context & component** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Context xác định system boundary và external actor/system. Component phân rã bên trong ở mức trách nhiệm. Deployment nói thành phần chạy ở đâu.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng system context & component, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Vẽ system context trước, sequence sau.
2. Đọc request, response, auth và error như một contract.
3. Làm rõ timeout, retry, owner của mapping và failure path.

### Bẫy thường gặp

Context diagram không phải sơ đồ network chi tiết.

### Tự kiểm tra

---

## Bài 33 — Sequence, sync & async

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Sequence, sync & async** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Sequence diagram kể một scenario theo thời gian. Sync chờ response; async tách thời điểm gửi/nhận. Timeout, retry và compensation phải có mặt trong flow quan trọng.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng sequence, sync & async, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Vẽ system context trước, sequence sau.
2. Đọc request, response, auth và error như một contract.
3. Làm rõ timeout, retry, owner của mapping và failure path.

### Bẫy thường gặp

Async không có nghĩa là “nhanh hơn”; nó đổi cách xử lý trạng thái và lỗi.

### Tự kiểm tra

---

## Bài 34 — HTTP, REST, JSON & OpenAPI

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **HTTP, REST, JSON & OpenAPI** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

HTTP có method, URL, header, status và body. REST dùng resource-oriented contract; JSON biểu đạt object/array/value. Status code nói outcome kỹ thuật. OpenAPI mô tả endpoint, schema, auth, examples và error. Contract giúp client/server độc lập triển khai nhưng phải version và compatibility cẩn thận.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng http, rest, json & openapi, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Vẽ system context trước, sequence sau.
2. Đọc request, response, auth và error như một contract.
3. Làm rõ timeout, retry, owner của mapping và failure path.

### Bẫy thường gặp

200 không luôn nghĩa business action thành công nếu response có partial failure. API spec không chỉ là list endpoint: validation và error behavior cũng là contract.

### Tự kiểm tra

---

## Bài 35 — Authentication, mapping, errors & pagination

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Authentication, mapping, errors & pagination** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Authentication trả lời “bạn là ai”; authorization trả lời “bạn được làm gì”. Token, scope, role và policy quyết định access. Field mapping nêu source/target/transform/validation. Error matrix nêu code, message, retryability và owner. Pagination tránh trả payload quá lớn và phải ổn định thứ tự.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng authentication, mapping, errors & pagination, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Vẽ system context trước, sequence sau.
2. Đọc request, response, auth và error như một contract.
3. Làm rõ timeout, retry, owner của mapping và failure path.

### Bẫy thường gặp

### Tự kiểm tra

---

# Route 7 — Events, security & operability

Hệ thống vận hành thật luôn gặp duplicate, timeout, quyền truy cập sai và incident. Security, recovery và observability là một phần của solution, không phải việc thêm sau.

```mermaid
flowchart LR
N0["Event"]
N1["Delivery"]
N0 --> N1
N2["Control"]
N1 --> N2
N3["Observe"]
N2 --> N3
N4["Recover"]
N3 --> N4
```

## Bài 36 — Events, webhooks & batch

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Events, webhooks & batch** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Event báo một việc đã xảy ra; webhook là push HTTP; batch/file gom dữ liệu theo lịch. Chọn cách tích hợp theo latency, volume, ownership và recovery need.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng events, webhooks & batch, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Thiết kế chịu duplicate, late arrival và replay.
2. Cấp least privilege và audit cho hành động nhạy cảm.
3. Đặt target đo được cho performance, recovery và support.

### Bẫy thường gặp

Webhook delivery không đảm bảo consumer đã xử lý thành công.

### Tự kiểm tra

---

## Bài 37 — Ordering, idempotency & replay

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Ordering, idempotency & replay** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Ordering quan trọng khi event sau phụ thuộc event trước. Idempotency đảm bảo nhận lại request/event không tạo tác dụng phụ thêm. Replay phải có checkpoint và audit.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng ordering, idempotency & replay, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Thiết kế chịu duplicate, late arrival và replay.
2. Cấp least privilege và audit cho hành động nhạy cảm.
3. Đặt target đo được cho performance, recovery và support.

### Bẫy thường gặp

“Exactly once” thường là claim nguy hiểm; thiết kế chịu duplicate thực tế hơn.

### Tự kiểm tra

---

## Bài 38 — Control totals & reconciliation

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Control totals & reconciliation** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

File control total như count, amount, hash giúp phát hiện thiếu/thừa. Reconciliation nối control theo batch với record-level exception.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng control totals & reconciliation, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Thiết kế chịu duplicate, late arrival và replay.
2. Cấp least privilege và audit cho hành động nhạy cảm.
3. Đặt target đo được cho performance, recovery và support.

### Bẫy thường gặp

Một file nhận được không chứng minh tất cả record đã post đúng.

### Tự kiểm tra

---

## Bài 39 — Access control & privacy

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Access control & privacy** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

RBAC cấp theo role; ABAC xét attribute/context. Least privilege giảm blast radius; SoD tách quyền tạo/duyệt. PII cần purpose, minimization, retention và protection.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng access control & privacy, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Thiết kế chịu duplicate, late arrival và replay.
2. Cấp least privilege và audit cho hành động nhạy cảm.
3. Đặt target đo được cho performance, recovery và support.

### Bẫy thường gặp

Mã hóa không tự giải quyết access control hoặc retention.

### Tự kiểm tra

---

## Bài 40 — NFR, SLI/SLO/SLA & recovery

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **NFR, SLI/SLO/SLA & recovery** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Performance, availability và resilience là quality attribute. SLI là measurement, SLO là target, SLA là cam kết. RTO là thời gian khôi phục; RPO là lượng dữ liệu chấp nhận mất.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng nfr, sli/slo/sla & recovery, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Thiết kế chịu duplicate, late arrival và replay.
2. Cấp least privilege và audit cho hành động nhạy cảm.
3. Đặt target đo được cho performance, recovery và support.

### Bẫy thường gặp

99.9% availability không nói gì về response time hoặc data loss.

### Tự kiểm tra

---

# Route 8 — Business case to migration

Không có option nào tốt tuyệt đối. BA senior so sánh benefit, cost, risk, change impact và khả năng vận hành trước khi chọn configure, buy hoặc build.

```mermaid
flowchart LR
N0["Need"]
N1["Options"]
N0 --> N1
N2["Economics"]
N1 --> N2
N3["Delivery"]
N2 --> N3
N4["Migration"]
N3 --> N4
```

## Bài 41 — CAPEX, OPEX & TCO

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **CAPEX, OPEX & TCO** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

CAPEX là đầu tư ban đầu; OPEX là chi phí vận hành. TCO cộng implementation, integration, license, support, training, change và exit — không chỉ giá vendor.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng capex, opex & tco, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. So sánh option theo benefit, TCO, risk và time-to-value.
2. Phân loại gap trước khi chọn configure, extend hay customize.
3. Thiết kế test, UAT, rehearsal và rollback trước cutover.

### Bẫy thường gặp

License rẻ có thể thành solution đắt nếu customization và support cao.

### Tự kiểm tra

---

## Bài 42 — ROI, payback, NPV & sensitivity

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **ROI, payback, NPV & sensitivity** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

ROI cho tỷ lệ lợi ích/chi phí; payback hỏi bao lâu hoàn vốn; NPV tính timing của cash flow. Sensitivity kiểm tra conclusion thay đổi ra sao khi assumption đổi.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng roi, payback, npv & sensitivity, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Đừng trình ROI chính xác đến 2 chữ số thập phân khi benefit chỉ là guess.

### Tự kiểm tra

---

## Bài 43 — Fit-gap & solution disposition

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Fit-gap & solution disposition** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Fit-to-standard đo mức đáp ứng baseline. Gap có thể configure, extend, integrate, customize hoặc chấp nhận đổi process. Mỗi lựa chọn có upgrade debt khác nhau.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng fit-gap & solution disposition, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Customization không phải chiến thắng mặc định vì nó dễ mang technical debt dài hạn.

### Tự kiểm tra

---

## Bài 44 — Make-buy, RFI/RFP/RFQ & contract

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Make-buy, RFI/RFP/RFQ & contract** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Make-buy cân capability strategic, time, cost và control. RFI để hiểu market; RFP đánh giá solution; RFQ lấy giá rõ. SOW nêu scope; SLA nêu service; exit strategy chống lock-in.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng make-buy, rfi/rfp/rfq & contract, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Scorecard phải weighting theo decision criteria, không phải checklist feature bằng nhau.

### Tự kiểm tra

---

## Bài 45 — Agile, testing, UAT & migration

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Agile, testing, UAT & migration** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

DoR làm story sẵn sàng, DoD làm increment hoàn tất. Test levels phát hiện lỗi ở các lớp; UAT xác nhận fit business. Migration cần mapping, cleansing, rehearsal, cutover, rollback và reconciliation.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng agile, testing, uat & migration, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Severity là mức tác động; priority là thứ tự xử lý. Go-live không thay thế cutover rehearsal.

### Tự kiểm tra

---

# Route 9 — Operations & senior judgement

Ở route cuối, BA nhìn toàn bộ lifecycle: release chỉ là một mốc; benefit, support, governance và retirement mới quyết định solution có thành công hay không.

```mermaid
flowchart LR
N0["Operate"]
N1["Incident"]
N0 --> N1
N2["RCA"]
N1 --> N2
N3["Improve"]
N2 --> N3
N4["Benefit"]
N3 --> N4
```

## Bài 46 — Incident, problem & RCA

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Incident, problem & RCA** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Incident khôi phục service; problem tìm nguyên nhân hệ thống. RCA nên nhìn people, process, technology, data và control thay vì chỉ tìm người sai.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng incident, problem & rca, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

1. Nối objective với requirement, design, test, release và benefit.
2. Nói rõ evidence đã có, uncertainty còn lại và risk owner.
3. Dùng số liệu sau release để enhance, fix hoặc retire.

### Bẫy thường gặp

Workaround đóng incident có thể để problem còn nguyên.

### Tự kiểm tra

---

## Bài 47 — Runbook, PIR, benefit & retirement

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Runbook, PIR, benefit & retirement** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

Runbook nêu trigger, diagnosis, action, escalation và rollback. PIR xem điều gì xảy ra sau release, lesson learned và action owner. Enhancement/retirement quản vòng đời solution. Benefit owner, baseline, target, measurement cadence và confounder phải rõ. Retirement cần data retention, integration decommission, access removal và communication.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng runbook, pir, benefit & retirement, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

PIR không phải buổi tìm người chịu lỗi. Đo adoption không tự chứng minh business benefit.

### Tự kiểm tra

---

## Bài 48 — Traceability & senior BA judgement

### Bạn sẽ hiểu được gì

Bài này giúp bạn dùng **Traceability & senior BA judgement** như một cách nhìn tình huống, thay vì chỉ biết định nghĩa. Sau khi đọc, bạn phải nói được nó giải quyết câu hỏi nào, nó khác gì với khái niệm dễ nhầm và nó tạo đầu vào cho quyết định nào.

### Giải thích từ số 0

RTM nối objective, requirement, design, test và release. Artifact register, glossary và version history giữ cùng một sự thật khi nhiều team tham gia. Senior nêu problem trước solution, so sánh options, chỉ rõ uncertainty, risk owner và escalation. Họ nối business outcome → process → requirement → data/system → NFR → operate.

### Đặt vào case đơn hàng chậm

Khách đang phàn nàn giao trễ. Nhân viên kho muốn thêm màn hình; quản lý muốn thay phần mềm; kế toán lại thấy số tiền đối soát lệch. Khi dùng traceability & senior ba judgement, BA không chọn phe nào trước. BA lấy từng phát biểu làm đầu vào để kiểm evidence, flow, rule, data hoặc decision liên quan. Nhờ vậy team có thể phát hiện đúng điểm gây chậm thay vì đầu tư vào thứ trông có vẻ hợp lý nhất.

### Cách áp dụng khi đọc một case

### Bẫy thường gặp

Traceability không phải bureaucratic matrix; nó giúp change impact và audit. Không có đủ evidence không đồng nghĩa không được quyết; phải nói rõ quyết định dựa vào gì và cần kiểm chứng gì tiếp.

### Tự kiểm tra

---