AnalysisERPUnderstanding

ERP và con người: tại sao user adoption quyết định thành bại

2026-09-24


Giới thiệu

→ Khám phá các giải pháp ERP Readiness

Để xem tác động của customization lên user adoption, xem: Customization ERP: ranh giới giữa linh hoạt và rủi ro

Để hiểu kế toán sẵn sàng sau thách thức adoption, xem: Accounting Readiness trước ERP — những gì CFO cần biết

Để hiểu lý do cơ bản, xem: Tại sao dự án ERP không đạt mục tiêu — và vấn đề thực sự không nằm ở phần mềm

Tóm tắt cho CEO / HR Director / Operations Director

  • Phần mềm ERP không tự thay đổi hành vi của con người — và nếu con người không thay đổi cách làm việc, ERP không tạo ra giá trị.
  • Kháng cự ERP không phải lúc nào cũng xuất phát từ thái độ tiêu cực. Nhiều khi nó xuất phát từ những lo ngại hợp lý mà doanh nghiệp chưa giải quyết.
  • Đào tạo phần mềm và change management là hai thứ khác nhau — và phần lớn dự án ERP chỉ làm thứ nhất.
  • User adoption cần được chuẩn bị từ trước go-live, không phải sau khi vấn đề đã xuất hiện.

Khi phần mềm chạy nhưng doanh nghiệp không thay đổi

Có một tình huống phổ biến sau go-live ERP mà nhiều CEO và Operations Director nhận ra:

Hệ thống hoạt động. Server chạy. Nhân viên đăng nhập. Nhưng sau vài tháng, phần lớn công việc thực tế vẫn được xử lý qua Excel, qua email, qua tin nhắn, qua những cách mà mọi người đã quen từ trước khi có ERP.

Dữ liệu trong ERP không đầy đủ hoặc không chính xác. Báo cáo từ ERP không được dùng để ra quyết định. Và dần dần, cả tổ chức ngầm chấp nhận rằng ERP là thứ phải nhập liệu để đáp ứng yêu cầu — chứ không phải thứ thực sự giúp mọi người làm việc.

Đây không phải thất bại kỹ thuật. Đây là thất bại về user adoption.

Và đây là dạng thất bại phổ biến hơn nhiều so với những gì được thừa nhận công khai trong các dự án ERP.


Tại sao nhân viên kháng cự ERP?

Bốn lo ngại khiến nhân viên kháng cự ERP: phức tạp hơn và không thấy lợi ích cho bản thân, sợ làm sai, dữ liệu không đáng tin và không có thời gian học.

Trước khi nói đến giải pháp, cần hiểu đúng vấn đề.

Kháng cự ERP thường bị gán nhãn là “thái độ tiêu cực” hoặc “không chịu thay đổi”. Nhưng nếu nhìn kỹ hơn, phần lớn kháng cự xuất phát từ những lo ngại hoàn toàn hợp lý mà doanh nghiệp chưa giải quyết thỏa đáng.

“Hệ thống mới phức tạp hơn cách cũ — và tôi không thấy mình được lợi gì.”

Đây là lo ngại phổ biến và thực ra rất hợp lý. Với người dùng cuối, ERP thường làm tăng số bước cần thực hiện cho một nhiệm vụ so với cách họ đang làm. Cách cũ — dù kém hơn về mặt tổ chức — cảm thấy nhanh hơn và quen thuộc hơn.

Nếu doanh nghiệp không giải thích rõ được cái lợi cụ thể mà người dùng cuối nhận được từ việc làm theo hệ thống — không phải lợi ích cho doanh nghiệp, mà lợi ích cho chính họ — thì kháng cự là phản ứng tự nhiên.

“Tôi không chắc mình làm đúng — và tôi sợ mắc lỗi.”

ERP, đặc biệt với những người chưa quen, có thể gây ra lo lắng về việc nhập sai dữ liệu, phê duyệt nhầm, hoặc làm ảnh hưởng đến quy trình của bộ phận khác. Lo ngại này ít được nói ra nhưng phổ biến hơn nhiều so với những gì các dự án ERP thường nhìn thấy.

Khi đào tạo không đủ và không có nơi để hỏi khi gặp vấn đề, cách an toàn nhất là tránh dùng hệ thống hoặc chỉ nhập những thứ tối thiểu bắt buộc.

“Thông tin trong hệ thống không đáng tin cậy — vậy tại sao tôi phải dùng nó?”

Đây là một vòng lặp tự củng cố: khi không đủ người dùng hệ thống đúng cách, dữ liệu trong ERP không đầy đủ và không chính xác → người dùng khác không tin vào dữ liệu → họ tiếp tục dùng cách cũ → dữ liệu trong ERP càng kém chất lượng hơn.

Vòng lặp này một khi đã hình thành thì rất khó phá vỡ.

“Tôi không có thời gian để vừa làm việc vừa học hệ thống mới.”

Nhân viên trong môi trường sản xuất thường có áp lực vận hành hàng ngày rất lớn. Thêm ERP vào trong bối cảnh đó — mà không giảm bớt khối lượng công việc tạm thời hoặc không có đủ hỗ trợ trong giai đoạn chuyển đổi — là tạo ra một tình huống mà người dùng cảm thấy bị mắc kẹt giữa hai hệ thống.


Ba dạng kháng cự phổ biến

Ba dạng kháng cự phổ biến: kháng cự thụ động, kháng cự ngầm là dạng khó phát hiện nhất và kháng cự công khai.

Kháng cự không phải lúc nào cũng biểu hiện rõ ràng. Có ba dạng thường gặp nhất:

Kháng cự thụ động. Nhân viên dùng hệ thống đúng mức tối thiểu — nhập đủ để không bị phàn nàn, nhưng vẫn giữ nguyên các file Excel, sổ tay, và quy trình ngầm bên cạnh. Dữ liệu trong ERP tồn tại nhưng không đủ để tin cậy.

Kháng cự chủ động nhưng ngầm. Nhân viên tìm cách làm vòng quanh hệ thống — xin sếp xử lý ngoài hệ thống, nhờ đồng nghiệp nhập thay, hoặc sáng tạo các quy trình ngoài luồng mà hệ thống không biết. Dạng này khó phát hiện nhất vì nó không biểu hiện thành phàn nàn.

Kháng cự công khai. Nhân viên, thường là cấp quản lý trung gian, phàn nàn công khai về hệ thống — cho rằng nó không phù hợp, quá phức tạp, hoặc kém hơn cách cũ. Dạng này dễ phát hiện nhất nhưng cũng có thể lan rộng và ảnh hưởng đến thái độ của nhiều người khác.

Cả ba dạng đều có cùng một hậu quả: ERP không phản ánh thực tế vận hành, và giá trị của hệ thống giảm dần theo thời gian.


Những sai lầm phổ biến trong đào tạo ERP

Bốn sai lầm phổ biến khi đào tạo ERP: đào tạo quá muộn, đào tạo kiểu demo, không gắn với công việc thực tế và thiếu hỗ trợ sau đào tạo.

Đào tạo ERP thường được coi là giải pháp cho vấn đề user adoption. Nhưng phần lớn cách đào tạo được thực hiện trong thực tế không giải quyết được vấn đề thực sự.

Đào tạo quá muộn. Nhiều dự án đào tạo người dùng cuối ngay trước go-live — một hoặc hai tuần trước khi hệ thống chính thức hoạt động. Ở thời điểm đó, áp lực deadline cao, không đủ thời gian để thực hành, và người dùng không có cơ hội hỏi thêm sau khi đào tạo kết thúc.

Kết quả: người dùng go-live với sự tự tin thấp và không có chỗ để hỏi khi gặp vấn đề.

Đào tạo theo kiểu “demo phần mềm”. Nhà triển khai trình bày cách hệ thống hoạt động trong môi trường demo, người dùng xem và gật đầu. Nhưng xem một quy trình được thực hiện trong môi trường demo khác hoàn toàn với tự mình thực hiện trong công việc thực tế.

Người dùng không học bằng cách xem — họ học bằng cách làm, mắc lỗi, và được sửa.

Đào tạo không gắn với công việc thực tế. Người dùng được dạy cách nhập một Purchase Order trong hệ thống demo, nhưng không được hướng dẫn về quy trình cụ thể của công ty — ai cần phê duyệt, khi nào cần nhập, cần đính kèm tài liệu gì.

Kết quả là người dùng biết cách dùng phần mềm về mặt kỹ thuật, nhưng không biết phải dùng nó như thế nào trong công việc thực tế của mình.

