PRIMAVERA P6'DA BASELINE VE SAPMA ANALİZİNİ YÖNETMEK

Bir baraj inşaatında planlama mühendisi sayıştay denetçisinin önünde duruyor. Denetçi soruyor: "Sözleşme baseline'ınız hangi tarihte donduruldu, hangi revizyondan sonra yeniden basıldı, hangi BL'ye karşı %18 sapmayı raporladınız?" Bu sorunun cevabı ya P6 veritabanındaki "BL01 - Sözleşme" snapshot'unun tarih damgasında yatar ya da hiçbir yerde. Baseline disiplini olmayan bir programlama dosyası, denetçi karşısında hızla bir savunma açığına dönüşür.

Baseline'ın amacı kaymayı raporlamak değil, kaymanın hangi orijinal plana göre olduğunu yasal olarak kanıtlamaktır. P6 bu konuda klasik MS Project mantığından ayrılır: dört ayrı baseline kanalını aynı anda yan yana taşır, her birinde sözleşme, revize ve "what-if" senaryolarını eşzamanlı tutar. Oracle'ın ürün dokümantasyonunda bu yapı ayrıntılı anlatılır; aşağıdaki bölümler sahadaki uygulama tarafına odaklanır.

Baseline Saklamak Neden Sözleşmesel Bir Yükümlülük?

Türk kamu inşaat sözleşmesinde baseline bir "iyi olsa hoş olur" değildir. Yapım İşleri Genel Şartnamesi'nin (YİGŞ) iş programı maddesi, idare onayından geçmiş ilk programın değiştirilemez bir referans olduğunu açıkça söyler. Süre uzatımı talebi, ceza muafiyeti, ek keşif onayı — hepsi bu referansa karşı ölçülen sapma üzerinden değerlendirilir.

KGM, DSİ ve büyük belediye yapı işleri ekiplerinde mühendisin sorumluluğu üç katmandır:

• Sözleşmenin ekinde sunulan orijinal P6 dosyasını XER veya PDF olarak donmuş halde arşivlemek
• Onaylanan her revizyondan önce dosyanın o anki halini ayrı bir baseline olarak P6 veritabanına saklamak
• Aylık ilerleme raporunda hangi BL'ye karşı sapma okunduğunu açıkça belirtmek

Sayıştay denetiminde sıkça karşılaşılan bulgu şudur: yüklenici "iş 42 gün gecikti" diyor, idare "sözleşme baseline'ında bu aktiviteler farklı sıralanmıştı" diyor, kimse iki ay önceki dosyayı bulamıyor. P6'da disiplinli baseline politikası bu tartışmayı kapatır. Tartışılan tek şey rakamlar olur, hangi dosyaya baktığımız değil.

Dört Baseline Kanalı Nasıl Ayırt Edilir?

P6'da bir projeye aynı anda dört farklı baseline atanabilir. Bunlar farklı amaçlara hizmet eder ve veritabanında ayrı kolonlarda saklanır:

• Project Baseline (BL Project): Stakeholder onayı ile kilitlenen resmi referans. EPS yöneticisinin dışındaki kullanıcılar bunu değiştiremez. Earned value hesapları ve resource histogramları varsayılan olarak buna bakar.
• Primary User Baseline (BL1): Planlama mühendisinin günlük çalışma referansı. Çoğu Gantt görünümünde varsayılan kıyaslama BL1'dir.
• Secondary User Baseline (BL2): İkinci bir kıyas — örneğin önceki revize program. "Bir önceki aya göre ne değişti" raporlarında kullanılır.
• Tertiary User Baseline (BL3): What-if senaryosu veya target plan. Hızlandırma çalışmalarında "ideal" hedef olarak konur.

Her kanalın kendi sütun ailesi vardır: BL Project Start, BL1 Start, BL2 Start, BL3 Start; aynısı Finish, Duration ve Cost için. Variance sütunları da aynı ayrımı korur — Variance - BL Project Start ayrı, Variance - BL1 Start ayrı kolondur. Rapor okurken hangi BL'ye karşı bakıldığını her zaman ekrana not düşmek gerekir; aksi halde aynı tabloya bakan iki kişi farklı sayıyı konuşur.

Maintain Baselines Penceresinde Snapshot Almak

Baseline oluşturma yolu: Project > Maintain Baselines. Açılan pencerede iki seçenek vardır:

1. Save a copy of the current project as a new baseline. Aktif projenin o anki halinin tam kopyası alınır. En sık kullanılan seçenek budur. Kopyalama tamamlandığında dosya ayrı bir proje değil, "baseline" tipinde gizli bir kayıt olarak veritabanına düşer.
2. Convert another project to a new baseline of the current project. Daha önce XER olarak gelmiş veya kopyalanmış ayrı bir P6 projesi mevcut projeye baseline olarak iliştirilir. Kıymetli kullanım yeri: yüklenici idareye sözleşme imzası sırasında XER dosyası teslim ederse, idare bu dosyayı kendi veritabanına alıp aktif projeye baseline olarak bağlayabilir.

Snapshot alırken adlandırma disiplini hayati. Önerilen format: BL{numara} - {tip} - {tarih} - {açıklama}. Örnek:

• BL01 - Sözleşme - 2026-03-15 - İmza eki
• BL02 - Revize 1 - 2026-06-20 - İmalat değişikliği sonrası
• BL03 - Süre Uzatımı 1 - 2026-09-10 - 45 gün hava muhalefeti

Bu adlandırma sayesinde 18 ay sonra dosyaya bakan biri, hangi snapshot'un hangi olaya ait olduğunu adından okur. Veritabanı yöneticisi backup'tan dönerken hangi BL'nin sözleşme aslı olduğunu sorgulamak zorunda kalmaz.

Assign Baselines ile Aktif Atamayı Belirlemek

Maintain Baselines penceresinde bir kopya kaydetmek tek başına yeterli değildir. P6, sapma sütunlarını ancak atanmış bir baseline'a karşı hesaplar. Atama yolu: Project > Assign Baselines. Burada dört dropdown vardır — Project Baseline, Primary, Secondary, Tertiary — ve her birine Maintain Baselines'ta hazırladığınız snapshot'lardan birini seçersiniz.

Pratik bir kurulum şudur:

• Project Baseline → "BL01 - Sözleşme" (sözleşmenin imzalı hali)
• Primary (BL1) → "BL02 - Revize 1" (idare onaylı son revize, günlük raporlar buna bakar)
• Secondary (BL2) → bir önceki aylık snapshot (ay-üzeri kıyas için)
• Tertiary (BL3) → "Hızlandırma senaryosu" (yönetim sunumlarında what-if)

Atama yapıldığında Gantt görünümüne baseline çubukları gelir. Çubukların görünmesi için ayrıca View > Bars menüsünden Project Baseline Bar veya Primary Baseline Bar satırlarının onaylı olması gerekir. İlk açılışta P6 bu çubukları gizli getirir; kullanıcı paneli açmadığı sürece sapma sütun değerleri görünür ama çubuk grafiği boş kalır.

Variance Sütunları Nasıl Okunur?

Sapma sütunları Activity Table üstüne Columns dialogundan (sağ tık > Columns veya View > Columns) eklenir. Variance grubu altında üç ana aile vardır:

• Variance - BL Project Start Date / Variance - BL Project Finish Date: Aktivitenin güncel başlangıç/bitişinin Project Baseline'a göre kayması. Negatif değer geç başlamayı/bitmeyi gösterir.
• Variance - BL1 Start Date / Variance - BL1 Finish Date: Aynı kıyas, ama Primary User Baseline'a karşı. Aylık periyodik raporlarda kullanılır.
• Variance - BL1 Duration / Variance - BL Project Duration: Süre farkı. Formül: BL Duration eksi At Completion Duration. Pozitif değer "baseline'a göre daha kısa sürede bitiyor", negatif değer "uzuyor" demektir.

Süre uzatımı dosyasının ana tablosu bu üç ailenin birleşimidir. Örnek: BL01'de bir kazı aktivitesi 14 Mart - 4 Nisan arası 22 gün planlanmış. Aktivite gerçekte 28 Mart başlamış, hâlâ devam ediyor, kalan süre 18 gün. Variance - BL Project Start -14 gün, Variance - BL Project Finish -25 gün okunuyor. Bu satır, idareye sunulacak hava muhalefeti dosyasının doğrudan kanıtıdır.

Cost ve Units ailesi de aynı mantıkla okunur: Variance - BL Project Total Cost, Variance - BL1 Labor Units. Maliyet sapması pozitif ise gerçekleşen maliyet baseline'ın altında, negatif ise üzerinde demektir. Türk kamu projelerinde TL bazında raporlama yapılırken kur etkisini ayıklamak için baseline maliyet kaydı tarihindeki kurun da metin olarak not düşülmesi sahanın gözden kaçırdığı bir disiplin.

Bars ve Filter ile Sapmayı Görselleştirmek

Tek bir sayfada hem güncel program hem baseline çubuğu hem de sapma değerleri yan yana göründüğünde rapor anlaşılır olur. P6 bunu üç katmanda yapar:

• Bars dialogu (View > Bars): Current Bar, Project Baseline Bar ve Primary Baseline Bar açılır. Project Baseline çubuğu genelde ince gri, Primary çubuğu kalın koyu gri olarak ayarlanır; üstte güncel çubuk renkli kalır.
• Filter (View > Filters): "Variance - BL Project Finish Date is less than 0" filtresi sadece geciken aktiviteleri listeler. Aylık idare raporunda 800 satırlık programı 40 satırlık özet sapma listesine indirir.
• Group and Sort (View > Group and Sort): Sapmaları WBS düğümüne göre veya sorumluya göre gruplar. Hangi şefliğin/taşeronun gecikme yarattığı tek bakışta okunur.

Sahada disiplinli ekiplerde aylık raporlama için ayrı bir Layout saklanır: "Variance Reporting - BL Project" gibi adlandırılır, içinde filtreli görünüm, baseline çubuğu açık ve Variance kolonları sağda olur. Primavera eğitimlerinde bu layoutun kurulumu uygulamalı olarak gösterilir; her şantiyenin kendi rapor şablonunu önceden hazırlaması ay sonu kaosunu engeller.

Restore ve Update Baseline ile Eski Snapshot'a Dokunmak

Baseline'lar P6 veritabanında ayrı bir proje olarak görünmez. Sadece Maintain Baselines penceresinden okunabilirler. Ancak bir baseline üzerinde değişiklik yapmak gerekirse iki yol vardır:

1. Restore Baseline: Baseline'ı geçici olarak ayrı bir aktif projeye dönüştürür. Activity ID'ler, ilişkiler, kaynak atamaları açılır. Düzenleme bittikten sonra tekrar Maintain Baselines'tan "Convert another project to a baseline" ile geri eklenir. Bu işlemde Project Baseline ataması düşer; Assign Baselines yeniden yapılmalıdır.
2. Update Baseline: Sadece belirli alanlarda (örneğin yeni eklenen aktiviteler veya değişen kaynak fiyatları) baseline'ın taze veriyle güncellenmesini sağlar. Tüm snapshot'ı yeniden almaktan daha hafiftir, ama orijinal sözleşme baseline'ında kesinlikle kullanılmaz; sözleşmesel referans kaybolur.

Sözleşme baseline'ına dokunmamak temel kuraldır. İdare onayı dışında BL01 hiçbir koşulda Update Baseline ile değiştirilmez. Revizyonlar her zaman yeni bir BL kaydı olarak (BL02, BL03...) eklenir. Bu disiplin ileride Sayıştay denetiminde "hangi tarihten itibaren hangi referans geçerliydi" sorusuna doğrudan cevap verir.

Sapma Analizi Süre Uzatımı Dosyasına Nasıl Dönüşür?

P6'da görünen sayılar tek başına süre uzatımı talebi değildir. Türk kamu sözleşmesinde süre uzatımı için gerekçe dosyası beş bileşeni birleştirir:

1. Sözleşme baseline'ında ilgili aktivitenin orijinal başlangıç-bitiş tarihleri (BL Project Start/Finish ekran görüntüsü)
2. Gerçekleşen tarihler ve Variance sütun değerleri (Activity Table dökümü, PDF)
3. Sapmanın sebebi (puantaj kayıtları, hava raporları, idare yazışmaları)
4. Sapmanın kritik yolu nasıl etkilediği (Total Float değişimi)
5. Talep edilen gün sayısının teknik gerekçelendirmesi

Bu beş bileşeni P6 üzerinden bir araya getirirken Bars dialogu açık, baseline çubuğu görünür ve Variance kolonları sağda olacak şekilde Layout export edilir. Şantiye yönetimi eğitimi kapsamında bu dosyanın hazırlanması, sahanın günlük raporlamasından idareye sunulan resmi talep yazısına nasıl dönüştüğü adım adım işlenir.

Baseline ve sapma analizinin nihai amacı geriye dönük kanıt zinciri kurmaktır. P6'da disiplinli adlandırma, doğru atama ve filtreli rapor üçlüsü bu zinciri kendiliğinden inşa eder; gevşek bir veri girişi ise aynı dosyayı denetim önünde savunulamaz hale getirir. Aradaki fark her zaman sayı değil, disiplindir.