Checklist go-live hai phía

Không có gì trong checklist bắt được tình huống này, bởi toàn bộ checklist đó nói về hệ thống.

Chỗ thiếu của checklist một cột

Nguyên nhân rất dễ hiểu và cũng vì thế mà khó sửa: bạn viết checklist cho những thứ bạn kiểm soát được.

Bên triển khai kiểm soát được hệ thống, nên phần hệ thống thì đầy đủ tới từng cấu hình. Còn nhân sự phía khách, dữ liệu mà phía khách phải cung cấp, và trạng thái sẵn sàng của những phần mềm khác đang tham gia vào bức tranh thì nằm ngoài tầm với, nên chúng không được viết ra; và cái gì không được viết ra thì không ai kiểm, không ai nhắc, không ai chịu trách nhiệm.

Điểm mấu chốt của cả bài nằm ở đây. Ngày go-live không phải là ngày một bên bàn giao cho bên kia, nó là ngày nhiều bên cùng làm một lúc, và checklist phải phản ánh đúng chuyện đó thì mới có tác dụng.

Bộ template kế hoạch mà tôi dùng giải quyết chuyện này bằng một cách rất gọn: mỗi dòng công việc có một cột ghi trách nhiệm, và cột đó gồm là bên triển khai, doanh nghiệp, bên thứ 3. Chỉ ba giá trị thôi, nhưng vì mỗi dòng đều phải điền nên người lập kế hoạch buộc phải nghĩ tới phía bên kia ở từng dòng một, thay vì nghĩ tới họ một lần rồi quên.

Cột của bên triển khai

Phần này gồm sáu nhóm việc, và cả sáu đều xoay quanh một chuyện duy nhất là dựng cho khách một hệ thống thật để chạy.

• Nhóm thứ nhất là module, tức cài đủ những phân hệ nằm trong phạm vi.
• Nhóm thứ hai là triển khai phần đã lập trình, tức đưa toàn bộ những gì đội phát triển làm thêm lên chính hệ thống này chứ không phải chỉ lên môi trường thử.
• Nhóm thứ ba là cấu hình, tức bật tắt tính năng ở từng phân hệ theo đúng phương án đã chốt với khách.
• Nhóm thứ tư là master data.
• Nhóm thứ năm là phân quyền cho người dùng.
• Nhóm thứ sáu là tích hợp với các hệ thống bên ngoài, chẳng hạn hóa đơn điện tử, dịch vụ tin nhắn, hay phần mềm kế toán mà doanh nghiệp đang dùng.

Riêng nhóm tích hợp có hai điều kiện phải chốt trước chứ không chốt trong ngày. Điều kiện thứ nhất là cả hai bên phải có môi trường thật và có khóa (key) kết nối của chính môi trường (production) đó, chứ không phải khóa của môi trường thử (staging) vốn vẫn đang dùng suốt mấy tháng qua. Điều kiện thứ hai là cấu trúc dữ liệu hai bên phải khớp nhau, và chuyện đó lẽ ra đã được xử lý từ giai đoạn phân tích chứ không phải phát hiện ở đây, bởi phát hiện ở đây thì không còn thời gian để sửa.

Cần lưu ý rằng dựng bản production là một bước riêng chứ không phải hệ quả tự nhiên của việc bạn đã dựng bản thử trước đó. Nó là một hệ thống mới hoàn toàn, và mọi thứ đã làm trên bản thử đều phải được làm lại một cách có kiểm soát; đây chính là lý do bước này cần một danh sách của riêng nó thay vì một dòng trong kế hoạch, và cũng là lý do nó hay bị đánh giá thấp về khối lượng.

Cột của khách hàng

Ba nhóm việc, và nhóm cuối là nhóm hay bị bỏ sót nhất trong cả checklist.

Nhóm thứ nhất là nhân sự. Ai sẽ ngồi ở mỗi vị trí trong ngày đầu, người đó đã được đào tạo chưa, và nếu người đó nghỉ đột xuất thì ai thay. Câu hỏi cuối nghe như lo xa, nhưng ngày go-live rất hay trùng với ngày có người nghỉ, bởi đó cũng là ngày căng thẳng nhất với chính họ.

Nhóm thứ hai là dữ liệu mà phía khách phải cung cấp để nạp lên hệ thống. Đây là chỗ thường trượt lịch, và trượt vì một lý do rất người: việc chuẩn bị file cho dự án nằm ngoài công việc hằng ngày của một nhân viên vốn đã bận, nên nó luôn bị xếp sau việc chính của họ, và bạn chỉ phát hiện ra khi hỏi tới.

Nhóm thứ ba là trạng thái sẵn sàng của những phần mềm mà hệ thống mới sẽ tích hợp hoặc trao đổi dữ liệu. Đây không chỉ là chuyện kỹ thuật đã thông hay chưa, mà là chuyện bên kia đã sẵn sàng vận hành thật hay chưa; và tình huống hay gặp là doanh nghiệp không bỏ hẳn hệ thống cũ ngay mà chạy song song một thời gian, khiến ngày go-live của bạn phụ thuộc vào một bên không tham gia bất kỳ buổi họp dự án nào của bạn.

Con người ở cả hai phía

Ngoài việc và dữ liệu thì còn một cột nữa mà rất ít checklist kẻ ra, đó là người trực trong ngày.

Ba câu cần trả lời. Bên triển khai có bao nhiêu người, ai ở đâu, và trực trong khung giờ nào. Bên khách có bao nhiêu người, và ai là đầu mối duy nhất để hai bên liên lạc. Khi có việc gấp thì ai gọi được cho ai, tức là một danh sách số điện thoại thật chứ không phải một nhóm chat.

