Go-live xong, đội vận hành của khách hàng không chịu nhận bàn giao: lập kế hoạch hypercare và tiêu chí thoát cùng khách hàng doanh nghiệp

Tình huống minh hoạ

Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.

Một nhà cung cấp triển khai hệ thống quản lý bán hàng cho một chuỗi siêu thị. Go-live diễn ra cuối tuần, đúng kế hoạch. Thứ Hai, tổng đài hỗ trợ của chuỗi nhận hơn 300 cuộc gọi từ các cửa hàng. Trưởng nhóm vận hành CNTT phía khách hàng — người lần đầu dự một cuộc họp dự án là tuần trước go-live — tuyên bố:

"Chúng tôi chưa được đào tạo, chưa có tài liệu xử lý sự cố, chưa biết lỗi nào chuyển cho ai. Bên nhà cung cấp tiếp tục hỗ trợ cho đến khi ổn định, chúng tôi chưa nhận."

Sáu tuần sau, đội dự án vẫn trực 12 giờ mỗi ngày. Không ai định nghĩa "ổn định" là gì. Ngân sách dự phòng đã hết, đội dự án đáng lẽ phải chuyển sang dự án khác từ một tháng trước.

Đội vận hành — stakeholder "đến sau cùng"

Trong dự án cho khách hàng doanh nghiệp, người ký hợp đồng và người dùng nghiệp vụ thường được gắn kết từ đầu. Đội vận hành CNTT, tổng đài hỗ trợ, đội an ninh thông tin — những người sẽ sống với hệ thống nhiều năm sau khi dự án đóng — lại thường chỉ được mời ở cuối. Hệ quả là họ nhận một hệ thống họ không hiểu, với rủi ro họ không đồng ý, và phản ứng tự nhiên là từ chối.

Hypercare là gì

Hypercare là giai đoạn hỗ trợ tăng cường, ngắn và có thời hạn, ngay sau một thay đổi vận hành lớn như go-live: tăng người, tăng giám sát để xử lý nhanh các vấn đề phát sinh trong lúc người dùng làm quen. Giai đoạn này thường kéo dài vài tuần (các tài liệu thực hành hay nêu khoảng 1–4 tuần, tuỳ độ phức tạp) và kết thúc khi các chỉ báo cho thấy hệ thống đã ổn định: số yêu cầu hỗ trợ trở về mức bình thường, hiệu năng ổn định, các lỗi phổ biến đã được xử lý.

Trong ITIL v3, khái niệm tương ứng là hỗ trợ giai đoạn đầu (early life support) thuộc chuyển giao dịch vụ. Sau hypercare, trách nhiệm chuyển sang mô hình vận hành thường xuyên, thường được quy định bằng thoả thuận mức dịch vụ (service-level agreement – SLA): mô tả dịch vụ, tiêu chuẩn hiệu năng, cách giám sát, cách báo sự cố, thời gian phản hồi và hậu quả khi không đạt.

Phân tích theo PMBOK® Guide

• Identify Stakeholders: đội vận hành, tổng đài, an ninh thông tin là stakeholder ngay từ đầu, vì họ quyết định hệ thống có "sống" được sau dự án hay không.
• Lĩnh vực hiệu suất Delivery (PMBOK 7): giá trị chỉ hiện thực hoá khi sản phẩm được sử dụng và vận hành; bàn giao không dừng ở go-live.
• Close Project or Phase: chuyển giao sản phẩm cho vận hành là một hoạt động của đóng dự án; cần tiêu chí, người nhận và biên bản rõ ràng.
• Tiêu chí chấp nhận cho vận hành: tương tự tiêu chí chấp nhận cho người dùng, đội vận hành cần tiêu chí "sẵn sàng nhận" (tài liệu, đào tạo, giám sát, quy trình xử lý sự cố).

Cách làm: thiết kế chuyển giao từ giữa dự án

1. Mời đội vận hành vào sớm

Từ giai đoạn thiết kế kiến trúc, có đại diện đội vận hành trong các buổi rà soát. Họ đóng góp yêu cầu phi chức năng (giám sát, sao lưu, nhật ký) mà người dùng nghiệp vụ không nghĩ tới.

2. Thống nhất tiêu chí "sẵn sàng vận hành" trước go-live

Danh mục mẫu: tài liệu vận hành và xử lý sự cố, đào tạo cho tổng đài và đội vận hành, công cụ giám sát đã cài đặt, quy trình phân loại và chuyển tiếp sự cố, danh sách liên hệ. Đội vận hành ký xác nhận trước go-live — nếu chưa đạt, đó là căn cứ để cân nhắc dời go-live.

3. Hypercare có thời hạn và tiêu chí thoát đo được

Ví dụ thoả thuận trước:

Thời hạn tối đa (ví dụ 4 tuần) được ghi kèm: nếu hết thời hạn mà chưa đạt ngưỡng, hai bên đánh giá nguyên nhân và quyết định gia hạn qua kiểm soát thay đổi, không tự động kéo dài.

4. Chuyển dần trách nhiệm

Nửa đầu hypercare: đội dự án xử lý, đội vận hành "ngồi cạnh". Nửa sau: đội vận hành xử lý tuyến 1, đội dự án hỗ trợ tuyến 2. Khi thoát: đội vận hành chịu trách nhiệm chính, nhà cung cấp hỗ trợ theo SLA bảo trì.

Bảng này nên được đưa vào ma trận RACI của kế hoạch chuyển giao để không ai phải hỏi "lỗi này ai xử lý" trong tuần go-live.

5. Đóng có biên bản

Biên bản chuyển giao ghi: tiêu chí đã đạt, tồn đọng còn lại và người chịu trách nhiệm, SLA áp dụng từ ngày nào.

Sai lầm thường gặp

• Hypercare không có tiêu chí thoát: "đến khi ổn định" nghĩa là không bao giờ.
• Đào tạo đội vận hành trong tuần go-live: quá muộn để họ hiểu, quá bận để họ học.
• Đội dự án tiếp tục "chữa cháy" mãi: không ai khác học được cách vận hành, rủi ro phụ thuộc vào vài cá nhân.
• Nhầm hypercare với bảo hành: hypercare là hỗ trợ tăng cường có thời hạn; bảo hành và SLA là cam kết dài hạn với phạm vi khác.
• Không đo đường cơ sở: nếu không biết trước go-live tổng đài nhận bao nhiêu cuộc gọi mỗi ngày, sẽ không ai chứng minh được lúc nào số yêu cầu "trở về bình thường".

Góc ôn thi PMP

• Chuyển giao sản phẩm cho vận hành/khách hàng là hoạt động trong Close Project or Phase; dự án không kết thúc ở go-live.
• Câu hỏi "đội vận hành từ chối nhận bàn giao" → kiểm tra tiêu chí chấp nhận/chuyển giao đã thống nhất, xác định khoảng cách và lập kế hoạch đóng khoảng cách; về sau rút bài học: nhận diện stakeholder vận hành sớm hơn.
• Nhớ khác biệt: dự án có thời hạn; vận hành là liên tục.

Nguồn tham khảo

• Salesforce – What is hypercare? (định nghĩa, tiêu chí thoát)
• Wikipedia – Service-level agreement
• Wikipedia – ITIL