Proje Dosya & Versiyon Arşivi (DWG, PDF, BIM)

Bu sistem, bünyesinde birden fazla mimar veya mühendis çalıştıran ve aynı proje dosyaları üzerinde paralel değişiklik yapan her büro için tasarlanmıştır. Ekip küçük olsa bile tek bir yanlış versiyon şantiyeye gittiğinde yaratacağı maliyet, sistemin bedelini fazlasıyla aşar. son_final_v3_GERÇEK.dwg gibi isimli dosyaların varlığı, büronun hâlâ insan hafızasına ve dosya ismine dayalı versiyon takibi yaptığını gösterir; bu yöntem büyüdükçe kaçınılmaz olarak çöker.

Özellikle şu profiller için kritik değer üretir:

• Mimarlık ofisleri: Ön tasarımdan uygulama projesine kadar onlarca revizyon geçiren ve her revizyonun izini kaybeden ofisler; özellikle aynı projeyi birden fazla mimarın aynı anda güncellediği yapılar. Bir mimar kolon yerini değiştirirken diğeri aynı paftanın başka katmanını güncelliyorsa, hangisi diğerinin üstüne yazdığını ancak şantiyede hata ortaya çıkınca anlarsınız.
• Mühendislik büroları: Statik hesap dosyaları, mekanik şemalar ve elektrik projeleri gibi farklı disiplin çizimlerini ortak bir havuzda tutmak isteyen, koordinasyon sırasında hangi disiplinin son versiyonu gönderdiğini bilmek zorunda olanlar. Yanlış paftadan imalat maliyeti mimarlıkta onlarca bin lira; mühendislikte bu rakam çok daha yüksek olabilir.
• Yapı denetim firmaları: Denetlediği projenin hangi çizim versiyonu üzerinden onay verdiğini hukuki olarak belgelemek isteyen firmalar. Saha kontrolü ile ofis arşivi arasındaki versiyon farkı, denetim sorumluluğunu belirsizleştirir.
• BIM kullanan ofisler: IFC ve Revit dosyalarının versiyon geçmişini otomatik kayıt altına almak, farklı modelleme yazılımlarından gelen dosyaları tek havuzda yönetmek isteyen ofisler. BIM koordinasyonunda hangi model versiyonunun çakışma analizinde kullanıldığı kaydedilmelidir.

Dropbox, Google Drive veya OneDrive gibi genel amaçlı bulut araçları dosya versiyonlama konusunda mimarlığın ihtiyaçlarını karşılamaz: DWG önizleme, proje bazlı erişim kontrolü, 'bu versiyon geçerli' işareti veya şantiye ekibine sadece onaylı versiyonun görünmesi gibi özellikler yoktur. Bu sistem bu boşlukları mimarlık iş akışına özgü biçimde doldurur.

Mimarlık bürolarındaki çizim kaosunun somut maliyeti şudur: yanlış versiyondan yapılan imalat, şantiyede yıkım ve yeniden yapım anlamına gelir. Bu kriz bürodan büroya değil, aylık veya yıllık sıklıkla yaşanır ve her defasında hem büro-müşteri ilişkisini hem de proje bütçesini zedeler.

Sorunun anatomisi:

• 'son_final_GERÇEK' sendromu: Dosya isimlendirmesi kişiden kişiye değişir; mimar kendi klasöründe 'final' olarak kaydettiğini sunucuya yanlış klasöre kopyalar. Şantiye ustası en son gelen e-posta ekini açar — bu versiyon iki revizyon eskidir. Aradaki fark bir kapı boyutu veya kolon ekseni kadar kritik olabilir; hata ancak beton döküldükten sonra ortaya çıkar.
• Paralel düzenleme çatışması: İki mimar aynı dosyayı aynı anda değiştirir; biri diğerinin üstüne yazar. Değişiklik kaybolur, kim ne yaptı bilinemez. En kötü senaryoda bu çatışma hem dosyayı bozar hem de hangisinin doğru olduğunu kimse bilemez.
• Revizyon geçmişinin yokluğu ve maliyet: Müşteri 'geçen hafta gönderdiğiniz çizimde pencere 1,20 genişliğindeydi, şimdi neden 0,90?' diyebilir. Eski versiyona ulaşmak saatler alır ya da mümkün olmaz. Yanlış paftadan imalat başladığında hem yıkım hem yeniden yapım maliyeti doğar; sorumluluk belirsizleşir ve hukuki süreç başlar.
• Yetkisiz erişim ve erken imalat: Şantiye şefi ya da taşeron, henüz onaylanmamış çizim versiyonuna ulaşır ve imalatı başlatır. Onay sürecinin dışından geçen çizimler sahada kargaşa ve yeniden yapım maliyeti yaratır.
• Depolama dağınıklığı ve personel riski: Projeler farklı kişilerin bilgisayarlarında, USB belleklerde ve bir kısmı bulutta, bir kısmı yerel sunucuda tutuluyor. Çalışan ayrılınca dosyalar kaybolabiliyor; büronun yıllarca biriktirdiği çizim arşivi tek bir istifayla erişilemez hale gelebiliyor.

Bu sistem her dosya kaydedildiğinde otomatik versiyon numarası atar, değiştiren kişiyi ve zamanı kaydeder, 'geçerli versiyon' işareti belirlenmeden şantiye ekibine görünmez ve tüm geçmiş versiyonlara tek tıkla ulaşılabilir. Yanlış versiyonun şantiyeye gitmesi teknik olarak olanaksız hale gelir. Müşteri 'geçen hafta gönderdiğiniz çizimle bu arasındaki fark nedir' diye sorduğunda hangi versiyonun ne zaman kime gönderildiği sistemden anında cevaplanır; saatler süren e-posta araştırması tarihe karışır.

1. Keşif ve dosya yapısı analizi (1–2 hafta): Büronuzun mevcut dosya klasörleme mantığı, kullandığınız yazılımlar (AutoCAD, Revit, ArchiCAD, SketchUp) ve şantiye ekibiyle dosya paylaşım yöntemi belgelenir. Hangi dosya formatlarının öncelikli destekleneceği ve mevcut isim kuralları incelenir; yeni hiyerarşi önerisi sunulur.
2. Sistem mimarisi tasarımı (1–2 hafta): Proje/disiplin/aşama klasör hiyerarşisi, erişim rolleri (büro ortağı, proje müdürü, mimar, taşeron, müşteri) ve 'geçerli versiyon' onay akışı tasarlanır. Hangi rolün yeni versiyon yükleyebileceği, hangisinin yalnızca görüntüleyebileceği netleştirilir.
3. Geliştirme (4–6 hafta): DWG/PDF/IFC önizleme, versiyon numaralandırma motoru, değişiklik geçmişi (kim, ne zaman, hangi dosya), erişim kontrol sistemi, şantiye paylaşım linki (yalnızca geçerli versiyon görünür) ve arama modülü kodlanır. Şantiye linkine süre veya indirme sayısı sınırı uygulanabilir.
4. Mevcut dosyaların aktarımı (1–2 hafta): Aktif projelerinizin dosyaları büronuzun belirlediği klasör yapısına göre sisteme aktarılır; ilk versiyon numaraları atanır. Hangi dosyanın 'geçerli' sayıldığı bu aşamada büro ile birlikte belirlenir.
5. Eğitim ve yayına alma (1 hafta): Tüm ekip için dosya yükleme, versiyon güncelleme, geçerli versiyon işaretleme ve şantiye paylaşımı konularında eğitim verilir. 'Artık dosyayı e-posta ile göndermek yerine şantiye linki paylaşıyoruz' alışkanlığının yerleşmesi için ilk hafta destek görüşmesi dahildir.

Sistem tarayıcı tabanlıdır; şantiyeden mobil cihazla da erişilebilir. Şantiye ekibine yalnızca 'geçerli' işaretli son versiyon gösterilir; geçmiş versiyonlar görünmez. Büro yöneticisi geçerli versiyonu değiştirdiğinde şantiye linki otomatik güncellenir; ekip ayrıca bilgilendirilmek zorunda kalmaz. Yeni bir revizyon yayınlandığında şantiye ekibine otomatik bildirim gönderilebilir; 'eski çizimden imalata devam etmeyin' mesajı sistemden iletilir ve bu mesajın okunup okunmadığı loglanır. Proje tamamlandığında tüm çizim geçmişi arşive taşınır; ileride tadilat veya emsal dava durumunda orijinal uygulama projesine tek tıkla ulaşılır. Yeni bir uygulama projesi revizyonu açıldığında önceki projenin temel paftaları referans olarak sisteme çekilebilir; sıfırdan aramak ve e-postaları taramak yerine arşivden saniyeler içinde getirilir. Büro büyüdükçe ve proje sayısı arttıkça bu arama ve geri getirme hızı günlük verimliliğe doğrudan katkı sağlar. Proje sürecini yeni bir çalışana devretmek de bu arşivle çok daha kolay hale gelir; yeni kişi tüm versiyon geçmişini ve kimin ne değiştirdiğini sistemden okuyabilir.

Proje çizimleri fikri mülkiyet değeri taşır ve yanlış ellere geçmesi hem rekabet açısından hem hukuki sorumluluk açısından zarar verir. Sistem rol tabanlı erişim kontrolü ile her kullanıcıya yalnızca ilgili proje ve disiplin dosyalarını gösterir. Şantiye ekibine paylaşılan bağlantılar süre sınırlı ve indirme kısıtlı olarak yapılandırılabilir; isterseniz filigran eklenerek gönderilir. Yetkisiz kişi şantiye linkini ele geçirse bile yalnızca o projenin geçerli versiyonunu görebilir; büronun tüm arşivine erişimi yoktur.

Tüm dosya işlemleri (yükleme, indirme, silme, versiyon güncelleme) kim, ne zaman, hangi IP'den yaptı şeklinde loglanır. Hukuki süreçte bu log çizimin ne zaman kimde olduğunu kanıtlar; yanlış versiyondan imalat iddiasında büronun hangi versiyonu geçerli ilan ettiği ve şantiye ekibinin o versiyona ne zaman eriştiği belgeden görünür. Veriler Türkiye merkezli sunucuda şifreli olarak saklanır; SSL zorunludur. Silinen dosyalar doksan gün kurtarılabilir arşivde tutulur; kalıcı silme yalnızca yönetici yetkisiyle ve onay adımından sonra gerçekleşir. Yedekleme günlük olarak otomatik alınır; depolama altyapısında arıza olsa bile en fazla yirmi dört saatlik veri kaybı riski söz konusudur ve bu da seçilen altyapıya göre daha kısa sürelere indirilebilir. Proje verilerinin kişisel bilgi içerip içermediğinden bağımsız olarak çizim arşivinin veri kaynağı sayıldığı durumlarda KVKK aydınlatma yükümlülüğü doğabilir; bu konuda büronuzun avukatıyla değerlendirme yapılması önerilir. Sistemin teslimi sırasında tüm güvenlik yapılandırması büroyla birlikte gözden geçirilir; çalışan rolleri ve erişim seviyeleri o aşamada kesinleştirilir. Yeni çalışan ekleme veya ayrılan çalışanın erişimini kapatmak büro yöneticisinin panelinden dakikalar içinde yapılır; IT desteği gerektirmez. Proje bitiminde taşeron veya müşteri erişimi de tek tıkla sonlandırılır.