0 212 951 05 08   bilgi@ofisdata.com

Yazılarımız

OfisData

DAX İLE ÖLÇÜ KÜLTÜRÜ: TOPLAM, ORAN, YTD VE KARŞILAŞTIRMALAR

Power BI’da raporlar büyüdükçe “aynı metrik ama farklı sayfa” problemi kaçınılmaz olur: Bir yerde Toplam Satış doğru görünürken başka bir yerde kırılım değişince tutarsızlaşır; oranlar bazen yüzde, bazen oran; YTD bir sayfada çalışır, diğerinde boş döner. Bu tür sorunlar genellikle DAX bilgisi eksikliğinden değil, ölçü kültürü eksikliğinden kaynaklanır.

Ölçü kültürü; metriklerin tanımı, isimlendirmesi, tekrar kullanılabilirliği, test edilmesi ve performansının yönetilmesi için ortak bir standarttır. İyi kurulduğunda hem analistlerin hem de karar vericilerin “hangi sayı doğru?” tartışmasını azaltır; ekipler arası iş birliğini güçlendirir ve modeli ölçeklenebilir kılar.

Bu yazıda DAX’te en çok kullanılan ölçü desenlerini (toplam, oran, YTD ve dönem karşılaştırmaları) ele alırken, bunları sürdürülebilir hâle getiren pratik ölçü kültürü kurallarını da birlikte kurgulayacağız. Eğer ekip içinde ortak bir yaklaşım arıyorsanız, örneklerle ilerleyen bu yapı sizin için sağlam bir başlangıç olacaktır.

Kurumsal raporlama ekranında ölçü kataloğu ve metrik standartlarını gösteren düzen

Ölçü kültürü nedir ve neden kurumsal ölçekte kritiktir?

Power BI modelinde iki temel hesaplama yaklaşımı vardır: hesaplanmış sütunlar ve ölçüler. Kurumsal raporlamada hedef, hesaplamaları olabildiğince ölçülere taşımak ve aynı iş kuralını tekrar tekrar yazmadan her yerde aynı sonucu üretmektir. Ölçü kültürü, bu hedefi operasyonel bir standarda dönüştürür.

Tekil gerçek kaynağı: aynı metrik, her bağlamda aynı sonuç

Bir metrik “Satış” ise; ürün, bölge, kanal veya zaman kırılımı değiştiğinde de tutarlı olmalıdır. Bu tutarlılık, DAX’in filtre bağlamını doğru yönetmekle başlar. CALCULATE, filter context ve row context kavramları doğru anlaşılmadan kurulan ölçüler genellikle “bazı sayfalarda doğru, bazılarında sürpriz” üretir.

Yönetilebilirlik: ölçülerin yaşam döngüsü

Kurumsal bir modelde ölçü sayısı yüzleri bulabilir. Burada kritik olan, ölçülerin isimlendirme, açıklama ve gruplama standartlarıyla yönetilmesidir. Ölçü kültürü; sürümleme, değişiklik etkisi analizi ve kullanıcı güveni için zemin hazırlar.

Performans: doğru sonuç kadar hızlı sonuç

Yanlış yazılmış bir oran ölçüsü küçük bir veri setinde sorun çıkarmayabilir. Ancak üretimde büyük modellerde gereksiz iterator kullanımı, yanlış tabloda hesaplama veya verimsiz filtre manipülasyonu, rapor deneyimini ciddi biçimde bozar. Ölçü kültürü, performans prensiplerini de standardın bir parçası yapar.

Farklı sayfalarda aynı metriğin tutarlı görünmesini sağlayan filtre bağlamı yaklaşımı

Toplam ölçüleri: temel metrikler için sağlam bir taban oluşturma

İyi bir ölçü kültürü, “temel ölçüler” ile başlar. Temel ölçüler genellikle veri modelindeki ölçülebilir büyüklüklerin (satış tutarı, maliyet, adet, süre) toplamsal hâlidir. Bu ölçüler, diğer tüm türev ölçülerin güvenilir temelini oluşturur.

