MS PROJECT BASELINE YÖNETİMİYLE SAPMA RAPORU ÜRETMEK

İşveren toplantıdan çıkıyor, kontrollük "gecikme on iki gün" diyor, yüklenici "yedi gün, çünkü beton mukavemet beklemesi planda yoktu" diyor. İkisi de aynı dosyaya bakıyor ama farklı bir tarih ekseni okuyorlar. Bu eksenin tek nesnel sürümü, programın ilk imzalandığı andaki snapshot'ıdır; yani baseline. Baseline kaydedilmemiş bir programda gecikme sayısı bir görüştür; baseline kaydedilmiş bir programda gecikme sayısı bir veridir.

Bu yazı MS Project'te baseline kavramının nasıl çalıştığını, neden 11 baseline slotu olduğunu, Tracking Gantt görünümünün okunmasını, Variance tablosundaki Finish Variance gibi alanların ne anlattığını ve PMBOK çerçevesinde SV/CV/SPI/CPI gibi earned value göstergelerinin sahaya nasıl bağlandığını anlatır. Türk inşaat pratiğinde hak ediş kesimi ile baseline tarihi nasıl eşlenir, KGM ve DSİ tip projelerinde S-eğrisi sapma raporu nasıl üretilir, Sayıştay denetimine girecek dosyada baseline disiplini ne anlama gelir — bu sorulara somut menü yolları ve örneklerle yanıt verir.

BASELINE NEDEN BİR REFERANS DEĞİL, BİR SÖZLEŞMEDİR?

Bir programı baseline'la donmuş hâle getirmek aslında bir mühendislik kararı değil, ticari bir karardır. Baseline kaydedildiği an "bu tarihlerden sapma artık ölçülecek" diye yazılı bir taahhüt verilmiş olur. Bu nedenle pratikte baseline imza eşiğinden geçmiş programdır: yüklenici teklif programını, kontrollük revize programını, idare onaylı programı kaydeder. Onaysız bir programın baseline'ı tutmaz; tutsa da Sayıştay incelemesinde "bu program nereden geliyor" sorusuna yanıt veremez.

Baseline'ın sözleşmesel niteliğini doğru kavramayanlar tipik dört hatayı tekrarlar:

• İlerleme girip sonra baseline kaydetmek: Variance sıfır çıkar, dosya yalan söyler. Önce baseline, sonra ilerleme — sıra değişmez.
• Her ay baseline güncellemek: Sapma okunamaz hâle gelir çünkü referans hareket eder. Sadece formel değişiklik onayı varsa güncelleme yapılır.
• Baseline'ı sözleşme tarafıyla paylaşmadan değiştirmek: İdarenin elindeki onaylı program ile yüklenicinin .mpp dosyası farklı baseline'ları taşır; toplantıda iki taraf ayrı sayı söyler.
• Tek bir baseline ile çok revizyonlu projeyi yönetmek: Üç defa revize olmuş bir programda tek baseline kaldıysa hangisinden sapma okuyacağı belirsizdir. MS Project bu nedenle on bir slot sunar.

Microsoft'un ürün belgeleri üzerinde Project tab → Schedule grubu → Set Baseline menüsünden bir Baseline ve Baseline 1'den Baseline 10'a kadar toplam on bir snapshot saklanabileceği açıktır. Bu mimari rastgele değil; sözleşme + revize 1 + revize 2 + ... şeklinde Türk kamu yapım işlerinin tipik revizyon serisini doğrudan yansıtacak şekilde tasarlanmıştır. PMBOK terminolojisinde de schedule baseline, cost baseline ve scope baseline üçlüsü "performance measurement baseline"ı oluşturur; MS Project bu üç ekseni tek baseline kaydında start/finish/duration/work/cost alanları ile birlikte saklar.

BASELINE NASIL KAYDEDİLİR VE HANGİ ALANLAR DONAR?

Baseline kaydı tek bir menü adımıdır ama arkasında yirmi civarı alanın anlık fotoğrafı saklanır. Project tab → Schedule grubu → Set Baseline → Set Baseline penceresi açılır. Bu pencerede iki radyo düğmesi vardır:

1. Set baseline: Açılır listede Baseline / Baseline 1 / … / Baseline 10 seçeneklerinden biri seçilir.
2. Set interim plan: Sadece start ve finish tarihlerini saklar; work ve cost saklanmaz. Interim plan slotları Start1/Finish1'den Start10/Finish10'a kadar uzanır.

Aynı pencerede "For" alanında Entire project (proje geneli) veya Selected tasks (seçili görevler) seçilir. Seçili görevler seçildiğinde "Roll up baselines" ile özet görevlere yayılım davranışı belirlenir — bu özellik özellikle bir bölümün revize edilip ana baseline'a entegre edilmesinde işe yarar. Baseline kaydedildiğinde donan alanlar:

• Baseline Start, Baseline Finish
• Baseline Duration
• Baseline Work (kaynak iş yükü)
• Baseline Cost (planlı maliyet)
• Baseline Budget Work / Cost (üst düzey bütçe kalemleri için)
• Time-phased baseline değerleri (BCWS — Budgeted Cost of Work Scheduled hesabı buradan beslenir)

İlk baseline imza sonrası iş programı için saklanır. Onaylı revizyon geldiğinde — örneğin zeyilname ile süre uzatımı verilince — yeni program açılır, eski baseline Baseline 1'e kopyalanır ve yeni baseline ana Baseline slot'una yazılır. Bu sayede sapma analizinde iki referans birden okunabilir: orijinal sözleşmeden sapma vs. son onaylı programdan sapma. Sayıştay denetiminde "hangi revizyondan itibaren bu hesap" sorusuna her revizyonun ayrı baseline'ı ile cevap verilir.

TRACKING GANTT GÖRÜNÜMÜNDE NE OKURUZ?

Standart Gantt görünümü sapmayı görünür kılmaz; her görev tek çubukla görünür. Tracking Gantt'a geçmek için View tab → Task Views grubu → Gantt Chart açılır listesi → Tracking Gantt seçilir. Bu görünümde her görevin altında ikinci bir çubuk belirir.

Çubuk renkleri:

• Alt çubuk gri: Baseline start - Baseline finish aralığı. Donmuş referans.
• Üst çubuk mavi: Kritik yolda olmayan güncel görevin planlanan tarihleri.
• Üst çubuk kırmızı: Kritik yolda olan görevin planlanan tarihleri.
• Üst çubuk üzerinde koyu bant: % Complete oranı; görsel ilerleme göstergesi.

Sapma okuma kuralı basittir: gri çubuğun bittiği yer ile renkli çubuğun bittiği yer arasındaki yatay mesafe Finish Variance'tır. Sağa kayma gecikme, sola kayma erken bitiş demektir. Aynı satırda alt ile üst aynı yerde duruyorsa o görev plana sadık ilerliyor.

Status Date çizgisi (varsayılan olarak Today çizgisi) Tracking Gantt'ın okunmasında merkezdir. Project tab → Status Date alanından hak ediş kesim tarihi girilir. Bu tarih girilmeden Late Tasks, Slipping Tasks raporları bugünün tarihine göre üretilir — hak ediş kesim disipline edilmemişse rapor hak edişe bağlanmaz. Şantiyede haftalık olarak değil aylık olarak status date hak ediş kesimine çekilir; ay sonu güncellemesinden önce ataşman-yeşil defter ile MS Project arasında çapraz teyit yapılır.

VARIANCE TABLOSU HANGİ DÖRT SÜTUNLA ÇALIŞIR?

View tab → Data grubu → Tables → Variance açıldığında görev tablosu dört temel sütuna geçer:

• Start / Finish: Görevin şu an için planlanan başlangıç ve bitişi (actuals dahil).
• Baseline Start / Baseline Finish: Donmuş referans tarihleri.
• Start Variance: Start eksi Baseline Start (gün cinsinden).
• Finish Variance: Finish eksi Baseline Finish (gün cinsinden).

Pozitif değer gecikme, negatif değer erken durumdur. Örnek tablo:

Variance tablosu sadece tarihsel okuma için yeterlidir; iş yükü ve maliyet sapması için ayrı tablolar açılır. View tab → Tables → More Tables menüsünden Work ve Cost tabloları seçilir. Bunlar Baseline Work / Work / Work Variance ve Baseline Cost / Cost / Cost Variance sütunları sunar. Tarihsel gecikme, kaynak aşımı ve maliyet aşımı üçü birden okunduğunda yöneticiye "neden geciktik" sorusuna bütünlüklü cevap verilebilir.

EARNED VALUE ALANLARI (SV, CV, BCWS, BCWP, ACWP) NE ANLATIR?

Tarih sapması ile maliyet sapmasını birlikte okuyan disiplinin adı earned value yönetimidir. PMBOK kılavuzunda standart hâle gelmiş üç temel veri ile dört türev gösterge çalışır. MS Project bu alanların hepsini View tab → Tables → More Tables → Earned Value tablosundan açar. Status Date doğru girilmiş olmalıdır; aksi hâlde tüm hesap kayar.

Üç temel veri:

• BCWS (Budgeted Cost of Work Scheduled / PV): Status Date'e kadar plan gereği harcanmış olması gereken bütçe. Baseline'dan beslenir.
• BCWP (Budgeted Cost of Work Performed / EV): Status Date'e kadar fiilen tamamlanan işin baseline değeri. % Complete × Baseline Cost ile hesaplanır.
• ACWP (Actual Cost of Work Performed / AC): Status Date'e kadar fiilen yapılan harcama.

Dört türev gösterge:

• SV (Schedule Variance) = BCWP − BCWS. Negatif ise işi yapamadık, plana göre geride; pozitif ise plana göre öndeyiz.
• CV (Cost Variance) = BCWP − ACWP. Negatif ise yapılanın baseline değerinden fazla harcadık; pozitif ise tasarruflu.
• SPI (Schedule Performance Index) = BCWP ÷ BCWS. 1'in altı geride, 1'in üstü önde.
• CPI (Cost Performance Index) = BCWP ÷ ACWP. 1'in altı bütçe aşımı, 1'in üstü tasarruf.

Türk inşaat pratiğinde bu kavramları S-eğrisine bağlamak okumayı kolaylaştırır. Hak ediş icmali, dönem dönem fiili harcamayı (ACWP karşılığı) ve fiili imalatın sözleşme birim fiyatları ile karşılığını (BCWP karşılığı) verir. Baseline'dan beslenen aylık planlı harcama eğrisi BCWS karşılığıdır. Üç eğri üst üste çizildiğinde SV ve CV grafiği görsel olarak okunur; yöneticiye sunulan raporun en sade hâli budur.

HAK EDİŞ DÖNEMİYLE BASELINE SAPMA RAPORU NASIL EŞLENİR?

Türkiye'de yapım işlerinde hak ediş aylık veya iki aylık dönemlerde kesilir; KGM tip sözleşmelerinde ayın 26'sından bir ay sonrasına, DSİ projelerinde sözleşmeye göre farklı kesim tarihleri kullanılır. MS Project'in raporu hak ediş kesim tarihiyle aynı status date'i taşımıyorsa rapor hak edişe bağlanamaz, sadece bilgi amaçlı kalır. Pratik akış şu sırayı izler:

1. Hak ediş kesim tarihinin bir gün öncesi şantiyeden ataşman, yeşil defter ve fotoğraf paketi toplanır.
2. Bu veriler MS Project'e Actual Start, Actual Finish, % Complete ve Actual Cost olarak işlenir.
3. Project tab → Status Date alanı hak ediş kesim tarihine çekilir.
4. View tab → Tracking Gantt + Variance tablosu açılır; pdf çıktısı hak ediş klasörüne konur.
5. Earned Value tablosu açılır; SV, CV, SPI, CPI değerleri hak ediş icmal sayfasına özet olarak yedirilir.
6. Visual Reports → Earned Value Over Time (Excel pivot) yöneticiye sunulacak S-eğrisi grafiğini üretir.

Bu zincir kurulduğunda hak ediş ödemesi ve sapma raporu artık aynı dosyada konuşur. Kontrol mühendisi imza atarken hem ödenecek tutara hem o tutarın baseline'a göre nereye düştüğüne bakar; yüklenici tarafı da aynı çıktıyı kendi içinde kontrol etmiş olur. MS Project'in plan-takip disiplinini sahaya bağlamayı baştan kuran MS Project eğitimi içinde bu hak ediş köprüsü örnek bir konut projesi üzerinden uçtan uca işlenir.

KGM, DSİ VE KAMU İŞLERİNDE BASELINE DİSİPLİNİ NEDEN ÖZELDİR?

Kamu yapım işlerinde 4735 sayılı Kamu İhale Sözleşmeleri Kanunu ve Yapım İşleri Genel Şartnamesi (YİGŞ) uyarınca süre uzatımı talebi her zaman bir "neden ve sonuç" zinciri ister: hangi olay, hangi görevi, kaç gün geciktirdi? Bu sorunun makineyle cevaplandığı tek araç baseline'dır. KGM ve DSİ tip projelerinde idare aşağıdaki kalemleri baseline disiplinine bağlı görür:

• Onaylı iş programı: Sözleşme imzasından sonraki 30 gün içinde idareye sunulur; idare onayı sonrası MS Project'te ilk baseline olur.
• Revize iş programı: Süre uzatımı, zeyilname veya kapsam değişikliği halinde yeni program. Onay sonrası Baseline 1'e (veya sıradaki slota) kopyalanır; ana Baseline değişmez.
• S-eğrisi: Aylık planlı/fiili nakit akışı; baseline cost zaman dağılımından üretilir.
• Süre uzatım gerekçe dosyası: Hangi görev geciktiyse Tracking Gantt çıktısı + Finish Variance tablosu + neden tutanağı (hava muhalefeti, ek iş, mücbir sebep) bir arada sunulur.
• Kesin hesap dosyasında baseline-fiili kıyası: Sayıştay denetçisi "süre uzatımı verilmiş, gerekçe nerede" sorusunu Tracking Gantt çıktısının imzalı PDF'i ile yanıtlar.

Bu disiplin bireysel yüklenicide de aynı netlikte kurulmalıdır. İç denetimde "sapma neden oluştu" sorusunun cevabı sözel değil, dosyaya gömülü olmalıdır. Baseline yönetimi bu nedenle MS Project'in kullanıcısının değil, projenin sözleşmesel ekseninin sorumluluğundadır; bir mühendis kararı değil, dosya kararıdır.

BASELINE SİLME, GÜNCELLEME VE GERİYE DÖNME — RİSKLER NEREDE?

Baseline silmek tek tıkla yapılır: Project tab → Set Baseline → Clear Baseline. Açılan pencerede hangi baseline'ın temizleneceği seçilir. Bu işlem geri alınamaz; yedek alınmadıysa o baseline gider. Pratikte hiçbir baseline silinmemeli, yenisi açılırken eskisi sıradaki numaralı slota kopyalanmalıdır.

Güncelleme stratejileri:

• Selected tasks ile kısmi güncelleme: Onaylı bir scope change geldiğinde sadece etkilenen görevler seçilip Set Baseline → Selected tasks ile mevcut Baseline'a yedirilir. Bu yöntem dosyanın geri kalanındaki tarihsel sapmayı korur.
• Yeni slota tam baseline: Büyük revizyonlarda mevcut Baseline → Baseline 1'e kopyalanır (Set Baseline → Baseline 1 + Entire project), sonra revize program ana Baseline'a yeniden yazılır.
• Interim plan ile ara snapshot: Sadece tarih farkı önemli, maliyet değil ise Set Interim Plan ile hızlı bir snapshot alınır; Start5/Finish5 gibi numaralı slotlara yazılır.

En sık görülen baseline yönetim hataları:

1. Onaysız revizyonla baseline güncellemek: İdare onayı olmadan değişen program baseline olamaz. Olursa sapma raporu sözleşmesel anlamını kaybeder.
2. Status Date'i baseline güncellemesi sırasında oynatmak: Earned value hesabı bozulur, BCWS-BCWP-ACWP zinciri zaman ekseninde kayar.
3. Tüm projeyi yeniden baseline'lamak: Tarihsel sapma silinir, dosya "her şey planda" diye yalan söyler. Eski actuals üzerinden hâlâ bir referans varmış gibi görünür ama yoktur.
4. Selected tasks rollup ayarını atlamak: Alt görevler güncellendiğinde özet görev baseline'ı eski kalır; Variance tablosu özet satırında yanlış rakam okur.
5. Interim plan ile baseline'ı karıştırmak: Interim plan sadece tarih saklar; maliyet sapması için kaynak olmaz. Sehven baseline yerine kullanılırsa earned value boş çıkar.

Baseline yönetimi sözleşme disiplininin uzantısıdır. İyi kurulduğunda toplantı masasında iki taraf aynı sayı üzerinden konuşur, kötü kurulduğunda her toplantı yeni baştan başlar. Programı sözleşme zamanında doğru kurmak, baseline'ı zamanında saklamak, her revizyonu numaralı slota yedeklemek — bu üç adım bir projenin sapma raporunu güvenilir tutan tek pratik zincirdir.