PRİMAVERA P6’DA WBS VE AKTİVİTE STANDARTLARI BELİRLEMEK

Primavera P6, tek bir proje planlama aracı olmaktan çok, kurumsal ölçekte zaman çizelgesi verisini yöneten bir omurga gibi çalışır. Bu yüzden aynı portföy içinde “her proje kendi bildiği gibi” WBS kurar ve aktivite adlandırırsa, bir süre sonra raporlama gücü düşer, karşılaştırma zorlaşır ve plan kalitesi tartışmalı hale gelir.

WBS ve aktivite standartları belirlemek, yalnızca isimleri düzenlemek değildir; kurumun planlama dilini tanımlamak demektir. Bu dil; hiyerarşi seviyeleri, kodlama mantığı, aktivite kimlik yapısı, takvim kullanımı, kod sözlüğü, şablon yönetimi ve kalite kontrolleriyle birlikte çalışır. Doğru kurgulandığında, aynı KPI’ları tüm projelerde tutarlı görmek ve veriyle konuşmak mümkün olur.

Bu makalede, Primavera P6’da WBS ve aktivite standartlarını adım adım kurgulayıp hayata geçirmeye odaklanıyoruz. Uygulamalı örnekler, kod blokları ve yönetişim yaklaşımıyla birlikte, ekibinizin farklı projelerde aynı standardı sürdürülebilir şekilde uygulaması hedeflenir. Daha kapsamlı pratik için Primavera eğitimi sayfasına da göz atabilirsiniz.

WBS standartlarını kurum genelinde tanımlamak

WBS (Work Breakdown Structure), P6’daki tüm planlama mantığının taşıyıcısıdır. Standart belirlemek, her projenin WBS’i “benzersiz ama uyumlu” olacak şekilde üretmesini sağlamaktır. Buradaki amaç; farklı projelerin farklı ihtiyaçlarına izin verirken, üst yönetim raporlaması için ortak bir çerçeve korumaktır.

Başlangıçta şu sorulara net cevap vermek gerekir: WBS seviyeleri kaç katmanlı olacak? Her seviyenin anlamı ne? Disiplin mi, lokasyon mu, teslimat mı, faz mı? Tek bir doğru yoktur; ancak kurum içinde tek bir yaklaşım olmalıdır. Aksi halde aynı projenin iki farklı planlamacı tarafından farklı biçimde parçalanması kaçınılmazdır.

Projeye göre WBS seviyelerini kurgulamak

WBS seviyelerini kurgularken “rapor ihtiyaçları” ile “saha gerçekliği” arasında denge kurmak gerekir. Çok derin WBS, güncelleme yükünü artırır; çok sığ WBS ise detay analizi kısıtlar. Kurumsal bir pratik olarak 3–5 seviye çoğu portföy için dengeli bir aralık olur.

Örnek bir yaklaşım aşağıdaki gibi kurgulanabilir:

• Seviye 1: Proje Fazı (Tasarım, Tedarik, İnşaat, Devreye Alma)
• Seviye 2: Teslimat veya Sistem (Alt Sistemler, Ürün Aileleri)
• Seviye 3: Disiplin veya Lokasyon (Elektrik, Mekanik, Saha Bölgesi)
• Seviye 4: Çalışma Paketi (İş Emri, Paket, Lot)

Bu yapı, farklı proje tiplerine adapte edilebilir; ancak seviyelerin anlamı değişmemelidir. Örneğin bir projede Seviye 2 “sistem” iken diğerinde “lokasyon” olursa, portföy raporları bozulur.

WBS kodlama ve adlandırma sözlüğü hazırlamak

P6’da WBS “Code” alanı ve “Name” alanı birlikte çalışır. Kod, makine için; isim, insan için daha faydalıdır. Kodun kısa, benzersiz, tutarlı; ismin ise anlaşılır ve standarda bağlı olması beklenir.

Kurumsal bir sözlük oluştururken şu ilkeler pratik sonuç verir:

• Kodlarda boşluk kullanmamak ve tire/alt çizgi standardını sabitlemek
• Faz kodlarını sabit tutmak (ör. DES, PROC, CONST, COM)
• İsimlerde aynı kelime dizilimini korumak (ör. “Sistem – Disiplin – İş Paketi”)
• Kısaltma listesini tek kaynakta yönetmek (PMO sözlüğü)

Bu sözlük, sadece doküman olarak kalmamalı; şablon projeye gömülmeli ve yeni proje açılışında uygulanmalıdır. Böylece standart sapması erken aşamada önlenir.

Aktivite kimlik ve isim kuralları koymak

Aktivite standardı, plan kalitesinin en görünür katmanıdır. Bir aktivite ID’si rastgele üretildiğinde; filtreleme, entegrasyon ve raporlama zorlaşır. Benzer şekilde, aktivite adları “Genel işler”, “Çeşitli” gibi belirsiz yazıldığında, plan anlamını kaybeder.

Burada hedef; aktivite kimlik yapısı, adlandırma şablonu, aktivite türleri ve ölçülebilir çıktı tanımıyla birlikte, planı hem yönetilebilir hem denetlenebilir hale getirmektir. Özellikle büyük portföylerde bu yaklaşım, karşılaştırılabilir çizelgeler üretmeyi kolaylaştırır.

Activity ID formatını tutarlı şekilde belirlemek

Activity ID formatı; WBS ile ilişki kuran, fazı ve iş paketini taşıyan bir şema olmalıdır. Çok uzun ID’ler kullanıcıyı yorar; çok kısa ID’ler anlam taşımaz. Uygulanabilir bir pratik, 3–5 parçalı bir şema kullanmaktır.

Aşağıdaki örnek, faz + disiplin + sıra mantığıyla çalışır:

Format: {FAZ}-{DIS}-{SEQ}
Örnekler:
DES-ENG-0010
PROC-PRC-0150
CONST-ELE-1200

Kurallar:
- FAZ: DES | PROC | CONST | COM
- DIS: ENG | CIV | ELE | MEC | INS
- SEQ: 4 haneli, 10'ar artış (0010, 0020, 0030...)

SEQ alanını 10’ar artışla vermek, araya yeni aktivite eklemeyi kolaylaştırır. Ayrıca entegrasyon sistemleri (ERP, EAM, doküman yönetimi) Activity ID üzerinden eşleşme yapacaksa, bu standardın değişmemesi kritik olur.

Aktivite adlarını eylem odaklı yazmak

Aktivite adı, kontrol toplantılarında herkesin baktığı satırdır. Bu yüzden adlar; çıktı, kapsam ve eylem içerir biçimde yazılmalıdır. “Kablo işleri” yerine “Kablo çekimini tamamlamak” gibi bir ifade, hem ölçülebilir hem de net bir kapanış kriteri sağlar.

Pratik bir adlandırma şablonu şöyle uygulanabilir:

• “Neyi + nerede + hangi kapsamda” sıralaması kullanmak
• Fiille bitirmek (tamamlamak, kurmak, test etmek, devreye almak)
• Tek satırda ölçülebilir olmak (başlangıç-bitiş kriteri anlaşılmak)

Ayrıca, P6’da Activity Type ve % Complete Type alanlarını standarda bağlamak gerekir. Örneğin inşaat aktivitelerinde “Physical” veya “Duration” kullanımını kurala bağlamak, ilerleme raporlarını daha tutarlı yapar.

Takvim, taksimat ve kodları standardize etmek

WBS ve aktivite isimleri tutarlı olsa bile, takvimler ve kodlar standart değilse çizelge davranışı farklılaşır. Aynı iş, bir projede 6 gün/hafta çalışılan takvimde; diğerinde 5 gün/hafta takvimde planlanırsa, portföy karşılaştırması anlamsızlaşır. Bu nedenle takvim sözlüğü, çalışma saatleri, resmi tatiller ve vardiya yapısı kurumsal politika ile uyumlu olmalıdır.

Benzer şekilde Activity Codes ve UDF (User Defined Fields) yapısı, raporlamayı güçlendirir. Doğru kod seti, “hangi lokasyon”, “hangi paket”, “hangi sorumlu ekip”, “hangi teslimat” gibi soruları tek tıklamayla yanıtlamayı sağlar.

Takvim tiplerini ve tatilleri yönetmek

Kurumsal ölçekte genellikle üç takvim sınıfı yeterli olur: ofis işleri, saha işleri ve 7/24 kritik operasyon. Takvim sayısını gereksiz artırmak, bakım yükü getirir; çok az takvim ise gerçekçi plan üretimini zorlaştırır.

Aşağıdaki örnek politika, PMO düzeyinde uygulanabilir:

Calendar Policy:
- CAL-OFFICE: 5x8 (Pzt-Cum, 09:00-18:00)
- CAL-SITE:   6x10 (Pzt-Cmt, 08:00-19:00)
- CAL-OPS:    7x24 (kritik operasyon ve devreye alma)

Holiday Rules:
- Resmi tatiller kurumsal liste üzerinden yıllık güncellenir
- Saha özel kapama günleri proje bazlı eklenir (istisna yönetimi)
- Takvim değişikliği sadece PMO onayıyla yapılır

Bu yaklaşım, çizelgenin davranışını standarda bağlar. Özellikle kaynak yükleme ve S-curve gibi analizlerde, takvim tutarlılığı doğrudan sonuç kalitesini belirler.

Şablon proje ve governance akışı kurmak

Standartları yazmak yetmez; standartların uygulanacağı bir şablon (template) ve yönetişim (governance) akışı kurmak gerekir. P6’da şablon proje, WBS iskeletini, aktivite kodlarını, takvimleri, UDF alanlarını ve rapor düzenlerini tek pakette taşır. Böylece yeni proje açılışları hızlı ve tutarlı olur.

Yönetişim tarafında ise “kim oluşturur, kim onaylar, kim değiştirir” net olmalıdır. Aksi halde her proje ekibi, sahadaki baskıyla standardı esnetmeye başlar. Burada kritik nokta; esneklik ihtiyacını “istisna süreci”yle yönetmek ve standardı rastgele deldirmemektir.

EPS, OBS ve güvenlik rolleri ayarlamak

