Yaygın İş Zekası Uygulaması İçin Önemli Olan Başarı Etkenleri

Transkript

1 Yaygın İş Zekası Uygulaması İçin Önemli Olan Başarı Etkenleri Eylül 2007 James Markarian Stephen Brobst Jeff Bedell Informatica Teradata MicroStrategy Teknoloji Direktörü Teknoloji Direktörü Teknoloji Direktörü

2 Yaygın İş Zekası Konuşlandırması İçin Önemli Olan Başarı Etmenleri İçindekiler Yaygın İş Zekası (Pervasive Business Intelligence BI) Yaygın BI Uygulamaları Bilişim Direktörünün (Chief Information Manager CIO) En Önemli Görevi Yaygın BI Kaynaklarının Mimarisi Karar Depoları: Aktif Veri Depolaması Taktiksel Kararlar Karışık İş Yükünü Önceliklendirmek Önemli Görevleri Yürüten Veri Depoları Veri Bütünleştirme Hizmetleri Veri Hizmeti Düzeyi Anlaşmaları Nedir (Data Service Level Agreements SLA)? Veri SLA sına Nasıl Ulaşırız? Karar Hizmetleri Müşteriyle Etkileşim İçindeki Kullanıcılar için Yaygın BI BI Hizmet Düzeyi Anlaşmaları Yaygın Analizler Yaygın BI için Dağıtım Mekanizmaları Yaygın BI için Karar Hizmetleri Başarı Etmenlerinin Özeti Teşekkür Bu çalışmanın gerçekleşmesini sağlayan destek ekibine teşekkürlerimizi sunarız. Bir teknoloji direktörü (Chief Technology Officer CTO) ile çalışmak için en az iki pazarlama ekibi görev almıştır (ve bu makaleyi üç CTO kaleme almıştır). Dan Graham, Jorge Lopez, Julianna DeLua, Amy Phillips, Tiffany Gumfory ve Cheryl Bowden a çok teşekkür ederiz. EB 5408 > 1007 > SAYFA 2/18

3 Yaygın İş Zekası İş zekası ve veri depoları, geçmişte, şirketlerin idari bölümlerinde (back office) çalışan personel ile ilişkilendiriliyordu larda veriler günlük olarak bütünleştirilmekte ve yüklenmekteydi. Veriler, eğilim raporları ve stratejik analizler için en uygun hale getirilmekte ve raporlama araçları aracılığıyla dağıtılmaktaydı. Önceden tanımlanmış raporları yürüten, idari bölümlerdeki planlamacılar, iş zekasının en temel kullanıcılarıydı. Bilgi çalışanları, zamanla daha zengin ve daha çeşitli bakış açıları istemeye başlamışlardır. Kullanım olgunlaştıkça, öngörülü analizleri, durum tabanlı uyarıları ve işletimsel karar desteğini içeren gereksinimler standart hale gelmiştir. Gerçek zamana yakın bilgilere yönelik talepler, genellikle müşteriyle doğrudan iletişim halindeki personelden (front office) gelmektedir. Ancak, verilerin günde birkaç kez girilmesinden kaynaklanan maliyetler ve karmaşıklık, verileri erişilmez kılmaktadır. Bu sorunlar, uzman veri merkezi yöneticilerini ve yenilikçi yazılım satıcılarını, kaynak sistemler ve veri depoları (data warehouse DW) arasındaki veri gecikmelerini engelleyerek, mesai saatleri boyunca tam zamanında kavrama becerisi sunan yöntemler bulmaya itmiştir. Birçokları için, bilgileri müşteriyle doğrudan ilişki içinde olan çalışanlardan izole eden (DW) çizgi ortadan kalkmıştır. İleriyi gören işletmeler, raporlamanın ötesine geçerek, birçok işletme süreci ve bilgi kullanıcıları boyunca, gelirleri ve maliyet tasarruflarını geliştirmenin yollarını bulmuşlardır. Müşteriyle doğrudan etkileşime sahip çalışanlar, sağlayıcılar, tüketiciler ve iş ortakları, en sonunda, taktiksel kara desteği için BI becerilerini kullanabilir hale gelmiştir. Bu sayede, veri analizi kullanarak rekabet eden işletmelerde, yaygın BI ortaya çıkmıştır. Yaygın BI Uygulamaları Kurumsal hedefleri belirleyen yöneticiler kadar, o hedefleri yürüten çalışanlar da büyük öneme sahiptir. Çalışanlar, müşteriler ve iş ortakları, her gün, karlılığı ve marka imajını etkileyebilecek, binlerce küçük karar almaktadır 1. Gerçektende geçmişte, müşteriyle doğrudan etkileşim içindeki birçok çalışan, kararlarını, kurumsal hedeflerle aynı hizayı yakalamak için gereken olgulara erişmeden almışlardır. Yaygın BI uygulamalarının amacı, idari birimler tarafından üretilen verilerin yatırım getirisini (Return of Investment ROI) %400 ten de fazlaya taşımaktır 2. Aynı zamanda, bu verileri müşteriyle doğrudan etkileşim içinde olan çalışanlara, yaptıkları işe uygun şekillerde dağıtmayı da hedeflemektedir (benzer sonuçlar ile). Bir işletmede, yaygın BI kavrama becerilerinin uygulanabileceği binlerce iş süreci bulunmaktadır. Peki, önde gelen şirketler, yaygın BI ile ne yapmaktadırlar? Bu soruyla ilgili bazı önemli noktalar aşağıdaki yer almaktadır: > Müşteri Hizmetleri Temsilcileri tarafından yapılan, gelen ve giden çapraz satışlar > Satış anındaki sahtekarlıklıların tespit edilmesi > Sigorta taleplerinin otomatik olarak sınıflandırılması ve sahtekarlıkların tespit edilmesi > Web sitelerinde, ATM lerde ve POS cihazlarında, kişiselleştirilmiş, bir sonraki en iyi teklifin sunulması > Tedarik zinciri faaliyetlerinin denetlenmesi > Promosyonlu ürünlerde, perakende stoğunda kalmayan ürünlerin denetlenmesi > Çalışma ve ekip zaman çizelgelerinin hazırlanması > Römork ve konteynır yüklemelerinin ve yönlendirmelerinin en iyi şekilde yapılması > Kara para aklanmasının önüne geçilmesi > Fiyatlandırmanın ve kazanç yönetiminin dinamik olarak gerçekleştirilmesi > Üretim hattındaki kalite uyarılarının gerçek zamanlı olarak aktarılması Yaygın BI, temel BI alt sistemlerine yeni iş yükleri ilave etmektedir. Klasik çıkart dönüştür yükle (extracttransform load ETL) alt sistemi artık, birden çok veri kaynağından, nerdeyse gerçek zamanlı olarak gelen verilerin bütünleştirmesi ile uğraşmak zorunda kalmaktadır. DW, sabit veri yüklemenin, karmaşık raporlamanın ve taktiksel taleplerin karışık iş yüklerini desteklemelidir. Bunun ardından, BI platformu, bütün verileri analiz etmeli ve bu bilgileri, raporlar, uyarılar ve işletimsel uygulamalar aracılığıyla zamanında iletmelidir. Yeni bilgi sağlama zinciri, yaygın BI çözümlerini sağlamak üzere oluşturulmalıdır. 1Frank Rohde, Little Decisions Add Up, Harvard Business Review, Haziran IDC, The Financial Impact of Business Analytics EB 5408 > 1007 > SAYFA 3/18

