Cách quản lý thay đổi khi triển khai công nghệ

Đây là lý do quản lý thay đổi phải chạy song song với triển khai kỹ thuật, thay vì được bổ sung vào vài tuần trước ngày go-live. Microsoft cũng lưu ý rằng một giải pháp có thể đáp ứng yêu cầu kỹ thuật nhưng vẫn không tạo ra kết quả kinh doanh nếu tồn tại khoảng cách giữa giải pháp và trải nghiệm sử dụng của người dùng.

Mức độ quản lý phần con người có quan hệ đáng kể với kết quả dự án. Trong nghiên cứu benchmark của Prosci với hơn 10.800 người tham gia tại 101 quốc gia, 88% sáng kiến được đánh giá có quản lý thay đổi xuất sắc đạt hoặc vượt mục tiêu, so với 13% ở nhóm quản lý thay đổi kém. Đây là tương quan chứ không phải bằng chứng rằng riêng quản lý thay đổi tạo ra toàn bộ khác biệt, nhưng nó cho thấy adoption không nên được xem là hoạt động phụ.

Xác định thay đổi trong công việc trước khi lập kế hoạch truyền thông

Bước đầu tiên không phải viết email thông báo mà là xác định chính xác công nghệ mới làm thay đổi công việc của từng nhóm người như thế nào. Một hệ thống ERP, CRM, nền tảng cộng tác hay công cụ AI có thể cùng được gọi là “triển khai công nghệ”, nhưng tác động thực tế rất khác nhau giữa kế toán, bán hàng, quản lý, vận hành và bộ phận hỗ trợ.

Doanh nghiệp cần chuyển phạm vi kỹ thuật thành bản đồ tác động nghiệp vụ. Với từng nhóm, cần làm rõ quy trình nào thay đổi, bước nào được thêm hoặc bỏ, dữ liệu nào phải nhập khác trước, quyền quyết định có dịch chuyển hay không, thao tác cũ nào không còn được phép và năng lực mới nào cần có.

Cách phân tích này giải quyết một lỗi thường gặp: dự án mô tả rất rõ “hệ thống có tính năng gì” nhưng lại mơ hồ về “ngày mai nhân viên phải làm khác hôm nay ở điểm nào”. Khi tác động cá nhân chưa rõ, truyền thông dễ trở thành thông điệp chung chung và đào tạo dễ biến thành buổi giới thiệu tính năng.

Ngay từ đây cũng nên xác định tiêu chí thành công ở phía người dùng. Go-live là mốc kỹ thuật; adoption cần các chỉ báo khác như tỷ lệ người dùng thực sự sử dụng quy trình mới, tốc độ chuyển từ cách làm cũ sang cách làm mới, mức độ thành thạo và kết quả nghiệp vụ phát sinh từ việc sử dụng đó. Prosci phân biệt ba chiều quan trọng của adoption là tốc độ chấp nhận, mức độ sử dụng và mức độ thành thạo.

Nhờ vậy, nhóm dự án có thể biết mình đang quản lý một thay đổi hành vi cụ thể, thay vì chỉ “quản lý cảm nhận của nhân viên” về công nghệ.

Biến lãnh đạo và quản lý trực tiếp thành tác nhân của thay đổi

Quản lý thay đổi không thể được giao hoàn toàn cho phòng nhân sự, đội truyền thông hoặc một change manager. Những đơn vị này có thể thiết kế phương pháp và công cụ, nhưng người tạo tính chính danh cho thay đổi phải là lãnh đạo chịu trách nhiệm về kết quả kinh doanh.

Vai trò của sponsor không dừng ở phê duyệt ngân sách hay xuất hiện tại buổi kick-off. Sponsor cần liên tục giải thích vì sao doanh nghiệp phải thay đổi, liên kết công nghệ với mục tiêu kinh doanh, giải quyết xung đột giữa các đơn vị và thể hiện bằng hành vi rằng cách làm mới thực sự được yêu cầu. Nghiên cứu của Prosci nhiều năm liên tiếp xác định sự tài trợ chủ động và có thể quan sát được của lãnh đạo là một trong những yếu tố đóng góp quan trọng nhất cho thành công của thay đổi.

Tuy nhiên, sponsor cấp cao không thể thay thế quản lý trực tiếp. Khi nhân viên muốn biết “tại sao công ty làm việc này?”, tiếng nói của lãnh đạo cấp cao có trọng lượng. Khi câu hỏi chuyển thành “việc này ảnh hưởng tới tôi thế nào?”, quản lý trực tiếp thường đáng tin cậy hơn vì họ hiểu công việc hàng ngày.

