Aslında rehber prensiplerden ikincisini yazıyordum. “Bulunduğun yerden başla” diyor ikinci prensibimiz. Ama güncel gelişmeler ve sizlerden gelen sorular üzerine araya bir başka konuyu almak istedim. Konumuz ITIL’da değişikliklerin nasıl yönetileceği. “Okullar olmasaydı Milli Eğitimi ne güzel idare ederdim” sözünü duymuşsunuzdur. Benzeri aslında BT için de geçerli: “Şu değişiklikler olmasa; hizmetleri, BT’yi ne güzel idare ederiz!”
Öncelikle genel yanılgıyı bir ortaya koyalım: Türkiye’de bir çok BT organizasyonu değişiklik yönetimini değişiklikleri yapmak / devreye almak olarak görüyor. Halbuki ITIL’da öncelikli amacımız değişiklikleri yapmak ya da devreye almak değil, değişiklikleri yapabilir hale gelebilmek!? Peki ama ne demek bu “değişiklikleri yapabilir hale gelmek”?
Değişiklikleri yapabilir hale gelmek (Change enablement)
Yine en temelden başlayalım, ilk tanımımız değişiklik – change.
Change:
The addition, modification ore removal of anything that could have a direct or indirect effect on services.
Değişiklik:
Hizmetleri doğrudan veya dolaylı etkileyebilecek her türlü ekleme, çıkartma veya modifikasyon.
Tanım oldukça kapsamlı. Bu tanım içerisine altyapı değişiklikleri de giriyor, uygulama değişiklikleri de. Süreç üzerindeki değişiklikler de bu kapsamda, tedarikçi değişiklikleri de.
Değişikliklerin olası olumsuz etkilerinden kullanıcıları/müşterileri korumak; değişiklilerin daha başarılı bir şekilde yapılabilmesine yardımcı olmak istiyoruz. Hatta sadece gerekli, bize veya tüketiciye değer katacak değişikliklerin yapılabilmesini sağlayalım istiyoruz.
Eskiden “change management” – değişiklik yönetimi – olarak adlandırılan süreç, ITIL 4 içerisinde değişiklikleri mümkün kılma/etkinleştirme/yapabilir hale gelme anlamına gelebilecek “change enablement” olarak güncellenmiş. Yani şimdiye kadar yapmadıysak da, gerçekten değişikliklerin yönetimi ile ilgili algımızı değiştirmemiz gerek!
Değişikliklerin olası olumsuz etkilerinden kullanıcıları/müşterileri korumak; değişikliklerin daha başarılı bir şekilde yapılabilmesine yardımcı olmak; hatta sadece gerekli, bize veya tüketiciye değer katacak değişikliklerin yapılabilmesini sağlamak amacımız.
Peki ITIL ne yapılmasını öneriyor “değişiklikleri yapabilir hale gelme” işleyişinde:
- Önce değişiklikleri kayıt altına alalım,
- Daha sonra değişiklikleri etkileri ve riskleri açısından değerlendirelim,
- Bir onay mekanizmasından geçirelim,
- Onaylanan değişikliklere ilişkin bir takvim oluşturalım.
Bakmayın sadece bu kadar temel aktivite olduğuna, bu aktivitelerin her biri son derece kritik, önemli aktiviteler.
Kayıt altına almak
Örneğin değişiklikleri kayıt altına almak başlı başına bir iş. BT ekiplerinin yaptıkları tüm değişiklikleri kayıt altına almasını sağlamak, inanın deveye hendek atlatmaktan çok daha zor.
BT ekipleri dokümantasyondan hoşlanmaz, kayıt altına almayı sevmez. Ama değişiklikleri disiplinli bir şekilde kayıt altına almaya başladığımızda bir liste oluşturmuş oluyoruz. Bir değişiklikler listesi. Belki bir sorunla karşı karşıya kaldığımızda elimize alıp sorgulayacağımız bir liste. “En son neyi değiştirmiştik?” sorusuna cevap bulabileceğimiz bir liste.
Boşu boşuna eski BT’ciler “çalışan sisteme dokunulmaz” dememişler, yapılan her değişiklik beraberinde belirli oranda bir risk barındırıyor. Hayatımızda Murphy gibi bir şahsiyet de var 😊. E bu durumda elimizde en azından bu listenin olması, “neye dokunduk da bu arızalar ile karşı karşıya kaldık?” sorusunun cevabını bulmamızda bize yardımcı oluyor.
Değerlendirmek
Peki gerçekleştirmek istediğimiz değişikliği kayıt altına aldık, şimdi ne yapacağız? Şimdi sıra değişikliği değerlendirmeye geldi.
Bu değişikliğin neden gerektiğini, ne getireceğini, ne götürebileceğini anlamak; değişikliği etraflıca sorgulamak, değişiklik ile ilgili riskleri değerlendirmek; değişikliğin hem uygulanacak olan hizmete/uygulamaya/sisteme, hem de ilişkili çevre hizmetlere/uygulamalara/sistemlere etkilerini öğrenmek gerekli.
Sunucumuzun IP adresini değiştiriyoruz ama acaba bu adres değişikliği farklı uygulamaları etkileyecek mi? Uygulama içerisinde yer alan fonksiyonu güncelliyoruz fakat bu güncelleme farklı modüllere dokunacak mı? Veritabanımızı değiştiriyoruz acaba bu değişiklik farklı uygulamalara nasıl yansıyacak?
Bana sorarsanız değişiklikleri yönetirken en kritik aşama bu aşama. Burada değişiklik gerçekten ne kadar gerekli anlama ve olası riskleri, olumsuzlukları kontrol altına alabilmek için neler yapabileceğimizi belirleme şansımız var.
Değişiklik vs. Değişiklik
Tabii ki değişiklik var, değişiklik var. Bazı değişikliler bir çok farklı sistemi etkileyebilecek veya kritik bir uygulama üzerinde ciddi yansımaları olabilecek riski yüksek değişiklikler. Bazı değişiklikler ise ne ile karşı karşıya kalacağımızı bildiğimiz riski düşük, rutin değişiklikler.
Burada tek bir “ideal” süreç tanımlayıp tüm değişiklikleri bu sürece uygun bir şekilde ele almaya kalkarsak patlıyoruz. Nasıl patlıyoruz?
Ya aslında riski yüksek değişiklikleri hak ettikleri kadar değerlendiremiyoruz, sonra yapılan değişikliğin olumsuz etkilerini yaşamak zorunda kalıyoruz. Ya da küçük bir değişiklik için bile milyon tane gereksiz kontrol yapmak zorunda kalıyoruz, bir dakikalık değişiklik için bile BT ekibi saatler harcamak zorunda kalabiliyor.
O yüzden gerçekleştirilecek değişiklik tipine göre farklı etki/risk değerlendirme çalışmaları yapabileceğimiz bir işleyiş oluşturmak önemli.
Bu aşamada genellikle tek bir kişinin – özellikle değişiklikten sorumlu kişinin – değişikliği değerlendirdiğini gözlemliyorum. Bu yanlış değil ama eksik. Değişikliğin, o değişiklikten etkilenebilecek bileşenlerin sorumluları tarafından – yani bir bakıma farklı açılardan – değerlendirilmesi önemli. Bir kişinin hatta ekibin – özellikle değişikliği gerçekleştirecek kişinin/ekibin – göremediği durumları böylelikle yakalamak mümkün olabiliyor.
Özellikle günümüzde birbiri ile etkileşimli çok fazla uygulama, hizmet, sistem, vb. yönetmek durumundayız. Ufak bir değişiklik bile bir çok farklı bileşene dokunabiliyor. O zaman tüm bu bileşenlerin birbirleri ile ilişkilerini görmemize yardımcı olabilecek bir araç (ya da ağaç) çok faydalı olur sanki. Buradan diğer başka ITIL pratiklerine/süreçlerine selam gönderelim. 😊
Onaylamak
Değerlendirilen değişikliklerin daha sonra onaylanmasına geldi sıra. Burada da tek/sabit bir onay mekanizması oluşturmak yerine esnek hareket etmek yerinde olacaktır. Değişiklik onayı bir kişi tarafından verilebileceği gibi değişikliğin kapsamına göre bir kurul oluşturulabilir. Hatta duruma göre üst yönetim bile onay konusunda devreye girebilir.
Değerlendirilen değişikliğin tipi, değişiklik konusu, söz konusu değişiklik ile ilgili riskler, etki alanı, vb. çeşitli faktörler göz önünde bulundurularak bir onay mekanizması oluşturmakta fayda var.
Sıklıkla gördüğüm kötü bir alışkanlıktan bahsetmek istiyorum bu noktada. Bu değerlendirme ve onay konusu ne yazık ki, bir çok BT ekibi tarafından gereksiz görülüyor. Her ne kadar başlangıçta iyi niyetlerle kurgulanmış bir işleyişimiz olsa da, zaman içerisinde değerlendirme ve onay adımları uygulamada yer alan kutucukları işaretleyerek hızlıca geçilebilen, formalite icabı yapılan görevlere dönüşüyor.
Burada tekrar hatırlatmak isterim: amacımız değişiklik yapmak değil, yapılmak istenen değişikliği önce anlamak, sonra değişikliği yapabilir hale gelmek! Değişikliği daha sonra yapacağız – hatta belki de yapmayacağız!
Bazı eğitimlerde katılımcı arkadaşlar değişikliklerin onaylanamayabileceği gerçeği ile ilk defa karşılaşıyorlar. Onay mekanizması, adı üzerinde, değişiklik yapılmalı mı yapılmamalı mı karar vermek için var. Gelen her değişiklik zaten onaylanıyorsa böyle bir mekanizma gerçekten etkin bir biçimde yürütülüyor diyebilir miyiz?
Takvim oluşturmak
Onaylanan değişikliğe ilişkin takvimin belirlenmesi ile “değişikliklere hazır hale gelmek” yolculuğunda son adımı atıyoruz.
Burada değişiklik ile ilgili ileri adımlarda gerekli kaynakları, farklı değişiklikleri, BT ekibi ve/veya iş birimleri tarafından önemli zamanları göz önünde bulundurarak bir planlama yapmak gerekiyor.
Farklı değişiklikler arası çatışmaları engellemek, değişikliklerin ilgili taraflara iletişimini sağlamak, doğru biçimde kaynak planlayabilmek için bu tür bir çalışma gerekli.
Asıl amacımız
Asıl amacı hiç bir zaman unutmamak gerekli. Öncelikli amacımız değişiklik yapmak değil! Öncelikli amacımız yapılacak değişikliği anlamak, değerlendirmek, sorgulamak! Amacımız değişikliği sorunsuz bir biçimde yapabilir hale gelmek.
Amaç değişiklik yapmak olduğunda gerek işleyiş, gerekse kişiler “bir an önce değişikliği yapmak” üzerine yoğunlaşıyor. Hatta performans hedeflerimizi bile bu yönde tanımlıyor; süreç ve kişi performansını bu hedefler üzerinden ölçüyoruz.
Amacı “değişikliği anlamak, sorgulamak; değişikliği yapabilir hale gelmek” olarak değiştirdiğimizde aslında odağımızı da değiştirmiş oluyoruz.
Haklı olarak bana “değişiklikleri anladık ama ne zaman ve nasıl devreye alacağız?” diye sorabilirsiniz. Ya da değişiklikler ile ilgili testleri veya geri dönüş planlarını öğrenmek isteyebilirsiniz. Bunlar güzel sorular, hepsinin cevabı var. ITIL’da tüm bu soruların cevapları ayrı ayrı pratiklerde/süreçlerde verilmiş. Ama önce bir değişikliği anlayalım!
Bu kadar mı?
Tabii ki hayır. Hatta daha yeni başlıyoruz. Buraya kadar anlattıklarım buzdağının sadece görünen yüzü. Mesela elimizde hazır, test edilmiş, canlıya aktaracağımız bir değişiklik olabilir. Veya müşteriden gelen talep doğrultusunda hazırlanması (tasarlanması, geliştirilmesi, test edilmesi) gerekli bir değişiklik olabilir. Değişiklik dış bir firma tarafından bize iletiliyor olabilir. Ya da iç kaynaklar tarafından geliştiriliyor olabilir. Tüm bu farklı durumlara cevap verebilecek şekilde esnek, dengeli; gerektiği durumda kontrollü, gerektiği zaman çevik bir yaklaşım oluşturmamız lazım. Bu belki biraz zor ama mümkün.
Sahi siz değişikliklerinizi nasıl yönetiyorsunuz? Son zamanlarda değişiklik nedeniyle ciddi bir sorun yaşadınız mı?
Sorularınızı, yorumlarınızı bekliyorum…
ITIL® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved