🧠 Đừng vội sửa con người — hãy nhìn vào hệ thống
Có một câu rất đáng nhớ trong Systems Thinking:
Structure generates behavior.
Nói đơn giản:
Hành vi của con người không xuất hiện trong chân không. Nó được tạo ra và giới hạn bởi cấu trúc của hệ thống mà họ đang sống và làm việc trong đó.
Đây là một thay đổi rất lớn trong cách nhìn vấn đề.
1️⃣ Cách tư duy thông thường
Khi thấy một vấn đề, chúng ta thường nhìn vào người đang gây ra vấn đề.
Ví dụ:
Deadline trễ
│
▼
Developer làm chậm
│
▼
"Developer thiếu trách nhiệm"
Hoặc:
Sales giảm
│
▼
Nhân viên bán hàng
│
▼
"Sales team làm việc kém"
Hoặc:
Khách hàng phàn nàn
│
▼
Support xử lý chậm
│
▼
"Support thiếu năng lực"
Đây là cách nhìn rất linear:
Problem → Person → Blame
Nhưng Systems Thinking đặt một câu hỏi khác:
“Điều gì trong hệ thống đang khiến hành vi này trở nên hợp lý?”
2️⃣ Structure → Behavior
Trong bài giảng, “structure” không chỉ là cấu trúc vật lý.
Nó có thể bao gồm:
- Quy trình
- Incentive
- Information
- Feedback
- Rules
- Constraints
- Time delays
- Mental models
- Cách các thành phần tương tác với nhau
Và tất cả những thứ đó ảnh hưởng đến hành vi.
SYSTEM STRUCTURE
│
┌───────┼────────┐
▼ ▼ ▼
Incentive Rules Information
│ │ │
└───────┼────────┘
▼
Decisions
│
▼
Behavior
│
▼
Result
│
└──────────► Feedback
│
└────► System
Vì vậy:
Muốn thay đổi behavior một cách bền vững, đôi khi phải thay đổi structure.
3️⃣ Một ví dụ rất đơn giản
Giả sử một team thường xuyên deploy vào cuối ngày.
Kết quả:
Deploy late
↓
Production incident
↓
On-call xử lý
↓
Team mệt mỏi
↓
Ngày hôm sau năng suất giảm
Cách phản ứng thông thường:
“Mọi người phải cẩn thận hơn.”
Nhưng Systems Thinking hỏi:
Tại sao mọi người lại deploy cuối ngày?
Có thể là:
Sprint deadline
↓
Feature chưa hoàn thành
↓
Pressure tăng
↓
Developer tiếp tục code
↓
Deploy cuối ngày
↓
Incident
Nhưng tại sao feature chưa hoàn thành?
Có thể:
Estimate thấp
↓
Sprint commitment cao
↓
Workload lớn
↓
Feature trễ
Vậy nếu chỉ nói:
“Developer cần cẩn thận.”
thì có thể bạn chỉ đang xử lý behavior.
Trong khi nguyên nhân nằm sâu hơn:
Planning
↓
Workload
↓
Deadline pressure
↓
Behavior
↓
Incident
4️⃣ Fundamental Attribution Error
Con người có xu hướng rất nhanh chóng quy nguyên nhân cho cá nhân thay vì hoàn cảnh hoặc hệ thống.
Ví dụ trên đường:
Someone cuts you off
│
▼
"Người này lái xe mất dạy!"
Nhưng nếu chính bạn cắt người khác:
Bạn đang trễ
+
Có việc khẩn cấp
↓
Bạn vượt lên
Đột nhiên:
“Tôi có lý do.”
Đây chính là một ví dụ được dùng trong bài giảng để minh họa fundamental attribution error.
Chúng ta thường:
Hành vi của người khác
↓
Tính cách của họ
Hành vi của tôi
↓
Hoàn cảnh của tôi
Systems Thinking yêu cầu chúng ta đảo ngược cách nhìn:
Behavior
↓
Context
↓
Structure
↓
Mental Model
↓
Why does this behavior make sense?
5️⃣ “Nhưng người đó vẫn phải chịu trách nhiệm?”
Đúng.
Systems Thinking không có nghĩa là đổ lỗi cho hệ thống thay cho con người.
Điểm quan trọng là:
Đừng dừng việc phân tích ở cá nhân.
Ví dụ:
Developer gây production bug
│
▼
Developer error
│
▼
STOP ❌
Thay vào đó:
Developer error
↓
Why?
↓
No code review?
↓
Why?
↓
Deadline pressure?
↓
Why?
↓
Planning / incentive?
↓
Why?
↓
System structure
Bạn vẫn có thể xử lý trách nhiệm cá nhân.
Nhưng đồng thời phải hỏi:
“Điều gì khiến lỗi tương tự có thể tiếp tục xảy ra với người tiếp theo?”
Đây mới là tư duy hệ thống.
6️⃣ Event → Pattern → Structure
Một trong những framework rất dễ nhớ:
EVENT
│
▼
"Chuyện gì xảy ra?"
│
▼
PATTERN
│
▼
"Nó xảy ra nhiều lần
theo pattern nào?"
│
▼
STRUCTURE
│
▼
"Điều gì đang tạo ra
pattern này?"
Ví dụ:
Event
Một developer nghỉ việc.
Nếu chỉ nhìn event:
“Anh ấy muốn tìm cơ hội tốt hơn.”
Nhưng hãy nhìn pattern:
Developer A → nghỉ
Developer B → nghỉ
Developer C → nghỉ
Developer D → nghỉ
Bây giờ có một pattern.
Câu hỏi tiếp theo:
“Điều gì trong hệ thống đang tạo ra pattern này?”
Có thể là:
Low autonomy
↓
Low engagement
↓
Low retention
↓
High turnover
Hoặc:
High workload
↓
Burnout
↓
Low engagement
↓
Resignation
Event chỉ là phần nổi của tảng băng.
7️⃣ Open-loop Thinking vs Systems Thinking
Đây là một điểm rất quan trọng trong bài giảng.
Tư duy tuyến tính thường giống:
Decision
↓
Action
↓
Result
↓
DONE
Đây là Open-loop Thinking.
Nhưng trong hệ thống thực tế:
Decision
↓
Action
↓
Result
↓
System changes
↓
Other actors react
↓
New decisions
↓
New result
│
└──────────────► affects original decision
Đây chính là feedback loop.
Bài giảng nhấn mạnh rằng không có quyết định nào tồn tại hoàn toàn độc lập; tác động của quyết định có thể quay trở lại ảnh hưởng hệ thống ban đầu.
8️⃣ “Side effects” thực ra là gì?
Có một cách diễn đạt rất thú vị trong bài:
Không hẳn có “side effects”.
Mà có thể hiểu là:
Những effects mà chúng ta chưa nghĩ tới.
Ví dụ:
Tăng Sales
↓
Orders ↑
↓
Production ↑
↓
Workload ↑
↓
Delivery delay ↑
↓
Customer satisfaction ↓
Bạn chỉ muốn:
Sales ↑
Nhưng hệ thống tạo ra:
Sales ↑
↓
Production pressure ↑
↓
Delay ↑
↓
Customer satisfaction ↓
Đó không phải là một “side effect” nằm ngoài hệ thống.
Nó là một effect của cùng hệ thống, chỉ là bạn chưa nhìn thấy loop đó.
9️⃣ Delays khiến Systems Thinking khó
Một trong những lý do hệ thống xã hội khó phân tích là:
Effects không xuất hiện ngay lập tức.
Ví dụ:
Training
↓
↓
↓ DELAY
↓
Employee skill ↑
↓
Customer satisfaction ↑
↓
Complaints ↓
↓
Manager workload ↓
↓
Manager có thêm thời gian
↓
More coaching
↓
Employee skill ↑
Nếu chỉ nhìn hôm nay:
“Training đang lấy mất thời gian.”
Bạn có thể kết luận sai.
Vì effect thật sự có thể xuất hiện sau nhiều tuần hoặc nhiều tháng.
🔟 Feedback Loop
Một ví dụ trong bài giảng:
Employee Skill
│
▼
Customer Satisfaction
│
▼
Complaints
│
▼
Manager Time Resolving Issues
│
▼
Manager Time Coaching
│
└──────────────► Employee Skill
Khi employee skill tăng:
Skill ↑
↓
Customer Satisfaction ↑
↓
Complaints ↓
↓
Issue Resolution Time ↓
↓
Coaching Time ↑
↓
Skill ↑
Đây là một Reinforcing Loop.
Một thay đổi ban đầu có thể tạo ra chuỗi thay đổi tiếp tục khuếch đại chính nó.
1️⃣1️⃣ Reinforcing vs Balancing Loop
Hai loại loop cơ bản:
🔄 Reinforcing Loop
A ↑
↓
B ↑
↓
C ↑
↓
A ↑
Nó khuếch đại thay đổi.
Ví dụ:
Skill ↑
↓
Satisfaction ↑
↓
Complaints ↓
↓
Coaching Time ↑
↓
Skill ↑
⚖️ Balancing Loop
Balancing loop có xu hướng đưa hệ thống về phía một mục tiêu hoặc trạng thái cân bằng.
Current Performance
│
▼
Gap
│
▼
Action
│
▼
Performance changes
│
└────────► Gap ↓
Ví dụ:
Desired Performance
│
▼
GAP
│
▼
Improvement
│
▼
Current Performance ↑
│
└────────► GAP ↓
Đây chính là logic của goal-seeking loop được trình bày trong bài.
1️⃣2️⃣ Một concept cực kỳ quan trọng: Stock & Flow
Systems Thinking không chỉ nói về feedback.
Một concept nền tảng khác là:
Stock và Flow.
Hãy tưởng tượng một cái bồn nước:
INFLOW
│
▼
┌───────────┐
│ │
│ STOCK │
│ │
└─────┬─────┘
│
▼
OUTFLOW
Stock
Là thứ tích lũy theo thời gian.
Ví dụ:
- Số lượng nhân viên
- Inventory
- Wealth
- CO₂ trong khí quyển
Flow
Là thứ làm stock tăng hoặc giảm.
Employees
↑
Hiring
↓
Employees
↓
Leaving
Hoặc:
Inventory
↑
Production
↓
Inventory
↓
Shipment
Bài giảng mô tả stock như một thứ có “memory” — trạng thái hiện tại phụ thuộc vào sự tích lũy của thay đổi theo thời gian.
🎯 Framework ghi nhớ
Nếu muốn bắt đầu phân tích một vấn đề bằng Systems Thinking, hãy đi theo chuỗi:
① EVENT
│
▼
② PATTERN
│
▼
③ STRUCTURE
│
▼
④ FEEDBACK
│
▼
⑤ DELAY
│
▼
⑥ BEHAVIOR
│
▼
⑦ NEW RESULT
│
└──────────► FEEDBACK
Thay vì hỏi:
“Ai gây ra vấn đề?”
Hãy hỏi:
“Cấu trúc nào đang tạo ra hành vi này?”
Thay vì hỏi:
“Tại sao chuyện này xảy ra?”
Hãy hỏi:
“Tại sao nó cứ tiếp tục xảy ra?”
Và thay vì:
“Giải pháp nào xử lý vấn đề ngay bây giờ?”
Hãy hỏi:
“Giải pháp này sẽ tạo ra feedback loop nào trong tương lai?”
🧠 SYSTEM THINKING IN ONE PICTURE
SYSTEM
│
┌────────────┼────────────┐
▼ ▼ ▼
STRUCTURE INFORMATION INCENTIVE
│ │ │
└────────────┼────────────┘
▼
DECISION
│
▼
BEHAVIOR
│
▼
EVENT
│
▼
PATTERN
│
▼
FEEDBACK
│
▼
SYSTEM CHANGES
│
└──────────────► DECISION
Đây là lúc bạn bắt đầu chuyển từ:
Linear Thinking
↓
"A gây ra B"
sang:
Systems Thinking
↓
"A ảnh hưởng B
B ảnh hưởng C
C quay lại ảnh hưởng A"
Và đó chính là sự khác biệt giữa việc nhìn thấy một vấn đề và hiểu hệ thống tạo ra vấn đề đó.