Khung ra quyết định toàn hệ thống — Tư duy Hệ thống Ứng dụng

“Khung ra quyết định toàn hệ thống” (whole-system decision framework) có trong lịch khóa học nhưng chưa được giảng trong Ngày 1. Bài này là một working decision record do kho học liệu biên soạn từ các gợi ý của Meadows, Ulrich, Midgley, Snowden và thực hành decision review; nó không được gán là khung chính thức của Prof. Shen. Khi có nội dung Ngày 2, phần chính thức cần được ghi ở lớp nguồn riêng và đối chiếu với working record này, không viết ngược lại lịch sử như thể mọi thành phần dưới đây đều do Giáo sư giảng.

Vì sao quyết định tốt lại tạo ra kết quả xấu

Một cách trả lời hệ thống có thể bắt đầu bằng năm cơ chế sau. Đây là phần tổng hợp của người biên soạn; các cơ chế mô tả giới hạn nhận thức và cấu trúc, không tự loại trừ lỗi đạo đức, năng lực chuyên môn hay vi phạm kiểm soát:

Duy lý có giới hạn (bounded rationality — Herbert Simon). Người ra quyết định bị giới hạn về thông tin, thời gian, sự chú ý và năng lực xử lý — và chỉ thấy thông tin đến được chỗ mình đứng trong hệ thống. Quyết định hợp lý trong các giới hạn đó vẫn có thể sai với toàn cục — không phải vì kém, mà vì vị trí và giới hạn là có thật.
Tối ưu cục bộ. Mỗi đơn vị tối ưu KPI của mình → tổng thể xấu đi. Ví dụ kinh điển: sales chốt deal bằng cam kết deadline gắt (KPI sales xanh) → delivery cháy → chất lượng giảm → khách rời bỏ (KPI công ty đỏ).
Độ trễ. Kết quả tốt ngắn hạn và hệ quả xấu dài hạn của cùng một quyết định xuất hiện cách nhau 6–24 tháng, nên hệ quả xấu hiếm khi được truy về đúng quyết định gốc.
Kháng chính sách (policy resistance). Hệ thống gồm nhiều tác nhân có mục tiêu riêng; khi một chính sách ép hệ thống lệch khỏi mục tiêu của các tác nhân, họ bù lại — và chính sách bị trung hoà. Cấm OT nhưng khoán sản phẩm không đổi → OT chui.
Mô hình tư duy (mental model) không được kiểm tra. Quyết định luôn chạy trên một mô hình ngầm về “thế giới vận hành thế nào”. Khi mô hình sai (thị trường đã đổi, nhân sự đã khác), quyết định đúng-theo-mô-hình vẫn sai-theo-thực-tế. Đây là mục “Nhận thức trong quá trình ra quyết định” trên thời khoá biểu.

Bảng “ý định – cơ chế – hệ quả” để tự soi các quyết định của chính mình:

Quyết định (ý định tốt)	Cơ chế hệ thống bị bỏ qua	Hệ quả ngoài ý muốn
Cắt 20% chi phí QA để cải thiện margin	Độ trễ: lỗi lọt ra thị trường sau 2 quý	Chi phí bảo hành + mất khách > số tiết kiệm
Thưởng sales theo doanh thu ký mới	Tối ưu cục bộ: deal xấu vẫn được ký	Delivery lỗ, khách một lần rồi đi
Chuẩn hoá một quy trình cho mọi công ty con	Kháng chính sách + bỏ qua bối cảnh (Không gian)	Mỗi nơi “lách” một kiểu, quy trình chỉ tồn tại trên giấy

Bản đồ hệ thống các bên liên quan — công cụ trước khung

Trong một decision review, lập bản đồ hệ thống các bên liên quan nên đứng trước đánh giá phương án: chưa thấy ai đang ở trong bức tranh thì chưa biết lợi ích, tổn thất và bằng chứng đang được phân phối ra sao. Có thể liên hệ công cụ này với lăng kính tương thuộc, nhưng bản đồ stakeholder không phải là bằng chứng tự thân của nguyên lý duyên khởi.

Nó không phải hai thứ hay bị nhầm: (i) một danh sách stakeholder — danh sách không cho thấy ai tác động ai; (ii) một ma trận power–interest — ma trận xếp hạng từng bên riêng lẻ, còn bản đồ hệ thống vẽ quan hệ giữa các bên với nhau. Giá trị nằm ở các mũi tên giữa các stakeholder (không đi qua ô trung tâm) — vì hệ quả thật thường chạy đường vòng: A tác động B, B tác động C, C mới quay lại tác động bạn.

Bản đồ mẫu cho case “rút 3 engineer” (xem Case xuyên suốt):

Bản đồ hệ thống các bên liên quan. nơi quyết định được chốt bên ngoài tổ chức, phát hiện muộn bị ảnh hưởng nhưng không có tiếng nói (nét đứt) · Mũi tên = chiều ảnh hưởng, ‖ = độ trễ. Giá trị nằm ở các mũi tên không đi qua ô trung tâm.

Sáu bước vẽ — làm được trên một tờ A4, không cần đẹp, cần trung thực:

Vẽ vấn đề của bạn ở giữa (ô vuông) — nhưng nhớ: ô trung tâm chỉ là điểm neo, phần quan trọng là các mũi tên giữa các bên.
Vẽ xung quanh tất cả các bên có ảnh hưởng hoặc bị ảnh hưởng — kể cả các bên “ẩn”: gia đình nhân viên, nhà cung cấp cấp 2, cơ quan quản lý chưa can thiệp, thế hệ tương lai.
Nối bằng mũi tên có nhãn: ghi rõ cái gì chảy qua quan hệ đó (tiền, lệnh, thông tin, niềm tin, áp lực). Một chiều (A ảnh hưởng B), hai chiều (phụ thuộc lẫn nhau), thêm ‖ nếu ảnh hưởng có độ trễ.
Gắn nhãn cảm xúc lên mỗi bên: hài lòng / bất an / bức xúc / thờ ơ / không biết đến.
Vẽ nét đứt quanh các bên bị ảnh hưởng nhưng không có tiếng nói (affected but not involved), rồi khoanh tròn 3 bên yếu thế nhất. Lưu ý phân biệt: câu hỏi thứ 10 của Ulrich hỏi ai nên làm “witness” — người đại diện chính danh cho mối quan tâm của các bên này, không phải chính họ. Ai được cử làm witness, và người đó có xung đột lợi ích không, tự nó là một câu hỏi ranh giới.
Kiểm tra cuối: đã có ít nhất 2 mũi tên không đi qua ô trung tâm chưa? Nếu chưa, sơ đồ của bạn đang là hình nan hoa (hub–spoke) — tức vẫn là danh sách, chưa phải bản đồ hệ thống.

Working decision record — 12 thành phần

Không phải quyết định nào cũng cần cùng mức phân tích. Một quyết định nhỏ, đảo ngược được có thể timebox record trong 20 phút; quyết định liên quan an toàn, dữ liệu cá nhân, pháp lý, tài chính lớn hoặc quyền lợi con người cần evidence review và cổng phê duyệt tương ứng. Dù mức sâu khác nhau, decision record nên để lại đủ 12 trường sau:

#	Thành phần	Câu hỏi phải trả lời
1	Quyết định, owner & quyền chốt	Quyết định chính xác là gì? Ai đề xuất, ai chịu kết quả, ai có quyền chốt? Hạn chót thật và nguồn tạo ra hạn là gì?
2	Baseline & reference mode	Chỉ báo đã biến động thế nào trong khoảng thời gian đủ dài? Nếu không làm gì, quỹ đạo dự kiến là gì?
3	Mục đích & thước đo	Quyết định phục vụ mục đích gì của hệ thống? Chỉ báo sớm/muộn nào đo “tốt hơn”; thước đo có tạo tối ưu cục bộ không?
4	Bằng chứng, giả định & confidence	Dữ liệu nào ủng hộ/phản bác? Đâu là fact, inference và unknown? Confidence hiện tại bao nhiêu phần trăm, và điều gì sẽ làm đổi mức tin?
5	Ranh giới	Phân tích bao gồm và loại ai/cái gì, ở recursion level và khung thời gian nào? Ai vẽ ranh giới? (xem CSH)
6	Bên liên quan & quyền lực	Ai được/ai mất? Ai có tiếng nói, ai không? Ai là witness chính danh cho bên không có tiếng nói, và witness có xung đột lợi ích không?
7	Mẫu hành vi, vòng lặp & độ trễ	Đây là sự kiện hay mẫu lặp? CLD nào là giả thuyết cấu trúc? Sau bao lâu mới thấy kết quả thật? Dữ liệu nào có thể bác bỏ?
8	Phương án & hệ quả ngoài ý muốn	Có ít nhất hai phương án thực sự khác nhau và phương án không làm gì chưa? Với từng phương án: ai được/mất, vòng nào có thể bị kích hoạt?
9	Điều kiện cần (“duyên”)	Năng lực, văn hoá, thời điểm, phụ thuộc và compliance nào phải có? Thiếu điều kiện nào thì cùng hành động sẽ cho kết quả khác?
10	Reversibility & blast radius	Quyết định đảo ngược được tới khi nào, chi phí đảo là bao nhiêu? Sai thì ảnh hưởng tới bao nhiêu người/hệ thống và có lan truyền không?
11	Chế độ can thiệp & guardrail	Tình huống cho phép thử safe-to-fail, cần fail-safe/controlled validation, hay phải dùng standard work? Cổng pháp lý, an toàn, bảo mật nào phải qua trước?
12	Review 30/60/90 & quy tắc hành động	Ngày nào so forecast với actual? Ngưỡng nào thì dừng, sửa, đảo hoặc mở rộng? Ai có quyền thực hiện từng hành động?

