← Tüm makaleler

BIM Yönetimi / 12 dk

ISO 19650 ve CDE Nedir? BIM Projelerinde Dosya Karmaşasını Bitirmek

ISO 19650, CDE, bilgi gereksinimleri, revizyon ve onay süreçleri: BIM bilgi yönetimi için uygulanabilir kontrol listesi.

BIM ekibinin model revizyonlarını ortak veri ortamı aşamalarında incelemesi

Ortak veri ortamı yalnızca paylaşımlı klasör değildir

Common Data Environment (CDE), proje bilgilerinin hazırlanması, gözden geçirilmesi, paylaşılması ve yayımlanması için yönetilen bir süreç ve bilgi ortamıdır. Tek bir klasör yapısı veya bulut depolama hizmeti, tek başına güvenilir bilgi yönetimi sağlamaz.

ISO 19650 serisi, varlığın yaşam döngüsü boyunca bilginin üretilmesi, paylaşılması, kaydedilmesi ve sürümlenmesine yönelik bir çerçeve sunar. Standardı uygulamak, yalnızca dosya isimlendirme şablonu seçmekten daha geniş bir organizasyon işidir.

ISO 19650 ve CDE Nedir? BIM Projelerinde Dosya Karmaşasını Bitirmek için açıklayıcı teknik diyagram
Kavramsal teknik diyagram; süreç ve ilişkileri açıklamak amacıyla kullanılır.

Hangi bilgiler gerçekten teslim edilmeli?

Her modele bütün verileri yüklemek maliyetli ve çoğu zaman gereksizdir. Önce varlık sahibinin cevaplamak istediği soruları belirleyin. Bakım ekibi ekipman seri numarası ve garanti bitişi istiyorsa, teslim şartnamesinde bu alanların nasıl doldurulacağı ve nasıl doğrulanacağı açık olmalıdır.

Bilgi gereksinimlerini rol, aşama ve kabul kriterine bağlayın. Modelin gösterdiği geometriyle teslim edilen dokümanın sürümü arasında fark varsa hangi kaynağın geçerli olduğu belirlenmelidir.

01 / KAYNAKVarlık ve mühendislik verisi
02 / BAĞLAMOctatus BIM/GIS ve ilişkiler
03 / KARARDoğrulama ve işletme aksiyonu
Şematik bilgi akışı; gerçek entegrasyon ve veri sahipliği proje kapsamına göre belirlenir.

Revizyon ve onay neden ayrılmalı?

Bir dosyanın sisteme yüklenmesi, tasarımın onaylandığı anlamına gelmez. Hazırlayan, inceleyen ve onaylayan rollerini ayırın; değişikliğin gerekçesini ve önceki sürümle ilişkisini saklayın. Özellikle saha değişikliklerinde fotoğraf, kontrol formu ve model revizyonu aynı varlıkla ilişkilendirilmelidir.

Bir pilot iş akışında şu zinciri test edin: bulgu açma, sorumlu atama, düzeltme, doğrulama, onay ve kayıt kapatma. Her adımın zaman damgası ve kanıtı bulunmalıdır.

Octatus ile bilgi yönetimi

Octatus'un saha iş akışları ve mühendislik revizyonu yaklaşımı, model öğelerini bulgu ve onay kayıtlarıyla bağlamayı hedefler. Bu, ISO 19650 sertifikası veya standardın tüm maddelerine otomatik uyum iddiası değildir; kurumsal süreç tasarımı ayrıca doğrulanmalıdır.

Kaynak: ISO 19650-1 https://www.iso.org/standard/68078.html

Sahadan örnek: karar anında hangi bilgi gerekir?

Ortak veri ortamında (CDE) 'çalışma sürümü', 'paylaşılan', 'yayınlanan' ve 'arşivlenen' bilgi durumları arasındaki geçiş yetkilendirilmelidir. Klasör adlandırması tek başına bu kontrolü sağlamaz.

Bir proje mühendisi aynı mekanik modelin iki revizyonunu gördüğünde hangisinin koordinasyon için, hangisinin resmî teslim için kullanılacağını bilmelidir. CDE üzerinde bilgi konteynerinin durumu, revizyonu ve uygunluk amacı görünür olmalıdır. Dosya adının sonunda 'final' yazması yayımlama onayı anlamına gelmez. Karar, yetkili inceleme ve kayıtlı bilgi durumuna dayanır.

Uygulama ve kabul kontrolü

Bir teslimat paketi için sorumlu taraf, bilgi gereksinimi, revizyon, inceleme kararı, yayın onayı ve geri çekme süreci örnek iş akışında doğrulanmalıdır.

Pilot olarak mimari ve mekanik ekiplerin ortak kullandığı bir bilgi konteyneri seçilir. Taslak, paylaşım, inceleme, yayımlama ve arşiv süreçlerindeki yetkiler test edilir. Yetkisiz kullanıcının onaysız modeli resmî teslim olarak işaretleyememesi beklenir. Her geçişin kim tarafından, ne zaman ve hangi gerekçeyle yapıldığı izlenmelidir.

Yatırım ve kapsam kararı nasıl verilir?

CDE seçimi yapılırken depolama alanı ve kullanıcı lisansı tek başına karşılaştırılmamalıdır. Bir modelin paylaşılmış, incelemede ve yayımlanmış durumları arasında yetkisiz geçişin önlenmesi, yanlış revizyon kullanımının maliyetini azaltabilir. Pilot, iki disiplinin bir teslim konteyneri üzerindeki onay ve geri çekme işlemlerini izlemelidir. Yatırım hesabına bilgi gereksinimi tanımı, rol eğitimi, denetim kayıtları ve proje sonu arşiv erişimi eklenmelidir.

CDE yatırımında depolama kapasitesi kadar süreç disiplini önemlidir. Basit dosya paylaşımı bazı küçük ekipler için yeterli olabilir; çok disiplinli teslimlerde revizyon ve uygunluk yönetimi gereksinimi artar. Karar, dosya sayısına değil yanlış revizyon kullanımının doğurduğu koordinasyon ve yeniden iş maliyetine dayanmalıdır.

ISO 19650 ve CDE: teknik veri modeli ve tasarım kararları

ISO 19650 bir yazılım sertifikası değil bilgi yönetimi yaklaşımıdır. OIR kurumsal, AIR varlık, PIR proje ve EIR bilgi alışverişi gereksinimlerini tanımlar.

Bilgi konteyneri kimliği, revizyon ve durum kodları kurumun bilgi yönetimi kurallarında tanımlanır. Aynı dosyanın yeni sürümüyle farklı disiplinin ayrı dosyası karıştırılmamalıdır. CDE kayıtlarında sorumlu ekip, inceleme kararı, geçerlilik ve geçmiş sürüme erişim korunur. Bu yapı modeldeki tekil BIM eleman kimliğinden farklı bir seviyede yönetilir.

ISO 19650 ve CDE: standartlar ve birlikte çalışabilirlik sınırları

CDE'nin WIP, Shared, Published ve Archived durumları farklı yetki ve kullanım koşulları taşır. Dosya yüklemek onaylı yayın değildir.

ISO 19650 bilgi yönetimi çerçevesidir; belirli bir yazılım ürününü zorunlu kılmaz. Sözleşmeye bağlanan bilgi gereksinimleri, sorumluluklar ve teslim süreçleri önemlidir. CDE iş akışındaki durum adları veya kodların uygulanması ilgili standardın geçerli bölümü, ulusal ekler ve proje protokolüyle doğrulanmalıdır. Yazılımda bir onay düğmesi bulunması tek başına uyum kanıtı değildir.

ISO 19650 ve CDE: gerçek işletme senaryosu ve hata türleri

BEP, MIDP ve TIDP gibi planlarda sorumlu ekip, teslimat, zaman, kontrol ve kabul koşullarını sözleşmeye göre tanımlayın.

Örnek hata, koordinasyon amacıyla paylaşılan bir modelin yanlışlıkla yapım için onaylı sanılmasıdır. Bir başka risk, yeni revizyon yüklenirken eski inceleme yorumlarının bağlamını kaybetmesidir. Negatif testlerde yetkisiz yayımlama, geri çekilen teslim ve revizyon çakışması denenir. Sistem hangi kaydın geçerli olduğunu açık göstermelidir.

