Người ta không ghét công nghệ mới. Người ta ghét cảm giác bị loại bỏ khỏi những quyết định ảnh hưởng trực tiếp đến công việc của họ.
Đó là bài học cốt lõi từ hàng chục dự án ERP thất bại được ghi chép lại trong 30 năm qua. Phần mềm hiếm khi là nguyên nhân. Phần mềm chỉ là nơi mà sự thất bại được nhìn thấy — còn nguyên nhân thực sự thường ẩn sâu hơn, trong phòng họp, trong bữa trưa, trong những cuộc trò chuyện không chính thức mà nhân viên thì thầm với nhau: “Cái hệ thống này không hiểu chúng ta làm gì.”
Đây là bốn câu chuyện thực tế — mỗi câu chuyện là một hình dạng khác nhau của cùng một hiện tượng: kháng cự thay đổi trong quá trình chuyển đổi số.
Câu chuyện 1 — Hershey’s: Kẹo sô cô la chất đống, không ai biết giao cho ai
Bối cảnh
Năm 1996, Hershey’s — hãng kẹo sô cô la lớn nhất nước Mỹ — quyết định thay thế toàn bộ hệ thống IT cũ bằng một nền tảng ERP mới tích hợp từ ba nhà cung cấp: SAP, Manugistics, và Siebel. Dự án được lên kế hoạch trong 48 tháng.
Rồi ban lãnh đạo quyết định rút ngắn xuống còn 30 tháng — vì muốn hệ thống sẵn sàng trước mùa bán hàng quan trọng nhất năm: Halloween và Giáng sinh.
Điều xảy ra
Tháng 7/1999, Hershey’s nhấn nút go-live. Ngay lập tức, mọi thứ sụp đổ.
Các đơn hàng tồn đọng. Hệ thống xử lý chậm đến mức đơn hàng mất nhiều ngày để được xác nhận, trong khi trước đó chỉ mất vài giờ. Kho hàng chất đầy kẹo — nhưng nhân viên không thể biết đơn hàng nào cần giao đi đâu, vì dữ liệu trong hệ thống không khớp với thực tế. Nhân viên, vốn chưa được đào tạo đầy đủ trong cái timeline bị nén đó, đứng trước màn hình và không biết phải làm gì.
Người mua lẻ — Walmart, Target, CVS — đặt hàng candy Halloween nhưng không nhận được. Hershey’s mất thị phần vào đúng thời điểm quan trọng nhất năm.
Thiệt hại
- Lợi nhuận quý giảm 19%
- Doanh số bán hàng giảm 12% so với cùng kỳ năm trước
- Cổ phiếu Hershey’s mất giá đáng kể
- Danh tiếng với các nhà bán lẻ bị tổn hại lâu dài
Bài học thực sự
Phần mềm không lỗi. Timeline mới là vấn đề — và sau timeline là một quyết định của ban lãnh đạo: ưu tiên ngày go-live hơn ưu tiên con người sẵn sàng. Nhân viên chưa hiểu hệ thống mới, chưa được luyện tập với dữ liệu thực, chưa có phản xạ xử lý tình huống bất thường — và khi mùa cao điểm ập đến, sự thiếu chuẩn bị đó biến thành thảm họa vận hành.
Kháng cự không phải lúc nào cũng là hành động có chủ ý. Đôi khi nó chỉ là: nhân viên không đủ tự tin để dùng hệ thống mới đúng cách — và không dám nói ra điều đó.
Câu chuyện 2 — Nestlé USA: 29 vương quốc và cuộc “nổi dậy” thầm lặng
Bối cảnh
Cuối thập niên 1990, Nestlé USA quyết định hợp nhất 29 bộ phận kinh doanh — mỗi bộ phận đang tự vận hành với quy trình và phần mềm riêng — vào một hệ thống SAP thống nhất. Ngân sách ban đầu: 210 triệu đô la. Timeline: 2 năm.
Đây là một trong những dự án ERP tham vọng nhất trong lịch sử doanh nghiệp Mỹ thời điểm đó. Và nó gần như thất bại hoàn toàn.
Điều xảy ra
Khi đội ngũ tư vấn và IT thiết kế quy trình mới trên SAP, họ làm việc chủ yếu với ban lãnh đạo cấp cao. Nhân viên nghiệp vụ — những người thực sự hiểu công việc hàng ngày — không được mời tham gia.
Kết quả: hệ thống mới được xây dựng dựa trên lý thuyết của các chuyên gia tư vấn, không phải trên thực tế vận hành. Khi triển khai đến các chi nhánh, nhân viên phát hiện rằng quy trình mới không phản ánh cách họ thực sự làm việc — và cũng không ai hỏi họ để điều chỉnh.
Phản ứng: nổi dậy thầm lặng. Không phải biểu ngữ hay đình công. Mà là những người từ chối sử dụng hệ thống đúng cách, những người tiếp tục dùng quy trình cũ song song, những người nhập dữ liệu sai vì họ không hiểu tại sao phải nhập theo cách mới. Toàn bộ dự án rơi vào hỗn loạn.
Thiệt hại
- Chi phí thực tế: hơn 500 triệu đô la — gần gấp 2,5 lần ngân sách ban đầu
- Thời gian thực tế: gần 5 năm — hơn gấp đôi so với kế hoạch
- Phải dừng lại giữa chừng, thiết kế lại toàn bộ cách tiếp cận, và lần này đưa nhân viên vào quá trình
Điều Nestlé làm khác ở lần thứ hai
Họ thành lập các nhóm làm việc có sự tham gia của nhân viên nghiệp vụ ở từng bộ phận. Thay vì áp đặt quy trình từ trên xuống, họ cùng thiết kế lại quy trình với những người trực tiếp thực hiện nó. Kết quả: sự kháng cự giảm đáng kể, và hệ thống cuối cùng đã hoạt động.
Bài học: Bạn không thể thiết kế một hệ thống cho con người mà không có con người trong phòng khi thiết kế. Những người bị bỏ qua sẽ tìm cách bỏ qua hệ thống.
Câu chuyện 3 — Target Canada: Khi 70% dữ liệu là dữ liệu sai
Bối cảnh
Năm 2011, Target mở rộng sang Canada — lần đầu tiên ra ngoài lãnh thổ Mỹ. Họ triển khai hệ thống SAP cho 133 cửa hàng mới cùng một lúc, không qua giai đoạn thử nghiệm hay rollout từng bước.
Điều xảy ra
Để hệ thống chạy được, một khối lượng khổng lồ dữ liệu sản phẩm cần được nhập vào SAP — mã hàng, kích thước, đơn vị đo lường, giá nhập, nhà cung cấp… Công việc này được giao cho một đội ngũ nhân viên được tuyển vội, đào tạo sơ sài, và phải nhập hàng triệu dòng dữ liệu trong thời gian ngắn.
Kết quả kiểm toán sau đó cho thấy: 70% dữ liệu trong hệ thống SAP chứa lỗi. Không phải vì nhân viên cố tình phá hoại — mà vì họ không được đào tạo đủ để biết đơn vị đo nào đúng, trường dữ liệu nào bắt buộc, tại sao con số này quan trọng.
Hệ thống cung ứng sụp đổ: hàng hóa không đến đúng cửa hàng, kệ hàng trống trong khi kho đầy, nhà cung cấp không thanh toán đúng vì hóa đơn sai. Khách hàng Canada đến Target và thấy kệ trống. Rồi họ không quay lại.
Thiệt hại
- Năm 2015, Target đóng cửa toàn bộ 133 cửa hàng tại Canada
- Khoản lỗ: hơn 2 tỷ đô la
- Hơn 17.600 nhân viên Canada mất việc
Bài học: Dữ liệu sai còn nguy hiểm hơn không có dữ liệu. Một hệ thống ERP chạy trên 70% dữ liệu sai không phải là hệ thống — đó là bẫy tốc độ cao.
Câu chuyện 4 — Bệnh viện ẩn danh: Hệ thống bị bỏ hoang sau một năm
Bối cảnh
Một tổ chức y tế lớn quyết định triển khai ERP mới để số hóa quy trình quản lý bệnh nhân, lên lịch ca trực, và hành chính viện phí. Dự án được lên kế hoạch kỹ lưỡng từ phía IT và ban lãnh đạo.
Nhưng một nhóm quan trọng không được hỏi ý kiến: y tá và nhân viên hành chính — những người sẽ dùng hệ thống này 8–12 giờ mỗi ngày.
Điều xảy ra
Sau go-live, phản hồi từ người dùng thực tế rất rõ ràng: hệ thống cồng kềnh, nhiều bước nhập liệu không cần thiết, giao diện không phù hợp với quy trình thực tế của bệnh viện. Nhưng thay vì lắng nghe, ban lãnh đạo chọn cách đổ lỗi cho người dùng — “họ không chịu học”.
Phản ứng tất nhiên là: shadow systems trỗi dậy. Y tá ghi chú trên giấy rồi nhập vào hệ thống cũ. Nhân viên hành chính duy trì bảng Excel riêng. Lịch ca trực vẫn được quản lý bằng file Word cá nhân. Hệ thống ERP chính thức vẫn chạy — nhưng chỉ để đối phó với các cuộc kiểm tra, không phải để thực sự làm việc.
Sau chưa đầy một năm, tổ chức đó bỏ hệ thống. Chi phí: hàng triệu đô la đầu tư và mất niềm tin nội bộ vào mọi dự án công nghệ tiếp theo.
Bài học: Khi người dùng nói “hệ thống không phù hợp” mà lãnh đạo nghe thành “người dùng không chịu thích nghi” — thì đó là lúc thất bại đã được quyết định, dù hệ thống chưa chính thức sập.
Hiện tượng: “Shadow Excel” — Chiếc file bí mật trong ngăn kéo
Trong tất cả các hình thức kháng cự thay đổi, shadow system — hệ thống bóng tối — là phổ biến và nguy hiểm nhất, vì nó vô hình.
Bạn đã đầu tư vào ERP. Hệ thống đang chạy. Dashboard hiển thị dữ liệu. Mọi thứ trông ổn. Nhưng nếu quan sát kỹ, bạn sẽ thấy:
- Trưởng kho vẫn tin con số trong file Excel riêng của anh ấy hơn con số ERP — vì anh ấy là người nhập file đó
- Nhân viên lập kế hoạch sản xuất có một workbook cá nhân để xử lý các ngoại lệ mà ERP không cover được
- Đội sales dùng Google Sheet riêng để track hoa hồng, vì module commission trong ERP “không đúng với thực tế”
- Bộ phận mua hàng vẫn gửi email xác nhận thủ công cho nhà cung cấp, vì họ không tin hệ thống tự động đã gửi chưa
Những chiếc file này không được thông báo. Không ai xin phép tạo ra chúng. Chúng tồn tại vì người dùng tìm thấy một khoảng trống giữa những gì ERP làm được và những gì công việc thực tế đòi hỏi — và họ tự lấp đầy khoảng trống đó bằng công cụ quen thuộc nhất: Excel.
Nguy hiểm không phải ở chỗ chúng tồn tại — mà ở chỗ chúng trở thành nguồn sự thật thực sự trong khi ERP chính thức trở thành hệ thống trưng bày. Và khi người sở hữu file Excel đó nghỉ phép, nghỉ việc, hoặc đơn giản là không nhớ mình lưu file ở đâu — cả một chức năng của doanh nghiệp có thể tê liệt.
Ba dạng kháng cự — và cách nhận biết chúng từ sớm
1. Kháng cự nhận thức — “Tôi không tin cái này sẽ tốt hơn”
Nhân viên chưa thấy bằng chứng rằng hệ thống mới sẽ giúp ích cho công việc cụ thể của họ. Họ nhìn vào giao diện mới và so sánh với quy trình quen thuộc đang hoạt động ổn. Trong đầu họ hiện ra câu hỏi: “Tại sao phải thay đổi cái đang chạy được?”
Dấu hiệu nhận biết: nhiều câu hỏi phản biện trong các buổi training, hoài nghi về tính năng mới, so sánh bất lợi với hệ thống cũ.
2. Kháng cự cảm xúc — “Tôi sợ mình sẽ bị bỏ lại”
Lo ngại về việc làm là thực và cần được thừa nhận. Khi một nhân viên kế toán nghe “phần mềm mới sẽ tự động hóa nhiều thứ”, điều họ nghe thấy là “công việc của tôi sắp biến mất”. Nỗi sợ này không hợp lý nhưng rất con người.
Dấu hiệu nhận biết: im lặng trong các buổi họp, tránh né các buổi training, lo âu lan tỏa trong team mà không ai nói thẳng ra.
3. Kháng cự hành vi — “Tôi vẫn làm theo cách cũ”
Đây là dạng hữu hình và có thể đo được: nhân viên đăng nhập hệ thống mới nhưng tiếp tục dùng quy trình cũ song song, nhập dữ liệu sai vì không hiểu tại sao trường đó lại quan trọng, hoặc tìm mọi cách tắt thông báo và bỏ qua bước xác nhận.
Dấu hiệu nhận biết: tỷ lệ sử dụng hệ thống thấp dù đã go-live, dữ liệu không nhất quán giữa các phòng ban, các shadow system bắt đầu xuất hiện.
Góc nhìn từ Nexus Prime: Chuyển đổi số thất bại ở phòng họp, không phải trên server
Tất cả những câu chuyện trên — Hershey’s, Nestlé, Target Canada, bệnh viện ẩn danh — có một điểm chung: công nghệ không phải nguyên nhân thất bại. SAP không lỗi. Oracle không lỗi. Odoo không lỗi.
Thất bại xảy ra khi dự án được quản lý như một dự án IT thay vì một dự án thay đổi tổ chức. Khi ngày go-live quan trọng hơn sự sẵn sàng của con người. Khi nhân viên được thông báo thay vì được tham vấn.
Tại Nexus Prime, mọi triển khai đều bao gồm:
- Khảo sát người dùng thực tế — không chỉ ban lãnh đạo — trước khi thiết kế bất kỳ quy trình nào
- Pilot nhỏ trước khi rollout toàn diện — để phát hiện vấn đề ở quy mô có thể kiểm soát
- Đào tạo theo vai trò, không phải đào tạo chung chung — kế toán học cái kế toán cần, kho học cái kho cần
- Giai đoạn chạy song song có giám sát — cho phép nhân viên làm quen với hệ thống mới mà không cảm thấy bị ép
- Kênh phản hồi nhanh sau go-live — vì vấn đề thực sự thường chỉ xuất hiện sau 2–4 tuần vận hành thực tế
Kháng cự thay đổi là phản ứng bình thường của con người trước điều bất định. Nhiệm vụ của đối tác triển khai không phải là triệt tiêu sự kháng cự — mà là thiết kế một hành trình thay đổi đủ rõ ràng, đủ an toàn, để kháng cự đó không cần phải xảy ra.
Nếu doanh nghiệp bạn đang chuẩn bị cho một dự án ERP — hoặc đang ở giữa một dự án đang có dấu hiệu kháng cự — chúng tôi rất muốn được nghe câu chuyện của bạn.
Giải pháp từ Nexus Prime
Triển khai ERP thành công cần đúng đối tác và đúng lộ trình đào tạo:
Đọc thêm
Khi vượt qua rào cản thay đổi, AI và ERP có thể tạo ra kết quả vượt kỳ vọng. Xem thêm:
