ISO 19650 CDE KURALLARIYLA VERİ YÖNETİMİ

CDE (Common Data Environment / ortak veri ortamı), ISO 19650'nin merkezinde yer alan ve proje boyunca üretilen her information container'ın (çizim, model, doküman, hesap) tek bir kontrollü ortamda tanımlı durumlar arasında geçerek dolaşmasını sağlayan iş akışı protokolüdür. Bu sayfada CDE'nin dört konteyner bölgesini (WIP, Shared, Published, Archived), S1-S5 ile A1 ve CR gibi suitability kodlarını, container adlandırma ve metadata alanlarını, federe model çakışma takibini ve Türk projelerindeki geçiş pratiklerini bulacaksınız. Merkezî bir ortam olmadığında "hangi versiyon onaylıydı, kim onayladı, ne zaman?" sorusu cevapsız kalır.

1. PAYLAŞIMLI SÜRÜCÜDEN CDE'YE NEDEN GEÇİLİR?

Türkiye'deki orta ölçekli mimarlık ofislerinin büyük bölümü hâlâ ağ üzerinde paylaşılan bir klasör (NAS, Google Drive, OneDrive, yerel sunucu) ile çalışır. "Proje" ana klasörü altında disiplin alt klasörleri, içinde rev01, rev02, final, final-final, son-revize klasörleri açılır. Bu mantığın çalıştığı projeler vardır; ancak iki sınır aşıldığında çöker: aktif disiplin sayısı dörtten fazla, eşzamanlı revizyon sayısı haftada beşten fazla. Bu band atlatıldığında dosya kaybı, üzerine yazma ve hangi versiyonun onaylı olduğu tartışması haftalık olağan hâle gelir. Standardın bu boşluğu kapatan resmi çerçevesi ISO web sitesindeki yayını üzerinden birinci elden takip edilebilir.

CDE bir klasör değildir, bir iş akışı protokolüdür. Üç temel özellikle paylaşımlı sürücüden ayrışır:

• Durum bilgisi: Her information container dört bölgeden birinde durur; bölge değiştirme bir kapıdan onayla geçer
• Denetim izi: Her revizyon, geçiş ve onay zaman damgalı, kullanıcı bağlamlı kayıt olarak saklanır; üç yıl sonraki yargı sürecinde bu kayıt kanıt değerindedir
• Rol bazlı erişim: WIP bölgesini sadece sahibi disiplin görür, Shared bölgesi koordinasyon ekibine açılır, Published bölgesi işveren onayı ile sahaya/üretime çıkar

Çevre, Şehircilik ve İklim Değişikliği Bakanlığı kamu yapım işlerinde BIM kullanımına yönelik yönergeler yayımlamakta; büyük altyapı ve raylı sistem ihaleleri BIM şartnamesi ile çıkmaktadır. ISO 19650 bu şartnamelerin uluslararası referans kaynağıdır; standart sözleşmeye girdiğinde paylaşımlı sürücü zorunlu olarak terk edilir.

2. DÖRT KONTEYNER BÖLGESİ VE GEÇİŞ KAPILARI

ISO 19650-1, information container'ın yaşam döngüsünü dört durumda tanımlar. Her container her an bu dört durumdan birindedir; bir sonrakine geçiş yalnızca tanımlı kapıdan gerçekleşir.

Work in Progress (WIP) — Çalışma alanı

Üreten disiplinin kendi içindeki taslak alanı. Yalnızca o disiplinin ekibi okur ve değiştirir. Mimari ekibin Revit modeli, statikçinin SAP2000 hesap dosyası, mekanikçinin DWG çizim seti burada üretilir. Diğer disiplinler bu alana hiç giremez; gördüğünde bile referans alamaz.

Shared — Paylaşım alanı

Disiplin kendi iç kontrolünü yapıp container'ı koordinasyon için diğer disiplinlere açar. WIP'ten Shared'a geçiş bir check / review / approve kapısından gerçekleşir; üreten disiplinin sorumlu mühendisi geometriyi, parametreleri ve uygunluğu doğrular. Shared bölgesinde container artık koordinasyon, federe model birleştirme ve clash detection için uygundur — ancak sahaya/üretime gidemez.

