ISO 19650'DE BEP YAPISI VE DÖKÜMAN HİYERARŞİSİ KURMAK

Bir şehir hastanesi projesinin koordinasyon toplantısında durum şuydu: mimari ofis IFC4 üzerinden çalışıyor, statik proje firması hâlâ IFC2x3 export ediyor, mekanik tasarımcı Naviswork tarafında federated model kuramıyor çünkü iki disiplinin proje sıfır noktası 47 metre kaymış. İdarenin BIM şartnamesi vardı, yüklenicinin de güzel görünen bir BEP belgesi vardı — ama belgede "ortak koordinat sistemi" tek cümleydi, sayısal bir referans yoktu. İki ay sonra revizyon yığını içeriden patladı.

ISO 19650'nin BEP (BIM Execution Plan) bölümü tam bu boşluğu kapatmak için var. Soyut prensip değil, "hangi taraf neyi hangi formatta hangi koordinat datumunda hangi tarihte üretecek" sorusuna belge düzeyinde cevap. Belge iyiyse proje yarısında ekipler hâlâ ona bakar; kötüyse ihale dosyasında bir kağıt olarak kalır.

BEP'i tetikleyen üst zincir nedir?

BEP'i kuran kişi önce yukarısını anlamak zorunda. Standart, bilgi akışını dört kademeli bir gereksinim ailesinden başlatır: OIR → AIR → PIR → EIR. Bu sıra bürokratik değil, mantıksal. Üst katman boşsa alttakini doldurmak tahmine kalır.

• OIR (Organizational Information Requirements): İşveren kurumun varlık portföyünü yönetmek için ne tür bilgiye ihtiyaç duyduğu. Üniversite kampüsü işleten bir vakıf veya şehir hastanelerini denetleyen kamu kurumu için kurumsal seviyede tanımlanır.
• AIR (Asset Information Requirements): Belirli bir varlığın işletme süresince ihtiyaç duyacağı veri. Bakım hangi sıklıkta yapılacak, enerji izleme hangi kalemlerden okunacak, kira sözleşmesi hangi alan verilerine bakacak.
• PIR (Project Information Requirements): Tasarım ve yapım sürecindeki kilometre taşlarında hangi bilginin masaya gelmesi gerektiği. Konsept onayı, ruhsat dosyası, ihale dokümanı gibi karar noktalarına bağlıdır.
• EIR (Exchange Information Requirements): Yukarıdaki üç katmanın somutlanmış teknik şartnamesi. Yüklenicinin ihalede karşılaştığı, "hangi disiplin, hangi aşamada, hangi formatta, hangi sınıflandırma ile teslim edecek" sorularına cevap veren doküman.

BEP işte bu EIR'e karşı yazılan uygulama planıdır. Eksik bir EIR ile yola çıkıldığında BEP varsayım üstüne kurulur, sonra teslimde format kavgası çıkar. Türkiye'de TS EN ISO 19650 olarak uyarlanan standardı bütüncül bir bağlamda görmek isteyenler için ISO 19650 BIM eğitimi kavramları sıralı şekilde derler.

Pre-appointment ile post-appointment BEP farkı nedir?

Standardın 19650-2 bölümü BEP'i iki aşamada tarif eder. İlki teklif aşamasında hazırlanır; aday yüklenicinin "eğer iş bana verilirse şöyle yöneteceğim" dediği niyet belgesidir. İkinci versiyon ise sözleşme imzalandıktan sonra detaylandırılır; canlı dokümandır, proje boyunca güncellenir.

Pre-appointment BEP'te olması beklenen ana başlıklar:

1. Önerilen bilgi yönetim ekibi ve yetkinlik kanıtları
2. Mevcut yazılım, donanım ve IT altyapısı kapasitesi
3. Önerilen üretim yöntemleri ve önceki proje referansları
4. Risk değerlendirmesi ve mitigasyon yaklaşımı
5. EIR'e karşı yorum ve varsayım listesi

Post-appointment BEP'te bunlara şu eklenir: gerçek MIDP zaman çizelgesi, görev bazlı TIDP'ler, CDE iş akış kuralları, kabul kriterleri, doküman adlandırma protokolü, koordinat sistemi tanımı, federated model birleştirme kadansı, denetim ve onay matriksi. Türk kamu projelerinde gözlemlenen yaygın hata: pre-appointment BEP'i ihalede teslim eden firma sözleşme sonrası post-appointment BEP'i hiç güncellemez. Aynı doküman 18 ay rafta bekler, gerçek uygulama paralel akar.

MIDP ve TIDP: BEP'in zaman boyutu

BEP statik bir belge gibi okunmamalı. Asıl güç, zamansal türevlerinde — Master Information Delivery Plan ve Task Information Delivery Plan'larda — gizli. MIDP, projenin tüm bilgi teslimlerini tek bir tablo halinde gösterir; her satır bir teslim kalemini, hangi disiplin tarafından, hangi tarihte, hangi LOIN seviyesinde geleceğini tutar.

MIDP genel; TIDP disipline iner. Mimari ofisin TIDP'si farklı, statik mühendislik bürosunun TIDP'si farklıdır. Her TIDP, MIDP'ye bağlı bir alt çizelge gibi çalışır. İstanbul'daki büyük altyapı projelerinde gözlemlenen pratik: TIDP'ler haftalık koordinasyon toplantısında masada açık duruyorsa proje sağlıklı; klasörde unutulduysa sözleşme eki olarak kalmış, gerçek hayatı yönetmiyordur.

Bir MIDP satırı tipik olarak şu alanları taşır:

• Teslim kalem kimliği (ID kodu)
• Sorumlu disiplin / task team
• Bilgi içeriği (model, çizim, doküman, hesap)
• Hedef LOIN seviyesi
• Format (IFC, RVT, PDF, Excel vb.)
• Planlanmış teslim tarihi
• CDE statüsü (WIP, Shared, Published, Archived)
• Onay sorumlusu

LOIN neden detay seviyesinin yeni adı oldu?

Eski PAS 1192 dünyasında LOD (Level of Definition) ve LOI (Level of Information) ayrı yürürdü. ISO 19650 ailesi bunları LOIN (Level of Information Need) kavramı altında birleştirdi. EN 17412-1 tarafından detaylandırılan LOIN, bir bilgi taşıyıcısının (örneğin bir kolon nesnesinin) üç boyutta tanımlanmasını ister: geometri, alfanümerik veri ve dokümantasyon.

Pratikte tek bir kolon için LOIN şöyle çözümlenir:

1. Geometri: Hangi netlikte? Sembolik (kütle), simgesel (kuvvet hattı), genel boyut, üretim seviyesi detay?
2. Alfanümerik bilgi: Hangi parametreler dolu olmak zorunda? Beton sınıfı, yangın direnci, çelik kalitesi, malzeme menşei?
3. Dokümantasyon: Hangi ek dosya bağlı? Üretici sertifikası, test raporu, montaj kılavuzu?

Bu üç eksen ayrı ayrı seviyelendiğinde "LOD 350" gibi tek skaler bir etiket yetersiz kalır. Türk büyük müteahhitlik firmalarının BIM dönüşümünde gözlemlenen kafa karışıklığı buradan gelir: birinci sözleşmede LOD 300 yazıyor, ikincide LOIN matriksi geliyor. İkisi aynı dilin farklı sürümleri ama eşleştirme çalışması yapılmazsa ekipler iki ayrı diyalekte çalışır.

CDE statüleri ve denetim zinciri

Common Data Environment, dosya paylaşım klasörü değildir — denetlenebilir bir bilgi deposudur. Standart dört temel statü tanımlar:

• Work in Progress (WIP): Disiplin içi üretim alanı. Sadece üreten task team görür. Buradaki dosyalar resmi referans değildir.
• Shared: Diğer disiplinlerle koordinasyon için açılan, henüz işverenden onay almamış sürüm. Çakışma kontrolü burada yapılır.
• Published: İşveren onayından geçmiş, sözleşmeye dayanak teşkil eden resmi sürüm. Saha bunu kullanır.
• Archived: Süresi geçmiş ama izlenebilirlik için saklanan eski sürümler. Dava ve denetim için kritik.

Saha gerçekliği şu: ekipler genelde WIP'e her şeyi atar, Shared'i atlar, Published'a doğrudan yükler. Bu durumda denetim zinciri kopar; bir hata ortaya çıktığında "onaylı olan hangiydi" sorusuna cevap kalmaz. İyi yazılmış BEP, her geçiş için tetikleyiciyi (kim yüklüyor, kim onaylıyor, hangi durumda red dönüyor) açıkça tanımlar.

Common Data Environment için pahalı yazılım şart değil. CDE bir prensiptir, ürün değil. Küçük ölçekli bir mimari ofiste SharePoint veya Google Drive üzerinde statü disipliniyle CDE yürür. Yüksek hacimli projelerde BIM 360, Trimble Connect, Bentley ProjectWise gibi araçlar otomatik denetim izi sunar. Bu altyapıyı ekip iş akışına bağlamak için BIM koordinasyon eğitimi rolden role değişen sorumluluk dağılımını netleştirir.

Doküman adlandırma protokolü nasıl kurulur?

BEP'in en sık ihmal edilen ama en yüksek geri dönüş veren bölümü dosya adlandırma kuralıdır. Standart, "Proje-Yüklenici-İşlev-Bölge-Kat-Disiplin-Tip-Sıra" yapısında sekiz alanlı bir kod önerir. Tek bir dosya adından elemanın hangi projeye, hangi katın hangi disiplinine ait olduğu okunabilmeli.

Örnek bir kod ve okunuşu:

SH001-MIM-ZN02-K05-MIM-DRG-0120

Bu kodu okumak: Şehir Hastanesi 001 / Mimari yüklenici / Zon 02 / Kat 05 / Mimari disiplin / Drawing tipi / Sıra 0120. Sekiz alan fazla görünür ama her alan bir filtreleme yeteneğidir. 50.000 dosyalı bir CDE'de belirli bir katın belirli bir disiplinine ait son revizyonu bulmak saniyeler içinde olur. Az alanlı sistemde aynı arama yarım saat sürer.

Türkiye'de gözlemlenen pratik tuzak: ekipler kendi kısa kodlarını uydurur, BEP'teki resmi yapı ile saha uygulaması ayrılır. Bir saha mühendisi K05-MEK-SON.dwg diye saklarken merkez ofis sekiz alanlı kod bekler. İki ayrı taksonomi paralel akar, koordinatör arada tercüman gibi çalışır.

IFC export ve koordinat datumu

BEP'te netleştirilmesi gereken en teknik bölüm IFC aktarım protokolüdür. Industry Foundation Classes formatı yazılım-bağımsız BIM standardıdır — teoride. Pratikte her export'ta veri kaybı veya bozulma riski sürer. BEP'te aşağıdaki kararlar yazılmamışsa her firma kendi varsayımıyla export eder:

• IFC sürümü: IFC4 zengin veri taşır ama bazı yazılımların eski sürümlerinde okuma sorunları çıkar. Tüm taraflar son sürüm yazılım kullanıyorsa IFC4; karma ekipte en zayıf halka hangisini stabil destekliyorsa o sürüm.
• MVD (Model View Definition): Coordination View 2.0 mı, Reference View mı, Design Transfer View mı? Yanlış MVD seçimi geometri ve property kaybı demektir.
• Property set mapping: Revit'in kendi parametreleri otomatik IFC standardına eşleşmez. BEP'te hangi parametrenin hangi IFC property set'ine bağlanacağı tablo halinde olmalı.
• Sınıflandırma kuralı: Uniclass, OmniClass veya proje-spesifik sınıflandırma — hangisi kullanılacak?
• Koordinat sistemi: Proje sıfır noktası, gerçek dünya datumu (UTM, ITRF), yüksekleştirme datumu (deniz seviyesi referansı). İki disiplinin sıfırı uyuşmuyorsa federated model anlamsız.

İstanbul Havalimanı ölçeğindeki projelerde yaşanan bir senaryo: mimari proje ofisi yerel koordinatla çalışıyor (proje sıfırı bina köşesinde), altyapı yüklenicisi UTM zone 35N kullanıyor. İki model birleştirildiğinde yapı 410 km kuzeydoğuya kayıyor. BEP'te ortak datum tanımlanmamışsa bu kayma her güncellemede tekrar eder.

Revizyon ve değişiklik yönetimi

BIM'de revizyon, kâğıt çizim revizyonundan farklı davranır. Bir kolon ekseni 30 cm kaydığında değişiklik 14 farklı pafta, 6 disiplin modeli, 3 imalat detayı ve metraj listesini eş zamanlı etkiler. BEP'in revizyon prosedürü olmadan bu değişiklik kontrolsüz yayılır.

Sağlam bir revizyon zinciri dört aşamadan oluşur:

1. Değişiklik talebi (Change Request): Kim, neden, hangi etki kapsamı ile istiyor? Form üzerinde yazılı.
2. Etki analizi: Disiplin sorumluları kendi modeline etkiyi değerlendirir. Süre ve maliyet etkisi belgelenir.
3. Onay: Bilgi yöneticisi veya proje yöneticisi formel onay verir. Onaysız değişiklik CDE'ye giremez.
4. Uygulama ve dağıtım: Onaylı değişiklik tüm taraflara revizyon notu ile dağıtılır, CDE'de sürüm numarası artar, MIDP güncellenir.

Türk kamu projelerinde son yıllarda artan BIM şartı, kontrolün eski kâğıt mantığıyla yürütülemeyeceğini gösterdi. Yapı denetim mekanizması artık model üzerinden çalışmaya başladıkça onaylı sürüm sorusu sözleşme düzeyinde önem kazanıyor.

Bilgi yöneticisi rolü ve sorumluluk matriksi

BEP'in başarısı, "Information Manager" rolünün gerçekten birinin omzuna oturmasına bağlı. ISO 19650 bu rolü tek bir disipline bağlamaz; mimari ofiste BIM koordinatörü, müteahhitte BIM yöneticisi, işverende ise atanan teknik temsilci üstlenebilir. Önemli olan rolün proje genelinde tek elden yürümesi.

Sorumluluk matriksi tipik olarak RACI formatında yazılır:

• R (Responsible): Üretimi yapan kişi/ekip
• A (Accountable): Sonuçtan hesap veren tek kişi (her satırda sadece bir A olabilir)
• C (Consulted): Üretim öncesi görüşü alınan
• I (Informed): Sonuçtan haberdar edilen

Pratikte ekipler RACI'yi formaliteden doldurur ama A satırlarını net çekmez. Bir kalem için iki A olduğunda kimse hesap vermez. BEP'te RACI matriksi varsa, A sütununu gözden geçirip her satırda yalnız tek kişi olduğunu doğrulamak ilk iştir.

BEP yazılırken hangi kalemler sıkça atlanır?

Onlarca BEP belgesi incelendiğinde tekrar eden zayıflıklar şu başlıklara toplanır: yazılım sürüm kontrolü tanımsız bırakılır (bir disiplin Revit 2024, diğeri 2026 — dosya açılmaz), yedekleme sıklığı ve sorumlusu yazılmaz, koordinasyon toplantı kadansı belirsizdir, federated model birleştirme tolerans değerleri yoktur, model element ownership matriksi eksiktir.

İyi yazılmış bir BEP, proje yarısına geldiğinde rafa kalkmayan, ekiplerin her sabah açtığı referans dokümana dönüşür. Kötü yazılmış BEP ise ihale dosyasında imzalanan, sonra herkesin kendi bildiği gibi devam ettiği bir kağıt parçasıdır. Aradaki farkı belirleyen şey, planın hayatın içinden gelen senaryolarla — koordinat çakışmasından, IFC export'un property kaybetmesine kadar — test edilip edilmediğidir.