BIM không cứu được dự án nếu tư duy quản lý vẫn rời rạc
BIM thường được giới thiệu như một bước nhảy công nghệ của ngành xây dựng. Nhưng trong nhiều dự án, vấn đề không nằm ở chỗ đội ngũ có mô hình 3D hay không. Vấn đề nằm ở chỗ dự án vẫn được quản lý bằng một tư duy rời rạc: thiết kế một nơi, QS một nơi, công trường một nơi, chủ đầu tư một nơi, và mọi người chỉ gặp nhau khi có va chạm.
Tôi không phủ nhận BIM. Ngược lại, BIM là một trong những công cụ hiếm hoi buộc ngành xây dựng phải nhìn công trình như một hệ thống thay vì một tập bản vẽ. Nhưng chính vì BIM mạnh, nó cũng làm lộ ra một sự thật khó chịu: nếu tư duy quản lý dự án vẫn rời rạc, BIM chỉ trở thành một lớp trình diễn đẹp hơn cho cùng một sự hỗn loạn cũ.
BIM không phải cây đũa thần
Trong nhiều buổi họp, BIM được nhắc đến như một giải pháp tổng quát: giảm clash, kiểm soát khối lượng, hỗ trợ tiến độ, liên kết dữ liệu, cải thiện phối hợp. Những điều đó đúng, nhưng chỉ đúng khi phía sau mô hình có một quy trình ra quyết định rõ ràng. Nếu không, BIM chỉ giúp chúng ta phát hiện lỗi nhanh hơn, chứ không tự sửa được cách một dự án đang vận hành.
Một mô hình có thể chỉ ra ống gió đang đụng dầm. Nhưng mô hình không thể tự quyết định ai có quyền thay đổi cao độ trần, ai chịu trách nhiệm cập nhật bản vẽ, thay đổi đó ảnh hưởng chi phí bao nhiêu, có cần chủ đầu tư phê duyệt không, và công trường đang thi công đến đâu. Những câu hỏi đó không thuộc về phần mềm. Chúng thuộc về quản lý.
Rời rạc bắt đầu từ cách chia việc
Ngành xây dựng quen chia dự án thành các gói: kiến trúc, kết cấu, MEP, QS, pháp lý, thi công, giám sát. Chia việc là cần thiết, nhưng chia xong rồi để mỗi nhóm tự chạy theo logic riêng là nguồn gốc của rất nhiều vấn đề. Khi BIM được đặt lên trên một cấu trúc như vậy, mô hình sẽ phản ánh chính sự phân mảnh đó.
Kiến trúc cập nhật layout nhưng MEP chưa biết. MEP chỉnh tuyến ống nhưng QS chưa cập nhật khối lượng. QS cắt chi phí nhưng công trường không được giải thích lý do. Công trường xử lý một chi tiết thực tế nhưng model không được cập nhật. Sau vài vòng như vậy, BIM không còn là “single source of truth” nữa. Nó trở thành một phiên bản khác của bản vẽ: có vẻ chính xác, nhưng mọi người vẫn phải hỏi nhau “bản nào mới nhất?”.
Vấn đề lớn nhất không phải clash, mà là quyền quyết định
Clash detection là lợi ích dễ thấy nhất của BIM, nên nhiều người nghĩ BIM implementation đồng nghĩa với việc dựng model và chạy va chạm. Nhưng va chạm hình học chỉ là phần nổi. Phần khó hơn là va chạm trách nhiệm. Ai được quyền ưu tiên hệ nào? Khi kiến trúc, kết cấu và MEP cùng muốn một không gian, tiêu chí nào quyết định? Khi tiến độ và chất lượng mâu thuẫn, ai chịu trách nhiệm chọn phương án?
Nếu dự án không định nghĩa rõ quyền quyết định, BIM meeting sẽ biến thành một cuộc họp dài hơn với nhiều hình ảnh hơn. Mọi người nhìn thấy vấn đề rõ hơn, nhưng vẫn không ai có đủ thẩm quyền hoặc dữ liệu để kết luận. Công nghệ lúc đó không làm dự án nhanh hơn; nó chỉ làm sự do dự trở nên trực quan hơn.
BIM cần một nhịp quản lý, không chỉ một BIM team
Một sai lầm phổ biến là xem BIM như trách nhiệm của “BIM team”. Đội BIM dựng model, kiểm tra clash, xuất report, gửi cho các bên. Nghe hợp lý, nhưng cách này dễ biến BIM thành một bộ phận hậu kiểm. Khi BIM chỉ xuất hiện sau khi các bên đã thiết kế xong, nó giống người đi tìm lỗi hơn là người giúp dự án ra quyết định tốt hơn.
BIM nên nằm trong nhịp quản lý dự án: khi nào khóa layout, khi nào khóa trục kỹ thuật, khi nào chốt không gian trần, khi nào cập nhật khối lượng, khi nào bản vẽ đi công trường, khi nào thay đổi phải quay lại model. Nếu những mốc này không rõ, mô hình dù đẹp cũng không có sức nặng trong vận hành.
Dữ liệu không tự có ý nghĩa
BIM tạo ra rất nhiều dữ liệu. Nhưng dữ liệu chỉ có giá trị khi biết dùng để trả lời câu hỏi nào. Một model có hàng nghìn object, parameter và sheet không giúp dự án tốt hơn nếu không ai biết dữ liệu đó phục vụ quyết định gì. Quản lý rời rạc thường thích tích dữ liệu nhưng không thiết kế luồng sử dụng dữ liệu.
Ví dụ, nếu muốn dùng BIM để kiểm soát chi phí, model phải được tổ chức theo logic bóc tách và mua sắm. Nếu muốn dùng BIM cho tiến độ, model phải liên kết với WBS và trình tự thi công. Nếu muốn dùng BIM cho vận hành, thông tin thiết bị phải được chuẩn hóa từ đầu. Không thể đến cuối dự án mới hỏi model có phục vụ FM được không.
Tại sao dự án vẫn chậm dù đã dùng BIM?
Vì BIM thường được đưa vào như một công cụ kỹ thuật, trong khi nguyên nhân chậm tiến độ lại nằm ở quản trị thay đổi, phối hợp ra quyết định và kỷ luật thông tin. Một dự án có thể có model tốt nhưng vẫn chậm vì phê duyệt kéo dài, scope thay đổi liên tục, chủ đầu tư chưa chốt tiêu chuẩn, nhà thầu phụ vào muộn, hoặc công trường xử lý bằng kinh nghiệm mà không phản hồi về thiết kế.
Nói cách khác, BIM không thay thế được sự rõ ràng. Nó cần một cơ chế để biến phát hiện thành quyết định, quyết định thành hành động, và hành động thành cập nhật dữ liệu. Thiếu vòng lặp này, BIM report chỉ là một tài liệu đẹp trong email.
Nói vui một chút: nếu dự án đã quen họp ba tiếng để quyết một cái trần cao bao nhiêu, BIM không làm cuộc họp đó thành “digital transformation”. Nó chỉ giúp mọi người nhìn cái trần đó bằng 3D trong lúc vẫn chưa ai dám quyết. Công nghệ không chữa được bệnh né quyết định; đôi khi nó chỉ chiếu đèn mạnh hơn vào căn bệnh đó.
Muốn BIM có ích, hãy bắt đầu từ BEP thật sự
BEP – BIM Execution Plan – không nên là một tài liệu copy từ dự án trước để đủ thủ tục. Nó phải trả lời những câu hỏi rất thực tế: BIM dùng để làm gì trong dự án này? Ai tạo model? Ai kiểm tra? Ai phê duyệt? Mức độ chi tiết đến đâu là đủ? Dữ liệu nào bắt buộc? Khi thay đổi thì quy trình cập nhật ra sao? Model nào được xem là bản chính? Công trường được nhận thông tin theo định dạng nào?
Một BEP tốt không cần dài một cách phô trương. Nó cần rõ. Rõ về mục tiêu, rõ về vai trò, rõ về mốc, rõ về trách nhiệm. Khi BEP chỉ nói về phần mềm mà không nói về cách dự án ra quyết định, nó chưa phải kế hoạch thực thi BIM; nó chỉ là tài liệu IT.
BIM tốt nhất khi nó làm cho cuộc họp ngắn hơn
Một dấu hiệu cho thấy BIM đang đi đúng hướng là cuộc họp phối hợp ngắn hơn, không phải dài hơn. Mọi người đến họp đã biết vấn đề, phương án, người chịu trách nhiệm và deadline. Model là nền để ra quyết định, không phải màn hình để mọi người cùng phát hiện vấn đề lần đầu.
Nếu mỗi BIM meeting đều biến thành buổi mở model và tranh luận từ đầu, dự án chưa có workflow. Lúc đó, BIM đang bị dùng như sân khấu của sự thiếu chuẩn bị.
Điều BIM đòi hỏi ở người quản lý dự án
BIM buộc người quản lý dự án phải hiểu nhiều hơn về logic thông tin. Không nhất thiết PM phải model giỏi, nhưng PM phải biết model đang phục vụ quyết định nào. PM phải biết khi nào một thay đổi nhỏ trong layout có thể kéo theo thay đổi lớn về MEP, PCCC, chi phí hoặc tiến độ. PM cũng phải biết yêu cầu đội dự án cập nhật thông tin theo kỷ luật, thay vì để mỗi bên giữ một “sự thật” riêng.
Trong môi trường đó, vai trò của kiến trúc sư hoặc design manager cũng thay đổi. Không chỉ bảo vệ ý tưởng thiết kế, họ phải bảo vệ tính liên tục của thông tin. Một phương án đẹp nhưng làm gãy chuỗi phối hợp có thể không còn là phương án tốt.
Vậy BIM cứu được điều gì?
BIM cứu được rất nhiều thứ nếu dự án đã sẵn sàng để được cứu. Nó giúp nhìn thấy xung đột sớm hơn, mô phỏng rõ hơn, kiểm soát dữ liệu tốt hơn, và buộc các bên nói chuyện trên một nền thông tin chung. Nhưng BIM không cứu được một dự án mà quyết định luôn đến muộn, trách nhiệm luôn mờ, và mỗi bên chỉ tối ưu phần việc của mình.
BIM không thay thế tư duy quản lý. Nó khuếch đại tư duy quản lý. Nếu tư duy đó tích hợp, BIM làm nó mạnh hơn. Nếu tư duy đó rời rạc, BIM làm sự rời rạc hiện ra rõ hơn.
Ba tầng rời rạc thường bị nhầm là lỗi BIM
Khi BIM không tạo ra hiệu quả như mong đợi, người ta thường đổ lỗi cho phần mềm, cho BIM modeler, hoặc cho việc đội ngũ chưa đủ kỹ năng. Những lý do đó có thể đúng một phần, nhưng chúng chưa chạm vào phần sâu hơn. Trong nhiều dự án, sự rời rạc tồn tại ở ba tầng: rời rạc mục tiêu, rời rạc quy trình và rời rạc trách nhiệm.
Rời rạc mục tiêu xảy ra khi mỗi bên kỳ vọng BIM phục vụ một việc khác nhau. Chủ đầu tư muốn kiểm soát chi phí. Tư vấn muốn phối hợp thiết kế. Nhà thầu muốn shop drawing nhanh hơn. Đội vận hành muốn dữ liệu thiết bị. Nếu không thống nhất từ đầu, cùng một model sẽ bị kéo theo nhiều hướng, cuối cùng không phục vụ tốt mục tiêu nào.
Rời rạc quy trình xảy ra khi dự án không định nghĩa đường đi của thông tin. Ai gửi gì, gửi lúc nào, theo chuẩn nào, ai kiểm tra, ai trả lời, ai chốt? Không có quy trình này, BIM platform chỉ là nơi chứa file. Một nơi chứa file tốt hơn email, nhưng vẫn không phải một hệ thống quản lý dự án.
Rời rạc trách nhiệm là tầng nguy hiểm nhất. Khi một lỗi được phát hiện, nếu không biết ai quyết, ai sửa, ai chịu ảnh hưởng và ai cập nhật lại dữ liệu, lỗi đó sẽ trôi từ cuộc họp này sang cuộc họp khác. BIM giúp lỗi trở nên nhìn thấy được; nhưng nếu trách nhiệm mờ, sự nhìn thấy đó không tự biến thành hành động.
Ở Việt Nam, BIM còn bị kéo bởi văn hóa xử lý tình huống
Tôi nghĩ một phần khó của BIM trong bối cảnh Việt Nam nằm ở văn hóa dự án. Chúng ta rất giỏi xử lý tình huống. Công trường gặp vấn đề thì tìm cách xoay, chỉnh, né, làm cho kịp. Khả năng đó có giá trị, nhưng khi trở thành thói quen chính, nó làm BIM yếu đi. BIM cần dự báo, chuẩn hóa và phản hồi dữ liệu. Văn hóa xử lý tình huống lại thường dựa vào kinh nghiệm cá nhân, cuộc gọi nhanh và quyết định không được ghi nhận đầy đủ.
Điều này không có nghĩa là kinh nghiệm công trường thấp hơn BIM. Ngược lại, BIM tốt phải hấp thụ được kinh nghiệm công trường. Nhưng để làm được vậy, kinh nghiệm đó phải quay lại thành thông tin: thay đổi gì, vì sao thay đổi, ảnh hưởng hệ nào, có cập nhật model không, có cập nhật khối lượng không, có ảnh hưởng nghiệm thu không. Nếu công trường luôn “xử lý xong rồi tính”, model sẽ ngày càng xa thực tế.
Nhiều dự án vẫn sống bằng những người rất giỏi nhớ. Người này nhớ phiên bản bản vẽ mới nhất, người kia nhớ thỏa thuận trong cuộc họp, người khác nhớ chi tiết ngoài công trường. Nhưng một dự án phức tạp không nên phụ thuộc vào trí nhớ của vài cá nhân. BIM, nếu được dùng đúng, là cách chuyển trí nhớ cá nhân thành trí nhớ tổ chức. Nhưng điều đó chỉ xảy ra khi đội dự án có kỷ luật cập nhật và chia sẻ thông tin.
BIM không sửa được hợp đồng mơ hồ
Một nguyên nhân khác khiến BIM không phát huy hiệu quả là hợp đồng và phạm vi công việc không rõ. BIM đòi hỏi nhiều việc nằm giữa các ranh giới truyền thống: ai dựng model hiện trạng, ai cập nhật model sau thay đổi, ai chịu trách nhiệm clash giữa thiết kế và shop drawing, mức độ chi tiết nào được thanh toán, dữ liệu nào bàn giao cho vận hành. Nếu hợp đồng không nói rõ, mỗi bên sẽ hiểu BIM theo cách có lợi cho mình.
Khi đó, BIM trở thành một nghĩa vụ “thêm” chứ không phải cách làm việc chính. Tư vấn làm model để đáp ứng yêu cầu, nhà thầu làm model để qua bước phối hợp, chủ đầu tư nhận model nhưng không chắc dùng để làm gì. Kết quả là mọi người đều có BIM, nhưng không ai thật sự quản lý dự án bằng BIM.
Nếu muốn BIM nghiêm túc, phạm vi BIM phải đi vào hợp đồng, tiến độ, deliverables và tiêu chí nghiệm thu. Không cần biến hợp đồng thành tài liệu kỹ thuật dày đặc, nhưng phải đủ rõ để khi có tranh luận, dự án biết quay về đâu. Một mô hình không thể thay thế một phạm vi công việc mơ hồ.
Đừng bắt đầu bằng phần mềm, hãy bắt đầu bằng câu hỏi quản lý
Nếu một công ty hỏi “nên dùng phần mềm BIM nào?”, tôi thường nghĩ câu hỏi đó đến hơi sớm. Câu hỏi trước đó nên là: chúng ta muốn kiểm soát điều gì tốt hơn? Thiết kế? Clash? Khối lượng? Tiến độ? Chi phí? Vận hành? Hay giao tiếp giữa văn phòng và công trường?
Mỗi mục tiêu kéo theo một cách tổ chức model khác nhau. Model để diễn họa khác model để phối hợp kỹ thuật. Model để bóc khối lượng khác model để vận hành. Model để phục vụ nhà thầu khác model để chủ đầu tư quản lý tài sản. Nếu không xác định mục tiêu, đội BIM dễ làm một model “có vẻ đầy đủ” nhưng không đủ sâu cho bất kỳ quyết định quan trọng nào.
Đây cũng là lý do nhiều dự án đầu tư nhiều vào mô hình nhưng ít đầu tư vào cấu trúc thông tin. Họ có 3D, có sheet, có clash report, nhưng không có naming convention rõ, không có trạng thái thông tin rõ, không có quy trình phê duyệt rõ, không có người chịu trách nhiệm dữ liệu rõ. Nhìn bên ngoài rất digital; bên trong vẫn là cách quản lý cũ.
Khi nào BIM thật sự đáng tiền?
BIM đáng tiền khi nó giảm được số lần dự án phải đoán. Đoán bản vẽ nào mới nhất. Đoán thay đổi này ảnh hưởng hệ nào. Đoán khối lượng tăng vì đâu. Đoán công trường đã thi công theo phiên bản nào. Đoán thiết bị nào cần thông tin bàn giao. Mỗi lần bớt đoán là một lần dự án bớt rủi ro.
BIM cũng đáng tiền khi nó làm cho các cuộc tranh luận bớt cảm tính. Thay vì nói “tôi nghĩ tuyến ống này đi được”, đội dự án có thể nhìn vào không gian, cao độ, xung đột, trình tự thi công. Thay vì tranh luận khối lượng theo cảm giác, có thể kiểm tra logic bóc tách. Thay vì đợi đến công trường mới biết không đủ không gian bảo trì, có thể thấy sớm trong model.
Nhưng BIM chỉ đáng tiền nếu kết quả đó được dùng. Clash report không được đóng issue thì không có giá trị. Model 4D không liên kết với quyết định tiến độ thì chỉ là animation. Quantity takeoff không liên kết với mua sắm thì chỉ là con số tham khảo. Dữ liệu không đi vào quyết định thì vẫn chỉ là dữ liệu.
Một cách nhìn thực tế hơn về triển khai BIM
Thay vì bắt đầu bằng tham vọng “BIM toàn diện”, nhiều tổ chức nên bắt đầu bằng một vài use case rõ ràng. Ví dụ: dùng BIM để kiểm soát không gian kỹ thuật trong giai đoạn thiết kế; dùng BIM để phối hợp MEP trước khi phát hành hồ sơ thi công; dùng BIM để kiểm soát thay đổi khối lượng của một nhóm hạng mục quan trọng; hoặc dùng BIM để chuẩn hóa dữ liệu thiết bị bàn giao.
Mỗi use case cần có mục tiêu, người phụ trách, tiêu chí thành công và cách đo lường. Khi một use case chạy tốt, tổ chức mới mở rộng. Cách này chậm hơn về khẩu hiệu nhưng nhanh hơn về hiệu quả thật. Nó giúp BIM đi vào thói quen quản lý thay vì trở thành một dự án công nghệ riêng biệt.
Điều quan trọng là đừng nhầm “có BIM” với “đang chuyển đổi số”. Chuyển đổi số không phải là dùng phần mềm mới để giữ nguyên cách phối hợp cũ. Chuyển đổi số là thay đổi cách thông tin di chuyển, cách quyết định được đưa ra và cách trách nhiệm được ghi nhận.
Vai trò mới của kiến trúc sư trong một dự án có BIM
Kiến trúc sư trong dự án có BIM không thể chỉ đứng ở vai trò tạo hình và phát hành bản vẽ. Kiến trúc sư phải hiểu thiết kế của mình đang đi qua những hệ thống nào: kết cấu, MEP, PCCC, chi phí, tiến độ, vận hành. Một quyết định về mặt bằng hoặc không gian không còn nằm riêng trong “ý tưởng kiến trúc”; nó trở thành một nút trong mạng lưới thông tin.
Điều này không làm kiến trúc sư mất đi vai trò sáng tạo. Ngược lại, nó làm vai trò đó nghiêm túc hơn. Sáng tạo không chỉ là tạo ra hình thức mới, mà là tạo ra một giải pháp có thể tồn tại qua nhiều lớp ràng buộc. BIM buộc kiến trúc sư nhìn rõ hơn những ràng buộc đó, nhưng chính kiến trúc sư phải quyết định cách biến chúng thành chất lượng không gian.
Trong tương lai, kiến trúc sư giỏi có thể không phải người biết nhiều lệnh phần mềm nhất, mà là người biết đặt câu hỏi đúng cho mô hình: thông tin này có đáng tin không, quyết định này ảnh hưởng ai, thay đổi này có được ghi nhận chưa, và giải pháp này có còn giữ được ý đồ ban đầu không.
Một mô hình tốt không cứu được một tổ chức không biết học
Điều tôi quan sát thấy trong nhiều dự án là các lỗi lặp lại không phải vì đội ngũ không nhìn thấy lỗi. Họ thấy. Họ thậm chí thấy rất rõ. Nhưng dự án không có cơ chế học từ lỗi đó. Một clash được xử lý trong dự án này, rồi sang dự án khác lại xuất hiện dưới hình thức gần như tương tự. Một bài học về cao độ trần, không gian kỹ thuật, route ống, phòng bơm, phòng điện, hoặc trình tự shop drawing không được chuyển thành tiêu chuẩn làm việc.
BIM có thể trở thành bộ nhớ tổ chức, nhưng chỉ khi tổ chức muốn học. Nếu mỗi dự án kết thúc rồi mọi người tản ra, không có review, không có cập nhật template, không có thư viện chi tiết, không có lesson learned, thì BIM chỉ là dữ liệu chết. Nó nằm trong server như một bằng chứng rằng chúng ta từng làm việc rất vất vả, nhưng không giúp dự án sau bớt vất vả hơn.
Một tổ chức biết học sẽ hỏi: clash nào lặp lại nhiều nhất, quyết định nào thường đến muộn, bộ môn nào hay thiếu thông tin đầu vào, loại thay đổi nào làm đội QS cập nhật chậm, chi tiết nào ra công trường thường phải sửa. Những câu hỏi này không hào nhoáng, nhưng chúng biến BIM từ công cụ dựng hình thành công cụ cải tiến quản lý.
Từ BIM model đến BIM culture
Điều khó nhất không phải là tạo ra BIM model. Điều khó nhất là tạo ra BIM culture – một văn hóa làm việc trong đó thông tin được tôn trọng. Văn hóa đó bắt đầu từ những việc nhỏ: không gửi bản vẽ không rõ version, không quyết miệng những thứ ảnh hưởng nhiều bộ môn, không xem việc cập nhật model là việc phụ, không để công trường tự xử lý rồi thiết kế biết sau.
BIM culture cũng đòi hỏi sự khiêm tốn. Mô hình không phải lúc nào cũng đúng. Người model có thể sai. Dữ liệu có thể thiếu. Công trường có thể có lý do thực tế mà model chưa phản ánh. Nhưng thay vì dùng sai sót đó để phủ nhận BIM, một văn hóa tốt sẽ dùng nó để cải thiện vòng phản hồi. Model học từ công trường, công trường học từ model, thiết kế học từ cả hai.
Khi văn hóa này chưa có, BIM dễ trở thành một cuộc chiến quyền lực. Ai giữ model thì người đó giữ sự thật. Ai giỏi phần mềm thì người đó có tiếng nói kỹ thuật. Ai không biết mở model thì bị đẩy ra ngoài cuộc thảo luận. Đây là một rủi ro thật. BIM không nên tạo ra một tầng chuyên gia mới tách khỏi dự án; nó nên làm cho thông tin dự án dễ hiểu hơn với nhiều người hơn.
BIM và vai trò của chủ đầu tư
Chủ đầu tư thường được khuyên yêu cầu BIM trong dự án. Nhưng yêu cầu BIM mà không biết mình cần gì từ BIM có thể tạo thêm chi phí mà không tạo thêm giá trị. Chủ đầu tư không nhất thiết phải hiểu sâu phần mềm, nhưng cần hiểu mình muốn kiểm soát điều gì: tiến độ, chi phí, chất lượng thiết kế, rủi ro thi công, dữ liệu vận hành hay khả năng phối hợp giữa các bên.
Nếu chủ đầu tư chỉ yêu cầu “có BIM” trong hồ sơ mời thầu, các bên sẽ đáp ứng bằng cách tối thiểu nhất để đạt yêu cầu. Nhưng nếu chủ đầu tư nói rõ “tôi muốn dùng BIM để kiểm soát thay đổi khối lượng MEP”, hoặc “tôi muốn dữ liệu thiết bị bàn giao phục vụ vận hành”, hoặc “tôi muốn kiểm tra xung đột không gian kỹ thuật trước khi phát hành bản vẽ thi công”, dự án sẽ có hướng rõ hơn.
Vai trò của chủ đầu tư còn nằm ở việc bảo vệ kỷ luật quyết định. Nếu chủ đầu tư thay đổi yêu cầu liên tục nhưng không cho phép cập nhật tiến độ và chi phí tương ứng, BIM cũng không cứu được dự án. Model có thể phản ánh thay đổi, nhưng không thể hấp thụ vô hạn sự bất định. Một dự án muốn dùng BIM hiệu quả cần một chủ đầu tư hiểu rằng thay đổi thông tin là thay đổi dự án.
BIM và khoảng cách giữa văn phòng với công trường
Một trong những khoảng cách lớn nhất của ngành xây dựng là khoảng cách giữa văn phòng và công trường. Văn phòng tạo ra bản vẽ, model, báo cáo. Công trường đối diện với thời tiết, vật tư, nhân công, máy móc, biện pháp thi công, thói quen nhà thầu phụ và áp lực tiến độ. Nếu BIM chỉ sống trong văn phòng, nó sẽ không chạm được vào phần khó nhất của dự án.
Muốn BIM đi tới công trường, thông tin phải được chuyển thành dạng công trường dùng được. Không phải ai ngoài công trường cũng cần mở model đầy đủ. Có khi họ cần một view rõ, một sequence thi công, một detail đã phối hợp, một QR dẫn đến bản vẽ mới nhất, hoặc một issue có hình ảnh và người chịu trách nhiệm. BIM không nhất thiết phải hiện diện dưới dạng phần mềm phức tạp; nó có thể hiện diện dưới dạng thông tin đúng, đến đúng người, đúng thời điểm.
Ngược lại, công trường cũng phải có đường quay lại model. Khi có điều chỉnh thực tế, thông tin đó không thể chỉ nằm trong nhật ký công trường hoặc nhóm chat. Nó cần được phân loại: thay đổi này có ảnh hưởng thiết kế không, có ảnh hưởng khối lượng không, có ảnh hưởng vận hành không, có cần as-built không. Nếu không, model sẽ càng ngày càng trở thành một ký ức song song, đẹp nhưng không còn đại diện cho công trình thật.
BIM không làm giảm vai trò của con người, nó làm lộ chất lượng phối hợp của con người
Có một ảo tưởng phổ biến trong chuyển đổi số: càng nhiều công nghệ thì càng ít phụ thuộc vào con người. Trong xây dựng, điều này chỉ đúng một phần rất nhỏ. Công nghệ có thể giảm thao tác lặp lại, tăng khả năng kiểm tra, làm rõ dữ liệu. Nhưng các quyết định quan trọng vẫn cần con người: ưu tiên gì, đánh đổi gì, chấp nhận rủi ro nào, giữ chất lượng nào, bỏ yêu cầu nào, thay đổi tiến độ ra sao.
BIM làm lộ chất lượng phối hợp của con người. Nếu một nhóm làm việc có kỷ luật, BIM giúp họ nhanh hơn. Nếu một nhóm quen làm việc mơ hồ, BIM làm sự mơ hồ đó hiện rõ hơn. Nếu một tổ chức tôn trọng dữ liệu, BIM trở thành tài sản. Nếu một tổ chức chỉ tôn trọng quyền lực cá nhân, BIM trở thành một công cụ để tranh luận xem dữ liệu của ai đúng.
Đó là lý do tôi nghĩ BIM implementation không nên giao hoàn toàn cho bộ phận kỹ thuật. Nó phải là một quyết định quản trị. Nó liên quan đến hợp đồng, quy trình, vai trò, đào tạo, văn hóa phản hồi, cách đo hiệu quả và cách tổ chức ra quyết định. Nếu chỉ nhìn BIM như phần mềm, chúng ta đã thu nhỏ vấn đề ngay từ đầu.
Nghe có vẻ hơi nghiêm trọng, nhưng thật ra rất đời thường: một dự án dùng BIM tốt thường không phải vì họ có người bấm Revit như nghệ sĩ piano. Họ tốt vì họ biết ai cần biết gì, vào lúc nào, để quyết việc gì. Phần mềm chỉ là cây đàn; bản nhạc vẫn do cách tổ chức chơi với nhau quyết định.
BIM maturity không phải là số phần mềm đang dùng
Nhiều tổ chức đánh giá mức độ trưởng thành BIM bằng số lượng phần mềm, số người biết model, hoặc số dự án đã yêu cầu BIM. Những chỉ số đó có ích, nhưng chưa đủ. Một tổ chức có thể dùng nhiều phần mềm mà vẫn chưa trưởng thành nếu mỗi dự án phải phát minh lại quy trình từ đầu. Ngược lại, một tổ chức dùng ít công cụ hơn nhưng có chuẩn thông tin rõ, vai trò rõ, cách review rõ, cách học từ dự án cũ rõ, thì lại trưởng thành hơn.
BIM maturity nên được nhìn như năng lực quản lý thông tin qua nhiều dự án. Sau mỗi dự án, tổ chức có tốt hơn không? Template có được cải thiện không? Thư viện có được làm sạch không? Quy trình phối hợp có ngắn hơn không? Những lỗi lặp lại có giảm không? Nếu câu trả lời là không, BIM đang dừng ở mức sản xuất deliverable chứ chưa trở thành năng lực tổ chức.
Một dấu hiệu trưởng thành khác là khả năng nói “không cần BIM cho việc này”. Không phải mọi thứ đều cần model phức tạp. Có những quyết định chỉ cần một sơ đồ, một bảng trách nhiệm, một bản vẽ rõ, hoặc một cuộc họp có người quyết. Khi tổ chức hiểu BIM phục vụ mục tiêu nào, họ cũng hiểu khi nào không nên lạm dụng BIM. Đó là sự trưởng thành thật.
Cái giá của BIM nửa vời
BIM nửa vời đôi khi còn nguy hiểm hơn không dùng BIM. Khi không dùng BIM, mọi người biết mình đang làm việc bằng bản vẽ truyền thống và có thể cẩn thận theo cách truyền thống. Nhưng khi có BIM nửa vời, dự án dễ có cảm giác an tâm giả. Mọi người tin rằng model đã kiểm tra rồi, rằng clash đã chạy rồi, rằng dữ liệu đã đúng rồi, trong khi quy trình kiểm tra và cập nhật thực tế lại không đủ chặt.
Cái giá của BIM nửa vời không chỉ là tiền phần mềm hay nhân sự. Nó là chi phí niềm tin sai chỗ. Khi đội dự án tin vào một model chưa được quản lý đúng, họ có thể ra quyết định dựa trên dữ liệu chưa đáng tin. Khi chủ đầu tư tin rằng BIM đã kiểm soát rủi ro, họ có thể đánh giá thấp nhu cầu phối hợp thật. Khi công trường nhận thông tin không đồng bộ, họ có thể mất niềm tin vào BIM và quay lại cách làm cũ.
Vì vậy, nếu triển khai BIM, hãy triển khai đủ nghiêm túc ở phạm vi đã chọn. Không nhất thiết phải làm tất cả. Nhưng cái gì đã chọn làm thì phải có người chịu trách nhiệm, có tiêu chí kiểm tra, có cách sử dụng kết quả và có vòng phản hồi. Một use case nhỏ nhưng chặt chẽ tốt hơn một tham vọng lớn nhưng lỏng lẻo.
Tại sao người giỏi phần mềm vẫn có thể làm BIM thất bại?
Người giỏi phần mềm có thể dựng model nhanh, xử lý family tốt, tạo template đẹp, tự động hóa nhiều thao tác. Nhưng BIM thất bại không chỉ vì model chậm hoặc xấu. BIM thất bại khi model không gắn với quyết định. Một người model rất giỏi nhưng không được tham gia vào nhịp phối hợp dự án sẽ chỉ nhận yêu cầu sau cùng, sửa sau cùng, và chịu áp lực sau cùng.
Ngược lại, một BIM coordinator tốt không nhất thiết là người biết mọi lệnh phần mềm. Họ phải hiểu dự án đang cần quyết định gì, issue nào là critical, issue nào chỉ là thẩm mỹ, issue nào ảnh hưởng tiến độ, issue nào ảnh hưởng chi phí, và issue nào cần kéo chủ đầu tư vào. Họ là người dịch giữa model và quản lý dự án.
Nếu tổ chức chỉ tuyển người biết phần mềm mà không trao vai trò phối hợp, BIM team sẽ luôn bị kẹt ở vị trí sản xuất. Họ làm nhiều, sửa nhiều, nhưng ít ảnh hưởng đến cách dự án ra quyết định. Đến cuối cùng, mọi người nói BIM không hiệu quả, trong khi thực ra tổ chức chưa bao giờ cho BIM cơ hội đi vào quản lý.
Một dự án BIM tốt cần ít nhất bốn loại kỷ luật
Thứ nhất là kỷ luật phiên bản. Không có phiên bản rõ, mọi cuộc thảo luận đều có nguy cơ dựa trên thông tin khác nhau. Thứ hai là kỷ luật quyết định. Một issue không thể mở mãi; nó cần người quyết và thời hạn quyết. Thứ ba là kỷ luật cập nhật. Khi quyết định đã có, model, bản vẽ, khối lượng và thông tin công trường phải đi cùng nhau. Thứ tư là kỷ luật phản hồi. Những gì xảy ra ngoài công trường phải quay lại hệ thống thông tin.
Bốn loại kỷ luật này nghe không mới. Nhưng BIM làm chúng trở nên không thể né tránh. Trong bản vẽ truyền thống, nhiều sự mơ hồ có thể bị che bởi kinh nghiệm cá nhân. Trong BIM, mơ hồ trở thành dữ liệu thiếu, issue treo, object sai, version lệch, hoặc model không còn khớp thực tế. Chính vì vậy BIM vừa là công cụ, vừa là bài kiểm tra kỷ luật tổ chức.
Nếu một dự án chưa sẵn sàng cho bốn kỷ luật này, nên bắt đầu nhỏ. Chọn một phạm vi, một nhóm hạng mục, một mốc phối hợp, một mục tiêu đo được. Khi đội dự án quen với kỷ luật thông tin, BIM có thể mở rộng. Nếu mở rộng quá nhanh, tổ chức dễ nhầm sự phức tạp với sự tiến bộ.
BIM và câu chuyện trách nhiệm nghề nghiệp
Ở một tầng sâu hơn, BIM đặt lại câu hỏi về trách nhiệm nghề nghiệp. Khi thông tin trở nên liên kết hơn, mỗi quyết định thiết kế không còn là một nét vẽ độc lập. Nó ảnh hưởng đến chi phí, tiến độ, vận hành, an toàn, bảo trì và trải nghiệm người dùng. Điều đó buộc kiến trúc sư, kỹ sư, quản lý dự án và nhà thầu phải nhìn công trình như một hệ quả của nhiều quyết định liên tục.
Trong cách làm rời rạc, mỗi bên dễ nói “phần tôi đã xong”. Nhưng trong một môi trường BIM đúng nghĩa, câu hỏi không phải phần tôi xong chưa, mà là thông tin của tôi đã giúp phần sau làm việc tốt hơn chưa. Thiết kế xong nhưng không thi công được thì chưa xong. Model xong nhưng không ai dùng để quyết định thì chưa xong. Báo cáo clash xong nhưng issue không đóng thì chưa xong.
Đây là thay đổi rất lớn về tư duy. Nó chuyển trọng tâm từ deliverable sang dòng chảy thông tin. Và có lẽ đó là điểm mà BIM có giá trị nhất: không phải vì nó tạo ra mô hình 3D, mà vì nó ép chúng ta đối diện với câu hỏi công việc của mình có đang kết nối với công việc của người khác hay không.
Một ghi chú cuối về AI, BIM và quản lý
Khi AI bắt đầu đi vào thiết kế, BIM lại càng quan trọng, nhưng không phải theo nghĩa “model sẽ tự thông minh hơn”. AI có thể giúp tạo phương án, phân tích dữ liệu, gợi ý clash, tóm tắt issue, hoặc hỗ trợ tìm thông tin trong model. Nhưng nếu nền quản lý vẫn rời rạc, AI chỉ làm rác thông tin chạy nhanh hơn. Một hệ thống chưa có kỷ luật dữ liệu sẽ không trở nên thông minh chỉ vì có thêm AI.
Vì vậy, trước khi nói đến AI-enabled BIM hay digital twin, có lẽ ngành xây dựng cần quay lại vài nguyên tắc rất cơ bản: ai chịu trách nhiệm thông tin, quyết định được ghi nhận ở đâu, thay đổi đi qua quy trình nào, và dữ liệu nào thật sự được dùng để quản lý dự án. Công nghệ mới làm những câu hỏi này cấp bách hơn, chứ không làm chúng biến mất.
Điều BIM bắt chúng ta phải thành thật
Có lẽ câu hỏi đúng không phải là “dự án này có dùng BIM không?”. Câu hỏi đúng hơn là: dự án này có đủ kỷ luật quản lý để BIM trở nên có nghĩa không?
Phần mềm có thể dựng mô hình. Nhưng chỉ con người mới quyết định mô hình đó đại diện cho một cách làm việc nghiêm túc hay chỉ là một lớp hình ảnh phủ lên thói quen cũ. Nếu một dự án vẫn quản lý bằng email rời rạc, quyết định miệng, bản vẽ không đồng bộ và trách nhiệm mơ hồ, BIM sẽ không cứu được nó. BIM chỉ đứng đó, rất chính xác, và chỉ cho chúng ta thấy dự án đang rời rạc đến mức nào.