Bir IT çalışanısınız. IT projelerini yürütürsünüz, yada sistem analistliği yaparsınız. Bir gün bir haber gelir; şirketiniz başka bir şirket ile birleşmeye karar vermiştir. Ya da portföyünün bir kısmını başka bir şirkete devretmeye karar vermiştir.Bu konudaki çalışmaları yürütmek üzere oluşturulan çalışma grubunda siz de bu grubun IT işleri yürütmekten sorumlu kişisi olarak seçilmişsinizdir.
Bir IT çalışanısınız. IT projelerini yürütürsünüz, yada sistem analistliği yaparsınız. Bir gün bir haber gelir; şirketiniz başka bir şirket ile birleşmeye karar vermiştir. Ya da portföyünün bir kısmını başka bir şirkete devretmeye karar vermiştir.Bu konudaki çalışmaları yürütmek üzere oluşturulan çalışma grubunda siz de bu grubun IT işleri yürütmekten sorumlu kişisi olarak seçilmişsinizdir.
Şirket birleşmeleri IT açısından çok sancılı süreçlerdir, Farklı veritabanlarında, farklı platformlarda geliştirilmiş çok farklı uygulamalar yine birbirinden çok farklı veriler üretmektedir. Nelerin birleştirileceği, nelerin olduğu gibi korunacağı, neyin hangi eski işin yerine geçeceği hep belirsizdir. Bunları siz sorana dek hiç kimse düşünmemiştir, böyle bir konu olabileceği genellikle kimsenin aklına da gelmez.
Bu konuda en çok sıkıntı yaratan şeylerden birisi de, büyük projeler olan bu tip çalışmaların proje yönetimi felsefesi hiç kullanılmadan çözülmeye çalışılmasıdır. Son derece zorlu ve riskli olan bu çalışmanın babadan kalma yöntemler ile yapılmaya çalışılması; süreci uzatmakta, risklerin engellenmesine fırsat vermemekte ve beklenen maksimum yararın elde edilmesini engellemektedir.
Konuya her iki açıdan da bakarak ilerleyelim.
Proje Yönetimi Felsefesi uygularsanız; önce varılması istenen hedef, ortaya çıkması beklenen ürün/hizmet net olarak tanımlıdır. Bir proje ekibiniz vardır. Eğer babadan kalma bir yöntemle ilerliyorsanız; hedef tek kelimeliktir “ birleşiyoruz”. Ne yapılması gerektiğini çözmek olası değildir. Ekibiniz yoktur, zorla insanları bulmaya ve bu işe zamanlarını ayırmaya çalışırsınız. Çünkü insanların acilen bitmesi gereken daha başka işleri de vardır.
Proje Yönetimi Felsefesi uygularsanız; hedeflenen ürüne/hizmete varmak için neler yapılması gerektiğini adım adım ilerleyerek planlayabilirsiniz, her yapılması gereken adım için sorumlular atayabilir, süre, bitiş tarihi tahmini yapabilirsiniz. Böylece sürecin takılabileceği, sıkışabileceği yerleri önceden görür ve gerekli tedbirleri alabilirsiniz. Eğer babadan kalma bir yöntemle ilerliyorsanız; neler yapılması gerektiğini ancak durumlarla, olaylarla yüzyüze geldiğinizde hesaplamak durumunda kalırsanız. Süreci ancak takıldığında görür ve önlem almakta geç kalırsınız.
En önemlisi; olası risklerin yönetimidir. Babadan kalma bir yöntemle belirgin 2-3 riski görebilir, önlem çalışmaları yapmakta yetersiz kalırsınız. Maliyet yönetimi, insan kaynakları yönetimi gibi konular zaten ilgi alanınız dışında olacaktır.
Varılması istenen nokta çok önemlidir.
Hangi veritabanı kullanılacak. Farklı veritabanları korunacak mı yoksa birleştirilecek mi? Örn. Her iki şirketinde verisi aynı tip veritabanı üzerinde duruyor ise; en azından bu konuda bir birleşme gerçekleşebileceği öngörülebilir.
Peki iş yapma şekilleri değişecek mi? Çünkü iş yapma şekillerinin değişip değişmeyeceği de burada çok belirleyici olacaktır. Şirketler kendi iş yapış şekillerini koruyacaklar ise bu türden bir birleşmenin gereği de olmayabilir. Sadece günlük, haftalık, aylık gibi belli periyotlarda bilgiyi özet halinde diğer taraftaki veritabanına yazmak ve raporları ortak alınabilir yada konsolide edilebilir kılmak yeterli olacaktır. Bu nedenle öncelikle hangi özet bilgilere nerede ve hangi zaman dilimlerinde ihtiyaç duyulduğunun net olarak belirlenmesi gerekmekte. Özet bilgilerin formatı da son derece önemli. Yazılacağı veritabanının ve ilgili dosyanın yapısına uygun olması zorunlu. Şirketlerden birisi en büyük 10 haneli fiyat verisi ürettiği için dosyadaki ilgili alanın uzunluğunu buna uygun olarak belirlemiş olabilir. Eğer eklenecek veri 12 haneli rakamlardan oluşacak ise bu ekleme sırasında sorun yaratacaktır. Yada ürün tanımlarının bir şirkette nümerik değerler ile ifade edildiğini, diğer şirkette ise karakter değerler kullanıldığını varsayalım; bu da bir sorun yaratacaktır. Aynı şekilde şirketlerin ürün, kapsam v.b. tanımları da birbiri ile çakışıyor olabilir. Bu nedenle ilgili kişiler ile görüşerek istenen birleşme yerleri, şekilleri ve oranları tam olarak tanımlandıktan sonra; detay çalışmaya başlayarak yukarıdaki gibi olası alt sorunların çözümü gerçekleştirilir.
Unutmamak gerek ki; dönüşüm çok zorlu bir süreçtir. Aklınıza gelmeyecek pek çok zorluk ile karşılaşırsınız. Hedefin, kaynağın ve arada hareket edecek verilerin çok iyi tanınması, analiz edilmesi gerektir. Verilerin hareket şeklini belirleyen şartların, kuralların iyi tanımlanmış olması ve bunlar yönetecek riskleri de göz önüne alan bir sistem kurulmalıdır.
Burada önerilebilecek ilk şey; varılmak istenen hedefin ne olduğunun belirlenmesidir. Tüm datalar birleştirilecek mi? Birleştirilmiş data üzerinde işlemler yapılacak mı? Veriler herhangi bir başka tabloyu besleyecek mi? Veriler özet haline getirilerek mi besleme yapacak? Birbiri ile eşlenebilir unique alanlar var mı? Bu ve bunun gibi soruları oluşturduktan sonra yanıtlara göre kaynakları değerlendirmek gerekir.
Sigorta sektörünü ele alalım. Sağlık Dışı Elementer Branşlar ile Sağlık Branşının birleşeceğini varsayalım. Diyelim ki; müşteri veritabanlarını birleştirmeye karar verildi. Olası sorunlar nelerdir? En başta sigortaya konu olan nesne her iki branşta birbirinden farklıdır. Sağlık branşında nesne insan iken diğer elementer branşlarda otomobil, ev, fabrika, üretim makinesi, taşınan mal, tarladaki ürün, denizde yol alan gemi olabilir. Bu durumda müşteri bilgisi olarak tuttuğunuz başlıklar birbirinden son derece farklı olacaktır. İnsan için ad, soyadı, doğum tarihi, adres, telefon, TCKN, VKN, anne-baba adları söz konusu iken bu bilgilerin hiçbiri diğer elementer branşlarda sözkonusu olamaz. Yani veri desenleri kesinlikle farklıdır.
Diyelim ki iki sağlık sigortası şirketi birleşiyor, veri desenleri de birbirine benzetilebilir durumda. Bu durumda alanların yapılarının uygunluğu kontrol edilmelidir. En önemlisi de unique olarak müşteriyi tanımlayan numaranın yani id’nin yapısının nasıl olduğudur. Alan tanımı benzer mi, uzunluklar uygun mu gibi sorulardan sonra çakışan id numaralarının ne yapılacağı konusu akla gelecektir. Buna bulunan herhangi bir çözüm bu id numaralarını kullanan tüm diğer dosyalar ve programlarda da değişiklik yapılması, müşteri elinde de bu bilgiyi taşıyan her türlü belge, kart v.b.’nin değiştirilmesi anlamına gelecektir.
Böyle bir birleştirmenin yapılıp yapılmaması için maliyetleri, riskleri, olası faydayı da göz önüne alarak kararın verilmesi gereklidir.
Burada şöyle bir çözüm geçici olarak kullanılabilir. Her iki numaranın da bağımsız kullanımı devam eder, zaman içersinde geçişi ve müşterilerin tekleştirilmesini sağlamak üzere yeni bir sayaçtan verilmiş yeni bir 3. müşteri numarası tüm müşterilere yeniden verilebilir. Böylece devam eden dönemde bu yeni numaraya geçiş sağlanırken ilgili tüm belge, kart v.b. de değiştirilebilir.
Değerlendirme yapılırken belki de en kritik noktalardan bu veriyi oluşturan unsurların aynı hizmeti aynı şekilde alıp almayacağıdır. İki sağlık sigortası şirketi birleşiyor ise ve müşterilerine aynı hizmeti, aynı ürünü, aynı şartlarda sunacaklarsa birleştirme kararı nerede ise kaçınılmazdır. Burada yapılacak işin maliyeti ve riskleri büyük proje için nasıl aksiyon alınacağına karar vermek için hesaplanmalıdır. İki ayrı sistemdeki bilgiler ile iki ayrı gruba aynı ürün ve hizmeti aynı kalitede sunmak daha fazla problem yaratacaktır. Aynı hizmeti aynı kalitede vermek için aynı işin her iki sistemde ayrı ayrı iki kere yapılması kaçınılmazdır. Ancak veritabanları aynı olamayacağı için benzer sonuçlara ulaşılmasında ciddi problemler yaşanacağı, çift işlemlerin kaynak ve zaman israfına yol açacağı da dikkate alınmalıdır. Bu problemler ancak gruplardan biri küçük ise, büyük grubun içinde eritilebilir ise veya erimeye yönlendirilebilir ise tahammül edilebilir olacaktır.
Veritabanlarının birleşmesi kendi başına bir problem olmakla birlikte tek problem değildir. Devamında başka problemlere de yol açacaktır. Bu veritabanlarını kullanan çok sayıda program olacaktır. Yapılacak her bir değişikliğin bu programlarında değişmesine neden olacağı, bazı programların gerekli veriye ulaşamaz hale gelebileceği de dikkate alınmalıdır. Bunlar için de hazırlık planları yapılması uygun olacaktır. Etkilenecek tüm uygulamaların envanterini çıkartmak, etkilenme noktalarını belirlemek, öncelik sırası tanımlama ve bağlantılı yapılması gerekenleri belirlemek son derece yararlıdır. Daima unutulmuş, atlanmış bir takım uygulamalar olabileceğinden bu çalışma için bitiş tarihini proje bitişinden önceye tanımlamak çok uygun olacaktır. Yeterli test süresinde eksikliği fark edilen uygulamalar bu ara dönemde tamamlanabilirler.
Yapılacakların üstünden geçecek olur isek; Önce birleşme veya birleşmeden kalarak bilgi sistemlerini besleme yöntemlerinden birinin tercihi yapılmalı.
Eğer birleşmeden kalma yönünde bir karar çıkar ise; beslenecek tüm tablolar belirlenmeli, besleme periyotları tanımlanmalıdır. Daha sonra besleme yapılacak tablolar için kurallar tanımlanmalıdır, beslemede kullanılacak verinin ayırt edici biçimde tanımlanabilir olması sağlanmalıdır. Bunun için pek çok geçiş tabloları kullanılması gereği doğacaktır. Bu tabloların gerekli ekleme, silme ve güncellemeler yapılabilecek şekilde dizayn edilmesi gerekli. Besleme için gerekli transfer işlemlerini yapacak uygulamaların hazırlanması gereklidir. Bu uygulamaların bazıları manuel çalıştırılabilir, programlanmış olarak çalışanlar veya koşula bağlı çalışanlar olabilecektir. Daha sonraki adım ise üretilen raporları, erken görüntüleri, v.b. üzerinde yapılacak çalışmalardır. Bir süre için veriler konsolide edilmiş ancak ayrımlı olarak incelenmek istenebilir. Bu nedenle gerekirse ayrımlı sonuç verisi üretebilecek hazırlığı yapmakta fayda var. Ve tabi verileri mevcut halleri ile arşivlemek de asla unutulmamalı.
Birleşme yönünde karar verilmesi durumunda ise yapılacaklar daha zahmetli olacak. Çünkü artık bir dönüşüm projesi de yapılması gerekecek. Birleşme sadece verilerin bir araya getirilmesi değil, herhangi bir veri yada değer kaybı yaşanmadan anlamlı bir bütünlük sağlanması demektir.Eğer tüm veriler birleştirilecek ise; yani müşteri bilgisi müşteri bilgisine, ürün bilgisi ürün bilgisine birleştirilecek ise her adımın dikkatlice planlanması gerekecek. Veriler mevcut halleri ile birleştirilemeyeceklerdir. Bu nedenle birleştirilebilir hale getirmek, birbirine benzetmek üzere çalışmalar yapılması gerekecektir. Çakışan tanımlar, bilgiler, aynı veri tipini tanımlayan farklı alan tanımları gibi pek çok sorun ile karşılaşılacaktır. Bu nedenle her iki veri grubu da dikkatle incelenmeli, problem noktaları saptanmalı ve çözümler üretilerek işleme başlanmalı.
Risk yönetimi, dönüşüm projelerinde üzerinde ciddiyetle durulması gereken bir kavramdır. Olası riskleri öngörmek, olası çözümleri kararlaştırmak ve bunların maliyetlerini öngörmek projenin sağlıklı ilerleyişi açısından elzemdir. İnsan kaynakları yönetimi de önemli bir kavramdır. Projenin çeşitli aşamalarında birimlerden, veri tabanı yöneticilerinden, uygulama geliştiricilerden uzmanlık alanlarına göre bilgi almak ve kaynak olarak yararlanmak gerekecek. Bu nedenle insan kaynağının doğru planlanması oldukça önemli. Yapılacak projenin maliyetinin yönetimi de yine çok önemli bir kavram. Yapılacak her hamlenin, direkt para ile ifade edilebilir veya paraya çevrilebilir maliyetleri olacaktır. Ayrıca olası veri kaybı, hizmet niteliği değişimi, geçici kalite kaybı, bilgilendirme gibi ek maliyetlerinde oluşacağı dikkate alınarak planlama yapılmalıdır.
Özetle söylemek gerekirse; bu tip büyük dönüşüm projelerinin yönetimi babadan kalma yöntemler ile yapılıyor ise proje yöneticisinin yardımcısı sadece Tanrı olabilir. Ama proje yönetimi felsefesi ile yönetiliyor ise; tüm proje yönetimi araçları ve bilgi sistemleri de yardımcı olacaktır.
Anita BARİN