4 Bilişim Direktörünün (Chief Information Manager CIO) En Önemli Görevi Yaygın BI konuşlandırılmasının en zorlu kısmı, işletmenin BI hakkındaki düşüncelerini değiştirmektir. CIO, değişimin temsilcisi olmalıdır (yeni bakış açısının ve gerekli becerilerin imkanlarını anlatan bir liderin düşüncesine sahip olmalıdır). CIO, işletmenin yöneticileri ve sahipleri ile temasa geçip, onları eğiterek, düşük gecikme sürelerine sahip bilgileri kullanarak, kurumun, kazancı arttırmak ve maliyetleri düşürmek için yeni yolların olduğunu kavramasına yardımcı olmaktadır. Bu süreç genellikle şu soruyla başlar; Eğer tüm çalışanlarımız bütünleştirilmiş analitik bilgilere, ertesi gün değil de dakikalar içinde sahip olsalardı, farklı olarak ne yapardık? İlk adım genellikle, diğer işletmelerin, yaygın BI çözümleri kullanarak, nasıl rekabetçi bir avantaj sağladıkları konusunda kuruluşu eğitmeyi kapsamaktadır. İkinci olarak CIO, BT mimarlarını ve geliştiricilerini, yaygın BI nın başarılı bir şekilde uygulanabileceği konusunda ikna etmelidir. Teknik olarak şüpheci olan birçok kişi, genellikle eski mimarileri ve tasarımları ön plana çıkaracaklardır. Gereken beceriler BT kuruluşu içerisindeki var olmasına rağmen, J2EE/.NET geliştiricileri ve BI mimarları, geçmişte nadiren iş birliği yaptığı görülmüştür. Eski yapılarla çalışan geliştiricilerin kanıt göster şüpheciliği, ilerlemek için mutlaka tatmin edilmelidir. CIO ların kurumsal değişikliklere alışkın olmaları bu durumu kolay hale getirmemektedir. Yaygın BI yı işletimsel uygulamalar ile bütünleştirmenin pahalı ya da devrimsel olması gerekmemektedir. Zamanında ya da doğru zamanda veriyi konuşlandırma konusunda, maliyeti ve riski kontrol altına almanın bir yolu da, veri dağıtımı için doğru gecikme zamanlarını seçmektir. Veri tazeliği seviyeleri, gerçek zamanlı veri depolama çerçevesinde, Pazar aldatmacaları (market hype) yerine, işletme süreçlerine dayandırılmalıdır. Dolayısıyla, verinin doğru zamanda dağıtılması, yeteri kadar taze olan verinin mümkün olan en az maliyetle sağlanması anlamına gelmektedir. Benzer bir şekilde, yaygın BI, tek bir proje ya da harcama değildir. Genellikle birçok küçük yaygın BI projesi yıllar içersinde gelişmiştir (her biri, daha önceden konuşlandırılan altyapı üzerine inşa edilmiştir). Maliyetleri kontrol altına almanın bir başka yolu ise, oluşturulacak altyapı hakkında, mimari bir kaynağa sahip olmaktır. İyi bir mimari kaynak, giderek artacak olan konuşlandırma için bir plan sağlamakta ve geleceği olmayan projeleri en düşük seviyeye indirmektedir. EB 5408 > 1007 > SAYFA 4/18

5 Yaygın BI Kaynaklarının Mimarisi Peki, yaygın BI nedir? Yaygın BI, bütünleştirilmiş doğru zamanlı DW bilgilerini tüm kullanıcılara dağıtma becerisidir (müşteriyle etkileşim halinde çalışanları, sağlayıcıları ve iş ortaklarını kapsayarak). Bir işletmeye tüm süreçlerde her zaman akıllı kararlar almak için gerekli olan görüş kabiliyetini, kavrama becerisini ve olguları sağlamaktadır. Çoğu şirket için bu süreç, var olan BI/DW altyapısını birçok işletimsel iş süreci için karar hizmetleri sağlayarak, geliştirme anlamına gelmektedir. Yaygın BI kaynak mimarisi, var olan altyapıya göre, hem işlem hizmetlerini (örneğin, OLTP) hem de karar alma hizmetlerini tanımlamaktadır. İşletme kullanıcıları, BT altyapısına, web portalları, web uygulamaları, POS terminalleri, self servis kulübeler, elle kullanılan cihazlar ve etkileşimli sesli yanıt sunucuları aracılığıyla ulaşabilmektedirler. yönetimi (ERP), tedarik zinciri yönetimi (SCM) ve daha önce kullanılan uygulamaların bulunduğu yerdir. Veri bütünleştirme hizmetleri, bilgilerin devamlı akışını ve toplu dosya (batch file) verilerin toplanmasını sağlayarak birden çok alan (domain) arasında köprü oluşturmaktadır. İşletimsel bilgi havuzlarından değişen bilgileri alarak, veri bütünleştirme hizmetleri verileri, aktarmakta, ortaya çıkarmakta, iyileştirmekte ve birçok aboneye dağıtmaktadır. Karar havuzları, işletmelerin veri depoları, veri ambarları ve işletimsel veri depolarıdır. Veri bütünleştirme hizmetlerinin sonuçlarını benimseyip sürdürmekte ve geniş çaptaki veri içeriğine yüksek hızda Erişim sağlamaktadırlar. İşlem hizmetleri, işletmeye muhasebe (bookkeeping) işlevi sağlayan uygulamalardır. Bu süreç, geleneksel çağrı merkezi otomasyonu (işletimsel CRM), işletme kaynak Şekil 1. Yaygın BI Kaynak Mimarisi EB 5408 > 1007 > SAYFA 5/1

6 Karar hizmetleri, olguları, şablonları ve işletmenin veri havuzları arasındaki ilişkileri analiz etmek ve uygun bilgileri dağıtmak için kullanılmaktadır. Mimarinin bu kısmı, BI ve veri depolarına erişen uygulamalar üzerine odaklanmaktadır. Bu süreç, pazar bölümlendirmesi, risk analizi, kategori yönetimi, karlılık analizi ve finansal planlama gibi raporlama, veri bulma, taktiksel uygulamalar, işletimsel uygulamalar ve stratejik uygulamaları içermektedir. İşletme uygulama bütünleştirmesine, genellikle, bir İşletme Hizmeti Veri Yolu (Enterprise Service Bus ESB), ileti ara katman yazılımı (messaging middleware), J2EE ve.net geliştirme araçları ve hizmet tabanlı mimari (serviceoriented architecture SOA) kullanılarak erişilmektedir. Bu noktada, bağdaştırıcılar, dönüştürücüler, üstleniciler, yayınlama ve abonelik ve bilgi yönlendirmesi gibi birçok ara katman yazılım hizmeti sürece dahil olmaktadır. Ticari süreç otomasyonu, denetleme ve düzenleme becerilerinin bir toplamıdır. Ticari Süreç Yönetimini (Business Process Management BPM), İşletme Faaliyet Denetlemesini (Business Activity Monitoring BAM) ve İşletme Kural Motorlarını (Business Rules Engines BRE) içermektedir. Bu sistemler, SOA iş akışını yönetmekte, durumları tespit etmekte, uyarılar göndermekte ve işletme kullanıcılarının işletme kurallarını gerçek zamanlı olarak değiştirmelerine olanak sağlamaktadır. EB 5408 > 1007 > SAYFA 6/18

7 Karar Depoları: Aktif Veri Depolaması Geleneksel veri depolaması stratejik karar desteğine odaklanmaktadır. İşletme stratejisini geliştirmek adına, karmaşık varsayım analizleri ile birlikte temel performans göstergelerini (key performance indicators KPIs) anlamak için tek bir gerçek kaynağına sahip olmak, rekabetçi pazar ortamlarında kesinlikle büyük bir öneme sahiptir. Veri arama (data mining) teknikleri çeşitli yollarla işletme stratejine incelik kazandırmaktadır. Örneğin; gelişmiş müşteri bölümlemesi, müşteri kazanılması ve kaybedilmemesi modelleri, mal karışımı optimizasyonu, fiyatlandırma modellemesi ve bunlara benzer diğer uygulamalar. Geleneksel veri depolaması, karar alıcılar tarafından genellikle, pazarlama, finans ve stratejik planlama gibi alanlarda kullanılmaktadır. Stratejik karar desteği, genellikle nispeten daha az sayıda bulunan yüksek kademedeki karar alıcılar tarafından kullanılmaktadır. Bunun aksine taktiksel karar desteği, sahada görev yapan karar alıcıları güçlendirmek için kullanılmaktadır. Her dakika karar alan yüzlerce ya da binlerce kişinin, karlarının kalitesini geliştirmek için doğru bilgilere sahip olması durumunda, bilgi arttırımı en üst seviyeye getirilmiş olur. Taktiksel bir karar, müşteri hizmetleri temsilcisiyle görüşen bir müşteriyle (ücret silinmeli mi yoksa silinmemeli mi?) ya da herhangi bir raydan çıkma arızası durumunda trenlerin tekrar yönlendirilmesiyle alakalı olabilmektedir. Aynı şekilde, taktiksel bir karar belirli bir mağazadaki belirli bir ürün için yapılacak fiyat indirimi ya da bir işletmeyi idare ederken her saat birçok kez karşılaşılan diğer kararlar ile ilişkili olabilmektedir. Tek bir taktiksel karar her ne kadar stratejik olmasa da, günde binlerce kez gerçekleşen bu kararları yürütme yeteneğinin stratejik uygulamalara büyük bir etkisinin olduğu kesindir. İşletmenin veri depolarında yönetilen veri varlıklardan gelen arttırım, verilerin çalışanların kullanımına sunulmasıyla gerçekleşmektedir (sadece kurumsal merkezde görev alanların değil). Ancak, bilgileri sadece olduğu gibi sunmak yeterli değildir. Bilgiler işlemeye uygun olmalı ve iş süreci, aktif veri depolarından gelecek verilerin etkili bir biçimde kullanımına uygun hale getirilmelidir. Taktiksel Kararlar Taktiksel karar desteğinin işletmenin veri deposundan sağlanması, var olan hizmet seviyesi anlaşmalarının tekrar gözden geçirilmesini gerektirmektedir. Veri tazeliği, performans ve kullanılabilirlik, odaklanılması geren üç temel alandır. Geleneksel bir veri deposunda, veriler genellikle periyodik ve toplu olarak güncellenmekte ve zaman aralığı bir günden bir haftaya kadar değişmektedir. Taktiksel bir karar destek ortamında, veriler çok daha sık güncellenmelidir. Örneğin, bugünün satış rakamları stratejik bir karar almak için gerekli olmasa da, güncel satış ve stok rakamlarına ulaşmak, fiyat indirimleri konusunda etkili (taktiksel) kararlar almak için oldukça önemlidir. Taktiksel karar desteği ortamında, toplu veri aktarımı, dönüşümü ve yüklemesi (ETL) süreçlerinin, yavaş ama sürekli veri toplamaya ya da devamlı ufak toplu veri toplamaya geçişi gerektirecektir. Bu süreç, tasarımda, çekiş paradigmasından (toplu zamanlanmış işleri temel alarak) itiş paradigmasına (gerçek zamana yakın durum yakalamasını temel alarak) doğru olan önemli bir geçiştir. Taktiksel bir karar desteği ortamında, destekler de, sorgulama performans hizmeti için yükseltilmiştir. Taktiksel kararlar günde birçok kez alınmaktadır ve bu kararların tutarlılığı büyük oranda zamanında alınmasına bağlıdır. Ömrü aylar ya da yıllar ile ölçülen stratejik kararların aksine, taktiksel kararların ömrü dakikalar hatta saniyelerdir. Bir raydan çıkma durumunda trenlerin nasıl yönlendirileceği, oldukça çabuk alınması gereken bir karardır. Karar alınırken yaşanacak her bir dakika gecikme, daha sonraki tarife gecikmeleri anlamında, büyük ekonomik maliyetler anlamıma gelmektedir. Benzer bir şekilde, web sitesinde müşteriye sunulan bir sonraki en iyi teklifin de hızlı olması gerekmektedir (rekabet sadece üç tıklama uzaktadır). Kararın uygulanmasındaki fırsatın kaybolmaması için, taktiksel kararlar saniyeler ya da dakikalar içinde yapılmalıdır. Kuşkusuz ki, taktiksel bir karar, stratejik bir karara göre genellikle daha dar bir çerçeveye odaklanmaktadır. Dolayısıyla, taranması, sınıflandırılması ve analiz edilmesi gereken daha az veri mevcuttur. Ancak taktiksel kararlar kesinlikle basit değildir. Trenlerin tekrar yönlendirilmesi birçok etmene bağlı olacaktır. EB 5408 > 1007 > SAYFA 7/18

8 Örneğin, tren vagonlarının bir önceki günkü yerlerinde olmamasından kaynaklanan domino etkileri, yükün beklenenden geç gelmesinin müşteri üzerindeki etkilerinin değerlendirilmesi, etkilenen müşterilerin göreceli karlılığı, tarihi belli olan yüklemelerin teslimat esnekliği gibi, çok karmaşık bir optimizasyon sorununa dönüşmektedir. Her ne kadar stratejik karar desteğinden daha seçici veri erişimi söz konusu olsa da, yüksek sayıdaki müşteriler, yüklemeler ve varlıklar bulunduğundan dolayı, incelenmesi uzun sürmektedir. Buna ek olarak, taktiksel karar desteğinde sorgulamanın yürütülmesi sırasındaki aynı anda kullanım seviyesi, genellikle, stratejik karar desteğinden daha büyüktür. Şimdi, stratejik ve taktiksel karar desteği sorgularının işletme veri deposunda beraber bulunduğunu düşünün. Şüphesiz, her sınıftaki iş yükü için belirgin hizmet seviyelerine ihtiyaç duyulacaktır. İş yükünün türüne göre, bilgisayar kaynaklarının her sorguya farklı bir biçimde tahsis edilmesi gerekecektir. Karışık İş Yüklerini Önceliklendirmek Sadece stratejik karar desteğine odaklanan veri depoları için, kaynakları yönetmek genellikle, eş zamanlı uygulamalara bazı en üst sayıdaki sorgulara kadar izin vermek anlamına gelmektedir. Çoğu uygulamada, tüm sorgulamalar, kaynak tahsisi bakımından aynı seviyede değerlendirilmektedir. Veri depolarının sadece uzun vadedeki kararlara odaklandığı durumlarda, acil cevap ihtiyacı ve akıllı kaynak yönetimi en önemli unsur olmamaktadır. Bu günlerde, veri depolama ortamları çok basit değildir. Oturmuş veri deposu konuşlandırmaları, raporlama, OLAP, özel amaçlı sorgular, veri bulma, sürekli veri yüklemesi, taktiksel karar desteği ve durum tabanlı tetiklenmiş karar yürütme kombinasyonlarını içeren, karışık bir iş yükü ile ele alınmalıdır. Ne yazık ki, çoğu uygulama, kaynakları, karışık iş yükleri için en uygun yolla yönetmemektedir. Şekil 2. Taktiksel Kararlar, Stratejik Kararlar ve Sürekli Yükleme EB 5408 > 1007 > SAYFA 8 /18

9 Oturmuş bir veri deposu konuşlandırmasının esası, karışık iş yüklerinin farklı özelliklerinin çok farklı hizmet seviye gereksinimlerinin bulunmasıdır. İki saatlik hizmet seviyesi gerektiren bir veri arama sorgusu ile iki saniyelik hizmet seviyesi gerektiren taktiksel bir karar desteği sorgusuna, eşit kaynak erişimi öncelliği sağlamak optimal bir süreç olmayacaktır. Önceliklendirme olmaksızın yapılan iki saniyelik taktiksel sorgulama, düşük performans gösteren 200 saniyelik bir sorguya dönüşebilmektedir. İleriye etkili (proactive) kaynak yönetimi çok daha iyi sonuçlar ortaya çıkarmaktadır. İleriye etkili kaynak yönetiminin iki temel özelliği bulunmaktadır: sorgu zamanlaması ve önceliklendirilmiş kaynak tahsisi. Sorgu zamanlaması, sorgunun uygulama için veri tabanı içersine ne zaman serbest bırakılacağını belirlemektedir. Kısa sorgular genellikle anında çalıştırılmakta, yoğun kaynak gerektiren ve esnek hizmet seviyelerine sahip sorgular ise işletim kaynakları boşalıncaya kadar ertelenmektedir. İleriye etkili sorgu zamanlaması, kaynakların aşırı kullanımından kaynaklanan, sunucu tahribatını azaltmaktadır. Maliyet tabanlı optimizasyon aracı tarafından gerçekleştirilen tahminler, zamanlama kararlarlarının temelini oluşturmaktadır. Dinamik önceliklendirilmiş kaynak tahsisi, bir sorgu yürütülmek için zamanlandığında, işletim kaynaklarına erişimi yönetmek için kullanılmalıdır. Makinenin toplam kapasitesi, eş zamanlı yürütülen sorgular arasında paylaştırılmalıdır. Örtüşmeli giriş/çıkış (overlapped I/O) ve CPU kullanımı, RDBMS süreçleri ve görevleri içerisinde, çoğul görevlendirme ve sorguların mikro zamanlaması aracılığıyla yer almaktadır. Bu karmaşık yürütme ortamında, kaynakların nasıl tahsis edileceği, veri depolarının ver tabanlarına uygulanan kaynak tahsisi politikalarına göre gerçekleşmektedir. Birçok bağlantısal veri tabanı, önceliklere göre kaynak tahsisi yönetimi için oturmuş algoritmalardan yoksundur. Bu yüzden, hizmet seviyesi hedeflerini karşılamakta zorlanmaktadırlar. Bazıları, kaynakları iş yüklerine kalıcı olarak tahsisi eden, sabit karışık iş yükü yönetimini kullanmaktadır. Dinamik kaynak önceliklendirmesinin olmadığı durumlarda, görevler işlerini bitirmek için yedekleme yaparken, bazı CPU kaynakları atıl durumda olacaktır. Bu zorlu bilgisayar bilimi sorunu, yaygın BI projelerine kalkışılmadan önce, ayrıntılarıyla anlaşılmalı ve gözden geçirilmelidir. Önemli Görevleri Yürüten Veri Depoları Kullanılırlık, geleneksel veri depolarında, hizmet seviyeleri anlamında genellikle ihmal edilen bir unsurdur. Uzun vadeli stratejik kararlar söz konusu olduğunda, veri deposunun bir günlük çöküşü halinde sorgu yürütülmesinin bir sonraki saate ya da güne kalmasının işletmeye olan ölçülebilir etkisi çok büyük değildir. Ancak aynı şey taktiksel karar desteği için söylenemez. En uygun müşteri ilişkileri kararlarını desteklemek için, gelen müşteri çağrılarının bir sonraki güne kadar ertelenmesi mümkün değildir. Aktif veri depolarının çöküş süresi, kaybolan ticari fırsatlar anlamına gelmektedir. Bu nedenle, en yüksek ticari değerin sağlanması için, planlanmış ya da planlanmamış aksama sürelerinin en aza indirgenmesi gerekmektedir. Aktif veri depolaması, açıkça, yeni nesil karar desteğini oluşturmaktadır. Hem taktiksel hem de stratejik karar desteğinin tek ve tutarlı bir bilgi deposundan sağlanmasının kaçınılmaz faydaları bulunmaktadır. Bunun gibi mimariler, doğal olarak, stratejik gelişme ile işletimsel (operational) yürütmenin aynı hizaya gelmesini desteklemektedir. Ancak birçok durumda, var olan veri deposu mimarisinin tekrar düşünülmesi gerekecektir. Veri tazeliği, performansı ve kullanılırlığı alanlarında daha katı hizmet seviyelerine doğru bir geçiş oldukça önemlidir. İşletme yetkilileri, operasyonlar üzerinde taktiksel karar desteğini bütünleştirmek için gereken, işletme süreçlerinin tekrar tasarlanmasına başlamaya hazır olmayabilirler. Bu tür durumlarda en azından, aktif veri deposu altyapısına kaçınılmaz geçişi öngören bir veri deposu konuşlandırma planı oluşturmak oldukça önemlidir. EB 5408 > 1007 > SAYFA 9/ 18

10 Veri Bütünleştirme Hizmetleri Yaygın BI sağlamak için yapılan herhangi bir kuvvetli strateji, veri bütünleştirmesine yeni bir bakış açısını da beraberinde getirecektir. Yaygın BI, sadece daha geniş bir kitleye taktiksel kavrama yeteneği sağlamaktan ibaret değildir. Aynı zamanda, ihtiyaç duyulan verileri, doğru sıklıkta, gerekli esneklikte ve kalite dağıtan, güvenilir bir mimariyi de gerektirmektedir. Veri Hizmeti Seviyesi Anlaşmaları Nedir (Data Service Level Agreements SLA)? Her girişimin başarısı, veri yeterliliği ve güncellemeler için uygun sıklıkların açıkça belirlenmesine bağlıdır. Bunu, Veri Hizmeti Seviyesi Anlaşmaları (SLA) çerçevesinde düşünmek, kullanıcı beklentilerini ve bütünleştirme altyapısının esas becerilerini ölçmek için oldukça iyi bir yoldur. Bu süreç aynı zamanda, veri sağlayıcıların bilgi çalışanlarının beklentilerini yerine getirmeye nasıl olanak sağladığının değerlendirilmesini de içermektedir. Veri SLA sının birçok unsuru olabilmektedir. Tam bir liste oluşturmasa da, veri tazeliği, veri bütünlüğü ve veri doğruluğu bunlardan en önemlileridir. İyi bir Veri SLA sı, bu unsurların her biri için, beklenen, kabul edilebilir ve kabul edilemez değerlerleri tanımlayacaktır. Aynı zamanda, kullanıcılarla açık bir anlaşma ve önceliklendirilmiş bir dağıtım planını da sağlayacaktır. Her kategori için önemli etmenler şunları içermektedir: Veri Tazeliği Gerçek zamanlı karar alma göz önünde alınıldığında, veri tazeliğine yönelik bir zihniyet değişikliği gerekmektedir. Taze verinin oluşturulduğu ya da değişikliğe uğradığı an dağıtılması, çevikliğe olanak sağlamaktadır. Örneğin işletmeler, finansal işlemlerdeki sahtekarlıklara hızlı bir şekilde müdahale etmek, perakende stoğunun tükenmesi durumunda çabuk cevap vermek ya da araca takılı navigasyon sistemlerine trafik uyarıları göndermek için çevikliğe ihtiyaç duymaktadırlar. İşletmenin hız ihtiyacını" anlamak, mimarların, hangi verinin hangi sıklıkta dağıtılması gerektiğini belirlemesine olanak sağlamaktadır. Her verinin gerçek zamanlı olarak aktarılması gerekmemektedir. Mimarın amacı, yeteri kadar hızlı olmaktır. Bir uçuş iptali durumunda, havayolunun 100 den fazla yolcunun yeni seyahat programını işlemesi için gereken verileri toplaması ve analiz etmesi için sadece birkaç dakikası vardır. Bunu aksine, online bir küresel konumlama sistemi (global positioning system GPS) sağlayıcısı, yol çalışmalarına ve servis yollarına ait verileri gerçek zamanlı olarak edinebilmektedir. Ancak bu bilgileri sadece birkaç saatte bir sisteme eklemekte ve yayınlamaktadır. Yeteri kadar hızlı olma kavramı, gecikmelerin derecesinin kazançlar, maliyetler ve müşteri memnuniyeti gibi performans ölçütleri üzerindeki etkisine bağlı olarak, havayolu ve GPS sağlayıcısı tarafından farklı tanımlanmaktadır. Veri Bütünlüğü Taktiksel kararlar belirli bir çerçeve içerisinde alınmalıdır. Veri çerçevesi, mümkün olan tüm kaynaklardan gelen her uygun verinin derlenmesiyle elde edilmektedir. İleti sıraları, ESB ler ve web hizmetleri gibi gerçek zamanlı bilgi kaynakları, veri sağlamak için, veri depolarına bağlanmalıdır. Bilgiler aynı zamanda, SWIFT, HIPAA, X12, EDIFACT gibi XML bilgi alışverişi formatlarından (interchange formats) hatta Word, Excel ve PDF gibi PC dokümanlarından aktarılmalıdır. Yapısal olmayan bu veri formatları, yaygın BI için yapılan veri bütünleştirmesi planına dahil edilmelidir. Veri Temizlenmesi ve Veri Doğruluğu Doğru olmayan verilere bağlı kararlar almak en iyi ihtimalle, riskli bir öneridir. Gerçek zamanlı ulaşan ve gerçek zamanlı kullanılan veriler, doğal olarak gerçek zamanlı temizlenmelidir. Bu süreç, verilerin gerçek zamanlı olarak temizlenmesi, gereksiz ve hatalı eylemlerin önüne geçmek adına oldukça önemlidir. Veri bütünleştirme platformu, tüm veri kaynaklarından gelen verileri, standartlaştırma, temizleme ve eşleme becerisine sahiptir. Bu sayede, tüm uygun veriler veri depoları boyunca birbirine bağlanmış ve çoğaltılmamış olmaktadır. Örneğin, veri bütünleştirmesi alt sistemi, veri kalitesi kurallarını kullanarak, yetkililere, muhtemel bir sahtekarlık, kimlik hırsızlığı ve kara para aklama konusunda gerçek zamanlı olarak rapor verebilmekte ve yetkilileri uyarabilmektedir. Bilgisayar korsanları ve gelişmiş suç şebekelerinin yoğun olduğu bu dönemde, hızlı müdahale süresi, kuruluşların büyük mali kayıplara ya da yasal ve diğer zararlara maruz kalmalarını engellemeye yardımcı olabilmektedir. Veri SLA sının diğer kısımlarında olduğu gibi, veri kategorilerinin temizlenmesi için yapılacak yatırım, o verinin işletme değerine göre ayarlanmalıdır. EB 5408 > 1007 > SAYFA 10/18

11 Veri SLA sına Nasıl Ulaşırız? Veri SLA sına ulaşmak için dört temel gereksinim mevcuttur: Gerçek zamanlı veri toplama, mikro grup (micro batch), değişmiş verinin yakalanması ve gerçek zamanlı dayanıklılık. Gerçek Zamanlı Veri Toplama Gerçek zamanlı veri toplama, veriyi çıkış noktasından veri tabanına, üç yöntemden biriyle atmaktadır: İleti gönderme, değişmiş verinin yakalanması ya da web hizmetleri. İletiler, ileti sıraları, EAI ya da ESB ara katman yazılımları aracılığıyla dağıtılmaktadır (Kaynak Mimarisi şekline bakınız). Göz önünde bulundurulması gereken iki önemli özellik, gerçek zamanlı bilgileri idare etmenin semantikleri ve ileti gönderme hizmeti seviye anlaşmalarına dahil olmaktır. İleti gönderme sistemleri ile temel bütünleştirme, her zaman devam eden veri bütünleştirme sistemleri için oldukça basittir. Ancak, gerçek zamanlı kaynaklar, toplu kopyalarının eşleri gibi işlem görememektedirler. Gerçek zamanlı verilerin işlenmesi, toplu işlemlerde olduğu gibi grup tabanlı işlemlerin benzer türlerini (bir araya getirme, bağlama ve derecelendirme) sağlamak için, veri bütünleştirme motorlarına ihtiyaç duymaktadır. Bu süreç, veri sonu işaretlerini (end of data markers) beklemek için tasarlanmış bütünleştirme motorları için genellikle, oldukça tehlikeli olmaktadır. Bunun aksine, doğru gerçek zamanlı veri bütünleştirme motorları grup tabanlı semantikleri veri akışına gönderebilmektedir. Bu süreç, geçen süre, ileti sayısı, veri işaretleri ya da iletiler arasındaki gecikmeler ile veri pencerelerini tanımlamak anlamına gelmektedir. Garantili İleti Dağıtımı (Guaranteed Message Delivery GMD) zincirleri, ileti alındı bildirimleri ve geri alma becerilerini sağlamak için tüm sistemlerin dahil olmasını gerektirmektedir. Tek bir iletiyi dağıtmak nispeten daha basittir: bir mesaj alınır, dönüştürülür ve hedef RDBMS içerisine gönderilir. Veri başarılı bir şekilde teslim edildiğinde, ileti sitemine alındı bildirimi gönderilmektedir. Veri bütünleştirmesi platformu, grup kayıtları ile uğraştığı zaman, çoklu iletileri, birlikte ya da ayrı ayrı dağıtılması ve alındı bildirimi gönderilmesi gereken atomik birimler gibi ele almalıdır. Şekil 3. Veri SLA sına Ulaşmak için Veri Bütünleştirme Hizmetleri EB 5408 > 1007 > SAYFA 11/18

12 Örneğin, 150 kalem ürün içeren bir fatura, üç ileti içerisinde gönderilebilmektedir, ancak hala tek bir iş birimidir. Bütünleştirme sistemi, iş birimindeki hataları ele almak adına, sadece bir kere yaz (örneğin geri almanın uygun olmayan şekilde iptal edilmesi halinde kayıtların çoğaltılmaması) gibi gerekli yazım semantiklerinin ihlalini önlemek için, kendi geri alma günlüğünü tutmalıdır. Tüm bunlar, yaygın BI için veri tazeliği ve bütünlüğünü amaçlamaktadır. Değişmiş Verinin Yakalanması Değişmiş Verinin Yakalanması (Changed Data Capture CDC), veriyi nerdeyse gerçek zamanlı olarak yakalamak için kullanılan diğer bir faydalı yoldur. Genellikle, işlemler veri tabanına uygulandığı zaman, DBMS geri alma günlüklerinden değişikliklerin algılanması yoluyla çalışmaktadır. Değişiklikler aynı zamanda, işletim sisteminin ya da işlem sisteminin, sırasıyla, VSAM ya da IMS durumunda var olması aracılığıyla da yakalanabilmektedir. Değişmiş veriler, CDC hizmetinin abonelerine dağıtılmaktadır. Bu yaklaşım, ileti tabanlı sistemlerde çeşitli avantajlara sahiptir. En başta, kaynak uygulamaları içerisine tamamen kesintisiz olmasıdır. CDC mekanizması aynı zamanda, bozulmalardan ve engellemelerden tamamen izole edilmiştir. CDC sistemleri, ekrandaki verilerin kopyalanmasına (screenscraping) ya da COBOL veya REXX kodlarının değiştirilmesine başvurmaksızın, IMS ve IDMS gibi eski DBMS sistemleri ile çalışabilmektedir. CDC, yaygın BI için, veri tazeliği ve bütünlüğünü desteklemektedir. Mikro Grup (Micro Batch) Modeli Birçok kuruluş, gerçek zamana yakın işlemeye doğru bir adım olarak, bilgilerin sık, küçük ve zamanlanmış çekişini sağlayan mikro grup modeline geçmektedirler. Bu süreç özellikle, dosyaların periyodik zaman aralıklarında oluşturuldukları ve işlemeye uygun hale geldikleri, çağrı detayı kayıtları ya da tıklama akışı verilerinin işlenmesi durumlarında oldukça faydalıdır. Mikro grup, ismine karşın, veri boyutları ve işleme süresine bağlı olarak, çok büyük olabilmektedir. Bu süreç, veri bütünleştirmesi platformunun performansına ve ölçeklendirebilirliğine önemli bir değer katmaktadır. Platform, tek bir SMP sunucusu ya da bir MPP sunucusunun çoklu devreleri üzerindeki, diziler ve işlemler boyunca verileri bölümleyebilen, ardışık düzenli bir mimari sağlamalıdır. Veri platformunun iş yükü yöneticisi, en iyi iş çıkışını elde etmek için, yoğun giriş çıkış talep eden işlemleri yoğun CPU gerektiren işlemlere karşı dengelemelidir. Arama ön belleklerinden ve veri hizmetlerinden faydalanmak adına, ağ ya da işlem atlamalarını en düşük seviyeye getirirken, belirli işlemler için devre benzerliklerini belirleyebilmelidir. Son olarak, hareketli veriyi, hedef veri deposuna optimize etmek için, yerel RDBMS ara yüzlerinden ve yükleyicilerinden faydalanmalıdır. Bu süreç, bağımlı veri ve performans ile daha iyi yan yana yerleştirme adına, bazı işlemleri RDBMS içerisine göndermek için aşağı itişli (push down) optimizasyonun uygulanmasını içermektedir. Gerçek Zamanlı Dayanıklılık Veri bütünleştirme hizmetlerinin güvenirliliğinden emin olmak adına, bir veri bütünleştirme platformu, kesinlikle yüksek derecede kullanırlık için tasarlanmalıdır. Platform, dayanıklılık, yedeğe geçme (failover) ve geri alma becerilerine sahip olmalıdır. Aynı zamanda, etrafındaki DBMS, ileti gönderme, işletim sistemi (OS) ve donanım ortamlarının sağladığı benzer beceriler ile birlikte çalışmalıdır. Dayanıklılık, savunmanın ilk hattıdır. Düşmüş veri tabanı ve ağ bağlantısı, mümkün olduğu takdirde yeniden kurulmalıdır. Yazımlar tekrar denenmeli ve FTP oturumları tekrar başlatılmalıdır. Donanım ve yazılım hataları denetlenmeli ve herhangi bir hatanın tespiti durumunda yedeğe geçme ölçütleri ele alınmalıdır. Peki, aktif haldeki işlerin kesilmesi durumunda ne olur? Bütünleştirme platformu, denetim noktası/tekrar başlatma, dengeleme (compensation) ve en baştan tekrar başlatma özelliklerini içeren otomatik geri alma mekanizması sağlamalıdır. CDC ortamında, kısa süreli kesilmeler için işlemler, kopyalanmış işlem günlüğünün son noktasından devam etmelidir. Kesilme süresinin, geri alma günlüğünün ömründen daha uzun olduğu durumlarda, arşiv günlükleri taranabilmelidir (günlüğü tekrar yapmak). Bu süreç, hem bütünleştirme platformunun hem de veri deposunda meydana gelebilecek uzun süreli kesilmeler için uygulanmaktadır. Sıralama ortamlarındaki uzun kesilmeler, bütünleştirme hizmetleri kullanılabilir donanım devrelerine yedeğe geçerken, değişiklileri kaybetmemek için kalıcı sıralar gerektirmektedir. Veri deposu DBMS indeki uzun süreli kesilmeler, sırasız işlemleri erteleyerek ya da bütünleştirme platformu tarafından verilerin geçici dosya tabanlı devamlı depolara birleştirilmesiyle ele alınmaktadır. EB 5408 > 1007 > SAYFA 12/18

13 Karar Hizmetleri Müşteriyle Etkileşim İçindeki Kullanıcılar için Yaygın BI Geleneksel olmayan BI kullanıcılarının kararlarını geliştirmek için kurumsal verileri arttırmak, yaygın BI için temel unsurdur. Altyapı, tüm potansiyeline ulamak için, sadece ham veriden ya da işlem sistemlerine ait basit bir görüşten fazlasını sağlamalıdır. Veriler, müşteriyle etkileşim halindeki kullanıcıların becerilerine, işletmenin operasyonel ihtiyaçlarına ve tercih edilen yöntem ve cihazlara uyacak şekilde, hem analitik hem de grafiksel olarak dağıtılmalıdır. Bu dönüşümler, işletmenin karar süreçlerini ve SLA'larını tatmin etmek için hızlı bir şekilde gerçekleşmelidir. Bu nedenle, BI platformunun, geniş ve daha çeşitli kullanıcı nüfusu tarafından talep edilen, hizmet seviyelerini, analitik ölçekleri ve esnek dağıtım mekanizmalarını sağlaması gerekmektedir. BI Hizmet Seviyesi Anlaşmaları Yaygın bir BI platformunu başlıca işletim gereksinimleri, ölçeklendirilebilirlik, performans ve güvenilirliktir. Müşteriyle etkileşim halindeki çalışanları, ortakları ve müşterileri kapsayan geleneksel olmayan BI kullanıcılarından oluşan, çok daha geniş bir kullanıcı nüfusu, bu gereksinimlerde kesişmektedir. Bunun bir sonucu olarak, yaygın BI uygulamaları, oldukça çeşitli sorgu iş yükleri üretmektedir. Geleneksel BI kullanıcıları, şirketin hedeflerini denetlemek için, daha çok özet raporlara göre hareket etmektedirler. Bunun aksine, müşteriyle etkileşim halinde kullanıcılar, belirli müşteriler ya da yüklemeler hakkında, anında karar alabilmek için çok küçük detaylara ihtiyaç duymaktadırlar. Bu süreç, işletmenin SLA larına göre dağıtılması gereken, hem geçmişe ait hem de güncel bütünleştirilmiş verileri gerektirmektedir. BI SLA ları aynı anda işlem gören yüksek sayıdaki talepler için nerdeyse her zaman desteğe ihtiyaç duymaktadırlar. Sistemin her tekil talebin ek işleme yükünü en düşük seviyeye getirmesini talep etmektedirler. İlk amaca ulaşmak için, tek bir sunucu içerisindeki birden çok işlemcinin kullanımını optimize eden çoklu kullanım (scalein), sunucu kümelemesi (scale out) ve günümüz sunucu platformlarında yaygın olan tam kullanımlı 64 bit bellek alanları gibi özelliklere sahip, etkili bir BI mimarisi gerekmektedir. Daha sonraki amaçlara ulaşmak içinse, BI platformu, veri deposunun işleme becerileri tamamen arttıran gerçek bir ROLAP 3 yaklaşımı kullanarak, BI sorgulamalarını çözmelidir. ROLAP kavramı genellikle yanlış anlaşılmakta ve BI satıcıları tarafından farklı uygulanmaktadır. Bu duruma bir açıklık getirmek adına, en etkili ROLAP uygulaması (gerçek ROLAP), bir araya getirmeler, hesaplamalar ve görevlerin filtrelenmesi içeren yöntemler ile veri tabanına gönderilen sorguyu çözmekte ve sadece sonucu düzeltmektedir. Bu teknik, orta düzey veri yapılarını ve geçici sonuç gruplarını en düşük seviyeye getirmektedir. Orta düzey veri yapılarının kullanımı, özellikle, gerçek zamana yakın sorgu cevabı gereksinimleri sayesinde, özel amaçlı talepler için, yaygın BI içerisinde her zaman mümkün değildir. Gerçek bir ROLAP yaklaşımı, katlar (cubes) ya da ön bellekler (caches) gibi orta düzeydeki yapılara bağlı kalmaksızın, karmaşık analitik işlevleri hesaplayan, yüksek derecede optimize edilmiş, veri tabanına özgü SQL oluşturmaktadır. Dolayısıyla, BI platformu, nerdeyse gerçek zamanlı taleplerin performans gereksinimlerini karşılamaya devam ederken, hem veri hem de kullanıcı ölçeklendirilebilirliği sağlayabilmektedir. 3 Relational Online Analytical Processing (ROLAP) Şekil 4. BI Platformu Karar Hizmetleri Alt Sistemlerini Güçlendirmektedir EB 5408 > 1007 > SAYFA 13/18

14 Veri bütünleştirme hizmetleri ve karar depolarında olduğu gibi, BI platformu önemli görevler için kullanırlık seviyesi sağlamalıdır. BI Platformu, yüksek kullanılırlığa, değişen yük koşullarına gerçek zamanlı uyum sağlayan, kapsamlı denetleme becerileri, otomatik yönetim, gruplama (clustering) becerileri, yük dengeleme, yedeğe geçme desteği, kendinden ayarlı motorlar aracılığıyla ulaşmaktadır. Yaygın Analitikler Çok daha çeşitli olan kullanıcı nüfusu, daha geniş analitik işlevler ve bilgi biçimleri gerektirmektedir. Bu yüzden, BI platformu, basit ve karmaşık hesaplamalardan veri arama modellerine ve ön görülü analitiklere kadar kapsamlı analitik işlevleri desteklemelidir. Örneğin, işletme analistleri gibi geleneksel BI kullanıcıları, karşılıklı temel neden analizi yürütüp, ön görü analizleri için kapsamlı modeller oluşturabilmektedirler. Müşteriyle etkileşim halindeki kullanıcılar ise, ön görü modellerini, gözle görülemeyen biçimde gerçek zamanlı taktiksel taleplerde kullanmaktadırlar. Neredeyse gerçek zamanlı olan bu veri arama yöntemi temel kullanım olma yönünde ilerlemektedir. Yaygın BI nın en önemli faydası, birleştirilmiş verileri sağlamasıdır. Doğru zamanlı analitikler ve geçmiş verilerin karışımı, çok daha bütün bir resim sunmaktadır. Örneğin, çağrı merkezi temsilcisinin (call center representative CCR) ekranı, müşterinin satın alma geçmişini, ömür değerini ve şirketi bırakma ihtimali puanlarını, bir sonraki en iyi teklif önerilerini, önceki on dakika içindeki web sitesi tıklama özetini birleştirebilmektedir. CCR, müşterinin değerini, nereyi ziyaret ettiğini (tıklama akışı aracılığıyla) ve en iyi eşleme önerilerini anlayarak, herhangi bir sorunu çözmek ve müşteriye sipariş ettiğinden fazlasını satma konusunda en yüksek olasılığa sahip olmaktadır. Geleneksel BI ile son kullanıcılar genellikle, özet verilerle başlayıp, temel nedenleri anlamak ve belirli sorun alanlarını belirlemek için işlem detaylarını incelemektedirler. Yaygın BI ile ise son kullanıcılar genellikle, belirli bir iş sürecini desteklemek için gereken işlem detayları ile başlamakta, kararlarını desteklemek için daha sonra özetler ve geçmiş bilgiler gibi daha geniş analitikler talep etmektedirler. Bu süreç çoğunlukla, gerçek zamana yakın cevap isteyen kullanıcılar için geçerli olan durumdur. Yaygın BI için Dağıtım Mekanizmaları BI platformu, iki temel dağıtım modeli (itme ve çekme push and pull) ve geniş çapta dağıtım mekanizmaları kullanarak, bilgi dağıtım aracı olarak hizmet etmektedir. Çekme modeli çoğunlukla, BI kullanıcılarının tercih etkileri uygulamalar içerisinde sorgulama yaparken kullandıkları bir modeldir. Bunun aksine itme modeli, sistemin kendisi tarafından, kullanıcıları istisna ve/veya kurallara dayanarak uyarması için kullanılmaktadır. Uyarılar aynı zamanda, bir ESB üzerinde doğrudan meydana gelen durumlar tarafından da tetiklenebilmektedir. İki modelde de, yaygın analitikler en uygun dağıtım mekanizmasıyla sunulmalıdır. Dağıtım mekanizmalarının üç ana kategorisi şu şekildedir: Geleneksel BI ara yüzleri, özel (custom) ya da birleşik (composite) BI uygulamaları ve işletimsel ve var olan uygulamalarla doğrudan bütünleştirme. Geleneksel BI ara yüzleri, işletme analistleri ya da yöneticileri gibi geleneksel BI kullanıcılarının web tabanlı raporları ya da performans değerlendirme tabloları için en uygun hale getirilmiştir. E posta dağıtımı ve yakın geçmişte kullanılmaya başlanan, kablosuz BI ara yüzleri gibi, diğer BI ara yüzleri taktiksel bilgi konuşlandırmasının sıkça rastlanan yöntemlerindendir. Her iki yöntem de, bütün bir web ya da istemci/sunucu uygulamasına erişime gerek olmaksızın, kullanıcılara verileri dağıtabilmektedir. E posta ve SMS, gerçek zamanlı uyarıları dağıtmak ve analitikleri büyük kullanıcı kitlelerine sunmak için oldukça uygundur. Örneğin, yöneticilere uyarı iletileri göndermek ya da müşterileri kendilerine özel promosyonlardan haberdar etmek gibi. Birleşik BI uygulamaları, belirli bir grup İşletme sürecini desteklemekte ve operasyonel iş akışını yaygın BI analitikleri ile birleştirmektedir. Karar alıcılara, uygun bilgileri, ilgili operasyonel işlevi ile aynı kullanıcı ara yüzünde sağlamaktadırlar. Böylelikle kullanıcı, karar alabilmekte ve anında uygulayabilmektedir. Birleşik uygulamaları oluşturmanın en etkili yolu, web hizmetleri, hizmet tabanlı mimariler (service oriented architectures SOA) ve Simple Object Access Protocol (SOAP) ve extensible Markup Language (XML) gibi açık standartların kullanılmasıdır. BI platformu, BI işlevselliğinin parçalarını paylaşabilmeli ve aynı zamanda, analitikleri ve uyarıları XML ya da yüksek biçimlendirmeli HTML olarak dağıtabilmelidir. BI platformu, karar hizmetleri ara katman yazılımı rolünü üstlenmektedir. Dolayısıyla, bu yazılımlar gibi, Web Services Description Language (WSDL) ve Universal Description Discovery and Integration (UDDI) kaydını kullanarak, konuşlandırma ve web hizmetlerini barındırma becerilerini içeren, bir web hizmetleri SDK sını da sunmalıdır. Alternatif olarak müşteriler, bir portal sunucusu kullanarak, birleşik uygulamaları bir araya getirebilmektedirler. EB 5408 > 1007 > PAGE 14 OF 18

15 Başarılı Bir Yaygın İş Zekası Uygulaması İçin Önemli Olan Başarı Etkenleri Bu nedenle, BI platformu, JSR 168 ve WSRP portletlerini içeren önde gelen ve açık kaynak portalları için, yaratıcı bütünleştirme sağlamalıdır. İki durumda da, BI platformunun rolü yaygın analitik hizmetleri sunmaktır. Yaygın BI, dağıtım mekanizmalarının üçüncü türü ile var olan işletimsel uygulamalara gözle görünmeden bütünleşmektedir. İşletimsel uygulamalar, yaygın analitikler ile büyütülmektedir. Örneğin CCR, BI içeriğinin dahil olmasıyla genişlemiş var olan destek uygulamasını besleyebilmektedir. Bu yaklaşımın faydası, müşteriyle etkileşim halindeki kullanıcıların, yeni ara yüzü öğrenmeye ihtiyaç duymamasıdır. Ancak, bu yaklaşım, birleşik yaklaşımda olduğu kadar esneklik sağlayamayabilir. Bu seviyedeki bir bütünleştirme,.net ve J2EE ya da giderek daha yaygın hale gelen Flash/Flex kullanılarak geliştirilebilmektedir. BI platformu, Java ve XML gibi yaygın standartlara dayanan zengin API leri ortaya çıkarmalıdır. Aynı zamanda, var olan uygulamalarla bütünleşmeyi sağlamak için, Eclipse ve Flex Builder gibi yaygın IDE ler için eklentiler (plug in) sağlamalıdır. Yaygın BI için Karar Hizmetleri BI platformları, veri bütünleştirme hizmetleri ve karar depoları gibi, gerçek zamanlı işletimsel süreçlerini ve daha geniş kullanıcı kitlelerini desteklemek için hızla yeni beceriler katmaktadırlar. İş zekası, kuruluşun her noktasına işlemeye uygun bilgiler sağlamak için, yüzlerce İşletme sürecine nüfuz etmektedir. Önemli bilgiler farklı kullanıcılara konuşlandırıldığı zaman, BI platformu, SOA uygulamalarına, portallar, performans değerlendirme tablolarına, toplu sistemlere ve diğer ara katman yazılımlarının alt sistemlerine destek sağlamalı ve aynı zamanda geleneksel BI kullanıcılarına zengin ara yüz gruplarıyla hizmet etmelidir. Yaygın BI sisteminin uzun vadedeki faydaları, işletimsel ve geleneksel BI ihtiyaçlarının birleştiği ve altyapının (veri hizmetleri, depolama platformları ve BI platformu) hem stratejik hem de işletimsel uygulamalar için yükseltildiği durumlarda gerçekleşmektedir. Şekil 5. BI Platformunun Dağıtım Araçları EB 5408 > 1007 > SAYFA 15/18

16 Başarı Etkenlerinin Özeti Bir bilgi tedarik zincirini üç temel alt sistem oluşturmaktadır (Veri Bütünleştirme Hizmetleri, Karar Depoları ve Karar Hizmetleri). Veri, ham biçimde başlamakta, son müşteriye ulaşıncaya kadar, dönüşümler, depolama, dağıtım ve paketleme süreçlerinden geçmektedir. Yaygın BI yı desteklemek için, üç unsura da ihtiyaç vardır. Yaygın BI, geleneksel BI tarafından genellikle sunulmayan bir gereksinimi ortaya çıkarmaktadır (üç alt sisteme içerisindeki SLA lar). Bunun sebebi, müşteriyle etkileşim halinde olan kullanıcıların günde 24 saat ve yılda 365 gün, gerçek zamana yakın performans beklentilerine sahip olmalarıdır. Müşterinin, başarısız veya yavaş bir çağrı merkezi ya da web sitesi ile karşılaşması oldukça uygunsuzdur. Bu yüzden, önemli başarı etmenleri, aşağıda yer alan unsurlar için, düzgün SLA lar üzerine odaklanmaktadır: > Veri tazeliği, temizliği, doğruluğu ve bütünlüğü. > Eş zamanlı kullanıcılar bağlamında, dağıtım mekanizmaları tarafından sağlanan ölçeklendirilebilirlik. > Hizmet seviyesi performans hedeflerini sağlamak için karışık iş yükü yönetimi. > Kullanıcının ve analitiğin türüne göre taktiksel sorgu cevabı süresi ölçütleri. > Kullanıcı kitleleri ve dağıtım mekanizmasına göre yüksek kullanılırlık ölçütleri. Bu SLA ların başarılamaması ve karşılanamaması, şirketin kazançlarını, maliyetlerini ve itibarını riske sokmaktadır. ETL komut dosyalarını, şema değişikliklerini ve yeni raporları üretime koyma sürecinin ilk zamanlarında kullanılan plansız araçlar ve süreçler, baştan sona bilgi kullanılırlığını sağlamak için yüksek kalitede testler, güçlü işletim ilkeleri ve yedeğe geçme sistemleri ile değiştirilmek zorundadır. Yaygın BI altyapısı, var olan BT işletimlerinin temeline bütünleştirilmelidir. Diğer önemli başarı etmenleri mimaridir. Esneklik ve çok yönlülük, giderek artan kullanıcı kitleleri ve cihazlar göz önüne alındığında, BT altyapısının geleceği için gereklidir. Çoğu kuruluş, esneklik ve çok yönlülük için portallara ve web hizmetlerine geçmiştir. Aynı şey, gerçek zamanlı veri toplama sürecinin düzenli olarak yeni kaynaklar ve veri türleri barındırmak zorunda olduğu veri bütünleştirme sistemleri için de geçerlidir. Çoğu şirket için yaygın BI bir sonraki adımdır. Var olan ETL araçları veri bütünleştirme sunucularına dönüşmekte, var olan veri depoları aktif hale getirilmekte ve var olan BI platformları kendilerini karar hizmetleri olarak yenilemektedir. Bunun sağlanabilmesi için gerekli olan, performans taleplerinin ve Aktif Veri Depolarının çok önemli olan baştan sonra kullanılırlık gereksinimlerini tanımlayan yeni bir hizmet seviyesi grubudur. İyi tanımlanmış SLA lar, tasarım hedeflerine açıklık getirmekte ve dikkatli işletme yöneticilerinin, taze veri ve rekabetçi avantaj arasındaki noktaları birleştirmelerine olanak sağlamaktadır. EB 5408 > 1007 > SAYFA 16/18

17 Sözlük Aktif Veri Deposu (Active Data Warehouse) Aktif bir veri deposu (ADW) geleneksel veri deposunun genişletilmiş şeklidir. İşletimsel zeka sağlamak için güncel veriler ile geçmiş verilerin birleştirmektedir. ADW, sorgu cevap süreleri için öngörülebilir hizmet seviyeleri ile karar almak, gerçek zamana yakın veri tazeliği ve çok önemli verilerin kullanılabilirliği için, tek gerçek kaynak olan hizmet eden işletmenin ver deposundaki karışık iş yüklerini desteklemektedir. Buna ek olarak, ADW, kuruluşun her yönüne karar hizmetleri sağlamak için, işletmenin tüm mimarisine bütünleştirilmektedir. BI platformu İşletmenin bilgi çalışanları ve karar havuzları arasındaki bir orta katman sunucusu ve hizmetler bütünüdür. Talepleri işlemekte ve sonuçları uygun bir son kullanıcı cihazına dağıtmaktadır. İş Zekası Eğilimleri ve şablonları ayırt etmek adına, yapısal, alan tabanlı bilgileri araştıran ve analiz eden etkileşimli bir süreçtir. Bu sayede, kavrama becerileri elde edilmekte ve sonuçlar ortaya çıkmaktadır. Veri ambarı (Data mart) Genellikle bir bilgi havuzuna yerleştirilmiş, önceden bağlanmış ve yüksek derecede birleştirilmiş işletme verilerin bir alt kümesidir. Belirli uygulamaların veri analizi gereksinimlerini desteklemektedir. Veri Deposu (Data Warehouse) Bir işletmenin geçmiş bilgilerini içeren başlıca bilgi havuzudur. Bu bilgi havuzu, geniş çaplı analitikler ve raporlama için kullanılmaktadır. Yönetimin karar destek hizmeti için ham maddeleri içermektedir. Veri deposunun kullanımına öncülük eden en önemli etmen, veri analistinin karmaşık sorgular ve analizler yapabilmesidir. İşletme hizmet veri yolu (Enterprise service bus) İşletme hizmet veri yolu (ESB), süreçler arası iletişimi ve uygulama etkileşimlerini destekleyen bir ara katman yazılımıdır. ESB ler, SOAP/HTTP, SOAP/MOM gibi programdan programa iletişim protokollerini ve ileti tabanlı orta katman yazılımlarını sunmaktadır (MOM ya da MQ). ESB ler, XML,WSDL, BPEL,WS Addressing ve WS Security i de içeren web hizmeti standartlarına destek sağlamaktadırlar. Aktarma, dönüştürme ve yükleme (Extraction, transformation, and loading) Aktarma, dönüştürme ve yükleme (ETL), veri depoları içerisinde, dış kaynaklardan verileri aktaran, işletme ihtiyaçlarına uyacak şekilde dönüştüren ve sonunda, veri deposu, veri ambarı, OLAP katı ya da diğer yapılar gibi, veri havuzları içerisine yükleyen bir süreçtir. Bütünleştirilmiş geliştirme ortamı (Integrated development environment) Bütünleştirilmiş bir geliştirme ortamı (IDE), programlama, hata ayıklama (debugging), test etme ve yazılım uygulamaları konuşlandırması için çeşitli araçları ve özelikleri içeren, bir programcı çalışma alanıdır (workbench). Bir IDE, aynı zamanda, geliştirme çerçevelerini, Proje yönetimini, yazılım yapılandırma yönetimini ve bileşen tasarımını ve birleştirmesini içerebilmektedir. J2EE (Java 2 İşletme Sürümü Enterprise Edition) J2EE, Java programlama dilinde, sunucu programlaması için sıkça kullanılan bir platform ve özelliktir. J2EE, JDBC, RMI, e posta, JMS, web hizmetleri ve XML gibi çeşitli API özelliklerin içermekte ve nasıl düzenleneceğini tanımlamaktadır. Java EE aynı zamanda, Enterprise JavaBean ler, servletler, portletler ve Java Sunucu Sayfaları için özellikler de içermektedir. Temel performans göstergeleri (Key performance indicators) Temel performans göstergeleri (KPI lar), bir kuruluşun stratejik performansını ölçmek için kullanılan, finansal ve finansal olmayan ölçütlerdir. KPI lar, iş zekasında, işletmenin var olan durumunu değerlendirmek ve hareket tarzını belirlemek için kullanılmaktadırlar. EB 5408 > 1007 > SAYFA 17/18

18 Microsoft.NET Çerçevesi Microsoft.NET Çerçevesi, Microsoft Windows işletim sistemine eklenebilen ya da dahil olan bir yazılım bileşenidir. Yaygın program gereksinimlerine önceden kodlanmış geniş çözümler getirmekte ve çerçeveye özgü yazılmış programların çalıştırılmasını yönetmektedir. Yoğun paralel işleme (Massively parallel processing) Çok yüksek kalitede bilimsel ve ticari uygulamaları çözmede, çok sayıda (yoğun) gevşek bağlı (looselycoupled) işletim sunucusunun birlikte çalışmasına olanak sağlayan, yüksek performanslı bir işletim mimarisidir. MPP mimarisinin tanımlayıcı özelliği, binlerce CPU nun birlikte çalışarak tek bir büyük uygulama sorununu, doğrusal ölçeklendirilebilirlik ile çözmesine olanak sağlayan, paralel bir yazılım ve ölçeklenebilir anahtarlama ara bağlantısı olmasıdır. Portletler Bir portal içerisinde çalışan Java ya da.net servletleridir. Düşük seviyede, noktadan noktaya bileşenler, uygulama programlama ara yüzlerine, URL lere (uniform resource locators) ya da yapısal sorgu diline (structured query Language) erişim sunmaktadır. Aşağı itimli optimizasyon (Push down optimization) Çoğu zaman bir SQL komutu ya da maddesi şeklinde olan veri dönüşümünün, veri bütünleştirme sunucusu yerine, yürütüleceği RDBMS nin içerisine gönderen, bir veri bütünleştirme tekniğidir. İş Zekası, aynı zamanda, görevleri ve işleri de özetleme ya da formüller şeklinde RDBMS nin içerisine itmektedir. Ölçeklenebilir RDBMS yazılımı güçlü bir sunucu üzerinde olduğu durumlarda, işleme süresi, aşağı itim olmaksızın uygulanan durumlara göre, büyük ölçüde daha hızlı gerçekleşmektedir. Hem Informatica hem de MicroStrategy aşağı itim becerisine sahiptir. Teradata ise ölçeklenebilir RDBMS platformu sağlamaktadır. Relational online analytical processing Relational online analytical processing (ROLAP) araçları, ANSI uyumlu bir RDBMS e karşı yürütülen SQL sorgularını oluşturmaktadır. Böylelikle, bilgileri çok amaçlı özet bir tablo biçimine özetlemekte ve hesaplamaktadırlar. ROLAP, bilgi çalışanlarının erişimi için verileri özel katman bilgi havuzlarına önceden özetleyen MOLAP (Çok amaçlı OLAP Multidimensional OLAP) uygulamalarına göre, daha ölçeklendirilebilir bir alternatiftir. Simetrik çoklu işlemci (Symmetric multi processor) Simetrik bir çoklu işlemci (SMP), çoklu CPU ları bellek ve disk kaynaklarına paylaşımlı erişim ile düzenleyen bir işletim mimarisidir. Hizmet tabanlı mimari (Service oriented architecture) Hizmet tabanlı bir mimari (SOA), hizmet tüketicileri için istenilen sonuçlara ulaşma talebi (son kullanıcılar ya da diğer hizmetler) durumunda, işletme ve işletim kaynaklarını (öncelikle kuruluşlar, uygulamalar ve veriler) bağlayan bir tasarımdır. OASIS, SOA yı şu şekilde tanımlamaktadır; Farklı sahiplik alanlarının (ownership domains) denetimi altında olabilen becerileri düzenleyen ve dağıtan bir değerler dizisidir (paradigm). Sağlamak, ortaya çıkarmak ve etkileşim kurmak için tek bir biçim ve ölçülebilir önkoşullarla ve beklentilerle tutarlı istenilen etkileri üretmek için kullanım becerileri sağlamaktadır. Simple object access protocol Bir simple object access protocol (SOAP), genellikle HTTP/HTTPS kullanarak, bilgisayar ağları üzerindeki XML tabanlı iletileri çeviren bir protokoldür. SOAP, üzerine daha soyut katmanların oluşturulabileceği temel ileti çerçevesi sağlarken, Web hizmetleri çatısının kuruluş katmanını biçimlendirmektedir. Genişletilebilir biçimlendirme dili (Extensible markup language) Genişletilebilir biçimlendirme dili (XML), kullanıcılarının kendi etiketlerini tanımlamalarına olanak sağlayan, genel amaçlı bir biçimlendirme dilidir. Başlıca amacı, farklı bilgi sistemleri (özellikle de Internet) boyunca verilerin paylaşılmasını kolaylaştırmaktır. Standard genelleşmiş biçimlendirme dilinin (standard generalized markup language SGML), basitleştirilmiş bir alt kümesidir ve nispeten insanların okumasına daha uygun olarak tasarlanmıştır. Informatica, Informatica Corporation ın tescilli markasıdır. MicroStrategy, MicroStrategy, Inc in tescilli markasıdır. Teradata, Teradata Corporation ın tescilli markasıdır. Bu yayının hiçbir parçası, yazılı izin olmaksızın çoğaltılamaz ve kullanılamaz. Telif Hakları 2007 Informatica Telif Hakları 2007 MicroStrategy Telif Hakları 2007 Teradata Corporation Tüm Hakları Saklıdır. A.B.D. de üretilmiştir. EB 5408 > 1007 > SAYFA 18/18

19