Veri ambarı, ERP, CRM, e-ticaret, üretim ve İK gibi farklı sistemlerdeki verinin raporlama ve analiz için tek bir veritabanında, ortak tanımlarla ve geçmişiyle birlikte toplandığı yapıdır. Veri, ETL (çıkar, dönüştür, yükle) süreçleriyle kaynaklardan otomatik çekilir, iş kurallarına göre temizlenip dönüştürülür ve ambara yüklenir. Sonuçta raporlar canlı sistemleri yavaşlatmadan tek bir kaynaktan beslenir ve herkes aynı rakamı görür.
Veri neden dağılır?
Şirket büyüdükçe her iş için ayrı bir sistem gelir. Muhasebe ve stok ERP'de, teklifler CRM'de, siparişler e-ticaret sitesinde ve pazaryeri panellerinde, üretim verisi MES'te, personel bilgisi İK yazılımında durur. Her sistem kendi formatında, kendi saatinde ve kendi kodlarıyla veri üretir.
Bir rapor gerektiğinde tipik senaryo şudur: biri her sistemden dışa aktarım alır, Excel'de DÜŞEYARA ile birleştirir, eşleşmeyen kayıtları elle düzeltir. Aynı ciro satışta bir, finansta başka rakam çıkar; ağır rapor sorguları gün içinde ERP'yi yavaşlatır; geçen yılla karşılaştırma yapılmak istendiğinde de o dönemin fiyat ya da organizasyon yapısı çoktan değişmiştir. Bu elle raporlamadan çıkış yolunu Excel raporlamadan BI'a geçiş yazısında adım adım anlattık.
ERP tek başına bu tabloyu çözmez, çünkü ERP işlemleri kaydetmek için tasarlanmıştır, analiz için değil. CRM'deki teklif, pazaryerindeki sipariş ya da MES'teki duruş kaydı ERP'ye hiç girmeyebilir.
Sorunu çözmemenin maliyeti
Türkiye'de işletmelerin çoğunda veri kaydediliyor ama analiz edilmiyor:
TÜİK'e göre 2025'te 10 ve daha fazla çalışanı olan girişimlerin %28,3'ü ERP kullanırken iş zekası (BI) yazılımı kullananların oranı yalnızca %6,5 oldu. (TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2025)
Aradaki fark, verinin sistemlerde durduğu ama karar için birleştirilmediği şirketleri gösteriyor. Dağınık verinin maliyeti tek bir kalemde görünmez; hatalı raporda, geciken kararda, iki kez sayılan stokta ortaya çıkar. Veri kalitesi uzmanı Thomas C. Redman, kötü verinin çoğu şirkete maliyetini gelirin %15-25'i olarak tahmin ediyor ve bu maliyetin üçte ikisinin belirlenip kalıcı olarak ortadan kaldırılabileceğini öngörüyor (MIT Sloan Management Review, "Seizing Opportunity in Data Quality", 2017).
Altyapı tarafında da tablo değişiyor. TÜİK'e göre 2026'da girişimlerin %20,2'si ücretli bulut bilişim hizmeti kullandı; oran 250+ çalışanlılarda %57,0, 10-49 çalışanlılarda %16,7 (TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2026). Aynı araştırmaya göre girişimlerin yalnızca %15,2'si BİT uzmanı istihdam ediyor. Kısacası veri ambarı artık yalnızca büyük şirketlerin işi değil; ama kurmak ve işletmek, çoğu şirketin kendi ekibinde bulunmayan bir uzmanlık gerektiriyor.
Veri ambarı nedir? Yapı taşları ve ETL
Bir veri ambarı projesi birkaç katmandan oluşur:
- Kaynak sistemler: ERP (Logo, SAP, Mikro, Netsis ya da firmaya özel), CRM, e-ticaret ve pazaryeri API'leri, MES/SCADA, İK ve bordro, Excel dosyaları.
- ETL / ELT süreçleri: Verinin kaynaktan çekilmesi (extract), iş kurallarına göre dönüştürülmesi (transform) ve ambara yüklenmesi (load). ELT'de veri önce ham haliyle yüklenir, dönüşüm ambarın içinde yapılır.
- Hazırlık (staging) alanı: Ham verinin dönüştürülmeden önce geçici olarak tutulduğu, kalite kontrollerinin yapıldığı katman.
- Ambar modeli: Olgu (satış, üretim, hareket) ve boyut (müşteri, ürün, tarih, şube) tablolarıyla kurulan yıldız şema (star schema). Raporları hızlandırır ve anlaşılır kılar.
- Veri pazarları (data mart): Satış, finans ya da üretim gibi tek bir alana odaklanan, ambarın alt kümeleri.
- Ham veri alanı (data lake): Sensör akışları, log dosyaları, görüntüler gibi hacimli ya da yapılandırılmamış veriler için ayrı depolama.
- Tüketim katmanı: BI dashboard'lar, raporlar, yapay zekâ ile talep tahmini ve diğer yapay zeka modelleri.
ETL mi, ELT mi, doğrudan bağlantı mı?
| Yaklaşım | Nasıl çalışır | Uygun olduğu durum | Dikkat edilecek nokta |
|---|---|---|---|
| Raporlamada doğrudan bağlantı | BI aracı kaynak veritabanını doğrudan sorgular | Tek sistem, az kullanıcı, basit raporlar | Canlı sistemi yavaşlatır, geçmiş korunmaz |
| ETL | Veri ambar dışında dönüştürülüp temiz haliyle yüklenir | Şirket içi (on-premise) sunucular, sıkı veri kuralları | Dönüşüm kuralı değişince yeniden yükleme gerekebilir |
| ELT | Ham veri önce yüklenir, dönüşüm ambarda yapılır | Bulut ambarları, yüksek veri hacmi | Ham veride kişisel veri erişimi iyi yönetilmeli |
| CDC (değişen veriyi yakalama) | Yalnızca değişen kayıtlar aktarılır | Stok, sipariş gibi sık güncellenen kritik veriler | Kaynak veritabanının bu yönteme uygunluğu kontrol edilmeli |
Pratikte çoğu proje bunların karışımını kullanır: stok ve sipariş verisi CDC ile dakikalar içinde, finans verisi gece toplu olarak aktarılır.
Geçmişi korumak neden önemli?
Bir müşteri bu yıl başka bir satış temsilcisine devredildiğinde, geçen yılki satışlarının hangi temsilciye yazılacağı sorusu raporları doğrudan etkiler. Kaynak sistem genellikle yalnızca güncel durumu tutar. Veri ambarında "yavaş değişen boyut" (slowly changing dimension) yöntemiyle eski ve yeni değer tarihleriyle saklanır; böylece fiyat, cari ya da organizasyon değiştiğinde geçmiş dönem rakamları bozulmaz.
Veri ambarı projesi adım adım
- Soruları toplayın. Ambar, yanıtlanacak iş sorularına göre tasarlanır. Yönetim, satış, finans ve üretimin her ay sorduğu soruları ve bunlar için kullanılan göstergeleri listeleyin. Göstergeleri seçme yöntemini yönetici paneli KPI seçimi yazımızda anlattık.
- Kaynakları haritalayın. Hangi veri hangi sistemde, hangi tabloda, hangi sıklıkla değişiyor; kim sorumlu. Excel'de tutulan paralel listeler de bu haritaya girer.
- Ortak tanımları yazın. "Net satış", "aktif müşteri", "stoktaki ürün" gibi terimlerin tek bir tanımı olmadan ambar, eski tartışmayı yeni bir veritabanına taşır.
- Veri kalitesini ölçün. Mükerrer cari, farklı kodlanmış ürün ve boş zorunlu alanlar yükleme öncesinde tespit edilir. Bu konuyu veri kalitesi ve mükerrer kayıt yazımızda ayrıntılı ele aldık.
- Altyapıyı seçin. PostgreSQL, MSSQL ya da BigQuery, Redshift gibi bulut ambarları; seçim veri hacmine, mevcut lisanslara, kişisel verinin nerede tutulması gerektiğine ve ekibin yetkinliğine göre yapılır. Bulut tarafının maliyet kalemlerini bulut geçişi maliyeti yazısında inceledik.
- Tek alanla başlayın. Önce satış ya da finans gibi tek bir veri pazarını uçtan uca kurun, raporu kullanıcıya açın, sonra genişletin.
- Otomatikleştirin ve izleyin. ETL süreçleri zamanlanmış ve yeniden çalıştırılabilir olmalı; başarısız yükleme kaydedilmeli ve sorumluya bildirilmelidir. Sessizce duran bir ETL, eski veriyle karar verdirir.
- Erişimi ve KVKK'yı planlayın. Ambar, birçok sistemin verisini tek yerde topladığı için yetki yapısı kaynaktakinden daha dikkatli kurulmalıdır. Kişisel veriler için maskeleme, saklama ve imha süresi ve erişim kaydı baştan tasarlanır.
Digital Bridge'de bu işi nasıl yapıyoruz?
Veri ambarı ve ETL entegrasyonu projelerimizde kurduğumuz yapı şu parçalardan oluşuyor:
- Zamanlanmış, yeniden çalıştırılabilir ETL. Veri kaynaklardan belirlenen aralıkla çekiliyor, firmanızın iş kurallarına göre dönüştürülüyor. Başarısız yükleme kaydediliyor, otomatik yeniden deneniyor ve sorumluya bildiriliyor.
- Yıldız şemayla modellenmiş merkezi ambar. PostgreSQL, MSSQL ya da bulut tabanlı altyapıyı veri hacminize ve mevcut sisteminize göre seçiyoruz; fiyat, cari veya organizasyon değişikliklerinde geçmiş dönem rakamları korunuyor. Bulut ya da şirket içi kararında bulut geçiş ve altyapı danışmanlığı ekibimiz de sürece dahil oluyor.
- Yükleme anında kalite kontrolü. Boş alanlar, yinelenen kayıtlar, biçim hataları ve eşleşmeyen referanslar yükleme sırasında yakalanıyor; hatalı kayıt rapora girmeden ayrılıyor. Kök nedenin kaynakta çözülmesi gerekiyorsa veri yönetişimi ve kalite çalışmasıyla ilerliyoruz.
- CDC ile canlı sistemi yormadan aktarım. Stok ve sipariş gibi kritik veriler dakikalar içinde, finans verisi günlük toplu aktarılıyor; yalnızca değişen kayıtlar taşındığı için ERP yavaşlamıyor.
- Kaynak sistem bağlantıları. Logo, SAP, Mikro, Netsis ve firmaya özel ERP'ler, CRM ve pazaryeri API'leri için bağlantıları sistem entegrasyonları deneyimimizle kuruyoruz.
- Tüketim katmanı. Ambarın üzerine BI dashboard ve talep tahmini analitiği gibi modeller kuruyor, hepsinin aynı tek kaynaktan beslenmesini sağlıyoruz.
Operasyon sistemleri de kaynak olabilir. SmartPass üzerindeki geçiş, puantaj ve yemekhane kayıtları rapor olarak alınıp ERP verisiyle aynı ambara yüklenebilir; böylece personel ve devam verisi, üretim ve maliyet rakamlarıyla yan yana görünür.
Hazır paket satmıyoruz; ihtiyaç analizinin ardından kapsamı, aşamaları ve bedeli içeren yazılı bir teklif hazırlıyoruz.
Sonraki adım
Kendinize üç soru sorun: Yönetim raporu için kaç sistemden dışa aktarım alınıyor? Aynı göstergeyi iki departman farklı rakamla raporluyor mu? Geçen yılın aynı dönemiyle güvenilir karşılaştırma yapabiliyor musunuz? Yanıtlardan biri bile sizi rahatsız ediyorsa, tek bir veri alanıyla başlayan bir ambar projesi değerlendirmeye değer. Bizimle iletişime geçin; kaynaklarınızı birlikte haritalayıp ilk veri pazarının kapsamını çıkaralım.