Bankacılık Sistemi'nde Proje Yönetimi'ne Neden İhtiyaç Var? (Why in the Banking Sector needs to the Project Management?)

Bankacılık Sistemi'nde Proje Yönetimi'ne Neden İhtiyaç Var? (Why in the Banking Sector needs to the Project Management?)

Maliyetleri düşürmek mi? Verimliliği arttırmak mı? (Reduce Costs or Increase Productivity)

Cevabı, hayatın içerisinde uygulanan üç farklı model üzerinden verebiliriz.


1. Model : Kapalı devre projelerde uygulanan laboratuvar modeli (Laboratory model used in closed circuit project.)

Bankacılık sektörü, Türkiye'de yaşanan 2000-2001 yılı krizi ile devlet ve bankalar arasında elzem hale gelen online çalışma sistemine geçiş yapmak zorunda kaldı.

Krize neden olan ekonomik daralma sonrası bankacılık sektöründe ortaya çıkan yolsuzlukların geleceğe taşınmaması için, mudilerin varlıklarının eş zamanlı olarak devlet denetimine alınmasına karar verildi. Sonuç olarak mevzuat değişikliğine gidildi. Bu durum IMF ile 2001 yılında yapılan Stand By anlaşmasında ana konulardan biri oldu. Yani bankalar hem devletle hem de kendi içinde online çalışmak zorundaydı artık. Süreç, bankaların teknolojik altayapısında değişime ve bankacılık önyüzlerinde yeniden yapılanmaya ivme kazandırdı.

Fona devrolan bankalar, birleşen bankalar, merkezi sisteme geçen bankalar (işlem şubede gerçekleştiğinde kayıdın banka genel merkezine ait server'da eş zamanlı olarak tutulması) vb. pek çok farklı durumdaki işletme elden geçti. Bu sayede bankacılık sektöründe yeni bir dönem başlamış oldu. Yani kısacası online data transferi gerçekleşti. Artık mutabakatlaşma gün sonunda yapılmayacaktı. Türkiye'de yaşanan en büyük çaplı projelerin geliştirildiği bu dönemde kapalı devre projeler oldukça yaygınlaştı. Çünkü halihazırda online olmasa da işleyen mevcut bir sistem vardı ve ekonomiye yön veren, paranın akışını sağlayan bankalar, yeni bankacılık paketlerine herşey tamamlandıktan sonra (yani riski minimize ederek) geçmeyi tercih ettiler.

Sistem Analist, yazılım mühendisi ve database admin'in bir toplantı odasında günlerce kampa girip 'brainstorming' beyin fırtınası'nı gerçekleştirdiği, makina parkından (sever özellikleri ve yüklenecek yazılımlar vb.), network alt yapısına (kullanılan bant genişliği, herhangi bir kesinti anındaki caseler vb.), kullanılacak tabloların dizaynından, güvenlik için oluşturulacak yapıya kadar, kapsam ve analizlerin birlikte hazırlanıp birlikte sorguladığı, banka tarafında iş koluyla yapılan toplantılara birlikte katılınan bu model, ancak bir laboratuvar ortamında gerçekleşebilir ki bu da kapalı devre projelerde mümkün.

Bu işleyişte sistem analist temel bir yazılım bilgisine sahiptir. Yazılım mühendisi de belli bir mevzuat ve iş bilgisine sahip olmak durumdadır ve tabi sistem analist aynı zamanda proje yönetimi yapmaktadır. Ayrı bir proje yönetim grubu bulunmamaktadır. Kapalı devre projelerde ayrı bir proje yöneticisi kullanmak hem maliyetli hem de işi yavaşlatan bir tercih olarak kabul edilmektedir.


2. Model: Çatışma yöntemini benimseyen model (Adopting the model of conflict management)

İşleyen bir bankacılık pakedi bitmiş demek değildir. Her geçen gün yeni bir ürün veya mevzuat değişikliğine bağlı modifikasyonlar söz konusu olacaktır ve deadline'lar kısa vadelidir. Bu işleyiş zannedildiğinden çok daha fazla iş yükü ve stres içermektedir. Hatayı minimize etmek ve mükemmel bir sonuca yaklaşmak için 'çatışma yöntemini' kullanan bankacılık sektörüne ait IT grupları, bu işleyişte iş danışmanlığı ve yazılım geliştirme olmak üzere iki temel gruptan oluşuyor. Bu iki grubu domine edecek hakem heyet ise 'PMO- Proje Yönetim Ofisi'dir.

İş danışmanlığı grubu, banka tarafındaki iş koluyla kapsam ve analizi diğer gruplardan bağımsız olarak hazırlar. Kapsam ve analiz tamamlandıktan sonra yazılım geliştirme grubu ile bir toplantı odasında iki taraf birer gladyatör gibi çarpışır. Bütün eksikler ve hatalar bu çarpışmada masaya konur. Ne yapılabilir, ne yapılamaz, ne mantıklı, ne değil,ne düşünülmüş, ne düşünülememiş... vb. Proje yöneticisi olaya tanıklık eder, düzeltmeler için deadline verilir, yazılım süreci için deadline verilir, test süreci için deadline verilir, tüm proje kaç adam /gün eder hesabı yapılır ve yazılım süreci başlar. Test sonunda 'Son kullanıcı memnuniyeti' işin başarısının ölçüsüdür. 'Zaman yönetimi' ise proje yöneticisinin başarısını belirler.


3. Model: Güçlerin birleşmesi modeli (Merger model of power)

Bu çalışma biçiminde 'analist yazılımcı' ve proje yöneticisi yer alır. Yani ayrı bir sistem analist yoktur. Yazılımcı hem business bilgisine sahip olmalıdır hem de arka alan veya mutfak dedilen alanda yazılım yapıyor olmalıdır. Bu gibi bir işleyişi tercih eden şirketler daha çok maliyeti düşürmek isteyen orta veya küçük ölçekli gruplardır.

Özellikle outsource edilen, riski düşük, küçük projelerde işi hızlandırmak için bu yöntem yaygın olarak kullanılıyor. Analist yazılımcılar, gelecekte de birer proje yöneticisi adayıdır.
3 modelin ortak sonucu ise, verimliliği arttırmak, maliyetleri düşürmek, kaliteli iş ortaya koymak, zaman yönetimi, son kullanıcı memnuniyetini sağlamak ve riski azaltmak... eğer yapılamazsa, bir ülkede dolandırılamayacak sektör yoktur.


PEM 360

Bu konuda yapılmış yorum bulunmamaktadır.
İlk yorumu siz yapmak için aşağıdaki formu doldurun.

Yorum Yaz