Bir satırın türü,bütün planın davranışı.

İki görselde gördüğünüz şey nedir?

İki görsel, Primavera P6’daki Activity Type / Aktivite Türü açılır listesini gösteriyor. Bu alan, seçili aktivitenin planlama hesabında nasıl davranacağını belirler. Bir imalatın çalışma süresini mi temsil edeceği, yalnız bir olay anı mı olacağı, tarihlerini ilişkili işlerden mi yoksa WBS içeriğinden mi alacağı burada seçilir.

İki listede sıralama farklı olsa da seçenekler birebir eşleşir. Her iki görselde aynı tür seçilidir. Sağ kenarlardaki kesilmiş alanlardan diğer aktivite ayarlarını veya yazılımın tam sürümünü belirlemek mümkün değildir; dolayısıyla burada görünen alanın anlamını açıklıyoruz.

Doğrulama: Oracle — Activity types · Primavera vault: Aktivite Tipleri. Görseller kullanıcı tarafından sağlanmıştır.

Bu kılavuz nasıl okunmalı?

Yeni başlayanlar 1–9. bölümleri sırayla okusun. Günlük P6 kullanıcıları 10–14. bölümlerdeki seçim ve güncelleme akışını uygulasın. İleri kullanıcılar 15–19. bölümlerdeki istisnaları, kontrol sorularını ve kaynak notlarını incelesin. Örnek hesaplar eğitim için oluşturulmuştur; bir canlı P6 projesinde çalıştırılmış test sonucu olarak sunulmaz.

Türleri anlamak için beş temel kavram

Aktivite: Yapılacak işi tarif eden satır

“Temel kazısının yapılması” bir iştir. “Kazı alanının çalışmaya açılması” bir olaydır. “Kazı boyunca saha gözetimi” destek işidir. Bunların hepsi aktivite listesinde satır olabilir; aynı tür olmak zorunda değildir. Satırın adı ne olduğunu, Activity Type alanı nasıl hesaplanacağını söyler.

Süre: Çalışma zamanı; tarih aralığı: Takvim üzerindeki yer

İki iş günü, her koşulda kırk sekiz saat geçmiş zaman değildir. Günde 8 saat çalışan bir düzende iki iş günü 16 çalışma saati demektir. Cuma başlayan işte cumartesi çalışılıyorsa bitiş cumartesiye, çalışılmıyorsa pazartesiye gelebilir. Aynı 16 saat, farklı takvimlerde farklı bitiş tarihi üretir.

Bir işin cuma 08.00’de başlayıp pazartesi 17.00’de bitmesi, hafta sonu çalışıldığı anlamına gelmez. Aradaki boş saatler çalışma süresine katılmamış olabilir. P6’da sadece tarihi gösteren bir sütun, bu farkın saat kısmını gizler. Tarih hatası araştırırken başlangıç ve bitiş saatlerini de görünür yapın.

Takvim: Hangi gün ve saatlerde çalışılabilir?

Aktivite takvimi işin çalışma düzenini; kaynak takvimi personelin veya ekipmanın çalışma düzenini tarif eder. Global ve proje takvimleri, tanımın paylaşım kapsamını belirler. Activity Type seçimi ise hesapta hangi takvimin kullanılacağını etkiler. “Global takvim” yedinci bir aktivite türü değildir.

Kaynak: İşi yapmak için kullanılan kapasite

İşgücü, iş makinesi ve malzeme kaynakları farklı şeyleri ölçer. İşçilik için adam-saat, makine için makine-saat, malzeme için m³ veya ton kullanılabilir. Atama, belirli bir kaynağın belirli bir aktivitedeki payıdır. Bir kişinin adını sorumlu olarak seçmek ile ona 40 saatlik iş atamak aynı işlem değildir.

“Takvimde pazartesi çalışır” demek, “pazartesi başka hiçbir işte görevlendirilmemiştir” demek de değildir. Takvim çalışma zamanını tanımlar; eşzamanlı işlerin kaynak kapasitesini aşması ayrı bir aşırı yüklenme problemidir. Bu fark Kaynak Bağımlı türünü doğru anlamanın anahtarıdır.

İlişki ve WBS: Sıra ile kapsamı ayırın

İlişki, iki iş arasındaki mantığı kurar. Örneğin “donatı bitmeden beton başlayamaz”. WBS — Work Breakdown Structure (İş Kırılım Yapısı) ise işlerin kapsam ağacıdır: Proje → Yapı → Temel → Donatı/Beton. WBS’de aynı başlık altında durmak, bu işlerin birbirinin ardından yapılacağı anlamına gelmez; sıra için ilişki gerekir.

Bu cümleler sıfır gecikmeli standart ilişki koşullarını açıklar; “aynı anda olmak zorundalar” demez. Başka öncüller, takvimler veya kısıtlar B’yi daha sonraya taşıyabilir. Lag (ilişki gecikmesi) varsa ilişki uçları arasına ayrıca zaman eklenir.

Yerel dayanak: Çalışma Takvimleri ve Aktivite Tipleri. Hesap sırası: Oracle — Scheduling projects.

Altı türü tek tabloda karşılaştıralım

İlk iki tür işi üretir; iki kilometre taşı olayları işaretler; son iki tür sürelerini başka satırlardan türetir. Bu, seçim için bir sınıflandırmadır; uygulamada her satırın kendi iş tanımını ayrıca değerlendirmek gerekir.

Gantt çubuğunun rengi veya şekli türün kesin kanıtı değildir; bunlar görünüm ayarlarıyla değiştirilebilir. Türü Activity Type sütunundan doğrulayın. Aynı şekilde “kritik” görünmek, bir aktivitenin türünü değiştirmez.

Kurallar: Oracle — Define activity types · Level of effort · WBS summary.

“Bu iş, aktiviteye verdiğim çalışma düzeninde yürüsün.”

Bu türde aktiviteye atanmış kaynakların çalışma zamanları aktivite takvimine göre planlanır. Bir işi birlikte yapan ekip için ortak çalışma penceresi tanımlamak istediğinizde doğal bir seçimdir. Kaynak atamadan yalnız süre ve ilişkilerle de iş programı kurulabilir. Oracle’ın bu tür için verdiği ayırt edici kullanım, aynı işte birlikte çalışması gereken birden fazla kaynaktır.

Oracle — Task dependent activity.

Somut örnek: Kazı ekibi

“Açık kazının yapılması” için operatör, ekskavatör ve kamyonlar düşünün. Şantiye pazartesi–cumartesi, günde 8 saat çalışıyor. İş 16 çalışma saati sürüyor ve cuma 08.00’de başlıyor. Aktivite takvimi cumartesiyi çalışma günü saydığı için örnekte bitiş cumartesi 17.00 olur; öğle arası 12.00–13.00 çalışma dışıdır.

Operatörün kişisel takvimini yalnız hafta içi yapmış olmanız, bu türde o izin gününü otomatik bir duruşa dönüştürmez. Bu bir personel yönetimi kararıdır: Operatör yerine başka biri gelecekse iş takvimi uygundur; kimse gelmeyecekse modelde ortak çalışma takvimi, uygun kaynak modeli veya iş sırası bu gerçeği yansıtmalıdır.

Hangi işlerde uygundur?

• Ortak vardiyaya göre yürüyen kazı, donatı, kalıp, beton dökümü ve montaj.
• Kaynakların ayrıntılı ataması henüz yapılmamış teklif veya ana iş programı.
• İşin teknolojik koşulunun süreyi belirlediği kontrollü beklemeler.
• Ortak takvim ve açık süre tahmini ile yönetilen teslimat üretimleri.

Beton kürü neden öğretici bir örnek?

Bir laboratuvar prosedüründeki bekleme, ilave personel getirildiğinde kendiliğinden kısalmaz. Bununla birlikte “kür her zaman şu kadar gündür” diye yazılımdan bağımsız bir değer varsayılmaz; süre proje şartnamesi, yöntem ve kabul kriterinden alınır. Kesintisiz geçen zaman esas ise 7 gün/24 saat takvim kullanılabilir. Örneğin tamamen varsayımsal 72 saatlik bekleme, cuma 08.00’den pazartesi 08.00’e uzanır.

Bu tür neyi garanti etmez?

Kaynakların hiçbir zaman çakışmayacağını, sürenin hiç değişmeyeceğini, faaliyetin otomatik kritik olacağını veya gerçekleşmenin otomatik ölçüleceğini garanti etmez. Bunlar ayrı model katmanlarıdır. Tür yalnızca bir davranış tercihini belirler; yanlış takvimi veya yanlış mantık bağlantısını düzeltmez.

“Bu işteki her kaynak, kendi çalışma takviminde çalışsın.”

Kaynak Bağımlı aktivitede kaynak atamalarının çalışma zamanları kaynakların kendi takvimleriyle hesaplanır. Bu tür, aynı aktiviteye atanmış fakat birbirinden bağımsız çalışabilen kaynaklar için anlamlıdır. Bir atamanın aralığı diğerinden farklı olabilir; aktivitenin tarihleri üzerindeki etkisi atamanın tarihleri sürme özelliğiyle birlikte değerlendirilir.

Oracle — Resource dependent activity · Atama süreleri ve takvimleri.

Somut örnek: Teknik dosya incelemesi

Bir elektrik uzmanı ve bir mekanik uzmanı, teknik dosyanın kendi disiplinlerine ait kısımlarını farklı günlerde inceleyebilir. Elektrik uzmanı pazartesi–cuma; mekanik uzmanı salı–cumartesi çalışabilir. İkisi aynı odada aynı anda bulunmak zorunda değilse, bağımsız atamaları kaynak takvimleriyle çizelgelemek anlamlıdır.

İş “iki uzmanın aynı anda katıldığı ortak test” ise bağımsız atama varsayımı yeterli değildir. Birinin pazartesi, diğerinin salı çalışması ortak testi gerçekleştirmez. Ortak uygunluk penceresini temsil eden bir takvim veya daha açık bir aktivite/ilişki modeli gerekir.

Aktiviteyi hangi kaynak bitirir?

“Her zaman en yavaş kişi belirler” kısa cevabı yetersizdir. Drive Activity Dates / Aktivite tarihlerini yönlendir gibi atama ayarları, kaynak başlangıç gecikmeleri, farklı atama süreleri ve gerçekleşmiş tarihler birlikte etkilidir. Tarihi süren bir atamanın daha geç bitmesi aktiviteyi uzatabilir; tarihi sürmeyen bir atama aynı etkiyi vermeyebilir. Bu yüzden yalnız üst satırdaki Start/Finish yerine Resources veya Resource Assignments görünümündeki atama tarihlerini de inceleyin.

Kaynak Bağımlı ile kaynak dengeleme aynı şey mi?

Hayır. Kaynak takviminde pazartesi çalışma günü olabilir; aynı kişi pazartesi üç ayrı aktiviteye %100 yükle atanmış da olabilir. Takvim, o günün çalışma zamanı olduğunu söyler; toplam kapasitenin üç kez kullanılmasını tek başına çözmez.

Resource Leveling / Kaynak Dengeleme, eşzamanlı talepleri kullanılabilir kapasiteyle karşılaştırıp, seçilen ayar ve önceliklere göre aktiviteleri geciktirebilen ayrı hesaplamadır. F9 sırasında çalışması bir seçeneğe bağlıdır. “Resource Dependent seçtim, artık çift rezervasyon yok” sonucu çıkarılamaz.

Oracle — About Resource Leveling · Schedule Options: Level resources during scheduling.

“Burada önemli bir süreç başlıyor.” Süresi sıfırdır.

Başlangıç kilometre taşı bir işin yapılmasını değil, bir başlangıç olayının gerçekleşmesini temsil eder. Örneğin “saha çalışmaya açıldı”, “tasarım aşaması başlatıldı”, “etap 2 için erişim sağlandı”. Olayın gerçekleşmesi için öncesinde günlerce iş yapılmış olabilir; o işler ayrı aktivitelerde yer alır.

“Mobilizasyon” çoğunlukla süreli bir iştir. “Mobilizasyona başlama izni verildi” bir başlangıç olayıdır. İki cümleyi aynı türle modellemek, hazırlık işinin süresini görünmez hâle getirebilir.

Ağa nasıl bağlanır?

