title: "Quản lý sự thay đổi (Change Management): Giúp khách hàng thích nghi với hệ thống mới"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 2 — Kỹ năng Thực chiến"
skill_number: 28
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "10 phút đọc"
tags:

• change-management
• adkar
• user-adoption
• stakeholder-management
• go-live

Quản lý sự thay đổi (Change Management): Giúp khách hàng thích nghi với hệ thống mới

Bạn đã bao giờ triển khai xong một hệ thống, mọi test case đều pass, khách hàng ký nghiệm thu, rồi ba tuần sau phát hiện nhân viên vận hành vẫn âm thầm dùng file Excel cũ song song? Đó không phải là lỗi kỹ thuật — đó là thất bại của quản lý sự thay đổi. Một hệ thống "go-live" thành công trên giấy tờ nhưng không ai chịu dùng thật thì coi như dự án chưa xong việc quan trọng nhất.

🎯 Kỹ thuật cốt lõi: Mô hình ADKAR

ADKAR là mô hình quản lý sự thay đổi do Prosci phát triển, tập trung vào cấp độ cá nhân — vì suy cho cùng, tổ chức chỉ thay đổi khi từng con người trong đó thay đổi. Mô hình gồm 5 trạng thái tuần tự, thiếu trạng thái nào thì thay đổi sẽ khựng lại ở đó:

Điểm mấu chốt của ADKAR: đây là chẩn đoán tuần tự. Khi một nhóm người dùng chống đối, việc đầu tiên không phải là đào tạo lại (Knowledge) hay ép dùng (Ability) — mà là chẩn đoán xem họ đang kẹt ở giai đoạn nào. Ép một người còn thiếu Desire phải luyện Ability chỉ khiến họ chống đối gay gắt hơn, vì bạn đang giải quyết sai vấn đề. BA/PO có thể dùng bảng này như một bộ câu hỏi phỏng vấn nhanh với từng nhóm người dùng để xác định điểm nghẽn trước khi chọn hành động can thiệp.

Bối cảnh (Situation)

Tình huống dưới đây là minh hoạ tổng hợp từ nhiều dự án triển khai hệ thống tại Việt Nam, không phải case cụ thể của một công ty có thật.

Một công ty phân phối hàng tiêu dùng quy mô vừa triển khai hệ thống quản lý kho và đơn hàng mới, thay thế cho quy trình cũ vốn chạy trên Excel kết hợp một phần mềm kế toán rời rạc. Dự án kéo dài 5 tháng, đã qua UAT (User Acceptance Test), khách hàng ký nghiệm thu giai đoạn 1, và go-live đúng deadline.

Chị H., BA của dự án, quay lại on-site sau go-live hai tuần theo lịch hỗ trợ hậu triển khai. Log hệ thống cho thấy: đội sales chỉ nhập khoảng 40% đơn hàng qua hệ thống mới, phần còn lại vẫn ghi vào Excel quen thuộc rồi nhờ một bạn thủ kho nhập hộ cuối ngày — công ty đang vận hành song song hai hệ thống, tốn công gấp đôi mà lãnh đạo không hề biết.

Khi chị H. hỏi han trực tiếp, nhóm nhân viên vận hành kho — đặc biệt là anh T., nhân viên kỳ cựu 8 năm phụ trách nhập xuất kho — tỏ ra không hợp tác. Anh T. nói thẳng: "Excel của tụi tôi làm 8 năm nay không sai bao giờ, giờ bắt học cái mới làm gì cho mất thời gian." Trưởng phòng vận hành thì im lặng, không phản đối ra mặt nhưng cũng không hề nhắc nhân viên phải đổi thói quen.

Thách thức (Task)

Cái khó ở đây không phải là kỹ thuật — hệ thống chạy đúng, UAT đã pass, không có bug nghiêm trọng. Cái khó là con người: một nhóm nhân viên vận hành có thâm niên cao, tự tin vào cách làm cũ, và không cảm thấy có động lực cá nhân nào để đổi.

Nếu chị H. xử lý sai ở đây — ví dụ báo cáo thẳng lên ban giám đốc khách hàng để "ép" nhân viên phải dùng, hoặc coi đây là vấn đề đào tạo và tổ chức thêm buổi training lặp lại nội dung cũ — thì rủi ro là:

• Nhân viên vận hành sẽ dùng hệ thống một cách đối phó (nhập cho có, dữ liệu sai lệch), khiến báo cáo tồn kho và công nợ từ hệ thống mới không đáng tin, làm mất luôn giá trị cốt lõi mà dự án hướng tới.
• Mâu thuẫn giữa BA/nhà cung cấp và đội vận hành khách hàng leo thang, ảnh hưởng đến các giai đoạn tiếp theo của dự án (công ty này còn kế hoạch mở rộng module CRM và báo cáo BI).
• Nếu đi con đường "mách lãnh đạo ép nhân viên", chị H. thắng trận này nhưng mất lòng tin của đội vận hành — nhóm mà chị còn phải làm việc cùng suốt vòng đời hệ thống.

Vấn đề thật sự không phải "họ không biết dùng" mà là hỗn hợp của nhận thức mơ hồ, thiếu động lực cá nhân, và chưa hình thành thói quen mới đủ vững để thắng thói quen cũ 8 năm.

Hành động (Action)

Chị H. quyết định không vội tổ chức lại training. Cô áp dụng ADKAR như một quy trình chẩn đoán và can thiệp theo từng bước.

Bước 1 — Chẩn đoán điểm nghẽn bằng phỏng vấn ngắn (xác định A-D-K-A-R đang kẹt ở đâu)

Chị H. dành nửa ngày phỏng vấn riêng từng nhân viên kho và 2 nhân viên sales, hỏi theo đúng cấu trúc 5 câu tương ứng 5 giai đoạn ADKAR (không hỏi "sao anh không dùng hệ thống" — câu đó chỉ ra câu trả lời phòng thủ):

• "Anh hiểu vì sao công ty đổi từ Excel sang hệ thống mới không?" → anh T. và nhóm kho hiểu mơ hồ, nghĩ đây là quyết định "trên ép xuống", không biết Excel từng gây 2 lần giao thiếu hàng cho khách lớn tháng trước vì tồn kho không đồng bộ real-time.
• "Việc dùng hệ thống mới có giúp gì cho công việc hàng ngày của anh không?" → anh T.: "không thấy lợi gì, chỉ thấy phải gõ nhiều hơn." → thiếu Desire.
• "Anh có tự tin làm hết các thao tác nhập xuất kho trên hệ thống mới không?" → nhân viên trẻ tự tin, riêng anh T. nói "cái cơ bản thì được, hàng trả lại thì chưa chắc" → thiếu Knowledge ở nghiệp vụ khó.
• Quan sát thao tác thực tế: nhập một đơn mất 4 phút trên hệ thống mới so với 1 phút trên Excel → thiếu Ability.
• Không ai theo dõi số liệu sử dụng hàng ngày, trưởng phòng cũng không nhắc → thiếu Reinforcement hoàn toàn.

Kết quả chẩn đoán: nhóm kho kẹt đồng thời ở cả 5 giai đoạn, nhưng nặng nhất là Awareness và Desire — nghĩa là vấn đề gốc không phải kỹ năng, mà là chưa ai cho họ thấy lý do thật và lợi ích thật.

Bước 2 — Xử lý Awareness: kể lại câu chuyện bằng hậu quả cụ thể, không bằng khẩu hiệu

Thay vì nhắc lại slide "chuyển đổi số là xu thế tất yếu", chị H. đề xuất trưởng phòng vận hành tổ chức một buổi 30 phút, dùng chính 2 sự cố giao thiếu hàng tháng trước làm ví dụ: chỉ ra rằng vì Excel cập nhật tồn kho trễ một ngày, sales đã báo còn hàng cho khách trong khi kho đã hết, dẫn đến khách phàn nàn và một đơn hàng bị huỷ. Bà giải thích hệ thống mới giải quyết đúng lỗ hổng đó bằng dữ liệu tồn kho real-time.

Bước 3 — Xử lý Desire: gắn thay đổi với lợi ích cá nhân, không chỉ lợi ích công ty

Chị H. làm việc riêng với anh T. để tìm ra điểm đau cá nhân: hoá ra cuối tháng anh T. phải thức khuya đối chiếu công nợ giữa Excel kho và phần mềm kế toán vì hai bên lệch số. Chị chỉ cho anh thấy tính năng đối chiếu tự động của hệ thống mới sẽ loại bỏ chính công việc thức khuya đó. Đây là điểm bấm đúng — lợi ích không trừu tượng mà chạm vào nỗi khổ có thật của anh T.

Bước 4 — Xử lý Knowledge và Ability: đào tạo lại nhưng đổi cách, tập trung vào tình huống khó và luyện tập thực chiến

Thay vì lặp lại buổi training tổng quát cũ, chị H. tổ chức 3 buổi ngắn 45 phút, mỗi buổi chỉ xử lý một nhóm nghiệp vụ khó (hàng trả lại, điều chỉnh tồn kho, xuất kho theo lô). Mỗi buổi kết thúc bằng việc từng nhân viên tự thao tác trên dữ liệu thật của chính họ, có chị H. đứng cạnh sửa lỗi tại chỗ — không xem demo, mà tự tay làm đến khi nhanh dần lên.

