Tình huống minh họa: Một tổng thầu nhận gói hạ tầng giao thông quy mô lớn, sáu thầu phụ chính, hàng chục mốc nghiệm thu theo hợp đồng. Tiến độ tổng thể được lập trong phần mềm chuyên dụng với hơn hai nghìn dòng đầu việc, nhưng mỗi tuần vẫn cập nhật bằng cách gửi file qua email cho từng bên. Khi chủ đầu tư hỏi ngày hoàn thành dự kiến mới sau một đợt mưa kéo dài, ba người trong ban điều hành đưa ra ba ngày khác nhau.
Trả lời ngắn: Master Schedule là lịch tổng thể tích hợp mọi gói thầu thành một chuỗi phụ thuộc duy nhất, chốt các mốc hợp đồng, chuỗi công việc găng và đệm dự phòng. Khác tiến độ chi tiết của từng thầu phụ, nó là nguồn sự thật duy nhất để đo tác động của mọi thay đổi lên ngày hoàn thành dự kiến của cả dự án.
Bài viết này dành cho ai?
Dành cho Giám đốc dự án, Trưởng phòng Kế hoạch (planning) và Ban điều hành của công ty tổng thầu đang chạy các dự án hạ tầng, dân dụng hoặc công nghiệp quy mô lớn — những người phải trả lời mỗi tuần hai câu hỏi: ngày hoàn thành dự kiến hiện tại là ngày nào, và thay đổi vừa xảy ra dịch nó bao nhiêu ngày.
Điều gì đang xảy ra?
- Tiến độ tổng thể chỉ là bản ghép thủ công của các tiến độ do thầu phụ gửi lên, không có logic phụ thuộc giữa các gói.
- Mốc hợp đồng nằm trong hợp đồng, còn mốc kế hoạch nằm trong phần mềm, hai bên không khớp nhau khi báo cáo.
- File tiến độ luân chuyển qua email nên mỗi bên đang giữ một phiên bản khác nhau.
- Không ai tính tác động của một thay đổi cục bộ lên ngày hoàn thành tổng thể trước khi đồng ý cho thay đổi.
- Đệm dự phòng bị cắt dần trong các cuộc họp để "cho tiến độ đẹp", đến lúc cần thì không còn gì để dùng.
Điều doanh nghiệp thực sự muốn đạt được
Chức năng: một tiến độ tổng thể duy nhất có logic phụ thuộc, gắn đúng các mốc hợp đồng, tự động dồn ngày khi có thay đổi ở bất kỳ gói nào. Quản trị: một quy trình chốt baseline và quản lý phiên bản, để mọi quyết định điều chỉnh tiến độ đều được ghi nhận và giải thích được. Tổ chức: rõ ai được đề xuất thay đổi, ai phân tích tác động, ai phê duyệt baseline mới và ai chịu trách nhiệm truyền thông ngày hoàn thành.
Điều gì đang cản trở?
| Lớp cản trở | Biểu hiện | Hệ quả |
|---|---|---|
| Dữ liệu | Mỗi gói thầu một file tiến độ, mã công việc và đơn vị thời gian khác nhau | Không ghép được thành một chuỗi phụ thuộc thống nhất |
| Quy trình | Không có vòng chốt baseline và không có quy trình cập nhật định kỳ | Các bên tự điều chỉnh tiến độ riêng, báo cáo lệch nhau |
| Kiểm soát | Đệm dự phòng không được đăng ký và bảo vệ bằng con số | Đệm bị dùng hết mà không ai biết đã tiêu vào việc gì |
| Tổ chức | Không ai sở hữu việc phân tích tác động của thay đổi lên tổng thể | Quyết định thay đổi đưa ra mà không biết cái giá về ngày hoàn thành |
| Công cụ | Tiến độ tách khỏi dữ liệu khối lượng và chi phí, cập nhật bằng email | Không có cảnh báo sớm, chỉ biết trễ khi mốc đã trôi qua |
Điểm nhìn cốt lõi: Tiến độ tổng thể không hỏng vì thiếu phần mềm, mà vì thiếu một baseline được bảo vệ. Khi mỗi gói thầu giữ tiến độ riêng và đệm dự phòng không có chủ, mọi thay đổi đều trông vô hại ở phạm vi cục bộ nhưng cộng dồn thành một ngày hoàn thành khác. Một baseline có phiên bản, có logic phụ thuộc và có đệm được đăng ký biến câu hỏi "trễ mấy ngày" từ tranh luận thành phép tính.
Tác động tới doanh nghiệp
| Chiều tác động | Điều gì xảy ra khi tiến độ tổng thể không được kiểm soát |
|---|---|
| Cost | Chi phí làm thêm giờ, huy động thiết bị và thầu phụ gấp để bù các mốc đã trôi |
| Margin | Chi phí cứu tiến độ ăn vào biên lợi nhuận gói thầu, không được dự phòng từ đầu |
| Cash Flow | Lệch mốc nghiệm thu làm lệch kế hoạch thu tiền, dòng tiền căng đúng lúc đang cần trả thầu phụ |
| Progress | Các gói dồn việc về cuối dự án, chuỗi găng ngày càng dài và càng khó nén |
| Risk | Mất quyền gia hạn hợp đồng khi không chứng minh được nguyên nhân và thời điểm trễ |
Nguyên nhân gốc
Không có quy tắc mã hóa công việc và đơn vị thời gian chung giữa các gói thầu ↓ Mỗi gói giữ tiến độ riêng nên không hình thành chuỗi phụ thuộc liên gói ↓ Mốc hợp đồng không được neo vào công việc cụ thể trên tiến độ tổng thể ↓ Thay đổi được chấp thuận ở phạm vi gói, không phân tích tác động lên tổng thể ↓ Đệm dự phòng bị tiêu âm thầm, baseline cũ vẫn được dùng để báo cáo ↓ Ngày hoàn thành thực tế khác ngày hoàn thành đã cam kết, không có hồ sơ giải trình
Framework quản trị
| Lớp | Nội dung | Chủ sở hữu |
|---|---|---|
| Cấu trúc | Quy tắc mã công việc (WBS), đơn vị thời gian và mức chi tiết tối thiểu dùng chung | Trưởng phòng Kế hoạch |
| Baseline | Tiến độ gốc được chốt, đánh số phiên bản và không sửa trực tiếp trên bản đã chốt | Giám đốc dự án |
| Logic | Phụ thuộc giữa các công việc và giữa các gói, xác định chuỗi găng và đệm dự phòng | Planner |
| Thay đổi | Mọi thay đổi phải kèm phân tích tác động ngày hoàn thành trước khi phê duyệt | Ban điều hành |
| Truyền thông | Một bản tiến độ chuẩn để báo cáo mọi cấp, kèm ngày dữ liệu cắt và người chốt số | Giám đốc dự án |
WBS CHUNG — mã công việc và mức chi tiết thống nhất cho mọi gói thầu ↓ BASELINE v1 — tiến độ gốc có dấu phiên bản và đệm dự phòng được đăng ký ↓ LOGIC PHỤ THUỘC — chuỗi găng liên gói, đệm tổng và đệm riêng từng gói ↓ MỐC HỢP ĐỒNG — neo từng mốc vào công việc cụ thể, không để mốc treo ↓ VÒNG CẬP NHẬT — nhịp cập nhật cố định, ngày dữ liệu cắt cố định ↓ KIỂM SOÁT THAY ĐỔI — phân tích tác động trước, phê duyệt baseline mới sau
Neo mốc hợp đồng vào công việc, chuẩn hóa cấu trúc công việc liên gói, đăng ký đệm dự phòng và kiểm soát thay đổi qua phân tích tác động lên ngày hoàn thành.
Khám phá EcoCons → Xem gói One →Quy trình To-Be (Process chi tiết)
| Bước | Người phụ trách | Điều kiện vào | Điểm kiểm soát |
|---|---|---|---|
| Chuẩn hóa cấu trúc công việc | Trưởng phòng Kế hoạch | Đã có phạm vi và BOQ các gói | Mọi gói dùng cùng quy tắc mã và mức chi tiết |
| Ghép tiến độ các gói thành chuỗi liên gói | Planner | Cấu trúc công việc chung đã chốt | Phụ thuộc liên gói được khai báo, không ghép bằng cảm nhận |
| Neo mốc hợp đồng vào công việc | Giám đốc dự án | Chuỗi liên gói đã có logic | Mỗi mốc có ít nhất một công việc và một người chịu trách nhiệm |
| Chốt baseline và đăng ký đệm | Giám đốc dự án | Mốc đã neo, logic đã kiểm tra | Đệm tổng và đệm riêng được ghi thành con số, không cắt ngầm |
| Cập nhật định kỳ theo ngày dữ liệu cắt | Planner | Baseline đã chốt | Tiến độ thực cập nhật trước khi báo cáo, có ngày cắt dữ liệu |
| Xử lý thay đổi và ra baseline mới | Ban điều hành | Có đề xuất thay đổi kèm phân tích | Bản cũ lưu lại, bản mới đánh số phiên bản và công bố ngày hoàn thành |
Ví dụ minh họa — số liệu giả định
Ví dụ minh họa — số liệu giả định, không phải thống kê.
Một dự án hạ tầng giả định có giá trị hợp đồng 1.200.000 triệu đồng và thời gian 540 ngày. Chuỗi găng gồm bốn gói: nền đường 120 ngày, cầu 180 ngày, mặt đường 90 ngày và hệ thống an toàn 60 ngày, cộng lại 450 ngày; đệm tổng 90 ngày, nên 450 + 90 = 540 ngày đúng bằng thời gian hợp đồng. Một đợt mưa làm gói nền đường chậm 20 ngày. Nếu gói này nằm trên chuỗi găng, ngày hoàn thành dự kiến dịch 20 ngày, tức còn 70 ngày đệm. Tự kiểm tra: 540 − 20 = 520 ngày còn lại so với cam kết, và 90 − 20 = 70 ngày đệm còn lại. Nếu thay đổi thiết kế ở gói cầu làm thêm 25 ngày công việc, tổng dịch chuyển là 20 + 25 = 45 ngày, đệm còn 90 − 45 = 45 ngày. Kiểm tra lại: 450 + 45 = 495 ngày công việc; 495 + 45 = 540, khớp thời gian hợp đồng. Kết luận: khi còn đệm, việc trễ chưa phải thảm họa — nhưng chỉ biết điều đó nếu baseline có đệm được đăng ký.
EcoCons hỗ trợ ở đâu?
| Yêu cầu | Năng lực | Mức đáp ứng |
|---|---|---|
| Cấu trúc công việc và nhiệm vụ theo gói thầu | Dự án, nhiệm vụ, phụ thuộc nhiệm vụ và mã phân tích theo công trình | Tiêu chuẩn |
| Mốc hợp đồng gắn với công việc | Cột mốc dự án, hạn chót nhiệm vụ và cảnh báo quá hạn | Tiêu chuẩn + cấu hình |
| Nguồn lực và thời gian thực hiện | Kế hoạch nguồn lực, timesheet và công suất theo tổ đội | Tiêu chuẩn + cấu hình |
| Ghép tiến độ với khối lượng và chi phí | Liên kết nhiệm vụ với đơn hàng, hóa đơn và bút toán theo công trình | Mở rộng (AI-X) |
AI / Automation hỗ trợ ở đâu?
Điểm ra quyết định cần AI hỗ trợ là lúc tiến độ thay đổi và cần biết nó ảnh hưởng tới đâu. Khi tiến độ, khối lượng và chi phí nằm trong cùng một hệ thống, AI có thể đọc chuỗi phụ thuộc để chỉ ra công việc nào đang chặn, tính lại ngày hoàn thành dự kiến theo ngày dữ liệu mới, và xếp hạng các thay đổi theo mức tiêu tốn đệm. AI không tự chốt baseline, không tự phê duyệt thay đổi, không tự cắt đệm dự phòng và không tự công bố ngày hoàn thành cho chủ đầu tư. Quyết định cuối cùng vẫn thuộc Giám đốc dự án và Ban điều hành.
KPI cần theo dõi
| KPI | Công thức | Tần suất | Chủ sở hữu | Hành động khi lệch |
|---|---|---|---|---|
| Độ chính xác ngày hoàn thành dự kiến | Chênh lệch ngày dự kiến tuần này so với tuần trước | Tuần | Planner | Rà lại logic phụ thuộc và độ trễ cập nhật |
| Tỷ lệ mốc hợp đồng đạt đúng hạn | Mốc đạt ÷ tổng mốc đến hạn trong kỳ | Tháng | Giám đốc dự án | Phân tích mốc trượt và cập nhật kế hoạch nén |
| Đệm dự phòng còn lại | Đệm còn lại ÷ đệm ban đầu | Hai tuần | Ban điều hành | Dừng thay đổi không thiết yếu khi đệm dưới ngưỡng |
| Độ trễ cập nhật tiến độ | Số ngày từ ngày dữ liệu cắt đến ngày phát hành báo cáo | Tuần | Planner | Rút ngắn chu kỳ, siết nhịp nhập liệu tại công trường |
Bộ bốn chỉ số này đủ để ban điều hành biết tiến độ tổng thể còn đáng tin hay không: dự báo có ổn định, mốc có giữ được, đệm còn bao nhiêu và báo cáo có phản ánh thực tế hay chỉ đang chép lại kế hoạch cũ.
Câu hỏi thường gặp
Master Schedule khác gì tiến độ chi tiết của từng thầu phụ?
Master Schedule là lịch tổng thể có logic phụ thuộc giữa các gói thầu, chốt mốc hợp đồng, chuỗi găng và đệm dự phòng của toàn dự án. Tiến độ chi tiết chỉ mô tả công việc bên trong một gói. Master Schedule là nơi trả lời câu hỏi ngày hoàn thành dự kiến; tiến độ chi tiết là nơi trả lời câu hỏi tổ đội nào làm việc gì trong tuần này.
Có cần phần mềm chuyên dụng mới lập được Master Schedule không?
Không bắt buộc. Với vài trăm đầu việc, một cấu trúc công việc chung, logic phụ thuộc và bảng đệm dự phòng đã tạo phần lớn giá trị. Phần mềm chuyên dụng cần khi số đầu việc lên hàng nghìn, nhiều gói cùng chạy và cần tính lại chuỗi găng tự động mỗi lần dữ liệu đổi.
Baseline tiến độ nên được chốt khi nào và bao lâu đổi một lần?
Baseline chốt sau khi phạm vi, BOQ và logic phụ thuộc đã ổn định. Sau đó chỉ mở baseline mới khi có thay đổi được phê duyệt kèm phân tích tác động, và bản cũ luôn được lưu. Không sửa trực tiếp trên bản đã chốt, vì làm vậy sẽ mất khả năng giải trình tại sao ngày hoàn thành đã dịch.
Đệm dự phòng nên đặt ở cấp gói hay cấp dự án?
Nên đặt cả hai, nhưng đệm tổng của dự án phải do Ban điều hành quản lý. Đệm ở cấp gói giúp thầu phụ chủ động xử lý trễ nhỏ. Đệm tổng là lớp bảo vệ cuối cho ngày hoàn thành cam kết, nên phải được đăng ký thành con số và chỉ tiêu khi có phân tích tác động.
Khi chủ đầu tư yêu cầu nén tiến độ thì trả lời thế nào?
Đưa ra ba phương án kèm cái giá: nén trong đệm hiện có, nén kèm tăng nguồn lực, hoặc nén kèm điều chỉnh phạm vi. Mỗi phương án phải nêu số ngày tiết kiệm, chi phí tăng thêm và rủi ro đi kèm. Trả lời bằng con số từ baseline thuyết phục hơn nhiều so với cam kết bằng cảm nhận.
Bao lâu nên cập nhật tiến độ tổng thể một lần?
Với dự án hạ tầng lớn, nhịp tuần là hợp lý, kèm một vòng cập nhật sâu theo tháng để rà lại logic và đệm. Điều quan trọng không phải tần suất mà là kỷ luật ngày dữ liệu cắt: số liệu phải được chốt trước khi phát hành báo cáo, để mọi người cùng nhìn một phiên bản.
Checklist: doanh nghiệp của bạn có vấn đề này không?
Đọc kết quả: 0–2 ô = tiến độ tổng thể đang được kiểm soát; 3–5 ô = cần chuẩn hóa cấu trúc công việc và chốt baseline có phiên bản; 6–8 ô = nên xây lại hệ tiến độ tổng thể theo năm lớp ở phần Framework.
Kết luận
Master Schedule không phải bản báo cáo để trình chủ đầu tư, mà là công cụ để trả lời một câu hỏi duy nhất: thay đổi vừa xảy ra dịch ngày hoàn thành bao nhiêu ngày. Khi cấu trúc công việc được chuẩn hóa, baseline có phiên bản, mốc hợp đồng được neo vào công việc và đệm dự phòng được đăng ký thành con số, tổng thầu chuyển từ giải thích trễ sang điều khiển tiến độ.
Xem thêm: Hành trình Tiến độ & phối hợp đa dự án và tầng Controller tổng thầu xây dựng để biết cách đưa tiến độ vào điều hành hằng ngày.