Skip to content
Nhiều người tin rằng để dự án chạy nhanh hơn và ra kết quả tốt hơn, cần phải thúc ép từng bộ phận làm việc cật lực hơn, theo dõi sát sao từng đầu việc hàng ngày và liên tục yêu cầu báo cáo tiến độ chi tiết. Niềm tin này sai. Tăng tốc độ và cải tiến hiệu suất thực thi không đến từ việc bắt mọi người làm nhanh hơn ở từng ô công việc rời rạc, mà đến từ việc làm cho toàn bộ dòng chảy công việc di chuyển mượt mà qua các điểm nghẽn của hệ thống.
Chu trình học hỏi và cải tiến là cơ chế phản hồi liên tục giúp tổ chức nhận diện sự chậm trễ, loại bỏ các bước không tạo ra giá trị và điều chỉnh năng lực thực thi trước khi các vấn đề nhỏ kịp hóa thành thảm họa tài chính. Trong thực tế điều hành, hệ thống thường kẹt không phải vì nhân sự lười biếng, mà vì mỗi bộ phận tối ưu hóa cục bộ hiệu suất của riêng mình, vô tình bóp nghẹt dòng chảy chung của toàn dự án.
Hiện trường điển hình tại một doanh nghiệp đang triển khai dự án công nghệ lớn: nhóm phát triển phần mềm hoàn thành khối lượng tính năng khổng lồ mỗi tuần và báo cáo chỉ số hoàn thành đạt một trăm phần trăm. Tuy nhiên, nhóm kiểm định chất lượng bị ngập lụt trong biển lỗi, thời gian chờ để đưa một tính năng lên môi trường thử nghiệm kéo dài ba tuần, còn bộ phận vận hành thì từ chối tiếp nhận sản phẩm vì không tương thích với hạ tầng cũ. Người quản lý giao nhận và quản lý xuất sắc vận hành đang đứng giữa dòng rác thải tiến độ: ngân sách tiêu hao theo đúng kế hoạch giải ngân, các báo cáo gửi lên ban điều hành hàng tuần đều tô màu xanh, nhưng sản phẩm cuối cùng vẫn nằm bất động trên máy chủ nội bộ, chưa từng chạm tay khách hàng.
Sai lầm phổ biến hình thành từ tư duy tối ưu từng bộ phận thay vì toàn hệ thống. Tư duy này rất hợp lý khi mới nhìn vào bảng lương và khối lượng công việc: nhà quản lý muốn mỗi cá nhân và mỗi phòng ban đều bận rộn một trăm phần trăm thời gian để không lãng phí chi phí nhân sự. Bộ phận lập trình hoạt động hết công suất để tạo ra hàng ngàn dòng mã lệnh, bộ phận thiết kế sản xuất ra hàng trăm bản vẽ giao diện, và phòng mua sắm đàm phán được hợp đồng giá rẻ nhất cho từng linh kiện riêng lẻ. Các trưởng bộ phận đều mừng vì các chỉ số hiệu suất cá nhân và phòng ban đều đạt mức tối ưu (minh họa). Hậu quả theo chuỗi bắt đầu xuất hiện khi lượng công việc dở dang ùn ứ tại ranh giới giữa các phòng ban, tạo ra những kho chứa khổng lồ các sản phẩm chưa được kiểm định hoặc chưa được phê duyệt, khiến vốn bị giam cầm và thời gian đưa sản phẩm ra thị trường kéo dài gấp ba lần dự kiến (quan sát nghề nghiệp).
Để trả lời cho câu hỏi trung tâm làm thế nào để tạo ra kết quả nhanh hơn và tốt hơn, phương pháp tiếp cận đúng đắn là quản trị dòng công việc thông qua việc đo lường và giới hạn lượng công việc dở dang trên toàn bộ hệ thống, thay vì đo lường năng suất đơn lẻ của từng cá nhân hay phòng ban. Luận đề trung tâm của việc tăng tốc độ và cải tiến hiệu suất là: Tốc độ thực thi tổng thể của một dự án bị chi phối hoàn toàn bởi điểm nghẽn hạn chế năng lực lớn nhất của toàn hệ thống, và mọi nỗ lực tăng tốc ở các khâu không phải điểm nghẽn đều chỉ làm tăng lượng hàng tồn đọng và lãng phí nguồn lực. Điều kiện đảo chiều của luận điểm này là khi hệ thống chuyển sang trạng thái dư thừa năng lực xử lý ở mọi khâu và vấn đề duy nhất là thiếu vốn đầu tư ban đầu hoặc thiếu nhân sự tổng thể, khi đó tốc độ phụ thuộc vào quy mô nhân lực chứ không phải dòng chảy (giả định).
Xét về mục tiêu loại bỏ lãng phí, theo các khung quản lý tinh gọn (Lean) và dòng chảy giá trị (Kanban), lãng phí lớn nhất không phải là nhân viên ngồi chơi, mà là thời gian chờ đợi giữa các công đoạn và việc sản xuất ra những tính năng không ai cần đến. Ví dụ thực tế: một đội ngũ lập trình mất ba tuần để viết ra một mô-đun phân tích báo cáo phức tạp mà không có yêu cầu thực tế từ người dùng cuối, chỉ vì hiểu lầm tài liệu mô tả ban đầu; khi bàn giao, sản phẩm bị loại bỏ hoàn toàn, lãng phí toàn bộ chi phí nhân công và thời gian của mười kỹ sư trong ba tuần đó (minh họa). Để loại bỏ lãng phí này, tổ chức phải áp dụng nguyên tắc sản xuất theo nhu cầu kéo thực tế thay vì đẩy công việc xuống hệ thống theo kế hoạch cứng nhắc.
Xét về mục tiêu tăng tốc độ, theo lý thuyết về ràng buộc (Theory of Constraints), việc đẩy nhanh tốc độ thực thi đòi hỏi phải tìm ra chính xác khâu nào đang chậm nhất trong toàn bộ chuỗi giá trị từ ý tưởng đến tay người dùng, sau đó tập trung toàn bộ nguồn lực tăng cường cho khâu đó. Ví dụ minh họa: trong một chu trình phát triển sản phẩm kéo dài mười tuần, nếu khâu kiểm định an toàn thông tin chỉ có duy nhất một chuyên gia phụ trách và mất tới sáu tuần để xét duyệt, thì việc tuyển thêm năm lập trình viên giỏi để viết mã nhanh hơn hoàn toàn vô nghĩa và chỉ làm tăng thêm đống hồ sơ chờ duyệt trên bàn của chuyên gia bảo mật đó. Tốc độ của toàn bộ dự án chỉ tăng lên khi năng lực của khâu kiểm định an toàn thông tin được mở rộng, chẳng hạn bằng cách tự động hóa quy trình kiểm tra hoặc đào tạo thêm nhân sự phụ trợ.
Xét về mục tiêu tăng năng suất, năng suất thực thi không được tính bằng số lượng dòng mã lệnh viết ra hay số lượng tài liệu được đóng dấu phê duyệt, mà tính bằng tốc độ chuyển hóa từ vốn đầu tư thành giá trị kinh doanh có thể đo lường. Ví dụ minh họa: một đội ngũ phát hành phần mềm thay vì dồn mọi tính năng vào một đợt phát hành lớn kéo dài sáu tháng với rủi ro sụp đổ cao, họ chia nhỏ thành các gói giá trị giao hàng mỗi hai tuần; cách làm này giúp phát hiện lỗi từ sớm, giảm chi phí sửa chữa xuống mười lần so với việc để lỗi tích tụ đến cuối dự án, và cho phép doanh nghiệp thu hồi vốn nhanh hơn từ những tính năng cốt lõi đã đưa vào khai thác thương mại (quan sát nghề nghiệp).
Mổ xẻ sâu hơn vào cơ chế vận hành của dòng công việc, năng suất hệ thống được điều phối qua hai chỉ số cốt lõi: thời gian chu kỳ và lượng công việc dở dang. Thời gian chu kỳ là khoảng thời gian tính từ lúc một yêu cầu công việc bắt đầu được đưa vào xử lý cho đến khi nó được bàn giao thành công cho người thụ hưởng. Lượng công việc dở dang là tổng số lượng các hạng mục đang nằm trong hệ thống nhưng chưa hoàn thành.
Công thức quản lý dòng chảy cơ bản dựa trên định luật Little (Little’s Law) trong quản trị vận hành: Thời gian chu kỳ bằng lượng công việc dở dang chia cho năng suất thông lượng của hệ thống.
– Giả định: Năng suất thông lượng duy trì ổn định ở mức mười hạng mục hoàn thành mỗi tuần.
– Nếu lượng công việc dở dang bị thả nổi ở mức năm mươi hạng mục, thời gian chu kỳ trung bình cho một hạng mục sẽ là năm mươi chia cho mười, bằng năm tuần.
– Nếu nhà quản lý can thiệp bằng cách áp dụng giới hạn lượng công việc dở dang, buộc hệ thống chỉ được phép chứa tối đa mười hạng mục cùng một thời điểm, thì thời gian chu kỳ sẽ giảm xuống còn mười chia cho mười, bằng một tuần.
Kết quả minh họa này chứng minh rằng việc cố gắng làm nhiều việc cùng lúc không làm tăng năng suất, mà làm chậm gấp năm lần thời gian đưa sản phẩm hoàn chỉnh ra thực tế, đồng thời làm tăng tỷ lệ làm lại do bối cảnh liên tục bị chuyển đổi giữa các nhiệm vụ khác nhau.
Hệ quả hệ thống của việc không kiểm soát dòng công việc sẽ lan rộng ra toàn bộ các cấp quản lý cao hơn. Ở cấp dự án, việc ùn ứ công việc làm gia tăng chi phí nhân sự do thời gian chờ đợi và làm lại. Khi tiến độ chậm dần, áp lực dồn lên vai người quản lý dự án, dẫn đến việc họ cắt giảm các bước kiểm định chất lượng để kịp thời hạn cam kết trên giấy. Ở cấp chương trình, các dự án thành phần liên tục báo cáo sai lệch trạng thái thực tế, khiến cho việc điều phối nguồn lực chung trở nên hỗn loạn; chương trình không thể bàn giao các lợi ích chiến lược đúng hạn vì phụ thuộc vào những đầu ra chưa hoàn chỉnh từ các dự án con. Ở cấp danh mục đầu tư, ban lãnh đạo cấp cao đưa ra các quyết định phân bổ vốn sai lầm, tiếp tục rót tiền vào những dự án đang bị kẹt ở điểm nghẽn thay vì dừng chúng lại để giải phóng nguồn lực cho những sáng kiến có khả năng tạo ra dòng tiền tốt hơn. Tư duy “hoàn thành dự án là thành công” che giấu đi sự thật rằng dự án đã hoàn thành các mốc kỹ thuật trên giấy nhưng không tạo ra bất kỳ lợi ích kinh doanh nào, vì sản phẩm làm ra không phù hợp với nhu cầu thực tế của thị trường tại thời điểm bàn giao.
Để áp dụng cơ chế cải tiến liên tục vào thực tế điều hành, người làm quản lý giao nhận và quản lý xuất sắc vận hành cần sử dụng các công cụ cấu trúc rõ ràng. Dưới đây là Mẫu sản phẩm Hiệu suất vượt trội, thiết kế dưới dạng bảng kiểm soát dòng công việc, dùng để theo dõi, phát hiện điểm nghên và đưa ra quyết định điều chỉnh hàng tuần.
<table border=”1″ style=”width:100%; border-collapse: collapse; text-align: left;”><tr><th>Giai đoạn dòng công việc</th><th>Số lượng hạng mục hiện tại</th><th>Giới hạn tối đa cho phép</th><th>Thời gian chờ trung bình (ngày)</th><th>Trạng thái nghẽn hệ thống</th></tr><tr><td>Ý tưởng & Phân tích nghiệp vụ</td><td>25</td><td>10</td><td>14</td><td>Quá tải / Cần dừng tiếp nhận mới</td></tr><tr><td>Thiết kế giải pháp kỹ thuật</td><td>18</td><td>15</td><td>8</td><td>Cảnh báo / Đang ùn ứ nhẹ</td></tr><tr><td>Phát triển mã nguồn</td><td>12</td><td>20</td><td>3</td><td>Bình thường / Còn dư năng lực</td></tr><tr><td>Kiểm định & Thử nghiệm</td><td>35</td><td>10</td><td>21</td><td>Điểm nghẽn nghiêm trọng</td></tr><tr><td>Chờ phát hành thương mại</td><td>8</td><td>5</td><td>5</td><td>Cảnh báo / Chờ phê duyệt cấp cao</td></tr></table>
Hướng dẫn cách điền và cách đọc mẫu sản phẩm hiệu suất vượt trội:
– Cột Giai đoạn dòng công việc liệt kê toàn bộ các bước mà một đơn vị công việc phải đi qua từ khi khởi tạo đến khi hoàn thành bàn giao.
– Cột Số lượng hạng mục hiện tại ghi nhận tổng số lượng công việc đang thực tế nằm trong giai đoạn đó tại thời điểm kiểm tra.
– Cột Giới hạn tối đa cho phép là con số cố định do đội ngũ tự thỏa thuận, thể hiện sức chứa tối đa của giai đoạn đó trước khi hệ thống bị quá tải.
– Cột Thời gian chờ trung bình đo lường số ngày một hạng mục phải nằm chờ tại giai đoạn đó trước khi được xử lý tiếp.
– Cột Trạng thái nghẽn hệ thống được tự động xác định dựa trên việc so sánh số lượng hiện tại với giới hạn cho phép.
– Cách đọc bảng để ra quyết định: Quan sát ngay lập tức các dòng có trạng thái quá tải nghiêm trọng (như giai đoạn Kiểm định và Thử nghiệm trong bảng minh họa, với 35 hạng mục trên giới hạn 10 và thời gian chờ lên tới 21 ngày). Quyết định quản trị bắt buộc phải đưa ra ngay lập tức tại đây: tuyệt đối không được phép đẩy thêm bất kỳ công việc mới nào từ giai đoạn trước xuống cho đến khi lượng hạng mục tồn đọng tại khâu kiểm định giảm xuống dưới mức giới hạn mười. Mọi nguồn lực rảnh rỗi từ các khâu khác (như lập trình viên ở giai đoạn phát triển mã nguồn) phải được điều động tạm thời sang hỗ trợ khâu kiểm định để giải tỏa điểm nghẽn.
Để minh họa cách vận hành này trong thực tế, dưới đây là hai tình huống tổng hợp (số liệu minh họa).
Tình huống làm sai và hệ quả: Một tổ chức tài chính triển khai dự án nâng cấp hệ thống thanh toán trực tuyến. Người quản lý dự án áp dụng cách tiếp cận truyền thống: chia dự án thành các giai đoạn tuần tự kéo dài sáu tháng, bắt buộc mọi phòng ban phải hoàn thành một trăm phần trăm khối lượng công việc của giai đoạn trước mới được chuyển sang giai đoạn sau. Khi đến mốc tháng thứ năm, bộ phận kiểm thử phát hiện lỗi tích hợp nghiêm trọng với hệ thống lõi cũ do các kỹ sư ở giai đoạn đầu đã tự ý thay đổi cấu trúc dữ liệu mà không thông báo. Để giữ đúng cam kết tiến độ ban đầu với ban tổng giám đốc, người quản lý ra lệnh cho toàn bộ đội ngũ làm việc tăng ca liên tục ngày đêm, cắt bỏ toàn bộ các bước kiểm tra bảo mật cuối cùng để kịp ngày phát hành. Hệ quả: ngay trong ngày đầu tiên đưa lên môi trường thật, hệ thống sập toàn bộ, gây gián đoạn giao dịch của hàng trăm ngàn khách hàng, khiến doanh nghiệp chịu tổn thất tài chính khổng lồ, bị cơ quan quản lý nhà nước nhắc nhở và mất sáu tháng sau đó chỉ để vá lỗi và khôi phục lòng tin của thị trường.
Tình huống làm đúng nhưng phải trả giá trước mắt: Một doanh nghiệp bán lẻ tái cấu trúc quy trình phát triển sản phẩm kỹ thuật số bằng cách áp dụng triệt để nguyên tắc giới hạn công việc dở dang và chia nhỏ chu kỳ phát hành thành các gói giá trị giao hàng mỗi tuần. Khi mới áp dụng tuần đầu tiên, năng suất hiển thị trên báo cáo giảm mạnh bốn mươi phần trăm vì các lập trình viên bị cấm nhận thêm việc mới và bắt buộc phải ngồi chờ cho đến khi các lỗi ở khâu kiểm định được xử lý triệt để. Trưởng phòng tài chính phản đối dữ dội vì for rằng chi phí nhân sự trên mỗi đầu việc hoàn thành đang tăng lên tạm thời, và các chỉ số hiệu suất cá nhân trông có vẻ kém hiệu quả hơn trước. Người quản lý giao nhận kiên quyết giữ vững kỷ luật hệ thống, chấp nhận áp lực ngắn hạn từ ban tài chính. Sau bốn tuần, khi điểm nghẽn kiểm định được giải phóng hoàn toàn, thời gian chu kỳ từ ý tưởng đến tay khách hàng giảm từ sáu mươi ngày xuống còn bảy ngày, tỷ lệ lỗi phát sinh thực tế giảm xuống gần bằng không, và doanh thu từ các tính năng mới tăng trưởng vượt bậc nhờ khả năng phản ứng nhanh với nhu cầu thị trường.
Kỷ luật vận hành và phân quyền ra quyết định đóng vai trò quyết định trong việc duy trì chu trình học hỏi và cải tiến. Ai được quyết định gì và theo ngưỡng nào cần phải được quy định rõ bằng văn bản để tránh tình trạng tranh chấp quyền lực giữa các bên liên quan.
<table border=”1″ style=”width:100%; border-collapse: collapse; text-align: left;”><tr><th>Điều kiện thực thi</th><th>Lựa chọn quyết định</th><th>Ngưỡng kích hoạt</th><th>Bên chịu trách nhiệm đánh đổi</th></tr><tr><td>Lượng công việc dở dang vượt quá giới hạn cho phép ở bất kỳ khâu nào</td><td>Tạm dừng toàn bộ việc tiếp nhận đầu vào mới cho đến khi giải phóng xong điểm nghẽn</td><td>Số lượng hạng mục tồn đọng lớn hơn 150 phần trăm giới hạn quy định trong hai tuần liên tiếp</td><td>Trưởng bộ phận phát triển / Chấp nhận giảm tốc độ đưa tính năng mới ra mắt</td></tr><tr><td>Chi phí phát sinh do sửa lỗi kỹ thuật vượt ngưỡng ngân sách dự phòng ban đầu</td><td>Cắt giảm phạm vi tính năng có giá trị thấp nhất để bù đắp chi phí sửa chữa lỗi hệ thống</td><td>Chi phí phát sinh vượt quá 10 phần trăm tổng ngân sách giai đoạn</td><td>Chủ sở hữu sản phẩm / Chấp nhận hy sinh một phần tính năng kinh doanh</td></tr><tr><td>Điểm nghẽn hệ thống kéo dài không thể giải quyết bằng nguồn lực nội bộ hiện tại</td><td>Điều chuyển nhân sự cấp cao từ dự án khác hoặc thuê chuyên gia tư vấn bên ngoài</td><td>Thời gian chờ tại điểm nghẽn vượt quá quãng thời gian mười bốn ngày làm việc</td><td>Người bảo trợ dự án / Chấp nhận tăng chi phí ngắn hạn để đổi lấy tiến độ dài hạn</td></tr><tr><td>Xung đột lợi ích nghiêm trọng giữa tiến độ giao hàng và chất lượng kiểm định an toàn</td><td>Ưu tiên tuyệt đối cho chất lượng và độ ổn định, lùi thời hạn bàn giao thương mại</td><td>Phát hiện rủi ro có khả năng gây gián đoạn hệ thống hoặc mất dữ liệu khách hàng</td><td>Ban điều hành doanh nghiệp / Chấp nhận chậm trễ tiến độ thương mại trước thị trường</td></tr></table>
Bảng quyết định này giúp người quản lý xác định rõ thời điểm và thẩm quyền đưa ra các quyết định đánh đổi, loại bỏ hoàn toàn tình trạng đùn đẩy trách nhiệm khi gặp sự cố trên hiện trường.
Bên cạnh bảng quyết định, hệ thống vận hành đòi hỏi một cơ chế cảnh báo sớm để phát hiện các vết rạn nứt trước khi chúng trở thành khủng hoảng toàn cục.
<table border=”1″ style=”width:100%; border-collapse: collapse; text-align: left;”><tr><th>Dấu hiệu sớm trên hiện trường</th><th>Cơ chế hình thành bên trong hệ thống</th><th>Hậu quả nếu bỏ qua cảnh báo</th><th>Phản ứng xử lý bắt buộc</th></tr><tr><td>Báo cáo tiến độ của tất cả các đội nhóm đều tô màu xanh trong nhiều tuần liên tiếp trong khi sản phẩm chưa từng được kiểm tra tích hợp thực tế</td><td>Các trưởng nhóm tự che giấu lỗi kỹ thuật nhỏ để tránh bị khiển trách, đẩy rủi ro dồn cục về giai đoạn cuối dự án</td><td>Hệ thống sập toàn bộ vào ngày phát hành cuối cùng, gây thiệt hại tài chính và uy tín nghiêm trọng</td><td>Tiến hành kiểm toán độc lập dòng mã nguồn và yêu cầu chạy thử nghiệm tích hợp ngay lập tức</td></tr><tr><td>Thời gian họp giao ban kéo dài nhưng không có quyết định nào được đưa ra để giải quyết các vướng mắc kỹ thuật tồn đọng</td><td>Thiếu phân quyền rõ ràng; mọi vấn đề nhỏ đều phải chờ ban lãnh đạo cấp cao phê duyệt theo thói quen hành chính</td><td>Đội ngũ thực thi mất động lực, công việc dầm dề trôi qua mà không có ai chịu trách nhiệm giải quyết</td><td>Trao quyền quyết định trực tiếp cho người quản lý giao nhận tại hiện trường theo ngưỡng ngân sách định sẵn</td></tr><tr><td>Tỷ lệ công việc phải làm lại tăng cao đột biến giữa các chu kỳ bàn giao ngắn hạn</td><td>Yêu cầu nghiệp vụ từ phía kinh doanh thay đổi liên tục nhưng không qua quy trình kiểm soát thay đổi chính thức</td><td>Lãng phí toàn bộ nguồn lực đã bỏ ra để xây dựng những tính năng bị loại bỏ, kéo dài thời gian chu kỳ</td><td>Khóa cứng phạm vi công việc trong từng chu kỳ ngắn, mọi thay đổi mới phải chờ chu kỳ sau</td></tr><tr><td>Nhân sự chủ chốt tại các khâu kiểm định xin nghỉ việc hàng loạt do áp lực quá tải kéo dài</td><td>Hệ thống không cân bằng năng lực, dồn toàn bộ áp lực xử lý lỗi vào một vài cá nhân chuyên môn cao</td><td>Đứt gãy hoàn toàn chuỗi cung ứng giá trị, dự án rơi vào trạng thái tê liệt không thể bàn giao sản phẩm</td><td>Phân bổ lại công việc, tuyển dụng khẩn cấp hoặc thuê ngoài phần việc kiểm định để giảm tải</td></tr></table>
Bảng dấu hiệu sớm và rủi ro này giúp người quản lý định vị chính xác các điểm đứt gãy tiềm ẩn trong cấu trúc vận hành trước khi chúng làm sụp đổ toàn bộ kế hoạch thực thi.
Cấu trúc quyền lực thực tế trong doanh nghiệp thường có khoảng cách lớn so với sơ đồ tổ chức trên giấy. Trên giấy, người quản lý dự án có toàn quyền điều phối công việc và nhân sự. Nhưng trong thực tế, quyền lực thực tế về phân bổ nguồn lực và quyết định ngân sách thường nằm trong tay các trưởng bộ phận chức năng, những người không chịu trách nhiệm trực tiếp về kết quả cuối cùng của dự án mà chỉ quan tâm đến chỉ số hiệu suất riêng của phòng ban mình. Người bảo trợ dự án thường mang danh nghĩa là người đỡ đầu nhưng thực tế quá bận rộn với chiến lược cấp cao, chỉ xuất hiện khi có khủng hoảng lớn hoặc khi cần cắt giảm ngân sách. Chủ sở hữu sản phẩm nắm giữ quyền quyết định về tính năng nhưng thường xuyên bị giằng xé giữa áp lực doanh số ngắn hạn của thị trường và tính bền vững kỹ thuật của hệ thống. Sự mâu thuẫn lợi ích này tạo ra một chiến trường ngầm nơi không ai thực sự chịu trách nhiệm về toàn bộ dòng chảy giá trị, khiến mọi cải tiến liên tục đều bị bóp nghẹt nếu không có một cơ chế kỷ luật vận hành cứng rắn từ ban điều hành cấp cao.
Kịch bản bất lợi cần được tính đến: nếu giả định quan trọng nhất trong cách tiếp cận này là ban điều hành sẵn sàng chấp nhận sự sụt giảm tạm thời về năng suất hiển thị trong những tuần đầu tiên để đổi lấy hiệu suất vượt trội dài hạn bị sai, và ban lãnh đạo lập tức sa thải người quản lý vì thấy báo cáo tuần đầu có vẻ kém hiệu quả, thì cách tiếp cận này sẽ sụp đổ. Để điều chỉnh khi kịch bản bất lợi này xảy ra, người quản lý buộc phải minh bạch hóa dữ liệu ngay từ ngày đầu tiên, trình bày trước ban điều hành mô hình toán học về định luật dòng chảy và chứng minh bằng các con số giả định có kiểm soát rằng việc thả nổi công việc dở dang chắc chắn sẽ dẫn đến thảm họa trễ hạn ở cuối kỳ, từ đó xin phép thực hiện thí điểm ở một nhóm nhỏ trong hai tuần để lấy số liệu thực tế làm bằng chứng thuyết phục trước khi nhân rộng ra toàn tổ chức.
Trả lời trực tiếp cho câu hỏi trung tâm làm thế nào để tạo ra kết quả nhanh hơn và tốt hơn: để đạt được điều này, tổ chức phải ngừng ngay việc ép mọi người làm việc nhanh hơn ở từng khâu đơn lẻ, thay vào đó phải tập trung toàn lực vào việc phát hiện và giải phóng điểm nghẽn lớn nhất trong dòng công việc, đồng thời áp dụng kỷ luật giới hạn nghiêm ngặt lượng công việc dở dang trên toàn hệ thống. Điều kiện đảo chiều của giải pháp này là khi tổ chức đang vận hành trong môi trường sản xuất thủ công đơn giản với một quy trình tuyến tính không có điểm nghẽn giao thoa, khi đó việc tăng tốc độ từng cá nhân vẫn mang lại hiệu quả ngắn hạn.
Các việc cần làm phân theo vai trò trong dự án phù hợp với cấp độ năng lực thực thi:
– Người bảo trợ dự án: Phê duyệt khung giới hạn lượng công việc dở dang và cam kết bảo vệ đội ngũ trước áp lực ngắn hạn của ban điều hành khi năng suất tạm thời sụt giảm ở giai đoạn đầu cải tiến; trực tiếp can thiệp để 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 nhận.
– Người quản lý giao nhận: Trực tiếp theo dõi bảng kiểm soát dòng công việc hàng ngày, phát hiện và thông báo ngay lập tức các điểm nghẽn vượt ngưỡng; điều phối nguồn lực tạm thời từ các khâu dư thừa sang hỗ trợ khâu đang bị quá tải theo đúng quy tắc hệ thống.
– Chủ sở hữu sản phẩm: Duy trì kỷ luật đóng băng phạm vi công việc trong từng chu kỳ ngắn hạn, từ chối đưa các yêu cầu phát sinh chưa qua kiểm định vào dòng chảy chính; liên tục đo lường và đánh giá giá trị kinh doanh thực tế của các tính năng đã bàn giao.
– Đội ngũ thực hiện trực tiếp: Tuân thủ tuyệt đối giới hạn công việc dở dang, không nhận thêm việc mới khi chưa hoàn thành công việc hiện tại; chủ động báo cáo các dấu hiệu ùn tắc kỹ thuật ngay khi xuất hiện thay vì tự ý che giấu.
Các câu hỏi tự kiểm tra dành cho người đọc để đánh giá năng lực tối ưu hóa hoạt động:
– Lượng công việc dở dang hiện tại trong hệ thống của bạn đang vượt quá sức chứa thực tế của khâu yếu nhất là bao nhiêu phần trăm, và bạn đã có cơ chế nào để chặn đứng việc tiếp nhận thêm đầu vào mới chưa?
– Điểm nghẽn lớn nhất trong chuỗi giá trị từ ý tưởng đến tay khách hàng của dự án bạn đang nằm ở khâu nào, và bạn đã điều động bao nhiêu phần trăm nguồn lực rảnh rỗi từ các khâu khác để giải tỏa nó trong tuần qua?
– Thời gian chu kỳ trung bình để hoàn thành một yêu cầu công việc từ lúc khởi tạo đến lúc bàn giao thực tế đã thay đổi như thế nào sau khi bạn áp dụng các biện pháp giới hạn dòng công việc?
– Làm thế nào bạn phân biệt được giữa một báo cáo tiến độ xanh chính thống dựa trên giá trị kinh doanh thực tế và một báo cáo xanh giả tạo được che giấu bởi các chỉ số hoàn thành công việc cục bộ?
– Bạn đã từ chối bao nhiêu yêu cầu thay đổi phạm vi không cần thiết trong chu kỳ gần đây nhất để bảo vệ tốc độ dòng chảy chung của toàn hệ thống?