Veri Analitiği & BI Dashboard: Karar Destek Panelleri

Veri her yerde ama bilgi hiçbir yerde: Türkiye'deki orta ölçekli işletmelerin çoğunun analitik durumu tam olarak bu. Satış rakamı ERP'de, sipariş verisi e-ticaret panelinde, pazarlama harcaması Google Ads'te, stok bir başka modülde, üst yönetimin baktığı "asıl rapor" ise birinin her ay elle güncellediği bir Excel dosyasında duruyor. Ay sonu raporu üç gün sürüyor, iki ekip aynı metriği farklı hesapladığı için toplantı "kimin rakamı doğru" tartışmasına dönüşüyor, kararlar veriden çok sezgiyle ve geç alınıyor. Dijital dönüşümün veri tarafında ilk müdahale ettiğimiz alan budur: dağınık kaynakları bir veri ambarında birleştirip, tek doğruluk kaynağından beslenen, gerçek zamanlı ya da düzenli tazelenen canlı KPI dashboard'larına geçiş: Excel'i veri girişi aracı olarak bırakıp raporlamayı sisteme almak.

Yaklaşımımız

Veri analitiği projelerinde ilk haftada teknolojiye değil sorulara odaklanmayı öneriyoruz. Çünkü en pahalı hata, kimsenin gerçekten bakmadığı güzel bir dashboard yapmaktır. Önce "hangi 8-10 soruyu sürekli soruyorsunuz ama cevabı zor alıyorsunuz" diye soruyoruz; bu sorular metrik tanımlarına, metrik tanımları da veri modeline dönüşüyor. Bu aşamada karşımıza çıkan en yaygın durum, aynı kelimenin (örneğin "ciro" ya da "aktif müşteri") farklı departmanlarda farklı anlama gelmesi. Bunu projenin başında bir metrik sözlüğünde netleştirmeyi tercih ediyoruz, çünkü panel ne kadar güzel olursa olsun, altındaki tanımlar tutarsızsa kimse rakama güvenmez.

İkinci kritik karar tek doğruluk kaynağı için bir veri ambarı. Verinin ERP, e-ticaret, CRM, reklam platformları ve Excel gibi kaynaklarda dağınık durmasının çözümü, hepsini merkezi bir ambarda toplamaktır. Hacme ve bütçeye göre BigQuery, Snowflake ya da daha mütevazı kurulumlar için PostgreSQL öneriyoruz. Kaynaklardan ham veriyi ambarına taşımak için Apache Airflow veya Dagster ile zamanlanmış ELT işleri kuruyoruz; ham veri önce olduğu gibi yükleniyor (extract-load), modelleme ambar içinde yapılıyor. Bu ELT yaklaşımını klasik ETL'e tercih etmemizin nedeni, dönüşüm mantığının görünür, sürümlenebilir ve geri alınabilir olması: bir hesaplama hatası çıktığında neyin neden değiştiğini görebiliyoruz.

Üçüncü katman dbt ile modelleme ve veri kalitesi. Ham veriyi panele bağlamak yerine, araya dbt ile bir dönüşüm katmanı koymayı öneriyoruz. Her kaynağın kendi tarih formatı, müşteri kodu, para birimi olabiliyor; dbt katmanında bunları tek tutarlı şemaya normalize ediyoruz, metrikleri tek yerde tanımlıyoruz (örneğin "net ciro" tanımı tek bir SQL modelinde yaşar, on farklı panelde değil). dbt'nin test ve dokümantasyon özellikleriyle veri kalitesini sürekli denetliyoruz: boş kalmaması gereken alan boş kaldığında, satır sayısı beklenmedik şekilde düştüğünde uyarı çıkıyor. Böylece "rapordaki rakam yanlış" sürprizlerini panel kullanıcıya ulaşmadan yakalıyoruz.

Son katman dashboard ve dağıtım stratejisi. İç ekip analizi, self-service keşif ve hızlı kurulum için Metabase ya da Apache Superset öneriyoruz; ekipler kendi sorgularını yazabiliyor, lisans maliyeti düşük kalıyor. Panelin müşteriye/bayiye gösterileceği, markalı ya da uygulama içine gömülü olması gereken durumlarda Next.js ile özel dashboard geliştiriyoruz. Operasyonel metrikler gerçek zamanlı isteniyorsa Apache Kafka ile bir streaming hattı kuruyoruz; aksi halde günlük/saatlik batch yeterli ve daha ekonomik. Panel açılış hızını korumak için hafif sorgularda DuckDB ve Redis cache kullanıyor, hata izleme için Sentry bağlıyoruz.

Tercih Ettiğimiz Teknolojiler

Tipik tercihlerimiz aşağıdaki gibi; veri hacminize, bütçenize ve gerçek zaman ihtiyacınıza göre uyarlıyoruz.