Chủ đầu tư quản lý nhiều dự án: Làm sao biết dự án nào đang có vấn đề?

Khi chỉ quản lý một dự án, chủ đầu tư hoặc Ban quản lý dự án có thể theo sát từng cuộc họp, từng mốc tiến độ, từng hồ sơ và từng vấn đề phát sinh. Nhưng khi số lượng dự án tăng lên 10, 20 hoặc hàng chục dự án cùng lúc, cách quản lý đó gần như không thể tiếp tục duy trì.

Lúc này, câu hỏi quan trọng nhất đối với lãnh đạo không còn là: “Dự án A hôm nay đang làm gì?” mà là: “Trong toàn bộ danh mục dự án, dự án nào đang có vấn đề và tôi cần can thiệp vào đâu trước?”

Đây chính là bài toán cốt lõi của quản lý nhiều dự án.

Một dự án báo cáo hoàn thành 85% chưa chắc đang an toàn. Một dự án mới đạt 70% cũng chưa chắc đang chậm. Có dự án vẫn chạy đúng tiến độ tổng thể nhưng hồ sơ thiết kế đang tồn đọng. Có dự án chưa vượt ngân sách nhưng khối lượng phát sinh đang tăng nhanh. Có dự án ngoài công trường vẫn thi công bình thường nhưng vật tư của công việc nằm trên đường găng chưa được phê duyệt hoặc chưa đặt hàng.

Nếu chỉ nhìn vào một vài con số tổng hợp, chủ đầu tư rất dễ phát hiện vấn đề khi nó đã trở thành hậu quả.

Muốn quản lý nhiều dự án hiệu quả, lãnh đạo cần một cách tiếp cận khác: dữ liệu phải được chuẩn hóa, các dự án phải được đánh giá trên cùng một hệ thống chỉ số, các tín hiệu bất thường phải được nhận diện sớm và dashboard quản lý dự án phải giúp người dùng đi từ tổng quan xuống đúng vấn đề cần xử lý.

Bài viết này phân tích cách chủ đầu tư có thể xây dựng một hệ thống như vậy, đồng thời làm rõ vai trò của phần mềm quản lý dự án xây dựng trong việc kiểm soát danh mục dự án ở cấp doanh nghiệp.

1. Quản lý nhiều dự án không đơn giản là cộng nhiều báo cáo dự án lại với nhau

Một sai lầm khá phổ biến khi doanh nghiệp bắt đầu quản lý nhiều dự án là cho rằng chỉ cần yêu cầu tất cả các Ban quản lý gửi báo cáo, sau đó tổng hợp những báo cáo đó thành một bảng chung.

Cách làm này có thể hoạt động khi số lượng dự án còn ít. Nhưng khi danh mục dự án tăng lên, nó nhanh chóng bộc lộ nhiều hạn chế.

Dự án A báo cáo theo phần trăm hoàn thành.

Dự án B báo cáo theo sản lượng.

Dự án C báo cáo theo mốc tiến độ.

Dự án D tập trung vào giải ngân.

Một dự án cập nhật dữ liệu mỗi ngày, một dự án mỗi tuần và một dự án chỉ cập nhật trước kỳ họp.

Khi dữ liệu được tạo ra theo những cách khác nhau, lãnh đạo rất khó đặt các dự án cạnh nhau để so sánh.

Đây là điểm khác biệt cơ bản giữa quản lý một dự án và quản lý danh mục dự án.

Ở cấp dự án, người quản lý cần hiểu chi tiết.

Ở cấp danh mục, lãnh đạo cần khả năng so sánh.

Muốn so sánh được, các dự án phải được chuẩn hóa về cách đo lường.

Tiến độ phải được đo theo cùng một logic.

Chi phí phải được phân loại theo cùng một nguyên tắc.

Hợp đồng phải được theo dõi trên cùng một cấu trúc.

Hồ sơ phải có trạng thái thống nhất.

Rủi ro phải có cách phân loại tương đồng.

Chỉ khi dữ liệu được đưa về cùng một “ngôn ngữ quản lý”, chủ đầu tư mới có thể trả lời một câu hỏi tưởng như rất đơn giản:

Dự án nào đang khỏe, dự án nào cần theo dõi và dự án nào cần lãnh đạo can thiệp ngay?

Đó là nền tảng của quản lý nhiều dự án.

