Phát hiện và xử lý lỗi từ sớm: Giá trị thiết thực của BIM

Trong một dự án xây dựng, một lỗi nhỏ có thể đi rất xa. Một yêu cầu chưa rõ ở đầu dự án có thể dẫn đến một chi tiết thiết kế không đúng. Chi tiết ấy đi vào mô hình. Từ mô hình, nó đi vào bảng khối lượng. Từ bảng khối lượng, nó đi vào dự toán, hợp đồng và kế hoạch thi công. Nếu không được phát hiện, cuối cùng cái sai trên máy tính có thể trở thành cái sai ngoài công trường. Điều đáng lo không hẳn là lỗi ban đầu lớn đến mức nào. Đáng lo hơn là nó có thể đi qua nhiều bước mà không ai nhận ra. Càng đi xa khỏi nơi phát sinh, càng có nhiều người, nhiều tài liệu và nhiều quyết định phụ thuộc vào nó. Đến khi phát hiện, chúng ta không còn sửa một con số hay một đối tượng nữa, mà có thể phải sửa cả một chuỗi công việc phía sau. Hãy cùng xem xét tình huống sau.

Giả sử một công trình văn phòng có 20 dầm bê tông cốt thép cùng loại. Theo thiết kế đúng, mỗi dầm có tiết diện 300 × 600 mm, dài 6 m. Khối lượng bê tông của một dầm xấp xỉ: 0,30 × 0,60 × 6 = 1,08 m³. Hai mươi dầm cần khoảng: 1,08 × 20 = 21,6 m³ bê tông. Nhưng trong quá trình dựng mô hình BIM, người thiết kế nhập nhầm chiều cao dầm từ 600 mm thành 800 mm. Nếu không có cơ chế kiểm tra ngay tại thời điểm tạo mô hình, lỗi này vẫn có thể đi tiếp. Khi đó, máy tính không biết rằng người thiết kế đã nhập nhầm. Nó chỉ tính toán rất chính xác trên dữ liệu được cung cấp: 0,30 × 0,80 × 6 × 20 = 28,8 m³. Như vậy chỉ từ một thông số sai 200 mm, khối lượng bê tông đã tăng từ 21,6 m³ lên 28,8 m³, chênh 7,2 m³. Đến bước lập dự toán, kỹ sư dự toán thấy 28,8 m³ có vẻ bất thường. Anh kiểm tra bản vẽ và nhận ra khối lượng đúng phải là 21,6 m³. Cách nhanh nhất là mở Excel và sửa: 28,8 → 21,6 m³. Bảng dự toán lúc này đúng. Nhưng mô hình BIM vẫn sai. Đây mới là thời điểm nguy hiểm. Dự án bắt đầu tồn tại hai nguồn thông tin khác nhau: mô hình nói 28,8 m³, dự toán nói 21,6 m³. Một tháng sau, thiết kế thay đổi một số dầm. Người khác xuất lại khối lượng từ mô hình BIM. Con số 28,8 m³ lại xuất hiện. Không ai biết người dự toán trước đây đã sửa con số nào, vì sao sửa và dựa trên phiên bản nào. Nếu dữ liệu tiếp tục được sử dụng cho đặt hàng, thanh toán hoặc thi công, một lỗi rất nhỏ ở đầu chuỗi đã đi qua nhiều người và nhiều hệ thống. Vấn đề càng nghiêm trọng nếu mỗi lần xuất mô hình, các đối tượng lại không giữ được định danh ổn định. Khi nhìn vào dòng 21,6 m³ trong bảng dự toán, người kiểm tra có thể không còn xác định chắc chắn nó được tạo ra từ 20 dầm nào trong mô hình.

Lúc ấy, câu hỏi tưởng rất đơn giản: “21,6 m³ này từ đâu ra?” lại trở nên khó trả lời. Nếu tổ chức theo cách khác, câu chuyện sẽ dừng rất sớm. Ngay khi dầm 300 × 800 mm được tạo ra, hệ thống đối chiếu với yêu cầu thiết kế và cảnh báo: Yêu cầu: 300 × 600 mm.Mô hình: 300 × 800 mm. Kết quả: Không đạt. Người thiết kế sửa lại dầm thành 300 × 600 mm. Hệ thống kiểm lại, xác nhận đạt yêu cầu rồi mới cho dữ liệu được sử dụng để tính khối lượng. Khi ấy chuỗi trở thành: Yêu cầu đúng → Mô hình → Kiểm tra → Phát hiện sai → Sửa tại mô hình → Kiểm lại → Đạt → Tính khối lượng → Dự toán. Thay vì: Yêu cầu → Mô hình sai → Khối lượng sai → Excel sửa tay → Mô hình vẫn sai → Lỗi có thể xuất hiện trở lại.