Điểm cần nhấn ở đây là khung giờ trực phải bám theo ca làm việc của khách chứ không bám theo giờ hành chính của bên triển khai; cách tính ca và cách bố trí người cho những doanh nghiệp chạy nhiều ca thì tôi để ở bài về hai tuần đầu sau go-live, vì phần đó kéo dài hơn một ngày.

Tiêu chí go hay no-go

Đây là chỗ mà rất nhiều dự án bước vào ngày go-live mà không có gì trong tay ngoài cảm giác của phòng họp.

Một tiêu chí dùng được phải đo được và phải có ngưỡng. Câu "hệ thống đã ổn định" thì không đo được, còn câu "không còn vướng mắc nào ở mức chặn nghiệp vụ, và số vướng mắc mức trung bình đang mở không vượt quá một ngưỡng đã thống nhất" thì đo được; quan trọng hơn, nó buộc hai bên phải bàn về ngưỡng đó từ trước thay vì tranh luận vào phút chót khi ai cũng đang căng.

Ba nhóm tiêu chí đáng đặt ngưỡng như sau. Nhóm thứ nhất là trạng thái danh sách vướng mắc, gồm số lượng còn mở theo từng mức nghiêm trọng. Nhóm thứ hai là kết quả đối soát dữ liệu với hệ thống cũ, và ở đây chuẩn không phải là chênh lệch bằng không mà là mọi chênh lệch đều giải thích được. Nhóm thứ ba là mức độ sẵn sàng của người dùng, thứ hay bị quên nhất và cũng dễ đo nhất — chẳng hạn tỷ lệ người sẽ thao tác trong tuần đầu đã dự đào tạo, và việc từng vai trò đã tự chạy hết luồng chính của mình ít nhất một lần trên dữ liệu thật hay chưa.

Bên cạnh ngưỡng thì phải có một người ký. Một quyết định go-live mà không ai đứng tên là một quyết định mà sau này không ai bảo vệ được, và cũng là quyết định dễ bị đẩy tới bởi áp lực lịch thay vì bởi trạng thái thật của hệ thống — điều mà một chữ ký, dù chỉ là hình thức, cũng làm chậm lại đủ để có người nhìn lại danh sách một lần nữa.

Kịch bản rollback

Không ai muốn dùng tới nó, và chính vì thế mà nó hay bị bỏ cho tới lúc cần.

Kịch bản rollback phụ thuộc vào một câu hỏi duy nhất, đó là doanh nghiệp có hệ thống nào đang chạy song song hay không.

Nếu có thì tình huống dễ hơn nhiều, bởi hệ thống cũ vẫn còn đó và phương án dự phòng là tiếp tục dùng nó cho phần nghiệp vụ đang gặp sự cố, nhờ vậy bạn có thời gian xử lý mà không chặn hoạt động của doanh nghiệp. Thứ cần chuẩn bị trước là một quy ước ghi nhận: những giao dịch phát sinh trong khoảng thời gian đó nằm ở hệ thống cũ, và phải có người chịu trách nhiệm nhập lại chúng lên hệ thống mới sau khi khắc phục xong, nếu không thì bạn vừa tạo ra một lỗ hổng dữ liệu ngay trong tuần đầu.

Nếu không có, tức doanh nghiệp đã chuyển hẳn, thì phương án phải là quay lại ngay cách làm việc trước đó, và chuyện này chỉ khả thi nếu bạn đã chuẩn bị từ trước gồm một bản sao lưu ở thời điểm ngay trước go-live cùng một mốc thời gian rõ ràng để ra quyết định.

Điểm mấu chốt là mốc quyết định phải được đặt trước ngày go-live. Không có mốc thì cả nhóm sẽ rơi vào trạng thái cố thêm một chút, và trạng thái đó có thể kéo dài hết cả ngày trong khi doanh nghiệp không bán được hàng, không xuất được kho, và không ai dám là người đầu tiên nói ra chữ dừng.

Việc phải làm xong trước ngày go-live, không phải trong ngày

Còn hai thứ nữa mà đặc điểm chung của chúng là làm trong ngày thì đã muộn.

Thứ nhất là chỗ ghi nhận vướng mắc. Người dùng cần biết ghi vào đâu, ghi những thông tin gì, và bao lâu thì có phản hồi; không phổ biến trước thì tới ngày go-live họ sẽ báo lỗi theo cách tiện nhất với họ, và cách tiện nhất luôn là nhắn vào nhóm chat. Cách tổ chức dòng vướng mắc trong những ngày đầu thì tôi để ở bài sau, nhưng việc phổ biến thuộc về hôm nay.

Thứ hai là nhật ký triển khai, tức ghi lại đã đẩy cái gì lên hệ thống vào thời điểm nào. Đây là một tài liệu rất mỏng và tôi đã nói về nó ở bài bộ tài liệu dự án ERP; điều cần làm trước ngày go-live chỉ là chốt xem ai ghi và ghi ở đâu, bởi từ ngày mai trở đi mỗi lần đẩy mã đều có thể tác động tới chức năng đang chạy và tới dữ liệu đã phát sinh.

Bảng checklist hai cột

Gộp lại thì có thể dựng thành bảng dưới đây. Nó không phải một biểu mẫu chuẩn, chỉ là cách sắp xếp lại những gì đã nói ở trên sao cho mỗi dòng đều buộc bạn nhìn sang cột bên phải.

Nhìn cột bên phải thì thấy ngay điều mà bài này muốn nói: mười một dòng thì cả mười một đều cần phía khách làm một việc gì đó. Một checklist không có cột đó không phải là checklist ngắn hơn, nó là checklist đang lặng lẽ giả định rằng một nửa số việc sẽ tự xong.

Sau khi bấm nút thì bắt đầu một giai đoạn có tính chất khác hẳn mọi giai đoạn trước, và không có danh sách nào chuẩn bị hết được cho nó.