Skip to content
Phần lớn các tổ chức hiện nay vẫn tin rằng cách nhanh nhất để hoàn thành nhiều việc hơn là bắt mọi người làm việc nhanh hơn và đẩy nhiều việc vào hệ thống cùng một lúc, nhưng niềm tin này trực tiếp làm chậm dòng chảy công việc và nhân đôi lãng phí.
Từ đội dự án hiệu quả đến tổ chức thực thi xuất sắc – 0300
Tình huống tổng hợp, số liệu minh họa. Tại một bộ phận giao hàng số của một tổ chức dịch vụ tài chính quy mô trung bình, người quản lý giao hàng (delivery manager) đang đối mặt với một bức tường áp lực từ ban điều hành. Ban điều hành yêu cầu rút ngắn thời gian đưa sản phẩm ra thị trường ba mươi phần trăm, đồng thời phải cắt giảm hai mươi phần trăm chi phí hoạt động trong sáu tháng tới. Để đáp ứng yêu cầu, người quản lý giao hàng yêu cầu cả bốn đội phát triển phần mềm chạy tối đa công suất, không được có khoảng nghỉ giữa các chu kỳ làm việc, và mọi kỹ sư phải báo cáo tỷ lệ sử dụng thời gian đạt một trăm phần trăm mỗi ngày. Trên giấy tờ, tổ chức đang hoạt động ở mức năng suất tối đa, mọi người đều bận rộn từ sáng đến tối, và các bảng quản lý công việc trực quan lúc nào cũng đặc kín thẻ công việc.
Sai lầm cốt lõi hình thành từ việc tối ưu từng bộ phận thay vì toàn hệ thống. Khi ban điều hành nhìn thấy các đội phát triển phần mềm hoàn thành lượng lớn thẻ công việc mỗi tuần, họ tin rằng hệ thống đang rất hiệu quả. Sự ngộ nhận này hợp lý vào thời điểm áp lực vì nó dựa trên trực giác quen thuộc: năng suất của toàn bộ tổ chức bằng tổng năng suất của từng cá nhân cộng lại. Người quản lý giao hàng hưởng lợi ngắn hạn vì các báo cáo tiến độ tuần nào cũng hiển thị màu xanh ở mục sản lượng công việc của từng nhóm. Tuy nhiên, cái giá phải trả là toàn bộ dòng chảy công việc bị bóp nghẹt tại khâu kiểm thử chất lượng và khâu phê duyệt tuân thủ, nơi không một nhóm riêng lẻ nào có quyền can thiệp.
Để hiểu vì sao tối ưu hóa từng bộ phận lại phá hủy năng suất tổng thể, cần phân tích dòng công việc qua góc nhìn của lý thuyết giới hạn và dòng chảy. Khi một đội phát triển phần mềm tăng tốc độ viết mã lên năm mươi phần trăm, họ không tạo ra sản phẩm hoàn chỉnh mà chỉ tạo ra lượng lớn công việc đang làm dở dang (work in progress) ùn ứ trước cửa phòng kiểm thử. Phòng kiểm thử chỉ có năng lực xử lý một nửa số lượng đó mỗi tuần, dẫn đến thời gian chờ đợi kéo dài gấp ba. Giả sử đội phát triển gồm mười kỹ sư, lương trung bình ba mươi triệu đồng một tháng, mỗi người tạo ra mười tính năng thô mỗi tuần. Khâu kiểm thử chỉ nhận được năm tính năng và giữ lại năm tính năng còn lại trong kho chờ. Chi phí cho lượng tính năng nằm chờ này tạo ra tổn thất tài chính vô hình nhưng hiện hữu, đồng thời làm giảm chất lượng do mã nguồn để lâu bị lỗi thời hoặc xung đột với các thay đổi khác.
Hệ thống hóa sai lầm này lan rộng rất nhanh. Chỉ sau sáu tuần, dấu hiệu sớm bắt đầu xuất hiện: tỷ lệ lỗi phát hiện ở giai đoạn cuối tăng vọt bốn mươi phần trăm, thời gian từ khi bắt đầu viết mã đến khi đưa được tính năng ra thực tế kéo dài thêm hai tuần thay vì rút ngắn lại, và các kỹ sư bắt đầu kiệt sức vì phải quay lại sửa những đoạn mã đã viết từ hai tháng trước. Dấu hiệu này bị phớt lờ vì các báo cáo vẫn tiếp tục đếm số lượng tính năng thô được tạo ra ở đầu nguồn. Hệ quả hệ thống là toàn bộ tổ chức rơi vào vòng xoáy bù đắp: làm nhanh ở đầu vào, tắc nghẽn ở giữa, hỏng hóc ở đầu ra, và cuối cùng phải tuyển thêm người để giải quyết đống đổ nát do chính quy trình quá tải tạo ra.
Để trả lời câu hỏi làm thế nào để tạo ra kết quả nhanh hơn và tốt hơn, tổ chức phải chuyển dịch tư duy từ tối ưu hóa sản lượng cá nhân sang tối ưu hóa dòng chảy toàn hệ thống. Luận đề trung tâm là tốc độ thực thi không đến từ việc bắt mọi người làm nhanh hơn, mà đến từ việc giảm lượng công việc đang làm dở dang để dòng chảy di chuyển liên tục qua các điểm nghẽn mà không bị gián đoạn. Luận điểm này chỉ đúng khi tổ chức có quyền kiểm soát và điều chỉnh dung lượng đầu vào; nếu ban điều hành ép nhận thêm dự án mới bất chấp năng lực thực tế, việc giảm công việc đang làm dở dang sẽ thất bại và hệ thống sẽ tê liệt hoàn toàn.
Quyết định đúng đắn đòi hỏi người quản lý giao hàng phải lập tức áp dụng cơ chế giới hạn công việc đang làm dở dang. Biến số quyết định ở đây là thời gian chu kỳ (cycle time) của một đơn vị công việc từ khi bắt đầu đến khi hoàn thành thực sự ở tay người dùng. Ngưỡng kích hoạt là khi thời gian chờ tại bất kỳ khâu trung gian nào vượt quá ba mươi phần trăm tổng thời gian xử lý. Khi ngưỡng này bị phá vỡ, người quản lý phải dừng việc nhận nhiệm vụ mới ở đầu nguồn, chuyển một nửa số nhân sự từ khâu đang dư thừa sang khâu đang là điểm nghẽn để giải tỏa dòng chảy.
Bên phản đối quyết định này chắc chắn là các giám đốc chức năng vì họ thấy nhóm của mình bị giảm lượng công việc hiển thị trên báo cáo và sợ bị đánh giá là kém năng suất. Lý lẽ của họ có cơ sở trong ngắn hạn dựa trên thước đo hiệu suất truyền thống là khối lượng đầu ra. Tuy nhiên, người quản lý giao hàng phải chấp nhận đánh đổi: tạm thời hy sinh sản lượng thô ở đầu nguồn để đổi lấy sự gia tăng chất lượng và tốc độ bàn giao thực tế ở đầu ra, chịu sự phàn nàn trước mắt để bảo vệ năng lực cốt lõi của toàn hệ thống về dài hạn.
Để vận hành cơ chế này, tổ chức sử dụng mẫu sản phẩm Hiệu suất vượt trội dưới đây để theo dõi và điều phối dòng công việc.
BẢNG QUẢN LÝ DÒNG CHẢY CÔNG VIỆC VÀ ĐIỂM NGHẼN (Mẫu sản phẩm)
– Cột 1: Giai đoạn công việc (ví dụ: Phân tích, Phát triển, Kiểm thử, Triển khai).
– Cột 2: Giới hạn công việc đang làm dở dang tối đa (ví dụ: 5, 3, 2, 1).
– Cột 3: Số lượng công việc thực tế đang có ở giai đoạn đó (ví dụ: 8, 7, 2, 1).
– Cột 4: Trạng thái dòng chảy (Bình thường / Tắc nghẽn / Quá tải).
– Cột 5: Hành động can thiệp bắt buộc khi trạng thái là Quá tải (ví dụ: Dừng nhận việc mới, Điều phối nhân sự hỗ trợ).
Cách điền: Cập nhật số liệu thực tế vào Cột 3 vào mỗi đầu buổi sáng làm việc dựa trên bảng trực quan của đội. So sánh Cột 3 với Cột 2. Nếu Cột 3 lớn hơn Cột 2, Cột 4 tự động chuyển thành Quá tải.
Cách đọc: Bảng này giúp người quản lý xác định chính xác vị trí điểm nghẽn trong hệ thống chứ không phải đoán mò. Khi thấy ô Giai đoạn Kiểm thử có số thực tế là 7 vượt quá giới hạn 3, người quản lý biết ngay dòng tiền và thời gian đang bị kẹt ở đâu và phải chuyển ngay quyết định hỗ trợ về khâu đó.
BẢNG 1: BẢNG QUYẾT ĐỊNH ĐIỀU PHỐI DÒNG CÔNG VIỆC
Điều kiện tình huống | Lựa chọn hành động | Ngưỡng kích hoạt | Người chịu đánh đổi
——————-|——————-|—————-|——————-
Đầu ra bị chậm dù nhân sự làm việc hết công suất | Giới hạn công việc đang làm dở dang, chuyển nhân sự hỗ trợ điểm nghẽn | Thời gian chờ tại điểm nghẽn vượt 30% tổng thời gian | Giám đốc bộ phận đầu nguồn (giảm sản lượng thô báo cáo)
Yêu cầu mới dồn dập vượt quá năng lực thực tế | Từ chối tiếp nhận hoặc lùi thời hạn các yêu cầu ưu tiên thấp | Tỷ lệ quá tải hệ thống đạt trên 50% liên tục 2 tuần | Người bảo trợ dự án (chậm trễ thời hạn cam kết ban đầu)
Chất lượng sản phẩm giảm do ép tiến độ | Kéo dài chu kỳ làm việc, đưa thêm bước kiểm tra tự động | Tỷ lệ lỗi quay vòng vượt quá 15% tổng sản lượng | Đội phát triển (phải dừng viết mã mới để sửa lỗi cũ)
Bảng này giúp người quản lý quyết định chính xác thời điểm nào phải dừng việc mở rộng quy mô để tập trung giải quyết điểm nghẽn hiện tại, đồng thời xác định rõ ai là người phải chấp nhận hy sinh quyền lợi cục bộ vì mục tiêu chung của hệ thống.
BẢNG 2: BẢNG DẤU HIỆU SỚM VÀ RỦI RO ĐIỀU HÀNH
Dấu hiệu sớm | Cơ chế hình thành | Hậu quả nếu bỏ qua | Phản ứng điều hành bắt buộc
————-|——————-|——————-|————————–
Báo cáo tiến độ màu xanh nhưng không có tính năng nào được phát hành thực tế | Đội ngũ chỉ đo lường khối lượng công việc đã bắt đầu thay vì công việc đã hoàn thành | Lãng phí toàn bộ ngân sách cho những sản phẩm không tạo ra giá trị sử dụng | Yêu cầu định nghĩa lại hoàn thành phải gắn với giá trị thực tế đến tay người dùng
Nhân sự chủ chốt làm việc quá giờ liên tục trong nhiều tuần | Áp dụng cơ chế tăng ca để bù đắp cho sự thiếu hụt năng lực hệ thống | Kiệt sức, tỷ lệ nghỉ việc tăng cao, chất lượng sản phẩm sụt giảm nghiêm trọng | Cắt giảm phạm vi công việc tương ứng với năng lực thực tế, cấm tăng ca kéo dài
Số lượng yêu cầu sửa đổi từ khách hàng tăng vọt ở giai đoạn cuối | Thiếu sự tham gia của người dùng từ các bước đầu, quy trình kiểm soát thay đổi lỏng lẻo | Vượt ngân sách, trễ hạn bàn giao, sản phẩm làm ra không đúng nhu cầu | Thiết lập lại cổng kiểm soát thay đổi, bắt buộc có xác nhận phạm vi từng giai đoạn
Bảng này giúp người quản lý đọc được các triệu chứng ngầm trước khi chúng bùng phát thành khủng hoảng toàn hệ thống, từ đó kích hoạt phản ứng điều chỉnh kịp thời trước khi quá muộn.
BẢNG 3: BẢNG SO SÁNH PHƯƠNG PHÁP THỰC THI THEO ĐIỀU KIỆN
Tiêu chí so sánh | Tối ưu từng bộ phận (Truyền thống) | Tối ưu toàn hệ thống (Lean và Kanban)
——————-|———————————–|———————————–
Mục tiêu đo lường | Sản lượng công việc của từng cá nhân hoặc phòng ban | Tốc độ và chất lượng của dòng chảy hoàn chỉnh đến tay người dùng
Cách xử lý khi quá tải | Ép nhân sự làm việc nhanh hơn, tăng ca, tuyển thêm người | Giới hạn công việc đang làm dở dang, tập trung giải quyết điểm nghẽn
Góc nhìn đánh giá | Cục bộ, chỉ nhìn vào hiệu suất của nhóm mình phụ trách | Toàn diện, nhìn vào toàn bộ chuỗi giá trị từ đầu đến cuối
Rủi ro chính | Tồn đọng công việc, giảm chất lượng, kiệt sức nhân sự | Xung đột quyền lợi giữa các bộ phận chức năng trong ngắn hạn
Bảng này giúp người quản lý phân biệt rõ hai tư duy điều hành đối lập, từ đó lựa chọn đúng phương pháp tối ưu toàn hệ thống thay vì sa vào cái bẫy bận rộn giả tạo của việc tối ưu từng bộ phận.
Tình huống nghiên cứu tổng hợp thứ nhất minh họa cho việc làm sai. Một tổ chức triển khai dự án phát triển ứng dụng di động theo cách truyền thống bằng cách chia nhỏ dự án cho bốn nhà thầu độc lập làm việc song song để tiết kiệm thời gian. Mỗi nhà thầu được giao tối ưu hóa phần việc của mình và được thưởng nếu hoàn thành sớm tiến độ phần việc đó. Kết quả là nhà thầu giao diện hoàn thành trước hai tháng và bỏ đi. Khi nhà thầu xử lý dữ liệu hoàn thành sau đó ba tháng, hai phần mềm không thể tích hợp được với nhau vì giao diện đã thay đổi cấu trúc ngầm mà không thông báo. Tổ chức mất thêm bốn tháng và năm mươi phần trăm ngân sách dự phòng để viết lại từ đầu toàn bộ hệ thống tích hợp. Bài học rút ra là tối ưu hóa từng phần riêng lẻ mà thiếu cơ chế đồng bộ dòng chảy toàn hệ thống dẫn đến thất bại toàn diện.
Tình huống nghiên cứu tổng hợp thứ hai minh họa cho việc làm đúng nhưng phải trả giá trước mắt. Một tổ chức vận hành hệ thống logistics quyết định dừng nhận toàn bộ các yêu cầu phát triển tính năng mới trong một tháng để tập trung dồn toàn lực xử lý điểm nghẽn ở hệ thống cơ sở dữ liệu cũ. Trong tháng đó, các báo cáo gửi lên ban điều hành cho thấy sản lượng tính năng mới bằng không, khiến một số lãnh đạo cấp cao hoài nghi năng lực của người quản lý vận hành. Tuy nhiên, sang tháng thứ hai, thời gian xử lý đơn hàng giảm từ bốn mươi tám giờ xuống còn bốn giờ, năng lực xử lý toàn hệ thống tăng gấp ba lần, và chi phí vận hành giảm ba mươi phần trăm trong quý tiếp theo. Cái giá phải trả là sự bất an ngắn hạn của cấp trên đã được đổi lấy hiệu suất vượt trội và sự ổn định dài hạn của tổ chức.
Để đạt được kết quả nhanh hơn và tốt hơn, tổ chức phải chấp nhận đánh đổi việc giảm sản lượng công việc thô ở đầu vào để đổi lấy sự thông suốt của dòng chảy ở đầu ra. Điều kiện đảo chiều của nguyên tắc này là khi thị trường biến động cực nhanh đòi hỏi phải thử nghiệm diện rộng không cần kiểm soát chặt, nhưng ngay cả trong trường hợp đó, việc không kiểm soát điểm nghẽn vẫn sẽ dẫn đến hỗn loạn thay vì tốc độ.
Các việc cần làm phân theo vai trò trong cấp thực thi:
– Người bảo trợ: Phê duyệt việc giới hạn số lượng dự án triển khai đồng thời; cam kết không ép bổ sung yêu cầu mới khi hệ thống đang quá tải.
– Người quản lý giao hàng: Theo dõi sát sao bảng dòng chảy công việc hàng ngày; chủ động phát hiện điểm nghẽn và điều phối nhân sự hỗ trợ kịp thời.
– Chủ sở hữu sản phẩm: Sắp xếp lại thứ tự ưu tiên của danh sách công việc dựa trên giá trị thực tế; kiên quyết loại bỏ các yêu cầu không mang lại hiệu quả cao.
– Đội thực hiện: Tuân thủ nghiêm ngặt giới hạn công việc đang làm dở dang; dừng ngay việc nhận việc mới khi chưa hoàn thành công việc hiện tại.
Các câu hỏi tự kiểm tra cho người đọc:
1. Tổ chức hiện tại của bạn đang đo lường thành công bằng số lượng công việc đã bắt đầu hay số lượng giá trị đã thực sự đến tay người dùng?
2. Khi một bộ phận trong hệ thống bị quá tải, phản ứng tự nhiên của ban điều hành là tăng ca hay tìm và giải quyết điểm nghẽn?
3. Bạn sẵn sàng hy sinh chỉ số nào trong ngắn hạn để bảo vệ dòng chảy công việc và chất lượng sản phẩm về dài hạn?
4. Giới hạn công việc đang làm dở dang ở đội ngũ của bạn hiện đang được áp dụng bằng quy định cứng hay chỉ là khẩu hiệu hình thức?
#QuanTriDuAn #ToanHieuSuat #DòngChảyCôngVệc #LeanKanban #HieuSuatToanHeThong