Değişiklik Yönetimi (Change Enablement)

Şartlar, koşullar değişiyor. İhtiyaçlar, gereksinimler değişiyor. Beklentiler, öncelikler değişiyor…

Herakleitos’un söylediği gibi “Değişmeyen tek şey değişimin kendisi”.

Peki biz BT hizmetleri için değişiklikleri nasıl yönetiyoruz?

Yine isterseniz tanım ile başlayalım: 

Değişiklik: Hizmetleri doğrudan ve dolaylı olarak etkileyebilecek her türlü ekleme, çıkarma ve modifikasyon. (The addition, modification, or removal of anything that could have a direct or indirect effect on services.)

Örneğin bir sunucunun IP adresini değiştireceksiniz. İki dakikanızı bile almaz. Peki bu işlem sunduğunuz hizmeti etkileyebilir mi? Evet, o zaman bu bir değişiklik!

Ya da uygulamanızın yeni versiyonunu yükleyeceksiniz. Bu işlem hizmetinizi etkileyebilir mi? Etkileyebilir! O zaman bu da bir değişiklik!

Ya da bir ağ cihazınızı güncelleyeceksiniz…

Kısacası sunmakta olduğunuz hizmetleri etkileyebilecek irili ufaklı tüm eklemeler, çıkarmalar, modifikasyonlar yukarıdaki tanıma göre bir değişiklik.

Çalışmakta olan hizmetler üzerinde ufak da olsa bir şeyleri değiştirmek riskli olabilir, hizmeti kesintiye uğratabilir. Çoğumuz duymuşuzdur, “çalışan sisteme dokunulmaz”. Biz tabii ki, gerektiğinde çalışan sisteme dokunalım ama nasıl dokunalım?

Amaç

Amacımız, BT değişikliklerinin başarılı bir şekilde gerçekleştirilmesini sağlamak. Bunun için önce yapılacak değişikliği anlamak, değişiklik ile ilgili riskleri ve olası etkileri değerlendirmek; söz konusu değişikliğin yapılıp yapılmayacağına ilişkin bir onay mekanizması yürütmek ve değişikliğin yapılması kararı verildiyse değişikliği planlamak gerekiyor.

Kısacası, ek değer sağlayacak, faydalı değişiklikleri hayata geçirirken müşterileri ve kullanıcıları değişikliklerin olumsuz etkilerinden korumaya çalışmak istiyoruz.

Burada özellikle tekrar vurgulamak isterim. Sadece riski büyük ve etki alanı geniş BT değişiklikleri değil, tüm BT değişiklikleri değişiklik yönetimi kapsamı içerisinde.

Akış

“Basit ve pratik tut” prensibini hatırlarsınız. Değişiklik yönetiminde de son derece basit ve pratik bir temel akışımız var:

Akış içerisinde kısaca ilerleyelim isterseniz:

• Değişiklikleri yönetmek adına hiçbir şey yapmıyorsak da, önce değişiklikleri kayıt altına alıyoruz. Değişikliği kayıt altına alarak, kimin, ne zaman, neyi, neden ve nasıl değiştirdiğine dair bir bilgi oluşturuyoruz. Örneğin dün çalışmakta olan sistem bugün arızalandığında, belki de dönüp bu değişiklik kayıtlarına bakarak, “En son bu değişiklik yapılmış. Belki kesinti bu yüzdendir.” diyebiliyoruz.
• Değişiklik kaydı aracılığı ile değişikliği ilgili ekiplere/kişilere duyuruyoruz. İlgili ekiplerin/kişilerin, kendi açılarından, söz konusu değişikliğin artılarını, eksilerini değerlendirmelerini bekliyoruz. Bu değerlendirme başlarda çok istediğimiz şekilde olmayabilir. Ama sadece, bir değişiklik yapılacağını ilgili kişilerin bilmesini sağlamak bile çok çok önemli.
• Değişikliğin kapsamına, risk ve etki alanına göre (az sonra değişiklik otoritesi olarak adlandıracağız) onaylanmasını sağlıyoruz. Belki bazı değişiklikleri bekletiyoruz, bazılarını bu aşamada önceliklendiriyoruz. Bu arada ufak bir not, tüm değişiklikleri onay için bir kurula sokMUyoruz. Detaylar az sonra…
• Onaylanan değişikliği planlıyoruz. Değişikliği, ne tür kaynaklar kullanarak, ne zaman gerçekleştireceğimizi belirliyoruz. Bir değişiklik takvimi oluşturuyoruz. Bazı değişiklikleri planlamadan bir an önce gerçekleştirmek gerekebilir – bunları birazdan acil değişiklikler olarak adlandıracağız.
• Planlandığı şekilde değişikliği gerçekleştiriyoruz. Burada belki gündeme farklı ITIL pratikleri gelebiliyor ama şimdilik onları bir kenarda tutuyoruz.
• Gerçekleştirilen değişikliği gözden geçiriyoruz. Her şey yolunda mı, beklenen sonuç elde edildi mi? Hatta bazı değişikliklerde, yan etkiler belirli bir süre sonra ortaya çıkabilir. O yüzden gözden geçirme süresini uzun tutmak iyi olabilir.
• Gözden geçirme sonrasında değişiklik kaydını (gözden geçirme sonucuna bağlı olarak) kapatıyoruz.

Genel olarak tanımladığımız bu akışı, tüm değişiklikler için bire bir işletmek doğru olmayabilir. Farklı durumlar için bu akışı özelleştirmek mümkün mü? Bu soruya cevap için önce değişiklik tiplerini tanıyalım.

Değişiklik tipleri

Değişiklik tanımı oldukça geniş. Bu geniş tanıma uygun bir çok farklı türde değişiklik ile karşılaşabiliriz. Bazı değişiklikler bir çok hizmeti etkileyebilirken, bazı değişikliklerin etkisi sınırlı olabilir. Ya da kimi değişiklikleri sık sık, rutin olarak gerçekleştirirken kimi değişiklikler ilk defa karşımıza çıkabilir.

Tüm bu farklı nitelikte değişiklikler için yukarıda kısaca özetlediğimiz akışı tüm adımları ile yürütmek bizi geciktirebilir. Açıkçası bir çok durumda çok anlamlı da olmayabilir. Peki ne yapalım?

Bu tür durumları daha doğru bir şekilde yönetebilmek için değişiklikleri önce üçe ayırıyoruz:

• Standart değişikliker,
• Normal değişiklikler,
• Acil değişikliler.

Standart değişiklikler

Düşük riskli, genellikle kendi konfor alanımız içerisinde ne yaptığımızı bildiğimiz, önceden onaylanmış değişiklikler standart değişiklik olarak adlandırılıyor.

Bu tür değişiklikler için, öncesinde, değişikliği nasıl gerçekleştireceğimize ilişkin reçeteler oluşturuyoruz. Değişikliği herhangi bir ek değerlendirme veya onay adımına sokmadan, ilgili reçeteyi uygulayarak hayata geçiriyoruz.

Yani kabaca değişikliği kayıt altına alıyor, planlıyor ve gerçekleştirip değişiklik kaydını kapatıyoruz.

Rutin (ama düşük riskli) yazılım güncellemeleri, sanal sunucular üzerinde sanal donanım ekleme/çıkarma, vb. çalışmalar standart değişiklik örnekleri olarak görülebilir.

Standart değişiklikler, birer reçeteye sahip olmaları nedeniyle, ileride otomasyon için de düşünülebileceğimiz türde değişiklikler.

Normal değişiklikler

Bazı değişiklikler için bir reçetemiz yok. Belki ilk defa yapacağımız bir değişiklik, ne ile karşı karşıya olduğumuzu bilmiyoruz. Belki de daha önce yaptığımız bir değişiklik ama riski, etkisi yüksek. Bu tür değişiklikleri normal değişiklik olarak görüyoruz.

Bu gibi durumlarda değişikliği öncesinde çalışmak, anlamak gerekiyor. Değişiklikten neler ve kimler etkilenebilir, ne tür riskler ile karşı karşıyayız, bu riskleri kontrol altına alabilir miyiz?

Normal değişiklikler, ilgili uzmanlar tarafından incelenip, analiz edilen ve daha sonra uygun bir onay mekanizmasına sunulan değişiklikler.

Yanlış anlaşılmasın, tüm normal değişikliklerin de aynı biçimde ele alınmasını beklemiyoruz. Değişiklik yönetiminde hantallaşmamak için esneyebilmek önemli.

Örneğin değişikliğin değerlendirilmesi adımını düşünelim. Bazı değişiklikler, kendi içerisinde, farklı bir sistemi etkilemeksizin gerçekleştirilebilecek değişiklikler. Bu tür değişiklikler için herkesi ayağa kaldırmak gerekmeyebilir. Sadece ilgili ekibin değişikliği değerlendirmesi yeterli olabilir.

Fakat bazı değişiklikler, birçok farklı sisteme (uygulama, donanım bileşeni, vb.) etki edebilir. Bu gibi durumlarda ilgili ekip temsilcilerinin, kendi açılarından değişikliği değerlendirmelerinde fayda var. Hatta belki bazı değişikliklerde hizmet/ürün aldığımız tedarikçilerin de devreye girmesi gerekebilir.

Ya da onay mekanizmasını ele alalım. ITIL’da, değişikliklerin onaylanmasından sorumlu kişi veya grup değişiklik otoritesi (change authority) bir rol olarak tanımlanıyor.

Değişiklik otoritesi sabit bir rol değil. Riski yüksek değişiklikler için belki bir kurul (birçok kurumda gözlediğimiz Değişiklik Danışma Kurulu – CAB / Change Advisory Board) değişiklik otoritesi rolünü üstlenirken, kapsamı sınırlı sadece belirli bir ekibi etkileyecek değişikliklerde, kurul beklenmeden, söz konusu ekibin yöneticisini bu rolü üstlenmesi düşünülebilir.

ITIL, değişiklilerin yönetimi için, bu yukarıda yazdıklarımıza benzer farklılıkların yansıtılabileceği değişiklik modelleri oluşturulmasını öneriyor. Ama bu konuya şimdilik girmeyelim.

Acil değişiklikler

Bazı değişikliklerde de, vakit kaybına tahammülümüz yok. Belki bir bilgi güvenliği açığını kapatmak, belki kritik bir hizmet üzerinde yaşanan arızayı/kesintiyi gidermek için değişikliği olabildiğince hızlı bir şekilde gerçekleştirmek gerekiyor.

Acil değişiklik olarak gördüğümüz bu tür değişikliklerde hızlı hareket etmek fakat bir yandan da kontrolü elden bırakmamak önemli. O yüzden gecikmemek için belirli adımları sonraya bırakıyoruz. Değerlendirme, onay gibi adımları hızlandırıyoruz. Mesela bu tür durumlarda ilgili ekipleri bir araya getirip, değerlendirmenin birlikte yapılmasını sağlamak daha hızlı hareket edebilmemize yardımcı oluyor.

Şunu da özellikle belirtelim, acil değişiklik, kesinlikle ve kesinlikle “kuralsız, kontrolsüz değişiklik yapacağız” anlamına gelmiyor!

Bana çok sık, acil değişikliler için “önce değişikliği yapsak, sonra kayıt oluştursak nasıl olur?” sorusu soruluyor.

Tabii ki, hiç kayıt oluşturmamaktansa önce değişikliği yapmak, sonra kayıt oluşturmak daha iyi, buna hiç şüphe yok. Ama kayıt oluşturmayı bir anlamda değişikliği duyurma aracı olarak da görmek lazım. Bu yüzden mümkünse (içerisinde bulunduğumuz durum buna elveriyorsa) acil değişiklikler için de önce kayıt oluşturulmasının daha doğru olacağını düşünüyorum.

Bu arada acil değişikliklerin, normal işleyişe alternatif, kötü niyetli bir biçimde kısa yol olarak kullanımı çok karşılaşılan bir durum. Bunu engellemek amacıyla, onay mekanizmasını biraz daha üst bir kademeden yürütmek fayda olabilir..

Peki ben ne yapmalıyım?

Değişiklik yönetimi biraz çekinilen bir süreç/pratik. Bazen çok gözümüzde büyütüyoruz, en iyisini yapamama kaygısıyla hiç birşey yapmıyoruz. Oysa ufak alışkanlıklar edinerek değişiklik yönetimini hayata geçirmek mümkün.

• Büyük küçük tüm değişiklikleri kayıt altına almaya başlayın. Evet ideal olarak elimizde bir BT hizmet yönetimi yazılımı olsa ve o yazılım üzerinde kayıt etmeye başlasak ne güzel olurdu! Ama elimizde böyle bir yazılım yoksa ya da bu yazılım üzerinde henüz değişiklik yönetimi modülü hazır değilse de kaydetmeye başlayın. Hiç olmadı Excel’e kaydedin. Kayıt oluşturmakla kalmayın duyurun. Özellikle BT ekibi içerisinde herkes kimin, ne zaman, neden, hangi değişikliği yapacağını bilsin!
• Amacımız üzüm yemek, bağcıyı dövmek değil. İşleri zorlaştırmayın. Akışı oluştururken basit ve pratik tutun. Bürokrasiden uzak durun. Bir dakikalık bir değişiklik için beş dakika boyunca kayıt oluşturuyorsam bu işte bir hata var.
• Farklı etki düzeylerine ve riskler içeren değişiklik türleri (standart, normal, acil durum) için farklı akışlar oluşturun. Tüm değişiklikler için sabit, tek tip bir yaklaşımdan kaçının.
• Değişiklikler çoğu zaman bir çok yere dokunur. Değişikliklerin doğru kişiler tarafından, doğru biçimde değerlendirilmesini sağlayın. Değerlendirme adımını kutucuk işaretleme çalışmasına çevirmeyin. Tüm değişiklikleri herkesin değerlendirmesini gerektirmeyin. Ya da sadece bir kişinin tüm değişiklikleri değerlendirmesini beklemeyin. Sadece ilgili kişileri değişikliklere dahil edin.
• Esnek bir onay mekanizması oluşturun. Bir tane kurul oluşturmak, tüm değişikliklerin bu tek kurul tarafından onaylanmasını sağlamak sizi hantallaştırabilir. Değişikliklerin etkilerine ve risklerine göre doğru bir otorite tarafından onaylanmasını sağlayın.
• Mümkün olduğunca değişiklikleri standardize edin. Rahat olduğunuz, düşük riskli rutin değişiklikler için reçeteler oluşturun. Bu tür değişiklikler için zaman kaybetmeyin.
• Otomasyonu düşünün. Bir çok standart değişiklik otomatize edilebilir,. Otomatize edilen değişiklikler size zaman ve kaynak kazandırır.

Uzun lafın kısası…

Değişiklikleri siz yönetmezseniz, değişiklikler sizi yönetir! Hiçbir şey yapmadan durup beklemektense, bir yerlerden başlamakta fayda var.

Değişiklik yönetimi, üzerinde uzun uzun konuşulacak bir konu. Ama bu ufak bir başlangıç olsun, ileride birlikte daha detaylandıralım.

😊

Bu arada değişiklik yönetimi ile ilgili aklınıza takılan herhangi bir soru ya da istek olursa çekinmeden bana ulaşabilirsiniz…

Fırat

ITIL® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.