---
title: "Vì sao dự án ERP thất bại: con số 70% đó từ đâu ra"
url: "https://bahub.vn/khoa-hoc/erp-cho-ba/vi-sao-du-an-erp-that-bai-con-so-70-phan-tram"
author: "Võ Văn Trí"
published: "2026-09-10"
updated: "2026-11-02"
source: "bahub.vn"
license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc."
---

# Vì sao dự án ERP thất bại: con số 70% đó từ đâu ra

> 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.

- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/vi-sao-du-an-erp-that-bai-con-so-70-phan-tram
- Tác giả: Võ Văn Trí
- Khoá học: ERP cho Business Analyst (mục lục: https://bahub.vn/khoa-hoc/erp-cho-ba.md)
- Chương: Tổng kết nghề

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.

## Đường đi ngược của con số

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**.

## Hai bản báo cáo đọc được và điều chúng thực sự nói

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 đó.

![Hai bản báo cáo đọc được không hề chứa một tỷ lệ thất bại nào](https://bahub.vn/uploads/2026/11/1793631600862-jlkzlf-vi-sao-du-an-erp-that-bai-con-so-70-phan-tram-1.webp "Hai bản báo cáo đọc được không hề chứa một tỷ lệ thất bại nào")

## Con số bảy mươi phần trăm có tên chủ

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:

* câu gốc là dự báo, còn slide nói như một tỷ lệ đã đo
* câu gốc dùng nghĩa hẹp và mềm, là chưa đạt trọn vẹn mục tiêu trong business case, còn slide để người nghe tự hiểu là dự án hỏng
* và câu gốc có vế riêng cho nhóm thất bại nặng nề, nhỏ hơn rất nhiều

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**.

## Chỗ việc truy nguồn dừng lại

Có bốn chỗ tôi không đi tiếp được, và chúng đáng được ghi ra.

* **Thứ nhất**, bản báo cáo năm 2026 của Panorama nằm sau trang đăng ký nên tôi không lấy được tệp.
* **Thứ hai**, trong hai trang tiếng Anh viết riêng về con số bảy mươi phần trăm, một trang tôi không mở được, còn trang kia gắn con số ở tiêu đề cho McKinsey và cho chuyển đổi số nói chung chứ không riêng ERP, không kèm tên báo cáo hay năm.
* **Thứ ba**, một trang tư vấn của Mỹ nêu dải từ năm mươi lăm tới bảy mươi lăm phần trăm dự án ERP không đạt mục tiêu và quy cho Gartner, nhưng không có tên báo cáo, không có năm phát hành, nên tôi không đối chiếu được với tài liệu gốc và không đưa nó vào bài như một sự thật.
* **Thứ tư**, các diễn đàn thảo luận lớn nhất về chủ đề này tôi không truy cập được, nên phần tiếng nói người trong nghề ở dưới lấy từ nơi khác.

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:

* bị bỏ dở
* lệch phạm vi
* vượt ngân sách
* kéo dài tiến độ
* và không đạt lợi ích kỳ vọng

## Bốn nghĩa khác nhau của chữ 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.

![Cùng chữ thất bại, mỗi nguồn đo một thứ khác nên ra con số khác](https://bahub.vn/uploads/2026/11/1793631605817-5hqrxb-vi-sao-du-an-erp-that-bai-con-so-70-phan-tram-2.webp "Cùng chữ thất bại, mỗi nguồn đo một thứ khác nên ra con số khác")

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.

## Bốn dạng hỏng quan sát được và dấu hiệu sớm của chú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](https://bahub.vn/khoa-hoc/erp-cho-ba/checklist-go-live-erp) 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](https://bahub.vn/khoa-hoc/erp-cho-ba/cau-hinh-hay-customize-erp), cùng [chi phí mang vác về sau](https://bahub.vn/khoa-hoc/erp-cho-ba/no-ky-thuat-cua-customization), đã có bài riêng.

![Dấu hiệu sớm: vướng mắc mở không giảm trong khi ngày go-live vẫn đứng yên](https://bahub.vn/uploads/2026/11/1793631606818-6xct3b-vi-sao-du-an-erp-that-bai-con-so-70-phan-tram-3.webp "Dấu hiệu sớm: vướng mắc mở không giảm trong khi ngày go-live vẫn đứng yên")

**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](https://bahub.vn/khoa-hoc/erp-cho-ba/hai-tuan-dau-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.

* Đếm số vướng mắc đang mở tuần này và so với ba tuần trước
* Đối chiếu ngày go-live cam kết với xu hướng của con số vừa đếm
* Đếm số dòng viết thêm mã trong bảng GAP, so bản đầu với bản mới nhất
* Chọn một chu trình nghiệp vụ và hỏi ai đã chạy trọn nó bằng dữ liệu thật
* Hỏi mỗi bộ phận còn giữ file riêng nào ngoài hệ thống
* Ghi tên người nhận mỗi rủi ro vừa phát hiện, kèm một hạn

## Giới hạn của bài nà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.

* Con số bảy mươi phần trăm có nguồn là một dự báo của Gartner, dùng một nghĩa hẹp của thất bại
* hai bản Panorama đọc được không chứa tỷ lệ thất bại nào
* còn phần đông các trang trích lại không nêu tên báo cáo, năm hay tiêu chí

Ở bài về [chi phí dự án](https://bahub.vn/khoa-hoc/erp-cho-ba/chi-phi-that-cua-mot-du-an-erp) 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.

---

Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/vi-sao-du-an-erp-that-bai-con-so-70-phan-tram — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.