ISO 19650 ve CDE: pilot uygulama ve kabul kriterleri

Bir HVAC değişikliğini talep, revizyon, inceleme, onay, yayın, as-built ve işletme kaydı boyunca izleyerek kabul testi yapın.

Pilot kabul matrisi bir bilgi konteynerinin oluşturulmasından yayımlanmasına kadar tüm adımları kapsar. Her adım için sorumlu rol, beklenen durum, izin verilen işlem ve denetim kanıtı kaydedilir. Eski revizyonun yanlışlıkla güncel kabul edilmesi kritik hata sayılabilir. Kurumun bilgi gereksinimleriyle eşleşmeyen alanlar ayrı raporlanır.

ISO 19650 ve CDE: maliyet, ölçekleme ve yönetişim

CDE toplam sahip olma maliyetinde kullanıcı lisansları kadar süreç tasarımı, eğitim, bilgi gereksinimi şablonları ve denetim yükü bulunur. İki disiplinin aynı durum kodunu farklı yorumlaması yazılım maliyetinden bağımsız bir risktir. Bu nedenle geçiş bütçesine pilot inceleme ve düzeltme döngüleri eklenmelidir.

Yaygınlaştırma kararı bir pilotta tüm konteyner durum geçişleri ve denetim kayıtları doğrulandıktan sonra verilir. Yeni disiplin veya yüklenici katıldığında rol matrisi ve teslim şablonları yeniden gözden geçirilir. Başarı ölçütü yüklenen dosya sayısı değil, yanlış revizyon kullanımının ve onaysız paylaşımın azaltılmasıdır.

Bilgi yönetimi ile model üretimini ayırmak

ISO 19650 yaklaşımında esas mesele tek başına 3D model üretmek değildir; doğru bilgiyi, doğru sorumluluk altında, doğru zamanda ve uygun onay statüsüyle paylaşmaktır. Bir proje çok ayrıntılı modeller üretebilir fakat hangi revizyonun sahada kullanılacağı belli değilse bilgi yönetimi başarısızdır. Buna karşılık daha sınırlı bir model, net bilgi gereksinimleri ve güvenilir teslimat süreçleriyle işletmeye yüksek değer sağlayabilir.

Bu nedenle ISO 19650 odaklı bir proje başlangıcında önce kararların hangi bilgiye ihtiyaç duyduğu belirlenir. Bilgi konteynerlerinin adlandırılması, revizyon ve statü kodları, sorumlu roller, erişim yetkileri ve onay kapıları birlikte tasarlanır. Kullanılan yazılım bunları destekleyebilir; fakat süreç sahipliği ve sözleşmesel gereksinimler yazılı değilse teknoloji tek başına uyum sağlamaz.

OIR ve AIR nasıl somutlaştırılır?

Organizational Information Requirements kurumun stratejik kararlarını destekleyen bilgi ihtiyaçlarını tarif eder. Örneğin bir hastane işletmecisi kritik hizmetlerin kesintisiz sürmesini, bakım maliyetinin öngörülebilir olmasını ve mevzuat kayıtlarının izlenmesini isteyebilir. Asset Information Requirements bu hedefleri varlık düzeyine indirger: UPS kapasitesi, garanti süresi, bakım prosedürü, bağlı sistemler ve kabul belgeleri gibi alanlar belirlenir.

Her AIR alanı için veri kaynağı, güncelleme sorumlusu, doğrulama ve kullanım amacı yazılmalıdır. 'Bütün ekipmanların tüm üretici katalogları' gibi sınırsız talepler veri yükünü artırabilir. Bunun yerine risk temelli önceliklendirme yapılır. Kritik bir jeneratör için test ve yakıt kapasitesi bilgisi zorunlu olabilirken dekoratif bir eleman için yalnızca konum ve sınıflandırma yeterli görülebilir.

PIR ve EIR ile proje teslimatı tanımlamak

Project Information Requirements proje kararlarını destekleyen bilgiyi belirler; Exchange Information Requirements ise belirli bir bilgi alışverişinde neyin, ne zaman ve hangi koşulla teslim edileceğini tanımlar. Bir kampüs yenileme projesinde tasarım kararları için elektrik yük dağılımı gerekli olabilir; işletmeye teslim aşamasında ise sahada doğrulanmış pano kimlikleri, test sonuçları ve bakım belgeleri istenir.

EIR yazarken yalnızca 'IFC teslim edilecek' demek yerine varlık sınıfları, zorunlu özellikler, format ve sürüm, model koordinatları, kalite kontrol yöntemi, hata toleransı ve kabul otoritesi belirtilmelidir. Bilginin hangi aşamada taslak, hangi aşamada onaylı olduğu ayrılmalıdır. Böylece yüklenicinin teslim ettiği dosya sayısı değil, işletmenin gerçekten kullanabileceği bilgi ölçülür.

CDE bilgi konteyneri ve durum yönetimi

Common Data Environment tek bir paylaşılan klasör olarak anlaşılmamalıdır. Bilgi konteyneri, dosya veya veri paketi gibi yönetilen birim olabilir; üzerinde kimlik, revizyon, uygunluk, durum, sorumlu ve erişim kontrolleri bulunur. WIP üretim sırasında ekip içi çalışmayı, Shared koordinasyon için kontrollü paylaşımı, Published yetkilendirilmiş kullanımı, Archived ise tarihsel kaydı temsil eden yaygın süreç durumlarıdır.

Örneğin mekanik ekip bir kanal revizyonunu WIP ortamında hazırlarken elektrik ekibinin sahada bunu uygulama çizimi olarak kullanmaması gerekir. Koordinasyon incelemesinden sonra paylaşılan revizyon uygunluk kontrolünden geçebilir; yetkili yayın kararı olmadan uygulama için geçerli sayılmamalıdır. Bir önceki revizyonun arşivde bulunması, onun güncel uygulama dokümanı olduğu anlamına gelmez.

BEP ile teslimat planlarının ilişkisi

BIM Execution Plan bilgi üretimi ve koordinasyon yaklaşımını açıklamak için kullanılır. Master Information Delivery Plan ve Task Information Delivery Plan gibi planlama araçları hangi ekibin hangi bilgi paketini ne zaman üreteceğini görünür kılar. Ancak bu belgelerin kapsamı ve isimlendirmesi sözleşmeye, standardın kullanılan baskısına ve yerel uygulamaya göre teyit edilmelidir. Bir belge adının bulunması, içeriğinin yeterli olduğu anlamına gelmez.

Örnek olarak mekanik ekip ekipman listesini hazırlarken elektrik ekibi besleme ilişkilerini, otomasyon ekibi kontrol noktalarını ve işletmeci bakım alanlarını tanımlar. Bu teslimatlar birbirine bağımlıdır. Plan, bir ekip geciktiğinde diğer bilgi paketlerinin nasıl etkileneceğini göstermelidir. Revizyonlar yalnızca takvim güncellemesi değil, veri kalitesi ve kabul planının yeniden değerlendirilmesini de gerektirebilir.

Onay matrisi ve rol ayrılığı

Bilgiyi üreten, inceleyen, uygun bulan ve yayımlayan taraflar aynı kişi veya rol olmak zorunda değildir. Özellikle güvenlik açısından kritik sistemlerde üretici ile onaylayıcının ayrılması hata riskini azaltabilir. Yetki matrisi her bilgi türü için kimin dosya yükleyebildiğini, kimin değişiklik talep edebildiğini, kimin yayın yapabildiğini ve kimin geri çekme kararı verebildiğini açıkça tanımlamalıdır.

Bir CDE yazılımında klasör erişimi vermek, onay yetkisi vermekle aynı şey değildir. Rol bazlı erişim, statü geçişleri ve denetim izi birlikte test edilmelidir. Örneğin yüklenici kendi WIP modelini güncelleyebilir fakat işverenin yayımlanmış kabul paketini değiştirememelidir. Ayrılan personelin yetkileri iptal edilmeli, delege edilen onaylar süre ve kapsam bakımından kayıt altına alınmalıdır.

Revizyon, statü ve uygunluk kodları

Bir bilgi konteynerinin revizyonu onun değişiklik geçmişini, statüsü ise hangi amaçla kullanılabileceğini açıklamaya yardımcı olur. Aynı dosya adının sonuna 'final', 'final2' veya 'son' eklemek denetlenebilir bir yöntem değildir. Kurumun adlandırma standardında proje, disiplin, bilgi türü, sıra, revizyon ve statü alanları tutarlı olmalıdır. Ancak kullanılan kodların anlamı sözleşme ve yerel bilgi standardına göre belirlenmelidir.

Örneğin bir elektrik tek hat şemasının koordinasyon için paylaşılan sürümü ile uygulama için yayımlanan sürümü aynı görünebilir ama kullanım yetkileri farklıdır. Kullanıcıya belgeyi indirirken geçerlilik statüsü açıkça gösterilmelidir. Yeni revizyon yayımlandığında eski sürüme erişim tamamen silinmek zorunda değildir; fakat yanlışlıkla güncel gibi kullanılmasını önleyecek uyarılar gerekir.

CDE ile Octatus varlık bilgi yönetimi nasıl bağlanır?

CDE onaylı bilgi paketlerini ve süreç kayıtlarını yönetirken Octatus fiziksel varlık, mekânsal bağlam ve ilişkilerin işletme görünümünü sunabilir. Bir IFC modelinin CDE'de yayımlanması, bütün ekipman alanlarının otomatik olarak doğrulanmış işletme kaydı olduğu anlamına gelmez. Veri dönüştürme, kimlik eşleme, kalite kontrol ve işletme onayı ayrı kapılardır. Böylece tasarım teslimatı ile canlı varlık kaydı birbirine karıştırılmaz.

Bir pompa değişikliğinde tasarım revizyonu CDE'de yayımlanabilir; fakat sahada yeni pompa monte edilip kabul edilene kadar işletme kaydı eski fiziksel varlığı gösterebilir. Octatus bu iki durumu farklı geçerlilik zamanlarıyla ilişkilendirebilir. İlgili mühendislik değişikliği Velocize gibi uzman bir sistemde, bakım iş emri ise ilgili işletme sisteminde kalabilir. Yetkili veri kaynakları korunmalıdır.

İhale ve sözleşmede doğrulanabilir teslimat

Teknik şartname bilgi gereksinimlerini, model ve belge formatlarını, koordinat sistemini, varlık sınıflandırmasını, revizyon kurallarını, CDE rollerini, onay akışlarını ve teslimat zamanlarını kapsamalıdır. Yükleniciye yalnızca model üretim görevi vermek, işletmeye aktarılacak verinin doğruluğunu garanti etmez. Teslimat paketinin hangi örneklemde nasıl denetleneceği, hata düzeltme süresi ve yeniden teslim koşulları yazılmalıdır.

Kabul sırasında bir HVAC ekipmanının gereksinimden tasarım revizyonuna, koordinasyon incelemesine, yayımlanmış modele, saha testine ve işletme varlık kaydına uzanan zinciri izleyin. Her adımın sorumlusu ve kanıtı bulunmalıdır. Bir adım eksikse dosya teknik olarak açılıyor olsa bile işletme teslimatı tamamlanmış sayılmamalıdır. Bu yaklaşım ihtilaflarda da nesnel değerlendirme zemini oluşturur.

Bilgi güvenliği ve hassas varlık kayıtları

Her BIM modeli herkese açık olmamalıdır. Kritik altyapı, güvenlik sistemleri, hassas teknik odalar ve erişim güzergâhları bazı kurumlarda kısıtlı bilgi olarak sınıflandırılabilir. ISO 19650 ailesinin güvenlik odaklı bilgi yönetimi yaklaşımı ve kurumun kendi siber güvenlik politikaları birlikte değerlendirilmelidir. Erişim yalnızca proje rolüne göre değil, bilginin hassasiyetine ve iş ihtiyacına göre sınırlandırılmalıdır.

CDE dış paylaşımlarında indirme, bağlantı süresi, üçüncü taraf erişimi, denetim kaydı ve veri saklama koşulları belirlenmelidir. Yedekleme ve arşiv kopyaları da aynı sınıflandırma kapsamında korunmalıdır. Kapalı ağ veya yerel barındırma gereksinimi varsa lisans doğrulaması, uzaktan destek ve telemetri gibi dolaylı veri akışları test edilmelidir. Güvenlik kontrolleri kullanıcı iş akışını tamamen durdurmadan uygulanmalıdır.

Olgunluk değerlendirmesi ve pilot kabulü

ISO 19650 odaklı pilotu değerlendirmek için yalnızca model kalitesine bakmayın. Bilgi gereksinimlerinin izlenebilirliği, doğru revizyonun bulunabilirliği, onay süresi, yetkisiz statü geçişi sayısı, eksik teslimat alanları ve arşivden geçmiş kayda erişim gibi göstergeler kullanın. Pilot başlamadan önce ölçüm yöntemi belirlenmeli; farklı proje ekiplerinin aynı kuralları uygulayıp uygulamadığı örneklemle sınanmalıdır.

Örnek pilotta iki disiplin, bir kritik ekipman grubu ve bir değişiklik senaryosu seçilebilir. Değişiklik talebinden yayımlanmış bilgi paketine kadar her kontrol adımı izlenir. Sonuçta eksik rol, belirsiz gereksinim, yanlış statü ve gecikmiş onay gibi sorunlar kayıt altına alınır. Yaygınlaştırma kararı, yalnızca yazılımın çalışmasına değil, süreçlerin sürdürülebilirliğine ve kurumun bakım kapasitesine dayanmalıdır.

Bilgi teslimi ile sözleşme kabulü arasındaki ayrım

Bir bilgi paketinin CDE ortamına yüklenmesi, teslim edilmesi, teknik incelemeden geçmesi ve sözleşmesel olarak kabul edilmesi farklı aşamalar olabilir. Özellikle çok disiplinli projelerde bir disiplinin onayladığı geometri, başka disiplinin sistem bağlantısı açısından hâlâ sorunlu olabilir. Bu nedenle kabul kararı ilgili kullanım amacı ve teslimat gereksinimleriyle ilişkilendirilmelidir.

İşveren, teslimat kontrolünde hem otomatik veri kurallarını hem de uzman incelemesini kullanabilir. Örneğin kritik ekipmanların asset ID ve zorunlu alanları makineyle denetlenirken, yangın güvenliği veya elektrik besleme ilişkileri yetkili mühendis tarafından doğrulanır. Sonuç raporu koşullu kabul, ret veya düzeltme gereksinimini açıkça belirtmelidir.

Sürdürülebilir işletme için bilgi yönetişimi

Proje tamamlandıktan sonra bilgi yönetimi sorumluluğu işletme organizasyonuna geçer. Yeni ekipman montajı, bakım sonucu, saha revizyonu veya varlık hizmet dışı bırakılması gibi olaylar kayıtların güncellenmesini gerektirir. Güncelleme iş akışı ve bütçesi yoksa teslim edilen model hızla güncelliğini kaybeder. Bu durum standarda atıf yapılmış olmasından bağımsız bir operasyonel risktir.

İşletme bilgi yöneticisi, teknik disiplin sorumluları ve sistem yöneticileri arasında rol ayrılığı yapılmalıdır. Periyodik örnekleme denetimiyle kritik varlıkların güncel revizyonu, doğru konumu, doküman bağlantısı ve onay geçmişi incelenebilir. Yeni bir tedarikçiyle çalışıldığında da aynı veri sözlüğü ve kabul kuralları korunmalıdır. Böylece bilgi kalitesi kişilere bağımlı olmaktan çıkar.

Yönetici için nihai karar ölçütü

ISO 19650 yaklaşımının başarısı bir CDE lisansının alınmasıyla değil, yetkili kişilerin doğru bilgiye onaylı sürüm üzerinden ulaşabilmesiyle ölçülür. Belirsiz rol, eksik gereksinim veya yanlış revizyon kullanımı sürüyorsa süreç olgunluğu henüz yeterli değildir.

Not: Teknik standartlara ilişkin açıklamalar bilgilendirme amaçlıdır. Ürün yetenekleri ve entegrasyon kapsamı proje bazında doğrulanmalıdır.