Giriş: İş Zekası (BI) En Basit Haliyle Nedir?
Gün içinde birçok karar veriyoruz: “Bu ay satışlar iyi mi?”, “Hangi ürün daha çok kazandırıyor?”, “Reklama harcadığımız para geri dönüyor mu?”, “Stok ne kadar kaldı?”, “Müşteri şikâyetleri artıyor mu?” Bu soruların cevapları genellikle farklı yerlerde dağınık durur: bir kısmı Excel dosyalarında, bir kısmı muhasebe / ERP sisteminde, bir kısmı e-ticaret panelinde, bir kısmı da ekiplerin mesajlaşmalarında…
İş Zekası (BI – Business Intelligence) tam olarak bu dağınıklığı toplamak için vardır. BI’yi en basit haliyle şöyle düşünebilirsiniz:
BI = Veriyi topla → düzenle → tek bir “doğru” hale getir → anlaşılır şekilde göster → karar almayı kolaylaştır.
BI neden “rapor”dan daha fazlasıdır?
Bir rapor, sadece “rakamları gösterir.” BI ise şu üç şeyi birlikte hedefler:
Doğru rakam: “Ciro” herkes için aynı hesaplanır mı?
Doğru zaman: Bugünün raporu gerçekten bugünü mü gösteriyor, yoksa iki gün geriden mi geliyor?
Doğru karar: Rakam kötüleştiğinde ne yapılacağını söyleyebiliyor musunuz?
BI’nin amacı, “güzel grafik” üretmekten çok, karar vermeyi hızlandırmak ve hataları azaltmaktır.
Günlük hayattan örnek
Diyelim ki bir e-ticaret işletmeniz var ve şu üç soruyu cevaplamak istiyorsunuz:
Bu hafta satışlar geçen haftaya göre arttı mı?
Hangi ürünler en çok kâr bırakıyor?
Kargoda gecikme artınca iade oranı yükseliyor mu?
Bu soruların her biri farklı veri gerektirir: siparişler, maliyetler, iade kayıtları, kargo teslim süreleri… BI, bu verileri bir araya getirip aynı dilde konuşturur ve genellikle bir dashboard (gösterge paneli) üzerinden size özet sunar.
BI’ye yeni başlayanlar için temel kavramlar
Veri kaynağı: Verinin geldiği sistem (ERP, CRM, e-ticaret, Excel vb.)
Veri modeli: Verilerin birbiriyle nasıl ilişkili olduğu düzen (ör. ürün–müşteri–sipariş)
KPI: En kritik metrik (ör. net kâr marjı)
Dashboard: KPI’ların ve kırılımların görselleştirildiği tek sayfa özet ekran
Bu yazıda ne öğreneceksiniz?
Bu yazı, BI’yi ilk kez duyan birinin bile adım adım anlayabileceği şekilde şunları açıklıyor:
BI mimarisi hangi parçalardan oluşur (veri toplama, depolama, modelleme, dashboard)
KPI’lar nasıl seçilir ve “tek doğru rakam” nasıl oluşturulur
Dashboard’lar nasıl daha anlaşılır ve hızlı hale getirilir
Self-service BI (kullanıcının kendi raporunu yapması) nasıl yönetilir
Veri kalitesi, güvenlik ve yönetişim BI’nin neden “olmazsa olmaz”ıdır
Kısacası: BI, doğru veriyi doğru kişiye doğru zamanda vererek daha iyi karar aldıran bir sistem kurma işidir.
BI’nin Kapsamı: “Raporlama Aracı” Değil, Karar Altyapısı
İş zekası (Business Intelligence / BI), pratikte çoğu ekipte “rapor / dashboards” ile eş anlamlıymış gibi kullanılır. Oysa doğru tanım, araç + süreç + yönetişim üçlüsünü kapsar:
Aynı kaynak, BI platformlarının tipik olarak analiz (OLAP vb.), bilgi sunumu (rapor/dashboards) ve platform entegrasyonu (metadata yönetimi vb.) kabiliyetleri taşıdığını vurgular.
Sonuç: BI, “görselleştirme” katmanıyla bitmez; asıl değer, doğru tanımlanmış metrikler ve güvenilir veri üretim hattı ile ortaya çıkar.
Modern BI Mimarisi: Uçtan Uca Veri Hattı (Data Pipeline) Resmi
Tipik bir BI mimarisini 6 katmanda düşünebilirsiniz:
Kaynak sistemler: ERP/CRM, e-ticaret, finans, loglar, IoT, pazarlama araçları
Entegrasyon (ETL/ELT): veri çekme, dönüştürme, kalite kontrolleri
Depolama: veri ambarı (DWH), data lake veya lakehouse
Modelleme + semantik katman: “iş terimleriyle konuşan” ölçüler, ilişkiler, sözlük
Sunum: raporlar, dashboard’lar, self-service keşif
Yönetişim ve güvenlik: yetki, veri kataloğu, kalite metrikleri, sürümleme
Bu katmanların her biri “tek seferlik proje” değil; ürün gibi yönetildiğinde BI sürdürülebilir olur.
Veri Ambarı, Data Lake ve Lakehouse: Hangisi BI İçin Neden Önemli?
Veri ambarı (DWH) neyi çözer?
Klasik yaklaşımda veri ambarı, analiz ve raporlama için optimize edilmiş, iş kuralları uygulanmış, tutarlı bir veri katmanı sunar. Veri ambarı literatüründe Bill Inmon’un meşhur tanımı (konu-odaklı, bütünleşik, zaman değişkeni olan, kalıcı veri koleksiyonu) hâlâ kavramsal çıpa olarak kullanılır.
BI açısından kritik fayda: CFO’nun “ciro” dediğiyle satış direktörünün “ciro” dediği aynı olur.
Data lake neyi çözer?
Data lake, yapılandırılmış + yarı yapılandırılmış + yapılandırılmamış veriyi “ham” saklayarak esneklik sağlar. Genellikle “schema-on-read” yaklaşımıyla anılır (şemayı okurken uygula). DWH ise daha çok “schema-on-write” (şemayı yazarken uygula) yaklaşımıyla düşünülür.
BI açısından uyarı: Ham veriyi doğrudan rapora taşımak, “hızlı kazanım” gibi görünse de, kısa sürede metrik kaosu üretir.
Lakehouse neyi çözer?
Lakehouse, data lake’in ölçek/esneklik avantajını, DWH’nin yönetilebilirlik ve analiz kabiliyetleriyle birleştirmeyi hedefleyen mimari kalıptır. Databricks bu yaklaşımı “data lake + data warehouse faydalarını birleştiren” sistem olarak tarif eder.
BI açısından kritik nokta: Lakehouse’ta da BI başarısı, depolamadan çok modelleme + semantik katman + yönetişim kalitesine bağlıdır.
ETL mi ELT mi? BI İçin Doğru Seçim Nasıl Yapılır?
ETL (Extract-Transform-Load) ve ELT (Extract-Load-Transform) farkı özünde dönüşümün nerede yapıldığıdır:
ETL: dönüşüm yüklemeden önce
ELT: dönüşüm yükledikten sonra, genellikle güçlü bulut veri ambarı/lakehouse üzerinde
Bulut analitik ekosisteminde ELT yaklaşımı daha yaygınlaştı; bunun nedenleri arasında ölçeklenebilir işlem gücü ve dönüşümlerin daha “versiyonlanabilir” hale gelmesi var.
Pratik karar kuralı (BI odaklı):
Çok sayıda kaynaktan gelen veriyi standardize edip kuralları “tek yerde” yönetmek istiyorsanız ELT + dönüşüm katmanı (ör. dbt tarzı) güçlüdür.
Regülasyon, veri maskeleme, PII ayrıştırma gibi sebeplerle ham veriyi depoya sokmadan önce ciddi temizlik gerekiyorsa ETL avantajlı olabilir.
Boyutsal Modelleme: BI’nin “Kullanılabilirlik” Motoru
Bir BI sistemi, kullanıcı için şu soruya cevap vermelidir:
“Bu metrik hangi boyutlarda kırılır, filtrelenir ve tutarlı kalır?”
Yıldız şema (star schema) neden bu kadar yaygın?
Yıldız şema, analitik sorguları kolaylaştıran, anlaşılabilir bir çok-boyutlu modeldir. Microsoft’un rehberleri, iyi BI modellerinde yıldız şemanın önemini ve özellikle tarih boyutu gibi boyut tablolarının (dimension) rolünü vurgular.
Fact table vs dimension table (en sade anlatım)
Kimball Group’un tanımıyla:
Fact table: ölçümleri (measure) ve boyutlara bağlanan anahtarları içerir
Dimension table: bağlamı (ürün, müşteri, mağaza, tarih…) taşır
Kimball Group, fact tablonun çoklu foreign key + ölçülerden oluştuğunu, boyut tablolarının ise analiz bağlamını sağladığını net biçimde açıklar.
Conformed dimension ve “tek doğru rakam”
Conformed dimension, farklı süreçlere ait fact tablolarının aynı boyut tanımıyla “drill-across” yapılabilmesini sağlar (ör. Satış ve İade tablolarını aynı “Ürün” boyutuyla birleştirmek). Kimball Group bu kavramı, raporların aynı satırlarda hizalanabilmesi için temel görür.
BI’ye etkisi: “Müşteri sayısı” farklı ekiplerde farklı hesaplanmaz; semantik katmanda tek tanım olur.
Bus matrix: BI yol haritasını görünür kılmak
Kimball yaklaşımında “enterprise bus matrix”, süreçler (satış, stok, sevkiyat…) ile boyutların (tarih, ürün, müşteri…) kesişimini gösteren planlama aracıdır.
KOBİ’ler için pratik kullanım: “Önce hangi süreçleri raporlayacağız?” sorusuna net öncelik verir.
Semantik Katman: İş Terimleriyle Konuşan Veri
Semantik katman, teknik veri yapıları ile iş kullanıcılarının dili arasındaki çeviri katmanıdır. IBM, semantik katmanın metrikleri ve ilişkileri standardize ederek teknik olmayan kullanıcıların karmaşık analizi daha güvenli yapmasına yardım ettiğini vurgular.
Neden kritik?
Aynı “Net Satış” ölçüsünü 12 farklı raporda 12 farklı DAX/SQL ile yazarsanız:
Sonuçlar tutmaz
Bakım maliyeti artar
“Raporlar güven vermiyor” algısı oluşur
Bu yüzden modern BI’de “metric store / semantic layer / semantic model” tartışmaları, aslında tek sözlük ve tek hesaplama ihtiyacının farklı isimlerle karşılanmasıdır.
Not: Microsoft ekosisteminde “dataset” adlandırması “semantic model” olarak yeniden konumlandı.
KPI Tasarımı: BI’nin Gerçek “İş Değeri” Burada Doğar
KPI’lar (Key Performance Indicators), rastgele seçilmiş metrikler değil; hedef + davranış + karar üçlüsüne bağlanan göstergelerdir. KPI tasarımında sık düşülen hatalar:
“Her şeyi ölçelim” yaklaşımı → dashboard mezarlığı
Tanımsız metrik → ekipler arası tartışma
Sahibi olmayan KPI → takip edilmez
Hedef/aksiyon bağı olmayan KPI → “izledik ama ne yapacağız?” sorusu
David Parmenter, KPI geliştirme ve uygulama için adım adım bir metodoloji önerir; özellikle KPI’ların organizasyon hedefleriyle ilişkilendirilmesini ve hayata geçirilmesini merkeze alır.
Pratik KPI şablonu (kopyalanabilir):
KPI adı: (tek anlamlı)
Tanım: (iş terimiyle)
Formül: (net matematik)
Granülerlik: (gün/hafta/ay; müşteri/ürün vb.)
Veri kaynağı: (sistem + tablo)
Güncellenme sıklığı: (D+1, saatlik…)
Sahip: (rol/ekip)
Eşikler: (hedef, alarm, tolerans)
Aksiyon: (eşik aşılınca ne yapılır?)
Dashboard Tasarımı: “Tek Sayfada Hikâye” Kuralı
Microsoft, dashboard’u genellikle tek sayfalık bir “canvas” olarak tanımlar; amaç detay rapor değil, hikâyenin özetini vermektir.
Aynı şekilde Power BI tasarım ipuçları, en önemli bilginin öne çıkması ve arayüzün “temiz/kalabalık olmayan” yapıda olması gerektiğini söyler.
Dashboard “kullanılsın” diye 7 tasarım kuralı
Tek karar sorusu seçin: “Bu paneli açan kişi hangi kararı verecek?”
Önce KPI kartları, sonra kırılımlar: özet → neden → aksiyon
Renk = vurgu, süs değil: Tableau, renk kullanımında “basit tutma” ve vurguyu sınırlı kullanma önerir.
Zamanı standartlaştırın: MTD/QTD/YTD tanımları her yerde aynı olsun
Varsayılan filtreleri bilinçli seçin: “son 30 gün” mü “bu ay” mı?
Aşırı görsel çeşitliliğinden kaçının: her grafik bir gerekçe taşımalı
Performansı tasarımla birlikte yönetin: 20 görsel = 20 sorgu demek olabilir
Bu alanda klasikleşmiş kaynaklardan biri Information Dashboard Design (Stephen Few) olup, dashboard’ların “hızlı algılanabilirlik” hedefiyle tasarlanmasını sistematik ele alır.
Self-Service BI: Hız Kazandırır, ama Kontrolsüzse Borç Üretir
Self-service BI, iş kullanıcılarının onaylı mimari ve araç seti içinde kendi rapor/analizlerini oluşturmasıdır.
Self-service BI için “altın orta”
Merkezi ekip (BI/Veri platformu): semantik katman, sertifikalı veri kümeleri, veri kataloğu, güvenlik
İş ekipleri: keşif raporları, departman panoları, ad-hoc analiz
Ortak sözlük: KPI tanımları, boyut sözlüğü, veri kalite kuralları
Kural: Self-service “modellemeyi” değil, “tüketimi” demokratikleştirirse ölçeklenir.
Güvenlik: BI Raporu da Bir “Veri Yüzeyi”dir
Satır düzeyi güvenlik (RLS)
Power BI bağlamında RLS’nin temel davranışı: tablo satırlarını filtreler; nesne (tablo/kolon/measure) gizleme amacıyla tasarlanmaz. Microsoft’un rehberi bu ayrımı açık şekilde koyar.
Güncel gerçek: BI platformları da CVE alır
BI, genellikle “iç sistem” algısıyla hafife alınır; oysa hem SaaS hem on-prem BI ürünleri düzenli güvenlik güncellemeleri gerektirir. Örnekler:
SAP, Şubat 2026 güvenlik notlarında SAP BusinessObjects BI Platform için DoS türü zafiyetleri listeler.
Tenable araştırması, Google Looker’da kritik etki doğurabilecek zafiyetlerin yamalandığını ve özellikle on-prem kurulumların güncel tutulması gerektiğini vurgular.
BI güvenliği için kontrol listesi
Kimlik/rol tasarımı (en az yetki)
RLS/OLS stratejisi (ürün kabiliyetlerine göre)
Paylaşım ve dışa aktarım politikaları
Yama takvimi (özellikle on-prem raporlama sunucuları)
Loglama ve denetim izleri (audit)
Veri Yönetişimi ve Veri Kalitesi: “Rapor Doğru mu?” Sorusunun Cevabı
Veri yönetişimi (data governance) tanımı
DAMA International bağlamında veri yönetişimi, veri varlıklarının yönetimi üzerinde otorite ve kontrolün (planlama, izleme, yaptırım) uygulanması olarak tarif edilir.
BI açısından yönetişimin çıktıları:
KPI sözlüğü (glossary)
Veri sahibi/steward atamaları
Sertifikalı veri setleri
Değişiklik yönetimi (schema change)
Veri kalitesi standardı: ISO/IEC 25012
International Organization for Standardization, ISO/IEC 25012 standardında veri kalitesini 15 karakteristik altında sınıflandırır.
BI’de en çok can yakan 4 kalite tipi (pratik):
Doğruluk: işlem doğru mu?
Tamlık: eksik kayıt var mı?
Tutarlılık: aynı alan farklı tablolarda farklı mı?
Güncellik: KPI “bugünü” mü gösteriyor, “D+3” mü?
BI Projelerinde Rol ve Süreçler: “Rapor Talebi Kuyruğu”ndan Ürün Yönetimine
Başarılı BI ekipleri, raporu “çıktı” değil “ürün” kabul eder:
Ürün sahibi (PO): KPI önceliği, kullanıcı senaryosu, kabul kriterleri
Veri mühendisi: entegrasyon, dönüşüm, kalite testleri
BI geliştirici/modelleyici: yıldız şema, semantik katman, performans
Analist: iş sorusunu veriyle çevirme, içgörü üretme
Data steward: sözlük, kalite, veri sahipliği
Teslim modeli önerisi (özellikle KOBİ için):
2–3 KPI + tek dashboard ile “çekirdek değer”
Aynı KPI’ların departman kırılımları (boyutlar)
Self-service alanının açılması (sertifikalı veri seti üstünden)
Yönetişim (sözlük + kalite metrikleri + değişiklik yönetimi)
Sık Yapılan BI Hataları ve Hızlı Teşhis
“Excel’den daha güzel Excel” üretmek → KPI’lar karar bağlamından kopuyor
Ham veriyi rapora bağlamak → metrik tutarsızlığı
Boyutsal model yerine “tek büyük tablo” → performans + anlam kaybı
Self-service’i sınırsız bırakmak → “herkesin kendi gerçeği”
Güvenliği en sona bırakmak → paylaşım kazaları, veri sızıntısı riski
Kalite ölçmemek → sorun hissedilir ama kanıtlanamaz
SSS: BI Arama Niyetiyle Birebir Uyumlu Kısa Cevaplar
KOBİ’ler için iş zekası (BI) nasıl kurulur?
Önce 2–3 kritik KPI seçin, yıldız şema + semantik katmanla “tek doğru tanım” üretin, tek dashboard ile yayına alın; sonra kırılımlar ve self-service açın.
ETL mi ELT mi? Bulut veri ambarı için hangisi daha doğru?
Bulutta çoğu senaryoda ELT pratik (ölçek + versiyonlama); ancak PII ayrıştırma veya regülasyon nedeniyle dönüşümün depoya girmeden yapılması gerekiyorsa ETL tercih edilebilir.
Yıldız şema (star schema) ile BI veri modeli nasıl tasarlanır?
İş süreçlerini (satış, iade, stok) fact tablolara ayırın; ürün/müşteri/tarih gibi bağlamları dimension tablolarla kurun; conformed dimension ile drill-across mümkün kılın.
Semantik katman (semantic layer) ne işe yarar?
Metrikleri tek yerden tanımlar, iş terimleriyle sunar, tutarsız hesaplamaları engeller; iş kullanıcılarının güvenle analiz yapmasını kolaylaştırır.
KPI ile metrik arasındaki fark nedir?
Metrik ölçümdür; KPI ise hedef ve aksiyonla ilişkilendirilmiş “kritik” metriktir. KPI’nın sahibi, eşiği ve aksiyonu olmalıdır.
Dashboard tasarımı için en önemli 3 kural nedir?
Tek karar sorusu, sade hiyerarşi (özet→neden→aksiyon), sınırlı vurgu (renk/etiket).
Power BI satır düzeyi güvenlik (RLS) nasıl çalışır?
RLS, modelde satırları filtreler; tablo/kolon/measure gizleme amacıyla tasarlanmaz.
BI raporları neden “farklı sonuç” verir?
Genellikle (1) farklı KPI tanımı, (2) farklı filtre/zaman penceresi, (3) farklı granülerlik, (4) veri kalitesi sorunları nedeniyle. ISO/IEC 25012 gibi kalite çerçeveleri bu sorunları kategorize etmeye yardım eder.
Kaynakça
- Gartner. (n.d.). Analytics and Business Intelligence (ABI). Gartner IT Glossary.
- Gartner. (n.d.). Business intelligence (BI) platforms. Gartner IT Glossary.
- Gartner. (n.d.). Self-service business intelligence. Gartner IT Glossary.
- Kimball Group. (2003, January 1). Fact tables and dimension tables.
- Kimball Group. (n.d.). Conformed dimension.
- Kimball Group. (n.d.). Enterprise data warehouse bus matrix.
- Microsoft. (2024, December 30). Understand star schema and the importance for Power BI. Microsoft Learn.
- Microsoft. (2024, December 30). Row-level security (RLS) guidance in Power BI Desktop. Microsoft Learn.
- Microsoft. (2025, December 1). Introduction to dashboards for Power BI designers. Microsoft Learn.
- Microsoft. (2025, October 20). Tips for designing a great Power BI dashboard. Microsoft Learn.
- Amazon Web Services. (n.d.). The difference between ETL and ELT.
- dbt Labs. (2025, September 23). ETL vs ELT: What’s the difference and why it matters.
- International Organization for Standardization. (2008). ISO/IEC 25012:2008 — Data quality model.
- IBM. (n.d.). What is a semantic layer?
- Databricks. (n.d.). What is a data lakehouse?
- Tenable. (2026). Google Looker vulnerabilities: Patch now (LookOut).
- SAP. (2026, February). SAP Security Patch Day — February 2026 (BusinessObjects BI Platform notes).
- Few, S. (2013). Information Dashboard Design: Displaying Data for At-a-Glance Monitoring (2nd ed.). Analytics Press.
- Parmenter, D. (2019). Key Performance Indicators: Developing, Implementing, and Using Winning KPIs (4th ed.). John Wiley & Sons.
İlave okuma önerileri
- Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). John Wiley & Sons.
- Inmon, W. H. (2005). Building the Data Warehouse (4th ed.). John Wiley & Sons.
- DAMA International. (2017). DAMA-DMBOK: Data Management Body of Knowledge (2nd ed.). Technics Publications.
- Tufte, E. R. (2001). The Visual Display of Quantitative Information (2nd ed.). Graphics Press.
- Ware, C. (2012). Information Visualization: Perception for Design (3rd ed.). Morgan Kaufmann.
- Cairo, A. (2016). The Truthful Art: Data, Charts, and Maps for Communication. New Riders.
🗓️ Yayınlanma Tarihi: 21 Şubat 2026
🔄 Son Güncelleme Tarihi: 21 Şubat 2026
🎯 Kimler için: Bu yazı;
KOBİ sahipleri ve yöneticiler: “Raporlama neden tutmuyor?”, “Tek doğru rakamı nasıl üretiriz?” sorularına çerçeve arayanlar,
Ürün sahipleri / iş birimi liderleri: KPI’ları standardize etmek, performans panolarını (dashboard) aksiyona dönüştürmek isteyenler,
Veri analistleri ve BI geliştiricileri: Modelleme, semantik katman, ölçü (measure) tasarımı ve performans iyileştirme konularında derinleşmek isteyenler,
Veri mühendisleri: ETL/ELT, veri ambarı–data lake–lakehouse mimarileri ve veri kalitesi/yönetişimi süreçlerini BI perspektifinde konumlamak isteyenler,
BT / güvenlik ekipleri: Yetkilendirme, satır-seviyesi güvenlik (RLS), SaaS BI riskleri ve yama yönetimi bağlamını netleştirmek isteyenler içimdir.
İçerik Bilgisi
Invictus Wiki editoryal ekibini temsil eden kolektif bir yazarlık imzasıdır. IW imzasıyla yayımlanan içerikler; çok kaynaklı araştırma, editoryal inceleme ve tarafsızlık ilkeleri doğrultusunda hazırlanır.
