1. Tổng quan — Ngày D-Day
Sau 6 tháng chuẩn bị — đánh giá nhu cầu (Bài 2), chọn nhà cung cấp (Bài 3), quản lý thay đổi (Bài 4), làm sạch dữ liệu (Bài 5), kiểm thử (Bài 6) — Việt Solution đến ngày go-live: ngày ERP chính thức thay thế Excel, trở thành hệ thống vận hành chính thức.
Ngày go-live là ngày căng thẳng nhất trong toàn bộ dự án. Mọi sự chuẩn bị đều quy về một câu hỏi: "Khi bấm nút chuyển đổi, mọi thứ có chạy được không?" Bài này kể chi tiết ngày go-live của Việt Solution — từ việc chọn ngày, lên kế hoạch dự phòng, xử lý sự cố trong tuần đầu, đến khi hệ thống thật sự ổn định.
Quyết định quan trọng nhất mà Việt Solution đưa ra là: không go-live "big bang" (chuyển toàn bộ 120 khách hàng cùng lúc) mà triển khai theo từng đợt — và quyết định đó đã cứu công ty.
2. Thách thức — Rủi ro của ngày chuyển đổi
2.1 Rủi ro "big bang"
Cách go-live phổ biến nhưng rủi ro nhất là "big bang" — chuyển toàn bộ hoạt động sang ERP trong một ngày. Nếu mọi thứ ổn thì tuyệt, nhưng nếu xảy ra sự cố, toàn bộ công ty bị tê liệt — không kê khai được cho ai, không nộp thuế được cho ai.
Với 120 khách hàng và deadline kê khai hàng tháng, Việt Solution không thể chịu rủi ro tê liệt toàn bộ. Một ngày ERP hỏng = 120 khách hàng chờ = có thể trễ deadline hàng loạt.
2.2 Rủi ro dữ liệu chuyển giao
Ngay cả khi dữ liệu đã làm sạch (Bài 5), việc chuyển từ môi trường thử nghiệm sang môi trường thật có thể phát sinh vấn đề. Ví dụ: một cột dữ liệu bị lệch trong quá trình import cuối cùng, hoặc định dạng ngày bị hiểu sai do cấu hình server khác nhau.
2.3 Rủi ro nhân viên chưa sẵn sàng
Dù đã đào tạo (sẽ kể chi tiết ở Bài 8), không phải nhân viên nào cũng sẵn sàng dùng ERP ngay trong ngày go-live. Sẽ có người quên cách làm, người bấm nhầm nút, người không đăng nhập được. Nếu tất cả 12 kế toán viên gặp khó cùng lúc, đội hỗ trợ sẽ quá tải.
2.4 Rủi ro ngoài ý muốn
Những thứ không lường trước: internet công ty bị đứt, nhà cung cấp ERP server bị sự cố, một khách hàng gửi chứng từ lỗi khiến ERP crash. Go-live là lúc mọi rủi ro tiềm ẩn bộc lộ cùng lúc.
3. Chiến lược — Triển khai theo 4 đợt
Thay vì big bang, Việt Solution chọn triển khai theo 4 đợt trong 4 tháng:
| Đợt | Tháng | Số khách hàng | Phân loại | Mục tiêu |
|---|---|---|---|---|
| Đợt 1 | Tháng 1 | 10 khách | Pilot — khách dễ, thân thiết | Kiểm tra thực tế, sửa lỗi |
| Đợt 2 | Tháng 2 | +30 khách (40 tổng) | Khách trung bình | Mở rộng, tối ưu |
| Đợt 3 | Tháng 3 | +40 khách (80 tổng) | Khách phức tạp | Chịu tải nặng |
| Đợt 4 | Tháng 4 | +40 khách (120 tổng) | Phần còn lại | Hoàn tất |
3.1 Tại sao chọn pilot 10 khách trước?
Đợt 1 (pilot) là bản thử nghiệm thật — ERP vận hành thật, khách hàng thật, nhưng quy mô nhỏ. Lý do chọn 10 khách đầu tiên:
- Khách hàng thân thiết: Dễ thông cảm nếu có sự cố, không đe dọa rời đi
- Khách hàng cấu trúc đơn giản: Ít ngoại lệ, ít khả năng phát sinh lỗi phức tạp
- Đại diện các loại hình: 4 thương mại, 3 dịch vụ, 2 sản xuất, 1 hộ kinh doanh — đủ đa dạng để phát hiện vấn đề
Trong đợt pilot, đội ngũ nội bộ và nhà cung cấp dành toàn lực cho 10 khách này — mọi vấn đề được xử lý ngay trong ngày, không để dồn.
3.2 Tiêu chí chuyển đợt
Không phải cứ đến tháng là tự động chuyển đợt. Mỗi đợt chỉ chuyển khi đạt tiêu chí ổn định:
- Tỷ lệ tờ khai đúng ≥ 98% (cho phép 2% lỗi nhỏ)
- Không có lỗi nghiêm trọng (tính sai thuế) trong 2 tuần liên tiếp
- Nhân viên phụ trách đợt hiện tại hài lòng (điểm ≥ 7/10)
- Đội hỗ trợ không quá tải (giải quyết sự cố trong cùng ngày)
Nếu đợt 1 chưa đạt, lùi đợt 2 — không cố chuyển vì "đến hạn". Việt Solution suýt lùi đợt 2 vì phát hiện 2 lỗi nghiêm trọng ở tuần 2 của đợt 1 — nhưng sửa kịp trong tuần 3, nên vẫn chuyển đúng thời gian.
4. Kế hoạch dự phòng — Khi ERP hỏng thì sao?
Go-live không thể không có kế hoạch dự phòng (contingency plan) — kế hoạch B khi ERP sự cố. Việt Solution chuẩn bị 2 lớp dự phòng:
Lớp 1: Rollback trong 48 giờ đầu
Trong 48 giờ đầu tiên của mỗi đợt, nếu xảy ra sự cố nghiêm trọng không xử lý được trong 4 giờ, kế hoạch là rollback — quay lại dùng Excel cho đợt đó, sửa ERP, thử lại sau.
Để rollback được, phải giữ Excel cũ hoạt động song song trong 48 giờ — không xóa, không đóng file. Đây là lưới an toàn quan trọng nhất.
Lớp 2: Quy trình thủ công dự phòng
Nếu ERP sự cố kéo dài (hơn 48 giờ), có quy trình thủ công dự phòng — kế toán viên dùng template Excel chuẩn (đã được chuẩn bị sẵn) để kê khai tạm thời, rồi nhập vào ERP khi hệ thống phục hồi. Mất thêm thời gian, nhưng đảm bảo không trễ deadline.
Kế hoạch giao tiếp khi sự cố
Khi sự cố xảy ra, giao tiếp quan trọng không kém kỹ thuật. Việt Solution chuẩn bị sẵn mẫu thông báo:
Mẫu thông báo khách hàng (khi sự cố):
"Kính gửi [Tên khách hàng],
Hệ thống của chúng tôi đang gặp sự cố kỹ thuật tạm thời,
dự kiến phục hồi trong [số giờ] giờ. Trong thời gian này,
chúng tôi sẽ [xử lý thủ công / thông báo lại sau].
Chúng tôi xin lỗi vì sự bất tiện và cam kết [kê khai đúng hạn /
bù đắp thiệt hại]."
Khách hàng thông cảm hơn nhiều khi được thông báo trước so với khi phát hiện trễ deadline mà không ai nói gì.
5. Tuần đầu tiên — Nhật ký go-live
Ngày 1 (Thứ Hai): Căng thẳng nhất
8h sáng, 12 kế toán viên đăng nhập ERP. Đội hỗ trợ (3 người nội bộ + 2 người nhà cung cấp) đứng sẵn.
- 8h-10h: 4 người không đăng nhập được (quên mật khẩu) → reset, ổn
- 10h-12h: 2 người nhập liệu bị lỗi (không hiểu giao diện) → hướng dẫn tại chỗ
- 14h-16h: ERP chậm khi 8 người dùng cùng lúc → nhà cung cấp tăng tài nguyên server
- Cuối ngày: 8/10 khách pilot được xử lý, 2 khách dở — hoàn thành sáng hôm sau
Kết quả ngày 1: không có sự cố nghiêm trọng, chỉ là những "vấp" nhỏ do chưa quen. Đội hỗ trợ giải quyết tất cả trong ngày.
Ngày 2-3: Tối ưu hóa
Sau ngày 1, đội hỗ trợ tổng hợp danh sách 12 câu hỏi thường gặp — và gửi cho toàn bộ nhân viên để họ tự tham khảo. Các câu hỏi như:
- "Làm sao tìm khách hàng cũ?" → Gõ mã hoặc tên vào ô tìm kiếm
- "Tại sao tờ khai không nộp được?" → Kiểm tra còn trường nào đỏ (bắt buộc) chưa điền
- "Làm sao xem lịch sử kê khai?" → Vào hồ sơ khách → tab "Lịch sử"
Giảm 60% câu hỏi lặp lại — nhân viên tự giải quyết được phần lớn vấn đề.
Ngày 4-5: Ổn định
Đến cuối tuần đầu, 10 khách hàng pilot được xử lý trọn vẹn. Kế toán viên bắt đầu quen, tốc độ tăng lên. Đội hỗ trợ chỉ còn xử lý 2-3 câu hỏi/ngày — chủ yếu là tính năng nâng cao.
Tuần 2: Tự tin hơn
Tuần thứ 2, kế toán viên bắt đầu chủ động đề xuất cải tiến — "có thể thêm nút lọc theo tháng không?", "có thể xuất Excel từ dashboard không?". Đây là dấu hiệu tích cực — họ đã chuyển từ "sợ dùng" sang "muốn dùng tốt hơn".
6. Sự cố lớn nhất — Và cách xử lý
Sự cố nghiêm trọng nhất xảy ra vào ngày 10 của đợt 1 — kế toán trưởng phát hiện tờ khai thuế GTGT của 1 khách pilot bị tính sai 2,3 triệu đồng. Lý do: ERP quy đổi đơn vị tính giữa "tấm" và "m²" theo cấu hình mặc định, nhưng khách hàng này dùng đơn vị "m³".
Phản ứng sai (theo phản xạ đầu tiên): hoảng loạn
Nếu hoảng, sẽ thông báo sai, xử lý sai, gây hoang mang.
Phản ứng đúng: quy trình 4 bước
- Cô lập: Đánh dấu khách hàng này là "đang sự cố", không nộp tờ khai cho đến khi sửa xong
- Thông báo: Giám đốc gọi trực tiếp cho khách hàng, giải thích, xin thêm thời gian — khách hàng thông cảm vì được báo trước
- Sửa lỗi: Nhà cung cấp sửa cấu hình quy đổi đơn vị trong 6 giờ
- Kiểm tra lại: Kế toán trưởng tính tay lại, xác nhận đúng, mới nộp tờ khai
Sự cố được xử lý trong 1 ngày, không ảnh hưởng đến 9 khách pilot còn lại. Bài học: sự cố không tránh được, cách xử lý mới quyết định hậu quả.
7. Kết quả — 4 đợt hoàn tất trong 4 tháng
| Đợt | Thời gian | Số khách | Sự cố nghiêm trọng | Tỷ lệ đúng |
|---|---|---|---|---|
| Đợt 1 | Tháng 1 | 10 | 1 (xử lý trong ngày) | 97% |
| Đợt 2 | Tháng 2 | +30 (40) | 0 | 99% |
| Đợt 3 | Tháng 3 | +40 (80) | 1 (server chậm, xử lý 2 giờ) | 98% |
| Đợt 4 | Tháng 4 | +40 (120) | 0 | 99% |
| Tổng | 4 tháng | 120 | 2 sự cố | 98,5% |
Tại sao đợt sau ít sự cố hơn?
Mỗi đợt đều mang lại bài học — lỗi phát hiện ở đợt trước được sửa cấu hình, cập nhật tài liệu hướng dẫn, đào tạo lại. Đợt sau thừa hưởng kinh nghiệm đợt trước, nên ít vấp hơn.
Nếu go-live big bang (120 khách cùng lúc), 2 sự cố nghiêm trọng của đợt 1 và đợt 3 sẽ xảy ra cùng lúc — đội hỗ trợ quá tải, không thể xử lý kịp, dẫn đến trễ deadline hàng loạt. Triển khai theo đợt phân tán rủi ro theo thời gian.
8. Bài học rút ra
8.1 Dành cho công ty dịch vụ kế toán thuế
- Đừng big bang — hãy triển khai theo đợt: Cho dù hấp dẫn muốn xong nhanh, rủi ro big bang quá cao. 4 đợt trong 4 tháng tốn lâu hơn nhưng an toàn hơn gấp nhiều lần. Mỗi đợt là cơ hội sửa lỗi trước khi lan rộng
- Pilot 10 khách là đủ: Không cần pilot 30-50 khách. 10 khách đại diện, được hỗ trợ tận tình, đủ để phát hiện 90% vấn đề. Quá nhiều khách pilot khiến đội hỗ trợ phân tán
- Luôn có kế hoạch rollback: Trong 48 giờ đầu của mỗi đợt, giữ Excel cũ hoạt động. Nếu ERP sự cố nghiêm trọng, quay lại Excel — không cố gắng sửa khi áp lực cao
- Giao tiếp khi sự cố quan trọng như kỹ thuật: Khách hàng thông cảm khi được báo trước. Đừng giấu sự cố — báo rõ, xin lỗi, cam kết xử lý. Uy tín nằm ở cách xử lý, không phải ở việc không bao giờ sai
8.2 Lời khuyên từ Giám đốc Việt Solution
"Ngày go-live, tôi đến công ty từ 6h sáng — dù nhân viên 8h mới vào. Tôi ngồi xem nhật ký hệ thống, đếm từng lỗi, tim đập nhanh hơn cả ngày khai trương công ty. Nhưng rồi mọi thứ ổn — không phải vì may mắn, mà vì 6 tháng chuẩn bị đã trả lời hết câu hỏi 'nếu sai thì sao'. Đợt 1 chỉ có 10 khách, nếu sai cũng chỉ 10 — sửa được. Nếu big bang 120 khách mà sai, tôi không biết phải làm sao. Bài học lớn nhất: go-live không phải khoảnh khắc anh nhảy — đó là chuỗi bước nhỏ có lưới an toàn. Chậm mà chắc, không nhanh mà đổ."
9. Kết luận
Go-live là khoảnh khắc mà mọi sự chuẩn bị được kiểm tra thực tế. Không có dự án ERP nào go-live hoàn toàn suôn sẻ — sẽ có sự cố, sẽ có vấp. Câu hỏi không phải "có sự cố không?" mà là "khi sự cố xảy ra, ta xử lý thế nào?"
Câu chuyện của Việt Solution cho thấy: triển khai theo đợt, có kế hoạch rollback, giao tiếp minh bạch — đó là bộ ba an toàn cho go-live. 4 tháng có vẻ dài, nhưng so với rủi ro big bang thất bại (có thể mất 1 năm phục hồi), 4 tháng là giá rẻ.
Bài tiếp theo (Bài 8) sẽ đào sâu vào yếu tố con người — đào tạo: làm sao biến nhân viên từ "biết dùng" thành "dùng giỏi", từ "làm theo" thành "làm chủ" ERP.
Nguyên tắc vàng: "Go-live không phải đích đến — đó là khởi đầu. Đừng coi ngày go-live là ngày kết thúc dự án. Đó là ngày bắt đầu vận hành thật, và vận hành thật mới là thử thách dài hạn. Hãy chuẩn bị cho nó như chuẩn bị cho một cuộc đ Marathon — không phải nước rút 100 mét."