Hai tuần đầu sau go-live

Đây là giai đoạn mà các bài viết về triển khai ERP thường không đi tới, vì phần lớn chúng kết thúc ở ngày go-live. Trong khi đó, theo cách một quản lý dự án lâu năm ở công ty triển khai mô tả lại, đây mới là lúc mọi thứ trở nên khó xử lý nhất: những bước trước đó dù làm sai tới đâu thì vẫn còn đường sửa, còn tới đây thì người dùng đã làm việc thật trên hệ thống.

Ba khác biệt của giai đoạn này

Ba khác biệt, và cả ba đều đổi cách bạn phải làm việc.

Khác biệt thứ nhất là không còn đường lùi bằng cách lùi lịch. Ở mọi giai đoạn trước, một sai sót đều xử lý được bằng cách sửa rồi chạy lại; tới đây thì mỗi giờ hệ thống không dùng được là một giờ doanh nghiệp không bán được hàng hoặc không xuất được kho, và cái giá đó rơi thẳng vào khách chứ không rơi vào lịch dự án.

Khác biệt thứ hai là số lượng người. Trước đó bạn làm việc với vài người của đội dự án phía khách; bây giờ là toàn bộ người dùng, và với một chuỗi vài chục cửa hàng mà mỗi nơi có vài nhân viên thì chỉ cần một tình huống nhỏ lặp lại ở mọi điểm là bạn có hàng chục tin nhắn về đúng một chuyện.

Khác biệt thứ ba là tính chất công việc. Bạn không còn xây gì nữa mà đang vận hành một dòng chảy, nên kỹ năng cần thiết đổi từ phân tích và thiết kế sang tổ chức và phân loại.

Và cần nhớ thêm một điều mà tôi đã nói ở bài về UAT và Pilot: dù người dùng đã chạm vào hệ thống ở giai đoạn kiểm thử, tâm thế lúc đó chưa phải tâm thế dùng thật. Hệ quả trực tiếp là phần lớn vướng mắc trong những ngày đầu không phải lỗi hệ thống mà là không biết thao tác ở đâu, hoặc thao tác sai nên chuyện hoàn toàn bình thường, nhưng nếu cả nhóm không lường trước thì sẽ hoảng khi thấy số lượng tăng vọt và tưởng hệ thống đầy lỗi.

Kênh nhận vướng mắc

Đây là quyết định tổ chức quan trọng nhất của cả giai đoạn, và nó phải được chốt trước ngày go-live chứ không phải sau khi đã ngập.

Thứ tự ưu tiên gồm ba mức:

• Tốt nhất là một biểu mẫu trực tuyến hoặc một file dùng chung để người dùng điền vào.
• Mức thứ hai là email.
• Mức cuối cùng, và là mức nên hạn chế tối đa, là nhắn tin trong nhóm chat.

Lý do nhóm chat đứng cuối không phải vì nó không tiện, nó tiện nhất, và đó chính là vấn đề. Tin nhắn trôi đi rất nhanh, một vấn đề bị nhắc ba lần bởi ba người khác nhau mà không ai biết là trùng, không có trạng thái nên không rõ cái nào đã xử lý xong, và tới cuối tuần thì bạn không có cách nào tổng hợp lại xem đã nhận bao nhiêu vấn đề và còn bao nhiêu cái treo.

Cần lưu ý rằng bạn không cấm được nhóm chat, và cũng không nên cố cấm, bởi đó là chỗ khách đã quen. Cách làm được là mỗi khi có người báo lỗi trong nhóm thì trả lời bằng một câu dẫn họ sang kênh chính, kiên trì làm vậy suốt tuần đầu, và tự mình chép những cái quan trọng sang kênh chính thay vì để chúng trôi mất.

Đồng thời, nếu công ty bạn có công cụ quản lý công việc và cấp được tài khoản cho phía khách thì đó là phương án tốt hơn cả file. Tuy nhiên có những khách không muốn dùng thêm một hệ thống nữa, và khi đó thì phải chấp nhận; điều nên làm là giải thích với họ rằng ghi vào đó thì hệ thống lưu lại toàn bộ và hai bên quản lý dễ hơn nhiều, chứ không áp đặt.

Dạy người dùng ghi một vướng mắc

Chọn được kênh mới là một nửa. Nửa còn lại là người dùng phải biết ghi cái gì vào đó, và điều này phải được phổ biến trước ngày go-live cùng lúc với việc giới thiệu kênh.

Không hướng dẫn thì họ ghi theo cách tự nhiên nhất, tức là mô tả cảm giác: cái này bị lỗi, không vào được, chậm quá. Những dòng như vậy không xử lý được, và bạn mất thêm một vòng hỏi lại cho mỗi dòng, nhân với số lượng vướng mắc của tuần đầu thì đó là rất nhiều thời gian.

Bốn thông tin tối thiểu cho một dòng dùng được:

• ai gặp và ở đâu
• đang làm việc gì trên màn hình nào
• kết quả mong đợi so với kết quả thực tế
• và một ảnh chụp màn hình

Ảnh chụp là thứ tiết kiệm nhiều thời gian nhất trong bốn thứ, nên đáng dành riêng vài phút trong buổi đào tạo để chỉ họ cách chụp.

Ngoài ra nên có sẵn một dòng mẫu đã điền đầy đủ ngay đầu file, bởi người ta bắt chước một mẫu có sẵn nhanh hơn nhiều so với đọc một bản hướng dẫn.

Vai trò của người phân tích

Ở giai đoạn này có một việc mà người làm phân tích làm tốt hơn hẳn các vai khác trong đội, đó là nhìn một vướng mắc và biết ngay nguyên nhân của nó thuộc nhóm nào.

Một quản lý dự án lâu năm ở công ty triển khai mà tôi có dịp học hỏi nói rất thẳng về chuyện này, rằng đây chính là chỗ BA thể hiện giá trị, bởi nhìn vào issue là biết vấn đề do đâu, trong khi người quản lý dự án nhiều khi không biết vì họ không phải người phân tích.

Vì sao vai trò này phân loại nhanh hơn các vai khác thì tôi đã nói ở bài về nghề BA ERP, và cách phân loại cụ thể theo từng nhóm nguyên nhân thì thuộc về bài phân biệt lỗi với yêu cầu phát sinh. Điều cần nhớ ở đây chỉ có một: phân loại phải xảy ra trước khi giao việc chứ không phải sau, bởi giao nhầm một chuyện cấu hình cho đội phát triển là bạn vừa đẩy một việc mươi phút vào hàng đợi của một người đang bận, và nó sẽ nằm đó vài ngày.

Bố trí người theo ca của khách

Không phải doanh nghiệp nào cũng làm giờ hành chính, và đây là chỗ mà kế hoạch trực rất hay được lập theo lịch của bên triển khai thay vì lịch của bên sử dụng.

Công ty sản xuất có thể chạy ba ca; chuỗi bán lẻ quần áo hay chuỗi ăn uống có thể mở từ sáu giờ sáng tới mười giờ tối. Nếu bạn bố trí người trực theo giờ của mình thì phần lớn thời gian vận hành thật của khách không có ai hỗ trợ, và một vướng mắc phát sinh lúc bảy giờ tối sẽ nằm im tới chín giờ sáng hôm sau — với một cửa hàng đang có khách đứng chờ thì mười bốn tiếng đó là rất dài.

Do đó việc lập ca trực phải bắt đầu từ lịch làm việc của khách, và nếu nguồn lực không đủ phủ hết thì phải nói ra ngay từ đầu chứ đừng để khách tự phát hiện. Một thỏa thuận rõ ràng rằng ngoài khung giờ này thì chỉ xử lý sự cố nghiêm trọng vẫn tốt hơn nhiều so với một kỳ vọng ngầm rằng lúc nào cũng có người trực.

Với những dự án nặng về vận hành, chẳng hạn nhà máy, thì có nơi cử người trực tại chỗ từ một tới hai tuần, thậm chí cả tháng, cho tới khi hệ thống ổn định và người dùng thao tác thuần thục. Chi phí đó nghe lớn nhưng nó thường rẻ hơn chi phí của việc một dây chuyền phải dừng vì không có ai xử lý kịp.

Nhịp làm việc của hai tuần đầu

Một dòng chảy chỉ kiểm soát được nếu có nhịp, và nhịp mà tôi thấy chạy được gồm ba mốc trong ngày.

Đầu ngày là một buổi ngắn giữa đội triển khai và đầu mối phía khách, để chốt hôm nay ưu tiên xử lý những gì. Danh sách ưu tiên này đổi mỗi ngày, và đó là chuyện bình thường của giai đoạn này chứ không phải dấu hiệu mất kiểm soát.

Trong ngày, mọi vướng mắc mới được ghi vào kênh chính, được phân loại, và được gán người ngay khi nhận chứ không để dồn lại tới cuối buổi. Lý do là một danh sách chưa phân loại thì càng dài càng khó xử lý, trong khi phân loại ngay lúc còn nhớ bối cảnh thì mất chưa tới một phút mỗi dòng.

Cuối ngày là một bản tổng hợp ngắn gửi cho cả hai bên: hôm nay nhận bao nhiêu, xử lý xong bao nhiêu, còn treo bao nhiêu và treo vì lý do gì. Bản tổng hợp này không phải để báo cáo thành tích, nó là thứ giữ cho hai bên nhìn cùng một bức tranh, và nó cắt hẳn những cuộc trao đổi kiểu sao chưa thấy ai xử lý cái em báo hôm qua.

Dấu hiệu kết thúc giai đoạn

Không có mốc thời gian cố định, nhưng có ba dấu hiệu.

Dấu hiệu thứ nhất là số vướng mắc mới mỗi ngày giảm và giữ ổn định ở mức thấp trong vài ngày liên tiếp, chứ không phải giảm một ngày rồi vọt lại vào ngày sau.

Dấu hiệu thứ hai là tỷ lệ các loại vướng mắc đổi. Trong tuần đầu phần lớn là hỏi thao tác; khi phần đó teo lại và những gì còn lại chủ yếu là yêu cầu cải tiến, nghĩa là người dùng đã qua được giai đoạn làm quen.

Dấu hiệu thứ ba là bắt đầu xuất hiện những yêu cầu nằm ngoài phạm vi dự án. Nghe như chuyện phiền, thực ra đó là tín hiệu tốt: người dùng đã dùng thành thạo tới mức nghĩ ra được thứ họ muốn có thêm.

Và đúng lúc đó thì bạn bước sang giai đoạn bảo trì, nơi câu hỏi chính không còn là hệ thống có chạy không mà là yêu cầu này nằm trong hay ngoài những gì hai bên đã ký.