BİM KOORDİNASYONDA DİSİPLİNLER ARASI MODEL CHECKLİSTİ OLUŞTURMAK

Disiplinler arası model checklisti, mimari, statik ve MEP modellerini tek federe modelde sorunsuz buluşturmak için her hafta aynı sırayla tekrarlanan kontrol listesidir. Bu sayfa koordinat datumu ve kot referansının kararlaştırılmasından naming convention'a, LOD-LOI eşleşmesinden IFC export ayarlarına, dosya boyutu sınırından çakışma sınıflandırması ve BCF akışına, ortak veri ortamı klasörlerinden toplantı öncesi hazırlığa kadar somut maddeleri sıralıyor. Aşağıdaki akış büyük müteahhitlik şantiyelerinde rafine edilmiş, TS EN ISO 19650 çerçevesini uygulanabilir adımlara dönüştüren bir checklisttir.

1. Koordinat Datumu Nasıl Kararlaştırılır?

Checklist'in birinci satırı her zaman koordinatla başlar. Sebep basit: mimar parsel köşesini sıfır kabul etmiş, statikçi binayı kendi koordinat sistemine yerleştirmiş, mekanikçi şehir grid'inden başlamış. Federe modelde her şey 47 metre öteye düşer, kimse nedenini ilk bakışta anlayamaz.

Proje açılış toplantısında üç nokta yazılı tutanağa bağlanır:

• Project Base Point: Binanın yerel sıfırı; çoğunlukla yapı kenarındaki kolon aksı kesişimi.
• Survey Point: Coğrafi sıfır; harita koordinatına (ITRF veya yerel grid) bağlanan referans.
• Shared Coordinates: Disiplinler arası taşınan koordinat sistemi. Bir kez paylaşılır, sonra her disiplin kendi modelinde bu noktayı hizalar.

Kot referansı için tek bir kural: ±0.00 zemin kat bitmiş döşeme üstü kabul edilir, deniz seviyesinden yüksekliği (örn. +874.20) tutanakta yazılır. Yapısal modelde bina kotu kaba beton üstü, mimari modelde bitmiş döşeme üstü değişebileceği için her disiplin kendi referansını mutlak kota çevirip raporlar. Türk kamu projelerinde KGM ve yapı işleri ihalelerinde bu netlik genellikle BEP'in (BIM Execution Plan) ilk ekinde matris olarak istenir.

2. Naming Convention Neden Kritik?

İkinci kontrol noktası dosya adlandırma. Beş disiplin, üç sürüm, iki revizyon — disiplinli bir adlandırma olmadan klasör bir hafta sonra geri-okunamaz. TS EN ISO 19650-2 dosya isminde yedi alan önerir; pratikte çoğu Türk projesi bunu kısaltıp dört-beş alanla çalışır:

Sonuç: ANK-MTH-23_MIM_B01_UP_R02.ifc. Türkçe karakter, boşluk, parantez yasak — bazı CDE platformları bu karakterleri sessizce dönüştürür ve link kırılır. Naming convention'ın denetimi insan eline bırakılmaz; CDE'ye yüklenirken regex kontrolü çalıştırılır.

3. LOD ve LOI Eşleşmesi

LOD (Level of Development) geometriyi, LOI (Level of Information) veriyi tanımlar. İkisi farklı eksendir; bir kolon LOD 350 geometriye sahip ama LOI 200 veriye sahip olabilir — montaj sertifikası, üretici bilgisi yoksa.

Checklist'e yedirilen sade matris şudur:

1. LOD 200: Ön tasarım; jenerik elemanlar, doğru yer, yaklaşık boyut.
2. LOD 300: Uygulama projesi; doğru geometri ve konum, üretici-bağımsız.
3. LOD 350: Disiplinler arası koordinasyon seviyesi; bağlantı detayları içerir, kavşak çakışmaları burada çözülür.
4. LOD 400: İmalat-hazır; çelik atölyesine giden kolon LOD 400 olmadan shop drawing çıkmaz.
5. LOD 500: As-built; saha doğrulamasıyla güncellenmiş model.

