Hệ thống chạy đúng quy trình. Tuần đầu, hồ sơ tồn gấp bốn.

Sáng thứ Tư, tuần thứ hai sau khi hệ thống lên chính thức, mình ngồi ở phòng tiếp nhận.

Không phải để họp. Để nhìn.

Trước đó một tuần, con số tồn đọng lên gấp bốn so với trước khi có phần mềm. Bên mình rà lại: hệ thống làm đúng quy trình mười bốn bước trong tài liệu đã phê duyệt, không thiếu bước nào. UAT pass sạch. Người dùng đã được đào tạo hai buổi, có ký danh sách. Không lỗi nào được log lại.

Mọi thứ đều đúng, và hồ sơ thì tồn gấp bốn.

Chị Hằng - chuyên viên nghiệp vụ ở đơn vị, mười lăm năm làm đúng việc này - nhận hồ sơ đầu tiên lúc tám giờ mười. Mình đã hỏi chị từ hôm trước, nói rõ mình ngồi xem để biết việc thật chạy thế nào. Ngồi cách hai bàn, không hỏi gì thêm.

Chị mở phần mềm. Nhập thông tin. Đến bước kiểm tra thành phần hồ sơ, chị dừng lại, mở một cửa sổ khác - một file Excel - gõ vài dòng, rồi quay về phần mềm, chọn “hồ sơ đầy đủ”, đi tiếp.

Hồ sơ thứ hai: cũng vậy. Hồ sơ thứ tư: cũng vậy. Đến trưa mình đếm được sáu lần.

Cái file ấy không có trong tài liệu quy trình. Không có trong biên bản khảo sát. Không có trong buổi phỏng vấn nào bên mình đã làm - mà bọn mình đã phỏng vấn chị hai lần, mỗi lần hơn một tiếng, có biên bản, chị đọc lại và ký.

Lúc đó mình cho là chị quên.

Hai bài trước đều nói về một câu bị truyền đi: đi xuống thì rụng mất quyết định đứng sau, đi ngang thì rụng mất chỗ đứng của người nói. Bài này chẳng có câu nào đi đâu cả. Tài liệu quy trình nằm yên một chỗ, đã phê duyệt, đóng dấu, và mình đọc nó kỹ hơn hầu hết mọi người trong dự án.

Nó vẫn sai. Không sai ở chữ nào - sai ở chỗ nó mô tả một thứ khác với thứ đang diễn ra ngoài kia.

Buổi chiều mình hỏi chị về cái file. Chị mở ra cho xem luôn, chẳng có gì bí mật cả.

Bước số bốn trong mười bốn bước là kiểm tra thành phần hồ sơ: đủ thì tiếp nhận, thiếu thì trả lại kèm phiếu hướng dẫn bổ sung. Rõ ràng, đúng văn bản.

Thực tế thì khoảng một phần tư số hồ sơ đến quầy thiếu một hai giấy tờ nhỏ. Người dân đi từ huyện xuống, mất nửa buổi. Trả về nghĩa là họ đi thêm một lượt nữa.

Nên nhiều năm nay, đơn vị làm thế này: nhận trước, ghi vào một file theo dõi riêng phần còn thiếu, hẹn bổ sung, và hồ sơ vẫn chạy song song ở các bước sau. Phần lớn bổ sung đúng hẹn. Phần còn lại mới trả về.

Cái file Excel đó chính là chỗ ghi. Nó không nằm trong quy trình, vì nếu nằm trong quy trình thì tức là quy trình đang mô tả một việc mà chính nó không cho phép.

Mình không phán ở đây rằng cách làm ấy đúng hay sai - không đủ tư cách phán, và đó cũng không phải việc của người đi làm phần mềm. Điều mình biết chắc chỉ là: nó đang tồn tại, nó đang gánh một áp lực có thật, và nó sắp va vào một hệ thống không biết nó tồn tại.

Cái hệ thống mới của bọn mình không có chỗ nào cho việc đó. Nó làm đúng bước bốn: thiếu thì trả. Và một phần tư số hồ sơ bắt đầu quay vòng.

Đây là chỗ cần đóng đinh, và mình muốn bạn đọc chậm câu này: cái quy trình mười bốn bước không mô tả công việc đang chạy. Nó mô tả công việc lẽ ra phải chạy. Hai thứ đó không mặc nhiên trùng nhau. Và khoảng cách giữa chúng không nhất thiết là lỗi của ai - nó thường là chỗ người làm việc bù vào phần mà văn bản không lường được.

Đừng vội đọc cái file Excel như bằng chứng rằng người dùng đang làm sai. Nó có thể vừa không khớp quy định, vừa là thứ đang giữ cho quy trình chạy - hai chuyện đó không loại trừ nhau, và gộp làm một là cách nhanh nhất để hiểu sai cả hai. Việc của bạn lúc này chưa phải xử lý nó. Là biết nó đang gánh phần nào. Vì bỏ nó đi mà không thay bằng gì thì cái đứng lại không phải cái file - là cả quy trình.

Nói thật với bạn một chuyện, để bạn đừng tưởng chỗ này gọn gàng như mình vừa kể: cái file Excel là phần dễ nhất, vì nó có hình hài, mở ra là thấy. Còn một loại điều chỉnh không có hình hài gì cả - nó nằm trong đầu người làm lâu năm, dưới dạng “hồ sơ loại này thì phải gọi trước cho bên kia”. Loại đó bạn không thấy trong một buổi sáng, và người ta cũng không kể được - không nhất thiết vì ai giấu; với người làm lâu năm thì nó có khi không được coi là một bước, nó chỉ là biết việc.

Giờ đến chỗ mình đoán bạn đang định phản đối: chẳng lẽ thấy người ta làm khác là chiều theo? Vậy quy trình để làm gì, và ai chịu trách nhiệm khi có chuyện?

Không. Việc phải làm không phải là hợp thức hoá mọi cách làm tắt. Là hỏi cho ra cái cách làm đó đang bù cho chuyện gì. Mình không có danh sách đầy đủ, nhưng có ba kiểu gặp đi gặp lại.

Bù cho một thiếu sót của quy trình - một loại ca có thật mà văn bản không có bước nào cho nó - thì thứ cần sửa là quy trình, ở cấp có thẩm quyền sửa, không phải lén đưa vào phần mềm.

Bù cho việc thiếu người, thiếu thời gian, thiếu một hệ thống khác chạy quá chậm - thì đưa nó vào phần mềm là cách chắc chắn nhất để chôn vấn đề đó thêm mười năm. Cái cần làm là nói nó ra thành một dòng trong báo cáo, không phải nuốt nó vào một cái field.

Và loại thứ ba: bù cho một rủi ro mà người làm đang gánh một mình. Loại này phần mềm không giải quyết được gì. Nhưng khi biết nó tồn tại, ít nhất bạn thôi viết câu “quy trình được thực hiện theo đúng quy định” vào tài liệu nghiệm thu như thể đó là một sự thật.

Ở ca này bọn mình không đi thẳng vào thiết kế, và đó là chỗ mình học được nhiều nhất. Việc đầu tiên là viết cái đang có ra thành một trang: có một loại ca chiếm khoảng một phần tư khối lượng, quy trình hiện hành không có bước nào cho nó, đơn vị đang xử lý bằng một file ngoài hệ thống. Không đề xuất gì. Chỉ mô tả.

Rồi đưa trang đó lên cho bên có thẩm quyền quyết, vì chỉ có hai đường: thừa nhận loại ca đó và sửa quy trình cho nó có chỗ, hoặc giữ nguyên quy trình và chấp nhận một phần tư số hồ sơ quay vòng. Cả hai đều có người phải ký. Không đường nào là việc của đội phần mềm.

Bảy tuần mới có câu trả lời. Phần code thì đúng là nhỏ đến mức hơi ngượng: thêm một trạng thái, một trường ghi phần còn thiếu, một cái nhắc. Bốn ngày công.

Giờ mình kể lại đúng chuyện đó, ở một chỗ mà bạn sẽ không nghĩ là cùng gốc.

Một dự án khác. Đào tạo xong, có video, có tài liệu, có nhóm hỗ trợ. Ba tháng sau kiểm tra: người dùng vẫn nhập vào phần mềm, nhưng để làm việc thì xuất ra Excel, xử lý ở đó, rồi nhập ngược kết quả.

Kết luận trong biên bản họp hôm ấy - mình còn giữ - là “người dùng chưa quen công cụ mới, đề nghị tăng cường đào tạo”. Đào tạo thêm hai buổi. Ba tháng sau vẫn thế.

Vì đào tạo dạy người ta dùng phần mềm để chạy cái quy trình trên giấy. Mà cái họ đang làm không phải quy trình trên giấy. Chỗ hổng không nằm ở chỗ họ chưa biết - nó nằm ở chỗ phần mềm không có chỗ cho phần việc mà cái Excel kia đang gánh. Học thêm bao nhiêu buổi cũng không tạo ra được chỗ đó.

