Một hệ thống được chọn kỹ, kiểm định cẩn thận, tích hợp đúng kỹ thuật. Sáu tháng sau, tỷ lệ sử dụng rất thấp.
Đây là mô hình thất bại phổ biến nhất, và nguyên nhân hầu như không bao giờ là công nghệ.
Vì sao người ta không dùng
Các lý do thực tế, xếp theo tần suất:
- Làm tăng thời gian làm việc thay vì giảm.
- Đòi thêm thao tác nhập liệu.
- Không hiểu vì sao nó đưa ra kết luận đó.
- Đã thấy nó sai vài lần và mất tin.
- Không được hỏi ý kiến khi thiết kế.
- Lợi ích thuộc về người khác — họ nhập liệu, người khác dùng dữ liệu.
- Không rõ dùng để làm gì.
Mục thứ sáu là nguyên nhân cấu trúc quan trọng: khi người chịu chi phí và người hưởng lợi là hai nhóm khác nhau, việc chấp nhận rất khó.
Nguyên tắc nền tảng
Hệ thống phải giảm việc cho chính người dùng nó.
Nếu không đạt được điều này, mọi biện pháp quản lý thay đổi chỉ trì hoãn thất bại.
Khi thiết kế, câu hỏi cần trả lời: người dùng hằng ngày được gì?
Nếu câu trả lời là "không được gì nhưng tổ chức được lợi", cần tìm cách đưa lợi ích về phía họ — ví dụ cho họ thấy dữ liệu của chính khoa mình, hoặc tự động hoá một việc khác mà họ đang phải làm tay.
Tham gia từ đầu
Đây là yếu tố có tác động lớn nhất và tốn ít chi phí nhất.
Người dùng nên tham gia từ khâu:
- Xác định vấn đề cần giải quyết.
- Đánh giá và chọn sản phẩm.
- Thiết kế cách tích hợp vào quy trình.
- Cấu hình quy tắc và ngưỡng.
- Thử nghiệm trước khi triển khai rộng.
Lợi ích kép: hệ thống được thiết kế phù hợp hơn với công việc thực tế, và người tham gia trở thành người ủng hộ tự nhiên.
Người dẫn dắt tại khoa
Mỗi khoa nên có một hoặc vài người đóng vai trò này. Tiêu chí chọn:
- Là người dùng thật, làm công việc hằng ngày.
- Được đồng nghiệp tin và hay được hỏi ý kiến.
- Quan tâm tới việc cải tiến.
- Không nhất thiết là người có chức vụ.
Vai trò của họ:
- Hỗ trợ đồng nghiệp tại chỗ — nhanh hơn nhiều so với gọi bộ phận kỹ thuật.
- Thu thập phản hồi.
- Là cầu nối hai chiều với nhóm dự án.
Điểm quan trọng: họ cần được dành thời gian chính thức cho việc này, không phải làm thêm ngoài công việc.
Đào tạo
Nội dung cần có
- Hệ thống làm gì và không làm gì.
- Nó hay sai ở tình huống nào.
- Hiệu năng tại chính cơ sở này, không phải con số trong tài liệu.
- Cách thao tác.
- Làm gì khi không đồng ý với kết quả.
- Báo lỗi ở đâu.
- Việc không được đánh dấu không có nghĩa là bình thường.
Hai mục về giới hạn thường bị bỏ qua trong đào tạo do nhà cung cấp thực hiện — vì họ không có động lực nhấn mạnh điểm yếu của sản phẩm.
Hình thức
- Ngắn, thực hành trên ca thật hoặc ca mô phỏng.
- Hỗ trợ tại chỗ trong tuần đầu.
- Tài liệu tra nhanh, không phải sổ tay dày.
- Đào tạo lại cho nhân viên mới — cần có trong quy trình nhận việc.
Mục cuối hay bị quên: sau một năm, tỷ lệ nhân viên chưa từng được đào tạo có thể khá cao.
Triển khai theo giai đoạn
- Thử nghiệm ở một khoa có người ủng hộ, với tiêu chí thành công định trước.
- Thu thập phản hồi và điều chỉnh.
- Mở rộng dần sang các khoa khác.
- Đánh giá lại sau mỗi bước.
Lợi thế: phát hiện vấn đề khi quy mô còn nhỏ, và khoa đầu tiên trở thành nơi tham chiếu cho các khoa sau.
Xử lý phản đối
Phản đối thường bị coi là trở ngại cần vượt qua. Cách nhìn hiệu quả hơn: nó là nguồn thông tin.
Phần lớn phản đối phản ánh vấn đề thật:
- Hệ thống thật sự làm tăng việc.
- Nó không phù hợp với quy trình thực tế.
- Có lo ngại chính đáng về chất lượng.
- Đã có trải nghiệm xấu với dự án trước.
Người phản đối mạnh nhất thường là người hiểu công việc rõ nhất. Lắng nghe họ thường cải thiện được sản phẩm.
Cách tiếp cận:
- Nghe trước khi phản bác.
- Tách phản đối về nguyên tắc với phản đối về cách thực hiện.
- Xử lý các vấn đề cụ thể một cách nhìn thấy được.
- Mời người phản đối tham gia vào việc cải thiện.
Vòng phản hồi
Yếu tố quyết định việc duy trì lâu dài:
- Kênh báo vấn đề dễ dùng, ngay trong hệ thống.
- Phản hồi lại cho người báo về những gì đã làm.
- Công bố các thay đổi thực hiện nhờ phản hồi.
- Rà soát định kỳ có sự tham gia của người dùng.
Mục thứ hai là mục quyết định. Khi người dùng thấy phản hồi của mình dẫn tới thay đổi thật, họ tiếp tục đóng góp. Khi không có gì xảy ra, họ ngừng.
Các chỉ số theo dõi việc chấp nhận
- Tỷ lệ người dùng thực tế so với số được cấp quyền.
- Tần suất sử dụng theo thời gian — có giảm dần không?
- Tỷ lệ bỏ qua gợi ý.
- Số lượng và nội dung phản hồi.
- Thời gian thao tác trung bình.
Chỉ số thứ hai là cảnh báo sớm tốt nhất: nếu sử dụng giảm dần sau tháng đầu, có vấn đề cần tìm hiểu ngay.
Một sai lầm phổ biến
Coi việc triển khai là dự án có ngày kết thúc.
Thực tế, việc duy trì là công việc liên tục: đào tạo nhân viên mới, điều chỉnh theo phản hồi, giám sát hiệu năng, rà soát định kỳ.
Nếu nguồn lực chỉ được bố trí cho giai đoạn triển khai, hệ thống sẽ dần xuống cấp sau khi nhóm dự án giải tán.
Câu hỏi thường gặp
Vì sao dự án thất bại thường không phải do công nghệ?
Vì một hệ thống không được dùng thì hiệu quả bằng không bất kể nó tốt tới đâu. Các lý do khiến người ta không dùng thường liên quan tới quy trình, khối lượng công việc và việc không được tham gia từ đầu.
Yếu tố nào quan trọng nhất để được chấp nhận?
Hệ thống phải giảm việc chứ không thêm việc cho người dùng. Nếu nó tạo thêm thao tác mà lợi ích thuộc về người khác, nó sẽ bị lách hoặc bỏ qua dù được lãnh đạo ủng hộ.
Vai trò của người dẫn dắt tại khoa là gì?
Họ là người dùng thật, được đồng nghiệp tin, hiểu cả công việc lâm sàng lẫn hệ thống mới. Họ hỗ trợ tại chỗ, thu thập phản hồi và là cầu nối hai chiều giữa khoa và nhóm dự án.
Nên xử lý phản đối thế nào?
Lắng nghe trước khi bác bỏ, vì phần lớn phản đối phản ánh vấn đề thật trong thiết kế hoặc quy trình. Người phản đối mạnh nhất thường là người hiểu công việc rõ nhất, và ý kiến của họ có giá trị cải thiện cao.