EPS (Enterprise Project Structure) ve OBS (Organizational Breakdown Structure), yetki ve rapor hiyerarşisinin temelidir. EPS doğru kurgulanmazsa, şablon ve standartlar yanlış klasörlerde çoğalır. OBS doğru kurgulanmazsa, onay süreçleri kağıt üzerinde kalır.

Kurumsal pratikte şu ayrım iş görür:

• EPS üst seviyede iş birimi/portföy mantığıyla parçalanmak
• Şablon projelerin ayrı bir EPS dalında tutulmak
• Rol bazlı güvenlik (Planner, Project Controls, PM, Viewer) tanımlamak

Böylece standartlara müdahale edebilecek kullanıcı sayısı sınırlanır ve “tek kaynaktan yönetim” mümkün olur.

Kalite kontrol metrikleriyle denetlemek

Standartların sürdürülebilirliği için ölçüm gerekir. Schedule quality metrikleri, hem planın teknik doğruluğunu hem de standarda uyumunu görünür kılar. Örneğin; aşırı uzun aktiviteler, fazla sayıda kısıt, eksik mantık bağları, mantıksız lag kullanımı gibi problemler, kurumsal denetim listesinde yer almalıdır.

Aşağıdaki kontrol listesi, haftalık ya da aylık denetimde kullanılabilir:

• Aktivite süresi sınırı (ör. 20 iş günü üstü istisna)
• Hard constraint oranı ve gerekçesinin kayıt altına alınması
• Open-ended activity (başlangıç/bitiş bağı olmayan) sayısının minimize edilmesi
• WBS seviyelerinde boş/duble kod bulunmaması
• Aktivite adlarının fiille bitmesi ve şablona uyması

Bu metrikleri raporlamak için Activity Codes veya UDF alanlarını kullanmak, denetimi otomatikleştirmeye yardımcı olur.

İthalat, sürümleme ve değişiklikleri izlemek

Standartları hayata geçirmenin en hızlı yollarından biri, toplu güncelleme ve kontrollü sürümleme yaklaşımıdır. P6 içinde Global Change, import/export ve SDK entegrasyonları; standart dışı veriyi hızla toparlamayı sağlar. Ancak bu araçlar yanlış kullanıldığında, planın mantık bağları bozulabilir veya sahadaki ekip güven kaybedebilir.

Bu nedenle “değişiklik yönetimi” adımı kritik olur. Baseline stratejisi, revizyon isimlendirmesi, onay akışı ve değişiklik log’u birlikte tasarlanmalıdır. Böylece yeni standartların uygulanması sırasında, planın önceki sürümleriyle karşılaştırma yapmak ve etkileri ölçmek mümkün olur.

Excel import ile toplu güncellemek

Özellikle aktivite adları, kodlar ve bazı UDF alanları için Excel üzerinden import yapmak pratik bir yaklaşımdır. Burada önemli olan; doğru kolonların taşınması ve geri dönüşte veri tiplerinin korunmasıdır. Aşağıdaki örnek, Excel’de hazırlanan bir import setinin mantığını gösterir:

Columns for Activity Update:
- Project ID
- Activity ID
- Activity Name
- WBS
- Activity Code: Discipline
- Activity Code: Location
- UDF: Deliverable Type
- UDF: Reporting Package

Best Practices:
- Activity ID değiştirilecekse önce eşleşme tablosu hazırlanır
- Toplu değişiklik öncesi baseline alınır
- Import sonrası örneklem kontrol (spot check) yapılır

Toplu güncelleme süreçlerinde, bir “pilot proje” seçip önce orada uygulamak; tüm portföye yaymadan önce riskleri azaltır. Ayrıca bir değişiklik paketi yayınlandığında, PMO’nun “ne değişti” özetini paylaşması, ekiplerin standarda güvenmesini destekler.

Standartları yaşatacak eğitim ve alışkanlıklar kurmak

Teknik standartlar, insan alışkanlıklarıyla birlikte yaşar. Planlama ekibi, proje yöneticileri ve saha sorumluları; WBS ve aktivite dilini ortak kullanmadıkça, standardın sürdürülebilirliği zorlaşır. Bu nedenle şablon, kontrol listesi ve onay akışının yanında kısa eğitim modülleri ve örnek kütüphanesi oluşturmak faydalıdır.

Kurumsal ölçekte şu uygulamalar, standardı “doküman” olmaktan çıkarıp “alışkanlık” haline getirir:

• Yeni proje açılışında standart kontrol toplantısı yapmak
• İlk iki haftada WBS ve aktivite isim denetimi yapmak
• Örnek iyi uygulamaları paylaşmak ve kütüphanelemek
• İstisna taleplerini kayıt altına alıp öğrenim üretmek

Sonuçta hedef; Primavera P6’da WBS ve aktivite standartları belirleyerek, projelerin plan kalitesini yükseltmek, portföy raporlamasını güçlendirmek ve veriyi uzun vadede sürdürülebilir kılmaktır. Bu yaklaşım, sadece planlamacının işini değil; karar vericinin doğru ve tutarlı bilgiye erişimini de iyileştirir.