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

BI Mimarisi: Katmanlar ve Bileşenler

Modern BI mimarisi, veriyi kaynaktan karara taşır

Is zekası raporlama sistemi, birbirini besleyen katmanlardan oluşur. Her katmanin ayrı bir sorumluluğu vardır ve bir katmandaki sorun, tüm sistemi etkiler.

1. Veri Kaynak Katmanı (Source Layer)

Verinin dogdugu yer. ERP, CRM, MES, Excel dosyaları, IoT senstorleri, web analitikileri gibi sistemler bu katmanda yer alır.

• 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. Veriler ç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 veya data lake olabilir.

• Data Warehouse: Kurumsal, yapılandirilmis 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ısini is diline çevirir. Is kullanıcıları “müşteri” der, sistem “DIM_CUSTOMER” tablosunu anlar.

• Is tanimlarileri: Metrik ve boyut tanimleri
• Hesaplamalar: KPI formulleri, türetilmiş metrikler
• İlişkiler: Tablolar arası bağlantılar

5. Sunum Katmanı (Presentation Layer)

Son kullanıcının etkileştigi katman. Dashboard, rapor, ad-hoc sorgu aracları.

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

Data Warehouse Tasarımi

Data warehouse, is zekası raporlamanın temelidir

Data warehouse (veri ambarı), is zekası raporlama için optimize edilmiş, konu odaklı, entegre, zaman varyantlı ve kalıcı veri deposudur. Operasyonel sistemlerden farklı olarak analitik sorgular için tasarlanmıştır.

Dimensional Modelleme

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

Fact Tabloları

Ölçülebilir, sayısal is olaylarını içerir. Genellikle büyük, dar (çok satır, az sütun) tablolardir.

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

Dimension Tabloları

Fact’leri tanimilayan, filtreleme ve gruplama için kullanılan tablolar. Geniş (çok sütun), kısa (az satır) yapıdadir.

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

Star Schema vs Snowflake Schema

Star Schema (Yıldız Semesi)

Fact tablosu merkezde, dimension tabloları etrafında. Basit, anlaşılır, sorgu performansı yüksek.

• Dimension tabloları normalize değil (denormalized)
• Daha az join, daha hızlı sorgular
• BI raporlama için tercih edilen yaklaşim

Snowflake Schema (Kar Tanesi Semesi)

Dimension tabloları normalize edilmiş, alt tablolara ayrılmış. Depolama verimli, sorgu karmaşık.

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

Slowly Changing Dimensions (SCD)

Dimension verileri zamanla değişir (müşteri adresi, ürün fiyatı). Bu değişikliklerin nasıl yönetilecegi kritiktir.

SCD Tıp 1: Üzerine Yaz

Eski değer silinir, yeni değer yazılır. Geçmiş kaybolur. Basit ama tarihsel analiz yapılaamaz.

SCD Tıp 2: Yeni Satır Ekle

Her degisiklik için yeni satır eklenir. Geçerlilik tarihleri ile tarihsel takip mümkün. En yaygın yaklaşim.

SCD Tıp 3: Yeni Sütun Ekle

Önceki ve mevcut değer ayrı sutunlarda tutulur. Sınırlı geçmiş (genellikle 1 önceki değer).

ETL/ELT Süreçleri

ETL, ham veriyi analiz edilebilir bilgiye dönüştürur

ETL (Extract-Transform-Load), is zekası raporlama sistemlerinin kalbidir. Kaynak sistemlerdeki daaginik, kirli veriyi temiz, tutarlı, analiz edilebilir hale getirir.

Extract (Çekme) Asaması

Veri kaynaklarından okuma işlemi. Kaynak sisteme minimum yük bindirmek esastir.

Çekme Yöntemleri

• Full extraction: Tüm veri çekilir. Basit ama yavaş ve kaynak yoğun
• Incremental extraction: Sadece değişen veriler çekilir. Verimli ama izleme mekanizmesi gerektirir
• CDC (Change Data Capture): Veritabanı logları üzerinden değişiklikleri yakalar. Gerçek zamanlı, minimum etki

Dikkat Edilecekler

• Kaynak sistem performansını etkilememek için mesai disi zamanlama
• Network bant genişliği ve gecikme süresi
• Kaynak sistem kesintilerine karşı hata yönetimi

Transform (Dönüştürme) Asaması

Ham verinin is kurallarl üzerinden islenme süreci. En karmaşık ve zaman alıcı aşama.

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

• Temizleme: Eksık değer yönetimi, format düzeltme, dublike silme
• Standardizasyon: Birim dönüşümleri, kod eşleştirme, isimlendirme tutarlılığı
• Birleştirme: Farklı kaynaklardan gelen verilerin eslestirilmesi
• Turetme: Hesaplanan alanlar, kategorilendirme, gruplama
• Filtreleme: Gereksiz verilerin ayiklanması
• Aggregation: Özet tabloların oluşturulması

Veri Kalitesi Kontrolleri

• Completeness: Eksık değer oranı
• Accuracy: Dogrluluk kontrolü (referans verilerle karşılaştırma)
• Consistency: Farklı kaynaklardaki tutarlılık
• Timeliness: Veri güncelliigi

Load (Yükleme) Asaması

Dönüştürülmüş verinin hedef sisteme yazilmesi.

Yükleme Stratejileri

• Full load: Hedef tablo tamamen yenilenir. Basit ama yavaş
• Incremental load: Sadece yeni/değişen kayıtlar eklenir. Verimli
• Upsert (Merge): Varsa güncelle, yoksa ekle. En esnek yaklaşim

ETL vs ELT

Modern bulut veri ambarları (Snowflake, BigQuery, Redshift) ile ELT (Extract-Load-Transform) populerlesti.

Dashboard Geliştirme Yaşam Dongusu

Başarıli dashboard, sistematik bir geliştirme sürecinin ürünüdür

Bir is zekası raporlama talebinin dashboard’a donusmesi, sistematik bir yaşam dongusu gerektirir. Ad-hoc talepler yerine yapıya oturmuş bir süreç, kalite ve süreklilik sağlar.

1. Gereksinim Toplama

Is kullanıcılarının gerçek ihtiyaçlarının anlasilmesi. “Bana bir dashboard yap” talebi, derinlemesine sorgulama gerektirir.

Sorulması Gereken Sorular

• Bu dashboard ile hangi kararları alacaksınız?
• Kime raporlayacaksiniz, kim kullanacak?
• Ne sıklıkta bakmanız gerekiyor?
• Hangi metrikleri takip etmek istiyorsunuz?
• Mevcut durumda bu bilgiye nasıl ulaşiyorsunuz?
• Başarı nasıl ölçülecek?

Çıktı

Gereksinim dokumani: Is soruları, metrik tanimleri, kullanıcı profilleri, veri kaynakları, güncelleme sıklığı.

2. Veri Kesfii ve Profilleme

Istenen metriklerin hesaplanabilmesi için gerekli verinin varlığını ve kalitesini doğrulama.

Yapılacaklar

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

Kritik Soru

“Istenen metrik hesaplanabilir mi?” Bazen is kullanıcısının istediği veri sistemlerde mevcut değildir veya hesaplama mantigi belirsizdir. Bu aşama, beklenti yönetimi için kritiktir.

3. Veri Modelleme

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

Adımlar

• Fact ve dimension tablolarının belirlenmesi
• Granularite kararı (en alt detay seviyesi)
• Hesaplanan metrik tanimleri
• Filtreleme ve slicelama boyutları

4. ETL Geliştirme

Kaynak sistemlerden data warehouse’a veri akışının oluşturulması.

Adımlar

• Kaynak bağlantileri kurulum
• Dönüşüm kurallarının kodlanması
• Veri kalitesi kontrolleri
• Zamalama ve orkestrasyon
• Hata yönetimi ve log mekanizmesi

5. Dashboard Tasarımi ve Geliştirme

Görsel arayuzun oluşturulması. Kullanıcı deneyimi ve bilgi mimarisi on planda.

Tasarım Ilkeleri

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

6. Test ve Doğrulama

Dashboard’un doğru, güvenilir ve performanslı olduğunu doğrulama.

Test Türleri

• Veri doğrulugu: Dashboard rakamları kaynak sistemle uyuumlu mu?
• Hesaplama doğrulugu: Metrikler doğru hesaplanli mi?
• Performans: Yükleme süresi kabul edilebilir mi?
• Kullanılabilirlik: Is kullanıcıları kolayca kullanabiliyor mu?

7. Devreye Alma ve Eğitim

Dashboard’un canlı ortama taşınması ve kullanıcıların egitilmesi.

Eğitim İ̇çeriği

• Dashboard’un amacı ve kapsamı
• Metrik tanimleri ve hesaplama mantigi
• Filtreleme ve navigasyon
• Veri güncelleme zamanları
• Destek ve geri bildirim kanalları

8. Izleme ve İ̇yileştirme

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

Izlenmesi 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şimi

Self-service BI, is kullanıcılarını veri ile bulusturur

Self-service BI, is kullanıcılarının IT desteigi olmadan kendi raporlarını ve analizlerini oluşturmasına imkan verir. Doğru uygulandığında IT darbogazini azaltır; yanlis uygulandığında veri kaosu yaratır.

Self-Service BI’in Vaat Ettiği

• Hız: IT kuyrugundan bagsimsiz, anında rapor
• Esneklik: Kullanıcı istedigini, istediginde analiz eder
• Is-IT isabirligi: IT veri hazırlar, is kullanıcı tüketir
• Yenilik: Is kullanıcıları yeni icgourler keşfeder

Self-Service BI’in Riskleri

• Veri tutarsızlığı: Herkes farklı metrik hesaplar, “gerçek tek kaynak” kaybolur
• Kalite sorunları: Eğitim yetersizliği nedeniyle yanlis analizler
• Güvenlik riskleri: Hassas veriye yetkisiz erişim
• Performans sorunları: Kontrolsüz sorgular sistemi yorar

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

1. Güvenilir Veri Modelı (Certified Data Sets)

IT tarafından onaylı, dokümante edilmiş veri setleri. Kullanıcılar bu “altın kaynakları” kullanır, ham tablolara doğrudan erişmez.

2. Veri Okuryazarlığı Eğitimi

Kullanıcıların temel veri analizi, istatistik ve görselleştirme becerileri. Eğitim olmadan self-service, yanlis sonuçlar üretir.

3. Yönetişim Kuralları

• Kim hangi veriye erişebilir?
• Hangi metrikler “resmi” kabul edilir?
• Kullanıcı olustuurdugu içerik nasıl paylaşılir?
• Versiyon kontrolü ve degisiklik izleme

4. IT ve Is Isabirligi Modelı

IT, veri altyapısını ve “certified” veri setlerini sağlar. Is kullanıcıları bu zemin üzerinde analiz yapar. Ikisi arasında net rol ve sorumluluk dağılımı.

Self-Service Olgünlük Seviyeleri

Çoğu organizasyonda Seviye 1-2 yeterlidir. Seviye 3-4 için veri olgunluğu ve eğitim yatirimi gerekir.

Sahadan Örnek: BI Kurulum Projesı

BI Projelerinde En Sik Yapılan 7 Hata

1. Veri Kalitesini Göz Ardı Etmek

“Garbage in, garbage out” ilkesi. BI sistemi kurulduktan sonra veri kalitesi sorunları ortaya çıkar ve güvenilirlik kaybolur. ETL’den önce veri kalitesi analizi yapılmalı, temizlik planı oluşturulmali.

2. Is Gereksinimlerini Atlamak

Teknoloji odaklı yaklaşim: “Araç alalım, sonra ne yapariz bakarız.” Is soruları tanımlanmadan dashboard yapılır, kimse kullanmaz. Önce “hangi kararları destekliyoruz?” sorusu cevaplanmali.

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

“Big bang” yaklaşiimi: Tüm departmanlar, tüm raporlar, tek seferde. Kapsam şişmesi, gecikme, başarısizlik. Iteratif yaklaşim, pilot projelerle başlamak daha güvenli.

4. Performansı Ihmal Etmek

Dashboard acilmesi 30 saniye sürüyorsa kimse kullanmaz. Performans, kullanım adaptasyonunun en büyük belirleyicisi. Veri modelı optimizasyonu, indexleme, aggregation tabloları kritik.

5. Eğitimi Atlamak

“Dashboard yapıldı, herkes kullanır” varsayımı. Eğitim olmadan kullanıcıllar eski aliskanliklara döner, Excel’e geri kaçar. Lansman öncesi ve sonrası eğitim planı şart.

6. Yönetişim Tanımlamamak

Veri tanimleri belirsiz (“gelir” her departmanda farklı hesaplanıyor), erişim yetkileri daginiik, güncelleme sorumluluğu yok. Veri yönetişimi çerçevesi oluşturulmali.

7. Sürekli İyileştirmeyi Unutmak

BI projesı “bitti” diye düşünmek. Is ihtiyaçları değişir, yeni sorular ortaya çıkar. Dashboard’lar canlı organizma gibi evrilmeli. Periyodik inceleme ve geri bildirim dongusu oluşturulmali.

BI projelerinde başarısizlik oranı %70’i aşıyor; hatalardan ogreniin

BI Sistemi Başarı Metrikleri

BI sisteminizin etkinliğini değerlendirmek için aşağıdaki metrikleri kullanın (temsili değerler):

Bu metrikler, BI yatırımınızın geri donusunu ölçmenizi sağlar. Aylık veya çeyreklik izleme önerilir.

BI Kurulum Kontrol Listesi

Sikca Sorulan Sorular (SSS)