BIM koordinasyon toplantısı: hazırlık, yürütme ve takip

Toplantı neyi karara bağlar?

Koordinasyon toplantısı, ayrı disiplinlerin ürettiği modellerin birbirine uyup uymadığını konuşmak için yapılır. Ancak asıl iş çakışmayı göstermek değil, bir çözüm kararı çıkarmaktır: hangi disiplin hangi elemanı, ne zamana kadar değiştirecek? Toplantıdan 'şurada çakışma var' bilgisiyle çıkılırsa bir sonraki turda aynı çakışma yine karşımıza gelir.

Bu yüzden toplantı tek başına bir olay olarak değil, bir döngünün halkası olarak planlanır. Çakışma testinin nasıl kurulacağı ve raporlanacağı Navisworks çakışma kontrolü sayfasında, çakışma kavramının tanımı ise sözlükte anlatılır. Buradaki konu, o raporun toplantıda nasıl kullanılacağıdır.

Toplantıdan önce: hazırlık listesi

Toplantının kalitesi, başlamadan belirlenir. Koordinatör şu işleri tamamlamış olmalıdır. • Katılımcılara model yayın tarihi önceden bildirilmiş ve herkes güncel modelini yayınlamış olmalı. Bir disiplin eski modelle gelirse test sonuçları geçersizdir. • Modellerin aynı konumlandırmada olduğu doğrulanmış olmalı. Konum farkı sahte çakışma üretir; bu konu Revit paylaşılan koordinatlar sayfasında anlatılır. • Çakışma testi çalıştırılmış, sonuçlar gruplanmış ve tekrar eden benzerler tek başlık altında toplanmış olmalı. Ham maddelerin tamamı değil, anlamlı başlıklar sunulmalı. • Her başlık için ekran görüntüsü ya da model görünümü ve yeri tanımlayan bilgi (bina, kat, aks, mahal) hazırlanmış olmalı. • Önceki toplantıdan açık kalan maddelerin durumu güncellenmiş olmalı.

Katılımcı listesi de hazırlığın parçasıdır. Her disiplinin kararı verebilecek kişisi toplantıda bulunmalıdır; yalnız bilgi alıp dönen katılımcı, bir sonraki turda kararın eksik kalmasına yol açar.

Toplantı sırasında: gündem sırası ve karar disiplini

İyi bir toplantı, sorunları etkisine göre sıralar. Yapısal bir elemanla tesisatın çakıştığı, imalatı durduracak bir sorun, bir elemanın birkaç santimlik sapmasından önce görüşülür. Düşük etkili maddeler toplantı dışında ilgili disiplinler arasında çözülebilir.

Her madde için aynı sorular sorulur ve yanıtlar kayda geçer. • Sorun gerçek mi? Bazen model hazırlığındaki bir eksik ya da konum farkı sahte çakışma yaratır. • Çözümü kim yapacak? Genellikle esnek olan taraf değişir; sert elemanlar, yani yapısal ve büyük taşıyıcı sistemler genelde yerinde kalır. • Çözümün başka sistemlere etkisi var mı? Kanalı kaydırmak başka bir hatla çakışma doğurabilir. • Ne zamana kadar? Yanıt tarihi, bir sonraki model yayını ile uyumlu olmalı.

Koordinatör toplantıyı yönetir ama çözümü dayatmaz; tasarım kararı disiplin sahibinindir. Tartışma uzarsa madde 'açık' olarak işaretlenir ve ilgili tarafların toplantı sonrasında görüşmesi istenir.

Toplantı ister salonda ister çevrim içi yapılsın, ekranda herkesin aynı model görünümünü izlemesi gerekir. Görünümlerin önceden kaydedilmesi, toplantıda zaman kaybettirmeden her başlığa gitmeyi sağlar. Karar notları toplantı sırasında tutulur ve sonunda katılımcılarla kısaca okunur; böylece sorumlu ve tarih konusunda yanlış anlama kalmaz.

Toplantıdan sonra: atama, takip ve kapanış

Toplantı bittiğinde yazılı çıktı hazır olmalıdır: karar, sorumlu, beklenen tarih. Sorunlar bir sorun takip aracında ya da ortak veri ortamında tutulur; bu işte Autodesk Construction Cloud kullanımı gibi araçlar ve BCF biçimi, sorunun yazılımlar arasında taşınmasına yardım eder.

Takip şu kurallarla işler. • Sorumlu, kendi modelinde düzeltmeyi yapar ve sorun kaydına notunu düşer. • Koordinatör, bir sonraki testten önce düzeltilmiş modellerin yayınlanmasını bekler. • Kapanış kararı, yeni test sonucuna bakılarak verilir; sorumlunun beyanı yetmez. • Aynı sorun tekrar ortaya çıkarsa kayıt yeniden açılır, yeni kayıt değil. Böylece sorunun tarihçesi okunur.

Takip listesi, bir sonraki toplantının gündem iskeletini de oluşturur. Açık maddeler önce görüşülür, yeni maddeler sonra eklenir.

Toplantı sonrası bildirim de gecikmemelidir: kararlar ve atamalar aynı gün içinde katılımcılara iletilirse sorumlular bir sonraki yayın tarihini gerçekçi planlayabilir.

Örnek: otel projesinde tavan arası koordinasyonu

Kurgusal bir otel projesinin tavan arasında havalandırma kanalı, yangın borusu ve kablo tavası birlikte geçiyor. Koordinatör, toplantı öncesinde testi çalıştırır ve çok sayıda ham çakışmayı kat ve geçiş bölgesine göre gruplar; her grup bir başlık olur.

Toplantıda ilk başlık koridor kavşağıdır: kanal, kirişin altında yeterli yüksekliği bırakmıyor. Statik ofis kirişin değişemeyeceğini söyler. Tesisat ofisi kanalı yassı bir kesite çevirmeyi önerir. Havalandırma sorumlusu bunun hava debisine etkisini kontrol edip yanıtlayacaktır. Karar kaydı: sorumlu tesisat ofisi, yanıt bir sonraki model yayınına kadar.

Bir sonraki toplantıda koordinatör, değişen kanalı birleştirip testi yeniden çalıştırır. Çakışma kaybolmuş ama kablo tavasıyla yeni bir çakışma doğmuştur. Kayıt, ilk sorunun yan etkisi olarak işlenir. Bu örnekte kapanışı test doğrulamış, yan etkiyi de döngü yakalamıştır.

Sık yapılan hatalar

Toplantı iyi niyetle başlasa da bazı kalıplar onu verimsiz kılar. Her birinin düzeltmesi basittir. • Ham çakışma listesini ekranda okumak yerine gruplanmış ve etkisine göre sıralı başlıkları görüşün. • Karar vermeyecek kişilerle toplanmak yerine her disiplinin karar sahibini davet edin. • Sorumlusu ve tarihi olmayan madde bırakmak yerine her maddeye sorumluyu ve tarihi yazın. • Kapanışı sorumlunun beyanıyla kabul etmek yerine yeni test sonucuyla doğrulayın.

Bir de sürece dair hata vardır: toplantı yapıldığı için işin yapıldığını sanmak. Toplantının ürünü, güncellenen modeller ve kapanan kayıtlardır; toplantı kendisi ürün değildir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Navisworks ile Çakışma Tespiti ve Model Koordinasyonu programının sonuç yönetimi ve koordinasyon toplantısı yönetimi modülleri, burada anlatılan sürecin uygulamasını işler.

BIM ve Autodesk Revit Uzmanlaşma Eğitimi'ndeki BIM koordinasyonu modülü ise Revit tarafındaki hazırlık ve çakışma tespiti için tamamlayıcıdır. BIM koordinatörleri ve disiplin sorumluları için uygundur.