Làm Thế Nào Để Vượt Qua Sự Chống Đối Của Người Sử Dụng Khi Triển Khai Hệ Thống Phần Mềm Mới?

Khi triển khai hệ thống phần mềm mới, doanh nghiệp thường vướng phải sự chống đối của nhân viên, luôn tìm cách từ chối sử dụng cùng với việc viện dẫn các lý do có thể hoặc cố cường điệu hóa vấn đề. Làm thế nào có thể giảm bớt quy mô ảnh hưởng của việc phản đối ngay từ giai đoạn thiết kế và triển khai phần mềm, và cần làm gì nếu như đã bỏ qua giai đoạn đầu. Chúng ta cùng xem một số lời khuyên.

Phần nhiều các công ty khi triển khai hệ thống ERP, dưới dạng này hay dạng khác đều đụng chạm tới vấn đề chống đối từ phía nhân viên. Phần lớn các vấn đề nảy sinh ở giai đoạn cuối của dự án, khi mà phần lớn các công việc đã được thực hiện, và có cảm giác rằng, không có gì có thể cản trở việc đưa hệ thống vào sử dụng.

Sự chống đối từ phía nhân viên được thể hiện bằng cách từ chối sử dụng hệ thống bởi các lý do khác nhau. "Nguyên nhân" thường gặp là có nhiều lỗi làm cản trở công việc với hệ thống, không hiểu lô-gíc nghiệp vụ, giao diện lạ và không thân thiện, cần nhiều thao tác cần để thực hiện các giao dịch đơn giản…

Sự chống đối của nhân viên có thể dẫn tới việc ngưng trệ dự án, kéo dài thời hạn và có thể làm dự án bị đóng lại dở dang. Nhưng nếu đi theo các nguyên tắc nhất định để quản lý dự án thì ngay từ đầu có thể giảm bớt các "lực kéo cản trở" và dễ dàng vượt qua nó.

Các chống đối được hình thành như thế nào?

Sự chống đối xuất hiện ngay khi mà nhân viên bắt đầu làm việc với hệ thống. Ngay từ khi mà họ được thông báo rằng, sắp tới họ sẽ sử dụng hệ thống quản lý mới mà sẽ tự động hóa các nghiệp vụ, giảm bớt công sức và tiết kiệm thời gian. Tất nhiên, họ sẽ được đào tạo để sử dụng.

Và đến ngày đào tạo. Mọi nhân viên đã tập hợp thành nhóm (Lúc này, theo quy định thì một số người vẫn phải làm việc và đồng thời tham gia đào tạo, và như vậy, đó là nguyên nhân thường dẫn tới việc vằng mặt tại nơi đào tạo).

Trên lớp đào tạo, các chuyên gia của công ty lần đầu tiên nhìn thấy hệ thống mà họ sẽ phải làm việc sau này. Việc nghiên cứu giải pháp bao gồm xem xét tổng quan các tính năng và giao diện, đồng thời thực hiện một số bài tập thực tế. Cùng với sự trợ giúp của giảng viên, nhân viên dù sao cũng có thể qua được bài thực hành, tuy nhiên điều này không có nghĩa là họ đã hiểu được lô-gíc làm việc của hệ thống. Họ có thể nghiên cứu sâu hơn về giải pháp, nếu như ngay sau buổi đào tạo mà được sử dụng trực tiếp – tuy nhiên, điều này thường ít xảy ra (thường là trong các dự án triển khai) bởi do sự ngắt quãng giữa việc đào tạo và việc đưa hệ thống vào vận hành, ngoài ra còn không có "bài tập về nhà" hoặc không có khả năng thực hiện vì không truy cập được vào phần mềm.

Đến thời điểm, khi mà nhân viên bắt đầu làm việc với hệ thống mới, một phần trong số họ không nhớ các quy tắc, một phần khác hoàn toàn không biết cách sử dụng, bởi vì đã vắng mặt tại lớp đào tạo. Người tư vấn hoặc giảng viên mà có thể trả lời cho các câu hỏi, thì không có mặt. Những gì còn lại là tài liệu "Hướng dẫn sử dụng" dài "lê thê và khó đọc".

Các yếu tố khác làm tăng mức độ chống đối hệ thống mới

Trong hệ thống có các lỗi mà tất cả các phần mềm đều có, và tốc độ sửa lỗi thường rất chậm. Hơn nữa, mức độ quan trọng của các lỗi này đối với quy trình nghiệp vụ thường được nhân viên làm "trầm trọng hóa" quá mức.

Để giải quyết một số bài toán sử dụng hệ thống thông tin, nhân viên cần phải thực hiện một số lượng lớn các thao tác nhiều hơn so với hệ thống cũ hoặc so với Excel. Nguyên nhân là do nhân viên không hiểu các nguyên tắc làm việc của hệ thống, cũng như là do kết quả của việc thiết kế đã không tính đến yếu tố thân thiện cho người sử dụng.

Các cơ chế và quy trình nghiệp vụ có trong hệ thống có sự khác biệt với những gì đang được áp dụng thực tế hàng ngày.

Kết quả là đến tai người lãnh đạo một ý kiến tập thể làm sai lệch tình huống thực tế: "Hệ thống còn nhiều lỗi, do đó không thể làm việc được. Còn những nơi mà không có lỗi thì cũng cần mất đến 30 phút để thực hiện thao tác mà trên Excel chỉ mất 5 phút. Như vậy thì chúng tối không thể thực hiện các công việc của mình. Và nói chung, hệ thống rất khó hiểu và phức tạp, và có lẽ là họ (người tư vấn) không hiểu được chúng ta làm việc thế nào".

Trong tình huống như vậy, người lãnh đạo bắt đầu thiên về việc xử lý tình huống với công ty tư vấn. Và khi mà quá trình này vẫn còn đang tiếp diễn thì nhân viên vẫn cố để đạt được quyền sử dụng cách làm cũ hoặc thuyết phục lãnh đạo cho phép sử dụng hệ thống cũ. Như vậy, hệ thống mới đã bị thất bại ngay từ hiệp đầu.

(Nguồn Internet)​

Làm thế nào để loại trừ sự chống đối

Chống đối lại các thay đổi là bản chất cố hữu của con người, bởi vậy không thể loại trừ hoàn toàn. Tuy nhiên, có thể giảm bớt hiệu ứng của nó bằng cách tập trung vào 3 nguyên nhân chính: không hiểu hệ thống, lỗi hệ thống và thực thi không đúng quy trình nghiệp vụ. Các nguyên nhân của các vấn đề có thể điều tiết bằng cách huy động nhân viên vào tham gia từ những giai đoạn đầu của dự án.

Ở giai đoạn phân tích các quy tình nghiệp vụ và thống nhất yêu cầu của người đặt hàng, đơn vị tư vấn thường tiến hành phỏng vấn những người quản lý để mô tả lại các quy trình ở góc độ mà họ nắm bắt và ở mức quản lý của mình. Lúc này, người quản lý thường không rõ những chi tiết và các tiềm ẩn trong các quy trình, các thao tác do nhân viên của mình thực hiện. Như vậy, có những điều quan trọng trong công việc tác nghiệp của nhân viên bình thường có thể không được ghi nhận vào phần yêu cầu đối với hệ thống.

Ở giai đoạn này, người tư vấn cần tháo gỡ và chi tiết hóa các quy trình nghiệp vụ, trong việc phân tích cần huy động thêm những nhân viên bình thường mà họ có tham dự vào đó, ghi nhận các chi tiết để thực hiện các thao tác hàng ngày. Điều này cho phép tính đến và thực thi các nhu cầu của nhân viên.

Sau khi tiến hành phân tích, người tư vấn lập ra bản mô tả nhiệm vụ kỹ thuật hoặc dự thảo thiết kế. Đây là văn bản bao gồm (với mức độ chi tiết cần thiết) tất cả những gì cần phải thực thi trong hệ thống. Vấn đề là ở chỗ, phần lớn những người đại diện cho bên đặt hàng thường "không hiểu" tài liệu này, và thường giả định rằng, "người tư vấn đã hiểu tất cả, và có lẽ là đã trình bày chính xác". Cuối cùng, bản mô tả nhiệm vụ kỹ thuật được thống nhất bởi các bên và được chuyển đi lập trình.

Tuy nhiên, để tránh những tranh chấp sau này và để không phải làm lại các tính năng tốn kém, ở giai đoạn này thường phân tích cẩn thận bản mô tả do người tư vấn soạn, trao đổi tất cả những điểm khó hiểu với người đặt hàng. Kết quả tốt nhất sẽ cung cấp cho các chuyên gia tư vấn để chứng minh cho khách hàng và các nhân viên chủ chốt xem cách hệ thống sẽ được sử dụng để thực hiện các hoạt động hàng ngày của người lao động (gọi là Use Case).

Sau khi thống nhất bản thảo, lập trình viên sẽ bắt đầu thiết kế hệ thống. Trong phần lớn các dự án được xây dựng không phải trên cơ sở phương pháp luận mềm dẻo, mà người đặt hàng chỉ nhìn thấy kết quả cuối cùng, khi mà đơn giá để làm thêm bất kỳ việc gì cũng tăng lên. Lời khuyên – hãy chia nhỏ công việc lập trình ra thành nhiều bước nhỏ, trong mỗi bước đó cần phải thực thi các quy trình nghiệp vụ nhỏ đã hoàn thành.

Khi kết thúc mỗi bước cần minh họa các tính năng đã triển khai không chỉ cho doanh nghiệp đặt hàng mà còn cho cả nhân viên. Sau đó tiến hành các buổi tập huấn mà trong đó những nhân viên chủ chốt (bằng sự trợ giúp của người tư vấn) thực hiện các quy trình nghiệp vụ trong hệ thống. Trong lúc này, sẽ thực sự hữu ích nếu nhân viên trải qua khóa học không chỉ bằng các tình huống giả định do người tư vấn đặt ra, mà thực hiện các nhiệm vụ thực tế. Càng nhiều các vòng lặp thực hiện với các phương án khác nhau bao nhiêu thì sự phản hồi về hệ thống càng tốt bấy nhiêu. Ngoài ra, nhân viên cũng bắt đầu làm quen với giao diện phần mềm.

Nếu như đặc điểm kinh doanh và công việc triển khai cho phép, bước tiến triển tiếp theo sẽ là bắt đầu vận hành hệ thống trước khi kết thúc việc phát triển toàn bộ các tính năng. Điều này làm đơn giản hóa các nhiệm vụ cho nhân viên trong việc nghiên cứu các tính năng của hệ thống: thay vào việc ngụp lặn vào khối lượng thông tin khổng lồ, họ sẽ chỉ nắm bắt giải pháp từng bước theo từng khối nhỏ.

Làm cách nào để tiếp cận các tính năng

Một vài lời về tính năng. Để sao cho giảm bớt rủi ro không tiếp nhận hệ thống bởi lý do mất nhiều thời gian để sử dụng, khối tính năng đầu tiên cần sao cho đúng là thực sự tiết kiệm thời gian cho nhân viên trong việc thực hiện các thao tác tỷ mẩn hoặc cho phép nhận được kết quả mà cách làm cũ không đạt được. Điều này cho phép nhân viên cảm nhận hệ thống mới như là công cụ có ích và hiệu quả.

Khi bắt đầu vận hành hệ thống, cần chú ý đến vấn đề đào tạo. Trước hết, tính năng cần phải được kiểm thử cẩn thận và khi làm việc không được có sự cố. Học viên cần không bị phân tâm bởi các lỗi, về cách xử lý và tìm kiếm nguyên nhân. Việc thiếu tự tin của người sử dụng về tính ổn định của phần mềm sẽ làm giảm bớt cảm nhận tốt về giải pháp. Có thể tiến hành việc triển khai thử để cho lãnh đạo của doanh nghiệp đặt hàng có thể tin tưởng vào tính chính xác của chương trình, cũng như khả năng thực hiện tất cả các bài toán đặt ra.

Trong giai đoạn triển khai, cần huy động tối đa mọi nhân viên vào quá trình đào tạo, giải phóng họ khỏi các nhiệm vụ hiện thời, và để sao cho họ không được vắng mặt. Một điểm quan trọng là cần có sự có mặt trực tiếp của chính người lãnh đạo doanh nghiệp, và thể hiện sự quan tâm của mình đối với quá trình đào tạo và vận hành hệ thống. Điều này nâng cao kỷ luật và uy tín của giải pháp đang triển khai (tất nhiên là với điều kiện, người lãnh đạo không được sao nhãng khỏi quá trình).

Phần lớn các hệ thống thông tin được xây dựng trên cơ sở của một nền tảng công nghệ nào đó mà không phải lúc nào cũng có giao diện và lô-gíc dễ hiểu. Bởi vậy, trong quá trình đào tạo cần có phần mô tả các nguyên tắc chính làm việc của giải pháp, lô-gíc và các phần tử giao diện.

Chương trình đào tạo cần phải có bao gồm các bài tập thực tế mà người sử dụng có thể thực hiện ngay lập tức trong hệ thống, ngoài ra còn cần có "bài tập về nhà" mà họ có thể tự mình thực hiện, và sau đó thảo luận với người huấn luyện. Kết quả tốt nhất đạt được là có một hay nhiều tài liệu lặp lại sau một khoảng thời gian ngắn, trong đó nhân viên có thể áp dụng kiến thức đạt được khi làm việc với hệ thống và tích lũy các câu hỏi cho lần đào tạo tiếp theo.

Và tất nhiên, không nên tách biệt việc đào tạo và việc bắt đầu vận hành hệ thống. Kiến thức đạt được sẽ bị quên lãng nếu như không được củng cố bằng thực tế.

Trong những tháng vận hành đầu tiên của hệ thống mới, cần phải luôn có mặt (hoặc dễ tiếp cận) với người tư vấn hoặc chuyên gia đã được đào tạo của người đặt hàng mà có thể đưa ra được những lời khuyên dễ hiểu và kịp thời.

Làm thế nào để khắc phục được sự chống đối

Nếu như các biện pháp cảnh báo không được đưa ra thì sẽ nảy sinh tình huống mâu thuẫn giữa nhân viên và người tư vấn, trong đó nhân viên sẽ gán tội cho hệ thống có chất lượng tồi, còn người tư vấn sẽ nói tốt về hệ thống với lập luận rằng, nhân viên không muốn và không biết làm việc. Trong trường hợp này, doanh nghiệp đặt hàng không được phép xảy ra lỗi sau: đặt toàn bộ trách nhiệm giải quyết xung đột lên vai người tư vấn. Thường xảy ra như sau: "các anh hãy xem xét các vấn đề của nhân viên và hãy làm những gì mà họ muốn". Kết quả là có một loạt các vòng lặp chỉnh sửa và hoàn thiện hệ thống mà trong đó nhân viên lại tiếp tục tìm ra các lập luận mới để từ chối sử dụng phần mềm.

Doanh nghiệp đặt hàng cần phải dành ra thời gian tối đa có thể cho việc giải quyết xung đột và có thể đóng vai trò làm trọng tài. Nhiệm vụ chính là xem xét tình huống, phát hiện thực trạng của công việc và vượt qua từng phản đối của nhân viên.

Các nguyên nhân chống đối của nhân viên và cách giải quyết

Các vấn đề chính

Vấn đề 1: Lỗi chương trình

Cần thực hiện việc kiểm toán các lỗi. Bởi vì nhân viên thường cường điệu hóa số lượng và mức độ quan trọng của các lỗi, nên cần phân loại ra thành nhiều khả năng thực hiện các quy trình nghiệp vụ. Khi có có các lỗi làm ngưng trệ hệ thống hoặc lỗi nghiêm trọng, cần thỏa thuận với người tư vấn để sửa nhanh, sau đó cần phải xác nhận bằng cách kiểm thử, và chỉ sau đó mới thông báo cáo nhân viên về việc sửa lỗi.

Vấn đề 2: Sai trong việc thực thi quy trình nghiệp vụ

Cần cùng với người tư vấn tiến hành phân tích cẩn thận các quy trình nghiệp vụ đã làm và đưa ra kế hoạch điều chỉnh các khác biệt được phát hiện.

Các vấn đề khác

Vấn đề 3: Giao diện người sử dụng không thân thiện

Khi xây dựng hệ thống thường có sử dụng các nền tảng sẵn có mà có những đặc điểm riêng. Đối với giao diện, cũng như đối với bất kỳ sản phẩm phần mềm nào khác, cũng cần có thời gian để làm quen. Cần truyền đặt ý nghĩ này cho nhân viên, và cần tiến hành đào tạo bổ sung với mục đích giải thích cho nhân viên về lô-gíc làm việc của nền tảng.

Vấn đề 4: Mất nhiều công sức để làm việc với hệ thống

Nguyên nhân có thể là do lô-gíc của hệ thống cũng như không có giao diện thân thiện với người sử dụng. Cần truyền đạt cho người sử dụng 2 điểm. Thứ nhất là tốc độ làm việc với hệ thống ở giai đoạn này chưa cao là do nhân viên chưa đạt đến mức tương đương với mức độ hiểu biết hệ thống cũ hoặc các hệ thống truyền thống, và cần có thời gian để rèn rũa thêm kỹ năng. Theo thời gian, tốc độ làm việc sẽ được tăng lên một cách tự nhiên, chỉ cần thực hành nhiều. Điểm thứ 2 là không bao giờ có thể thiết kế được giao diện thân thiện ngay từ lần đầu tiên, bởi vì cách thức sử dụng hệ thống thực tế sẽ được cảm nhận trong quá trình làm việc. Không thể xây dựng được giao diện hoàn hảo, bởi vì giao diện luôn được hoàn thiện và có các thay đổi. Bởi vậy, không nên dừng hệ thống, nhưng cần bắt đầu quá trình tối ưu giao diện.

Vấn đề 5: Nhập thừa dữ liệu

Thường thì nhân viên hay phàn nàn về việc phải nhập dữ liệu quá nhiều so với sự cần thiết thực tế để thực hiện nhiệm vụ. Trong trường hợp này, cần xác định xem dữ liệu nào cần phải bắt buộc nhập và không bắt buộc nhập. Ngoài ra, cần giải thích cho nhân viên xem các thông tin nhập thừa sẽ trợ giúp cho công việc của họ thế nào. Ví dụ, tiết kiệm thời gian khi xem báo cáo hoặc tìm kiếm nhanh và chính xác dữ liệu cần tìm.

Vấn đề 6: Khó khăn trong việc nắm bắt hệ thống do không có sự trợ giúp

Cần thỏa thuận với người tư vấn để họ có mặt trong một khoảng thời gian tại nơi người sử dụng và có thể đưa ra tư vấn cho nhân viên khi cần thiết, có thể tiến hành đào tạo lại. Nếu như hệ thống lớn có nhiều tính năng thì nên tách ra thành các khối nhỏ để có thể tập trung xử lý và nắm bắt tài liệu.

Kết luận: Chỉ có 2 nguyên nhân (có các lỗi nghiêm trọng hoặc không thể thực hiện các quy trình nghiệp vụ) là có thể làm ngưng trệ việc đưa hệ thống vào vận hành, bởi vì việc sửa chữa các vấn đề có thể mất nhiều thời gian. Bất kỳ nguyên nhân chống đối nào khác đều có thể loại bỏ trong quá trình vận hành hệ thống.

Nhưng, tất nhiên là người lãnh đạo trực tiếp cần không được "phá hoại" việc triển khai hệ thống bằng cách thể hiện sự chống đối, mà ngược lại, sử dụng hệ thống và thể hiện như là một hình mẫu cho nhân viên dưới quyền.

 

Trị từ gốc trước chứ ko nên làm đến ngọn rồi mới sửa. Theo mình nên kết hợp phân tích nghiệp vụ và tập hợp ý kiến từ người dùng trước. khi triển khai đồng loạt cũng có quá trình kiểm thử đánh giá rồi sửa chữa lúc này nếu vấp phải khó khăn bạn có thể tháo gỡ dần. Chúc bạn thành công.

 

Người Việt mình thường luôn có tính "bảo thủ", khi muốn thay đổi một vấn đề gì mới mà vấn đề tiên phong, đột phá nữa thì lại rất khó thay đổi, nhưng ko phải là ko thay đổi được. Việc đầu tiên cần làm là phải chuẩn bị tâm lý+ với công tác truyền thông để mọi người hiểu cái hay cái mới, cái tốt. Khi mọi người trong cty hiểu hoặc ít nhất cũng 70% hiểu và đồng ý tức là chúng ta đã thành công trong việc triển khai hệ thống PM mới rồi.

 

Mình đồng ý với @maytrelang. Nói chung là họ ngại thay đổi với những gì đã trở thành thói quen, những công nghệ ngày càng phát triển, họ chưa hiểu sức mạnh của CNTT (phần mềm) có thể giúp họ giảm thiểu thời gian và công sức để làm những công việc trước đây họ từng làm, thậm chí còn làm vượt xa với những gì họ mong đợi. Vì vậy, những buổi truyền thông nội bộ về chức năng hay những ưu việt của phần mềm mới đem lại cần được phổ biến trước khi ứng dụng thì sẽ có sự đồng thuận hơn.