Làm sao biết phần mềm đang mang lại hiệu quả?
Sau một thời gian sử dụng phần mềm mới, doanh nghiệp thường muốn biết khoản đầu tư đó đã giúp ích đến đâu. Hệ thống có nhiều tài khoản và nhân viên đăng nhập hằng ngày, nhưng khách hàng có được phục vụ sớm hơn không? Những việc từng phải làm thủ công đã giảm bớt, hay chỉ chuyển sang một màn hình khác?
Để trả lời, người quản lý cần nhìn vào thay đổi trong công việc mà phần mềm được kỳ vọng hỗ trợ. Bạn không cần bắt đầu bằng một báo cáo phức tạp; điều cần làm trước là xác định vấn đề muốn giải quyết và cách nhận biết vấn đề đó đã cải thiện.
Hãy lấy một tình huống giả định: nhóm chăm sóc khách hàng đưa vào sử dụng cổng tiếp nhận yêu cầu, thay cho việc tổng hợp email và tin nhắn. Mục tiêu là hạn chế bỏ sót và phản hồi khách hàng sớm hơn. Ví dụ này sẽ được dùng xuyên suốt bài; đây không phải kết quả dự án của Fenix.
1. Bắt đầu từ điều doanh nghiệp muốn thay đổi
Với cổng tiếp nhận yêu cầu, số lượt đăng nhập cho biết hệ thống có người dùng, nhưng chưa đủ để kết luận nhóm đang phục vụ khách hàng tốt hơn. Nếu nhân viên phải đăng nhập nhiều lần để sửa thông tin, con số này tăng lên còn có thể phản ánh một bất tiện.
Thay vì tổng hợp mọi dữ liệu có sẵn, hãy quay lại mục tiêu ban đầu. Nếu muốn phản hồi sớm hơn, cần theo dõi thời gian khách hàng chờ phản hồi đầu tiên. Nếu muốn hạn chế bỏ sót, cần thống nhất thế nào là một yêu cầu bị bỏ sót và cách phát hiện nó.
Từ mỗi mục tiêu, doanh nghiệp có thể chọn vài chỉ số phù hợp, rồi kết hợp với ý kiến của người trực tiếp sử dụng. Dữ liệu cho biết điều gì đang thay đổi; trao đổi với người dùng giúp tìm hiểu vì sao thay đổi đó xảy ra.
| Điều muốn biết | Chỉ số có thể xem | Thông tin cần đối chiếu |
|---|---|---|
| Khách hàng có được phản hồi sớm hơn? | Thời gian đến phản hồi đầu tiên của nhân viên | Loại yêu cầu, lịch làm việc và thời gian chờ ở từng bước |
| Yêu cầu có ít bị bỏ sót hơn? | Tỷ lệ yêu cầu chưa được xử lý trong thời hạn đã thống nhất | Cùng định nghĩa về yêu cầu bị bỏ sót, cùng phạm vi kênh tiếp nhận |
| Nhân viên có bớt nhập lại thông tin? | Thời gian thao tác và số trường hợp phải sửa hoặc nhập lại | Cả công sức kiểm tra và xử lý bổ sung |
| Công việc đã chuyển sang hệ thống mới chưa? | Tỷ lệ yêu cầu thuộc phạm vi triển khai được ghi nhận trên cổng | Những yêu cầu vẫn nằm ở email hoặc bảng tính và lý do |
Khi đã chọn chỉ số, cần ghi rõ cách tính và nguồn dữ liệu. Chẳng hạn, “thời gian phản hồi” được tính từ lúc khách gửi yêu cầu đến lúc nhận thông báo tự động, hay đến khi nhân viên trả lời nội dung? Nếu mục tiêu là hỗ trợ khách sớm hơn, hai cách tính này không thể dùng thay cho nhau.
Nếu doanh nghiệp chưa xác định rõ phần mềm cần cải thiện bước nào, nên xem lại quy trình trước khi chọn thêm chỉ số.
2. So sánh trước–sau thế nào cho có ý nghĩa?
Để biết công việc đã thay đổi ra sao, cần có thông tin về cách làm trước đây làm mốc đối chiếu. Tốt nhất là chuẩn bị từ trước khi triển khai: ghi nhận thời gian xử lý, số việc phải làm lại hoặc tình trạng tồn đọng theo cùng cách sẽ dùng sau này. Việc theo dõi lặp lại theo thời gian cũng giúp nhận ra xu hướng thay vì chỉ nhìn một kết quả riêng lẻ. [2]
Nếu phần mềm đã vận hành mà dữ liệu cũ không đầy đủ, bạn vẫn có thể bắt đầu. Hãy ghi rõ phần nào chưa có căn cứ so sánh, thiết lập mốc đo hiện tại và theo dõi những lần điều chỉnh tiếp theo. Không nên ước lượng một con số “trước đây” chỉ để tạo ra tỷ lệ cải thiện.
Điều kiện so sánh cũng cần tương đối tương đồng. Với nhóm chăm sóc khách hàng, tuần ít yêu cầu sẽ khác tuần chạy chiến dịch; một câu hỏi đơn giản cũng khác một khiếu nại cần nhiều bộ phận phối hợp. Vì vậy, khi xem kết quả, nên đối chiếu cả khối lượng và loại yêu cầu, số người xử lý, cũng như thay đổi về lịch trực hoặc quy trình.
Giả sử thời gian phản hồi giảm sau khi mở cổng mới, nhưng doanh nghiệp đồng thời bổ sung nhân viên. Đây là tín hiệu tích cực, song chưa đủ để quy toàn bộ kết quả cho phần mềm. Báo cáo cần nêu cả hai thay đổi để người đọc hiểu đúng.
Trong giai đoạn đầu, người dùng còn đang làm quen và một số công việc có thể được thực hiện song song trên hệ thống cũ. Nên ghi nhận riêng giai đoạn chuyển tiếp này. Thời điểm đánh giá cần phù hợp với chu kỳ công việc và mức độ ổn định thực tế, thay vì mặc định mọi phần mềm đều phải chứng minh hiệu quả sau cùng một số ngày.
3. Thời gian tiết kiệm có đồng nghĩa với giảm chi phí?
Nếu cổng mới giúp nhân viên bớt nhập lại dữ liệu, đó là một lợi ích đáng ghi nhận. Tuy nhiên, cần xem cả những việc mới phát sinh, chẳng hạn kiểm tra thông tin, sửa dữ liệu hoặc hỗ trợ người dùng, để biết tổng công sức có thực sự giảm hay không.
Ví dụ tính toán giả định: một thao tác giảm từ 10 phút xuống 6 phút, với 300 lượt công việc tương đương trong kỳ. Phần thời gian giảm ở thao tác đó là 1.200 phút, tương đương 20 giờ. Nếu phát sinh thêm 5 giờ kiểm tra và hỗ trợ liên quan, phần thời gian tiết kiệm ròng theo giả định này còn 15 giờ.
Con số 15 giờ không tự động có nghĩa là doanh nghiệp đã giảm được một khoản tiền lương. Nhân viên có thể dùng thời gian đó để xử lý việc tồn, phục vụ thêm khách hàng hoặc làm những việc cần chuyên môn. Khi trình bày lợi ích, cần nói rõ nguồn lực được giải phóng đã được sử dụng như thế nào.
Nếu muốn đánh giá bằng tiền, hãy thống nhất phạm vi và kỳ đánh giá, rồi tính cả chi phí liên quan như phát triển, phí sử dụng, hạ tầng, đào tạo và bảo trì trong phạm vi đó. Với lợi ích chưa thể quy đổi đáng tin cậy, nên trình bày riêng bằng thời gian hoặc chất lượng công việc thay vì gán một giá trị tiền thiếu căn cứ.
4. Dùng kết quả để quyết định việc tiếp theo
Mục đích của việc đo lường là giúp doanh nghiệp biết nên làm gì sau đó. Nếu số yêu cầu được ghi nhận tăng nhưng khách vẫn chờ lâu, có thể cổng tiếp nhận đã làm tốt việc tập hợp thông tin, trong khi bước phân công hoặc phê duyệt vẫn đang gây chậm.
Lúc này, người phụ trách nên xem một số trường hợp cụ thể và trao đổi với người xử lý, thay vì vội kết luận rằng cần thay phần mềm. Nếu người dùng vẫn giữ bảng tính riêng, hãy tìm hiểu họ đang thiếu thông tin hay chức năng nào. Nếu công việc chậm đúng lúc hệ thống gặp lỗi hoặc kết nối gián đoạn, cần phối hợp với đội kỹ thuật để kiểm tra. Theo dõi cả kết quả nghiệp vụ và tình trạng vận hành sẽ giúp việc trao đổi có cơ sở hơn. [3]
Mỗi lần rà soát nên chốt được vấn đề cần ưu tiên, người phụ trách và thời điểm xem lại kết quả. Ví dụ, hai bên có thể thử điều chỉnh cách phân công yêu cầu, theo dõi bằng cùng chỉ số đã chọn, rồi đánh giá xem thay đổi đó có giúp giảm thời gian chờ không.
Bảo trì phần mềm gồm những gì?
Đánh giá sau triển khai cũng là cách chuẩn bị cho những quyết định đầu tư tiếp theo. Khi doanh nghiệp biết phần nào đã giúp ích và phần nào còn vướng, việc trao đổi với đối tác phát triển sẽ cụ thể hơn: cần điều chỉnh quy trình, hỗ trợ người dùng hay bổ sung chức năng nào để giải quyết đúng vấn đề.
Nếu đang chuẩn bị xây dựng hoặc cải tiến hệ thống, doanh nghiệp nên làm rõ mục tiêu và cách đánh giá ngay từ đầu. Đây là cơ sở để hai bên cùng xem lại kết quả sau khi phần mềm đi vào sử dụng.
