Primavera P6 zamanlama seçenekleri: ilerleme mantığı ve bolluk hesabı

Zamanlama (F9) ne yapar, seçenekler neden önemlidir?

P6'da Tools, Schedule komutu (kısayolu F9) ağı baştan hesaplar: aktivitelerin erken ve geç tarihlerini, bolluğunu ve kritik yolunu üretir. Schedule penceresinde veri tarihini görür, Options düğmesiyle zamanlama ayarlarını açar, istersen sonuçları bir log dosyasına yazdırır ve Schedule düğmesine basarsınız.

Seçenekler, ağın nasıl yorumlanacağını belirler. Aynı program farklı ayarlarla hesaplanırsa farklı bitiş tarihi ve farklı kritik yol verebilir. Bu yüzden ekip içinde ayarları paylaşmak ve ilk güncellemeden önce kararlaştırmak gerekir. Aksi halde bir meslektaşınızın açtığı program sizde başka tarihlerle hesaplanır ve fark hata sanılır.

Options penceresindeki Default düğmesi varsayılan zamanlama ayarlarını gösterir ve kullanır. Varsayılanların sözleşme ya da program şartnamesinde belirtilen yöntemle uyumlu olup olmadığını denetlemek, yeni bir proje kurarken ilk işlerden biridir.

Retained Logic, Progress Override ve Actual Dates

Seçenek, When scheduling progressed activities use başlığı altındadır ve ilerleme kaydı girilmiş aktiviteleri nasıl zamanlayacağını belirler. Asıl fark sıra dışı ilerlemede ortaya çıkar: yani selefi bitmeden başlayan bir aktivite.

Retained Logic seçiliyken, ilerlemiş aktivitenin kalan süresi tüm selefleri bitene kadar zamanlanmaz. Ağ mantığı korunur. Progress Override seçiliyken ağ mantığı yok sayılır ve aktivite gecikmeden ilerleyebilir. Actual Dates seçiliyken ileri ve geri hesaplar gerçekleşen tarihleri kullanır; gerçekleşen tarihler veri tarihinden sonraysa negatif bolluk üretebilir.

Hangisinin seçileceği programın amacına ve sözleşme şartlarına bağlıdır. Ağ mantığına sadık kalan bir tahmin isteniyorsa Retained Logic, sahada fiilen olanı program tahminine yansıtmak isteniyorsa Progress Override düşünülür. Önemli olan, seçimin yazılı olması, her güncellemede aynı kalması ve değişikliğin açıkça not edilmesidir.

Bununla ilişkili Calculate start-to-start lag from ayarı, selefi sıra dışı başlayan bir başlangıç-başlangıç bağlantısında bekleme süresinin hangi tarihten sayılacağını belirler. Seçenekler Actual Start ve Early Start'tır; Actual Dates seçiliyken bu ayar devre dışıdır.

Toplam bolluk ve kritik aktivite nasıl tanımlanır?

Toplam bolluk (Total Float) hesabı da bir ayardır. Compute Total Float as seçeneği farklı hesap yöntemleri sunar: Start Float, geç başlangıçtan erken başlangıcı çıkarır; Finish Float, geç bitişten erken bitişi çıkarır; Smallest of Start Float and Finish Float ise ikisinden daha kritik olanı alır. Aktivitenin takvimi ve süresi farklılaştığında başlangıç ve bitiş bolluğu birbirinden ayrışabilir, bu yüzden ayarı bilmeden bolluk değerlerini karşılaştırmak yanıltır.

Kritik aktivite tanımı Define critical activities as başlığındadır. Total Float less than or equal to seçeneğinde, bolluğu girdiğiniz değere eşit ya da küçük olan aktiviteler kritik sayılır; birimsiz değer saat kabul edilir. Longest Path seçeneğinde ise projenin en uzun yolu üzerindeki aktiviteler kritik sayılır. Açık uçlu aktiviteler yüzünden yöntemlerin her biri gerçekte kritik olmayan aktiviteleri kritik gösterebilir. Make open-ended activities critical kutusu, açık uçlu aktivitelerin kritik sayılıp sayılmayacağını belirler.

Birden çok proje açıkken Calculate float based on end date of ayarı önem kazanır. Each project seçeneği her projenin kendi bitişini, Opened projects seçeneği ise açık projelerin en geç bitişini baz alır; ikincisi açık uçlu aktivitelere daha fazla bolluk verir. Bu ayar açıkken Schedule komutu ek bir uyarı gösterebilir.

Diğer ayarlar: ne zaman dokunmalı?

General sekmesinde birkaç ayar daha tarihleri doğrudan etkiler:

• Ignore relationships to and from other projects: Projeler arası bağlantıları yok sayar. Veritabanınızda bulunmayan dış projelere bağlı bir projenin dış tarihlerini korumak istiyorsanız bu kutuyu işaretleyin.
• Use Expected Finish Dates: Aktivite bitişlerini beklenen bitiş tarihlerinden alır.
• Schedule automatically when a change affects dates: Aktivite, ilişki ya da kaynak değiştiğinde programı otomatik hesaplar. Kapalıysa değişiklik, siz zamanlayana kadar tarihlere yansımaz.
• Level resources during scheduling: Her zamanlamada kaynak dengelemeyi de çalıştırır.
• Recalculate assignment costs after scheduling: Birden çok fiyatlı atamalarda maliyetleri zamanlama sonrası yeniden hesaplar.
• Calendar for scheduling Relationship Lag: Bekleme sürelerinin hangi takvime göre sayılacağını seçer.

Bu ayarların birçoğunun etkisi zamanlamadan sonra bitiş tarihinde, bolluklarda ya da maliyette görülür. Bir ayarı değiştirmeden önce bitiş tarihini ve kritik yolu not almak, sonra karşılaştırmak mantıklı bir kontroldür.

Zamanlamayı çalıştırmak ve sonucu kontrol etmek

Güvenli bir zamanlama sırası şöyle işler:

• Veri tarihini kontrol edin; çok projeli çalışmada her projenin veri tarihi Project Details penceresinin Dates sekmesinde durur.
• Tools, Schedule yolunu izleyin ya da F9'a basın.
• Options düğmesiyle ayarları gözden geçirin; ekip standardıyla aynı olduklarından emin olun.
• Birden çok proje açıksa her projenin kendi veri tarihini mi, seçilen tek bir veri tarihini mi kullanacağınızı belirleyin.
• Sonuçları denetlemek için Log to File kutusunu işaretleyin.
• Schedule düğmesine basın ve çıkan uyarılara dikkatle yanıt verin.

Sonrasında log dosyasını açın; hangi ayarlarla hesaplandığı ve hangi uyarıların çıktığı orada yer alır. Bitiş tarihi, kritik yol ve negatif bolluk olan aktiviteleri bir önceki zamanlamayla karşılaştırın. Beklenmedik bir değişiklik varsa önce ayarların aynı kalıp kalmadığına, sonra veri tarihine ve son girilen ilerlemeye bakın.

Sık yapılan hatalar

En sık hata, ekip üyelerinin farklı ayarlarla çalışmasıdır. Aynı program bir bilgisayarda başka bir bitiş tarihi gösterdiğinde sebep çoğunlukla zamanlama seçenekleridir. Ayarlar yazılı bir standarda bağlanmalıdır.

İkinci hata, ilerleme mantığını güncellemeler arasında sessizce değiştirmektir. Retained Logic'ten Progress Override'a geçmek bitiş tarihini kendiliğinden değiştirebilir ve bu fark gerçek ilerleme sanılabilir.

Üçüncü hata, Actual Dates ile çalışırken veri tarihinden sonra gerçekleşen kayıt bırakmaktır. Negatif bolluk, çoğu zaman bu kayıtların işaretidir ve ağda bir hata aramak yerine ilerleme verisini düzeltmek gerekir.

Dördüncü hata, kritik yolu yalnız bolluk eşiğine bakarak okumaktır. Açık uçlu aktiviteler yüzünden bazı işler gerçekte kritik olmadığı halde kritik görünebilir; Longest Path ile karşılaştırmak ya da açık uçlu aktiviteleri düzeltmek gerekir.

Beşinci hata, zamanlama logunu hiç kaydetmemektir. Hangi ayarla hesaplandığını sonradan göstermek mümkün olmaz.

Bu beceriyi Mindset programlarında nerede çalışırsınız

Zamanlama ayarları, kritik yol analizinin ve sözleşmesel program denetiminin temelidir. Primavera P6 ile Proje Yönetimi Eğitimi zaman çizelgesi ve kritik yol analizi başlığını; Primavera P6 ile İş Programı Hazırlama ise mantıksal bağlar ve kritik yol analizi ile sözleşmesel kullanım ve program denetimi modüllerini içerir.

Planlama mühendisleri ve program denetçileri için bu programların ortak değeri, zamanlama sonucunu yalnız okumak değil, hangi ayarla üretildiğini sorgulamayı öğretmesidir.