Ví dụ này cho thấy một điều rất quan trọng: máy tính không nhất thiết tính sai. Nó có thể tính hoàn toàn chính xác trên một dữ liệu đầu vào sai. Vì vậy, vấn đề không chỉ là “tính toán có chính xác không”, mà phải hỏi sớm hơn: Dữ liệu dùng để tính toán có đúng không? Và đây chính là điều phải lưu ý:  Sai 200 mm ở một dầm chỉ là một lỗi nhỏ. Nhưng nếu không được phát hiện tại nơi nó sinh ra, lỗi ấy có thể biến thành sai khối lượng, sai dự toán, sai đặt hàng và cuối cùng thành tiền thật ngoài công trường. Phát hiện lỗi sớm vì thế không chỉ là kiểm tra mô hình; đó là ngăn một sai sót nhỏ có cơ hội trở thành một sai lầm lớn.

Vì vậy, một vấn đề quan trọng của BIM và chuyển đổi số ngành xây dựng không chỉ là tạo ra nhiều dữ liệu hơn. Quan trọng hơn là làm thế nào phát hiện cái sai trước khi nó kịp đi xa. BIM thường được kỳ vọng sẽ giúp giải quyết vấn đề này. Chúng ta có mô hình 3D, có dữ liệu về cấu kiện, vật liệu, khối lượng và nhiều thông tin khác. Phần mềm ngày càng mạnh, mô hình ngày càng chi tiết. Nhưng có nhiều dữ liệu hơn không đồng nghĩa với ít sai hơn. Nếu yêu cầu ban đầu chưa rõ, người thiết kế có thể hiểu một cách, người kiểm tra hiểu một cách khác. Nếu yêu cầu chỉ tồn tại trong những trang văn bản dài, máy tính cũng không thể tự biết điều gì phải kiểm và thế nào mới được coi là đúng. Đây chính là nơi lỗi có thể bắt đầu. Sau đó là cách chúng ta kiểm tra. Trong nhiều trường hợp, mô hình được làm gần xong rồi mới chuyển sang kiểm tra hoặc thẩm định. Khi ấy, một sai sót xuất hiện từ rất sớm có thể đã tồn tại trong dự án nhiều tuần hoặc nhiều tháng. Phát hiện càng muộn, sửa càng khó. Một lỗi ban đầu chỉ liên quan đến một cấu kiện có thể đã ảnh hưởng đến bản vẽ, khối lượng, dự toán và nhiều công việc khác. Vì vậy, tư duy “làm xong rồi kiểm” cần dần được thay bằng “làm đến đâu kiểm đến đó”.

Trong môi trường số, chúng ta hoàn toàn có thể kiểm sớm hơn. Một nhóm cấu kiện vừa hoàn thành có thể được kiểm ngay. Một thay đổi thiết kế vừa thực hiện có thể được kiểm xem ảnh hưởng đến những gì. Một bảng khối lượng vừa được tạo ra có thể được đối chiếu ngay với nguồn dữ liệu của nó. Thay vì một chuỗi dài: Làm → Làm tiếp → Làm tiếp → Nộp → Kiểm → Phát hiện sai, chúng ta cần tiến tới một cách làm đơn giản hơn: Làm → Kiểm → Đúng thì đi tiếp → Sai thì quay lại sửa. Điều quan trọng ở đây không phải là một phần mềm mới. Đó là cách tổ chức công việc mới.

Trong một dự án, thông tin liên tục được chuyển giao. Thiết kế chuyển dữ liệu cho dự toán. Dự toán cung cấp thông tin cho hợp đồng và quản lý chi phí. Thiết kế chuyển hồ sơ cho thi công. Khi công trình hoàn thành, dữ liệu lại được bàn giao cho đơn vị quản lý, vận hành. Mỗi lần chuyển như vậy đều là một nơi mà lỗi có thể đi qua. Vì thế, mỗi lần chuyển giao cũng phải trở thành một điểm chặn lỗi..Trước khi thông tin đi tiếp, chỉ cần trả lời rõ ba câu hỏi: Chúng ta yêu cầu điều gì? Dữ liệu hiện tại đã đáp ứng chưa? Có gì chứng minh rằng nó đã được kiểm? Nếu chưa trả lời được, dữ liệu chưa nên đi tiếp. Một hệ thống như vậy còn phải giúp chúng ta trả lời một câu hỏi rất đời thường: Con số này từ đâu ra? Một dòng khối lượng bê tông phải có thể lần ngược về những cấu kiện tạo ra nó. Những cấu kiện ấy phải có thể lần ngược về phiên bản thiết kế tương ứng. Một kết quả kiểm tra phải cho biết đã kiểm cái gì, kiểm khi nào và căn cứ vào yêu cầu nào. Nói cách khác, thay vì yêu cầu người sau tin rằng con số này đúng, chúng ta phải cho họ khả năng tự kiểm lại tại sao con số này đúng. 

Sự khác biệt giữa hai cách tiếp cận ấy rất lớn. Cách thứ nhất phụ thuộc vào con người. Người lập hồ sơ nói rằng đã kiểm và người nhận hồ sơ tin rằng đã kiểm. Nhưng con người thay đổi, đơn vị tư vấn thay đổi, phần mềm thay đổi. Sau mười hay hai mươi năm, những người từng tạo ra hồ sơ có thể không còn tham gia công trình nữa. Cách thứ hai dựa vào bằng chứng. Người khác, ở một thời điểm khác, vẫn có thể lần lại nguồn gốc của thông tin, biết nó đã được kiểm như thế nào và tự kiểm lại khi cần. Đó mới là nền tảng để dữ liệu BIM trở thành tài sản lâu dài của công trình, thay vì chỉ là sản phẩm phục vụ một giai đoạn của dự án. Tuy nhiên, công nghệ chỉ giải quyết được một phần. Phần còn lại là trách nhiệm.

