Skip to content
Nhiều người vẫn tin rằng một dự án hoàn thành đúng hạn, không vượt ngân sách và bàn giao đủ các tính năng đã cam kết trên hợp đồng là một dự án thành công. Niềm tin này sai, bởi một hệ thống có thể hoạt động hoàn hảo ở từng phần nhỏ nhưng lại tạo ra một sản phẩm cuối cùng không ai dùng đến hoặc không mang lại dòng tiền thực tế cho doanh nghiệp.
Biến sai lầm thành tài sản tri thức – 0276
Để 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 là phải tối ưu hóa toàn bộ dòng chảy công việc từ đầu đến cuối thay vì cố gắng đẩy nhanh tốc độ của từng bộ phận riêng lẻ. Luận điểm này chỉ đúng khi tổ chức có quyền lực tập trung đủ để phá vỡ các rào cản phòng ban; nếu cơ cấu quản lý vẫn bị chia cắt theo chức năng theo chiều dọc, việc tối ưu hóa toàn hệ thống sẽ tạo ra xung đột lợi ích gay gắt và thất bại. Luận điểm này sẽ sai nếu doanh nghiệp hoạt động trong môi trường có tính tuân thủ pháp lý cực kỳ khắt khe, nơi việc chia nhỏ quy trình thành các bước kiểm soát độc lập là bắt buộc để tránh rủi ro pháp lý, dù điều đó làm chậm tốc độ tổng thể.
Hiện trường đặt ra cho một người quản lý bàn giao dự án hoặc quản lý xuất sắc vận hành là áp lực dồn dập từ việc các phòng ban liên tục than phiền về năng lực thực thi chậm trễ. Bộ phận phát triển sản phẩm báo cáo họ làm việc cật lực ngày đêm nhưng sản phẩm vẫn không kịp ra mắt thị trường. Bộ phận kinh doanh thúc ép đòi thêm tính năng mới vì đối thủ vừa tung ra sản phẩm cạnh tranh. Ban giám đốc thì yêu cầu cắt giảm chi phí vận hành trong khi khối lượng công việc tăng lên. Người quản lý bị kẹt ở giữa, buộc phải tìm cách tăng tốc độ mà không có thêm nguồn lực, trong khi các bộ phận bên dưới vẫn giữ nguyên cách làm việc cũ, mỗi nơi tự giam mình trong một ốc đảo riêng biệt và chỉ quan tâm đến chỉ số hiệu suất cá nhân của đơn vị mình.
Sai lầm phổ biến nhất trong tình huống này là tối ưu từng bộ phận thay vì toàn hệ thống, dẫn đến việc nhà quản lý áp dụng các biện pháp cải tiến cục bộ như bắt đội ngũ lập trình làm việc tăng ca để tăng tốc độ viết mã, hoặc yêu cầu đội ngũ kiểm tra chất lượng làm việc nhanh hơn gấp đôi. Sai lầm này hình thành vì nó mang lại ảo tưởng về quyền lực và sự kiểm soát ngắn hạn, dễ dàng báo cáo với cấp trên rằng mọi bộ phận đều đang chạy hết công suất. Người đứng đầu từng phòng ban rất ủng hộ cách làm này vì nó bảo vệ thành tích của đơn vị họ trên giấy, khiến họ trông có vẻ hiệu quả. Tuy nhiên, cái giá phải trả là sự tắc nghẽn chuyển dời từ điểm này sang điểm khác: đội lập trình viết mã nhanh hơn chỉ làm cho kho chứa mã nguồn ùn ứ thêm vì đội kiểm tra chất lượng không thể xử lý kịp lượng công việc khổng lồ đổ dồn về, tạo ra các lỗi ẩn sâu hơn và buộc phải sửa đi sửa lại nhiều lần, làm tổng thời gian hoàn thành sản phẩm thực tế dài ra chứ không hề ngắn lại.
Để mổ xẻ vấn đề này dưới góc độ năng suất và dòng chảy công việc, cần nhìn nhận đơn vị phân tích ở đây là dòng công việc trải dài từ khi ý tưởng hình thành cho đến khi giá trị được chuyển giao đến tay người sử dụng cuối cùng. Theo các nguyên lý về dòng chảy và lý thuyết giới hạn, một hệ thống sản xuất hay triển khai dự án luôn bị chi phối bởi điểm nghẽn hẹp nhất của nó. Khi một bộ phận hoạt động với công suất vượt quá năng lực tiếp nhận của điểm nghẽn tiếp theo, lượng công việc tồn đọng tăng lên, thời gian chờ đợi kéo dài và lãng phí phát sinh dưới dạng các công việc dang dở nằm chờ xử lý.
Ví dụ minh họa cụ thể về dòng công việc này được thể hiện qua thời gian dẫn xuất của một yêu cầu tính năng sản phẩm. Giả định dòng công việc gồm bốn bước: phân tích nghiệp vụ, lập trình, kiểm tra chất lượng, và triển khai. Bước phân tích nghiệp vụ tiếp nhận một trăm yêu cầu mỗi tháng nhưng chỉ xử lý xong năm mươi yêu cầu. Bước lập trình có năng lực xử lý tám mươi yêu cầu mỗi tháng. Bước kiểm tra chất lượng chỉ xử lý được bốn mươi yêu cầu mỗi tháng do thiếu nhân sự tự động hóa kiểm thử. Bước triển khai xử lý được một trăm yêu cầu mỗi tháng. Điểm nghẽn của hệ thống nằm ở bước kiểm tra chất lượng với công suất bốn mươi yêu cầu mỗi tháng. Nếu người quản lý dồn ngân sách để tăng tốc độ lập trình lên một trăm hai mươi yêu cầu mỗi tháng, hệ thống không những không nhanh hơn mà còn tệ hơn. Tồn đọng tại bước kiểm tra chất lượng sẽ phình to gấp ba lần, thời gian chờ đợi tăng vọt, các lỗi phần mềm bị bỏ sót nhiều hơn do áp lực kiểm tra vội vàng, và chi phí sửa lỗi sau khi phát hành tăng theo cấp số nhân. Toàn bộ hệ thống bị kéo tụt lại phía sau chỉ vì cố tối ưu hóa sai chỗ.
Hệ quả hệ thống của việc tối ưu cục bộ bắt đầu lộ diện sau khoảng ba đến sáu tháng triển khai. Dấu hiệu sớm là các chỉ số hiệu suất của từng phòng ban đều màu xanh hoàn hảo, nhưng thời gian từ lúc khách hàng yêu cầu tính năng đến lúc nhận được sản phẩm thực tế lại kéo dài thêm năm mươi phần trăm. Chi phí phát sinh do phải làm lại công việc tăng cao, tỷ lệ rời bỏ của khách hàng nhích lên vì sản phẩm giao chậm và chứa nhiều lỗi. Khi ban giám đốc yêu cầu giải trình, các trưởng bộ phận đều đổ lỗi cho nhau: bộ phận kỹ thuật nói họ đã hoàn thành nhiệm vụ đúng hạn, bộ phận kiểm tra chất lượng kêu ca quá tải, còn bộ phận kinh doanh phàn nàn sản phẩm không đáp ứng nhu cầu thị trường.
Để giải quyết triệt để tình trạng này, quyết định đúng đắn đòi hỏi nhà quản lý phải từ bỏ cách quản lý theo từng phòng ban chức năng rời rạc để chuyển sang quản lý theo dòng giá trị.
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 quản trị | Ngưỡng kích hoạt | Người chịu đánh đổi |
|—|—|—|—|
| Tồn đọng tại một bước vượt quá hai tuần làm việc | Dừng nhận việc mới, chuyển toàn bộ nhân lực dư thừa sang hỗ trợ điểm nghẽn | Khối lượng công việc chờ xử lý tại một khâu lớn hơn 150% công suất tháng | Trưởng bộ phận không phải điểm nghẽn (phải chịu cảnh nhân sự bị điều động tạm thời) |
| Tỷ lệ lỗi phát sinh sau khi bàn giao vượt mức cho phép | Kéo dài thời gian kiểm tra, siết chặt tiêu chí chấp nhận đầu ra | Tỷ lệ lỗi nghiệm thu vượt quá 5% tổng số hạng mục bàn giao | Bộ phận kinh doanh và khách hàng (phải chờ đợi lâu hơn để nhận tính năng) |
| Chi phí phát sinh do làm lại vượt ngưỡng ngân sách dự phòng | Đóng băng các hạng mục mở rộng phạm vi, tập trung hoàn thiện hạng mục cốt lõi | Chi phí làm lại chạm mốc 10% tổng ngân sách giai đoạn | Đội ngũ phát triển (mất cơ hội thử nghiệm các tính năng phụ trợ mới) |
Bảng trên giúp người quản lý quyết định khi nào cần dừng việc mở rộng quy mô để tập trung giải quyết triệt để các điểm nghẽn hiện hữu thay vì tiếp tục bơm nguồn lực vào những chỗ không cần thiết.
Mục tiêu học tập đầu tiên là loại bỏ lãng phí. Lãng phí trong môi trường thực thi dự án không chỉ là tiền bạc bị vứt qua cửa sổ mà là thời gian chết, là việc làm ra những tính năng không ai dùng, và là công việc phải làm đi làm lại nhiều lần. Ví dụ, một đội ngũ phần mềm dành ba tháng để phát triển một báo cáo tài chính phức tạp theo yêu cầu của một nhóm người dùng, nhưng khi ra mắt thì không ai sử dụng vì họ đã quen dùng bảng tính cá nhân. Đó là lãng phí do sản xuất thừa. Để loại bỏ, mọi yêu cầu tính năng trước khi đưa vào lịch trình thực hiện đều phải đi qua một bộ lọc xác thực nhu cầu thực tế từ người dùng cuối, thay vì chỉ dựa vào mệnh lệnh của một cấp quản lý phòng ban nào đó.
Mục tiêu học tập thứ hai là tăng tốc độ. Tăng tốc độ không có nghĩa là bắt mọi người làm việc nhanh hơn đến mức kiệt sức, mà là rút ngắn thời gian một đơn vị công việc di chuyển qua toàn bộ hệ thống từ đầu đến cuối. Ví dụ, một dự án triển khai hệ thống quản lý kho thường mất sáu tháng để hoàn thành. Bằng cách chia nhỏ dự án thành các gói bàn giao giá trị theo từng kho hàng riêng lẻ thay vì chờ làm xong toàn bộ hệ thống mới đưa vào vận hành, đội ngũ có thể đưa kho hàng trung tâm đi vào hoạt động chỉ sau bốn tuần. Tốc độ quay vòng vốn và tốc độ nhận phản hồi từ thực tế được đẩy lên gấp nhiều lần, giúp điều chỉnh ngay các sai sót trước khi chúng lan rộng ra toàn hệ thống.
Mục tiêu học tập thứ ba là tăng năng suất. Năng suất thực chất là tỷ lệ giữa giá trị thực tế tạo ra so với nguồn lực tiêu tốn. Ví dụ, một đội ngũ mười người nếu làm việc trong cơ chế phân mảnh, mỗi người làm một góc không liên quan đến nhau, sẽ tạo ra rất ít sản phẩm hoàn chỉnh vì thiếu sự đồng bộ khi ghép nối. Khi tổ chức lại thành một đội ngũ đa chức năng, nơi lập trình viên, kiểm thử viên và chuyên gia nghiệp vụ ngồi chung một nhóm và chịu chung một mục tiêu bàn giao, năng suất tổng thể tăng lên vì thời gian chờ đợi giữa các bước bị triệt tiêu hoàn toàn.
Để đo lường và theo dõi các cải tiến này, mẫu sản phẩm hiệu suất vượt trội dưới đây cung cấp một khung làm việc rõ ràng cho người quản lý vận hành.
Mẫu sản phẩm Hiệu suất vượt trội (Bảng kiểm tra dòng chảy công việc):
| Bước công việc | Thời gian xử lý thực tế (ngày) | Thời gian chờ đợi (ngày) | Tỷ lệ lỗi phát sinh (%) | Hành động tối ưu cần làm ngay |
|—|—|—|—|—|
| Tiếp nhận và phân tích yêu cầu | 3 | 5 | 10 | Chuẩn hóa mẫu mô tả yêu cầu, loại bỏ yêu cầu mơ hồ |
| Thiết kế giải pháp kỹ thuật | 5 | 8 | 15 | Tổ chức họp xem xét chéo giữa các bên liên quan trước khi chốt |
| Triển khai và lập trình mã nguồn | 10 | 12 | 8 | Áp dụng kiểm tra mã nguồn tự động trước khi chuyển giao |
| Kiểm tra chất lượng và thử nghiệm | 4 | 15 | 25 | Bổ sung nhân sự hỗ trợ từ bước thiết kế sang kiểm thử |
| Bàn giao và đưa vào vận hành | 2 | 3 | 2 | Lập biên bản nghiệm thu lợi ích kinh doanh sau 30 ngày |
Cách điền mẫu này rất đơn giản: định kỳ hàng tuần, người quản lý ghi nhận lại số liệu thực tế tại từng bước công việc của một nhóm tác nghiệp tiêu biểu. Cách đọc mẫu đòi hỏi phải nhìn vào cột thời gian chờ đợi và tỷ lệ lỗi. Nếu thời gian chờ đợi ở bất kỳ bước nào cao hơn gấp đôi thời gian xử lý thực tế, đó chính là điểm nghẽn nghiêm trọng cần được giải tỏa ngay lập tức bằng cách điều chuyển nguồn lực. Nếu tỷ lệ lỗi vượt quá mười phần trăm, bước trước đó đang thả lỏng tiêu chuẩn chất lượng đầu ra và cần phải được siết chặt lại quy trình kiểm tra tại chỗ.
Bảng dấu hiệu sớm và rủi ro trong quản lý dòng công việc:
| Dấu hiệu sớm | Cơ chế hình thành | Hậu quả nếu bỏ qua | Phản ứng quản trị cần thiết |
|—|—|—|—|
| Báo cáo tiến độ tuần nào cũng xanh nhưng không có sản phẩm bàn giao thực tế | Các đội ngũ báo cáo dựa trên số lượng công việc đã bắt đầu thay vì số lượng giá trị đã hoàn thành | Dự án rơi vào trạng thái cạn kiệt ngân sách khi chỉ còn vài tuần nữa là đến hạn chót nhưng không thể nghiệm thu | Đổi mới định nghĩa hoàn thành, chỉ ghi nhận tiến độ khi sản phẩm đã qua kiểm tra chất lượng và sẵn sàng sử dụng |
| Số lượng lỗi phần mềm phát sinh tăng vọt sau mỗi đợt phát hành | Đội ngũ kỹ thuật chạy đua theo thời hạn tiến độ mà cắt giảm các bước kiểm tra cơ bản | Khách hàng từ chối sử dụng hệ thống, uy tín của đơn vị triển khai bị suy giảm nghiêm trọng | Tạm dừng nhận yêu cầu mới, bắt buộc sửa triệt để các lỗi tồn đọng trước khi phát hành tính năng tiếp theo |
| Các phòng ban chức năng từ chối chia sẻ nhân sự hỗ trợ qua lại khi có điểm nghẽn | Chỉ tiêu đánh giá hiệu quả cá nhân của từng trưởng phòng gắn chặt với thành tích cục bộ của bộ phận mình | Hệ thống chung bị tắc nghẽn, các dự án chiến lược chậm tiến độ diện rộng | Thay đổi cơ chế đánh giá thành tích từ cấp phòng ban sang mức độ đóng góp vào thành công chung của dòng giá trị |
Bảng này giúp người quản lý nhận diện sớm các nguy cơ ngầm trước khi chúng bùng phát thành khủng hoảng toàn hệ thống, từ đó có cơ sở pháp lý và logic để yêu cầu các bên liên quan thay đổi cách phối hợp.
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 doanh nghiệp tài chính triển khai dự án nâng cấp hệ thống giao dịch trực tuyến với ngân sách lớn. Người quản lý dự án áp dụng mô hình quản lý theo tiến độ truyền thống, chia dự án thành các giai đoạn riêng biệt: sáu tháng phân tích, sáu tháng thiết kế, sáu tháng lập trình và ba tháng kiểm thử. Trong suốt hai năm triển khai, mọi báo cáo gửi lên ban giám đốc đều cho thấy tiến độ màu xanh vì các giai đoạn đều hoàn thành đúng thời hạn trên giấy. Tuy nhiên, đến giai đoạn kiểm thử tổng thể vào tháng thứ hai mươi tư, thị trường đã thay đổi hoàn toàn, các quy định pháp lý mới được ban hành và nhu cầu của khách hàng đã dịch chuyển sang nền tảng di động thay vì website truyền thống. Hệ thống khi ra mắt không thể sử dụng được, toàn bộ chi phí đầu tư hàng chục tỷ đồng trở thành khoản lỗ không thu hồi. Sai lầm xuất phát từ việc tư duy hoàn thành dự án là thành công theo từng mốc thời gian trên giấy mà không quan tâm đến việc giá trị kinh doanh có còn phù hợp với thực tế hay không.
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ập đoàn bán lẻ quyết định tái cấu trúc dòng công việc bằng cách áp dụng phương pháp quản lý dòng chảy liên tục, từ bỏ cách làm việc qua lại bằng văn bản giữa các phòng ban. Người quản lý dự án quyết định dừng toàn bộ các dự án phát triển tính năng mới trong vòng một tháng để tập trung toàn lực giải quyết dứt điểm lượng công việc đang tồn đọng tại kho chứa dữ liệu khách hàng. Ngay lập tức, các giám đốc kinh doanh phản đối gay gắt vì cho rằng quyết định này làm gián đoạn các chiến dịch bán hàng đã lên lịch sẵn, làm họ mất cơ hội doanh thu ngắn hạn. Người quản lý phải chịu áp lực cực lớn từ ban điều hành, phải đứng ra giải trình và chấp nhận đánh đổi sự bất mãn trước mắt của khối kinh doanh để lấy sự ổn định và tốc độ bứt phá dài hạn của toàn hệ thống. Kết quả sau đó là thời gian đưa một chương trình khuyến mãi mới ra thị trường giảm từ sáu mươi ngày xuống còn bảy ngày, doanh thu tăng trưởng vượt bậc trong các quý tiếp theo, chứng minh rằng cái giá phải trả cho việc dừng lại tối ưu hóa là hoàn toàn xứng đáng.
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 liên tục đo lường dòng chảy công việc, chủ động tìm kiếm và giải tỏa điểm nghẽn hẹp nhất, từ bỏ tư duy tối ưu hóa từng bộ phận rời rạc để chuyển sang tối ưu hóa toàn bộ hệ thống giá trị. Điều kiện đảo chiều của nguyên tắc này là khi cấu trúc pháp lý hoặc hợp đồng ràng buộc chặt chẽ buộc phải tuân thủ quy trình nhiều bước không thể cắt giảm, hoặc khi năng lực của đội ngũ chưa đủ trưởng thành để tự quản lý công việc mà cần có sự giám sát phân tầng nghiêm ngặt.
Các việc cần làm phân theo vai trò cụ thể:
– Người bảo trợ dự án: Phê duyệt việc thay đổi cơ chế đánh giá thành tích từ cấp phòng ban sang đóng góp vào dòng giá trị chung; đứng ra bảo vệ đội ngũ trước áp lực ngắn hạn của các bên liên quan khi thực hiện tái cấu trúc dòng công việc.
– Người quản lý dự án hoặc điều phối vận hành: Trực tiếp xây dựng và duy trì bảng kiểm tra dòng chảy công việc; định kỳ hàng tuần rà soát thời gian chờ đợi và chủ động điều phối nhân sự để giải tỏa điểm nghẽn.
– Chủ sở hữu sản phẩm: Chịu trách nhiệm xác thực và sắp xếp thứ tự ưu tiên các yêu cầu tính năng dựa trên giá trị thực tế mang lại cho người dùng cuối; kiên quyết từ bỏ các yêu cầu không mang lại giá trị gia tăng rõ ràng.
– Đội ngũ thực hiện trực tiếp: Tuân thủ nghiêm ngặt định nghĩa hoàn thành của từng bước công việc; chủ động báo cáo ngay khi phát hiện lượng công việc tồn đọng vượt ngưỡng để được hỗ trợ kịp thời.
Câu hỏi tự kiểm tra dành cho người đọc:
1. Điểm nghẽn hiện tại trong dòng công việc của bạn nằm ở khâu nào, và bạn dùng số liệu gì để chứng minh đó là điểm nghẽn chứ không phải cảm tính?
2. Nếu bạn buộc phải dừng ngay lập tức một bộ phận đang hoạt động rất tích cực để giải cứu cho một khâu khác đang bị ùn tắc, bạn sẽ căn cứ vào tiêu chí nào để đưa ra quyết định đó?
3. Định nghĩa hoàn thành công việc của đội ngũ bạn hiện nay có gắn liền với giá trị thực tế mà khách hàng nhận được, hay chỉ dừng lại ở việc bàn giao tài liệu và mã nguồn cho bộ phận tiếp theo?
4. Đâu là khoản lãng phí lớn nhất về thời gian trong quy trình triển khai dự án hiện tại của bạn, và bạn đã sẵn sàng đánh đổi điều gì để loại bỏ nó?
