Mục lục
Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.
Trả lời ngắn: Hệ thống cải tiến liên tục là chuỗi paper test có giới hạn: chọn một gap, ghi baseline, thử một thay đổi nhỏ, so evidence rồi đóng vòng bằng
ADOPT,ADAPThoặcABANDON. “Liên tục” nghĩa là có thể mở vòng kế tiếp sau đó, không phải sửa quy tắc không ngừng.
Đọc xong, bạn sẽ hiểu:
- Vì sao cải tiến khác với chỉnh sửa ngẫu hứng sau mỗi kết quả.
- Cách điền năm field của Improvement Test Card.
- Cách đóng một test dù kết quả là tốt, mixed hay không đổi.
1. Hệ thống cải tiến liên tục nghĩa là gì?
Một quầy bếp hay thất lạc phiếu giữa khâu nhận đơn và khâu nấu. Người quản lý có thể đổi vị trí đặt phiếu trong một ca thử. Nếu đồng thời đổi luôn mẫu phiếu, người giao phiếu và thứ tự làm món, cuối ca chẳng ai biết thay đổi nào liên quan đến kết quả. Improvement loop là vòng học có ranh giới để tránh tình huống đó.
Ở bài #45 về xây dựng quy trình, ta đã vẽ một process version có trigger, step, handoff, exception và trace. Bài #46 lấy một gap đã được ghi trong trace, thử một thay đổi trên tài liệu giả rồi ra quyết định cho version kế. Mỗi vòng có đầu, cuối và record riêng.
“Liên tục” dễ bị hiểu sai thành “thấy gì cũng sửa ngay”. Thực ra, một hệ thống có thể chạy nhiều vòng theo thời gian, nhưng từng vòng phải đóng. Nếu chưa biết target là gì, baseline ở đâu hoặc test kết thúc lúc nào, ta chưa có vòng cải tiến; ta chỉ đang random tweaking — chỉnh sửa ngẫu hứng.
Hình 1 — Một vòng chỉ hoàn tất khi có quyết định giữ, sửa hoặc bỏ thay đổi.
Bài này không tối ưu chiến lược, không chạy backtest, không dùng P&L làm target và không cấp quyền giao dịch thật. Paper test giảm phạm vi rủi ro và giúp câu hỏi rõ hơn, nhưng không chứng minh thay đổi sẽ có tác dụng trong thị trường.
2. Improvement Test Card gồm năm field
Mỗi card đại diện một test nhỏ. Điền đủ năm field trước khi bắt đầu.
a. IMPROVEMENT TARGET
Target là một gap quan sát được, có scope và điểm kết thúc. “Làm quy trình tốt hơn” quá rộng. “Giảm số hồ sơ giả bị trả vì thiếu mã trong bốn card test” rõ hơn vì biết đang nhìn lỗi nào và trên tập nào. Target không phải phán xét “tôi thiếu kỷ luật”.
b. BASELINE/EVIDENCE
Baseline là record trước thay đổi để làm mốc so. Evidence là dấu vết quan sát được, chẳng hạn 2/4 hồ sơ giả thiếu mã. Ký ức “hình như tuần trước ổn” không thay baseline. Baseline nhỏ không đại diện cả thế giới; nó chỉ khóa điểm so cho paper test này.
c. ONE CHANGE HYPOTHESIS
Change hypothesis là dự đoán có điều kiện: nếu thêm trường MÃ HỒ SƠ vào
template, số card thiếu mã trong test kế có thể giảm. Đây không phải causal
guarantee. Quy tắc “một change” là boundary để bài tập dễ học; hệ thống thật có
thể có nhiều interaction cần thiết kế khác.
d. TEST BOUNDARY/MEASURE
Boundary ghi phạm vi: bốn hồ sơ hư cấu, một template, một lượt 10 phút. Measure là điều sẽ so, như số card đủ mã và ghi chú lý do card bị trả. Thêm stop condition: dừng nếu phải dùng dữ liệu thật hoặc đổi thêm owner/route.
e. REVIEW DECISION/VERSION
Khi test kết thúc, chọn một trong ba quyết định:
ADOPT: giữ change cho paper version kế.ADAPT: sửa change rồi mở một test mới.ABANDON: bỏ change và ghi lý do.
Card phải ghi version và review date. ABANDON không phải thất bại của người
thử; nó là một kết quả học đã được đóng.
Hình 2 — Target, baseline và decision giữ vòng test khỏi biến thành sửa tùy hứng.
3. Bốn bước chạy một vòng cải tiến
Vòng thao tác là:
SELECT → TEST SMALL → COMPARE → ADOPT/ADAPT/ABANDON.
a. SELECT
Chọn đúng một gap từ trace hoặc exception của process map. Viết target bằng artifact và trạng thái, không bằng cảm giác. Nếu chưa có baseline, đứng ngoài: thu thập record trước, chưa thay đổi template.
b. TEST SMALL
Chạy một change hypothesis trên ba hoặc bốn document card hư cấu. IHI mô tả PDSA như cách thử thay đổi ở quy mô nhỏ, rồi quan sát và hành động theo điều đã học (IHI, Model for Improvement). Đây là framework cải tiến chất lượng, không phải nghiên cứu trading.
c. COMPARE
So cùng field trước và sau. Nếu baseline là “2/4 card thiếu mã”, test cũng phải đếm lỗi thiếu mã, không đổi sang “cảm thấy nhanh hơn”. Null result nghĩa là không thấy khác trong phạm vi test; mixed result là một mặt tốt hơn nhưng mặt khác xấu đi. Cả hai vẫn phải được ghi.
d. ADOPT/ADAPT/ABANDON
Đọc evidence, chọn decision và đóng version. IHI cũng mô tả vòng kế dùng điều đã học để giữ, sửa hoặc bỏ một thay đổi (IHI, Testing Changes). Việc nhiều vòng nối nhau không miễn cho từng vòng khỏi prediction, measure và decision.
4. Bốn Improvement Test Card để đối chiếu
a. C46-A — BOUNDED IMPROVEMENT LOOP COMPLETE
Card có target thiếu mã, baseline 2/4, một change thêm trường mã, boundary bốn card, comparison cùng measure và decision cho v1.1.
Description là BOUNDED IMPROVEMENT LOOP COMPLETE. Nó chỉ xác nhận đường học
đã đóng trong phạm vi giấy, không chứng minh causality hay hiệu quả live.
b. C46-B — TARGET NOT DEFINED
Card ghi “làm quy trình tốt hơn”, không nêu gap, scope hoặc end condition. Không ai biết cần baseline gì.
Description là TARGET NOT DEFINED. Quay lại trace #45, chọn một exception
quan sát được rồi mới mở test.
c. C46-C — MULTIPLE CHANGES STACKED
Card đổi template, owner và exception route trong cùng lượt. Kết quả khác baseline nhưng không thể gán hợp lý cho một change.
Description là MULTIPLE CHANGES STACKED. Đóng card mà không kết luận cause;
tách một change hypothesis cho paper test kế.
d. C46-D — REVIEW DECISION MISSING
Card có before/after evidence nhưng không ghi ADOPT, ADAPT, ABANDON hoặc
version. Change tạm thời dễ biến thành rule vĩnh viễn.
Description là REVIEW DECISION MISSING. Thêm decision và reason trước khi
mở vòng khác.
Hình 3 — C46-A–D phân biệt vòng đã đóng với target, change hoặc decision còn thiếu.
5. Sáu lỗi, giới hạn và rủi ro
a. Sửa rule sau mỗi kết quả
Outcome gần nhất không tự là improvement target. Sửa liên tục làm baseline và version mất nghĩa.
b. Dùng P&L hoặc identity làm target
P&L chứa nhiều yếu tố ngoài process; “tôi phải giỏi hơn” không phải artifact quan sát được. Bài chỉ test document flow.
c. Không giữ baseline
Không có record trước test, comparison dễ thành chuyện kể theo memory hoặc mood.
d. Stack nhiều changes rồi gán cause
Ba change có thể tương tác. Kết quả tốt hơn không cho biết change nào liên quan; comparison không bằng causality.
e. Chỉ giữ kết quả đẹp
Che null, mixed hoặc abandoned result làm lịch sử học sai lệch. Record âm tính có thể ngăn lặp lại change không phù hợp.
f. Không đóng vòng
Test không có decision/version sẽ thành rule ngầm. Automation lúc này chỉ nhân rộng một trạng thái chưa review.
Một systematic review về PDSA trong healthcare báo rằng chỉ 4/47 bài được xem xét có nêu prediction rõ, cho thấy nhiều báo cáo chưa dùng đầy đủ vòng học như lý thuyết (Taylor et al., 2014). Một nghiên cứu khác cũng ghi nhận PDSA khó hiểu và khó áp dụng, với fidelity tổng thể còn thấp trong bối cảnh các team được khảo sát (McNicholas et al., 2019). Hai nguồn thuộc cải tiến y tế, không đo trader hay lợi nhuận.
ISO mô tả process approach theo hướng plan, do, check rồi act để tiếp tục cải tiến (ISO, quality management). NIST CSF 2.0 cũng nhấn mạnh context riêng và việc quản lý rủi ro là process liên tục (NIST CSF 2.0). Đây là nguyên tắc quản lý hệ thống; context shift, measurement noise, sample giấy nhỏ và implementation fidelity vẫn giới hạn khả năng ngoại suy sang trading.
6. Bài tập 15 phút: chạy bốn improvement card
Dùng giấy, Notes hoặc Sheets. Lấy process giả “nhận hồ sơ → kiểm mã → bàn giao” từ #45. Không mở chart, order, dữ liệu thị trường, tài khoản hoặc tiền thật.
- Ghi baseline: 4 card giả, 2 card bị trả vì thiếu mã.
- Chọn target: quan sát lỗi thiếu mã trong đúng 4 card kế.
- Test một change: thêm trường
MÃ HỒ SƠ; không đổi owner hoặc route. - Compare cùng measure rồi chọn
ADOPT,ADAPThoặcABANDON. - Chạy C46-B–D để nhận ra ba chỗ gãy còn lại.
Mẫu đối chiếu đã điền
| ID | Improvement evidence | Description |
|---|---|---|
| C46-A | Target + baseline + one change + boundary + comparison + decision/version | BOUNDED IMPROVEMENT LOOP COMPLETE |
| C46-B | “Make it better”; no scoped gap/end | TARGET NOT DEFINED |
| C46-C | Template + owner + route changed together | MULTIPLE CHANGES STACKED |
| C46-D | Before/after present; no decision/version | REVIEW DECISION MISSING |
Dừng sau 15 phút và giữ lại mọi card, kể cả null/mixed result. Không cộng efficiency, discipline, optimization hoặc improvement score. Paper only: exercise không cấp live permission.
7. Tổng kết và cầu sang Anti-Fragile Trader
a. Năm ý chính
- Cải tiến liên tục gồm nhiều vòng, nhưng từng vòng phải đóng.
- Target và baseline phải là evidence quan sát được, không phải mood.
- Một change boundary giúp học rõ hơn nhưng không loại mọi interaction.
- Comparison không chứng minh causality; null/mixed result vẫn cần lưu.
- Mỗi vòng kết thúc bằng
ADOPT,ADAPThoặcABANDONcùng version.
b. Câu hỏi tự kiểm tra
- “Liên tục” khác “sửa liên tục” ở điểm nào?
- Vì sao C46-C không cho phép gán nguyên nhân cho một change?
- Khi test không tạo khác biệt, card nên được xử lý thế nào?
c. Gợi ý đáp án
Xem gợi ý câu 1
Nhiều vòng có thể nối nhau, nhưng mỗi vòng cần target, boundary và decision rõ. Xem lại mục 1.
Xem gợi ý câu 2
Vì template, owner và route đổi cùng lúc nên các effect bị trộn. Xem lại mục 4.
Xem gợi ý câu 3
Ghi null result, chọn adapt hoặc abandon có lý do rồi đóng version. Xem lại mục 3.
d. Thuật ngữ cần nhớ
| Thuật ngữ | Giải thích ngắn |
|---|---|
| Improvement loop | Vòng chọn, thử, so và ra quyết định |
| Target | Gap cụ thể muốn quan sát trong test |
| Baseline | Record trước thay đổi để làm mốc |
| Change hypothesis | Dự đoán có điều kiện về một thay đổi |
| Test boundary | Phạm vi, thời gian và điểm dừng của test |
| Measure | Trường evidence dùng để so trước và sau |
| Null result | Không thấy khác trong phạm vi test |
| Mixed result | Một số evidence tốt hơn, số khác xấu đi |
| Version | Nhãn phân biệt các lần sửa |
| Implementation fidelity | Mức thực tế bám cách làm đã thiết kế |
e. Nguồn tham khảo
- IHI, Model for Improvement.
- IHI, Testing Changes.
- Taylor et al. (2014), systematic review of PDSA.
- McNicholas et al. (2019), PDSA fidelity.
- ISO, ISO 9000 quality-management family.
- NIST Cybersecurity Framework 2.0.
Tiếp theo, Anti-Fragile Trader #47 sẽ xem cách một response contract học từ stressor có giới hạn. #46 chỉ quản lý paper test và version decision; nó không hứa rằng gặp lỗi nhiều sẽ tự mạnh hơn.
Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư, tín hiệu giao dịch hay quy trình tối ưu lợi nhuận. Mọi thị trường đều có rủi ro mất vốn.
Bài tiếp theo