Mở đầu — vì sao bài này quan trọng
Trong suốt khóa học này, bạn đã học cách vẽ As-Is, thiết kế To-Be, tối ưu quy trình, thậm chí tự động hóa bằng BPMN. Nhưng có một sự thật phũ phàng mà rất nhiều nhà phân tích quy trình học được theo cách đau đớn: một quy trình To-Be hoàn hảo trên giấy vẫn có thể thất bại hoàn toàn khi triển khai, không phải vì bản thiết kế sai, mà vì con người không chịu thay đổi cách họ làm việc.
Theo các nghiên cứu kinh điển của McKinsey và Prosci, khoảng 70% các sáng kiến chuyển đổi (transformation) không đạt mục tiêu đề ra. Và lý do số một không phải là công nghệ kém hay quy trình thiết kế tồi — mà là yếu tố con người: nhân viên kháng cự, quản lý cấp trung lặng lẽ phá hoại, hoặc đơn giản là không ai biết cách vận hành quy trình mới.
Đây chính là khoảng trống mà Process Change Management lấp đầy. Một Business Process Analyst giỏi không chỉ tối ưu được luồng công việc, mà còn biết cách dẫn dắt con người đi qua sự thay đổi. Và công cụ nền tảng để làm điều đó — đơn giản, dễ nhớ, dễ áp dụng — chính là mô hình ADKAR do Jeff Hiatt (sáng lập Prosci) phát triển. Bài học này sẽ dạy bạn dùng ADKAR như một tấm bản đồ chẩn đoán: mỗi khi một sáng kiến cải tiến quy trình bị "kẹt", bạn sẽ biết chính xác nó kẹt ở đâu và phải làm gì để gỡ.
Khái niệm cốt lõi
ADKAR là một mô hình thay đổi lấy cá nhân làm trung tâm (individual change model). Triết lý nền tảng của nó rất quan trọng để bạn hiểu đúng: tổ chức không thay đổi — chỉ có từng cá nhân trong tổ chức thay đổi. Nếu bạn muốn 200 nhân viên áp dụng quy trình mới, bạn phải giúp 200 con người, từng người một, đi qua đúng năm cột mốc. Tổng thay đổi của tổ chức chỉ là tổng các thay đổi cá nhân thành công.
ADKAR là viết tắt của năm giai đoạn, và điều mấu chốt là chúng diễn ra theo trình tự. Bạn không thể nhảy cóc. Nếu một người chưa có Awareness thì việc bồi đắp Desire là vô nghĩa; nếu chưa có Desire thì dù bạn đào tạo Knowledge bao nhiêu cũng đổ sông đổ biển.
A — Awareness (Nhận thức cần thay đổi)
Đây là giai đoạn trả lời câu hỏi "Tại sao?". Nhân viên phải hiểu lý do tại sao phải thay đổi, điều gì sẽ xảy ra nếu không thay đổi, và rủi ro của việc giữ nguyên hiện trạng. Lưu ý: Awareness không phải là "tôi biết có dự án đổi quy trình" — mà là "tôi hiểu vì sao quy trình cũ không còn ổn và vì sao việc này cấp bách". Thiếu Awareness, mọi thông báo đều bị coi là "lại một sáng kiến nữa của sếp rồi cũng quên".
D — Desire (Mong muốn tham gia và ủng hộ)
Đây là giai đoạn khó nhất và mang tính cá nhân nhất, trả lời câu hỏi "What's in it for me?" (Tôi được gì?). Một người có thể hoàn toàn hiểu lý do thay đổi (Awareness) nhưng vẫn không muốn tham gia, vì sợ mất việc, mất quyền lực, mất sự thoải mái, hoặc đơn giản là không tin lãnh đạo. Desire không thể ép buộc — bạn chỉ có thể tạo điều kiện để nó nảy sinh. Đây là nơi vai trò của quản lý trực tiếp (line manager) và nhà tài trợ (sponsor) trở nên quyết định.
K — Knowledge (Kiến thức về cách thay đổi)
Trả lời câu hỏi "Làm thế nào?". Bao gồm hai loại kiến thức: (1) kiến thức về cách làm trong trạng thái mới — ví dụ thao tác trên hệ thống mới, các bước của quy trình To-Be; và (2) kiến thức về cách chuyển đổi — ví dụ trong giai đoạn chạy song song thì xử lý hồ sơ cũ ra sao. Đây là giai đoạn của đào tạo, tài liệu hướng dẫn, và coaching.
A — Ability (Khả năng thực hiện trên thực tế)
Trả lời câu hỏi "Tôi có thực sự làm được không?". Đây là sự khác biệt tinh tế nhưng cực kỳ quan trọng giữa biết và làm được. Bạn có thể đọc xong sách dạy bơi (Knowledge) nhưng nhảy xuống nước vẫn chìm (thiếu Ability). Ability đạt được qua thực hành thật, có người kèm cặp, có thời gian để mắc lỗi và sửa. Nhiều dự án "đào tạo xong là xong" thất bại chính ở đây.
R — Reinforcement (Củng cố để duy trì)
Trả lời câu hỏi "Làm sao để thay đổi không bị trôi ngược?". Bản chất con người là quay về thói quen cũ khi áp lực giảm. Reinforcement gồm ghi nhận, khen thưởng, đo lường tuân thủ (compliance), thu thập phản hồi, và xử lý những điểm còn vướng. Thiếu Reinforcement, sau ba tháng bạn sẽ thấy nhân viên lén dùng lại file Excel cũ thay vì hệ thống mới.
ADKAR như một công cụ chẩn đoán
Sức mạnh thực sự của ADKAR nằm ở chỗ nó là mô hình tuần tự dạng "mắt xích yếu nhất". Khi một sáng kiến gặp trục trặc, bạn không hỏi chung chung "tại sao thất bại", mà đi từ A đến R để tìm rào cản đầu tiên (barrier point). Nếu nhân viên không dùng quy trình mới, hãy hỏi: Họ có hiểu vì sao cần đổi không (A)? Có muốn không (D)? Có biết cách không (K)? Có làm được không (Ability)? Có ai củng cố không (R)? Mắt xích yếu đầu tiên chính là nơi bạn cần dồn nguồn lực — chứ không phải đào tạo thêm khi vấn đề thực ra nằm ở Desire.
Tình huống thực tế
Ví dụ 1 — Ngân hàng triển khai quy trình phê duyệt tín dụng số (kẹt ở Desire)
Một ngân hàng thương mại cổ phần tại TP.HCM (gọi là Bank A) triển khai quy trình phê duyệt khoản vay tiêu dùng mới: chuyển từ luân chuyển hồ sơ giấy sang luồng số hóa trên hệ thống BPM, dự kiến giảm thời gian phê duyệt từ 5 ngày xuống còn 1,5 ngày. Đội dự án đào tạo rất bài bản: 12 lớp, tài liệu dày 60 trang, video hướng dẫn. Sau hai tháng go-live, chỉ 40% chuyên viên thẩm định thực sự dùng hệ thống; số còn lại vẫn in hồ sơ ra ký tay rồi nhập sau.
Diễn giải: Đội dự án mặc định rằng vấn đề là thiếu Knowledge nên dồn toàn lực vào đào tạo. Nhưng khi khảo sát theo ADKAR, họ phát hiện điểm kẹt thực sự là Desire. Lý do: hệ thống mới ghi lại dấu vết mọi quyết định và thời gian xử lý của từng chuyên viên — nhiều người sợ điều này sẽ phơi bày việc họ "linh động" cho khách quen, và lo bị đánh giá năng suất khắt khe hơn. Awareness có, Knowledge có, nhưng Desire âm.
Bài học rút ra: Đào tạo thêm sẽ vô ích khi rào cản nằm ở Desire. Ban lãnh đạo phải xử lý ở đúng tầng: minh bạch rằng dữ liệu dùng để cải thiện quy trình chứ không phải để "soi" nhân viên, gắn KPI mới công bằng, và để các trưởng nhóm — người nhân viên tin tưởng — trực tiếp giải thích "cái lợi cho anh em". Sau khi tái định vị thông điệp này, tỷ lệ áp dụng lên 88% trong sáu tuần.
Ví dụ 2 — Công ty sản xuất chuyển sang quy trình kiểm soát chất lượng số (kẹt ở Ability)
Một nhà máy sản xuất linh kiện điện tử FDI tại Bắc Ninh (gọi là VietTech Manufacturing) thay quy trình ghi nhận lỗi sản phẩm từ sổ tay sang ứng dụng tablet ngay tại dây chuyền. Công nhân hiểu rõ lý do (giảm sai sót truy xuất nguồn gốc — Awareness tốt), thật sự muốn dùng vì app nhanh hơn viết tay (Desire tốt), và đã được dạy đầy đủ các thao tác (Knowledge tốt). Vậy mà sau go-live, tốc độ ghi nhận lỗi chậm hơn cách cũ, năng suất dây chuyền tụt 8%.
Diễn giải: Điểm kẹt là Ability. Công nhân biết phải bấm nút nào, nhưng trong môi trường thực — đeo găng tay, ánh sáng xưởng, áp lực nhịp dây chuyền 30 giây/sản phẩm — họ không làm được trơn tru. Thao tác trong lớp học khác hẳn thao tác giữa tiếng máy ồn ào. Đây đúng là khoảng cách kinh điển giữa Knowledge và Ability.
Bài học rút ra: Nhà máy bổ sung hai tuần "đi kèm" (floor coaching): mỗi ca có một super-user đứng cạnh hỗ trợ tại chỗ, đồng thời tinh chỉnh giao diện app cho nút to hơn, dùng được khi đeo găng. Họ cũng cố ý đặt mục tiêu năng suất thấp hơn trong giai đoạn học (cho phép mắc lỗi). Sau ba tuần, tốc độ ghi nhận vượt cách cũ 25%. Bài học: Ability cần thời gian thực hành thật, không thể rút gọn bằng cách dạy kỹ hơn.
Ví dụ 3 — Thay đổi trôi ngược vì thiếu Reinforcement
Một chuỗi bán lẻ tại Việt Nam (gọi là RetailCo) triển khai quy trình duyệt đề xuất nhập hàng mới qua hệ thống workflow, thay cho việc gửi email và gọi điện. Ba tháng đầu mọi thứ tuyệt vời — tỷ lệ tuân thủ 95%, đội dự án ăn mừng, sponsor chuyển sự chú ý sang dự án khác, các super-user được rút về vị trí cũ. Đến tháng thứ năm, kiểm tra lại thì chỉ còn 50% đề xuất đi qua hệ thống; phần còn lại lại "gọi điện cho nhanh".
Diễn giải: Cả bốn giai đoạn A-D-K-A đều đã hoàn thành tốt, nhưng tổ chức bỏ quên giai đoạn cuối — Reinforcement. Khi không còn ai đo lường, không còn ai nhắc, không có khen thưởng cho người làm đúng cũng không có hệ quả cho người làm tắt, lực hấp dẫn của thói quen cũ kéo mọi người quay về.
Bài học rút ra: Thay đổi không phải một sự kiện (go-live) mà là một trạng thái cần được duy trì. RetailCo khắc phục bằng cách đưa "tỷ lệ đề xuất qua hệ thống" vào dashboard hằng tuần của trưởng phòng mua hàng, công khai vinh danh nhóm tuân thủ cao, và quy định những đề xuất ngoài hệ thống sẽ không được giải ngân. Reinforcement phải được lên kế hoạch ngay từ đầu, không phải xử lý khi đã trôi ngược.
Hướng dẫn từng bước
Dưới đây là cách áp dụng ADKAR vào một dự án thay đổi quy trình thực tế, từ lúc lập kế hoạch đến lúc duy trì.
Bước 1 — Xác định chính xác sự thay đổi. Viết ra một câu rõ ràng: "Chuyển từ [trạng thái As-Is] sang [trạng thái To-Be]". Càng cụ thể, bạn càng dễ truyền thông và đo lường. Mơ hồ kiểu "số hóa quy trình" sẽ khiến mọi giai đoạn ADKAR sau đó cũng mơ hồ.
Bước 2 — Xác định nhóm bị ảnh hưởng và đánh giá ADKAR ban đầu. Liệt kê các nhóm đối tượng (chuyên viên, quản lý trực tiếp, bộ phận hỗ trợ...). Với mỗi nhóm, chấm điểm hiện trạng từng giai đoạn ADKAR theo thang 1–5. Điểm này cho bạn biết khoảng cách cần lấp ở mỗi giai đoạn.
Bước 3 — Lập kế hoạch cho từng giai đoạn:
- Awareness: chuẩn bị thông điệp "tại sao" — gắn với áp lực kinh doanh thật (chi phí, thời gian, rủi ro). Người truyền tải lý tưởng nhất là sponsor cấp cao.
- Desire: nhận diện nguồn kháng cự cho từng nhóm, thiết kế câu trả lời "tôi được gì", trao quyền cho line manager trò chuyện 1-1.
- Knowledge: thiết kế đào tạo, tài liệu, job aid sát với công việc thực.
- Ability: lên kế hoạch thực hành có hướng dẫn, coaching tại chỗ, giai đoạn chạy thử cho phép mắc lỗi.
- Reinforcement: định nghĩa chỉ số tuân thủ, cơ chế ghi nhận/khen thưởng, lịch kiểm tra định kỳ.
Bước 5 — Đo lường và tìm rào cản. Sau triển khai, nếu kết quả chưa đạt, dùng ADKAR chẩn đoán: đi từ A đến R, tìm giai đoạn đầu tiên có điểm thấp. Đó là nơi bạn can thiệp — không phải nơi bạn đoán.
Bước 6 — Duy trì Reinforcement. Đừng tuyên bố thắng lợi quá sớm. Giữ đo lường và ghi nhận ít nhất vài tháng sau go-live.
Lỗi thường gặp & mẹo
Lỗi 1 — Cho rằng mọi vấn đề đều là vấn đề đào tạo. Đây là lỗi phổ biến nhất. Khi nhân viên không dùng quy trình mới, phản xạ là "đào tạo thêm". Nhưng như Ví dụ 1, rào cản thật có thể là Desire. Mẹo: Luôn chẩn đoán theo trình tự A→D→K→A→R trước khi quyết định hành động.
Lỗi 2 — Nhảy thẳng vào Knowledge mà bỏ qua Awareness và Desire. Đào tạo cho người chưa muốn thay đổi là lãng phí. Mẹo: Coi A và D là "đất nền"; chưa làm móng vững thì đừng xây nhà.
Lỗi 3 — Nhầm Knowledge với Ability. "Đào tạo xong = triển khai xong" là cái bẫy chết người. Mẹo: Luôn dành ngân sách và thời gian cho coaching tại chỗ sau đào tạo; đo lường khả năng làm thật, không chỉ điểm bài kiểm tra.
Lỗi 4 — Bỏ quên Reinforcement sau go-live. Ăn mừng quá sớm khiến thay đổi trôi ngược. Mẹo: Lên kế hoạch Reinforcement ngay từ đầu dự án, không phải sau khi đã thấy tụt dốc.
Lỗi 5 — Để mỗi đội dự án (Process Analyst) gánh hết. ADKAR cần đúng người ở đúng vai: sponsor cấp cao tạo Awareness; quản lý trực tiếp nuôi Desire và Reinforcement; đội dự án/đào tạo lo Knowledge và Ability. Mẹo: Map rõ ai chịu trách nhiệm cho giai đoạn nào — đây cũng là cầu nối tới RACI mà bạn sẽ học sâu hơn ở các bài sau.
Mẹo tổng quát: ADKAR mạnh nhất khi dùng làm ngôn ngữ chung. Khi cả nhóm dùng chung từ vựng "vấn đề này là D hay K?", các cuộc họp xử lý kháng cự trở nên cụ thể và bớt cảm tính.
Bài tập thực hành
Bài tập 1 — Chẩn đoán rào cản. Một phòng kế toán được yêu cầu chuyển từ duyệt chi phí qua email sang quy trình workflow tự động. Sau một tháng, 60% nhân viên vẫn gửi email. Khi hỏi, họ nói: "Tôi biết hệ thống tồn tại, tôi cũng đồng ý nó tốt hơn, tôi đã được đào tạo, nhưng mỗi lần vào hệ thống tôi loay hoay mãi không tìm được nút nộp đúng loại chứng từ." Hãy xác định: rào cản nằm ở giai đoạn ADKAR nào? Bạn sẽ đề xuất hành động gì (không phải đào tạo lại từ đầu)?
Bài tập 2 — Lập kế hoạch ADKAR. Chọn một thay đổi quy trình bạn từng trải qua (ở công ty, trường học, hoặc một dự án giả định như "chuyển cả lớp từ nộp bài giấy sang nộp online"). Viết một bảng 5 dòng, mỗi dòng một giai đoạn ADKAR, ghi rõ: hành động cụ thể bạn sẽ làm và ai chịu trách nhiệm chính cho giai đoạn đó.
Bài tập 3 — Đánh giá rủi ro trôi ngược. Với cùng thay đổi ở Bài tập 2, hãy liệt kê ba dấu hiệu cảnh báo cho thấy thay đổi đang trôi ngược, và ba biện pháp Reinforcement bạn sẽ triển khai để ngăn điều đó. Suy nghĩ xem chỉ số nào bạn có thể đưa lên dashboard để theo dõi tuần.
Tóm tắt
Process Change Management là phần "con người" của việc cải tiến quy trình — và thường là phần quyết định thành bại, vì khoảng 70% sáng kiến chuyển đổi thất bại do yếu tố con người chứ không phải kỹ thuật. ADKAR là mô hình lấy cá nhân làm trung tâm, dựa trên triết lý rằng tổ chức không thay đổi mà chỉ từng cá nhân thay đổi, qua năm cột mốc tuần tự:
- Awareness — hiểu tại sao phải thay đổi.
- Desire — muốn tham gia, trả lời "tôi được gì".
- Knowledge — biết cách làm trong trạng thái mới.
- Ability — thực sự làm được trên thực tế (khác với chỉ biết).
- Reinforcement — củng cố để thay đổi không trôi ngược.