CDE trong ISO 19650: Quy trình WIP, Shared, Published và Archive

 , , , , , , , ,

Tóm tắt: Bài viết giải thích CDE trong ISO 19650, cách thông tin chuyển trạng thái từ WIP sang Shared, Published và Archive, cùng vai trò của QA/QC, Status và Revision trong kiểm soát dữ liệu BIM cho dự án xây dựng.

Đối tượng phù hợp: BIM Modeler, BIM Coordinator, BIM Manager, tư vấn thiết kế, nhà thầu, quản lý dự án và các nhóm triển khai BIM theo ISO 19650.



Mục lục nhanh

  • CDE là gì trong bối cảnh ISO 19650?
  • Bốn trạng thái thông tin chính trong CDE
  • Quy trình WIP, Shared, Published và Archive
  • Vai trò của Status và Revision trong BIM
  • Lỗi thường gặp khi vận hành CDE
  • Vai trò của BIM Manager trong kiểm soát CDE

Trong các dự án BIM, nhiều người vẫn hiểu CDE đơn giản là một nơi lưu trữ file: một thư mục trên server, một nền tảng cloud, hoặc một hệ thống như Autodesk Construction Cloud, BIM 360, ProjectWise, SharePoint hay một giải pháp quản lý tài liệu nào đó.

Cách hiểu này chưa sai, nhưng chưa đủ.

Theo tinh thần của ISO 19650, CDE – Common Data Environment, hay Môi trường dữ liệu chung – không chỉ là một công cụ công nghệ. Bản chất của CDE là một quy trình làm việc có kiểm soát để thu thập, quản lý, chia sẻ, phê duyệt, phát hành và lưu trữ các vùng chứa thông tin trong suốt vòng đời dự án.

Nói ngắn gọn: CDE không phải chỉ là “chỗ để file”. CDE là cơ chế kiểm soát thông tin.

Điểm quan trọng nhất trong CDE là thông tin không được sử dụng tùy tiện. Mỗi bản vẽ, mô hình, bảng dữ liệu, tài liệu kỹ thuật hoặc vùng chứa thông tin đều phải có trạng thái rõ ràng: đang làm dở, được chia sẻ để phối hợp, được phát hành chính thức, hay được lưu trữ để truy vết.

Đó là lý do các trạng thái WIP, Shared, Published và Archive trở thành xương sống của quy trình quản lý thông tin theo ISO 19650.

CDE là gì trong bối cảnh ISO 19650?

CDE là môi trường dùng để quản lý các information containers – vùng chứa thông tin – của dự án. Information container có thể là:

  • Mô hình Revit
  • File IFC
  • Bản vẽ PDF
  • File DWG
  • Bảng COBie
  • Báo cáo clash
  • Tài liệu BEP
  • Bảng MIDP/TIDP
  • Thông tin nghiệm thu hoặc bàn giao

Trong dự án BIM, các nhóm thiết kế và thi công thường làm việc song song. Kiến trúc, kết cấu, MEP, QS, nhà thầu, tư vấn giám sát và chủ đầu tư đều cần truy cập thông tin. Nếu không có quy trình kiểm soát, các bên rất dễ lấy nhầm file, dùng sai bản vẽ, phối hợp trên mô hình chưa hoàn thiện, hoặc thi công theo thông tin chưa được phê duyệt.

CDE giải quyết vấn đề này bằng cách kiểm soát trạng thái, quyền truy cập, phiên bản, mã trạng thái, lịch sử thay đổi và trách nhiệm phê duyệt của từng vùng chứa thông tin.

Trong ISO 19650, việc chuyển đổi trạng thái của thông tin là cơ chế cốt lõi để xác định:

  • Thông tin này đang ở giai đoạn nào?
  • Ai được phép sử dụng?
  • Được sử dụng cho mục đích gì?
  • Ai đã kiểm tra?
  • Ai đã phê duyệt?
  • Bản này có giá trị hợp đồng hay chưa?
  • Có thể dùng để thi công, mua sắm hoặc bàn giao hay không?

Nếu không trả lời được các câu hỏi này, dự án chưa thật sự kiểm soát được dữ liệu BIM.

Bốn trạng thái thông tin chính trong CDE

Trong quy trình CDE, thông tin thường được quản lý qua bốn trạng thái chính:

  1. Work in Progress – WIP
  2. Shared
  3. Published
  4. Archive

Mỗi trạng thái có mục đích, quyền sử dụng và mức độ tin cậy khác nhau.

