Skip to content
Niềm tin phổ biến trong các tổ chức là dự án hoàn thành đúng hạn, đúng ngân sách và đủ các tính năng trên tài liệu bàn giao nghĩa là đã thành công. Niềm tin này sai. Sự thật là một dự án có thể hoàn thành toàn bộ hạng mục theo cam kết ban đầu nhưng vẫn thất bại về mặt kinh tế, vì sản phẩm làm ra không tạo ra dòng tiền nhanh hơn, không giảm được chi phí vận hành và không mang lại lợi thế cạnh tranh khi ra thị trường. Hoàn thành dự án chỉ là hoàn thành công việc của nhà thầu, còn tạo ra kết quả kinh doanh mới là bản chất của thực thi.
Làm thế nào để tạo ra kết quả nhanh hơn và tốt hơn? Câu trả lời nằm ở việc đo lường và tối ưu hóa dòng chảy của công việc trên toàn bộ hệ thống, thay vì đo lường năng suất cục bộ của từng cá nhân hay từng phòng ban riêng lẻ. Khi dòng công việc di chuyển xuyên suốt từ ý tưởng đến tay người sử dụng mà không bị kẹt lại ở các điểm chờ phê duyệt hay các hàng đợi ngầm, kết quả tự khắc đến nhanh hơn và đạt chất lượng cao hơn. Luận điểm này chỉ đúng khi tổ chức có nhu cầu thị trường ổn định; nếu thị trường biến động quá nhanh khiến định nghĩa giá trị thay đổi từng tuần, việc tối ưu dòng chảy cũ sẽ chỉ giúp sản xuất ra những sản phẩm không còn ai mua nhanh hơn mà thôi (giả định, dựa trên quan sát nghề nghiệp trong các doanh nghiệp triển khai dòng giá trị).
Trong một dự án triển khai nền tảng vận hành mới cho một doanh nghiệp bán lẻ lớn, người quản lý giao hàng đang đứng giữa áp lực khổng lồ. Ban điều hành yêu cầu rút ngắn thời gian bàn giao xuống một nửa so với kế hoạch ban đầu để kịp mùa mua sắm cuối năm. Bộ phận công nghệ thông tin báo cáo tỷ lệ hoàn thành các đoạn mã lệnh đạt một trăm phần trăm công suất thiết kế mỗi tuần. Tuy nhiên, khi ghép các đoạn mã lại để chạy thử nghiệm tổng thể, hệ thống liên tục sập vì không đồng bộ giao diện với bộ phận kho vận. Bộ phận kiểm thử chất lượng ngập trong hàng trăm lỗi phát sinh nhưng không thể đóng bất kỳ lỗi nào vì thiếu tài liệu kỹ thuật từ đội phân tích nghiệp vụ. Không ai trễ việc của phòng mình, nhưng toàn bộ dự án đang tắc nghẽn ở ranh giới giữa các phòng ban. Áp lực dồn lên người quản lý giao hàng khi các bên liên tục đổ lỗi cho nhau, còn ngân sách dự phòng đã cạn kiệt cho việc làm lại các tính năng không khớp nhau.
Sai lầm cốt lõi dẫn đến tình trạng này là 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 rất tự nhiên trong các doanh nghiệp cấu trúc theo chức năng, nơi mỗi giám đốc bộ phận được giao chỉ tiêu hiệu suất riêng biệt. Trưởng phòng công nghệ thông tin phải chứng minh đội ngũ của mình viết được nhiều mã lệnh nhất mỗi tháng. Trưởng phòng mua sắm phải chứng minh mua được thiết bị với giá thấp nhất. Những chỉ tiêu cục bộ này hợp lý đối với từng quản lý bộ phận trong ngắn hạn, vì nó giúp họ bảo vệ ngân sách và nhân sự của mình. Nhưng hệ quả theo chuỗi là mỗi bộ phận tối ưu hóa năng suất riêng bằng cách đẩy hàng tồn đọng và lỗi sang bước tiếp theo. Đội công nghệ đẩy mã lệnh chưa kiểm tra kỹ sang đội kiểm thử; đội kiểm thử đẩy danh sách lỗi dài dằng dặc về cho đội phát triển. Hậu quả là tổng thời gian để một tính năng đi từ yêu cầu đến thực tế bị kéo dài gấp ba lần, dù không ai ngồi chơi.
Để giải quyết tình trạng này, cần nhìn nhận đơn vị phân tích là dòng công việc, thay vì từng cá nhân hay từng phòng ban. Theo các nguyên lý của quản trị dòng giá trị và lý thuyết ràng buộc, hiệu suất của toàn hệ thống bị quyết định hoàn toàn bởi điểm nghẽn duy nhất có năng lực thấp nhất trên dòng chảy đó. Việc cố gắng tăng tốc độ ở các khâu không phải điểm nghẽn không những không làm tăng tổng sản lượng, mà còn tạo ra lượng công việc dồn ứ lớn hơn, làm tăng chi phí lưu kho và chi phí sửa lỗi.
Ví dụ cụ thể về cơ chế này dựa trên số liệu minh họa của một chuỗi công việc phát triển tính năng phần mềm. Giả sử dòng công việc đi qua bốn bước: Phân tích nghiệp vụ, Lập trình, Kiểm thử, và Triển hành. Năng lực xử lý tối đa của từng bước trong một tuần lần lượt là: Phân tích xử lý được mười tài liệu, Lập trình xử lý được hai mươi tài liệu, Kiểm thử xử lý được năm tài liệu, và Triển hành xử lý được mười lăm tài liệu. Bước kiểm thử chính là điểm nghẽn của toàn bộ hệ thống với năng lực chỉ đạt năm tài liệu mỗi tuần.
Nếu ban quản lý rót thêm tiền để tuyển thêm lập trình viên nhằm đẩy năng lực lập trình lên ba mươi tài liệu mỗi tuần, điều gì sẽ xảy ra? Số lượng tài liệu hoàn thành từ bước lập trình sẽ ùn ứ trước cửa phòng kiểm thử. Hàng đợi chờ kiểm thử phình to, thời gian chờ đợi tăng lên, các lỗi phát sinh bị giữ lại lâu hơn trước khi được phát hiện, khiến chi phí sửa lỗi tăng theo cấp số nhân. Năng lực đầu ra của toàn hệ thống vẫn giữ nguyên ở mức năm tài liệu mỗi tuần, trong khi chi phí nhân sự tăng lên và tinh thần đội ngũ giảm sút do ngập trong đống việc dở dang.
Hiệu suất vượt trội chỉ đạt được khi loại bỏ lãng phí, tăng tốc độ và tăng năng suất dựa trên việc khai thác điểm nghẽn. Loại bỏ lãng phí trong dòng công việc đòi hỏi phải nhận diện và cắt bỏ những bước không tạo ra giá trị cho người sử dụng cuối cùng, chẳng hạn như việc làm ba lớp báo cáo tiến độ khác nhau cho ba cấp quản lý nhưng không cấp nào dùng đến số liệu đó để ra quyết định. Tăng tốc độ được thực hiện bằng cách giới hạn số lượng công việc đang làm đồng thời (tác phẩm dở dang), buộc đội ngũ phải hoàn thành dứt điểm một việc trước khi chuyển sang việc tiếp theo, thay vì ôm đồm nhiều việc cùng lúc khiến mọi thứ đều dang dở. Tăng năng suất đạt được bằng cách chuyển giao nguồn lực từ những khâu có dư thừa năng lực đến thẳng điểm nghẽn của hệ thống, giúp nâng trần năng lực toàn cục lên một mức cao hơn.
Hệ quả hệ thống của việc không quản lý dòng công việc là sự suy giảm năng lực cạnh tranh diễn ra từ từ rồi đột ngột. Dấu hiệu sớm xuất hiện sau khoảng một phần ba thời gian dự án: số lượng biên bản họp tăng vọt nhưng không có tính năng nào được bàn giao thực tế; các bảng theo dõi tiến độ bắt đầu xuất hiện các cột màu vàng và đỏ ở khâu kiểm thử hoặc bàn giao; các bên liên quan bắt đầu có văn bản tự bảo vệ mình trước khi rủi ro bùng nổ. Nếu không can thiệp kịp thời, dự án sẽ rơi vào trạng thái tê liệt toàn tập khi ngày bàn giao cận kề mà không ai biết chính xác phần nào đã sẵn sàng.
Khi đối mặt với điểm nghẽn và hiệu suất suy giảm, người quản lý phải đưa ra quyết định dựa trên các biến số thực tế thay vì cảm tính.
BẢNG QUYẾT ĐỊNH ĐIỀU PHỐI DÒNG CÔNG VIỆC
| Điều kiện hệ thống | Lựa chọn can thiệp | Ngưỡng kích hoạt | Người chịu đánh đổi |
| :— | :— | :— | :— |
| Điểm nghẽn nằm ở khâu kiểm thử chất lượng, hàng đợi vượt quá mười ngày làm việc | Tạm dừng nhận yêu cầu mới, điều chuyển lập trình viên sang hỗ trợ viết kịch bản kiểm thử | Tồn đọng vượt hai tuần năng lực xử lý của điểm nghẽn | Bộ phận yêu cầu tính năng mới phải chờ đợi lâu hơn cho các yêu cầu tiếp theo |
| Điểm nghẽn nằm ở khâu phê duyệt pháp lý từ bên ngoài dự án, không thể điều chuyển nội bộ | Tách gói công việc thành phần độc lập có thể triển khai trước, thiết lập cơ chế giảm thiểu rủi ro pháp lý | Thời gian chờ phê duyệt vượt quá mười lăm ngày làm việc so với kế hoạch | Bộ phận pháp lý và kiểm soát tuân thủ phải làm việc với khối lượng hồ sơ dồn dập trong thời gian ngắn |
| Tỷ lệ lỗi phát sinh sau khi bàn giao vượt quá mười phần trăm tổng số lượng giao hàng | Giảm năm mươi phần trăm số lượng công việc đang làm đồng thời, tập trung toàn lực sửa lỗi cũ | Tỷ lệ lỗi chạm ngưỡng quy định trong hai chu kỳ đo lường liên tiếp | Người bảo trợ dự án phải chấp nhận lùi thời hạn bàn giao các tính năng giai đoạn sau |
Bảng này giúp người quản lý quyết định chính xác thời điểm nào cần dừng nhận việc mới để giải quyết ùn tắc, thay vì tiếp tục dồn áp lực làm tăng tỷ lệ lỗi và lãng phí nguồn lực.
Trong thực tế triển khai, các bên liên quan sẽ phản đối kịch liệt các quyết định tái phân bổ nguồn lực. Trưởng bộ phận phát triển sản phẩm sẽ phản đối việc dừng nhận yêu cầu mới vì họ sợ mất chỉ tiêu đóng góp tính năng với ban tổng giám đốc. Lập trình viên được điều sang hỗ trợ kiểm thử sẽ phản đối vì cho rằng đó không phải chuyên môn của họ. Lý lẽ của các bên có cơ sở từ hệ thống đánh giá hiệu suất hiện hành của doanh nghiệp, nơi mỗi cá nhân chỉ được thưởng dựa trên việc hoàn thành chỉ tiêu hẹp của phòng ban mình. Người quản lý dự án phải chấp nhận đứng giữa những mâu thuẫn này, bảo vệ quyết định tối ưu hóa toàn hệ thống và yêu cầu ban điều hành thay đổi cách đánh giá thành tích sang hướng ghi nhận đóng góp vào dòng chảy chung của toàn dự á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 và hậu quả. (Tình huống tổng hợp, số liệu minh họa). Một dự án xây dựng hệ thống quản lý kho cho một doanh nghiệp sản xuất chọn cách đo lường hiệu suất bằng số lượng biên bản họp và số lượng tài liệu thiết kế kỹ thuật được các bên ký duyệt hàng tuần. Đội ngũ quản lý dự án thúc ép các nhóm đẩy mạnh tốc độ viết tài liệu để đạt chỉ tiêu đề ra. Các tài liệu được thông qua nhanh chóng mà không kiểm tra tính khả thi thực tế của quy trình kho. Khi hệ thống được cài đặt sau sáu tháng, các thủ kho từ chối sử dụng vì giao diện quá phức tạp và không khớp với thực tế thao tác tại hiện trường. Dự án hoàn thành trên giấy tờ, ngân sách giải ngân đủ một trăm phần trăm, nhưng hệ thống bị bỏ xó trong kho dữ liệu, không tạo ra bất kỳ giá trị tiết kiệm chi phí nào như cam kết ban đầu trong phương án đầu tư.
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. (Tình huống tổng hợp, số liệu minh họa). Một dự án tái cấu trúc chuỗi cung ứng quyết định áp dụng giới hạn công việc đang làm đồng thời. Thay vì cho phép năm mươi nhà cung cấp cùng gửi hồ sơ thẩm định giá một lúc, ban quản lý chỉ nhận tối đa mươi hồ sơ cho mỗi đợt xử lý. Ngay tuần đầu tiên, các giám đốc kinh doanh của nhà cung cấp gửi đơn khiếu nại lên cấp cao vì cho rằng quy trình làm việc bị chậm lại và họ mất lợi thế cạnh tranh về thời gian. Ban quản lý dự án giữ nguyên quyết định, chấp nhận áp lực chính trị ngắn hạn từ phía nhà cung cấp. Kết quả sau ba tháng là thời gian thẩm định trung bình mỗi hồ sơ giảm từ bốn mươi ngày xuống còn bảy ngày, tỷ lệ hồ sơ thiếu sót giảm từ sáu mươi phần trăm xuống còn dưới năm phần trăm, và toàn bộ chuỗi cung ứng vận hành trơn tru mà không cần tăng thêm nhân sự.
BẢNG DẤU HIỆU SỚM VÀ RỦI RO TRONG THỰC THI
| Dấu hiệu sớm | Cơ chế phát sinh | Hậu quả nếu bỏ qua | Phản ứng cần thiết |
| :— | :— | :— | :— |
| Số lượng tài liệu thiết kế và yêu cầu đang chờ phê duyệt tăng liên tục qua các tuần | Năng lực thẩm định của cấp quản lý thấp hơn tốc độ sinh ra yêu cầu từ đội ngũ phân tích | Dự án chìm trong các yêu cầu lỗi thời, khi triển khai thực tế không ai còn nhớ rõ bối cảnh ban đầu | Áp dụng giới hạn số lượng tài liệu chờ phê duyệt, tổ chức họp quyết định nhanh theo khung thời gian cố định |
| Đội ngũ phát triển liên tục đổi nhiệm vụ giữa nhiều hạng mục khác nhau trong cùng một tuần | Thiếu sự ưu tiên rõ ràng từ người sở hữu sản phẩm, ai kêu trước được làm trước | Năng suất thực tế sụt giảm nghiêm trọng do chi phí chuyển đổi ngữ cảnh làm việc của nhân sự | Khóa danh sách công việc được phép làm trong tuần, cấm nhận việc ngoài danh sách đã cam kết |
| Tỷ lệ công việc phải làm lại sau khi kiểm thử vượt quá ba mươi phần trăm tổng sản lượng | Bỏ qua bước kiểm tra chất lượng ở các khâu trung gian để kịp tiến độ báo cáo ban điều hành | Chi phí sửa lỗi vượt ngân sách dự phòng, các thành viên kiệt sức vì làm việc quá giờ liên tục | Tạm dừng toàn bộ hạng mục mới, tập trung nguồn lực thiết lập lại chuẩn chất lượng ở từng bước nhỏ |
Bảng này giúp người quản lý nhận biết các triệu chứng suy giảm hiệu suất từ sớm, trước khi chúng biến thành khủng hoảng chi phí và tiến độ ở giai đoạn cuối dự án.
Mẫu sản phẩm dùng ngay dưới đây giúp đo lường và hiển thị hiệu suất thực thi của dòng công việc theo thời gian thực. Mẫu này dành cho cấp quản lý giao hàng và quản lý vận hành.
BẢNG THEO DÕI DÒNG CHẢY CÔNG VIỆC VÀ HIỆU SUẤT THỰC THI (MẪU)
| Giai đoạn công việc | Số lượng đang làm (WIP) | Giới hạn tối đa (Limit) | Thời gian chờ trung bình (Lead Time) | Tỷ lệ lỗi phát sinh (%) |
| :— | :— | :— | :— | :— |
| 1. Tiếp nhận yêu cầu | 12 | 15 | 3 ngày | 5% |
| 2. Phân tích nghiệp vụ | 8 | 10 | 5 ngày | 12% |
| 3. Phát triển / Lập trình | 25 | 20 | 12 ngày | 20% |
| 4. Kiểm thử chất lượng | 35 | 10 | 18 ngày | 35% |
| 5. Bàn giao vận hành | 4 | 5 | 2 ngày | 2% |
Hướng dẫn cách điền và cách đọc mẫu:
– Cột Số lượng đang làm: Ghi tổng số lượng hạng mục đang nằm chờ hoặc đang được xử lý thực tế tại mỗi giai đoạn tính đến thời điểm báo cáo. Số liệu này đếm trực tiếp từ bảng quản lý công việc, không lấy từ ước tính chủ quan.
– Cột Giới hạn tối đa: Đặt ra ngưỡng số lượng tối đa mà mỗi giai đoạn được phép nhận để tránh quá tải. Ngưỡng này bằng năng lực thực tế của khâu yếu nhất trên dây chuyền.
– Cột Thời gian chờ trung bình: Đo khoảng thời gian tính bằng ngày từ khi một hạng mục bước vào giai đoạn đó cho đến khi hoàn thành và chuyển sang giai đoạn kế tiếp.
– Cột Tỷ lệ lỗi phát sinh: Tính tỷ lệ phần trăm số lượng hạng mục phải trả lại giai đoạn trước để sửa chữa so với tổng số lượng đã nhận vào giai đoạn đó.
– Cách đọc bảng: Nhìn vào dòng nào có số lượng đang làm vượt quá giới hạn tối đa và thời gian chờ tăng vọt (như giai đoạn Kiểm thử trong mẫu trên có số lượng 35 vượt giới hạn 10 và thời gian chờ lên tới 18 ngày), đó chính là điểm nghẽn của toàn hệ thống. Mọi nỗ lực tối ưu phải tập trung giải cứu điểm nghẽn này thay vì đẩy thêm người vào giai đoạn Phát triển vốn đang có số lượng đang làm vượt trần nhưng không thể đẩy hàng đi tiếp.
Để tạo ra kết quả nhanh hơn và tốt hơn, tổ chức phải chuyển từ việc ép buộc tăng năng suất cục bộ từng phòng ban sang việc khai thác và làm sạch điểm nghẽn trên toàn bộ dòng công việc. Điều này chỉ mang lại hiệu quả khi ban lãnh đạo sẵn sàng thay đổi hệ thống đánh giá thành tích từ đo lường khối lượng công việc hoàn thành trên giấy sang đo lường tốc độ dòng chảy giá trị thực tế đến tay người sử dụng. Nếu thị trường biến động quá nhanh khiến giá trị sản phẩm thay đổi từng tuần, cách tiếp cận này cần được kết hợp với việc thu hẹp chu kỳ lập kế hoạch xuống mức ngày thay vì tuần.
Các việc cần làm phân theo vai trò:
– Người bảo trợ dự án: Phê duyệt việc áp dụng giới hạn công việc đang làm đồng thời trên toàn dự án; bảo vệ quyết định tạm dừng nhận yêu cầu mới khi điểm nghẽn quá tải trước áp lực từ các phòng ban chức năng; thay đổi tiêu chí đánh giá thành tích của quản lý các bên sang đóng góp vào dòng chảy chung.
– Quản lý dự án: Vận hành và cập nhật bảng theo dõi dòng chảy công việc hàng tuần; xác định chính xác điểm nghẽn của hệ thống bằng số liệu thực tế; điều chuyển nguồn lực tạm thời đến khâu bị nghẽn theo đúng ngưỡng quy định.
– Chủ sở hữu sản phẩm: Sắp xếp lại thứ tự ưu tiên của danh sách yêu cầu dựa trên giá trị kinh doanh thực tế; kiên quyế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 đang làm đã đạt ngưỡng tối đa.
– Đội thực hiện: Tuân thủ nghiêm ngặt việc không nhận việc mới khi chưa hoàn thành việc cũ; chủ động báo cáo ngay các dấu hiệu ùn tắc và lỗi phát sinh tại khâu mình phụ trách thay vì tự ý xử lý chìm khuất.
Câu hỏi tự kiểm tra cho người đọc:
– Điểm nghẽn hiện tại trên dòng công việc của dự án bạn đang điều hành nằm ở khâu nào, và năng lực xử lý tối đa của khâu đó là bao nhiêu đơn vị mỗi tuần?
– Bạn đã áp dụng cơ chế giới hạn số lượng công việc đang làm đồng thời chưa, và điều gì xảy ra với các bên liên quan khi bạn từ chối nhận thêm yêu cầu mới?
– Làm thế nào để phân biệt giữa một nỗ lực tối ưu hóa toàn hệ thống thực sự với việc chuyển rác thải từ phòng ban này sang phòng ban khác?
– Chỉ số nào trong báo cáo tiến độ hiện tại của bạn đang phản ánh sai lệch thực tế dòng chảy công việc, và bạn sẽ thay thế nó bằng chỉ số gì?
#QuanTriDuAn #DoLuongHieuSuat #LyThuyetRangBuoc #ValueStreamManagement #QuanTriHieuQua #ToiUuHeThong
