Có một câu nói mà tôi nghe khá thường xuyên trong doanh nghiệp.
"Anh ơi, cái này chỉ mất năm phút thôi."
Một đơn hàng cần điều chỉnh giá.
Năm phút.
Một khách hàng cần được hỗ trợ phí vận chuyển.
Năm phút.
Một giao dịch cần xác nhận công nợ.
Năm phút.
Một nhân viên gặp tình huống chưa có trong quy trình, cần quản lý quyết định.
Cũng năm phút.
Thật tuyệt vời.
Chúng ta đang sở hữu một doanh nghiệp mà mọi vấn đề đều có thể giải quyết trong năm phút.
Chỉ có một điều hơi bất tiện.
Mỗi ngày có khoảng một trăm vấn đề như vậy.
Và năm phút của người này thường cần thêm năm phút của một người khác.
Đôi khi cả ba người.
Đến cuối ngày, mọi người đều rất bận.
Quản lý làm việc liên tục.
Nhân viên cố gắng hết sức.
Điện thoại reo không ngừng.
Tin nhắn được xử lý với tốc độ đáng kinh ngạc.
Nhưng nếu hỏi hôm nay tổ chức đã cải thiện được điều gì để ngày mai vận hành tốt hơn, câu trả lời thường khá khiêm tốn.
Chúng ta đã giải quyết rất nhiều vấn đề.
Và chuẩn bị sẵn sàng để ngày mai tiếp tục giải quyết chúng.
Một mô hình kinh doanh có tính bền vững đáng kinh ngạc.
Tiếc là bền vững cho vấn đề, không phải cho doanh nghiệp.
01. Ngoại lệ là gì, và tại sao chúng nguy hiểm?
Trong một hệ thống vận hành, chúng ta thường có một luồng xử lý tiêu chuẩn.
Khách đặt hàng.
Hệ thống xác nhận.
Kho chuẩn bị.
Đơn vị vận chuyển giao hàng.
Giao dịch hoàn tất.
Nếu mọi điều kiện đều đúng như dự kiến, công việc diễn ra tương đối trơn tru.
Nhưng thực tế hiếm khi đơn giản như vậy.
Khách muốn thay đổi địa chỉ sau khi đơn đã được xử lý.
Một mặt hàng hết tồn kho.
Một đơn hàng không đạt ngưỡng giao hàng miễn phí.
Một khách hàng quan trọng cần chính sách khác.
Một giao dịch bị chặn vì công nợ.
Một yêu cầu xuất hiện mà hệ thống chưa biết phải xử lý thế nào.
Chúng ta gọi những tình huống nằm ngoài luồng xử lý tiêu chuẩn là ngoại lệ.
Và tôi muốn làm rõ một điều ngay từ đầu.
Ngoại lệ không nhất thiết là lỗi.
Một khách hàng lớn yêu cầu lịch giao đặc biệt có thể là cơ hội kinh doanh.
Một đơn hàng có cấu trúc khác thường có thể đại diện cho một phân khúc thị trường mới.
Một đề xuất vượt khỏi quy trình có thể là dấu hiệu cho thấy cách tổ chức hiện tại đã không còn phù hợp.
Vì vậy, tôi không xem mọi ngoại lệ là vấn đề cần loại bỏ.
Điều tôi quan tâm là cách hệ thống phản ứng với chúng.
Một ngoại lệ được nhận diện, đánh giá và xử lý có kiểm soát là một phần bình thường của kinh doanh.
Nhưng một ngoại lệ lặp lại hàng trăm lần, lần nào cũng cần con người tự tìm cách giải quyết, lại là chuyện hoàn toàn khác.
Một ngoại lệ lặp lại đủ thường xuyên không còn thực sự là ngoại lệ. Nó là một quy trình chưa được thừa nhận.
Và những quy trình không được thừa nhận thường có một đặc điểm chung.
Chúng rất đắt.
Chỉ là không ai biết chính xác đắt bao nhiêu.
02. Năm phút không bao giờ thực sự chỉ là năm phút.
Hãy quay lại với một yêu cầu hỗ trợ phí vận chuyển.
Nhân viên bán hàng nhận được yêu cầu từ khách.
Đơn hàng không đủ điều kiện miễn phí giao hàng, nhưng nhân viên cho rằng cần hỗ trợ vì khách có tiềm năng mua thường xuyên.
Nhân viên nhắn cho quản lý.
Quản lý đang xử lý một vấn đề khác.
Mười phút sau, quản lý đọc tin nhắn.
Thông tin chưa đủ.
Quản lý hỏi lại về lịch sử mua hàng và lợi nhuận dự kiến.
Nhân viên mở dữ liệu, kiểm tra, gửi bổ sung.
Quản lý đồng ý.
Nhân viên quay lại đơn hàng và hoàn tất.
Tổng thời gian thực sự thao tác có thể chỉ khoảng năm đến mười phút.
Nhưng giao dịch đã chờ gần nửa giờ.
Hai người bị gián đoạn công việc.
Một quyết định phải đi qua nhiều lượt trao đổi.
Và khách hàng có thể đã phải chờ trong suốt quá trình đó.
Nếu chỉ tính thời gian quản lý bấm nút phê duyệt, chi phí gần như bằng không.
Nếu tính toàn bộ hoạt động bị ảnh hưởng, bức tranh hoàn toàn khác.
Tôi thường nhìn một ngoại lệ qua bốn loại chi phí.
Handling Cost — Chi phí xử lý trực tiếp.
Thời gian con người thực sự dành để kiểm tra, trao đổi và giải quyết tình huống.
Coordination Cost — Chi phí phối hợp.
Số lần chuyển giao thông tin, chờ phản hồi, xác minh và đồng bộ giữa các bộ phận.
Disruption Cost — Chi phí gián đoạn.
Những công việc đang thực hiện bị ngắt quãng, khiến người xử lý phải tái lập ngữ cảnh trước khi tiếp tục.
Opportunity Cost — Chi phí cơ hội.
Những việc có giá trị cao hơn đã không được thực hiện vì nguồn lực bị tiêu hao vào ngoại lệ.
Hai loại đầu tương đối dễ đo lường.
Hai loại sau nguy hiểm hơn.
Bởi vì chúng thường không xuất hiện dưới dạng một khoản chi cụ thể.
Không có hóa đơn nào ghi:
"Chi phí gián đoạn tư duy của trưởng bộ phận: 47 phút."
Không có dòng nào trên báo cáo tài chính ghi:
"Ý tưởng cải tiến hệ thống chưa được triển khai vì hôm nay phải giải quyết 26 yêu cầu ngoại lệ."
Nhưng việc không có một dòng chi phí không có nghĩa là chi phí đó không tồn tại.
Nó chỉ có nghĩa chúng ta chưa đo được.
Và những thứ chưa đo được thường có cơ hội rất tốt để tồn tại lâu dài.
03. Sự đắt đỏ của một lần mất tập trung.
Hãy tưởng tượng một người đang thiết kế lại hệ thống phân bổ đơn hàng.
Họ phải phân tích lịch sử giao dịch, công suất vận hành, đặc điểm khách hàng, ràng buộc vận chuyển và những ngoại lệ đang tồn tại.
Đây không phải một công việc chỉ cần mở laptop và bắt đầu gõ.
Người thực hiện phải xây dựng một mô hình trong đầu.
Những dữ liệu tưởng chừng không liên quan được kết nối.
Các giả định được kiểm tra.
Một số phương án bị loại bỏ.
Một cấu trúc mới dần hình thành.
Và đúng lúc đó:
"Anh ơi, cái này chỉ mất năm phút."
Người đó dừng công việc.
Xem yêu cầu.
Đưa ra quyết định.
Quay lại màn hình.
Nhưng mô hình tư duy trước đó không nhất thiết còn nguyên vẹn.
Họ phải nhớ mình đang phân tích đến đâu.
Tại sao loại bỏ phương án thứ hai.
Giả định nào chưa được kiểm tra.
Và chi tiết nào vừa xuất hiện trước khi bị ngắt quãng.
Năm phút xử lý ngoại lệ có thể kéo theo một khoảng thời gian đáng kể để quay lại trạng thái tập trung ban đầu.
Tôi không cho rằng có một con số cố định áp dụng cho mọi người và mọi công việc.
Nhưng tôi tin một điều:
Thời gian bị gián đoạn và thời gian cần thiết để phục hồi khả năng tư duy không phải lúc nào cũng bằng nhau.
Đặc biệt với những công việc đòi hỏi abstraction, thiết kế kiến trúc và giải quyết vấn đề mới.
Đây là lý do tôi không đánh giá năng suất chỉ bằng số giờ làm việc.
Một người có thể làm việc mười hai giờ mỗi ngày nhưng không có nổi hai giờ suy nghĩ liên tục.
Một tổ chức có thể sở hữu rất nhiều người thông minh nhưng không cho họ đủ không gian để sử dụng trí thông minh đó.
Và một founder có thể dành cả ngày giải quyết công việc, để rồi nhận ra mình chưa thực sự xây dựng được điều gì mới.
Đây không phải câu chuyện về sự lười biếng.
Đây là vấn đề phân bổ tài nguyên nhận thức.
Chúng ta đang sử dụng những bộ não có khả năng giải quyết vấn đề phức tạp để liên tục xử lý những quyết định mà một quy tắc đơn giản có thể thực hiện.
Điều đó không sai trong mọi trường hợp.
Nhưng nếu nó trở thành cách vận hành mặc định, tổ chức đang trả một cái giá rất lớn.
04. Tại sao ngoại lệ tăng nhanh hơn quy mô doanh nghiệp?
Khi doanh nghiệp còn nhỏ, ngoại lệ thường không phải vấn đề lớn.
Founder có thể trực tiếp xử lý hầu hết tình huống.
Nhân viên chỉ cần quay sang hỏi.
Các bộ phận ngồi gần nhau.
Thông tin được trao đổi nhanh.
Một vấn đề phát sinh có thể được giải quyết bằng một cuộc trò chuyện ngắn.
Mọi thứ khá hiệu quả.
Rồi doanh nghiệp phát triển.
Số khách hàng tăng.
Số sản phẩm tăng.
Nhân sự tăng.
Địa điểm vận hành tăng.
Các bộ phận bắt đầu chuyên môn hóa.
Và số lượng điểm tương tác giữa các thành phần cũng tăng lên.
Một yêu cầu đặc biệt không còn chỉ liên quan đến người bán hàng.
Nó có thể ảnh hưởng đến chính sách giá, công nợ, tồn kho, kế hoạch giao hàng và chăm sóc khách hàng.
Một ngoại lệ đi qua càng nhiều bộ phận, càng có nhiều cơ hội phát sinh thêm ngoại lệ khác.
Đây là điểm rất đáng chú ý.
Độ phức tạp của một tổ chức không nhất thiết tăng tuyến tính theo số lượng nhân viên.
Mười người không đơn giản chỉ phức tạp gấp đôi năm người.
Bởi vì ngoài số lượng cá nhân, chúng ta còn phải xem xét số lượng mối quan hệ, phụ thuộc và quyết định cần được phối hợp.
Tất nhiên, không phải mọi người đều cần tương tác trực tiếp với nhau. Một kiến trúc tổ chức tốt có thể giới hạn các phụ thuộc đó.
Nhưng nếu không chủ động thiết kế, số điểm cần phối hợp có thể phát triển nhanh hơn năng lực quản lý.
Một quy trình từng hoạt động rất tốt ở quy mô nhỏ bắt đầu bộc lộ những điểm yếu chưa từng được nhìn thấy.
Không hẳn vì nó được thiết kế sai ngay từ đầu.
Mà vì các giả định khiến nó hoạt động trước đây đã không còn đúng.
Founder không còn đủ thời gian để kiểm tra mọi quyết định.
Quản lý không thể ghi nhớ tất cả khách hàng.
Thông tin không thể tiếp tục tồn tại trong những cuộc trò chuyện riêng.
Và việc "cứ hỏi anh khi có vấn đề" không còn là một giải pháp vận hành khả thi.
Nó trở thành một kiến trúc tập trung với khả năng mở rộng cực kỳ hạn chế.
Trong Software Engineering, chúng ta sẽ khá lo lắng nếu toàn bộ hệ thống phải phụ thuộc vào một thành phần duy nhất.
Trong kinh doanh, đôi khi chúng ta lại gọi thành phần đó là người lãnh đạo tận tâm.
Nghe dễ chịu hơn nhiều.
Cho đến khi hệ thống bắt đầu quá tải.
05. Ngoại lệ không chỉ tiêu tốn thời gian. Chúng tạo ra hàng đợi.
Có một khía cạnh thường bị bỏ qua khi đánh giá chi phí vận hành.
Đó là sự khác biệt giữa thời gian xử lý và thời gian chờ đợi.
Giả sử một quản lý có thể xử lý một yêu cầu phê duyệt trong ba phút.
Về lý thuyết, một giờ có thể xử lý hai mươi yêu cầu.
Nghe có vẻ rất tốt.
Nhưng điều gì xảy ra nếu mười yêu cầu xuất hiện gần như cùng lúc?
Yêu cầu đầu tiên được xử lý ngay.
Yêu cầu thứ hai phải chờ.
Yêu cầu thứ ba phải chờ lâu hơn.
Và nếu trong lúc đó quản lý còn phải tham gia họp, xử lý khiếu nại hoặc giải quyết một tình huống khẩn cấp khác, hàng đợi tiếp tục kéo dài.
Đây là một vấn đề quen thuộc trong Queueing Theory.
Khi mức sử dụng công suất tiến sát giới hạn, thời gian chờ trung bình có thể tăng rất mạnh, đặc biệt khi yêu cầu đến không đều và thời gian xử lý biến động.
Một bộ phận hoạt động ở mức 95% công suất không nhất thiết hiệu quả hơn bộ phận hoạt động ở mức 75%.
Nó có thể đang sống trong trạng thái chỉ cần thêm một biến động nhỏ là toàn bộ lịch xử lý bị xáo trộn.
Trong các hệ thống như vậy, công suất dự phòng không nhất thiết là lãng phí.
Đôi khi nó là điều kiện để duy trì độ tin cậy.
Điều thú vị là các ngoại lệ thường có tính biến động cao.
Chúng không xuất hiện theo lịch.
Không có độ phức tạp cố định.
Không thể dự đoán chính xác thời gian xử lý.
Và thường phải cạnh tranh tài nguyên với những công việc bình thường.
Nếu tất cả cùng đi qua một người có quyền quyết định, chúng ta vừa tạo ra một nút thắt cổ chai.
Một tổ chức có thể đủ năng lực xử lý tổng khối lượng công việc, nhưng vẫn thất bại vì không đủ năng lực xử lý những thời điểm công việc tập trung.
Vấn đề này đặc biệt rõ ở những doanh nghiệp có hoạt động giao nhận, bán lẻ, dịch vụ hoặc xử lý giao dịch theo thời gian thực.
Khách hàng không quan tâm rằng yêu cầu của họ chỉ cần ba phút để được phê duyệt.
Họ quan tâm tại sao mình phải đợi bốn mươi phút.
Và nếu một đơn hàng phải chờ quá lâu, đôi khi chi phí không còn là bốn mươi phút nữa.
Nó là một khách hàng không quay lại.
06. Khi doanh nghiệp bắt đầu phát triển những quy trình ngầm.
Có một giai đoạn khá thú vị trong quá trình trưởng thành của tổ chức.
Đó là khi quy trình chính thức không còn đáp ứng đủ nhu cầu vận hành, nhưng tổ chức chưa kịp thiết kế lại.
Con người sẽ tự tìm cách thích nghi.
Một nhân viên tạo file Excel riêng để theo dõi những thông tin hệ thống chưa hỗ trợ.
Một nhóm lập chat riêng để xử lý những đơn hàng đặc biệt.
Một quản lý duy trì danh sách ngoại lệ trong điện thoại cá nhân.
Một bộ phận sử dụng mã quy ước không xuất hiện trong bất kỳ tài liệu chính thức nào.
Một nhân viên lâu năm biết phải gọi ai để một vấn đề được giải quyết nhanh hơn.
Những cơ chế này thường hình thành vì nhu cầu thực tế.
Và đôi khi chúng rất thông minh.
Chúng cho thấy con người có khả năng sáng tạo để vượt qua những giới hạn của công cụ.
Tôi không xem chúng là điều xấu mặc định.
Nhưng chúng đặt ra một câu hỏi:
Tại sao hệ thống chính thức không biết những điều mà hệ thống không chính thức đang biết?
Đây là nơi các quy trình ngầm bắt đầu tạo ra rủi ro.
Thông tin bị phân mảnh.
Quyết định thiếu khả năng truy vết.
Người mới không biết những quy tắc bất thành văn.
Một cá nhân nghỉ việc có thể mang theo cả một phần tri thức vận hành mà tổ chức chưa từng ghi nhận.
Và hai bộ phận có thể sử dụng hai phiên bản sự thật hoàn toàn khác nhau.
Càng có nhiều hệ thống ngầm, tổ chức càng khó xác định đâu là nguồn dữ liệu đáng tin cậy.
Một khách hàng có thể có trạng thái khác nhau trong CRM, trong file Excel và trong trí nhớ của nhân viên phụ trách.
Một quy định có thể tồn tại trên giấy, nhưng cách thực thi thực tế lại phụ thuộc vào người đang trực ca.
Một quyết định có thể được đưa ra đúng, nhưng không ai biết nó dựa trên những thông tin nào.
Chúng ta đang tạo ra một doanh nghiệp có hai kiến trúc.
Một kiến trúc chính thức được trình bày trong tài liệu.
Và một kiến trúc thực tế tồn tại trong thói quen của con người.
Điều nguy hiểm không phải là hai kiến trúc đó khác nhau.
Điều nguy hiểm là người thiết kế tổ chức không biết chúng đang khác nhau ở đâu.
07. Exception Debt — Khoản nợ được trả bằng năng lực vận hành.
Tôi thích sử dụng khái niệm Technical Debt trong phần mềm để suy nghĩ về một hiện tượng tương tự trong kinh doanh.
Trong quá trình phát triển, đôi khi chúng ta chấp nhận một giải pháp chưa tối ưu để đáp ứng nhu cầu trước mắt.
Điều đó có thể hoàn toàn hợp lý.
Nhưng nếu giải pháp tạm thời trở thành cấu trúc lâu dài, việc thay đổi hệ thống về sau có thể ngày càng khó khăn và tốn kém.
Tôi gọi một hiện tượng tương tự trong tổ chức là Exception Debt.
Khoản nợ ngoại lệ.
Nó hình thành khi doanh nghiệp liên tục chấp nhận xử lý thủ công những tình huống lặp lại mà không đầu tư đủ để hiểu và cải thiện nguyên nhân.
Một ngoại lệ được giải quyết.
Công việc tiếp tục.
Không có sự cố nghiêm trọng.
Không ai cảm thấy cần phải thay đổi.
Ngày hôm sau, ngoại lệ xuất hiện lần nữa.
Và quá trình lặp lại.
Mỗi lần xử lý, tổ chức đang trả một khoản chi phí nhỏ để duy trì cấu trúc hiện tại.
Nếu không có lý do kinh tế hợp lý để thay đổi, khoản chi đó có thể chấp nhận được.
Nhưng khi tần suất tăng, số lượng người liên quan tăng, hoặc chi phí cơ hội trở nên đáng kể, quyết định không cải tiến bắt đầu trở nên đắt đỏ.
Điều tôi quan tâm không chỉ là tổng số tiền phải trả.
Mà là khoản nợ đó đang chiếm dụng năng lực của ai.
Một ngoại lệ cần năm phút của nhân viên mới có thể không nghiêm trọng.
Nhưng một ngoại lệ cần năm phút của người duy nhất có khả năng thiết kế kiến trúc kinh doanh có thể rất đắt.
Không phải vì mức lương của người đó cao.
Mà vì năm phút ấy có thể khiến một công việc tạo ra giá trị lâu dài bị gián đoạn.
Đây là một khác biệt quan trọng.
Chi phí lao động phản ánh giá của thời gian.
Chi phí cơ hội phản ánh giá trị của phương án mà chúng ta đã từ bỏ khi sử dụng thời gian đó.
Hai thứ không giống nhau.
Một founder có thể tiết kiệm được vài triệu đồng mỗi tháng bằng cách tự xử lý một số công việc vận hành.
Nhưng nếu hoạt động đó khiến một dự án cải tiến quan trọng bị trì hoãn, khoản tiết kiệm có thể trở nên vô nghĩa.
Tôi không cho rằng founder nên tránh mọi công việc vận hành.
Trực tiếp tham gia thực tế đôi khi là cách tốt nhất để phát hiện những điều mà báo cáo không cho thấy.
Nhưng tham gia để học hỏi khác với trở thành điều kiện bắt buộc để công việc tiếp tục.
Nếu một người liên tục phải giải quyết những ngoại lệ đã quen thuộc, người đó không còn quan sát hệ thống nữa. Người đó đã trở thành một phần của cơ chế xử lý ngoại lệ.
Và có thể chính là phần đắt nhất.
08. Nhưng nếu loại bỏ mọi ngoại lệ, chúng ta sẽ giết chết sự tiến hóa.
Đến đây, có thể một người yêu thích tự động hóa sẽ đề xuất:
Vậy hãy chuẩn hóa mọi tình huống.
Thiết kế quy tắc cho tất cả trường hợp.
Không cho phép nhân viên xử lý ngoài quy trình.
Mọi thứ phải có trong hệ thống.
Tôi hiểu sức hấp dẫn của ý tưởng đó.
Và tôi cũng nghĩ nó có thể tạo ra một tổ chức cực kỳ tồi tệ.
Bởi vì thị trường không có nghĩa vụ phải vận hành theo những giả định mà chúng ta đã đưa vào phần mềm.
Khách hàng thay đổi.
Nhu cầu thay đổi.
Sản phẩm thay đổi.
Đối thủ thay đổi.
Những cơ hội kinh doanh mới thường xuất hiện dưới hình thức một yêu cầu mà hệ thống hiện tại chưa biết cách xử lý.
Nếu mọi ngoại lệ đều bị chặn, tổ chức sẽ ngày càng ổn định.
Ổn định đến mức không thể thích nghi.
Tôi thích phân biệt bốn nhóm ngoại lệ.
Nhóm thứ nhất: Known & Repetitive.
Những tình huống đã hiểu rõ, thường xuyên lặp lại và có cách xử lý tương đối ổn định.
Đây là ứng viên tốt cho việc chuẩn hóa hoặc tự động hóa.
Nhóm thứ hai: Known but Judgment-Dependent.
Những tình huống đã được nhận diện nhưng vẫn cần con người đánh giá tùy theo ngữ cảnh.
Chúng cần chính sách, dữ liệu hỗ trợ và quyền hạn quyết định rõ ràng.
Không nhất thiết cần một quy tắc cứng cho mọi trường hợp.
Nhóm thứ ba: Unknown but Valuable.
Những tình huống mới có khả năng đại diện cho một nhu cầu, cơ hội hoặc quy luật chưa được khám phá.
Đây là nơi tôi muốn những người có năng lực tốt nhất của tổ chức tập trung.
Nhóm thứ tư: Noise.
Những sự cố hiếm, tác động thấp hoặc biến động ngẫu nhiên mà việc xây dựng một cơ chế riêng không tạo ra giá trị tương xứng.
Đôi khi giải pháp tốt nhất là xử lý chúng và tiếp tục công việc.
Không phải mọi thứ đều cần trở thành một dự án phần mềm.
Không phải mọi ngoại lệ đều cần một quy trình mười bảy bước.
Và chắc chắn không phải mọi ý tưởng xuất hiện trong cuộc họp đều xứng đáng có một dashboard.
Tôi nói điều này với tư cách một người thích viết phần mềm.
Một thú vui khá nguy hiểm khi kết hợp với quyền quyết định ngân sách.
Điểm quan trọng không phải loại bỏ ngoại lệ. Mà là phân loại đúng thứ nào nên được hệ thống hóa, thứ nào cần con người phán đoán, và thứ nào đáng được khám phá.
Đây mới là nền tảng của một tổ chức vừa ổn định, vừa có khả năng thích nghi.
09. Biến ngoại lệ thành nguyên liệu cho kiến trúc.
Nếu được thiết kế đúng, một doanh nghiệp không chỉ xử lý ngoại lệ.
Nó học từ chúng.
Hãy lấy ví dụ về chính sách hỗ trợ phí vận chuyển.
Ban đầu, một số tình huống cần quản lý phê duyệt thủ công.
Sau một thời gian, dữ liệu có thể cho thấy những mẫu hình nhất định.
Có những đơn hàng được hỗ trợ vì khách mua thường xuyên.
Có những trường hợp do sai sót trong quy trình giao nhận.
Có những khách hàng mới cần một chính sách thử nghiệm hợp lý.
Và có những yêu cầu thực sự không mang lại lợi ích kinh tế.
Thay vì xử lý tất cả bằng một câu hỏi chung chung: "Có hỗ trợ được không anh?", hệ thống có thể tiến hóa.
Bước đầu tiên là ghi nhận lý do ngoại lệ một cách có cấu trúc.
Tiếp theo là phân tích tần suất, chi phí và kết quả kinh doanh.
Sau đó, xác định những tình huống có đủ dữ liệu để chuyển thành quy tắc.
Một số trường hợp có thể được xử lý tự động.
Một số được giao quyền cho nhân viên trong những giới hạn cụ thể.
Một số tiếp tục cần phê duyệt.
Và một số nên bị từ chối.
Quan trọng hơn, chúng ta phải tiếp tục quan sát kết quả.
Một chính sách hỗ trợ được sử dụng thường xuyên không tự động có nghĩa đó là chính sách tốt.
Một ngoại lệ ít xuất hiện không tự động có nghĩa nó không quan trọng.
Nếu chính sách mới giúp giảm thời gian xử lý nhưng khiến lợi nhuận giảm mạnh, chúng ta chưa chắc đã cải tiến được gì.
Nếu một quy tắc chặn những giao dịch có tiềm năng cao chỉ vì chúng không giống các giao dịch trong quá khứ, chúng ta có thể đang làm tổn hại khả năng phát triển của doanh nghiệp.
Vì vậy, mục tiêu không phải là tối đa hóa số lượng ngoại lệ được tự động hóa.
Mục tiêu là nâng cao chất lượng quyết định với chi phí vận hành hợp lý.
Tôi gọi đây là một vòng học hỏi:
Observe → Classify → Abstract → Design → Validate → Evolve.
Quan sát.
Phân loại.
Tìm cấu trúc chung.
Thiết kế cơ chế.
Kiểm chứng kết quả.
Và tiếp tục tiến hóa.
Một ngoại lệ được xử lý có thể giúp một giao dịch hoàn tất.
Một ngoại lệ được hiểu đúng có thể giúp hàng nghìn giao dịch trong tương lai được xử lý tốt hơn.
Đó là sự khác biệt giữa giải quyết công việc và phát triển năng lực tổ chức.
10. Đừng đo sự bận rộn. Hãy đo khả năng hấp thụ độ phức tạp.
Tôi nghĩ có một câu hỏi mà nhiều doanh nghiệp nên đặt ra thường xuyên hơn.
Nếu khối lượng kinh doanh tăng gấp đôi, chúng ta cần tăng bao nhiêu nguồn lực để duy trì chất lượng vận hành?
Nếu doanh thu tăng 50%, bộ phận xử lý đơn có phải tăng nhân sự tương ứng?
Nếu số khách hàng tăng gấp ba, số lượng yêu cầu cần quản lý can thiệp có tăng gấp ba?
Nếu số sản phẩm tăng gấp năm, độ phức tạp của hoạt động bán hàng có tăng theo cùng tỷ lệ?
Không có một đáp án đúng cho mọi doanh nghiệp.
Một số hoạt động có tính chất lao động trực tiếp và buộc phải tăng nguồn lực khi sản lượng tăng.
Một kho hàng không thể tự nhiên xử lý gấp đôi lượng hàng chỉ nhờ một dashboard đẹp.
Một tài xế không thể giao hàng đồng thời tại hai địa điểm cách nhau mười cây số chỉ vì chúng ta vừa triển khai AI.
Thực tế vật lý không quan tâm đến sự lạc quan của người thiết kế phần mềm.
Nhưng có những loại công việc không nhất thiết phải tăng theo sản lượng.
Kiểm tra điều kiện giao dịch.
Phân loại yêu cầu.
Xác định chính sách phù hợp.
Đối chiếu thông tin.
Phân quyền quyết định.
Phát hiện những trường hợp bất thường.
Đây là những nơi kiến trúc vận hành có thể tạo ra sự khác biệt lớn.
Tôi quan tâm đến tỷ lệ giữa khối lượng kinh doanh và lượng can thiệp thủ công cần thiết để duy trì hoạt động.
Nếu số giao dịch tăng nhưng số ngoại lệ phải chuyển lên quản lý không tăng tương ứng, đó có thể là tín hiệu tốt.
Nếu thời gian xử lý giảm trong khi chất lượng dịch vụ và kết quả kinh doanh được duy trì, đó là một cải tiến có ý nghĩa.
Nếu nhân viên mới có thể xử lý những tình huống từng đòi hỏi kinh nghiệm lâu năm, tổ chức đã chuyển hóa được một phần tri thức cá nhân thành năng lực chung.
Nhưng tất cả những chỉ số đó phải được xem xét cùng nhau.
Giảm ngoại lệ bằng cách cấm khách hàng đưa ra yêu cầu đặc biệt không nhất thiết là thành công.
Giảm số lần phê duyệt bằng cách mặc nhiên chấp thuận mọi thứ có thể là một thảm họa.
Và tăng tốc độ xử lý bằng cách bỏ qua các bước kiểm soát quan trọng cũng không phải cải tiến.
Một hệ thống tốt không chỉ làm công việc nhanh hơn. Nó cho phép tổ chức xử lý độ phức tạp cao hơn mà không phải trả chi phí tăng trưởng tương ứng ở mọi khâu.
Đó mới là năng lực mở rộng mà tôi quan tâm.
11. Người lãnh đạo nên dành thời gian cho những ngoại lệ nào?
Tôi không tin rằng mục tiêu của một CEO là không bao giờ bị làm phiền.
Nếu người lãnh đạo hoàn toàn tách khỏi thực tế vận hành, họ có thể đánh mất nguồn thông tin quan trọng nhất để hiểu doanh nghiệp.
Nhưng tôi cũng không nghĩ một CEO nên trở thành tổng đài phê duyệt cao cấp.
Điều tôi muốn là thay đổi bản chất những vấn đề đi đến người lãnh đạo.
Ở một tổ chức chưa trưởng thành, người lãnh đạo thường phải xử lý những ngoại lệ đã biết.
Một đơn hàng cần giảm giá.
Một khách hàng cần hỗ trợ.
Một tình huống giao nhận cần quyết định.
Một nhân viên không biết nên làm gì.
Ở một tổ chức trưởng thành hơn, phần lớn những trường hợp này nên có cơ chế xử lý rõ ràng.
Người lãnh đạo vẫn có thể quan sát chúng thông qua dữ liệu và các tín hiệu bất thường.
Nhưng không cần trực tiếp can thiệp vào từng sự kiện.
Thời gian đó được dành cho những câu hỏi khó hơn.
Tại sao cấu trúc lợi nhuận đang thay đổi?
Có một nhóm khách hàng mới mà hệ thống chưa nhận diện được không?
Mô hình kinh doanh hiện tại có còn phù hợp khi quy mô tăng gấp năm?
Những năng lực nào tổ chức cần xây dựng trong ba năm tới?
Và điều gì đang giới hạn khả năng phát triển của những con người bên trong hệ thống?
Đây là những vấn đề không có quy trình sẵn.
Chúng đòi hỏi quan sát, phán đoán, thử nghiệm và đôi khi cả những quyết định rất khó.
Tôi muốn người lãnh đạo tập trung vào những vấn đề như vậy.
Không phải vì các công việc vận hành thường ngày kém quan trọng.
Mà vì chúng quan trọng đến mức không nên phụ thuộc mãi vào sự hiện diện của một người duy nhất.
Một người lãnh đạo giỏi không nhất thiết là người ít phải ra quyết định. Mà là người ngày càng dành nhiều quyết định hơn cho những vấn đề chưa từng có lời giải.
Và nếu toàn bộ thời gian của người đó vẫn bị tiêu hao vào những tình huống đã xuất hiện hàng trăm lần?
Tôi nghĩ tổ chức đang gửi đi một tín hiệu khá rõ ràng.
Chỉ là tín hiệu đó thường bị che lấp bởi tiếng chuông điện thoại.
12. Sự tiến hóa không miễn phí. Nhưng sự trì trệ cũng vậy.
Có một sai lầm mà những người yêu thích cải tiến hệ thống rất dễ mắc phải.
Đó là nhìn thấy một quy trình thủ công và lập tức kết luận rằng nó cần được tự động hóa.
Tôi đã từng bị hấp dẫn bởi kiểu suy nghĩ đó.
Một vấn đề xuất hiện.
Chúng ta nhìn thấy khả năng xây dựng một cơ chế mới.
Ý tưởng rất thú vị.
Giải pháp có vẻ thanh lịch.
Và bộ não của một Software Engineer bắt đầu hoạt động.
Nhưng kinh doanh không phải một cuộc thi thiết kế kiến trúc đẹp nhất.
Mọi cải tiến đều có chi phí.
Chi phí phát triển.
Chi phí bảo trì.
Chi phí đào tạo.
Chi phí thay đổi hành vi.
Và chi phí phát sinh khi một quy tắc từng đúng trở nên không còn phù hợp.
Một cơ chế tự động hóa có thể giải quyết rất tốt những trường hợp được dự đoán trước.
Nhưng nếu được thiết kế quá cứng nhắc, nó có thể khiến việc xử lý những tình huống mới trở nên khó khăn hơn.
Vì vậy, câu hỏi không phải:
"Chúng ta có thể tự động hóa việc này không?"
Câu hỏi nên là:
"Việc thay đổi cơ chế xử lý ngoại lệ này có tạo ra nhiều giá trị hơn tổng chi phí và rủi ro mà nó mang lại hay không?"
Đôi khi câu trả lời là có.
Đôi khi câu trả lời là không.
Và đôi khi cách tốt nhất không phải viết thêm phần mềm, mà là xóa bỏ một bước phê duyệt không còn cần thiết.
Tôi thích những giải pháp như vậy.
Chúng không có giao diện đẹp để đem đi khoe.
Nhưng chúng có một ưu điểm rất đáng quý.
Không cần bảo trì.
Lời kết: The Hidden Cost of Exceptions.
Tôi không muốn xây dựng một doanh nghiệp không có ngoại lệ.
Một tổ chức như vậy có lẽ chỉ tồn tại khi thị trường ngừng thay đổi, khách hàng ngừng có nhu cầu mới và con người ngừng đưa ra những ý tưởng khác biệt.
Nói cách khác, khi doanh nghiệp không còn nhiều lý do để tồn tại.
Tôi muốn một tổ chức có khả năng hấp thụ ngoại lệ.
Những tình huống đã biết được xử lý hiệu quả.
Những tình huống cần phán đoán được giao cho người có đủ thông tin và quyền hạn.
Những tình huống mới được xem là cơ hội để học hỏi.
Và những nhiễu loạn không đáng kể không bị biến thành những dự án cải tiến hoành tráng.
Một hệ thống như vậy không thể được xây dựng trong một ngày.
Nó hình thành qua hàng nghìn quyết định nhỏ, hàng trăm lần kiểm chứng và vô số lần điều chỉnh những giả định đã không còn đúng.
Nhưng tôi tin đó là một hướng đi đáng giá.
Bởi vì năng lực cạnh tranh dài hạn của một doanh nghiệp không chỉ đến từ việc nó đang vận hành tốt như thế nào.
Nó còn đến từ khả năng học hỏi và tái cấu trúc nhanh đến đâu khi thế giới xung quanh thay đổi.
Và những ngoại lệ chính là một trong những nơi tốt nhất để quan sát sự thay đổi ấy.
Mỗi ngoại lệ là một tín hiệu.
Một số chỉ là nhiễu.
Một số cho thấy hệ thống có khiếm khuyết.
Một số hé lộ một nhu cầu mà chúng ta chưa từng biết đến.
Và một số đủ quan trọng để khiến chúng ta phải xem xét lại toàn bộ cách doanh nghiệp đang vận hành.
Một tổ chức yếu xử lý ngoại lệ để tiếp tục tồn tại. Một tổ chức mạnh học từ ngoại lệ để trở nên tốt hơn.
Sự khác biệt không nằm ở số lượng vấn đề mà hai tổ chức phải đối mặt.
Nó nằm ở những gì còn lại sau khi vấn đề được giải quyết.
Một bên có thêm kinh nghiệm trong đầu vài người.
Bên còn lại có thêm năng lực trong kiến trúc của toàn bộ tổ chức.
Và đến một ngày, sự khác biệt đó có thể quyết định ai là người có khả năng tiếp tục mở rộng.
Còn nếu ngày mai tôi vẫn phải phê duyệt đúng loại ngoại lệ mà mình đã phê duyệt 500 lần trước đó?
Tôi nghĩ chúng ta không cần tổ chức thêm một cuộc họp rút kinh nghiệm.
Chúng ta cần trả lời một câu hỏi đơn giản hơn.
"Rốt cuộc, sau 500 lần ấy, cái hệ thống này đã học được cái quái gì?"
Nếu câu trả lời là không có gì...
Thì ít nhất chúng ta cũng đã biết ai cần bị gọi lên nói chuyện.
Và rất có thể người đó đang ngồi ở ghế CEO.
Chết tiệt. Lại là tôi.
NEXT CHAPTER — CONNECTING THE DOTS
Nhìn thấy những quy luật ẩn sau sự hỗn loạn: tại sao cùng một dữ liệu, có người chỉ thấy những sự kiện rời rạc, còn người khác nhìn thấy cả một cấu trúc?
The Architect of Chaos — Ông Chú Hay Chửi