PRİMAVERA P6’DA S CURVE VE KPI RAPORLAMA KURGULAMAK

Primavera P6’da “S Curve” görmek çoğu ekip için sadece şık bir grafik değildir; planın gerçekçi olup olmadığını, ilerlemenin güvenilirliğini ve raporun yönetim diline çevrilip çevrilmediğini test eden bir kontroldür. Ancak S Curve tek başına bir hedef değildir; doğru kurgu yapılmadığında aynı proje için farklı ekiplerin birbirinden tamamen farklı eğriler üretmesi kaçınılmaz olur.

Bu yazıda, Primavera P6 üzerinde S Curve ve KPI raporlamayı uçtan uca tasarlamayı; baseline mantığını oturtmayı, ölçüm türlerini seçmeyi, Earned Value (EV) metriklerini doğru kullanmayı ve raporu “karar verilebilir” hale getirmeyi adım adım ele alacağız. Amaç, proje kontrol ekibinin günlük işine uyacak kadar pratik; yöneticinin tek ekranda anlayacağı kadar sade bir yapı kurmaktır.

Özellikle çoklu disiplin, çoklu yüklenici ve değişken kapsamın olduğu projelerde; “hangi veri doğru?” tartışması yerine “hangi karar doğru?” tartışmasına geçmek için S Curve ve KPI çerçevesini standardize etmek kritik hale gelir.

Raporlama hedeflerini ve veri sözlüğünü netleştirmek

İlk adım, S Curve’ün hangi amaçla kullanılacağını tanımlamaktır: nakit akışı mı, işçilik mi, miktar mı, maliyet mi, yoksa EV tabanlı performans mı? Bu soruya net cevap vermeden çizilen her eğri, farklı bir gerçeği temsil eder ve raporların birbiriyle çelişmesine yol açar.

Kurumsal ölçekte sürdürülebilir bir raporlama için proje başında kısa bir “veri sözlüğü” oluşturmak gerekir. Bu sözlükte; kaynak türleri, birimlerin nasıl normalize edileceği, takvimlerin rapora etkisi, ilerleme (progress) toplama mantığı, baseline seçimi ve raporların kim tarafından onaylanacağı açıkça yazılmalıdır.

• Primary keyword olarak “Primavera P6 S Curve KPI raporlama” odağını korumak
• Secondary keyword kümeleriyle baseline yönetimi, Earned Value, Schedule Performance Index, Cost Performance Index, nakit akışı, progress ölçümü gibi alanları doğal biçimde yaymak
• Raporun hedef kitlesini (PMO, proje müdürü, üst yönetim) ayrı ayrı tanımlamak

Bu yapı kurulduğunda, P6 içindeki alan seçimi de otomatik olarak netleşir: “Planned Value nereden gelir?”, “Actual hangi kaynaktan okunur?”, “Earned nasıl hesaplanır?” gibi sorular kayıt altına alınır ve denetlenebilir hale gelir.

KPI tanımlarını ölçülebilir eşiklerle standardize etmek

KPI’ları “iyi/kötü” diye yorumlamak yerine ölçülebilir eşiklerle tanımlamak gerekir. Örneğin SPI için 0.95–1.05 bandı “stabil”, 0.90 altı “kritik” gibi kurallar; PMO raporunu kişiye bağlı olmaktan çıkarır. Aynı yaklaşım CPI, gecikme günleri, kritik yol aktivite sayısı ve değişiklik (change) hacmi için de uygulanmalıdır.

Baseline stratejisini kurumsal ölçekte tasarlamak

S Curve ve KPI raporlama, baseline olmadan güvenilir değildir. Çünkü “planlanan” ile “gerçekleşen” kıyasının referansı baseline’dır. Primavera P6’da baseline yönetimi bir buton değil, bir yönetişim (governance) konusudur.

Temel kural şudur: Baseline her revizyonda rastgele güncellenmez; plan revizyonu bir değişiklik kaydıyla (change request) ilişkilendirilir, onaylanır ve rapora “neden” bilgisiyle yansıtılır. Bu sayede yönetim, kötüleşen bir KPI’ı “sadece plan güncellendi” bahanesiyle kaybetmez.

Baseline kopyalama ve revizyon izini oluşturmak

Önerilen yaklaşım; proje başlangıcında Contract Baseline, her ana revizyonda Current Baseline ve haftalık izleme için Reporting Baseline

S Curve veri kaynağını ve ölçüm türünü seçmek

S Curve, aynı projede farklı ölçüm türleriyle üretilebilir: maliyet, saat, miktar, bütçe veya EV. Hangi türün seçileceği; sözleşme modeline, ölçüm altyapısına ve veri doğrulama kapasitesine bağlıdır. Örneğin EPC projelerinde miktar bazlı ilerleme güçlü olabilirken, yazılım projelerinde işçilik ve kazanılmış değer yaklaşımı daha anlamlıdır.

Primavera P6 tarafında S Curve için tipik veri kaynakları şunlardır: bütçe (budgeted cost), gerçekleşen (actual cost), kazanılmış (earned value), kaynak saatleri, aktivite bazlı physical % complete veya units % complete. Yanlış seçildiğinde eğri “doğru görünür” ama gerçeği temsil etmez.

Physical yüzde ilerleme mantığını kalibre etmek

Physical % Complete yaklaşımı, özellikle üretim ve saha işlerinde güçlüdür; ancak kriterleri net değilse subjektifleşir. Bu nedenle her disiplin için ölçüm kriterleri tanımlanmalı; kontrol listesi, teslim dokümanı veya ölçülebilir miktarlarla bağlanmalıdır. Aksi durumda S Curve “iyimser raporlama”ya dönüşür ve kritik sapmaları geç fark ettirir.

Earned Value KPI setini kurgulamak

Yönetimin en hızlı anladığı KPI setlerinden biri Earned Value (EV) setidir. P6 içinde EV metriklerini doğru okuyabilmek için; aktivite türleri, kaynak atamaları, maliyet sınıfları ve ilerleme ölçüm yöntemleri tutarlı olmalıdır. Aksi halde PV/EV/AC üçlüsü gerçeği yansıtmaz.

Tipik EV KPI seti; SPI (Schedule Performance Index), CPI (Cost Performance Index), SV (Schedule Variance), CV (Cost Variance), EAC (Estimate at Completion) ve ETC (Estimate to Complete) gibi göstergeleri içerir. Bu metriklerin raporda “tek başına” verilmesi yerine; hedef eşikleri ve kısa yorum alanıyla birlikte sunulması daha etkilidir.

SPI ve CPI eşiklerini rapor diline çevirmek

SPI ve CPI rakamları, teknik ekip için anlamlıdır; fakat yönetim için “risk seviyesi” daha değerlidir. Bu nedenle raporda eşiklere göre sınıflandırma yapılmalı ve örneğin “CPI 0.92: bütçe aşımı eğilimi” gibi kısa bir yorumla desteklenmelidir. Böylece KPI, sadece izlenen değil, aksiyon doğuran bir göstergiye dönüşür.

WBS, OBS ve filtrelerle raporu yönetilebilir kılmak

S Curve ve KPI raporlama, “tek grafik” yaklaşımıyla başlar ama hızla parçalanır: disiplinler, lokasyonlar, yükleniciler, fazlar ve paketler raporu çoğaltır. Bu çoğalmayı kontrol etmek için WBS yapısı ve filtre mantığı kritik rol oynar.

Öneri: WBS’yi raporlama ihtiyaçlarına göre tasarlamak; raporların “hangi kırılımda” üretileceğini proje başında belirlemek. Ayrıca OBS (organizasyon yapısı) ve activity code’lar, yüklenici/ekip bazlı KPI takibini kolaylaştırır. P6’da doğru kod yapısı; BI tarafında da modellemeyi basitleştirir.

Activity code ve layout standardını oturtmak

Aynı raporun farklı kullanıcı ekranlarında farklı görünmesi, kurumsal raporlamada sık görülen bir sorundur. Bu nedenle standart layout’lar, filtre preset’leri ve rapor şablonları tanımlanmalıdır. Örneğin “Weekly Executive KPI”, “Discipline S Curve”, “Contractor Productivity” gibi sabit setler; rapor üretimini kişiye bağlı olmaktan çıkarır.

Raporlamayı otomatikleştirmek ve veri hattını kurmak

Kurumsal ölçekte S Curve ve KPI raporlama, manuel export ile sürdürülemez. P6 verisinin bir veri ambarına (ör. P6 Analytics, veri tabanı replikasyonu veya API entegrasyonu) alınması; Power BI/Tableau gibi araçlarda standart dashboard’lar üretilmesi yaygın bir yaklaşımdır. Buradaki kritik nokta, “tek doğru veri kaynağı”nı tanımlamak ve veri yenileme periyodunu standartlaştırmaktır.

Aşağıdaki örnekler, raporlama otomasyonunun nasıl kurgulanabileceğine dair gerçekçi şablonlardır. Kullandığınız P6 sürümüne ve veri erişim yöntemine göre alan adları değişebilir; ancak mantık aynı kalır: PV/EV/AC ve tarih boyutlarını doğru ilişkilendirmek.

Veri çekimini rapor tarihine göre tasarlamak

Haftalık raporlama için “data date” (cut-off) kavramı net olmalıdır. Raporlama dönemi, farklı ekiplerce farklı günlerde kapatılırsa aynı hafta için farklı KPI’lar üretilebilir. Bu nedenle rapor tarihini, veri çekimi ve onay süreciyle birlikte tanımlamak gerekir. Böylece raporlar karşılaştırılabilir olur ve trend analizi güvenilirleşir.

-- Example SQL-style extraction for weekly EV snapshot (conceptual)
SELECT
  p.PROJECT_ID,
  p.PROJECT_NAME,
  s.DATA_DATE,
  w.WBS_CODE,
  SUM(a.BCWS) AS PV,   -- Planned Value
  SUM(a.BCWP) AS EV,   -- Earned Value
  SUM(a.ACWP) AS AC    -- Actual Cost
FROM PROJECTS p
JOIN EV_SNAPSHOTS s   ON s.PROJECT_ID = p.PROJECT_ID
JOIN ACTIVITIES_EV a  ON a.SNAPSHOT_ID = s.SNAPSHOT_ID
JOIN WBS w            ON w.WBS_ID = a.WBS_ID
WHERE s.DATA_DATE = :reporting_cutoff_date
GROUP BY p.PROJECT_ID, p.PROJECT_NAME, s.DATA_DATE, w.WBS_CODE
ORDER BY w.WBS_CODE;

// Example KPI mapping rules for reporting layer (pseudo-config)
kpi_rules:
  spi:
    formula: "EV / PV"
    thresholds:
      green: ">= 0.95 and <= 1.05"
      amber: ">= 0.90 and < 0.95"
      red: "< 0.90"
    message:
      green: "Planla uyumlu ilerleme"
      amber: "Yakın izleme gerekli"
      red: "Kritik gecikme riski"
  cpi:
    formula: "EV / AC"
    thresholds:
      green: ">= 0.98"
      amber: ">= 0.92 and < 0.98"
      red: "< 0.92"

Bu tür bir kurgu, rapor üretimini hızlandırırken denetlenebilirliği artırır. Ayrıca dashboard tarafında SPI/CPI trendleri, S Curve eğrileri ve WBS kırılımları tek model üzerinden yönetilir.

Yönetim dashboard’unu karar odaklı tasarlamak

En iyi rapor, en çok grafiği olan rapor değildir; en hızlı doğru kararı aldıran rapordur. Yönetim dashboard’unda S Curve; projenin “nereye gittiğini” gösterirken, KPI kartları “neden”i ve “ne yapmalı”yı tetikler. Bu nedenle ekran kurgusu; özet, kırılım ve detaya inme şeklinde katmanlı tasarlanmalıdır.

Önerilen sayfa yapısı: Üstte proje özeti (Data Date, baseline versiyonu, kritik riskler), ortada S Curve (PV/EV/AC veya seçilen ölçüm), altta KPI kartları (SPI, CPI, SV, CV, kritik yol aktivite sayısı, open issues). Detay sayfalarında WBS/discipline/contractor kırılımları sunulabilir.

İstisna yönetimini rapor akışına entegre etmek

İyi dashboard, sadece ortalamayı değil, istisnayı da görünür kılar. Örneğin SPI düşüşünün hangi WBS paketinden geldiğini tek tıkla gösterebilmek; PMO’nun aksiyon hızını artırır. Bu yaklaşım, “rapor okuma”yı “problem çözme”ye dönüştürür ve rapor toplantılarını kısaltır.

Kalite kontrol adımlarını ve denetim izini kurmak

S Curve ve KPI raporlama; veri kalitesi kontrolü yapılmadığında, en hızlı güven kaybeden çıktılardan biridir. Bu yüzden raporlama döngüsüne “kontrol kapıları” eklemek gerekir: veri tarihi kapatıldı mı, progress kuralları uygulandı mı, baseline doğru mu, activity code’lar eksiksiz mi, maliyet sınıfları tutarlı mı?

Özellikle çok ekipli projelerde, rapor yayımlanmadan önce kısa bir kontrol listesiyle doğrulama yapılması; hatalı KPI’ların yönetim toplantısına taşınmasını engeller. Kontrol adımlarının loglanması da denetim izi (audit trail) sağlar.

Rapor kapanış sürecini rol bazlı işletmek

Haftalık rapor kapanışı; planlama mühendisi, maliyet kontrol, saha ekipleri ve PMO arasında rol bazlı yürütülmelidir. Her rolün hangi veriden sorumlu olduğu netleşirse; “veri kimin?” tartışması biter. Böylece rapor, kurumsal hafızaya dönüşür ve proje sonu analizleri için güvenilir bir temel sağlar.

Primavera eğitim yoluyla uygulamaya geçirmek

Kurgu ne kadar doğru olursa olsun, ekip aynı standardı uygulamıyorsa raporlar kısa sürede bozulur. Bu nedenle P6 kullanıcılarının; baseline yönetimi, progress ölçüm yöntemleri, EV mantığı ve rapor şablonları konusunda ortak bir çalışma biçimi geliştirmesi gerekir. Kurumsal eğitim ve örnek proje setleri, standardın kalıcı hale gelmesini kolaylaştırır.

Bu noktada, kurguya uygun pratik senaryolarla ilerlemek isterseniz Primavera eğitimi içeriği üzerinden rol bazlı uygulamalarla standardı hızla yaygınlaştırabilirsiniz.

S Curve ve KPI raporlama kurgusunu sürdürülebilir kılmak

Son aşama, kurulan yapının sürdürülebilirliğini garanti etmektir. KPI seti, rapor şablonları ve veri sözlüğü; proje yaşam döngüsü boyunca güncellenecek canlı dokümanlar olmalıdır. Ayrıca yeni projeler başladığında bu şablonların kopyalanabilmesi; PMO’nun olgunluk seviyesini yükseltir.

Özetle; Primavera P6’da S Curve ve KPI raporlama kurgulamak, sadece grafik üretmek değil; baseline disiplinini kurmak, ölçüm yöntemini netleştirmek, EV metriklerini güvenilir yapmak, otomasyon hattını oluşturmak ve kalite kontrol süreçlerini işletmektir. Bu yaklaşım benimsendiğinde; raporlar bir “sunum” değil, karar veren bir yönetim aracına dönüşür.