Tự động hóa có nhất thiết phải bắt đầu từ một hệ thống lớn?

Khi nghĩ đến tự động hóa, người ta rất dễ hình dung một hệ thống lớn: các công cụ nối với nhau, dữ liệu di chuyển qua nhiều bước, báo cáo xuất hiện đúng giờ, mọi thứ hoạt động mà không cần ai nhắc. Hình ảnh ấy hấp dẫn vì nó hứa hẹn một tương lai nhẹ việc hơn. Nhưng gần đây, tôi lại muốn bắt đầu từ một câu hỏi khiêm tốn hơn: trong những việc mình phải làm lặp đi lặp lại mỗi sáng, việc nào đang thực sự lấy mất sự chú ý?

Tôi đang tìm cách tiếp cận những công việc nhập dữ liệu hằng ngày theo hướng ấy: chọn một việc cụ thể, hiểu đầu vào và đầu ra, rồi mới cân nhắc tự động hóa. Đây vẫn là một định hướng cần làm rõ và kiểm thử, không phải câu chuyện về một hệ thống tôi đã triển khai thành công. Chính vì chưa có thành quả để kể, câu hỏi về điểm bắt đầu lại càng đáng suy nghĩ.

Đôi khi ta muốn làm một hệ thống thật lớn không phải vì công việc đòi hỏi như vậy, mà vì hệ thống lớn làm ý tưởng của mình trông quan trọng hơn. Một quy trình nhỏ, lặp lại mỗi sáng, nghe có vẻ chẳng đáng đem ra nói trong một cuộc trình bày công nghệ. Nhưng có khi chính những việc nhỏ ấy lại là nơi ta nhìn rõ nhất sự khác nhau giữa làm cho nhanh hơn và làm cho đáng làm hơn.

Những việc nhỏ thường không nhỏ với người phải lặp lại chúng

Một thao tác mất vài phút có vẻ không đáng để tối ưu. Nhưng nếu nó xuất hiện gần như mỗi ngày, yêu cầu nhớ đúng thứ tự, chọn đúng tệp, sao chép đúng vùng dữ liệu rồi kiểm tra lại, nó không chỉ lấy đi số phút trên đồng hồ. Nó còn lấy một phần sự chú ý vào thời điểm người làm cần bắt đầu một ngày mới.

Không nên vì thế mà mặc định mọi việc lặp lại đều có hại. Có những thao tác thủ công giúp người vận hành nhận ra dấu hiệu bất thường, hiểu dữ liệu hoặc chuẩn bị tâm thế cho công việc. Nếu bỏ chúng mà không hiểu giá trị ấy, ta có thể tiết kiệm vài thao tác nhưng mất đi một cơ hội kiểm tra quan trọng.

Điều tôi muốn phân biệt là phần nào thực sự cần con người suy nghĩ, phần nào chỉ là di chuyển thông tin từ chỗ này sang chỗ khác. Chúng trông giống nhau trong một danh sách công việc, nhưng đòi hỏi những năng lực khác nhau. Chọn cách diễn giải một chỉ số nên có người chịu trách nhiệm. Sao chép cùng một dữ liệu theo quy tắc cố định thì có thể cần một cách làm khác.

Đừng hỏi công cụ làm được gì trước khi hiểu công việc

Với một công cụ mới, câu hỏi tự nhiên là: nó có thể kết nối những hệ thống nào; có thể gọi API nào; có thể viết dữ liệu ở đâu; có thể chạy tự động mấy lần một ngày? Những câu hỏi ấy cần thiết khi triển khai kỹ thuật, nhưng nếu đặt quá sớm, chúng dễ kéo người ta đi xa khỏi vấn đề ban đầu.

Có thể ta dành cả buổi để tìm cách nối hai phần mềm, rồi mới phát hiện thao tác đang muốn thay thế vốn chưa có quy tắc ổn định. Mỗi người làm một cách. Tên cột thay đổi. Có ngày thiếu dữ liệu, có ngày cần ngoại lệ. Khi ấy, việc dùng công cụ mạnh hơn không giải quyết được sự mơ hồ. Nó chỉ khiến sự mơ hồ di chuyển nhanh hơn.

Có lẽ nên thử mô tả công việc bằng ngôn ngữ đơn giản trước. Thông tin xuất phát từ đâu? Ai xác nhận nó đã đúng? Dữ liệu đi đến đâu? Khi nào được coi là hoàn thành? Nếu không có tệp nguồn thì làm gì? Nếu số mới khác số cũ bất thường thì ai quyết định? Một người mới đọc mô tả ấy có thể làm đúng mà không phải đoán không?

Nếu chưa trả lời được, có thể việc hữu ích nhất hôm nay không phải viết thêm một đoạn code, mà là ngồi xuống quan sát công việc. Việc này nghe chậm, nhưng đôi khi nó chính là phần tạo ra khả năng tự động hóa về sau.

Tự động hóa một thao tác sai chỉ khiến sai lầm đều đặn hơn

Có một sức cám dỗ trong chữ tự động: nó làm chúng ta liên tưởng đến sự chính xác. Máy không mệt, không quên bước đã được lập trình và có thể lặp lại đúng cùng một hành động. Nhưng chính tính nhất quán ấy lại có mặt trái. Nếu quy tắc đầu vào sai, một hệ thống vẫn có thể lặp lại lỗi rất đúng giờ.

Người làm thủ công có thể phát hiện một con số lạ vì nó khiến họ khựng lại. Hệ thống tự động có thể đi tiếp nếu chưa được dạy lúc nào phải dừng. Bởi vậy, điều cần viết rõ không chỉ là khi nào thao tác được thực hiện, mà còn là khi nào nó không được thực hiện. Dữ liệu thiếu, quyền truy cập bị từ chối, kết quả vượt ngưỡng hợp lý hoặc định dạng thay đổi đều có thể là lý do để báo người kiểm tra.

Tôi thấy ý tưởng ấy thú vị vì nó đảo ngược hình dung về tự động hóa. Một hệ thống tốt không nhất thiết là hệ thống làm được tất cả mà không hỏi. Có khi hệ thống tốt là hệ thống biết công việc nào nên để con người quyết định, và biết báo rõ khi mình chưa đủ điều kiện hoàn tất.

Bắt đầu nhỏ để giữ được quyền hiểu

Khi phạm vi còn hẹp, người tạo quy trình có cơ hội hiểu từng mắt xích. Họ biết một trường dữ liệu có nghĩa gì, kết quả đúng trông như thế nào, và lỗi thường xuất hiện ở đâu. Nếu việc thử nghiệm không đạt, họ có thể quay lại thao tác thủ công mà không làm đảo lộn cả hệ thống.

Điều này không tự động chứng minh làm nhỏ luôn rẻ hơn hay tốt hơn. Có những công việc chỉ có ý nghĩa khi giải quyết đồng thời cả một chuỗi lớn. Cũng có lúc xây từng mảnh rời rạc tạo ra quá nhiều chỗ nối. Nhưng với một người đang học cách tự động hóa công việc thường ngày, phạm vi nhỏ có một lợi thế quan trọng: sai thì còn hiểu được tại sao sai.

Một thử nghiệm nhỏ cần được chọn có chủ đích. Không chỉ vì nó dễ lập trình, mà vì đầu vào rõ, đầu ra kiểm tra được, hậu quả khi sai có thể kiểm soát và có người chịu trách nhiệm. Nếu không tìm được một việc đáp ứng các điều kiện ấy, có lẽ chưa nên vội chọn công cụ.

Thời gian tiết kiệm được có đi về nơi ta mong muốn?

Ta thường nói sẽ tự động hóa để tiết kiệm thời gian. Nhưng tiết kiệm thời gian cho ai, vào lúc nào và để làm gì? Nếu một việc mỗi sáng không còn cần thao tác thủ công, khoảng trống ấy có thể được dùng để kiểm tra chất lượng dữ liệu, tìm hiểu một vấn đề quan trọng hơn hoặc chỉ đơn giản bắt đầu ngày làm việc ít căng thẳng hơn.

Ngược lại, nếu vừa giải phóng một khoảng thời gian lại lập tức lấp đầy bằng thêm nhiều quy trình phải theo dõi, lợi ích thực tế có thể khác với kỳ vọng ban đầu. Hệ thống mới cần được bảo trì, theo dõi lỗi, cập nhật quyền truy cập và xử lý những lần dữ liệu nguồn thay đổi. Một công việc được tự động hóa không có nghĩa công việc quản lý nó biến mất.

Tôi nghĩ một phần giá trị thường bị quên là giảm sự gián đoạn. Không phải ngày nào cũng cần chứng minh đã tiết kiệm một số phút cụ thể. Đôi khi điều đáng quan sát hơn là buổi sáng có ít bước dễ nhầm hơn không; người làm có thể tập trung vào phần cần suy nghĩ hơn không; dữ liệu có dễ kiểm tra hơn không. Đây là những điều nên đo hoặc hỏi lại sau khi thử, không phải thành quả có thể tuyên bố trước khi triển khai.

Công cụ chỉ là một phần của lời hứa

Khi muốn dùng AI, workflow hay một kết nối dữ liệu mới, tôi thấy cần tự nhắc rằng công cụ không phải nhân vật chính. Người thực sự sống cùng quy trình mới là người có thể nói nó hữu ích hay phiền phức. Một đoạn tự động hóa chạy thành công trên màn hình của người thiết kế vẫn có thể gây khó cho người phải xử lý kết quả mỗi ngày.

Có thể màn hình báo “thành công”, nhưng người nhận không biết dữ liệu được lấy lúc nào. Có thể tệp được điền đầy đủ, nhưng không ai biết xử lý thế nào khi số liệu khác với ngày hôm trước. Có thể công cụ chạy rất nhanh, nhưng một thay đổi nhỏ ở nguồn khiến cả chuỗi dừng mà không có thông báo dễ hiểu.

Những khả năng ấy chưa phải lỗi đã xảy ra trong dự án cụ thể nào. Chúng là các câu hỏi cần hỏi trước. Nếu câu trả lời của hệ thống chỉ là “đã chạy xong”, người vận hành vẫn cần tìm hiểu nó đã làm gì, có đúng điều được giao hay không và phải xử lý thế nào khi chưa đúng.

Có những việc đáng bỏ hơn là đáng tự động hóa

Một câu hỏi ít hấp dẫn hơn xây hệ thống mới là: công việc này có còn cần tồn tại không? Ta có thể đang nhập cùng một thông tin vào nhiều bảng chỉ vì quy trình cũ hình thành như thế. Ta có thể tạo một báo cáo không còn ai đọc, hoặc giữ một bước sao chép vì không ai từng hỏi nó phục vụ quyết định nào.

Nếu một việc không còn tạo giá trị, tự động hóa nó có thể giúp tiết kiệm chút công sức nhưng vẫn giữ nguyên sự phức tạp. Loại bỏ một bước dư thừa, khi đã kiểm tra không có hậu quả xấu, đôi khi hữu ích hơn việc xây một công cụ thật khéo để thực hiện bước đó.

Điều khó là phân biệt bước thừa với bước kiểm soát. Một lần kiểm tra thủ công có thể trông chậm nhưng giúp bảo vệ chất lượng dữ liệu. Một lời xác nhận của người phụ trách có thể làm quy trình thêm thời gian nhưng ngăn thay đổi ngoài ý muốn. Vì vậy, trước khi cắt bớt, cần hiểu mục đích và người chịu trách nhiệm của bước đó.

Đừng lấy buổi demo đẹp làm bằng chứng cho việc vận hành bền

Một quy trình mới chạy trơn tru trên dữ liệu mẫu có thể khiến người làm rất hào hứng. Đó là tín hiệu tốt: ít nhất ý tưởng có khả năng thực hiện. Nhưng môi trường thật còn có dữ liệu trễ, cột thiếu, quyền đổi, và những buổi sáng không ai có thời gian ngồi chờ một lỗi nhỏ được giải thích.

Vì vậy, tôi thích cách đặt câu hỏi: nếu ngày mai không chạy được, ai biết và biết bằng cách nào? Nếu kết quả sai, có thể đối chiếu với nguồn gốc không? Nếu phải dừng, người phụ trách có quay lại cách làm cũ được không? Nếu thông tin nhạy cảm đi qua hệ thống, ranh giới nào giữ nó ở đúng nơi?

Đó không phải lời kêu gọi thiết kế quá nhiều lớp kiểm soát ngay từ ngày đầu. Trái lại, mục tiêu là chọn được một vài điều kiện căn bản để thử nghiệm nhỏ không biến thành một khoản nợ vận hành khó thấy. Khi phạm vi rõ, việc kiểm tra cũng có thể rất giản dị.

Một công việc buổi sáng có thể dạy nhiều hơn một sơ đồ lớn

Tôi chưa có lý do để kể rằng mình đã giải phóng được bao nhiêu giờ mỗi tháng nhờ kế hoạch này. Các tác vụ cụ thể còn cần được mô tả và thử nghiệm. Nhưng chính trạng thái chưa hoàn tất khiến tôi muốn giữ lại một cách làm: nhìn công việc bằng mắt người phải thực hiện nó trước khi nhìn bằng mắt người muốn xây hệ thống.

Một việc nhập dữ liệu có thể dạy ta về định nghĩa trường, về nguồn đáng tin, về thói quen kiểm tra, về nhu cầu thông báo và cả cách một nhóm chuyển giao trách nhiệm. Khi hiểu những điều ấy trên phạm vi nhỏ, ta mới có cơ sở để hỏi phần nào nên được kết nối thành một hệ thống lớn hơn.

Có thể sau cùng, việc chọn đúng một tác vụ nhỏ sẽ dẫn đến một workflow tự động. Cũng có thể nó chỉ dẫn đến một bảng hướng dẫn rõ hơn và ít sai sót hơn. Tôi không nghĩ kết quả thứ hai đáng thất vọng. Nếu mục tiêu là làm việc tốt hơn, công cụ chỉ là một con đường trong nhiều con đường.

Thứ tôi muốn giữ lại sau cùng

Tự động hóa nghe như câu chuyện về tương lai: để ngày mai bớt thao tác, bớt mệt và làm được nhiều việc hơn. Nhưng muốn đi đến tương lai đó, có lẽ trước tiên phải đủ kiên nhẫn nhìn thật kỹ việc đang xảy ra trong hiện tại.

Không cần bắt đầu bằng một hệ thống đồ sộ để chứng minh mình đang thay đổi cách làm. Cũng không cần coi mọi công việc lặp lại là thứ phải loại bỏ. Điều đáng hỏi hơn là: phần nào đang lấy sự chú ý mà không cần suy nghĩ, phần nào cần được giữ vì giúp kiểm soát chất lượng, và phần nào hoàn toàn có thể ngừng làm?

Tôi muốn bắt đầu từ một việc nhỏ mỗi sáng không phải vì thiếu tham vọng, mà vì muốn khi hệ thống lớn dần lên, mình vẫn hiểu nó đang phục vụ ai, giải quyết điều gì và phải dừng lại ở đâu.

Có lẽ tự động hóa trưởng thành không bắt đầu từ mong muốn bỏ con người ra khỏi quy trình, mà từ mong muốn trả lại cho con người thời gian và sự chú ý để làm những việc thật sự cần họ.