ŞANTİYE YÖNETİMİNDE PRIMAVERA RAPORLARINI YÖNETİM DİLİNE ÇEVİRMEK

Pazartesi sabahı saat 09:30. Genel müdür odasında üç kişi var: müteahhit firmanın proje müdürü, planlama mühendisi ve şirketin finans direktörü. Masada 110 sayfalık bir Primavera çıktısı duruyor. Genel müdürün tek sorusu var: "Eylül teslim tarihi tutuyor mu, idareye süre uzatımı yazısı yazacak mıyım?" Planlama mühendisi sayfa karıştırıyor — Total Float sütunu, kritik aktiviteler, baseline karşılaştırması; ama sayfalardan tek bir cümlelik cevap çıkmıyor. Toplantı 40 dakika uzuyor, karar verilemiyor, ertesi haftaya erteleniyor.

Bu sahnenin tek sebebi Primavera'nın yetersizliği değil; yetersizliği şudur ki üretilen rapor yöneticinin diline çevrilmemiş. Primavera dolu, ekran teknik veriyle taşan, planlama mühendisi kahraman; ama Genel Müdür koltuğundaki kişi için bu veri bir okunabilir özet değil. Aradaki çeviriyi planlama mühendisinin yapması gerekir. Oracle bu çeviri için Primavera P6 ürün ailesinde üç katmanlı bir araç seti sunuyor: Report Wizard, Visualizer ve EPPM Dashboard portletleri. Aşağıdaki bölümler bu çeviriyi sahaya nasıl indireceğinizi anlatıyor.

Genel Müdür Hangi Tek Cümleyi Bekler?

Üst yönetim toplantısının dili farklı bir dildir. Şantiyede günlük konuşulan "BL Project Variance Finish 17 gün", "Total Float -3", "labor demand peak 47 kişi" cümleleri toplantı odasında karşılığını bulmaz. Genel müdürün, idare temsilcisinin veya yönetim kurulu üyesinin sorduğu soru üç maddenin altında toplanır:

• Eylül 2027 teslim tarihi tutuyor mu, tutmuyorsa kaç gün?
• Bu gecikme bize ne maliyete patlıyor, hangi kalemden çıkıyor?
• Karar bekleyen ne var, bugün toplantıdan ne çıkmalı?

Planlama mühendisinin görevi bu üç soruya birer cümleyle cevap üretmek. P6 raporu sayfanın üst dörtte birine "Proje 22 gün gecikmeli, kritik yol mekanik tesisat dağıtımında, beklenen ek maliyet net X gün ve buna karşılık idareye süre uzatımı yazısı önerilir" satırını koyarsa toplantı 10 dakikada biter. Geri kalan 90 sayfa o cümlenin arkasında durur, sorulursa gösterilir; sorulmazsa açılmaz.

KGM Bölge Müdürlüğü aylık ilerleme raporlarında bu prensip resmen yerleşmiştir: ilk sayfa "tek satır özet + sapma yüzdesi + öneri", arka sayfalar ise destekleyici veri ve gerekçedir. Yüklenicinin bu formata uyumlu rapor sunması idare-müşavir-kontrol mühendisi zincirinde hız sağlar; kontrol mühendisi bir sayfada karar verir, müşavir ikinci sayfada doğrular, idare üçüncü sayfada onaylar.

Report Wizard ile Şablon Nasıl Üretilir?

P6 Professional'da yönetim raporunun çekirdeği Tools > Report Wizard menüsünden açılır. Sihirbaz altı adımlı bir akışı izler ve her adımda yönetim diline yaklaşmanız için ayar imkanı verir:

1. Create or Modify Report: Yeni rapor başlatılır. Sıfırdan yapmak yerine "Schedule Report" şablonundan başlayıp özelleştirmek pratiktir.
2. Select Subject Area: Activities, Resources, Projects, WBS gibi seçeneklerden raporun konusu seçilir. Üst yönetim raporu için Activities + time distribution kapalı kalır; haftalık ilerleme raporu için time distribution açılır.
3. Columns: Hangi sütunların raporda yer alacağı belirlenir. Yönetim için 30 sütun değil 6-7 sütun yeter — Activity ID, Activity Name, Start, Finish, Total Float, Physical % Complete, Variance - BL Project Finish.
4. Group & Sort: WBS'in 2. seviyesine göre gruplama açılır (bloklar veya disiplinler). Toplantıdaki yönetici bu seviyede konuşur.
5. Filter: Critical filtresi açılır veya Total Float < 5 olan aktiviteler süzülür. 200 satırlık rapor 12 satıra iner.
6. Report Title: Adlandırma standardı: YÖN-{slug}-{tarih}. Örnek: YON-Kritik-Aktiviteler-Haftalik.

Bu şablon bir kez kurulup Reports klasörüne kaydedildiğinde her hafta tek tıkla yeniden üretilir. Çıktı önizleme penceresinden HTML veya ASCII text olarak dışa alınır; çoğu yüklenici PDF için Print Preview üzerinden Microsoft Print to PDF kullanır. KGM idarelerine sunulan haftalık ilerleme raporu çoğu zaman aynı şablonun farklı filtreyle çalıştırılmış halleridir — bir kritikler, bir near-critical, bir resource overallocation.

Hangi Rapor Kimden Kime Konuşur?

Tek bir "yönetim raporu" yoktur; muhatabın koltuğuna göre rapor tipi değişir. P6'da üç temel rapor ailesi standart şablonlar olarak hazır gelir:

• Schedule Report: Aktivite bazlı süre raporu. Critical path, total float, geciken aktiviteler, baseline sapması. Şantiye şefi, proje müdürü ve idare kontrol mühendisinin haftalık dili.
• Resource Report: Kaynak yükü ve histogramı. Hangi hafta kaç kalıpçı gerek, kule vinç yüzde kaç doluluk, demirci ekibinde overallocation var mı. Şantiye şefi ve insan kaynakları/operasyon müdürünün dili.
• Cost Report: Bütçeye karşı fiili harcama, ETC (Estimate to Complete), EAC (Estimate at Completion). CFO, finans direktörü ve yönetim kurulu mali komitesinin dili.

Genel Müdür toplantısına bu üç raporun hepsi gitmez; bir hibrit sayfa gider. O sayfada Schedule'dan tek cümle gecikme, Resource'dan kritik darboğaz adı, Cost'tan beklenen ek maliyet üçü birlikte durur. Müşavir mühendislik denetiminde ise ayrıntılar değil tutarsızlık aranır: aynı projede Schedule %62 ilerleme gösterirken Cost'un %48 görünmesi sahaya gitme sebebidir. Bu üç raporun birbirini doğrulaması yöneticiye güven verir, doğrulamaması ise şüphe.

Visualizer ile TSLD Tek Sayfaya 200 Aktivite Sığdırmak

Primavera P6 Visualizer, P6 Professional kurulumuyla birlikte gelen ayrı bir uygulamadır. Görevi yazısal değil görsel rapor üretmektir. İki ana çıktı tipi vardır:

• Gantt Chart: Standart aktivite-süre çubukları, ilişki okları, baseline karşılaştırma çubuğu üst veya alt. Print Preview yöneticiye verilebilir kaliteye getirilir.
• TSLD (Timescaled Logic Diagram): Aynı sayfada birden çok aktivite satırı yan yana, üç farklı zaman ölçeği (çeyrek, ay, hafta) üst üste. 200 aktiviteli bir program tek sayfaya sıkıştırılır.

TSLD'nin yönetim için değeri burada saklıdır. 200 sayfalık Gantt çıktısı kimsenin masasında durmaz; tek sayfa TSLD, A3 baskıda toplantı masasına serilebilir hale gelir. Kontrol mühendisi haftalık ilerleme toplantısında bu A3'ün üzerine kırmızı kalemle gecikme aktivitelerini işaretler, müşavir ikinci nüsha üzerinden notlarını paylaşır, idare arşive üçüncü nüsha alır. Üç taraf da aynı resme bakar.

Visualizer'da Schedule Comparison özelliği iki ayrı XER dosyasını yan yana karşılaştırır — örneğin sözleşme baseline'ı ile bu ayın güncel programını. Hangi aktivite eklendi, hangisi silindi, hangi süre uzadı kolon kolon görünür. Bu çıktı süre uzatımı dosyalarının ek belgesi olarak doğrudan kullanılır; idare karşısında "iki ay önce neyi konuşmuştuk" sorusunu kesin verir.

Dashboard Portletleri EPPM Tarafında Üst Yönetimin Yaşam Alanı

P6 EPPM web arayüzünün Dashboards sekmesi, üst yönetim portföy görünümünün ev sahibidir. Buradan tek bir projeye değil 12 projeye birden bakılır; portletler (widget'lar) ile her dashboard sayfası lego gibi kurulur:

• Project Performance: SPI ve CPI değerlerini bütün projeler için yan yana gösterir. Yeşil-sarı-kırmızı eşik renkleriyle hangi projenin dikkat istediği bir bakışta okunur.
• Schedule Performance: Bitiş tarihi sapması ve total float trendi. Aylık trend grafiği üst yönetimin "durum kötüye mi gidiyor iyiye mi" sorusuna cevaptır.
• Cost Performance: Baseline cost vs actual cost vs forecast. Finans direktörünün portföy görünümü.
• Resource Analysis: Şirket bazında kaynak yüklemesi. "Önümüzdeki üç ay kalıpçı ihtiyacımız hangi hafta zirve yapar" sorusunu cevaplar.
• Issues and Risks: Açık riskler ve sorumlu listesi. Yönetim toplantısında karar bekleyen kalemler.

Bu portletler her kullanıcıya rol bazlı sunulur: Genel Müdür ekranı, Proje Müdürü ekranı, Kontrol Amirliği ekranı ayrı ayrı yapılandırılabilir. Aynı veritabanından beslenir ama her ekran kendi soruyu cevaplar. KGM'nin merkezi koordinasyon birimi gibi çok-projeli idarelerde bu portföy görünümü tek bir Excel raporundan daha hızlı karar aldırır; canlı veridir, ayın 30'unu beklemez.

Sapmayı Mazeret Değil Aksiyon Olarak Sunmak

Yönetim diline çevirmenin en zor yanı sapmayı sunma şeklidir. Sayısal sapma (17 gün, %23, 4,2 milyon TL) tek başına yönetici için anlamsızdır; soracağı tek soru "ne yapacağız" olur. Planlama mühendisinin raporu bu sorunun cevabıyla birlikte gelmelidir.

Sapma sunumunun üç parçası vardır:

1. Olgu cümlesi: "Mekanik kaba tesisat 14 gün gecikmeli, kritik yol bu disiplinden geçiyor."
2. Kök neden: "Sebep yurtdışından gelen pompa grubunun gümrük gecikmesi; teknik değil tedarik kaynaklı."
3. Aksiyon önerisi: "İki paralel ekip ve gece vardiyası ile 8 gün kazanılabilir; idare süre uzatımı dosyası ile kalan 6 gün korunabilir."

Üç madde tek slayttır. Yönetim "süre uzatımı yazısı yazılsın" veya "vardiyayı onaylıyorum" dediği anda toplantı biter. Aynı sapma "14 gün gecikmiş durumdayız, çalışmalar devam ediyor" şeklinde sunulursa yönetici cevap üretemez; üretemediği için sorumluluk planlama mühendisine geri döner. Disiplin uygulayan bir planlama ekibi için bütünleşik bir planlama yazılımı eğitim programı, sapma sunumunun standart bir kalıba oturmasını ve farklı projelerde aynı dilin konuşulmasını sağlar.

İdare Müşavir Kontrol Mühendisi Müteahhit Zincirinde Tek Dil

Türk inşaat sektöründe kamu projesi yürüten her ekip dört taraflı bir koordinasyon yapar:

• İdare (KGM, DSİ, belediye) — yatırımcı; bitiş tarihi ve bütçe kararı verir.
• Müşavir — idare adına teknik denetim; aylık raporu inceler, süre uzatımı talebine görüş verir.
• Kontrol mühendisi — şantiyede idare temsilcisi; günlük imalatı kontrol eder, hak edişi parafe eder.
• Müteahhit (yüklenici) — işi yapan; planlama mühendisi de bu tarafta durur.

Bu dört taraf aynı P6 dosyasını farklı dillerde okur. Yüklenicinin planlama mühendisi raporun her sürümünü dört farklı versiyonda çıkartırsa hiçbiri okunmaz; aynı çekirdek veriyi her tarafın diline göre filtrelemek gerekir. İdareye giden raporda hak ediş ilerleme yüzdeleri öne çıkar; müşavirin nüshasında ilişki mantığı ve baseline karşılaştırması; kontrol mühendisinin nüshasında günlük imalat ve resource kullanımı; iç toplantıda ise kritik yol ve maliyet sapması.

P6 Report Wizard ve Visualizer'da bu dört şablon bir kez kurulduğunda her ay aynı işten dört farklı çıktı tek tıkla üretilir. Çekirdek aynı veridir, dilini her taraf kendi koltuğuna uygun bulur. Planlama mühendisi haftada beş gün rapor yazmak yerine ayda bir gün şablon revizyonu yapar.

Raporu Toplantıya Götürmeden Önce Ne Yapılır?

P6'dan çıkan ham rapor doğrudan toplantı odasına götürülmez. Üç filtreden geçirildikten sonra sunulur:

1. Anlamlı sayı testi: Raporda yer alan her sayı, yöneticinin koltuğunda anlam taşıyor mu? Total Float Genel Müdür için anlamlı değildir, "kalan tampon gün" anlamlıdır. Sütun adları Türkçeleştirilir.
2. Eşik testi: Yeşil-sarı-kırmızı eşikleri her metrik için tanımlı mı? SPI 0,95 sarı, 0,90 kırmızı; toplam bütçe sapması %3 sarı, %5 kırmızı. Eşiksiz sayı yorumlanmaz.
3. Aksiyon testi: Raporun ana yargısının arkasında somut bir öneri var mı? "Yapılması gereken" sütunu yoksa rapor yarımdır.

Bu üç filtre uygulanmış bir Primavera raporu, 110 sayfanın yerini alır; planlama mühendisini günde 4 saat veri kopyalamaktan kurtarır ve yönetim toplantısını kararla biten bir toplantıya çevirir. Yazılımın detay gücü ile yöneticinin karar isteği arasındaki köprü buradadır — köprüyü kuran kişi planlama mühendisidir, P6 değil.