Published — Onaylı alan

İşveren (appointing party) tarafından sözleşmesel olarak onaylanmış container. Bu bölgedeki dosya imalat, ihale ve yapım için resmi referans olur. Shared'dan Published'a geçiş authorization kapısıyla yapılır; işverenin yetkili temsilcisi imzasıyla geçer. Bir kez Published olan container artık değiştirilemez; revizyon yeni bir container olarak yeniden döngüye girer.

Archived — Arşiv

Yaşam döngüsünü tamamlamış ya da üst sürümle yer değiştirmiş tüm container'lar arşive düşer. Silinmez, kayıt değeri taşır. "Hangi versiyona göre çalışıldı, ne zaman değişti, kim onayladı" sorularının cevabı yıllar sonra da burada bulunur.

Önemli ayrıntı: akış doğrusal değildir. Bir container WIP ile Shared arasında defalarca gidip gelebilir; tasarım koordinasyonu sırasında federe modelde çakışma çıktığında ilgili disiplin container'ı WIP'e geri alır, düzeltir, Shared'a tekrar yükler. Published bölgesine geçiş ise tek yönlüdür ve sözleşmesel ağırlık taşır.

3. SUITABILITY KODLARI HANGİ SIRAYLA İLERLER?

Container'ın hangi bölgede olduğu kadar "hangi amaçla kullanılabileceği" de tanımlı olmalıdır. ISO 19650-2'nin İngiltere ek'i (UK National Annex) suitability kodlarını detaylı tanımlar ve sektörde fiili standart hâlinde kullanılır. Bu kodlar dosya adına değil, metadata alanına yazılır; CDE platformu container'ı listede gösterirken kodu yanına eklerler.

S kodları — Work in Progress ve Shared bölgeleri için:

• S0: İlk taslak, hazırlık aşamasında; yazarın kendi alanı dışına çıkmamalıdır
• S1: Disiplinler arasında bilgi ve referans amaçlı paylaşılır; başka disiplinin koordinasyon kararlarına temel olur
• S2: Koordinasyon ve geliştirme amaçlı paylaşım; federe model bu kodlu container'lardan kurulur
• S3: Resmi onay sürecinin ilk basamağı; disiplin içi formal sign-off öncesi paylaşım
• S4: İşveren onayı öncesi yetkilendirilen ikinci onay aşaması
• S5: İşveren onayı için son sunum; Published'a geçişten hemen önce

A ve B kodları — Published bölgesi için:

• A1...A7: İşveren tarafından sözleşmesel olarak onaylı, ilgili proje aşamasına uygun. A6 tipik olarak işletmeye devir aşamasında kullanılır
• B1...B7: Yorumla onaylı; içerik kabul edilmiş ancak küçük revizyon notları eklenmiş. Sıklıkla A'ya çevrilmek üzere bekler
• CR: As-built / as-constructed kaydı; yapım sonrası gerçek durumu yansıtan container

Revizyon numarası kod ile birlikte yazılır. WIP ve Shared aşamasındaki container'lar "P" ile başlar (preliminary): P01, P02, P03. Published aşamasındaki container'lar "C" ile başlar (contractual): C01, C02. Sahada bir container'ın metadata satırı tipik olarak S2 - P03 ya da A1 - C01 şeklinde okunur. İlki "koordinasyon için paylaşılmış, üçüncü taslak revizyonu"; ikincisi "sözleşmesel olarak onaylı, ilk sözleşmesel sürüm" anlamına gelir.

4. CONTAINER NAMING VE METADATA ALANLARI

ISO 19650-2 her information container'ın belirli bir kodlama düzeniyle adlandırılmasını ister. Tipik yapı yedi alandan oluşur; alanlar tire ile ayrılır ve büyük harf kullanılır:

PROJE-ORIGINATOR-VOLUME-LEVEL-TYPE-ROLE-NUMARA

Örnek bir Türk projesi adlandırması: KMP01-MIM-01-Z0-DR-A-0014

