PRIMAVERA P6'DA CLAIM DELAY ANALİZİ İÇİN VERİ HAZIRLAMAK

Primavera P6'da claim delay analizi için veri hazırlamak, bir gecikme talebinin dayanacağı programı hukuki delil niteliğine kavuşturmak demektir; bir delay claim'in başarısı sahadaki olaydan değil, olayın programa nasıl işlendiğinden gelir. Seçilen analiz yöntemi belirli bir kayıt seti ister, bu set hazırlık aşamasında doğru kurulmadıysa hangi yöntem seçilirse seçilsin analiz çürür. Bu yazıda AACE 29R-03 yöntem seçimini, baseline kilitleme, contemporaneous updates arşivi, fragnet hazırlığı, calendar ve constraint disiplini ile saha kayıtlarının programa eşlenmesini bulacaksınız.

1. YÖNTEM SEÇİMİ — HANGİ VERİYE NE YETERLİ?

Veri hazırlığına başlamadan önce dosyanın hangi analiz yöntemini destekleyeceği belirlenir. Yöntem seçimi yapılmadan toplanan veri çoğu zaman ya eksik kalır ya da gereksiz şişer. AACE 29R-03 yöntemleri iki ekseninde sınıflandırır: gözlemsel mi modellenmiş mi, statik mi dinamik mi. Bu yöntem tasnifi AACE Recommended Practices kütüphanesinde belgelenmiştir; Türk yapım ihaleleri pratiği bu ayrımı 4735 sayılı Kamu İhale Sözleşmeleri Kanunu ve YİGŞ çerçevesinde benzer mantıkla uygular.

• As-Planned vs. As-Built (MIP 3.1): Sadece baseline ile fiili programın yan yana konması. Küçük işler, az olay sayısı. Veri olarak iki XER dosyası yeterlidir.
• Contemporaneous Period Analysis (MIP 3.3): Aylık güncelleme arşivinin pencerelere bölünüp her pencerede kritik yol değişiminin izlenmesi. Orta-büyük projelerde Türk idarelerinin en çok ikna olduğu yöntem.
• Impacted As-Planned (MIP 3.6): Baseline'a gecikme olaylarını temsil eden fragnetlerin eklenmesi, prospektif etki simülasyonu. Erken claim'lerde kullanılır; data date baseline'dan uzaklaştıkça doğruluğu düşer.
• Time Impact Analysis (MIP 3.7): Periyodik güncellemelere fragnet ekleyerek dinamik etki ölçümü. Çok sayıda olayın olduğu uzun süreli projelerde altın standart kabul edilir.
• Collapsed As-Built (MIP 3.8): Fiili programdan gecikme aktivitelerini çıkararak "olmasaydı ne olurdu" tarihinin hesaplanması. Manipülasyona açık olduğu için idareler nadiren kabul eder.

FIDIC Kırmızı Kitap madde 8.4 (extension of time) ve Society of Construction Law Delay and Disruption Protocol, MIP 3.3 ve 3.7'yi öncelikli olarak işaret eder; Türk pratiğinde Kamu İhale Kurumu kararlarında atıf yapılan yöntemler de bu iki yapıdadır. Veri hazırlığı bu seçim üzerinden çatlatılır: az aylık güncelleme arşivi olan bir proje TIA'ya zorlanırsa, eksik veri ileride dosyayı çürütür.

2. BASELINE — KİLİTLENMEMİŞ PROGRAM CLAIM'DE DELİL DEĞİLDİR

Baseline (referans program), claim'in zaman matematiğinin sıfır noktasıdır. Onaylanmamış veya sonradan değiştirilen bir baseline, hangi yöntem uygulanırsa uygulansın savunulamaz. Türk yapım ihalelerinde "onay" aşaması ihale dosyasında zaman zaman muğlak bırakıldığı için pratikte üç katmanlı bir koruma kurulur.

• Sözleşmenin yürürlüğe girdiği gün baseline XER olarak dışa aktarılır, e-posta ile idareye iletilir ve KEP üzerinden bildirimi yapılır.
• Aynı dosya hash değeri (SHA-256) hesaplanıp bildirim yazısına eklenir; sonradan dosyanın değiştirilmediği doğrulanabilir.
• Primavera tarafında Project > Maintain Baselines üzerinden "Original Contract Baseline" etiketiyle saklanır; Project > Assign Baselines'da Project Baseline ve Primary User Baseline olarak atanır.

Baseline'ın saklanması kadar "ne zaman güncellenmeyeceği" kuralı da önemlidir. Sözleşme tadilatı veya kabul edilmiş ek protokol olmadan baseline değiştirilmez. Bazı projelerde proje yöneticisi her ay baseline'ı "tazelediği" için claim aşamasına gelindiğinde orijinal program bulunamaz; mahkeme veya tahkim önünde tarafların hangi planı tartıştığı bile belirsizleşir. Detaylı baseline yönetimi disiplinini sahada oturtmak için bir primavera eğitimi sürecinde Maintain Baselines, Restore Baseline ve Schedule Comparison komutlarının pratikle birlikte öğrenilmesi gerekir.

3. CONTEMPORANEOUS UPDATES NEDEN AYLIK ARŞİVİN İSKELETİDİR?

Contemporaneous (eş zamanlı) güncellemeler, claim verisinin omurgasıdır. Her veri tarihinde alınan snapshot, daha sonra hangi olayın hangi pencerede etki ettiğini gösterir. AACE 29R-03 dinamik yöntemlerin tamamı (MIP 3.3, 3.4, 3.7) aylık update arşivine dayanır. Türk projelerinde aylık hakediş döngüsüyle çoğu zaman zaten aylık güncelleme yapılır; eksik olan disiplinli arşivleme.

Her güncellemede dört temel alan eksiksiz doldurulur: Actual Start, Actual Finish, Remaining Duration ve Physical % Complete. Tools > Schedule (F9) çalıştırılırken Data Date doğru ay sonu tarihine çekilir. Aksi takdirde program eski mantıkla yeniden hesaplanır ve aylık snapshot anlamsızlaşır.

Aylık update'in her ay aynı kişi tarafından, aynı disiplinle alınması da kritik. Şirket içinde planlama mühendisi değişikliği yaşandığında devir teslim tutanağına son baseline ve son üç ayın update XER'leri eklenir. Bu zincir kopmadığı sürece üç yıl sonra bile pencere analizi yapılabilir.

4. FRAGNET NASIL HAZIRLANIR?

Fragnet (fragmented network), claim olayını programa temsil eden aktivite kümesidir. TIA ve Impacted As-Planned yöntemlerinin teknik kalbidir. Hatalı fragnet, doğru olayı bile yanlış sonuca götürür.

Fragnet hazırlarken takip edilen disiplin:

1. Olayın yaşandığı tarihten bir önceki ay sonu update'i seçilir; bu update fragnet'in işleneceği taban olur.
2. Activities ekranında yeni bir WBS düğümü açılır; adı "CLAIM-EVT-{tarih}" gibi konvansiyonel bir kodla tutulur.
3. Olayı temsil eden aktiviteler eklenir: "İdare proje revizyonu beklemesi", "Beklenmeyen zemin koşulu kazı durması" gibi.
4. Bu aktivitelerin süreleri olay süresine eşit girilir; calendar olarak proje takvimi atanır.
5. Predecessor olarak olayın etki ettiği gerçek aktivite gösterilir; ilişki tipi FS, SS veya FF olay mantığına göre seçilir.
6. Successor olarak olayın bittikten sonra başlayabilen aktivite işaretlenir.
7. Schedule (F9) çalıştırılır; fragnet öncesi ve sonrası tamamlanma tarihi karşılaştırılır.

Fragnet aktivitelerine constraint koymak en sık görülen hatadır. "Start On" veya "Mandatory Finish" ile zorlanmış bir fragnet, gerçek mantıksal etkiyi göstermez; karşı taraf analizcisi bunu hemen ayıklar. Fragnet'in CPM mantığıyla doğal akması gerekir; ne kadar şeffaf olursa savunulması o kadar kolaylaşır.

5. VERİ NASIL FİLTRELENEBİLİR HALE GELİR?

Claim hazırlığının saha tarafı kadar veri yapısı tarafı vardır. Activity codes ve kaynak atamaları doğru kurgulanmadığında, üç yıl sonra binlerce aktivite arasından olayın etki ettiği imalatı izole etmek mümkün olmaz.

Bir delay claim için minimum activity code seti:

• DISIPLIN: Mimari, Statik, Mekanik, Elektrik, Çevre
• BOLGE: A Blok, B Blok, Çevre Düzenleme
• SORUMLU: Yüklenici, İdare, Müşavir, Yapı Denetim
• CLAIM_KAT: Mücbir, İdare kaynaklı, Tedarik, Hava muhalefeti, Sürpriz zemin
• ETKI_TIPI: Süre, Maliyet, Hem süre hem maliyet

Enterprise > Activity Codes menüsünden tanımlanır; aktivite başına Activities > General sekmesinde Activity Code Values üzerinden atanır. Bu yapı kurulduğunda, ileride "İdare kaynaklı + Statik disiplini + B Blok" filtresi tek tıklamayla çalışır; rapor saniyeler içinde çıkar.

Kaynak tarafında Labor (işçilik), Nonlabor (ekipman) ve Material (malzeme) ayrımı zorunlu. Sadece süre uzatımı talep ediliyorsa kaynak isteğe bağlı; ek maliyet, prolongasyon veya verimlilik kaybı talep ediliyorsa Budgeted Units / Actual Units karşılaştırması olmadan dosya yarım kalır. Türk pratiğinde YİGŞ ek maliyet kalemini sınırladığı için kaynak verisi çoğu zaman sözleşme kapsamında değil; ancak tahkim veya uluslararası proje senaryolarında devreye girer.

6. CALENDAR DİSİPLİNİ — "BİR GÜN" HANGİ GÜN?

Calendar (takvim) atamaları çoğu projede arka planda kalır ama claim analizinde belirleyici hale gelir. "Olay 7 gün sürdü" ifadesi hangi calendar'da 7 gündür? Standart 5 günlük iş haftası takviminde 7 gün, 7 günlük tam takvimde 7 günden farklı bir takvim süresine denk gelir.

Bir projede genellikle üç calendar bulunur:

• Standart İş Takvimi: Pazartesi-Cumartesi, hafta içi 9 saat, hafta sonu 5 saat. Genel imalat aktiviteleri için.
• 7 Gün Takvimi: Beton kürü, kuruma süreleri, kimyasal reaksiyonlar için. Hafta sonu da çalışıyor sayılır.
• İdare Takvimi: Resmi tatiller dahil sadece çalışma günleri. Onay süreleri, revizyon beklemeleri için.

Enterprise > Calendars menüsünden tanımlanır; her aktiviteye Activities > General sekmesinde Activity Calendar alanından atanır. Türk projelerinde dini bayramlar ve resmi tatiller (29 Ekim, 23 Nisan, 19 Mayıs) calendar'a tek tek girilir; ayrıca proje özelinde yer teslimi tarihine kadar olan dönem "ön hazırlık takvimi" olarak ayrı tutulabilir.

Calendar disiplini olmayan bir programda claim hazırlanırken "9 günlük gecikme" ifadesi savunulamaz; karşı taraf takvim manipülasyonu iddia eder. Aynı olay üç farklı calendar'da farklı gün sayısı verir; hangi calendar'da hesaplandığı dosyada açıkça yazılır.

7. CONSTRAINT TEMİZLİĞİ — KRİTİK YOLU YALAN SÖYLETMEMEK

Constraint (kısıt), Primavera'nın aktivitelere atayabildiği tarih zorlamalarıdır. Sert kısıtlar (Mandatory Start, Mandatory Finish, Start On) CPM mantığını ezer; aktivitenin gerçek lojik bağı yerine kullanıcının istediği tarihi gösterir. Claim verisinde temizlenmemiş constraint, dosyanın en sık çürüdüğü noktadır.

Claim öncesi constraint denetimi şu sırayla yapılır:

1. View > Filter By > Activities With Constraints filtresi uygulanır.
2. Listelenen aktivitelerin her biri için constraint gerekçesi sorgulanır.
3. Sözleşmesel zorunluluk (örn. milestone teslim tarihi) içermeyen sert kısıtlar kaldırılır.
4. Yumuşak kısıtlar (Start On or After, Finish On or Before) gerekçeli not olarak Activity Notebook'a yazılır.
5. Schedule (F9) yeniden çalıştırılır; kritik yolun değişip değişmediği gözlemlenir.

Constraint kaldırma sırasında Activity Notebook'a "Claim hazırlığı için constraint kaldırıldı, gerekçe X" notu eklenir. Bu not denetim mühendisi veya tahkim heyeti tarafından sorgulandığında programcının niyetini belgeler. Notebook'a not yazma alışkanlığı olmayan ofislerde bu adım atlanır ve karşı taraf manipülasyon iddiasıyla dosyayı zayıflatır.

8. SAHA KAYITLARI PROGRAMA NASIL EŞLENİR?

Programdaki sayıların hukuki ağırlığı saha kayıtları ile birlikte doğar. Aylık update ne kadar disiplinli alınırsa alınsın, arkasında saha kayıtları olmayan bir XER dosyası mahkeme veya tahkim önünde tek başına yeterli değildir. Türk pratiğinde kontrol mühendisi tutanağı, yapı denetim raporu ve şantiye günlüğü bu üçüncü taraf delilini oluşturur.

Veri hazırlığında program ile saha kaydının eşleştirilmesi:

• Her olay için Activity Notebook'a olay tarihi, kontrol mühendisi tutanak numarası ve fotoğraf klasör yolu yazılır.
• Saha günlüğüne her gün işçi sayısı, hava durumu, ilerleyebilen-ilerleyemeyen kalemler tek tek işlenir; geriye dönük doldurulan günlükler mürekkep yaşından tespit edilir.
• Drone veya fotoğraf çekimlerinde metadata korunur; tarih ve GPS bilgisi silinmemiş olmalı.
• İdare ile yapılan yazışmaların KEP veya iadeli taahhütlü posta üzerinden tebliğ tarihleri saklanır; sadece dosya kopyası değil idare evrak numarası ile birlikte.

Kamu İhale Kurumu uyuşmazlık kurul kararlarında bu zincirin nasıl kurulduğu sıkça emsal olarak değerlendirilir. Saha kaydı eksik bir claim, programdaki kritik yol analizi ne kadar kusursuz olursa olsun "ispat yetersizliği" gerekçesiyle reddedilir. Bu nedenle Primavera tarafı kadar saha tarafı disiplini de hazırlık aşamasında kurulur, sonradan tamamlanamaz.

9. DOSYA NASIL KORUNUR?

Hazırlanan baseline, aylık update'ler ve claim öncesi fragnet'li versiyon üç ayrı klasörde arşivlenir. Her XER dosyası yanında PDF Gantt çıktısı ve Excel detay listesi tutulur. Tek format yetmez; XER native veriyi taşır, PDF görsel tutarlılığı gösterir, Excel filtrelenebilir özet sunar.

Sürüm meselesi de ayrı bir konu. Primavera sürümleri arasında XER formatı geriye dönük uyumlu değildir; yeni sürümden ihraç edilen dosya eski sürümde açılmayabilir. Tahkim veya mahkeme heyetinin elinde olan sürüm bilinmediğinden, dosya export edilirken Tools > Compatibility Mode düşük sürüm uyumluluğu seçilir; alternatif olarak XML format paralel olarak saklanır.

Arşiv klasör yapısı sade tutulur: "01_Baseline", "02_Updates" (alt klasör her ay), "03_Claim_Hazirlik" (fragnet'li versiyonlar), "04_Saha_Kayitlari". Klasör adlarında Türkçe karakter olmaması ileride sistem değişikliklerinde sorun çıkmasını engeller. Aynı arşivin iki kopyası saklanır: biri şirket sunucusu, diğeri bağımsız bulut servisi.

10. VERİ HAZIR — SIRA HUKUKİ STRATEJİDE

Baseline kilitli, aylık update'ler kronolojik dizilmiş, activity codes ile filtreleme yapılabilir, calendar atamaları net, constraint'ler temizlenmiş, fragnet hazırlığı yapılabilir, saha kayıtları program ile eşleşmiş durumda. Bu altı katmanlı veri seti tamamlandığında AACE 29R-03'ün hangi yöntemiyle (3.1, 3.3, 3.6, 3.7 veya 3.8) çalışılacağı hukuk müşaviri ile birlikte kararlaştırılır.

Pratikte gözlenen şu: veri hazırlığı sözleşme imzasından itibaren günde 15-20 dakika ek disiplin gerektirir; aylık update'te bir ek saat ister. Bu küçük yatırım, claim aşamasında üç-altı hafta süren forensic schedule analysis sürecini bir-iki haftaya indirir. Saha mühendisinin günlük disiplini, üç yıl sonra avukatın elindeki dosyanın gücüdür. Programın konuştuğu yer sözleşmenin imzalandığı gün değil, baseline'ın kilitlendiği saniyeden itibaren her geçen gündür.