Is Zekasi Kurulumu: Raporlama Istekten Ürüne Nasil Donusur?

BI Mimarisi: Katmanlar ve Bileşenler

Veri, kaynaktan karara kadar bu katmanlardan geçer

İş zekası raporlama sistemi, birbirini besleyen katmanlardan oluşur. Her katmanın kendi sorumluluğu vardır; bir katmanda çıkan sorun, çoğu zaman bütün zinciri aşağı çeker.

1. Veri Kaynak Katmanı (Source Layer)

Verinin doğduğu yer. ERP, CRM, MES, Excel dosyaları, IoT sensörleri, web analitiği; ham veri hep buradan gelir.

• Operasyonel sistemler: ERP, CRM, SCM, HRM
• Dosya kaynakları: Excel, CSV, XML, JSON
• Dış kaynaklar: API’ler, web servisleri, pazar verileri
• IoT ve sensör verileri: Makine verileri, SCADA sistemleri

2. Veri Entegrasyon Katmanı (Integration Layer)

ETL/ELT süreçlerinin yaşadığı katman. Veri çekilir, temizlenir, dönüştürülür ve hedef sisteme yüklenir.

• Extract (Çekme): Kaynak sistemlerden veri okuma
• Transform (Dönüştürme): Temizleme, birleştirme, hesaplama
• Load (Yükleme): Hedef sisteme yazma

3. Veri Depolama Katmanı (Storage Layer)

Dönüştürülmüş verinin saklandığı yer. Data warehouse, data mart ya da data lake olabilir.

• Data Warehouse: Kurumsal, yapılandırılmış veri deposu
• Data Mart: Departman bazlı alt küme (satış, finans, üretim)
• Data Lake: Ham veri deposu (ML ve ileri analitik için)

4. Semantik Katman (Semantic Layer)

Teknik veri yapısını iş diline çevirir. İş kullanıcısı “müşteri” der; sistem arkada “DIM_CUSTOMER” tablosunu anlar.

• İş tanımları: Metrik ve boyut tanımları
• Hesaplamalar: KPI formülleri, türetilmiş metrikler
• İlişkiler: Tablolar arası bağlantılar

5. Sunum Katmanı (Presentation Layer)

Son kullanıcının gördüğü katman. Dashboard, rapor, ad-hoc sorgu araçları burada durur.

• Dashboard: Görsel, interaktif özet panolar
• Raporlar: Standart, zamanlanmış çıktılar
• Ad-hoc analiz: Kullanıcının kendi oluşturduğu sorgular
• Mobil erişim: Tablet ve telefon uyumluluğu

Data Warehouse Tasarımı

Sağlam bir data warehouse olmadan güvenilir raporlama olmaz

Data warehouse (veri ambarı); konu odaklı, entegre, zaman varyantlı ve kalıcı bir veri deposudur ve iş zekası raporlama için optimize edilmiştir. Operasyonel sistemlerin aksine analitik sorgular düşünülerek tasarlanır.

Dimensional Modelleme

Ralph Kimball’ın popülerleştirdiği yaklaşım, veriyi “fact” ve “dimension” tablolarına ayırır.

Fact Tabloları

Ölçülebilir, sayısal iş olaylarını tutar. Genellikle büyük ve dardır: çok satır, az sütun.

• Örnek: Satış fact tablosu – tarih, müşteri, ürün, miktar, tutar
• Granülarite: En alt detay seviyesi (örneğin sipariş kalemi)
• Ölçümler: Toplanabilir metrikler (adet, tutar, süre)

Dimension Tabloları

Fact’leri tanımlayan, filtreleme ve gruplamada kullanılan tablolar. Yapı olarak geniş (çok sütun) ama kısadır (az satır).

• Örnek: Müşteri dimension – müşteri ID, ad, segment, bölge, sektör
• Hiyerarşi: Üst-alt ilişkiler (örneğin ülke > şehir > ilçe)
• Nitelikler: Filtreleme ve raporlama için kullanılan özellikler

Star Schema vs Snowflake Schema

Star Schema (Yıldız Şeması)

Fact tablosu merkezde, dimension tabloları çevresinde. Basit, anlaşılır ve sorgu performansı yüksek.

• Dimension tabloları normalize değil (denormalized)
• Daha az join, daha hızlı sorgular
• BI raporlamada çoğunlukla tercih edilen yaklaşım

Snowflake Schema (Kar Tanesi Şeması)

Dimension tabloları normalize edilir, alt tablolara bölünür. Depolama açısından ekonomik ama sorgular karmaşıklaşır.

• Daha fazla tablo, daha fazla join
• Depolama alanı tasarrufu
• Yönetimi daha zor

Slowly Changing Dimensions (SCD)

Dimension verileri zamanla değişir; müşterinin adresi, ürünün fiyatı sabit kalmaz. Bu değişiklikleri nasıl sakladığınız kritik bir karardır.

SCD Tip 1: Üzerine Yaz

Eski değer silinir, yerine yenisi yazılır. Geçmiş kaybolur. Basittir ama tarihsel analiz imkânı bırakmaz.

SCD Tip 2: Yeni Satır Ekle

Her değişiklikte yeni bir satır açılır. Geçerlilik tarihleriyle geçmişi izleyebilirsiniz. En yaygın kullanılan yöntem budur.

SCD Tip 3: Yeni Sütun Ekle

Önceki ve mevcut değer ayrı sütunlarda tutulur. Geçmiş sınırlıdır; genellikle sadece bir önceki değeri görebilirsiniz.

ETL/ELT Süreçleri

Ham veriyi işe yarar bilgiye çeviren yer burasıdır

ETL (Extract-Transform-Load), iş zekası raporlama sistemlerinin kalbidir. Kaynaklardaki dağınık ve kirli veriyi alır; temiz, tutarlı ve analiz edilebilir hale getirir.

Extract (Çekme) Aşaması

Veri kaynaklarından okuma işlemi. Buradaki temel kaygı, kaynak sisteme mümkün olan en az yükü bindirmektir.

Çekme Yöntemleri

• Full extraction: Tüm veri çekilir. Basittir ama yavaştır ve kaynağı yorar
• Incremental extraction: Yalnızca değişen veri çekilir. Verimlidir ama bir izleme mekanizması ister
• CDC (Change Data Capture): Değişiklikleri veritabanı logları üzerinden yakalar. Gerçek zamanlıdır, etkisi minimumdur

Dikkat Edilecekler

• Kaynak sistemi yormamak için çekimleri mesai dışına almak
• Network bant genişliği ve gecikme süresi
• Kaynak sistem kesintilerine karşı hata yönetimi

Transform (Dönüştürme) Aşaması

Ham verinin iş kuralları üzerinden işlendiği aşama. Süreç boyunca en karmaşık ve en çok zaman yiyen kısım genellikle burasıdır.

Yaygın Dönüşüm İşlemleri

• Temizleme: Eksik değer yönetimi, format düzeltme, tekrar eden kayıtları ayıklama
• Standardizasyon: Birim dönüşümleri, kod eşleştirme, isimlendirme tutarlılığı
• Birleştirme: Farklı kaynaklardan gelen verinin eşleştirilmesi
• Türetme: Hesaplanan alanlar, kategorilendirme, gruplama
• Filtreleme: Gereksiz verinin ayıklanması
• Aggregation: Özet tabloların oluşturulması

Veri Kalitesi Kontrolleri

• Completeness: Eksik değer oranı
• Accuracy: Doğruluk kontrolü (referans verilerle karşılaştırma)
• Consistency: Farklı kaynaklar arasında tutarlılık
• Timeliness: Veri güncelliği

Load (Yükleme) Aşaması

Dönüştürülmüş verinin hedef sisteme yazılması.

Yükleme Stratejileri

• Full load: Hedef tablo baştan yenilenir. Basittir ama yavaştır
• Incremental load: Yalnızca yeni ya da değişen kayıtlar eklenir. Verimli
• Upsert (Merge): Varsa güncelle, yoksa ekle. En esnek olanı

ETL vs ELT

Snowflake, BigQuery, Redshift gibi bulut veri ambarları yaygınlaşınca ELT (Extract-Load-Transform) hızla popülerleşti.

Dashboard Geliştirme Yaşam Döngüsü

İyi bir dashboard tesadüf değildir; belli bir sürecin sonucudur

Bir iş zekası raporlama talebinin dashboard’a dönüşmesi belli bir yaşam döngüsü ister. Ad-hoc taleplerle savrulmak yerine oturmuş bir süreç işletmek, hem kaliteyi hem sürekliliği getirir.

1. Gereksinim Toplama

İş kullanıcısının gerçekte neye ihtiyaç duyduğunu anlamak. “Bana bir dashboard yap” cümlesi, arkasında ciddi bir sorgulama gerektirir.

Sorulması Gereken Sorular

• Bu dashboard ile hangi kararları alacaksınız?
• Kime raporlayacaksınız, kim kullanacak?
• Ne sıklıkta bakmanız gerekiyor?
• Hangi metrikleri takip etmek istiyorsunuz?
• Şu an bu bilgiye nasıl ulaşıyorsunuz?
• Başarıyı nasıl ölçeceksiniz?

Çıktı

Gereksinim dokümanı: İş soruları, metrik tanımları, kullanıcı profilleri, veri kaynakları ve güncelleme sıklığı.

2. Veri Keşfi ve Profilleme

İstenen metriklerin hesaplanabilmesi için gereken verinin gerçekten var olup olmadığını ve kalitesini doğrulamak.

Yapılacaklar

• Veri kaynaklarının tespiti
• Veri kalitesi analizi (eksiklik, tutarsızlık, format sorunları)
• İş kuralları ve hesaplama mantığının doğrulanması
• Veri hacmi ve performans beklentisi

Kritik Soru

“İstenen metrik gerçekten hesaplanabilir mi?” Kimi zaman kullanıcının istediği veri sistemlerde yoktur ya da hesaplama mantığı belirsizdir. Bu aşamayı atlarsanız, beklenti yönetimi ilerleyen haftalarda başınızı ağrıtır.

3. Veri Modelleme

Dashboard’u besleyecek veri yapısının tasarımı. Data warehouse’da hangi tablolar, hangi ilişkiler olacak?

Adımlar

• Fact ve dimension tablolarının belirlenmesi
• Granülarite kararı (en alt detay seviyesi)
• Hesaplanan metrik tanımları
• Filtreleme ve dilimleme boyutları

4. ETL Geliştirme

Kaynak sistemlerden data warehouse’a giden veri akışının kurulması.

Adımlar

• Kaynak bağlantılarının kurulması
• Dönüşüm kurallarının kodlanması
• Veri kalitesi kontrolleri
• Zamanlama ve orkestrasyon
• Hata yönetimi ve log mekanizması

5. Dashboard Tasarımı ve Geliştirme

Görsel arayüzün oluşturulması. Burada kullanıcı deneyimi ve bilgi mimarisi ön planda olmalı.

Tasarım İlkeleri

• Görsel hiyerarşi: Önemli metrikler önde
• Bağlam: Hedef, trend, karşılaştırma
• İnteraktivite: Filtre, drill-down, hover detay
• Sadelik: Gereksiz görsel kirlilik yok
• Tutarlılık: Renk kodlama, terminoloji

6. Test ve Doğrulama

Dashboard’un doğru, güvenilir ve yeterince hızlı olduğunu doğrulamak.

Test Türleri

• Veri doğruluğu: Dashboard rakamları kaynak sistemle uyumlu mu?
• Hesaplama doğruluğu: Metrikler doğru hesaplanıyor mu?
• Performans: Yükleme süresi kabul edilebilir mi?
• Kullanılabilirlik: İş kullanıcıları rahatça kullanabiliyor mu?

7. Devreye Alma ve Eğitim

Dashboard’un canlı ortama taşınması ve kullanıcıların eğitilmesi.

Eğitim İçeriği

• Dashboard’un amacı ve kapsamı
• Metrik tanımları ve hesaplama mantığı
• Filtreleme ve navigasyon
• Veri güncelleme zamanları
• Destek ve geri bildirim kanalları

8. İzleme ve İyileştirme

Canlıya alınan dashboard’un sürekli iyileştirilmesi.

İzlenmesi Gerekenler

• Kullanım metrikleri (kim, ne sıklıkla, hangi bölümler)
• Performans trendi
• Kullanıcı geri bildirimleri
• Veri kalitesi sorunları

Self-Service BI Yaklaşımı

Self-service BI, kullanıcıyı veriyle doğrudan buluşturur

Self-service BI, iş kullanıcılarının IT’ye ihtiyaç duymadan kendi raporlarını ve analizlerini üretmesine imkân verir. Doğru kurgulandığında IT’nin üzerindeki yükü hafifletir; yanlış kurgulandığında ortalığı veri kaosuna çevirir.

Self-Service BI’ın Vaat Ettiği

• Hız: IT kuyruğunu beklemeden, anında rapor
• Esneklik: Kullanıcı istediğini, istediği anda analiz eder
• İş-IT işbirliği: IT veriyi hazırlar, iş kullanıcısı tüketir
• Yenilik: İş kullanıcıları yeni içgörüler yakalar

Self-Service BI’ın Riskleri

• Veri tutarsızlığı: Herkes metriği kendince hesaplar, “tek doğru kaynak” ortadan kalkar
• Kalite sorunları: Yetersiz eğitim yüzünden hatalı analizler
• Güvenlik riskleri: Hassas veriye yetkisiz erişim
• Performans sorunları: Kontrolsüz sorgular sistemi yorar

Başarılı Self-Service BI İçin Gereklilikler

1. Güvenilir Veri Modeli (Certified Data Sets)

IT’nin onayladığı, dokümante edilmiş veri setleri. Kullanıcılar bu “altın kaynakları” kullanır, ham tablolara doğrudan dokunmaz.

2. Veri Okuryazarlığı Eğitimi

Temel veri analizi, istatistik ve görselleştirme becerileri. Bu zemin olmadan self-service, hızla yanlış sonuç üretmeye başlar.

3. Yönetişim Kuralları

• Kim hangi veriye erişebilir?
• Hangi metrikler “resmi” sayılır?
• Kullanıcının oluşturduğu içerik nasıl paylaşılır?
• Versiyon kontrolü ve değişiklik izleme

4. IT ve İş İşbirliği Modeli

IT, veri altyapısını ve “certified” veri setlerini sağlar; iş kullanıcısı bu zemin üzerinde analiz yapar. İki taraf arasında rol ve sorumluluk dağılımı net olmalıdır.

Self-Service Olgunluk Seviyeleri

Çoğu organizasyonda Seviye 1-2 fazlasıyla yeterlidir. Seviye 3-4 ise ancak belli bir veri olgunluğu ve eğitim yatırımıyla anlam kazanır.

Sahadan Örnek: BI Kurulum Projesi

BI Projelerinde En Sık Yapılan 7 Hata

1. Veri Kalitesini Göz Ardı Etmek

“Garbage in, garbage out.” BI sistemi kurulduktan sonra veri kalitesi sorunları su yüzüne çıkar ve sisteme olan güven bir anda erir. Veri kalitesi analizini ve temizlik planını ETL’den önce yapmak gerekir.

2. İş Gereksinimlerini Atlamak

Teknoloji odaklı klasik hata: “Aracı alalım, sonra ne yaparız bakarız.” İş soruları tanımlanmadan yapılan dashboard’u kimse kullanmaz. Önce “hangi kararları destekliyoruz?” sorusuna cevap vermek lazım.

3. Her Şeyi Birden Yapmaya Çalışmak

“Big bang” yaklaşımı: bütün departmanlar, bütün raporlar, tek seferde. Sonu kapsam şişmesi, gecikme ve çoğu zaman başarısızlık. İteratif ilerlemek, pilotla başlamak çok daha emniyetli.

4. Performansı İhmal Etmek

Açılması 30 saniye süren dashboard’u kimse kullanmaz. Performans, benimsenmeyi belirleyen en güçlü etkendir. Veri modeli optimizasyonu, indexleme ve aggregation tabloları burada kritik.

5. Eğitimi Atlamak

“Dashboard hazır, nasılsa herkes kullanır” varsayımı. Eğitim verilmezse kullanıcılar eski alışkanlıklarına, yani Excel’e geri kaçar. Lansman öncesi ve sonrası eğitim planı şart.

6. Yönetişim Tanımlamamak

Veri tanımları belirsiz (“gelir” her departmanda başka türlü hesaplanıyor), erişim yetkileri dağınık, güncelleme sorumluluğu ortada yok. Bir veri yönetişimi çerçevesi kurmak gerekir.

7. Sürekli İyileştirmeyi Unutmak

BI projesini “bitti” sanmak. İş ihtiyaçları değişir, yeni sorular gelir. Dashboard’lar canlı bir organizma gibi evrilmeli; bunun için periyodik inceleme ve geri bildirim döngüsü kurulmalı.

BI projelerinde başarısızlık oranı %70’i aşıyor; bu hatalar tam da nedeni

BI Sistemi Başarı Metrikleri

BI sisteminizin ne kadar işe yaradığını görmek için aşağıdaki metrikleri kullanabilirsiniz (değerler temsilidir):

Bu metrikler, BI yatırımınızın geri dönüşünü ölçmenizi sağlar. Aylık ya da çeyreklik izlemek yeterli olur.

BI Kurulum Kontrol Listesi

Sıkça Sorulan Sorular (SSS)