Work in Progress – WIP: Thông tin đang phát triển nội bộ

WIP là trạng thái thông tin đang được nhóm tác vụ phát triển. Đây là vùng làm việc nội bộ của từng discipline hoặc task team.

Ví dụ:

  • Đội kiến trúc đang dựng mô hình layout.
  • Đội kết cấu đang cập nhật dầm, cột, sàn.
  • Đội MEP đang thiết kế tuyến ống gió, ống nước, máng cáp.
  • BIM Modeler đang chỉnh family hoặc update markup.

Thông tin trong WIP chưa được xem là hoàn thiện. Nó có thể còn sai, thiếu, chưa được kiểm tra, hoặc chưa phù hợp để nhóm khác sử dụng.

Vì vậy, dữ liệu WIP cần được cô lập. Các nhóm bên ngoài không nên có quyền truy cập trực tiếp vào vùng WIP của nhóm khác. Mục tiêu là tránh việc một bên vô tình link, copy hoặc sử dụng dữ liệu đang làm dở để ra quyết định.

Trong thực tế, lỗi này xảy ra khá nhiều. Một file Revit đang chỉnh trong WIP bị nhóm khác lấy để phối hợp. Sau đó mô hình thay đổi, thông tin không còn đúng, clash report bị sai, bản vẽ bị lệch, và cả nhóm mất thời gian xử lý lỗi không đáng có.

WIP phải được hiểu là vùng làm việc nội bộ, không phải vùng thông tin chính thức của dự án.

Từ WIP sang Shared: Chia sẻ để phối hợp, không phải để thi công

Shared là trạng thái thông tin đã qua kiểm tra nội bộ và được chia sẻ cho các bên khác sử dụng theo mục đích giới hạn.

Thông thường, thông tin từ WIP chỉ được chuyển sang Shared sau khi nhóm tác vụ thực hiện QA/QC cơ bản. Việc kiểm tra này không chỉ là mở file lên xem có chạy được hay không. Nó cần bao gồm các yếu tố như:

  • Tên file đúng quy ước đặt tên
  • Định dạng file đúng yêu cầu
  • Mã trạng thái được gán đúng
  • Revision được ghi nhận đúng
  • Nội dung mô hình hoặc bản vẽ phù hợp với mục đích chia sẻ
  • Mức độ phát triển thông tin phù hợp với TIDP
  • Không có lỗi nghiêm trọng ảnh hưởng đến phối hợp liên bộ môn

Ở bước này, tác giả hoặc người phụ trách nhóm tác vụ thường kiểm tra chất lượng ban đầu. Sau đó, Task Team Manager hoặc người quản lý nhóm đánh giá nội dung so với yêu cầu thông tin trao đổi, TIDP và phạm vi giao nộp.

Khi đạt yêu cầu, thông tin được chuyển sang Shared.

Điểm cần nhấn mạnh: Shared không có nghĩa là thông tin đã được phê duyệt để thi công.

Trong nhiều dự án, trạng thái Shared có thể được gán các mã như S1, S3, S4 tùy theo quy ước trong BEP hoặc Information Standard của dự án. Ví dụ:

  • S1: Phù hợp để phối hợp
  • S3: Phù hợp để xem xét và bình luận
  • S4: Phù hợp để đệ trình phê duyệt

Các mã này phải được hiểu theo quy định cụ thể của từng dự án. Không nên mặc định rằng mọi file trong Shared đều có giá trị sử dụng như nhau.

Một bản vẽ ở trạng thái S3 có thể chỉ phù hợp để review và comment. Nếu nhà thầu lấy bản vẽ đó để đặt hàng vật tư hoặc thi công ngoài công trường, rủi ro tranh chấp sẽ rất lớn.

Từ Shared sang Published: Thông tin được ủy quyền và chấp nhận

Published là trạng thái thông tin đã được kiểm tra, ủy quyền và chấp nhận cho mục đích sử dụng chính thức.

Đây là khác biệt quan trọng giữa Shared và Published.

Ở trạng thái Shared, thông tin có thể dùng để phối hợp, review hoặc đệ trình. Nhưng ở trạng thái Published, thông tin đã đạt mức độ tin cậy cao hơn và thường được sử dụng cho các mục đích chính thức như:

  • Phát hành bản vẽ thiết kế
  • Phát hành hồ sơ thi công
  • Phát hành thông tin hợp đồng
  • Bàn giao giai đoạn
  • Nghiệm thu thông tin
  • Lưu làm hồ sơ chính thức của dự án

Quy trình chuyển từ Shared sang Published thường có hai lớp kiểm soát chính.

Lead Appointed Party kiểm tra và ủy quyền

Lead Appointed Party là bên được chỉ định chính. Trong thực tế, đây có thể là tư vấn chính, tổng thầu, hoặc đơn vị chịu trách nhiệm điều phối thông tin theo hợp đồng.

Vai trò của Lead Appointed Party là kiểm tra mô hình thông tin hoặc bộ hồ sơ thông tin trước khi đệ trình lên Client. Việc kiểm tra này thường dựa trên:

  • EIR – Exchange Information Requirements
  • MIDP – Master Information Delivery Plan
  • BEP – BIM Execution Plan
  • Quy định về naming, status, revision
  • Mức độ nhu cầu thông tin – Level of Information Need
  • Phạm vi giao nộp theo từng giai đoạn
  • Yêu cầu phối hợp liên bộ môn
  • QA/QC checklist của dự án

Nếu thông tin đạt yêu cầu, Lead Appointed Party ủy quyền để đệ trình.

Client hoặc Appointing Party kiểm tra và chấp nhận

Sau khi được Lead Appointed Party ủy quyền, thông tin được gửi đến Appointing Party, thường là Client hoặc đại diện của chủ đầu tư.

Client kiểm tra theo tiêu chí nghiệm thu đã được xác định trong hợp đồng, EIR hoặc Information Protocol. Nếu đạt, thông tin được chấp nhận và có thể chuyển sang trạng thái Published.

Ở bước này, thông tin thường được gán mã trạng thái phù hợp với published/accepted status và mã revision hợp đồng như C01, C02. Cách đặt mã cụ thể phụ thuộc vào quy định của dự án, nhưng nguyên tắc là phải phân biệt rõ giữa revision sơ bộ và revision chính thức.

Ví dụ:

  • P01, P02: revision sơ bộ trong quá trình phối hợp hoặc đệ trình
  • C01, C02: revision hợp đồng hoặc phát hành chính thức

Nếu dự án không kiểm soát được sự khác biệt này, các bên rất dễ nhầm giữa bản nháp, bản phối hợp và bản đã được phê duyệt.

Archive: Lưu trữ để truy vết và bảo vệ dự án

Archive không chỉ là thư mục “cất file cũ”.

Trong CDE, Archive là cơ chế ghi lại lịch sử giao dịch thông tin. Nó giúp dự án biết được:

  • Ai đã phát hành thông tin?
  • Phát hành vào thời điểm nào?
  • Bản nào đã được thay thế?
  • Nội dung nào đã được phê duyệt?
  • File nào từng được sử dụng cho một mốc phát hành?
  • Ai đã thay đổi trạng thái?
  • Quyết định nào được đưa ra dựa trên bản thông tin nào?

Archive tạo ra audit trail – dấu vết kiểm toán – cho toàn bộ vòng đời dự án.

Trong các dự án có tranh chấp, thay đổi thiết kế, variation order hoặc claim, audit trail rất quan trọng. Nếu dự án không lưu được lịch sử trạng thái, revision và người phê duyệt, việc xác định trách nhiệm sẽ rất khó.

Archive cần diễn ra liên tục, không chỉ ở cuối dự án. Mỗi lần có phát hành quan trọng, mỗi lần chuyển trạng thái, mỗi lần thông tin được accepted hoặc superseded, hệ thống CDE nên ghi nhận lại.

Vì sao Status và Revision là cơ chế kiểm soát bắt buộc?

Trong quản lý thông tin BIM, Status và Revision không phải là thông tin phụ. Đây là hai trường metadata quan trọng để xác định giá trị sử dụng của dữ liệu.

Revision cho biết phiên bản của thông tin.

Status cho biết thông tin được phép sử dụng cho mục đích gì.

Một file có thể là bản mới nhất nhưng chưa chắc được phép thi công. Ngược lại, một bản đã Published có thể không phải bản đang chỉnh mới nhất trong WIP, nhưng lại là bản có giá trị hợp đồng tại thời điểm phát hành.

Đây là điểm nhiều đội dự án hay nhầm.

Ví dụ, nhóm MEP có thể đang chỉnh bản P02.01 trong WIP. Tuy nhiên, bản chính thức đang có hiệu lực ngoài công trường vẫn là C01 trong Published. Nếu một bên lấy bản P02.01 để thi công, họ đang dùng thông tin chưa được phê duyệt.

