ITIL® ile değişiklik yönetimi için kapsamlı bir rehber

İş ortamı ve müşteri beklentileri sürekli olarak değişim göstermektedir ve dijital dönüşüm, her sektörden işletmenin başarısı açısından önemli bir katkı faktörü haline gelmiştir. Dijital dönüşüm, tamamen iş ile ilgili zorluklarla mücadele edilmesi ve fırsatların kaçırılmaması için mevcut teknolojilerden faydalanılmasıyla ilgilidir. Parçalarına ayırdığınızda, dijital dönüşüm, temel olarak sorunlu alanların ortadan kaldırılması ve BT altyapısının iş ile ilgili zorluklarla yüzleşmek üzere sağlanması için BT yönetiminin daha iyi bir şekilde yapılmasıdır. Ve bu, kuruluşunuzun yeni teknolojileri mevcut işletme ve BT süreçlerine uygulamasına yardımcı olacak BT değişikliklerinin uygulanmasını içerir.

Bu değişiklikler, daha iyi işletimsel verimlilik için iş birliği uygulamalarının buluta taşınması ya da daha iyi bir tüketici deneyimi için "önce mobil" yaklaşımının benimsenmesi kadar basit olabilir. Dışarıdan bakıldığında basit görünseler de bu değişiklikler de kendi içlerinde lojistik zorluklar barındırır. Bir değişikliğin doğru şekilde uygulanmaması, kuruluşunuzun bir adım ilerlerken iki adım gerilemesine neden olabilir.

Aralık 2018'de tanınan bir bankanın mobil uygulama yükseltmesinin başarısız olması, değişikliğin nasıl uygulanmaması gerektiğine dair harika bir örnektir. Bankanın yeni ve iyileştirilmiş bir mobil bankacılık uygulaması sunmaya yönelik planı harika bir fikirdi ve buna gerçekten ihtiyaç vardı. Ancak yeni uygulama sunulduğu andan itibaren sorunluydu. Banka, yeni uygulamayı eskisini kullanımdan kaldırdıktan sonra sundu. Yeni uygulama çalışmaz hale geldiğinde, binlerce müşteri uygulamadan hesaplarına erişemez duruma geldi. İşleri daha da kötüleştiren, yeni uygulama için yapılacak düzeltmeyle ilgili olarak asgari düzeyde iletişim kurulmasıydı; bu da müşterilerin sinirlenmesine yol açtı. Mobil uygulama, dört gün boyunca, banka eski uygulamayı yeniden kullanıma sunmaya karar verene kadar kullanım dışı kaldı.

Bankanın bu önerilen değişikliğin çeşitli aşamalarında başarısız olduğunu görebiliyoruz: yeni uygulamanın dağıtıma hazır olmadan sunulması, şeffaf bir şekilde hareket ederek güncelleme ile ilgili olarak uygulamanın kullanılamayacağı sürenin son kullanıcılara iletilmemesi ve başarısızlığa karşı alternatif bir plan bulunamaması. Bu kesinlikle hiçbirimizin değişiklikleri uygulamada tercih edeceği bir durum değildir.

Değişiklik yönetimi tam da bu noktada devreye girer; kuruluşunuzdaki tüm farklı değişiklikleri yönetmenize yardımcı olur, değişikliklerin kuruluşunuzun geri kalanını etkilemeden, verimli bir biçimde sunulması için size bir süreç sağlar. Değişiklik yönetimi, bankanın karşı karşıya kaldığı sıkıntılar gibi durumların oluşma olasılığını azaltır.

Bu rehberde, değişiklik yönetimi ile ilgili olarak ne, nasıl ve neden sorularını cevaplayacağız. Kuruluşunuzun etkili değişiklikler ile sektördeki trendlere ayak uydurmasına nasıl yardımcı olabileceğinizi öğreneceksiniz.

Hemen başlayalım!

Değişiklik yönetimi nedir?

ITIL, değişiklik yönetimini, bir değişikliği başlangıçtan kapanışa kadar yaşam döngüsü süresince riski en aza indirme hedefiyle takip etme ve yönetme süreci olarak tanımlamaktadır.

Sistematik bir değişiklik yönetimi sürecinin ayarlanması, kuruluşunuzun değişiklikleri yüksek başarı oranıyla olaysız bir biçimde uygulamaya koymasına yardımcı olur.

ITIL kapsamında, değişiklik "hizmetler üzerinde doğrudan ya da dolaylı etki yaratabilecek herhangi bir şeyin eklenmesi, değiştirilmesi veya kaldırılması" olarak tanımlanmaktadır.

En sade tanımıyla, bir kuruluşun BT altyapısında yapılan ve kuruluşun operasyonlarını etkileyebilecek her türlü değişiklik BT değişikliğidir. Bu, yazıcılar, projektörler, sunucular ve daha fazlasının değiştirilmesini içerir.

Olay, sorun ve değişiklik arasındaki fark nedir?

Kuruluşlar neden değişiklik yönetimine ihtiyaç duyar?

Artık değişiklik yönetiminin ne olduğunu bildiğimize göre, değişiklik yönetiminin amaçlarıyla başlayarak kuruluşların neden böyle bir sürece ihtiyaç duyduğuna göz atalım.

Kuruluşlara değişikliklerinin kontrolünü ele alma ve bu değişiklikleri yönetme gücü vermek:

Değişiklik yönetimi, değişiklik sürecinizi daha iyi bir şekilde kontrol etmenizi sağlayacak ve değişiklikleri asgari düzeyde riskle uygulamanıza yardımcı olacaktır. Değişiklik yönetimi, standart süreçlerin izlenmesiyle her değişimin planlama, risk değerlendirmesi ve uygulama takibi gibi tüm yönleriyle etkili bir biçimde yönetilmesini sağlar. Baştan sona kadar değişikliklerin takip edilmesi için bir hizmet masası aracının kullanılması harikalar yaratabilir ve bir kuruluşun BT altyapısını iyi planlanmış ve yürütülmüş değişiklikler ile daha iyi bir şekilde yönetmesini sağlayabilir.

Kuruluşların değişiklikleri daha iyi bir şekilde uygulamasına yardımcı olmak:

Değişiklik yönetimi, değişiklik sürecinin tamamının takip edilmesiyle, kuruluşların tüm değişiklik taleplerine dair tüm güncel bilgileri almasını mümkün kılar. Aynı zamanda, izinsiz değişiklik sayısının tespit edilmesini ve kontrol altına alınmasını kolaylaştırır. Kuruluşlar, kullanıcıların değişiklik isteğini (RFC) yalnızca bir hizmet masası aracı üzerinden göndermesine izin vererek en baştan değişiklikle ilgili tüm gerekli bilgileri toplayabilir ve ardından değişikliğin uygulanmasının gerekli olup olmadığına karar verebilir. Sağlam bir onay mekanizması, değişikliklerin uygulanmadan önce tüm gerekli izinleri almasını sağlar.

Sürekli iyileştirmeyi mümkün kılmak:

Değişiklik yönetimi yalnızca kötü günler için değildir; kuruluşların altyapılarını ve süreçlerini sürekli olarak iyileştirmelerine ve gerekli değişiklikleri mevcut hizmet operasyonlarını etkilemeden sorunsuzca sunabilmelerini sağlayarak sektördeki eğilimlere ayak uydurmalarına yardımcı olmayı amaçlar.

Kuruluş için:

• Değişikliklerin etkili yönetimi sayesinde değişikliklerde daha az çakışma.
• Yükseltmelerin operasyonları etkilemeden sunulabilmesi.
• Daha az başarısız değişiklik.
• Değişikliklerin doğru bir biçimde sınıflandırılması.

Son kullanıcılar için:

• Planlanmış değişiklikler nedeniyle hizmetlerin kullanım dışı kalacağı sürenin ve duruş süresinin daha iyi bir şekilde iletilmesi.
• Kötü planlanmış değişikliklerin neden olduğu sıkıntıların daha az olması nedeniyle daha sorunsuz hizmet operasyonları.

Kuruluşlar değişiklik yönetimini nasıl yürütür?

Şimdi kuruluşunuzda değişiklik yönetimini nasıl uyguladığına göz atalım. Değişiklikleri planlamanızı sağlayacak etkili bir değişiklik süreci için ilk adım gerekli onayın alınması ve değişikliklerin uygulanmasıdır. Burada, değişiklikleri etkili bir şekilde ele almak için izleyebileceğiniz bir değişikli yönetimi süreci verilmiştir.

Değişiklik yönetimi süreci

Adım 1: Gönderim

İlk aşama, değişikliğin başlatılmasıdır. Bu, değişiklik türü ve önceliği gibi temel değişiklik bileti bilgilerinin toplanmasını içerir.

• Oluşturma: Değişikli biletleri, bir hizmet masası aracı ile başlatılır. Gerekli bilgiler, zorunlu alanlar içeren bir değişiklik formu kullanılarak, en başta toplanır.
• Değişiklik rollerinin tanımlanması : Kuruluşlar, değişiklik rollerini kullanarak değişiklik sorumluluklarını çeşitli paydaşlara devredebilir ve her rolün bir değişimin her aşaması için erişim seviyesini kontrol edebilir.

Adım 2: Planlama

Bir sonraki aşama, tüm değişikliğin planlamasının yapıldığı aşamadır. Başarılı bir değişiklik uygulamasının sırrı, iyi planlanmış bir değişikliktir. Ayrıca, değişikliğin uygulanması için gerekli onayların alınması da büyük önem taşımaktadır. Değişiklik planının paydaşlara net bir biçimde iletilmesi ve paydaşların değişikliğin uygulanmaya değer olduğu konusunda ikna edilmesi için etki, sunum planları, geri çekme planları ve ilişkili duruş süresi gibi ayrıntılar belgelendirilir.

Adım 3: Onay

Daha sonra, değişiklik planının değişiklik denetleme kurulu (CAB), acil değişiklik denetleme kurulu (ECAB) ve değişiklikte veya değişikliğin etkileyeceği kuruluş altyapısında payı olan diğer kurumlar tarafından onaylanması gerekmektedir. Özel CAB'lerin oluşturulması, kuruluşların onayları kolaylıkla yönetmek üzere ilgili personeli gruplandırmasına yardımcı olur. Onay sürecinin otomatik hale getirilmesi değişikliğin tamamını hızlandırır ve herhangi bir onay isteğinin atlanmamasını sağlar.

