Primavera P6'yı Power BI'a Bağlamanın Dört Yolu (ve Hangisi Ne Zaman)

Her Primavera P6 kurulumu er ya da geç aynı duvara toslar: paydaşlar dashboard ister, P6’nın yerleşik raporlaması ise modern bir BI aracının sunduğunu sunamaz. Power BI çoğu kurum için varsayılan tercih haline geldi, sebepsiz de değil — zaten parasını ödedikleri Microsoft yığınının içinde.

Soru artık P6’yı Power BI’a bağlayıp bağlamamak değil, nasıl bağlamak. Aşağıdaki dört yaklaşımın hepsini gerçek programlarda uyguladım; her biri farklı bir duruma oturuyor. Yanlış yöntemi seçmek, aylarca sürecek yeniden çalışma demek.

Yöntem 1: XER Export ile Power BI (Hızlı Kazanım)

Çoğu ekip buradan başlıyor ve açıkçası bu yöntemin hakkı yeniyor.

Nasıl çalışır

P6 programınızı XER dosyası olarak export edin (P6 Professional’da File > Export, ya da P6 web arayüzü üzerinden). Sonra XER dosyasını Power BI’ın Power Query (M dili) tarafında parse edin. XER dosyaları tablo başlıkları içeren, tab ile ayrılmış metin dosyalarıdır — formatı bir kez anlayınca şaşırtıcı derecede kolay parse edilirler.

Uygulama

Power Query’de XER’i metin dosyası olarak yükler, tablo ve alan sınırlarını işaretleyen %T ve %F ayraçlarına göre bölersiniz. Her tabloyu (TASK, TASKPRED, RSRC, TASKRSRC vb.) tanıyıp veriyi düzgün kolonlara döndüren M kodu yazarsınız.

TASK tablosu için tipik bir M sorgusu 30 satır civarındadır. Önemsiz değil ama büyük bir mühendislik işi de değil.

Artıları

• Sıfır altyapı gereksinimi — bir laptop ve P6 Professional yeter
• Veritabanı erişimi gerekmez, API kimlik bilgisi gerekmez, IT’nin dahil olması gerekmez
• Hangi veriyi export edeceğiniz tamamen sizin kontrolünüzde (belirli projeler, belirli alanlar)
• Standalone Professional kurulumları dahil her P6 sürümüyle çalışır

Eksileri

• Manuel süreç — birinin XER’i export edip Power BI veri setini yenilemesi gerekir
• Yalnızca anlık görüntü; XER dosyalarını arşivlemezseniz tarihsel trend yok
• Oracle sürümler arasında formatı değiştirirse XER parse işlemi kırılabilir (nadir ama oluyor)
• Export ayarlarına bağlı olarak XER’deki kaynak ve maliyet verisi eksik kalabilir

En uygun olduğu durumlar

Ad-hoc analiz, küçük ekipler, altyapıya yatırım yapmadan önce konsept kanıtlama. Ben bunu program sağlığı değerlendirmelerinde de kullanıyorum — XER’i export edip tüm DCMA 14-point metriklerini otomatik hesaplayan bir Power BI şablonundan geçiriyorum.

Yöntem 2: Doğrudan Veritabanı Bağlantısı (Kurumsal Oyun)

Büyük kurumlarda gördüğüm en yaygın üretim kurulumu bu.

Nasıl çalışır

P6 EPPM tüm verisini bir Oracle veritabanında tutar (kuruluma göre SQL Server da olabilir). Power BI, Oracle ODP.NET sürücüsü ya da SQL Server bağlayıcısıyla bu veritabanına doğrudan bağlanır.

Sorguları ya P6’nın temel şema tablolarına (TASK, TASKPRED, PROJECT vb.) ya da Extended Schema’ya — Oracle’ın özellikle raporlama için sunduğu denormalize görünüm setine — yazabilirsiniz. Extended Schema ile çalışmak daha kolaydır ve desteklenen yaklaşım da budur.

Uygulama

Power BI gateway makinenize Oracle Data Access Client kurun. P6 veritabanını gösteren bir veri kaynağı tanımlayın. SQL sorguları yazın ya da DirectQuery modunu kullanın.

En çok kullanacağınız Extended Schema görünümleri:

• TASK_SPREAD — zamana yayılmış kaynak ve maliyet verisi
• TASKSUM — aktivite düzeyinde özet veri
• PROJSUM — proje düzeyinde toplamlar
• RSRCSUM — kaynak özetleri

Power BI Service’te zamanlanmış yenileme kurun (tipik olarak günlük ya da haftalık).

Artıları

• Zamanlanmış yenilemeyle gerçek zamana yakın veri erişimi
• P6’daki her alana tam erişim — UDF’ler, kodlar ve notebook’lar dahil
• Büyük veri setlerini verimli işler — SQL filtreleme veritabanı tarafında yapılır
• P6 arşiv tablolarını tutuyorsanız tarihsel veri de elinizin altında

Eksileri

• Bağlantı kurulumu, kimlik bilgileri ve firewall kuralları için DBA desteği gerekir
• Oracle istemci sürücüsü kurulumu sancılıdır — sürücü, veritabanı ve işletim sistemi arasındaki sürüm uyumsuzlukları, size bir gününüze mal olacak anlaşılmaz hatalar üretir
• Güvenlik incelemesi gerekir — çoğu IT ekibi bir BI aracının üretim veritabanını doğrudan sorgulamasını istemez
• Extended Schema’nın yapılandırılması ve periyodik olarak yenilenmesi gerekir (P6 Admin tarafında ayrı bir süreçtir)

En uygun olduğu durumlar

Özel IT desteği olan büyük kurumlar, güvenilir günlük yenileme isteyen üretim dashboard’ları ve birden çok projenin birlikte raporlanması gereken programlar. P6 EPPM’i zaten kurmuş kurumlar için varsayılan önerim budur.

Yöntem 3: P6 REST API ile Power BI (Modern Yaklaşım)

P6 EPPM (15.2 ve sonrası) son birkaç sürümde belirgin biçimde olgunlaşan bir REST API içeriyor. P6 Cloud’daysanız ya da güncel bir on-premise EPPM sürümündeyseniz en temiz entegrasyon yolu bu.

Nasıl çalışır

Power BI’ın Web bağlayıcısı (ya da özel bir Power Query fonksiyonu) P6 REST API uç noktalarına HTTP GET istekleri gönderir. API JSON döner ve Power Query bunu doğal olarak parse eder. Kimlik doğrulama, P6 yapılandırmanıza göre Basic Auth ya da OAuth ile yapılır.

Uygulama

Temel API uç noktaları:

• /restapi/activity — tüm standart alanlarıyla aktiviteler
• /restapi/relationship — aktivite ilişkileri
• /restapi/resourceAssignment — kaynak atamaları
• /restapi/project — proje düzeyinde veri
• /restapi/udfValue — user-defined field değerleri

Kimlik doğrulama, sayfalama ve alan seçimini yöneten Power Query fonksiyonları yazarsınız. API, OData tarzı $filter ve $select parametrelerini destekler; veriyi kaynağında sınırlayabilirsiniz.

Tipik bir kurulumda uç nokta başına bir tane olmak üzere 5-8 Power Query fonksiyonu ve ortak bir kimlik doğrulama fonksiyonu bulunur.

Artıları

• Doğrudan veritabanı erişimi gerekmez — IT ekipleri API erişimine daha sıcak bakar
• P6 Cloud ile çalışır (orada veritabanı erişimi zaten hiç yok)
• Güvenliği API yönetir — kullanıcılar yalnızca P6 yetkilerinin izin verdiği veriyi görür
• Temiz JSON çıktısı; kapalı dosya formatı parse etmeye gerek yok

Eksileri

• Büyük veri setlerinde sayfalama şart — varsayılan sayfa boyutu 200 kayıt, bazı uç noktalar istek başına 5.000 ile sınırlı
• Büyük programlarda ilk yüklemeleri rate limit yavaşlatabilir (30.000+ aktivite çekerken bunu bizzat yaşadım)
• P6 verisinin tamamı API’den erişilebilir değil — bazı tablolar ve alanlar eksik
• UDF değerleri ayrı bir uç noktadan gelir ve aktivitelerle join gerektirir; bu da karmaşıklık ve ek API çağrısı demek
• EPPM lisansı gerekir — standalone P6 Professional’da REST API yok

En uygun olduğu durumlar

P6 Cloud müşterileri (tek seçeneğiniz bu olabilir), DBA’in veritabanı erişimi vermediği kurumlar ve halihazırda API entegrasyonu deneyimi olan ekipler.

Yöntem 4: Middleware/ETL Hattı (Tam Teşekküllü Hat)

P6, kurumsal bir analitik platformunu besleyen birkaç kaynak sistemden biriyse, düzgün bir ETL katmanına ihtiyacınız var demektir.

Nasıl çalışır

Bir middleware aracı P6’dan veriyi çeker (veritabanı, API ya da XER üzerinden), dönüştürür ve bir veri ambarına ya da lakehouse’a yükler. Power BI, P6’ya değil ambara bağlanır.

Yaygın middleware seçenekleri:

• Azure Data Factory — yerel Azure entegrasyonu; zaten Microsoft ekosistemindeyseniz iyi çalışır
• Informatica / Talend — hazır P6 bağlayıcıları olan kurumsal ETL araçları
• Özel Python script’leri — XER için xerparser, REST API için requests gibi kütüphanelerle veriyi bir SQL veritabanına yüklemek
• SSIS (SQL Server Integration Services) — özellikle mevcut SSIS altyapısı olan kurumlarda hâlâ yaygın

Uygulama

Tipik bir hat:

1. Aktiviteleri, ilişkileri, kaynakları ve WBS’i P6’dan çek (gece çalışan iş)
2. Dönüştür: UDF’leri kolonlara aç, kazanılmış değer (EV) metriklerini hesapla, maliyet sistemi verisiyle birleştir
3. Azure SQL ya da Snowflake’te bir star schema’ya yükle
4. Power BI, zamanlanmış yenilemeyle ambara bağlansın

Asıl değer dönüşüm adımında yaratılır. Program metriklerini hesaplayabilir, P6 verisini ERP sistemlerindeki maliyet verisiyle birleştirebilir ve P6’nın kendi başına tutmadığı tarihsel trend tablolarını kurabilirsiniz.

Artıları

• Veri dönüşümü ve kalitesi üzerinde tam kontrol
• P6 verisi başka sistemlerin verisiyle (ERP, doküman yönetimi, risk araçları) birleştirilebilir
• Tarihsel trend hattın içine gömülü gelir
• Power BI sorguları hızlıdır — ambar okuma için optimize edilmiştir
• BI katmanını kaynak sistemden ayırır

Eksileri

• Ciddi kurulum eforu — günler değil, haftalar
• Süregiden bakım yükü (P6 yükseltmelerinden sonra şema değişiklikleri hattı kırabilir)
• Çoğu proje kontrol ekibinde olmayan veri mühendisliği becerileri gerektirir
• Maliyet: middleware lisansı, ambar barındırma, hat izleme

En uygun olduğu durumlar

P6’nın birçok veri kaynağından yalnızca biri olduğu kurumsal analitik platformları, program verisini maliyet, risk ve doküman verisiyle birleştirmesi gereken kurumlar ve sıkı veri yönetişimi gereksinimleri olan programlar.

Karşılaştırma Tablosu

Faktör	XER Export	Doğrudan DB	REST API	Middleware/ETL
Kurulum eforu	Saatler	Günler	Günler	Haftalar
Gereken altyapı	Yok	DB erişimi + Oracle sürücüsü	EPPM + API erişimi	ETL aracı + ambar
Yenileme sıklığı	Manuel	Günlük (zamanlanmış)	Günlük (zamanlanmış)	Günlük (zamanlanmış)
Veri bütünlüğü	Yüksek	Tam	Kısmi	Tam
P6 Cloud ile çalışır mı	Evet	Hayır	Evet	Evet (API üzerinden)
P6 Professional ile çalışır mı	Evet	Hayır	Hayır	Evet (XER üzerinden)
IT katılımı	Yok	Yüksek	Orta	Yüksek
Tarihsel trend	Manuel (XER arşivi)	Sınırlı	Sınırlı	Gömülü
Bakım yükü	Düşük	Orta	Orta	Yüksek

Sık Düşülen Tuzaklar

Hangi yöntemi seçerseniz seçin, P6 verisinin şu huyları sizi bir noktada ısıracak:

Tarih işleme. P6 tarihleri Oracle DATE ya da TIMESTAMP tipinde tutar. Power BI bunları içeri alırken, gateway sunucunuzun saat dilimi ayarına bağlı olarak tarihler bir gün kayabilir. Power BI’daki tarihlerin P6’da gördüklerinizle eşleştiğini her zaman doğrulayın — özellikle Actual Start ve Actual Finish tarihlerinde.

UDF eşleme. P6 user-defined field’ları ayrı bir tabloda, jenerik bir yapıyla tutar (UDF_TYPE_ID, UDF_VALUE). UDF’leri kolon olarak görmek için bu tabloyu pivot etmeniz gerekir. API yönteminde bu, ayrı bir API çağrısı ve bir merge adımı demek. Veritabanı yönteminde Extended Schema önceden pivot edilmiş UDF görünümleri sunar — kullanın.

Kaynak veri yapısı. P6, kaynakları (insan/ekipman) kaynak atamalarından (kaynakların aktivitelere tahsisi) ayrı tutar. Power BI’da neredeyse her zaman atama verisini istersiniz, kaynak verisini değil. Saatler, maliyetler ve tarihler atama tablosunda (TASKRSRC); birim fiyat ve uygunluk bilgisi kaynak tablosunda (RSRC) durur.

Activity ID ile Task ID farkı. P6’nın dahili tanımlayıcısı task_id’dir (sayısal anahtar). Kullanıcının gördüğü kod ise activity_id’dir (“A1020” gibi). Veri modelinize ikisini de koyun — join’ler için task_id, gösterim için activity_id.

WBS hiyerarşisi. P6’nın WBS’i düz bir yapı değil, üst-alt hiyerarşisi olarak tutulur. Power BI üst-alt hiyerarşilerle başa çıkabilir ama her aktivite için tam WBS yolunu kurmak üzere DAX’ta bir PATH fonksiyonuna ihtiyacınız olacak. Topu topu 10 satır DAX ama ilk kez yapan herkes buna takılır.

Hangi Yöntemle Başlamalısınız?

XER export ile başlayın — sonuca bu hafta ihtiyacınız varsa, P6 Professional ile çalışıyorsanız ya da IT’den veritabanı erişimi istemeden önce konsepti kanıtlamak istiyorsanız.

Doğrudan veritabanına gidin — on-premise P6 EPPM’iniz varsa, IT ekibiniz işbirliğine açıksa ve günlük yenilenen üretim dashboard’larına ihtiyacınız varsa.

REST API’yi seçin — P6 Cloud’daysanız, kurumunuz veritabanı erişimi vermiyorsa ya da P6’daki her alana ihtiyaç duymayan hafif bir entegrasyon kuruyorsanız.

Middleware’e yatırım yapın — P6 daha büyük bir analitik girişiminin parçasıysa, program verisini başka sistemlerdeki maliyet ve risk verisiyle birleştirmeniz gerekiyorsa ya da sağlam tarihsel trend istiyorsanız.

Müşterilerimin çoğu Yöntem 1 ile başlıyor, dashboard tasarımını doğruluyor, sonra üretim için Yöntem 2 ya da 3’e geçiyor. XER yaklaşımı için kurduğunuz dashboard mantığı ve DAX ölçüleri doğrudan taşınır — değiştirdiğiniz tek şey veri kaynağıdır. Power BI mimarisinin güzelliği bu; basit başlayıp ölçeklendirmeyi bu yüzden öneriyorum.

Rotayı seçmeden önce varış noktasını görmek isterseniz, rapor ve dashboard kataloğu bu bağlantıların neyi beslediğini gösteriyor — bunları kuran çalışma ise raporlama ve analitik.