Hypercare sau go-live: FDE trực thế nào và khi nào mới được rút

Hệ thống go-live sáng thứ Hai. Đến chiều thứ Tư, ticket bắt đầu dồn về, và quản lý của bạn đã nhắn hỏi tuần sau bạn sang khách hàng mới được chưa.

Câu trả lời đúng hiếm khi là “có” hay “không”. Câu trả lời đúng là “khi đạt tiêu chí rút”. Khoảng thời gian từ go-live đến lúc bạn thật sự rời đi gọi là hypercare.

Một FDE làm hypercare tốt cần làm được ba việc: chốt điều kiện rút từ trước, xếp đủ người trực, và bàn giao sao cho không việc gì bị rơi giữa hai đội.

Thời lượng không phải thứ bạn quyết định

Supportbench định nghĩa hypercare là giai đoạn ổn định hệ thống có giới hạn thời gian sau go-live, thường kéo dài 2–6 tuần. Giai đoạn này kết thúc khi đạt một bộ tiêu chí cụ thể đã thống nhất từ trước, chứ không phải khi lịch báo hết.

Mỗi nơi đưa ra một con số khác. ERP Research nói 2–8 tuần sau go-live. Featurebase nói phần lớn kéo dài 1–8 tuần, còn các dự án ERP hay platform migration phức tạp có thể kéo tới 12 tuần hoặc hơn. Khoảng chênh rộng như vậy cho thấy số tuần là kết quả, không phải thứ bạn chọn trước.

Cái bạn chủ động được là bộ tiêu chí. Điểm kết thúc cũng phải rõ ràng: theo ERP Research, hypercare khép lại bằng việc chuyển giao chính thức phần hỗ trợ lâu dài sang help desk hoặc đội managed service. Phải có người nhận hệ thống, FDE không thể cứ thế biến mất.

Chốt tiêu chí rút trước ngày go-live

Panorama khuyên đặt tiêu chí rút trước go-live và dùng chỉ số đo được, như độ chính xác giao dịch, lượng yêu cầu hỗ trợ và mức giảm backlog. Lý do rất thực tế: sau go-live ai cũng mệt, nên tiêu chí đặt lúc đó rất dễ bị bẻ cho khớp với ngày mọi người muốn rút.

Supportbench đặt chuẩn chặt hơn: mọi điều kiện phải cùng đạt trong năm ngày làm việc liên tiếp. Một điều kiện cụ thể là lượng ticket không vượt quá 120% mức BAU dự kiến. Hai điều kiện khác liên quan đến con người: mọi workaround đều được ghi lại và có người sở hữu, và stakeholder phía khách hàng ký vào bản tóm tắt bàn giao.

Ví dụ: hệ thống đối soát hóa đơn cho phòng kế toán

Thử hình dung bạn deploy một hệ thống đối soát hóa đơn và go-live ngày 10 của tháng. Trước go-live, bạn cùng trưởng phòng kế toán ước tính mức BAU khoảng 5 ticket mỗi ngày làm việc. Ngưỡng 120% vì thế là 6 ticket mỗi ngày.

Tiêu chí	Cách đo	Ngưỡng trong ví dụ
Lượng ticket	Đếm theo ngày làm việc	Không quá 6/ngày (120% của 5)
Độ chính xác giao dịch	So kết quả đối soát với chứng từ	Con số khách đã chốt trước go-live
Backlog	Số ticket đang mở	Giảm dần qua từng tuần
Workaround	Danh sách workaround	Mỗi dòng có tên người sở hữu
Kỳ khóa sổ	Close cycle cuối tháng	Chạy hết, không gián đoạn
Sign-off	Bản tóm tắt bàn giao	Stakeholder phía khách đã ký

Giả sử sang tuần thứ ba, ticket xuống còn 5–6 mỗi ngày. Thứ Năm bỗng vọt lên 9 vì một lỗi import file. Chuỗi năm ngày bị đứt và phải đếm lại từ thứ Sáu. Bạn sẽ thấy bực, nhưng quy tắc này tồn tại chính là để chặn kiểu rút sớm vì “gần đạt rồi”.

