
Đã hoàn thành xong dự án không một ngày chậm trễ, nhưng tổ chức vẫn phải đóng cửa dòng sản phẩm đó sau sáu tháng vì không ai mua, không phải là một sự cố hy hữu mà là hệ quả tất yếu của việc đánh đồng việc hoàn thành khối lượng công việc trên giấy với việc tạo ra giá trị thực tế cho thị trường.
Lãng phí trong môi trường dự án là gì. Trong quản lý vận hành và triển khai thực thi, lãng phí không chỉ nằm ở những khoản ngân sách bị thất thoát do sai sót tài chính, mà nằm ở mọi hoạt động tiêu tốn thời gian, nhân lực và chi phí nhưng không đóng góp bất kỳ giá trị nào cho người sử dụng cuối cùng. Nền tảng của tư duy tinh gọn Lean và quản lý dòng chảy công việc Kanban đều chỉ ra rằng phần lớn thời gian trong một dự án không dành cho việc tạo ra sản phẩm, mà dành cho việc chờ đợi, sửa lỗi, làm lại và luân chuyển giữa các phòng ban. Khi một đội ngũ tự hào vì đã hoàn thành một trăm phần trăm các hạng mục công việc theo đúng kế hoạch ban đầu, nhưng sản phẩm làm ra phải nằm chờ nhiều tuần để đợi phòng ban khác phê duyệt, đó là biểu hiện rõ nét của lãng phí độ trễ. Khi một tính năng được phát triển rất nhanh bằng hàng nghìn giờ công kỹ thuật nhưng không bao giờ được khách hàng sử dụng, đó là biểu hiện của lãng phí sản xuất thừa. Lãng phí trong dự án Việt Nam thường ẩn giấu dưới vỏ bọc của sự bận rộn liên tục, nơi nhân sự phải tham gia các cuộc họp kéo dài để báo cáo tiến độ thay vì tập trung giải quyết điểm nghẽn.
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 dịch chuyển trọng tâm từ việc quản lý khối lượng công việc sang việc quản lý tốc độ di chuyển của dòng công việc qua hệ thống, kết hợp với việc triệt tiêu tận gốc các điểm nghẽn cục bộ thay vì tìm cách tăng năng suất của từng cá nhân riêng lẻ. Khi dòng công việc được làm phẳng và loại bỏ các bước trung gian không tạo ra giá trị, kết quả sẽ tự động đến nhanh hơn và đạt chất lượng cao hơn mà không cần ép buộc đội ngũ làm việc quá sức.
Hiện trường. Một tình huống tổng hợp, số liệu minh họa. Tại một doanh nghiệp dịch vụ tài chính đang triển khai dự án nâng cấp hệ thống giao dịch số, người quản lý giao hàng và quản lý tối ưu hóa vận hành đang đứng giữa áp lực nặng nề từ ban điều hành. Dự án đã đi qua một nửa thời gian cam kết nhưng bộ phận công nghệ liên tục báo cáo rằng họ đang quá tải và không thể kịp tiến độ. Trong khi đó, các phòng ban nghiệp vụ liên tục gửi yêu cầu bổ sung tính năng mới với lý do thị trường thay đổi nhanh. Bộ phận kiểm thử phần mềm đang phải ngâm các bản dựng trong nhiều tuần vì thiếu nhân sự, dẫn đến việc khi lỗi được phát hiện thì đội ngũ lập trình đã chuyển sang làm việc khác và mất rất nhiều thời gian để nhớ lại ngữ cảnh cũ. Báo cáo tuần nào cũng hiển thị màu xanh ở các đầu mục công việc đã hoàn thành của từng phòng ban riêng lẻ, nhưng toàn bộ dự án thì dậm chân tại chỗ.
Giả định sai. Sai lầm phổ biến nhất trong tình huống này là tư duy tối ưu từng bộ phận thay vì toàn hệ thống, xuất phát từ quan điểm cho rằng nếu mọi cá nhân và mọi phòng ban đều làm việc hết công suất thì toàn bộ dự án sẽ đạt hiệu suất cao nhất. Tư duy này rất hợp lý vào lúc mắc phải vì nó trực quan và dễ đo lường bằng các chỉ số KPI cá nhân quen thuộc: lập trình viên viết được bao nhiêu dòng mã, kiểm thử viên chạy được bao nhiêu kịch bản, nhân viên nghiệp vụ soạn được bao nhiêu trang tài liệu. Những người quản lý cấp trung hưởng lợi ngắn hạn từ cách tiếp cận này vì họ dễ dàng chứng minh được đội ngũ của mình đang rất bận rộn và không có thời gian nhàn rỗi. Tuy nhiên, cái giá phải trả cho việc này là sự hình thành các kho chứa công việc dở dang khổng lồ giữa các phòng ban, làm tăng thời gian chờ đợi lên gấp nhiều lần thời gian thực hiện thực tế, kéo dài tổng thời gian hoàn thành dự án và làm suy kiệt năng lượng của toàn bộ tổ chức.
Mổ xẻ. Dựa trên các nguyên tắc của Lý thuyết ràng buộc (Theory of Constraints) và quản lý dòng chảy công việc, tốc độ của toàn bộ dự án không bị quyết định bởi tốc độ của bộ phận nhanh nhất, mà bị bóp nghẹt hoàn toàn bởi bộ phận chậm nhất trong dây chuyền. Trong tình huống trên, nếu bộ phận kiểm thử chỉ có khả năng xử lý mười tính năng mỗi tuần trong khi bộ phận lập trình sản sinh ra ba mươi tính năng mỗi tuần, thì việc ép lập trình viên viết nhanh hơn không giúp dự án chạy nhanh hơn, mà chỉ làm cho số lượng tính năng nằm chờ kiểm thử tăng vọt, chiếm không gian lưu trữ, làm suy giảm chất lượng và tạo ra áp lực tâm lý lớn hơn.
Để minh họa cơ chế này, xét một dự án có quy mô một trăm đơn vị công việc phải qua ba bước liên tiếp: lập trình, kiểm thử và triển khai. Bước một, lập trình xử lý năm đơn vị mỗi ngày. Bước thứ hai, kiểm thử xử lý hai đơn vị mỗi ngày. Bước thứ ba, triển khai xử lý bốn đơn vị mỗi ngày.
Theo lý thuyết dòng chảy, điểm nghẽn nằm ở bước kiểm thử với công suất hai đơn vị mỗi ngày. Nếu đầu tư tăng gấp đôi năng lực lập trình lên mười đơn vị mỗi ngày, kết quả thu được không phải là dự án hoàn thành nhanh hơn, mà là lượng công việc tồn đọng trước cửa phòng kiểm thử phình to từ mười lên năm mươi đơn vị sau mười ngày. Chi phí tài chính cho công việc dở dang tăng lên, rủi ro lỗi phần mềm tăng theo cấp số nhân do thông tin bị cũ đi, và thời gian chờ đợi từ lúc bắt đầu đến khi phát hành sản phẩm thực tế bị kéo dài ra thay vì rút ngắn lại.
Hệ quả hệ thống. Sai lầm tối ưu cục bộ lan từ phòng ban kỹ thuật sang bộ phận tài chính và kinh doanh qua cơ chế trễ hạn phản hồi. Sau khoảng ba tháng, các dấu hiệu bắt đầu lộ diện: chi phí phát sinh tăng do phải làm thêm giờ để giải quyết các đợt ùn tắc đột xuất, nhân sự giỏi chán nản vì thấy công sức của mình bị kẹt lại ở các khâu trung gian, và quan hệ giữa các bộ phận trở nên căng thẳng khi ai cũng đổ lỗi cho nhau chậm tiến độ. Dấu hiệu sớm nhất và đáng tin cậy nhất không phải là việc báo cáo tiến độ chậm, mà là sự gia tăng đột biến của lượng công việc đang chờ xử lý giữa các phòng ban trong khi năng suất làm việc thực tế của từng cá nhân vẫn được báo cáo là đạt một trăm phần trăm.
Quyết định. Cách tiếp cận đúng đắn đòi hỏi người quản lý phải dừng ngay lập tức việc ép các bộ phận tăng tốc độ đầu vào, thay vào đó phải áp dụng nguyên tắc bóp nghẹt đầu vào theo công suất của điểm nghẽn. Nếu điểm nghẽn kiểm thử chỉ xử lý được hai đơn vị mỗi ngày, thì lập trình viên chỉ được phép bàn giao tối đa hai đơn vị mỗi ngày cho kiểm thử, phần thời gian dư ra phải được chuyển sang hỗ trợ kiểm thử hoặc tự động hóa quy trình kiểm thử.
Bảng dưới đây minh họa khung ra quyết định dựa trên trạng thái của dòng công việc và điểm nghẽn trong dự án.
+———————–+—————————+———————–+———————–+———————–+
| Trạng thái điểm nghẽn | Lựa chọn hành động | Ngưỡng kích hoạt | Bên phản đối dự kiến | Người chịu đánh đổi |
+———————–+—————————+———————–+———————–+———————–+
| Ùn tắc nghiêm trọng | Giới hạn công việc dở dang| Lượng tồn đọng vượt | Bộ phận đầu vào | Tốc độ bắt đầu |
| tại một khâu | (WIP Limit), chuyển | mức chịu đựng của | (lập trình viên, | của từng cá nhân bị |
| | nhân sự hỗ trợ điểm nghẽn | điểm nghẽn trên 150% | chuyên viên nghiệp vụ)| giảm để cứu toàn cục |
+———————–+—————————+———————–+———————–+———————–+
| Năng lực các khâu | Cân đối lại nguồn lực | Chênh lệch công suất | Quản lý các phòng | Ngân sách phân bổ |
| tương đối cân bằng | theo dòng chảy liên tục | giữa các bước vượt | ban chịu ảnh hưởng | lại giữa các hạng mục |
| | (Flow optimization) | quá 30% | về định biên nhân sự | ưu tiên |
+———————–+—————————+———————–+———————–+———————–+
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 việc mở rộng quy mô công việc và chuyển sang tối ưu hóa năng lực thông lượng của toàn bộ hệ thống.
Mẫu sản phẩm hiệu suất vượt trội dưới đây cung cấp một công cụ trực tiếp để đo lường và loại bỏ lãng phí dòng công việc trong thực tế triển khai.
MẪU SẢN PHẨM: BẢNG KIỂM SOÁT DÒNG CHẢY CÔNG VIỆC VÀ TỒN ĐỌNG (WIP CONTROL & FLOW BOARD)
Cách điền:
1. Chia quy trình thực hiện dự án thành các bước rõ ràng từ trái sang phải (Ví dụ: Tiếp nhận yêu cầu, Phân tích, Lập trình, Kiểm thử, Phát hành).
2. Đặt giới hạn số lượng công việc dở dang tối đa cho phép ở mỗi bước (Ví dụ: Kiểm thử tối đa cho phép 5 hạng mục cùng lúc).
3. Ghi nhận số lượng thực tế đang nằm ở từng bước vào cuối mỗi tuần.
4. Tính thời gian chuyển dịch trung bình từ lúc bắt đầu đến khi hoàn thành (Lead Time).
Cách đọc:
– Nếu số lượng thực tế ở bất kỳ bước nào vượt quá giới hạn cho phép trong hai tuần liên tiếp, đó là điểm nghẽn bắt buộc phải can thiệp bằng cách điều chuyển nhân lực từ các bước khác sang hỗ trợ.
– Nếu thời gian chuyển dịch tăng lên trong khi số lượng công việc hoàn thành giảm xuống, hệ thống đang tồn tại lãng phí do làm nhiều việc cùng lúc (Multitasking waste).
Tình huống nghiên cứu tổng hợp thứ nhất, làm sai và hệ quả. Một dự án triển khai nền tảng quản trị doanh nghiệp quyết định mở rộng quy mô bằng cách chia nhỏ thành mười tiểu dự án chạy song song để đẩy nhanh tiến độ trên giấy. Do nguồn lực phân tán và thiếu tập trung, không có tiểu dự án nào hoàn thành trọn vẹn để đưa vào vận hành. Sau tám tháng, toàn bộ ngân sách cạn kiệt, các bên liên thiện mâu thuẫn gay gắt, và tổ chức phải xóa sổ toàn bộ kết quả để làm lại từ đầu.
Tình huống nghiên cứu tổng hợp thứ hai, làm đúng nhưng phải trả giá trước mắt. Một dự án tái cấu trúc quy trình vận hành quyết định cắt giảm một nửa số lượng hạng mục đang làm dở dang để tập trung toàn lực hoàn thành dứt điểm từng phần một. Quyết định này ngay lập tức vấp phải sự phản đối dữ dội từ các quản lý cấp trung vì họ phải thừa nhận trước ban điều hành rằng nhiều phần việc đang bị đình trệ tạm thời. Tuy nhiên, cái giá phải trả ngắn hạn đó đổi lại việc những sản phẩm đầu tiên được bàn giao đưa vào khai thác thực tế chỉ trong vòng một tháng, tạo ra dòng tiền và niềm tin ban đầu cho toàn bộ ban lãnh đạo cấp cao.
Bảng dưới đây liệt kê các dấu hiệu sớm và rủi ro hệ thống khi xuất hiện lãng phí trong môi trường dự án.
+———————–+———————–+———————–+———————–+
| 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 |
+———————–+———————–+———————–+———————–+
| Báo cáo tiến độ xanh | Báo cáo dựa trên đầu | Dự án đột ngột chuyển | Áp dụng đo lường dựa |
| nhưng không có sản | mục công việc đã làm | sang màu đỏ ở giai | trên giá trị thực tế |
| phẩm thực tế bàn giao | thay vì giá trị tạo ra| đoạn cuối cùng | đã được nghiệm thu |
+———————–+———————–+———————–+———————–+
| Thời gian chờ phê | Phân quyền quyết định | Trì trệ toàn bộ chu | Thiết lập ngưỡng phân |
| duyệt giữa các cấp | bị nén chặt ở tầng | trình, nhân sự mất | quyền rõ ràng theo |
| kéo dài hơn thời gian | quản lý cấp cao | động lực làm việc | giá trị tài chính |
| thực hiện | | | và rủi ro |
+———————–+———————–+———————–+———————–+
Bảng này giúp người quản lý nhận diện chính xác các rủi ro ẩn giấu đằng sau những con số báo cáo tiến độ hình thức trước khi chúng biến thành khủng hoảng không thể cứu vãn.
Để tạo ra kết quả nhanh hơn và tốt hơn, người quản lý phải kiên quyết từ bỏ ảo tưởng rằng làm nhiều việc cùng một lúc sẽ đẩy nhanh tiến độ, và thay vào đó phải chấp nhận đánh đổi số lượng công việc triển khai song song để đổi lấy tốc độ hoàn thành dứt điểm của từng dòng giá trị. Điều kiện đảo chiều của nguyên lý này nằm ở mức độ ổn định của môi trường pháp lý và công nghệ: nếu môi trường biến động liên tục với tần suất cao, việc thu hẹp quy mô công việc dở dang phải diễn ra nhanh hơn nữa để tránh việc sản phẩm làm ra bị lỗi thời trước khi kịp bàn giao.
Các việc cần làm phân theo vai trò trong quản lý thực thi dự án:
– Người bảo trợ dự án: Phê duyệt giới hạn công việc dở dang cho từng giai đoạn, bảo vệ đội ngũ khỏi các yêu cầu thay đổi phạm vi ngoài quy trình đã thống nhất.
– Quản lý dự án: Theo dõi sát sao biểu đồ dòng chảy công việc, chủ động phát hiện và xử lý điểm nghẽn trước khi chúng làm ùn tắc toàn bộ hệ thống.
– Chủ sở hữu sản phẩm: Sắp xếp thứ tự ưu tiên tuyệt đối cho danh sách yêu cầu công việc, đảm bảo đội ngũ chỉ tập trung làm những việc mang lại giá trị cao nhất.
– Đội ngũ thực hiện: Cam kết không nhận thêm việc mới khi các giới hạn công việc dở dang ở bước hiện tại đã đạt ngưỡng tối đa cho phép.
Các câu hỏi tự kiểm tra năng lực tối ưu hóa hoạt động và loại bỏ lãng phí:
– Làm thế nào để chứng minh rằng việc dừng một hoạt động đang làm sẽ giúp toàn bộ dự án hoàn thành nhanh hơn?
– Dấu hiệu nào trên bảng điều khiển dòng công việc cho biết hệ thống đang bị quá tải ở tầng trung gian thay vì thiếu nhân lực?
– Khi các bên liên quan yêu cầu bổ sung thêm tính năng vào giữa giai đoạn thực hiện, cơ chế ra quyết định nào được dùng để bảo vệ tốc độ dòng chảy mà không làm mất lòng khách hàng?
– Làm thế nào để phân biệt chính xác giữa một hoạt động tạo ra giá trị thực sự cho người dùng cuối và một hoạt động chỉ mang tính hình thức để làm đẹp báo cáo tiến độ?
#QuanLyDuAn #Lean #Kanban #ThuyetRangBuoc #ToanHieuSuat #GiamLangPhi
