PRİMAVERA P6’DA RESOURCE LOADİNG VE LEVELLİNG UYGULAMAK

Bir proje takvimi “mantıklı” görünebilir ama ekip gerçek hayatta o planı taşıyamıyorsa, Gantt şeması sadece iyi niyetli bir tahmindir. Primavera P6’da resource loading ve resource levelling uygulamak, işlerin kimin üzerinde biriktiğini görünür kılar ve takvimi “yapılabilir” hale getirir.

Bu makalede, P6’da kaynak yüklemesini doğru kurmaktan başlayıp, aşırı yüklenmeleri analiz etmeye ve levelling ile dengeli bir plan üretmeye kadar uçtan uca bir yaklaşım bulacaksınız. Ayrıca, kurumlarda en sık yapılan hataları ve karar vericilerin takip edebileceği metrikleri de netleştireceğiz.

Eğer P6’yı proje kontrol, planlama veya PMO perspektifiyle kullanıyor; gerçekçi kapasite planı ve izlenebilir kaynak stratejisi üretmek istiyorsanız, aşağıdaki adımlar sizi hızlıca sağlam bir standarda taşır.

Primavera P6’da kaynak yüklemesini doğru planlamak

Resource loading, aktiviteler üzerine kaynak atayıp bu atamaların zaman içinde nasıl bir talep yarattığını hesaplatmaktır. P6, bu hesaplamayı aktivite süreleri, takvimler, birim/zaman (units/time), aktivite tipleri ve remaining work mantığıyla yapar. Bu yüzden, “önce atama yapıp sonra bakarız” yaklaşımı çoğu zaman yanlış sonuç verir.

Sağlıklı bir yükleme için minimum kontrol listesi şudur: (1) aktivite takvimleri doğru mu, (2) süre tipi ve fiziksel ilerleme mantığı tutarlı mı, (3) kaynaklar doğru “Max Units/Time” ve takvimle mi tanımlı, (4) aktiviteye atanan units ve remaining units mantığı belirlenmiş mi. Bu temeller doğru değilse levelling, hatalı veriyi daha da “resmi” hale getirir.

Activity Duration Type seçimini standardize etmek

P6’da Duration Type; bir aktivitenin süresi değiştiğinde, kaynak birimlerinin ve toplam iş miktarının nasıl etkileneceğini belirler. Kurumsal senaryolarda en yaygın yaklaşım; tekrarlanabilir işlerde iş miktarını sabit tutup süreyi kapasiteye göre yönetmek, tasarım gibi “zaman-kritik” işlerde ise süreyi sabit tutmaktır. Önemli olan, aynı WBS altında rastgele Duration Type karışıklığı yaratmamaktır.

Resource Calendar ve Max Units/Time kurgulamak

Kapasiteyi doğru okumak için kaynağın takvimi ile projenin takvimi uyumlu olmalıdır. Örneğin saha ekibi 6 gün çalışırken ofis ekibi 5 gün çalışıyorsa, hepsini tek takvime bağlamak kaynak yüklerini yapay şekilde şişirir veya saklar. Ayrıca Max Units/Time değerleri (ör. 8h/day veya 1 FTE) şirket standardına göre tanımlanmalı; yarı zamanlı kaynaklarda bu değer açıkça düşürülmelidir.

Kaynak atamalarını veri kalitesiyle yönetmek

Resource loading’in çıktıları; atamalar ve bu atamaların dağıtım mantığı kadar “veri temizliği”ne de bağlıdır. P6’da aynı kaynağın hem “labor” hem “nonlabor” gibi tutarsız türlerde tekrar tanımlanması, roll ile resource’un birbirine karıştırılması veya yanlış UOM kullanımı raporları bozabilir.

Kurumsal ölçekte ideal yöntem; önce rol bazlı planı kurmak, sonra kritik paketlerde role karşılık gelen gerçek personel kaynaklarına dönmektir. Böylece hem erken fazlarda plan yapmak kolaylaşır hem de ilerleyen fazlarda gerçek kapasiteyi ölçmek mümkün olur. Özellikle PMO’lar için bu yaklaşım, portföy seviyesinde karşılaştırılabilirlik sağlar.

Roles ile erken faz kapasite tahmini yapmak

Roller, “kim”den bağımsız olarak “hangi uzmanlık” gerektiğini ifade eder. Erken fazda rollerle plan yapıp, kaynak havuzu netleşince rollerin yerini gerçek kaynaklarla değiştirmek; hem esneklik hem de izlenebilirlik sağlar. Burada dikkat edilmesi gereken, role atanmış units değerlerinin daha sonra gerçek kaynağa aktarılırken kaybolmamasıdır.

Units, Remaining Units ve Actual Units tutarlılığını korumak

Kaynak yükleri çoğu zaman “actual” girişleriyle bozulur. Örneğin, %Complete girerken actual units girilmez veya remaining units yanlış güncellenirse, P6 kalan yükü hatalı dağıtır. Bu nedenle, ilerleme metodunuzla (Physical %, Duration %, Units %) uyumlu bir veri giriş standardı belirlemek gerekir. Progress ölçüm yöntemi ile work hesap mantığı aynı dili konuşmalıdır.

