Chuyển đổi số thất bại chủ yếu vì những lý do không nằm ở công nghệ: mục tiêu kinh doanh mơ hồ, lãnh đạo giao khoán cho bộ phận kỹ thuật, quy trình không được thiết kế lại, dữ liệu nền kém chất lượng, người dùng không được thuyết phục và dự án quá lớn để sửa sai kịp. Lỗi phần mềm thuần tuý hiếm khi là nguyên nhân chính.
Còn con số "70% dự án chuyển đổi số thất bại" được trích dẫn khắp nơi thì nên đọc dè dặt. Nó có thật trong một số khảo sát của các hãng tư vấn, nhưng định nghĩa "thất bại" mỗi nơi một kiểu, mẫu khảo sát là tự báo cáo, và con số 70% đã lưu hành trong văn liệu quản trị thay đổi từ trước khi có chữ chuyển đổi số. Hiểu nguồn gốc con số giúp bạn dùng nó đúng chỗ, và quan trọng hơn là tập trung vào những cơ chế thất bại có bằng chứng.
Con số 70% đến từ đâu và nên tin đến mức nào
Tỷ lệ "khoảng 70% sáng kiến thay đổi thất bại" xuất hiện trong văn liệu quản trị ít nhất từ thập niên 1990. Hammer và Champy, khi viết về tái lập quy trình năm 1993, ước đoán phần lớn nỗ lực tái lập không đạt kết quả mong muốn, và sau này chính Hammer nói rằng ước đoán đó bị trích dẫn quá đà. Năm 1995, John Kotter đăng bài "Leading Change: Why Transformation Efforts Fail" trên Harvard Business Review, mô tả các sai lầm phổ biến từ quan sát của ông, không phải từ một thống kê tỷ lệ chặt chẽ.
Năm 2011, Mark Hughes công bố bài phân tích trên Journal of Change Management truy lại các nguồn thường được dẫn cho con số 70%, và kết luận rằng không có bằng chứng thực nghiệm hợp lệ nào cho một tỷ lệ thất bại phổ quát như vậy. Sau đó, khi "chuyển đổi số" thành chủ đề nóng, nhiều khảo sát của các hãng tư vấn lớn lại đưa ra con số tương tự, thường ở dạng "chưa đến một phần ba các nỗ lực chuyển đổi đạt được mục tiêu đã đặt ra".
Cách đọc hợp lý: các khảo sát này cho thấy tỷ lệ dự án không đạt đủ mục tiêu ban đầu là cao, điều đó khá nhất quán. Nhưng "không đạt đủ mục tiêu" khác xa "thất bại", và người trả lời khảo sát là lãnh đạo doanh nghiệp tự đánh giá. Đừng dùng con số này để dọa hội đồng quản trị, cũng đừng dùng nó để biện minh rằng thất bại là bình thường. Dùng nó như một lời nhắc rằng khoảng cách giữa kế hoạch và kết quả thường lớn, nên phải thiết kế dự án để phát hiện sớm khoảng cách đó.
Sáu nguyên nhân thất bại lặp lại nhiều nhất
1. Mục tiêu là công nghệ, không phải kết quả kinh doanh. Dự án được định nghĩa bằng "triển khai hệ thống X trong 12 tháng" thay vì "giảm thời gian giao hàng từ năm ngày xuống hai ngày". Khi mục tiêu là công nghệ, dự án có thể đúng hạn, đúng ngân sách mà vẫn không tạo ra giá trị, và không ai nhận ra cho tới khi đã tiêu hết tiền.
2. Lãnh đạo tài trợ nhưng không tham gia. Ban giám đốc ký quyết định rồi giao cho phòng công nghệ. Những quyết định khó, như bỏ một quy trình mà một trưởng phòng đã xây mười năm, hay chuẩn hoá giá giữa các chi nhánh, không ai đủ quyền chốt nên bị né, và hệ thống mới phải "chiều" theo mọi ngoại lệ cũ.
3. Tự động hoá quy trình cũ. Đúng điều Hammer cảnh báo từ 1990: đưa nguyên quy trình giấy lên hệ thống, kể cả các bước duyệt thừa, chỉ khiến cái chậm trở nên chậm một cách có hệ thống. Nhiều dự án còn tốn thêm chi phí tuỳ biến phần mềm để giữ đúng thói quen cũ.
4. Dữ liệu nền bị đánh giá thấp. Mã hàng trùng, khách hàng ghi ba tên khác nhau, tồn kho trên sổ lệch thực tế. Hệ thống mới chạy trên dữ liệu đó cho ra báo cáo sai, người dùng mất niềm tin và quay về bảng tính riêng. Làm sạch dữ liệu thường tốn thời gian hơn dự tính ban đầu nhiều lần.
5. Người dùng là đối tượng bị triển khai, không phải người tham gia. Nhân viên tuyến đầu chỉ được gọi vào ở khâu đào tạo cuối cùng. Họ thấy hệ thống thêm việc cho mình mà không thấy lợi ích, nên dùng đối phó, nhập liệu cho xong, làm dữ liệu càng xấu thêm.
6. Dự án quá lớn để sửa sai. Kế hoạch "big bang" thay toàn bộ hệ thống trong một lần chuyển giao dồn hết rủi ro vào một ngày. Nếu có vấn đề, tổ chức không còn đường lùi. Các dự án chia nhỏ, có kết quả đo được sau mỗi vài tháng, cho phép phát hiện giả định sai khi chi phí sửa còn thấp.
Những vụ thất bại kinh điển và bài học
Lịch sử hệ thống doanh nghiệp có vài trường hợp được giảng dạy nhiều ở các trường kinh doanh. Chi tiết số liệu khác nhau tùy nguồn, nhưng cơ chế thất bại thì nhất quán:
- Một nhà phân phối dược phẩm lớn ở Mỹ giữa thập niên 1990 (FoxMeyer) triển khai đồng thời hệ thống quản trị doanh nghiệp mới và kho tự động hoá, kỳ vọng tiết kiệm chi phí lớn. Hệ thống không xử lý kịp khối lượng đơn hàng, kho tự động gặp sự cố, công ty nộp đơn phá sản năm 1996. Bài học: ghép hai thay đổi rủi ro cao vào cùng một thời điểm và đặt cược vào dự báo tiết kiệm chưa kiểm chứng.
- Một hãng sản xuất bánh kẹo Mỹ năm 1999 (Hershey) chuyển giao cùng lúc ba hệ thống lớn, rút ngắn lịch triển khai và chọn thời điểm ngay trước mùa cao điểm Halloween. Đơn hàng không được xử lý và giao kịp dù kho vẫn đầy hàng, doanh thu quý bị ảnh hưởng đáng kể. Bài học: chọn thời điểm chuyển giao vào mùa thấp điểm, và không nén lịch kiểm thử để kịp một hạn chót do kinh doanh đặt ra.
- Nhiều dự án hệ thống khu vực công ở nhiều nước bị dừng sau khi tiêu tốn ngân sách lớn, thường vì phạm vi phình to liên tục, yêu cầu thay đổi theo chính sách, và hợp đồng giao trọn gói cho nhà thầu khiến bên đặt hàng mất năng lực tự đánh giá. Bài học: giữ năng lực kỹ thuật nòng cốt ở bên trong tổ chức, kể cả khi thuê ngoài phần lớn công việc.
Điểm chung của các trường hợp trên không phải phần mềm kém. Phần mềm trong các vụ này phần lớn là sản phẩm phổ biến, chạy tốt ở nơi khác. Thất bại nằm ở quyết định quản trị: phạm vi, thời điểm, mức độ thay đổi dồn vào một lần, và việc bỏ qua tín hiệu cảnh báo trong giai đoạn kiểm thử.
Cơ chế tâm lý và tổ chức phía sau
Vì sao những sai lầm đã được mô tả từ ba mươi năm trước vẫn lặp lại? Một phần lời giải nằm ở các thiên kiến đã được nghiên cứu kỹ. Ngụy biện kế hoạch (planning fallacy), được Daniel Kahneman và Amos Tversky mô tả từ cuối thập niên 1970, là xu hướng ước lượng thời gian và chi phí theo kịch bản thuận lợi nhất của chính dự án, bỏ qua tỷ lệ cơ sở của các dự án tương tự. Bent Flyvbjerg, qua nhiều nghiên cứu về dự án lớn, đề xuất kỹ thuật dự báo theo nhóm tham chiếu (reference class forecasting) để khắc phục: thay vì hỏi "dự án của mình cần bao lâu", hãy hỏi "các dự án giống thế này thường vượt bao nhiêu".
Leo thang cam kết (escalation of commitment), được Barry Staw nghiên cứu từ giữa thập niên 1970, giải thích vì sao dự án đang trượt vẫn được rót thêm tiền: người quyết định ban đầu khó thừa nhận sai, và chi phí đã bỏ ra trở thành lý do để tiếp tục. Trong dự án số, điều này biểu hiện ở việc "đã đi 80% rồi, cố nốt", trong khi 20% còn lại thường là phần khó nhất.
Ở cấp tổ chức, chuyển đổi số phân phối lại quyền lực. Dữ liệu minh bạch khiến những người trước đây nắm thông tin độc quyền, như trưởng kho biết chính xác hàng nào nằm ở đâu, hay nhân viên kinh doanh giữ quan hệ khách hàng trong điện thoại riêng, mất một phần vị thế. Kháng cự thay đổi trong trường hợp này không phải sự bảo thủ vô lý, mà là phản ứng hợp lý trước nguy cơ mất quyền. Dự án nào không tính đến lợi ích của những nhóm này sẽ gặp lực cản ngầm khó phát hiện.
Dấu hiệu cảnh báo sớm và cách phản ứng
Phần lớn dự án thất bại đều có dấu hiệu từ rất sớm, chỉ là không ai có động cơ nói ra. Bảng sau tổng hợp các tín hiệu thường gặp:
| Dấu hiệu | Thường có nghĩa là | Phản ứng nên có |
|---|---|---|
| Báo cáo tiến độ toàn màu xanh trong nhiều tháng | Đo tiến độ bằng công việc đã làm, không bằng kết quả đã kiểm chứng | Yêu cầu trình diễn chức năng chạy với dữ liệu thật thay cho báo cáo phần trăm |
| Danh sách yêu cầu tuỳ biến dài dần | Quy trình cũ chưa được thiết kế lại, hệ thống đang bị bẻ cho giống cách làm cũ | Đưa từng yêu cầu tuỳ biến lên cấp có quyền quyết định bỏ quy trình |
| Người dùng chủ chốt vắng mặt trong các buổi kiểm thử | Họ không được giải phóng khỏi việc thường ngày, hoặc không tin dự án | Bố trí người thay việc, gắn trách nhiệm kiểm thử vào mục tiêu cá nhân |
| Làm sạch dữ liệu bị đẩy về "giai đoạn sau" | Rủi ro lớn nhất đang bị hoãn | Làm thử chuyển đổi dữ liệu với một mẫu đủ lớn ngay từ đầu |
| Không ai nói được chỉ số kinh doanh nào sẽ đổi | Dự án là dự án công nghệ | Dừng lại định nghĩa thước đo trước khi chi tiếp |
Một kỹ thuật hữu ích là phân tích tiền thất bại (pre-mortem) do Gary Klein đề xuất: trước khi bắt đầu, nhóm dự án tưởng tượng rằng một năm sau dự án đã thất bại, rồi mỗi người viết ra lý do. Cách đặt vấn đề này giúp người trong nhóm nói ra lo ngại mà bình thường họ giữ lại để tránh bị coi là bi quan.
Thiết kế dự án để thất bại nhỏ, không thất bại lớn
Không thể loại bỏ hết rủi ro, nhưng có thể thiết kế để sai lầm lộ ra sớm, khi còn rẻ. Một trình tự thường được các nhóm có kinh nghiệm áp dụng:
- Viết mục tiêu bằng chỉ số kinh doanh có giá trị nền hiện tại, ví dụ "tỷ lệ đơn giao đúng hẹn từ mức hiện tại lên mức mục tiêu", và chỉ định một người trong ban lãnh đạo chịu trách nhiệm về chỉ số đó.
- Vẽ quy trình hiện tại và quy trình mục tiêu trước khi chọn phần mềm. Mỗi khác biệt giữa hai bản vẽ là một thay đổi cần người có quyền chấp thuận.
- Chọn một phạm vi thí điểm nhỏ nhưng thật: một chi nhánh, một dòng sản phẩm, một nhóm khách hàng. Chạy với dữ liệu thật và người dùng thật.
- Đặt điểm dừng định trước: sau thí điểm, nếu chỉ số không cải thiện ở mức tối thiểu đã thống nhất, dự án phải được xem xét lại thay vì tự động mở rộng.
- Mở rộng theo đợt, mỗi đợt có kiểm tra lại dữ liệu và đào tạo người dùng tại chỗ, tránh chuyển giao toàn bộ trong một ngày.
- Sau khi chạy ổn định, tiếp tục đo chỉ số kinh doanh ít nhất vài quý. Lợi ích thật thường đến chậm hơn ngày "go-live", và rủi ro quay về cách làm cũ cũng xuất hiện sau đó.
Trình tự này không mới; nó là tinh thần của quản lý dự án lặp và của thử nghiệm có kiểm soát. Cái khó không nằm ở kỹ thuật mà ở chỗ ban lãnh đạo phải chấp nhận nghe tin xấu sớm và chấp nhận dừng một dự án mình đã công bố.
Câu hỏi thường gặp
Có nên thuê đơn vị tư vấn để giảm rủi ro thất bại không?
Tư vấn hữu ích để mang vào kinh nghiệm từ nhiều dự án và phương pháp có cấu trúc. Rủi ro là tổ chức giao luôn phần tư duy cho họ và không xây được năng lực bên trong. Nên giữ quyền quyết định về quy trình và dữ liệu ở nội bộ, yêu cầu chuyển giao kiến thức thành điều khoản cụ thể, và tách đơn vị tư vấn với đơn vị bán phần mềm để tránh xung đột lợi ích.
Dự án chuyển đổi số nên kéo dài bao lâu là hợp lý?
Không có độ dài chuẩn. Kinh nghiệm chung là mỗi giai đoạn nên cho ra kết quả đo được trong khoảng ba đến sáu tháng. Dự án chỉ hứa hẹn giá trị sau hai năm mà không có cột mốc trung gian rất khó kiểm soát, vì môi trường kinh doanh, nhân sự và cả công nghệ đều có thể thay đổi trước khi dự án kịp xong.
Làm sao đo được dự án đã thất bại hay chỉ đang chậm?
So sánh chỉ số kinh doanh mục tiêu với giá trị nền, không so tiến độ công việc với kế hoạch. Nếu sau thí điểm chỉ số không nhích, cần tách ba khả năng: giả định kinh doanh sai, triển khai chưa đúng, hoặc người dùng chưa dùng thật. Mỗi khả năng có cách xử lý khác nhau, và chỉ khả năng thứ nhất mới là lý do dừng hẳn.
Văn hoá doanh nghiệp Việt Nam có làm chuyển đổi số khó hơn không?
Một số đặc điểm thường được nhắc tới, như ra quyết định tập trung ở người đứng đầu hay ngại báo tin xấu lên cấp trên, có thể làm chậm việc phát hiện vấn đề. Nhưng chưa có bằng chứng đủ mạnh để nói đây là yếu tố riêng của Việt Nam; các đặc điểm tương tự xuất hiện ở doanh nghiệp gia đình nhiều nơi. Quy mô, cơ cấu sở hữu và năng lực quản trị giải thích được nhiều hơn.
Thất bại của dự án số có phải luôn là điều xấu không?
Thất bại sớm, rẻ và có bài học, ví dụ một thí điểm cho thấy giả định về hành vi khách hàng là sai, là kết quả có giá trị. Điều nguy hiểm là thất bại muộn và lớn, khi phần lớn ngân sách đã chi và tổ chức đã thay đổi quy trình. Mục tiêu quản trị không phải tránh mọi thất bại mà là dịch chuyển thất bại về phía sớm và nhỏ.
Có nên công bố dự án chuyển đổi số rộng rãi trong công ty ngay từ đầu không?
Công bố giúp tạo cam kết và kêu gọi người tham gia, nhưng cũng làm tăng áp lực không được dừng, đúng cơ chế leo thang cam kết. Cách cân bằng là công bố mục tiêu kinh doanh và cách tiếp cận thử nghiệm, nói rõ có điểm dừng định trước, thay vì công bố một hệ thống cụ thể với ngày hoàn thành cố định.