Vì vậy, CDE phải quản lý metadata tối thiểu như:

  • ID duy nhất của information container
  • Tên file theo quy ước
  • Status
  • Revision
  • Classification
  • Discipline
  • Originator
  • Suitability
  • Ngày phát hành
  • Người phát hành
  • Người phê duyệt

Metadata không phải để làm đẹp hệ thống. Metadata là cách dự án điều khiển quyền sử dụng thông tin.

Các lỗi thường gặp khi vận hành CDE

Dù quy trình CDE nghe có vẻ rõ ràng, nhưng khi triển khai thực tế, lỗi vẫn xảy ra thường xuyên. Phần lớn lỗi không nằm ở phần mềm, mà nằm ở cách con người sử dụng thông tin.

Lỗi 1: Dùng thông tin sai mục đích

Đây là lỗi nguy hiểm nhất.

Ví dụ, nhà thầu hoặc đội thi công lấy bản vẽ ở trạng thái Shared, mã S3 – phù hợp để xem xét và bình luận – rồi dùng để mua sắm vật tư hoặc thi công.

Hậu quả có thể rất nặng:

  • Thi công sai bản thiết kế đã chốt
  • Đặt hàng sai vật tư
  • Phát sinh chi phí tháo dỡ, làm lại
  • Gây tranh chấp giữa các bên
  • Khó xác định trách nhiệm nếu quy trình thông tin không rõ

Shared không đồng nghĩa với Approved. Review không đồng nghĩa với Construction. Đây là nguyên tắc phải được nhắc lại trong mọi BEP và Information Protocol.

Lỗi 2: Đẩy file từ WIP sang Shared mà không QA/QC

Một lỗi phổ biến khác là file được đưa thẳng từ WIP lên Shared mà không qua kiểm tra nội bộ.

Vấn đề này có thể gây hậu quả dây chuyền:

  • File sai naming khiến hệ thống không nhận diện đúng
  • Model bị lỗi link
  • Workset hoặc coordinate sai
  • View, sheet, family chưa kiểm soát
  • Mô hình phối hợp bị phá vỡ
  • Các bộ môn khác link dữ liệu sai
  • Clash detection cho kết quả nhiễu
  • Lead Appointed Party mất thời gian review lỗi cơ bản

Trong dự án BIM, QA/QC nội bộ là lớp lọc bắt buộc trước khi chia sẻ thông tin. Không thể đẩy lỗi của task team sang nhóm điều phối chung rồi gọi đó là “collaboration”.

Lỗi 3: Không quản lý revision trong WIP

Nhiều nhóm chỉ quản lý revision khi phát hành chính thức, nhưng lại bỏ qua revision trong giai đoạn làm việc nội bộ.

Điều này tạo ra rủi ro khi thiết kế thay đổi liên tục. Nếu tác giả không ghi nhận các bản nháp như P01.01, P01.02, P02.01, nhóm sẽ khó:

  • Khôi phục phương án cũ
  • So sánh thay đổi thiết kế
  • Truy vết nguyên nhân lỗi
  • Biết ai đã chỉnh gì
  • Xác định bản nào đã được review nội bộ

Trong môi trường BIM, đặc biệt khi nhiều người cùng làm trên model, quản lý revision nội bộ giúp giảm rủi ro mất dữ liệu và giảm tranh cãi khi có thay đổi.

Vai trò của BIM Manager trong kiểm soát CDE

Để CDE vận hành đúng, BIM Manager không thể chỉ tạo folder rồi để mọi người tự dùng. BIM Manager cần thiết lập quy trình, kiểm soát quyền, định nghĩa rule và duy trì kỷ luật thông tin.

Thiết lập cấu trúc và quyền truy cập

BIM Manager cần cấu hình CDE để phân tách rõ các vùng:

  • WIP theo từng discipline hoặc task team
  • Shared cho phối hợp
  • Published cho phát hành chính thức
  • Archive cho lưu trữ và truy vết

Quyền truy cập phải phản ánh đúng trạng thái thông tin. Ví dụ, nhóm MEP không nên có quyền chỉnh sửa trực tiếp WIP của nhóm kết cấu. Đội thi công không nên lấy thông tin từ Shared nếu trạng thái chưa cho phép construction use.

Trên các nền tảng như Autodesk Construction Cloud, quy trình này có thể được cấu hình thông qua folder permission, approval workflow, review step và metadata requirement.

Kiểm soát bằng BEP, MIDP và TIDP

CDE không thể vận hành tốt nếu BEP, MIDP và TIDP không rõ.