Hai triệu chứng. Một cái là hồ sơ tồn gấp bốn ngay sau go-live, một cái là người dùng quay về Excel sau hai đợt đào tạo. Người ta thường xếp chúng vào hai ngăn: một cái là lỗi thiết kế, một cái là chuyện con người. Nhưng cùng một chỗ hỏng: bọn mình xây phần mềm theo bản mô tả công việc, và tưởng bản mô tả đó là công việc.

Chuyện này có người nghĩ trước mình khá lâu. Từ giữa thế kỷ trước, ngành nghiên cứu lao động ở Pháp đã tách hai khái niệm mà tiếng Việt hay gộp làm một: công việc được quy định và công việc được thực hiện. Dòng nghiên cứu về an toàn sau này mở thành bốn: công việc như người ta hình dung, như được quy định, như người ta kể lại khi được hỏi, và như nó thật sự diễn ra. Bốn thứ chồng lấn nhưng không cái nào trùng khít cái nào. Người dựng ra cách phân bốn ấy nhấn mạnh: cái thứ tư đáng quan tâm nhất mà ít được nhìn tới nhất - vì ba cái kia dễ lấy hơn nhiều, nên hay bị dùng thay cho nó.

Bạn để ý cái thứ ba trong danh sách chứ. Công việc như người ta kể lại khi được hỏi. Nó được xếp riêng, không gộp vào cái nào. Mình sẽ quay lại chuyện đó, ở một bài khác.

Còn bây giờ thì phải nói cái giá. Ngồi nhìn người ta làm việc tốn thời gian, và tốn thứ khó hơn thời gian. Không ai thoải mái khi có người lạ ngồi cạnh ghi chép trong lúc mình làm - nhất là người lạ đó đến từ bên nhà thầu, và nhất là ở chỗ mà “bị kiểm tra” nghĩa khác hẳn “được khảo sát”. Phải nói rõ mình ngồi đó để làm gì, và phải hỏi trước. Làm ẩu chuyện này thì bạn không thu được gì, chỉ được xem một buổi diễn.

Nên đừng quan sát mọi quy trình. Quan sát cái sắp bị đóng cứng vào phần mềm. Một quy trình sai trong tài liệu thì sửa tài liệu; sai rồi mà đã thành cái form có nút bấm thì phải qua một vòng phê duyệt thay đổi, một đợt phát hành, và vài tháng người ta không làm việc được. Vẫn là câu hỏi cũ: sai rồi thì gỡ có dễ không.

Và cái nguyên lý đằng sau chẳng dính gì tới quy trình hành chính. Một bản quy trình đã được phê duyệt cho bạn biết công việc được quy định sẽ diễn ra thế nào. Nó không tự chứng minh rằng đó là toàn bộ công việc đang diễn ra. Công việc thật thường có thêm một lớp điều chỉnh - cho những ca văn bản không lường, cho những nguồn lực không có. Lớp đó thường không được viết ra, và không nhất thiết vì ai giấu - nó không có chỗ nào trong hệ thống văn bản để mà nằm. Còn bản mô tả thì không tự khai rằng nó chỉ là bản mô tả.

Một việc bạn thử được ngay tuần này, nếu đang làm với một quy trình sắp số hoá. Ngồi cạnh một người làm việc đó, xong rồi hỏi đúng một câu: “Ngoài cái phần mềm này ra, để làm xong một hồ sơ thì chị còn phải mở cái gì nữa không ạ?”

Đừng hỏi “chị có làm tắt bước nào không”. Câu đó bắt người ta tự xếp loại hành vi của chính mình vào đúng-bước hay làm-tắt, và cách hỏi như vậy rất dễ đẩy người được hỏi về phương án an toàn. Không nhất thiết vì ai muốn giấu; chỉ là câu hỏi ấy đặt sai chỗ. Hỏi cái họ mở. File, sổ tay, nhóm chat, một cuộc gọi. Câu hỏi về một vật cụ thể kéo người ta về một hành động cụ thể, chứ không bắt họ tự đánh giá mình.

Có thể câu trả lời là không có gì. Nếu vậy thì tốt, bạn mất mười phút để yên tâm. Còn nếu có một cái gì đó, thì bạn chưa tìm ra lỗ hổng nào cả - bạn vừa tìm được một thứ đáng hỏi tiếp, trước khi đóng cái quy trình này vào phần mềm. Có khi nó là một phần việc thật đang thiếu chỗ. Có khi nó chỉ là cái máy tính bỏ túi.

Thảo hôm đó ngồi cùng mình cả buổi sáng. Lúc ra về nó nói: