Dijital Dönüşüm Yazıları III – En İyi Yazılım Nereden Alınır?

Başlıktaki ironi aslında daha ziyade yazılım seçimlerindeki yaygın irrasyonelliğe dem vuruyor. Zira benzer sorular onlarca kez soruldu, onlarca kez “yazılım öyle bir şey değil” diye sabırla anlatılmaya çalışıldı. Öte yandan, yazılım tedariki nasıl yapılırsa yapılsın, ortaya çıkabilecek pek çok potansiyel sorun var.

İhtiyaç duyulan bir yazılımı tedarik etmek için üç temel yöntemden bahsetmek mümkün: ya iş ihtiyacını karşılayacak hazır bir paket ürün satın alınabilir ya tam olarak iş ihtiyacını karşılayabilmesi için terzi usulü özel bir proje yazdırılabilir ya da kurum içi kaynaklarla uygulama geliştirilebilir. Seçilen yöntem ne olursa olsun yazılım tedarikinin doğru yöntemle yapılamamasının temel sebeplerinden bir tanesi karar vericilerin çoğunlukla IT alanındaki yetkinliklerinin oldukça sınırlı olmasıdır. Tedarik edilen yazılımın yeteneklerinden ve kurum için uygunluğundan ziyade maliyet öne çıkan faktör olabilmektedir. Görece düşük maliyetli ama esasen iş ihtiyaçlarını karşılamayan yazılımların astarı ise çoğunluk yüzünden pahalıya çıkmaktadır.

Paket Yazılım Çözümleri

Fiyatı daha uygun olan yazılımlardan bahis açmışken ürüne dönüşmüş yazılım çözümlerini biraz daha yakından irdelemekte fayda var. Bu tip yazılım çözümleri, bir ya da birden fazla iş ihtiyacını karşılamak üzere jenerik olarak geliştirilmiş çözümlerdir. ERP, CRM, SCM gibi yazılımlar örnek verilebilir. Yazılımın destekleyeceği süreçler, yazılım sağlayıcısı tarafından belirli bir saha analizi sonrasında belirlenir, yazılım da bu ihtiyaca uygun olarak geliştirilir. Müşteriden müşteriye farklılaşan süreçler de parametrelerle yönetilmeye çalışılır. Ne var ki, bu parametreler kurumların süreçlerine uyumluluk konusunda çoğunlukla yetersiz kalırlar. Dolayısıyla bu tip yazılımların oldukça hantal olduklarını söylemek yanlış olmayacaktır. Bunun sonucu olarak yazılımın müşterileri ya süreçlerini yazılıma uyarlamak durumunda kalırlar, ya yazılım üzerinde birtakım özelleştirme çalışmalarına yönelirler ya da yazılımın yeteneklerinden kısıtlı bir şekilde yararlanabilirler.

Yazılımın kurum iş ihtiyaçlarına göre uyarlanması kulağa cazip gelse de bu süreç de oldukça meşakkatlidir ve zaman zaman maliyetler çok yükselebilmektedir, kaldı ki bazen yazılımın tam olarak ihtiyaçlara uyarlanabilmesi hiç mümkün de olmayabilir. Öte yandan, bu özelleştirme süreci de yazılıma ve özelleştirme ihtiyacına göre değişkenlik göstermekle birlikte aylarca sürebilir. Bu süreçte değişen pazar koşulları sebebiyle iş ihtiyaçları bile farklılık gösterebilir. Öyle ki her iki taraftaki insan kaynağında değişimler bile gerçekleşebilir.

Paket ürünlerin yukarıda sayılan şekilde sorunları olmasına karşın çokça tercih edilmesinin sebebi genel olarak maliyet avantajıdır. Tedarikçi açısından bir kez geliştirilip pek çok kuruma satılabildiği için paket çözümlerin maliyetleri pek çok alıcı arasında paylaşılmaktadır. Ayrıca bir yazılımın farklı kurumlar tarafından kullanılıyor olması yani referansları olması sağlayacağı faydalar açısından ikna edici olmaktadır.

Terzi Usulü Yazılım Çözümleri

Yazılım tedariki için bir diğer olasılık da kurumun kendi ihtiyaçlarına bire bir uyan (terzi usulü / tailor made) özel bir yazılım projesi sipariş etmesidir. Yazılım kuruma özel geliştirileceğinden maliyetin paket bir yazılım çözümünden oldukça yüksek olacağını öngörmek mümkündür. Bununla birlikte, yazılım bire bir kurumun ihtiyaçlarına binaen geliştirileceği için süreçlerle yazılım arasında bir uyumsuzluk olması, en azından, kâğıt üzerinde düşünülmez.

Her ne kadar kâğıt üzerinde kuruma özel geliştirilen yazılımlarla yönetme iddiasında olduğu süreç arasında bir uyumsuzluk beklenmese de gerçek hayatta durum hiç de öyle değildir ve bu tip bir seçimde bile beklenen fayda sağlanamayabilir. Bunun birden fazla sebebi vardır. Öncelikle yazılım geliştirme süreci pek çok adımdan oluşan, çok dikkatli yönetilmesi gereken oldukça meşakkatli bir süreçtir. Bu süreci yönetmek de ayrı bir yetenek ve deneyim gerektirir. Ne var ki kurumlarda bu yetkinlikte personel genel olarak bulunmaz. Bu görev genellikle iş birimlerinden başka görevler üstlenmiş olan, bu konuda herhangi bir yetkinliği olmayan çalışanlardan beklenir. Bu tip bir yazılım projesinin geliştirilmesinde en kritik konu iş ihtiyaçlarının tamamının, en ince detayına kadar doğru ve anlaşılır şekilde tarif edilebilmesidir. Ne var ki bu tarif genellikle sağlıklı olarak yapılamaz. Tarafların aynı dili kullanamaması geliştirilen yazılımda sürekli söylenenle anlaşılan arasındaki farktan kaynaklanan sorunlar doğmasına sebep olur. Aradaki farkın giderilmesi için ardı arkası kesilmeyen toplantılar yapılır, süreçler tekrar tekrar konuşulur, yazılım sürekli en baştan elden geçirilir. Muhtemeldir ki sorunların bazıları giderilir ancak bu defa başka problemler ortaya çıkar. Bu süreç tekrarlamalı (iterative) bir şekilde işlemeye devam eder. Sürecin bu şekilde işlemesi her iki tarafta da belli bir yılgınlığa sebep olur. Proje müşteri planlı takvimin dışına çıkar ve gecikir. Dolayısıyla iş ihtiyacının bir türlü karşılanamıyor olması dijitalleşmeden beklenen faydanın yaratılmasını engeller. Yazılım sağlayıcı için de sürekli tekrarlanan işler maliyetin planlanan çerçevenin dışına çıkmasına sebep olur. Yazılım firmaları da nihayetinde sınırlı kaynakla pek çok yazılım projesini aynı anda idame ettirmeye çalışmaktadır. Sözün özü proje her iki taraf için de tavsar ve heves kaçırıcı hatta can sıkıcı bir sürece dönüşür. O kadar ki, proje tamamlanana kadar baştan doğru yapılan işler bile değişen iş ihtiyaçları sebebiyle âtıl hale gelebilir. Aşağıdaki grafikte yazılım projelerinin başarıyla kapatılma oranları verilmiştir.

Böyle bir süreç yazılımı satın alan kurum için zaman zaman öyle can sıkıcı bir hale gelir ki, yazılım kavramına ve yazılım geliştiren kurumlara güvenini tamamen kaybedebilir ve tüm dijital dönüşüm hikayesi koca bir kabusa dönüşür.

Görüldüğü gibi her iki yöntemde kendi içinde çeşitli avantajlar ve dezavantajlar içerir. Hangisinin daha verimli olacağı ise mevcut durumun ne kadar iyi yönetildiğiyle ilgilidir.

Yazılım Çözümlerinin İç Kaynaklarla Üretilmesi

Tüm bunların yanında üçüncü bir seçenek olarak kurum kendi yazılımını kendi kaynaklarını kullanarak kurum içinde geliştirmeyi de düşünebilir. Ne var ki bu yöntemi hayata geçirebilmek de öncelikle bir yazılım biriminin varlığını gerektirir. Bu durumda, bir yazılım birimi kurmanın, yönetmenin ve sürekliliğini sağlamanın maliyetini düşünmek kritik önemdedir. Öncelikli olarak yazılımcı, özellikle kalifiye yazılımcı, oldukça pahalı bir kaynaktır. Doğru yazılımcıyı / yazılımcıları seçmek de yine bu konuda bir uzmanlık gerektirmektedir. Bunun yanında yazılım profesyonellerinin yönetilmesi de zaman zaman oldukça zor olabilmektedir. Yazılım sektöründe iş değiştirme eğiliminin yüksekliği de düşünüldüğünde kurulan bir yazılım biriminin sürekliliğini sağlamak da oldukça çetrefilli bir sürece dönüşebilmektedir.

Bahsedilen her yöntemin kendine özgü avantajları ve dezavantajları var. Hangisinin daha doğru bir seçim olduğu, elbette ki, tamamen mevcut koşullarla ilgilidir. Öte yandan, belki de başka bir ihtimal daha vardır.

O da bir sonraki yazının konusu olsun mu?



Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir