Khi nào KHÔNG nên tự động hoá

TL;DR: Tự động hoá một quy trình sai chỉ làm nó sai nhanh hơn và khó sửa hơn. Bảy trường hợp nên dừng lại: quy trình chưa ổn định, chưa ai làm thủ công thành thạo, tần suất quá thấp, dữ liệu đầu vào bẩn, việc cần phán đoán, không ai nhận bảo trì, và làm chỉ vì thấy người khác làm.

Vì sao một đơn vị làm automation lại viết bài này

Vì phần lớn dự án automation thất bại không phải do kỹ thuật. Nó thất bại vì làm sai chỗ ngay từ đầu — và khi đó, tiền càng chi nhiều thì hậu quả càng lớn.

Chúng tôi từ chối một số việc, và trong nhiều buổi khảo sát, kết luận đúng là "chưa nên làm". Bài này là bộ lọc đó, viết ra để bạn tự dùng.

1. Quy trình còn đang thay đổi

Tháng này duyệt hai cấp, tháng sau ba cấp, tháng sau nữa lại gộp về một. Quy trình chưa ổn định thì mỗi lần đổi là một lần sửa hệ thống, và tiền sửa cộng lại nhanh hơn tiền dựng.

Nên làm trước: để quy trình chạy ổn định vài tháng trên giấy hoặc trên file chung. Khi ba tháng liền không phải đổi gì nữa, lúc đó số hoá.

2. Chưa ai làm thủ công thành thạo

Nếu trong công ty chưa ai làm được việc đó bằng tay một cách trơn tru, thì không ai đủ hiểu để nói cho hệ thống biết phải làm gì.

Kết quả quen thuộc: hệ thống dựng xong, chạy được, nhưng không ai dám tin kết quả vì không ai biết đúng phải ra thế nào.

Nên làm trước: làm tay cho thuần, viết ra thành các bước rõ ràng. Cái viết ra đó chính là đặc tả để dựng hệ thống.

3. Tần suất quá thấp

Việc mỗi quý làm một lần, mất 2 tiếng. Một năm 8 tiếng. Dựng automation mất 3 ngày, cộng duy trì mỗi tháng.

Phép tính không cần máy tính. Nhưng người ta vẫn làm, vì "làm tay thấy phiền" — cảm giác phiền không tỷ lệ thuận với thời gian thật bỏ ra.

ℹ️ Info: Mẹo đơn giản: đo thật số giờ việc đó ngốn trong một quý. Nếu dưới 10 giờ một năm, gần như chắc chắn không đáng tự động hoá — trừ khi nó hay sai và cái sai đó đắt.

4. Dữ liệu đầu vào bẩn

Tên khách viết ba kiểu, mã sản phẩm lúc có lúc không, ngày tháng mỗi người nhập một định dạng.

Automation không làm sạch dữ liệu giúp bạn. Nó nhân bản cái bẩn lên với tốc độ cao hơn, và đẩy hậu quả xuống tận báo cáo cuối cùng — nơi bạn phát hiện ra muộn nhất.

Nên làm trước: chuẩn hoá dữ liệu gốc, chốt một nguồn sự thật. Đây là phần chán nhất của chuyển đổi số và cũng là phần quyết định nhất.

5. Việc cần phán đoán, không phải quy tắc

"Duyệt nếu hợp lý" thì không tự động hoá được — vì "hợp lý" không phải một quy tắc, đó là một cái nhìn.

Việc hợp để tự động hoá là việc mô tả được bằng: nếu A thì B, không thì C. Diễn đạt mãi vẫn phải chốt bằng "tuỳ tình huống" thì phần đó nên để người quyết.

Cách xử lý đúng: tự động hoá phần lấy dữ liệu và trình bày, để người ra quyết định cuối. Máy chuẩn bị, người quyết — đừng bắt máy quyết.

6. Không ai nhận bảo trì

Câu hỏi này nên hỏi trước khi bắt đầu, không phải sau khi bàn giao: sáu tháng nữa ai sửa cái này?

Không trả lời được thì bạn đang tạo ra một hệ thống mà một ngày nào đó sẽ hỏng, và cả công ty đứng nhìn. Lúc đó phải quay về làm tay — nhưng người từng làm tay thành thạo đã quên hoặc đã nghỉ.

7. Làm vì thấy người khác làm

"Đối thủ có AI rồi", "hội thảo nào cũng nói chuyển đổi số". Đây là lý do tệ nhất, và phổ biến nhất.

Automation không phải huy hiệu. Nó là công cụ để cắt một chi phí cụ thể hoặc chặn một lỗi cụ thể. Không chỉ ra được đang cắt cái gì thì chưa nên chi tiền.

Vậy khi nào nên làm

Đảo ngược danh sách trên. Nên làm khi:

• Quy trình đã ổn định vài tháng
• Có người làm tay thành thạo, mô tả được từng bước
• Việc lặp đủ nhiều để tiết kiệm thật sự
• Dữ liệu đầu vào đã chuẩn hoá
• Quy tắc rõ ràng, không phụ thuộc cảm tính
• Đã biết ai bảo trì
• Nói được câu: "làm cái này để cắt X giờ mỗi tháng" hoặc "để chặn lỗi Y"

Đủ bảy điều thì dự án gần như chắc chắn thành công. Thiếu ba bốn điều thì nên xử lý phần thiếu trước — thường rẻ hơn nhiều so với dựng hệ thống rồi bỏ.

Nếu bạn đang phân vân giữa tự làm và thuê

Đó là câu hỏi khác, và có cách tính riêng — xem tự dựng automation hay thuê. Nhưng hãy trả lời câu hỏi trong bài này trước: có nên làm không, rồi mới tới ai làm.