Erdem Aksoy

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.

Read it on Medium

For most of the organizations, maintaining a healthy CMDB (Configuration Management DataBase) is a really hard job.

Is it really that difficult or are we doing something wrong?

Let me tell you something, it is not that difficult and yes, you are doing something wrong.

Organizations start projects for CMDB implementation and most of them result with a failure. You are not destined to fail, all you need is to plan it right and take time to analyze before you implement, not the other way around.

And do not forget that the configuration management process is the core of IT service management, so have your CMDB and configuration management process before you start with other processes like change management for the best result.

First of all, start with a good scope definition. You don’t want to fill your CMDB with configuration items that you are not really dealing with. Take time to understand what different units work on, where do they keep their data, whether scanning and auto-populating the CMDB is possible, and on what extent the scanning tools can populate your CMDB.

Now you know what you can do and what you should do.

Decide on the classes and carefully select the attributes for each class depending on your needs and the capability of your data sources. You now have your organization’s data dictionary with all the details.

The next step is to decide on the relations between classes: Applications run on servers, depends on network and so on.

You are now ready to implement it once you have everything ready on paper.

Then comes the related processes, your service management will be shaped around the CMDB. How you are going to track the change history, when you are going to update a CI, how you are going to use the dependencies in order to fix the problems, they are all the subjects of related processes but cannot be done if you don’t have a steady CMDB.

It is not that difficult to accomplish but it must be done in the right order. Do it right once and you will be ready to excel in the other processes as well.