Với hệ thống phục vụ tài chính, danh sách kiểm tra của Panorama hỏi thêm một câu: các hoạt động trong close cycle có chạy được mà không bị gián đoạn không?

Go-live ngày 10 thì kỳ khóa sổ cuối tháng chính là bài kiểm tra thật đầu tiên. Kể cả khi chuỗi năm ngày đã đủ trước đó, đừng rút trước khi kỳ khóa sổ đầu tiên chạy xong.

Trực dày ở đầu, mỏng dần về sau

Supportbench chỉ ra một lỗi phổ biến là xếp người trực hypercare bằng đúng mức BAU. Họ gợi ý hệ số 2.0–3.0 cho tuần 1–2 và 1.3–1.5 cho tuần 3–4, họp standup hằng ngày trong hai tuần đầu, sau đó giảm dần.

Hãy làm phép tính. Nếu bình thường có 2 người hỗ trợ hệ thống này, tuần 1–2 cần 4 đến 6 người, tuần 3–4 cần 2.6 đến 3 người. Trên thực tế, khoảng 2.6 người có thể là 2 người trực toàn thời gian cộng một FDE dành hơn nửa ngày cho hệ thống.

Featurebase nhấn mạnh hypercare hiệu quả nhất khi có người cụ thể sở hữu, thay vì cả đội gánh thêm bên cạnh việc thường ngày. Nếu bạn là FDE của dự án, hãy đưa tên mình vào lịch trực kèm khung giờ rõ ràng, đừng nhận kiểu “ai rảnh thì xem giúp”.

Rút từ từ và bàn giao giữa người với người

Featurebase khuyên giảm hỗ trợ từ từ, kèm một log ghi lại mọi rủi ro còn mở, thay vì cắt đột ngột. Một cách làm đáng thử cho FDE: ở tuần cuối, để người của help desk trực chính còn bạn ngồi cạnh, rồi mỗi ngày lùi thêm một bước.

OneUptime nói rõ: sự cố đang mở phải được chuyển giao trực tiếp giữa người với người, không thể chỉ đăng lên một tài liệu là xong. Vì vậy, nếu đến ngày bàn giao vẫn còn một lỗi import chưa xử lý xong, hãy gọi một cuộc ngắn với người nhận, cùng xem log, rồi để họ xác nhận đã nắm được việc.

Những lỗi khiến hypercare kéo dài hoặc đổ vỡ

Lỗi đắt nhất là rút theo lịch: hết bốn tuần là đi, bất kể ticket đang ở mức nào. Lỗi thứ hai là để đến sau go-live mới đặt tiêu chí, khi ai cũng muốn kết thúc. Khi đó tiêu chí sẽ bị nới cho vừa với mong muốn của mọi người.

Kế đến là để cả đội cùng gánh mà không ai thật sự sở hữu, rồi cắt hỗ trợ một lần mà không có log rủi ro. Với hệ thống tài chính, còn có lỗi rút trước kỳ khóa sổ đầu tiên. Lỗi phát sinh lúc khóa sổ sẽ quay lại với bạn, có khi lúc bạn đã sang dự án khác.

Biến hypercare thành điểm cộng khi đi phỏng vấn

Khi đọc JD của các vị trí FDE, hãy để ý những cụm như post-go-live support, hypercare hay handover. Nếu thấy chúng, hãy hỏi thẳng trong buổi phỏng vấn: bạn sẽ ở lại với khách bao lâu sau go-live, và ai sẽ nhận hệ thống sau khi bạn rời đi.

Trong CV, đừng chỉ ghi “hỗ trợ sau go-live”. Hãy mô tả việc bạn đã thiết kế tiêu chí rút, đưa lượng ticket về ngưỡng BAU và bàn giao có chữ ký của khách. Dùng số liệu thật của dự án bạn, vì người tuyển dụng sẽ hỏi bạn đo những con số đó như thế nào.

Khách hàng ít khi nhớ ngày go-live. Thứ họ nhớ là tuần đầu tiên hệ thống tự chạy ổn mà không ai phải gọi cho bạn.