• KMP01 projenin kısa kodu (örneğin Kemerburgaz Mahalle Projesi 01)
• MIM üreten firma ya da disiplin (mimari)
• 01 blok ya da hacim kodu
• Z0 kat seviyesi (zemin kat)
• DR container tipi (drawing); MD model, SP şartname, RP rapor
• A rol kodu (mimari); S statik, M mekanik, E elektrik
• 0014 dosya sıra numarası

Suitability kodu (S2) ve revizyon (P03) dosya adına değil; ayrı bir metadata alanına yazılır. Bu kritik bir noktadır: paylaşımlı sürücü kültüründen gelen ekipler kodu dosya adının sonuna ekleme alışkanlığını taşır; CDE platformu bunu engellemez ama metadata alanları boş kalırsa raporlama ve filtreleme çalışmaz. Metadata alanları minimum şu içeriği taşımalıdır: container unique ID, suitability, revizyon, durum (state), oluşturma tarihi, yazar, son güncelleme, sınıflandırma (Uniclass / OmniClass / sektör), bağlı olduğu görev paketi.

Türkiye'deki ofislerde sahada en sık yaşanan hata Türkçe karakter ve boşluk kullanımıdır. 1.kat-plan revize.dwg tipindeki adlandırma CDE'ye yüklenirken ya reddedilir ya da raporlamada karakter karmaşası yaratır. ASCII karakter ve tire kullanımı pratik kural olarak benimsenmelidir.

5. FEDERE MODEL VE ÇAKIŞMA TAKİBİ

CDE'nin asıl değeri Shared bölgesinde ortaya çıkar. Mimari, statik, mekanik, elektrik ve altyapı disiplinleri kendi container'larını S2 - P0x kodlarıyla Shared bölgesine yüklediğinde BIM koordinatörü bunları birleştirip federe model oluşturur. Bu modelde Navisworks, Solibri ya da BIM koordinasyon yazılımlarıyla clash detection (çakışma tespiti) çalıştırılır. Standart, çakışmaları üç kategoriye ayırır:

1. Hard clash: Fiziksel çakışma. Mekanik kanal, statik kirişin içinden geçer; kolon mimari duvarın dışına taşar
2. Soft clash: Tolerans çakışması. Kanal duvara çok yakın, bakım ve servis için yeterli boşluk yok
3. Workflow clash: Zaman ya da sıra çakışması. İmalat sırası önce yapılması gereken işi sonraki aşamaya bırakmış

İstanbul'da bir hastane projesinde tipik bir koordinasyon döngüsü şu adımlarla işler: Pazartesi her disiplin container'ını S2 - P0x kodlu olarak Shared'a yükler. Salı koordinatör federe modeli kurar, clash testi koşar, BCF (BIM Collaboration Format) dosyasıyla çakışmaları ilgili disipline atar. Çarşamba-Perşembe disiplinler WIP'te düzeltir, yeniden Shared'a yükler (revizyon P0x+1). Cuma koordinasyon toplantısı kapatılan çakışmaları gözden geçirir. Üçüncü hafta sonunda 300 hard clash, 30'a iner; sahaya çıkmadan önce sıfıra yaklaşır. Aynı koordinasyon işinin sahada çözülmesi haftalarca süre ve onlarca tonluk imalat israfı anlamına gelir.

Federe modelin tek doğru kaynaktan kurulması kritiktir. Disiplinler kendi container'larından özel formatlar (RVT, IFC, DWG) gönderir; koordinasyon ortamı çoğunlukla IFC üzerinden çalışır. IFC ISO 16739 ile standartlaşmıştır ve ISO 19650'in "tek doğru kaynak" ilkesinin teknik dayanağıdır. ISO 19650 BIM eğitimi bu disiplinin kavram setini saha pratiğine indirir; standart-bazlı eğitim CDE geçişinde direnci yarı yarıya azaltır.

6. BEP İLE EIR CDE'DE NE ROL OYNAR?

CDE'nin teknik altyapısı kadar sözleşmesel altyapısı da vardır. İki temel doküman bütün akışın yasal zeminini kurar:

EIR — Exchange Information Requirements

İşverenin BIM şartnamesidir. Hangi aşamada hangi LOD/LOI, hangi container tipleri, hangi suitability seviyesi, hangi sıklıkta teslim, hangi sınıflandırma sistemi (Uniclass, OmniClass, sektör), CDE'de hangi formatlar kabul edilir, kim hangi bölgeye yazar tüm bu kararlar EIR'da yazılır.

BEP — BIM Execution Plan

Yüklenicinin EIR'ı nasıl karşılayacağını anlatan plandır. Roller (Information Manager, Task Team Manager, BIM Coordinator), iş akışı, yazılım listesi, koordinasyon takvimi, CDE platformu seçimi, dosya adlandırma kodu, sınıflandırma haritası, riskler ve kabul kriterleri yer alır.

Türkiye'de büyük altyapı ve kamu projelerinin ihale dosyalarına EIR girmeye başladığında BEP yazma yetkinliği müteahhitler için ihale kazanma şartı hâline geldi. Küçük ölçekli projelerde 2-3 sayfalık sade BEP yeterlidir; büyük ölçekli karayolu, raylı sistem ya da hastane projesinde 40-60 sayfalık detaylı BEP'ler hazırlanır. EIR-BEP eşleşmesi tutarsız ise CDE çalışsa bile koordinasyon disiplini oturmaz; her toplantıda "bu container hangi durumda olmalıydı" tartışması yeniden açılır.

7. CDE PLATFORMU SEÇERKEN TÜRK PROJELERİ HANGİ KISITLARI YAŞAR?

Türkiye'de büyük müteahhitler bulut tabanlı CDE platformlarına yönelir; orta ve küçük ofislerde maliyet ile yetkinlik kısıtı seçimi etkiler. Platform seçiminde sektörde değerlendirilen ana eksenler:

• Lisans modeli: Kullanıcı başına aylık abonelik mi, container kapasitesi bazlı mı, proje bazlı mı; küçük ofiste kullanıcı başına model pahalıya patlar
• Yerel mevzuat uyumu: KVKK gereği proje verilerinin nerede saklandığı (Türkiye, AB, ABD veri merkezi) kamu projelerinde belirleyicidir
• KEP ve e-imza entegrasyonu: Sözleşmesel onay akışlarında KEP yoluyla teslim ve elektronik imza zorunluluğu; CDE platformunun Türkiye'deki e-imza altyapısıyla nasıl çalıştığı kritik
• Mevcut yazılım ekosistemi: Revit-ağırlıklı ofis ile Tekla-ağırlıklı çelik ofisin tercihi farklıdır; her platformun belirli yazılımlarla canlı bağlantısı (live link) güçlüdür
• BCF, IFC, Uniclass desteği: Açık standartlara native destek; ihracat-ithalat kalitesi koordinasyon hızını belirler
• Mobil saha erişimi: Saha personelinin tablet ya da telefondan Published container'a 4G ile erişebilmesi; baret altında çalışan ustanın güncel paftaya ulaşması
• Bağlantı maliyeti: Türkiye'de saha şantiyesinin internet altyapısı şehir merkezindeki ofise göre zayıf olabilir; senkronizasyon stratejisi düşünülmelidir

Spesifik platform adı önermek yerine pratik kararı şöyle özetlemek mümkün: önce EIR ve BEP'in net olduğundan emin olun, sonra ekipteki ana yazılımları belirleyin, üç farklı CDE platformuyla 2-4 haftalık pilot deneyim yapın, eş zamanlı kullanılan disiplin sayısı altıyı geçen büyük projede platformun federe model performansını test edin.

8. DENETİM İZİ VE SÖZLEŞMESEL DEĞER

Bir gün proje teslim edildikten üç yıl sonra mahkemeye gidiyorsunuz. Yapısal bir hasar inceleniyor, sebebi belirlenmek üzere; soru "hangi versiyon onaylanmıştı, kim onayladı, ne zaman, hangi container'a göre imalat yapıldı?". Paylaşımlı sürücüde bu sorunun cevabı yoktur; e-postalar dağılmış, klasör adları karışmış, üzerine yazma ile orijinal dosya kaybolmuştur. CDE'de cevap iki tıklamadadır.

Denetim izi pratikte şunları kayıt altına alır:

• Container her durumda kalış süresi (örn. WIP'te 14 gün, Shared'da 8 gün, Published'da kalıcı)
• Geçiş tetikleyen kullanıcı, tarih, saat, IP adresi
• Eklenen yorum, kabul/red kararı ve gerekçe metni
• Bağlı görev paketi (work breakdown), ihale kalemi, ödeme adımı
• Federe modelde yer alma tarihi, hangi clash raporlarının çözüm referansı olduğu
• İndirme ve görüntüleme geçmişi (kim ne zaman dosyaya baktı)

Bu kayıt yapısı sözleşme yönetimi açısından ciddi değer taşır. Hakediş hesabında "onaylı projeye göre" ifadesinin neyi referans aldığı belirsiz değildir; A1 - C01 kodlu container hangisiyse hakediş ona göre işler. Hakediş ve kesin hesap eğitimi CDE'den çıkan onaylı container ile metraj arasındaki ilişkiyi kurar; bu ilişki kurulmadığında hak ediş incelemelerinde "hangi proje" sorusu açık kalır.

KEP üzerinden teslim entegrasyonu Türkiye'ye özgü bir disiplindir. Sözleşmesel olarak işverene gönderilen bir Published container, KEP yoluyla gönderildiğinde teslim tarihi yasal olarak sabit hâle gelir. CDE platformu çıktısının ZIP'ini KEP'e bağlama, hash değerini KEP'in mesaj gövdesine yazma yaygın bir pratiktir; container'ın bütünlüğü sözleşme dosyasında kalıcı olarak kanıtlanır.

9. GEÇİŞ TAKVİMİ EKİP DİRENCİNİ NASIL AŞAR?

Türk inşaat sektöründe paylaşımlı sürücüden ISO 19650 uyumlu CDE'ye geçiş tek seferde olmaz. Tipik geçiş 4-6 ayda tamamlanır ve içinden geçen kilometre taşları bellidir:

1. Hafta 1-2: EIR ve BEP taslakları hazırlanır; ofis içinde 2-3 sayfalık "bizim BIM şartnamemiz" ile başlanır
2. Hafta 3-4: CDE platform pilotu, tek pilot proje, tek disiplin (genelde mimari); naming kodu basit tutulur, herkese tek sayfalık "cheatsheet" dağıtılır
3. Hafta 5-8: İkinci disiplin (statik) eklenir; Shared bölgesi devreye girer, federe modelin ilk denemesi yapılır. Bu hafta tipik olarak direncin en yüksek olduğu dönemdir
4. Hafta 9-12: MEP disiplinleri eklenir; haftalık koordinasyon toplantısı sabitlenir, suitability kodları gündelik dile girer
5. Hafta 13-16: İşveren onay akışı (Published bölgesi) çalıştırılır; KEP entegrasyonu kurulur, e-imza akışı ilk Published container ile test edilir
6. Hafta 17-24: Yeni projeler doğrudan CDE'de açılır; eski paylaşımlı sürücü artık sadece arşiv referansı olarak tutulur, yeni iş girmez

İlk iki haftada direnç gerçektir. "Klasörde çalışmak daha kolaydı", "her dosya için onay kim onaylayacak", "benim WIP'im var, niye paylaşmak zorundayım" gibi soruların tamamı ortaya çıkar. Üçüncü haftadan sonra ekiplerin büyük bölümü artık dosya adında üç farklı "final" kelimesi olan yapıya geri dönmeyi reddeder; çünkü tartışmaların adresi belli, kayıt var, "ben göndermiştim" gerilimi yaşanmıyor.

ISO 19650 bürokrasi getiren bir standart değildir; sözleşme, hakediş, tasarım ve şantiye arasındaki bilgi köprüsünü disipline eden bir yapıdır. Standardın özü dört bölge ve birkaç onay kapısından ibarettir; karmaşıklık standardın kendisinden değil, ekibin paylaşımlı sürücü alışkanlığını bırakma süresinden gelir. Süreyi kısaltan iki şey vardır: kavram setini doğru oturtmak ve pilot projeyi küçük tutmak.