MS PROJECT'TE KRİTİK YOL ANALİZİYLE SÜRE YÖNETMEK

Aynı planı iki farklı kontrol mühendisine sorun: birinci hangi imalatın geciktiğini söyler, ikinci bu gecikmenin işin teslim tarihini kaydırıp kaydırmadığını söyler. İkisi arasındaki fark çoğu zaman ihbar süresine sığar; biri haftalık raporun ilk satırını, diğeri yöneticinin masasındaki kararı yazar. Kritik yol analizi bu farkı kuran araçtır: bir gecikmenin programın iç boşluklarında erimesi mi, yoksa bütün takvimi öteleyecek bir kaymaya dönmesi mi gerektiğini söyler. Total slack değeri bunun matematiksel cevabıdır; sıfırsa kritik, pozitifse esnek, negatifse plan zaten geride.

Bu yazı, kritik yol yönteminin (CPM) sahada nasıl okunduğunu, MS Project'in ileri-geri pas hesabını arka planda nasıl yürüttüğünü ve günlük plancı işinde hangi adımların sırayla tutturulması gerektiğini ele alıyor. Yöntemin kökeni 1957'de DuPont mühendisi Kelley ile Remington Rand mühendisi Walker'a uzanır; kimya tesisi bakım planlaması için geliştirilen matematik, bugün Microsoft Project dahil tüm modern planlama araçlarında aynı çekirdek mantıkla çalışır. Türk yapım pratiğinde ise CPM, Yapım İşleri Genel Şartnamesi'nin iş programı taleplerinden Sayıştay sürelerine, savunma sanayi entegrasyon takvimlerinden OSB içi fabrika kurulum planlarına kadar geniş bir yelpazede plancının elindeki en hesaplanabilir araçtır.

KRİTİK YOL HANGİ MATEMATİĞİN ÜZERİNE OTURUR?

Kritik yol, görevler arası bağımlılık ağı içinde proje başlangıcından bitişine giden en uzun zincirdir. Bu zincirin uzunluğu projenin minimum bitiş süresidir; zincirdeki bir gün gecikme projenin tamamını bir gün öteler. Aritmetiği iki yönlü yürür: önce ileri pas, sonra geri pas. İki pas birlikte her görev için dört zaman değeri üretir; bu dört değerden iki adet slack türetilir.

Dört temel zaman değeri:

• ES (Early Start): Görevin en erken başlayabileceği gün. Öncüllerinin EF değerlerinden en geç olanı.
• EF (Early Finish): Görevin en erken bitebileceği gün. Formül: EF = ES + Duration.
• LS (Late Start): Görevin projeyi geciktirmeden başlayabileceği en geç gün.
• LF (Late Finish): Görevin projeyi geciktirmeden bitebileceği en geç gün. Formül: LS = LF - Duration.

İki slack türü bu dört değerden çıkar:

• Total Slack: LS - ES ya da eşdeğeri LF - EF. Görevin proje bitişini kaydırmadan kaybedebileceği gün sayısı.
• Free Slack: Bir sonraki görevin ES'i - mevcut görevin EF'i. Görevin sonraki görevi sıkıştırmadan kaybedebileceği gün sayısı. Her zaman total slack'ten küçük veya eşittir.

Kritik yol, total slack değeri sıfır olan görevlerin oluşturduğu zincirdir. Total slack negatif çıkıyorsa proje zaten hedef tarihin gerisindedir; pozitif çıkıyorsa görev tampona oturmuştur. Kelley ve Walker'ın 1957'de DuPont için kurduğu matematik tam olarak budur; ileri pas en kısa olası bitişi, geri pas hedef bitişe göre tamponları hesaplar. MS Project'in arka planında her schedule recalculation döngüsünde bu iki pas yeniden işler.

MS PROJECT İLERİ PAS HESABINI HANGİ SIRA İLE YÜRÜTÜR?

İleri pas projenin başlangıç tarihinden son göreve doğru ilerler. Her görev için ES değeri öncüllerinin EF değerlerinden en geç olanına bağlanır; sonra EF = ES + Duration ile bitiş çıkarılır. Tek bir öncülü olan görevde hesap düz çalışır; birden fazla öncülü olan birleştirme noktasında en geç biten öncül belirleyicidir. MS Project bu hesabı her görev için anlık yapar; bir görev değiştirildiğinde bağımlı tüm görevlerin ES/EF değerleri yeniden hesaplanır.

