Bilgi Teknolojilerinde Değişimi Yönetmek

iStock-482819124-1254x506[1]

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.

5608686e1900003000fde7df[1]

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.

IC-change-managment[1].png

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.

Teamwork[1]

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

CMDB, a pain in the neck… Is it really?

 

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.

CAREER-DEV_iStock-518310332[1]

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.

Explaining IT Strategies to the Non-IT Executives in a World of Technology

Why so expensive?

It’s what we usually hear from the C level executives in the budgeting period that IT is a huge cost. Are we doing something wrong? Are our estimations so bad that the C levels go crazy each time we sit down around the table.

Most probably NO!

But why do we get misunderstood?

Here you can find some answers from my experiences and thoughts on the dilemma of explaining IT budgets to the non-IT executives (especially for manufacturing companies in emerging markets).

The Problem:

Not everyone works in a tech company. Life is easier for those who work in tech since the executives know technology.

For the rest, you should understand that the technological progress is faster than the changes in the traditional businesses. Businesses like manufacturing or finance have evolved throuhout the years but the core processes remained more or less the same. Yes, they are using more technology today but their main processes are the same as they used to be in the past. There is automation, there is AI, they have all the data they don’t even need but they are still using all these technologies in order to do the jobs they used to do, just faster and more reliable.

I would like to point out that those are the 2 businesses that use technology the most, all the other businesses are behind these 2 which most of the economy relies on.

Technology became a part of almost all businesses very fast. Most companies did not even have computers or internet just 2 decades ago and now even the local store around the corner uses internet for banking and ordering goods. Technology is more and more integrated as the complexity and size of the business grows.

But most of these companies are run by executives who did not use computers as a part of their daily routine when they first started working. Some of them were able to be a part of the change and understand the meaning of IT in their business but for most of them IT is all about buying “computers and stuff”.

Today companies need infrastructure and software as well as support but that’s not the end. More business processes evolve with technology so larger companies started to either become tech companies or create tech companies to support their needs.

Outsourcing is an option, it s still profitable especially in the developed markets where the awareness and the level of technology is higher.

What about the emerging markets?

There is a great potential in the emerging markets since they still have a long way to go in their local businesses but on the other hand they are the ones outsourcing the developed markets so they have the right resources.

All they need is to have right strategies to lead the companies (or countries) in the right direction.

How are we supposed to convince the executives that what we are doing is not an extra cost but it is essential to the continuity of the business?

First of all we must all know that “doing what everyone else is doing” will not take us to the lead.

We must do what everyone else is doing and just then we will be on the same level with our competitors. We must look for areas of innovation after this point.

For many years, executives expected IT departments to miraculously take the company to another level when they wanted to invest on IT processes. They thought this was continuous improvement (or Kaizen if you are working in a Lean environment).

Let’s agree on something; being ITIL compliant or ISO 27001 certified is not something that will make you a star, it is the baseline. Whatever you do after that point will take you to the other levels.

Make sure that your executives are on the same page with you on this. Make sure that the IT standards are the baseline that you need to comply with, not a magic wand.

Form a compliance team to ensure your organization meets the baseline.

And now we can talk about innovation.

Internet of Things (IoT), Industry 4.0, Digital Transformation, Big Data, Artificial Intelligence and all those great areas of innovation is now ahead of you.

But again, doing what everyone else is doing is not going to get you to the lead so plan your projects accordingly.

First, start with baby steps: draw your technological baseline. See what everone else is doing and pinpoint the problematic areas to catch up with the baseline.

Form a team for innovation, do not overload the team with the routine, let the other teams handle the daily routine while the innovation team builds your future.

Keep it simple.

Use the power of iterative development.

Set achievable targets and manage the innovation.

And the world is yours once you pass the baseline.

There is one more thing to remember: yesterday’s innovation is today’s baseline.

So, improve continually!

Now it’s the Kaizen time 😉

Kurumsal IT Birimleri Neden Başarılı Olamıyor?

IT yöneticilerinin en büyük derdidir yapılan işi üst yönetime anlatabilmek. O kadar yüksek bir hızla dijitalleşen bir dünyadayız ki işe başladığı yıllarda iş yapma pratiği bilgisayar içermeyen pek çok beyaz yaka ile hala beraber çalışıyoruz ve üst yönetimler de çoğunlukla bu kişilerden oluşuyor.

Tüm şirketin birkaç bilgisayar ve yazılım ile döndürüldüğü 90’lardan her çalışanın bilgisayar, tablet, akıllı telefon gibi ara yüzlerle onlarca, hatta yüzlerce sisteme eriştiği günümüze 20 yıl gibi bir sürede geldik, arayüzler basitleştikçe arka plandaki sistemler karmaşıklaştı, sistemler karmaşıklaştıkça IT’nin işi zorlaştı ama son kullanıcı ve üst yönetimin gözü arayüzlerin arkasını göremediği için yapılan işi görünür hale getirmek de daha zor hale geldi.

Eski kafalı yöneticiler, eski alışkanlıklarına devam ettiler bu süreç boyunca ve şirketleri, teknolojik evrimlerinde güçsüz kaldılar. IT’nin kendine özgü sistematiği olduğunu kavrayamadılar, yanlış kurgulanan sistemler yamalı bohçalar haline geldikçe daha da vazgeçilmez oldular şirkette eski IT’ciler.

Ama diğer bir yandan da sorun ve masraf merkezi haline getirdiler IT’yi son kullanıcının ve tabii ki yönetimin gözünde.

IT’yi bir destek birimi olarak görmelerine rağmen IT’nin bir hizmet birimi olarak yapılanmasını gerçekleştiremeyen şirketlerde müşteri memnuniyeti düşerken, bel bağlanan sistemlerin kurumsal kurguda olmaması sebebiyle de verimlilikte beklenen artış yaşanmadı.

Bir de bunun üstüne çoğalan sistemlere ve büyüyen şirketlere paralel bir IT büyümesi gerçekleşmeyince memnuniyetsizlik arttı da arttı.

Bazı şirketler de sorunu tespit edebilmelerine rağmen ilacı yanlış kullandılar. IT hizmetlerini ITIL tabanlı süreçlere geçirirken süreçlerin sadece adlarının olduğu, eski yöntemlerin pratikte işletildiği bir yapıya büründüler, sonuç tabii ki yine düşük müşteri memnuniyeti.

Peki sorun neydi?

Kalite maliyetleri ya ihmal edildi, ya da dile getirilse bile kabul görmedi.

20 yıl öncesinin düşük teknolojili az sayıda sistemine göre kurgulanmış IT kadrosunu, yüksek teknolojili çok sayıda sistemden sorumlu tutup, bir de üzerine ekstra kalite süreçleri getirince bünye yapılan tedaviyi reddetti ve kendi içinde kısayollar oluşturmaya başladı.

Kısayollar kalite maliyeti yaratmadıklarından o an için işe yarar ve masrafsız sonuçlar verdiyse de uzun vadede getirdikleri kalitesizlik maliyetleri ile şirketlere daha büyük zarar verdi.

Peki treni kaçıran bu şirketler için endüstri 4.0, nesnelerin interneti ve dijitalleşme ile yakalanması gereken hedefin daha da hızlı uzaklaştığı bir dünyada çözüm nedir?

Yeniden yapılanma.

Ama daha önce denenen şekliyle değil, kanserli hücrelerden kurtularak, yapıyı sağlam temeller üzerine oturtarak.

Tabii ki IT’ye olan bakış açısında da değişikliklere gitmek gerekli bu yapılanma sırasında. IT’nin, ana iş kolunun iş yapış şeklinin ayrılmaz bir parçası olduğu gerçeğini kabullenerek kurgulanan bir şirket geleceğe emin adımlarla ilerleyebilir, aksi takdirde geçmişin tozlu sayfaları arasında kendisine yer edinmekten başka bir seçeneği yoktur.

Dijitalleşen dünyanın geleceği IT’dir. IT geleceğimizdir.