Không có hỗ trợ sau đào tạo. Ngay cả khi đào tạo tốt, người dùng sẽ gặp tình huống không được đề cập khi họ bắt đầu dùng hệ thống thực. Nếu không có kênh hỗ trợ rõ ràng — ai để hỏi, hỏi qua đâu, thời gian phản hồi bao lâu — người dùng sẽ tự tìm cách giải quyết theo cách riêng của họ, thường là không dùng hệ thống.


Change management không phải đào tạo phần mềm

Đào tạo phần mềm trả lời câu hỏi làm thao tác này thế nào, còn change management trả lời vì sao tôi nên đổi và điều đó có ý nghĩa gì với tôi; câu hỏi thứ hai cần được trả lời trước.

Đây là điểm phân biệt quan trọng nhất mà nhiều dự án ERP bỏ qua.

Đào tạo phần mềm trả lời câu hỏi: “Làm thế nào để thực hiện thao tác X trong hệ thống?”

Change management trả lời câu hỏi: “Tại sao tôi nên thay đổi cách làm việc, và điều đó có ý nghĩa gì với tôi?”

Câu hỏi thứ hai cần được trả lời trước câu hỏi thứ nhất. Nếu người dùng chưa hiểu tại sao thì việc biết như thế nào cũng không đủ để tạo ra thay đổi hành vi bền vững.

Một số yếu tố của change management thực sự hiệu quả:

Truyền thông sớm và rõ ràng. Trước khi dự án bắt đầu, nhân viên cần biết: hệ thống mới sẽ ảnh hưởng đến công việc của họ như thế nào, lịch trình là gì, và họ sẽ được hỗ trợ như thế nào trong quá trình chuyển đổi. Không có thông tin, người ta tự lấp đầy bằng giả định — thường là tiêu cực hơn thực tế.

Giải thích lợi ích ở góc độ người dùng cuối. “Hệ thống mới giúp doanh nghiệp có báo cáo tốt hơn” không phải lý do để người dùng cuối thay đổi cách làm việc. “Hệ thống mới giúp bạn không phải chờ đợi phê duyệt qua email và theo dõi đơn hàng theo thời gian thực” thì khác.

Super user — người dùng nội bộ am hiểu hệ thống. Chọn và đào tạo một nhóm nhỏ người dùng nội bộ trở thành “super user” — người hiểu hệ thống sâu hơn mức trung bình và có thể hỗ trợ đồng nghiệp trong công việc hàng ngày. Đây là cơ chế hỗ trợ bền vững hơn nhiều so với chỉ dựa vào nhà triển khai.

Lãnh đạo dùng hệ thống trước. Khi CEO, COO, hoặc quản lý cấp trung yêu cầu báo cáo từ ERP thay vì từ Excel, khi họ đặt câu hỏi dựa trên dữ liệu từ hệ thống — đó là tín hiệu mạnh nhất mà tổ chức có thể gửi đến nhân viên về mức độ nghiêm túc của việc dùng ERP.

Tạo điều kiện để thử nghiệm và mắc lỗi an toàn. Môi trường sandbox hoặc giai đoạn parallel run — cho phép người dùng thực hành với dữ liệu thực trong hệ thống thực mà không lo ngại về hậu quả — giảm đáng kể lo ngại về việc mắc lỗi và tăng sự tự tin trước go-live.

Năm yếu tố change management hiệu quả: truyền thông sớm và rõ ràng, lợi ích theo góc nhìn người dùng, super user, lãnh đạo dùng hệ thống trước và môi trường thử an toàn.


Tự đánh giá: doanh nghiệp bạn đã chuẩn bị cho change management chưa?

Sáu câu hỏi tự đánh giá mức sẵn sàng change management: thông tin dự án, lợi ích theo nhóm người dùng, đào tạo thực hành, super user, cam kết của lãnh đạo và kênh hỗ trợ sau go-live.

→ Xem thêm: Khi nhân sự chủ chốt nghỉ việc, họ mang đi thứ gì? — bài về knowledge retention

→ Làm ERP Readiness Assessment


Bài viết này là một phần của chuỗi chuyên đề về ERP readiness cho doanh nghiệp sản xuất SME.

Bài liên quan:

Does this describe your organization?

Điều này có đúng với doanh nghiệp bạn?

Chia sẻ:FacebookLinkedIn

Next step

Xác định mức độ sẵn sàng triển khai ERP của doanh nghiệp bạn