P6 EPPM Kurulumu: Keşke Elimde Olsaydı Dediğim Kontrol Listesi

Savunma yüklenicileri, enerji şirketleri, altyapı programları ve madencilik operasyonları için P6 EPPM kurulumları yönettim veya destekledim. Her birinde sürprizler oldu. Ama işlerin nerede ters gittiğinin örüntüsü şaşırtıcı derecede tutarlı.

Bu, şu an kullandığım kontrol listesi. Teorik değil — yara izlerinden inşa edildi.

Kurulumlar Neden Başarısız Olur

Zorlandığını gördüğüm P6 kurulumlarının kabaca %80’inde üç kök neden var:

1. Organizasyonel değişimi hafife almak. P6 EPPM sadece bir yazılım değil. İnsanların ilerlemeyi nasıl raporladığını, yöneticilerin görünürlüğü nasıl elde ettiğini ve kimin neyi görebildiğini değiştirir. On yıldır standalone P6 Professional kullanan bir planlamacı, programının artık PMO tarafından gerçek zamanlı görülebildiğini duymak istemez. O direnç gerçektir ve görmezden gelmek ölümcüldür.

2. İşi bir BT projesi gibi ele almak. 400 bin dolarlık bir kurulumun, sunucuları ve veritabanlarını iyi bilen ama hayatında hiç P6 açmamış bir BT proje yöneticisine devredildiğine tanık oldum. Altyapı kusursuzdu. Konfigürasyon tam bir felaketti. P6 EPPM, tesadüfen sunuculara ihtiyaç duyan bir iş süreci projesidir.

3. Yeterince test etmeden canlıya geçmek. “Test ettik — login sayfası çalışıyor.” Bu test değildir. Test demek, gerçek bir planlamacının gerçek bir programı yüklemesi, gerçek resource’lar ataması, program hesaplaması çalıştırması, bir XER export etmesi ve rapor üretmesi demektir. Bunu gerçek kullanıcılarla yapmadıysanız test etmediniz.

Faz 1: Keşif ve Gereksinimler (1-3. Haftalar)

• Tüm paydaş gruplarını belirleyin (planlamacılar, PM’ler, PMO, yöneticiler, BT)
• Paydaş görüşmeleri yapın — planlama verisini kim, nasıl tüketiyor?
• Mevcut araç ve süreçleri belgeleyin (Standalone P6? Excel? MS Project? Peçete arkası?)
• Mevcut planlama olgunluğunu değerlendirin (DCMA 14-point? Baseline bile alıyorlar mı?)
• Fonksiyonel gereksinimleri tanımlayın (planlama, resource yönetimi, raporlama, portföyler)
• Teknik gereksinimleri tanımlayın (kullanıcı sayısı, eşzamanlı oturumlar, veri hacmi, erişilebilirlik)
• Entegrasyon gereksinimlerini tanımlayın (ERP, maliyet, doküman yönetimi)
• Başarı kriterlerini belirleyin — spesifik ve ölçülebilir
• Üst yönetim sponsorluğunu yazılı olarak teyit ettirin

Sık düşülen tuzak: Gereksinimleri yalnızca yönetimden toplamak. Bunu ikinci kurulumumda yaptım ve direktörlerin bayıldığı ama planlamacıların kullanmayı reddettiği bir sistem kurdum. P6’yı günde sekiz saat kullanacak insanlarla konuşun. En çok onların gereksinimleri önemli.

Faz 2: Mimari ve Tasarım (3-6. Haftalar)

• Sunucu ortamını boyutlandırın (P6, sanıldığından daha aç bir uygulamadır — uygulama katmanı için minimum 16GB RAM bütçeleyin)
• Veritabanı platformu seçimi (EPPM için Oracle DB zorunludur — bu opsiyonel değil; hayır, PostgreSQL çalışmaz)
• WebLogic dağıtımını tasarlayın (HA için cluster, load balancer, session persistence)
• Uygulama katmanını planlayın (P6 Web, P6 Professional gateway, API servisleri)
• Güvenlik modelini tasarlayın (OBS tabanlı erişim kontrolü, rol tanımları, LDAP/AD entegrasyonu)
• Entegrasyon mimarisini çıkarın (hangi sistemler P6 ile konuşuyor, hangi yönde, ne sıklıkla)
• Ortamları tanımlayın (dev, test, production — minimum bu. Ben bir de eğitim ortamı eklemeyi tercih ederim)
• Felaket kurtarma planı (yedekleme sıklığı, saklama süresi, RTO/RPO)
• Ağ mimarisi (firewall kuralları, uzak kullanıcılar için VPN, dış erişim için DMZ)
• Mimarinin BT operasyonlarına devri için dokümantasyon hazırlayın

Sık düşülen tuzak: WebLogic katmanını küçük boyutlandırmak. Tedarikçi ne derse desin, tek uygulama sunucusu high availability değildir. Bir müşterim tek app server ile canlıya geçti. İlk aylık raporlama döngüsünde, 40 kullanıcı aynı anda yüklenince sistem çöktü. En az iki cluster’lı instance için bütçe ayırın.

Faz 3: Konfigürasyon (6-10. Haftalar)

İş kararlarının verildiği yer burası. Buradaki her ayar bir süreç tercihini yansıtır.

• OBS yapısını tanımlayın (organizasyonunuzun raporlama hatlarını yansıtır; organizasyon şemanızın birebir kopyası olmak zorunda değil)
• EPS hiyerarşisini kurun (Enterprise Project Structure — projelerin nasıl gruplandığı)
• Standart WBS yapılarıyla proje şablonları oluşturun
• Global takvimleri yapılandırın (şirket tatilleri, standart çalışma haftaları)
• Projeye özel takvim şablonları oluşturun (vardiya düzenleri, bölgesel tatiller)
• Standart dışı programlar için resource takvimlerini tanımlayın
• Activity code sözlüğünü kurun (faz kodları, alan kodları, disiplin kodları)
• UDF kütüphanesini tanımlayın (User Defined Fields — büyümeye alan bırakın ama ilk gün 200 UDF yaratmayın)
• Kullanıcı rollerini ve yetki profillerini yapılandırın (ben genellikle 5-7 rol tanımlarım: Viewer, Scheduler, Senior Scheduler, Project Manager, PMO, Admin, Executive)
• Global admin tercihlerini ayarlayın (varsayılan duration type, percent complete type, scheduling seçenekleri)
• Unifier entegrasyon ayarlarını yapılandırın (uygulanabiliyorsa)
• BI Publisher veya P6 Web üzerinde rapor şablonlarını kurun

Sık düşülen tuzak: Her proje yöneticisinin kendi kod yapısını tanımlamasına izin vermek. Altı ay sonra elinizde 14 farklı kodlama geleneği olur ve projeler arası raporlama imkânsızlaşır. Kimse proje oluşturmadan önce activity code’larınızı, WBS yapınızı ve adlandırma kurallarınızı standartlaştırın. Bir planlama prosedürleri el kitabı yayımlayın ve uygulatın.

Faz 4: Veri Taşıma (8-12. Haftalar)

Bu faz konfigürasyonla örtüşür, çünkü içine veri taşıyacağınız yapılandırılmış bir sisteme ihtiyacınız var.

• Tüm kaynak veriyi envantere alın (XER dosyaları, XML, MPP dosyaları, Excel programları, standalone veritabanları)
• Her kaynağın veri kalitesini değerlendirin (baseline’lar sağlam mı? actual’lar kayıtlı mı? mantık temiz mi?)
• Alan eşleme dokümanları oluşturun (kaynak alan → P6 hedef alanı, her alan için)
• Taşıma script’leri yazın veya Oracle’ın taşıma araçlarını kullanın
• Pilot taşıma yapın — temsilî bir proje, uçtan uca
• Pilotu doğrulayın (tarihler tutuyor mu? resource’lar aktarıldı mı? ilişkiler sağlam mı? baseline’lar doğru mu?)
• Pilotta bulunan sorunları düzeltip tekrarlayın
• Toplu taşımayı partiler halinde yürütün (500 projeyi tek seferde taşımaya kalkmayın)
• Taşınan her projeyi doğrulayın — rastgele kontroller yetmez
• Neyin taşınmadığını ve nedenini belgeleyin (belgelendiği sürece bir miktar veri kaybı kabul edilebilir)

Sık düşülen tuzak: Çöp veriyi taşımak. Mantığı ve baseline’ı olmayan 3.000 activity’lik bir programı EPPM’e taşımak onu daha iyi yapmaz. Yeni sisteminizi daha ilk günden kötü gösterir. Müşterilere şunu söylerim: önce temizleyin ya da hiç taşımayın. Olduğu gibi arşivleyin ve EPPM’de sıfırdan başlayın.

Yakın zamanda bir enerji sektörü kurulumunda taşıma için 120 standalone programı değerlendirdik. Yalnızca 45’i asgari kalite eşiğini geçti. Kalan 75’i arşivlendi ve proje ekipleri bunları EPPM’de düzgün biçimde yeniden kurdu. Acı verdi ama doğru karardı.

Faz 5: Entegrasyon (10-16. Haftalar)

P6’yı standalone çalıştırıyorsanız bu bölümü atlayın. Ama entegrasyona ihtiyacınız varsa, erken planlayın.

• ERP entegrasyonu (SAP, Oracle EBS, JD Edwards — tipik olarak maliyet ve WBS senkronizasyonu)
• Doküman yönetimi entegrasyonu (Aconex, SharePoint, Unifier)
• Maliyet yönetimi entegrasyonu (EcoSys, Cleopatra, HCSS)
• Risk yönetimi entegrasyonu (ARM, Safran)
• P6 Integration API’yi yapılandırın (sürüme göre REST veya XML tabanlı)
• Her entegrasyon noktasını tek tek kurup test edin
• Entegrasyonları birlikte test edin (eşzamanlı senkronizasyonlar arası çakışmalar yaygındır)
• Hata yönetimi ve uyarı mekanizması kurun (SAP senkronizasyonu gece 2’de düşerse kime haber gidecek?)
• Entegrasyon takvimlerini belgeleyin (ne, ne zaman, hangi sırayla çalışıyor)
• Yük altında performans testi yapın (entegrasyon işleri 30 eşzamanlı kullanıcıyla yarışırken)

Sık düşülen tuzak: Entegrasyonu canlıya geçişten sonra yapılacak bir “Faz 2” olarak ele almak. Bunu en az beş kurulumda gördüm. Faz 2 asla gelmez. Entegrasyon bir gereksinimse şimdi kurun. Gerçekten bekleyebiliyorsa, bunu finansmanı ayrılmış bir takvimle yazılı hale getirin.

Faz 6: Test ve Eğitim (14-18. Haftalar)

• Gerçek iş akışlarına dayalı UAT test senaryoları yazın (proje oluştur, programla, resource ata, ilerleme gir, rapor al)
• UAT’yi yalnızca uygulama ekibiyle değil, gerçek son kullanıcılarla yürütün
• Gerçekçi veri hacimleriyle performans testi yapın (50.000+ activity yükleyin ve ne olduğuna bakın)
• Gerçekçi eşzamanlı kullanıcı sayısıyla performans testi yapın (30 kullanıcılık lisansınız, aynı anda 30 kişi demek)
• Güvenlik testi yapın (bir planlamacı görmemesi gereken projeleri görebiliyor mu? bir viewer düzenleme yapabiliyor mu?)
• Role dayalı eğitim materyalleri geliştirin (planlamacının eğitimi PM’inkinden farklıdır)
• Planlamacı eğitimini verin (uygulamalı, 2-3 gün, gerçek yapılandırılmış sistem üzerinde alıştırmalarla)
• PM eğitimini verin (raporlama, dashboard’lar, ilerleme güncellemeleri odaklı — 1 gün)
• Admin eğitimini verin (ayrı bir hat: kullanıcı yönetimi, güvenlik, global değişiklikler, sorun giderme)
• Yönetici eğitimini verin (dashboard’lar ve KPI’lar üzerine 30 dakikalık genel bakış)
• Sık işlemler için hızlı başvuru kılavuzları hazırlayın
• UAT’de bulunan tüm kritik ve yüksek öncelikli sorunları canlıya geçişten önce düzeltin

Sık düşülen tuzak: İnsanları canlıya geçişten altı hafta önce eğitmek. Gerçekten oturum açtıklarında öğrendiklerinin %70’ini unutmuş olurlar. Eğitimi canlıya geçişe olabildiğince yakın verin — ideali bir hafta öncesi. 3. hafta için de tazeleme oturumları planlayın.

Faz 7: Canlıya Geçiş ve Hypercare (18-22. Haftalar)

• Geçiş (cutover) planını netleştirin (olay sırası, sorumlular, geri dönüş kriterleri)
• Canlıya geçiş tarihini ve beklentileri tüm kullanıcılara duyurun (en az 2 hafta önceden)
• Geçişi yürütün (production konfigürasyonunu dağıtın, son veriyi taşıyın, kullanıcı erişimini açın)
• Eski sistemi kilitleyin (kimsenin iki sistemi birden güncellemesine izin vermeyin)
• Hypercare destek masası kurun (ilk 4 hafta için adanmış P6 desteği)
• Bildirilen sorunları günlük triyaja alın (sınıflandırın: hata mı, eğitim eksiği mi, değişiklik talebi mi?)
• Hypercare süresince yürütme kuruluna haftalık durum raporları verin
• İç admin ekibiyle bilgi aktarımı oturumları yapın
• Hypercare’de bulunan sorunlara göre dokümantasyonu güncelleyin
• Resmî hypercare çıkışı — sistemin stabil olduğunu ve desteğin devredildiğini teyit edin

Sık düşülen tuzak: Danışman canlıya geçişten sonra gider. İç ekip hazır değildir. Sorunlar birikir, kullanıcılar güvenini kaybeder ve altı ay sonra EPPM’i kimse kullanmıyordur. Düzgün bir devir planı kurun. Danışmanı, canlıya geçiş sonrası en az 4 hafta iç ekiple birlikte tutun.

Takvim Gerçeklik Testi

Fiilen gördüklerim şunlar:

Kapsam	Gerçekçi Takvim
Tek iş birimi, entegrasyonsuz	12-16 hafta
Tek iş birimi, 1-2 entegrasyon	16-22 hafta
Kurum genelinde, birden çok iş birimi	20-30 hafta
Kurum genelinde, karmaşık entegrasyonlarla	30-40 hafta

Size tam bir EPPM kurulumunu 6 haftada yapabileceğini söyleyen biri ya köşe kesiyordur ya da “kurulum” kelimesini “yazılımı yükledik” anlamına gelecek şekilde yeniden tanımlıyordur. Yükleme 2. haftanın işidir. Ondan sonrası asıl iştir.

En Önemli Tek Şey

Üst yönetim sponsorluğu. Bir genel müdür yardımcısının proje beratını imzalayıp ortadan kaybolduğu türden değil. Yetki sahibi birinin yürütme kurulu toplantılarına bizzat geldiği, engelleri kaldırdığı ve organizasyona bu işin olacağını net biçimde hissettirdiği türden.

Parçası olduğum her başarılı P6 EPPM kurulumunun güçlü bir sponsoru vardı. Başarısız olanların ya hiç sponsoru yoktu ya da kâğıt üstünde vardı. Gerçek bir sponsorluğunuz yoksa, başka her şeyden önce onu düzeltin.

Yukarıdaki fazlar, bir P6 EPPM kurulumu çalışmasının iskeletidir — düzgün yürütülmüş, sponsorluk sorusu en baştan çözülmüş haliyle.