Ma trận ưu tiên tự động hóa: quy trình nào nên làm trước

Hầu hết bài viết về tự động hóa bắt đầu bằng câu hỏi “dùng công cụ nào”. Đó là câu hỏi thứ hai. Câu hỏi thứ nhất, và cũng là câu hỏi ít khi được viết ra, là: trong danh sách quy trình đang làm thủ công, cái nào nên tự động hóa trước, cái nào nên để yên?

Trả lời sai câu hỏi đầu tiên thì công cụ tốt đến đâu cũng không cứu được. Một đội có thể dựng một hệ thống tự động hóa rất chỉn chu cho một việc chỉ xảy ra ba lần một năm, trong khi việc lặp lại hai trăm lần một ngày vẫn có người ngồi làm tay.

Hai trục, không phải một danh sách

Cách phổ biến để chọn việc tự động hóa là liệt kê các quy trình đang tốn thời gian rồi xếp hạng theo cảm tính. Vấn đề là “tốn thời gian” gộp chung hai thứ khác nhau: một việc có thể tốn thời gian vì nó xảy ra thường xuyên, hoặc tốn thời gian vì mỗi lần làm đều phức tạp. Hai nguyên nhân đó dẫn tới hai quyết định khác nhau.

Một khung quyết định rõ hơn dùng hai trục độc lập:

• Tần suất: quy trình này xảy ra bao nhiêu lần trong một tuần, một tháng?
• Chi phí khi sai: nếu một lần chạy tự động cho ra kết quả sai, thiệt hại là gì và mất bao lâu để phát hiện, để sửa?

Hai trục này tạo ra bốn góc phần tư, và mỗi góc gợi ý một hành động khác nhau chứ không phải “tự động hóa” hay “không” một cách chung chung.

quadrantChart
    title Ưu tiên tự động hóa
    x-axis Ít xảy ra --> Xảy ra thường xuyên
    y-axis Sai thì rẻ --> Sai thì đắt
    quadrant-1 Cần người duyệt trước khi chạy
    quadrant-2 Hiếm khi đáng làm
    quadrant-3 Để tay, không đáng đầu tư
    quadrant-4 Ưu tiên tự động hóa ngay
    Gửi email nhắc lịch: [0.75, 0.15]
    Đối soát công nợ hàng tuần: [0.7, 0.55]
    Gửi hợp đồng cho khách: [0.35, 0.8]
    Báo cáo quý cho ban điều hành: [0.15, 0.75]
    Sắp xếp lại thư mục nội bộ: [0.2, 0.15]

Góc phần tư đáng chú ý nhất không phải là góc “làm ngay”, mà là góc phía trên bên trái: xảy ra không thường xuyên nhưng sai thì đắt. Đây là nơi phần lớn dự án tự động hóa thất bại, không phải vì kỹ thuật kém, mà vì bài toán bị chọn sai ngay từ đầu.

Vì sao “xảy ra thường xuyên, sai thì rẻ” là nơi bắt đầu đúng

Một quy trình lặp lại nhiều và sai số có thể sửa nhanh là nơi tự động hóa trả về giá trị nhanh nhất, vì hai lý do cộng dồn:

1. Tần suất cao nghĩa là mỗi giờ tiết kiệm được nhân lên nhiều lần mỗi tuần. Một quy trình mất năm phút nhưng chạy hai trăm lần một tuần tốn nhiều thời gian hơn một quy trình mất hai giờ nhưng chỉ chạy một lần một tháng.
2. Chi phí sai thấp nghĩa là hệ thống được phép chạy tự động hoàn toàn, không cần một người đứng chờ duyệt từng lần. Một bước duyệt thủ công đặt vào một quy trình chạy hai trăm lần một tuần sẽ giết chết phần lớn lợi ích tự động hóa, vì người duyệt trở thành nút thắt mới.