Bağımlılık tipi ES değerini doğrudan etkiler:

• FS (Finish-to-Start): Sonraki görevin ES'i, öncülün EF'ine eşittir. Saha dilinde "kalıp söküm bitmeden bir sonraki kat betonu dökülemez". Project varsayılan tipi budur.
• SS (Start-to-Start): Sonraki görevin ES'i, öncülün ES'ine eşittir. Aynı anda başlayan paralel imalatlar için. Genelde lag ile kullanılır: SS+3, öncü başladıktan üç gün sonra ardıl başlasın demektir.
• FF (Finish-to-Finish): Sonraki görevin EF'i, öncülün EF'ine eşittir. Süpürgelik montajının zemin döşemesi ile birlikte bitmesi gibi.
• SF (Start-to-Finish): Sonraki görev başlamadan önceki bitemez. Pratikte nadir; vardiya devirleri veya geçiş senaryolarında karşılaşılır.

Lag ve lead değerleri ileri pas hesabına doğrudan girer. "FS+2g" iki gün gecikmeli bağlanış, "FS-3g" üç gün öne çekilmiş örtüşmeyi anlatır. Lead değerleri, beton dökümünden iki gün sonra çekiciye sökmeyi başlatma gibi pratik senaryolarda kullanılır; ancak negatif lag aşırı kullanılırsa kritik yol mantığı bulanır. Plancılar genelde her görev için en az bir öncül kuralı uygular; öncülsüz görev (dangling task) ileri pas içinde proje başlangıcına bağlanır ve hesap sahanın gerçeğinden kopar.

GERİ PAS NEDEN İLERİ PASTAN BAĞIMSIZ ÇALIŞIR?

Geri pas projenin hedef bitiş tarihinden başlayarak başlangıca doğru ilerler. Bu pas görevlerin en geç ne zaman başlayıp bitmesi gerektiğini hesaplar. Her görev için LF değeri ardıllarının LS değerlerinden en erken olanına bağlanır; sonra LS = LF - Duration ile en geç başlama tarihi çıkar. Hedef bitiş tarihi belirtilmemişse Project ileri pas sonunda bulduğu en erken bitişi referans alır; constraint atanmışsa o tarihi.

Geri pas pratikte üç sahada test edilir:

1. Sabit deadline'lı işler: Kamu yapım takviminde teslim tarihi sözleşmeyle sabittir; geri pas bu tarihten başlar. Total slack hesabı buna göre çıkar.
2. Hedef tarihsiz işler: Mimari ofis içi tasarım gibi esnek programlarda hedef tarih yok; geri pas en erken bitişten başlar. Kritik yol üzerindeki görevler sıfır slack ile başlar, diğerleri pozitif.
3. Geriye sayım planları: Fuar açılışı, ihale teslim tarihi gibi geriye doğru hesaplanan işlerde Project ayarı File > Options > Schedule altından Schedule From: Project Finish Date'e çekilir. İleri pas mantığı geriye doğru çalışır.

Geri pasın görünmez ama belirleyici sonucu negatif slack'tir. Hedef tarih ileri pasın bulduğu en erken bitişten önce ise total slack negatif çıkar; bu plan zaten yapılabilir değil demektir. Yüklenici "süre yetmiyor" itirazını sayısal olarak burada belgeler. Geri pas hesabı total slack negatif çıkardığında plancının önünde üç seçenek vardır: süre uzatımı talebi, kapsam daraltması (descope), fast-tracking veya crashing ile süre sıkıştırma. Hangisinin uygun olduğu Sayıştay denetim perspektifi ve sözleşme ekleriyle birlikte değerlendirilir.

NETWORK DIAGRAM VE GANTT GÖRÜNÜMÜ ARASINDA NASIL GEÇİŞ YAPILIR?

Plancı bir gün içinde iki, bazen üç farklı görünüm arasında gezinir. Her görünüm farklı bir soruya cevap verir; biri diğerinin yerini tutmaz.

Network Diagram, Activity-on-Node (AON) yöntemiyle çizilir; görev kutu, bağımlılık ok olarak gösterilir. 1960'larda yaygın olan Activity-on-Arrow gösterimi modern araçlarda terk edilmiştir. Network'te görev kutusunun rengi kritik yolu doğrudan açığa çıkarır — kırmızı görev kritik, mavi/siyah görev tampona oturmuş. Plancı dangling task'ı en hızlı burada yakalar: bir kutu yalnız duruyorsa öncülü/ardılı eksiktir.

Gantt görünümünde kritik yolu açmak için Gantt Chart Format sekmesindeki Critical Tasks kutusu işaretlenir; kritik görevler kırmızıya döner. Daha sıkı analiz için View > Tables > Schedule menüsünden Total Slack ve Free Slack sütunları açılır; sayısal değerler ile görsel renk karşılıklı kontrol edilir. Critical kabul edilme eşiği varsayılan olarak sıfır gündür ama File > Options > Advanced altındaki "Tasks are critical if slack is less than or equal to" değeri sahaya göre 2-3 güne çekilebilir. Yapım işlerinde havaya bağımlı kalemler için bu eşik yararlıdır; near-critical yolların erken görünmesini sağlar.

BİRDEN FAZLA KRİTİK YOL OLABİLİR Mİ?

Evet, hatta büyük projelerde tek kritik yol istisnadır. Yapım işlerinde mimari, statik, mekanik, elektrik kollarının paralel ilerlediği durumlarda her kol kendi içinde kritik yol oluşturabilir. MS Project varsayılan olarak yalnızca bir kritik yol gösterir — projenin tamamına ait olan. Alt projelerin veya paralel kolların kritik yollarını görmek için File > Options > Advanced altındaki "Calculate multiple critical paths" kutusu işaretlenir. Bu ayar açıldığında her bağımsız kol kendi kritik yolunu kırmızıyla işaretler.

Çoklu kritik yol senaryolarında plancı şu soruları arka arkaya sorar:

1. Her kolun kritik yolu hangi kalemlerden geçiyor?
2. Kollar arası bağımlılık (örn. statik bitmeden mekanik geçişi yapılamaz) hangi noktada birleşiyor?
3. Birleşim noktasında hangi kolun total slack'i daha düşük? O kol darboğazdır.
4. Darboğaz kolda crashing (kaynak artırarak süre kısaltma) ya da fast-tracking (paralel yürütme) mümkün mü?
5. Karar maliyet karşılığında alınıyor mu? Crashing genelde maliyet, fast-tracking risk artırır.

Crashing ve fast-tracking, CPM'in 1957'de tasarımına dahil edilmiş iki klasik manevradır. Türk savunma sanayi entegrasyon takvimlerinde fast-tracking, normalde seri yapılması gereken yazılım entegrasyonu ile donanım kalifikasyon testlerini paralel yürütmek anlamına gelir; risk artırır, süre kısalır. Crashing ise inşaatta vardiya artırma, ek kalıp ekipmanı ile dökümleri paralel yapma gibi maliyet getiren kararlardır. İki yöntemin uygulanabilirliği işin bağımlılık ağına bağlıdır; her görev paralel yürütülemez, her kaynak ikiye katlanamaz.

TAKVİM VE ÇALIŞMA SÜRESİ AYARI SLACK HESABINI NASIL DEĞİŞTİRİR?

MS Project varsayılan olarak haftada 5 gün, günde 8 saat takvim kullanır. Türkiye'de bu varsayım birkaç yerde sahadan kopar:

• Resmi tatiller: 23 Nisan, 1 Mayıs, 19 Mayıs, 15 Temmuz, 30 Ağustos, 29 Ekim. Manuel girilmezse plan bu günleri çalışma günü sayar.
• Dini bayramlar: Ramazan ve Kurban bayramları her yıl farklı tarihte; idari tatil günleri de eklenince 4-6 günlük kapanış olur.
• Yarıyıl/yaz kapanışları: Bazı OSB'ler ve büyük tedarikçiler temmuz-ağustosta 2 hafta tatil yapar; bu ana planın kritik yoluna işlenmezse ardıl imalatlar 2 hafta sapar.
• Cumartesi yarım gün ayarı: Şantiyelerde Cumartesi yarım gün çalışma yaygın; Project bunu otomatik çekmez.
• Saat 18 sonrası mesai: Vardiyalı işlerde günlük 8 saat varsayımı plan süresini şişirir.

Takvim ayarı için Project sekmesi > Change Working Time menüsüne girilir. Exceptions sekmesinde tatil adı ve tarih aralığı tanımlanır; Work Weeks sekmesinde Cumartesi yarım gün gibi senaryolar işlenir. Yeni bir takvim ("Şantiye Takvimi", "Ofis Takvimi" gibi) oluşturulup ilgili görevlere atanır; her görev kendi takvimi üzerinden yürür. Türk pratikte üç takvimi yan yana tutmak yaygındır: Genel proje takvimi (tatiller dahil), Şantiye takvimi (Cumartesi yarım), Mühendislik ofis takvimi (5x8 standart).

Takvim ayarının slack hesabına etkisi doğrudandır. 60 günlük bir görevin başlangıç ve bitiş tarihleri tatil günlerine denk geliyorsa Project bu günleri sayar, total slack pozitif görünür; ama saha gerçeği takvimi farklı olduğunda gerçek tampon erimiş olur. Plancı kritik yolu yorumlamadan önce takvim ayarını doğrular; bu adım atlanırsa total slack sayıları yanıltır.

BASELINE ALINMADAN KRİTİK YOL YORUMLANIR MI?

Hayır. Baseline (referans plan), plan onaylandığında alınır ve o andaki tüm ES, EF, LS, LF, Duration, maliyet değerleri dondurulur. İlerleyen haftalarda fiili veri girildikçe yeni hesaplanan değerler baseline ile karşılaştırılır. Baseline alınmayan projede "plana göre 10 gün geride" cümlesi sayısal olarak savunulamaz; karşılaştırılacak referans yoktur. PMI ve PMBOK literatürü baseline'ı CPM hesabının ön koşulu olarak ele alır; Türk yapım pratiğinde ise Sayıştay denetiminde plan revizyonlarının gerekçesi baseline farkları üzerinden okunur.

Baseline alma süreci pratik adımlar:

1. Plan idare/yüklenici tarafından onaylanır.
2. Project sekmesi > Set Baseline komutu açılır. Project varsayılan olarak 11 baseline (Baseline, Baseline 1 … Baseline 10) saklayabilir.
3. "Entire project" seçilir; tüm görevler dondurulur.
4. Revizyon olursa yeni baseline (Baseline 1, Baseline 2) atanır; eski baseline silinmez, karşılaştırma için kalır.
5. Status Date her hafta sabitlenir (Project > Status Date). İlerleme veri o tarih itibariyle girilir.
6. Tracking Gantt görünümünde baseline çubuğu (gri) ile fiili çubuk (mavi/kırmızı) üst üste görünür; gözle kaydırma okunur.

İlerleme girişi üç yöntemden biriyle yapılır: % Complete (en hızlı, en yanıltıcı), Actual Duration + Remaining Duration (süre bazlı), Actual Work + Remaining Work (saat bazlı). Yapım işlerinde % Complete genellikle hakediş pursantajı ile zorlanır; gerçek üretimi yansıtmayabilir. Tasarım ofisinde Actual Work daha sağlıklıdır çünkü iş gücü saat üzerinden takip edilir. Hangi yöntem seçilirse seçilsin, kritik yol her haftalık update sonrası yeniden hesaplanır — başlangıçta kritik olmayan bir görev fiili gecikme sonucu kritik yola düşebilir.

Bu döngünün uygulamada nasıl kurulduğunu, baseline'dan haftalık güncellemeye, kaynak leveling'den fiyat farkı senaryolarına kadar uçtan uca işleyen MS Project eğitimi içinde yapım takvimi vakalarıyla birlikte pratik olarak çalışılır; formül bilen plancının saha kararı verebilen plancıya dönüşmesi tam olarak bu döngü kurulduğunda olur.

KAYNAK LEVELING KRİTİK YOLU NEDEN DEĞİŞTİRİR?

Kaynak leveling, aşırı yüklenmiş kaynakları rahatlatmak için görevleri otomatik kaydıran fonksiyondur. Aynı kontrol mühendisi aynı anda iki paralel statik görevde %100 atanmışsa, leveling görevlerden birini öne veya arkaya kaydırır. Bu kaydırma sırasında görevin slack değeri değişir; daha önce kritik yolun dışında olan bir görev kritik yola düşebilir, daha önce kritik olan bir görev kritik dışına çıkabilir. Leveling matematiksel olarak ileri-geri pas hesabını yeniden tetikler.

Leveling'e gitmeden önce mutlaka baseline alınmalıdır. Aksi halde leveling sonrası "kritik yol değişti" iddiası karşılaştırılacak referans olmadığı için belirsiz kalır. Leveling işlemi Resource sekmesi > Level All veya Level Selection komutu ile başlatılır; Leveling Options menüsünden öncelik kriterleri (ID order, Priority, Standard) ayarlanır.

Leveling sonrası dört kontrol yapılır:

• Yeni kritik yol haritası: Hangi görevler kritik yola düştü, hangileri çıktı?
• Total proje süresi: Leveling uzattıysa ne kadar uzattı? Bu fark sözleşme süresine sığıyor mu?
• Slack dağılımı: Near-critical görevler (slack 1-3 gün) hangileri? Bu görevler her an kritik yola düşebilir.
• Kaynak yüklemesi: Resource Usage görünümünde herhangi bir kaynak hâlâ overallocated mu?

Leveling otomatik yapılırsa Project görev önceliklerini ve constraint'leri dikkate alır. Manuel leveling, deneyimli plancının görev görev hangi göreve hangi süre kaydırılacağına karar vermesidir; daha kontrollü ama yorucu. Karma yaklaşım — önce otomatik, sonra manuel düzeltme — büyük yapım projelerinde tercih edilir. Sonuç ne olursa olsun, leveling sonrası kritik yol yeniden okunmadan plan idareye sunulmaz.

HAFTALIK UPDATE DÖNGÜSÜ HANGİ ADIMLARDA AKAR?

Kritik yol, statik bir hesap değildir; her haftalık update sonrası yeniden hesaplanan canlı bir göstergedir. Plancının haftalık döngüsü tipik olarak şu sırada yürür:

1. Saha verisi toplama: Şantiye şefi ve kontrol mühendisi haftalık ilerleme formunu doldurur. Hangi görev başladı, hangisi bitti, hangisinin tahmini kalan süresi değişti.
2. Status Date sabitleme: Project > Status Date menüsünden cuma günü sabitlenir. Tüm update bu tarihe göre yorumlanır.
3. İlerleme girişi: Update Project veya Task Information > Tracking sekmesinden % Complete, Actual Duration veya Actual Work girilir.
4. Yeniden hesaplama: Project otomatik ileri-geri pas yeniden çalıştırır. Kritik yol değişir veya aynı kalır.
5. Sapma okuma: Tracking Gantt'ta baseline ile fiili çubuk farkı; Variance tablosunda günlük rakam.
6. Near-critical kontrol: Slack 1-3 gün arası görevler tek tek okunur; bu görevler bir sonraki haftanın kritik yolu adayıdır.
7. Kaynak yüklemesi kontrol: Resource Usage; kırmızı çıkan kaynak varsa o kaynağa atanan kritik görev tek tek incelenir.
8. Toplantı raporu: Üç çıktı: kritik yol sapması (gün), tampona oturmuş görevlerin durumu, gelecek hafta riskli kalemler.

Bu döngü kurulduğunda kritik yol artık bir grafik öğesi olmaz; haftalık karar üreten bir hesaba döner. Plancı sapmayı sayısal olarak söyler, müteahhit önündeki seçenekleri (süre uzatımı, crashing, fast-tracking) görür, kontrol mühendisi sözleşmeyle uyumu doğrular. Türk kamu yapımında bu döngü ne kadar disiplinli işliyorsa, Sayıştay denetiminde belge zinciri o kadar tutarlı kapanır; düzensiz update yapılan projeler genelde kesin hesap aşamasında süre uzatım gerekçelerini ispat edemez.