Gecikme Analizi Tipleri ve Tanımları

Öncelikle şunu belirtmeliyim ki gecikme analizleri konusunda diğer mühendislik uygulamalarında olduğu gibi bir uzlaşma mevcut değil , İngiltere’de mahkemede ki bir bilirkişinin kabul ettiği analizi Danimarka’da ki başka bir bilirkişi kabul etmeyebiliyor , ayrıca isimlendirme de bile ayrışmalar söz konusu , bir kurumun TIA olarak adlandırdığı analizi başka bir kurum modelled multi based window analysis olarak yada bir kurumun window analysis olarak adlandırdığı analizi diğer bir kurum snapshot analysis olarak değerlendirebiliyor. Benim görebildiğim kadarıyla bu konuda insanların referans olarak kullandıkları 2 adet protokol var bunlardan birincisi

AACE International Recommended Practice No. 29R-03 -Forensic Schedule Analysis

AACE (American Association of Cost Engineers) tarafından hazırlanan ve çok Teknik bir dile sahip olan bu şartname dünyada kabul gören bir referanslardan biri, , bu şartnamenin avantajı özellikle Amerika ile ilgili bir iş yapıyorsanız bu şartnameye referans yaparak sunduğunuz süre uzatımı iddiasının kabul edilmesi daha olası, dezavantajı ise içerisinde çok fazla analiz seçeneği var ve bu da kafa karıştırıcı olabiliyor, halka açık bir yayın olmadığı için burada paylaşamıyorum ama internette biraz araştırırsanız bulabileceğiniz bir doküman.

İkincisi ise

Society of Construction Law- Delay and Disruption Protocol

SCL (Society of Construction Law) tarafından hazırlanan bu protokol ise bir önceki belgeden daha basit bir dile sahip ve dünyada kabul gören bir başka referans, halka açık olarak kendi sitesinde yayınlanan bu protokole

https://www.scl.org.uk/sites/default/files/SCL_Delay_Protocol_2nd_Edition.pdf

adresini kullanarak ulaşabilirsiniz

Bu protokolün avantajı daha az analiz seçeneği sunması, basit bir dili olması, sadece analizin nasıl yapılacağını açıklamaktansa gecikme ile ilgili tüm detaylara odaklanması ve herkes tarafından ulaşılabilir olması, dezavantajı ise analizlerin AACE de olduğu gibi güzel gruplanmaması. Benim bu protokolü tercih etmemdeki en önemli sebep ise Analiz olarak TAI’yi önermesi.

Yazının bu kısmından sonra vereceğimiz bilgiler SCL protokolü temel alınarak hazırlanmış bilgiler olacaktır, bu protokole göre 6 adet temel analiz var;

Impacted As Planned

Bu teknik gerçekleşen gecikmelerin baseline iş programına işlenerek yeni oluşan programındaki bitiş tarihindeki ötelenmenin süre uzatımına eşit olması mantığıyla yapılan bir analiz , öncelikle bu analizi kullanabilmeniz için iş programının çok iyi hazırlanmış olması ve gecikme anına kadar birebir uygulanmış olması lazım böylece kritik hat değişmemiş ve uyguladığımız impact gerçekten projeyi olması gerektiği gibi ötelemiş olmalı , fakat gerçek hayatta böyle bir proje mümkün değil impact ortaya çıktığında kritik hattın değişmiş olma ihtimali çok yüksek bu yüzden bu Teknik bence kullanılabilir bir teknik değil.

Time Impact Analysis

Bu teknik impactin olduğu zaman aralığındaki en son güncellenmiş iş programına bu impacti uygulayıp proje süresinin ne kadar ötelendiğini hesapladığımız bir yöntem, diğer yöntemlerden farklı olarak eşzamanlı gecikmeleri daha önceki yazımızda anlattığımız gibi kolayca hesaplayabileceğimiz bir yöntem, eşzamanlı gecikmeleri TIA yönteminde nasıl hesaplayabileceğinizi anlattığımız yazı için

http://planlamadanismanlik.com/impacted-as-planned-iap-analizi-neden-ise-yaramiyor/

Linkini kullanabilirsiniz,

Bu tekniğin avantajı diğer bazı tekniklerden farklı olarak sadece impact'in olduğu zaman aralığını analiz edebilirsiniz, eğer proje ortasında bir baseline revizyonu olduysa bile bu sizin hesaplamanızı etkilemez, her ne kadar SCL dokümanında prospective bir yöntem olduğunu söylese de elinizde as-built bir iş programı varsa bir nokta için güncelleme tahmin edip geçmişe yönelik bir çalışmada yapabilirsiniz,

Dezavantajı ise hesaplamanın doğruluğunun tamamen gerçekleşmemiş aktivitelerin tahminlerinin doğru olmasına bağlı olması, mesela gerçekleşmemiş 3 ardıl aktivite aslında aynı anda yapılabiliyorsa ve sizin gecikmeniz bu hat üzerindeyse aslında kritik hatta olmayan bir gecikme kritik hattaymış gibi hesaplanıp hesabınızı etkiliyor , burada yapılabilecek tek şey baseline’ı doğruymuş gibi kabul edip eğer yüklenici bu 3 aktiviteyi aynı anda yaptıysa bunu projeyi hızlandıran bir efor olarak kabul etmek.

Time Slice Window Analysis

Bu teknik her güncellemeyi bir önceki ile karşılaştırıp eğer projenin bitiş zamanında bir değişim varsa bu periyoddaki her iki taraf içinde olan gecikmeleri ayrı ayrı analiz etme üzerine kurulmuş bir sistem , avantajları TIA’da bahsettiğimiz güncellenmemiş aktivitelerin önemi yok çünkü baştan sona tüm güncellemeleri gözden geçirmeniz gerekiyor, eğer bir periyodda proje bitiş tarihinde değişiklik yoksa bu periyod için analiz yapmanıza gerek kalmıyor , ki bu avantaj pek uygulanabilir değil çünkü her güncellemede değişiklikler olması çok muhtemel.

Dezavantajları TIA’da sadece impact öncesi güncellemenin düzgün yapılması yeterli iken bu teknikte tüm güncellemelerinizin düzgün yapılmış olması gerekiyor, hatalı tek güncelleme tüm hesaplamayı bozabiliyor , eğer proje ortasında baseline revizyonu yapıldıysa ,bu gerçekleşmemiş 2 aktivitenin ilişkilerinin düzeltilmesi bile olsa bu tekniği  kullanamıyorsunuz, en önemlisi incelenen peridodaki tüm gecikmeleri teker teker bulmanız ve bunu tüm periyodlar için tekrarlamanız gerekiyor , hata yapmaya çok elverişli,çok uzun ve bence uygulanma ihtimali çok düşük bir prosedür bu.

 As Planned Versus As-Built Window Analysis

Bu tekniği time slice window tekniğinin güncelleme periyodunun tüm proje olduğu bir Teknik olarak düşünebiliriz, yani eğer elimizde düzenli güncellemeler yoksa bu tekniği kullanıyoruz,

Bu tekniğin avantajları ve dezavantajları time slice window analysis ile aynı fakat bu analizde incelenecek periyod çok daha uzun olduğu için hata yapma olasılığı çok daha yüksek.

Retrospective longest path analysis

Bu Teknik as built projede son aktiviteden itibaren geriye doğru gidip en uzun hattı bulup sadece bu hat üzenindeki gecikmeleri hesaba katarak yapılan bir hesaplama,

Avantajı baselinedaki hatalı ilişkilerin önemi kalmıyor,

Dezavantajı ise yapması çok zor ve gecikme yaşandığı zaman en uzun hatta olmayan fakat kritik hatta olup gerçekte projeyi uzatmış aktiviteleri hesaplamaya katamıyorsunuz.

Collapsed As-Built

Bu teknikte ise baseline’ı hiç dikkate almadan as built üzerinden yeni bir iş programı oluşturuyoruz. Daha sonra da bu programdan impact’leri çıkartarak ortaya çıkan yeni programın bitiş tarihi ne kadar öne geldiyse gecikmenin bu süre kadar olduğu kabul ediyoruz.

Avantajı baselinedaki hatalı ilişkilerin önemi kalmıyor,

Dezavantajı yeni oluşturulan programda ilişkiler bir mantık üzerinden değil gerçekleşmeler üzerinden yapıldığı için sıkıntılar yaşanıyor, mesela birbirinden 5 sün soran başlayan ve 10 gün sonra biten 2 aktiviteyi SS 5 gün  veya FF 10gün olarak bağlayabiliyoruz fakat bu iki bağlantı sonucu hesaplama farklı çıkabiliyor , hatta belki 2. Aktiviteyi öteleyen aktivite bambaşka bir aktiviteydi ve analiz sırasında bunun kontrolü pek mümkün olmuyor, aynı gerçekleşmeleri gösteren farklı programlarda çok farklı hesaplamalar ortaya çıkabiliyor.

Sonuç olarak tüm analizleri gözden geçirdiğimizde TIA’nın hem makul bir şekilde uygulanabildiğini hem de nispeten daha doğru sonuçlar verdiğini görüyoruz. Proje sonunda analiz tekniği tartışmalarından kaçınmak için bence kullanılacak yöntem proje basında belirlenmeli, şartname ya da sözleşmede belirtilmeli. Benim bu konuda ki önerim kullanılacak  yöntem TIA olmalı ve impact oluştuktan sonra ilk güncelleme ile birlikte analiz olarak sunulmalı.

 

 

 

 

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir