Bài này trả lời: Hypercare 30 ngày sau go-live Các phần: tình huống thật — trả lời ngắn — điều gì cản trở — framework — bảng thực thi — ví dụ minh họa — FAQ — checklist tự kiểm. Đọc 12 phút, dùng được tuần này.
Tình huống minh họa: Ngày go-live mọi người khen suôn sẻ. Ngày 3: 47 tin Zalo đêm về "không in được phiếu", "số này sao lệch" — consultant trả hết, ngày ngầy. Ngày 10: support dọn dần "khách đã ổn" — nhưng "ổn" nghĩa là người ta thôi hỏi vì... chuyển sang ghi giấy tay làm ngoài hệ thống. Ngày 30 không có tiêu chí đóng nào: ca hypercare nhạt dần, tới khi một vấn đề thật (đối soát cuối tháng sai) nổ ra — mọi thứ về hệ thống bị nghi, không ai phân biệt "hệ thống sai" với "chưa ai dạy chỗ này".
Trả lời ngắn: Hypercare không phải "còn ngồi hỗ trợ" — là chế độ hỗ trợ có cấu trúc và có điểm dừng: ca trực rõ người rõ giờ, mọi yêu cầu qua phiếu (không Zalo trôi), phân loại theo mức ảnh hưởng với SLA, 3 con số đo mỗi tuần (phiếu sinh, phiếu nguyên nhân hệ thống vs người dùng, nhóm chức năng tập trung), và tiêu chí đóng rõ: phiếu giảm ổn định + nhóm train-the-trainer nhận việc + top vấn đề có gốc xử. Không cấu trúc thì hypercare hoặc chết dần (người dùng lặng lẽ quay về Excel), hoặc kéo vô hạn (consultant thành support vĩnh viễn).
Bài này dành cho ai?
Dành cho đội triển khai và quản lý dự án lo giai đoạn sau go-live — nơi 47 tin Zalo đêm và câu hỏi "bao giờ hết hỗ trợ" quyết định dự án được coi thành công hay không.
Điều gì đang xảy ra?
- Hỗ trợ sau go-live qua Zalo — không phiếu, không số liệu.
- Ca trực "ai rảnh trả lời" — không người chịu.
- Phân biệt lỗi hệ thống với chưa được dạy — bằng cãi.
- Không tiêu chí đóng — hypercare chết dần hoặc kéo vô hạn.
- Vấn đề lặp không thống kê — chỗ nào dạy thiếu không biết.
- Người dùng lặng lẽ quay về Excel — không ai thấy.
Điều người đọc muốn đạt được
Chạy hypercare 30 ngày có cấu trúc: ca trực, phiếu theo mức ảnh hưởng + SLA, thống kê nguyên nhân theo tuần, tiêu chí đóng bằng 3 con số.
Điều gì đang cản trở?
| Cản trở | Biểu hiện | Hệ quả |
|---|---|---|
| Zalo là kênh chính | Câu hỏi trôi sau 3 ngày | Không số liệu, không học được gì |
| Không ca trực | Ai rảnh trả — đêm không ai | Vấn đề nhỏ thành cháy |
| Không phân loại | Lỗi hệ thống lẫn chưa dạy | Cãi nhau thay vì xử |
| Không tiêu chí đóng | Nhạt dần hoặc kéo vô hạn | Hai kiểu thiệt hại cùng lúc |
| Không thống kê | Vấn đề lặp không thấy | Đào tạo không biết dạy bù gì |
Tác động nếu không xử lý
- Không số liệu, không học được gì
- Vấn đề nhỏ thành cháy
- Cãi nhau thay vì xử
- Hai kiểu thiệt hại cùng lúc
- Đào tạo không biết dạy bù gì
Insight: Hypercare là giai đoạn duy nhất nhìn thấy sự thật về chất lượng triển khai: mọi lỗ hổng đào tạo, mọi cấu hình thiếu, mọi dữ liệu bẩn đều hiện ra trong 30 ngày — qua phiếu. Vì vậy phiếu không phải gánh nặng quản trị: là camera ghi lại chỗ nào dự án chưa xong thật. Đóng hypercare đúng lúc cũng quan trọng như mở: kéo dài vô hạn biến consultant thành support miễn phí, đóng sớm biến người dùng thành kẻ phản bội hệ thống (quay về Excel) — 3 con số (phiếu/tuần giảm, tỷ lệ nguyên nhân người dùng ổn, nhóm chức năng hết tập trung) là phao quyết định.
Framework (5 bước)
TUẦN 1 — Ca trực đặc: ngày 2 người + đêm 1 người on-call, mọi kênh dồn về phiếu ↓ TUẦN 2–3 — Ca trực thường: sáng duyệt phiếu treo + xử nhóm; thống kê nguyên nhân ↓ TUẦN 2–3 — Đào tạo bù đúng chỗ: nhóm chức năng nào nhiều phiếu nhất dạy lại nhóm đó ↓ TUẦN 4 — Chuyển giao: key user nhận nhóm câu thường gặp (SOP + slot hỏi cuối cùng) ↓ ĐIỂM ĐÓNG — 3 con số: phiếu/tuần < ngưỡng, nguyên nhân người dùng <40%, không nhóm nào tập trung
Lộ trình học theo luồng nghiệp vụ, lớp theo vai, bài thực hành chấm theo tình huống thật — học xong kể được luồng, không chỉ bấm được nút.
Khám phá EcoTalent →Bảng thực thi (To-Be)
| Mức phiếu | Định nghĩa | SLA phản hồi | Người xử |
|---|---|---|---|
| P1 — chặn việc | Không phát sinh phiếu/giao dịch được | 30 phút (giờ làm) / on-call đêm | Consultant trực |
| P2 — sai lệch | Làm được nhưng số/tiến trình lệch | 4 giờ | Consultant + key user |
| P3 — hỏi cách làm | Chưa biết thao tác, không sai hệ thống | 8 giờ — gom lớp bù tuần | Key user |
| P4 — đề xuất | Muốn thêm/cải thiện sau ổn định | Đóng gói vào backlog | PM duyệt |
Ví dụ minh họa — số liệu giả định
Số liệu giả định để minh họa, không phải thống kê thực tế.
Cùng dự án 60 người dùng — hypercare 2 kiểu trong 30 ngày.
| Chỉ số | Zalo + ai rảnh | Phiếu + ca + tiêu chí đóng |
|---|---|---|
| Câu hỏi tuần 1 | ~120 tin rải Zalo | 98 phiếu — phân loại đủ 4 mức |
| Câu hỏi tuần 4 | Không đếm được | <15 phiếu — đường giảm hiện |
| Biết chỗ dạy thiếu | Không | Tuần 2: 60% phiếu nhóm Kho — dạy bù ngay |
| Key user nhận việc | Không | Tuần 4: P3 chuyển hết qua key user |
| Quyết định đóng | Cảm tính "hình như ổn" | 3 con số đạt — đóng, chuyển gói hậu mãi |
Triển khai 4 tuần đầu
Tuần 1: chọn đúng nơi bắt đầu theo framework trên — dựng tối thiểu dữ liệu/thành phần bắt buộc, chưa hoàn thiện. Tuần 2: chạy thử 1 luồng/vòng đầy đủ trên dữ liệu thật hoặc giả định có tính cách; ghi vướng vào danh sách. Tuần 3: xử 3 vướng lớn nhất + mở rộng nửa còn lại; bắt đầu đo 1–2 con số so với cách làm cũ. Tuần 4: chốt thành quy trình có người chịu + số liệu theo tuần — nếu tuần 4 vẫn cần đôn đốc từng ngày, quay lại xem bước nào trong framework gây ma sát và đơn giản hóa nó.
Quan niệm sai và thực tế
| Quan niệm sai | Thực tế | Hệ quả nếu tin sai |
|---|---|---|
| ['Vấn đề này giải quyết bằng thêm công sức cá nhân', 'Giải bằng cấu trúc — quy trình + dữ liệu tại nguồn + người chịu', 'Người giỏi kiệt sức, vấn đề tái phát khi người đó nghỉ'] | ['Đợi khi nào "rảnh" sẽ làm', 'Chuyện để dành never cheaper — dữ liệu rối thêm mỗi ngày chờ', 'Chi phí sửa tăng theo thời gian trì hoãn'] | ['Cách cũ vẫn chạy — chưa cần đổi', 'Vẫn chạy nghĩa là vẫn trả chi phí vô hình mỗi ngày', 'Tiền mất âm thầm nhân lên trong khi đối thủ đi trước'] |
Câu hỏi thường gặp
Người dùng cứ nhắn Zalo vì tiện — ép phiếu kiểu gì?
Giai đoạn chuyển 2 tuần: Zalo vẫn trả, nhưng trả bằng link phiếu + paste nội dung vào giúp (tạo phiếu hộ rồi gửi link — người dùng thấy phiếu nhanh hơn Zalo vì có SLA). Sau tuần 2: Zalo chỉ nhận P1 (chặn việc). Hành vi chuyển bằng trải nghiệm nhanh hơn, không bằng lệnh cấm.
Phiếu P3 nhiều quá — có đáng ghi phiếu?
Đáng nhất: P3 là bản đồ chỗ đào tạo thiếu. 60% P3 nhóm Kho nghĩa là lớp kho dạy sơ hoặc SOP chưa đủ — gom thành 1 lớp bù đúng chỗ thay trả lẻ 40 câu. Không ghi P3 thì hypercare chỉ thấy "người dùng yếu" — không thấy mình dạy thiếu.
Nhà tư vấn nói hypercare tính phí — hợp lý không?
Hợp lý nếu tách rõ: gói ổn định 30 ngày có giới hạn (trong hợp đồng từ đầu — giờ, phạm vi, kênh), vượt gói tính thêm. Không hợp lý nếu "hypercare" là chỗ hútvô hạn việc triển khai thiếu: lỗi cấu hình/lỗi chưa hoàn thành là việc dự án, không phải việc hỗ trợ. Phân loại phiếu chính là ranh giới thanh toán: lỗi hệ thống — bên triển khai; chưa dạy — đào tạo; muốn thêm — change request.
30 ngày có đủ không — ngành dày nghiệp vụ?
Chu kỳ hypercare nên phủ ít nhất 1 vòng kết sổ/tháng khóa (nhiều vấn đề chỉ lộ cuối kỳ). 30 ngày đủ cho 90% loại; ngành có chu kỳ quý phức tạp có thể 45 ngày với ca trực giảm dần (tuần 5–6 chỉ on-call). Nguyên tắc: thời lượng theo chu kỳ nghiệp vụ lặp lại, không theo cảm giác "khách đang có vẻ ổn".
Key user chưa đủ mạnh nhận P3 tuần 4 — làm sao?
Lùi giao tiếp phần: P3 nhóm nào key user chưa chắc thì giữ consultant thêm 1 tuần kèm slot "key user trả lời — consultant nghe". Giao theo nhịp từng nhóm chức năng (nhóm mạnh nhận trước), không giao cả loạt deadline tuần 4 cứng nhắc.
Bài học một câu?
Hypercare không phải "ngồi hỗ trợ thêm" — là 30 ngày có cấu trúc: phiếu thay Zalo, ca thay ai-rảnh, 3 con số quyết định đóng — và mọi phiếu là camera quay lại chỗ dự án chưa thật xong.
Checklist tự kiểm tra
3 dấu hiệu bạn cần bài này
(1) Hỗ trợ sau go-live qua Zalo — không phiếu, không số liệu. (2) Phân biệt lỗi hệ thống với chưa được dạy — bằng cãi. (3) Người dùng lặng lẽ quay về Excel — không ai thấy.
Nếu ít nhất 2 trong 3 dấu hiệu trên đúng với tình huống của bạn, framework trong bài đáng áp dụng ngay tuần này — đừng đợi đến khi dấu hiệu thứ ba "đau" thêm. Nếu chỉ có 1 dấu hiệu, hãy đánh dấu bài và quay lại khi dữ kiện đủ: áp dụng nửa vời một framework thường tốn công hơn chờ đúng lúc.
Kết luận
Hypercare 30 ngày là camera quay sự thật triển khai: phiếu thay Zalo, 4 mức với SLA, thống kê nguyên nhân tuần, đào tạo bù đúng nhóm nhiều phiếu nhất, key user nhận dần P3 — và đóng bằng 3 con số chứ không cảm tính. Không cấu trúc này, sau go-live chỉ có 2 kết cục đều xấu: người dùng lặng lẽ quay về Excel, hoặc consultant thành bộ phận support không lương.
Bước tiếp theo thực dụng: chọn đúng 1 hạng mục nhỏ nhất từ framework trên — vừa đủ để làm trong 1 tuần và đo được 1 con số. Làm trọn 1 hạng mục nhỏ tạo moment duy trì tốt hơn cố gắng làm 5 hạng mục cùng lúc rồi bỏ giữa chừng. Khi hạng mục đầu chạy đúng, hạng mục sau có sẵn người tin việc đang làm — và dữ liệu để mở rộng. Đó là cách mọi đội chuyển từ "biết nên làm" sang "đang làm được": một bước nhỏ trọn vẹn mỗi tuần, thay vì một kế hoạch lớn nằm giấy.