BİM KOORDİNASYONDA REVİZYON VE DEĞİŞİKLİK YÖNETİMİ KURGULAMAK

Aynı şantiyede üç farklı paftanın dolaşması bir yönetim hatası değil, kurgu hatasıdır. Mimari ekip cuma akşamı tavan yüksekliğini 10 cm değiştirir, mekanik bunu pazartesi günü Navisworks federation üzerinde görür, yapısal disiplinin elinde hâlâ önceki hafta paylaşılan model vardır. Üç ekibin de niyeti iyidir; ama hangi sürümün geçerli olduğunu söyleyen tek bir yer yoktur. BİM koordinasyonunda revizyon ve değişiklik yönetimi tam bu boşluğu doldurmak için kurgulanır.

İşin özü model değil, modelin etrafındaki bilgi akışıdır. Akış kurgulanmazsa modelin kendisi risk üretir; revizyon numarası verilmeden yapılan her güncelleme, sahanın "hangi paftaya göre üreteyim?" sorusunu cevapsız bırakır. Bu yazıda revizyon kodlamasını, CDE durum geçişlerini, değişiklik talebi akışını ve Türk kamu projelerinde dosya isimlendirme alışkanlığını birlikte ele alıyoruz.

Revizyon Numarası, Sürüm Numarası ve Durum Kodu Aynı Şey Değildir

Yeni başlayan koordinatörlerin en sık karıştırdığı üç kavram bunlar. TS EN ISO 19650-2 ulusal eki bunları birbirinden net ayırır:

• Sürüm numarası: Yazılımın iç sayacı — Revit central'ı her açıp kapattığında artar, bilgi taşımaz.
• Revizyon kodu: Bilgi konteynerinin sözleşmesel olmayan (P01, P02…) veya sözleşmesel (C01, C02…) hangi iterasyonunda olduğu.
• Durum kodu (Suitability): O iterasyonun ne için kullanılabileceği — S0 yazımda, S2 koordinasyon için, S4 onay için, A1 sözleşmesel kabul.

Aynı dosya hem P02 hem S2 hem de Revit'in iç sayacı 73 olabilir. Üç bilgi farklı şey söyler: P02 "ikinci ön sürüm", S2 "koordinasyon için uygundur", 73 ise "yazılım buradaydı". Sahaya gönderilen pakette yalnız revizyon kodu ve durum kodu yazılır; iç sürüm sayacı asla sözleşmeye girmez.

Türk kamu projelerinde bu ayrımın olmaması en sık tartışma sebebidir. "İdareye gönderdiğimiz paftada Rev 03 yazıyordu, müteahhit Rev 05'le iş yapmış" cümlesi, durum kodu hiç değişmediğinde sözleşmesel olarak hangi paftanın geçerli olduğu sorusunu cevapsız bırakır. Çözüm: her revizyon ile birlikte durum kodu açıkça yazılır.

ISO 19650 Durum Kodları Türkiye'de Nasıl Karşılanır?

BS EN ISO 19650-2 ulusal ek A'da tanımlanan ve TS EN ISO 19650 uyarlamasında da yer alan durum kodları, modelin yaşam döngüsünde nerede olduğunu söyler. Türk müteahhitlik pratiğine oturtarak okumak gerekir:

1. S0 — İlk taslak: Yalnız yazar disiplinin görebildiği, dışarı çıkmamış sürüm. WIP klasöründe yaşar.
2. S1 — Referans paylaşımı: Diğer disiplinlerin bilgi amaçlı görmesi için. Koordinasyon kararı bağlamaz.
3. S2 — Koordinasyon için uygun: Disiplinler arası çakışma testine girer. Federation modeline bu kodla katılır.
4. S3 — Görev ekibi onayı: Disiplin sorumlusunun imzaladığı ilk gate.
5. S4 — İşveren/müşavir onayına: İdareye sunulmadan önceki son onay aşaması.
6. S6/S7 — PIM/AIM yetkilendirme: Proje bilgi modeli ya da varlık bilgi modeli olarak teslim almak için.
7. A1 — Sözleşmesel kabul: Tüm tarafların imzaladığı, uygulamaya esas paftalar. P01 → C01 geçişi burada olur.

Türk projesinde gerçek hayatta sıklıkla S2-S3-S4-A1 dörtlüsü kullanılır; S1 ve S6/S7 büyük altyapı veya kamu varlık yönetim projelerine kalır. Disiplinler arası kapsam ve sürüm disiplini açısından konuyu sıfırdan kurmak isteyen ekipler için ISO 19650 BİM eğitimi içeriğindeki gate review pratikleri Türk sözleşme diliyle eşleştirilmiş örnekler içerir.

CDE İçinde WIP, Shared, Published ve Archived Geçişleri Nasıl İşler?

Ortak veri ortamının dört durumlu kapı sistemi vardır; her kapının kimin açabileceği yazılıdır.

WIP (Work in Progress) yazar disiplinin kendine ait alanıdır. Mekanik koordinatör burada günde 30 kez kaydetse de kimse rahatsız olmaz, çünkü diğer disiplinlerin erişimi yoktur. Burada modele S0 durum kodu yapışıktır. Türk ofislerinde sık yapılan hata: WIP'i ortak ağ klasörü olarak tanımlamak ve sonra "kim üzerine yazdı?" tartışmasına girmek. WIP disiplinin tek erişim alanıdır.

Shared durumuna geçiş bir karar anıdır. Mekanik koordinatör modeli S2 koduyla shared'e attığında diğer disiplinler "artık bu sürümün üstüne çakışma testi koşabiliriz" sinyali alır. Bu aşamada model artık üzerine yazılmaz; her yeni sürüm yeni P kodu alır (P02, P03…).

Published sözleşmesel zonedir. Müşavir ve idare onayı ardından dosya A1 koduyla buraya geçer. P01 → C01 dönüşümü tam burada olur: ön sürüm karakteri silinir, sözleşmesel iterasyon başlar. Türk inşaat sözleşmesi pratiğinde bu adım çoğu zaman atlanır — "yeşil ışık aldık, devam" denip published klasör es geçilir. Sonra hak ediş itirazında "hangi paftaya göre üretildi" sorusu cevapsız kalır.

Archived superseded sürümlerin saklandığı, salt-okunur tarihçedir. Hak ediş, garanti süresi ve yargıya intikal eden uyuşmazlıklarda en sık başvurulan klasör burası olur. Türk projesinde 5+ yıl saklama zorunluluğu vardır; bulut CDE seçilirken bu kalıcılık doğrulanmalı.

Değişiklik Talebi Akışı: CR'den Onaya

Revizyon teknik bir kayıttır, değişiklik yönetimi idari bir süreçtir. Sağlıklı projede her revizyonun arkasında bir Change Request (CR) durur. Türk müteahhitlik pratiğinde buna "değişiklik talep formu" denir ve genellikle PDF olarak imzalanır; ama içerik aynı olmalı.

1. Talep açma: Disiplin sorumlusu, saha tespiti veya idare talebi ile tetikler. Gerekçe ve etkilenen modeller listelenir.
2. Etki analizi: BIM koordinatörü ilgili federation modeli üzerinde olası çakışma alanlarını işaretler. Maliyet ve takvim etkisi tahmin edilir.
3. Onay zinciri: Küçük değişiklik proje yöneticisinde, orta etki müşavirde, sözleşmesel etki idarede onaylanır.
4. Disiplin revizesi: İlgili disiplinler model güncellemesini WIP'te yapar, sonra S2 ile shared'e taşır.
5. Yeniden çakışma testi: Navisworks veya Revizto üzerinde clash detection tekrar koşar.
6. Paket yayını: Revize edilmiş dosya yeni P/C kodu ile published'a alınır.
7. Paydaş bildirimi: CDE platformu (Autodesk Construction Cloud, Trimble Connect, Aconex, BIMcollab) ilgili paydaşlara otomatik bildirim yollar; e-posta ekine PDF transmittal eklenir.

Bu zincirde en sık atlanan halka yedinci adımdır. Modelin değiştiği bildirilmezse saha mühendisi haftalarca eski paftayla iş üretir; sonradan "haberim yoktu" itirazı sözleşmesel boşluğa dönüşür. Otomatik bildirim kuralı CDE platformuna açıkça yazılmalı: "S2 üstü her durum geçişi tüm task team koordinatörlerine push edilir."

Revizyon Bulutu Sahada Hangi İzi Bırakır?

Pafta üzerindeki revizyon bulutu (revision cloud) görünüşte küçük bir grafik elemandır; sahada ise revizyonun ne olduğunu söyleyen tek görsel iz olabilir. Türk projelerinde mavi kalemle elle çizilmiş bulutlar hâlâ kullanılır; BİM ortamında ise Revit içindeki Revision Cloud aracı pafta üstünde otomatik üçgen revizyon tag'i üretir.

İyi bir revizyon bulutu pratiği:

• Her bulutun yanında üçgen içinde revizyon numarası bulunur (Rev 03, Rev 04…).
• Pafta başlığındaki revizyon tablosunda her bulutun gerekçesi yazılır (tarih, sebep, onay).
• Önceki revizyon bulutu kapatıldığında tag'i silinmez, "kapatıldı" işaretiyle dondurulur. Sahada hangi notun hangi revizyona ait olduğu okunur.
• Pafta paketi PDF olarak çıkarılırken revizyon tablosu ilk sayfaya konur, hak ediş ekine de eklenir.

Görünür iz, BIM'in soyut "model" kavramını sahanın anladığı dile çeviren köprüdür. Koordinatörün bulutu doğru yere koyma alışkanlığı yoksa modeldeki bilgi sahaya ulaşmaz.

Disiplinler Arası Sürüm Senkronizasyonu

Federation modeli farklı disiplinlerin shared sürümlerini birleştirerek tek görsel üretir. Senkronizasyon kuralı burada belirleyicidir.

Pratikte üç senkronizasyon ritmi kullanılır:

1. Haftalık koordinasyon (varsayılan): Her cuma 16:00'da disiplinler shared'e P kodlu güncel sürümlerini yükler. Pazartesi sabahı federation toplantısı.
2. Olay-tetiklemeli senkron: Onaylı CR sonrası ilgili disiplinler 48 saat içinde günceller, koordinatör clash testini tetikler.
3. Gate review öncesi tam senkron: İdareye S4 paketi gitmeden 5 iş günü önce tüm disiplinler "soğuk dondurma" yapar; o pencerede WIP değişmez.

Türk kamu projesinde takvimle birlikte ihale sözleşmesine bağlanan ek hesap dosyaları (hak ediş, kesin kabul, yapı denetim raporları) bu senkron noktaları üzerinden üretilir. Senkron yapılmadıysa hak ediş kesilmez. Bu yüzden senkron tarihleri proje takviminde milestone olarak işaretlenir.

Türk Müteahhitlik Pratiğinde Hangi Tuzaklar Sık Görülür?

Standart yerinde olsa bile saha alışkanlıkları kurguyu erozyona uğratır. Sık görülenler:

• "Hızlıca düzelt" reflexi: Saha telefonla arar, koordinatör modeli WIP dışında düzeltir, idari iz kalmaz. Kural: her değişiklik CR ile başlar, telefon görüşmesi CR'ye not olarak eklenir.
• İdare onayı sözle alındı varsayımı: Müşavir toplantıda "tamam" demiş olabilir; A1 kodu için yazılı imza şart. Yazılı olmayan onay sözleşmesel değil.
• Klasör yapısının disipline değil zamana göre kurulması: "2026-04 paketi" gibi klasörler hangi disiplinin neyi gönderdiğini gizler. ISO 19650'nin önerisi: disiplin → durum → revizyon hiyerarşisi.
• Archive'in göz ardı edilmesi: Superseded sürümler silinir, sonradan sözleşmesel uyuşmazlıkta delil kaybolur.
• Tek paftada birden çok revizyon bulutu birikmesi: Pafta okunamaz hâle gelir, üçüncü revizyondan sonra eskiyi kapatıp pafta numarasını artırmak iyi pratiktir.

Koordinatörün asıl işi yazılım kullanmak değil bu tuzakları öngörüp prosedürle önlemektir. BİM koordinasyon eğitimi programları içinde gate review ve CR akışı pratik vakalarla işlenir; ekip içi terim birliği bu eğitimlerin asıl çıktısıdır.

Dosya İsimlendirme Şeması ve Transmittal

ISO 19650 ulusal ek A önerdiği isimlendirme şeması Türk projesine birebir oturur: PROJE-YAZAR-LOKASYON-KAT-TIP-DISIPLIN-NUM-DURUM-REV. Örnek: ANK01-XYZ-Z01-K03-MOD-M-001-S2-P03 — Ankara projesi 01, yazar XYZ ofisi, zon 01, kat 03, model dosyası, mekanik disiplini, sıra 001, koordinasyon için uygun, üçüncü ön sürüm.

Transmittal ise paketin teslim belgesidir. İyi bir transmittal şunları taşır:

• Gönderen ve alıcı disiplin/firma.
• Paketteki tüm dosyaların listesi, her birinin durum ve revizyon kodu.
• Önceki revizyondan farkın özeti (1-2 satır).
• Beklenen aksiyon (incelemek, onaylamak, koordinasyon testine almak).
• Yanıt süresi (örn. 5 iş günü).

Transmittal kâğıt değil ama dijital bir kayıt olarak korunmalı. CDE platformları otomatik üretir; küçük ofislerde PDF + e-posta da iş görür, yeter ki audit log içinde saklansın.

Kurguyu Yaşatan Görünmez Ritim

Teknik kısım anlatılınca iş bitmiş gibi görünür; ama gerçek kurgu rutin alışkanlıklarla ayakta kalır. Her cuma shared klasör temizliği, her CR sonrası bildirim doğrulaması, her gate review öncesi tam senkron — bu ritimler olmadan en iyi şablon iki ayda dağılır. BİM koordinatörünün asıl işi yazılım kullanmak değil, ekibin bu ritmi unutmamasını sağlamaktır. Modelin değerini koruyan teknoloji değil, koordinatörün haftalık disiplinidir.