INFOCHIEF ACADEMY · IT MANAGER KNOWLEDGE SERIES

Trưởng phòng IT quản lý công việc hay quản lý kết quả? Cách chuyển đổi phương pháp điều hành.

Một bộ phận IT có thể rất bận nhưng vẫn không tạo ra cảm giác tiến bộ. Ticket được đóng, cuộc họp diễn ra đều, dự án có nhiều task hoàn tất nhưng người dùng vẫn phàn nàn và Ban điều hành vẫn hỏi “kết quả là gì?”. Vấn đề thường không phải thiếu nỗ lực; vấn đề là cách quản lý đang tập trung vào hoạt động thay vì kết quả.

Biên soạn: Infochief Academy · Chuyên đề: Trưởng Phòng IT Chuyên Nghiệp – IT Manager

← Trở về danh mục IT Manager

Minh họa biên tập: IT Manager trình bày sự khác biệt giữa quản lý công việc và quản lý kết quả dịch vụ IT.

Cái bẫy quản lý bằng danh sách việc: bận rộn không đồng nghĩa hiệu quả

Quản lý công việc là cần thiết, nhưng nếu IT Manager chỉ đo số việc hoàn thành, số ticket xử lý hoặc tỷ lệ task đúng hạn thì rất dễ tối ưu sai mục tiêu. Một nhóm có thể đóng nhiều ticket bằng cách chia nhỏ yêu cầu; một dự án có thể hoàn thành milestone nhưng giải pháp chưa được người dùng áp dụng; một hệ thống có thể ổn định nhưng quy trình kinh doanh vẫn chậm.

Đặc điểm của “activity trap” là cuộc họp đầy chi tiết nhưng khó kết luận. Mỗi người báo cáo đã làm gì, đang làm gì và vướng gì; ít ai trả lời được dịch vụ nào đã tốt hơn, rủi ro nào đã giảm hoặc mục tiêu nào đang lệch. Quản lý phải tự ghép hàng chục mẩu thông tin để hiểu bức tranh chung.

Vì vậy, IT Manager cần chuyển từ câu hỏi “đã làm bao nhiêu?” sang “kết quả nào đã thay đổi?”. Nội dung IT Manager chuyên nghiệp của Infochief nhấn mạnh việc điều hành bộ phận bằng mục tiêu, KPI và trách nhiệm thay vì dựa trên mức độ bận rộn của đội ngũ.

Xây chuỗi kết quả: từ hoạt động IT đến kết quả dịch vụ và tác động kinh doanh

Một phương pháp thực tế là thiết kế chuỗi bốn tầng: hoạt động → sản phẩm đầu ra → kết quả dịch vụ → tác động kinh doanh. Ví dụ, “triển khai công cụ monitoring” chỉ là hoạt động; “cảnh báo phủ đủ dịch vụ trọng yếu” là đầu ra; “phát hiện sớm và giảm thời gian gián đoạn” là kết quả dịch vụ; “giảm rủi ro dừng quy trình bán hàng” mới là tác động mà lãnh đạo quan tâm.

Tầng	Câu hỏi quản lý	Ví dụ
Hoạt động	Đội ngũ đã làm gì?	Cấu hình monitoring, cập nhật runbook
Đầu ra	Đã tạo ra sản phẩm quản lý nào?	Dashboard, cảnh báo, SOP, automation
Kết quả dịch vụ	Dịch vụ thay đổi ra sao?	Phát hiện nhanh hơn, ít gián đoạn hơn
Tác động kinh doanh	Điều đó có ý nghĩa gì?	Quy trình bán hàng ổn định, giảm rủi ro doanh thu

Không phải mọi công việc đều cần quy đổi thành tiền. Quan trọng là xác định mối liên hệ có lý và có thể kiểm chứng. Tư duy giá trị dịch vụ trong Quản Lý Dịch Vụ IT – ITSM giúp IT Manager tránh tình trạng tối ưu chỉ số nội bộ mà bỏ quên trải nghiệm và outcome của người sử dụng.