Checklist'in kritik sorusu: "Bu çakışma hangi LOD'da bulundu?" LOD 200 modelde jenerik bir kanal ile LOD 350 yapısal kirişin çakışması anlamsızdır; kanal henüz son boyutunu almamıştır. Yanlış aşamada erken çakışma avı ekibi boğar, kararlar geri alınmak zorunda kalır.

4. IFC Export Ayarları Hangi Hatayı Önler?

Disiplinler farklı yazılımlar kullandığında ortak dil IFC olur. Mimari Revit, statikçi Tekla Structures, mekanikçi farklı bir paket — üçü de IFC üretir. buildingSMART tarafından geliştirilen format, yazılım-bağımsız veri alışverişi için ISO 16739 standardına bağlıdır; format detaylarına ilişkin teknik referans proje başında ortak dile gelinmesi için faydalıdır.

Export ayarında üç başlık checklist'in en sık ihlal edilen kısmıdır:

• IFC sürümü: IFC2x3 (Coordination View 2.0) hâlâ yaygın; IFC4 (Reference View) zenginlik sunar ama bazı eski yazılımlar tam okuyamaz. Proje başında tek sürüm kararlaştırılır, sözleşmeye yazılır.
• MVD (Model View Definition): Coordination View koordinasyon için, Reference View clash için, Design Transfer View geometri taşıma için optimize. Yanlış MVD seçimi yarısı kayıp dosya üretir.
• Property Set haritalama: Revit'te "Generic Model" olarak modellenmiş kanal IFC'ye IfcBuildingElementProxy olarak gider; karşı yazılım onu kanal olarak filtreleyemez. Element kategorisi açıkça eşlenir.

Her export sonrası beş dakikalık doğrulama: dosya boyutu mantıklı mı (genelde 50-300 MB bandı; 2 GB'a vuran model bir yerlerde hata var), eleman sayısı son haftaya göre %5'ten fazla sapma yapmış mı, koordinat doğru noktada mı, kategori map'leri tutuyor mu. Bu kontrol manuel yapılırsa unutulur — Solibri veya BIMcollab Zoom ruleset olarak kaydedilir.

5. Dosya Boyutu Sınırı

Pratik bir checklist maddesi: tek bir IFC dosyası 500 MB'ı geçmesin. Sebep teknik değil iş akışı: 1.2 GB IFC açılması 8 dakika sürer, koordinatörün toplantı öncesi rutin kontrolünü çığırından çıkarır. Büyük projelerde dosya bloka göre bölünür — A blok mimari, B blok mimari ayrı IFC'ler; federe model üst seviyede birleştirir.

Boyut şişiren tipik nedenler ve müdahale:

• Detaysız aile şişkinliği: Mobilya, mutfak ekipmanı 3D NURBS yüzeyle modellenmişse IFC'ye taşınırken mesh patlar. Genel detay bloklar Generic Model + ölçü etiketiyle yeterli.
• Gereksiz alt sınıf: Vida, somun, ankraj çubuğu LOD 350'de modele girmez — montaj sırasında üretici dokümantasyonu yeterlidir.
• Çift CAD link: Eski 2D çizimler model dosyasına gömülü olarak takılı kalır; ihtiyaç yoksa kaldırılır.
• Render-amaçlı malzeme detayı: 4K texture, prosedürel ahşap deseni; sunum modeline kalır, koordinasyon modelinde yer almaz.

6. Çakışma Sınıflandırması ve BCF Akışı

Federe model Navisworks, Solibri veya BIMcollab Zoom üzerinde clash detective çalıştırılır. Çıktıyı tek bir 800 satırlık listeye dökmek anlamsızdır; ekip onu okumaz. Üç sınıfa ayrılır:

1. Sert çakışma (hard clash): İki katı eleman fiziksel iç içe — kiriş içinden geçen kanal, perde içinden geçen kolon. Tolerans 10-25 mm; altı modelleme gürültüsü.
2. Yumuşak çakışma (soft clash / clearance): Tolerans ihlali — vana etrafı 300 mm, yangın kapağı önü 600 mm, kablo tavası bakım kanalı 200 mm. Eleman tipine göre matris.
3. İş sırası çakışması (4D clash): Zaman ekseninde çakışma — vinç montajı sırasında dökülmemiş döşeme, geçici iskelenin kalıcı çelik ile karşılaşması.

Tespit edilen çakışmalar BCF (BIM Collaboration Format) paketinde taşınır: ekran görüntüsü, kamera açısı, ilgili elemanların GUID'leri, atanan kişi, durum (Open / In Progress / Resolved / Closed). Revizto, BIMcollab veya Trimble Connect üzerinden disiplin sahibine atanır. Kapanan BCF federe modelde bizzat doğrulanmadan "Closed" işaretlenmez; aksi takdirde aynı çakışma bir sonraki sürümde yeniden açılır ve disiplinler birbirini suçlar.

Karmaşık projelerde toplam BCF sayısının haftalık düşüş eğrisi koordinasyon sağlığının en sade göstergesidir. Disiplinler arası model kontrolünü yapılandırılmış akışla işletmek isteyen ofislerin başvurduğu BIM koordinasyon eğitimi bu pratiği proje başından sona oturtur.

7. Ortak Veri Ortamı ve Durum Klasörleri

TS EN ISO 19650-1 standardı CDE'yi (Common Data Environment) projenin tek doğru kaynağı olarak tanımlar. Pratikte ACC, Trimble Connect, Bentley ProjectWise veya açık kaynak çözümler bu işi görür. Dört durum klasörü checklist için kritiktir:

• WIP (Work in Progress): Disiplinin kendi içinde çalıştığı taslak; sadece o disiplin erişir.
• Shared: Diğer disiplinlerle koordinasyon için paylaşılan, onaylı taslak; tüm proje ekibi okuyabilir.
• Published: İşveren onayından geçmiş resmi sürüm; saha, kontrol, ihale buradan çeker.
• Archived: Süresi geçmiş veya üst sürümle değiştirilmiş; geriye dönük inceleme için tutulur.

Federe model her zaman Shared katmandan kurulur. WIP dosyayı federe etmek toplantıyı havada bırakır; karşı disiplin yarın değişeceğini bilemediği bir hata için saatlerce revizyon yapar. Türk yapım sektöründe sık görülen bir hata: e-posta ile gönderilen "son IFC" Shared'a yüklenmeden federe edilir, üç gün sonra revize sürüm geldiğinde hangi çakışmanın hâlâ geçerli olduğu kaybedilir.

8. Toplantı Öncesi Ne Hazırlanmalı?

Koordinatörün her hafta tekrarladığı somut adımlar bir A4 sayfa olarak duvara asılır:

• Shared klasörden tüm disiplinlerin güncel IFC'leri çekildi mi (tarih damgası kontrol)?
• Federe modelde her disiplinin eleman sayısı son haftaya göre mantıklı mı?
• Project Base Point hizalama doğrulandı mı (referans nokta üzerinde 0,0,0 testi)?
• Clash Detective ruleset güncel mi (yeni disiplin eklendiyse matris büyüdü mü)?
• Sert / yumuşak / 4D çakışma raporları ayrı export edildi mi?
• Geçen toplantıda Resolved işaretlenen BCF'ler bu sürümde gerçekten kapandı mı?
• Gündeme alınmayacak gürültü çakışmalar gruplandı mı (mimari rüsus < 5 cm)?
• Kritik öncelikli 10-15 madde belirlendi mi (toplantı 800 maddeyle açılmasın)?

Bu liste duvara asılınca hafif görünür; uygulanmadığında ise her toplantı kendini tekrar eder. Checklist'in büyüsü değişmesinde değil, değişmeden tekrar edilebilmesindedir. Üç ay sonra clash sayısı grafikte gerçekten düşer; saha günü kanal yeri kaymış olarak değil, planlandığı yerde döküme girer.