Özet
Kontrolden geçmemiş değişikliklerin IT servislerinde kesintiye neden olması, en çok karşılaşılan felaket senaryolarından biridir. Bu kesintiler işletmelerin donanım ve yazılımlarını kaybetmelerine neden olur. Bilgi kayıplarından doğacak itibar kaybı ise, aynı nedenden ötürü işletmenin başına gelebilecek başka bir felakettir.
Yanlış kurgulanmış/uygulanamayan IT Change Management süreçleri, IT servislerinin geri getirilmesinde gecikmelere, IT ekiplerinin gereğinden fazla mesai harcamasına, IT ekipleri ile farklı iş birimleri arasındaki diyaloğun zamanla bozulmasına neden olur. Tüm bu negatif girdiler, işletmenin maliyet kaybında önemli birer faktördür.
Bu makale, IT Change Management sürecinin tanımını yapmak, kurgulanış sürecindeki en iyi pratikleri ele almak, gereksinimleri ortaya koymak, sürecin rollerini tanımlamak ve araştırmanın teknik sonuçlarını paylaşmak amacıyla yazılmıştır.
- Giriş
Değişiklik yönetimi, kritik sistemlerde ve hizmetlerde değişiklik yaparken, IT hizmetlerindeki kesintileri en aza indirmek için tasarlanmış bir ITIL uygulamasıdır.
Değişiklik, hizmetler üzerinde doğrudan veya dolaylı etkisi olabilecek herhangi bir şeyi eklemek, değiştirmek veya kaldırmaktır.
Değişiklik yönetimi pratikleri, IT servislerinde yaşanabilecek olayları (incident) azaltmak ve yasal standartları karşılamak için tasarlanmıştır. Bu pratikler, IT altyapısı ve yazılımlardaki değişikliklerin verimli ve hızlı bir şekilde ele alınmasını sağlar. İster yeni hizmetler sunulsun, ister mevcut hizmetler yönetilsin, ister bir yazılımdaki sorunlar çözülsün, modern değişiklik yönetimi yaklaşımları siloları yıkar, şeffaflık sağlar, darboğazları önler ve riski en aza indirir. Risk yönetimi, ITIL v4 ile ilgili bir değişiklik yönetimi uygulamasıdır ve “kuruluşun riskleri anlamasını ve etkili bir şekilde işlemesini sağlamak için” uygulanır. Risk yönetimi, denetlenebilir bir veri sağlamak için değişiklikleri izleme ve birbirlerine bağlama işlemi gerektirir. İşletmelerin önceki değişiklikler ve bu değişiklikler üzerindeki başarı oranları hakkındaki verileri kullanma yeteneği, değişiklik yönetiminin kurgulanması sırasında işletmelere büyük oranda bir karar destek mekanizması sağlar. Değişiklik yönetimi risk ve uyumluluk, denetlenebilirlik ve takımlar arası koordinasyon ile ilgili zorluklarla uğraştığından, bu durum sıklıkla karmaşık ve bürokratik hale gelir.
Değişiklik yönetiminde doğru uygulamalar ve bu kültürün kurum içinde oturtulması; daha az olaya (incident), ekipler üzerinde daha az strese ve zamanın, müşterilere değer katmak için daha verimli kullanılmasına katkı sağlayabilir.
2. Tanımlar ve Kısaltmalar
IT : Information Technology
ITIL : IT Infrastructure Library
ITSM : IT Servis Management
IT Change Management : Bilgi Teknolojileri Değişiklik Yönetimi
CAB : Change Advisory Board (Değişiklik Danışma Kurulu)
ECAB : Emergency Change Advisory Board (Acil Durum Değişiklik Danışma Kurulu)
RFC : Request For Change
CR : Change Request
SLA : Service Level Agreement (Servis Seviyesi Anlaşması)
KPI : Key Performance Indicators
3. Değişiklik Yönetim Sürecinin Oluşturulması
Yeni bir değişiklik yönetim süreci oluşturulurken, bu sürecin kuruluşa özgü olduğu unutulmamalıdır. Standart bir süreç olması zorunlu değildir. Önemli olan resmi bir sürece sahip olmaktır. Değişiklik Yönetimi süreci oluşturulurken dikkat edilmesi gereken hususlar aşağıda verilmiştir:
- Kuruluş için kritik olan iş kolları belirlenmeli ve bunlar değişiklik yönetim sürecine dâhil edilmelidir.
- Sürecin oluşturulması sırasında tüm paydaşlar (IT tedarikçileri, iş birimleri, IT çalışanları ve liderleri) oluşumun içerisinde yer almalıdır.
- IT değişikliklerinin neleri kapsadığı belirlenmelidir (donanımsal ve yazılımsal anlamda tüm kaynaklar taranmalıdır).
3.1. Roller ve Sorumlulukların Belirlenmesi
IT perspektifinden değişiklik yönetiminin yerine getirilebilmesi için, rollerin açıkça belirlenmiş olması gerekmektedir. Tek bir kişi, birden fazla rol üstlenebilir. Rol ve sorumlulukların belirlenmesinde işletmenin sahip olduğu kaynaklar önem taşır. Rol ataması yapmanın ve sorumlulukları açıkça belirlemenin faydası, hesap verilebilirliği ve tutarlılığı sağlamaktır.
Makalenin bu bölümünde, kurumsal işletmelerde yaygın olarak kullanılan değişiklik yönetimi rolleri ve bu rollerin sorumlulukları açıkça ifade edilmeye çalışılmıştır:
Change Requester (Talep Eden)
Değişiklik talebini gönderen kişilerdir. Genel olarak aşağıdakileri yapmaktadır:
- Değişiklik taleplerinin eksiksiz (öncelik, etki, risk, zaman gibi gereksinimlerin oluşturulması) gönderilmesini sağlar.
- Değişiklikle ilgili iletişimi tüm paydaşlar arasında sürdürür.
- Değişikliği koordine etmek için, değişiklik uygulayıcısı ile birlikte çalışır.
Change Implementer (Uygulayıcı)
Değişikliği, onay mekanizmasından sonra bizzat uygulayandır. Bazı durumlarda Change Implementer, aynı zamanda Change Requester olabilir. Genel olarak aşağıdaki görevleri üstlenmektedir:
- Değişikliğin planlamasını, başlatılmasını ve yürütülmesini sağlar.
- Talebi yapılan değişikliğin tüm onayları almasını sağlar.
- Başarısız bir değişiklik durumunda, değişikliğin geri alınması işlemlerini yapar.
Change Approver (Onaylayıcı)
Her değişiklik talebine, uzmanlık alanına göre farklı onaylayıcılar (Approver) atanabilir. Örneğin değişiklik talebi network tarafında yapılacak bir yapılandırmayı içeriyor ise, değişiklik onaylayıcısı network tarafında yetkin biri olmalıdır. Aynı şekilde sistem, yazılım ve benzeri farklı uzmanlıklar için de farklı onaylayıcılar, ITSM uygulamasında yer almalıdır. Change Approver, değişiklik talebini incelemekten ve yapılan talebin teknik olarak uygulanmaya hazır hale getirilmesinden sorumludur. Ayrıca görevleri arasında şunlar da bulunur:
- Değişiklik talebinin geçerli bir iş gereksinimini karşılamasından emin olur.
- CAB’ e sunulacak değişiklik talebinin ilk onayını verir.
- Başarısız bir değişiklik durumunda, değişikliğin geri alınması için gerekli onayı verir.
Change Manager (Değişiklik Yöneticisi)
Değişiklik yöneticisi olarak anılır. Değişiklik yöneticiliği fonksiyonel bir pozisyon değildir. Çoğu zaman işletmeler, fonksiyonel IT yöneticilerine aynı zamanda Change Manager da derler. Bu rol, süreç ile ilgili iyileştirme fırsatlarının tanımlanmasından sorumludur ve sürecin kullanımını operasyonel düzeyde sürekli olarak denetler. Son olarak, değişiklik yöneticisi diğer hizmet yönetimi işlevleriyle (Incident Management, Release Management, Request Fulfillment, Knowledge Management gibi) bağlantı kurmak ve raporlar sunmaktan sorumludur.
Değişiklik yöneticisi, IT içerisinde bir etki sahibi veya karar alıcı olmalıdır. Genel olarak, değişiklik yöneticisi şu sorumluluklara sahiptir:
- CAB’ e başkanlık eder, toplantıları organize eder.
- CAB’ in, kurumun çıkarlarını korumak için tüm değişiklikleri uyum, uygun planlama ve iletişim açısından doğru değerlendirme ile gerçekleştirmesine destek olur.
- Değişiklik yönetim planını zamanlama olarak yönetir.
- Tamamlanan değişiklikleri kapatır.
- Değişiklik sonrası gerçekleştirilecek adımları belirler ve doğruluğunu kontrol eder.
- Değişiklik yönetim süreci ile ilgili problemleri, Değişiklik Yönetimi Süreç Sahibine bildirir.
- Değişiklik yönetim sürecinin iyileştirilmesine yönelik girdiler sağlar.
- Değişiklik yönetiminin raporlarını oluşturur ve süreç sahibine veya üst yönetime raporlar.
Change Management Process Owner (Süreç Sahibi)
Bu rolü yerine getiren kişi, değişiklik yönetimi sürecinin oluşturulması, işleyişi ve gelişmesi için uçtan uca sorumluluğa sahiptir. Değişiklik yönetimi süreç sahibinin temel rolü; sürecin verimli, etkili ve amacına uygun olmasını sağlamaktır. Değişiklik yönetimi süreç sahibi, IT disiplinlerinin ve süreç akışlarının entegrasyonunu sağlamak için diğer süreç sahipleriyle yakın işbirliği içinde çalışır. Şu görevleri gerçekleştirir:
- IT’ nin misyonu doğrultusunda değişiklik yönetimi misyonu ve stratejisinin geliştirilmesi, uygulanması ve iletişiminden sorumludur.
- Değişiklik yönetimi hizmetiyle ilgili SLA hedeflerinin geliştirilmesi ve bu hedefler üzerinde anlaşmaya varılmasını sağlar.
- Change Manager’ dan aldığı raporlara göre süreci iyileştirir ve geliştirir.
Change Advisory Board (CAB)
CAB, değişiklikleri denetlemek ve değişiklik yöneticisine değişikliklerin planlanması ve değerlendirilmesinde yardımcı olmak için toplanan bir gruptur. Bu grup her işletmede farklı olmakla birlikte, genellikle haftada bir defa veya iki haftada bir defa toplanır. CAB üyeleri, değişiklikleri tartışırken ve onaylarken hem iş, hem de teknik bakış açılarını kullanmalıdır. Bu nedenle CAB üyelerinin, hem iş birimlerinden hem de IT’ nin kritik noktalarındaki uzman kadrolarından oluşması gerekir. Sabit bir üye sayısı yoktur veya üyeler her iki haftada bir toplanan grup içerisinde aynı kişiler olmak zorunda değildir. Değişiklikler iki haftada bir farklılaşacağından, üyelerin de bu yönde farklılaşması sürece pozitif yönde katkı yapacaktır. CAB bir toplantı biçiminde gerçekleştirilir. Bu toplantıya CAB Meeting denir. CAB toplantılarında aşağıdakiler gerçekleştirilir:
- Her değişiklik talebi için ayrı ayrı olmak üzere, doğru risk ve iş-etki analizi yapılır.
- Önerilen değişiklikler tartışılır ve onaylanır, reddedilir veya ertelenir.
- Tamamlanan değişiklikler CAB’ de yeniden değerlendirilir.
- Tüm başarısız ve acil değişiklikler CAB’ de tekrar değerlendirilir.
CAB’ ler birkaç mekândan birinde toplanabilir:
- Bizzat: Fiziksel olarak aynı ortamda toplantı yapılır.
- Sanal: Yalnızca sesli veya görüntülü aramayla çevrimiçi toplantı metodu kullanılır.
- Hibrit: Aynı anda hem yüz yüze, hem de çevrimiçi olarak toplanılır.
Emergency Change Advisory Board (CAB)
ECAB, değişiklik yöneticisine acil durumlarda yetki verilmesini tavsiye eder. Tipik olarak üst düzey IT yöneticilerini ve acil durum değişikliğinden etkilenecek olan paydaşları içerir. ECAB, acil durumun niteliğine göre her hangi bir gün veya zaman aralığında toplanabilir. Temel görevi, acil durumda uygulanacak değişikliğin riskini ölçüp, değişikliğin uygulanıp uygulanmayacağına karar vermektir.
4. Değişiklik Yönetimi Aktiviteleri
Değişikliklerin uygulanması işletmelerin yapısına bağlı olarak değişse de, değişiklik yönetimi aktivitelerinin temel akışı aynı kalacaktır.
Değişiklik sayısına ve işletmenin büyüklüğüne bağlı olarak, değişikliğe dâhil olan kişi sayısı ve gerekli belgeler farklılık gösterebilir. Tablo 1‘ de listelenen faaliyetler kuruluşların değişiklik yönetimi süreçlerini oluşturmaya başlamasına yardımcı olabilir.
| Aktivite | Açıklama |
| 1.1. RFC Oluşturulması | Değişiklik talep eden (veya atanan kişi), bir risk ve etki analizi de dâhil olmak üzere, RFC’ yi oluşturmak için değişiklik yönetimi oluşturma talimatlarını izler (RFC oluşturmak için gereken bileşenler Tablo 2‘ de açıklanmıştır). Değişiklik uygulayıcısı akışın bu noktasında atanır. |
| 1.2. RFC Gönderilmesi | RFC, bir sistem kullanılarak onay için gönderilir. |
| 1.3. RFC İncelenmesi | RFC, bütünlük açısından gözden geçirilir. Değişikliğin türüne göre, istenen içerikler tamamlanmamışsa, talep değişiklik yöneticisi tarafından, talebi açana geri gönderilebilir. |
| 1.4. Risk ve etki analizinin yapılması | Değişiklik, risk ve iş-etki analizi anlamında gözden geçirilir (Risk ve Etki Bölüm 5’ te incelenmiştir). |
| 1.5. Değişikliğin onaylanması | Onay yetkilisi, gönderilen değişiklik zamanlamasında herhangi bir çakışma olmadığını doğrular. Değişiklik, uygulama için onaylanır ve uygun şekilde plan/uygulama/test/dağıtım ekiplerine gönderilir. RFC reddedilirse, değişiklik bir açıklama ile talep edene iade edilir. |
| 1.6. Değişiklik bilgilendirmesi | Değişikliği talep eden ve/veya değişiklik uygulayıcısı, değişiklik ayrıntılarını uygun paydaşlara iletir. |
| 1.7. Değişikliğin koordine edilmesi | Değişiklik uygulayıcısı, değişikliğin uygulanması için gereken adımları tanımlar, işi koordine eder ve değişikliği başlatır. Değişiklik başarısız olursa, değişiklik uygulayıcısı, hizmetin bilinen çalışma durumuna geri getirilmesi için geri çekme planını uygular. |
| 1.8. Çıktıların gözden geçirilmesi | Değişikliğin yürütülmesi üzerine, değişiklik uygulayıcısı ve değişikliği talep eden kişi, değişikliğin amaçlanan sonuçları ürettiğini doğrular. |
| 1.9. RFC Kapatılması | Change Manager veya Change Requester değişikliği kapatır. |
Makalenin bu bölümünde, etkinliklerin bir akış şemasında görülmesinin faydalı olacağı düşünülmüştür. Şekil 1, normal bir değişiklik için tipik bir değişiklik akışını göstermektedir. Bu şekil sadece aktivite adımlarını göstermekle kalmamış, aynı zamanda her adım için birincil rolleri de tanımlamıştır.
Değişiklik Talebi (RFC, Request For Change)
Değişiklik talebi, değişiklik beklentilerini özetleyen resmi bir belgedir. Talep bir sistem üzerinden açılıyor ise, bu belgeye Form ismi de verilebilir. Bir RFC; değişikliğin neden gerekli olduğunu, değişikliği yapmakla ilişkili riskleri ve bu risklerin nasıl azaltılabileceğini anlamak için bir işletmenin gerekli olduğuna inandığı bilgileri içermelidir. Bu formun yapısı her IT organizasyonunda farklıdır. Temel bir değişiklik talebi için en yaygın form/belge alanları Tablo 2‘ de gösterilmiştir.
| Alan | Açıklama |
| Referans No | RFC’ yi ayırt etmek için kullanılabilecek benzersiz bir tanımlayıcıdır. |
| Gönderilme Tarihi | RFC’ nin gönderildiği tarih. Değişiklik isteklerini izlemek için otomatik bir sistem kullanılıyorsa, sistem tarafından otomatik olarak oluşturulabilir. |
| Change Requester | Değişikliği talep eden kişinin adı bulunur. |
| Change Implementer | Değişikliği gerçekleştirecek kişinin adı bulunur. |
| Değişiklik Yapılacak Sistem | Değiştirilmesi istenen hizmetlerin veya sistemlerin basit bir açıklamasını içerir. |
| Değişikliğin Açıklaması | Kapsamın genel bir görünümünü ve değişikliğin ne başaracağını ve nasıl uygulanacağını anlamak için yeterli ayrıntıyı sağlar. |
| İş Gerekçesi | Değişikliğin neden gerekli olduğuna dair bir açıklama içerir. |
| Değişiklik için Talep Edilen Tarih | Değişikliğin uygulanacağı tarihi içerir. |
| Risk ve Etki Analizi | Değişikliğin riskleri ve etkisinin değerlendirilmesinin bu alanda bulunması gereklidir. Bu alan, değişikliğin etkisinin kapsamını (örn. Kaç kişinin etkilendiğini) içerir ve değişiklik sırasında hizmet veya sistemin beklenen kullanılabilirliğini (örn. Bir kesinti olup olmayacağı) belirtir. |
| Test/Doğrulama Planı | Uygulanan değişikliğin başarılı olup olmadığını öğrenmek için nasıl test edileceği ve doğrulanacağına dair kısa bir açıklama yazılır. |
| Düzeltme/Geri Çekme Planı | Değişiklik uygulaması başarısız olursa hangi adımların atılacağının ayrıntılarıdır. Plan, tersine çevrilebilecek değişiklikler için bir geri çekme planı biçiminde olabilir veya işletmenin tersine çevrilemeyen değişiklikler için süreklilik planını çağırmayı içerebilir. Düzeltme planı olmadan hiçbir talep kabul edilmemeli veya onaylanmamalıdır. Plan ayrıntılarının RFC’ ye dâhil edilmesi gerekmez, ancak belgelendirilmiş bir plan olduğu, nerede bulunacağı ve gerektiğinde planı kimin uygulayacağının kabul edilmesi gerekir. |
| İletişim Planı | Kuruluştaki değişikliğin niteliği ve etkisine göre kimlerin formda bulunması gerektiğine dair ayrıntılardır. Plan ayrıntıları, değişiklikten etkilenen tüm paydaşları ve kullanıcıları bilgilendirmek için gerekli iletişim kanallarını içermelidir. |
5. Risk ve Etki
Risk, zarara veya kayba neden olabilecek veya belirtilen hedeflere ulaşma kabiliyetini etkileyebilecek olası bir olay olarak tanımlanır. Sunulan RFC’ nin başarılı bir şekilde uygulanmasını olumsuz etkileyebilecek herhangi bir şey olarak düşünülebilir. Etki ise, bir değişikliğin insanlar ve iş süreçleri üzerindeki etkisinin bir ölçüsüdür.
Bir risk ve etki analizini kolaylaştırmak için değişiklik yetkilisinin gönderilen her değişiklik talebi hakkında detaylı bilgiye ihtiyacı vardır. Bu bilgiler genellikle değişiklik talep edenlerin bir değişiklik isteği gönderirken sağladığı soru-cevaplar biçiminde gelir.
Önerilen risk ve etki soruları, kendi değişiklik talebi gönderme süreçlerini kuran veya revize eden işletmeler için rehber olarak Tablo 3’ te sunulmuştur. Kurumlar tipik olarak her cevaba bir değer atar. Bu değerler, değişikliğin riskini ve etkisini hesaplamaya yardımcı olacaktır.
| Risk ve Etki Analizi Anketi |
| Bu değişiklik için tasarlanan etkinin kapsamı nedir? a. Kurumsal/tüm organizasyon b. Birden çok büyük iş birimi c. Bölgeye özel (tek bir bina veya küçük bir iş birimi) d. Küçük çalışma ekibi / küçük iş birimi |
| Bu değişiklik, karmaşık veya yüksek riskli mi? (Evet / Hayır) |
| Bu değişiklik potansiyel olarak diğer IT sistemlerinin kullanılabilirliğini, bütünlüğünü ve/veya güvenliğini etkileyebilir mi? (Evet / Hayır) |
| Değişiklik daha önce test edildi mi? (Evet / Hayır) |
| Uygulama sırasında, üzerinde değişiklik istenen sistem/hizmet hangi durumda olacak? a. Servis dışı b. Limitli fonksiyonel c. Read-only d. Normal veya yüksek erişilebilir sistem tarafından erişilebilir |
| Değişiklik ne zaman gerçekleşecek? a. Bakım periyodu sırasında b. Yoğun olmayan saatlerde ve çalışma saatleri dışında c. Yoğun olmayan çalışma saatleri içinde d. Herhangi bir zaman diliminde |
| Geri çekme (Rollback) planı nedir? a. Zor veya imkânsız b. Kolayca gerçekleştirilemese de mümkün c. Bakım periyodu içerisinde kolayca yapılabilir d. Minimal, en kısa sürede |
Gerek CAB toplantılarında, gerekse CAB’ e gitmeden, Change Manager Tablo 3’ teki sorulara cevap arar ve değişikliğin yapılıp yapılmayacağı bu sorulara verilen cevaplar ile ortaya çıkar.
6. Değişiklik Yönetimi ve Sürüm Yönetimi Arasındaki İlişki
Sürüm yönetimi ile değişiklik yönetimi arasındaki ilişkide önemli olan, yeni bir uygulamadır. ITIL 4′ e göre, “sürüm yönetiminin amacı yeni ve değiştirilmiş hizmet ve özellikleri kullanıma sunmaktır”. Sürümler, yazılımlardaki değişikliklerden dökümantasyon ve eğitim güncellemelerine kadar her şeyi içerebilir.
Sürüm yönetimi, geleneksel olarak değişiklikleri bir araya getirerek müşterilere bir paket halinde sunar. Bu geleneksel yöntem, katı proje yönetimi standartlarını destekler ve müşterilere değerli güncellemeler göndermede çakışma yaratarak Çevik ilkelere bağlı ekipler arasında hayal kırıklığına yol açabilir.
Değişiklik yönetimi süreci için düşünüldüğünde, DevOps kullanılarak sürüm yönetimi yeniden tasarlanabilir. Başarının anahtarı ise, geleneksel proje yönetimi işlevinden uzaklaşarak, sürüm yönetimi entegrasyon ve otomasyon ile ilgili olmalıdır.
Bir başka bilimsel bakış açısı; değişiklik yönetimi ile sürüm yönetiminde DevOps ile bu işi gerçekleştirmenin; kod mimarisini, mümkün olduğunda otomatik incelemeyi içeren, izleme ve denetleme sağlayan güvenli bir sisteme geçilerek başlanması gerektiğini söyler. Bu yeni bakış açısına göre, sürüm yönetimi standart yaklaşımları parçalayabilir ve üretime çakışma olmadan yeni bir yol sağlayabilir. Böylece sürüm yönetiminde, sürekli olarak değer sunma prensibini uygulamak hiç olmadığı kadar kolay olabilir. Bu konu, farklı bir bilimsel makale konusudur.
7. En İyi Uygulama Pratikleri
Bir değişiklik yönetimi uygulaması, işletmelerin bir yandan istikrar sağlarken ve riski azaltırken bir yandan sistemlere yeni güncellemeler göndermesini sağlar. Değişiklik yönetimi, değişikliğin aşağıdaki şekillerde gerçekleştirilmesine yardımcı olur:
- Değişiklik sürecini yönetmek için bir çerçeve oluşturulması
- Kaynakların uygun şekilde ayrılması için gerçekten gerekli değişikliklere öncelik verilmesi
- Daha verimli kararlar alınması için gerekli bilgilerin RFC’ ye dâhil edilmesi
- Değişiklik onayları için iş birimlerinden ve IT’ den gerekli paydaşların süreçlere dâhil edilmesi
- Hizmet kesintilerinin önlenmesi için değişikliklerin testinin sürece dâhil edilmesi
- Daha hızlı değer sunulması için değişikliklerin akışının bir düzene konması ve sürekli iyileştirilmesi
7.1. Örnek Service Desk Uygulaması
Makalenin bu bölümü, diğer tüm bölümlerde anlatılanların okurlar tarafından yeniden uygulanabilir olduğunu kanıtlamak için hazırlanmıştır. Change Management en iyi pratikleri; örnek bir Service Desk uygulaması üzerinde iş akışı, talep oluşturma, talebin cevaplanması şeklinde modellenmiş ve gösterilmiştir.
Yapılan uygulamada;
- Service Desk ürünü olarak test amaçlı bir ürün seçildi.
- Makalede, Şekil 1’ de belirtilen iş akışı oluşturuldu.
- Örnek bir Normal Change oluşturuldu.
- Service Desk tarafından sunulan tüm gerekli alanlar dolduruldu (Bkz. Tablo 2).
- Oluşturulan Normal Change iş akışına göre önce Change Manager’ a onaya gönderildi.
- Change Manager tarafından teknik olarak onaylanan değişiklik, CAB’ e gönderildi.
- CAB tarafından onaylanan değişiklik, Implementer tarafından uygulandı.
- Uygulanan değişiklik ile ilgili müşteriye bilgi verildi.
8. Tavsiyeler
Makalenin önceki bölümlerinde de anlatıldığı gibi, değişiklik yönetimi, her zaman dört gözle beklenmemektedir, ama ne kadar önemli olduğu da herkes tarafından bilinmektedir. Uygulaması zor olan Change Management sürecinin cazip hale getirilmesi için bir takım tavsiyeler aşağıda maddeler halinde sunulmuştur:
- İşletmenin risk toleransının anlaşılması
- Yasak yükümlülüklerin anlaşılması
- Mümkün olan yerlerde (özellikle onay süreçlerinde) süreçlerin basitleştirilmesi
- Mümkün olan yerlerde (özellikle onay süreçlerinde) süreçlerin otomasyona bağlanması
- CAB’ lere teknik detaydan çok stratejik bilgilerin sunulması
- ITIL ve DevOps gibi rehber ve çatılardan sıkça faydalanılması
- İşbirliğine (değişiklikten etkilenen iş birimleri ile) öncelik verilmesi
- Değişiklik talep alımlarının kolaylaştırılması (Service Desk türü uygulamaların kullanılması)
- Değişiklik metriklerinin öğrenilmesi (KPI vb.)
- Sürüm Yönetiminde DevOps temelli bir yaklaşımın benimsenmesi
9. Sonuç
Bu araştırmada, IT Change Management (BT Değişiklik Yönetimi) sürecinin oluşumu uçtan uca aktarılmaya çalışıldı. Sürecin kuralları, esnetilebilen veya esnetilemeyen yönleri gösterildi. ITIL çerçevesinde IT’ ye negatif yönde etki edecek etmenler nitel şekilde araştırıldı ve referanslar eşliğinde bu sorunlara çözüm arandı. Bu bilgiler ışığında:
Değişiklik yönetimi uygulanırken, bir değişikliğin oluşturulabilmesi için ortalama on iki (12) form alanının doldurulabileceği gösterildi (Bkz. Tablo 2:RFC bileşenleri).
Değişiklik yönetiminin uygulanışı sırasında, iş akışlarının en az 6 veya 7 rol ile işletilebileceği anlatılmaya çalışıldı (Bkz. 3.1. Roller ve Sorumlulukların Belirlenmesi).
Söz konusu iş akışlarını işletmeye özel belirlenme özgürlüğü bulunmakla birlikte, dokuz (9) adımdan oluşmasının optimum faydayı sağlayacağı nitel olarak anlatıldı. Örnek bir IT Service Desk uygulaması üzerinde bu veriler okurlar tarafından tekrar test edilebilir olarak gösterildi.
10. Referanslar
The ITSM Benchmarking Report – Axelos,2019
IT Change Management A Practical Approach – Educause,2018
Guidelines for ITIL Implementation – Mian Abbas Ahmed, 2015
Innovate ITIL: A DevOps Approach to the ITIL Framework – Sean D. Mack,2018
A Deep Dive into ITIL 4 – Beyond20, 2020
IT Change Management Best Practices – JIRA, 2020
The Evolution of IT Change Management – JIRA, 2020