Phối hợp và giải quyết xung đột mô hình
Chạy một vòng phối hợp phát hiện xung đột: hợp nhất các mô hình chuyên ngành, phát hiện xung đột, phân loại và giao trách nhiệm cho các xung đột thực sự, đặt các câu hỏi thiết kế phát sinh từ đó và xác nhận chúng đã được giải quyết trong lần phát hành mô hình tiếp theo.
Cách hoạt động, từng bước một
5 bước xuyên suốt nền tảng - bạn làm gì ở mỗi bước và vì sao điều đó quan trọng.
Hợp nhất các mô hình chuyên ngành
FederationsGộp các mô hình kiến trúc, kết cấu và hệ thống kỹ thuật mới nhất vào một bộ mô hình hợp nhất trên gốc tọa độ dự án chung, và xác nhận mỗi chuyên ngành là phiên bản hiện tại trước khi kiểm tra bất kỳ điều gì.
Tại sao: Kết quả xung đột chỉ tốt bằng các mô hình đứng sau chúng. Phối hợp trên một mô hình cũ hoặc lệch trục lãng phí cả một vòng để đuổi theo các xung đột đã được sửa hoặc thực ra không tồn tại.
Chạy phát hiện xung đột
Clash detectionChạy kiểm tra xung đột giữa các chuyên ngành quan trọng, kết cấu với hệ thống kỹ thuật, hệ thống kỹ thuật với trần, và để dung sai lọc bớt nhiễu chạm nhẹ để các xung đột thực sự nổi bật.
Tại sao: Một ống chạy qua dầm hoặc ống gió chạy qua tường tốn kém hơn nhiều để sửa tại hiện trường so với trong mô hình. Phát hiện là nơi bạn bắt lỗi trong khi nó vẫn chỉ là một đường trên màn hình chứ không phải một lệnh thay đổi.
Phân loại và giao trách nhiệm cho xung đột thực sự
BIMNhóm các kết quả thô thành các vấn đề thực sự, loại bỏ các trường hợp sai dương tính, và giao mỗi xung đột thực sự cho chuyên ngành chịu trách nhiệm sửa với một góc nhìn rõ ràng về vị trí trong mô hình.
Tại sao: Một con số hàng nghìn xung đột thô không giúp ích gì cho ai. Giá trị nằm ở một danh sách ngắn, có người chịu trách nhiệm, mỗi mục là một xung đột thực sự có tên đứng sau, để cuộc họp phối hợp là về các quyết định, không phải sắp xếp.
Đặt các câu hỏi thiết kế
RFIKhi một xung đột cần một quyết định thiết kế thay vì đơn giản là dịch chuyển, lập nó thành RFI gửi cho chủ nhiệm thiết kế để câu trả lời được ghi lại, có ngày tháng và truy vết được về góc nhìn mô hình.
Tại sao: Một số xung đột không thể được đóng chỉ bởi người điều phối, chúng cần một quyết định thiết kế thực sự. Lập chúng chính thức nghĩa là quyết định được ghi lại và thay đổi mô hình theo sau có thể truy vết về lý do đã tạo ra nó.
Xác nhận giải quyết trong lần phát hành tiếp theo
Báo cáoKhi phiên bản mô hình tiếp theo đến, chạy lại kiểm tra, xác minh các xung đột đã giao trách nhiệm thực sự đã biến mất, và báo cáo vòng phối hợp gồm những gì đã đóng, những gì còn mở và những gì kéo dài sang vòng sau.
Tại sao: Phối hợp chưa xong khi một sửa chữa được hứa hẹn, nó chỉ xong khi mô hình tiếp theo chứng minh điều đó. Chạy lại và báo cáo mỗi vòng là điều cho thấy xu hướng tiến về không và giữ mọi người trung thực về tiến độ.