Một người nghỉ, cả quy trình đứng: 4 cách giảm phụ thuộc vào một cá nhân

[baonguyen]

Giả sử chị A là người phụ trách theo dõi các đề xuất mua hàng trong công ty.

Mỗi ngày, chị tiếp nhận yêu cầu, kiểm tra thông tin, chuyển cấp phê duyệt và theo dõi cho đến khi việc mua hàng hoàn tất.

Nhờ có nhiều kinh nghiệm, chị A biết khá rõ cách xử lý từng tình huống:

• Hồ sơ nào cần bổ sung thêm báo giá

• Khoản chi nào cần thêm cấp phê duyệt

• Trường hợp nào cần ưu tiên

• Phải liên hệ ai khi có phát sinh

• File nhà cung cấp đang được lưu ở đâu

• Case nào có thể linh hoạt xử lý

Mọi thứ vẫn chạy ổn cho đến ngày chị nghỉ phép.

Một yêu cầu thiếu báo giá nhưng người tiếp nhận thay không biết nên trả lại hay cho bổ sung sau.

Một khoản mua trên 50 triệu có vẻ cần thêm cấp duyệt, nhưng cả team không nhớ chính xác người có thẩm quyền.

Một yêu cầu đã được phê duyệt lại thiếu thông tin nhà cung cấp. File liên quan nằm trong thư mục cá nhân của chị A.

Sau vài lượt trao đổi, team quyết định chờ chị quay lại.

Ngày nghỉ của chị A làm lộ ra một rủi ro vận hành: phần lớn kiến thức và cách xử lý của quy trình đang tập trung ở một người.

Vì sao quy trình dễ phụ thuộc vào một cá nhân?

Tình trạng này thường hình thành từ từ.

Một người làm công việc đủ lâu sẽ tích lũy nhiều kinh nghiệm thực tế. Họ nhớ những ngoại lệ chưa từng được viết lại, biết nên liên hệ ai và có thể tự xử lý các khoảng trống trong quy trình.

Theo thời gian, team quen với việc hỏi người đó mỗi khi có vấn đề.

Các quyết định được trao đổi qua chat. Tài liệu được lưu trong thư mục cá nhân. Một số rule được truyền miệng. Người thay thế có thể đã được chỉ định, nhưng chưa hiểu đầy đủ cách xử lý.

Khi người phụ trách vẫn có mặt, những khoảng trống này ít được chú ý. Đến lúc họ nghỉ phép, chuyển vị trí hoặc rời công ty, công việc mới bắt đầu mắc lại.

Dưới đây là bốn cách giúp quy trình bớt phụ thuộc vào một cá nhân.

1. Gắn trách nhiệm với vai trò

Một task có thể được giao cho một người cụ thể, nhưng trách nhiệm trong quy trình nên được xác định theo vai trò.

Với quy trình mua hàng, các vai trò có thể gồm:

• Người tiếp nhận đề xuất

• Quản lý phê duyệt

• Người kiểm tra ngân sách

• Nhân sự phụ trách mua hàng

• Người bàn giao tài sản

Khi chị A nghỉ phép, một người khác có thể tiếp nhận vai trò phụ trách mua hàng trong khoảng thời gian đó.

Cách thiết kế này giúp team thay đổi người thực hiện mà vẫn giữ nguyên logic của quy trình.

2. Có người thay thế và quy tắc chuyển giao rõ ràng

Chỉ định một người backup là chưa đủ. Người đó cần biết mình được phép xử lý những gì.

Team nên thống nhất:

• Khi nào công việc được chuyển sang người thay thế

• Người thay thế có những quyền xử lý nào

• Trường hợp nào cần xin thêm xác nhận

• Các case đang dở được bàn giao ra sao

• Khi người phụ trách quay lại, công việc được chuyển về như thế nào

Ví dụ, người thay thế có thể tiếp nhận các đề xuất thông thường nhưng cần chuyển những khoản vượt hạn mức cho trưởng bộ phận.

Phạm vi càng rõ, người backup càng dễ tiếp tục công việc mà không phải chờ hướng dẫn.

3. Viết rõ những rule đang được ghi nhớ

Nhiều rule vận hành tồn tại dưới dạng kinh nghiệm cá nhân.

Chị A có thể biết rằng khoản mua trên 50 triệu cần thêm cấp phê duyệt. Tuy nhiên, nếu rule này chưa được ghi lại, những người còn lại chỉ có thể nhớ một cách tương đối.

Hãy chọn một số case thực tế và làm rõ:

• Khi nào yêu cầu cần thêm cấp duyệt

• Thiếu tài liệu thì chuyển về trạng thái nào

• Trường hợp khẩn cấp được xác định bằng tiêu chí gì

• Người duyệt vắng mặt thì yêu cầu được chuyển cho ai

• Thay đổi sau phê duyệt được xử lý như thế nào

Mỗi câu trả lời có thể trở thành một điều kiện chuyển bước, quy tắc xử lý hoặc hướng giải quyết ngoại lệ.

4. Lưu file và lịch sử ngay trên từng case

Người tiếp nhận thay cần có đủ thông tin để tiếp tục công việc.

Khi mở một yêu cầu, họ nên nhìn thấy:

• Yêu cầu đã trải qua những bước nào

• Ai đã thực hiện từng thao tác

• Quyết định nào đã được đưa ra

• Lý do trả lại hoặc từ chối

• Tài liệu liên quan được lưu ở đâu

• Việc tiếp theo cần thực hiện là gì

Nếu lịch sử nằm rải rác giữa email, tin nhắn và file cá nhân, người mới tiếp nhận sẽ mất nhiều thời gian để ghép lại toàn bộ bối cảnh.

Việc lưu đủ lịch sử cũng giúp team kiểm tra nguyên nhân khi một case bị chậm hoặc xử lý sai.

Bài kiểm tra nghỉ phép trong 30 phút

Chọn một quy trình quan trọng và giả định người hiểu quy trình nhất sẽ nghỉ vào ngày mai.

Sau đó giao một case đang chạy cho người khác và quan sát:

1. Người đó có biết cần làm gì tiếp theo không?

2. Họ có tìm được đủ dữ liệu và tài liệu không?

3. Họ có biết mình được quyền đưa ra quyết định nào không?

4. Họ có hiểu vì sao case đang ở trạng thái hiện tại không?

5. Khi có ngoại lệ, họ có biết cần chuyển cho ai không?

Mỗi điểm khiến người tiếp nhận phải dừng lại và hỏi chính là một phần kiến thức cần được làm rõ.

Solution Builder tham gia ở đâu?

Solution Builder quan sát cách công việc đang chạy, lấy các case thật để hiểu logic xử lý và chuyển kinh nghiệm cá nhân thành những thành phần rõ ràng hơn:

• Vai trò

• Dữ liệu

• Trạng thái

• Quy tắc

• Quyền xử lý

• Lịch sử thao tác

• Phương án bàn giao

Kết quả cần hướng tới là một quy trình mà người khác có thể tiếp tục vận hành khi nhân sự thay đổi.

Hãy thử chọn một quy trình trong team và tự hỏi:

Nếu người hiểu quy trình nhất nghỉ một tuần, công việc có thể tiếp tục đến đâu?

Phần khiến mọi người bắt đầu lúng túng chính là nơi nên được làm rõ trước tiên.