Một dự án xây dựng chỉ quản lý được thông tin khi trả lời rành mạch bốn câu hỏi: tổ chức cần thông tin gì, dự án cần thông tin gì, công trình sau bàn giao cần thông tin gì, và thông tin nào phải được trao đổi giữa các bên.
Bốn câu hỏi đó tương ứng với bốn lớp yêu cầu thông tin: yêu cầu thông tin cấp tổ chức (OIR), yêu cầu thông tin dự án (PIR), yêu cầu thông tin tài sản (AIR) và yêu cầu trao đổi thông tin (EIR).
Ba lớp đầu xác định cần gì; lớp cuối xác định giao nhận thế nào. Chính lớp cuối biến nhu cầu thành nhiệm vụ cụ thể trong kế hoạch thực hiện BIM, nên bỏ sót bất kỳ lớp nào cũng dẫn tới thiếu dữ liệu ở giai đoạn không còn sửa được.
Vì sao quản lý BIM phải bắt đầu từ yêu cầu thông tin?
Khi một dự án tuyên bố áp dụng BIM, câu hỏi đầu tiên cần trả lời không phải là “dùng phần mềm nào” mà là “chúng ta cần thông tin gì, để phục vụ quyết định nào”. Việc phân tầng nhu cầu thành bốn lớp là cách để câu hỏi đó không bị bỏ sót ở bất kỳ cấp nào.
Cách phân tầng này xuất phát từ một quan sát thực tế: nhu cầu thông tin của tổ chức khác nhu cầu của một dự án cụ thể, và cả hai lại khác nhu cầu của người vận hành công trình sau khi dự án kết thúc. Nếu gộp chung, luôn có một nhóm nhu cầu bị bỏ quên — thường là nhóm vận hành, vì họ chưa xuất hiện lúc dự án bắt đầu.
Về cách gọi tên: cụm “hệ thống yêu cầu thông tin” dùng trong bài là cách diễn đạt để gọi chung bốn lớp, không phải tên gọi chính thức do một tiêu chuẩn nào quy định. bài viết này dùng EIR = Exchange Information Requirements (yêu cầu trao đổi thông tin), thống nhất với đề cương chương trình BIM của Viện. Trong một số tài liệu cũ hơn, cụm EIR từng được hiểu là “Employer’s Information Requirements”. Khi đọc hồ sơ dự án, nên xác nhận tài liệu đang dùng nghĩa nào để tránh hiểu nhầm phạm vi.
Điều gì xảy ra khi dự án không xác định yêu cầu thông tin?
Không xác định yêu cầu thông tin, dự án vẫn có mô hình — nhưng sẽ gặp ba vấn đề lặp đi lặp lại.
Thứ nhất, mỗi bên hiểu “đủ thông tin” theo một kiểu. Bộ môn kiến trúc nghĩ mô hình đã đủ để duyệt phương án; bên chi phí lại thấy thiếu thuộc tính để bóc khối lượng; bên vận hành thì không tìm được thông tin thiết bị nào. Cả ba đều đúng theo góc nhìn của mình, vì chưa ai định nghĩa “đủ” là gì.
Thứ hai, công sức bị đặt nhầm chỗ. Không có yêu cầu rõ, người dựng mô hình có xu hướng làm chi tiết những gì mình quen thuộc và bỏ qua những gì mình không biết ai cần. Kết quả là mô hình rất công phu ở vài chỗ và trống rỗng ở những chỗ quan trọng.
Thứ ba, đến lúc bàn giao mới phát hiện thiếu. Đây là hệ quả nghiêm trọng nhất. Dữ liệu phục vụ vận hành không tự xuất hiện; nếu không ai được giao nhiệm vụ tạo ra từ đầu, đến cuối dự án việc bổ sung gần như phải làm lại từ số không.
Yêu cầu thông tin ở cấp tổ chức: vai trò của OIR
OIR — Organizational Information Requirements — là yêu cầu thông tin ở cấp tổ chức. Đây là những thông tin mà một chủ đầu tư, một tập đoàn hay một cơ quan cần có để phục vụ mục tiêu và quyết định của chính tổ chức đó, không giới hạn ở một dự án đơn lẻ.
Ví dụ, một tổ chức sở hữu nhiều công trình có thể cần biết: tổng diện tích sàn đang quản lý, chi phí vận hành theo từng loại công trình, tuổi thọ còn lại của các hệ thống kỹ thuật chính. Những nhu cầu này tồn tại độc lập với việc họ đang triển khai dự án nào.
OIR quan trọng vì nó là điểm neo: nếu tổ chức không biết mình cần gì, thì mọi yêu cầu ở cấp dự án phía dưới đều thiếu căn cứ. Trong thực tế, nhiều tổ chức chưa từng viết OIR ra thành văn bản — nhu cầu tồn tại trong đầu người quản lý nhưng không được diễn đạt thành yêu cầu dữ liệu.
Yêu cầu thông tin của dự án: vai trò của PIR
PIR — Project Information Requirements — là yêu cầu thông tin của một dự án cụ thể. Đây là bước cụ thể hóa OIR xuống phạm vi một dự án, gắn với các mốc quyết định của dự án đó.
PIR thường trả lời: ở mỗi giai đoạn, người ra quyết định cần biết gì để phê duyệt bước tiếp theo? Trước khi duyệt phương án thiết kế, cần thông tin nào? Trước khi khởi công, cần thông tin nào? Trước khi nghiệm thu, cần thông tin nào?
Điểm dễ nhầm: PIR không phải danh sách sản phẩm cần nộp. Nó là danh sách nhu cầu thông tin gắn với quyết định. Sản phẩm cần nộp là hệ quả, không phải điểm xuất phát. Bắt đầu từ “cần nộp file gì” sẽ dẫn tới bộ hồ sơ đầy đủ về hình thức nhưng không giúp ai ra quyết định tốt hơn.
Yêu cầu thông tin tài sản: vai trò của AIR
AIR — Asset Information Requirements — là yêu cầu thông tin phục vụ quản lý và vận hành tài sản sau khi công trình hoàn thành.
Đây là lớp yêu cầu hay bị bỏ quên nhất, vì lý do rất đơn giản: người sẽ dùng thông tin này thường chưa có mặt lúc dự án bắt đầu. Đội vận hành nhận bàn giao khi mọi quyết định về dữ liệu đã được đưa ra từ lâu.
AIR trả lời các câu hỏi thuộc về vòng đời sau xây dựng: cần biết gì về mỗi thiết bị để lập kế hoạch bảo trì? Cần thông tin nào để xử lý sự cố nhanh? Cần dữ liệu nào để đánh giá hiệu quả vận hành?
Nguyên tắc thực dụng: AIR phải được đặt ra sớm, dù người dùng nó xuất hiện muộn. Nếu chủ đầu tư muốn có dữ liệu bảo trì trong bộ bàn giao, yêu cầu đó phải xuất hiện ngay từ giai đoạn chuẩn bị — vì nó quyết định người dựng mô hình phải nhập những thuộc tính nào ngay từ đầu.
Yêu cầu trao đổi thông tin: vai trò của EIR
EIR — Exchange Information Requirements — là yêu cầu về việc trao đổi thông tin giữa các bên. Nếu ba lớp trên trả lời “cần thông tin gì”, thì EIR trả lời “thông tin đó được giao nhận như thế nào”.
EIR thường đề cập tới: thông tin nào cần được trao đổi, ở thời điểm nào, dưới định dạng gì, do bên nào cung cấp, theo quy ước đặt tên nào, và được kiểm tra chấp thuận ra sao.
Vai trò của EIR mang tính bản lề. Đây là tài liệu mà bên yêu cầu thông tin (thường là chủ đầu tư) dùng để nói với các bên thực hiện: đây là những gì chúng tôi cần nhận, theo cách này. Các bên thực hiện đọc EIR rồi trả lời bằng kế hoạch thực hiện BIM — cam kết họ sẽ đáp ứng ra sao.
Mục này chỉ nêu vị trí của EIR trong hệ thống bốn lớp. Nội dung chi tiết — các nhóm nội dung khi xây dựng, cách viết yêu cầu kiểm tra được, checklist khi đọc và lỗi thường gặp — được trình bày riêng tại bài yêu cầu trao đổi thông tin EIR.
Vì tính bản lề đó, EIR được trình bày chi tiết trong một bài riêng: yêu cầu trao đổi thông tin EIR.
OIR, PIR, AIR và EIR khác nhau ở phạm vi nào?
| Tiêu chí | OIR | PIR | AIR | EIR |
|---|---|---|---|---|
| Phạm vi | Cả tổ chức | Một dự án | Tài sản sau bàn giao | Việc giao nhận thông tin |
| Câu hỏi trả lời | Tổ chức cần biết gì? | Dự án cần biết gì? | Vận hành cần biết gì? | Giao nhận thế nào? |
| Ai thường đặt ra | Cấp quản lý tổ chức | Ban quản lý dự án | Bên vận hành / chủ sở hữu | Bên yêu cầu thông tin |
| Thời điểm | Trước và ngoài dự án | Đầu dự án | Đặt sớm, dùng muộn | Trước khi chọn bên thực hiện |
| Tuổi thọ | Dài, ít thay đổi | Theo vòng đời dự án | Kéo dài sau bàn giao | Theo từng gói/hợp đồng |
| Đầu ra dẫn tới | Định hướng PIR | Định hướng EIR | Định hướng dữ liệu bàn giao | Kế hoạch thực hiện BIM |
Mối quan hệ giữa bốn lớp yêu cầu thông tin
Sơ đồ dưới đây minh họa quan hệ khái quát. Đây là cách trình bày để dễ hình dung, không phải một trình tự pháp lý bắt buộc — thực tế nhiều dự án làm song song hoặc lặp lại nhiều vòng.
- OIRYêu cầu thông tin cấp tổ chứcTổ chức cần thông tin gì để ra quyết định và quản lý danh mục tài sản của mình.
- PIRYêu cầu thông tin dự ánDự án cụ thể này cần thông tin gì, gắn với các mốc phê duyệt của dự án.
- AIRYêu cầu thông tin tài sảnSau khi bàn giao, đội vận hành cần thông tin nào để quản lý và bảo trì công trình.
- EIRYêu cầu trao đổi thông tinBa lớp trên được chuyển thành yêu cầu giao nhận cụ thể: nội dung, thời điểm, định dạng, quy ước, cách kiểm tra.
Từ EIR, dòng chảy tiếp tục xuống kế hoạch thực hiện BIM (BEP) — nơi các bên thực hiện cam kết cách họ đáp ứng yêu cầu — rồi xuống môi trường dữ liệu chung (CDE), nơi thông tin thực sự được tạo, kiểm tra và chia sẻ.
Một cách nhớ đơn giản: OIR/PIR/AIR là nhu cầu, EIR là hợp đồng thông tin, BEP là kế hoạch đáp ứng, CDE là nơi việc đó diễn ra.
Tư vấn đăng ký: 0904 889 859 – Ms. Hoa
Các lớp yêu cầu thông tin kết nối với kế hoạch thực hiện BIM ra sao?
Quan hệ giữa yêu cầu thông tin và kế hoạch thực hiện BIM giống quan hệ giữa đề bài và lời giải.
EIR nêu đề bài: chúng tôi cần nhận những thông tin này, vào các thời điểm này, theo quy ước này. Bên thực hiện đọc đề bài đó rồi soạn kế hoạch thực hiện BIM để trả lời: chúng tôi sẽ tổ chức công việc thế nào, ai làm gì, mô hình được phân chia ra sao, thông tin được nộp theo mốc nào.
Hệ quả thực tế của quan hệ này rất rõ: một kế hoạch thực hiện BIM không đối chiếu được với yêu cầu thông tin thì không kiểm tra được. Bạn không thể đánh giá lời giải nếu không biết đề bài. Đây là lý do khi rà soát BEP, việc đầu tiên nên làm là mở EIR ra đặt cạnh.
Yêu cầu thông tin được thực thi trong môi trường dữ liệu chung thế nào?
Yêu cầu thông tin quyết định khá nhiều thứ trong cách môi trường dữ liệu chung được thiết lập, dù hai chủ đề này thường được bàn tách rời.
Nếu EIR quy định thông tin phải được nộp theo từng mốc và phải trải qua bước kiểm tra trước khi được chấp thuận, thì môi trường dữ liệu chung phải có trạng thái tương ứng để phản ánh việc đó. Nếu yêu cầu có quy ước đặt tên, thì cấu trúc lưu trữ phải hỗ trợ quy ước đó thay vì chống lại nó.
Nói cách khác, môi trường dữ liệu chung không nên được thiết kế trước rồi mới nhét yêu cầu vào sau. Trình tự hợp lý là ngược lại. Chi tiết xem tại bài môi trường dữ liệu chung (CDE).
BIM Manager sử dụng các yêu cầu thông tin để kiểm soát dự án như thế nào?
Với người làm quản lý BIM, bốn lớp yêu cầu thông tin không phải kiến thức để thuộc lòng mà là công cụ làm việc hằng ngày. Có ba năng lực cụ thể cần phát triển.
- Năng lực 01Diễn giải nhu cầu thành yêu cầu dữ liệuNghe chủ đầu tư nói “tôi muốn quản lý bảo trì tốt hơn” và chuyển thành danh sách thuộc tính cụ thể, kiểm tra được.
- Năng lực 02Giữ tính nhất quán giữa các lớpBảo đảm yêu cầu ở lớp trên thực sự xuất hiện ở lớp dưới, không bị rơi rụng dọc đường.
- Năng lực 03Biết dừng đúng chỗYêu cầu quá nhiều thông tin cũng có hại như quá ít: tốn công tạo ra dữ liệu không ai dùng.
Năng lực thứ ba thường bị đánh giá thấp. Trong thực tế, danh sách yêu cầu càng dài thì khả năng được tuân thủ đầy đủ càng thấp. Một bộ yêu cầu ngắn nhưng được thực hiện nghiêm túc có giá trị hơn một bộ dài mà không ai kiểm tra được.
Ví dụ minh họa trong một dự án
| Lớp | Nội dung trong ví dụ |
|---|---|
| OIR | Đơn vị muốn theo dõi chi phí vận hành hệ thống điều hòa trên toàn bộ danh mục tòa nhà để so sánh hiệu quả giữa các công trình. |
| PIR | Với công trình mới này, ở mốc duyệt thiết kế kỹ thuật cần biết công suất và chủng loại thiết bị điều hòa dự kiến; ở mốc nghiệm thu cần biết thiết bị thực tế đã lắp. |
| AIR | Sau bàn giao, đội vận hành cần mã thiết bị, nhà sản xuất, ngày lắp đặt, chu kỳ bảo dưỡng khuyến nghị và thông tin bảo hành của từng máy. |
| EIR | Nhà thầu cơ điện phải nộp danh mục thiết bị kèm các thuộc tính trên, theo quy ước đặt tên đã thống nhất, tại hai mốc: khi duyệt vật tư và khi nghiệm thu; nộp qua môi trường dữ liệu chung và phải được bên tư vấn kiểm tra trước khi chấp thuận. |
Điều đáng chú ý trong ví dụ: yêu cầu ở AIR (thông tin bảo hành, chu kỳ bảo dưỡng) chỉ thành hiện thực nếu nó được viết vào EIR ngay từ đầu. Nếu bỏ qua bước đó, đến lúc nghiệm thu sẽ không ai có nghĩa vụ cung cấp những thuộc tính này.
Những nhầm lẫn thường gặp
Nhầm lẫn 1: Coi bốn lớp là bốn tài liệu bắt buộc phải có
Không phải dự án nào cũng cần đủ bốn tài liệu riêng biệt. Ở dự án nhỏ, nội dung của cả bốn có thể gộp trong một tài liệu ngắn. Điều quan trọng là các câu hỏi được trả lời, không phải số lượng tài liệu.
Nhầm lẫn 2: Nghĩ EIR là danh sách file cần nộp
EIR không chỉ liệt kê sản phẩm. Nó mô tả yêu cầu về nội dung thông tin, thời điểm, định dạng, quy ước và cách kiểm tra. Một EIR chỉ có danh sách file sẽ không giúp bên thực hiện hiểu thông tin phải chi tiết đến đâu.
Nhầm lẫn 3: Viết yêu cầu bằng ngôn ngữ không kiểm tra được
“Mô hình phải đầy đủ thông tin” là một yêu cầu không dùng được, vì không ai kiểm tra được thế nào là đầy đủ. Yêu cầu tốt phải diễn đạt được thành tiêu chí kiểm tra cụ thể.
Nhầm lẫn 4: Bỏ qua AIR vì “chưa đến lúc”
Đây là nhầm lẫn tốn kém nhất. Thông tin phục vụ vận hành phải được thu thập trong quá trình thực hiện, không thể bổ sung ngược sau khi công trình đã hoàn thành.
Nhầm lẫn 5: Sao chép bộ yêu cầu từ dự án khác
Yêu cầu thông tin phản ánh nhu cầu quyết định cụ thể của tổ chức và dự án. Sao chép nguyên bộ từ dự án khác thường tạo ra tài liệu đầy đủ về hình thức nhưng không khớp với thứ đơn vị thực sự cần.
Bốn lớp yêu cầu trong dự án ở các quy mô khác nhau
Một phản ứng thường gặp khi lần đầu nhìn cấu trúc bốn lớp là: dự án của tôi nhỏ, chẳng lẽ phải làm đủ bốn bộ tài liệu? Câu trả lời là không.
Bốn lớp mô tả bốn loại câu hỏi cần được trả lời, không phải bốn tập tài liệu bắt buộc. Với dự án nhỏ, cả bốn có thể gói trong vài trang. Điều quan trọng là không câu hỏi nào bị bỏ trống.
| Quy mô | Cách thể hiện thực tế | Rủi ro nếu bỏ qua hoàn toàn |
|---|---|---|
| Gói thầu nhỏ, một bên thực hiện | Một tài liệu vài trang, gộp cả bốn lớp thành các mục | Thông tin bàn giao không dùng được cho vận hành |
| Dự án vừa, nhiều bộ môn | Yêu cầu cấp dự án tách riêng; yêu cầu trao đổi lập theo từng gói | Các gói đòi hỏi lệch nhau, khó hợp nhất mô hình |
| Dự án lớn hoặc chuỗi nhiều dự án | Yêu cầu cấp tổ chức lập một lần, dùng lại cho nhiều dự án | Mỗi dự án tự định nghĩa lại, dữ liệu không so sánh được giữa các dự án |
| Tổ chức quản lý tài sản dài hạn | Yêu cầu cấp tài sản là trung tâm; các lớp khác phục vụ nó | Hết bảo hành mới phát hiện không có dữ liệu để vận hành |
Dòng cuối bảng đáng chú ý nhất. Với chủ sở hữu vận hành công trình lâu dài, lớp yêu cầu về tài sản mới là thứ tạo ra giá trị bền — nhưng nó lại là lớp thường được nghĩ đến muộn nhất, khi mọi quyết định về cấu trúc dữ liệu đã bị chốt.
Ai chịu trách nhiệm cho từng lớp?
Phân công trách nhiệm không giống nhau giữa các tổ chức, nhưng có một nguyên tắc chung: lớp nào phục vụ quyết định của ai thì người đó phải tham gia định nghĩa nó.
- Lớp tổ chứcCấp lãnh đạo và bộ phận quản lý danh mụcHọ là người dùng thông tin để ra quyết định đầu tư và ưu tiên nguồn lực.
- Lớp dự ánBan quản lý dự ánNgười theo dõi tiến độ, chi phí, chất lượng của chính dự án đó.
- Lớp tài sảnBộ phận vận hành và bảo trìNếu họ không được hỏi, dữ liệu bàn giao gần như chắc chắn sẽ thiếu thứ họ cần.
- Lớp trao đổiNgười phụ trách quản lý thông tin của bên yêu cầuNgười dịch ba lớp trên thành yêu cầu mà bên thực hiện đọc được.
Trong thực tế, lỗi phổ biến nhất là để một mình bộ phận kỹ thuật viết cả bốn lớp. Kết quả là tài liệu phản ánh những gì kỹ thuật quan tâm, còn nhu cầu của vận hành và của cấp quản lý bị bỏ ngoài — và không ai phát hiện ra cho đến khi quá muộn.
Kiểm tra tính nhất quán giữa bốn lớp
Khi đã có đủ bốn lớp, việc rà soát tính nhất quán giữa chúng quan trọng không kém việc viết ra từng lớp. Ba phép kiểm tra đơn giản:
- Truy ngược từ dưới lênChọn ngẫu nhiên một yêu cầu ở lớp trao đổi, hỏi nó phục vụ nhu cầu nào ở lớp trên. Không truy được nghĩa là yêu cầu thừa.
- Truy xuôi từ trên xuốngChọn một nhu cầu ở lớp tổ chức hoặc lớp tài sản, hỏi nó xuất hiện ở đâu trong lớp trao đổi. Không tìm thấy nghĩa là nhu cầu sẽ không được đáp ứng.
- Đối chiếu thuật ngữCùng một khái niệm có được gọi bằng cùng một tên ở cả bốn lớp không. Lệch tên gọi là nguồn gốc của phần lớn hiểu nhầm về sau.
Phép kiểm tra thứ hai thường phát hiện nhiều vấn đề nhất. Rất dễ viết ra một danh sách nhu cầu nghe hợp lý ở cấp cao, rồi quên chuyển chúng thành yêu cầu cụ thể — và một nhu cầu không được chuyển xuống thì không tồn tại trong mắt bên thực hiện.
Câu hỏi thường gặp về yêu cầu thông tin trong BIM
OIR, PIR, AIR, EIR khác nhau thế nào?
OIR là nhu cầu thông tin của tổ chức; PIR là nhu cầu của một dự án cụ thể theo từng mốc quyết định; AIR là nhu cầu phục vụ vận hành công trình sau bàn giao; EIR là yêu cầu về cách các bên trao đổi thông tin với nhau. Ba lớp đầu nói “cần gì”, lớp cuối nói “giao nhận thế nào”.
Dự án nhỏ có cần đủ bốn lớp không?
Không nhất thiết cần bốn tài liệu riêng. Điều cần thiết là các câu hỏi được trả lời ở mức phù hợp với quy mô. Ở dự án nhỏ, nội dung có thể gộp trong một tài liệu ngắn gọn.
EIR do ai lập?
EIR thường do bên yêu cầu thông tin lập — trong nhiều dự án là chủ đầu tư hoặc đơn vị tư vấn được chủ đầu tư ủy quyền. Bên thực hiện đọc EIR và trả lời bằng kế hoạch thực hiện BIM. Phân công cụ thể phụ thuộc vào cơ cấu hợp đồng của từng dự án.
Yêu cầu thông tin liên quan gì tới BEP?
Yêu cầu thông tin là đề bài, kế hoạch thực hiện BIM là lời giải. BEP mô tả cách bên thực hiện tổ chức công việc để đáp ứng những gì EIR yêu cầu. Rà soát BEP mà không đối chiếu với EIR thì không có cơ sở đánh giá.
Nếu tổ chức chưa có OIR thì làm sao?
Đây là tình huống rất phổ biến. Khi đó có thể bắt đầu từ PIR của dự án hiện tại, đồng thời ghi nhận lại những nhu cầu lặp đi lặp lại qua nhiều dự án — đó chính là nguyên liệu để hình thành OIR về sau.
Học nội dung này ở đâu?
Nội dung Quản lý BIM trong chương trình BIM của Viện Nghiên cứu Đào tạo Bồi dưỡng Cán bộ có phần về các yêu cầu thông tin OIR, PIR, AIR, EIR kèm bài thực hành thiết kế EIR rút gọn. Chi tiết xem tại khóa học Quản lý BIM – BIM Manager, hoặc liên hệ 0904 889 859 – Ms. Hoa để nhận thông tin tuyển sinh mới nhất.
