ISO 19650'DE VERSİYONLAMA VE ONAY SÜRECİNİ YÖNETMEK

Ankara'da bir kamu hastane yatırımının uygulama projesi teslim haftasında işveren tarafında üç farklı "final" mimari plan dolaşıyor. Birinin üst köşesinde damga var ama tarih okunmuyor; ikincisi e-posta ekiyle gelmiş ve gönderen kişi ofiste değil; üçüncüsü ortak sürücüden indirilmiş ve dosya adı kat-plani-onayli-revize-son.dwg. Şantiyede demir döşeyen ekip hangisinin geçerli olduğunu telefonda sorunca proje müdürü "sabah göndereceğim" diyor; cevap geldiğinde dökümün üçte biri yapılmış. Ertesi hafta yapılan toplantıda kimse "hangi versiyon, ne zaman, kimin imzasıyla yayınlandı" sorusuna kayda dayalı bir cevap veremiyor.

Bu sahnenin tekrarlanmaması için ISO 19650 versiyonlama ve onay sürecini sıkıya bağlar. Standart yalnızca dosya adlandırma değil; her information container'ın hangi revizyonda olduğunu, hangi uygunluk koduyla paylaşıldığını, kimin tarafından kontrol-inceleme-onay zincirinden geçirildiğini ve hangi tarihte hangi statüye geçtiğini denetlenebilir kayda dönüştürmeyi şart koşar. Standardın ikinci bölümü olan ISO 19650-2 bu zincirin proje teslim aşamasındaki kurallarını verir; Türk yapı sektöründe işveren-müşavir-yüklenici üçlüsünde uygulamak için her katmanın yerelleştirilmesi gerekir.

REVİZYON KODU NE ANLAM TAŞIR?

ISO 19650'de bir information container'ın versiyon kimliği iki parçalıdır: revizyon ve suitability. Revizyon kodu dosyanın yaşam çizgisinde kaçıncı sürümde olduğunu söyler; suitability kodu o sürümün hangi amaçla paylaşıldığını belirler. Bu ikilik anlaşılmadan versiyonlama disiplini sahaya inmez.

Revizyon kodları iki ön ekle ayrılır:

• P (Preliminary) — sözleşme öncesi / tasarım aşaması revizyonu: P01, P02, P03 şeklinde artar. Bu sürümler tasarım, koordinasyon ve inceleme süreçlerinde dolaşır; sözleşmesel taahhüt taşımaz. Avan proje, uygulama projesi geliştirme, çakışma çözümü aşamasında üretilen tüm modeller P serisindedir.
• C (Contractual) — sözleşme sonrası / yapım aşaması revizyonu: C01, C02 şeklinde artar. Container resmi olarak onaylanıp Published kapsamına alındıktan sonra C serisine geçer. C kodlu bir sürüm sözleşmesel referanstır; saha imalatı bu sürümden yürütülür.

Suitability ise sürümün hangi kullanım iznine sahip olduğunu belirtir. UK National Annex revizyonu ile sabitlenmiş ve uluslararası pratikte yaygınlaşmış kodlar şunlardır:

Container'ın tam kimliği bu iki bilginin birleşimidir. Bir mimari plan dosyası adında S2-P03 görüldüğünde bu üçüncü ön sürümün diğer disiplinler için bilgi amaçlı paylaşıldığı anlaşılır; A1-C01 ise yapım aşaması için onaylı ilk sözleşmesel sürüm demektir. İki kodu birbirinden ayırmadan yalnızca "rev01" yazmak ISO 19650 değildir; o sadece eski Türk pratiğinin yeniden adlandırılmış halidir.

CONTAINER İSİMLENDİRMESİ NASIL YAPILIR?

ISO 19650 her information container için minimum metadata setini şart koşar: konteyner kimliği (dosya adı), revizyon kodu, suitability kodu ve sınıflandırma kodu. Dosya adı yalnızca disiplin-aşama bilgisini değil, proje kodunu, sahibi tarafı, konum kodunu ve tip kodunu da taşır. UK National Annex'in önerdiği yapı şu sırayı izler: Proje-OluşturanTaraf-Hacim-Seviye-Tip-Rol-Konu. Türk projelerinde bu yapı kısaltılabilir ama dört alan korunmalıdır: proje kodu, oluşturan taraf, disiplin (rol) ve içerik tipi.