Bước 5 — Xử lý Reinforcement: thiết lập cơ chế theo dõi và ghi nhận sau go-live

Chị H. đề xuất và cùng trưởng phòng vận hành thiết lập một báo cáo tỷ lệ nhập liệu qua hệ thống (so với qua Excel) gửi hàng ngày trong 3 tuần đầu, để trưởng phòng chủ động nhắc nhân viên còn làm song song. Đồng thời, chị đề nghị trưởng phòng công khai ghi nhận anh T. — người có thâm niên cao nhất — khi anh chuyển hẳn sang hệ thống mới trong buổi họp giao ban tuần, biến anh từ người cản trở thành hình mẫu để nhân viên trẻ noi theo.

Kết quả (Result)

Sau 4 tuần áp dụng quy trình ADKAR có chủ đích, tỷ lệ nhập đơn hàng và xuất kho qua hệ thống mới tăng từ 40% lên khoảng 85%. Anh T. trở thành người hướng dẫn lại cho 2 nhân viên mới vào — một sự đảo ngược vai trò khá bất ngờ so với hai tuần trước đó.

Điều chưa hoàn hảo: vẫn còn khoảng 15% giao dịch, chủ yếu là các trường hợp hàng lỗi/trả về phức tạp, được xử lý ngoài hệ thống rồi nhập bù sau — vì nghiệp vụ này có nhiều ngoại lệ mà hệ thống chưa cấu hình đủ linh hoạt. Chị H. ghi nhận đây là backlog cần cải tiến ở giai đoạn 2, không che giấu con số này khi báo cáo lên ban giám đốc khách hàng và team dự án nội bộ. Bài học lớn nhất chị rút ra: nếu áp dụng ADKAR ngay từ tuần đầu triển khai (thay vì đợi đến sau go-live hai tuần mới phát hiện vấn đề), có thể đã tránh được giai đoạn "chạy song song" gây lãng phí công sức và rủi ro sai lệch dữ liệu.

📋 Áp dụng ngay

• Trước mỗi lần triển khai thay đổi hệ thống/quy trình, tự hỏi 5 câu ADKAR cho từng nhóm người dùng chính — đừng giả định "cứ đào tạo là xong".
• Khi gặp người dùng chống đối, đừng vội ép hoặc đào tạo lại ngay — dành thời gian phỏng vấn ngắn để xác định họ đang kẹt ở giai đoạn nào trong 5 giai đoạn.
• Luôn tìm một lợi ích cá nhân cụ thể (không phải lợi ích công ty chung chung) để gắn vào lý do thay đổi cho từng nhóm/từng cá nhân chủ chốt.
• Thiết lập cơ chế theo dõi mức độ sử dụng thực tế (dashboard/report đơn giản) trong ít nhất 3-4 tuần đầu sau go-live — đừng coi go-live là điểm kết thúc dự án.
• Tìm và ghi nhận công khai ít nhất một "người ảnh hưởng" trong nhóm người dùng chuyển đổi thành công sớm, để họ trở thành đòn bẩy lan toả tự nhiên.

💡 Bài học đúc rút (Key Takeaway): Go-live không phải là đích đến của quản lý sự thay đổi, mà là điểm khởi đầu của nó — hệ thống chạy đúng chỉ chứng minh năng lực kỹ thuật, còn con người có thật sự đổi thói quen hay không mới quyết định dự án có thành công. Khi người dùng chống đối, đừng hỏi "sao họ không chịu học", hãy hỏi "họ đang thiếu Awareness, Desire, Knowledge, Ability hay Reinforcement" — vì mỗi câu trả lời đòi một cách can thiệp hoàn toàn khác nhau.

🔗 Kỹ năng liên quan

• Cách tổ chức các buổi Review/Demo — nền tảng để người dùng nhìn thấy giá trị hệ thống trước khi go-live, hỗ trợ giai đoạn Awareness/Desire sớm hơn.
• Cách xử lý các bên liên quan (Stakeholder Management) — kỹ thuật xác định và tác động đúng người có ảnh hưởng, bổ trợ cho bước tìm "người ảnh hưởng" trong ADKAR.
• Tư duy chịu trách nhiệm (Ownership) — tinh thần theo sát dự án đến khi người dùng thật sự áp dụng, không dừng ở nghiệm thu.

Bài trước: Cách tổ chức các buổi Review/Demo · Bài tiếp theo: Sử dụng dữ liệu để đàm phán