Dữ liệu Prosci phản ánh sự phân vai này: trong nghiên cứu về người gửi thông điệp được ưu tiên, CEO/chủ tịch đứng đầu đối với thông điệp cấp tổ chức ở mức 37%, trong khi 58% lựa chọn quản lý trực tiếp đối với thông điệp mang tính cá nhân.

Vì vậy, thay vì chỉ cung cấp cho quản lý một bộ slide, nhóm thay đổi cần chuẩn bị cho họ các câu trả lời về tác động công việc, kỳ vọng mới, vấn đề chưa được giải quyết và cách tiếp nhận phản hồi. Nếu quản lý trực tiếp không hiểu hoặc không ủng hộ thay đổi, họ có thể trở thành điểm nghẽn ngay cả khi thông điệp từ ban lãnh đạo rất rõ.

Truyền thông theo câu hỏi của người nhận, không theo lịch của dự án

Truyền thông thay đổi thường thất bại khi được tổ chức quanh các mốc của đội dự án: hoàn tất thiết kế, hoàn tất UAT, chuẩn bị go-live. Người dùng lại tiếp nhận thay đổi theo một logic khác. Họ muốn biết vì sao cần thay đổi, điều gì ảnh hưởng tới mình, khi nào phải hành động và mình sẽ được hỗ trợ ra sao.

Do đó, kế hoạch truyền thông nên được thiết kế theo tiến trình nhận thức của người nhận.

Ở giai đoạn đầu, thông điệp quan trọng là lý do thay đổi: vấn đề hiện tại là gì, nếu không thay đổi thì doanh nghiệp gặp giới hạn nào và công nghệ mới liên quan đến mục tiêu kinh doanh ra sao. Khi giải pháp đã cụ thể hơn, nội dung phải chuyển sang tác động theo vai trò. Gần thời điểm triển khai, thông tin cần thực dụng hơn: việc phải chuẩn bị, thời gian đào tạo, ngày chuyển đổi, nơi nhận hỗ trợ và cách xử lý công việc trong giai đoạn chuyển tiếp.

Prosci khuyến nghị phân biệt người gửi theo loại thông điệp: lãnh đạo cấp cao truyền đạt lý do và bối cảnh kinh doanh; quản lý trực tiếp giải thích tác động cá nhân. Đồng thời, người gửi cần được chuẩn bị trước để thông điệp nhất quán thay vì chỉ nhận nội dung rồi tự diễn giải.

Truyền thông cũng phải có chiều phản hồi. Một cuộc họp town hall, FAQ hay email hàng tuần không chứng minh rằng người nhận đã hiểu. Nhóm thay đổi cần quan sát câu hỏi lặp lại, phản hồi của quản lý, chủ đề phát sinh trong đào tạo, dữ liệu khảo sát và các điểm vướng trong pilot để biết thông điệp nào chưa được tiếp nhận.

Điểm giới hạn cần lưu ý là truyền thông nhiều không đồng nghĩa với quản lý thay đổi tốt. Prosci thậm chí cảnh báo việc đồng nhất kế hoạch truyền thông với toàn bộ change management là một hiểu lầm: sponsorship, cách tiếp cận có cấu trúc, sự tham gia của quản lý và các hoạt động hỗ trợ adoption vẫn giữ vai trò riêng.

Đào tạo theo vai trò và tình huống làm việc thực tế

Đào tạo công nghệ không nên được thiết kế như một chuyến tham quan toàn bộ hệ thống. Một nhân viên hiếm khi cần biết mọi menu và tính năng; họ cần hoàn thành chính xác những nhiệm vụ thuộc vai trò của mình.

Vì vậy, đơn vị triển khai nên bắt đầu từ persona, vai trò và quy trình nghiệp vụ rồi xác định năng lực cần đạt. Người phê duyệt đơn hàng cần một lộ trình khác người tạo đơn. Quản lý bán hàng cần biết cách theo dõi pipeline và kiểm tra chất lượng dữ liệu, trong khi nhân viên bán hàng phải biết nhập và cập nhật cơ hội đúng quy trình.

Microsoft khuyến nghị liên kết rõ persona với vai trò, quy trình kinh doanh và cấp độ người dùng để mỗi buổi đào tạo cung cấp nội dung phù hợp; mục tiêu đào tạo cũng nên có khả năng đo lường và gắn với mục tiêu adoption của tổ chức.

