Skip to content
Khi nhìn vào Israel, “Quốc gia Khởi nghiệp”, chúng ta thường thấy một cụm từ được nhắc đi nhắc lại: Họ không sợ thất bại, thậm chí coi thất bại là tài sản. Đó là nền tảng văn hóa, là triết lý xương sống giúp một quốc gia nhỏ bé có thể trở thành trung tâm công nghệ toàn cầu.
Nhưng nếu chỉ dừng lại ở câu nói đó – “cứ thất bại đi, thất bại là mẹ thành công” – thì e rằng chúng ta đã đọc được đúng lời, nhưng hiểu sai bản chất.
Trong mắt những người đang trực tiếp điều hành, tái cấu trúc hoặc cố gắng xây dựng hệ thống tăng trưởng ổn định, thất bại không phải là một chiếc huy chương dễ dàng đeo lên ngực. Nó là chi phí vận hành, là bài học đắt giá, và quan trọng nhất, nó phải được kiểm soát và chuyển hóa. Nếu không, thất bại chỉ là sự lãng phí tài nguyên và rủi ro phá sản.
Bài viết này không nhằm tóm tắt sách, mà là một cuộc đối thoại giữa tinh thần dám chấp nhận rủi ro của Israel và áp lực vận hành thực tế tại các doanh nghiệp đang cố gắng bước ra khỏi vùng an toàn.
***
MỤC LỤC
1. Thất Bại Như Một Tài Sản: Cái giá của sự Học Hỏi
- Bản chất của văn hóa "Sheldon": Thất bại có chủ đích.
- Sai lầm phổ biến: Nhầm lẫn giữa Rủi ro Chiến lược và Quản trị Lỏng lẻo.
2. Rào Cản Vận Hành: Vì sao CEO Việt Nam ngại thất bại?
- Áp lực từ Vòng vốn và Kiểm soát Nội bộ (Internal Control).
- Vấn đề Vòng lặp Học hỏi (Learning Loop) và Chuyển giao kinh nghiệm.
3. Cần Gì Để Thất Bại Thông Minh?
- Vai trò của Hệ thống Vận hành (SOC/SaaS).
- Xây dựng KPIs đo lường Tốc độ Học hỏi, không chỉ Hiệu suất Đầu ra.
4. Đối Thoại Thực Tế: Góc nhìn Tái Cấu Trúc
- Case Study 1: Cái giá của sự hỗn loạn dưới danh nghĩa "Fail Fast".
- Case Study 2: Chiến lược chấp nhận Tổn thất Tối đa (Max Pain) trong tái cấu trúc SME.
5. Tư Duy Chuyển Hóa: Điều nên Học và Điều cần Cẩn trọng.
***
1. Thất Bại Như Một Tài Sản: Cái giá của sự Học Hỏi
Bản chất của văn hóa "Sheldon": Thất bại có chủ đích
Cốt lõi triết lý của Israel nằm ở chỗ: Họ không khuyến khích bất kỳ thất bại nào. Họ khuyến khích thất bại có giá trị thông tin cao.
Nghĩa là, khi bạn quyết định khởi nghiệp hoặc bắt đầu một dự án, bạn được kỳ vọng sẽ làm việc dựa trên những giả định chưa được chứng minh (unproven hypotheses). Nếu dự án đó thất bại, điều đó có nghĩa là giả định ban đầu của bạn đã sai. Nhưng nếu bạn có khả năng trình bày rõ ràng:
– Bạn đã thử nghiệm gì? (What did you test?)
– Bạn đã học được gì? (What did you learn?)
– Dữ liệu nào chứng minh điều đó? (What data confirms it?)
Thì thất bại đó không phải là một dấu chấm hết, mà là một bước tiến trong quá trình tìm kiếm giải pháp.
Văn hóa này được hun đúc mạnh mẽ từ môi trường quân đội (đặc biệt là đơn vị 8200) và áp lực sinh tồn. Trong môi trường đó, thử nghiệm nhanh, học hỏi nhanh, và truyền lại kinh nghiệm cho đội kế tiếp là điều kiện bắt buộc để tồn tại. Không có chỗ cho sự kiêu ngạo hay sợ hãi thể hiện sai lầm, bởi vì thất bại của cá nhân có thể là thông tin sống còn cho tập thể.
Đó là lý do tại sao các nhà đầu tư mạo hiểm (VC) Israel thường chấp nhận việc một founder có hồ sơ thất bại rõ ràng, miễn là họ chứng minh được khả năng phục hồi và bộ dữ liệu học hỏi từ lần vấp ngã trước.
Sai lầm phổ biến: Nhầm lẫn giữa Rủi ro Chiến lược và Quản trị Lỏng lẻo
Đây là điểm gãy phổ biến nhất khi các startup Việt Nam cố gắng áp dụng triết lý này.
Rủi ro Chiến lược (Strategic Risk) là rủi ro bạn chấp nhận khi cố gắng làm điều chưa ai làm, hoặc làm điều đã có theo một cách hoàn toàn mới (ví dụ: thâm nhập thị trường mới, phát triển công nghệ đột phá). Đây là loại rủi ro được khuyến khích trong tinh thần "Quốc gia Khởi nghiệp".
Quản trị Lỏng lẻo (Operational Laziness/Governance Failure) là rủi ro xuất phát từ việc thiếu kiểm soát nội bộ, quản lý tài chính yếu kém, không theo dõi KPIs, hoặc triển khai kế hoạch nửa vời.
Khi một startup thất bại, nếu nguyên nhân là do:
– Không có mô hình kinh doanh rõ ràng.
– Không quản lý dòng tiền.
– Chi tiêu không kiểm soát.
– Mâu thuẫn nội bộ không giải quyết được.
Đó không phải là thất bại đáng giá, đó là kém chuyên nghiệp. Nhưng nhiều founder lại dùng tấm khiên "Fail Fast, Learn Faster" để biện minh cho sự thiếu kỷ luật trong vận hành.
***
Bảng 1: Phân biệt Thất bại Giá trị cao và Thất bại Vận hành
| Đặc điểm | Thất bại Giá trị Cao (Strategic Failure) | Thất bại Vận hành (Operational Failure) |
|---|---|---|
| Mục tiêu | Chứng minh giả định (Hypothesis Testing) | Đạt mục tiêu đã biết (Execution Goal) |
| Chi phí | Định sẵn và Kiểm soát được (Budgeted Loss) | Vượt ngân sách, không kiểm soát được |
| Sản phẩm | Dữ liệu, Bài học Chuyển giao, Tốc độ (Speed) | Mất mát tài sản, Giảm niềm tin nhân sự |
| Khả năng tái lập | Cao (Có thể lặp lại thử nghiệm mới) | Thấp (Lỗi thường xuyên, thiếu quy trình) |
| Câu hỏi cốt lõi | "Điều gì chúng ta đã học được về thị trường/sản phẩm?" | "Tại sao chúng ta không làm theo đúng quy trình?" |
Nếu bạn không thể xác định rõ thất bại của mình thuộc cột nào, nhiều khả năng bạn đang ở cột thứ hai.
***
2. Rào Cản Vận Hành: Vì sao CEO Việt Nam ngại thất bại?
Triết lý chấp nhận thất bại cần một hệ thống hỗ trợ khổng lồ để nó hoạt động hiệu quả. Trong bối cảnh kinh doanh Việt Nam, rào cản lớn nhất không phải là văn hóa cá nhân, mà là:
Áp lực từ Vòng vốn và Kiểm soát Nội bộ (Internal Control)
Startup Israel thường hoạt động trong một hệ sinh thái VC có độ chín muồi cao. Các quỹ đầu tư hiểu rằng công nghệ đột phá cần nhiều vòng thử nghiệm và thời gian quay vốn dài hơn. Họ chấp nhận chi phí thử nghiệm (Cost of Experimentation) là một phần của tổng chi phí đầu tư.
Ngược lại, tại Việt Nam, nhiều startup thường phụ thuộc vào vốn tự có, vốn vay ngân hàng (với áp lực trả nợ ngắn hạn), hoặc các vòng gọi vốn nhỏ lẻ từ nhà đầu tư thiên thần/quỹ non trẻ. Các nhà đầu tư này thường yêu cầu:
– Lộ trình tăng trưởng tuyến tính và rõ ràng.
– KPIs cứng (Hard KPIs) về doanh số, thị phần, chứ không phải KPIs mềm về Tốc độ Học hỏi (Learning Velocity).
– Rủi ro cá nhân hóa cao: Nếu thất bại, founder thường phải chịu trách nhiệm cá nhân rất lớn (mất nhà, nợ nần), điều này tạo ra tâm lý "thà làm chậm, thà làm an toàn còn hơn mất tất cả".
Để áp dụng triết lý thất bại, bạn cần một hệ thống Kiểm soát Nội bộ (Internal Control) đủ mạnh để đảm bảo rằng khi một dự án thất bại, nó chỉ thất bại theo đúng kịch bản và ngân sách định sẵn (Fail within the box).
Ví dụ: Nếu bạn cấp 500 triệu đồng cho một dự án R&D đầy rủi ro. Hệ thống kiểm soát nội bộ phải đảm bảo 500 triệu đó được chi tiêu đúng mục tiêu nghiên cứu, không bị chuyển thành chi phí điều hành hoặc rút ruột. Nếu không có Internal Control mạnh, thất bại 500 triệu đồng trở thành tổn thất 5 tỷ đồng khi nó kéo theo sự sụp đổ của các phòng ban khác.
Vấn đề Vòng lặp Học hỏi (Learning Loop) và Chuyển giao kinh nghiệm
Điều làm nên "tài sản" của thất bại là khả năng chuyển giao kinh nghiệm. Ở Israel, vòng luân chuyển nhân sự giữa quân đội, startup, và các tập đoàn lớn diễn ra rất nhanh. Khi một dự án A thất bại, những người trong dự án A sẽ mang kinh nghiệm đó sang dự án B hoặc startup C.
Ở Việt Nam, chúng ta thường gặp tình trạng:
– Thất bại dẫn đến sự im lặng và sợ hãi. Không ai muốn làm Post-Mortem (phân tích sau dự án) vì sợ bị quy trách nhiệm.
– Founder và ban lãnh đạo thường không chấp nhận thừa nhận sai lầm công khai, dẫn đến kinh nghiệm bị chôn vùi trong cá nhân người thực hiện.
– Khi nhân sự cốt lõi rời đi (do thất bại hoặc chuyển việc), kinh nghiệm đó cũng mất theo. Doanh nghiệp tiếp theo lại phải trả đúng cái giá thử nghiệm đó một lần nữa.
Để thất bại thành tài sản, bạn cần thể chế hóa việc học hỏi. Tức là, kinh nghiệm phải được ghi lại trong quy trình vận hành chuẩn (SOPs), được số hóa, và được đào tạo lại cho đội ngũ mới.
***
3. Cần Gì Để Thất Bại Thông Minh?
Thất bại thông minh không phải là một hành động đơn lẻ, nó là kết quả của một kiến trúc vận hành được thiết kế để chịu đựng rủi ro.
Vai trò của Hệ thống Vận hành (SOC/SaaS)
Thất bại nhanh (Fail Fast) đòi hỏi khả năng tái lập nhanh (Fast Recovery). Bạn không thể thất bại nhanh nếu quy trình vận hành của bạn quá nặng nề, thiếu minh bạch, hoặc không dựa trên dữ liệu.
Đây là nơi mà việc áp dụng công nghệ và chuẩn mực quản trị đóng vai trò then chốt:
– Cloud Adoption và Hệ thống ERP/SCM: Các công ty Israel (và các công ty công nghệ lớn khác) dùng hệ thống vận hành trên nền tảng Cloud (điện toán đám mây) để kiểm soát tài nguyên và luồng công việc theo thời gian thực. Điều này cho phép họ nhanh chóng cắt giảm chi phí (pivot) khi giả định thất bại, mà không phải vật lộn với quy trình mua sắm, kho bãi, hoặc tài sản cố định.
– SOC (Service Organization Control): Chuẩn mực kiểm soát nội bộ, đặc biệt quan trọng khi bạn làm việc với dữ liệu nhạy cảm hoặc đối tác quốc tế. SOC đảm bảo rằng ngay cả khi một dự án thất bại và đội ngũ thay đổi, tính toàn vẹn và bảo mật của dữ liệu vẫn được duy trì.
Nếu bạn muốn thất bại nhanh, bạn phải có khả năng tắt một dự án ngay lập tức, chuyển nguồn lực sang dự án khác mà không làm sụp đổ các chức năng hỗ trợ (tài chính, nhân sự, IT). Hệ thống vận hành là bộ phận giảm xóc cho những cú sốc chiến lược này.
Xây dựng KPIs đo lường Tốc độ Học hỏi, không chỉ Hiệu suất Đầu ra
Chúng ta thường đo lường hiệu suất bằng các chỉ số đầu ra cứng (Doanh thu, Lợi nhuận, Khách hàng mới). Nhưng để khuyến khích sự đổi mới và chấp nhận rủi ro, chúng ta cần KPIs đo lường các chỉ số đầu vào và quy trình:
| Chỉ số truyền thống (Output KPIs) | Chỉ số học hỏi (Learning Velocity KPIs) |
|---|---|
| Số lượng sản phẩm/tính năng tung ra | Tỷ lệ thí nghiệm được thực hiện thành công/thất bại |
| Doanh thu từ tính năng mới | Chi phí trung bình cho mỗi giả định được chứng minh |
| Tỷ lệ chuyển đổi khách hàng | Tốc độ chu trình phát triển sản phẩm (Cycle time) |
| Tỷ lệ giữ chân nhân viên | Tỷ lệ nhân viên tham gia các buổi Post-Mortem/Lesson Learned |
Nếu bạn đánh giá một đội ngũ R&D dựa trên số lần họ thử nghiệm, thay vì số lần họ thành công, bạn đã tạo ra một môi trường an toàn để họ dám thất bại. Điều này đòi hỏi CEO và ban lãnh đạo phải có tầm nhìn dài hạn và chấp nhận rằng chi phí R&D đôi khi chỉ mang lại dữ liệu phủ định (negative data), chứ không phải doanh thu ngay lập tức. Dữ liệu phủ định, nói cho cùng, vẫn là một tài sản giá trị.
***
4. Đối Thoại Thực Tế: Góc nhìn Tái Cấu Trúc
Chúng ta sẽ đi sâu vào hai bối cảnh kinh doanh thực tế, nơi triết lý "thất bại là tài sản" được áp dụng (hoặc bị hiểu sai) trong quá trình tái cấu trúc doanh nghiệp.
Case Study 1: Cái giá của sự hỗn loạn dưới danh nghĩa "Fail Fast"
Bối cảnh doanh nghiệp:
Một startup công nghệ (PropTech) với mô hình B2B2C, đã qua vòng Seed, định giá khoảng 5 triệu USD. Founder là người trẻ, nhiệt huyết, tin vào triết lý "Fail Fast" tuyệt đối.
Vấn đề thực tế:
Họ thử nghiệm liên tục 4-5 mô hình kinh doanh nhỏ cùng lúc để tìm kiếm Product-Market Fit. Vấn đề là, việc thử nghiệm không được kiểm soát.
– Về Vận hành: Không có KPIs rõ ràng cho từng thử nghiệm. Chi phí R&D bị trộn lẫn với chi phí Marketing chung.
– Về Tài chính: Dòng tiền âm nặng. Nhân sự làm việc chồng chéo.
– Hệ quả: Sau 12 tháng, họ đã đốt hết 70% vốn mà không có dữ liệu tin cậy nào để chứng minh giả định nào là đúng hay sai. Mọi thứ là một mớ hỗn độn (chaotic experiment).
Điểm trong sách liên quan:
"Thua một trận không nghĩa là thua cuộc chiến." (Ý chí không sợ thất bại)
Cách áp dụng (hoặc không thể áp dụng):
Founder tin rằng thất bại của từng mô hình thử nghiệm nhỏ là "tài sản" và là "bài học cần thiết."
Tuy nhiên, khi đội tái cấu trúc vào cuộc, chúng tôi nhận ra đây không phải là thất bại chiến lược, mà là quản trị khủng hoảng.
– Phân tích: Thử nghiệm phải là quy trình kiểm soát (Controlled Experimentation). Bạn không thể "Fail Fast" nếu bạn không biết chính xác: (1) Bạn đã chi bao nhiêu cho thử nghiệm A? (2) Nếu thất bại, bao nhiêu dữ liệu được thu thập?
– Hệ quả khi hiểu sai: Việc thiếu Kiểm soát Nội bộ (Internal Control) biến các thất bại nhỏ thành một thất bại hệ thống lớn. Thất bại không được ghi nhận, không được đo lường, nên không thể chuyển thành tài sản. Nó chỉ là chi phí chìm (Sunk Cost) kéo cả công ty đi xuống.
Cách giải quyết của đội tái cấu trúc:
Chúng tôi phải buộc họ làm chậm lại để xây dựng lại nền tảng vận hành.
– Bước 1: Thiết lập KPIs cho từng "thử nghiệm" (thay vì dự án). KPIs này phải đo lường tốc độ đạt được dữ liệu phủ định/khẳng định, chứ không phải doanh số.
– Bước 2: Thiết lập hệ thống kiểm soát tài chính để phân bổ chi phí R&D tách biệt, với giới hạn ngân sách nghiêm ngặt (Hard Stop Budget).
– Bước 3: Tổ chức các buổi Post-Mortem bắt buộc để chuyển hóa dữ liệu thành SOPs vận hành mới.
Kết quả định lượng:
Sau 6 tháng, startup chỉ còn tập trung vào 1 mô hình đã được chứng minh là có khả năng tạo ra doanh thu. Mặc dù họ mất nhiều thời gian hơn so với ước tính ban đầu, nhưng họ đã mua được dữ liệu chính xác về thị trường bằng ngân sách có kiểm soát. Thất bại trước đó trở thành gánh nặng nợ nần (hỗn loạn) chứ không phải tài sản.
***
Case Study 2: Chiến lược chấp nhận Tổn thất Tối đa (Max Pain) trong tái cấu trúc SME
Bối cảnh doanh nghiệp:
Một công ty sản xuất truyền thống (SME) quy mô trung bình (khoảng 300 nhân sự), đã hoạt động 15 năm, với hai dòng sản phẩm chính A (truyền thống, lợi nhuận ổn định nhưng thị trường co hẹp) và B (mới, nhiều tiềm năng nhưng chưa hoàn thiện công nghệ).
Vấn đề thực tế:
Sản phẩm A đang nuôi sống công ty, nhưng nó ngốn 80% tài nguyên sản xuất và quản trị. Sản phẩm B cần đầu tư mạnh vào R&D nhưng ban lãnh đạo không dám "giết" A vì sợ mất dòng tiền. Công ty rơi vào trạng thái "tệ nhất": không chết, nhưng cũng không tăng trưởng được (Stagnation).
Điểm trong sách liên quan:
Tinh thần dám chấp nhận rủi ro và "thua một trận để thắng cuộc chiến lớn hơn."
Cách áp dụng:
Đây là trường hợp mà việc chấp nhận một thất bại (thua một trận) là bắt buộc để chiến thắng cuộc chiến tăng trưởng (cuộc chiến lớn hơn). Thất bại ở đây không phải là thất bại công nghệ, mà là thất bại chiến lược khi phải chấp nhận giết chết một dòng sản phẩm đang mang lại lợi nhuận.
– Phân tích: Lãnh đạo phải chấp nhận tổn thất tối đa có kiểm soát (Max Pain Strategy). Nghĩa là, phải chấp nhận một quý kinh doanh lỗ nặng, sa thải một phần nhân sự gắn bó với Dòng A, và chịu đựng sự phản đối của nhà cung cấp/khách hàng truyền thống.
– Hệ quả khi áp dụng: Sự chấp nhận thất bại này đòi hỏi sự dũng cảm về chiến lược, không phải về vận hành. Nó là hành động phá hủy sáng tạo (Creative Destruction) để giải phóng tài nguyên.
Cách giải quyết của đội tái cấu trúc:
– Bước 1: Định lượng chính xác chi phí ẩn (opportunity cost) của Dòng A (chi phí quản lý, chi phí tồn kho cũ, chi phí năng lượng R&D bị chìm).
– Bước 2: Lập kế hoạch "Shut-down" Dòng A trong 6 tháng, thay vì kéo dài 3 năm như dự tính ban đầu (chấp nhận thất bại nhanh).
– Bước 3: Chuyển toàn bộ tài nguyên (cả nhân sự và vốn) sang Dòng B, coi thất bại của Dòng A là kinh nghiệm về quản trị chuỗi cung ứng (SCM) không hiệu quả cho sản phẩm cũ.
Kết quả định lượng:
Công ty lỗ nặng trong quý chuyển đổi, nhưng sau 12 tháng, Dòng B phát triển nhanh hơn gấp 4 lần so với kịch bản trước đó, nhờ giải phóng được nguồn lực. Thất bại (việc hủy bỏ một dòng sản phẩm lợi nhuận) đã trở thành tài sản chiến lược – nó giải phóng nguồn lực cho tăng trưởng và chứng minh khả năng ra quyết định cứng rắn của ban lãnh đạo.
***
5. Tư Duy Chuyển Hóa: Điều nên Học và Điều cần Cẩn trọng
Triết lý thất bại của Israel là một lời nhắc nhở mạnh mẽ về tầm quan trọng của sự can đảm và tính linh hoạt. Tuy nhiên, khi nhìn vào trải nghiệm điều hành và tái cấu trúc doanh nghiệp, ta cần chắt lọc những bài học thực tế, tránh thần thánh hóa một cách máy móc.
Điều nên học (Actionable Takeaways)
- Mua Dữ liệu, không phải Sản phẩm: Coi các thử nghiệm R&D hoặc mô hình kinh doanh mới là hành động "mua dữ liệu" (dù kết quả là khẳng định hay phủ định). Đặt ngân sách cho việc mua dữ liệu này và coi đó là chi phí bắt buộc. Nếu thử nghiệm thất bại nhưng mang lại dữ liệu hữu ích, đó là ROI (Return on Investment) thông tin cao.
- Thiết lập Hard Stop Budget cho Thất bại: Bất kỳ thử nghiệm nào cũng phải có giới hạn tài chính và thời gian rõ ràng (Kill Criteria). Khi chạm giới hạn, bắt buộc phải dừng lại và đánh giá. Đây là cách Kiểm soát Nội bộ cho phép bạn chấp nhận rủi ro chiến lược mà không bị phá sản.
- Vinh danh Bài học, không Vinh danh Thất bại: Xây dựng quy trình Post-Mortem không đổ lỗi. Mục đích là chuyển hóa kinh nghiệm cá nhân thành kiến thức tổ chức. Dùng các buổi học này để cập nhật SOPs, thay vì tìm người chịu trách nhiệm.
Điều cần cẩn trọng (The Pitfalls)
- Đừng dùng Fail Fast để che đậy Run Slow: Đảm bảo rằng sự thất bại không phải là kết quả của việc ra quyết định chậm, quy trình cồng kềnh, hay thực thi yếu kém. Thất bại nhanh chỉ có giá trị khi quy trình triển khai của bạn đã ở mức độ chuyên nghiệp cao.
- Phân biệt Thất bại Đổi mới và Thất bại Đạo đức: Văn hóa chấp nhận thất bại không nên là cái cớ cho sự thiếu minh bạch, vi phạm các chuẩn mực đạo đức hoặc quy định pháp luật. Kiểm soát nội bộ mạnh mẽ (đặc biệt là khâu tài chính và tuân thủ) phải luôn là tuyến phòng thủ không thể phá vỡ.
- Hiểu rõ Giới hạn Vốn: Nếu bạn đang dùng vốn tự thân, vốn vay ngắn hạn, hoặc vốn VC non trẻ, áp lực thời gian của bạn cao hơn rất nhiều so với các startup được rót vốn VC quốc tế. Bạn cần thất bại nhanh hơn, rẻ hơn, và với biên độ sai sót nhỏ hơn.
Điều không nên thần thánh hóa
Thất bại ở Israel không chỉ là tư duy, mà còn là kết quả của một mật độ tài năng và hỗ trợ tài chính khổng lồ.
– Tài năng: Việc xoay vòng nhân sự cao cấp đã được huấn luyện bài bản từ đơn vị 8200 hoặc các tập đoàn lớn đảm bảo rằng, khi một startup thất bại, nguồn lực con người không bị lãng phí. Họ mang kỹ năng đó đi nơi khác.
– Vốn: Hệ sinh thái đầu tư mạo hiểm đủ kiên nhẫn để đợi chờ 7-10 năm mới thấy lợi nhuận từ các thử nghiệm công nghệ.
Nếu doanh nghiệp của bạn thiếu hai yếu tố trên, việc áp dụng máy móc triết lý này có thể dẫn đến việc đốt tiền nhanh chóng mà không có khả năng thu thập và chuyển hóa kinh nghiệm.
***
Tóm lại, tinh thần "Thua một trận không nghĩa là thua cuộc chiến" không phải là một lời mời gọi sự hỗn loạn, mà là một yêu cầu về sự kỷ luật cao nhất trong việc kiểm soát rủi ro.
Một doanh nghiệp muốn coi thất bại là tài sản phải xây dựng một hệ thống đủ vững chắc để biến sự mất mát thành dữ liệu, và dữ liệu đó thành hành động. Nếu không, chúng ta chỉ đang làm giàu thêm kinh nghiệm cho một ai đó khác, với chi phí do chính chúng ta chi trả.
Bản chất của câu nói không phải là về sự thất bại, mà là về tốc độ phục hồi và tính hiệu quả của việc học hỏi – đó mới là cuộc chiến thực sự của người điều hành.
