1.2.12- Nguyên tắc quản lý tài liệu trong CDE
## 2.12. Nguyên tắc quản lý tài liệu trong CDE
(Principles of Document Management in CDE)
### 2.12.1. CDE không chỉ là nơi lưu file
CDE NPD không được hiểu đơn giản như một ổ đĩa mạng hoặc dịch vụ lưu trữ file trên Internet.
Mỗi tài liệu trong CDE được quản lý như một Information Container có:
- mã nhận diện;
- metadata;
- Folder;
- Zone;
- State;
- Version;
- Current Version;
- người tạo;
- thời điểm tạo;
- quyền truy cập;
- lịch sử Review;
- Approval;
- trạng thái phát hành;
- và lịch sử thay đổi.
Do đó, khi đưa một file vào CDE, người dùng không chỉ đang "Upload một file" mà đang tạo hoặc cập nhật một Information Container của Project.
--------------------------------------------------
### 2.12.2. Mỗi Information Container phải có Identity ổn định
Một Document phải có một Identity ổn định trong suốt vòng đời của nó.
Ví dụ:
PRJ_001-NPD-ZZ-ZZ-CM-D-03
được xem là một Document.
Các lần cập nhật sau:
Version 001
Version 002
Version 003
...
không phải là các Document mới.
Chúng là các DocumentVersion của cùng một Document.
Nguyên tắc:
Document
→ Identity ổn định.
DocumentVersion
→ nội dung thay đổi theo thời gian.
Không tạo nhiều Document khác nhau chỉ để biểu diễn các lần chỉnh sửa của cùng một tài liệu.
--------------------------------------------------
### 2.12.3. Version phải do CDE quản lý
Người dùng không tự quản lý Version bằng cách:
- Copy file;
- đổi tên;
- thêm V1, V2, V3;
- thêm Final;
- thêm Final2;
- hoặc tạo nhiều file gần giống nhau.
Ví dụ không nên:
Model_Final.rvt
Model_Final2.rvt
Model_New.rvt
Model_Final_New.rvt
CDE phải quản lý Version theo chuỗi chính thức.
Ví dụ:
Document:
PRJ_001-NPD-ZZ-ZZ-CM-D-03
CDE quản lý:
001
002
003
004
...
Nguyên tắc:
Người dùng tạo nội dung.
CDE quản lý lịch sử nội dung.
--------------------------------------------------
### 2.12.4. Luôn xác định Current Version
Một Document có thể có nhiều Version nhưng chỉ có một Version hiện hành trong một chuỗi Version tương ứng.
Current Version là Version mà các chức năng khác của CDE nên sử dụng khi cần dữ liệu hiện tại.
Người dùng cần tránh:
- sử dụng Version cũ khi không có chủ đích;
- Download nhầm Version cũ;
- Review nhầm Version;
- phối hợp trên Version không còn Current.
Trước khi thực hiện các nghiệp vụ quan trọng, cần kiểm tra:
Current = Yes
hoặc:
IsCurrent = Yes.
--------------------------------------------------
### 2.12.5. RVT và PDF có chuỗi Version riêng
Nếu một Information Container có cả RVT và PDF thì hai loại file phải được quản lý theo hai chuỗi Version độc lập.
Ví dụ:
RVT:
001
002
003
PDF:
001
002
Không sử dụng Version RVT để tiếp tục đánh số cho PDF và ngược lại.
Nguyên tắc:
Document + FileType
→ chuỗi Version riêng.
Điều này giúp mỗi định dạng phát triển độc lập mà không làm sai lịch sử của loại file còn lại.
--------------------------------------------------
### 2.12.6. Tên file phải tuân theo Naming Convention
Tên Information Container phải được tạo theo Naming Convention của Project.
Cấu trúc cơ bản gồm:
PROJECT-ORIGINATOR-VOLUME-LEVEL-TYPE-ROLE-NUMBER
Ví dụ:
PRJ_001-NPD-ZZ-ZZ-CM-A-01.rvt
Nếu sử dụng Option:
PRJ_001-NPD-ZZ-ZZ-CM-A-01_(NMD-S1).rvt
Các mã:
- Originator;
- Volume/System;
- Level/Location;
- Type;
- Role
phải tuân theo danh mục NameCode của Project.
Project Code được CDE lấy trực tiếp từ Project hiện hành.
Version không phải là trường người dùng tự nhập.
--------------------------------------------------
### 2.12.7. Metadata quan trọng không nên chỉ tồn tại trong tên file
Tên file giúp con người nhận diện Information Container.
Tuy nhiên CDE còn lưu các thành phần dưới dạng metadata riêng như:
- ProjectCode;
- Originator;
- Discipline;
- RoleCode;
- ContainerNumber;
- SuitabilityCode;
- Type;
- Zone;
- Status.
Điều này giúp CDE:
- tìm kiếm;
- lọc;
- kiểm tra;
- tự động hóa;
- liên kết dữ liệu;
- và hỗ trợ AI
mà không phải phụ thuộc hoàn toàn vào việc đọc chuỗi tên file.
Nguyên tắc:
File Name
→ để nhận diện.
Metadata
→ để hệ thống hiểu dữ liệu.
--------------------------------------------------
### 2.12.8. Tài liệu phải đi đúng Zone
CDE NPD sử dụng các vùng dữ liệu chính:
WIP
→ Work In Progress – Đang làm việc.
Shared
→ Chia sẻ / Phối hợp.
Published
→ Phát hành.
Archive
→ Lưu trữ.
Mỗi Zone có ý nghĩa nghiệp vụ riêng.
Không nên coi các Zone chỉ là các Folder khác nhau.
Việc một Information Container chuyển Zone thể hiện sự thay đổi trạng thái sử dụng của thông tin.
--------------------------------------------------
### 2.12.9. WIP là nơi tạo và chỉnh sửa
WIP là vùng làm việc của nhóm tác giả.
Các hoạt động chính tại WIP:
- tạo tài liệu;
- chỉnh sửa;
- tạo Version;
- kiểm tra nội bộ;
- chuẩn bị tài liệu trước khi chia sẻ.
WIP không phải nguồn phát hành chính thức.
Nguyên tắc:
Chưa hoàn thành
→ ở WIP.
Sẵn sàng phối hợp
→ đưa sang Shared.
--------------------------------------------------
### 2.12.10. Shared là nơi phối hợp, không phải nơi phát hành
Shared chứa các Information Container đã đủ điều kiện để chia sẻ với các bên khác.
Shared được dùng cho:
- phối hợp;
- Review;
- kiểm tra;
- trao đổi thông tin.
Shared không đồng nghĩa với Published.
Một Document đang ở Shared chưa nên được coi là bản chính thức để thi công hoặc sử dụng cho mục đích yêu cầu tài liệu phát hành.
--------------------------------------------------
### 2.12.11. Published là nguồn thông tin chính thức
Published chứa các Information Container đã đạt điều kiện phát hành theo Workflow của Project.
Khi người dùng cần:
- tài liệu chính thức;
- hồ sơ sử dụng;
- tài liệu phục vụ thi công;
- hoặc thông tin đã được chấp thuận,
nên ưu tiên lấy từ Published.
Published không phải vùng tiếp tục chỉnh sửa.
Nếu cần thay đổi:
Published
→ quay về quy trình tạo nội dung
→ tạo Version mới
→ Shared
→ Review / Approval
→ Published Version mới.
--------------------------------------------------
### 2.12.12. Archive dùng để bảo toàn lịch sử
Archive dùng để lưu các Information Container không còn là dữ liệu hiện hành nhưng vẫn cần được giữ lại.
Archive phục vụ:
- truy vết;
- đối chiếu;
- lưu hồ sơ;
- kiểm tra lịch sử Project.
Archive không phải Recycle Bin.
Tài liệu Archive vẫn là một phần hợp lệ của hồ sơ Project.
--------------------------------------------------
### 2.12.13. Review và Approval phải gắn với Version
Một kết quả Review chỉ có ý nghĩa đối với Version đã được Review.
Ví dụ:
Version 001
→ NEEDS_CHANGES.
Version 002
→ APPROVED.
Không được hiểu rằng vì Document đã từng được Approved thì mọi Version sau tự động được Approved.
Mỗi Version mới cần đi qua Workflow kiểm tra tương ứng khi Project yêu cầu.
Nguyên tắc:
Document
→ đối tượng quản lý.
Version
→ nội dung được kiểm tra.
Review
→ đánh giá Version.
Approval
→ chấp thuận Version.
--------------------------------------------------
### 2.12.14. Phân biệt Review, Approval và Publish
Ba khái niệm này không giống nhau.
Review
→ kiểm tra và đánh giá.
Approval
→ quyết định chấp thuận.
Publish
→ phát hành Information Container để sử dụng chính thức.
Một tài liệu có thể:
được Review
nhưng chưa Approved.
Hoặc:
đã Approved
nhưng chưa Publish
nếu Workflow của Project còn bước khác.
Do đó không nên đồng nhất:
Reviewed = Published.
--------------------------------------------------
### 2.12.15. Không chỉnh sửa trực tiếp Published hoặc Archive
Published và Archive chủ yếu phục vụ:
- sử dụng;
- tham chiếu;
- tra cứu;
- truy vết.
Không nên chỉnh sửa trực tiếp file trong các vùng này.
Nếu cần cập nhật tài liệu đã Published:
1. Tạo hoặc chỉnh sửa Version trong vùng làm việc phù hợp.
2. Hoàn thành kiểm tra nội bộ.
3. Đưa sang Shared.
4. Review / Approval.
5. Publish Version mới.
Cách này giữ nguyên lịch sử phát hành.
--------------------------------------------------
### 2.12.16. Delete không đồng nghĩa với xóa vĩnh viễn
Khi người dùng Delete Document hoặc Folder, dữ liệu nên đi qua Recycle Bin.
Có thể hiểu:
Delete
→ Recycle Bin.
Sau đó mới quyết định:
Restore
hoặc
Delete Permanently.
Điều này giảm nguy cơ mất dữ liệu do thao tác nhầm.
--------------------------------------------------
### 2.12.17. Phân biệt Document Recycle Bin và Version Recycle Bin
CDE NPD có hai cấp Recycle Bin.
Project Recycle Bin:
- Document;
- Folder.
Version Recycle Bin:
- DocumentVersion.
Ví dụ:
Xóa Document
→ cả Document được đưa vào Project Recycle Bin.
Loại Version 028
→ chỉ Version 028 vào Version Recycle Bin.
→ Document vẫn tồn tại.
Hai cơ chế không được nhầm lẫn.
--------------------------------------------------
### 2.12.18. Revit WIP Version Retention chỉ áp dụng cho RVT
Project có thể thiết lập:
Keep WIP Revit Versions.
Ví dụ:
5
CDE giữ 5 Version RVT WIP hoạt động gần nhất.
Khi có Version vượt quá giới hạn:
Version RVT cũ nhất
→ Version Recycle Bin.
Giới hạn:
Tối thiểu: 1
Mặc định: 5
Tối đa: 20
Cơ chế này nhằm giảm dung lượng lưu trữ của các file Revit lớn.
--------------------------------------------------
### 2.12.19. PDF không bị loại bởi Revit Version Retention
PDF không thuộc cơ chế:
Keep WIP Revit Versions.
Các Version PDF phải được giữ lại và không tự động bị chuyển vào Version Recycle Bin chỉ vì vượt số Version RVT được cấu hình.
Lý do là PDF có thể liên quan đến:
- Review;
- Approval;
- Technical Review;
- Annotation;
- hồ sơ phát hành;
- lịch sử chứng cứ.
Do đó không được áp dụng cơ chế dọn Version Revit cho PDF.
--------------------------------------------------
### 2.12.20. Permission phải được kiểm soát theo phạm vi
Không phải User có một Permission thì được thực hiện hành động đó tại mọi vị trí trong Project.
Quyền thực tế có thể phụ thuộc vào:
- ProjectRole;
- Group;
- Direct User Permission;
- Folder Permission;
- Document Permission.
Có thể hiểu:
Ai
+
Vai trò gì
+
Thuộc Group nào
+
Đang thao tác ở đâu
→ Effective Permission.
Ví dụ:
Một Designer có quyền Upload nhưng Folder cụ thể có thể không cho phép Upload đối với Group đó.
--------------------------------------------------
### 2.12.21. Ưu tiên phân quyền theo Role và Group
Khi tổ chức Permission nên ưu tiên:
ProjectRole
→ quyền tiêu chuẩn theo vai trò.
Group
→ quyền theo nhóm công việc.
Folder / Document Permission
→ giới hạn theo phạm vi dữ liệu.
Direct User Permission
→ xử lý ngoại lệ.
Không nên cấp quá nhiều Direct Permission cho từng User vì hệ thống sẽ khó quản lý khi Project lớn.
--------------------------------------------------
### 2.12.22. Deny chỉ sử dụng khi thực sự cần
Trong Folder / Document Permission:
Allow
→ cấp quyền.
Không chọn
→ không cấp trực tiếp quyền từ cấu hình này.
Deny
→ chủ động chặn.
Deny là cơ chế mạnh và cần sử dụng thận trọng.
Nếu chỉ muốn không cấp quyền, không nên tự động sử dụng Deny.
Quá nhiều Deny sẽ khiến Effective Permission khó hiểu và khó kiểm tra.
--------------------------------------------------
### 2.12.23. Mọi thay đổi quan trọng phải có khả năng truy vết
CDE cần lưu lại các thông tin như:
- CreatedBy;
- CreatedDate;
- UploadedBy;
- UploadDate;
- DeletedBy;
- DeletedAt;
- Reviewer;
- ReviewDate;
- ApprovedBy;
- ApprovedAt;
- UpdatedBy;
- UpdatedAt.
Mục tiêu là có thể trả lời:
Ai?
Làm gì?
Với Document nào?
Version nào?
Khi nào?
Đây là nền tảng của Audit Trail trong CDE.
--------------------------------------------------
### 2.12.24. Hạn chế Download / Upload thủ công
CDE NPD hướng đến quy trình làm việc khép kín.
Thay vì:
Download
→ sửa bên ngoài
→ tìm file
→ Upload lại,
nên ưu tiên các workflow tích hợp:
Revit
→ CDE
CDE
→ Navisworks
Navisworks
→ CDE
CDE
→ Revit
hoặc:
Revit
→ PDF
→ CDE Review
→ kết quả Review
→ Revit.
Download vẫn được hỗ trợ nhưng không nên trở thành cách làm việc mặc định nếu CDE đã có chức năng tích hợp trực tiếp.
--------------------------------------------------
### 2.12.25. Không dùng file làm trung tâm duy nhất
Trong CDE NPD, file không phải đối tượng trung tâm duy nhất.
Document còn có thể liên kết với:
- BIM Object;
- Work Package;
- Clash;
- Review;
- Technical Review;
- Task;
- Risk;
- COBie;
- Cost;
- Planning;
- các dữ liệu nghiệp vụ khác.
Do đó không nên quản lý thông tin theo tư duy:
"Chỉ cần tìm đúng file là đủ."
CDE cần biết:
File này thuộc Document nào?
Version nào?
Liên quan Object nào?
Package nào?
Workflow nào?
Ai chịu trách nhiệm?
--------------------------------------------------
### 2.12.26. Không thay đổi Identity chỉ vì nội dung thay đổi
Nếu bản chất Information Container vẫn là cùng một tài liệu thì việc thay đổi nội dung không nên làm thay đổi Document Identity.
Ví dụ:
Bản vẽ mặt bằng tầng 1 được chỉnh sửa.
Đúng:
Document cũ
→ Version mới.
Không nên:
Document cũ
→ tạo một Document mới chỉ vì đã sửa nội dung.
Chỉ tạo Document mới khi bản chất Information Container thực sự khác.
--------------------------------------------------
### 2.12.27. RevisionNote nên giải thích thay đổi giữa các Version
Khi tạo Version mới, nên sử dụng RevisionNote để ghi ngắn gọn nội dung thay đổi khi cần.
Ví dụ:
- Sửa cửa theo Review.
- Cập nhật MEP tầng 2.
- Điều chỉnh theo RFI-015.
- Cập nhật kết cấu theo thiết kế mới.
RevisionNote giúp Reviewer và các bên liên quan hiểu Version mới khác Version trước ở đâu.
--------------------------------------------------
### 2.12.28. Người dùng phải làm việc trên đúng Project
Project là phạm vi dữ liệu độc lập.
Mỗi Project có:
- ProjectCode;
- Member;
- Group;
- ProjectRole;
- NameCode;
- Folder;
- Permission;
- Workflow;
- Version;
- Setting riêng.
Trước khi Upload, Review hoặc quản lý tài liệu, người dùng cần kiểm tra đúng Project hiện hành.
Không sử dụng tài liệu của Project này cho Project khác chỉ vì tên hoặc nội dung tương tự.
--------------------------------------------------
### 2.12.29. CDE phải là nguồn thông tin chính thức của Project
Khi Project đã sử dụng CDE NPD, CDE nên được xem là nguồn dữ liệu chính thức để xác định:
- Document hiện tại;
- Current Version;
- trạng thái Review;
- trạng thái Approval;
- bản Published;
- lịch sử Version;
- quyền truy cập.
Không nên duy trì song song nhiều nguồn "chính thức" khác nhau như:
- thư mục cá nhân;
- ổ mạng;
- USB;
- email;
- ứng dụng chat.
Các bản sao ngoài CDE chỉ nên được xem là bản sao phục vụ công việc khi cần.
--------------------------------------------------
### 2.12.30. Nguyên tắc cốt lõi
Có thể tóm tắt toàn bộ cơ chế quản lý tài liệu của CDE NPD bằng chuỗi:
Project
→ Document
→ DocumentVersion
→ Zone
→ Review
→ Approval
→ Published
→ Archive.
Trong đó:
Project
→ xác định phạm vi.
Document
→ xác định Information Container.
DocumentVersion
→ xác định nội dung tại một thời điểm.
WIP
→ tạo và chỉnh sửa.
Shared
→ chia sẻ và phối hợp.
Review / Approval
→ kiểm tra và quyết định.
Published
→ thông tin chính thức.
Archive
→ bảo toàn lịch sử.
Recycle Bin
→ bảo vệ dữ liệu trước khi xóa vật lý.
Permission
→ kiểm soát ai được làm gì.
Audit Trail
→ ghi lại ai đã làm gì và khi nào.
Nguyên tắc tổng quát:
Đúng tài liệu
→ đúng Version
→ đúng Zone
→ đúng người
→ đúng quyền
→ đúng Workflow
→ có thể truy vết.