Veri üretiminin
ve kullanılamadan tüketilen verinin hiç bu kadar büyük hacimlerde olduğu bir
dönemden geçmemiştik. Kurumlar satış rakamlarını yukarı çekmek, müşteri
memnuniyetlerinde zirve yapmak için tek bir müşteri şikayetini dahi kaçırmamak
adına yeni teknolojiler arıyorlar, teknoloji üretenler de, bu ihtiyaçları
karşılamak için, AR&GE’lerden gelen bilimsel çalışmaları, ürün haline
getirmek için uğraşıyorlar.
Öyle bir
noktadayız ki, eskiden doğru bilgiyi bulamamak bir problemdi, şimdi bilgiye
ulaşmak için veri okyanusunda boğulmamak daha büyük yetenek gerektiriyor.
Bu bağlamda, OLTP
sistemlerimizde oluşturduğumuz verileri anlamlı hale getirmek için Veri Ambarları oluşturduk, bu ambarları, ETL
süreçleri ile doldurduk. Başlarda bu doldurma süreleri makul sürelerdeydi. İş
birimleri de bizi o kadar sıkıştırmıyorlardı. Raporların ertesi günü alınması
sorun olmuyordu. Zamanla bu ambarlardan anlık, analitik sorgu yapmak ve bu
sorgularla karar süreçlerimizi beslemek için “Canlı” Karar Destek Sistemleri
kurduk. İş birimleri bu sistemlerden hazır raporları değil, istedikleri dinamik
raporları çeker hale geldiler ve öyle de bağımlı hale geldiler ki, kimse artık
istediği rapor için saatler geçmesine veya ertesi sabahı beklemeye dayanamıyor.
İş birimlerinin
aradığı her cevabın arkasında veri var ve doğru veriyi toplayan, hızlı
raporlayan ve analiz edebilenin (bu üçünü aynı anda yapabilenin) avantaj
sağladığı günlerdeyiz. Öyle ki, yukarıda ki analiz sistemleri mevcut veri
üzerinden özet ve rafine bilgi üreterek karar vericileri desteklerken, bu
olgunun bir adım ötesi olan “Predictive” yani ileriyi gören analiz
sistemlerinin de (Predictive Analytics - PA) konuşulduğunu ve uygulandığıni
görüyoruz. PA, karar destek süreçlerine, verinin istatistiksel olarak analiz edilmesi
ve bilginin tahminde bulunularak dahil edilmesi olarak da adlandırlılabilir. PA,
İş analizi süreçlerine tarihi verinin incelenerek bir tahmin çıkarılması
üzerinden dahil olmak olarak da görülebilir. Bu tahminler, bir model
kullanılarak, geçmiş verilerden üretilen skor ile servis edilir.
Skorlama katmanı;
verinin içindeki bu gizli değeri süzerek, belirlenen kategoriler ile müşteriyi,
hizmeti, servisi belli bir segmente yerleştirmek olarak da düşünülüyor. Müşteri
özelinden bakarsak, o müşterinin sadakati, ürün çeşitliliği, geçmiş
hareketleri, portföy, vb. çeşitleyebileceğimiz
bir çok değer bir araya gelerek bu skor oluşuyor. Online veya Offline olarak
üretilebilen bu skor genellikle müşterinin anlık hareketine göre üretilmiyor.
Skorlama sürecinde, periyodik olarak, OLTP’den ve ambardan alınan veriler
işlenip skor oluşuyor; kurum buradan bu bilgiyi sorgulayarak tüketiyor,
kullanıyor ve işini görüyor.
Bu süreçteki
sorun şu;
Eğer skor
bilgisini üretecek veriyi sağlayan sistem, skoru üreten sistem ve skoru
kullanacak sistemler birbirinden ayrık ve dağıtık olarak çalışıyorsa,
işletimden, karar sürecine kadar olan süreçlerde ki cevap süreleri, SLA’lerin
üzerine çıkabiliyor, veriye ulaşımda gecikmeler olabiliyor. Daha da kötüsü,
doğru zamanda doğru kararı vermeye yardımcı olacak skor bilgisinin zamanında
alınamamasına neden oluyor.
Model Skorlamanın
üretimi ve bu skorun OLTP sistem içinden erişimi için çok temel iki yaklaşım var:
A- Offline - Batch Skorlama: klasik
ve en yaygın yaklaşım bu. ETL süreçi ile taşınan veri üzerinden, yine Batch
işlemle geçilerek türetilen skor, tüketime hazır hale geliyor ama güncelliği
ancak bir sonraki üretim döngüsünden sonra olabiliyor. OLTP Transaction içinden
erişimi yok.
B- Online – OLTP ve dış
skorlama fonksiyonu: Bu metod birincisine göre daha modern. Webservis ile transaction
içinden çağrılan skorlama modeli, işini görüp geri geliyor. Yalnız bu metodun
işletimi sırasında, OLTP ile senkron çalışması gereken Webservisi, OLTP’nin
SLA’ler içinde tamamlanmasını engellediği gibi, güvenlik, ağ gecikmesi gibi
sorunlar da barındırıyor.
Yukarıdaki
durumların bütün bileşkesi ve acil iş ihtiyaçlarının dayatmaları, B metodunun
da “gerçek zamanlı ve In-DB olarak”
yapılması ihtiyacını doğurdu. Böyle bir teknoloji bizlere, skorlama ihtiyacını,
OLTP ortamında çalışan transaction henüz sonlanmadan ve dış skorlama katmanına
gitmeden, veritabanının içinde çalışan skorlama metodu ile sağlayacak, veri
güvenliği ve ağ gecikmelerinden soyutlayacaktır. Bu teknoloji ancak ve ancak
kullanılan programlama dilinin ve SQL’ün olanakları ile çağrılabilen ve Veri
Tabanının içinde çalışabilen imkanlar serisi ile sağlanacaktır.
Bu çok detay gibi
gözüken ama büyük finans kurumlarının dört gözle beklediği bir olanak olarak
gözüküyor. Özellikle rekabetin zirve yaptığı bu dönemde yazılım üreticilere çok
iş düşüyor.
