ITIL (Information Technology Infrastructure Library) là bộ hướng dẫn thực hành tốt về quản lý dịch vụ công nghệ thông tin (IT Service Management — ITSM), được dùng rộng rãi nhất thế giới. Ý tưởng cốt lõi: bộ phận IT không phải là nơi "sửa máy" mà là đơn vị cung cấp dịch vụ cho phần còn lại của doanh nghiệp, nên cần quy trình rõ ràng để tiếp nhận, ưu tiên, xử lý, đo lường và cải tiến.
ITIL không phải phần mềm, không phải tiêu chuẩn bắt buộc, và không cần áp dụng toàn bộ. Doanh nghiệp vừa thường chỉ cần năm thực hành nền tảng: quản lý sự cố, đáp ứng yêu cầu, quản lý vấn đề, quản lý thay đổi và quản lý tri thức, chạy trên một hệ thống ghi phiếu đơn giản. Bài viết giải thích các khái niệm, lịch sử, cách dựng bàn hỗ trợ nội bộ và những chỉ số đáng đo.
Lịch sử ngắn: từ thư viện của chính phủ Anh tới ITIL 4
Hiểu nguồn gốc giúp giải thích vì sao ITIL có dạng như hiện nay và những phê phán đi kèm:
- Cuối thập niên 1980: cơ quan CCTA của chính phủ Anh soạn một loạt sách hướng dẫn thực hành vận hành CNTT cho các cơ quan nhà nước, vì nhận thấy chất lượng dịch vụ CNTT không đồng đều và phụ thuộc nhà cung cấp. Bộ sách ban đầu có hàng chục cuốn.
- Đầu những năm 2000 — ITIL v2: gom lại quanh hai khối chính là hỗ trợ dịch vụ và cung cấp dịch vụ, phổ biến rộng trong khối doanh nghiệp toàn cầu.
- 2005: tiêu chuẩn ISO/IEC 20000 về quản lý dịch vụ CNTT ra đời, có gốc từ tiêu chuẩn Anh BS 15000 vốn gắn chặt với ITIL. ISO 20000 là tiêu chuẩn chứng nhận được; ITIL là hướng dẫn thực hành.
- 2007 — ITIL v3, cập nhật năm 2011: tổ chức quanh vòng đời dịch vụ năm giai đoạn (chiến lược, thiết kế, chuyển giao, vận hành, cải tiến liên tục).
- 2019 — ITIL 4: chuyển từ "quy trình" sang "thực hành", đặt trong hệ thống giá trị dịch vụ, tích hợp tư duy Agile, DevOps và Lean, nhấn mạnh đồng tạo giá trị với người dùng.
Phê phán phổ biến với các phiên bản cũ là ITIL bị áp dụng quá cứng nhắc: tổ chức sao chép quy trình nặng nề, nhiều biểu mẫu, phê duyệt nhiều tầng, khiến IT chậm chạp hơn. ITIL 4 phần nào phản hồi phê phán này với nguyên tắc "giữ đơn giản và thực tế" và "bắt đầu từ chỗ bạn đang đứng". Bài học cho doanh nghiệp vừa: lấy những gì giải quyết vấn đề của mình, không áp nguyên khối.
Phân biệt năm khái niệm hay bị lẫn
Hệ thống phiếu hỗ trợ hiệu quả bắt đầu từ việc gọi đúng tên từng loại công việc, vì mỗi loại có cách xử lý và mục tiêu khác nhau.
| Khái niệm | Định nghĩa | Mục tiêu | Ví dụ |
|---|---|---|---|
| Sự cố (incident) | Gián đoạn ngoài kế hoạch hoặc suy giảm chất lượng của một dịch vụ | Khôi phục dịch vụ nhanh nhất, kể cả bằng giải pháp tạm | Phần mềm kế toán không mở được; Wi-Fi tầng ba mất |
| Yêu cầu dịch vụ (service request) | Đề nghị một việc đã được định nghĩa trước, không phải hỏng hóc | Đáp ứng theo quy trình chuẩn, dự đoán được | Cấp tài khoản cho nhân viên mới; cài phần mềm có trong danh mục |
| Vấn đề (problem) | Nguyên nhân gốc, thường chưa biết, của một hoặc nhiều sự cố | Tìm và loại bỏ nguyên nhân để sự cố không lặp lại | Vì sao máy chủ tệp treo mỗi thứ Hai |
| Lỗi đã biết (known error) | Vấn đề đã xác định nguyên nhân, có hoặc chưa có giải pháp triệt để | Ghi lại cách xử lý tạm để giải quyết sự cố nhanh | Máy in tầng hai cần khởi động lại sau khi đổi giấy, chờ thay bo mạch |
| Thay đổi (change) | Thêm, sửa, gỡ bất cứ thứ gì có thể ảnh hưởng dịch vụ | Thực hiện thay đổi có lợi mà giảm rủi ro gây sự cố | Nâng cấp tường lửa; đổi cấu hình VLAN |
Lẫn sự cố với vấn đề là lỗi phổ biến nhất: đội IT khởi động lại máy chủ mỗi tuần và đóng phiếu, nhưng không ai mở phiếu vấn đề để tìm nguyên nhân. Lẫn yêu cầu với sự cố làm méo số liệu: cấp tài khoản mới bị tính là "sự cố", khiến báo cáo trông như hệ thống hỏng liên tục.
Ma trận ưu tiên: ảnh hưởng nhân mức khẩn
Ưu tiên không do người báo quyết định. Mọi người dùng đều thấy việc của mình khẩn. Mức ưu tiên cần được tính theo tiêu chí khách quan, phổ biến nhất là kết hợp hai trục: ảnh hưởng (bao nhiêu người, dịch vụ nào, có ảnh hưởng khách hàng hay doanh thu không) và mức khẩn (có giải pháp tạm không, thiệt hại tăng nhanh thế nào theo thời gian).
Một ma trận ba nhân ba là đủ cho phần lớn doanh nghiệp. Ảnh hưởng cao (cả công ty hoặc dịch vụ khách hàng), trung bình (một phòng ban), thấp (một người). Mức khẩn cao (ngừng việc hoàn toàn), trung bình (làm việc được nhưng khó khăn), thấp (bất tiện). Kết hợp ra bốn hoặc năm mức ưu tiên, mỗi mức gắn mục tiêu phản hồi và khắc phục.
Định nghĩa trước các trường hợp đặc biệt. Ví dụ: sự cố liên quan đến hệ thống thanh toán hoặc quầy giao dịch luôn ở mức cao nhất; máy của ban giám đốc có thể có quy tắc riêng nhưng cần ghi rõ, tránh ưu tiên ngầm làm mất lòng tin của người dùng khác.
Sự cố nghiêm trọng cần quy trình riêng. Khi dịch vụ quan trọng ngừng hoạt động, cần chỉ định một người điều phối, kênh thông báo định kỳ cho người dùng và lãnh đạo, và họp rút kinh nghiệm sau khi khắc phục. Đây là lúc quản lý sự cố gặp kế hoạch liên tục kinh doanh.
Rà soát lại sau khi xử lý. Phiếu bị đánh giá sai mức ưu tiên nên được ghi nhận để chỉnh tiêu chí, không phải để đổ lỗi cho người phân loại.
Dựng bàn hỗ trợ nội bộ từ con số không
Doanh nghiệp vài chục đến vài trăm người, IT xử lý yêu cầu qua điện thoại, chat và lời nhờ ngoài hành lang, có thể chuyển sang mô hình bàn hỗ trợ theo các bước sau.
- Một điểm tiếp nhận duy nhất: mọi yêu cầu vào một hệ thống phiếu, qua cổng web, email hoặc chat tích hợp. Lời nhờ miệng cũng được ghi thành phiếu bởi chính người nhận. Không có phiếu thì không có dữ liệu để cải thiện.
- Danh mục phân loại gọn: loại (sự cố, yêu cầu), dịch vụ bị ảnh hưởng (email, mạng, phần mềm kế toán, máy in, tài khoản), mức ưu tiên. Danh mục quá chi tiết khiến người phân loại chọn bừa.
- Danh mục dịch vụ và yêu cầu chuẩn: liệt kê những gì IT cung cấp, thời gian đáp ứng dự kiến, ai phê duyệt. Ví dụ: cấp tài khoản nhân viên mới trong một ngày làm việc nếu nhận thông tin từ nhân sự trước ba ngày.
- Phân tầng hỗ trợ: tầng 1 tiếp nhận và giải quyết việc phổ biến theo hướng dẫn; tầng 2 xử lý kỹ thuật sâu hơn; tầng 3 là chuyên gia hoặc nhà cung cấp. Ở doanh nghiệp nhỏ, một người có thể kiêm nhiều tầng, nhưng phân tầng vẫn giúp biết khi nào cần chuyển tiếp.
- Kho tri thức: mỗi lần giải quyết một việc lặp lại, viết một bài hướng dẫn ngắn cho kỹ thuật viên và, nếu phù hợp, cho người dùng tự làm. Đây là cách ITIL gọi là dịch chuyển sang trái (shift-left): đưa việc giải quyết về tầng sớm hơn, rẻ hơn.
- Quy trình thay đổi tối giản: thay đổi rủi ro thấp lặp lại được phê duyệt sẵn; thay đổi lớn cần mô tả, kế hoạch quay lui, thời điểm ít ảnh hưởng và người phê duyệt.
- Họp rà soát hằng tháng trên số liệu phiếu: loại sự cố nào nhiều nhất, sự cố nào lặp lại, mở phiếu vấn đề cho những nguyên nhân đáng xử lý.
Thứ tự quan trọng: điểm tiếp nhận duy nhất và phân loại cơ bản phải có trước, vì mọi cải tiến sau đều dựa trên dữ liệu phiếu. Mua phần mềm ITSM đầy đủ tính năng khi chưa có thói quen ghi phiếu thường dẫn tới hệ thống đắt tiền mà không ai dùng.
Chỉ số bàn hỗ trợ: đo gì và đọc thế nào
Mỗi chỉ số kể một phần câu chuyện; theo dõi một chỉ số đơn lẻ dễ dẫn tới hành vi lệch. Bảng dưới gồm các chỉ số phổ biến và cách tránh hiểu sai.
| Chỉ số | Ý nghĩa | Bẫy khi đọc |
|---|---|---|
| Tỷ lệ giải quyết ngay lần đầu | Phần trăm phiếu được giải quyết ở lần tiếp xúc đầu tiên, không chuyển tiếp | Bị đẩy lên bằng cách đóng phiếu vội; cần đối chiếu với tỷ lệ mở lại |
| Thời gian khắc phục trung bình | Thời gian từ lúc mở tới lúc đóng phiếu sự cố | Trung bình bị kéo lệch bởi vài phiếu rất dài; xem thêm trung vị và theo mức ưu tiên |
| Tỷ lệ đạt SLA | Phần trăm phiếu đạt mục tiêu phản hồi và khắc phục | Có thể đạt cao nếu mục tiêu đặt quá dễ |
| Tồn đọng | Số phiếu đang mở và tuổi của chúng | Tồn đọng tăng đều là dấu hiệu thiếu năng lực hoặc quy trình tắc |
| Tỷ lệ mở lại | Phần trăm phiếu bị người dùng mở lại sau khi đóng | Cao nghĩa là giải quyết chưa triệt để hoặc đóng sớm |
| Mức hài lòng người dùng | Khảo sát ngắn sau khi đóng phiếu | Tỷ lệ trả lời thấp, thiên về người rất hài lòng hoặc rất bực |
| Sự cố lặp lại theo dịch vụ | Số sự cố cùng loại trên một dịch vụ theo thời gian | Chỉ số quan trọng nhất để quyết định đầu tư sửa tận gốc |
Mục đích của chỉ số là cải tiến, không phải chấm điểm cá nhân. Khi chỉ số trở thành chỉ tiêu thưởng phạt, chúng dễ bị "làm đẹp" — hiện tượng mà nhà kinh tế học Charles Goodhart mô tả và thường được phát biểu lại thành định luật Goodhart: khi một thước đo trở thành mục tiêu, nó không còn là thước đo tốt. Kết hợp vài chỉ số kéo ngược chiều nhau, như giải quyết lần đầu cùng tỷ lệ mở lại, giúp hạn chế điều này.
Áp dụng ITIL gọn cho doanh nghiệp vừa: ví dụ giả định
Một công ty phân phối thiết bị y tế 150 người ở Hà Nội, có ba chi nhánh (ví dụ giả định), đội IT bốn người. Trước khi thay đổi, yêu cầu đến qua điện thoại di động của từng kỹ thuật viên và nhóm chat chung; trưởng IT không biết mỗi tuần đội xử lý bao nhiêu việc, việc gì tốn thời gian nhất; nhân viên phàn nàn "gọi IT không ai nghe".
Trong ba tháng, đội IT dựng một cổng phiếu đơn giản, quy định mọi yêu cầu phải có phiếu, áp ma trận ưu tiên ba nhân ba, và viết hai mươi bài hướng dẫn cho các việc lặp lại nhiều nhất như đặt lại mật khẩu, kết nối máy in, cấu hình email trên điện thoại. Họ thêm biểu mẫu nhân viên mới do phòng nhân sự gửi trước ba ngày, thay cho việc nhân viên mới đến ngồi chờ máy.
Dữ liệu ba tháng đầu cho thấy gần một phần ba phiếu là đặt lại mật khẩu và khoá tài khoản; công ty triển khai tự đặt lại mật khẩu có xác thực, cắt phần lớn nhóm phiếu này. Một chi nhánh chiếm tỷ lệ sự cố mạng cao bất thường; mở phiếu vấn đề phát hiện bộ chuyển mạch cũ quá nhiệt trong tủ không thông gió. Không có phần mềm đắt tiền nào, chỉ là gọi đúng tên công việc, ghi lại, và nhìn vào số liệu.
Câu hỏi thường gặp
Có cần chứng chỉ ITIL để áp dụng ITIL không?
Không. Chứng chỉ ITIL giúp đội ngũ có ngôn ngữ chung và hiểu khung tổng thể, hữu ích khi làm việc với đối tác lớn hoặc nhà cung cấp dịch vụ. Nhưng áp dụng tốt đến từ việc chọn đúng thực hành cho vấn đề của mình và kiên trì vận hành, không phải từ số người có chứng chỉ.
ITIL và ISO/IEC 20000 khác nhau thế nào?
ITIL là bộ hướng dẫn thực hành, mô tả nên làm gì và làm thế nào, không có chứng nhận cho tổ chức. ISO/IEC 20000 là tiêu chuẩn quốc tế về hệ thống quản lý dịch vụ, nêu yêu cầu tổ chức phải đáp ứng và có thể được đánh giá chứng nhận. Nhiều tổ chức dùng ITIL làm cách để đạt yêu cầu của ISO 20000.
ITIL có mâu thuẫn với DevOps và Agile không?
Các phiên bản cũ bị cho là cứng nhắc so với nhịp phát hành nhanh của DevOps, đặc biệt ở quản lý thay đổi nhiều tầng phê duyệt. ITIL 4 tích hợp tư duy Agile và DevOps, khuyến khích phê duyệt tự động cho thay đổi rủi ro thấp được kiểm thử tốt. Hai cách tiếp cận có thể bổ trợ nếu áp dụng linh hoạt.
Doanh nghiệp thuê ngoài IT có cần quan tâm ITIL không?
Có, ở vai trò bên mua dịch vụ. Hiểu khái niệm sự cố, yêu cầu, vấn đề, SLA giúp đọc hợp đồng và báo cáo của nhà cung cấp, đặt câu hỏi đúng như sự cố lặp lại có được mở phiếu vấn đề không, và đánh giá chất lượng dịch vụ dựa trên số liệu thay vì cảm nhận.
Phần mềm quản lý phiếu nên chọn theo tiêu chí gì?
Dễ dùng cho người báo yêu cầu, hỗ trợ nhiều kênh tiếp nhận, phân loại và ưu tiên tuỳ chỉnh được, có kho tri thức, báo cáo cơ bản, tích hợp hệ thống tài khoản và danh mục tài sản. Doanh nghiệp vừa nên bắt đầu với công cụ gọn, tránh nền tảng quá phức tạp khi quy trình chưa định hình.
Bàn hỗ trợ nên phục vụ ngoài giờ hành chính không?
Tuỳ hoạt động của doanh nghiệp. Nhà máy chạy ca, chuỗi bán lẻ mở cửa buổi tối cần ít nhất một kênh tiếp nhận sự cố nghiêm trọng ngoài giờ, có người trực luân phiên hoặc thuê ngoài phần trực. Văn phòng làm giờ hành chính có thể chỉ cần quy trình liên lạc khẩn cho sự cố nghiêm trọng.