Not: CAB, çeşitli iş rolleri ve ekiplerin birleşiminden oluşur. Değişikliğin şiddeti ve ölçeğine bağlı olarak C seviyesi yöneticileri, ekip yöneticilerini, teknik ekipleri, finans personelini ve daha fazlasını içerebilir.

Adım 4: Uygulama

Gerekli onaylar alındıktan sonra, değişiklik uygulanabilir. Kuruluşlar, görevler oluşturarak ya da bir proje kullanarak değişikliklerin uygulanmasını izleyebilir ve yönetebilir.

• Görevler aracılığıyla işlerin devredilmesi: Değişikliğin uygulanma sürecine dahil olan herkesin yaptığı işlerin kolaylıkla yönetilebilmesi için görevler oluşturulur ve farklı ekiplerden farklı teknisyenlere atanır. Görev bağımlılıklarını ayarlamak ve görevlerin belirli bir sırada yapılmasını ve herhangi bir görevin göz ardı edilmemesini sağlamak üzere ana ve alt görevler kullanılabilir.
• Proje yönetiminden faydalanılması: Kuruluşlar, kuruluşun altyapısının tamamının buluta taşınması gibi büyük ölçekli değişikliklerle çalışırken projelerden faydalanabilir. Projeler, daha geniş kapsamlı uygulamaları destekler ve daha yüksek sayıda görev, kişi ve aşamayı daha iyi bir şekilde ele alabilir. Değişiklik yönetimi ve proje yönetimi arasındaki güçlü entegrasyon, kuruluşlara oldukça fazla avantaj sağlayabilir.

Adım 5: Gözden Geçirme

Daha sonra, uygulamada herhangi bir sapma olmadığından ve değişiklik kapatılmadan önce tüm sorunların düzeltildiğinden emin olunması için bir gözden geçirme süreci yürütülür.

Adım 6: Kapanış

Bu, değişiklik yönetimi sürecindeki son adımdır. Tamamlanan değişikliğin niteliği başarılı, başarısız veya tamamlanmamış olarak kaydedilir. Doğru kapanış kodunun kaydedilmesi, bir kuruluşun ölçümlerinin çok daha doğru ve faydalı olmasını sağlar.

Tüm değişiklikler aynı değildir; bazıları farklı gerekliliklere sahiptir. Bazı değişikliklerin mümkün olduğunca kısa süre içinde uygulanması gerekirken, bazıları kuruluşun üst düzeylerinden onay gerektirir ve bazıları da haftalık olarak uygulanan normal değişikliklerdir.

ITIL'e göre, değişiklikler, üç türe ayrılabilir: standart, normal ve acil değişiklikler.

Standart değişiklikler:

Bunlar, etkisi düşük, iyi bilinen ve belgelendirilen önceden onaylanmış değişikliklerdir. Standart değişiklikler, ilk uygulandıklarında bir risk değerlendirmesi ve izin gerektirir ancak değişiklik değiştirilmediği sürece daha sonraki uygulamalar bu tedbirler olmadan gerçekleştirilebilir.
Örnek: Bir yazıcının mürekkep kartuşunun değiştirilmesi

Normal değişiklikler:

Normal bir değişikliğin değişiklik sürecinin tamamını izlemesi gerekmektedir; planlanmalı, risk değerlendirmesinden geçmeli ve onaylanmalıdır. Normal değişiklikler hem küçük (düşük ilâ orta etkili ve öncelikli) hem de büyük değişiklikleri (yüksek etkili ve öncelikli) içerir. Standart veya acil olmayan tüm değişiklikler, normal değişiklik olarak ele alınmalı ve değişiklik sürecine bağlı kalınmalıdır.
Örnek: Tesis içindeki hizmetlerin buluta taşınması

Acil değişiklikler:

Acil değişiklikler yüksek etkili ve önceliklidir; hizmetlerin mümkün olan en kısa süre içinde çalışır ve etkin hale getirilebilmesi için hızlandırılmış değerlendirme, onay ve uygulama süreçlerinden geçmeleri gerekir. İş operasyonlarını etkileyen ve dolayısıyla da duruş süresine neden olan bileşenlerde yapılan değişiklikler acil değişiklik olarak ele alınır.
Örnekler: Birincil sunucu arızası, veri merkezi kesintisi, güvenlik zaafı için acil yama

Değişiklik sahibi:

Değişiklik sahibi, değişiklik yönetimi sürecinin iyileştirmeyi de içeren tüm aşamaları için hesap sorulabilecek olan kişidir. Değişiklik sahibi kuruluşundaki değişiklik yönetiminden sorumlu olduğundan genellikle üst seviyelerden bir yetkilidir.

Değişiklik yöneticisi:

Değişiklik yöneticisi, değişikliğin yönetilmesini ve bununla ilgili aktiviteleri ele alır. Ayrıca, CAB'yi ve ilgili çeşitli ekipler ile paydaşları yönetir ve bunlarla koordinasyonu sağlarlar.

Değişikliği başlatan:

Değişikliği başlatan, değişikliği başlatarak değişiklik planlarını, uygulama planlarını ve diğer gerekli ayrıntıları ekleyen kişidir. Bu kişiler, aynı zamanda değişiklik uygulama planını da organize eder. Değişikliği başlatan kişi bir teknisyen veya son kullanıcı olabilir.

CAB:

CAB, farklı ekipler ve iş işlevlerinden çeşitli üyelerin bir araya gelmesiyle oluşturulur. Bu kişiler, bir araya gelerek önerilen değişikliği analiz ederek değişiklik ve uygulanması ile ilgili onay ve önerilerini iletir.

İlave roller:

Bazı kuruluşlar, işleri devretmek ve sorumlulukları bölümlere ayırmak üzere bu dört ana role ek olarak özel rollerden faydalanır. Özel rolleri oluşturabilme becerisi, değişiklik yönetiminizin kuruluşunuzun ihtiyaçlarına göre özelleştirilebilmesine yardımcı olur. Sık kullanılan birkaç ilave rol aşağıdaki gibidir:

• Değişikliği onaylayan
• Değişikliği uygulayan
• Değişikliği gözden geçiren
• Değişikliği planlayan

Burada, değişiklik yönetimini olumsuz etkileyebilecek ve genel olarak karşılaşılan dört zorluk listelenmektedir.

1. Başarısız değişiklikler:

   Değişiklikler, oldukça fazla miktarda kaynak ve zaman gerektirir ve değişikliklerin planlanmasında oldukça fazla araştırma yapılır. Başarısız değişiklik sayısının fazla olması, süreçlerin kontrol edilmemesi halinde çok hızlı bir şekilde oldukça yüksek maliyetler doğurabilir. Altyapısal değişiklikler durumunda, yüksek bir başarısızlık oranı uygulama sırasında ya da geri çekme planları uygulanırken daha büyük sorunlara yol açabilir. Çoğu başarısız değişiklik, aynı zamanda kötü değişiklik yönetimi sürecine dair bir göstergedir.

   Örnek: Zylker, birincil ağ altyapısını yükseltmeyi planlamaktaydı; dolayısıyla şirket bir üçüncü taraf ağ sağlayıcısı ile alternatif bir ağ oluşturdu; değişikliğin hafta sonu uygulanması beklenmekteydi. Uygulama sırasında, Zylker hizmetlerin çalışmadığına dair biletler aldı; bu, şirketin alternatif bir ağ oluşturmuş olduğu göz önünde bulundurulduğunda, şaşırtıcı bir gelişmeydi. Alternatif ağ sağlayıcının da aynı hafta sonu planlı bakım faaliyetleri gerçekleştirdiği anlaşıldı; bu da Zylker'in hem birincil hem de alternatif ağlarının çalışmaz durumda olduğu ve Zylker'in hizmetlerinin kullanılamaz duruma geldiği anlamına geliyordu. Değişiklik doğru şekilde planlanmadığından, başarısızlıkla sonuçlandı.

2. İzinsiz değişiklikler:

   İzinsiz değişiklikler, etkisiz bir onay mekanizmasının ve onay aşamasına doğru paydaşların dahil edilmemesinin sonucudur. Bu değişiklikler, gerekli izinleri atlar ve zamanında işaretlenmemeleri halinde uygulanabilir. İzinsiz değişiklikler, kuruluşunuzun ihtiyaç duymadığı ya da uygulamaya hazır olmadığı değişikliklere yol açabilir. Nihayetinde, izinsiz değişiklikler kötüdür ve gereksiz harcamalara neden olur.

3. Çok fazla acil değişiklik:

   Daha önce de açıklandığı gibi, acil değişiklikler, mümkün olan en kısa süre içinde uygulanabilmeleri için hızlandırılmış onay süreçleri gerektirir. Çok fazla değişikliğin acil değişiklik olarak ele alınması, uygulanması gereken ciddi bir acil değişikliğin bulunması durumunda gecikmelere yol açabilir. Bir değişikliğin acil değişiklik olarak sınıflandırılması sırasında dikkatli davranılması her zaman iyi bir uygulama olacaktır.

   Not: Yalancı çoban hikayesi, çok fazla değişikliğin acil değişiklik olarak ele alınmasının neden sorun yaratacağına dair iyi bir benzetmedir. Gerçek bir acil durum söz konusu olduğunda, kuruluşunuz değişikliği gerektirdiği ciddiyetle ele alamayabilir ve acil durumla baş etmek için gerekli kaynaklara ulaşamayabilirsiniz.

4. Değişiklik çakışmaları:

   Kötü planlama, değişikliklerde çakışmalara neden olabilir. Bir değişiklik çakışması, iki veya daha fazla değişikliğin kazara aynı anda uygulanacak şekilde planlandığı ve her iki değişikliğin de uygulanmasını kesintiye uğrattığı durumları ifade eder. Değişikliklerinizin daha iyi planlanması için bir değişiklik takvimi kullanmanız, değişiklik çakışmalarını önlemenize yardımcı olabilir.

Burada, değişiklik yönetimine yaklaşım için en iyi yollar listelenmiştir.

1. Değişiklik türlerini tanımlayın:

   Tüm değişikliklerin aynı olmadığını aklınızdan çıkarmayın: Değişiklikler, değişiklik türleri bölümünde de açıklandığı gibi farklı öncelik seviyelerine ve farklı gerekliliklere sahiptir.

2. Farklı değişiklik türleri için süreçler tasarlayın:

   Farklı değişiklik türlerinin kendi benzersiz gereklilikleri bulunduğundan, bu ihtiyaçları karşılamak için benzersiz süreçler tasarlamanız gerekir. Tüm değişiklik türleri için aynı değişiklik sürecinin kullanılması, yalnızca gereksiz gecikmelere ve yetersiz değişiklik uygulamalarına yol açacaktır.

   Not: Ayrıca, değişiklik türlerinizden her biri için farklı değişiklik iş akışları oluşturabilirsiniz.

3. Temel rol ve sorumlulukları tanımlayın:

   Rollerin tanımlanması, değişiklik yöneticisinin aktivite ve sorumlulukları başkalarına devretmesine olanak tanır. Roller, değişikliklerin yönetilmesini kolaylaştırır ve her bir kişinin gerçekleştirebileceği aktiviteleri net bir şekilde tanımlar.

4. Değişiklik önerilerini kaydedin, yönetin ve öncelik sıralamasına dizin:

   Değişikliklerinizi kaydetmek ve bunları tek bir yerden yöneterek öncelik sıralamasına dizmek için düzenli bir yöntem kullanılması, en iyi uygulamalardan biridir. Kuruluşunuzun değişikliklerini daha iyi görme becerisi elde ettiğinizde, hangi değişikliklerin diğerlerinden önce gerçekleştirilmesi gerektiğini belirleyebilirsiniz.

5. Değişikliklerin riskleri ve etkisi hakkında net içgörüler edinin:

   Değişikliğin daha iyi bir şekilde anlaşılması ve gerekli kaynakların tahsis edilmesi için tüm değişikliklerin risk ve etki analizinden geçmesi gerekmektedir. Risk ve etkinin ayrıntıları, planlama aşamasında eklenmelidir; bu şekilde CAB, değişikliğe dair net bir fikir elde edebilir ve öneride bulunabilir.

6. Etkili bir onay mekanizmasını uygulamaya koyun:

   Onay sürecinin tanımlanması, bir değişikliğin uygulanması için gerekli izinleri almayı kolaylaştırır. Bu, bir değişiklik uygulanmadan önce tüm paydaşların değişikliklerin farkında olmasını ve öneride bulunmasını sağlar. Bu, izinsiz değişikliklerin kontrol altına alınmasına yardımcı olur.

7. Programları ve duruş sürelerini paydaşlara iletin:

   Paydaşların planlanan değişikliklerden haberdar edilmesi, değişikliklerin neden olduğu olay sayısını azaltır. Anlık bilgilerin iletilmesi de herhangi bir hizmetin değişikliklerden etkilenmemesini ve değişikliğin etkili bir biçimde yürütülebilmesini sağlar. Buna ek olarak, değişikliğin yaşam döngüsü konusunda bilgilendirilmek yönetimi de mutlu edecektir.

8. Değişiklik uygulamasının ilerleyişini ve etkililiğini ölçün:

   Değişikliğin yaşam döngüsü boyunca değişikliğin takip edilmesi, hiçbir şeyin yanlış gitmemesini ve değişikliğin değişiklik planına uygun biçimde uygulanmasını sağlar. Temel ölçümler, değişiklik projenizin ne kadar etkili olduğu hakkında size net bir görüş verir ve iyileştirebileceğiniz alanları tanımlayabilmenizi sağlar.

9. Yedek planları hazır bulundurun:

   Fazla hazırlıklı olmak diye bir şey yoktur; dolayısıyla en kötü durumlar için planlama yapılması ve değişikliğin planlanma aşaması sırasında bir geri çekme planının bulundurulması her zaman iyi bir fikir olacaktır. Bu derinlemesine planlama, sıradan bir başarısız değişiklik ile BT altyapınızda geri dönülemez hasarlara neden olacak başarısızlık değişiklik arasındaki farkı yaratır.

10. Sürekli hizmet iyileştirmeleri uygulayın:

    Her ne kadar sorunlarla mücadele değişiklik yönetiminin kritik bir işlevi olsa da kuruluşunuzda değişikliklerin kapsamı daha geniştir. Teknoloji ve süreçlerin iyileştirilmesi için değişikliklerin kullanılması ve dolayısıyla da kuruluşunuzun daha iyi hizmetler sunma becerisinin geliştirilmesi, değişiklik yönetiminin önemli bir işlevi haline gelmektedir.

Değişiklik yönetimi, bir değişikliğin tamamlanmasıyla sona ermez. Değişiklik yönetiminin değişiklikleri etkili bir biçimde sunma becerisi, diğer ITSM süreçlerinden toplanan bilgilerden faydalanabilir ve bunun tam tersi de geçerlidir. Olayların neden oldukları değişiklikler ya da bu olaylara neden olan değişiklikler ile ilişkilendirilebilmesi veya CMDB'nin BT altyapısal değişikliklerine dayalı olarak güncellenebilmesi, kuruluşunuzun daha iyi yönetilmesine yardımcı olmak üzere birlikte çalışan eksiksiz bir ITSM uygulamasının oluşturulmasında yalnızca bir başlangıçtır.