Đặt outcome và tiêu chí hoàn thành trước khi giao việc

Một task mô tả hành động; một outcome mô tả trạng thái mong muốn sau khi hành động hoàn tất. “Nâng cấp firewall” là task. “Loại bỏ phiên bản hết hỗ trợ mà không làm gián đoạn kết nối của ba hệ thống trọng yếu” là outcome có điều kiện thành công rõ hơn.

Trước khi giao việc quan trọng, IT Manager nên yêu cầu bốn thành phần: mục tiêu, tiêu chí hoàn thành, phạm vi trách nhiệm và bằng chứng xác nhận. Cách làm này giúp nhân viên có không gian lựa chọn phương án nhưng vẫn rõ điều kiện phải đạt. Với công việc có nhiều bên tham gia, có thể bổ sung mốc kiểm tra và tiêu chí escalation.

Thiết kế nhịp điều hành theo kết quả thay vì theo sự vụ

Chuyển đổi cách quản lý không nhất thiết bắt đầu bằng một hệ thống KPI phức tạp. Hãy bắt đầu từ nhịp họp. Cuộc họp tuần có thể được tổ chức theo bốn câu hỏi: kết quả quan trọng tuần trước; rủi ro và ngoại lệ; ưu tiên tuần tới; quyết định hoặc hỗ trợ cần từ quản lý. Chỉ các vấn đề ngoại lệ mới đi sâu vào chi tiết kỹ thuật.

Họp tháng nên nâng góc nhìn lên dịch vụ và năng lực: xu hướng SLA/experience, backlog cải tiến, năng lực nhân sự, chi phí, nhà cung cấp và các thay đổi sắp tới. Họp quý nên kết nối với kế hoạch bộ phận, danh mục dự án và mục tiêu doanh nghiệp. Khi nhịp review được phân tầng, IT Manager tránh được việc biến mọi cuộc họp thành status meeting.

Để triển khai tốt, trưởng nhóm và IT Supervisor cần biết cách theo dõi tiến độ, phản hồi và báo cáo ngoại lệ. Đây là lý do năng lực giám sát IT có vai trò quan trọng trong hệ thống quản lý nhiều tầng.

Dashboard cho IT Manager: ít chỉ số hơn nhưng có khả năng dẫn đến quyết định

Nhóm	Nên theo dõi	Quyết định hỗ trợ
Dịch vụ	gián đoạn theo tác động, SLA/XLA, backlog vấn đề	ưu tiên cải tiến và nguồn lực
Công việc	cam kết quan trọng, độ trễ, phụ thuộc	gỡ điểm nghẽn và điều chỉnh ưu tiên
Rủi ro	vấn đề bảo mật, capacity, thay đổi lớn	chấp nhận, giảm thiểu hoặc escalated
Con người	workload, năng lực thiếu, bus factor	đào tạo, tuyển, phân quyền
Cải tiến	lợi ích dự kiến, mức áp dụng, kết quả	tiếp tục, điều chỉnh hoặc dừng

Mỗi chỉ số cần có ngưỡng hoặc ngữ cảnh. “120 ticket mở” không nói lên nhiều nếu không biết mức bình thường, mức độ nghiêm trọng và xu hướng. “Backlog P1/P2 tăng ba tuần liên tiếp và 40% liên quan cùng một dịch vụ” hữu ích hơn vì dẫn đến quyết định phân tích vấn đề gốc và ưu tiên nguồn lực.

Khi dashboard trở thành công cụ ra quyết định thay vì bảng thống kê, IT Manager có thể dành ít thời gian hơn cho việc tổng hợp thủ công và nhiều thời gian hơn cho phân tích nguyên nhân, năng lực và cải tiến.

Tình huống minh họa: nhóm vận hành luôn bận nhưng người dùng vẫn chưa hài lòng

Tình huống giả định: một nhóm vận hành báo cáo mỗi tháng xử lý hàng nghìn ticket và đạt tỷ lệ đóng đúng SLA cao. Tuy nhiên, phòng kinh doanh liên tục phàn nàn về cùng một lỗi truy cập và thời gian chờ hỗ trợ trong giờ cao điểm.

IT Manager thay đổi báo cáo từ “số ticket đã đóng” sang ba lớp: nhu cầu phát sinh, nguyên nhân lặp lại và tác động người dùng. Nhóm phát hiện một nhóm lỗi tài khoản chiếm tỷ trọng lớn và có thể tự động hóa; đồng thời lịch trực không khớp giờ cao điểm. Thay vì yêu cầu nhân viên xử lý nhanh hơn, quản lý đầu tư vào automation và điều chỉnh capacity.

Điểm đáng chú ý là kết quả đến từ việc đổi câu hỏi quản trị: không phải “làm sao xử lý nhiều ticket hơn?” mà là “làm sao giảm nhu cầu lặp lại và phục vụ tốt hơn?”. Đây là khác biệt căn bản giữa quản lý công việc và quản lý kết quả.

Từ chỉ số sang hành động: thiết kế ngưỡng và escalation

Một hệ thống quản lý theo kết quả cần quy tắc phản ứng. Mỗi KPI quan trọng nên có ngưỡng, xu hướng và hành động dự kiến. Ví dụ, backlog critical tăng trong hai kỳ review không chỉ chuyển màu dashboard; nó kích hoạt problem review hoặc tái phân bổ capacity. Khi threshold gắn với action, dashboard trở thành hệ thống điều hành thay vì màn hình trang trí.

IT Manager cũng nên phân biệt chỉ số để quan sát và chỉ số để cam kết. Không phải mọi metric nội bộ đều nên đưa vào KPI. Một số dữ liệu dùng để chẩn đoán, một số chỉ số dùng để cảnh báo sớm, và một số outcome mới phù hợp để cam kết với cấp trên. Việc phân tầng này giảm áp lực tối ưu số liệu mà vẫn giữ khả năng phân tích sâu.

Checklist cho cuộc họp và báo cáo theo kết quả

Mỗi ưu tiên có outcome rõ và người chịu trách nhiệm.
Có bằng chứng hoặc chỉ số xác nhận outcome, không chỉ trạng thái task.
Các ngoại lệ được phân loại theo tác động và rủi ro, không theo người kêu lớn nhất.
Cuộc họp kết thúc bằng quyết định, hành động, chủ sở hữu và thời hạn.
Backlog được xem theo giá trị và rủi ro, không chỉ theo tuổi ticket.
Có mục cải tiến nguyên nhân gốc để tránh lặp lại cùng một khối lượng công việc.
Báo cáo cấp trên được dịch sang ngôn ngữ dịch vụ, rủi ro, chi phí và giá trị.

Nếu checklist này làm thay đổi cách họp nhưng KPI chưa thay đổi ngay, vẫn là một bước tiến. Thói quen quản lý theo kết quả thường được hình thành trước trong câu hỏi, agenda và quyết định; hệ thống đo lường sẽ dần hoàn thiện sau đó.

Kết luận: quản lý kết quả là quản lý điều gì thay đổi, không chỉ điều gì đã làm

IT Manager không thể bỏ quản lý công việc, nhưng công việc phải là phương tiện. Đơn vị quản lý cuối cùng cần là kết quả dịch vụ, mức độ rủi ro, năng lực đội ngũ và giá trị được tạo hoặc bảo vệ. Khi điều này rõ, team dễ tự tổ chức hơn vì họ hiểu điều gì quan trọng thay vì chỉ chờ danh sách task.

Một hành động đơn giản cho tuần tới: chọn một báo cáo hiện tại, thêm cột “kết quả mong đợi”, “bằng chứng” và “quyết định cần thiết”. Chỉ ba cột này có thể thay đổi đáng kể chất lượng cuộc trao đổi giữa IT Manager và đội ngũ.

Nguồn tham khảo

Các nguồn trên được dùng để tham khảo nguyên tắc quản trị, quản lý dịch vụ, trách nhiệm và tổ chức công việc. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.