Có một loại công việc mà tôi thấy đặc biệt khó chịu.
Không phải vì nó phức tạp.
Mà vì nó quá đơn giản.
Một nhân viên mở đơn hàng.
Kiểm tra điều kiện thanh toán.
Xác nhận tồn kho.
Đối chiếu chính sách vận chuyển.
Ghi chú trạng thái.
Chuyển sang bộ phận tiếp theo.
Một quy trình khá bình thường.
Người nhân viên thực hiện đúng.
Không có sai sót.
Không có khiếu nại.
Công việc hoàn tất.
Ngày hôm sau, họ tiếp tục làm như vậy.
Ngày tiếp theo cũng vậy.
Một tháng sau, họ đã thực hiện cùng một chuỗi thao tác hàng nghìn lần.
Và doanh nghiệp đánh giá họ là một nhân viên chăm chỉ, có kinh nghiệm, xử lý công việc ổn định.
Tôi không phản đối nhận định đó.
Nhưng có một câu hỏi khiến tôi khó chịu hơn nhiều so với việc nhân viên phải thực hiện những thao tác lặp lại.
Tại sao chúng ta lại cần một bộ não con người để thực hiện hàng nghìn lần một chuỗi quyết định mà các điều kiện đúng sai đã được xác định rõ?
Nếu quy trình chỉ yêu cầu kiểm tra một số dữ liệu, đối chiếu những ràng buộc và thực hiện một hành động đã được định nghĩa, thì chính xác phần nào cần đến trí thông minh của con người?
Phần nào cần kinh nghiệm?
Phần nào cần khả năng phán đoán?
Và phần nào đơn giản chỉ cần một cơ chế thực thi đáng tin cậy?
Đây là câu hỏi thường khiến bộ não Software Engineer của tôi bắt đầu hoạt động.
Chúng ta có thể tự động hóa việc này không?
Nhưng sau nhiều lần suy nghĩ về cách doanh nghiệp vận hành, tôi nhận ra đó chưa phải câu hỏi quan trọng nhất.
Câu hỏi quan trọng hơn là:
Nếu tự động hóa được công việc này, chúng ta sẽ sử dụng năng lực con người được giải phóng để làm điều gì?
Bởi vì nếu câu trả lời chỉ là tạo ra thêm một trăm công việc lặp lại khác, chúng ta có thể đang xây dựng một cỗ máy cực kỳ hiện đại để tiếp tục lãng phí trí tuệ con người theo một cách hiệu quả hơn.
Một thành tựu đáng nể.
Nhưng không phải điều tôi muốn theo đuổi.
01. Sự lặp lại là một tín hiệu, không phải mệnh lệnh phải tự động hóa.
Tôi thích quan sát những công việc lặp lại.
Chúng thường chỉ ra cơ hội cải tiến.
Một nhân viên phải nhập cùng một thông tin vào ba hệ thống.
Một quản lý phải phê duyệt cùng một loại yêu cầu hàng chục lần.
Một bộ phận phải liên tục đối chiếu dữ liệu từ những nguồn khác nhau.
Một người phải ghi nhớ những điều kiện mà phần mềm hoàn toàn có khả năng kiểm tra.
Những công việc đó khiến tôi tò mò.
Nhưng tôi không cho rằng cứ có sự lặp lại là phải tự động hóa.
Một đầu bếp có thể lặp lại thao tác chế biến một món ăn hàng trăm lần.
Một nhân viên tư vấn có thể lặp lại những câu hỏi cơ bản với nhiều khách hàng.
Một người kiểm tra chất lượng có thể xem xét những sản phẩm tương tự mỗi ngày.
Không phải mọi sự lặp lại đều vô nghĩa.
Có những công việc mà sự thành thạo của con người tạo ra giá trị trực tiếp.
Có những hoạt động đòi hỏi cảm nhận, phán đoán hoặc khả năng thích nghi với những chi tiết không dễ mô hình hóa.
Và có những công việc tuy lặp lại nhưng chi phí tự động hóa cao hơn nhiều so với lợi ích có thể đạt được.
Vì vậy, tôi muốn phân biệt ba loại hoạt động.
Mechanical Repetition — Lặp lại thao tác.
Những công việc có đầu vào, quy trình và kết quả đã được xác định tương đối rõ.
Chẳng hạn sao chép dữ liệu, kiểm tra định dạng, đối chiếu mã hoặc cập nhật trạng thái theo quy tắc.
Đây thường là những ứng viên dễ xem xét tự động hóa.
Rule-Based Decisions — Quyết định dựa trên điều kiện đã biết.
Những tình huống cần đánh giá dữ liệu nhưng logic ra quyết định có thể được diễn đạt thành những ràng buộc tương đối chính xác.
Chẳng hạn xác định phí vận chuyển theo chính sách, kiểm tra hạn mức hoặc phân loại giao dịch theo điều kiện đã định nghĩa.
Chúng cũng có thể được tự động hóa, nhưng đòi hỏi sự chính xác về logic nghiệp vụ.
Judgment-Dependent Work — Công việc cần phán đoán.
Những tình huống có thông tin chưa đầy đủ, mục tiêu xung đột, hậu quả khó dự đoán hoặc cần hiểu sâu về bối cảnh.
Chẳng hạn đánh giá một cơ hội kinh doanh mới, giải quyết một quan hệ khách hàng phức tạp hoặc quyết định thay đổi chiến lược.
Chúng có thể được hỗ trợ bằng công nghệ.
Nhưng không nhất thiết nên được giao hoàn toàn cho máy.
Ranh giới giữa ba loại không cố định.
Một quyết định từng đòi hỏi kinh nghiệm có thể trở nên đủ rõ để tự động hóa sau khi chúng ta hiểu được cấu trúc.
Ngược lại, một quy tắc từng hoạt động tốt có thể trở nên không phù hợp khi thị trường thay đổi.
Automation is not a binary choice. It is a boundary that moves as our understanding improves.
Tự động hóa không phải lựa chọn có hoặc không.
Nó là một ranh giới thay đổi theo mức độ hiểu biết của chúng ta.
Điều tôi quan tâm là làm sao dịch chuyển ranh giới ấy một cách có trách nhiệm.
Không quá chậm để lãng phí nguồn lực.
Nhưng cũng không quá nhanh đến mức tự động hóa những quyết định mà bản thân tổ chức chưa thực sự hiểu.
02. Đừng tự động hóa những cú nhấp chuột. Hãy hiểu quyết định đằng sau chúng.
Có một cách làm automation khá phổ biến.
Chúng ta quan sát nhân viên đang thao tác.
Họ mở màn hình.
Nhấp nút.
Sao chép dữ liệu.
Chuyển tab.
Nhập thông tin.
Và xác nhận.
Sau đó, chúng ta tạo một chương trình thực hiện chính xác những thao tác ấy.
Tôi không phản đối.
Trong một số trường hợp, đó là cách tiết kiệm thời gian và công sức rất hợp lý.
Nhưng tôi cho rằng nó có giới hạn.
Bởi vì mô phỏng hành vi con người không đồng nghĩa với việc hiểu công việc mà con người đang thực hiện.
Hãy tưởng tượng một nhân viên phải mở hai hệ thống để kiểm tra trạng thái công nợ trước khi xác nhận đơn hàng.
Chúng ta có thể tạo một automation mở cả hai màn hình, lấy dữ liệu rồi nhấp xác nhận.
Nhưng tại sao nhân viên phải mở hai hệ thống?
Hệ thống nào thực sự có thẩm quyền xác định trạng thái công nợ?
Dữ liệu có thể bị trễ không?
Những khoản thanh toán đang xử lý có được tính đến không?
Điều kiện nào khiến đơn hàng được phép tiếp tục?
Và tại thời điểm giao dịch được xác nhận, những ràng buộc đó có còn đúng không?
Nếu chúng ta chưa trả lời những câu hỏi ấy, automation chỉ đang thực hiện nhanh hơn một quy trình mà chúng ta chưa thực sự hiểu đầy đủ.
Nó có thể tiết kiệm thao tác.
Nhưng chưa chắc nâng cao tính đúng đắn.
Tôi thích nhìn một quy trình qua bốn hoạt động cơ bản.
Observe — Thu thập trạng thái.
Hệ thống cần biết điều gì?
Decide — Xác định hành động phù hợp.
Những điều kiện nào quyết định kết quả?
Execute — Thực hiện hành động.
Hành động tạo ra thay đổi hoặc cam kết nào?
Verify — Kiểm chứng kết quả.
Làm sao biết hành động đã thành công và không vi phạm ràng buộc?
Khi phân tách như vậy, chúng ta thường phát hiện rằng một phần công việc đang tồn tại chỉ để bù đắp cho thiếu sót của phần khác.
Nhân viên phải nhập dữ liệu nhiều lần vì các hệ thống chưa kết nối.
Phải xác nhận thủ công vì không có nguồn sự thật có thẩm quyền.
Phải gửi tin nhắn vì workflow không thể hiện đầy đủ trạng thái.
Phải kiểm tra lại vì hệ thống không bảo đảm được một điều kiện quan trọng.
Nếu tự động hóa những thao tác đó mà không xem xét nguyên nhân, chúng ta có thể giữ nguyên toàn bộ sự phức tạp không cần thiết.
Chỉ khác là bây giờ máy tính sẽ thực hiện nó.
Với tốc độ rất cao.
The first question is not how to automate the workflow. It is why the workflow exists in its current form.
Tôi không muốn tự động hóa một bước công việc chỉ để phát hiện rằng bước đó đáng lẽ không cần tồn tại.
Loại bỏ một thao tác vô nghĩa thường tốt hơn xây dựng một hệ thống tự động thực hiện thao tác vô nghĩa.
Ít code hơn.
Ít bảo trì hơn.
Ít khả năng xảy ra lỗi hơn.
Và không cần thêm một dashboard để theo dõi xem automation có đang tự động làm chuyện vô nghĩa một cách thành công hay không.
03. Không phải mọi công việc lặp lại đều có cùng giá trị kinh tế.
Giả sử chúng ta có hai hoạt động.
Hoạt động thứ nhất tiêu tốn mười phút mỗi ngày của một nhân viên.
Hoạt động thứ hai tiêu tốn năm phút mỗi ngày của người duy nhất có khả năng giải quyết một nhóm vấn đề chiến lược quan trọng.
Nên tự động hóa hoạt động nào trước?
Nếu chỉ tính tổng thời gian, chúng ta có thể chọn hoạt động thứ nhất.
Nếu tính mức độ quan trọng của công việc đang bị gián đoạn, câu trả lời có thể khác.
Tôi nghĩ đây là một điểm thường bị đánh giá chưa đầy đủ trong các dự án automation.
Chúng ta thích tính số giờ lao động tiết kiệm được.
Một thao tác mất hai phút.
Một ngày thực hiện hai trăm lần.
Vậy tiết kiệm được bốn trăm phút.
Nhân với số ngày làm việc.
Nhân với chi phí lao động.
Và chúng ta có một bảng tính Return on Investment khá đẹp.
Nhưng thời gian không phải một nguồn lực hoàn toàn đồng nhất về giá trị sử dụng.
Một phút xử lý thủ công của nhân viên có thể ảnh hưởng đến năng suất.
Một phút gián đoạn của người đang thiết kế kiến trúc mới có thể ảnh hưởng đến khả năng hoàn thành một công việc có giá trị dài hạn.
Một phút chờ phê duyệt có thể khiến một khách hàng quan trọng bỏ giao dịch.
Và một phút chậm trễ trong xử lý sự cố có thể ảnh hưởng đến hàng trăm giao dịch khác.
Tôi không đề xuất chúng ta tùy tiện gán những giá trị tưởng tượng cho thời gian của người lãnh đạo.
Điều đó rất dễ dẫn đến những bảng tính đẹp nhưng không có giá trị thực tế.
Tôi chỉ muốn nhấn mạnh rằng chi phí xử lý trực tiếp không phản ánh đầy đủ chi phí của sự phụ thuộc.
Một automation có thể không tiết kiệm nhiều giờ lao động.
Nhưng nếu nó loại bỏ một điểm phê duyệt thường xuyên tạo hàng đợi, giá trị có thể rất lớn.
Một cải tiến có thể không giảm biên chế.
Nhưng giúp tổ chức tăng khối lượng giao dịch mà không cần tăng tương ứng nguồn lực hành chính.
Một cơ chế có thể không giảm đáng kể thời gian làm việc.
Nhưng giúp một người có năng lực cao duy trì được sự tập trung cho những vấn đề khó hơn.
Đó là những giá trị tôi muốn quan sát.
Automation ROI should include the capacity it releases, not merely the labor minutes it removes.
Tuy nhiên, năng lực được giải phóng chỉ trở thành giá trị khi nó thực sự được sử dụng.
Nếu nhân viên được tiết kiệm hai giờ mỗi ngày nhưng tổ chức không biết dùng hai giờ đó vào việc gì, chúng ta mới tạo ra năng lực dự phòng.
Chưa chắc tạo ra kết quả kinh doanh mới.
Một automation tốt không chỉ có kế hoạch triển khai.
Nó nên có cả một giả thuyết về cách năng lực được giải phóng sẽ tạo ra giá trị.
Nếu không, chúng ta có thể đang tối ưu một con số mà chưa xác định được ý nghĩa kinh doanh của nó.
04. Một quy tắc sai được tự động hóa vẫn là một quy tắc sai.
Hãy tưởng tượng chúng ta xây dựng một hệ thống tự động tính phí vận chuyển.
Nó lấy giá trị đơn hàng.
Xác định khu vực giao.
Áp dụng chính sách.
Tính phí.
Và hoàn tất.
Mọi thứ hoạt động rất nhanh.
Không cần nhân viên can thiệp.
Không có sai sót thao tác.
Nhưng sau ba tháng, chúng ta phát hiện một nhóm đơn hàng có giá trị tương đối cao vẫn mang lại lợi nhuận rất thấp.
Lý do là cấu trúc chi phí phục vụ của nhóm đơn này khác với những giả định ban đầu.
Có thể tuyến giao dài.
Có thể hàng hóa cồng kềnh.
Có thể số điểm giao và thời gian phục vụ khiến chi phí thực tế lớn hơn dự tính.
Hệ thống đã tính phí đúng theo chính sách.
Không có bug.
Không có lỗi database.
Không có request thất bại.
Nhưng chính sách được tự động hóa không phản ánh đầy đủ thực tế kinh tế.
Đây là một trong những điều nguy hiểm nhất của automation.
Máy móc rất giỏi thực hiện nhất quán những điều chúng ta yêu cầu. Kể cả khi yêu cầu đó sai.
Một nhân viên thực hiện thủ công có thể thỉnh thoảng nhận thấy một tình huống bất thường.
Họ có thể hỏi lại.
Có thể nghi ngờ.
Có thể nhận ra rằng một giao dịch trông có vẻ hợp lệ nhưng không thực sự hợp lý.
Khi quy trình được tự động hóa hoàn toàn, những tín hiệu đó có nguy cơ biến mất nếu chúng ta không chủ động thiết kế cơ chế quan sát.
Và một sai lầm trong mô hình có thể được nhân rộng trên hàng nghìn giao dịch.
Với độ chính xác tuyệt vời.
Tôi nghĩ trước khi tự động hóa một quyết định, chúng ta phải phân biệt được ít nhất ba điều.
Execution Correctness — Hành động có được thực hiện đúng không?
Policy Correctness — Quy tắc được áp dụng có đúng với chính sách không?
Business Correctness — Chính sách và kết quả có còn phù hợp với mục tiêu kinh doanh không?
Một hệ thống có thể đạt hai điều đầu và thất bại ở điều thứ ba.
Và điều thứ ba thường khó đánh giá nhất.
Bởi vì nó đòi hỏi chúng ta xem xét kết quả qua thời gian.
Không chỉ qua một giao dịch.
Đó là lý do automation phải kết nối với Business Observability mà chúng ta đã bàn ở Chapter 7.
Không phải để tạo thêm biểu đồ.
Mà để kiểm tra xem những quyết định tự động có đang tạo ra kết quả như dự kiến không.
Automation without observability is a machine that can fail at scale without anyone noticing.
Một máy tính thực hiện sai một nghìn lần nhanh hơn con người không phải một thành tựu.
Nó chỉ là một phương pháp công nghiệp hóa sai lầm.
05. Không phải mọi quyết định đều đáng được trao quyền tự động như nhau.
Tôi nghĩ một kiến trúc automation trưởng thành phải biết phân biệt mức độ rủi ro của hành động.
Có những thao tác rất dễ đảo ngược.
Có những thao tác tạo ra tác động đáng kể nhưng vẫn có khả năng khắc phục.
Và có những quyết định mà hậu quả đã xảy ra trong thế giới thực gần như không thể hoàn tác đầy đủ.
Gắn nhãn phân loại cho một lead có thể tương đối dễ sửa.
Gợi ý một bộ sản phẩm cho nhân viên có thể được kiểm tra trước khi gửi khách.
Nhưng thay đổi giá đã cam kết, xác nhận một điều kiện tín dụng hoặc phát lệnh giao hàng có thể tạo ra hậu quả kinh tế và nghĩa vụ thực tế.
Không nên sử dụng cùng một cơ chế tự động hóa cho tất cả.
Tôi thích nghĩ đến những cấp độ khác nhau.
Assistive Automation — Tự động hỗ trợ.
Hệ thống thu thập thông tin, phân tích và đề xuất.
Con người vẫn đưa ra quyết định cuối cùng.
Conditional Automation — Tự động có điều kiện.
Hệ thống thực hiện hành động khi những điều kiện rõ ràng được đáp ứng.
Những trường hợp ngoài phạm vi được chuyển sang xử lý riêng.
Bounded Autonomy — Tự chủ trong giới hạn.
Hệ thống được phép thực hiện một nhóm hành động với phạm vi quyền hạn, ngân sách, điều kiện và khả năng khôi phục đã được thiết kế.
Human-Controlled Exceptions — Ngoại lệ cần con người quyết định.
Những tình huống chưa đủ hiểu biết, có rủi ro cao hoặc đòi hỏi phán đoán đặc biệt được giữ lại cho người có thẩm quyền.
Đây không phải một thang đo để doanh nghiệp cố gắng đẩy mọi hoạt động lên mức tự động cao nhất.
Có những công việc nên duy trì ở mức hỗ trợ trong thời gian dài.
Có những quyết định có thể hoàn toàn tự động.
Và có những hành động mà quyền quyết định cuối cùng nên thuộc về con người vì bản chất trách nhiệm hoặc hậu quả của chúng.
Điểm quan trọng là mỗi cấp độ phải có lý do.
The goal is not maximum automation. It is appropriate autonomy for each class of decision.
Tôi không muốn hệ thống tự động mọi thứ chỉ vì nó có khả năng làm được.
Cũng như tôi không muốn giữ lại mọi bước phê duyệt chỉ vì người quản lý cảm thấy an toàn hơn khi trực tiếp kiểm tra.
Cả hai đều có thể là những hình thức thiết kế dựa trên cảm xúc.
Chỉ khác một bên quá tin tưởng máy móc.
Bên còn lại quá tin tưởng chính mình.
06. Cơ chế xử lý thất bại quan trọng không kém cơ chế xử lý thành công.
Một quy trình tự động thường rất đẹp khi mọi thứ diễn ra đúng như dự kiến.
Dữ liệu hợp lệ.
Hệ thống phản hồi.
Điều kiện được đáp ứng.
Hành động thành công.
Trạng thái được cập nhật.
Nhưng thực tế không luôn hợp tác.
Một service có thể không phản hồi.
Một sự kiện có thể được gửi hai lần.
Một dữ liệu có thể đến chậm.
Một giao dịch có thể bị thay đổi bởi tiến trình khác.
Một thao tác có thể thành công một phần.
Và một hệ thống bên ngoài có thể báo lỗi sau khi đã thực sự thực hiện hành động.
Đây là những tình huống quen thuộc với Software Engineer.
Nhưng khi automation đi vào hoạt động kinh doanh, ý nghĩa của chúng trở nên rất cụ thể.
Một đơn hàng được tạo hai lần.
Một khoản ưu đãi bị áp dụng hai lần.
Một giao dịch bị đánh dấu hoàn tất dù chưa thực sự thành công.
Một khách hàng nhận hai thông báo mâu thuẫn.
Một lệnh giao hàng được phát ra trong khi điều kiện tín dụng đã thay đổi.
Những lỗi đó không chỉ là exception trong log.
Chúng là sự kiện kinh doanh.
Vì vậy, tôi không muốn một automation chỉ được thiết kế cho happy path.
Nó phải biết điều gì xảy ra khi không thể tiếp tục.
Khi nào thử lại?
Khi nào dừng?
Khi nào yêu cầu con người can thiệp?
Khi nào cần kiểm tra lại trạng thái trước khi thực hiện?
Và khi một hành động đã tạo ra tác động không thể tự động đảo ngược, chúng ta có cơ chế xử lý hậu quả thế nào?
Một hệ thống đáng tin cậy không nhất thiết phải tự sửa được mọi lỗi.
Nhưng nó phải biết cách thất bại mà không tạo ra hỗn loạn không cần thiết.
Graceful failure is part of successful automation.
Thất bại có kiểm soát là một phần của tự động hóa thành công.
Đôi khi, quyết định tốt nhất của phần mềm là từ chối tiếp tục.
Không phải vì nó thiếu thông minh.
Mà vì nó đã nhận diện được rằng điều kiện cần thiết để hành động an toàn không còn được bảo đảm.
Tôi thích những hệ thống biết giới hạn của mình.
Chúng thường đáng tin cậy hơn những hệ thống luôn cố gắng đưa ra một câu trả lời.
Đặc biệt khi câu trả lời đó có thể khiến một chiếc xe tải phải chạy thêm vài chục cây số.
07. Ngoại lệ là nơi chúng ta quyết định ranh giới giữa con người và máy móc.
Trong Chapter 3, tôi đã bàn về những ngoại lệ và chi phí vô hình mà chúng tạo ra.
Nhưng khi bước vào automation, ngoại lệ còn mang một ý nghĩa quan trọng hơn.
Chúng cho thấy ranh giới hiện tại của những gì hệ thống đã hiểu.
Một giao dịch bình thường có thể được xử lý tự động.
Một tình huống không nằm trong các điều kiện đã định nghĩa cần được xem xét.
Một kết quả bất thường cần được phân tích.
Và một nhóm ngoại lệ liên tục xuất hiện có thể cho thấy những giới hạn của mô hình hiện tại.
Tôi không muốn mọi ngoại lệ đều bị đẩy lên quản lý.
Nhưng cũng không muốn mọi ngoại lệ đều bị chặn một cách máy móc.
Tôi thích một cơ chế có khả năng phân loại.
Những trường hợp đã biết và có chính sách rõ ràng được xử lý theo chính sách.
Những trường hợp có thể được phân quyền tiếp tục được xử lý bởi người có đủ quyền hạn.
Những tình huống thực sự mới được chuyển đến người có năng lực phù hợp.
Và những lỗi kỹ thuật được đưa đến đúng bộ phận chịu trách nhiệm.
Một yêu cầu hỗ trợ thương mại không nên tự động trở thành vấn đề của CEO.
Một lỗi đồng bộ tồn kho không nên được giải quyết bằng cách yêu cầu nhân viên bán hàng gọi điện xác nhận thủ công mãi mãi.
Một tình huống khách hàng có nhu cầu mới không nên bị từ chối chỉ vì chưa có trong danh sách quy tắc.
Mỗi nhóm cần một đường xử lý thích hợp.
Điều quan trọng hơn là những ngoại lệ đó phải quay trở lại để giúp hệ thống tiến hóa.
Nếu một loại tình huống xuất hiện đủ thường xuyên, chúng ta có thể phân tích xem nó đã đủ rõ để chuẩn hóa chưa.
Nếu chưa, cần thêm dữ liệu gì?
Nếu rủi ro có thể kiểm soát, có thể trao thêm quyền cho cấp thấp hơn không?
Nếu vẫn cần phán đoán, hệ thống có thể hỗ trợ con người ra quyết định tốt hơn thế nào?
Đây chính là cách ranh giới automation dịch chuyển.
Không phải bằng một dự án khổng lồ với tham vọng loại bỏ mọi thao tác thủ công.
Mà bằng một quá trình học hỏi có kiểm chứng.
Today's exceptions can become tomorrow's standard operations — but only after we understand them.
Những ngoại lệ hôm nay có thể trở thành quy trình tiêu chuẩn ngày mai.
Nhưng phải hiểu chúng trước.
Nếu chưa hiểu mà đã tự động hóa, chúng ta không giải quyết sự không chắc chắn.
Chúng ta chỉ giấu nó bên trong code.
Và sự không chắc chắn bị giấu đi thường có một thói quen khá khó chịu.
Nó quay trở lại vào những thời điểm tệ nhất.
08. AI không biến một quyết định chưa hiểu thành một quyết định đã hiểu.
Sự xuất hiện của AI làm cho bài toán automation hấp dẫn hơn rất nhiều.
Trước đây, nhiều công việc khó tự động hóa vì chúng phụ thuộc vào ngôn ngữ tự nhiên.
Khách hàng gửi tin nhắn.
Nhân viên phải đọc.
Hiểu yêu cầu.
Phân loại.
Tra cứu thông tin.
Và lựa chọn hướng xử lý.
Giờ đây, AI có thể hỗ trợ khá tốt một phần lớn những hoạt động đó.
Một AI assistant có thể nhận diện khách hàng đang hỏi giá, tìm sản phẩm, yêu cầu tư vấn hay khiếu nại.
Có thể tóm tắt cuộc trò chuyện.
Có thể tìm những sản phẩm phù hợp.
Có thể đề xuất phản hồi.
Và trong một số phạm vi, có thể trực tiếp thực hiện những hành động được cấp quyền.
Tôi thấy tiềm năng rất lớn.
Nhưng có một sai lầm tôi muốn tránh.
Khả năng AI tạo ra câu trả lời không đồng nghĩa với việc vấn đề đã có một mô hình quyết định đáng tin cậy.
Một khách hàng nhắn:
"Anh mua thường xuyên rồi, hỗ trợ anh chuyến này đi."
AI có thể hiểu khá tốt ngữ nghĩa của câu nói.
Nó có thể nhận ra đây là yêu cầu hỗ trợ thương mại dựa trên quan hệ khách hàng.
Nhưng liệu có nên chấp thuận?
Đó là một câu hỏi khác.
Cần dữ liệu về khách hàng.
Điều kiện giao dịch.
Chi phí.
Chính sách.
Thẩm quyền.
Và những ràng buộc đang có hiệu lực.
AI có thể giúp phân tích và đề xuất.
Nhưng hành động thực tế phải đi qua những cơ chế kiểm soát phù hợp.
Tôi thích phân biệt hai khả năng.
Interpretation — Hiểu ý định và bối cảnh.
Authorization — Xác định hành động nào được phép.
AI có thể mở rộng đáng kể năng lực ở tầng thứ nhất.
Nhưng điều đó không có nghĩa quyền hạn ở tầng thứ hai nên được giao hoàn toàn cho những câu trả lời xác suất.
Một mô hình có thể suy luận rằng khách hàng này rất đáng được hỗ trợ.
Nhưng một suy luận hợp lý không tự động tạo ra quyền thay đổi giá hay chi phí của doanh nghiệp.
Một hệ thống AI có quyền thực hiện hành động phải sử dụng các capability được cấp quyền, có kiểm tra điều kiện và có khả năng truy vết.
Với những hành động rủi ro cao, mức độ giám sát phải tương ứng.
Tôi cũng không cho rằng AI nên được sử dụng để che giấu sự thiếu rõ ràng trong chính sách.
Nếu doanh nghiệp chưa biết khi nào nên miễn phí vận chuyển, việc yêu cầu AI tự quyết định không làm bài toán biến mất.
Nó chỉ chuyển trách nhiệm phán đoán sang một thành phần khó kiểm soát hơn.
AI can automate interpretation faster than an organization can formalize responsibility. That gap is dangerous.
AI có thể tự động hóa việc diễn giải nhanh hơn tốc độ tổ chức làm rõ trách nhiệm.
Khoảng cách đó rất nguy hiểm.
Đặc biệt khi chúng ta bắt đầu cho AI quyền thực hiện hành động thay vì chỉ đề xuất.
Một chatbot trả lời sai có thể làm khách hàng khó chịu.
Một AI agent thực hiện sai một giao dịch có thể tạo ra nghĩa vụ kinh doanh.
Hai loại rủi ro đó không giống nhau.
Và một kiến trúc nghiêm túc phải biết phân biệt.
09. Tự động hóa có thể khiến con người mất dần năng lực.
Đây là một nghịch lý mà tôi cho rằng ít người yêu thích automation muốn nói đến.
Nếu máy móc thực hiện ngày càng nhiều công việc, con người có thể không còn đủ cơ hội để phát triển những kỹ năng từng được hình thành thông qua công việc đó.
Một nhân viên mới có thể sử dụng hệ thống để tìm sản phẩm phù hợp rất nhanh.
Nhưng họ có thực sự hiểu vì sao những sản phẩm đó phù hợp?
Một người có thể xác nhận đơn hàng thông qua những trạng thái được tính toán tự động.
Nhưng họ có hiểu những yếu tố kinh tế khiến một giao dịch đáng hoặc không đáng thực hiện?
Một người quản lý có thể nhìn dashboard để phát hiện vấn đề.
Nhưng họ có đủ năng lực đánh giá khi chính dữ liệu hoặc mô hình trên dashboard có sai sót?
Nếu mọi quyết định thông thường đều được tự động hóa, con người sẽ chủ yếu tiếp xúc với những tình huống bất thường.
Nhưng những tình huống bất thường thường khó hơn.
Chúng đòi hỏi kiến thức nền tảng và kinh nghiệm.
Vậy nếu những công việc cơ bản đã được máy xử lý, con người sẽ học những kiến thức và kinh nghiệm ấy bằng cách nào?
Đây là một câu hỏi nghiêm túc.
Một tổ chức không thể giả định rằng nhân viên sẽ tự nhiên phát triển khả năng phán đoán nếu công việc thường ngày không còn yêu cầu họ sử dụng khả năng đó.
Tôi nghĩ automation phải đi cùng một kiến trúc phát triển năng lực.
Nhân viên cần hiểu những nguyên lý quan trọng đằng sau hệ thống mà họ sử dụng.
Những người được giao xử lý ngoại lệ cần được đào tạo thông qua các tình huống thực tế và những bài toán có kiểm soát.
Những quyết định tự động có thể được lấy mẫu để kiểm tra, giải thích và thảo luận.
Và những người có tiềm năng cần có cơ hội tham gia vào việc phân tích nguyên nhân, cải thiện quy tắc và thiết kế giải pháp mới.
Không phải mọi nhân viên đều cần hiểu toàn bộ thuật toán.
Nhưng những người chịu trách nhiệm cho một lĩnh vực phải có khả năng nhận diện khi thuật toán không còn phản ánh đúng thực tế.
If automation removes routine experience, the organization must deliberately create opportunities for deeper learning.
Nếu tự động hóa loại bỏ những trải nghiệm công việc cơ bản, tổ chức phải chủ động tạo ra những cơ hội học hỏi sâu hơn.
Nếu không, chúng ta có thể xây dựng một thế hệ nhân viên rất thành thạo trong việc sử dụng phần mềm.
Nhưng thiếu khả năng vận hành khi phần mềm không còn đưa ra được câu trả lời.
Một tổ chức như vậy có thể cực kỳ hiệu quả trong điều kiện bình thường.
Và cực kỳ mong manh khi điều kiện thay đổi.
Tôi không muốn điều đó.
Tôi muốn máy móc giúp con người tiếp cận những công việc có giá trị cao hơn.
Không phải khiến họ dần đánh mất khả năng hiểu chính công việc mà mình đang phụ trách.
10. Không có gì nguy hiểm hơn một hệ thống tự động mà không ai còn hiểu.
Hãy tưởng tượng một doanh nghiệp đã tự động hóa rất nhiều hoạt động.
Giá được tính tự động.
Đơn hàng được phân loại tự động.
Lead được phân bổ tự động.
Sản phẩm được đề xuất tự động.
Chính sách được áp dụng tự động.
Vận chuyển được lập kế hoạch tự động.
Mọi thứ hoạt động tốt.
Rồi một ngày, một kết quả bất thường xuất hiện.
Một nhóm khách hàng bị phân loại sai.
Một chính sách được áp dụng không phù hợp.
Một loại sản phẩm được gợi ý dù không đáp ứng đủ điều kiện tương thích.
Hoặc một cơ chế tối ưu chi phí bắt đầu tạo ra những hậu quả không mong muốn ở bộ phận khác.
Người vận hành hỏi:
"Tại sao hệ thống lại làm như vậy?"
Và không ai trả lời được.
Người viết logic ban đầu đã nghỉ.
Tài liệu không còn phản ánh đầy đủ cách hệ thống hoạt động.
Các quy tắc đã được sửa nhiều lần.
Một số phần được tự động điều chỉnh theo dữ liệu.
Và những người hiện tại chỉ biết rằng trước giờ hệ thống vẫn chạy như vậy.
Tôi nghĩ đây là một trạng thái rất nguy hiểm.
Bởi vì doanh nghiệp đã chuyển sự phụ thuộc từ con người sang phần mềm.
Nhưng chưa thực sự xây dựng được khả năng kiểm soát phần mềm đó.
Trong Chapter 7, tôi đã nói người thiết kế không nên trở thành Operating System của doanh nghiệp.
Nhưng điều ngược lại cũng đúng.
Operating System không nên trở thành một hộp đen mà không ai trong doanh nghiệp đủ khả năng hiểu và thay đổi.
Tự động hóa cần khả năng giải thích ở mức phù hợp.
Không nhất thiết mọi quyết định phải có một bài luận dài.
Nhưng những hành động quan trọng nên có đủ thông tin để truy vết.
Dữ liệu đầu vào nào đã được sử dụng?
Quy tắc nào đang có hiệu lực?
Quyền hạn nào cho phép thực hiện hành động?
Trạng thái nào đã thay đổi?
Và nếu kết quả không phù hợp, ai có quyền can thiệp?
Một automation cũng cần người sở hữu về mặt vận hành.
Không chỉ người viết code.
Có người chịu trách nhiệm về tính đúng đắn của chính sách.
Có người theo dõi kết quả.
Có người đánh giá những ngoại lệ.
Và có cơ chế thay đổi khi điều kiện kinh doanh không còn phù hợp.
Tôi không muốn hệ thống hoạt động mãi bằng một logic chỉ có tác giả ban đầu mới hiểu.
Đó không phải là tri thức tổ chức.
Đó là tri thức cá nhân được mã hóa thành phần mềm.
Nghe hiện đại hơn.
Nhưng mức độ phụ thuộc có thể chẳng khác bao nhiêu.
11. Một tổ chức không nên tự động hóa để che giấu sự thiếu năng lực quản trị.
Có một trường hợp mà tôi nghĩ những người yêu thích công nghệ rất dễ mắc phải.
Một bộ phận vận hành không hiệu quả.
Quy trình thiếu rõ ràng.
Trách nhiệm chồng chéo.
Thông tin không được cập nhật nhất quán.
Nhân viên liên tục phải hỏi quản lý.
Và kết luận được đưa ra là:
"Chúng ta cần xây thêm phần mềm."
Có thể.
Nhưng phần mềm không tự động sửa được một cấu trúc trách nhiệm chưa được xác định.
Một automation có thể đẩy thông báo đến đúng người.
Nhưng nếu không ai thực sự có quyền quyết định, thông báo chỉ khiến sự thiếu rõ ràng xuất hiện nhanh hơn.
Một workflow có thể tự động chuyển công việc giữa các bộ phận.
Nhưng nếu các bộ phận có mục tiêu mâu thuẫn, việc chuyển nhanh hơn không nhất thiết giải quyết được xung đột.
Một AI có thể tóm tắt vấn đề rất tốt.
Nhưng nếu tổ chức không có người chịu trách nhiệm xử lý, bản tóm tắt chỉ là một tài liệu đẹp.
Tôi muốn phân biệt rõ.
Automation có thể thực thi một cơ chế đã được thiết kế.
Nhưng nó không thay thế được trách nhiệm thiết kế cơ chế đó.
Nếu quy trình hiện tại thiếu ownership, chúng ta phải làm rõ ownership.
Nếu quyền hạn không phù hợp, chúng ta phải thiết kế lại quyền hạn.
Nếu KPI tạo ra hành vi sai lệch, chúng ta phải xem lại KPI.
Nếu năng lực nhân sự không đáp ứng yêu cầu, chúng ta phải giải quyết vấn đề năng lực.
Và nếu chiến lược kinh doanh không phù hợp, một hệ thống tự động hóa xuất sắc cũng không biến nó thành chiến lược tốt.
Automation amplifies organizational design. It does not redeem bad organizational design.
Tự động hóa khuếch đại kiến trúc tổ chức.
Nó không cứu chuộc được một kiến trúc tồi.
Nếu mô hình vận hành tốt, automation có thể tạo ra đòn bẩy rất lớn.
Nếu mô hình vận hành sai, automation có thể khiến doanh nghiệp sai nhanh hơn và trên quy mô lớn hơn.
Vì vậy, trước khi tự động hóa một quy trình quan trọng, tôi muốn biết liệu chúng ta đã hiểu đủ rõ cơ chế đang được tự động hóa chưa.
Nếu chưa, đôi khi cần để con người tiếp tục xử lý trong một thời gian.
Không phải vì công nghệ không làm được.
Mà vì tổ chức chưa đủ hiểu để giao công việc đó cho công nghệ một cách đáng tin cậy.
12. Đừng nhầm tăng năng suất với tăng năng lực cạnh tranh.
Một doanh nghiệp có thể tự động hóa thành công rất nhiều công việc.
Số đơn xử lý mỗi nhân viên tăng.
Thời gian tạo giao dịch giảm.
Báo cáo được cập nhật nhanh.
Các bước kiểm tra trở nên nhất quán hơn.
Đây là những kết quả tích cực.
Nhưng tôi không cho rằng chúng tự động chuyển thành lợi thế cạnh tranh bền vững.
Bởi vì khi năng suất của một khâu tăng, giới hạn của toàn bộ hoạt động có thể chuyển sang nơi khác.
Hệ thống có thể tiếp nhận đơn hàng rất nhanh.
Nhưng kho không đủ công suất chuẩn bị.
Kho có thể xử lý nhanh.
Nhưng phương tiện vận chuyển không đáp ứng được giờ cao điểm.
Vận chuyển có thể mở rộng.
Nhưng vốn lưu động không đủ để duy trì mức tồn kho cần thiết.
Công nghệ có thể giúp tăng số lượng khách hàng.
Nhưng đội ngũ bán hàng chưa đủ năng lực chuyển những cơ hội đó thành quan hệ kinh doanh bền vững.
Đây là một hiện tượng quan trọng.
Khi loại bỏ một nút thắt, chúng ta không loại bỏ mọi giới hạn. Chúng ta thường làm lộ ra nút thắt tiếp theo.
Và không phải nút thắt nào cũng có thể giải quyết bằng phần mềm.
Một chiếc xe tải vẫn phải di chuyển qua không gian vật lý.
Một kho hàng vẫn có giới hạn diện tích và công suất.
Một nhân viên mới vẫn cần thời gian để phát triển năng lực.
Một quan hệ khách hàng quan trọng vẫn cần sự tin cậy được xây dựng qua nhiều lần tương tác.
Tôi thích công nghệ.
Nhưng tôi không có ý định dùng sự lạc quan của Software Engineering để phủ nhận những giới hạn của thế giới thực.
Một automation chỉ tạo ra lợi ích toàn hệ thống khi những thành phần còn lại có khả năng hấp thụ sự thay đổi.
Nếu tự động hóa giúp bán được nhiều hơn nhưng doanh nghiệp không giao hàng đúng hạn, chúng ta chưa chắc đã tạo ra giá trị.
Nếu hệ thống tiếp nhận thêm nhiều giao dịch nhưng phần lớn có hiệu quả kinh tế thấp, năng suất tăng chưa chắc khiến doanh nghiệp khỏe hơn.
Và nếu phần mềm tạo ra thêm rất nhiều cơ hội kinh doanh mà không ai có đủ năng lực khai thác, đó mới chỉ là tiềm năng.
Chưa phải kết quả.
Local efficiency is not the same as system throughput. System throughput is not the same as business value.
Hiệu quả cục bộ không đồng nghĩa với năng suất toàn hệ thống.
Và năng suất toàn hệ thống cũng không tự động đồng nghĩa với giá trị kinh doanh.
Đây là lý do tôi không muốn những dự án automation chỉ được đánh giá bằng số giờ tiết kiệm hoặc số thao tác bị loại bỏ.
Tôi muốn biết tổ chức đã cải thiện được điều gì.
Khả năng phục vụ khách hàng?
Độ tin cậy?
Hiệu quả kinh tế?
Năng lực mở rộng?
Hay khả năng thích nghi với những nhu cầu mới?
Nếu không thể chỉ ra một kết quả có ý nghĩa, có lẽ chúng ta chưa xác định đúng giá trị cần tạo ra.
13. Automation Debt — Khi những thứ giúp tiết kiệm thời gian bắt đầu tiêu tốn thời gian.
Có một giai đoạn trong phát triển phần mềm mà automation đem lại cảm giác cực kỳ dễ chịu.
Một công việc thủ công được thay thế.
Thêm một automation.
Một báo cáo được tạo tự động.
Thêm một automation.
Một quy trình được đồng bộ.
Thêm một automation.
Một thông báo được kích hoạt theo điều kiện.
Thêm một automation.
Mọi thứ trông ngày càng hiện đại.
Cho đến khi doanh nghiệp thay đổi chính sách.
Và chúng ta phát hiện một thay đổi nhỏ có thể ảnh hưởng đến hàng chục cơ chế tự động khác nhau.
Một quy tắc được sửa.
Một job cũ vẫn sử dụng điều kiện trước đó.
Một automation chạy theo lịch chưa được cập nhật.
Một service phụ thuộc vào trạng thái đã thay đổi ý nghĩa.
Một nhóm nhân viên vẫn sử dụng phương pháp xử lý cũ vì không biết cơ chế mới đã được triển khai.
Hệ thống bắt đầu tạo ra những hành vi không nhất quán.
Và nhóm kỹ thuật phải dành thời gian truy tìm nguyên nhân.
Điều thú vị là những automation ban đầu được xây dựng để giảm thời gian làm việc thủ công.
Nhưng sau một thời gian, chúng có thể trở thành một nguồn công việc mới.
Theo dõi.
Bảo trì.
Xử lý lỗi.
Đồng bộ phiên bản.
Kiểm tra ảnh hưởng.
Và khắc phục những tình huống không được dự đoán trước.
Tôi gọi đây là Automation Debt.
Khoản nợ tự động hóa.
Không phải mọi khoản nợ đều xấu.
Một automation đơn giản được xây dựng nhanh để giải quyết một nhu cầu cấp thiết có thể hoàn toàn hợp lý.
Nhưng nếu những giải pháp tạm thời liên tục tích tụ mà không có kiến trúc chung, chi phí bảo trì có thể ngày càng lớn.
Và đến một thời điểm, chúng ta phải thuê người để chăm sóc những automation được xây dựng nhằm giảm nhu cầu sử dụng con người.
Một vòng tròn khá thú vị.
Đặc biệt khi bộ phận IT bắt đầu đề xuất thêm một automation để giám sát các automation khác.
Tôi không phản đối việc giám sát tự động.
Nhưng tôi nghĩ chúng ta nên nhận ra khi nào sự phức tạp đang tăng nhanh hơn giá trị mà nó tạo ra.
Một hệ thống automation trưởng thành cần có khả năng quản lý vòng đời.
Cơ chế nào đang hoạt động?
Ai chịu trách nhiệm?
Nó phụ thuộc vào những dữ liệu và chính sách nào?
Kết quả thực tế ra sao?
Khi có thay đổi, những thành phần nào bị ảnh hưởng?
Và khi một automation không còn tạo ra đủ giá trị, chúng ta có sẵn sàng loại bỏ nó không?
Tôi nghĩ câu hỏi cuối cùng rất quan trọng.
Bởi vì người xây dựng thường có xu hướng yêu thích những gì mình đã tạo ra.
Một đoạn code từng khiến chúng ta tự hào có thể tiếp tục được bảo trì nhiều năm, dù giá trị kinh doanh đã không còn tương xứng.
A system that can automate new work must also be capable of retiring obsolete automation.
Một hệ thống có khả năng tạo automation mới cũng phải có khả năng loại bỏ những automation đã lỗi thời.
Nếu không, chúng ta không thực sự kiểm soát sự phức tạp.
Chúng ta chỉ liên tục tích lũy nó.
14. Không phải mọi thời gian được giải phóng đều nên được lấp đầy.
Đây là một điều tôi muốn bàn sâu hơn.
Trong quản trị, chúng ta có xu hướng xem thời gian nhàn rỗi như một nguồn lực chưa được sử dụng hiệu quả.
Nếu automation giúp nhân viên tiết kiệm hai giờ mỗi ngày, phản ứng tự nhiên là giao thêm công việc để lấp đầy hai giờ đó.
Tôi hiểu logic kinh tế.
Doanh nghiệp không nên lãng phí nguồn lực.
Nhưng tôi nghĩ chúng ta cần phân biệt thời gian nhàn rỗi vô ích với năng lực dự phòng có giá trị.
Một tổ chức vận hành ở mức công suất tối đa liên tục có thể trông rất hiệu quả.
Không ai rảnh.
Mọi người đều bận.
Không có thời gian trống.
Nhưng khi một vấn đề mới xuất hiện, tổ chức không còn nguồn lực để xử lý.
Một khách hàng quan trọng cần hỗ trợ.
Không ai có thời gian.
Một cơ hội thị trường xuất hiện.
Không ai có khả năng nghiên cứu.
Một quy trình bộc lộ vấn đề.
Không ai có thời gian phân tích nguyên nhân.
Và một nhân viên đề xuất ý tưởng cải tiến.
Quản lý trả lời:
"Để khi nào rảnh."
Một thời điểm rất thú vị.
Thường không bao giờ đến.
Tôi không cho rằng mọi bộ phận đều nên duy trì công suất dự phòng giống nhau.
Mức dự phòng phù hợp phụ thuộc vào biến động nhu cầu, tính chất công việc và chi phí của việc chờ đợi.
Nhưng với những vị trí đòi hỏi phán đoán, sáng tạo và xử lý tình huống mới, khả năng có thời gian suy nghĩ liên tục là một nguồn lực quan trọng.
Nếu chúng ta tự động hóa mười công việc thường ngày rồi lập tức giao thêm mười công việc thường ngày khác, tổ chức có thể tăng sản lượng.
Nhưng chưa chắc tăng khả năng học hỏi.
Tôi muốn một phần năng lực được giải phóng dành cho những hoạt động không thể được đo lường hoàn toàn bằng số lượng giao dịch.
Học một lĩnh vực mới.
Phân tích một nhóm khách hàng.
Xem xét những ngoại lệ.
Thử nghiệm một phương pháp.
Đánh giá một giả định kinh doanh.
Hoặc đơn giản là có đủ thời gian để suy nghĩ sâu về một vấn đề chưa có lời giải.
Slack is not always waste. Sometimes it is the capacity required for adaptation.
Năng lực dự phòng không phải lúc nào cũng là lãng phí.
Đôi khi đó là điều kiện cần thiết để tổ chức thích nghi.
Một doanh nghiệp không có thời gian để học hỏi có thể vẫn hoạt động rất hiệu quả.
Cho đến khi môi trường thay đổi.
Và lúc ấy, tất cả mọi người đều quá bận để hiểu tại sao mình đang gặp khó khăn.
15. Tự động hóa công việc thường ngày để mở ra công việc chưa từng tồn tại.
Đây là nơi tôi nghĩ automation thực sự trở nên thú vị.
Một nhân viên không còn phải mất quá nhiều thời gian kiểm tra điều kiện giao dịch.
Họ có thể dành nhiều thời gian hơn để hiểu khách hàng.
Một người không còn phải nhập thông tin sản phẩm thủ công ở nhiều nơi.
Họ có thể tập trung vào việc phát triển tri thức sản phẩm.
Một quản lý không còn phải phê duyệt hàng chục yêu cầu đã có quy tắc rõ ràng.
Họ có thể dành thời gian đào tạo đội ngũ, đánh giá những tình huống khó và tìm cơ hội cải tiến.
Một nhân viên bán hàng không còn chỉ là người nhận đơn và theo dõi đơn.
Họ có thể dần trở thành người hiểu sâu một ngành nghề.
Một chuyên gia về bao bì cho quán cà phê.
Một người có khả năng tư vấn giải pháp cho tiệm bánh.
Một người phát triển những sản phẩm in ấn phù hợp với một nhóm khách hàng cụ thể.
Một người có thể tự xây dựng những công cụ giúp khách hàng lựa chọn, tính toán và vận hành tốt hơn.
Đây không còn chỉ là automation.
Nó bắt đầu liên quan đến job redesign.
Thiết kế lại công việc.
Và xa hơn là thiết kế lại vai trò của con người trong tổ chức.
Một nhân viên từng được đánh giá bằng số lượng thao tác có thể dần được đánh giá bằng chất lượng hiểu biết và kết quả tạo ra.
Một người từng phải chờ được giao việc có thể bắt đầu phát hiện những cơ hội kinh doanh mới.
Một nhóm từng phụ thuộc vào bộ phận kỹ thuật có thể sử dụng những capability có sẵn để tạo công cụ riêng.
Tất nhiên, điều này không xảy ra một cách tự động.
Không phải cứ loại bỏ công việc thủ công là nhân viên sẽ lập tức trở thành chuyên gia.
Họ cần năng lực.
Động lực.
Cơ hội.
Sự hướng dẫn.
Và một hệ thống đánh giá, đãi ngộ phù hợp với loại giá trị mới mà họ được kỳ vọng tạo ra.
Nếu doanh nghiệp tự động hóa công việc cũ nhưng vẫn đánh giá nhân viên bằng những chỉ tiêu cũ, sự chuyển đổi có thể không diễn ra.
Nhân viên sẽ tiếp tục tối ưu những gì được đo lường.
Dù công nghệ đã cho phép họ làm những điều khác.
Automation changes what people can do. Organizational design determines what they actually choose to do.
Tự động hóa thay đổi những gì con người có khả năng thực hiện.
Thiết kế tổ chức quyết định họ thực sự lựa chọn thực hiện điều gì.
Đó là lý do automation không thể tách rời khỏi cách tổ chức phát triển con người.
Nếu muốn năng lực được giải phóng tạo ra giá trị mới, chúng ta phải thiết kế được không gian, động lực và trách nhiệm tương ứng.
16. Những người giỏi nhất nên được giao những vấn đề chưa được hiểu.
Trong một tổ chức chưa trưởng thành, người giỏi thường được giao nhiều việc hơn.
Họ xử lý nhanh.
Ít sai sót.
Hiểu công việc.
Và có thể giải quyết những tình huống mà người khác gặp khó khăn.
Kết quả là họ liên tục được giao những công việc quan trọng.
Ban đầu, điều đó có vẻ hợp lý.
Nhưng về lâu dài, nó có thể tạo ra một vấn đề lớn.
Người có năng lực cao nhất dành phần lớn thời gian để giải quyết những công việc mà tổ chức chưa chuyển hóa được thành quy trình đáng tin cậy.
Họ trở thành một thành phần không thể thiếu trong hoạt động thường ngày.
Và càng làm tốt, họ càng khó thoát khỏi vai trò đó.
Tôi nghĩ một hệ thống tốt phải cố gắng đảo ngược xu hướng này.
Những công việc đã hiểu rõ nên được chuẩn hóa ở mức phù hợp.
Những quyết định đã có nguyên lý rõ ràng nên được phân quyền hoặc tự động hóa.
Những ngoại lệ đã có cách xử lý ổn định nên được chuyển thành năng lực chung.
Và những người giỏi nhất nên dành ngày càng nhiều thời gian cho những vấn đề mà tổ chức chưa biết cách giải quyết.
Không phải vì họ quan trọng hơn những người khác.
Mà vì đó là nơi năng lực đặc biệt của họ có thể tạo ra giá trị lớn nhất.
Một người có khả năng xây dựng mối quan hệ khách hàng xuất sắc không nên dành cả ngày để nhập dữ liệu.
Một người có khả năng thiết kế quy trình tốt không nên phải trực tiếp kiểm tra cùng một loại lỗi mỗi ngày.
Một người có khả năng phát hiện cơ hội thị trường không nên bị mắc kẹt trong việc xử lý những thủ tục đã có thể chuẩn hóa.
Và một người có khả năng tạo ra abstraction mới không nên dành phần lớn thời gian để thực hiện những abstraction cũ.
Tôi muốn tổ chức có khả năng liên tục dịch chuyển công việc.
Những vấn đề chưa hiểu được đưa đến người có khả năng giải quyết.
Khi đã hiểu, chúng được xem xét để chuyển thành cơ chế.
Khi cơ chế đủ đáng tin cậy, công việc không còn phụ thuộc vào người ban đầu.
Và người đó tiếp tục đối diện với những vấn đề mới.
Human intelligence should be allocated to uncertainty, not merely to workload.
Năng lực trí tuệ của con người nên được phân bổ theo mức độ không chắc chắn và giá trị của vấn đề.
Không chỉ theo số lượng công việc còn tồn đọng.
Tuy nhiên, tôi không nghĩ việc phân bổ đó phải tuyệt đối.
Một người giỏi vẫn cần tiếp xúc với hoạt động thực tế.
Nếu hoàn toàn tách khỏi công việc thường ngày, họ có thể mất đi nguồn thông tin quan trọng để hiểu hệ thống.
Nhưng tiếp xúc để học hỏi khác với việc phải tham gia vì tổ chức chưa thể hoạt động nếu thiếu họ.
Sự khác biệt ấy rất lớn.
Một người bước vào vận hành để phát hiện vấn đề.
Người khác bị kéo vào vận hành để giải quyết vấn đề.
Hai hành động có thể trông giống nhau.
Nhưng ý nghĩa tổ chức hoàn toàn khác.
17. Người thiết kế automation cũng phải biết khi nào nên dừng xây dựng.
Tôi muốn dành một phần cho chính những người giống mình.
Những người nhìn thấy một công việc lặp lại và lập tức nghĩ ra cách tự động hóa.
Những người có thể quan sát một quy trình, nhận diện cấu trúc rồi nhanh chóng tạo ra một công cụ.
Những người thấy một vấn đề nhỏ và cảm thấy khó chịu cho đến khi tìm được cách giải quyết nó bằng hệ thống.
Đây là một lợi thế.
Nhưng cũng có thể trở thành một dạng ám ảnh nghề nghiệp.
Bởi vì khi khả năng xây dựng công cụ trở nên quá mạnh, chúng ta có thể bắt đầu sử dụng nó cho những vấn đề không thực sự đáng giải quyết bằng công nghệ.
Một thao tác thủ công mất ba phút mỗi tháng.
Chúng ta muốn tự động hóa.
Một báo cáo chỉ cần xuất một lần mỗi quý.
Chúng ta muốn tạo dashboard realtime.
Một ngoại lệ cực kỳ hiếm.
Chúng ta muốn xây một rule engine.
Một công việc có thể được giải quyết bằng việc thay đổi một dòng chính sách.
Chúng ta muốn tạo thêm một microservice.
Tôi hiểu cảm giác ấy.
Một giải pháp kỹ thuật thanh lịch có sức hấp dẫn rất lớn.
Nhưng tôi nghĩ người thiết kế giỏi cần có một năng lực khó hơn khả năng xây dựng.
Khả năng quyết định không xây dựng.
Không phải mọi vấn đề đều cần phần mềm.
Không phải mọi công việc thủ công đều là lãng phí.
Không phải mọi ngoại lệ đều cần quy tắc.
Và không phải mọi sự phức tạp đều đáng được trừu tượng hóa thành một framework.
Đôi khi, giải pháp tốt nhất là loại bỏ công việc.
Đôi khi là thay đổi trách nhiệm.
Đôi khi là cung cấp thông tin tốt hơn.
Đôi khi là đào tạo.
Đôi khi là chấp nhận một chi phí thủ công nhỏ vì tự động hóa sẽ tạo ra chi phí bảo trì lớn hơn.
Và đôi khi, chúng ta cần để vấn đề tồn tại thêm một thời gian để hiểu rõ bản chất trước khi can thiệp.
Engineering maturity is not measured by how much we automate, but by how wisely we choose what deserves automation.
Trưởng thành trong kỹ thuật không chỉ là khả năng xây được nhiều thứ.
Mà là khả năng lựa chọn đúng những thứ đáng xây.
Một người có thể rất giỏi viết code.
Nhưng nếu họ liên tục tạo ra những công cụ không tạo giá trị tương xứng, kỹ năng ấy chưa chắc giúp doanh nghiệp phát triển.
Ngược lại, một thay đổi nhỏ, đúng thời điểm, có thể giải phóng một năng lực vận hành rất lớn.
Không cần AI.
Không cần distributed architecture.
Không cần microservices.
Và đôi khi thậm chí không cần thêm một dòng code.
Một tin khá buồn với những người thích lập trình.
Nhưng rất tốt cho doanh nghiệp.
Lời kết: Automate the Ordinary.
Tôi không muốn xây dựng một tổ chức mà con người phải liên tục thực hiện những công việc đã có thể được hệ thống hóa.
Nhưng tôi cũng không muốn xây dựng một tổ chức mà con người dần đánh mất khả năng hiểu và kiểm soát công việc vì đã giao mọi thứ cho máy.
Tôi muốn một sự phân chia hợp lý hơn.
Những thao tác lặp lại được xem xét để loại bỏ hoặc tự động hóa.
Những quyết định đã có logic đáng tin cậy được thực thi một cách nhất quán.
Những ràng buộc quan trọng được bảo vệ.
Những ngoại lệ được đưa đến người có đủ thông tin và quyền hạn.
Và những vấn đề mới được xem như cơ hội để tổ chức học hỏi.
Tôi không quan tâm automation có thể thay thế được bao nhiêu nhân viên.
Tôi quan tâm đến việc nó có thể giúp những nhân viên hiện tại tạo ra bao nhiêu giá trị mới.
Một người từng dành phần lớn thời gian xử lý đơn hàng có thể trở thành người phát triển khách hàng.
Một người từng phải nhập dữ liệu có thể chuyển sang kiểm tra chất lượng và cải thiện tri thức sản phẩm.
Một quản lý từng phải phê duyệt hàng chục yêu cầu có thể tập trung vào những quyết định quan trọng hơn.
Và một nhân viên có khả năng nhìn thấy cơ hội có thể được trao công cụ để tự xây dựng giải pháp của mình.
Không phải ai cũng sẽ phát triển theo cùng một hướng.
Không phải mọi công việc được tự động hóa đều có thể được thay thế bằng một công việc giá trị cao hơn ngay lập tức.
Những thay đổi đó cần thời gian, năng lực và cả những quyết định tổ chức khó khăn.
Nhưng tôi nghĩ đó là hướng đi đáng theo đuổi.
Automate the known. Empower the capable. Explore the unknown.
Tự động hóa những điều đã hiểu.
Trao quyền cho những người có năng lực.
Và dành trí tuệ cho những điều chưa biết.
Tôi thích nghĩ về tổ chức như một hệ thống liên tục mở rộng ranh giới hiểu biết của mình.
Một vấn đề mới xuất hiện.
Con người quan sát.
Phân tích.
Thử nghiệm.
Và tìm ra một cách xử lý đáng tin cậy.
Khi cách xử lý đủ rõ, chúng ta xem xét chuyển nó thành một phần năng lực chung.
Có thể là một quy trình.
Một quy tắc.
Một cơ chế phân quyền.
Một công cụ.
Hoặc một automation.
Sau đó, con người tiếp tục đối diện với những vấn đề mới.
Vòng lặp đó không có điểm kết thúc cố định.
Bởi vì thị trường không ngừng thay đổi.
Khách hàng không ngừng có nhu cầu mới.
Và những giới hạn của doanh nghiệp cũng thay đổi khi quy mô tăng lên.
Điều từng là một vấn đề khó có thể trở thành công việc bình thường.
Điều từng là ngoại lệ có thể trở thành quy trình tiêu chuẩn.
Và điều từng đòi hỏi một người rất giỏi có thể dần trở thành năng lực mà nhiều người sử dụng được.
Tôi nghĩ đây là một trong những dạng tiến bộ đáng giá nhất của tổ chức.
Không phải con người ngày càng ít quan trọng vì máy móc làm được nhiều việc hơn. Mà con người có cơ hội trở nên quan trọng theo những cách mới.
Nhưng để điều đó xảy ra, chúng ta không thể chỉ xây dựng phần mềm.
Chúng ta phải xây dựng cả khả năng học hỏi.
Khả năng phát triển năng lực.
Khả năng phân quyền.
Và những cơ hội để con người thực sự thử nghiệm, đưa ra quyết định và trưởng thành.
Nếu không, automation có thể tạo ra một tổ chức rất hiệu quả trong việc thực hiện những điều đã biết.
Nhưng bất lực trước những điều chưa biết.
Một hệ thống như vậy có thể vận hành rất đẹp khi mọi điều kiện đúng như dự kiến.
Mọi thao tác tự động.
Mọi trạng thái chính xác.
Mọi dashboard đều xanh.
Mọi KPI đều đạt.
Cho đến khi thị trường thay đổi.
Một nhóm khách hàng mới xuất hiện.
Một loại nhu cầu chưa được mô hình hóa.
Một ràng buộc kinh doanh không còn phù hợp.
Và một vấn đề xuất hiện mà hệ thống chưa có câu trả lời.
Lúc đó, chúng ta nhìn quanh.
Những nhân viên từng có khả năng phán đoán đã quen với việc làm theo đề xuất.
Những quản lý từng hiểu sâu quy trình giờ chỉ quen theo dõi dashboard.
Những người có kinh nghiệm đã dành quá lâu để sử dụng hệ thống mà không còn trực tiếp phân tích bản chất công việc.
Và cả tổ chức bắt đầu chờ phần mềm được cập nhật.
Chúng ta đã tự động hóa rất thành công.
Đến mức vô tình tự động hóa luôn cả thói quen không cần suy nghĩ.
A perfectly automated organization can still be a profoundly unintelligent organization.
Một tổ chức được tự động hóa hoàn hảo vẫn có thể là một tổ chức thiếu năng lực tư duy nghiêm trọng.
Tôi không muốn điều đó.
Tôi muốn automation tạo ra không gian cho trí tuệ con người.
Không phải thay thế nhu cầu sử dụng trí tuệ ấy.
Tôi muốn những người bình thường có thể thực hiện công việc tốt hơn nhờ những hệ thống đáng tin cậy.
Những người có năng lực có thể phát triển xa hơn nhờ được giải phóng khỏi những thao tác không cần thiết.
Và những người xuất sắc có thể liên tục đẩy giới hạn hiểu biết và năng lực của tổ chức về phía trước.
Đó là lý do tôi không xem tự động hóa là mục tiêu cuối cùng.
Nó là một phương tiện.
Một dạng đòn bẩy.
Và cũng giống như mọi đòn bẩy, giá trị của nó phụ thuộc vào nơi chúng ta đặt điểm tựa và mục tiêu chúng ta đang cố gắng đạt được.
Nếu đặt sai chỗ, nó có thể khuếch đại những sai lầm.
Nếu đặt đúng chỗ, nó có thể tạo ra những năng lực mà trước đây tổ chức không thể đạt được.
Nhưng đến đây, một câu hỏi mới xuất hiện.
Giả sử chúng ta đã thiết kế được abstraction tốt.
Đã xây dựng guardrails phù hợp.
Đã tạo ra Business Operating System.
Đã tự động hóa những hoạt động lặp lại có giá trị.
Và đã giải phóng một phần lớn năng lực con người khỏi những công việc thường ngày.
Điều gì bảo đảm những con người ấy sẽ thực sự phát triển để sử dụng năng lực đó?
Bởi vì một hệ thống tốt có thể giúp một người bình thường làm việc hiệu quả hơn.
Nhưng nó không tự động biến người đó thành một người có khả năng sáng tạo, phán đoán và chịu trách nhiệm ở cấp độ cao hơn.
Một tổ chức vẫn cần phát triển những con người có khả năng sở hữu công việc.
Phát triển chuyên môn.
Dẫn dắt người khác.
Và dần dần có thể chịu trách nhiệm cho những đơn vị kinh doanh lớn hơn.
Đây là lúc vấn đề không còn chủ yếu nằm ở Software Engineering.
Nó bước sang một lĩnh vực khó hơn.
Organizational Engineering.
Chúng ta không còn chỉ thiết kế cách phần mềm hoạt động.
Chúng ta phải thiết kế những điều kiện để con người có thể phát triển.
Và có lẽ đây mới là thử thách thực sự.
Bởi vì một phần mềm có thể được sửa khi phát hiện sai lầm.
Một quy tắc có thể được thay đổi.
Một automation có thể được tắt.
Một database có thể được tái cấu trúc.
Nhưng con người không có nút Deploy.
Không có Rollback.
Không có một bộ Unit Test nào bảo đảm họ sẽ phản ứng đúng trước mọi tình huống.
Và chắc chắn không có câu lệnh nào giúp một người bình thường thức dậy vào sáng thứ Hai với năng lực tư duy của một Software Architect.
Thật bất tiện.
Đặc biệt với một thằng từng quen giải quyết vấn đề bằng code.
Nhưng đó cũng là lý do công việc này đáng để theo đuổi.
The next frontier is not automating more work. It is engineering an organization where more people can do work that actually matters.
Không phải tiếp tục tự động hóa nhiều hơn bằng mọi giá.
Mà là xây dựng một tổ chức nơi ngày càng nhiều người có khả năng tạo ra những giá trị thực sự quan trọng.
Và nếu cuối cùng tôi nhận ra mình đã dành nhiều năm viết phần mềm để nhân viên không cần suy nghĩ, rồi lại phàn nàn rằng nhân viên không biết suy nghĩ...
Thì có lẽ vấn đề không nằm ở họ.
Có lẽ tôi đã vô tình thiết kế đúng cái thứ mà mình đang ghét.
Một cỗ máy thực thi hoàn hảo.
Với những con người chỉ biết chờ chỉ dẫn.
Fuck.
Congratulations. You've automated the work.
And accidentally outsourced the thinking.
END OF PART II — DESIGNING ORDER
Chúng ta đã đi từ khả năng nhận diện cấu trúc đến việc xây dựng abstraction, thiết kế guardrails, hình thành Business Operating System và tự động hóa những hoạt động đã được hiểu rõ.
Nhưng kiến trúc không tự tạo ra một tổ chức xuất sắc.
Cuối cùng, mọi hệ thống đều phải được vận hành, phát triển và cải thiện bởi những con người thực sự.
Và đó là nơi phần khó nhất bắt đầu.
NEXT — PART III: ENGINEERING PEOPLE & SCALE
CHAPTER 09 — ORDINARY PEOPLE, EXTRAORDINARY SYSTEMS
Tại sao một tổ chức xuất sắc không thể được xây dựng trên giả định rằng tất cả nhân viên đều phải xuất sắc? Và làm thế nào để nâng cao năng lực tối thiểu mà không giới hạn tiềm năng tối đa?
The Architect of Chaos — Ông Chú Hay Chửi