• Sonuç bulunamadı

2. KURUMSAL UYGULAMA YAZILIM PAKETLERİ ve SEÇİM SÜRECİ

2.5 Kurumsal Uygulama Yazılımı Seçimi

2.5.2 Kurumsal Uygulama Yazılım Paketi Seçim Süreci

Literatürde yazılım seçim metodolojileri tanımlayan akademik çalışmalar bulunmaktadır, fakat bu metodolojiler genellikle, spesifik bir kurumsal uygulama yazılımına özel olmaktadır. Bu yaklaşımlar 3. bölümdeki literatür araştırması kapsamında özetlenmektedir. Varolan genel metodolojiler ise genellikle, firmalara yazılım seçimi danışmanlık hizmeti sunan danışmanlık firmaları tarafından tanımlanan metodolojilerdir. Bu metodolojiler, geniş kabul görmüş yazılım seçimi stratejilerine ve danışmanlık firmalarının birçok firmadaki uygulamaları neticesinde oluşan tecrübe ve bilgi birikimlerine dayanmaktadır. Bu metodolojilerin genel olarak birçok adımı ortak olmakta, sadece kullanılan karar metotlarında farklılıklar göstermektedir. Bu bölümde, kurumsal uygulama yazılım seçimi sürecinin temel safhalarını ve bu safhalarda gerçekleştirilecek adımları tanıtmak amacıyla, birkaç danışmanlık firmasının geliştirdiği metodolojiler doğrultusunda genel bir bakış açısı sunulmaktadır.

Organizasyonlardaki yazılım paketi seçim projeleri birbirinden farklı ve her projenin kendine özgü olmasına rağmen, tüm yazılım paketi seçim projelerinde genel adımlar bulunmaktadır. Kontio vd. (1995) bu adımları,

• Seçim sürecinde oluşturulan proje takımının görevlerinin açık bir şekilde tanımlanması, • Değerlendirme kriterlerinin hiyerarşik ve detaylı tanımının yapılması,

• Yazılım alternatiflerin değerlendirme kriterleri baz alınarak birbiriyle karşılaştırılması, • Değerlendirme sonuçlarının analizi ve özetinde uygun karar verme metotlarının

kullanılarak son seçim kararının verilmesi şeklinde tanımlamaktadır.

Amerika’da faaliyet gösteren ve “Fortune 500” firmalarına, orta düzey pazarda yer alan firmalara ve büyümekte olan firmalara bilgi sistemleri danışmanlık ve eğitim hizmetleri sunan bir danışmanlık firması tarafından sunulan iş odaklı yazılım seçim metodolojisinin aşamaları aşağıda özetlenmektedir (Mason, 2000):

• Aşama 1 - Projenin başlatılması: Projenin başlatılması safhası aşağıdaki adımlardan oluşmaktadır:

• Proje hedef ve amaçlarının belirlenmesi: Bu adımda firma, içeriğinde aşağıdakilerin bulunduğu bir rapor hazırlamaktadır:

• Problemin tanımı,

• Proje sponsorunun ve yönetim kurulunun tanımı ve hedefleri, • Proje amaçları,

• Proje takım üyeleri ve rolleri, • Proje dışında tutulanlar,

• Önemli olasılıklar ve proje kısıtları.

• Proje takımının oluşturulması: Kurumun en iyi başarı şansına sahip olması için, projeye her seviyeden katılımın sağlanması gerekmektedir. İdeal olarak bir proje aşağıdaki yapıya sahip olmalıdır:

• Proje sponsoru: Yönetim kurulundan bir veya iki personelin projeyi başlatması ve projenin amaçlarını başlangıçtan itibaren ortaya koyması gerekmektedir.

• Destekleyici yönetim kurulu: Projeden kazanç sağlayabilecek iki veya daha fazla üst düzey yöneticinin başlangıçtan itibaren projenin içinde olmaları gerekmektedir. • Proje yöneticisi: Projeden sorumlu olan ve yönetim kuruluna proje gelişmelerini

rapor eden bir proje yöneticisi gerekmektedir.

• Proje takımı: Proje amaçlarından etkilenen farklı departmanlardan çalışanların proje takımı içinde bulunmaları gerekmektedir.

• Başlangıç toplantısının yapılması: Proje amaç ve hedefleri belirlendikten ve proje takımı oluşturulduktan sonraki adım, projenin başlatılması için başlangıç toplantısının yapılmasıdır. Bu toplantının amacı, takım üyelerini proje hakkında eğitmektir.

• Aşama 2 - İş süreçlerinin analizi: İş süreçlerinin analizi aşaması aşağıdaki adımlardan oluşmaktadır:

• Mevcut süreçlerin anlaşılması: Bir organizasyonun işlerini nasıl yapması gerektiğini anlaması için, öncelikle mevcut süreçlerini anlaması çok önemlidir. İş süreçleri haritası boyunca takım; insanlar, teknoloji ve süreçler arasındaki etkileşimi tanımlayabilmektedir. İş süreçleri analizi, mevcut iş süreçlerinin anlaşılmasını içermektedir. Bunun için proje takımı yönetim kurulu ile başlayarak, tüm ilgili kişilerle görüşmeler yapmalıdır. Görüşmenin şekli, görüşülecek kişilere göre aşağıdakiler dikkate alınarak düzenlenmelidir:

• Üst yönetim: Görüşmeler, stratejiler ve hedefler konusunda gerçekleştirilmelidir. • Yönetim: Görüşmeler, projeyle ilgili konuların ve problemlerin ne olduğunu

saptamak, süreç akışları ve bu akıştaki kişilerin rollerini özetlemek yönünde düzenlenmelidir.

• Çalışanlar: Bir iş sürecinin haritasını çizerken en çok detayı sağladıkları için çalışanlarla yapılan görüşmeler çok önemlidir. Proje takımı, çalışanların kendi görevlerini tamamlamak için hangi sistemleri kullandığını ve manuel olarak gerçekleştirilen işleri saptamak zorundadır. Görüşme zamanlarının büyük bir yüzdesi çalışanlara ayrılmalıdır. Genellikle, operasyonel süreçler boyunca kontroller ve raporlar dağınık durumda olduğundan, bu süreçlerin anlaşılması güçtür. Bununla

birlikte, süreçler objektif olarak analiz edilmeli ve gelişme için fırsatlar hızlı bir şekilde tanımlanmalıdır.

• İş amaçlarını destekleyecek en iyi uygulamaların belirlenmesi: Proje takımının en iyi uygulamaları belirlemesi, organizasyona süreçlerinin nasıl çalışmasını istediğini saptamasına izin vermektedir. En iyi uygulamalar, sektördeki lider firmaların süreçleri, araştırma raporları veya diğer sektörlerdeki başarılı firmaların uygulamaları baz alınarak belirlenebilmektedir. Eğer organizasyonun kaynak kısıtı yoksa, organizasyonun nasıl davranması gerektiğini göstermektedir (Mason, 2000).

• İş süreçleri üzerinde boşluk analizinin yapılması: En iyi uygulamalar belirlendikten sonra proje takımı, görüşmelere geri dönerek, firma için olması gereken iş süreçlerini geliştirmektedir. Her firmanın birtakım kısıtları olduğu için, en iyi uygulamaları gerçekleştiremeyebilmektedir. Bundan dolayı, en iyi uygulamaları belirledikten sonra proje takımı, organizasyon için en iyiyi tanımlayabilmek amaçlı bir boşluk analizi çalışması yapmalıdır. Boşluk analizi, organizasyonun mevcut iş süreçlerindeki zayıf alanları tanımlayabilmektedir.

Bu zayıflıklar aşağıdaki faktörlerden kaynaklanabilmektedir: • Süreçleri destekleyen teknolojinin yetersiz olması,

• Manuel süreçleri destekleyen kaynakların yetersiz olması,

• Mevcut sistemlerden kaynaklanan etkin olmayan süreçlerin varolması.

Boşluk analizinin çıktısı, gerekli süreç iyileştirmelerini özetleyen bir öneri raporu şeklinde olmaktadır.

• İş süreçlerinin iyileştirilmesi: Proje takımı, boşluk analizi çıktılarına ve öneri raporunda yer alan kararlara dayanarak, olması gereken iş süreçlerinin haritasını geliştirmektedir.

• Aşama 3 - İhtiyaçların tanımlanması: Bu aşama, en uygun çözümün değerlendirilmesi projesinde bir dönüm noktasıdır. Birçok firma detaylı ihtiyaç analizi yapmadığı için tatmin etmeyen sonuçlar elde edebilmektedir. Bu aşamada aşağıdaki ihtiyaç tipleriyle ilgili konular tanımlanmaktadır:

• Yönetim ihtiyaçları • Bütçe/zamanlama

• Yönetim tarafından rapor edilen ihtiyaçlar • Fonksiyonel ihtiyaçlar

• Teknik ihtiyaçlar

• Bilgi sistemi standartları • Veri akış diyagramları • Sistem arayüzleri

• Aşama 4 - Satınalma seçeneğine karşılık yazılım geliştirmenin analiz edilmesi: Proje takımı firmanın fonksiyonel, teknik ve yönetimsel ihtiyaçlarını belirledikten sonra, mevcut paket yazılımlardan birini satınalma veya ihtiyaçlarına uygun yazılımı geliştirme kararını verebilmektedir. Eğer mevcut pazarda spesifik iş alanlarına yönelik çok sayıda çözüm alternatifi bulunuyorsa ve satıcıların sundukları ürün ve hizmetler proje bütçesini aşmıyorsa, genellikle kurumsal uygulama yazılımı satın almak önerilen bir yaklaşımdır. Bununla beraber, mevcut yazılımlar firmanın belirlediği ihtiyaçları karşılayabilecek nitelikte değilse, bu durumda firma içerisinde yazılım geliştirmek daha az riskli bir çözüm olmaktadır.

• Aşama 5 - Yazılım seçimi: Proje takımı bir önceki aşamada bir yazılım satınalma kararı vermiş ise, bu durumda yeni hedef doğru çözümün seçilmesi olmaktadır. Doğru çözüm iş ihtiyaçlarını, teknik ihtiyaçları ve yönetim ihtiyaçlarını karşılayan çözümdür. Bu aşama aşağıdaki adımları kapsamaktadır:

• Potansiyel satıcı alternatiflerinin araştırılması

• Bilgi istek formunun (Request for Information-RFI) geliştirilmesi: Bilgi istek formu çalışılabileceği düşünülen satıcılara gönderilen bir formdur. Bilgi istek formunda aşağıdaki konular yer alabilmektedir:

• Projenin kapsamı (bütçe ve zaman kısıtı), • Yüksek öncelikli fonksiyonel ihtiyaçlar, • Teknik ihtiyaçlar

• Kısa satıcı listesinin oluşturulması: Satıcı firmaların RFI cevapları dikkate alınarak kısa bir liste oluşturulabilmektedir. Bu liste 4-7 satıcı içermelidir. Çok fazla satıcı ile görüşme yapmak, projenin maliyetini yükseltebilmekte ve proje zamanını uzatmaktadır. Aynı zamanda takım elemanları çok fazla ürün çeşidi karşısında odak noktalarından uzaklaşabilmektedir.

• Puanlama kartı: Bu adımda proje takımı, satıcıların değerlendirilmesinde kullanılmak üzere bir puanlama tablosu hazırlamaktadır. Bu değerlendirmeler satıcı sunumları sırasında gerçekleştirilmektedir. Puanlama kartı, detaylı fonksiyonel ve teknik ihtiyaçları içermelidir. Seçilen maddeler spesifik ve ölçülebilir olmalıdır.

• Öneri istek formunun (Request for Proposal-RFP) geliştirilmesi: RFP, puanlama kartındaki maddeleri, detaylı finansal bilgileri, teknik bilgileri, satıcı destek ve bakım vaatlerini ve yazılımın gerçekleştirme maliyetlerini içeren bir formdur.

• Satıcı sunumlarının planlanması: Proje takımının satıcı sunumlarını kontrol edebilmesi çok önemlidir. Tüm satıcılara sunum için eşit süre ayrılmalı ve bu süreyi aşmalarına izin verilmemelidir. Her sunum sonunda takım, tüm maddelerin sunum içinde gösterildiğinden emin olmalıdır. Tüm takım üyeleri, her sunumun sonunda puanlama kartını doldurmuş olmalıdır. Böylelikle diğer sunumlardan etkilenerek ya da kıyaslama yaparak puanlama yapılmasının önüne geçilmiş olmaktadır. Firma için uygun yazılımın seçiminde puanlama kartlarının ve RFP’lerin cevapları esas alınmalıdır. Tüm sunumlar tamamlandıktan sonra, elde edilen veriler satıcıların sıralanması için kullanılmaktadır. Bir sonraki adım, takımın görüşmelere iki ana konu üzerinde yoğunlaşarak başlamasıdır. Bunlar; yazılımın lisans maliyeti ve gerçekleştirme maliyetidir. Lisans maliyeti başlangıç maliyetidir, yani bir nevi telif hakkıdır. Gerçekleştirme maliyetleri ise genellikle projenin bütçeyi aşmasına sebep olan maliyetlerdir. Bu nedenle uygulama aşamasına geçmeden önce tüm maliyet kalemleri detayları ile gözden geçirilmeli ve seçim toplam maliyete göre yapılmalıdır (Mason, 2000).

Bir başka danışmanlık firması Capterra kurumsal yazılım merkezi, yazılım satınalma sürecinde firmalara destek olmak amacıyla on-line danışmanlık hizmeti vermekte ve konuyla ilgili birçok araç ve kaynağı bünyesinde barınmaktadır. Kullandığı genel yazılım seçimi metodolojisini, temel olarak dört safhada tanımlamaktadır. Bu safhalar aşağıda özetlenmektedir (Capterra, 2001):

• Planlama safhası: Bu safha, firmanın mevcut durumunun değerlendirilmesini ve firmanın yeni bir yazılım çözümüne ihtiyaç duyma sebeplerinin tanımlanmasını gerektirmektedir. Amaçların tanımlanması ve iş süreçlerinin gözden geçirilmesi ile yazılım seçimi sürecinin temellerinin oluşturulduğu safhadır. Bu safhada yazılım seçim projesi için proje planı geliştirilmekte ve onaylanmaktadır. Bu safhanın temel aşama ve adımları şunlardır:

• Aşama 1: Amaçların tanımlanması

• Adım 1: Üst ve orta yöneticilerle görüşmeler yapılması

• Adım 2: Bilgi teknolojileri ve operasyon yöneticileriyle görüşmeler yapılması • Adım 3: Fonksiyonel departmanlardaki yönetici ve kullanıcılarla görüşmeler

yapılması

• Aşama 2: İhtiyaçların belirlenmesi

• Adım 1: Mevcut sistemin değerlendirilmesi • Adım 2: Alternatiflerin belirlenmesi

• Adım 3: Fayda maliyet analizlerinin yapılması • Aşama 3: Proje planının ve takımın oluşturulması

• Adım 1: Proje yapısının tanımlanması • Adım 2: Proje amacının tanımlanması • Adım 3: Proje takımının oluşturulması

• Adım 4: Proje aşamalarının ve görevlerin tanımlanması

• Tanımlama safhası: Bu safha, seçilecek çözüm için fonksiyonel, teknik ve operasyonel ihtiyaçların belirlenmesine odaklanmaktadır. Bu ihtiyaçlar, planlama safhasında tanımlanan amaçlar üzerine oluşturulmaktadır. Planlama safhası kısa satıcı listesinin, bir sonraki safhada kullanılacak öneri istek formunun oluşturulması ile tamamlanmaktadır. Bu safhanın temel aşama ve adımları şunlardır:

• Aşama 1: İhtiyaçların tanımlanması

• Adım 1: Proje planının ve amaçların gözden geçirilmesi • Adım 2: İhtiyaçların oluşturulması için hazırlık yapılması • Adım 3: İhtiyaçların oluşturulması

• Adım 4: İhtiyaçların önceliklendirilmesi

• Adım 5: İhtiyaçların tüm proje amaçlarını kapsadığının doğrulanması • Aşama 2: Potansiyel satıcıların tanımlanması

• Adım 1: Bilgi kaynaklarının tanımlanması ve satıcı listesinin oluşturulması • Adım 2: Ön değerlendirmenin yapılması

• Aşama 3: Öneri istek formunun (Request for Proposal-RFP) oluşturulması

• Değerlendirme safhası: Bu safha, ürünlerin fonksiyonel ve teknik özelliklerinin ve satıcıların detaylı bir şekilde değerlendirilmesini kapsamaktadır. Bu safhada, bir önceki safhada belirlenen ihtiyaçların, ürün özellikleri ile karşılaştırılması ve ürünlerin puanlandırılması gerçekleştirilmektedir. Değerlendirme safhasının amacı, her bir potansiyel ürün alternatifinin firmanın ihtiyaçlarını hangi derecede karşıladığının belirlenmesidir. Bu safhanın temel aşama ve adımları şunlardır:

• Aşama 1: Değerlendirmeye hazırlık

• Adım 1: Değerlendirme yaklaşımının belirlenmesi • Adım 2: Kaynakların bulunması ve düzenlenmesi

• Aşama 2: Ürün değerlendirme

• Adım 1: Fonksiyonel değerlendirmenin tamamlanması • Adım 2: Teknik değerlendirmenin tamamlanması • Adım 3: Fiyat ve bakım seviyelerinin değerlendirilmesi • Aşama 3: Satıcı değerlendirme

• Adım 1: Firmanın değerlendirilmesi

• Adım 2: Teknik destek ve bakım çalışanlarının değerlendirilmesi • Adım 3: Firmanın mevcut müşterileriyle görüşülmesi

• Seçim safhası: Bu safha, yazılım seçim sürecinin tamamlandığı aşamaları kapsamaktadır. İlk aşama yapılan değerlendirme skorlarının hesaplanması, gözden geçirilmesi ve son seçim adımlarını kapsamaktadır. İkinci aşama ise kontrat anlaşmaları aşamasıdır. Bu iki aşama da tamamlandıktan sonra seçim yapan firma seçtiği yazılım çözümünü gerçekleştirme projesine başlamaktadır (Capterra, 2001).

Başka bir danışmanlık firmasının tanımladığı yazılım seçimi metodolojisi de aşağıdaki aşamaları ve adımları içermektedir (Fewell ve Wald, 2001):

• Projenin başlatılması,

• Sektörün ve sektördeki en iyi uygulamaların kontrol edilmesi, • İhtiyaçların belgelenmesi, • Stratejik ihtiyaçlar • Fonksiyonel ihtiyaçlar • Satıcı ihtiyaçları • Teknik/operasyonel ihtiyaçlar • Arayüz/değiştirme ihtiyaçları

• Paketlerin analiz edilmesi ve finalistlerin seçilmesi,

• Satınalma seçeneğine karşılık yazılım geliştirme seçeneğinin analiz edilmesi, • Seçilen finalistlerin gözden geçirilmesi,

• RFP

• Satıcı Sunumları

• Önerinin belgelenmesi/Yönetimin onayının alınması,

• Seçilen yazılımın gerçekleştirme maliyetlerinin ve personel planının geliştirilmesi, • Altyapıyı iyileştirme

• Yükleme • Özelleştirme

• Mevcut sistemlere arayüz oluşturma • Dosya değişikliği/transferi

• Eğitim/değişim yönetimi • Dokümantasyon ve destek

Yukarıda sunulan metodolojiler, kurumsal uygulama yazılım paketi seçiminde uygulanabilecek temel adımları içermektedir. Bu adımlar içerisinde şüphesiz en önemli nokta her aşamada kullanılacak karar destek metodunun etkinliğidir. Uygulamada bu ve benzeri noktalarda pek çok güçlükle karşılaşılmakta ve büyük hatalar yapılmaktadır.