ITIL Sürekli Gelişim Süreci

Her şirket için sürekli gelişim tabii ki çok önemlidir, fakat bu yazıda ITIL (Information Technology Infrastructure Library) perspektifiyle gelişim ele alınacak.

ITIL, sürekli gelişimi şu adımlarla ifade ediyor;
1. Neyin ölçülmesi gerektiğini belirleyin.
2. Neyi "ölçebileceğinizi" belirleyin
3. Data toplayın - Disiplinli ve sabırlı bir çalışma gerektirir
4. Datayı işleyin (anlamlı bir formata çevirin, raporlar oluşturma vs.)
5. Datayı Analiz Edin (Üretilen raporların analizi)
6. Analiz sonucunu ilgili rollere sunun ve bilgiyi kullanın
7. Gerekli düzenleyici aksiyonları alın.



Farzedelim ki bir yazılım şirketisiniz sürekli gelişim için ölçmeniz gereken metriklerden biri 1000 satır içindeki defect sayısı olsun. 1. adım için ölçülmesi gerekeni belirledik peki gelelim 2. adıma peki bu veriyi ölçebiliyor muyuz? Teknik olarak ölçmekte bir sorun yok fakat bu ölçüme üst yönetim ne kadar önem veriyor? Bu veri ölçüldükten sonra 7. adıma kadar bu süreçte veriler taşınacak mıdır? Bu soruların cevabı önemli ve belirleyici. 7. adıma kadar etkisi olmayacak bir verinin ölçümü boşa zaman ve para harcamaktır. Bu durumdan daha da kötüsü ölçülmesi çok kolay olmayan metriklerin yanlış ölçülmesi dolayısı ile yanlış yorumlanması ve yanlış aksiyonların alınmasıdır, bu durum çok daha dramatik sonuçlar doğurur.

Bir yazılım şirketi için "Defect oranı" 1. adım içerisinde yeralan yani ölçülmesi gereken metriklerden biri. Şirketin bu veriyi ölçecek olgunlukta ve yetkinlikte olduğunu varsayarsak 2. adımı da şirket, yazılım kalitesi adına atmış olur. 3. Adım için aksiyon alınmalı ve barajda suların (defect verilerinin) birikmesi beklenmeli unutmayalım daha sonra bu sulardan enerji üretilecektir. Tabii ki bu süre içerisinde diğer adımlar için yöntem belirleme ve planlama yapmak için uygun fırsat ve zaman olacaktır.

Bir başka veri; "Geliştirilen Yazılımların Karmaşıklık Derecesi" ölçülmesi gereken yada ölçülebilen bir metrik midir? Projelerin büyüklükleri ile karmaşıklık derecesi birbirine karıştırılmamalıdır. Bu veri ölçülmeli midir(1. Adım)? Evet kesinlikle ölçülmelidir çünkü bir önceki veri olan defect sayısını direkt etkileyen bir faktör olabilir. Fakat bu veriyi şirket olarak doğru ölçüp ölçemeyeceğinizi objektif bir şekilde kendinize itiraf etmelisiniz. Keza bu veriyi oluşturacak donelerin hepsinin tangible(sayılabilir/somut) olmadığı aşikardır. Ölçüm yapmadan da şirket bünyesinde geliştirilen yazılımların karmaşıklıkları arasındaki farkların dikkate değer olup olmadığı da bir şekilde gözlemlenebilir.

Unutmamak gerekir ki yanlış ölçümler, yanlış aksiyonların alınmasını tetikler ve genelde hiç ölçmemekten daha maliyetlidir. Bu nedenler egoları bir kenara bırakıp özellikle 2. adım için doğru kararlar alınması son derece önemlidir.

ITIL Sürekli gelişim adımlarını açıklamak için 2 veri ele alındı. İlgili veriler hem Bilgi Teknolojileri sektöründe hem de diğer sektörler için çeşitlendirilerek süreç işletilebilir.

BT Servis Operasyonlarında Kurulması Gereken Denge

ITIL derki;
Servis Operasyonları tekrarlanan standart işlemlerden daha fazlasını kapsamaktadır. Kullanıcılara sağlanan bütün fonksiyonaliteler, süreçler, aktiviteler belirli bir katma değer sağlamak için tasarlanmıştır fakat bir yandan bu servisler her zaman gelişmektedir.
BT Ekiplerinin içe ve dışa odaklanmaları birbirleri ile çatışan çalışmalar içerebilir. Fazlası ile dışa odaklı BT Ekipleri, müşteri odaklı çalışırlar, müşterilerin isterklerine öncelik verirler onlara kesintisiz bir hizmet sunmak için hızlı çözümler üretirler.

Bilgi Teknolojileri çok hızlı değişen çeşitli sistemler üzerine kurulu olduğu için içe odaklı BT Ekipleri, kendilerine bu anlamda geliştirmeye yönelik çalışmalara ağırlık verirler. Her ne kadar temel amaç müşteri memnuniyeti olsa da, kaliteli hizmet teslimleri daha çok zaman ve para gerektirebiliyor.



Fazlası ile dış odaklı BT Birimleri müşteriye verile taahütlerin çok hesabını yapmaz her talebi hızlıca gerçekleştirebileceğine inanır ve genelde sonuç, yerine getirilemeyen taahütler, orta ya da uzun zamanda çıkan teknolojik sorunlar olur. Fazlası ile içe bağımlı BT Birimleri çok gelişmiş sistemleri müşterinin çok basit bir ihtiyacını karşılamak için kullanabilir bu durumda servisler çok daha pahalı sunulabilir.

Peki hangi yaklaşım doğrudur? İşte burda iç ve dış odaklı çalışmaların dengesi tutturulmalıdır. Terazi herhangi bir tarafa çok kaymamalıdır. Birden çok BT Birimini barındıran kurumlarda, BT Birimlerinin kendi içerisindeki yaklaşımlarının da diğer BT Birimleri ile uyumlu olmalıdır.