Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Truy ngược con số tỷ lệ thất bại dự án ERP đang lưu hành, xem nó thật ra đo cái gì và đường trích dẫn đứt ở đâu, rồi thay bằng bốn dạng hỏng có dấu hiệu sớm quan sát được.
Slide thứ hai của một bản đề xuất triển khai thường có một dòng nói rằng phần lớn dự án ERP thất bại, kèm một con số tròn trịa mà cả phòng gật đầu, vì nó nghe quen tới mức không ai hỏi lại.
Cho tới hôm một giám đốc hỏi đúng hai câu ngắn: con số này của ai, và trong con số này thì thất bại nghĩa là gì.
Người trình bày không trả lời được câu nào, và chuyện đó bình thường, bởi con số ấy đã được chép qua nhiều tầng tới mức người dùng nó không còn biết nguồn gốc. Tôi mang hai câu hỏi ấy đi tra ngược, và dưới đây là những gì tra được, kể cả những chỗ tra không tới nơi.
Càng đi sang phía tiếng Anh thì con số càng cụ thể, nhưng nguồn thì không rõ hơn bao nhiêu.
Ở phía tiếng Việt, một trang tư vấn triển khai của nhà cung cấp trong nước đặt thẳng bảy mươi phần trăm dự án gặp khó khăn vào tiêu đề, nhưng không có dòng nào dẫn nguồn cho chính con số đó. Thân bài có nhắc Panorama Consulting Group kèm cụm báo cáo thường niên và nhắc Gartner, song cả hai chỗ đều chỉ nói về đa số nói chung.
Ở phía tiếng Anh, một trang tổng hợp của nhà tích hợp hệ thống nêu tỷ lệ thất bại toàn ngành và mức vượt ngân sách rất cụ thể cho năm 2026. Lần đầu tôi đọc, trang quy các con số ấy về báo cáo ERP năm 2026 của Panorama Consulting Group; khoảng hai tháng sau, trang đã được sửa và các con số thành phân tích riêng của chính họ, không mô tả phương pháp. Gartner, Industry Week và Deloitte vẫn nằm ở mục nguồn mà không gắn với số nào.
Tới nhà phát hành thì trang giới thiệu báo cáo năm 2026 của Panorama không hiển thị con số nào, còn bản đầy đủ nằm sau trang đăng ký. Thông cáo phát hành báo cáo ấy, đề ngày 4 tháng Ba năm 2026, chỉ nói bằng lời rằng hơn một phần tư tổ chức vượt ngân sách dự án, và không nêu tỷ lệ thất bại nào.
May là trang lưu trữ của Panorama cho tải trực tiếp các bản cũ, và hai bản gần nhất kể một câu chuyện khác hẳn.
Bản The 2025 ERP Report khảo sát một trăm bảy mươi hai tổ chức trả lời, từ tháng Một năm 2024 tới tháng Một năm 2025. Báo cáo không đưa ra tỷ lệ thất bại tổng và không định nghĩa thất bại, mà đo ba thứ tách rời là bám ngân sách, bám tiến độ và mức đạt được của từng nhóm lợi ích kỳ vọng. Nói đúng như báo cáo nói thì hơn một nửa số tổ chức nằm trong ngân sách dự kiến, và hơn ba phần tư hoàn thành đúng tiến độ dự kiến.
Bản The 2024 ERP Report khảo sát một trăm ba mươi mốt tổ chức trả lời, từ tháng Tám năm 2022 tới tháng Mười Hai năm 2023, cũng không có tỷ lệ thất bại tổng, cũng không định nghĩa thất bại, và cũng ghi rằng hơn một nửa nằm trong ngân sách lẫn tiến độ dự kiến.
Đây là chỗ nên đọc chậm. Hai bản gần nhất của chính tổ chức đang bị trích dẫn nhiều nhất không chứa tỷ lệ thất bại nào, và phần về ngân sách với tiến độ lại đi ngược bức tranh mà các trang trích lại đang vẽ. Tuy nhiên tôi không kết luận rằng con số kia không có trong bản 2026, bởi tôi chưa đọc được bản đó.
Trong các con số bảy mươi phần trăm về ERP, cái duy nhất tôi lần được tới một nguồn có tên lại không nằm ở Panorama mà ở Gartner, và nó là một dự báo chứ không phải một số đo.
Trang giới thiệu nghiên cứu của Gartner viết rằng tới năm 2027, hơn bảy mươi phần trăm các sáng kiến ERP mới triển khai gần đây sẽ không đạt trọn vẹn các mục tiêu kinh doanh ban đầu.
Báo chí công nghệ dẫn lại dự báo này ít nhất từ tháng Bảy năm 2025, kèm vế có tới một phần tư sẽ thất bại nặng nề, và một chuyên gia của Gartner nhắc lại cả hai con số tại hội nghị Gartner Symposium ở Barcelona tháng Mười Một năm 2025. Bản đầy đủ nằm sau biểu mẫu đăng ký, nên phương pháp đằng sau dự báo tôi không đọc được.
Đặt câu gốc cạnh dòng trên slide thì thấy ba chỗ lệch:
Ngoài ra, con số bảy mươi phần trăm còn có đời sống riêng ở mảng quản trị thay đổi, từ ước tính năm mươi tới bảy mươi phần trăm nỗ lực tái cấu trúc quy trình không đạt kết quả, mà chính hai tác giả cuốn Reengineering the Corporation năm 1993 gọi là không khoa học, tới những câu bảy mươi phần trăm chương trình chuyển đổi không đạt mục tiêu thường được gắn tên McKinsey, và một bài rà soát trên Journal of Change Management năm 2011 đã lần lại các nguồn ấy mà không tìm thấy cơ sở thực nghiệm hợp lệ nào.
Do đó khi một trang về ERP đặt con số này lên tiêu đề, bạn nên kiểm xem nó đang mượn con số của ERP hay của chuyển đổi nói chung.
Có bốn chỗ tôi không đi tiếp được, và chúng đáng được ghi ra.
Cần lưu ý rằng chính trang tư vấn Mỹ nói trên lại đưa ra một thứ giá trị hơn con số của họ, là cách họ mô tả thất bại:
Cùng một chữ thất bại, nhưng mỗi nguồn đo một thứ khác, và chọn nghĩa nào thì ra con số ấy.
Nghĩa thứ nhất là vượt ngân sách, và nó phụ thuộc hoàn toàn vào mốc được lấy làm gốc, bởi một dự án ký nhiều phụ lục thay đổi trong lúc chạy sẽ vượt xa con số ban đầu nhưng vẫn bám sát con số đã điều chỉnh, tức là chọn mốc nào thì có kết luận ấy.
Nghĩa thứ hai là trễ tiến độ, thứ dễ đo nhất và cũng dễ làm đẹp nhất, bởi một dự án cắt bớt phạm vi để kịp ngày vẫn được ghi là đúng hạn.
Nghĩa thứ ba là không đạt lợi ích kỳ vọng, nghĩa nghiêm túc nhất về mặt nghiệp vụ nhưng mềm nhất về mặt đo đạc, vì lợi ích kỳ vọng do chính tổ chức tự đặt ra lúc đầu rồi tự chấm lúc sau; dự báo của Gartner ở trên dùng đúng nghĩa này.
Nghĩa thứ tư là bị bỏ giữa chừng, nghĩa hẹp nhất và hiếm nhất, nên bất kỳ con số lớn nào cũng gần như chắc chắn không dùng nghĩa này.
Ngoài bốn nghĩa đó còn một lớp hay bị bỏ qua, là ai được hỏi, bởi các khảo sát kiểu này thu câu trả lời từ những tổ chức tự nguyện điền biểu mẫu của một công ty tư vấn chứ không phải từ một mẫu ngẫu nhiên.
Do đó khi ai đó đưa cho bạn một tỷ lệ thất bại mà không kèm định nghĩa và cỡ mẫu, thứ bạn nhận được là một cảm giác chứ không phải một số đo.
Vì vậy khi con số ấy xuất hiện trong một cuộc họp, cách tôi vẫn làm gồm hai bước. Đầu tiên là hỏi lại định nghĩa bằng một câu trung tính, dạng một dự án chậm hai tháng nhưng chạy tốt thì được xếp vào nhóm nào. Sau đó là đổi câu hỏi từ tỷ lệ sang danh sách, tức là hỏi dự án này có thể hỏng theo những cách nào và dấu hiệu sớm nhất của mỗi cách là gì.
Câu trả lời cho câu hỏi sau ghi thẳng vào biên bản họp được, còn một tỷ lệ thì không.
Phần dưới không phải thống kê, và tôi cũng không xếp hạng bốn dạng này vì không có dữ liệu để xếp; mỗi dạng đều có hồ sơ công khai đủ để dẫn, kèm dấu hiệu quan sát được trước khi hậu quả xuất hiện.
Dạng thứ nhất là go-live theo ngày đã hứa trong khi danh sách vướng mắc vẫn mở. Với hệ thống tài chính của một hội đồng thành phố ở Anh, go-live năm 2022, kiểm toán viên độc lập ghi rằng quyết định go-live được đưa ra khi những rủi ro chương trình đã biết chưa được xử lý thỏa đáng, kiểm thử chưa đạt, nhân viên đã lên tiếng lo ngại về độ ổn định, và trong đội có tâm lý ngại phản biện.
Trong một vụ kiện giữa hãng thiết bị y tế và hãng tư vấn triển khai, đơn kiện gọi lần go-live là thiếu cân nhắc, và kể rằng các trục trặc ban đầu được bên tư vấn coi là vấp váp thường gặp của giai đoạn chuyển đổi; đây là cáo buộc của một bên, bên kia đang phản bác tại tòa.
Dấu hiệu sớm nằm ở tương quan giữa hai đường, tức số vướng mắc mở không giảm trong khi ngày go-live không đổi, và một dấu hiệu đến sớm hơn nữa là người báo động bắt đầu bị nhìn như người tiêu cực. Bộ tiêu chí có ngưỡng để quyết định go hay không go thì đã có bài riêng.
Dạng thứ hai là đứng nửa vời giữa chuẩn của sản phẩm và đặc thù của doanh nghiệp.
Trên một diễn đàn kỹ thuật, một người từng triển khai ở doanh nghiệp rất lớn nói rằng tổ chức chỉ có hai lựa chọn sống được, hoặc quy trình cực chắc rồi ép phần mềm theo, hoặc chấp nhận hoàn toàn mặc định của sản phẩm, còn đứng giữa là chết.
Hội đồng thành phố nói trên đặt ra nguyên tắc theo chuẩn của sản phẩm, rồi không giữ được nó và dựng thêm phần mềm riêng quanh hệ thống, và hóa đơn của lựa chọn ấy thành tin tức nhiều năm liền. Dấu hiệu sớm nằm ngay trên tài liệu của bạn, là số dòng trong bảng GAP có hướng xử lý viết thêm mã tăng dần qua từng buổi họp. Ranh giới giữa cấu hình và customize, cùng chi phí mang vác về sau, đã có bài riêng.
Dạng thứ ba là dự án đẹp trên giấy. Một bài phân tích về nghề tư vấn triển khai hệ thống lớn mô tả trạng thái mọi tài liệu đều xong, mọi kịch bản kiểm thử đều pass, nhưng doanh nghiệp không vận hành được. Nguyên nhân theo bài phân tích đó là các chốt chất lượng kiểm tra sự đầy đủ của tài liệu chứ không kiểm tra mức liên quan tới nghiệp vụ, còn các chỉ số dùng để báo cáo, chẳng hạn tỷ lệ đóng lỗi, đều dễ làm đẹp.
Dấu hiệu sớm là một câu bạn tự hỏi cuối mỗi giai đoạn: đã có ai chạy trọn một chu trình từ đầu tới cuối bằng dữ liệu thật của khách chưa.
Dạng thứ tư là chết dần sau go-live, dạng không lên báo, và cũng là dạng tôi tin là phổ biến nhất ở quy mô vừa và nhỏ, dù đây là niềm tin nghề chứ không phải kết luận có dữ liệu.
Hệ thống vẫn chạy, không ai tuyên bố dự án hỏng, nhưng người dùng lặng lẽ quay về bảng tính, master data hỏng dần, và tới lúc ban lãnh đạo mở báo cáo thì các con số không khớp thực tế. Một người triển khai trên diễn đàn kỹ thuật mô tả đúng cơ chế giữ cho chuyện này im lặng, rằng người dùng cuối chịu đựng bất tiện hằng ngày mà không có đường nào để nỗi đau đó đi lên tới cấp quyết định.
Dấu hiệu sớm đo bằng dữ liệu chứ không bằng cảm nhận, gồm số chứng từ tạo trên hệ thống mỗi tuần không tăng sau tháng đầu, và một bộ phận vẫn giữ file riêng sau vài tháng. Nhịp làm việc của hai tuần đầu sau go-live thì đã có bài riêng.
Đây là bản rà nửa giờ mà bạn dùng được ngay cho một dự án đang chạy.
Tôi không đưa ra tỷ lệ thất bại thật của ngành, bởi tôi không có tập dữ liệu nào để làm việc đó.
Bài này cũng không nói rằng các con số đang lưu hành là bịa, mà nói một điều hẹp hơn.
Ở bài về chi phí dự án tôi cũng không đưa con số, nhưng lý do bên đó thuộc về nguồn giá chứ không thuộc về định nghĩa.
Bốn dạng hỏng ở trên dựng từ hồ sơ công khai và từ những gì quan sát được khi đi dự án, chưa có hồ sơ dự án hỏng nào của riêng tôi, nên hãy đọc chúng như một khung để tự soi dự án mình. Phần lớn các nguồn trong bài tôi đọc lại lần cuối vào cuối tháng Mười năm 2026, và vì trang thứ cấp có thể sửa nội dung bất cứ lúc nào, như trang tổng hợp ở đầu bài, bạn nên tự mở lại trước khi trích dẫn.
Ở cả bốn dạng, người nhìn thấy sớm nhất thường là người ít thâm niên nhất trong đội, nên chuyện đáng nói tiếp theo là những sai lầm mà một BA ERP mới vào nghề hay mắc, và vì sao phần lớn chúng không phải lỗi chuyên môn.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận