PRIMAVERA P6'DA WBS VE AKTİVİTE STANDARTLARI BELİRLEMEK

Primavera P6'da WBS ve aktivite standartları, P6 çalıştırılmadan önce kurum içinde bir kez kararlaştırılan ortak dildir: iş kırılım hiyerarşisinin nasıl açılacağı, Activity ID'lerin nasıl kodlanacağı ve aktivite isimlerinin hangi yapıda yazılacağı. Bu dil oturmadığında her proje planlamacının kişisel tercihine göre farklı bir form alır, portföy seviyesinde raporlar karşılaştırılamaz hâle gelir. Bu yazıda WBS'in neden çıktı odaklı kurulduğunu, Activity ID kodlamasını, aktivite isim yapısını, Activity Type seçimini, takvim disiplinini ve KGM-DSİ pozlarıyla eşleştirmeyi bulacaksınız.

1. WBS Neden Çıktı Odaklıdır?

WBS (Work Breakdown Structure), projeyi teslim edilebilir çıktılara böler. PMI/PMBOK kılavuzunda da vurgulandığı gibi, WBS düğümü bittiğinde "elimde ne var" sorusunun fiziksel bir cevabı olmalıdır: bir kat, bir blok, bir disiplinin imalatı. P6 top-down (yukarıdan aşağıya) bir araçtır; önce teslimatları tanımlarsınız, aktiviteler bu teslimatlardan türeyen iş kalemleri olarak alt seviyeye düşer. Bu temel yapı taşlarını (WBS, Activity Code, Activity Type) Oracle'ın Primavera P6 ürün ailesi referans dokümantasyonu tarif eder; hangi mantıkla uygulanacağını ise her kurum kendi proje karakteristiğine göre standart hâline getirir.

Sahada üç farklı WBS mantığı yaygındır ve hangisinin seçileceği proje tipine bağlıdır:

• Lokasyon bazlı: Şantiye > Blok > Kat > Daire. Çok bloklu konut, TOKİ ve KİPTAŞ tipi siteler için doğal düşer. Hak ediş icmali blok bazında kesilir.
• Disiplin bazlı: Proje > Kaba inşaat > Mekanik > Elektrik > İnce işler. KGM yol projeleri ve endüstriyel tesislerde okunaklıdır.
• Faz bazlı: Mobilizasyon > Kazı > Temel > Üstyapı > Cephe > Devreye alma. DSİ baraj, arıtma tesisi ve enerji santrali tipi projelerde tercih edilir.

Pratikte bu üç mantık çoğunlukla melez kullanılır; üst seviye disiplin, orta seviye lokasyon, alt seviye iş paketi. Önemli olan kurum içinde tek bir şablonun benimsenmesi ve EPS > New Project ile her yeni proje açılışında aynı WBS iskeletinin Copy ile taşınması.

2. WBS Code ve Levels İçin Sade Kural

P6'da her WBS düğümü iki alana sahiptir: WBS Code (kısa alfasayısal kimlik) ve WBS Name (açıklayıcı ad). WBS Code projenin acronymiyle başlar, hiyerarşi seviyesine göre nokta ile uzar:

• Seviye 1 — KNT (proje acronymi, örn. "Konut")
• Seviye 2 — KNT.A (A blok)
• Seviye 3 — KNT.A.KAB (A blok kaba inşaat)
• Seviye 4 — KNT.A.KAB.K03 (A blok kaba inşaat 3. kat)

Yaygın hata, WBS'i sekiz dokuz seviyeye kadar derinleştirmek. Üç-dört seviye genel olarak yeterlidir; daha derin yapı toplam aktivite sayısını şişirir, schedule (F9) çalışma süresini uzatır ve raporlamayı zorlaştırır. Aktivitenin doğal yeri WBS'in altıdır, WBS'in ek bir seviyesi değildir. Türk kamu inşaatlarında KGM/DSİ pozları (örn. 16.001/A "kazı"), WBS'in en alt seviyesinde değil, aktivitenin Activity Code alanında etiketlenir — bu sayede aynı WBS düğümü altında birden fazla poz takip edilebilir.

3. Activity ID'de Akıllı Kod Neden Tuzak?

P6 dünyasında en sık kavga edilen konu Activity ID formatıdır. "Akıllı" görünmek isteyen planlayıcılar A-BLOK-K03-MEC-WS001 gibi içine lokasyon, disiplin, vardiya kodlanmış kimlikler üretirler. Bu yapı ilk bakışta okunabilir görünür ama üç pratik sorun çıkarır: aktivite başka bir bloğa kopyalandığında manuel düzeltme gerekir, ID alanı maksimum karakter sınırına dayanır, kolon genişliği rapor çıktısını bozar.

Saha dostu basit kural: Activity ID kısa ve tekrarlanmaz olsun, anlamı Activity Code taşısın.

• Prefix: WBS'e bağlı 1-3 harfli ön ek (örn. A A blok için, M mekanik için)
• Suffix: 4 haneli sıra numarası
• Increment: 10'ar artış — A1010, A1020, A1030... aralarda eklenebilir aktiviteler için yer bırakır

Lokasyon, disiplin, müteahhit, vardiya gibi bilgiler ID içine değil, Activity Codes alanına (Project Activity Code veya Global Activity Code olarak) eklenir. Bu sayede aynı aktivite hem "A blok" hem "Mekanik" hem "Vardiya 2" kodlarıyla etiketlenir; filtreleme ve raporlama esnekleşir. Enterprise > Activity Codes menüsünden tanımlanır, aktivite formunda atanır.

4. Activity Name Fiil İsim Yapısı

Aktivite ismi bir fiil + isim kalıbıyla yazılır. WBS düğümü "ne teslim ediliyor" sorusunu cevaplar (isim), aktivite "ne yapılıyor" sorusunu cevaplar (fiil + isim). Bu mantık aynı zamanda ilerleme raporlarında okunabilirliği artırır.

Lokasyon bilgisi gerekiyorsa fiil-isimden sonra eklenir. Bütün aktiviteler aynı dilbilgisinde tutulur — bazıları fiille başlayıp bazılarının isimle başlaması okumayı bozar. Türkçe pratikte fiil her zaman sona da alınabilir ("Bodrum perde betonu dökmek") — kurum içinde hangisi seçilirse tüm projelerde aynı şekilde uygulanır.

5. Hangi Activity Type Hangi Durumda?

P6'da bir aktivitenin nasıl scheduler tarafından hesaplanacağını Activity Type belirler. Yanlış tip seçilirse süre yanlış hesaplanır, kaynak yüklemesi sapar, milestone tablosu kayar:

• Task Dependent: Varsayılan tip. Süre, aktiviteye atanan Activity Calendar'a göre hesaplanır; resource calendar göz ardı edilir. Saha imalatının çoğu için doğru tercihtir (kazı, kalıp, beton, sıva).
• Resource Dependent: Süre, atanan kaynağın takvimine göre hesaplanır. Tek bir kaynağa bağlı uzmanlık işlerinde (örn. test mühendisi sertifikasyonu, vinç operatörü çalışması) kullanılır.
• Start Milestone / Finish Milestone: Sıfır süreli kilit noktalar. Süreleri yok ama tarih taşıyıcılarıdır — sözleşmesel teslim tarihleri, ara teslim noktaları, izin onayları milestone olarak işaretlenir.
• Level of Effort (LOE): Süresi öncül ve ardıl aktivitelere bağlı olarak otomatik hesaplanır. Saha şefliği, kalite kontrol, proje yönetimi gibi tüm proje süresince devam eden destek faaliyetleri için uygundur. Resource Leveling sırasında LOE aktiviteleri yok sayılır.
• WBS Summary: Alt seviye aktivitelerin başlangıç ve bitişini özetleyen üst seviye etiket. Üst yönetim raporu için pratiktir.

Türk kamu projelerinde sık karşılaşılan bir hata, şantiye yöneticisi maaşını veya jenerik mobilizasyon-demobilizasyon kalemlerini Task Dependent açıp manuel süre vermek. Doğru yaklaşım LOE tipidir — başka aktiviteler değişince süresi otomatik güncellenir, manuel müdahale gerekmez.

6. Calendar Türk Tatil Düzeniyle Uyumlu

P6 takvim (Calendar) ayarı, schedule hesabının sessiz arka planıdır. Yanlış takvim, aylar sonra "neden bitiş tarihi 15 gün öteye kayıyor" şeklinde çıkar. Enterprise > Calendars menüsünden üç ayrı havuz tanımlanabilir:

• Global Calendar: Tüm projeler için ortak (örn. "TR Standart 6 gün")
• Project Calendar: Tek bir projeye özel
• Resource Calendar: Belirli bir kaynağa özel (vardiyalı çalışan operatör için)

Türk inşaat sahasında pratik standart 6 gün × 8 saat (Pazartesi-Cumartesi), saatlik girilen iş günü 08:00-12:00 ve 13:00-17:00. Resmi tatiller (29 Ekim, Ramazan ve Kurban Bayramı, 1 Mayıs vb.) Global Calendar'a yıllık bazda işaretlenir. Bayram tatilleri Hicri takvimle her yıl kaydığı için en az 2 yıllık projelerde bayram tarihleri ileriye taşınmalı. Mevsimsel kısıtlar (kış aylarında beton dökümü kısıtı, yağışlı dönemde kazı duraksaması) Activity Calendar düzeyinde ayrı bir takvim açılarak modellenir.

7. Activity Code KGM DSİ Pozlarıyla Nasıl Eşlenir?

Türk kamu altyapı ve bayındırlık projelerinde planlama, hak ediş ile aynı kodlama dilini paylaşmalı. KGM birim fiyat poz numaraları (örn. 16.001/A, 21.054, KGM-04.250) ve DSİ pozları (örn. DSİ-31.301) bütçe ve hak ediş tarafında tanımlı. Aktivite tarafında bu pozların yansıması için Activity Code alanı kullanılır:

1. Enterprise > Activity Codes > Global tab > "POZ-NO" kodu tanımla
2. İlgili pozları value olarak ekle (16.001/A, 16.002/A, 21.054 vb.)
3. Aktivite formunda Codes sekmesinden ilgili pozu ata
4. Aktivite Usage sekmesinden Activity Code bazlı pivot/filtre al

Bu eşleme yapıldığında aylık ilerleme raporu doğrudan poz bazlı kesilir; hak ediş icmali için ayrıca Excel çalışması yapılmasına gerek kalmaz. Kontrol mühendisi yüzde fiziksel ilerleme ile poz birim miktarını çapraz doğrularken aynı raporu okur — saha ve ofis aynı dilden konuşmaya başlar.

8. İlişki Disiplini ve Lag Açıklaması

Aktiviteler arası ilişkiler scheduler'ın kritik yolu hesaplamasının temeli. Standart bir kurguda dört ilişki tipi tanımlıdır ama sahada üçü baskındır:

• FS (Finish to Start): Klasik sıralı bağ — kalıp söküldükten sonra şap başlar.
• SS (Start to Start): Paralel bağ — kazı başladıktan 3 gün sonra iksa başlar, SS+3d.
• FF (Finish to Finish): Eş zamanlı tamamlanma — boya, iç sıvanın bitişinden 2 gün sonra biter, FF+2d.
• SF (Start to Finish): Çok nadir — vardiya devrinde eski vardiya yeni başlamadan bitmemeli.

Lag (gecikme) değerleri sahada savunulabilir olmalı; "schedule güzel görünsün" diye eklenen lag baseline aşamasında sorgulanır. KGM kontrol amirliği genellikle 30 günü aşan bekleme sürelerini lag içine değil, ayrı bir kürlenme veya onay bekleme aktivitesi olarak ister — gerekçesi açık görünür ve hak edişte denetlenebilir olur.

9. Sıfırdan Kurulum Şablonu

Yeni proje açılışında uygulanan kontrol listesi, kurum içi standardın somut hâlidir:

• EPS altında doğru node, proje acronymi belirlenmiş
• Calendar: TR Standart 6×8, resmi tatiller ve hareketli bayramlar yüklü
• WBS şablonu kopyalanmış, 3-4 seviye derinlik
• WBS Code: proje acronymi + nokta + alt kırılım
• Activity ID: prefix + 10'ar artan suffix, akıllı kod yok
• Activity Name: fiil + isim kalıbı, kurum içi sözlüğe uygun
• Activity Type: imalat Task Dependent, milestone'lar Start/Finish Milestone, destek faaliyetleri LOE
• Activity Codes: Disiplin, Lokasyon, Müteahhit, KGM/DSİ Pozu kodları atanmış
• İlişki: varsayılan FS, lag açıklamalı veya ayrı aktivite
• Resource pool: kurum genel havuzdan
• Baseline: schedule onayından sonra ilk gün alınmış
• Data Date güncellemesi: haftalık, Cuma 17:00

Bu şablon kurum içinde bir kez yazılır, Project > Copy ile yeni projeye taşınır. Her planlamacının kendi yöntemini kurmasına izin vermek, üç ay sonra portföy raporunun çökmesi demektir. P6'nın gücü tek bir projede değil, onlarca projenin aynı dilde konuşabilmesindedir. Yapısal bir P6 kurgu öğrenimi için Primavera eğitimi WBS hiyerarşisi, Activity ID disiplini ve EVM zincirini gerçek projeler üzerinden işler; daha hafif süre planlaması arayanlar için MS Project eğitimi alternatif bir başlangıç sunar.

10. Standart Nasıl Sürdürülebilir Kılınır?

Standart bir kez yazıldıktan sonra denetlenmediği takdirde altı ay içinde aşınır. Yeni gelen planlamacı kendi alışkanlığını ekler, üst yönetim "biraz daha detay istiyorum" diyerek seviye derinleştirir, müteahhit hak ediş için ayrı kod ister. Standardı koruyan üç pratik kural vardır.

Birincisi, kurum içinde bir master template proje tutulur. EPS altında "00-Master" gibi sürekli güncel kalan, hiçbir gerçek aktivitesi olmayan iskelet proje. Yeni proje her zaman bu master'dan kopyalanır.

İkincisi, schedule review disiplini. Her ay sonu kontrol amirliği veya planlama şefi 10 dakikalık bir review yapar: Activity ID'ler standart mı, WBS seviye derinleşmiş mi, lag değerleri açıklanmış mı, milestone tipleri doğru mu. Bulunan sapmalar planlamacıya geri verilir.

Üçüncüsü, portföy raporu doğal denetimdir. Üst yönetime gönderilen aylık özet rapor, kurum standardının uygulanıp uygulanmadığını görsel olarak ortaya koyar. Bir projenin grafiği diğerlerinden farklı şekilleniyorsa, o projenin kurgusu sapmıştır. Standart belirlemek bir kerelik bir iş değil, her ay yeniden hatırlatılması gereken bir kurum disiplinidir.