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.

Hazırlık üzerine...

Benjamin Franklin der ki:
"By failing to prepare, you are preparing to fail."

Hazırlanmakta başarısız olmakla, başarısızlığa hazırlık yapmış olursunuz. (Bu kulağa hoş gelen çevirisi)

Hazırlanmayı ihmal etmekle, başarısızlığa hazırlık yapmış olursunuz. (Bu da vurgusu biraz azalmış ama anlam olarak daha doğru bir çeviri)

22 Haziran 2009 Pazartesi

İşin zaman boyutu

İş zekası sistemlerinde herhangibir veriye baktığımız ilk boyut zamandır. Zaman boyutu olmadan herhangi bir şeyin ölçümü anlam taşımaz.

Basitçe iki inşaat firmasını düşünün. Binalarını tamamen aynı birim fiyatlarla üretebiliyor ve satabiliyor olsunlar. İkisinin de eleman ve müşteri derdi yok. Ama bir tanesi daha iyi organize olabiliyor ve bir binayı üretip satma süresi bir yıl. Diğeri ise aynı binayı iki yılda üretip satabiliyor. Tamamen aynı maliyetlerle ve aynı fiyatlarla çalışan iki firmadan bir yılda işi bitirebilen diğerininin iki katı para kazanıyor ve kar ediyor olacaktır.

David A. J. Axson, Best Practices in Planning and Performance Management adlı kitabında zaman bazlı rekabetin bileşenlerini listelemiş. O listeyi buraya tercüme ederek aktaracağım. Bakın bir şirketi 'bitirebilecek' zaman bağlamında ne tür rekabet unsurları var:

- Yeni ürün ve hizmetlerin kavramdan gerçeğe dönüştürülme süresi
- Ürün ve hizmetlerin müşteriye sunulabilme süresi
- Hesap (dönem) kapatma süresi
- Yeni elaman alma süresi
- Yeni eleman sahaya alma süresi
- Yeni elemanın tam üretkenliğe erişme süresi
- Anahtar kararların alınma süresi
- Büyük işlerin (satış, proje vb) bitirilme süresi
- Ekipman ve ürünlerin yararlı ömürlerini bitirme süresi
- Satın almaları bünyeye entegre etme süresi
- Rekabetçi eylemlere karşılık verebilme süresi
- Yeni teknoloji yatırımlarından değer üretebilme süresi
- Yeni bir pazara girme süresi

19 Haziran 2009 Cuma

Project Server 2007'de bir kuyruk sorunu ve çözümü

Project Server 2007, 2003'e göre önemli bir yenilik olarak kuyruklama sistemini getirdi. Performans algısı açısından önemli bir fayda sağlanmış olsa da bazı konularda karışıklık seviyesi de yükselmiş oldu.

Yaşanan önemli sorunlardan biri, bazı durumlarda bazı job'ların "getting queued" durumunda takılı kalması. Bu joblar belirli bir projeyle ilgili olarak sonraki jobların da yapılmasını engelleyebilir. İlgili projenin checked out durumda kalmasına sebep olabilir. Hatta admin olarak force check-in yapmaya çalıştığınızda bile kuyruktaki iş yüzünden force check-in'i gerçekleştiremeyebilirsiniz.

İki önemli soru var:
1. Bu durumu yaşadığımda sorunu nasıl aşabilirim?
2. Bu durumun sebebi nedir? Tekrar oluşmasını nasıl engelleyebilirim.

Birinci sorudan başlayalım. Sorunu çözmek için "getting queued" durumunda takılı kalan job'ı iptal etmelisiniz. Ama bunu normal ayarlarla yapamazsınız. Aşagıdaki yolu izlemeniz gerekir:

Project Web Access Server Settings sayfasında, Queue bölümünde Manage Queue'yi tıklayın.
Gelen sayfada Advanced Options bölümünü açın.
Advanced Options bölümünde Cancel jobs getting enqueued seçeneğini seçili hale getirin.

Bu işlem, bu tür işlerin iptal edilebilmesi için gereklidir.

Daha yukarıdan hangi zaman aralığındaki işleri görüntüleyeceğinizle ilgili kısımda da kuyruğa alınırken takılı kalmış işi görecek şekilde tarih aralığını değiştirmeniz gerekebilir.

Bu işlemleri yaptıktan sonra "getting enqueued" durumundaki işi seçip 'cancel' edebilirsiniz.

Aslında cancel etmeden önce denenecek bir şey daha var. Ama bunu anlatmak için ikinci ana sorumuza gelmemiz gerekiyor: Bu tür sorunlar nasıl oluşur ve nasıl tekrar oluşmamalarını sağlayabiliriz?

Bir işin bu durumda olmasının sebebi şudur: Kuyruk işlenecek bir işi almak üzere bilgilendirilmiştir ama yapılacak iş için gerekli tüm veriyi henüz alamamıştır. Bu yüzden de işi kuyruklama konumunda beklemektedir. Mesela büyük, satır sayısı ve custom alanları fazlaca olan bir proje kaydedilmeye başlamış olabilir. Ama kullanıcı kayıt işlemi yüzde yüz bitmeden project professional'ı kapatmış ya da server ile bağlantıyı kesmiştir. Bu durumda kayıt işlemi kuyruklanmaya devam etmektedir, henüz tamamlanamamıştır. Böyle bir işi yukarıda belirttiğimiz gibi cancel etmeden önce ilgili istemciyi sunucuya tekrar bağlayarak işin bitmesini sağlamaya çalışabilirsiniz. Bunu yapamıyorsanız, cancel yoluna gitmelisiniz.

Tekrar bu durumla karşılaşmamak için, kullanıcılarınız status bar'ı kontrol etmeyi alışkanlık haline getirmeli. Project Professional'ın status barında kuyrukla ilgili bilgiler görülür. Kaydetme gibi sunucuda kuyruklama ile yapılan işlerde işin yüzde yüz bittiğinden emin olmadan bağlantınızı kesmeyin.

15 Haziran 2009 Pazartesi

Veri madeninde ve analysis services kübünde many to many dimension uygulaması

Fact tabloları ile boyutlarımız arasında çoğunlukla 'regular' ilişkiler vardır. Ama bazen regular ilişkiler yeterli olmaz, farklı yaklaşımlar gerekir. Bu yazıda o ilişki tiplerinden biri üzerinde duracağım: Many to many dimensions yani çoklu ilişkili boyutlar.

Örneği basit alacağız ki konuya odaklanabilelim. Bu yüzden anlatacağım örnekte slowly changing dimension gibi kavramları da yok sayacağım. Bunun bütüncül bir örnek olmadığını unutmayın. Tüm amacımız many to many dimension'ın net bir örneğini görmenizi sağlamak.

Öncelikle ele alacağımız problemi ifade edelim: Bir hastane için hastalara yapılan işlemleri ve bunların tutar bilgilerini analiz etmek istiyoruz. Analizimizin önemli bir konusu da işlemi hangi doktor ya da doktorların yapmış olduğu. Tek bir doktor da işlem yapabilir bir grup doktor da. Yani işlemlerle hastalar arasında regular bir ilişki varken işlemlerle doktorlar arasında çokluya çoklu (many to many) bir ilişki var.Kurmamız gereken veriambarının basit tasarımı yukarıdaki gibi. Her hastanın bir id'si ve adsoyadı var. Her doktorun da bir id'si ve ad soyadı var. Hasta işlemleri fact'i hasta boyutuna doğrudan bağlı. Bu fact'te doktor bilgisini ise tutmuyoruz. Yani hangi doktorun işlemi yaptığına dair bilgi işlem fact'inde yok. Bunun yerine işlem facti ile doktor boyutu arasına ikinci bir fact olacak olan bir ara köprü tablosu koyuyoruz. Bu tablo hem işlemle hem doktorla ilişkili ve iki foreign key kolonunu birlikte primary key olarak kullanıyor.

Şimdi bu tablolara örnek kayıtlar ekleyelim. Ben 1. Doktor1, 2. Doktor2, 3.Doktor3 olarak doktor kayıtlarını ve 1.Hasta1, 2.Hasta2, 3.Hasta3 olarak hasta kayıtlarını ekledim.

İşlem tablosunun verileri şöyle:

İşlemID / HastaID / Tutar
1 1 100
2 2 200
3 3 300
4 1 500
5 1 800

İşlem Doktor'un verileri ise şöyle (Facthastadoktor isimli tablo. Aslında işlemdoktor deseymişim daha uygun bir isim olacakmış. İdare edin artık :) ):

İşlemID / DoktorID
1 1
2 2
3 3
4 1
4 2
5 1
5 2
5 3

İlk 3 işlemi birer doktor yapmış. 4 nolu işlem Hasta1'e 2 doktor tarafından yapılmış. 5 nolu işlem Hasta3'e 3 doktor tarafından yapılmış.

Şimdi bunun küp sisteminde görünümüne bakalım. İki temel yer var bakacağımız: Dimension usage ve datanın görünümü: Gördüğünüz gibi ara tablomuz da bir measure group olarak yapılandırılmış. Bunun da bir fact olduğunu söylemiştik. Ayrıca hasta işlem fact'indeki işlem id de bir boyut olarak yapılandırılmış. Bu özel bir boyut. Verisini factteki bir kolondan alıyor. Buna Kimball degenerate dimension, Microsoft ise fact dimension der. Daha önceki yazılarımda bahsettiğimi hatırlıyorum. Kısaca söylemek gerekirse, bağlı olduğu tüm attribute'ler başka boyutlara dağıldığı ve fact satırlarıyla ilişkisi de bire bir ya da birebire yakın olduğu için bu özel boyutun verisini fact'te bırakırız.
Bizim için şu an kritik olan nokta, dim doktor ile fact hasta işlem arasında fact hasta doktor measure grubu üzerinden many to many ilişki oluşturulmuş olması.
Peki böyle bir küp bize nasıl bir veri görünümü sunuyor:Genel toplamların doğru olduğuna da dikkat edin lütfen.
Doktor1'in dahil olduğu hasta1 tutarları 1400. Ama doktor1 zaten hasta1'in tüm tutarlarına dahil olmuştu. Bu yüzden hasta1'in toplam tutarı da 1400.

Bu veri ambarından küp oluştururken ne yapmak gerekli?

AS projenizde data source ve data source view'i oluşturun. Dört tabloyu da alın view'e. Sonra new cube diyerek wizard'ı başlatın. Fact olarak her iki tabloyu seçin. Wizardın kalan adımlarında hiçbir değişiklik yapmayın. (Wizard bittikten sonra fact boyutunun isminiuygun bir şekilde değiştirebilirsiniz.)

Bu kadar. Sonuç yukarıdaki gibi olacaktır.

22 Nisan 2009 Çarşamba

SQL 2008 upgrade webinarı

Bugün 15.00'te SQL 2008'e upgrade ile ilgili bir webinar (web semineri) veriyorum.

Seminerde de referans vermek üzere birkaç bağlantı noktasını burada aktarmak istiyorum:

Scalability Experts'in Upgrade Assistant'ıyla ilgili giriş ve indirme sayfaları:

http://www.scalabilityexperts.com/default.asp?action=article&ID=43
http://www.scalabilityexperts.com/default.asp?action=article&ID=45

Upgrade Assistant'ın kullanımı biraz karışık. İndirme sayfasında nasıl kullanılacağına ilişkin doküman da var. Ama yine de Türkçe bir özet görmek isterseniz:

http://mustafaacungil.blogspot.com/2008/05/sql-2008e-upgrade-ediyoruz.html

Türkçe özeti tek başına kullanmayı denemeyin. Sadece tamamlayıcı nitelikte bir açıklama var o yazımda. Upgrade Assistant'ı ve dokümanının indirdikten sonra, onları kullanırken takılabileceğiniz noktalara destek amacıyla bu yazıyı kullanabilirsiniz.

Sistem tablolarını, metadata ile ilgili fonksiyonları, görünümleri vb kullanmak gibi özelleştirme işlerine girmişseniz, ya da veritabanı motoru haricinde diğer servisleri de kullanıyorsanız, pek çoğunda en az birkaç tane 'breaking change' bulunduğunu dikkate almanız gerekir. Büyük olasılıkla bunların pek çoğu sizi hiç etkilemeyecektir, ama bir tanesi bile etkiliyorsa, kodunuzda birtakım (az ya da çok) değişiklikler yapmanız gerekebilir.

Bu 'kıran değişikliklerin' yani 'breaking change'lerin neler olduğunu öğrenmek için SQL Server 2008 Books Online'ı açın ve indekste 'breaking changes' yazın. Farklı servislerle ilgili girdiler çıkacak karşınıza, sizi ilgilendirenleri inceleyin.

Bir başka önemli araçsa, Upgrade Advisor. Upgrade Assistant çok daha yetenekli, ama Upgrade Advisor'ı da kullanmak istersiniz. Upgrade Advisor'un kullanımı ile ilgili olarak da SQL Server 2008 Books Online'da indekste 'Upgrade Advisor' yazdığınızda geniş bilgi olan bir sayfaya ulaşıyorsunuz. Başlangıç noktası olarak bu sayfayı inceleyin.

20 Nisan 2009 Pazartesi

Project Professional'da kazayla kısıt oluşturmak

Projenizdeki bazı görevlerin standart ilişkiler dışında da zaman bağlamında kısıtları olabilir. Mesela bir görev kendisinin öncülleri daha önce bitse bile belirli bir tarihten önce başlayamayacak olabilir. Bu durumda Start No Earlier Than kısıtı oluşturursunuz. Ya da bir görevin belirli bir tarihten sonraya kalmaması gerekiyordur ve Finish No Later Than kısıtı oluşturursunuz.

Bu iki tür kısıt yarı esnek kısıtlar sınıfındadır. Yarı esnektirler çünkü bir uçtan bağlıyken diğer uçtan bağlamamış olurlar.

Ancak bu kısıtları kazara da projenize ekleme olasılığınız var. Hem de hayli yüksek bir olasılık!

Eğer projenin başlangıç ya da bitiş tarihi görülen bir tablodaysanız ve niyetiniz bu olmadığı halde bu tarihlerden birini elle girerseniz, bu kısıtlardan birini oluşturmuş olursunuz.

Benzer şekilde gant diyagramında bir görevin çubuğunu sürükleyerek tarihini değiştirirseniz, yine bu kısıtlardan oluşturmuş olursunuz.

Küçük bir hareket, bazen beklenmedik sonuçlar doğurabilir. Dikkat etmenizde fayda var.

SQL Server 2008 geçişiyle ilgili durumunuz nedir?