En yalın toplam ölçüsü: basit, okunur, tekrar kullanılabilir

Toplam ölçülerde hedef; karmaşık iş kuralı eklemeden, mümkün olan en net biçimde gerçeği ifade etmektir. Örneğin satış tutarı için en yalın ölçü:

Toplam Satış = SUM ( 'F_Sales'[SalesAmount] )

Bu ölçüyü çoğaltmak yerine, diğer ölçülerin bu temeli kullanmasını sağlayın. Böylece bir gün satış tutarı alanı değişirse, tek noktadan güncelleme yapılır.

Netlik için isimlendirme ve birim standardı

Toplam ölçülerde isimlendirme, raporu okuyan herkesin aynı şeyi anlaması için kritiktir. Örneğin para birimi belirsizse metrik güveni düşer. Bazı ekipler “Toplam Satış (₺)” gibi birim ekler; bazıları da formatlamayı model seviyesinde yönetip isimleri sade tutar. Hangi yaklaşım seçilirse seçilsin, tutarlılık şarttır.

Temel ölçülerden türev üretme prensibi

Brüt Kâr gibi bir metrik üretirken, doğrudan sütunlardan hesaplamak yerine temel ölçüleri kullanmak daha yönetilebilir bir tasarımdır. Örnek:

Toplam Maliyet = SUM ( 'F_Sales'[CostAmount] )
Brüt Kâr = [Toplam Satış] - [Toplam Maliyet]

Bu yaklaşım; tekrar yazımı azaltır, ölçülerin testini kolaylaştırır ve performans optimizasyonunu tekil noktalarda yapmayı mümkün kılar.

Ölçü hiyerarşisiyle temel metriklerden türetilen kâr ve marj yapısı şeması

Oran ölçüleri: DIVIDE, payda güvenliği ve doğru bağlam

Kurumsal raporlarda en çok hata üreten alanlardan biri oranlardır. Çünkü oran ölçülerinde hem pay hem payda bağlamı önemlidir; ayrıca sıfıra bölme, boş değerler ve filtre etkileşimleri doğru ele alınmalıdır. Sağlam bir ölçü kültürü, oranları “güvenli şablonlarla” üretir.

DIVIDE ile güvenli oran: sıfır ve boş durumlarını standardize etme

Oranlarda DIVIDE kullanımı bir standart olmalıdır. Bu fonksiyon, paydanın sıfır veya boş olduğu durumları kontrollü yönetir.

Brüt Kâr Marjı = 
DIVIDE ( [Brüt Kâr], [Toplam Satış], BLANK() )

Üçüncü parametre, hata yerine ne döndürüleceğini belirler. Kurumsal raporlarda çoğu zaman BLANK tercih edilir; çünkü görselde “0” gibi yanıltıcı bir değer yerine boş gösterim daha doğru yorum sağlar.

Oran formatı: yüzde mi, oran mı?

Aynı metrik bazen “0,23” bazen “%23” olarak raporlanırsa, kullanıcıların güveni sarsılır. Bu nedenle ölçü kültüründe oranların formatı net olmalıdır. Model formatlama ayarlarıyla yüzde gösterimi standardize edin; ölçü içinde gereksiz çarpma işlemlerini (x100) yaygınlaştırmayın.

Doğru payda: bağlamı bilinçli tasarlama

“Kategori payı” gibi metriklerde payda, görselin filtre bağlamına göre değişebilir. Bu, bazen istenen davranıştır; bazen de paydanın “toplam pazar” gibi sabit bir düzeyde kalması gerekir. Ölçü kültürü, bu tür oranları ikiye ayırır:

  • Bağlama duyarlı oranlar: Payda, mevcut filtrelerle değişir.
  • Bağlamdan bağımsız oranlar: Payda belirli filtreleri yok sayar (ör. tüm kategoriler).

Bağlamdan bağımsız oran örneği için, kategori filtresini kaldırarak toplamı sabitleyebilirsiniz:

Kategori Payı = 
VAR Pay = [Toplam Satış]
VAR Toplam = CALCULATE ( [Toplam Satış], ALL ( 'D_Product'[Category] ) )
RETURN DIVIDE ( Pay, Toplam, BLANK() )

Burada önemli olan, hangi alanın ALL ile kaldırıldığıdır. Yanlış tablo/kolon seçimi, raporun iş mantığını bozar. Bu yüzden oran ölçülerini “tanımıyla” birlikte kataloglamak iyi bir pratiktir.


YTD ölçüleri: zaman zekâsını sağlam bir tarih tablosuyla kurma

YTD (Year-to-Date) ölçüleri, dönem içindeki birikimli performansı okumak için vazgeçilmezdir. Ancak YTD’nin güvenilir çalışması için bir ön koşul vardır: modelde iyi tanımlanmış bir tarih tablosu bulunmalı ve ilişki doğru kurulmalıdır. Ölçü kültürü, “tarih tablosu standardı” olmadan zaman zekâsına geçmez.

Tarih tablosu standardı: tek tarih, tek mantık

Tarih tablosu; kesintisiz günleri içermeli, yıl/çeyrek/ay gibi sütunlar barındırmalı ve Power BI’da “Mark as date table” olarak işaretlenmelidir. Ayrıca fact tablolardaki tarih alanları bu tabloya ilişkilendirilmelidir. Aksi hâlde DAX time intelligence fonksiyonları beklenmedik sonuçlar üretebilir.

DATESYTD ile birikimli ölçü

Temel satış ölçünüz hazırsa, YTD üretimi oldukça okunur bir desenle yapılır:

Toplam Satış YTD =
CALCULATE (
  [Toplam Satış],
  DATESYTD ( 'D_Date'[Date] )
)

Bu ölçü, seçili tarihe kadar olan yıl içi birikimi verir. Raporlama için kritik olan nokta, “seçili tarih” kavramının görsel ve slicer’larla nasıl belirlendiğidir. Ölçü kültürü, YTD’nin her raporda benzer slicer tasarımlarıyla kullanılmasını önerir.

Mali yıl YTD ve farklı takvimler

Birçok kurum mali yılı takvim yılından farklı yönetir. Bu durumda DATESYTD fonksiyonunun yıl bitiş parametresiyle mali yıl kurgulanır. Örneğin mali yılın 30 Haziran’da bittiği senaryoda yaklaşım değişir. Bu tür farklı takvimleri “modelin standardı” olarak belirleyin; departman bazında farklı YTD tanımları üretmek ölçü güvenini düşürür.

Tarih tablosu ve YTD hesaplarını besleyen takvim hiyerarşisi düzeni ve dilimleyici tasarımı

Dönem karşılaştırmaları: geçen yıl, önceki dönem ve fark analizi

Karar vericiler sadece “bu ay ne oldu?” diye sormaz; asıl soru “geçen yıla göre ne değişti?” olur. Bu yüzden dönem karşılaştırmaları, ölçü kültürünün olmazsa olmazıdır. Burada hedef; hem mutlak farkı hem de yüzde değişimi tutarlı biçimde üretmek ve tüm raporlarda aynı şekilde sunmaktır.

SAMEPERIODLASTYEAR ile geçen yıl karşılaştırması

Geçen yıl ölçüsü genellikle temel metrik üzerinden türetilir:

Toplam Satış LY =
CALCULATE (
  [Toplam Satış],
  SAMEPERIODLASTYEAR ( 'D_Date'[Date] )
)

Bu yaklaşım, seçili tarih aralığının bir yıl öncesini baz alır. Eğer tarihler kesintiliyse veya tarih tablosu doğru değilse, ölçü boş dönebilir. Ölçü kültürü, karşılaştırma ölçülerini devreye almadan önce tarih modelini doğrulamayı şart koşar.

Fark ve yüzde değişim: karar odaklı iki tamamlayıcı ölçü

Tek bir “değişim” ölçüsü yetmez. Kurumsal kararlar genellikle hem fark (₺) hem de değişim oranı (%) ile alınır:

Satış Farkı (₺) = [Toplam Satış] - [Toplam Satış LY]

Satış Değişimi (%) =
DIVIDE ( [Toplam Satış] - [Toplam Satış LY], [Toplam Satış LY], BLANK() )

Burada yine DIVIDE kullanımı, düşük bazlı dönemlerde sıfır/boş yönetimi için kritiktir. Ayrıca yüzde değişim ölçüsünü “model formatı” olarak yüzdeye sabitlemek, raporlar arası tutarlılığı artırır.

Önceki dönem: DATEADD ile esnek karşılaştırma

Geçen yıl dışında “bir önceki ay” veya “bir önceki çeyrek” gibi karşılaştırmalar için DATEADD iyi bir desendir. Örneğin bir önceki ay:

Toplam Satış PM =
CALCULATE (
  [Toplam Satış],
  DATEADD ( 'D_Date'[Date], -1, MONTH )
)

Ölçü kültüründe bu tür ölçülerin adlandırılması (LY, PM, PQ gibi) ekip içinde ortak bir sözlükle tanımlanmalıdır. Aksi hâlde aynı kavram farklı raporlarda farklı kısaltmalarla çoğalır.


Filtre bağlamı yönetimi: CALCULATE, ALL, KEEPFILTERS ve niyetin netliği

DAX’te doğru ölçü yazmanın kalbi, filtre bağlamını bilinçli yönetmektir. Ölçü kültürü, “ne yapıyoruz?” sorusunu her ölçüde görünür kılmayı hedefler. Çünkü CALCULATE ile yapılan küçük bir filtre manipülasyonu, rapor mantığını tamamen değiştirebilir.

ALL ile bağlamı sıfırlama: neyi kaldırdığını açıkça belirt

ALL kullanımı güçlüdür ama kolay suistimal edilir. “Toplam” üretmek adına yanlışlıkla çok geniş bir bağlamı kaldırırsanız, kullanıcı bir daha sayılara güvenmez. Bu nedenle ALL, mümkün olduğunca hedefli uygulanmalıdır: tablo yerine kolon seviyesinde kullanmak genellikle daha güvenlidir.

KEEPFILTERS: ek filtre mi, filtreyi ezmek mi?

CALCULATE içinde filtre verdiğinizde, bazı durumlarda mevcut filtrelerin üzerine yazarsınız. KEEPFILTERS, “mevcut filtreyi daralt” niyetini netleştirir. Ölçü kültürü; kritik raporlama ölçülerinde bu niyeti açık eden desenleri tercih eder.

İş kuralını açıklayan ölçüler: kodun kendisi doküman olsun

Okunabilirlik, sadece estetik değildir; sürdürülebilirliktir. VAR kullanımı, ölçüyü bir “mini tasarım belgesi” gibi okunur yapar. Örneğin oran ölçülerinde Pay/Toplam gibi isimler, iş mantığını kod üzerinden anlatır. Bu yaklaşım, ekip değişse bile ölçünün yaşayabilmesini sağlar.


Ölçü kataloğu ve standartlar: isimlendirme, klasörleme, açıklama

Teknik olarak doğru ölçüler yazsanız bile, ölçülerin keşfedilebilirliği zayıfsa ekip verimliliği düşer. Ölçü kültürü; ölçüleri bir “ürün” gibi ele alır: isimleri, açıklamaları, grupları ve kullanım amacı net olmalıdır.

Adlandırma standardı: iş diline yakın, kısa, tutarlı

İyi bir kural: Ölçü adı, raporu okuyan kişinin iş dilinde kullandığı ifadeye yakın olmalı. “SalesAmountSum” gibi teknik isimler yerine “Toplam Satış” gibi iş odaklı isimler tercih edilir. Kısaltmalar (LY, YTD) ise ekip sözlüğünde tanımlanmış olmalıdır.

Display folder yapısı: tüketim odaklı organizasyon

Ölçüleri “Finans”, “Satış”, “Operasyon” gibi tüketici odaklı klasörlerde toplayın. Bir de “Temel Ölçüler” (Base Measures) gibi bir katman oluşturup, türev ölçülerin buradan üretildiğini netleştirin. Bu yaklaşım, yeni gelen bir analistin modeli öğrenme süresini ciddi biçimde kısaltır.

Açıklama alanı: ölçünün tanımı ve varsayımları

Ölçünün açıklamasında şu bilgiler yer alabilir: iş tanımı, pay/payda kurgusu, kullanılan filtre manipülasyonları ve beklenen format. Özellikle “ALL ile hangi bağlamın kaldırıldığı” gibi kritik varsayımlar açıklamaya yazıldığında, yanlış kullanım riski azalır.

Bu standartları ekip içinde hızla yaymak için pratik bir yol, ölçü kültürünü kısa bir rehber hâline getirip yeni projelerde “varsayılan yaklaşım” olarak uygulamaktır. Uygulamalı ilerlemek isteyen ekipler için Power BI eğitimi programlarında ölçü tasarımı ve DAX desenleri birlikte ele alınır.


Test ve bakım: ölçülerde güven, sürümleme ve regresyon kontrolü

Kurumsal ölçü kültürü “bir kere yaz ve unut” değildir. Veri kaynakları değişir, iş kuralları güncellenir, yeni segmentler eklenir. Bu değişimlerde raporların bozulmaması için ölçülerin test edilebilir olması gerekir.

Kontrol sayfaları: metrik sağlığı için küçük panolar

Model içinde, temel ölçüler için bir “kontrol sayfası” oluşturmak iyi bir pratiktir. Burada Toplam Satış, Toplam Maliyet, Brüt Kâr, Marj, YTD ve LY gibi çekirdek ölçüler aynı filtre setleriyle izlenir. Bir değişiklik sonrası beklenmedik sıçramalar, hızlıca fark edilir.

Regresyon yaklaşımı: küçük örneklerle doğrulama

Ölçüleri doğrulamak için belirli müşteri/ürün/tarih kombinasyonlarını “örnek vaka” olarak seçin. Bu vakalarda beklenen sonuçları dokümante edin ve değişiklik sonrası yeniden kontrol edin. Bu yaklaşım, BI ekiplerinde yazılım geliştirmedeki regresyon testine benzer bir güven sağlar.

Değişiklik yönetimi: ölçü kırılmalarını görünür kılma

Bir ölçünün tanımı değiştiğinde, rapor tüketicilerine neyin değiştiği anlatılmalıdır. “Satış Marjı” ölçüsünde payda tanımı değiştiyse, karar süreçleri de etkilenir. Ölçü kültürü; değişiklik kayıtlarını, ölçü açıklamalarında veya ekip içi dokümantasyonda görünür tutar.


Ölçü kültürü için pratik bir kontrol listesi

Bu yazının özü, DAX desenlerini tek tek ezberlemek değil; aynı desenleri ekip içinde standartlaştırıp sürdürülebilir hâle getirmektir. Aşağıdaki kontrol listesi, yeni bir model kurarken veya mevcut bir modeli toparlarken hızlı bir rehber olabilir.

  • Temel ölçüler ayrı bir katmanda mı ve tüm türevler onları mı kullanıyor?
  • Oran ölçüleri DIVIDE ile mi yazıldı, sıfır/boş stratejisi net mi?
  • Zaman zekâsı için tarih tablosu eksiksiz mi ve ilişkiler doğru mu?
  • LY/YTD/PM gibi kısaltmalar ekip sözlüğünde tanımlı mı ve tutarlı mı?
  • Ölçüler display folder ve açıklamalarla keşfedilebilir mi?
  • Performans için gereksiz karmaşıklıklar (aşırı iterator, geniş ALL) azaltıldı mı?
  • Kontrol sayfası ve örnek vakalarla ölçüler doğrulanıyor mu?

Ölçü kültürü olgunlaştıkça, ekipler “rapor geliştirme” yerine “işi anlayıp hızla karar destek” üretmeye odaklanır. Bu da Power BI yatırımlarının gerçek değerini ortaya çıkarır: doğru metrik, doğru bağlam, doğru zamanda.

 OFİS DATA