Quản trị thay đổi: vì sao việc của FDE chưa xong vào ngày go-live

Hãy hình dung thế này: demo đã xong, khách hàng ký nghiệm thu, dashboard xanh hết. Hai tuần sau bạn mở log thì thấy hệ thống vẫn chạy tốt, chỉ có điều gần như không ai dùng nó.

Đây là kiểu thất bại khó chịu nhất với một FDE. Không có incident, không có bug nào để sửa, và trong ticket cũng chẳng ai phàn nàn. Người dùng chỉ đơn giản là quay lại cách làm cũ, rồi sáu tháng sau, đến lúc gia hạn hợp đồng, khách hàng hỏi hệ thống này đã mang lại được gì.

Planisware, một vendor phần mềm quản lý dự án, viết thẳng rằng khách hàng của họ thường nghĩ phần lớn công việc đã xong khi hệ thống sẵn sàng deploy, và họ khẳng định điều đó không đúng.

Tryolabs thì gọi phần còn lại là “last mile” của FDE: onboarding người dùng, quản trị thay đổi và tích hợp vào quy trình làm việc. Phần việc này không nằm ngoài kỹ thuật. Nó quyết định hệ thống bạn viết có tạo ra giá trị hay không.

Vì sao một buổi training thường không đủ?

Hầu hết engineer hiểu “đào tạo người dùng” là một buổi chiếu slide trước ngày go-live, có demo, có Q&A và một file hướng dẫn gửi qua email. Cách đó bỏ qua một chi tiết quan trọng: biết cách dùng và làm được không phải là một.

Mô hình ADKAR của Prosci tách quá trình thay đổi của từng người thành năm kết quả, ứng với năm chữ cái: Awareness, Desire, Knowledge, Ability, Reinforcement. Trong đó Knowledge là biết cách thay đổi, còn Ability là đưa kỹ năng và hành vi mới vào thực hành.

Buổi học trên lớp chỉ chạm tới Knowledge. Một kế toán viên có thể gật đầu suốt buổi demo, nhưng đến khi gặp hóa đơn đầu tiên bị scan lệch, họ vẫn không biết phải làm gì.

Hai đầu còn lại của mô hình cũng hay bị bỏ qua. Ở đầu vào, Prosci cảnh báo rằng gửi thông báo cho nhân viên không có nghĩa họ đã có Awareness, tức là đã hiểu vì sao phải thay đổi.

Ở đầu ra, Reinforcement là duy trì cách làm mới và ngăn người dùng trượt về thói quen cũ. Theo Prosci, thiếu bước này thì người dùng có thể quay lại cách làm cũ, và dự án có nguy cơ không thu về được những lợi ích đã đặt ra.

Một ca cụ thể: agent đọc hóa đơn cho phòng kế toán

Thử hình dung bạn deploy một agent trích xuất dữ liệu hóa đơn cho phòng kế toán 12 người ở một công ty phân phối. Agent đọc file PDF, điền các trường vào hệ thống ERP, và những trường có độ tin cậy thấp sẽ được đẩy sang hàng đợi để con người duyệt. Về mặt kỹ thuật, mọi thứ đều ổn.

Việc của bạn ở từng giai đoạn sẽ trông như sau.

Awareness. Đừng bắt đầu bằng email “từ thứ Hai, phòng mình chuyển sang công cụ mới”. Hãy ngồi với kế toán trưởng và hỏi: “Cuối tháng, phòng mình mất bao nhiêu buổi tối để nhập tay hóa đơn?” Câu trả lời của chị ấy chính là lý do cần thay đổi, và đó phải là lời của người trong phòng chứ không phải lời của vendor.

Desire. Hiểu lý do chưa chắc đã muốn đổi. Một kế toán viên đã nhập tay nhiều năm có thể lo công cụ mới làm lộ sai sót cũ, hoặc làm mình thành thừa. Bạn mời hai người trong phòng góp ý cách sắp xếp hàng đợi duyệt, để hệ thống có phần đóng góp của chính họ.

Knowledge. Buổi training dùng hóa đơn thật của chính công ty, không dùng dữ liệu demo. Bạn cố ý chọn cả những ca xấu như ảnh chụp mờ, hóa đơn hai trang, mã số thuế bị che, vì đó là những ca người dùng sẽ gặp ngay trong tuần đầu làm việc thật.

Ability. Tuần đầu sau go-live, mỗi người xử lý hóa đơn hằng ngày của mình trên hệ thống mới trong khi bạn ngồi cạnh. Bạn ghi lại từng lần ai đó định mở Excel ra. Mỗi lần như vậy là dấu hiệu có một chỗ hệ thống chưa khớp với cách công việc thực sự diễn ra.

Tryolabs mô tả mục tiêu của giai đoạn này đúng như vậy: gỡ bỏ ma sát giữa một hệ thống chạy được và cách mọi người thực sự làm việc.

Reinforcement. Sau 30 ngày, bạn xem lại log: ai còn xử lý qua hệ thống, ai đã bỏ, hàng đợi duyệt có bị dồn không. Bạn trao đổi với kế toán trưởng để đưa hệ thống vào quy trình chốt sổ chính thức, sao cho cách làm mới trở thành mặc định chứ không chỉ là một lựa chọn.

Người huấn luyện tiếp theo phải là người của khách hàng

Còn một rủi ro mà năm giai đoạn trên chưa xử lý, nên nó cần một nhánh việc chạy song song: bạn sẽ rời đi, và người mà bạn đã đào tạo kỹ nhất cũng có thể nghỉ việc.

Tin tuyển dụng FDE của Tungsten Automation đưa vào mô tả công việc các buổi train-the-trainer có mục tiêu và tài liệu kỹ thuật được viết riêng cho từng khách hàng. Lý do được nêu rõ: giảm mất kiến thức khi nhân sự phía khách hàng nghỉ việc.

Trong ca phòng kế toán, việc này có nghĩa là chọn hai người, chứ không phải một, và để chính họ đứng lớp hướng dẫn cho đồng nghiệp trong khi bạn chỉ ngồi nghe và bổ sung.

Tài liệu cũng cần viết cho đúng người đọc. Đừng viết README cho developer, hãy viết một trang “khi hóa đơn bị đẩy vào hàng đợi duyệt thì làm gì”, kèm ảnh chụp màn hình từ chính hệ thống của họ.

Tryolabs mô tả đích đến là tổ chức khách hàng có năng lực hơn và sở hữu trọn vẹn những gì đã được xây. Nếu sau khi bạn rời đi mà hệ thống không còn ai biết vận hành, nghĩa là bạn chưa bàn giao xong.

Bản kế hoạch một trang

Bảng dưới đây là template bạn có thể dùng ngay cho dự án tiếp theo. Cột quan trọng nhất là cột cuối, vì mỗi giai đoạn chỉ được coi là đạt khi có bằng chứng quan sát được.

Giai đoạn	Người dùng đang tự hỏi	Việc FDE làm	Bằng chứng đã đạt
Awareness	Tại sao phải đổi?	Để trưởng nhóm tự nói ra việc nào đang tốn công nhất	Người dùng tự nói ra được lý do bằng lời của họ
Desire	Mình được gì khi đổi?	Mời người dùng góp ý vào thiết kế	Người dùng chủ động mang ca khó tới thử
Knowledge	Dùng thế nào?	Training trên dữ liệu thật, có cả ca xấu	Mỗi người tự xử lý được một ca khó trong buổi học
Ability	Làm được trên việc thật không?	Ngồi cạnh trong tuần đầu, sửa chỗ còn ma sát	Hóa đơn hằng ngày được xử lý trên hệ thống mới
Reinforcement	Có quay lại cách cũ không?	Xem log sau 30 ngày, đưa vào quy trình chính thức	Không ai còn làm song song bằng Excel

Bốn lỗi hay gặp

Lỗi đầu tiên là coi go-live là vạch đích, nên toàn bộ thời gian dự án dồn hết cho code và không chừa lại tuần nào để ngồi cạnh người dùng. Lỗi thứ hai là training bằng dữ liệu demo sạch sẽ, khiến người dùng tự tin trên lớp rồi bị bất ngờ ngay khi gặp việc thật.

Lỗi thứ ba là nghĩ rằng gửi thông báo là đủ để người dùng hiểu vì sao phải đổi. Email từ ban giám đốc chỉ báo rằng sắp có thay đổi, còn lý do thì người dùng phải tự nói ra được bằng lời của mình. Lỗi thứ tư là chỉ dựa vào một “người dùng giỏi” duy nhất. Khi người đó nghỉ, toàn bộ kiến thức đi theo họ.

Với engineer đang muốn chuyển sang làm FDE, đây cũng là một lợi thế khi viết CV. Thay vì chỉ ghi “xây pipeline trích xuất hóa đơn”, hãy ghi thêm số người bạn đã onboard, số người vẫn dùng hệ thống sau 30 ngày, và việc bạn đã đào tạo ai để họ tự hướng dẫn tiếp cho đồng nghiệp.

Khi đọc JD, hãy để ý các cụm “user onboarding”, “change management” hay “train-the-trainer”. Tryolabs xếp onboarding người dùng và quản trị thay đổi vào phần việc của FDE, còn tin tuyển dụng của Tungsten Automation ghi thẳng train-the-trainer vào mô tả công việc. Vì thế, bạn nên chuẩn bị sẵn một câu chuyện cụ thể cho từng cụm.

Planisware gọi đào tạo là một phần của quản trị thay đổi, có tác động lớn tới cả mức chấp nhận của người dùng lẫn hiệu suất. Code giúp hệ thống của bạn chạy được, nhưng người dùng có tiếp tục dùng nó sau khi bạn rời đi hay không lại phụ thuộc vào phần việc này.