Trong BEP, BIM Manager cần quy định:

  • Cấu trúc CDE
  • Quy trình chuyển trạng thái
  • Quy tắc đặt tên file
  • Quy tắc status và revision
  • Quy trình QA/QC
  • Federation strategy
  • Clash detection workflow
  • Responsibility matrix
  • Quy trình phát hành và phê duyệt

Trong TIDP và MIDP, cần xác định rõ:

  • Information container nào sẽ được giao nộp
  • Ai là tác giả
  • Khi nào giao nộp
  • Giao nộp ở trạng thái nào
  • Mức độ nhu cầu thông tin cần đạt
  • Ai kiểm tra
  • Ai phê duyệt
  • File nào liên quan đến mốc phát hành nào

Nếu MIDP và TIDP chỉ là bảng làm cho có, CDE sẽ nhanh chóng biến thành kho file lộn xộn có giao diện đẹp.

Gắn Information Protocol vào hợp đồng

Một điểm rất quan trọng là Information Protocol cần được đưa vào hợp đồng của các bên.

Lý do rất đơn giản: nếu quy trình thông tin không có tính ràng buộc, các bên sẽ dùng dữ liệu theo thói quen riêng. Khi xảy ra lỗi, rất khó xác định ai chịu trách nhiệm.

Information Protocol cần làm rõ:

  • Trạng thái nào được phép dùng cho mục đích nào
  • Ai có quyền phát hành
  • Ai có quyền chấp nhận
  • Dữ liệu nào có giá trị hợp đồng
  • Trách nhiệm của bên sử dụng thông tin
  • Hậu quả khi dùng sai trạng thái thông tin

Ví dụ, nếu một nhà thầu tải file ở trạng thái S3 để thi công, trong khi Information Protocol đã quy định S3 chỉ dùng để review, trách nhiệm không thể đẩy ngược về nhóm phát hành thông tin.

Đây là lý do quy trình CDE phải gắn với quản trị hợp đồng, không chỉ quản trị kỹ thuật.

Ví dụ thực tế: Quy trình CDE trên dự án dùng Autodesk Construction Cloud

Giả sử một dự án có ba bộ môn: Kiến trúc, Kết cấu và MEP. Dự án sử dụng Autodesk Construction Cloud làm CDE.

Đội MEP đang thiết kế hệ thống ống gió.

Bước 1: Làm việc trong WIP

File Revit của MEP được lưu trong thư mục WIP_MEP. Nhóm MEP phát triển mô hình nội bộ, kiểm tra routing, chỉnh family và xử lý các yêu cầu thiết kế.

Ở giai đoạn này, file có thể được ghi nhận revision nội bộ là P01.01 và status S0. Các nhóm Arch và Struct không dùng file này để phối hợp chính thức.

Bước 2: Chuyển sang Shared để phối hợp

Sau khi trưởng nhóm MEP kiểm tra QA, file được chuyển sang vùng Shared. Revision được cập nhật thành P01, status là S1 – phù hợp để phối hợp.

Lúc này, đội Arch và Struct có thể link file MEP vào mô hình của họ để kiểm tra không gian, chạy clash detection và đánh giá xung đột thiết kế.

Bước 3: Phát hiện clash và quay lại WIP để sửa

Trong quá trình phối hợp, phát hiện tuyến ống gió đâm xuyên dầm chính. Đội MEP không chỉnh trực tiếp trên bản Shared. Họ quay lại WIP, tạo bản làm việc mới P02.01 để xử lý clash.

Sau khi chỉnh xong và QA lại, file được đẩy lại lên Shared với revision P02. Tùy mục đích, status có thể được đặt là S1 để tiếp tục phối hợp hoặc S4 nếu dùng để đệ trình phê duyệt giai đoạn.

Bước 4: Chuyển sang Published sau khi được kiểm tra và chấp nhận

BIM Manager hoặc Lead Appointed Party kiểm tra mô hình, xác nhận thông tin đáp ứng EIR, MIDP và yêu cầu phối hợp. Sau đó hồ sơ được gửi Client để review và accept.

Khi được chấp nhận, file được chuyển sang Published, khóa chỉnh sửa, cập nhật revision thành C01 và gán trạng thái phát hành phù hợp, ví dụ A3 nếu quy ước dự án định nghĩa A3 là trạng thái phê duyệt xuất bản.

Từ thời điểm này, bản Published mới là nguồn thông tin chính thức cho mục đích đã được phê duyệt.

Khuyến nghị thực tế khi triển khai CDE

Một CDE hiệu quả không nên phụ thuộc hoàn toàn vào thao tác thủ công. Nếu mọi việc dựa vào việc người dùng tự kéo file, tự đổi tên, tự cập nhật revision và tự nhớ status, hệ thống sẽ sớm lỗi.

Các dự án nên thiết lập approval workflow tự động trên nền tảng CDE. Khi thông tin được phê duyệt, hệ thống có thể:

  • Khóa quyền chỉnh sửa
  • Ghi nhận người phê duyệt
  • Ghi nhận ngày phát hành
  • Cập nhật trạng thái
  • Ghi nhận revision
  • Chuyển file sang khu vực phù hợp
  • Lưu lịch sử trong Archive
  • Tạo audit trail cho dự án

Tự động hóa không thay thế trách nhiệm của BIM Manager, nhưng giúp giảm lỗi thao tác và tăng tính nhất quán của quy trình.

Kết luận

CDE trong ISO 19650 không nên được hiểu đơn giản là một nền tảng lưu trữ file. CDE là một quy trình kiểm soát thông tin có cấu trúc, giúp dự án xác định rõ dữ liệu nào đang làm dở, dữ liệu nào được chia sẻ để phối hợp, dữ liệu nào được phát hành chính thức và dữ liệu nào cần lưu trữ để truy vết.

Có năm điểm quan trọng cần ghi nhớ.

Thứ nhất, CDE là workflow được hỗ trợ bởi công nghệ, không phải chỉ là phần mềm.

Thứ hai, sự dịch chuyển trạng thái từ WIP sang Shared, từ Shared sang Published và vào Archive giúp cô lập rủi ro và kiểm soát mức độ tin cậy của thông tin.

Thứ ba, Status và Revision là metadata bắt buộc để xác định quyền sử dụng dữ liệu.

Thứ tư, QA/QC nội bộ là điều kiện tiên quyết trước khi thông tin được chia sẻ cho các bên khác.

Thứ năm, cần phân định rõ trách nhiệm giữa Author, Task Team Manager, Lead Appointed Party và Appointing Party. Đặc biệt, phải tách bạch giữa hành động ủy quyền đệ trình và hành động chấp nhận thông tin.

Một CDE tốt không làm dự án chậm đi. Ngược lại, nó giúp dự án tránh việc dùng sai thông tin, giảm tranh chấp, cải thiện phối hợp đa bộ môn và tạo nền tảng quản lý dữ liệu đáng tin cậy trong toàn bộ vòng đời công trình.

FAQ

CDE có phải là phần mềm không?

Không hoàn toàn. CDE có thể được triển khai bằng phần mềm, nhưng bản chất CDE là quy trình quản lý thông tin. Phần mềm chỉ là công cụ hỗ trợ quy trình đó.

File trong Shared có được dùng để thi công không?

Không mặc định. File trong Shared chỉ được dùng theo đúng mục đích của status được gán. Nếu status chỉ phù hợp để review hoặc phối hợp, không được dùng để thi công.

Vì sao cần phân biệt Revision P và C?

Revision P thường dùng cho giai đoạn sơ bộ, phối hợp hoặc đệ trình. Revision C thường dùng cho phát hành chính thức hoặc hợp đồng. Cách đặt mã cụ thể phụ thuộc quy định dự án, nhưng phải phân biệt rõ bản nháp và bản chính thức.

Ai chịu trách nhiệm kiểm tra thông tin trước khi chuyển sang Shared?

Thông thường, tác giả và quản lý nhóm tác vụ chịu trách nhiệm QA/QC nội bộ trước khi chia sẻ thông tin ra môi trường chung.

BIM Manager cần kiểm soát gì trong CDE?

BIM Manager cần kiểm soát cấu trúc CDE, quyền truy cập, naming convention, status, revision, metadata, QA/QC workflow, BEP, MIDP, TIDP và quy trình phát hành thông tin.

Tại BIMLearning.edu.vn, chúng tôi tin rằng việc phổ cập kiến thức BIM và các xu hướng công nghệ liên quan không chỉ giúp các chuyên gia và doanh nghiệp xây dựng cập nhật thông tin mới nhất mà còn tạo nền tảng cho sự phát triển toàn diện của ngành.

Bạn có ý kiến hay câu hỏi? Hãy để lại bình luận bên dưới và cùng trao đổi thêm về tương lai của ngành xây dựng Việt Nam! Bài viết được thực hiện bởi đội ngũ BIMLearning.edu.vn – Nơi cung cấp kiến thức và giải pháp BIM chuyên sâu cho ngành xây dựng.