SQL Server 2008 R2'nin November CTP'si (Community Technology Preview) çıktı. İlk bağlantı R2 için, ikinci bağlantı ise Feature Pack'i için...
http://www.microsoft.com/downloads/details.aspx?FamilyID=fe0c6a31-5ad6-4eea-a865-73bbe2608bd1&displaylang=en
http://www.microsoft.com/downloads/details.aspx?familyid=020EE0D5-BCE4-4A45-9D64-B0C49C8831E5&displaylang=en
19 Kasım 2009 Perşembe
09 Eylül 2009 Çarşamba
Ortak boyut (conforming dimension) kullanımında bir ipucu
Veri ambarı ve küp tasarımında en önemli ilkelerden birisi, farklı fact tablolarında aynı bakış açısını yani boyutu kullanıyorsak, bunlar için ortak bir boyutun kullanılmasıdır.
Yani bir ürün boyutunuz varsa, ürünle ilgili tüm fact tabloları aynı ürün boyutuna bağlı olsun istenir. Ya da bir zaman boyutunuz varsa, zamanla ilgili tüm fact tabloları aynı zaman boyutuna bağlı olsun istenir.
Peki ya bazı fact'lerinizin zaman kırılımı ay, bazı factlerinizin zaman kırılımı ise çeyrekse? O zaman ne yapacaksınız?
Veritabanı kurallarına göre düşünecek olursanız, fact tablolarında foreign key ataması yapmak için karşılık tabloda primary key ya da unique constraint ataması yapmanız gerekir. Zaman tablosunda diyelim ki en küçük kırılımınız ay olsun. AyID'yi primary key yapabilirsiniz. Peki ya çeyreğe bağlı fact için foreign key atamasını nasıl yapacaksınız. Bir ÇeyrekID kolonunuz olabilir, ama satırlarda doğal olarak tekrar edeceği için (aynı çeyrekte üç ay var) bu kolonu unique yapamazsınız. Bu durumda da foreign key yapamazsınız!
Ama... Veritabanı kısıtlarıyla düşünmeyi bırakın. Bir iş zekası çözümü gerçekleştiriyorsunuz ve küplerin dünyasındasınız. Kübün data source view'inde bu tür karşılığı unique olmayan bir foreign key ilişkisi oluşturabilirsiniz. Ardından da bir fact'te zaman boyutunu AyID bazında bağlarken diğerinde ÇeyrekID bazında bağlantı yapabilirsiniz.
Küçük bir ipucu: Küplerin dünyasında bir boyutla bir fact arasında many to many ilişki de tasarlayabilirsiniz. Bunu daha önceki bir yazımda anlatmıştım.
DÜZELTİ:
Yukarıda ufak bir hata var. Anlatılan ilişki kurma şekli yapılabiliyor ama sonucu biraz farklı. Bu yaklaşımla da yine many to many ilişki kurmuş oluyorsunuz.
Şöyle bir durum düşünün: Haftalık nöbet ataması yapıyorsunuz. Ama günlük olarak nöbetleri sayıyorsunuz. Yani atamalarda nöbet hafta bazında bağlı olsa da bir haftaya bağladığınızda o değer alttaki günler için de tekrar etmeli. Bu durumda tarih boyutunda haftaID alanıyla data source view üzerinden bir ilişki kurabilirsiniz. Kübün içinde dolaşırken, gün bazında bu ilişkiye girerseniz, atama bilgisinin altındaki günlerde tekrar ettiğini görürsünüz. Yani bir yedi olur.
Peki yapmak istediğiniz gerçekten bir fact'te zamanla gün bazında, bir başkasında ise hafta kırılımında ilişki kurmaksa ne yapacaksınız. Çözüm yine data source view'de. Hafta bazında kırılımın kolonlarını içeren bir named query yaratın. Aynı zaman tablosundan türetildiği için veri yüklerken tek bir tabloyu yüklemeniz yeterli olacak ve bir update her iki boyutu beraber etkileyebilecektir
Üstelik günlük boyutunuzda haftaID'yi de bulundurup, bu boyutu haftalık fact'le haftaID attribute'ü ve haftalık boyut üzerinden haftalık fact'le de ilişkilendirebilirsiniz. Böylelikle haftalık fact ve günlük fact'ten measure'ları, haftadan aşağıya inmemek koşuluyla aynı raporda yanyana getirebilirsiniz.
Belki biraz karışık oldu ama bu konuyla ilgili kafa yormanız gerekmişse, çözümü anlayacağınızı düşünüyorum. Çözmeniz gereken bir sorunsa ve yazdıklarımı anlamadıysanız, bir yorum bırakın bu yazıma. Anlamadığınız noktaları belirtin. Açıklama yaparım.
Yani bir ürün boyutunuz varsa, ürünle ilgili tüm fact tabloları aynı ürün boyutuna bağlı olsun istenir. Ya da bir zaman boyutunuz varsa, zamanla ilgili tüm fact tabloları aynı zaman boyutuna bağlı olsun istenir.
Peki ya bazı fact'lerinizin zaman kırılımı ay, bazı factlerinizin zaman kırılımı ise çeyrekse? O zaman ne yapacaksınız?
Veritabanı kurallarına göre düşünecek olursanız, fact tablolarında foreign key ataması yapmak için karşılık tabloda primary key ya da unique constraint ataması yapmanız gerekir. Zaman tablosunda diyelim ki en küçük kırılımınız ay olsun. AyID'yi primary key yapabilirsiniz. Peki ya çeyreğe bağlı fact için foreign key atamasını nasıl yapacaksınız. Bir ÇeyrekID kolonunuz olabilir, ama satırlarda doğal olarak tekrar edeceği için (aynı çeyrekte üç ay var) bu kolonu unique yapamazsınız. Bu durumda da foreign key yapamazsınız!
Ama... Veritabanı kısıtlarıyla düşünmeyi bırakın. Bir iş zekası çözümü gerçekleştiriyorsunuz ve küplerin dünyasındasınız. Kübün data source view'inde bu tür karşılığı unique olmayan bir foreign key ilişkisi oluşturabilirsiniz. Ardından da bir fact'te zaman boyutunu AyID bazında bağlarken diğerinde ÇeyrekID bazında bağlantı yapabilirsiniz.
Küçük bir ipucu: Küplerin dünyasında bir boyutla bir fact arasında many to many ilişki de tasarlayabilirsiniz. Bunu daha önceki bir yazımda anlatmıştım.
DÜZELTİ:
Yukarıda ufak bir hata var. Anlatılan ilişki kurma şekli yapılabiliyor ama sonucu biraz farklı. Bu yaklaşımla da yine many to many ilişki kurmuş oluyorsunuz.
Şöyle bir durum düşünün: Haftalık nöbet ataması yapıyorsunuz. Ama günlük olarak nöbetleri sayıyorsunuz. Yani atamalarda nöbet hafta bazında bağlı olsa da bir haftaya bağladığınızda o değer alttaki günler için de tekrar etmeli. Bu durumda tarih boyutunda haftaID alanıyla data source view üzerinden bir ilişki kurabilirsiniz. Kübün içinde dolaşırken, gün bazında bu ilişkiye girerseniz, atama bilgisinin altındaki günlerde tekrar ettiğini görürsünüz. Yani bir yedi olur.
Peki yapmak istediğiniz gerçekten bir fact'te zamanla gün bazında, bir başkasında ise hafta kırılımında ilişki kurmaksa ne yapacaksınız. Çözüm yine data source view'de. Hafta bazında kırılımın kolonlarını içeren bir named query yaratın. Aynı zaman tablosundan türetildiği için veri yüklerken tek bir tabloyu yüklemeniz yeterli olacak ve bir update her iki boyutu beraber etkileyebilecektir
Üstelik günlük boyutunuzda haftaID'yi de bulundurup, bu boyutu haftalık fact'le haftaID attribute'ü ve haftalık boyut üzerinden haftalık fact'le de ilişkilendirebilirsiniz. Böylelikle haftalık fact ve günlük fact'ten measure'ları, haftadan aşağıya inmemek koşuluyla aynı raporda yanyana getirebilirsiniz.
Belki biraz karışık oldu ama bu konuyla ilgili kafa yormanız gerekmişse, çözümü anlayacağınızı düşünüyorum. Çözmeniz gereken bir sorunsa ve yazdıklarımı anlamadıysanız, bir yorum bırakın bu yazıma. Anlamadığınız noktaları belirtin. Açıklama yaparım.
19 Ağustos 2009 Çarşamba
Veri madenciliğinde model kümesi gerçeği ne kadar iyi temsil ediyor olmalı?
Öncelikle gerçeği iyi temsil etmek ne demek? Buna kafa yormak gerekir.
Diyelim ki, kredi ödemesini geri hiç yapmayacak, geciktirerek yapacak, bir de hiç bir sorun olmadan yapacak kişileri ayrıştırmak istiyorsunuz. Geçmiş deneyimlerinizden yüzde 2 geri ödemeyi hiç yapmayacak, yüzde 5 sorunlu yapacak, yüzde 93 de sorunsuz yapacak insan olacağını biliyorsunuz. Model kümenizde her üç durumla sonuçlanmış kayıt örnekleri bulunmalı. Bu kesin. Her üçünden de yeteri kadar örnek bulunmalı bu da kesin.
Peki bunların oranları gerçekte olduğu gibi mi olmalı? Hayır.
Her üç duruma ilişkin yeterince kayıt olması yeterli. Hatta sorunsuz geri ödeyenlerin oranı üçte bir gibi falan olmalı, yüzde 93 değil.
Biraz kafa karıştırıcı gibi geliyor belki, ama amacınız insanların yüzde kaçının geri ödeme sorunu çıkaracaklarını bulmak değil! Amacınız, kişilerin hangi özelliklerinin kredi geri ödemesinde belirleyici olduğunu bulmak.
Diyelim ki, kredi ödemesini geri hiç yapmayacak, geciktirerek yapacak, bir de hiç bir sorun olmadan yapacak kişileri ayrıştırmak istiyorsunuz. Geçmiş deneyimlerinizden yüzde 2 geri ödemeyi hiç yapmayacak, yüzde 5 sorunlu yapacak, yüzde 93 de sorunsuz yapacak insan olacağını biliyorsunuz. Model kümenizde her üç durumla sonuçlanmış kayıt örnekleri bulunmalı. Bu kesin. Her üçünden de yeteri kadar örnek bulunmalı bu da kesin.
Peki bunların oranları gerçekte olduğu gibi mi olmalı? Hayır.
Her üç duruma ilişkin yeterince kayıt olması yeterli. Hatta sorunsuz geri ödeyenlerin oranı üçte bir gibi falan olmalı, yüzde 93 değil.
Biraz kafa karıştırıcı gibi geliyor belki, ama amacınız insanların yüzde kaçının geri ödeme sorunu çıkaracaklarını bulmak değil! Amacınız, kişilerin hangi özelliklerinin kredi geri ödemesinde belirleyici olduğunu bulmak.
Veri madenciliği başlığı altında hangi tür işler yapılabilir?
Veri madenciliği, reklam etkisi de hayli yüksek olan bir kalıp. Ama acaba ne demek? Veri madenciliği yaparken, aslında hangi alt görevleri gerçekleştiriyoruz.
Bunları şu şekilde sıralayabiliriz:
- Classification
- Estimation
- Prediction
- Affinity Grouping
- Clustering
- Description and Profiling
Terimlerin Türkçelerini tabii ki düşünmeliyiz.
Classification sınıflandırma olarak adlandırılabilir. Clustering ise kümeleme.
Sınıflandırma ve kümeleme birbirlerine bir hayli yakın kavramlar. Ama aralarında önemli bir fark var: Sınıflandırma yaparken elimizde referans sınıflar var ve yeni kayıtların bu sınıflardan hangisine uygun olduğunu tahmin etmeye çalışıyoruz. Kümelendirme yaparken ise elimizde belirli sınıflar yok. Verinin içindeki anlamlı kümeleri bulmaya çalışıyoruz.
Örnek düşünelim. Diyelim ki müşterilerimizin şirkete toplam getirisine göre belirli sınıflarımız henüz yok. Bu durumda kümeleme çalışması yaparak anlamlı sınıflandırma nasıl yapılmalı diye belirlemeye çalışabiliriz. Ama eğer altın, gümüş ve bronz müşteriler olarak zaten bir sınıflama yapmışsak, o zaman yeni müşteri adaylarının hangi sınıfa karşılık geldiğini tahmin etmek için sınıflandırma çalışması yapabiliriz.
Birbirine yakın bir başka kavram ikilisi de Estimation ve Prediction. Estimation'a tahmin, prediction'a ise öngörü diyebiliriz. Ama estimation için tahmin yerine çıkarsama da diyebiliriz. Aralarındaki en önemli fark şudur: Estimation şu an var olan veriler içindeki desenleri tahmin etmek içindir. Prediction ise, şu anki veriler ışığında gelecekteki bir durumu tahmin etmek içindir. Bu fark projenin geliştirilmesini de çok derinden etkiler. Estimation (çıkarsama) yaparken, şu anki verilerin içinde şu an geçerli olan desenleri bulmaya çalışırsınız. Oysa prediction (tahmin) yaparken, verilerin mesela 6 ay önceki hallerinin şu an ne sonuç doğurduğuna bakıp, şu anki verilerin 6 ay sonra ne sonuç doğuracağını tahmin etmeye çalışırsınız.
Estimation ve Classification arasında da bir hayli benzerlik var. Burdaki farkı bir örnekle anlatmak daha iyi olacak:
Diyelim ki kredileri risk açısından değerlendiriyorsunuz. Eğer risk sınıfları oluşturup kredileri bunlara eşlemeyi düşünüyorsanız, classification yapıyorsunuz demektir. Bunun yerine tüm krediler için 1-100 arasında bir risk puanı verecekseniz, estimation yapmanız gerekir.
Affinity Grouping Association Rules olarak da adlandırılabilir. Birliktelik kuralları olarak çevirebiliriz. Neler birlikte olur? Hangisi hangisini tetikler? Hangi ürün diğer ürününün satışını tetikler? Hangi suçlar bir arada işlenir? Bu gibi soruların yanıtı aranır bu görev tipinde.
Profiling ise, profil çıkarımı olarak düşünülebilir. 40 yaş üstü ekonomik durumu iyi bayanların oy verirken yoğunlukla belirli bir partiyi tercih etmesi bir profil örneği olarak verilebilir.
Bunları şu şekilde sıralayabiliriz:
- Classification
- Estimation
- Prediction
- Affinity Grouping
- Clustering
- Description and Profiling
Terimlerin Türkçelerini tabii ki düşünmeliyiz.
Classification sınıflandırma olarak adlandırılabilir. Clustering ise kümeleme.
Sınıflandırma ve kümeleme birbirlerine bir hayli yakın kavramlar. Ama aralarında önemli bir fark var: Sınıflandırma yaparken elimizde referans sınıflar var ve yeni kayıtların bu sınıflardan hangisine uygun olduğunu tahmin etmeye çalışıyoruz. Kümelendirme yaparken ise elimizde belirli sınıflar yok. Verinin içindeki anlamlı kümeleri bulmaya çalışıyoruz.
Örnek düşünelim. Diyelim ki müşterilerimizin şirkete toplam getirisine göre belirli sınıflarımız henüz yok. Bu durumda kümeleme çalışması yaparak anlamlı sınıflandırma nasıl yapılmalı diye belirlemeye çalışabiliriz. Ama eğer altın, gümüş ve bronz müşteriler olarak zaten bir sınıflama yapmışsak, o zaman yeni müşteri adaylarının hangi sınıfa karşılık geldiğini tahmin etmek için sınıflandırma çalışması yapabiliriz.
Birbirine yakın bir başka kavram ikilisi de Estimation ve Prediction. Estimation'a tahmin, prediction'a ise öngörü diyebiliriz. Ama estimation için tahmin yerine çıkarsama da diyebiliriz. Aralarındaki en önemli fark şudur: Estimation şu an var olan veriler içindeki desenleri tahmin etmek içindir. Prediction ise, şu anki veriler ışığında gelecekteki bir durumu tahmin etmek içindir. Bu fark projenin geliştirilmesini de çok derinden etkiler. Estimation (çıkarsama) yaparken, şu anki verilerin içinde şu an geçerli olan desenleri bulmaya çalışırsınız. Oysa prediction (tahmin) yaparken, verilerin mesela 6 ay önceki hallerinin şu an ne sonuç doğurduğuna bakıp, şu anki verilerin 6 ay sonra ne sonuç doğuracağını tahmin etmeye çalışırsınız.
Estimation ve Classification arasında da bir hayli benzerlik var. Burdaki farkı bir örnekle anlatmak daha iyi olacak:
Diyelim ki kredileri risk açısından değerlendiriyorsunuz. Eğer risk sınıfları oluşturup kredileri bunlara eşlemeyi düşünüyorsanız, classification yapıyorsunuz demektir. Bunun yerine tüm krediler için 1-100 arasında bir risk puanı verecekseniz, estimation yapmanız gerekir.
Affinity Grouping Association Rules olarak da adlandırılabilir. Birliktelik kuralları olarak çevirebiliriz. Neler birlikte olur? Hangisi hangisini tetikler? Hangi ürün diğer ürününün satışını tetikler? Hangi suçlar bir arada işlenir? Bu gibi soruların yanıtı aranır bu görev tipinde.
Profiling ise, profil çıkarımı olarak düşünülebilir. 40 yaş üstü ekonomik durumu iyi bayanların oy verirken yoğunlukla belirli bir partiyi tercih etmesi bir profil örneği olarak verilebilir.
Data Mining (veri madenciliği) konusunda kitap tavsiyesi
Wiley'den çıkmış olan Data Mining Techniques Second Edition for Marketing, Sales, and Customer Relations Management çok iyi bir kitap. Yazarları Michael J. A. Berry ve Gordon S. Linoff.
Blogda ileride yazacağım bazı girdilerde kaynak olarak da yararlanacağım önemli bir kitap. Her seferinde kaynak belirtmeyebilirim yazılarımda, ama tamamen alıntı niteliğinde birşeyler yazarsam, tabii ki belirtmiş olurum. : )
Blogda ileride yazacağım bazı girdilerde kaynak olarak da yararlanacağım önemli bir kitap. Her seferinde kaynak belirtmeyebilirim yazılarımda, ama tamamen alıntı niteliğinde birşeyler yazarsam, tabii ki belirtmiş olurum. : )
17 Ağustos 2009 Pazartesi
SQL Server 2008 R2
SQL Server 2008 R2'nin Ağustos CTP'si (Community Technology Preview) indirime hazır.
İlgili bir yazıyı şu adresten okuyabilir ve aynı yazıdan indirme bağlantılarına ulaşabilirsiniz:
http://redmondmag.com/articles/2009/08/10/microsoft-offers-sql-server-2008-r2-test-bits.aspx
İlgili bir yazıyı şu adresten okuyabilir ve aynı yazıdan indirme bağlantılarına ulaşabilirsiniz:
http://redmondmag.com/articles/2009/08/10/microsoft-offers-sql-server-2008-r2-test-bits.aspx
30 Haziran 2009 Salı
İş zekası projeleri için önemli bazı başlıklar
Her projede ele alınması gereken konular vardır. İster kişisel bir çalışma yapın, ister büyük bir kamu kurumu için beş yıllık bir projeye giriyor olun, bazen sadece düşünce seviyesinde bazen yüzlerce yazılı sayfa şeklinde ele almanız gereken konular vardır.
Biz de bu unsurlardan bazıları açısından iş zekası projelerini inceleyelim:
PROJE GETİRİLERİ (ya da hedefleri)
Finansal sonuçların yanısıra finansal olmayan sonuçlar da hedeflenebilir.
Sektörüne, içeriğine ve şirketin yaklaşımına bağlı olarak değişiklikler göstermesi mümkün olmakla birlikte iş zekası projelerinden beklenebilecek bazı hedefleri sıralayalım. Tabii ki bu liste bütüncül değil, yani olası tüm getirileri listelemiyor. Ama size bir fikir verebilir:
- Şirket gelirlerinin daha iyi anlaşılıp artırılabilmesi.
- Şirket maliyetlerinin daha iyi anlaşılıp azaltılabilmesi.
- Müşteriler, çalışanlar, departmanlar gibi unsurların özellikleri bazında performans açısından incelenebilmesi sonucu, müşteri ödül programlarının, çalışan ödül programlarının ve departmanlar arası kaynak paylaşımının daha iyi yönetilebilmesi.
- Şirketin stratejik, taktik ve operasyonel seviyede aldığı kararların bilgisiz fikirlerden çok bilgi temelli fikirlere dayanmasını sağlamak.
- Şirkette bilgi şeffaflığını artırmak.
- Performans ölçümlerinin daha sağlıklı olmasını sağlamak ve sorunlar konusunda sahiplenme sorunlarını iyileştirmek.
- Sorun oluşan konuların erken fark edilmesini sağlamak.
- Olası kar modellerinin erken ve daha iyi anlaşılmasını sağlamak, böylelikle fırsat süreci kapanmadan faydayı ençoklamak.
- Konsol ve karne gibi izleme sistemleri ile işi doğru izlemek ve işin izlendiği bilincini tüm şirkette oturtmak.
- Finansal başarıyı sağlayan müşteri, üretim ve insan kaynakları kriterlerini belirleyerek finansal sonuçlar gibi ardıl ölçütlerin yanısıra bu tür öncül ölçütleri de denetim altında tutabilmek.
...
Bu liste daha çok uzayabilir. Ama sanırım bir fikir verecek seviyeye gelmiştir.
PROJE RİSKLERİ
- Kullanıcıların güvenini kazanamamak. Haklı ya da haksız olarak iş zekası sisteminin yanlış sonuçlar verdiği düşüncesi yayılırsa proje ölü doğmuş olabilir.
- Kullanıcıların alışkanlıklarını değiştirememek. Eski sistemlerini daha rahat bulan kullanıcılar yeni sistemin getirdiği faydalardan yararlanmayabilir. Kullanılmayan bir iş zekası sistemi yok hükmündedir.
- Projenin çok uzun süreli ve çok kapsamlı olarak ele alınması, sürümlü yaklaşıma gidilmemesi sonucu bir türlü bitmeyen canavar bir projeyle başbaşa kalmak.
- Projenin başarılı olması durumunda ortaya çıkaracağı birtakım rahatsızlık verici gerçekleri öngörememek ve bunların hazmedilebilmesi için şirket yönetiminde gerekli hazırlıkları yapmamak. (Örneğin örtülü ve küçük çaplı birtakım yolsuzlukların ortaya çıkması...)
- Bilginin kolay ulaşılmasının getireceği fazladan güvenlik sorunlarını öngörememek. Yanlış kişiler yanlış bilgilere çok kolaylıkla ulaşır hale gelebilir.
- İş zekası sistemini şirket çapında bütüncül bir yapı gibi öngörmek yerine, departman bazlı ve birbiriyle ilişkisiz küçük iş zekası adacıkları oluşturmak. Bu durum, iş zekasının pek çok faydasını sıfırlayacaktır.
- Raporlama ve analiz alanında çalışan insanların kendilerinin daha kalifiye analize yöneleceklerini fark edememeleri, aksine işlerinden olacakları, işlerinin tamamen otomatikleşerek kendilerine gerek kalmayacağı fikrine kapılmaları ve projeye direnmeleri sonucu hatalı, yanlış ya da eksik sistemlerin ortaya çıkması.
Risklerle ilgili olarak da yukarıdaki liste tabii ki tüm riskleri 'tüketen' konumunda değil. Ama yine fikir vermek açısından iyi bir başlangıç olduğunu düşünüyorum.
PROJE VARSAYIMLARI
Bir projede dikkatle ele alınması gereken çok önemli bir konu varsayımlardır. Varsaymak anlamındaki ASSUME kelimesiyle ilgili İngilizce'de şöyle bir anlam da verilir: make an ASS of U and ME. Türkçesini burada yazmayacağım. Ama varsaymanın ne kadar sakıncalı olabileceğiyle ilgili önemli bir uyarı olarak aklınızda kalsın.
Varsayımlarla ilgili sorun şudur: Yanlış olabilirler.
Bir varsayımı veri olarak kabul edip sonraki yaklaşımlarınızı ona göre geliştirdiğiniz için sıkıntılı durumlara düşebilirsiniz sonradan.
Şunu düşünün: Şirkette iş zekası projesine başlayacaksınız, o ana kadar sürekli Microsoft ürünleri kullanılmış durumda. Ama iş zekasına yeni giriyor şirket. Microsoft ürünleriyle devam edileceğini varsayıp ona göre bir proje hazırlığına girişiyorsunuz, ama üst yönetim projenizle ilgili hazırlık sunumunu yaparken böyle bir seçim yapılmış olduğunu nereden çıkardığınızı soruyor. Öğreniyorsunuz ki, daha önce yapılmış tüm yatırımlarda hangi teknolojinin kullanılacağı da proje kapsamında incelenerek karara varılmış. Burada da Microsoft teknolojileri kullanılabilecek olduğu gibi belki başka teknoloji de kullanılabilecek. Proje kapsamında bunun da incelenip karara bağlanması gerekiyor.
Varsayımlar hakkında bir liste vermek pek mümkün değil. Şirketin kendine özgü şartları çok etkili çünkü bu alanda. Ama birkaç tehlikeli varsayım örneği verebiliriz:
- Kullanıcıların sisteme büyük bir hevesle atlayacağını varsaymak. Oysa çoğu durumda onlara projenin 'satışını' yapmak gerekir.
- Ekibin becerisinin bu konuda yeterli olduğunu varsaymak, hazırlıkla ilgili yeterli öngörüde bulunmamak. İş zekası projeleri disiplinler arası projelerdir. Çoğu durumda yakın projeler yapmış kişilerin bile bakış açılarında önemli değişiklik yapmayı gerektirirler.
- IT kaynakları ve IT liderliğinin başarılı bir iş zekası projesi için yeterli olduğunu varsaymak. Oysa değildir. İş zekası projelerinin sahibi iş tarafı olmalıdır. Tabii ki IT'nin büyük desteği, emeği ve mesaisi gerekir. Ama işin sahibi IT olmamalıdır.
PROJE BAŞARI KRİTERLERİ
Bir iş zekası projesinin başarı kriterleri teknik ya da işle ilgili olmak üzere iki grupta ele alınabilir.
Hangi gruptan olursa olsun, her başarı kriterinde zaman bağlamının da olması çok önemlidir.
Teknik başarı kritelerlerine örnek olarak birkaç şey sayalım:
- Proje kapsamının x ayda tamamlanması- x, y, z raporlarının t günde eski sistemden yeni sisteme sorunsuz hale çalışır halde aktarılması.
- Daha önceki ortamda alınamayan t1, t2 raporlarının yeni sistemde alınır hale getirilmesi ve z ayda iş süreçlerinde etkin olarak kullanım alışkanlığının geliştirilmesi.
Asıl iş tarafındaki başarı kriterlerine göz atalım:
- x ay içinde, şirket için karlılık ölçütlerine göre müşterilerin sıralanabilir hale gelmesi.
- x ay içinde, gereksiz masraf kalemlerinin yakalanması yoluyla satışların maliyetlerinin yüzde y düşürülmesi.
- x ay içinde büyüme potansiyeline sahip bayilerin temel belirleyici özelliklerinin belirlenmesi ve bu profile uyan bayilere yönelik özel satış programı geliştirilmesi.
Gördüğünüz gibi business hedefleriyle olayı ele aldığınızda işin sahibinin neden IT değil de business olması gerektiği net bir şekilde ortaya çıkıyor.
DEĞİŞİM YÖNETİMİ
İş zekası projeleri bitmez. Başarılı iş zekası projeleri sürekli yeni isterlere sebep olur ve yeni fazlarla yaşamlarına devam ederler.
Bu durumda iş zekası projelerini sürümlü olarak ele almak ve sürüm sürelerini kısa tutmak faydalı olacaktır. Benim önerim bir faz için 4 ila 6 aylık bir süre öngörmek yönünde.
Öte yandan iş zekası projeleri çok dinamiktir ve iş kraldır. Bu durumda projenin akışına zarar vermeyecek şekilde iş taraflarının isterleri çok önemlidir.
Bir başka önemli gerçek ise, değişimi yönetemeyen bir projenin asla başarılı olamayacağı.
O zaman değişim yönetimi konusunda önerimiz nedir?
Kesinlikle ilkeleri önceden belirlenmiş bir değişim yönetimi süreci bulunmalıdır. Her faz için kapsam dışı bırakılmış unsurları kapsama almakta isteksiz davranmakta fayda var. Özellikle sürüm aralıkları yeterince kısa tutulduysa bu tür istekler sonraki sürümlere ertelenmelidir.
Projenin ilgili fazında hata, yaklaşım farkı gibi konuları ilgilendiren değişim istekleri ise çok daha istekli ele alınmalıdır. İş tarafının işine yaramayacak, iş zekasına inançlarını sarsacak, yanlış, eksik bir şey sunmayı hiçbir zaman istemeyiz.
Biz de bu unsurlardan bazıları açısından iş zekası projelerini inceleyelim:
PROJE GETİRİLERİ (ya da hedefleri)
Finansal sonuçların yanısıra finansal olmayan sonuçlar da hedeflenebilir.
Sektörüne, içeriğine ve şirketin yaklaşımına bağlı olarak değişiklikler göstermesi mümkün olmakla birlikte iş zekası projelerinden beklenebilecek bazı hedefleri sıralayalım. Tabii ki bu liste bütüncül değil, yani olası tüm getirileri listelemiyor. Ama size bir fikir verebilir:
- Şirket gelirlerinin daha iyi anlaşılıp artırılabilmesi.
- Şirket maliyetlerinin daha iyi anlaşılıp azaltılabilmesi.
- Müşteriler, çalışanlar, departmanlar gibi unsurların özellikleri bazında performans açısından incelenebilmesi sonucu, müşteri ödül programlarının, çalışan ödül programlarının ve departmanlar arası kaynak paylaşımının daha iyi yönetilebilmesi.
- Şirketin stratejik, taktik ve operasyonel seviyede aldığı kararların bilgisiz fikirlerden çok bilgi temelli fikirlere dayanmasını sağlamak.
- Şirkette bilgi şeffaflığını artırmak.
- Performans ölçümlerinin daha sağlıklı olmasını sağlamak ve sorunlar konusunda sahiplenme sorunlarını iyileştirmek.
- Sorun oluşan konuların erken fark edilmesini sağlamak.
- Olası kar modellerinin erken ve daha iyi anlaşılmasını sağlamak, böylelikle fırsat süreci kapanmadan faydayı ençoklamak.
- Konsol ve karne gibi izleme sistemleri ile işi doğru izlemek ve işin izlendiği bilincini tüm şirkette oturtmak.
- Finansal başarıyı sağlayan müşteri, üretim ve insan kaynakları kriterlerini belirleyerek finansal sonuçlar gibi ardıl ölçütlerin yanısıra bu tür öncül ölçütleri de denetim altında tutabilmek.
...
Bu liste daha çok uzayabilir. Ama sanırım bir fikir verecek seviyeye gelmiştir.
PROJE RİSKLERİ
- Kullanıcıların güvenini kazanamamak. Haklı ya da haksız olarak iş zekası sisteminin yanlış sonuçlar verdiği düşüncesi yayılırsa proje ölü doğmuş olabilir.
- Kullanıcıların alışkanlıklarını değiştirememek. Eski sistemlerini daha rahat bulan kullanıcılar yeni sistemin getirdiği faydalardan yararlanmayabilir. Kullanılmayan bir iş zekası sistemi yok hükmündedir.
- Projenin çok uzun süreli ve çok kapsamlı olarak ele alınması, sürümlü yaklaşıma gidilmemesi sonucu bir türlü bitmeyen canavar bir projeyle başbaşa kalmak.
- Projenin başarılı olması durumunda ortaya çıkaracağı birtakım rahatsızlık verici gerçekleri öngörememek ve bunların hazmedilebilmesi için şirket yönetiminde gerekli hazırlıkları yapmamak. (Örneğin örtülü ve küçük çaplı birtakım yolsuzlukların ortaya çıkması...)
- Bilginin kolay ulaşılmasının getireceği fazladan güvenlik sorunlarını öngörememek. Yanlış kişiler yanlış bilgilere çok kolaylıkla ulaşır hale gelebilir.
- İş zekası sistemini şirket çapında bütüncül bir yapı gibi öngörmek yerine, departman bazlı ve birbiriyle ilişkisiz küçük iş zekası adacıkları oluşturmak. Bu durum, iş zekasının pek çok faydasını sıfırlayacaktır.
- Raporlama ve analiz alanında çalışan insanların kendilerinin daha kalifiye analize yöneleceklerini fark edememeleri, aksine işlerinden olacakları, işlerinin tamamen otomatikleşerek kendilerine gerek kalmayacağı fikrine kapılmaları ve projeye direnmeleri sonucu hatalı, yanlış ya da eksik sistemlerin ortaya çıkması.
Risklerle ilgili olarak da yukarıdaki liste tabii ki tüm riskleri 'tüketen' konumunda değil. Ama yine fikir vermek açısından iyi bir başlangıç olduğunu düşünüyorum.
PROJE VARSAYIMLARI
Bir projede dikkatle ele alınması gereken çok önemli bir konu varsayımlardır. Varsaymak anlamındaki ASSUME kelimesiyle ilgili İngilizce'de şöyle bir anlam da verilir: make an ASS of U and ME. Türkçesini burada yazmayacağım. Ama varsaymanın ne kadar sakıncalı olabileceğiyle ilgili önemli bir uyarı olarak aklınızda kalsın.
Varsayımlarla ilgili sorun şudur: Yanlış olabilirler.
Bir varsayımı veri olarak kabul edip sonraki yaklaşımlarınızı ona göre geliştirdiğiniz için sıkıntılı durumlara düşebilirsiniz sonradan.
Şunu düşünün: Şirkette iş zekası projesine başlayacaksınız, o ana kadar sürekli Microsoft ürünleri kullanılmış durumda. Ama iş zekasına yeni giriyor şirket. Microsoft ürünleriyle devam edileceğini varsayıp ona göre bir proje hazırlığına girişiyorsunuz, ama üst yönetim projenizle ilgili hazırlık sunumunu yaparken böyle bir seçim yapılmış olduğunu nereden çıkardığınızı soruyor. Öğreniyorsunuz ki, daha önce yapılmış tüm yatırımlarda hangi teknolojinin kullanılacağı da proje kapsamında incelenerek karara varılmış. Burada da Microsoft teknolojileri kullanılabilecek olduğu gibi belki başka teknoloji de kullanılabilecek. Proje kapsamında bunun da incelenip karara bağlanması gerekiyor.
Varsayımlar hakkında bir liste vermek pek mümkün değil. Şirketin kendine özgü şartları çok etkili çünkü bu alanda. Ama birkaç tehlikeli varsayım örneği verebiliriz:
- Kullanıcıların sisteme büyük bir hevesle atlayacağını varsaymak. Oysa çoğu durumda onlara projenin 'satışını' yapmak gerekir.
- Ekibin becerisinin bu konuda yeterli olduğunu varsaymak, hazırlıkla ilgili yeterli öngörüde bulunmamak. İş zekası projeleri disiplinler arası projelerdir. Çoğu durumda yakın projeler yapmış kişilerin bile bakış açılarında önemli değişiklik yapmayı gerektirirler.
- IT kaynakları ve IT liderliğinin başarılı bir iş zekası projesi için yeterli olduğunu varsaymak. Oysa değildir. İş zekası projelerinin sahibi iş tarafı olmalıdır. Tabii ki IT'nin büyük desteği, emeği ve mesaisi gerekir. Ama işin sahibi IT olmamalıdır.
PROJE BAŞARI KRİTERLERİ
Bir iş zekası projesinin başarı kriterleri teknik ya da işle ilgili olmak üzere iki grupta ele alınabilir.
Hangi gruptan olursa olsun, her başarı kriterinde zaman bağlamının da olması çok önemlidir.
Teknik başarı kritelerlerine örnek olarak birkaç şey sayalım:
- Proje kapsamının x ayda tamamlanması- x, y, z raporlarının t günde eski sistemden yeni sisteme sorunsuz hale çalışır halde aktarılması.
- Daha önceki ortamda alınamayan t1, t2 raporlarının yeni sistemde alınır hale getirilmesi ve z ayda iş süreçlerinde etkin olarak kullanım alışkanlığının geliştirilmesi.
Asıl iş tarafındaki başarı kriterlerine göz atalım:
- x ay içinde, şirket için karlılık ölçütlerine göre müşterilerin sıralanabilir hale gelmesi.
- x ay içinde, gereksiz masraf kalemlerinin yakalanması yoluyla satışların maliyetlerinin yüzde y düşürülmesi.
- x ay içinde büyüme potansiyeline sahip bayilerin temel belirleyici özelliklerinin belirlenmesi ve bu profile uyan bayilere yönelik özel satış programı geliştirilmesi.
Gördüğünüz gibi business hedefleriyle olayı ele aldığınızda işin sahibinin neden IT değil de business olması gerektiği net bir şekilde ortaya çıkıyor.
DEĞİŞİM YÖNETİMİ
İş zekası projeleri bitmez. Başarılı iş zekası projeleri sürekli yeni isterlere sebep olur ve yeni fazlarla yaşamlarına devam ederler.
Bu durumda iş zekası projelerini sürümlü olarak ele almak ve sürüm sürelerini kısa tutmak faydalı olacaktır. Benim önerim bir faz için 4 ila 6 aylık bir süre öngörmek yönünde.
Öte yandan iş zekası projeleri çok dinamiktir ve iş kraldır. Bu durumda projenin akışına zarar vermeyecek şekilde iş taraflarının isterleri çok önemlidir.
Bir başka önemli gerçek ise, değişimi yönetemeyen bir projenin asla başarılı olamayacağı.
O zaman değişim yönetimi konusunda önerimiz nedir?
Kesinlikle ilkeleri önceden belirlenmiş bir değişim yönetimi süreci bulunmalıdır. Her faz için kapsam dışı bırakılmış unsurları kapsama almakta isteksiz davranmakta fayda var. Özellikle sürüm aralıkları yeterince kısa tutulduysa bu tür istekler sonraki sürümlere ertelenmelidir.
Projenin ilgili fazında hata, yaklaşım farkı gibi konuları ilgilendiren değişim istekleri ise çok daha istekli ele alınmalıdır. İş tarafının işine yaramayacak, iş zekasına inançlarını sarsacak, yanlış, eksik bir şey sunmayı hiçbir zaman istemeyiz.
Kaydol:
Kayıtlar (Atom)
