Yazılarımız

Veri Akademi

ISO 19650’DE BEP YAPISI VE DOKÜMAN HİYERARŞİSİ KURMAK

ISO 19650 ile çalışmaya başlayan ekiplerin en hızlı tıkandığı yer, “BEP yazmak” değil; BEP’in yaşayacağı doküman düzenini kurmak ve herkesin aynı dili konuşmasını sağlamaktır. Çünkü iyi bir BEP, tek seferlik bir PDF olmaktan çok, proje boyunca güncellenmesi ve referans alınması gereken bir yönetim sistemidir.

Bu nedenle BEP’in yapısını kurmakla doküman hiyerarşisini kurmak aynı problemin iki yüzüdür. Bir tarafta süreç, roller, onay akışları ve bilgi gereksinimleri; diğer tarafta klasörler, dosya adlandırma, revizyon mantığı ve CDE (Common Data Environment) katmanları vardır.

Bu yazıda, ISO 19650’ye uygun BEP yapısını kurgulamak, doküman hiyerarşisini standardize etmek ve ekiplerin günlük üretimini bozmadan sürdürülebilir bir sistem kurmak için uygulanabilir bir çerçeve bulacaksınız.


ISO 19650 bağlamında BEP’in omurgasını kurmak

BEP (BIM Execution Plan), ISO 19650 terminolojisiyle bilgi yönetimi yaklaşımını tanımlamak için kullanılan temel dokümandır. Ancak pratikte BEP’i bir “kapsam dokümanı” gibi ele almak, proje ilerledikçe ciddi tutarsızlık üretir.

Sağlam bir BEP omurgası kurmak; bilgi teslimatlarını tanımlamak, süreç sorumluluklarını eşlemek ve doküman setini “kullanılabilir” hale getirmekle başlar. Buradaki amaç, ekiplerin BEP’i yalnızca ihale aşamasında değil, teslimata kadar düzenli olarak kullanmasıdır.

BEP bölümlerini bilgi yönetimi akışıyla hizalamak

BEP yapısını tasarlarken, bölümleri klasik “genel bilgiler” sıralamasıyla değil; CDE akışı, onay döngüsü ve teslimat paketleriyle hizalamak gerekir. Böylece BEP, bir doküman olmaktan çıkıp işleyen bir proje protokolüne dönüşür.

  • Proje bilgi hedeflerini tanımlamak
  • Bilgi gereksinimlerini eşlemek (OIR/AIR/PIR/EIR)
  • Rolleri ve sorumlulukları netleştirmek
  • CDE durumlarını ve geçişlerini açıklamak
  • Doküman hiyerarşisini ve adlandırmayı standardize etmek

Proje rollerini RACI ile şeffaflaştırmak

ISO 19650’de rollerin isimleri kadar, rollerin hangi çıktılardan sorumlu olduğu da kritiktir. BEP içinde RACI yaklaşımını kullanmak; kimin ürettiğini, kimin kontrol ettiğini, kimin onayladığını netleştirmekle sonuçlanır.

Bu şeffaflık, özellikle çok disiplinli ekiplerde revizyon ve onay karmaşasını azaltır. Ayrıca bilgi teslimatlarının gecikmesini önleyerek CDE akışının tıkanmasını engeller.

BIM proje ekibinin ortak ortamda BEP bölümlerini rollerle eşleştirerek çalışma düzenini oluşturması

CDE katmanlarını doküman hiyerarşisine bağlamak

ISO 19650’nin en kritik bileşenlerinden biri CDE’dir. CDE, sadece bir dosya deposu değildir; bilgi üretiminin durumlara göre yönetilmesini sağlayan bir sistemdir. Bu nedenle doküman hiyerarşisi tasarlarken CDE katmanlarını doğrudan yansıtmak gerekir.

Genellikle dört ana durumla çalışılır: Work In Progress, Shared, Published ve Archived. Bu durumlar yalnızca klasör ismi değil, onay akışının kendisidir.

Work In Progress ve Shared ayrımını doğru yapmak

En sık yapılan hata, WIP ve Shared alanlarını aynı hiyerarşide karıştırmaktır. WIP, disiplin içi üretim alanıdır; Shared ise disiplinler arası koordinasyon alanıdır. Bu ayrımı net yapmak, çakışmaları azaltır ve sorumluluğu görünür kılar.

Örneğin bir mimari modelin WIP’te üretilmesi ve kontrol sonrası Shared’a aktarılması, BEP içinde tarif edilen kontrol prosedürleriyle birebir örtüşmelidir.

Published alanını teslimat paketi mantığıyla kurmak

Published alanı, çoğu ekipte “final” klasörü gibi ele alınır. Oysa ISO 19650’de Published, bir teslimat paketinin resmileşmiş halidir. Bu nedenle Published hiyerarşisini; teslimat tarihleri, bilgi teslimat paketleri ve onay kayıtlarıyla ilişkilendirmek gerekir.

{
  "CDE": {
    "WIP": ["ARC", "STR", "MEP"],
    "SHARED": ["COORDINATION", "CLASH", "ISSUES"],
    "PUBLISHED": ["DELIVERY_PACKAGES", "CLIENT_ISSUES"],
    "ARCHIVED": ["SUPERSEDED", "OLD_REVISIONS"]
  }
}

Doküman hiyerarşisini disiplin ve teslimat mantığıyla kurmak

Doküman hiyerarşisi kurmak, yalnızca klasör isimlerini seçmek değildir; bilgi üretiminin mantığını kurmaktır. ISO 19650’de hedef, herkesin aynı “bilgi konumunu” aynı şekilde bulabilmesidir.

İyi bir hiyerarşi; disiplin, sistem, paket, durum ve revizyon mantığını birlikte taşır. Bu sayede hem insan gözüyle hem de yazılım araçlarıyla yönetilebilir hale gelir.

Disiplin bazlı kök yapıyı tasarlamak

Başlangıçta disiplin bazlı bir kök yapı kurmak, ölçeklenebilirlik sağlar. Ancak bu kök yapının altında “proje aşaması” veya “teslimat paketi” gibi bir ikinci katman daha gereklidir. Sadece disiplinle sınırlı bir yapı, ilerleyen aşamalarda dosya kalabalığına yol açar.

Teslimat paketlerini standart isimlerle yönetmek

Teslimat paketleri, hem BEP’in hem de doküman hiyerarşisinin kalbidir. Paket isimleri serbest bırakıldığında, aynı teslimat farklı ekiplerde farklı şekilde adlandırılır. Bu da raporlama ve denetim süreçlerini zayıflatır.

Bu yüzden paketleri belirli bir şablonla kodlamak; teslimatların izlenmesini, otomasyonların çalışmasını ve kalite kontrollerinin uygulanmasını kolaylaştırır.

Disiplinlere ayrılmış klasör yapısının teslimat paketleriyle birlikte okunabilir şekilde düzenlenmesi

Adlandırma standardını kurmak ve dosya isimlerini yönetmek

ISO 19650’nin en somut çıktılarından biri adlandırma standardıdır. Çünkü adlandırma, dokümanın kimliğidir. İyi bir adlandırma standardı; arama yapılmasını, filtrelenmesini, otomatik kontrol edilmesini ve raporlanmasını sağlar.

Burada amaç, herkesin “kendi mantığıyla” dosya isimlendirmesini engellemek değil; ekiplerin hızını düşürmeden tutarlı bir şema uygulamak olmalıdır.

ISO 19650 dosya adı bileşenlerini sabitlemek

Tipik bir ISO 19650 dosya adı; proje, originator, volume/system, level/location, type, role ve number bileşenlerini içerir. Bu bileşenleri BEP içinde sabitlemek, hem eğitim ihtiyacını azaltır hem de yeni katılan ekip üyelerinin adaptasyonunu hızlandırır.

Revizyon ve durum kodlarını süreçle eşlemek

Revizyon kodu tek başına yeterli değildir; durum kodu (S0, S1 vb.) ile birlikte anlam kazanır. Bu kodları BEP’in kontrol ve onay prosedürüyle eşlemek, “dosya güncel mi?” tartışmasını bitirir.

PRJ-ORG-ZZ-00-DR-A-0001_S1_P01.pdf
PRJ-ORG-ZZ-00-M3-A-0002_S2_P02.ifc
PRJ-ORG-ZZ-00-MD-A-0100_S0_P01.rvt

Bu örneklerde görüldüğü gibi, durum kodu (S1, S2) bilgi paylaşım seviyesini; revizyon kodu (P01, P02) ise iterasyonu temsil eder. Bu ayrımı doğru kurmak, teslimat sürecini daha öngörülebilir hale getirir.


BEP doküman setini yaşayan bir sistem haline getirmek

BEP’in en büyük riski, bir kere hazırlanıp rafa kaldırılmasıdır. ISO 19650’ye uyumlu çalışmak isteyen ekipler, BEP’i yaşayan bir sistem haline getirmek zorundadır. Bunun yolu, BEP’i tek bir doküman olarak değil, bir doküman seti olarak ele almaktır.

Örneğin “BEP ana dokümanı” yanında, adlandırma standardı, CDE prosedürü, kontrol listeleri ve teslimat paket şablonları gibi ekleri ayrı yönetmek; güncelleme yapılmasını kolaylaştırır.

BEP eklerini sürümleyerek yönetmek

BEP ekleri, ana dokümandan daha sık değişir. Bu yüzden ekleri ayrı sürümleyerek yönetmek; küçük güncellemelerin BEP’in tamamını bozmasını önler. Ayrıca denetimlerde hangi tarihte hangi ekin geçerli olduğunu göstermek kolaylaşır.

Kontrol listeleriyle kaliteyi standardize etmek

Kalite kontrol, kişisel deneyime bırakıldığında tutarsızlık üretir. BEP içinde standart kontrol listeleri tanımlamak; model kontrolü, doküman kontrolü ve teslimat kontrolünü ölçülebilir hale getirir. Böylece “kontrol edildi” ifadesi somut bir anlam kazanır.

Bu noktada ekiplerin BEP’i daha hızlı uygulayabilmesi için eğitim içeriğiyle desteklenmesi önemlidir. ISO 19650 süreçlerini uçtan uca anlamak için ISO 19650 BIM eğitimi sayfasındaki akışları inceleyebilirsiniz.

Kalite kontrol listeleri ve sürüm kayıtlarıyla BEP eklerinin yönetilmesini gösteren çalışma ekranı

Uygulama planını çıkararak ekipleri hizalamak

Bir BEP yapısı ve doküman hiyerarşisi kurulduktan sonra, asıl iş bunun uygulanmasını sağlamaktır. Burada kritik olan, tüm ekibin aynı anda “mükemmel” uygulamasını beklemek değil; kademeli bir geçiş planı hazırlamaktır.

Uygulama planı; pilot disiplin seçmek, şablonları devreye almak, kontrol noktalarını tanımlamak ve geri bildirim döngüsü kurmakla ilerler. Bu yaklaşım, direnci azaltır ve standardın benimsenmesini hızlandırır.

Pilot disiplinle başlayarak kademeli yaygınlaştırmak

İlk günden tüm disiplinlerde tam standardizasyon beklemek, çoğu projede gerçekçi değildir. Bunun yerine bir pilot disiplin seçmek, doküman hiyerarşisini test etmek ve BEP eklerini sahada doğrulamak daha sağlıklıdır.

Otomasyon noktalarını belirleyerek sürdürülebilirlik sağlamak

Adlandırma kontrolü, klasör yerleşimi kontrolü ve teslimat paket kontrolü gibi noktalar, otomasyonla desteklenebilir. Bu otomasyonları BEP içinde tarif etmek, “kişiye bağlı” kontrol süreçlerini azaltır.

Sonuç olarak ISO 19650’ye uygun BEP yapısı ve doküman hiyerarşisi kurmak; sadece düzen değil, proje boyunca sürdürülen bir yönetim alışkanlığıdır. Doğru kurulduğunda ekiplerin koordinasyonunu hızlandırır, teslimat kalitesini artırır ve denetim süreçlerini kolaylaştırır.

 CADSAY