Lần đầu tiên tôi nghe thuật ngữ “shadow IT,” tôi nghĩ đó là chuyện của những công ty lớn, thiếu kỷ luật. Sau đó tôi đến một doanh nghiệp gia đình 40 người, ngành phân phối thực phẩm, và thấy 23 file Google Sheet đang chạy song song với phần mềm ERP mà họ vừa triển khai xong năm ngoái.

Người tạo ra 23 file đó không phải kẻ phá hoại. Đó là trưởng phòng kinh doanh — người làm việc ở đó 11 năm và biết hơn ai hết cái gì không hoạt động.

Hai bộ quy trình

Tôi bắt đầu để ý đến điều này sau nhiều năm: mọi tổ chức đều vận hành bằng hai bộ quy trình cùng một lúc.

Bộ quy trình viết là thứ được ghi trong sổ tay nội bộ, trong tài liệu ISO, trong slide onboarding cho nhân viên mới. Nó gọn gàng, logic, có flow chart đẹp. Nó mô tả cách mọi thứ nên xảy ra.

Bộ quy trình thật là thứ mọi người thực sự làm để công việc chạy được. Nó có đầy ngoại lệ, shortcut, quy tắc bất thành văn, và bộ nhớ cá nhân mà không ai ghi lại bao giờ. “Cái đơn đặt hàng này gửi qua Zalo cho chị Lan trước, sau đó mới nhập hệ thống, nếu không chị Lan sẽ không kịp chuẩn bị.” Không có trong tài liệu nào. Nhưng ai cũng biết.

Khoảng cách giữa hai bộ đó là nơi mọi dự án phần mềm đến và chết.

Vì sao phần mềm luôn được xây trên bộ sai

Khi một doanh nghiệp mua phần mềm, họ thường mô tả nhu cầu bằng bộ quy trình viết. Không phải vì họ cố tình lừa nhà cung cấp. Mà vì đó là thứ họ có thể mô tả — nó đã được ghi ra, có cấu trúc, dễ diễn đạt trong cuộc họp.

Bộ quy trình thật thì khó hơn nhiều. Nó sống trong đầu người, trong thói quen, trong “cái này thì anh Tuấn biết, hỏi anh Tuấn đi.” Để kéo nó ra ngoài cần thời gian và sự kiên nhẫn mà hầu hết dự án không có — hoặc không nghĩ là quan trọng.

Kết quả: phần mềm được xây để phục vụ bộ quy trình viết. Khi ra thực tế, nó va vào bộ quy trình thật và không khớp. Và thay vì thừa nhận điều đó, người ta nói nhân viên “kháng cự thay đổi.”

Nhân viên không kháng cự thay đổi. Họ kháng cự những thứ làm công việc của họ khó hơn. Đó là hai điều rất khác nhau.

Cái tôi học được từ 23 file Google Sheet

Tôi ngồi lại với trưởng phòng kinh doanh đó và hỏi anh giải thích từng file. Mất gần ba tiếng.

Mỗi file là một giải pháp cho một điểm gãy cụ thể trong hệ thống ERP. File theo dõi đơn hàng gấp vì ERP không có trường “độ ưu tiên” linh hoạt. File tổng hợp công nợ theo nhóm khách vì ERP chỉ báo cáo theo từng khách riêng lẻ. File dự báo tồn kho thủ công vì module dự báo của ERP dùng thuật toán không phù hợp với đặc thù ngành thực phẩm theo mùa.

Không một file nào là tùy tiện. Tất cả đều là bằng chứng của người thực sự hiểu nghiệp vụ đang ứng phó với một hệ thống không đủ linh hoạt.

Đúng ra, 23 file đó là tài liệu thiết kế phần mềm tốt nhất tôi từng thấy — nếu ai đó chịu đọc chúng như vậy.

Cách đọc khoảng cách đó

Tôi không có công thức vạn năng. Nhưng có một vài câu hỏi thực tế giúp tôi bắt đầu đọc khoảng cách giữa hai bộ quy trình trong bất kỳ tổ chức nào:

Ai là người mới nhất mà cả phòng đều tìm đến khi cần hỏi? Không phải người có chức danh cao nhất. Người mà mọi người tìm đến khi cần làm xong việc. Đó thường là người nắm nhiều nhất về bộ quy trình thật.

Những ngoại lệ nào được xử lý thường xuyên nhất? Quy trình viết thường nói “trong trường hợp bình thường.” Nhưng thực tế của nhiều ngành là “bình thường” chiếm 60%, và 40% còn lại là ngoại lệ được xử lý bằng kinh nghiệm cá nhân. Nếu phần mềm không xử lý được 40% đó, người ta sẽ dùng phần mềm cho 60% và dùng Excel cho 40%.

Cái gì sẽ bị mất nếu người lâu năm nhất nghỉ việc tuần tới? Câu trả lời cho câu hỏi đó chính xác là những gì không được ghi trong bất kỳ tài liệu nào — và là những gì bất kỳ hệ thống tốt nào cũng cần phải có.

Khoảng cách đó tốn bao nhiêu?

Tôi không có con số chính xác. Nhưng tôi có một cách nhìn thô: đếm số giờ mỗi tuần mà người của bạn đang dành để “làm cho hệ thống chạy được” thay vì “làm việc thật.”

Nhập lại dữ liệu từ hệ thống này sang hệ thống kia. Tạo báo cáo thủ công vì hệ thống không ra được đúng định dạng. Kiểm tra chéo giữa file và phần mềm. Gọi điện xác nhận vì hệ thống không đủ tin tưởng.

Cộng tất cả lại, nhân với lương giờ, nhân với 52 tuần. Con số đó thường lớn hơn chi phí phần mềm rất nhiều.

23 file Google Sheet kia cuối cùng không bị xóa. Chúng trở thành bản thiết kế cho bản nâng cấp hệ thống. Lần này, người ngồi viết yêu cầu kỹ thuật là trưởng phòng kinh doanh — không phải bộ phận IT.

Trong doanh nghiệp của bạn, bộ quy trình thật đang sống ở đâu — và ai là người giữ nó?