Veri Ambarı Çözümleri: KOBİ İçin Ne Zaman Gerekir?

Doğru soru "gerekli mi" değil, "hangi eşiği geçtik"

İşletmelerde veri sorunu gürültüsüz büyür. Başlangıçta tek bir Excel dosyası yeter; sonra ikinci bir program gelir, ardından üçüncü. Kimse "artık dağıldık" diye bir karar anı yaşamaz. Bir gün yönetim toplantısında iki kişinin elindeki aynı ayın satış rakamı tutmaz ve toplantının yarısı hangi rakamın doğru olduğunu tartışmakla geçer. Veri ambarı çözümleri KOBİ için ne zaman gerekir sorusu genelde tam bu noktada gündeme gelir — ama gündeme gelmesiyle gerekli olması aynı şey değildir.

Bu ayrımı yapmak, KOBİ ölçeğinde küçük bir işletmenin bütçesini yanlış yere harcamasını engeller. Aynı kurulum, doğru eşikten önce yapıldığında pahalı bir raporlama oyuncağı; doğru eşikten sonra yapıldığında yönetimin karar hızını değiştiren bir altyapı olur. Bu yazı, o eşiğin nerede olduğunu somut belirtilerle anlatıyor.

Dağınık verinin faturası nereye yazılır

Dağınık veri, muhasebe defterinde bir gider satırı olarak görünmez. Görünmediği için de uzun süre katlanılır. Oysa bedelini üç yerden öder işletme.

Birincisi zaman. Ay sonu raporu, birilerinin farklı sistemlerden veri indirip elle birleştirmesiyle çıkar. Bu iş her ay tekrarlanır ve her tekrarında sıfırdan yapılır. Yapan kişi izne çıktığında raporun nasıl üretildiğini kimse tam olarak bilmez.

İkincisi güven. CRM'deki ciro ile muhasebedeki ciro tutmadığında, tartışma işin kendisinden çıkıp rakamın doğruluğuna kayar. Bir kez güven kırıldığında insanlar rapora değil sezgilerine döner; bu noktadan sonra en iyi rapor bile kararı değiştirmez.

Üçüncüsü gecikme. "Geçen çeyrekte hangi ürün grubu kâr kaybettirdi?" sorusunun cevabı üç gün sonra geliyorsa, cevap geldiğinde karar penceresi çoktan kapanmıştır. Yavaş cevap, çoğu zaman yanlış cevaptan daha maliyetlidir.

KOBİ için veri ambarı çözümleri ne zaman gerekir

Aşağıdaki maddeler bir puanlama listesi değil, eşik göstergesidir. Birkaçı birden geçerliyse konuyu ciddiye almanın vakti gelmiştir.

• İki ve daha fazla sistem aynı bilgiyi farklı tutuyor. Satış CRM'de, fatura muhasebede, stok ERP'de duruyorsa ve bunlar arasında elle mutabakat yapılıyorsa, mutabakatı yapan kişi aslında insan eliyle çalışan bir veri ambarıdır.
• Aynı raporu her ay yeniden üretiyorsunuz. Tekrarlanan el emeği, otomatikleştirilebilir demektir; tekrar eden manuel birleştirme klasik bir veri ambarı işidir.
• Geçmişi kaybediyorsunuz. Pek çok operasyonel yazılım güncel durumu tutar, geçmiş fotoğrafı tutmaz. Stok bugün ne, cevabı vardır; geçen yılın mart ayında ne olduğunun cevabı yoktur. Trend göremeyen işletme mevsimselliği de göremez.
• Pazaryeri, reklam ve site verisi ayrı ayrı duruyor. Reklam harcaması bir panelde, sipariş başka bir panelde, iade üçüncü bir yerdeyse ürün bazında gerçek kârlılık hiçbir ekranda yazmıyor demektir.
• Sorular tek seferlik değil, tekrarlayan tipte. "Bu müşteri segmenti büyüyor mu?" sorusu her ay soruluyorsa, bu bir rapor değil bir gösterge ihtiyacıdır.

Bu belirtilerin ortak noktası hacim değil parçalanma. Veri ambarı çözümleri büyük veri için değil, bölünmüş veri için vardır. Günde birkaç yüz sipariş alan bir e-ticaret işletmesi, günde on bin satır üreten ama tek sistemde çalışan bir üreticiden daha çok ihtiyaç duyabilir.

Veri Ambarı Çözümleri KOBİ İçin Ne Zaman Gerekir: Kısa Cevap

Eşikleri tek tek yazdım, ama kısa cevap şu: ihtiyaç verinin miktarından değil, aynı soruya iki farklı cevap gelmeye başlamasından doğar. Toplantıda iki kişinin aynı ayın rakamını farklı söylemesi, tek başına bir teknoloji kararından daha güçlü bir işarettir. Aşağıda tersini, yani henüz gerekmediğini gösteren işaretleri sıraladım.

Henüz gerekmediğini gösteren işaretler

Bir danışmanlık yazısının söylemesi gereken diğer yarısı da bu: her işletmenin buna bugün ihtiyacı yok.

• Tüm operasyon tek bir sistemde dönüyorsa ve o sistemin raporları sorulan soruları karşılıyorsa, araya bir katman koymak yalnızca bakım yükü ekler.
• Veri girişinin kendisi düzensizse — aynı müşteri üç farklı yazımla kayıtlıysa, ürün kodları tutarsızsa — önce kayıt disiplini kurulur. Dağınık veriyi merkezileştirmek onu düzeltmez, yalnızca dağınıklığı tek yerde toplar.
• Cevabı aranan soru henüz netleşmemişse. "Elimizde veri var, bir şeyler çıkaralım" ile başlayan projelerin çoğu kimsenin açmadığı bir panoyla biter.

Bu üç durumdan biri sizdeyse doğru hamle beklemek değil, sırayı düzeltmektir: önce kayıt düzeni, sonra entegrasyon, sonra ambar. Veri ambarı çözümleri bu sıranın son halkasıdır, ilk halkası değil.

Veri ambarı, raporlama aracı ve yedek aynı şey değil

Konuşmalarda en sık karışan üç kavram bunlar. Aradaki farkı bilmek, teklif alırken neyin fiyatlandığını anlamayı da kolaylaştırır.

Yedek

Yedek, veriyi kaybetmemek içindir; sorgulamak için değil. Bir yedekten "geçen yılın en kârlı üç ürünü" sorusunun cevabı çıkmaz.

Raporlama aracı (BI)

Power BI, Metabase veya Tableau gibi araçlar veriyi gösterir. Gösterecek düzgün bir kaynak yoksa, aracın yaptığı iş her seferinde farklı yerlerden veri çekip birleştirmeye çalışmaktır. Görselleştirme katmanı, altındaki dağınıklığı çözmez.

Veri ambarı

Ambar, farklı kaynaklardan gelen veriyi düzenli aralıklarla çekip temizleyen, ortak bir sözlükle eşleyen ve analiz için saklayan katmandır. Kurulumun asıl işi burada, panolarda değil. Bu yüzden ciddi veri ambarı çözümleri her zaman üç parçadan oluşur: veriyi taşıyan akış (ETL), veriyi saklayan yapı ve üstteki gösterim katmanı.

Kurulum pratikte neye benzer

Süreç genelde beklendiği gibi teknik bir işle başlamaz; envanterle başlar.

Kaynak envanteri. Hangi sistemde hangi veri var, kim giriyor, ne sıklıkla değişiyor. Bu adım çoğu işletmede ilk sürprizin çıktığı yerdir: kimsenin hatırlamadığı bir tabloda kritik bir bilginin tutulduğu burada görülür.

Ortak tanım. "Ciro" kelimesi satış ekibiyle muhasebe için aynı anlama gelmiyorsa, hangi tanımın kullanılacağı yazılı olarak kararlaştırılır. Teknik olmayan ama projenin başarısını en çok belirleyen adım budur.

Akışın kurulması. Kaynak sistemlerden veri düzenli aralıklarla çekilir, tekilleştirilir ve ambara yazılır. Kaynak API vermiyorsa entegrasyon yazılır; bu noktada iş özel çözüm geliştirme tarafına geçer.

İlk pano. Onlarca gösterge değil, yönetimin gerçekten baktığı birkaç gösterge ile başlanır. Kullanılmayan gösterge bakım yüküdür.

Bu sıralamayı bozan projeler, hazır sistemlerin nerede bitip özel kodun nerede başladığını da genellikle yanlış konumlandırır; özel yazılımın hangi eşikte gerektiği ayrı bir karar konusudur ve aynı mantıkla ele alınır.

Bulutta mı, kendi sunucunuzda mı

Kaynaklar netleştikten sonra gelen ilk teknik soru budur ve cevabı ölçeğe göre değişir.

Bulut tarafındaki ambar hizmetleri kullandığınız kadar ödeme mantığıyla çalışır. Küçük başlayıp büyütmek mümkündür, donanım bakımı yoktur. Buna karşılık maliyet sabit değildir: sorgu alışkanlıkları değiştikçe fatura da değişir, verinin hangi ülkede tutulduğu ise sözleşmeyle belirlenir ve baştan kontrol edilmesi gereken bir maddedir.

Kendi sunucunuzda tutmak maliyeti öngörülebilir kılar ve veriyi fiziksel olarak elinizde bırakır. Karşılığında yedekleme, güncelleme ve erişim güvenliği tamamen sizin sorumluluğunuza geçer. Bu sorumluluğu üstlenecek teknik bir ekibiniz yoksa, ucuz görünen seçenek pratikte daha pahalıya gelir.

KOBİ ölçeğinde çoğu durumda yönetilen bir bulut yapısı daha az bakım yükü çıkarır. Karar "hangisi daha modern" sorusuna göre değil, bir sabah akış durduğunda telefonu kimin açacağına göre verilir. Kurumsal veri ambarı tartışmalarının çoğu bu noktada teknik olmaktan çıkıp operasyonel bir soruya döner.

Maliyeti belirleyen üç değişken

Veri ambarı çözümleri için sabit bir fiyat listesi vermek yanıltıcı olur, çünkü tutarı kurulumun kendisi değil aşağıdaki üç şey belirler.

• Kaynak sayısı ve erişilebilirliği. Standart API'si olan bir sistemden veri çekmek ile kapalı bir programın veritabanından veri çıkarmak aynı iş değildir.
• Veri kalitesi. Temizlik gerektiren kayıt ne kadar çoksa, işin ağırlığı taşımadan temizliğe kayar.
• Tazelik ihtiyacı. Günde bir kez güncellenen bir yapı ile anlık akış isteyen bir yapı farklı mimarilerdir. Çoğu KOBİ için günlük tazelik fazlasıyla yeterlidir; gerçek zamanlı isteği çoğu zaman ihtiyaçtan değil alışkanlıktan doğar.

Bu üç değişken konuşulmadan verilen rakam tahmindir. Bu yüzden değerlendirme, kaynakların gözden geçirildiği bir görüşmeyle başlar; kapsam netleştikten sonra kapsama göre bir teklif anlamlı hâle gelir.

Bir de kurulum bittikten sonra devam eden kalem vardır ve teklif aşamasında çoğu zaman konuşulmaz: barındırma, akışın izlenmesi ve kaynak sistemler değiştikçe yapılan bakım. Bu kalem küçüktür ama sıfır değildir. Baştan konuşulmadığında, altı ay sonra "bu neden hâlâ para istiyor" sorusuna dönüşür.

Veriyi bir yerde toplamak sorumluluğu da toplar

Dağınık veride kişisel veri riski de dağınıktır; merkezileştirdiğinizde risk tek noktada birikir. Bu, projenin teknik değil hukuki tarafıdır ve sonraya bırakılmaz.

Pratikte üç şey baştan kararlaştırılır: hangi alanların ambara hiç taşınmayacağı (gereksiz kişisel veri taşınmaz), kimin hangi tabloyu görebileceği (rol bazlı erişim) ve kayıtların ne kadar süre saklanacağı. KVKK uyumu bir kurulum sonrası düzeltme değil, mimarinin parçasıdır. Aynı ilke şirket içinde veriye erişen tüm sistemler için geçerlidir; web ve yazılım tarafındaki yetkilendirme mantığıyla ambarın yetkilendirmesi birbirini tutmalıdır.

Bir veriyi ambara taşımadan önce sorulacak soru şu: bu alan olmadan cevaplayamayacağımız bir soru var mı? Yoksa taşınmaz.

Kurulumdan sonra ambarın sahibi kim

Bu tür projelerin çoğu teknik nedenlerle değil sahipsizlik yüzünden söner. Ambar canlıya alındıktan sonra üç iş sürekli hâle gelir ve her birinin bir adı olması gerekir.

Akışın izlenmesi. Kaynak sistemlerden biri bir alanın adını değiştirdiğinde ya da bir API sürümü eskidiğinde akış sessizce durabilir. Fark edilmeyen bir duruş, yanlış rakamdan daha tehlikelidir; çünkü pano çalışıyor görünür, yalnızca eskimiştir. Bu yüzden akış hatalarının bir yere alarm üretmesi kurulumun parçasıdır, sonradan eklenen bir ayrıntı değil.

Tanımların güncel tutulması. Yeni bir ürün grubu, yeni bir satış kanalı ya da değişen bir iade kuralı geldiğinde tanımlar da güncellenir. Aksi hâlde ambar bir süre sonra geçmişi doğru, bugünü eksik anlatır ve bu, en zor fark edilen hata türüdür.

Kullanımın gözden geçirilmesi. Hangi gösterge gerçekten açılıyor, hangisi bir kez bakılıp unutuldu. Kullanılmayan gösterge silinir; bakım yükü ancak böyle küçük kalır. Sürdürülebilir veri ambarı çözümleri kurulum günü değil altıncı ayda belli olur.

Başlamanın en ucuz yolu: soru listesi

Teknoloji seçimiyle başlamayın. Bir sayfaya, yönetimin ayda en az bir kez sorduğu ve cevabı zor bulunan soruları yazın. Beş ila on soru genellikle yeterlidir. Sonra her sorunun yanına cevabın hangi sistemde saklı olduğunu yazın.

Bu liste iki şeyi birden gösterir: gerçekten kaç kaynağa dokunulması gerektiğini ve sorunun veri eksikliğinden mi yoksa dağınıklıktan mı kaynaklandığını. Çoğu işletmede sorular üç ya da dört sistemde toplanır, bu da kapsamı beklenenden dar tutmayı mümkün kılar. Kapsamı dar tutulmuş veri ambarı çözümleri, geniş başlayıp yarım kalan projelerden hem daha hızlı hem daha ucuz sonuç verir.

Listeniz hazırsa bir sonraki adım teknik değerlendirmedir: kaynakların erişilebilirliği, veri kalitesi ve tazelik ihtiyacı üzerinden kapsamın çıkarılması. Veri ambarı kurulumu ve iş zekâsı hizmetimizin kapsamı, hangi sistemlerden veri çekildiği ve mimarinin nasıl kurulduğu ayrı bir sayfada anlatılıyor.

Son bir not: bu işin başarısı panonun görünüşüyle değil, aylar sonra hâlâ açılıp açılmadığıyla ölçülür. Kurulumdan otuz gün sonra kimse bakmıyorsa, sorun veride değil soru listesindedir.