Đào tạo nên diễn ra đủ gần thời điểm sử dụng để kiến thức không bị quên trước khi người học có cơ hội áp dụng. Với những quy trình quan trọng, chỉ xem video hoặc tham dự lớp học chưa đủ. Người dùng cần được thực hành trên tình huống gần với công việc thật, nhận phản hồi về lỗi và biết cách xử lý các ngoại lệ thường gặp.

Sau đào tạo, doanh nghiệp cũng không nên dùng “tỷ lệ tham dự lớp” làm bằng chứng duy nhất cho readiness. Microsoft khuyến nghị thiết lập feedback loop thông qua khảo sát, phỏng vấn hoặc quan sát trực tiếp, đồng thời chú ý riêng đến các nhóm người dùng và quy trình có rủi ro cao.

Nếu một nhóm đã học nhưng vẫn không hoàn thành được thao tác cốt lõi, vấn đề là proficiency chưa đạt chứ không phải chương trình đào tạo đã “hoàn tất”.

Xử lý phản kháng bằng nguyên nhân gốc thay vì ép tuân thủ

Phản kháng không nhất thiết có nghĩa nhân viên chống công nghệ. Một người có thể ủng hộ mục tiêu chung nhưng vẫn phản đối cách triển khai vì lo tăng khối lượng công việc, mất quyền kiểm soát, không hiểu lợi ích, thiếu kỹ năng hoặc từng trải qua các dự án thất bại.

Đây là lý do doanh nghiệp không nên gom mọi phản ứng vào một nhãn “resistant user”. Cùng một hành vi trì hoãn sử dụng hệ thống có thể xuất phát từ nhiều nguyên nhân khác nhau, và mỗi nguyên nhân cần một cách xử lý khác.

Nếu người dùng chưa hiểu lý do thay đổi, cần bổ sung nhận thức. Nếu họ thấy công nghệ tạo thêm việc nhưng lợi ích thuộc về bộ phận khác, cần xử lý thiết kế quy trình hoặc động lực. Nếu họ sợ không sử dụng được hệ thống, giải pháp nằm ở đào tạo và hỗ trợ. Nếu quản lý vẫn ngầm cho phép dùng file Excel hoặc quy trình cũ, vấn đề là quản trị và reinforcement chứ không phải truyền thông.

Nghiên cứu Prosci cho thấy các nguyên nhân phản kháng của quản lý có thể bao gồm văn hóa tổ chức, thiếu nhận thức và kiến thức về thay đổi, thiếu cam kết, mục tiêu dự án không phù hợp với động lực cá nhân và thiếu tự tin trong khả năng quản lý thay đổi. Điều này củng cố cách tiếp cận theo nguyên nhân thay vì coi phản kháng chỉ là thái độ tiêu cực.

Một ranh giới quan trọng là không phải mọi phản đối đều cần được “loại bỏ”. Phản hồi từ người dùng đôi khi phát hiện một bước quy trình bất hợp lý, phân quyền sai, dữ liệu chưa sẵn sàng hoặc thiết kế giao diện gây trở ngại. Khi đó, phản kháng mang thông tin về chất lượng giải pháp. Quản lý thay đổi hiệu quả phải phân biệt vấn đề cần thay đổi ở con người với vấn đề cần sửa ở chính giải pháp.

Dùng pilot và hỗ trợ go-live để giảm khoảng cách từ học sang làm

Giữa việc “biết sử dụng” và “sử dụng được trong công việc thật” luôn tồn tại một khoảng cách. Áp lực thời gian, dữ liệu thật, ngoại lệ nghiệp vụ và sự phụ thuộc giữa các phòng ban chỉ xuất hiện đầy đủ khi người dùng bắt đầu làm việc trong môi trường thực tế.

Pilot giúp doanh nghiệp phát hiện khoảng cách này trước khi mở rộng quy mô. Nhóm thử nghiệm nên đại diện cho những vai trò, quy trình hoặc nhóm rủi ro quan trọng, thay vì chỉ gồm những người nhiệt tình với dự án. Phản hồi từ pilot có thể được dùng để điều chỉnh hướng dẫn, đào tạo, quy trình hỗ trợ và đôi khi cả cấu hình giải pháp.

