Đưa nhân viên vào hệ thống mới mà không có sự hỗn loạn

Việc triển khai hệ thống không tốt thường không thất bại ở cấp độ kỹ thuật. Phần mềm hoạt động. Điều đáng lo ngại nằm ở phía con người: nhân viên sử dụng song song hệ thống cũ, người quản lý không thực thi quy trình mới, khóa đào tạo diễn ra một lần nhưng không được giữ lại và ngày đưa vào hoạt động đến trước khi mọi người sẵn sàng.

# Tại sao triển khai thất bại

Các chế độ thất bại phổ biến nhất:

• Đào tạo quá gần thời điểm đi vào hoạt động.* Nhân viên được đào tạo ba ngày trước khi ra mắt đã quên 60% nội dung đó vào ngày đầu tiên. Họ quay lại quy trình cũ hoặc hỏi những đồng nghiệp cũng không chắc chắn như vậy.

• Không có tài liệu về quy trình.* Hệ thống phản ánh một quy trình. Nếu quy trình không được viết ra trước khi xây dựng, nhân viên sẽ không biết họ phải làm gì - họ biết cách nhấp qua màn hình nhưng không biết theo thứ tự và thời điểm nào.

• Chưa xác định được nhà vô địch.* Mọi đội đều cần một người đủ hiểu biết về hệ thống để trả lời các câu hỏi ngay lúc đó. Nếu không có người được chỉ định, mọi câu hỏi sẽ được chuyển đến nhà cung cấp hoặc không được trả lời.

• Chạy song song không có ngày kết thúc.* Chạy hệ thống mới song song với hệ thống cũ là điều hợp lý trong một khoảng thời gian chuyển tiếp xác định. Nếu không có ngày chuyển giao cứng nhắc, hệ thống cũ sẽ không bao giờ thực sự dừng lại - nhân viên sẽ mặc định áp dụng nó bất cứ khi nào hệ thống mới chưa quen thuộc.

# Giai đoạn chuẩn bị

Trước khi bắt đầu bất kỳ hoạt động đào tạo nhân viên nào, cần phải có hai điều.

• Tài liệu về quy trình.* Đối với mỗi vai trò sẽ sử dụng hệ thống, hãy ghi lại quy trình làm việc: điều gì kích hoạt một hành động, điều gì cần phải nhập, điều gì xảy ra tiếp theo. Điều này không cần phải phức tạp - một danh sách được đánh số đơn giản cho mỗi vai trò là đủ. Hành động viết nó ra sẽ bộc lộ những lỗ hổng trong quá trình thiết kế hệ thống đã bỏ sót.

• Dữ liệu thử nghiệm và môi trường chạy thử.* Nhân viên cần thực hành trong một hệ thống trông giống như hệ thống đang hoạt động nhưng sẽ không làm hỏng hồ sơ thực. Môi trường dàn dựng với dữ liệu thực tế cho phép mọi người mắc lỗi một cách an toàn trước khi đi vào hoạt động.

# Đào tạo dựa trên vai trò

"Đào tạo hệ thống" chung chung - một buổi bao gồm mọi thứ cho mọi người - hiếm khi có hiệu quả. Người lấy hàng tại kho không cần biết cách chạy báo cáo cuối tháng. Người sử dụng tài chính không cần biết luồng nhận hàng.

Đào tạo theo vai trò, chỉ bao gồm những gì vai trò đó thực hiện trong hệ thống, sẽ ngắn hơn, phù hợp hơn và được giữ chân tốt hơn. Nguyên tắc thiết kế của Jacob Ng cho giao diện giữa nhân viên tuyến đầu và người lao động nhập cư cũng được áp dụng ở đây: nếu màn hình dành cho người lấy hàng chỉ hiển thị những gì người lấy hàng cần thì việc đào tạo cho vai trò đó cũng tương ứng đơn giản.

# Người mẫu vô địch

Xác định một người trong mỗi nhóm hoặc ca sẽ được đào tạo ở cấp độ sâu hơn — không chỉ cách sử dụng hệ thống mà còn cả cấu trúc của hệ thống, ý nghĩa của các lỗi phổ biến và ai cần liên hệ khi gặp loại vấn đề. Người này trở thành người hỗ trợ đầu tiên trên sàn, xử lý các câu hỏi thông thường trước khi chúng leo thang.

Nhà vô địch cần thời gian để chuẩn bị. Họ phải được xác định sớm, được đào tạo trước những người còn lại trong nhóm và được tiếp cận với môi trường dàn dựng để thực hành.

# Trình tự phát trực tiếp

Không phải mọi thứ đều cần phải diễn ra trong cùng một ngày. Cách tiếp cận theo từng giai đoạn theo mô-đun hoặc theo nhóm sẽ giảm bán kính vụ nổ nếu có điều gì đó cần điều chỉnh:

1. Bắt đầu với chức năng có tần suất cao nhất, rủi ro thấp nhất (thường là nhận hàng tồn kho hoặc nhập đơn đặt hàng)
2. Chạy mô-đun đó trực tiếp trong hai đến bốn tuần trước khi thêm mô-đun tiếp theo
3. Luôn sẵn sàng hỗ trợ nhóm triển khai trong mỗi giai đoạn

Việc cắt giảm đồng thời tất cả các mô-đun là phương pháp có rủi ro cao nhất. kiểm tra hệ thống trước và sau khi triển khai xác định các lĩnh vực có nhiều khả năng cần điều chỉnh nhất.

# Sau Go-Live: Tháng đầu tiên

Tháng đầu tiên là lúc việc triển khai thành công hay thất bại về lâu dài. Bề mặt vấn đề không xuất hiện trong thử nghiệm. Những trường hợp nguy hiểm xuất hiện ngoài dự kiến. Nhân viên cần sự hỗ trợ rõ ràng - ai đó luôn sẵn sàng hỗ trợ chứ không chỉ là số điện thoại để gọi.

Đánh giá sau khi đưa vào hoạt động vào ngày thứ 30 — kiểm tra tỷ lệ lỗi, số lượng yêu cầu hỗ trợ và nơi nhân viên vẫn đang sử dụng các giải pháp thay thế — xác định những gì cần điều chỉnh trước khi nó trở nên cố hữu.

Câu hỏi thường gặp

# Chúng ta nên chạy song song hệ thống cũ và mới trong bao lâu?

Hai đến bốn tuần là khoảng thời gian thực tế cho hầu hết các hoạt động. Đủ lâu để bắt lỗi trong hệ thống mới; đủ ngắn để nhân viên có động cơ thực sự để học nó thay vì mặc định làm theo cái cũ. Đặt ngày theo lịch để hệ thống cũ dừng và liên lạc với nó trước khi đi vào hoạt động.

# Điều gì sẽ xảy ra nếu nhân viên từ chối sử dụng hệ thống mới?

Sự phản kháng thường có nguyên nhân: hệ thống khó sử dụng hơn hệ thống cũ cho nhiệm vụ cụ thể của họ hoặc họ không hiểu tại sao cần phải thay đổi. Cả hai đều đáng để điều tra trước khi quy vấn đề cho thái độ. Quy trình làm việc thực sự chậm hơn đối với nhân viên tuyến đầu so với quy trình được thay thế là vấn đề về thiết kế, không phải vấn đề quản lý thay đổi.

# Chúng ta nên dành bao nhiêu thời gian cho việc đào tạo nhân viên cho mỗi vai trò?

Đối với một buổi đào tạo tập trung dựa trên vai trò, thông thường sẽ mất từ ​​​​hai đến bốn giờ cho các vai trò vận hành (kho, nhập đơn đặt hàng). Người dùng tài chính có quy trình làm việc phức tạp hơn có thể cần cả ngày. Hãy tham gia buổi học thứ hai hai tuần sau khi đi vào hoạt động - đây là lúc các câu hỏi trở nên cụ thể và nội dung đào tạo được lưu giữ tốt hơn.

• Đặt lịch kiểm tra hệ thống*