Quản lý thay đổi khi triển khai phần mềm là phần việc giúp con người chuyển từ cách làm cũ sang cách làm mới với phần mềm, để hệ thống được dùng thật và tạo ra giá trị như dự tính. Một phần mềm đúng đặc tả, nghiệm thu đạt, nhưng nhân viên vẫn ghi sổ tay rồi cuối ngày nhập lại cho có, là dự án thất bại về kinh doanh dù thành công về kỹ thuật.
Người dùng không chống lại phần mềm vì lười hay bảo thủ, như cách giải thích dễ dãi thường nghe. Họ chống lại vì những lý do khá hợp lý: phần mềm mới chậm hơn trong vài tuần đầu, làm lộ sai sót trước đây không ai thấy, đe doạ vị thế của người giỏi cách cũ, hoặc đơn giản là không ai giải thích vì sao phải đổi. Bài này đi qua các mô hình có cơ sở nghiên cứu, nguồn gốc kháng cự, kế hoạch quản lý thay đổi theo giai đoạn và cách đo mức sử dụng thật.
Mô hình chấp nhận công nghệ: người dùng thật sự cân nhắc gì
Mô hình chấp nhận công nghệ TAM do Fred Davis công bố năm 1989 là một trong những lý thuyết được kiểm chứng nhiều nhất trong lĩnh vực hệ thống thông tin. Davis đề xuất hai yếu tố chính quyết định ý định sử dụng: cảm nhận hữu ích (công cụ này có giúp mình làm việc tốt hơn không) và cảm nhận dễ dùng (dùng nó có tốn công không). Nhiều nghiên cứu sau đó cho thấy cảm nhận hữu ích thường có tác động mạnh hơn: người ta chịu học công cụ khó nếu thấy rõ lợi ích.
Venkatesh và cộng sự năm 2003 tổng hợp nhiều mô hình thành UTAUT, bổ sung hai yếu tố có ý nghĩa thực tiễn: ảnh hưởng xã hội, tức người quan trọng với mình có dùng và mong mình dùng không, và điều kiện hỗ trợ, tức có thiết bị, hướng dẫn, người giúp khi vướng không. Các mô hình này được kiểm chứng chủ yếu bằng khảo sát ý định, nên khả năng dự báo hành vi thực tế có giới hạn, nhưng khung tư duy thì rất dùng được.
Hệ quả cho người triển khai: đừng chỉ tập trung vào đào tạo thao tác. Câu hỏi đầu tiên người dùng cần được trả lời là "việc này giúp mình được gì" — với chính vị trí của họ, không phải với công ty nói chung. Một thủ kho không quan tâm báo cáo tồn kho thời gian thực cho ban giám đốc; anh ta quan tâm việc không phải kiểm kê lại cả kho mỗi khi lệch số.
Nguồn gốc thật của kháng cự
Hiểu đúng vì sao người dùng chống lại giúp chọn đúng biện pháp. Các nguồn thường gặp trong dự án phần mềm doanh nghiệp:
- Giảm năng suất tạm thời: người thạo cách cũ làm nhanh; tuần đầu với phần mềm mới chậm hơn rõ rệt, trong khi chỉ tiêu công việc vẫn giữ nguyên.
- Mất vị thế chuyên môn: người "biết hết" hệ thống cũ, sổ sách cũ trở thành người mới như mọi người khác.
- Minh bạch không mong muốn: phần mềm ghi lại ai làm gì lúc nào, làm lộ chậm trễ, sai sót hay những khoản linh động trước đây không ai thấy.
- Không hiểu lý do: quyết định từ trên xuống, không ai giải thích vấn đề mà phần mềm giải quyết.
- Trải nghiệm xấu từ trước: từng có phần mềm triển khai rồi bỏ, nên người dùng chờ xem lần này có bỏ nữa không.
- Phần mềm thật sự kém: thiếu chức năng thiết yếu, chậm, nhiều lỗi. Đây là kháng cự đúng, cần sửa phần mềm chứ không phải sửa người dùng.
- Tăng khối lượng việc: phần mềm đòi nhập thêm dữ liệu phục vụ người khác, mà người nhập không thấy lợi ích gì.
Nguồn thứ sáu và thứ bảy hay bị bỏ qua nhất. Khi người dùng phàn nàn, đội dự án thường mặc định đó là vấn đề thái độ. Lắng nghe kỹ, nhiều khi đó là thông tin quý về lỗi thiết kế: một bước nhập liệu thừa, một màn hình phải bấm mười lần cho việc trước đây làm trong một dòng sổ.
Mô hình ADKAR: chẩn đoán ai đang kẹt ở đâu
ADKAR do Jeff Hiatt phát triển tại Prosci, trình bày trong cuốn sách năm 2006, mô tả năm điều kiện mỗi cá nhân cần đạt lần lượt để thay đổi. Giá trị thực tiễn của nó là chẩn đoán: người dùng đang kẹt ở bước nào thì can thiệp đúng bước đó.
| Bước | Ý nghĩa | Dấu hiệu đang kẹt | Biện pháp phù hợp |
|---|---|---|---|
| Nhận thức (Awareness) | Hiểu vì sao phải thay đổi | "Cách cũ vẫn ổn mà" | Lãnh đạo trực tiếp giải thích vấn đề, chi phí của việc giữ nguyên |
| Mong muốn (Desire) | Muốn tham gia thay đổi | Hiểu nhưng thờ ơ, chờ xem | Chỉ rõ lợi ích cho từng vai trò; quản lý trực tiếp làm gương |
| Kiến thức (Knowledge) | Biết cách làm theo cách mới | Muốn dùng nhưng lúng túng | Đào tạo theo tình huống công việc, tài liệu ngắn theo vai trò |
| Khả năng (Ability) | Làm được trong công việc thật | Học rồi nhưng làm thật vẫn sai, vẫn chậm | Hỗ trợ tại chỗ những tuần đầu, người dùng chủ chốt kèm cặp |
| Củng cố (Reinforcement) | Duy trì, không quay lại cách cũ | Dùng vài tuần rồi quay về sổ tay, bảng tính | Đo mức sử dụng, khen thưởng, gỡ bỏ lối đi tắt về cách cũ |
Sai lầm phổ biến là dồn toàn bộ ngân sách quản lý thay đổi vào bước Kiến thức, tức các buổi đào tạo, trong khi người dùng đang kẹt ở Mong muốn hoặc Củng cố. Đào tạo kỹ cho người không muốn dùng chỉ tạo ra người biết dùng mà vẫn không dùng. Mô hình tám bước của Kotter bổ sung góc nhìn ở cấp tổ chức, như tạo cảm giác cấp bách và liên minh dẫn dắt; ADKAR mạnh ở cấp cá nhân.
Kế hoạch quản lý thay đổi theo giai đoạn dự án
Quản lý thay đổi không phải một hoạt động sát ngày vận hành, mà chạy song song suốt dự án:
- Khởi động: xác định nhà tài trợ cấp cao có tiếng nói thật; phân tích các nhóm bị ảnh hưởng, mức độ thay đổi với từng nhóm, những ai có thể mất hoặc được.
- Làm yêu cầu: mời người dùng đại diện tham gia viết yêu cầu và xem nguyên mẫu; người được hỏi ý kiến ít chống lại hơn người bị thông báo.
- Phát triển: chọn mạng lưới người dùng chủ chốt ở mỗi bộ phận, cho tham gia UAT, biến họ thành người hỗ trợ đồng nghiệp sau này.
- Trước vận hành: đào tạo theo vai trò và tình huống thật, sát ngày dùng; chuẩn bị tài liệu ngắn một trang cho thao tác chính; điều chỉnh chỉ tiêu công việc cho giai đoạn chuyển đổi.
- Tuần đầu vận hành: hỗ trợ tại chỗ, kênh hỏi đáp phản hồi nhanh, họp ngắn cuối ngày để gom vướng mắc và sửa nhanh những điều làm người dùng khó chịu nhất.
- Một đến ba tháng sau: đo mức sử dụng, tìm nhóm còn dùng cách cũ, tìm hiểu lý do; tắt dần các lối đi tắt về cách cũ như bảng tính song song, sổ tay.
- Sau ba tháng: chuyển quyền sở hữu sang bộ phận vận hành; ghi lại bài học cho dự án sau.
Bước điều chỉnh chỉ tiêu công việc ở giai đoạn trước vận hành thường bị bỏ qua. Nếu một nhân viên bán hàng bị đánh giá theo doanh số tuần mà phần mềm mới làm họ chậm trong hai tuần đầu, họ sẽ quay về cách cũ, và họ hành động hoàn toàn hợp lý theo hệ thống khuyến khích mà công ty đặt ra.
Người dùng chủ chốt và quản lý trực tiếp: hai đòn bẩy mạnh nhất
Trong thực hành quản lý thay đổi, người quản lý trực tiếp thường được coi là người có ảnh hưởng lớn nhất đến việc nhân viên có thay đổi hay không, hơn cả thông điệp từ lãnh đạo cấp cao. Nếu trưởng ca kho vẫn chấp nhận phiếu viết tay, mọi khẩu hiệu chuyển đổi số đều vô nghĩa. Vì vậy quản lý cấp trung cần được thuyết phục và đào tạo trước nhân viên, và được giao chỉ tiêu cụ thể về mức sử dụng của nhóm mình.
Đòn bẩy thứ hai là mạng lưới người dùng chủ chốt, những nhân viên giỏi việc, được đồng nghiệp tin, được tham gia sớm vào dự án. Họ biết phần mềm sâu hơn người khác, hiểu lý do thiết kế, và trở thành người đầu tiên đồng nghiệp hỏi khi vướng. Một câu trả lời từ người ngồi cạnh có sức thuyết phục hơn mười trang tài liệu. Theo tinh thần UTAUT, đây chính là ảnh hưởng xã hội và điều kiện hỗ trợ được tổ chức có chủ đích.
Người dùng chủ chốt cần được ghi nhận thật: giảm bớt công việc thường ngày trong giai đoạn dự án, tính vào đánh giá hiệu suất, có tiếng nói khi đề xuất thay đổi phần mềm. Giao thêm việc mà không ghi nhận thì sau dự án đầu tiên, sẽ không ai muốn nhận vai trò này nữa.
Đo mức sử dụng thật, không đo số tài khoản
Số người đăng nhập là chỉ số dễ lấy nhưng gần như vô nghĩa. Các chỉ số sau phản ánh mức sử dụng thật tốt hơn:
| Chỉ số | Cách đo | Đọc như thế nào |
|---|---|---|
| Tỷ lệ giao dịch đi qua hệ thống | Số đơn, phiếu, chứng từ tạo trên phần mềm so với tổng số thực tế | Dưới mức kỳ vọng nghĩa là còn kênh song song |
| Độ trễ nhập liệu | Khoảng cách giữa thời điểm phát sinh nghiệp vụ và thời điểm ghi vào hệ thống | Nhập dồn cuối ngày là dấu hiệu dùng cho có |
| Tỷ lệ dùng theo tính năng | Số người dùng từng chức năng chính | Chức năng không ai dùng: hoặc thừa, hoặc khó dùng, hoặc chưa được đào tạo |
| Yêu cầu hỗ trợ theo chủ đề | Phân loại câu hỏi, lỗi gửi về bộ phận hỗ trợ | Câu hỏi lặp lại chỉ ra chỗ cần sửa giao diện hoặc tài liệu |
| Chỉ số kinh doanh mục tiêu | Các chỉ số đặt ra trong RFP: thời gian chốt sổ, sai lệch tồn kho, thời gian xử lý đơn | Thước đo cuối cùng của giá trị dự án |
Dòng cuối nối quản lý thay đổi trở lại mục tiêu ban đầu của dự án. Nếu sau ba tháng mọi người đều dùng hệ thống mà thời gian chốt sổ không giảm, vấn đề có thể nằm ở thiết kế quy trình chứ không ở người dùng, và cần một vòng cải tiến tiếp theo.
Câu hỏi thường gặp
Ngân sách cho quản lý thay đổi nên chiếm bao nhiêu trong dự án phần mềm?
Không có tỷ lệ chuẩn được kiểm chứng rộng rãi; con số thay đổi theo mức độ thay đổi quy trình và số người bị ảnh hưởng. Nguyên tắc thực tế là dự án càng thay đổi nhiều cách làm việc của nhiều người thì phần này càng lớn, và nên được lập ngân sách riêng gồm đào tạo, hỗ trợ tại chỗ, thời gian của người dùng chủ chốt, chứ không gộp vào chi phí nhà cung cấp.
Có nên bắt buộc dùng phần mềm bằng cách tắt hẳn cách làm cũ?
Tắt cách cũ là biện pháp củng cố mạnh, nhưng chỉ nên làm khi phần mềm đã ổn định, người dùng đã được hỗ trợ đủ, và các lỗi lớn đã sửa. Tắt quá sớm khi phần mềm còn thiếu chức năng thiết yếu sẽ làm gián đoạn công việc và tạo kháng cự mạnh hơn. Thường nên có lộ trình công bố trước, tắt từng phần.
Người lớn tuổi khó dùng phần mềm thì làm sao?
Tuổi tác ít khi là vấn đề chính; vấn đề thường là thiếu thời gian học, sợ sai trước đồng nghiệp, và giao diện thiết kế cho người trẻ. Đào tạo nhóm nhỏ, cho thực hành trên dữ liệu thử không sợ hỏng, có người kèm cặp riêng vài buổi thường hiệu quả. Kinh nghiệm nghiệp vụ của họ cũng rất quý khi kiểm thử.
Đào tạo nên làm trước bao lâu so với ngày vận hành?
Càng sát càng tốt, thường trong vài ngày đến hai tuần trước khi dùng thật. Đào tạo quá sớm, người dùng quên trước khi kịp áp dụng. Nên kết hợp đào tạo chính thức với hỗ trợ tại chỗ trong tuần đầu và tài liệu tra cứu nhanh, vì phần lớn việc học thật sự diễn ra khi làm việc thật.
Lãnh đạo cấp cao cần làm gì cụ thể trong quản lý thay đổi?
Giải thích trực tiếp lý do thay đổi, không chỉ ký quyết định; tự mình dùng các báo cáo từ hệ thống mới thay vì yêu cầu báo cáo theo mẫu cũ; xử lý các xung đột giữa phòng ban; và bảo vệ dự án khi gặp khó khăn giai đoạn đầu. Khi lãnh đạo vẫn yêu cầu báo cáo bằng bảng tính cũ, nhân viên hiểu rằng hệ thống mới không thật sự quan trọng.
Khi nào nên dừng nỗ lực thuyết phục và xem lại phần mềm?
Khi nhiều người dùng thuộc các nhóm khác nhau phàn nàn cùng một điểm, khi mức sử dụng không tăng dù đã hỗ trợ đầy đủ, hoặc khi người dùng giỏi việc nhất lại là người chống mạnh nhất. Đó là dấu hiệu vấn đề nằm ở thiết kế hoặc quy trình. Phân tích hành vi sử dụng và phỏng vấn người dùng sẽ cho biết cần sửa gì.