Skip to content
Nhiều người vẫn tin rằng dự án thành công là khi tất cả các bộ phận trong tổ chức đều hoạt động hết công suất và đạt chỉ tiêu hiệu suất riêng của mình. Niềm tin này không những sai mà còn là nguyên nhân trực tiếp làm cho dự án trễ hạn, vượt ngân sách và tạo ra những sản phẩm không ai muốn dùng.
Hiệu suất cá nhân và hiệu suất hệ thống khác nhau ở bản chất và mục đích. Hiệu suất cá nhân đo lường mức độ bận rộn và lượng đầu ra của một cá nhân, một đội nhóm hoặc một phòng ban độc lập. Hiệu suất hệ thống đo lường tốc độ dòng công việc di chuyển từ điểm khởi đầu đến khi tạo ra giá trị thực tế cho khách hàng. Một hệ thống có thể bao gồm nhiều cá nhân và bộ phận làm việc với năng suất một trăm phần trăm, nhưng toàn bộ dự án vẫn bị đình trệ vì sản phẩm làm ra bị kẹt lại ở khâu chờ phê duyệt hoặc không khớp với các bộ phận tiếp theo.
Để trả lời cho câu hỏi làm thế nào để tạo ra kết quả nhanh hơn và tốt hơn, câu trả lời cốt lõi nằm ở việc tối ưu hóa toàn bộ dòng chảy công việc thay vì đẩy mạnh hiệu suất của từng bộ phận riêng lẻ. Khi dòng chảy được khơi thông, tốc độ tự động tăng và lãng phí tự động giảm mà không cần ép nhân sự làm việc nhiều hơn. Ngược lại, nếu tập trung tăng năng suất cục bộ, hệ thống sẽ tích tụ lượng công việc dang dở lớn hơn, làm tăng thời gian chờ và kéo dài tổng thời gian hoàn thành dự án.
Hiện trường tại một doanh nghiệp triển khai sản phẩm phần mềm cho thấy rõ áp lực này. Người quản lý giao hàng đang chịu sức ép từ ban điều hành về việc rút ngắn thời gian phát hành tính năng mới. Để đáp ứng, bộ phận lập trình được yêu cầu tăng gấp đôi số lượng dòng mã nguồn và tính năng hoàn thành mỗi tuần. Tuy nhiên, thời gian để đưa tính năng đó ra thị trường không những không giảm mà còn kéo dài thêm hai tuần so với trước. Nguyên nhân là bộ phận kiểm tra chất lượng và bộ phận vận hành không thể xử lý kịp lượng công việc khổng lồ đổ dồn từ lập trình. Khối lượng công việc dang dở chất đống, lỗi phát sinh nhiều hơn, và đội ngũ phải mất thêm thời gian sửa lỗi thay vì phát triển tính năng mới.
Sai lầm phổ biến bắt nguồn từ tư duy tối ưu từng bộ phận thay vì toàn hệ thống. Tư duy này hình thành vì các nhà quản lý thường được giao chỉ tiêu đánh giá theo từng phòng ban, chẳng hạn như số lượng giờ công khai thác của lập trình viên hoặc số lượng hồ sơ xử lý của nhân viên hành chính. Vào lúc áp lực chi phí tăng cao, việc yêu cầu từng bộ phận chứng minh năng suất bằng các con số định lượng riêng lẻ là hợp lý đối với người quản lý cấp trung. Những người trưởng bộ phận hưởng lợi ngắn hạn vì họ đạt chỉ tiêu và nhận thưởng thành tích. Nhưng cái giá phải trả theo chuỗi là toàn bộ hệ thống bị tắc nghẽn, thời gian chờ đợi giữa các khâu tăng vọt, chi phí phát sinh do sửa lỗi và làm lại vượt quá ngân sách dự kiến ban đầu.
Quá trình mổ xẻ vấn đề này dựa trên các nguyên lý về dòng chảy công việc và điểm nghẽn trong quản trị tinh gọn. Khi một công đoạn hoạt động với công suất vượt quá năng lực tiếp nhận của công đoạn liền kề, điểm nghẽn chính thức xuất hiện. Theo lý thuyết về giới hạn, tổng thông lượng của toàn bộ hệ thống bị quyết định hoàn toàn bởi công đoạn có năng lực thấp nhất.
Ví dụ minh họa cho cơ chế này tại một dự án có ba bước: phân tích nghiệp vụ, lập trình, và kiểm thử. Bước phân tích nghiệp vụ hoàn thành năm tài liệu thiết kế mỗi ngày. Bước lập trình với năm nhân sự có thể xử lý mười tính năng mỗi ngày (minh họa). Bước kiểm thử chỉ có một nhân sự với năng lực kiểm tra tối đa hai tính năng mỗi ngày (minh họa). Nếu bước lập trình cố gắng làm việc hết công suất để tạo ra mười tính năng mỗi ngày, lượng công việc tồn đọng tại bước kiểm thử sẽ tăng thêm tám tính năng sau mỗi ngày làm việc (minh họa). Sau năm ngày làm việc, bốn mươi tính năng nằm chờ kiểm thử trong trạng thái chưa được xác thực (minh họa). Khi kiểm thử phát hiện lỗi ở các tính năng này và trả về, lập trình viên đã quên mất bối cảnh ban đầu, mất thêm thời gian tìm hiểu lại, làm giảm năng suất thực tế và gây ùn tắc trầm trọng hơn.
Hệ quả hệ thống của việc tối ưu cục bộ lan rộng ra toàn bộ chuỗi giá trị. Dấu hiệu sớm của hiện tượng này là nhân sự luôn bận rộn, các báo cáo tuần đều ghi nhận khối lượng công việc hoàn thành cao, nhưng không có sản phẩm nào được bàn giao thực tế cho khách hàng sử dụng. Sau khoảng từ bốn đến sáu tuần, các lỗi ẩn bắt đầu bùng nổ khi tích hợp, các bên liên quan bắt đầu tranh chấp trách nhiệm, và dự án trượt tiến độ mà không rõ nguyên nhân gốc rễ.
Để giải quyết tình trạng này, quyết định đúng đắn là áp dụng hạn chế khối lượng công việc dang dở trên toàn hệ thống. Nếu tổng số lượng công việc đang xử lý vượt quá một ngưỡng nhất định, ví dụ vượt quá năng lực của điểm nghẽn nhân ba, thì toàn bộ các công đoạn trước đó phải tạm dừng nhận nhiệm vụ mới để tập trung hỗ trợ giải quyết điểm nghẽn.
Bảng dưới đây mô tả khung quyết định dựa trên trạng thái của điểm nghẽn trong dự án:
| Điều kiện hệ thống | Lựa chọn hành động | Ngưỡng kích hoạt | Người chịu đánh đổi |
|---|---|---|---|
| Điểm nghẽn hoạt động dưới tám mươi phần trăm công suất | Duy trì tốc độ hiện tại, phân phối đều nhiệm vụ | Tải công việc dưới ngưỡng giới hạn | Không có |
| Điểm nghẽn đạt một trăm phần trăm công suất và tồn đọng tăng | Dừng nhận nhiệm vụ mới ở các khâu trước, điều phối nhân sự hỗ trợ điểm nghẽn | Tồn đọng chờ xử lý vượt quá ba ngày làm việc | Các bộ phận thượng nguồn phải giảm tốc độ xuất công việc |
| Điểm nghẽn xảy ra sự cố ngừng trệ hoàn toàn | Kích hoạt phương án dự phòng, chuyển giao bớt việc cho đơn vị ngoài hoặc tái phân bổ ưu tiên | Sự cố kéo dài quá một ngày làm việc | Tiến độ của các hạng mục phụ trợ bị hoãn lại |
Bảng này giúp người quản lý giao hàng quyết định thời điểm chính xác để can thiệp vào dòng công việc, tránh việc dồn ứ tài nguyên vào những hạng mục chưa cần thiết.
Bên phản đối phương án này thường là các trưởng bộ phận thượng nguồn, những người lập luận rằng việc bắt nhân viên của họ giảm tốc độ làm việc sẽ làm lãng phí thời gian và làm giảm chỉ số năng suất cá nhân trên báo cáo hàng tháng. Lý lẽ này có cơ sở từ góc nhìn quản trị truyền thống, nhưng bỏ qua thực tế rằng năng suất cá nhân cao không tạo ra giá trị nếu sản phẩm không thể đến tay người dùng cuối.
Để theo dõi các dấu hiệu suy giảm hiệu suất hệ thống trước khi chúng trở thành khủng hoảng, bảng dấu hiệu sớm dưới đây cần được giám sát thường xuyên:
| Dấu hiệu | Cơ chế hình thành | Hậu quả nếu bỏ qua | Phản ứng cần thiết |
|---|---|---|---|
| Thời gian chờ phê duyệt dài hơn thời gian thực hiện | Phân quyền quyết định quá tập trung, cấp trên quá tải | Dự án chậm tiến độ trước khi bước vào giai đoạn thực thi chính thức | Phân cấp lại thẩm quyền phê duyệt dựa trên hạn mức giá trị |
| Số lượng tài liệu bàn giao tăng mạnh nhưng ít tính năng được nghiệm thu | Đội ngũ tập trung tạo ra tài liệu hình thức thay vì sản phẩm vận hành được | Sản phẩm làm ra không đúng nhu cầu thực tế của người dùng | Chuyển sang phương thức bàn giao sản phẩm chạy thử ngắn hạn |
| Tỷ lệ làm lại công việc vượt quá hai mươi phần trăm tổng thời gian | Thiếu sự thống nhất yêu cầu từ đầu, kiểm tra chất lượng quá muộn | Đội ngũ mệt mỏi, chi phí vượt ngân sách dự kiến | Áp dụng kiểm tra chất lượng ngay trong quá trình thực hiện |
Bảng này giúp người quản lý vận hành nhận diện sớm các điểm nghẽn ẩn giấu trong quy trình phối hợp giữa các phòng ban.
Tình huống nghiên cứu tổng hợp dưới đây minh họa cho việc làm sai: Một dự án xây dựng hệ thống phần mềm nội bộ áp dụng phương pháp đo lường hiệu suất dựa trên số lượng dòng mã nguồn viết ra mỗi ngày của từng lập trình viên. Các lập trình viên đua nhau viết mã nhanh để đạt chỉ tiêu cá nhân. Kết quả là hệ thống có hàng triệu dòng mã nguồn nhưng không có tính năng nào liên kết được với nhau vì thiếu quy chuẩn chung. Dự án thất bại sau sáu tháng triển khai và phải đập đi làm lại toàn bộ với chi phí tổn thất lớ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 đội ngũ triển khai sản phẩm quyết định áp dụng hạn chế công việc dang dở, chỉ cho phép thực hiện tối đa ba tính năng cùng một thời điểm cho toàn bộ hệ thống. Trong hai tuần đầu tiên, các chỉ số đo lường hiệu suất cá nhân của bộ phận lập trình giảm năm mươi phần trăm do có thời gian rảnh rỗi chờ đợi. Trưởng phòng lập trình phản ứng gay gắt vì cho rằng nhân sự đang bị lãng phí thời gian. Tuy nhiên, người quản lý giao hàng giữ nguyên quyết định, yêu cầu nhân viên lập trình dùng thời gian rảnh để hỗ trợ bộ phận kiểm thử và hoàn thiện tài liệu kỹ thuật. Kết quả sau một tháng, thời gian phát hành tính năng ra thị trường giảm từ bốn tuần xuống còn bốn ngày, chất lượng sản phẩm tăng lên rõ rệt và không còn hiện tượng dồn ứ công việc vào cuối chu kỳ.
Mẫu sản phẩm dưới đây có tên gọi Bảng kiểm soát dòng chảy hiệu suất hệ thống, được thiết kế để người quản lý vận hành sử dụng trực tiếp trong các buổi họp đánh giá tiến độ định kỳ:
– Tên công đoạn: [Điền tên bước công việc, ví dụ: Phân tích, Lập trình, Kiểm thử, Bàn giao]
– Giới hạn công việc dang dở tối đa: [Điền số lượng tối đa các hạng mục được phép tồn tại đồng thời tại công đoạn này]
– Số lượng hạng mục đang thực tế xử lý: [Điền số lượng hạng mục hiện tại]
– Tình trạng dòng chảy: [Chọn một trong ba trạng thái: Thông thoáng, Cảnh báo chậm, Tắc nghẽn]
– Biện pháp can thiệp ngay lập tức: [Nêu rõ hành động cụ thể nếu trạng thái là Tắc nghẽn, ví dụ: Chuyển một nhân sự từ công đoạn thông thoáng sang hỗ trợ công đoạn này]
Cách điền mẫu này yêu cầu người quản lý cập nhật số liệu thực tế tại từng công đoạn vào đầu mỗi tuần làm việc. Cách đọc mẫu dựa vào so sánh giữa giới hạn tối đa và số lượng thực tế: nếu số lượng thực tế chạm hoặc vượt giới hạn tối đa, hệ thống lập tức phát tín hiệu cảnh báo và yêu cầu dừng tiếp nhận công việc mới ở các bước trước đó để tập trung giải phóng lượng tồn đọng.
Luận đề trung tâm của bài viết khẳng định rằng để tạo ra kết quả nhanh hơn và tốt hơn, tổ chức phải tối ưu hóa toàn bộ dòng chảy công việc thông qua việc giới hạn công việc dang dở và loại bỏ điểm nghẽn hệ thống, thay vì tăng năng suất đơn lẻ của từng bộ phận. Điều kiện đảo chiều của luận đề này là khi bối cảnh kinh doanh đòi hỏi sản xuất hàng loạt các sản phẩm đơn giản, ít phụ thuộc lẫn nhau và không cần tích hợp hệ thống, thì việc tối ưu hóa năng suất từng cá nhân độc lập lại mang lại hiệu quả cao hơn.
Các việc cụ thể cần làm theo từng vai trò trong dự án nhằm đảm bảo hiệu suất hệ thống:
– Người bảo trợ dự án: Phê duyệt việc áp dụng giới hạn công việc dang dở trên toàn hệ thống; bảo vệ đội ngũ khỏi các áp lực bổ sung phạm vi ngoài kế hoạch; tham gia giải quyết các điểm nghẽn vượt quá thẩm quyền của người quản lý giao hàng.
– Người quản lý giao hàng: Theo dõi sát sao dòng chảy công việc hằng ngày; phát hiện sớm các điểm nghẽn trước khi chúng gây ùn tắc; chủ động điều phối tài nguyên hỗ trợ các khâu bị quá tải theo đúng ngưỡng quy định.
– Chủ sở hữu sản phẩm: Sắp xếp thứ tự ưu tiên rõ ràng cho danh sách các hạng mục công việc; cam kết không đưa thêm yêu cầu mới vào hệ thống khi giới hạn công việc dang dở đã đạt ngưỡng tối đa; phối hợp xác thực chất lượng sản phẩm liên tục.
– Đội ngũ thực hiện: Tuân thủ nghiêm ngặt giới hạn công việc dang dở đã thiết lập; chủ động hỗ trợ các công đoạn khác khi công việc của mình bị kẹt; báo cáo trung thực tình trạng tồn đọng thay vì che giấu để đạt chỉ tiêu cá nhân.
Các câu hỏi tự kiểm tra dành cho người đọc để đánh giá năng lực thực thi:
– Hệ thống hiện tại của tổ chức đang đo lường sự bận rộn của cá nhân hay tốc độ chuyển giao giá trị cho khách hàng?
– Điểm nghẽn lớn nhất trong dòng công việc hiện tại nằm ở khâu nào, và công suất tối đa của khâu đó là bao nhiêu?
– Điều gì xảy ra với các bộ phận thượng nguồn khi công đoạn kiểm thử hoặc bàn giao xảy ra sự cố ùn tắc kéo dài?
– Tổ chức sẵn sàng đánh đổi chỉ số năng suất cục bộ nào để đổi lấy sự thông suốt của toàn bộ dòng chảy công việc?
#QuanTriDuAn #HieuSuatHeThong #QuanTriTinhGon #Kanban #ToiUuQuyTrinh #ReboostLab