Nếu dữ liệu từ thiết kế chuyển sang dự toán và có sai sót, ai phải kiểm trước khi chuyển? Nếu người làm dự toán phát hiện bất thường, ai có trách nhiệm yêu cầu quay lại sửa nguồn? Ai được quyền xác nhận rằng dữ liệu đã đủ tin cậy để sử dụng cho bước tiếp theo? Nếu những câu hỏi ấy không có câu trả lời rõ ràng, phần mềm tốt đến đâu cũng khó giải quyết tận gốc. Vì vậy, cùng với việc đầu tư phần mềm và đào tạo BIM, cần xác định rõ ai chịu trách nhiệm tại mỗi lần chuyển giao thông tin. Người đó không nhất thiết phải tự kiểm từng con số. Nhưng phải bảo đảm rằng những việc cần kiểm đã được kiểm, những lỗi phát hiện được đã được xử lý và có bằng chứng cho thấy dữ liệu đủ điều kiện để đi tiếp.

Nhìn từ góc độ này, chúng ta cũng cần nhìn lại cách đánh giá một mô hình BIM. Một mô hình đẹp chưa chắc là một mô hình đáng tin. Một mô hình rất chi tiết chưa chắc là một mô hình đáng tin. Một mô hình không báo lỗi phần mềm cũng chưa chắc chứa thông tin đúng. Một mô hình đáng tin phải cho phép những thông tin quan trọng được kiểm tra, truy ngược và chứng minh. Đây có thể là bước chuyển quan trọng tiếp theo của BIM tại Việt Nam: từ tập trung vào tạo mô hình sang tập trung vào tạo ra thông tin có thể kiểm chứng. Khi ấy, BIM không chỉ giúp chúng ta nhìn thấy công trình trên màn hình. Nó còn phải giúp trả lời: thông tin này từ đâu đến, đã được kiểm chưa, nếu sai thì sai ở đâu, ảnh hưởng đến những gì và phải quay lại đâu để sửa.

AI có thể giúp khả năng này mạnh hơn. Máy có thể kiểm hàng nghìn đối tượng, phát hiện những điểm bất thường, so sánh các phiên bản và cảnh báo khi một thay đổi thiết kế có thể ảnh hưởng đến khối lượng hoặc chi phí. Nhưng AI cũng không thay đổi được một nguyên lý căn bản: muốn phát hiện cái sai, trước hết phải nói rõ thế nào là đúng. Vì vậy, con đường phía trước không nhất thiết phải bắt đầu bằng những công nghệ phức tạp. Nó có thể bắt đầu bằng những việc rất cơ bản: yêu cầu phải rõ hơn, kiểm tra phải sớm hơn, lỗi phải được sửa tại nguồn, thông tin phải truy ngược được và trách nhiệm tại mỗi lần chuyển giao phải được xác định.

Chúng ta cũng không nên đặt ra một mục tiêu không thực tế rằng dự án số hóa sẽ không bao giờ có lỗi. Một kỹ sư có thể nhập nhầm một thông số. Một người thiết kế có thể hiểu sai một yêu cầu. Một bảng tính có thể chứa một công thức sai. Một phần mềm cũng có thể tạo ra kết quả không như mong muốn. Lỗi vẫn sẽ xuất hiện. Điều quan trọng là lỗi được phép đi xa đến đâu trước khi bị phát hiện. Một lỗi được phát hiện ngay tại nơi nó sinh ra thường chỉ là một việc phải sửa. Nhưng cũng lỗi ấy, nếu đi qua thiết kế, khối lượng, dự toán, hợp đồng rồi ra công trường, có thể trở thành vấn đề của cả dự án.

Vì vậy, có lẽ một trong những thước đo đáng quan tâm của một hệ thống BIM trưởng thành không phải chỉ là mô hình chi tiết đến đâu, sử dụng phần mềm gì hay chứa bao nhiêu dữ liệu. Câu hỏi quan trọng hơn là: Nếu một thông tin sai xuất hiện hôm nay, mất bao lâu để hệ thống phát hiện ra nó, biết nó từ đâu đến, biết nó đã ảnh hưởng đến đâu và ngăn nó đi tiếp? Khi trả lời được câu hỏi đó, BIM bắt đầu vượt khỏi vai trò của một công cụ tạo mô hình. Nó trở thành một phương thức kiểm soát chất lượng thông tin xuyên suốt dự án. Và cuối cùng, tư tưởng của vấn đề có thể được diễn đạt rất giản dị: Một hệ thống tốt không phải là hệ thống không bao giờ có lỗi. Đó là hệ thống phát hiện lỗi đủ sớm để một lỗi nhỏ không có cơ hội âm thầm trở thành một sai lầm lớn.