Mở đầu — vì sao bài này quan trọng
Trong suốt chuỗi bài về Systems Thinking, chúng ta đã học cách nhìn hệ thống như một mạng lưới các vòng phản hồi, độ trễ, và các archetype lặp đi lặp lại. Nhưng có một câu hỏi mà rất ít người dừng lại để hỏi trước khi hành động: "Tình huống tôi đang đối mặt thuộc loại nào?" Đây không phải câu hỏi vô thưởng vô phạt. Bởi vì cách bạn ra quyết định cho một dây chuyền lắp ráp ổn định hoàn toàn khác với cách bạn ra quyết định khi một sản phẩm mới đang ra mắt thị trường mà chưa ai biết khách hàng sẽ phản ứng ra sao.
Sai lầm đắt giá nhất của nhiều nhà quản lý Việt Nam — và cả thế giới — là áp dụng "best practice" (cách làm tốt nhất đã được chứng minh) vào một bối cảnh mà bản chất của nó không cho phép có "best practice". Họ mang tư duy của nhà máy vào việc xây dựng văn hóa đội ngũ. Họ mang tư duy lập kế hoạch chi tiết vào một thị trường đang biến động khôn lường. Kết quả là họ tốn tiền, mất thời gian, và tệ hơn, đánh mất niềm tin của đội ngũ.
Cynefin Framework — do Dave Snowden phát triển trong thời gian làm việc tại IBM đầu những năm 2000 — chính là công cụ giúp bạn trả lời câu hỏi nền tảng đó: "Bối cảnh này là loại nào, và do đó cách ra quyết định phù hợp là gì?" Cynefin (đọc gần như "ku-NEV-in", tiếng xứ Wales nghĩa là "nơi chốn", "môi trường gắn bó") không phải một mô hình phân loại tĩnh. Nó là một khung "sense-making" — khung giúp ta nhận diện ý nghĩa của tình huống — để chọn đúng kiểu hành động. Với người làm Lean và VSM, đây là mảnh ghép tư duy cực kỳ quan trọng: nó cho bạn biết khi nào quy trình chuẩn hóa phát huy tác dụng, và khi nào bạn phải buông quy trình ra để thử nghiệm.
Khái niệm cốt lõi
Cynefin chia các tình huống ra quyết định thành năm "domain" (vùng/lãnh địa). Bốn vùng chính được sắp xếp theo mức độ rõ ràng của quan hệ nhân–quả, cộng thêm một vùng thứ năm rất đặc biệt nằm ở giữa.
1. Clear (Rõ ràng) — trước đây gọi là Obvious/Simple
Đây là vùng mà quan hệ nhân–quả hiển nhiên với tất cả mọi người. Bạn làm A thì chắc chắn ra B. Có "best practice" rõ ràng, được viết thành quy trình, ai làm cũng giống nhau.
Cách hành động: Sense – Categorize – Respond (Cảm nhận tình huống → Phân loại nó vào nhóm đã biết → Phản hồi theo quy trình chuẩn). Ví dụ: khách gọi tổng đài, nhân viên đối chiếu vào kịch bản, trả lời theo kịch bản. Đây là vùng của SOP, checklist, of quy trình 5S đã ổn định.
Cảnh báo: vùng Clear có một "vực" nguy hiểm ngay cạnh nó. Khi ta quá tự tin, ta dễ rơi vào trạng thái tự mãn, đơn giản hóa quá mức, và khi một cú sốc xảy ra, ta rơi thẳng xuống vùng Chaotic. Snowden vẽ ranh giới giữa Clear và Chaotic như một vách đá (cliff), không phải một đường mượt.
2. Complicated (Phức tạp) — cần chuyên gia
Ở đây vẫn có quan hệ nhân–quả, nhưng nó không hiển nhiên. Bạn cần chuyên gia phân tích mới thấy được. Có thể có nhiều cách đúng — không phải một "best practice" duy nhất mà là "good practice" (cách làm tốt).
Cách hành động: Sense – Analyze – Respond (Cảm nhận → Phân tích bằng chuyên môn → Phản hồi). Ví dụ: chẩn đoán vì sao máy CNC bị lệch dung sai, tối ưu thời gian Takt cho một line phức tạp, thiết kế hệ thống điều hòa cho tòa nhà. Bạn thuê kỹ sư, họ tính toán, rồi ra giải pháp.
Đây là vùng mà phần lớn công cụ Lean phân tích (như A3, root cause analysis, VSM future state) hoạt động: vấn đề khó nhưng có thể tìm ra lời giải qua phân tích.
3. Complex (Phức hợp) — không thể đoán trước
Đây là vùng cốt lõi của Systems Thinking và cũng là vùng dễ bị nhầm với Complicated nhất. Trong vùng Complex, quan hệ nhân–quả chỉ nhìn thấy được sau khi sự việc đã xảy ra (retrospective coherence), không thể đoán trước. Hệ thống có quá nhiều tác nhân tương tác, có vòng phản hồi, có hành vi nổi (emergent). Bạn không thể phân tích để biết trước kết quả — bạn phải thử.
Cách hành động: Probe – Sense – Respond (Thăm dò bằng thử nghiệm an toàn → Cảm nhận tín hiệu → Khuếch đại cái hiệu quả, dập cái không hiệu quả). Ở đây ta nói về "safe-to-fail experiments" (thử nghiệm an toàn khi thất bại), không phải "fail-safe" (chống thất bại). Practice ở đây là "emergent practice" — cách làm nổi lên từ chính việc thử.
Ví dụ: xây dựng văn hóa đội ngũ, ra mắt sản phẩm mới, thay đổi hành vi khách hàng, chuyển đổi số. Bạn không thể viết một SOP cho "làm sao để nhân viên gắn kết hơn". Bạn thử nhiều thứ nhỏ, quan sát, rồi nhân rộng cái nào có hiệu quả.
4. Chaotic (Hỗn loạn) — không có thời gian phân tích
Không có quan hệ nhân–quả nào nhận diện được. Khủng hoảng. Mọi thứ đang sụp đổ. Ưu tiên số một là dừng chảy máu, lập lại trật tự tối thiểu.
Cách hành động: Act – Sense – Respond (Hành động ngay để ổn định → Cảm nhận xem tình hình chuyển biến thế nào → Phản hồi để kéo về vùng Complex). Practice ở đây là "novel practice" — cách làm mới mẻ, chưa từng có. Ví dụ: nhà máy cháy, server sập toàn hệ thống lúc cao điểm, một scandal truyền thông bùng nổ. Lúc này không ai hỏi "best practice là gì" — bạn hành động.
5. Confusion (Aporia / Disorder) — vùng giữa
Vùng thứ năm nằm ở chính giữa: trạng thái bạn không biết mình đang ở vùng nào. Đây là vùng nguy hiểm âm thầm nhất, vì mỗi người trong phòng họp sẽ vô thức kéo vấn đề về vùng mà họ quen thuộc nhất: kế toán nhìn mọi thứ như Clear, kỹ sư nhìn như Complicated, người làm đổi mới nhìn như Complex. Mục tiêu khi ở Confusion là nhanh chóng tách vấn đề ra và đẩy các phần về đúng vùng của nó.
Vì sao khung này khớp với Lean/VSM
Một sai lầm kinh điển: lãnh đạo áp dụng "Toyota làm thế này nên ta cũng làm thế" (tư duy Clear/best practice) vào một bài toán thực ra là Complex (văn hóa, con người, thị trường). Cynefin nhắc ta: công cụ Lean rất mạnh trong vùng Clear và Complicated, nhưng khi bước vào vùng Complex, ta cần chuyển sang tư duy thử nghiệm — đúng tinh thần Kaizen thực thụ chứ không phải sao chép máy móc.
Tình huống thực tế
Ví dụ 1 — Chuỗi cà phê Việt mở rộng nhanh (nhầm Complex thành Clear)
Một chuỗi cà phê giả định tên "Cà Phê Đồng Xanh" tại TP.HCM có 8 cửa hàng vận hành rất tốt. Quy trình pha chế được chuẩn hóa, mỗi ly cà phê sữa đá đều ra đúng công thức 18 giây — đây là vùng Clear, SOP hoạt động hoàn hảo. Tự tin với thành công đó, ban giám đốc quyết định nhân bản công thức ấy ra 40 cửa hàng trong 12 tháng, kèm theo việc ép mỗi quản lý cửa hàng tuân thủ y hệt "playbook" về cách tuyển nhân viên, cách tạo không khí quán, cách giữ chân khách quen.
Kết quả: 14 cửa hàng mới ở các tỉnh lỗ nặng. Vì sao? Việc pha chế là Clear, nhưng "tạo cộng đồng khách quen ở một thị trấn mới" là vùng Complex — phụ thuộc văn hóa địa phương, thói quen, mạng lưới quan hệ. Họ đã áp SOP (best practice) vào một bài toán đòi hỏi probe–sense–respond.
Diễn giải: ban giám đốc lẽ ra nên tách bài toán. Pha chế và vận hành quầy: chuẩn hóa cứng (Clear). Xây tệp khách địa phương: chạy thử nghiệm nhỏ ở 3 cửa hàng pilot, mỗi nơi thử một cách kết nối cộng đồng khác nhau, đo đạc trong 8 tuần, rồi mới nhân rộng cái hiệu quả.
Bài học: cùng một doanh nghiệp có thể tồn tại nhiều vùng Cynefin cùng lúc. Đừng dùng một kiểu tư duy cho mọi phần.
Ví dụ 2 — Sự cố sập hệ thống của một sàn TMĐT (Chaotic → Complex)
Hãy hình dung một sàn thương mại điện tử Đông Nam Á trong ngày sale 11/11. Lúc 20h, hệ thống thanh toán sập hoàn toàn, hàng trăm nghìn đơn treo, mạng xã hội bắt đầu sôi sục. Đây là vùng Chaotic thuần túy.
Đội kỹ thuật không họp 2 tiếng để phân tích root cause. Họ Act ngay: cô lập module thanh toán lỗi, chuyển sang cổng dự phòng, hiển thị thông báo tạm cho khách. Đó là "novel practice" — quyết định nhanh, chưa từng có trong sổ tay. Sau khoảng 40 phút, hệ thống ổn định trở lại ở mức tối thiểu — họ đã kéo tình huống từ Chaotic về một trạng thái có thể quản lý.
Tuần sau, vấn đề chuyển vùng. "Vì sao hệ thống chịu tải kém ở đỉnh điểm?" lúc này là một bài toán Complicated — cần các kỹ sư hệ thống phân tích kiến trúc, mô phỏng tải, đề xuất giải pháp scaling. Còn "làm sao khôi phục niềm tin khách hàng đã giận dữ?" lại nghiêng về Complex — phải thử nhiều cách bù đắp, đo phản ứng cộng đồng.
Bài học: tình huống không đứng yên trong một vùng. Người lãnh đạo giỏi nhận ra sự dịch chuyển vùng theo thời gian và đổi kiểu hành động tương ứng. Dùng tư duy Chaotic (hành động vội) khi đã sang vùng Complicated sẽ tạo ra giải pháp chắp vá; ngược lại, dùng tư duy phân tích chậm rãi khi đang Chaotic sẽ khiến doanh nghiệp chết chìm.
Ví dụ 3 — FPT và bài toán chuyển đổi cách làm việc (Complicated vs Complex)
Lấy bối cảnh một công ty phần mềm lớn của Việt Nam muốn triển khai một framework Agile mới trên toàn bộ vài nghìn kỹ sư. Ban đầu lãnh đạo coi đây là bài toán Complicated: thuê chuyên gia tư vấn, thiết kế quy trình chuẩn, đào tạo, rollout đồng loạt. Phần "thiết kế quy trình và công cụ" đúng là Complicated và làm tốt.
Nhưng phần "thay đổi cách hàng nghìn con người thực sự cộng tác hằng ngày" lại là Complex. Khi áp quy trình chuẩn lên mọi đội, một số đội bùng nổ năng suất, một số đội lại đình trệ vì bản chất công việc và con người khác nhau. Quan hệ nhân–quả ở đây chỉ thấy được sau khi thử.
Cách xử lý đúng tinh thần Cynefin: chọn vài đội làm pilot, cho phép mỗi đội điều chỉnh cách áp dụng (probe), quan sát chỉ số (sense), rồi lan tỏa mô hình của những đội thành công nhất ra toàn công ty (amplify). Đây cũng chính là cách Kaizen và "emergent practice" gặp nhau.
Bài học: một sáng kiến chuyển đổi lớn gần như luôn có cả phần Complicated (công cụ, quy trình) lẫn phần Complex (con người, văn hóa). Đối xử với cả hai bằng cùng một cách là công thức thất bại.
Hướng dẫn từng bước
Khi bạn đối mặt một quyết định hoặc một vấn đề, hãy chạy quy trình sau:
Bước 1 — Viết rõ vấn đề cụ thể. Đừng để mơ hồ. "Cải thiện đội ngũ" quá rộng. Hãy tách thành các vấn đề nhỏ, cụ thể: "giảm thời gian onboarding nhân viên mới", "tăng tỷ lệ khách quay lại".
Bước 2 — Với mỗi vấn đề, hỏi về quan hệ nhân–quả. Nhân–quả có hiển nhiên với mọi người không? → Clear. Cần chuyên gia phân tích mới thấy? → Complicated. Chỉ thấy được sau khi thử? → Complex. Không thấy gì, đang khủng hoảng? → Chaotic. Không chắc thuộc đâu? → Bạn đang ở Confusion, quay lại tách nhỏ vấn đề.
Bước 3 — Chọn kiểu hành động đúng với vùng.
- Clear → áp SOP/checklist (Sense–Categorize–Respond).
- Complicated → mời chuyên gia phân tích (Sense–Analyze–Respond).
- Complex → thiết kế thử nghiệm an toàn (Probe–Sense–Respond).
- Chaotic → hành động ổn định ngay (Act–Sense–Respond).
Bước 5 — Theo dõi sự dịch chuyển vùng. Sau khi hành động, tình huống thường chuyển vùng (Chaotic → Complex → Complicated → Clear). Định kỳ đánh giá lại: "Giờ vấn đề này đang ở vùng nào?" và đổi cách tiếp cận tương ứng.
Lỗi thường gặp & mẹo
Lỗi 1 — Áp best practice vào vùng Complex. Đây là lỗi phổ biến nhất. "Công ty X làm thế này thành công nên ta copy". Trong vùng Complex, không tồn tại best practice — chỉ có emergent practice. Mẹo: hễ thấy bài toán liên quan tới con người, văn hóa, hay thị trường mới, hãy nghi ngờ ngay rằng nó là Complex và chuyển sang chế độ thử nghiệm.
Lỗi 2 — Nhầm Complex thành Complicated. Cả hai đều "khó", nhưng Complicated giải được bằng phân tích, còn Complex thì không. Triệu chứng: bạn thuê tư vấn xịn, có báo cáo dày 80 trang, làm đúng kế hoạch mà kết quả vẫn lệch. Đó là dấu hiệu bài toán thực ra là Complex. Mẹo: nếu hai chuyên gia giỏi ngang nhau đưa ra hai kết luận trái ngược và đều có lý, khả năng cao bạn đang ở Complex.
Lỗi 3 — Tự mãn ở vùng Clear và rơi xuống vực Chaotic. Quy trình chạy quá êm khiến ta ngừng đặt câu hỏi, bỏ qua tín hiệu yếu của rủi ro. Mẹo: định kỳ làm "pre-mortem" — giả định hệ thống đã sập, hỏi vì sao, để phát hiện sớm điểm gãy.
Lỗi 4 — Ở lại Chaotic quá lâu vì nghiện cảm giác "anh hùng cứu hỏa". Một số lãnh đạo vô thức thích khủng hoảng vì lúc đó họ được toàn quyền hành động. Mẹo: mục tiêu của Chaotic luôn là kéo nhanh về Complex, không phải sống mãi trong nó.
Mẹo lớn nhất: đừng phân loại cả doanh nghiệp vào một vùng. Một dự án luôn chứa nhiều mảnh ở nhiều vùng khác nhau. Việc tách đúng từng mảnh và đối xử với mỗi mảnh theo đúng vùng của nó mới là nghệ thuật.
Bài tập thực hành
Bài 1 — Phân vùng vấn đề của chính bạn. Liệt kê 5 vấn đề bạn đang xử lý trong công việc. Với mỗi vấn đề, dùng Bước 2 ở trên để gán vào một trong bốn vùng. Ghi rõ lý do bạn xếp nó vào vùng đó (dựa trên đặc tính nhân–quả).
Bài 2 — Tách một dự án. Chọn một sáng kiến lớn đang triển khai (ví dụ: ra mắt sản phẩm, triển khai phần mềm mới, mở chi nhánh). Tách nó thành ít nhất 4 phần nhỏ, gán mỗi phần vào một vùng Cynefin, và viết kiểu hành động phù hợp cho từng phần.
Bài 3 — Thiết kế một safe-to-fail experiment. Lấy một vấn đề bạn đã xác định là Complex ở Bài 1. Thiết kế một thử nghiệm an toàn theo 4 tiêu chí ở Bước 4: nhỏ, chi phí thất bại chấp nhận được, cách đo, cách khuếch đại/dập. Mô tả trong nửa trang.
Bài 4 — Soi lại một thất bại cũ. Nhớ lại một quyết định trong quá khứ không như mong đợi. Theo bạn, lúc đó bạn đã xếp nhầm vấn đề vào vùng nào? Nếu xếp đúng, bạn sẽ hành động khác ra sao?
Tóm tắt
Cynefin Framework của Dave Snowden là một khung "sense-making" giúp bạn trả lời câu hỏi nền tảng trước mọi quyết định: "Bối cảnh này thuộc loại nào?" Năm vùng gồm: Clear (nhân–quả hiển nhiên, dùng best practice, Sense–Categorize–Respond), Complicated (cần chuyên gia, good practice, Sense–Analyze–Respond), Complex (chỉ hiểu được sau khi thử, emergent practice, Probe–Sense–Respond), Chaotic (khủng hoảng, novel practice, Act–Sense–Respond), và Confusion ở giữa (không biết mình đang ở đâu).
Bài học cốt lõi cho người làm Lean và Systems Thinking: công cụ chuẩn hóa rất mạnh trong vùng Clear và Complicated, nhưng các bài toán về con người, văn hóa và thị trường thường nằm ở vùng Complex — nơi bạn phải buông quy trình ra và chuyển sang tư duy thử nghiệm. Sai lầm đắt nhất là áp "best practice" vào nơi không hề có best practice. Hãy luôn tách vấn đề lớn thành các mảnh nhỏ, gán đúng vùng cho từng mảnh, và đối xử với mỗi mảnh bằng đúng kiểu hành động của nó. Đó là cách biến Cynefin từ một sơ đồ đẹp thành một thói quen ra quyết định thực sự.