PRİMAVERA P6’DA BASELİNE VE SAPMA ANALİZİ YÖNETMEK

Proje planı “yayınlandı” denildiğinde herkes aynı şeyi anladığını varsayar: tarihleri, süreleri, kaynakları ve maliyetleri baz alan tek bir doğruluk noktası. Oysa sahada en sık yaşanan sorun, planın sürekli değişmesi ve “sapma” dediğimiz şeyin neye göre ölçüldüğünün belirsiz kalmasıdır. Primavera P6’da baseline yönetimi bu belirsizliği ortadan kaldırır; sapma analizi ise performansın kanıta dayalı şekilde konuşulmasını sağlar.

Bu yazıda, P6’da baseline stratejisi kurgulamayı; onaylı planı kilitlemeyi; schedule, maliyet ve kaynak tarafında sapma metriklerini okumayı; raporlama ve yönetişim döngüsünü kurmayı adım adım ele alacağız. Hedef, sadece “bir baseline atamak” değil; aynı zamanda güncelleme disiplinini oturtup tutarlı, izlenebilir bir kontrol mekanizması kurmaktır.

Özellikle EPC, altyapı, enerji ve IT portföylerinde sık görülen “revizyonlar” ve “re-baseline” tartışmaları için pratik karar çerçeveleri de paylaşacağız. İlerlerken, P6 raporları, Earned Value (EV) metrikleri ve veri tabanı sorguları gibi teknik detaylara da değinip, farklı paydaşların aynı dili konuşmasını sağlayacağız.

Baseline stratejisini Primavera P6’da kurgulamak

Baseline, özetle “onaylı planın dondurulmuş kopyası”dır. P6’da birden fazla baseline tutabilmek büyük avantajdır; fakat yanlış strateji, analizleri çelişkili hale getirir. En yaygın yaklaşım, Initial Baseline (sözleşme/ihale onayı) ve Current Baseline (son onaylı revizyon) ikilisini yönetmektir. Bazı kurumlar ayrıca “What-if Baseline” ile iyileştirme senaryolarını ayrı izler.

Stratejiyi kurgularken üç soru net olmalıdır: (1) Baseline kim tarafından ve hangi kalite kriteriyle onaylanır? (2) Baseline hangi sıklıkta güncellenir ve hangi koşulda re-baseline yapılır? (3) Sapma raporu hangi baseline’a göre üretilir? Bu üç sorunun cevabı netleşmeden “tek tıkla baseline” yaklaşımı, toplantıların yorum savaşına dönüşmesine yol açar.

Initial baseline oluşturma seçeneklerini karşılaştırmak

Initial Baseline genellikle planın ilk kez onaylandığı anın fotoğrafıdır. P6’da proje kopyalayıp baseline’a dönüştürmek yerine doğrudan “Maintain Baselines” üzerinden baseline üretmek, ID/ilişki tutarlılığını korur. Eğer sözleşmeye bağlı bir teslimat takvimi varsa, bu baseline’ın “değişmez referans” olduğu açıkça tanımlanmalıdır.

Current baseline güncelleme eşiğini belirlemek

Current Baseline, onaylı revizyonu temsil eder. Burada kritik nokta şudur: Her schedule update sonrasında baseline güncellenmez. Baseline güncellemesi, değişiklik kontrolü (Change Control) ile tetiklenir. Örneğin kapsam değişikliği, kritik yol değişimi, resmi süre uzatımı (EOT) ya da kaynak stratejisinde köklü revizyon gibi koşullar, re-baseline gerektirebilir.

Onaylı planı projede izlenebilir kılmak

Baseline yönetiminin değeri, planın “izlenebilir” olmasıyla ortaya çıkar. P6 tarafında bu izlenebilirlik; baseline’ı oluşturmak, doğru baseline’ı projeye atamak, ardından raporlarda doğru kolonları kullanmakla sağlanır. Ayrıca WBS hiyerarşisi ve kodlamalar (Project Codes, Activity Codes) baseline raporlarının okunabilirliğini doğrudan etkiler.

Baseline atama adımını doğru yerde yapmak

P6’da baseline oluşturduktan sonra “Assign Baselines” ekranından Project Baseline, Primary Baseline ve Secondary/Tertiary Baseline seçimleri yapılır. Kurumsal senaryolarda sık önerilen yaklaşım, Primary Baseline’ı Current Baseline olarak belirlemek ve Secondary Baseline’da Initial Baseline’ı tutmaktır. Böylece raporlar iki referansı aynı anda kıyaslayabilir.

WBS ve kod standardını sapmaya göre kurmak

Sapma analizi sadece aktivite seviyesinde yapılmaz; WBS, disiplin, lokasyon ya da sözleşme paketleri bazında özetlenir. Bu nedenle WBS yapısını “raporlanabilir” tasarlamak gerekir. Örneğin her WBS altında teslimat (deliverable) net olmalı; activity code’lar ise sorumluluk matrisiyle (RACI) uyumlu olmalıdır. Bu sayede sapma raporu toplantıları “kim, hangi pakette, ne kadar geride?” sorusuna hızlı cevap verir.

Sapma metriklerini tarih, süre ve mantıkla okumak

Schedule sapması, tek bir metrikle anlaşılmaz. En sağlıklı okuma; tarih sapması, süre sapması ve kritik yol etkisini birlikte değerlendirmektir. P6’da baseline kolonları (Baseline Start/Finish, Baseline Duration) ile current kolonlar (Start/Finish, Remaining Duration) kıyaslanır. Ancak bu kıyasın anlamlı olması için güncelleme yönteminin (progressing rules) tutarlı olması şarttır.

Kritik yol değişimini rapora bağlamak

Kritik yol değişimi, bazen takvim sapmasından daha önemlidir. Baseline’a göre kritik olmayan bir aktivite, güncel durumda kritik hale gelmiş olabilir. Bu durumda sadece tarih farkına bakmak yerine, “Total Float” ve “Longest Path” gibi göstergelerle neden-sonuç ilişkisi kurulmalıdır. Özellikle “constraints” kullanımı kritik yolu yapay olarak değiştirebileceği için, constraint politikası da yönetişim dokümanında tanımlanmalıdır.

Takvim farkını kolonlarla tutarlı göstermek

P6 raporlarında en sık kullanılan yaklaşım, “Finish Variance = Finish - Baseline Finish” gibi bir kolonla sapmayı sayısallaştırmaktır. Bu kolon bazen rapor düzeninde hazır gelir; bazen de kullanıcı tanımlı alan (UDF) ya da dış raporlama aracıyla hesaplanır. Burada önemli olan, sapma hesabında hangi tarihlerin baz alınacağının standartlaşmasıdır: erken bitiş mi, geç bitiş mi; mevcut bitiş mi, planlanan bitiş mi?

// Örnek: P6 raporlamasında kullanılabilecek basit sapma mantığı (pseudocode)
// Not: Bu mantık dış BI aracında ya da rapor katmanında uygulanabilir.

if (BaselineFinish is null) {
  VarianceDays = null
} else if (CurrentFinish is not null) {
  VarianceDays = days_between(CurrentFinish, BaselineFinish)
} else {
  VarianceDays = days_between(ForecastFinish, BaselineFinish)
}

// Negatif değer: baseline'a göre önde
// Pozitif değer: baseline'a göre geride

İlerleme güncellemesini kontrollü biçimde toplamak

Baseline doğru olsa bile, güncelleme disiplini zayıfsa sapma analizi yanıltıcı olur. Bu nedenle “update cycle” net olmalıdır: kesim tarihi (data date), rapor periyodu, ilerleme yöntemi (Physical % Complete, Duration % Complete, Units % Complete) ve onay akışı aynı standarda bağlanmalıdır. Proje kontrol ekibinin görevi, “veri kalitesi”ni korumaktır.

Data date disiplinini haftalık ritimle yürütmek

Data date, raporun referans anıdır. Haftalık update’lerde data date genellikle hafta sonu kapanışı olur. P6’da data date kaydırılmadan yapılan güncellemeler, float ve kritik yol analizini bozar. Bu yüzden “Schedule Update Checklist” içinde data date adımı mutlaka yer almalıdır. Ayrıca ilerleme toplanırken gerçekleşen tarihler (Actual Start/Finish) mümkün olduğunca belgelere bağlanmalıdır.

Progressing kuralını aktivite tipine göre seçmek

LOE (Level of Effort) aktiviteler, milestone’lar ve fiziksel ilerleme gerektiren saha işleri aynı yöntemle güncellenmez. LOE aktivitelerde duration bazlı ilerleme, yanlış pozitif performans yaratabilir. Fiziksel işlerde ise Physical % Complete yaklaşımı, sahadan ölçüm alınabildiği için daha güvenilir olur. Kurum içinde “hangi aktivite tipine hangi ilerleme yöntemi uygulanır?” matrisi hazırlamak, sapma tartışmalarını ciddi biçimde azaltır.

Maliyet ve kaynak sapmasını EV metrikleriyle yönetmek

Sapma analizi çoğu ekipte “tarih gecikti mi?” sorusuna indirgenir; oysa maliyet ve kaynak boyutu, karar vericiler için daha kritik olabilir. Primavera P6 EPPM tarafında Earned Value (EV) analiziyle PV, EV ve AC gibi metrikler izlenebilir. Bu metrikler doğru kurgulandığında, schedule gecikmesi ile maliyet aşımı arasındaki ilişki netleşir.

Budget at completion çizgisini baseline’a bağlamak

EV analizinin temeli, BAC ve zamanlanmış bütçedir. Baseline oluştururken kaynak atamalarının, birim fiyatların ve maliyet hesaplarının “onaylı” olması gerekir. Aksi halde EV raporu, hatalı maliyet kodları nedeniyle gerçeği yansıtmaz. En iyi pratik, baseline öncesinde “resource/cost audit” yapmak ve kritik paketlerde maliyet kodlarının doğruluğunu kontrol etmektir.

SPI ve CPI yorumunu karar mekanizmasına taşımak

SPI (Schedule Performance Index) ve CPI (Cost Performance Index) sadece sayılar değildir; aksiyon tetikleyicileridir. Örneğin SPI 0.90 altına düşerse recovery plan, CPI 0.95 altına düşerse cost review toplantısı tetiklenebilir. Bu eşikler, projenin risk iştahına göre belirlenir. Önemli olan, bu metriklerin “raporda dursun” diye değil; karar almak için kullanılmasıdır.

-- Örnek: P6 veritabanında (Oracle/SQL Server mantığında) baseline ve güncel bitiş farkını WBS bazında özetlemek
-- Not: Tablo/ad alanları kuruma göre değişebilir; şema uyarlaması gerekir.

SELECT
  w.wbs_id,
  w.wbs_name,
  COUNT(a.task_id) AS activity_count,
  AVG(DATEDIFF(day, bl.bl_finish_date, a.finish_date)) AS avg_finish_variance_days,
  MAX(DATEDIFF(day, bl.bl_finish_date, a.finish_date)) AS max_finish_variance_days
FROM task a
JOIN wbs w ON w.wbs_id = a.wbs_id
JOIN task_baseline bl ON bl.task_id = a.task_id AND bl.baseline_type = 'PRIMARY'
WHERE a.proj_id = :proj_id
  AND a.finish_date IS NOT NULL
  AND bl.bl_finish_date IS NOT NULL
GROUP BY w.wbs_id, w.wbs_name
ORDER BY max_finish_variance_days DESC;

Raporlama ve yönetişim akışını kurumsallaştırmak

Baseline ve sapma yönetimi, sadece planlama mühendisinin ekranında kalırsa ölçeklenmez. Kurumsallaşma için rapor formatı, toplantı ritmi, sorumluluklar ve değişiklik kontrol süreci netleşmelidir. Bu noktada P6 raporları (Reports), layouts, dashboards ve dış BI katmanı birlikte kurgulanabilir. Hedef, tek bir “truth set” yaratmak ve herkesin aynı snapshot üzerinden konuşmasını sağlamaktır.

Change control sürecini re-baseline ile bağlamak

Re-baseline, “kötü gidiyoruz, sıfırlayalım” çözümü değildir; resmi bir değişiklik kaydıyla (change request) yürütülmelidir. Önerilen pratik: (1) değişiklik talebi açmak, (2) etki analizi yapmak, (3) onay almak, (4) yeni baseline üretip “Current Baseline” olarak atamak, (5) eski baseline’ı “Initial/History” olarak saklamaktır. Bu sayede audit izleri korunur.

Dashboard ve filtrelerle sapmayı görünür kılmak

Karar vericiler için en değerli çıktı, “neresi kırmızı ve neden?” sorusunun cevabıdır. Bu nedenle dashboard’larda kritik paketler, trendler ve eşik aşımları öne çıkarılmalıdır. Filtreler; sorumlu ekip, WBS, lokasyon, sözleşme paketi gibi boyutlarla sapmayı ayrıştırabilmelidir. P6’yı daha derin öğrenmek isteyen ekipler için Primavera eğitimi içeriği, standart kurulum ve raporlama pratiklerini hızlandırır.

Sık hataları önleyerek analiz kalitesini artırmak

Doğru baseline ve doğru rapor bile bazı hatalarla anlamsızlaşabilir. En yaygın hatalar; baseline’ı yanlış projeye atamak, data date’i kaydırmadan güncellemek, aşırı constraint kullanmak, LOE aktiviteleri yanlış ilerletmek ve onaysız plan revizyonlarını “current” plana yansıtmak olarak özetlenebilir. Bu hatalar, sapmayı gerçek sebeplerinden koparır.

Constraint kullanımını politika seviyesinde sınırlamak

Must Finish, Start On gibi sert constraint’ler, planı “makyajlayabilir” ve kritik yol analizini bozabilir. Bu nedenle constraint kullanımı; sadece sözleşme milestone’ları ve dış bağımlılıklar gibi zorunlu alanlara sınırlandırılmalıdır. Geri kalan durumlarda relationship ve doğru calendar seçimiyle plan davranışı yönetilmelidir.

Baseline kalitesini kontrol listesiyle doğrulamak

Baseline almadan önce kısa bir kontrol listesi oluşturmak büyük fark yaratır. Örneğin: takvimler doğru mu, logic tamam mı, open end var mı, kaynak atamaları tutarlı mı, coding standardı uygun mu, milestone’lar onaylı mı? Bu kontrol listesi, “baseline aldıktan sonra” yapılan acil düzeltmeleri minimize eder ve sapma analizini güvenilir kılar.

Özetle, Primavera P6’da baseline ve sapma analizi yönetimi; sadece bir özellik kullanımı değil, bir yönetişim sistemi kurmaktır. Doğru baseline stratejisi, disiplinli update döngüsü ve tutarlı raporlama dili birleştiğinde, proje performansı şeffaflaşır ve kararlar hızlanır. Bu yaklaşımı bir standarda dönüştürmek, tek projede değil portföy genelinde öngörülebilirlik sağlar.