BT dünyasında teknoloji değişim projeleri neden başarısız olur?

Çalışan sistemlerin de belli bir ömrü var, onlar da zaman içinde istenilen şekilde çalışamaz, onunla uyumlu çalışacak yeni sistemler bulunamaz olur. Bu yüzden BT dünyasında bir zamanların şampiyonu mainframe uygulamaları yerini yeni nesil sistemlere bırakıyor. Bu teknoloji geçiş projelerinin kimisi ise başarısızlıkla sonlanıyor. Başarısızlığın nedeni seçilen teknoloji mi, oluşturulan sözleşmeler mi, kullanılan kaynaklar mı, yoksa yönetim mi?

 Mainframe üzerinde geliştirilmiş “Core Banking” uygulamalarının modernleştirilmesi projelerinde yaşanılan başarısızlıkların nedeninin teknolojiden ziyade insan ve yönetim olduğu sık sık tekrarlanır. Özellikle sınır ötesi çalışan legacy sistemleri kullanan yerel bankalardan ilgili mercilerin sistemlerin sınırlar dahiline çekilmesi talepleri nedeni ile modernleştirilme projeleri bir dönem hayli hızlanmıştı. Günümüzde de 80’li yılların veri tabanlarını ve eski nesil dillerini halen kullanan kuruluşları var ve bunlar da ortamlarını modernleştirmek arzusundalar. Bu istemlerin arkasında yer alan nedenlerine bakıldığında; dönemin analist-programcılarının emekli olmaya başlaması, gençlerin antik diye nitelendirdikleri bu ortamlara ilgisizliği, bu dilleri bilenlerin sadece “off-shore” olarak ulaşılabilmesi vb sebepler sıralanır. Öte yandan talebi olan modernizasyon projelerinde bir yandan da hayli büyük hatalar da yaşanır.

Teknolojiyi yoğun ve iyi kullanan sektörlerden biri olan bankacılık dünyasında bile bu tip projeler neden başarısız olur ki? Proje yöneticileri daha önce yaptıkları geçişlerin, işletim sistemi değiştirilmesi, veri tabanı güncellemesi şeklinde parçalı işlerin, her dekat benzeri işleri yapmış olan takım üyelerinin bir sonraki dekat değişmesi veya emekli edilmesi nedeniyle olabilir mi? Hem iş akışı, hem veri tabanı, hem programlama dili hem önyüz hem sunucu hem de bağlantıların aynı anda değiştirilmesinden dolayı mıdır? Projenin baştan sona yönetiminin sadece BT takımına verilmesinden midir? Zamanlama konusunda yoğun baskı olmasından mıdır? Yoğun olarak rastlanılan kapsam değişiklikleri ve değişim yönetiminin başarısızlığından mıdır? O halde herhangi bir kuruluşta programlar farklı platformlara taşınırken (recomission), kullanılan programlar emekli edilirken (decomission) nelere dikkat edilmelidir?

Öncelikle proje sadece BT’nin veya iş biriminin projesi olmayıp ortak yapılacak bir proje olduğu taraflarca kabul edilmelidir. Hem tedarikçi hem de müşteri değişimin amacı kesin ve net bir dille ifade etmeli ve yazılı hale getirilmelidir. Test senaryoları yeteri kadar detaylı oluşturulmalıdır. Zamanlama konusunda herkes mutabık kalmalıdır, Niteliklerinden emin olunan kaynaklar kullanılmalı, proje süresince kaynak değiştirilmemelidir. Proje planı detaylı yapılmalı, riskler ve sorunlar sıkı takip edilmelidir. Kapsam genişlemesinin proje süresince mümkün olduğunca yapılmaması, olmazsa olmazların değişim yönetimi çerçevesinde yönetilmesi sağlanmalıdır. Böylesi sistemlerin en büyük sorunu, uygulamaların iş akışları ve güncel dokümantasyonlarının olmamasıdır.

Her başarılı değişimin arkasında işini bilen ve layığı ile yapan insanlar yer alır ki bu kaynakların hayli önceden emekli edilmiş olması veya farklı kuruluşlara geçmesi projelerin başarısızlığını getirir. Hele hele taşeronlaştırılan hizmetlerde “software-as-a-service” ya da “platform-as-a-service” olarak dışarı verildikten sonra bunun zamanla daha farklı bir tedarikçiye zaman içinde geçirilmesi çok maliyetli ve riskli işler olmaktadır ki yapılacak sözleşmelerde bu konular göz ardı edilebilmektedir.

Sonuç olarak Türkçemizdeki deyiş güzel özetliyor “ekmeği ekmekçiye vereceksin üzerine de bir ekmek vereceksin.” Seçilecek teknoloji, çalıştırılacak kaynaklar, oluşturulacak sözleşme ve tüm bu bileşenlerin doğru yönetimi başarılı geçiş için önemlidir.