PRİMAVERA P6’DA CLAİM DELAY ANALİZİ İÇİN VERİ HAZIRLAMAK

Gecikme iddiası (claim) tartışmaları çoğu zaman “kimin hatası”ndan önce “hangi veri doğru” sorusuna takılır. Primavera P6’da planlar, baseline’lar ve güncellemeler doğru kurgulanmadıysa, en iyi analiz yöntemi bile zayıf kanıtla çalışır.

Bu makalede, Primavera P6 claim delay analizi için veri hazırlarken sahada ve ofiste en sık yaşanan kırılmaları, hangi alanların mutlaka standartlaştırılması gerektiğini ve teslim edilebilir bir veri paketinin nasıl çıkarılacağını adım adım ele alacağız.

Hedef, yalnızca P6’dan rapor almak değil; baseline–as-built kıyasını, gecikme kaynaklarını ve kritik yol etkisini savunulabilir şekilde kurabilecek izlenebilir, tekrarlanabilir ve denetlenebilir bir veri seti üretmek.

Analize başlamadan önce veri kapsamını tanımlamak

İyi bir gecikme analizi verisi, “hangi proje takvimi konuşuluyor?” sorusunu tek cümlede cevaplar. Burada ilk iş, inceleme periyodunu (ör. Notice to Proceed–Substantial Completion arası), sözleşme revizyonlarını ve hangi teslim tarihlerinin esas alınacağını netleştirmektir. Kurum içinde gecikme analizine girecek paket genellikle üç katmandan oluşur: (1) plan verisi, (2) ilerleme verisi, (3) kanıtlayıcı doküman eşleştirmesi.

Baseline ve revizyon setini netleştirmek

Claim tartışmalarında en sık problem, birden fazla baseline veya “gizli revizyon” kullanılmasıdır. P6’da Project Baselines alanında hangi baseline’ın “Primary” olduğu, hangi tarihte freeze edildiği ve sonradan değişip değişmediği kontrol edilmelidir. Baseline kopyalandıysa, kopyanın hangi amaçla (tender, contract, recovery) üretildiği de pakete yazılmalıdır.

As-built tanımını sözleşmeye göre doğrulamak

“As-built” bazen gerçek bitiş tarihleri, bazen de kabul tarihleridir. Sözleşme maddeleri ve hakediş ölçütleri ile uyumsuz bir as-built tanımı, analizde hatalı gecikme günleri üretir. Bu yüzden, P6’daki Actual Start/Finish alanlarının hangi dokümanla beslendiğini (günlük rapor, ITP, teslim tutanağı) açık bir eşleştirme tablosuyla göstermek gerekir.

WBS ve aktivite şemasını standardize ederek izlenebilirlik kurmak

Gecikme iddialarında “hangi iş paketi etkilendi?” sorusu kritik olduğu için WBS hiyerarşisi rastgele bırakılamaz. WBS; disiplin, alan, faz veya teslimat bazında tutarlı olmalı ve her aktivite tek bir WBS altında anlamlı bir bağlama sahip olmalıdır. P6’da sonradan WBS taşımak, raporların ve baseline kıyaslarının geriye dönük yorumunu zorlaştırabilir.

Aktivite tiplerini tutarlı hale getirmek

Task Dependent, Resource Dependent, Milestone gibi aktivite tiplerinin yanlış kullanımı, kritik yol ve float hesabını bozar. Özellikle “Start/Finish Milestone” aktiviteleri, sözleşme teslim tarihlerinin kanıtı olduğu için ayrı bir kod yapısıyla yönetilmelidir. Ayrıca LOE (Level of Effort) aktiviteleri gecikme hesabına doğrudan girmeyecek şekilde filtrelenebilir olmalıdır.

Kod yapısını claim odaklı kurgulamak

Aktivite kodları, gecikme kaynaklarını sınıflamak için analizde altın değerindedir. Önerilen minimum kodlar: “Disiplin”, “Lokasyon/Alan”, “Sorumlu Taraf”, “Değişiklik/VO”, “Kısıt Tipi”, “Risk/İş Güvenliği Etkisi”. Böylece belirli bir gecikme sebebinin hangi iş paketlerini nasıl etkilediği tek raporda görülebilir.

• Sorumlu Taraf: İşveren, yüklenici, alt yüklenici, tasarımcı
• Değişiklik/VO: VO numarası, revizyon tarihi, kapsam özeti
• Kısıt Tipi: Permit, erişim, malzeme, tasarım onayı

Takvim, ilişki mantığı ve kısıtları denetleyerek analiz edilebilirlik sağlamak

Claim delay analizi sadece tarihlerden ibaret değildir; tarihler arasındaki mantık (logic) doğru kurulmadıysa sonuçlar savunulamaz. P6’da takvimler (Calendars), ilişki tipleri (FS/SS/FF/SF) ve kısıtlar (Constraints) analiz öncesi kapsamlı şekilde taranmalıdır. Aksi halde, örneğin “Must Finish By” ile kapatılmış bir aktivite, kritik yolun gerçekçi görünmesini engeller.

Calendar kalibrasyonunu tutarlı şekilde yapmak

Çoklu takvim kullanımında (6x10, 5x8, vardiya) gecikme günleri farklı hesaplanabilir. Analizde kullanılacak takvimlerin vardiya, tatil ve istisna günleri, sahadaki fiili çalışma düzeniyle uyumlu olmalıdır. Kalibrasyon belgesi olmadan takvim savunmak zordur; bu yüzden takvim tanımlarını pakete eklemek iyi bir pratiktir.

Kısıt ve açık uçların temizliğini yapmak

“Start On” ve “Finish On” gibi sert kısıtlar, gecikme analizinde “modeli zorlayan” unsurlardır. Gereksiz kısıtlar kaldırılmalı; zorunlu olanlar ise nedenleriyle birlikte (talimat, onay, şantiye erişimi) açıklanmalıdır. Benzer şekilde, “open-ended” aktiviteler (mantıksız başlangıç/bitiş boşlukları) mantık zincirini bozar. Analiz öncesi bir temizlik kontrol listesi şarttır.

Baseline–güncelleme verisini çıkararak karşılaştırılabilir set üretmek

Birçok kurum P6’da düzenli update yaptığını düşünür ama update dosyası baseline ile “aynı evrende” değildir. Claim analizinde, baseline ve her update döneminin ayrı bir snapshot olarak arşivlenmesi gerekir. Bu sayede gecikmenin hangi dönemlerde biriktiği, hangi değişikliklerin kritik yolu etkilediği gösterilebilir.

Update disipliniyle dönemsel snapshot üretmek

Öneri: Her raporlama döneminde “Update YYYY-MM” adında bir kopya oluşturmak veya XER/SQLite export ile arşivlemek. Böylece hem veri donmuş olur hem de sonradan yapılan düzeltmeler geriye dönük tartışma yaratmaz. Kurumsal eğitim içeriklerinde bu disiplinin süreçle bağlanması için Primavera eğitimi içeriğiyle aynı terminolojiyi kullanmak faydalıdır.

Baseline kıyas alanlarını eksiksiz taşımak

Veri paketinde mutlaka bulunması önerilen alanlar: Activity ID/Name, WBS, Original Duration, Remaining Duration, Start/Finish, Actual Start/Finish, Baseline Start/Finish, Total Float, Critical flag, Calendar, Constraints, Relationships (predecessor/successor), Activity Codes. Bu alanlar olmadan “gecikme nereden geldi?” sorusu çoğu zaman yoruma döner.

Yukarıdaki yaklaşım, veri setini yalnızca tek dosya olmaktan çıkarıp, her update dönemini kanıt niteliğinde bir kayıt haline getirir. Bu noktada “as-planned vs as-built” tartışması daha az duygusal, daha çok sayısal hale gelir.

Claim delay analizi için veri temizliği kontrollerini otomatikleştirmek

