Thiết lập KPI cho bộ phận IT: Đo lường hiệu quả thay vì chỉ đếm số lượng công việc.

Bẫy phổ biến: đo cái dễ đếm thay vì cái cần quản lý

Số ticket đóng, số yêu cầu xử lý, số server đã vá hay số thay đổi đã triển khai đều là dữ liệu hữu ích. Nhưng chúng chủ yếu đo activity/output. Nếu dùng chúng như KPI chính, nhân viên có thể tối ưu hành vi theo số lượng: chia nhỏ ticket, đóng sớm, tránh nhận case khó hoặc ưu tiên việc dễ để tăng sản lượng. Kết quả là dashboard đẹp trong khi trải nghiệm người dùng và rủi ro vận hành không cải thiện tương ứng.

KPI phải bắt đầu từ câu hỏi quản trị. Ví dụ: “dịch vụ có đủ tin cậy cho quy trình bán hàng?”, “người dùng có được hỗ trợ đúng kỳ vọng?”, “thay đổi có tạo thêm sự cố?”, “danh mục dự án có thực sự tạo ra năng lực mới?”, “chi phí IT có đang tăng nhanh hơn giá trị nhận được?”. Khi câu hỏi rõ, chỉ số mới có ngữ cảnh và người quản lý biết phải hành động thế nào khi chỉ số lệch.

Đây là bước chuyển từ quản lý công việc sang quản lý kết quả, liên hệ trực tiếp với nội dung của bài viết về điều hành IT theo kết quả và chương trình Trưởng Phòng IT Chuyên Nghiệp – IT Manager.

Xây KPI từ chuỗi mục tiêu thay vì từ danh sách dữ liệu có sẵn

Một cách thiết kế thực dụng là đi theo chuỗi: mục tiêu doanh nghiệp → kết quả cần từ IT → năng lực/dịch vụ cần có → chỉ số dẫn dắt và chỉ số kết quả. Nếu doanh nghiệp muốn rút ngắn thời gian mở cửa hàng mới, IT có thể cần chuẩn hóa triển khai thiết bị, tài khoản và kết nối. KPI khi đó không chỉ là “số thiết bị cấu hình”, mà có thể là thời gian sẵn sàng IT trước ngày khai trương, tỷ lệ triển khai đúng hạn và số lỗi phát sinh trong tuần đầu.

Chuỗi này giúp tránh việc mỗi nhóm tự chọn KPI theo chuyên môn riêng. Nhóm hạ tầng quan tâm availability, Service Desk quan tâm SLA, dự án quan tâm milestone; nhưng trưởng phòng cần nhìn cách các chỉ số này cùng phục vụ một mục tiêu lớn hơn. KPI cấp bộ phận phải tạo một bức tranh kết nối, không phải ghép nhiều bảng đo kỹ thuật.

Khi mục tiêu IT cần gắn chặt với mục tiêu doanh nghiệp, bài xây dựng mục tiêu và kế hoạch hoạt động của bộ phận IT là nền tảng trước khi thiết kế thước đo.

Xây một bộ KPI cân bằng theo bốn lớp

Bộ KPI nên cân bằng ít nhất bốn lớp. Lớp dịch vụ đo độ tin cậy, khả năng đáp ứng và trải nghiệm. Lớp hiệu quả đo năng suất dòng công việc, thời gian xử lý, tỷ lệ tự động hóa hoặc chi phí đơn vị. Lớp rủi ro đo khả năng phục hồi, lỗ hổng, thay đổi thất bại và phụ thuộc trọng yếu. Lớp giá trị/enablement đo mức IT hỗ trợ mục tiêu doanh nghiệp, tỷ lệ sáng kiến quan trọng đúng tiến độ và mức áp dụng năng lực mới.

Không cần mỗi lớp có mười chỉ số. IT Manager nên chọn một số ít KPI thật sự dẫn đến quyết định. Nếu một chỉ số thay đổi nhưng không ai biết phải làm gì khác đi, có thể nó chỉ phù hợp làm operational metric chứ chưa cần xuất hiện trên dashboard quản lý.

Kết hợp chỉ số dẫn dắt và chỉ số kết quả

Chỉ số kết quả cho biết điều gì đã xảy ra; chỉ số dẫn dắt giúp dự báo hoặc tác động trước khi kết quả xấu xuất hiện. Ví dụ, số sự cố nghiêm trọng là lagging indicator; tỷ lệ thay đổi được test đầy đủ hoặc số lỗ hổng quá hạn có thể là leading indicator. Thời gian xử lý ticket là kết quả; backlog aging và tỷ lệ ticket thiếu phân loại đúng có thể cảnh báo sớm chất lượng sẽ giảm.

Một dashboard chỉ có lagging indicator khiến quản lý phản ứng sau sự kiện. Một dashboard chỉ có leading indicator lại có nguy cơ quá xa kết quả mà doanh nghiệp quan tâm. Cặp chỉ số nên được xây theo quan hệ nhân quả đủ hợp lý và được kiểm tra thực tế theo thời gian. Nếu một leading KPI luôn “xanh” nhưng kết quả vẫn xấu, giả định quản trị cần được xem lại.

Tư duy liên kết service metric với trải nghiệm và kết quả dịch vụ được hỗ trợ bởi Quản Lý Dịch Vụ IT – ITSM và ITIL 4 Foundation.

Đặt target mà không khuyến khích hành vi sai

Một target tốt cần có baseline, bối cảnh và ngưỡng giải thích. Đặt “100% ticket đúng SLA” có thể khiến nhóm đóng ticket hoặc chuyển trạng thái để bảo vệ con số. Đặt “0 sự cố” có thể khiến nhân viên ngại ghi nhận incident. Vì vậy trước khi ban hành target, IT Manager cần hỏi: người thực hiện có thể thao túng chỉ số không, điều gì sẽ bị hy sinh để đạt số, và có cần một chỉ số cân bằng khác?

Ví dụ, KPI thời gian xử lý nên đi cùng reopen rate hoặc satisfaction; KPI deployment frequency nên đi cùng change failure rate; KPI tiết kiệm chi phí nên đi cùng rủi ro hoặc chất lượng dịch vụ. Không phải để làm dashboard phức tạp, mà để tránh tối ưu cục bộ. Khi hai chỉ số có thể xung đột, đó chính là thông tin quản trị hữu ích.

KPI cũng cần owner và cadence review. Chỉ số không có người chịu trách nhiệm phân tích thường biến thành báo cáo tự động không ai sử dụng. Owner không nhất thiết “chịu tội” khi KPI đỏ; họ chịu trách nhiệm làm rõ nguyên nhân, đề xuất hành động và theo dõi cải thiện.

Thiết kế dashboard một trang cho trưởng phòng IT

Dashboard cấp trưởng phòng nên ưu tiên xu hướng, ngoại lệ và quyết định. Mỗi KPI cần thể hiện baseline/target, xu hướng, nguyên nhân chính nếu lệch và action owner. Việc chỉ tô đỏ/xanh mà không có bối cảnh thường dẫn tới cuộc họp hỏi lại dữ liệu thay vì quyết định.

Một cấu trúc hữu ích gồm bốn vùng: Health of Services; Delivery & Flow; Risk & Control; Business Enablement. Mỗi vùng chỉ nên có vài KPI chính. Các operational metrics chi tiết có thể nằm ở drill-down cho trưởng nhóm. Cách phân tầng này giúp quản lý cấp cao nhìn được bức tranh mà không mất khả năng truy về bằng chứng.

Đối với các bộ phận có nhiều nhóm chức năng, KPI cấp nhóm có thể khác nhau nhưng phải cuộn lên cùng mục tiêu bộ phận. Hạ tầng, ứng dụng và Service Desk không cần giống KPI, nhưng cùng cần chứng minh đóng góp vào độ tin cậy, tốc độ cung cấp, rủi ro và trải nghiệm.

Tình huống minh họa: “đóng ticket nhiều” nhưng người dùng vẫn phàn nàn

Tình huống giả định: Service Desk đạt KPI 95% ticket xử lý đúng SLA và số ticket đóng tăng 20%. Tuy nhiên khảo sát người dùng giảm và số ticket reopen tăng. Phân tích cho thấy nhóm ưu tiên đóng ticket trong hệ thống khi đã hướng dẫn sơ bộ, nhưng người dùng vẫn chưa giải quyết dứt điểm vấn đề. KPI số lượng đã vô tình khuyến khích hành vi kết thúc quy trình thay vì kết thúc vấn đề.

IT Manager thay dashboard bằng ba chỉ số cân bằng: first-contact resolution cho nhóm case phù hợp, reopen rate và satisfaction sau xử lý; SLA tiếp tục được theo dõi nhưng không đứng một mình. Đồng thời, ticket lặp lại được đưa sang problem management để xử lý nguyên nhân gốc. Sau đó, cuộc họp hiệu suất chuyển từ “ai đóng ít ticket?” sang “loại yêu cầu nào tạo nhiều effort mà chưa được loại bỏ?”.

Đây là ví dụ cho thấy KPI là một thiết kế hành vi. Chọn sai chỉ số không chỉ tạo báo cáo sai; nó còn có thể khiến tổ chức làm đúng điều được đo nhưng sai điều doanh nghiệp cần.

Checklist trước khi phê duyệt KPI bộ phận IT

• KPI có bắt đầu từ mục tiêu quản trị cụ thể?
• Đã phân biệt KPI cấp quản lý với operational metrics?
• Có ít nhất một chỉ số về dịch vụ, hiệu quả, rủi ro và giá trị?
• Có cặp leading/lagging hợp lý cho các mục tiêu trọng yếu?
• Target có baseline và tránh khuyến khích hành vi gaming?
• Mỗi KPI có owner, nguồn dữ liệu và định nghĩa thống nhất?
• Dashboard có xu hướng và action, không chỉ trạng thái màu?
• KPI có được review định kỳ để bỏ chỉ số không còn giá trị?

Hành động nên bắt đầu: lấy 10 chỉ số đang báo cáo hiện nay và gắn nhãn Activity, Output, Outcome hoặc Risk. Nếu dashboard chủ yếu là Activity/Output, hãy thay ít nhất ba chỉ số bằng thước đo kết quả hoặc rủi ro mà lãnh đạo có thể dùng để ra quyết định.

Bài viết liên quan

• Quản lý công việc hay quản lý kết quả?
• Xây dựng mục tiêu bộ phận IT gắn với doanh nghiệp
• Cân đối nguồn lực IT giữa vận hành và dự án
• Xây dựng danh mục dịch vụ IT và cam kết phục vụ

Nguồn tham khảo

1. ISO/IEC 38500:2024 – Governance of IT for the organization
2. ISACA – COBIT resources
3. ISO/IEC 20000-1:2018 – Service management system requirements
4. PeopleCert – ITIL 4 practices

Các nguồn trên được sử dụng để tham khảo các nguyên tắc quản trị, quản lý dịch vụ và thực hành quản lý. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.