Bir projedeki tek başlangıç noktası olabilir; bir fazın ortasında, öncülü bulunan bir başlangıç kilometre taşı da olabilir. “Start” kelimesi yalnız projenin ilk satırında kullanılabileceği anlamına gelmez.

Ön hazırlık tamamlandı → Saha erişimi sağlandı [Start Milestone]
                         └─ FS → Mobilizasyon [süreli aktivite]

Başlangıç kilometre taşında olayı temsil eden uç başlangıçtır. İlişkileri bu uçla uyumlu kurun. Genel FS bağlantısı P6’nın kilometre taşı bağlantılarında varsayılanıdır; standart faaliyetlerdeki dört ilişkinin tamamını, ilgili kilometre taşının sahip olmadığı uca bağlayabileceğinizi varsaymayın.

Süre sıfırsa maliyet de kesinlikle sıfır mı?

Çalışma kaynağı veya rol ataması ve zamana bağlı işçilik maliyeti yoktur. Ancak Oracle, kilometre taşına Primary Resource / Birincil Kaynak ve Expense / Masraf bağlanabileceğini belirtir. Birincil kaynak, burada sorumluyu göstermek için kullanılabilir; çalışma saati ataması değildir. Tek seferlik olay masrafı da bir faaliyet boyunca çalışan ekip maliyetinden farklıdır.

Oracle — Start milestone activity.

“Buradaki teslimat veya aşama tamamlandı.” Süresi sıfırdır.

“Temel işleri tamamlandı”, “enerji verme onayı alındı”, “test kabul tutanağı imzalandı” gibi sonuca ulaşıldığını bildiren olayları temsil eder. Öncesindeki inceleme, test veya onay hazırlığı süre alıyorsa bunlar ayrı süreli aktivitelerdir; sonucun onaylandığı an kilometre taşıdır.

Testlerin yapılması [süreli] ─ FS → Testler kabul edildi [Finish Milestone]
                                      └─ FS → İşletmeye alma [süreli]

Birden fazla teslim koşulunu bir noktada birleştirmek

“Etap teslim edildi” için hem imalatların bitmesi hem testlerin geçmesi hem belgelerin tamamlanması gerekebilir. Bu durumda gerçek koşulları temsil eden aktiviteleri bitiş kilometre taşının öncülleri yapın. Yalnız fiziksel imalatı bağlarsanız eksik belgeler planın teslim tarihini etkilemez; bu, yazılım hatası değil eksik modeldir.

Planlanan tarih, hedef tarih ve gerçekleşen tarih

Hesaplanan bitiş mevcut mantığın ürettiği sonuçtur. Hedef bitiş ulaşılması istenen tarihtir; baseline veya uygun kısıtla ayrı temsil edilebilir. Actual Finish / Gerçekleşen Bitiş olayın gerçekten tamamlandığı andır. Bir hedef tarihi, gerçekleşmiş gibi Actual Finish’e girmek ilerlemeyi yanlış kaydeder.

Finish Milestone seçmek tek başına hiçbir tarihi sabitlemez. Bağlı işler ötelenirse kilometre taşı da ötelenecektir. Bir hedefe göre sapma görmek isteniyorsa, kısıt türünün erken/geç tarih ve bolluk etkisi bilinçli seçilir. İş modelini eksik bırakıp her kilometre taşına zorlayıcı bir tarih yazmak çözüm değildir.

Başlangıç ve bitiş türünü neden ayırıyoruz?

İkisi de sıfır süreli olsa da biri başlangıç olayını, diğeri tamamlanma olayını temsil eder. Görünümdeki tarih sütunlarının ve bağlantı uçlarının anlamı buna göre değişir. Aynı gün içinde sabah bir başlangıç, mesai sonunda bir bitiş bulunabilir. Tarihin saat kısmını gizlemek iki olayı aynı sanmaya yol açar.

Gantt görünümünde genellikle elmas biçimiyle gösterilirler; şekil ve renk yerleşime göre değiştirilebilir. İkisinin de birincil sorumlusu, dokümanı ve tek seferlik masrafı olabilir; çalışma kaynağı/rol ataması ve süreleri bulunmaz.

Oracle — Finish milestone activity.

“Belirlediğim işler devam ettiği sürece bu destek de devam etsin.”

LOE, başka aktivitelerin tarih sınırları üzerinden süre alan bir destek aktivitesidir. Şantiye yönetimi, sürekli evrak koordinasyonu, gözetim veya güvenlik gibi işlerde kullanılır. Buradaki “sürekli”, mutlaka haftanın yedi günü, günün yirmi dört saati demek değildir. Bir mühendis yalnız hafta içi günde dört saat destek verebilir; bunu LOE’nin takvimi ve kaynak atama oranıyla ifade edersiniz.

Süreyi nereden alır?

LOE’nin başlangıç ve bitiş uçlarını hangi işlere bağladığınız belirleyicidir. Oracle açıklamasında başlangıç ucuna bağlı öncül/ardılların en erken Early Start / Erken Başlangıç, bitiş ucuna bağlı olanların en geç Early Finish / Erken Bitiş sınırları kullanılır. Aradaki süre LOE’nin kendi çalışma takviminde hesaplanır. “Öncülün başlangıcı ile ardılın Late Finish’i arasındaki fark” biçimindeki tek formül doğru bir genel tarif değildir.

Oracle — Level of effort activity · Vault: LOE notları ve düzeltmeler.

Yönleri karıştırmadan LOE kurmak

Eğitim örneğinde A ilk iş, Z son iş, L destek aktivitesi olsun. L’nin Predecessors / Öncüller sekmesine şu iki satırı ekleyebiliriz:

LOE, öncül veya ardıl uçlar üzerinden de tanımlanabildiği için farklı geçerli ağ düzenleri görebilirsiniz. Ekranda yalnız “SS ve FF var” diye karar vermeyin; hangi satırdan hangi satıra verildiğini okuyun. Üretim zincirini gereksiz yere destek aktivitesinin içinden geçirmeyin ve dairesel bağlantı kurmayın.

LOE süresi iş sürelerinin toplamı değildir

A işi 1–5. iş günlerinde, B işi 4–8. iş günlerinde gerçekleşsin. Beşer gün süren iki iş toplam 10 aktivite-günü içerir; fakat ilk başlangıçtan son bitişe kadar aralık 8 iş günüdür. Destek bu aralığı kapsıyorsa LOE 8 gün olur. Tersine arada çalışılmayan bir üretim boşluğu olup destek devam ediyorsa LOE bu boşluğu da kendi takvimine göre kapsayabilir.