Veri hazırlama sürecinin en maliyetli kısmı, aynı kontrollerin tekrar tekrar yapılmasıdır. Bu nedenle bir “data quality” kontrol paketi oluşturmak gerekir. P6’dan export edilen veriyi Excel/CSV veya veri tabanı üzerinden kontrol edip raporlamak, hem tutarlılığı hem de denetlenebilirliği artırır. Aşağıdaki örnekler gerçekçi bir başlangıç şablonu sunar.

P6 export şablonunu standardize ederek paylaşmak

Birçok ekip export kolonlarını kişiye göre değiştirir. Claim odaklı çalışmada, tek bir CSV şablonu belirleyip her dönem aynı kolonlarla export almak kritik önem taşır. Aşağıdaki örnek, minimum alan setiyle kullanılabilecek bir export başlığıdır:

ProjectID,ActivityID,ActivityName,WBS,Calendar,Status,OrigDur,RemDur
PlannedStart,PlannedFinish,ActualStart,ActualFinish
BLStart,BLFinish,TotalFloat,CriticalFlag
ConstraintType,ConstraintDate,Predecessors,Successors
RespPartyCode,VOCode,LocationCode

Bu şablon, hem baseline karşılaştırmasını hem de gecikmenin dönemlere dağılımını raporlamayı kolaylaştırır. “Predecessors/Successors” alanlarını tek hücrede saklamak yerine ayrı tablolarla yönetmek daha sağlıklıdır; ancak hızlı paketleme için bu yöntem de kullanılabilir.

Temel kalite kurallarını kodla doğrulayarak uygulamak

Örneğin, “Actual Finish var ama Status ‘In Progress’” veya “Constraint var ama gerekçe kodu boş” gibi hataları otomatik yakalamak, inceleme süresini kısaltır. Aşağıdaki Python örneği, CSV üzerinden basit doğrulamalar yapar ve sorunlu satırları ayrı bir dosyaya ayırır:

import pandas as pd

df = pd.read_csv("p6_export.csv")

issues = []

# 1) ActualFinish doluysa status Completed olmalı
mask1 = df["ActualFinish"].notna() & (df["Status"] != "Completed")
issues.append(df.loc[mask1].assign(Issue="ActualFinish var ama Status Completed değil"))

# 2) Constraint varsa ConstraintType ve Date dolu olmalı
mask2 = df["ConstraintType"].notna() & df["ConstraintDate"].isna()
issues.append(df.loc[mask2].assign(Issue="ConstraintType var ama ConstraintDate boş"))

# 3) Kritiklik bayrağı varsa total float beklenen aralıkta olmalı
mask3 = (df["CriticalFlag"] == 1) & (df["TotalFloat"] > 0)
issues.append(df.loc[mask3].assign(Issue="Kritik işte pozitif float görünüyor, kontrol gerekli"))

out = pd.concat(issues, ignore_index=True) if issues else pd.DataFrame()
out.to_csv("p6_data_quality_issues.csv", index=False)

Bu tarz kontroller, sadece hatayı yakalamakla kalmaz; aynı zamanda “verinin nasıl hazırlandığı”nı gösteren bir yöntem dokümantasyonu üretir. Claim sürecinde metodoloji kadar, metodolojinin uygulanma disiplini de önemlidir.

Değişiklik emirlerini ve kanıt dokümanlarını veriyle eşleştirmek

Delay analizi çoğu zaman VO/Change Order, RFI, shop drawing onayı, permit süreçleri ve işveren talimatlarıyla iç içedir. Bu nedenle P6 verisi tek başına yetmez; aktivite kodları ve doküman kayıtları bir araya getirilmelidir. Buradaki amaç, her gecikme iddiasının “hangi aktivite(ler)”, “hangi tarih aralığı”, “hangi doküman” ile desteklendiğini netleştirmektir.

VO ve RFI izini aktivite kodlarına bağlamak

Aktivite kodunda VOCode ve RespPartyCode gibi alanlar varsa, her VO’nun etkilediği WBS ve aktiviteler tek filtreyle görülebilir. Eğer VO henüz onaylanmadıysa, “Potential VO” olarak ayrı bir kod setiyle izlemek, analizde şeffaflık sağlar. Secondary keyword olarak “baseline karşılaştırması”, “as-built program”, “time impact analysis” ve “kritik yol güncellemesi” gibi ifadeler raporlarda doğal şekilde yer alabilir.

Kanıt matrisi oluşturup veri paketine eklemek

Önerilen kanıt matrisi kolonları: DocID, DocType, IssueDate, ResponseDate, RelatedVO, RelatedActivities, Narrative. Böylece hem teknik ekip hem de karar vericiler, gecikme iddiasının dayanağını hızlıca tarayabilir. Bu matris, P6 export ile birlikte teslim edildiğinde “veri–kanıt” bağı kurulur.

Analiz yöntemine göre veri paketini son haline getirmek

Claim delay analizi için tek bir yöntem yoktur; ancak hangi yöntem seçilirse seçilsin veri paketinin yapısı buna göre düzenlenmelidir. Örneğin, “Time Impact Analysis (TIA)” daha fazla dönemsel snapshot ve değişiklik olaylarının tarihsel izini isterken, “As-Planned vs As-Built” yaklaşımı güçlü baseline doğruluğu ve as-built kanıtı ister. Bu nedenle veri paketini “yöntem bağımsız çekirdek” + “yöntem ekleri” şeklinde tasarlamak iyi bir pratiktir.

TIA için olay temelli veri seti üretmek

TIA’da her olayın başlangıç/bitiş etkisi ve mantık zincirine nasıl eklendiği gösterilir. Bu yüzden, olay tarihleri, ilgili aktiviteler ve mantık değişiklikleri (relationship ekleme/çıkarma) ayrı bir log olarak saklanmalıdır. P6’dan tek seferlik export yerine, her olay öncesi/sonrası snapshot yaklaşımı analizin iskeletini güçlendirir.

As-planned kıyası için kritik yol kanıtını hazırlamak

Bu yaklaşımda “baseline kritik yol” ve “gerçekleşen kritik yol” anlatısı önem kazanır. Toplam float, kritik bayrak, takvim ve kısıtlar birlikte değerlendirilir. İyi hazırlanmış bir paket; “kritik yol neden değişti?” sorusuna, update dönemleri üzerinden iz sürerek cevap verir. Ek olarak, S-curve veya EVMS metrikleri varsa, bunları P6 verisiyle tarihsel olarak uyumlu hale getirmek analiz güvenilirliğini artırır.

Pratik teslim paketi kontrol listesi oluşturarak kapatmak

Son adım, hazırlanmış veriyi “teslim edilebilir” hale getirmektir. Bu, yalnızca dosyaları bir klasöre koymak değil; veri paketinin nasıl üretildiğini, hangi varsayımların yapıldığını ve hangi kontrollerin geçtiğini yazılı hale getirmektir. Aşağıdaki kontrol listesi, en sık istenen teslim kalemlerini toparlar:

1. Primary baseline tanımı, freeze tarihi ve kim tarafından onaylandığı
2. Update snapshot listesi ve her snapshot’ın raporlama tarihleri
3. P6 export kolon şablonu ve alan sözlüğü (data dictionary)
4. Takvim tanımları ve istisna günleri listesi
5. Kısıt raporu, gerekçe kodları ve temizleme notları
6. İlişki (logic) raporu ve open-ended kontrol çıktıları
7. Kanıt matrisi ve VO/RFI eşleştirme tablosu
8. Kalite kontrol scripti çıktısı ve düzeltme kayıtları

Bu paket, claim değerlendirmesinde “veri tartışması” yerine “yorum tartışması” yapılmasını sağlar. Ayrıca kurum içinde süreç olgunluğu yaratır: sonraki projelerde aynı veri standardı tekrar edilir ve analizler daha hızlı sonuçlanır.

Özetle, Primavera P6 claim delay analizi için veri hazırlamak; doğru baseline seçimi, disiplinli update snapshot’ları, mantık–takvim–kısıt denetimi ve otomatik kalite kontrolleriyle mümkün olur. Bu yaklaşım, hem teknik ekiplerin analiz üretmesini hem de karar vericilerin sonuçlara güvenmesini kolaylaştırır.