2. Không thể biết dự án có vấn đề chỉ bằng phần trăm hoàn thành

Một trong những chỉ số được hỏi nhiều nhất trong các cuộc họp dự án là phần trăm hoàn thành.

“Dự án đã đạt bao nhiêu phần trăm?”

Con số này quan trọng, nhưng nếu sử dụng riêng lẻ thì rất dễ gây hiểu nhầm.

Giả sử dự án A đang đạt 82% và dự án B mới đạt 72%.

Nếu chỉ nhìn hai con số đó, dự án A có vẻ đang tốt hơn.

Nhưng nếu theo kế hoạch tại thời điểm hiện tại dự án A phải đạt 92%, trong khi dự án B chỉ cần đạt 70%, thì bức tranh hoàn toàn thay đổi.

Dự án A đang chậm 10%.

Dự án B đang vượt kế hoạch 2%.

Vì vậy, khi quản lý nhiều dự án, chủ đầu tư không nên chỉ hỏi “đã làm được bao nhiêu”, mà phải đặt kết quả thực tế cạnh kế hoạch.

Một dashboard quản lý dự án cần cho thấy ít nhất ba lớp thông tin: kế hoạch ban đầu, thực tế hiện tại và xu hướng dự báo.

Nhưng ngay cả độ lệch tiến độ cũng chưa đủ.

Một công việc có thể chậm năm ngày nhưng còn rất nhiều thời gian dự phòng.

Một công việc khác mới chậm hai ngày nhưng nằm trên đường găng.

Về mặt quản trị, công việc thứ hai có thể nguy hiểm hơn.

Do đó, đánh giá sức khỏe dự án phải dựa trên mức độ ảnh hưởng đến mục tiêu cuối cùng chứ không chỉ dựa vào số ngày chậm hoặc tỷ lệ hoàn thành.

Đây là lý do phần mềm quản lý tiến độ dự án cần được kết nối với dữ liệu quản trị khác thay vì chỉ hiển thị một biểu đồ Gantt.

3. Dự án thường phát tín hiệu cảnh báo trước khi tiến độ chuyển sang trạng thái đỏ

Một dự án rất hiếm khi đang hoàn toàn ổn vào ngày hôm nay rồi bất ngờ trở thành dự án khủng hoảng vào ngày mai.

Trước khi tiến độ tổng thể bị ảnh hưởng, dự án thường đã phát ra nhiều tín hiệu nhỏ.

Một bản vẽ lẽ ra phải được phê duyệt tuần trước nhưng vẫn đang chờ.

Một hồ sơ vật liệu chưa được chấp thuận.

Một thiết bị có thời gian đặt hàng dài vẫn chưa được quyết định.

Một gói thầu sắp tới ngày triển khai nhưng hợp đồng chưa hoàn thành.

Một thủ tục pháp lý sắp đến hạn.

Nhân lực thực tế liên tục thấp hơn kế hoạch.

Khối lượng nghiệm thu bắt đầu không theo kịp khối lượng thi công.

Một loạt RFI chưa được phản hồi.

Giá trị phát sinh tăng nhanh trong nhiều kỳ liên tiếp.

Từng vấn đề riêng lẻ có thể chưa làm dự án chậm ngay lập tức.

Nhưng nếu nhiều tín hiệu xuất hiện đồng thời, đó là dấu hiệu cho thấy sức khỏe của dự án đang xấu đi.

Vì vậy, quản lý dự án hiệu quả không nên chỉ phát hiện những việc đã quá hạn.

Hệ thống phải tiến tới khả năng nhận diện những việc sắp trở thành vấn đề.

Đây là sự khác nhau giữa báo cáo và cảnh báo sớm.

Báo cáo nói cho người quản lý biết chuyện gì đã xảy ra.

Cảnh báo sớm giúp người quản lý nhìn thấy chuyện gì có khả năng xảy ra nếu không có hành động.

Với chủ đầu tư quản lý nhiều dự án, khả năng này đặc biệt quan trọng bởi lãnh đạo không thể theo dõi từng công việc chi tiết của mọi dự án mỗi ngày.

4. Chủ đầu tư cần một chỉ số sức khỏe dự án thay vì hàng chục báo cáo rời rạc

Khi số lượng dự án tăng, lãnh đạo không thể đọc toàn bộ dữ liệu chi tiết trước khi biết dự án nào cần quan tâm.