LOE için uygun ve uygun olmayan iş tanımları

“Kalite kontrol” adı tek başına LOE kararı verdirmez. Sürekli gözetim LOE olabilir; sonraki işi başlatmak için zorunlu bir test ise kendi süresi ve sonucu olan ayrı iştir. “Saha temizliği” de günlük destek veya teslim öncesi ölçülebilir iş olabilir; türü ismi değil gerçek iş tanımı belirler.

Kaynak, maliyet ve uzayan süre

Destek mühendisi günde 4 saat çalışıyorsa, 10 iş günlük destek için toplam efor 40 adam-saattir. Destek aralığı 15 iş gününe uzar ve günlük oran korunursa efor 60 adam-saate çıkar. Saatlik ücret varsayımsal 500,00 ise planlanan toplam 20.000,00’dan 30.000,00’a yükselir.

Ancak P6’da yalnız “LOE seçmek” bu maliyet artışını her ayarda garanti etmez. Duration Type, birim/zaman, fiyat değişimleri, maliyetlerin birimlerden hesaplanması ve çizelgeleme sonrası maliyet hesabı ayarları sonucu etkiler. Toplam birimi koruyan modelde süre uzarken günlük yük azalabilir. İleri düzey kullanıcı, LOE’nin tarih davranışı ile maliyet davranışını ayrı doğrular.

Kısıt, dengeleme ve gerçekleşme sınırları

LOE’ye tarih kısıtı atanamaz; kaynak dengelemede LOE aktiviteleri dışarıda bırakılır. Bu nedenle bir destek mühendisini hem LOE’ye hem üretim işine yüklediğinizde kapasite sorununu dengelemenin kendiliğinden çözeceğini varsaymayın. Gerçek ortak kaynağı iki hayalî kaynak kimliğine bölüp çakışmayı gizlemek de çözüm değildir.

LOE’nin tarihinin türetilmesi, gerçek çalışma saatlerinin, masrafların veya tüm ilerleme alanlarının sahadan veri almadan doğru olacağı anlamına gelmez. Her güncellemede bağlı işlerin gerçekleşmeleri, veri tarihi, LOE’nin status alanları ve kaynak gerçekleşmeleri birlikte kontrol edilmelidir.

Eski “hammock” ile tamamen aynı mı?

Hamak benzetmesi öğreticidir: uçlar açıldıkça aralık uzar. Fakat Oracle LOE ile eski hammock davranışını aynı saymaz. LOE kendi takvimini kullanır ve farklı ilişki türleriyle bağlanabilir; klasik hammock için tarif edilen takvim ve SS/FF sınırlamaları farklıdır. Eski yazılımdaki bir hamak aktivitesini P6’ya taşırken yalnız ad değiştirmek yeterli kabul edilmez.

“Bu WBS dalının tarih aralığını tek aktiviteyle temsil et.”

WBS Özeti, atandığı WBS dalındaki aktiviteleri topluca temsil eden özel bir aktivitedir. En erken başlangıç ve en geç bitiş özetin sınırlarını verir. Süre, bu sınırlar arasında özet aktivitenin kendi takvimi kullanılarak hesaplanır. Bu yüzden alt işlerin sürelerini toplayıp aynı rakamı beklemek yanlıştır.

Hangi işler kapsama girer?

WBS hiyerarşisindeki konum belirler. Özet A dalındaysa A’nın alt dalları da kapsamdadır. A.1’e atandığında A.1 ve onun alt dallarını kapsar; kardeş A.2 dalını kapsamaz. Buradaki kuralı gelişigüzel metin benzerliği değil, WBS’deki gerçek üst–alt ilişkisi olarak okuyun. Aktivite adının veya Activity ID’nin “A.1” ile başlaması tek başına üyelik yaratmaz.

A — Yapı işleri                         ← WBS Özeti burada: tüm A dalı
├── A.1 — Temel                         ← WBS Özeti burada: yalnız temel dalı
│   ├── A.1.1 — Kazı                    → temel özetine dahil
│   └── A.1.2 — Donatı ve beton          → temel özetine dahil
└── A.2 — Üstyapı                       → temel özetine dahil DEĞİL

Oracle P6 Professional — WBS summary activity · Vault: WBS Summary Aktiviteler.

WBS başlığı, WBS grup satırı ve WBS Summary aynı şey mi?

Dolayısıyla WBS oluşturunca her zaman ayrıca bir WBS Summary aktivitesi otomatik oluştuğunu varsaymayın. Yalnız raporda bir WBS toplamı görmek için çoğu kez Group and Sort / Grupla ve Sırala görünümü yeterlidir. Ayrı Activity ID, kodlama, alanlar veya özet düzey kaynak yükü gerekiyorsa özel özet aktivitesinin amacı vardır.

Özet aktiviteye ilişki verince işler sıralanır mı?

Hayır. Doğrudan WBS Summary’ye atanmış ilişkiler çizelgelemede ve kaynak dengelemede dikkate alınmaz. Örneğin “Temel Özeti → Üstyapı” diye bağlayarak üstyapıyı güvenilir biçimde durduramazsınız. Gerçek bitiş koşullarını bir Finish Milestone üzerinde birleştirip sonraki işleri o kilometre taşına bağlayın.

WBS Özeti’ne kaynak atanabilir mi?

“Hiçbir kaynak atanamaz” genel ifadesi doğru değildir. Özet düzeyde birim ve maliyet yüklenebilir. P6 Professional yardımındaki temel sınır, kaynak atamalarının WBS Summary aktivitesinin tarihlerini sürmemesidir: tarihleri WBS içindeki işler belirler.

EPPM’nin ayrıntılı açıklaması driving/non-driving atama davranışlarını da tarif eder. “Driving” atamanın tarihleri özetin tarihlerine uydurulur; süre türüne göre birimler veya birim/zaman yeniden hesaplanır. “Non-driving” atama özetle aynı başlangıcı alırken kendi atama süresi bitişini belirler. Burada “driving” kelimesini “alt işlerin tarihini kaynak uzatır” şeklinde yorumlamayın. Atama ekranındaki davranış ile WBS’nin tarih toplama kuralı ayrı konulardır.

Oracle EPPM — About WBS Summary Activities · P6 Professional: tarih süren kaynak sınırı.

LOE ile farkını gecikmeyle sınayın

A ve Z’ye bağlı bir LOE düşünün. Aynı WBS’ye yeni bir N işi eklensin ve N, Z’den daha geç bitsin. LOE’nin bağlantıları değişmemişse N’yi sırf aynı WBS’de olduğu için kendiliğinden kapsaması beklenmez. WBS Summary ise N kendi hiyerarşik kapsamındaysa onun daha geç bitişini özete dahil eder.

Hangi durumda hangi türü seçmeliyim?

Bir aktiviteyi sınıflandırırken önce işin sonucunu ve sınırlarını yazın. Ardından aşağıdaki sırayı izleyin. “İnşaatta her zaman X” veya “ofis işinde mutlaka Y” gibi evrensel oranlar kullanmayın.

1. Yalnız bir olay anı mı? Evetse başlangıç olayı için Start Milestone, tamamlanma olayı için Finish Milestone.
2. Belirli bir WBS dalını özetleyen ayrı satır mı? Evetse WBS Summary. Sadece görünümde toplam gerekiyorsa WBS gruplamasını değerlendirin.
3. Başka işler sürdükçe sürmesi gereken destek mi? Evetse LOE; hangi başlangıç ve bitiş olaylarına bağlı olduğunu yazın.
4. Kendi süresi olan gerçek iş mi? Ortak iş takvimi belirleyiciyse Task Dependent.
5. Aynı işte kaynakların farklı takvimlerde bağımsız çalışması mı gerekiyor? Evetse Resource Dependent; kaynak ve atama modeli tamamlanmış olmalı.

Uçtan uca örnek: Teknik binanın temel işleri

Bu örnek, altı türü tek bir iş programında bir araya getirir. Gerçek bir proje hesabı değil, seçimin sonuçlarını görünür yapan eğitim senaryosudur. Tatil ve gerçekleşme yoktur; ilişki gecikmeleri sıfırdır. Günler çalışma günü sırası olarak numaralanmıştır; saat dönüşümü sorunu olmaması için bütün ana işler ortak 8 saatlik takvimdedir.

A100–A130 ve M010/M020 Temel dalındadır. L200, yanlışlıkla özetin kapsama sınırını değiştirmemek için ayrı Destek WBS dalında tutulmuştur. S300 ise Temel dalının özetidir. Bu ayrım, yalnız görsel düzen değil, özete hangi satırların girdiği açısından önemlidir.

Başlangıç durumunun hesabı

Kazı 1–3, kalıp/donatı 4–7, muayene 8 ve beton 9. iş günündedir. Üretim zinciri dokuz iş günü sürer. L200 aynı başlangıç ve bitişi kapsadığı için ortak takvimde dokuz gün olur. S300’ün kapsamındaki en geç olay da dokuzuncu günün bitişidir.

Değişiklik 1: Mühendis bir gün çalışamıyor

Mühendisin kaynak takviminde 8. gün çalışma dışı yapılırsa muayenenin ataması 9. güne taşınır. Beton 10. güne, bağlı bitiş kilometre taşı da betonun bitişine kayar. LOE’nin A130 bitişine bağlı ucu uzar; WBS Özeti de kapsamdaki son bitişi alır.

Muayene Task Dependent olup aktivite takvimi 8. günü çalışır saysaydı, aynı kişisel takvim değişikliği bu biçimde uygulanmayacaktı. Bu karşılaştırma, “kaynağın gerçekte gelememesi” ile “modelin bunu dikkate alması” arasındaki farkı gösterir.

Değişiklik 2: Yeni bir tamamlayıcı iş eklendi

Temel WBS dalına 12. günde biten bir belge teslim aktivitesi ekleyin. WBS Özeti 12. güne uzar. LOE hâlâ yalnız kazı başlangıcı ile beton bitişine bağlı olduğundan otomatik olarak yeni belge teslimine uzanmaz. Gözetimin belge teslimini de kapsaması gerekiyorsa LOE’nin bitiş sınırını yeniden tasarlamak gerekir.

Değişiklik 3: Alt iş başka WBS’ye taşındı

Belge teslimini Temel dalından Dokümantasyon dalına taşırsanız, artık Temel WBS Özeti’nin kapsama üyeliği değişir. LOE’de ise WBS taşınması tek başına var olan ilişkiyi kaldırmaz. Aynı organizasyon değişikliği iki türde farklı sonuç verir.

Türü tanımlama, değiştirme ve doğrulama

Yeni bir aktivite için işlem sırası

1. Project → Activities ekranını açın; hedef WBS altında aktiviteyi oluşturun.
2. Satıra işin sonucunu açıklayan bir ad verin. “İmalat” yerine “Temel donatısının tamamlanması” gibi denetlenebilir bir kapsam yazın.
3. Activity Details → General alanında Activity Type seçimini yapın. Türkçe ekranda bu, görseldeki Aktivite Türü alanıdır.
4. Aktivite takvimini kontrol edin. Kaynak Bağımlı ise kaynak ve atama takvimlerini ayrıca kontrol edin.
5. Süreli işlerde süre, gerekli kaynaklar, Duration Type ve % Complete Type alanlarını tanımlayın. Kilometre taşına iş süresi yüklemeyin.
6. Gerçek öncül/ardıl ilişkilerini kurun. LOE için sınır ilişkilerini, WBS Özeti için doğru WBS üyeliğini doğrulayın.
7. Tools → Schedule / F9 ile veri tarihini ve hesap seçeneklerini görerek çizelgeleyin.
8. Activity Type, Calendar, Start, Finish, Remaining Duration, Total Float ve gerekli atama sütunlarını birlikte okuyun.

Menü yolu: Oracle — Define activity types. Yerleşim veya dil paketi nedeniyle panel adları değişebilir; alanın İngilizce anahtarını karşılaştırın.

Bir aktivitenin türünü sonradan değiştirirken

Tür değişikliği sadece etiket değişikliği değildir. Süreli aktiviteyi kilometre taşına çevirmek süre ve atama modelini değiştirir. Normal işi LOE yapmak bağımsız süre mantığını kaldırır. WBS Summary yapmak ise satırı WBS kapsamının tarih sonucuna dönüştürür. Eski değerlerin ve atamaların aynen korunacağını varsaymayın.

Kontrollü bir denemede değişiklik öncesi ve sonrası şu alanları karşılaştırın: aktivite türü, takvim, süreler, gerçekleşen tarihler, ilişkiler, kısıtlar, kaynak/rol atamaları, birimler, birim/zaman, maliyet ve bağlı teslim tarihleri. Bir “kür” işinin aniden kilometre taşı olması gibi model kayıpları yalnız Start/Finish’e bakılarak yakalanamaz.

F9 ne yapar, ne yapmaz?

F9, mevcut süre, takvim, ilişki ve hesap seçeneklerini kullanarak çizelgeyi hesaplar. Saha verisini kendiliğinden bilmez. “F9’a bastım; demek ki geçen hafta yapılan iş doğru işlendi” sonucu çıkarılamaz. Otomatik çizelgeleme kapalıysa önemli değişiklikler F9 öncesinde tarih alanlarına yansımayabilir.

Aylık/haftalık güncellemede kısa akış

1. Raporun Data Date / Veri Tarihi anını belirleyin.
2. Gerçekten başlamış ve bitmiş işleri, gerçek tarih ve saatleriyle işleyin.
3. Devam eden işlerin Remaining Duration / Kalan Süre tahminini sahadan güncelleyin.
4. Fiziksel üretim, harcanan saat ve masraf verilerini birbirine karıştırmadan girin.
5. Değişen vardiya, izin ve kaynak atama koşullarını güncelleyin.
6. F9 sonrasında LOE sınırlarını, WBS kapsamını, teslim kilometre taşlarını ve baseline sapmalarını denetleyin.

Oracle — Scheduling projects · Güncelleme mantığı ve hesap seçenekleri.

Activity Type ile Duration Type farkı

Activity Type, aktivitenin nasıl bir planlama nesnesi olduğunu ve hangi takvim/sınır davranışını kullandığını belirler. Duration Type, kaynak atanmış bir aktivitede süre, birimler ve birim/zaman arasında güncelleme yapıldığında hesap davranışını belirler. Duration Type’ın hesap etkisi kaynak ataması bulunduğunda anlam kazanır.

Basitleştirilmiş örnek: günde 8 saat yüklenen tek mühendis × 10 iş günü = 80 adam-saat. Burada 8 saat/gün bir kaynak yükleme oranıdır; kendiliğinden “8 m³/gün imalat verimi” değildir. Malzeme miktarı ile işçilik saatinin bağlantısı ayrıca tanımlanan verim varsayımıdır.

“Sabit” kelimesi, kullanıcının o alana asla yeni değer yazamayacağı anlamına gelmez; diğer girdiler değişirken korunması hedeflenen hesap davranışını açıklar. Yukarıdaki örnekler tek kaynak, aynı takvim ve düzgün yükleme varsayımıyladır. Atama ekleme/çıkarma, gerçekleşmeler ve mevcut atamaları koruma/yeniden hesaplama tercihleri daha ayrıntılı davranış doğurabilir.

Oracle — About Duration Types · Vault: Oracle süre türü notları.

Matematiksel tutarlılık testi

Bir kaynak için 10 gün ve toplam 80 saat aynı anda korunuyorsa, ortalama çalışma yükü 8 saat/gündür. “Süre ve toplam efor değişmeden toplam günlük efor 16 saate çıktı” deniyorsa denklem tutarsızdır. Kaynak sayısı değiştiğinde kişi başına yük ile bütün atamaların toplam yükünü ayrı okuyun.

Bir tür diğerini zorunlu kılar mı?

Task Dependent seçildi diye her aktivitenin aynı Duration Type kullanması gerekmez. Resource Dependent seçildi diye kaynak eklediğinizde işin mutlaka yarı sürede biteceği de söylenemez. İşin bölünebilirliği, kaynakların birbirini beklemesi ve teknolojik minimum süre gibi gerçek dünya sınırları model kararının parçasıdır.

Tür seçimi ilerlemeyi ve kazanılmış değeri nasıl etkiler?

Üç farklı yüzde aynı aktivitede farklı sonuç verebilir

Bir işin süresinin yarısının geçmiş olması, imalatın yarısının tamamlandığını kanıtlamaz. Planlanan adam-saatin yarısının tüketilmesi de aynı kanıtı vermez. P6’nın üç temel % Complete Type / Tamamlanma Yüzdesi Türü seçeneği bu ayrımı taşır.

Sonuç yüzde için 100 ile çarpılır. Units hesabında aktivite düzeyindeki işgücü ve işgücü dışı kaynak birimleri kullanılır; bunu doğrudan malzeme miktarı tamamlanma yüzdesi sanmayın. Activity Steps, dördüncü bağımsız % Complete Type seçeneği değildir; uygun ayarlarla Physical % değerini besleyen yöntemdir.

Oracle — Define activity percent complete types · Vault: Yüzde Tamamlanma Türleri.

Physical % girince kalan süre kendiliğinden doğru olur mu?

Hayır. Fiziksel ilerleme ile kalan süre ayrı bilgi girdileridir. İş %60 bitmiş olabilir ama kalan %40’ta daha zor birleşim ve testler bulunabilir. Kalan süreyi sahadaki üretim koşullarıyla tahmin edin; yüzdeyi otomatik olarak süreye çevirip gerçek iş zorluğunu silmeyin.

LOE için “zaman geçti, iş üretildi” yanılgısı

Destek işinde zaman tabanlı ilerleme makul olabilir; fakat bu oranı üretim başarı ölçüsü olarak karıştırırsanız geciken ana işler görünmez hâle gelebilir. LOE’nin türetilmiş tarih/süre davranışı, her koşulda EV = PV veya gerçek maliyet otomatik doğrudur anlamına gelmez. Güncelleme yöntemi, bütçe, referans plan ve kazanılmış değer hesabının seçimi ayrıca belirleyicidir.

EVM’de asıl ölçü hangi yüzde?

Earned Value Management — EVM (Kazanılmış Değer Yönetimi), planlanan değer, kazanılan değer ve gerçek maliyeti karşılaştırır. P6’da Performance % Complete, seçilen WBS kazanılmış değer tekniğine göre belirlenir; Activity % Complete ile her durumda aynı olmak zorunda değildir.

Burada BAC tamamlanma bütçesi, EV kazanılmış değer, PV veri tarihine kadar planlanan değer, AC gerçekleşen maliyettir. Yüzde, hesapta 0–1 aralığında kullanılır. SPI/CPI oranlarının paydası sıfırsa bölme sonucu tanımlı değildir. Bu oranlar fiziksel gerçekleşmenin veya gecikmenin bütün nedenlerini tek başına açıklamaz.

Kilometre taşı ve ağırlıklı kilometre taşı tekniği

Aktivite türü olan Start/Finish Milestone ile WBS düzeyindeki Weighted Milestones / Ağırlıklı Kilometre Taşları kazanılmış değer yöntemi aynı nesne değildir. Bir satırı Finish Milestone yapmak ona otomatik bütçe veya ağırlık vermez. Olayın gerçekleşti/gerçekleşmedi durumu, onun maliyetinin ve EVM ağırlığının nasıl tanımlandığıyla birlikte yorumlanır.

WBS özet yüzdesi neden aritmetik ortalama olmayabilir?

İki aktivite %100 ve %0 ise proje mutlaka %50 değildir. Birincinin ağırlığı 10, ikincinin 90 ise ağırlıklı sonuç %10 olur. Özetlediğiniz alanın süre, birim, bütçe veya EVM tekniği açısından hangi ağırlıklandırmayı kullandığını okuyun. WBS Summary aktivitesini “alttaki bütün yüzdeleri topla ve ikiye böl” diye yorumlamayın.

EVM dayanağı: Oracle — WBS kazanılmış değer hesabı · Vault kaydı. Sayısal örnekler bu kılavuz için oluşturulmuştur.

Uzman kullanıcıların da gözden kaçırabildiği noktalar

Kritik görünmek ile proje bitişini sürmek farklıdır

P6, kritik aktiviteleri seçilen Total Float eşiği veya Longest Path / En Uzun Yol yaklaşımıyla işaretleyebilir. Çoklu takvimler, açık uçlar ve tarih kısıtları raporun yorumunu değiştirir. Gantt’ta kırmızı görünen her satırın süresini kısaltmak proje teslimini aynı ölçüde erkene getirmeyebilir.

LOE, desteklediği işlerin tarih aralığını izlemek için kullanılır. Kritik işlerle aynı aralığı kaplaması veya bir bolluk filtresinde görünmesi, bağımsız üretim işi olduğunu göstermez. Projeyi hızlandırmak için LOE’nin süresini elle küçültmeye çalışmak yerine üretim zincirindeki gerçek sürücü ilişkileri ve teslim koşullarını inceleyin. “LOE hiçbir görünümde kritik olamaz” gibi koşulsuz bir slogan da kullanmayın.

WBS Summary bağlantıları hesapta dikkate alınmadığından, bu özet satırını üretim ağının kritik bağımlılık düğümü olarak kullanmayın. Özetin bitişi bir sonuç göstergesidir; işi teslim ettiren gerçek ağ aşağıdaki aktivitelerdedir.

Oracle — Define critical activities · Bir teslim olayına biten çoklu bolluk yolları.

İlişki gecikmesinin takvimi ayrı bir seçenektir

Aktivite takvimini seçmiş olmanız, bütün lag sürelerinin kesinlikle o takvimle sayılacağı anlamına gelmez. Schedule Options içindeki ilişki gecikmesi takvimi ayarı önemlidir. Bir beklemeyi, süresini ve gerçekleşmesini ayrıca takip etmek gerekiyorsa, onu görünmeyen uzun bir lag yerine kendi adı ve takvimi olan aktiviteyle temsil etmek daha denetlenebilir olabilir.

Özellikle LOE uçlarında gereksiz gecikmeler tanımlamak “ilk işten son işe kadar destek” yorumunu değiştirebilir. Başlangıçta sıfır lag ile okunabilir bir model kurun; gerçek gecikme gereksinimi varsa neyi temsil ettiğini not edin.

Başlamış işlerde aynı tür neden farklı tarih verebilir?

Devam eden aktivitelerde sonuç yalnız Activity Type’tan gelmez. Gerçekleşen başlangıç/bitişler, kalan süre ve Retained Logic / Korunan Mantık, Progress Override / İlerlemeye Öncelik ya da Actual Dates / Gerçekleşen Tarihler seçenekleri de etkilidir. Öncülü tamamlanmadan başlamış bir aktivitenin kalan kısmının nerede hesaplanacağı bu ayarlara bağlıdır.

Dolayısıyla yeni oluşturulmuş, hiç başlamamış bir eğitim örneğinin sonucunu gerçekleşmeler içeren projeye koşulsuz taşımayın. Türü değiştirmeden önce problemin türden mi, gerçekleşmeden mi, hesap seçeneğinden mi geldiğini ayırın.

Projeler arası LOE bağımlılığı

LOE’nin bağlandığı iş başka bir projede olabilir. Böyle bir modelde dış ilişkinin erişilebilirliği, karşı projenin güncelliği ve projeler arası ilişkileri yok sayma seçeneği denetlenmelidir. “İki projeyi birbirine bağladım” demek, her hesapta güncel karşı tarihlerin kullanıldığını tek başına kanıtlamaz. Ortak teslim koşullarını ve kullanılan veri kesitini kaydedin.

Lag, gerçekleşmiş iş ve dış ilişki ayarları: Oracle — General tab, Schedule Options.

Kaynak atama süreleri ile aktivite süresi farklı olabilir

Bir aktivite iki hafta sürebilir fakat uzman yalnız son üç gün çalışabilir. Kaynak atamasının başlangıç gecikmesi, kalan süresi ve tarihleri üst satırla birebir aynı olmayabilir. Kaynak Bağımlı ve WBS Summary örneklerinde bu ayrım özellikle önemlidir. Maliyet ve histogram incelemesinde yalnız aktivite çubuğunu değil, atamanın zaman içindeki dağılımını da okuyun.

Kapsama yanlışlıkla dahil edilen destek satırları

Bir WBS Summary’nin altında, aslında bütün projeyi kapsayan uzun bir LOE bulunursa özet iş paketinin sınırları beklediğinizden uzun görünebilir. WBS Summary, sizin “yalnız imalatları özetlemek istedim” niyetinizi bilmez; gerçek kapsamını kullanır. Bu nedenle destek WBS’si, üretim WBS’si ve rapor gruplamasını bilinçli kurun.

Filtreler gerçek üyeliği değiştirmez

Bir aktiviteyi ekrandaki filtreyle gizlemek, onu WBS hiyerarşisinden çıkarmak değildir. WBS Summary’nin neyi kapsadığını ekranın o anki görünürlüğünden çıkarmayın. Özellikle gizlenmiş, pasif sanılan veya tamamlanmış satırlar için gerçek WBS üyeliğini, durumunu ve tarih alanlarını kontrol edin.

Modeli küçük değişikliklerle sınamak

1. Bir üretim işinin kalan süresini kontrollü örnekte bir gün artırın; hangi teslim tarihi değişiyor?
2. Bir kaynak takvimine izin günü ekleyin; Task ve Resource Dependent karşılaştırması beklediğiniz farkı veriyor mu?
3. LOE’nin son sınır işini geciktirin; destek aralığı doğru uzuyor mu?
4. Aynı WBS’ye daha geç biten iş ekleyin; WBS Summary kapsamı güncelleniyor mu?
5. Atama oranını veya toplam birimi değiştirin; Duration Type seçimiyle hesap tutarlı mı?

Bu kontrollü değişiklikler, bir ayarı ezberlemekten daha güçlü bir kabul yöntemidir. Başlangıçtaki veri, hesap seçenekleri ve beklenen sonuç açıkça yazılırsa modelin neden öyle davrandığı anlaşılır.

Bir şey beklediğim gibi çalışmıyorsa

Sık sorulan sorular

Yanıtları tek tek açabilir veya üstteki “Yanıtları aç” düğmesini kullanabilirsiniz. Yazdırmada bütün yanıtlar görünür olur.

Altı kısa alıştırma

Son kontrol listesi

• Her satırın iş, olay, sürekli destek veya kapsam özeti olduğu açık mı?
• Görseldeki Türkçe ad ile İngilizce Activity Type doğru eşleşiyor mu?
• Aktivite takvimi ve kaynak takvimleri gerçek çalışma düzenini temsil ediyor mu?
• “1 gün” dönüşümü ile gerçek çalışma saatleri ayrı kontrol edildi mi?
• Kaynakların birlikte mi, bağımsız mı çalışacağı doğru modellenmiş mi?
• Kilometre taşlarının öncesindeki süreli hazırlık/inceleme işleri kaybolmadan duruyor mu?
• LOE’nin başlangıç ve bitiş ilişkileri doğru yön ve uçlara bağlanmış mı?
• LOE’nin WBS dışındaki sınırları ve sonradan eklenen işler değerlendirilmiş mi?
• WBS Summary gerçek WBS dalını kapsıyor mu; grup satırıyla karıştırılmış mı?
• Üretim mantığı WBS Summary bağlantılarına dayandırılmamış mı?
• Duration Type ile toplam efor ve günlük yük hesabı tutarlı mı?
• Physical %, kalan süre, kaynak gerçekleşmesi ve maliyet ayrı doğrulanmış mı?
• Üretim, destek ve özet satırları arasında mükerrer bütçe yok mu?
• F9 sonrası gerçek teslim noktaları ve atama tarihleri kontrol edilmiş mi?
• Güncel plan ve baseline karşılaştırması aynı veri kesiti ve açık varsayımlarla yapılıyor mu?

Kısa terim sözlüğü

Bu kılavuz neye dayanıyor?

Görseller doğrudan görsel olarak okunmuştur. Konu, Baran SEREN’in Obsidian PrimaveraVault notlarıyla incelenmiş; ürün davranışını belirleyen noktalar 05.09.2026 tarihinde erişilen Oracle P6 Professional ve P6 EPPM yardım belgeleriyle karşılaştırılmıştır. İki görselden tam yazılım sürümü çıkarılmamıştır.

Metin, kaynakların kopyası değil; kavramları birleştiren açıklama, özgün eğitim senaryoları ve hesap örneklerinden oluşur. Takvim ve kapsam deneyleri açıklama amaçlıdır. Ana içerik, ekran görüntüleri ve şemalar internet olmadan okunur; aşağıdaki web bağlantılarına gitmek için internet gerekir.

Kaynak çelişkilerini nasıl ele aldık?

Vault, farklı dönem ve kaynaklardan gelen kayıtları birlikte barındırıyor. Bazı notların ilerleyen kısımlarında eski ifadelere düzeltmeler eklenmiş. Bu makalede ilgili güncel Oracle davranışı esas alındı; vault dosyaları değiştirilmedi.

Vault’taki doğrulanmamış evrensel yüzdeler veya tüm sürümlerde bulunduğu varsayılan “LOE in Critical Path” türü bir ayar adı, bu makalede ürün kuralı olarak kullanılmamıştır. Kritik görünümün değerlendirilmesi, doğrulanan bolluk/en uzun yol seçenekleriyle açıklanmıştır.

Okunan Primavera vault notları

Kök: C:\Users\baranseren\Desktop\Brain\Obsidian-Primavera\PrimaveraVault. Aşağıdaki yollar bu köke göredir; makalenin çalışması bu dosyaların bulunmasına bağlı değildir.

Ön bağlam taraması ayrıca ClaudeCode vault’undaki _DAMITILMIS\primavera.md üzerinden yapılmıştır. Esas konu içeriği yukarıdaki Primavera notlarından ve aşağıdaki birincil belgelerden doğrulanmıştır.

Oracle’ın birincil belgeleri

Okuma ve paylaşma

Dosyayı çift tıklayarak tarayıcıda açabilirsiniz. Bölüm araması, büyütülmüş metin, iki eğitim deneyi ve açılır yanıtlar dosyanın içinde çalışır. “Yazdır / PDF” düğmesi tarayıcının yazdırma ekranını açar; bütün yanıtlar baskıya dahil edilir. JavaScript kapalıysa ana makale, tablolar, örneklerin varsayılan sonuçları ve görseller okunmaya devam eder.