Değişiklik yönetiminin diğer ITSM süreçleriyle birlikte nasıl çalışabileceğini buradan görebilirsiniz:

1. Olay yönetimi:

   Bir değişikliğe neden olan olayların ve değişikliğin neden olduğu olayların takip edilmesi, değişikliklerin kuruluşunuzu nasıl etkilediğini daha iyi anlayabilmenizi sağlar. Örneğin; bir yönlendirici güncellendiğinde, internetin kesik olduğunu bildiren olay biletleri alabilirsiniz. Değişikliklerin neden oldukları olaylarla ilişkilendirilmesi, bir olayın nedenini hızlıca tanımlayabilmenize yardımcı olur ve ilgili olay değişiklik tamamlandıktan sonra düzeltileceğinden, bu olayın düzeltilmesi için ilave kaynak atamanıza gerek kalmamasını sağlar.

2. İsteklerin yerine getirilmesi:

   BT altyapınızı güncel tutmak için yüksek etkili hizmet taleplerinde değişikliklerin kullanılması önemlidir. Değişiklikler olmadan bir sunucu yükseltmesi için bir hizmet isteği veya Azure depolama alanının yükseltilmesine yönelik bir istek, hizmetin iletilmesiyle sonlanır. Ancak hizmet isteğinin uygulanmasında bir değişikliği kullanmanız halinde, değişikliğin nedeni ve uygulama planı gibi daha fazla bilgi toplayabilir, tüm paydaşlardan gerekli onayları alabilir ve CMDB'yi yeni bilgilerle güncelleyebilirsiniz.

   Not: İsteklerin yerine getirilmesi için değişikliklerin kullanılması, en iyi yüksek etkili hizmet isteklerinde ve CMDB'de değişiklik yapılmasını gerektiren hizmet isteklerinde çalışır. CMDB'nin güncellenmesini gerektirmesi halinde, bir değişiklik gereklidir!

3. Sorun yönetimi:

   Sorun yönetimi, bir sorunun temel nedeninin düzeltilmesi için bir değişiklik oluşturulmasını gerektirir. Doğrudan bir bilet içinden RFC oluşturulması, ilişkili değişiklikler ve sorunların takibini kolaylaştırır. Ayrıca CAB'nin değişikliğin neden gerekli olduğunu daha net bir şekilde anlayabilmesini sağlar ve değişikliğin başlatılmasına neden olan sorunun şiddetini belirtir.

4. Sunum ve dağıtım yönetimi:

   Sunum ve değişim yükseltmeler, değişiklik sürecinin beraberinde getirdiği yapılandırılmış yaklaşımdan faydalanır. Uygulama planlarını, sunum planlarını ve sunum ve dağıtımların değişikliklerin kullanılmasıyla fiili olarak uygulanmasını kolaylıkla izleyebilirsiniz. Değişikliklerin sunduğu şeffaflık ve görünürlük de tüm paydaşların bilgilendirilmesine yardımcı olur.

5. CMDB:

   CMDB'de yapılan her türlü değişiklik, her zaman bir değişim ile birlikte gerçekleştirilmelidir. Bir değişiklik, güncellemenin neden, ne zaman ve nasıl yapıldığı hakkında birçok faydalı bilgi sağlar. Bir değişiklikle beraber gerçekleştirilen etki analizi de CMDB'de yapılan güncellemelerin doğru şekilde analiz edilmesini ve güncellemenin kuruluşunuzun geri kalanında herhangi bir sıkıntıya neden olmamasını sağlar. Değişen önceliklere sahip CMDB güncellemelerinin kaydedilmesi için değişiklik türlerini kullanabilirsiniz.

Burada, değişiklik yönetimi sürecinizin etkililiğini ölçmek için kullanabileceğiniz bazı önemli ölçümler yer almaktadır.

Şimdi, değişiklik yönetimi sürecinizi nasıl iyileştirebileceğinizi görmek için bir değişikliğe ayrıntılı olarak bakalım.

Çok fazla sayıda uzaktan kullanıcısı olan Zylker şirketi, bulut hizmetlerine yönelmeye karar vermiştir.

Mevcut durumda bir şirketin verimlilik uygulamalarının ve kaynaklarının tamamı tesis içinde bulunmaktadır; dolayısıyla uzaktan kullanıcıların ağa erişmesi için bu kullanıcılara VPN erişimi tanınmaktadır. Verilere daha hızlı bir şekilde erişilmesini sağlamak için Zylker bulut uygulamalarını kullanmaya başlamaya karar vermiştir. Verimlilik programlı olarak Zoho One'ı, e-postalar içinse Office 365'i seçmiştir. Şirketin dosya sunucuları ve veri tabanları gibi kaynaklarının bir kısmı hala tesiste bulunduğundan, uzaktan kullanıcıların bunlara da erişebilmesi gerekmektedir.

Bu gerekliliğin karşılanması için BT ekibi bir hibrit Azure Active Directory (AD) ortamının kurulumunu gerçekleştirmiştir. Bulut tabanlı Azure AD'de tesislerindeki AD'yi aynen yansıtmak için bir federasyon sunucusu kullanmışlardır. Artık uzaktan kullanıcılar dahil olmak üzere son kullanıcılar, bulut kaynaklarına AD kimlik bilgileriyle erişebilmektedir.

Adım 1: RFC'nin İletilmesi

İlk adım, bir değişiklik biletinin iletilmesi, değişikliğin türü, etkisi ve önceliği gibi değişiklik hakkındaki gerekli bilgilerin toplanması ve değişiklik rollerinin ayarlanmasıdır. Değişikliği başlatan, web portalını kullanarak bir değişiklik biletini kolaylıkla iletebilir ve ilgili değişiklik şablonu ile değişiklik türünü seçebilir. Değişiklik şablonu, zorunlu alanları kullanarak tüm gerekli bilgileri toplar. Burada, değişikliği başlatan, değişiklik türünü normal olarak ayarlar, uygun değişiklik şablonunu seçer, değişiklik rollerini atar ve değişikliğin neden gerekli olduğu hakkında bir açıklama sunar.

Adım 2: Değişikliğin planlanması

Daha sonra, değişikliği başlatan, değişikliğin nedeni, etkisi, sunum ve geriş çekme planları ile ilgili ayrıntılı bilgi ve planlanan duruş süresi hakkında değişiklik bilgilerini ekler. Değişikliği başlatan, aynı zamanda, değişikliği ve etkisini daha iyi takip edebilmek için tüm ilişkili olay ve sorunları ekler. Aşağıda, değişikliği başlatanın geliştirdiği çeşitli planlar bulunmaktadır:

Sunum planı:

• Azure AD ve Office 365 hesapları edinmek
• Active Directory Federation Services (ADFS) için kurulumu gerçekleştirmek
• Tesisteki AD ve Azure AD arasında eşitlemeyi başlatmak
• Tekli oturum açmayı yapılandırmak
• Tesisteki Exchange'i Office 365 ile eşitlemek

Geri çekme planı:

Mevcut yapılandırma bütün halinde olduğundan, eski yapılandırmaya dönerek hizmetlere devam etmek.

Planlanan duruş süresi: 12 saat

Adım 3: Doğru onayların alınması

Değişiklik yöneticisi, değişiklik planını gözden geçirmeleri ve değişikliğin uygulanmasının gerekip gerekmediğine ya da değişikliğin değiştirilmesinin gerekli olup olmadığına dair tavsiyede bulunmaları için CAB'ler oluşturur. Bu büyük ölçekli bir değişiklik olduğundan, bir dizi işleve dağılmış çeşitli iş rollerinden onay alınması gerekmektedir. Burada, onay sürecine dahil olan CAB'ler ile üyelerin bir listesi yer almaktadır:

1. İdari CAB:
   • Bilişim Kurulu Başkanı (CIO)
   • Teknoloji Kurulu Başkanı (CTO)
   • Mali İşler Kurulu Başkanı (CFO)
   • İcra Kurulu Başkanı (CEO)
2. Teknik CAB:
   • Hizmet iletim yöneticisi
   • Operasyon yöneticisi
   • Bilgi güvenliği yöneticisi
   • Veri koruma sorumlusu
3. Ticari CAB:
   • İşletme yöneticisi
   • İnsan kaynakları yöneticisi
   • Ticari ilişkiler yöneticisi

Adım 4: Değişikliğin doğru şekilde uygulanması

Zylker, uygulamanın takip edilmesi için görevleri kullanır. Görevler, farklı teknisyenlere atanır ve bunların yapılması gereken sıra, görev bağımlılıkları kullanılarak tanımlanır. Değişiklik sahibi, değişikliğin uygulanmasındaki ilerlemeyi kolaylıkla izleyebilir ve tüm görevleri tek bir yerden yönetebilir.

Burada, Zylker'in değişikliğin uygulanmasını izlemeyi ve yönetmeyi kolaylaştırmak üzere uygulamayı nasıl görevlere böldüğü gösterilmektedir:

• Office 365 ve Azure AD'nin Hazırlanması
• Bir içe alma sunucusunun ayarlanması
• Verilerin taşınmasının başlatılması
• Azure AD vekil sunucularının yapılandırılması
• Veri bütünlüğünün kontrol edilmesi

Adım 5: Plana bağlı kalınmasın

Daha sonra, plandan sapma olup olmadığının kontrol edilmesi için değişikliğin uygulanması, değişiklik sahibi/yöneticisi tarafından gözden geçirilir. Değişikliğin başarılı olduğu teyit edilmeden önce tüm sapmalar bildirilir ve düzeltilir.

Adım 6: Değişiklik biletinin kapatılması

Son olarak, değişikliğin niteliğine bağlı olarak değişiklik kapatılır ve bir kapanış kodu atanır.

Adım 7: Ölçümlerin toplanması

Değişiklik yöneticisi etkili değişiklik sürecinin ne kadar etkili olduğunu belirlemek ve iyileştirilebilecek alanları tanımlamak üzere belirli KPI'ları ölçer.

Burada, bir hizmet masası aracı seçerken dikkat etmeniz gereken özelliklerin bir listesi yer almaktadır. Bu özelliklerin bulunması, kuruluşunuzda etkili bir değişiklik yönetimi süreci uygulamanıza yardımcı olacaktır.

Değişiklik yönetimi

Değişikliğin oluşturulması ve kaydedilmesi

• Olaylar ve sorunlardan değişiklikler oluşturun ve gerekli bilgileri aktarın.
• Özel değişiklik şablonları ile gerekli bilgileri toplayın.
• Farklı değişiklik türleri oluşturun ve her bir tür için benzersiz iş akışları yaratın.
• Değişiklik rollerini kullanarak değişiklik sahibi, onaylayanı, bağlı yöneticisi ve değişikliği gözden geçiren gibi doğru paydaşları sürece dahil edin.

Değişiklik planlaması ve değerlendirmesi

• Etki analizi ve sunum, geri çekme ve duruş süresi planlarının bulunduğu ayrıntılı değişiklik planları oluşturun.
• Atılacak temel adımların kontrol listesini oluşturun.

Değişiklik onayı

• Birden fazla CAB oluşturun.
• Birden fazla onay seviyesi yapılandırın. RFC'nin CAB'nin tüm üyelerinin mi yoksa herhangi bir üyesinin mi onayını gerektirdiğini işaretleyin.
• Değişikliğin onayı ile ilgili olarak son sözü değişiklik yöneticisine bırakın.
• Tüm CAB üyeleri önerdiğinde, değişikliği otomatik olarak onaylayarak değişiklik yöneticisi ve değişiklik onaylayanının onaylarını atlayın.
• Son kullanıcıları hizmet isteği onaylayanları olarak işaretleyin.

Değişiklik uygulamasının koordine edilmesi

• Değişiklikleri görevlere ayırın ve değişikliği uygulama ekibinin aktiviteleri tamamlamasının ne kadar süreceğini tahmin etmek için iş günlüklerinden faydalanın.
• Bir değişiklikten projeler oluşturarak ya da bir değişikliği mevcut projeler ile ilişkilendirerek uygulamayı sadeleştirin.
• Değişikliğin neden olduğu ya da değişikliğe neden tüm olay ve sorunları takip edin.
• Duruş süresini planlayın ve temel paydaşlara duyurun.
• Düzenli bildirimler ile paydaşları durumdan haberdar edin.

Değişikliğin gözden geçirilmesi ve kapatılması

• Uygulama sonrası gözden geçirme sürecini (PIR) belgelendirin.

Değişiklik iş akışları

• Değişen seviyelerde karmaşıklıkta ve farklı işlevleri bulunan farklı değişiklik türleri ve süreçler için ayrı iş akışları oluşturun.
• Aşamalar arası geçişler sırasında koşullar, anahtarlar, bildirimler, alan güncellemeleri ve onaylar gibi çeşitli eylemler yapılandırın.
• Sürükle-bırak alanında değişiklik iş akışları oluşturun.

Değişiklik:

Hizmetler üzerinde doğrudan ya da dolaylı etki yaratabilecek herhangi bir şeyin eklenmesi, değiştirilmesi veya kaldırılması.

Değişiklik denetleme kurulu (CAB):

Değişiklik hakkında önerilerde bulunan ve değişiklik planını onaylayan çeşitli paydaşlardan oluşan bir ekip.

Değişiklik çakışması:

İki veya daha fazla değişikliğin kazara aynı anda uygulanacak şekilde planlandığı ve her iki değişikliğin de uygulanmasını kesintiye uğrattığı durumlar.

Değişiklik yönetimi:

Değişikliklerin asgari düzeyde sıkıntı ve çakışma ile tamamlanma süreci.

Değişiklik rolleri:

Değişikliğin farklı yönleri ile ilgili sorumlulukların kuruluşun farklı üyelerine devredilmesi.

Kapanış kodu:

Başarısız veya başarılı gibi değişikliğin kapanış niteliğini kaydetmek için kullanılan ifade.

Yapılandırma yönetimi veri tabanı (CMDB):

Tüm yapılandırma öğeleri ve bunların ilişkilerinin yer aldığı bir depolama alanı.

Sürekli hizmet iyileştirmesi:

Hizmetleri daha da iyileştirmek için geliştirilebilecek alanların tanımlanma ve düzeltilme süreci.

Duruş süresi:

Belirli bir hizmetin kullanılabilir olmadığı dönem.

Olay:

BT hizmetinde planlanmamış bir kesinti veya bir BT hizmetinin kalitesinde azalış. Henüz bir hizmeti etkilememiş olsa bile bir yapılandırma öğesindeki başarısızlık da bir olaydır (ör. bir ayna setten bir diskteki arıza).

Sorun:

Bir veya daha fazla olayın nedeni veya olası nedeni.

Uygulama sonrası gözden geçirme:

Değişiklik planının herhangi bir sapma olmadan izlenip izlenmediğinin değerlendirildiği ve herhangi bir değişikliğin gerekip gerekmediğini görmek üzere uygulamanın incelendiği süreç.

Değişiklik isteği (RFC):

Geçerli bir nedenle bir değişikliği başlatma süreci.

Risk değerlendirmesi:

Bir değişiklikle ilgili olası riskleri değerlendirme süreci.

Hizmet masası:

Hizmet sağlayıcıları ve kuruluşun kullanıcıları arasındaki iletişim noktası.