Bir Türk hastane projesi için örnek dosya kimliği:

• Tam ad: HSP01-MIM-ZN-00-DR-A-001_S2-P03.dwg
• Çözümleme: HSP01 (proje kodu) - MIM (mimari yüklenici) - ZN (zemin kat) - 00 (genel) - DR (drawing) - A (architectural) - 001 (sıra no) + S2-P03 (suitability-revizyon)

Bu metadata yalnızca dosya adına yazılmaz; aynı bilgi CDE platformunun container property setine de işlenir. Dosya adı bozulursa CDE içindeki metadata referans kalır. Türk pratikte yaygın hata her iki yerin tutarlı tutulmaması; dosya adı el ile değiştirildiğinde CDE alanı güncellenmez ve sorgu sonuçları yanlış container'ı getirir. ISO 19650 bu tutarlılığı information manager rolünün sorumluluğuna verir.

CHECK REVIEW APPROVE — ÜÇ KAPILI ZİNCİR

Bir container yeni bir suitability koduna geçerken üç adımlı bir kapıdan geçer: check (kontrol), review (inceleme), approve (onay). Bu zincir disiplin içinde başlar ve dış paydaş onayına kadar uzanır. ISO 19650-2 zincirin her halkasında ayrı bir rol sahibi tanımlar.

1. Check — Görev ekibi içi kontrol: Container'ı üreten kişi yalnız bırakılmaz; aynı görev ekibinden başka bir uzman dosyayı açar, modeller doğru mu, ölçü doğru mu, property seti tam mı kontrol eder. Bu kontrol başarısızsa container WIP'te kalır; başarılıysa task team leader'ın masasına gelir.
2. Review — Görev ekibi lideri incelemesi: Disiplin lideri (örneğin mimari ekibinin baş mimarı) container'ı bütünsel bakar; iç tutarlılık, EIR-BEP uyumu, çakışma riski. Lider onaylarsa container WIP'ten Shared'a S1 ile geçer.
3. Approve — Yetkili onay: Container disiplinler arası koordinasyondan geçtikten ve S4'e yükseldikten sonra appointing party (işveren) veya onun delege ettiği lead appointed party (BIM koordinatörü) tarafından onaylanır. Onay verildiğinde container Published'a A1 koduyla geçer; revizyon serisi P'den C'ye döner.

Üç kapının hiçbiri pas geçilemez. Bir mimari ekibin doğrudan modeli S4'e gönderme refleksi (çok rastlanan) check ve review kapılarını boşaltır; sonradan koordinasyon sorunlarında "biz onayladık ama mekanik baktığında çakışma vardı" tartışması başlar. Standart bu tartışmayı kapatmak için zincirin her halkasında zaman damgalı kayıt tutar; CDE platformu kim ne zaman hangi container'ı hangi statüye taşıdı sorusunu otomatik raporlar.

SUITABILITY YÜKSELİRKEN HANGİ KARARLAR DEĞİŞİR?

Suitability kodunun artması basit bir etiket değişimi değildir; container'ın kullanılma izninin değişmesidir. S1 kodlu bir mimari model koordinasyon için paylaşılmıştır; mekanik ekip bu modeli okur, çakışma testi yapar ama imalata sokmaz. S2 bilgi amaçlıdır; statik ekip cephe yükünü bu modelden alabilir ama hâlâ imalat tetiklenmez. S3 yorum için açılır; işveren temsilcisi paftaya kırmızı kalem dolaştırır, açıklama notu yazar. S4 aşama onayı için son adımdır; içeride sorun yoksa Published'a A1 ile alınır.

Her kodun davranışsal sonucu vardır:

S0 → S1 (WIP'ten Shared'a)

Container ilk kez dış disiplinlere açılır. Yazar disiplin onun üzerinde artık yalnız değildir; herhangi bir değişiklik yeni revizyon (P02, P03) gerektirir. Yazar disiplinin keyfi düzenleme dönemi biter.

S1 → S2 / S3

Diğer disiplinler container'ı bilgi olarak kullanma yetkisi alır. Bu noktadan sonra bir disiplinin başka disiplinin S1 modelinden veri çekip kendi modeline referans vermesi sözleşmesel temas yaratmaya başlar.

S3 → S4

Container işveren onayına hazır olduğunu beyan eder. Bu adım için disiplinler arası koordinasyon tamamlanmış olmalıdır; aksi halde onay reddedilir.

S4 → A1 (Shared'dan Published'a)

Sözleşmesel sürüm doğar. Saha bu sürüme göre imalat yapar; hata oluşursa hatanın sorumluluğu A1'i yayınlayan tarafa düşer.

Bu davranış farklarının bilinmesi ekibi koruyan tek şeydir. Bir cephe altyüklenicisi S2 kodlu bir mimari modelden ölçü alıp imalat siparişi geçerse hata ortaya çıktığında ana yüklenici S2'nin bağlayıcı olmadığını ileri sürer. Standart bu sınırı net çizmiş, kullanıcının okuması beklenir.

TRANSMITTAL VE ONAY KAYITLARI

ISO 19650, container'ın bir bölgeden diğerine geçişini transmittal belgesi üzerinden kayda alır. Transmittal "bu kalemi şu tarihte şu statüye taşıdım, ekteki container şu revizyondadır, şu sürede cevap bekliyorum" bilgisini taşıyan belgedir. Eski Türk pratikteki teslim tutanağı veya zarf nakil belgesinin BIM dünyasındaki karşılığıdır ama dijitaldir ve CDE içinde otomatik üretilir.

Bir transmittal şu alanları taşır:

• Gönderen taraf ve alan taraf (kişi ve rol)
• Konteyner kimliği, revizyon ve suitability kodu
• Hedef statü (örneğin S3'ten S4'e çekme talebi)
• Beklenen cevap süresi (genelde 5-10 iş günü)
• Container'ın değişim özeti (change description)
• İlgili önceki transmittal referansı (chain)

Transmittal'ın olmadığı bir onay süreci ISO 19650'ye uygun değildir. Türk projelerinde "e-posta ile gönderdim, onay verdiler" cümlesi sıkça duyulur; bu cümle standart açısından geçersizdir çünkü e-posta CDE dışıdır, zincir izleme yapmaz, alıcı kuruma bağlı, gönderen kişiye bağlı bilgi kalır. Transmittal yapısı bunu kaldırmak için tasarlanmıştır; gönderen kim olursa olsun belge CDE içinde durur ve denetimde sorgulanabilir.

TÜRK İŞVEREN MÜŞAVİR YÜKLENİCİ ZİNCİRİNDE ONAY ROLLERİ

Türk yapı sektöründe onay zinciri klasik üçlüye dayanır: işveren (yatırımcı kurum), müşavir (idarenin teknik danışmanı veya proje müdürlüğü), yüklenici (ana yüklenici ve alt yükleniciler). ISO 19650 dili bu üçlüye yeni roller eklemez; mevcut rollerin yetki sınırlarını netleştirir. Pratikte rol matrisi şu şekilde oturur:

Bu eşleştirme uygulamada büyük fark yaratır. Türk şartnamelerinde "yüklenici BIM yapacaktır" cümlesi geçtiği halde information manager rolü tarif edilmemişse onay kapıları boş kalır; container'lar Shared bölgesine birikir ama Published'a geçemez. Tersine, bu rol işveren tarafında net atanmış ve adam sahaya çıkmışsa zincir günde birkaç container'ı işleyebilecek hızda akar. ISO 19650 BIM eğitimi bu rol matrisinin Türk şartnamelerine yerleştirilmesini ve check-review-approve kapılarının pratik kurulumunu vaka temelli çalışır.

KEP E-İMZA M-İMZA — ONAYIN HUKUKİ KATMANI

Türkiye'de onay zinciri yalnızca süreç değil hukuki bir belge üretimidir. Bir A1 onayı sözleşmesel sürüm yarattığı için imzalayan kişinin imzasının hukuken geçerli olması gerekir. Üç araç bu katmanı tamamlar:

• E-imza (Nitelikli Elektronik Sertifika): 5070 sayılı kanun çerçevesinde ıslak imza ile eşdeğer hukuki etki taşır. BTK lisanslı ESHS (Elektronik Sertifika Hizmet Sağlayıcısı) tarafından verilir. CDE platformu transmittal'ı bu sertifikayla imzalattığında onay zinciri hukuken denetlenebilir kayıt halini alır.
• Mobil imza (m-imza): GSM operatörü SIM kartına entegre edilmiş nitelikli sertifikadır. Saha mühendisinin tabletinden veya telefonundan dakikalar içinde transmittal imzalamasını mümkün kılar.
• KEP (Kayıtlı Elektronik Posta): PTT ve özel KEP servis sağlayıcıları üzerinden işleyen, gönderim ve teslim tarihinin yasal delil değeri taşıdığı e-posta sistemidir. Sözleşmesel teslimler (geçici kabul tutanağı, ihtarname, fesih bildirimi) için tercih edilir. CDE içindeki onay sürecinin paralel kanalı olarak KEP üzerinden bildirim de iletilebilir.

Türk yapı sektörü için pratik öneri: CDE platformuna e-imza entegrasyonu açılır; idare tarafındaki Information manager A1 onayını e-imza ile yapar. Yüklenici disiplin liderleri saha onayları için m-imza kullanır. KEP'e taşınan adımlar yalnızca büyük sözleşmesel dönüm noktaları (geçici kabul, hakediş onayı) olur. Bu yapı standart ISO 19650 zincirini Türk hukuki katmanına oturtur ve bir uyuşmazlık durumunda mahkemenin sorduğu "onayı kim ne zaman verdi" sorusu CDE üzerinden cevap bulur.

REVİZYON SAYAÇI NE ZAMAN ARTAR?

Revizyon sayaçının ne zaman bir basamak ileri gideceği uygulama disiplinin en sık tartıştığı konudur. Standart şu kuralı verir: container'da hangi alanı değiştirirseniz değiştirin, suitability dış paydaş etkileşimine açıldıktan sonra yapılan her değişiklik yeni revizyon doğurur. Pratikte sayaç şu olaylarda ilerler:

• WIP'te yapılan değişiklikler revizyon doğurmaz; yazar disiplin S0 içinde dilediği kadar P01 üzerinde çalışabilir.
• Container S1'e (Shared'a) ilk çıkışında P01 sabitlenir; bu container donmuş bir sürümdür.
• Diğer disiplinler S1'e yorum yazınca ve yazar disiplin düzeltme yapınca yeni sürüm P02 doğar; ilki Archived'a kayar.
• S4'ten geri çevrilen bir container düzeltildiğinde P03 olur; aynı suitability'de geri yüklenir.
• Published'a A1 ile alınan bir container'da değişiklik gerekirse yeni sürüm C01'dir; ana sayaç P'den C'ye atlar.
• C01 üzerinde minör düzeltme gerekirse C02 doğar; majör değişiklik (örneğin bir mahalin kat planının yeniden çizilmesi) genelde yeni C revizyonu açar.

Türk pratikte sıkça karşılaşılan hata bir revizyonun "küçük olduğu için" sayaçta sayılmamasıdır. ISO 19650'ye göre değişiklik büyüklüğü değil container'ın suitability dışına çıkmış olması revizyonu doğurur. Bir kapı ölçüsünün 5 cm değiştirilmesi bile, container Shared'dan inip tekrar çıkıyorsa yeni P revizyonudur. Bu disiplin sözleşmesel takiplerde her kararın hangi sürüme dayandığını izlenebilir kılar; ortadan kalkması sözleşme uyuşmazlıklarında belge zincirinin kopmasıyla sonuçlanır.

ITT VE EIR ZİNCİRİYLE ONAYIN İŞLETİLMESİ

Onay süreci tek başına çalışmaz; ITT (Invitation to Tender, ihaleye davet) ve EIR (Exchange Information Requirements) belgeleriyle paralel akar. ITT içinde işveren, ihale aşamasında hangi container'ların hangi suitability'de teslim edileceğini yazılı talep eder. EIR ise sözleşme sonrası tüm yaşam döngüsünde aynı talebi detaylandırır. Yüklenici BEP (BIM Execution Plan) hazırlarken EIR'deki suitability kapılarına nasıl cevap vereceğini taahhüt eder; MIDP (Master Information Delivery Plan) içine onay tarihleri yerleşir.

Bu zincir bütün halinde işlediğinde proje yöneticisi haftalık toplantıda "şu hafta hangi container hangi onaya gelecek" sorusuna MIDP'den bakarak cevap verir. Geç kalan kalem varsa MIDP referansıyla yazılı uyarı çıkar; gecikme ceza klozuna bağlıdır. Bu yapı kurulmadan onay disiplini saha refleksine kalır ve disiplinden disipline değişir.

VERSİYONLAMADA SIK HANGİ HATALAR YAPILIR?

Onlarca proje incelendiğinde versiyonlama disiplini şu altı noktada kırılır:

1. Suitability ile revizyonu karıştırmak: "Rev03" yazıp suitability'i atlamak. Bu yapı "hangi sürüm" sorusunun yanıtını yarım verir; "hangi amaçla" sorusu havada kalır.
2. P serisinden C'ye otomatik geçme: Container S4'ten A1'e geçerken sayaç P'den C'ye otomatik atlar; bunu unutup C00 veya P sürümü Published'a almak metadata tutarsızlığı yaratır.
3. Check kapısını yazar üzerinde yığmak: Yazar disiplin kendi container'ını kendi kontrol etmesi yetersizdir; ekip içinden bağımsız ikinci göz şarttır. Bu adım atlandığında küçük hatalar S4'e kadar taşınır.
4. Transmittal'ı CDE dışında yürütmek: WhatsApp'tan "onayladım" cevabı, e-posta'dan "tamam" yazısı transmittal yerine geçmez. Standart belge zincirinin CDE içinde olmasını şart koşar.
5. Archived bölgesini boş bırakmak: Yeni revizyon üretilince eski sürüm Archived'a alınmalı, silinmemeli. Türk pratikte "disk yer kapsın diye sildim" refleksi denetim sırasında belge eksikliği yaratır.
6. Information manager rolünü boş bırakmak: Onay zincirini izleyen kişi yoksa container'lar S3-S4 arasında haftalarca asılı kalır. Bu rol mutlaka tek kişiye atanmalı, ona yetki verilmeli, ona ulaşılabilir olmalıdır.

Hataların ortak özü standardın kendisinden değil, uygulama disiplininden gelir. ISO 19650 kuralları yazmış, sahanın yürütmesi gerekiyor. Bir BIM koordinatörünün haftalık görevi check-review-approve kapılarındaki container'ları izlemek, gecikenleri rapor etmek ve transmittal eksiklerini kapatmaktır. Bu rolün doldurulmadığı projeler standart belgesini imzalamış görünse de pratikte standart dışındadır.

Versiyonlama ve onay süreci görünüşte teknik bir formalite gibi durur; gerçekte projenin hukuki, finansal ve operasyonel omurgasıdır. Saha bir A1 onayına bakarak beton döker, hakediş bir transmittal zincirine bakarak yazılır, uyuşmazlık bir versiyon kaydına bakarak çözülür. ISO 19650'nin bu katmanını sahaya indirmek tek başına BIM yazılımı satın almak veya eğitim alma ile olmaz; rol tanımı, CDE yapılandırması, e-imza entegrasyonu ve disiplinler arası alışkanlık birlikte kurulduğunda standart işler. Türk yapı sektöründe bu omurganın oturması son birkaç yılda hızlanmış olsa da hâlâ proje proje değişen bir olgunluk seviyesindedir; ilerleyen ihalelerde işveren tarafının bu yapıyı talep gücü arttıkça yüklenici tarafı da bu disipline geçmek zorunda kalacaktır.