Nhiều dự án xem go-live là lúc deploy xong hệ thống lên production. Nhưng với một digital operations system, deploy chỉ là điều kiện cần. Go-live chỉ có ý nghĩa khi công việc thật bắt đầu chạy trên hệ thống, người dùng thật sự dùng được, và tổ chức có đủ ownership, runbook, readiness và improve loop để giữ cho việc adoption diễn ra thành công.
Go-live không phải là deploy: hệ thống chỉ thật sự “sống” khi người dùng dùng được
Trong nhiều dự án phần mềm, go-live thường được hiểu là một cột mốc kỹ thuật: deploy xong, có tài khoản, có dữ liệu, hệ thống mở được, vậy là xong. Nhưng với một digital operations system, cách hiểu đó thường chưa đủ.
Vì một hệ thống được deploy chưa chắc đã thật sự live. Và một hệ thống đã live về mặt kỹ thuật cũng chưa chắc đã được người dùng chấp nhận để làm việc hằng ngày. Thực tế không hiếm những dự án mà trên giấy tờ đã go-live, nhưng khi đi vào vận hành thì người dùng vẫn quay về Excel, chat nhóm, hoặc gọi nhau để xử lý việc. Hệ thống có mặt, nhưng vận hành thật vẫn chưa đi qua hệ thống.
Vì vậy, điểm mấu chốt của go-live không nằm ở việc đưa phần mềm lên production, mà nằm ở việc hệ thống có thật sự đi vào công việc và được người dùng áp dụng hay không.
Hiểu lầm phổ biến: xem go-live là điểm kết thúc
Một suy nghĩ rất phổ biến là: build xong, test xong, deploy xong, bàn giao xong, tức là dự án đã hoàn thành. Nhưng với các hệ thống phục vụ vận hành, go-live hiếm khi là điểm kết thúc. Thực ra, nó thường là điểm bắt đầu của một câu hỏi quan trọng hơn: Người dùng đã thật sự dùng hệ thống này để làm việc chưa?
Đó mới là bài test thật. Vì giá trị của hệ thống không nằm ở số màn hình đã build hay số workflow đã cấu hình. Giá trị chỉ xuất hiện khi:
-
người dùng biết phải làm gì trên hệ thống
-
công việc thật bắt đầu chạy qua hệ thống
-
các trục trặc đầu tiên được xử lý kịp thời
-
hệ thống tiếp tục được điều chỉnh để phù hợp hơn với thực tế sử dụng
Nói cách khác, go-live is just a beginning.
Go-live là chuyển trọng tâm từ development sang adoption
Trước go-live, trọng tâm của dự án nằm ở delivery: thiết kế, build, test, deploy.
Sau go-live, trọng tâm cần chuyển sang một thứ khác: adoption.
Từ thời điểm đó, câu hỏi không còn xoay quanh:
-
build đủ chưa
-
deploy xong chưa
-
bug kỹ thuật còn không
Mà là:
-
user đã dùng được chưa
-
công việc đã chạy trơn chưa
-
ai đang chịu trách nhiệm cho việc adoption
-
khi có vướng mắc thì ai theo dõi, ai hỗ trợ, ai quyết định điều chỉnh
Nếu không có sự chuyển trọng tâm này, hệ thống rất dễ rơi vào trạng thái quen thuộc: đã bàn giao nhưng chưa thật sự được dùng. Và khi đó, deployment có thể thành công, nhưng go-live thì chưa chắc.
Muốn go-live vững, phải có ownership rõ
Một hệ thống không tự được áp dụng chỉ vì đã training xong. Adoption luôn cần người chịu trách nhiệm.
Trong giai đoạn go-live, thường cần ít nhất ba vai trò rõ ràng.
1. Owner
Owner là người chịu trách nhiệm cho việc hệ thống được dùng thành công trong thực tế.
Không chỉ là “người sở hữu hệ thống”, mà là người phải nhìn vào những câu hỏi rất thực tế:
-
nhóm nào đã bắt đầu dùng thật
-
nhóm nào còn bị kẹt
-
luồng công việc nào chưa chạy trơn
-
thay đổi nào cần ưu tiên để adoption tốt hơn
Nếu không có owner đúng nghĩa, adoption rất dễ trở thành việc không ai thực sự dẫn dắt.
2. Admin
Admin giữ vai trò giám sát hệ thống từ góc nhìn vận hành. Công việc của họ không chỉ là cấp quyền hay chỉnh cấu hình, mà còn phải theo dõi xem hệ thống có đang thực sự hỗ trợ người dùng làm việc hay không:
-
user có vào được không
-
role có đúng không
-
dashboard có đúng theo vai trò không
-
workflow có bị nghẽn ở đâu không
Nếu owner chịu trách nhiệm về kết quả adoption, thì admin giữ cho hệ thống vận hành trơn tru hằng ngày.
3. Support
Support hiệu quả nhất thường không phải là một người kỹ thuật đứng ngoài quy trình, mà là một người dùng chủ chốt của chính hệ thống đó.
Lý do khá đơn giản. Người dùng mới thường không chỉ cần biết “bấm nút nào”. Họ cần một người đã từng dùng hệ thống để làm việc thật, hiểu các tình huống thực tế, và biết phải xử lý ra sao khi bị kẹt.
Một support như vậy giúp adoption diễn ra nhanh hơn rất nhiều, vì họ hỗ trợ từ góc nhìn công việc, không chỉ từ góc nhìn tính năng.
Runbook là thứ biến “được triển khai” thành “dùng được”
Một lý do rất phổ biến khiến hệ thống hụt hơi sau go-live là: người dùng đã được training, nhưng đến lúc làm việc thật thì lại không nhớ rõ phải làm gì.
-
phải làm theo bước nào
-
cần kiểm tra gì trước
-
gặp vấn đề thì xử lý ra sao
-
khi nào tự xử lý, khi nào phải escalated
Đó là lý do runbook rất quan trọng.
Runbook không phải là một tài liệu lý thuyết dài dòng. Nó giống một hướng dẫn vận hành thực tế, để bất kỳ ai tham gia cũng biết:
-
từng bước phải làm gì
-
cần check gì
-
khi nào có dấu hiệu bất thường
-
khi nào phải escalated và escalated cho ai
Một hệ thống mới rất dễ gặp khó khăn nếu tri thức vận hành chỉ nằm trong đầu team triển khai hoặc một vài người dùng giỏi. Runbook giúp biến tri thức đó thành cách làm có thể lặp lại và lan rộng.
Go-live readiness phải là readiness theo vận hành
Nhiều team đánh giá readiness bằng checklist kỹ thuật:
-
deploy xong
-
test pass
-
dữ liệu đã nạp
-
user có tài khoản
-
phân quyền đã set
Tất cả những điều này đều cần. Nhưng với một digital operations system, chúng vẫn chưa đủ.
Điều quan trọng hơn là những câu hỏi mang tính vận hành:
-
user có vào hệ thống và làm được việc thật không
-
role có thấy đúng màn hình, đúng queue, đúng dữ liệu không
-
quy trình có đủ rõ để công việc không bị nghẽn không
-
support đã sẵn sàng chưa
-
runbook đã sẵn sàng chưa
Nói ngắn gọn: một hệ thống có thể technically ready nhưng vẫn operationally not ready.
Và nếu hai mức readiness này không được phân biệt rõ, team rất dễ go-live quá sớm.
Go-live chỉ bền khi có improve loop
Go-live không phải là lúc ngừng thay đổi. Ngược lại, đó là lúc feedback thật bắt đầu xuất hiện.
Khi hệ thống được dùng trong công việc hằng ngày, người dùng sẽ rất nhanh nhận ra:
-
bước nào còn rườm rà
-
chỗ nào làm chậm công việc
-
điều gì chưa hợp với thực tế vận hành
-
thay đổi nào sẽ giúp làm việc dễ hơn và nhanh hơn
Vì vậy, sau go-live phải có một improve loop rõ ràng:
-
thu nhận feedback
-
đưa vào backlog
-
ưu tiên thay đổi
-
liên tục cải tiến để adoption tốt hơn
Nếu không có vòng lặp này, hệ thống rất dễ rơi vào hai trạng thái quen thuộc: hoặc bị đóng băng sau ngày go-live, hoặc bị sửa ad hoc theo từng phản ứng ngắn hạn. Cả hai đều làm adoption yếu đi theo thời gian.
Kết luận
Một hệ thống không trở nên “sống” chỉ vì đã deploy xong. Nó chỉ thật sự sống khi người dùng bắt đầu dùng nó để làm việc, khi công việc thật sự chạy qua nó, và khi có người chịu trách nhiệm giữ cho việc adoption đó diễn ra thành công.
Vì vậy, muốn go-live with confidence, đừng chỉ chuẩn bị deployment plan. Hãy chuẩn bị cho bốn thứ quan trọng hơn:
-
ownership rõ ràng
-
runbook đủ dùng
-
readiness theo vận hành
-
improve loop sau go-live
Go-live không phải là kết thúc của delivery. Nó là điểm bắt đầu của adoption.