Bilgi Teknolojilerinde Değişimi Yönetmek

Herakleitos’un günümüzden yaklaşık 2500 yıl önce de dediği gibi “Değişmeyen tek şey değişimin kendisidir.”.

İhtiyaçların, standartların, yasaların, bağlı sistemlerin ve paydaşların sürekli değiştiği sistemlerde de değişim kaçınılmazdır. Değişimi nasıl yöneteceğimiz ise her ne kadar bize kalmış olsa da, minimum gereksinimler için standartların bizi nerelere yönlendirdiğini izlemekte fayda olduğu gözardı edilemeyecek bir gerçektir.

Gelişmiş ülkelerde standardizasyon önem verilen bir konu olduğu için yıllardır uygulanan teknikler olsa da ülkemizde BT ekipleri/şirketleri değişimi yıllarca yönetmedi. İhtiyaç duyulmadı diyenler de olabilir ama benim görüşüm farklı, ihtiyaç her zaman vardı ama BT’nin iş süreçlerindeki önemi henüz anlaşılamadığı için değişimin yönetilmesi hep geri planda kaldı.

BT sistemlerinin bağımsız çalıştığı ve sayılarının az olduğu zamanlarda her ne kadar kişiye bağımlılık problemi olsa da değişimi insanlar üzerinden yönetmek kolaydı. Çalışan, sorumlu olduğu sistemin tarihçesini de bildiği için dokümante edilmemiş olsa da çalışabilir ve karar verebilir durumdaydı.

Bu durum uzun süre sorun yaratmadı, çalışan orada olduğu sürece sorun çıkmayacağı fikri yönetimlerin kafasında yer etti etmesine ama bu durum da BT birimleri içerisinde kendini geliştirmeyen, varolan sistemi devam ettirme (statüko) üzerine çalışan dinozorların yer etmesine yol açtı.

Dinozorlar statükoyu koruma konusunda iyiydiler, sistematik çalışmamaları sebebiyle dokümantasyon ve kayıt tutma en düşük seviyede kaldığından anlık maliyetleri de düşük kalıyordu fakat işin kalite maliyetleri göz önüne alınınca yaptıklarının yanlış olduğu ortadaydı. Dolayısıyla sistematik bir değişim yönetimi BT için de ihtiyaç durumuna geldi.

Dinozorların diğer bir kötü etkisi de gelişime açık, genç ve arzulu elemanların ekipten ayrılması yönünde oldu. Statükoyu devam ettiren şirketler yeni ve iyi elemanları elinde tutmakta zorlanırken, dinozorlara ayak uyduran ve değişime/gelişime ayak direyen çalışanlar kadroları doldurdu. Bu da şirketlerin günü yakalamasının önünde günden güne büyüyen bir engel haline geldi.

Son yıllarda sistemlerin sayısının artması ve karmaşıklaşmasının yanısıra entegrasyonların da hayatımızın daha büyük parçaları olduğunu düşündüğümüzde değişimin etkilerinin de paralel olarak büyüdüğünü de anlamak için alim olmaya gerek yok. Bağımsız sistemlerde tek kaynaktan gelip tek ya da az sayıda kaynağı besleyen veriler artık hayatımızın parçaları değiller. Farklı kaynaklardan toplanıp, farklı sistemleri besleyen verilerle karşı karşıyayız. Dijital dönüşümün hızlandığı, nesnelerin interneti ve endüstri 4.0 konseptlerinin de sistemlerimiz arasındaki bağlılığı günden güne arttırdığı bir süreçte oluşan büyük verinin yönetilebilir olması daha da önemli oldu.

Büyük veri diyoruz ve genelde dinozorlar büyük veriyi bir ebat sorunu olarak algılıyorlar. Sorunun bir boyutu elbette verinin çok olması ama diğer bir boyutu da farklı sistemler arasında dağınık olması. Bu dağınık veriyi yönetemedikten sonra toplanan veri bizim için depoladığımız çöpten başka bir şey değildir. Yönetimi içinse sistemlerdeki değişimin etki ve risklerinin yönetilebilir olması gerekmektedir.

ITIL çerçevesinde bir geçiş süreci olarak tanımlanan değişim yönetimi süreci de donanımdan yazılıma, veri yönetiminden ağ yönetimine tüm sistemlerdeki değişikliklerin kayıt altına alınmasından canlıda sorunsuz halde çalışmasına kadar geçen sürede yapılması gerekenleri standardize ederek değişimin kontrollü bir biçimde gerçekleşmesini yönetmeye yarıyor.

Minimum gereksinimler bazında baktığımızda değişim yönetimini 5 adımda özetlesek de diğer süreçlerle bağlantılarının ne kadar derinlere gittiğini gördükçe aslında BT Hizmet Yönetimi’nin ne kadar geniş bir alan olduğunu ve tekil süreçlerden ziyade bir ağ gibi, BT’nin her yerinde uygulandıkça daha iyi sonuçlar ortaya çıkaran bir yönetim sistemi olduğunu görebiliriz.

Adımlara ve bizden istenen minimumlara gelirsek;

1. Request for Change: Değişiklik Talebi… İstenen değişimin kayıt altına alınması adımıdır. Olay ve talep yönetimi süreçleri ile doğrudan ilişkilidir.
2. Impact Analysis: Değişikliğin etki ve risklerinin analiz edildiği adımdır. Konfigürasyon yönetimi süreci ile doğrudan ilişkilidir.
3. Approve / Deny: Onay adımımız. Değişiklik Değerlendirme Kurulu (Change Advisory Board) ile değişikliğin etkilerinin değerlendirildiği bir görüşme yapılır. Değişikliğin zamanlaması ve bağımlılıkları konusunda paydaşların fikri alınır.
4. Implement Change: Değişikliğin gerçekleştirildiği adım. Geliştirme, test ve devreye alma adımları burada işler. Devreye alma ve konfigürasyon yönetimi süreçleri ile doğrudan ilişkilidir.
5. Review / Reporting: Devreye alınan değişikliğin etkilerinin canlıda izlendiği adımdır.

Doğrudan ilişkili süreçlere ek olarak değişikliğin içeriğine göre kapasite yönetimi, tedarikçi yönetimi, bütçe yönetimi gibi diğer hizmet yönetimi süreçleri ile de etkileşim olabilir.

Değişim Yönetimi ayrıca yazılım ve sistem geliştirme yaşam döngüsü ile birebir örtüşen bir akışa sahiptir. Analiz, geliştirme, test ve canlıya alma süreçleri birebir değişim döngüsü içerisinde ele alınır. Günlük operasyonlardan oluşan bakım süreci ise yeni değişiklikleri tetikleyerek döngüyü tamamlar.

Sürecin başında tanımlı bir değişiklik yöneticisi bulunması gerekmektedir. Değişiklik Denetleme Kurulu’nun toplanması ve değişiklik onaylarının verilmesi gibi önemli görevler bu yöneticinin sorumluluğunda işleyen görevler olsa da süreç tüm ekibin ahenkli çalışması ile doğru sonuç verir.

Takım çalışması, değişimin yönetilebilmesi için olmazsa olmazdır.

Değişimden etkilenen ve değişimi etkileyen tüm birimlerin ortak bir amaç için, yani değişimin başarılı sonuçlaması için birlikte çalışması bizi doğru sonuca götürür.

Kaçınılmazdan kaçmadan, değişimin ve gelişimin yanında, en doğru sonuçlara ulaşabilmek için bir ekip olarak uyguladığımız değişim yönetimi, kurumsal BT yönetiminde günü ve geleceği kurtarır.