ISO 19650'DE INFORMATION REQUIREMENTS KAVRAMSALLAŞTIRMAK

Bir kamu hastane ihalesinin ön yeterlilik dosyasında işveren teknik şartnamesi 84 sayfa. Sayfaların 12'si BIM bölümüne ayrılmış. İçinde "tüm modeller IFC formatında teslim edilecektir" cümlesi var ama hangi IFC sürümü, hangi MVD, hangi property set, hangi aşamada teslim, kim onaylayacak — hiçbiri yazılı değil. Yüklenici teklif verirken "BIM şartı var, oradan idare karar verir" diyerek geçiyor. Sözleşme imzalanıyor. Ön projede mimar Revit kaynak dosyasını yüklüyor, statik Tekla'dan IFC export'u koyuyor, mekanik MagiCAD çıktısı paylaşıyor. Üç dosya birbirine takılmıyor; müşavir "federe model getirin" diyor ama hangi disiplinin neyi nereye koyacağı tarif edilmediği için aylar sahada tartışmaya gidiyor.

Bu boşluğun adı bilgi gereksinimi tanımsızlığıdır. ISO 19650 standardı tam bu noktayı düzeltmek için yazıldı; standardın resmi referansı dört katmanlı bir bilgi gereksinim hiyerarşisi tanımlar ve her katmanın kimin tarafından, ne zaman, hangi belgeyle üretileceğini sıkıya bağlar. Türk yapı sektöründe yatırımcı kurum (Çevre, Şehircilik ve İklim Değişikliği Bakanlığı, KGM, Sağlık Bakanlığı Yatırım Genel Müdürlüğü vb.), müşavir ve yüklenici üçlüsünde bu zincirin nasıl çalıştığını anlamadan ne ihale şartnamesi tutarlı yazılır, ne teslim disiplini kurulabilir.

BİLGİ GEREKSİNİMİ DEDİĞİMİZ ŞEY NEREDEN ÇIKTI?

ISO 19650 bilgi gereksinimini bir karar verici tarafın (appointing party — Türkçesiyle atayan taraf, pratikte işveren), bir bilgi üretici taraftan (appointed party — atanan taraf, müşavir veya yüklenici) ne zaman, hangi formatta, hangi içerikle bilgi beklediğini yazıya döken belge olarak tanımlar. Standart bunu dört seviyeye ayırır ve seviyeler birbirine kaskat şeklinde bağlıdır:

• OIR — Organizational Information Requirements (Kurumsal Bilgi Gereksinimi): Yatırımcı kurumun kendi stratejik kararları için ne tür bilgiye ihtiyacı var. ÇŞB için "Türkiye genelindeki kamu binalarının enerji performansını merkezi izleyebilmek" gibi.
• AIR — Asset Information Requirements (Varlık Bilgi Gereksinimi): Tek bir varlığın (bir hastane, bir otoyol, bir baraj) işletim aşamasında hangi veriyle yönetileceği. Asansör seri numarası, HVAC ekipman bakım kayıtları, yangın bölgesi sınırları, garanti süreleri.
• PIR — Project Information Requirements (Proje Bilgi Gereksinimi): Proje boyunca işverenin karar vermesi gereken anlarda eline ne tür bilgi geçmeli. Avan proje onayı için ne, ruhsat için ne, kabul için ne.
• EIR — Exchange Information Requirements (Bilgi Değişim Gereksinimi): Bunların hepsinin teknik şartname diline çevrilmiş hali. Yüklenici bu belgeyi okur, BEP (BIM Execution Plan) hazırlar ve teslim formatını bu plana göre kurar.

Sıralama tek yönlü: OIR strateji belgesidir, AIR varlığa indirir, PIR projeye odaklar, EIR ihale belgesi haline gelir. Üstteki bozuk olursa altı zorla düzelmez. Bir bakanlık bir hastane için EIR yazmadan ihaleye çıkarsa, yüklenici teklif verirken hangi LOD, hangi LOI, hangi sınıflandırma sisteminin geleceğini bilemez. Tahmin üzerine fiyat oluşur; sözleşme sonrası "bu da BIM kapsamında" tartışmaları başlar.

OIR — STRATEJİK KARAR SEVİYESİNDE BAŞLAR

OIR çoğu Türk yatırımcısı için karanlık bir kavramdır çünkü kurumun bütününe bakar, tek bir projeye değil. Bir bakanlık veya büyükşehir belediyesi düşünelim: yıl içinde ortalama 40 yapım işi ihalesi açar, her biri 5-15 yıl işletim ömrüne girer, 30 yıl sonra ya yenilenir ya yıkılır. Bu süreçte kurumun cevaplaması gereken sorular vardır:

• Hangi varlıkların enerji tüketimi referans değerin üstünde, hangileri için iyileştirme bütçesi ayrılmalı?
• 10 yıl sonra hangi yapının kabuk yenilemesi gelecek, planlama bütçesi ne olmalı?
• Deprem sonrası varlık envanterinin kritik yapısal verisi merkezi sistemden çekilebiliyor mu?
• Bakım sözleşmesi yenilenirken mevcut ekipman listesi tek tıkla raporlanabiliyor mu?

Bu sorulara cevap verebilmek için kurumun her varlığından düzenli, tutarlı, karşılaştırılabilir veri akması gerekir. OIR işte bu akışın talep listesidir. Türk kamu yatırımcı kurumları için OIR genellikle henüz yazılı değildir; ama Çevre, Şehircilik ve İklim Değişikliği Bakanlığı'nın BIM yönergesi gibi rehber belgeler bu boşluğu doldurmaya başlamıştır. OIR olmadan AIR yazılamaz çünkü AIR, OIR sorularına cevap verecek varlık-seviyesi veriyi tanımlar.

AIR — VARLIK İŞLETMEK İÇİN GEREKLİ VERİ

AIR, OIR sorularının somut karşılığıdır. ÇŞB "enerji performansı izlemeliyim" dediğinde, AIR şu seviyeye iner:

HVAC ekipmanları

Marka, model, kapasite (kW), enerji sınıfı, kurulum tarihi, garanti bitiş tarihi, bakım sözleşme numarası, son bakım tarihi, üretici teknik dokümantasyon linki, periyodik bakım takvimi.

Aydınlatma armatürleri

Tip (LED/floresan), watt, ömür beklentisi, devre kodu, anahtar konumu, dim kontrol özelliği, üretici, montaj tarihi.

Yangın algılama ve söndürme

Detektör tip, kapsadığı bölge, panel adresi, son test tarihi, sertifika numarası, hangi yangın bölge planında olduğu.

Asansör ve yürüyen merdiven

Seri numarası, kapasite, kat sayısı, yıllık muayene tarihi, asansör periyodik kontrol şirketi, garantili çalışma saati.

AIR bir Excel'e veya bir CAFM (Computer Aided Facility Management) sistemine doldurulur değildir; standardın diliyle Asset Information Model (AIM) içine yerleşir. AIM yapı modelinin işletim sürümüdür; geometri sade tutulur, bilgi (LOI) zenginleşir. Bir asansörün AIM'deki geometrisi LOD 200 (kabin hacmi) kalır, ama LOI 500'e çıkar — marka, model, bakım, garanti, sertifika hepsi içinde. Kamu mega projelerinde, özellikle 25-30 yıl YİD (Yap-İşlet-Devret) süresince varlığı işletecek özel ortağın, AIR'i karşılayan bir AIM teslim alması sözleşme şartıdır.

PIR — PROJE KARARLARI HANGİ BİLGİYLE ALINIR?

PIR proje boyunca işverenin karar verme anlarına odaklanır. ISO 19650'nin yaşam döngüsü 8 aşamadır (strategy, brief, concept, definition, design, construction, handover, operation). Her aşama bitiminde bir kapı (information delivery milestone) vardır; bu kapıdan geçmeden bir sonraki aşamaya geçilemez. PIR bu kapılarda işverenin elinde ne olması gerektiğini sıralar.

Türk kamu yapım pratiğinde PIR'in karşılıkları:

• Avan proje onayı: İşveren temsilcisi (idare) avan kararının verilebilmesi için maliyet tahmini (yaklaşık keşif), alan analiz tablosu, fonksiyon şeması, kütle çalışması, ön statik fizibilite raporu, ön mekanik konsept raporu bekler.
• Uygulama projesi onayı (ruhsat): Yapı denetim onaylı statik hesap, uygulama paftaları, mahal listesi, metraj cetveli, mekanik tesisat hesap raporu, elektrik yük listesi, yangın güvenlik raporu istenir.
• İmalat / ihale dökümanı kabul: Detay paftalar, birim fiyat analizleri, pursantaj tablosu, BoQ (bill of quantities), iş programı (genelde Primavera P6 veya MS Project).
• Geçici kabul: As-built modeller, montaj kayıtları, test raporları, ekipman manuelleri, garanti belgeleri, kullanım kılavuzları.
• Kesin kabul (1-3 yıl sonra): Kusur giderme dosyası, son revizyonlu as-built çizim seti, AIM güncel sürümü.

PIR'in detayını standart 19650-1 bu kararların hangi bilgi paketleriyle desteklendiğini, hangi formatta beklendiğini ve kimin onaylayacağını içerir. Türk uygulamasında bu cetvel klasik "projecilerin yapacağı liste" olarak idare şartnamesinde yer alır; BIM'li projede aynı listenin model katmanına çevrilmesi gerekir. Geleneksel pafta + statik hesap listesi BIM dünyasında federe model + property set + IFC sınıflandırma katmanına dönüşür.

EIR — TEKNİK ŞARTNAMENİN OMURGASI

EIR, üst üç katmanın somut çıktısıdır. İşverenin kendisi veya BIM danışmanı tarafından ihale öncesi hazırlanır ve idari şartnamenin eki olarak istekliye sunulur. Yüklenici teklif hazırlarken EIR'i okur, karşılığında BEP (BIM Execution Plan) yazar; bu plan teklif dosyasının BIM cevabıdır.

İyi yazılmış bir EIR aşağıdaki başlıkları ayrıntılı tarif eder:

1. Proje bilgileri: Yatırım kimliği, yer, kullanım türü, yaşam döngüsü tahmini, BIM uygulanacak disiplinler.
2. Bilgi teslim takvimi: Hangi aşamada hangi model, hangi pafta, hangi rapor teslim edilecek. Tarihler ihale takvimi ile hizalanır.
3. LOD/LOI matrisi: Her element kategorisi için (kolon, kiriş, perde, döşeme, kapı, pencere, HVAC ünite, sıhhi tesisat armatürü vb.) aşama bazlı geometri ve bilgi seviyesi.
4. Format ve dosya isimlendirme: Native dosya (Revit, Tekla, ArchiCAD vb.) + IFC sürümü (IFC4 Reference View, Design Transfer View vb.) + paftalar (PDF, DWG). Dosya adı kuralı projeye özgü olarak belirlenir.
5. Sınıflandırma sistemi: Uniclass, OmniClass, Türk pratiğinde ÇŞB poz numarası eşlemesi veya hibrit. Hangi sistemin hangi property'e yazılacağı sabitlenir.
6. Koordinat sistemi: ITRF96 / ED50 6 derece dilim, yükseklik datumu, proje sıfır noktasının harita koordinatları.
7. Ortak veri ortamı (CDE): Hangi platform, hangi klasör yapısı, hangi durum kodları (S0-S4 / A1 / B1 vb.), kimin neyi görmeye yetkili olduğu.
8. Federasyon ve koordinasyon: Federe modeli kim kuracak, ne sıklıkla, çakışma kontrolü hangi araçla (Navisworks, Solibri, BIMcollab vb.).
9. Onay ve red kriterleri: Müşavir bir model paketini hangi şartlar altında reddedebilir, düzeltme süresi ne kadar.

EIR yazılmamış veya eksik yazılmış bir ihalede tüm bu kararlar sözleşme sonrası tartışmaya açılır. Yüklenici "sizin EIR'iniz LOD 300 demiş, biz LOD 300 verdik" der; müşavir "ama mahal listesi LOD 350'ye karşılık geliyor" der. Hangi tarafın haklı olduğu ihale dokümanına geri dönülerek aranır; orada açıklık yoksa idare ya bedel artışına ya gecikmeye razı olur. Türk kamu mega projelerinde son üç-dört yılda EIR yazımı işverenin (veya işverenin teknik danışmanının) öncelikli hazırlığına dönüşmüştür; ISO 19650 BIM eğitimi EIR şablonunu vaka temelli çalışır ve Türk şartnamelerine uyarlanmış örnek dosyaları inceler.

BEP — YÜKLENİCİ EIR'E NASIL CEVAP VERİR?

BIM Execution Plan (BEP), EIR'in muhatabıdır. Yüklenici teklif aşamasında pre-contract BEP hazırlar; sözleşme sonrası bu belge post-contract BEP'e dönüşür ve uygulama dokümanı haline gelir. BEP iki yönü taşır:

• Cevap: EIR'deki her madde için "biz bu maddeyi nasıl karşılayacağız" cevabı yazılır. Hangi yazılım, hangi sürüm, hangi takım yapısı, hangi BIM koordinatörü.
• Plan: Sözleşme süresince hangi modelin hangi tarihte hangi durumda olacağı zaman çizelgesi olarak verilir. Bu çizelge MIDP'nin (Master Information Delivery Plan) zeminidir.

MIDP, BEP'in detayına iner: tüm yüklenici ve alt yüklenici teslim sorumluluklarını tek bir cetvelde toplar. Her satır bir teslim kalemi, bir disiplin, bir tarih, bir durum kodu içerir. MIDP'nin altında her disiplinin TIDP'si (Task Information Delivery Plan) durur; TIDP o disiplinin kendi içindeki haftalık-aylık görev ayrıştırmasıdır. Hiyerarşi temiz şöyledir:

• EIR (işveren talebi) → BEP (yüklenicinin metodolojisi) → MIDP (yüklenicinin toplu teslim takvimi) → TIDP (her disiplinin görev planı)

Bu dört belge bir aradayken proje yöneticisi haftalık toplantıda "bu hafta hangi disiplin neyi teslim edecek" sorusuna cetvelden bakarak cevap verir. Yokken aynı cevap WhatsApp grubundan toplanır ve haftadan haftaya değişir.

TÜRK İŞVEREN-MÜŞAVİR-YÜKLENİCİ ZİNCİRİNDE BİLGİ TALEBİ

Türk yapım sektöründe bilgi talep zinciri klasik üçlüye dayanır: işveren (yatırımcı kurum), müşavir (genelde idarenin teknik danışmanı / yapı denetim / proje müdürlüğü), yüklenici (ana yüklenici + alt yükleniciler). ISO 19650 dilinde bu üçlünün karşılığı:

Bu eşleştirme yapıldığında ihale dokümanlarındaki rollerin BIM dünyasındaki karşılıkları netleşir. Mevcut Türk şartnameleri çoğu projede "yüklenici BIM yapacaktır" cümlesini geçer ama lead appointed party / information manager rolü tarif edilmez. Sonuçta bir BIM koordinatörü atanmaz, alt yüklenicilerin teslim disiplini denetlenmez, federe model oluşmaz. ISO 19650 bu boşluğu doldurmak için her atanan tarafa yazılı yetki tanımlar; özellikle information manager rolü işveren tarafında belirli bir kişi/firmaya verilir, BIM kararı bu rol üzerinden yürür.

Müşavir tarafında bu rolü genelde idare adına çalışan teknik müşavirlik firması veya proje müdürlüğü üstlenir. Bağımsız yapı denetim, bu rolün dışındadır; yapı denetimin görevi statik-zemin-mimari uygunluk kontrolüdür, BIM süreç yönetimi değildir. Karıştırılması yaygındır.

BİLGİ TALEBİ ZİNCİRİ NEREDE TIKANIR?

Saha pratiğinde EIR yazılmış bir projede bile zincir tıkanabilir. En sık görülen sebepler:

1. OIR yazılmadan AIR'e atlama: Yatırımcı kurum stratejik soruyu netleştirmeden "asansörlerin marka modelini istiyoruz" der. Aslında ihtiyacı "yıllık bakım maliyet trendini izlemek" ise AIR satırı daha geniş olmalıdır (bakım sözleşmesi süresi, garanti uzatma seçeneği). Eksik AIR, AIM'i yetersiz bırakır.
2. PIR'den EIR'e atlamada teknik dile çevirmemek: "Avan projede maliyet tahmini lazım" PIR cümlesidir; EIR karşılığı "LOD 200 mimari model + element bazlı miktarları m³/m²/ad birimleriyle" olmalıdır. Çevirilmeden ihaleye konursa yüklenici nereye kadar detay vereceğini bilemez.
3. EIR'in iç tutarsızlığı: Avan projede LOD 200 isteniyor ama property set olarak garanti süresi (LOI 400 seviye veri) talep ediliyor. Geometri seviye düşük, bilgi seviye yüksek istemek çelişkidir; EIR yazarı bu eşleştirmeyi matriste kontrol etmelidir.
4. BEP'in EIR'i okumadan yazılması: Yüklenicinin BIM ekibi "biz hep böyle yaparız" mantığıyla standart şirket BEP'ini sunar. EIR'deki spesifik sınıflandırma, koordinat sistemi veya teslim formatı talepleri karşılanmaz. Müşavir teslim aşamasında ret kararını EIR satırına dayandırır.
5. MIDP'nin sözleşmeye eklenmemesi: Teslim tarihleri BEP'te yer alıyor ama sözleşme zaman çizelgesinden ayrı duruyor. Yüklenici gecikince ceza yazılmıyor çünkü gecikme "sözleşmesel teslim" değil "BEP iç planı".
6. Information manager rolünün boş olması: İşveren BIM koordinatörü atamamış, alt yüklenicilerden gelen teslimler arasında arabuluculuk yapan kimse yok. Çakışma raporları yığılır, kararlar gecikir.

Bu altı tıkanma noktası standartla ilgili değil, uygulama disiplini ile ilgilidir. EIR mükemmel yazılmış olsa bile information manager rolü boşsa zincir aksamaya başlar; tersine, EIR çok ayrıntılı olmasa bile aktif bir information manager varsa boşluklar süreç içinde kapatılır. Standart yazılı belgeyi kurar, insan zinciri yürütür.

ÇŞB BIM YÖNERGESİ VE ÇKD/MEC İÇERİK GEREKSİNİMLERİ

Türkiye'de kamu yapım işlerinde BIM uygulaması Çevre, Şehircilik ve İklim Değişikliği Bakanlığı'nın yayımladığı BIM yönergesi ile yön bulur. Yönerge, kapsam dahilindeki yapım işlerinde model teslimini, çakışma kontrolünü ve bilgi yönetimini şart koşar. Yönergenin ISO 19650 hiyerarşisindeki karşılığı yatırımcı kurum-bazlı OIR'in ilk taslağıdır; bakanlık tüm kamu binaları için temel bilgi gereksinimini bu belgeyle ortaya koyar.

Yönerge ile birlikte gelen ÇKD (Çalışma Kapsamı Dokümanı) ve MEC (Model Element Cetveli) tipik bir EIR'in iki ana parçasıdır:

• ÇKD: Projenin BIM kapsam tanımı. Hangi disiplinler modelde olacak, hangi aşamada teslim edilecek, hangi yazılım/format kullanılacak.
• MEC: ISO 19650'deki LOD/LOI matrisinin Türkçe karşılığı. Her element için geometri seviyesi + bilgi seviyesi + sorumlu disiplin + teslim aşaması tablo halinde.

Türk yüklenicisi MEC tablosunu açtığında ne yapması gerektiğini doğrudan görür. MEC olmayan bir projede "LOD 300 modelleyin" cümlesi yetersizdir; LOD 300 tanımı yazılım üreticisine, ülkeye, danışmana göre değişir. MEC bunu sabitler: "Kolon, avan projede LOD 200 geometri + LOI 200 bilgi (beton sınıfı, kesit boyutu, kat); uygulama projesinde LOD 300 + LOI 300 (donatı planı referansı, üretim metodu)". Bu seviye sabitlendiğinde teklif fiyatı tutarlı oluşur, teslim onayı net karara bağlanır.

BİLGİ GEREKSİNİMİ YAZIMINA NEREDEN BAŞLANIR?

Bir yatırımcı kurumun veya müşavirlik firmasının ilk EIR'ini sıfırdan yazması haftalar sürer ama doğru sıra takip edilirse iskelet stabil kurulur:

• Önce kurum stratejik sorularını sıralasın (OIR). "Bu projeyi 25 yıl sonra hangi soruları cevaplayabilen veriyle teslim almak isterim?" sorusu cevaplansın.
• OIR sorularına karşılık varlık-seviyesi veri seti çıkarılsın (AIR). Tek tek element kategorileri (HVAC, asansör, yangın, aydınlatma vb.) için hangi property'lerin lazım olduğu listelensin.
• Proje yaşam döngüsü kapıları belirlensin (PIR). Türk kamu pratiğinde avan-uygulama-imalat-geçici kabul-kesin kabul kapıları kullanılır. Her kapıda işverenin eline ne geleceği yazılsın.
• Üst üç katman teknik şartname diline çevrilsin (EIR). LOD/LOI matrisi, dosya formatı, isimlendirme, CDE, federasyon kuralları sabitlensin. ÇŞB MEC şablonu başlangıç noktası olabilir.
• Information manager rolü işveren tarafında tanımlansın. Bu kişi/firma EIR'i savunur, teslim onayını verir, çakışma kararını yürütür.
• Pilot proje seçilsin. İlk EIR komple bir kampüs üzerine değil tek bir yapıda denensin; eksikler ikinci projeye aktarılsın. Üç-dört pilot sonrası kurumsal şablon olgunlaşır.

Bu altı adım takip edildiğinde kurumun BIM yatırımı verimli bir sistematik haline gelir; bilgi gereksinimi kavramı sözleşmesel bir omurgaya dönüşür ve şantiyedeki belirsizlik kapanır. ISO 19650 sertifikalı uygulamanın saha gerçeğine indirgenmesi için BIM koordinasyon eğitimi federe model kurulumu, BCF iş akışı, durum kodu yönetimi ve EIR-BEP eşleştirme pratiğini saha vakaları üzerinden çalışır.