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.