Điểm khác một checklist thông thường: record giữ lại baseline, bằng chứng và confidence để hậu kiểm chất lượng phán đoán; hỏi về ranh giới và quyền lực thay vì chỉ phương án; coi vòng lặp, độ trễ và điều kiện là giả thuyết có thể bác bỏ; và buộc xác định khả năng đảo quyết định cùng quy tắc review trước khi biết kết quả.

Chọn chế độ can thiệp trước khi “pilot”

Safe-to-fail không phải nhãn mặc định cho mọi thử nghiệm:

Loại tình huống	Chế độ phù hợp	Ví dụ guardrail
Đơn giản, quy trình đã biết	Standard work / checklist; không cần biến thành thí nghiệm	Four-eyes approval, SLA, audit log
Phức tạp về chuyên môn nhưng quan hệ nhân quả có thể phân tích	Expert analysis + controlled pilot/fail-safe	Review kiến trúc, test plan, rollback
Phức hợp, bất định cao, blast radius nhỏ và đảo được	Nhiều probe safe-to-fail song song	Giới hạn phạm vi/thời gian, telemetry, kill switch
Regulated, safety-critical, ảnh hưởng quyền lợi hoặc dữ liệu nhạy cảm	Compliance/ethics gate + validation có kiểm soát; ưu tiên fail-safe	DPIA, security review, informed consent, phê duyệt có thẩm quyền

Nếu chưa phân loại được, mặc định giảm blast radius và xin đánh giá chuyên môn; không dùng chữ “pilot” để đi vòng qua nghĩa vụ pháp lý hay an toàn.

Canvas hành động và học hỏi

Canvas dưới đây là phần thực thi của decision record: mỗi trường một dòng, có thể hoàn thành ở mức nháp trong 15–20 phút, sau đó tăng độ sâu theo rủi ro.

Trường	Bạn điền	Ví dụ (case rút engineer)
Decision owner & quyền chốt	Một người chịu record; ghi riêng người phê duyệt nếu khác	CTO sở hữu record; CEO chốt thay đổi allocation policy
Baseline & forecast	3–5 chỉ báo lịch sử; dự báo tại mốc 30/60/90 nếu không can thiệp	OT, rework, SLA, số lần xin người khẩn trong 6 tháng
Bằng chứng & confidence	Fact/inference/unknown; mức tin và counter-evidence cần tìm	65%; cần đối chiếu dữ liệu điều chuyển với rework
Giả thuyết can thiệp	”Tôi tin rằng nếu ___ thì ___ vì vòng lặp/cấu trúc ___"	"Nếu lập cơ chế điều phối nguồn lực liên dự án (S2) thì yêu cầu khẩn giảm, vì xoáy rework R1 được kích hoạt bởi điều chuyển đột ngột”
Điểm đòn bẩy	Can thiệp ở tầng nào — tham số, cấu trúc, hay mô hình tư duy?	Cấu trúc (quy trình điều người), không phải tham số (thêm headcount)
Bên liên quan & witness	Ai bị ảnh hưởng, ai là người đại diện chính danh cho bên không có tiếng nói?	Team các dự án bị rút người (bị ảnh hưởng, không dự họp); witness đề cử: một kỹ sư senior do team tự chọn — không phải HR, vì HR có xung đột lợi ích
Reversibility & chế độ thử	Điểm không thể đảo; safe-to-fail, controlled pilot hay standard work?	Controlled pilot trên 1 cặp dự án; rollback trong 24 giờ
Owner	Một cái tên, không phải một phòng ban	—
Chỉ báo sớm (≤30 ngày)	Tín hiệu đầu tiên cho biết đang đúng/sai hướng	Số lần “xin người khẩn” ngoài cơ chế
Chỉ báo muộn (90 ngày)	Kết quả thật muốn thấy	SLA ổn định, OT giảm, không ai nghỉ vì điều chuyển
Hệ quả phụ cần canh	Vòng lặp nào có thể bị kích hoạt ngoài ý muốn?	Cơ chế thành nút cổ chai mới → mọi yêu cầu xếp hàng
Mốc xem lại	30 / 60 / 90 ngày — lịch cụ thể, so forecast với actual	—
Điều kiện dừng / mở rộng	Thấy gì thì dừng pilot, thấy gì thì nhân rộng?	Dừng nếu thời gian chờ điều phối >1 tuần; nhân rộng nếu pilot chạy 2 chu kỳ êm

Giá trị của record không nằm ở số ô được điền, mà ở việc không viết lại dự báo sau khi đã biết kết quả. Tại mỗi mốc 30/60/90 ngày, giữ nguyên forecast gốc, ghi actual, giải thích sai lệch, cập nhật confidence và quyết định dừng/sửa/đảo/mở rộng. Đây là Mode 2 — Học hỏi & Đánh giá — nối trực tiếp với bộ 36 câu hỏi BSM.

Ghi chú nguồn: stakeholder/boundary dựa trên Ulrich và Midgley; vòng lặp/độ trễ dựa trên Systems Thinking; phân biệt safe-to-fail chịu ảnh hưởng từ Cynefin; risk gate, confidence và decision review là phần tổng hợp thực hành của kho học liệu. Đây chưa phải khung chính thức của Prof. Shen.