İş Zekası Hakkında Her Şey – 7
Önceki bölümlerde İş Zekası ile ilgili pek çok temel konuyu, örneklerle ele aldık ve iş zekasının karar verme sürecindeki önemini vurguladık. Bununla birlikte İş Zekasının işletmedeki pek çok farklı seviye için önemini ve kullanım alanlarını açıkladık. Son olaraksa örnek işletmemiz olan “TinyToys Ltd” firmasını yakından tanıdık.
Sıradaki adımımız, “TinyToys Ltd” firmasının ihtiyaç duyduğu iş zekası çözümünü geliştirirken kullanacağımız örnek veritabanı yapılarını oluşturmak olacak. Bazı durumlarda İş Zekası için kaynak durumunda olan veriler doğrudan bazı veritabanı veya dosyalardan temin edilebilir durumda olurken, bazı durumlarda ise bu verilerin İş Zekası amacıyla kullanılabilir hale getirilmesi için gereken ön işlemleri yapabileceğimiz ayrı bir alana taşınması gerekir. Bu ayrı alana İş Zekası terminolojisinde “data mart” adı verilmektedir.
Kaynağın Aranması
İş Zekasının işletmelerin sağlıklı karar verebilmesi açısından önemini gördük. Bu bizi şu soruya yönlendiriyor: “İş Zekası’nın kaynağı nedir?”. İş Zekası çözümlerinde kaynak olarak kullanılan bilgi işletmenin zaten günlük işleyişiyle ortaya çıkarttığı transactional verilerdir.
Transactional Veri
Pek çok işletme gerçekleştirdiği işlemlerin takibini yapmaktadır. Alınan siparişler, üretilen ürünler, verilen servisler, müşterilerden alınan ödemeler ve tedarikçilere yapılan ödemeler gibi. Tüm bu işlemlere genel olarak “Business Transaction” ismini veriyoruz. Bu işlemler sonucunda oluşan verileri ise “transactional data” olarak adlandırıyoruz.
Bir işletmenin sağlıklı yürüyebilmesi için gerçekleşen “Business Transaction”ların takip edilmesi, ürün ve servisler için ödemelerin alınması, alınan ürün ve hizmetler için ise ödemelerin yapılması, sipariş ve servis taleplerinin karşılanması gerekmektedir. İşletmeler genellikle nelerin yapıldığı ve nelerin yapılması gerektiği ile ilgili kayıt tutmak zorundadırlar. Bu bilgilerin bilgisayar tarafından yönetilmesi ve bilgisayarda saklanması durumunu “Online Transaction Processing” ya da kısaca “OLTP” olarak adlandırıyoruz.
OLTP sisteminde saklanan verilerin toplamı, işletmenin geçmişini oluşturmaktadır. OLTP sistemleri, önceki bölümlerde değindiğim ölçütleri hesaplamak için gerekli ham verileri içermektedir. Bu nedenle İş Zekası çözümümüzü geliştirebilmek için bu verilere gereksinim duyarız.
Transactional Verilerin İş Zekası Çözümünde Kullanımının Zorlukları
OLTP sistemleri ölçütleri hesaplamak ve İş Zekası çözümümüzü geliştirebilmemiz için gereksinim duyduğumuz ham verileri barındırır demiştik. Ancak bu verilere erişimde bazı sıkıntılarla karşılaşabiliriz. Bu problemleri kısaca özetleyelim:
Tasarım Kısıtları: İyi tasarlanmış OLTP sistemleri transactionların sağlıklı bir şekilde işlenmesi ve saklanmasını sağlamak için optimize edilmiştir. Bu verilerin normalizasyon kuralları doğrultusunda daha ufak parçalara bölünmesi anlamına gelir. Bu OLTP sistemlerin çok sayıda transaction’ı eşzamanlı olarak yürütebilmesini sağlar. Bu tür verilerin saklanması için en sağlıklı platform ilişkisel veritabanı yönetim sistemleridir.
Diğer yandan İş Zekası için kullanacağımız ölçütler bir transaction’a ait olayları yansıtmak için değil, bir grup transaction’ın istenen zaman dilimi içindeki net sonucunu yansıtmak için tasarlanmıştır. İş zekası ölçütleri çoğunlukla yüzlerce, binlerce hatta milyonlarca ayrı transaction’ın hesaplanması ile elde edilirler. Bu sonuçları hesaplayabilmesi için sistemin bir grup farklı optimizasyondan geçirilmesi gerekecektir.
OLTP sistemler, tasarım amaçları ve yöntemlerinden dolayı bu tarz hesaplamalar konusunda çok başarılı değillerdir. Bu, zaten OLTP sistemlerin geliştirilme amacının dışındadır. Bu hesaplamaların sağlıklı çalışması için farklı bir veri saklama optimizasyonu ile çalışmamız gerekir.
Günlük İşlemler: OLTP sistemler işletmemizin günlük işlerini destekler. Çoğu durumda işletmenin reaksiyon hızı bu sistemlerin performansı ile orantılıdır. Eğer sipariş sistemi veya müşteri yönetim sistemi cevap vermez hale gelirse, işletmemizin işleri ciddi oranda aksayabilir. OLTP sistemler üzerinde az önce bahsettiğim hesaplamaları yapmak, bu sistemlerin işlem gücünü ve kaynaklarını ciddi oranda kullanacak ve hesaplamanın tamamlanması oldukça uzun zaman alacaktır. Hesaplama sırasında pek çok kaydın bloke olması da güçlü bir ihtimaldir ki bu, bu kayıtlara dayanan günlük işlemlerin o kayıtlardaki lock kalkana kadar durması anlamına gelecektir. Sanırım bu hesaplamaların OLTP sistemler üzerinde yapılmasının sakıncalarını saymaya devam etmeme gerek yoktur. Sadece bir rapor oluşturmak için muhasebe sisteminin durduğunu ya da e-ticaret platformunuzun cevap veremez hale geldiğini düşünün.
Arşivleme: OLTP sistemler günlük işlemlere odaklanmış olduğundan, uzak geçmişe yönelik verilerle ilgilenmez.Bu sistemler kısa bir döneme ait veriyi kaydeder ve/veya veri sadece o anki durumu gösterir. Bir ürünün o anki stok durumu gibi. Veriler bir yıl için kaydedilip sonrasında bir yıllık işlem tarafından silinebilir. Farklı bir formatta arşivlenebilir veya basitçe, silinebilir. Hangi durum olursa olsun, arşivlenen bu verilere erişim kolay olmayacaktır.
OLTP sistemler bu tarz arşivleme yöntemlerini sistemin sağlıklı çalışmasını garanti etmek için desteklerler. Bir transaction tablosu çok fazla kayıt içerirse, OLTP sistemi yavaş çalışmaya başlayabilir. Arşivleme, bu sistemlerin sağlıklı ve beklenen performansla çalışmasını sağlamak amacıyla da kullanılabilir. Ancak arşivleme İş Zekası açısından ciddi bir problem olabilir. Ölçütlerimizdeki trendlere bakarken geçen yılın değerlerini bu yıl ile hatta pek çok yılı birbiri ile kıyaslamak isteriz. Geçmiş yıllara ait veriler arşivlendiğinde ya da silindiğinde bu işlemin yapılması oldukça zorlaşacaktır.
Farklı Noktalardaki Veriler: İşletmelerin operasyonlarını yürüttüğü pek çok farklı OLTP sistemi olabilir. Örnek firmamızda olduğu gibi veriler farklı iş operasyonlar için farklı sistemlerde, farklı formatlarda saklanabilir. Hatta işletmenin tüm verilerinin tek bir sistemde saklandığı bir yapıyla büyük ihtimalle hiç bir zaman karşılaşamayacaksınız diyebilirim.
Diğer yandan İş Zekası çözümümüzde yer alacak ölçütler bu tür bir ayrımı desteklememektedir. Bunun yerine tüm işletmeyi bir bütün olarak görürler. Örneğin sıklıkla ihtiyaç duyulan ölçütlerden biri belirli bir ürüne dair kar payıdır. Bu ölçütü hesaplayabilmek için üretim sisteminden bu ürünün üretiminde kullanılan hammaddelerle ilgili bilgilere, muhasebe sisteminden bu hammaddelerin maliyetlerine, puantaj sisteminden bu ürünün üretimi için harcanan işgücü bilgisine, sipariş sisteminden ürün için ödenen rakama ihtiyaç duyarız. Bu, bu tür bir ölçütün hesaplanabilmesi için tüm bu farklı sistemlere ait verilerin bir araya getirilmesi gerektiği anlamına geliyor.
Sistemler arasındaki iletişime gelmeden önce, önümüzde farklı bir sorun var. Tüm bu sistemler, büyük ihtimalle farklı ürün tanımlama şemaları, kodlar ve takvimler kullanmaktadır. Aynı ürün üretim sisteminde “17187” ürün kodu ile tanımlıyken, e-ticaret sisteminde “EB-17RXQ” kodu ile tanımlı olabilir. Bordro programı 2 haftalık ödeme sistemi ile çalışırken, muhasebe sistemi mali aylarla çalışabilir. Farklı sistemlerdeki veriler bir araya getirildiğinde yapmamız gereken ilk iş, verilerin eşleştirilmesi olacaktır ki inanın bu çoğu durumda bir kaç sunucunun birbirleri ile iletişimini sağlamaktan çok daha basit bir işlemdir.
Yazı dizimizin bir sonraki bölümünde “Data Mart” konusunu ele alıyor olacağız.