Ngược lại, một quy trình hiếm khi xảy ra nhưng sai thì đắt - gửi nhầm hợp đồng cho khách, cam kết sai một mức giá - thường không đáng để xây một hệ thống tự động hoàn toàn. Chi phí xây và duy trì hệ thống đó, cộng với chi phí khi nó sai đúng một lần, dễ vượt quá thời gian nó tiết kiệm được trong cả năm. Việc hợp lý hơn ở góc này là chuẩn hóa quy trình thủ công - một mẫu (template), một danh sách kiểm tra - thay vì tự động hóa toàn phần.

Chi phí kiểm chứng là trục ẩn thứ ba

Hai trục trên đủ để xếp hạng, nhưng còn thiếu một câu hỏi quan trọng không kém: có cách nào rẻ để biết kết quả tự động đúng hay sai, mà không phải tự làm lại từ đầu?

Nếu câu trả lời là có - một con số phải khớp với hệ thống kế toán, một mã đơn hàng phải tồn tại, một file phải mở được - thì quy trình đó an toàn để tự động hóa ngay cả khi nằm gần góc “sai thì đắt”, vì hệ thống có thể tự kiểm tra trước khi kết quả đi ra ngoài. Nếu câu trả lời là không - kết quả chỉ đúng hay sai tùy vào phán đoán của người đọc - thì mức độ tự động hóa hợp lý dừng lại ở bản nháp cho người duyệt, bất kể quy trình đó xảy ra thường xuyên đến đâu.

Nói cách khác, trục “chi phí khi sai” trong ma trận trên nên được đọc là “chi phí khi sai và không ai phát hiện kịp”. Một phép kiểm tra rẻ làm giảm chi phí đó xuống đáng kể, và có thể kéo một quy trình từ góc phần tư “cần người duyệt” sang góc “tự động hóa ngay” mà không cần thay đổi gì về tần suất.

Sai lầm thường gặp: xếp hạng theo độ khó kỹ thuật

Một cách chọn sai phổ biến khác là bắt đầu từ việc “cái này dễ tự động hóa hơn” thay vì “cái này đáng tự động hóa hơn”. Độ khó kỹ thuật và giá trị mang lại là hai trục gần như độc lập. Một quy trình rất dễ viết script - vì dữ liệu đầu vào sạch, định dạng cố định - có thể lại là quy trình xảy ra rất hiếm, nên công sức bỏ ra không bao giờ hoàn vốn. Ngược lại, quy trình mang lại giá trị lớn nhất đôi khi lại lộn xộn nhất, vì chính sự lộn xộn đó là lý do nó vẫn còn làm thủ công sau nhiều năm.

Thứ tự đúng là chọn theo giá trị trước bằng ma trận tần suất và chi phí sai, rồi mới hỏi đến độ khó kỹ thuật khi quyết định cách làm, không phải có nên làm. Một quy trình giá trị cao nhưng khó tự động hóa toàn phần vẫn có thể được lợi từ tự động hóa một phần - xử lý sẵn 80% trường hợp đơn giản, chuyển 20% còn lại cho người xử lý - thay vì bị gạt khỏi danh sách vì “khó quá”.

Cách dùng ma trận này

Cách áp dụng đơn giản nhất là liệt kê mọi quy trình thủ công đang lặp lại trong một tuần làm việc bình thường, rồi đặt từng cái lên hai trục: tần suất và chi phí khi sai. Không cần số liệu chính xác, ước lượng tương đối là đủ để thấy quy trình nào rơi vào góc phần tư nào.

Sau đó, với mỗi quy trình ở góc “ưu tiên tự động hóa ngay”, hỏi thêm câu hỏi kiểm chứng ở trên trước khi bắt tay vào xây: nếu không có cách rẻ để kiểm tra kết quả, thu hẹp phạm vi tự động hóa lại thành soạn nháp cho người duyệt, thay vì để hệ thống tự chạy hết và hy vọng không sai.

Bài toán chọn quy trình để tự động hóa gần như luôn quan trọng hơn bài toán chọn công cụ. Công cụ có thể đổi sau; một quy trình bị chọn sai từ đầu thì thường được phát hiện muộn, sau khi thời gian và ngân sách đã bỏ vào.