Khi go-live, cơ chế hỗ trợ phải được thiết kế trước. Người dùng cần biết vấn đề nào tự tra cứu được, vấn đề nào gửi cho super user, trường hợp nào lên help desk và lỗi nào cần chuyển cho đội kỹ thuật. Không có đường hỗ trợ rõ ràng, một lỗi nhỏ trong tuần đầu có thể nhanh chóng trở thành lý do để quay lại cách làm cũ.

Cũng cần ưu tiên các nhóm rủi ro cao. Microsoft khuyến nghị sau UAT phải đồng thời triển khai kế hoạch đào tạo và truyền thông, theo dõi trải nghiệm đào tạo và chú ý tới các nhóm người dùng hoặc quy trình có nguy cơ cao trước go-live.

Pilot vì thế không chỉ là kiểm thử kỹ thuật ở quy mô nhỏ. Nó là cơ hội kiểm tra xem tổ chức đã đủ sẵn sàng để biến giải pháp kỹ thuật thành một cách làm việc mới hay chưa.

Đo adoption sau go-live và củng cố hành vi mới

Ngày go-live không phải điểm kết thúc của quản lý thay đổi. Nếu dự án dừng theo dõi ngay sau khi hệ thống ổn định kỹ thuật, doanh nghiệp có thể bỏ qua tình huống hệ thống “đang chạy” nhưng nhân viên sử dụng không đầy đủ, tạo quy trình vòng hoặc tiếp tục duy trì công cụ cũ bên ngoài hệ thống.

Đo adoption cần kết hợp nhiều lớp. Dữ liệu đăng nhập chỉ chứng minh người dùng đã vào hệ thống; nó không cho biết họ đã thực hiện đúng quy trình hay chưa. Doanh nghiệp nên theo dõi mức độ sử dụng các giao dịch hoặc chức năng cốt lõi, tỷ lệ hoàn thành đúng quy trình, chất lượng dữ liệu, lỗi hỗ trợ, thời gian xử lý và các KPI nghiệp vụ mà công nghệ được triển khai để cải thiện.

Các chỉ số phải được đọc theo nhóm người dùng và theo thời gian. Nếu adoption thấp tập trung ở một bộ phận, đó có thể là vấn đề về quản lý, đào tạo hoặc thiết kế công việc tại bộ phận ấy. Nếu sử dụng cao nhưng KPI nghiệp vụ không cải thiện, doanh nghiệp cần kiểm tra liệu công nghệ có được sử dụng đúng cách hay mục tiêu ban đầu có thực tế hay không.

Sự tham gia của tuyến đầu đặc biệt đáng chú ý. Trong nghiên cứu của McKinsey về chuyển đổi tổ chức, 73% người trả lời tại các chuyển đổi thành công cho biết nhân viên tuyến đầu tham gia rõ rệt, so với 46% ở các trường hợp còn lại. Khi cả quản lý tuyến và nhân viên tuyến đầu đều không được thu hút tham gia, chỉ 3% người trả lời đánh giá chuyển đổi của họ thành công.

Sau khi phát hiện khoảng trống adoption, reinforcement phải tác động đúng nguyên nhân: huấn luyện bổ sung khi thiếu kỹ năng, coaching cho quản lý khi kỳ vọng chưa rõ, sửa quy trình khi người dùng phải tìm đường vòng, tăng hỗ trợ khi lỗi vận hành còn nhiều, hoặc loại bỏ cách làm cũ khi việc duy trì song song khiến người dùng không có lý do chuyển hẳn sang hệ thống mới.

Quản lý thay đổi chỉ thực sự hoàn thành khi hành vi mới trở thành cách vận hành bình thường và kết quả kỳ vọng bắt đầu xuất hiện, không phải khi dự án kỹ thuật đóng biên bản nghiệm thu.

Doanh nghiệp quản lý thay đổi trong quá trình triển khai công nghệ hiệu quả khi coi adoption là một phần của thiết kế dự án ngay từ đầu. Trình tự hợp lý là xác định tác động đến công việc và tiêu chí thành công, huy động sponsor cùng quản lý trực tiếp, truyền thông theo nhu cầu của từng nhóm, đào tạo theo vai trò, xử lý phản kháng theo nguyên nhân, kiểm chứng readiness qua pilot và tiếp tục đo mức sử dụng sau go-live. Công nghệ cung cấp năng lực mới; kết quả kinh doanh chỉ hình thành khi tổ chức biến năng lực đó thành hành vi làm việc ổn định.