Aşırı yüklenmeleri görünür kılmak ve teşhis etmek

Loading sonrası ilk hedef; hangi kaynakların ne zaman aşırı yüklendiğini net görmektir. P6’da bunun için Resource Usage Profile, Resource Usage Spreadsheet ve Activity Usage Spreadsheet gibi görünümler kullanılır. Buradaki kritik nokta, raporun time period (day/week/month) ayarının karar anınıza uygun olmasıdır: haftalık planlama için günlük detay çoğu zaman gürültü yaratır.

Teşhiste iki soru çok belirleyicidir: Aşırı yüklenme “gerçek” mi yoksa veri hatası mı? Ve gerçekse, bunun sebebi paralel iş mi, yanlış takvim mi, yoksa yanlış units dağıtımı mı? Bu ayrımı hızlı yapmak için, belirli filtreler ve kontrol hesapları kullanmak faydalıdır.

Resource Usage Profile ile pik yükleri yakalamak

Resource Usage Profile, histogram benzeri bir görünümle belirli periyotlarda units talebini gösterir. Piklerin hangi aktivitelerden geldiğini görmek için, ilgili periyotta drill-down yapıp aktiviteleri sıralamak gerekir. Özellikle “aynı anda başlatılmış” işler, kritik yol dışı görünse bile ekip kapasitesini kilitleyebilir.

Baseline ile planlanan kapasite farkını izlemek

Resource loading’i sadece mevcut takvimde izlemek yerine, baseline ile kıyaslamak sapmaları daha erken gösterir. Baseline sonrası artan yük, scope genişlemesi veya yanlış yeniden planlamanın işareti olabilir. Bu kıyas; PMO raporlarında “planlanan FTE” ile “güncel talep” arasındaki farkı somutlaştırır.

Resource levelling ayarlarını güvenli uygulamak

Levelling, aşırı yüklenmeleri çözmek için aktivitelerin zamanlamasını P6’nın belirli kurallarına göre kaydırmasıdır. Ancak levelling “sihirli değnek” değildir; yanlış ayarla çalıştırılırsa kritik teslim tarihlerini öteleyebilir, gereksiz boşluklar yaratabilir veya öncelik mantığını bozabilir. Bu yüzden levelling’i, önce kural setini netleştirip sonra kontrollü bir senaryo olarak uygulamak gerekir.

En iyi pratik; levelling’i doğrudan ana programda değil, bir kopya üzerinde senaryo olarak çalıştırmaktır. Sonuçlar kabul edilirse, belirli WBS veya belirli kaynak grupları için aşamalı şekilde ana programa taşınır. Böylece tek bir butonla tüm projeyi “yeniden yazmak” yerine, kontrollü optimizasyon yapılır.

Levelling Priority sıralamasını kurumsal yapmak

Levelling Priority; P6’nın hangi aktiviteyi önce koruyacağını, hangisini kaydıracağını belirler. Kurumsal kullanımda yaygın yaklaşım; kritik aktiviteleri, sözleşme tarihlerini ve saha mobilizasyonlarını öncelikli tutmaktır. Örneğin; “Activity Total Float” ve “Activity ID” gibi alanları tek başına bırakmak yerine, “priority” veya “driving path” mantığını destekleyen alanlarla birlikte değerlendirmek gerekir.

Constraints ve riskli kısıtları yönetmek

“Must Finish By” gibi sert kısıtlar levelling’i kilitleyebilir; P6 kaynak sorununu çözemeyince farklı yerlerde gereksiz kaydırmalar yapabilir. Kısıtları, teslim tarihi yönetimi için kullanırken kapasite çözümünü imkânsız hale getirmemek gerekir. Burada amaç; kısıtları minimumda tutup, teslim tarihini daha çok mantıksal ilişkiler ve milestone yapısı ile yönetmektir.

Split ve overtime gibi seçenekleri bilinçli kullanmak

Bazı organizasyonlar levelling sırasında aktivitelerin bölünmesine (split) izin verir; bazıları bunu istemez. Split, kapasiteyi dengeleyebilir ama sahada kesintili çalışma pratikte verimsizlik yaratabilir. Benzer şekilde overtime, takvimi korur ama maliyet ve ekip yorgunluğu riskini artırır. Bu seçenekler; planın gerçek operasyonel davranışı ile uyumlu değilse, çıktılar kabul görmez.

// Örnek: Levelling öncesi hızlı kontrol için filtre mantığı (pseudo)
// Amaç: Total Float düşük, aynı hafta yüksek units talebi olan aktiviteleri listelemek
FILTER "Overload_Risk_Week":
  IF (Activity.TotalFloat <= 5) AND (Assignment.RemainingUnits > 40) AND (Activity.Status = "Not Started")
  THEN SHOW ActivityID, ActivityName, WBS, TotalFloat, RemainingUnits, PlannedStart, PlannedFinish
// Not: Kurum standardında RemainingUnits eşik değeri rol/ekip tipine göre değiştirilebilir

Senaryo bazlı dengeleme yaklaşımını uygulamak

Resource levelling’i tek seferde tüm proje üzerinde çalıştırmak yerine, senaryo bazlı ilerlemek daha güvenlidir. Örneğin önce sadece “kritik uzmanlık” kaynaklarını (tasarım lideri, saha süpervizörü, test ekibi gibi) hedefleyebilir; diğer kaynakları sabit tutabilirsiniz. Böylece projenin tümünü değil, darboğaz yaratan alanları optimize etmiş olursunuz.

Senaryo yaklaşımında temel akış şöyledir: (1) mevcut programı kopyala, (2) ilgili kaynak grubunu seç, (3) levelling seçeneklerini kurumsal şablondan uygula, (4) sonuçları baseline ve milestone tarihleriyle kıyasla, (5) kabul edilen değişiklikleri ana programa kontrollü taşı. Bu akış, PMO onay süreçlerini de kolaylaştırır.

WBS ve phase bazında levelling çalıştırmak

Özellikle büyük projelerde levelling’i WBS bazında yapmak, yerel optimizasyon sağlar. Örneğin “Design” fazında tasarım kaynaklarını dengelemek, “Construction” fazındaki saha teslimlerini etkilemeden kapasite sorunlarını azaltır. Ancak WBS sınırı koyarken, fazlar arası bağımlılıkların doğru kurulduğundan emin olmak gerekir.

Raporlamayı ve yönetişimi sürdürülebilir kılmak

Loading ve levelling bir defalık “düzeltme” değil, periyodik bir yönetişim pratiğidir. Haftalık veya iki haftalık periyotlarda; kaynak yükleri, kritik uzmanlık darboğazları ve teslim tarihleri bir arada gözden geçirilmelidir. Bu toplantılarda amaç; “kimin çok işi var” tartışması değil, kapasiteyi planla uyumlu hale getiren kararları hızlandırmaktır.

Karar vericiler için en faydalı çıktılar; (1) pik yüklenen kaynak listesi, (2) pik yüklerin hangi WBS’lerden geldiği, (3) levelling sonrası milestone etkisi, (4) ilave kapasite ihtiyacının kaç hafta sürdüğü gibi özetlerdir. Bu özetler, bütçe ve outsource kararlarını veriyle destekler.

Kurumsal şablonlarla tekrarlanabilir süreç kurmak

P6’da görünüm, filtre ve rapor şablonlarını standartlaştırmak; farklı projeler arasında kıyaslamayı kolaylaştırır. Ayrıca levelling seçeneklerinin “kurumsal profil” olarak tanımlanması, her planlamacının farklı buton kombinasyonlarıyla farklı sonuçlar üretmesini engeller. Bu standardı oluştururken, saha ve ofis ekiplerinden geri bildirim almak kritik önemdedir.

İç eğitim ve ortak dil geliştirmek

Kaynak yönetimi, sadece planlama ekibinin değil; proje yöneticisi, disiplin liderleri ve hatta satın alma ekiplerinin ortak dilidir. Bu yüzden kavramları ekibe yaymak, planın kabul edilmesini hızlandırır. İhtiyaç duyarsanız Primavera eğitimi içerikleriyle ekibin aynı standarda gelmesini destekleyebilirsiniz.

# Örnek: Levelling sonrası kabul kontrol checklist'i (uygulanabilir bir şablon)
1) Milestone tarihleri: Kritik teslimler değişti mi?
2) Critical Path / Driving Path: Değişim mantıklı mı?
3) Total Float dağılımı: Negatif float oluştu mu?
4) Resource peaks: Pikler azaldı mı, başka haftaya mı taşındı?
5) Split aktiviteler: Operasyonel olarak kabul edilebilir mi?
6) Calendar uyumu: Kaynak takvimi ile proje takvimi çakışıyor mu?
7) Baseline kıyası: Planlanan vs güncel talep farkı raporlandı mı?

Yaygın hataları önceden engellemek

Pratikte en sık görülen hata; P6’da yanlış takvim, yanlış Duration Type ve eksik progress girişleriyle resource loading’e güvenmektir. Bu durumda histogramlar “ikna edici” görünür ama gerçek kapasiteyi temsil etmez. İkinci yaygın hata ise levelling’i bir kere çalıştırıp çıktıyı sorgulamadan kabul etmektir.

İyi bir kontrol yaklaşımı; veriyi önce temizlemek, sonra loading çıktısını teşhis etmek, ardından levelling’i senaryo olarak uygulamak ve sonuçları yönetim metrikleriyle doğrulamaktır. Böyle yaptığınızda, takvim “güzel” olduğu için değil, uygulanabilir olduğu için güvenilir hale gelir.

Özet: Primavera P6’da resource loading ile talebi ölçer, resource levelling ile takvimi kapasiteye uyarlarsınız. Başarının anahtarı; veri standardı kurmak, aşırı yüklenmeyi doğru teşhis etmek ve levelling’i kontrollü senaryolarla uygulamaktır.