Một giải pháp phù hợp là xây dựng Project Health Score, có thể hiểu là chỉ số sức khỏe tổng hợp của dự án.

Project Health Score không nhất thiết phải là một công thức cố định cho mọi doanh nghiệp.

Điều quan trọng là nó phải phản ánh được những yếu tố ảnh hưởng trực tiếp đến mục tiêu của chủ đầu tư.

Ví dụ, sức khỏe dự án có thể được tổng hợp từ tiến độ, chi phí, tình trạng pháp lý, hợp đồng, hồ sơ, rủi ro và các issue quan trọng.

Một dự án đang kiểm soát tốt có thể hiển thị trạng thái xanh.

Một dự án bắt đầu xuất hiện sai lệch hiển thị trạng thái vàng.

Một dự án vượt các ngưỡng kiểm soát quan trọng chuyển sang trạng thái đỏ.

Điều cần tránh là để Project Manager tự đánh giá dự án xanh, vàng hay đỏ hoàn toàn bằng cảm nhận.

Nếu trạng thái phụ thuộc vào ý kiến cá nhân, cùng một tình trạng nhưng mỗi người có thể đánh giá khác nhau.

Một hệ thống quản lý tốt nên để dữ liệu tự tạo ra phần lớn tín hiệu.

Bao nhiêu milestone đã quá hạn?

Tiến độ lệch bao nhiêu so với baseline?

Bao nhiêu hồ sơ phê duyệt đang tồn?

Có thủ tục pháp lý nào sắp đến hạn không?

Chi phí dự kiến cuối dự án đang ở đâu so với ngân sách?

Có bao nhiêu vấn đề nghiêm trọng chưa được xử lý?

Khi những dữ liệu này được chuẩn hóa, việc đánh giá dự án trở nên nhất quán hơn.

Đó cũng là điều kiện để chủ đầu tư so sánh nhiều dự án trên cùng một dashboard.

( Hình ảnh chỉ mang tính chất minh họa )

5. Dashboard quản lý dự án phải giúp lãnh đạo biết cần xử lý việc gì

Một dashboard có rất nhiều biểu đồ chưa chắc là một dashboard tốt.

Mục tiêu của dashboard quản lý nhiều dự án không phải trình bày càng nhiều dữ liệu càng tốt.

Mục tiêu là hỗ trợ ra quyết định.

Ở cấp lãnh đạo, màn hình đầu tiên phải trả lời được câu hỏi:

Dự án nào đang có vấn đề?

Sau đó là:

Vấn đề chính của dự án đó nằm ở đâu?

Và cuối cùng:

Ai đang chịu trách nhiệm xử lý?

Ví dụ, trong danh mục 20 dự án, hệ thống xác định ba dự án có mức độ rủi ro cao.

Khi lãnh đạo chọn dự án thứ nhất, dashboard cho thấy nguyên nhân lớn nhất nằm ở tiến độ pháp lý.

Dự án thứ hai có vấn đề ở hợp đồng và nguồn vốn.

Dự án thứ ba có nhiều hồ sơ kỹ thuật quá hạn.

Từ đó người quản lý có thể đi sâu vào đúng nhóm dữ liệu cần xem.

Đây là cách tiếp cận drill-down.

Từ danh mục dự án xuống từng dự án.

Từ dự án xuống từng nhóm vấn đề.

Từ vấn đề xuống đầu việc.

Từ đầu việc xuống người chịu trách nhiệm.

Nếu dashboard chỉ cho biết “dự án đang đỏ” nhưng người dùng vẫn phải gọi điện cho Ban QLDA để hỏi “tại sao đỏ”, dashboard vẫn chưa giải quyết triệt để bài toán quản trị.

6. Tiến độ phải được nhìn cùng pháp lý, hồ sơ và hợp đồng

Một trong những nguyên nhân khiến chủ đầu tư phát hiện chậm tiến độ muộn là vì tiến độ thường được quản lý tách khỏi những dữ liệu khác.

Trong thực tế, rất nhiều công việc ngoài công trường không chậm vì năng lực thi công.

Chúng chậm vì một điều kiện trước đó chưa hoàn thành.

Một hạng mục chưa thể triển khai vì thiết kế chưa phát hành.

Thiết kế chưa phát hành vì hồ sơ đang chờ phê duyệt.

Thiết bị chưa thể đặt hàng vì vật liệu chưa được chấp thuận.

Một gói thầu chưa thể khởi động vì hợp đồng chưa hoàn tất.

Một công việc chưa được phép triển khai vì thủ tục pháp lý chưa hoàn thành.

Nếu chủ đầu tư chỉ nhìn Gantt Chart, phần lớn những nguyên nhân này nằm bên ngoài biểu đồ tiến độ.

Vì vậy, quản lý nhiều dự án phải được xây dựng theo tư duy dữ liệu liên kết.

Tiến độ không đứng riêng.

Pháp lý không đứng riêng.

Hợp đồng không đứng riêng.

Hồ sơ không đứng riêng.

Chúng là các mắt xích của cùng một quá trình.

Trong hệ sinh thái TBT360, QLDA 360 được định hướng quản lý đồng thời các nhóm dữ liệu như tiến độ dự án, tiến độ pháp lý, hợp đồng, nguồn vốn, cảnh báo và báo cáo quản trị.

Khi những dữ liệu này được quản lý trên cùng một hệ thống, chủ đầu tư có khả năng nhìn thấy mối liên hệ giữa vấn đề quản trị và ảnh hưởng của nó tới tiến độ tổng thể.

Đây là khác biệt quan trọng giữa phần mềm lập tiến độ và phần mềm quản lý dự án xây dựng.

7. Một dự án chưa vượt ngân sách vẫn có thể đang có vấn đề về chi phí

Quản lý chi phí cũng có một lỗi tương tự quản lý tiến độ.

Nhiều báo cáo tập trung vào câu hỏi:

Đã chi bao nhiêu tiền?

Nhưng với người quản lý, câu hỏi quan trọng hơn là:

Nếu xu hướng hiện tại tiếp tục, cuối dự án sẽ tốn bao nhiêu tiền?

Giả sử ngân sách dự án là 500 tỷ đồng.

Dự án mới thực chi 300 tỷ đồng.

Nếu chỉ nhìn Actual Cost, tình hình có vẻ vẫn an toàn.

Nhưng nếu các hợp đồng đã cam kết, phát sinh đang xử lý và những gói sắp triển khai khiến tổng chi phí dự kiến đạt 540 tỷ đồng, dự án đã có nguy cơ vượt ngân sách.

Vấn đề chỉ chưa xuất hiện trên số tiền đã thanh toán.

Do đó, quản lý chi phí phải nhìn đồng thời ngân sách, giá trị cam kết, chi phí thực tế và dự báo cuối dự án.

Khi quản lý nhiều dự án, dữ liệu này càng quan trọng.

Một dự án vượt 3% có thể chưa phải vấn đề lớn.

Nhưng nếu 15 dự án đều có xu hướng vượt ngân sách từ 3% đến 5%, doanh nghiệp có thể đang đối mặt với rủi ro tài chính ở cấp danh mục.

Dashboard phải giúp lãnh đạo nhìn thấy xu hướng đó.

8. Hồ sơ quá hạn có thể là nguyên nhân khiến dự án chậm mà dashboard tiến độ không nhìn thấy

Trong quản lý xây dựng, hồ sơ thường bị xem là một hoạt động hành chính.

Thực tế, tốc độ xử lý hồ sơ có thể tác động trực tiếp tới tốc độ thi công.

Một Shop Drawing chưa được duyệt có thể khiến nhà thầu chưa thể triển khai.

Một Material Submittal chậm có thể khiến vật tư không thể đặt hàng.

Một RFI tồn đọng có thể khiến đội thi công phải chờ quyết định.

Một hồ sơ thay đổi chưa được phê duyệt có thể khiến cả một khu vực không thể tiếp tục.

Nếu mỗi dự án có hàng trăm hoặc hàng nghìn hồ sơ, lãnh đạo không thể kiểm tra từng hồ sơ.

Hệ thống phải tự động nhận diện những hồ sơ quá hạn và sắp quá hạn.

Quan trọng hơn, hệ thống cần giúp người dùng biết hồ sơ đó liên quan đến công việc nào.

Khi dữ liệu hồ sơ được quản lý trên CDE và liên kết với dữ liệu dự án, chủ đầu tư có khả năng nhìn thấy dòng chảy thông tin thay vì chỉ nhìn từng file riêng lẻ.

Đây cũng là lý do TBT360 định hướng kết nối quản lý dự án với môi trường dữ liệu chung CDE.

Một dự án có tiến độ tốt nhưng liên tục tích tụ hồ sơ chưa xử lý vẫn có thể đang tạo ra rủi ro cho những tuần tiếp theo.

9. Vấn đề lớn nhất của chủ đầu tư thường không phải thiếu dữ liệu mà là dữ liệu nằm ở quá nhiều nơi

Hãy hình dung một doanh nghiệp đang quản lý 20 dự án.

Tiến độ nằm trong Microsoft Project hoặc Primavera.

Một số dự án vẫn dùng Excel.

Hợp đồng nằm ở một hệ thống khác.

Tài liệu kỹ thuật nằm trên Google Drive.

Trao đổi hàng ngày nằm trong Zalo.

Báo cáo tuần được gửi bằng Word hoặc PDF.

Dữ liệu BIM nằm trong một phần mềm chuyên dụng.

Kế toán có hệ thống riêng.

Mỗi công cụ đều có thể thực hiện tốt nhiệm vụ của nó.

Nhưng khi Tổng giám đốc hỏi:

“Trong 20 dự án, dự án nào đang có nguy cơ lớn nhất?”

không một nguồn dữ liệu đơn lẻ nào có thể trả lời đầy đủ.

Người quản lý phải yêu cầu từng dự án tổng hợp.

Sau đó dữ liệu được gửi về.

Một người khác ghép báo cáo.

Đến khi báo cáo hoàn thành, dữ liệu có thể đã cũ.

Đây là bài toán data silo, hay dữ liệu bị phân mảnh.

Khi dữ liệu phân mảnh, doanh nghiệp không chỉ mất thời gian tổng hợp.

Khả năng cảnh báo sớm cũng giảm mạnh.

Một hệ thống không biết hồ sơ đang quá hạn sẽ không thể cảnh báo hồ sơ đó đang đe dọa tiến độ.

Một hệ thống không biết giá trị hợp đồng sẽ không thể đánh giá chính xác tình hình ngân sách.

Một hệ thống không biết trạng thái pháp lý sẽ không thể đưa ra bức tranh đầy đủ về sức khỏe dự án.

Do đó, nền tảng của quản lý nhiều dự án không phải là dashboard.

Nền tảng thực sự là dữ liệu.

10. Single Source of Truth là nền tảng để lãnh đạo tin vào dashboard

Single Source of Truth có thể hiểu đơn giản là một nguồn thông tin chính thức mà tổ chức cùng sử dụng để ra quyết định.

Điều đó không có nghĩa toàn bộ dữ liệu vật lý bắt buộc phải nằm trong một database duy nhất.

Điều quan trọng là với mỗi loại thông tin, tổ chức phải biết đâu là dữ liệu đang có hiệu lực.

Bản tiến độ nào là bản chính thức?

Giá trị hợp đồng hiện tại là bao nhiêu?

Hồ sơ nào đã được phê duyệt?

Mô hình BIM nào đang ở trạng thái Published?

Ngân sách mới nhất là bao nhiêu?

Issue nào đã đóng?

Nếu mỗi câu hỏi có nhiều câu trả lời tùy người được hỏi, doanh nghiệp chưa có một nguồn dữ liệu đủ tin cậy.

Khi quản lý nhiều dự án, vấn đề này tăng theo quy mô.

Một sai lệch nhỏ ở một dự án có thể chấp nhận được.

Nhưng nếu 30 dự án đều báo cáo theo 30 cách khác nhau, dashboard tổng hợp phía trên gần như mất ý nghĩa.

Do đó, trước khi xây dựng hệ thống báo cáo cho lãnh đạo, doanh nghiệp phải chuẩn hóa dữ liệu từ cấp dự án.

Đây là nền tảng để sau này triển khai cảnh báo thông minh, phân tích xu hướng hoặc AI trong quản lý dự án.

11. Mỗi cấp quản lý cần một dashboard khác nhau

Một sai lầm khác khi triển khai phần mềm quản lý dự án là cố gắng đưa tất cả dữ liệu lên cùng một màn hình.

Tổng giám đốc không cần xem từng công việc nhỏ.

Kỹ sư hiện trường không cần xem toàn bộ danh mục đầu tư.

Trưởng phòng hợp đồng không cần một dashboard giống người phụ trách pháp lý.

Mỗi vai trò cần một lớp thông tin khác nhau.

Ở cấp lãnh đạo, dashboard nên tập trung vào sức khỏe toàn bộ danh mục dự án, các chỉ số tài chính lớn, tiến độ tổng thể, rủi ro và những vấn đề cần quyết định.

Ở cấp Giám đốc dự án, dữ liệu phải đi sâu hơn vào mốc tiến độ, hợp đồng, hồ sơ, phát sinh và nguồn lực.

Ở cấp chuyên viên, hệ thống cần tập trung vào những đầu việc cụ thể phải xử lý.

Nguyên tắc ở đây rất đơn giản:

Người dùng mở dashboard lên phải biết ngay mình cần quan tâm điều gì.

Nếu một màn hình có 50 biểu đồ nhưng người dùng vẫn không biết phải làm gì tiếp theo, dashboard đó chưa thực sự hỗ trợ quản lý.

12. Chủ đầu tư cần chuyển từ báo cáo quá khứ sang cảnh báo tương lai

Báo cáo truyền thống chủ yếu mô tả chuyện đã xảy ra.

Tuần trước đã làm gì?

Đã hoàn thành bao nhiêu phần trăm?

Đã giải ngân bao nhiêu?

Có bao nhiêu hồ sơ quá hạn?

Nhưng quản lý dự án không chỉ cần hiểu quá khứ.

Người quản lý cần ra quyết định cho tương lai.

Do đó, hệ thống quản lý hiện đại phải từng bước chuyển từ reporting sang early warning.

Thay vì chỉ báo rằng một công việc đã quá hạn, hệ thống cần cảnh báo khi công việc sắp đến hạn nhưng chưa có dấu hiệu hoàn thành.

Thay vì chỉ báo hợp đồng đã hết hiệu lực, hệ thống cần cảnh báo trước.

Thay vì đợi ngân sách bị vượt, dashboard cần cho thấy Forecast đang tiến gần hoặc vượt giới hạn.

Thay vì chờ một hồ sơ trễ, hệ thống cần nhận diện workflow đang có nguy cơ chậm.

Đây là lúc dữ liệu bắt đầu trở thành công cụ quản trị.

Và đây cũng là bước nền trước khi doanh nghiệp nghĩ tới AI hoặc các mô hình dự báo phức tạp hơn.

13. Khi nào chủ đầu tư nên chuyển từ Excel sang phần mềm quản lý nhiều dự án?

Không có một con số cố định rằng doanh nghiệp phải có 10 hay 20 dự án mới cần phần mềm.

Dấu hiệu quan trọng hơn nằm ở cách tổ chức đang phải làm việc.

Nếu lãnh đạo liên tục yêu cầu “tổng hợp lại cho tôi”.

Nếu mỗi kỳ họp phải mất vài ngày chuẩn bị báo cáo.

Nếu cùng một chỉ số nhưng mỗi dự án tính theo một cách.

Nếu số liệu giữa Ban QLDA và phòng kế hoạch khác nhau.

Nếu không ai chắc bản tiến độ nào mới nhất.

Nếu một vấn đề đã xảy ra nhiều ngày nhưng lãnh đạo chỉ biết tại cuộc họp tuần.

Nếu dữ liệu nằm trong quá nhiều Excel, email và nhóm chat.

Đó là thời điểm doanh nghiệp nên nghĩ đến một phần mềm quản lý dự án xây dựng có khả năng quản lý ở cả cấp dự án và cấp danh mục.

Excel không phải công cụ kém.

Excel rất mạnh trong phân tích cá nhân.

Vấn đề xuất hiện khi doanh nghiệp sử dụng công cụ cá nhân để giải quyết bài toán cộng tác của hàng chục hoặc hàng trăm người.

Càng nhiều người tham gia, việc kiểm soát phiên bản, quyền chỉnh sửa, lịch sử thay đổi và dữ liệu chính thức càng khó.

14. TBT360 hỗ trợ chủ đầu tư quản lý nhiều dự án như thế nào?

Khi xây dựng hệ thống quản lý nhiều dự án, giá trị không nằm ở việc đưa thật nhiều biểu đồ lên màn hình.

Giá trị nằm ở dữ liệu phía dưới các biểu đồ đó.

TBT360 là hệ sinh thái giải pháp số của Công ty Cổ phần Công nghệ TBT Việt Nam, hướng tới các nghiệp vụ quản lý dự án, quản lý thi công, BIM, CDE và nghiệm thu trong ngành xây dựng.

Trong đó, QLDA 360 tập trung vào bài toán quản lý dự án cho chủ đầu tư và Ban quản lý dự án với các nhóm dữ liệu như tiến độ, tiến độ pháp lý, cảnh báo, vốn, hợp đồng, báo cáo và khai thác dữ liệu BIM/CDE.

Mục tiêu không phải thay thế người quản lý dự án.

Mục tiêu là giúp người quản lý có một nguồn dữ liệu thống nhất hơn để ra quyết định.

Khi dữ liệu được cập nhật tại nơi phát sinh, dashboard có thể tổng hợp trạng thái của từng dự án và toàn bộ danh mục.

Lãnh đạo có thể bắt đầu từ màn hình tổng quan.

Khi thấy một dự án bất thường, người dùng đi xuống dự án.

Từ dự án đi xuống nhóm vấn đề.

Từ nhóm vấn đề đi tới đầu việc.

Như vậy, thay vì đợi Ban QLDA làm một bản báo cáo mới mỗi khi có câu hỏi, lãnh đạo có thể khai thác dữ liệu trực tiếp trên hệ thống.

Với những chủ đầu tư đang quản lý nhiều dự án, đây là sự thay đổi quan trọng.

Từ quản lý bằng báo cáo sang quản lý bằng dữ liệu.

15. Phần mềm không thay người quản lý nhưng giúp người quản lý không bỏ sót tín hiệu quan trọng

Một phần mềm tốt không thể thay hoàn toàn Project Manager.

Phần mềm không tự quyết định một thay đổi thiết kế nên được phê duyệt hay không.

Không tự thương lượng với nhà thầu.

Không thay kỹ sư giải quyết mọi vấn đề ngoài hiện trường.

Nhưng hệ thống có một lợi thế rất rõ.

Nó có thể theo dõi dữ liệu liên tục.

Một người khó nhớ hàng trăm deadline.

Hệ thống có thể kiểm tra mỗi ngày.

Một người khó so sánh tình trạng của 30 dự án cùng lúc.

Dashboard có thể tổng hợp.

Một người có thể bỏ sót một hồ sơ sắp quá hạn.

Hệ thống có thể cảnh báo.

Do đó, giá trị của phần mềm quản lý dự án không nằm ở việc thay con người.

Giá trị nằm ở việc giúp con người dành ít thời gian hơn cho tổng hợp dữ liệu và nhiều thời gian hơn cho quyết định.

Đây cũng là hướng tiếp cận phù hợp khi doanh nghiệp tiến tới AI.

AI có thể hỗ trợ đọc dữ liệu, nhận diện bất thường hoặc hỗ trợ dự báo.

Nhưng trách nhiệm cuối cùng đối với quyết định quản trị vẫn nằm ở con người.

16. Quản lý nhiều dự án cuối cùng là bài toán quản trị dữ liệu

Khi số lượng dự án tăng, bài toán không còn chỉ là tiến độ.

Nó trở thành bài toán dữ liệu.

Dữ liệu nào là chính thức?

Ai cập nhật?

Cập nhật khi nào?

Dự án nào sử dụng cùng một cấu trúc?

Ngưỡng nào được coi là bất thường?

Vấn đề nào phải cảnh báo?

Vấn đề nào cần escalated lên lãnh đạo?

Một hệ thống phần mềm chỉ thực sự hiệu quả khi những nguyên tắc này được xác định rõ.

Công nghệ giúp doanh nghiệp thực thi quy trình.

Nhưng bản thân công nghệ không thể thay thế một quy trình quản lý chưa được thiết kế.

Vì vậy, khi triển khai TBT360 hoặc bất kỳ phần mềm quản lý dự án xây dựng nào, doanh nghiệp nên đồng thời chuẩn hóa quy trình báo cáo, cấu trúc dữ liệu và trách nhiệm cập nhật.

Đó mới là cách tạo ra một hệ thống có khả năng mở rộng từ 5 dự án lên 20 dự án, 50 dự án hoặc nhiều hơn.

17. Làm sao biết dự án nào đang có vấn đề?

Cuối cùng, câu trả lời không nằm trong một KPI duy nhất.

Một dự án có thể đúng tiến độ nhưng có rủi ro chi phí.

Một dự án có chi phí ổn nhưng đang tồn đọng pháp lý.

Một dự án đã hoàn thành pháp lý nhưng thiết kế chưa được phê duyệt.

Một dự án có thiết kế tốt nhưng nhà thầu chưa huy động đủ nguồn lực.

Vì vậy, chủ đầu tư phải nhìn dự án theo nhiều chiều.

Tiến độ cho biết công việc đang chạy thế nào.

Chi phí cho biết khả năng kiểm soát ngân sách.

Pháp lý cho biết điều kiện thực hiện.

Hợp đồng cho biết phạm vi, trách nhiệm và cam kết.

Hồ sơ cho biết dòng thông tin có đang vận hành hay không.

Rủi ro và issue cho biết các vấn đề chưa được giải quyết.

Khi các dữ liệu này được kết nối, chủ đầu tư có một bức tranh gần với tình trạng thực của dự án hơn.

Mục tiêu cuối cùng của dashboard quản lý nhiều dự án không phải tạo ra một màn hình đẹp.

Mục tiêu là để lãnh đạo có thể mở hệ thống và trong vài phút trả lời được năm câu hỏi:

Dự án nào đang có vấn đề?

Vấn đề nằm ở đâu?

Mức độ ảnh hưởng thế nào?

Ai đang chịu trách nhiệm?

Có cần can thiệp ngay không?

Nếu doanh nghiệp vẫn cần vài ngày tổng hợp dữ liệu mới trả lời được những câu hỏi trên, đó là dấu hiệu cho thấy bài toán không còn nằm ở năng lực của từng Project Manager.

Nó nằm ở hệ thống quản trị dự án.

18. Kết luận

Quản lý nhiều dự án không có nghĩa là lãnh đạo phải đọc nhiều báo cáo hơn.

Ngược lại, một hệ thống quản lý tốt phải giúp lãnh đạo đọc ít hơn nhưng hiểu được nhiều hơn.

Không cần nhìn tất cả công việc.

Cần nhìn đúng công việc đang có nguy cơ.

Không cần kiểm tra tất cả hồ sơ.

Cần biết hồ sơ nào đang ảnh hưởng đến tiến độ.

Không cần xem toàn bộ chi phí chi tiết.

Cần biết dự án nào đang có xu hướng vượt ngân sách.

Không cần gọi từng Ban QLDA để hỏi tình hình.

Cần một nguồn dữ liệu đủ tin cậy để nhìn thấy tình hình.

Đó chính là giá trị của việc quản lý danh mục dự án bằng dữ liệu.

Đối với chủ đầu tư đang vận hành nhiều dự án cùng lúc, việc xây dựng một hệ thống quản lý tập trung không chỉ giúp giảm thời gian báo cáo mà còn tạo nền tảng cho cảnh báo sớm, phân tích xu hướng và các ứng dụng AI trong tương lai.

TBT360 hướng tới việc hỗ trợ doanh nghiệp xây dựng nền tảng đó thông qua các giải pháp quản lý dự án, quản lý thi công, BIM, CDE và nghiệm thu được phát triển cho đặc thù ngành xây dựng Việt Nam.

Khi dữ liệu được chuẩn hóa và kết nối, câu hỏi “Dự án nào đang có vấn đề?” không còn phải chờ đến cuộc họp tuần mới có câu trả lời.

Nó có thể trở thành một thông tin mà lãnh đạo nhìn thấy hàng ngày.

Thông tin liên hệ

Nếu doanh nghiệp đang quản lý nhiều dự án và gặp khó khăn trong việc tổng hợp tiến độ, pháp lý, hợp đồng, nguồn vốn, hồ sơ hoặc báo cáo từ nhiều Ban quản lý dự án, có thể trao đổi với TBT Việt Nam để tìm hiểu mô hình triển khai QLDA 360 và hệ sinh thái TBT360 phù hợp với quy trình hiện tại.

Công ty Cổ phần Công nghệ TBT Việt Nam

Hệ sinh thái giải pháp: TBT360

Giải pháp quản lý dự án: QLDA 360

Website: https://bimxaydung.com/

Trụ sở: 122 đường Lê Lai, Khu phố 4, Phường Quang Trung, Tỉnh Thanh Hóa.

Cơ sở 2: CT5A, Khu đô thị Xa La, Hà Đông, Hà Nội.

Cơ sở 3: B3, Fresca Riverside, Tam Bình, Thành phố Hồ Chí Minh.